From owner-freebsd-current@freebsd.org Sun Apr 3 07:02: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 0AF8CB005FB for ; Sun, 3 Apr 2016 07:02:30 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-157.reflexion.net [208.70.211.157]) (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 BF37E12F6 for ; Sun, 3 Apr 2016 07:02:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 18283 invoked from network); 3 Apr 2016 07:02:23 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 3 Apr 2016 07:02:23 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.2) with SMTP; Sun, 03 Apr 2016 03:02:13 -0400 (EDT) Received: (qmail 23008 invoked from network); 3 Apr 2016 07:02:13 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 3 Apr 2016 07:02:13 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 29735B1E001; Sat, 2 Apr 2016 23:06:42 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build) From: Mark Millard In-Reply-To: Date: Sat, 2 Apr 2016 23:06:48 -0700 Cc: Dimitry Andric , FreeBSD Toolchain , FreeBSD Current , Gerald Pfeifer , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <53DAD70E-8DE4-4DBA-BF88-AD7F51B0B816@dsl-only.net> References: <5A0ACA76-6F1D-4975-9E59-2A64BB8EFC77@dsl-only.net> <56FD9757.6040709@FreeBSD.org> <9E3033D5-F416-4B78-97C2-0A0AABF5A49E@dsl-only.net> <56FDA5F9.1090601@FreeBSD.org> <5FDFDC6A-911B-4A77-BCEF-BBB711BFA0AC@FreeBSD.org> <5334F356-982F-40CA-9009-41B59AAC8665@dsl-only.net> To: Warner Losh , Bryan Drewery X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 03 Apr 2016 07:02:30 -0000 On 2016-Apr-2, at 3:59 PM, Mark Millard wrote: > [My testing for the likes of the below does not yet extend outside = powerpc64 contexts.] >=20 > For the likes of self-hosted powerpc64-xtoolchain-gcc/powerpc64-gcc = use with, say, gcc49 materials as the so-called "host" compiler tools I = have not yet found a way around using the workaround: >=20 >> # ls -l /usr/lib/libstdc++.* >> lrwxr-xr-x 1 root wheel 17 Feb 23 00:09 /usr/lib/libstdc++.a -> = /usr/lib/libc++.a >> lrwxr-xr-x 1 root wheel 18 Feb 23 00:09 /usr/lib/libstdc++.so -> = /usr/lib/libc++.so >=20 >=20 >=20 > But I appear to now have a src.conf (or a family of them) that avoids = needing workarounds in /usr/local/include and /usr/local/lib for = filename conflicts. This is based on CC/CXX ("HOST") and XCC/XCXX = ("CROSS") in src.conf being the likes of: >=20 > "HOST" (CC/CXX): >> CC=3Denv C_INCLUDE_PATH=3D/usr/include /usr/local/bin/gcc49 = -L/usr/lib >> CXX=3Denv C_INCLUDE_PATH=3D/usr/include = CPLUS_INCLUDE_PATH=3D/usr/include/c++/v1 /usr/local/bin/g++49 -std=3Dc++11= -nostdinc++ -L/usr/lib >=20 > and. . . >=20 > "CROSS" (XCC/XCXX): >> TO_TYPE=3Dpowerpc64 >> TOOLS_TO_TYPE=3D${TO_TYPE} >> . . . >> VERSION_CONTEXT=3D11.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= ++ >=20 > In other words: CROSS use is already handled for /usr/local/. . . just = given the compiler paths but some special src.conf adjustments beyond = compiler paths were needed for HOST. >=20 > So far it appears that gcc49 materials can be used in "CROSS" and/or = powerpc64-gcc materials can be used in "HOST" via just appropriate = compiler-path editing. (I have jumped to testing -r297514 but am still = doing various build tests. So this aspect is subject to updates.) It = appears to be possible to use just one compiler/tool family --but in the = 2 different ways-- instead of using a mix of 2 compiler/tool families. >=20 > Historically I've not gotten gcc variants to make a working lib32 for = powerpc64 and I've yet to retest this: So no claims about the lib32 = status are implied here. (The problem was code in crtbeginS that = arbitrarily used R30 in a way that the context was not set up for and so = crtbeginS code was dereferencing arbitrary addresses.) I probably knew this someplace in the back of my head but gcc49 does not = handle -fformat-extensions (quoting the script log): > --- accf_data.o --- > env /usr/local/bin/gcc49 -isystem = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include = -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib = --sysroot=3D/usr/obj/xtoolchain/powerpc.powerp > c64/usr/src/tmp -B/usr/local/powerpc64-portbld-freebsd11.0/bin/ -O2 = -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODEBUG/op= t_global.h -I. -I/usr/src/sys -fno-common -g -mlongcall = -fno-omit-frame-pointer = -I/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODEBUG = -MD -MF.depend.accf_data.o -MTaccf_data.o -mno-altivec -ffreestanding = -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls = -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes = -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign = -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option = -Wno-unknown-pragmas -Wno-error=3Dinline -Wno-error=3Denum-compare = -Wno-error=3Dunused-but-set-variable = -Wno-error=3Daggressive-loop-optimizations = -Wno-error=3Dmaybe-uninitialized -Wno-error=3Darray-bounds = -Wno-error=3Daddress -Wno-error=3Dcast-qual -Wno-error=3Dsequence-point = -Wno-error=3Dattributes -Wno-error=3Dstrict-overflow = -Wno-error=3Doverflow -v -finline-limit=3D15000 -fms-extensions --param = inline-unit-growth=3D100 --param large-function-growth=3D1000 = -msoft-float -mcall-aixdesc -std=3Diso9899:1999 -c = /usr/src/sys/modules/accf_data/../../netinet/accf_data.c -o accf_data.o > Using built-in specs. > COLLECT_GCC=3D/usr/local/bin/gcc49 > gcc49: error: unrecognized command line option '-fformat-extensions' > Target: powerpc64-portbld-freebsd11.0 > Configured with: ./../gcc-4.9-20160210/configure --disable-multilib = --disable-bootstrap --disable-nls --enable-gnu-indirect-function = --libdir=3D/usr/local/lib/gcc49 --libexecdir=3D/usr/local/libexec/gcc49 = --program-suffix=3D49 --with-as=3D/usr/local/bin/as = --with-gmp=3D/usr/local = --with-gxx-include-dir=3D/usr/local/lib/gcc49/include/c++/ = --with-ld=3D/usr/local/bin/ld --with-pkgversion=3D'FreeBSD Ports = Collection' --with-system-zlib --disable-libgcj = --enable-languages=3Dc,c++,objc,fortran --prefix=3D/usr/local = --localstatedir=3D/var --mandir=3D/usr/local/man = --infodir=3D/usr/local/info/gcc49 --build=3Dpowerpc64-portbld-freebsd11.0 > Thread model: posix > gcc version 4.9.4 20160210 (prerelease) (FreeBSD Ports Collection)=20 > *** [accf_data.o] Error code 1 So my > it appears that gcc49 materials can be used in "CROSS" is just false for gcc49, gcc5, and the like. I had hoped such would work with TARGET_ARCH=3Dpowerpc because there is = no powerpc-gcc port predefined and clang 3.8.0 is still insufficient for = this context. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Apr-1, at 4:35 PM, Mark Millard wrote: >=20 > [Just a top-post showing what powerpc64-xtoolchain-gcc/powerpc64-gcc = has for the default include search places:] >=20 > powerpc64-xtoolchain-gcc/powerpc64-gcc also looks in = /usr/local/include before /usr/include : see below. >=20 >> # portmaster --list-origins >> . . . >> devel/powerpc64-xtoolchain-gcc >> . . . >>=20 >> # /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc --version >> powerpc64-portbld-freebsd11.0-gcc (FreeBSD Ports Collection for = powerpc64) 5.3.0 >> Copyright (C) 2015 Free Software Foundation, Inc. >> This is free software; see the source for copying conditions. There = is NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR = PURPOSE. >>=20 >> # echo '' |/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -v -x c++ = - -o /dev/null >> . . . >> ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../includ= e/c++/5.3.0" >> ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../includ= e/c++/5.3.0/powerpc64-portbld-freebsd11.0" >> ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../includ= e/c++/5.3.0/backward" >> ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../powerp= c64-portbld-freebsd11.0/include" >> #include "..." search starts here: >> #include <...> search starts here: >> /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include >> /usr/local/include >> /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include-fixed >> /usr/include >> End of search list. >> . . . >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net > On 2016-Apr-1, at 7:25 AM, Warner Losh wrote: >=20 >=20 >=20 > On Fri, Apr 1, 2016 at 2:25 AM, Dimitry Andric = wrote: > On 01 Apr 2016, at 00:44, Warner Losh wrote: >>=20 >>> On Mar 31, 2016, at 4:34 PM, Bryan Drewery = wrote: >>> I didn't realize the ports compiler was defaulting = /usr/local/include >>> into the search path now. It does not have /usr/local/lib in the >>> default library path as far as I can tell. It's also broken for its >>> -rpath (noted in its pkg-message). So having a default >>> /usr/local/include path seems odd. >>=20 >> It has for a while now. It=E2=80=99s one of the maddening = inconsistencies that abound in this >> area. I took a poll a while ago and there seemed to be widespread = support for adding >> it to the base compiler. >=20 > This was the main reason /usr/local/include was *not* included in the > base compiler, otherwise it would unpredictably pick up headers in > /usr/local/include during builds. You can never know which = conflicting > headers a certain user has installed in /usr/local/include... :) >=20 > That's why it shouldn't be *FIRST*, not why it shouldn't be there > at all. >=20 >>> Adding -isystem /usr/include to fix this is probably possible but >>> there's a risk someone will remove it as redundant. In this case I = wish >>> /usr/include was first but I'm not sure what impact that would have = on >>> consumers expecting /usr/local/include (and /usr/local/lib) = overrides to >>> work, though they would need to pass a -L /usr/local/lib anyhow and >>> would likely be passing -I /usr/local/lib too. >>=20 >> /usr/include should be first. But it isn=E2=80=99t. That=E2=80=99s = another inconsistency that was found >> when we looked at /usr/local stuff. Someone recently added = /usr/local/bin to the path, >> if I recall correctly. >=20 > Isn't that a bit of a bikeshed? I guess some people would just as = well > prefer /usr/local/include to be first, just like some people prefer > /usr/local/bin before /usr/bin in their PATH. >=20 > Sigh. No. /usr/local is moving into many different things in the base = and ports. We should > do it in a consistent way. What we have now is not consistent and = somewhat brittle. >=20 > In any case, if such paths are added to external compilers, we better > make sure almost everything in buildworld uses -nostdinc, and = specifying > exactly the include directories we need, and no others. Cumbersome, = but > maybe for a good cause. >=20 > That's the non-brittle solution here. An over-reliance on defaults = makes it > difficult to ensure other compilers will work, especially ones we = don't > tightly control the defaults for. >=20 > Warner From owner-freebsd-current@freebsd.org Sun Apr 3 09:39:45 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 A50B3ADE6A9 for ; Sun, 3 Apr 2016 09:39:45 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 895A91B3B; Sun, 3 Apr 2016 09:39:45 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id A85CC12B5; Sun, 3 Apr 2016 09:39:44 +0000 (UTC) Date: Sun, 3 Apr 2016 09:39:42 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: avg@FreeBSD.org, jmcneill@FreeBSD.org, dchagin@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <2034599654.182.1459676383628.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_amd64_gcc X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 09:39:45 -0000 FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1144/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1144/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1144/console Change summaries: 297521 by avg: fix zfs set canmount=off on an unmounted filesystem Previously this operation tried to unmount and remount children. Also see https://www.illumos.org/issues/6428. MFC after: 2 weeks X-Needs-Upstreaming: illumos 297520 by avg: zfs receive: -u can be ignored sometimes When force-receiving a filesystem that was already mounted the re-created filesystem is mounted despite -u flag. Also see https://www.illumos.org/issues/6412. PR: 204705 Tested by: Vladimir Krstulja MFC after: 2 weeks X-Needs-Upstreaming: illumos 297519 by dchagin: Move Linux specific times tests up to guarantee the values are defined. CID: 1305178 Submitted by: pfg@ MFC after: 1 week 297514 by jmcneill: Improve HDMI display detection by searching the CEA-861 extension block for an HDMI vendor-specific data block (VSDB) containing the HDMI 24-bit IEEE registration ID (0x000C03). Approved by: gonzo (mentor) 297513 by avg: remove emulation of VFS_HOLD and VFS_RELE from opensolaris compat On FreeBSD VFS_HOLD/VN_RELE were mapped to MNT_REF/MNT_REL that manipulate mnt_ref. But the job of properly maintaining the reference count is already automatically performed by insmntque(9) and delmntque(9). So, in effect all ZFS vnodes referenced the corresponding mountpoint twice. That was completely harmless, but we want to be very explicit about what FreeBSD VFS APIs are used, because illumos VFS_HOLD and FreeBSD MNT_REF provide quite different guarantees with respect to the held vfs_t / mountpoint. On illumos VFS_HOLD is sufficient to guarantee that vfs_t.vfs_data stays valid. On the other hand, on FreeBSD MNT_REF does *not* provide the same guarantee about mnt_data. We have to use vfs_busy() to get that guarantee. Thus, the calls to VFS_HOLD/VFS_RELE on vnode init and fini are removed. VFS_HOLD calls are replaced with vfs_busy in the ioctl handlers. And because vfs_busy has a richer interface that can not be dumbed down in all cases it's better to explicitly use it rather than trying to mask it behind VFS_HOLD. This change fixes a panic that could result from a race between zfs_umount() and zfs_ioc_rollback(). We observed a case where zfsvfs_free() tried to destroy data that zfsvfs_teardown() was still using. That happened because there was nothing to prevent unmounting of a ZFS filesystem that was in between zfs_suspend_fs() and zfs_resume_fs(). Reviewed by: kib, smh MFC after: 3 weeks Sponsored by: ClusterHQ Differential Revision: https://reviews.freebsd.org/D2794 The end of the build log: Started by an SCM change Building remotely on jenkins10a.freebsd.org (FreeBSD-10) in workspace /builds/FreeBSD_HEAD_amd64_gcc Updating svn://svn.freebsd.org/base/head at revision '2016-04-03T09:38:08.949 +0000' U cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c U cddl/contrib/opensolaris/lib/libzfs/common/libzfs_sendrecv.c U sys/compat/linux/linux_misc.c U sys/arm/allwinner/a10_hdmi.c U sys/cddl/compat/opensolaris/sys/vfs.h U sys/cddl/contrib/opensolaris/uts/common/fs/gfs.c U sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c U sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c At revision 297521 No emails were triggered. [FreeBSD_HEAD_amd64_gcc] $ /bin/sh -xe /tmp/hudson8754098237068074298.sh + cat + svn revert Makefile.inc1 + svn revert sys/boot/i386/Makefile Reverted 'sys/boot/i386/Makefile' + patch -f Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/boot/i386/Makefile |=================================================================== |--- sys/boot/i386/Makefile (revision 280912) |+++ sys/boot/i386/Makefile (working copy) -------------------------- Patching file sys/boot/i386/Makefile using Plan A... Hunk #1 succeeded at 16 (offset 4 lines). Hmm... Ignoring the trailing garbage. done + /vm/freebsd-ci/scripts/build/cross-build.sh + [ -z /builds/FreeBSD_HEAD_amd64_gcc ] + [ -z amd64 ] + export MAKEOBJDIRPREFIX=/builds/FreeBSD_HEAD_amd64_gcc/obj + mkdir -p /builds/FreeBSD_HEAD_amd64_gcc/obj + echo -e 'NO_WERROR=yes WERROR= WITH_FAST_DEPEND=yes' + cat + set +x -------------------------------------------------------------- >>> /builds/FreeBSD_HEAD_amd64_gcc/make.conf contains: + cat /builds/FreeBSD_HEAD_amd64_gcc/make.conf # Put make.conf entries here NO_WERROR=yes WERROR= WITH_FAST_DEPEND=yes + set +x -------------------------------------------------------------- + sudo pkg install -y devel/amd64-xtoolchain-gcc Updating FreeBSD repository catalogue... Fetching meta.txz: . done Fetching packagesite.txz: .......... done Processing entries: .......... done FreeBSD repository update completed. 25093 packages processed. New version of pkg detected; it needs to be installed first. The following 1 package(s) will be affected (of 0 checked): Installed packages to be UPGRADED: pkg: 1.6.4_1 -> 1.7.1 The process will require 84 KiB more space. 2 MiB to be downloaded. Fetching pkg-1.7.1.txz: .......... done Checking integrity... done (0 conflicting) [1/1] Upgrading pkg from 1.6.4_1 to 1.7.1... [1/1] Extracting pkg-1.7.1: .......... done Updating FreeBSD repository catalogue... Repo "FreeBSD" upgrade schema 2012 to 2013: Add vital field FreeBSD repository is up-to-date. All repositories are up-to-date. Build step 'Execute shell' marked build as failure [WARNINGS] Skipping publisher since build result is FAILURE IRC notifier plugin: Sending notification to: #freebsd-commits Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-current@freebsd.org Sun Apr 3 17:20: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 E45E9B01F6C for ; Sun, 3 Apr 2016 17:20:10 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8AAAB104D; Sun, 3 Apr 2016 17:20:09 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA14445; Sun, 03 Apr 2016 20:20:01 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1amlgv-0005u0-4z; Sun, 03 Apr 2016 20:20:01 +0300 Subject: Re: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure To: jenkins-admin@FreeBSD.org, jmcneill@FreeBSD.org, dchagin@FreeBSD.org, freebsd-current@FreeBSD.org References: <2034599654.182.1459676383628.JavaMail.jenkins@jenkins-9.freebsd.org> From: Andriy Gapon Message-ID: <57015089.4010700@FreeBSD.org> Date: Sun, 3 Apr 2016 20:19:05 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <2034599654.182.1459676383628.JavaMail.jenkins@jenkins-9.freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 03 Apr 2016 17:20:11 -0000 I wasn't able to understand what was the failure here... On 03/04/2016 12:39, jenkins-admin@FreeBSD.org wrote: > FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure: > > Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1144/ > Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1144/changes > Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1144/console > > Change summaries: > > 297521 by avg: > fix zfs set canmount=off on an unmounted filesystem > > Previously this operation tried to unmount and remount children. > Also see https://www.illumos.org/issues/6428. > > MFC after: 2 weeks > X-Needs-Upstreaming: illumos > > 297520 by avg: > zfs receive: -u can be ignored sometimes > > When force-receiving a filesystem that was already mounted the re-created > filesystem is mounted despite -u flag. > > Also see https://www.illumos.org/issues/6412. > > PR: 204705 > Tested by: Vladimir Krstulja > MFC after: 2 weeks > X-Needs-Upstreaming: illumos > > 297519 by dchagin: > Move Linux specific times tests up to guarantee the values are defined. > > CID: 1305178 > Submitted by: pfg@ > MFC after: 1 week > > 297514 by jmcneill: > Improve HDMI display detection by searching the CEA-861 extension block for > an HDMI vendor-specific data block (VSDB) containing the HDMI 24-bit IEEE > registration ID (0x000C03). > > Approved by: gonzo (mentor) > > 297513 by avg: > remove emulation of VFS_HOLD and VFS_RELE from opensolaris compat > > On FreeBSD VFS_HOLD/VN_RELE were mapped to MNT_REF/MNT_REL that > manipulate mnt_ref. But the job of properly maintaining the reference > count is already automatically performed by insmntque(9) and > delmntque(9). So, in effect all ZFS vnodes referenced the corresponding > mountpoint twice. > > That was completely harmless, but we want to be very explicit about what > FreeBSD VFS APIs are used, because illumos VFS_HOLD and FreeBSD MNT_REF > provide quite different guarantees with respect to the held vfs_t / > mountpoint. On illumos VFS_HOLD is sufficient to guarantee that > vfs_t.vfs_data stays valid. On the other hand, on FreeBSD MNT_REF does > *not* provide the same guarantee about mnt_data. We have to use > vfs_busy() to get that guarantee. > > Thus, the calls to VFS_HOLD/VFS_RELE on vnode init and fini are removed. > VFS_HOLD calls are replaced with vfs_busy in the ioctl handlers. > > And because vfs_busy has a richer interface that can not be dumbed down > in all cases it's better to explicitly use it rather than trying to mask > it behind VFS_HOLD. > > This change fixes a panic that could result from a race between > zfs_umount() and zfs_ioc_rollback(). We observed a case where > zfsvfs_free() tried to destroy data that zfsvfs_teardown() was still > using. That happened because there was nothing to prevent unmounting of > a ZFS filesystem that was in between zfs_suspend_fs() and > zfs_resume_fs(). > > Reviewed by: kib, smh > MFC after: 3 weeks > Sponsored by: ClusterHQ > Differential Revision: https://reviews.freebsd.org/D2794 > > > > The end of the build log: > > Started by an SCM change > Building remotely on jenkins10a.freebsd.org (FreeBSD-10) in workspace /builds/FreeBSD_HEAD_amd64_gcc > Updating svn://svn.freebsd.org/base/head at revision '2016-04-03T09:38:08.949 +0000' > U cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c > U cddl/contrib/opensolaris/lib/libzfs/common/libzfs_sendrecv.c > U sys/compat/linux/linux_misc.c > U sys/arm/allwinner/a10_hdmi.c > U sys/cddl/compat/opensolaris/sys/vfs.h > U sys/cddl/contrib/opensolaris/uts/common/fs/gfs.c > U sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c > U sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c > At revision 297521 > > No emails were triggered. > [FreeBSD_HEAD_amd64_gcc] $ /bin/sh -xe /tmp/hudson8754098237068074298.sh > + cat > + svn revert Makefile.inc1 > + svn revert sys/boot/i386/Makefile > Reverted 'sys/boot/i386/Makefile' > + patch -f > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: sys/boot/i386/Makefile > |=================================================================== > |--- sys/boot/i386/Makefile (revision 280912) > |+++ sys/boot/i386/Makefile (working copy) > -------------------------- > Patching file sys/boot/i386/Makefile using Plan A... > Hunk #1 succeeded at 16 (offset 4 lines). > Hmm... Ignoring the trailing garbage. > done > + /vm/freebsd-ci/scripts/build/cross-build.sh > + [ -z /builds/FreeBSD_HEAD_amd64_gcc ] > + [ -z amd64 ] > + export MAKEOBJDIRPREFIX=/builds/FreeBSD_HEAD_amd64_gcc/obj > + mkdir -p /builds/FreeBSD_HEAD_amd64_gcc/obj > + echo -e 'NO_WERROR=yes > WERROR= > WITH_FAST_DEPEND=yes' > + cat > + set +x > -------------------------------------------------------------- >>>> /builds/FreeBSD_HEAD_amd64_gcc/make.conf contains: > + cat /builds/FreeBSD_HEAD_amd64_gcc/make.conf > # Put make.conf entries here > NO_WERROR=yes > WERROR= > WITH_FAST_DEPEND=yes > + set +x > -------------------------------------------------------------- > + sudo pkg install -y devel/amd64-xtoolchain-gcc > Updating FreeBSD repository catalogue... > Fetching meta.txz: . done > Fetching packagesite.txz: .......... done > Processing entries: .......... done > FreeBSD repository update completed. 25093 packages processed. > New version of pkg detected; it needs to be installed first. > The following 1 package(s) will be affected (of 0 checked): > > Installed packages to be UPGRADED: > pkg: 1.6.4_1 -> 1.7.1 > > The process will require 84 KiB more space. > 2 MiB to be downloaded. > Fetching pkg-1.7.1.txz: .......... done > Checking integrity... done (0 conflicting) > [1/1] Upgrading pkg from 1.6.4_1 to 1.7.1... > [1/1] Extracting pkg-1.7.1: .......... done > Updating FreeBSD repository catalogue... > Repo "FreeBSD" upgrade schema 2012 to 2013: Add vital field > FreeBSD repository is up-to-date. > All repositories are up-to-date. > Build step 'Execute shell' marked build as failure > [WARNINGS] Skipping publisher since build result is FAILURE > IRC notifier plugin: Sending notification to: #freebsd-commits > Email was triggered for: Failure - Any > Sending email for trigger: Failure - Any > -- Andriy Gapon From owner-freebsd-current@freebsd.org Sun Apr 3 17:59:15 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 11DD5B01C0A for ; Sun, 3 Apr 2016 17:59:15 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CBED31135; Sun, 3 Apr 2016 17:59:14 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::b12f:3116:8e02:ad8a] (unknown [IPv6:2001:7b8:3a7:0:b12f:3116:8e02:ad8a]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 2E2742A806; Sun, 3 Apr 2016 19:59:13 +0200 (CEST) Subject: Re: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_8840EF3F-9FC1-4476-9FDB-C1E50702A493"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 (ebbf3ef) From: Dimitry Andric In-Reply-To: <57015089.4010700@FreeBSD.org> Date: Sun, 3 Apr 2016 19:59:04 +0200 Cc: freebsd-current@FreeBSD.org, Baptiste Daroussin Message-Id: <19A774FF-773C-4F29-8DF1-E72BBED81DA9@FreeBSD.org> References: <2034599654.182.1459676383628.JavaMail.jenkins@jenkins-9.freebsd.org> <57015089.4010700@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 03 Apr 2016 17:59:15 -0000 --Apple-Mail=_8840EF3F-9FC1-4476-9FDB-C1E50702A493 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 03 Apr 2016, at 19:19, Andriy Gapon wrote: > On 03/04/2016 12:39, jenkins-admin@FreeBSD.org wrote: >> FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure: >>=20 >> Build information: = https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1144/ >> Full change log: = https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1144/changes >> Full build log: = https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1144/console >>=20 >=20 > I wasn't able to understand what was the failure here... The step to install the amd64-xtoolchain-gcc package failed, apparently = because it decided to auto-upgrade pkg first, without actually = installing the package that was asked for: + sudo pkg install -y devel/amd64-xtoolchain-gcc Updating FreeBSD repository catalogue... Fetching meta.txz: . done Fetching packagesite.txz: .......... done Processing entries: .......... done FreeBSD repository update completed. 25093 packages processed. New version of pkg detected; it needs to be installed first. The following 1 package(s) will be affected (of 0 checked): Installed packages to be UPGRADED: pkg: 1.6.4_1 -> 1.7.1 The process will require 84 KiB more space. 2 MiB to be downloaded. Fetching pkg-1.7.1.txz: .......... done Checking integrity... done (0 conflicting) [1/1] Upgrading pkg from 1.6.4_1 to 1.7.1... [1/1] Extracting pkg-1.7.1: .......... done Updating FreeBSD repository catalogue... Repo "FreeBSD" upgrade schema 2012 to 2013: Add vital field FreeBSD repository is up-to-date. All repositories are up-to-date. Build step 'Execute shell' marked build as failure I'd consider this a bug in pkg? Is it suppose to return a failure code = in this case? -Dimitry --Apple-Mail=_8840EF3F-9FC1-4476-9FDB-C1E50702A493 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.29 iEYEARECAAYFAlcBWfAACgkQsF6jCi4glqNv9QCg8P1lGr7+Xv/eUg5Ah+L0GCmV xbsAnj6mLnYgEn605Rr0/TNTi/FvujHF =kbN2 -----END PGP SIGNATURE----- --Apple-Mail=_8840EF3F-9FC1-4476-9FDB-C1E50702A493-- From owner-freebsd-current@freebsd.org Sun Apr 3 19:06: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 B7827B01278 for ; Sun, 3 Apr 2016 19:06:28 +0000 (UTC) (envelope-from bergerkos@yahoo.co.uk) Received: from nm6-vm3.bullet.mail.ir2.yahoo.com (nm6-vm3.bullet.mail.ir2.yahoo.com [212.82.96.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 229831E27 for ; Sun, 3 Apr 2016 19:06:27 +0000 (UTC) (envelope-from bergerkos@yahoo.co.uk) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1459710187; bh=7ObhEBaXgtte6/h4/px1nP0mdJ1q+n0D6+qoLCAz4Q8=; h=Date:From:Reply-To:To:Subject:References:From:Subject; b=eEvSgz67eLqly8LfRaDfN9hlDs8KoWo4lrK2hCRkrXeV+qCpQzq3FmVucH4cbbakW9rLRpp0yxiduHNaqUJ8X9JkttzNy8CB9i8UysbicCmaaBFJKIR2alOwSVZDtYTF7PE/SkpYCaRRj22BmWPuiqMPL/2K2FDnp70ALCMLlezlH6i7ia9AAxX6WHtTTGBzJLm+xZZG4V0P61nCcRIcDAsRT84KcCofuzeAA4gl0/fPRRcX2T9wVHopwj66aPsXFDJMpB5wDh1f7vlS6/g5xk4rS2Bcay+rCSmYnwBMmPn3GVjS1AaGOEGNLeOOhsF5IfNOjDZ9nJ4JHWqT+woRdA== Received: from [212.82.98.61] by nm6.bullet.mail.ir2.yahoo.com with NNFMP; 03 Apr 2016 19:03:07 -0000 Received: from [212.82.98.98] by tm14.bullet.mail.ir2.yahoo.com with NNFMP; 03 Apr 2016 19:03:07 -0000 Received: from [127.0.0.1] by omp1035.mail.ir2.yahoo.com with NNFMP; 03 Apr 2016 19:03:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 825302.68986.bm@omp1035.mail.ir2.yahoo.com Received: by 212.82.98.117; Sun, 03 Apr 2016 19:03:07 +0000 Date: Sun, 3 Apr 2016 19:03:06 +0000 (UTC) From: Kostya Berger Reply-To: "bergerkos@yahoo.co.uk" To: FreeBSD Current Message-ID: <1745275267.3130243.1459710186387.JavaMail.yahoo@mail.yahoo.com> Subject: error running context: operation timed out MIME-Version: 1.0 References: <1745275267.3130243.1459710186387.JavaMail.yahoo.ref@mail.yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 03 Apr 2016 19:06:28 -0000 Cannot download svn sources, times out. Even tried svn.freebsd.org with the same result. Sent from Yahoo Mail on Android From owner-freebsd-current@freebsd.org Sun Apr 3 20:15:38 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 2B2FDB01B75 for ; Sun, 3 Apr 2016 20:15:38 +0000 (UTC) (envelope-from bergerkos@yahoo.co.uk) Received: from nm19-vm9.bullet.mail.ir2.yahoo.com (nm19-vm9.bullet.mail.ir2.yahoo.com [212.82.96.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 88FF4105E for ; Sun, 3 Apr 2016 20:15:37 +0000 (UTC) (envelope-from bergerkos@yahoo.co.uk) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1459714351; bh=GNccZImUHjjUO8cw+NIb5D3wr+EPXC3ta5oysmp6ovM=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=RDDcU9LJUYA/dKb0B8fIWlAQIJu9HNKTc3sqXlTKDJIOxibo4hld1iRYnPf6331wHYWAjfWJAavVJ4db+DEUYbsrqcgLxF51myBAYpWp9KJJluZMLp0PdSxP4O/IH1DLWep8ZbIxgaFLRucXzP7nK0QrlFWg/5ygCJbCGN2G+hQKRzMWitJJomJRf0/4KbzQfDDqvUgqhmJr5CqJidpZ5B9q3l9XgcEIZRc2/T7AMIcEdZgpzLp+5BS4sCWeAh3p6tmXOd4dj+6EHeN+3v9UK036KCU/J7dn8u6ITdAPYzXJwpVYEy+CPL1oen0aEuaDudPizIXpflTp/qrnouBytw== Received: from [212.82.98.59] by nm19.bullet.mail.ir2.yahoo.com with NNFMP; 03 Apr 2016 20:12:31 -0000 Received: from [212.82.98.94] by tm12.bullet.mail.ir2.yahoo.com with NNFMP; 03 Apr 2016 20:12:31 -0000 Received: from [127.0.0.1] by omp1031.mail.ir2.yahoo.com with NNFMP; 03 Apr 2016 20:12:31 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 658464.86130.bm@omp1031.mail.ir2.yahoo.com Received: by 217.12.9.14; Sun, 03 Apr 2016 20:12:31 +0000 Date: Sun, 3 Apr 2016 20:12:30 +0000 (UTC) From: Kostya Berger Reply-To: "bergerkos@yahoo.co.uk" To: FreeBSD Current Message-ID: <123095204.3187192.1459714350679.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <1745275267.3130243.1459710186387.JavaMail.yahoo@mail.yahoo.com> References: <1745275267.3130243.1459710186387.JavaMail.yahoo.ref@mail.yahoo.com> <1745275267.3130243.1459710186387.JavaMail.yahoo@mail.yahoo.com> Subject: Re: error running context: operation timed out MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 03 Apr 2016 20:15:38 -0000 Ok, seems to be working now :) Sent from Yahoo Mail on Android On Sun, Apr 3, 2016 at 22:03, Kostya Berger wrote: Cannot download svn sources, times out. Even tried svn.freebsd.org with the same result. Sent from Yahoo Mail on Android From owner-freebsd-current@freebsd.org Sun Apr 3 20:41:48 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 50747B006A4 for ; Sun, 3 Apr 2016 20:41:48 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 170DA1F8B; Sun, 3 Apr 2016 20:41:48 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: by mail-oi0-x234.google.com with SMTP id y204so27020529oie.3; Sun, 03 Apr 2016 13:41:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=vgU44opXFuy81q2Xzkl6yiQRmJY/wFY3Xqwf1ZoRH/I=; b=y0maJ1AMwfw1HELKkJ1UWt6yyG8mQoWfh8J3wztdNZlDibKS46MM0UX/9ru1vXwIz2 NaJBFDkj7jdrh/rGsGoWQui1D39VGe1IC0eNSf1R51H02ekDatxntD4n5mZ4hNHLx0qR 16V1ZufoJxMSAArBz+oXHPO1jzgkZGJLGy5mIoWtyjD8MbWVdGhOh30eMDNzBiPUAHXR gbq8MuFhNw8n8zoLXfUXsMIMhumkCRQNajm/XntLE8UMtbnA7tR6bQoFDB+VPhDP5vp8 BzC/uFEJRli4HC74Ca3ZobXEDizxceXNEMpYUJN5fF3rdFie3wiGCLQ1ajpDk01DmfKY 6Uuw== 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:date :message-id:subject:from:to:cc; bh=vgU44opXFuy81q2Xzkl6yiQRmJY/wFY3Xqwf1ZoRH/I=; b=KbvGWalHaWJd+8910LPbQj1lUvQXFyQlfBwKfVBnfLXiunNK6GXx2ccoDZ4CYxJREQ YjyM+ED0b+CRdpEy04XgM1Gfh0js+gg/LZwL65w+wXeQOW3bxOlWMnu7gw00cJzO867O uDcr9G2Oi/WUe0isdSKUr0CeeEdYF5Jf8/n2FOgpt5EBorbTGoid1bb4Oj758R+45Vlr P7GQ1CfVabDhQ5Wdy4UA+vhdlZt4Ms977ypSxCqdyFSL/y/+9KjllEKrgi6YeYH97qJW aDT+hA+FBcEsXcOqVX71ijzhmnV9VoeCf3zdS9VqACIhDneKAmCXwMhkDOwfhfzcryTg gzWA== X-Gm-Message-State: AD7BkJIuNm5Iywm1sQwlRF5gCSrElJuCwgxGBHkkVaLPkPr7AQdtWhayzgf0fHwg13O45Z0Vq7RJWDUXIZN7Tg== MIME-Version: 1.0 X-Received: by 10.157.2.65 with SMTP id 59mr7921061otb.140.1459716107321; Sun, 03 Apr 2016 13:41:47 -0700 (PDT) Sender: lwhsu.freebsd@gmail.com Received: by 10.202.218.87 with HTTP; Sun, 3 Apr 2016 13:41:47 -0700 (PDT) In-Reply-To: <19A774FF-773C-4F29-8DF1-E72BBED81DA9@FreeBSD.org> References: <2034599654.182.1459676383628.JavaMail.jenkins@jenkins-9.freebsd.org> <57015089.4010700@FreeBSD.org> <19A774FF-773C-4F29-8DF1-E72BBED81DA9@FreeBSD.org> Date: Mon, 4 Apr 2016 04:41:47 +0800 X-Google-Sender-Auth: RdQ98bb2KAdk4bLo2KdgYxYy0os Message-ID: Subject: Re: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure From: Li-Wen Hsu To: Dimitry Andric Cc: Andriy Gapon , freebsd-current@freebsd.org, Baptiste Daroussin Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 03 Apr 2016 20:41:48 -0000 On Mon, Apr 4, 2016 at 1:59 AM, Dimitry Andric wrote: > On 03 Apr 2016, at 19:19, Andriy Gapon wrote: >> On 03/04/2016 12:39, jenkins-admin@FreeBSD.org wrote: >>> FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure: >>> >>> Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1144/ >>> Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1144/changes >>> Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1144/console >>> >> >> I wasn't able to understand what was the failure here... > > The step to install the amd64-xtoolchain-gcc package failed, apparently because it decided to auto-upgrade pkg first, without actually installing the package that was asked for: > > + sudo pkg install -y devel/amd64-xtoolchain-gcc > Updating FreeBSD repository catalogue... > Fetching meta.txz: . done > Fetching packagesite.txz: .......... done > Processing entries: .......... done > FreeBSD repository update completed. 25093 packages processed. > New version of pkg detected; it needs to be installed first. > The following 1 package(s) will be affected (of 0 checked): > > Installed packages to be UPGRADED: > pkg: 1.6.4_1 -> 1.7.1 > > The process will require 84 KiB more space. > 2 MiB to be downloaded. > Fetching pkg-1.7.1.txz: .......... done > Checking integrity... done (0 conflicting) > [1/1] Upgrading pkg from 1.6.4_1 to 1.7.1... > [1/1] Extracting pkg-1.7.1: .......... done > Updating FreeBSD repository catalogue... > Repo "FreeBSD" upgrade schema 2012 to 2013: Add vital field > FreeBSD repository is up-to-date. > All repositories are up-to-date. > Build step 'Execute shell' marked build as failure > > I'd consider this a bug in pkg? Is it suppose to return a failure code in this case? I've checked this a little more, I found the return code of "installing a installed package" has been changed. For pkg 1.6.4_1, it returns 0, but 1.7.1 returns 70, thus jenkins consider the build script execution failure. Li-Wen -- Li-Wen Hsu https://lwhsu.org From owner-freebsd-current@freebsd.org Sun Apr 3 22:50: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 9EAAEB0206A for ; Sun, 3 Apr 2016 22:50:20 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 3B805165E; Sun, 3 Apr 2016 22:50:20 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by mail-lf0-x22c.google.com with SMTP id g184so69954793lfb.3; Sun, 03 Apr 2016 15:50:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=7YgPRbPiUHs49/uKCVxZceFBleQb7jrW2T0g5BZVpEw=; b=ilcXGEI5H8aSET9CLqsNQFDyCwkOb+S8k6JrgTTMLEwcw5FZHcNVDCWjij7wCwncfZ LU0udV2cIhp9ZMssZ0uR8Jrkn8EKTzqZ+QotYUUo7+aCnZWNoeKB2uSQ/fMcKnnEFw0e z+uU1+c33smwtYA/RRv46AYfjVkfa+dU5FS2r1t7V05zGtanf7+/L6BU1dcwiwg4Mdol s3tqwyq39ItXGJ7L85VR6AcGhi3XwpYDqVkLl9jj+0sgEKIkd46Hf0mDujCt4C3WL80L rKOehQvJ/xqsvg5Pmf+ZP6ziq9vZasTYAK9a+AZi0o+2tfmPlKIP1cawA/KtaglM7UsH C91g== 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 :references:mime-version:content-disposition:in-reply-to:user-agent; bh=7YgPRbPiUHs49/uKCVxZceFBleQb7jrW2T0g5BZVpEw=; b=eL11C63OZj5oBspoRK8ZCnyq2oeClei4l+qYTHxYnfp+aOju5FprhWw5V6g4dXbswr rfuR9ITTzL2ryNPEyOOECBLynA1KfmsMqjNaWhopkADZSDfGn67euQAFU2ik8MJPQajy LPKokU51FMA+h6eDLv0K7Z8ZUMocsQRSYPQ4dvFzraDCacRhNBoALh0PwKgF90KZWOpZ wIR0CdK2u2G/9aNk9Vu05poVNwkPEXsUi0K+9Mfad6N+KF6Ht0b92aHg6Srdh4o17F5i MWcLbegB7vzjxEo81Npc3ksYNMeIajMAeDbEpsciYNfYwh2MZKnjoaJ30qLYr+ae49cU FQHw== X-Gm-Message-State: AD7BkJJHqV7/RJQxEbE6201KZgRi6ZhXsQLD3lVRoEBazzEHZM3wBAyhKceJuUPEbU3m1Q== X-Received: by 10.194.21.102 with SMTP id u6mr2126624wje.124.1459723817447; Sun, 03 Apr 2016 15:50:17 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by smtp.gmail.com with ESMTPSA id z6sm10796086wme.9.2016.04.03.15.50.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 Apr 2016 15:50:16 -0700 (PDT) Sender: Baptiste Daroussin Date: Mon, 4 Apr 2016 00:50:14 +0200 From: Baptiste Daroussin To: Li-Wen Hsu Cc: Dimitry Andric , Andriy Gapon , freebsd-current@freebsd.org Subject: Re: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure Message-ID: <20160403225014.GH5214@ivaldir.etoilebsd.net> References: <2034599654.182.1459676383628.JavaMail.jenkins@jenkins-9.freebsd.org> <57015089.4010700@FreeBSD.org> <19A774FF-773C-4F29-8DF1-E72BBED81DA9@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="aF3LVLvitz/VQU3c" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 03 Apr 2016 22:50:20 -0000 --aF3LVLvitz/VQU3c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 04, 2016 at 04:41:47AM +0800, Li-Wen Hsu wrote: > On Mon, Apr 4, 2016 at 1:59 AM, Dimitry Andric wrote: > > On 03 Apr 2016, at 19:19, Andriy Gapon wrote: > >> On 03/04/2016 12:39, jenkins-admin@FreeBSD.org wrote: > >>> FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure: > >>> > >>> Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64= _gcc/1144/ > >>> Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_g= cc/1144/changes > >>> Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gc= c/1144/console > >>> > >> > >> I wasn't able to understand what was the failure here... > > > > The step to install the amd64-xtoolchain-gcc package failed, apparently= because it decided to auto-upgrade pkg first, without actually installing = the package that was asked for: > > > > + sudo pkg install -y devel/amd64-xtoolchain-gcc > > Updating FreeBSD repository catalogue... > > Fetching meta.txz: . done > > Fetching packagesite.txz: .......... done > > Processing entries: .......... done > > FreeBSD repository update completed. 25093 packages processed. > > New version of pkg detected; it needs to be installed first. > > The following 1 package(s) will be affected (of 0 checked): > > > > Installed packages to be UPGRADED: > > pkg: 1.6.4_1 -> 1.7.1 > > > > The process will require 84 KiB more space. > > 2 MiB to be downloaded. > > Fetching pkg-1.7.1.txz: .......... done > > Checking integrity... done (0 conflicting) > > [1/1] Upgrading pkg from 1.6.4_1 to 1.7.1... > > [1/1] Extracting pkg-1.7.1: .......... done > > Updating FreeBSD repository catalogue... > > Repo "FreeBSD" upgrade schema 2012 to 2013: Add vital field > > FreeBSD repository is up-to-date. > > All repositories are up-to-date. > > Build step 'Execute shell' marked build as failure > > > > I'd consider this a bug in pkg? Is it suppose to return a failure code= in this case? >=20 > I've checked this a little more, I found the return code of > "installing a installed package" has been changed. >=20 > For pkg 1.6.4_1, it returns 0, but 1.7.1 returns 70, thus jenkins > consider the build script execution failure. >=20 >=20 It shoudl not return 70 if it returns 70 then there is a bug I can fix, I n= eed to know more about what is failing to be able to fix Best regards, Bapt --aF3LVLvitz/VQU3c Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXAZ4mAAoJEGOJi9zxtz5a+k0QAMfz8XXypOuj7HeO2Myz2qDz sglJkOsDcfkFn1d5dTt4OE1vHVDD59N3E4bG3X3wvY9s3BlvhPqO60N2PG+LA7+N TZWNvm5unU7W+z2EpRJqPlwgmotGHnaEG4ysXmeVLL11uhGviNIKGr0XPi2M8drN NaoJbPadHc5S1+/1m6SDXNI3nvRWHvtUT6DMHe+PrR5tdefVRN1ipN5gTClWUbXj PZS51eZJzH+AY9+hwbmBPjhYwIQekFELN9uFe/3e6AP6FJ/TGEFDLtYqMj5FKVD/ kfvXV85gDy5L+RIT63kWsVBGUdmg2tSRdyyKhYpe0VJpV9TjEqfcutp72P90en1q AyRfA7uI3v9bw7AsjnnrACs2r2NuSnFsX9VstwWj6/owIa+qdE81hMewkFBdQMlT x10MS/62ZF2Niju4glZd3O97FBK6qD7nGG8BLbEfbNBbS/YYRYLKHaASCSP1PZ9P gbJOWOwz+tXWYgyKd93ESnLXkniZvZO5RfS1HSI8CweAgYCGiGWZUFxaQZqwbpWZ 2bYXHoHJe+fCkv08aOBg+QOauGmjm7l2N7rf7lURVepOsicaKRKjbaQIjVINhASZ quZCYg9UaJmUNJv1FJmii/3VqS62VSPvPHzVwF3u+Ga8ipugvXn6oMTpWadBmlWm rSXpi+N8NcmmoJVZ5FyU =x+Hg -----END PGP SIGNATURE----- --aF3LVLvitz/VQU3c-- From owner-freebsd-current@freebsd.org Mon Apr 4 10:39: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 5D178B02A33 for ; Mon, 4 Apr 2016 10:39:02 +0000 (UTC) (envelope-from lwhsu@FreeBSD.cs.nctu.edu.tw) Received: from FreeBSD.cs.nctu.edu.tw (freebsd2.cs.nctu.edu.tw [140.113.17.206]) by mx1.freebsd.org (Postfix) with ESMTP id 281B71157; Mon, 4 Apr 2016 10:39:01 +0000 (UTC) (envelope-from lwhsu@FreeBSD.cs.nctu.edu.tw) Received: by FreeBSD.cs.nctu.edu.tw (Postfix, from userid 1058) id 20D262E5B; Mon, 4 Apr 2016 18:39:00 +0800 (CST) Date: Mon, 4 Apr 2016 18:39:00 +0800 From: Li-Wen Hsu To: Baptiste Daroussin Cc: Dimitry Andric , Andriy Gapon , freebsd-current@freebsd.org Subject: Re: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure Message-ID: <20160404103859.GA27648@FreeBSD.cs.nctu.edu.tw> References: <2034599654.182.1459676383628.JavaMail.jenkins@jenkins-9.freebsd.org> <57015089.4010700@FreeBSD.org> <19A774FF-773C-4F29-8DF1-E72BBED81DA9@FreeBSD.org> <20160403225014.GH5214@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline In-Reply-To: <20160403225014.GH5214@ivaldir.etoilebsd.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 04 Apr 2016 10:39:02 -0000 --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 04, 2016 at 00:50:14 +0200, Baptiste Daroussin wrote: > On Mon, Apr 04, 2016 at 04:41:47AM +0800, Li-Wen Hsu wrote: > > I've checked this a little more, I found the return code of > > "installing a installed package" has been changed. > >=20 > > For pkg 1.6.4_1, it returns 0, but 1.7.1 returns 70, thus jenkins > > consider the build script execution failure. > >=20 > >=20 > It shoudl not return 70 if it returns 70 then there is a bug I can fix, I= need > to know more about what is failing to be able to fix What else information do you need? My experiment is as following: On a machine uses quarterly branch, where pkg is 1.6.4_1, install a installed package. I choose rsync here, then echo $?, it returns 0. And I switch to latest branch, also use `pkg install -y rsync`, but this time $? is 70. Jenkins "Execute shell" build step checks return value of each command in the shell script, if it is non-zero, it aborts the build and considers if failure. Regards, Li-Wen --=20 Li-Wen Hsu https://lwhsu.org --qDbXVdCdHGoSgWSk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJXAkRCXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMDdENTNGNjUyMTUzMzVCNzA5NDNGODQ2 NzI3RTc3Qzg4NjJCNjU2AAoJEGcn53yIYrZWk/EP/AjfamxifqeCB+dnVkRSh1La sBVYHP2rFvoBofPsLOw4WsrxfvCV44xf151Fmr7vzVl/B1rn9viidmStARSbZ9M7 cUaNvIZn9C295t0kTtVGQJ9hBKDzifcbzQ7jF4WZ8lnqwkFmxOov/BefBXFci2Ui bXzrFv3KGY+24e+ywbw8hmDSfnVIhv40r7VPp6pQ6Bii5JhnwzDQPZ2ewqfpiWGJ g5GSXyFhI9TBmeUWFtZRyyqkOuuUmGFsoR1LT+f4yulwGSqrwalsiQtnhDPTHYac MmszOdi6sjpvURNt3xfyf8Ifzl9Rf0uoG94GOxP89QpS4RD3O8UXCUpRpdMbPw86 Xkpghq7tY+G2Y4I40bB+Wsg6sc0bOXSVl1FuF0A5NssvnW5fmPXPn0gH5HQmU8C+ 7Si/Bn9oXsEwgi65pETay5sZU5037XyMlFfVGzTTkNe6O/FY7Mo9j4YtHTVwphR4 42Zta9BW2GDZxp5oglX5nJzq7IlUyVhSPr+MHaZpp4y/Og/8eJ+fU5DEnJUgn7FU Q9bVE9z8NZ8ZuX03LSo7yZHJ6ifyl2H648/nJztI/l4TVc/fszswWFo2wWLquvXw kvf1kNrUu1J+6BuaQOOkgqH+Qc5Qwms0I2p8Laus3KuEntT4c2SvxG2O6HbNJ5J8 DVaw0WmU8qwf60uH7bNy =LlpN -----END PGP SIGNATURE----- --qDbXVdCdHGoSgWSk-- From owner-freebsd-current@freebsd.org Mon Apr 4 10:53: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 7BE34B021D4 for ; Mon, 4 Apr 2016 10:53:20 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-qg0-x241.google.com (mail-qg0-x241.google.com [IPv6:2607:f8b0:400d:c04::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 324A11CED; Mon, 4 Apr 2016 10:53:20 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by mail-qg0-x241.google.com with SMTP id f105so2051185qge.3; Mon, 04 Apr 2016 03:53:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=tCn/vhX37bBSjF6r3shLgTTP6p8wGL0Isj0DEV8V6LA=; b=JS4mc2LuKtqc4qTK9YhiKN/OAAR8CPo57WXpIhMLrtQ5tMJ9jq9ICv4/CIAsqJZb/b yzF3OKfxlpRDgnl15uBeMI0oV4GQ/rdJ5O3ZIiLbQnmMIYOGvD82FNA9z64tx0Lb8uvL E/tqGeZgzKqKpN/pwjuPDoFzmDQ/bCsxq/qVzaErtJ9odXtEH3PW2IooJ08+b3B/yN2Y 3znHojypoBfD8dRbNMNPtxA++7eRiN9K8yer7gyrP7CNgUVBx8SBmjdCzW1tLxwFJfwu nC9BdBNjoLM78qibuJRV+wQm04k+CUePsWIPZ4nDfDsO5rMgXFW5PLQpNHOFdhtVa10j CyxQ== 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 :references:mime-version:content-disposition:in-reply-to:user-agent; bh=tCn/vhX37bBSjF6r3shLgTTP6p8wGL0Isj0DEV8V6LA=; b=houc0MaidpcXfWcQjuo8p8CR/e14tn7tLkWyyGfsmGf30srO1+qMCiHv8Wkd2b60v1 XKPC/nKdpOMWZBDStZx+Q4nNxb4WQzuVAGyCMP/z6CSM5ZzNxPHIF85/8aEBAghYpMdm OGs861hlTabjd0j8lO78465lxndwA/K+n+Qq59gz3s96RkBcxAGk5gRu1PbDiW1PuAEX r85CvJ+jJwU8yIBGPSlUazzQapGrFy9h7wh1+rQiQJOXa1LNrAfoFq2V4fDNx2JaAsNi EfdLmqhJ6T8SHrBcpcScfdDRd2WOl89IQqS4QasrqK3s9+sVLRKCyBMO2YdbXyeLYkkX NDkw== X-Gm-Message-State: AD7BkJIfl2G3A9dnlZKxp1iS+zvCg17vzIOniPJ3j53/TFkLoimspiDU14vTIvSchaMCgQ== X-Received: by 10.194.6.36 with SMTP id x4mr9459523wjx.122.1459767199349; Mon, 04 Apr 2016 03:53:19 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by smtp.gmail.com with ESMTPSA id m13sm13281358wma.3.2016.04.04.03.53.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Apr 2016 03:53:18 -0700 (PDT) Sender: Baptiste Daroussin Date: Mon, 4 Apr 2016 12:53:16 +0200 From: Baptiste Daroussin To: Li-Wen Hsu Cc: Dimitry Andric , Andriy Gapon , freebsd-current@freebsd.org Subject: Re: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure Message-ID: <20160404105316.GA49864@ivaldir.etoilebsd.net> References: <2034599654.182.1459676383628.JavaMail.jenkins@jenkins-9.freebsd.org> <57015089.4010700@FreeBSD.org> <19A774FF-773C-4F29-8DF1-E72BBED81DA9@FreeBSD.org> <20160403225014.GH5214@ivaldir.etoilebsd.net> <20160404103859.GA27648@FreeBSD.cs.nctu.edu.tw> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pf9I7BMVVzbSWLtt" Content-Disposition: inline In-Reply-To: <20160404103859.GA27648@FreeBSD.cs.nctu.edu.tw> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 04 Apr 2016 10:53:20 -0000 --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 04, 2016 at 06:39:00PM +0800, Li-Wen Hsu wrote: > On Mon, Apr 04, 2016 at 00:50:14 +0200, Baptiste Daroussin wrote: > > On Mon, Apr 04, 2016 at 04:41:47AM +0800, Li-Wen Hsu wrote: > > > I've checked this a little more, I found the return code of > > > "installing a installed package" has been changed. > > >=20 > > > For pkg 1.6.4_1, it returns 0, but 1.7.1 returns 70, thus jenkins > > > consider the build script execution failure. > > >=20 > > >=20 > > It shoudl not return 70 if it returns 70 then there is a bug I can fix,= I need > > to know more about what is failing to be able to fix >=20 > What else information do you need? My experiment is as following: >=20 > On a machine uses quarterly branch, where pkg is 1.6.4_1, install a > installed package. I choose rsync here, then echo $?, it returns 0. >=20 > And I switch to latest branch, also use `pkg install -y rsync`, but this > time $? is 70. >=20 > Jenkins "Execute shell" build step checks return value of each command > in the shell script, if it is non-zero, it aborts the build and > considers if failure. Return 70 means an error occured. if I look at the log I can see that powerpc64-gcc is not installed for sure, hence the error 70 What is strange it that no "error message is shown" Best regards, Bapt --pf9I7BMVVzbSWLtt Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXAkecAAoJEGOJi9zxtz5aXVQP/05LXNnzsRwMyGIGOEhBUwgZ QMjFzrEkPo+ovYvRMQsQ+OOYLGDGsLCFEy+IWBeT63+q9kCFHhshoesumlCmuXGj i07afwgc12AJeY2eKtd0oS7ZAVAzFhUkm3nVXXOTZwNIjk/iSVsCTnZt1o/qtjdz 0VHuzDsEhACEEvR+MOHN+TC6TON1WwaY+n5f002EQazYamvIvCE6XmZ2uhPlmmZd 83W/8RgOVnHSyziIWeJmhNlVfMesCHKbd9PU8jwaCMFJsNcAXP6rvcl4OEM07dDO zwLzy0DlNgmNQ+bK5gWPZ9nszChsL3fZVGP2BUqTeOlC8Kzo01v3dZErhs9vk+e+ dssn2qLeXs7dns+ZvjYWW/EOf5/1aDN+ASIiKSfdCgvDysPCmnW08U76yskcFJVN Q8WEReqZ2uy6xywvld7BOqmCBtTfbLTxOaSmKx1kQq9y2MyYfYXRICBr1y63C2Qv 0+iO9osTjb3N+2diqF8GUIxKQvct7qf7739U/sDiS4Oh0RO23ZfYqbnrHSampa95 JzlhOXoyXMHu5JPU/81pvuS0aACeQWs3hOJtI0W8Hj/GILEOF0VGzrSZfq5exjNz v9YkNmgtsrpb/9sBbltpXDjiacH2nYo/zCAkwQpT3E8Y99m9dhKHjiYuNcXinKrY hAIBAQ3OOvtVwWy/c+54 =nGu/ -----END PGP SIGNATURE----- --pf9I7BMVVzbSWLtt-- From owner-freebsd-current@freebsd.org Mon Apr 4 12:25: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 CCFEBB022E8 for ; Mon, 4 Apr 2016 12:25:42 +0000 (UTC) (envelope-from lwhsu@FreeBSD.cs.nctu.edu.tw) Received: from FreeBSD.cs.nctu.edu.tw (freebsd2.cs.nctu.edu.tw [140.113.17.206]) by mx1.freebsd.org (Postfix) with ESMTP id 6A4E81A53; Mon, 4 Apr 2016 12:25:42 +0000 (UTC) (envelope-from lwhsu@FreeBSD.cs.nctu.edu.tw) Received: by FreeBSD.cs.nctu.edu.tw (Postfix, from userid 1058) id DACAB2F3B; Mon, 4 Apr 2016 20:25:39 +0800 (CST) Date: Mon, 4 Apr 2016 20:25:39 +0800 From: Li-Wen Hsu To: Baptiste Daroussin Cc: Dimitry Andric , Andriy Gapon , freebsd-current@freebsd.org Subject: Re: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure Message-ID: <20160404122539.GA14905@FreeBSD.cs.nctu.edu.tw> References: <2034599654.182.1459676383628.JavaMail.jenkins@jenkins-9.freebsd.org> <57015089.4010700@FreeBSD.org> <19A774FF-773C-4F29-8DF1-E72BBED81DA9@FreeBSD.org> <20160403225014.GH5214@ivaldir.etoilebsd.net> <20160404103859.GA27648@FreeBSD.cs.nctu.edu.tw> <20160404105316.GA49864@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gKMricLos+KVdGMg" Content-Disposition: inline In-Reply-To: <20160404105316.GA49864@ivaldir.etoilebsd.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 04 Apr 2016 12:25:42 -0000 --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 04, 2016 at 12:53:16 +0200, Baptiste Daroussin wrote: > On Mon, Apr 04, 2016 at 06:39:00PM +0800, Li-Wen Hsu wrote: > > On Mon, Apr 04, 2016 at 00:50:14 +0200, Baptiste Daroussin wrote: > > > On Mon, Apr 04, 2016 at 04:41:47AM +0800, Li-Wen Hsu wrote: > > > > I've checked this a little more, I found the return code of > > > > "installing a installed package" has been changed. > > > >=20 > > > > For pkg 1.6.4_1, it returns 0, but 1.7.1 returns 70, thus jenkins > > > > consider the build script execution failure. > > > >=20 > > > >=20 > > > It shoudl not return 70 if it returns 70 then there is a bug I can fi= x, I need > > > to know more about what is failing to be able to fix > >=20 > > What else information do you need? My experiment is as following: > >=20 > > On a machine uses quarterly branch, where pkg is 1.6.4_1, install a > > installed package. I choose rsync here, then echo $?, it returns 0. > >=20 > > And I switch to latest branch, also use `pkg install -y rsync`, but this > > time $? is 70. > >=20 > > Jenkins "Execute shell" build step checks return value of each command > > in the shell script, if it is non-zero, it aborts the build and > > considers if failure. >=20 > Return 70 means an error occured. if I look at the log I can see that > powerpc64-gcc is not installed for sure, hence the error 70 >=20 > What is strange it that no "error message is shown" Very strange, no further error message is shown, even -d provided. root@jenkins10a:~ # pkg -d install -y devel/amd64-xtoolchain-gcc DBG(1)[44393]> pkg initialized Updating FreeBSD repository catalogue... DBG(1)[44393]> PkgRepo: verifying update for FreeBSD DBG(1)[44393]> Pkgrepo, begin update of '/var/db/pkg/repo-FreeBSD.sqlite' DBG(1)[44393]> Fetch: fetching from: http://pkgmir.pkg.freebsd.org/FreeBSD:= 10:amd64/latest/meta.txz with opts "i" DBG(1)[44393]> Fetch: fetching from: http://pkgmir.pkg.freebsd.org/FreeBSD:= 10:amd64/latest/packagesite.txz with opts "i" FreeBSD repository is up-to-date. All repositories are up-to-date. DBG(1)[44393]> want to get an advisory lock on a database DBG(1)[44393]> release an advisory lock on a database root@jenkins10a:~ # echo $? 70 Is there anything I can help on debugging this? Li-Wen --=20 Li-Wen Hsu https://lwhsu.org --gKMricLos+KVdGMg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJXAl1CXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMDdENTNGNjUyMTUzMzVCNzA5NDNGODQ2 NzI3RTc3Qzg4NjJCNjU2AAoJEGcn53yIYrZWdOUP/R7Ydos+uJcR4roBFtqx1aAj zthZOaDp9gQ0cQFrjmIkZJbCfKPAupDnJ4mPdhaI+RfS+1Mvk0o0J37QfuwbgbYi F0NF+TxDDX2QjdgFlPFvFeakgJ5bX2C5pIh+DcHLimjwD1Tq2FpH+i1Kcvm7Q0uw OxCR1sP2Cqw0RNq+d4exHjB0R9oJoEzzwGUKiw0DlBXwdSgnbzDrvcChw53pro+f 10HLLqxMbC2wa49vPA+kvRpaz0BojcVhN53zc06VGv1vZ5P8umluvblZbN2/NX6M 61uEKxlQ4ahFSW+rM3kTvPOWARAmm7Ju76KZ4Nd20TMihOgoHtx/SaN5tMs0M8KZ oPtwrtw5PoKyBS6TMf1DHP6SuNHm2gZARTewchq/A5USiv/DejvjmtuAOmx5nN24 6nQ0GcRYlhmgBombpBzeYsE6p6mj2R01cNTYVa6d6MHPmWvvtc2hdzzX4zGysAgJ rTCglSrAfiNI5kw3I4Uk/lkZihhK7Ph2Q610IQUVsH9INpGtzZUO0/qjaJcUw7wC YKH5PyakyLcg1EFVPcaf/7hJG5NXWzDN6c6G1fHVRy/O8Zb5cDk5S8s4n9f2qGyS x/kLtgn4aGlLxZ/680SfumNyhNn1DSviBISt5raadry/V8yg+2I6W15IVjolZeZg 0KwBogPtdDWzmrEQg6Bx =xRAN -----END PGP SIGNATURE----- --gKMricLos+KVdGMg-- From owner-freebsd-current@freebsd.org Mon Apr 4 12:32: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 08DFFB025F6 for ; Mon, 4 Apr 2016 12:32:40 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 984551E13; Mon, 4 Apr 2016 12:32:39 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by mail-lf0-x234.google.com with SMTP id p188so141098534lfd.0; Mon, 04 Apr 2016 05:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=maT/uoMokbRkJZ2vp0p+wGhiv8en4wDN0vPcMlucjk4=; b=j47fWp7BqRqM9McMRoNQZD7B6c1+SInwxfiwU2ivAws0MInuSDyLX90n3uFNIfvP1W ge5iMYQG6mifux5pdN1CcSjfnJlFsnN1NnVSGPDpoKbhQo5TypJ5Qmipl0zOAfqCBhmR /mwuTrRVzbr0thzc5sZCo7VIue7TU6MVStI8g3fTscLWW8cj3aroM/vBVESgkcgQ/D84 cv31k+1IwGvXCcOP/iheD8D9/S5PRnnobjaoE6V6K2eHYbmqd2NihwKREJceJY8GERUZ cYdvA3zXMeFyNctvg+abpuS5Lr6esoiCbY3ttcoR+CONQaGKWGXPmAa9xhS5bBBxFAMz pzJA== 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 :references:mime-version:content-disposition:in-reply-to:user-agent; bh=maT/uoMokbRkJZ2vp0p+wGhiv8en4wDN0vPcMlucjk4=; b=dUG1oOuBmGbpc2le/ZFRkBV6lH0jFeVEv+dBI5ZQW4W3jK0k4W3QPPzlKQXmk2QQU2 dCH4ZNhpDjzDXhCHHgcWFX3TwmDTCGMddpH5EerjfCdQ/qUdSXJnSkhcotrPNSPHxQdC 0D9p4Y4tK53fKGI6rMUAlXFRobEmXL9o9jEV1ED4cUi5dXV2EmUFpTDjAK2iwGdYJjSx fCSF/hZ9m1PtchK9JMnp2aEcSTFUmnsTjdtMr/BWxpXXNG239O/m2wDI1aHvI7VpL2D8 d9dS75/5i3zTuV9PyjJY16G3u0C0nfKM7Vncw+MyDTR7lO3K9dX2PPsj9R2lSkJtlRzP ARCw== X-Gm-Message-State: AD7BkJIkzJaTFsUHSHVaoJ5UAuWCiHy2+7VokAkLGtd7yEfxvaquLDIONYlfL26Tx3ydrw== X-Received: by 10.194.116.9 with SMTP id js9mr19295784wjb.112.1459773157898; Mon, 04 Apr 2016 05:32:37 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by smtp.gmail.com with ESMTPSA id r8sm28893453wjz.34.2016.04.04.05.32.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Apr 2016 05:32:36 -0700 (PDT) Sender: Baptiste Daroussin Date: Mon, 4 Apr 2016 14:32:35 +0200 From: Baptiste Daroussin To: Li-Wen Hsu Cc: Dimitry Andric , Andriy Gapon , freebsd-current@freebsd.org Subject: Re: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure Message-ID: <20160404123234.GC49864@ivaldir.etoilebsd.net> References: <2034599654.182.1459676383628.JavaMail.jenkins@jenkins-9.freebsd.org> <57015089.4010700@FreeBSD.org> <19A774FF-773C-4F29-8DF1-E72BBED81DA9@FreeBSD.org> <20160403225014.GH5214@ivaldir.etoilebsd.net> <20160404103859.GA27648@FreeBSD.cs.nctu.edu.tw> <20160404105316.GA49864@ivaldir.etoilebsd.net> <20160404122539.GA14905@FreeBSD.cs.nctu.edu.tw> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2/5bycvrmDh4d1IB" Content-Disposition: inline In-Reply-To: <20160404122539.GA14905@FreeBSD.cs.nctu.edu.tw> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 04 Apr 2016 12:32:40 -0000 --2/5bycvrmDh4d1IB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 04, 2016 at 08:25:39PM +0800, Li-Wen Hsu wrote: > On Mon, Apr 04, 2016 at 12:53:16 +0200, Baptiste Daroussin wrote: > > On Mon, Apr 04, 2016 at 06:39:00PM +0800, Li-Wen Hsu wrote: > > > On Mon, Apr 04, 2016 at 00:50:14 +0200, Baptiste Daroussin wrote: > > > > On Mon, Apr 04, 2016 at 04:41:47AM +0800, Li-Wen Hsu wrote: > > > > > I've checked this a little more, I found the return code of > > > > > "installing a installed package" has been changed. > > > > >=20 > > > > > For pkg 1.6.4_1, it returns 0, but 1.7.1 returns 70, thus jenkins > > > > > consider the build script execution failure. > > > > >=20 > > > > >=20 > > > > It shoudl not return 70 if it returns 70 then there is a bug I can = fix, I need > > > > to know more about what is failing to be able to fix > > >=20 > > > What else information do you need? My experiment is as following: > > >=20 > > > On a machine uses quarterly branch, where pkg is 1.6.4_1, install a > > > installed package. I choose rsync here, then echo $?, it returns 0. > > >=20 > > > And I switch to latest branch, also use `pkg install -y rsync`, but t= his > > > time $? is 70. > > >=20 > > > Jenkins "Execute shell" build step checks return value of each command > > > in the shell script, if it is non-zero, it aborts the build and > > > considers if failure. > >=20 > > Return 70 means an error occured. if I look at the log I can see that > > powerpc64-gcc is not installed for sure, hence the error 70 > >=20 > > What is strange it that no "error message is shown" >=20 > Very strange, no further error message is shown, even -d provided. >=20 > root@jenkins10a:~ # pkg -d install -y devel/amd64-xtoolchain-gcc > DBG(1)[44393]> pkg initialized > Updating FreeBSD repository catalogue... > DBG(1)[44393]> PkgRepo: verifying update for FreeBSD > DBG(1)[44393]> Pkgrepo, begin update of '/var/db/pkg/repo-FreeBSD.sqlite' > DBG(1)[44393]> Fetch: fetching from: http://pkgmir.pkg.freebsd.org/FreeBS= D:10:amd64/latest/meta.txz with opts "i" > DBG(1)[44393]> Fetch: fetching from: http://pkgmir.pkg.freebsd.org/FreeBS= D:10:amd64/latest/packagesite.txz with opts "i" > FreeBSD repository is up-to-date. > All repositories are up-to-date. > DBG(1)[44393]> want to get an advisory lock on a database > DBG(1)[44393]> release an advisory lock on a database > root@jenkins10a:~ # echo $? > 70 >=20 > Is there anything I can help on debugging this? >=20 pkg info amd64-xtoolchain-gcc please Bapt --2/5bycvrmDh4d1IB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXAl7iAAoJEGOJi9zxtz5ayKoP/1Ylsv9aHHFd6M7c9mKiAvFk 69MzR0GbS0XLAzaUVtXV08THJla8FAELvP3nEPM44RI/NQQk7pshWkHzk65O06vd aRoAPt0293RFvcW4RL+F/U9W8vybosvq2YMb16ALVq7epzSuPhV8RXayBYTh2hox Kl1zz6T+LxDWZMMdC4r43Kbe88xot4bU51rNgivilxZSyxuwInKNaoVEUxlktAUX XSkfdPSxd1wBbjpAAQGAUSZ/IGGwv8UsbpUCJP++4p274x58B+pM7ELojUPpLw+4 hYDkWNw5XPB8WakoZyO5k0p7sXMiS9Q05KpHtDmLJ1ob6qvpN7JxxjBMsBkQb9MY nHCOTWIs5qmNVNk9lXTBGzgP4isf8aj6m7R3Kv6n4+rTaYpvOnw2+w/chaauZsCh NjyI5ghHU+BAdoDbDKlm5hGk12UF7QzExGcCC650gnVF1oX2+KAWhyjuu83mhs0D n65JBYr0Ar0uo1WPo9BKN3kHkM797C3RnT5djz2BN1XFtlIWwdn0H0PFG1+JDEf/ FagIXOoSYAXmKtlTToQHHU5J4NcF0roUOeh1LW1CDvrbZwQBLBfBWlLuAjFDhXUM KX0ES2lAx/NEeLYWAxLOdak03s7zCyZpse/6wGDfKGy5ucSn+rTvpTfYhmm8PDdr 6RvIJdhv4h/ZznO6XZdn =JfD8 -----END PGP SIGNATURE----- --2/5bycvrmDh4d1IB-- From owner-freebsd-current@freebsd.org Mon Apr 4 12:38: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 E8370B0278D for ; Mon, 4 Apr 2016 12:38:04 +0000 (UTC) (envelope-from lwhsu@FreeBSD.cs.nctu.edu.tw) Received: from FreeBSD.cs.nctu.edu.tw (freebsd2.cs.nctu.edu.tw [140.113.17.206]) by mx1.freebsd.org (Postfix) with ESMTP id B4B2C10C2; Mon, 4 Apr 2016 12:38:04 +0000 (UTC) (envelope-from lwhsu@FreeBSD.cs.nctu.edu.tw) Received: by FreeBSD.cs.nctu.edu.tw (Postfix, from userid 1058) id A98FA2F50; Mon, 4 Apr 2016 20:38:03 +0800 (CST) Date: Mon, 4 Apr 2016 20:38:03 +0800 From: Li-Wen Hsu To: Baptiste Daroussin Cc: Dimitry Andric , Andriy Gapon , freebsd-current@freebsd.org Subject: Re: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure Message-ID: <20160404123803.GA99836@FreeBSD.cs.nctu.edu.tw> References: <2034599654.182.1459676383628.JavaMail.jenkins@jenkins-9.freebsd.org> <57015089.4010700@FreeBSD.org> <19A774FF-773C-4F29-8DF1-E72BBED81DA9@FreeBSD.org> <20160403225014.GH5214@ivaldir.etoilebsd.net> <20160404103859.GA27648@FreeBSD.cs.nctu.edu.tw> <20160404105316.GA49864@ivaldir.etoilebsd.net> <20160404122539.GA14905@FreeBSD.cs.nctu.edu.tw> <20160404123234.GC49864@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline In-Reply-To: <20160404123234.GC49864@ivaldir.etoilebsd.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 04 Apr 2016 12:38:05 -0000 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 04, 2016 at 14:32:35 +0200, Baptiste Daroussin wrote: > On Mon, Apr 04, 2016 at 08:25:39PM +0800, Li-Wen Hsu wrote: > > On Mon, Apr 04, 2016 at 12:53:16 +0200, Baptiste Daroussin wrote: > > > On Mon, Apr 04, 2016 at 06:39:00PM +0800, Li-Wen Hsu wrote: > > > > On Mon, Apr 04, 2016 at 00:50:14 +0200, Baptiste Daroussin wrote: > > > > > On Mon, Apr 04, 2016 at 04:41:47AM +0800, Li-Wen Hsu wrote: > > > > > > I've checked this a little more, I found the return code of > > > > > > "installing a installed package" has been changed. > > > > > >=20 > > > > > > For pkg 1.6.4_1, it returns 0, but 1.7.1 returns 70, thus jenki= ns > > > > > > consider the build script execution failure. > > > > > >=20 > > > > > >=20 > > > > > It shoudl not return 70 if it returns 70 then there is a bug I ca= n fix, I need > > > > > to know more about what is failing to be able to fix > > > >=20 > > > > What else information do you need? My experiment is as following: > > > >=20 > > > > On a machine uses quarterly branch, where pkg is 1.6.4_1, install a > > > > installed package. I choose rsync here, then echo $?, it returns 0. > > > >=20 > > > > And I switch to latest branch, also use `pkg install -y rsync`, but= this > > > > time $? is 70. > > > >=20 > > > > Jenkins "Execute shell" build step checks return value of each comm= and > > > > in the shell script, if it is non-zero, it aborts the build and > > > > considers if failure. > > >=20 > > > Return 70 means an error occured. if I look at the log I can see that > > > powerpc64-gcc is not installed for sure, hence the error 70 > > >=20 > > > What is strange it that no "error message is shown" > >=20 > > Very strange, no further error message is shown, even -d provided. > >=20 > > root@jenkins10a:~ # pkg -d install -y devel/amd64-xtoolchain-gcc > > DBG(1)[44393]> pkg initialized > > Updating FreeBSD repository catalogue... > > DBG(1)[44393]> PkgRepo: verifying update for FreeBSD > > DBG(1)[44393]> Pkgrepo, begin update of '/var/db/pkg/repo-FreeBSD.sqlit= e' > > DBG(1)[44393]> Fetch: fetching from: http://pkgmir.pkg.freebsd.org/Free= BSD:10:amd64/latest/meta.txz with opts "i" > > DBG(1)[44393]> Fetch: fetching from: http://pkgmir.pkg.freebsd.org/Free= BSD:10:amd64/latest/packagesite.txz with opts "i" > > FreeBSD repository is up-to-date. > > All repositories are up-to-date. > > DBG(1)[44393]> want to get an advisory lock on a database > > DBG(1)[44393]> release an advisory lock on a database > > root@jenkins10a:~ # echo $? > > 70 > >=20 > > Is there anything I can help on debugging this? > >=20 > pkg info amd64-xtoolchain-gcc please root@jenkins10a:~ # pkg -d info amd64-xtoolchain-gcc DBG(1)[44644]> pkg initialized amd64-xtoolchain-gcc-0.1 Name : amd64-xtoolchain-gcc Version : 0.1 Installed on : Tue Mar 3 07:32:25 2015 UTC Origin : devel/amd64-xtoolchain-gcc Architecture : freebsd:10:x86:64 Prefix : /usr/local Categories : devel Licenses : Maintainer : bapt@FreeBSD.org WWW : UNKNOWN Comment : Pre seeded toolchain to cross build FreeBSD base Annotations : repo_type : binary repository : FreeBSD Flat size : 225B Description : Pre seeded cross toolchain definition to cross build FreeBSD base --=20 Li-Wen Hsu https://lwhsu.org --CE+1k2dSO48ffgeK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJXAmAqXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMDdENTNGNjUyMTUzMzVCNzA5NDNGODQ2 NzI3RTc3Qzg4NjJCNjU2AAoJEGcn53yIYrZWK+wQAJo+sp726xIXuHlQcQw7kOSm HWjoIPrwF1C1usKf9GI+7LuFGg7EvnsDboD49VsXIKBETZ850UV3Il1LUlrmKf22 S6MXOEaCU7Yi3PqiU/oXkby93Sb4yGyBsXhAj9pXSdtb1He9P1DubOHIYeXKk8jM a2GN8z6iN0i5Oy+5DrhH7W3JRyUtwdi5k72rBr6Y7ygcx5Jl9h4emOieEE+UDw3U FypgMXDyJVDj/Ca0ECZX6gh59kKwA98+CE5lv3j2cXCcnzV+IlkddR3YGX6KqUxj YdVh6Jdskhi8biRelbChoUo7WiLw5Et1cb4Xs9fouEb0s7uHrinfXqIRrNkuDku5 hTKmuy+sXJ56TBEsHRnOgYavcJB2NKthz+T0lhxOCyfBCKVjHhdn97a0EAGDn6l0 hDXDQ3/hrl4+0EvEkMVo2QdxwpsBicNqB0YzuiJ4OGNL4H1uSvFQJjIVVY7XJ4+h fgPHUi6S0mbt69xNK/jAy6QDjKtuGC7PR89Eph/a35fQJ4cJkh4ili5rNDfsNOaF 1g7w3HxysxerAfc+7RBKhlGKsG4zvCrJelkQhdUomz0g8TNrIXMpPBBt078qSkb2 rnNk2b3WE+mtppkmnfiOfB5QdEJlqos5ZNPd9icoCTlFs9SQbleC43UtH5ufLGdm dytMpQ2bUEEPnbWixkjK =2f4Q -----END PGP SIGNATURE----- --CE+1k2dSO48ffgeK-- From owner-freebsd-current@freebsd.org Mon Apr 4 12:43:54 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 7F6CDB029AC for ; Mon, 4 Apr 2016 12:43:54 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 1042F14CA; Mon, 4 Apr 2016 12:43:54 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by mail-lf0-x234.google.com with SMTP id p188so141597403lfd.0; Mon, 04 Apr 2016 05:43:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=NBHioagR5VPLQGvQOQMZ/oF0kdn7+yuYFNZhGUVc9Bk=; b=fmxSxhiUFxBOyhjvQOrq8giQpd/dX+8cyV/C6Jcq5ZjE5w9w/J4UIqaOmQTKyMd2OR cdGQWZBp9ENkQlvVLV++lt7duzy7K7MDyWX3LKG1uQrIzzczWthe3YYceMIWWgTm3nmL zKvW2ZnkOMd0sNRAHrlyi0b96x+pvsqV+sENh/tynAeuommSUy+ecOtktxm40k49IdoF B6LD+98XNcbwnVxyophaj/5KmBK+wfEyQVauqrncyNq4uwP0hCgkWwf0/mQ7PVsVsjNl LRZlAfRhG6ufO7ZPO5GcyCuqMjyQ9grzgciu6EAw1xzVZVvdFr4vg8V3TsYW3O1N/sVd WOEA== 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 :references:mime-version:content-disposition:in-reply-to:user-agent; bh=NBHioagR5VPLQGvQOQMZ/oF0kdn7+yuYFNZhGUVc9Bk=; b=A/4yV6Sm4krakKSNufJiUYkfm4+7yBY7QhCPoFtqq6CRytHHxyEzQwcHu0pVDb0Wq2 nGG1SWan5/nxp6xl2XLgmuDMSF8h8xbqyyJQIhRd20Vj0+fS3qscP0UwCBS5DFQwzlms yajnMvIqemAXa+il8kmSeFhizvpAn9P0mCKcB9P0hH2STI4snI5t3FRkSlhCq6ES95h/ SLVZpZZCPAwvTzjT9af318htdJdYvMb+Hw/2bqxZda1eVCJoPrT9F0XPU7RaVP+WTaUJ bmVHh4yZU+6KWwR7/H3zwc1ZbeM9N2+ialUipHkCFMWSuwaqV8M3AOOvMoKSh448tgdr 7i1w== X-Gm-Message-State: AD7BkJJa/Fe4GHsXiGjKnNb9qTLYy66mEK9Zci2yybNVEJqSqA5SiGO8BTEuR0pH99NSrA== X-Received: by 10.194.22.35 with SMTP id a3mr954115wjf.165.1459773832241; Mon, 04 Apr 2016 05:43:52 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by smtp.gmail.com with ESMTPSA id c190sm12694517wmd.10.2016.04.04.05.43.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Apr 2016 05:43:51 -0700 (PDT) Sender: Baptiste Daroussin Date: Mon, 4 Apr 2016 14:43:49 +0200 From: Baptiste Daroussin To: Li-Wen Hsu Cc: Dimitry Andric , Andriy Gapon , freebsd-current@freebsd.org Subject: Re: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure Message-ID: <20160404124349.GD49864@ivaldir.etoilebsd.net> References: <2034599654.182.1459676383628.JavaMail.jenkins@jenkins-9.freebsd.org> <57015089.4010700@FreeBSD.org> <19A774FF-773C-4F29-8DF1-E72BBED81DA9@FreeBSD.org> <20160403225014.GH5214@ivaldir.etoilebsd.net> <20160404103859.GA27648@FreeBSD.cs.nctu.edu.tw> <20160404105316.GA49864@ivaldir.etoilebsd.net> <20160404122539.GA14905@FreeBSD.cs.nctu.edu.tw> <20160404123234.GC49864@ivaldir.etoilebsd.net> <20160404123803.GA99836@FreeBSD.cs.nctu.edu.tw> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WChQLJJJfbwij+9x" Content-Disposition: inline In-Reply-To: <20160404123803.GA99836@FreeBSD.cs.nctu.edu.tw> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 04 Apr 2016 12:43:54 -0000 --WChQLJJJfbwij+9x Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 04, 2016 at 08:38:03PM +0800, Li-Wen Hsu wrote: > On Mon, Apr 04, 2016 at 14:32:35 +0200, Baptiste Daroussin wrote: > > On Mon, Apr 04, 2016 at 08:25:39PM +0800, Li-Wen Hsu wrote: > > > On Mon, Apr 04, 2016 at 12:53:16 +0200, Baptiste Daroussin wrote: > > > > On Mon, Apr 04, 2016 at 06:39:00PM +0800, Li-Wen Hsu wrote: > > > > > On Mon, Apr 04, 2016 at 00:50:14 +0200, Baptiste Daroussin wrote: > > > > > > On Mon, Apr 04, 2016 at 04:41:47AM +0800, Li-Wen Hsu wrote: > > > > > > > I've checked this a little more, I found the return code of > > > > > > > "installing a installed package" has been changed. > > > > > > >=20 > > > > > > > For pkg 1.6.4_1, it returns 0, but 1.7.1 returns 70, thus jen= kins > > > > > > > consider the build script execution failure. > > > > > > >=20 > > > > > > >=20 > > > > > > It shoudl not return 70 if it returns 70 then there is a bug I = can fix, I need > > > > > > to know more about what is failing to be able to fix > > > > >=20 > > > > > What else information do you need? My experiment is as following: > > > > >=20 > > > > > On a machine uses quarterly branch, where pkg is 1.6.4_1, install= a > > > > > installed package. I choose rsync here, then echo $?, it returns= 0. > > > > >=20 > > > > > And I switch to latest branch, also use `pkg install -y rsync`, b= ut this > > > > > time $? is 70. > > > > >=20 > > > > > Jenkins "Execute shell" build step checks return value of each co= mmand > > > > > in the shell script, if it is non-zero, it aborts the build and > > > > > considers if failure. > > > >=20 > > > > Return 70 means an error occured. if I look at the log I can see th= at > > > > powerpc64-gcc is not installed for sure, hence the error 70 > > > >=20 > > > > What is strange it that no "error message is shown" > > >=20 > > > Very strange, no further error message is shown, even -d provided. > > >=20 > > > root@jenkins10a:~ # pkg -d install -y devel/amd64-xtoolchain-gcc > > > DBG(1)[44393]> pkg initialized > > > Updating FreeBSD repository catalogue... > > > DBG(1)[44393]> PkgRepo: verifying update for FreeBSD > > > DBG(1)[44393]> Pkgrepo, begin update of '/var/db/pkg/repo-FreeBSD.sql= ite' > > > DBG(1)[44393]> Fetch: fetching from: http://pkgmir.pkg.freebsd.org/Fr= eeBSD:10:amd64/latest/meta.txz with opts "i" > > > DBG(1)[44393]> Fetch: fetching from: http://pkgmir.pkg.freebsd.org/Fr= eeBSD:10:amd64/latest/packagesite.txz with opts "i" > > > FreeBSD repository is up-to-date. > > > All repositories are up-to-date. > > > DBG(1)[44393]> want to get an advisory lock on a database > > > DBG(1)[44393]> release an advisory lock on a database > > > root@jenkins10a:~ # echo $? > > > 70 > > >=20 > > > Is there anything I can help on debugging this? > > >=20 > > pkg info amd64-xtoolchain-gcc please >=20 > root@jenkins10a:~ # pkg -d info amd64-xtoolchain-gcc > DBG(1)[44644]> pkg initialized > amd64-xtoolchain-gcc-0.1 > Name : amd64-xtoolchain-gcc > Version : 0.1 > Installed on : Tue Mar 3 07:32:25 2015 UTC > Origin : devel/amd64-xtoolchain-gcc > Architecture : freebsd:10:x86:64 > Prefix : /usr/local > Categories : devel > Licenses : > Maintainer : bapt@FreeBSD.org > WWW : UNKNOWN > Comment : Pre seeded toolchain to cross build FreeBSD base > Annotations : > repo_type : binary > repository : FreeBSD > Flat size : 225B > Description : > Pre seeded cross toolchain definition to cross build FreeBSD base >=20 Ok I see the issue, I will fix it thanks. Bapt --WChQLJJJfbwij+9x Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXAmGFAAoJEGOJi9zxtz5aKfMP/iHaL/n0jRP2Nb+zuJ6+ntW3 BI5a+QmdzUpkhBdmApxvMjzMHviTfL7QYJIRVOT8OwkRUcN91BksM9uK00ENmova oL+6pZBAKruhn40FTaZFBv3QGubvRD3wOubD5GNe6mrtXWJlH36h/2XsRcetaqLM BANDyuONUQGTdnQMGDVK2tCW6LBBMECmw+iIkzV1Kx6GPLYiQK2LKB4woORXsb/G ImOmdl9iGJci6Y6KKoW+BY844u9nAfvBIuOBNgXiodEYld/oMVbHjr3QOeFMOo2Q bXMsJq2DMiHKedixoj9ym8tYAFBMLZzJQGmiiMblgrQQYCaSBdShqK73Ob1B0op4 zgoXFOjVPP6edOaLsU3nG/C049ybWKgd7Wpajmu+i4rPWhgCUQ39oo0gQ/ZVD/gw tuu3uT79932ONf99k6p1c23a91f75RRJl4Zb02ceahz5wLde/9xuqBpocDjVB/4b 7fkvVHTMQTgEsXVYZBELz5GdO5Z1cJ5kWm3BEblZ2PYi4GDOX7d8MnASDLiu8Fu8 zU8e8GU59Qy3v7wJcngdV8jW+Yh+7guqNKerB1A1qi70tOcC4J9d2OtmTH3exbH9 v3DZfinWbr13hC/XsXQ/2DIkN7sJky08dFZ/0joJjCm16j6klR0Iy2rikBVW9e1C fIJ3Ok7JBCH7Rg0YrhEN =gXTP -----END PGP SIGNATURE----- --WChQLJJJfbwij+9x-- From owner-freebsd-current@freebsd.org Mon Apr 4 13:58:32 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 100FDB032CE; Mon, 4 Apr 2016 13:58:32 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.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 A1A851807; Mon, 4 Apr 2016 13:58:31 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074423-537ff70000002943-81-570273044cd5 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id AC.A6.10563.40372075; Mon, 4 Apr 2016 09:58:29 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u34DwSwH018056; Mon, 4 Apr 2016 09:58:28 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u34DwP3e015135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 4 Apr 2016 09:58:28 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u34DwP1L024208; Mon, 4 Apr 2016 09:58:25 -0400 (EDT) Date: Mon, 4 Apr 2016 09:58:24 -0400 (EDT) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: freebsd-hackers@FreeBSD.org cc: freebsd-current@FreeBSD.org Subject: Last call for 2016Q1 quarterly status report submissions Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLIsWRmVeSWpSXmKPExsUixCmqrctazBRu8DrQYs6bD0wW2zf/Y3Rg 8pjxaT5LAGMUl01Kak5mWWqRvl0CV8alR32sBbO4K36eP8DWwLiCs4uRk0NCwERizb1e5i5G Lg4hgTYmiRUzP7OAJIQENjBKbDrMDpE4yCQxfcF3ZohEvcSmiYvZuhg5OFgEtCQWn2cCCbMJ qEmsX3GNGWKoosTmU5PAbBEBeYl9Te/ZQWxmIHvL6slsILawgKPEof0PwXp5gezPvy4xgtii AjoSq/dPYYGIC0qcnPmEBaJXS2L59G0sExj5ZyFJzUKSWsDItIpRNiW3Sjc3MTOnODVZtzg5 MS8vtUjXTC83s0QvNaV0EyMo1NhdlHcwvuzzPsQowMGoxMP74ShjuBBrYllxZe4hRkkOJiVR 3vpwpnAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrwnC4FyvCmJlVWpRfkwKWkOFiVxXkYGBgYh gfTEktTs1NSC1CKYrAwHh5IE71OQRsGi1PTUirTMnBKENBMHJ8hwHqDhp8CGFxck5hZnpkPk TzEqSonz2oEkBEASGaV5cL3gVLCbSfUVozjQK8K8NkVAVTzANALX/QpoMBPQ4HphsMEliQgp qQZGUa8pj1n2zZApCDsvWZeo4V1/viuTVT9cJvMyy9pf0RqP7/TGvDU5zfWF8QDX3fg8y9qb y7z9BEv3brv1XLGhzf+r+8+JISxKnM5ts4rDD905qrDhnprdUsO/er84NxXONGtlVV3gvdyq t0/q/WqWhlOT280fC/Ee3vJpyvNW6/Kkh8fsMxYqsRRnJBpqMRcVJwIAYL87nOACAAA= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 04 Apr 2016 13:58:32 -0000 Dear FreeBSD Community, There are just a few days left until the April 7 deadline for submitting entries for the next FreeBSD Quarterly Status Report. Please submit entries for work done in January, February, or March. Status report submissions do not have to be very long. They may be about anything happening in the FreeBSD project and community, and provide a great way to inform FreeBSD users and developers about what you're working on. Submission of reports is not restricted to committers. Anyone doing anything interesting and FreeBSD-related can -- and should -- write one! The preferred and easiest submission method is to use the XML generator [1] with the results emailed to the status report team at monthly at FreeBSD.org . There is also an XML template [2] which can be filled out manually and attached if preferred. For the expected content and style, please study our guidelines on how to write a good status report [3]. You can also review previous issues [4][5] for ideas on the style and format. We are looking forward to all of your 2016Q1 reports! Thanks, Ben (on behalf of monthly@) [1] http://www.freebsd.org/cgi/monthly.cgi [2] http://www.freebsd.org/news/status/report-sample.xml [3] http://www.freebsd.org/news/status/howto.html [4] http://www.freebsd.org/news/status/report-2015-07-2015-09.html [5] http://www.freebsd.org/news/status/report-2015-10-2015-12.html From owner-freebsd-current@freebsd.org Mon Apr 4 16:32: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 E8E17B0289F for ; Mon, 4 Apr 2016 16:32:46 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C42B9160F for ; Mon, 4 Apr 2016 16:32:45 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA18885 for ; Mon, 04 Apr 2016 19:32:43 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1an7Qh-0007Oa-4X for freebsd-current@FreeBSD.org; Mon, 04 Apr 2016 19:32:43 +0300 Subject: [HEADSUP] new x86 smp topology detection code References: <201604041609.u34G9TCd022548@repo.freebsd.org> To: FreeBSD Current From: Andriy Gapon X-Forwarded-Message-Id: <201604041609.u34G9TCd022548@repo.freebsd.org> Message-ID: <570296F3.8090307@FreeBSD.org> Date: Mon, 4 Apr 2016 19:31:47 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <201604041609.u34G9TCd022548@repo.freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 04 Apr 2016 16:32:47 -0000 I've just committed new code for detecting SMP (processor and cache) topology on x86 systems. Please be aware. If you get any panics or crashes that look like they might be caused by this change please send a copy of a report to me. Another thing to watch is kern.sched.topology_spec. Please check if the reported topology reasonably matches what you expect on your system. You can install hwloc package (devel/hwloc) and then run lstopo -p --no-io to double-check the topology (--output-format ascii would produce a nice ASCII-art diagram). I hope that you see only improvements :-) -------- Forwarded Message -------- Subject: svn commit: r297558 - in head/sys: kern sys x86/x86 Date: Mon, 4 Apr 2016 16:09:29 +0000 (UTC) From: Andriy Gapon To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Author: avg Date: Mon Apr 4 16:09:29 2016 New Revision: 297558 URL: https://svnweb.freebsd.org/changeset/base/297558 Log: new x86 smp topology detection code Previously, the code determined a topology of processing units (hardware threads, cores, packages) and then deduced a cache topology using certain assumptions. The new code builds a topology that includes both processing units and caches using the information provided by the hardware. At the moment, the discovered full topology is used only to creeate a scheduling topology for SCHED_ULE. There is no KPI for other kernel uses. Summary: - based on APIC ID derivation rules for Intel and AMD CPUs - can handle non-uniform topologies - requires homogeneous APIC ID assignment (same bit widths for ID components) - topology for dual-node AMD CPUs may not be optimal - topology for latest AMD CPU models may not be optimal as the code is several years old - supports only thread/package/core/cache nodes Todo: - AMD dual-node processors - latest AMD processors - NUMA nodes - checking for homogeneity of the APIC ID assignment across packages - more flexible cache placement within topology - expose topology to userland, e.g., via sysctl nodes Long term todo: - KPI for CPU sharing and affinity with respect to various resources (e.g., two logical processors may share the same FPU, etc) Reviewed by: mav Tested by: mav MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D2728 Modified: head/sys/kern/subr_smp.c head/sys/sys/smp.h head/sys/x86/x86/mp_x86.c Modified: head/sys/kern/subr_smp.c ============================================================================== --- head/sys/kern/subr_smp.c Mon Apr 4 15:56:14 2016 (r297557) +++ head/sys/kern/subr_smp.c Mon Apr 4 16:09:29 2016 (r297558) @@ -39,6 +39,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -51,6 +52,10 @@ __FBSDID("$FreeBSD$"); #include "opt_sched.h" #ifdef SMP +MALLOC_DEFINE(M_TOPO, "toponodes", "SMP topology data"); +#endif + +#ifdef SMP volatile cpuset_t stopped_cpus; volatile cpuset_t started_cpus; volatile cpuset_t suspended_cpus; @@ -556,7 +561,7 @@ smp_rendezvous(void (* setup_func)(void smp_rendezvous_cpus(all_cpus, setup_func, action_func, teardown_func, arg); } -static struct cpu_group group[MAXCPU]; +static struct cpu_group group[MAXCPU * MAX_CACHE_LEVELS + 1]; struct cpu_group * smp_topo(void) @@ -616,6 +621,17 @@ smp_topo(void) } struct cpu_group * +smp_topo_alloc(u_int count) +{ + static u_int index; + u_int curr; + + curr = index; + index += count; + return (&group[curr]); +} + +struct cpu_group * smp_topo_none(void) { struct cpu_group *top; @@ -861,3 +877,233 @@ sysctl_kern_smp_active(SYSCTL_HANDLER_AR return (error); } + +#ifdef SMP +void +topo_init_node(struct topo_node *node) +{ + + bzero(node, sizeof(*node)); + TAILQ_INIT(&node->children); +} + +void +topo_init_root(struct topo_node *root) +{ + + topo_init_node(root); + root->type = TOPO_TYPE_SYSTEM; +} + +struct topo_node * +topo_add_node_by_hwid(struct topo_node *parent, int hwid, + topo_node_type type, uintptr_t subtype) +{ + struct topo_node *node; + + TAILQ_FOREACH_REVERSE(node, &parent->children, + topo_children, siblings) { + if (node->hwid == hwid + && node->type == type && node->subtype == subtype) { + return (node); + } + } + + node = malloc(sizeof(*node), M_TOPO, M_WAITOK); + topo_init_node(node); + node->parent = parent; + node->hwid = hwid; + node->type = type; + node->subtype = subtype; + TAILQ_INSERT_TAIL(&parent->children, node, siblings); + parent->nchildren++; + + return (node); +} + +struct topo_node * +topo_find_node_by_hwid(struct topo_node *parent, int hwid, + topo_node_type type, uintptr_t subtype) +{ + + struct topo_node *node; + + TAILQ_FOREACH(node, &parent->children, siblings) { + if (node->hwid == hwid + && node->type == type && node->subtype == subtype) { + return (node); + } + } + + return (NULL); +} + +void +topo_promote_child(struct topo_node *child) +{ + struct topo_node *next; + struct topo_node *node; + struct topo_node *parent; + + parent = child->parent; + next = TAILQ_NEXT(child, siblings); + TAILQ_REMOVE(&parent->children, child, siblings); + TAILQ_INSERT_HEAD(&parent->children, child, siblings); + + while (next != NULL) { + node = next; + next = TAILQ_NEXT(node, siblings); + TAILQ_REMOVE(&parent->children, node, siblings); + TAILQ_INSERT_AFTER(&parent->children, child, node, siblings); + child = node; + } +} + +struct topo_node * +topo_next_node(struct topo_node *top, struct topo_node *node) +{ + struct topo_node *next; + + if ((next = TAILQ_FIRST(&node->children)) != NULL) + return (next); + + if ((next = TAILQ_NEXT(node, siblings)) != NULL) + return (next); + + while ((node = node->parent) != top) + if ((next = TAILQ_NEXT(node, siblings)) != NULL) + return (next); + + return (NULL); +} + +struct topo_node * +topo_next_nonchild_node(struct topo_node *top, struct topo_node *node) +{ + struct topo_node *next; + + if ((next = TAILQ_NEXT(node, siblings)) != NULL) + return (next); + + while ((node = node->parent) != top) + if ((next = TAILQ_NEXT(node, siblings)) != NULL) + return (next); + + return (NULL); +} + +void +topo_set_pu_id(struct topo_node *node, cpuid_t id) +{ + + KASSERT(node->type == TOPO_TYPE_PU, + ("topo_set_pu_id: wrong node type: %u", node->type)); + KASSERT(CPU_EMPTY(&node->cpuset) && node->cpu_count == 0, + ("topo_set_pu_id: cpuset already not empty")); + node->id = id; + CPU_SET(id, &node->cpuset); + node->cpu_count = 1; + node->subtype = 1; + + while ((node = node->parent) != NULL) { + if (CPU_ISSET(id, &node->cpuset)) + break; + CPU_SET(id, &node->cpuset); + node->cpu_count++; + } +} + +int +topo_analyze(struct topo_node *topo_root, int all, + int *pkg_count, int *cores_per_pkg, int *thrs_per_core) +{ + struct topo_node *pkg_node; + struct topo_node *core_node; + struct topo_node *pu_node; + int thrs_per_pkg; + int cpp_counter; + int tpc_counter; + int tpp_counter; + + *pkg_count = 0; + *cores_per_pkg = -1; + *thrs_per_core = -1; + thrs_per_pkg = -1; + pkg_node = topo_root; + while (pkg_node != NULL) { + if (pkg_node->type != TOPO_TYPE_PKG) { + pkg_node = topo_next_node(topo_root, pkg_node); + continue; + } + if (!all && CPU_EMPTY(&pkg_node->cpuset)) { + pkg_node = topo_next_nonchild_node(topo_root, pkg_node); + continue; + } + + (*pkg_count)++; + + cpp_counter = 0; + tpp_counter = 0; + core_node = pkg_node; + while (core_node != NULL) { + if (core_node->type == TOPO_TYPE_CORE) { + if (!all && CPU_EMPTY(&core_node->cpuset)) { + core_node = + topo_next_nonchild_node(pkg_node, + core_node); + continue; + } + + cpp_counter++; + + tpc_counter = 0; + pu_node = core_node; + while (pu_node != NULL) { + if (pu_node->type == TOPO_TYPE_PU && + (all || !CPU_EMPTY(&pu_node->cpuset))) + tpc_counter++; + pu_node = topo_next_node(core_node, + pu_node); + } + + if (*thrs_per_core == -1) + *thrs_per_core = tpc_counter; + else if (*thrs_per_core != tpc_counter) + return (0); + + core_node = topo_next_nonchild_node(pkg_node, + core_node); + } else { + /* PU node directly under PKG. */ + if (core_node->type == TOPO_TYPE_PU && + (all || !CPU_EMPTY(&core_node->cpuset))) + tpp_counter++; + core_node = topo_next_node(pkg_node, + core_node); + } + } + + if (*cores_per_pkg == -1) + *cores_per_pkg = cpp_counter; + else if (*cores_per_pkg != cpp_counter) + return (0); + if (thrs_per_pkg == -1) + thrs_per_pkg = tpp_counter; + else if (thrs_per_pkg != tpp_counter) + return (0); + + pkg_node = topo_next_nonchild_node(topo_root, pkg_node); + } + + KASSERT(*pkg_count > 0, + ("bug in topology or analysis")); + if (*cores_per_pkg == 0) { + KASSERT(*thrs_per_core == -1 && thrs_per_pkg > 0, + ("bug in topology or analysis")); + *thrs_per_core = thrs_per_pkg; + } + + return (1); +} +#endif /* SMP */ + Modified: head/sys/sys/smp.h ============================================================================== --- head/sys/sys/smp.h Mon Apr 4 15:56:14 2016 (r297557) +++ head/sys/sys/smp.h Mon Apr 4 16:09:29 2016 (r297558) @@ -17,9 +17,52 @@ #ifndef LOCORE #include +#include /* - * Topology of a NUMA or HTT system. + * Types of nodes in the topological tree. + */ +typedef enum { + /* No node has this type; can be used in topo API calls. */ + TOPO_TYPE_DUMMY, + /* Processing unit aka computing unit aka logical CPU. */ + TOPO_TYPE_PU, + /* Physical subdivision of a package. */ + TOPO_TYPE_CORE, + /* CPU L1/L2/L3 cache. */ + TOPO_TYPE_CACHE, + /* Package aka chip, equivalent to socket. */ + TOPO_TYPE_PKG, + /* NUMA node. */ + TOPO_TYPE_NODE, + /* Other logical or physical grouping of PUs. */ + /* E.g. PUs on the same dye, or PUs sharing an FPU. */ + TOPO_TYPE_GROUP, + /* The whole system. */ + TOPO_TYPE_SYSTEM +} topo_node_type; + +/* Hardware indenitifier of a topology component. */ +typedef unsigned int hwid_t; +/* Logical CPU idenitifier. */ +typedef int cpuid_t; + +/* A node in the topology. */ +struct topo_node { + struct topo_node *parent; + TAILQ_HEAD(topo_children, topo_node) children; + TAILQ_ENTRY(topo_node) siblings; + cpuset_t cpuset; + topo_node_type type; + uintptr_t subtype; + hwid_t hwid; + cpuid_t id; + int nchildren; + int cpu_count; +}; + +/* + * Scheduling topology of a NUMA or SMP system. * * The top level topology is an array of pointers to groups. Each group * contains a bitmask of cpus in its group or subgroups. It may also @@ -52,6 +95,8 @@ typedef struct cpu_group *cpu_group_t; #define CG_SHARE_L2 2 #define CG_SHARE_L3 3 +#define MAX_CACHE_LEVELS CG_SHARE_L3 + /* * Behavior modifiers for load balancing and affinity. */ @@ -60,10 +105,29 @@ typedef struct cpu_group *cpu_group_t; #define CG_FLAG_THREAD (CG_FLAG_HTT | CG_FLAG_SMT) /* Any threading. */ /* - * Convenience routines for building topologies. + * Convenience routines for building and traversing topologies. */ #ifdef SMP +void topo_init_node(struct topo_node *node); +void topo_init_root(struct topo_node *root); +struct topo_node * topo_add_node_by_hwid(struct topo_node *parent, int hwid, + topo_node_type type, uintptr_t subtype); +struct topo_node * topo_find_node_by_hwid(struct topo_node *parent, int hwid, + topo_node_type type, uintptr_t subtype); +void topo_promote_child(struct topo_node *child); +struct topo_node * topo_next_node(struct topo_node *top, + struct topo_node *node); +struct topo_node * topo_next_nonchild_node(struct topo_node *top, + struct topo_node *node); +void topo_set_pu_id(struct topo_node *node, cpuid_t id); +int topo_analyze(struct topo_node *topo_root, int all, int *pkg_count, + int *cores_per_pkg, int *thrs_per_core); + +#define TOPO_FOREACH(i, root) \ + for (i = root; i != NULL; i = topo_next_node(root, i)) + struct cpu_group *smp_topo(void); +struct cpu_group *smp_topo_alloc(u_int count); struct cpu_group *smp_topo_none(void); struct cpu_group *smp_topo_1level(int l1share, int l1count, int l1flags); struct cpu_group *smp_topo_2level(int l2share, int l2count, int l1share, Modified: head/sys/x86/x86/mp_x86.c ============================================================================== --- head/sys/x86/x86/mp_x86.c Mon Apr 4 15:56:14 2016 (r297557) +++ head/sys/x86/x86/mp_x86.c Mon Apr 4 16:09:29 2016 (r297558) @@ -133,19 +133,28 @@ volatile int aps_ready = 0; * the APs. */ struct cpu_info cpu_info[MAX_APIC_ID + 1]; -int cpu_apic_ids[MAXCPU]; int apic_cpuids[MAX_APIC_ID + 1]; +int cpu_apic_ids[MAXCPU]; /* Holds pending bitmap based IPIs per CPU */ volatile u_int cpu_ipi_pending[MAXCPU]; -int cpu_logical; /* logical cpus per core */ -int cpu_cores; /* cores per package */ - static void release_aps(void *dummy); -static u_int hyperthreading_cpus; /* logical cpus sharing L1 cache */ static int hyperthreading_allowed = 1; +SYSCTL_INT(_machdep, OID_AUTO, hyperthreading_allowed, CTLFLAG_RDTUN, + &hyperthreading_allowed, 0, "Use Intel HTT logical CPUs"); + +static struct topo_node topo_root; + +static int pkg_id_shift; +static int core_id_shift; +static int disabled_cpus; + +struct cache_info { + int id_shift; + int present; +} static caches[MAX_CACHE_LEVELS]; void mem_range_AP_init(void) @@ -155,60 +164,125 @@ mem_range_AP_init(void) mem_range_softc.mr_op->initAP(&mem_range_softc); } -static void -topo_probe_amd(void) +/* + * Round up to the next power of two, if necessary, and then + * take log2. + * Returns -1 if argument is zero. + */ +static __inline int +mask_width(u_int x) { - int core_id_bits; - int id; - /* AMD processors do not support HTT. */ - cpu_logical = 1; + return (fls(x << (1 - powerof2(x))) - 1); +} + +static int +add_deterministic_cache(int type, int level, int share_count) +{ - if ((amd_feature2 & AMDID2_CMP) == 0) { - cpu_cores = 1; - return; + if (type == 0) + return (0); + if (type > 3) { + printf("unexpected cache type %d\n", type); + return (1); } - - core_id_bits = (cpu_procinfo2 & AMDID_COREID_SIZE) >> - AMDID_COREID_SIZE_SHIFT; - if (core_id_bits == 0) { - cpu_cores = (cpu_procinfo2 & AMDID_CMP_CORES) + 1; - return; + if (type == 2) /* ignore instruction cache */ + return (1); + if (level == 0 || level > MAX_CACHE_LEVELS) { + printf("unexpected cache level %d\n", type); + return (1); } - /* Fam 10h and newer should get here. */ - for (id = 0; id <= MAX_APIC_ID; id++) { - /* Check logical CPU availability. */ - if (!cpu_info[id].cpu_present || cpu_info[id].cpu_disabled) - continue; - /* Check if logical CPU has the same package ID. */ - if ((id >> core_id_bits) != (boot_cpu_id >> core_id_bits)) - continue; - cpu_cores++; + if (caches[level - 1].present) { + printf("WARNING: multiple entries for L%u data cache\n", level); + printf("%u => %u\n", caches[level - 1].id_shift, + mask_width(share_count)); + } + caches[level - 1].id_shift = mask_width(share_count); + caches[level - 1].present = 1; + + if (caches[level - 1].id_shift > pkg_id_shift) { + printf("WARNING: L%u data cache covers more " + "APIC IDs than a package\n", level); + printf("%u > %u\n", caches[level - 1].id_shift, pkg_id_shift); + caches[level - 1].id_shift = pkg_id_shift; + } + if (caches[level - 1].id_shift < core_id_shift) { + printf("WARNING: L%u data cache covers less " + "APIC IDs than a core\n", level); + printf("%u < %u\n", caches[level - 1].id_shift, core_id_shift); + caches[level - 1].id_shift = core_id_shift; } + + return (1); } -/* - * Round up to the next power of two, if necessary, and then - * take log2. - * Returns -1 if argument is zero. - */ -static __inline int -mask_width(u_int x) +static void +topo_probe_amd(void) { + u_int p[4]; + int level; + int share_count; + int type; + int i; - return (fls(x << (1 - powerof2(x))) - 1); + /* No multi-core capability. */ + if ((amd_feature2 & AMDID2_CMP) == 0) + return; + + /* For families 10h and newer. */ + pkg_id_shift = (cpu_procinfo2 & AMDID_COREID_SIZE) >> + AMDID_COREID_SIZE_SHIFT; + + /* For 0Fh family. */ + if (pkg_id_shift == 0) + pkg_id_shift = + mask_width((cpu_procinfo2 & AMDID_CMP_CORES) + 1); + + if ((amd_feature2 & AMDID2_TOPOLOGY) != 0) { + for (i = 0; ; i++) { + cpuid_count(0x8000001d, i, p); + type = p[0] & 0x1f; + level = (p[0] >> 5) & 0x7; + share_count = 1 + ((p[0] >> 14) & 0xfff); + + if (!add_deterministic_cache(type, level, share_count)) + break; + } + } else { + if (cpu_exthigh >= 0x80000005) { + cpuid_count(0x80000005, 0, p); + if (((p[2] >> 24) & 0xff) != 0) { + caches[0].id_shift = 0; + caches[0].present = 1; + } + } + if (cpu_exthigh >= 0x80000006) { + cpuid_count(0x80000006, 0, p); + if (((p[2] >> 16) & 0xffff) != 0) { + caches[1].id_shift = 0; + caches[1].present = 1; + } + if (((p[3] >> 18) & 0x3fff) != 0) { + + /* + * TODO: Account for dual-node processors + * where each node within a package has its own + * L3 cache. + */ + caches[2].id_shift = pkg_id_shift; + caches[2].present = 1; + } + } + } } static void -topo_probe_0x4(void) +topo_probe_intel_0x4(void) { u_int p[4]; - int pkg_id_bits; - int core_id_bits; int max_cores; int max_logical; - int id; /* Both zero and one here mean one logical processor per package. */ max_logical = (cpu_feature & CPUID_HTT) != 0 ? @@ -216,180 +290,432 @@ topo_probe_0x4(void) if (max_logical <= 1) return; - /* - * Because of uniformity assumption we examine only - * those logical processors that belong to the same - * package as BSP. Further, we count number of - * logical processors that belong to the same core - * as BSP thus deducing number of threads per core. - */ if (cpu_high >= 0x4) { cpuid_count(0x04, 0, p); max_cores = ((p[0] >> 26) & 0x3f) + 1; } else max_cores = 1; - core_id_bits = mask_width(max_logical/max_cores); - if (core_id_bits < 0) - return; - pkg_id_bits = core_id_bits + mask_width(max_cores); - - for (id = 0; id <= MAX_APIC_ID; id++) { - /* Check logical CPU availability. */ - if (!cpu_info[id].cpu_present || cpu_info[id].cpu_disabled) - continue; - /* Check if logical CPU has the same package ID. */ - if ((id >> pkg_id_bits) != (boot_cpu_id >> pkg_id_bits)) - continue; - cpu_cores++; - /* Check if logical CPU has the same package and core IDs. */ - if ((id >> core_id_bits) == (boot_cpu_id >> core_id_bits)) - cpu_logical++; - } - KASSERT(cpu_cores >= 1 && cpu_logical >= 1, - ("topo_probe_0x4 couldn't find BSP")); - - cpu_cores /= cpu_logical; - hyperthreading_cpus = cpu_logical; + core_id_shift = mask_width(max_logical/max_cores); + KASSERT(core_id_shift >= 0, + ("intel topo: max_cores > max_logical\n")); + pkg_id_shift = core_id_shift + mask_width(max_cores); } static void -topo_probe_0xb(void) +topo_probe_intel_0xb(void) { u_int p[4]; int bits; - int cnt; - int i; - int logical; int type; - int x; + int i; + + /* Fall back if CPU leaf 11 doesn't really exist. */ + cpuid_count(0x0b, 0, p); + if (p[1] == 0) { + topo_probe_intel_0x4(); + return; + } /* We only support three levels for now. */ - for (i = 0; i < 3; i++) { + for (i = 0; ; i++) { cpuid_count(0x0b, i, p); - /* Fall back if CPU leaf 11 doesn't really exist. */ - if (i == 0 && p[1] == 0) { - topo_probe_0x4(); - return; - } - bits = p[0] & 0x1f; - logical = p[1] &= 0xffff; type = (p[2] >> 8) & 0xff; - if (type == 0 || logical == 0) + + if (type == 0) break; - /* - * Because of uniformity assumption we examine only - * those logical processors that belong to the same - * package as BSP. - */ - for (cnt = 0, x = 0; x <= MAX_APIC_ID; x++) { - if (!cpu_info[x].cpu_present || - cpu_info[x].cpu_disabled) - continue; - if (x >> bits == boot_cpu_id >> bits) - cnt++; - } + + /* TODO: check for duplicate (re-)assignment */ if (type == CPUID_TYPE_SMT) - cpu_logical = cnt; + core_id_shift = bits; else if (type == CPUID_TYPE_CORE) - cpu_cores = cnt; + pkg_id_shift = bits; + else + printf("unknown CPU level type %d\n", type); + } + + if (pkg_id_shift < core_id_shift) { + printf("WARNING: core covers more APIC IDs than a package\n"); + core_id_shift = pkg_id_shift; + } +} + +static void +topo_probe_intel_caches(void) +{ + u_int p[4]; + int level; + int share_count; + int type; + int i; + + if (cpu_high < 0x4) { + /* + * Available cache level and sizes can be determined + * via CPUID leaf 2, but that requires a huge table of hardcoded + * values, so for now just assume L1 and L2 caches potentially + * shared only by HTT processing units, if HTT is present. + */ + caches[0].id_shift = pkg_id_shift; + caches[0].present = 1; + caches[1].id_shift = pkg_id_shift; + caches[1].present = 1; + return; + } + + for (i = 0; ; i++) { + cpuid_count(0x4, i, p); + type = p[0] & 0x1f; + level = (p[0] >> 5) & 0x7; + share_count = 1 + ((p[0] >> 14) & 0xfff); + + if (!add_deterministic_cache(type, level, share_count)) + break; } - if (cpu_logical == 0) - cpu_logical = 1; - cpu_cores /= cpu_logical; +} + +static void +topo_probe_intel(void) +{ + + /* + * See Intel(R) 64 Architecture Processor + * Topology Enumeration article for details. + * + * Note that 0x1 <= cpu_high < 4 case should be + * compatible with topo_probe_intel_0x4() logic when + * CPUID.1:EBX[23:16] > 0 (cpu_cores will be 1) + * or it should trigger the fallback otherwise. + */ + if (cpu_high >= 0xb) + topo_probe_intel_0xb(); + else if (cpu_high >= 0x1) + topo_probe_intel_0x4(); + + topo_probe_intel_caches(); } /* - * Both topology discovery code and code that consumes topology - * information assume top-down uniformity of the topology. - * That is, all physical packages must be identical and each - * core in a package must have the same number of threads. * Topology information is queried only on BSP, on which this * code runs and for which it can query CPUID information. - * Then topology is extrapolated on all packages using the - * uniformity assumption. + * Then topology is extrapolated on all packages using an + * assumption that APIC ID to hardware component ID mapping is + * homogenious. + * That doesn't necesserily imply that the topology is uniform. */ void topo_probe(void) { static int cpu_topo_probed = 0; + struct x86_topo_layer { + int type; + int subtype; + int id_shift; + } topo_layers[MAX_CACHE_LEVELS + 3]; + struct topo_node *parent; + struct topo_node *node; + int layer; + int nlayers; + int node_id; + int i; if (cpu_topo_probed) return; CPU_ZERO(&logical_cpus_mask); + if (mp_ncpus <= 1) - cpu_cores = cpu_logical = 1; + ; /* nothing */ else if (cpu_vendor_id == CPU_VENDOR_AMD) topo_probe_amd(); - else if (cpu_vendor_id == CPU_VENDOR_INTEL) { - /* - * See Intel(R) 64 Architecture Processor - * Topology Enumeration article for details. - * - * Note that 0x1 <= cpu_high < 4 case should be - * compatible with topo_probe_0x4() logic when - * CPUID.1:EBX[23:16] > 0 (cpu_cores will be 1) - * or it should trigger the fallback otherwise. - */ - if (cpu_high >= 0xb) - topo_probe_0xb(); - else if (cpu_high >= 0x1) - topo_probe_0x4(); - } + else if (cpu_vendor_id == CPU_VENDOR_INTEL) + topo_probe_intel(); + + KASSERT(pkg_id_shift >= core_id_shift, + ("bug in APIC topology discovery")); + + nlayers = 0; + bzero(topo_layers, sizeof(topo_layers)); + + topo_layers[nlayers].type = TOPO_TYPE_PKG; + topo_layers[nlayers].id_shift = pkg_id_shift; + if (bootverbose) + printf("Package ID shift: %u\n", topo_layers[nlayers].id_shift); + nlayers++; /* - * Fallback: assume each logical CPU is in separate - * physical package. That is, no multi-core, no SMT. - */ - if (cpu_cores == 0 || cpu_logical == 0) - cpu_cores = cpu_logical = 1; + * Consider all caches to be within a package/chip + * and "in front" of all sub-components like + * cores and hardware threads. + */ + for (i = MAX_CACHE_LEVELS - 1; i >= 0; --i) { + if (caches[i].present) { + KASSERT(caches[i].id_shift <= pkg_id_shift, + ("bug in APIC topology discovery")); + KASSERT(caches[i].id_shift >= core_id_shift, + ("bug in APIC topology discovery")); + + topo_layers[nlayers].type = TOPO_TYPE_CACHE; + topo_layers[nlayers].subtype = i + 1; + topo_layers[nlayers].id_shift = caches[i].id_shift; + if (bootverbose) + printf("L%u cache ID shift: %u\n", + topo_layers[nlayers].subtype, + topo_layers[nlayers].id_shift); + nlayers++; + } + } + + if (pkg_id_shift > core_id_shift) { + topo_layers[nlayers].type = TOPO_TYPE_CORE; + topo_layers[nlayers].id_shift = core_id_shift; + if (bootverbose) + printf("Core ID shift: %u\n", + topo_layers[nlayers].id_shift); + nlayers++; + } + + topo_layers[nlayers].type = TOPO_TYPE_PU; + topo_layers[nlayers].id_shift = 0; + nlayers++; + + topo_init_root(&topo_root); + for (i = 0; i <= MAX_APIC_ID; ++i) { + if (!cpu_info[i].cpu_present) + continue; + + parent = &topo_root; + for (layer = 0; layer < nlayers; ++layer) { + node_id = i >> topo_layers[layer].id_shift; + parent = topo_add_node_by_hwid(parent, node_id, + topo_layers[layer].type, + topo_layers[layer].subtype); + } + } + + parent = &topo_root; + for (layer = 0; layer < nlayers; ++layer) { + node_id = boot_cpu_id >> topo_layers[layer].id_shift; + node = topo_find_node_by_hwid(parent, node_id, + topo_layers[layer].type, + topo_layers[layer].subtype); + topo_promote_child(node); + parent = node; + } + cpu_topo_probed = 1; } -struct cpu_group * -cpu_topo(void) +/* + * Assign logical CPU IDs to local APICs. + */ +void +assign_cpu_ids(void) { - int cg_flags; + struct topo_node *node; + u_int smt_mask; + + smt_mask = (1u << core_id_shift) - 1; /* - * Determine whether any threading flags are - * necessry. + * Assign CPU IDs to local APIC IDs and disable any CPUs + * beyond MAXCPU. CPU 0 is always assigned to the BSP. */ - topo_probe(); - if (cpu_logical > 1 && hyperthreading_cpus) - cg_flags = CG_FLAG_HTT; - else if (cpu_logical > 1) - cg_flags = CG_FLAG_SMT; + mp_ncpus = 0; + TOPO_FOREACH(node, &topo_root) { + if (node->type != TOPO_TYPE_PU) + continue; + + if ((node->hwid & smt_mask) != (boot_cpu_id & smt_mask)) + cpu_info[node->hwid].cpu_hyperthread = 1; + + if (resource_disabled("lapic", node->hwid)) { + if (node->hwid != boot_cpu_id) + cpu_info[node->hwid].cpu_disabled = 1; + else + printf("Cannot disable BSP, APIC ID = %d\n", + node->hwid); + } + + if (!hyperthreading_allowed && + cpu_info[node->hwid].cpu_hyperthread) + cpu_info[node->hwid].cpu_disabled = 1; + + if (mp_ncpus >= MAXCPU) + cpu_info[node->hwid].cpu_disabled = 1; + + if (cpu_info[node->hwid].cpu_disabled) { + disabled_cpus++; + continue; + } + + cpu_apic_ids[mp_ncpus] = node->hwid; + apic_cpuids[node->hwid] = mp_ncpus; + topo_set_pu_id(node, mp_ncpus); + mp_ncpus++; + } + + KASSERT(mp_maxid >= mp_ncpus - 1, + ("%s: counters out of sync: max %d, count %d", __func__, mp_maxid, + mp_ncpus)); +} + +/* + * Print various information about the SMP system hardware and setup. + */ +void +cpu_mp_announce(void) +{ + struct topo_node *node; + const char *hyperthread; + int pkg_count; + int cores_per_pkg; + int thrs_per_core; + + printf("FreeBSD/SMP: "); + if (topo_analyze(&topo_root, 1, &pkg_count, + &cores_per_pkg, &thrs_per_core)) { + printf("%d package(s)", pkg_count); + if (cores_per_pkg > 0) + printf(" x %d core(s)", cores_per_pkg); + if (thrs_per_core > 1) + printf(" x %d hardware threads", thrs_per_core); + } else { + printf("Non-uniform topology"); + } + printf("\n"); + + if (disabled_cpus) { + printf("FreeBSD/SMP Online: "); + if (topo_analyze(&topo_root, 0, &pkg_count, + &cores_per_pkg, &thrs_per_core)) { + printf("%d package(s)", pkg_count); + if (cores_per_pkg > 0) + printf(" x %d core(s)", cores_per_pkg); + if (thrs_per_core > 1) + printf(" x %d hardware threads", thrs_per_core); + } else { + printf("Non-uniform topology"); + } + printf("\n"); + } + + if (!bootverbose) + return; + + TOPO_FOREACH(node, &topo_root) { + switch (node->type) { + case TOPO_TYPE_PKG: + printf("Package HW ID = %u (%#x)\n", + node->hwid, node->hwid); + break; + case TOPO_TYPE_CORE: + printf("\tCore HW ID = %u (%#x)\n", *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** From owner-freebsd-current@freebsd.org Mon Apr 4 18:42: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 A75FFB03106 for ; Mon, 4 Apr 2016 18:42:16 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 6C5881B24 for ; Mon, 4 Apr 2016 18:42:16 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: by mail-vk0-x234.google.com with SMTP id c4so66435591vkb.3 for ; Mon, 04 Apr 2016 11:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brilliantservice-co-jp.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=QlmRvRmOHt9x7cXFZ0oHqrlTCxKFrzMU6yyi/l6UAfg=; b=Pw9akhwCVJeyfUVWkbZHwBmqGEuV7Os5huSoU5LKEed4MwYJYDdbQktGVda28jhtEf K/z0K6kxs8mE9OsL08QiGO79HPyaXTIjVonxZypz87puZQ8D63zRzfGuVe3aOWaNF+XW Ug6AyEVpn/JhHuXVODv9VwJ9cN5MR+E+CBx98FuOdyPBq/OLZguaJ5QWbCLv7paOfcnX tK8mTf9aRco5yhIYhX9+oQuh2Ue504Uj4lQrIeGfoLwQ7C+cE73YNyxfZFLVSni4jXRR Vp5dI2WOV0rTdlDmhCeis0b22unI3XxO425hs19ji7cI5eCq2NUa1veAaDFjc4PKG3Cq boxA== 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=QlmRvRmOHt9x7cXFZ0oHqrlTCxKFrzMU6yyi/l6UAfg=; b=PhhgPhTYsZWILAgCYGx7sWbjNm5ljeYf4GCDxB8mluLq6v0VnYku+50meuys4iXwXq ELZax9Uc64MJIm7rccKmdJiF1M2D9dnXQDaNmfqiK4/LO9Gp1DCIYQwYqnA9/s9VmfQ0 Z6W1favF43hPaqEBo2rl9Qr4kOpFCTlAYgTldpcLQAlXXyalCw/jJPz5zBdvNBZTZPfX 8RknTsA8BAauwYB9MElbiGLBxy5ZKukW8BCnLKxUAyh/hBys1Hq81j9qYhoBLEmmd/Ad sdWSCzkjWOFAUoo3WnCVOxA3XNnSerHbWjvcbC5+SXL2zZQNuVkbgrngT75XdShfY6SC N5Sw== X-Gm-Message-State: AD7BkJIYtIutn9RCOXelfWD/bwDC0RINTmoYclxiKS/EzecSrSfNXpld6IEXMcTj/NMfiaELUctIIhcnDFrbDI3ko+XA25yJOAB4ddQv43th1MdQe2LLjuRhTsoMKbZZHrWo6FTH2ODrITNvD0SNYZ/zXKA= X-Received: by 10.176.6.2 with SMTP id f2mr7034429uaf.94.1459795335261; Mon, 04 Apr 2016 11:42:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.36.136 with HTTP; Mon, 4 Apr 2016 11:42:00 -0700 (PDT) From: "Lundberg, Johannes" Date: Mon, 4 Apr 2016 11:42:00 -0700 Message-ID: Subject: EGL driver for vt? To: "freebsd-x11@freebsd.org" , FreeBSD Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 04 Apr 2016 18:42:16 -0000 SGkNCg0KV291bGQgYW55b25lIGJlIGludGVyZXN0ZWQgaW4gYW4gTWVzYS9FR0wgZHJpdmVyIGZv ciB2dD8NCg0KSWYgd2UgaGFkIHRoaXMgd2UgY291bGQgcnVuIHdheWxhbmQvZWdsLWJhc2VkIGNv bXBvc2l0b3JzIHdpdGggbGx2bXBpcGUgb24NCnBsYXRmb3JtcyB3aXRob3V0IEdQVSBzdXBwb3J0 IHNpbWlsYXIgdG8gWCtzY2ZiIGRyaXZlci4gKGlmIG15DQp1bmRlcnN0YW5kaW5nIG9mIHRoZSBn cmFwaGljcyBzdGFjayBpZiBjb3JyZWN0Li4pDQoNCklmIHNpbWlsYXIgdG8gdGhlIChub3cgZGVw cmVjYXRlZCkgTGludXggZnJhbWVidWZmZXIgZHJpdmVyIGluIE1lc2EgSSBndWVzcw0KaXQgd291 bGQgbm90IGJlIHRoYXQgbXVjaCB3b3JrIHRoYXQgaGFzIHRvIGJlIGRvbmUuIG1lc2EvbGx2bXBp cGUgd291bGQgZG8NCmFsbCB0aGUgaGVhdnkgbGlmdGluZywgY29ycmVjdD8NCg0KVGhpcyB3b3Vs ZCBlbmFibGUgYSB3aG9sZSBsb3Qgb2YgbmV3IGV4Y2l0aW5nIHBvc3NpYmlsaXRpZXMgYW5kIHNv bHZlIHRoZQ0KcHJvYmxlbSB3aXRoIGxhY2sgb2YgR1BVIGRyaXZlcnMuLg0KDQpXaGF0IGRvIHlv dSB0aGluaz8NCgotLSAKPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0t PS09LT0tPS09LT0tCuenmOWvhuS/neaMgeOBq+OBpOOBhOOBpu+8muOBk+OBrumbu+WtkOODoeOD vOODq+OBr+OAgeWQjeWum+S6uuOBq+mAgeS/oeOBl+OBn+OCguOBruOBp+OBguOCiuOAgeenmOWM v+eJueaoqeOBruWvvuixoeOBqOOBquOCi+aDheWgseOCkuWQq+OCk+OBp+OBhOOBvuOBmeOAggrj goLjgZfjgIHlkI3lrpvkurrku6XlpJbjga7mlrnjgYzlj5fkv6HjgZXjgozjgZ/loLTlkIjjgIHj gZPjga7jg6Hjg7zjg6vjga7noLTmo4TjgIHjgYrjgojjgbPjgZPjga7jg6Hjg7zjg6vjgavplqLj gZnjgovkuIDliIfjga7plovnpLrjgIEK6KSH5YaZ44CB6YWN5biD44CB44Gd44Gu5LuW44Gu5Yip 55So44CB44G+44Gf44Gv6KiY6LyJ5YaF5a6544Gr5Z+644Gl44GP44GE44GL44Gq44KL6KGM5YuV 44KC44GV44KM44Gq44GE44KI44GG44GK6aGY44GE55Sz44GX5LiK44GS44G+44GZ44CCCi0tLQpD T05GSURFTlRJQUxJVFkgTk9URTogVGhlIGluZm9ybWF0aW9uIGluIHRoaXMgZW1haWwgaXMgY29u ZmlkZW50aWFsCmFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUuCkRpc2Nsb3N1 cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciBhbnkgb3RoZXIgYWN0aW9uIG9mIHVzZSBvZiB0 aGlzCmVtYWlsIGJ5IHBlcnNvbiBvdGhlciB0aGFuIGludGVuZGVkIHJlY2lwaWVudCwgaXMgcHJv aGliaXRlZC4KSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBhbmQgaGF2ZSBy ZWNlaXZlZCB0aGlzIGVtYWlsIGluCmVycm9yLCBwbGVhc2UgZGVzdHJveSB0aGUgb3JpZ2luYWwg bWVzc2FnZS4K From owner-freebsd-current@freebsd.org Mon Apr 4 22:53: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 E6453B037AA for ; Mon, 4 Apr 2016 22:53:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.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 C7851143B for ; Mon, 4 Apr 2016 22:53:41 +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 bigwig.baldwin.cx (Postfix) with ESMTPSA id 8BE74B95D; Mon, 4 Apr 2016 18:53:40 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Cc: Konstantin Belousov , Ryan Stone Subject: Re: accessing a PCIe register from userspace through kmem or other ways ? Date: Mon, 04 Apr 2016 15:45:07 -0700 Message-ID: <9376230.YZMFsgSvTf@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20160401170458.GV1741@kib.kiev.ua> References: <20160401170458.GV1741@kib.kiev.ua> 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.2.7 (bigwig.baldwin.cx); Mon, 04 Apr 2016 18:53:40 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 04 Apr 2016 22:53:42 -0000 On Friday, April 01, 2016 08:04:58 PM Konstantin Belousov wrote: > On Fri, Apr 01, 2016 at 12:48:24PM -0400, Ryan Stone wrote: > > That is actually a really good question. I know that with some recent > > BIOSes if I enabled allocating 64-bit addresses to BARs, the BAR would > > actually be mapped outside of the range of /dev/mem. From a quick glance > > at libpciaccess, I don't think that it handles this case. A specific > > mechanism for allowing mmaping of BARs would be useful, I think. > > I am not sure what do you mean by 'outside of the range of /dev/mem'. > IMO /dev/mem (not kmem) handles every possible physical address both > for mmap(2) and for read(2)/write(2). For io interface there were > some bugs, but they are believed to be fixed. I mean amd64. I suspect Ryan might be referring to BARs outside of the DMAP which we only populate to Maxmem IIRC. /dev/mem should work for those. However, another question is how to deal with systems that do bus address translation (like the arm64 ThunderX boxes) where the values in the PCI BAR are not CPU physical addresses. To do this properly we may need some sort of bus method akin to my bus_map_resource() WIP but one that instead returns a suitable 'struct sglist' for a given 'struct resource *' that can be used with OBJT_SG to build a VM object to use for the mapping. (At some point I do think I would like a variant of OBJT_SG that used managed pages so that mappings could be revoked when whatever is backing the sglist is disabled (e.g. the device is ejected or the BAR is relocated, etc.).) -- John Baldwin From owner-freebsd-current@freebsd.org Tue Apr 5 00:58: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 F344DB01C56 for ; Tue, 5 Apr 2016 00:58:47 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::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 BD925156C; Tue, 5 Apr 2016 00:58:47 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mail-ig0-x233.google.com with SMTP id kb1so8126630igb.0; Mon, 04 Apr 2016 17:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=9fFGQl36PdBksJO2b9RlKtESnhmQrRe/OIJbmJ8u93g=; b=ytF8TsCHu8nTQszEUVD20g8cHkdEQHYtBI3IgNsKuNt08vosjkv2TeNzC5tHyxoO5p G1dJUZa14gFtoBuMM6jHQdnxl5/GJG8ymoahamxfsxScnOgMUQRxbXNhlU7IFuJjT8bI ZPPTZs1Fjoes4ClwKzPF1BQFw9NaVvsY4ogNSFSjA5us5vBWPVQ4wtsKWAl3UMHEeSV7 rRApdA7UsAQCcgruSitsoWVMPOfS0Hmopn6bLkytIlePFEvn0H32dfYcuueHz5XJhh1M Y30OVJJ3tozQIs/4VNAgBV75WfyBV1+70/dNwqGl/BrAlOKNefk8EufpJpprkddp+AuB Y/eQ== 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:date :message-id:subject:from:to:cc; bh=9fFGQl36PdBksJO2b9RlKtESnhmQrRe/OIJbmJ8u93g=; b=k3X36ZzGJvYUnD5qvfx6CrxABLVjp/ZBzrdla+MkRbBG2bL+p12O0D4gdh/0UcO99p jmFcrgRUV4+LXvXcomMl7Qh13NU/fhSIjkbk7t+o3dhEfyvwIsfGvW/OMiB0Nrm2k46o 7JIgmPr1ZxR5GNtacaxfTanOCbGmLf8hQSsaE2i54aDtLuvXnJcF20Pe0XHCSXV3S0MD DbT9M4TnglC6wDQY/Um8ETnKvJ+fUg/a71/m4Gfwfh8Byci8lSYoonGX24olQNHoF010 gvSvPo2teCLCa5/EEK5V+vdwf9lQJA5C/vz/b42lFNuk120pj6nR4j1yP3yRuWjp0kLr inJg== X-Gm-Message-State: AD7BkJI5/9MabqX+6B2/auI8Rmd+s/ezNV2r5CanZeMjli2V9vm49SFbA/hhwxLasCfBALpKaNWzBnkUBs4ywQ== MIME-Version: 1.0 X-Received: by 10.50.66.132 with SMTP id f4mr6242951igt.83.1459817927125; Mon, 04 Apr 2016 17:58:47 -0700 (PDT) Received: by 10.107.153.206 with HTTP; Mon, 4 Apr 2016 17:58:47 -0700 (PDT) In-Reply-To: <9376230.YZMFsgSvTf@ralph.baldwin.cx> References: <20160401170458.GV1741@kib.kiev.ua> <9376230.YZMFsgSvTf@ralph.baldwin.cx> Date: Mon, 4 Apr 2016 20:58:47 -0400 Message-ID: Subject: Re: accessing a PCIe register from userspace through kmem or other ways ? From: Ryan Stone To: John Baldwin Cc: FreeBSD Current , Konstantin Belousov Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 05 Apr 2016 00:58:48 -0000 On Mon, Apr 4, 2016 at 6:45 PM, John Baldwin wrote: > I suspect Ryan might be referring to BARs outside of the DMAP which we > only populate to Maxmem IIRC. /dev/mem should work for those. > Unfortunately I no longer have access to the systems so I can't really confirm. I had a debug tool that attempted to read PCI device registers through /dev/mem, and on these systems (which were running a 8.2 derivative) the reads from /dev/mem failed with some kind of error. The one detail that I do remember is that the errors started happening after we enabled the use of 64-bit BARs in the BIOS and the addresses assigned to the BARs were quite large -- I believe well beyond the bounds of real memory. From owner-freebsd-current@freebsd.org Tue Apr 5 04:03: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 646C8ADE9CA for ; Tue, 5 Apr 2016 04:03:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.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 44D721AA2 for ; Tue, 5 Apr 2016 04:03:13 +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 bigwig.baldwin.cx (Postfix) with ESMTPSA id AB937B972; Tue, 5 Apr 2016 00:03:11 -0400 (EDT) From: John Baldwin To: Ryan Stone Cc: FreeBSD Current , Konstantin Belousov Subject: Re: accessing a PCIe register from userspace through kmem or other ways ? Date: Mon, 04 Apr 2016 21:02:49 -0700 Message-ID: <5009932.qXoZ6E4rhX@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: References: <9376230.YZMFsgSvTf@ralph.baldwin.cx> 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.2.7 (bigwig.baldwin.cx); Tue, 05 Apr 2016 00:03:11 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 05 Apr 2016 04:03:13 -0000 On Monday, April 04, 2016 08:58:47 PM Ryan Stone wrote: > On Mon, Apr 4, 2016 at 6:45 PM, John Baldwin wrote: > > > I suspect Ryan might be referring to BARs outside of the DMAP which we > > only populate to Maxmem IIRC. /dev/mem should work for those. > > > > Unfortunately I no longer have access to the systems so I can't really > confirm. I had a debug tool that attempted to read PCI device registers > through /dev/mem, and on these systems (which were running a 8.2 > derivative) the reads from /dev/mem failed with some kind of error. > > The one detail that I do remember is that the errors started happening > after we enabled the use of 64-bit BARs in the BIOS and the addresses > assigned to the BARs were quite large -- I believe well beyond the bounds > of real memory. kib@ fixed /dev/mem to handle addresses beyond the direct map limit to use temporary mappings instead of failing with EFAULT in 277051 which was only committed to HEAD last January, so well after 8.2. -- John Baldwin From owner-freebsd-current@freebsd.org Tue Apr 5 04:22: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 E3A73B030BB for ; Tue, 5 Apr 2016 04:22:31 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 95FBF11B0 for ; Tue, 5 Apr 2016 04:22:31 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.15.2/8.15.2) with ESMTPS id u354MUW5029022 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 4 Apr 2016 22:22:30 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.15.2/8.15.2/Submit) with ESMTP id u354MUfZ029019 for ; Mon, 4 Apr 2016 22:22:30 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Mon, 4 Apr 2016 22:22:30 -0600 (MDT) From: Warren Block To: freebsd-current@FreeBSD.org Subject: D3702: add support for Bluetooth Magic Mouse Message-ID: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Mon, 04 Apr 2016 22:22:30 -0600 (MDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 05 Apr 2016 04:22:32 -0000 Is anyone working on Bluetooth stuff? https://reviews.freebsd.org/D3702 adds support for the Apple Magic Mouse, and has been tested and reported working: https://lists.freebsd.org/pipermail/freebsd-bluetooth/2016-April/002053.html Could someone please review and commit this? Thanks! From owner-freebsd-current@freebsd.org Tue Apr 5 06:10: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 E0520B01939 for ; Tue, 5 Apr 2016 06:10:18 +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 78D5714CB; Tue, 5 Apr 2016 06:10:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u356ADHJ070848 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 5 Apr 2016 09:10:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u356ADHJ070848 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u356ADbl070846; Tue, 5 Apr 2016 09:10:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 5 Apr 2016 09:10:13 +0300 From: Konstantin Belousov To: John Baldwin Cc: Ryan Stone , FreeBSD Current Subject: Re: accessing a PCIe register from userspace through kmem or other ways ? Message-ID: <20160405061013.GE1741@kib.kiev.ua> References: <9376230.YZMFsgSvTf@ralph.baldwin.cx> <5009932.qXoZ6E4rhX@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5009932.qXoZ6E4rhX@ralph.baldwin.cx> User-Agent: Mutt/1.5.24 (2015-08-30) 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.21 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, 05 Apr 2016 06:10:19 -0000 On Mon, Apr 04, 2016 at 09:02:49PM -0700, John Baldwin wrote: > kib@ fixed /dev/mem to handle addresses beyond the direct map limit to use > temporary mappings instead of failing with EFAULT in 277051 which was only > committed to HEAD last January, so well after 8.2. The mmap(2) interface to /dev/mem did not have the issue ever. The problem was only with the read(2)/write(2) accesses. >From what I understand, since the goal of the OP was to measure BAR access latencies, read(2) (or write) is unsuitable for him for obvious reasons. From owner-freebsd-current@freebsd.org Tue Apr 5 06:14:36 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 3096FB01B72 for ; Tue, 5 Apr 2016 06:14:36 +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 A498818DA; Tue, 5 Apr 2016 06:14:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u356EVaq071493 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 5 Apr 2016 09:14:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u356EVaq071493 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u356EVpd071492; Tue, 5 Apr 2016 09:14:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 5 Apr 2016 09:14:31 +0300 From: Konstantin Belousov To: John Baldwin Cc: freebsd-current@freebsd.org, Ryan Stone Subject: Re: accessing a PCIe register from userspace through kmem or other ways ? Message-ID: <20160405061431.GF1741@kib.kiev.ua> References: <20160401170458.GV1741@kib.kiev.ua> <9376230.YZMFsgSvTf@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9376230.YZMFsgSvTf@ralph.baldwin.cx> User-Agent: Mutt/1.5.24 (2015-08-30) 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.21 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, 05 Apr 2016 06:14:36 -0000 On Mon, Apr 04, 2016 at 03:45:07PM -0700, John Baldwin wrote: > However, another question is how to deal with systems that do bus address > translation (like the arm64 ThunderX boxes) where the values in the PCI > BAR are not CPU physical addresses. To do this properly we may need some > sort of bus method akin to my bus_map_resource() WIP but one that instead > returns a suitable 'struct sglist' for a given 'struct resource *' that > can be used with OBJT_SG to build a VM object to use for the mapping. Is there any documentation on the ThunderX PCI access mechanisms ? > > (At some point I do think I would like a variant of OBJT_SG that used > managed pages so that mappings could be revoked when whatever is backing > the sglist is disabled (e.g. the device is ejected or the BAR is > relocated, etc.).) Why cannot you use MGTDEVICE pager already ? Driver would need to maintain its private list of pages, and from this PoV, a convenience wrapper around MGTDEVICE which unifies operations on sg lists could be useful. Still, it could be that the wrapper appear to be single-purpose. From owner-freebsd-current@freebsd.org Tue Apr 5 06:21: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 D3652B01CB0 for ; Tue, 5 Apr 2016 06:21:04 +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 951691AEA; Tue, 5 Apr 2016 06:21:04 +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 <1anKM8-002VII-2l>; Tue, 05 Apr 2016 08:20:52 +0200 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=freyja.zeit4.iv.bundesimmobilien.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (envelope-from ) id <1anKM7-001OFT-ND>; Tue, 05 Apr 2016 08:20:51 +0200 Date: Tue, 5 Apr 2016 08:20:47 +0200 From: "O. Hartmann" To: Cy Schubert Cc: Michael Butler , "K. Macy" , FreeBSD CURRENT Subject: Re: CURRENT slow and shaky network stability Message-ID: <20160405082047.670d7241@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <201604022314.u32NEvgs067448@slippy.cwsent.com> References: <20160402231955.41b05526.ohartman@zedat.fu-berlin.de> <201604022314.u32NEvgs067448@slippy.cwsent.com> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 87.138.105.249 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 05 Apr 2016 06:21:04 -0000 On Sat, 02 Apr 2016 16:14:57 -0700 Cy Schubert wrote: > In message <20160402231955.41b05526.ohartman@zedat.fu-berlin.de>, "O. > Hartmann" > writes: > > --Sig_/eJJPtbrEuK1nN2zIpc7BmVr > > Content-Type: text/plain; charset=US-ASCII > > Content-Transfer-Encoding: quoted-printable > > > > Am Sat, 2 Apr 2016 11:39:10 +0200 > > "O. Hartmann" schrieb: > > > > > Am Sat, 2 Apr 2016 10:55:03 +0200 > > > "O. Hartmann" schrieb: > > >=20 > > > > Am Sat, 02 Apr 2016 01:07:55 -0700 > > > > Cy Schubert schrieb: > > > > =20 > > > > > In message <56F6C6B0.6010103@protected-networks.net>, Michael Butler > > > > > = > > writes: =20 > > > > > > -current is not great for interactive use at all. The strategy of > > > > > > pre-emptively dropping idle processes to swap is hurting .. big > > > > > > tim= > > e. =20 > > > > >=20 > > > > > FreeBSD doesn't "preemptively" or arbitrarily push pages out to > > > > > disk.= > > LRU=20 > > > > > doesn't do this. > > > > > =20 > > > > > >=20 > > > > > > Compare inactive memory to swap in this example .. > > > > > >=20 > > > > > > 110 processes: 1 running, 108 sleeping, 1 zombie > > > > > > CPU: 1.2% user, 0.0% nice, 4.3% system, 0.0% interrupt, 94.5% > > > > > > i= > > dle > > > > > > Mem: 474M Active, 1609M Inact, 764M Wired, 281M Buf, 119M Free > > > > > > Swap: 4096M Total, 917M Used, 3178M Free, 22% Inuse =20 > > > > >=20 > > > > > To analyze this you need to capture vmstat output. You'll see the > > > > > fre= > > e pool=20 > > > > > dip below a threshold and pages go out to disk in response. If you > > > > > ha= > > ve=20 > > > > > daemons with small working sets, pages that are not part of the > > > > > worki= > > ng=20 > > > > > sets for daemons or applications will eventually be paged out. This > > > > > i= > > s not=20 > > > > > a bad thing. In your example above, the 281 MB of UFS buffers are > > > > > mor= > > e=20 > > > > > active than the 917 MB paged out. If it's paged out and never used > > > > > ag= > > ain,=20 > > > > > then it doesn't hurt. However the 281 MB of buffers saves you I/O. > > > > > Th= > > e=20 > > > > > inactive pages are part of your free pool that were active at one > > > > > tim= > > e but=20 > > > > > now are not. They may be reclaimed and if they are, you've just > > > > > saved= > > more=20 > > > > > I/O. > > > > >=20 > > > > > Top is a poor tool to analyze memory use. Vmstat is the better tool > > > > > t= > > o help=20 > > > > > understand memory use. Inactive memory isn't a bad thing per se. > > > > > Moni= > > tor=20 > > > > > page outs, scan rate and page reclaims. > > > > >=20 > > > > > =20 > > > >=20 > > > > I give up! Tried to check via ssh/vmstat what is going on. Last lines > > > > b= > > efore broken > > > > pipe: > > > >=20 > > > > [...] > > > > procs memory page disks faults cpu > > > > r b w avm fre flt re pi po fr sr ad0 ad1 in sy cs > > > > = > > us sy id > > > > 22 0 22 5.8G 1.0G 46319 0 0 0 55721 1297 0 4 219 23907 > > > > 540= > > 0 95 5 0 > > > > 22 0 22 5.4G 1.3G 51733 0 0 0 72436 1162 0 0 108 40869 > > > > 345= > > 9 93 7 0 > > > > 15 0 22 12G 1.2G 54400 0 27 0 52188 1160 0 42 148 52192 > > > > 436= > > 6 91 9 0 > > > > 14 0 22 12G 1.0G 44954 0 37 0 37550 1179 0 39 141 86209 > > > > 436= > > 8 88 12 0 > > > > 26 0 22 12G 1.1G 60258 0 81 0 69459 1119 0 27 123 779569 > > > > 704= > > 359 87 13 0 > > > > 29 3 22 13G 774M 50576 0 68 0 32204 1304 0 2 102 507337 > > > > 484= > > 861 93 7 0 > > > > 27 0 22 13G 937M 47477 0 48 0 59458 1264 3 2 112 68131 > > > > 4440= > > 7 95 5 0 > > > > 36 0 22 13G 829M 83164 0 2 0 82575 1225 1 0 126 99366 > > > > 3806= > > 0 89 11 0 > > > > 35 0 22 6.2G 1.1G 98803 0 13 0 121375 1217 2 8 112 99371 > > > > 49= > > 99 85 15 0 > > > > 34 0 22 13G 723M 54436 0 20 0 36952 1276 0 17 153 29142 > > > > 443= > > 1 95 5 0 > > > > Fssh_packet_write_wait: Connection to 192.168.0.1 port 22: Broken pipe > > > >=20 > > > >=20 > > > > This makes this crap system completely unusable. The server (FreeBSD > > > > 11= > > .0-CURRENT #20 > > > > r297503: Sat Apr 2 09:02:41 CEST 2016 amd64) in question did > > > > poudriere= > > bulk job. I > > > > can not even determine what terminal goes down first - another one, > > > > muc= > > h more time > > > > idle than the one shwoing the "vmstat 5" output, is still alive!=20 > > > >=20 > > > > i consider this a serious bug and it is no benefit what happened since > > > > = > > this "fancy" > > > > update. :-( =20 > > >=20 > > > By the way - it might be of interest and some hint. > > >=20 > > > One of my boxes is acting as server and gateway. It utilises NAT, IPFW, > > > w= > > hen it is under > > > high load, as it was today, sometimes passing the network flow from ISP > > > i= > > nto the network > > > for clients is extremely slow. I do not consider this the reason for > > > coll= > > apsing ssh > > > sessions, since this incident happens also under no-load, but in the > > > over= > > all-view onto > > > the problem, this could be a hint - I hope.=20 > > > > I just checked on one box, that "broke pipe" very quickly after I started p= > > oudriere, > > while it did well a couple of hours before until the pipe broke. It seems i= > > t's load > > dependend when the ssh session gets wrecked, but more important, after the = > > long-haul > > poudriere run, I rebooted the box and tried again with the mentioned broken= > > pipe after a > > couple of minutes after poudriere ran. Then I left the box for several hour= > > s and logged > > in again and checked the swap. Although there was for hours no load or othe= > > r pressure, > > there were 31% of of swap used - still (box has 16 GB of RAM and is propell= > > ed by a XEON > > E3-1245 V2). > > > > 31%! Is it *actively* paging or is the 31% previously paged out and no > paging is *currently* being experienced? 31% of how swap space in total? > > Also, what does ps aumx or ps aumxww say? Pipe it to head -40 or similar. > > On FreeBSD 11.0-CURRENT #4 r297573: Tue Apr 5 07:01:19 CEST 2016 amd64, local network, no NAT. Stuck ssh session in the middle of administering and leaving the console/ssh session for a couple of minutes: root 2064 0.0 0.1 91416 8492 - Is 07:18 0:00.03 sshd: hartmann [priv] (sshd) hartmann 2108 0.0 0.1 91416 8664 - I 07:18 0:07.33 sshd: hartmann@pts/0 (sshd) root 72961 0.0 0.1 91416 8496 - Is 08:11 0:00.03 sshd: hartmann [priv] (sshd) hartmann 72970 0.0 0.1 91416 8564 - S 08:11 0:00.02 sshd: hartmann@pts/1 (sshd) The situation is worse and i consider this a serious bug. From owner-freebsd-current@freebsd.org Tue Apr 5 06:46: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 5C133B034AD for ; Tue, 5 Apr 2016 06:46:20 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2734116FD; Tue, 5 Apr 2016 06:46:19 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id nKkcatdHDQeymnKkdaXUxY; Tue, 05 Apr 2016 00:46:13 -0600 X-Authority-Analysis: v=2.2 cv=H9KZ+KQi c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kziv93cY1bsA:10 a=BWvPGDcYAAAA:8 a=zxA2vyXaAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=ij63hNtKrUkdOZeuT7AA:9 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 0A3EC13751; Mon, 4 Apr 2016 23:46:10 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id u356k850078565; Mon, 4 Apr 2016 23:46:08 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201604050646.u356k850078565@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: "O. Hartmann" cc: Cy Schubert , Michael Butler , "K. Macy" , FreeBSD CURRENT Subject: Re: CURRENT slow and shaky network stability In-Reply-To: Message from "O. Hartmann" of "Tue, 05 Apr 2016 08:20:47 +0200." <20160405082047.670d7241@freyja.zeit4.iv.bundesimmobilien.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Apr 2016 23:46:08 -0700 X-CMAE-Envelope: MS4wfOb0/5zKoeB4Dsa9fLix6RAQLwEXPHPhyjM2N65be73d0ej5CwfS7irXDOvLjbxuqTjO0lEWT23YnmLDU43Zp1jHTQ73I/Edfw4Or+F4VkZ1cxXze8DU VMqjuLVLObAs/jnm9xPP8fszP4yRbHX6K5463Ac+L/mZn6BqmMNGq1CukNTc8+1Wp2zsL+2t2abds7005OUcriHe7EuNJ0thFM1uvotWuVj57J9dXWYR218B qOCijtFnZ9dE3igVIEF6d9/WVDqvkCwLCV6C68++JFMrKqhryLtR/WfQgmu0YRA8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 05 Apr 2016 06:46:20 -0000 In message <20160405082047.670d7241@freyja.zeit4.iv.bundesimmobilien.de>, "O. H artmann" writes: > On Sat, 02 Apr 2016 16:14:57 -0700 > Cy Schubert wrote: > > > In message <20160402231955.41b05526.ohartman@zedat.fu-berlin.de>, "O. > > Hartmann" > > writes: > > > --Sig_/eJJPtbrEuK1nN2zIpc7BmVr > > > Content-Type: text/plain; charset=US-ASCII > > > Content-Transfer-Encoding: quoted-printable > > > > > > Am Sat, 2 Apr 2016 11:39:10 +0200 > > > "O. Hartmann" schrieb: > > > > > > > Am Sat, 2 Apr 2016 10:55:03 +0200 > > > > "O. Hartmann" schrieb: > > > >=20 > > > > > Am Sat, 02 Apr 2016 01:07:55 -0700 > > > > > Cy Schubert schrieb: > > > > > =20 > > > > > > In message <56F6C6B0.6010103@protected-networks.net>, Michael Butle > r > > > > > > = > > > writes: =20 > > > > > > > -current is not great for interactive use at all. The strategy of > > > > > > > pre-emptively dropping idle processes to swap is hurting .. big > > > > > > > tim= > > > e. =20 > > > > > >=20 > > > > > > FreeBSD doesn't "preemptively" or arbitrarily push pages out to > > > > > > disk.= > > > LRU=20 > > > > > > doesn't do this. > > > > > > =20 > > > > > > >=20 > > > > > > > Compare inactive memory to swap in this example .. > > > > > > >=20 > > > > > > > 110 processes: 1 running, 108 sleeping, 1 zombie > > > > > > > CPU: 1.2% user, 0.0% nice, 4.3% system, 0.0% interrupt, 94.5% > > > > > > > i= > > > dle > > > > > > > Mem: 474M Active, 1609M Inact, 764M Wired, 281M Buf, 119M Free > > > > > > > Swap: 4096M Total, 917M Used, 3178M Free, 22% Inuse =20 > > > > > >=20 > > > > > > To analyze this you need to capture vmstat output. You'll see the > > > > > > fre= > > > e pool=20 > > > > > > dip below a threshold and pages go out to disk in response. If you > > > > > > ha= > > > ve=20 > > > > > > daemons with small working sets, pages that are not part of the > > > > > > worki= > > > ng=20 > > > > > > sets for daemons or applications will eventually be paged out. This > > > > > > i= > > > s not=20 > > > > > > a bad thing. In your example above, the 281 MB of UFS buffers are > > > > > > mor= > > > e=20 > > > > > > active than the 917 MB paged out. If it's paged out and never used > > > > > > ag= > > > ain,=20 > > > > > > then it doesn't hurt. However the 281 MB of buffers saves you I/O. > > > > > > Th= > > > e=20 > > > > > > inactive pages are part of your free pool that were active at one > > > > > > tim= > > > e but=20 > > > > > > now are not. They may be reclaimed and if they are, you've just > > > > > > saved= > > > more=20 > > > > > > I/O. > > > > > >=20 > > > > > > Top is a poor tool to analyze memory use. Vmstat is the better tool > > > > > > t= > > > o help=20 > > > > > > understand memory use. Inactive memory isn't a bad thing per se. > > > > > > Moni= > > > tor=20 > > > > > > page outs, scan rate and page reclaims. > > > > > >=20 > > > > > > =20 > > > > >=20 > > > > > I give up! Tried to check via ssh/vmstat what is going on. Last lines > > > > > b= > > > efore broken > > > > > pipe: > > > > >=20 > > > > > [...] > > > > > procs memory page disks faults > cpu > > > > > r b w avm fre flt re pi po fr sr ad0 ad1 in sy c > s > > > > > = > > > us sy id > > > > > 22 0 22 5.8G 1.0G 46319 0 0 0 55721 1297 0 4 219 23907 > > > > > 540= > > > 0 95 5 0 > > > > > 22 0 22 5.4G 1.3G 51733 0 0 0 72436 1162 0 0 108 40869 > > > > > 345= > > > 9 93 7 0 > > > > > 15 0 22 12G 1.2G 54400 0 27 0 52188 1160 0 42 148 52192 > > > > > 436= > > > 6 91 9 0 > > > > > 14 0 22 12G 1.0G 44954 0 37 0 37550 1179 0 39 141 86209 > > > > > 436= > > > 8 88 12 0 > > > > > 26 0 22 12G 1.1G 60258 0 81 0 69459 1119 0 27 123 779569 > > > > > 704= > > > 359 87 13 0 > > > > > 29 3 22 13G 774M 50576 0 68 0 32204 1304 0 2 102 507337 > > > > > 484= > > > 861 93 7 0 > > > > > 27 0 22 13G 937M 47477 0 48 0 59458 1264 3 2 112 68131 > > > > > 4440= > > > 7 95 5 0 > > > > > 36 0 22 13G 829M 83164 0 2 0 82575 1225 1 0 126 99366 > > > > > 3806= > > > 0 89 11 0 > > > > > 35 0 22 6.2G 1.1G 98803 0 13 0 121375 1217 2 8 112 99371 > > > > > 49= > > > 99 85 15 0 > > > > > 34 0 22 13G 723M 54436 0 20 0 36952 1276 0 17 153 29142 > > > > > 443= > > > 1 95 5 0 > > > > > Fssh_packet_write_wait: Connection to 192.168.0.1 port 22: Broken pip > e > > > > >=20 > > > > >=20 > > > > > This makes this crap system completely unusable. The server (FreeBSD > > > > > 11= > > > .0-CURRENT #20 > > > > > r297503: Sat Apr 2 09:02:41 CEST 2016 amd64) in question did > > > > > poudriere= > > > bulk job. I > > > > > can not even determine what terminal goes down first - another one, > > > > > muc= > > > h more time > > > > > idle than the one shwoing the "vmstat 5" output, is still alive!=20 > > > > >=20 > > > > > i consider this a serious bug and it is no benefit what happened sinc > e > > > > > = > > > this "fancy" > > > > > update. :-( =20 > > > >=20 > > > > By the way - it might be of interest and some hint. > > > >=20 > > > > One of my boxes is acting as server and gateway. It utilises NAT, IPFW, > > > > w= > > > hen it is under > > > > high load, as it was today, sometimes passing the network flow from ISP > > > > i= > > > nto the network > > > > for clients is extremely slow. I do not consider this the reason for > > > > coll= > > > apsing ssh > > > > sessions, since this incident happens also under no-load, but in the > > > > over= > > > all-view onto > > > > the problem, this could be a hint - I hope.=20 > > > > > > I just checked on one box, that "broke pipe" very quickly after I started > p= > > > oudriere, > > > while it did well a couple of hours before until the pipe broke. It seems > i= > > > t's load > > > dependend when the ssh session gets wrecked, but more important, after th > e = > > > long-haul > > > poudriere run, I rebooted the box and tried again with the mentioned brok > en= > > > pipe after a > > > couple of minutes after poudriere ran. Then I left the box for several ho > ur= > > > s and logged > > > in again and checked the swap. Although there was for hours no load or ot > he= > > > r pressure, > > > there were 31% of of swap used - still (box has 16 GB of RAM and is prope > ll= > > > ed by a XEON > > > E3-1245 V2). > > > > > > > 31%! Is it *actively* paging or is the 31% previously paged out and no > > paging is *currently* being experienced? 31% of how swap space in total? > > > > Also, what does ps aumx or ps aumxww say? Pipe it to head -40 or similar. > > > > > > On FreeBSD 11.0-CURRENT #4 r297573: Tue Apr 5 07:01:19 CEST 2016 amd64, loca > l > network, no NAT. Stuck ssh session in the middle of administering and leaving > the console/ssh session for a couple of minutes: > > root 2064 0.0 0.1 91416 8492 - Is 07:18 0:00.03 sshd: > hartmann [priv] (sshd) > > hartmann 2108 0.0 0.1 91416 8664 - I 07:18 0:07.33 sshd: > hartmann@pts/0 (sshd) > > root 72961 0.0 0.1 91416 8496 - Is 08:11 0:00.03 sshd: > hartmann [priv] (sshd) > > hartmann 72970 0.0 0.1 91416 8564 - S 08:11 0:00.02 sshd: > hartmann@pts/1 (sshd) > > The situation is worse and i consider this a serious bug. > There's not a lot to go on here. Do you have physical access to the machine to pop into DDB and take a look? You did say you're using a lot of swap. IIRC 30%. You didn't answer how much 30% was of. Without more data I can't help you. At the best I can take wild guesses but that won't help you. Try to answer the questions I asked last week and we can go further. Until then all we can do is wildly guess. -- Cheers, Cy Schubert or FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Tue Apr 5 07:27:15 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 B28DCB03213 for ; Tue, 5 Apr 2016 07:27:15 +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 7703D1A8D for ; Tue, 5 Apr 2016 07:27:14 +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 <1anLOL-002oIn-57>; Tue, 05 Apr 2016 09:27:13 +0200 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=freyja.zeit4.iv.bundesimmobilien.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (envelope-from ) id <1anLOK-001TsM-Pg>; Tue, 05 Apr 2016 09:27:13 +0200 Date: Tue, 5 Apr 2016 09:27:12 +0200 From: "O. Hartmann" To: freebsd-current@freebsd.org Subject: Re: CURRENT slow and shaky network stability Message-ID: <20160405092712.131ee52c@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <201604050646.u356k850078565@slippy.cwsent.com> References: <20160405082047.670d7241@freyja.zeit4.iv.bundesimmobilien.de> <201604050646.u356k850078565@slippy.cwsent.com> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 87.138.105.249 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 05 Apr 2016 07:27:15 -0000 On Mon, 04 Apr 2016 23:46:08 -0700 Cy Schubert wrote: > In message <20160405082047.670d7241@freyja.zeit4.iv.bundesimmobilien.de>, > "O. H > artmann" writes: > > On Sat, 02 Apr 2016 16:14:57 -0700 > > Cy Schubert wrote: > > > > > In message <20160402231955.41b05526.ohartman@zedat.fu-berlin.de>, "O. > > > Hartmann" > > > writes: > > > > --Sig_/eJJPtbrEuK1nN2zIpc7BmVr > > > > Content-Type: text/plain; charset=US-ASCII > > > > Content-Transfer-Encoding: quoted-printable > > > > > > > > Am Sat, 2 Apr 2016 11:39:10 +0200 > > > > "O. Hartmann" schrieb: > > > > > > > > > Am Sat, 2 Apr 2016 10:55:03 +0200 > > > > > "O. Hartmann" schrieb: > > > > >=20 > > > > > > Am Sat, 02 Apr 2016 01:07:55 -0700 > > > > > > Cy Schubert schrieb: > > > > > > =20 > > > > > > > In message <56F6C6B0.6010103@protected-networks.net>, Michael > > > > > > > Butle > > r > > > > > > > = > > > > writes: =20 > > > > > > > > -current is not great for interactive use at all. The strategy > > > > > > > > of pre-emptively dropping idle processes to swap is hurting .. > > > > > > > > big tim= > > > > e. =20 > > > > > > >=20 > > > > > > > FreeBSD doesn't "preemptively" or arbitrarily push pages out to > > > > > > > disk.= > > > > LRU=20 > > > > > > > doesn't do this. > > > > > > > =20 > > > > > > > >=20 > > > > > > > > Compare inactive memory to swap in this example .. > > > > > > > >=20 > > > > > > > > 110 processes: 1 running, 108 sleeping, 1 zombie > > > > > > > > CPU: 1.2% user, 0.0% nice, 4.3% system, 0.0% interrupt, > > > > > > > > 94.5% i= > > > > dle > > > > > > > > Mem: 474M Active, 1609M Inact, 764M Wired, 281M Buf, 119M Free > > > > > > > > Swap: 4096M Total, 917M Used, 3178M Free, 22% Inuse =20 > > > > > > >=20 > > > > > > > To analyze this you need to capture vmstat output. You'll see the > > > > > > > fre= > > > > e pool=20 > > > > > > > dip below a threshold and pages go out to disk in response. If you > > > > > > > ha= > > > > ve=20 > > > > > > > daemons with small working sets, pages that are not part of the > > > > > > > worki= > > > > ng=20 > > > > > > > sets for daemons or applications will eventually be paged out. > > > > > > > This i= > > > > s not=20 > > > > > > > a bad thing. In your example above, the 281 MB of UFS buffers are > > > > > > > mor= > > > > e=20 > > > > > > > active than the 917 MB paged out. If it's paged out and never used > > > > > > > ag= > > > > ain,=20 > > > > > > > then it doesn't hurt. However the 281 MB of buffers saves you I/O. > > > > > > > Th= > > > > e=20 > > > > > > > inactive pages are part of your free pool that were active at one > > > > > > > tim= > > > > e but=20 > > > > > > > now are not. They may be reclaimed and if they are, you've just > > > > > > > saved= > > > > more=20 > > > > > > > I/O. > > > > > > >=20 > > > > > > > Top is a poor tool to analyze memory use. Vmstat is the better > > > > > > > tool t= > > > > o help=20 > > > > > > > understand memory use. Inactive memory isn't a bad thing per se. > > > > > > > Moni= > > > > tor=20 > > > > > > > page outs, scan rate and page reclaims. > > > > > > >=20 > > > > > > > =20 > > > > > >=20 > > > > > > I give up! Tried to check via ssh/vmstat what is going on. Last > > > > > > lines b= > > > > efore broken > > > > > > pipe: > > > > > >=20 > > > > > > [...] > > > > > > procs memory page disks > > > > > > faults > > cpu > > > > > > r b w avm fre flt re pi po fr sr ad0 ad1 in sy > > > > > > c > > s > > > > > > = > > > > us sy id > > > > > > 22 0 22 5.8G 1.0G 46319 0 0 0 55721 1297 0 4 219 23907 > > > > > > 540= > > > > 0 95 5 0 > > > > > > 22 0 22 5.4G 1.3G 51733 0 0 0 72436 1162 0 0 108 40869 > > > > > > 345= > > > > 9 93 7 0 > > > > > > 15 0 22 12G 1.2G 54400 0 27 0 52188 1160 0 42 148 52192 > > > > > > 436= > > > > 6 91 9 0 > > > > > > 14 0 22 12G 1.0G 44954 0 37 0 37550 1179 0 39 141 86209 > > > > > > 436= > > > > 8 88 12 0 > > > > > > 26 0 22 12G 1.1G 60258 0 81 0 69459 1119 0 27 123 779569 > > > > > > 704= > > > > 359 87 13 0 > > > > > > 29 3 22 13G 774M 50576 0 68 0 32204 1304 0 2 102 507337 > > > > > > 484= > > > > 861 93 7 0 > > > > > > 27 0 22 13G 937M 47477 0 48 0 59458 1264 3 2 112 68131 > > > > > > 4440= > > > > 7 95 5 0 > > > > > > 36 0 22 13G 829M 83164 0 2 0 82575 1225 1 0 126 99366 > > > > > > 3806= > > > > 0 89 11 0 > > > > > > 35 0 22 6.2G 1.1G 98803 0 13 0 121375 1217 2 8 112 99371 > > > > > > 49= > > > > 99 85 15 0 > > > > > > 34 0 22 13G 723M 54436 0 20 0 36952 1276 0 17 153 29142 > > > > > > 443= > > > > 1 95 5 0 > > > > > > Fssh_packet_write_wait: Connection to 192.168.0.1 port 22: Broken > > > > > > pip > > e > > > > > >=20 > > > > > >=20 > > > > > > This makes this crap system completely unusable. The server (FreeBSD > > > > > > 11= > > > > .0-CURRENT #20 > > > > > > r297503: Sat Apr 2 09:02:41 CEST 2016 amd64) in question did > > > > > > poudriere= > > > > bulk job. I > > > > > > can not even determine what terminal goes down first - another one, > > > > > > muc= > > > > h more time > > > > > > idle than the one shwoing the "vmstat 5" output, is still alive!=20 > > > > > >=20 > > > > > > i consider this a serious bug and it is no benefit what happened > > > > > > sinc > > e > > > > > > = > > > > this "fancy" > > > > > > update. :-( =20 > > > > >=20 > > > > > By the way - it might be of interest and some hint. > > > > >=20 > > > > > One of my boxes is acting as server and gateway. It utilises NAT, > > > > > IPFW, w= > > > > hen it is under > > > > > high load, as it was today, sometimes passing the network flow from > > > > > ISP i= > > > > nto the network > > > > > for clients is extremely slow. I do not consider this the reason for > > > > > coll= > > > > apsing ssh > > > > > sessions, since this incident happens also under no-load, but in the > > > > > over= > > > > all-view onto > > > > > the problem, this could be a hint - I hope.=20 > > > > > > > > I just checked on one box, that "broke pipe" very quickly after I > > > > started > > p= > > > > oudriere, > > > > while it did well a couple of hours before until the pipe broke. It > > > > seems > > i= > > > > t's load > > > > dependend when the ssh session gets wrecked, but more important, after > > > > th > > e = > > > > long-haul > > > > poudriere run, I rebooted the box and tried again with the mentioned > > > > brok > > en= > > > > pipe after a > > > > couple of minutes after poudriere ran. Then I left the box for several > > > > ho > > ur= > > > > s and logged > > > > in again and checked the swap. Although there was for hours no load or > > > > ot > > he= > > > > r pressure, > > > > there were 31% of of swap used - still (box has 16 GB of RAM and is > > > > prope > > ll= > > > > ed by a XEON > > > > E3-1245 V2). > > > > > > > > > > 31%! Is it *actively* paging or is the 31% previously paged out and no > > > paging is *currently* being experienced? 31% of how swap space in total? > > > > > > Also, what does ps aumx or ps aumxww say? Pipe it to head -40 or similar. > > > > > > > > > > On FreeBSD 11.0-CURRENT #4 r297573: Tue Apr 5 07:01:19 CEST 2016 amd64, > > loca l > > network, no NAT. Stuck ssh session in the middle of administering and > > leaving the console/ssh session for a couple of minutes: > > > > root 2064 0.0 0.1 91416 8492 - Is 07:18 0:00.03 sshd: > > hartmann [priv] (sshd) > > > > hartmann 2108 0.0 0.1 91416 8664 - I 07:18 0:07.33 sshd: > > hartmann@pts/0 (sshd) > > > > root 72961 0.0 0.1 91416 8496 - Is 08:11 0:00.03 sshd: > > hartmann [priv] (sshd) > > > > hartmann 72970 0.0 0.1 91416 8564 - S 08:11 0:00.02 sshd: > > hartmann@pts/1 (sshd) > > > > The situation is worse and i consider this a serious bug. > > > > There's not a lot to go on here. Do you have physical access to the machine > to pop into DDB and take a look? You did say you're using a lot of swap. > IIRC 30%. You didn't answer how much 30% was of. Without more data I can't > help you. At the best I can take wild guesses but that won't help you. Try > to answer the questions I asked last week and we can go further. Until then > all we can do is wildly guess. > > Hello Cy, sorry for the lack of information. The machine in question is not accessible at this very moment. The box has 16 GB of physical RAM, 32 GB of swap (on SSD) and a 4-core/8-thread CPU (I think tht is also important due to allocation of arbitrary memory). The problem I described arose when using poudriere. The box uses 6 builders, but each builder can, as I understand, spwan several instances of jobs for compiling/linking etc. But - that box is only a placeholder for the weirdness that is going on (despite the fact that it is using NAT since it is atatched to a DSL line). To the contrary, the system I face today at work is not(!) behind NAT and doesn't have the "toy" network binding. This box I'm accessing now has 16 GB of physical RAM, and two sockets, each populated with a oldish 4-core XEON 5XXX from the Core2Duo age (no SMT). That box does not run poudriere, only postgresql and some other services. In February, I was able to push the other box in question (behind NAT, as a remark) to its limits using poudriere and using 8 builders. Network became slow, since the box also acts as gateway, but it never failed, broke or dropped the ssh session due to "broken pipe". Without changing the config except the base system's sources for CURRENT, since ~ two, or at most three weeks for now I get this weird drops. And this is why I started "wining" - there is also a drop in performance when compiling world, which elongates the compiling time ~ 5 - 10 minutes on the NATed box. I'm fully aware of being on CURRENT, but I think it is considerably reasonable to report about those weird things happening now. I did not receive any word about dramatic changes that could trigger such a behaviour. And as I understand the thread we are in here, there has been made a change which results in a more aggressive swap of inactive processes. I tried to stop all services on the boxes (postgresql, icinga2, http etc) to check whether those could force the kernel to swap a process. But the loss of ssh connection and the very strange behaviour that the ssh connection gets irresponsive is eratic, which means: it comes sometimes very fast after seconds not touching the xterm/ssh from the remote box, sometimes it lasts up to 30 minutes, even on load. So, there is probably a problem with me understanding this new feature ... From owner-freebsd-current@freebsd.org Tue Apr 5 08:33:03 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 EAA4AB03E0C for ; Tue, 5 Apr 2016 08:33:03 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B70231BA4 for ; Tue, 5 Apr 2016 08:33:03 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id nMPuadhQPN9d0nMPvaqAI4; Tue, 05 Apr 2016 02:32:57 -0600 X-Authority-Analysis: v=2.2 cv=QZUkhYTv c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kziv93cY1bsA:10 a=BWvPGDcYAAAA:8 a=zxA2vyXaAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=qIeoArkkAZ8lILkxW8UA:9 a=6t4BGag4H7ou5BV-:21 a=XfSfGf8MXgAFfJ2E:21 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 6055613751; Tue, 5 Apr 2016 01:32:54 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id u358WrGk086150; Tue, 5 Apr 2016 01:32:53 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201604050832.u358WrGk086150@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: "O. Hartmann" cc: freebsd-current@freebsd.org, Cy Schubert Subject: Re: CURRENT slow and shaky network stability In-Reply-To: Message from "O. Hartmann" of "Tue, 05 Apr 2016 09:27:12 +0200." <20160405092712.131ee52c@freyja.zeit4.iv.bundesimmobilien.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 05 Apr 2016 01:32:53 -0700 X-CMAE-Envelope: MS4wfAl9NuSuqGRu2VQs6PwkTvd6mjQHkhXrxlwhEY0mT2z0yxU6WwXmlqwP71ZQbd4N+uYcCLEXvk2XbPLWr7fBTQXgGYFIQL9EMffrdj4OQwuSViRViGjl yPEqlV9YYCXdrk5ijDThrvEW8/PT4CxZP7IROj4nmdZeWYZb/slx70TBSQ4U6xX4hiJkFXBwgvOB9G8OJOAoDlUfgR9IpnRzW0/CblJQ8Z35jtVggXTdX1NQ X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 05 Apr 2016 08:33:04 -0000 In message <20160405092712.131ee52c@freyja.zeit4.iv.bundesimmobilien.de>, "O. H artmann" writes: > On Mon, 04 Apr 2016 23:46:08 -0700 > Cy Schubert wrote: > > > In message <20160405082047.670d7241@freyja.zeit4.iv.bundesimmobilien.de>, > > "O. H > > artmann" writes: > > > On Sat, 02 Apr 2016 16:14:57 -0700 > > > Cy Schubert wrote: > > > > > > > In message <20160402231955.41b05526.ohartman@zedat.fu-berlin.de>, "O. > > > > Hartmann" > > > > writes: > > > > > --Sig_/eJJPtbrEuK1nN2zIpc7BmVr > > > > > Content-Type: text/plain; charset=US-ASCII > > > > > Content-Transfer-Encoding: quoted-printable > > > > > > > > > > Am Sat, 2 Apr 2016 11:39:10 +0200 > > > > > "O. Hartmann" schrieb: > > > > > > > > > > > Am Sat, 2 Apr 2016 10:55:03 +0200 > > > > > > "O. Hartmann" schrieb: > > > > > >=20 > > > > > > > Am Sat, 02 Apr 2016 01:07:55 -0700 > > > > > > > Cy Schubert schrieb: > > > > > > > =20 > > > > > > > > In message <56F6C6B0.6010103@protected-networks.net>, Michael > > > > > > > > Butle > > > r > > > > > > > > = > > > > > writes: =20 > > > > > > > > > -current is not great for interactive use at all. The strateg > y > > > > > > > > > of pre-emptively dropping idle processes to swap is hurting . > . > > > > > > > > > big tim= > > > > > e. =20 > > > > > > > >=20 > > > > > > > > FreeBSD doesn't "preemptively" or arbitrarily push pages out to > > > > > > > > disk.= > > > > > LRU=20 > > > > > > > > doesn't do this. > > > > > > > > =20 > > > > > > > > >=20 > > > > > > > > > Compare inactive memory to swap in this example .. > > > > > > > > >=20 > > > > > > > > > 110 processes: 1 running, 108 sleeping, 1 zombie > > > > > > > > > CPU: 1.2% user, 0.0% nice, 4.3% system, 0.0% interrupt, > > > > > > > > > 94.5% i= > > > > > dle > > > > > > > > > Mem: 474M Active, 1609M Inact, 764M Wired, 281M Buf, 119M Fre > e > > > > > > > > > Swap: 4096M Total, 917M Used, 3178M Free, 22% Inuse =20 > > > > > > > > >=20 > > > > > > > > To analyze this you need to capture vmstat output. You'll see t > he > > > > > > > > fre= > > > > > e pool=20 > > > > > > > > dip below a threshold and pages go out to disk in response. If > you > > > > > > > > ha= > > > > > ve=20 > > > > > > > > daemons with small working sets, pages that are not part of the > > > > > > > > worki= > > > > > ng=20 > > > > > > > > sets for daemons or applications will eventually be paged out. > > > > > > > > This i= > > > > > s not=20 > > > > > > > > a bad thing. In your example above, the 281 MB of UFS buffers a > re > > > > > > > > mor= > > > > > e=20 > > > > > > > > active than the 917 MB paged out. If it's paged out and never u > sed > > > > > > > > ag= > > > > > ain,=20 > > > > > > > > then it doesn't hurt. However the 281 MB of buffers saves you I > /O. > > > > > > > > Th= > > > > > e=20 > > > > > > > > inactive pages are part of your free pool that were active at o > ne > > > > > > > > tim= > > > > > e but=20 > > > > > > > > now are not. They may be reclaimed and if they are, you've just > > > > > > > > saved= > > > > > more=20 > > > > > > > > I/O. > > > > > > > >=20 > > > > > > > > Top is a poor tool to analyze memory use. Vmstat is the better > > > > > > > > tool t= > > > > > o help=20 > > > > > > > > understand memory use. Inactive memory isn't a bad thing per se > . > > > > > > > > Moni= > > > > > tor=20 > > > > > > > > page outs, scan rate and page reclaims. > > > > > > > >=20 > > > > > > > > =20 > > > > > > >=20 > > > > > > > I give up! Tried to check via ssh/vmstat what is going on. Last > > > > > > > lines b= > > > > > efore broken > > > > > > > pipe: > > > > > > >=20 > > > > > > > [...] > > > > > > > procs memory page disks > > > > > > > faults > > > cpu > > > > > > > r b w avm fre flt re pi po fr sr ad0 ad1 in sy > > > > > > > c > > > s > > > > > > > = > > > > > us sy id > > > > > > > 22 0 22 5.8G 1.0G 46319 0 0 0 55721 1297 0 4 219 2390 > 7 > > > > > > > 540= > > > > > 0 95 5 0 > > > > > > > 22 0 22 5.4G 1.3G 51733 0 0 0 72436 1162 0 0 108 4086 > 9 > > > > > > > 345= > > > > > 9 93 7 0 > > > > > > > 15 0 22 12G 1.2G 54400 0 27 0 52188 1160 0 42 148 5219 > 2 > > > > > > > 436= > > > > > 6 91 9 0 > > > > > > > 14 0 22 12G 1.0G 44954 0 37 0 37550 1179 0 39 141 8620 > 9 > > > > > > > 436= > > > > > 8 88 12 0 > > > > > > > 26 0 22 12G 1.1G 60258 0 81 0 69459 1119 0 27 123 7795 > 69 > > > > > > > 704= > > > > > 359 87 13 0 > > > > > > > 29 3 22 13G 774M 50576 0 68 0 32204 1304 0 2 102 5073 > 37 > > > > > > > 484= > > > > > 861 93 7 0 > > > > > > > 27 0 22 13G 937M 47477 0 48 0 59458 1264 3 2 112 6813 > 1 > > > > > > > 4440= > > > > > 7 95 5 0 > > > > > > > 36 0 22 13G 829M 83164 0 2 0 82575 1225 1 0 126 9936 > 6 > > > > > > > 3806= > > > > > 0 89 11 0 > > > > > > > 35 0 22 6.2G 1.1G 98803 0 13 0 121375 1217 2 8 112 993 > 71 > > > > > > > 49= > > > > > 99 85 15 0 > > > > > > > 34 0 22 13G 723M 54436 0 20 0 36952 1276 0 17 153 2914 > 2 > > > > > > > 443= > > > > > 1 95 5 0 > > > > > > > Fssh_packet_write_wait: Connection to 192.168.0.1 port 22: Broken > > > > > > > pip > > > e > > > > > > >=20 > > > > > > >=20 > > > > > > > This makes this crap system completely unusable. The server (Free > BSD > > > > > > > 11= > > > > > .0-CURRENT #20 > > > > > > > r297503: Sat Apr 2 09:02:41 CEST 2016 amd64) in question did > > > > > > > poudriere= > > > > > bulk job. I > > > > > > > can not even determine what terminal goes down first - another on > e, > > > > > > > muc= > > > > > h more time > > > > > > > idle than the one shwoing the "vmstat 5" output, is still alive!= > 20 > > > > > > >=20 > > > > > > > i consider this a serious bug and it is no benefit what happened > > > > > > > sinc > > > e > > > > > > > = > > > > > this "fancy" > > > > > > > update. :-( =20 > > > > > >=20 > > > > > > By the way - it might be of interest and some hint. > > > > > >=20 > > > > > > One of my boxes is acting as server and gateway. It utilises NAT, > > > > > > IPFW, w= > > > > > hen it is under > > > > > > high load, as it was today, sometimes passing the network flow from > > > > > > ISP i= > > > > > nto the network > > > > > > for clients is extremely slow. I do not consider this the reason fo > r > > > > > > coll= > > > > > apsing ssh > > > > > > sessions, since this incident happens also under no-load, but in th > e > > > > > > over= > > > > > all-view onto > > > > > > the problem, this could be a hint - I hope.=20 > > > > > > > > > > I just checked on one box, that "broke pipe" very quickly after I > > > > > started > > > p= > > > > > oudriere, > > > > > while it did well a couple of hours before until the pipe broke. It > > > > > seems > > > i= > > > > > t's load > > > > > dependend when the ssh session gets wrecked, but more important, afte > r > > > > > th > > > e = > > > > > long-haul > > > > > poudriere run, I rebooted the box and tried again with the mentioned > > > > > brok > > > en= > > > > > pipe after a > > > > > couple of minutes after poudriere ran. Then I left the box for severa > l > > > > > ho > > > ur= > > > > > s and logged > > > > > in again and checked the swap. Although there was for hours no load o > r > > > > > ot > > > he= > > > > > r pressure, > > > > > there were 31% of of swap used - still (box has 16 GB of RAM and is > > > > > prope > > > ll= > > > > > ed by a XEON > > > > > E3-1245 V2). > > > > > > > > > > > > > 31%! Is it *actively* paging or is the 31% previously paged out and no > > > > paging is *currently* being experienced? 31% of how swap space in total > ? > > > > > > > > Also, what does ps aumx or ps aumxww say? Pipe it to head -40 or simila > r. > > > > > > > > > > > > > > On FreeBSD 11.0-CURRENT #4 r297573: Tue Apr 5 07:01:19 CEST 2016 amd64, > > > loca l > > > network, no NAT. Stuck ssh session in the middle of administering and > > > leaving the console/ssh session for a couple of minutes: > > > > > > root 2064 0.0 0.1 91416 8492 - Is 07:18 0:00.03 sshd: > > > hartmann [priv] (sshd) > > > > > > hartmann 2108 0.0 0.1 91416 8664 - I 07:18 0:07.33 sshd: > > > hartmann@pts/0 (sshd) > > > > > > root 72961 0.0 0.1 91416 8496 - Is 08:11 0:00.03 sshd: > > > hartmann [priv] (sshd) > > > > > > hartmann 72970 0.0 0.1 91416 8564 - S 08:11 0:00.02 sshd: > > > hartmann@pts/1 (sshd) > > > > > > The situation is worse and i consider this a serious bug. > > > > > > > There's not a lot to go on here. Do you have physical access to the machine > > > to pop into DDB and take a look? You did say you're using a lot of swap. > > IIRC 30%. You didn't answer how much 30% was of. Without more data I can't > > help you. At the best I can take wild guesses but that won't help you. Try > > to answer the questions I asked last week and we can go further. Until then > > > all we can do is wildly guess. > > > > > > Hello Cy, sorry for the lack of information. > > The machine in question is not accessible at this very moment. The box has 16 > GB of physical RAM, 32 GB of swap (on SSD) and a 4-core/8-thread CPU (I think So that's 10 GB of swap. Hmmm. Memory leak? What? We need to investigate this avenue. 4-core/8-thread: A total of 8 threads. It had 22-29 active processes in the run queue (based on your vmstat output). It would appear your box is simply overloaded. > tht is also important due to allocation of arbitrary memory). The problem I > described arose when using poudriere. The box uses 6 builders, but each build > er > can, as I understand, spwan several instances of jobs for compiling/linking e > tc. I'm thinking you have too much loaded on the box (22-29 active processes in the run queue and 10 GB swap used). I'm currently running two poudriere builds on two separate machines, each is dual core with no hyperthreading (AMD X2 5200+ and 5000+) with three builders, each single threaded: load average of about 3-4. > But - that box is only a placeholder for the weirdness that is going on > (despite the fact that it is using NAT since it is atatched to a DSL line). > > To the contrary, the system I face today at work is not(!) behind NAT and > doesn't have the "toy" network binding. This box I'm accessing now has 16 GB > of > physical RAM, and two sockets, each populated with a oldish 4-core XEON 5XXX > from the Core2Duo age (no SMT). That box does not run poudriere, only > postgresql and some other services. What are the performance stats there? CPU, swap, free memory (mem used), scan rate, reclaim rate, and also load average? Do you use ZFS, UFS or both? (I have both and if I use UFS, then swap is used because UFS cache displacement of infrequently used pages, though heavy use of ZFS cache will push some VM out to swap too. Not a big deal as I'm using memory I've paid for rather than it being idle. I wouldn't be this cheap at $JOB though.) > > In February, I was able to push the other box in question (behind NAT, as a > remark) to its limits using poudriere and using 8 builders. Network became > slow, since the box also acts as gateway, but it never failed, broke or dropp > ed > the ssh session due to "broken pipe". Without changing the config except the > base system's sources for CURRENT, since ~ two, or at most three weeks for no > w > I get this weird drops. And this is why I started "wining" - there is also a > drop in performance when compiling world, which elongates the compiling time > ~ > 5 - 10 minutes on the NATed box. > > I'm fully aware of being on CURRENT, but I think it is considerably reasonabl > e > to report about those weird things happening now. I did not receive any word > about dramatic changes that could trigger such a behaviour. And as I > understand the thread we are in here, there has been made a change which > results in a more aggressive swap of inactive processes. > > I tried to stop all services on the boxes (postgresql, icinga2, http etc) to > check whether those could force the kernel to swap a process. But the loss of Swapping isn't really performed until memory is critical. (Swapping is: swapping whole processes out to disk.) Paging OTOH is what you're seeing. That's classic LRU. Scan rate is the determining factor with LRU (or unreferenced interval count if you may -- the amount of time since the page has last been referenced). > ssh connection and the very strange behaviour that the ssh connection gets > irresponsive is eratic, which means: it comes sometimes very fast after > seconds not touching the xterm/ssh from the remote box, sometimes it lasts > up to 30 minutes, even on load. So, there is probably a problem with me > understanding this new feature ... Which new feature? Erratic and unresponsive sessions could be anything. Your stats look way off, indicating the one box is overloaded CPU-wise and memory-wise. Erratic behavior could be due to a number of other factors. What about the other box? CPU, memory stats, swap... What kind of workload is run on it? What kind of NICs do they have too? It's probably buried in another email but do you use UFS, ZFS or both? IIRC only UFS. (UFS and ZFS don't mix. They're like oil and water. The UFS buffer cache and ZFS ARC compete for memory. Throw applications into the mix (obviously) and minor to moderate paging will result. I'll cut to the chase. Without precise information, the areas of possible investigation are too much load (CPU & memory), possible memory leak (?), or possible NIC or network issue causing the disconnects. Similarities between the two systems -- better to look at both and we discover similarities here than through a lens. -- Cheers, Cy Schubert or FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Tue Apr 5 09:05: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 5A684B03CA6 for ; Tue, 5 Apr 2016 09:05:33 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.0x20.net", Issuer "mail.0x20.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1E260101A; Tue, 5 Apr 2016 09:05:32 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id C766A6DF91B; Tue, 5 Apr 2016 11:05:29 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id u3595TJP095267; Tue, 5 Apr 2016 11:05:29 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id u3595SjX094597; Tue, 5 Apr 2016 11:05:28 +0200 (CEST) (envelope-from lars) Date: Tue, 5 Apr 2016 11:05:28 +0200 From: Lars Engels To: Warren Block Cc: freebsd-current@FreeBSD.org, sobomax@freebsd.org Subject: Re: D3702: add support for Bluetooth Magic Mouse Message-ID: <20160405090527.GZ24170@e-new.0x20.net> Mail-Followup-To: Lars Engels , Warren Block , freebsd-current@FreeBSD.org, sobomax@freebsd.org References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HYC+c85AsWjroYih" Content-Disposition: inline In-Reply-To: X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p23 User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 05 Apr 2016 09:05:33 -0000 --HYC+c85AsWjroYih Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 04, 2016 at 10:22:30PM -0600, Warren Block wrote: > Is anyone working on Bluetooth stuff? https://reviews.freebsd.org/D3702= =20 > adds support for the Apple Magic Mouse, and has been tested and reported= =20 > working:=20 > https://lists.freebsd.org/pipermail/freebsd-bluetooth/2016-April/002053.h= tml >=20 > Could someone please review and commit this? Thanks! Sobomax@ (cc'ed) is the most likely person to review this. --HYC+c85AsWjroYih Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQF8BAEBCgBmBQJXA3/XXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1t424H/2Pk56m9ZMYQzFU+GgnIp6Kk n5/FbLVJ0UywtIVLZVrLuqY7SIfs4FfYGfEeq/Q+iZ2oFzFN89rsR1UNvpq4fXL+ 5fFt5KhV7WjhPS80pg8TIRppkJnqvMrD9W1Kqs33L04QTuOOvRp2QO98NthHKgCq qInvIduYZw/TIWI4eP8c7xF8tJ7DlZo9fR6GzJsz+PdmbaYNm+vNrAEDhDiO5aVy W3Gbz/+mjqHxrLhj1oszgjk+w8GdD/yycyBsEwmuhCcju3efKni9TZXmXEmNZ3oT s7mCmpfN9b3trvtFVGKWJOOstk1xDFAwgx23vhdsxQfdzN+RXxA9ABOoRxrvgHM= =GLI1 -----END PGP SIGNATURE----- --HYC+c85AsWjroYih-- From owner-freebsd-current@freebsd.org Tue Apr 5 09:14:34 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 53AFAB022BD; Tue, 5 Apr 2016 09:14:34 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) (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 175C01645; Tue, 5 Apr 2016 09:14:30 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from business-89-133-214-251.business.broadband.hu ([89.133.214.251] helo=[10.160.11.151]) by marvin.harmless.hu with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1anMxV-0002VS-Nk; Tue, 05 Apr 2016 09:07:37 +0000 Subject: Re: Packaging the FreeBSD base system with pkg(8) To: Glen Barber , freebsd-pkgbase@FreeBSD.org References: <20160127223323.GG98557@FreeBSD.org> Cc: freebsd-current@FreeBSD.org From: Gergely Czuczy Message-ID: <5703805A.7090204@harmless.hu> Date: Tue, 5 Apr 2016 11:07:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <20160127223323.GG98557@FreeBSD.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.21 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, 05 Apr 2016 09:14:34 -0000 On 2016-01-27 23:33, Glen Barber wrote: > As many know, work has been in progress for quite some time to provide > the ability to package and upgrade the FreeBSD base system using pkg(8). > The majority of the initial implementation has provided much of the core > functionality to make this possible, however much work still needs to be > done. > > Over the past few weeks, there have been several inquiries on if this > work is still targeted for the 11.0-RELEASE, as well as the status of > the project branch (base/projects/release-pkg). > > The answer to the first question is: Yes. This is still targeted for > 11.0-RELEASE, which was one of the requirements during discussion of the > new support model announced early last year [1]. > > The status of the in progress work is a bit more complex to answer in > a short email, but work on packaging the FreeBSD base system is indeed > ongoing, and has been my primary focus over the past several weeks. > > I am finishing an initial list of outstanding items that need to be > resolved before the project branch can feasibly merged back to head, > which I will send to the new freebsd-pkgbase@ mailing list. People > interested in discussion surrounding this topic are urged to subscribe: > > https://lists.freebsd.org/mailman/listinfo/freebsd-pkgbase > > Finally, I want to personally thank Baptiste Daroussin for all of his > tireless efforts to get us to the point we are at now. Without his > ideas and insights, as well as ensuring pkg(8) contained the necessary > functionality, we would not be anywhere close to completing this work > for the 11.0-RELEASE. May I ask how are you going to handle the tricky merging part, like /etc/master.passwd? Usually that file has entries from 3 sources: - From the Base system, which might change between releases - From installed ports - Manually created entries. Also, quite often entries from the base system are changed manually, think of root's/toor's password. Are such cases going to be dealt with properly between upgrades, including self-built-and-packaged base systems? Currently it can be a PITA with mergemaster to handle things like master.passwd properly between upgrades, automation so far wasn't famous on doing it properly. Another thing is, there are a couple of parts of the base system where we add or remove features using knobs, and those take effect at multiple places. Like if I want to have wireless support, there's a bunch of userland utilities being built, and (the important part) some utilities are going to be built differently, like ifconfig. Is handling such features implemented properly by packaging base? We still have to be able to switch between different builds using the new tools. Another thing is, sometimes when upgrading systems, to make things easier, I deploy the new major version of base, leave old libs/stuff in there till I rebuild and upgrade the packages installed, and after that remove the old libs (rm-old-libs target IIRC). The reason for this, for smaller systems there's usually a build jail which produces packages, and it needs to be upgraded to the new release to make the packages for it, so it's a bit of catch-22, and running rm-old-libs late just solved the issue. Is such a functionality still supported during upgrades? That is, upgrading base systems first in a way that old packages are still functional? It's a very big projects, with lots of corner cases and difficult issues to tackle, I really appreciate your effort on this. Best regards, Gergely > > [1] > https://lists.freebsd.org/pipermail/freebsd-announce/2015-February/001624.html > > Thanks. > > Glen > From owner-freebsd-current@freebsd.org Tue Apr 5 09:22: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 A1255B026BD; Tue, 5 Apr 2016 09:22:23 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 77DF31E52; Tue, 5 Apr 2016 09:22:22 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.0.7] (cpc91230-cmbg18-2-0-cust661.5-4.cable.virginm.net [82.1.230.150]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id u359MB2d006756 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Apr 2016 09:22:14 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host cpc91230-cmbg18-2-0-cust661.5-4.cable.virginm.net [82.1.230.150] claimed to be [192.168.0.7] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Packaging the FreeBSD base system with pkg(8) From: David Chisnall In-Reply-To: <5703805A.7090204@harmless.hu> Date: Tue, 5 Apr 2016 10:22:04 +0100 Cc: Glen Barber , freebsd-pkgbase@FreeBSD.org, freebsd-current@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: <14CD9D09-A32E-46ED-96CA-296FC04B8506@FreeBSD.org> References: <20160127223323.GG98557@FreeBSD.org> <5703805A.7090204@harmless.hu> To: Gergely Czuczy X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 05 Apr 2016 09:22:23 -0000 On 5 Apr 2016, at 10:07, Gergely Czuczy = wrote: >=20 > Also, quite often entries from the base system are changed manually, = think of root's/toor's password. Are such cases going to be dealt with = properly between upgrades, including self-built-and-packaged base = systems? Currently it can be a PITA with mergemaster to handle things = like master.passwd properly between upgrades, automation so far wasn't = famous on doing it properly. Mergemaster uses a 2-way merge. It has the version that you have = installed and the version that=E2=80=99s being proposed for = installation. Etcupdate and pkg perform a 3-way merge. It has the = pristine version, the version that you have made changes to, and the new = version. If you have changed an entry and so has the package, then you = will get a conflict that you have to resolve manually. If you have = added lines and so has the upstream version, then that should cleanly = apply. Similarly, if you and upstream have both modified different = lines, then there should be no problem. David From owner-freebsd-current@freebsd.org Tue Apr 5 10:22: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 52AA5B03E13; Tue, 5 Apr 2016 10:22:53 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::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 DE1EC1C24; Tue, 5 Apr 2016 10:22:52 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm0-x242.google.com with SMTP id 20so2897575wmh.3; Tue, 05 Apr 2016 03:22:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=tDJPdbKyE8QZO02nnaWfkmSUzK7Tomrixg06Zmgbkx8=; b=K7J1b2WCQX97/aHy6DcbBgVLw9PEMJePjTe/JxOdxEzOD6cZqlnW8l7Uh2ON93rBym BwFdoofv5ZvRYeOX5BxedFDjOmDY7ht9t8F4HDRZQVIZHo12UxQmuDvZFraDB1djs9Q0 qRTaJfr53+IesC7XxQ2GBrliLCauErBWSEjcBEn4J7Y6H1mHJk9XU3sORUD3tNP2PtGs wCdq64wJisKuXylSIe5x0NZIJntVHmDUhLzJYXll2aQHqFTU5rVeAWUeDadur7vcOA+D raMps5NqsyWqZ6GntegNpqQfOpfaC9hSagUODCGtO/+Ph9pM/Uee0GkG26uLPhReuYfQ BFIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=tDJPdbKyE8QZO02nnaWfkmSUzK7Tomrixg06Zmgbkx8=; b=QpDZsxjSdhqjt2K33EgVnQzBKT08EW4zcA0mCIC4kMN9mTCrkImQSoC4c8eSFrrJZ6 VH81NMLZv7Aiz8Hpme3iAzrdY8ju/2MW1waHJ2vqBWg0KnsBMmAk0Cuv6H+jzYdYZFui m6bO/22x8IOypHa3K5ptNX3PfnZP3hvC1ql/v7Jh4YWD02//AB1PRGZzS0BQF89M2maw EHwMtFDox4rYNr6KEIMCGZywfpF9wSmoZpUEiCQGVLGl0dnIjU7FWJASE3bFtadzh+Ta /FyarB6Jsi0q/DH3aTU85wGlqBpDzWPN4h6WwMnA/c1/ao16eTv+S4VoIZ1pTXtZm+jd N1VA== X-Gm-Message-State: AD7BkJIwAJnR6UIpyYHWcYImm/MJNuSYTQ4GCpxW1ya4mbtKPIqKG+zBW6wZ7StyC+HCpw== X-Received: by 10.28.225.198 with SMTP id y189mr4373984wmg.34.1459851771380; Tue, 05 Apr 2016 03:22:51 -0700 (PDT) Received: from ernst.home (p578E1682.dip0.t-ipconnect.de. [87.142.22.130]) by smtp.gmail.com with ESMTPSA id lz5sm33915969wjb.5.2016.04.05.03.22.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Apr 2016 03:22:50 -0700 (PDT) Date: Tue, 5 Apr 2016 12:22:49 +0200 From: Gary Jennejohn To: David Chisnall Cc: Gergely Czuczy , Glen Barber , freebsd-pkgbase@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: Packaging the FreeBSD base system with pkg(8) Message-ID: <20160405122249.19419b9f@ernst.home> In-Reply-To: <14CD9D09-A32E-46ED-96CA-296FC04B8506@FreeBSD.org> References: <20160127223323.GG98557@FreeBSD.org> <5703805A.7090204@harmless.hu> <14CD9D09-A32E-46ED-96CA-296FC04B8506@FreeBSD.org> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.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.21 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, 05 Apr 2016 10:22:53 -0000 On Tue, 5 Apr 2016 10:22:04 +0100 David Chisnall wrote: > On 5 Apr 2016, at 10:07, Gergely Czuczy wrote: > > > > Also, quite often entries from the base system are changed > > manually, think of root's/toor's password. Are such cases > > going to be dealt with properly between upgrades, including > > self-built-and-packaged base systems? Currently it can be a > > PITA with mergemaster to handle things like master.passwd > > properly between upgrades, automation so far wasn't famous on > > doing it properly. > > Mergemaster uses a 2-way merge. It has the version that you > have installed and the version that's being proposed for > installation. Etcupdate and pkg perform a 3-way merge. It has > the pristine version, the version that you have made changes > to, and the new version. If you have changed an entry and so > has the package, then you will get a conflict that you have to > resolve manually. If you have added lines and so has the > upstream version, then that should cleanly apply. Similarly, > if you and upstream have both modified different lines, then > there should be no problem. > Will there be an option not to merge? I never update /etc when I do installworld because what I have works for me and I see no need to make any changes to a working system. -- Gary Jennejohn From owner-freebsd-current@freebsd.org Tue Apr 5 10:54: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 37B53B01AF7 for ; Tue, 5 Apr 2016 10:54:17 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 24B251D1C; Tue, 5 Apr 2016 10:54:17 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 1B34B1A5E; Tue, 5 Apr 2016 10:54:17 +0000 (UTC) Date: Tue, 5 Apr 2016 10:54:11 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: avg@FreeBSD.org, adrian@FreeBSD.org, wblock@FreeBSD.org, jhb@FreeBSD.org, mmel@FreeBSD.org, andrew@FreeBSD.org, bdrewery@FreeBSD.org, ache@FreeBSD.org, jhibbits@FreeBSD.org, glebius@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <744631082.192.1459853656450.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1782359103.186.1459767280942.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1782359103.186.1459767280942.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_amd64_gcc - Build #1147 - Still Failing MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_amd64_gcc X-Jenkins-Result: FAILURE Precedence: bulk X-Mailman-Approved-At: Tue, 05 Apr 2016 11:04:23 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 10:54:17 -0000 FreeBSD_HEAD_amd64_gcc - Build #1147 - Still Failing: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1147/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1147/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1147/console Change summaries: 297577 by avg: x86 topo: add some comments, descriptions and references to documentation Plus a minor cosmetic change. MFC after: 1 month 297576 by mmel: TEGRA: Fix CPU frequency switching. The PLL_X, base CPU frequency source, doesn't have a bypass switch and thus we must use another frequency source for CPU while changing its frequency. PLL_P is ideal for this, it runs at 480MHz and CPU can be clocked at this frequency at any CPU voltage. 297573 by jhibbits: Add support for the Microchip mcp7941x. This is compatible with the ds1307, but comparing the mcp7941x datasheet vs the ds1307 code, appears there is one bit placement difference, so that is now accounted for. Relnotes: yes 297572 by jhibbits: Make i2c device child auto-probe work for MPC85xx and QorIQ SoCs. OFW i2c probing requires a new method ofw_bus_get_node(), and the bus device is assumed iichb. With these changes, i2c devices attached in fdt are probed and attached automagically. 297571 by wblock: Add another real-life example of setting a quirk for a USB gaming keyboard. From forum thread: https://forums.freebsd.org/threads/55717/ MFC after: 1 week 297570 by jhb: Remove a redundant check. cpu_suspend_map is always empty if smp_started is false. Sponsored by: Netflix 297569 by jhb: Remove an unneeded check. CPUs with valid per-CPU data are not absent. Sponsored by: Netflix 297568 by jhb: Don't wakeup the fdc worker thread once a second when idle. The fdc worker thread was using a one second timeout while waiting for a new bio to arrive or for the device to detach. However, the driver already does a wakeup when queueing a new bio or asking the thread to detach, so the timeout only served to waste CPU time waking up the thread once a second just so it could go right back to sleep. Use an infinite timeout instead. Discussed with: phk Sponsored by: Netflix 297566 by bdrewery: DIRDEPS_BUILD: Use 1 parameter for defining -rpath-link. Sponsored by: EMC / Isilon Storage Division 297565 by adrian: [net80211] Add an A-MSDU debug output shortcut. 297564 by glebius: Add early_customize_cmd() that allows to register custom functions run before the build stage. Reviewed by: imp Obtained from: Netflix 297563 by adrian: [net80211] teach wlanstats about the ff_encapfail field. Without this it just displays a blank, short column which is just plainly not useful. 297562 by adrian: [net80211] add amsdu and fast frames encap failure counters in the ioctl definition. The code to set these will come in a subsequent commit (when I start fleshing out A-MSDU support.) 297561 by andrew: Add a table to map from the FreeBSD CPUID space to the GIC CPUID space. On many SoCs these two are the same, however there is no requirement for this to be the case, e.g. on the ARM Juno we boot on what the GIC thinks of as CPU 2, but FreeBSD numbers it CPU 0. Obtained from: ABT Systems Ltd Sponsored by: The FreeBSD Foundation 297558 by avg: new x86 smp topology detection code Previously, the code determined a topology of processing units (hardware threads, cores, packages) and then deduced a cache topology using certain assumptions. The new code builds a topology that includes both processing units and caches using the information provided by the hardware. At the moment, the discovered full topology is used only to creeate a scheduling topology for SCHED_ULE. There is no KPI for other kernel uses. Summary: - based on APIC ID derivation rules for Intel and AMD CPUs - can handle non-uniform topologies - requires homogeneous APIC ID assignment (same bit widths for ID components) - topology for dual-node AMD CPUs may not be optimal - topology for latest AMD CPU models may not be optimal as the code is several years old - supports only thread/package/core/cache nodes Todo: - AMD dual-node processors - latest AMD processors - NUMA nodes - checking for homogeneity of the APIC ID assignment across packages - more flexible cache placement within topology - expose topology to userland, e.g., via sysctl nodes Long term todo: - KPI for CPU sharing and affinity with respect to various resources (e.g., two logical processors may share the same FPU, etc) Reviewed by: mav Tested by: mav MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D2728 297557 by ache: SJIS encoding don't have single byte characters >= 224 MFC after: 1 week 297556 by andrew: Reduce the diff for when we switch to intrng. The IPI interrupts will be split out to multiple handlers. Obtained from: ABT Systems Ltd Sponsored by: The FreeBSD Foundation The end of the build log: Started by an SCM change Building remotely on jenkins10a.freebsd.org (FreeBSD-10) in workspace /builds/FreeBSD_HEAD_amd64_gcc Updating svn://svn.freebsd.org/base/head at revision '2016-04-05T10:53:22.016 +0000' U sys/kern/subr_smp.c U sys/x86/x86/mp_x86.c U sys/arm/nvidia/tegra124/tegra124_clk_pll.c U sys/arm/nvidia/tegra124/tegra124_clk_super.c U sys/arm/nvidia/tegra124/tegra124_cpufreq.c U sys/arm/arm/gic.c U sys/dev/iicbus/ds1307.c U sys/dev/iicbus/ds1307reg.h U sys/dev/xen/control/control.c U sys/dev/fdc/fdc.c U sys/powerpc/mpc85xx/i2c.c U sys/net/netisr.c U sys/net80211/ieee80211_ioctl.h U sys/arm64/arm64/gic.c U sys/arm64/arm64/mp_machdep.c U sys/sys/smp.h U share/man/man4/usb_quirk.4 U share/mk/local.meta.sys.mk U tools/tools/net80211/wlanstats/main.c U tools/tools/net80211/wlanstats/wlanstats.c U tools/tools/nanobsd/defaults.sh U tools/tools/nanobsd/nanobsd.sh U lib/libc/locale/mskanji.c At revision 297577 No emails were triggered. [FreeBSD_HEAD_amd64_gcc] $ /bin/sh -xe /tmp/hudson5792676365205741213.sh + cat + svn revert Makefile.inc1 + svn revert sys/boot/i386/Makefile Reverted 'sys/boot/i386/Makefile' + patch -f Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/boot/i386/Makefile |=================================================================== |--- sys/boot/i386/Makefile (revision 280912) |+++ sys/boot/i386/Makefile (working copy) -------------------------- Patching file sys/boot/i386/Makefile using Plan A... Hunk #1 succeeded at 16 (offset 4 lines). Hmm... Ignoring the trailing garbage. done + /vm/freebsd-ci/scripts/build/cross-build.sh + [ -z /builds/FreeBSD_HEAD_amd64_gcc ] + [ -z amd64 ] + export MAKEOBJDIRPREFIX=/builds/FreeBSD_HEAD_amd64_gcc/obj + mkdir -p /builds/FreeBSD_HEAD_amd64_gcc/obj + echo -e 'NO_WERROR=yes WERROR= WITH_FAST_DEPEND=yes' + cat + set +x -------------------------------------------------------------- >>> /builds/FreeBSD_HEAD_amd64_gcc/make.conf contains: + cat /builds/FreeBSD_HEAD_amd64_gcc/make.conf # Put make.conf entries here NO_WERROR=yes WERROR= WITH_FAST_DEPEND=yes + set +x -------------------------------------------------------------- + sudo pkg install -y devel/amd64-xtoolchain-gcc Updating FreeBSD repository catalogue... FreeBSD repository is up-to-date. All repositories are up-to-date. Build step 'Execute shell' marked build as failure [WARNINGS] Skipping publisher since build result is FAILURE IRC notifier plugin: Sending notification to: #freebsd-commits Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-current@freebsd.org Tue Apr 5 14:58: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 69684B04ACF; Tue, 5 Apr 2016 14:58:37 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::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 F25A81450; Tue, 5 Apr 2016 14:58:36 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by mail-wm0-x241.google.com with SMTP id n3so5077079wmn.1; Tue, 05 Apr 2016 07:58:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=YV9vS6LasxXkISKeiUdy+Mddy/ousK7i1zsIO/yXehU=; b=cfrw9MPID1uTPcZK7RzBJrX9nGoVuBWzD4fynJ2eRPLAVHnBj8m1+qXrgkJWSCg/kL 382r0oE2c7eQz/djBdJ2QWkHoEjz5rreoN2y4MnMC9ogmu4gNmA9NxQXTSmByaboaFBU 5JDXRxkeoHcLtCSxAzi9eF6eQbmEscRTrQFAFkRremPZcgNyM9DkZwz3de6H+vJU986m iPWHBOch1dO9690ev3ljsLLg4P3pGRny9vDFRrJSUh3MYo6hipDqP+T52hCQmhzr1AxX R2CZ1ACwoTYRKJFViDqx1fduwG7TMJrHV1pLoXRGPBeVJ6Z6yGpg8cDP9m0tGlNQZHEw YGPg== 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 :references:mime-version:content-disposition:in-reply-to:user-agent; bh=YV9vS6LasxXkISKeiUdy+Mddy/ousK7i1zsIO/yXehU=; b=ipdZ8/3OQ/3ZJTTSN9XhNSVT1lt40TwpN6m/izwjd0xHAmzv1KuU6dimYbmpvNZJpI 4GMo3CwdtR432Uc7BVfxfqtzA8/j4i2ma2mO3rNH6YwiCIQvwFlHNHj1SHE6gXotepdS DzDqsEuRBIEGYTZiwC3m2v9t7dDkzpYbSpgINuquChjFkYGgMBgF6Nvv/iJdg6SordPf HSL/o0lqnaB0MSEIuL3buqhwGsIGAYIa2NjiQLjdaa9PD+mcKzqBI6syEljXYJo1bFQ3 jtD2oLXdD/S069cWKXZ3lwjBURUwe9neY6atxlncC8cgR/ZwGe3AoHwO0EGJNVZlnEqb RMZw== X-Gm-Message-State: AD7BkJLFI2IhkkeGXPZFWdajx3N9Pt6YHoZqfmGUnp58lnS2o1PiOJMmWlkWPSCfYyYlvw== X-Received: by 10.194.20.193 with SMTP id p1mr13750303wje.87.1459868314524; Tue, 05 Apr 2016 07:58:34 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by smtp.gmail.com with ESMTPSA id wr2sm35171346wjc.49.2016.04.05.07.58.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Apr 2016 07:58:33 -0700 (PDT) Sender: Baptiste Daroussin Date: Tue, 5 Apr 2016 16:58:31 +0200 From: Baptiste Daroussin To: Gary Jennejohn Cc: David Chisnall , Glen Barber , freebsd-current@FreeBSD.org, Gergely Czuczy , freebsd-pkgbase@FreeBSD.org Subject: Re: Packaging the FreeBSD base system with pkg(8) Message-ID: <20160405145830.GH49864@ivaldir.etoilebsd.net> References: <20160127223323.GG98557@FreeBSD.org> <5703805A.7090204@harmless.hu> <14CD9D09-A32E-46ED-96CA-296FC04B8506@FreeBSD.org> <20160405122249.19419b9f@ernst.home> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KscVNZbUup0vZz0f" Content-Disposition: inline In-Reply-To: <20160405122249.19419b9f@ernst.home> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 05 Apr 2016 14:58:37 -0000 --KscVNZbUup0vZz0f Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 05, 2016 at 12:22:49PM +0200, Gary Jennejohn wrote: > On Tue, 5 Apr 2016 10:22:04 +0100 > David Chisnall wrote: >=20 > > On 5 Apr 2016, at 10:07, Gergely Czuczy wr= ote: > > >=20 > > > Also, quite often entries from the base system are changed > > > manually, think of root's/toor's password. Are such cases > > > going to be dealt with properly between upgrades, including > > > self-built-and-packaged base systems? Currently it can be a > > > PITA with mergemaster to handle things like master.passwd > > > properly between upgrades, automation so far wasn't famous on > > > doing it properly.=20 > >=20 > > Mergemaster uses a 2-way merge. It has the version that you > > have installed and the version that's being proposed for > > installation. Etcupdate and pkg perform a 3-way merge. It has > > the pristine version, the version that you have made changes > > to, and the new version. If you have changed an entry and so > > has the package, then you will get a conflict that you have to > > resolve manually. If you have added lines and so has the > > upstream version, then that should cleanly apply. Similarly, > > if you and upstream have both modified different lines, then > > there should be no problem. > >=20 >=20 > Will there be an option not to merge? I never update /etc when > I do installworld because what I have works for me and I see no > need to make any changes to a working system. Yes pkg has an option to not merge and will give you some .pkgnew files Bapt --KscVNZbUup0vZz0f Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXA9KWAAoJEGOJi9zxtz5apQsQAN5niLq6sFeDRv9849c2qpJr //ZrI7NkcI5bSkI4TOkE8R/sUMAcoC74kW0AD41qLHJEj6XY4ho6tF29LPANOjTQ YRzT9dJJlnOcOcNAAhPYBdoWHeKIN3rSib73yyyYbZiz3t/yt1ZdyPxgbTRTWX7X 1hi0A8uorri+YbfrjMI803K7clJLTl2OQWJ0Db1BRepRAhHsCldZxPapW71sFMFB RHFjNOi/qJI7ulupAc/ee4J4zcollYwXU9Z/CbjV2yJDcmuE9dDJH2+ByfuastuV Gw3C6UJ7bTY/DhBTnD32To5i2ajv/HLdOQw6Z6PGI8XyJQb4swJctaBnlPpekQ0B iIY6PKU0d8MGjYoUMr9gV0RLAx43rnYjNRX0IzNrcuoY/b2urAdfVdxm+eEzNAYZ UxSND5fhOpv3ZCW3CUohTo/XlgpBorDD4Td4qqBaDdbkJkjv5JLtK8rhs7tqGTvs 0JSL59nwDVnWRdKtFoiw2kH7pk1DpmN8Ps793MK/Z80oovyZIKuDPjvDHkjSWJMx 9B4P0flTzAnmh1QLiP1iD7bdJefalaZUYSTp2T8xiZEv1QswwGfO1lDkdiH04+xP 6/Hep30MctV05dr3qv4Q9w1I/HF/1vZIaFSMYdpX6f/f4oEcdMZnUljb/RVQgoQo xmqI5F509FDonFTypRpj =CyNJ -----END PGP SIGNATURE----- --KscVNZbUup0vZz0f-- From owner-freebsd-current@freebsd.org Tue Apr 5 16:06: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 8904AB040E9 for ; Tue, 5 Apr 2016 16:06:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.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 69C0318B6 for ; Tue, 5 Apr 2016 16:06:01 +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 bigwig.baldwin.cx (Postfix) with ESMTPSA id 35798B972; Tue, 5 Apr 2016 12:06:00 -0400 (EDT) From: John Baldwin To: Konstantin Belousov Cc: freebsd-current@freebsd.org, Ryan Stone Subject: Re: accessing a PCIe register from userspace through kmem or other ways ? Date: Tue, 05 Apr 2016 08:55:54 -0700 Message-ID: <2874767.SJKfSzhn1q@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20160405061431.GF1741@kib.kiev.ua> References: <9376230.YZMFsgSvTf@ralph.baldwin.cx> <20160405061431.GF1741@kib.kiev.ua> 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.2.7 (bigwig.baldwin.cx); Tue, 05 Apr 2016 12:06:00 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 05 Apr 2016 16:06:01 -0000 On Tuesday, April 05, 2016 09:14:31 AM Konstantin Belousov wrote: > On Mon, Apr 04, 2016 at 03:45:07PM -0700, John Baldwin wrote: > > However, another question is how to deal with systems that do bus address > > translation (like the arm64 ThunderX boxes) where the values in the PCI > > BAR are not CPU physical addresses. To do this properly we may need some > > sort of bus method akin to my bus_map_resource() WIP but one that instead > > returns a suitable 'struct sglist' for a given 'struct resource *' that > > can be used with OBJT_SG to build a VM object to use for the mapping. > Is there any documentation on the ThunderX PCI access mechanisms ? The Host-PCI (or really some other bus -> PCI) bridges apply a fixed offset to PCI addresses, so if your BAR has address X written to it, the CPU has to use an address of X + Y (where Y is the PCI window base address) to access it. The bridge device decodes the access to address X + Y and generates a PCI transaction to address X. It's not clear to me how DMA works for these devices (e.g. if all DMA requests from PCI devices have to use an IOMMU built into the bridge). > > (At some point I do think I would like a variant of OBJT_SG that used > > managed pages so that mappings could be revoked when whatever is backing > > the sglist is disabled (e.g. the device is ejected or the BAR is > > relocated, etc.).) > Why cannot you use MGTDEVICE pager already ? Driver would need to > maintain its private list of pages, and from this PoV, a convenience > wrapper around MGTDEVICE which unifies operations on sg lists could be > useful. Still, it could be that the wrapper appear to be single-purpose. Mostly I do not have experience with MGTDEVICE, though I was planning to look at it as a way to implement this. Two things though: 1) there may not be a cdev to associate with, and 2) I know of at least one device driver that would use this in addition to using this for a general "map this BAR" ioctl on /dev/pci. There are other cases in the past where I used OBJT_SG but would have preferred to use a variant that used managed pages so that I could invidate any existing mappings. In particular what I want to do is invalidate an object so that any future uses fail. Alternatively, it might be nice to hook a destructor call into a VM object so that I could know when the object is no longer in use (knowing that all its mappings have been destroyed). When using OBJT_SG objects as aliases for other things (memory allocated via contigmalloc or bus_dma or for resources like PCI BARs), I could keep a reference count on the original "thing" that I increment when creating an OBJT_SG object to return from something like d_mmap_single() or the /dev/pci ioctl and drop the reference count in the destructor hook for that object. -- John Baldwin From owner-freebsd-current@freebsd.org Tue Apr 5 16:21: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 0D482B044CE for ; Tue, 5 Apr 2016 16:21:43 +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 824741105; Tue, 5 Apr 2016 16:21:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u35GLUo2076256 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 5 Apr 2016 19:21:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u35GLUo2076256 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u35GLUkO076255; Tue, 5 Apr 2016 19:21:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 5 Apr 2016 19:21:29 +0300 From: Konstantin Belousov To: John Baldwin Cc: freebsd-current@freebsd.org, Ryan Stone Subject: Re: accessing a PCIe register from userspace through kmem or other ways ? Message-ID: <20160405162129.GG1741@kib.kiev.ua> References: <9376230.YZMFsgSvTf@ralph.baldwin.cx> <20160405061431.GF1741@kib.kiev.ua> <2874767.SJKfSzhn1q@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2874767.SJKfSzhn1q@ralph.baldwin.cx> User-Agent: Mutt/1.5.24 (2015-08-30) 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.21 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, 05 Apr 2016 16:21:43 -0000 On Tue, Apr 05, 2016 at 08:55:54AM -0700, John Baldwin wrote: > Mostly I do not have experience with MGTDEVICE, though I was planning to > look at it as a way to implement this. Two things though: 1) there may > not be a cdev to associate with, and 2) I know of at least one device driver > that would use this in addition to using this for a general "map this BAR" > ioctl on /dev/pci. So /dev/pci is the natural cdev to place the functionality. An ioctl on /dev/pci may mmap BAR and return the base address. > There are other cases in the past where I used OBJT_SG > but would have preferred to use a variant that used managed pages so that > I could invidate any existing mappings. In particular what I want to do > is invalidate an object so that any future uses fail. > > Alternatively, it might be nice to hook a destructor call into a VM object > so that I could know when the object is no longer in use (knowing that all > its mappings have been destroyed). When using OBJT_SG objects as aliases > for other things (memory allocated via contigmalloc or bus_dma or for > resources like PCI BARs), I could keep a reference count on the original > "thing" that I increment when creating an OBJT_SG object to return from > something like d_mmap_single() or the /dev/pci ioctl and drop the reference > count in the destructor hook for that object. This is in essence how GEM objects + MGTDEVICE mappings work for i915. The only bottleneck in the API arrangement is that d_mmap_single() only gets the offset as the identifying data to construct the mapping. For /dev/pci, the offset parameter would need to encode d:b:s:f and BAR index. From owner-freebsd-current@freebsd.org Tue Apr 5 17:02: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 B81D0B035BB for ; Tue, 5 Apr 2016 17:02:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.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 988C91D46 for ; Tue, 5 Apr 2016 17:02:12 +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 bigwig.baldwin.cx (Postfix) with ESMTPSA id A4982B93C; Tue, 5 Apr 2016 13:02:11 -0400 (EDT) From: John Baldwin To: Konstantin Belousov Cc: freebsd-current@freebsd.org, Ryan Stone Subject: Re: accessing a PCIe register from userspace through kmem or other ways ? Date: Tue, 05 Apr 2016 10:02:07 -0700 Message-ID: <8615362.BAVEr0Gv7s@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20160405162129.GG1741@kib.kiev.ua> References: <2874767.SJKfSzhn1q@ralph.baldwin.cx> <20160405162129.GG1741@kib.kiev.ua> 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.2.7 (bigwig.baldwin.cx); Tue, 05 Apr 2016 13:02:11 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 05 Apr 2016 17:02:12 -0000 On Tuesday, April 05, 2016 07:21:29 PM Konstantin Belousov wrote: > On Tue, Apr 05, 2016 at 08:55:54AM -0700, John Baldwin wrote: > > Mostly I do not have experience with MGTDEVICE, though I was planning to > > look at it as a way to implement this. Two things though: 1) there may > > not be a cdev to associate with, and 2) I know of at least one device driver > > that would use this in addition to using this for a general "map this BAR" > > ioctl on /dev/pci. > So /dev/pci is the natural cdev to place the functionality. > An ioctl on /dev/pci may mmap BAR and return the base address. > > > There are other cases in the past where I used OBJT_SG > > but would have preferred to use a variant that used managed pages so that > > I could invidate any existing mappings. In particular what I want to do > > is invalidate an object so that any future uses fail. > > > > Alternatively, it might be nice to hook a destructor call into a VM object > > so that I could know when the object is no longer in use (knowing that all > > its mappings have been destroyed). When using OBJT_SG objects as aliases > > for other things (memory allocated via contigmalloc or bus_dma or for > > resources like PCI BARs), I could keep a reference count on the original > > "thing" that I increment when creating an OBJT_SG object to return from > > something like d_mmap_single() or the /dev/pci ioctl and drop the reference > > count in the destructor hook for that object. > This is in essence how GEM objects + MGTDEVICE mappings work for i915. > > The only bottleneck in the API arrangement is that d_mmap_single() only > gets the offset as the identifying data to construct the mapping. > For /dev/pci, the offset parameter would need to encode d:b:s:f and BAR > index. For the ioctl I planned to either 1) call vm_mmap_object() or the like directly and return the virtual address to the user, or 2) return the mmap offset to use from the ioctl that the user would then supply to mmap() and d_mmap_single would use to find the object created by the ioctl. 1) is probably simpler and is more what I was leaning towards. Still, I want to be able to handle invalidations either by pinning the BAR while the object is mapped, or being able to invalidate the object. Given that you can eject a hotplug PCI device, I think explicit invalidation is the better route in this case. I would create a VM object for each BAR on the first mmap request and save a reference to it in the PCI bus ivars. If the BAR is ever cleared I would be able to find the object and invalidate it ensuring any programs that then tried to access it would get a page fault instead of accessing some other random thing. -- John Baldwin From owner-freebsd-current@freebsd.org Tue Apr 5 17:27: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 0FDF7B03C5C for ; Tue, 5 Apr 2016 17:27:42 +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 855E017D9; Tue, 5 Apr 2016 17:27:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u35HRYRt091744 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 5 Apr 2016 20:27:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u35HRYRt091744 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u35HRW3s091743; Tue, 5 Apr 2016 20:27:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 5 Apr 2016 20:27:32 +0300 From: Konstantin Belousov To: John Baldwin Cc: freebsd-current@freebsd.org, Ryan Stone Subject: Re: accessing a PCIe register from userspace through kmem or other ways ? Message-ID: <20160405172732.GH1741@kib.kiev.ua> References: <2874767.SJKfSzhn1q@ralph.baldwin.cx> <20160405162129.GG1741@kib.kiev.ua> <8615362.BAVEr0Gv7s@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8615362.BAVEr0Gv7s@ralph.baldwin.cx> User-Agent: Mutt/1.5.24 (2015-08-30) 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.21 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, 05 Apr 2016 17:27:42 -0000 On Tue, Apr 05, 2016 at 10:02:07AM -0700, John Baldwin wrote: > For the ioctl I planned to either 1) call vm_mmap_object() or the like directly > and return the virtual address to the user, or 2) return the mmap offset to use > from the ioctl that the user would then supply to mmap() and d_mmap_single would > use to find the object created by the ioctl. 1) is probably simpler and is more > what I was leaning towards. Still, I want to be able to handle invalidations > either by pinning the BAR while the object is mapped, or being able to invalidate > the object. Given that you can eject a hotplug PCI device, I think explicit > invalidation is the better route in this case. I would create a VM object for > each BAR on the first mmap request and save a reference to it in the PCI bus > ivars. If the BAR is ever cleared I would be able to find the object and > invalidate it ensuring any programs that then tried to access it would get a > page fault instead of accessing some other random thing. Option 2) is what I discussed, and what has been used for GEM and TTM. It allows to create an object per buffer (per BAR for /dev/pci case), and you indeed can easily iterate over managed pages belonging to the given buffer/BAR because they belong to the object' queue. This scheme utilizes d_mmap_single() on the 'global' object (/dev/pci, /dev/card/dri etc), which takes offset and decodes it into the buffer/BAR. In my opinion, it is prettier than explicit call to vm_mmap_object() since it leaves all high-level stuff to the VM subsystem proper. Driver only needs to create the suitable object (and manage offsets). On the other hand, GEM has to emulate another Linux interface, where ioctl() really performs mapping. But again, there it is simpler to ensure that vm_object for buffer/BAR is created, and then call vm_map_find((), not even touching middle-level of vm_mmap_object(). See i915_gem_mmap_ioctl(). From owner-freebsd-current@freebsd.org Tue Apr 5 17:40: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 82331B0415A for ; Tue, 5 Apr 2016 17:40:23 +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 2CAAC1F5B; Tue, 5 Apr 2016 17:40:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u35HeHS7094755 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 5 Apr 2016 20:40:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u35HeHS7094755 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u35HeGKK094754; Tue, 5 Apr 2016 20:40:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 5 Apr 2016 20:40:16 +0300 From: Konstantin Belousov To: John Baldwin Cc: freebsd-current@freebsd.org, Ryan Stone Subject: Re: accessing a PCIe register from userspace through kmem or other ways ? Message-ID: <20160405174016.GI1741@kib.kiev.ua> References: <2874767.SJKfSzhn1q@ralph.baldwin.cx> <20160405162129.GG1741@kib.kiev.ua> <8615362.BAVEr0Gv7s@ralph.baldwin.cx> <20160405172732.GH1741@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160405172732.GH1741@kib.kiev.ua> User-Agent: Mutt/1.5.24 (2015-08-30) 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.21 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, 05 Apr 2016 17:40:23 -0000 On Tue, Apr 05, 2016 at 08:27:32PM +0300, Konstantin Belousov wrote: > On Tue, Apr 05, 2016 at 10:02:07AM -0700, John Baldwin wrote: > > For the ioctl I planned to either 1) call vm_mmap_object() or the like directly > > and return the virtual address to the user, or 2) return the mmap offset to use > > from the ioctl that the user would then supply to mmap() and d_mmap_single would > > use to find the object created by the ioctl. 1) is probably simpler and is more > > what I was leaning towards. Still, I want to be able to handle invalidations > > either by pinning the BAR while the object is mapped, or being able to invalidate > > the object. Given that you can eject a hotplug PCI device, I think explicit > > invalidation is the better route in this case. I would create a VM object for > > each BAR on the first mmap request and save a reference to it in the PCI bus > > ivars. If the BAR is ever cleared I would be able to find the object and > > invalidate it ensuring any programs that then tried to access it would get a > > page fault instead of accessing some other random thing. > > Option 2) is what I discussed, and what has been used for GEM and TTM. > It allows to create an object per buffer (per BAR for /dev/pci case), > and you indeed can easily iterate over managed pages belonging to the > given buffer/BAR because they belong to the object' queue. > > This scheme utilizes d_mmap_single() on the 'global' object (/dev/pci, > /dev/card/dri etc), which takes offset and decodes it into the > buffer/BAR. > > In my opinion, it is prettier than explicit call to vm_mmap_object() > since it leaves all high-level stuff to the VM subsystem proper. Driver > only needs to create the suitable object (and manage offsets). > > On the other hand, GEM has to emulate another Linux interface, where > ioctl() really performs mapping. But again, there it is simpler > to ensure that vm_object for buffer/BAR is created, and then call > vm_map_find((), not even touching middle-level of vm_mmap_object(). See > i915_gem_mmap_ioctl(). > Important thing I forgot about, is that managed fictitious pages, which are created by MGTDEVICE pagers, must be supported by the pmap. It is not hard, the issue is that typical pmap does not make a distinction between unmanaged and fictitious pages. For x86, this was implemented by r224746 + r233168. For other pmaps, r224746 alone might be enough, but it was never tested for clear reasons. From owner-freebsd-current@freebsd.org Tue Apr 5 17:42: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 84F63B0432B; Tue, 5 Apr 2016 17:42:56 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 20D9813AE; Tue, 5 Apr 2016 17:42:55 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190f-ca3ff70000004b9e-78-5703f91dbb97 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id C3.7C.19358.D19F3075; Tue, 5 Apr 2016 13:42:53 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u35Hgq6x019986; Tue, 5 Apr 2016 13:42:53 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u35Hgnl4000449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Apr 2016 13:42:52 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u35HgnqQ025582; Tue, 5 Apr 2016 13:42:49 -0400 (EDT) Date: Tue, 5 Apr 2016 13:42:48 -0400 (EDT) From: Benjamin Kaduk To: Gary Jennejohn cc: freebsd-pkgbase@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: Packaging the FreeBSD base system with pkg(8) In-Reply-To: <20160405122249.19419b9f@ernst.home> Message-ID: References: <20160127223323.GG98557@FreeBSD.org> <5703805A.7090204@harmless.hu> <14CD9D09-A32E-46ED-96CA-296FC04B8506@FreeBSD.org> <20160405122249.19419b9f@ernst.home> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixCmqrSv7kznc4OhTSYs5bz4wWWx51sFm sfrVd2YHZo8Zn+azeOycdZc9gCmKyyYlNSezLLVI3y6BK+PW8vKCg0wVi+8aNTB+Yexi5OSQ EDCRmH3nFHsXIxeHkEAbk0TvxmZGCGcDo8TsaydZIZyDTBLXp31jAmkREqiXaPv5jKWLkYOD RUBLYvlxeZAwm4CKxMw3G9lAbBEBTYmut9dZQWxmARuJmw9mMoPYwgJWEvfbrjODtHIKGErM vpUCYvIKOEo8bveA2LScUeJ13xmwTaICOhKr909hAbF5BQQlTs58wgIxEmjr9G0sExgFZiFJ zUKSWsDItIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXRC83s0QvNaV0EyM4KCX5dzDOafA+xCjA wajEwzvjPVO4EGtiWXFl7iFGSQ4mJVHefe+Zw4X4kvJTKjMSizPii0pzUosPMUpwMCuJ8NZ+ B8rxpiRWVqUW5cOkpDlYlMR5GRkYGIQE0hNLUrNTUwtSi2CyMhwcShK890EaBYtS01Mr0jJz ShDSTBycIMN5gIavAhteXJCYW5yZDpE/xajLseDH7bVMQix5+XmpUuK8Z0GKBECKMkrz4OaA k8luJtVXjOJAbwnzXgep4gEmIrhJr4CWMAEtqRdmAllSkoiQkmpg9Hmju4enq2i72YHEn9HH NzDkJRgoT9EWCnoUsESscfeadx7qhxqreo+pTnaR532/fFttnECwO1efVB+znu5UTtbfk354 hh7RLTrNGxma+7crLCuiv5e1c65OwiOP2haGexulj2to2sklXGvbo7x1SeD7tckOklJCW1j3 r1oZ7yK0gu1vsLgSS3FGoqEWc1FxIgAplytMAQMAAA== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 05 Apr 2016 17:42:56 -0000 On Tue, 5 Apr 2016, Gary Jennejohn wrote: > Will there be an option not to merge? I never update /etc when > I do installworld because what I have works for me and I see no > need to make any changes to a working system. And you expect your system to continue working after a new system user is added? -Ben From owner-freebsd-current@freebsd.org Tue Apr 5 17:43:48 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 0D1E7B043FC for ; Tue, 5 Apr 2016 17:43:48 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) by mx1.freebsd.org (Postfix) with ESMTP id E4E221658 for ; Tue, 5 Apr 2016 17:43:47 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [192.168.1.10] (unknown [192.168.1.10]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id CB9C7D32B for ; Tue, 5 Apr 2016 17:43:46 +0000 (UTC) Subject: Re: Packaging the FreeBSD base system with pkg(8) To: freebsd-current@freebsd.org References: <20160127223323.GG98557@FreeBSD.org> <5703805A.7090204@harmless.hu> <14CD9D09-A32E-46ED-96CA-296FC04B8506@FreeBSD.org> <20160405122249.19419b9f@ernst.home> From: Allan Jude Message-ID: <5703F94F.7010002@freebsd.org> Date: Tue, 5 Apr 2016 13:43:43 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 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.21 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, 05 Apr 2016 17:43:48 -0000 On 2016-04-05 13:42, Benjamin Kaduk wrote: > On Tue, 5 Apr 2016, Gary Jennejohn wrote: > >> Will there be an option not to merge? I never update /etc when >> I do installworld because what I have works for me and I see no >> need to make any changes to a working system. > > And you expect your system to continue working after a new system user is > added? > > -Ben > _______________________________________________ > 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" > At a minimum, you need to run 'mergemaster -p', which does things required for 'installworld' to actually succeed. -- Allan Jude From owner-freebsd-current@freebsd.org Tue Apr 5 18:11: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 3588CB04FAC for ; Tue, 5 Apr 2016 18:11:27 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 298B4186D; Tue, 5 Apr 2016 18:11:27 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 26F2A1BAE; Tue, 5 Apr 2016 18:11:25 +0000 (UTC) Date: Tue, 5 Apr 2016 18:09:01 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: trasz@FreeBSD.org, ian@FreeBSD.org, mmel@FreeBSD.org, skra@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <2001079397.196.1459879866354.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <744631082.192.1459853656450.JavaMail.jenkins@jenkins-9.freebsd.org> References: <744631082.192.1459853656450.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_amd64_gcc - Build #1148 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_amd64_gcc X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 18:11:27 -0000 FreeBSD_HEAD_amd64_gcc - Build #1148 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1148/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1148/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1148/console Change summaries: 297584 by skra: Fix typo. No functional change. 297583 by ian: Add more DPRINTF() to the ftdi driver. Now everything that can change the chip's state has a DPRINTF, with things that happen repeatedly at debug=2 level and things that happen frequently (like per-transfer IO) at debug=3. 297582 by skra: Rework BCM283x gpio interrupt controller for INTRNG. It's used on RPI-B and RPI2 where INTRNG is already enabled by default. Differential Revision: https://reviews.freebsd.org/D5810 297581 by skra: Implement bcm2836 interrupt controller for INTRNG and enable it on RPI2 by default. Differential Revision: https://reviews.freebsd.org/D5822 297580 by skra: Rework bcm283x interrupt controller for INTRNG and enable it on RPI-B by default. Reviewed by: gonzo Differential Revision: https://reviews.freebsd.org/D5809 297579 by mmel: ehci_interrupt is MPSAFE code. Most drivers in tree calls bus_setup_intr with MPSAFE, some are not. Fix those. Submitted by: Howard Su Differential Revision: https://reviews.freebsd.org/D5755 297578 by trasz: Use proper locking macros in RACCT in RCTL. MFC after: 1 month Sponsored by: The FreeBSD Foundation From owner-freebsd-current@freebsd.org Tue Apr 5 18:16:05 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 7267AB03215 for ; Tue, 5 Apr 2016 18:16:05 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::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 4E79F1C15; Tue, 5 Apr 2016 18:16:05 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mail-pa0-x231.google.com with SMTP id td3so15319802pab.2; Tue, 05 Apr 2016 11:16:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Yv3FvvChwB4wnRYsyJbOBRQ+tosCE3p/l/hvYlKG/Ic=; b=dysurvngqe7aasaM5QFd9jnbkn9bA1MKEjZInREmDZ8AOIInOmQqZOBNsCKIbgKyJX OMJuzRZmxW8Voyk/7PV4iXmjeEdfIsN5aSPKEtKWdykTEqDGokXXhmKqqJsxC0kXbgbH V2SFGnNrIfauk5j+CSr05WqgG+9y6XXLEI67X+1naYvShGdiibGAvG8D7WztnJF9AK/8 VF4Ew8eLF1eHtMYXkJfm16sMWi7/zhwq9fr1pMRG7zXwtT6uWzu8Ys2QSXCBcrEw7juc 1QEkHWVbErOM1miOHRONvO+VP45zHZdhz8SXq7vFcAV2HKs0j64nJQaL20blPssWFLxs Zq9w== 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:date :message-id:subject:from:to:cc; bh=Yv3FvvChwB4wnRYsyJbOBRQ+tosCE3p/l/hvYlKG/Ic=; b=afhlWcFgIXZUj73KpPszgiMWLEL9GeciNIOh47dLggezBXLGYtbRq6UvTh96bHCk+6 S71xo6nnsq3y/A7nWDirqVgIjSfcx6FNKlkHdvacpQJ6eC3ikR5L0XJp0p1g1u1EJei+ xywrgChgD0QX7IyAAniKvwcB/5OB4S9HcIMaBdwmbg3V3Sq47pbtErVjjsO6pCSYjGyv 7BgCGZwDGjbtV/iFy/Mg213VBz54M+J2WiEtvDffmPSzfqqxb2sARjPrDv9M51gyjYN3 QhPNKqpU6LHpw+P8XeZTr077jcm5lrCdklw7ja9qA38msDMHpYFhADu5IcN1aoFSIgKd ejxQ== X-Gm-Message-State: AD7BkJK1eF+YpqeWIyGMSMe4knONdyC6DdG1RWfdPjSPiDBnPm8Yq+OfnTCVYX/6/5C6jIAjM9eogB7UOk0WYQ== MIME-Version: 1.0 X-Received: by 10.107.150.2 with SMTP id y2mr18299725iod.113.1459880164533; Tue, 05 Apr 2016 11:16:04 -0700 (PDT) Received: by 10.107.153.206 with HTTP; Tue, 5 Apr 2016 11:16:04 -0700 (PDT) In-Reply-To: <20160405061013.GE1741@kib.kiev.ua> References: <9376230.YZMFsgSvTf@ralph.baldwin.cx> <5009932.qXoZ6E4rhX@ralph.baldwin.cx> <20160405061013.GE1741@kib.kiev.ua> Date: Tue, 5 Apr 2016 14:16:04 -0400 Message-ID: Subject: Re: accessing a PCIe register from userspace through kmem or other ways ? From: Ryan Stone To: Konstantin Belousov Cc: John Baldwin , FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 05 Apr 2016 18:16:05 -0000 On Tue, Apr 5, 2016 at 2:10 AM, Konstantin Belousov wrote: > The mmap(2) interface to /dev/mem did not have the issue ever. The problem > was only with the read(2)/write(2) accesses. > I mis-remembered my situation. I was performing a read on /dev/mem rather than reading through a mmap. Thanks for clearing this up. From owner-freebsd-current@freebsd.org Tue Apr 5 16:22: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 6B86DB04528 for ; Tue, 5 Apr 2016 16:22:17 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 553161332; Tue, 5 Apr 2016 16:22:17 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 4BEC91AB4; Tue, 5 Apr 2016 16:22:17 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id D868720C1C; Tue, 5 Apr 2016 16:22:16 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id HTXrtpNR2bsO; Tue, 5 Apr 2016 16:22:14 +0000 (UTC) Subject: Re: FreeBSD_HEAD_amd64_gcc - Build #1147 - Still Failing DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com F223320C14 To: jenkins-admin@FreeBSD.org, avg@FreeBSD.org, adrian@FreeBSD.org, wblock@FreeBSD.org, jhb@FreeBSD.org, mmel@FreeBSD.org, andrew@FreeBSD.org, ache@FreeBSD.org, jhibbits@FreeBSD.org, glebius@FreeBSD.org, freebsd-current@FreeBSD.org, Baptiste Daroussin References: <1782359103.186.1459767280942.JavaMail.jenkins@jenkins-9.freebsd.org> <744631082.192.1459853656450.JavaMail.jenkins@jenkins-9.freebsd.org> From: Bryan Drewery Organization: FreeBSD Message-ID: <5703E633.50805@FreeBSD.org> Date: Tue, 5 Apr 2016 09:22:11 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <744631082.192.1459853656450.JavaMail.jenkins@jenkins-9.freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 05 Apr 2016 19:18:01 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 05 Apr 2016 16:22:17 -0000 On 4/5/16 3:54 AM, jenkins-admin@FreeBSD.org wrote: > + sudo pkg install -y devel/amd64-xtoolchain-gcc > Updating FreeBSD repository catalogue... > FreeBSD repository is up-to-date. > All repositories are up-to-date. > Build step 'Execute shell' marked build as failure pkg install -y is returning an error now here where it didn't before. -- Regards, Bryan Drewery From owner-freebsd-current@freebsd.org Tue Apr 5 16:52: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 0AADBB0301C for ; Tue, 5 Apr 2016 16:52:35 +0000 (UTC) (envelope-from lwhsu@FreeBSD.cs.nctu.edu.tw) Received: from FreeBSD.cs.nctu.edu.tw (freebsd2.cs.nctu.edu.tw [140.113.17.206]) by mx1.freebsd.org (Postfix) with ESMTP id CAB8818E1; Tue, 5 Apr 2016 16:52:34 +0000 (UTC) (envelope-from lwhsu@FreeBSD.cs.nctu.edu.tw) Received: by FreeBSD.cs.nctu.edu.tw (Postfix, from userid 1058) id 6F2AD2B1F; Wed, 6 Apr 2016 00:52:33 +0800 (CST) Date: Wed, 6 Apr 2016 00:52:33 +0800 From: Li-Wen Hsu To: Bryan Drewery Cc: jenkins-admin@FreeBSD.org, avg@FreeBSD.org, adrian@FreeBSD.org, wblock@FreeBSD.org, jhb@FreeBSD.org, mmel@FreeBSD.org, andrew@FreeBSD.org, ache@FreeBSD.org, jhibbits@FreeBSD.org, glebius@FreeBSD.org, freebsd-current@FreeBSD.org, Baptiste Daroussin Subject: Re: FreeBSD_HEAD_amd64_gcc - Build #1147 - Still Failing Message-ID: <20160405165233.GA58466@FreeBSD.cs.nctu.edu.tw> References: <1782359103.186.1459767280942.JavaMail.jenkins@jenkins-9.freebsd.org> <744631082.192.1459853656450.JavaMail.jenkins@jenkins-9.freebsd.org> <5703E633.50805@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline In-Reply-To: <5703E633.50805@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Tue, 05 Apr 2016 19:27:02 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 05 Apr 2016 16:52:35 -0000 --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 05, 2016 at 09:22:11 -0700, Bryan Drewery wrote: > On 4/5/16 3:54 AM, jenkins-admin@FreeBSD.org wrote: > > + sudo pkg install -y devel/amd64-xtoolchain-gcc > > Updating FreeBSD repository catalogue... > > FreeBSD repository is up-to-date. > > All repositories are up-to-date. > > Build step 'Execute shell' marked build as failure >=20 > pkg install -y is returning an error now here where it didn't before. Yeah, Baptiste is working on a fix and I think it will be completed soon. I'll disable this step in the build process temporarily until pkg is fixed. Li-Wen --=20 Li-Wen Hsu https://lwhsu.org --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJXA+1QXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMDdENTNGNjUyMTUzMzVCNzA5NDNGODQ2 NzI3RTc3Qzg4NjJCNjU2AAoJEGcn53yIYrZWjT8P/1j+1zTlb1ktJIYZvsQitlj7 cqYHUqAoJB2t940ltK4Se8I+CQw7LuqDl8F/Iw5dGXD061Vn1fmEIb5jxLTnqZGY q7EtEMiUuENOzirIPbDr4IXtKuDBJ3pYROx0oorVTyHrSv7zD2s+asb8kHqtJ8Bq 52atLsknQ7Dy7huRtiJSxANHxWaoRRtXvgYrx2zBj5faXM8ABNHbsBCNTU+Wk74+ vogxqA/ejizuHi823umLD8t0wIvUijnM0DukK/xYXX79Etd1YcAiZRB+b1Yf50G9 TDgycm95nOUo/pVf0zHKmBzpH+CBMigQyLdwsgwTiU79bqmtpNkeVT5LVwnNtTzX FkwO+zOcDb54MWLUkH9Hn0doKaZO2NQZiTR83Z55diQyR7INO+rWtlN75mNOtHcV hZOR2RdRiNryFzh63RWdnd/di+7JPy3vLWg0at0l/57XIYqiYdrtyPN6bj5RDF1D hKd37taC7wyLR5St6niqPzJu0u0od6Rb+rWjGexQ2w9vt5YNoX+8ZwJxcZxmJguH FjLXMtwwivhqVH7NDvecCybF1EvMdPoWqDzYoUxacfYCMpWAqTXAnlA6Ml2Cy1Jd 0yqRYIGtPJtBLhgOCQ8vqeGu69zwtDQyy8WHdBjX5OtyHaWbEFWQVxyi6e+AgNWY DeTcFfYsaA75T5oECl/+ =YcbP -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH-- From owner-freebsd-current@freebsd.org Tue Apr 5 21:57: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 BA5E8B049C4 for ; Tue, 5 Apr 2016 21:57:52 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id AA8711ED1; Tue, 5 Apr 2016 21:57:52 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 9C3FE1C7B; Tue, 5 Apr 2016 21:57:52 +0000 (UTC) Date: Tue, 5 Apr 2016 21:57:52 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <1873316596.198.1459893472561.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #161 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 05 Apr 2016 21:57:52 -0000 See ------------------------------------------ Started by user rodrigc > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url https://github.com/freebsd/freebsd-ci.git # timeout=10 Fetching upstream changes from https://github.com/freebsd/freebsd-ci.git > git --version # timeout=10 > git -c core.askpass=true fetch --tags --progress https://github.com/freebsd/freebsd-ci.git +refs/heads/*:refs/remotes/origin/* > git rev-parse refs/remotes/origin/master^{commit} # timeout=10 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10 Checking out Revision 926429031e0241da821577c12b4b8f7db789e7e1 (refs/remotes/origin/master) > git config core.sparsecheckout # timeout=10 > git checkout -f 926429031e0241da821577c12b4b8f7db789e7e1 > git rev-list 926429031e0241da821577c12b4b8f7db789e7e1 # timeout=10 [Pipeline] Allocate node : Start Still waiting to schedule task Waiting for next available executor on jenkins-10.freebsd.org Running on jenkins-10.freebsd.org in /builds/workspace/FreeBSD_HEAD [Pipeline] node { [Pipeline] pwd [Pipeline] sh [FreeBSD_HEAD] Running shell script + sudo chown -R jenkins . [Pipeline] deleteDir [Pipeline] } //node [Pipeline] Allocate node : End [Pipeline] Allocate node : Start Still waiting to schedule task havoc.ysv.freebsd.org is offline Running on havoc.ysv.freebsd.org in /builds/workspace/FreeBSD_HEAD [Pipeline] node { [Pipeline] Change current directory : Start Running in /builds/workspace/FreeBSD_HEAD/freebsd-ci [Pipeline] dir { [Pipeline] git > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url https://github.com/freebsd/freebsd-ci.git # timeout=10 Fetching upstream changes from https://github.com/freebsd/freebsd-ci.git > git --version # timeout=10 > git -c core.askpass=true fetch --tags --progress https://github.com/freebsd/freebsd-ci.git +refs/heads/*:refs/remotes/origin/* > git rev-parse refs/remotes/origin/master^{commit} # timeout=10 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10 Checking out Revision 926429031e0241da821577c12b4b8f7db789e7e1 (refs/remotes/origin/master) > git config core.sparsecheckout # timeout=10 > git checkout -f 926429031e0241da821577c12b4b8f7db789e7e1 [Pipeline] } //dir [Pipeline] Change current directory : End [Pipeline] writeFile [Pipeline] } //node [Pipeline] Allocate node : End [Pipeline] Allocate node : Start Running on master in /usr/local/jenkins/workspace/FreeBSD_HEAD [Pipeline] node { From owner-freebsd-current@freebsd.org Tue Apr 5 23:32: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 1C1ADB046BA for ; Tue, 5 Apr 2016 23:32:20 +0000 (UTC) (envelope-from megas@alum.rpi.edu) Received: from tmde01oc.mail2world.com (tmde01oc.mail2world.com [209.67.128.209]) by mx1.freebsd.org (Postfix) with ESMTP id 029AB1C0B for ; Tue, 5 Apr 2016 23:32:19 +0000 (UTC) (envelope-from megas@alum.rpi.edu) Received: from mail pickup service by tmde01oc.mail2world.com with Microsoft SMTPSVC; Tue, 5 Apr 2016 16:32:09 -0700 X-CTCH-Spam: Unknown auth-sender: megas@alum.rpi.edu Received: from 10.1.106.119 unverified ([10.1.106.119]) by mwsmtp02oc.mail2world.com with Mail2World SMTP Server; Tue, 05 Apr 2016 16:32:07 -0700 MIME-Version: 1.0 From: Alexis Megas To: freebsd-current@freebsd.org Date: Tue, 05 Apr 2016 16:32:07 -0700 Subject: freebsd-update Message-Id: <6KIQMAN4VXT4.V3ETS7TFGAJL3@emweb04oc> X-Mailer: Microsoft CDO for Exchange 2000 X-OriginalArrivalTime: 05 Apr 2016 23:32:09.0648 (UTC) FILETIME=[5F8CC300:01D18F93] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 05 Apr 2016 23:32:20 -0000 Hello. Please consider a new clean command in the freebsd-update script. The modified manual and script are located at https://github.com/textbrowser/freebsd-update. Included are two diffs. Sorry for the long e-mail. --- /usr/src/usr.sbin/freebsd-update/freebsd-update.8    2015-08-12 10:21:35.000000000 -0400 +++ ./freebsd-update.8    2016-04-02 15:16:47.780095000 -0400 @@ -119,6 +119,12 @@  .Cm command  can be any one of the following:  .Bl -tag -width "rollback" +.It Cm clean +Remove the contents of +.Ar workdir . +(default: +.Ar /var/db/freebsd-update/ +).  .It Cm fetch  Based on the currently installed world and the configuration  options set, fetch all available binary updates. --- /usr/src/usr.sbin/freebsd-update/freebsd-update.sh    2015-08-12 10:21:35.000000000 -0400 +++ ./freebsd-update.sh    2016-04-02 15:26:57.990003000 -0400 @@ -53,6 +53,7 @@    --not-running-from-cron                 -- Run without a tty, for use by automated tools  Commands: +  clean        -- Clean workdir    fetch        -- Fetch updates from server    cron         -- Sleep rand(3600) seconds, fetch updates, and send an                    email if updates were found @@ -474,7 +475,7 @@              ;;            # Commands -        cron | fetch | upgrade | install | rollback | IDS) +        clean | cron | fetch | upgrade | install | rollback | IDS)              COMMANDS="${COMMANDS} $1"              ;;   @@ -559,6 +560,25 @@      mergeconfig  }   +# Perform sanity checks in preparation of cleaning workdir. +clean_check_params () { +    # Check that we are root.  All sorts of things won't work otherwise. +    if [ `id -u` != 0 ]; then +        echo "You must be root to run this." +        exit 1 +    fi + +    # Check that we have a working directory. +    _WORKDIR_bad="Directory does not exist or is not writable: " +    if ! [ -d "${WORKDIR}" -a -w "${WORKDIR}" ]; then +        echo -n "`basename $0`: " +        echo -n "${_WORKDIR_bad}" +        echo ${WORKDIR} +        exit 1 +    fi +    cd ${WORKDIR} || exit 1 +} +  # Set utility output filtering options, based on ${VERBOSELEVEL}  fetch_setup_verboselevel () {      case ${VERBOSELEVEL} in @@ -2047,6 +2067,11 @@      echo ${NOWTIME} > lasteolwarn  }   +# Clean workdir. +clean_run() { +        rm -fr * +} +  # Do the actual work involved in "fetch" / "cron".  fetch_run () {      workdir_init || return 1 @@ -3225,6 +3250,12 @@      default_params  }   +# Clean command. Allow non-interactive use. +cmd_clean () { +        clean_check_params +    clean_run || exit 1 +} +  # Fetch command.  Make sure that we're being called  # interactively, then run fetch_check_params and fetch_run  cmd_fetch () { From owner-freebsd-current@freebsd.org Wed Apr 6 01:42: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 B0ABFB04C92 for ; Wed, 6 Apr 2016 01:42:06 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id A3DD71612; Wed, 6 Apr 2016 01:42:06 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 2C9CC1D1E; Wed, 6 Apr 2016 01:42:06 +0000 (UTC) Date: Wed, 6 Apr 2016 01:42:05 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <1624186645.199.1459906925596.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1873316596.198.1459893472561.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1873316596.198.1459893472561.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is unstable: FreeBSD_HEAD #162 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 06 Apr 2016 01:42:06 -0000 See From owner-freebsd-current@freebsd.org Wed Apr 6 07:01: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 31898B064A9 for ; Wed, 6 Apr 2016 07:01:50 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 16B3419F7; Wed, 6 Apr 2016 07:01:50 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 9D4A61DE0; Wed, 6 Apr 2016 07:01:49 +0000 (UTC) Date: Wed, 6 Apr 2016 07:01:49 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <2014810599.200.1459926109053.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1624186645.199.1459906925596.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1624186645.199.1459906925596.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_HEAD #163 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 06 Apr 2016 07:01:50 -0000 See From owner-freebsd-current@freebsd.org Wed Apr 6 10:34: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 C88A2B04C4E for ; Wed, 6 Apr 2016 10:34:40 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id BBAC8169E; Wed, 6 Apr 2016 10:34:40 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 8039B1E76; Wed, 6 Apr 2016 10:34:40 +0000 (UTC) Date: Wed, 6 Apr 2016 10:34:38 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <373431611.201.1459938878773.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <2014810599.200.1459926109053.JavaMail.jenkins@jenkins-9.freebsd.org> References: <2014810599.200.1459926109053.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_HEAD #164 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 06 Apr 2016 10:34:40 -0000 See From owner-freebsd-current@freebsd.org Wed Apr 6 16:21: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 C2A76B06BBB; Wed, 6 Apr 2016 16:21:43 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::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 5A8261633; Wed, 6 Apr 2016 16:21:43 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm0-x241.google.com with SMTP id n3so14728714wmn.1; Wed, 06 Apr 2016 09:21:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=O0F6WbqA4XM3ckCDVvP4j8vDdf3E6HC/VUwe9IIInWw=; b=BeudNZ12oNOA9lbEgYu2QFJbpqsTvwYDNTYP2Vd+jR0GWVw0DbxHojjj6c1629tnqQ o1tul6SoEetIZT3LRprsE78wn/qKRYH8+8nJl/PW2kv0WUFUx+dWiGaOsdKdjom9dlpY a82VEftXi6vGFQXOTLdeDsWpsVPnrKzOQWbHiTCKrvZIl9aZ37uA0t4qxiU7MEUl/CxY fbJ4BWDBkGyyxfZwzqMDHQbjbfpw9pleKRKbrLCja7b/Jbx+YxJtV+i+rTW8KfgVoaMW tySzhvfL0cKpNyS/b66AykIWv1mZg684eTOHhK5ikGL9QmrKwoZcv+B2M66C+s8sllB+ qr0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=O0F6WbqA4XM3ckCDVvP4j8vDdf3E6HC/VUwe9IIInWw=; b=Bm7J5TquxZTBwJs5mXsLRNt7n+vLYc4FwfJP9O6bLyAgMh2FazPGHS9leM7p06Zwvn m5La3Qwr2bbW2bF3RRbezhVSNVSHke77K9slmo6dXJp5o0BkxORfIfFV9jwjzrJFShpy QeFyzJKP8+xYlRNw2ZASbAaoUW+nDyvCDrHf1P+roYAnwMSnfQtrO9Uhd81H765RQhO3 LDfPmLoA/zJEk36yE2ka2M2UXHj+/1MXaLcwpv5gndE3cMUTbkhMY6Wq+Us7IRa3Ku21 2z9XL7SiIf8qOX4pmd7R96GtIF7Rq1y8ZsUQd9PnhY2d9kCpE4qYPxWrRpNqOJkaRVO/ brkg== X-Gm-Message-State: AD7BkJL1jRE+2ETjWy/ExlJfCerdYszbh/mKaaPzwRT3dUg3iM+rOaQTnAL5LPrnWkIMuw== X-Received: by 10.194.144.10 with SMTP id si10mr24035470wjb.180.1459959701956; Wed, 06 Apr 2016 09:21:41 -0700 (PDT) Received: from ernst.home (p578E160A.dip0.t-ipconnect.de. [87.142.22.10]) by smtp.gmail.com with ESMTPSA id w75sm15693949wmw.4.2016.04.06.09.21.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Apr 2016 09:21:41 -0700 (PDT) Date: Wed, 6 Apr 2016 18:21:34 +0200 From: Gary Jennejohn To: Benjamin Kaduk Cc: freebsd-pkgbase@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: Packaging the FreeBSD base system with pkg(8) Message-ID: <20160406182134.246c7fcd@ernst.home> In-Reply-To: References: <20160127223323.GG98557@FreeBSD.org> <5703805A.7090204@harmless.hu> <14CD9D09-A32E-46ED-96CA-296FC04B8506@FreeBSD.org> <20160405122249.19419b9f@ernst.home> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.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.21 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, 06 Apr 2016 16:21:43 -0000 On Tue, 5 Apr 2016 13:42:48 -0400 (EDT) Benjamin Kaduk wrote: > On Tue, 5 Apr 2016, Gary Jennejohn wrote: > > > Will there be an option not to merge? I never update /etc when > > I do installworld because what I have works for me and I see no > > need to make any changes to a working system. > > And you expect your system to continue working after a new system user is > added? > Yes, because these are mentioned in UPDATING and I add them by hand. -- Gary Jennejohn From owner-freebsd-current@freebsd.org Wed Apr 6 17:56: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 78472B06738; Wed, 6 Apr 2016 17:56:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.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 5804914E7; Wed, 6 Apr 2016 17:56:41 +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 bigwig.baldwin.cx (Postfix) with ESMTPSA id C65FBB97D; Wed, 6 Apr 2016 13:56:39 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org, gljennjohn@gmail.com Cc: David Chisnall , Gergely Czuczy , Glen Barber , freebsd-pkgbase@freebsd.org, freebsd-current@freebsd.org Subject: Re: Packaging the FreeBSD base system with pkg(8) Date: Wed, 06 Apr 2016 10:56:08 -0700 Message-ID: <1602050.ZkkBBj7Otx@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20160405122249.19419b9f@ernst.home> References: <20160127223323.GG98557@FreeBSD.org> <14CD9D09-A32E-46ED-96CA-296FC04B8506@FreeBSD.org> <20160405122249.19419b9f@ernst.home> 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.2.7 (bigwig.baldwin.cx); Wed, 06 Apr 2016 13:56:39 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 06 Apr 2016 17:56:41 -0000 On Tuesday, April 05, 2016 12:22:49 PM Gary Jennejohn wrote: > On Tue, 5 Apr 2016 10:22:04 +0100 > David Chisnall wrote: > > > On 5 Apr 2016, at 10:07, Gergely Czuczy wrote: > > > > > > Also, quite often entries from the base system are changed > > > manually, think of root's/toor's password. Are such cases > > > going to be dealt with properly between upgrades, including > > > self-built-and-packaged base systems? Currently it can be a > > > PITA with mergemaster to handle things like master.passwd > > > properly between upgrades, automation so far wasn't famous on > > > doing it properly. > > > > Mergemaster uses a 2-way merge. It has the version that you > > have installed and the version that's being proposed for > > installation. Etcupdate and pkg perform a 3-way merge. It has > > the pristine version, the version that you have made changes > > to, and the new version. If you have changed an entry and so > > has the package, then you will get a conflict that you have to > > resolve manually. If you have added lines and so has the > > upstream version, then that should cleanly apply. Similarly, > > if you and upstream have both modified different lines, then > > there should be no problem. > > > > Will there be an option not to merge? I never update /etc when > I do installworld because what I have works for me and I see no > need to make any changes to a working system. Some parts of /etc (like /etc/rc.d) aren't really config files and need to be updated. You wouldn't have working wireless after a 10 -> 11 upgrade if you didn't update /etc/rc.d (and some helper scripts those use like /etc/rc.subr and /etc/network.subr). The files in /etc that are config files rarely change in FreeBSD in my experience compared with the "non-config" files like /etc/rc.d/*. I rarely encounter conflicts when using etcupdate personally, but both etcupdate and mergemaster can be configured to ignore individual files (or globs of files). -- John Baldwin From owner-freebsd-current@freebsd.org Wed Apr 6 20:14:54 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 0FC9DB0689B for ; Wed, 6 Apr 2016 20:14:54 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-157.reflexion.net [208.70.211.157]) (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 B19461097 for ; Wed, 6 Apr 2016 20:14:53 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 11563 invoked from network); 6 Apr 2016 20:15:09 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 6 Apr 2016 20:15:09 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.2) with SMTP; Wed, 06 Apr 2016 16:14:50 -0400 (EDT) Received: (qmail 24296 invoked from network); 6 Apr 2016 20:14:50 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 6 Apr 2016 20:14:50 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 83D5C1C407A; Wed, 6 Apr 2016 13:14:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Fwd: 11.0: head/lib/libsysdecode/Makefile for . . ./libsoft/usr/include uses CPP when XCPP needed? [Makefile.libcompat issue] From: Mark Millard In-Reply-To: <9952A60C-C3F1-40C3-AEAE-96AF6CA6E829@dsl-only.net> Date: Wed, 6 Apr 2016 13:14:44 -0700 Cc: Bryan Drewery Content-Transfer-Encoding: quoted-printable Message-Id: <6311C740-362F-45AE-9044-B72E61FC04C9@dsl-only.net> References: <3A6ED16B-F941-41FC-B844-50292894D5F4@dsl-only.net> <050EC0FA-21F9-4EAB-8771-B0F6E9DEE087@dsl-only.net> <9952A60C-C3F1-40C3-AEAE-96AF6CA6E829@dsl-only.net> To: FreeBSD Current , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 06 Apr 2016 20:14:54 -0000 The below forwards an example of a possibly more general issue not = necessarily limited to arm context of the example: in a cross compile = context the host CPP is in use via Makefile.libcompat not involving = "${XCPP}" and so various macro checks for the target context fail to = work. [The below and the material leading up to it was originally posted to = freebsd-arm.] =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Apr-4, at 2:02 PM, Mark Millard wrote: As a fix for >> --- all_subdir_lib/libsysdecode --- >> In file included from :17: >> In file included from = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/dev/nvme/nvme.h:36: >> In file included from = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/sys/param.h:135: >> In file included from = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/machine/param.h:49: >> = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/machine/acle-compat.h= :182:4: error: Unable to determine architecture version. >> # error Unable to determine architecture version. >> ^ I tested building an amd64 -> arm cross-build based on > # svnlite diff Makefile.libcompat > Index: Makefile.libcompat > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- Makefile.libcompat (revision 297514) > +++ Makefile.libcompat (working copy) > @@ -90,6 +90,7 @@ > DTRACE=3D"${LIB$COMPATDTRACE:U${DTRACE}}" > LIBCOMPATWMAKEFLAGS+=3D CC=3D"${XCC} ${LIBCOMPATCFLAGS}" \ > CXX=3D"${XCXX} ${LIBCOMPATCFLAGS} ${LIBCOMPATCXXFLAGS}" = \ > + CPP=3D"${XCPP}" \ > DESTDIR=3D${LIBCOMPATTMP} \ > -DNO_CPU_CFLAGS \ > MK_CTF=3Dno \ and it completed without getting an "error:". So this addition to = Makefile.libcompat may be one option for a fix. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Thu Apr 7 03:55: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 A9ABFB061A0; Thu, 7 Apr 2016 03:55:06 +0000 (UTC) (envelope-from seu.aba@gmail.com) Received: from mail-lf0-x241.google.com (mail-lf0-x241.google.com [IPv6:2a00:1450:4010:c07::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 4EDF11D8F; Thu, 7 Apr 2016 03:55:06 +0000 (UTC) (envelope-from seu.aba@gmail.com) Received: by mail-lf0-x241.google.com with SMTP id e190so6290408lfe.1; Wed, 06 Apr 2016 20:55:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=o0DSxnfdt3CJksCQTLMlpek1zTv3H1IffmjAWaPQ9MA=; b=Xit8v8tMpa57SfBbRCpWn0hHxT1fuViZSGGPZL0t1eAeTa2fqYMTAR5XFv5IdGBXhF pbuPrPT0lfMVcfKnaehj7DQGQnw5JCdavosUEqgnrkhoan/srtiq5t5iCcA0y+Wnuy3a N26VcLNM3Jdujv3jn97prCRu1wY2ZjnQ8uzMxOSnxPelODQJ2tXOGZOpDPMq4+ojJ/ss /oLWqdqVVoe4m67YRI+3mB0dm9ovnt/wDS3Fe0MeDfX7fmmq7k4x0jxv0uOmxg3+EA3K XxYf0DqXimlQz4wyGGf5kqQOvwmbvEAo3umnAGmxX+zBarcAri6vYH6RRBje0IBydYWn Nd2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=o0DSxnfdt3CJksCQTLMlpek1zTv3H1IffmjAWaPQ9MA=; b=fTe6kIlpMcEa6FmPEalvAPAuRIoJshB8qG2hj2+UUKyZ9VahNqv281IxVcXEQHyuqf GhgYs4Le9bO2VgNhXCGmV6kdjfchEqSWBxfwjysC3zLrV2pVeAyo60h8TaPzyHxO3z6i vgRr/sGpupN4fM4MyUSF1fs77g0X1OR6tLsclwU1pYYr4bGLpLnByp8FP5BHLvKwgnEU LjisIA1xpxay3KOi2uazhZU0uFy7e8bTpfMDUCaaNNs+/h6zN1iAYIw1vhLvFqXalAxi RBnilo6O+hr49ZuNEJfCCcPb4+LmdZNGbaVLeJuCn06Sh4ohPZ01zppIKi5BI0FZyf50 i7VQ== X-Gm-Message-State: AD7BkJJRG5ZBkVG+w9yEf2gQg2GYqNU5iew7Fgl/pBJLeDYmfO0hFZVYDFMKuFE0BdUcvVT+WsKvmKAfNcPNFA== MIME-Version: 1.0 X-Received: by 10.25.160.10 with SMTP id j10mr309019lfe.31.1460001303417; Wed, 06 Apr 2016 20:55:03 -0700 (PDT) Received: by 10.25.136.133 with HTTP; Wed, 6 Apr 2016 20:55:03 -0700 (PDT) Date: Wed, 6 Apr 2016 23:55:03 -0400 Message-ID: Subject: So, what I have read and seen From: Seu Aba To: freebsd-hackers@freebsd.org, freebsd-desktop@freebsd.org, freebsd-current@freebsd.org, freebsd-ppc@freebsd.org, freebsd-questions@freebsd.org, info@freebsd.org, dru@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 07 Apr 2016 03:55:06 -0000 Is that the lot of you have treated a homeless man with disrespect simply because he was open and honest about what goes on in his life. I have also read about his ideas and they make perfect sense to me. Aiding and assisting the blind while standing up for others is not a bad thing. The reaction he received from most of you borders on harassment which is illegal in a lot of places. He did not ask any of you for anything and refused both money and help to prove his honesty. Not only that, but, you allow someone known for being rude to convince you that the man did wrong without bothering to gather any other information. If you are not aware of the rudeness and social manipulation of deRaadt, you need to rethink things through. More than one person left OpenBSD because of his lack of respect. It also seems that David Wolfskill - one of the info@freebsd members, had treated this homeless man with disrespect. There is something seriously wrong with all of you to treat such a person with disdain and disrespect. Don't say shit. This man received news that his mother was raped and beat and some of you make jokes about that situation. What in the fuck is wrong with you people? What if that happened to your mother or sister or wife or daughter? How would you handle the situation? Don't say a fucking thing. All of you owe that man an apology. From owner-freebsd-current@freebsd.org Thu Apr 7 09:34: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 596E2B07E01 for ; Thu, 7 Apr 2016 09:34:33 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9042B1AAB for ; Thu, 7 Apr 2016 09:34:32 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA02719 for ; Thu, 07 Apr 2016 12:34:23 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1ao6KV-000BT6-QO for freebsd-current@FreeBSD.org; Thu, 07 Apr 2016 12:34:23 +0300 Subject: Opteron 6100-series "Magny-Cours" [Was: [HEADSUP] new x86 smp topology detection code] To: FreeBSD Current References: <201604041609.u34G9TCd022548@repo.freebsd.org> <570296F3.8090307@FreeBSD.org> From: Andriy Gapon Message-ID: <5706297C.3050009@FreeBSD.org> Date: Thu, 7 Apr 2016 12:33:48 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <570296F3.8090307@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 07 Apr 2016 09:34:33 -0000 If anyone uses FreeBSD head on a system with "Magny-Cours" CPU(s), could you please test the following patch? http://dpaste.com/0XRSXZB.txt I am interested in kern.sched.topology_spec sysctl before and after the patch. Also, lines containing "ID shift" from a dmesg of a verbose boot (before and after). Thank you! On 04/04/2016 19:31, Andriy Gapon wrote: > > > I've just committed new code for detecting SMP (processor and cache) topology on > x86 systems. Please be aware. > > If you get any panics or crashes that look like they might be caused by this > change please send a copy of a report to me. > > Another thing to watch is kern.sched.topology_spec. > Please check if the reported topology reasonably matches what you expect on your > system. > You can install hwloc package (devel/hwloc) and then run lstopo -p --no-io to > double-check the topology (--output-format ascii would produce a nice ASCII-art > diagram). > > I hope that you see only improvements :-) > > -------- Forwarded Message -------- > Subject: svn commit: r297558 - in head/sys: kern sys x86/x86 > Date: Mon, 4 Apr 2016 16:09:29 +0000 (UTC) > From: Andriy Gapon > To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org > > Author: avg > Date: Mon Apr 4 16:09:29 2016 > New Revision: 297558 > URL: https://svnweb.freebsd.org/changeset/base/297558 > > Log: > new x86 smp topology detection code > > Previously, the code determined a topology of processing units > (hardware threads, cores, packages) and then deduced a cache topology > using certain assumptions. The new code builds a topology that > includes both processing units and caches using the information > provided by the hardware. > > At the moment, the discovered full topology is used only to creeate > a scheduling topology for SCHED_ULE. > There is no KPI for other kernel uses. > > Summary: > - based on APIC ID derivation rules for Intel and AMD CPUs > - can handle non-uniform topologies > - requires homogeneous APIC ID assignment (same bit widths for ID > components) > - topology for dual-node AMD CPUs may not be optimal > - topology for latest AMD CPU models may not be optimal as the code is > several years old > - supports only thread/package/core/cache nodes > > Todo: > - AMD dual-node processors > - latest AMD processors > - NUMA nodes > - checking for homogeneity of the APIC ID assignment across packages > - more flexible cache placement within topology > - expose topology to userland, e.g., via sysctl nodes > > Long term todo: > - KPI for CPU sharing and affinity with respect to various resources > (e.g., two logical processors may share the same FPU, etc) > > Reviewed by: mav > Tested by: mav > MFC after: 1 month > Differential Revision: https://reviews.freebsd.org/D2728 > > Modified: > head/sys/kern/subr_smp.c > head/sys/sys/smp.h > head/sys/x86/x86/mp_x86.c -- Andriy Gapon From owner-freebsd-current@freebsd.org Thu Apr 7 21:00: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 36B27B072A9 for ; Thu, 7 Apr 2016 21:00:20 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) (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 03DE91890 for ; Thu, 7 Apr 2016 21:00:20 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: from mail-lf0-f54.google.com (unknown [209.85.215.54]) (Authenticated sender: gugus69) by smtp6-g21.free.fr (Postfix) with ESMTPSA id C3484822E0 for ; Thu, 7 Apr 2016 22:56:09 +0200 (CEST) Received: by mail-lf0-f54.google.com with SMTP id j11so65721773lfb.1 for ; Thu, 07 Apr 2016 14:00:16 -0700 (PDT) X-Gm-Message-State: AD7BkJI84hqb74dmvTmizzzGAIJkrBcFw71cgwgj5sDewEYfox7OfRPjMjFjFZQenSIxup6st+kRaZH6JNJrPA== X-Received: by 10.25.84.17 with SMTP id i17mr2214709lfb.136.1460062816380; Thu, 07 Apr 2016 14:00:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.166.138 with HTTP; Thu, 7 Apr 2016 13:59:56 -0700 (PDT) From: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Date: Thu, 7 Apr 2016 22:59:56 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Keeping OptionalObsoleteFiles.inc up to date To: "freebsd-current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 07 Apr 2016 21:00:20 -0000 Hi, I'm trying to use "make delete-old" specifying WITHOUT_ keyword for removing some no-more used set of files. I've start by testing WITHOUT_TOOLCHAIN: - Some of files related to clang are correctly delete - But there are still lot's of others (like /usr/bin/cc) Then I've checked tools/build/mk/OptionalObsoleteFiles.in and found that lot's files are missing in the ".if ${MK_TOOLCHAIN} == no" section. I've started a new run of phk's build_options_survey script: https://people.freebsd.org/~olivier/build_option_survey_20160406/ And wonder if it's possible to automatically generate the list of conditional files to be put in OptionalObsoleteFiles.in from the result of a build_option_survey script ? Regards, Olivier From owner-freebsd-current@freebsd.org Thu Apr 7 21:28: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 88E79B07D41 for ; Thu, 7 Apr 2016 21:28:46 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 7BE6F1376; Thu, 7 Apr 2016 21:28:46 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 9460E523; Thu, 7 Apr 2016 21:28:46 +0000 (UTC) Date: Thu, 7 Apr 2016 21:28:46 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <311686471.6.1460064526547.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <373431611.201.1459938878773.JavaMail.jenkins@jenkins-9.freebsd.org> References: <373431611.201.1459938878773.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #165 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 07 Apr 2016 21:28:46 -0000 See ------------------------------------------ Started by an SCM change > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url https://github.com/freebsd/freebsd-ci.git # timeout=10 Fetching upstream changes from https://github.com/freebsd/freebsd-ci.git > git --version # timeout=10 > git -c core.askpass=true fetch --tags --progress https://github.com/freebsd/freebsd-ci.git +refs/heads/*:refs/remotes/origin/* > git rev-parse refs/remotes/origin/master^{commit} # timeout=10 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10 Checking out Revision 926429031e0241da821577c12b4b8f7db789e7e1 (refs/remotes/origin/master) > git config core.sparsecheckout # timeout=10 > git checkout -f 926429031e0241da821577c12b4b8f7db789e7e1 > git rev-list 926429031e0241da821577c12b4b8f7db789e7e1 # timeout=10 [Pipeline] Allocate node : Start Still waiting to schedule task Waiting for next available executor on jenkins-10.freebsd.org Resuming build Aborted by rodrigc [Pipeline] Allocate node : End [Pipeline] Allocate node : Start Running on master in /usr/local/jenkins/workspace/FreeBSD_HEAD [Pipeline] node { [Pipeline] step From owner-freebsd-current@freebsd.org Thu Apr 7 21:43: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 0483BB081BD for ; Thu, 7 Apr 2016 21:43:40 +0000 (UTC) (envelope-from jlehen@gmail.com) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 8F0DB1D9A for ; Thu, 7 Apr 2016 21:43:39 +0000 (UTC) (envelope-from jlehen@gmail.com) Received: by mail-wm0-x233.google.com with SMTP id u206so103991316wme.1 for ; Thu, 07 Apr 2016 14:43:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to; bh=0DFcNuo0X0lbfeWPiaDA72bLlRWcSLvGt5MiNOkKy9o=; b=zrKrNieH4JJHJTiuLwdqCzmA9IlxJT5f+mTdOh2QPfNfdDEST70O7ctBXdNxxY3mnB /ibfzMo3kjvnijdrlKwXgnbaNgiKFGAMZ3tKJjNFSmYSdfSztaM7RZToojL9QrjryQXx 79jSIldTwjEaXcMMvdu+Uo14F+V8h4yiL4OpPz4wWIb78kH5iRjrG0pUhDMY4xMQTzLQ 7Is2tWpsc+ZdMjVkQJicgK15rqGt/w5XewuzH1Dxt/ljIXOnV5sKhQiUUv0NDgA8rjKd wCDUJdP0fx91VOMYy9uRhutxErKkHbT5A6tBBuKLB43e+ibE1R4l9K/fnk52SdvNZj3Z sI4A== 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:date:message-id:subject:from :to; bh=0DFcNuo0X0lbfeWPiaDA72bLlRWcSLvGt5MiNOkKy9o=; b=Fp5aHZCwP+spGdWOs4+fZ+jwkTsDTn/uQfAnsJY1zsraCYHEY5ft7zcIhBFmucXPeI zDKA0ZsleRYKJrYZ8wzGQGzgJf7w+E20/I8JX3hlQuzqhmYfCbl4zlg8GaKgdEUC3Fk2 MVBb3Teopgv9E6q78kbPt9mXuhdieIA+2n5aCcieUcg0GWuOra0iIWpC5X2iIYEEtwUb 4ZSgEJ1CiEywtHECdYv2DkTdajgmTt0L8C4nQkodumUbkItsm5K5GV+shA1WkzRHlhta eUtgo1IrGMwNTLCagI3jZPW3karL0t/dDuFBCahJEJN1W7awKMrBZO2jQVnLf3JALK5C lFcA== X-Gm-Message-State: AD7BkJKCU0Vxhx5wZv0G0dFLirn5Zrxh2vbQspsWifVYD08tzHHaNVKy4OmYO4N+LljowNnUCLSYe9MoxI8unw== MIME-Version: 1.0 X-Received: by 10.194.121.70 with SMTP id li6mr5717025wjb.164.1460065418250; Thu, 07 Apr 2016 14:43:38 -0700 (PDT) Sender: jlehen@gmail.com Received: by 10.28.104.139 with HTTP; Thu, 7 Apr 2016 14:43:38 -0700 (PDT) Date: Thu, 7 Apr 2016 23:43:38 +0200 X-Google-Sender-Auth: LokWolNP9eJZE_25RwFGkBDLSRk Message-ID: Subject: Panic in pfsync_sendout() From: Jeremie Le Hen To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 07 Apr 2016 21:43:40 -0000 Hey, I happen to have pfsync in my kernel but I don't use it. I do use pf though. It panics when my jails are starting. No idea if it's related or not. I managed to grab a core with "call doadump()" but I can't open it with kgdb(1). I get: # kgdb /boot/kernel.panic/kernel vmcore.3 [...] Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. kgdb: kvm_read: invalid address (0x0) #0 0x0000000000000000 in ?? () "bt" doesn't work, "info threads" yields hundreds of: * 51 Thread 0 (PID=0: /zil_clean) 0x0000000000000000 in ?? () Why is that? This should work since How can I get a proper one? DDB spit the following stacktrace (this is amd64): Fatal trap 9: general protection fault while in kernel mode [...] pfsync_sendout() at pfsync_sendout+0x1d0 pfsyncintr() at pfsyncintr+0x42 intr_event_execute_handlers() ithread_loop() -- Jeremie Le Hen jlh@FreeBSD.org From owner-freebsd-current@freebsd.org Thu Apr 7 22:14: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 99B8BB08B15 for ; Thu, 7 Apr 2016 22:14:10 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (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 21DE41D62; Thu, 7 Apr 2016 22:14:10 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-lb0-x234.google.com with SMTP id os9so14316189lbb.2; Thu, 07 Apr 2016 15:14:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=BpqTQLO5RlcQxsQT0I7nLWsIwaFcSujPvPhb7I0AKBw=; b=HEePJbgIz5touNTEC3TpcHQL9lAP3WiuqT32Q/ZbyEpBhvULYRYMXnr5xRdzL3Gjtw 5uRKbDq3iR80hi/fdpkNydAlXU0DshXk3tQN86s1RIfxDNz4zeJfSVV/yEQOsvGtU3QF TrKDwafyTallgiwYkQ52l0msmBAogqKV1sLLOTsOjuroi6dETJu/j3CX+AVsVXFWNCG3 z4IcUHMdbE75DZ9NyHZ3FgI/GraxaIm94hqSIoYm6/7M0+VEHHMzGEp/fO48qd1RCuG0 neP88i6kc944dxMSe5faoaJn57mpdGlKvMd4bl3zn6/0tzYgq3lVGySwRoWf2RwE6oAD D/Eg== 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:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=BpqTQLO5RlcQxsQT0I7nLWsIwaFcSujPvPhb7I0AKBw=; b=bN3i/TV5yN4PYoOVUFjTXLEh5clyrzPNcTaqXBpiknrNIrDhDdZU/Bqp7m7gYnskdS MB0kHHyWFHQ8z78n5B+CCkusoYTwRET8KGEdYRtD3WuZYR3Gh36Ect/miLdsZKStC2vk Sgm625Fu/E2XRGeoYQ6BsUbul1sJLhvWElifNr//gptvfsVnVboNBeCEoP97nvqpU/DS On8N6/NiFJGUvW0LkozHfqX9iQ13/Bdd22ALlZ4+kCrw1o9ZgRMU+ORrhvxfogevP7zT pz9E75i4+HtZeIgbrAESVHUzmPqd7vjKozOoK+8gIUfqIitillEJbT148pP9nFPtCs+x k4WQ== X-Gm-Message-State: AD7BkJKlBGPv6y4F163rj/PaN2yKSZYfG91rk5Rvyf1IxuVIwCWBuWqTuXq9l6wFWTR9WQrrKYW0pQr2/n9pkw== MIME-Version: 1.0 X-Received: by 10.112.140.41 with SMTP id rd9mr2357938lbb.138.1460067248376; Thu, 07 Apr 2016 15:14:08 -0700 (PDT) Received: by 10.112.236.33 with HTTP; Thu, 7 Apr 2016 15:14:08 -0700 (PDT) In-Reply-To: References: Date: Thu, 7 Apr 2016 15:14:08 -0700 Message-ID: Subject: Re: Keeping OptionalObsoleteFiles.inc up to date From: Ngie Cooper To: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Cc: "freebsd-current@freebsd.org" , Dmitry Marakasov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 07 Apr 2016 22:14:10 -0000 On Thu, Apr 7, 2016 at 1:59 PM, Olivier Cochard-Labb=C3=A9 wrote: > Hi, > > I'm trying to use "make delete-old" specifying WITHOUT_ keyword for > removing some no-more used set of files. > > I've start by testing WITHOUT_TOOLCHAIN: > - Some of files related to clang are correctly delete > - But there are still lot's of others (like /usr/bin/cc) > > Then I've checked tools/build/mk/OptionalObsoleteFiles.in and found that > lot's files are missing in the ".if ${MK_TOOLCHAIN} =3D=3D no" section. > > I've started a new run of phk's build_options_survey script: > https://people.freebsd.org/~olivier/build_option_survey_20160406/ > > And wonder if it's possible to automatically generate the list of > conditional files to be put in OptionalObsoleteFiles.in from the result o= f > a build_option_survey script ? amdmi3 had a method for doing this, but I think it was a bit of a brute force approach (I could be wrong). The release-pkg project branch method seems like the best way to go about it though because it would kind of do the sanity checking for us... Thanks! -Ngie From owner-freebsd-current@freebsd.org Fri Apr 8 00:53: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 DC0FBB07947 for ; Fri, 8 Apr 2016 00:53:41 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id C1FE010AC; Fri, 8 Apr 2016 00:53:41 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 0390E5AD; Fri, 8 Apr 2016 00:53:41 +0000 (UTC) Date: Fri, 8 Apr 2016 00:53:40 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <1248754585.0.1460076820532.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <311686471.6.1460064526547.JavaMail.jenkins@jenkins-9.freebsd.org> References: <311686471.6.1460064526547.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is unstable: FreeBSD_HEAD #166 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 08 Apr 2016 00:53:42 -0000 See From owner-freebsd-current@freebsd.org Fri Apr 8 01:42: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 AB5B1B08850 for ; Fri, 8 Apr 2016 01:42:08 +0000 (UTC) (envelope-from ted-lists@xy0.org) Received: from mail.xy0.org (mail.xy0.org [107.170.177.202]) by mx1.freebsd.org (Postfix) with ESMTP id 8ADC7194A for ; Fri, 8 Apr 2016 01:42:08 +0000 (UTC) (envelope-from ted-lists@xy0.org) Received: from xbook2.techmachine.net (unknown [23.31.151.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.xy0.org (Postfix) with ESMTPSA id 1724F412B6 for ; Fri, 8 Apr 2016 01:42:07 +0000 (UTC) Subject: Re: Booting FreeBSD on a RPI3 To: freebsd-current@freebsd.org References: <1A9A04FA-3247-4A26-81F0-F11ECAD43F5A@galasoluciones.com> From: "Ted W." Message-ID: <57070C6F.6070309@xy0.org> Date: Thu, 7 Apr 2016 21:42:07 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <1A9A04FA-3247-4A26-81F0-F11ECAD43F5A@galasoluciones.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 08 Apr 2016 01:42:08 -0000 I too anxiously await the widespread availability of FreeBSD on the Pi3. If you're like me and just can't wait the image below does boot but does not have network support: https://people.freebsd.org/~andrew/arm64/rpi3-20160306.img.xz On 03/30/2016 04:11 PM, Gala IT wrote: > Nice to know, thanks a lot :) > >> El 30 març 2016, a les 1:38, Adrian Chadd va escriure: >> >> Hi, >> >> It's under active development right now. Stay tuned. >> >> >> -a >> >> >> On 29 March 2016 at 13:58, Gala IT wrote: >>> Hi, >>> >>> Being that it’s a 64-bit system and RPI2 images don’t work, is there any procedure already established to build an image to boot on a Raspberry Pi 3? >>> >>> Should Crochet work? How? >>> >>> Thanks, >>> David. >>> _______________________________________________ >>> 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" > _______________________________________________ > 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 Fri Apr 8 06:58: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 8EE18B07167 for ; Fri, 8 Apr 2016 06:58:12 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 820EA1948; Fri, 8 Apr 2016 06:58:12 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id ADAD16ED; Fri, 8 Apr 2016 06:58:11 +0000 (UTC) Date: Fri, 8 Apr 2016 06:58:11 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <1161594143.1.1460098691257.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1248754585.0.1460076820532.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1248754585.0.1460076820532.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_HEAD #167 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 08 Apr 2016 06:58:12 -0000 See From owner-freebsd-current@freebsd.org Fri Apr 8 08:31:19 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 7672BB08FFB for ; Fri, 8 Apr 2016 08:31:19 +0000 (UTC) (envelope-from smokehydration@tutanota.com) Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.tutanota.de", Issuer "StartCom Class 2 Primary Intermediate Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 232261048 for ; Fri, 8 Apr 2016 08:31:18 +0000 (UTC) (envelope-from smokehydration@tutanota.com) Received: from localhost (unknown [127.0.0.1]) by w1.tutanota.de (Postfix) with ESMTP id 837A0FA8350 for ; Fri, 8 Apr 2016 08:22:39 +0000 (UTC) Received: from w1.tutanota.de ([127.0.0.1]) by localhost (w1.tutanota.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsebIvw2XbDs for ; Fri, 8 Apr 2016 08:22:37 +0000 (UTC) Received: from w1.tutanota.de (unknown [127.0.0.1]) by w1.tutanota.de (Postfix) with ESMTP id 9C139FA8396 for ; Fri, 8 Apr 2016 08:22:37 +0000 (UTC) Date: Fri, 8 Apr 2016 09:22:37 +0100 (BST) From: To: Cc: Message-ID: Subject: RE: Revision 297176 - hyperv/evttimer: Use an independent message slot so that it can work MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 08 Apr 2016 08:31:19 -0000 Hello I recently update one of my many vms from an older CURRENT revision r297196= =20 to r297659 and on reboot it just panics with the following: FreeBSD clang version 3.8.0 (tags/RELEHSE_380/final 262564) (based on LLVM= =20 3.8.0 ) VT(vga): text 80x25 Timecounter "Hyper-V" frequency 10000000 Hz quality 10000000 Kernel trap 9 with interrupts disabled Fatal trap 9: general protection fault while in kernel mode cpuid =3D 0: apic id =3D 00 instruction pointer=C2=A0=C2=A0=C2=A0=C2=A0 =3D 0x20:0xffffffff8100d6?9 stack pointer=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =3D 0x28:oxffffffff820d5c30 frame pointer=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =3D 0x28:oxffffffff820d5c40 code segment=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 =3D base 0x0, limit 0xfffff, type 0x1b =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D DPL 0, = pres 1, long 1, def32 0, gran 1 processor eflags=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D IOPL =3D 0 current process=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D 0 () [ thread pid 0 tid 0 ] stopped at=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 hv_get_timecount+0x9:=C2=A0=C2=A0 = rdmsr db) wh Tracing pid 0 tid 0 td 0xffffffff81d0eff0 hv_get_timecount() at hv_get_timecount+0x9/frame 0xffffffff820d5c40 tc_init() at tc_init+0x251/frame 0xffffffff820d5c90 mi_startup() at mi_startup+0x118/frame 0xffffffff820d5cb0 btext() at btext+ox2c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D db> I changed hv_hv.c back to the previous revision (297176) and no panics unde= r=20 Xen VM. Thanks! p.s. not sure why Xen gets detected as HyperV From owner-freebsd-current@freebsd.org Fri Apr 8 09:29: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 B4109B0884E for ; Fri, 8 Apr 2016 09:29:08 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::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 6FD20102E for ; Fri, 8 Apr 2016 09:29:08 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by mail-vk0-x22e.google.com with SMTP id t129so45057312vkg.2 for ; Fri, 08 Apr 2016 02:29:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=6TRq6AT8jynszfXIAgtXJsoHhV8NjkQJsoYGyRnMH7s=; b=tBEAUFRitZa6tePuhCV0TY1CicpFY7MHS+5vLZyZB+3H+t1FUs+6CzZdPSg2O6gQkA brbmj09RtcSGzoSLTKjldrrd7XHcWWQO+/7D4HlkeO8YraxBrYR2REZnh68l+PoW557D JtwoH4e7BjAFcVg4mfsxakNG5Vn++ME0P/2SZkGV+0pDFwBORA6V4xOziHDE1tYxMlNQ Fr4Lk+S5viINQXhvIxHozKUFGzuRAozOwJNAL93Jwbl83aNLLsBQNXynjOuoLOkphLHd uJt7oHiBOK2wRb853ZY5OysW/H4x8poaqhCg61mWzLs1Hv7HVzgDQ14eHsYW0zMMzwBG mb+w== 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:date :message-id:subject:from:to:cc; bh=6TRq6AT8jynszfXIAgtXJsoHhV8NjkQJsoYGyRnMH7s=; b=YpgQmj1VvYOhWI9VyKLzPSa0nr91+5D5IRlMMUmMq37n3XtlMsDx8yiEMB95rS9c/T jb91iep1rrk4+x9soddasZ44m8tA3J8CEJ6vyqhk/uWe2QtGu3ynlSnMOiyrZycejuys KMdwZhjVY80sfIpBRk/n0jjoBiWQqcH0r8Ys2QMDh2YJqH69U410cixj8jfVAk6qdX0C VvB2mAbfzezmtZVFJ2Bu4r5+Ll13kUgdyDbY70sd7nT+p4PfcsUPvypNh83jGSzLENW1 zatDcfKXvrko59IPx9KjZ696EUcrUPufMVcg8p+JSFz1EV9fCqJtzAk1us0c8YtDcNP2 DNQw== X-Gm-Message-State: AD7BkJIavLD7zdwIj7rNCgFHsEY5oljQ4O6mYyUh9zlWPQGVOy2ttVfg/muqIalhfYxjUGQIoL2fV2yQI7K4/Q== MIME-Version: 1.0 X-Received: by 10.31.168.1 with SMTP id r1mr3677120vke.8.1460107747171; Fri, 08 Apr 2016 02:29:07 -0700 (PDT) Sender: sepherosa@gmail.com Received: by 10.176.64.130 with HTTP; Fri, 8 Apr 2016 02:29:07 -0700 (PDT) In-Reply-To: References: Date: Fri, 8 Apr 2016 17:29:07 +0800 X-Google-Sender-Auth: Qov8BVwcGwULy3rbA9vEDV0JTrg Message-ID: Subject: Re: Revision 297176 - hyperv/evttimer: Use an independent message slot so that it can work From: Sepherosa Ziehau To: smokehydration@tutanota.com Cc: "freebsd-current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 08 Apr 2016 09:29:08 -0000 I have reverted this change. It will be brought back, after some code refactoring. On Fri, Apr 8, 2016 at 4:22 PM, wrote: > > Hello > > I recently update one of my many vms from an older CURRENT revision r297196 > to r297659 and on reboot it just panics with the following: > > FreeBSD clang version 3.8.0 (tags/RELEHSE_380/final 262564) (based on LLVM > 3.8.0 > ) > VT(vga): text 80x25 > Timecounter "Hyper-V" frequency 10000000 Hz quality 10000000 > Kernel trap 9 with interrupts disabled > > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 0: apic id = 00 > instruction pointer = 0x20:0xffffffff8100d6?9 > stack pointer = 0x28:oxffffffff820d5c30 > frame pointer = 0x28:oxffffffff820d5c40 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = IOPL = 0 > current process = 0 () > [ thread pid 0 tid 0 ] > stopped at hv_get_timecount+0x9: rdmsr > db) wh > Tracing pid 0 tid 0 td 0xffffffff81d0eff0 > hv_get_timecount() at hv_get_timecount+0x9/frame 0xffffffff820d5c40 > tc_init() at tc_init+0x251/frame 0xffffffff820d5c90 > mi_startup() at mi_startup+0x118/frame 0xffffffff820d5cb0 > btext() at btext+ox2c = > db> > > I changed hv_hv.c back to the previous revision (297176) and no panics under > Xen VM. > > Thanks! > > p.s. not sure why Xen gets detected as HyperV > -- Tomorrow Will Never Die From owner-freebsd-current@freebsd.org Fri Apr 8 10:26: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 8D630B07EA4 for ; Fri, 8 Apr 2016 10:26:52 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 808631F42; Fri, 8 Apr 2016 10:26:52 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id AA63280D; Fri, 8 Apr 2016 10:26:51 +0000 (UTC) Date: Fri, 8 Apr 2016 10:26:50 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <2087459086.0.1460111210809.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1161594143.1.1460098691257.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1161594143.1.1460098691257.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_HEAD #168 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 08 Apr 2016 10:26:52 -0000 See From owner-freebsd-current@freebsd.org Fri Apr 8 13:16: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 58009B08B1F for ; Fri, 8 Apr 2016 13:16:08 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::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 135431161 for ; Fri, 8 Apr 2016 13:16:08 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qg0-x231.google.com with SMTP id j35so89703143qge.0 for ; Fri, 08 Apr 2016 06:16:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=6Kha6KUoz3t28J50RzhXljONc+/kSKjZF13S4STnpNU=; b=R+86+55uYqkXhgwZmUs5EXnPW/m1Qi3daHmgznj38kjJVuAlh7CAWtc2KJPlb/Uqwm GZ0ti0jQxNDFT1ksrtseahgp6pYc9C4JrhbNieMX+KHq3h1pRjGT2/uE29I7tvkI4A/e 2PoMAItt9eMB9BpE3dZTRL1WtWpb/jDq4xADWxDNF+s5dSyvhw/DFBCgcL/lZcQY7tP2 z/FVytntFJyj9Rpj8rTY9D9jWWJFDlZp69Sf78kYYczTm1uK3+BdLjNIJX/K3rxPrQs6 Up8rY5k8Ya9J3orAgTumQPt9dewlYu5jCysRpYtsALCHK/dCkjwhU/JpbxgQcU5OthAg ejhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=6Kha6KUoz3t28J50RzhXljONc+/kSKjZF13S4STnpNU=; b=E5+NgdbrDLfeYwGkhwz1Evp0GhAa78oFMXQeBLOCjFA0a0zPxd/lvJmwbmgL0AeJ7W RotmdJlNvaeRfAWTojA2AStfi+c6A4xhZzkIFIeMn/3PRjdGh1n6w2DzUgpVi/FWj0jF wK4IxlR6jtZg1DcjF8qEbx9863Xj8QFlpJZ/ppZ91C6DbZ3u+WU+gAYIt/SLdEX7Xcyb OLEhddtgbhK6AFQyRbjLQKj543JfmJjImLhJ7WldeutC5LyKDRsWdrZCWGMTBYXTSPXg XwR1RHbSNxFa145v8D7TZtk8NKvqtpzp8uOMdxiZV0N1CFqqycqWdpJ8NdoldNqboMuX KxsA== X-Gm-Message-State: AD7BkJLgn1TUEdoJNsTfR95/YXcrNtTlv8mKiThuKJcsysWwbhqn6M5KKOkzbWcGZq+3u3x+ X-Received: by 10.140.253.197 with SMTP id y188mr11056502qhc.67.1460121366933; Fri, 08 Apr 2016 06:16:06 -0700 (PDT) Received: from mutt-hardenedbsd ([63.88.83.105]) by smtp.gmail.com with ESMTPSA id h9sm5442613qhh.29.2016.04.08.06.16.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Apr 2016 06:16:05 -0700 (PDT) Date: Fri, 8 Apr 2016 09:16:04 -0400 From: Shawn Webb To: "Ted W." Cc: freebsd-current@freebsd.org Subject: Re: Booting FreeBSD on a RPI3 Message-ID: <20160408131604.GB78157@mutt-hardenedbsd> References: <1A9A04FA-3247-4A26-81F0-F11ECAD43F5A@galasoluciones.com> <57070C6F.6070309@xy0.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="H+4ONPRPur6+Ovig" Content-Disposition: inline In-Reply-To: <57070C6F.6070309@xy0.org> X-Operating-System: FreeBSD mutt-hardenedbsd 11.0-CURRENT-HBSD FreeBSD 11.0-CURRENT-HBSD X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 08 Apr 2016 13:16:08 -0000 --H+4ONPRPur6+Ovig Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I also did a build based on HardenedBSD. Networking works. https://hardenedbsd.org/~shawn/rpi3/2016-04-04/rpi3.img.xz On Thu, Apr 07, 2016 at 09:42:07PM -0400, Ted W. wrote: > I too anxiously await the widespread availability of FreeBSD on the Pi3.= =20 > If you're like me and just can't wait the image below does boot but does= =20 > not have network support: >=20 > https://people.freebsd.org/~andrew/arm64/rpi3-20160306.img.xz >=20 > On 03/30/2016 04:11 PM, Gala IT wrote: > > Nice to know, thanks a lot :) > > > >> El 30 mar?? 2016, a les 1:38, Adrian Chadd va= escriure: > >> > >> Hi, > >> > >> It's under active development right now. Stay tuned. > >> > >> > >> -a > >> > >> > >> On 29 March 2016 at 13:58, Gala IT wrote: > >>> Hi, > >>> > >>> Being that it???s a 64-bit system and RPI2 images don???t work, is th= ere any procedure already established to build an image to boot on a Raspbe= rry Pi 3? > >>> > >>> Should Crochet work? How? > >>> > >>> Thanks, > >>> David. > >>> _______________________________________________ > >>> freebsd-current@freebsd.org mailing list > >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current > >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd= =2Eorg" > > _______________________________________________ > > 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 > _______________________________________________ > 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" --=20 Shawn Webb HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --H+4ONPRPur6+Ovig Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXB68TAAoJEGqEZY9SRW7uv7sP/jFBSdrPFN/PAmwMj6lSS83y 6LaSFLnrDCtNSM5HIh57CARiUdOnJXtV9Bib9LIFhS0DI9XcbR6Zezbze/j0ms/q a8MsJgW6q/I31xtlzN8WZVqA26TfyMTS4n+0gJOYwH/cZAX2xjVZtkz/ZPx/bDGl 09gWQeu1sWAIM/maTWEsVnvf5oMeYPVhsWz/ihXUG/amKF0UnaldUpLl8oBQ/Zuo zfvg6uYM/YqM4EuTsKTeySfoYVY1Vz2FIWFeaG7AHJJUGPq6qenYrrTCicf0n9UC t7D3zzoPgNLwg+U6w7A8b1Y1SMB/cj2hmwqhCyEazo5fUun4E6SvwwZZXEgzLQIW 72a8syZdwqiv1Rr1rqPtc3ts3Dloa7BfYhSdOh6fVT3uXzL2bS6jliU0vd0bSDVU apH2M85De0Q9mmaqqdCUMd4sg3QcuKov5yArisY+GdnUKMjb03noT0YYJiM43tSf bDVa6sBzVcrf0kMT6sfI0CMEtyrPFu1Cg/k2CRxf4QF5EHAdgIXgGSmpYYg708Fj cg4J7WX+/YPnrgZLDVqCH39OfdLeRuJYGq4QdVyy8UcuRmcx30TBvyM/NyV0LJ+V gABL/D9j9annDkno8TfqUNW9dxz9S32uMJK1f3sry+0To+Vosm1EhdOWZH2FSLpP C3VjX59GnkuF2vvZuMVU =XjG7 -----END PGP SIGNATURE----- --H+4ONPRPur6+Ovig-- From owner-freebsd-current@freebsd.org Fri Apr 8 13:36: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 09551B081A4 for ; Fri, 8 Apr 2016 13:36:12 +0000 (UTC) (envelope-from decui@microsoft.com) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0113.outbound.protection.outlook.com [65.55.169.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8DC2A1BF1; Fri, 8 Apr 2016 13:36:11 +0000 (UTC) (envelope-from decui@microsoft.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FtyesewNlzrRNCPNxkwk7oynjqGbnK7aJ9QBbyMYUX8=; b=ZFxb7fdaHORXOsVm2OZwHJNWjWCxmAV03b4PCAaZMmElVn5yTAgG2RDIe2r1VIu+Ac610Buysx/7FwgrD/kgRTCnt6TgTUn2FXNaUHTMT4hN2JZbo/Cf1xL6LESPfIWEEtOMXJvie96U8XcQwvN74C/AQ29RkhajTWndo4ktOXA= Received: from BLUPR03MB1410.namprd03.prod.outlook.com (10.163.81.144) by BLUPR03MB1410.namprd03.prod.outlook.com (10.163.81.144) with Microsoft SMTP Server (TLS) id 15.1.447.15; Fri, 8 Apr 2016 11:03:46 +0000 Received: from BLUPR03MB1410.namprd03.prod.outlook.com ([10.163.81.144]) by BLUPR03MB1410.namprd03.prod.outlook.com ([10.163.81.144]) with mapi id 15.01.0447.029; Fri, 8 Apr 2016 11:03:46 +0000 From: Dexuan Cui To: Sepherosa Ziehau , "smokehydration@tutanota.com" CC: "freebsd-current@freebsd.org" Subject: RE: Revision 297176 - hyperv/evttimer: Use an independent message slot so that it can work Thread-Topic: Revision 297176 - hyperv/evttimer: Use an independent message slot so that it can work Thread-Index: AQHRkXkiMx921mGqikmAHSfbkel4Ap9/174g Date: Fri, 8 Apr 2016 11:03:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [167.220.255.14] x-ms-office365-filtering-correlation-id: 994c344e-53f3-4d86-2b38-08d35f9d7509 x-microsoft-exchange-diagnostics: 1; BLUPR03MB1410; 5:2AnLa//aQCwMPC0h5PCFSSYgzm5n5G75n7TV/WiJgDB2Ly/hSU1ugXBTGiNPARcBkNFXNYigjVbiptdGQDS725lyRAu+4QoW2poMO+0NP8TRJJWxRw5jSleHks/fsShDAHJra+4ZqsP+oagjPaNXtg==; 24:vzykGmhej7XHENk0MiNNlg6PVkAidR/tvYXFL3esIlZltkNUCEd7qhS/f0gOWzDIkDuyQbr7cypR2HZ+ETa7o06vf/GooijnIaOAzwjaMkA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1410; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BLUPR03MB1410; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1410; x-forefront-prvs: 0906E83A25 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(377454003)(86362001)(5001770100001)(74316001)(2501003)(189998001)(92566002)(5008740100001)(77096005)(33656002)(15650500001)(54356999)(81166005)(15975445007)(5004730100002)(122556002)(11100500001)(164054004)(575784001)(2900100001)(19580405001)(19580395003)(86612001)(2950100001)(87936001)(4326007)(6116002)(10090500001)(5002640100001)(10290500002)(5005710100001)(5003600100002)(10400500002)(3846002)(102836003)(106116001)(99286002)(586003)(50986999)(76176999)(1220700001)(1096002)(76576001)(3660700001)(2906002)(9686002)(8990500004)(3280700002)(66066001)(21314002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1410; H:BLUPR03MB1410.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2016 11:03:46.5536 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1410 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 08 Apr 2016 13:36:12 -0000 Hi smokehydration, I guess your VM config file has something like "viridian =3D 1" or "viridian_enlightenment=3Dxxx". With this, Xen tries to pretend to be Hyper-V, but obviously Xen can't be 1= 00% Hyper-V. BTW, I know at least KVM can have the same behavior. We have to find a reliable way to distinguish Hyper-V from other hypervisor= s that try to pretend to be Hyper-V... Thanks, -- Dexuan > -----Original Message----- > From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- > current@freebsd.org] On Behalf Of Sepherosa Ziehau > Sent: Friday, April 8, 2016 17:29 > To: smokehydration@tutanota.com > Cc: freebsd-current@freebsd.org > Subject: Re: Revision 297176 - hyperv/evttimer: Use an independent messag= e > slot so that it can work >=20 > I have reverted this change. It will be brought back, after some code > refactoring. >=20 > On Fri, Apr 8, 2016 at 4:22 PM, wrote: > > > > Hello > > > > I recently update one of my many vms from an older CURRENT revision > r297196 > > to r297659 and on reboot it just panics with the following: > > > > FreeBSD clang version 3.8.0 (tags/RELEHSE_380/final 262564) (based on L= LVM > > 3.8.0 > > ) > > VT(vga): text 80x25 > > Timecounter "Hyper-V" frequency 10000000 Hz quality 10000000 > > Kernel trap 9 with interrupts disabled > > > > > > Fatal trap 9: general protection fault while in kernel mode > > cpuid =3D 0: apic id =3D 00 > > instruction pointer =3D 0x20:0xffffffff8100d6?9 > > stack pointer =3D 0x28:oxffffffff820d5c30 > > frame pointer =3D 0x28:oxffffffff820d5c40 > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags =3D IOPL =3D 0 > > current process =3D 0 () > > [ thread pid 0 tid 0 ] > > stopped at hv_get_timecount+0x9: rdmsr > > db) wh > > Tracing pid 0 tid 0 td 0xffffffff81d0eff0 > > hv_get_timecount() at hv_get_timecount+0x9/frame 0xffffffff820d5c40 > > tc_init() at tc_init+0x251/frame 0xffffffff820d5c90 > > mi_startup() at mi_startup+0x118/frame 0xffffffff820d5cb0 > > btext() at btext+ox2c =3D > > db> > > > > I changed hv_hv.c back to the previous revision (297176) and no panics = under > > Xen VM. > > > > Thanks! > > > > p.s. not sure why Xen gets detected as HyperV > > >=20 >=20 >=20 > -- > Tomorrow Will Never Die > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2flists.= freebs > d.org%2fmailman%2flistinfo%2ffreebsd- > current&data=3D01%7c01%7cdecui%40microsoft.com%7c3a2924929b7b4158aa4f > 08d35f9043e2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DomVqiBrK > 9sWAd10koNsZkG72nSoXnjFdXKUsXhGFK6k%3d > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-current@freebsd.org Fri Apr 8 14:00: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 60D59B0894A for ; Fri, 8 Apr 2016 14:00:46 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 542581779; Fri, 8 Apr 2016 14:00:46 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id B6D9689A; Fri, 8 Apr 2016 14:00:45 +0000 (UTC) Date: Fri, 8 Apr 2016 14:00:45 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <1773135525.1.1460124045183.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <2087459086.0.1460111210809.JavaMail.jenkins@jenkins-9.freebsd.org> References: <2087459086.0.1460111210809.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_HEAD #169 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 08 Apr 2016 14:00:46 -0000 See From owner-freebsd-current@freebsd.org Fri Apr 8 14:02: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 ADD4EB08AB0 for ; Fri, 8 Apr 2016 14:02:18 +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 2D3681AF4; Fri, 8 Apr 2016 14:02:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u38E29iN036109 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 8 Apr 2016 17:02:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u38E29iN036109 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u38E29Hr036108; Fri, 8 Apr 2016 17:02:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 8 Apr 2016 17:02:09 +0300 From: Konstantin Belousov To: Dexuan Cui Cc: Sepherosa Ziehau , "smokehydration@tutanota.com" , "freebsd-current@freebsd.org" Subject: Re: Revision 297176 - hyperv/evttimer: Use an independent message slot so that it can work Message-ID: <20160408140208.GN1741@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.5.24 (2015-08-30) 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.21 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, 08 Apr 2016 14:02:18 -0000 On Fri, Apr 08, 2016 at 11:03:46AM +0000, Dexuan Cui wrote: > Hi smokehydration, > I guess your VM config file has something like "viridian = 1" or > "viridian_enlightenment=xxx". > > With this, Xen tries to pretend to be Hyper-V, but obviously Xen can't be 100% Hyper-V. > BTW, I know at least KVM can have the same behavior. > > We have to find a reliable way to distinguish Hyper-V from other hypervisors that > try to pretend to be Hyper-V... At the time when the probe is done, the IDT entries for exceptions are already set. You can use rdmsr_safe() instead of rdmsr() to read Hyper-V timecounter register. Then, a fault definitely indicates that the kernel is not executing on the compatible Hyper-V emulator. Hopefully, a non-fault read is not impossible for undesired cases. From owner-freebsd-current@freebsd.org Fri Apr 8 14:47:32 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 B8345B07729 for ; Fri, 8 Apr 2016 14:47:32 +0000 (UTC) (envelope-from decui@microsoft.com) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0132.outbound.protection.outlook.com [207.46.100.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49EFC1BCC; Fri, 8 Apr 2016 14:47:31 +0000 (UTC) (envelope-from decui@microsoft.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uqxOXx/crA0akWaI59e0huIgGSoEiUiiW+TYoFXwutY=; b=fAXqlttqeP3yBPPIRSjP3LZxs2hN8DimjpKsA991nfQZAwho8EteWnVb1mzWd+l4KOZ/iDTGm5LMRY91po/dQuJran1phhYWWXza6DOsYDwnUPucymzrnO5oTrchHFzfTXcWwg48oCjYUFyZinAMQLrEAXYoBx1D6yRJv+ugYes= Received: from BLUPR03MB1410.namprd03.prod.outlook.com (10.163.81.144) by BLUPR03MB1409.namprd03.prod.outlook.com (10.163.81.143) with Microsoft SMTP Server (TLS) id 15.1.447.15; Fri, 8 Apr 2016 14:15:05 +0000 Received: from BLUPR03MB1410.namprd03.prod.outlook.com ([10.163.81.144]) by BLUPR03MB1410.namprd03.prod.outlook.com ([10.163.81.144]) with mapi id 15.01.0447.029; Fri, 8 Apr 2016 14:15:05 +0000 From: Dexuan Cui To: Konstantin Belousov CC: Sepherosa Ziehau , "smokehydration@tutanota.com" , "freebsd-current@freebsd.org" Subject: RE: Revision 297176 - hyperv/evttimer: Use an independent message slot so that it can work Thread-Topic: Revision 297176 - hyperv/evttimer: Use an independent message slot so that it can work Thread-Index: AQHRkXkiMx921mGqikmAHSfbkel4Ap9/174ggABDyoCAAAFIAA== Date: Fri, 8 Apr 2016 14:15:05 +0000 Message-ID: References: <20160408140208.GN1741@kib.kiev.ua> In-Reply-To: <20160408140208.GN1741@kib.kiev.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [167.220.255.14] x-ms-office365-filtering-correlation-id: 93c1434e-01bc-42c6-c3fc-08d35fb82ec4 x-microsoft-exchange-diagnostics: 1; BLUPR03MB1409; 5:72TG1WxREEFg7/NR4tBszmPvRuorDVecM89O8k2wWKrcH/PkFOR+6TFzkO1zXXkdYDZ+QJkg76sQBsaL3+bEiz7lpLJfvkOqXzevbyQ7TjYoZN26aU+sq6CnwCfb0q7OISH62IfDVDbauD5JCEHLqg==; 24:18oWSizWuCNlmz2h7zBQFLmsv3QPDHBRwYsemgn5KNCf7rwo1AfJfbmmMxQAoBoPw8fRhwDeuUhX+CTgGS8x4gy+U6P5fxA3U7RI/+UnpsE= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1409; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BLUPR03MB1409; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1409; x-forefront-prvs: 0906E83A25 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(10400500002)(8990500004)(5005710100001)(10290500002)(10090500001)(15650500001)(3660700001)(74316001)(3280700002)(110136002)(189998001)(2906002)(4326007)(76576001)(50986999)(76176999)(54356999)(5004730100002)(106116001)(575784001)(77096005)(15975445007)(86612001)(122556002)(2950100001)(81166005)(2900100001)(33656002)(87936001)(5002640100001)(86362001)(99286002)(5003600100002)(92566002)(93886004)(5008740100001)(1411001)(9686002)(6116002)(102836003)(3846002)(66066001)(19580405001)(1096002)(19580395003)(11100500001)(586003)(1220700001)(21314002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1409; H:BLUPR03MB1410.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2016 14:15:05.1077 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1409 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 08 Apr 2016 14:47:32 -0000 > From: Konstantin Belousov [mailto:kostikbel@gmail.com] > Sent: Friday, April 8, 2016 22:02 > To: Dexuan Cui > Cc: Sepherosa Ziehau ; smokehydration@tutanota.com; > freebsd-current@freebsd.org > Subject: Re: Revision 297176 - hyperv/evttimer: Use an independent messag= e > slot so that it can work >=20 > On Fri, Apr 08, 2016 at 11:03:46AM +0000, Dexuan Cui wrote: > > Hi smokehydration, > > I guess your VM config file has something like "viridian =3D 1" or > > "viridian_enlightenment=3Dxxx". > > > > With this, Xen tries to pretend to be Hyper-V, but obviously Xen can't = be 100% > Hyper-V. > > BTW, I know at least KVM can have the same behavior. > > > > We have to find a reliable way to distinguish Hyper-V from other hyperv= isors > that > > try to pretend to be Hyper-V... >=20 > At the time when the probe is done, the IDT entries for exceptions are > already set. You can use rdmsr_safe() instead of rdmsr() to read Hyper-V > timecounter register. Then, a fault definitely indicates that the kernel > is not executing on the compatible Hyper-V emulator. Hopefully, a > non-fault read is not impossible for undesired cases. Hi Konstantin, Thanks for the suggestion! We're trying to solve the issue with "hv_features/hv_recommendations" of some Hyper-V specific CPUIDs -- the other hypervisors are unlikely to touch these CPUIDs; even if they do touch the CPUIDs, I think they should respect the meanings of the CPUIDs and shouldn't incorrectly report capabilities they doesn't really have. A drafted patch is here: https://github.com/howard0su/freebsd/commit/d1d031e0d8991ab1f94de00325705d2= 66829c647 We'll clean up & post it -- Dexuan From owner-freebsd-current@freebsd.org Fri Apr 8 16:19: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 EAF18B08B09 for ; Fri, 8 Apr 2016 16:19:28 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id BB0FC18E1 for ; Fri, 8 Apr 2016 16:19:28 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 055097300A; Fri, 8 Apr 2016 18:24:17 +0200 (CEST) Date: Fri, 8 Apr 2016 18:24:16 +0200 From: Luigi Rizzo To: freebsd-current@freebsd.org Subject: stall-free memory reads ? (possibly stale) ? Message-ID: <20160408162416.GA94343@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 08 Apr 2016 16:19:29 -0000 Hi, I have an application with two threads sharing a memory variable, one continuously writing, one continuously reading. Because of the way my system works, the reader can tolerate reading stale data, but it should not stall on memory reads (the line is on the local cache for the reader, just might be invalidated). I was wondering if there is some way (either generic or x86-specific, either simple or convoluted, possibly using multiple versions of the shared variable in different cache lines) to make sure that reads never stalls (or, equivalently, let me read stale values from the cache) ? I have done some experiments and on a single-socket machines the stallled reads take some 50ns; on a dual socket machine the stall penalty grows to about 200ns. cheers luigi From owner-freebsd-current@freebsd.org Fri Apr 8 17:45: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 5E19FB0751C for ; Fri, 8 Apr 2016 17:45: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 D43E315BB for ; Fri, 8 Apr 2016 17:45:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u38HjhcT095386 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 8 Apr 2016 20:45:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u38HjhcT095386 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u38HjgpN095374; Fri, 8 Apr 2016 20:45:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 8 Apr 2016 20:45:42 +0300 From: Konstantin Belousov To: Luigi Rizzo Cc: freebsd-current@freebsd.org Subject: Re: stall-free memory reads ? (possibly stale) ? Message-ID: <20160408174542.GO1741@kib.kiev.ua> References: <20160408162416.GA94343@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160408162416.GA94343@onelab2.iet.unipi.it> User-Agent: Mutt/1.5.24 (2015-08-30) 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.21 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, 08 Apr 2016 17:45:50 -0000 On Fri, Apr 08, 2016 at 06:24:16PM +0200, Luigi Rizzo wrote: > Hi, > I have an application with two threads sharing a memory variable, > one continuously writing, one continuously reading. > > Because of the way my system works, the reader can tolerate reading > stale data, but it should not stall on memory reads (the line > is on the local cache for the reader, just might be invalidated). > > I was wondering if there is some way (either generic or > x86-specific, either simple or convoluted, possibly using > multiple versions of the shared variable in different cache > lines) to make sure that reads never stalls (or, equivalently, > let me read stale values from the cache) ? > > I have done some experiments and on a single-socket machines > the stallled reads take some 50ns; on a dual socket machine > the stall penalty grows to about 200ns. You cannot turn off cache-coherence logic. Of course, you could avoid cache at all, by using non-temporal stores or setting memory to write-combining or non-cacheable. But the result from the non-temporal writes/cached reads is undefined and probably never working, while for WC memory you get hit from full memory latency on read. If you are fine reading stale value, then you could update two instances of the variable, one with the full rate, and another instance, located in different cache line, with the reduced rate. Readers would access only the reduced rate instance. To get the eventual consistency, a timer would be needed which updates the slow variable by the fast value. From owner-freebsd-current@freebsd.org Fri Apr 8 18:17: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 8C41BB081AA for ; Fri, 8 Apr 2016 18:17:30 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 7F63F1847; Fri, 8 Apr 2016 18:17:30 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 5D3C8954; Fri, 8 Apr 2016 18:17:30 +0000 (UTC) Date: Fri, 8 Apr 2016 18:17:29 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <397233237.3.1460139449217.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1773135525.1.1460124045183.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1773135525.1.1460124045183.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_HEAD #170 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 08 Apr 2016 18:17:30 -0000 See From owner-freebsd-current@freebsd.org Fri Apr 8 19:36:03 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 ED479B088F6 for ; Fri, 8 Apr 2016 19:36:03 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qg0-x243.google.com (mail-qg0-x243.google.com [IPv6:2607:f8b0:400d:c04::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 B4C721D07 for ; Fri, 8 Apr 2016 19:36:03 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qg0-x243.google.com with SMTP id b32so10905145qgf.2 for ; Fri, 08 Apr 2016 12:36:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=abeoouwHokcWVe9d5HarYvieRQCk7T0WftvWaJ+uyYA=; b=amW2p4WnwEdgVI3wkwHBNmiRN43AdkJjHhjKUr4kTO1uhyKcvTxRxSttG6Ch1hjYaK CJtcLKFebBWCR3XRFntUg4vJF8AmGtRVymLBWTW+VtlI6Yk8+YWBE6XKwwXtvHbxfsJL MwzVIn+HGG8Ttrk8urLQHYfIAaJpQZrZaW0wA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=abeoouwHokcWVe9d5HarYvieRQCk7T0WftvWaJ+uyYA=; b=FWTDSomq4pABcpZzYxhqnO5jgoNveWXMcIBA3k1J/UCItKZtCmZOV3JW+WpboDkWlU Smzuod3sh/0KzwY6iTdF7mR7Tl0tEvSpXgudpztNWGTPozSkF21L4dTvaYYQY3pPQsZY c32GBOZIp4znsesL/XT9O6b9As3/EdNLuDAyeQSKbdri1ooP1qUnygsyfqmmeFD/Yryy zlCRTG2y/ZO2KxjYtUOxYT4CHL4CwLxek2xrjg27uYtEO0+7M/G4IKnMOArq/dcPRWYN CCnISevNbGW2ywLh9n9HfhGbBJWEeAUez8PbQ/P31nObVlz/4NGojxSFmgWWLDco/A5y F6YQ== X-Gm-Message-State: AD7BkJKBdy4C8CP7kEEDS4TCX38Yfb2V3GoLHFlJqNMN+xZZCMiRBokWWc60OIOuLVCDUA== X-Received: by 10.140.201.130 with SMTP id w124mr14371111qha.57.1460144162150; Fri, 08 Apr 2016 12:36:02 -0700 (PDT) Received: from [192.168.0.18] ([187.60.94.34]) by smtp.googlemail.com with ESMTPSA id w188sm6079283qhb.37.2016.04.08.12.36.00 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Apr 2016 12:36:01 -0700 (PDT) To: freebsd-current@freebsd.org, freebsd-arm@freebsd.org From: =?UTF-8?B?T3RhY8OtbGlv?= Subject: WIFI urtwn possibly broken on 297561 Message-ID: <57080811.5030405@bsd.com.br> Date: Fri, 8 Apr 2016 16:35:45 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 08 Apr 2016 19:36:04 -0000 Dears I'm testing the CURRENT version on a beaglebone black and have noted the follow behavior. On revision 297561 the wifi adapter stops works after a pkg update. I did the follow tests. Using the version 296898 (OK behavior) and 297561 (wrong behavior): FreeBSD beaglebone 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r296898M: Wed Mar 16 23:52:02 BRT 2016 ota@nostromo:/root/crochet/work/obj/arm.armv6/usr/src/sys/BEAGLEBONE-DEBUG arm ping nostromo ==> OK pkg update ==> OK ping nostromo==> OK network is OK I have tested using this follows adapters and on both the behavior is the same and OK on 296898 : urtwn0: on usbus1 urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R urtwn0: on usbus1 urtwn0: MAC/BB RTL8192CU, RF 6052 2T2R After update to this version FreeBSD beaglebone 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r297561: Fri Apr 8 00:53:13 BRT 2016 ota@nostromo:/root/crochet/work/obj/arm.armv6/usr/src/sys/BEAGLEBONE-DEBUG arm And I did the same tests using the same adapters and the wifi stops work after pkg update. And a complete log of the test: Edit /etc/motd to change this login announcement. % ping nostromo PING nostromo (192.168.0.26): 56 data bytes 64 bytes from 192.168.0.26: icmp_seq=0 ttl=64 time=98.318 ms 64 bytes from 192.168.0.26: icmp_seq=1 ttl=64 time=3.679 ms 64 bytes from 192.168.0.26: icmp_seq=2 ttl=64 time=58.809 ms 64 bytes from 192.168.0.26: icmp_seq=3 ttl=64 time=5.464 ms 64 bytes from 192.168.0.26: icmp_seq=4 ttl=64 time=10.979 ms ^C --- nostromo ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 3.679/35.450/98.318/37.431 ms % su pkg upApr 8 04:18:24 beaglebone su: ota to root on /dev/ttyu0 daroot@beaglebone:/usr/home/ota # pkg update The package management tool is not yet installed on your system. Do you want to fetch and install it now? [y/N]: y Bootstrapping pkg from pkg+http://nostromo:8080/repo/101armv6-default/.latest, please wait... ^C root@beaglebone:/usr/home/ota # ping nostromo PING nostromo (192.168.0.26): 56 data bytes ^C --- nostromo ping statistics --- 7 packets transmitted, 0 packets received, 100.0% packet loss root@beaglebone:/usr/home/ota # uname -a FreeBSD beaglebone 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r297561: Fri Apr 8 00:53:13 BRT 2016 ota@nostromo:/root/crochet/work/obj/arm.armv6/usr/src/sys/BEAGLEBONE-DEBUG arm this log is for the follow adapter but for the next one the behavior is the same urtwn0: on usbus1 urtwn0: MAC/BB RTL8192CU, RF 6052 2T2R urtwn0: on usbus1 urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R Someone knows whats going on? Thanks a lot -Otacílio From owner-freebsd-current@freebsd.org Fri Apr 8 19:55:59 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 16F08B090F2; Fri, 8 Apr 2016 19:55:59 +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 D762A1858; Fri, 8 Apr 2016 19:55:58 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x22b.google.com with SMTP id g185so144343679ioa.2; Fri, 08 Apr 2016 12:55:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=NWBET6DRRVfkXNfN7ZlmfXz2uRDq8x6DAVUJ7LrQD/Q=; b=QUHxDLZtqOxgCBbj2Cu26A/aixtkSMiV7PP48jOW8Ij92yaDfGjC/FfMYNKdb1SR7l 2YkJ7vbp5dlbrFb6VrgkHb8hf3hEayVHuKcEpntPiiqga8gxtUWyc/kWLAQwc7RJQbYl nmaHnig6e9NY0G1kozs7BCVlGAFj9rJLehRlQiujZZfAOSoJzm+13uakvGod6An+H/B8 IoYLqByjPWh12Zd9DyW0S8UF+qbQCU+C0TTvF41blLd7/XNjbYVQI8qgwxnhWJXTHhCa ZD3K9+XkxjZ0NQj5bxbjPmHxgGS7U3xNe+eklMFYnkwS8N8CMHyK34cJaKqQB47EyiMT UyzA== 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:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=NWBET6DRRVfkXNfN7ZlmfXz2uRDq8x6DAVUJ7LrQD/Q=; b=eTPt46oAxfJd513EASjkBFjOab7uPOn1pvgTwwm79rqrU4teX3W4Ky5MxKihXC6aIj xfowmRAKOW20YsQMkiA2Xk7Od5dGvf+drSfDD7tD+sbYdrSukZ6ylTKV6Xlgd5YdFWcE 4uVL+2NiaWvTzhFvIK43FaonmYZkIXzuzQ/PuGCks5DupFkr3QMjbtjsQCnfbVnegWMB X4z14scyVNft1e+oj8EaAmieDVUogUyAyYWP0TTR3dW4kDw6cO1SAie1PXguDjAbPY0W a9/8a2R2M8F9ZGRyvh57zxbQ1sZK1pFQDcdc/KgRqBsDcx9cQMeTckKOowjzFEpfGjdH c+fQ== X-Gm-Message-State: AD7BkJKwN/bzEw4Ubo5rkkM6derqt+PzNMFRcx+LGJ9F4Ck5T03HY/DjiQCRPq5WGdEtxUbsiD6QymU+NRPQPQ== MIME-Version: 1.0 X-Received: by 10.107.19.42 with SMTP id b42mr11070246ioj.75.1460145358099; Fri, 08 Apr 2016 12:55:58 -0700 (PDT) Received: by 10.36.14.19 with HTTP; Fri, 8 Apr 2016 12:55:57 -0700 (PDT) In-Reply-To: <57080811.5030405@bsd.com.br> References: <57080811.5030405@bsd.com.br> Date: Fri, 8 Apr 2016 12:55:57 -0700 Message-ID: Subject: Re: WIFI urtwn possibly broken on 297561 From: Adrian Chadd To: =?UTF-8?B?T3RhY8OtbGlv?= Cc: freebsd-current , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 08 Apr 2016 19:55:59 -0000 hi, try 'ifconfig wlan0 -ff -amsdu' and try again -a On 8 April 2016 at 12:35, Otac=C3=ADlio wrote: > Dears > > I'm testing the CURRENT version on a beaglebone black and have noted the > follow behavior. On revision 297561 the wifi adapter stops works after a = pkg > update. I did the follow tests. > Using the version 296898 (OK behavior) and 297561 (wrong behavior): > > FreeBSD beaglebone 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r296898M: Wed Mar= 16 > 23:52:02 BRT 2016 > ota@nostromo:/root/crochet/work/obj/arm.armv6/usr/src/sys/BEAGLEBONE-DEBU= G > arm > > ping nostromo =3D=3D> OK > pkg update =3D=3D> OK > ping nostromo=3D=3D> OK > network is OK > > I have tested using this follows adapters and on both the behavior is the > same and OK on 296898 : > urtwn0: = on > usbus1 > urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R > > urtwn0: = on > usbus1 > urtwn0: MAC/BB RTL8192CU, RF 6052 2T2R > > > After update to this version > FreeBSD beaglebone 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r297561: Fri Apr = 8 > 00:53:13 BRT 2016 > ota@nostromo:/root/crochet/work/obj/arm.armv6/usr/src/sys/BEAGLEBONE-DEBU= G > arm > > And I did the same tests using the same adapters and the wifi stops work > after pkg update. > > > And a complete log of the test: > > Edit /etc/motd to change this login announcement. > % ping nostromo > PING nostromo (192.168.0.26): 56 data bytes > 64 bytes from 192.168.0.26: icmp_seq=3D0 ttl=3D64 time=3D98.318 ms > 64 bytes from 192.168.0.26: icmp_seq=3D1 ttl=3D64 time=3D3.679 ms > 64 bytes from 192.168.0.26: icmp_seq=3D2 ttl=3D64 time=3D58.809 ms > 64 bytes from 192.168.0.26: icmp_seq=3D3 ttl=3D64 time=3D5.464 ms > 64 bytes from 192.168.0.26: icmp_seq=3D4 ttl=3D64 time=3D10.979 ms > ^C > --- nostromo ping statistics --- > 5 packets transmitted, 5 packets received, 0.0% packet loss > round-trip min/avg/max/stddev =3D 3.679/35.450/98.318/37.431 ms > % su > pkg upApr 8 04:18:24 beaglebone su: ota to root on /dev/ttyu0 > daroot@beaglebone:/usr/home/ota # pkg update > The package management tool is not yet installed on your system. > Do you want to fetch and install it now? [y/N]: y > Bootstrapping pkg from > pkg+http://nostromo:8080/repo/101armv6-default/.latest, please wait... > ^C > root@beaglebone:/usr/home/ota # ping nostromo > PING nostromo (192.168.0.26): 56 data bytes > ^C > --- nostromo ping statistics --- > 7 packets transmitted, 0 packets received, 100.0% packet loss > root@beaglebone:/usr/home/ota # uname -a > FreeBSD beaglebone 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r297561: Fri Apr = 8 > 00:53:13 BRT 2016 > ota@nostromo:/root/crochet/work/obj/arm.armv6/usr/src/sys/BEAGLEBONE-DEBU= G > arm > > this log is for the follow adapter but for the next one the behavior is t= he > same > > urtwn0: = on > usbus1 > urtwn0: MAC/BB RTL8192CU, RF 6052 2T2R > > urtwn0: = on > usbus1 > urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R > > > Someone knows whats going on? > > > Thanks a lot > -Otac=C3=ADlio > > > > _______________________________________________ > 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 Fri Apr 8 20:21: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 8B933B097B9 for ; Fri, 8 Apr 2016 20:21:13 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qg0-x242.google.com (mail-qg0-x242.google.com [IPv6:2607:f8b0:400d:c04::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 4AF9312FA for ; Fri, 8 Apr 2016 20:21:13 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qg0-x242.google.com with SMTP id j35so10974050qge.1 for ; Fri, 08 Apr 2016 13:21:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=2CYdx+dMvsjWWG3GEZMlgf+ZKSJc3uGE/R0NLFzXYoM=; b=MlGKVW//1JFqJP2P6AWUvKwcdlO27qHz951tVb67qTWfB7cTpTdX+GSTJW6do1jC1I GZQ7nCu/WnLACWCxgZ2j1QjNOec0AJGIYOPf+Ed7aIaU+Lby8uioi+8QbTmdiM7pNX2G /Fg5Kuz+w7IDSjgqNU8Iwz4IcGVWA7hGamsOE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=2CYdx+dMvsjWWG3GEZMlgf+ZKSJc3uGE/R0NLFzXYoM=; b=Wx3kPUnHOMj22Lobyhvzgk2k0u/LUujq9t9LDP8YfpmkcVfnMFwwD3P209aSX/PAtM 9MOiEAYG3tknnAHtdYmHvztwoKGtX56In60npodcU5I3DpslFkSyPZUslAHby0eaA7MI yk7Zs/t2/XQqKxHEoggNjPwEuDlVVulguO0/6GVd3TTxXHYa7K3A5g2DJZDcaOGWJ0QY qWWDbUyNeGxAlCVPxCdlVek6TKzVHASM6i4DI39pR36O6PzPGzOA1yPigIfao/abqq40 fVZIdgOJLK3iu0zdV09ShP8OYUgQ9pi47VgUl6fZVLgI1W/AhyTRFHBAFOfw3oGEgCaX OGow== X-Gm-Message-State: AD7BkJIVi8itllKPt7CE8LDMMLL1nb4uMrPC1GBNtXJ/PBPonZ1lnr6HzHch0jJtn7M15A== X-Received: by 10.140.221.9 with SMTP id r9mr14568856qhb.77.1460146872312; Fri, 08 Apr 2016 13:21:12 -0700 (PDT) Received: from [192.168.0.18] ([187.60.94.34]) by smtp.googlemail.com with ESMTPSA id j67sm6167608qgj.35.2016.04.08.13.21.10 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Apr 2016 13:21:11 -0700 (PDT) Subject: Re: WIFI urtwn possibly broken on 297561 To: Adrian Chadd References: <57080811.5030405@bsd.com.br> Cc: freebsd-current , "freebsd-arm@freebsd.org" From: =?UTF-8?B?T3RhY8OtbGlv?= Message-ID: <570812A5.1050600@bsd.com.br> Date: Fri, 8 Apr 2016 17:20:53 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 08 Apr 2016 20:21:13 -0000 The parameter --ff looks like is not valid for my adapter. First I try using prompt: ===================================================================================================== Edit /etc/motd to change this login announcement. % su Apr 8 05:04:12 beaglebone su: ota to root on /dev/ttyu0 root@beaglebone:/usr/home/ota # ifconfig wlan0 -ff -amsdu ifconfig: SIOCS80211: Invalid argument root@beaglebone:/usr/home/ota # ifconfig wlan0 -ff ifconfig: SIOCS80211: Invalid argument root@beaglebone:/usr/home/ota # ifconfig wlan0 -amsdu root@beaglebone:/usr/home/ota # pkg update The package management tool is not yet installed on your system. Do you want to fetch and install it now? [y/N]: y Bootstrapping pkg from pkg+http://nostromo:8080/repo/101armv6-default/.latest, please wait... ^C root@beaglebone:/usr/home/ota # ping nostromo PING nostromo (192.168.0.26): 56 data bytes ^C --- nostromo ping statistics --- 13 packets transmitted, 0 packets received, 100.0% packet loss root@beaglebone:/usr/home/ota # ===================================================================================================== And in rc.conf ===================================================================================================== Feeding entropy:. ifconfig: SIOCIFCREATE2: Invalid argument cpsw0: link state changed to DOWN Starting Network: lo0 cpsw0. lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 0xff000000 groups: lo nd6 options=21 cpsw0: flags=8843 metric 0 mtu 1500 options=8000b ether 90:59:af:4c:20:9a media: Ethernet autoselect (none) status: no carrier nd6 options=29 ELF ldconfig path: /lib /usr/lib /usr/lib/compat Soft Float compatibility ldconfig path: Starting devd. urtwn0: on usbu s1 urtwn0: MAC/BB RTL8192CU, RF 6052 2T2R urtwn0: enabling 11n wlan0: Ethernet address: 14:cc:20:12:ee:55 Created wlan(4) interfaces: wlan0. Starting wpa_supplicant. Starting dhclient. wlan0: no link .............. giving up /etc/rc.d/dhclient: WARNING: failed to start dhclient Starting Network: wlan0. wlan0: flags=8843 metric 0 mtu 1500 ether 14:cc:20:12:ee:55 groups: wlan ssid "" channel 10 (2457 MHz 11g) country US authmode WPA1+WPA2/802.11i privacy MIXED deftxkey UNDEF txpower 0 bmiss 7 scanvalid 60 protmode CTS wme roaming MANUAL bintval 0 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier nd6 options=29 add net fe80::: gateway ::1 add net ff02::: gateway ::1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 Waiting 30s for the default route interface: wlan0: link state changed to UP ..(wlan0) Creating and/or trimming log files. Starting syslogd. Clearing /tmp (X related). Updating motd:. Mounting late file systems:. Performing sanity check on sshd configuration. Could not load host key: /etc/ssh/ssh_host_dsa_key Starting sshd. Could not load host key: /etc/ssh/ssh_host_dsa_key Starting cron. Starting background file system checks in 60 seconds. Fri Apr 8 05:09:54 UTC 2016 FreeBSD/arm (beaglebone) (ttyu0) login: ota Password: FreeBSD 11.0-CURRENT (BEAGLEBONE-DEBUG) #1 r297561: Fri Apr 8 00:53:13 BRT 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. % su Apr 8 05:10:25 beaglebone su: ota to root on /dev/ttyu0 root@beaglebone:/usr/home/ota # ping nostromo PING nostromo (192.168.0.26): 56 data bytes 64 bytes from 192.168.0.26: icmp_seq=0 ttl=64 time=76.013 ms 64 bytes from 192.168.0.26: icmp_seq=1 ttl=64 time=2.554 ms ^C --- nostromo ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 2.554/39.284/76.013/36.730 ms root@beaglebone:/usr/home/ota # pkg update The package management tool is not yet installed on your system. Do you want to fetch and install it now? [y/N]: y Bootstrapping pkg from pkg+http://nostromo:8080/repo/101armv6-default/.latest, please wait... ^C root@beaglebone:/usr/home/ota # ping nostromo PING nostromo (192.168.0.26): 56 data bytes ^C --- nostromo ping statistics --- 9 packets transmitted, 0 packets received, 100.0% packet loss root@beaglebone:/usr/home/ota # cat /etc/rc.conf hostname="beaglebone" ifconfig_cpsw0="DHCP" sshd_enable="YES" # Nice if you have a network, else annoying. #ntpd_enable="YES" ntpd_sync_on_start="YES" # Uncomment to disable common services (more memory) #cron_enable="NO" #syslogd_enable="NO" sendmail_submit_enable="NO" sendmail_outbound_enable="NO" sendmail_msp_queue_enable="NO" # On first boot, enlarge the root filesystem to fill the SD card growfs_enable="YES" wlans_urtwn0="wlan0" ifconfig_wlan0="WPA SYNCDHCP -amsdu" ===================================================================================================== The behavior is the same. I did a test without the options -ff and -amsdu and get response after a lot of time: ===================================================================================================== ping nostromo PING nostromo (192.168.0.26): 56 data bytes ¦64 bytes from 192.168.0.26: icmp_seq=0 ttl=64 time=29700.789 ms 64 bytes from 192.168.0.26: icmp_seq=1 ttl=64 time=28686.953 ms 64 bytes from 192.168.0.26: icmp_seq=2 ttl=64 time=27662.899 ms 64 bytes from 192.168.0.26: icmp_seq=3 ttl=64 time=26640.436 ms 64 bytes from 192.168.0.26: icmp_seq=4 ttl=64 time=25614.867 ms 64 bytes from 192.168.0.26: icmp_seq=5 ttl=64 time=24590.894 ms 64 bytes from 192.168.0.26: icmp_seq=6 ttl=64 time=23566.904 ms 64 bytes from 192.168.0.26: icmp_seq=7 ttl=64 time=22542.891 ms 64 bytes from 192.168.0.26: icmp_seq=8 ttl=64 time=21518.889 ms 64 bytes from 192.168.0.26: icmp_seq=9 ttl=64 time=20494.831 ms 64 bytes from 192.168.0.26: icmp_seq=10 ttl=64 time=19470.858 ms 64 bytes from 192.168.0.26: icmp_seq=11 ttl=64 time=18446.867 ms 64 bytes from 192.168.0.26: icmp_seq=12 ttl=64 time=17422.918 ms 64 bytes from 192.168.0.26: icmp_seq=13 ttl=64 time=16400.771 ms 64 bytes from 192.168.0.26: icmp_seq=14 ttl=64 time=15374.826 ms 64 bytes from 192.168.0.26: icmp_seq=15 ttl=64 time=14350.861 ms 64 bytes from 192.168.0.26: icmp_seq=16 ttl=64 time=13325.829 ms 64 bytes from 192.168.0.26: icmp_seq=17 ttl=64 time=12303.424 ms 64 bytes from 192.168.0.26: icmp_seq=18 ttl=64 time=11277.698 ms 64 bytes from 192.168.0.26: icmp_seq=19 ttl=64 time=10254.808 ms 64 bytes from 192.168.0.26: icmp_seq=20 ttl=64 time=9231.029 ms 64 bytes from 192.168.0.26: icmp_seq=21 ttl=64 time=8206.789 ms 64 bytes from 192.168.0.26: icmp_seq=22 ttl=64 time=7182.765 ms 64 bytes from 192.168.0.26: icmp_seq=23 ttl=64 time=6158.762 ms 64 bytes from 192.168.0.26: icmp_seq=24 ttl=64 time=5134.735 ms 64 bytes from 192.168.0.26: icmp_seq=25 ttl=64 time=4111.212 ms 64 bytes from 192.168.0.26: icmp_seq=26 ttl=64 time=3086.722 ms 64 bytes from 192.168.0.26: icmp_seq=27 ttl=64 time=2062.736 ms 64 bytes from 192.168.0.26: icmp_seq=28 ttl=64 time=1038.563 ms 64 bytes from 192.168.0.26: icmp_seq=29 ttl=64 time=14.707 ms 64 bytes from 192.168.0.26: icmp_seq=30 ttl=64 time=17.124 ms 64 bytes from 192.168.0.26: icmp_seq=31 ttl=64 time=11.297 ms 64 bytes from 192.168.0.26: icmp_seq=32 ttl=64 time=15.849 ms 64 bytes from 192.168.0.26: icmp_seq=33 ttl=64 time=38.727 ms 64 bytes from 192.168.0.26: icmp_seq=34 ttl=64 time=19.729 ms 64 bytes from 192.168.0.26: icmp_seq=35 ttl=64 time=7.052 ms []'s -Otacilio Em 08/04/2016 16:55, Adrian Chadd escreveu: > hi, > > try 'ifconfig wlan0 -ff -amsdu' and try again > > > -a > > > On 8 April 2016 at 12:35, Otacílio wrote: >> Dears >> >> I'm testing the CURRENT version on a beaglebone black and have noted the >> follow behavior. On revision 297561 the wifi adapter stops works after a pkg >> update. I did the follow tests. >> Using the version 296898 (OK behavior) and 297561 (wrong behavior): >> >> FreeBSD beaglebone 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r296898M: Wed Mar 16 >> 23:52:02 BRT 2016 >> ota@nostromo:/root/crochet/work/obj/arm.armv6/usr/src/sys/BEAGLEBONE-DEBUG >> arm >> >> ping nostromo ==> OK >> pkg update ==> OK >> ping nostromo==> OK >> network is OK >> >> I have tested using this follows adapters and on both the behavior is the >> same and OK on 296898 : >> urtwn0: on >> usbus1 >> urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R >> >> urtwn0: on >> usbus1 >> urtwn0: MAC/BB RTL8192CU, RF 6052 2T2R >> >> >> After update to this version >> FreeBSD beaglebone 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r297561: Fri Apr 8 >> 00:53:13 BRT 2016 >> ota@nostromo:/root/crochet/work/obj/arm.armv6/usr/src/sys/BEAGLEBONE-DEBUG >> arm >> >> And I did the same tests using the same adapters and the wifi stops work >> after pkg update. >> >> >> And a complete log of the test: >> >> Edit /etc/motd to change this login announcement. >> % ping nostromo >> PING nostromo (192.168.0.26): 56 data bytes >> 64 bytes from 192.168.0.26: icmp_seq=0 ttl=64 time=98.318 ms >> 64 bytes from 192.168.0.26: icmp_seq=1 ttl=64 time=3.679 ms >> 64 bytes from 192.168.0.26: icmp_seq=2 ttl=64 time=58.809 ms >> 64 bytes from 192.168.0.26: icmp_seq=3 ttl=64 time=5.464 ms >> 64 bytes from 192.168.0.26: icmp_seq=4 ttl=64 time=10.979 ms >> ^C >> --- nostromo ping statistics --- >> 5 packets transmitted, 5 packets received, 0.0% packet loss >> round-trip min/avg/max/stddev = 3.679/35.450/98.318/37.431 ms >> % su >> pkg upApr 8 04:18:24 beaglebone su: ota to root on /dev/ttyu0 >> daroot@beaglebone:/usr/home/ota # pkg update >> The package management tool is not yet installed on your system. >> Do you want to fetch and install it now? [y/N]: y >> Bootstrapping pkg from >> pkg+http://nostromo:8080/repo/101armv6-default/.latest, please wait... >> ^C >> root@beaglebone:/usr/home/ota # ping nostromo >> PING nostromo (192.168.0.26): 56 data bytes >> ^C >> --- nostromo ping statistics --- >> 7 packets transmitted, 0 packets received, 100.0% packet loss >> root@beaglebone:/usr/home/ota # uname -a >> FreeBSD beaglebone 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r297561: Fri Apr 8 >> 00:53:13 BRT 2016 >> ota@nostromo:/root/crochet/work/obj/arm.armv6/usr/src/sys/BEAGLEBONE-DEBUG >> arm >> >> this log is for the follow adapter but for the next one the behavior is the >> same >> >> urtwn0: on >> usbus1 >> urtwn0: MAC/BB RTL8192CU, RF 6052 2T2R >> >> urtwn0: on >> usbus1 >> urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R >> >> >> Someone knows whats going on? >> >> >> Thanks a lot >> -Otacílio >> >> >> >> _______________________________________________ >> 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 Fri Apr 8 20:34: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 E19CCB09BED; Fri, 8 Apr 2016 20:34:42 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (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 AE3F31BB6; Fri, 8 Apr 2016 20:34:42 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-ig0-x22c.google.com with SMTP id kb1so44185823igb.0; Fri, 08 Apr 2016 13:34:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=zbqrxd+VtH3wMPldrKUVVWnRxUdSzQ/gszq4IQLuY6Y=; b=lTJHnh/q9oJppOqVGt9SDSd7Afk0yiL8CwNtqtsyr0aDSmijeluwd6si9pdNqKaKf9 2HqSJnKN+RAll32W7weGFonPPGeeW0xFrgwE9msBQI1OyrAoy2zD1PwZDfhzL9dhFOB2 7YwLoMB3etSDJs1lnf90QVXkVa4phqhrKZaie/TrxA2IwfvMUt1P7lUyxABhLos9yW0G WiJXpilpPFYoa1PetFBc/zNDjvWGDJOoGTUVQB6gZOyEO07lm4sZ+/CWO3gSb5u6Ku6M aubHIEbI6xMXGT4LDErjrzD3R4g3CRK2f2t8yfjDOMa04BjLJJ0ilwiQfBBDrLigTi1V yx1Q== 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:date :message-id:subject:from:to:cc; bh=zbqrxd+VtH3wMPldrKUVVWnRxUdSzQ/gszq4IQLuY6Y=; b=GArHLifD3Tma01hkUC0RYgOJ/8x40XBImhToYvL+DEy4ypYl77R6LaOWqACbo9icmg VaNgkxPcrgDyYjBSwVnf/b6EdYhD9Yhk/XHo0VZep8tT4gBs2Jc/gZySuLtL/WRMq2RY FNahWuNBGAcVwXrPSptNU4nLpL0s436AblXnhYj6jBQF/0rlLaHF0P2S7NZPgF+vqfv8 MtC+FToD7lSuZN8//JuS//ivVhtm3kleR42ASzUXvYm7IT0V2Wfn3Fg5857K4nSwyq7e vLfEzn6DhBERi3woAr1mExbIDkHccuYO46SHNkH953AeWdWF8oXTl4mxz7zg69npVEKA /rqQ== X-Gm-Message-State: AD7BkJKooYIQmPFTAOVrAp/zaxBgN1ovn7fLKbXjCsDTQUtLxolMzUcLqSH7SJH9RKllgWAfeeOfqooEEzZQuw== MIME-Version: 1.0 X-Received: by 10.50.78.200 with SMTP id d8mr5709762igx.61.1460147682137; Fri, 08 Apr 2016 13:34:42 -0700 (PDT) Received: by 10.36.14.19 with HTTP; Fri, 8 Apr 2016 13:34:42 -0700 (PDT) In-Reply-To: <570812A5.1050600@bsd.com.br> References: <57080811.5030405@bsd.com.br> <570812A5.1050600@bsd.com.br> Date: Fri, 8 Apr 2016 13:34:42 -0700 Message-ID: Subject: Re: WIFI urtwn possibly broken on 297561 From: Adrian Chadd To: =?UTF-8?B?T3RhY8OtbGlv?= Cc: freebsd-current , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 08 Apr 2016 20:34:43 -0000 Hi, Not '--ff', just '-ff' and '-amsdu' It's possible that one or the other of those options are a problem. I added those features recently to urtwn. Can you please do 'ifconfig -v wlan0 list sta' and 'ifconfig -v wlan0' ? Thanks, -adrian From owner-freebsd-current@freebsd.org Fri Apr 8 20:51:54 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 A1BACB0709D for ; Fri, 8 Apr 2016 20:51:54 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qg0-x244.google.com (mail-qg0-x244.google.com [IPv6:2607:f8b0:400d:c04::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 652641639 for ; Fri, 8 Apr 2016 20:51:54 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qg0-x244.google.com with SMTP id 7so8320337qgj.0 for ; Fri, 08 Apr 2016 13:51:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=It7kBud1Du/i8XqsqmI2BO8jLrGSacHs7MIsqJPqBWE=; b=EISoecTwVDa7ldxQBB/abLnFwPPdTS8Y0kp8yaHGi0rTy+pBmNvB6YHQ50G2voEAfo y49NKcdhLelNR7Z0Saeqszy/ztzS9q61Tr6EW8fDqvWkNDpO1ijEiufbMdrjQEKTN8OS h2V+mjUFCWwtSPMx68mJzvSAzRkHlq5ibRUUM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=It7kBud1Du/i8XqsqmI2BO8jLrGSacHs7MIsqJPqBWE=; b=YooZlB9CSzyKoVxcawLnYtAtNGZ/chSrVZC1Ij9BjvKLXgTUVgKCRh+gwIc1zGXzCV Kg602cOq1LiIe1mPXflkyOTRihVRWjwASVXqnqZ5HFWWdE0FzReaIKH3Zd6Zky6xsMh/ zYsrf5o7CgNlekkWpL0YvemT3YL6bJt9C6SIe6MnE+qfIu97Sivyto4uWi6VHO3uw8TW S7V8lR3NlKuebNZa09CW3FmK6uceyb372qUG7fzGMk8PfTxumPNjD2IEgjbRrkw6lO7r kMfVcU3N/H7BOF4KQiywC7sBFEgU8x0/ocVkwT5FpOh0HU4s8VKKKDxaBv+9AeLhI+I+ /VXA== X-Gm-Message-State: AD7BkJIVp3r9HjMY0SrWxOjfm511I6cIANqx/AX9/XHwjcmzOrvH8mI8JO0v2x+Rhnr1ow== X-Received: by 10.140.255.136 with SMTP id a130mr14839154qhd.20.1460148713244; Fri, 08 Apr 2016 13:51:53 -0700 (PDT) Received: from [192.168.0.18] ([187.60.94.34]) by smtp.googlemail.com with ESMTPSA id u16sm6266052qka.22.2016.04.08.13.51.51 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Apr 2016 13:51:52 -0700 (PDT) Subject: Re: WIFI urtwn possibly broken on 297561 To: Adrian Chadd References: <57080811.5030405@bsd.com.br> <570812A5.1050600@bsd.com.br> Cc: freebsd-current , "freebsd-arm@freebsd.org" From: =?UTF-8?B?T3RhY8OtbGlv?= Message-ID: <570819D7.3040206@bsd.com.br> Date: Fri, 8 Apr 2016 17:51:35 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 08 Apr 2016 20:51:54 -0000 Em 08/04/2016 17:34, Adrian Chadd escreveu: > Hi, > > Not '--ff', just '-ff' and '-amsdu' > > It's possible that one or the other of those options are a problem. I > added those features recently to urtwn. > > Can you please do 'ifconfig -v wlan0 list sta' and 'ifconfig -v wlan0' ? > > Thanks, > > > > -adrian Sorry, I type wrong but use the commands correctly :-) Its my rc.conf hostname="beaglebone" ifconfig_cpsw0="DHCP" sshd_enable="YES" # Nice if you have a network, else annoying. #ntpd_enable="YES" ntpd_sync_on_start="YES" # Uncomment to disable common services (more memory) #cron_enable="NO" #syslogd_enable="NO" sendmail_submit_enable="NO" sendmail_outbound_enable="NO" sendmail_msp_queue_enable="NO" # On first boot, enlarge the root filesystem to fill the SD card growfs_enable="YES" wlans_urtwn0="wlan0" ifconfig_wlan0="WPA SYNCDHCP -amsdu" ========================================================= And the commands that you request: ========================================================== root@beaglebone:/usr/home/ota # ifconfig -v wlan0 list sta ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 58:23:8c:c6:e1:aa 5 11 144M 14.5 0 5 19408 EP AQEHTR SSID RATES DSPARMS<11> TIM<050400010000> ERP<0x4> ???<2f0104> RSN XRATES<12,18,24,96> HTCAP HTINFO WPS VEN WPA WME root@beaglebone:/usr/home/ota # ifconfig -v wlan0 wlan0: flags=8843 metric 0 mtu 1500 ether 14:cc:20:12:ee:55 inet 192.168.0.25 netmask 0xffffff00 broadcast 192.168.0.255 groups: wlan ssid Diana channel 11 (2462 MHz 11g ht/20) bssid 58:23:8c:c6:e1:aa regdomain 0 country US anywhere -ecm authmode WPA2/802.11i -wps -tsn privacy ON deftxkey UNDEF TKIP 2:128-bit powersavemode OFF powersavesleep 100 txpower 0 txpowmax 50.0 -dotd rtsthreshold 2346 fragthreshold 2346 bmiss 7 11a ucast NONE mgmt 6 Mb/s mcast 6 Mb/s maxretry 6 11b ucast NONE mgmt 1 Mb/s mcast 1 Mb/s maxretry 6 11g ucast NONE mgmt 1 Mb/s mcast 1 Mb/s maxretry 6 turboA ucast NONE mgmt 6 Mb/s mcast 6 Mb/s maxretry 6 turboG ucast NONE mgmt 1 Mb/s mcast 1 Mb/s maxretry 6 sturbo ucast NONE mgmt 6 Mb/s mcast 6 Mb/s maxretry 6 11na ucast NONE mgmt 12 MCS mcast 12 MCS maxretry 6 11ng ucast NONE mgmt 2 MCS mcast 2 MCS maxretry 6 half ucast NONE mgmt 3 Mb/s mcast 3 Mb/s maxretry 6 quarter ucast NONE mgmt 1 Mb/s mcast 1 Mb/s maxretry 6 scanvalid 60 -bgscan bgscanintvl 300 bgscanidle 250 roam:11a rssi 7dBm rate 12 Mb/s roam:11b rssi 7dBm rate 1 Mb/s roam:11g rssi 7dBm rate 5 Mb/s roam:turboA rssi 7dBm rate 12 Mb/s roam:turboG rssi 7dBm rate 12 Mb/s roam:sturbo rssi 7dBm rate 12 Mb/s roam:11na rssi 7dBm MCS 1 roam:11ng rssi 7dBm MCS 1 roam:half rssi 7dBm rate 6 Mb/s roam:quarter rssi 7dBm rate 3 Mb/s -pureg protmode CTS ht20 htcompat ampdu ampdulimit 64k ampdudensity 8 -amsdu -shortgi htprotmode RTSCTS -puren -smps -rifs wme -burst -dwds roaming MANUAL bintval 100 AC_BE cwmin 4 cwmax 10 aifs 3 txopLimit 0 -acm ack cwmin 4 cwmax 10 aifs 3 txopLimit 0 -acm AC_BK cwmin 4 cwmax 10 aifs 7 txopLimit 0 -acm ack cwmin 4 cwmax 10 aifs 7 txopLimit 0 -acm AC_VI cwmin 3 cwmax 4 aifs 2 txopLimit 94 -acm ack cwmin 3 cwmax 4 aifs 2 txopLimit 94 -acm AC_VO cwmin 2 cwmax 3 aifs 2 txopLimit 47 -acm ack cwmin 2 cwmax 3 aifs 2 txopLimit 47 -acm media: IEEE 802.11 Wireless Ethernet MCS mode 11ng status: associated nd6 options=29 =================================================================================== If you need more test I can do. Send me the requests and I will response tomorrow. Thanks a lot! []'s -Otacílio From owner-freebsd-current@freebsd.org Fri Apr 8 21:22:48 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 70EFBB07AD4 for ; Fri, 8 Apr 2016 21:22:48 +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 34B1612BC for ; Fri, 8 Apr 2016 21:22:48 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aodrR-000CF2-7s; Sat, 09 Apr 2016 00:22:37 +0300 Date: Sat, 9 Apr 2016 00:22:37 +0300 From: Slawa Olhovchenkov To: Luigi Rizzo Cc: freebsd-current@freebsd.org Subject: Re: stall-free memory reads ? (possibly stale) ? Message-ID: <20160408212237.GA6614@zxy.spb.ru> References: <20160408162416.GA94343@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160408162416.GA94343@onelab2.iet.unipi.it> 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.21 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, 08 Apr 2016 21:22:48 -0000 On Fri, Apr 08, 2016 at 06:24:16PM +0200, Luigi Rizzo wrote: > Hi, > I have an application with two threads sharing a memory variable, > one continuously writing, one continuously reading. > > Because of the way my system works, the reader can tolerate reading > stale data, but it should not stall on memory reads (the line > is on the local cache for the reader, just might be invalidated). > > I was wondering if there is some way (either generic or > x86-specific, either simple or convoluted, possibly using > multiple versions of the shared variable in different cache > lines) to make sure that reads never stalls (or, equivalently, > let me read stale values from the cache) ? > > I have done some experiments and on a single-socket machines > the stallled reads take some 50ns; on a dual socket machine > the stall penalty grows to about 200ns. Can this link help to you? https://tu-dresden.de/die_tu_dresden/zentrale_einrichtungen/zih/forschung/projekte/benchit/2015_ICPP_authors_version.pdf From owner-freebsd-current@freebsd.org Fri Apr 8 21:40: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 AA491B08046; Fri, 8 Apr 2016 21:40:06 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001: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 7512D1AAB; Fri, 8 Apr 2016 21:40:06 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x233.google.com with SMTP id o126so124757650iod.0; Fri, 08 Apr 2016 14:40:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=5en61qZ+GzmeZ6NJtgBVB4mzHbOAlYxivRzFwLP/9+8=; b=IHjCId0cX4Yv8Fae+l3amsN3QoexEu2yAOyxzTS0JLNiNke1XWXub1x4EQDovmzjcA 3O16576+hp2DiYM28cTlMDRe4HBg1naVyMcyZxGzKrahrlu7gbBVTG/JoMrwVMltZCkv DhSLhNLOhv3zTAjaG6g18h9L6Lj1CEkXf6hcRdlg8Fk2flPVis5rpn2MI6nyzsJHznrj wINF5Cr8ECt/W0A4pGwPmDjVJVfBVCPjNPR5yAf4sEE7Ih9MgxEOiQyrGyuhXiRJmUq0 /aZtgym3F9mwowE10bzs1b/++TGULpYs+lWDE+WTbxqRqcZJ435iaF6EA06IYuQBcw2O 9ZOA== 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:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=5en61qZ+GzmeZ6NJtgBVB4mzHbOAlYxivRzFwLP/9+8=; b=IS794qVJ9SYt8EKMQVBkiFp8NfZ2xJYvzwkjnOwBQUXF1U8zcWTCmKIwBC6Bcv6yY0 W3SSYPSmdBzrVgeXEhejnj+Ay7D4P826QVGjV99yh1mqcBLYc8v8FMl8aQ4A05vOk8Yv xt28V5b450mVnnMg3XhC5MLLhYHG/AXzmr+plQQQ7vL1/CUNr8ZZ7WW5zOyGseAxEwgu dU36TGJy7H/AhxdD1QVG6JYPlodb9v8PP+bwefTTI8Pi//PLZ71EbxZNu5+pbGbrKZyo 7O9yff4SZs5unL5Ex1k0JfzL1R4835UeLewgTr8dZnqcZ1nl/+v1eWuzQjVxv9mLReDq VDCA== X-Gm-Message-State: AD7BkJI2FbeE/2qoQH3atlWg/KOF6o+kWnTrHfDmV2zO/EbNmQPlVw2bgQst2jwR4gsPVe2fUsf+CyCVHyZB7g== MIME-Version: 1.0 X-Received: by 10.107.35.82 with SMTP id j79mr11124593ioj.123.1460151605855; Fri, 08 Apr 2016 14:40:05 -0700 (PDT) Received: by 10.36.14.19 with HTTP; Fri, 8 Apr 2016 14:40:05 -0700 (PDT) In-Reply-To: <570819D7.3040206@bsd.com.br> References: <57080811.5030405@bsd.com.br> <570812A5.1050600@bsd.com.br> <570819D7.3040206@bsd.com.br> Date: Fri, 8 Apr 2016 14:40:05 -0700 Message-ID: Subject: Re: WIFI urtwn possibly broken on 297561 From: Adrian Chadd To: =?UTF-8?B?T3RhY8OtbGlv?= Cc: freebsd-current , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 08 Apr 2016 21:40:06 -0000 ok, try "ifconfig wlan0 -ht" before starting wpa_supplicant and see if that makes it any better. You should also include IEEE80211_AMPDU_AGE in your config file if you haven't yet. Also, include IEEE80211_DEBUG in there too, and try "wlandebug +rate +ht" ? -adrian On 8 April 2016 at 13:51, Otac=C3=ADlio wrote: > Em 08/04/2016 17:34, Adrian Chadd escreveu: >> >> Hi, >> >> Not '--ff', just '-ff' and '-amsdu' >> >> It's possible that one or the other of those options are a problem. I >> added those features recently to urtwn. >> >> Can you please do 'ifconfig -v wlan0 list sta' and 'ifconfig -v wlan0' ? >> >> Thanks, >> >> >> >> -adrian > > > Sorry, I type wrong but use the commands correctly :-) > > Its my rc.conf > > hostname=3D"beaglebone" > ifconfig_cpsw0=3D"DHCP" > sshd_enable=3D"YES" > > # Nice if you have a network, else annoying. > #ntpd_enable=3D"YES" > ntpd_sync_on_start=3D"YES" > > # Uncomment to disable common services (more memory) > #cron_enable=3D"NO" > #syslogd_enable=3D"NO" > > sendmail_submit_enable=3D"NO" > sendmail_outbound_enable=3D"NO" > sendmail_msp_queue_enable=3D"NO" > # On first boot, enlarge the root filesystem to fill the SD card > growfs_enable=3D"YES" > > wlans_urtwn0=3D"wlan0" > ifconfig_wlan0=3D"WPA SYNCDHCP -amsdu" > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > And the commands that you request: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > root@beaglebone:/usr/home/ota # ifconfig -v wlan0 list sta > ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG > 58:23:8c:c6:e1:aa 5 11 144M 14.5 0 5 19408 EP AQEHTR > SSID RATES DSPARMS<11> TIM<05040001000= 0> > ERP<0x4> ???<2f0104> RSN > XRATES<12,18,24,96> HTCAP 0x0 antenna 0x0> HTINFO WPS > VEN WPA > WME cwmax 10 txop 0] VO[aifsn 2 cwmin 3 cwmax 4 txop 94] VI[aifsn 2 cwmin 2 > cwmax 3 txop 47]> > root@beaglebone:/usr/home/ota # ifconfig -v wlan0 > wlan0: flags=3D8843 metric 0 mtu = 1500 > ether 14:cc:20:12:ee:55 > inet 192.168.0.25 netmask 0xffffff00 broadcast 192.168.0.255 > groups: wlan > ssid Diana channel 11 (2462 MHz 11g ht/20) bssid 58:23:8c:c6:e1:a= a > regdomain 0 country US anywhere -ecm authmode WPA2/802.11i -wps -= tsn > privacy ON deftxkey UNDEF > TKIP 2:128-bit powersavemode OFF powersavesleep 100 txpower 0 > txpowmax 50.0 -dotd rtsthreshold 2346 fragthreshold 2346 bmiss 7 > 11a ucast NONE mgmt 6 Mb/s mcast 6 Mb/s maxretry 6 > 11b ucast NONE mgmt 1 Mb/s mcast 1 Mb/s maxretry 6 > 11g ucast NONE mgmt 1 Mb/s mcast 1 Mb/s maxretry 6 > turboA ucast NONE mgmt 6 Mb/s mcast 6 Mb/s maxretry 6 > turboG ucast NONE mgmt 1 Mb/s mcast 1 Mb/s maxretry 6 > sturbo ucast NONE mgmt 6 Mb/s mcast 6 Mb/s maxretry 6 > 11na ucast NONE mgmt 12 MCS mcast 12 MCS maxretry 6 > 11ng ucast NONE mgmt 2 MCS mcast 2 MCS maxretry 6 > half ucast NONE mgmt 3 Mb/s mcast 3 Mb/s maxretry 6 > quarter ucast NONE mgmt 1 Mb/s mcast 1 Mb/s maxretry 6 > scanvalid 60 -bgscan bgscanintvl 300 bgscanidle 250 > roam:11a rssi 7dBm rate 12 Mb/s > roam:11b rssi 7dBm rate 1 Mb/s > roam:11g rssi 7dBm rate 5 Mb/s > roam:turboA rssi 7dBm rate 12 Mb/s > roam:turboG rssi 7dBm rate 12 Mb/s > roam:sturbo rssi 7dBm rate 12 Mb/s > roam:11na rssi 7dBm MCS 1 > roam:11ng rssi 7dBm MCS 1 > roam:half rssi 7dBm rate 6 Mb/s > roam:quarter rssi 7dBm rate 3 Mb/s > -pureg protmode CTS ht20 htcompat ampdu ampdulimit 64k ampdudensi= ty > 8 > -amsdu -shortgi htprotmode RTSCTS -puren -smps -rifs wme -burst > -dwds > roaming MANUAL bintval 100 > AC_BE cwmin 4 cwmax 10 aifs 3 txopLimit 0 -acm ack > cwmin 4 cwmax 10 aifs 3 txopLimit 0 -acm > AC_BK cwmin 4 cwmax 10 aifs 7 txopLimit 0 -acm ack > cwmin 4 cwmax 10 aifs 7 txopLimit 0 -acm > AC_VI cwmin 3 cwmax 4 aifs 2 txopLimit 94 -acm ack > cwmin 3 cwmax 4 aifs 2 txopLimit 94 -acm > AC_VO cwmin 2 cwmax 3 aifs 2 txopLimit 47 -acm ack > cwmin 2 cwmax 3 aifs 2 txopLimit 47 -acm > media: IEEE 802.11 Wireless Ethernet MCS mode 11ng > status: associated > nd6 options=3D29 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > If you need more test I can do. Send me the requests and I will response > tomorrow. > > > Thanks a lot! > > []'s > -Otac=C3=ADlio From owner-freebsd-current@freebsd.org Fri Apr 8 22:25:36 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 CAC63B0905A for ; Fri, 8 Apr 2016 22:25:36 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id BDDC911EF; Fri, 8 Apr 2016 22:25:36 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 263259FE; Fri, 8 Apr 2016 22:25:36 +0000 (UTC) Date: Fri, 8 Apr 2016 22:25:35 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <1499369481.5.1460154335016.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <397233237.3.1460139449217.JavaMail.jenkins@jenkins-9.freebsd.org> References: <397233237.3.1460139449217.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_HEAD #171 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 08 Apr 2016 22:25:36 -0000 See From owner-freebsd-current@freebsd.org Sat Apr 9 02:33: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 94B88B09616 for ; Sat, 9 Apr 2016 02:33:35 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 87CE41D67; Sat, 9 Apr 2016 02:33:35 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 3B048AA2; Sat, 9 Apr 2016 02:33:35 +0000 (UTC) Date: Sat, 9 Apr 2016 02:33:32 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <1648637074.7.1460169212748.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1499369481.5.1460154335016.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1499369481.5.1460154335016.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_HEAD #172 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 09 Apr 2016 02:33:35 -0000 See From owner-freebsd-current@freebsd.org Sat Apr 9 07:22: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 1410BB08684 for ; Sat, 9 Apr 2016 07:22:25 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 0700B1438; Sat, 9 Apr 2016 07:22:25 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 43486B89; Sat, 9 Apr 2016 07:22:25 +0000 (UTC) Date: Sat, 9 Apr 2016 07:22:25 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <847492494.13.1460186545198.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1648637074.7.1460169212748.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1648637074.7.1460169212748.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_HEAD #173 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 09 Apr 2016 07:22:25 -0000 See From owner-freebsd-current@freebsd.org Sat Apr 9 08:54:22 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 B872FB08024 for ; Sat, 9 Apr 2016 08:54:22 +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 5D40115B2; Sat, 9 Apr 2016 08:54:21 +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 <1aooef-003hbM-OV>; Sat, 09 Apr 2016 10:54:09 +0200 Received: from x55b3acb0.dyn.telefonica.de ([85.179.172.176] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (envelope-from ) id <1aooef-000oiO-AY>; Sat, 09 Apr 2016 10:54:09 +0200 Date: Sat, 9 Apr 2016 10:54:44 +0200 From: "O. Hartmann" To: Cy Schubert Cc: Michael Butler , "K. Macy" , FreeBSD CURRENT Subject: Re: CURRENT slow and shaky network stability Message-ID: <20160409105444.7020f2f1.ohartman@zedat.fu-berlin.de> In-Reply-To: <201604050646.u356k850078565@slippy.cwsent.com> References: <20160405082047.670d7241@freyja.zeit4.iv.bundesimmobilien.de> <201604050646.u356k850078565@slippy.cwsent.com> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/SqWr.x1C_BgJVIYh7m_9T5y"; protocol="application/pgp-signature" X-Originating-IP: 85.179.172.176 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 09 Apr 2016 08:54:22 -0000 --Sig_/SqWr.x1C_BgJVIYh7m_9T5y Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Mon, 04 Apr 2016 23:46:08 -0700 Cy Schubert schrieb: > In message <20160405082047.670d7241@freyja.zeit4.iv.bundesimmobilien.de>,= =20 > "O. H > artmann" writes: > > On Sat, 02 Apr 2016 16:14:57 -0700 > > Cy Schubert wrote: > > =20 > > > In message <20160402231955.41b05526.ohartman@zedat.fu-berlin.de>, "O.= =20 > > > Hartmann" > > > writes: =20 > > > > --Sig_/eJJPtbrEuK1nN2zIpc7BmVr > > > > Content-Type: text/plain; charset=3DUS-ASCII > > > > Content-Transfer-Encoding: quoted-printable > > > >=20 > > > > Am Sat, 2 Apr 2016 11:39:10 +0200 > > > > "O. Hartmann" schrieb: > > > > =20 > > > > > Am Sat, 2 Apr 2016 10:55:03 +0200 > > > > > "O. Hartmann" schrieb: > > > > >=3D20 =20 > > > > > > Am Sat, 02 Apr 2016 01:07:55 -0700 > > > > > > Cy Schubert schrieb: > > > > > > =3D20 =20 > > > > > > > In message <56F6C6B0.6010103@protected-networks.net>, Michael= Butle =20 > > r =20 > > > > > > > =3D =20 > > > > writes: =3D20 =20 > > > > > > > > -current is not great for interactive use at all. The strat= egy of > > > > > > > > pre-emptively dropping idle processes to swap is hurting ..= big > > > > > > > > tim=3D =20 > > > > e. =3D20 =20 > > > > > > >=3D20 > > > > > > > FreeBSD doesn't "preemptively" or arbitrarily push pages out = to > > > > > > > disk.=3D =20 > > > > LRU=3D20 =20 > > > > > > > doesn't do this. > > > > > > > =3D20 =20 > > > > > > > >=3D20 > > > > > > > > Compare inactive memory to swap in this example .. > > > > > > > >=3D20 > > > > > > > > 110 processes: 1 running, 108 sleeping, 1 zombie > > > > > > > > CPU: 1.2% user, 0.0% nice, 4.3% system, 0.0% interrupt,= 94.5% > > > > > > > > i=3D =20 > > > > dle =20 > > > > > > > > Mem: 474M Active, 1609M Inact, 764M Wired, 281M Buf, 119M F= ree > > > > > > > > Swap: 4096M Total, 917M Used, 3178M Free, 22% Inuse =3D= 20 =20 > > > > > > >=3D20 > > > > > > > To analyze this you need to capture vmstat output. You'll see= the > > > > > > > fre=3D =20 > > > > e pool=3D20 =20 > > > > > > > dip below a threshold and pages go out to disk in response. I= f you > > > > > > > ha=3D =20 > > > > ve=3D20 =20 > > > > > > > daemons with small working sets, pages that are not part of t= he > > > > > > > worki=3D =20 > > > > ng=3D20 =20 > > > > > > > sets for daemons or applications will eventually be paged out= . This > > > > > > > i=3D =20 > > > > s not=3D20 =20 > > > > > > > a bad thing. In your example above, the 281 MB of UFS buffers= are > > > > > > > mor=3D =20 > > > > e=3D20 =20 > > > > > > > active than the 917 MB paged out. If it's paged out and never= used > > > > > > > ag=3D =20 > > > > ain,=3D20 =20 > > > > > > > then it doesn't hurt. However the 281 MB of buffers saves you= I/O. > > > > > > > Th=3D =20 > > > > e=3D20 =20 > > > > > > > inactive pages are part of your free pool that were active at= one > > > > > > > tim=3D =20 > > > > e but=3D20 =20 > > > > > > > now are not. They may be reclaimed and if they are, you've ju= st > > > > > > > saved=3D =20 > > > > more=3D20 =20 > > > > > > > I/O. > > > > > > >=3D20 > > > > > > > Top is a poor tool to analyze memory use. Vmstat is the bette= r tool > > > > > > > t=3D =20 > > > > o help=3D20 =20 > > > > > > > understand memory use. Inactive memory isn't a bad thing per = se. > > > > > > > Moni=3D =20 > > > > tor=3D20 =20 > > > > > > > page outs, scan rate and page reclaims. > > > > > > >=3D20 > > > > > > > =3D20 =20 > > > > > >=3D20 > > > > > > I give up! Tried to check via ssh/vmstat what is going on. Last= lines > > > > > > b=3D =20 > > > > efore broken =20 > > > > > > pipe: > > > > > >=3D20 > > > > > > [...] > > > > > > procs memory page disks faults = =20 > > cpu =20 > > > > > > r b w avm fre flt re pi po fr sr ad0 ad1 in s= y c =20 > > s =20 > > > > > > =3D =20 > > > > us sy id =20 > > > > > > 22 0 22 5.8G 1.0G 46319 0 0 0 55721 1297 0 4 219 23= 907 > > > > > > 540=3D =20 > > > > 0 95 5 0 =20 > > > > > > 22 0 22 5.4G 1.3G 51733 0 0 0 72436 1162 0 0 108 40= 869 > > > > > > 345=3D =20 > > > > 9 93 7 0 =20 > > > > > > 15 0 22 12G 1.2G 54400 0 27 0 52188 1160 0 42 148 52= 192 > > > > > > 436=3D =20 > > > > 6 91 9 0 =20 > > > > > > 14 0 22 12G 1.0G 44954 0 37 0 37550 1179 0 39 141 86= 209 > > > > > > 436=3D =20 > > > > 8 88 12 0 =20 > > > > > > 26 0 22 12G 1.1G 60258 0 81 0 69459 1119 0 27 123 77= 9569 > > > > > > 704=3D =20 > > > > 359 87 13 0 =20 > > > > > > 29 3 22 13G 774M 50576 0 68 0 32204 1304 0 2 102 50= 7337 > > > > > > 484=3D =20 > > > > 861 93 7 0 =20 > > > > > > 27 0 22 13G 937M 47477 0 48 0 59458 1264 3 2 112 68= 131 > > > > > > 4440=3D =20 > > > > 7 95 5 0 =20 > > > > > > 36 0 22 13G 829M 83164 0 2 0 82575 1225 1 0 126 99= 366 > > > > > > 3806=3D =20 > > > > 0 89 11 0 =20 > > > > > > 35 0 22 6.2G 1.1G 98803 0 13 0 121375 1217 2 8 112 9= 9371 > > > > > > 49=3D =20 > > > > 99 85 15 0 =20 > > > > > > 34 0 22 13G 723M 54436 0 20 0 36952 1276 0 17 153 29= 142 > > > > > > 443=3D =20 > > > > 1 95 5 0 =20 > > > > > > Fssh_packet_write_wait: Connection to 192.168.0.1 port 22: Brok= en pip =20 > > e =20 > > > > > >=3D20 > > > > > >=3D20 > > > > > > This makes this crap system completely unusable. The server (Fr= eeBSD > > > > > > 11=3D =20 > > > > .0-CURRENT #20 =20 > > > > > > r297503: Sat Apr 2 09:02:41 CEST 2016 amd64) in question did > > > > > > poudriere=3D =20 > > > > bulk job. I =20 > > > > > > can not even determine what terminal goes down first - another = one, > > > > > > muc=3D =20 > > > > h more time =20 > > > > > > idle than the one shwoing the "vmstat 5" output, is still alive= !=3D20 > > > > > >=3D20 > > > > > > i consider this a serious bug and it is no benefit what happene= d sinc =20 > > e =20 > > > > > > =3D =20 > > > > this "fancy" =20 > > > > > > update. :-( =3D20 =20 > > > > >=3D20 > > > > > By the way - it might be of interest and some hint. > > > > >=3D20 > > > > > One of my boxes is acting as server and gateway. It utilises NAT,= IPFW, > > > > > w=3D =20 > > > > hen it is under =20 > > > > > high load, as it was today, sometimes passing the network flow fr= om ISP > > > > > i=3D =20 > > > > nto the network =20 > > > > > for clients is extremely slow. I do not consider this the reason = for > > > > > coll=3D =20 > > > > apsing ssh =20 > > > > > sessions, since this incident happens also under no-load, but in = the > > > > > over=3D =20 > > > > all-view onto =20 > > > > > the problem, this could be a hint - I hope.=3D20 =20 > > > >=20 > > > > I just checked on one box, that "broke pipe" very quickly after I s= tarted =20 > > p=3D =20 > > > > oudriere, > > > > while it did well a couple of hours before until the pipe broke. It= seems =20 > > i=3D =20 > > > > t's load > > > > dependend when the ssh session gets wrecked, but more important, af= ter th =20 > > e =3D =20 > > > > long-haul > > > > poudriere run, I rebooted the box and tried again with the mentione= d brok =20 > > en=3D =20 > > > > pipe after a > > > > couple of minutes after poudriere ran. Then I left the box for seve= ral ho =20 > > ur=3D =20 > > > > s and logged > > > > in again and checked the swap. Although there was for hours no load= or ot =20 > > he=3D =20 > > > > r pressure, > > > > there were 31% of of swap used - still (box has 16 GB of RAM and is= prope =20 > > ll=3D =20 > > > > ed by a XEON > > > > E3-1245 V2). > > > > =20 > > >=20 > > > 31%! Is it *actively* paging or is the 31% previously paged out and n= o=20 > > > paging is *currently* being experienced? 31% of how swap space in tot= al? > > >=20 > > > Also, what does ps aumx or ps aumxww say? Pipe it to head -40 or simi= lar. > > >=20 > > > =20 > >=20 > > On FreeBSD 11.0-CURRENT #4 r297573: Tue Apr 5 07:01:19 CEST 2016 amd64= , loca > > l > > network, no NAT. Stuck ssh session in the middle of administering and l= eaving > > the console/ssh session for a couple of minutes: > >=20 > > root 2064 0.0 0.1 91416 8492 - Is 07:18 0:00.03 ssh= d: > > hartmann [priv] (sshd) > >=20 > > hartmann 2108 0.0 0.1 91416 8664 - I 07:18 0:07.33 ssh= d: > > hartmann@pts/0 (sshd) > >=20 > > root 72961 0.0 0.1 91416 8496 - Is 08:11 0:00.03 ssh= d: > > hartmann [priv] (sshd) > >=20 > > hartmann 72970 0.0 0.1 91416 8564 - S 08:11 0:00.02 ssh= d: > > hartmann@pts/1 (sshd) > >=20 > > The situation is worse and i consider this a serious bug. > > =20 >=20 > There's not a lot to go on here. Do you have physical access to the machi= ne=20 > to pop into DDB and take a look? You did say you're using a lot of swap.= =20 > IIRC 30%. You didn't answer how much 30% was of. Without more data I can'= t=20 > help you. At the best I can take wild guesses but that won't help you. Tr= y=20 > to answer the questions I asked last week and we can go further. Until th= en=20 > all we can do is wildly guess. >=20 >=20 Apologies for the late answer, I'm busy. Well, The "homebox" is physical accessible as well as the systems at work, = but at work they are heavily used right now. As you stated in your prior to this Email, I "overload" the boxes. Yes, I d= o this by intention and FreeBSD CURRENT withstood those attacks - approximately until= 3 or 4 weeks ago, when these problems occured. 30% swap was the "remain" after I started poudriere, poudriere "died" due t= o a lost/broken pipe ssh session and did not relax after hours! The box didn't = do anything in that time after the pipe was broken. So I mentioned this.=20 You also mentioned UFS and ZFS concurrency. Yes, I use a mixed system. UFS = for the system's partitions, and ZFS for the data volumes. UFS is on SSDs "faster",= but this is only a subjective impression of mine. Having /usr/ports on UFS and ZFS and = enough memory (32 GB RAM) shows significant differences on the very same HDD drive: while= UFS has finished a "matured" svn tree, the ZFS based tree could take up to 5 or 6 m= inutes until finished. I think this is due to the growing .svn-folder. But on ZFS this o= ccurs only the first time the update of /usr/ports is done. Just to say: if UFS and ZFS coexistency is critical, this is defintely a mu= st for the handbook! But on the other hand, what I complain about is a dramatically change in st= ability of CURRENT since the first occurency of the reported problems. Before, the ver= y same hardware, the very same setup, the very same jobs performed well. I pushed = the boxes with poudriere and several scientific jobs to their limits, and they took it lik= e a German tank.=20 By the way, I use csh in all scenarios - I do not know whether this helps. So, I'm at this moment quite unfamiliar with deeper investigations of the F= reeBSD OS with tools for debugging, but this has high priority on my to-do-list. If someon= e can hint me towards the right tools and literature (manpages, also maybe sections in de= velopment literature for FreeBSD), it would be highly appreciated. And another info that came just to my mind right now: I use tmpfs on /tmp and /var/run. I also have a GELI encrypted swap partiti= on (on UFS based SSD).=20 Kind regards, Oliver --Sig_/SqWr.x1C_BgJVIYh7m_9T5y Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXCMNUAAoJEOgBcD7A/5N8AfcIAKniTue/BHkODRYcD3YWEhu1 A44k4TF6jBBbgQkb8tt/gEKkRTCT3dOyK5Sjq6eASqO4jaoflVlU7YMS2RjVWl7K nt7xLsNjA1QcysoFc7ADCDACSdWaFEBpaYYaw+wPPL6K8/q8tCo3aD0lUjsvBHA1 TDmxWrGrtP8C0cirEafKJIrSeRlacQcCKFKoHbjdxn5ja4Pvf138S41/yH2Np92y kw7PlYKOvwooIP+LLs+CkUxyvi9MRfYnwaKx/gdfzHtQ1RHk2BAQd2FyCRZyGNi0 PhTl03ats4Yvhb6Hb9RbJEAYmcMmwg25zuMlA/X+FNfh2ULgm+8TGy9Cf6OHn/Q= =POS3 -----END PGP SIGNATURE----- --Sig_/SqWr.x1C_BgJVIYh7m_9T5y-- From owner-freebsd-current@freebsd.org Sat Apr 9 11:29:03 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 A20DDB0784D for ; Sat, 9 Apr 2016 11:29:03 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 94F321687; Sat, 9 Apr 2016 11:29:03 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 449FEC30; Sat, 9 Apr 2016 11:29:04 +0000 (UTC) Date: Sat, 9 Apr 2016 11:29:04 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <720652704.17.1460201344160.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <847492494.13.1460186545198.JavaMail.jenkins@jenkins-9.freebsd.org> References: <847492494.13.1460186545198.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_HEAD #174 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 09 Apr 2016 11:29:03 -0000 See From owner-freebsd-current@freebsd.org Sat Apr 9 12:23: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 9E525B092E8 for ; Sat, 9 Apr 2016 12:23:29 +0000 (UTC) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from saturn.lyxys.ka.sub.org (saturn.lyxys.ka.sub.org [217.29.35.151]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 358241613 for ; Sat, 9 Apr 2016 12:23:28 +0000 (UTC) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from juno.lyxys.ka.sub.org (juno.lyx [IPv6:fd2a:89ca:7d54:0:240:caff:fe92:4f47]) by saturn.lyxys.ka.sub.org (8.15.2/8.15.2) with ESMTPS id u39CA5bI024359 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=FAIL) for ; Sat, 9 Apr 2016 14:10:06 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from juno.lyxys.ka.sub.org (localhost [127.0.0.1]) by juno.lyxys.ka.sub.org (8.15.2/8.15.2) with ESMTPS id u39CA4mI069166 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 9 Apr 2016 14:10:04 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) Received: (from wolfgang@localhost) by juno.lyxys.ka.sub.org (8.15.2/8.15.2/Submit) id u39CA4kl069165 for freebsd-current@freebsd.org; Sat, 9 Apr 2016 14:10:04 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) X-Authentication-Warning: juno.lyx: wolfgang set sender to wolfgang@lyxys.ka.sub.org using -f Date: Sat, 9 Apr 2016 14:10:04 +0200 From: Wolfgang Zenker To: freebsd-current@freebsd.org Subject: Acer C720 crash at boot Message-ID: <20160409121004.GA69051@lyxys.ka.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: private site User-Agent: Mutt/1.5.24 (2015-08-30) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (saturn.lyxys.ka.sub.org [IPv6:fd2a:89ca:7d54:1:200:24ff:feca:b4cc]); Sat, 09 Apr 2016 14:10:06 +0200 (CEST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 09 Apr 2016 12:23:29 -0000 Hi, I can no longer boot my Acer C720 with current; during boot I get a panic and the system drops into kdb, unfortunately without a working keyboard. What is visible on the screen looks like it might be a stack trace; top line starts with vpanic(). Would transcribing the screen output be of any use? When I first noticed this a few days ago, I assumed I might have just updated src in the mittle of a change, so I went back to kernel.old and updated src again yesterday (twice within some time to make sure I'm not in the middle of something) and rebuilt. kernel.old is a few weeks old now. I'm using GENERIC. Wolfgang From owner-freebsd-current@freebsd.org Sat Apr 9 12:35:57 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 7AF87B09C35 for ; Sat, 9 Apr 2016 12:35:57 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from vps.amdmi3.ru (vps.amdmi3.ru [109.234.38.216]) by mx1.freebsd.org (Postfix) with ESMTP id 457D1187E; Sat, 9 Apr 2016 12:35:56 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from hive.panopticon (unknown [78.153.152.119]) by vps.amdmi3.ru (Postfix) with ESMTPS id 93D33B0582; Sat, 9 Apr 2016 15:35:49 +0300 (MSK) Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id 72689C68; Fri, 8 Apr 2016 16:01:19 +0300 (MSK) Received: by hades.panopticon (Postfix, from userid 1000) id 80E90ADA; Fri, 8 Apr 2016 15:59:03 +0300 (MSK) Date: Fri, 8 Apr 2016 15:59:03 +0300 From: Dmitry Marakasov To: Ngie Cooper Cc: Olivier =?utf-8?Q?Cochard-Labb=C3=A9?= , "freebsd-current@freebsd.org" Subject: Re: Keeping OptionalObsoleteFiles.inc up to date Message-ID: <20160408125903.GD11361@hades.panopticon> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 09 Apr 2016 12:35:57 -0000 * Ngie Cooper (yaneurabeya@gmail.com) wrote: > > I'm trying to use "make delete-old" specifying WITHOUT_ keyword for > > removing some no-more used set of files. > > > > I've start by testing WITHOUT_TOOLCHAIN: > > - Some of files related to clang are correctly delete > > - But there are still lot's of others (like /usr/bin/cc) > > > > Then I've checked tools/build/mk/OptionalObsoleteFiles.in and found that > > lot's files are missing in the ".if ${MK_TOOLCHAIN} == no" section. > > > > I've started a new run of phk's build_options_survey script: > > https://people.freebsd.org/~olivier/build_option_survey_20160406/ > > > > And wonder if it's possible to automatically generate the list of > > conditional files to be put in OptionalObsoleteFiles.in from the result of > > a build_option_survey script ? > > amdmi3 had a method for doing this, but I think it was a bit of a > brute force approach (I could be wrong). You are not. https://github.com/AMDmi3/obsolete-files-checker > The release-pkg project branch method seems like the best way to go > about it though because it would kind of do the sanity checking for > us... Agreed. make delete-old + OptionalObsoleteFiles.in will never be complete and work correctly. I'm waiting for packaged base too. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://amdmi3.ru From owner-freebsd-current@freebsd.org Sat Apr 9 12:49:36 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 8DB97B0905B for ; Sat, 9 Apr 2016 12:49:36 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C496F1F90 for ; Sat, 9 Apr 2016 12:49:35 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA12586; Sat, 09 Apr 2016 15:49:31 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1aosKR-000F90-MX; Sat, 09 Apr 2016 15:49:31 +0300 Subject: Re: Acer C720 crash at boot To: Wolfgang Zenker , freebsd-current@FreeBSD.org References: <20160409121004.GA69051@lyxys.ka.sub.org> From: Andriy Gapon Message-ID: <5708FA24.6040108@FreeBSD.org> Date: Sat, 9 Apr 2016 15:48:36 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <20160409121004.GA69051@lyxys.ka.sub.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 09 Apr 2016 12:49:36 -0000 On 09/04/2016 15:10, Wolfgang Zenker wrote: > Hi, > > I can no longer boot my Acer C720 with current; during boot I get > a panic and the system drops into kdb, unfortunately without a > working keyboard. What is visible on the screen looks like > it might be a stack trace; top line starts with vpanic(). > Would transcribing the screen output be of any use? Or better snap a picture with a smartphone or a digital camera, upload the picture somewhere and send a link to it (do not attach the image to a post, that won't work). > When I first noticed this a few days ago, I assumed I might > have just updated src in the mittle of a change, so I went back > to kernel.old and updated src again yesterday (twice within > some time to make sure I'm not in the middle of something) > and rebuilt. kernel.old is a few weeks old now. > I'm using GENERIC. -- Andriy Gapon From owner-freebsd-current@freebsd.org Sat Apr 9 13:28: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 42BC5B09C6E for ; Sat, 9 Apr 2016 13:28:06 +0000 (UTC) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from saturn.lyxys.ka.sub.org (saturn.lyxys.ka.sub.org [217.29.35.151]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CC0621161 for ; Sat, 9 Apr 2016 13:28:04 +0000 (UTC) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from juno.lyxys.ka.sub.org (juno.lyx [IPv6:fd2a:89ca:7d54:0:240:caff:fe92:4f47]) by saturn.lyxys.ka.sub.org (8.15.2/8.15.2) with ESMTPS id u39DRllJ024550 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=FAIL) for ; Sat, 9 Apr 2016 15:27:48 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from juno.lyxys.ka.sub.org (localhost [127.0.0.1]) by juno.lyxys.ka.sub.org (8.15.2/8.15.2) with ESMTPS id u39DRlpF070328 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 9 Apr 2016 15:27:47 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) Received: (from wolfgang@localhost) by juno.lyxys.ka.sub.org (8.15.2/8.15.2/Submit) id u39DRkCm070327 for freebsd-current@FreeBSD.org; Sat, 9 Apr 2016 15:27:46 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) X-Authentication-Warning: juno.lyx: wolfgang set sender to wolfgang@lyxys.ka.sub.org using -f Date: Sat, 9 Apr 2016 15:27:46 +0200 From: Wolfgang Zenker To: freebsd-current@FreeBSD.org Subject: Re: Acer C720 crash at boot Message-ID: <20160409132746.GA69968@lyxys.ka.sub.org> References: <20160409121004.GA69051@lyxys.ka.sub.org> <5708FA24.6040108@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5708FA24.6040108@FreeBSD.org> Organization: private site User-Agent: Mutt/1.5.24 (2015-08-30) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (saturn.lyxys.ka.sub.org [IPv6:fd2a:89ca:7d54:1:200:24ff:feca:b4cc]); Sat, 09 Apr 2016 15:27:48 +0200 (CEST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 09 Apr 2016 13:28:06 -0000 * Andriy Gapon [160409 14:48]: > On 09/04/2016 15:10, Wolfgang Zenker wrote: >> I can no longer boot my Acer C720 with current; during boot I get >> a panic and the system drops into kdb, unfortunately without a >> working keyboard. What is visible on the screen looks like >> it might be a stack trace; top line starts with vpanic(). >> Would transcribing the screen output be of any use? > Or better snap a picture with a smartphone or a digital camera, upload the > picture somewhere and send a link to it (do not attach the image to a post, that > won't work). Done: http://cid2945g797.hs14.hosting.punkt.de/IMG_3762.JPG (sorry, 2.3 MB) Wolfgang From owner-freebsd-current@freebsd.org Sat Apr 9 13:50: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 47218B09331 for ; Sat, 9 Apr 2016 13:50:10 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0CD671C41 for ; Sat, 9 Apr 2016 13:50:09 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [62.216.192.160] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1aosLA-0001vo-9Z for freebsd-current@freebsd.org; Sat, 09 Apr 2016 14:50:16 +0200 Received: from localhost.my.domain (c720-r292778-amd64 [127.0.0.1]) by localhost.unixarea.de (8.15.2/8.14.9) with ESMTPS id u39CoFGE003110 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 9 Apr 2016 14:50:15 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.15.2/8.14.9/Submit) id u39CoEe8003109 for freebsd-current@freebsd.org; Sat, 9 Apr 2016 14:50:14 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sat, 9 Apr 2016 14:50:14 +0200 From: Matthias Apitz To: freebsd-current@freebsd.org Subject: Re: Acer C720 crash at boot Message-ID: <20160409125014.GB3029@c720-r292778-amd64> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , freebsd-current@freebsd.org References: <20160409121004.GA69051@lyxys.ka.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160409121004.GA69051@lyxys.ka.sub.org> X-Operating-System: FreeBSD 11.0-CURRENT r292778 (amd64) User-Agent: Mutt/1.5.24 (2015-08-30) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 62.216.192.160 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 09 Apr 2016 13:50:10 -0000 El día Saturday, April 09, 2016 a las 02:10:04PM +0200, Wolfgang Zenker escribió: > Hi, > > I can no longer boot my Acer C720 with current; during boot I get > a panic and the system drops into kdb, unfortunately without a > working keyboard. What is visible on the screen looks like > it might be a stack trace; top line starts with vpanic(). > Would transcribing the screen output be of any use? > ... Hi, Maybe a photo of the screen (put it on some server, not by mail, or send it to me directly and I put it on my server). matthias (long time C720 user with CURRENT) -- Matthias Apitz, ✉ guru@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 From owner-freebsd-current@freebsd.org Sat Apr 9 14:25: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 A6476B09F14 for ; Sat, 9 Apr 2016 14:25:46 +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 419F01333; Sat, 9 Apr 2016 14:25:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u39EPaTC048371 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 9 Apr 2016 17:25:36 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u39EPaTC048371 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u39EPZqX048364; Sat, 9 Apr 2016 17:25:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 9 Apr 2016 17:25:35 +0300 From: Konstantin Belousov To: Wolfgang Zenker Cc: freebsd-current@FreeBSD.org, jhb@freebsd.org, freebsd@grem.de Subject: Re: Acer C720 crash at boot Message-ID: <20160409142535.GP1741@kib.kiev.ua> References: <20160409121004.GA69051@lyxys.ka.sub.org> <5708FA24.6040108@FreeBSD.org> <20160409132746.GA69968@lyxys.ka.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160409132746.GA69968@lyxys.ka.sub.org> User-Agent: Mutt/1.5.24 (2015-08-30) 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.21 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, 09 Apr 2016 14:25:46 -0000 On Sat, Apr 09, 2016 at 03:27:46PM +0200, Wolfgang Zenker wrote: > Done: http://cid2945g797.hs14.hosting.punkt.de/IMG_3762.JPG The immediate cause was the change in r297466, but the code that existed there, did not worked. It looks as a bug in ichiic, set_controller() use msleep() with timeout too early when compiled into the kernel. From owner-freebsd-current@freebsd.org Sat Apr 9 15:00: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 05BB3B087F4 for ; Sat, 9 Apr 2016 15:00:14 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id ECF15131F; Sat, 9 Apr 2016 15:00:13 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id D7846CB4; Sat, 9 Apr 2016 15:00:13 +0000 (UTC) Date: Sat, 9 Apr 2016 15:00:13 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <2101111082.18.1460214013378.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <720652704.17.1460201344160.JavaMail.jenkins@jenkins-9.freebsd.org> References: <720652704.17.1460201344160.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_HEAD #175 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 09 Apr 2016 15:00:14 -0000 See From owner-freebsd-current@freebsd.org Sat Apr 9 15:27: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 B26D3B08FBC for ; Sat, 9 Apr 2016 15:27:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.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 938861DB3 for ; Sat, 9 Apr 2016 15:27:33 +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 bigwig.baldwin.cx (Postfix) with ESMTPSA id 29FCFB94C; Sat, 9 Apr 2016 11:27:32 -0400 (EDT) From: John Baldwin To: Konstantin Belousov Cc: Wolfgang Zenker , freebsd-current@freebsd.org, freebsd@grem.de Subject: Re: Acer C720 crash at boot Date: Sat, 09 Apr 2016 08:27:27 -0700 Message-ID: <1560530.UPOY1Ni5U9@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20160409142535.GP1741@kib.kiev.ua> References: <20160409121004.GA69051@lyxys.ka.sub.org> <20160409132746.GA69968@lyxys.ka.sub.org> <20160409142535.GP1741@kib.kiev.ua> 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.2.7 (bigwig.baldwin.cx); Sat, 09 Apr 2016 11:27:32 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 09 Apr 2016 15:27:33 -0000 On Saturday, April 09, 2016 05:25:35 PM Konstantin Belousov wrote: > On Sat, Apr 09, 2016 at 03:27:46PM +0200, Wolfgang Zenker wrote: > > Done: http://cid2945g797.hs14.hosting.punkt.de/IMG_3762.JPG > > The immediate cause was the change in r297466, but the code that existed > there, did not worked. It looks as a bug in ichiic, set_controller() > use msleep() with timeout too early when compiled into the kernel. Can you try this change: diff --git a/sys/dev/ichiic/ig4_iic.c b/sys/dev/ichiic/ig4_iic.c index a556127..23bdb7d 100644 --- a/sys/dev/ichiic/ig4_iic.c +++ b/sys/dev/ichiic/ig4_iic.c @@ -117,7 +117,10 @@ set_controller(ig4iic_softc_t *sc, uint32_t ctl) error = 0; break; } - mtx_sleep(sc, &sc->io_lock, 0, "i2cslv", 1); + if (cold) + DELAY(1000); + else + mtx_sleep(sc, &sc->io_lock, 0, "i2cslv", 1); } return (error); } -- John Baldwin From owner-freebsd-current@freebsd.org Sat Apr 9 16:42: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 8D9C3B09561 for ; Sat, 9 Apr 2016 16:42:46 +0000 (UTC) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from saturn.lyxys.ka.sub.org (saturn.lyxys.ka.sub.org [217.29.35.151]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 212A012AB; Sat, 9 Apr 2016 16:42:45 +0000 (UTC) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from juno.lyxys.ka.sub.org (juno.lyx [IPv6:fd2a:89ca:7d54:0:240:caff:fe92:4f47]) by saturn.lyxys.ka.sub.org (8.15.2/8.15.2) with ESMTPS id u39GgRVD024956 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=FAIL); Sat, 9 Apr 2016 18:42:28 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from juno.lyxys.ka.sub.org (localhost [127.0.0.1]) by juno.lyxys.ka.sub.org (8.15.2/8.15.2) with ESMTPS id u39GgRIW073161 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 9 Apr 2016 18:42:27 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) Received: (from wolfgang@localhost) by juno.lyxys.ka.sub.org (8.15.2/8.15.2/Submit) id u39GgQVr073160; Sat, 9 Apr 2016 18:42:26 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) X-Authentication-Warning: juno.lyx: wolfgang set sender to wolfgang@lyxys.ka.sub.org using -f Date: Sat, 9 Apr 2016 18:42:26 +0200 From: Wolfgang Zenker To: John Baldwin Cc: Konstantin Belousov , freebsd-current@freebsd.org, freebsd@grem.de Subject: Re: Acer C720 crash at boot Message-ID: <20160409164226.GB69968@lyxys.ka.sub.org> References: <20160409121004.GA69051@lyxys.ka.sub.org> <20160409132746.GA69968@lyxys.ka.sub.org> <20160409142535.GP1741@kib.kiev.ua> <1560530.UPOY1Ni5U9@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1560530.UPOY1Ni5U9@ralph.baldwin.cx> Organization: private site User-Agent: Mutt/1.5.24 (2015-08-30) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (saturn.lyxys.ka.sub.org [IPv6:fd2a:89ca:7d54:1:200:24ff:feca:b4cc]); Sat, 09 Apr 2016 18:42:28 +0200 (CEST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 09 Apr 2016 16:42:46 -0000 Hi, system does not crash with this patch, thanks! * John Baldwin [160409 17:27]: > On Saturday, April 09, 2016 05:25:35 PM Konstantin Belousov wrote: >> On Sat, Apr 09, 2016 at 03:27:46PM +0200, Wolfgang Zenker wrote: >>> Done: http://cid2945g797.hs14.hosting.punkt.de/IMG_3762.JPG >> The immediate cause was the change in r297466, but the code that existed >> there, did not worked. It looks as a bug in ichiic, set_controller() >> use msleep() with timeout too early when compiled into the kernel. > Can you try this change: > diff --git a/sys/dev/ichiic/ig4_iic.c b/sys/dev/ichiic/ig4_iic.c > index a556127..23bdb7d 100644 > --- a/sys/dev/ichiic/ig4_iic.c > +++ b/sys/dev/ichiic/ig4_iic.c > @@ -117,7 +117,10 @@ set_controller(ig4iic_softc_t *sc, uint32_t ctl) > error = 0; > break; > } > - mtx_sleep(sc, &sc->io_lock, 0, "i2cslv", 1); > + if (cold) > + DELAY(1000); > + else > + mtx_sleep(sc, &sc->io_lock, 0, "i2cslv", 1); > } > return (error); > } Wolfgang From owner-freebsd-current@freebsd.org Sat Apr 9 18:35: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 43A69B081E3 for ; Sat, 9 Apr 2016 18:35:24 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 272551694; Sat, 9 Apr 2016 18:35:24 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 48E85D6D; Sat, 9 Apr 2016 18:35:23 +0000 (UTC) Date: Sat, 9 Apr 2016 18:35:22 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <658815625.19.1460226922209.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <2101111082.18.1460214013378.JavaMail.jenkins@jenkins-9.freebsd.org> References: <2101111082.18.1460214013378.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_HEAD #176 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 09 Apr 2016 18:35:24 -0000 See From owner-freebsd-current@freebsd.org Sat Apr 9 22:50:58 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 ACEF0B094E8 for ; Sat, 9 Apr 2016 22:50:58 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 97F571A9B; Sat, 9 Apr 2016 22:50:58 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id A6CC0E56; Sat, 9 Apr 2016 22:50:58 +0000 (UTC) Date: Sat, 9 Apr 2016 22:50:58 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <94732689.21.1460242258111.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <658815625.19.1460226922209.JavaMail.jenkins@jenkins-9.freebsd.org> References: <658815625.19.1460226922209.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_HEAD #177 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 09 Apr 2016 22:50:58 -0000 See