From owner-freebsd-current@freebsd.org Sun Oct 25 07:44:51 2015 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 A479D8277 for ; Sun, 25 Oct 2015 07:44:51 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::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 75A5C1DD5; Sun, 25 Oct 2015 07:44:51 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by padhk11 with SMTP id hk11so156984750pad.1; Sun, 25 Oct 2015 00:44:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LQwVOq+9mOB2S6t9Yo26mwY7omfz0U1+2N/xl8obvvo=; b=Vregp4K7HSrVHGIa22lK8kexuholLHEw0vdQ9NEkkswWQPd4uyRucp+y7C99WVwkvC KR/5A/jkSayC2acafVGskuEjB2+sGKXyzULukrKP+b97GKCN+CLDw+oM5wk5FXkn/Aic e47lLsxyx2Xi69MW2LFuaJrvrbMP4pcuXs8g3x0Zl1lyf8OWRNTjwjVvAL5hvZ2Y9WG1 MU1s1qvkG52hcPbsaHjaP0YBkVMKVs8rOi4SAaQYP8Ql1PUm1MlpEpfhvvp2fnV4DKpk tFP+YnEJtI6Zf9wn7a7bKoswlY7bSOTRjfm3YCPWxc1kNyqIXMS/H8Q56OItIuDihx9A eF3Q== X-Received: by 10.68.57.171 with SMTP id j11mr34781610pbq.17.1445759090944; Sun, 25 Oct 2015 00:44:50 -0700 (PDT) Received: from [192.168.20.7] (c-24-16-212-205.hsd1.wa.comcast.net. [24.16.212.205]) by smtp.gmail.com with ESMTPSA id qn5sm27616834pac.41.2015.10.25.00.44.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 25 Oct 2015 00:44:50 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: r287797 breaks build WITHOUT_NIS From: NGie Cooper In-Reply-To: Date: Sun, 25 Oct 2015 00:44:49 -0700 Cc: FreeBSD Current , Craig Rodrigues Content-Transfer-Encoding: quoted-printable Message-Id: <0B5D0762-F5A6-4025-A16F-E7A96DF72BF4@gmail.com> References: To: Justin Hibbits X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 25 Oct 2015 07:44:51 -0000 > On Oct 10, 2015, at 16:18, Justin Hibbits = wrote: >=20 > When building WITHOUT_NIS, the following errors show up (base gcc, for > building powerpc): >=20 > cc1: warnings being treated as errors > /home/chmeee/freebsd/head/lib/libc/gen/getgrent.c: In function > 'compat_setgrent': > /home/chmeee/freebsd/head/lib/libc/gen/getgrent.c:1258: warning: > comparison is always false due to limited range of data type > /home/chmeee/freebsd/head/lib/libc/gen/getgrent.c:1267: warning: > comparison is always false due to limited range of data type > /home/chmeee/freebsd/head/lib/libc/gen/getgrent.c: In function = 'compat_group': > /home/chmeee/freebsd/head/lib/libc/gen/getgrent.c:1355: warning: > comparison is always false due to limited range of data type > /home/chmeee/freebsd/head/lib/libc/gen/getgrent.c:1378: warning: > comparison is always false due to limited range of data type >=20 > Converting the local variable in the macros back to int fixes it. Fixed in r289925. Thanks!= From owner-freebsd-current@freebsd.org Sat Oct 24 16:37:17 2015 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 01E1BA1DC2F; Sat, 24 Oct 2015 16:37: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 E49FA14C9; Sat, 24 Oct 2015 16:37:16 +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 3FF40144D; Sat, 24 Oct 2015 16:37:17 +0000 (UTC) Date: Sat, 24 Oct 2015 16:37:12 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: markj@FreeBSD.org, mav@FreeBSD.org, emaste@FreeBSD.org, asomers@FreeBSD.org, bapt@FreeBSD.org, bdrewery@FreeBSD.org, tuexen@FreeBSD.org, ian@FreeBSD.org, ache@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <1578901063.1.1445704636176.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #1496 - Failure MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: FAILURE Precedence: bulk X-Mailman-Approved-At: Sun, 25 Oct 2015 08:32:30 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2015 16:37:17 -0000 FreeBSD_HEAD_i386 - Build #1496 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1496/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1496/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1496/console Change summaries: 289879 by bapt: newsyslog.conf: allow to configure the signal using the signal name. Submitted by: Alexandre Perrin MFC after: 1 week Relnotes: yes Differential Revision: https://reviews.freebsd.org/D3961 289878 by bapt: timeout(1): fix the acceptable range values for parse_signal() Before both 0 and sys_nsig would be successfully returned by parse_signal() although being invalid signal numbers. PR: Alexandre Perrin MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D3990 289877 by mav: Remove ISP_INTERNAL_TARGET code. We have CTL now, which is real and much more functional then this joke. 289876 by bapt: Fix some mdoc(7) issues Obtained from: DragonflyBSD 289875 by mav: Decode few more response info codes. Though CAM still does not send any requests that would require those. 289874 by tuexen: Bump date. Missed in r289873. MFC after: 1 week X-MFC with: r289873 289873 by tuexen: Add support to systat to display SCTP statistics. MFC after: 1 week 289872 by bdrewery: Replace gcc reference with 'cc' and document the default ${CC}. MFC after: 1 week 289871 by bdrewery: Sort properly. MFC after: 1 week X-MFC-With: r289870 289870 by bdrewery: Add bsd.crunchgen.mk to bsd.README. MFC after: 1 week 289869 by bdrewery: Slightly rework the comments and logic for default Clang/GCC. This is because the previous version was very obscure about the fact that despite having Clang "on by default" for architectures such as powerpc, it does not actually build due to the GCC it uses not having C++11 support. Using an external compiler that supports C++11 does allow this to work. This whole block should be rethought more given "on by default" is not really default without extra work which could actually be surprising for why Clang is showing up when using a newer GCC. Sponsored by: EMC / Isilon Storage Division 289868 by bdrewery: Configs should not be under MK_INCLUDES control. 'buildconfig' is connected to 'all', but 'installconfig' is only called manually. There is not much need to conditionalize this file right now due to how it is hooked up and its impact on various build phases. Sponsored by: EMC / Isilon Storage Division 289867 by markj: Remove an erroneous semicolon. MFC after: 3 days 289866 by markj: DWARF emitted by clang 3.7 encodes array sizes using the DW_AT_count attribute rather than DW_AT_upper_bound. Teach ctfconvert about this so that array type sizes are encoded correctly. PR: 203772 MFC after: 1 week 289865 by ian: A few more whitespace, style, and comment cleanups. No functional changes. 289864 by ian: Bring in all the new(-ish) statistics code from armv6. 289863 by ache: Since no room left in the _flags, reuse __SALC for O_APPEND. It helps to remove _fcntl() call from _ftello() and optimize seek position calculation in _swrite(). MFC after: 3 weeks 289862 by ian: Change the preallocation of a busdma segment mapping array from per-tag to per-map. The per-tag scheme is not safe, and a mutex can't be used to protect it because the mapping routines can't sleep. Code brought in from armv6 implementation. 289861 by bdrewery: native-xtools: Replace common path with NXBDESTDIR. Also combine some mkdir calls. Sponsored by: EMC / Isilon Storage Division 289859 by bdrewery: native-xtools: Fix build with WITH_DEBUG_FILES. Sponsored by: EMC / Isilon Storage Division 289858 by ian: Instead of all memory allocations using M_DEVBUF, use new categories M_BUSDMA for allocations of metadata (tags, maps, segment tracking lists), and M_BOUNCE for bounce pages. 289857 by ian: Instead of all memory allocations using M_DEVBUF, use new categories M_BUSDMA for allocations of metadata (tags, maps, segment tracking lists), and M_BOUNCE for bounce pages. 289856 by bdrewery: Rework r289778 to always parallelize known targets, without ordering. - Rather than allow 'make clean*' to ignore dependencies, make a static list of targets in STANDALONE_SUBDIR_TARGETS that are known to be safe. This allows a user to override them if needed and avoids adding this feature to user-defined targets that are in ${SUBDIR_TARGETS}. [1] - This now also allows to force SUBDIR_PARALLEL when calling these targets, since no dependencies are needed. Reported by: ian [1] Sponsored by: EMC / Isilon Storage Division MFC after: 3 weeks X-MFC-With: r289778 289855 by mav: Minor additions to Status Type 0 IOCB. 289854 by ian: Catch up to r232356: change the boundary constraint type to bus_addr_t. This code lived in the projects/armv6 branch when that change got applied to all the other arches. 289853 by emaste: Add aarch64 files to the hwpmc(4) module build This was probably missed because FreeBSD/arm64 did not yet support modules when aarch64 support was added to hwpmc(4). Submitted by: andrew 289852 by mav: Missed addition for r289812. 289851 by ian: Whitespace and style nits, no functional changes. The goal is to make these two files cosmetically alike so that the actual implementation differences are visible. The only changes which aren't spaces<->tabs and rewrapping and reindenting lines are a couple fields shuffled around in the tag and map structs so that everything is in the same order in both versions (which should amount to no functional change). 289846 by bdrewery: Fix regression from r289734 that caused crunchgen "subdirs" to not be properly recursed. The .for loop was defining a ${__dir} variable that was being set at a different evaluation time than the target itself, so every 'cd ${__dir}' became the last value that was in ${__dir}. This resulted in 'make obj' not properly being ran in the tree that would leave .depend files scattered around when 'make all' was ran in rescue/. To fix this, define a CRUNCH_SRCDIR_* for every prog if it does not already have one and then use that variable in every relevant place. This allows simplifying some logic as well. Reported by: emaste X-MFC-With: r289734 MFC after: 3 weeks Sponsored by: EMC / Isilon Storage Division 289845 by asomers: Fix various Coverity issues in sbin/savecore/savecore.c: CID1009429: Fix unchecked return value from lseek while clearing dump CID1007781: Fix file descriptor leak in DoFile CID1007261: Don't send potentially unterminated string to syslog(3) Coverity CID: 1009429 Coverity CID: 1007781 Coverity CID: 1007261 MFC after: 2 weeks Sponsored by: Spectra Logic Differential Revision: https://reviews.freebsd.org/D3991 The end of the build log: [...truncated 197578 lines...] ctfconvert -L VERSION -g sym_hipd.o --- tws_hdm.o --- ctfconvert -L VERSION -g tws_hdm.o --- tws_services.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/tws/tws_services.c --- tws_user.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/tws/tws_user.c --- if_txp.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/txp/if_txp.c --- tws_cam.o --- ctfconvert -L VERSION -g tws_cam.o --- uart_bus_pci.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/uart/uart_bus_pci.c --- tws_user.o --- ctfconvert -L VERSION -g tws_user.o --- tws_services.o --- ctfconvert -L VERSION -g tws_services.o --- vt_vga.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/vt/hw/vga/vt_vga.c --- if_vx_pci.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/vx/if_vx_pci.c --- uart_bus_pci.o --- ctfconvert -L VERSION -g uart_bus_pci.o --- if_wi_pci.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/wi/if_wi_pci.c --- if_vx_pci.o --- ctfconvert -L VERSION -g if_vx_pci.o --- if_wpi.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/wpi/if_wpi.c --- if_wi_pci.o --- ctfconvert -L VERSION -g if_wi_pci.o --- xenpci.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/xen/xenpci/xenpci.c ctfconvert -L VERSION -g xenpci.o --- vt_vga.o --- ctfconvert -L VERSION -g vt_vga.o --- arcmsr.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/arcmsr/arcmsr.c --- bxe.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/bxe/bxe.c --- if_txp.o --- ctfconvert -L VERSION -g if_txp.o --- bxe_stats.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/bxe/bxe_stats.c --- if_wpi.o --- ctfconvert -L VERSION -g if_wpi.o --- bxe_debug.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/bxe/bxe_debug.c --- arcmsr.o --- ctfconvert -L VERSION -g arcmsr.o --- ecore_sp.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/bxe/ecore_sp.c --- bxe_stats.o --- ctfconvert -L VERSION -g bxe_stats.o --- bxe_elink.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/bxe/bxe_elink.c --- bxe_debug.o --- ctfconvert -L VERSION -g bxe_debug.o --- 57710_init_values.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/bxe/57710_init_values.c ctfconvert -L VERSION -g 57710_init_values.o --- 57711_init_values.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/bxe/57711_init_values.c --- ecore_sp.o --- ctfconvert -L VERSION -g ecore_sp.o --- 57712_init_values.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/bxe/57712_init_values.c --- 57711_init_values.o --- ctfconvert -L VERSION -g 57711_init_values.o --- vesa.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/fb/vesa.c ctfconvert -L VERSION -g vesa.o --- hpt27xx_os_bsd.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/hpt27xx/hpt27xx_os_bsd.c ctfconvert -L VERSION -g hpt27xx_os_bsd.o --- hpt27xx_osm_bsd.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/hpt27xx/hpt27xx_osm_bsd.c --- 57712_init_values.o --- ctfconvert -L VERSION -g 57712_init_values.o --- hpt27xx_config.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/hpt27xx/hpt27xx_config.c ctfconvert -L VERSION -g hpt27xx_config.o --- entry.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/hptmv/entry.c --- hpt27xx_osm_bsd.o --- ctfconvert -L VERSION -g hpt27xx_osm_bsd.o --- hptnr_os_bsd.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/hptnr/hptnr_os_bsd.c ctfconvert -L VERSION -g hptnr_os_bsd.o --- hptnr_osm_bsd.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/hptnr/hptnr_osm_bsd.c --- bxe_elink.o --- ctfconvert -L VERSION -g bxe_elink.o --- hptnr_config.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/hptnr/hptnr_config.c ctfconvert -L VERSION -g hptnr_config.o --- hptrr_os_bsd.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/hptrr/hptrr_os_bsd.c --- entry.o --- ctfconvert -L VERSION -g entry.o --- hptrr_osm_bsd.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/hptrr/hptrr_osm_bsd.c --- hptrr_os_bsd.o --- ctfconvert -L VERSION -g hptrr_os_bsd.o --- hptrr_config.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/hptrr/hptrr_config.c --- hptnr_osm_bsd.o --- ctfconvert -L VERSION -g hptnr_osm_bsd.o --- hv_ata_pci_disengage.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/hyperv/stordisengage/hv_ata_pci_disengage.c --- hptrr_config.o --- ctfconvert -L VERSION -g hptrr_config.o --- nvme.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/nvme/nvme.c --- hv_ata_pci_disengage.o --- ctfconvert -L VERSION -g hv_ata_pci_disengage.o --- nvme_ctrlr.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/nvme/nvme_ctrlr.c --- hptrr_osm_bsd.o --- ctfconvert -L VERSION -g hptrr_osm_bsd.o --- nvme_ns.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/nvme/nvme_ns.c --- nvme.o --- ctfconvert -L VERSION -g nvme.o --- nvme_qpair.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/nvme/nvme_qpair.c --- nvme_ns.o --- ctfconvert -L VERSION -g nvme_ns.o --- nvme_ctrlr.o --- ctfconvert -L VERSION -g nvme_ctrlr.o --- if_vmx.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/vmware/vmxnet3/if_vmx.c --- isci.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/isci/isci.c --- nvme_qpair.o --- ctfconvert -L VERSION -g nvme_qpair.o --- isci_interrupt.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/isci/isci_interrupt.c ctfconvert -L VERSION -g isci_interrupt.o --- isci.o --- ctfconvert -L VERSION -g isci.o --- mp_clock.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/i386/i386/mp_clock.c --- pci_cfgreg.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/i386/pci/pci_cfgreg.c --- mp_clock.o --- ctfconvert -L VERSION -g mp_clock.o --- pci_pir.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/i386/pci/pci_pir.c --- pci_cfgreg.o --- ctfconvert -L VERSION -g pci_cfgreg.o --- x86bios.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/compat/x86bios/x86bios.c --- bxe.o --- ctfconvert -L VERSION -g bxe.o --- pci_pir.o --- ctfconvert -L VERSION -g pci_pir.o --- io_apic.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/x86/x86/io_apic.c --- x86bios.o --- ctfconvert -L VERSION -g x86bios.o --- mptable.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/x86/x86/mptable.c --- msi.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/x86/x86/msi.c ctfconvert -L VERSION -g msi.o --- hvm.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/x86/xen/hvm.c --- io_apic.o --- ctfconvert -L VERSION -g io_apic.o --- xen_intr.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/x86/xen/xen_intr.c --- mptable.o --- ctfconvert -L VERSION -g mptable.o --- xen_msi.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/x86/xen/xen_msi.c --- xen_intr.o --- /usr/src/sys/x86/xen/xen_intr.c:75:44: error: expected ';' after struct BITSET_DEFINE(enabledbits, ENABLED_SETSIZE) ^ ; 1 error generated. *** [xen_intr.o] Error code 1 make[2]: stopped in /usr/obj/usr/src/sys/GENERIC --- xen_msi.o --- ctfconvert -L VERSION -g xen_msi.o --- hvm.o --- ctfconvert -L VERSION -g hvm.o --- if_vmx.o --- ctfconvert -L VERSION -g if_vmx.o 1 error make[2]: stopped in /usr/obj/usr/src/sys/GENERIC *** [buildkernel] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildkernel] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src Build step 'Execute shell' marked build as failure [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_i386] $ /bin/sh -xe /tmp/hudson8204140269967827177.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_i386' + echo 'clean up jail FreeBSD_HEAD_i386' clean up jail FreeBSD_HEAD_i386 + sudo jail -r FreeBSD_HEAD_i386 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::106:1 -alias + sudo umount FreeBSD_HEAD_i386/usr/src + sudo umount FreeBSD_HEAD_i386/dev + sudo rm -fr FreeBSD_HEAD_i386 rm: FreeBSD_HEAD_i386/lib/libcrypt.so.5: Operation not permitted rm: FreeBSD_HEAD_i386/lib/libthr.so.3: Operation not permitted rm: FreeBSD_HEAD_i386/lib/libc.so.7: Operation not permitted rm: FreeBSD_HEAD_i386/lib: Directory not empty rm: FreeBSD_HEAD_i386/sbin/init: Operation not permitted rm: FreeBSD_HEAD_i386/sbin: Directory not empty rm: FreeBSD_HEAD_i386/usr/lib/librt.so.1: Operation not permitted rm: FreeBSD_HEAD_i386/usr/lib: Directory not empty rm: FreeBSD_HEAD_i386/usr/bin/chsh: Operation not permitted rm: FreeBSD_HEAD_i386/usr/bin/opieinfo: Operation not permitted rm: FreeBSD_HEAD_i386/usr/bin/yppasswd: Operation not permitted rm: FreeBSD_HEAD_i386/usr/bin/chfn: Operation not permitted rm: FreeBSD_HEAD_i386/usr/bin/login: Operation not permitted rm: FreeBSD_HEAD_i386/usr/bin/chpass: Operation not permitted rm: FreeBSD_HEAD_i386/usr/bin/passwd: Operation not permitted rm: FreeBSD_HEAD_i386/usr/bin/opiepasswd: Operation not permitted rm: FreeBSD_HEAD_i386/usr/bin/ypchpass: Operation not permitted rm: FreeBSD_HEAD_i386/usr/bin/ypchsh: Operation not permitted rm: FreeBSD_HEAD_i386/usr/bin/ypchfn: Operation not permitted rm: FreeBSD_HEAD_i386/usr/bin/su: Operation not permitted rm: FreeBSD_HEAD_i386/usr/bin/crontab: Operation not permitted rm: FreeBSD_HEAD_i386/usr/bin: Directory not empty rm: FreeBSD_HEAD_i386/usr: Directory not empty rm: FreeBSD_HEAD_i386/libexec/ld-elf.so.1: Operation not permitted rm: FreeBSD_HEAD_i386/libexec: Directory not empty rm: FreeBSD_HEAD_i386: Directory not empty + true + sudo chflags -R noschg FreeBSD_HEAD_i386 + sudo rm -fr FreeBSD_HEAD_i386 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-current@freebsd.org Sat Oct 24 22:49:21 2015 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 834DEA1E23A for ; Sat, 24 Oct 2015 22:49:21 +0000 (UTC) (envelope-from gabdelmalik@mail.uniridge.com.au) Received: from mail.uniridge.com.au (ec2-54-206-17-100.ap-southeast-2.compute.amazonaws.com [54.206.17.100]) by mx1.freebsd.org (Postfix) with ESMTP id 3C587F80; Sat, 24 Oct 2015 22:49:20 +0000 (UTC) (envelope-from gabdelmalik@mail.uniridge.com.au) Received: by mail.uniridge.com.au (Postfix, from userid 1007) id DB1504A6F; Sun, 25 Oct 2015 09:49:13 +1100 (EST) Date: Sun, 25 Oct 2015 09:49:13 +1100 From: George Abdelmalik To: Ian Lepore Cc: freebsd-current@freebsd.org Subject: Re: dtc(1): reproducible segmentation fault Message-ID: <20151024224913.GA5266@barney.uniridge.com.au> References: <562A3FE5.8020809@uniridge.com.au> <1445618437.91534.13.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1445618437.91534.13.camel@freebsd.org> User-Agent: Mutt/1.5.22 (2013-10-16) X-Mailman-Approved-At: Sun, 25 Oct 2015 08:33:16 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 24 Oct 2015 22:49:21 -0000 On Fri, Oct 23, 2015 at 10:40:37AM -0600, Ian Lepore wrote: > > Don't cc me. I looked at the in-tree dtc code once and decided it's > too flawed to try to maintain, and it supports only a subset of the > full dts syntax. That's why we switched back to using the gnu dtc for > buildkernel. But I just discovered that for some reason gnu is not the > copy of dtc that gets installed, it's just the one that gets used > during a buildkernel. > > So basically if you do 'dtc -v' and the result is 0.4.0, that's too > limited to compile modern dts files, and if the result is 1.4.0 that's > the gnu dtc that should work fine, and if it doesn't we probably need > to report the problem upstream. > > -- Ian > Thanks Ian, The GPL dtc worked fine. I was actually wanting to compiler the in-tree zedbaord.dts file. I'd successfully done it some time back in June but must have been using the GPL dtc without realising it. George. From owner-freebsd-current@freebsd.org Sat Oct 24 23:07:52 2015 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 810A1A1E4CB for ; Sat, 24 Oct 2015 23:07:52 +0000 (UTC) (envelope-from gabdelmalik@mail.uniridge.com.au) Received: from mail.uniridge.com.au (ec2-54-206-17-100.ap-southeast-2.compute.amazonaws.com [54.206.17.100]) by mx1.freebsd.org (Postfix) with ESMTP id E9B941586; Sat, 24 Oct 2015 23:07:51 +0000 (UTC) (envelope-from gabdelmalik@mail.uniridge.com.au) Received: by mail.uniridge.com.au (Postfix, from userid 1007) id 7E4004A6F; Sun, 25 Oct 2015 10:07:50 +1100 (EST) Date: Sun, 25 Oct 2015 10:07:50 +1100 From: George Abdelmalik To: David Chisnall Cc: Ian Lepore , freebsd-current@freebsd.org Subject: Re: dtc(1): reproducible segmentation fault Message-ID: <20151024230750.GB5266@barney.uniridge.com.au> References: <562A3FE5.8020809@uniridge.com.au> <1445618437.91534.13.camel@freebsd.org> <2D772151-85F9-4D80-8074-58CD11FFF778@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) X-Mailman-Approved-At: Sun, 25 Oct 2015 08:33:42 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 24 Oct 2015 23:07:52 -0000 On Sat, Oct 24, 2015 at 02:11:36PM +0100, David Chisnall wrote: > On 24 Oct 2015, at 11:07, David Chisnall wrote: > > > > On 23 Oct 2015, at 17:40, Ian Lepore wrote: > >> > >> Don't cc me. I looked at the in-tree dtc code once and decided it's > >> too flawed to try to maintain, and it supports only a subset of the > >> full dts syntax. That's why we switched back to using the gnu dtc for > >> buildkernel. But I just discovered that for some reason gnu is not the > >> copy of dtc that gets installed, it's just the one that gets used > >> during a buildkernel. > > > > Please assign the bug to me. > > Actually, it looks as if this is one of the (many) bugs in dtc that I fixed in a bunch of changes that I made (and didn?t get around to committing) last Christmas (https://github.com/davidchisnall/dtc). Patrick Wildt tested the version that I was working on with a load of things from the GPL dtc test suite and they all passed. I?m now running a make universe with the new version, and I?ll commit if there are no problems. > > David > Hi David, You've beaten me to it with the fix before I could lodge the bug report :) In your repo I've seen that the mmap(2) call now takes the MAP_PRIVATE flag. I applied that change locally to my source tree and that has fixed the problem. I've since re-read the mmap(2) man page to find out how that change could be influential... [EINVAL] None of MAP_ANON, MAP_PRIVATE, MAP_SHARED, or MAP_STACK was specified. At least one of these flags must be included. Although obvious to me now, I missed it on my previous reads. Thanks for your assistance. I look forward to your coming set of changes. In my view DTC is an important tool and I would be willing contribute effort to making it feature parity with the GPL version if that is lacking. Keep up the valuable work, George. From owner-freebsd-current@freebsd.org Sun Oct 25 15:00:43 2015 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 B4C878E97 for ; Sun, 25 Oct 2015 15:00:43 +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 8596415B1; Sun, 25 Oct 2015 15:00:42 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.0.7] (cpc16-cmbg15-2-0-cust60.5-4.cable.virginm.net [86.5.162.61]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id t9PF0Usi036123 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Oct 2015 15:00:34 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host cpc16-cmbg15-2-0-cust60.5-4.cable.virginm.net [86.5.162.61] 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: dtc(1): reproducible segmentation fault From: David Chisnall In-Reply-To: <20151024230750.GB5266@barney.uniridge.com.au> Date: Sun, 25 Oct 2015 15:00:25 +0000 Cc: Ian Lepore , freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <562A3FE5.8020809@uniridge.com.au> <1445618437.91534.13.camel@freebsd.org> <2D772151-85F9-4D80-8074-58CD11FFF778@FreeBSD.org> <20151024230750.GB5266@barney.uniridge.com.au> To: George Abdelmalik X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 25 Oct 2015 15:00:43 -0000 On 25 Oct 2015, at 00:07, George Abdelmalik = wrote: >=20 > You've beaten me to it with the fix before I could lodge the bug = report :) >=20 > In your repo I've seen that the mmap(2) call now takes the MAP_PRIVATE = flag. I > applied that change locally to my source tree and that has fixed the = problem. > I've since re-read the mmap(2) man page to find out how that change = could > be influential... >=20 > [EINVAL] None of MAP_ANON, MAP_PRIVATE, MAP_SHARED, or > MAP_STACK was specified. At least one of these = flags > must be included. >=20 > Although obvious to me now, I missed it on my previous reads. >=20 > Thanks for your assistance. I look forward to your coming set of = changes. In > my view DTC is an important tool and I would be willing contribute = effort to > making it feature parity with the GPL version if that is lacking. It=E2=80=99s now committed (r289935). Sorry for the delay - I meant to = commit the changes in January and it slipped down my to-do list. Please do test with any dts files that you have. If you find bugs, then = please report them and assign them to me. David From owner-freebsd-current@freebsd.org Sun Oct 25 19:20:31 2015 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 DB1D08C8C for ; Sun, 25 Oct 2015 19:20:31 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9B79A1E9B for ; Sun, 25 Oct 2015 19:20:31 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:3c23:bcdc:5292:fa5f]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 8AC772C99 for ; Sun, 25 Oct 2015 22:20:27 +0300 (MSK) Date: Sun, 25 Oct 2015 22:20:25 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <16610120144.20151025222025@serebryakov.spb.ru> To: freebsd-current Subject: What changed in rc.d infrastructure in last months? 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.20 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, 25 Oct 2015 19:20:32 -0000 Hello freebsd-current, New version of -CURRENT try to configure wlan0 and run hostapd twice: Created wlan(4) interfaces: wlan0. Created clone interfaces: gif0. em0: link state changed to UP em0: link state changed to DOWN ifconfig: NONE: bad value vlan0: changing name to 'skynet' vlan1: changing name to 'eltel' Starting hostapd. Configuration file: /etc/hostapd-wlan0.conf Using interface wlan0 with hwaddr 00:15:6d:85:5f:fc and ssid "home.serebryakov.spb.ru" wlan0: interface state UNINITIALIZED->ENABLED wlan0: AP-ENABLED gif0: link state changed to UP Starting Network: lo0 em0 em1 wlan0 gif0. .... Starting devd. ifconfig: SIOCS80211: Device busy hostapd already running? (pid=455). em1: link state changed to UP eltel: link state changed to UP skynet: link state changed to UP Starting Network: wlan0. Before this there was no second try to run hostapd. What should I change in /etc/rc.d to eliminate this double-run and double-configuration? Now I have: wlans_ath0="wlan0" create_args_wlan0="wlanmode hostap bssid" ifconfig_wlan0="HOSTAP inet 192.168.135.1 netmask 255.255.255.0 mode 11ng channel 3:ht/40 -bgscan ssid home.serebryakov.spb.ru country DE regdomain row txpower 30" I DON'T have "hostapd_enable"! -- Best regards, Lev mailto:lev@FreeBSD.org From owner-freebsd-current@freebsd.org Sun Oct 25 19:24:15 2015 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 C5B0E8EBD for ; Sun, 25 Oct 2015 19:24:15 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (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 9D185136C; Sun, 25 Oct 2015 19:24:15 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igbhv6 with SMTP id hv6so44212131igb.0; Sun, 25 Oct 2015 12:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OTZppCOLGJf+67pK7DjM4wLR50n4c0AV6Mfiv2mQQk4=; b=i2mNWVHl6K7ZbUdfeOYvAQVzAPxWYuRqPyf4GPlEElTNrbjgF6iZ4RQxhiMisCV9KC j0OqLyWupUTnsEGa+MipCAbelJbgvlLcveqD4i5KW4GYlmaKkaaB6v3AbRFOfy4nUTRM VPHBifS+8aYqaN4e/lz2f6rKQRPK5prx14sjH5j07vs+lYAumcyXTYJ5QGp7NiPOy67e mJkWJ3zZJsWyiqcJ6aqkqM5yHK76Q4VYJKQx20tSJu93plekHG1KM4MfKjFr93cFt7gs JEjpCZoP4cb0Y9kenIhuIhcCqdW8dUqhevLMPLQBdJAFR0GOyaxVkklKALrwQ1PCnm7n l/mQ== MIME-Version: 1.0 X-Received: by 10.50.155.41 with SMTP id vt9mr6501532igb.22.1445801054827; Sun, 25 Oct 2015 12:24:14 -0700 (PDT) Received: by 10.36.46.66 with HTTP; Sun, 25 Oct 2015 12:24:14 -0700 (PDT) In-Reply-To: <16610120144.20151025222025@serebryakov.spb.ru> References: <16610120144.20151025222025@serebryakov.spb.ru> Date: Sun, 25 Oct 2015 12:24:14 -0700 Message-ID: Subject: Re: What changed in rc.d infrastructure in last months? From: Adrian Chadd To: Lev Serebryakov Cc: freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 25 Oct 2015 19:24:15 -0000 Hm, poke glebius? He went and rototilled bits of net80211 recently and that did touch the rc scripts. -a On 25 October 2015 at 12:20, Lev Serebryakov wrote: > Hello freebsd-current, > > > New version of -CURRENT try to configure wlan0 and run hostapd twice: > > Created wlan(4) interfaces: wlan0. > Created clone interfaces: gif0. > em0: link state changed to UP > em0: link state changed to DOWN > ifconfig: NONE: bad value > vlan0: changing name to 'skynet' > vlan1: changing name to 'eltel' > Starting hostapd. > Configuration file: /etc/hostapd-wlan0.conf > Using interface wlan0 with hwaddr 00:15:6d:85:5f:fc and ssid "home.serebryakov.spb.ru" > wlan0: interface state UNINITIALIZED->ENABLED > wlan0: AP-ENABLED > gif0: link state changed to UP > Starting Network: lo0 em0 em1 wlan0 gif0. > .... > Starting devd. > ifconfig: SIOCS80211: Device busy > hostapd already running? (pid=455). > em1: link state changed to UP > eltel: link state changed to UP > skynet: link state changed to UP > Starting Network: wlan0. > > Before this there was no second try to run hostapd. What should I change in > /etc/rc.d to eliminate this double-run and double-configuration? Now I > have: > > wlans_ath0="wlan0" > create_args_wlan0="wlanmode hostap bssid" > ifconfig_wlan0="HOSTAP inet 192.168.135.1 netmask 255.255.255.0 mode 11ng channel 3:ht/40 -bgscan ssid home.serebryakov.spb.ru country DE regdomain row txpower 30" > > I DON'T have "hostapd_enable"! > > -- > Best regards, > Lev mailto:lev@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 Sun Oct 25 19:30:49 2015 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 858848F7F for ; Sun, 25 Oct 2015 19:30:49 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::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 57E1E155A; Sun, 25 Oct 2015 19:30:49 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by pacfv9 with SMTP id fv9so173058268pac.3; Sun, 25 Oct 2015 12:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yq/gShUabmbP+F++zGSdcgrOu7OUDi4kf573Exlfqzk=; b=LtH8+B2Nh8dFkjgcCJ2vhGUN7UF1qIWqG+/IQKvHw2pE5xnBjB/J/60IoJYkweDduA 8QBd1NTvkbZUe4qQiqMGFLFNb3X0zhXIvuBM93717YWsCBS7nas5ZIQ9SPRxqJZUwM4J enMSqFya1v4liY698rIfc3LfWvFG3gIzDuLUKV6O+2CM9J/VwSBnJPBr+QBeqsub0wMH KFe7wrIic6/6BdQahfqKnFYvnxbpM6fFu6xvpNSObCmdY7p6cloXQKbkMilT//KsF2a1 EiXlbN0Jsb9nsvwqhNHTaXW0azeVhpgVlh/nzUzzJNvJiFkWGhLEM/zCuP8+oj2Sm/GO l+KA== X-Received: by 10.68.216.6 with SMTP id om6mr18118519pbc.29.1445801448871; Sun, 25 Oct 2015 12:30:48 -0700 (PDT) Received: from [192.168.20.7] (c-24-16-212-205.hsd1.wa.comcast.net. [24.16.212.205]) by smtp.gmail.com with ESMTPSA id xz5sm29809760pbb.12.2015.10.25.12.30.48 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 25 Oct 2015 12:30:48 -0700 (PDT) Subject: Re: What changed in rc.d infrastructure in last months? Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=utf-8 From: NGie Cooper X-Priority: 3 (Normal) In-Reply-To: <16610120144.20151025222025@serebryakov.spb.ru> Date: Sun, 25 Oct 2015 12:30:47 -0700 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: References: <16610120144.20151025222025@serebryakov.spb.ru> To: lev@FreeBSD.org X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 25 Oct 2015 19:30:49 -0000 > On Oct 25, 2015, at 12:20, Lev Serebryakov wrote: >=20 > Hello freebsd-current, >=20 >=20 > New version of -CURRENT try to configure wlan0 and run hostapd twice: >=20 > Created wlan(4) interfaces: wlan0. > Created clone interfaces: gif0. > em0: link state changed to UP > em0: link state changed to DOWN > ifconfig: NONE: bad value > vlan0: changing name to 'skynet' > vlan1: changing name to 'eltel' > Starting hostapd. > Configuration file: /etc/hostapd-wlan0.conf > Using interface wlan0 with hwaddr 00:15:6d:85:5f:fc and ssid = "home.serebryakov.spb.ru" > wlan0: interface state UNINITIALIZED->ENABLED > wlan0: AP-ENABLED > gif0: link state changed to UP > Starting Network: lo0 em0 em1 wlan0 gif0. > .... > Starting devd. > ifconfig: SIOCS80211: Device busy > hostapd already running? (pid=3D455). > em1: link state changed to UP > eltel: link state changed to UP > skynet: link state changed to UP > Starting Network: wlan0. >=20 > Before this there was no second try to run hostapd. What should I = change in > /etc/rc.d to eliminate this double-run and double-configuration? Now I > have: >=20 > wlans_ath0=3D"wlan0" > create_args_wlan0=3D"wlanmode hostap bssid" > ifconfig_wlan0=3D"HOSTAP inet 192.168.135.1 netmask 255.255.255.0 mode = 11ng channel 3:ht/40 -bgscan ssid home.serebryakov.spb.ru country DE = regdomain row txpower 30" >=20 > I DON'T have "hostapd_enable=E2=80=9D! etc/rc.d/hostapd is written a bit weird for an rc.d script. It doesn=E2=80= =99t check =E2=80=9Chostapd_enable=E2=80=9D in the case where it=E2=80=99s= explicitly provided an interface: 15 ifn=3D"$2" 16 if [ -z "$ifn" ]; then 17 rcvar=3D"hostapd_enable" 18 conf_file=3D"/etc/${name}.conf" 19 pidfile=3D"/var/run/${name}.pid" 20 else 21 rcvar=3D 22 conf_file=3D"/etc/${name}-${ifn}.conf" 23 pidfile=3D"/var/run/${name}-${ifn}.pid" 24 fi This scenario is trigged by network.subr: 221 if wpaif $1; then 222 /etc/rc.d/wpa_supplicant start $1 223 _cfg=3D0 # XXX: not sure this should count 224 elif hostapif $1; then 225 /etc/rc.d/hostapd start $1 226 _cfg=3D0 227 fi =E2=80=A6 251 if wpaif $1; then 252 /etc/rc.d/wpa_supplicant stop $1 253 _cfg=3D0 254 elif hostapif $1; then 255 /etc/rc.d/hostapd stop $1 256 _cfg=3D0 257 fi What determines whether or not it=E2=80=99s a hostapif? Whether or not = `hostap` is in ifconfig_. 445 # hostapif if 446 # Returns 0 if the interface is a HOSTAP interface and 1 = otherwise. 447 hostapif() 448 { 449 local _tmpargs _arg 450 _tmpargs=3D`_ifconfig_getargs $1` 451=20 452 for _arg in $_tmpargs; do 453 case $_arg in 454 [Hh][Oo][Ss][Tt][Aa][Pp]) 455 return 0 456 ;; 457 esac 458 done 459=20 460 return 1 461 } This [the hostapd start/stop logic] all gets triggered whenever the = interface goes up and down. glebius broke etc/rc.d/{devd,ldconfig} back in April by reordering the = dependencies, which can affect this. See = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D202726 for more = details. Cheers! -NGie= From owner-freebsd-current@freebsd.org Sun Oct 25 19:39:32 2015 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 7BA9B8173 for ; Sun, 25 Oct 2015 19:39:32 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 410B21B19 for ; Sun, 25 Oct 2015 19:39:32 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:3c23:bcdc:5292:fa5f]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 5DE4A2CA4; Sun, 25 Oct 2015 22:39:30 +0300 (MSK) Date: Sun, 25 Oct 2015 22:39:28 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <221574465.20151025223928@serebryakov.spb.ru> To: NGie Cooper CC: freebsd-current Subject: Re: What changed in rc.d infrastructure in last months? In-Reply-To: References: <16610120144.20151025222025@serebryakov.spb.ru> 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.20 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, 25 Oct 2015 19:39:32 -0000 Hello NGie, Sunday, October 25, 2015, 10:30:47 PM, you wrote: > This [the hostapd start/stop logic] all gets triggered whenever the interface goes up and down. So, first time hostapd is started by /etc/rc.d/netif before devd, and second time devd call /etc/rc.d/netif again on interface up, am I right? It looks weird. > glebius broke etc/rc.d/{devd,ldconfig} back in April by reordering the > dependencies, which can affect this. See > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202726 for more details. -- Best regards, Lev mailto:lev@FreeBSD.org From owner-freebsd-current@freebsd.org Sun Oct 25 19:39:53 2015 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 44ADE81AE for ; Sun, 25 Oct 2015 19:39:53 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (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 16C4C1C4A; Sun, 25 Oct 2015 19:39:53 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by pabuq3 with SMTP id uq3so662339pab.0; Sun, 25 Oct 2015 12:39:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=f1igTjV7JMRm+lw7DdhNKnhjytHqNSDl9MoPp8W3dYE=; b=Ef3bGJhbNzgQ/hK0wrTH18gPxjvGP0Ffi0l5nyKMv0cWuPBCVd2sF5WUVzrfk9un4t btxN/o3kukYkWQoQnrnkBnDJXctRV6O0ybskjl1kCFVXu5GZUhnFkUkBz1R0rTJSvtp7 x+JZbcvVfun6CU47dvd02wOGR4FSgsq5X4Z5ySqf9SRcypwoDhWikZ1p4UFzwfnKpNqe MVVdr5O3WKxDsYq33MYmI4P31LJVNc1KELk2YbaUTn3YZFRgYX2kkEOkELUhrbsKjcWj 00bjxow5/C7sFFyl4rD8917bIKdcdaevxLTizoMHl3dcuMRrDGA3aLYEPVbo7uW5PodH 4C/Q== X-Received: by 10.68.125.225 with SMTP id mt1mr17736474pbb.168.1445801992693; Sun, 25 Oct 2015 12:39:52 -0700 (PDT) Received: from [192.168.20.7] (c-24-16-212-205.hsd1.wa.comcast.net. [24.16.212.205]) by smtp.gmail.com with ESMTPSA id bo5sm29802688pbb.76.2015.10.25.12.39.52 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 25 Oct 2015 12:39:52 -0700 (PDT) Subject: Re: What changed in rc.d infrastructure in last months? Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=utf-8 From: NGie Cooper X-Priority: 3 (Normal) In-Reply-To: Date: Sun, 25 Oct 2015 12:39:51 -0700 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <28FF29D6-A2D9-46C0-A419-DB433BB9F54A@gmail.com> References: <16610120144.20151025222025@serebryakov.spb.ru> To: lev@FreeBSD.org X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 25 Oct 2015 19:39:53 -0000 > On Oct 25, 2015, at 12:30, NGie Cooper wrote: =E2=80=A6 > 445 # hostapif if > 446 # Returns 0 if the interface is a HOSTAP interface and 1 = otherwise. > 447 hostapif() > 448 { > 449 local _tmpargs _arg > 450 _tmpargs=3D`_ifconfig_getargs $1` > 451=20 > 452 for _arg in $_tmpargs; do > 453 case $_arg in > 454 [Hh][Oo][Ss][Tt][Aa][Pp]) > 455 return 0 > 456 ;; > 457 esac > 458 done > 459=20 > 460 return 1 > 461 } Here=E2=80=99s an example of how this works, by the way: $ sh find_hostapifs.sh wlan1 is! $ cat find_hostapifs.sh . /etc/rc.subr load_rc_config . /etc/network.subr for i in em0 wlan0 wlan1; do hostapif $i && echo "$i is!=E2=80=9D done $ grep ^ifconfig /etc/rc.conf ifconfig_em0=3D"inet W.X.Y.Z netmask 255.255.255.0" ifconfig_em0_ipv6=3D"inet6 accept_rtadv" ifconfig_wlan0=3D"inet 127.0.0.2/8" ifconfig_wlan1=3D=E2=80=9Chostap=E2=80=9D $ It=E2=80=99s documented here: On the other hand, if you want to configure your = wireless interface with hostapd(8), you need to add ``HOSTAP'' = to the ifconfig_ variable. hostapd(8) will use the settings from /etc/hostapd-.conf Cheers, -NGie= From owner-freebsd-current@freebsd.org Sun Oct 25 19:44:10 2015 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 6C0CE83A3 for ; Sun, 25 Oct 2015 19:44:10 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 00E4C10CB; Sun, 25 Oct 2015 19:44:10 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:3c23:bcdc:5292:fa5f]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 8A3642CAB; Sun, 25 Oct 2015 22:44:08 +0300 (MSK) Date: Sun, 25 Oct 2015 22:44:06 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1496792606.20151025224406@serebryakov.spb.ru> To: freebsd-current CC: jhb@FreeBSD.org, kib@FreeBSD.org Subject: r286256 (changes in both schedulers) leads to almost-instant reboot on my system. 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.20 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, 25 Oct 2015 19:44:10 -0000 Hello freebsd-current, I've tracked down my reboot on r289874 to r286256. My system crashes after several seconds of running with several post-286256 revisions (r289874 is tested most by me). But if I revert r286256 (and only this one), r289874 works solid-stable with both ULE and 4BSD. It is amd64 system. Typical panic logs look like this: ====================================================================== gif0: link state changed to UP kernel trap 9 with interrupts disabled Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xffffffff8046e3c6 stack pointer = 0x28:0xfffffe011bd59890 frame pointer = 0x28:0xfffffe011bd59980 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 11 (swi4: clock (0)) trap number = 9 panic: general protection fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe011bd59530 vpanic() at vpanic+0x182/frame 0xfffffe011bd595b0 panic() at panic+0x43/frame 0xfffffe011bd59610 trap_fatal() at trap_fatal+0x351/frame 0xfffffe011bd59670 trap() at trap+0x6d8/frame 0xfffffe011bd597d0 calltrap() at calltrap+0x8/frame 0xfffffe011bd597d0 --- trap 0x9, rip = 0xffffffff8046e3c6, rsp = 0xfffffe011bd598a0, rbp = 0xfffffe011bd59980 --- sched_add() at sched_add+0x116/frame 0xfffffe011bd59980 intr_event_schedule_thread() at intr_event_schedule_thread+0xae/frame 0xfffffe011bd599b0 intr_event_handle() at intr_event_handle+0xe2/frame 0xfffffe011bd59a00 intr_execute_handlers() at intr_execute_handlers+0x48/frame 0xfffffe011bd59a30 lapic_handle_intr() at lapic_handle_intr+0x3f/frame 0xfffffe011bd59a50 Xapic_isr1() at Xapic_isr1+0xb7/frame 0xfffffe011bd59a50 --- interrupt, rip = 0xffffffff8063e1f2, rsp = 0xfffffe011bd59b20, rbp = 0xfffffe011bd59b20 --- spinlock_exit() at spinlock_exit+0x32/frame 0xfffffe011bd59b20 intr_event_execute_handlers() at intr_event_execute_handlers+0xae/frame 0xfffffe011bd59b60 ithread_loop() at ithread_loop+0xa6/frame 0xfffffe011bd59bb0 fork_exit() at fork_exit+0x75/frame 0xfffffe011bd59bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe011bd59bf0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- Uptime: 16s ====================================================================== wlan0: AP-ENABLED kernel trap 9 with interrupts disabled Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xffffffff805190b6 stack pointer = 0x28:0xfffffe012260e7d0 frame pointer = 0x28:0xfffffe012260e8c0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 16 (syncer) trap number = 9 panic: general protection fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe012260e470 vpanic() at vpanic+0x182/frame 0xfffffe012260e4f0 panic() at panic+0x43/frame 0xfffffe012260e550 trap_fatal() at trap_fatal+0x351/frame 0xfffffe012260e5b0 trap() at trap+0x6d8/frame 0xfffffe012260e710 calltrap() at calltrap+0x8/frame 0xfffffe012260e710 --- trap 0x9, rip = 0xffffffff805190b6, rsp = 0xfffffe012260e7e0, rbp = 0xfffffe012260e8c0 --- sched_add() at sched_add+0x116/frame 0xfffffe012260e8c0 intr_event_schedule_thread() at intr_event_schedule_thread+0xae/frame 0xfffffe012260e8f0 intr_event_handle() at intr_event_handle+0xe2/frame 0xfffffe012260e940 intr_execute_handlers() at intr_execute_handlers+0x48/frame 0xfffffe012260e970 lapic_handle_intr() at lapic_handle_intr+0x3f/frame 0xfffffe012260e990 Xapic_isr1() at Xapic_isr1+0xb7/frame 0xfffffe012260e990 --- interrupt, rip = 0xffffffff8071eaad, rsp = 0xfffffe012260ea60, rbp = 0xfffffe012260ea70 --- spinlock_exit() at spinlock_exit+0x2d/frame 0xfffffe012260ea70 sleepq_timedwait() at sleepq_timedwait+0xd3/frame 0xfffffe012260eaa0 _cv_timedwait_sbt() at _cv_timedwait_sbt+0x1a0/frame 0xfffffe012260eb10 sched_sync() at sched_sync+0x6b6/frame 0xfffffe012260ebb0 fork_exit() at fork_exit+0x75/frame 0xfffffe012260ebf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe012260ebf0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- Uptime: 14s ====================================================================== -- Best regards, Lev mailto:lev@FreeBSD.org From owner-freebsd-current@freebsd.org Sun Oct 25 19:45:12 2015 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 2B0BD8451 for ; Sun, 25 Oct 2015 19:45:12 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F03DD120B; Sun, 25 Oct 2015 19:45:11 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by pacfv9 with SMTP id fv9so173232737pac.3; Sun, 25 Oct 2015 12:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3s1x//Ht+TPBC3tJT2aDgEO/GJ1q/PFn8Vs5HNA4Q1U=; b=wEPcTxWDoDSByP9zsHXXWTLXAP9VbpuwmLcBdvYrjTTvhygbN4zNKQiGiz5ZnrYHRr AYX3iS8nFHOqPMRHsNXY2sPTtqKmU/VafQYWY/3fpxC6a/kVWtfiEo+j2VEo4t+Pw8co OUgzJk5GgQqs60JzI7NSiF1MXL60vFDzVGTwtQBGXW4Dc/8QjmTQW1s+njMxrP2jRdjq jin8r4HWnRK6T4UmNbm/5s5DBaeYbttq8bbrqxSWgJP1Haevtt0bmXdS8VKiG1w3kWr9 M1CuM9hLbdgoQxesB1AuUe5Zy125VObJtyaLD2RwI90UcJgvoAGuKLgWLgYio9nQ32/i 6u/w== X-Received: by 10.68.228.3 with SMTP id se3mr11558602pbc.114.1445802311609; Sun, 25 Oct 2015 12:45:11 -0700 (PDT) Received: from [192.168.20.7] (c-24-16-212-205.hsd1.wa.comcast.net. [24.16.212.205]) by smtp.gmail.com with ESMTPSA id rx10sm29927819pab.21.2015.10.25.12.45.11 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 25 Oct 2015 12:45:11 -0700 (PDT) Subject: Re: What changed in rc.d infrastructure in last months? Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=utf-8 From: NGie Cooper X-Priority: 3 (Normal) In-Reply-To: <221574465.20151025223928@serebryakov.spb.ru> Date: Sun, 25 Oct 2015 12:45:10 -0700 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <55E08B75-1A33-4480-B099-D694C669A285@gmail.com> References: <16610120144.20151025222025@serebryakov.spb.ru> <221574465.20151025223928@serebryakov.spb.ru> To: lev@FreeBSD.org X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 25 Oct 2015 19:45:12 -0000 > On Oct 25, 2015, at 12:39, Lev Serebryakov wrote: >=20 > Hello NGie, >=20 > Sunday, October 25, 2015, 10:30:47 PM, you wrote: >=20 >=20 >> This [the hostapd start/stop logic] all gets triggered whenever the = interface goes up and down. > So, first time hostapd is started by /etc/rc.d/netif before devd, and > second time devd call /etc/rc.d/netif again on interface up, am I = right? >=20 > It looks weird. It depends on how it=E2=80=99s setup. Is your interface is using DHCP = and are you using the stock devd.conf file? =46rom etc/devd.conf: 55 notify 0 { 56 match "system" "IFNET"; 57 match "type" "LINK_UP"; 58 media-type "ethernet"; 59 action "/etc/rc.d/dhclient quietstart $subsystem"; 60 }; =E2=80=A6 74 notify 0 { 75 match "system" "IFNET"; 76 match "type" "LINK_UP"; 77 media-type "802.11"; 78 action "/etc/rc.d/dhclient quietstart $subsystem"; 79 }; Thanks! -NGie= From owner-freebsd-current@freebsd.org Sun Oct 25 19:46:40 2015 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 729E184F6 for ; Sun, 25 Oct 2015 19:46:40 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3BFEE143F for ; Sun, 25 Oct 2015 19:46:40 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:3c23:bcdc:5292:fa5f]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 0C7622CB0; Sun, 25 Oct 2015 22:46:38 +0300 (MSK) Date: Sun, 25 Oct 2015 22:46:36 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <606144753.20151025224636@serebryakov.spb.ru> To: NGie Cooper CC: freebsd-current Subject: Re: What changed in rc.d infrastructure in last months? In-Reply-To: <28FF29D6-A2D9-46C0-A419-DB433BB9F54A@gmail.com> References: <16610120144.20151025222025@serebryakov.spb.ru> <28FF29D6-A2D9-46C0-A419-DB433BB9F54A@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 25 Oct 2015 19:46:40 -0000 Hello NGie, Sunday, October 25, 2015, 10:39:51 PM, you wrote: > It=E2=80=99s documented here: > On the other hand, if you want to configure your wireless > interface with hostapd(8), you need to add ``HOSTAP'' to= the > ifconfig_ variable. hostapd(8) will use the > settings from /etc/hostapd-.conf I understand this, and as you can see from my config samples, I'm using exactly this feature. I'm wonder why ifconfig & hostapd try to start TWICE now for same interaface in course of normal boot now. It was not case in, say, r285355. --=20 Best regards, Lev mailto:lev@FreeBSD.org From owner-freebsd-current@freebsd.org Sun Oct 25 19:49:16 2015 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 CE51D85AB for ; Sun, 25 Oct 2015 19:49:16 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 975E11791 for ; Sun, 25 Oct 2015 19:49:16 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:3c23:bcdc:5292:fa5f]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 650C02CB3; Sun, 25 Oct 2015 22:49:15 +0300 (MSK) Date: Sun, 25 Oct 2015 22:49:12 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <262572830.20151025224912@serebryakov.spb.ru> To: NGie Cooper CC: freebsd-current Subject: Re: What changed in rc.d infrastructure in last months? In-Reply-To: <55E08B75-1A33-4480-B099-D694C669A285@gmail.com> References: <16610120144.20151025222025@serebryakov.spb.ru> <221574465.20151025223928@serebryakov.spb.ru> <55E08B75-1A33-4480-B099-D694C669A285@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 25 Oct 2015 19:49:16 -0000 Hello NGie, Sunday, October 25, 2015, 10:45:10 PM, you wrote: > It depends on how it=E2=80=99s setup. Is your interface is using DHCP and= are you > using the stock devd.conf file? From etc/devd.conf: devd.conf is stock one, but, of course, HOSTAP-interface uses static address. One more time: wlans_ath0=3D"wlan0" create_args_wlan0=3D"wlanmode hostap bssid" ifconfig_wlan0=3D"HOSTAP inet 192.168.135.1 netmask 255.255.255.0 mode 11ng= channel 3:ht/40 -bgscan ssid home.serebryakov.spb.ru country DE regdomain = row txpower 30" Everything works, but this double-configuration of wlan and double-start of hostpad looks ugly. --=20 Best regards, Lev mailto:lev@FreeBSD.org From owner-freebsd-current@freebsd.org Sun Oct 25 19:54:50 2015 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 325AA87D5 for ; Sun, 25 Oct 2015 19:54:50 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::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 0286F1C0E; Sun, 25 Oct 2015 19:54:50 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by pasz6 with SMTP id z6so165611435pas.2; Sun, 25 Oct 2015 12:54:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sFhCVOT14nHsUiXcgi2lcab2Uf3ele06+b3qBxkaMhw=; b=KJJVvCPz+JIDP/E5b5oApgLlPiY679DbS0BnYHuKgC49EnzVEZ5gPq60ghEBd1eud7 HtSetSCiHKx7tvWXZKY7Po2IEDaz6rnxhfCaexuXHYVZK16+7+OD9H4stgUtCTYNqq7G +oleSJEZT8sKX0R5mRHA3kbCsaTZsqS0lbAwQNWjYExpcdnLYMYttaojUKbirmpf0tkU zROuLQcgU9lXJfEXiR5t/0JlYQATkM/KY/8qP9jJ4z/8Mjmvlxk4F/JRmIbJMOn7et06 wm6p8jyk17eL5wy1zgvjByx1jMZR6nVtv8mKwKvGXDpFQUkITb6f+W/vvhwO3nSkmpu9 GH2g== X-Received: by 10.66.132.37 with SMTP id or5mr36917202pab.5.1445802889485; Sun, 25 Oct 2015 12:54:49 -0700 (PDT) Received: from [192.168.20.7] (c-24-16-212-205.hsd1.wa.comcast.net. [24.16.212.205]) by smtp.gmail.com with ESMTPSA id y5sm29825413pbt.77.2015.10.25.12.54.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 25 Oct 2015 12:54:49 -0700 (PDT) Subject: Re: What changed in rc.d infrastructure in last months? Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=utf-8 From: NGie Cooper X-Priority: 3 (Normal) In-Reply-To: <606144753.20151025224636@serebryakov.spb.ru> Date: Sun, 25 Oct 2015 12:54:48 -0700 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: References: <16610120144.20151025222025@serebryakov.spb.ru> <28FF29D6-A2D9-46C0-A419-DB433BB9F54A@gmail.com> <606144753.20151025224636@serebryakov.spb.ru> To: lev@FreeBSD.org X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 25 Oct 2015 19:54:50 -0000 > On Oct 25, 2015, at 12:46, Lev Serebryakov wrote: >=20 > Hello NGie, >=20 > Sunday, October 25, 2015, 10:39:51 PM, you wrote: >=20 >=20 >> It=E2=80=99s documented here: >=20 >> On the other hand, if you want to configure your = wireless >> interface with hostapd(8), you need to add ``HOSTAP'' = to the >> ifconfig_ variable. hostapd(8) will use = the >> settings from /etc/hostapd-.conf > I understand this, and as you can see from my config samples, I'm = using > exactly this feature. >=20 > I'm wonder why ifconfig & hostapd try to start TWICE now for same > interaface in course of normal boot now. It was not case in, say, = r285355. These commits are probably why =E2=80=94 in particular now all net80211 = devices post-r287394/r287398 are being restarted via /etc/pccard_ether, = which will trigger /etc/rc.d/netif (which doesn=E2=80=99t make sense = because iwn, etc _aren=E2=80=99t_ pcmcia devices). Sidenote, fixing bug 202726 might fix this case with [serial] boot. = I=E2=80=99ll need to double-check the rcorder and get back to you on = that. Thanks, -NGie ------------------------------------------------------------------------ r287398 | glebius | 2015-09-02 07:38:16 -0700 (Wed, 02 Sep 2015) | 4 = lines Add iwm(4), that was missing in r287394. Submitted by: Shawn Webb ------------------------------------------------------------------------ r287394 | glebius | 2015-09-02 05:46:42 -0700 (Wed, 02 Sep 2015) | 11 = lines Fix dynamic attach/detach of 802.11 devices after r287197: o In pccard_ether add code to start children of a 802.11 device, that are configured in rc.conf. o In devd.conf provide a regex matching all 802.11 devices, and on match run pccard_ether to spawn children. PR: 202784 Submitted by: In collaboration with: "Oleg V. Nauman" ------------------------------------------------------------------------ r287197 | glebius | 2015-08-27 01:56:39 -0700 (Thu, 27 Aug 2015) | 43 = lines Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 = layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which = notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, = when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.= From owner-freebsd-current@freebsd.org Sun Oct 25 19:58:58 2015 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 D25E1892F for ; Sun, 25 Oct 2015 19:58:58 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::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 A2A3D1EE9; Sun, 25 Oct 2015 19:58:58 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by padhk11 with SMTP id hk11so165876523pad.1; Sun, 25 Oct 2015 12:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ayGxYyJH27yPvlrNpfDJDrZQlEH8THnlrcxG7QjndlA=; b=r4ELwsDZ33OFIG2SE2SuLIpllJNjyLaEqKhY9CLtiX0RXRvATsQsiovfhRHfGWM6pi MKJs22t0SB9tyjDWgLm5GyX+eqNYoUXLITD74PLCXQAttVkM1FXY/BuR7Mel+yq+fw9o F31kuhSrlrAaMPDuFTN0nO26RlFPR4drdlX517ixYWG+YENYdCgaXGWtKwSKAcrGSCC4 rqQjWyJAob1n1qbmadDnkIZ+ktU28Yo2y01Uq7/1/PslilxInnh/wtL73bufRTFawt6y X7eVl6DxgL3I97PBLXPlZ5HDrjwNR4ZMFfPEem9eWyDUTGFh3aAnhZH6t6QKS3y0T7OR Asvw== X-Received: by 10.67.30.74 with SMTP id kc10mr36332040pad.147.1445803138334; Sun, 25 Oct 2015 12:58:58 -0700 (PDT) Received: from [192.168.20.7] (c-24-16-212-205.hsd1.wa.comcast.net. [24.16.212.205]) by smtp.gmail.com with ESMTPSA id ij3sm14515250pbb.62.2015.10.25.12.58.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 25 Oct 2015 12:58:57 -0700 (PDT) Subject: Re: What changed in rc.d infrastructure in last months? Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=utf-8 From: NGie Cooper X-Priority: 3 (Normal) In-Reply-To: Date: Sun, 25 Oct 2015 12:58:57 -0700 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <562C2E44-DA31-450F-B867-607047697EFE@gmail.com> References: <16610120144.20151025222025@serebryakov.spb.ru> <28FF29D6-A2D9-46C0-A419-DB433BB9F54A@gmail.com> <606144753.20151025224636@serebryakov.spb.ru> To: lev@FreeBSD.org X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 25 Oct 2015 19:58:58 -0000 > On Oct 25, 2015, at 12:54, NGie Cooper wrote: ... > I=E2=80=99ll need to double-check the rcorder and get back to you on = that. Answering this part: nope. devd still gets started after netif on my = branch, so it=E2=80=99ll still start hostapd twice: $ rcorder `make -VFILES SRCCONF=3D/dev/null` growfs ... netif devd ... $ Thanks,= From owner-freebsd-current@freebsd.org Sun Oct 25 20:09:06 2015 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 863FA8C89 for ; Sun, 25 Oct 2015 20:09:06 +0000 (UTC) (envelope-from yaneurabeya@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 49EDA13AD; Sun, 25 Oct 2015 20:09:06 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by oiao187 with SMTP id o187so90225729oia.3; Sun, 25 Oct 2015 13:09:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PGyHLWktODvJUi9m4QLQriK/Tnpw9oMignsx2qMjw6k=; b=MVFcNe/ckeMorYFK1fH17atR7yW/gfHUFbikZoIIFQtXXkJ2QMJvhwiC1XOSCWJ60X easTJnOACJNf2hdcqJMDdIN1ugvxERklP2C845Xb1UioVamCaILr2rLa3Hd3OndvnRap CUKfGrf0iKnQrkYHWsRoOfthADC3og/CVuhlgheG1cKFnvL7RaCgDmf+75uzVuKwG4Z7 RGCedj4eU/MjwKR6/B6r5fwf/4pJDdxLslDgEfhavSbyqW9vTkWr23x4Ks7666eOUCax rtOX9HCcbeQ3AlryOKGIut8KSmr/R+ZJcGY4W9pBVsWiWxcq7UEDoVapsgGKIQeAcbdl 0vLA== X-Received: by 10.202.44.195 with SMTP id s186mr21080951ois.11.1445803745323; Sun, 25 Oct 2015 13:09:05 -0700 (PDT) Received: from ?IPv6:2601:601:800:126d:6c5b:a5fd:aec8:13bf? ([2601:601:800:126d:6c5b:a5fd:aec8:13bf]) by smtp.gmail.com with ESMTPSA id c185sm13411910oif.17.2015.10.25.13.09.04 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 25 Oct 2015 13:09:04 -0700 (PDT) Subject: Re: What changed in rc.d infrastructure in last months? Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=utf-8 From: NGie Cooper X-Priority: 3 (Normal) In-Reply-To: <562C2E44-DA31-450F-B867-607047697EFE@gmail.com> Date: Sun, 25 Oct 2015 13:09:03 -0700 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <731AEB43-6519-4FC4-A115-E45FCFAE8F72@gmail.com> References: <16610120144.20151025222025@serebryakov.spb.ru> <28FF29D6-A2D9-46C0-A419-DB433BB9F54A@gmail.com> <606144753.20151025224636@serebryakov.spb.ru> <562C2E44-DA31-450F-B867-607047697EFE@gmail.com> To: lev@FreeBSD.org X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 25 Oct 2015 20:09:06 -0000 > On Oct 25, 2015, at 12:58, NGie Cooper wrote: >=20 >=20 >> On Oct 25, 2015, at 12:54, NGie Cooper wrote: >=20 > ... >=20 >> I=E2=80=99ll need to double-check the rcorder and get back to you on = that. >=20 > Answering this part: nope. devd still gets started after netif on my = branch, so it=E2=80=99ll still start hostapd twice: >=20 > $ rcorder `make -VFILES SRCCONF=3D/dev/null` > growfs > ... > netif > devd > ... > $ Ok, this is really not making sense from a design perspective. = `ifconfig_` is being overloaded for starting up hostap=E2=80=99s = (even though ifconfig itself doesn=E2=80=99t support hostap =E2=80=94 = only `wlanmode ap`). I don=E2=80=99t understand why it was done this way = instead of just creating additional variables for `hostapd_`, = similar to `ifconfig_` (other than maybe, it simplified things = because `_ifconfig_getargs` could be used to grab the variables from = `ifconfig_` =E2=80=94 but it seems like a kludge to me). I=E2=80=99d need to boot up FreeBSD on one of my PC laptops to confirm = what the behavior is (the earliest I will likely be able to do this is = later on today). $ grep -r hostap sbin/ifconfig/ sbin/ifconfig/ifconfig.8:.Cm hostap ), sbin/ifconfig/ifconfig.8:.Cm hostap sbin/ifconfig/ifconfig.8:.Xr hostapd 8 $ Thanks, -NGie= From owner-freebsd-current@freebsd.org Sun Oct 25 20:50:57 2015 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 E98F7848F for ; Sun, 25 Oct 2015 20:50:56 +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 8C9CA1503; Sun, 25 Oct 2015 20:50:56 +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 t9PKooVT083178 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 25 Oct 2015 22:50:51 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua t9PKooVT083178 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id t9PKooEH083177; Sun, 25 Oct 2015 22:50:50 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 25 Oct 2015 22:50:50 +0200 From: Konstantin Belousov To: Lev Serebryakov Cc: freebsd-current , jhb@FreeBSD.org Subject: Re: r286256 (changes in both schedulers) leads to almost-instant reboot on my system. Message-ID: <20151025205050.GL2257@kib.kiev.ua> References: <1496792606.20151025224406@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1496792606.20151025224406@serebryakov.spb.ru> 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.20 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, 25 Oct 2015 20:50:57 -0000 On Sun, Oct 25, 2015 at 10:44:06PM +0300, Lev Serebryakov wrote: > Hello freebsd-current, > > I've tracked down my reboot on r289874 to r286256. My system crashes > after several seconds of running with several post-286256 revisions > (r289874 is tested most by me). But if I revert r286256 (and only this > one), r289874 works solid-stable with both ULE and 4BSD. It is amd64 > system. td_oncpu and td_lastcpu are not used for anything in scheduler, td_lastcpu usage is only advisory. At least, show the source line for the sched_add+0x116. But you probably already know that a full backtrace from kgdb, with locals, and print-out of the current thread structure would be useful to see what is going on. > > Typical panic logs look like this: > > ====================================================================== > gif0: link state changed to UP > kernel trap 9 with interrupts disabled > > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 0; apic id = 00 > instruction pointer = 0x20:0xffffffff8046e3c6 > stack pointer = 0x28:0xfffffe011bd59890 > frame pointer = 0x28:0xfffffe011bd59980 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = resume, IOPL = 0 > current process = 11 (swi4: clock (0)) > trap number = 9 > panic: general protection fault > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe011bd59530 > vpanic() at vpanic+0x182/frame 0xfffffe011bd595b0 > panic() at panic+0x43/frame 0xfffffe011bd59610 > trap_fatal() at trap_fatal+0x351/frame 0xfffffe011bd59670 > trap() at trap+0x6d8/frame 0xfffffe011bd597d0 > calltrap() at calltrap+0x8/frame 0xfffffe011bd597d0 > --- trap 0x9, rip = 0xffffffff8046e3c6, rsp = 0xfffffe011bd598a0, rbp = 0xfffffe011bd59980 --- > sched_add() at sched_add+0x116/frame 0xfffffe011bd59980 > intr_event_schedule_thread() at intr_event_schedule_thread+0xae/frame 0xfffffe011bd599b0 > intr_event_handle() at intr_event_handle+0xe2/frame 0xfffffe011bd59a00 > intr_execute_handlers() at intr_execute_handlers+0x48/frame 0xfffffe011bd59a30 > lapic_handle_intr() at lapic_handle_intr+0x3f/frame 0xfffffe011bd59a50 > Xapic_isr1() at Xapic_isr1+0xb7/frame 0xfffffe011bd59a50 > --- interrupt, rip = 0xffffffff8063e1f2, rsp = 0xfffffe011bd59b20, rbp = 0xfffffe011bd59b20 --- > spinlock_exit() at spinlock_exit+0x32/frame 0xfffffe011bd59b20 > intr_event_execute_handlers() at intr_event_execute_handlers+0xae/frame 0xfffffe011bd59b60 > ithread_loop() at ithread_loop+0xa6/frame 0xfffffe011bd59bb0 > fork_exit() at fork_exit+0x75/frame 0xfffffe011bd59bf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe011bd59bf0 > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > Uptime: 16s > ====================================================================== > wlan0: AP-ENABLED > kernel trap 9 with interrupts disabled > > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 0; apic id = 00 > instruction pointer = 0x20:0xffffffff805190b6 > stack pointer = 0x28:0xfffffe012260e7d0 > frame pointer = 0x28:0xfffffe012260e8c0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = resume, IOPL = 0 > current process = 16 (syncer) > trap number = 9 > panic: general protection fault > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe012260e470 > vpanic() at vpanic+0x182/frame 0xfffffe012260e4f0 > panic() at panic+0x43/frame 0xfffffe012260e550 > trap_fatal() at trap_fatal+0x351/frame 0xfffffe012260e5b0 > trap() at trap+0x6d8/frame 0xfffffe012260e710 > calltrap() at calltrap+0x8/frame 0xfffffe012260e710 > --- trap 0x9, rip = 0xffffffff805190b6, rsp = 0xfffffe012260e7e0, rbp = 0xfffffe012260e8c0 --- > sched_add() at sched_add+0x116/frame 0xfffffe012260e8c0 > intr_event_schedule_thread() at intr_event_schedule_thread+0xae/frame 0xfffffe012260e8f0 > intr_event_handle() at intr_event_handle+0xe2/frame 0xfffffe012260e940 > intr_execute_handlers() at intr_execute_handlers+0x48/frame 0xfffffe012260e970 > lapic_handle_intr() at lapic_handle_intr+0x3f/frame 0xfffffe012260e990 > Xapic_isr1() at Xapic_isr1+0xb7/frame 0xfffffe012260e990 > --- interrupt, rip = 0xffffffff8071eaad, rsp = 0xfffffe012260ea60, rbp = 0xfffffe012260ea70 --- > spinlock_exit() at spinlock_exit+0x2d/frame 0xfffffe012260ea70 > sleepq_timedwait() at sleepq_timedwait+0xd3/frame 0xfffffe012260eaa0 > _cv_timedwait_sbt() at _cv_timedwait_sbt+0x1a0/frame 0xfffffe012260eb10 > sched_sync() at sched_sync+0x6b6/frame 0xfffffe012260ebb0 > fork_exit() at fork_exit+0x75/frame 0xfffffe012260ebf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe012260ebf0 > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > Uptime: 14s > ====================================================================== > > > -- > Best regards, > Lev mailto:lev@FreeBSD.org From owner-freebsd-current@freebsd.org Sun Oct 25 22:33:18 2015 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 E3306A17440 for ; Sun, 25 Oct 2015 22:33:17 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B7F63184D; Sun, 25 Oct 2015 22:33:17 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by ioll68 with SMTP id l68so170465590iol.3; Sun, 25 Oct 2015 15:33:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=OR9VmMycNZJL7tq0QXqWf1WAG6Cjw2d6qyTiidrFxAo=; b=kZWrtrjA+H4zASvPN1JPenETkz+Y3pwyJI8r6aHzCXGZ7j1tkumW25MCJD/TQzw5HY E8Id/VypC7YfAkZ1QGy9SwfHg+TIclUZDVbTjQM3T/pybjeXq/1WZ4+3N17B6Ih3Np86 cJ9o5iX72EZtfi1f9p9q/OhU/TYnDV1hC3VZBRUBLptbT4FXJF8vBIIv/xNqGdKxgMKA lcJsGa+mUKk+MvwgNrP1ien5bR3t+nzCU/lcPlH/h7AhCF0K03nF6v9hg9Xq23pVp0CE eUakJ/+2wNgO5/d6ZIYxjkAKR9G+hnoi6beLG4AcCF6EONvS4cchL4p0ilh9JFFrdjjI 16GQ== MIME-Version: 1.0 X-Received: by 10.107.137.202 with SMTP id t71mr38560375ioi.119.1445812397057; Sun, 25 Oct 2015 15:33:17 -0700 (PDT) Sender: chmeeedalf@gmail.com Received: by 10.36.41.138 with HTTP; Sun, 25 Oct 2015 15:33:16 -0700 (PDT) Received: by 10.36.41.138 with HTTP; Sun, 25 Oct 2015 15:33:16 -0700 (PDT) In-Reply-To: <0B5D0762-F5A6-4025-A16F-E7A96DF72BF4@gmail.com> References: <0B5D0762-F5A6-4025-A16F-E7A96DF72BF4@gmail.com> Date: Sun, 25 Oct 2015 17:33:16 -0500 X-Google-Sender-Auth: jSalk8Mhd0GIlIZs-RxoTvAymJc Message-ID: Subject: Re: r287797 breaks build WITHOUT_NIS From: Justin Hibbits To: Garrett Cooper Cc: Craig Rodrigues , FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 25 Oct 2015 22:33:18 -0000 Thanks! On Oct 25, 2015 02:44, "NGie Cooper" wrote: > > > On Oct 10, 2015, at 16:18, Justin Hibbits wrote: > > > > When building WITHOUT_NIS, the following errors show up (base gcc, for > > building powerpc): > > > > cc1: warnings being treated as errors > > /home/chmeee/freebsd/head/lib/libc/gen/getgrent.c: In function > > 'compat_setgrent': > > /home/chmeee/freebsd/head/lib/libc/gen/getgrent.c:1258: warning: > > comparison is always false due to limited range of data type > > /home/chmeee/freebsd/head/lib/libc/gen/getgrent.c:1267: warning: > > comparison is always false due to limited range of data type > > /home/chmeee/freebsd/head/lib/libc/gen/getgrent.c: In function > 'compat_group': > > /home/chmeee/freebsd/head/lib/libc/gen/getgrent.c:1355: warning: > > comparison is always false due to limited range of data type > > /home/chmeee/freebsd/head/lib/libc/gen/getgrent.c:1378: warning: > > comparison is always false due to limited range of data type > > > > Converting the local variable in the macros back to int fixes it. > > Fixed in r289925. > Thanks! From owner-freebsd-current@freebsd.org Mon Oct 26 02:59:47 2015 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 8177C8C6A; Mon, 26 Oct 2015 02:59:47 +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 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2DE1313D6; Mon, 26 Oct 2015 02:59:45 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190f-f799c6d000001933-47-562d971edd9b Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id A3.A0.06451.E179D265; Sun, 25 Oct 2015 22:59:42 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t9Q2xf8d028728; Sun, 25 Oct 2015 22:59:41 -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 t9Q2xbBC005829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 25 Oct 2015 22:59:40 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t9Q2xbd4023860; Sun, 25 Oct 2015 22:59:37 -0400 (EDT) Date: Sun, 25 Oct 2015 22:59:37 -0400 (EDT) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: freebsd-hackers@freebsd.org cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD Quarterly Status Report - Third Quarter 2015 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+NgFvrOIsWRmVeSWpSXmKPExsUixCmqrCs3XTfMYOInLotd106zW8x584HJ Yvvmf4wWh5uFHFg8ZnyazxLAGMVlk5Kak1mWWqRvl8CVceXWA8aCXx1sFfeO3WVrYFx5j6WL kYNDQsBEYul8wS5GTiBTTOLCvfVsILaQwGImientdl2MXED2RkaJTdMnskI4h5gkZvxYyQjh NDBKNB+YyQ7SwiKgLfH3/ktmEJtNQE3i8d5mVoixihKbT01iBtkmIiAvseC8PUiYWcBaYu66 9WAlwgK2Ek/XX2ABsXkFHCV+fJjABGKLCuhIrN4/BSouKHFy5hMWiF4tieXTt7FMYBSYhSQ1 C0lqASPTKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl0TvdzMEr3UlNJNjODQlOTfwfjtoNIhRgEO RiUe3hc8umFCrIllxZW5hxglOZiURHnP1gKF+JLyUyozEosz4otKc1KLDzFKcDArifBmtQHl eFMSK6tSi/JhUtIcLErivJt+8IUICaQnlqRmp6YWpBbBZGU4OJQkeOOnAjUKFqWmp1akZeaU IKSZODhBhvMADf81BWR4cUFibnFmOkT+FKMxx6Np19YycayZcn8tkxBLXn5eqpQ4byPIOAGQ 0ozSPLhp4PSym0n1FaM40HPCvBtBqniAqQlu3iugVUxAq/KfaYKsKklESEk1MPq/m8h7XJqL +deiW7ESScxb/hhM8pacEmg3S/TVeu0niyX+Ni5dVqXOHLZSVy/itMjuM1tnebrf0/z5MKrs gmTx5t+/Fqw1vKD5cLVzhHhrK7fMGXvdfrcNuUJhDTvOxC0/Lv9M5WFBJ9NfP4bHKrY8jxvC T4cekNjxdrOU7AZO3aXqBbqmeUosxRmJhlrMRcWJABFBCNsKAwAA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 26 Oct 2015 02:59:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 FreeBSD Project Quarterly Status Report: July - September 2015 The third quarter of 2015, from July to September, was again a period of busy activity for FreeBSD: for the second quarter in a row we have the largest report yet published. The Foundation continues to play a strong role, bringing both a developer and evangelist presence to conferences, funding much of the hardware that the cluster administration team uses to keep things running, and sponsoring many development projects for FreeBSD. This quarter we also hear from some of the student projects funded by Google Summer of Code 2015, ranging a wide gamut from the bootloader to additional ARM support, but also at a range of completion status. Some of the GSoC output is in the tree already, but others could benefit from additional attention to help out our budding new contributors as their schedules fill with the return to classes. ZFS and the network stack continue to be strong areas for FreeBSD, with both receiving active maintenance and feature improvements during this quarter. Substantial work continues on arm64, potentially putting it on the path toward a promotion to Tier-1 status, and a new port to the RISC-V architecture has made great headway in a short period of time. But it is not just our strengths and exciting new areas that have seen attention this cycle; there are also some parts of the system that are frequently perceived as unchanging infrastructure that have received attention and improvements, with truss and (k)gdb receiving significant overhauls, new implementations for the man page tools being brought in, the website receiving a new skin, and a brand new system for translating documentation that greatly lowers the barrier to entry. Nonetheless, despite its record length, this report does not and cannot cover all of the work being done on FreeBSD throughout the reporting period -- there are many bug fixes too minor to mention here, and developers too busy working on the next project to write up an entry for the previous project. It is not just the developers committing to Subversion that comprise the ongoing activities of FreeBSD, but also the users testing unreleased code or reporting bugs in released code, and participants on the mailing lists and forums helping each other solve their problems. Even the chats on IRC that wander far from the stated topic of a channel contribute to the community around FreeBSD; it is that community whose effectiveness and helpfulness is a key component of the effectiveness and usefulness of FreeBSD itself. Not just to the developers listed in this report, but to everyone in the community, thank you for making FreeBSD a great operating system. --Ben Kaduk __________________________________________________________________ Please submit status reports for the fourth quarter of 2015 (from October to December) by January 7, 2016. __________________________________________________________________ FreeBSD Team Reports * FreeBSD Cluster Administration Team * FreeBSD Release Engineering Team * The FreeBSD Core Team Projects * automtud: Better Jumbo Frame Support * bhyve * Clang, llvm, lldb, compiler-rt and libc++ Updated to 3.7.0 * DTrace and TCP * FreeBSD on the Acer C720 Chromebook * High Availability Clustering in CTL * Multipath TCP for FreeBSD * Porting bhyve to ARM-based Platforms * Root Remount * The Graphics Stack on FreeBSD * The nosh Project * UEFI Boot and Framebuffer Support * ZFS Code Sync with Latest Illumos * ZFS Support for UEFI Boot/Loader Kernel * Adding PCIe Hot-plug Support * Cavium LiquidIO Smart NIC Driver * CloudABI: Pure Capabilities Runtime Environment * FreeBSD Xen * ioat(4) Driver Import * IPsec Upgrades Architectures * Atomics * FreeBSD on Cavium ThunderX (arm64) * FreeBSD on the HiKey ARMv8 Board * FreeBSD/arm64 * FreeBSD/RISC-V Port Userland Programs * mandoc and roff Toolchain * pkg 1.6 * sesutil(8) * truss(1) * Updates to GDB Ports * Bringing GitLab into the Ports Collection * GNOME on FreeBSD * KDE on FreeBSD * Node.js Modules * Ports Collection * Ports on PowerPC * Xfce on FreeBSD Documentation * PO Translation Project * Website CSS Update Google Summer of Code * Allwinner A10/A20 Support * mtree Parsing and Manipulation Library * Multiqueue Testing * Update Ficl in Bootloader Miscellaneous * The FreeBSD Foundation * ZFSguru __________________________________________________________________ FreeBSD Cluster Administration Team Contact: FreeBSD Cluster Administration Team The FreeBSD Cluster Administration Team consists of the people responsible for administering the machines that the project relies on for its distributed work and communications to be synchronised. Our primary cluster has been hosted as a guest in California for many years. Our ongoing project is relocating the core functionality to a location in New Jersey with a formal hosting arrangement. This is an equipment refresh, consolidation for better use of resources, and for better continuity of service. There is a significant amount of behind-the-scenes work to make this happen. The original cluster was implemented with a common, shared, assumed-to-be secure network with ubiquitous NFS everywhere. This structure does not lend itself well to being distributed across geographically diverse locations, particularly when Internet transit is required. The bulk of the work is rebuilding services to be portable, stand-alone components that do not depend on shared-network access and are safe enough to use across the insecure Internet. Highlights this quarter: * Many internal distribution systems switched from rsync to a distribution mesh using "syncthing". * We have implemented more code/data signing infrastructure with out-of-band verification. * New 32-core reference build hosts are online. * Internal admbugs switched from bugzilla 4.4 to 5.0 and packages were made available for the bugmeister team. * Finally switched from varnish3 to varnish4. * We exorcised hub.FreeBSD.org, the last survivor of the 2012 security incident. * vuxml and the legacy portaudit build system were converted to components and integrated. * https://download.FreeBSD.org/ is nearing completion (please do not use until officially announced). * A Taiwan node was brought into service for pkg, ftp, svn, and vuxml mirroring. * One of the freebsd-update mirrors was converted from lighttpd to nginx due to a data corruption bug. * We completed detachment of the svn repository from the old cluster and moved it to its new location. Ongoing: * The cluster runs a mixture of 11-current and 10-stable as part of our "eat our own dogfood" project. For this to be useful, we do monthly cluster refreshes to keep up with current code. * We build internal base system snapshots every few days and packages every day. * We also provide support for non-clusteradm-operated services including jenkins, reviews, portsnap, freebsd-update, bugzilla, package builders, git, and mercurial. This varies from as little as maintaining SSL front-ends through operating servers, distributing data or building packages/binaries to run. __________________________________________________________________ FreeBSD Release Engineering Team Links FreeBSD 10.2-RELEASE announcement URL: https://www.freebsd.org/releases/10.2R/announce.html FreeBSD development snapshots URL: http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/ FreeBSD 10.3-RELEASE schedule URL: https://www.freebsd.org/releases/10.3R/schedule.html FreeBSD 11.0-RELEASE schedule URL: https://www.freebsd.org/releases/11.0R/schedule.html Contact: FreeBSD Release Engineering Team The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes, and maintaining the respective branches, among other things. In mid-August, the FreeBSD Release Engineering Team released FreeBSD 10.2-RELEASE, two weeks earlier than the original schedule anticipated. The FreeBSD Release Engineering Team would like to thank all that have tested the BETA and RC builds and reported issues during the release cycle. The FreeBSD Release Engineering Team, with approval from the FreeBSD Core Team, appointed Marius Strobl as the Deputy Lead. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ The FreeBSD Core Team Contact: FreeBSD Core Team The biggest task handled by the Core Team during this quarter was developing and publishing the new Code of Conduct. The Code of Conduct describes how people are expected to behave on all FreeBSD official communication channels, as well as how developers and other people involved with the project are to behave when representing the project in public. The Code of Conduct was generally well received and elicited numerous comments and suggestions for improvements from the community, many of which have been integrated. The next task handled by Core was the restoration of Babak Farrokhi's ports commit bit. Babak resides in Iran. A few years ago, legal advice suggested that allowing contributions from Iranian residents might violate US trade sanctions. After several years, Core was asked to revisit the issue. On the advice of counsel, Core decided that it could restore commit privileges to commmitters residing in Iran. The CTM service came under security review. Given that the lack of use of routine authenticity checking made the injection of trivial exploit code relatively easy, the service was held to be too risky to continue as an official part of the FreeBSD base system. CTM has very few remaining users but they should be able to install CTM from the Ports Collection in order to continue doing so. Core learned that ISC was ceasing its hosting service, which has entailed a rapid rework of plans on the movement of significant portions of the FreeBSD cluster to that data center. Cluster administration has taken ownership of the situation and is making progress. Core fielded an enquiry about NextBSD and whether this should be the future direction for the whole FreeBSD project. Core's position is that NextBSD is an interesting project, and we regard it, like the other BSD projects, as a potential source of good ideas. However, we currently have no plans to adopt NextBSD as the official FreeBSD distribution. Beyond these issues, Core also spent time in various routine activities. During this quarter we issued three new src commit bits, and took none in for safekeeping. Welcome to Allan Jude, Marcelo Araujo, and Andriy Voskoboinyk. __________________________________________________________________ automtud: Better Jumbo Frame Support Links jmgurney/automtud on github URL: https://github.com/jmgurney/automtud Contact: John-Mark Gurney The automtud script will allow a FreeBSD machine to send jumbo frames to machines that support them, while using normal-sized frames for other machines. There are various advantages to using jumbo frames, such as reduced protocol overhead. It also means that TCP streams will not be segmented as much, although TSO helps mitigate the disadvantages of such segmentation. In cases where LRO does not work well, fewer packets will be received. The script currently does not restore the system to its original state when it exits. This means that you must manually change the interface MTU and delete host routes after stopping the script. Open tasks: 1. Fix up various Ethernet drivers to better support jumbo frames. Most Ethernet drivers, though they support scatter/gather, use a physically contiguous zone to do so, which can cause resource shortages. 2. More testing is needed to ensure that things behave as expected. This means that when running the script, communication to all machines functions normally, without slowdown or connectivity issues. Check vmstat -z | grep mbuf to ensure that such issues are not due to running out of jumbo_9k or jumbo_16k buffers due to Ethernet driver issues. __________________________________________________________________ bhyve Links bhyve FAQ and talks URL: http://www.bhyve.org NE2000 device emulation GSoC project URL: https://wiki.FreeBSD.org/SummerOfCode2015/NE2000EmulationForBhyve Porting bhyve to ARM GSoC project URL: https://wiki.FreeBSD.org/SummerOfCode2015/PortingBhyveToArm ptnetmap support in bhyve GSoC project URL: https://wiki.FreeBSD.org/SummerOfCode2015/ptnetmapOnBhyve Windows support URL: http://docs.FreeBSD.org/cgi/mid.cgi?561187FB.8040506 Illumos support URL: http://docs.FreeBSD.org/cgi/mid.cgi?56118B2B.2040101 Contact: Peter Grehan Contact: Neel Natu Contact: Tycho Nightingale Contact: Allan Jude Contact: Michael Dexter bhyve is a hypervisor that runs on the FreeBSD/amd64 platform. At present, it runs FreeBSD (8.x or later), Linux i386/x64, OpenBSD i386/amd64, NetBSD/amd64, Illumos, and Windows Vista/7/8/10/2008r2/2012r2/2016 x64 guests. Current development is focused on enabling additional guest operating systems and implementing features found in other hypervisors. A combined bhyve and ZFS BoF was held during vBSDCon 2015, hosted by Michael Dexter and Allan Jude. Questions asked about bhyve included live migration and suspend/resume support, and configurations using ZFS. Three bhyve-related projects were selected for GSoC 2015: NE2000 device emulation, porting bhyve to ARM, and ptnetmap support. The major enhancement for bhyve this quarter was support for external firmware, along with a port of the Intel edk2 UEFI firmware. This allows bhyve to run Windows in headless mode, and also Illumos. Open tasks: 1. Improve the documentation. 2. bhyveucl is a work-in-progress script for starting bhyve instances based on a libUCL config file. More information at https://github.com/allanjude/bhyveucl. 3. Add support for virtio-scsi. 4. Flexible networking backends: wanproxy, vhost-net. 5. Support running bhyve as non-root. 6. Add filters for popular VM file formats (VMDK, VHD, QCOW2). 7. Implement an abstraction layer for video (no X11 or SDL in base system). 8. Suspend/resume support. 9. Live migration. 10. Nested VT-x support (bhyve in bhyve). 11. Support for other architectures (ARM, MIPS, PPC). __________________________________________________________________ Clang, llvm, lldb, compiler-rt and libc++ Updated to 3.7.0 Links LLVM 3.7.0 Release Notes URL: http://llvm.org/releases/3.7.0/docs/ReleaseNotes.html Clang 3.7.0 Release Notes URL: http://llvm.org/releases/3.7.0/tools/clang/docs/ReleaseNotes.html PR 201377 Ports exp-run URL: https://bugs.freebsd.org/201377 Contact: Dimitry Andric Contact: Ed Maste Contact: Roman Divacky Contact: Davide Italiano We have updated clang, llvm, lldb, compiler-rt, and libc++ in base to the 3.7.0 release. These all contain numerous improvements. Please see the linked release notes for more detailed information. This brings us completely up-to-date with the latest upstream versions of these projects. Meanwhile, Ed Maste is working on importing the llvm.org version of libunwind. Like the 3.5.x and 3.6.x releases, these components require C++11 support to build. At this point, FreeBSD 10.0 and later provide that support, at least on x86. Currently, there are no solid plans to MFC these versions to any stable branches, due to the difficulties this would introduce for the usual upgrade scenarios. Thanks to Ed Maste and Andrew Turner for their help with this import, and thanks to Antoine Brodin for several ports exp-runs. During the first ports exp-run, some major problems were found, one introduced by a clang bug which caused pow() to generate floating point exceptions in some cases. This in turn caused libpng to fail to build, and one bug in libjpeg-turbo, which was caused by undefined behavior. These two problems took some time to fix, after which another exp-run was done, and this resulted in about a dozen newly failed ports. For almost all of these new failures, fixes were submitted and linked to the original PR 201377 for the exp-run. Open tasks: 1. Commit ports fixes for dependencies of PR 201377. 2. Test and report issues with the new tool chain. __________________________________________________________________ DTrace and TCP Links Commit adding trace points replacing TCPDEBUG URL: https://svnweb.freebsd.org/changeset/base/287759 Contact: George Neville-Neil With the advent of DTrace we are able to replace many of the internal kernel debugging options, such as TCPDEBUG, with statically defined tracepoints (SDTs). Tracepoints have now been added to the system that replicate the functionality of the TCPDEBUG kernel option. No new kernel options need to be added -- they are standard with any kernel that has DTrace, which is included in the default GENERIC kernels in 10.X and HEAD. This project is sponsored by Limelight Networks. __________________________________________________________________ FreeBSD on the Acer C720 Chromebook Links Blog post on how to get things working URL: http://blog.grem.de/pages/c720.html Blog post with links to commits in HEAD URL: http://blog.grem.de/sysadmin/FreeBSD-On-AcerC720-Merged-2015-07-25-23-30.html Backported patch for 10.2-RELEASE URL: http://blog.grem.de/sysadmin/FreeBSD-10.2-On-AcerC720-2015-09-19-17-00. html Contact: Michael Gmelin The Acer C720 Chromebook is an affordable (under $200) and powerful little laptop that provides a battery life of up to six hours running FreeBSD. It is a great machine for travelling and coding in general. The machine is fully functional, meaning that all essential devices work: keyboard, trackpad, light sensor, backlight control, display in VESA mode (fast), external Display on HDMI (only VESA mirror mode), sound, USB ports, SD card slot, camera, and Atheros wireless. This quarter, this project extended previous work on the boot process and keyboard driver as well as the smbus(4) driver. It added three new drivers: ig4(4) for the I2C bus, cyapa(4) for the trackpad, and isl(4), for the ambient light sensor. Much of the development was originally done in late 2014. Since then, the patches have been massively improved and merged into HEAD, so that all relevant devices work without manual patching. For those who are unable to run HEAD, there is a backported patch to 10.2-RELEASE. Thanks to everyone who helped in the process. I couldn't have done it without you (you know who you are). __________________________________________________________________ High Availability Clustering in CTL Contact: Alexander Motin CAM Target Layer (CTL), when originally developed by Copan/SGI, had support for High Availability clustering. Unfortunately, significant portions of the HA code were never published with the main body of the source code. Now, the missing part has been reimplemented from scratch, fixed, and improved. This code supports dual-node HA with Asynchronous LUN Unit Access (ALUA) in four modes: * Active/Unavailable without interlink between nodes, where the secondary node can report nothing except its presence. * Active/Standby with the secondary node handling only basic LUN discovery and reservation, synchronizing state and command execution with the primary node through the interlink. * Active/Active with both nodes processing commands and accessing the backing storage, synchronizing state and command execution with the primary node through the interlink. * Active/Active with the secondary node having no backing storage access, but instead working as a proxy, transferring all commands to the first node for execution through the interlink. In the case of lost interlink connectivity to primary node, the secondary node falls into the Transitioning state, which is like Unavailable and cannot answer most requests, but makes the initiator wait for recovery or cluster failover. CTL also got a large number of other improvements, including support for emulation of CD/DVD drives and removable disks, live LUN reconfiguration, and so on. The code is committed to FreeBSD head and was recently merged to the stable/10 branch. This project is sponsored by iXsystems, Inc.. __________________________________________________________________ Multipath TCP for FreeBSD Links MPTCP for FreeBSD Project Website URL: http://caia.swin.edu.au/urp/newtcp/mptcp/ MPTCP for FreeBSD Source Repository URL: https://bitbucket.org/nw-swin/caia-mptcp-freebsd/ Contact: Nigel Williams Multipath TCP (MPTCP) is an extension to TCP that allows for the use of multiple network interfaces on a standard TCP session. The addition of new addresses and scheduling of data across them occurs transparently from the perspective of the TCP application. The goal of this project is to deliver an MPTCP kernel patch that interoperates with the reference MPTCP implementation, along with additional enhancements to aid network research. The v0.5 patch was released, which is the first patch of the re-written implementation. We are in the process of documenting the new design and addressing some feedback as provided from the community. Work has commenced on improved input handling, as the current method of receiving and reassembling segments has been the cause of some instability and stalls during connection shutdown. This will involve re-using the subflow receive buffers and an upcall to enqueue a MP-layer reassembly task without the need to take a lock on the MP control block. The improvements should also allow bypassing mptcp_usrreq for standard TCP connections. The MPTCP commit history was synchronized with hg-beta.FreeBSD.org, and we have made the repository available on BitBucket (see links). Future patch releases will be tagged there. The tree is now merged with FreeBSD head weekly. An updated v0.51 patch is ready for release. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Release the v0.51 patch. 2. Populate documentation and the issue tracker on the BitBucket repository. 3. Improvements to receive-side code before further testing. 4. Prepare a technical report detailing the design of the current patch. __________________________________________________________________ Porting bhyve to ARM-based Platforms Links Project Wiki page URL: https://wiki.FreeBSD.org/SummerOfCode2015/PortingBhyveToArm Contact: Mihai Carabas Contact: Peter Grehan This summer we have started porting bhyve onto ARMv7 platforms. The low-level routines for ARM processors were rewritten while trying to preserve the hypervisor API originally created for the x86 architectures. We managed to bring up a FreeBSD guest up to the point of initializing interrupts. There is still work to be done in order to virtualize the interrupts and the timer. Our short-term plan after finishing the interrupts and the timer is porting to a real hardware platform (Cubie2). Open tasks: 1. Virtualize interrupts and timer. 2. Port to a real hardware platform. 3. Create SMP support for bhyve-on-arm. 4. Port to ARMv8. __________________________________________________________________ Root Remount Links Userland code review URL: https://reviews.freebsd.org/D3693 Contact: Edward Tomasz Napierala A feature long missing from FreeBSD was the ability to boot up with a temporary rootfs, configure the kernel to be able to access the real rootfs, and then replace the temporary root with the real one. In Linux, this functionality is known as pivot_root. The reroot project aims to provide similar functionality in a different, slightly more user-friendly, way. Simply put, from the user's point of view it is as simple as running reboot -r. The system performs a partial shutdown, killing all processes and unmounting the rootfs, and then partial bringup, mounting the new rootfs, running init, and running the startup scripts as usual. The kernel part of the project has been committed to 11-CURRENT. The userland part is at the "finishing touches" stage, and is expected to be committed soon. A merge to stable/10 is planned and reroot support is planned be included in FreeBSD 10.3. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ The Graphics Stack on FreeBSD Links Graphics stack roadmap and supported hardware matrix URL: https://wiki.FreeBSD.org/Graphics Graphics stack team blog URL: http://blogs.freebsdish.org/graphics/ Ports development tree on GitHub URL: https://github.com/freebsd/freebsd-ports-graphics Contact: FreeBSD Graphics team The Mesa ports were updated to 10.6.8. At the same time, the ports received a major overhaul to make sure all ports are correctly configured. Dual version support was removed. There is only one Mesa version for all supported FreeBSD versions. The libosmesa port, which provided the off-screen version of Mesa, was merged into the Mesa framework. Another big item that was included in the Mesa port is OpenCL. There are two GPU-based OpenCL implementations: lang/clover for supported Radeon cards, and lang/beignet for supported Intel cards (currently only Ivybridge). Thanks go to Johannes Dieterich, O. Hartmann, and Koop Mast for making this happen. Now that Mesa is up-to-date, we can apply the same update procedure to the X.Org server. It is currently at 1.14, and an update to 1.17 is ready. It will be committed shortly. On the kernel side, progress has been made with the i915 update. The driver is able to attach. There are some reports that the X.Org server starts but Mesa is unhappy, so acceleration does not work yet. If you want to test, instructions will be posted on the wiki in the i915 update article (see links). At this stage, we can only accept patches, though -- we will not be able to provide support. We attended two conferences: XDC 2015 in Toronto and EuroBSDcon 2015 in Stockholm. Reports will be posted on the blog. Open tasks: 1. See the Graphics wiki page for up-to-date information. __________________________________________________________________ The nosh Project Links Introduction and blurb URL: http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh.html FreeBSD binary packages URL: http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh/freebsd-binary-packages.html Installation How-To URL: http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh/timorous-admin-installation-how-to.html Roadmap URL: http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh/roadmap.html Commands URL: http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh/commands.html A slightly outdated nosh Guide URL: http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh/guide/index.html Contact: Jonathan de Boyne Pollard The nosh project is a suite of system-level utilities for initializing, running, and shutting down BSD systems, and for managing daemons, terminals, and logging. It supersedes BSD init and the NetBSD rc.d system, drawing inspiration from Solaris SMF for named milestones, daemontools-encore for service control/status mechanisms, UCSPI, and IBM AIX for separated service and system management. It comprises a range of compatibility mechanisms, including shims for familiar commands from other systems, and an automatic import mechanism that takes existing configuration data from /etc/fstab, /etc/rc.conf{,.local}, /etc/ttys, and elsewhere, applying them to its native service definitions and creating additional native services. It is portable (including to Linux) and composable, it provides a migration path from the world of systemd Linux, and it does not require new kernel APIs. It provides clean service environments, orderings and dependencies between services, parallelized startup and shutdown (including fsck), strictly size-capped and autorotated logging, the service manager as a "subreaper", and uses kevent(2) for event-driven parallelism. The past few months have seen a growth in the import mechanism, with full import of /etc/fstab and /etc/ttys available in version 1.18 in July, and importing PC-BSD Warden and FreeBSD 9 jails, and full import of gbde and geli mount/unmount mechanisms in version 1.21 in October. It has also gained the ability to automatically re-generate host.conf and sysctl.conf whenever their source files change. Other developments in the past few months include fully independent shutdown support, no longer relying upon an externally provided shutdown command from another toolset, and a full suite of binary packages. As of version 1.20, it became possible to have a fully-nosh-managed system, on both FreeBSD and Linux, using just precompiled binary packages. The biggest task remaining is one that was set a while ago: the creation of enough native service bundles and ancillary utilities to entirely supplant the rc.d system. A lot of this has been achieved, with the original target list of 157 items now down to just 39 remaining. These are the tricky ones, of course, where help is most needed. Open tasks: 1. There are still a few rc scripts left that should be easy to convert, such as /etc/rc.d/gptboot and /etc/rc.d/growfs as oneshot services, /etc/rc.d/routing, and /etc/rc.d/kldxref. 2. FreeBSD's /etc/rc.d/bluetooth is over 360 lines long. In 2011, Iain Hibbert wrote a "simpler" bluetooth for NetBSD. This can perhaps be used as a simpler basis for a nosh translation. 3. Add kernel support for passing a -b option to pid 1, and support for a boot_bare variable in the loader, to allow "emergency" (where even no shell dotfiles are loaded) and "rescue" mode bootstraps, akin to Linux. (History: The -b mechanism and idea date back to version 2.57d of Miquel van Smoorenburg's System 5 init clone, dated 1995-12-03, and was already known as "emergency boot" by 1997.) 4. Add support to FreeBSD's fsck(8) for outputting machine-readable progress reports to a designated file descriptor, so that nosh can provide progress bars for multiple fscks running in parallel. nosh already provides this functionality on Linux, where fsck(8) does provide machine-readable output. 5. Identify when the configuration import system needs to be triggered, such as when bsdconfig alters configuration files, and create the necessary hooks to import external configuration changes into nosh. 6. Investigate how FreeBSD/PC-BSD could be improved by taking advantage of some available nosh package mechanisms. __________________________________________________________________ UEFI Boot and Framebuffer Support Contact: Ed Maste Contact: Marcel Moolenaar A number of UEFI bug fixes were committed over the last quarter, improving compatibility with different UEFI implementations. This includes improvements to EFI's vt(4) framebuffer driver, efifb, to handle systems with high resolution displays and unusual framebuffer stride values. In particular, this improves compatibility with a large number of recent Apple MacBook Pros and other Macs. Open tasks: 1. Test FreeBSD head and FreeBSD-STABLE snapshots on a variety of UEFI implementations. __________________________________________________________________ ZFS Code Sync with Latest Illumos Contact: Alexander Motin The ZFS codebase received a significant batch of merges, and is now in sync with the latest Illumos. Among other things, this update includes: * LZ4 is now the default compression algorithm. * Improved prefetch for faster send/receive. * Reduced RAM usage by almost 50% for L2ARC. * Improved I/O aggregation. * Fine-grained checksumming in send/receive stream. * Reduced import time for pools with many datasets. * Reworked and simplified predictive prefetcher. The code is committed to FreeBSD head and was recently merged to the stable/10 branch. __________________________________________________________________ ZFS Support for UEFI Boot/Loader Contact: Eric McCorkle UEFI-enabled boot1.efi and loader.efi have been modified to support loading and booting from a ZFS filesystem, as described in the previous report. The ZFS-enabled loader.efi can be treated as a chainloader when using ZFS-enabled GRUB. During this quarter, several successful tests have been reported on simple ZFS setups, using both boot1.efi with loader.efi as well as GRUB and loader.efi. Successful tests have been reported for UFS with the patched boot1.efi and loader.efi as well. Open tasks: 1. Test reports are needed for more complex ZFS setups, such as with log/l2arc vdevs, mirroring, striping, and raidz. 2. Pending successful reports, the patch needs to be reviewed and committed. __________________________________________________________________ Adding PCIe Hot-plug Support Links PCIe Hot-plug Perforce Branch URL: http://p4db.FreeBSD.org/depotTreeBrowser.cgi?FSPC=//depot/projects/pciehotplug Commit adding bridge save/restore URL: https://svnweb.FreeBSD.org/changeset/base/r281874 Github branch with patches URL: https://github.com/FreeBSDFoundation/freebsd/tree/pciehp Contact: John-Mark Gurney PCI Express (PCIe) hot-plug is used on both laptops and servers to allow peripheral devices to be added or removed while the system is running. Laptops commonly include hot-pluggable PCIe as either an ExpressCard slot or a Thunderbolt interface. ExpressCard has built-in USB support that is already supported by FreeBSD, but ExpressCard PCIe devices like Gigabit Ethernet adapters and eSATA cards are only supported when they are present at boot, and their removal may cause FreeBSD to crash. The goal of this project is to allow these devices to be inserted and removed while FreeBSD is running. This work will provide the basic infrastructure to support adding and removing devices, though it is expected that additional work will be needed to update individual drivers to support hot-plug. Current testing is focused on getting a simple UART device functional. Basic hot swap is currently functional. A set of the patches for the work done in this project is now available on github.com. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Get suspend/resume functional by saving and restoring the necessary registers. This should be addressed by r281874. 2. Make sure that upon suspend, devices are removed so that we are not fooled if they are replaced with different devices while the machine is suspended. 3. Improve how state transitions are handled, possibly by using a proper state machine. __________________________________________________________________ Cavium LiquidIO Smart NIC Driver Links LiquidIO product page URL: http://www.cavium.com/LiquidIO_Application_Acceleration_Adapters.html Contact: Stanislaw Kardach Contact: Zyta Racia This project aims to add support for the LiquidIO family of high-performance programmable accelerator 10/40-gigabit Ethernet network adapters. The currently developed kernel driver supports CN6640- and CN6880-based PCIe cards, enabling these features: * A CNNIC API for controlling/interacting with the smart NIC from user and kernel space including: + Handling multiple concurrent applications running on the same device + A request/reply mechanism for (a)synchronous ordered/unordered communication + Remote memory operations + Device shutdown/reset * A basic NIC module utilizing the CNNIC API and a Cavium-provided NIC firmware. This module provides: + Single/multi-queue TX + Hardware TCP/UDP checksum offloading + Large Receive Offload + Promiscous mode * Sysctl-based device statistics and configuration view * Custom firmware loading via user-built modules and FreeBSD's firmware(9) mechanism. The project is currently being developed in house and is being prepared for upstream. We plan on making it available in FreeBSD 11. This project is sponsored by Cavium, and Semihalf. Open tasks: 1. Upstream the code to FreeBSD head. __________________________________________________________________ CloudABI: Pure Capabilities Runtime Environment Links CloudABI project page URL: https://github.com/NuxiNL/cloudlibc CloudABI Ports Collection URL: https://github.com/NuxiNL/cloudabi-ports CloudABI presentation at FrOSCon URL: https://www.youtube.com/watch?v=LTHSZGVvLw4 Contact: Ed Schouten CloudABI is a POSIX-like runtime environment that uses Capsicum as its sole access control mechanism. CloudABI allows you to develop software that is better hardened against security vulnerabilities, is easier to test, and is easier to migrate across systems. As of August, all of the kernel modifications that are needed to run CloudABI programs have been integrated into FreeBSD head. After loading the cloudabi64 kernel module, you can either run CloudABI programs directly from the shell or by using the cloudabi-run tool (sysutils/cloudabi-utils). cloudabi-run allows you to inject sockets, files, and directories into the launched program in a more structured way. In the meantime, work has started on developing a Ports Collection that contains cross-compiled utilities and libraries for CloudABI. The intent is that this framework generates native packages for a number of operating systems, making it possible to develop CloudABI applications on any operating system, regardless of whether that operating system actually supports CloudABI. If you are interested in CloudABI, be sure to go to the project page on GitHub, watch recordings of talks at conferences, or wait for the upcoming edition of the FreeBSD Journal, which will feature an article on CloudABI. This project is sponsored by Nuxi, the Netherlands. Open tasks: 1. CloudABI is currently only available for amd64. It would make sense to port CloudABI to additional architectures like aarch64. 2. Support for CloudABI has only been integrated into FreeBSD. If we manage to upstream support for CloudABI into other operating systems, it should be possible to run the same binary on multiple operating systems without recompilation. 3. The CloudABI Ports Collection currently has only 60 packages. Although these packages already the building blocks of some interesting software, we are always interested in expanding. __________________________________________________________________ FreeBSD Xen Links FreeBSD PVH DomU wiki page URL: http://wiki.xen.org/wiki/FreeBSD_PVH FreeBSD PVH Dom0 wiki page URL: http://wiki.xen.org/wiki/FreeBSD_Dom0 Porting FreeBSD as a Xen ARM guest URL: http://www.xenproject.org/component/allvideoshare/video/latest/bsdcan-2015-how-to-port-bsd-as-a-xen-on-arm-guest.html Contact: Roger Pau Monn? Contact: Julien Grall Xen is a hypervisor using a microkernel design, providing services that allow multiple computer operating systems to execute on the same computer hardware concurrently. Xen support for FreeBSD on x86 as a guest was introduced in version 8 and ARM support is currently being worked on. Support for running FreeBSD as an amd64 Xen host (Dom0) is available in HEAD. On the x86 front, most of the work during this quarter focused on the implementation of PVH inside Xen. Consequently, most of the activity happened inside of the hypervisor. Patches for a clean PVH implementation have been posted, with the aim of having them merged in the next Xen release (4.7). Once that is done, work will continue adding new features to both FreeBSD and Xen to have feature parity with traditional PV guests/hosts. Apart from this, work is ongoing to import a new netfront from Linux in order to support new features, like split event channel and multiple queue support. On the ARM front, this quarter's work focused on getting FreeBSD/arm64 booting as a Xen guest. The current activity is to upstream patches preparing Xen drivers to support arm64. This includes a rework of the console driver. This project is sponsored by Citrix Systems R&D. Open tasks: 1. Generalize the event channel code so it can be used on ARM. 2. Improve backend (netback, blkback) performance. 3. Work with upstream Xen to improve PVH and make it stable. 4. Improve the generic bounce buffer code for unmapped bios in order to support the alignment requirements of the blkfront driver. __________________________________________________________________ ioat(4) Driver Import Links Wikipedia article on IOAT URL: https://en.wikipedia.org/wiki/I/O_Acceleration_Technology Commit importing ioat(4) URL: https://svnweb.FreeBSD.org/base?view=revision&revision=r287117 Contact: Jim Harris Contact: Conrad Meyer A new driver, ioat(4), was added to the tree. ioat(4) supports Intel's I/O Acceleration Technology devices which are found on some Intel server systems. These devices are DMA offload engines, which can accelerate some I/O-heavy applications by offloading memory copies from the main CPU to the I/OAT unit. This acceleration is not transparent; applications must be adapted to take advantage of the hardware. Some I/OAT models support more advanced copying modes, such as XOR; these modes are not yet supported in the ioat(4) driver. This project is sponsored by Intel Corporation, and EMC / Isilon Storage Division. Open tasks: 1. Further testing, especially on a range of device models other than BDXDE (looking for volunteers here). 2. Support for the more advanced copy modes. __________________________________________________________________ IPsec Upgrades Contact: George Neville-Neil Contact: John-Mark Gurney Contact: Ermal Lu? IPsec is now enabled by default in the GENERIC kernel configuration, and work is proceeding to speed things up in various ways. The latest changes are the addition, by John-Mark Gurney, Ermal Lu?, and George V. Neville-Neil, of AES modes both in hardware and in software. Part of this work also includes more benchmarks undertaken using Conductor in the netperf project. Results have been reported at BSDCan and vBSDcon with more to come at EuroBSDcon and BSDCon Brasil. This project is sponsored by Netgate, and The FreeBSD Foundation. Open tasks: 1. Performance improvements and other tweaks are ongoing. __________________________________________________________________ Atomics Contact: Konstantin Belousov Contact: Alan Cox Contact: Bruce Evans Atomic operations serve two fundamental purposes. First, they are the building blocks for expressing synchronization algorithms in a single, machine-independent way using high-level languages. In essense, atomics abstract the different building blocks supported by the various architectures on which FreeBSD runs, making it easier to develop and reason about lock-less code by hiding hardware-level details. Atomics also provide the barrier operations that allow software to control the effects on memory of out-of-order and speculative execution in modern processors as well as optimizations by compilers. This capability is especially important to multithreaded software, such as the FreeBSD kernel, when running on systems where multiple processors communicate through a shared main memory. Each machine architecture defines a memory model, which specifies the possible effects on memory of out-of-order and speculative execution. More precisely, it specifies the extent to which the machine may visibly reorder memory accesses to optimize performance. Unfortunately, there are almost as many models as architectures. Some architectures, for example IA32 or Sparcv9 TSO, are relatively strongly ordered. In contrast, others, like PowerPC or ARM, are very relaxed. In effect, atomics define a very relaxed abstract memory model for FreeBSD's machine-independent code that can be efficiently realized on any of these architectures. Most FreeBSD development and testing still happens on x86 machines, which, when combined with x86's strongly ordered memory model, leads to errors in the use of atomics, specifically, barriers. In other words, the code is not properly written to FreeBSD's abstract memory model, but the strong ordering of the x86 architecture hides this fact. The architectures impacted by the code that incorrectly uses atomics are less popular or have limited availability, and the resulting bugs from the misuse of atomics are hard to diagnose. The goal of this project is to audit and upgrade the usage of lockless facilities, hopefully fixing bugs before they are observed in the wild. FreeBSD defines its own set of atomics operations, like many other operating systems. But unlike other operating systems, FreeBSD models its atomics and barriers on the release consistency model, which is also known as acquire/release model. This is the same model which is used by the C11 and C++11 language standards as well as the new 64-bit ARM architecture. Despite having syntactical differences, C11 and FreeBSD atomics share essentially the same semantics. Consequently, ample tutorials about the C11 memory model and algorithms expressed with C11 atomics can be trivially reused under FreeBSD. One facility of C11 that was missing from FreeBSD atomics was fences. Fences are bidirectional barrier operations which could not be expressed by the existing atomic+barrier accesses. They were added in r285283. Due to the strong memory model implemented by x86 processors, atomic_load_acq() and atomic_store_rel() can be implemented by plain load and store instructions with only a compiler barrier. No additional ordering constraints are required. This simplification of atomic_store_rel() was done some time ago in r236456. The atomic_load_acq() change was done in r285934, after careful review of all its uses in the kernel and user-space to ensure that no hidden dependency on a stronger implementation was left. The only reordering in memory accesses which is allowed on x86 is that loads may be reordered with older stores to different locations. This results from the use of store buffers at the micro-architecural level. So, to ensure sequentially consistent behavior on x86, a store/load barrier needs to be issued, which can be done with an MFENCE instruction or by any locked read-modify-write operation. The latter approach is recommended by the optimization guides from Intel and AMD. It was noted that careful selection of the scratch memory location, which is modified by the locked RMW operation, can reduce the cost of the barrier by avoiding false data dependencies. The corresponding optimization was committed in r284901. The atomic(9) man page was often a cause of confusion due to both erroneous and ambiguous statements. The most significant of these issues were addressed in changes r286513 and r286784. Some examples of our preemptive fixes to the misuse of atomics that would only become evident on weakly ordered machines are: * A very important lockless algorithm, used in both the kernel and libc, is the timekeeping functionality implemented in kern/kern_tc.c and the userspace __vdso_gettimeofday. This algorithm relied on x86 total store order (TSO) behavior. It was fixed in r284178 and r285286. * The kern/kern_intr.c lockless updates to the it_need indicator were corrected in r285607. * An issue with kern/subr_smp.c:smp_rendezvous_cpus() not guaranteeing the visibility of updates done on other CPUs to the caller was fixed in r285771. * The pthread_once() implementation was fixed to include missed barriers in r287556. This project is sponsored by The FreeBSD Foundation (Konstantin Belousov's work). __________________________________________________________________ FreeBSD on Cavium ThunderX (arm64) Contact: Dominik Ermel Contact: Wojciech Macek Contact: Zbigniew Bodek Cavium's ThunderX is a high-performance 64-bit ARMv8 CPU, available in configurations with up to 48 cores per package. ThunderX is the initial reference platform for the FreeBSD/arm64 porting effort. Additional Semihalf-sponsored work on ThunderX support brought brand new features such as: * Multi-socket operation: FreeBSD now runs on a two-node ThunderX server board with a total of 96 CPU cores! * Virtual Networking Interface Card driver: The VNIC driver consists of 4 elements (BGX, MDIO, and Physical and Virtual Functions) and is the second driver in FreeBSD to utilize SR-IOV capabilities. ThunderX is now able to use built-in networking interfaces at 1-40 Gbps. Moreover, previously introduced functionalities have been improved and committed to HEAD. This includes: * PCIe drivers for both internal and external controllers * ITS (Interrupt Translation Services) fixes * Platform-specific changes for ThunderX * Various other fixes to the kernel (PCI, UMA, etc.) The remaining features are being reviewed and will be integrated into HEAD soon. However, the GENERIC kernel already supports and runs on ThunderX. This project is sponsored by The FreeBSD Foundation, ARM Ltd., Cavium, and Semihalf. Open tasks: 1. Upstream the remaining features: 2-socket support, VNIC driver, and PCIe fixes __________________________________________________________________ FreeBSD on the HiKey ARMv8 Board Links HiKey wiki entry URL: https://wiki.FreeBSD.org/arm64/HiKey Hardware description URL: https://www.96boards.org/products/ce/hikey/ Contact: Andrew Turner The HiKey is a low-cost ARMv8 development board from the Linaro 96boards initiative. It contains a HiSilicon Kirin 6220 with eight ARMv8 cores and 1GB of ram. FreeBSD has been ported to run on the HiKey with a minimal set of drivers. As of this report, FreeBSD supports the micro-SD slot and USB host, and will boot off the SD card to multi-user mode using a recent arm64 snapshot. The kernel is missing a number of device drivers. However, it is at a usable state for people interested in testing FreeBSD on ARMv8 hardware. This project is sponsored by ABT Systems Ltd, and ARM Ltd. Open tasks: 1. A driver for SDIO and the onboard WiFi. 2. Fix the MMC driver to access the eMMC. 3. Support the USB in OTG mode. 4. Support a display via HDMI. 5. Add thermal management. __________________________________________________________________ FreeBSD/arm64 Links FreeBSD arm64 wiki page URL: https://wiki.FreeBSD.org/arm64 Contact: Andrew Turner Contact: Ed Maste Numerous cleanups and fixes have been applied to the arm64 kernel. This includes fixes to exception handling, asynchronous signals, ddb, and pmap. ddb has been updated to better handle accessing memory that may be unmapped. The pmap code was made more complete by implementing more functions as needed. Further work on SMP means that FreeBSD now boots on all 48 cores on the Cavium ThunderX platform. This includes adding support for the ARM GICv3 interrupt controllers and fixing the memory mapping to be shareable between CPUs. The test suite has been run on both qemu and hardware. Most of the test cases are passing, with around 30 tests either broken or failing. Work on diagnosing the issues with the remaining test cases is ongoing. This project is sponsored by The FreeBSD Foundation, and ABT Systems Ltd. Open tasks: 1. Port to more SoCs. __________________________________________________________________ FreeBSD/RISC-V Port Links FreeBSD wiki RISC-V URL: https://wiki.freebsd.org/riscv Single user boot log URL: https://people.freebsd.org/~br/riscv-singleuser.txt Contact: Ruslan Bukin Contact: Arun Thomas Contact: Ed Maste RISC-V is an open source Instruction Set Architecture (ISA) designed at UC Berkeley. It is freely available for all uses without requiring fees or license agreements. The RISC-V team intends to provide freely available BSD licensed CPU designs. Ruslan Bukin (University of Cambridge) now has FreeBSD booting to a single user shell on a RISC-V simulator. The porting effort started only two months ago and is very much a work in progress, requiring significant refactoring and clean up before it reaches a committable state. Nonetheless, this is exceptional progress in a short time. The porting effort also identified a number of proposed ISA improvements. The port currently uses the GNU tool chain (GCC and binutils), and runs on the Spike simulator. Improved RISC-V support in Clang/LLVM and related tools is highly desired. This project is sponsored by DARPA, AFRL. __________________________________________________________________ mandoc and roff Toolchain Links Heirloom doctools URL: https://github.com/n-t-roff/heirloom-doctools mandoc URL: http://mdocml.bsd.lv/ Contact: Baptiste Daroussin mandoc is a suite of tools for compiling mdoc, the roff macro language of choice for BSD manual pages. mandoc is the default renderer for manpages on FreeBSD head. This quarter, the apropos(1) utility was switched to use mandoc's version, which offers a new database format (in SQLite) bringing more powerful, fine-grained ways to search man pages. While mandoc is very good for man pages, we also provide lots of other documentation in plain roff format. The Heirloom toolchain is being studied to replace groff in base. The Heirloom nroff toolchain has multiple benefits: it has very good unicode support and very good compatibility with groff. A great deal of work as been done testing the Heirloom nroff toolchain with all the roff documents in the base system (including man pages), and upstream has been very proactive in fixing reported bugs. The soelim(1) utility has been replaced with a BSD-licensed version which is good enough to work with all available roff toolchains to ease the transition. This version of the soelim(1) utility, originally written solely for FreeBSD, is now part of the mandoc tool suite. In coordination with Ingo Schwarze from OpenBSD, the col(1) utility has been cleaned up and updated to recognize both SUSv2-style escape-digit and BSD-style escape-control-char sequences in the input stream. The checknr(1) utility has been cleaned up and extended to support modern roff(7) macros, including synchronizing code from NetBSD and the Heirloom doctools version. Many roff fixes were made to documentation and man pages, having been discovered while testing the new toolchain. __________________________________________________________________ pkg 1.6 Contact: FreeBSD pkg Team pkg 1.6.0 has been released. Many changes have been made since pkg 1.5: * The dependency solver is greatly improved * Lots of fixes in the three-way merge code * pkg add can now work without a version specified in the dependency line * pkg check -d now also checks the required libraries * Improved support for partial upgrades * Improved zsh completion support * Improved Linux support: all regression tests now pass on Linux * Messages can now be context-aware, showing a given message always, or only during installation, upgrade (conditional on the previous version), or removal * @keywords now accept new entries to add context-aware messages * Added the ability to generate graphiz's dot format representation of the solver's problem * pkg search now defaults to showing the pkg-comments of the matched packages * Lots of bug fixes and code cleanup * Improvements in cross-installation support Open tasks: 1. Add a notion of priority to the list of files to ensure that certain files are the first to be replaced. This was a blocker for packaging base. 2. Investigate replacing openssl by mbedtls. __________________________________________________________________ sesutil(8) Links Wikipedia: SCSI Enclosure Services (SES) URL: https://en.wikipedia.org/wiki/SCSI_Enclosure_Services Contact: Baptiste Daroussin Contact: Allan Jude sesutil(8) was originally created as a more universal way to blink the "locate" LEDs on most hot-swappable drive enclosures. This work is based on the original SES tools created by Matthew Jacob in 2000, which have been available in the share/examples section of the source tree, but were not built by default. The new utility extends the original code with a number of very useful features: * Print a map of all objects connected to the SES controller * Map device names (/dev/da5) to SES slot number * Blink the Locate and/or Fault LED of a drive by its SES slot number or device name * Check the status of the entire SES controller This project is sponsored by Gandi, and ScaleEngine Inc.. Open tasks: 1. Test sesutil(8) against more hardware. 2. Diagnose an issue where the locate command sometimes needs to be sent twice to activate the LED. 3. Add support for libxo output types. __________________________________________________________________ truss(1) Contact: John Baldwin Contact: Bryan Drewery The interface between the ABI-specific backends and the truss core was refactored, reducing duplicated code. This prompted additional follow-on work to add support for more ABIs, including aarch64 and CloudABI. ptrace(2) was extended to return more information about the currently executing system call. This restored behavior that had been present in a previous version of truss: knowing the correct number of arguments for all system calls. The fork-following support in truss was reworked to use native fork following in ptrace(2) rather than forking a new truss process for each child of a traced process. Support for decoding more arguments has been added in the last quarter as well. Open tasks: 1. Create a new libsysdecode library to hold shared code between truss(1) and kdump(1). 2. Decode more system call arguments. 3. Add appropriate system call decoding specifications for freebsd32 system calls. 4. Implement an ABI for 64-bit Linux binaries under FreeBSD/amd64. __________________________________________________________________ Updates to GDB Links Extend libkvm to support cross-debugging of vmcores URL: https://reviews.FreeBSD.org/D3341 Contact: John Baldwin Support for following children after forks for FreeBSD was implemented and merged upstream to GDB's master branch, and was included in GDB 7.10. Work has continued on porting kgdb to newer gdb. The amd64, i386, powerpc, powerpc64, and sparc64 backends have all been ported and are now available via a new KGDB option in the devel/gdb port. The MD backends for libkvm have been rewritten to support cross-debugging crashdumps, and the kgdb targets for amd64 and i386 have been reworked to support cross-debugging. Both i386 and amd64 kgdb binaries have been able to cross-debug the other architecture's vmcores with these changes. This changeset for libkvm is not yet in the tree, but is awaiting more testing. Open tasks: 1. Test the libkvm changes on platforms other than amd64, i386, and powerpc64. 2. Figure out why the powerpc kgdb targets are not able to unwind the stack past the initial frame. 3. Add support for more platforms (arm, mips, aarch64) to upstream gdb for both userland and kgdb. 4. Write a new 1:1-only thread target for FreeBSD that can be sent upstream. 5. Add support for debugging powerpc vector registers. __________________________________________________________________ Bringing GitLab into the Ports Collection Links PR for the new port URL: https://bugs.FreeBSD.org/bugzilla/show_bug.cgi?id=202468 Installation guide URL: https://github.com/t-zuehlsdorff/gitlabhq/blob/master/doc/install/installation-freebsd.md GitLab Source Tree URL: https://github.com/gitlabhq/gitlabhq/ Contact: Torsten Z?lsdorff Contact: Michael Fausten GitLab is a web-based Git repository manager with many features, used by more than 100.000 organizations, including NASA and Alibaba. It also is a very long-standing entry on the "Wanted Ports" list on the FreeBSD Wiki. In the last month there was steady progress, finally resulting in the PR for adding the new port. In addition to the many dependencies Philip M. Gollucci is working on, there was already a large amount of work done. Along with many new or updated rubygems, Rails 4.1 was resurrected. A large group of committers were involved in the process and guided us through the various problems and pitfalls. Because of the number of dependencies -- we nearly hit 100 -- making progress takes some time. In the meantime, a new major version of GitLab has already been released, requiring even more dependencies and updates. Work on this version is in progress, but the first goal is to get the latest stable version from the 7.14 branch into the ports tree. This project is sponsored by anyMOTION GRAPHICS GmbH, D?seldorf, Germany. Open tasks: 1. Closing all the PRs of the dependencies 2. Committing the GitLab port itself 3. Updating the port to the latest version of the 8.x branch __________________________________________________________________ GNOME on FreeBSD Links FreeBSD Gnome website URL: http://www.FreeBSD.org/gnome Devel repository URL: https://github.com/freebsd/freebsd-ports-gnome Upstream build bot URL: https://wiki.gnome.org/Projects/Jhbuild/FreeBSD USE_GNOME Porter's Handbook chapter URL: https://www.FreeBSD.org/doc/en_US.ISO8859-1/books/porters-handbook/using-gnome.html Contact: FreeBSD GNOME Team The FreeBSD GNOME Team maintains the GNOME, MATE, and CINNAMON desktop environments and graphical user interfaces for FreeBSD. GNOME 3 is part of the GNU Project. MATE is a fork of the GNOME 2 desktop. CINNAMON is a desktop environment using GNOME 3 technologies but with a GNOME 2 look and feel. This quarter, GNOME 3.16 and MATE 1.10 were committed to the ports tree, followed up by some incremental improvements. A chapter covering the use of USE_GNOME within individual ports' Makefiles was written and committed to the Porter's Handbook. GNOME 3.18 has been ported. There are, however, some issues that need to be resolved before it can be committed to the ports tree. Open tasks: 1. The FreeBSD GNOME website is stale. Work is under way to improve it. 2. Please give feedback on and suggest improvements to the chapter in the Porter's Handbook on the USE_GNOME functionality. 3. Continue working on investigating the issues blocking GNOME 3.18. __________________________________________________________________ KDE on FreeBSD Links KDE on FreeBSD website URL: https://freebsd.kde.org/ KDE ports staging area URL: https://freebsd.kde.org/area51.php KDE on FreeBSD wiki URL: https://wiki.FreeBSD.org/KDE KDE/FreeBSD mailing list URL: https://mail.kde.org/mailman/listinfo/kde-freebsd Development repository for integrating KDE 5 URL: http://src.mouf.net/area51/log/branches/plasma5 Contact: KDE on FreeBSD team Overall, we have updated the following ports this quarter: * CMake 3.3.1 (r396266) * Qt 4.8.7 (r397043) * QtCreator 3.5.0 (r395935) * Fixed some dependencies, typos and plists in Qt5-ports (r396044-r396047), spotted by Ralf Nolden In our development repository, we have done the following work: * Updated PyQt-bindings for qt4 to 4.11.4 and added qt5 bindings 5.5, contributed by Guido Falsi, and modified by Tobias Berner (area51) * Updated qt5 to 5.5.0. Ralf Nolden has contributed a handful of useful new ports, for example lang/qt5-l10n (area51/qt-5.5) * The plasma5 branch has been kept up to date with KDE's upstream and contains ports for Frameworks 5.14.0, Plasma Desktop 5.4.2 and Applications 15.08.1 (area51/plasma5) Open tasks: 1. Work on getting the stuff from plasma5 branch into ports. (This is a major update to nearly all KDE applications, so testers are very welcome.) 2. Finalize the work on PyQt5. 3. Port qt5-webengine. Qt-5.5 will probably be the last release shipping a www/webkit-qt5 port. __________________________________________________________________ Node.js Modules Links Node.js modules URL: https://www.assembla.com/spaces/cozycloud/subversion/source Pre-draft documentation URL: https://people.FreeBSD.org/~olivierd/porters-handbook/using-nodejs.html Contact: Olivier Duchateau Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. It uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices. The goal of this project is to make it easy to install the modules available in the npm package registry. Currently, the repository contains more than 100 new ports, in particular: * CoffeeScript (a programming language that transcompiles to JavaScript) * node-gyp (allows building Node.js addons, often written in C or C++) * Request (a simplified HTTP client) We have also written several helpers for the porting, available in our experimental repository. Open tasks: 1. Bring in grunt.js (and modules), the JavaScript task runner. 2. Put more effort into support for node-gyp in the USES framework __________________________________________________________________ Ports Collection Links Ports Collection website URL: http://www.FreeBSD.org/ports/ Contributing to the Ports Collection URL: https://www.freebsd.org/doc/en/articles/contributing/ports-contributing.html Port Monitoring service URL: http://portsmon.FreeBSD.org/index.html Team Website URL: http://www.FreeBSD.org/portmgr/index.html Blog URL: http://blogs.freebsdish.org/portmgr/ Twitter feed URL: http://www.twitter.com/freebsd_portmgr/ Facebook page URL: http://www.facebook.com/portmgr Google+ page URL: http://plus.google.com/communities/108335846196454338383 Contact: Frederic Culot Contact: FreeBSD Ports Management Team As of the end of Q3 the ports tree holds just over 25,000 ports, and the PR count is above 2,000. The summer period saw less activity on the ports tree than during the previous quarter, with fewer than 7,000 commits performed by 120 active committers. Unfortunately, the number of problem reports closed also decreased significantly, with fewer than 1,500 problem reports fixed during Q3. In Q3 several commit bits were taken in for safekeeping, following an inactivity period of more than 18 months (fluffy), or on committer's request (xmj, stefan, brix). One new developer was granted a ports commit bit (Jason Unovitch junovitch@FreeBSD.org), and one returning committer (Babak Farrokhi) had his commit bit reinstated. On the management side, no changes were made to the portmgr team during Q3. On the QA side, 25 exp-runs were performed to validate sensitive updates or cleanups. Amongst those, the noticeable changes are the update to pkg 1.6, the automake14 removal, and several important port updates such as doxygen to 1.8.10, gnome3 to 3.16, cmake to 3.3.1, and the Qt4 ports to 4.8.7. The default jdk was also set to openjdk8. Some infrastructure changes included the addition of new options helpers: opt_VARS, opt_VARS_OFF, opt_IMPLIES, and opt_PREVENTS. Some macros were also removed, such as UNIQUENAME and LATEST_LINK. Open tasks: 1. We would like to remind everyone that the ports tree is built and run by volunteers, and any help is greatly appreciated. This is more important than ever, since the number of problem reports cannot seem to stop increasing. So if you use ports or packages, please consider jumping in and helping! This is also true for existing porters: it would be great if you would consider the next step, which is to share your knowledge and mentor someone more junior with the ports tree internals. And if you already do these tasks, many thanks to you! __________________________________________________________________ Ports on PowerPC Contact: Alexey Dokuchaev The Ports Collection typically receives less attention on Tier-2 architectures than on Tier-1 architectures, although several build-runs were performed at various points in the past, and broken ports were marked as such at those times. Some of the Tier-2 platforms, such as PowerPC and ARM, have improved considerably recently, both on FreeBSD's and the compilers' sides, but as the tree is not rebuilt on the cluster very often, it was suspected that many ports are marked BROKEN while they in fact now build and run correctly. Over the past several weeks, 26 ports that were indeed broken on at least PowerPC had been fixed, 58 ports that were incorrectly marked as broken (leftovers from the old times) were marked as working, and fewer than 40 ports still have issues requiring further work. Open tasks: 1. The Ports Collection could benefit a lot from more frequent sweeps targeting Tier-2 systems. 2. Recent work on QEMU-backed emulators and the much-anticipated cross-building of ports are essential pieces to bring FreeBSD packages on par with the base system's support, architecture-wise. __________________________________________________________________ Xfce on FreeBSD Links FreeBSD Xfce Project URL: https://wiki.FreeBSD.org/Xfce FreeBSD Xfce Repository URL: https://www.assembla.com/spaces/xfce4/subversion/source Contact: FreeBSD Xfce Team Xfce is a free software desktop environment for Unix and Unix-like platforms, such as FreeBSD. It aims to be fast and lightweight, while still being visually appealing and easy to use. During this quarter, the team has kept these applications up-to-date: * science/xfce4-equake-plugin 1.3.8 * sysutils/xfce4-power-manager 1.5.2 * x11/libexo 0.10.7 * x11/xfce4-embed-plugin 1.6.0 * x11/xfce4-verve-plugin 1.1.0 * x11/xfce4-whiskermenu-plugin 1.5.1 * x11-wm/xfce4-desktop 4.12.3 * www/midori 0.5.11 We also follow the unstable releases (available in our experimental repository) of: * sysutils/xfce4-panel-switch 1.0.2 (utility to backup panel layouts) * x11/xfce4-dashboard 0.5.1 In the trunk branch, x11-wm/xfce4-panel contains a patch to support sysutils/xfce4-panel-switch (available through the panel preferences). Open tasks: 1. Test the new stable release of GLib 2.46.x with the kqueue/kevent backend enabled (it was disabled with revision r393663). Currently several features are broken, especially in Thunar, xfce4-panel, and Xfdashboard. __________________________________________________________________ PO Translation Project Links PO Translations URL: https://www.FreeBSD.org/doc/en_US.ISO8859-1/books/fdp-primer/po-translations.html German translation of the Leap Seconds article URL: https://www.FreeBSD.org/doc/de_DE.ISO8859-1/articles/leap-seconds/ Dutch translation of the Explaining BSD article URL: https://www.FreeBSD.org/doc/nl_NL.ISO8859-1/articles/explaining-bsd/ FreeBSD Translators mailing list URL: https://lists.FreeBSD.org/pipermail/freebsd-translators/ Contact: FreeBSD Documentation Team Contact: FreeBSD Translators Contact: Warren Block The FreeBSD documentation translation process has been in need of modernization for quite some time. The existing process was just too difficult for translators to keep translations up to date. With help from Benedict Reuschling, Shaun McCance, Ryan Lortie, Hiroki Sato, and many others, the availability of a new PO translation system was announced in August. PO translations handle most of the overhead of the translation process. Translators do not have to keep track of commits to the upstream English version. The actual work of translating is quicker and easier. PO editors show how much of the document has been translated. If a translation is already available for a given string, it can be easily reused. Early testing has been very successful. Most issues involve discovering and documenting the new processes rather than fixing bugs. New translations of English documents have already been committed. There will certainly be additional changes and improvements, but the system works. We will continue to discover how to share work between translation teams and the project as a whole. This work will be much easier now that the initial hurdle of being able to use PO software has been passed. Open tasks: 1. Continue testing. The system is new to us and there are bound to be bugs and situations with unexpected results. 2. Improve documentation on using the new PO translations. Much of this involves things that rarely happened with the old system, like adding a completely new language directory. 3. Add new translations for existing documents. There is much less work to create and update a translated document now. Existing and new translators are working on adding and updating translations of the English documentation. 4. Figure out how to generate and share translation memory with other members of a language team or translators outside the team. 5. Test new PO editors like Pootle and Virtaal. 6. Determine a method to allow translators commit access for translations. 7. Develop and test code to translate manual pages. __________________________________________________________________ Website CSS Update Links FreeBSD Main Site URL: https://www.FreeBSD.org/ Contact: Warren Block The FreeBSD website has remained essentially unchanged in appearance for many years. Like other legacy systems, it is difficult to change. It is heavily used and therefore subject to non-trivial bikeshedding. The CSS shrunk the reader's font from the size they had requested. It specified hardcoded font and object sizes in pixels. On wide monitors, only the middle third of the screen was used. Hardware has changed from what existed when this version of the site was created. Screens have become larger and wider, and increased in resolution at the same time. It was time for a change. Font sizes were set to percentages, with none smaller than 100%. The width of the main box was changed to 90%. Other small adjustments were added. These limited changes produced a rendered site that better respects the reader's settings, is much easier to read, and shows more information. Although no content changed, the appearance was so different that some viewers thought we had redesigned the site. It is gratifying to know that so many people are using it. We would also like to thank people for the response, which was overwhelmingly positive and hardly bikesheddy at all. Open tasks: 1. Fix other outdated assumptions in the CSS. Alternately, rework the entire site. However, that is a much more complex and ambitious project than it might seem. __________________________________________________________________ Allwinner A10/A20 Support Links Wiki page URL: https://wiki.FreeBSD.org/FreeBSD/arm/Allwinner Contact: Luiz Otavio O Souza Contact: Pratik Singhal The Allwinner A10 and A20 chips are ARM CPUs found in increasingly common development boards and other devices, such as the Cubieboard/Cubieboard 2 and the Banana Pi. With the end of a GSoC project by Pratik Singhal, our A10 and A20 support has improved. Pratik helped with the implementation and testing of the SD card and SATA support for the Allwinner chips. Luiz Otavio O Souza added support for the dwc network interface on the A20, which is capable of gigabit speeds. Glen Barber kindly added support for official FreeBSD images for Cubieboard 2 and the Banana Pi. This project is sponsored by Google Summer of Code 2015 (partly). Open tasks: 1. Some drivers are still missing: audio, video/HDMI/framebuffer, IR, I2C, SPI, PWM. 2. Fix if_dwc for better performance. __________________________________________________________________ mtree Parsing and Manipulation Library Links Wiki page URL: https://wiki.FreeBSD.org/SummerOfCode2015/mtreeParsingLibrary Contact: Michal Ratajsky Contact: Brooks Davis FreeBSD includes several programs that work with file system hierarchy descriptions in the mtree(5) format. These descriptions, also called specifications, have a broad range of uses, from automatically creating directory structures to security auditing. Each of the programs, namely mtree, bsdtar, install, and makefs, has its own implementation of the mtree format. This not only adds maintenance overhead, but also makes interoperability difficult, as each of the implementations only supports a limited subset of the format. The goal of this project was to create a new libmtree library, implementing everything the mtree format has to offer, and wrapping it with an expressive API which all the listed programs can use. We also wanted libmtree to be portable, as one of the major users of the mtree format is libarchive, the library implementing most of bsdtar. Currently, the library is functionally complete, ready to be downloaded and receive everyone's attention. We have also decided to bundle the mtree program along with it. The bundled mtree has also been modified for better portability. The project included modifying libarchive, install and makefs to use libmtree. These modified versions are also available. Please see the Wiki page for more information, download locations, and an example of using the libmtree API. This project is sponsored by Google Summer of Code 2015. Open tasks: 1. Test and review the library code and API, and the modifications made to the programs. 2. Fix the known problems that are mentioned on the Wiki page. __________________________________________________________________ Multiqueue Testing Links Project Wiki Page URL: https://wiki.FreeBSD.org/SummerOfCode2015/MultiqueueTestingProject Contact: Tiwei Bie Contact: Hiren Panchasara Contact: George Neville-Neil Contact: Robert Watson The aim of this project is to design and implement infrastructure to validate that a number of the network stack's multiqueue behaviours are functioning as expected. At present, most of this project has been implemented. It mainly consists of two parts: 1. A general mechanism to collect the per-ring per-cpu statistics that can be used by all NIC drivers, and extensions to netstat(1) to report these statistics. 2. A suite of network stack behavior testing programs that consists of: + a virtual multiqueue ethernet interface (vme) + a UDP packet generator based on vme + a UDP server based on socket(2) + a TCP client based on lwip and vme + a TCP server based on socket(2) However, it still needs further refinements to make it suitable for committing to FreeBSD head. This project is sponsored by Google Summer of Code 2015. __________________________________________________________________ Update Ficl in Bootloader Links Wiki Page URL: https://wiki.FreeBSD.org/SummerOfCode2015/UpdateFiclInBootloader Contact: Colin Lord The FreeBSD bootloader has used Ficl 3 for quite some time. This project was intended to update the version of Ficl in use to Ficl 4. Ficl 4 is not only faster but also has a smaller memory footprint, both being important advantages for a bootloader. As part of the Google Summer of Code program, I worked on importing the Ficl 4 sources to get a bootloader running Ficl 4. The first half of the summer consisted of setting up my test environment, as well as arranging the sources in the tree properly and modifying the build files to point to the new locations. Once that was complete, the sources had to be modified to build correctly and to add back in some of the FreeBSD-specific parts from Ficl 3. Unfortunately, after all those tasks were completed, a few bugs in the Ficl project were discovered that delayed the bootloader update, so it is not finished. The Illumos project has faced similar issues with Ficl 4 so I received some good tips from them, but since school has started back up I have not been able to put much work into fixing the bugs. This project is sponsored by Google Summer of Code 2015. __________________________________________________________________ The FreeBSD Foundation Links Foundation website URL: http://www.FreeBSDFoundation.org/ FreeBSD Journal URL: http://freebsdjournal.com/ Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Funding comes from individual and corporate donations and is used to fund and manage development projects, conferences and developer summits, and provide travel grants to FreeBSD developers. The Foundation purchases hardware to improve and maintain FreeBSD infrastructure and publishes FreeBSD white papers and marketing material to promote, educate, and advocate for the FreeBSD Project. The Foundation also represents the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity. Here are some highlights of what we did to help FreeBSD last quarter: Anne Dickison and Deb Goodkin attended OSCON to promote FreeBSD. Robert Watson organized and ran the Cambridge FreeBSD Developer Summit 2015 ("BSDCam"). We provided travel grants to two FreeBSD developers to attend the summit. Three Foundation board/staff members attended too. George V. Neville-Neil attended the ARM Partner Meeting where he met with 15 silicon and systems vendors to present the unique traits and qualities of FreeBSD and work on setting up partnerships with the companies building and deploying ARM hardware. George and Robert Watson collaborated in Cambridge on developing further FreeBSD-based teaching material at undergraduate and masters levels. Part of this project was funded by the Foundation. George planned and ran the DevSummit at vBSDCon 2015. We were proud to be a sponsor of vBSDCon 2015, Sept 11-13 in Washington DC. George V. Neville-Neil and Ed Maste presented "Supporting a BSD Project" at the conference. Dru Lavigne, Glen Barber, George V. Neville-Neil, and Ed Maste attended and represented the Foundation at both vBSDCon and the FreeBSD Developer Summit that preceded it. We had many people stop by our table to make a donation, and it was another great opportunity to talk and work with people face-to-face. Cheryl Blain and John Baldwin promoted the Foundation and FreeBSD at the SNIA 2015 Storage Developer Conference, in Santa Clara, California, Sept 21-24. The Foundation was also a sponsor. We sponsored Andy Turner to attend Linaro Connect in San Francisco, Sept 21-25. Ed Maste, our project development director, attended the X.Org Developer's Conference (XDC) in Toronto, Ontario. We sponsored the 2015 nginx Conference and sent FreeBSD community member John Baldwin. George Neville-Neil continued planning the 2015 Silicon Valley Vendor Summit, including securing the venue. Benedict Reuschling and Erwin Lansing helped plan and organize the EuroBSDCon FreeBSD Developer Summit. This included setting up the working groups, securing the venue, and getting the T-shirts made. Benedict helped organize, and he and Dru Lavigne participated in the FreeBSD Hackathon in the Linuxhotel in Essen, Germany. It was a successful weekend of fixing bugs and collaborating with others. Dru Lavigne taught a FreeBSD class in Berlin, Germany July 29-31. We were a sponsor of womENcourage 2015, in Uppsala Sweden, Sept 24-26. Dru was the moderator for a panel on Open Source as a Career Path. All the panelists were FreeBSD contributors including Dan Langille, Allan Jude, Benedict Reuschling, and Deb Goodkin. We also had a table at the job fair and talked to a lot of students and professors about the benefits of working on FreeBSD as an alternative to an internship, teaching about FreeBSD in university classes, and hosting FreeBSD events at their schools. Dan taught a workshop on How to Contribute to an Open Source project. Deb participated in this workshop and started a discussion on offering a similar workshop at BSD and non-BSD conferences. The workshop would be titled "How to Contribute to FreeBSD", and participants would learn how to contribute documentation to the Project. We continued to publish our monthly newsletters, keeping the community informed on what we are doing, including event recaps, testimonials, project updates, and upcoming events. We received testimonials from Microsoft, NYCBus, and ScaleEngine. We also continued to approach companies to provide us with testimonials to help promote their use of FreeBSD. Anne Dickison rebooted the Faces of FreeBSD series and is working with FreeBSD contributors on writing their stories. She continued to produce more FreeBSD Swag and literature to promote FreeBSD, as well as advocating for FreeBSD over our social channels and with new partnerships. We reached our 2015 goal of 10,000 FreeBSD Journal subscribers, and we published a new Open Journal article on our website, to help promote the Journal. We also started offering a new subscription bundle, where you can buy all the 2014 issues. The July/August issue was published. Justin T. Gibbs began teaching a semester-long FreeBSD class at a middle school in Boulder, Colorado. We are using the BeagleBone Black (BBB) to run FreeBSD connected to Macs and PCs. We have received a lot of support, both internally, and from the Project, to get the FreeBSD images to work on the BBB with the Macs and PCs. It has been a great collaborative effort with community members, and this will help future classes in being able to support inexpensive platforms for teaching FreeBSD. Work continued on creating a FreeBSD curriculum for a half day workshop. Hopefully this will be available in late Spring. We provided legal support for the Project including granting trademark permission for some users and companies who requested permission to put the FreeBSD logo on their websites and marketing literature. We met with commercial users to get their input on what they would like to see supported in FreeBSD. We also do this to help connect FreeBSD developers with commercial users to help facilitate collaboration. FreeBSD Foundation employee and Release Engineer Glen Barber was extremely busy during this quarter, working on a number of exciting areas of the FreeBSD Project. Some of the highlights include: * Code cleanup and bug fixes to several parts of the release build code, and finishing adding support for automatically uploading cloud provider images, which was merged to the stable/10 branch before the code freeze. The 10.2-RELEASE cycle spanned a 9-week timeframe overall, starting from the code slush. * With the FreeBSD Release Engineering Team, released two BETA builds and three RC builds for the 10.2-RELEASE cycle, with the final release announced mid-August, two weeks ahead of the original schedule. * With the FreeBSD Cluster Administrators Team, assisted with a number of general updates and enhancements to the FreeBSD infrastructure. __________________________________________________________________ ZFSguru Links Home page URL: http://zfsguru.com Forum post on Gnome 3 debugging URL: http://zfsguru.com/forum/zfsgurudevelopment/1038 Contact: Jason Edwards ZFSguru started as a front-end to ZFS but has since grown into a multifunctional server appliance with its own unique features. While the project is still in early development, it already offers multiple unique features not found in other projects. Unlike similar projects, nothing is stripped away from the base operating system, meaning ZFSguru behaves as a normal FreeBSD installation and thus is very versatile. The web-interface is designed to unite both novice and advanced users, providing both very easy to use basic functionality as well as features to be appreciated by more experienced users. The modular nature of the project combats the danger of bloat, whilst still allowing extended functionality to be easily deployed. On the 15th of August, version 0.3 of ZFSguru was released. Some highlights of the new version: * New build infrastructure allows for frequent releases of system images and services in a semi-automated way. * A new GuruDB database allows for a growing number of system images and servers, and provides good caching to accelerate pages. * The installation procedure was given a major overhaul. * In addition to the LiveCD, USB images are now available. The USB image supports both legacy MBR bootcode and UEFI boot. * Many libraries in the web-interface have been overhauled, in addition to many other additions to the web interface. * Many improvements were made to optional add-on services, such as the new Gnome 3 graphical environment. Other progress made in the months July, August, and September: * System image builds 001, 002, 003, and 004 have been released for all supported branches: 10.0, 10.1, 10.2, 10.3 (-STABLE), and 11.0 (-CURRENT). * Work on the 0.4 web-interface has started, which focuses on improving network support in the web-interface. * Work on a new visual theme for the web-interface has started. The new interface is likely to be included in the upcoming 0.4 release. * A new master server is being prepared, which is likely to be operational in December. * A new website is being worked on, to be launched the first of January, 2016. Open tasks: 1. The new Gnome 3 desktop does not work for everyone and still has issues. Anyone capable of diagnosing these issues can give the Gnome 3 LiveCD a try. Please see the linked forum thread for more information. 2. Several ports fail to compile with our own build infrastructure, and require bug reports in order to get them fixed upstream. 3. A 'State of the Project 2015' is due in Q4, providing an overview for future development of the project. __________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGgBAEBCgAGBQJWLZXJAAoJECjZpvNk63US9QkMIIp+DgtLqA1bt02ldMvtOQi8 UX2TkKTHJrJLtSl5Iv5JUJ9IaZR1gYRkTYS0vINCOMXwTsp3y+xb6ESiR5H0iJRF Jnw5gy8HBi8ZY+MLasFG/KdYTcIUVcfUxloak96FFDOA23ru+LWy4t8YxMMiBIde xnebJXxoKo1RxCePbbAyS6vri/jvP9KZth8rE0V8CgUbFo3IuROMrvYS7jVhzhrL yOJn2vER6LXEM8j11c8RYMNOtSrwCLrO2CI5u2frTAvPXEXPLx4WSX/Gw0R3mVS/ l12bjBK3i89q2XWiiglbXiMxK3JBHKtIZZowHwHCCwhgd2cxEHiP3XaKFtxFlQ1c Isk4hHp/rbzozdG6HX9m52Qg90ieQXjcCoJ46apV50VLK4eSe+WdD1/mhC8VE7GU o3Ako+zJlUnW9SKY82YG2ENQFqa2/CPEDM6N/l7cFqD9ixaNLWBjR1fJ3b2cvKiS m3nbMHPeJnNTMo83l9RNoZm0jGvNLikW+f47yjuoTXbFb54= =0xZT -----END PGP SIGNATURE----- From owner-freebsd-current@freebsd.org Mon Oct 26 08:27:57 2015 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 51563846D for ; Mon, 26 Oct 2015 08:27:57 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 172011E9F for ; Mon, 26 Oct 2015 08:27:57 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:3c23:bcdc:5292:fa5f]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 7A9832D68; Mon, 26 Oct 2015 11:27:48 +0300 (MSK) Date: Mon, 26 Oct 2015 11:27:45 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1648746569.20151026112745@serebryakov.spb.ru> To: NGie Cooper CC: freebsd-current Subject: Re: What changed in rc.d infrastructure in last months? In-Reply-To: <731AEB43-6519-4FC4-A115-E45FCFAE8F72@gmail.com> References: <16610120144.20151025222025@serebryakov.spb.ru> <28FF29D6-A2D9-46C0-A419-DB433BB9F54A@gmail.com> <606144753.20151025224636@serebryakov.spb.ru> <562C2E44-DA31-450F-B867-607047697EFE@gmail.com> <731AEB43-6519-4FC4-A115-E45FCFAE8F72@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 26 Oct 2015 08:27:57 -0000 Hello NGie, Sunday, October 25, 2015, 11:09:03 PM, you wrote: > Ok, this is really not making sense from a design perspective. > `ifconfig_` is being overloaded for starting up hostap=E2=80=99s (ev= en though > ifconfig itself doesn=E2=80=99t support hostap =E2=80=94 only `wlanmode a= p`). I don=E2=80=99t ifconfig doesn't support dhcp either, but dhclient is run via "DHCP" in `ficonfig_` > understand why it was done this way instead of just creating additional > variables for `hostapd_` Long time ago there was simple `hostapd_enable` and `hostapd_interfaces` :) But it doesn't allow to automagically start hostapd for hotplugged (i.e. USB) interfaces. On the other hand, automatic DHCP on hot-plugged interfaces have sense and automatic hostapd doesn't, IMHO. --=20 Best regards, Lev mailto:lev@FreeBSD.org From owner-freebsd-current@freebsd.org Mon Oct 26 08:33:33 2015 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 0F9E48618 for ; Mon, 26 Oct 2015 08:33:33 +0000 (UTC) (envelope-from mueller6724@bellsouth.net) Received: from nm9-vm1.access.bullet.mail.gq1.yahoo.com (nm9-vm1.access.bullet.mail.gq1.yahoo.com [216.39.63.7]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D02FF11E1 for ; Mon, 26 Oct 2015 08:33:32 +0000 (UTC) (envelope-from mueller6724@bellsouth.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s2048; t=1445848285; bh=pN0wlvHW8N/in87cik1gXGIIiwJ4EKrocCaPo565wGY=; h=Date:From:To:Subject:References:From:Subject; b=tTPnfS6nj7I6i7iTVpQj5Y5YeIFihtbXvh0r0ejv8nPvdAmpTP8xzTQX8yohjEMiSMmNHUBgqYvoI+ZAnJVmVkrEEi3ij8Ba/ogNyOu+Z4PXzBhbNA2VS898DnrwdAGrJnJk7Rggfb1BFQQmrPl/qEhxxUIGYSLMGxMIzwEP5uXHgPSisLY79jT8vSGJ6L4DXt/MNtNsE5CT2bjLt4xHMMct9xzs5jOcr6fq2/EFinrJntx19z3ijlu8ePIKDZWmoEtH9GgxCWk7DpJw/FZPRKqEaMo2mMk4u3WJqtIaaJdYE7sDzMMbjkXNAGCHb8O8f5aEh44YbxS5wTsEfzWatg== Received: from [216.39.60.167] by nm9.access.bullet.mail.gq1.yahoo.com with NNFMP; 26 Oct 2015 08:31:25 -0000 Received: from [98.138.226.243] by tm3.access.bullet.mail.gq1.yahoo.com with NNFMP; 26 Oct 2015 08:31:25 -0000 Received: from [127.0.0.1] by smtp114.sbc.mail.ne1.yahoo.com with NNFMP; 26 Oct 2015 08:31:24 -0000 X-Yahoo-Newman-Id: 969071.89813.bm@smtp114.sbc.mail.ne1.yahoo.com Message-ID: <969071.89813.bm@smtp114.sbc.mail.ne1.yahoo.com> X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: gwjJkKQVM1lkBAz.OlyY1IQiUdZA2d1HJyjO0DRtJDb9Efo qm9K_xLca0_VtlDON5B0JegRpyvcR4hOnIYfhmGKG05vayYDMwcq4iP0bHqf mxPl8knuBzuYgpI3zPi0X.85rU86vLZR73S.iBqEyDPC2bQd2miTqTE9eOkH Lrb3b4qfhNjffPw.ytkBEP2Ja32OKgzwSBQ3UzKiMyRrqvRTIeKYRjVUnNI5 1hU5src744f094zksoLQ8OC60gKcf6SWBRUKJCq.IjBBq1VgPkUn3R3aNDde rqyndxOVbE5rzU3znC9tLCOQVLNAfvineH3Dhp2yslLC8hKML7qg6F4JXevt 10ArIUrH.4X8xJz8ixhw3SA41a6s2f.SOT.H7.vCMMGs0gzPUwlWsqdKTFIz veddldjHr.oxUVQ4hE3GtI05W7ZU_JPfBhGw80jBuG.0RITuHoEI5zmJy68H BpINDXKDpRU_Sy4SogonY8hATcEgFzGrxRdHkgMEhQeGipNncuAAp5YY1UkA o_rdbvG.amvOgGZPvvNCOIck85YQHGXi1ziHtd0NI_oQbjv7ozRXdKSJdXuQ - X-Yahoo-SMTP: Kz_aW1.swBBYof3zAD7.RWzXz9ZAQVDMml1VADsbgPT4Kq79LC0- Date: Mon, 26 Oct 2015 08:30:53 +0000 From: "Thomas Mueller" To: freebsd-current@freebsd.org Subject: Re: Make installworld fails on file not found (Error code 71) References: <559603.75995.bm@smtp120.sbc.mail.ne1.yahoo.com> <562955A1.3080103@FreeBSD.org> <56296371.7070607@FreeBSD.org> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 26 Oct 2015 08:33:33 -0000 > > It looks like a problem with WITHOUT_MANCOMPRESS. > > I am looking into it. > A fix is now committed. It has been broken since June. > Regards, > Bryan Drewery Thanks for the fix, computer is now busy with NetBSD update from 6.99.44 (16 months old) to 7.99.21 for both amd64 and i386, but I intend to get back to the FreeBSD update after that is done. I checked /etc/src.conf and found WITHOUT_MANCOMPRESS=yes WITHOUT_DOCCOMPRESS=yes I looked in other directions for the problem and would have just been wasting time and computer energy. Compressed man pages can be a nuisance, and not really necessary or helpful with today's big hard drives and USB sticks. Good I was able to expose a bug of four months' standing. UPDATE: buildworld succeeded, but installworld crashed to the debugger prompt: Fatal trap 12: page fault while in kernel mode Reboot attempt, both with custom kernel and GENERIB, failed: /libc/libc.so.7: version FBSD_1.3 required by /bin/sh not defined GENERIB is kernel config derived from GENERIC but with some outdated devices unlikely to be found on a modern computer system removed, and some wireless drivers including rsu added. So now that FreeBSD installation is not bootable. I ran fsck_ffs -y /dev/dk9 from NetBSD 7.99.21 (current) i386, /dev/dk9 being NetBSD's version of the FreeBSD partition name. I can say "make installworld" likely failed because, after interrupted (crashed) installworld, userland was out of sync. I have another FreeBSD partition, 10.1-STABLE amd64, dating to January 29, 2015, could boot into that and try to update both that (10.2-STABLE) and the messed-up FreeBSD-current installation (with HEAD/current). MicroNet Fantom external hard drives, 1 TB to 5 TB, USB 3.0 and eSATA, look attractive now, back up a whole OS installation, eSATA figures to work better than USB 3.0: better for FreeBSD and NetBSD, and better recognition at boot time by motherboard/BIOS/UEFI. Tom From owner-freebsd-current@freebsd.org Mon Oct 26 09:10:01 2015 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 C76788FF6 for ; Mon, 26 Oct 2015 09:10:01 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8FAE91115 for ; Mon, 26 Oct 2015 09:10:01 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 667EF1FE023 for ; Mon, 26 Oct 2015 10:09:59 +0100 (CET) To: FreeBSD Current From: Hans Petter Selasky Subject: Quick test building a module cross all targets and architectures Message-ID: <562DEE4F.5010203@selasky.org> Date: Mon, 26 Oct 2015 10:11:43 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 26 Oct 2015 09:10:01 -0000 Hi, We have NO_MODULES for building kernel without modules, but no NO_KERNEL to only build the modules. What do you think about the following patch: > diff --git a/sys/conf/kern.post.mk b/sys/conf/kern.post.mk > index ddf828e..f0920df 100644 > --- a/sys/conf/kern.post.mk > +++ b/sys/conf/kern.post.mk > @@ -32,7 +32,11 @@ KERN_DEBUGDIR?= ${DEBUGDIR} > > .for target in all clean cleandepend cleandir clobber depend install \ > obj reinstall tags > +.if !defined(NO_KERNEL) > ${target}: kernel-${target} > +.else > +${target}: > +.endif > .if !defined(MODULES_WITH_WORLD) && !defined(NO_MODULES) && exists($S/modules) > ${target}: modules-${target} > modules-${target}: It allows only a single module with MODULES_OVERRIDE= and NO_KERNEL=YES to be built with universe in very little time. This can save a lot of build time when changes are limited to a set of kernel modules. --HPS From owner-freebsd-current@freebsd.org Mon Oct 26 11:38:23 2015 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 23D04A19807 for ; Mon, 26 Oct 2015 11:38:23 +0000 (UTC) (envelope-from adrian.chadd@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 E26C41125; Mon, 26 Oct 2015 11:38:22 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igdg1 with SMTP id g1so56271517igd.1; Mon, 26 Oct 2015 04:38:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=QRU2bbK7tbfW1novfP2I1JbgUn31LaGzrbvVAGCGU+g=; b=f1dHv3dA9GeuRJWQRXGQ/02pvV0nA9JSh8cyKcbrjLuIdlhmpDnuf92THljl3Easka 4MZ/FsURIe6X+SgHT2SOyrb7jKPUkWjNBbUGGvT/4ryMMmVEvaG9mrvEOBNRTGxKcJMe b2D1V3MpygoNMx1wu6ngoCMbypRvK7Ej6W0IDa8KcTD2kyMmqwbLqoDnfjAUKH2TudRC qm2CC79adsnGWiiE150qrEK7g9CKbsGfGeTwbfxrqmbVLLQ6UNuKfV0yATpRBgiZ2RNV kdnO83XBug11C03tapG8MVIl7Lc/VvNKuDYtnymWY1zFecU99TNEpuDwYfiU6YaIFlKl XQfQ== MIME-Version: 1.0 X-Received: by 10.50.155.41 with SMTP id vt9mr9291498igb.22.1445859501951; Mon, 26 Oct 2015 04:38:21 -0700 (PDT) Received: by 10.36.46.66 with HTTP; Mon, 26 Oct 2015 04:38:21 -0700 (PDT) In-Reply-To: <1648746569.20151026112745@serebryakov.spb.ru> References: <16610120144.20151025222025@serebryakov.spb.ru> <28FF29D6-A2D9-46C0-A419-DB433BB9F54A@gmail.com> <606144753.20151025224636@serebryakov.spb.ru> <562C2E44-DA31-450F-B867-607047697EFE@gmail.com> <731AEB43-6519-4FC4-A115-E45FCFAE8F72@gmail.com> <1648746569.20151026112745@serebryakov.spb.ru> Date: Mon, 26 Oct 2015 04:38:21 -0700 Message-ID: Subject: Re: What changed in rc.d infrastructure in last months? From: Adrian Chadd To: Lev Serebryakov Cc: NGie Cooper , freebsd-current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 26 Oct 2015 11:38:23 -0000 On 26 October 2015 at 01:27, Lev Serebryakov wrote: > Hello NGie, > > Sunday, October 25, 2015, 11:09:03 PM, you wrote: > > >> Ok, this is really not making sense from a design perspective. >> `ifconfig_` is being overloaded for starting up hostap=E2=80=99s (e= ven though >> ifconfig itself doesn=E2=80=99t support hostap =E2=80=94 only `wlanmode = ap`). I don=E2=80=99t > ifconfig doesn't support dhcp either, but dhclient is run via "DHCP" in > `ficonfig_` > >> understand why it was done this way instead of just creating additional >> variables for `hostapd_` > Long time ago there was simple `hostapd_enable` and `hostapd_interfaces`= :) > But it doesn't allow to automagically start hostapd for hotplugged (i.e. > USB) interfaces. On the other hand, automatic DHCP on hot-plugged > interfaces have sense and automatic hostapd doesn't, IMHO. This sounds like the same issue as double-running wpa_supplicant. I thought this was fixed already :( Would someone please figure out a cleanish solution to this? I'd really appreciate it. -a From owner-freebsd-current@freebsd.org Mon Oct 26 11:38:44 2015 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 02842A19841 for ; Mon, 26 Oct 2015 11:38:44 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (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 C5630122E for ; Mon, 26 Oct 2015 11:38:43 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igbdj2 with SMTP id dj2so53871439igb.1 for ; Mon, 26 Oct 2015 04:38:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8le9n+jfpJXYYt4RAmBOQd79QmYmea6cAIFwbzDKGUY=; b=vYlOP/2eZSt/xktmNQ2rSwFcOABgEV7G8vRORNnG9McY6/l4nswkHacmzpVDtW1C3x 2Q6ir8HnfB6WVaWcz77HgKp7PoeG3G6ElpwGQq/ucAzqRh70Lb/HhLaBCbxXqT29WolR cb2XlPlRr8kfrbNiQERUd+Mhalg9wjD2kuCG6ZLF6WKqMpWJtCut7Hi6EFSLBZgPxa0h H7QO341wN8/Jwuw8dm9lGrOfCSfD9wrgIfI0BXr7AOqH+1kc7ZYLTqWVnR48EHHyOyQn 8mZnC+IjsUw7Bs6QKMtLONU71sbx4LidHoRYACFqOFqRTBZhYxnd3LfcoKqR1V1K4nhs aHEQ== MIME-Version: 1.0 X-Received: by 10.50.111.226 with SMTP id il2mr16812364igb.61.1445859523204; Mon, 26 Oct 2015 04:38:43 -0700 (PDT) Received: by 10.36.46.66 with HTTP; Mon, 26 Oct 2015 04:38:43 -0700 (PDT) In-Reply-To: <562DEE4F.5010203@selasky.org> References: <562DEE4F.5010203@selasky.org> Date: Mon, 26 Oct 2015 04:38:43 -0700 Message-ID: Subject: Re: Quick test building a module cross all targets and architectures From: Adrian Chadd To: Hans Petter Selasky Cc: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 26 Oct 2015 11:38:44 -0000 +1 to this thankyou! -adrian On 26 October 2015 at 02:11, Hans Petter Selasky wrote: > Hi, > > We have NO_MODULES for building kernel without modules, but no NO_KERNEL to > only build the modules. > > What do you think about the following patch: > >> diff --git a/sys/conf/kern.post.mk b/sys/conf/kern.post.mk >> index ddf828e..f0920df 100644 >> --- a/sys/conf/kern.post.mk >> +++ b/sys/conf/kern.post.mk >> @@ -32,7 +32,11 @@ KERN_DEBUGDIR?= ${DEBUGDIR} >> >> .for target in all clean cleandepend cleandir clobber depend install \ >> obj reinstall tags >> +.if !defined(NO_KERNEL) >> ${target}: kernel-${target} >> +.else >> +${target}: >> +.endif >> .if !defined(MODULES_WITH_WORLD) && !defined(NO_MODULES) && >> exists($S/modules) >> ${target}: modules-${target} >> modules-${target}: > > > It allows only a single module with MODULES_OVERRIDE= and NO_KERNEL=YES to > be built with universe in very little time. This can save a lot of build > time when changes are limited to a set of kernel modules. > > --HPS > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Mon Oct 26 18:04:02 2015 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 BE4D184F1 for ; Mon, 26 Oct 2015 18:04:02 +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 9CBB3178D for ; Mon, 26 Oct 2015 18:04:02 +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 9D56EB918; Mon, 26 Oct 2015 14:04:01 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Cc: Hans Petter Selasky Subject: Re: Quick test building a module cross all targets and architectures Date: Mon, 26 Oct 2015 11:03:07 -0700 Message-ID: <5888922.UHSgpdyTWY@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-PRERELEASE; KDE/4.14.3; amd64; ; ) In-Reply-To: <562DEE4F.5010203@selasky.org> References: <562DEE4F.5010203@selasky.org> 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, 26 Oct 2015 14:04:01 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 26 Oct 2015 18:04:02 -0000 On Monday, October 26, 2015 10:11:43 AM Hans Petter Selasky wrote: > Hi, > > We have NO_MODULES for building kernel without modules, but no NO_KERNEL > to only build the modules. > > What do you think about the following patch: > > > diff --git a/sys/conf/kern.post.mk b/sys/conf/kern.post.mk > > index ddf828e..f0920df 100644 > > --- a/sys/conf/kern.post.mk > > +++ b/sys/conf/kern.post.mk > > @@ -32,7 +32,11 @@ KERN_DEBUGDIR?= ${DEBUGDIR} > > > > .for target in all clean cleandepend cleandir clobber depend install \ > > obj reinstall tags > > +.if !defined(NO_KERNEL) > > ${target}: kernel-${target} > > +.else > > +${target}: > > +.endif > > .if !defined(MODULES_WITH_WORLD) && !defined(NO_MODULES) && exists($S/modules) > > ${target}: modules-${target} > > modules-${target}: > > It allows only a single module with MODULES_OVERRIDE= and NO_KERNEL=YES > to be built with universe in very little time. This can save a lot of > build time when changes are limited to a set of kernel modules. Can you just use something like MODULES_WITH_WORLD instead? make tinderbox MAKE_JUST_WORLDS=yes SUBDIR_OVERRIDE=sys/modules MODULES_OVERRIDE=foo (If it's only 1 module directory you can probably just use SUBDIR_OVERRIDE directly?) make tinderbox MAKE_JUST_WORLDS=yes SUBDIR_OVERRIDE=sys/modules/foo -- John Baldwin From owner-freebsd-current@freebsd.org Mon Oct 26 18:04:03 2015 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 E7EA884F9 for ; Mon, 26 Oct 2015 18:04:03 +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 C34E41790; Mon, 26 Oct 2015 18:04:03 +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 D43A3B94A; Mon, 26 Oct 2015 14:04:02 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Cc: Adrian Chadd , Lev Serebryakov , NGie Cooper Subject: Re: What changed in rc.d infrastructure in last months? Date: Mon, 26 Oct 2015 10:58:12 -0700 Message-ID: <10965004.5DFcuHMnDm@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-PRERELEASE; KDE/4.14.3; amd64; ; ) In-Reply-To: References: <16610120144.20151025222025@serebryakov.spb.ru> <1648746569.20151026112745@serebryakov.spb.ru> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 26 Oct 2015 14:04:02 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 26 Oct 2015 18:04:04 -0000 On Monday, October 26, 2015 04:38:21 AM Adrian Chadd wrote: > On 26 October 2015 at 01:27, Lev Serebryakov wrote:= > > Hello NGie, > > > > Sunday, October 25, 2015, 11:09:03 PM, you wrote: > > > > > >> Ok, this is really not making sense from a design perspective. > >> `ifconfig_` is being overloaded for starting up hostap=E2=80=99= s (even though > >> ifconfig itself doesn=E2=80=99t support hostap =E2=80=94 only `wla= nmode ap`). I don=E2=80=99t > > ifconfig doesn't support dhcp either, but dhclient is run via "DHC= P" in > > `ficonfig_` > > > >> understand why it was done this way instead of just creating addit= ional > >> variables for `hostapd_` > > Long time ago there was simple `hostapd_enable` and `hostapd_inter= faces` :) > > But it doesn't allow to automagically start hostapd for hotplugged= (i.e. > > USB) interfaces. On the other hand, automatic DHCP on hot-plugged > > interfaces have sense and automatic hostapd doesn't, IMHO. >=20 > This sounds like the same issue as double-running wpa_supplicant. >=20 > I thought this was fixed already :( Would someone please figure out a= > cleanish solution to this? I'd really appreciate it. Note that /etc/pccard_ether bails right away if the interface is marked= up without doing anything. That is what is supposed to make devd events a= t boot get ignored. (See the initial loop in pccard_ether_start().) --=20 John Baldwin From owner-freebsd-current@freebsd.org Mon Oct 26 18:23:54 2015 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 ABB9C8B8B for ; Mon, 26 Oct 2015 18:23:54 +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 266381474 for ; Mon, 26 Oct 2015 18:23:53 +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 t9QINmqU091281 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 26 Oct 2015 20:23:48 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua t9QINmqU091281 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id t9QINmhm091280; Mon, 26 Oct 2015 20:23:48 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 26 Oct 2015 20:23:48 +0200 From: Konstantin Belousov To: Hans Petter Selasky Cc: freebsd-current@freebsd.org Subject: Re: Quick test building a module cross all targets and architectures Message-ID: <20151026182348.GT2257@kib.kiev.ua> References: <562DEE4F.5010203@selasky.org> <5888922.UHSgpdyTWY@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5888922.UHSgpdyTWY@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.20 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, 26 Oct 2015 18:23:54 -0000 On Mon, Oct 26, 2015 at 11:03:07AM -0700, John Baldwin wrote: > On Monday, October 26, 2015 10:11:43 AM Hans Petter Selasky wrote: > > Hi, > > > > We have NO_MODULES for building kernel without modules, but no NO_KERNEL > > to only build the modules. > > > > What do you think about the following patch: > > > > > diff --git a/sys/conf/kern.post.mk b/sys/conf/kern.post.mk > > > index ddf828e..f0920df 100644 > > > --- a/sys/conf/kern.post.mk > > > +++ b/sys/conf/kern.post.mk > > > @@ -32,7 +32,11 @@ KERN_DEBUGDIR?= ${DEBUGDIR} > > > > > > .for target in all clean cleandepend cleandir clobber depend install \ > > > obj reinstall tags > > > +.if !defined(NO_KERNEL) > > > ${target}: kernel-${target} > > > +.else > > > +${target}: > > > +.endif > > > .if !defined(MODULES_WITH_WORLD) && !defined(NO_MODULES) && exists($S/modules) > > > ${target}: modules-${target} > > > modules-${target}: > > > > It allows only a single module with MODULES_OVERRIDE= and NO_KERNEL=YES > > to be built with universe in very little time. This can save a lot of > > build time when changes are limited to a set of kernel modules. > > Can you just use something like MODULES_WITH_WORLD instead? > > make tinderbox MAKE_JUST_WORLDS=yes SUBDIR_OVERRIDE=sys/modules MODULES_OVERRIDE=foo > > (If it's only 1 module directory you can probably just use SUBDIR_OVERRIDE directly?) > > make tinderbox MAKE_JUST_WORLDS=yes SUBDIR_OVERRIDE=sys/modules/foo > In any variant, this proposal sounds strange. Almost all in-kernel code is compiled both for kernel and for modules. I am only aware of exceptions for i915kms, which was done for a reason which is no longer valid. In other words, if your goal is to check that the change does not break compilation of some kernel code, then it is wrong to not compile kernels. Note that kernel and modules compilation environments are differrent. From owner-freebsd-current@freebsd.org Mon Oct 26 19:12:19 2015 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 6B6ABA1E97B for ; Mon, 26 Oct 2015 19:12:19 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (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 384A31C8D for ; Mon, 26 Oct 2015 19:12:19 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igbni9 with SMTP id ni9so80256133igb.1 for ; Mon, 26 Oct 2015 12:12:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2F+z276Zv9nNm+i/D+ra5MLXm6ItKYUglHBmw4QZEm0=; b=Ysz5tbzFbOQDQsl4nKQXa8GQGzF4XtAs+gTdsOJ3f/iewbAq12Xq62kI8wld9UQSjN ViDb/4/cT8PirFk6y3ix5aS/PBZOpZB8eP7CxQfuDChhWOnLJfB1ikpR5unafzeWxGHK tJ5bu3okQU4gBN+TLsMaWCWTT+Z46/5nLzukvcl4ZIKWJYfg+4qWJwUAgomnzfrXYGKC X9IYq9iCySn45aidjuUgp2sQxalK/c45/SFgRH2HF9KqARhzUJWmzNyU3vFNhhu4AndT EZUkex0aTBM4IPgKxnf2PR/b8gmdxysFvbbGToQvhEpyJEH0ieEu/ohpHUO+4eq2bFgj 26YA== MIME-Version: 1.0 X-Received: by 10.50.178.141 with SMTP id cy13mr19575605igc.61.1445886738579; Mon, 26 Oct 2015 12:12:18 -0700 (PDT) Received: by 10.36.46.66 with HTTP; Mon, 26 Oct 2015 12:12:18 -0700 (PDT) In-Reply-To: <20151026182348.GT2257@kib.kiev.ua> References: <562DEE4F.5010203@selasky.org> <5888922.UHSgpdyTWY@ralph.baldwin.cx> <20151026182348.GT2257@kib.kiev.ua> Date: Mon, 26 Oct 2015 12:12:18 -0700 Message-ID: Subject: Re: Quick test building a module cross all targets and architectures From: Adrian Chadd To: Konstantin Belousov Cc: Hans Petter Selasky , freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 26 Oct 2015 19:12:19 -0000 On 26 October 2015 at 11:23, Konstantin Belousov wrote: > On Mon, Oct 26, 2015 at 11:03:07AM -0700, John Baldwin wrote: >> On Monday, October 26, 2015 10:11:43 AM Hans Petter Selasky wrote: >> > Hi, >> > >> > We have NO_MODULES for building kernel without modules, but no NO_KERNEL >> > to only build the modules. >> > >> > What do you think about the following patch: >> > >> > > diff --git a/sys/conf/kern.post.mk b/sys/conf/kern.post.mk >> > > index ddf828e..f0920df 100644 >> > > --- a/sys/conf/kern.post.mk >> > > +++ b/sys/conf/kern.post.mk >> > > @@ -32,7 +32,11 @@ KERN_DEBUGDIR?= ${DEBUGDIR} >> > > >> > > .for target in all clean cleandepend cleandir clobber depend install \ >> > > obj reinstall tags >> > > +.if !defined(NO_KERNEL) >> > > ${target}: kernel-${target} >> > > +.else >> > > +${target}: >> > > +.endif >> > > .if !defined(MODULES_WITH_WORLD) && !defined(NO_MODULES) && exists($S/modules) >> > > ${target}: modules-${target} >> > > modules-${target}: >> > >> > It allows only a single module with MODULES_OVERRIDE= and NO_KERNEL=YES >> > to be built with universe in very little time. This can save a lot of >> > build time when changes are limited to a set of kernel modules. >> >> Can you just use something like MODULES_WITH_WORLD instead? >> >> make tinderbox MAKE_JUST_WORLDS=yes SUBDIR_OVERRIDE=sys/modules MODULES_OVERRIDE=foo >> >> (If it's only 1 module directory you can probably just use SUBDIR_OVERRIDE directly?) >> >> make tinderbox MAKE_JUST_WORLDS=yes SUBDIR_OVERRIDE=sys/modules/foo >> > > In any variant, this proposal sounds strange. Almost all in-kernel > code is compiled both for kernel and for modules. I am only aware of > exceptions for i915kms, which was done for a reason which is no longer > valid. In other words, if your goal is to check that the change does not > break compilation of some kernel code, then it is wrong to not compile > kernels. > > Note that kernel and modules compilation environments are differrent. No, the goal isn't that - it's to do things like "let's recompile usb + usb modules, unload, load to test." It's not a substitute for the "test a full build"; it's for testing things that are easily tested as modules - usb, wlan, etc. -a From owner-freebsd-current@freebsd.org Tue Oct 27 01:20:54 2015 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 821588C29 for ; Tue, 27 Oct 2015 01:20:54 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.auburn.protected-networks.net", Issuer "Protected Networks Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D26D1A82 for ; Tue, 27 Oct 2015 01:20:54 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA v2" (verified OK)) (Authenticated sender: imb@mail.auburn.protected-networks.net) by mail.auburn.protected-networks.net (Postfix) with ESMTPSA id 4E0131FE; Mon, 26 Oct 2015 21:20:38 -0400 (EDT) Subject: Re: AHC - 29160 interrupts not functioning? To: Patrick Hess , freebsd-current@freebsd.org References: <5623A50A.9080809@protected-networks.net> <2869849.nf8kUEgBFm@desk8.phess.net> From: Michael Butler Message-ID: <562ED164.7090403@protected-networks.net> Date: Mon, 26 Oct 2015 21:20:36 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <2869849.nf8kUEgBFm@desk8.phess.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 27 Oct 2015 01:20:54 -0000 On 10/18/15 17:37, Patrick Hess wrote: [ .. ] > I can send you a full verbose dmesg if that's of any help to you. > >> "Timedout SCBs already complete. Interrupts may not be functioning." >> when given any significant load :-( > > Just extracted an entire ports tree on that machine with no issues. > Can you give an example of a workload that causes these problems? Do you have "options AHC_ALLOW_MEMIO" in your kernel config? The machine I have running is an old Dell PowerApp 100 (700MHz Pentium-III) running about 4 jails :-( imb From owner-freebsd-current@freebsd.org Tue Oct 27 02:05:53 2015 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 15A39A1C91A for ; Tue, 27 Oct 2015 02:05:53 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (orthanc.ca [IPv6:2607:f2f8:abf8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ftp.orthanc.ca", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EF7BB1804 for ; Tue, 27 Oct 2015 02:05:52 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from [192.168.43.199] ([24.114.39.9]) (authenticated bits=0) by orthanc.ca (8.14.9/8.14.9) with ESMTP id t9R25na6094047 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 26 Oct 2015 19:05:51 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Subject: Re: Depreciate and remove gbde Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_2F0DBA9E-8AFD-4FC0-AF33-E5753FFB5C27"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5.1 From: Lyndon Nerenberg In-Reply-To: <20151024190611.GE65715@funkthat.com> Date: Mon, 26 Oct 2015 19:06:23 -0700 Cc: freebsd-current Current Message-Id: References: <6216.1445631619@critter.freebsd.dk> <201510241559.t9OFwsiF078038@fire.js.berklix.net> <20151024190611.GE65715@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 27 Oct 2015 02:05:53 -0000 --Apple-Mail=_2F0DBA9E-8AFD-4FC0-AF33-E5753FFB5C27 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 24, 2015, at 12:06 PM, John-Mark Gurney wrote: > The thing I like most about encryption is that when I RMA a bad > drive, I don't have to worry about my data leaking if I am unable > to overwrite all the data... You are optimistic if you believe that. We ($WORK) factor the cost of = DOA/warranty drives into our operational budget. They never get RMAed. = We drill them when they die. --lyndon --Apple-Mail=_2F0DBA9E-8AFD-4FC0-AF33-E5753FFB5C27 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----- iQIcBAEBCAAGBQJWLtwfAAoJEG8PnXiV/JnUmGEQAKSIjrIu+1153SqkbxtGoaYH tSZrEw5RhEtgFiEr0pOMm3jx/TV3SA9L741r0Zs7hO4mYIFr9OS7NUqahsxcFYFD 21htQ+Bkisf8RgUPRK9BO8yAtdqG3IDv70qT0YZrrjZ17+Gi5+iinds9vi6uDk+1 9T+m100wiUgYVjKDP6MS+y1jZOAAAHfAfMaNqnCOuLK8DO+y5tL93zASjd9tIkjP GHCsvuR3q4rlJ39wkVQbWYLw9aAMj1il2BpSQSBJE1oot5pJs/2oMxR2gD9nQZV5 LjPtAHeC9I3MklBjqKnco/1fMHLet22gDfCrRGfQUnDHi9U8jN6V6f75HOqOkXT3 pjZcZ7d+ijJdqauoEHzNR5oVW1kAb27uxDlKfrtqz0bODoFjuexrgucWV16DFhhB rvEBzSK2PSTTMOrjCrXtf8HzC9ncTfUCSCHNHeQ3K3GW1D6Sb1jcDfObAjCK8G1v aSy3N/1sQVa7/q/vqnqjSEBf4jUKx5eBvfK7erGAb+1x6nY3CQvANMO33s+bcBhH VDrQmT+lkbVmjMsBmGL9VESQuFAztjJI0Zpve3Rnq2Vrai5PhMCWLtj2/myvt+Ro 6nis6vQ8ZJ/sFiKvV0gWMGZIweYTe8DgbeleGD2qilziRBWqHOf4BW3QvWa9uvwq FDa1IAedmhMoSeKWNxny =kSK3 -----END PGP SIGNATURE----- --Apple-Mail=_2F0DBA9E-8AFD-4FC0-AF33-E5753FFB5C27-- From owner-freebsd-current@freebsd.org Tue Oct 27 09:05:01 2015 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 33D7881EE for ; Tue, 27 Oct 2015 09:05:01 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E9C9318CC; Tue, 27 Oct 2015 09:05:00 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id B350E1FE023; Tue, 27 Oct 2015 10:04:56 +0100 (CET) Subject: Re: Quick test building a module cross all targets and architectures To: John Baldwin , freebsd-current@freebsd.org References: <562DEE4F.5010203@selasky.org> <5888922.UHSgpdyTWY@ralph.baldwin.cx> From: Hans Petter Selasky Message-ID: <562F3EA1.9020708@selasky.org> Date: Tue, 27 Oct 2015 10:06:41 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <5888922.UHSgpdyTWY@ralph.baldwin.cx> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 27 Oct 2015 09:05:01 -0000 On 10/26/15 19:03, John Baldwin wrote: > On Monday, October 26, 2015 10:11:43 AM Hans Petter Selasky wrote: >> Hi, >> >> We have NO_MODULES for building kernel without modules, but no NO_KERNEL >> to only build the modules. >> >> What do you think about the following patch: >> >>> diff --git a/sys/conf/kern.post.mk b/sys/conf/kern.post.mk >>> index ddf828e..f0920df 100644 >>> --- a/sys/conf/kern.post.mk >>> +++ b/sys/conf/kern.post.mk >>> @@ -32,7 +32,11 @@ KERN_DEBUGDIR?= ${DEBUGDIR} >>> >>> .for target in all clean cleandepend cleandir clobber depend install \ >>> obj reinstall tags >>> +.if !defined(NO_KERNEL) >>> ${target}: kernel-${target} >>> +.else >>> +${target}: >>> +.endif >>> .if !defined(MODULES_WITH_WORLD) && !defined(NO_MODULES) && exists($S/modules) >>> ${target}: modules-${target} >>> modules-${target}: >> >> It allows only a single module with MODULES_OVERRIDE= and NO_KERNEL=YES >> to be built with universe in very little time. This can save a lot of >> build time when changes are limited to a set of kernel modules. > > Can you just use something like MODULES_WITH_WORLD instead? > > make tinderbox MAKE_JUST_WORLDS=yes SUBDIR_OVERRIDE=sys/modules MODULES_OVERRIDE=foo > > (If it's only 1 module directory you can probably just use SUBDIR_OVERRIDE directly?) > > make tinderbox MAKE_JUST_WORLDS=yes SUBDIR_OVERRIDE=sys/modules/foo > Hi John, The command you suggested will re-build all the cross-tools, which is not what I want. --HPS From owner-freebsd-current@freebsd.org Tue Oct 27 09:29:50 2015 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 AD560867F for ; Tue, 27 Oct 2015 09:29:50 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B5461263 for ; Tue, 27 Oct 2015 09:29:49 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 83EB11FE023; Tue, 27 Oct 2015 10:29:41 +0100 (CET) Subject: Re: Quick test building a module cross all targets and architectures To: Konstantin Belousov References: <562DEE4F.5010203@selasky.org> <5888922.UHSgpdyTWY@ralph.baldwin.cx> <20151026182348.GT2257@kib.kiev.ua> Cc: freebsd-current@freebsd.org From: Hans Petter Selasky Message-ID: <562F446E.6090906@selasky.org> Date: Tue, 27 Oct 2015 10:31:26 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20151026182348.GT2257@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 27 Oct 2015 09:29:50 -0000 On 10/26/15 19:23, Konstantin Belousov wrote: > On Mon, Oct 26, 2015 at 11:03:07AM -0700, John Baldwin wrote: >> On Monday, October 26, 2015 10:11:43 AM Hans Petter Selasky wrote: >>> Hi, >>> >>> We have NO_MODULES for building kernel without modules, but no NO_KERNEL >>> to only build the modules. >>> >>> What do you think about the following patch: >>> >>>> diff --git a/sys/conf/kern.post.mk b/sys/conf/kern.post.mk >>>> index ddf828e..f0920df 100644 >>>> --- a/sys/conf/kern.post.mk >>>> +++ b/sys/conf/kern.post.mk >>>> @@ -32,7 +32,11 @@ KERN_DEBUGDIR?= ${DEBUGDIR} >>>> >>>> .for target in all clean cleandepend cleandir clobber depend install \ >>>> obj reinstall tags >>>> +.if !defined(NO_KERNEL) >>>> ${target}: kernel-${target} >>>> +.else >>>> +${target}: >>>> +.endif >>>> .if !defined(MODULES_WITH_WORLD) && !defined(NO_MODULES) && exists($S/modules) >>>> ${target}: modules-${target} >>>> modules-${target}: >>> >>> It allows only a single module with MODULES_OVERRIDE= and NO_KERNEL=YES >>> to be built with universe in very little time. This can save a lot of >>> build time when changes are limited to a set of kernel modules. >> >> Can you just use something like MODULES_WITH_WORLD instead? >> >> make tinderbox MAKE_JUST_WORLDS=yes SUBDIR_OVERRIDE=sys/modules MODULES_OVERRIDE=foo >> >> (If it's only 1 module directory you can probably just use SUBDIR_OVERRIDE directly?) >> >> make tinderbox MAKE_JUST_WORLDS=yes SUBDIR_OVERRIDE=sys/modules/foo >> > > In any variant, this proposal sounds strange. Almost all in-kernel > code is compiled both for kernel and for modules. I am only aware of > exceptions for i915kms, which was done for a reason which is no longer > valid. In other words, if your goal is to check that the change does not > break compilation of some kernel code, then it is wrong to not compile > kernels. > > Note that kernel and modules compilation environments are differrent. > Hi, I understand that the compilation environments are different. How would you suggest to build-test a handful of C-files under a single device keyword and associated kernel module cross all kernels we have in a 10-minutes time-frame? MODULES_OVERRIDE can be defined from within kernel configs aswell, so possibly a MODULES_OVERRIDE_OVERRIDE is needed for this kind of feature. How about some kind of KERNCONF_APPEND= parameter, which contains instructions for "config" to only emit a single device keyword, yet, keeping all options and parameters. --HPS From owner-freebsd-current@freebsd.org Tue Oct 27 12:16:32 2015 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 C2FF3872B for ; Tue, 27 Oct 2015 12:16:32 +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 3B175147E for ; Tue, 27 Oct 2015 12:16:32 +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 t9RCGN3R036947 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 27 Oct 2015 14:16:23 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua t9RCGN3R036947 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id t9RCGNoA036946; Tue, 27 Oct 2015 14:16:23 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 27 Oct 2015 14:16:23 +0200 From: Konstantin Belousov To: Hans Petter Selasky Cc: freebsd-current@freebsd.org Subject: Re: Quick test building a module cross all targets and architectures Message-ID: <20151027121623.GW2257@kib.kiev.ua> References: <562DEE4F.5010203@selasky.org> <5888922.UHSgpdyTWY@ralph.baldwin.cx> <20151026182348.GT2257@kib.kiev.ua> <562F446E.6090906@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <562F446E.6090906@selasky.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.20 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, 27 Oct 2015 12:16:32 -0000 On Tue, Oct 27, 2015 at 10:31:26AM +0100, Hans Petter Selasky wrote: > I understand that the compilation environments are different. > > How would you suggest to build-test a handful of C-files under a single > device keyword and associated kernel module cross all kernels we have in > a 10-minutes time-frame? MODULES_OVERRIDE can be defined from within > kernel configs aswell, so possibly a MODULES_OVERRIDE_OVERRIDE is needed > for this kind of feature. How about some kind of KERNCONF_APPEND= > parameter, which contains instructions for "config" to only emit a > single device keyword, yet, keeping all options and parameters. Did you tried to pass -DNO_CLEAN -DNO_KERNELCLEAN -DNO_KERNELCONFIG -DNO_KERNELDEPEND -DNO_KERNELOBJ options for make universe over the already built tree ? When I develop, I use make buildkernel -DNO_KERNELCLEAN -DNO_KERNELCONFIG -DNO_KERNELDEPEND -DNO_KERNELOBJ unless I change config, or add a file, or add a module etc. This combination gives me seconds for whole kernel and modules rebuild time when I know that the build metadata, i.e. files participating in the build, and the build options, did not changed from the latest full rebuild. I think that a similar trick should work with make universe, it might be somewhat more involved to properly pass the directions, may be not. But it should give the build time in the range of tens of minutes, indeed. From owner-freebsd-current@freebsd.org Tue Oct 27 12:58:15 2015 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 EBC1DA1E6D1 for ; Tue, 27 Oct 2015 12:58:15 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AF4F71CDC for ; Tue, 27 Oct 2015 12:58:15 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 954751FE023; Tue, 27 Oct 2015 13:58:13 +0100 (CET) Subject: Re: Quick test building a module cross all targets and architectures To: Konstantin Belousov References: <562DEE4F.5010203@selasky.org> <5888922.UHSgpdyTWY@ralph.baldwin.cx> <20151026182348.GT2257@kib.kiev.ua> <562F446E.6090906@selasky.org> <20151027121623.GW2257@kib.kiev.ua> Cc: freebsd-current@freebsd.org From: Hans Petter Selasky Message-ID: <562F754E.7010906@selasky.org> Date: Tue, 27 Oct 2015 13:59:58 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20151027121623.GW2257@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 27 Oct 2015 12:58:16 -0000 On 10/27/15 13:16, Konstantin Belousov wrote: > On Tue, Oct 27, 2015 at 10:31:26AM +0100, Hans Petter Selasky wrote: >> I understand that the compilation environments are different. >> >> How would you suggest to build-test a handful of C-files under a single >> device keyword and associated kernel module cross all kernels we have in >> a 10-minutes time-frame? MODULES_OVERRIDE can be defined from within >> kernel configs aswell, so possibly a MODULES_OVERRIDE_OVERRIDE is needed >> for this kind of feature. How about some kind of KERNCONF_APPEND= >> parameter, which contains instructions for "config" to only emit a >> single device keyword, yet, keeping all options and parameters. > > Did you tried to pass > -DNO_CLEAN -DNO_KERNELCLEAN -DNO_KERNELCONFIG -DNO_KERNELDEPEND -DNO_KERNELOBJ > options for make universe over the already built tree ? > > When I develop, I use > make buildkernel -DNO_KERNELCLEAN -DNO_KERNELCONFIG -DNO_KERNELDEPEND -DNO_KERNELOBJ > unless I change config, or add a file, or add a module etc. This > combination gives me seconds for whole kernel and modules rebuild time > when I know that the build metadata, i.e. files participating in the > build, and the build options, did not changed from the latest full > rebuild. > > I think that a similar trick should work with make universe, it might be > somewhat more involved to properly pass the directions, may be not. But > it should give the build time in the range of tens of minutes, indeed. Hi Konstantin, You will need an initial complete universe build which compiles to be able to use these options. Not all C-files have a dependency rule, possibly due to a lack of functionality in "config". I've burnt a few times with -DNO_CLEAN in the past because of "no-depend" keywords in sys/conf/files . In other words: > make buildkernel -DNO_KERNELCLEAN -DNO_KERNELCONFIG -DNO_KERNELDEPEND -DNO_KERNELOBJ Is not the same like: > make buildkernel And especially before commit. The most promising in this thread so far is: > make tinderbox MAKE_JUST_WORLDS=yes SUBDIR_OVERRIDE=sys/modules MODULES_OVERRIDE=foo --HPS From owner-freebsd-current@freebsd.org Tue Oct 27 12:58:57 2015 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 14C40A1E73C for ; Tue, 27 Oct 2015 12:58:57 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C84A21E03 for ; Tue, 27 Oct 2015 12:58:56 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id A4DCE1FE023; Tue, 27 Oct 2015 13:58:54 +0100 (CET) From: Hans Petter Selasky Subject: Re: Quick test building a module cross all targets and architectures To: Konstantin Belousov References: <562DEE4F.5010203@selasky.org> <5888922.UHSgpdyTWY@ralph.baldwin.cx> <20151026182348.GT2257@kib.kiev.ua> <562F446E.6090906@selasky.org> <20151027121623.GW2257@kib.kiev.ua> Cc: freebsd-current@freebsd.org Message-ID: <562F7577.7040804@selasky.org> Date: Tue, 27 Oct 2015 14:00:39 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20151027121623.GW2257@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 27 Oct 2015 12:58:57 -0000 On 10/27/15 13:16, Konstantin Belousov wrote: > On Tue, Oct 27, 2015 at 10:31:26AM +0100, Hans Petter Selasky wrote: >> I understand that the compilation environments are different. >> >> How would you suggest to build-test a handful of C-files under a single >> device keyword and associated kernel module cross all kernels we have in >> a 10-minutes time-frame? MODULES_OVERRIDE can be defined from within >> kernel configs aswell, so possibly a MODULES_OVERRIDE_OVERRIDE is needed >> for this kind of feature. How about some kind of KERNCONF_APPEND= >> parameter, which contains instructions for "config" to only emit a >> single device keyword, yet, keeping all options and parameters. > > Did you tried to pass > -DNO_CLEAN -DNO_KERNELCLEAN -DNO_KERNELCONFIG -DNO_KERNELDEPEND -DNO_KERNELOBJ > options for make universe over the already built tree ? > > When I develop, I use > make buildkernel -DNO_KERNELCLEAN -DNO_KERNELCONFIG -DNO_KERNELDEPEND -DNO_KERNELOBJ > unless I change config, or add a file, or add a module etc. This > combination gives me seconds for whole kernel and modules rebuild time > when I know that the build metadata, i.e. files participating in the > build, and the build options, did not changed from the latest full > rebuild. > > I think that a similar trick should work with make universe, it might be > somewhat more involved to properly pass the directions, may be not. But > it should give the build time in the range of tens of minutes, indeed. Hi Konstantin, You will need an initial complete universe build which compiles to be able to use these options. Not all C-files have a dependency rule, possibly due to a lack of functionality in "config". I've burnt a few times with -DNO_CLEAN in the past because of "no-depend" keywords in sys/conf/files . In other words: > make buildkernel -DNO_KERNELCLEAN -DNO_KERNELCONFIG -DNO_KERNELDEPEND -DNO_KERNELOBJ Is not the same like: > make buildkernel And especially before commit. The most promising in this thread so far is: > make tinderbox MAKE_JUST_WORLDS=yes SUBDIR_OVERRIDE=sys/modules MODULES_OVERRIDE=foo --HPS From owner-freebsd-current@freebsd.org Tue Oct 27 15:38:54 2015 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 0CB4EA1F629 for ; Tue, 27 Oct 2015 15:38:54 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 E446F1B79 for ; Tue, 27 Oct 2015 15:38:53 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Tue, 27 Oct 2015 15:39:08 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t9RFcitP030069; Tue, 27 Oct 2015 09:38:45 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1445960324.91534.84.camel@freebsd.org> Subject: Re: Quick test building a module cross all targets and architectures From: Ian Lepore To: Hans Petter Selasky , Konstantin Belousov Cc: freebsd-current@freebsd.org Date: Tue, 27 Oct 2015 09:38:44 -0600 In-Reply-To: <562F7577.7040804@selasky.org> References: <562DEE4F.5010203@selasky.org> <5888922.UHSgpdyTWY@ralph.baldwin.cx> <20151026182348.GT2257@kib.kiev.ua> <562F446E.6090906@selasky.org> <20151027121623.GW2257@kib.kiev.ua> <562F7577.7040804@selasky.org> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 27 Oct 2015 15:38:54 -0000 On Tue, 2015-10-27 at 14:00 +0100, Hans Petter Selasky wrote: > On 10/27/15 13:16, Konstantin Belousov wrote: > > On Tue, Oct 27, 2015 at 10:31:26AM +0100, Hans Petter Selasky > > wrote: > > > I understand that the compilation environments are different. > > > > > > How would you suggest to build-test a handful of C-files under a > > > single > > > device keyword and associated kernel module cross all kernels we > > > have in > > > a 10-minutes time-frame? MODULES_OVERRIDE can be defined from > > > within > > > kernel configs aswell, so possibly a MODULES_OVERRIDE_OVERRIDE is > > > needed > > > for this kind of feature. How about some kind of KERNCONF_APPEND= > > > parameter, which contains instructions for "config" to only emit > > > a > > > single device keyword, yet, keeping all options and parameters. > > > > Did you tried to pass > > -DNO_CLEAN -DNO_KERNELCLEAN -DNO_KERNELCONFIG -DNO_KERNELDEPEND > > -DNO_KERNELOBJ > > options for make universe over the already built tree ? > > > > When I develop, I use > > make buildkernel -DNO_KERNELCLEAN -DNO_KERNELCONFIG > > -DNO_KERNELDEPEND -DNO_KERNELOBJ > > unless I change config, or add a file, or add a module etc. This > > combination gives me seconds for whole kernel and modules rebuild > > time > > when I know that the build metadata, i.e. files participating in > > the > > build, and the build options, did not changed from the latest full > > rebuild. > > > > I think that a similar trick should work with make universe, it > > might be > > somewhat more involved to properly pass the directions, may be not. > > But > > it should give the build time in the range of tens of minutes, > > indeed. > > Hi Konstantin, > > You will need an initial complete universe build which compiles to be > able to use these options. > No, just a "make kernel-toolchains" which is noticibly faster than universe. You can add TARGETS=arm to get just the toolchains for the arm arches, or TARGET_ARCH=amd64 to get just that one arch. Building kernel toolchains for all arches means building clang many times, but it's something you only have to do a few times a year when a new version of clang is imported. > Not all C-files have a dependency rule, possibly due to a lack of > functionality in "config". I've burnt a few times with -DNO_CLEAN in > the > past because of "no-depend" keywords in sys/conf/files . > > In other words: > > make buildkernel -DNO_KERNELCLEAN -DNO_KERNELCONFIG > > -DNO_KERNELDEPEND -DNO_KERNELOBJ > > Is not the same like: > > make buildkernel > > And especially before commit. > > The most promising in this thread so far is: > > make tinderbox MAKE_JUST_WORLDS=yes SUBDIR_OVERRIDE=sys/modules > > MODULES_OVERRIDE=foo Certainly it's *possible* to have a problem building kernels with NO_CLEAN, but IMO it's just not right to elevate that possibility into anything like a serious problem. I do NO_CLEAN builds literally dozens of times a day, across all arches. I can't remember the last time I had a problem. When it does cause a problem, or when I've made big changes that might require regenerating dependencies, I just rm -rf the kernel dir(s) within $OBJDIR and the next build takes 40 seconds instead of 7, or if doing all arch kernels and they're all removed, it takes maybe 15 minutes, but that's something I only do once every few weeks. BTW, MODULES_OVERRIDE on the command line already overrides the one in the config file. -- Ian From owner-freebsd-current@freebsd.org Tue Oct 27 16:07:01 2015 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 E27A9A1EBE1 for ; Tue, 27 Oct 2015 16:07: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 C0761142F for ; Tue, 27 Oct 2015 16:07: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 DEA6FB91E; Tue, 27 Oct 2015 12:06:59 -0400 (EDT) From: John Baldwin To: Hans Petter Selasky Cc: freebsd-current@freebsd.org Subject: Re: Quick test building a module cross all targets and architectures Date: Tue, 27 Oct 2015 08:49:09 -0700 Message-ID: <4276722.e5fJFDHm8P@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-PRERELEASE; KDE/4.14.3; amd64; ; ) In-Reply-To: <562F3EA1.9020708@selasky.org> References: <562DEE4F.5010203@selasky.org> <5888922.UHSgpdyTWY@ralph.baldwin.cx> <562F3EA1.9020708@selasky.org> 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, 27 Oct 2015 12:07:00 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 27 Oct 2015 16:07:02 -0000 On Tuesday, October 27, 2015 10:06:41 AM Hans Petter Selasky wrote: > On 10/26/15 19:03, John Baldwin wrote: > > On Monday, October 26, 2015 10:11:43 AM Hans Petter Selasky wrote: > >> Hi, > >> > >> We have NO_MODULES for building kernel without modules, but no NO_KERNEL > >> to only build the modules. > >> > >> What do you think about the following patch: > >> > >>> diff --git a/sys/conf/kern.post.mk b/sys/conf/kern.post.mk > >>> index ddf828e..f0920df 100644 > >>> --- a/sys/conf/kern.post.mk > >>> +++ b/sys/conf/kern.post.mk > >>> @@ -32,7 +32,11 @@ KERN_DEBUGDIR?= ${DEBUGDIR} > >>> > >>> .for target in all clean cleandepend cleandir clobber depend install \ > >>> obj reinstall tags > >>> +.if !defined(NO_KERNEL) > >>> ${target}: kernel-${target} > >>> +.else > >>> +${target}: > >>> +.endif > >>> .if !defined(MODULES_WITH_WORLD) && !defined(NO_MODULES) && exists($S/modules) > >>> ${target}: modules-${target} > >>> modules-${target}: > >> > >> It allows only a single module with MODULES_OVERRIDE= and NO_KERNEL=YES > >> to be built with universe in very little time. This can save a lot of > >> build time when changes are limited to a set of kernel modules. > > > > Can you just use something like MODULES_WITH_WORLD instead? > > > > make tinderbox MAKE_JUST_WORLDS=yes SUBDIR_OVERRIDE=sys/modules MODULES_OVERRIDE=foo > > > > (If it's only 1 module directory you can probably just use SUBDIR_OVERRIDE directly?) > > > > make tinderbox MAKE_JUST_WORLDS=yes SUBDIR_OVERRIDE=sys/modules/foo > > > > Hi John, > > The command you suggested will re-build all the cross-tools, which is > not what I want. NO_CLEAN=yes? You have to build all the compilers no matter what, and for incremental builds once you have NO_CLEAN=yes you only have to build it once. Having a NO_KERNEL for buildkernel just seems rather obscure. You still have to have a config file (even if it's the implicit GENERIC). Also, with your change, you will still build the module umpteen times (once for each kernel, so about 80 times on arm, etc.). With MAKE_JUST_WORLDS you would only build a "generic" module once per architecture. That savings is likely far more than the cost of the additional tools. -- John Baldwin From owner-freebsd-current@freebsd.org Tue Oct 27 16:15:14 2015 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 5FA0AA1EE8D for ; Tue, 27 Oct 2015 16:15:14 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2697E1A8E; Tue, 27 Oct 2015 16:15:13 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id CD7B01FE023; Tue, 27 Oct 2015 17:15:10 +0100 (CET) Subject: Re: Quick test building a module cross all targets and architectures To: John Baldwin References: <562DEE4F.5010203@selasky.org> <5888922.UHSgpdyTWY@ralph.baldwin.cx> <562F3EA1.9020708@selasky.org> <4276722.e5fJFDHm8P@ralph.baldwin.cx> Cc: freebsd-current@freebsd.org From: Hans Petter Selasky Message-ID: <562FA376.1060403@selasky.org> Date: Tue, 27 Oct 2015 17:16:54 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <4276722.e5fJFDHm8P@ralph.baldwin.cx> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 27 Oct 2015 16:15:14 -0000 On 10/27/15 16:49, John Baldwin wrote: > With MAKE_JUST_WORLDS you would only build > a "generic" module once per architecture. That savings is likely far more > than the cost of the additional tools. I will try it out. Thanks for your hints and tips. --HPS From owner-freebsd-current@freebsd.org Tue Oct 27 16:12:25 2015 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 F33DFA1EDD9 for ; Tue, 27 Oct 2015 16:12:25 +0000 (UTC) (envelope-from fkr@hazardous.org) Received: from smtp.bytemine.net (smtp.fra2.bytemine.net [IPv6:2a00:12d8:200a::43]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B9BBA19AC for ; Tue, 27 Oct 2015 16:12:25 +0000 (UTC) (envelope-from fkr@hazardous.org) Received: from hoza07.fra.bytemine.net ([91.212.95.175]) by smtp.bytemine.net with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.82) (envelope-from ) id 1Zr6r6-00040E-WB; Tue, 27 Oct 2015 17:12:12 +0100 Received: from vpn.fra.bytemine.net ([91.212.95.9] helo=badwater.local) by hoza07.fra.bytemine.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.84) (envelope-from ) id 1Zr6r1-0007rP-LZ; Tue, 27 Oct 2015 17:12:07 +0100 Message-ID: <562FA251.6050900@hazardous.org> Date: Tue, 27 Oct 2015 17:12:01 +0100 From: Felix Kronlage User-Agent: Postbox 4.0.7 (Macintosh/20151021) MIME-Version: 1.0 To: Lyndon Nerenberg CC: John-Mark Gurney , freebsd-current Current Subject: Re: Depreciate and remove gbde References: <6216.1445631619@critter.freebsd.dk> <201510241559.t9OFwsiF078038@fire.js.berklix.net> <20151024190611.GE65715@funkthat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 27 Oct 2015 16:20:52 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 27 Oct 2015 16:12:26 -0000 Lyndon Nerenberg wrote: > On Oct 24, 2015, at 12:06 PM, John-Mark Gurney wrote: >> The thing I like most about encryption is that when I RMA a bad >> drive, I don't have to worry about my data leaking if I am unable >> to overwrite all the data... > You are optimistic if you believe that. We ($WORK) factor the cost of DOA/warranty drives into our operational budget. They never get RMAed. We drill them when they die. Can only second that. One of the reasons why we work with hardware vendors that offer Keep-your-drive warranty. That way, we get to keep the broken drive and still get them RMA'ed. Can definitly recommend that ;) felix From owner-freebsd-current@freebsd.org Tue Oct 27 17:50:58 2015 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 6DCE8A1F259 for ; Tue, 27 Oct 2015 17:50:58 +0000 (UTC) (envelope-from patrickhess@gmx.net) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BA5851F2F for ; Tue, 27 Oct 2015 17:50:56 +0000 (UTC) (envelope-from patrickhess@gmx.net) Received: from desk8.phess.net ([95.88.166.205]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lm2lZ-1aPv320rRZ-00Zfjn for ; Tue, 27 Oct 2015 18:50:49 +0100 From: Patrick Hess To: freebsd-current@freebsd.org Subject: Re: AHC - 29160 interrupts not functioning? Date: Tue, 27 Oct 2015 18:50:47 +0100 Message-ID: <2137786.8PrZuT7CDg@desk8.phess.net> User-Agent: KMail/4.14.3 (FreeBSD/10.1-RELEASE-p16; KDE/4.14.3; i386; ; ) In-Reply-To: <562ED164.7090403@protected-networks.net> References: <5623A50A.9080809@protected-networks.net> <2869849.nf8kUEgBFm@desk8.phess.net> <562ED164.7090403@protected-networks.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:91O9sJTUgjkjUtXop0/AxWVPgMG9mXA+6zbVAitCdLd7WacoBw8 kuMc9KwnXdhnI9Np8NMgAEyxrboNTbAMjMgd2zrUOD1nKHXQ3g2wvhrBA0UWh6dzr1eNmYw MCq2AfE3eI/BPAJ2PtHqiAP9hQkjAKnw8BYSrzrTHB6MMW8jMNgDUo6FmqyJKRI3e/Cb/lC cC9KraH8i1xFNpQex+pqg== X-UI-Out-Filterresults: notjunk:1;V01:K0:tmPWGtWLSao=:L923xyDGda9EK8gqnhs/uc XGvDxMagGYYoVYgw2+lkqUwXvo0whjb2n5gsDb1PtFVfECINbC2G+PHPPN6+np1pp2C1jTMA8 Ogjvn4v+auRjaZ7GnkEfQWVdTjhn958UJtv40QTIAvhgULmgvVycNPWlYqW1whbtwvUl5zCYI boxqVC5ei58iyXt/N43XuspS81fxRPb/ZdePbARxmzB2BGAnK1MZrItprsDDbmemAv5T4MTGU FUjAuUYpWSyzxJwaVOolmMGX2E/KSF9rcFJjpnpsKAS8++b0wrVxCzbsPddmoxkHCAygt5gn+ IJDcnscQz0dvuO8W5SsQudMgGosS1fcwkJkhyNjXHQkxqc3W7Jo8VDM5iGDES0s4Ck7CgfaNE YbMAeeKR+oP3+/vHBso8KOV2IIo3m0+H/NU4Mw2XA7nnNvIZ6Zartzb4AY7fnM+mdIFM3OwwY XpSQ4sXr15ih/QvASSpRco9NFOyTT+4GQibHj5xIEDi/ZVGgooYAfjG11MZayhYbuty/hC8nR HonJ+t6eRvh8a+5NE3e1NTklKK4Hbo/At1Z3h/MRUAwlC9HZV9ovKL0B1J58k8H2I6LEfOKmW 8a/3A4Mdm34zD3N4k2lV9NedI+0WuuNjOTqXB2uuWTgq6uzT7yAOVa64VH3RHXeKZzfyLDSUf 6xuDPImWC3CIWbz5s+ooRy5ZcsnjTBF1o3Mq6m3nHRlNqATKdmC9uxhBTr+qoER3ibG327NpW G+t51h1QZEQIrZLgeFw+7LZ8gJqN0vjQKgYd7C83NrUJm7GTrXk17WDhHv90rkG3Riowcn3GQ foDvVra X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 27 Oct 2015 17:50:58 -0000 Michael Butler wrote: > Do you have "options AHC_ALLOW_MEMIO" in your kernel config? I'm running GENERIC on all of those machines, and as far as I can tell, that option is not enabled by default, at least on 10.1-RELEASE: # config -x /boot/kernel/kernel | grep -i ahc options AHC_REG_PRETTY_PRINT device ahci device ahc # uname -v FreeBSD 10.1-RELEASE-p16 #0: Tue Jul 28 11:41:12 UTC 2015 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC > The machine I have running is an old Dell PowerApp 100 (700MHz > Pentium-III) running about 4 jails :-( Have you tried running an off-the-shelf GENERIC kernel on that machine? I have an even older Primergy server (450 MHz Pentium-II) that runs my backup system, and a 10.1-RELEASE GENERIC kernel works perfectly fine on that ancient box, too. Patrick From owner-freebsd-current@freebsd.org Tue Oct 27 20:11:22 2015 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 9E64681C4 for ; Tue, 27 Oct 2015 20:11:22 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (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 6A1081459 for ; Tue, 27 Oct 2015 20:11:22 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by obctp1 with SMTP id tp1so153188304obc.2 for ; Tue, 27 Oct 2015 13:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=sQGm1XQMv0leaTIdX1e8kGPq3T12QYVlDox7+NxFX78=; b=HEL5N3aIHoq1Z8oTFYQ6nNfVYYzjp2m2d6PZcvmUsTKqyaFHuUBSVzcLSDU0nJrvtM NuA61ooWSMuzPweMgjWlnINpSEh9LEkAdnB7wpglQsRnyK21VmoTJ9TvPrQ7X7/Ea2Ew 6D5tW533wulvR9Q+3meONh0bEIa/OzzNl5G6By6uzSPk5+ASlPmH7cvyyI1gRkXUDZiM 49uyEn2UIcqwlPsz85NAUGWoMyPuTtAl4fa4djWgz2HWHfdPpDpwBfk+llJ5Somz/RNx T/symacxwJYhugvsCrLM+Q/1ItGkZMZKWo9/s1zcsLpZJ+1NDJ05GiMAQVLEDdL+y4hB juRQ== MIME-Version: 1.0 X-Received: by 10.60.125.165 with SMTP id mr5mr5880581oeb.60.1445976681780; Tue, 27 Oct 2015 13:11:21 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.202.1.206 with HTTP; Tue, 27 Oct 2015 13:11:21 -0700 (PDT) Date: Tue, 27 Oct 2015 14:11:21 -0600 X-Google-Sender-Auth: OJBWqMDwTsM7_dZC0iSo9AD7sno Message-ID: Subject: Coverity down? From: Alan Somers To: FreeBSD CURRENT Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 27 Oct 2015 20:11:22 -0000 I just noticed that our last Coverity scan happened on either July-6 (according to my inbox) or June-26 (according to Coverity's website). Prior to that, we seemed to get scanned about once per week. Does anybody know why we haven't been scanned for so long? I can't figure out what triggers a scan, but it seems like it should've happened by now. -Alan From owner-freebsd-current@freebsd.org Tue Oct 27 20:23:58 2015 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 DD35F85AD for ; Tue, 27 Oct 2015 20:23:58 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [202.12.127.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.auburn.protected-networks.net", Issuer "Protected Networks Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 90D651DFB for ; Tue, 27 Oct 2015 20:23:58 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA v2" (verified OK)) (Authenticated sender: imb@mail.auburn.protected-networks.net) by mail.auburn.protected-networks.net (Postfix) with ESMTPSA id CA4AA41 for ; Tue, 27 Oct 2015 16:23:28 -0400 (EDT) Subject: Re: AHC - 29160 interrupts not functioning? To: freebsd-current@freebsd.org References: <5623A50A.9080809@protected-networks.net> <2869849.nf8kUEgBFm@desk8.phess.net> <562ED164.7090403@protected-networks.net> <2137786.8PrZuT7CDg@desk8.phess.net> From: Michael Butler Message-ID: <562FDD3F.8020101@protected-networks.net> Date: Tue, 27 Oct 2015 16:23:27 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <2137786.8PrZuT7CDg@desk8.phess.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 27 Oct 2015 20:23:59 -0000 On 10/27/15 13:50, Patrick Hess wrote: > Michael Butler wrote: >> Do you have "options AHC_ALLOW_MEMIO" in your kernel config? > > I'm running GENERIC on all of those machines, and as far as I can tell, > that option is not enabled by default, at least on 10.1-RELEASE: I discovered that there are two ports that, if not also upgraded, play poorly with a new kernel. It seems that sysutils/smartmontools and sysutils/lmmon are capable of disrupting the SCSI controller's activities on my particular host :-( Recompiling them made the weird symptoms go away :) imb From owner-freebsd-current@freebsd.org Tue Oct 27 20:50:14 2015 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 CC06EA1C034 for ; Tue, 27 Oct 2015 20:50:14 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (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 8F4CA1F7F for ; Tue, 27 Oct 2015 20:50:14 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1ZrBCI-0002xn-QA; Tue, 27 Oct 2015 21:50:22 +0100 Date: Tue, 27 Oct 2015 21:50:22 +0100 From: Kurt Jaeger To: Michael Butler Cc: freebsd-current@freebsd.org Subject: Re: AHC - 29160 interrupts not functioning? Message-ID: <20151027205022.GX19913@home.opsec.eu> References: <5623A50A.9080809@protected-networks.net> <2869849.nf8kUEgBFm@desk8.phess.net> <562ED164.7090403@protected-networks.net> <2137786.8PrZuT7CDg@desk8.phess.net> <562FDD3F.8020101@protected-networks.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <562FDD3F.8020101@protected-networks.net> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 27 Oct 2015 20:50:14 -0000 Hi! > On 10/27/15 13:50, Patrick Hess wrote: > > Michael Butler wrote: > >> Do you have "options AHC_ALLOW_MEMIO" in your kernel config? > > > > I'm running GENERIC on all of those machines, and as far as I can tell, > > that option is not enabled by default, at least on 10.1-RELEASE: > > I discovered that there are two ports that, if not also upgraded, play > poorly with a new kernel. It seems that sysutils/smartmontools and > sysutils/lmmon are capable of disrupting the SCSI controller's > activities on my particular host :-( > > Recompiling them made the weird symptoms go away :) This should be mentioned in the pkg-messages of those ports. Can you tell more about the difference before you recompiled the ports ? 10.0 -> 10.1 ? Or was it 9.3 -> 10.1 ? -- pi@opsec.eu +49 171 3101372 5 years to go ! From owner-freebsd-current@freebsd.org Tue Oct 27 21:18:03 2015 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 7FF7AA1CA1A for ; Tue, 27 Oct 2015 21:18:03 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.auburn.protected-networks.net", Issuer "Protected Networks Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 745AA1AD2 for ; Tue, 27 Oct 2015 21:18:02 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA v2" (verified OK)) (Authenticated sender: imb@mail.auburn.protected-networks.net) by mail.auburn.protected-networks.net (Postfix) with ESMTPSA id 552068B; Tue, 27 Oct 2015 17:11:53 -0400 (EDT) Subject: Re: AHC - 29160 interrupts not functioning? To: Kurt Jaeger References: <5623A50A.9080809@protected-networks.net> <2869849.nf8kUEgBFm@desk8.phess.net> <562ED164.7090403@protected-networks.net> <2137786.8PrZuT7CDg@desk8.phess.net> <562FDD3F.8020101@protected-networks.net> <20151027205022.GX19913@home.opsec.eu> Cc: freebsd-current@freebsd.org From: Michael Butler Message-ID: <562FE898.2090802@protected-networks.net> Date: Tue, 27 Oct 2015 17:11:52 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151027205022.GX19913@home.opsec.eu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 27 Oct 2015 21:18:03 -0000 On 10/27/15 16:50, Kurt Jaeger wrote: > Hi! > >> On 10/27/15 13:50, Patrick Hess wrote: >>> Michael Butler wrote: >>>> Do you have "options AHC_ALLOW_MEMIO" in your kernel config? >>> >>> I'm running GENERIC on all of those machines, and as far as I can tell, >>> that option is not enabled by default, at least on 10.1-RELEASE: >> >> I discovered that there are two ports that, if not also upgraded, play >> poorly with a new kernel. It seems that sysutils/smartmontools and >> sysutils/lmmon are capable of disrupting the SCSI controller's >> activities on my particular host :-( >> >> Recompiling them made the weird symptoms go away :) > > This should be mentioned in the pkg-messages of those ports. > > Can you tell more about the difference before you recompiled the ports ? > 10.0 -> 10.1 ? Or was it 9.3 -> 10.1 ? I was trying to step up from 9.3 to 10.1. I'm not sure exactly what ABI change upset the controller - I happened to be sitting at the console when smartd caused a problem, imb From owner-freebsd-current@freebsd.org Tue Oct 27 22:09:57 2015 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 5F9B2A1D88D for ; Tue, 27 Oct 2015 22:09:57 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001: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 2D3AC108C; Tue, 27 Oct 2015 22:09:57 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by ioll68 with SMTP id l68so238854825iol.3; Tue, 27 Oct 2015 15:09:56 -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:from:date:message-id :subject:to:cc:content-type; bh=EQ2A3wUUc4RfoPuYKn2JPnsCwEU/81MKwq7ouKrrsOc=; b=i7Ngl18KWohgN7NaOnjWvMevRaB8g6TkHvwGGWIRK+p4tN7YL5SNv3NswdiOl5DCBe Il8gEYBi6k+337VulKjlrAl2f53FUlWD9NuFfgvaz20K0iGpOtP5h5SGfRuVG8MUkCL9 IeJN9U3wgJslxXUbx3qidgqI7Kvn8G3s/4sd3+Zl+topenuLgf4Q0Js9uceq19yEWYgH pdWtZh5CpR/DotsQOHk6izQnCiCFX/bfPsGrsHmkCViNe/twj38gNKoB8OGrfnPr7oBj eXCzaubecN0zVwuNMSLWw7vYFQ7GOAzOUh+0tnkY4D5fwBTcBGK2gMx1SPzPnw0rHh63 HDsQ== X-Received: by 10.107.10.95 with SMTP id u92mr45133702ioi.180.1445983796514; Tue, 27 Oct 2015 15:09:56 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.158.75 with HTTP; Tue, 27 Oct 2015 15:09:37 -0700 (PDT) In-Reply-To: <20150212023912.GG1302@hub.FreeBSD.org> References: <20150212023912.GG1302@hub.FreeBSD.org> From: Ed Maste Date: Tue, 27 Oct 2015 18:09:37 -0400 X-Google-Sender-Auth: x2zc9GcPRWwwLEaC-XlDwLNFzsc Message-ID: Subject: Re: HEADS-UP: Enabling WITH_DEBUG_FILES by default To: Glen Barber Cc: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 27 Oct 2015 22:09:57 -0000 On 11 February 2015 at 21:39, Glen Barber wrote: > Hi, > > Within the next 24 hours, I will merge the release-install-debug branch > into head, which will enable building and installing stripped debugging > files by default. > > In general, this should have no significant impact, but any fallout will > be addressed as soon as possible after the merge. > > Those that do not want debugging files built/installed by default should > add 'WITHOUT_DEBUG_FILES=1' to src.conf(5). This will also be noted in > UPDATING. I want to pick this change up again. There are a few separate parts under discussion: 1. Release build changes to support standalone debug 2. Installer changes 3. Switching debug files on by default 4. Separating into two or more debug dist sets Glen's proposed merge from earlier this year included #1 through #3, but was held up based on discussion in this thread. I propose that we merge #1 and #2 now, since they're effectively a no-op if debug files aren't enabled, but facilitate further testing. Separating the debug dist sets (into runtime and binaries, or even more fine-grained) requires coordination with the packaged base work, and I suggest that we hold off on that project for now. I'd like to flip the default shortly after and continue refining it with it enabled - we need to start finding and fix issues now in order to have it ready for 11.0. I have a review open for the default switch, in https://reviews.freebsd.org/D4018. In my test just now on a powerful server the cpu (user+system) time increased from 15260s to 15760s. Wall clock time increased by under 40s (20:08.83 to 20:47.49). The objdir was 2.4GB without debug and 4.3GB with. From owner-freebsd-current@freebsd.org Tue Oct 27 23:09:35 2015 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 6F6ADA1FC33 for ; Tue, 27 Oct 2015 23:09:35 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 46FE8138B for ; Tue, 27 Oct 2015 23:09:35 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id t9RN9SPc018751 for ; Tue, 27 Oct 2015 16:09:32 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201510272309.t9RN9SPc018751@gw.catspoiler.org> Date: Tue, 27 Oct 2015 16:09:28 -0700 (PDT) From: Don Lewis Subject: 11.0-CURRENT r290039 privileged instruction fault while in kernel mode To: freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 27 Oct 2015 23:09:35 -0000 I just got this crash while running poudriere on a freshly upgraded 11.0-CURRENT machine. The instruction pointer value looks pretty strange. FreeBSD zipper.catspoiler.org 11.0-CURRENT FreeBSD 11.0-CURRENT #30 r290039: Tue Oct 27 00:08:00 PDT 2015 dl@zipper.catspoiler.org:/usr/obj/usr/src/sys/GENERIC amd64 panic: GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 1: privileged instruction fault while in kernel mode cpuid = 4; apic id = 14 instruction pointer = 0x20:0xffffffff8240fef5 stack pointer = 0x28:0xfffffe0859c636c0 frame pointer = 0x28:0xfffffe0859c636e0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (zio_free_issue_2_9) Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /usr/lib/debug//boot/kernel/zfs.ko.debug...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /usr/lib/debug//boot/kernel/opensolaris.ko.debug...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/geom_mirror.ko...Reading symbols from /usr/lib/debug//boot/kernel/geom_mirror.ko.debug...done. done. Loaded symbols for /boot/kernel/geom_mirror.ko Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko Reading symbols from /boot/modules/vboxnetflt.ko...done. Loaded symbols for /boot/modules/vboxnetflt.ko Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from /usr/lib/debug//boot/kernel/netgraph.ko.debug...done. done. Loaded symbols for /boot/kernel/netgraph.ko Reading symbols from /boot/kernel/ng_ether.ko...Reading symbols from /usr/lib/debug//boot/kernel/ng_ether.ko.debug...done. done. Loaded symbols for /boot/kernel/ng_ether.ko Reading symbols from /boot/modules/vboxnetadp.ko...done. Loaded symbols for /boot/modules/vboxnetadp.ko Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from /usr/lib/debug//boot/kernel/nullfs.ko.debug...done. done. Loaded symbols for /boot/kernel/nullfs.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /usr/lib/debug//boot/kernel/linux.ko.debug...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/linux_common.ko...Reading symbols from /usr/lib/debug//boot/kernel/linux_common.ko.debug...done. done. Loaded symbols for /boot/kernel/linux_common.ko Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /usr/lib/debug//boot/kernel/linprocfs.ko.debug...done. done. Loaded symbols for /boot/kernel/linprocfs.ko Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from /usr/lib/debug//boot/kernel/tmpfs.ko.debug...done. done. Loaded symbols for /boot/kernel/tmpfs.ko Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from /usr/lib/debug//boot/kernel/fdescfs.ko.debug...done. done. Loaded symbols for /boot/kernel/fdescfs.ko #0 doadump (textdump=0) at pcpu.h:221 221 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=0) at pcpu.h:221 #1 0xffffffff8037c6b6 in db_fncall (dummy1=, dummy2=, dummy3=, dummy4=) at /usr/src/sys/ddb/db_command.c:568 #2 0xffffffff8037c14e in db_command (cmd_table=0x0) at /usr/src/sys/ddb/db_command.c:440 #3 0xffffffff8037bee4 in db_command_loop () at /usr/src/sys/ddb/db_command.c:493 #4 0xffffffff8037e97b in db_trap (type=, code=0) at /usr/src/sys/ddb/db_main.c:251 #5 0xffffffff80a5fc73 in kdb_trap (type=1, code=0, tf=) at /usr/src/sys/kern/subr_kdb.c:654 #6 0xffffffff80e69c81 in trap_fatal (frame=0xfffffe0859c63610, eva=) at /usr/src/sys/amd64/amd64/trap.c:829 #7 0xffffffff80e69951 in trap (frame=) at /usr/src/sys/amd64/amd64/trap.c:203 #8 0xffffffff80e498d7 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:234 #9 0xffffffff8240fef5 in cpu_lock () from /boot/kernel/opensolaris.ko #10 0xfffff804aaeb8000 in ?? () #11 0x0000000000000001 in ?? () #12 0xfffffe0859c63760 in ?? () #13 0xffffffff82125325 in vdev_mirror_io_start (zio=0xfffff8047a6d9000) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_mirror.c:475 Previous frame identical to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) From owner-freebsd-current@freebsd.org Wed Oct 28 00:00:21 2015 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 CD925A1FC0D for ; Wed, 28 Oct 2015 00:00:21 +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 AA27115BA; Wed, 28 Oct 2015 00:00:21 +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 DF86DB922; Tue, 27 Oct 2015 20:00:19 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Cc: Ed Maste , Glen Barber Subject: Re: HEADS-UP: Enabling WITH_DEBUG_FILES by default Date: Tue, 27 Oct 2015 16:54:34 -0700 Message-ID: <3948346.AvdWYvOr03@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: References: <20150212023912.GG1302@hub.FreeBSD.org> 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, 27 Oct 2015 20:00:20 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 28 Oct 2015 00:00:21 -0000 On Tuesday, October 27, 2015 06:09:37 PM Ed Maste wrote: > On 11 February 2015 at 21:39, Glen Barber wrote: > > Hi, > > > > Within the next 24 hours, I will merge the release-install-debug branch > > into head, which will enable building and installing stripped debugging > > files by default. > > > > In general, this should have no significant impact, but any fallout will > > be addressed as soon as possible after the merge. > > > > Those that do not want debugging files built/installed by default should > > add 'WITHOUT_DEBUG_FILES=1' to src.conf(5). This will also be noted in > > UPDATING. > > I want to pick this change up again. There are a few separate parts > under discussion: > > 1. Release build changes to support standalone debug > 2. Installer changes > 3. Switching debug files on by default > 4. Separating into two or more debug dist sets > > Glen's proposed merge from earlier this year included #1 through #3, > but was held up based on discussion in this thread. I propose that we > merge #1 and #2 now, since they're effectively a no-op if debug files > aren't enabled, but facilitate further testing. Sounds good. > Separating the debug dist sets (into runtime and binaries, or even > more fine-grained) requires coordination with the packaged base work, > and I suggest that we hold off on that project for now. Agreed. > I'd like to flip the default shortly after and continue refining it > with it enabled - we need to start finding and fix issues now in order > to have it ready for 11.0. I have a review open for the default > switch, in https://reviews.freebsd.org/D4018. All ahead full! I do think that packaged base is going to force us to revisit things quite a bit in that you won't necessarily just install the equivalent of base.txz all the time. Long term I do think that is the solution for folks wanting more fine-grained control over disk space as well as the ability to "fault in" symbols on demand. For whatever we are going to do for the graybeards like myself that will still use make, I think that the only knob you would need for 4 is runtime vs everything else where runtime is libs + rtld. Anything finer-grained than that should be handled by pkg(8) instead. For my part I already set WITH_DEBUG_FILES=yes in /etc/src.conf on just about all of my boxes and VMs (head or stable). -- John Baldwin From owner-freebsd-current@freebsd.org Wed Oct 28 02:44:14 2015 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 7EAF9A1FDFE for ; Wed, 28 Oct 2015 02:44:14 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 36B491835; Wed, 28 Oct 2015 02:44:14 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by qkgb2 with SMTP id b2so8852514qkg.0; Tue, 27 Oct 2015 19:44:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0Hjt0a699myztE2/I6cdeJI6qfxIZ7sRPehnBze4Ui0=; b=q9kAoJhfb8+JGdBgUdtfm4OtZ8VBA8O2eFNRwO1CWIc/Gdky4b+1kuQNNH9EnJ2OsE BU9DF2+cLX1L8A+w4BkDyjVP3o85vy9IEltci0TdZq8mpBnz5NadgGE7Lqe3gHjPQVmq P5x/g/t6bZG3Ztmuc+L8X1VqQ/PiMgcVADlDhE/60uVV7qeW5C8s6S9VexUaBRDXmo8S ZYeRJ52yBg3EIVBQJEzMXgcDn6DM07tz16WGUie4TXZbYcw9Qjna8s5zctajpiEAxf9Y 8g1wjMWq7b5pNGRpsZ6y5EJZkQtMh5COmhf2kOZxM+SmKZQA9JA7rG+r9FGA8lZUYRvQ MKVw== MIME-Version: 1.0 X-Received: by 10.55.23.170 with SMTP id 42mr7077377qkx.42.1446000253183; Tue, 27 Oct 2015 19:44:13 -0700 (PDT) Received: by 10.140.88.209 with HTTP; Tue, 27 Oct 2015 19:44:13 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 Oct 2015 19:44:13 -0700 Message-ID: Subject: Re: Coverity down? From: NGie Cooper To: Alan Somers Cc: FreeBSD CURRENT Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 28 Oct 2015 02:44:14 -0000 On Tue, Oct 27, 2015 at 1:11 PM, Alan Somers wrote: > I just noticed that our last Coverity scan happened on either July-6 > (according to my inbox) or June-26 (according to Coverity's website). > Prior to that, we seemed to get scanned about once per week. Does > anybody know why we haven't been scanned for so long? I can't figure > out what triggers a scan, but it seems like it should've happened by > now. +1 Is it due to svn moving? From owner-freebsd-current@freebsd.org Wed Oct 28 05:27:25 2015 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 85126A1FF5C for ; Wed, 28 Oct 2015 05:27:25 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 4471D13C4 for ; Wed, 28 Oct 2015 05:27:25 +0000 (UTC) (envelope-from sjg@juniper.net) Received: by mailman.ysv.freebsd.org (Postfix) id 4292AA1FF5B; Wed, 28 Oct 2015 05:27:25 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4220DA1FF5A for ; Wed, 28 Oct 2015 05:27:25 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0127.outbound.protection.outlook.com [207.46.100.127]) (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 D4D0A13C3; Wed, 28 Oct 2015 05:27:24 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from DM2PR0501CA0004.namprd05.prod.outlook.com (10.162.29.142) by BY2PR05MB064.namprd05.prod.outlook.com (10.242.34.152) with Microsoft SMTP Server (TLS) id 15.1.306.13; Wed, 28 Oct 2015 05:27:16 +0000 Received: from BY2FFO11OLC001.protection.gbl (2a01:111:f400:7c0c::144) by DM2PR0501CA0004.outlook.office365.com (2a01:111:e400:5148::14) with Microsoft SMTP Server (TLS) id 15.1.312.18 via Frontend Transport; Wed, 28 Oct 2015 05:27:15 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01b-sac.jnpr.net (66.129.239.18) by BY2FFO11OLC001.mail.protection.outlook.com (10.1.15.185) with Microsoft SMTP Server (TLS) id 15.1.306.13 via Frontend Transport; Wed, 28 Oct 2015 05:27:15 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01b-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 27 Oct 2015 22:27:14 -0700 Received: from chaos.jnpr.net (chaos.jnpr.net [172.21.16.28]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t9S5RDD88918; Tue, 27 Oct 2015 22:27:13 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from chaos (localhost [IPv6:::1]) by chaos.jnpr.net (Postfix) with ESMTP id 70E9C580A9; Tue, 27 Oct 2015 22:27:13 -0700 (PDT) To: Bryan Drewery CC: , Subject: Re: [CFT] Buildworld ccache support In-Reply-To: <561FC81B.1090309@FreeBSD.org> References: <561FC81B.1090309@FreeBSD.org> Comments: In-reply-to: Bryan Drewery message dated "Thu, 15 Oct 2015 08:36:59 -0700." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20482.1446010033.1@chaos> Date: Tue, 27 Oct 2015 22:27:13 -0700 Message-ID: <27231.1446010033@chaos> X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11OLC001; 1:dwB2Y1GG+6Twd+LdmunzTRKb8j4CGVpUW+bwr4SmNA7rcBpFJFSG/qYmtpEhfltyr1dcTW5bG1/c798FOGQAvP2IFBFnY9j9dz6XwMLhufcl9IjdfSv2vQNqLUAcex1ojbDLhDjmRvWrvYkJQadVAcC6VAbQfFRaMx8mDubPYu08mJuLphLnovfwIIitic80fN3FboQ8OzXUGSiwvVf+aM4e5asvl+3RpcfydizBckjT8mkCfBS0V4hFhtH8G7gVMO55xEC0Tl9NtPR/b8LzrklLSJG35R5pybg/7ObZyM1086B355gJmUBL8v52Ll472Cmt8GlFViRthYwXuLRXPQ== X-Forefront-Antispam-Report: CIP:66.129.239.18; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(199003)(189002)(24454002)(86362001)(11100500001)(92566002)(77096005)(450100001)(15975445007)(19580395003)(97736004)(5008740100001)(81156007)(50986999)(76176999)(47776003)(6806005)(2950100001)(117636001)(46406003)(5007970100001)(4001430100002)(76506005)(87936001)(110136002)(57986006)(106466001)(50466002)(189998001)(69596002)(19580405001)(33716001)(50226001)(5001960100002)(107886002)(97756001)(105596002)(23726002)(42262002)(62816006); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB064; H:p-emfe01b-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB064; 2:I0GbqC/ngOnC7VFD5uHJS4Apz1biCgS5id4qJr6FqaG52aqqcJYD/joMB1bIQu+OmLfULKpGj31T8WS+WArHkjyEXpnibXgxX7AdF39S/WAhS8kIe3MjLxMwrJybtaBWcndBYv+hT9NW2+rVooy3gE9dHbEvIGK6Sca2i0k2x5Y=; 3:QHei98pMq1U1We9FxIDew1XZFFTEkRDH6SJDrOOUs41Z8HZ6EoWGrTORiMiBNgvF0mZL3MjSNWeWnwc+tAbCRJExw9OO8VJhVQNSVEHZa6Wr+zQopAWixwCPNo/jRyUpyWjB8u8BHUjgGYcl4Uv8VBSIsXLTg+jDmSrWub6PgEU+LERCmC5qlFnbLQXnFgNLIj45BXRrvK8FxSxlGeUfgxnI4UT4BBdwc1pkQyf2okI=; 25:HrRnMFCRvXUBprSBihQaT4YD12RoOTM4rL4XZS6XPsnNg/q2FmmuVUMIG8lGu+qPWp7rVgHjickhjC1bDAr72gj3TO27B0A+j2N8jNMzyrgGuCHftHNbXOTWo+iH0X/9VVTRgbu1Kf42xrO7hfsHnx2esBUTT3yBcDDuWiD4PfWParBWQY5CDbbFPvl43ObCsxSUJ1ctRsJeybmZcxlhHVgE8DVauI/ub85ZXnhjcSMkZeRHxG89VRJCVnlKNjsn93PjdjspHvBHP4YTtYf+2w== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB064; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB064; 20:wBLK3MSXIejQTUa1FoxTNIR2ijrV2yShjJCR5muRusInD4L2w8LKXBPnPE4NTmhu/+0xkClbkwFhgjT0aHIn62KGXHQbwil0mYmIvFotvPMQZGuFfOHev0juPC/yegZU/ia7FWildEik0To0x6syXgd7Jx8fi060VrVvtVKDT83I+vOP1HketdHGB0m7v5clvqrjh4yfCsVUULvphl34nW9mUnJf1HDznR7S6G/SYMLDnLgmTeMfIcn90DVWRh3fvG/pt1pVcen5P9bORcQOhEGpVnOb6RQAzPVPzDwLw0yEYOpRwVgfNP87iJEH73vjSdeuW9DW7S4r4e99Z1J+7qxLXFaPzAZt/XS08yIheaRZ1CPf8OnyGTore9sYgRgHuGJEmu4OhmRoFtPcIxa29kWWB+cl1JQGSpxC848SwGyvq0q0b8XQL8CjNrHW3j7vXhrCb4j7i8HJ85YYflHlIDB70q8ZL/EMEqy2Z83SoNpAhnUHf9WBVoOm0CJ0w/SI; 4:SBYx7ytZ1IO+1ugj9T6zWSpaRIpm1N4JQ1gU7xi6310ODmoqhyfX2snhWZj7zrpt0SSGdlgjWuDMdPgL8YLvxDCzyq5H1LkyaViZhnSPOc8T2nTrFnG4Xldfkq/YKvspFjAO2CaZkYpFMUIvrPS/sN1LFlM72uUwW2lW7pFIbh2x/cMGVhSkS7M9p8hFqc9QIjCNg7imootvOngxHeT9ejTc2goZEU/c5oJ9ijE7KALB1DmVrcQfw51bN/+pTKwab2VA3pZgDn7XtvMhP1awrcp5xCfwU6h7SxFp1ey5yycrYkeWepYG90qi67+FBHn88XnqpmvXvdK1SD86/38YDF8X9p3yToF1u9QqGmudDlKvUl5N8U80Fl6vxmtJm3porP4tZ9iI6HCKQkp8eLBg+g== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501044)(102215026); SRVR:BY2PR05MB064; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB064; X-Forefront-PRVS: 0743E8D0A6 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR05MB064; 23:4fc4QOl/O8qVtG0NIVJguX75P7SlYXMIQ/D42luRfK?= =?us-ascii?Q?7q4Rpjb80I70QAsySaBjuOKgA8uQEsEEa1+243pfPbCvzWQ7PCbD4oR1CULG?= =?us-ascii?Q?tAjo++ZLdR5wgN55rFJClHES2g5FFjRcxbBgzvJTBg1KvQCL0se99u90riS7?= =?us-ascii?Q?C8Oftshf3DZERilo9IP0xcPUIUIn/TnKiJcHMR8jKSjeGBEOmzur5LUIcRbe?= =?us-ascii?Q?X7Sm1MP8oAKRdavDGgCzcA2avr5/8wuHSo1946PfTXQ9Rf382tPSXsEym923?= =?us-ascii?Q?vsuWR/JwwzwAbIXTmMW2BLNS0asnd7x9EQiQIrMvoe83yZFcL/sglwDyaljw?= =?us-ascii?Q?DINQ3dqYMQ3svI+ymF8i2h2O/KPjzuSxtOeBOOiQ7+Ufb7VyIrkUlpkvOThF?= =?us-ascii?Q?NWcX+jVzFd15aAYxelwhd+C+DH0qBFpyo5tw+AI+tTvr/nT5f/4lyEg1m1nS?= =?us-ascii?Q?yyB6w7IXv+qGF4fssv4wj5g3sgng6Ozz0MYEcvbl/2ianYCtoCbW7mVd73eP?= =?us-ascii?Q?Rf6Ysgo4x1j8BSNjWNK0lo5iHqgD45L+7C52JLsdrj+476BNrn0pMMcOT7Ak?= =?us-ascii?Q?57U6cA6RuEcPZNUY8GH6gGF1k5k4USn2QqAAc7OfJ36C2U3WYdbgaARZs837?= =?us-ascii?Q?T66a1jNL/TeGH8baY81nyKNDZ6E7RF2PGj6KbiZLP5/KyvaSDbbHXSaQrk29?= =?us-ascii?Q?OhAnQI7kboKbLLgVcbhGEk0FU5tHnmazuUPgjJaERx5ECD0K6Do2vjoJyVfN?= =?us-ascii?Q?e5F0C4MJb8hL9jPqVT6h7ugeFHinb90k+wiWgECS51LAFPlKLEPCNip6Qbva?= =?us-ascii?Q?n7FoCOSP+Ay5HGlo6ZyvGAkvAFOK2EwfuY0RRhDaaQke6c8S8GWS6zaYPIxw?= =?us-ascii?Q?X89QAqY2WAiD6gn4HiJFumT57qNHIX3JQB508LY08J6gl7d3udZPXMKMU0Tg?= =?us-ascii?Q?0snIL2xWFbpMPxorg9vJ1VYj6i1uPOZ/jGZbpBpY1blxhaRdFWTWCH9yTAmg?= =?us-ascii?Q?5OdOyACVGRnMjpOyZHxN1U+A2Ts9ZrqlAwPbvfrNFpFKbZvOng9k60GgbHee?= =?us-ascii?Q?Do6Zx89sADmHGe3plpRLDuiLACE2ADtLkaQJD6Y6suGakPnHtjSSuQP8GaRr?= =?us-ascii?Q?xL1Aaxu7+JylonarzD+Z0e9rXerB3W?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB064; 5:zfaePEvwjnjCZzvwYMDGhQErIKmSIODUmxWTAvuEi1CM9HfKFkoaMD3N4llyym4N9j4DfzroCnETu0nkvTudD4hRycAjQgwrn02/dN6EHUfDBhA/2xeQi+kCHFD8vYfh6yEZeCAXFFor/2JO5E0wtw==; 24:4pViFAkMeziSIjD0bE+Qt3/yILvzlTREb6TnkLlhyeO6ME8MrTnJp8LFwEXzf+dnL2w7FPX2VQQkFidqVkPlDdn71RFhSI2wO0RIERrsyJQ=; 20:RAui1BB2/dzKD2koGrANpyK/4G3BD6F+CrB/Ngq3nwNvh9XXtcJopzqwNsHwMcUwADRnSyEeht3ecourRw1rlA== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Oct 2015 05:27:15.4560 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18]; Helo=[p-emfe01b-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB064 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 28 Oct 2015 05:27:25 -0000 Bryan Drewery wrote: > https://people.freebsd.org/~bdrewery/patches/world-ccache.diff In the Junos build - where we used ccache for quite some time I did: _CC := ${CC} CC = ${CCACHE_ENV} ${_CC} Since sometimes you want the compiler without ccache - eg when linking. That needs to happen after CC is determined of course. If the include of bsd.mkopt.mk were moved to after the inlcude of local.sys.env.mk, then you could simply: __DEFAULT_NO_OPTIONS+= CCACHE_BUILD there or in src.sys.env.mk > > To use just set WITH_CCACHE_BUILD= in src.conf or make.conf. I > purposely matched it to the same as the ports build. > > Thanks! From owner-freebsd-current@freebsd.org Wed Oct 28 09:53:34 2015 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 48324A1FA8A for ; Wed, 28 Oct 2015 09:53:34 +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 E2C611EA4; Wed, 28 Oct 2015 09:53:33 +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 t9S9rQhx096292 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 28 Oct 2015 11:53:26 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua t9S9rQhx096292 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id t9S9rQjw096291; Wed, 28 Oct 2015 11:53:26 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 28 Oct 2015 11:53:26 +0200 From: Konstantin Belousov To: Don Lewis Cc: freebsd-current@FreeBSD.org Subject: Re: 11.0-CURRENT r290039 privileged instruction fault while in kernel mode Message-ID: <20151028095326.GD2257@kib.kiev.ua> References: <201510272309.t9RN9SPc018751@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201510272309.t9RN9SPc018751@gw.catspoiler.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.20 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, 28 Oct 2015 09:53:34 -0000 On Tue, Oct 27, 2015 at 04:09:28PM -0700, Don Lewis wrote: > I just got this crash while running poudriere on a freshly upgraded > 11.0-CURRENT machine. The instruction pointer value looks pretty > strange. > > > FreeBSD zipper.catspoiler.org 11.0-CURRENT FreeBSD 11.0-CURRENT #30 r290039: Tue Oct 27 00:08:00 PDT 2015 dl@zipper.catspoiler.org:/usr/obj/usr/src/sys/GENERIC amd64 > > panic: > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > > > Fatal trap 1: privileged instruction fault while in kernel mode > cpuid = 4; apic id = 14 > instruction pointer = 0x20:0xffffffff8240fef5 What is the instruction at the reported address ? > stack pointer = 0x28:0xfffffe0859c636c0 > frame pointer = 0x28:0xfffffe0859c636e0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 0 (zio_free_issue_2_9) > > Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /usr/lib/debug//boot/kernel/zfs.ko.debug...done. > done. > Loaded symbols for /boot/kernel/zfs.ko > Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /usr/lib/debug//boot/kernel/opensolaris.ko.debug...done. > done. > Loaded symbols for /boot/kernel/opensolaris.ko > Reading symbols from /boot/kernel/geom_mirror.ko...Reading symbols from /usr/lib/debug//boot/kernel/geom_mirror.ko.debug...done. > done. > Loaded symbols for /boot/kernel/geom_mirror.ko > Reading symbols from /boot/modules/vboxdrv.ko...done. > Loaded symbols for /boot/modules/vboxdrv.ko > Reading symbols from /boot/modules/vboxnetflt.ko...done. > Loaded symbols for /boot/modules/vboxnetflt.ko > Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from /usr/lib/debug//boot/kernel/netgraph.ko.debug...done. > done. > Loaded symbols for /boot/kernel/netgraph.ko > Reading symbols from /boot/kernel/ng_ether.ko...Reading symbols from /usr/lib/debug//boot/kernel/ng_ether.ko.debug...done. > done. > Loaded symbols for /boot/kernel/ng_ether.ko > Reading symbols from /boot/modules/vboxnetadp.ko...done. > Loaded symbols for /boot/modules/vboxnetadp.ko > Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from /usr/lib/debug//boot/kernel/nullfs.ko.debug...done. > done. > Loaded symbols for /boot/kernel/nullfs.ko > Reading symbols from /boot/kernel/linux.ko...Reading symbols from /usr/lib/debug//boot/kernel/linux.ko.debug...done. > done. > Loaded symbols for /boot/kernel/linux.ko > Reading symbols from /boot/kernel/linux_common.ko...Reading symbols from /usr/lib/debug//boot/kernel/linux_common.ko.debug...done. > done. > Loaded symbols for /boot/kernel/linux_common.ko > Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /usr/lib/debug//boot/kernel/linprocfs.ko.debug...done. > done. > Loaded symbols for /boot/kernel/linprocfs.ko > Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from /usr/lib/debug//boot/kernel/tmpfs.ko.debug...done. > done. > Loaded symbols for /boot/kernel/tmpfs.ko > Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from /usr/lib/debug//boot/kernel/fdescfs.ko.debug...done. > done. > Loaded symbols for /boot/kernel/fdescfs.ko > #0 doadump (textdump=0) at pcpu.h:221 > 221 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=0) at pcpu.h:221 > #1 0xffffffff8037c6b6 in db_fncall (dummy1=, > dummy2=, dummy3=, > dummy4=) at /usr/src/sys/ddb/db_command.c:568 > #2 0xffffffff8037c14e in db_command (cmd_table=0x0) > at /usr/src/sys/ddb/db_command.c:440 > #3 0xffffffff8037bee4 in db_command_loop () > at /usr/src/sys/ddb/db_command.c:493 > #4 0xffffffff8037e97b in db_trap (type=, code=0) > at /usr/src/sys/ddb/db_main.c:251 > #5 0xffffffff80a5fc73 in kdb_trap (type=1, code=0, tf=) > at /usr/src/sys/kern/subr_kdb.c:654 > #6 0xffffffff80e69c81 in trap_fatal (frame=0xfffffe0859c63610, > eva=) at /usr/src/sys/amd64/amd64/trap.c:829 > #7 0xffffffff80e69951 in trap (frame=) > at /usr/src/sys/amd64/amd64/trap.c:203 > #8 0xffffffff80e498d7 in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:234 > #9 0xffffffff8240fef5 in cpu_lock () from /boot/kernel/opensolaris.ko > #10 0xfffff804aaeb8000 in ?? () > #11 0x0000000000000001 in ?? () > #12 0xfffffe0859c63760 in ?? () > #13 0xffffffff82125325 in vdev_mirror_io_start (zio=0xfffff8047a6d9000) > at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_mirror.c:475 From owner-freebsd-current@freebsd.org Wed Oct 28 10:43:13 2015 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 EFB26A1F76F for ; Wed, 28 Oct 2015 10:43:13 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 780FB131A; Wed, 28 Oct 2015 10:43:13 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by lbbec13 with SMTP id ec13so2535534lbb.0; Wed, 28 Oct 2015 03:43:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fUVYcgInR9KH+gNn6B6Kxa3GXe01fsc/Pu1CD2NZivc=; b=ykYmNDHP5277NwMa1ap0zno9A7sX5B3TjqszSN5WijX8icX+3/5mVM5TYzomTt5kfe FYZpj98InskUYx7wryp8sN92owAikFtLmXqKofArL6FrcXCfcBXEQUOOzomjIFzi7bS3 mmoUXJDX5KzLJyBpoq61LEwS6RFu0Eq/04onhmsdoVAAnw3aI7E8GFfHRwD7j8D70OaW X6GwPyhKvlzcgHkYBCD1j9WxzSYQumNzysWVlNQb6BnQJhuMuhiuEB1+thVapzoHGKeU ZAEXrIDkYn0NF8fok0XTT4dZcmpHln0jMXsqIk76mu3u/FxbQuZfQvfuydtl4XTv9aSS 7/MQ== MIME-Version: 1.0 X-Received: by 10.112.218.42 with SMTP id pd10mr22995119lbc.114.1446028991398; Wed, 28 Oct 2015 03:43:11 -0700 (PDT) Received: by 10.25.144.136 with HTTP; Wed, 28 Oct 2015 03:43:11 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 Oct 2015 11:43:11 +0100 Message-ID: Subject: Re: Coverity down? From: =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= To: NGie Cooper , Alan Somers Cc: FreeBSD CURRENT Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Wed, 28 Oct 2015 11:26:25 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 28 Oct 2015 10:43:14 -0000 2015-10-28 3:44 GMT+01:00 NGie Cooper : > On Tue, Oct 27, 2015 at 1:11 PM, Alan Somers wrote: >> I just noticed that our last Coverity scan happened on either July-6 >> (according to my inbox) or June-26 (according to Coverity's website). >> Prior to that, we seemed to get scanned about once per week. Does >> anybody know why we haven't been scanned for so long? I can't figure >> out what triggers a scan, but it seems like it should've happened by >> now. > > +1 > > Is it due to svn moving? No, it's a stupid bug in our crond and/or nslcd and LDAP handling. The setup is as follows: - a server running 24/7 with `uqs` being a user ID that is stored in LDAP - a cronjob is set up to run coverity scan twice a week - nslcd is running and getent passwd will list all local and LDAP users - - cron somehow no longer sees any of the LDAP users and thus is not executing any user crontabs, I think this is due to the connection to nslcd breaking - restarting crond fixes that (for a while) So my box was last restarted 94d ago, which was July 26 and it seems that it even that reboot and cron restart didn't help. I've now put in a crontab entry, to have cron restart cron daily (no kidding), let's see if that fixes things. Though the best option would be to move this off my box, run it with a local account via cron that should be more robust. Or someone could fix our cron, because this is really annoying. Anyway, thanks for letting me know, expect some more coverity runs by the end of the week! Cheers, Uli From owner-freebsd-current@freebsd.org Wed Oct 28 11:32:30 2015 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 0D0C4A1F7B0 for ; Wed, 28 Oct 2015 11:32:30 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (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 89B2D127C; Wed, 28 Oct 2015 11:32:29 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by lffz202 with SMTP id z202so2146439lff.3; Wed, 28 Oct 2015 04:32:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=ofD/+Fknu1YHMT3mWRqvHzRu1fCN0+ujNPGE60Uk788=; b=UJu/y+e4WpNvwUaiBeIkVaMF6fG93+hVx0URv0szN56WLpRJSXA8vGSMTPBMuaVoCm fJAWKadAeRqDTlitIcZNVdsIol6MC2vDxwyt4sDcZVP2RMjBtbCm6Adrwwo2bR5K7kF6 PrbkrA9peTg6AQ48ZWyzbX1yzxD4Kp2ReNzlRbrZmu8t6c1wBYwSoyvxWGe5/qtKcKba 4X0blstLuwz2xrvxJgWsN2phC6tV+Ls3mAtp1VaqILh70mwDt9W0346c18NDALNwf9WN sI83QIZICFC3j8SW+BwupD0E7k82kfxWKsFVATb4stfq2buqXvb3CIk0HT73yDUVfi9c DPow== MIME-Version: 1.0 X-Received: by 10.25.162.21 with SMTP id l21mr15064961lfe.70.1446031947354; Wed, 28 Oct 2015 04:32:27 -0700 (PDT) Sender: uspoerlein@gmail.com Received: by 10.25.144.136 with HTTP; Wed, 28 Oct 2015 04:32:27 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 Oct 2015 12:32:27 +0100 X-Google-Sender-Auth: ynlSmVUMFtuMNarWvI11bZe_VLQ Message-ID: Subject: Re: Coverity down? From: =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= To: NGie Cooper , Alan Somers Cc: FreeBSD CURRENT Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 28 Oct 2015 11:32:30 -0000 [resent to avoid moderator approval] 2015-10-28 11:43 GMT+01:00 Ulrich Sp=C3=B6rlein : > 2015-10-28 3:44 GMT+01:00 NGie Cooper : >> On Tue, Oct 27, 2015 at 1:11 PM, Alan Somers wrote= : >>> I just noticed that our last Coverity scan happened on either July-6 >>> (according to my inbox) or June-26 (according to Coverity's website). >>> Prior to that, we seemed to get scanned about once per week. Does >>> anybody know why we haven't been scanned for so long? I can't figure >>> out what triggers a scan, but it seems like it should've happened by >>> now. >> >> +1 >> >> Is it due to svn moving? > > No, it's a stupid bug in our crond and/or nslcd and LDAP handling. The > setup is as follows: > > - a server running 24/7 with `uqs` being a user ID that is stored in LDAP > - a cronjob is set up to run coverity scan twice a week > - nslcd is running and getent passwd will list all local and LDAP users > - > - cron somehow no longer sees any of the LDAP users and thus is not > executing any user crontabs, I think this is due to the connection to > nslcd breaking > - restarting crond fixes that (for a while) > > So my box was last restarted 94d ago, which was July 26 and it seems > that it even that reboot and cron restart didn't help. I've now put in > a crontab entry, to have cron restart cron daily (no kidding), let's > see if that fixes things. > > Though the best option would be to move this off my box, run it with a > local account via cron that should be more robust. Or someone could > fix our cron, because this is really annoying. > > Anyway, thanks for letting me know, expect some more coverity runs by > the end of the week! > > Cheers, > Uli From owner-freebsd-current@freebsd.org Wed Oct 28 13:12:27 2015 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 BE975A1F8FC for ; Wed, 28 Oct 2015 13:12:27 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.37]) (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 7E3E31764 for ; Wed, 28 Oct 2015 13:12:27 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from [78.35.176.193] (helo=fabiankeil.de) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1ZrQJ4-0000Ag-DU; Wed, 28 Oct 2015 13:58:22 +0100 Date: Wed, 28 Oct 2015 13:58:21 +0100 From: Fabian Keil To: freebsd-current@freebsd.org Cc: "Steven Hartland" , Xin Li , "Alexander Motin" Subject: Re: ZFS-related panic: "possible" spa->spa_errlog_lock deadlock Message-ID: <20151028135821.0d375ec5@fabiankeil.de> In-Reply-To: <540C8039.7010309@delphij.net> References: <492dbacb.5942cc9b@fabiankeil.de> <540C66AC.8070809@delphij.net> <4fa875ba.3cc970d7@fabiankeil.de> <540C8039.7010309@delphij.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/n/RaV4NiQBkXCK0r/1ymFqH"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 28 Oct 2015 13:12:27 -0000 --Sig_/n/RaV4NiQBkXCK0r/1ymFqH Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Xin Li wrote: > On 9/7/14 11:23 PM, Fabian Keil wrote: > > Xin Li wrote: > > =20 > >> On 9/7/14 9:02 PM, Fabian Keil wrote: =20 > >>> Using a kernel built from FreeBSD 11.0-CURRENT r271182 I got > >>> the following panic yesterday: > >>>=20 > >>> [...] Unread portion of the kernel message buffer: [6880] > >>> panic: deadlkres: possible deadlock detected for > >>> 0xfffff80015289490, blocked for 1800503 ticks =20 > >>=20 > >> Any chance to get all backtraces (e.g. thread apply all bt full > >> 16)? I think a different thread that held the lock have been > >> blocked, probably related to your disconnected vdev. =20 > >=20 > > Output of "thread apply all bt full 16" is available at:=20 > > http://www.fabiankeil.de/tmp/freebsd/kgdb-output-spa_errlog_lock-deadlo= ck.txt > > > > A lot of the backtraces prematurely end with "Cannot access memory > > at address", therefore I also added "thread apply all bt" output. > >=20 > > Apparently there are at least two additional threads blocking below > > spa_get_stats(): [...] > Yes, thread 1182 owned the lock and is waiting for the zio be done. > Other threads that wanted the lock would have to wait. >=20 > I don't have much clue why the system entered this state, however, as > the operations should have errored out (the GELI device is gone on > 21:44:56 based on your log, which suggests all references were closed) > instead of waiting. Thanks for the responses. I finally found the time to analyse the problem which seems to be that spa_sync() requires at least one writeable vdev to complete, but holds the lock(s) required to remove or bring back vdevs. Letting spa_sync() drop the lock and wait for at least one vdev to become writeable again seems to make the problem unreproducible for me, but probably merely shrinks the race window and thus is not a complete solution. For details see: https://www.fabiankeil.de/sourcecode/electrobsd/ZFS-Optionally-let-spa_sync= -wait-for-writable-vdev.diff (Experimental, only lightly tested) Fabian --Sig_/n/RaV4NiQBkXCK0r/1ymFqH Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlYwxm0ACgkQBYqIVf93VJ2AngCfePGkoeHRWCqRLVT27oFZS/bp vUEAnjYV7S6jmWHQVMYvXEJCN3//79k6 =wBhO -----END PGP SIGNATURE----- --Sig_/n/RaV4NiQBkXCK0r/1ymFqH-- From owner-freebsd-current@freebsd.org Wed Oct 28 14:51:26 2015 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 9EE7AA204DC for ; Wed, 28 Oct 2015 14:51:26 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (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 6EB381BC2 for ; Wed, 28 Oct 2015 14:51:26 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by obbza9 with SMTP id za9so7993717obb.1 for ; Wed, 28 Oct 2015 07:51:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=8/jAAy9AG7qq/7RAULp6dcQCsx9Gq0uxftIn/Izc60s=; b=Z5KFHtBlGixMhTU4vbkiTdXROTNEmCG3rKY5nrG0NPHDBUps3E0KaUorrtLghgZfoB ScfoPJGHbWtTEPICvOo5uporJkTMJ/xoDzUeHUCvXcVMPE3kfLOnL36Jsn+itAweSZZN ivNvCr1Sz0MuOc1kN71S+lBI2pWTFy4uBoBQnHcco6Z2ED4WO+PI2cfh/Jb9XIPb2lMh Ly1211D3Lnl3VMpX1MsDMaEYJoAyom495TT1gUs60eHOPG0eyKn2va+PeqPZrcTjtXkG E1svbmTnlzIxuIzJe7lD/NTccwDJSA/zDlLfq/RHGnLkBmLA0Cw2U7nAwMauN7UuBxxm TbSA== MIME-Version: 1.0 X-Received: by 10.182.153.101 with SMTP id vf5mr7144225obb.81.1446043885353; Wed, 28 Oct 2015 07:51:25 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.202.1.206 with HTTP; Wed, 28 Oct 2015 07:51:25 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 Oct 2015 08:51:25 -0600 X-Google-Sender-Auth: S-YmZqgQN8AUbl_Twp1mwfeNLIA Message-ID: Subject: Re: Coverity down? From: Alan Somers To: =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= Cc: NGie Cooper , FreeBSD CURRENT Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 28 Oct 2015 14:51:26 -0000 On Wed, Oct 28, 2015 at 4:43 AM, Ulrich Sp=C3=B6rlein wrote: > 2015-10-28 3:44 GMT+01:00 NGie Cooper : >> On Tue, Oct 27, 2015 at 1:11 PM, Alan Somers wrote= : >>> I just noticed that our last Coverity scan happened on either July-6 >>> (according to my inbox) or June-26 (according to Coverity's website). >>> Prior to that, we seemed to get scanned about once per week. Does >>> anybody know why we haven't been scanned for so long? I can't figure >>> out what triggers a scan, but it seems like it should've happened by >>> now. >> >> +1 >> >> Is it due to svn moving? > > No, it's a stupid bug in our crond and/or nslcd and LDAP handling. The > setup is as follows: > > - a server running 24/7 with `uqs` being a user ID that is stored in LDAP > - a cronjob is set up to run coverity scan twice a week > - nslcd is running and getent passwd will list all local and LDAP users > - > - cron somehow no longer sees any of the LDAP users and thus is not > executing any user crontabs, I think this is due to the connection to > nslcd breaking > - restarting crond fixes that (for a while) > > So my box was last restarted 94d ago, which was July 26 and it seems > that it even that reboot and cron restart didn't help. I've now put in > a crontab entry, to have cron restart cron daily (no kidding), let's > see if that fixes things. > > Though the best option would be to move this off my box, run it with a > local account via cron that should be more robust. Or someone could > fix our cron, because this is really annoying. > > Anyway, thanks for letting me know, expect some more coverity runs by > the end of the week! > > Cheers, > Uli Looking forward to it. Muchas gracias, Ulrich. -Alan From owner-freebsd-current@freebsd.org Wed Oct 28 17:16:21 2015 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 B4E1DA1E957 for ; Wed, 28 Oct 2015 17:16:21 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 963511B7A for ; Wed, 28 Oct 2015 17:16:21 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id t9SHGCdJ021372; Wed, 28 Oct 2015 10:16:16 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201510281716.t9SHGCdJ021372@gw.catspoiler.org> Date: Wed, 28 Oct 2015 10:16:12 -0700 (PDT) From: Don Lewis Subject: Re: 11.0-CURRENT r290039 privileged instruction fault while in kernel mode To: kostikbel@gmail.com cc: freebsd-current@FreeBSD.org In-Reply-To: <20151028095326.GD2257@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 28 Oct 2015 17:16:21 -0000 On 28 Oct, Konstantin Belousov wrote: > On Tue, Oct 27, 2015 at 04:09:28PM -0700, Don Lewis wrote: >> I just got this crash while running poudriere on a freshly upgraded >> 11.0-CURRENT machine. The instruction pointer value looks pretty >> strange. >> >> >> FreeBSD zipper.catspoiler.org 11.0-CURRENT FreeBSD 11.0-CURRENT #30 r290039: Tue Oct 27 00:08:00 PDT 2015 dl@zipper.catspoiler.org:/usr/obj/usr/src/sys/GENERIC amd64 >> >> panic: >> >> GNU gdb 6.1.1 [FreeBSD] >> Copyright 2004 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and you are >> welcome to change it and/or distribute copies of it under certain conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for details. >> This GDB was configured as "amd64-marcel-freebsd"... >> >> Unread portion of the kernel message buffer: >> >> >> Fatal trap 1: privileged instruction fault while in kernel mode >> cpuid = 4; apic id = 14 >> instruction pointer = 0x20:0xffffffff8240fef5 > What is the instruction at the reported address ? (kgdb) disassemble/r Dump of assembler code for function cpu_lock: 0xffffffff8240fef0 <+0>: 25 bb 40 82 ff and $0xff8240bb,%eax => 0xffffffff8240fef5 <+5>: ff (bad) 0xffffffff8240fef6 <+6>: ff (bad) 0xffffffff8240fef7 <+7>: ff 00 incl (%rax) 0xffffffff8240fef9 <+9>: 00 71 02 add %dh,0x2(%rcx) 0xffffffff8240fefc <+12>: 00 00 add %al,(%rax) 0xffffffff8240fefe <+14>: 00 00 add %al,(%rax) 0xffffffff8240ff00 <+16>: 00 00 add %al,(%rax) 0xffffffff8240ff02 <+18>: 00 00 add %al,(%rax) 0xffffffff8240ff04 <+20>: 00 00 add %al,(%rax) 0xffffffff8240ff06 <+22>: 00 00 add %al,(%rax) 0xffffffff8240ff08 <+24>: 01 00 add %eax,(%rax) 0xffffffff8240ff0a <+26>: 00 00 add %al,(%rax) 0xffffffff8240ff0c <+28>: 00 00 add %al,(%rax) 0xffffffff8240ff0e <+30>: 00 00 add %al,(%rax) End of assembler dump. From owner-freebsd-current@freebsd.org Wed Oct 28 17:32:24 2015 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 5A632A1ED25 for ; Wed, 28 Oct 2015 17:32:24 +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 01C0317E2; Wed, 28 Oct 2015 17:32: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 t9SHWIjT066362 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 28 Oct 2015 19:32:18 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua t9SHWIjT066362 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id t9SHWIM9066361; Wed, 28 Oct 2015 19:32:18 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 28 Oct 2015 19:32:18 +0200 From: Konstantin Belousov To: Don Lewis Cc: freebsd-current@FreeBSD.org Subject: Re: 11.0-CURRENT r290039 privileged instruction fault while in kernel mode Message-ID: <20151028173218.GN2257@kib.kiev.ua> References: <20151028095326.GD2257@kib.kiev.ua> <201510281716.t9SHGCdJ021372@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201510281716.t9SHGCdJ021372@gw.catspoiler.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.20 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, 28 Oct 2015 17:32:24 -0000 On Wed, Oct 28, 2015 at 10:16:12AM -0700, Don Lewis wrote: > On 28 Oct, Konstantin Belousov wrote: > > On Tue, Oct 27, 2015 at 04:09:28PM -0700, Don Lewis wrote: > >> I just got this crash while running poudriere on a freshly upgraded > >> 11.0-CURRENT machine. The instruction pointer value looks pretty > >> strange. > >> > >> > >> FreeBSD zipper.catspoiler.org 11.0-CURRENT FreeBSD 11.0-CURRENT #30 r290039: Tue Oct 27 00:08:00 PDT 2015 dl@zipper.catspoiler.org:/usr/obj/usr/src/sys/GENERIC amd64 > >> > >> panic: > >> > >> GNU gdb 6.1.1 [FreeBSD] > >> Copyright 2004 Free Software Foundation, Inc. > >> GDB is free software, covered by the GNU General Public License, and you are > >> welcome to change it and/or distribute copies of it under certain conditions. > >> Type "show copying" to see the conditions. > >> There is absolutely no warranty for GDB. Type "show warranty" for details. > >> This GDB was configured as "amd64-marcel-freebsd"... > >> > >> Unread portion of the kernel message buffer: > >> > >> > >> Fatal trap 1: privileged instruction fault while in kernel mode > >> cpuid = 4; apic id = 14 > >> instruction pointer = 0x20:0xffffffff8240fef5 > > What is the instruction at the reported address ? > > (kgdb) disassemble/r > Dump of assembler code for function cpu_lock: > 0xffffffff8240fef0 <+0>: 25 bb 40 82 ff and $0xff8240bb,%eax > => 0xffffffff8240fef5 <+5>: ff (bad) > 0xffffffff8240fef6 <+6>: ff (bad) > 0xffffffff8240fef7 <+7>: ff 00 incl (%rax) > 0xffffffff8240fef9 <+9>: 00 71 02 add %dh,0x2(%rcx) > 0xffffffff8240fefc <+12>: 00 00 add %al,(%rax) > 0xffffffff8240fefe <+14>: 00 00 add %al,(%rax) > 0xffffffff8240ff00 <+16>: 00 00 add %al,(%rax) > 0xffffffff8240ff02 <+18>: 00 00 add %al,(%rax) > 0xffffffff8240ff04 <+20>: 00 00 add %al,(%rax) > 0xffffffff8240ff06 <+22>: 00 00 add %al,(%rax) > 0xffffffff8240ff08 <+24>: 01 00 add %eax,(%rax) > 0xffffffff8240ff0a <+26>: 00 00 add %al,(%rax) > 0xffffffff8240ff0c <+28>: 00 00 add %al,(%rax) > 0xffffffff8240ff0e <+30>: 00 00 add %al,(%rax) > End of assembler dump. Oh, I see. cpu_lock is mutex, dump above demonstrates is cleanly. Most likely, something overwrote some pointer to a function with the address. You probably have to bisect. From owner-freebsd-current@freebsd.org Wed Oct 28 18:43:35 2015 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 3A932A1FD09 for ; Wed, 28 Oct 2015 18:43:35 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 1BF1E1FDD for ; Wed, 28 Oct 2015 18:43:35 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 1B5C8A1FD08; Wed, 28 Oct 2015 18:43:35 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 19EF7A1FD07 for ; Wed, 28 Oct 2015 18:43:35 +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 001161FDC; Wed, 28 Oct 2015 18:43:34 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id EE93B1637; Wed, 28 Oct 2015 18:43:34 +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 AB202166E7; Wed, 28 Oct 2015 18:43:34 +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 BXINV7SbzKYc; Wed, 28 Oct 2015 18:43:30 +0000 (UTC) Subject: Re: [CFT] Buildworld ccache support DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com CF628166E1 References: <561FC81B.1090309@FreeBSD.org> <27231.1446010033@chaos> Cc: "Simon J. Gerraty" , current@freebsd.org From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <5631174B.7070609@FreeBSD.org> Date: Wed, 28 Oct 2015 11:43:23 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <27231.1446010033@chaos> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tUlKtk0Hbi7VNdef1XpkQJ2di7SExtdc5" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 28 Oct 2015 18:43:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tUlKtk0Hbi7VNdef1XpkQJ2di7SExtdc5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 10/27/2015 10:27 PM, Simon J. Gerraty wrote: > Bryan Drewery wrote: >> https://people.freebsd.org/~bdrewery/patches/world-ccache.diff >=20 > In the Junos build - where we used ccache for quite some time > I did: >=20 > _CC :=3D ${CC} > CC =3D ${CCACHE_ENV} ${_CC} >=20 > Since sometimes you want the compiler without ccache - eg when linking.= Yes, I ended up changing the patch significantly to avoid using it for mkdep and linking. I moved away from using PATH as well since it is obscure about whether ccache is being used or not. I now always modify C= C. >=20 > That needs to happen after CC is determined of course. >=20 > If the include of bsd.mkopt.mk were moved to after the inlcude of > local.sys.env.mk, then you could simply: >=20 > __DEFAULT_NO_OPTIONS+=3D CCACHE_BUILD >=20 > there or in src.sys.env.mk >=20 >> >> To use just set WITH_CCACHE_BUILD=3D in src.conf or make.conf. I >> purposely matched it to the same as the ports build. >> >> Thanks! --=20 Regards, Bryan Drewery --tUlKtk0Hbi7VNdef1XpkQJ2di7SExtdc5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJWMRdSAAoJEDXXcbtuRpfPzp0H+wTyXQIkHnBI0foTsJSZkrFf 5JnB/HjeBLUfbU3uAkojuAQuO4A/Rv2nNHmxiVjtoXWHyAnEDxkFjpRLc79YYqh/ SpMqQamMdJZJgUnEFwrHoy8necIG+4QZTihRrX9SUeTZgJD1A2JNeDcHxaWlfgGg snzTYcuc3s6mqgHCQEySbN/uCtgJ3bwDBTQItwAuiM+WpKTtJDQWQKBz2uhC+VlM 2lfiBps97wLzLDCUhEIfx3gvnk6XtUQ8Gv/bIQ68Sc9hRMeuyAWPJnJ51APYLCf5 Tk/sA9V/o9Hg/D2FxTf1U47kfhllo0pQb14PkOjW4+zYQ7v1AMoYC7XWdh5HvLg= =WR8s -----END PGP SIGNATURE----- --tUlKtk0Hbi7VNdef1XpkQJ2di7SExtdc5-- From owner-freebsd-current@freebsd.org Wed Oct 28 21:12:42 2015 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 E925CA20109 for ; Wed, 28 Oct 2015 21:12:42 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AE42A1AFF for ; Wed, 28 Oct 2015 21:12:42 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id t9SLCXeQ021960; Wed, 28 Oct 2015 14:12:37 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201510282112.t9SLCXeQ021960@gw.catspoiler.org> Date: Wed, 28 Oct 2015 14:12:33 -0700 (PDT) From: Don Lewis Subject: Re: 11.0-CURRENT r290039 privileged instruction fault while in kernel mode To: kostikbel@gmail.com cc: freebsd-current@FreeBSD.org In-Reply-To: <20151028173218.GN2257@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 28 Oct 2015 21:12:43 -0000 On 28 Oct, Konstantin Belousov wrote: > On Wed, Oct 28, 2015 at 10:16:12AM -0700, Don Lewis wrote: >> On 28 Oct, Konstantin Belousov wrote: >> > On Tue, Oct 27, 2015 at 04:09:28PM -0700, Don Lewis wrote: >> >> I just got this crash while running poudriere on a freshly upgraded >> >> 11.0-CURRENT machine. The instruction pointer value looks pretty >> >> strange. >> >> >> >> >> >> FreeBSD zipper.catspoiler.org 11.0-CURRENT FreeBSD 11.0-CURRENT #30 r290039: Tue Oct 27 00:08:00 PDT 2015 dl@zipper.catspoiler.org:/usr/obj/usr/src/sys/GENERIC amd64 >> >> >> >> panic: >> >> >> >> GNU gdb 6.1.1 [FreeBSD] >> >> Copyright 2004 Free Software Foundation, Inc. >> >> GDB is free software, covered by the GNU General Public License, and you are >> >> welcome to change it and/or distribute copies of it under certain conditions. >> >> Type "show copying" to see the conditions. >> >> There is absolutely no warranty for GDB. Type "show warranty" for details. >> >> This GDB was configured as "amd64-marcel-freebsd"... >> >> >> >> Unread portion of the kernel message buffer: >> >> >> >> >> >> Fatal trap 1: privileged instruction fault while in kernel mode >> >> cpuid = 4; apic id = 14 >> >> instruction pointer = 0x20:0xffffffff8240fef5 >> > What is the instruction at the reported address ? >> >> (kgdb) disassemble/r >> Dump of assembler code for function cpu_lock: >> 0xffffffff8240fef0 <+0>: 25 bb 40 82 ff and $0xff8240bb,%eax >> => 0xffffffff8240fef5 <+5>: ff (bad) >> 0xffffffff8240fef6 <+6>: ff (bad) >> 0xffffffff8240fef7 <+7>: ff 00 incl (%rax) >> 0xffffffff8240fef9 <+9>: 00 71 02 add %dh,0x2(%rcx) >> 0xffffffff8240fefc <+12>: 00 00 add %al,(%rax) >> 0xffffffff8240fefe <+14>: 00 00 add %al,(%rax) >> 0xffffffff8240ff00 <+16>: 00 00 add %al,(%rax) >> 0xffffffff8240ff02 <+18>: 00 00 add %al,(%rax) >> 0xffffffff8240ff04 <+20>: 00 00 add %al,(%rax) >> 0xffffffff8240ff06 <+22>: 00 00 add %al,(%rax) >> 0xffffffff8240ff08 <+24>: 01 00 add %eax,(%rax) >> 0xffffffff8240ff0a <+26>: 00 00 add %al,(%rax) >> 0xffffffff8240ff0c <+28>: 00 00 add %al,(%rax) >> 0xffffffff8240ff0e <+30>: 00 00 add %al,(%rax) >> End of assembler dump. > > Oh, I see. cpu_lock is mutex, dump above demonstrates is cleanly. > Most likely, something overwrote some pointer to a function with > the address. > > You probably have to bisect. The could be difficult. Whatever this is, it seems to be very hard to trigger. The machine was up and doing a lot of poudriere package building for about a day before it crashed. It's now got close to a day of uptime again, mostly building packages, without another crash. The previous kernel was r289123. From owner-freebsd-current@freebsd.org Thu Oct 29 12:38:39 2015 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 D4230A124EF for ; Thu, 29 Oct 2015 12:38:39 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.24]) (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 6A1351E57 for ; Thu, 29 Oct 2015 12:38:38 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from [78.35.160.31] (helo=fabiankeil.de) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1ZrmRw-0003W8-LL; Thu, 29 Oct 2015 13:37:00 +0100 Date: Thu, 29 Oct 2015 13:35:41 +0100 From: Fabian Keil To: freebsd-current@freebsd.org Cc: "Steven Hartland" , Xin Li , "Alexander Motin" Subject: Re: ZFS-related panic: "possible" spa->spa_errlog_lock deadlock Message-ID: <20151029133541.2bb55af9@fabiankeil.de> In-Reply-To: <20151028135821.0d375ec5@fabiankeil.de> References: <492dbacb.5942cc9b@fabiankeil.de> <540C66AC.8070809@delphij.net> <4fa875ba.3cc970d7@fabiankeil.de> <540C8039.7010309@delphij.net> <20151028135821.0d375ec5@fabiankeil.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/4TEXJLc2m1/KqUySJtNSQbe"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 29 Oct 2015 12:38:40 -0000 --Sig_/4TEXJLc2m1/KqUySJtNSQbe Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Fabian Keil wrote: > Xin Li wrote: >=20 > > On 9/7/14 11:23 PM, Fabian Keil wrote: =20 > > > Xin Li wrote: > > > =20 > > >> On 9/7/14 9:02 PM, Fabian Keil wrote: =20 > > >>> Using a kernel built from FreeBSD 11.0-CURRENT r271182 I got > > >>> the following panic yesterday: > > >>>=20 > > >>> [...] Unread portion of the kernel message buffer: [6880] > > >>> panic: deadlkres: possible deadlock detected for > > >>> 0xfffff80015289490, blocked for 1800503 ticks =20 > > >>=20 > > >> Any chance to get all backtraces (e.g. thread apply all bt full > > >> 16)? I think a different thread that held the lock have been > > >> blocked, probably related to your disconnected vdev. =20 > > >=20 > > > Output of "thread apply all bt full 16" is available at:=20 > > > http://www.fabiankeil.de/tmp/freebsd/kgdb-output-spa_errlog_lock-dead= lock.txt > > > > > > A lot of the backtraces prematurely end with "Cannot access memory > > > at address", therefore I also added "thread apply all bt" output. > > >=20 > > > Apparently there are at least two additional threads blocking below > > > spa_get_stats(): =20 > [...] > > Yes, thread 1182 owned the lock and is waiting for the zio be done. > > Other threads that wanted the lock would have to wait. > >=20 > > I don't have much clue why the system entered this state, however, as > > the operations should have errored out (the GELI device is gone on > > 21:44:56 based on your log, which suggests all references were closed) > > instead of waiting. =20 > I finally found the time to analyse the problem which seems > to be that spa_sync() requires at least one writeable vdev to > complete, but holds the lock(s) required to remove or bring back > vdevs. >=20 > Letting spa_sync() drop the lock and wait for at least one vdev > to become writeable again seems to make the problem unreproducible > for me, but probably merely shrinks the race window and thus is not > a complete solution. >=20 > For details see: > https://www.fabiankeil.de/sourcecode/electrobsd/ZFS-Optionally-let-spa_sy= nc-wait-for-writable-vdev.diff Patch updated to unbreak the userspace build and to note that the deadlock can still be reproduced with an artifical test case like: Shell 1: mdconfig -u 0 -f /dpool/scratch/test-vdev.img zpool create test /dev/md0 while sleep 1; do mdconfig -d -u 0 -o force && mdconfig -f /dpool/scratch/test-vdev.img && zpool clear test; done Shell 2: # Cause writes to the pool from another shell, for example # by creating datasets. Log excerpt (from test begin to deadlock): Oct 29 12:34:28 kendra ZFS: vdev state changed, pool_guid=3D160393537382368= 08887 vdev_guid=3D3080051161477470469 [...] Oct 29 12:46:57 kendra ZFS: vdev state changed, pool_guid=3D160393537382368= 08887 vdev_guid=3D3080051161477470469 Oct 29 12:46:59 kendra ZFS: vdev is removed, pool_guid=3D160393537382368088= 87 vdev_guid=3D3080051161477470469 Oct 29 12:46:59 kendra ZFS: vdev state changed, pool_guid=3D160393537382368= 08887 vdev_guid=3D3080051161477470469 Oct 29 12:47:00 kendra kernel: g_dev_taste: make_dev_p() failed (gp->name= =3Dmd0, error=3D17) With the deadman enabled, this will also cause: panic: I/O to pool 'test' appears to be hung on vdev guid 3080051161477470= 469 at '/dev/md0'. cpuid =3D 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe01136a= f870 vpanic() at vpanic+0x182/frame 0xfffffe01136af8f0 panic() at panic+0x43/frame 0xfffffe01136af950 vdev_deadman() at vdev_deadman+0x127/frame 0xfffffe01136af9a0 vdev_deadman() at vdev_deadman+0x40/frame 0xfffffe01136af9f0 spa_deadman() at spa_deadman+0x86/frame 0xfffffe01136afa20 softclock_call_cc() at softclock_call_cc+0x1a3/frame 0xfffffe01136afaf0 softclock() at softclock+0x94/frame 0xfffffe01136afb20 intr_event_execute_handlers() at intr_event_execute_handlers+0x1b6/frame 0= xfffffe01136afb60 ithread_loop() at ithread_loop+0xa6/frame 0xfffffe01136afbb0 fork_exit() at fork_exit+0x9c/frame 0xfffffe01136afbf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe01136afbf0 With test's txg_sync_thread being the offender: (kgdb) tid 101874 [Switching to thread 819 (Thread 101874)]#0 sched_switch (td=3D0xfffff800= 513649a0, newtd=3D, flags=3D) at = /usr/src/sys/kern/sched_ule.c:1969 1969 cpuid =3D PCPU_GET(cpuid); (kgdb) where #0 sched_switch (td=3D0xfffff800513649a0, newtd=3D, = flags=3D) at /usr/src/sys/kern/sched_ule.c:1969 #1 0xffffffff805a3a18 in mi_switch (flags=3D260, newtd=3D0x0) at /usr/src= /sys/kern/kern_synch.c:470 #2 0xffffffff805ea15a in sleepq_wait (wchan=3D0x0, pri=3D0) at /usr/src/s= ys/kern/subr_sleepqueue.c:631 #3 0xffffffff80530509 in _cv_wait (cvp=3D0xfffff8002678ea98, lock=3D0xfff= ff8002678ea78) at /usr/src/sys/kern/kern_condvar.c:139 #4 0xffffffff81930bbb in zio_wait (zio=3D) at /usr/s= rc/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1535 #5 0xffffffff818e4871 in dsl_pool_sync (dp=3D0xfffff80047dfd000, txg=3D76= ) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_pool.c:540 #6 0xffffffff81903653 in spa_sync (spa=3D0xfffff8009dfe2000, txg=3D76) at= /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:6734 #7 0xffffffff8190ccfa in txg_sync_thread (arg=3D0xfffff80047dfd000) at /u= sr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c:517 #8 0xffffffff80556edc in fork_exit (callout=3D0xffffffff8190c970 , arg=3D0xfffff80047dfd000, frame=3D0xfffffe011c27bc00) at /usr/sr= c/sys/kern/kern_fork.c:1011 #9 0xffffffff8085b91e in fork_trampoline () at /usr/src/sys/amd64/amd64/e= xception.S:609 #10 0x0000000000000000 in ?? () (kgdb) f 6 #6 0xffffffff81903653 in spa_sync (spa=3D0xfffff8009dfe2000, txg=3D76) at= /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:6734 (kgdb) p spa->spa_name $3 =3D 0xfffff8009dfe2000 "test" Fabian --Sig_/4TEXJLc2m1/KqUySJtNSQbe Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlYyEp4ACgkQBYqIVf93VJ0sxgCfYP3pBHRJnWy1IZIxJiNERYDN NoAAn2SGahuiiTpA4II8Q3kF+1815Pvc =83oi -----END PGP SIGNATURE----- --Sig_/4TEXJLc2m1/KqUySJtNSQbe-- From owner-freebsd-current@freebsd.org Thu Oct 29 16:25:05 2015 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 950C0A21A79 for ; Thu, 29 Oct 2015 16:25:05 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 7BB7F1BBF for ; Thu, 29 Oct 2015 16:25:05 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 78C77A21A78; Thu, 29 Oct 2015 16:25:05 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 785B2A21A77 for ; Thu, 29 Oct 2015 16:25:05 +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 6674E1BBE for ; Thu, 29 Oct 2015 16:25:05 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 6033D1703 for ; Thu, 29 Oct 2015 16:25:05 +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 2192E17411 for ; Thu, 29 Oct 2015 16:25:05 +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 742iPVcG9Yt4 for ; Thu, 29 Oct 2015 16:25:03 +0000 (UTC) To: current@FreeBSD.org DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com D613B1740B From: Bryan Drewery Subject: r288951: ifconfig -alias, arp not removed Organization: FreeBSD Message-ID: <5632485F.5080203@FreeBSD.org> Date: Thu, 29 Oct 2015 09:25:03 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 29 Oct 2015 16:25:05 -0000 # ifconfig igb0: flags=8843 metric 0 mtu 1500 options=403bb ether c8:0a:a9:04:39:78 inet 10.10.0.7 netmask 0xffff0000 broadcast 10.10.255.255 inet 10.10.7.2 netmask 0xffff0000 broadcast 10.10.255.255 inet 10.10.0.9 netmask 0xffff0000 broadcast 10.10.255.255 nd6 options=23 media: Ethernet autoselect (1000baseT ) status: active # ifconfig igb0 inet 10.10.0.9 -alias # arp -an|grep 10.10.0.9 ? (10.10.0.9) at c8:0a:a9:04:39:78 on igb0 permanent [ethernet] # arp -d 10.10.0.9 arp: writing to routing socket: Operation not permitted I swear this is not normal. I'm on an older build as well, r288951. -- Regards, Bryan Drewery From owner-freebsd-current@freebsd.org Thu Oct 29 16:42:50 2015 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 85D68A21ECD for ; Thu, 29 Oct 2015 16:42:50 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 635DD1B14 for ; Thu, 29 Oct 2015 16:42:50 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: by mailman.ysv.freebsd.org (Postfix) id 59734A21ECC; Thu, 29 Oct 2015 16:42:50 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5910FA21ECB for ; Thu, 29 Oct 2015 16:42:50 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) by mx1.freebsd.org (Postfix) with ESMTP id 391431B0F; Thu, 29 Oct 2015 16:42:49 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from marvin.beer.town (unknown [76.164.8.130]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 7723456486; Thu, 29 Oct 2015 11:42:43 -0500 (CDT) Subject: Re: r288951: ifconfig -alias, arp not removed To: Bryan Drewery , current@FreeBSD.org References: <5632485F.5080203@FreeBSD.org> From: Eric van Gyzen Message-ID: <56324C80.8000408@vangyzen.net> Date: Thu, 29 Oct 2015 11:42:40 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <5632485F.5080203@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 29 Oct 2015 16:42:50 -0000 On 10/29/2015 11:25, Bryan Drewery wrote: > # ifconfig > igb0: flags=8843 metric 0 mtu 1500 > > options=403bb > ether c8:0a:a9:04:39:78 > inet 10.10.0.7 netmask 0xffff0000 broadcast 10.10.255.255 > inet 10.10.7.2 netmask 0xffff0000 broadcast 10.10.255.255 > inet 10.10.0.9 netmask 0xffff0000 broadcast 10.10.255.255 > nd6 options=23 > media: Ethernet autoselect (1000baseT ) > status: active > > # ifconfig igb0 inet 10.10.0.9 -alias > # arp -an|grep 10.10.0.9 > ? (10.10.0.9) at c8:0a:a9:04:39:78 on igb0 permanent [ethernet] > # arp -d 10.10.0.9 > arp: writing to routing socket: Operation not permitted > > I swear this is not normal. I'm on an older build as well, r288951. That definitely looks abnormal. See what "route get" says. I think that's the error you get when there is a route for that address. Eric From owner-freebsd-current@freebsd.org Thu Oct 29 16:46:38 2015 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 66325A21FC2 for ; Thu, 29 Oct 2015 16:46:38 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 4AE181ED6 for ; Thu, 29 Oct 2015 16:46:38 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 47F69A21FC1; Thu, 29 Oct 2015 16:46:38 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4790DA21FC0 for ; Thu, 29 Oct 2015 16:46:38 +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 34DEB1ED5; Thu, 29 Oct 2015 16:46:38 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 2EE7A133E; Thu, 29 Oct 2015 16:46:38 +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 D5CC4174AF; Thu, 29 Oct 2015 16:46:37 +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 2Y8FZ66QnCNb; Thu, 29 Oct 2015 16:46:34 +0000 (UTC) Subject: Re: r288951: ifconfig -alias, arp not removed DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com B1A7D174A5 To: Eric van Gyzen , current@FreeBSD.org References: <5632485F.5080203@FreeBSD.org> <56324C80.8000408@vangyzen.net> From: Bryan Drewery Organization: FreeBSD Message-ID: <56324D69.4080507@FreeBSD.org> Date: Thu, 29 Oct 2015 09:46:33 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56324C80.8000408@vangyzen.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 29 Oct 2015 16:46:38 -0000 On 10/29/15 9:42 AM, Eric van Gyzen wrote: > On 10/29/2015 11:25, Bryan Drewery wrote: >> # ifconfig >> igb0: flags=8843 metric 0 mtu 1500 >> >> options=403bb >> ether c8:0a:a9:04:39:78 >> inet 10.10.0.7 netmask 0xffff0000 broadcast 10.10.255.255 >> inet 10.10.7.2 netmask 0xffff0000 broadcast 10.10.255.255 >> inet 10.10.0.9 netmask 0xffff0000 broadcast 10.10.255.255 >> nd6 options=23 >> media: Ethernet autoselect (1000baseT ) >> status: active >> >> # ifconfig igb0 inet 10.10.0.9 -alias >> # arp -an|grep 10.10.0.9 >> ? (10.10.0.9) at c8:0a:a9:04:39:78 on igb0 permanent [ethernet] >> # arp -d 10.10.0.9 >> arp: writing to routing socket: Operation not permitted >> >> I swear this is not normal. I'm on an older build as well, r288951. > > That definitely looks abnormal. See what "route get" says. I think > that's the error you get when there is a route for that address. > # netstat -rn|grep 10.10.0.9 # route get 10.10.0.9 route to: lapbox destination: 10.10.0.0 mask: 255.255.0.0 fib: 0 interface: igb0 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1500 1 0 # route get 5.5.5.5 route to: 5.5.5.5 destination: default mask: default gateway: router.asus.com fib: 0 interface: igb0 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1500 1 0 For more context, this current system had 10.10.0.9 added to it. I started up a VM which also started using 10.10.0.9 and managed to "win" on the local network for owning it. (I don't know arp and this stuff well). I then came to this system to remove the alias and the arp entry to allow me to connect from it and have gotten into this situation. -- Regards, Bryan Drewery From owner-freebsd-current@freebsd.org Thu Oct 29 21:56:44 2015 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 7ED55A2100E for ; Thu, 29 Oct 2015 21:56:44 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 5FD971FC8 for ; Thu, 29 Oct 2015 21:56:44 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 5D2DEA2100D; Thu, 29 Oct 2015 21:56:44 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5BCEDA2100C for ; Thu, 29 Oct 2015 21:56:44 +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 39BBC1FC6 for ; Thu, 29 Oct 2015 21:56:44 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 337AC1F01 for ; Thu, 29 Oct 2015 21:56:44 +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 D004D17893 for ; Thu, 29 Oct 2015 21:56:43 +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 nmhsIodkznUb for ; Thu, 29 Oct 2015 21:56:41 +0000 (UTC) Subject: Re: r288951: ifconfig -alias, arp not removed DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 930D41788E To: current@FreeBSD.org References: <5632485F.5080203@FreeBSD.org> <56324C80.8000408@vangyzen.net> <56324D69.4080507@FreeBSD.org> From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <5632961B.2040604@FreeBSD.org> Date: Thu, 29 Oct 2015 14:56:43 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56324D69.4080507@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="idTac2hu78KME0irTXCJbIcMF2QbvRb6S" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 29 Oct 2015 21:56:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --idTac2hu78KME0irTXCJbIcMF2QbvRb6S Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 10/29/2015 9:46 AM, Bryan Drewery wrote: > On 10/29/15 9:42 AM, Eric van Gyzen wrote: >> On 10/29/2015 11:25, Bryan Drewery wrote: >>> # ifconfig >>> igb0: flags=3D8843 metric 0 m= tu 1500 >>> >>> options=3D403bb >>> ether c8:0a:a9:04:39:78 >>> inet 10.10.0.7 netmask 0xffff0000 broadcast 10.10.255.255 >>> inet 10.10.7.2 netmask 0xffff0000 broadcast 10.10.255.255 >>> inet 10.10.0.9 netmask 0xffff0000 broadcast 10.10.255.255 >>> nd6 options=3D23 >>> media: Ethernet autoselect (1000baseT ) >>> status: active >>> >>> # ifconfig igb0 inet 10.10.0.9 -alias >>> # arp -an|grep 10.10.0.9 >>> ? (10.10.0.9) at c8:0a:a9:04:39:78 on igb0 permanent [ethernet] >>> # arp -d 10.10.0.9 >>> arp: writing to routing socket: Operation not permitted >>> >>> I swear this is not normal. I'm on an older build as well, r288951. >> >> That definitely looks abnormal. See what "route get" says. I think >> that's the error you get when there is a route for that address. >> >=20 > # netstat -rn|grep 10.10.0.9 > # route get 10.10.0.9 > route to: lapbox > destination: 10.10.0.0 > mask: 255.255.0.0 > fib: 0 > interface: igb0 > flags: > recvpipe sendpipe ssthresh rtt,msec mtu weight expire > 0 0 0 0 1500 1 0 > # route get 5.5.5.5 > route to: 5.5.5.5 > destination: default > mask: default > gateway: router.asus.com > fib: 0 > interface: igb0 > flags: > recvpipe sendpipe ssthresh rtt,msec mtu weight expire > 0 0 0 0 1500 1 0 >=20 > For more context, this current system had 10.10.0.9 added to it. I > started up a VM which also started using 10.10.0.9 and managed to "win"= > on the local network for owning it. (I don't know arp and this stuff > well). I then came to this system to remove the alias and the arp entry= > to allow me to connect from it and have gotten into this situation. >=20 Just saw this in dmesg, which is what I described: arp: 08:00:27:12:c1:a5 is using my IP address 10.10.0.9 on igb0! arp: 08:00:27:12:c1:a5 is using my IP address 10.10.0.9 on igb0! arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9 on igb0 arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9 on igb0 arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9 on igb0 arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9 on igb0 --=20 Regards, Bryan Drewery --idTac2hu78KME0irTXCJbIcMF2QbvRb6S Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJWMpYbAAoJEDXXcbtuRpfPlqYH/0t/FtB7pORqqdX7Zpc5YTjl fSk7bLOPUBxNFnLwXJmoPQ0VvOSM2GEcsYzQPHAIAozFv6093FjQXqWX1j60d0yg YMaM0Uh0cQMZx2MBXIscoZ7Zg8FLbj7X4Btc6y0wYMdlTuAR1M7GNscIDZver6aG LxiZSBRDYmnvQQLYESerMGaAJVV6dCx5yTuzgcCYeKvtObCZgPrXDo0+rscuIVL4 NVtg9lCU3n0jZASNs5G3WcFCqAWmlCQp6BQMn9NQ2bdlYuseZEDRUlRSxgA4sHDm Fox5z0hxkHcGtk11FqayV1fuKWuv9p/TwB8AeTpfC9A5iJgA8Ovd+98aH/myfNk= =SDaL -----END PGP SIGNATURE----- --idTac2hu78KME0irTXCJbIcMF2QbvRb6S-- From owner-freebsd-current@freebsd.org Thu Oct 29 23:24:01 2015 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 314F0A1F021 for ; Thu, 29 Oct 2015 23:24:01 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EEAE81A89 for ; Thu, 29 Oct 2015 23:24:00 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t9TNO07L083118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Oct 2015 16:24:00 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t9TNO07n083117; Thu, 29 Oct 2015 16:24:00 -0700 (PDT) (envelope-from jmg) Date: Thu, 29 Oct 2015 16:24:00 -0700 From: John-Mark Gurney To: Lyndon Nerenberg Cc: freebsd-current Current Subject: Re: Depreciate and remove gbde Message-ID: <20151029232359.GQ65715@funkthat.com> References: <6216.1445631619@critter.freebsd.dk> <201510241559.t9OFwsiF078038@fire.js.berklix.net> <20151024190611.GE65715@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Thu, 29 Oct 2015 16:24:00 -0700 (PDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 29 Oct 2015 23:24:01 -0000 Lyndon Nerenberg wrote this message on Mon, Oct 26, 2015 at 19:06 -0700: > On Oct 24, 2015, at 12:06 PM, John-Mark Gurney wrote: > > > The thing I like most about encryption is that when I RMA a bad > > drive, I don't have to worry about my data leaking if I am unable > > to overwrite all the data... > > You are optimistic if you believe that. We ($WORK) factor the cost of DOA/warranty drives into our operational budget. They never get RMAed. We drill them when they die. Being a personal user, and having close to a 10% RMA rate on recent hard drives, that would be a bit costly... I consider a HD defective if it's under waranty and it's performance drops below 80% of new, i.e. 130MB/sec normal sequential write drops below 100MB/sec.. The weekest point is the passphrase/passfile protecting the master key... In my case, I use a random passfile for these drives... If someone is able to break the passfile, or the AES-256 encryption, then they must really want my data... It'd be easier, even for governments, to do a black bag job than recover partial data (it's one drive of a RAIDZ array)... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@freebsd.org Fri Oct 30 01:13:11 2015 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 CB687A208D2 for ; Fri, 30 Oct 2015 01:13:11 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8D63A1966 for ; Fri, 30 Oct 2015 01:13:10 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from [10.9.9.241] (helo=rmm6prod02.runbox.com) by bars.runbox.com with esmtp (Exim 4.71) (envelope-from ) id 1ZryFV-0003Cg-MC; Fri, 30 Oct 2015 02:12:57 +0100 Received: from mail by rmm6prod02.runbox.com with local (Exim 4.76) (envelope-from ) id 1ZryFV-0003N7-Lb; Fri, 30 Oct 2015 02:12:57 +0100 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [Authenticated user (846156)] by runbox.com with http (RMM6); Fri, 30 Oct 2015 01:12:57 GMT From: "Jeffrey Bouquet" Reply-To: jbtakk@iherebuywisely.com To: "John-Mark Gurney" CC: "Lyndon Nerenberg" , "freebsd-current Current" Subject: Re: Depreciate and remove gbde Date: Thu, 29 Oct 2015 18:12:57 -0700 (PDT) X-Mailer: RMM6 In-Reply-To: <20151029232359.GQ65715@funkthat.com> Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 30 Oct 2015 01:13:11 -0000 On Thu, 29 Oct 2015 16:24:00 -0700, John-Mark Gurney wro= te: > Lyndon Nerenberg wrote this message on Mon, Oct 26, 2015 at 19:06 -0700: > > On Oct 24, 2015, at 12:06 PM, John-Mark Gurney wrote: > >=20 > > > The thing I like most about encryption is that when I RMA a bad > > > drive, I don't have to worry about my data leaking if I am unable > > > to overwrite all the data... > >=20 > > You are optimistic if you believe that. We ($WORK) factor the cost of = DOA/warranty drives into our operational budget. They never get RMAed. We= drill them when they die. >=20 > Being a personal user, and having close to a 10% RMA rate on recent > hard drives, that would be a bit costly... >=20 > I consider a HD defective if it's under waranty and it's performance > drops below 80% of new, i.e. 130MB/sec normal sequential write drops > below 100MB/sec.. >=20 > The weekest point is the passphrase/passfile protecting the master > key... In my case, I use a random passfile for these drives... If > someone is able to break the passfile, or the AES-256 encryption, then > they must really want my data... It'd be easier, even for governments, > to do a black bag job than recover partial data (it's one drive of a > RAIDZ array)... >=20 > --=20 > John-Mark Gurney Voice: +1 415 225 5579 >=20 > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > 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" FWIW I've several WD eide that corrupt with twed0... fix them with dosdlg.exe on floppy (long test, an hour...) and they work fine as primary eide drives a long while thereafter (not secondary on twed0...)=20=20=20 in case that saves anyone some time/money...= From owner-freebsd-current@freebsd.org Fri Oct 30 08:42:12 2015 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 DADC2A20C6E for ; Fri, 30 Oct 2015 08:42:12 +0000 (UTC) (envelope-from des@des.no) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C5CC91DF7 for ; Fri, 30 Oct 2015 08:42:12 +0000 (UTC) (envelope-from des@des.no) Received: by mailman.ysv.freebsd.org (Postfix) id C5723A20C6D; Fri, 30 Oct 2015 08:42:12 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C50B4A20C6B for ; Fri, 30 Oct 2015 08:42:12 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 8D3781DF6 for ; Fri, 30 Oct 2015 08:42:12 +0000 (UTC) (envelope-from des@des.no) Received: from desk.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 170422A87; Fri, 30 Oct 2015 08:42:08 +0000 (UTC) Received: by desk.des.no (Postfix, from userid 1001) id 66B0FA663; Fri, 30 Oct 2015 09:42:07 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: David Wolfskill Cc: current@freebsd.org Subject: Re: Segmentation fault running ntpd References: <20150718120956.GC1155@albert.catwhisker.org> Date: Fri, 30 Oct 2015 09:42:07 +0100 In-Reply-To: <20150718120956.GC1155@albert.catwhisker.org> (David Wolfskill's message of "Sat, 18 Jul 2015 05:09:56 -0700") Message-ID: <86pozwbvds.fsf@desk.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 30 Oct 2015 08:42:12 -0000 David Wolfskill writes: > ... > bound to 172.17.1.245 -- renewal in 43200 seconds. > pid 544 (ntpd), uid 0: exited on signal 11 (core dumped) > Starting Network: lo0 em0 iwn0 lagg0. > ... Did you find a solution? I'm wondering if the ntpd problems people are reporting on freebsd-security@ are related. I vaguely recall hearing that this had been traced to a pthread bug, but can't find anything about it in commit logs or mailing list archives. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@freebsd.org Fri Oct 30 08:52:51 2015 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 E3D28A20F4C for ; Fri, 30 Oct 2015 08:52:51 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C200D122F for ; Fri, 30 Oct 2015 08:52:51 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id BF96EA20F4B; Fri, 30 Oct 2015 08:52:51 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BE3A4A20F4A for ; Fri, 30 Oct 2015 08:52:51 +0000 (UTC) (envelope-from yaneurabeya@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 8A58D122E for ; Fri, 30 Oct 2015 08:52:51 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by padhy1 with SMTP id hy1so62492583pad.0 for ; Fri, 30 Oct 2015 01:52:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9vUAN+TxzZ6uFzTPjJJgNCrUpfw2nRgG7U0rtUfzK8o=; b=mLC9YM2Sv9N/XBAY5Bo2G10lj5SGJNtgQYVTxpJgAiylGPPX7RvhxQtv9dEvxf4soA m6E54zrbyKbpMkwyFZZpbPP/2hJw0xdH2qWWo4Qc+yQaw+r6VotGsUlo3FvB098jmUHB XAp/qmcZXwbdSl5ItTU9RMtSy34BVu3Hoxp36bY5O+Jy5Cg52j6w+a1jw7AGrvw1nvJ8 VI6qfGFxkV4Na5CggVFEnzqoGh/hheQXXb9m0ugy1USqM1TcxxkiFJXZRNvPT4OnHMEb rfl4lefna8uXIWB6Xtz+Jei5IDtFejJPNCLmNioDt0Jhi70YxhzpZj+Z/eWiNGlW4oNp ZcTw== X-Received: by 10.68.134.3 with SMTP id pg3mr7336650pbb.41.1446195171172; Fri, 30 Oct 2015 01:52:51 -0700 (PDT) Received: from ?IPv6:2601:601:800:126d:b09f:a62d:eef9:d2bc? ([2601:601:800:126d:b09f:a62d:eef9:d2bc]) by smtp.gmail.com with ESMTPSA id h10sm6781118pat.34.2015.10.30.01.52.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 Oct 2015 01:52:50 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Segmentation fault running ntpd From: NGie Cooper In-Reply-To: <86pozwbvds.fsf@desk.des.no> Date: Fri, 30 Oct 2015 01:52:49 -0700 Cc: David Wolfskill , current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150718120956.GC1155@albert.catwhisker.org> <86pozwbvds.fsf@desk.des.no> To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 30 Oct 2015 08:52:52 -0000 > On Oct 30, 2015, at 01:42, Dag-Erling Sm=C3=B8rgrav = wrote: >=20 > David Wolfskill writes: >> ... >> bound to 172.17.1.245 -- renewal in 43200 seconds. >> pid 544 (ntpd), uid 0: exited on signal 11 (core dumped) >> Starting Network: lo0 em0 iwn0 lagg0. >> ... >=20 > Did you find a solution? I'm wondering if the ntpd problems people = are > reporting on freebsd-security@ are related. I vaguely recall hearing > that this had been traced to a pthread bug, but can't find anything > about it in commit logs or mailing list archives. https://svnweb.freebsd.org/changeset/base/287591 ?= From owner-freebsd-current@freebsd.org Fri Oct 30 09:05:59 2015 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 77E31A21296 for ; Fri, 30 Oct 2015 09:05:59 +0000 (UTC) (envelope-from des@des.no) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 60BB117C1 for ; Fri, 30 Oct 2015 09:05:59 +0000 (UTC) (envelope-from des@des.no) Received: by mailman.ysv.freebsd.org (Postfix) id 5E1BFA21295; Fri, 30 Oct 2015 09:05:59 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5CBCFA21293 for ; Fri, 30 Oct 2015 09:05:59 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 191B217C0 for ; Fri, 30 Oct 2015 09:05:58 +0000 (UTC) (envelope-from des@des.no) Received: from desk.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 3283E2AB1; Fri, 30 Oct 2015 09:05:56 +0000 (UTC) Received: by desk.des.no (Postfix, from userid 1001) id 82BA9A668; Fri, 30 Oct 2015 10:05:52 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: NGie Cooper Cc: David Wolfskill , current@freebsd.org Subject: Re: Segmentation fault running ntpd References: <20150718120956.GC1155@albert.catwhisker.org> <86pozwbvds.fsf@desk.des.no> Date: Fri, 30 Oct 2015 10:05:52 +0100 In-Reply-To: (NGie Cooper's message of "Fri, 30 Oct 2015 01:52:49 -0700") Message-ID: <86lhakbua7.fsf@desk.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 30 Oct 2015 09:05:59 -0000 NGie Cooper writes: > Dag-Erling Sm=C3=B8rgrav writes: > > David Wolfskill writes: > > > pid 544 (ntpd), uid 0: exited on signal 11 (core dumped) > > Did you find a solution? [...] > https://svnweb.freebsd.org/changeset/base/287591 ? Are you certain? The commit message does not mention David or ntpd. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@freebsd.org Fri Oct 30 09:09:41 2015 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 995CFA2130A for ; Fri, 30 Oct 2015 09:09:41 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 76D8A1909 for ; Fri, 30 Oct 2015 09:09:41 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 748FAA21309; Fri, 30 Oct 2015 09:09:41 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 73337A21307 for ; Fri, 30 Oct 2015 09:09:41 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3E7001908 for ; Fri, 30 Oct 2015 09:09:41 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by pasz6 with SMTP id z6so68926053pas.2 for ; Fri, 30 Oct 2015 02:09:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jn9bVtuQUgF5DgELD+tuCfFh6/enrYbm2LVagqKTgeE=; b=b4NY6RwQiwGUihiP4+Bg4Zk/ybWxE+aCHHHIqr6qFmBIopIXfuBtSaXW47j57JvJbd aWeE80QgpKv0FT7y+LPvpq8vZsXXCER0I+gMqA0d08YwoQ4Oqn86T2bCRA31nIk57VQU ogFlbIWKZMPD1B2CdVJbDqoc5S3M61ubwTFN2R5ntmJpZMOmQRRpbXK0JD9Qc7B6Z52i kfv8ivyL3E4yaimpBBhLGEBu+o6HIv3IxbaArJAgHeNGyg+bBCMaRA+KNkVAuYoD8m2Q c+ht6I2008aMMTBresVr0q11fZC/ogcdPhO7qz4XtgMC5SyS4inY/gMX/nDkQMemGTAS SAUw== X-Received: by 10.68.105.34 with SMTP id gj2mr7423754pbb.136.1446196180756; Fri, 30 Oct 2015 02:09:40 -0700 (PDT) Received: from ?IPv6:2601:601:800:126d:b09f:a62d:eef9:d2bc? ([2601:601:800:126d:b09f:a62d:eef9:d2bc]) by smtp.gmail.com with ESMTPSA id iy1sm6844615pbb.85.2015.10.30.02.09.40 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Oct 2015 02:09:40 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Segmentation fault running ntpd From: NGie Cooper In-Reply-To: <86lhakbua7.fsf@desk.des.no> Date: Fri, 30 Oct 2015 02:09:39 -0700 Cc: David Wolfskill , FreeBSD CURRENT Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150718120956.GC1155@albert.catwhisker.org> <86pozwbvds.fsf@desk.des.no> <86lhakbua7.fsf@desk.des.no> To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 30 Oct 2015 09:09:41 -0000 > On Oct 30, 2015, at 02:05, Dag-Erling Sm=C3=B8rgrav = wrote: >=20 > NGie Cooper writes: >> Dag-Erling Sm=C3=B8rgrav writes: >>> David Wolfskill writes: >>>> pid 544 (ntpd), uid 0: exited on signal 11 (core dumped) >>> Did you find a solution? [...] >> https://svnweb.freebsd.org/changeset/base/287591 ? >=20 > Are you certain? The commit message does not mention David or ntpd. That commit was pretty involved. Peter documented the issue in the = thread titled "ABORT! ABORT! Re: HEADS UP: this month's cluster = refresh=E2=80=9D that was sent to the internal list.= From owner-freebsd-current@freebsd.org Fri Oct 30 09:24:13 2015 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 E6062A215E6 for ; Fri, 30 Oct 2015 09:24:13 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C09DF1F9F for ; Fri, 30 Oct 2015 09:24:13 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id BE176A215E5; Fri, 30 Oct 2015 09:24:13 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BCD88A215E4 for ; Fri, 30 Oct 2015 09:24:13 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8124A1F9E for ; Fri, 30 Oct 2015 09:24:13 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by padhy1 with SMTP id hy1so63335811pad.0 for ; Fri, 30 Oct 2015 02:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bi0zm6XuPs5KfM0Xt9Oat39j3PgoPLQpCgrVyDXcNJI=; b=ces5Dtry6K55cvyGSChQsw3+yhlyaUPttTElY+4xd0+L+RiybAaLaiuFOZlVm2UIJg /RVlVC184W15RBNrgDdOg8SjeRroLtCr41jRw24+Zr2L4zMe76gOcSx0XADY7gevpFKa 3awngA78TRhD9Lf2tpKn0a+qun1gcvyXM8a1OeE8NO2pvkZxOT0p8z8mxjEqqwpPiCIf DwnwF+Qj+n21RicLZtQdKIyGBlWgnHnu+02ua5Jbbf5Vw0/6FppWUj+hAU+5bWYxUKjA apPUr1DSIZm0AEnRvXM/aER/eH7CWVSuCsX/+QDeeh2l9YydSQTySvVWgt/I7EOn0Hif 4Xpw== X-Received: by 10.68.103.194 with SMTP id fy2mr7620734pbb.31.1446197053140; Fri, 30 Oct 2015 02:24:13 -0700 (PDT) Received: from [192.168.20.7] (c-24-16-212-205.hsd1.wa.comcast.net. [24.16.212.205]) by smtp.gmail.com with ESMTPSA id y16sm4361106pbt.88.2015.10.30.02.24.12 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Oct 2015 02:24:12 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Segmentation fault running ntpd From: NGie Cooper In-Reply-To: <9D306406-691B-491E-8933-D991A09620A3@lastsummer.de> Date: Fri, 30 Oct 2015 02:24:11 -0700 Cc: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= , David Wolfskill , FreeBSD CURRENT Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150718120956.GC1155@albert.catwhisker.org> <86pozwbvds.fsf@desk.des.no> <86lhakbua7.fsf@desk.des.no> <9D306406-691B-491E-8933-D991A09620A3@lastsummer.de> To: Franco Fichtner X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 30 Oct 2015 09:24:14 -0000 > On Oct 30, 2015, at 02:18, Franco Fichtner = wrote: >=20 > Hi all, >=20 > I did a quick test build and this seems to solve the ntpd crash issue > on top of releng/10.1. Makes sense =E2=80=A6 looking through my email r287591 was never MFCed = back to stable/9 or stable/10 :/ . HTH, -NGie= From owner-freebsd-current@freebsd.org Fri Oct 30 09:26:06 2015 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 6824FA216C3 for ; Fri, 30 Oct 2015 09:26:06 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 4A845128B for ; Fri, 30 Oct 2015 09:26:06 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: by mailman.ysv.freebsd.org (Postfix) id 4A29AA216C2; Fri, 30 Oct 2015 09:26:06 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 49CA1A216C1 for ; Fri, 30 Oct 2015 09:26:06 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from host64.kissl.de (host64.kissl.de [213.239.241.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "*.shmhost.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0AE34128A for ; Fri, 30 Oct 2015 09:26:05 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from localhost (localhost.localdomain [127.0.0.1]) by host64.kissl.de (Postfix) with ESMTP id 80EC8B07E36; Fri, 30 Oct 2015 10:18:52 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at host64.kissl.de Received: from host64.kissl.de ([127.0.0.1]) by localhost (host64.kissl.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKp_O-MUrh27; Fri, 30 Oct 2015 10:18:52 +0100 (CET) Received: from [10.0.100.2] (ip5f5ad30f.dynamic.kabel-deutschland.de [95.90.211.15]) (Authenticated sender: web104p1) by host64.kissl.de (Postfix) with ESMTPSA id 545C1B07E35; Fri, 30 Oct 2015 10:18:52 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Segmentation fault running ntpd From: Franco Fichtner In-Reply-To: Date: Fri, 30 Oct 2015 10:18:51 +0100 Cc: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= , David Wolfskill , FreeBSD CURRENT Content-Transfer-Encoding: quoted-printable Message-Id: <9D306406-691B-491E-8933-D991A09620A3@lastsummer.de> References: <20150718120956.GC1155@albert.catwhisker.org> <86pozwbvds.fsf@desk.des.no> <86lhakbua7.fsf@desk.des.no> To: NGie Cooper X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 30 Oct 2015 09:26:06 -0000 Hi all, I did a quick test build and this seems to solve the ntpd crash issue on top of releng/10.1. Cheers, Franco > On 30 Oct 2015, at 10:09 am, NGie Cooper = wrote: >=20 >=20 >> On Oct 30, 2015, at 02:05, Dag-Erling Sm=C3=B8rgrav = wrote: >>=20 >> NGie Cooper writes: >>> Dag-Erling Sm=C3=B8rgrav writes: >>>> David Wolfskill writes: >>>>> pid 544 (ntpd), uid 0: exited on signal 11 (core dumped) >>>> Did you find a solution? [...] >>> https://svnweb.freebsd.org/changeset/base/287591 ? >>=20 >> Are you certain? The commit message does not mention David or ntpd. >=20 > That commit was pretty involved. Peter documented the issue in the = thread titled "ABORT! ABORT! Re: HEADS UP: this month's cluster = refresh=E2=80=9D that was sent to the internal list. > _______________________________________________ > 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 Oct 30 09:32:09 2015 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 E25D6A21951 for ; Fri, 30 Oct 2015 09:32:09 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C2D1115F0 for ; Fri, 30 Oct 2015 09:32:09 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: by mailman.ysv.freebsd.org (Postfix) id C0456A21950; Fri, 30 Oct 2015 09:32:09 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BFD59A2194F for ; Fri, 30 Oct 2015 09:32:09 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from host64.kissl.de (host64.kissl.de [213.239.241.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "*.shmhost.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7F15C15EF for ; Fri, 30 Oct 2015 09:32:09 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from localhost (localhost.localdomain [127.0.0.1]) by host64.kissl.de (Postfix) with ESMTP id 2DFCAB07E4F; Fri, 30 Oct 2015 10:32:07 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at host64.kissl.de Received: from host64.kissl.de ([127.0.0.1]) by localhost (host64.kissl.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFNABBp7eN6e; Fri, 30 Oct 2015 10:32:07 +0100 (CET) Received: from [10.0.100.2] (ip5f5ad30f.dynamic.kabel-deutschland.de [95.90.211.15]) (Authenticated sender: web104p1) by host64.kissl.de (Postfix) with ESMTPSA id 018DAB07E4E; Fri, 30 Oct 2015 10:32:06 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Segmentation fault running ntpd From: Franco Fichtner In-Reply-To: Date: Fri, 30 Oct 2015 10:32:05 +0100 Cc: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= , David Wolfskill , FreeBSD CURRENT Content-Transfer-Encoding: quoted-printable Message-Id: <5C3532DB-CFD2-4C30-8854-9C9E883D5148@lastsummer.de> References: <20150718120956.GC1155@albert.catwhisker.org> <86pozwbvds.fsf@desk.des.no> <86lhakbua7.fsf@desk.des.no> <9D306406-691B-491E-8933-D991A09620A3@lastsummer.de> To: NGie Cooper X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 30 Oct 2015 09:32:10 -0000 Well, it=E2=80=99s on stable/10 since September 16 and somebody reported = that this particular branch would not trigger the crash along with HEAD, but any 10.x would. Can=E2=80=99t find the reference right now though. > On 30 Oct 2015, at 10:24 am, NGie Cooper = wrote: >=20 >=20 >> On Oct 30, 2015, at 02:18, Franco Fichtner = wrote: >>=20 >> Hi all, >>=20 >> I did a quick test build and this seems to solve the ntpd crash issue >> on top of releng/10.1. >=20 > Makes sense =E2=80=A6 looking through my email r287591 was never MFCed = back to stable/9 or stable/10 :/ . > HTH, > -NGie > _______________________________________________ > 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 Oct 30 09:38:29 2015 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 BB43BA21B13 for ; Fri, 30 Oct 2015 09:38:29 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 95D451BA2 for ; Fri, 30 Oct 2015 09:38:29 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 94C65A21B12; Fri, 30 Oct 2015 09:38:29 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 94623A21B11 for ; Fri, 30 Oct 2015 09:38:29 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (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 61BDF1BA1 for ; Fri, 30 Oct 2015 09:38:29 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by pasz6 with SMTP id z6so69698160pas.2 for ; Fri, 30 Oct 2015 02:38:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7uF/Eppy46/1AE8MTgydtJnnIG0w66X5Ruigic/mdzk=; b=JRB9xoyyCyowgsCJb30EnnkY2uPaHBvTpzmEjfH8U4MMw7bkFUCVUUtCe94aPWpXK5 3TWDc0EgqljuwD7dp8i1ExutFepVGASk44aXyYmTmnksDl3GgeHospwL1YOhOiZKfPSt FTWZJCITLei0cKY0v75qy3okq2rDkZtWX7J541hCulmXLnjFz5miMYJjjgcHfZ1L0h86 XsnRQOgu+yNIdH0rgyffj522C+8w2Id2ESHDjwjmBbT7IJk/2V2ah4GkPGUwBXdDnhLW bqSo21hCgWJJ5EAiz7IjlfidzB69cPiZb/Pq2gTVJX4QX7+PEDI/vQrp8oGYX1U1lmbj 6OwA== X-Received: by 10.66.184.42 with SMTP id er10mr7799420pac.117.1446197908993; Fri, 30 Oct 2015 02:38:28 -0700 (PDT) Received: from [192.168.20.7] (c-24-16-212-205.hsd1.wa.comcast.net. [24.16.212.205]) by smtp.gmail.com with ESMTPSA id pn8sm7104278pbb.16.2015.10.30.02.38.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 Oct 2015 02:38:28 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Segmentation fault running ntpd From: NGie Cooper In-Reply-To: <5C3532DB-CFD2-4C30-8854-9C9E883D5148@lastsummer.de> Date: Fri, 30 Oct 2015 02:38:27 -0700 Cc: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= , David Wolfskill , FreeBSD CURRENT Content-Transfer-Encoding: quoted-printable Message-Id: <08BE7960-C917-4E99-AC9A-6ADFA24FD10E@gmail.com> References: <20150718120956.GC1155@albert.catwhisker.org> <86pozwbvds.fsf@desk.des.no> <86lhakbua7.fsf@desk.des.no> <9D306406-691B-491E-8933-D991A09620A3@lastsummer.de> <5C3532DB-CFD2-4C30-8854-9C9E883D5148@lastsummer.de> To: Franco Fichtner X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 30 Oct 2015 09:38:29 -0000 > On Oct 30, 2015, at 02:32, Franco Fichtner = wrote: >=20 > Well, it=E2=80=99s on stable/10 since September 16 and somebody = reported that > this particular branch would not trigger the crash along with HEAD, > but any 10.x would. Can=E2=80=99t find the reference right now = though. You=E2=80=99re right. My Mail.app search fu was failing me for a = minute.. ------------------------------------------------------------------------ r287846 | kib | 2015-09-15 21:20:39 -0700 (Tue, 15 Sep 2015) | 4 lines MFC r287591: There is no reason in the current kernel to disallow write access to the COW wired entry if the entry permissions allow it. Remove the = check. From owner-freebsd-current@freebsd.org Fri Oct 30 09:47:57 2015 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 9F7B3A21D30 for ; Fri, 30 Oct 2015 09:47:57 +0000 (UTC) (envelope-from matthew@freebsd.org) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 30C6D1323 for ; Fri, 30 Oct 2015 09:47:57 +0000 (UTC) (envelope-from matthew@freebsd.org) Received: from ox-dell39.ox.adestra.com (no-reverse-dns.metronet-uk.com [85.199.232.226] (may be forged)) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.15.2/8.15.2) with ESMTPSA id t9U9lcQx084524 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 30 Oct 2015 09:47:46 GMT (envelope-from matthew@freebsd.org) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=freebsd.org DKIM-Filter: OpenDKIM Filter v2.10.3 smtp.infracaninophile.co.uk t9U9lcQx084524 Authentication-Results: smtp.infracaninophile.co.uk/t9U9lcQx084524; dkim=none; dkim-atps=neutral X-Authentication-Warning: lucid-nonsense.infracaninophile.co.uk: Host no-reverse-dns.metronet-uk.com [85.199.232.226] (may be forged) claimed to be ox-dell39.ox.adestra.com Subject: Re: Segmentation fault running ntpd To: freebsd-current@freebsd.org References: <20150718120956.GC1155@albert.catwhisker.org> <86pozwbvds.fsf@desk.des.no> <86lhakbua7.fsf@desk.des.no> <9D306406-691B-491E-8933-D991A09620A3@lastsummer.de> <5C3532DB-CFD2-4C30-8854-9C9E883D5148@lastsummer.de> From: Matthew Seaman X-Enigmail-Draft-Status: N1110 Message-ID: <56333CB1.5050003@freebsd.org> Date: Fri, 30 Oct 2015 09:47:29 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5C3532DB-CFD2-4C30-8854-9C9E883D5148@lastsummer.de> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cN8TTx5bwmB7Hu1kqwihcCiMdVSCihTct" X-Virus-Scanned: clamav-milter 0.98.7 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on lucid-nonsense.infracaninophile.co.uk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 30 Oct 2015 09:47:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cN8TTx5bwmB7Hu1kqwihcCiMdVSCihTct Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/30/15 09:32, Franco Fichtner wrote: > Well, it=E2=80=99s on stable/10 since September 16 and somebody reporte= d that > this particular branch would not trigger the crash along with HEAD, > but any 10.x would. Can=E2=80=99t find the reference right now though.= That was me, amongst others. There are threads on security@ and question= s@. >> On 30 Oct 2015, at 10:24 am, NGie Cooper wrote= : >> >> >>> On Oct 30, 2015, at 02:18, Franco Fichtner wro= te: >>> >>> Hi all, >>> >>> I did a quick test build and this seems to solve the ntpd crash issue= >>> on top of releng/10.1. >> >> Makes sense =E2=80=A6 looking through my email r287591 was never MFCed= back to stable/9 or stable/10 :/ . >> HTH, >> -NGie There were two problems reported: 1) ntpdc and ntpq would crash -- this was reported for 9.3-STABLE -- I don't think it affected other releases, and was diagnosed as due to a pthreads linking issue. Solved for 9.x in r290044 and r290046 2) ntpd SEGV's on startup on 10.2-RELEASE-p6 (possibly others). Curiously, so does net/ntp from ports, but only on the second startup. Exactly the same ntp package seems to run and restart just fine on recent 10-STABLE though. As does the base system ntpd. Cheers, Matthew =09 --cN8TTx5bwmB7Hu1kqwihcCiMdVSCihTct Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWMzy6AAoJEABRPxDgqeTn5poQAJ/JUSKykxkH2R2rkJHy1O7A bvroxyu+Yd5pxbRJkZMYkHtFu78mTS1Md8Onzs5VnYycpC9o9Jnql9fqahUfamn5 VvGhRFdisjaKADI8ztbnRVSSZJTMvxo7lBcDnsQRXgqa8Ky9zk2I1oPvEisnU8EK LAARfhg6dujgZTlCwpAyghBFthEwVFcCYMlPJll6LNsceIwuCB5IFssOBnvAwFUw WEpp2t9yYLspPN0gD8m+HeHrz5j4Y3BPK7Vh8rAY1ue9vdkBHN0doYN78xqS4cEl c0xjhf1CdDeuUGjYG3fuPwV84rwf9fvjB5oWfnZblW0RH+R3SmynghzSRHKbaOWJ uXV1IkHJScu3YayY9DTI3vRRz4sAGFm0Z4iQkh+9Qf97qPo0qxncPdHK1pR+H0Cd q9GJIn3szZ/wcrB/Aud4hTLVQ5WiWigmKEhbDAwknHqfuhOQsgwSOvejV2SemJRk VWnold1tjFefMgl7/riaWwJPB4XWRvaR8GtbaMpUsxBwwJmKuIm+nv1/r/Ug/ZWW nj6fXbeozI4ltkY5omQM+sKLfwQmOaT/LGZuV9Jm/CBxm42x3Z8oILzw2SNeWjhP F1Ls50y9sGMu0XFHDVdj1HiSOx1iG5PjOmSUZDmzSvtgTKBVYtgB3YLjxl50aZzS 6Qp365i7GFnE1zDRJLp3 =93pR -----END PGP SIGNATURE----- --cN8TTx5bwmB7Hu1kqwihcCiMdVSCihTct-- From owner-freebsd-current@freebsd.org Fri Oct 30 11:19:52 2015 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 70D19A21FA4 for ; Fri, 30 Oct 2015 11:19:52 +0000 (UTC) (envelope-from des@des.no) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 575F01A5E for ; Fri, 30 Oct 2015 11:19:52 +0000 (UTC) (envelope-from des@des.no) Received: by mailman.ysv.freebsd.org (Postfix) id 54213A21FA3; Fri, 30 Oct 2015 11:19:52 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 52DA7A21FA2 for ; Fri, 30 Oct 2015 11:19:52 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 0FA611A5D for ; Fri, 30 Oct 2015 11:19:51 +0000 (UTC) (envelope-from des@des.no) Received: from desk.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 3F2282C7D; Fri, 30 Oct 2015 11:19:51 +0000 (UTC) Received: by desk.des.no (Postfix, from userid 1001) id 2EB6EA67C; Fri, 30 Oct 2015 12:19:45 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Franco Fichtner Cc: NGie Cooper , David Wolfskill , FreeBSD CURRENT Subject: Re: Segmentation fault running ntpd References: <20150718120956.GC1155@albert.catwhisker.org> <86pozwbvds.fsf@desk.des.no> <86lhakbua7.fsf@desk.des.no> <9D306406-691B-491E-8933-D991A09620A3@lastsummer.de> <5C3532DB-CFD2-4C30-8854-9C9E883D5148@lastsummer.de> Date: Fri, 30 Oct 2015 12:19:44 +0100 In-Reply-To: <5C3532DB-CFD2-4C30-8854-9C9E883D5148@lastsummer.de> (Franco Fichtner's message of "Fri, 30 Oct 2015 10:32:05 +0100") Message-ID: <86ziz0ioxb.fsf@desk.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 30 Oct 2015 11:19:52 -0000 Franco Fichtner writes: > Well, it=E2=80=99s on stable/10 since September 16 and somebody reported = that > this particular branch would not trigger the crash along with HEAD, > but any 10.x would. Can=E2=80=99t find the reference right now though. OK, we should do an EN with that patch then, but we may have to include some of the other recent commits to the vm_map.c, which seem (at a quick glance) to be related. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@freebsd.org Fri Oct 30 11:35:01 2015 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 CBD66A20B5B for ; Fri, 30 Oct 2015 11:35:01 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id AFF8F12ED for ; Fri, 30 Oct 2015 11:35:01 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id ACA9BA20B59; Fri, 30 Oct 2015 11:35:01 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92CCBA20B58 for ; Fri, 30 Oct 2015 11:35:01 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 5795812EC for ; Fri, 30 Oct 2015 11:35:00 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id t9UBYov8071312; Fri, 30 Oct 2015 04:34:50 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id t9UBYnVt071311; Fri, 30 Oct 2015 04:34:49 -0700 (PDT) (envelope-from david) Date: Fri, 30 Oct 2015 04:34:49 -0700 From: David Wolfskill To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Cc: current@freebsd.org Subject: Re: Segmentation fault running ntpd Message-ID: <20151030113449.GF13438@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , current@freebsd.org References: <20150718120956.GC1155@albert.catwhisker.org> <86pozwbvds.fsf@desk.des.no> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oZv4yqUxWy6Z3hn+" Content-Disposition: inline In-Reply-To: <86pozwbvds.fsf@desk.des.no> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 30 Oct 2015 11:35:01 -0000 --oZv4yqUxWy6Z3hn+ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 30, 2015 at 09:42:07AM +0100, Dag-Erling Sm=F8rgrav wrote: > David Wolfskill writes: > > ... > > bound to 172.17.1.245 -- renewal in 43200 seconds. > > pid 544 (ntpd), uid 0: exited on signal 11 (core dumped) > > Starting Network: lo0 em0 iwn0 lagg0. > > ... >=20 > Did you find a solution? I'm wondering if the ntpd problems people are > reporting on freebsd-security@ are related. I vaguely recall hearing > that this had been traced to a pthread bug, but can't find anything > about it in commit logs or mailing list archives. > .... I don't recall finding "a solution" per se; that said, I also don't recall seeing an occurrence of the above for enough time that I'm not sure when I sent that message. :-} As a reality check: g1-252(11.0-C)[1] ls -lT /*.core -rw-r--r-- 1 root wheel 13783040 Aug 18 04:19:03 2015 /ntpd.core g1-252(11.0-C)[2]=20 So -- among other points -- my last sighting of whatever was causing that was the day I built: FreeBSD 11.0-CURRENT #157 r286880M/286880:1100079: Tue Aug 18 04:45:25 PDT= 2015 root@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd= 64 Note that the machines where I run head get updated daily (unless there's enough of a problem with head that I can't build it or can't boot it (and I'm unable to circumvent the issue within a reasonable time)) -- and while I do attempt to run ntpd on the machines, the above failure is more "annoying" than "crippling" in my particular case. And I'm presently running: FreeBSD 11.0-CURRENT #227 r290138M/290138:1100084: Thu Oct 29 05:12:58 PDT= 2015 root@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd= 64 and building head @r290190 as I type. And FWIW, I *suspect* that one of the issues involved (in my case) was a ... lack of determinism ... in events involving getting the (wireless) network connectivity into a usable state as part of the initial transition to multi-user mode. (I only have evidence at the moment of the issue on my laptop; my build machine, which only uses a wired NIC, has no /ntpd.core file. It and my laptop are updated pretty much in lock-step; it runs a completely GENERIC kernel, while the laptop runs a modestly customized one based on GENERIC.) Peace, david --=20 David H. Wolfskill david@catwhisker.org Those who would murder in the name of God or prophet are blasphemous coward= s. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --oZv4yqUxWy6Z3hn+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJWM1XZXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk70gQQAIDqscWwlqwRE/aQO2WXIWFz XwFD4OgHGqE2AW7tOO8tbNHsNBSeJ7Ml7pcuqopNHOZHqLKD2xqLa+wgQEX8rFC2 KHOXW+VjMYT/mZ6BeZRNH/3lzwAO+v4vGP6JNejcI/HKto9Zuu50/tjgqJZ5xvzU ++tktooQ81aaCTZQnksVY2CLp11kXmQRoBhD+ttLcM723I4isQ726waCWWQF7ggg VCwmai+twAKZ43zmLuGBfdPF5AqwDk29DKY1scFZL3tXmIdp9QBoZoFxxcsCBqyG v6J50ou8VDjBV/KIsABw7GFtBUSxqIKxpEGFwfpWRnMN9zAEebZQXaPbWPyhXoj/ M8YFqkhfy3t/Uz9ONflcLHBVsYE7RdOXi84ROgGShGs7ON9HISJuhbMWz/7pJTOc VKh3unZz7KxaWMUDIP4pTuNb5ZrV3YH5N3UPwTicG3G/bqNa4UuW5FxAfIMD5b+Z p3T6Kt97UQWfxiSV4DhJBoI5TWwgLZ35aRruvn/I/DDpSm31MCHYvdrmMjQZmTeA iCYLKofxFwRfltK1DXAf48svpd/K63TZizcJ0BCQN3BmySfb1P58Wg83sOqBndXR K/VpDqj3IrMcNbp9DJbqR+TW+GYPBDBSTDmnBBVcXAFFux/7UgJPwyizO3kyGDP2 0lgTqsdOI8Gk0hXcNIg5 =55Cg -----END PGP SIGNATURE----- --oZv4yqUxWy6Z3hn+-- From owner-freebsd-current@freebsd.org Fri Oct 30 12:13:50 2015 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 BF6E5A21B66 for ; Fri, 30 Oct 2015 12:13:50 +0000 (UTC) (envelope-from jon.ruse@thegarbagefile.org) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0114.outbound.protection.outlook.com [157.55.234.114]) (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 2E57C1AAA for ; Fri, 30 Oct 2015 12:13:49 +0000 (UTC) (envelope-from jon.ruse@thegarbagefile.org) Received: from HE1PR06MB0953.eurprd06.prod.outlook.com (10.162.251.14) by HE1PR06MB1353.eurprd06.prod.outlook.com (10.163.176.151) with Microsoft SMTP Server (TLS) id 15.1.312.18; Fri, 30 Oct 2015 12:13:39 +0000 Received: from HE1PR06MB0953.eurprd06.prod.outlook.com (10.162.251.14) by HE1PR06MB0953.eurprd06.prod.outlook.com (10.162.251.14) with Microsoft SMTP Server (TLS) id 15.1.306.13; Fri, 30 Oct 2015 12:13:37 +0000 Received: from HE1PR06MB0953.eurprd06.prod.outlook.com ([10.162.251.14]) by HE1PR06MB0953.eurprd06.prod.outlook.com ([10.162.251.14]) with mapi id 15.01.0306.003; Fri, 30 Oct 2015 12:13:37 +0000 From: Administrator To: "freebsd-current@freebsd.org" Subject: unsubscribe me please Thread-Topic: unsubscribe me please Thread-Index: AdETDFztRlDmzWN3SkuGr9R73ouuXw== Date: Fri, 30 Oct 2015 12:13:36 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jon.ruse@thegarbagefile.org; x-originating-ip: [82.37.211.165] x-microsoft-exchange-diagnostics: 1; HE1PR06MB0953; 5:LiY3hOnmhTjtcsVo5fKZN+nThDAryQxUcxJ4dzcGJH3hxhzCHyAa/A7oqWZ9hFTCc5qKp/AKOA4cgy0TtgB8/S1kDPkOct1x2//OCw0fTPr2eRpy5phMFmXgMdRqqQKroTCfxMU+fsn5cqNXLV0C+Q==; 24:ymaI9VWx1fizNSfhWSnKcIsgMsM8hRds+wVhUJ/4VS2iputMeSlGZ5N42mpQeBXO0/LuyEC+xbOmcepY0IxGPnBPImS8FMxScnf/+h38fq0=; 20:DrQOdibu5qreMxanuemSnWqaA4a09E2xCvh16p7NtwZjKt3VfQTYP3+DDEkMdwUsoy8Oz98FIMtwW0aGJjxBxw== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42134001)(42139001); SRVR:HE1PR06MB0953; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(10201501046)(3002001)(102215026); SRVR:HE1PR06MB0953; BCL:0; PCL:0; RULEID:; SRVR:HE1PR06MB0953; x-forefront-prvs: 07459438AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(189002)(199003)(92566002)(2351001)(229853001)(5001960100002)(107886002)(105586002)(5002640100001)(86362001)(76576001)(189998001)(106356001)(5008740100001)(81156007)(97736004)(110136002)(33656002)(74316001)(2501003)(87936001)(15975445007)(77096005)(40100003)(122556002)(54356999)(5003600100002)(10400500002)(66066001)(11100500001)(101416001)(102836002)(2900100001)(19580405001)(50986999)(5007970100001)(19580395003)(5004730100002)(450100001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR06MB0953; H:HE1PR06MB0953.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: thegarbagefile.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2015 12:13:36.6163 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4315f647-e505-436d-988d-06a3cb11edd4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR06MB0953 X-Microsoft-Exchange-Diagnostics: 1; HE1PR06MB1353; 2:O4lcCFG4ZtIkSEAbBB38r7jO3NfASMXoobmL7gDt0TxxydBn2vzPnPEQP4iWKTUpGWO8acPhaSrfpJWiRN3Z8YJwGdtb5Iwj/s5V14Q1/qr22kgAvLAl4S0U0U1/o6GQl8qyXkywBUpqrx+L2RoqXPZbpGaAFaOmYEHNoey2VGA=; 23:XI4z9gRanbJbYZXqad2Z6bW0jE5S88PukCLOKnkKRjjbzG21UCZAYZT5XsYLbBjf7ihXrIIYXdSZB+HHk98/zinIFEp/IhzFHkPgp3yiM00gkan9kkqAVmDrrNHwWcnw3BJyhQCa+BIc9izvPNP50y8y66rgrFjySOVMHe4WwuAmXKTW3h7qFPnM+huhX0Ee X-OriginatorOrg: thegarbagefile.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 30 Oct 2015 12:13:50 -0000 Unsubscribe me please -----Original Message----- From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd-current@freeb= sd.org] On Behalf Of freebsd-current-request@freebsd.org Sent: 30 October 2015 12:00 To: freebsd-current@freebsd.org Subject: freebsd-current Digest, Vol 627, Issue 5 Send freebsd-current mailing list submissions to freebsd-current@freebsd.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.freebsd.org/mailman/listinfo/freebsd-current or, via email, send a message with subject or body 'help' to freebsd-current-request@freebsd.org You can reach the person managing the list at freebsd-current-owner@freebsd.org When replying, please edit your Subject line so it is more specific than "R= e: Contents of freebsd-current digest..." From owner-freebsd-current@freebsd.org Fri Oct 30 14:26:52 2015 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 82887A1EB36 for ; Fri, 30 Oct 2015 14:26:52 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 6718A1E20 for ; Fri, 30 Oct 2015 14:26:52 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: by mailman.ysv.freebsd.org (Postfix) id 66ADDA1EB35; Fri, 30 Oct 2015 14:26:52 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C475A1EB34 for ; Fri, 30 Oct 2015 14:26:52 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) by mx1.freebsd.org (Postfix) with ESMTP id 337CD1E1E; Fri, 30 Oct 2015 14:26:52 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from marvin.beer.town (unknown [76.164.8.130]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 2821F56486; Fri, 30 Oct 2015 09:26:51 -0500 (CDT) Subject: Re: r288951: ifconfig -alias, arp not removed To: Bryan Drewery , current@FreeBSD.org References: <5632485F.5080203@FreeBSD.org> <56324C80.8000408@vangyzen.net> <56324D69.4080507@FreeBSD.org> <5632961B.2040604@FreeBSD.org> From: Eric van Gyzen Message-ID: <56337E2A.20500@vangyzen.net> Date: Fri, 30 Oct 2015 09:26:50 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <5632961B.2040604@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 30 Oct 2015 14:26:52 -0000 On 10/29/2015 16:56, Bryan Drewery wrote: > On 10/29/2015 9:46 AM, Bryan Drewery wrote: >> On 10/29/15 9:42 AM, Eric van Gyzen wrote: >>> On 10/29/2015 11:25, Bryan Drewery wrote: >>>> # ifconfig >>>> igb0: flags=8843 metric 0 mtu 1500 >>>> >>>> options=403bb >>>> ether c8:0a:a9:04:39:78 >>>> inet 10.10.0.7 netmask 0xffff0000 broadcast 10.10.255.255 >>>> inet 10.10.7.2 netmask 0xffff0000 broadcast 10.10.255.255 >>>> inet 10.10.0.9 netmask 0xffff0000 broadcast 10.10.255.255 >>>> nd6 options=23 >>>> media: Ethernet autoselect (1000baseT ) >>>> status: active >>>> >>>> # ifconfig igb0 inet 10.10.0.9 -alias >>>> # arp -an|grep 10.10.0.9 >>>> ? (10.10.0.9) at c8:0a:a9:04:39:78 on igb0 permanent [ethernet] >>>> # arp -d 10.10.0.9 >>>> arp: writing to routing socket: Operation not permitted >>>> >>>> I swear this is not normal. I'm on an older build as well, r288951. >>> >>> That definitely looks abnormal. See what "route get" says. I think >>> that's the error you get when there is a route for that address. >>> >> >> # netstat -rn|grep 10.10.0.9 >> # route get 10.10.0.9 >> route to: lapbox >> destination: 10.10.0.0 >> mask: 255.255.0.0 >> fib: 0 >> interface: igb0 >> flags: >> recvpipe sendpipe ssthresh rtt,msec mtu weight expire >> 0 0 0 0 1500 1 0 >> # route get 5.5.5.5 >> route to: 5.5.5.5 >> destination: default >> mask: default >> gateway: router.asus.com >> fib: 0 >> interface: igb0 >> flags: >> recvpipe sendpipe ssthresh rtt,msec mtu weight expire >> 0 0 0 0 1500 1 0 >> >> For more context, this current system had 10.10.0.9 added to it. I >> started up a VM which also started using 10.10.0.9 and managed to "win" >> on the local network for owning it. (I don't know arp and this stuff >> well). I then came to this system to remove the alias and the arp entry >> to allow me to connect from it and have gotten into this situation. >> > > Just saw this in dmesg, which is what I described: > > arp: 08:00:27:12:c1:a5 is using my IP address 10.10.0.9 on igb0! > arp: 08:00:27:12:c1:a5 is using my IP address 10.10.0.9 on igb0! > arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9 > on igb0 > arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9 > on igb0 > arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9 > on igb0 > arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9 > on igb0 The kernel should have removed the arp entry when you removed the alias. I just played with this on r289837 (one week old), and I could not reproduce the failure. In particular, r289501 sounds interesting, even though your interface is up. Eric From owner-freebsd-current@freebsd.org Fri Oct 30 16:03:51 2015 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 327F7A20E44 for ; Fri, 30 Oct 2015 16:03:51 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 176621C18 for ; Fri, 30 Oct 2015 16:03:51 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: by mailman.ysv.freebsd.org (Postfix) id 1501EA20E42; Fri, 30 Oct 2015 16:03:51 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EEF3EA20E41 for ; Fri, 30 Oct 2015 16:03:50 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from forward11h.cmail.yandex.net (forward11h.cmail.yandex.net [IPv6:2a02:6b8:0:f35::9c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 75AEC1C16; Fri, 30 Oct 2015 16:03:50 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from web12h.yandex.ru (web12h.yandex.ru [IPv6:2a02:6b8:0:f05::22]) by forward11h.cmail.yandex.net (Yandex) with ESMTP id 578AA2148A; Fri, 30 Oct 2015 19:03:37 +0300 (MSK) Received: from 127.0.0.1 (localhost [127.0.0.1]) by web12h.yandex.ru (Yandex) with ESMTP id A146AC2039A; Fri, 30 Oct 2015 19:03:36 +0300 (MSK) Received: by web12h.yandex.ru with HTTP; Fri, 30 Oct 2015 19:03:36 +0300 From: Alexander V. Chernikov Envelope-From: melifaro@ipfw.ru To: Bryan Drewery , "current@FreeBSD.org" In-Reply-To: <5632961B.2040604@FreeBSD.org> References: <5632485F.5080203@FreeBSD.org> <56324C80.8000408@vangyzen.net> <56324D69.4080507@FreeBSD.org> <5632961B.2040604@FreeBSD.org> Subject: Re: r288951: ifconfig -alias, arp not removed MIME-Version: 1.0 Message-Id: <1500541446221016@web12h.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Fri, 30 Oct 2015 19:03:36 +0300 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=koi8-r X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 30 Oct 2015 16:03:51 -0000 30.10.2015, 00:57, "Bryan Drewery" : > On 10/29/2015 9:46 AM, Bryan Drewery wrote: >> šOn 10/29/15 9:42 AM, Eric van Gyzen wrote: >>> šOn 10/29/2015 11:25, Bryan Drewery wrote: >>>> š# ifconfig >>>> šigb0: flags=8843 metric 0 mtu 1500 >>>> >>>> šoptions=403bb >>>> šššššššššether c8:0a:a9:04:39:78 >>>> šššššššššinet 10.10.0.7 netmask 0xffff0000 broadcast 10.10.255.255 >>>> šššššššššinet 10.10.7.2 netmask 0xffff0000 broadcast 10.10.255.255 >>>> šššššššššinet 10.10.0.9 netmask 0xffff0000 broadcast 10.10.255.255 >>>> šššššššššnd6 options=23 >>>> šššššššššmedia: Ethernet autoselect (1000baseT ) >>>> šššššššššstatus: active >>>> >>>> š# ifconfig igb0 inet 10.10.0.9 -alias >>>> š# arp -an|grep 10.10.0.9 >>>> š? (10.10.0.9) at c8:0a:a9:04:39:78 on igb0 permanent [ethernet] >>>> š# arp -d 10.10.0.9 >>>> šarp: writing to routing socket: Operation not permitted >>>> >>>> šI swear this is not normal. I'm on an older build as well, r288951. Well, there were changes on arpscrub procedures in r287789. (There was one bug fixed in r289501, but I think it is not relevant). Could you consider trying more recent HEAD and check if this is still reproducible? I was not able to reproduce that behavior. >>> >>> šThat definitely looks abnormal. See what "route get" says. I think >>> šthat's the error you get when there is a route for that address. >> >> š# netstat -rn|grep 10.10.0.9 >> š# route get 10.10.0.9 >> ššššroute to: lapbox >> šdestination: 10.10.0.0 >> ššššššššmask: 255.255.0.0 >> šššššššššfib: 0 >> šššinterface: igb0 >> šššššššflags: >> ššrecvpipe sendpipe ssthresh rtt,msec mtu weight expire >> šššššššš0 0 0 0 1500 1 0 >> š# route get 5.5.5.5 >> ššššroute to: 5.5.5.5 >> šdestination: default >> ššššššššmask: default >> šššššgateway: router.asus.com >> šššššššššfib: 0 >> šššinterface: igb0 >> šššššššflags: >> ššrecvpipe sendpipe ssthresh rtt,msec mtu weight expire >> šššššššš0 0 0 0 1500 1 0 >> >> šFor more context, this current system had 10.10.0.9 added to it. I >> šstarted up a VM which also started using 10.10.0.9 and managed to "win" >> šon the local network for owning it. (I don't know arp and this stuff >> šwell). I then came to this system to remove the alias and the arp entry >> što allow me to connect from it and have gotten into this situation. > > Just saw this in dmesg, which is what I described: > > arp: 08:00:27:12:c1:a5 is using my IP address 10.10.0.9 on igb0! > arp: 08:00:27:12:c1:a5 is using my IP address 10.10.0.9 on igb0! > arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9 > on igb0 > arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9 > on igb0 > arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9 > on igb0 > arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9 > on igb0 > > -- > Regards, > Bryan Drewery From owner-freebsd-current@freebsd.org Fri Oct 30 13:51:38 2015 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 05574A1E34B for ; Fri, 30 Oct 2015 13:51:38 +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 DBCC61989; Fri, 30 Oct 2015 13:51:37 +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 AD95E1FB7; Fri, 30 Oct 2015 13:51:37 +0000 (UTC) Date: Fri, 30 Oct 2015 13:51:12 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: gnn@FreeBSD.org, dteske@FreeBSD.org, delphij@FreeBSD.org, gonzo@FreeBSD.org, hiren@FreeBSD.org, bapt@FreeBSD.org, cem@FreeBSD.org, ngie@FreeBSD.org, jkim@FreeBSD.org, jtl@FreeBSD.org, imp@FreeBSD.org, kib@FreeBSD.org, andrew@FreeBSD.org, skra@FreeBSD.org, mckusick@FreeBSD.org, emaste@FreeBSD.org, np@FreeBSD.org, zbb@FreeBSD.org, jhb@FreeBSD.org, hselasky@FreeBSD.org, jilles@FreeBSD.org, melifaro@FreeBSD.org, bdrewery@FreeBSD.org, ed@FreeBSD.org, mav@FreeBSD.org, ache@FreeBSD.org, avg@FreeBSD.org, avos@FreeBSD.org, dumbbell@FreeBSD.org, kevlo@FreeBSD.org, jah@FreeBSD.org, vangyzen@FreeBSD.org, ae@FreeBSD.org, kp@FreeBSD.org, adrian@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <1551563138.7.1446213097509.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <618854355.7.1445994828754.JavaMail.jenkins@jenkins-9.freebsd.org> References: <618854355.7.1445994828754.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_amd64_gcc4.9 - Build #719 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_amd64_gcc4.9 X-Jenkins-Result: SUCCESS Precedence: bulk X-Mailman-Approved-At: Fri, 30 Oct 2015 16:40:31 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2015 13:51:38 -0000 FreeBSD_HEAD_amd64_gcc4.9 - Build #719 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/719/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/719/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/719/console Change summaries: 290193 by zbb: Use PCB/LR from PCB rather from stack on armv7-gdb The kernel dump does not store these values on the stack. Use PCB structure to resolve PC and LR properly. Submitted by: Wojciech Macek Reviewed by: jhb, kib Obtained from: Semihalf Sponsored by: Juniper Networks Inc. Differential Revision: https://reviews.freebsd.org/D4013 290192 by zbb: Workaround KGDB issues on ARM by ignoring ARM EABI version higher than 5 To make KGDB working, it needs to understand kernel ELF image. By default it is compiled using EABI_5, which is not supported on the gdb-6. As a workaround, treat these images as EABI_2 because they share a lot of things in common. This workaround does not guarantee ALL funtionalities to work. Submitted by: Wojciech Macek Reviewed by: jhb Obtained from: Semihalf Sponsored by: Juniper Networks Inc. Differential Revision: https://reviews.freebsd.org/D4012 290191 by avg: l2arc: do not call trim_map_free() for blocks with zero b_asize b_asize can be zero if the block is compressed into an empty block (ZIO_COMPRESS_EMPTY) and the trim code asserts that meaningless zero-sized trimming is not attempted. The logic for calling trim_map_free() is extracted into a new function l2arc_trim() to minimize code duplication. PR: 203473 Reported by: Willem Jan Withagen Tested by: Willem Jan Withagen MFC after: 11 days 290190 by ngie: Fix compiler warnings with open_to_operation.c Other sidenotes: - Remove unused variables with main(..) - Convert errx/exit with -1 to errx/exit with 1 - Fix a bogus test in try_directory_open (expected_errno == expected_errno -> errno == expected_errno) [*] - Fix some warnings related to discarded qualifiers - Remove a bogus else-statement at the end of check_mmap_exec(..) in the successful case. mmap(2), POSIX, Linux, etc all don't state what the behavior is when mixing O_WRONLY + PROT_EXEC, so assume success for now to get the test program to pass again. PR: 201286 [*] MFC after: 1 week Submitted by: David Binderman Sponsored by: EMC / Isilon Storage Division 290188 by kib: The prefix for CLFLUSHOPT is 0x66. It was right on amd64. Sponsored by: The FreeBSD Foundation 290186 by ed: Make truss work for CloudABI processes on aarch64. This change copies over amd64-cloudabi64.c to aarch64-cloudabi.c and adjusts it to fetch the proper registers on aarch64. To reduce the amount of shared code, the errno conversion function is moved into a separate source file. Reviewed by: jhb, andrew Differential Revision: https://reviews.freebsd.org/D4023 290185 by ngie: Disable h_raw/h_read with gcc I forgot that these testcases fail with gcc 4.2.1; add a note to that effect MFC after: never Sponsored by: EMC / Isilon Storage Division 290184 by ngie: Fix a set but not used variable warning flagged by gcc 4.9 with lib/libc/ssp/h_readlink MFC after: 3 days Sponsored by: EMC / Isilon Storage Division 290183 by ngie: - Re-enable h_raw with clang 3.7.0+ - Fix the compiler check to allow the test to be compiled for gcc PR: 196430 MFC after: never Sponsored by: EMC / Isilon Storage Division 290182 by ngie: Fix rtsold's usage message - Remove -a from the usage message example dealing with specific interfaces. -a only makes sense when not specifying an interface, such that it's to be run on all interfaces - Fix the pidfile option (it's -p, not -P) - Change `interfaces` to `interface` to match the manpage MFC after: 3 days PR: 173744 Sponsored by: EMC / Isilon Storage Division 290181 by ngie: Unbreak bsd.progs.mk with PROGS (but not PROGS_CXX) and when invoking the "one of many" targets, e.g. `make hello_world`, where hello_world is a C program Tested with: PROGS and PROGS_CXX MFC after: 1 week X-MFC with: r289289 Sponsored by: EMC / Isilon Storage Division 290180 by ngie: Follow up to roundup feature addition in r289203 - Rename -r to -R to avoid the clash with makefs -r in NetBSD - Note that -R is an FFS-specific option because it's not implemented in cd9660 today - Rename the roundup variable to "roundup-size" in the manpage and help text for consistency with other variables. - Bump .Dd (missed in r289203) PR: 203707 MFC after: 1 week X-MFC with: r289203 Differential Revision: https://reviews.freebsd.org/D3959 Reviewed by: adrian (earlier patch), emaste Sponsored by: EMC / Isilon Storage Division 290179 by ngie: Remove a set but unused variable in __getgroupmembership to fix a gcc 4.9+ warning MFC after: 1 week Sponsored by: EMC / Isilon Storage Division 290178 by ngie: Fix GOST engine cipher linkage by adding e_gost_err.c to SRCS so it picks up undefined symbols, like "ERR_load_GOST_strings" MFC after: 3 days PR: 184805 Submitted by: Ivan IvanZhdanov Sponsored by: EMC / Isilon Storage Division 290177 by ngie: Integrate contrib/netbsd-tests/lib/libc/rpc into the FreeBSD test suite as lib/libc/rpc This testcase requires rpcbind be up in running; otherwise the testcases will time out and be skipped MFC after: 1 week Sponsored by: EMC / Isilon Storage Division 290176 by gonzo: Fix BULK read transfer if destination buffer is not cache line-aligned. We can't use copyout because destination memory is userland address in another process but we have reference to respective page so map the page into kernel address space and copy fragments there 290175 by np: cxgbe/tom: decide whether to shove segments or not only if there is payload to transmit. MFC after: 1 week 290174 by delphij: In pw_userlock, set 'name' to NULL when we encounter an all number string because it is also used as an indicator of whether a name or an UID is being used and we may have undefined results as 'name' may contain uninitialized stack contents. MFC after: 2 weeks 290173 by delphij: Use strlcpy(). MFC after: 2 weeks 290171 by gonzo: Fix framebuffer compatibility with new RPi firmware. Framebuffer driver receives video memory address from VideoCore through property mailbox channel. Older versions of firmware (and the one that is currently part of sysutils/u-boot-rpi and sysutils/u-boot-rpi2) returned real physical address, newer one returns VideoCore bus address, so we need to convert it to actual physical address. this version works with both older and newer interface. 290170 by bdrewery: Remove unneeded NULL as this is initialized with M_ZERO. MFC after: 2 weeks Sponsored by: EMC / Isilon Storage Division 290169 by bdrewery: Use memmove(3) to avoid overlapping copy. Reported by: valgrind MFC after: 2 weeks X-MFC-With: r290168 290168 by bdrewery: Fix several memory leaks, and crashes, in iconvlist(3). - Both curitem and curitem (via the names list) was always leaked. - malloc(3) failures lead to some leaks. - __bsd___iconv_get_list() failure lead to a crash since its error was not handles and __bsd___iconv_free_list() is not NULL-safe. I have slightly refactored this to avoid extra malloc and free logic in cases of malloc(3) failing. There are still bad assumptions here that I did not deal with. One of which is that the data will always have a '/' so the strchr(3) will not return NULL. Coverity CID: 1130055 1130054 1130053 290167 by gonzo: Fix LEAVE_HYP macro: spsr is not guaranteed to contain valid value at this point, e.g. on RaspberryPi 2 when control is passed from loader to kernel it contains garbage. So we use cpsr as a base for new cpsr value: if we have reached this point it means current value is OK Reviewed by: andrew 290166 by skra: Install myself as src committer. Approved by: kib (mentor) 290165 by gnn: Set the proper direction to check for policies in this one case. Pointed out by: eri Sponsored by: Rubicon Communications (Netgate) 290164 by jhb: Use movw instead of movl (or plain mov) when moving segment registers into memory. This is a nop on clang's assembler, but some assemblers complain if the size suffix is incorrect. Submitted by: bde 290163 by dteske: Ignore per-mdN settings in mdconfig[2] startup PR: base/189696 Submitted by: ganael.laplanche@martymac.org MFC after: 3 days X-MFC-to: stable/10 stable/9 290162 by jtl: Add myself (jtl) and my mentor to the committers-src.dot file. Approved by: gnn (mentor) Differential Revision: https://reviews.freebsd.org/D4029 290161 by kp: pf: Fix IPv6 checksums with route-to. When using route-to (or reply-to) pf sends the packet directly to the output interface. If that interface doesn't support checksum offloading the checksum has to be calculated in software. That was already done in the IPv4 case, but not for the IPv6 case. As a result we'd emit packets with pseudo-header checksums (i.e. incorrect checksums). This issue was exposed by the changes in r289316 when pf stopped performing full checksum calculations for all packets. Submitted by: Luoqi Chen MFC after: 1 week 290160 by mav: Remove some unneeded code. 290159 by mav: Remove reset delays for which I see neither explanation nor need. 290158 by cem: ntb: Revert r290130 now that r290156 has landed Nagged by: vangyzen Sponsored by: EMC / Isilon Storage Division 290157 by bdrewery: Check archive_entry_new() result. Coverity CID: 1331341 290156 by cem: pmap_change_attr: Only fixup DMAP for DMAPed ranges pmap_change_attr must change the memory type of both the requested KVA and the corresponding DMAP mappings (if such mappings exist), to satisfy an Intel requirement that two or more mappings to the same physical pages must have the same memory type. However, not all kernel mapped pages have corresponding DMAP mappings -- for example, 64-bit BARs. Skip fixing up the DMAP for out-of-bounds addresses. Submitted by: Steve Wahl Reviewed by: alc, jhb Sponsored by: Dell Compellent Differential Revision: https://reviews.freebsd.org/D4030 290155 by bdrewery: getnewbuf: Initialize bp to avoid uninitialized pointer dereference and brelse(). This came in recently in r289279. Coverity CID: 1331561 290154 by bdrewery: Avoid passing an uninitialized 'i'. Currently nothing was depending on it anyhow. Coverity CID: 1331562 290153 by bdrewery: Fix unlikely memory leak. It is unlikely since the first check in the function is that dir[0] is '/', but later code changes may make it real. Coverity CID: 1332104 290148 by imp: PC Card and Cardbus are now in extended maintenance mode. No need to have them cluttering up MAINTAINERS. 290147 by mav: Fix and improve error masking and reporting. 290144 by jhb: Update for LINUX32 rename. The assembler didn't complain about undefined symbols but just used 0 after the rename. 290143 by jhb: Fix build with DEBUG defined. Reported by: hselasky 290140 by hselasky: Add missing NULL check in physio(). When destroying a character device the si_devsw field is set to NULL before all references are gone, to indicate the character device is going away. This can cause a NULL-dereference fault inside physio(). The callers of physio() should own a thread reference on the cdev and if si_devsw is seen as non-NULL, it is usable during the execution of the function. Else an ENXIO error code is returned. Reviewed by: kib MFC after: 2 weeks 290139 by mav: Some minor additions to r290138, 290138 by mav: Some updates to isp(4) manual page. 290136 by hselasky: Add myself to MAINTAINERS. 290135 by hselasky: Finish process of moving the LinuxKPI module into the default kernel build. - Move all files related to the LinuxKPI into sys/compat/linuxkpi and its subfolders. - Update sys/conf/files and some Makefiles to use new file locations. - Added description of COMPAT_LINUXKPI to sys/conf/NOTES which in turn adds the LinuxKPI to all LINT builds. - The LinuxKPI can be added to the kernel by setting the COMPAT_LINUXKPI option. The OFED kernel option no longer builds the LinuxKPI into the kernel. This was done to keep the build rules for the LinuxKPI in sys/conf/files simple. - Extend the LinuxKPI module to include support for USB by moving the Linux USB compat from usb.ko to linuxkpi.ko. - Bump the FreeBSD_version. - A universe kernel build has been done. Reviewed by: np @ (cxgb and cxgbe related changes only) Sponsored by: Mellanox Technologies 290134 by kevlo: Remove the static function declaration. 290133 by kevlo: - Add a missing prototype - Fix typos 290132 by cem: ioat_test: Handled forced hardware resets gracefully Sponsored by: EMC / Isilon Storage Division 290131 by cem: ioat: Drain/quiesce the device less racily On detach and during a forced HW reset. Sponsored by: EMC / Isilon Storage Division 290130 by cem: ntb: Do not attempt to set write-combining on MWs AMD64 pmap assumes ranges will be in the DMAP, which isn't necessarily true for NTB memory windows (especially 64-bit BARs). Suggested by: pmap_change_attr_locked -> kassert_panic Sponsored by: EMC / Isilon Storage Division 290129 by cem: ioatcontrol(8): Add and document "raw" testing mode Allows DMA from/to arbitrary KVA or physical address. /dev/ioat_test must be enabled by root and is only R/W root, so this is approximately as dangerous as /dev/mem and /dev/kmem. Sponsored by: EMC / Isilon Storage Division 290128 by kevlo: Add MLINKS for if_otus(4), if_rsu(4) and if_urtwn(4). 290127 by kevlo: Xref otus(4). 290126 by bdrewery: Fix regression from using .USEBEFORE in _SUBDIR in r289705. Using .USEBEFORE had the unintended side-effect of changing the directory for the real target ran in the current directory. For example this meant that the 'make clean' would run in one of the SUBDIR. Sponsored by: EMC / Isilon Storage Division Pointyhat to: bdrewery 290123 by adrian: Oops - use the wrong array offset. 290122 by hiren: Calculate the correct amount of bytes that are in-flight for a connection as suggested by RFC 6675. Currently differnt places in the stack tries to guess this in suboptimal ways. The main problem is that current calculations don't take sacked bytes into account. Sacked bytes are the bytes receiver acked via SACK option. This is suboptimal because it assumes that network has more outstanding (unacked) bytes than the actual value and thus sends less data by setting congestion window lower than what's possible which in turn may cause slower recovery from losses. As an example, one of the current calculations looks something like this: snd_nxt - snd_fack + sackhint.sack_bytes_rexmit New proposal from RFC 6675 is: snd_max - snd_una - sackhint.sacked_bytes + sackhint.sack_bytes_rexmit which takes sacked bytes into account which is a new addition to the sackhint struct. Only thing we are missing from RFC 6675 is isLost() i.e. segment being considered lost and thus adjusting pipe based on that which makes this calculation a bit on conservative side. The approach is very simple. We already process each ack with sack info in tcp_sack_doack() and extract sack blocks/holes out of it. We'd now also track this new variable sacked_bytes which keeps track of total sacked bytes reported. One downside to this approach is that we may get incorrect count of sacked_bytes if the other end decides to drop sack info in the ack because of memory pressure or some other reasons. But in this (not very likely) case also the pipe calculation would be conservative which is okay as opposed to being aggressive in sending packets into the network. Next step is to use this more accurate pipe estimation to drive congestion window adjustments. In collaboration with: rrs Reviewed by: jason_eggnet dot com, rrs MFC after: 2 weeks Sponsored by: Limelight Networks Differential Revision: https://reviews.freebsd.org/D3971 290121 by jkim: Define endianness for non-x86 platforms. MFC after: 3 days 290120 by jah: Retire pmap_dmap_iscurrent(). It is only a wrapper around pmap_is_current(), and is no longer called. 290119 by imp: BUS_ADD_CHILD calls device_add_child. device_add_child does not call BUS_ADD_CHILD. Make it explicit since it follows the command paradigm rather than the callback paradigm. Add other clarifying notes as well. 290118 by mav: Change the way how target mode is enabled on 23xx chips. Without docs I am not completely sure about this, but on my tests new method works better then previous, at least with our latest firmware. 290117 by imp: Add a note to the effect that BUS_ADD_CHILD calls device_add_child_ordered to add the child. device_add_child_ordered doesn't call BUS_ADD_CHILD. 290116 by ae: Check the size of data available in mbuf, before using them. PR: 202667 MFC after: 1 week 290115 by bdrewery: Include libutil's headers directly from src to avoid recording a dirdeps dependency for META MODE. 290113 by bdrewery: Connect mpsutil for META MODE. 290112 by vangyzen: Fix spelling and grammer in tools/test/README. Reviewed by: gnn 290110 by ache: Add _flags2 per jhb@ suggestion since no room left in _flags. Rewrite O_APPEND flag checking using new __S2OAP flag. MFC after: 3 weeks 290106 by andrew: Remove the s3c2xx0 code, it's no longer used. As far as I know I as the main user of this code, however I haven't used it in over two years, and don't expect to in the future. 290105 by andrew: Start to remove support for the XScale i80321. As far as I can tell nobody uses this which makes it difficult to support. 290104 by mav: Improve/fix loop scanning routine. For the most of chips (except anscient ones) port handlers have no relation to port IDs. In such situation old code scanning first 125 handlers was quite naive. Instead of doing that, send to chip single request to get full list of port handlers available on specific virtual port and scan only them. Old code had problems with case of several virtual ports enabled, when port handlers allocated from global address space could easily go above 125. This change was successfully tested on 23xx, 24xx and 25xx chips in loop mode with 4 virtual initiator ports, each seing 50 virtual target ports. 290103 by bapt: Connect mpsutil(8) to the build Sponsored by: Gandi.net 290102 by bapt: Merge mpsutil(8) branch mpsutil(8)/mprutil(8) are new utilities for managing LSI Fusion-MPT 2/3 controllers (mps(4) and mpr(4)) For now only informational commands have been implemented. This utility has been written by scottl@ [1] and polished by myself[2] Submitted by: scottl Discussed with: scottl Relnotes: yes Sponsored by: Netflix [1] Sponsored by: Gandi.net [2] 290101 by hselasky: Build fix for i386/XBOX and pc98/GENERIC. Reviewed by: kib 290090 by adrian: Add some debugging code (under ARGE_DEBUG) that counts each interrupt source. This should make it easier to track down interrupt storms from arge. Tested: * AP135 (QCA955x) SoC - defaults to ARGE_DEBUG enabled * Carambola2 (AR9331 SoC) - defaults to ARGE_DEBUG disabled 290089 by gnn: Add a test for the listen queue using two test programs, listen, and connect. The listen program is a simple server that accepts and closes sockets, until a fixed limit, then sets the listen queue to 0 and counts how many remaining connections it processes. The connect program repeatedly opens connections and closes them serving as the driver for the listen program. Sponsored by: Limelight Networks 290088 by gnn: Update the README to describe all the current tests in this directory. 290087 by cem: ioat: Define DMACAPABILITY bits Check for BFILL capability before initiating blockfill operations. Sponsored by: EMC / Isilon Storage Division 290086 by bdrewery: Use proper CONFDIR after r289148 290085 by andrew: Start to remove support for the Samsung s3c24x0 SoCs by removing the kernel config, and support from NOTES. 290084 by bdrewery: Remove unneeded NAME override. MFC after: 2 weeks Sponsored by: EMC / Isilon Storage Division 290083 by bdrewery: Use more appropriate ${SHAREDIR} rather than /usr/share. MFC after: 2 weeks Sponsored by: EMC / Isilon Storage Division 290082 by adrian: mips: use the correct va for wbinv flushing. arge doesn't trigger this, but ath(4) does. Tested: * AR9331 SoC (Carambola2); ath(4) hostap Submitted by: ian 290081 by mckusick: Bring the tags and links entries for amd64 up to date. Based on how out of date it is, I doubt that anyone other than me and my code-reading students still use it. 290079 by andrew: Mark functions as such. This means we call them directly rather than have the dynamic linker copy them, but not relocate them at the new location. This allows us to run sqlite3 without it crashing. Sponsored by: ABT Systems Ltd 290075 by melifaro: Use m_cat() to reassembly IPv6 packets. Submitted by: jonloony_gmail.com MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D3863 290073 by delphij: Update NetBSD RCS IDs to reflect the changes being upstreamed. MFC after: 13 days X-MFC-With: r290024 290072 by melifaro: Eliminate last rtalloc_ign() caller. Differential Revision: https://reviews.freebsd.org/D3927 290071 by bapt: Update libucl to latest git snapshot (20151027) 290070 by dumbbell: drm/i915: Reduce diff with Linux 3.8 There is no functional change. The goal is to ease the future update to Linux 3.8's i915 driver. MFC after: 2 months 290065 by jilles: libedit: Use correct buffer lengths in vi mode v command. Libedit's vi mode provides a v command to edit the current line in vi(1) (hard-coded to vi, in fact). When Unicode/wide character mode was added, this command started truncating and/or corrupting the edited text. This commit fixes v if the text fits into the buffer. If the text is longer, it is truncated. PR: 203743 Obtained from: NetBSD (originally submitted by me) 290059 by emaste: Add WITHOUT_DEBUG_FILES description 290058 by avos: net80211: add ieee80211_restart_all() call. This call may be used when device cannot continue to operate normally (e.g., throws firmware error, watchdog timer expires) and need to be restarted. Approved by: adrian (mentor) Differential Revision: https://reviews.freebsd.org/D3998 290055 by dumbbell: drm/i915: Reduce diff with Linux 3.8 There is no functional change. The goal is to ease the future update to Linux 3.8's i915 driver. MFC after: 2 months From owner-freebsd-current@freebsd.org Fri Oct 30 18:48:07 2015 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 ECA5CA1F02F for ; Fri, 30 Oct 2015 18:48:07 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C9F0F1805 for ; Fri, 30 Oct 2015 18:48:07 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: by mailman.ysv.freebsd.org (Postfix) id C5EBFA1F02D; Fri, 30 Oct 2015 18:48:07 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C5506A1F02C; Fri, 30 Oct 2015 18:48:07 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) (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 6E0DD1804; Fri, 30 Oct 2015 18:48:07 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from amavis-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3nnXhM0Gp9z1VQ; Fri, 30 Oct 2015 19:48:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:from:from:date:date:content-transfer-encoding :content-type:content-type:mime-version:received:received :received:received; s=jakla4; t=1446230879; x=1448822880; bh=i3q r+9cu6SOyOhWJJDfqSKQJ1hRSwDNXLO1L85w3vU0=; b=h4PusJ1Xxd3E0Ca4tD/ K0rhYk7xexPTVit0Ef60aR6npOCpMUqMG3Ehr5qGhfuoBkMlNIFDFpf0GY24l2te tufgdXKFgZU5Y+jqHtxL9chkSz+N9v3EC0zV9wSx/rtdnZb03DuvqqRyRecpHhkm AMIvB0w+fxr3GsX0GgBrdIYQ= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10026) with LMTP id 6qn9fXfNBepo; Fri, 30 Oct 2015 19:47:59 +0100 (CET) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP id 3nnXhH5Pbkz1VN; Fri, 30 Oct 2015 19:47:59 +0100 (CET) Received: from nabiralnik.ijs.si (nabiralnik.ijs.si [IPv6:2001:1470:ff80::80:16]) by mildred.ijs.si (Postfix) with ESMTP id 3nnXhH4W4Cz175; Fri, 30 Oct 2015 19:47:59 +0100 (CET) Received: from neli.ijs.si (2001:1470:ff80:88:21c:c0ff:feb1:8c91) by nabiralnik.ijs.si with HTTP (HTTP/1.1 POST); Fri, 30 Oct 2015 19:47:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 30 Oct 2015 19:47:59 +0100 From: Mark Martinec To: freebsd-stable@freebsd.org, current@freebsd.org Subject: Re: Segmentation fault running ntpd Organization: Jozef Stefan Institute In-Reply-To: <20151030113449.GF13438@albert.catwhisker.org> References: <20150718120956.GC1155@albert.catwhisker.org> <86pozwbvds.fsf@desk.des.no> <20151030113449.GF13438@albert.catwhisker.org> Message-ID: X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.1.3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 30 Oct 2015 18:48:08 -0000 Not sure if it's the same issue, but it sure looks like it is. I have upgraded a couple of hosts (amd64) from 10.2-RELEASE-p5 to 10.2-RELEASE-p6, i.e. the freebsd-upgrade essentially just replaced the /usr/sbin/ntpd with a new one; then I restarted the ntpd. On all host but one this was successful: the new ntpd starts fine and works normally. But on one of these machines the ntpd process immediately crashes with SIGSEGV. That machine has an Intel Xeon cpu. It is not apparent to me in what way this machine differs from others, Played with some variations of ntpd on that host, here are some findings: - the new ntpd (that came with 10.2-RELEASE-p6) runs fine if it does *not* daemonize, i.e. ntpd with an option -n or -d stays attached to a terminal and works fine; the same happens when run under ktrace -d -i ntpd ... it works fine, even when it daemonizes; - the ntpd built from fresh net/ntp-devel behaves exactly the same: crashes on that machine when it daemonizes - a previous ntpd (from 10.2-RELEASE-p5) works fine, so I ended up downgrading ntpd to that previous version on that machine. Also a ntpd from a recent 10-STABLE when copied to that host runs fine there! I haven't tried yet to build it with debugging, or capture a core dump. Puzzling... Mark 2015-10-30 12:34, je David Wolfskill napisal > On Fri, Oct 30, 2015 at 09:42:07AM +0100, Dag-Erling Smørgrav wrote: >> David Wolfskill writes: >> > ... >> > bound to 172.17.1.245 -- renewal in 43200 seconds. >> > pid 544 (ntpd), uid 0: exited on signal 11 (core dumped) >> > Starting Network: lo0 em0 iwn0 lagg0. >> > ... >> >> Did you find a solution? I'm wondering if the ntpd problems people >> are >> reporting on freebsd-security@ are related. I vaguely recall hearing >> that this had been traced to a pthread bug, but can't find anything >> about it in commit logs or mailing list archives. >> .... > > I don't recall finding "a solution" per se; that said, I also don't > recall seeing an occurrence of the above for enough time that I'm not > sure when I sent that message. :-} > > As a reality check: > > g1-252(11.0-C)[1] ls -lT /*.core > -rw-r--r-- 1 root wheel 13783040 Aug 18 04:19:03 2015 /ntpd.core > g1-252(11.0-C)[2] > > So -- among other points -- my last sighting of whatever was causing > that was the day I built: > > FreeBSD 11.0-CURRENT #157 r286880M/286880:1100079: Tue Aug 18 > 04:45:25 PDT 2015 > root@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 > > Note that the machines where I run head get updated daily (unless > there's enough of a problem with head that I can't build it or can't > boot it (and I'm unable to circumvent the issue within a reasonable > time)) -- and while I do attempt to run ntpd on the machines, the above > failure is more "annoying" than "crippling" in my particular case. > > And I'm presently running: > > FreeBSD 11.0-CURRENT #227 r290138M/290138:1100084: Thu Oct 29 > 05:12:58 PDT 2015 > root@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 > > and building head @r290190 as I type. > > And FWIW, I *suspect* that one of the issues involved (in my case) > was a ... lack of determinism ... in events involving getting the > (wireless) network connectivity into a usable state as part of the > initial transition to multi-user mode. (I only have evidence at > the moment of the issue on my laptop; my build machine, which only > uses a wired NIC, has no /ntpd.core file. It and my laptop are updated > pretty much in lock-step; it runs a completely GENERIC kernel, while > the laptop runs a modestly customized one based on GENERIC.) > > Peace, > david From owner-freebsd-current@freebsd.org Fri Oct 30 20:57:12 2015 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 C7CCFA22269 for ; Fri, 30 Oct 2015 20:57:12 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id A72781AEB for ; Fri, 30 Oct 2015 20:57:12 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id A52AAA22268; Fri, 30 Oct 2015 20:57:12 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A4C96A22267 for ; Fri, 30 Oct 2015 20:57:12 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::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 791F11AE9; Fri, 30 Oct 2015 20:57:12 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by pacfv9 with SMTP id fv9so87680355pac.3; Fri, 30 Oct 2015 13:57:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=Nt1dNFTC9dk08jP6J1nloWgxrMq31So6BbyPpxOUAwc=; b=N7zZfNR3jzO3vQwwBpMRGp6AdOy1oXu2XfK97uTLhT6idW0MugThcNIbWzyWIaavEr nu4fCn45Fig3Qcw0rX9vLzX1omK5sE72r6gl7IWwTgLrHR1+jMh99kWemcrXnGjFDriQ SidE2k/rQ262r93AMtCgRYEUCpJmlbSZZhUSGSOCTmm1CquXo0UBN9vp6T3YPxmmJvA8 XyLtwou+yhbGUcXC8O6oqWs0IfmCXJTQn7Yxc9530RgGgJ/SgszpCxaVof4Vz7BDAOMS /TveRD+i4wTQYiHqwImoY84hAEh/056SCxkBqseuYc+Ljcgki9v/iMQ6fcqUmJu7RLKt Vv+w== X-Received: by 10.66.124.200 with SMTP id mk8mr10782558pab.25.1446238632138; Fri, 30 Oct 2015 13:57:12 -0700 (PDT) Received: from [192.168.20.7] (c-24-16-212-205.hsd1.wa.comcast.net. [24.16.212.205]) by smtp.gmail.com with ESMTPSA id yi8sm9889030pab.22.2015.10.30.13.57.11 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Oct 2015 13:57:11 -0700 (PDT) From: NGie Cooper Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect Date: Fri, 30 Oct 2015 13:57:10 -0700 Message-Id: <653F31AA-982B-4026-BEF5-F608BCFFFD3A@gmail.com> Cc: Ed Maste , Mark Johnston , FreeBSD CURRENT To: Bryan Drewery , "Simon J. Gerraty" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 30 Oct 2015 20:57:13 -0000 Hi Bryan/Simon! I tried doing buildworld on powerpc/powerpc with = -DWITH_DTRACE_TESTS and I ran into this linker issue below. I have no = idea (yet) why it=E2=80=99s trying to compile an x64 object when I = specify powerpc/powerpc =E2=80=94 and more importantly, why is the = object not being put in obj.powerpc? I ran into the same issue on ref11-amd64.freebsd.org when I ran = =E2=80=9Cmake tinderbox". Thanks! -NGie % make buildworld TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc =E2=80=A6 =3D=3D=3D> cddl/usr.sbin/dtrace/tests/common/json (all) (cd /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json && = DEPENDFILE=3D.depend.tst.usdt.exe NO_SUBDIR=3D1 make -f = /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile = _RECURSING_PROGS=3D PROG=3Dtst.usdt.exe ) cc -O2 -pipe -fno-strict-aliasing -O2 -pipe -O0 -g = -I/usr/obj/powerpc.powerpc/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/j= son -std=3Dgnu99 -fstack-protector-strong -c = /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/tst.= usdt.c -o tst.usdt.o dtrace -C -x nolibs -G -o usdt.o -s = /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt= .d tst.usdt.o dtrace: failed to link script = /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt= .d: incorrect ELF machine type for object file: tst.usdt.o *** Error code 1 $ find /usr/obj/usr/src/svn/ -name tst.usdt.o /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o $ file = /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: = ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped= From owner-freebsd-current@freebsd.org Fri Oct 30 20:57:46 2015 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 17703A222B3 for ; Fri, 30 Oct 2015 20:57:46 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx2.freebsd.org", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0A95F1C4A for ; Fri, 30 Oct 2015 20:57:46 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx2.freebsd.org (Postfix) with ESMTP id BABEB66E65 for ; Fri, 30 Oct 2015 20:57:45 +0000 (UTC) (envelope-from jkim@FreeBSD.org) To: FreeBSD-current From: Jung-uk Kim Subject: [HEADSUP] OpenSSL updated to 1.0.2d Message-ID: <5633D9C9.2060906@FreeBSD.org> Date: Fri, 30 Oct 2015 16:57:45 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 30 Oct 2015 20:57:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL on head has been updated to 1.0.2d. Please make sure to recompile all binaries depending on libcrypto.so.7 or libssl.so.7. Cheers! Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWM9nDAAoJEHyflib82/FGuV8H+gKZRDJ/FvPQ/D5wCTBddfgJ 0i8ptgdzWtSABOSOUeKYBceHhiHUOjlnl2UdMv3JWq6virqCx1YXlJTIHACeZL7D SSqyuMT3qfZFLwi8fw/dnzgIZx1N86wQlIZOU/3807SN0+h0uCcOq1/Dj/j/wsQx XpM/tLgnQfqiRSl8pZPUleyOKqqhrFv+pJv7uybAQzTwdQ03pzhd694dy4futsg2 wxFLUK8BbXWv1ZW37wDysyMyaem02nqCMYUXPoGfjMEwN6DFsx3WVUyKpZxMYQ8x fNtV3l61tXRczQWzh/rnslSxjbbjMlS4/DKt2x+mzHELUFiOoPqc3/z0CgFUoNk= =Wa/Z -----END PGP SIGNATURE----- From owner-freebsd-current@freebsd.org Fri Oct 30 21:21:30 2015 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 780A5A226C7 for ; Fri, 30 Oct 2015 21:21:30 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 58CAA151A for ; Fri, 30 Oct 2015 21:21:30 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 56C65A226C6; Fri, 30 Oct 2015 21:21:30 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3B8A4A226C5 for ; Fri, 30 Oct 2015 21:21:30 +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 198801516; Fri, 30 Oct 2015 21:21:30 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 0C42B1D62; Fri, 30 Oct 2015 21:21:30 +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 BD487105E9; Fri, 30 Oct 2015 21:21:29 +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 29tZfMv0hwDv; Fri, 30 Oct 2015 21:21:22 +0000 (UTC) Subject: Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 4CFD5105E4 To: NGie Cooper , "Simon J. Gerraty" References: <653F31AA-982B-4026-BEF5-F608BCFFFD3A@gmail.com> Cc: Ed Maste , Mark Johnston , FreeBSD CURRENT From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <5633DF51.1070305@FreeBSD.org> Date: Fri, 30 Oct 2015 14:21:21 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <653F31AA-982B-4026-BEF5-F608BCFFFD3A@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5krXj5lf1eJxV4m2xg1AM9l3JL3N3Iocm" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 30 Oct 2015 21:21:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5krXj5lf1eJxV4m2xg1AM9l3JL3N3Iocm Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/30/2015 1:57 PM, NGie Cooper wrote: > Hi Bryan/Simon! > I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS a= nd I ran into this linker issue below. I have no idea (yet) why it=E2=80=99= s trying to compile an x64 object when I specify powerpc/powerpc =E2=80=94= and more importantly, why is the object not being put in obj.powerpc? > I ran into the same issue on ref11-amd64.freebsd.org when I ran =E2=80= =9Cmake tinderbox". > Thanks! > -NGie >=20 Have you modified any of your local toolchain handling, or skipped CLANG_BOOTSTRAP? I would expect this to be failing much more broadly and there to be a lot more reports if there was a problem with buildworld cross compiling. > % make buildworld TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc > =E2=80=A6 > =3D=3D=3D> cddl/usr.sbin/dtrace/tests/common/json (all) > (cd /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json && DEPENDFILE=3D= =2Edepend.tst.usdt.exe NO_SUBDIR=3D1 make -f /usr/src/svn/cddl/usr.sbin/= dtrace/tests/common/json/Makefile _RECURSING_PROGS=3D PROG=3Dtst.usdt.ex= e ) > cc -O2 -pipe -fno-strict-aliasing -O2 -pipe -O0 -g -I/usr/obj/powerp= c.powerpc/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json -std=3Dgnu99= -fstack-protector-strong -c /usr/src/svn/cddl/contrib/opensolaris/cmd= /dtrace/test/tst/common/json/tst.usdt.c -o tst.usdt.o > dtrace -C -x nolibs -G -o usdt.o -s /usr/src/svn/cddl/contrib/opensolar= is/cmd/dtrace/test/tst/common/json/usdt.d tst.usdt.o > dtrace: failed to link script /usr/src/svn/cddl/contrib/opensolaris/cmd= /dtrace/test/tst/common/json/usdt.d: incorrect ELF machine type for objec= t file: tst.usdt.o > *** Error code 1 > $ find /usr/obj/usr/src/svn/ -name tst.usdt.o > /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o > $ file /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.= usdt.o > /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:= ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped >=20 --=20 Regards, Bryan Drewery --5krXj5lf1eJxV4m2xg1AM9l3JL3N3Iocm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJWM99RAAoJEDXXcbtuRpfP7NsH/118B7ustqSvWnuJxWIC0Hyq DAzKu/iGVtpUGg5je356F1w9i7qtq9fN9PyKzPGN8/67i9xg13nsij+FNw6dWeuh qDQHfThQW40Oj+pfBn14zjve61pruEkZazkKAThtRYB/BxUaUsLAxzlpmudWH98G rwnYH1Wk4dx2YX02qc5fhD9kKab0LtLOdGJlUE1KZ2/+zc+7L9WzwNdR1JJnQQIM 8+wH0htL2rnNBZoN+WdlBGqO6ydJ7+ZExb4tBpiXKMZzuID7atpX//q56065mBqK tytOrKMnXQk/2yizv/HLrwvehHXHStxyfr5CSDHIRbe91yGJuCe7rQdT6SMMZ8k= =Rfte -----END PGP SIGNATURE----- --5krXj5lf1eJxV4m2xg1AM9l3JL3N3Iocm-- From owner-freebsd-current@freebsd.org Fri Oct 30 21:34:52 2015 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 D542EA228E6 for ; Fri, 30 Oct 2015 21:34:52 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B4AA51DE5 for ; Fri, 30 Oct 2015 21:34:52 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id B30FEA228E5; Fri, 30 Oct 2015 21:34:52 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B2ABAA228E4 for ; Fri, 30 Oct 2015 21:34:52 +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 990731DE4; Fri, 30 Oct 2015 21:34:52 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 8F3691136; Fri, 30 Oct 2015 21:34:52 +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 517CB10609; Fri, 30 Oct 2015 21:34:52 +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 R2subz_nCkDw; Fri, 30 Oct 2015 21:34:49 +0000 (UTC) Subject: Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 70C6D10603 To: NGie Cooper , "Simon J. Gerraty" References: <653F31AA-982B-4026-BEF5-F608BCFFFD3A@gmail.com> <5633DF51.1070305@FreeBSD.org> Cc: Ed Maste , Mark Johnston , FreeBSD CURRENT From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <5633E27C.6000101@FreeBSD.org> Date: Fri, 30 Oct 2015 14:34:52 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5633DF51.1070305@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Ob6TCNlRos0oSTuPfmU8M9Bmo687eb1Jv" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 30 Oct 2015 21:34:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ob6TCNlRos0oSTuPfmU8M9Bmo687eb1Jv Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/30/2015 2:21 PM, Bryan Drewery wrote: > On 10/30/2015 1:57 PM, NGie Cooper wrote: >> Hi Bryan/Simon! >> I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS = and I ran into this linker issue below. I have no idea (yet) why it=E2=80= =99s trying to compile an x64 object when I specify powerpc/powerpc =E2=80= =94 and more importantly, why is the object not being put in obj.powerpc?= >> I ran into the same issue on ref11-amd64.freebsd.org when I ran =E2=80= =9Cmake tinderbox". >> Thanks! >> -NGie >> >=20 > Have you modified any of your local toolchain handling, or skipped > CLANG_BOOTSTRAP? I would expect this to be failing much more broadly an= d > there to be a lot more reports if there was a problem with buildworld > cross compiling. >=20 >> % make buildworld TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc >> =E2=80=A6 >> =3D=3D=3D> cddl/usr.sbin/dtrace/tests/common/json (all) >> (cd /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json && DEPENDFILE= =3D.depend.tst.usdt.exe NO_SUBDIR=3D1 make -f /usr/src/svn/cddl/usr.sbin= /dtrace/tests/common/json/Makefile _RECURSING_PROGS=3D PROG=3Dtst.usdt.e= xe ) >> cc -O2 -pipe -fno-strict-aliasing -O2 -pipe -O0 -g -I/usr/obj/power= pc.powerpc/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json -std=3Dgnu9= 9 -fstack-protector-strong -c /usr/src/svn/cddl/contrib/opensolaris/cm= d/dtrace/test/tst/common/json/tst.usdt.c -o tst.usdt.o >> dtrace -C -x nolibs -G -o usdt.o -s /usr/src/svn/cddl/contrib/opensola= ris/cmd/dtrace/test/tst/common/json/usdt.d tst.usdt.o >> dtrace: failed to link script /usr/src/svn/cddl/contrib/opensolaris/cm= d/dtrace/test/tst/common/json/usdt.d: incorrect ELF machine type for obje= ct file: tst.usdt.o >> *** Error code 1 >> $ find /usr/obj/usr/src/svn/ -name tst.usdt.o >> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o= >> $ file /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst= =2Eusdt.o >> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o= : ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped >> I ran a buildworld with TARGET=3Dpowerpc just a few days ago and it seeme= d to be fine with PROGS. Here's a test object built via PROGS: ~/git/freebsd # find /usr/obj/powerpc.powerpc -name ld_library_pathfds.o /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_libra= ry_pathfds.o ~/git/freebsd # file /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_libra= ry_pathfds.o /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_libra= ry_pathfds.o: ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (FreeBSD), not stripped -rw-r--r-- 1 root wheel 21136 Oct 23 17:08 /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_libra= ry_pathfds.o I see nothing special with the DTRACE_TESTS to change any of this. --=20 Regards, Bryan Drewery --Ob6TCNlRos0oSTuPfmU8M9Bmo687eb1Jv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJWM+J8AAoJEDXXcbtuRpfPJPAH/i0f1wzE6JybxAh/2nxkYABv k9CI4xvv7i1Vk8wpeEopCq1mmcXAIhVfnpWyEsfg7xrXIFvl0T792zi0yZySluHx 6QkYRgoWeCfdBYutTrf8bq+J4LZQeI41zy1o1UxUk9elPPGHJW2Lyb11qpYD/HTV 5ucJfIJEYGohET9yJbEBSB13GK3lXyQt0mKE7F6vKmDEcd7tq/prCoRWrgm7jHoF ijM0YTtfNAmBAv5NWiy7TNhYj3G83BBjDYRc6ZCTwBbSrMgLzzo9x2GyDLaCto8O JVK86Bgg/w09YR3sSHQKxL9zl81xWyBul0nTG0cMUHit2gh4HVHNCQg7F5ZV/AE= =MZyq -----END PGP SIGNATURE----- --Ob6TCNlRos0oSTuPfmU8M9Bmo687eb1Jv-- From owner-freebsd-current@freebsd.org Fri Oct 30 22:03:59 2015 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 6ACFBA22D72 for ; Fri, 30 Oct 2015 22:03:59 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 4AC4019E0 for ; Fri, 30 Oct 2015 22:03:59 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 47317A22D70; Fri, 30 Oct 2015 22:03:59 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2D945A22D6F for ; Fri, 30 Oct 2015 22:03:59 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) 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 DD19119DF; Fri, 30 Oct 2015 22:03:58 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by qgad10 with SMTP id d10so73128931qga.3; Fri, 30 Oct 2015 15:03:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=RHf02r1RryH/DraqnmvnbVUoTe4KduVIe/TahJ5skDU=; b=U4YssHLLc2sPGjIJbHZIXqOfBgo8EEX98TLXSDxFjUAURnHR0+yu7qbXizA2THqlHD 1DfWy0WkgPTXjaxJI6tYx5rofPYscCktbLU1fZnakvwTWnnhDHrB0EWe0V+c/F5XnCJL ZugzsG5pM9F4QDeQCqh49OWMbBJLfjKLmtTWHqP+VSaa/Cov8veEFwZeiDZQsXVINVLM Pigr7FPBZ+GIsyIdps4XzRf+HNl1o1h9lic5rc8JIDljNOq1lWmsKQEVtG4bVupIF+6P 7WHL1DO+94sbLywvAjCfBDBSkGWkn+qc6VF1JpuM4tIlUzh/6jAI/QMoZOkY5asnteZF iarg== MIME-Version: 1.0 X-Received: by 10.140.128.16 with SMTP id 16mr13617268qha.54.1446242637745; Fri, 30 Oct 2015 15:03:57 -0700 (PDT) Received: by 10.140.88.209 with HTTP; Fri, 30 Oct 2015 15:03:57 -0700 (PDT) In-Reply-To: <5633E27C.6000101@FreeBSD.org> References: <653F31AA-982B-4026-BEF5-F608BCFFFD3A@gmail.com> <5633DF51.1070305@FreeBSD.org> <5633E27C.6000101@FreeBSD.org> Date: Fri, 30 Oct 2015 15:03:57 -0700 Message-ID: Subject: Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect From: NGie Cooper To: Bryan Drewery Cc: "Simon J. Gerraty" , Ed Maste , Mark Johnston , FreeBSD CURRENT Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 30 Oct 2015 22:03:59 -0000 On Fri, Oct 30, 2015 at 2:34 PM, Bryan Drewery wrote= : > On 10/30/2015 2:21 PM, Bryan Drewery wrote: >> On 10/30/2015 1:57 PM, NGie Cooper wrote: >>> Hi Bryan/Simon! >>> I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TES= TS and I ran into this linker issue below. I have no idea (yet) why it=E2= =80=99s trying to compile an x64 object when I specify powerpc/powerpc =E2= =80=94 and more importantly, why is the object not being put in obj.powerpc= ? >>> I ran into the same issue on ref11-amd64.freebsd.org when I ran = =E2=80=9Cmake tinderbox". >>> Thanks! >>> -NGie >>> >> >> Have you modified any of your local toolchain handling, or skipped >> CLANG_BOOTSTRAP? I would expect this to be failing much more broadly and >> there to be a lot more reports if there was a problem with buildworld >> cross compiling. >> >>> % make buildworld TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc >>> =E2=80=A6 >>> =3D=3D=3D> cddl/usr.sbin/dtrace/tests/common/json (all) >>> (cd /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json && DEPENDFILE= =3D.depend.tst.usdt.exe NO_SUBDIR=3D1 make -f /usr/src/svn/cddl/usr.sbin/d= trace/tests/common/json/Makefile _RECURSING_PROGS=3D PROG=3Dtst.usdt.exe ) >>> cc -O2 -pipe -fno-strict-aliasing -O2 -pipe -O0 -g -I/usr/obj/powerp= c.powerpc/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json -std=3Dgnu99 -= fstack-protector-strong -c /usr/src/svn/cddl/contrib/opensolaris/cmd/dtr= ace/test/tst/common/json/tst.usdt.c -o tst.usdt.o >>> dtrace -C -x nolibs -G -o usdt.o -s /usr/src/svn/cddl/contrib/opensolar= is/cmd/dtrace/test/tst/common/json/usdt.d tst.usdt.o >>> dtrace: failed to link script /usr/src/svn/cddl/contrib/opensolaris/cmd= /dtrace/test/tst/common/json/usdt.d: incorrect ELF machine type for object = file: tst.usdt.o >>> *** Error code 1 >>> $ find /usr/obj/usr/src/svn/ -name tst.usdt.o >>> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o >>> $ file /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.= usdt.o >>> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:= ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped >>> > > I ran a buildworld with TARGET=3Dpowerpc just a few days ago and it seeme= d > to be fine with PROGS. Here's a test object built via PROGS: > > ~/git/freebsd # find /usr/obj/powerpc.powerpc -name ld_library_pathfds.o > /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_libra= ry_pathfds.o > ~/git/freebsd # file > /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_libra= ry_pathfds.o > /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_libra= ry_pathfds.o: > ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (FreeBSD), > not stripped > -rw-r--r-- 1 root wheel 21136 Oct 23 17:08 > /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_libra= ry_pathfds.o > > I see nothing special with the DTRACE_TESTS to change any of this. I could see there being a possible issue with my host VM, but I haven't modified my environment in ref11-amd64.freebsd.org at all. Could you please try reproing it there with your user? Thanks, -NGie From owner-freebsd-current@freebsd.org Fri Oct 30 23:01:28 2015 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 DEBEDA21998 for ; Fri, 30 Oct 2015 23:01:27 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id BB425143E for ; Fri, 30 Oct 2015 23:01:27 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id B896EA21997; Fri, 30 Oct 2015 23:01:27 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B82F5A21996 for ; Fri, 30 Oct 2015 23:01:27 +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 98FFF143C; Fri, 30 Oct 2015 23:01:27 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 8CFA4125F; Fri, 30 Oct 2015 23:01:27 +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 4290A10700; Fri, 30 Oct 2015 23:01:27 +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 fZPb7aVfa_XX; Fri, 30 Oct 2015 23:01:24 +0000 (UTC) Subject: Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 459F3106FA To: NGie Cooper References: <653F31AA-982B-4026-BEF5-F608BCFFFD3A@gmail.com> <5633DF51.1070305@FreeBSD.org> <5633E27C.6000101@FreeBSD.org> Cc: "Simon J. Gerraty" , Ed Maste , Mark Johnston , FreeBSD CURRENT From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <5633F6C7.4080500@FreeBSD.org> Date: Fri, 30 Oct 2015 16:01:27 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mfXbb0Srb75tuKgSBWUii5JXnjiVwxDjv" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 30 Oct 2015 23:01:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mfXbb0Srb75tuKgSBWUii5JXnjiVwxDjv Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/30/2015 3:03 PM, NGie Cooper wrote: > On Fri, Oct 30, 2015 at 2:34 PM, Bryan Drewery w= rote: >> On 10/30/2015 2:21 PM, Bryan Drewery wrote: >>> On 10/30/2015 1:57 PM, NGie Cooper wrote: >>>> Hi Bryan/Simon! >>>> I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_= TESTS and I ran into this linker issue below. I have no idea (yet) why it= =E2=80=99s trying to compile an x64 object when I specify powerpc/powerpc= =E2=80=94 and more importantly, why is the object not being put in obj.p= owerpc? >>>> I ran into the same issue on ref11-amd64.freebsd.org when I ran= =E2=80=9Cmake tinderbox". >>>> Thanks! >>>> -NGie >>>> >>> >>> Have you modified any of your local toolchain handling, or skipped >>> CLANG_BOOTSTRAP? I would expect this to be failing much more broadly = and >>> there to be a lot more reports if there was a problem with buildworld= >>> cross compiling. >>> >>>> % make buildworld TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc >>>> =E2=80=A6 >>>> =3D=3D=3D> cddl/usr.sbin/dtrace/tests/common/json (all) >>>> (cd /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json && DEPENDFI= LE=3D.depend.tst.usdt.exe NO_SUBDIR=3D1 make -f /usr/src/svn/cddl/usr.sb= in/dtrace/tests/common/json/Makefile _RECURSING_PROGS=3D PROG=3Dtst.usdt= =2Eexe ) >>>> cc -O2 -pipe -fno-strict-aliasing -O2 -pipe -O0 -g -I/usr/obj/pow= erpc.powerpc/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json -std=3Dgn= u99 -fstack-protector-strong -c /usr/src/svn/cddl/contrib/opensolaris/= cmd/dtrace/test/tst/common/json/tst.usdt.c -o tst.usdt.o >>>> dtrace -C -x nolibs -G -o usdt.o -s /usr/src/svn/cddl/contrib/openso= laris/cmd/dtrace/test/tst/common/json/usdt.d tst.usdt.o >>>> dtrace: failed to link script /usr/src/svn/cddl/contrib/opensolaris/= cmd/dtrace/test/tst/common/json/usdt.d: incorrect ELF machine type for ob= ject file: tst.usdt.o >>>> *** Error code 1 The problem looks specific to compiling of .d files using dtrace(1). It must not have cross-compile support. The manpage does say: "The D compiler produces programs using the native data model of the operating system kernel.". So these will need to be disabled for non-native builds. I don't know if it would be possible to build a cross-compile version of dtrace(1) and drop it in WORLDTMP/usr/sbin and have it work. >>>> $ find /usr/obj/usr/src/svn/ -name tst.usdt.o >>>> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt= =2Eo >>>> $ file /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/t= st.usdt.o >>>> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt= =2Eo: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripp= ed >>>> >> >> I ran a buildworld with TARGET=3Dpowerpc just a few days ago and it se= emed >> to be fine with PROGS. Here's a test object built via PROGS: >> >> ~/git/freebsd # find /usr/obj/powerpc.powerpc -name ld_library_pathfds= =2Eo >> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_li= brary_pathfds.o >> ~/git/freebsd # file >> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_li= brary_pathfds.o >> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_li= brary_pathfds.o: >> ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (FreeBSD)= , >> not stripped >> -rw-r--r-- 1 root wheel 21136 Oct 23 17:08 >> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_li= brary_pathfds.o >> >> I see nothing special with the DTRACE_TESTS to change any of this. >=20 > I could see there being a possible issue with my host VM, but I > haven't modified my environment in ref11-amd64.freebsd.org at all. >=20 > Could you please try reproing it there with your user? >=20 > Thanks, > -NGie >=20 --=20 Regards, Bryan Drewery --mfXbb0Srb75tuKgSBWUii5JXnjiVwxDjv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJWM/bHAAoJEDXXcbtuRpfP3i0H/0lKt+SzK2ksTezx+Agk8aJo kB/gfnIdPK9pkR/oAY7OSMeKxgvbfZ4CWf5miyapq7BJxUtPxlDp0IHpdweqUMC5 YaOHOmGYiH+BSBgiaNrmXsPOXz4xuydRWTKHgc9Q5k071OLkuDOnrfB9ipOrXC76 ESLdx3wBOSoi3Sy6sk50d8K+WIpaa0u6boaGF5LAMceOtIub1QG7pj65TlzlMbm/ pNWVhKokx2a9iu9Jwvsq5nqVB529m1XNXEmg3e0RC32ifQJcIMqujzKD5ysGBGcl 2xuFs/TYLzl7svyilaJP2WDQpNEDDfUlMDM38+NzqlkErfuqXwrPM3MS1SDKQsI= =OBIz -----END PGP SIGNATURE----- --mfXbb0Srb75tuKgSBWUii5JXnjiVwxDjv-- From owner-freebsd-current@freebsd.org Fri Oct 30 23:07:20 2015 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 C75FBA21B31 for ; Fri, 30 Oct 2015 23:07:20 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 9FF5C17A8 for ; Fri, 30 Oct 2015 23:07:20 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 9D18AA21B30; Fri, 30 Oct 2015 23:07:20 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9CA2BA21B2E for ; Fri, 30 Oct 2015 23:07:20 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::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 5247617A7; Fri, 30 Oct 2015 23:07:20 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by qgem9 with SMTP id m9so74019722qge.1; Fri, 30 Oct 2015 16:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=hamE2U4SkhdjKuH2vC3FClA391Necevow0RAoXBnhqU=; b=Iypp0gzPtVKcUxHfNM9f1BnlVd28SGkDUzmqDFRwrLN+MiPon1h6yZRmYrfjqz74Fu bEJ+Z4i6znW/RQEoFthlLMcGW9FCrkqe76z8M6VWegIUmJCP41aP+BkkHvM2lkKVnzpO 7DqVpcGeBnp2BeEarNS5bJbwokwQi3WdvnDRBNDvMYpcEaJ4Q8TFdy5PFusOIVJbFpce fFkLflrJr59JM1JxcZ4TKU1Sov6go5DSxywEwnYb6io2QVaDNnBMk34h2J1vH9ojzDJ/ ZM5rFPcbrY90fonaCrgj2O32ntpjqzQEjl9ukeGQDIB0UXqwNflAf0i4k6Rzllu8xT5j xXGw== X-Received: by 10.140.246.69 with SMTP id r66mr14629993qhc.56.1446246439231; Fri, 30 Oct 2015 16:07:19 -0700 (PDT) Received: from wkstn-mjohnston.west.isilon.com (c-67-182-131-225.hsd1.wa.comcast.net. [67.182.131.225]) by smtp.gmail.com with ESMTPSA id p64sm3411410qkl.30.2015.10.30.16.07.18 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Oct 2015 16:07:18 -0700 (PDT) Sender: Mark Johnston Date: Fri, 30 Oct 2015 16:08:17 -0700 From: Mark Johnston To: Bryan Drewery Cc: NGie Cooper , "Simon J. Gerraty" , Ed Maste , FreeBSD CURRENT Subject: Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect Message-ID: <20151030230817.GA3845@wkstn-mjohnston.west.isilon.com> References: <653F31AA-982B-4026-BEF5-F608BCFFFD3A@gmail.com> <5633DF51.1070305@FreeBSD.org> <5633E27C.6000101@FreeBSD.org> <5633F6C7.4080500@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5633F6C7.4080500@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 30 Oct 2015 23:07:21 -0000 On Fri, Oct 30, 2015 at 04:01:27PM -0700, Bryan Drewery wrote: > On 10/30/2015 3:03 PM, NGie Cooper wrote: > > On Fri, Oct 30, 2015 at 2:34 PM, Bryan Drewery wrote: > >> On 10/30/2015 2:21 PM, Bryan Drewery wrote: > >>> On 10/30/2015 1:57 PM, NGie Cooper wrote: > >>>> Hi Bryan/Simon! > >>>> I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS and I ran into this linker issue below. I have no idea (yet) why it’s trying to compile an x64 object when I specify powerpc/powerpc — and more importantly, why is the object not being put in obj.powerpc? > >>>> I ran into the same issue on ref11-amd64.freebsd.org when I ran “make tinderbox". > >>>> Thanks! > >>>> -NGie > >>>> > >>> > >>> Have you modified any of your local toolchain handling, or skipped > >>> CLANG_BOOTSTRAP? I would expect this to be failing much more broadly and > >>> there to be a lot more reports if there was a problem with buildworld > >>> cross compiling. > >>> > >>>> % make buildworld TARGET=powerpc TARGET_ARCH=powerpc > >>>> … > >>>> ===> cddl/usr.sbin/dtrace/tests/common/json (all) > >>>> (cd /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json && DEPENDFILE=.depend.tst.usdt.exe NO_SUBDIR=1 make -f /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile _RECURSING_PROGS= PROG=tst.usdt.exe ) > >>>> cc -O2 -pipe -fno-strict-aliasing -O2 -pipe -O0 -g -I/usr/obj/powerpc.powerpc/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json -std=gnu99 -fstack-protector-strong -c /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/tst.usdt.c -o tst.usdt.o > >>>> dtrace -C -x nolibs -G -o usdt.o -s /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d tst.usdt.o > >>>> dtrace: failed to link script /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d: incorrect ELF machine type for object file: tst.usdt.o > >>>> *** Error code 1 > > The problem looks specific to compiling of .d files using dtrace(1). It > must not have cross-compile support. > > The manpage does say: "The D compiler produces programs using the native > data model of the operating system kernel.". > > So these will need to be disabled for non-native builds. > > I don't know if it would be possible to build a cross-compile version of > dtrace(1) and drop it in WORLDTMP/usr/sbin and have it work. In the snippet above, tst.usdt.o is generated by cc, not dtrace(1). dtrace is complaining that the input file doesn't have the expected machine type, which seems valid given the file(1) output below. > > >>>> $ find /usr/obj/usr/src/svn/ -name tst.usdt.o > >>>> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o > >>>> $ file /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o > >>>> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped > >>>> > >> > >> I ran a buildworld with TARGET=powerpc just a few days ago and it seemed > >> to be fine with PROGS. Here's a test object built via PROGS: > >> > >> ~/git/freebsd # find /usr/obj/powerpc.powerpc -name ld_library_pathfds.o > >> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o > >> ~/git/freebsd # file > >> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o > >> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o: > >> ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (FreeBSD), > >> not stripped > >> -rw-r--r-- 1 root wheel 21136 Oct 23 17:08 > >> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o > >> > >> I see nothing special with the DTRACE_TESTS to change any of this. > > > > I could see there being a possible issue with my host VM, but I > > haven't modified my environment in ref11-amd64.freebsd.org at all. > > > > Could you please try reproing it there with your user? > > > > Thanks, > > -NGie > > > > > -- > Regards, > Bryan Drewery > From owner-freebsd-current@freebsd.org Fri Oct 30 23:09:58 2015 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 0271DA21CD7 for ; Fri, 30 Oct 2015 23:09:58 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id D19EE1CFB for ; Fri, 30 Oct 2015 23:09:57 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id CEE31A21CD6; Fri, 30 Oct 2015 23:09:57 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CE744A21CD5 for ; Fri, 30 Oct 2015 23:09:57 +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 B0B971CFA; Fri, 30 Oct 2015 23:09:57 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id A038817A4; Fri, 30 Oct 2015 23:09:57 +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 65AA01073D; Fri, 30 Oct 2015 23:09:57 +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 F6wAWNI34lvO; Fri, 30 Oct 2015 23:09:54 +0000 (UTC) Subject: Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 3C70810737 To: Mark Johnston References: <653F31AA-982B-4026-BEF5-F608BCFFFD3A@gmail.com> <5633DF51.1070305@FreeBSD.org> <5633E27C.6000101@FreeBSD.org> <5633F6C7.4080500@FreeBSD.org> <20151030230817.GA3845@wkstn-mjohnston.west.isilon.com> Cc: NGie Cooper , "Simon J. Gerraty" , Ed Maste , FreeBSD CURRENT From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <5633F8C5.6040500@FreeBSD.org> Date: Fri, 30 Oct 2015 16:09:57 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151030230817.GA3845@wkstn-mjohnston.west.isilon.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BdiK8hFnKoaetNS77MaHoeVdAhQhG9Ofl" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 30 Oct 2015 23:09:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BdiK8hFnKoaetNS77MaHoeVdAhQhG9Ofl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/30/2015 4:08 PM, Mark Johnston wrote: > On Fri, Oct 30, 2015 at 04:01:27PM -0700, Bryan Drewery wrote: >> On 10/30/2015 3:03 PM, NGie Cooper wrote: >>> On Fri, Oct 30, 2015 at 2:34 PM, Bryan Drewery = wrote: >>>> On 10/30/2015 2:21 PM, Bryan Drewery wrote: >>>>> On 10/30/2015 1:57 PM, NGie Cooper wrote: >>>>>> Hi Bryan/Simon! >>>>>> I tried doing buildworld on powerpc/powerpc with -DWITH_DTRAC= E_TESTS and I ran into this linker issue below. I have no idea (yet) why = it=E2=80=99s trying to compile an x64 object when I specify powerpc/power= pc =E2=80=94 and more importantly, why is the object not being put in obj= =2Epowerpc? >>>>>> I ran into the same issue on ref11-amd64.freebsd.org when I r= an =E2=80=9Cmake tinderbox". >>>>>> Thanks! >>>>>> -NGie >>>>>> >>>>> >>>>> Have you modified any of your local toolchain handling, or skipped >>>>> CLANG_BOOTSTRAP? I would expect this to be failing much more broadl= y and >>>>> there to be a lot more reports if there was a problem with buildwor= ld >>>>> cross compiling. >>>>> >>>>>> % make buildworld TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc >>>>>> =E2=80=A6 >>>>>> =3D=3D=3D> cddl/usr.sbin/dtrace/tests/common/json (all) >>>>>> (cd /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json && DEPEND= FILE=3D.depend.tst.usdt.exe NO_SUBDIR=3D1 make -f /usr/src/svn/cddl/usr.= sbin/dtrace/tests/common/json/Makefile _RECURSING_PROGS=3D PROG=3Dtst.us= dt.exe ) >>>>>> cc -O2 -pipe -fno-strict-aliasing -O2 -pipe -O0 -g -I/usr/obj/p= owerpc.powerpc/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json -std=3D= gnu99 -fstack-protector-strong -c /usr/src/svn/cddl/contrib/opensolari= s/cmd/dtrace/test/tst/common/json/tst.usdt.c -o tst.usdt.o >>>>>> dtrace -C -x nolibs -G -o usdt.o -s /usr/src/svn/cddl/contrib/open= solaris/cmd/dtrace/test/tst/common/json/usdt.d tst.usdt.o >>>>>> dtrace: failed to link script /usr/src/svn/cddl/contrib/opensolari= s/cmd/dtrace/test/tst/common/json/usdt.d: incorrect ELF machine type for = object file: tst.usdt.o >>>>>> *** Error code 1 >> >> The problem looks specific to compiling of .d files using dtrace(1). I= t >> must not have cross-compile support. >> >> The manpage does say: "The D compiler produces programs using the nati= ve >> data model of the operating system kernel.". >> >> So these will need to be disabled for non-native builds. >> >> I don't know if it would be possible to build a cross-compile version = of >> dtrace(1) and drop it in WORLDTMP/usr/sbin and have it work. >=20 > In the snippet above, tst.usdt.o is generated by cc, not dtrace(1). > dtrace is complaining that the input file doesn't have the expected > machine type, which seems valid given the file(1) output below. >=20 The example output must be a mistake as they are correct on ref11: ref11-amd64% find /scratch/tmp/ngie/obj/*/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/c= ommon/json -name tst.usdt.o -exec file {} + /scratch/tmp/ngie/obj/arm.arm/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/t= ests/common/json/tst.usdt.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not stripped /scratch/tmp/ngie/obj/arm.armeb/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace= /tests/common/json/tst.usdt.o: ELF 32-bit MSB relocatable, ARM, EABI5 version 1 (FreeBSD), not stripped /scratch/tmp/ngie/obj/arm.armv6/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace= /tests/common/json/tst.usdt.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not stripped /scratch/tmp/ngie/obj/arm.armv6hf/scratch/tmp/ngie/svn/cddl/usr.sbin/dtra= ce/tests/common/json/tst.usdt.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not stripped /scratch/tmp/ngie/obj/arm64.aarch64/scratch/tmp/ngie/svn/cddl/usr.sbin/dt= race/tests/common/json/tst.usdt.o: ELF 64-bit LSB relocatable, ARM aarch64, version 1 (FreeBSD), not stripped /scratch/tmp/ngie/obj/i386.i386/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace= /tests/common/json/tst.usdt.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD), not stripped /scratch/tmp/ngie/obj/pc98.i386/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace= /tests/common/json/tst.usdt.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD), not stripped /scratch/tmp/ngie/obj/powerpc.powerpc/scratch/tmp/ngie/svn/cddl/usr.sbin/= dtrace/tests/common/json/tst.usdt.o: ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (FreeBSD), not stripped /scratch/tmp/ngie/obj/powerpc.powerpc64/scratch/tmp/ngie/svn/cddl/usr.sbi= n/dtrace/tests/common/json/tst.usdt.o: ELF 64-bit MSB relocatable, 64-bit PowerPC or cisco 7500, version 1 (FreeBSD), not stripped [sorry for bad mail client] >> >>>>>> $ find /usr/obj/usr/src/svn/ -name tst.usdt.o >>>>>> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.us= dt.o >>>>>> $ file /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json= /tst.usdt.o >>>>>> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.us= dt.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripp= ed >>>>>> >>>> >>>> I ran a buildworld with TARGET=3Dpowerpc just a few days ago and it = seemed >>>> to be fine with PROGS. Here's a test object built via PROGS: >>>> >>>> ~/git/freebsd # find /usr/obj/powerpc.powerpc -name ld_library_pathf= ds.o >>>> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_= library_pathfds.o >>>> ~/git/freebsd # file >>>> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_= library_pathfds.o >>>> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_= library_pathfds.o: >>>> ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (FreeBS= D), >>>> not stripped >>>> -rw-r--r-- 1 root wheel 21136 Oct 23 17:08 >>>> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_= library_pathfds.o >>>> >>>> I see nothing special with the DTRACE_TESTS to change any of this. >>> >>> I could see there being a possible issue with my host VM, but I >>> haven't modified my environment in ref11-amd64.freebsd.org at all. >>> >>> Could you please try reproing it there with your user? >>> >>> Thanks, >>> -NGie >>> >> >> >> --=20 >> Regards, >> Bryan Drewery >> >=20 >=20 --=20 Regards, Bryan Drewery --BdiK8hFnKoaetNS77MaHoeVdAhQhG9Ofl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJWM/jFAAoJEDXXcbtuRpfPudAH/2I4Ob3+N1srMvuiHd3LNx7Z D/sfzv9GzPDDu2L/AJzEVH1nQ6/t4u8LqOL1yraQRK8VQZ2UZaViIJcaHq6cMUCK Py8NwufZRrbZHHGlIVgECDLPNVdAfzqyZk7XakXA7SuydyczKEw2ENLzto+u3ahY Xl1/JwyUgY4hFhA34wXgFKA/v6nA+r+dVHeGmrEFZbYCITRItDoxKrQ/3181L7hm LnSbzA6Jfk21Jl6/yhAH2Epkijoe3JlxnL5XHLgl71InILhSF/PIt5d4QLyD0tgx ZRkz37yEZbdJPlozql23GlrqBqWTu1+cQcw6YTiSzqp5O4dLyR+z6JwyE3BuAD4= =X8kP -----END PGP SIGNATURE----- --BdiK8hFnKoaetNS77MaHoeVdAhQhG9Ofl-- From owner-freebsd-current@freebsd.org Fri Oct 30 23:16:27 2015 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 D0205A21E84 for ; Fri, 30 Oct 2015 23:16:27 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id ADD8E1029 for ; Fri, 30 Oct 2015 23:16:27 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id ADA48A21E83; Fri, 30 Oct 2015 23:16:27 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 935A5A21E82 for ; Fri, 30 Oct 2015 23:16:27 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (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 4CBC51028; Fri, 30 Oct 2015 23:16:27 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by qgad10 with SMTP id d10so74208075qga.3; Fri, 30 Oct 2015 16:16:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lSA9ezpXiuV9H63AnVS5TuHuLVu+mCcLX9Q9WNuijYs=; b=UYUtBXIwH684AXnbJZlL+osYKrxWp8Ch6hizodyT0rMNr9HwanUpHhI0OU2zRe8giT +DPrU//m/DXNSaO9j79WcYPeJXJ0qWPpOHrME4EE8pjNXSwF+j19MSOPF2u75e+ASnm4 1+NXfwxu7/7xQJbj7Z8XPzL1OnNOL0GbT/nfisk7wTLNTVXFdbA7vXLbt3Wx/RC0gQ4b BYdjdvbyEzteBb7hugf8lNjv7vqWoNfa/cH5eH0V2Xpbnuwkz2xdsXZ7EcDQUJn/kLls xkf1tn/MjvWK5IHAWufQA6QdYEUZB7lyBn+t5tLPekMQceq33e7t6Og5w2b07U30+6eD NTTQ== MIME-Version: 1.0 X-Received: by 10.140.195.143 with SMTP id q137mr14424929qha.44.1446246986324; Fri, 30 Oct 2015 16:16:26 -0700 (PDT) Received: by 10.140.88.209 with HTTP; Fri, 30 Oct 2015 16:16:26 -0700 (PDT) In-Reply-To: <5633F8C5.6040500@FreeBSD.org> References: <653F31AA-982B-4026-BEF5-F608BCFFFD3A@gmail.com> <5633DF51.1070305@FreeBSD.org> <5633E27C.6000101@FreeBSD.org> <5633F6C7.4080500@FreeBSD.org> <20151030230817.GA3845@wkstn-mjohnston.west.isilon.com> <5633F8C5.6040500@FreeBSD.org> Date: Fri, 30 Oct 2015 16:16:26 -0700 Message-ID: Subject: Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect From: NGie Cooper To: Bryan Drewery Cc: Mark Johnston , "Simon J. Gerraty" , Ed Maste , FreeBSD CURRENT Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 30 Oct 2015 23:16:28 -0000 On Fri, Oct 30, 2015 at 4:09 PM, Bryan Drewery wrote: ... > The example output must be a mistake as they are correct on ref11: > > ref11-amd64% find > /scratch/tmp/ngie/obj/*/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json > -name tst.usdt.o -exec file {} + > /scratch/tmp/ngie/obj/arm.arm/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: > ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), > not stripped > /scratch/tmp/ngie/obj/arm.armeb/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: > ELF 32-bit MSB relocatable, ARM, EABI5 version 1 (FreeBSD), not > stripped > /scratch/tmp/ngie/obj/arm.armv6/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: > ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not > stripped > /scratch/tmp/ngie/obj/arm.armv6hf/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: > ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not > stripped > /scratch/tmp/ngie/obj/arm64.aarch64/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: > ELF 64-bit LSB relocatable, ARM aarch64, version 1 (FreeBSD), not > stripped > /scratch/tmp/ngie/obj/i386.i386/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: > ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD), > not stripped > /scratch/tmp/ngie/obj/pc98.i386/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: > ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD), > not stripped > /scratch/tmp/ngie/obj/powerpc.powerpc/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: > ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 > (FreeBSD), not stripped > /scratch/tmp/ngie/obj/powerpc.powerpc64/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: > ELF 64-bit MSB relocatable, 64-bit PowerPC or cisco 7500, version 1 > (FreeBSD), not stripped > > [sorry for bad mail client] Weird. Ok, I'll do some more digging into this. Thanks for the input! From owner-freebsd-current@freebsd.org Sat Oct 31 00:17:24 2015 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 35D9CA22A85 for ; Sat, 31 Oct 2015 00:17:24 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C01F81EFC for ; Sat, 31 Oct 2015 00:17:23 +0000 (UTC) (envelope-from sjg@juniper.net) Received: by mailman.ysv.freebsd.org (Postfix) id BE370A22A83; Sat, 31 Oct 2015 00:17:23 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3D5FA22A82 for ; Sat, 31 Oct 2015 00:17:23 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0119.outbound.protection.outlook.com [207.46.100.119]) (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 9557F1EFB; Sat, 31 Oct 2015 00:17:21 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from BY2PR05CA062.namprd05.prod.outlook.com (10.141.250.52) by BN1PR05MB059.namprd05.prod.outlook.com (10.255.202.149) with Microsoft SMTP Server (TLS) id 15.1.312.18; Fri, 30 Oct 2015 23:43:46 +0000 Received: from BL2FFO11FD030.protection.gbl (2a01:111:f400:7c09::109) by BY2PR05CA062.outlook.office365.com (2a01:111:e400:2c5f::52) with Microsoft SMTP Server (TLS) id 15.1.312.18 via Frontend Transport; Fri, 30 Oct 2015 23:43:45 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01b-sac.jnpr.net (66.129.239.18) by BL2FFO11FD030.mail.protection.outlook.com (10.173.161.40) with Microsoft SMTP Server (TLS) id 15.1.318.9 via Frontend Transport; Fri, 30 Oct 2015 23:43:43 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01b-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 30 Oct 2015 16:43:42 -0700 Received: from chaos.jnpr.net (chaos.jnpr.net [172.21.16.28]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t9UNhfD54520; Fri, 30 Oct 2015 16:43:41 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from chaos (localhost [IPv6:::1]) by chaos.jnpr.net (Postfix) with ESMTP id F2432580A9; Fri, 30 Oct 2015 16:43:40 -0700 (PDT) To: NGie Cooper CC: Bryan Drewery , Ed Maste , "Mark Johnston" , FreeBSD CURRENT , Subject: Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect In-Reply-To: <653F31AA-982B-4026-BEF5-F608BCFFFD3A@gmail.com> References: <653F31AA-982B-4026-BEF5-F608BCFFFD3A@gmail.com> Comments: In-reply-to: NGie Cooper message dated "Fri, 30 Oct 2015 13:57:10 -0700." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Oct 2015 16:43:40 -0700 Message-ID: <6585.1446248620@chaos> X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD030; 1:1zv2zdj1US0Fse3TB0BZmW+uxsKkDUvTJaEosWLF4lhoHJX7OXIkCEvcS4L9qh+fAox39XVj1itT7vFqTss5p3Fq75RZb2cZfl1Vv6qDLbCFpN1AaDii9HnixRA8+N4BpfmGDL3rcFIeLQoiNUAfnKxPQH5OIDe+VLs+8JouTq8uBg4XL9tzeHmYi9itVRtm0y/t8SAMpcuP5GXXr25kQeLHTGP0mO9/jDreErPyn/tt7SoJJdF34bdcNX9wHzwJ4N4WCDzGLUP55RXPg7T+ialznscA86I/bVMOHhGrgJmMsE1minFCAFp8ymtgLTr05S767E5FDwQJJw0Z+VpisLPHnjYzuLKC7jYJrqUXz/cqqrR3r0DBHSBi97Hlr7jR X-Forefront-Antispam-Report: CIP:66.129.239.18; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(199003)(189002)(24454002)(19580405001)(15975445007)(81156007)(6806005)(86362001)(1411001)(77096005)(33716001)(92566002)(19580395003)(97736004)(117636001)(76176999)(5001960100002)(105596002)(5007970100001)(50226001)(47776003)(57986006)(23676002)(50466002)(50986999)(76506005)(4001430100002)(2950100001)(5008740100001)(106466001)(69596002)(110136002)(107886002)(87936001)(189998001)(42262002)(62816006); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB059; H:p-emfe01b-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB059; 2:j2MWaaZu1iB2vvnVpTksLw0JwaYoOpfslWE3ceEGrSE/NfOFN/Mxf/wjpcgD1R8mI/1NK+xPU+oC2ViNpSu8rJNWebd6YZ85iis/7Sxw2DjnnWB44TAg/oIxuKYqF5Xdpul8B5DZ68TDQt8GwqtY7HaHBfTaZvkPJ9zwyh9HdKo=; 3:5FLscWjDa+A73mJ7GdDfQ8XuPH3R9hSw2BqK1BFcVSSSvhJdXuqTq0UENrR353OiIZYCWmXKiDdR42uQgeA6BcWGH0NVmg8JYNZdsxoBTMbpSrGTJ47LpGZ8bK472ZbotlwyxCUZRagRAPp4UcvCU32lJO4P77RoGlT17QIwnb4X6zFgJ0uGAzMm6wLmk1VsQhTE51TTFXvOMCFYYWHRBz3IsyUhT/5ib0pjcD/MiLDbYLGlVJN0C3he9NhboT1y+dpYdD5joyxB1SUnDt+HZQ==; 25:GyhZT8feRFU4anhuGiD33o4wDC6HZTY2c6duokmgaOf2KZSeQ7FheWgpLsZDzBueEcXeNTQri3jwY3GIHE+ZOrk4AwUfz83m7HrmgQurZVO33OTg7/3kVG3/ious94BojdGc+zc7GxR1MLuDmCQY1Dod8iA/wXIpJZSH5+Fz2fxRvb5ppovdsolqp7Y24EFsKxiOVOxDUFihOUm+rGo1kIEcM11Buk7jYmFilL3BzJkzS5eO0AKdv34USGN3EWGThPkkVFbh08c4vHQkz2K+0Q== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(42134001)(42139001); SRVR:BN1PR05MB059; X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB059; 20:mjdq5E68DzqPnZELvKuJnFrQTukfNsQIljz49a9w7IXpPsk8Oq0nz1a+ArQMJ6jNNcawvHQAL7Jvg4rxa5ekNh+QhxpZ7qGEoP6al7pBRTQ4FZ2GdDePnOFNidbpQNjDBzruq9bKyToctsClUHodvrdw7SIxwrenVs/6zwEKTU6ifggw/IjmI3eCr5yH585yxApqarlCYNYVC48l/K2/EWEr85MYMwMwXINs70Oh9RutuJujeWfLgT1tvkTDI24yTMwJ0auUaaToXAsHWpkrBaqVH8JyP6r+cqcaSAHLp9aR0xyCNWPKEbx8D7iFqQ7u/83X2q5Y3IhPR6kVax89DdaY4C5KvijDo6u2loIskl87ZtZ+JXyzFGepAnd2t5ON8pQ+70Sxt6w8Mao8WXkMlikfI/UH6l8jaw5A7qI3ufwkAaMV4/X3kcs9gFDBOqbkBqjIA0xhESEI+rDFh9jTAJ59BZboq3Wodqc7HxyWrUzmV4npLqBeq6ObT9HX0aCP; 4:W/7A2FOvbOsqFhGtw9/AMi9I+L50NwzEE/BdKrFW316HNArVycvpdcVMGH/MUBceMTScc69xuhcoWAZKB8K9JrowXDSlMhXLLsguwC2O3fuFxv5G4k431pVS7D2ITBXkyiTJEhdrtlEXYWUMrx3QePB3aLJrrtOk2BcBLBKAZCwFNBlNyfI87GsGftdbN5LvP1+5dTF++xfps/cr+Gcmw0HbAfsW0iZqtcvDWgAXtqh1qrUyGaNfGBm8IuGMSAGmRFunCUTjOp/BlaSFP8yLRoTOo6/g5FNEhMIKgS5mvBao6eDfReCxXn7bETYTHrMycpDx8zjm2siHVNfRzObbYT9DxrpaSdPaBovrtk5UZ3JKlypq6iFN8TcJWu+PU2ZQ X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001)(10201501046); SRVR:BN1PR05MB059; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB059; X-Forefront-PRVS: 07459438AA X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjFQUjA1TUIwNTk7MjM6VklVRUhUem9PYThrR00xQjhRVmNaMlNuQ01S?= =?utf-8?B?V1d4cXZJalFxRGt6OWx0SW5EbVZMOUxTSGFTWURkVkgwOGt5enM1YVhjTmFy?= =?utf-8?B?cDFWQjFDc0tCL0N5a1V3ZkozUWdyV1crWjNWRGJhc2w1Zk9TdGVqZjNBemVy?= =?utf-8?B?QnN1RFVIbXNaMXg3WGd0VFZ3YVFRdjNEU3AySldqYTJXSVJjTWhVVmhOdExN?= =?utf-8?B?cEs1NFpVeUc3Y1BEaXpoRW96dnkxbGpycXdWdFZWSkxNWnQ2ZUI5L1BlZFZR?= =?utf-8?B?Titxc1h3RjJRRE5HWVU1YTh3a0UybXNYSzFXcnJmaEl2d2YrRXVkejNMdjRU?= =?utf-8?B?R21kQjRwc3IwYXRnOTNRM2M4MFMzRDdoWVUwdEpOQll1R25XQ0JQM0NnelI5?= =?utf-8?B?U3lrMmRwUmlhNno3YlNvNlg3MHVpWnhPZUlTMVRHTTh0SnhaYjNuTkNwRlU5?= =?utf-8?B?ZmlVTks3TWpVMERUMzFRT3FGbXNuQVZlejFZYjdRUUl6ZUlFeGF6Vkc3YkdX?= =?utf-8?B?anpiN1NmM2JSZlpGNlIvcGRsSSs4MFcxbTBkVDB2Qnl1WlpycEtqVjhlMlU2?= =?utf-8?B?MXJxZDBneFJ4b0VvclpCNjdWaDdjYlh4M0RZTW0wUWRVdWJnaDVPeDFhemJI?= =?utf-8?B?cEMrVWh2YTMvL0ovdTE4YlhTVng2M05UZzVvYjFERnRrYnc3QTB1d0pCT0F2?= =?utf-8?B?cUlzd2Q4dkpnNFlVbzg2NEE5dzRhN2o4MWszZC9SVVk3OGNwNlg2TkNkZXlG?= =?utf-8?B?aUhwUDRKTFgvbSt3S2lMQUVPclBpbzZZMjdnZGx5anMyMHdLV1ZSSEtmRlVG?= =?utf-8?B?NkJqdHRzUlppNGhiOEJLWUZWM2M4dlV6QnpHNmJVMTRhSVBITTdZem5pblBW?= =?utf-8?B?SUF1aFdoRTQ5Z1pCSE1SdXUyTm1McVhRNVNPVWpjMDY5TkFBN0pvUHlqVDBl?= =?utf-8?B?U283aUQya2l4eGRROGFPN3c0UFM4RTdhcWxjaVVsU2RNQWZ2ZHc2UE9EVHFt?= =?utf-8?B?VUQ1a1FkcktlVjIybW9hRGk1NUZvNjIxSHZYdzBNTnc5bXVYbmJMUnlMcVli?= =?utf-8?B?TDN1TllJVTVwMlVCVlVXMXlWb25LVHNnY2VqdGtxM1lQVFR1MmcwQ3JXeW1w?= =?utf-8?B?MjVlNEM5YlZQd3lqb2tGUUNVSXVDZDNTUkZCNUtyVGhramhRK0x4T1kxdTRn?= =?utf-8?B?ZGFGaEZpelhpWnFoVGFYclFkTHpHeXN5aU9vZkJLV09hTlR3ZkhSTVJTSmNJ?= =?utf-8?B?bnc2TXRlWmtCQS9qRzRJVWRsMGNDY25HbzR2djl5OEdnMXJvYVJ5d0s1aEVx?= =?utf-8?B?NjlBbS94Z2lWU3pnUGJOZEhjcUNjNEY3QmczZlQ2QXRPcytiTStsOU9BMXZu?= =?utf-8?B?N2J6VG5TZVVraG5XT2F5Vkp3YlhBQVdQbnJHTVRSbGJjTW5KQ1hlWmZBcURW?= =?utf-8?Q?T5yzw=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB059; 5:HvKxIc8sgPlPIKtmNiseCat+BgyLFMwS01sUmbqZP7XvL7ZsA/MELFsNFBzIgRCswVFyRkQV5CP3QsYwHYFcXTuUaGi8o3i2kaEEyBf1mSWQmPsXkSvNMAmhUo4N6bbSMavYshbdOjUP3UbNsSraEQ==; 24:vEB/OBak28Zw1V8IBMXD052QV4qEvQRVJsEkVvPNQGVrZIQVDDNNalN5EwStXqZANDvwyd8nVaWS9qW8QRdKrp+fa2IuB8hOZwO33HSl3dY=; 20:nonUjLe3U6Zfp9VaPeX4Lbo2FjNJj+moYxSu7oxUJ4/IjJImXhcshmYzKfKL0g2fn+LahbazqJ0sFvsmmE9/OQ== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Oct 2015 23:43:43.4776 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18]; Helo=[p-emfe01b-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB059 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 31 Oct 2015 00:17:24 -0000 NGie Cooper wrote: > I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS and= I ran into this linker issue below. I have no idea (yet) why it=E2=80=99s = trying to compile an x64 object when I specify powerpc/powerpc =E2=80=94 an= d more importantly, why is the object not being put in obj.powerpc? > I ran into the same issue on ref11-amd64.freebsd.org when I ran =E2=80= =9Cmake tinderbox". Is it possible that the file is left over from a previous build (of amd64?) Does your log show it being built? > dtrace -C -x nolibs -G -o usdt.o -s /usr/src/svn/cddl/contrib/opensolaris= /cmd/dtrace/test/tst/common/json/usdt.d tst.usdt.o > dtrace: failed to link script /usr/src/svn/cddl/contrib/opensolaris/cmd/d= trace/test/tst/common/json/usdt.d: incorrect ELF machine type for object fi= le: tst.usdt.o > *** Error code 1 > $ find /usr/obj/usr/src/svn/ -name tst.usdt.o > /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o > $ file /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.us= dt.o > /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: E= LF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Sat Oct 31 02:32:40 2015 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 3A3A9A218E0; Sat, 31 Oct 2015 02:32:40 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 08F031768; Sat, 31 Oct 2015 02:32:40 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by iodd200 with SMTP id d200so97586413iod.0; Fri, 30 Oct 2015 19:32: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:content-type :content-transfer-encoding; bh=64j2nPHlyoB23z8cu9/YMPam7ru2XcEG/iUmuFmtdyM=; b=jzuY3yVS6DQGcizENJzvCuz9XIH9q3ttDbCQPYpuOQOM0fG2XtnCvNsXlcqoCfj1N5 G3BqAN6t3kuYpUm6uEsS8ocyR/ujQucfCcrH144tWdropMXaNdoNmDN4gPuUxKjwigfX ebNeCOnjqmv+RDzwJDYh4U6ToQl0bdrDiaxo0LfLyOZkvsJPNTjK3sEiiS4cy7zvmHgp nbzU5zu0HagZ/KmoJeCvZWc9AASuKtwrJEE6DuAvOMDJRxVhJVLpmjRxWNBKp9SdG2/y tMi9gQ3KW32VaW2/44vaBP7pjh5avPinxSVikoevLkBEOCWwu+oqEjB8H/jMw4t4kmNK WXKw== MIME-Version: 1.0 X-Received: by 10.107.152.2 with SMTP id a2mr12602048ioe.123.1446258759223; Fri, 30 Oct 2015 19:32:39 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.46.66 with HTTP; Fri, 30 Oct 2015 19:32:39 -0700 (PDT) Date: Fri, 30 Oct 2015 19:32:39 -0700 X-Google-Sender-Auth: IHYo-KhSwGW3ybogicM5IGgMwGY Message-ID: Subject: panic in arptimer in r289937 From: Adrian Chadd To: freebsd-current , FreeBSD Net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 31 Oct 2015 02:32:40 -0000 Hiya, Here's a panic from arptimer: (kgdb) bt #0 doadump (textdump=3D0) at pcpu.h:221 #1 0xffffffff803666b6 in db_fncall (dummy1=3D, dummy2=3D, dummy3=3D, dummy4=3D) at /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:568 #2 0xffffffff8036614e in db_command (cmd_table=3D0x0) at /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:440 #3 0xffffffff80365ee4 in db_command_loop () at /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:493 #4 0xffffffff8036897b in db_trap (type=3D, code=3D0) at /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_main.c:251 #5 0xffffffff8096c0f3 in kdb_trap (type=3D9, code=3D0, tf=3D) at /usr/home/adrian/work/freebsd/head/src/sys/kern/subr_kdb.c:654 #6 0xffffffff80d34c81 in trap_fatal (frame=3D0xfffffe022815d7a0, eva=3D) at /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/trap.c:829 #7 0xffffffff80d34951 in trap (frame=3D) at /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/trap.c:203 #8 0xffffffff80d149f7 in calltrap () at /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/exception.S:234 #9 0xffffffff8092c3fb in _rw_wlock_cookie (c=3D0xdeadc0dedeadc2de, file=3D0xffffffff81211b1f "/usr/home/adrian/work/freebsd/head/src/sys/netinet/if_ether.c", line=3D205) at /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_rwlock.c:261 #10 0xffffffff80a2487f in arptimer (arg=3D0xfffff8005ecc4000) at /usr/home/adrian/work/freebsd/head/src/sys/netinet/if_ether.c:205 #11 0xffffffff80944c24 in softclock_call_cc (c=3D0xfffff8005ecc40a8, cc=3D0xffffffff81b2d480, direct=3D0) at /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_timeout.c:722 #12 0xffffffff80944f87 in softclock (arg=3D) at /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_timeout.c:851 #13 0xffffffff808f7eb6 in intr_event_execute_handlers (p=3D, ie=3D0xfffff800035a6600) at /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_intr.c:1262 #14 0xffffffff808f8546 in ithread_loop (arg=3D0xfffff800032c47c0) at /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_intr.c:1275 #15 0xffffffff808f57a4 in fork_exit (callout=3D0xffffffff808f84a0 , arg=3D0xfffff800032c47c0, frame=3D0xfffffe022815dac0) at /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_fork.c:1011 #16 0xffffffff80d14f2e in fork_trampoline () at /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/exception.S:609 #17 0x0000000000000000 in ?? () Current language: auto; currently minimal (kgdb) print *(struct llentry *)c_arg $2 =3D {lle_next =3D {le_next =3D 0x0, le_prev =3D 0xfffff8005e867dc8}, r_l3addr =3D {addr4 =3D {s_addr =3D 16782508}, addr6 =3D {__u6_addr =3D {__u6_addr8 =3D 0xfffff8005ecc4010 "=EF=BF=BD\024", __u6_addr16 =3D 0xfffff8005ecc4010, __u6_addr32 =3D 0xfffff8005ecc4010}}}, ll_addr =3D {mac_aligned =3D 110869256150596, mac16 =3D 0xfffff8005ecc4020, mac8 =3D 0xfffff8005ecc4020 "D\036=EF=BF=BD=EF=BF=BD=EF=BF=BDd"}, spare0 =3D 0, spare1 =3D 0, lle_tbl = =3D 0xfffff8005e867e00, lle_head =3D 0xfffff8005e867dc8, lle_free =3D 0xffffffff80a2c5d0 , la_hold =3D 0x0, la_numheld =3D 0, la_expire =3D 2110, la_flags =3D 1, la_asked =3D 0, la_preempt =3D 5, ln_state =3D 0, ln_router =3D 0, ln_ntick =3D 0, lle_refcnt =3D 1, lle_chain =3D {le_next =3D 0x0, le_prev =3D 0x0}, lle_timer =3D {c_links =3D {le =3D {le_next =3D 0x0, le_prev =3D 0xffffffff81b2d588}, sle =3D {sle_next =3D 0x0}, tqe =3D {tqe_next =3D 0x0, tqe_prev =3D 0xffffffff81b2d588}}, c_time =3D 9066299815445, c_precision =3D 322122525000, c_arg =3D 0xfffff8005ecc4000, c_func =3D 0xffffffff80a246e0 , c_lock =3D 0x0, c_flags =3D 0, c_iflags =3D 144, c_cpu =3D 0}, lle_lock =3D {lock_obje= ct =3D { lo_name =3D 0xffffffff8120fbce "lle", lo_flags =3D 90374144, lo_data =3D 0, lo_witness =3D 0xfffffe0000b53c80}, rw_lock =3D 1}} .. (kgdb) print *((struct llentry *)c_arg)->lle_tbl $4 =3D {llt_link =3D {sle_next =3D 0xdeadc0dedeadc0de}, llt_af =3D -5590382= 42, llt_hsize =3D -559038242, lle_head =3D 0xdeadc0dedeadc0de, llt_ifp =3D 0xdeadc0dedeadc0de, llt_lookup =3D 0xdeadc0dedeadc0de, llt_alloc_entry =3D 0xdeadc0dedeadc0de, llt_delete_entry =3D 0xdeadc0dedeadc0de, llt_prefix_free =3D 0xdeadc0dedeadc0de, llt_dump_entry =3D 0xdeadc0dedeadc0de, llt_hash =3D 0xdeadc0dedeadc0de, llt_match_prefix =3D 0xdeadc0dedeadc0de, llt_free_entry =3D 0xdeadc0dedeadc0de, llt_foreach_entry =3D 0xdeadc0dedeadc0de, llt_link_entry =3D 0xdeadc0dedeadc0de, llt_unlink_entry =3D 0xdeadc0dedeadc0de, llt_fill_sa_entry =3D 0xdeadc0dedeadc0de, llt_free_tbl =3D 0xdeadc0dedeadc0de} :( Any ideas on where next to look? -adrian From owner-freebsd-current@freebsd.org Sat Oct 31 06:38:07 2015 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 F2D36A21C35; Sat, 31 Oct 2015 06:38: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 DE9441D3F; Sat, 31 Oct 2015 06:38: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 7F76F5BE; Sat, 31 Oct 2015 06:38:07 +0000 (UTC) Date: Sat, 31 Oct 2015 06:38:05 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: imp@FreeBSD.org, jhibbits@FreeBSD.org, bdrewery@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <1576794911.28.1446273487489.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1863767250.22.1446257413806.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1863767250.22.1446257413806.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #1558 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_i386 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.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2015 06:38:07 -0000 FreeBSD_HEAD_i386 - Build #1558 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1558/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1558/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1558/console Change summaries: 290224 by imp: The error classification from lower layers is a poor indicator of whether an error is recoverable. Always re-dirty the buffer on errors from write requests. The invalidation we used to do for errors not EIO doesn't need to be done for a device that's really gone, since that's done in a different path. Reviewed by: mckusick@, kib@ 290223 by imp: Rather than using the #define for path names, indirect through a char * variable that could change for different executable types detected. 290222 by imp: Move all the paths into a new path.h to centralize them. 290221 by jhibbits: Print unsigned memory sizes, to handle >2GB RAM on 32-bit powerpc. Sponsored by: Alex Perez/Intertial Computing 290220 by bdrewery: Don't hide stderr when checking ${CC} --version. This can have important debugging information such as 'cc: not found' or 'ccache: error: Could not find compiler "cc" in PATH'. MFC after: 2 weeks Sponsored by: EMC / Isilon Storage Division From owner-freebsd-current@freebsd.org Sat Oct 31 06:51:03 2015 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 78220A22035 for ; Sat, 31 Oct 2015 06:51:03 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 54F611100 for ; Sat, 31 Oct 2015 06:51:03 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 51185A22034; Sat, 31 Oct 2015 06:51:03 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 509D1A22033 for ; Sat, 31 Oct 2015 06:51:03 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::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 1DA3110FD; Sat, 31 Oct 2015 06:51:03 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by padhy1 with SMTP id hy1so88559761pad.0; Fri, 30 Oct 2015 23:51:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=d7kuQ6TzogmWmkXbOYMi5xLzFg3xUEtHqs7NavpiaLo=; b=0+a5pCCLngequpVChMPxfP49xz02EAZaNeQwpgZCtgMlHEWWZfiPXlF11fJVOJxm5a swK0gkX7o8mf536YRvg6TBIuvV7ZjKYySZHHa4zsPOXRbCrx8Cc6FD77lMKpJNRR0Wdt Xw+bPfALC2+kzkqpnV1ObykfW+C9A6I4cn+piwpTWtVmNCYQWnrq2+ZOnQ4EoXjnSavK INCzube/qndmtkmchZ86LWAOWd1HwoTDHvWLxiU2Si1lelZp7YP8wauZZeEFJOeogQuN +jnmD5zmv8EdeQLKTUJ0Dn0y6iMEkFMFH6VAZdYFpSqXhe5V1dD7oi8sk1pxD4tuxuX6 7A4A== X-Received: by 10.66.185.228 with SMTP id ff4mr10650613pac.79.1446274262734; Fri, 30 Oct 2015 23:51:02 -0700 (PDT) Received: from [192.168.20.7] (c-24-16-212-205.hsd1.wa.comcast.net. [24.16.212.205]) by smtp.gmail.com with ESMTPSA id im9sm11906605pbc.1.2015.10.30.23.51.01 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Oct 2015 23:51:02 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect From: NGie Cooper In-Reply-To: <6585.1446248620@chaos> Date: Fri, 30 Oct 2015 23:51:00 -0700 Cc: Bryan Drewery , Ed Maste , Mark Johnston , FreeBSD CURRENT Content-Transfer-Encoding: quoted-printable Message-Id: <9192D4AA-FCF1-4841-89FD-A4E5D93C6941@gmail.com> References: <653F31AA-982B-4026-BEF5-F608BCFFFD3A@gmail.com> <6585.1446248620@chaos> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 31 Oct 2015 06:51:03 -0000 > On Oct 30, 2015, at 16:43, Simon J. Gerraty wrote: >=20 > NGie Cooper wrote: >> I tried doing buildworld on powerpc/powerpc with = -DWITH_DTRACE_TESTS and I ran into this linker issue below. I have no = idea (yet) why it=E2=80=99s trying to compile an x64 object when I = specify powerpc/powerpc =E2=80=94 and more importantly, why is the = object not being put in obj.powerpc? >> I ran into the same issue on ref11-amd64.freebsd.org when I ran = =E2=80=9Cmake tinderbox". >=20 > Is it possible that the file is left over from a previous build (of = amd64?) >=20 > Does your log show it being built? >=20 >=20 >> dtrace -C -x nolibs -G -o usdt.o -s = /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt= .d tst.usdt.o >> dtrace: failed to link script = /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt= .d: incorrect ELF machine type for object file: tst.usdt.o >> *** Error code 1 >> $ find /usr/obj/usr/src/svn/ -name tst.usdt.o >> = /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o >> $ file = /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o >> = /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: = ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped Still running into issues on ref11-amd64: cc1: error: unrecognized command line option "-m64" dtrace: failed to compile script = /scratch/tmp/ngie/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/= json/usdt.d: Preprocessor failed to process input program --- usdt.h --- *** [usdt.h] Error code 1 Let=E2=80=99s see what happens if I use make buildenv $ env MAKEOBJDIRPREFIX=3D/scratch/tmp/$USER/obj make buildenv = TARGET=3Dmips TARGET_ARCH=3Dmips Entering world for mips:mips $ make -VMAKEOBJDIRPREFIX /scratch/tmp/ngie/obj/mips.mips $ which dtrace /usr/sbin/dtrace Uh=E2=80=A6 yeah=E2=80=A6 running the copy from the build host is no = bueno. So, that root causes that issue. I=E2=80=99ll file a bug for that = (dtrace needs to be built as a bootstrap/cross tool). The -m64 issue is = because it=E2=80=99s compiled for amd64 and is running arguments that = are only supposed to =E2=80=9Cwork=E2=80=9D for x86 platforms (in = reality, there=E2=80=99s also no reason why -m32/-m64 need to be passed = to ${CC}/${CPP}): 1256 #ifdef illumos 1257 #ifdef __x86 1258 /* 1259 * On x86 systems, __i386 is defined for = for 32-bit 1260 * compiles and __amd64 is defined for 64-bit compiles. = Unlike SPARC, 1261 * they are defined exclusive of one another (see PSARC = 2004/619). 1262 */ 1263 if (dtp->dt_conf.dtc_ctfmodel =3D=3D CTF_MODEL_LP64) { 1264 if (dt_cpp_add_arg(dtp, "-D__amd64") =3D=3D NULL) 1265 return (set_open_errno(dtp, errp, = EDT_NOMEM)); 1266 } else { 1267 if (dt_cpp_add_arg(dtp, "-D__i386") =3D=3D NULL) 1268 return (set_open_errno(dtp, errp, = EDT_NOMEM)); 1269 } 1270 #endif 1271 #else 1272 #if defined(__amd64__) || defined(__i386__) 1273 if (dtp->dt_conf.dtc_ctfmodel =3D=3D CTF_MODEL_LP64) { 1274 if (dt_cpp_add_arg(dtp, "-m64") =3D=3D NULL) 1275 return (set_open_errno(dtp, errp, = EDT_NOMEM)); 1276 } else { 1277 if (dt_cpp_add_arg(dtp, "-m32") =3D=3D NULL) 1278 return (set_open_errno(dtp, errp, = EDT_NOMEM)); 1279 } 1280 #endif 1281 #endif As for why the original issue occurred on my VM (which was the = powerpc:powerpc case), I=E2=80=99m not sure yet. I=E2=80=99m working on = figuring that out. Thanks! -NGie= From owner-freebsd-current@freebsd.org Sat Oct 31 10:25:58 2015 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 CCCD2A22B65 for ; Sat, 31 Oct 2015 10:25:58 +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 836481B47; Sat, 31 Oct 2015 10:25:58 +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 esmtp (envelope-from ) id <1ZsTM6-003Nc6-Cq>; Sat, 31 Oct 2015 11:25:50 +0100 Received: from f052129248.adsl.alicedsl.de ([78.52.129.248] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (envelope-from ) id <1ZsTM5-003olf-Tc>; Sat, 31 Oct 2015 11:25:50 +0100 Date: Sat, 31 Oct 2015 11:25:45 +0100 From: "O. Hartmann" To: Jung-uk Kim Cc: FreeBSD-current Subject: Re: [HEADSUP] OpenSSL updated to 1.0.2d Message-ID: <20151031112545.46aa9dca.ohartman@zedat.fu-berlin.de> In-Reply-To: <5633D9C9.2060906@FreeBSD.org> References: <5633D9C9.2060906@FreeBSD.org> Organization: FU Berlin X-Mailer: Claws Mail 3.13.0 (GTK+ 2.24.28; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/qSnteQJxKFnebB_l47i0tNL"; protocol="application/pgp-signature" X-Originating-IP: 78.52.129.248 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 31 Oct 2015 10:25:58 -0000 --Sig_/qSnteQJxKFnebB_l47i0tNL Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Fri, 30 Oct 2015 16:57:45 -0400 Jung-uk Kim schrieb: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > OpenSSL on head has been updated to 1.0.2d. Please make sure to > recompile all binaries depending on libcrypto.so.7 or libssl.so.7. That is good news. Could you provide, please, some hints how one could check all installed por= ts for the usage of those specific libraries? Or could you provide a hint towards an e= xisting port already providing those tools? It would be great for those "from the set of= ordinary people" using FreeBSD. I ask for that because I recall that there were a couple of ports which exp= licitely asks for a selection of what SSL lib should be used and in my case, I use the ba= se system's one. Thank you very much in advance, oh >=20 > Cheers! >=20 > Jung-uk Kim > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 >=20 > iQEcBAEBCAAGBQJWM9nDAAoJEHyflib82/FGuV8H+gKZRDJ/FvPQ/D5wCTBddfgJ > 0i8ptgdzWtSABOSOUeKYBceHhiHUOjlnl2UdMv3JWq6virqCx1YXlJTIHACeZL7D > SSqyuMT3qfZFLwi8fw/dnzgIZx1N86wQlIZOU/3807SN0+h0uCcOq1/Dj/j/wsQx > XpM/tLgnQfqiRSl8pZPUleyOKqqhrFv+pJv7uybAQzTwdQ03pzhd694dy4futsg2 > wxFLUK8BbXWv1ZW37wDysyMyaem02nqCMYUXPoGfjMEwN6DFsx3WVUyKpZxMYQ8x > fNtV3l61tXRczQWzh/rnslSxjbbjMlS4/DKt2x+mzHELUFiOoPqc3/z0CgFUoNk=3D > =3DWa/Z > -----END PGP SIGNATURE----- > _______________________________________________ > 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" --Sig_/qSnteQJxKFnebB_l47i0tNL Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWNJcpAAoJEOgBcD7A/5N8uQcIAOkTn4W2AP+WgPMpgP5dNrv5 9jIiHA1znbaEjMoHDBZlUUOfRigvdcRLSnxCzkr2we1ljkadVDzbFcddu4ks4Fsu Ua05zaqBUd2jfjc5LpG57C+xryWhLUgXriDwVmTLz06hlx9ZIElczyEtAPH7FD0T OlZ8cCRkSYl1eUtPsg+v7E1mD/sk8NHjkuOl8YuSX+oIGw6TglSRKPC2sTZGO1O3 jFJLdL8oVzXBaQFk4bn06nFXyuohKRt2L1fzEUVn3Zy7+STH8drt2beluIBqx8bO h+kMSoO8klw8GDRkRYy/VNl5LHOQz3AUbNE/UA2NsUBu/ccUpmr6I6anw9HedV0= =wu9J -----END PGP SIGNATURE----- --Sig_/qSnteQJxKFnebB_l47i0tNL-- From owner-freebsd-current@freebsd.org Sat Oct 31 13:34:59 2015 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 08F79A21E5D; Sat, 31 Oct 2015 13:34:59 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from forward15h.cmail.yandex.net (forward15h.cmail.yandex.net [IPv6:2a02:6b8:0:f35::a0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8E6B11B9E; Sat, 31 Oct 2015 13:34:58 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from web2h.yandex.ru (web2h.yandex.ru [84.201.186.31]) by forward15h.cmail.yandex.net (Yandex) with ESMTP id 5314220F7B; Sat, 31 Oct 2015 16:34:45 +0300 (MSK) Received: from 127.0.0.1 (localhost [127.0.0.1]) by web2h.yandex.ru (Yandex) with ESMTP id A704346C16D1; Sat, 31 Oct 2015 16:34:44 +0300 (MSK) Received: by web2h.yandex.ru with HTTP; Sat, 31 Oct 2015 16:34:43 +0300 From: Alexander V. Chernikov Envelope-From: melifaro@ipfw.ru To: Adrian Chadd , freebsd-current , FreeBSD Net In-Reply-To: References: null Subject: Re: panic in arptimer in r289937 MIME-Version: 1.0 Message-Id: <2739461446298483@web2h.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Sat, 31 Oct 2015 16:34:43 +0300 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 31 Oct 2015 13:34:59 -0000 31.10.2015, 05:32, "Adrian Chadd" : > Hiya, > > Here's a panic from arptimer: Hi Adrian, As far as I see, line 205 in if_ether.c is IF_AFDATA_LOCK(ifp) which happens after LLE_WUNLOCK(). So, it looks like (pre-cached) ifp had been freed before locking ifdata. Do you have any more details on that? (e.g. was some interface detached at that moment, is it reproducible, etc..) >From a quick glance, potential use-after-free has been possible for quite a long time, but I wonder why it hasn't been observed before. Probably lltable_free() changes might have triggered that. I'll take a deeper look on that and reply. > > (kgdb) bt > #0 doadump (textdump=0) at pcpu.h:221 > #1 0xffffffff803666b6 in db_fncall (dummy1=, > dummy2=, dummy3=, > dummy4=) at > /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:568 > #2 0xffffffff8036614e in db_command (cmd_table=0x0) at > /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:440 > #3 0xffffffff80365ee4 in db_command_loop () at > /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:493 > #4 0xffffffff8036897b in db_trap (type=, code=0) > at /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_main.c:251 > #5 0xffffffff8096c0f3 in kdb_trap (type=9, code=0, tf= optimized out>) at > /usr/home/adrian/work/freebsd/head/src/sys/kern/subr_kdb.c:654 > #6 0xffffffff80d34c81 in trap_fatal (frame=0xfffffe022815d7a0, > eva=) at > /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/trap.c:829 > #7 0xffffffff80d34951 in trap (frame=) at > /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/trap.c:203 > #8 0xffffffff80d149f7 in calltrap () at > /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/exception.S:234 > #9 0xffffffff8092c3fb in _rw_wlock_cookie (c=0xdeadc0dedeadc2de, > file=0xffffffff81211b1f > "/usr/home/adrian/work/freebsd/head/src/sys/netinet/if_ether.c", > line=205) >     at /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_rwlock.c:261 > #10 0xffffffff80a2487f in arptimer (arg=0xfffff8005ecc4000) at > /usr/home/adrian/work/freebsd/head/src/sys/netinet/if_ether.c:205 > #11 0xffffffff80944c24 in softclock_call_cc (c=0xfffff8005ecc40a8, > cc=0xffffffff81b2d480, direct=0) at > /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_timeout.c:722 > #12 0xffffffff80944f87 in softclock (arg=) at > /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_timeout.c:851 > #13 0xffffffff808f7eb6 in intr_event_execute_handlers (p= optimized out>, ie=0xfffff800035a6600) at > /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_intr.c:1262 > #14 0xffffffff808f8546 in ithread_loop (arg=0xfffff800032c47c0) at > /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_intr.c:1275 > #15 0xffffffff808f57a4 in fork_exit (callout=0xffffffff808f84a0 > , arg=0xfffff800032c47c0, frame=0xfffffe022815dac0) at > /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_fork.c:1011 > #16 0xffffffff80d14f2e in fork_trampoline () at > /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/exception.S:609 > #17 0x0000000000000000 in ?? () > Current language: auto; currently minimal > > (kgdb) print *(struct llentry *)c_arg > $2 = {lle_next = {le_next = 0x0, le_prev = 0xfffff8005e867dc8}, > r_l3addr = {addr4 = {s_addr = 16782508}, addr6 = {__u6_addr = > {__u6_addr8 = 0xfffff8005ecc4010 "�\024", __u6_addr16 = > 0xfffff8005ecc4010, >         __u6_addr32 = 0xfffff8005ecc4010}}}, ll_addr = {mac_aligned = > 110869256150596, mac16 = 0xfffff8005ecc4020, mac8 = 0xfffff8005ecc4020 > "D\036���d"}, spare0 = 0, spare1 = 0, lle_tbl = 0xfffff8005e867e00, >   lle_head = 0xfffff8005e867dc8, lle_free = 0xffffffff80a2c5d0 > , la_hold = 0x0, la_numheld = 0, la_expire = > 2110, la_flags = 1, la_asked = 0, la_preempt = 5, ln_state = 0, > ln_router = 0, ln_ntick = 0, >   lle_refcnt = 1, lle_chain = {le_next = 0x0, le_prev = 0x0}, > lle_timer = {c_links = {le = {le_next = 0x0, le_prev = > 0xffffffff81b2d588}, sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0, > tqe_prev = 0xffffffff81b2d588}}, >     c_time = 9066299815445, c_precision = 322122525000, c_arg = > 0xfffff8005ecc4000, c_func = 0xffffffff80a246e0 , c_lock = > 0x0, c_flags = 0, c_iflags = 144, c_cpu = 0}, lle_lock = {lock_object > = { >       lo_name = 0xffffffff8120fbce "lle", lo_flags = 90374144, lo_data > = 0, lo_witness = 0xfffffe0000b53c80}, rw_lock = 1}} > > .. > > (kgdb) print *((struct llentry *)c_arg)->lle_tbl > $4 = {llt_link = {sle_next = 0xdeadc0dedeadc0de}, llt_af = -559038242, > llt_hsize = -559038242, lle_head = 0xdeadc0dedeadc0de, llt_ifp = > 0xdeadc0dedeadc0de, llt_lookup = 0xdeadc0dedeadc0de, >   llt_alloc_entry = 0xdeadc0dedeadc0de, llt_delete_entry = > 0xdeadc0dedeadc0de, llt_prefix_free = 0xdeadc0dedeadc0de, > llt_dump_entry = 0xdeadc0dedeadc0de, llt_hash = 0xdeadc0dedeadc0de, > llt_match_prefix = 0xdeadc0dedeadc0de, >   llt_free_entry = 0xdeadc0dedeadc0de, llt_foreach_entry = > 0xdeadc0dedeadc0de, llt_link_entry = 0xdeadc0dedeadc0de, > llt_unlink_entry = 0xdeadc0dedeadc0de, llt_fill_sa_entry = > 0xdeadc0dedeadc0de, >   llt_free_tbl = 0xdeadc0dedeadc0de} > > :( > > Any ideas on where next to look? > > -adrian > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Sat Oct 31 13:46:04 2015 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 DD84CA220E2; Sat, 31 Oct 2015 13:46:04 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 A7EF71FB4; Sat, 31 Oct 2015 13:46:04 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by iodd200 with SMTP id d200so105638506iod.0; Sat, 31 Oct 2015 06:46:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=MW2WjyAiM66g+7je4Xog+4jjzEc974CcfmJeSeeF7DU=; b=qEznoCISUWZbxQC2kbIfzk2dgRk01JVND+MIplTcf13LxOpbytaEEiW5cJOXgDqqLa 9WEbYpIN7AI2Fuvs9QVKfYD6dA1/+rnPAXUOASF1fC0QIbvMbVrrA9svohGKmqhpouyP BChKAQ/oidWw51PoK9MmfRpWLoKSf9rO7uWijcBJO+qtpVnpnF6z7gbaJ47FqkSwYu6J e7qfZFHad8YWficYk5AvYhHTt0hCv7xzZgDhyWARJ57Im17nsPcC9LIHAEGWFfHTvlWs c4JjYM/G70RKvQpGMi31tUV0JC5AI9KuEw5aoVLvbz0D2/3QYRPMfItJ2v9MOPufd1wV hK7Q== MIME-Version: 1.0 X-Received: by 10.107.152.2 with SMTP id a2mr14329731ioe.123.1446299163802; Sat, 31 Oct 2015 06:46:03 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.46.66 with HTTP; Sat, 31 Oct 2015 06:46:03 -0700 (PDT) In-Reply-To: <2739461446298483@web2h.yandex.ru> References: <2739461446298483@web2h.yandex.ru> Date: Sat, 31 Oct 2015 09:46:03 -0400 X-Google-Sender-Auth: thS5hslgLf2fJ2EQntXQd3THCDc Message-ID: Subject: Re: panic in arptimer in r289937 From: Adrian Chadd To: "Alexander V. Chernikov" Cc: freebsd-current , FreeBSD Net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 31 Oct 2015 13:46:05 -0000 On 31 October 2015 at 09:34, Alexander V. Chernikov wrote: > > > 31.10.2015, 05:32, "Adrian Chadd" : >> Hiya, >> >> Here's a panic from arptimer: > Hi Adrian, > > As far as I see, line 205 in if_ether.c is IF_AFDATA_LOCK(ifp) which happ= ens after LLE_WUNLOCK(). > So, it looks like (pre-cached) ifp had been freed before locking ifdata. > Do you have any more details on that? (e.g. was some interface detached a= t that moment, is it reproducible, etc..) > > From a quick glance, potential use-after-free has been possible for quite= a long time, but I wonder why it hasn't been observed before. > Probably lltable_free() changes might have triggered that. > > I'll take a deeper look on that and reply. Hiya! Thanks for your quick response. I mean, I use wifi, and ARPs can get lost / transmit can get delayed / etc. I'm also testing through a MIPS CPU based bridge, so I'm also not bridging at line rate. (The above is from one of the x86 laptops doing the traffic test.) These are both reasons why I may be poking at a path that you don't normally see. :) I appreciate you taking a very quick look at this! Thanks, -adrian > >> >> (kgdb) bt >> #0 doadump (textdump=3D0) at pcpu.h:221 >> #1 0xffffffff803666b6 in db_fncall (dummy1=3D, >> dummy2=3D, dummy3=3D, >> dummy4=3D) at >> /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:568 >> #2 0xffffffff8036614e in db_command (cmd_table=3D0x0) at >> /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:440 >> #3 0xffffffff80365ee4 in db_command_loop () at >> /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:493 >> #4 0xffffffff8036897b in db_trap (type=3D, code=3D0= ) >> at /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_main.c:251 >> #5 0xffffffff8096c0f3 in kdb_trap (type=3D9, code=3D0, tf=3D> optimized out>) at >> /usr/home/adrian/work/freebsd/head/src/sys/kern/subr_kdb.c:654 >> #6 0xffffffff80d34c81 in trap_fatal (frame=3D0xfffffe022815d7a0, >> eva=3D) at >> /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/trap.c:829 >> #7 0xffffffff80d34951 in trap (frame=3D) at >> /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/trap.c:203 >> #8 0xffffffff80d149f7 in calltrap () at >> /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/exception.S:234 >> #9 0xffffffff8092c3fb in _rw_wlock_cookie (c=3D0xdeadc0dedeadc2de, >> file=3D0xffffffff81211b1f >> "/usr/home/adrian/work/freebsd/head/src/sys/netinet/if_ether.c", >> line=3D205) >> at /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_rwlock.c:261 >> #10 0xffffffff80a2487f in arptimer (arg=3D0xfffff8005ecc4000) at >> /usr/home/adrian/work/freebsd/head/src/sys/netinet/if_ether.c:205 >> #11 0xffffffff80944c24 in softclock_call_cc (c=3D0xfffff8005ecc40a8, >> cc=3D0xffffffff81b2d480, direct=3D0) at >> /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_timeout.c:722 >> #12 0xffffffff80944f87 in softclock (arg=3D) at >> /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_timeout.c:851 >> #13 0xffffffff808f7eb6 in intr_event_execute_handlers (p=3D> optimized out>, ie=3D0xfffff800035a6600) at >> /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_intr.c:1262 >> #14 0xffffffff808f8546 in ithread_loop (arg=3D0xfffff800032c47c0) at >> /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_intr.c:1275 >> #15 0xffffffff808f57a4 in fork_exit (callout=3D0xffffffff808f84a0 >> , arg=3D0xfffff800032c47c0, frame=3D0xfffffe022815dac0) at >> /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_fork.c:1011 >> #16 0xffffffff80d14f2e in fork_trampoline () at >> /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/exception.S:609 >> #17 0x0000000000000000 in ?? () >> Current language: auto; currently minimal >> >> (kgdb) print *(struct llentry *)c_arg >> $2 =3D {lle_next =3D {le_next =3D 0x0, le_prev =3D 0xfffff8005e867dc8}, >> r_l3addr =3D {addr4 =3D {s_addr =3D 16782508}, addr6 =3D {__u6_addr =3D >> {__u6_addr8 =3D 0xfffff8005ecc4010 "=EF=BF=BD\024", __u6_addr16 =3D >> 0xfffff8005ecc4010, >> __u6_addr32 =3D 0xfffff8005ecc4010}}}, ll_addr =3D {mac_aligned = =3D >> 110869256150596, mac16 =3D 0xfffff8005ecc4020, mac8 =3D 0xfffff8005ecc40= 20 >> "D\036=EF=BF=BD=EF=BF=BD=EF=BF=BDd"}, spare0 =3D 0, spare1 =3D 0, lle_tb= l =3D 0xfffff8005e867e00, >> lle_head =3D 0xfffff8005e867dc8, lle_free =3D 0xffffffff80a2c5d0 >> , la_hold =3D 0x0, la_numheld =3D 0, la_expire = =3D >> 2110, la_flags =3D 1, la_asked =3D 0, la_preempt =3D 5, ln_state =3D 0, >> ln_router =3D 0, ln_ntick =3D 0, >> lle_refcnt =3D 1, lle_chain =3D {le_next =3D 0x0, le_prev =3D 0x0}, >> lle_timer =3D {c_links =3D {le =3D {le_next =3D 0x0, le_prev =3D >> 0xffffffff81b2d588}, sle =3D {sle_next =3D 0x0}, tqe =3D {tqe_next =3D 0= x0, >> tqe_prev =3D 0xffffffff81b2d588}}, >> c_time =3D 9066299815445, c_precision =3D 322122525000, c_arg =3D >> 0xfffff8005ecc4000, c_func =3D 0xffffffff80a246e0 , c_lock =3D >> 0x0, c_flags =3D 0, c_iflags =3D 144, c_cpu =3D 0}, lle_lock =3D {lock_o= bject >> =3D { >> lo_name =3D 0xffffffff8120fbce "lle", lo_flags =3D 90374144, lo_da= ta >> =3D 0, lo_witness =3D 0xfffffe0000b53c80}, rw_lock =3D 1}} >> >> .. >> >> (kgdb) print *((struct llentry *)c_arg)->lle_tbl >> $4 =3D {llt_link =3D {sle_next =3D 0xdeadc0dedeadc0de}, llt_af =3D -5590= 38242, >> llt_hsize =3D -559038242, lle_head =3D 0xdeadc0dedeadc0de, llt_ifp =3D >> 0xdeadc0dedeadc0de, llt_lookup =3D 0xdeadc0dedeadc0de, >> llt_alloc_entry =3D 0xdeadc0dedeadc0de, llt_delete_entry =3D >> 0xdeadc0dedeadc0de, llt_prefix_free =3D 0xdeadc0dedeadc0de, >> llt_dump_entry =3D 0xdeadc0dedeadc0de, llt_hash =3D 0xdeadc0dedeadc0de, >> llt_match_prefix =3D 0xdeadc0dedeadc0de, >> llt_free_entry =3D 0xdeadc0dedeadc0de, llt_foreach_entry =3D >> 0xdeadc0dedeadc0de, llt_link_entry =3D 0xdeadc0dedeadc0de, >> llt_unlink_entry =3D 0xdeadc0dedeadc0de, llt_fill_sa_entry =3D >> 0xdeadc0dedeadc0de, >> llt_free_tbl =3D 0xdeadc0dedeadc0de} >> >> :( >> >> Any ideas on where next to look? >> >> -adrian >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Sat Oct 31 14:23:18 2015 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 40B23A22823 for ; Sat, 31 Oct 2015 14:23:18 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) by mx1.freebsd.org (Postfix) with ESMTP id 200E61CFB; Sat, 31 Oct 2015 14:23:17 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from coconut.local (unknown [76.164.15.242]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 6729C56486; Sat, 31 Oct 2015 09:23:10 -0500 (CDT) Subject: Re: [HEADSUP] OpenSSL updated to 1.0.2d To: "O. Hartmann" , Jung-uk Kim References: <5633D9C9.2060906@FreeBSD.org> <20151031112545.46aa9dca.ohartman@zedat.fu-berlin.de> Cc: FreeBSD-current From: Eric van Gyzen Message-ID: <5634CECA.6080405@vangyzen.net> Date: Sat, 31 Oct 2015 09:23:06 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151031112545.46aa9dca.ohartman@zedat.fu-berlin.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 31 Oct 2015 14:23:18 -0000 On 10/31/15 5:25 AM, O. Hartmann wrote: > Am Fri, 30 Oct 2015 16:57:45 -0400 > Jung-uk Kim schrieb: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> OpenSSL on head has been updated to 1.0.2d. Please make sure to >> recompile all binaries depending on libcrypto.so.7 or libssl.so.7. > > That is good news. > > Could you provide, please, some hints how one could check all installed ports for the > usage of those specific libraries? Or could you provide a hint towards an existing port > already providing those tools? It would be great for those "from the set of ordinary > people" using FreeBSD. > > I ask for that because I recall that there were a couple of ports which explicitely asks > for a selection of what SSL lib should be used and in my case, I use the base system's > one. I expect there's a port, but I'm not aware of one. This should work: find /usr/local/*bin /usr/local/lib* -type f | \ while read F; do \ objdump -x $F 2>&1 | grep -Eq 'NEEDED *lib(crypto|ssl).so.7' && \ echo $F; \ done This is in /bin/sh (or bash). You could change "echo" to "pkg which" to show the package names. Cheers, Eric From owner-freebsd-current@freebsd.org Sat Oct 31 15:01:22 2015 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 A947BA22DD9; Sat, 31 Oct 2015 15:01:22 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from forward11h.cmail.yandex.net (forward11h.cmail.yandex.net [87.250.230.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 42BF81BAA; Sat, 31 Oct 2015 15:01:21 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from web19h.yandex.ru (web19h.yandex.ru [84.201.186.48]) by forward11h.cmail.yandex.net (Yandex) with ESMTP id 4BD5C20F8A; Sat, 31 Oct 2015 18:01:17 +0300 (MSK) Received: from 127.0.0.1 (localhost [127.0.0.1]) by web19h.yandex.ru (Yandex) with ESMTP id 9E9B12E011BF; Sat, 31 Oct 2015 18:01:16 +0300 (MSK) Received: by web19h.yandex.ru with HTTP; Sat, 31 Oct 2015 18:01:15 +0300 From: Alexander V. Chernikov Envelope-From: melifaro@ipfw.ru To: Adrian Chadd Cc: freebsd-current , FreeBSD Net In-Reply-To: References: <2739461446298483@web2h.yandex.ru> Subject: Re: panic in arptimer in r289937 MIME-Version: 1.0 Message-Id: <1733241446303675@web19h.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Sat, 31 Oct 2015 18:01:15 +0300 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 31 Oct 2015 15:01:22 -0000 31.10.2015, 16:46, "Adrian Chadd" : > On 31 October 2015 at 09:34, Alexander V. Chernikov > wrote: >>  31.10.2015, 05:32, "Adrian Chadd" : >>>  Hiya, >>> >>>  Here's a panic from arptimer: >>  Hi Adrian, >> >>  As far as I see, line 205 in if_ether.c is IF_AFDATA_LOCK(ifp) which happens after LLE_WUNLOCK(). >>  So, it looks like (pre-cached) ifp had been freed before locking ifdata. >>  Do you have any more details on that? (e.g. was some interface detached at that moment, is it reproducible, etc..) >> >>  From a quick glance, potential use-after-free has been possible for quite a long time, but I wonder why it hasn't been observed before. >>  Probably lltable_free() changes might have triggered that. >> >>  I'll take a deeper look on that and reply. > > Hiya! > > Thanks for your quick response. > > I mean, I use wifi, and ARPs can get lost / transmit can get delayed / > etc. I'm also testing through a MIPS CPU based bridge, so I'm also not I remember that :) > bridging at line rate. (The above is from one of the x86 laptops doing > the traffic test.) These are both reasons why I may be poking at a > path that you don't normally see. :) Yup. So, once again, could you provide a bit more details? :) Was it related with any interface being destroyed? What was the test scenario (just bridging between interfaces?) Is this reproducible? > > I appreciate you taking a very quick look at this! > > Thanks, > > -adrian > >>>  (kgdb) bt >>>  #0 doadump (textdump=0) at pcpu.h:221 >>>  #1 0xffffffff803666b6 in db_fncall (dummy1=, >>>  dummy2=, dummy3=, >>>  dummy4=) at >>>  /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:568 >>>  #2 0xffffffff8036614e in db_command (cmd_table=0x0) at >>>  /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:440 >>>  #3 0xffffffff80365ee4 in db_command_loop () at >>>  /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:493 >>>  #4 0xffffffff8036897b in db_trap (type=, code=0) >>>  at /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_main.c:251 >>>  #5 0xffffffff8096c0f3 in kdb_trap (type=9, code=0, tf=>>  optimized out>) at >>>  /usr/home/adrian/work/freebsd/head/src/sys/kern/subr_kdb.c:654 >>>  #6 0xffffffff80d34c81 in trap_fatal (frame=0xfffffe022815d7a0, >>>  eva=) at >>>  /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/trap.c:829 >>>  #7 0xffffffff80d34951 in trap (frame=) at >>>  /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/trap.c:203 >>>  #8 0xffffffff80d149f7 in calltrap () at >>>  /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/exception.S:234 >>>  #9 0xffffffff8092c3fb in _rw_wlock_cookie (c=0xdeadc0dedeadc2de, >>>  file=0xffffffff81211b1f >>>  "/usr/home/adrian/work/freebsd/head/src/sys/netinet/if_ether.c", >>>  line=205) >>>      at /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_rwlock.c:261 >>>  #10 0xffffffff80a2487f in arptimer (arg=0xfffff8005ecc4000) at >>>  /usr/home/adrian/work/freebsd/head/src/sys/netinet/if_ether.c:205 >>>  #11 0xffffffff80944c24 in softclock_call_cc (c=0xfffff8005ecc40a8, >>>  cc=0xffffffff81b2d480, direct=0) at >>>  /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_timeout.c:722 >>>  #12 0xffffffff80944f87 in softclock (arg=) at >>>  /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_timeout.c:851 >>>  #13 0xffffffff808f7eb6 in intr_event_execute_handlers (p=>>  optimized out>, ie=0xfffff800035a6600) at >>>  /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_intr.c:1262 >>>  #14 0xffffffff808f8546 in ithread_loop (arg=0xfffff800032c47c0) at >>>  /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_intr.c:1275 >>>  #15 0xffffffff808f57a4 in fork_exit (callout=0xffffffff808f84a0 >>>  , arg=0xfffff800032c47c0, frame=0xfffffe022815dac0) at >>>  /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_fork.c:1011 >>>  #16 0xffffffff80d14f2e in fork_trampoline () at >>>  /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/exception.S:609 >>>  #17 0x0000000000000000 in ?? () >>>  Current language: auto; currently minimal >>> >>>  (kgdb) print *(struct llentry *)c_arg >>>  $2 = {lle_next = {le_next = 0x0, le_prev = 0xfffff8005e867dc8}, >>>  r_l3addr = {addr4 = {s_addr = 16782508}, addr6 = {__u6_addr = >>>  {__u6_addr8 = 0xfffff8005ecc4010 "�\024", __u6_addr16 = >>>  0xfffff8005ecc4010, >>>          __u6_addr32 = 0xfffff8005ecc4010}}}, ll_addr = {mac_aligned = >>>  110869256150596, mac16 = 0xfffff8005ecc4020, mac8 = 0xfffff8005ecc4020 >>>  "D\036���d"}, spare0 = 0, spare1 = 0, lle_tbl = 0xfffff8005e867e00, >>>    lle_head = 0xfffff8005e867dc8, lle_free = 0xffffffff80a2c5d0 >>>  , la_hold = 0x0, la_numheld = 0, la_expire = >>>  2110, la_flags = 1, la_asked = 0, la_preempt = 5, ln_state = 0, >>>  ln_router = 0, ln_ntick = 0, >>>    lle_refcnt = 1, lle_chain = {le_next = 0x0, le_prev = 0x0}, >>>  lle_timer = {c_links = {le = {le_next = 0x0, le_prev = >>>  0xffffffff81b2d588}, sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0, >>>  tqe_prev = 0xffffffff81b2d588}}, >>>      c_time = 9066299815445, c_precision = 322122525000, c_arg = >>>  0xfffff8005ecc4000, c_func = 0xffffffff80a246e0 , c_lock = >>>  0x0, c_flags = 0, c_iflags = 144, c_cpu = 0}, lle_lock = {lock_object >>>  = { >>>        lo_name = 0xffffffff8120fbce "lle", lo_flags = 90374144, lo_data >>>  = 0, lo_witness = 0xfffffe0000b53c80}, rw_lock = 1}} >>> >>>  .. >>> >>>  (kgdb) print *((struct llentry *)c_arg)->lle_tbl >>>  $4 = {llt_link = {sle_next = 0xdeadc0dedeadc0de}, llt_af = -559038242, >>>  llt_hsize = -559038242, lle_head = 0xdeadc0dedeadc0de, llt_ifp = >>>  0xdeadc0dedeadc0de, llt_lookup = 0xdeadc0dedeadc0de, >>>    llt_alloc_entry = 0xdeadc0dedeadc0de, llt_delete_entry = >>>  0xdeadc0dedeadc0de, llt_prefix_free = 0xdeadc0dedeadc0de, >>>  llt_dump_entry = 0xdeadc0dedeadc0de, llt_hash = 0xdeadc0dedeadc0de, >>>  llt_match_prefix = 0xdeadc0dedeadc0de, >>>    llt_free_entry = 0xdeadc0dedeadc0de, llt_foreach_entry = >>>  0xdeadc0dedeadc0de, llt_link_entry = 0xdeadc0dedeadc0de, >>>  llt_unlink_entry = 0xdeadc0dedeadc0de, llt_fill_sa_entry = >>>  0xdeadc0dedeadc0de, >>>    llt_free_tbl = 0xdeadc0dedeadc0de} >>> >>>  :( >>> >>>  Any ideas on where next to look? >>> >>>  -adrian >>>  _______________________________________________ >>>  freebsd-net@freebsd.org mailing list >>>  https://lists.freebsd.org/mailman/listinfo/freebsd-net >>>  To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Sat Oct 31 18:50:17 2015 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 D5AFEA1B92B for ; Sat, 31 Oct 2015 18:50:17 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (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 8EF541102 for ; Sat, 31 Oct 2015 18:50:17 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by qgad10 with SMTP id d10so87041544qga.3 for ; Sat, 31 Oct 2015 11:50:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd_org.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=pDngZpHwYH4jY+ioRmfo6D7NPK8Hz7/UzBVsIQubwkE=; b=JMLAnhgYypLpV/Z95HcylfCvJDTeJ6ZtsnrQVSfO0bcKlmueCpxDQDlAiV+hHto9Wi H2jC4qVYheKWafM01jzElfAzwJY71piBiy466ng9LjC0kpQ6g7Q7PWeh0Mc5FtdDYsv9 p/bcOsjTMLq53kzOv0FdC7349iEppdKJ4ibrkLQzaV0LTmtA8uofCPVFR1auAE0j3zU9 pztkYeG1cDDgw+6bEP3RhGbHntxsfqaqPB8mWI6Pa3/ndDXMK2eKAM5hNIRqUPzDcvyd SsCQaRfseNNCxJjdWirRCIBNMzg/hFS34EVAktqdUjI+z3BOGzkKI6+KZHhel7t3FSg6 o8Hw== 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 :content-type; bh=pDngZpHwYH4jY+ioRmfo6D7NPK8Hz7/UzBVsIQubwkE=; b=mb1tVB2AxLitPTjR/y9QF4y21X69VRzrBP1f81RSkUH+mHdY+XuamK+NfbHd+jNIcL n2CsBREY/5wnwNKjdUcEe5PGwXze0bqGKfTbyTTnoBau/sKQJhGy0FPZNEn/sX38/Dgt 5lUrQqwowhR2FOKfrywAISshh3pkzWt1JJA/mz/1GSCK766T/dLTDxLTew2xmlcvaGff bIrDLMMhgmEW9gr67rcNyeNHP8VIdNJMeqLXoBW6rgB4shBwUEEQ1QPyAWVV00P5OPGs cxp5Pv1GCeEwzFEDbltP5Ss7qJYw7aWOSW7mslDUSeVJSbBLAxcb1ozFHwITmY/Gvf1D nXVQ== X-Gm-Message-State: ALoCoQklp1thyJWf/fe3YYe6Jq7peQLWjnwQGuYdAAdYvngy/XDTbXGCBjSqEbFfSjfPq8VrEImo MIME-Version: 1.0 X-Received: by 10.140.104.243 with SMTP id a106mr18274651qgf.19.1446317416350; Sat, 31 Oct 2015 11:50:16 -0700 (PDT) Received: by 10.140.29.201 with HTTP; Sat, 31 Oct 2015 11:50:16 -0700 (PDT) Date: Sat, 31 Oct 2015 14:50:16 -0400 Message-ID: Subject: pf NAT and VNET Jails From: Shawn Webb To: "freebsd-current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 31 Oct 2015 18:50:18 -0000 I'm at r290228 on amd64. I'm not sure which revision I was on last when it last worked, but it seems VNET jails aren't working anymore. I've got a bridge, bridge1, with an IP of 192.168.7.1. The VNET jails set their default route to 192.168.7.1. The host simply NATs outbound from 192.168.7.0/24 to the rest of the world. The various epairs get added to bridge1 and assigned to each jail. Pretty simple setup. That worked until today. When I do tcpdump on my public-facing NIC, I see that NAT isn't applied. When I run `ping 8.8.8.8` from the jail, the jail's 192.168.7.0/24 address gets sent on the wire. Let me know what I can do to help debug this further. Thanks, Shawn Webb From owner-freebsd-current@freebsd.org Sat Oct 31 21:37:13 2015 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 7278FA2282D for ; Sat, 31 Oct 2015 21:37:13 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 4EE801C5E for ; Sat, 31 Oct 2015 21:37:13 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 4E065A2282C; Sat, 31 Oct 2015 21:37:13 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4DA18A2282B for ; Sat, 31 Oct 2015 21:37:13 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::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 1CE741C5D; Sat, 31 Oct 2015 21:37:13 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by pacfv9 with SMTP id fv9so111906157pac.3; Sat, 31 Oct 2015 14:37:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/WihuWzD3QIR6vJw15Fb5+1KMG5spqYyWzwp5jg57RE=; b=AGVFDhS/yOg0QTm5WSMovfPZnm3rwaRieKL4vo56NO9FlIPQ1G5pupaDhWyDyLt10D V+3v9JpAOxsOBsvCAxQUfIYSsR3usyvvBD1yqGvhzsncsNtKnvtZTxqOouzPvGausGv5 DuXByhyvj2dVJOnxyaYgybzymsZNpM3cX9Vj+NcXmC7BOflwar92eIeHbxFD4YKfxgBW 6Mwdq7q5u4HdPXwsF7CusLrJQloaooq3QFKiHjZJU87VEjviKasl6WBuQH40ftYRD+vo RRlTvNUcgAWRekwANzzqIyF9unFFDrIRFDBbuDkHM4isF1IHJ4WF+E6tClD/vjp97fXm xjwg== X-Received: by 10.68.201.200 with SMTP id kc8mr16882638pbc.18.1446327432749; Sat, 31 Oct 2015 14:37:12 -0700 (PDT) Received: from [192.168.20.7] (c-24-16-212-205.hsd1.wa.comcast.net. [24.16.212.205]) by smtp.gmail.com with ESMTPSA id k10sm15479998pbq.78.2015.10.31.14.37.11 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 31 Oct 2015 14:37:12 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect From: NGie Cooper In-Reply-To: <9192D4AA-FCF1-4841-89FD-A4E5D93C6941@gmail.com> Date: Sat, 31 Oct 2015 14:37:10 -0700 Cc: Bryan Drewery , Ed Maste , Mark Johnston , FreeBSD CURRENT Content-Transfer-Encoding: quoted-printable Message-Id: <3957F6B6-275D-4A63-8406-A5AAECF3F131@gmail.com> References: <653F31AA-982B-4026-BEF5-F608BCFFFD3A@gmail.com> <6585.1446248620@chaos> <9192D4AA-FCF1-4841-89FD-A4E5D93C6941@gmail.com> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 31 Oct 2015 21:37:13 -0000 > On Oct 30, 2015, at 23:51, NGie Cooper wrote: >=20 >=20 >> On Oct 30, 2015, at 16:43, Simon J. Gerraty wrote: >>=20 >> NGie Cooper wrote: >>> I tried doing buildworld on powerpc/powerpc with = -DWITH_DTRACE_TESTS and I ran into this linker issue below. I have no = idea (yet) why it=E2=80=99s trying to compile an x64 object when I = specify powerpc/powerpc =E2=80=94 and more importantly, why is the = object not being put in obj.powerpc? >>> I ran into the same issue on ref11-amd64.freebsd.org when I ran = =E2=80=9Cmake tinderbox". >>=20 >> Is it possible that the file is left over from a previous build (of = amd64?) >>=20 >> Does your log show it being built? >>=20 >>=20 >>> dtrace -C -x nolibs -G -o usdt.o -s = /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt= .d tst.usdt.o >>> dtrace: failed to link script = /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt= .d: incorrect ELF machine type for object file: tst.usdt.o >>> *** Error code 1 >>> $ find /usr/obj/usr/src/svn/ -name tst.usdt.o >>> = /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o >>> $ file = /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o >>> = /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: = ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped >=20 > Still running into issues on ref11-amd64: >=20 > cc1: error: unrecognized command line option "-m64" > dtrace: failed to compile script = /scratch/tmp/ngie/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/= json/usdt.d: Preprocessor failed to process input program > --- usdt.h --- > *** [usdt.h] Error code 1 >=20 > Let=E2=80=99s see what happens if I use make buildenv =E2=80=A6 Deleting the lines that pass -m32/-m64 gets me back to the same point I = was at before: dtrace: failed to link script = /scratch/tmp/ngie/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/= json/usdt.d: incorrect ELF machine type for object file: tst.usdt.o --- usdt.o --- *** [usdt.o] Error code 1 I=E2=80=99ll need to check .PATH, but I think it=E2=80=99s picking up = the host copy by accident: $ find ../obj/ -name tst.usdt.o | xargs file = ../obj/arm.armv6hf/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/= json/tst.usdt.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 = (FreeBSD), not stripped = ../obj/arm.arm/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json= /tst.usdt.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 = (FreeBSD), not stripped = ../obj/arm.armeb/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/js= on/tst.usdt.o: ELF 32-bit MSB relocatable, ARM, EABI5 version 1 = (FreeBSD), not stripped = ../obj/powerpc.powerpc/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/com= mon/json/tst.usdt.o: ELF 32-bit MSB relocatable, PowerPC or cisco = 4500, version 1 (FreeBSD), not stripped = ../obj/arm.armv6/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/js= on/tst.usdt.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 = (FreeBSD), not stripped = ../obj/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usd= t.o: ELF 64-bit LSB relocatable, x86-64, version 1 = (FreeBSD), not stripped = ../obj/i386.i386/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/js= on/tst.usdt.o: ELF 32-bit LSB relocatable, Intel 80386, version = 1 (FreeBSD), not stripped = ../obj/pc98.i386/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/js= on/tst.usdt.o: ELF 32-bit LSB relocatable, Intel 80386, version = 1 (FreeBSD), not stripped = ../obj/powerpc.powerpc64/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/c= ommon/json/tst.usdt.o: ELF 64-bit MSB relocatable, 64-bit PowerPC or = cisco 7500, version 1 (FreeBSD), not stripped = ../obj/arm64.aarch64/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/commo= n/json/tst.usdt.o: ELF 64-bit LSB relocatable, ARM aarch64, version = 1 (FreeBSD), not stripped= From owner-freebsd-current@freebsd.org Sat Oct 31 22:37:21 2015 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 73F2DA2231C for ; Sat, 31 Oct 2015 22:37:21 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 4DCDA1606 for ; Sat, 31 Oct 2015 22:37:21 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 4AFD9A2231B; Sat, 31 Oct 2015 22:37:21 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4A891A2231A for ; Sat, 31 Oct 2015 22:37:21 +0000 (UTC) (envelope-from yaneurabeya@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 215D21605; Sat, 31 Oct 2015 22:37:21 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by pacfv9 with SMTP id fv9so112713391pac.3; Sat, 31 Oct 2015 15:37:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UrM5vMF4ONBgxfBPfYqAe5Gb8eIPk0MTuU4Mxk1DacU=; b=ESp+ye+kSr7hWVlIROj14N0bQDP/4fgzT5bHcyseavZM4Sm4oS1ddvu2jB9oACjpXC XcsM8J3duJ89SXVcesGL7bQgqgFeNA3e/9Qw7Vuh4RBuIoDzT1cu+wcYWvD/9cXwcH6w sA9S3ux6J2WHR1RU3aOEc3dr680sR3VtFIrPqGoIk7GK/IiTYb9vhE9qgW2vq/siJdcA wtz2YlJjRxh4WsfYGkWVzTVqKVJmwKXkypSdL0h1hsvznrGJR81miA/90hhqYonUlJ7f 4aTX+lGwmgUk/ieDwHA+J+G/UrVEgn2NfhLdmEod1q/nCI2kb7XjI4v4//BVNobeiBXk 9/LQ== X-Received: by 10.68.221.133 with SMTP id qe5mr17364904pbc.93.1446331040637; Sat, 31 Oct 2015 15:37:20 -0700 (PDT) Received: from [192.168.20.7] (c-24-16-212-205.hsd1.wa.comcast.net. [24.16.212.205]) by smtp.gmail.com with ESMTPSA id ff2sm15690740pac.14.2015.10.31.15.37.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 31 Oct 2015 15:37:19 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect From: NGie Cooper In-Reply-To: <3957F6B6-275D-4A63-8406-A5AAECF3F131@gmail.com> Date: Sat, 31 Oct 2015 15:37:18 -0700 Cc: Bryan Drewery , Ed Maste , Mark Johnston , FreeBSD CURRENT Content-Transfer-Encoding: quoted-printable Message-Id: <5AEBE041-4AAC-49F4-BE34-C92EBD736092@gmail.com> References: <653F31AA-982B-4026-BEF5-F608BCFFFD3A@gmail.com> <6585.1446248620@chaos> <9192D4AA-FCF1-4841-89FD-A4E5D93C6941@gmail.com> <3957F6B6-275D-4A63-8406-A5AAECF3F131@gmail.com> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 31 Oct 2015 22:37:21 -0000 > On Oct 31, 2015, at 14:37, NGie Cooper wrote: >=20 >=20 >> On Oct 30, 2015, at 23:51, NGie Cooper wrote: >>=20 >>=20 >>> On Oct 30, 2015, at 16:43, Simon J. Gerraty wrote: >>>=20 >>> NGie Cooper wrote: >>>> I tried doing buildworld on powerpc/powerpc with = -DWITH_DTRACE_TESTS and I ran into this linker issue below. I have no = idea (yet) why it=E2=80=99s trying to compile an x64 object when I = specify powerpc/powerpc =E2=80=94 and more importantly, why is the = object not being put in obj.powerpc? >>>> I ran into the same issue on ref11-amd64.freebsd.org when I ran = =E2=80=9Cmake tinderbox". >>>=20 >>> Is it possible that the file is left over from a previous build (of = amd64?) >>>=20 >>> Does your log show it being built? >>>=20 >>>=20 >>>> dtrace -C -x nolibs -G -o usdt.o -s = /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt= .d tst.usdt.o >>>> dtrace: failed to link script = /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt= .d: incorrect ELF machine type for object file: tst.usdt.o >>>> *** Error code 1 >>>> $ find /usr/obj/usr/src/svn/ -name tst.usdt.o >>>> = /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o >>>> $ file = /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o >>>> = /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: = ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped >>=20 >> Still running into issues on ref11-amd64: >>=20 >> cc1: error: unrecognized command line option "-m64" >> dtrace: failed to compile script = /scratch/tmp/ngie/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/= json/usdt.d: Preprocessor failed to process input program >> --- usdt.h --- >> *** [usdt.h] Error code 1 >>=20 >> Let=E2=80=99s see what happens if I use make buildenv >=20 > =E2=80=A6 >=20 > Deleting the lines that pass -m32/-m64 gets me back to the same point = I was at before: >=20 > dtrace: failed to link script = /scratch/tmp/ngie/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/= json/usdt.d: incorrect ELF machine type for object file: tst.usdt.o > --- usdt.o --- > *** [usdt.o] Error code 1 >=20 > I=E2=80=99ll need to check .PATH, but I think it=E2=80=99s picking up = the host copy by accident: >=20 > $ find ../obj/ -name tst.usdt.o | xargs file > = ../obj/arm.armv6hf/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/= json/tst.usdt.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 = (FreeBSD), not stripped > = ../obj/arm.arm/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json= /tst.usdt.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 = (FreeBSD), not stripped > = ../obj/arm.armeb/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/js= on/tst.usdt.o: ELF 32-bit MSB relocatable, ARM, EABI5 version 1 = (FreeBSD), not stripped > = ../obj/powerpc.powerpc/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/com= mon/json/tst.usdt.o: ELF 32-bit MSB relocatable, PowerPC or cisco = 4500, version 1 (FreeBSD), not stripped > = ../obj/arm.armv6/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/js= on/tst.usdt.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 = (FreeBSD), not stripped > = ../obj/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usd= t.o: ELF 64-bit LSB relocatable, x86-64, version 1 = (FreeBSD), not stripped > = ../obj/i386.i386/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/js= on/tst.usdt.o: ELF 32-bit LSB relocatable, Intel 80386, version = 1 (FreeBSD), not stripped > = ../obj/pc98.i386/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/js= on/tst.usdt.o: ELF 32-bit LSB relocatable, Intel 80386, version = 1 (FreeBSD), not stripped > = ../obj/powerpc.powerpc64/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/c= ommon/json/tst.usdt.o: ELF 64-bit MSB relocatable, 64-bit PowerPC or = cisco 7500, version 1 (FreeBSD), not stripped > = ../obj/arm64.aarch64/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/commo= n/json/tst.usdt.o: ELF 64-bit LSB relocatable, ARM aarch64, version = 1 (FreeBSD), not stripped And here=E2=80=99s the real issue =E2=80=94 .PATH is completely broken = when TARGET/TARGET_ARCH are specified as explicit values: $ env MAKEOBJDIRPREFIX=3D/scratch/tmp/ngie/obj/ make buildenv = TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc Entering world for powerpc:powerpc $ cd cddl/usr.sbin/dtrace/tests/common/json $ make -V.OBJDIR = /scratch/tmp/ngie/obj//powerpc.powerpc/scratch/tmp/ngie/svn/cddl/usr.sbin/= dtrace/tests/common/json $ make -VMAKEOBJDIRPREFIX /scratch/tmp/ngie/obj//powerpc.powerpc $ make depend (cd /scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json && = DEPENDFILE=3D.depend.tst.usdt.exe NO_SUBDIR=3D1 make -f = /scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile = _RECURSING_PROGS=3D PROG=3Dtst.usdt.exe depend) $ make all (cd /scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json && = DEPENDFILE=3D.depend.tst.usdt.exe NO_SUBDIR=3D1 make -f = /scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile = _RECURSING_PROGS=3D PROG=3Dtst.usdt.exe ) dtrace -C -x nolibs -G -o usdt.o -s = /scratch/tmp/ngie/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/= json/usdt.d tst.usdt.o dtrace: failed to link script = /scratch/tmp/ngie/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/= json/usdt.d: incorrect ELF machine type for object file: tst.usdt.o *** Error code 1 Stop. make[3]: stopped in = /scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json *** Error code 1 Stop. make[2]: stopped in = /scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json $ make -V.PATH . /scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json = /scratch/tmp/ngie/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/= json Something seems broken with cross-building via `make tinderbox`/`make = buildworld`=E2=80=A6= From owner-freebsd-current@freebsd.org Sat Oct 31 23:16:51 2015 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 C18C9A22C35 for ; Sat, 31 Oct 2015 23:16:51 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9B8091C28 for ; Sat, 31 Oct 2015 23:16:51 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-229-78.lns20.per1.internode.on.net [121.45.229.78]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id t9VNGeDv029840 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sat, 31 Oct 2015 16:16:43 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: pf NAT and VNET Jails To: freebsd-current@freebsd.org References: From: Julian Elischer Message-ID: <56354BD2.5060608@freebsd.org> Date: Sun, 1 Nov 2015 07:16:34 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 31 Oct 2015 23:16:51 -0000 On 11/1/15 2:50 AM, Shawn Webb wrote: > I'm at r290228 on amd64. I'm not sure which revision I was on last when it > last worked, but it seems VNET jails aren't working anymore. > > I've got a bridge, bridge1, with an IP of 192.168.7.1. The VNET jails set > their default route to 192.168.7.1. The host simply NATs outbound from > 192.168.7.0/24 to the rest of the world. The various epairs get added to > bridge1 and assigned to each jail. Pretty simple setup. That worked until > today. When I do tcpdump on my public-facing NIC, I see that NAT isn't > applied. When I run `ping 8.8.8.8` from the jail, the jail's 192.168.7.0/24 > address gets sent on the wire. > > Let me know what I can do to help debug this further. send the list your setup script/settings? > > Thanks, > > Shawn Webb > _______________________________________________ > 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" >