From owner-freebsd-current@freebsd.org Sun Aug 7 00:31:38 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8F4D9BAFB39 for ; Sun, 7 Aug 2016 00:31:38 +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 3E92419D5 for ; Sun, 7 Aug 2016 00:31:37 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from amavis-ori.ijs.si (localhost [IPv6:::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.ijs.si (Postfix) with ESMTPS id 3s6M121SHPzZJ for ; Sun, 7 Aug 2016 02:31:34 +0200 (CEST) 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=1470529890; x=1473121891; bh=7e4 8SbdDFaYtYZ8SfVs0kX5cy+exSubcYv9eTVEsoh0=; b=OXmhbpzgfXg8IC04iSS 4c4fZZM52WVPJHt0YGEZaftsfJ4scCYdgjfHsQynxjeDbpODddjHMMXED0xqLtXS XPxKqyXfp6GMUHPEO2fHQZUQoCGCYE3SXUojenFwu+5ydiJ6TNT5vztTsFjq5m7A BOQVXDoPcwPw41J/AF9Td4TA= 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 XGvvutziLJdX for ; Sun, 7 Aug 2016 02:31:30 +0200 (CEST) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP id 3s6M0y5CmDzZH for ; Sun, 7 Aug 2016 02:31:30 +0200 (CEST) Received: from nabiralnik.ijs.si (nabiralnik.ijs.si [IPv6:2001:1470:ff80::80:16]) by mildred.ijs.si (Postfix) with ESMTP id 3s6M0y2QFhz1S9 for ; Sun, 7 Aug 2016 02:31:30 +0200 (CEST) Received: from sleepy.ijs.si (2001:1470:ff80:e001::1:1) by webmail.ijs.si with HTTP (HTTP/1.1 POST); Sun, 07 Aug 2016 02:31:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 07 Aug 2016 02:31:30 +0200 From: Mark Martinec To: freebsd-current@freebsd.org Subject: Re: date(1) default format changed between 10.3 and 11.0-BETA3 Organization: Jozef Stefan Institute In-Reply-To: <3b68be24-7ec8-08be-53f4-a4b088840c35@freebsd.org> References: <3629a441-ee6d-2407-fa13-5ebd8db8d802@freebsd.org> <000c29ee0f3dbd1d433c565023d69e25@mailbox.ijs.si> <279e9b67-da23-cdd6-3a77-b084ad8269eb@freebsd.org> <4a454eef-55ae-b90d-4441-2aa9708fc747@freebsd.org> <20160806041536.GL86883@eureka.lemis.com> <20160806100053.5fpf27pcgona7czp@ivaldir.etoilebsd.net> <3b68be24-7ec8-08be-53f4-a4b088840c35@freebsd.org> Message-ID: <745900399560cd03077ffb3afa5a35cd@mailbox.ijs.si> X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.2.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 07 Aug 2016 00:31:38 -0000 On 2016-08-06 21:08, Julian Elischer wrote: > On 6/08/2016 11:09 PM, Benjamin Kaduk wrote: >> On Sat, 6 Aug 2016, Baptiste Daroussin wrote: >>> On Sat, Aug 06, 2016 at 02:15:36PM +1000, Greg 'groggy' Lehey wrote: >>>> On Friday, 5 August 2016 at 18:56:33 +0300, Andrey A. Chernov >>>> wrote: >>>>> On 05.08.2016 18:44, Mark Martinec wrote: >>>>>> On 2016-08-05 17:23, Andrey Chernov wrote: >>>>>> >>>>>> POSIX does say that the default format should be the same >>>>>> as with "+%a %b %e %H:%M:%S %Z %Y". >>>>>> It also says that %a and %b are locale's abbreviated names. >>>>> It is true for _POSIX_ locale only, as I already say. en_US.* is >>>>> not >>>>> POSIX or C locale. >>>> It still violates POLA. >>>> >>> I really do not think that it violates POLA fiven that the behaviour >>> you are >>> expecting is still available in the default configurtion that is >>> still POSIX. >> Regardless, at a new major release is precisely when it is permissible >> to >> break POLA. > switching from short form to long form is more than a POLA.. short > form has a specific fixed layout > and feeding a long form string into it will break things. >> >>> Set LC_TIME to C and then you are back on your behaviour (and this is >>> the >>> default when you install FreeBSD). >>> >>> locales should be seen as tzdata for exemple, they are a moving >>> target >>> complicated to handle for every locale we do support: 78 for >>> 11.0-RELEASE and >>> 193 if we do count the encoding variants. locales are updated very >>> often (for >>> exemple cldr unicode make a new release of the data every 8 month or >>> so) >> As I understand it, your change will improve the maintainability of >> locales in FreeBSD in the future, which justifies a POLA break at the >> release boundary. >> -Ben $ LC_ALL=en_US.UTF-8 date FreeBSD 11.0-BETA3 : Friday, August 5, 2016 at 03:20:25 PM CEST FreeBSD 10.3-RELEASE-p6 : Fri Aug 5 15:15:11 CEST 2016 OSX version 10.9.5 : Fri Aug 5 14:57:14 CEST 2016 Fedora Linux 4.6.4-301.fc24.x86_64 : Fri Aug 5 15:10:40 CEST 2016 Debian 8.0 / Linux 4.4.16-v7+ : Fri Aug 5 15:25:49 CEST 2016 It's not just long vs. short forms of a name, it is also the order of fields, their separators, and a 12/24h time form that is different from everyone else and from what we used to have in 10.3. Is it really worth being different? I wonder how many ad-hoc scripts will break. Although as Andrey Chernov correctly noted that the date(1) specs in The Open Group Base Specifications Issue 7 IEEE Std 1003.1, 2013 Edition ( http://pubs.opengroup.org/onlinepubs/9699919799/utilities/date.html ) says that the default format applies to POSIX locale only: STDOUT When no formatting operand is specified, the output in the POSIX locale shall be equivalent to specifying: date "+%a %b %e %H:%M:%S %Z %Y" imo, unless there is a very good reason not to, the above default format should be applicable to most locales, but at least to English spoken locales. The explicit locale-dependency of %a, %b, and %Z conversion specifications already takes care of most locale-specific idiosyncrasies. Mark From owner-freebsd-current@freebsd.org Mon Aug 8 00:44:21 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6E551BA958C for ; Mon, 8 Aug 2016 00:44: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 4D22E1362 for ; Mon, 8 Aug 2016 00:44: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 u780iEuP026615 for ; Sun, 7 Aug 2016 17:44:18 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201608080044.u780iEuP026615@gw.catspoiler.org> Date: Sun, 7 Aug 2016 17:44:14 -0700 (PDT) From: Don Lewis Subject: PORTS_MODULES breakage on HEAD 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.22 Precedence: 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, 08 Aug 2016 00:44:21 -0000 Adding PORTS_MODULES=emulators/virtualbox-ose-kmod recently broke on HEAD. When I do that I get this failure: ===> Ports module emulators/virtualbox-ose-kmod (all) cd ${PORTSDIR:-/usr/ports}/emulators/virtualbox-ose-kmod; PATH=/usr/obj/usr/src/ tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/leg acy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/u sr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin SRC_BASE=/usr/src OSVERSION=12 00000 WRKDIRPREFIX=/usr/obj/usr/src/sys/ make -B clean all ===> Cleaning for virtualbox-ose-kmod-5.0.26_1 ===> License GPLv2 accepted by the user ===> Found saved configuration for virtualbox-ose-kmod-4.3.34 ===> virtualbox-ose-kmod-5.0.26_1 depends on file: /usr/local/sbin/pkg - found ===> Fetching all distfiles required by virtualbox-ose-kmod-5.0.26_1 for buildin g ===> Extracting for virtualbox-ose-kmod-5.0.26_1 => SHA256 Checksum OK for VirtualBox-5.0.26.tar.bz2. ===> Patching for virtualbox-ose-kmod-5.0.26_1 ===> Applying FreeBSD patches for virtualbox-ose-kmod-5.0.26_1 ===> virtualbox-ose-kmod-5.0.26_1 depends on executable: kmk - found ===> Configuring for virtualbox-ose-kmod-5.0.26_1 Checking for environment: Determined build machine: freebsd.amd64, target machin e: freebsd.amd64, OK. Checking for kBuild: found, OK. Checking for gcc: ** cc -target x86_64-unknown-freebsd12.0 --sysroot (variable CC) not found! Check /usr/obj/usr/src/sys/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualB ox-5.0.26/configure.log for details ===> Script "configure" failed unexpectedly. Please report the problem to vbox@FreeBSD.org [maintainer] and attach the "/usr/obj/usr/src/sys//usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-5 .0.26/config.log" It appears that the problem is due to CC being set to: cc -target x86_64-unknown-freebsd12.0 --sysroot and the Makefile for the port passes this: --with-gcc="${CC}" to configure. The configure script passes $CC to check_avail, which does a -z test on it. I think that CC should just be set to "cc" and the rest should get added to CFLAGS. I suspect this got broken by the recent crossbuild changes. From owner-freebsd-current@freebsd.org Mon Aug 8 03:20:45 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A7BD3BB120B for ; Mon, 8 Aug 2016 03:20:45 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::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 6F35D1BFA; Mon, 8 Aug 2016 03:20:45 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-io0-x229.google.com with SMTP id b62so346805521iod.3; Sun, 07 Aug 2016 20:20:45 -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; bh=bA6aMFawwbvcdRnS7uIgQYwr+hlulMKnf7/9u0Y7+0A=; b=WlQklLYZcDFcBZem+f1BxlCfFIpjFN/ORq6Nndd1qhl3BVbXvUzyybnwf6PXJLXWE0 wnP40JRMxcwjJQuc4fa9xPbgeG5ZuK9WRUV3CVf/jopDEduiJRXbjGvix8A/6k63zskl VWIkTqjbwAp3dGN2iHfYDX4wfjg9emKI/HdGgyhT5JYQIDFOCRDUVmmnkOEyUbODGZxR ym3AxldzwH51D3HkRzWrYhs7HiPkj/fnrcHURG+4lhA5Evo3XuqTITQwYgq1HMGypT32 5fFIcRwgTH4vucl9ZiRE6vciB/OXVFzVrRcL4Am4i29zG1TqIt+xYy3kOHpKqqJay5NH FpNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=bA6aMFawwbvcdRnS7uIgQYwr+hlulMKnf7/9u0Y7+0A=; b=G6VULLFG5dQxDlDfXdv8YR4S5V/4nZBbB+/KUOcgxBLcYoyqgqJMRs3a2tsgpUJD+m oECaZVtDY4eWsL4c+b/WMgcI831+dHZ+ouD+0RRKXJD2Vos6FbNW+kp2xuLT46Xn3Y2n +HtrmqB9x+gv4suXwW0uayv10KTFr/Z/D/cKzstsPPVz335YBFIQOU4r5ubmPwbDTErl A2dUZJDoYFbTZfBQSt+5T+UyqUz/IRyrcZo2BjJqsaAF78u5ydwCyOzuEuaD8njMMAX7 dC88R4VXxaBrKbGHlE1Cywu7UgQusqNrxMazQjEqBK8nyUhFQeYWUImBPd702ofgLDe7 Rpug== X-Gm-Message-State: AEkoouvSkcqwGCAQksHkvJ13WyxChHPpwFoMHKHCuEMtttVJC5QLKGIadZt4ZQYzgZedcehgK49mpF7MMMLrJQ== X-Received: by 10.107.129.152 with SMTP id l24mr91460327ioi.179.1470626444672; Sun, 07 Aug 2016 20:20:44 -0700 (PDT) MIME-Version: 1.0 Sender: kob6558@gmail.com Received: by 10.79.119.144 with HTTP; Sun, 7 Aug 2016 20:20:44 -0700 (PDT) In-Reply-To: <201608080044.u780iEuP026615@gw.catspoiler.org> References: <201608080044.u780iEuP026615@gw.catspoiler.org> From: Kevin Oberman Date: Sun, 7 Aug 2016 20:20:44 -0700 X-Google-Sender-Auth: D7rhjgcY_qbgjnbg7FXjuOoNoqA Message-ID: Subject: Re: PORTS_MODULES breakage on HEAD To: Don Lewis Cc: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 08 Aug 2016 03:20:45 -0000 On Sun, Aug 7, 2016 at 5:44 PM, Don Lewis wrote: > Adding PORTS_MODULES=emulators/virtualbox-ose-kmod recently broke on > HEAD. When I do that I get this failure: > > ===> Ports module emulators/virtualbox-ose-kmod (all) > cd ${PORTSDIR:-/usr/ports}/emulators/virtualbox-ose-kmod; > PATH=/usr/obj/usr/src/ > tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/ > usr/obj/usr/src/tmp/leg > acy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/ > usr/bin:/sbin:/bin:/u > sr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin SRC_BASE=/usr/src > OSVERSION=12 > 00000 WRKDIRPREFIX=/usr/obj/usr/src/sys/ make -B clean all > ===> Cleaning for virtualbox-ose-kmod-5.0.26_1 > ===> License GPLv2 accepted by the user > ===> Found saved configuration for virtualbox-ose-kmod-4.3.34 > ===> virtualbox-ose-kmod-5.0.26_1 depends on file: /usr/local/sbin/pkg - > found > ===> Fetching all distfiles required by virtualbox-ose-kmod-5.0.26_1 for > buildin > g > ===> Extracting for virtualbox-ose-kmod-5.0.26_1 > => SHA256 Checksum OK for VirtualBox-5.0.26.tar.bz2. > ===> Patching for virtualbox-ose-kmod-5.0.26_1 > ===> Applying FreeBSD patches for virtualbox-ose-kmod-5.0.26_1 > ===> virtualbox-ose-kmod-5.0.26_1 depends on executable: kmk - found > ===> Configuring for virtualbox-ose-kmod-5.0.26_1 > Checking for environment: Determined build machine: freebsd.amd64, target > machin > e: freebsd.amd64, OK. > Checking for kBuild: found, OK. > Checking for gcc: > ** cc -target x86_64-unknown-freebsd12.0 --sysroot (variable CC) not > found! > Check /usr/obj/usr/src/sys/usr/ports/emulators/virtualbox- > ose-kmod/work/VirtualB > ox-5.0.26/configure.log for details > ===> Script "configure" failed unexpectedly. > Please report the problem to vbox@FreeBSD.org [maintainer] and attach the > "/usr/obj/usr/src/sys//usr/ports/emulators/virtualbox- > ose-kmod/work/VirtualBox-5 > .0.26/config.log" > > > It appears that the problem is due to CC being set to: > cc -target x86_64-unknown-freebsd12.0 --sysroot > and the Makefile for the port passes this: > --with-gcc="${CC}" > to configure. The configure script passes $CC to check_avail, which > does a -z test on it. > > I think that CC should just be set to "cc" and the rest should get added > to CFLAGS. I suspect this got broken by the recent crossbuild changes. > > _______________________________________________ > 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" > Same issue on 11.0-BETA4 (and at least BETA3). It's not just HEAD. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 From owner-freebsd-current@freebsd.org Mon Aug 8 08:48:34 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D88F5BB2BAC; Mon, 8 Aug 2016 08:48:34 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "0x20.net", Issuer "StartCom Class 1 DV Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9E5BF1E7F; Mon, 8 Aug 2016 08:48:34 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 302F96E0081; Mon, 8 Aug 2016 10:48:31 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id u788mUMZ027244; Mon, 8 Aug 2016 10:48:30 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id u788mUd6026542; Mon, 8 Aug 2016 10:48:30 +0200 (CEST) (envelope-from lars) Date: Mon, 8 Aug 2016 10:48:30 +0200 From: Lars Engels To: Glen Barber Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, FreeBSD Release Engineering Team Subject: Re: FreeBSD 11.0-BETA4 Now Available Message-ID: <20160808084830.GP148@e-new.0x20.net> Mail-Followup-To: Lars Engels , Glen Barber , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, FreeBSD Release Engineering Team References: <20160806210526.GJ50364@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kPvmKZRaHW6UEX9w" Content-Disposition: inline In-Reply-To: <20160806210526.GJ50364@FreeBSD.org> X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p23 User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 08 Aug 2016 08:48:34 -0000 --kPvmKZRaHW6UEX9w Content-Type: text/plain; charset=utf-8 Content-Disposition: inline On Sat, Aug 06, 2016 at 09:05:26PM +0000, Glen Barber wrote: > -----BEGIN PGP SIGNED MESSAGE----- > o The new system hardening options have been fixed to avoid overwriting > other options selected during install time. Can those options also get added to "bsdconfig"? --kPvmKZRaHW6UEX9w Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQF8BAEBCgBmBQJXqEdeXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1tp3sH/A0tbZ/1kG25rWxDvu4Ls+3C 6x0bM8VV4uZ9qz3V/GrSwxl3oyMCGO8mQcz1xaN3lphNGKMXsa0DYDCInsxbDwzB YJLBcHirj6wWaJjHGCqXDY5z9kY9q7JsSgbKhTilKLOj2BH1ZVJWLpB1ccRop5/2 Em/jOBV/5VJTCYLZNauY2bNhy4lbr5UrLIN9FmY38lKC5U2V1qCAWfIM0VUXMVJ0 fUjHpM9K6KOI/LWTFxLg3N/rpHJbcPaGnLzCUsPWPg5jIgk1Nez8gk5tZMmv22ih yc7JnE7XDM/6DnT9y1QjGAMpEncCWwZ2lQfIDYS7ukuVsS0siximQeHk+3zzj4Q= =1rYD -----END PGP SIGNATURE----- --kPvmKZRaHW6UEX9w-- From owner-freebsd-current@freebsd.org Mon Aug 8 14:44:07 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7F0F1BB228A; Mon, 8 Aug 2016 14:44:07 +0000 (UTC) (envelope-from gjb@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 6FDB01CBC; Mon, 8 Aug 2016 14:44:07 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id 1D82C1229; Mon, 8 Aug 2016 14:44:07 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Mon, 8 Aug 2016 14:44:05 +0000 From: Glen Barber To: Lars Engels Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, FreeBSD Release Engineering Team Subject: Re: FreeBSD 11.0-BETA4 Now Available Message-ID: <20160808144405.GD2008@FreeBSD.org> References: <20160806210526.GJ50364@FreeBSD.org> <20160808084830.GP148@e-new.0x20.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="n/aVsWSeQ4JHkrmm" Content-Disposition: inline In-Reply-To: <20160808084830.GP148@e-new.0x20.net> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 08 Aug 2016 14:44:07 -0000 --n/aVsWSeQ4JHkrmm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 08, 2016 at 10:48:30AM +0200, Lars Engels wrote: > On Sat, Aug 06, 2016 at 09:05:26PM +0000, Glen Barber wrote: > > -----BEGIN PGP SIGNED MESSAGE----- >=20 > > o The new system hardening options have been fixed to avoid overwriting > > other options selected during install time. >=20 > Can those options also get added to "bsdconfig"? You would have to ask the bsdconfig maintainer(s). Glen --n/aVsWSeQ4JHkrmm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXqJq1AAoJEAMUWKVHj+KTntMP/j5GO8L2NDv0Ec4N1syZXzFa M4WPms+1PXUIw8ZG3kfONQ/HUH4AnKlS7zagKH6qfL31rLBwYbjPqXSShVkTjr+x UiO2zXAgHp0tfeA1NVEYkB437SrMtzHZwAXclVh4EC0l61qw05Nfx3B/cjcrduRP oTMSnjSFhatJj20F7aFeEOdQYam20QN8SvSUTiz6YFDScI0JXGjRPOltLdnNJQ7/ 7FDwcGPkhhxqDtnxUM0N3kGc4TwUeK5eiLCQroPMuAslIOq7E6Q2e4yIqbiCrtjq Uhk4trdZBpCkamsEZ+OiuTVFM1zOOOlXRIrTgNn7fUvAlCN9aRe3d4hSj9hzaSbd br55DxgF3EhUMQRAUlK53nIeSaXRCZV8ETyxrWDTBK0zQxwWPp3pMtSZb/emq8CO 5I2WjWB2Z8FbPT6ZnDXZjVOH1x82DYStx2tAGddnMYlgz+4SsZ1S3Vc/xdg7DOWZ wYTMOrQq5BI2/WrX3GBrjr9QIX/IvNBWkjuhGpsl+Xx6enpoFtEzGaW4tdJKuN4g JQ2pyV+eeAAW+MXzQaSWBwj/O+CTScnQHl9BYNfwfgk9BhQaB9dMs1lX4DPRsXil HTadlnwb3mht0Xb29BTDDxh155qu28MCfSVUwpsVA9RwCOMRhMc9NFnMdnPvDNqJ 2wJb9rc8RO57EKoYZBAf =RZrZ -----END PGP SIGNATURE----- --n/aVsWSeQ4JHkrmm-- From owner-freebsd-current@freebsd.org Mon Aug 8 15:02:11 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E478BB2AFE; Mon, 8 Aug 2016 15:02:11 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "0x20.net", Issuer "StartCom Class 1 DV Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 413BD1E32; Mon, 8 Aug 2016 15:02:11 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 7EA046E0081; Mon, 8 Aug 2016 17:02:08 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id u78F28V1031299; Mon, 8 Aug 2016 17:02:08 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id u78F28aN031116; Mon, 8 Aug 2016 17:02:08 +0200 (CEST) (envelope-from lars) Date: Mon, 8 Aug 2016 17:02:08 +0200 From: Lars Engels To: Glen Barber Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, FreeBSD Release Engineering Team , dteske@freebsd.org Subject: Re: FreeBSD 11.0-BETA4 Now Available Message-ID: <20160808150207.GA148@e-new.0x20.net> Mail-Followup-To: Lars Engels , Glen Barber , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, FreeBSD Release Engineering Team , dteske@freebsd.org References: <20160806210526.GJ50364@FreeBSD.org> <20160808084830.GP148@e-new.0x20.net> <20160808144405.GD2008@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1XmnKQGVLLNJnMip" Content-Disposition: inline In-Reply-To: <20160808144405.GD2008@FreeBSD.org> X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p23 User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 08 Aug 2016 15:02:11 -0000 --1XmnKQGVLLNJnMip Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 08, 2016 at 02:44:05PM +0000, Glen Barber wrote: > On Mon, Aug 08, 2016 at 10:48:30AM +0200, Lars Engels wrote: > > On Sat, Aug 06, 2016 at 09:05:26PM +0000, Glen Barber wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > >=20 > > > o The new system hardening options have been fixed to avoid overwriti= ng > > > other options selected during install time. > >=20 > > Can those options also get added to "bsdconfig"? >=20 > You would have to ask the bsdconfig maintainer(s). >=20 Cc'ing dteske. --1XmnKQGVLLNJnMip Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQF8BAEBCgBmBQJXqJ7vXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1tG5sH/R0oX/wME7dvkTIFfTNIjB75 4Xjmnm9erLqq4QXkfBoT8p+FqzXbX0XVbSKkmvTIWUjEaHx2042AHYZXzOT6gI3j LgoVjT7QZNZSjcjGu2C6vfIFrueJZqGi0uWouuNzNlSdviWzzMJGLc44QpHaoQ6B xUj8SPHwUmSNqXC5lsBcX8OUaGONAOXXjMN1wCPuH1UIl8al4Nz83pHeZBcnx5W4 RIyhjolj3/Ne+9hPSF+F0K9MYCFMTbSTYniwFqGBjvLZQ7cvbxYCkzQ1qpswUzli zBMW4twjwMc6vP8tXoDvxSUK18eaW9qtT3zLVKE6gDvVqOPv5gNKe9zI1h6t3BQ= =PZHo -----END PGP SIGNATURE----- --1XmnKQGVLLNJnMip-- From owner-freebsd-current@freebsd.org Mon Aug 8 17:28:42 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3B29BBB29E4 for ; Mon, 8 Aug 2016 17:28:42 +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 1CFC71857; Mon, 8 Aug 2016 17:28:42 +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 367D3B97E; Mon, 8 Aug 2016 13:28:40 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Cc: Don Lewis , freebsd-current@freebsd.org Subject: Re: kernel panic caused by virtualbox(?) Date: Mon, 08 Aug 2016 10:22:44 -0700 Message-ID: <2743385.seuRjyAMVA@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.3-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <201608050132.u751WE75016607@gw.catspoiler.org> References: <201608050132.u751WE75016607@gw.catspoiler.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, 08 Aug 2016 13:28:40 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 08 Aug 2016 17:28:42 -0000 On Thursday, August 04, 2016 05:10:29 PM Don Lewis wrote: > Reposted to -current to get some more eyes on this ... > > I just got a kernel panic when I started up a CentOS 7 VM in virtualbox. > The host is: > FreeBSD 12.0-CURRENT #17 r302500 GENERIC amd64 > The virtualbox version is: > virtualbox-ose-5.0.26 > virtualbox-ose-kmod-5.0.26_1 > > The panic message is: > > panic: Unregistered use of FPU in kernel > cpuid = 1 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe085a55d030 > vpanic() at vpanic+0x182/frame 0xfffffe085a55d0b0 > kassert_panic() at kassert_panic+0x126/frame 0xfffffe085a55d120 > trap() at trap+0x7ae/frame 0xfffffe085a55d330 > calltrap() at calltrap+0x8/frame 0xfffffe085a55d330 > --- trap 0x16, rip = 0xffffffff827dd3a9, rsp = 0xfffffe085a55d408, rbp = 0xfffffe085a55d430 --- > g_pLogger() at 0xffffffff827dd3a9/frame 0xfffffe085a55d430 > g_pLogger() at 0xffffffff8274e5c7/frame 0x3 > KDB: enter: panic > > Since g_pLogger is a symbol in vboxdrv.ko, it looks like virtualbox is > the trigger. > > There are no symbols for the virtualbox kmods, possibly because I > installed them as an upgrade using packages (built with the same source > tree version) instead of by using PORTS_MODULES in make.conf, so ports > kgdb didn't have anything useful to say about what happened before the > trap. > > This panic is very repeatable. I just got another one when starting the > same VM., but this time the two calls before the trap were > null_bug_bypass(). Hmn, that symbol is in nullfs ... > > I don't see this with a Windows 7 VM. > > All of the virtualbox kmod files are compiled with -mno-mmx -mno-sse > -msoft-float -mno-aes -mno-avx I suspect head packages are quite likely built against the a "wrong" KBI and are too fragile to use for kmods vs compiling from ports. :-/ I would try a built-from-ports kmod to see if the panics go away. -- John Baldwin From owner-freebsd-current@freebsd.org Mon Aug 8 17:43:53 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3CADBBB2E7B; Mon, 8 Aug 2016 17:43:53 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "0x20.net", Issuer "StartCom Class 1 DV Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F10171438; Mon, 8 Aug 2016 17:43:52 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 021BC6E0081; Mon, 8 Aug 2016 19:43:50 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id u78Hho27024454; Mon, 8 Aug 2016 19:43:50 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id u78HhoZm024065; Mon, 8 Aug 2016 19:43:50 +0200 (CEST) (envelope-from lars) Date: Mon, 8 Aug 2016 19:43:50 +0200 From: Lars Engels To: Devin Teske Cc: Glen Barber , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, FreeBSD Release Engineering Team Subject: Re: FreeBSD 11.0-BETA4 Now Available Message-ID: <20160808174350.GB148@e-new.0x20.net> Mail-Followup-To: Lars Engels , Devin Teske , Glen Barber , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, FreeBSD Release Engineering Team References: <20160806210526.GJ50364@FreeBSD.org> <20160808084830.GP148@e-new.0x20.net> <20160808144405.GD2008@FreeBSD.org> <20160808150207.GA148@e-new.0x20.net> <0DC3A3B2-6915-4203-B9EB-4C46A5809B1C@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Sz/4MAOlM1c8JZ8/" Content-Disposition: inline In-Reply-To: <0DC3A3B2-6915-4203-B9EB-4C46A5809B1C@freebsd.org> X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p23 User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 08 Aug 2016 17:43:53 -0000 --Sz/4MAOlM1c8JZ8/ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 08, 2016 at 10:15:07AM -0700, Devin Teske wrote: >=20 > > On Aug 8, 2016, at 8:02 AM, Lars Engels wrote: > >=20 > > On Mon, Aug 08, 2016 at 02:44:05PM +0000, Glen Barber wrote: > >> On Mon, Aug 08, 2016 at 10:48:30AM +0200, Lars Engels wrote: > >>> On Sat, Aug 06, 2016 at 09:05:26PM +0000, Glen Barber wrote: > >>>> -----BEGIN PGP SIGNED MESSAGE----- > >>>=20 > >>>> o The new system hardening options have been fixed to avoid overwrit= ing > >>>> other options selected during install time. > >>>=20 > >>> Can those options also get added to "bsdconfig"? > >>=20 > >> You would have to ask the bsdconfig maintainer(s). > >>=20 > >=20 > > Cc'ing dteske. > >=20 >=20 > What aspects of bsdconfig need updating? bsdinstall has a new "hardening" module. AFAIK bsdinstall and bsdconfig share a lot of code, so bsdconfig should probably also offer the "hardening" module. --Sz/4MAOlM1c8JZ8/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQF8BAEBCgBmBQJXqMTWXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1tuBoH+gMqgMwaPQn7ts4jGF0/w89T T9Xx1XGw637b90IJSypg6q67os418DuvuEJBr2c+exmCQOKBjM6AGjDlqXEmHlfh hgWUM1EO0DfqHGFCYIVsgXPnTuayq+GVZ7hm8/ww+dO/DEEIAVvIK5Zt/N5sj/EB Cv9sJdpZQfrkYEamQtBTeJqCxp68hcxE1gLPQzZUrUg8xq8q87z1m+JHqMCikYoe NEqA3/S1Roxlkj7NIKeWUChhER/teikxZdoAGXkbyA4q/sNUkzZQB6XwPzpjh8nn 5/bRN6qgHLQIQzgHQMMflOvR8Q6NQJrY8CBjnoPDd2YIGNaNPMNGL07HLczHssk= =X0wR -----END PGP SIGNATURE----- --Sz/4MAOlM1c8JZ8/-- From owner-freebsd-current@freebsd.org Mon Aug 8 17:51:16 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 87F9DBB327E; Mon, 8 Aug 2016 17:51:16 +0000 (UTC) (envelope-from devin@shxd.cx) Received: from shxd.cx (mail.shxd.cx [64.201.244.140]) (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 72A5710E8; Mon, 8 Aug 2016 17:51:16 +0000 (UTC) (envelope-from devin@shxd.cx) Received: from 50-196-156-133-static.hfc.comcastbusiness.net ([50.196.156.133]:62119 helo=[10.19.158.225]) by shxd.cx with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1bWnBy-000IwC-OQ; Mon, 08 Aug 2016 16:14:18 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: FreeBSD 11.0-BETA4 Now Available From: Devin Teske In-Reply-To: <20160808150207.GA148@e-new.0x20.net> Date: Mon, 8 Aug 2016 10:15:07 -0700 Cc: Glen Barber , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, FreeBSD Release Engineering Team , Devin Teske Content-Transfer-Encoding: 7bit Message-Id: <0DC3A3B2-6915-4203-B9EB-4C46A5809B1C@freebsd.org> References: <20160806210526.GJ50364@FreeBSD.org> <20160808084830.GP148@e-new.0x20.net> <20160808144405.GD2008@FreeBSD.org> <20160808150207.GA148@e-new.0x20.net> To: Lars Engels X-Mailer: Apple Mail (2.2104) Sender: devin@shxd.cx X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 08 Aug 2016 17:51:16 -0000 > On Aug 8, 2016, at 8:02 AM, Lars Engels wrote: > > On Mon, Aug 08, 2016 at 02:44:05PM +0000, Glen Barber wrote: >> On Mon, Aug 08, 2016 at 10:48:30AM +0200, Lars Engels wrote: >>> On Sat, Aug 06, 2016 at 09:05:26PM +0000, Glen Barber wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>> >>>> o The new system hardening options have been fixed to avoid overwriting >>>> other options selected during install time. >>> >>> Can those options also get added to "bsdconfig"? >> >> You would have to ask the bsdconfig maintainer(s). >> > > Cc'ing dteske. > What aspects of bsdconfig need updating? -- Devin From owner-freebsd-current@freebsd.org Mon Aug 8 17:53:33 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B2779BB358C; Mon, 8 Aug 2016 17:53:33 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8CD32199C; Mon, 8 Aug 2016 17:53:33 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from aurora.physics.berkeley.edu (aurora.physics.berkeley.edu [128.32.117.67]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u78HrQ4o030993 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 8 Aug 2016 10:53:27 -0700 Subject: Re: FreeBSD 11.0-BETA4 Now Available To: Lars Engels , Devin Teske , Glen Barber , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, FreeBSD Release Engineering Team References: <20160806210526.GJ50364@FreeBSD.org> <20160808084830.GP148@e-new.0x20.net> <20160808144405.GD2008@FreeBSD.org> <20160808150207.GA148@e-new.0x20.net> <0DC3A3B2-6915-4203-B9EB-4C46A5809B1C@freebsd.org> <20160808174350.GB148@e-new.0x20.net> From: Nathan Whitehorn Message-ID: <7e621f3a-8659-3cc1-01ac-3360dcb89604@freebsd.org> Date: Mon, 8 Aug 2016 10:53:26 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160808174350.GB148@e-new.0x20.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVa3p6svzeROAp0MepS713bHPfAoB0nqgA2BS+hPlzaXOBx3o5fGx2q9tkAgWdp3GraDEJSKJtjwkYCofbErdHYZEUuZNyJGTZY= X-Sonic-ID: C;zqbVAZFd5hGy76Dx2xNB0g== M;FDZGApFd5hGy76Dx2xNB0g== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 08 Aug 2016 17:53:33 -0000 On 08/08/16 10:43, Lars Engels wrote: > On Mon, Aug 08, 2016 at 10:15:07AM -0700, Devin Teske wrote: >>> On Aug 8, 2016, at 8:02 AM, Lars Engels wrote: >>> >>> On Mon, Aug 08, 2016 at 02:44:05PM +0000, Glen Barber wrote: >>>> On Mon, Aug 08, 2016 at 10:48:30AM +0200, Lars Engels wrote: >>>>> On Sat, Aug 06, 2016 at 09:05:26PM +0000, Glen Barber wrote: >>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>> o The new system hardening options have been fixed to avoid overwriting >>>>>> other options selected during install time. >>>>> Can those options also get added to "bsdconfig"? >>>> You would have to ask the bsdconfig maintainer(s). >>>> >>> Cc'ing dteske. >>> >> What aspects of bsdconfig need updating? > bsdinstall has a new "hardening" module. AFAIK bsdinstall and bsdconfig > share a lot of code, so bsdconfig should probably also offer the > "hardening" module. The hardening module should probably just be a part of bsdconfig, actually, and an option to open bsdconfig be an option at the end of the installer. -Nathan From owner-freebsd-current@freebsd.org Mon Aug 8 17:56:33 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70D55BB3838; Mon, 8 Aug 2016 17:56:33 +0000 (UTC) (envelope-from gjb@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 5E9F91009; Mon, 8 Aug 2016 17:56:33 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id EB3E814FE; Mon, 8 Aug 2016 17:56:32 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Mon, 8 Aug 2016 17:56:32 +0000 From: Glen Barber To: Nathan Whitehorn Cc: Lars Engels , Devin Teske , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, FreeBSD Release Engineering Team Subject: Re: FreeBSD 11.0-BETA4 Now Available Message-ID: <20160808175632.GJ2008@FreeBSD.org> References: <20160806210526.GJ50364@FreeBSD.org> <20160808084830.GP148@e-new.0x20.net> <20160808144405.GD2008@FreeBSD.org> <20160808150207.GA148@e-new.0x20.net> <0DC3A3B2-6915-4203-B9EB-4C46A5809B1C@freebsd.org> <20160808174350.GB148@e-new.0x20.net> <7e621f3a-8659-3cc1-01ac-3360dcb89604@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="g3RkK9jYN81zD2N+" Content-Disposition: inline In-Reply-To: <7e621f3a-8659-3cc1-01ac-3360dcb89604@freebsd.org> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 08 Aug 2016 17:56:33 -0000 --g3RkK9jYN81zD2N+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 08, 2016 at 10:53:26AM -0700, Nathan Whitehorn wrote: >=20 >=20 > On 08/08/16 10:43, Lars Engels wrote: > >On Mon, Aug 08, 2016 at 10:15:07AM -0700, Devin Teske wrote: > >>>On Aug 8, 2016, at 8:02 AM, Lars Engels wrote: > >>> > >>>On Mon, Aug 08, 2016 at 02:44:05PM +0000, Glen Barber wrote: > >>>>On Mon, Aug 08, 2016 at 10:48:30AM +0200, Lars Engels wrote: > >>>>>On Sat, Aug 06, 2016 at 09:05:26PM +0000, Glen Barber wrote: > >>>>>>-----BEGIN PGP SIGNED MESSAGE----- > >>>>>>o The new system hardening options have been fixed to avoid overwri= ting > >>>>>> other options selected during install time. > >>>>>Can those options also get added to "bsdconfig"? > >>>>You would have to ask the bsdconfig maintainer(s). > >>>> > >>>Cc'ing dteske. > >>> > >>What aspects of bsdconfig need updating? > >bsdinstall has a new "hardening" module. AFAIK bsdinstall and bsdconfig > >share a lot of code, so bsdconfig should probably also offer the > >"hardening" module. >=20 > The hardening module should probably just be a part of bsdconfig, actuall= y, > and an option to open bsdconfig be an option at the end of the installer. >=20 In order for that to be an option, I'd strongly suggest updating bsdconfig to properly detect packages on the DVD (which it has not since 10.0-RELEASE), as it makes too many incorrect assumptions. Glen --g3RkK9jYN81zD2N+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXqMfQAAoJEAMUWKVHj+KTxGUP/jskazT685S22zvNvcWkAu45 WCXSC8E1aM5VwR483vCgrIA6SxtLqdanfHJBK/sgoRTgb/TkZWFHiWIYiLjD3r2y mgRZFZZJaJOycsYn3juw5lcLYr9Q5kiSdWTQ+6auVAC6UG5kOgIZxA6MVbdZ+hzp AgY8wq8iXLfjI9lhaqhRAJ+7gnDs07JgWuXt6lZpqtXe+H7RUHf5Q4L9CFX/afTX /MKjv/g+QufxjDFbpslDDlItgfloCYho9rCtQseXv8MsPlxGncPs61IVK15QeeMG 0eI76ZWTFDH8Rz5oqPlMIjuYNhigMBQm9CdYkatOeG4o+G8JnfUmWtGqg6uI6QY0 k0GwdWPfzTuC2oWiziGrhfr7NeIrXrgt0o3KKSzHOWMLIKYOEj4mdYKIXPIuk6NT mS0HDMRKrQYn2WYZvNx0QXELJRvT4fXqOqiNehOJZ2Mlc7ZU6C8L4InUnTrk4OVg yL+pN5fOFUpJ7WivLAr3wygQ1JELQkJtGsSj+EKyi6zpvvaDyVaLBLyDvJrhqsjR pQibed7mm0Jq/nTT9cbpZJgsFpFIEK4sB6SJG4nsX0xWzyr8R2+F241CBMqMd2So Fnq4Wg2Cd5R+9Cb7V+zT690Y7qvr+Xd/AP0GOUzFsk3LU08sk8rZrhAaMSKGVvpv YP1PD49cht4/d+4+f6bq =7hHI -----END PGP SIGNATURE----- --g3RkK9jYN81zD2N+-- From owner-freebsd-current@freebsd.org Mon Aug 8 17:56:37 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5C39FBB3864; Mon, 8 Aug 2016 17:56:37 +0000 (UTC) (envelope-from devin@shxd.cx) Received: from shxd.cx (mail.shxd.cx [64.201.244.140]) (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 A9FE61141; Mon, 8 Aug 2016 17:56:36 +0000 (UTC) (envelope-from devin@shxd.cx) Received: from 50-196-156-133-static.hfc.comcastbusiness.net ([50.196.156.133]:62955 helo=[10.19.158.225]) by shxd.cx with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1bWnq6-000JGO-My; Mon, 08 Aug 2016 16:55:46 +0000 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0 From: Devin Teske In-Reply-To: <20160805015918.GI43509@FreeBSD.org> Date: Mon, 8 Aug 2016 10:56:35 -0700 Cc: FreeBSD Current , freebsd-stable@freebsd.org, freebsd-announce@freebsd.org, Devin Teske Message-Id: <86CE9314-487D-4D63-8CE1-34F167765EC5@freebsd.org> References: <20160805015918.GI43509@FreeBSD.org> To: Glen Barber X-Mailer: Apple Mail (2.2104) Sender: devin@shxd.cx Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 08 Aug 2016 17:56:37 -0000 Which would you use? ECDSA? https://en.wikipedia.org/wiki/Elliptic_curve_cryptography = "" In the wake of the exposure of Dual_EC_DRBG as "an NSA undercover = operation", cryptography experts have also expressed concern over the = security of the NIST recommended elliptic curves,[31] = = suggesting a return to encryption based on non-elliptic-curve groups. "" Or perhaps RSA? (as des@ recommends) (not necessarily to Glen but anyone that wants to answer) --=20 Devin > On Aug 4, 2016, at 6:59 PM, Glen Barber wrote: >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > This is a heads-up that OpenSSH keys are deprecated upstream by = OpenSSH, > and will be deprecated effective 11.0-RELEASE (and preceeding RCs). >=20 > Please see r303716 for details on the relevant commit, but upstream no > longer considers them secure. Please replace DSA keys with ECDSA or = RSA > keys as soon as possible, otherwise there will be issues when = upgrading > from 11.0-BETA4 to the subsequent 11.0 build, but most definitely the > 11.0-RELEASE build. >=20 > Glen > On behalf of: re@ and secteam@ >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 >=20 > iQIcBAEBCAAGBQJXo/L2AAoJEAMUWKVHj+KTG3sP/3j5PBVMBlYVVR+M4PUoRJjb > kShIRFHzHUV9YzTIljtqOVf/f/mw3kRHA4fUonID5AJlo23ht9cwGOvGUi5H3lBK > rnL9vsU9lvZoGyaHLpR/nikMOaRTa8bl1cdpULlEGH94HEzDuLT92AtAZ5HtdDEl > GcXRfTe3eGOaxcqNSF8NKSMQQ8rzbKmsgsa5Cbf0PYToemn3xyPAr+9Nz8tbSrlR > TrrFhzOR6+Ix0NcYJAKs6RUZ2kgbAheYF6nQmAHlJzyBihlfdfieJdysqNwSOQ8u > c7CyBLNFrGKqYTDVQI36MUwoyVtEqbOjt3cPitsMsD3fVAf05H7dHp/0iqrUghUs > 60HYOjfmvZxH5wvhEPdv/wPLAZeosdQgW8np3Y5cztw7cxZXF+PxoMjRcnXVpQ2c > QIZg3RsiQmJtAT4Z2OuvYikqGzrpsVido0um/KMM9b82XilJExxPPzgEpXCK3CE8 > 7TchzrRA/W27eST4VXoNYrrMlmpavur1IxvMS54fBOu98efTIoER6uJc1t7qcL6r > mEVmBoMqecg+auuWqz50Bh8K329dlYuGLMbk/Ktc3agXtpkw88ylDmC6l5N7qrnL > kSb4i3DboU7R1cltiin3c/P+ahwfKQdNH18QbN3utJuzSSRVvXq4laUGFlRhWEEx > bLbbH2fh5bxDmDXDMdCF > =3DLLtP > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-announce@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-announce > To unsubscribe, send any mail to = "freebsd-announce-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Mon Aug 8 18:17:50 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 927F1BB23F5; Mon, 8 Aug 2016 18:17:50 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f50.google.com (mail-it0-f50.google.com [209.85.214.50]) (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 5AB551E25; Mon, 8 Aug 2016 18:17:50 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f50.google.com with SMTP id u186so80673316ita.0; Mon, 08 Aug 2016 11:17:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=dOjG/Fva8By73eDR91aTZo+wB1or0EtJ1/LBnBeEHuU=; b=Xyjeb1Vei/POrOMmHcvECLi86JGbIZ986dIRp++9NhKkHqT1s9plTEYazjbc7WUKmM jpKfOZGzGHbwzMIf4LXR71ggTdKrv13DnAfYRTcB4KuYoILo16KDLPe5e5qnYP56aQNv Tn+YmAJzV8JhHblzTtqrlGdo2pvlXP8evVkfcgZbsPtZiIzbH7fnapP3qXWWqmk4831k FAb3AUB+wtEFuZMhvhM96tZap/t9dOb6UVqi/tcVSWsngwF43dROJuQkiZKIQp60OH0t q4YZJGVG44W9Ka1O9yDi1+B4e2S58GAZUo7CtI/Ymn8N5DX24MZZItcabM3PV/N53eRP SzDg== X-Gm-Message-State: AEkooutlwDcP4JTuydBti4W6bNW2z6mszVwXATkwoNzKcxW//xGs1V05gHXEFPMwy7jLqQ== X-Received: by 10.36.34.145 with SMTP id o139mr20292888ito.11.1470680269481; Mon, 08 Aug 2016 11:17:49 -0700 (PDT) Received: from mail-io0-f182.google.com (mail-io0-f182.google.com. [209.85.223.182]) by smtp.gmail.com with ESMTPSA id 140sm10683542itl.4.2016.08.08.11.17.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Aug 2016 11:17:49 -0700 (PDT) Received: by mail-io0-f182.google.com with SMTP id m101so365021350ioi.2; Mon, 08 Aug 2016 11:17:49 -0700 (PDT) X-Received: by 10.107.28.11 with SMTP id c11mr111350827ioc.7.1470680268947; Mon, 08 Aug 2016 11:17:48 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.36.122.208 with HTTP; Mon, 8 Aug 2016 11:17:48 -0700 (PDT) In-Reply-To: <86CE9314-487D-4D63-8CE1-34F167765EC5@freebsd.org> References: <20160805015918.GI43509@FreeBSD.org> <86CE9314-487D-4D63-8CE1-34F167765EC5@freebsd.org> From: Conrad Meyer Date: Mon, 8 Aug 2016 11:17:48 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0 To: Devin Teske Cc: Glen Barber , FreeBSD Current , freebsd-stable@freebsd.org, freebsd-announce@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 08 Aug 2016 18:17:50 -0000 The OpenSSH defaults are intentionally sane. RSA 2048 is anticipated to be fine for the next 10 years. It would not be a bad choice. I'm not aware of any reason not to use EC keys, and presumably the openssh authors wouldn't ship them as an option if they knew of any reason to believe they were compromised. Best, Conrad On Mon, Aug 8, 2016 at 10:56 AM, Devin Teske wrote: > Which would you use? > > ECDSA? > > https://en.wikipedia.org/wiki/Elliptic_curve_cryptography > > "" In the wake of the exposure of Dual_EC_DRBG as "an NSA undercover oper= ation", cryptography experts have also expressed concern over the security = of the NIST recommended elliptic curves,[31] suggesting a return to encryptio= n based on non-elliptic-curve groups. "" > > Or perhaps RSA? (as des@ recommends) > > (not necessarily to Glen but anyone that wants to answer) > -- > Devin > > >> On Aug 4, 2016, at 6:59 PM, Glen Barber wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> This is a heads-up that OpenSSH keys are deprecated upstream by OpenSSH, >> and will be deprecated effective 11.0-RELEASE (and preceeding RCs). >> >> Please see r303716 for details on the relevant commit, but upstream no >> longer considers them secure. Please replace DSA keys with ECDSA or RSA >> keys as soon as possible, otherwise there will be issues when upgrading >> from 11.0-BETA4 to the subsequent 11.0 build, but most definitely the >> 11.0-RELEASE build. >> >> Glen >> On behalf of: re@ and secteam@ >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2 >> >> iQIcBAEBCAAGBQJXo/L2AAoJEAMUWKVHj+KTG3sP/3j5PBVMBlYVVR+M4PUoRJjb >> kShIRFHzHUV9YzTIljtqOVf/f/mw3kRHA4fUonID5AJlo23ht9cwGOvGUi5H3lBK >> rnL9vsU9lvZoGyaHLpR/nikMOaRTa8bl1cdpULlEGH94HEzDuLT92AtAZ5HtdDEl >> GcXRfTe3eGOaxcqNSF8NKSMQQ8rzbKmsgsa5Cbf0PYToemn3xyPAr+9Nz8tbSrlR >> TrrFhzOR6+Ix0NcYJAKs6RUZ2kgbAheYF6nQmAHlJzyBihlfdfieJdysqNwSOQ8u >> c7CyBLNFrGKqYTDVQI36MUwoyVtEqbOjt3cPitsMsD3fVAf05H7dHp/0iqrUghUs >> 60HYOjfmvZxH5wvhEPdv/wPLAZeosdQgW8np3Y5cztw7cxZXF+PxoMjRcnXVpQ2c >> QIZg3RsiQmJtAT4Z2OuvYikqGzrpsVido0um/KMM9b82XilJExxPPzgEpXCK3CE8 >> 7TchzrRA/W27eST4VXoNYrrMlmpavur1IxvMS54fBOu98efTIoER6uJc1t7qcL6r >> mEVmBoMqecg+auuWqz50Bh8K329dlYuGLMbk/Ktc3agXtpkw88ylDmC6l5N7qrnL >> kSb4i3DboU7R1cltiin3c/P+ahwfKQdNH18QbN3utJuzSSRVvXq4laUGFlRhWEEx >> bLbbH2fh5bxDmDXDMdCF >> =3DLLtP >> -----END PGP SIGNATURE----- >> _______________________________________________ >> freebsd-announce@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-announce >> To unsubscribe, send any mail to "freebsd-announce-unsubscribe@freebsd.o= rg" > > _______________________________________________ > 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 Aug 8 18:21:31 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 241D9BB26C2 for ; Mon, 8 Aug 2016 18:21:31 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 06ED113D9 for ; Mon, 8 Aug 2016 18:21:30 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [192.168.1.10] (unknown [192.168.1.10]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 979D015A2 for ; Mon, 8 Aug 2016 18:21:29 +0000 (UTC) Subject: Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0 To: freebsd-current@freebsd.org References: <20160805015918.GI43509@FreeBSD.org> <86CE9314-487D-4D63-8CE1-34F167765EC5@freebsd.org> From: Allan Jude Message-ID: <6e97cb0a-0f9b-b60c-a762-454c3f257903@freebsd.org> Date: Mon, 8 Aug 2016 14:21:26 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 08 Aug 2016 18:21:31 -0000 On 2016-08-08 14:17, Conrad Meyer wrote: > The OpenSSH defaults are intentionally sane. RSA 2048 is anticipated > to be fine for the next 10 years. It would not be a bad choice. I'm > not aware of any reason not to use EC keys, and presumably the openssh > authors wouldn't ship them as an option if they knew of any reason to > believe they were compromised. > > Best, > Conrad > > On Mon, Aug 8, 2016 at 10:56 AM, Devin Teske wrote: >> Which would you use? >> >> ECDSA? >> >> https://en.wikipedia.org/wiki/Elliptic_curve_cryptography >> >> "" In the wake of the exposure of Dual_EC_DRBG as "an NSA undercover operation", cryptography experts have also expressed concern over the security of the NIST recommended elliptic curves,[31] suggesting a return to encryption based on non-elliptic-curve groups. "" >> >> Or perhaps RSA? (as des@ recommends) >> >> (not necessarily to Glen but anyone that wants to answer) >> -- >> Devin >> >> >>> On Aug 4, 2016, at 6:59 PM, Glen Barber wrote: >>> > This is a heads-up that OpenSSH keys are deprecated upstream by OpenSSH, > and will be deprecated effective 11.0-RELEASE (and preceeding RCs). > > Please see r303716 for details on the relevant commit, but upstream no > longer considers them secure. Please replace DSA keys with ECDSA or RSA > keys as soon as possible, otherwise there will be issues when upgrading > from 11.0-BETA4 to the subsequent 11.0 build, but most definitely the > 11.0-RELEASE build. > > Glen > On behalf of: re@ and secteam@ > As far as I know, the "advantage" to ED25519 keys, is that you can build openssh without openssl, if you forgo supporting RSA etc. -- Allan Jude From owner-freebsd-current@freebsd.org Mon Aug 8 18:22:31 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 71A79BB27F9; Mon, 8 Aug 2016 18:22:31 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5C1D01636; Mon, 8 Aug 2016 18:22:31 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (airbears2-136-152-142-124.airbears2.berkeley.edu [136.152.142.124]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u78IMRah029154 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 8 Aug 2016 11:22:27 -0700 Subject: Re: FreeBSD 11.0-BETA4 Now Available To: Glen Barber References: <20160806210526.GJ50364@FreeBSD.org> <20160808084830.GP148@e-new.0x20.net> <20160808144405.GD2008@FreeBSD.org> <20160808150207.GA148@e-new.0x20.net> <0DC3A3B2-6915-4203-B9EB-4C46A5809B1C@freebsd.org> <20160808174350.GB148@e-new.0x20.net> <7e621f3a-8659-3cc1-01ac-3360dcb89604@freebsd.org> <20160808175632.GJ2008@FreeBSD.org> Cc: Lars Engels , Devin Teske , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, FreeBSD Release Engineering Team From: Nathan Whitehorn Message-ID: Date: Mon, 8 Aug 2016 11:22:27 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160808175632.GJ2008@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVYzG+Bq415z9lY25fH7W2YRz4XbDc43pXR5BJDsZhNjAvtQXQ2iA3gGZdf+fVUyc5ZaqS74onxoHL+9oUCTQzndcygchjmm8eU= X-Sonic-ID: C;VJh+D5Vd5hGCGKDx2xNB0g== M;hji2D5Vd5hGCGKDx2xNB0g== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 08 Aug 2016 18:22:31 -0000 On 08/08/16 10:56, Glen Barber wrote: > On Mon, Aug 08, 2016 at 10:53:26AM -0700, Nathan Whitehorn wrote: >> >> On 08/08/16 10:43, Lars Engels wrote: >>> On Mon, Aug 08, 2016 at 10:15:07AM -0700, Devin Teske wrote: >>>>> On Aug 8, 2016, at 8:02 AM, Lars Engels wrote: >>>>> >>>>> On Mon, Aug 08, 2016 at 02:44:05PM +0000, Glen Barber wrote: >>>>>> On Mon, Aug 08, 2016 at 10:48:30AM +0200, Lars Engels wrote: >>>>>>> On Sat, Aug 06, 2016 at 09:05:26PM +0000, Glen Barber wrote: >>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>>> o The new system hardening options have been fixed to avoid overwriting >>>>>>>> other options selected during install time. >>>>>>> Can those options also get added to "bsdconfig"? >>>>>> You would have to ask the bsdconfig maintainer(s). >>>>>> >>>>> Cc'ing dteske. >>>>> >>>> What aspects of bsdconfig need updating? >>> bsdinstall has a new "hardening" module. AFAIK bsdinstall and bsdconfig >>> share a lot of code, so bsdconfig should probably also offer the >>> "hardening" module. >> The hardening module should probably just be a part of bsdconfig, actually, >> and an option to open bsdconfig be an option at the end of the installer. >> > In order for that to be an option, I'd strongly suggest updating > bsdconfig to properly detect packages on the DVD (which it has not since > 10.0-RELEASE), as it makes too many incorrect assumptions. > > Glen > It's way too late for this for 11.0. I was just making a general statement. I think things are fine as they are for the upcoming release. -Nathan From owner-freebsd-current@freebsd.org Mon Aug 8 18:24:10 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 60909BB29FE; Mon, 8 Aug 2016 18:24:10 +0000 (UTC) (envelope-from gjb@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 450C21A0C; Mon, 8 Aug 2016 18:24:10 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id CF53419FA; Mon, 8 Aug 2016 18:24:09 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Mon, 8 Aug 2016 18:24:08 +0000 From: Glen Barber To: Nathan Whitehorn Cc: Lars Engels , Devin Teske , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, FreeBSD Release Engineering Team Subject: Re: FreeBSD 11.0-BETA4 Now Available Message-ID: <20160808182408.GJ21640@FreeBSD.org> References: <20160806210526.GJ50364@FreeBSD.org> <20160808084830.GP148@e-new.0x20.net> <20160808144405.GD2008@FreeBSD.org> <20160808150207.GA148@e-new.0x20.net> <0DC3A3B2-6915-4203-B9EB-4C46A5809B1C@freebsd.org> <20160808174350.GB148@e-new.0x20.net> <7e621f3a-8659-3cc1-01ac-3360dcb89604@freebsd.org> <20160808175632.GJ2008@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kswDJesP0akhmDn8" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 08 Aug 2016 18:24:10 -0000 --kswDJesP0akhmDn8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 08, 2016 at 11:22:27AM -0700, Nathan Whitehorn wrote: >=20 >=20 > On 08/08/16 10:56, Glen Barber wrote: > >On Mon, Aug 08, 2016 at 10:53:26AM -0700, Nathan Whitehorn wrote: > >> > >>On 08/08/16 10:43, Lars Engels wrote: > >>>On Mon, Aug 08, 2016 at 10:15:07AM -0700, Devin Teske wrote: > >>>>>On Aug 8, 2016, at 8:02 AM, Lars Engels wrote: > >>>>> > >>>>>On Mon, Aug 08, 2016 at 02:44:05PM +0000, Glen Barber wrote: > >>>>>>On Mon, Aug 08, 2016 at 10:48:30AM +0200, Lars Engels wrote: > >>>>>>>On Sat, Aug 06, 2016 at 09:05:26PM +0000, Glen Barber wrote: > >>>>>>>>-----BEGIN PGP SIGNED MESSAGE----- > >>>>>>>>o The new system hardening options have been fixed to avoid overw= riting > >>>>>>>> other options selected during install time. > >>>>>>>Can those options also get added to "bsdconfig"? > >>>>>>You would have to ask the bsdconfig maintainer(s). > >>>>>> > >>>>>Cc'ing dteske. > >>>>> > >>>>What aspects of bsdconfig need updating? > >>>bsdinstall has a new "hardening" module. AFAIK bsdinstall and bsdconfig > >>>share a lot of code, so bsdconfig should probably also offer the > >>>"hardening" module. > >>The hardening module should probably just be a part of bsdconfig, actua= lly, > >>and an option to open bsdconfig be an option at the end of the installe= r. > >> > >In order for that to be an option, I'd strongly suggest updating > >bsdconfig to properly detect packages on the DVD (which it has not since > >10.0-RELEASE), as it makes too many incorrect assumptions. > > > > >=20 > It's way too late for this for 11.0. I was just making a general statemen= t. > I think things are fine as they are for the upcoming release. Agreed on both counts. Glen --kswDJesP0akhmDn8 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXqM5IAAoJEAMUWKVHj+KTrtIP/jgsOBqi1+LYe4oExglAD1m8 YcNdC0tQdCYTM79BywnMQmPHYxcMKdf8mxuoa6U0X2wdiPxZlouExwbSamDNRkW4 6tXbHZW29WCqJTZ5w/Q9p5L/oj8F3BieQdvBifG3nrRD7kLi0wCH9gcIF8ccBfRU 1er/gmQ7uXLnUV/9J5pAaQQw/64GYsZNmFguBVvG3TeS5ugv6oNeinMh1JcGMZO1 VRWW9EebINHQwQ45ujLhlnVoOvUNjqpChDo3bfyVJD/M6pBUz6RZUFN/hmu+TrYB SfCZPxdXGHCkyNdi74vmW/SVr/2sJn6dinkTpGQHtnSvIIm8j+9i9wAW+lbLeeQ2 sybR67akzpHTduhh6LM6NpQiwjJ0TGh5YpBAe8DzIG/rbiuyBfQwm3sePK55Feig 1def4ouvAkhsNc+w/nvSXC9JbTLCGudfdTTUdYndTz3edYwlPB4Mmi+SNrRcKoSd w54eORdYuS8ISBN3PYx2EgZtarqsYNIHMkELN1IxSwre690qcYj0mr1B4KmziZrY eyYDYtZKqk3/m+OHy0dHVmofy65Acm8ef8A/AHC9VVJ/3TGduF+fQ8Un8xYnLV8K GMvK2VOlsNQUPXVSpz3bbkcgkZuAXbtjfDH6BBKTdiX0fI6q5AuUGhzxkgIQW7wt 1evwMODH7WUwT366euRe =Ycqq -----END PGP SIGNATURE----- --kswDJesP0akhmDn8-- From owner-freebsd-current@freebsd.org Mon Aug 8 18:37:49 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 78DFBBB2F78 for ; Mon, 8 Aug 2016 18:37:49 +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 09C4E180B; Mon, 8 Aug 2016 18:37:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u78IbhN9043163 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 8 Aug 2016 21:37:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u78IbhN9043163 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u78IbhKB043162; Mon, 8 Aug 2016 21:37:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 8 Aug 2016 21:37:43 +0300 From: Konstantin Belousov To: Don Lewis Cc: freebsd-current@freebsd.org, John Baldwin Subject: Re: kernel panic caused by virtualbox(?) Message-ID: <20160808183743.GL83214@kib.kiev.ua> References: <201608050132.u751WE75016607@gw.catspoiler.org> <2743385.seuRjyAMVA@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2743385.seuRjyAMVA@ralph.baldwin.cx> User-Agent: Mutt/1.6.1 (2016-04-27) 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.22 Precedence: 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, 08 Aug 2016 18:37:49 -0000 On Mon, Aug 08, 2016 at 10:22:44AM -0700, John Baldwin wrote: > On Thursday, August 04, 2016 05:10:29 PM Don Lewis wrote: > > Reposted to -current to get some more eyes on this ... > > > > I just got a kernel panic when I started up a CentOS 7 VM in virtualbox. > > The host is: > > FreeBSD 12.0-CURRENT #17 r302500 GENERIC amd64 > > The virtualbox version is: > > virtualbox-ose-5.0.26 > > virtualbox-ose-kmod-5.0.26_1 > > > > The panic message is: > > > > panic: Unregistered use of FPU in kernel > > cpuid = 1 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe085a55d030 > > vpanic() at vpanic+0x182/frame 0xfffffe085a55d0b0 > > kassert_panic() at kassert_panic+0x126/frame 0xfffffe085a55d120 > > trap() at trap+0x7ae/frame 0xfffffe085a55d330 > > calltrap() at calltrap+0x8/frame 0xfffffe085a55d330 > > --- trap 0x16, rip = 0xffffffff827dd3a9, rsp = 0xfffffe085a55d408, rbp = 0xfffffe085a55d430 --- > > g_pLogger() at 0xffffffff827dd3a9/frame 0xfffffe085a55d430 > > g_pLogger() at 0xffffffff8274e5c7/frame 0x3 > > KDB: enter: panic > > > > Since g_pLogger is a symbol in vboxdrv.ko, it looks like virtualbox is > > the trigger. > > > > There are no symbols for the virtualbox kmods, possibly because I > > installed them as an upgrade using packages (built with the same source > > tree version) instead of by using PORTS_MODULES in make.conf, so ports > > kgdb didn't have anything useful to say about what happened before the > > trap. > > > > This panic is very repeatable. I just got another one when starting the > > same VM., but this time the two calls before the trap were > > null_bug_bypass(). Hmn, that symbol is in nullfs ... > > > > I don't see this with a Windows 7 VM. > > > > All of the virtualbox kmod files are compiled with -mno-mmx -mno-sse > > -msoft-float -mno-aes -mno-avx Your disassemble listed fxrstor instruction that failing, or did I mis-remembered ? This is most likely some context switch code, either by virtual machine or erronously executed guest code. It is not a spontaneous use of FPU, but more likely something different. Can you confirm ? In either case, I do not remember any KBI changes around PCB layout or fpu_enter() KPI recently. > > I suspect head packages are quite likely built against the a "wrong" KBI > and are too fragile to use for kmods vs compiling from ports. :-/ I would > try a built-from-ports kmod to see if the panics go away. FWIW, I will commit the following change shortly. Since third-party modules break the invariant, either due to bugs (ndis wrappers) or possibly due to KBI breakage, it is worth to have the detection enabled for production kernels. diff --git a/sys/amd64/amd64/trap.c b/sys/amd64/amd64/trap.c index 1b85b32..04c5dcc 100644 --- a/sys/amd64/amd64/trap.c +++ b/sys/amd64/amd64/trap.c @@ -443,8 +443,8 @@ trap(struct trapframe *frame) goto out; case T_DNA: - KASSERT(!PCB_USER_FPU(td->td_pcb), - ("Unregistered use of FPU in kernel")); + if (PCB_USER_FPU(td->td_pcb)) + panic("Unregistered use of FPU in kernel"); fpudna(); goto out; diff --git a/sys/i386/i386/trap.c b/sys/i386/i386/trap.c index 40f7204..c540a49 100644 --- a/sys/i386/i386/trap.c +++ b/sys/i386/i386/trap.c @@ -540,8 +540,8 @@ trap(struct trapframe *frame) case T_DNA: #ifdef DEV_NPX - KASSERT(!PCB_USER_FPU(td->td_pcb), - ("Unregistered use of FPU in kernel")); + if (PCB_USER_FPU(td->td_pcb)) + panic("Unregistered use of FPU in kernel"); if (npxdna()) goto out; #endif From owner-freebsd-current@freebsd.org Mon Aug 8 20:15:42 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8CF11BB2D7F for ; Mon, 8 Aug 2016 20:15: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 4FEEF1D36; Mon, 8 Aug 2016 20:15: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 u78KFYBd029974; Mon, 8 Aug 2016 13:15:38 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201608082015.u78KFYBd029974@gw.catspoiler.org> Date: Mon, 8 Aug 2016 13:15:34 -0700 (PDT) From: Don Lewis Subject: Re: kernel panic caused by virtualbox(?) To: jhb@freebsd.org cc: freebsd-current@freebsd.org In-Reply-To: <2743385.seuRjyAMVA@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 08 Aug 2016 20:15:42 -0000 On 8 Aug, John Baldwin wrote: > On Thursday, August 04, 2016 05:10:29 PM Don Lewis wrote: >> Reposted to -current to get some more eyes on this ... >> >> I just got a kernel panic when I started up a CentOS 7 VM in virtualbox. >> The host is: >> FreeBSD 12.0-CURRENT #17 r302500 GENERIC amd64 >> The virtualbox version is: >> virtualbox-ose-5.0.26 >> virtualbox-ose-kmod-5.0.26_1 >> >> The panic message is: >> >> panic: Unregistered use of FPU in kernel >> cpuid = 1 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe085a55d030 >> vpanic() at vpanic+0x182/frame 0xfffffe085a55d0b0 >> kassert_panic() at kassert_panic+0x126/frame 0xfffffe085a55d120 >> trap() at trap+0x7ae/frame 0xfffffe085a55d330 >> calltrap() at calltrap+0x8/frame 0xfffffe085a55d330 >> --- trap 0x16, rip = 0xffffffff827dd3a9, rsp = 0xfffffe085a55d408, rbp = 0xfffffe085a55d430 --- >> g_pLogger() at 0xffffffff827dd3a9/frame 0xfffffe085a55d430 >> g_pLogger() at 0xffffffff8274e5c7/frame 0x3 >> KDB: enter: panic >> >> Since g_pLogger is a symbol in vboxdrv.ko, it looks like virtualbox is >> the trigger. >> >> There are no symbols for the virtualbox kmods, possibly because I >> installed them as an upgrade using packages (built with the same source >> tree version) instead of by using PORTS_MODULES in make.conf, so ports >> kgdb didn't have anything useful to say about what happened before the >> trap. >> >> This panic is very repeatable. I just got another one when starting the >> same VM., but this time the two calls before the trap were >> null_bug_bypass(). Hmn, that symbol is in nullfs ... >> >> I don't see this with a Windows 7 VM. >> >> All of the virtualbox kmod files are compiled with -mno-mmx -mno-sse >> -msoft-float -mno-aes -mno-avx > > I suspect head packages are quite likely built against the a "wrong" KBI > and are too fragile to use for kmods vs compiling from ports. :-/ I would > try a built-from-ports kmod to see if the panics go away. The poudriere jail that I used to build the package was the same source version as the host. I updated the host to r303762 and manually rebuilt and installed the kmod from ports and still see the panic. What is interesting is that if I configure the Linux guests to use only one processor, the panic goes away. See for the latest info. I just figured out a way to test this on recent 10.3-STABLE without endangering my desktop machine. I should have some results in a couple hours after I bring the test machine up to date. From owner-freebsd-current@freebsd.org Mon Aug 8 20:46:12 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8450ABB3668 for ; Mon, 8 Aug 2016 20:46:12 +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 4E0F912CB; Mon, 8 Aug 2016 20:46:12 +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 u78Kk2m0030042; Mon, 8 Aug 2016 13:46:06 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201608082046.u78Kk2m0030042@gw.catspoiler.org> Date: Mon, 8 Aug 2016 13:46:02 -0700 (PDT) From: Don Lewis Subject: Re: kernel panic caused by virtualbox(?) To: kostikbel@gmail.com cc: freebsd-current@freebsd.org, jhb@freebsd.org In-Reply-To: <20160808183743.GL83214@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.22 Precedence: 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, 08 Aug 2016 20:46:12 -0000 On 8 Aug, Konstantin Belousov wrote: > On Mon, Aug 08, 2016 at 10:22:44AM -0700, John Baldwin wrote: >> On Thursday, August 04, 2016 05:10:29 PM Don Lewis wrote: >> > Reposted to -current to get some more eyes on this ... >> > >> > I just got a kernel panic when I started up a CentOS 7 VM in virtualbox. >> > The host is: >> > FreeBSD 12.0-CURRENT #17 r302500 GENERIC amd64 >> > The virtualbox version is: >> > virtualbox-ose-5.0.26 >> > virtualbox-ose-kmod-5.0.26_1 >> > >> > The panic message is: >> > >> > panic: Unregistered use of FPU in kernel >> > cpuid = 1 >> > KDB: stack backtrace: >> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe085a55d030 >> > vpanic() at vpanic+0x182/frame 0xfffffe085a55d0b0 >> > kassert_panic() at kassert_panic+0x126/frame 0xfffffe085a55d120 >> > trap() at trap+0x7ae/frame 0xfffffe085a55d330 >> > calltrap() at calltrap+0x8/frame 0xfffffe085a55d330 >> > --- trap 0x16, rip = 0xffffffff827dd3a9, rsp = 0xfffffe085a55d408, rbp = 0xfffffe085a55d430 --- >> > g_pLogger() at 0xffffffff827dd3a9/frame 0xfffffe085a55d430 >> > g_pLogger() at 0xffffffff8274e5c7/frame 0x3 >> > KDB: enter: panic >> > >> > Since g_pLogger is a symbol in vboxdrv.ko, it looks like virtualbox is >> > the trigger. >> > >> > There are no symbols for the virtualbox kmods, possibly because I >> > installed them as an upgrade using packages (built with the same source >> > tree version) instead of by using PORTS_MODULES in make.conf, so ports >> > kgdb didn't have anything useful to say about what happened before the >> > trap. >> > >> > This panic is very repeatable. I just got another one when starting the >> > same VM., but this time the two calls before the trap were >> > null_bug_bypass(). Hmn, that symbol is in nullfs ... >> > >> > I don't see this with a Windows 7 VM. >> > >> > All of the virtualbox kmod files are compiled with -mno-mmx -mno-sse >> > -msoft-float -mno-aes -mno-avx > Your disassemble listed fxrstor instruction that failing, or did I > mis-remembered ? This is most likely some context switch code, either > by virtual machine or erronously executed guest code. It is not a > spontaneous use of FPU, but more likely something different. Can you > confirm ? That is correct. My first guess was that it was some guest code incorrectly getting executed in the host context, but when I disassembled segments of the code for the two frames leading up to the trap, I noticed that there is a call from the first to the second, which would only work if the code was located at these locations in the host KVA space. In the guest address space the code locations would likely be totally different and the call would not work. My next best guess is that this is some sort of trampoline code that virtualbox stashed in some allocated memory. As I mentioned previously, I don't have this problem if I restrict the guest to one processor. Another observation is that Linux guests now default to KVM paravirtualization, whereas the other guests use other methods. One experiment that I will try is setting this to "none", but my 12.0-CURRENT box will be busy running poudriere for about the next 12 hours. I also hope to try this on FreeBSD 10.3-STABLE in the next couple of hours. From owner-freebsd-current@freebsd.org Mon Aug 8 19:48:54 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D5B23BB2663; Mon, 8 Aug 2016 19:48:54 +0000 (UTC) (envelope-from bernard@bachfreund.nl) Received: from smtp02.qsp.nl (smtp02.qsp.nl [193.254.214.163]) by mx1.freebsd.org (Postfix) with ESMTP id 7F0021AB5; Mon, 8 Aug 2016 19:48:53 +0000 (UTC) (envelope-from bernard@bachfreund.nl) Received: from smtp02.qsp.nl (localhost [127.0.0.1]) by smtp02.qsp.nl (Postfix) with ESMTP id 91F56FD034; Mon, 8 Aug 2016 21:39:49 +0200 (CEST) Received: from mail.brnrd.eu (unknown [193.164.217.85]) by smtp02.qsp.nl (Postfix) with ESMTP; Mon, 8 Aug 2016 21:39:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=brnrd.eu; h=date:from:to:subject:message-id; s=default; bh=aaFY9D09n7L8ajP6KSpy3WLrzjW3VI4YP478qJmNsjY=; b=z/RHds0AoY6HAuDGFy11+9nTCpEQfrLyQi1OczCivktd+TubX8PEwz0GVnzwJrzF2peW8pGfjVUk88ZYxc0EvxOpQe5Z7kXLjFCsyYrelB0HmTzgXOBSl/hAZ+AcMvkZay0Pre4qKl4meHxFPKQszA3rRdM/fQi8ULKWUNqzd657s5fCPfumNJQ4v+0yzNBE59QWJ4OtVRzr7PC4A+UL7DKBOhKKa4+UAqaUDMW9BRXDYtG7mK7dIo8l6PwRsNq9wxh2oB+QvMQ3OEv6FxaIa9uLZVXtj51AAaTo5kB1Nes9DBs0rhMKDLu2AyifDXeZHai++e5gbeOhRpTsuFYgAg== Received: by bachfreund.nl (OpenSMTPD) with ESMTPSA id 498a1894 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO; Mon, 8 Aug 2016 21:39:48 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 08 Aug 2016 21:39:48 +0200 From: Bernard Spil To: Devin Teske Cc: Glen Barber , FreeBSD Current , freebsd-stable@freebsd.org, owner-freebsd-stable@freebsd.org Subject: Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0 In-Reply-To: <86CE9314-487D-4D63-8CE1-34F167765EC5@freebsd.org> References: <20160805015918.GI43509@FreeBSD.org> <86CE9314-487D-4D63-8CE1-34F167765EC5@freebsd.org> Message-ID: <33cacfb7366727a725c477959a23e1a8@imap.brnrd.eu> X-Sender: bernard@bachfreund.nl User-Agent: Roundcube Webmail/1.2.0 X-Virus-Scanned: clamav at smtp02 X-Spam-Status: No, score=0.1 required=5.0 tests=DKIM_SIGNED,T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on svfilter04.qsp.nl X-Mailman-Approved-At: Mon, 08 Aug 2016 20:53:54 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 08 Aug 2016 19:48:54 -0000 Hi Devin, This resource documents the choices pretty well I think https://stribika.github.io/2015/01/04/secure-secure-shell.html Author has made some modifications up to Jan 2016 https://github.com/stribika/stribika.github.io/commits/master/_posts/2015-01-04-secure-secure-shell.md The short answer then is ed25519 or rsa4096, disable both dsa and ecdsa. Even 6.5p1 shipped with 9.3 supports ed25519. Cheers, Bernard. On 2016-08-08 19:56, Devin Teske wrote: > Which would you use? > > ECDSA? > > https://en.wikipedia.org/wiki/Elliptic_curve_cryptography > > > "" In the wake of the exposure of Dual_EC_DRBG as "an NSA undercover > operation", cryptography experts have also expressed concern over the > security of the NIST recommended elliptic curves,[31] > > suggesting a return to encryption based on non-elliptic-curve groups. > "" > > Or perhaps RSA? (as des@ recommends) > > (not necessarily to Glen but anyone that wants to answer) > -- > Devin > > >> On Aug 4, 2016, at 6:59 PM, Glen Barber wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> This is a heads-up that OpenSSH keys are deprecated upstream by >> OpenSSH, >> and will be deprecated effective 11.0-RELEASE (and preceeding RCs). >> >> Please see r303716 for details on the relevant commit, but upstream no >> longer considers them secure. Please replace DSA keys with ECDSA or >> RSA >> keys as soon as possible, otherwise there will be issues when >> upgrading >> from 11.0-BETA4 to the subsequent 11.0 build, but most definitely the >> 11.0-RELEASE build. >> >> Glen >> On behalf of: re@ and secteam@ >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2 >> >> iQIcBAEBCAAGBQJXo/L2AAoJEAMUWKVHj+KTG3sP/3j5PBVMBlYVVR+M4PUoRJjb >> kShIRFHzHUV9YzTIljtqOVf/f/mw3kRHA4fUonID5AJlo23ht9cwGOvGUi5H3lBK >> rnL9vsU9lvZoGyaHLpR/nikMOaRTa8bl1cdpULlEGH94HEzDuLT92AtAZ5HtdDEl >> GcXRfTe3eGOaxcqNSF8NKSMQQ8rzbKmsgsa5Cbf0PYToemn3xyPAr+9Nz8tbSrlR >> TrrFhzOR6+Ix0NcYJAKs6RUZ2kgbAheYF6nQmAHlJzyBihlfdfieJdysqNwSOQ8u >> c7CyBLNFrGKqYTDVQI36MUwoyVtEqbOjt3cPitsMsD3fVAf05H7dHp/0iqrUghUs >> 60HYOjfmvZxH5wvhEPdv/wPLAZeosdQgW8np3Y5cztw7cxZXF+PxoMjRcnXVpQ2c >> QIZg3RsiQmJtAT4Z2OuvYikqGzrpsVido0um/KMM9b82XilJExxPPzgEpXCK3CE8 >> 7TchzrRA/W27eST4VXoNYrrMlmpavur1IxvMS54fBOu98efTIoER6uJc1t7qcL6r >> mEVmBoMqecg+auuWqz50Bh8K329dlYuGLMbk/Ktc3agXtpkw88ylDmC6l5N7qrnL >> kSb4i3DboU7R1cltiin3c/P+ahwfKQdNH18QbN3utJuzSSRVvXq4laUGFlRhWEEx >> bLbbH2fh5bxDmDXDMdCF >> =LLtP >> -----END PGP SIGNATURE----- >> _______________________________________________ >> freebsd-announce@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-announce >> To unsubscribe, send any mail to >> "freebsd-announce-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Mon Aug 8 21:57:08 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EC1E5BB354C; Mon, 8 Aug 2016 21:57:08 +0000 (UTC) (envelope-from devin@shxd.cx) Received: from shxd.cx (mail.shxd.cx [64.201.244.140]) (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 DA02D1D01; Mon, 8 Aug 2016 21:57:08 +0000 (UTC) (envelope-from devin@shxd.cx) Received: from 50-196-156-133-static.hfc.comcastbusiness.net ([50.196.156.133]:49779 helo=[10.19.158.225]) by shxd.cx with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1bWra3-000LCL-53; Mon, 08 Aug 2016 20:55:27 +0000 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0 From: Devin Teske In-Reply-To: <33cacfb7366727a725c477959a23e1a8@imap.brnrd.eu> Date: Mon, 8 Aug 2016 14:57:05 -0700 Cc: Glen Barber , FreeBSD Current , freebsd-stable@freebsd.org, owner-freebsd-stable@freebsd.org, Devin Teske Message-Id: <22DB6A66-B8E8-4C13-B3F8-A3B53213E220@freebsd.org> References: <20160805015918.GI43509@FreeBSD.org> <86CE9314-487D-4D63-8CE1-34F167765EC5@freebsd.org> <33cacfb7366727a725c477959a23e1a8@imap.brnrd.eu> To: Bernard Spil X-Mailer: Apple Mail (2.2104) Sender: devin@shxd.cx Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 08 Aug 2016 21:57:09 -0000 > On Aug 8, 2016, at 12:39 PM, Bernard Spil = wrote: >=20 > Hi Devin, >=20 > This resource documents the choices pretty well I think > https://stribika.github.io/2015/01/04/secure-secure-shell.html = > Author has made some modifications up to Jan 2016 > = https://github.com/stribika/stribika.github.io/commits/master/_posts/2015-= 01-04-secure-secure-shell.md = >=20 > The short answer then is ed25519 or rsa4096, disable both dsa and = ecdsa. >=20 > Even 6.5p1 shipped with 9.3 supports ed25519. >=20 > Cheers, >=20 > Bernard. >=20 Thanks for confirming, Bernard! --=20 Cheers, Devin > On 2016-08-08 19:56, Devin Teske wrote: >> Which would you use? >> ECDSA? >> https://en.wikipedia.org/wiki/Elliptic_curve_cryptography = >> > >> "" In the wake of the exposure of Dual_EC_DRBG as "an NSA undercover >> operation", cryptography experts have also expressed concern over the >> security of the NIST recommended elliptic curves,[31] >> = > >> suggesting a return to encryption based on non-elliptic-curve groups. >> "" >> Or perhaps RSA? (as des@ recommends) >> (not necessarily to Glen but anyone that wants to answer) >> -- >> Devin >>> On Aug 4, 2016, at 6:59 PM, Glen Barber wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA256 >>> This is a heads-up that OpenSSH keys are deprecated upstream by = OpenSSH, >>> and will be deprecated effective 11.0-RELEASE (and preceeding RCs). >>> Please see r303716 for details on the relevant commit, but upstream = no >>> longer considers them secure. Please replace DSA keys with ECDSA or = RSA >>> keys as soon as possible, otherwise there will be issues when = upgrading >>> from 11.0-BETA4 to the subsequent 11.0 build, but most definitely = the >>> 11.0-RELEASE build. >>> Glen >>> On behalf of: re@ and secteam@ >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v2 >>> iQIcBAEBCAAGBQJXo/L2AAoJEAMUWKVHj+KTG3sP/3j5PBVMBlYVVR+M4PUoRJjb >>> kShIRFHzHUV9YzTIljtqOVf/f/mw3kRHA4fUonID5AJlo23ht9cwGOvGUi5H3lBK >>> rnL9vsU9lvZoGyaHLpR/nikMOaRTa8bl1cdpULlEGH94HEzDuLT92AtAZ5HtdDEl >>> GcXRfTe3eGOaxcqNSF8NKSMQQ8rzbKmsgsa5Cbf0PYToemn3xyPAr+9Nz8tbSrlR >>> TrrFhzOR6+Ix0NcYJAKs6RUZ2kgbAheYF6nQmAHlJzyBihlfdfieJdysqNwSOQ8u >>> c7CyBLNFrGKqYTDVQI36MUwoyVtEqbOjt3cPitsMsD3fVAf05H7dHp/0iqrUghUs >>> 60HYOjfmvZxH5wvhEPdv/wPLAZeosdQgW8np3Y5cztw7cxZXF+PxoMjRcnXVpQ2c >>> QIZg3RsiQmJtAT4Z2OuvYikqGzrpsVido0um/KMM9b82XilJExxPPzgEpXCK3CE8 >>> 7TchzrRA/W27eST4VXoNYrrMlmpavur1IxvMS54fBOu98efTIoER6uJc1t7qcL6r >>> mEVmBoMqecg+auuWqz50Bh8K329dlYuGLMbk/Ktc3agXtpkw88ylDmC6l5N7qrnL >>> kSb4i3DboU7R1cltiin3c/P+ahwfKQdNH18QbN3utJuzSSRVvXq4laUGFlRhWEEx >>> bLbbH2fh5bxDmDXDMdCF >>> =3DLLtP >>> -----END PGP SIGNATURE----- >>> _______________________________________________ >>> freebsd-announce@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-announce >>> To unsubscribe, send any mail to = "freebsd-announce-unsubscribe@freebsd.org" >> _______________________________________________ >> freebsd-stable@freebsd.org = mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable = >> To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org = " From owner-freebsd-current@freebsd.org Mon Aug 8 22:48:19 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82967BB3DE5; Mon, 8 Aug 2016 22:48:19 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4738E12D7; Mon, 8 Aug 2016 22:48:19 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi0-x231.google.com with SMTP id 4so256900020oih.2; Mon, 08 Aug 2016 15:48:19 -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; bh=5UumD63tkY36vKyctmT9/WrEk+ij11xWL4z4+zw77tg=; b=EoT/aiBjXIeL9dESvwgyfLe7Il2pDs6F3sB7Z9pqcXO4h9GN20sF/AcctzxcPFuFyS tRD5oYMq8PMABqafNiYRbbof3YkTLR/kgXQ3Uvps/C715tbfAlNYEZ0/WzR050fP5Uz8 uYbjV0eO+NDCfzsT9ek6j83d5joVLspemzYEgN5Pilu77Z73EJGyB4Dbdwodu3WUX7TH IciYf1edUiQiAUy1tTWjiC1jEU3APJDGk9Wq7C0CXFw4Z9mPeatL5wBlHO8v0QoehM9d xIep/UYg1iUX9p/W6CKkoWVtiS9dV4pZi4wy8JXsP7rCPjC1S2BO5+OGodTXyNbJzDn2 Xptg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=5UumD63tkY36vKyctmT9/WrEk+ij11xWL4z4+zw77tg=; b=fa7P7WYqweevrX/TmSc1UjmH6qB10bymp4+KtefNog7p8jOaopSOttZNeHdiPndoSl JU2Bfa3WdxmlIc5+rjkZgHJOijKW4GLIVdJwpWhI9IhuJEq1ndhsTIfYRdkC00YEUs4n lstzLg0bIuUR2jKZ+vw615eot5h/8cLL5GiXgHsQbmKPROw4xOoPQ7mTxVz4z2HvVVmm qkM38rQIX2OApjcfAWUMAt1OFVvDaMQDgYYiTI428rfdWNQTGMj3c0riIfl5YyI9oAMn GKAzX9Pjh7q3+mXHo1z/oQKNLrFSgg+kGAg/v81k/xEdWK4wl60SHwbzlt9hwf9OtxJi 3Bfg== X-Gm-Message-State: AEkoouvsLeduBxhDL2qIgj/9JwMAMOqPeCsdnYKGLFeT8Dx4qsCSGPVLUDUAZZtY8TX9Qcj8EYDi8xSRSUFo+A== X-Received: by 10.157.32.195 with SMTP id x61mr1531490ota.10.1470696498284; Mon, 08 Aug 2016 15:48:18 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.202.196.149 with HTTP; Mon, 8 Aug 2016 15:48:17 -0700 (PDT) In-Reply-To: <4bb4d0c0-fdbb-ed8c-1a47-0e789d777c1a@FreeBSD.org> References: <3f79e88d-a519-0c8d-f16a-7c83460a37c1@FreeBSD.org> <04a12279-ab01-5f5c-d8d3-5571db07c229@FreeBSD.org> <4bb4d0c0-fdbb-ed8c-1a47-0e789d777c1a@FreeBSD.org> From: Alan Somers Date: Mon, 8 Aug 2016 16:48:17 -0600 X-Google-Sender-Auth: 943pNaoiqTErGnrXMF9O_s2T26A Message-ID: Subject: Re: some [big] changes to ZPL (ZFS<->VFS ) To: Andriy Gapon Cc: FreeBSD Filesystems , FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 08 Aug 2016 22:48:19 -0000 On r303834 I can no longer reproduce the problem. -Alan On Sat, Aug 6, 2016 at 5:05 AM, Andriy Gapon wrote: > On 05/08/2016 23:31, Alan Somers wrote: >> I'm not certain it's related, but on a head build at r303767 I see a >> LOR and a reproducible panic that involve the snapdir code. > > Alan, > > thank you very much for the clear report and for the very easy > reproduction scenario. I am not sure how I missed this simple and > severe bug. > Please try r303791, it should fix the problem. > > I believe that the LOR is not new and been there since we started using > distinct tags for .zfs special vnodes. > >> First, the LOR: >> $ zpool destroy foo >> >> lock order reversal: >> 1st 0xfffff800404c8b78 zfs (zfs) @ >> /usr/home/alans/freebsd/head/sys/kern/vfs_mount.c:1244 >> 2nd 0xfffff800404c85f0 zfs_gfs (zfs_gfs) @ >> /usr/home/alans/freebsd/head/sys/cddl/contrib/opensolaris/uts/common/fs/gfs.c:484 >> stack backtrace: >> #0 0xffffffff80aa90b0 at witness_debugger+0x70 >> #1 0xffffffff80aa8fa4 at witness_checkorder+0xe54 >> #2 0xffffffff80a22072 at __lockmgr_args+0x4c2 >> #3 0xffffffff80af8e7c at vop_stdlock+0x3c >> #4 0xffffffff81018880 at VOP_LOCK1_APV+0xe0 >> #5 0xffffffff80b19f2a at _vn_lock+0x9a >> #6 0xffffffff821b9c53 at gfs_file_create+0x73 >> #7 0xffffffff821b9cfd at gfs_dir_create+0x1d >> #8 0xffffffff8228aa07 at zfsctl_mknode_snapdir+0x47 >> #9 0xffffffff821ba1a5 at gfs_dir_lookup+0x185 >> #10 0xffffffff821ba68d at gfs_vop_lookup+0x1d >> #11 0xffffffff82289a42 at zfsctl_root_lookup+0xf2 >> #12 0xffffffff8228a8c3 at zfsctl_umount_snapshots+0x83 >> #13 0xffffffff822a1d2b at zfs_umount+0x7b >> #14 0xffffffff80b02a14 at dounmount+0x6f4 >> #15 0xffffffff80b0228d at sys_unmount+0x35d >> #16 0xffffffff80ebbb7b at amd64_syscall+0x2db >> #17 0xffffffff80e9b72b at Xfast_syscall+0xfb >> >> >> Here's the panic: >> $ zpool create testpool da0 >> $ touch /testpool/testfile >> $ zfs snapshot testpool@testsnap >> $ cd /testpool/.zfs/snapshots >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 2; apic id = 04 >> fault virtual address = 0x8 >> fault code = supervisor read data, page not present >> instruction pointer = 0x20:0xffffffff80b19f1c >> stack pointer = 0x28:0xfffffe0b54bf7430 >> frame pointer = 0x28:0xfffffe0b54bf74a0 >> 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 = 966 (bash) >> trap number = 12 >> panic: page fault >> cpuid = 2 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0b54bf6fc0 >> vpanic() at vpanic+0x182/frame 0xfffffe0b54bf7040 >> panic() at panic+0x43/frame 0xfffffe0b54bf70a0 >> trap_fatal() at trap_fatal+0x351/frame 0xfffffe0b54bf7100 >> trap_pfault() at trap_pfault+0x1fd/frame 0xfffffe0b54bf7160 >> trap() at trap+0x284/frame 0xfffffe0b54bf7370 >> calltrap() at calltrap+0x8/frame 0xfffffe0b54bf7370 >> --- trap 0xc, rip = 0xffffffff80b19f1c, rsp = 0xfffffe0b54bf7440, rbp >> = 0xfffffe0b54bf74a0 --- >> _vn_lock() at _vn_lock+0x8c/frame 0xfffffe0b54bf74a0 >> zfs_lookup() at zfs_lookup+0x50d/frame 0xfffffe0b54bf7540 >> zfs_freebsd_lookup() at zfs_freebsd_lookup+0x91/frame 0xfffffe0b54bf7680 >> VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xda/frame 0xfffffe0b54bf76b0 >> vfs_cache_lookup() at vfs_cache_lookup+0xd6/frame 0xfffffe0b54bf7710 >> VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xda/frame 0xfffffe0b54bf7740 >> lookup() at lookup+0x5a2/frame 0xfffffe0b54bf77d0 >> namei() at namei+0x5b2/frame 0xfffffe0b54bf7890 >> kern_statat() at kern_statat+0xa8/frame 0xfffffe0b54bf7a40 >> sys_stat() at sys_stat+0x2d/frame 0xfffffe0b54bf7ae0 >> amd64_syscall() at amd64_syscall+0x2db/frame 0xfffffe0b54bf7bf0 >> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0b54bf7bf0 >> >> >> I can provide core files, test scripts, whatever you need. Thanks for >> tackling this difficult problem. >> >> -Alan >> >> On Fri, Aug 5, 2016 at 12:36 AM, Andriy Gapon wrote: >>> On 03/08/2016 17:25, Andriy Gapon wrote: >>>> Another change that was not strictly required and which is probably too >>>> intrusive is killing the support for case insensitive operations. My >>>> thinking was that FreeBSD VFS does not provide support for those anyway. >>>> But I'll probably restore the code, at least in the bottom half of the >>>> ZPL, before committing the change. >>> >>> It turned out that most of the removed code was dead anyway and it took >>> just a few lines of code to restore support for case-insensitive >>> filesystems. Filesystems with mixed case sensitivity behave exactly the >>> same as case-sensitive filesystem as it has always been the case on FreeBSD. >>> >>> Anyway the big change has just been committed: >>> https://svnweb.freebsd.org/changeset/base/303763 >>> Please test away. >>> >>> Another note is that the filesystem name cache is now disabled for case >>> insensitive filesystems and filesystems with normalization other than >>> none. That may hurt the lookup performance, but should ensure >>> correctness of operations. >>> >>> -- >>> Andriy Gapon >>> _______________________________________________ >>> 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" > > > -- > Andriy Gapon From owner-freebsd-current@freebsd.org Mon Aug 8 23:44:30 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ECD51BB3C44 for ; Mon, 8 Aug 2016 23:44:30 +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 A0C3F1646; Mon, 8 Aug 2016 23:44:30 +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 u78NiK1V030408; Mon, 8 Aug 2016 16:44:24 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201608082344.u78NiK1V030408@gw.catspoiler.org> Date: Mon, 8 Aug 2016 16:44:20 -0700 (PDT) From: Don Lewis Subject: Re: kernel panic caused by virtualbox(?) To: kostikbel@gmail.com cc: freebsd-current@freebsd.org, jhb@freebsd.org In-Reply-To: <20160808183743.GL83214@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.22 Precedence: 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, 08 Aug 2016 23:44:31 -0000 On 8 Aug, Konstantin Belousov wrote: > On Mon, Aug 08, 2016 at 10:22:44AM -0700, John Baldwin wrote: >> On Thursday, August 04, 2016 05:10:29 PM Don Lewis wrote: >> > Reposted to -current to get some more eyes on this ... >> > >> > I just got a kernel panic when I started up a CentOS 7 VM in virtualbox. >> > The host is: >> > FreeBSD 12.0-CURRENT #17 r302500 GENERIC amd64 >> > The virtualbox version is: >> > virtualbox-ose-5.0.26 >> > virtualbox-ose-kmod-5.0.26_1 >> > >> > The panic message is: >> > >> > panic: Unregistered use of FPU in kernel >> > cpuid = 1 >> > KDB: stack backtrace: >> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe085a55d030 >> > vpanic() at vpanic+0x182/frame 0xfffffe085a55d0b0 >> > kassert_panic() at kassert_panic+0x126/frame 0xfffffe085a55d120 >> > trap() at trap+0x7ae/frame 0xfffffe085a55d330 >> > calltrap() at calltrap+0x8/frame 0xfffffe085a55d330 >> > --- trap 0x16, rip = 0xffffffff827dd3a9, rsp = 0xfffffe085a55d408, rbp = 0xfffffe085a55d430 --- >> > g_pLogger() at 0xffffffff827dd3a9/frame 0xfffffe085a55d430 >> > g_pLogger() at 0xffffffff8274e5c7/frame 0x3 >> > KDB: enter: panic >> > >> > Since g_pLogger is a symbol in vboxdrv.ko, it looks like virtualbox is >> > the trigger. >> > >> > There are no symbols for the virtualbox kmods, possibly because I >> > installed them as an upgrade using packages (built with the same source >> > tree version) instead of by using PORTS_MODULES in make.conf, so ports >> > kgdb didn't have anything useful to say about what happened before the >> > trap. >> > >> > This panic is very repeatable. I just got another one when starting the >> > same VM., but this time the two calls before the trap were >> > null_bug_bypass(). Hmn, that symbol is in nullfs ... >> > >> > I don't see this with a Windows 7 VM. >> > >> > All of the virtualbox kmod files are compiled with -mno-mmx -mno-sse >> > -msoft-float -mno-aes -mno-avx > Your disassemble listed fxrstor instruction that failing, or did I > mis-remembered ? This is most likely some context switch code, either > by virtual machine or erronously executed guest code. It is not a > spontaneous use of FPU, but more likely something different. Can you > confirm ? > > In either case, I do not remember any KBI changes around PCB layout or > fpu_enter() KPI recently. > >> >> I suspect head packages are quite likely built against the a "wrong" KBI >> and are too fragile to use for kmods vs compiling from ports. :-/ I would >> try a built-from-ports kmod to see if the panics go away. > > FWIW, I will commit the following change shortly. Since third-party > modules break the invariant, either due to bugs (ndis wrappers) or > possibly due to KBI breakage, it is worth to have the detection enabled > for production kernels. Interesting ... I tried running virtualbox on recent 10.3-STABLE with a GENERIC kernel and the guest seemed to operate properly. Then I enabled INVARIANTS and got the panic. I suspect that is why nobody has stumbled across this before. From owner-freebsd-current@freebsd.org Tue Aug 9 01:17:06 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0BF22BB3E6C for ; Tue, 9 Aug 2016 01:17: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 E4D611CB6; Tue, 9 Aug 2016 01:17:05 +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 C3A43105; Tue, 9 Aug 2016 01:17:05 +0000 (UTC) Date: Tue, 9 Aug 2016 01:17:04 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <420125077.9.1470705425399.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #554 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 09 Aug 2016 01:17:06 -0000 See ------------------------------------------ [...truncated 324428 lines...] [192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_account_expiration_date_relative -> passed [0.114s] [192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_account_expiration_epoch -> passed [0.120s] [192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_already_exists -> passed [0.114s] [192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_bad_shell -> passed [0.121s] [192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_comments -> passed [0.115s] [192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_comments_invalid -> passed [0.084s] [192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_comments_invalid_noupdate -> passed [0.086s] [192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_comments_noupdate -> passed [0.079s] [192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_expiration -> passed [0.588s] [192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_homedir -> passed [0.119s] [192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_invalid_group_entry -> passed [0.105s] [192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_invalid_user_entry -> passed [0.103s] [192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_name_too_long -> passed [0.075s] [192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_noupdate -> passed [0.087s] [192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_password_expiration_date_month -> passed [0.119s] [192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_password_expiration_date_numeric -> passed [0.119s] [192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_password_expiration_date_relative -> passed [0.113s] [192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_password_expiration_epoch -> passed [0.115s] [192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_password_from_h -> passed [0.127s] [192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_skel -> passed [1.044s] [192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_uid0 -> passed [0.156s] [192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_uid_too_large -> passed [0.074s] [192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_w_error -> passed [0.071s] [192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_w_no -> passed [0.113s] [192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_w_none -> passed [0.115s] [192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_w_random -> passed [0.120s] [192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_w_yes -> passed [0.124s] [192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_with_pw_conf -> passed [0.131s] [192.168.10.2] out: usr.sbin/pw/pw_userdel:delete_files -> passed [0.606s] [192.168.10.2] out: usr.sbin/pw/pw_userdel:delete_numeric_name -> passed [0.117s] [192.168.10.2] out: usr.sbin/pw/pw_userdel:home_not_a_dir -> passed [0.349s] [192.168.10.2] out: usr.sbin/pw/pw_userdel:rmuser_seperate_group -> passed [0.287s] [192.168.10.2] out: usr.sbin/pw/pw_userdel:user_do_not_try_to_delete_root_if_user_unknown -> passed [0.084s] [192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod -> passed [0.153s] [192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_H -> passed [0.164s] [192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_comments -> passed [0.152s] [192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_comments_invalid -> passed [0.140s] [192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_comments_invalid_noupdate -> passed [0.130s] [192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_comments_noupdate -> passed [0.125s] [192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_h -> passed [0.218s] [192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_name_noupdate -> passed [0.131s] [192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_nogroups -> passed [0.277s] [192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_noupdate -> passed [0.143s] [192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_rename -> passed [0.155s] [192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_rename_multigroups -> passed [0.260s] [192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_rename_too_long -> passed [0.118s] [192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_renamehome -> passed [2.768s] [192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_uid -> passed [0.144s] [192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_w_error -> passed [0.112s] [192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_w_no -> passed [0.295s] [192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_w_none -> passed [0.160s] [192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_w_random -> passed [0.163s] [192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_w_yes -> passed [0.164s] [192.168.10.2] out: usr.sbin/pw/pw_usernext:usernext -> passed [0.610s] [192.168.10.2] out: usr.sbin/pw/pw_usernext:usernext_assigned_group -> passed [4.446s] [192.168.10.2] out: usr.sbin/sa/legacy_test:main -> passed [0.201s] [192.168.10.2] out: usr.sbin/extattr/extattr_test:bad_namespace -> passed [0.071s] [192.168.10.2] out: usr.sbin/extattr/extattr_test:hex -> passed [0.071s] [192.168.10.2] out: usr.sbin/extattr/extattr_test:hex_nonascii -> passed [0.074s] [192.168.10.2] out: usr.sbin/extattr/extattr_test:long_name -> expected_failure: BUG 208965 extattr(2) doesn't allow maxlen attr names: atf-check failed; see the output of the test for details [0.065s] [192.168.10.2] out: usr.sbin/extattr/extattr_test:loud -> passed [0.116s] [192.168.10.2] out: usr.sbin/extattr/extattr_test:noattrs -> passed [0.060s] [192.168.10.2] out: usr.sbin/extattr/extattr_test:nonexistent_file -> passed [0.091s] [192.168.10.2] out: usr.sbin/extattr/extattr_test:null -> passed [0.072s] [192.168.10.2] out: usr.sbin/extattr/extattr_test:one_system_attr -> passed [0.108s] [192.168.10.2] out: usr.sbin/extattr/extattr_test:one_user_attr -> passed [0.107s] [192.168.10.2] out: usr.sbin/extattr/extattr_test:stdin -> passed [0.085s] [192.168.10.2] out: usr.sbin/extattr/extattr_test:stringify -> passed [0.076s] [192.168.10.2] out: usr.sbin/extattr/extattr_test:symlink -> passed [0.086s] [192.168.10.2] out: usr.sbin/extattr/extattr_test:symlink_nofollow -> passed [0.118s] [192.168.10.2] out: usr.sbin/extattr/extattr_test:system_and_user_attrs -> passed [0.154s] [192.168.10.2] out: usr.sbin/extattr/extattr_test:two_files -> passed [0.104s] [192.168.10.2] out: usr.sbin/extattr/extattr_test:two_files_force -> passed [0.154s] [192.168.10.2] out: usr.sbin/extattr/extattr_test:two_user_attrs -> passed [0.124s] [192.168.10.2] out: usr.sbin/extattr/extattr_test:unprivileged_user_cannot_set_system_attr -> passed [0.066s] [192.168.10.2] out: usr.sbin/makefs/makefs_cd9660_tests:D_flag -> skipped: makefs crashes with SIGBUS with dupe mtree entries; see FreeBSD bug # 192839 [0.075s] [192.168.10.2] out: usr.sbin/makefs/makefs_cd9660_tests:F_flag -> passed [0.908s] [192.168.10.2] out: usr.sbin/makefs/makefs_cd9660_tests:from_mtree_spec_file -> passed [0.774s] [192.168.10.2] out: usr.sbin/makefs/makefs_cd9660_tests:from_multiple_dirs -> passed [0.574s] [192.168.10.2] out: usr.sbin/makefs/makefs_cd9660_tests:from_single_dir -> passed [0.968s] [192.168.10.2] out: usr.sbin/makefs/makefs_cd9660_tests:o_flag_allow_deep_trees -> passed [0.848s] [192.168.10.2] out: usr.sbin/makefs/makefs_cd9660_tests:o_flag_allow_max_name -> expected_failure: -o allow-max-name doesn't appear to be implemented on FreeBSD's copy of makefs [yet]: atf-check failed; see the output of the test for details [0.570s] [192.168.10.2] out: usr.sbin/makefs/makefs_cd9660_tests:o_flag_isolevel_1 -> expected_failure: this testcase needs work; the filenames generated seem incorrect/corrupt: atf-check failed; see the output of the test for details [0.552s] [192.168.10.2] out: usr.sbin/makefs/makefs_cd9660_tests:o_flag_isolevel_2 -> passed [0.559s] [192.168.10.2] out: usr.sbin/makefs/makefs_cd9660_tests:o_flag_isolevel_3 -> passed [0.479s] [192.168.10.2] out: usr.sbin/makefs/makefs_cd9660_tests:o_flag_preparer -> passed [0.127s] [192.168.10.2] out: usr.sbin/makefs/makefs_cd9660_tests:o_flag_publisher -> passed [0.152s] [192.168.10.2] out: usr.sbin/makefs/makefs_cd9660_tests:o_flag_rockridge -> passed [0.545s] [192.168.10.2] out: usr.sbin/makefs/makefs_cd9660_tests:o_flag_rockridge_dev_nodes -> passed [0.253s] [192.168.10.2] out: usr.sbin/makefs/makefs_ffs_tests:D_flag -> skipped: makefs crashes with SIGBUS with dupe mtree entries; see FreeBSD bug # 192839 [0.066s] [192.168.10.2] out: usr.sbin/makefs/makefs_ffs_tests:F_flag -> passed [0.644s] [192.168.10.2] out: usr.sbin/makefs/makefs_ffs_tests:from_mtree_spec_file -> passed [0.598s] [192.168.10.2] out: usr.sbin/makefs/makefs_ffs_tests:from_multiple_dirs -> passed [0.571s] [192.168.10.2] out: usr.sbin/makefs/makefs_ffs_tests:from_single_dir -> passed [0.593s] [192.168.10.2] out: usr.sbin/makefs/makefs_ffs_tests:o_flag_version_1 -> passed [0.621s] [192.168.10.2] out: usr.sbin/makefs/makefs_ffs_tests:o_flag_version_2 -> passed [2.539s] [192.168.10.2] out: usr.sbin/etcupdate/always_test:main -> passed [21.916s] [192.168.10.2] out: usr.sbin/etcupdate/conflicts_test:main -> passed [1.121s] [192.168.10.2] out: usr.sbin/etcupdate/fbsdid_test:main -> passed [1.087s] [192.168.10.2] out: usr.sbin/etcupdate/ignore_test:main -> passed [0.590s] [192.168.10.2] out: usr.sbin/etcupdate/preworld_test:main -> passed [0.508s] [192.168.10.2] out: usr.sbin/etcupdate/tests_test:main -> passed [10.862s] [192.168.10.2] out: usr.sbin/etcupdate/tzsetup_test:main -> passed [0.775s] [192.168.10.2] out: usr.sbin/chown/chown-f_test:main -> passed [0.022s] [192.168.10.2] out: usr.sbin/nmtree/nmtree_test:mtree_check -> passed [0.082s] [192.168.10.2] out: usr.sbin/nmtree/nmtree_test:mtree_convert_C -> passed [0.050s] [192.168.10.2] out: usr.sbin/nmtree/nmtree_test:mtree_convert_C_S -> passed [0.049s] [192.168.10.2] out: usr.sbin/nmtree/nmtree_test:mtree_convert_D -> passed [0.049s] [192.168.10.2] out: usr.sbin/nmtree/nmtree_test:mtree_convert_D_S -> passed [0.048s] [192.168.10.2] out: usr.sbin/nmtree/nmtree_test:mtree_create -> passed [0.092s] [192.168.10.2] out: usr.sbin/nmtree/nmtree_test:mtree_ignore -> passed [0.081s] [192.168.10.2] out: usr.sbin/nmtree/nmtree_test:mtree_merge -> passed [0.058s] [192.168.10.2] out: usr.sbin/nmtree/nmtree_test:mtree_nonemptydir -> passed [0.069s] [192.168.10.2] out: usr.sbin/nmtree/nmtree_test:netbsd6_check -> passed [0.089s] [192.168.10.2] out: usr.sbin/nmtree/nmtree_test:netbsd6_convert_C -> passed [0.047s] [192.168.10.2] out: usr.sbin/nmtree/nmtree_test:netbsd6_convert_C_S -> passed [0.050s] [192.168.10.2] out: usr.sbin/nmtree/nmtree_test:netbsd6_convert_D -> passed [0.049s] [192.168.10.2] out: usr.sbin/nmtree/nmtree_test:netbsd6_convert_D_S -> passed [0.049s] [192.168.10.2] out: usr.sbin/nmtree/nmtree_test:netbsd6_create -> passed [0.092s] [192.168.10.2] out: usr.sbin/nmtree/nmtree_test:netbsd6_ignore -> passed [0.090s] [192.168.10.2] out: usr.sbin/nmtree/nmtree_test:netbsd6_merge -> passed [0.056s] [192.168.10.2] out: usr.sbin/nmtree/nmtree_test:netbsd6_nonemptydir -> passed [0.067s] [192.168.10.2] out: usr.sbin/newsyslog/legacy_test:main -> passed [38.568s] [192.168.10.2] out: usr.sbin/rpcbind/addrmerge_test:addrmerge_bindip -> passed [0.015s] [192.168.10.2] out: usr.sbin/rpcbind/addrmerge_test:addrmerge_bindip6 -> passed [0.014s] [192.168.10.2] out: usr.sbin/rpcbind/addrmerge_test:addrmerge_bindip6_rev -> passed [0.013s] [192.168.10.2] out: usr.sbin/rpcbind/addrmerge_test:addrmerge_bindip_rev -> passed [0.014s] [192.168.10.2] out: usr.sbin/rpcbind/addrmerge_test:addrmerge_ipv6_linklocal -> passed [0.016s] [192.168.10.2] out: usr.sbin/rpcbind/addrmerge_test:addrmerge_ipv6_linklocal_rev -> passed [0.017s] [192.168.10.2] out: usr.sbin/rpcbind/addrmerge_test:addrmerge_localhost_only -> passed [0.016s] [192.168.10.2] out: usr.sbin/rpcbind/addrmerge_test:addrmerge_localhost_only6 -> passed [0.015s] [192.168.10.2] out: usr.sbin/rpcbind/addrmerge_test:addrmerge_noifaddrs -> passed [0.014s] [192.168.10.2] out: usr.sbin/rpcbind/addrmerge_test:addrmerge_one_addr_on_each_subnet -> passed [0.014s] [192.168.10.2] out: usr.sbin/rpcbind/addrmerge_test:addrmerge_one_addr_on_each_subnet6 -> passed [0.015s] [192.168.10.2] out: usr.sbin/rpcbind/addrmerge_test:addrmerge_one_addr_on_each_subnet6_rev -> passed [0.015s] [192.168.10.2] out: usr.sbin/rpcbind/addrmerge_test:addrmerge_one_addr_on_each_subnet_rev -> passed [0.013s] [192.168.10.2] out: usr.sbin/rpcbind/addrmerge_test:addrmerge_point2point -> passed [0.014s] [192.168.10.2] out: usr.sbin/rpcbind/addrmerge_test:addrmerge_point2point6 -> passed [0.014s] [192.168.10.2] out: usr.sbin/rpcbind/addrmerge_test:addrmerge_point2point6_rev -> passed [0.014s] [192.168.10.2] out: usr.sbin/rpcbind/addrmerge_test:addrmerge_point2point_rev -> passed [0.014s] [192.168.10.2] out: usr.sbin/rpcbind/addrmerge_test:addrmerge_recvdstaddr -> passed [0.014s] [192.168.10.2] out: usr.sbin/rpcbind/addrmerge_test:addrmerge_recvdstaddr6 -> passed [0.013s] [192.168.10.2] out: usr.sbin/rpcbind/addrmerge_test:addrmerge_recvdstaddr6_rev -> passed [0.013s] [192.168.10.2] out: usr.sbin/rpcbind/addrmerge_test:addrmerge_recvdstaddr_rev -> passed [0.014s] [192.168.10.2] out: usr.sbin/rpcbind/addrmerge_test:addrmerge_singlehomed -> passed [0.014s] [192.168.10.2] out: usr.sbin/rpcbind/addrmerge_test:addrmerge_singlehomed6 -> passed [0.014s] [192.168.10.2] out: gnu/usr.bin/diff/diff_test:mallocv -> passed [0.060s] [192.168.10.2] out: gnu/usr.bin/diff/diff_test:nomallocv -> passed [0.055s] [192.168.10.2] out: gnu/usr.bin/diff/diff_test:same -> passed [0.058s] [192.168.10.2] out: etc/rc.d/routing_test:static_ipv4_loopback_route_for_each_fib -> passed [0.094s] [192.168.10.2] out: etc/rc.d/routing_test:static_ipv6_loopback_route_for_each_fib -> passed [0.088s] [192.168.10.2] out: [192.168.10.2] out: Results file id is usr_tests.20160809-000747-866297 [192.168.10.2] out: Results saved to /root/.kyua/store/results.usr_tests.20160809-000747-866297.db [192.168.10.2] out: [192.168.10.2] out: 5738/5738 passed (0 failed) [192.168.10.2] out: [192.168.10.2] run: kyua report --verbose --results-filter passed,skipped,xfail,broken,failed --output test-report.txt [192.168.10.2] run: kyua report-junit --output=test-report.xml [192.168.10.2] run: shutdown -p now [192.168.10.2] out: Shutdown NOW! [192.168.10.2] out: kyuatestprompt # lock order reversal: 1st 0xfffffe007b1154b0 bufwait (bufwait) @ /builds/workspace/FreeBSD_HEAD/src/sys/kern/vfs_bio.c:3512 2nd 0xfffff80009331c00 dirhash (dirhash) @ /builds/workspace/FreeBSD_HEAD/src/sys/ufs/ufs/ufs_dirhash.c:281 stack backtrace: #0 0xffffffff80aaa0c0 at witness_debugger+0x70 #1 0xffffffff80aa9fb4 at witness_checkorder+0xe54 #2 0xffffffff80a53082 at _sx_xlock+0x72 #3 0xffffffff80d12ccd at ufsdirhash_add+0x3d #4 0xffffffff80d15add at ufs_direnter+0x51d #5 0xffffffff80d1efd9 at ufs_makeinode+0x5e9 #6 0xffffffff80d1ab23 at ufs_create+0x33 #7 0xffffffff8101d02a at VOP_CREATE_APV+0xda #8 0xffffffff80b1a7c8 at vn_open_cred+0x2f8 #9 0xffffffff80b13afc at kern_openat+0x25c #10 0xffffffff80ebcb7b at amd64_syscall+0x2db #11 0xffffffff80e9cc2b at Xfast_syscall+0xfb Aug 9 00:10:34 kernel: pid 24982 (sh), uid 0, was killed: exceeded maximum CPU limit lock order reversal: 1st 0xfffff8001a53c240 ufs (ufs) @ /builds/workspace/FreeBSD_HEAD/src/sys/kern/vfs_mount.c:1244 2nd 0xfffff8001a4f4b78 devfs (devfs) @ /builds/workspace/FreeBSD_HEAD/src/sys/ufs/ffs/ffs_vfsops.c:1590 stack backtrace: #0 0xffffffff80aaa0c0 at witness_debugger+0x70 #1 0xffffffff80aa9fb4 at witness_checkorder+0xe54 #2 0xffffffff80a23082 at __lockmgr_args+0x4c2 #3 0xffffffff80af9ecc at vop_stdlock+0x3c #4 0xffffffff8101f740 at VOP_LOCK1_APV+0xe0 #5 0xffffffff80b1af7a at _vn_lock+0x9a #6 0xffffffff80d0c192 at ffs_sync+0x2f2 #7 0xffffffff80b1c650 at vfs_write_suspend+0x180 #8 0xffffffff80b1c897 at vfs_write_suspend_umnt+0x47 #9 0xffffffff80d0ba54 at ffs_unmount+0x54 #10 0xffffffff80b03a64 at dounmount+0x6f4 #11 0xffffffff80b032dd at sys_unmount+0x35d #12 0xffffffff80ebcb7b at amd64_syscall+0x2db #13 0xffffffff80e9cc2b at Xfast_syscall+0xfb GEOM_CONCAT: Device concat.PYGZds created (id=1087248685). GEOM_CONCAT: Disk md0 attached to concat.PYGZds. GEOM_CONCAT: Disk md1 attached to concat.PYGZds. GEOM_CONCAT: Disk md2 attachedTraceback (most recent call last): File "freebsd-ci/scripts/test/run-tests.py", line 207, in main(sys.argv) File "freebsd-ci/scripts/test/run-tests.py", line 79, in main runTest() File "freebsd-ci/scripts/test/run-tests.py", line 187, in runTest child2.expect(pexpect.EOF, timeout=1000) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1451, in expect timeout, searchwindowsize) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1466, in expect_list timeout, searchwindowsize) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1568, in expect_loop raise TIMEOUT(str(err) + '\n' + str(self)) pexpect.TIMEOUT: Timeout exceeded. version: 3.3 command: /usr/sbin/bhyve args: [u'/usr/sbin/bhyve', u'-c', u'2', u'-m', u'2G', u'-AI', u'-H', u'-P', u'-g', u'0', u'-s', u'0:0,hostbridge', u'-s', u'1:0,lpc', u'-s', u'2:0,virtio-net,tap10,mac=58:9c:fc:00:00:2e', u'-s', u'3:0,ahci-hd,/net/jenkins-10.freebsd.org//builds/workspace/FreeBSD_HEAD/image/src/test.img', u'-l', u'com1,stdio', u'vm_test'] searcher: buffer (last 100 chars): ' to concat.PYGZds.\r\nGEOM_CONCAT: Disk md1 attached to concat.PYGZds.\r\nGEOM_CONCAT: Disk md2 attached' before (last 100 chars): ' to concat.PYGZds.\r\nGEOM_CONCAT: Disk md1 attached to concat.PYGZds.\r\nGEOM_CONCAT: Disk md2 attached' after: match: None match_index: None exitstatus: None flag_eof: False pid: 12214 child_fd: 4 closed: False timeout: 30 delimiter: logfile: ', mode 'w' at 0x800671150> logfile_read: None logfile_send: None maxread: 2000 ignorecase: False searchwindowsize: None delaybeforesend: 0.05 delayafterclose: 0.1 delayafterterminate: 0.1 [Pipeline] } [Pipeline] // node [Pipeline] node Running on master in /usr/local/jenkins/workspace/FreeBSD_HEAD [Pipeline] { [Pipeline] step From owner-freebsd-current@freebsd.org Tue Aug 9 01:43:45 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1A9E7BB04FE for ; Tue, 9 Aug 2016 01:43:45 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DB57D1A9E for ; Tue, 9 Aug 2016 01:43:44 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by mail-it0-x241.google.com with SMTP id d65so131193ith.0 for ; Mon, 08 Aug 2016 18:43:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=9+pILgUi09F2uzkWEvLsGXSGf/BxUwfz6am8cnKMwbs=; b=H/e1ITwlZ09CycYuStX3e/sFvwMVzLMI+unfrTYK/2XYPQeAbE6ouGk3PlQzajalH2 tWZPEc7lm6NmH1WH1FZXh3gNgWivSXSW5ay7eDHnVJ5fTrHVfjCe//IbKCpauvA8NbOD OCNRpyHhfaOrZQtyqYibQafo7zYwHKDJ+kUcxei43MwDD3d/wRkt4kb37U0x4vQijnrO 4+goxF/H7jFHyGQrCV7OoSSOFUpnWPn7jDtST27sLcjz9t+BWKcTV2PzdFf6qTBsPk/5 PshPEX7QtfCcJxfM5UNsV8aq99a0gE/NvRCNzlwnMFXUoAY78avAQpsaelq36AgSsYd+ Drwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=9+pILgUi09F2uzkWEvLsGXSGf/BxUwfz6am8cnKMwbs=; b=iL3L8Q0pblxftTCgT5wBx13HPgQywPaRxWR/qM3OmB++uDOMltpCzMGbkyVMELBaPm YnUuqgG3CijaPlZBgK3AsCX2g7v0i+rydNuVDqeWrzpDhL9/GqUHO8AEGpqJjz+tSJgb cHdabNNx5oVQpRMc0pzSkmzVSN2Q8hn1ENyNun+srljOu41EN080kwT2ecABops3mlAh D2VWqEAfMCnFixiGoHH18J8JDTJzjX+dMXEXLYPaCWpfaIJr7eQc9ilwDyHm+ELWJpwg 0DWriTCBDvDc3a0Kba62bzbd2G+py3u0rYT7sOLjh0o1C6hgHMa+9YS0U+rofLRLfUgV o4cA== X-Gm-Message-State: AEkoouvvZmFiLOXIhiJxXQ6AXGVBqKtkPYyShJIb9GayomafRCyEVNnxwO619rgiN/v8kEIOjLMonAovYrtECw== X-Received: by 10.36.214.209 with SMTP id o200mr21364058itg.56.1470707023350; Mon, 08 Aug 2016 18:43:43 -0700 (PDT) MIME-Version: 1.0 Sender: kmacybsd@gmail.com Received: by 10.107.143.11 with HTTP; Mon, 8 Aug 2016 18:43:42 -0700 (PDT) From: "K. Macy" Date: Mon, 8 Aug 2016 18:43:42 -0700 X-Google-Sender-Auth: Msclyq9x41iJCYigaMq-efqzLQ4 Message-ID: Subject: lengthy sdhci timeouts on KBL-Y tester To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 09 Aug 2016 01:43:45 -0000 I have a KBL-Y "Software Development Platform" for purposes of getting the i915 KMS working on that system on FreeBSD. I've just installed 11 BETA4. sdhci timeouts add several minutes to boot time. The dmesg output follows: Copyright (c) 1992-2016 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-BETA4 #0 r303759: Fri Aug 5 02:26:47 UTC 2016 root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0) VT(efifb): resolution 2560x1440 CPU: Intel(R) Core(TM) m5-7Y54 CPU @ 1.20GHz (1608.05-MHz K8-class CPU) Origin="GenuineIntel" Id=0x806e9 Family=0x6 Model=0x8e Stepping=9 Features=0xbfebfbff Features2=0x7ffafbbf AMD Features=0x2c100800 AMD Features2=0x121 Structured Extended Features=0x29c67af XSAVE Features=0xf VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 8589934592 (8192 MB) avail memory = 8160288768 (7782 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads random: unblocking device. ioapic0 irqs 0-119 on motherboard random: entropy device external interface kbd1 at kbdmux0 netmap: loaded module module_register_init: MOD_LOAD (vesa, 0xffffffff81018940, 0) error 19 random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) [EmbeddedControl] (20160527/evregion-180) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320) ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) [EmbeddedControl] (20160527/evregion-180) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320) ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) [EmbeddedControl] (20160527/evregion-180) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320) ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) [EmbeddedControl] (20160527/evregion-180) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320) ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) [EmbeddedControl] (20160527/evregion-180) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320) ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) [EmbeddedControl] (20160527/evregion-180) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320) ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) [EmbeddedControl] (20160527/evregion-180) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320) ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) [EmbeddedControl] (20160527/evregion-180) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320) ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) [EmbeddedControl] (20160527/evregion-180) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320) ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) [EmbeddedControl] (20160527/evregion-180) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320) ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) [EmbeddedControl] (20160527/evregion-180) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320) ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) [EmbeddedControl] (20160527/evregion-180) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320) ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) [EmbeddedControl] (20160527/evregion-180) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320) ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) [EmbeddedControl] (20160527/evregion-180) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320) ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) [EmbeddedControl] (20160527/evregion-180) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320) ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) [EmbeddedControl] (20160527/evregion-180) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320) ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) [EmbeddedControl] (20160527/evregion-180) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320) ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) [EmbeddedControl] (20160527/evregion-180) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320) ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) [EmbeddedControl] (20160527/evregion-180) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320) ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) [EmbeddedControl] (20160527/evregion-180) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320) ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) [EmbeddedControl] (20160527/evregion-180) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320) ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) [EmbeddedControl] (20160527/evregion-180) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320) ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) [EmbeddedControl] (20160527/evregion-180) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320) ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) [EmbeddedControl] (20160527/evregion-180) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320) ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) [EmbeddedControl] (20160527/evregion-180) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320) ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) [EmbeddedControl] (20160527/evregion-180) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320) ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) [EmbeddedControl] (20160527/evregion-180) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320) ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) [EmbeddedControl] (20160527/evregion-180) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320) ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) cpu0: on acpi0 ACPI Error: Mutex [0x0] is not acquired, cannot release (20160527/utmutex-386) ACPI Error: Could not release AML Interpreter mutex (20160527/exutils-147) ACPI Error: Mutex [0x0] is not acquired, cannot release (20160527/utmutex-386) ACPI Error: Could not release AML Interpreter mutex (20160527/exutils-147) cpu1: on acpi0 ACPI Error: Mutex [0x0] is not acquired, cannot release (20160527/utmutex-386) ACPI Error: Could not release AML Interpreter mutex (20160527/exutils-147) ACPI Error: Mutex [0x0] is not acquired, cannot release (20160527/utmutex-386) ACPI Error: Could not release AML Interpreter mutex (20160527/exutils-147) cpu2: on acpi0 cpu3: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 24000000 Hz quality 950 Event timer "HPET" frequency 24000000 Hz quality 550 Event timer "HPET1" frequency 24000000 Hz quality 440 Event timer "HPET2" frequency 24000000 Hz quality 440 Event timer "HPET3" frequency 24000000 Hz quality 440 Event timer "HPET4" frequency 24000000 Hz quality 440 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x3000-0x303f mem 0xb0000000-0xb0ffffff,0xa0000000-0xafffffff at device 2.0 on pci0 vgapci0: Boot video device xhci0: mem 0xb1320000-0xb132ffff at device 20.0 on pci0 xhci0: 32 bytes context size, 64-bit DMA usbus0 on xhci0 pci0: at device 20.1 (no driver attached) pci0: at device 22.0 (no driver attached) ahci0: port 0x3080-0x3087,0x3088-0x308b,0x3060-0x307f mem 0xb1350000-0xb1351fff,0xb135d000-0xb135d0ff,0xb135b000-0xb135b7ff at device 23.0 on pci0 ahci0: AHCI v1.31 with 1 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 pcib1: at device 29.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) sdhci_pci0: mem 0xb1359000-0xb1359fff at device 30.4 on pci0 sdhci_pci0: 1 slot(s) allocated mmc0: on sdhci_pci0 sdhci_pci1: mem 0xb135a000-0xb135afff at device 30.6 on pci0 sdhci_pci1: 1 slot(s) allocated isab0: at device 31.0 on pci0 isa0: on isab0 pci0: at device 31.2 (no driver attached) hdac0: mem 0xb1348000-0xb134bfff,0xb1330000-0xb133ffff at device 31.3 on pci0 em0: mem 0xb1300000-0xb131ffff at device 31.6 on pci0 em0: Using an MSI interrupt em0: Ethernet address: 90:49:fa:02:6b:8b em0: netmap queues/slots: TX 1/1024, RX 1/1024 acpi_acad0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_tz0: on acpi0 acpi_tz1: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] battery0: on acpi0 battery1: on acpi0 battery2: on acpi0 acpi_lid0: on acpi0 ppc1: cannot reserve I/O port range ppc0: cannot reserve I/O port range uart0: at port 0x3f8 irq 4 flags 0x10 on isa0 est0: on cpu0 est1: on cpu1 est2: on cpu2 est3: on cpu3 usbus0: 5.0Gbps Super Speed USB v3.0 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec nvme cam probe device init ugen0.1: <0x8086> at usbus0 uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ACS-3 ATA SATA 3.x device ada0: Serial Number CVTR6233050T480EGN ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 457862MB (937703088 512 byte sectors) ada0: quirks=0x1<4K> uhub0: 18 ports with 18 removable, self powered ugen0.2: at usbus0 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x8100 umass0:1:0: Attached to scbus1 da0 at umass-sim0 bus 0 scbus1 target 0 lun 0 da0: Removable Direct Access SPC-4 SCSI device da0: Serial Number AA63032200000027 da0: 40.000MB/s transfers da0: 31704MB (64929792 512 byte sectors) da0: quirks=0x13 GEOM: da0: the secondary GPT header is not in the last LBA. ugen0.3: at usbus0 ukbd0: on usbus0 kbd2 at ukbd0 ugen0.4: at usbus0 ugen0.2: at usbus0 (disconnected) umass0: at uhub0, port 2, addr 1 (disconnected) da0 at umass-sim0 bus 0 scbus1 target 0 lun 0 da0: s/n AA63032200000027 detached (da0:umass-sim0:0:0:0): Periph destroyed sdhci_pci0-slot0: Controller timeout sdhci_pci0-slot0: ============== REGISTER DUMP ============== sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 sdhci_pci0-slot0: =========================================== ugen0.2: at usbus0 sdhci_pci0-slot0: Controller timeout sdhci_pci0-slot0: ============== REGISTER DUMP ============== sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 sdhci_pci0-slot0: =========================================== sdhci_pci0-slot0: Controller timeout sdhci_pci0-slot0: ============== REGISTER DUMP ============== sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 sdhci_pci0-slot0: =========================================== sdhci_pci0-slot0: Controller timeout sdhci_pci0-slot0: ============== REGISTER DUMP ============== sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 sdhci_pci0-slot0: =========================================== sdhci_pci0-slot0: Controller timeout sdhci_pci0-slot0: ============== REGISTER DUMP ============== sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 sdhci_pci0-slot0: Argument: 0x000001aa | Trn mode: 0x00000000 sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 sdhci_pci0-slot0: =========================================== sdhci_pci0-slot0: Controller timeout sdhci_pci0-slot0: ============== REGISTER DUMP ============== sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 sdhci_pci0-slot0: Argument: 0x000001aa | Trn mode: 0x00000000 sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 sdhci_pci0-slot0: =========================================== sdhci_pci0-slot0: Controller timeout sdhci_pci0-slot0: ============== REGISTER DUMP ============== sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 sdhci_pci0-slot0: Argument: 0x000001aa | Trn mode: 0x00000000 sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 sdhci_pci0-slot0: =========================================== sdhci_pci0-slot0: Controller timeout sdhci_pci0-slot0: ============== REGISTER DUMP ============== sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 sdhci_pci0-slot0: Argument: 0x000001aa | Trn mode: 0x00000000 sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 sdhci_pci0-slot0: =========================================== sdhci_pci0-slot0: Controller timeout sdhci_pci0-slot0: ============== REGISTER DUMP ============== sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 sdhci_pci0-slot0: =========================================== sdhci_pci0-slot0: Controller timeout sdhci_pci0-slot0: ============== REGISTER DUMP ============== sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 sdhci_pci0-slot0: =========================================== sdhci_pci0-slot0: Controller timeout sdhci_pci0-slot0: ============== REGISTER DUMP ============== sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 sdhci_pci0-slot0: =========================================== sdhci_pci0-slot0: Controller timeout sdhci_pci0-slot0: ============== REGISTER DUMP ============== sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 sdhci_pci0-slot0: =========================================== sdhci_pci0-slot0: Controller timeout sdhci_pci0-slot0: ============== REGISTER DUMP ============== sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 sdhci_pci0-slot0: =========================================== sdhci_pci0-slot0: Controller timeout sdhci_pci0-slot0: ============== REGISTER DUMP ============== sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 sdhci_pci0-slot0: =========================================== sdhci_pci0-slot0: Controller timeout sdhci_pci0-slot0: ============== REGISTER DUMP ============== sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 sdhci_pci0-slot0: =========================================== sdhci_pci0-slot0: Controller timeout sdhci_pci0-slot0: ============== REGISTER DUMP ============== sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 sdhci_pci0-slot0: =========================================== mmc0: No compatible cards found on bus hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 hdaa0: hdaa_audio_as_parse: Duplicate pin 0 (23) in association 1! Disabling association. pcm0: at nid 33 and 24 on hdaa0 hdacc1: at cad 2 on hdac0 hdaa1: at nid 1 on hdacc1 pcm1: at nid 3 on hdaa1 SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! Timecounter "TSC" frequency 1608052518 Hz quality 1000 Trying to mount root from zfs:zroot/ROOT/default []... uhid0: on usbus0 uhid1: on usbus0 ubt0: on usbus0 ums0: on usbus0 ums0: 16 buttons and [XYZT] coordinates ID=0 WARNING: attempt to domain_add(bluetooth) after domainfinalize() WARNING: attempt to domain_add(netgraph) after domainfinalize() The pciconf entry for sdhci are: sdhci_pci0@pci0:0:30:4: class=0x080501 card=0x72708086 chip=0x9d2b8086 rev=0x21 hdr=0x00 vendor = 'Intel Corporation' class = base peripheral subclass = SD host controller sdhci_pci1@pci0:0:30:6: class=0x080501 card=0x72708086 chip=0x9d2d8086 rev=0x21 hdr=0x00 vendor = 'Intel Corporation' device = 'Sunrise Point-LP Secure Digital IO Controller' class = base peripheral subclass = SD host controller If someone wants to take a crack at it I can test any changes. Otherwise I'll just take it out of the kernel. Thanks. -M From owner-freebsd-current@freebsd.org Tue Aug 9 02:45:03 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B4235BB27BF for ; Tue, 9 Aug 2016 02:45:03 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.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 9EEA61A23 for ; Tue, 9 Aug 2016 02:45:03 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: by mailman.ysv.freebsd.org (Postfix) id 9ABC6BB27BE; Tue, 9 Aug 2016 02:45: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 98185BB27BD for ; Tue, 9 Aug 2016 02:45:03 +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 5063D1A22 for ; Tue, 9 Aug 2016 02:45:03 +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 1bWwhq-0002Zl-4r for current@freebsd.org; Tue, 09 Aug 2016 04:23:50 +0200 Received: from mail by rmm6prod02.runbox.com with local (Exim 4.76) (envelope-from ) id 1bWwhq-0003jI-4a for current@freebsd.org; Tue, 09 Aug 2016 04:23:50 +0200 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); for ; Tue, 09 Aug 2016 02:23:50 GMT From: "Jeffrey Bouquet" Reply-To: jbtakk@iherebuywisely.com To: "current" Subject: Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0 Date: Mon, 08 Aug 2016 19:23:50 -0700 (PDT) X-Mailer: RMM6 In-Reply-To: <22DB6A66-B8E8-4C13-B3F8-A3B53213E220@freebsd.org> Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 09 Aug 2016 02:45:03 -0000 Will/could there be some kind of UPDATING announcement re which files expli= citly to=20 switch out/remove/replace/checkfor etc the deprecated lines and precisely t= he steps to replace with new or some other suitable action? Action required for both= the sshd and client? Subdirectories involved? etc... Unclear here, but I don't use SSH = hardly yet... despite having bought the book. On Mon, 8 Aug 2016 14:57:05 -0700, Devin Teske wrote: >=20 > > On Aug 8, 2016, at 12:39 PM, Bernard Spil wrote: > >=20 > > Hi Devin, > >=20 > > This resource documents the choices pretty well I think > > https://stribika.github.io/2015/01/04/secure-secure-shell.html > > Author has made some modifications up to Jan 2016 > > https://github.com/stribika/stribika.github.io/commits/master/_posts/20= 15-01-04-secure-secure-shell.md > >=20 > > The short answer then is ed25519 or rsa4096, disable both dsa and ecdsa. > >=20 > > Even 6.5p1 shipped with 9.3 supports ed25519. > >=20 > > Cheers, > >=20 > > Bernard. > >=20 >=20 > Thanks for confirming, Bernard! > --=20 > Cheers, > Devin >=20 >=20 > > On 2016-08-08 19:56, Devin Teske wrote: > >> Which would you use? > >> ECDSA? > >> https://en.wikipedia.org/wiki/Elliptic_curve_cryptography > >> > > >> "" In the wake of the exposure of Dual_EC_DRBG as "an NSA undercover > >> operation", cryptography experts have also expressed concern over the > >> security of the NIST recommended elliptic curves,[31] > >> > > >> suggesting a return to encryption based on non-elliptic-curve groups. > >> "" > >> Or perhaps RSA? (as des@ recommends) > >> (not necessarily to Glen but anyone that wants to answer) > >> -- > >> Devin > >>> On Aug 4, 2016, at 6:59 PM, Glen Barber wrote: > >>> -----BEGIN PGP SIGNED MESSAGE----- > >>> Hash: SHA256 > >>> This is a heads-up that OpenSSH keys are deprecated upstream by OpenS= SH, > >>> and will be deprecated effective 11.0-RELEASE (and preceeding RCs). > >>> Please see r303716 for details on the relevant commit, but upstream no > >>> longer considers them secure. Please replace DSA keys with ECDSA or = RSA > >>> keys as soon as possible, otherwise there will be issues when upgradi= ng > >>> from 11.0-BETA4 to the subsequent 11.0 build, but most definitely the > >>> 11.0-RELEASE build. > >>> Glen > >>> On behalf of: re@ and secteam@ > >>> -----BEGIN PGP SIGNATURE----- > >>> Version: GnuPG v2 > >>> iQIcBAEBCAAGBQJXo/L2AAoJEAMUWKVHj+KTG3sP/3j5PBVMBlYVVR+M4PUoRJjb > >>> kShIRFHzHUV9YzTIljtqOVf/f/mw3kRHA4fUonID5AJlo23ht9cwGOvGUi5H3lBK > >>> rnL9vsU9lvZoGyaHLpR/nikMOaRTa8bl1cdpULlEGH94HEzDuLT92AtAZ5HtdDEl > >>> GcXRfTe3eGOaxcqNSF8NKSMQQ8rzbKmsgsa5Cbf0PYToemn3xyPAr+9Nz8tbSrlR > >>> TrrFhzOR6+Ix0NcYJAKs6RUZ2kgbAheYF6nQmAHlJzyBihlfdfieJdysqNwSOQ8u > >>> c7CyBLNFrGKqYTDVQI36MUwoyVtEqbOjt3cPitsMsD3fVAf05H7dHp/0iqrUghUs > >>> 60HYOjfmvZxH5wvhEPdv/wPLAZeosdQgW8np3Y5cztw7cxZXF+PxoMjRcnXVpQ2c > >>> QIZg3RsiQmJtAT4Z2OuvYikqGzrpsVido0um/KMM9b82XilJExxPPzgEpXCK3CE8 > >>> 7TchzrRA/W27eST4VXoNYrrMlmpavur1IxvMS54fBOu98efTIoER6uJc1t7qcL6r > >>> mEVmBoMqecg+auuWqz50Bh8K329dlYuGLMbk/Ktc3agXtpkw88ylDmC6l5N7qrnL > >>> kSb4i3DboU7R1cltiin3c/P+ahwfKQdNH18QbN3utJuzSSRVvXq4laUGFlRhWEEx > >>> bLbbH2fh5bxDmDXDMdCF > >>> =3DLLtP > >>> -----END PGP SIGNATURE----- > >>> _______________________________________________ > >>> freebsd-announce@freebsd.org mailing list > >>> https://lists.freebsd.org/mailman/listinfo/freebsd-announce > >>> To unsubscribe, send any mail to "freebsd-announce-unsubscribe@freebs= d.org" > >> _______________________________________________ > >> freebsd-stable@freebsd.org mailing= list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable > >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.o= rg " >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Tue Aug 9 04:56:51 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9C749BB2760 for ; Tue, 9 Aug 2016 04:56:51 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 44F3D1B20; Tue, 9 Aug 2016 04:56:51 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1bWz5s-001IlE-QA>; Tue, 09 Aug 2016 06:56:48 +0200 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=freyja.zeit4.iv.bundesimmobilien.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1bWz5s-001LMN-6Y>; Tue, 09 Aug 2016 06:56:48 +0200 Date: Tue, 9 Aug 2016 06:56:42 +0200 From: "O. Hartmann" To: "K. Macy" Cc: FreeBSD Current Subject: Re: lengthy sdhci timeouts on KBL-Y tester Message-ID: <20160809065642.1feb4299@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: References: Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 87.138.105.249 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 09 Aug 2016 04:56:51 -0000 On Mon, 8 Aug 2016 18:43:42 -0700 "K. Macy" wrote: > I have a KBL-Y "Software Development Platform" for purposes of getting > the i915 KMS working on that system on FreeBSD. I've just installed 11 > BETA4. sdhci timeouts add several minutes to boot time. The dmesg > output follows: [...] A very similar situation here with a Intel NUC5CPYH. I circumvent the problem by setting in /boot/device.hints "hint.sdhci_pci.0.disabled=1" as a workaround. [...] > Copyright (c) 1992-2016 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 11.0-BETA4 #0 r303759: Fri Aug 5 02:26:47 UTC 2016 > root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 > FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on > LLVM 3.8.0) > VT(efifb): resolution 2560x1440 > CPU: Intel(R) Core(TM) m5-7Y54 CPU @ 1.20GHz (1608.05-MHz K8-class CPU) > Origin="GenuineIntel" Id=0x806e9 Family=0x6 Model=0x8e Stepping=9 > Features=0xbfebfbff > Features2=0x7ffafbbf > AMD Features=0x2c100800 > AMD Features2=0x121 > Structured Extended > Features=0x29c67af > XSAVE Features=0xf > VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID > TSC: P-state invariant, performance statistics > real memory = 8589934592 (8192 MB) > avail memory = 8160288768 (7782 MB) > Event timer "LAPIC" quality 600 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads > random: unblocking device. > ioapic0 irqs 0-119 on motherboard > random: entropy device external interface > kbd1 at kbdmux0 > netmap: loaded module > module_register_init: MOD_LOAD (vesa, 0xffffffff81018940, 0) error 19 > random: registering fast source Intel Secure Key RNG > random: fast provider: "Intel Secure Key RNG" > cryptosoft0: on motherboard > acpi0: on motherboard > acpi0: Power Button (fixed) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] > (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] > (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] > (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] > (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] > (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] > (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] > (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] > (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] > (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] > (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] > (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] > (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] > (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] > (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] > (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] > (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] > (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] > (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] > (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] > (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] > (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] > (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] > (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] > (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] > (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] > (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] > (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] > (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) > cpu0: on acpi0 > ACPI Error: Mutex [0x0] is not acquired, cannot release (20160527/utmutex-386) > ACPI Error: Could not release AML Interpreter mutex (20160527/exutils-147) > ACPI Error: Mutex [0x0] is not acquired, cannot release (20160527/utmutex-386) > ACPI Error: Could not release AML Interpreter mutex (20160527/exutils-147) > cpu1: on acpi0 > ACPI Error: Mutex [0x0] is not acquired, cannot release (20160527/utmutex-386) > ACPI Error: Could not release AML Interpreter mutex (20160527/exutils-147) > ACPI Error: Mutex [0x0] is not acquired, cannot release (20160527/utmutex-386) > ACPI Error: Could not release AML Interpreter mutex (20160527/exutils-147) > cpu2: on acpi0 > cpu3: on acpi0 > hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > Timecounter "HPET" frequency 24000000 Hz quality 950 > Event timer "HPET" frequency 24000000 Hz quality 550 > Event timer "HPET1" frequency 24000000 Hz quality 440 > Event timer "HPET2" frequency 24000000 Hz quality 440 > Event timer "HPET3" frequency 24000000 Hz quality 440 > Event timer "HPET4" frequency 24000000 Hz quality 440 > atrtc0: port 0x70-0x77 irq 8 on acpi0 > atrtc0: Warning: Couldn't map I/O. > Event timer "RTC" frequency 32768 Hz quality 0 > attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0 > acpi_ec0: port 0x62,0x66 on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > vgapci0: port 0x3000-0x303f mem > 0xb0000000-0xb0ffffff,0xa0000000-0xafffffff at device 2.0 on pci0 > vgapci0: Boot video device > xhci0: mem 0xb1320000-0xb132ffff > at device 20.0 on pci0 > xhci0: 32 bytes context size, 64-bit DMA > usbus0 on xhci0 > pci0: at device 20.1 (no driver attached) > pci0: at device 22.0 (no driver attached) > ahci0: port > 0x3080-0x3087,0x3088-0x308b,0x3060-0x307f mem > 0xb1350000-0xb1351fff,0xb135d000-0xb135d0ff,0xb135b000-0xb135b7ff at > device 23.0 on pci0 > ahci0: AHCI v1.31 with 1 6Gbps ports, Port Multiplier not supported > ahcich0: at channel 0 on ahci0 > pcib1: at device 29.0 on pci0 > pci1: on pcib1 > pci1: at device 0.0 (no driver attached) > sdhci_pci0: mem 0xb1359000-0xb1359fff at device 30.4 on pci0 > sdhci_pci0: 1 slot(s) allocated > mmc0: on sdhci_pci0 > sdhci_pci1: mem 0xb135a000-0xb135afff at device 30.6 on pci0 > sdhci_pci1: 1 slot(s) allocated > isab0: at device 31.0 on pci0 > isa0: on isab0 > pci0: at device 31.2 (no driver attached) > hdac0: mem > 0xb1348000-0xb134bfff,0xb1330000-0xb133ffff at device 31.3 on pci0 > em0: mem > 0xb1300000-0xb131ffff at device 31.6 on pci0 > em0: Using an MSI interrupt > em0: Ethernet address: 90:49:fa:02:6b:8b > em0: netmap queues/slots: TX 1/1024, RX 1/1024 > acpi_acad0: on acpi0 > acpi_button0: on acpi0 > acpi_button1: on acpi0 > acpi_tz0: on acpi0 > acpi_tz1: on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > battery0: on acpi0 > battery1: on acpi0 > battery2: on acpi0 > acpi_lid0: on acpi0 > ppc1: cannot reserve I/O port range > ppc0: cannot reserve I/O port range > uart0: at port 0x3f8 irq 4 > flags 0x10 on isa0 > est0: on cpu0 > est1: on cpu1 > est2: on cpu2 > est3: on cpu3 > usbus0: 5.0Gbps Super Speed USB v3.0 > ZFS filesystem version: 5 > ZFS storage pool version: features support (5000) > Timecounters tick every 1.000 msec > nvme cam probe device init > ugen0.1: <0x8086> at usbus0 > uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ACS-3 ATA SATA 3.x device > ada0: Serial Number CVTR6233050T480EGN > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 457862MB (937703088 512 byte sectors) > ada0: quirks=0x1<4K> > uhub0: 18 ports with 18 removable, self powered > ugen0.2: at usbus0 > umass0: 1> on usbus0 > umass0: SCSI over Bulk-Only; quirks = 0x8100 > umass0:1:0: Attached to scbus1 > da0 at umass-sim0 bus 0 scbus1 target 0 lun 0 > da0: Removable Direct Access SPC-4 SCSI device > da0: Serial Number AA63032200000027 > da0: 40.000MB/s transfers > da0: 31704MB (64929792 512 byte sectors) > da0: quirks=0x13 > GEOM: da0: the secondary GPT header is not in the last LBA. > ugen0.3: at usbus0 > ukbd0: on usbus0 > kbd2 at ukbd0 > ugen0.4: at usbus0 > ugen0.2: at usbus0 (disconnected) > umass0: at uhub0, port 2, addr 1 (disconnected) > da0 at umass-sim0 bus 0 scbus1 target 0 lun 0 > da0: s/n AA63032200000027 detached > (da0:umass-sim0:0:0:0): Periph destroyed > sdhci_pci0-slot0: Controller timeout > sdhci_pci0-slot0: ============== REGISTER DUMP ============== > sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 > sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 > sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 > sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 > sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 > sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 > sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 > sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb > sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 > sdhci_pci0-slot0: =========================================== > ugen0.2: at usbus0 > sdhci_pci0-slot0: Controller timeout > sdhci_pci0-slot0: ============== REGISTER DUMP ============== > sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 > sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 > sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 > sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 > sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 > sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 > sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 > sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb > sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 > sdhci_pci0-slot0: =========================================== > sdhci_pci0-slot0: Controller timeout > sdhci_pci0-slot0: ============== REGISTER DUMP ============== > sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 > sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 > sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 > sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 > sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 > sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 > sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 > sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb > sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 > sdhci_pci0-slot0: =========================================== > sdhci_pci0-slot0: Controller timeout > sdhci_pci0-slot0: ============== REGISTER DUMP ============== > sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 > sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 > sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 > sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 > sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 > sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 > sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 > sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb > sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 > sdhci_pci0-slot0: =========================================== > sdhci_pci0-slot0: Controller timeout > sdhci_pci0-slot0: ============== REGISTER DUMP ============== > sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 > sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 > sdhci_pci0-slot0: Argument: 0x000001aa | Trn mode: 0x00000000 > sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 > sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 > sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 > sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 > sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb > sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 > sdhci_pci0-slot0: =========================================== > sdhci_pci0-slot0: Controller timeout > sdhci_pci0-slot0: ============== REGISTER DUMP ============== > sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 > sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 > sdhci_pci0-slot0: Argument: 0x000001aa | Trn mode: 0x00000000 > sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 > sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 > sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 > sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 > sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb > sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 > sdhci_pci0-slot0: =========================================== > sdhci_pci0-slot0: Controller timeout > sdhci_pci0-slot0: ============== REGISTER DUMP ============== > sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 > sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 > sdhci_pci0-slot0: Argument: 0x000001aa | Trn mode: 0x00000000 > sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 > sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 > sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 > sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 > sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb > sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 > sdhci_pci0-slot0: =========================================== > sdhci_pci0-slot0: Controller timeout > sdhci_pci0-slot0: ============== REGISTER DUMP ============== > sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 > sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 > sdhci_pci0-slot0: Argument: 0x000001aa | Trn mode: 0x00000000 > sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 > sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 > sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 > sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 > sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb > sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 > sdhci_pci0-slot0: =========================================== > sdhci_pci0-slot0: Controller timeout > sdhci_pci0-slot0: ============== REGISTER DUMP ============== > sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 > sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 > sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 > sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 > sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 > sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 > sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 > sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb > sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 > sdhci_pci0-slot0: =========================================== > sdhci_pci0-slot0: Controller timeout > sdhci_pci0-slot0: ============== REGISTER DUMP ============== > sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 > sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 > sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 > sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 > sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 > sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 > sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 > sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb > sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 > sdhci_pci0-slot0: =========================================== > sdhci_pci0-slot0: Controller timeout > sdhci_pci0-slot0: ============== REGISTER DUMP ============== > sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 > sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 > sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 > sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 > sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 > sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 > sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 > sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb > sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 > sdhci_pci0-slot0: =========================================== > sdhci_pci0-slot0: Controller timeout > sdhci_pci0-slot0: ============== REGISTER DUMP ============== > sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 > sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 > sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 > sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 > sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 > sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 > sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 > sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb > sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 > sdhci_pci0-slot0: =========================================== > sdhci_pci0-slot0: Controller timeout > sdhci_pci0-slot0: ============== REGISTER DUMP ============== > sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 > sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 > sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 > sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 > sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 > sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 > sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 > sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb > sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 > sdhci_pci0-slot0: =========================================== > sdhci_pci0-slot0: Controller timeout > sdhci_pci0-slot0: ============== REGISTER DUMP ============== > sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 > sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 > sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 > sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 > sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 > sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 > sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 > sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb > sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 > sdhci_pci0-slot0: =========================================== > sdhci_pci0-slot0: Controller timeout > sdhci_pci0-slot0: ============== REGISTER DUMP ============== > sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 > sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 > sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 > sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 > sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 > sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 > sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 > sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb > sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 > sdhci_pci0-slot0: =========================================== > sdhci_pci0-slot0: Controller timeout > sdhci_pci0-slot0: ============== REGISTER DUMP ============== > sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 > sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 > sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 > sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 > sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 > sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 > sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 > sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb > sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 > sdhci_pci0-slot0: =========================================== > mmc0: No compatible cards found on bus > hdacc0: at cad 0 on hdac0 > hdaa0: at nid 1 on hdacc0 > hdaa0: hdaa_audio_as_parse: Duplicate pin 0 (23) in association 1! > Disabling association. > pcm0: at nid 33 and 24 on hdaa0 > hdacc1: at cad 2 on hdac0 > hdaa1: at nid 1 on hdacc1 > pcm1: at nid 3 on hdaa1 > SMP: AP CPU #1 Launched! > SMP: AP CPU #2 Launched! > SMP: AP CPU #3 Launched! > Timecounter "TSC" frequency 1608052518 Hz quality 1000 > Trying to mount root from zfs:zroot/ROOT/default []... > uhid0: on usbus0 > uhid1: on usbus0 > ubt0: 3> on usbus0 > ums0: on usbus0 > ums0: 16 buttons and [XYZT] coordinates ID=0 > WARNING: attempt to domain_add(bluetooth) after domainfinalize() > WARNING: attempt to domain_add(netgraph) after domainfinalize() > > The pciconf entry for sdhci are: > sdhci_pci0@pci0:0:30:4: class=0x080501 card=0x72708086 chip=0x9d2b8086 > rev=0x21 hdr=0x00 > vendor = 'Intel Corporation' > class = base peripheral > subclass = SD host controller > sdhci_pci1@pci0:0:30:6: class=0x080501 card=0x72708086 chip=0x9d2d8086 > rev=0x21 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Sunrise Point-LP Secure Digital IO Controller' > class = base peripheral > subclass = SD host controller > > If someone wants to take a crack at it I can test any changes. > Otherwise I'll just take it out of the kernel. > > Thanks. > -M > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Tue Aug 9 06:19:53 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B1246BB3BAB for ; Tue, 9 Aug 2016 06:19:53 +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 A36621604; Tue, 9 Aug 2016 06:19:53 +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 CB82A112; Tue, 9 Aug 2016 06:19:53 +0000 (UTC) Date: Tue, 9 Aug 2016 06:19:53 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <1366485467.11.1470723593717.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <420125077.9.1470705425399.JavaMail.jenkins@jenkins-9.freebsd.org> References: <420125077.9.1470705425399.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD #555 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 09 Aug 2016 06:19:53 -0000 See From owner-freebsd-current@freebsd.org Tue Aug 9 06:37:03 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3A419BB3EE3; Tue, 9 Aug 2016 06:37:03 +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 ECBEB1CE8; Tue, 9 Aug 2016 06:37:02 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1bX0eq-001ejG-8P>; Tue, 09 Aug 2016 08:37:00 +0200 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=freyja.zeit4.iv.bundesimmobilien.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1bX0ep-001Rub-VE>; Tue, 09 Aug 2016 08:37:00 +0200 Date: Tue, 9 Aug 2016 08:36:54 +0200 From: "O. Hartmann" To: Ian Lepore Cc: Warner Losh , Kevin Oberman , FreeBSD CURRENT , "freebsd-usb@FreeBSD.org\" Subject: Re: Digi Watchport/T temperature sensor as /dev/ttyU Message-ID: <20160809083654.25d2ac67@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <1469387555.84197.48.camel@freebsd.org> References: <20160722183556.2fc39fd7.ohartman@zedat.fu-berlin.de> <1469206374.84197.14.camel@freebsd.org> <20160723220430.34ce02fe.ohartman@zedat.fu-berlin.de> <1469306951.84197.31.camel@freebsd.org> <20160724080330.3a27e875.ohartman@zedat.fu-berlin.de> <20160724083859.4c0dd392@ernst.home> <20160724105134.184f0b7f.ohartman@zedat.fu-berlin.de> <1469379334.84197.40.camel@freebsd.org> <1469387555.84197.48.camel@freebsd.org> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 87.138.105.249 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 09 Aug 2016 06:37:03 -0000 On Sun, 24 Jul 2016 13:12:35 -0600 Ian Lepore wrote: > On Sun, 2016-07-24 at 12:52 -0600, Warner Losh wrote: > > On Sun, Jul 24, 2016 at 12:42 PM, Kevin Oberman > > wrote: > > > There are several different USB serial drivers. Off-hand I see > > > ubser, ubsa, > > > uchcom, ucom, ucycom, uftdi, ubgensa, umcs, umct, umoscom, uplcom, > > > usb_serial, uslcom, and uvscom. Whether any of these will support > > > the TI > > > chip, I can't say. Most have man pages, but a few, as has been > > > noted, are > > > lacking one. > > > > I tried to automate discovery of these things. However, the only way > > you can really know for sure about the TI chip is to read it's > > datasheet > > and compare that with extant drivers. It's actually easier than it > > sounds. > > > > I've often thought of unification of the TTY USB drivers, since they > > are > > most (but not all) based on the standard plus extra bits. > > > > Warner > > To reiterate: we do not have a driver for TI 5052 chips. > > It's not much like other usb-serial chips. In fact it's not strictly a > usb-serial chip, it's a multifunction chip that includes a software > -controllable usb hub, 2 serial ports, gpio, an i2c bus master, an MCU > interface, a multichannel DMA controller, and apparently even has the > ability to download your own 8052-compatible microcontroller code into > the 5052 and have it take over from the built-in rom code. > > It would be reasonable enough to write a driver that initially > supported only the uart part of the chip. > > -- Ian Now, that I know that I can not use any of our plenty Digi Watchport/T sensors with FreeBSD, I'm looking for a cheap alternative of sensor, prefereably being capable of taking temperature and humidity and being accessed as easy as a serial terminal - as the Digi Watchport/T does with Linux. I still have a "resistance" changing the OS of our infrastructure to Linux due to ZFS, but the very good support of drivers with the Linux OS is tempting ... From owner-freebsd-current@freebsd.org Tue Aug 9 06:58:19 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 11F59BB3647 for ; Tue, 9 Aug 2016 06:58:19 +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 CAC1E1A41 for ; Tue, 9 Aug 2016 06:58:18 +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) for freebsd-current@freebsd.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1bX0zQ-001jhM-V5>; Tue, 09 Aug 2016 08:58:16 +0200 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=freyja.zeit4.iv.bundesimmobilien.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1bX0zQ-001TSj-Lu>; Tue, 09 Aug 2016 08:58:16 +0200 Date: Tue, 9 Aug 2016 08:58:09 +0200 From: "O. Hartmann" To: freebsd-current Subject: r303869: dmesg: sysctl kern.msgbuf: Operation not permitted Message-ID: <20160809085809.621667ef@freyja.zeit4.iv.bundesimmobilien.de> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 87.138.105.249 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 09 Aug 2016 06:58:19 -0000 On recent 12.0-CURRENT FreeBSD 12.0-CURRENT #36 r303869, I see apart from serious performance issues and stuck ZFS rsync synchronisations this on the console, when typing "dmesg" in theshell from a user which is member of group "wheel": dmesg: sysctl kern.msgbuf: Operation not permitted Is this a feature or a bug? Trying to sync a poudriere built ports collection to a automounted ZFS filesystem on a remote server, the rsync gets stuck very quickly, stopping and never resume. I did the last synchronisation on July, 20th with CURRENT without problems the very same way. Kind regards, Oliver From owner-freebsd-current@freebsd.org Tue Aug 9 07:53:15 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3F69FBB30F3 for ; Tue, 9 Aug 2016 07:53:15 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [81.2.117.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D8C7715E2 for ; Tue, 9 Aug 2016 07:53:14 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from liminal.local (liminal.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3636:3bff:fed4:b0d6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: m.seaman@infracaninophile.co.uk) by smtp.infracaninophile.co.uk (Postfix) with ESMTPSA id 1A98EC9E9 for ; Tue, 9 Aug 2016 07:53:11 +0000 (UTC) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=FreeBSD.org Authentication-Results: smtp.infracaninophile.co.uk/1A98EC9E9; dkim=none; dkim-atps=neutral Subject: Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0 To: freebsd-current@freebsd.org References: From: Matthew Seaman Message-ID: Date: Tue, 9 Aug 2016 08:53:06 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lHprRe2L34EuRuPj3ucTe7aeCeEn9miNv" X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on smtp.infracaninophile.co.uk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 09 Aug 2016 07:53:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lHprRe2L34EuRuPj3ucTe7aeCeEn9miNv Content-Type: multipart/mixed; boundary="kOcHjxRo1apcHqrgefAOlu7s1P0gVGrxi" From: Matthew Seaman To: freebsd-current@freebsd.org Message-ID: Subject: Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0 References: In-Reply-To: --kOcHjxRo1apcHqrgefAOlu7s1P0gVGrxi Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 09/08/2016 03:23, Jeffrey Bouquet wrote: > Will/could there be some kind of UPDATING announcement re which files > explicitly to switch out/remove/replace/checkfor etc the deprecated > lines and precisely the steps to replace with new or some other > suitable action? Action required for both the sshd and client? > Subdirectories involved? etc... Unclear here, but I don't use SSH > hardly yet... despite having bought the book. As far as managing sshd on your own systems, you should not need to make massive changes to the /etc/ssh/sshd_config when upgrading to 11.0 or 12.0 -- the normal mergemaster or etcmerge procedures will probably cover things. On an upgraded system, you will have still have /etc/ssh/ssh_host_dsa_key{,.pub} but these will be ignored by sshd and would not be generated on a new machine. Optionally, you may choose to replace /etc/ssh/ssh_host_rsa_key{,.pub} if that key has a short bit-length. You may find that you get 'Key mismatch' warnings -- ssh may use a different type of host key on connection to a machine after this update, and it will alert you if this does not match what it has in ~/ssh/known-hosts from previous connections. If you're satisfied that the warning is explained by this configuration change, then you can edit known-hosts to eliminate the warning message. As a ssh user, you will need to review the ssh keys you are using, and what is listed in the ~/.ssh/authorized_keys files of any machines you want to login to. You can add a new key of and alternate type in parallel to your existing keys, and load multiple keys into ssh-agent -- this allows you to phase in a new key with minimal risk that you will lock yourself out of a remote machine. Doing this *before* you upgrade any systems is just common sense. The default configuration of sshd provided with FreeBSD provides good security and a good level of interoperability with other ssh implementations, and you can use it with confidence. Depending on local requirements you may want to impose a stricter policy. In that case, the following references will be interesting to you: https://wiki.mozilla.org/Security/Guidelines/OpenSSH https://stribika.github.io/2015/01/04/secure-secure-shell.html These are, however, rather more than most people will really find necessa= ry. Cheers, Matthew --kOcHjxRo1apcHqrgefAOlu7s1P0gVGrxi-- --lHprRe2L34EuRuPj3ucTe7aeCeEn9miNv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQJ8BAEBCgBmBQJXqYviXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkATPH0P/RkHBxhZPfczqB3vDDI5Pyfy jihquESPDkXafKNvo11//1Q8zMPmk6J5AtFlx0B8OO0MfXWGHLCoZwNWMFu5GOmp FDkYx09RBVYFqHfATGVO352FTWcJQcDMga5eL7njMpMpqJa7+5fHZdBBRlqucs6p H1JDWBqKAzXxbvQVZ1UPWWcNGnQdV9yqlenBA6BO8FYIQO3lozwyStb7m/VKJxH+ kSbWjQnnOymBm2XKzLDOIYMoFDmoLM3cKcYseW3hmM/hG+r36s/e0MCf39F8TSn0 5pA2fOJBPUOhtpu12nN+7iX4TSKeZRK9rXwdVTjwFmwobLVzGhEYdLpyiXmYauqW 2ty3c4kqWJkJdumiJyVgZnkewk2xI8bhTaz99mDThQyw98HCdK8r+RBB5lgM3PIQ 3RdeFjZSALChY9xBfT/LrlkJ5HKKziuEBaShvHvtkolvbz7lO+NxHmtbCXst9OD/ lkE+7844j4aZMcN6WVpOUYgSq9Q0Kob7BUjKLRHhKsalNWH1eFF+3jexHBHTwKlU rS1lMRXhhlQz6MaV9xt357L1uq9fMiOLrLTMLuKQw7hoePhe7fPR7AZOUkJBJlwj fSjjfTbTuKBmO/RHYj0nzwsiBP9mqFvKSAdGhlWrDPW6KUCRGW3pmCt8B/+1jzwX gerbDF7wVFiaHBF+bnhS =6Hy6 -----END PGP SIGNATURE----- --lHprRe2L34EuRuPj3ucTe7aeCeEn9miNv-- From owner-freebsd-current@freebsd.org Tue Aug 9 08:55:36 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 780DCBB234D for ; Tue, 9 Aug 2016 08:55:36 +0000 (UTC) (envelope-from prvs=022e014eb=roger.pau@citrix.com) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "DigiCert SHA2 Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2BAAD130D for ; Tue, 9 Aug 2016 08:55:35 +0000 (UTC) (envelope-from prvs=022e014eb=roger.pau@citrix.com) X-IronPort-AV: E=Sophos;i="5.28,494,1464652800"; d="scan'208";a="378570497" Date: Tue, 9 Aug 2016 10:55:32 +0200 From: Roger Pau =?iso-8859-1?Q?Monn=E9?= To: Miguel C CC: freebsd-current Subject: Re: FreeBSD 11 - BETA-1 Xen DOMU loses network when jail (VIMAGE) starts Message-ID: <20160809085523.kow2qbpirzppytv6@mac> References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.2-neo (2016-06-11) X-DLP: MIA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 09 Aug 2016 08:55:36 -0000 On Sat, Jul 23, 2016 at 08:46:49PM +0100, Miguel C wrote: > Just as a note using netgraph (with jng script as a workaround) works.... > > Also manually creating a bridge in the domu and adding xn0 as a member > makes this fail.... so the issue is indeed related to the bridge. > > I'll open a PR later in case someone want to look into it, but I'm happy it > works with netgraph. I seem to be able to use xn* interfaces with bridges without problems: xn0: flags=8943 metric 0 mtu 1500 options=3 ether 00:16:3e:74:3d:76 nd6 options=29 media: Ethernet manual status: active bridge0: flags=8843 metric 0 mtu 1500 ether 02:77:3d:4a:18:00 inet 172.16.1.140 netmask 0xffffff00 broadcast 172.16.1.255 nd6 options=9 groups: bridge id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: xn0 flags=143 ifmaxaddr 0 port 2 priority 128 path cost 2000000 Is this a GENERIC kernel or are you using some custom configuration/patches? Can you provide some more information about how to reproduce this? Roger. From owner-freebsd-current@freebsd.org Tue Aug 9 09:12:36 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DE751BB2C74 for ; Tue, 9 Aug 2016 09:12:36 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6D92A1F0E; Tue, 9 Aug 2016 09:12:36 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u799CUX3056895 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 9 Aug 2016 12:12:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u799CUX3056895 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u799CUe5056894; Tue, 9 Aug 2016 12:12:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 9 Aug 2016 12:12:30 +0300 From: Konstantin Belousov To: Don Lewis Cc: freebsd-current@freebsd.org, jhb@freebsd.org Subject: Re: kernel panic caused by virtualbox(?) Message-ID: <20160809091230.GQ83214@kib.kiev.ua> References: <20160808183743.GL83214@kib.kiev.ua> <201608082344.u78NiK1V030408@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201608082344.u78NiK1V030408@gw.catspoiler.org> User-Agent: Mutt/1.6.1 (2016-04-27) 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.22 Precedence: 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, 09 Aug 2016 09:12:37 -0000 On Mon, Aug 08, 2016 at 04:44:20PM -0700, Don Lewis wrote: > On 8 Aug, Konstantin Belousov wrote: > > On Mon, Aug 08, 2016 at 10:22:44AM -0700, John Baldwin wrote: > >> On Thursday, August 04, 2016 05:10:29 PM Don Lewis wrote: > >> > Reposted to -current to get some more eyes on this ... > >> > > >> > I just got a kernel panic when I started up a CentOS 7 VM in virtualbox. > >> > The host is: > >> > FreeBSD 12.0-CURRENT #17 r302500 GENERIC amd64 > >> > The virtualbox version is: > >> > virtualbox-ose-5.0.26 > >> > virtualbox-ose-kmod-5.0.26_1 > >> > > >> > The panic message is: > >> > > >> > panic: Unregistered use of FPU in kernel > >> > cpuid = 1 > >> > KDB: stack backtrace: > >> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe085a55d030 > >> > vpanic() at vpanic+0x182/frame 0xfffffe085a55d0b0 > >> > kassert_panic() at kassert_panic+0x126/frame 0xfffffe085a55d120 > >> > trap() at trap+0x7ae/frame 0xfffffe085a55d330 > >> > calltrap() at calltrap+0x8/frame 0xfffffe085a55d330 > >> > --- trap 0x16, rip = 0xffffffff827dd3a9, rsp = 0xfffffe085a55d408, rbp = 0xfffffe085a55d430 --- > >> > g_pLogger() at 0xffffffff827dd3a9/frame 0xfffffe085a55d430 > >> > g_pLogger() at 0xffffffff8274e5c7/frame 0x3 > >> > KDB: enter: panic > >> > > >> > Since g_pLogger is a symbol in vboxdrv.ko, it looks like virtualbox is > >> > the trigger. > >> > > >> > There are no symbols for the virtualbox kmods, possibly because I > >> > installed them as an upgrade using packages (built with the same source > >> > tree version) instead of by using PORTS_MODULES in make.conf, so ports > >> > kgdb didn't have anything useful to say about what happened before the > >> > trap. > >> > > >> > This panic is very repeatable. I just got another one when starting the > >> > same VM., but this time the two calls before the trap were > >> > null_bug_bypass(). Hmn, that symbol is in nullfs ... > >> > > >> > I don't see this with a Windows 7 VM. > >> > > >> > All of the virtualbox kmod files are compiled with -mno-mmx -mno-sse > >> > -msoft-float -mno-aes -mno-avx > > Your disassemble listed fxrstor instruction that failing, or did I > > mis-remembered ? This is most likely some context switch code, either > > by virtual machine or erronously executed guest code. It is not a > > spontaneous use of FPU, but more likely something different. Can you > > confirm ? > > > > In either case, I do not remember any KBI changes around PCB layout or > > fpu_enter() KPI recently. > > > >> > >> I suspect head packages are quite likely built against the a "wrong" KBI > >> and are too fragile to use for kmods vs compiling from ports. :-/ I would > >> try a built-from-ports kmod to see if the panics go away. > > > > FWIW, I will commit the following change shortly. Since third-party > > modules break the invariant, either due to bugs (ndis wrappers) or > > possibly due to KBI breakage, it is worth to have the detection enabled > > for production kernels. > > Interesting ... I tried running virtualbox on recent 10.3-STABLE with a > GENERIC kernel and the guest seemed to operate properly. Then I enabled > INVARIANTS and got the panic. I suspect that is why nobody has stumbled > across this before. > This is yet another reason to promote KASSERT to the full panic. I expect that the vbox source lacks fpu_kern_enter() calls around the FPU state restoration. From owner-freebsd-current@freebsd.org Tue Aug 9 11:13:17 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1F347BB37C3 for ; Tue, 9 Aug 2016 11:13:17 +0000 (UTC) (envelope-from miguelmclara@gmail.com) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 A0D331FA5 for ; Tue, 9 Aug 2016 11:13:16 +0000 (UTC) (envelope-from miguelmclara@gmail.com) Received: by mail-wm0-x234.google.com with SMTP id o80so27247135wme.1 for ; Tue, 09 Aug 2016 04:13:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PF6oiBAgJI99e2LMuTp89xWhbS8S0lmDfsaAqbjUSFA=; b=AcfVCJeOrlA0RVK1Lrd9EhyE8PwkphevpdMbOUlRLaDmxUgHFlwsakw2IOYw1aw8Pe G1f5tg0H1AQYI7i9IsCXi0faNbdhbORs8D18jgpdg5Pdop2wfs66Wun4UNQneSL9QL4l E9TqbeyA7Tg+wivbZRcQzwcGXqj38HCbxKfCYD+wY+q85JPCmoL4ei9jjEM83yA0hlCQ kI4jvyFJb/n66qUMXLQ44bdXsbx+M9m6LeYcD0sYanmGeKTIS+Dedq3OejEyvFHaqUqB g18nBOpLmEVQV9l2Bgnh99OA4KYHR5tVRyHzEjRXwhqvSuBdwUnvzKzTW39jEkF/CoqK Vf5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PF6oiBAgJI99e2LMuTp89xWhbS8S0lmDfsaAqbjUSFA=; b=h5e39w4dbWBgnEEOsnZu6BR11Hzi9moX/nbmqk8T8/4SgoPxO/hE3HI+vXNC8DDoHV CtePIDqmm9H0pkxMz+EfWVemZgUv65ktzROJdFwd3fn7Q36fp0Hjha0XpOkDJQ3DKsjG 6CuM6ZKp8nbnb3SSfLUKTxcd611DeYmEW0vuRV16WRdxVVf3UPDKec9MywsFj6R332te NtL/OucUGzAwkMGbTh3yVDyf3RIYHCFP6NDWR2M9qPjeSRVqmBOt3xnXP49ciJKQX9Sd GyeRtgZXdtBez1M8aOHlq/manyI1PoYi6Ls3nVhfJSUMu+GjiRqekMnOl1f+0ilIw8QA H/Hw== X-Gm-Message-State: AEkoouuzs7B9mjc5L/2qLBTj6eswgzir344xo0BKP1QR5yJx4EUresyjmnXLDcdwwgfs780ixH0uJ0w0YjnjXw== X-Received: by 10.28.25.135 with SMTP id 129mr19724921wmz.59.1470741195088; Tue, 09 Aug 2016 04:13:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.198.201 with HTTP; Tue, 9 Aug 2016 04:12:34 -0700 (PDT) In-Reply-To: <20160809085523.kow2qbpirzppytv6@mac> References: <20160809085523.kow2qbpirzppytv6@mac> From: Miguel C Date: Tue, 9 Aug 2016 12:12:34 +0100 Message-ID: Subject: Re: FreeBSD 11 - BETA-1 Xen DOMU loses network when jail (VIMAGE) starts To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: freebsd-current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 09 Aug 2016 11:13:17 -0000 Melhores Cumprimentos // Best Regards ----------------------------------------------- *Miguel Clara* *IT - Sys Admin & Developer* On Tue, Aug 9, 2016 at 9:55 AM, Roger Pau Monn=C3=A9 wrote: > On Sat, Jul 23, 2016 at 08:46:49PM +0100, Miguel C wrote: > > Just as a note using netgraph (with jng script as a workaround) works..= .. > > > > Also manually creating a bridge in the domu and adding xn0 as a member > > makes this fail.... so the issue is indeed related to the bridge. > > > > I'll open a PR later in case someone want to look into it, but I'm happ= y > it > > works with netgraph. > > I seem to be able to use xn* interfaces with bridges without problems: > > xn0: flags=3D8943 metric = 0 > mtu 1500 > options=3D3 > ether 00:16:3e:74:3d:76 > nd6 options=3D29 > media: Ethernet manual > status: active > bridge0: flags=3D8843 metric 0 mt= u > 1500 > ether 02:77:3d:4a:18:00 > inet 172.16.1.140 netmask 0xffffff00 broadcast 172.16.1.255 > nd6 options=3D9 > groups: bridge > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: xn0 flags=3D143 > ifmaxaddr 0 port 2 priority 128 path cost 2000000 > > Is this a GENERIC kernel or are you using some custom > configuration/patches? > Can you provide some more information about how to reproduce this? > > GENERIC + VIMAGE, but that's just it, no other custom changes or patches. Note however that this is under a NetbBSD Dom0, and I see the "vifXX" interface disappear in the Dom0 side when the bridge is create on FreeBSD DomU. I'm actually happy with netgraph, although I've never played with it, and seems more complex, the script provide in /share/examples is perfect to use with "jail.conf" and pf seems happy in FreeBSD-11 (which is not CURRENT, should we move this to a different mailing list!?) too, no panics so far. I suspect the main issue, since it works fine for you is the fact that this is in a NetBSD Dom0. > Roger. > From owner-freebsd-current@freebsd.org Tue Aug 9 13:14:30 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CE7E0BB3361 for ; Tue, 9 Aug 2016 13:14:30 +0000 (UTC) (envelope-from jeffrey.e.pieper@intel.com) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mx1.freebsd.org (Postfix) with ESMTP id A10211992; Tue, 9 Aug 2016 13:14:30 +0000 (UTC) (envelope-from jeffrey.e.pieper@intel.com) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP; 09 Aug 2016 06:14:29 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,494,1464678000"; d="scan'208";a="1037896899" Received: from orsmsx102.amr.corp.intel.com ([10.22.225.129]) by fmsmga002.fm.intel.com with ESMTP; 09 Aug 2016 06:14:28 -0700 Received: from orsmsx156.amr.corp.intel.com (10.22.240.22) by ORSMSX102.amr.corp.intel.com (10.22.225.129) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 9 Aug 2016 06:14:28 -0700 Received: from orsmsx111.amr.corp.intel.com ([169.254.12.25]) by ORSMSX156.amr.corp.intel.com ([169.254.8.236]) with mapi id 14.03.0248.002; Tue, 9 Aug 2016 06:14:28 -0700 From: "Pieper, Jeffrey E" To: "O. Hartmann" , "K. Macy" CC: FreeBSD Current Subject: RE: lengthy sdhci timeouts on KBL-Y tester Thread-Topic: lengthy sdhci timeouts on KBL-Y tester Thread-Index: AQHR8d+K8oWwb7WOWkCRPHmy2uhjyaBAhnAAgAAVCpA= Date: Tue, 9 Aug 2016 13:14:27 +0000 Message-ID: <2A35EA60C3C77D438915767F458D656883915ABF@ORSMSX111.amr.corp.intel.com> References: <20160809065642.1feb4299@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <20160809065642.1feb4299@freyja.zeit4.iv.bundesimmobilien.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNjllYWIwZmQtZWZhNS00M2UyLTk1ODEtMzYwOTViNGU2ODAyIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IjdKRHJFMURTV1ZOc05cLzc5aUFPNUg0YnJ3SlRXUDRQMkcrWjRSdzZ0RUo0PSJ9 x-ctpclassification: CTP_IC x-originating-ip: [10.22.254.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 09 Aug 2016 13:14:31 -0000 This is pre-production hardware and this type of behavior is generally expe= cted due the hardware debugging that is enabled in both the HW itself and U= EFI/IFWI. Thanks, Jeff -----Original Message----- From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd-current@freeb= sd.org] On Behalf Of O. Hartmann Sent: Monday, August 08, 2016 9:57 PM To: K. Macy Cc: FreeBSD Current Subject: Re: lengthy sdhci timeouts on KBL-Y tester On Mon, 8 Aug 2016 18:43:42 -0700 "K. Macy" wrote: > I have a KBL-Y "Software Development Platform" for purposes of getting > the i915 KMS working on that system on FreeBSD. I've just installed 11 > BETA4. sdhci timeouts add several minutes to boot time. The dmesg > output follows: [...] A very similar situation here with a Intel NUC5CPYH. I circumvent the probl= em by setting in /boot/device.hints "hint.sdhci_pci.0.disabled=3D1" as a workaround.=20 [...] > Copyright (c) 1992-2016 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 11.0-BETA4 #0 r303759: Fri Aug 5 02:26:47 UTC 2016 > root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 > FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on > LLVM 3.8.0) > VT(efifb): resolution 2560x1440 > CPU: Intel(R) Core(TM) m5-7Y54 CPU @ 1.20GHz (1608.05-MHz K8-class CPU) > Origin=3D"GenuineIntel" Id=3D0x806e9 Family=3D0x6 Model=3D0x8e Step= ping=3D9 > Features=3D0xbfebfbff > Features2=3D0x7ffafbbf > AMD Features=3D0x2c100800 > AMD Features2=3D0x121 > Structured Extended > Features=3D0x29c67af > XSAVE Features=3D0xf > VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID > TSC: P-state invariant, performance statistics > real memory =3D 8589934592 (8192 MB) > avail memory =3D 8160288768 (7782 MB) > Event timer "LAPIC" quality 600 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads > random: unblocking device. > ioapic0 irqs 0-119 on motherboard > random: entropy device external interface > kbd1 at kbdmux0 > netmap: loaded module > module_register_init: MOD_LOAD (vesa, 0xffffffff81018940, 0) error 19 > random: registering fast source Intel Secure Key RNG > random: fast provider: "Intel Secure Key RNG" > cryptosoft0: on motherboard > acpi0: on motherboard > acpi0: Power Button (fixed) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3D3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] > (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3D3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] > (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3D3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] > (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3D3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] > (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3D3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] > (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3D3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] > (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3D3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] > (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3D3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] > (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3D3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] > (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3D3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] > (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3D3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] > (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3D3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] > (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3D3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] > (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3D3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] > (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3D3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] > (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3D3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] > (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3D3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] > (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3D3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] > (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3D3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] > (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3D3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] > (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3D3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] > (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3D3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] > (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3D3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] > (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3D3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] > (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3D3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] > (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3D3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] > (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3D3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xfffff8000641a4c0), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] > (Node 0xfffff8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xfffff800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3D3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] (Node 0xfffff80006422480), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT2._STA] > (Node 0xfffff80006422480), AE_NOT_EXIST (20160527/uteval-111) > cpu0: on acpi0 > ACPI Error: Mutex [0x0] is not acquired, cannot release (20160527/utmutex= -386) > ACPI Error: Could not release AML Interpreter mutex (20160527/exutils-147= ) > ACPI Error: Mutex [0x0] is not acquired, cannot release (20160527/utmutex= -386) > ACPI Error: Could not release AML Interpreter mutex (20160527/exutils-147= ) > cpu1: on acpi0 > ACPI Error: Mutex [0x0] is not acquired, cannot release (20160527/utmutex= -386) > ACPI Error: Could not release AML Interpreter mutex (20160527/exutils-147= ) > ACPI Error: Mutex [0x0] is not acquired, cannot release (20160527/utmutex= -386) > ACPI Error: Could not release AML Interpreter mutex (20160527/exutils-147= ) > cpu2: on acpi0 > cpu3: on acpi0 > hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > Timecounter "HPET" frequency 24000000 Hz quality 950 > Event timer "HPET" frequency 24000000 Hz quality 550 > Event timer "HPET1" frequency 24000000 Hz quality 440 > Event timer "HPET2" frequency 24000000 Hz quality 440 > Event timer "HPET3" frequency 24000000 Hz quality 440 > Event timer "HPET4" frequency 24000000 Hz quality 440 > atrtc0: port 0x70-0x77 irq 8 on acpi0 > atrtc0: Warning: Couldn't map I/O. > Event timer "RTC" frequency 32768 Hz quality 0 > attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0 > acpi_ec0: port 0x62,0x66 on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > vgapci0: port 0x3000-0x303f mem > 0xb0000000-0xb0ffffff,0xa0000000-0xafffffff at device 2.0 on pci0 > vgapci0: Boot video device > xhci0: mem 0xb1320000-0xb132ffff > at device 20.0 on pci0 > xhci0: 32 bytes context size, 64-bit DMA > usbus0 on xhci0 > pci0: at device 20.1 (no driver attached) > pci0: at device 22.0 (no driver attached) > ahci0: port > 0x3080-0x3087,0x3088-0x308b,0x3060-0x307f mem > 0xb1350000-0xb1351fff,0xb135d000-0xb135d0ff,0xb135b000-0xb135b7ff at > device 23.0 on pci0 > ahci0: AHCI v1.31 with 1 6Gbps ports, Port Multiplier not supported > ahcich0: at channel 0 on ahci0 > pcib1: at device 29.0 on pci0 > pci1: on pcib1 > pci1: at device 0.0 (no driver attached) > sdhci_pci0: mem 0xb1359000-0xb1359fff at device 30.4 on = pci0 > sdhci_pci0: 1 slot(s) allocated > mmc0: on sdhci_pci0 > sdhci_pci1: mem 0xb135a000-0xb135afff at device 30.6 on = pci0 > sdhci_pci1: 1 slot(s) allocated > isab0: at device 31.0 on pci0 > isa0: on isab0 > pci0: at device 31.2 (no driver attached) > hdac0: mem > 0xb1348000-0xb134bfff,0xb1330000-0xb133ffff at device 31.3 on pci0 > em0: mem > 0xb1300000-0xb131ffff at device 31.6 on pci0 > em0: Using an MSI interrupt > em0: Ethernet address: 90:49:fa:02:6b:8b > em0: netmap queues/slots: TX 1/1024, RX 1/1024 > acpi_acad0: on acpi0 > acpi_button0: on acpi0 > acpi_button1: on acpi0 > acpi_tz0: on acpi0 > acpi_tz1: on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > battery0: on acpi0 > battery1: on acpi0 > battery2: on acpi0 > acpi_lid0: on acpi0 > ppc1: cannot reserve I/O port range > ppc0: cannot reserve I/O port range > uart0: at port 0x3f8 irq 4 > flags 0x10 on isa0 > est0: on cpu0 > est1: on cpu1 > est2: on cpu2 > est3: on cpu3 > usbus0: 5.0Gbps Super Speed USB v3.0 > ZFS filesystem version: 5 > ZFS storage pool version: features support (5000) > Timecounters tick every 1.000 msec > nvme cam probe device init > ugen0.1: <0x8086> at usbus0 > uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ACS-3 ATA SATA 3.x device > ada0: Serial Number CVTR6233050T480EGN > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 457862MB (937703088 512 byte sectors) > ada0: quirks=3D0x1<4K> > uhub0: 18 ports with 18 removable, self powered > ugen0.2: at usbus0 > umass0: 1> on usbus0 =20 > umass0: SCSI over Bulk-Only; quirks =3D 0x8100 > umass0:1:0: Attached to scbus1 > da0 at umass-sim0 bus 0 scbus1 target 0 lun 0 > da0: Removable Direct Access SPC-4 SCSI device > da0: Serial Number AA63032200000027 > da0: 40.000MB/s transfers > da0: 31704MB (64929792 512 byte sectors) > da0: quirks=3D0x13 > GEOM: da0: the secondary GPT header is not in the last LBA. > ugen0.3: at usbus0 > ukbd0: on usbus0 > kbd2 at ukbd0 > ugen0.4: at usbus0 > ugen0.2: at usbus0 (disconnected) > umass0: at uhub0, port 2, addr 1 (disconnected) > da0 at umass-sim0 bus 0 scbus1 target 0 lun 0 > da0: s/n AA63032200000027 detached > (da0:umass-sim0:0:0:0): Periph destroyed > sdhci_pci0-slot0: Controller timeout > sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER DUM= P =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 > sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 > sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 > sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 > sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 > sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 > sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 > sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb > sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 > sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > ugen0.2: at usbus0 > sdhci_pci0-slot0: Controller timeout > sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER DUM= P =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 > sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 > sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 > sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 > sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 > sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 > sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 > sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb > sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 > sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_pci0-slot0: Controller timeout > sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER DUM= P =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 > sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 > sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 > sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 > sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 > sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 > sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 > sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb > sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 > sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_pci0-slot0: Controller timeout > sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER DUM= P =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 > sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 > sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 > sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 > sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 > sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 > sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 > sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb > sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 > sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_pci0-slot0: Controller timeout > sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER DUM= P =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 > sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 > sdhci_pci0-slot0: Argument: 0x000001aa | Trn mode: 0x00000000 > sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 > sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 > sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 > sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 > sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb > sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 > sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_pci0-slot0: Controller timeout > sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER DUM= P =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 > sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 > sdhci_pci0-slot0: Argument: 0x000001aa | Trn mode: 0x00000000 > sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 > sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 > sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 > sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 > sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb > sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 > sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_pci0-slot0: Controller timeout > sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER DUM= P =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 > sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 > sdhci_pci0-slot0: Argument: 0x000001aa | Trn mode: 0x00000000 > sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 > sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 > sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 > sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 > sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb > sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 > sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_pci0-slot0: Controller timeout > sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER DUM= P =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 > sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 > sdhci_pci0-slot0: Argument: 0x000001aa | Trn mode: 0x00000000 > sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 > sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 > sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 > sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 > sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb > sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 > sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_pci0-slot0: Controller timeout > sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER DUM= P =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 > sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 > sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 > sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 > sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 > sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 > sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 > sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb > sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 > sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_pci0-slot0: Controller timeout > sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER DUM= P =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 > sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 > sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 > sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 > sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 > sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 > sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 > sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb > sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 > sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_pci0-slot0: Controller timeout > sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER DUM= P =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 > sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 > sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 > sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 > sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 > sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 > sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 > sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb > sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 > sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_pci0-slot0: Controller timeout > sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER DUM= P =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 > sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 > sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 > sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 > sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 > sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 > sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 > sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb > sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 > sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_pci0-slot0: Controller timeout > sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER DUM= P =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 > sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 > sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 > sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 > sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 > sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 > sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 > sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb > sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 > sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_pci0-slot0: Controller timeout > sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER DUM= P =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 > sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 > sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 > sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 > sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 > sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 > sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 > sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb > sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 > sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_pci0-slot0: Controller timeout > sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER DUM= P =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 > sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 > sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 > sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 > sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 > sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 > sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 > sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb > sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 > sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_pci0-slot0: Controller timeout > sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER DUM= P =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00001002 > sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 > sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 > sdhci_pci0-slot0: Present: 0x1fff0001 | Host ctl: 0x00000001 > sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000080 > sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 > sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 > sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb > sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_pci0-slot0: Caps: 0x546ec881 | Max curr: 0x00000000 > sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > mmc0: No compatible cards found on bus > hdacc0: at cad 0 on hdac0 > hdaa0: at nid 1 on hdacc0 > hdaa0: hdaa_audio_as_parse: Duplicate pin 0 (23) in association 1! > Disabling association. > pcm0: at nid 33 and 24 on hdaa0 > hdacc1: at cad 2 on hdac0 > hdaa1: at nid 1 on hdacc1 > pcm1: at nid 3 on hdaa1 > SMP: AP CPU #1 Launched! > SMP: AP CPU #2 Launched! > SMP: AP CPU #3 Launched! > Timecounter "TSC" frequency 1608052518 Hz quality 1000 > Trying to mount root from zfs:zroot/ROOT/default []... > uhid0: on usbu= s0 > uhid1: on usbus0 > ubt0: 3> on usbus0 =20 > ums0: on usbus= 0 > ums0: 16 buttons and [XYZT] coordinates ID=3D0 > WARNING: attempt to domain_add(bluetooth) after domainfinalize() > WARNING: attempt to domain_add(netgraph) after domainfinalize() >=20 > The pciconf entry for sdhci are: > sdhci_pci0@pci0:0:30:4: class=3D0x080501 card=3D0x72708086 chip=3D0x9d2b8= 086 > rev=3D0x21 hdr=3D0x00 > vendor =3D 'Intel Corporation' > class =3D base peripheral > subclass =3D SD host controller > sdhci_pci1@pci0:0:30:6: class=3D0x080501 card=3D0x72708086 chip=3D0x9d2d8= 086 > rev=3D0x21 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D 'Sunrise Point-LP Secure Digital IO Controller' > class =3D base peripheral > subclass =3D SD host controller >=20 > If someone wants to take a crack at it I can test any changes. > Otherwise I'll just take it out of the kernel. >=20 > Thanks. > -M > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Tue Aug 9 13:16:50 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E451ABB342D; Tue, 9 Aug 2016 13:16:50 +0000 (UTC) (envelope-from prvs=022e014eb=roger.pau@citrix.com) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "DigiCert SHA2 Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5A0301B7B; Tue, 9 Aug 2016 13:16:49 +0000 (UTC) (envelope-from prvs=022e014eb=roger.pau@citrix.com) X-IronPort-AV: E=Sophos;i="5.28,494,1464652800"; d="scan'208";a="378600540" Date: Tue, 9 Aug 2016 13:32:41 +0200 From: Roger Pau =?iso-8859-1?Q?Monn=E9?= To: Miguel C CC: freebsd-current , Subject: Re: FreeBSD 11 - BETA-1 Xen DOMU loses network when jail (VIMAGE) starts Message-ID: <20160809113210.p2rkqmjnypg2iw5l@mac> References: <20160809085523.kow2qbpirzppytv6@mac> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.6.2-neo (2016-06-11) X-DLP: MIA1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 09 Aug 2016 13:16:51 -0000 On Tue, Aug 09, 2016 at 12:12:34PM +0100, Miguel C wrote: > Melhores Cumprimentos // Best Regards > ----------------------------------------------- > *Miguel Clara* > *IT - Sys Admin & Developer* > > On Tue, Aug 9, 2016 at 9:55 AM, Roger Pau Monné > wrote: > > > On Sat, Jul 23, 2016 at 08:46:49PM +0100, Miguel C wrote: > > > Just as a note using netgraph (with jng script as a workaround) works.... > > > > > > Also manually creating a bridge in the domu and adding xn0 as a member > > > makes this fail.... so the issue is indeed related to the bridge. > > > > > > I'll open a PR later in case someone want to look into it, but I'm happy > > it > > > works with netgraph. > > > > I seem to be able to use xn* interfaces with bridges without problems: > > > > xn0: flags=8943 metric 0 > > mtu 1500 > > options=3 > > ether 00:16:3e:74:3d:76 > > nd6 options=29 > > media: Ethernet manual > > status: active > > bridge0: flags=8843 metric 0 mtu > > 1500 > > ether 02:77:3d:4a:18:00 > > inet 172.16.1.140 netmask 0xffffff00 broadcast 172.16.1.255 > > nd6 options=9 > > groups: bridge > > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > > maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 > > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > > member: xn0 flags=143 > > ifmaxaddr 0 port 2 priority 128 path cost 2000000 > > > > Is this a GENERIC kernel or are you using some custom > > configuration/patches? > > Can you provide some more information about how to reproduce this? > > > > GENERIC + VIMAGE, but that's just it, no other custom changes or patches. > > Note however that this is under a NetbBSD Dom0, and I see the "vifXX" > interface disappear in the Dom0 side when the bridge is create on FreeBSD > DomU. > > I'm actually happy with netgraph, although I've never played with it, and > seems more complex, the script provide in /share/examples is perfect to use > with "jail.conf" and pf seems happy in FreeBSD-11 (which is not CURRENT, > should we move this to a different mailing list!?) too, no panics so far. > > I suspect the main issue, since it works fine for you is the fact that this > is in a NetBSD Dom0. Oh, from your previous email I thought that it was the interface inside of the DomU that disappeared. Does then same happen on a NetBSD Dom0 with a NetBSD DomU? Roger. From owner-freebsd-current@freebsd.org Tue Aug 9 14:09:41 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 19015BB4371; Tue, 9 Aug 2016 14:09:41 +0000 (UTC) (envelope-from miguelmclara@gmail.com) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 B913D16AC; Tue, 9 Aug 2016 14:09:40 +0000 (UTC) (envelope-from miguelmclara@gmail.com) Received: by mail-wm0-x22b.google.com with SMTP id d196so5352224wmd.0; Tue, 09 Aug 2016 07:09:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cBOmICYxej69ZJHMLKojdXg0nxKPYj5SSIlYI8FOs14=; b=Pb/HMkIDipiXaIoLdEJzA5DSJjl9a2nV0Tq7vhFqoBZSQHoDoGzvZ4fAzLyEf79n7N PBAIP57RF/uvMOrCE5ml6syGJyDTYTlZ7HZ3KwVpjzZQestBZ3uuuKg3qp8NTdp/GAb4 pV1fgTWtCnOzgZr4OFea7ZMC0+8yW8VypRt+GYtnnNdgpJO5pLLq3DAzc1ohl8xps90K lGVaYsKSX24up2oweVEyAc2ri6XNuPr0jJdjPuneioR0U0ZlF63fH2yBGe7vXJ/zSj4L zTqTKSv0ce5NpTLsxNr8+P2zV9wUdAiZLxzPx5Cj+DXWC++CtBtoyNgXP8Fs+jAmlKtm /arA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cBOmICYxej69ZJHMLKojdXg0nxKPYj5SSIlYI8FOs14=; b=Btx2IffhBShSxlBHJ6qRjNfcgJn4gYBS0Lio9/5SP5cxWe6ohAswmwTGoLiUAghIOA j8DVeedpMak5bFgHtU/5JUxqw2NUguHoLjA5OezjSwFtsnEom6UBmkr2Ki+TyIqAB8QP lCT77TnmxKLLS9IjMl3XW8C1/RAQ/39CXE5M+t7dZRhHlMaxwae7u0X7ZTlDRxiHNlJG K46migLBn7mzP5KLvwoI3cgtdyro+uUvzla9XPWZZa4U5rCg2NANWTfUzDNDyTnFX4y4 OL9yDTXoM/dJp0tkDdemgRhJF7fd3KZDBxg/o9xXES+xrV93N044QfnWUK82SGW+ze5T sJBA== X-Gm-Message-State: AEkoouuvmO88GRYKotzGAsH0O/svIPhCuUMSSKEHlO+AO6pFO3IyWrMdwEFDpyyERLbonDFRJrgf/4ohMKAFiQ== X-Received: by 10.194.18.35 with SMTP id t3mr88847792wjd.174.1470751778681; Tue, 09 Aug 2016 07:09:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.198.201 with HTTP; Tue, 9 Aug 2016 07:09:37 -0700 (PDT) In-Reply-To: <20160809113210.p2rkqmjnypg2iw5l@mac> References: <20160809085523.kow2qbpirzppytv6@mac> <20160809113210.p2rkqmjnypg2iw5l@mac> From: Miguel C Date: Tue, 9 Aug 2016 15:09:37 +0100 Message-ID: Subject: Re: FreeBSD 11 - BETA-1 Xen DOMU loses network when jail (VIMAGE) starts To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: freebsd-current , "freebsd-xen@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 09 Aug 2016 14:09:41 -0000 On Tuesday, August 9, 2016, Roger Pau Monn=C3=A9 wro= te: > On Tue, Aug 09, 2016 at 12:12:34PM +0100, Miguel C wrote: > > Melhores Cumprimentos // Best Regards > > ----------------------------------------------- > > *Miguel Clara* > > *IT - Sys Admin & Developer* > > > > On Tue, Aug 9, 2016 at 9:55 AM, Roger Pau Monn=C3=A9 > > > wrote: > > > > > On Sat, Jul 23, 2016 at 08:46:49PM +0100, Miguel C wrote: > > > > Just as a note using netgraph (with jng script as a workaround) > works.... > > > > > > > > Also manually creating a bridge in the domu and adding xn0 as a > member > > > > makes this fail.... so the issue is indeed related to the bridge. > > > > > > > > I'll open a PR later in case someone want to look into it, but I'm > happy > > > it > > > > works with netgraph. > > > > > > I seem to be able to use xn* interfaces with bridges without problems= : > > > > > > xn0: flags=3D8943 > metric 0 > > > mtu 1500 > > > options=3D3 > > > ether 00:16:3e:74:3d:76 > > > nd6 options=3D29 > > > media: Ethernet manual > > > status: active > > > bridge0: flags=3D8843 metric = 0 > mtu > > > 1500 > > > ether 02:77:3d:4a:18:00 > > > inet 172.16.1.140 netmask 0xffffff00 broadcast 172.16.1.255 > > > nd6 options=3D9 > > > groups: bridge > > > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > > > maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 > > > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > > > member: xn0 flags=3D143 > > > ifmaxaddr 0 port 2 priority 128 path cost 2000000 > > > > > > Is this a GENERIC kernel or are you using some custom > > > configuration/patches? > > > Can you provide some more information about how to reproduce this? > > > > > > GENERIC + VIMAGE, but that's just it, no other custom changes or > patches. > > > > Note however that this is under a NetbBSD Dom0, and I see the "vifXX" > > interface disappear in the Dom0 side when the bridge is create on FreeB= SD > > DomU. > > > > I'm actually happy with netgraph, although I've never played with it, a= nd > > seems more complex, the script provide in /share/examples is perfect to > use > > with "jail.conf" and pf seems happy in FreeBSD-11 (which is not CURRENT= , > > should we move this to a different mailing list!?) too, no panics so fa= r. > > > > I suspect the main issue, since it works fine for you is the fact that > this > > is in a NetBSD Dom0. > > Oh, from your previous email I thought that it was the interface inside o= f > the DomU that disappeared. Does then same happen on a NetBSD Dom0 with a > NetBSD DomU? > > Sorry I should have explained better, and no it does not happen with othe= r guests not even FreeBSD 9 or 10, but VIMAGE has major issues there and some have been fixed in 11 (panics while using of for example), and I also needed a patch for xn to even work (also related to NetBSD dom0) but bridge did not give any issues. It seems with 11 when I add xn0 to the bridge the dom0 thinks the interface was disconnected, and when that happens I guess the vif bridge script ( on dom0 ) destroys the interface. Roger. --=20 Miguel Clara, Sent from Gmail Mobile From owner-freebsd-current@freebsd.org Tue Aug 9 14:24:51 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 59E16BB490F; Tue, 9 Aug 2016 14:24:51 +0000 (UTC) (envelope-from prvs=022e014eb=roger.pau@citrix.com) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "DigiCert SHA2 Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 039A91394; Tue, 9 Aug 2016 14:24:50 +0000 (UTC) (envelope-from prvs=022e014eb=roger.pau@citrix.com) X-IronPort-AV: E=Sophos;i="5.28,494,1464652800"; d="scan'208";a="371225454" Date: Tue, 9 Aug 2016 16:24:41 +0200 From: Roger Pau =?iso-8859-1?Q?Monn=E9?= To: Miguel C CC: freebsd-current , "freebsd-xen@freebsd.org" Subject: Re: FreeBSD 11 - BETA-1 Xen DOMU loses network when jail (VIMAGE) starts Message-ID: <20160809142433.hxevvocxwokrftbs@mac> References: <20160809085523.kow2qbpirzppytv6@mac> <20160809113210.p2rkqmjnypg2iw5l@mac> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.6.2-neo (2016-06-11) X-DLP: MIA1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 09 Aug 2016 14:24:51 -0000 On Tue, Aug 09, 2016 at 03:09:37PM +0100, Miguel C wrote: > On Tuesday, August 9, 2016, Roger Pau Monné wrote: > > > On Tue, Aug 09, 2016 at 12:12:34PM +0100, Miguel C wrote: > > > Melhores Cumprimentos // Best Regards > > > ----------------------------------------------- > > > *Miguel Clara* > > > *IT - Sys Admin & Developer* > > > > > > On Tue, Aug 9, 2016 at 9:55 AM, Roger Pau Monné > > > > > wrote: > > > > > > > On Sat, Jul 23, 2016 at 08:46:49PM +0100, Miguel C wrote: > > > > > Just as a note using netgraph (with jng script as a workaround) > > works.... > > > > > > > > > > Also manually creating a bridge in the domu and adding xn0 as a > > member > > > > > makes this fail.... so the issue is indeed related to the bridge. > > > > > > > > > > I'll open a PR later in case someone want to look into it, but I'm > > happy > > > > it > > > > > works with netgraph. > > > > > > > > I seem to be able to use xn* interfaces with bridges without problems: > > > > > > > > xn0: flags=8943 > > metric 0 > > > > mtu 1500 > > > > options=3 > > > > ether 00:16:3e:74:3d:76 > > > > nd6 options=29 > > > > media: Ethernet manual > > > > status: active > > > > bridge0: flags=8843 metric 0 > > mtu > > > > 1500 > > > > ether 02:77:3d:4a:18:00 > > > > inet 172.16.1.140 netmask 0xffffff00 broadcast 172.16.1.255 > > > > nd6 options=9 > > > > groups: bridge > > > > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > > > > maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 > > > > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > > > > member: xn0 flags=143 > > > > ifmaxaddr 0 port 2 priority 128 path cost 2000000 > > > > > > > > Is this a GENERIC kernel or are you using some custom > > > > configuration/patches? > > > > Can you provide some more information about how to reproduce this? > > > > > > > > GENERIC + VIMAGE, but that's just it, no other custom changes or > > patches. > > > > > > Note however that this is under a NetbBSD Dom0, and I see the "vifXX" > > > interface disappear in the Dom0 side when the bridge is create on FreeBSD > > > DomU. > > > > > > I'm actually happy with netgraph, although I've never played with it, and > > > seems more complex, the script provide in /share/examples is perfect to > > use > > > with "jail.conf" and pf seems happy in FreeBSD-11 (which is not CURRENT, > > > should we move this to a different mailing list!?) too, no panics so far. > > > > > > I suspect the main issue, since it works fine for you is the fact that > > this > > > is in a NetBSD Dom0. > > > > Oh, from your previous email I thought that it was the interface inside of > > the DomU that disappeared. Does then same happen on a NetBSD Dom0 with a > > NetBSD DomU? > > > > Sorry I should have explained better, and no it does not happen with other > guests not even FreeBSD 9 or 10, but VIMAGE has major issues there and some > have been fixed in 11 (panics while using of for example), and I also > needed a patch for xn to even work (also related to NetBSD dom0) but bridge > did not give any issues. > > It seems with 11 when I add xn0 to the bridge the dom0 thinks the interface > was disconnected, and when that happens I guess the vif bridge script ( on > dom0 ) destroys the interface. Can you paste the output of `xenstore-ls -fp` on the Dom0 when that happens? Also are there any messages in the Dom0 dmesg? You might want to modify src/sys/arch/xen/xen/xennetback_xenbus.c (on the NetBSD sources) to define XENDEBUG_NET, so that you get verbose output. Roger. From owner-freebsd-current@freebsd.org Tue Aug 9 21:24:50 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 14A01BB4F6B for ; Tue, 9 Aug 2016 21:24:50 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [IPv6:2001:470:8d59:1::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protected-networks.net", Issuer "Protected Networks CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9538E1FA4; Tue, 9 Aug 2016 21:24:49 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding:content-type :content-type:mime-version:user-agent:date:date:message-id :subject:subject:from:from; s=201508; t=1470777887; bh=DQSHdxRmz 9EyWoZcYRGlw7VKWYC0rnAGYHbZve7DIzU=; b=c/iDeKGsAuCdkEFPaDxDQXqGK 9JL4W9H4b+D+cDCJjOm0UaCKmgQ64ep4z/z6rJVxwnvIVLuF9GxqO3/WOseO26NW Ygl0/T2zeu4aYLCuuwZJZLLEAlTzrNvC7JbUCd1CEXoVZM9FJrh59wzKIFV1t/dt cvVjAcBST/dkxmwWas= Received: from toshi.auburn.protected-networks.net (gw.auburn.protected-networks.net [192.168.1.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id 1488C1D30E; Tue, 9 Aug 2016 17:24:47 -0400 (EDT) To: freebsd-current Cc: dumbbell@freebsd.org From: Michael Butler Subject: SVN r303890 breaks build Openpgp: id=6F63E6399DCC8E3E94D60F0642FF6BAE0442D492 Message-ID: <0505a313-c177-2aca-85bc-d8afb24b558a@protected-networks.net> Date: Tue, 9 Aug 2016 17:24:46 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.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.22 Precedence: 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, 09 Aug 2016 21:24:50 -0000 The switch to device_t breaks the user-space compilation with .. Building /usr/obj/usr/src/lib/libkvm/kvm.o --- kvm.o --- In file included from /usr/src/lib/libkvm/kvm.c:50: /usr/obj/usr/src/tmp/usr/include/sys/pcpu.h:163:2: error: unknown type name 'device_t' device_t pc_device; ^ 1 error generated. *** [kvm.o] Error code 1 imb From owner-freebsd-current@freebsd.org Tue Aug 9 21:27:11 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 41F11BB4185 for ; Tue, 9 Aug 2016 21:27:11 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 09F471669 for ; Tue, 9 Aug 2016 21:27:11 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) Received: from 141.7.19.93.rev.sfr.net ([93.19.7.141] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1bXEYF-000PWu-VC; Tue, 09 Aug 2016 23:27:09 +0200 Subject: Re: SVN r303890 breaks build To: Michael Butler , freebsd-current References: <0505a313-c177-2aca-85bc-d8afb24b558a@protected-networks.net> From: =?UTF-8?Q?Jean-S=c3=a9bastien_P=c3=a9dron?= Message-ID: Date: Tue, 9 Aug 2016 23:27:03 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <0505a313-c177-2aca-85bc-d8afb24b558a@protected-networks.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Wsi1A1Paie4Hot6ROIGEF04eLaHp7La2d" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 09 Aug 2016 21:27:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Wsi1A1Paie4Hot6ROIGEF04eLaHp7La2d Content-Type: multipart/mixed; boundary="a57kGP6o1W7uxWBQ7AGA6vNtQhxjxUKxd" From: =?UTF-8?Q?Jean-S=c3=a9bastien_P=c3=a9dron?= To: Michael Butler , freebsd-current Message-ID: Subject: Re: SVN r303890 breaks build References: <0505a313-c177-2aca-85bc-d8afb24b558a@protected-networks.net> In-Reply-To: <0505a313-c177-2aca-85bc-d8afb24b558a@protected-networks.net> --a57kGP6o1W7uxWBQ7AGA6vNtQhxjxUKxd Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 09/08/2016 23:24, Michael Butler wrote: > The switch to device_t breaks the user-space compilation with .. Ye, I saw that. I'm waiting for buildworld to finish before committing. I'm sorry, I was sure only the kernel used this structure. Thank you for the report! And sorry for the breakage. --=20 Jean-S=C3=A9bastien P=C3=A9dron --a57kGP6o1W7uxWBQ7AGA6vNtQhxjxUKxd-- --Wsi1A1Paie4Hot6ROIGEF04eLaHp7La2d Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXqkqnAAoJEDnpl2Gl/ZTM62wQAOYUs00Zqbe4SlKO+RluZi7c ifrplgBZPxTiiS4J3y7jRg8qBi0sP4M08LdG0bRqo7YK2yg3TF8IyrP3+No6e9AJ mvarVr/08lkLhhuvd7kCDirQg1dQ40HxmteBXWxwyYiUHzzW/ljT0logtgvIwlNi aDpLZfNVvQW8HO2v8yiZA31ACCCkZCbWYGxc6RtwDp20DUzg2iwyQFAXMFt7hude /RcMuFWevUlPul4NQ6zXeOHHSKDrdrq7WTYJwnp/Y2926xQJzmrps1NJwjjFqSAt 6sc6K5kItcC+4r/knmSj73iUTsN+GiB8UUw1PZEJv7lVX1qaNr25tft3uByheIcG PI2Kp08JMxLRsAioaB3fdxfzjKKYJgDZ2hUN+VMcL2esM2+oYOsxI4KP8JkpPj2+ oOGh8OlIrXuuPH5qfWlSip4U2+M0dIMkMRiRFVbZRxHbJJlY8utrkA/HUAI+2vEE EaAHqzZOUOic35V95J92yVzHMGIwoQWVRkLfHo4hQy8vLi7t+lMOVoDstdu8/bkG 2YF4zrFtYEUNfo7FQN07V+1gd5GR5jQOTjcO/t/9AL3nVFBWBeCaKQXZihGS9LMM 3OxbeBgNX8VYf8Q6xPooMRJ8e4VOX8oeadIQd8UZrrScbwAjr536CWm1BvQ+ZJCa IpdSFSCiVg8mHzmwOMPH =28VS -----END PGP SIGNATURE----- --Wsi1A1Paie4Hot6ROIGEF04eLaHp7La2d-- From owner-freebsd-current@freebsd.org Wed Aug 10 08:18:50 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DCCE6BB4712; Wed, 10 Aug 2016 08:18:50 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "rulingia.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BAE931300; Wed, 10 Aug 2016 08:18:48 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (ppp59-167-167-3.static.internode.on.net [59.167.167.3]) by vps.rulingia.com (8.15.2/8.15.2) with ESMTPS id u7A8IchB076211 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 10 Aug 2016 18:18:44 +1000 (AEST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id u7A8IWPR060313 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 10 Aug 2016 18:18:32 +1000 (AEST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id u7A8IVXw060312; Wed, 10 Aug 2016 18:18:31 +1000 (AEST) (envelope-from peter) Date: Wed, 10 Aug 2016 18:18:31 +1000 From: Peter Jeremy To: freebsd-ports@freebsd.org, freebsd-current@freebsd.org Subject: Mosh regression between 10.x and 11-stable Message-ID: <20160810081831.GA65184@server.rulingia.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 10 Aug 2016 08:18:51 -0000 --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I recently updated one of my VPS hosts from 10.3-RELEASE-p5 to 11.0-BETA4 r303811 and mosh to that host from my Linux laptop stopped working. All I get on the laptop is: $ mosh remotehost Connection to remotehost closed. /usr/bin/mosh: Did not find mosh server startup message. I've tried rebuilding mosh (and all dependencies) on the host to no avail. This isn't the DSA change that's been discussed elsewhere: I can SSH from my laptop to the host without problem. I can also manually invoke mosh-client and mosh-server and it works. Unfortunately, mosh has no provision for debugging. I've tried hacking the mosh perl script to make it more verbose and that shows that: 1) the "MOSH CONNECT" message isn't making it out of the local ssh process. 2) it's racy because I can get it from "always fails" to "sometimes works". My suspicion is that something has changed in either sshd or TCP that is resulting in the connection going away before the stdout from the remote mosh-server makes it out from the local ssh process. I've looked at tcpdump's of both successful and failed SSH sessions but don't see anything obviously different (encryption makes it difficult to decode the session). Has anyone else seen this behaviour or have any ideas what might be causing it? --=20 Peter Jeremy --SLDf9lqlvOQaIe6s Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJXquNXXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs0jYMQAIlS3y9xU4Y3atZNIBDTW7mB CFewmgQfbvC4hvXYhSmXyI8X7ZSZaGnCkNLo2gXXPHjg8Q7Zxkbz1luG/DJlXwlx rY3TPgB2T/UiIzwngAVsnUa76dqgTqmFpdLFa6Qb1+6FCeTWKt8tncEv1zquv0vk OXdVtAnM+PjMnmEEc+5U41hZxaAjqZc5DeD6GJGH/V8WCno/gRujef+wl97XGTk5 +fBU6J2wuSGqT6Ys9lDFUY2dMfUaUHn7aCbKvLIdelry4tjmqsRGNpU6deUP4Y1P r4xlZefCWdfxR//OqgCxtOtygg6vMvejEVWnkVm++naxgszr8lGFn+EukpJfDajT jqvJHNJEN5g1i4/596wAF16aB8Hcwt7kDDX6dbfnvhw+8nc4+JgDt4BwoTVqtGOM EE4d47A48VuyAps6wAWrEk/6PrjMWnIch724bkf3k0VA4LD0A7V3axHbXSoBFElj 5WIaurz86xhrVSC2nvJMrddwGTigD0wLYwdYmQMy5EPaukOoGZS0vowqoLjv+GMI dM0pUvPPDcsHxLVpQsNSVun1XIVcpy7iG1l2zJwZxfrWUTXfCITFdFYToQZzYile JmKscG0ErIjrKUX3OyA/P6zHLSEq/G1zAX+jEVGB6iC612B9HSX3WuR/mYqew5VV L6ZgNfhy0uWjL2wNE2Bw =RVeM -----END PGP SIGNATURE----- --SLDf9lqlvOQaIe6s-- From owner-freebsd-current@freebsd.org Wed Aug 10 14:33:27 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5966BBB4DDE for ; Wed, 10 Aug 2016 14:33:27 +0000 (UTC) (envelope-from rionda@gmail.com) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::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 1069F1332 for ; Wed, 10 Aug 2016 14:33:27 +0000 (UTC) (envelope-from rionda@gmail.com) Received: by mail-qk0-x235.google.com with SMTP id v123so4067981qkh.2 for ; Wed, 10 Aug 2016 07:33:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:subject:date:message-id:to:mime-version; bh=cAxcU+tqYEs8Escq8z63Ll5O8NJfVn/gSLzql+XZsmQ=; b=FaYEB7RhwNdR3VLK45sqZvwn/d7do6wx2c/cXOFhsGh8L05NzSDp8pbBKkSrpheGT9 dSL31f5DiHQexwdWzABXsHxN9G/rQo/ZM4srspva4qSoh4SOYke28ltgfqsjzLmWp3kY 7O5uJtcmRakNrb8e8TKeE9KwjPiCbwiH1itkynsDyA3Iiz6euoqfLi2kei74EBaqikCi oPH5gSrbjNBAJ0MLoZ390er+c+pf6m6nc3FWxZOBigvZ0mOiZrPvSA8YaikgwigbIQNB 5oGJ6w7jirnYgT4M51AJHGJZLNDj4Xr1jBjUHLSQiQevGVtNDrN+0kkSSnE2EfDNKjyR NJxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:subject:date:message-id:to :mime-version; bh=cAxcU+tqYEs8Escq8z63Ll5O8NJfVn/gSLzql+XZsmQ=; b=DFz8QLy98f3foAUdzv72fNgxJjaptGfvZ0Lui8vGYTX7Bm8VgMDynTFaS9NBHMeio2 TBNizOaPvqaVof66vODIzR+Fja0em9tmFXtl8X3/jdE3zTgqWsKSf2mzK3R4T7iO0VYL gb8TfcQtoT18PvTlK+4NOuw0mOh7L2W+vyISpeRLmbYXRYqPJNmeUcRmWgS7kylcH1mH l2pM9+nWhoxClljDbOc/KYO2ZLQ5JpcnCPI/NIIwI+ENei/E3Qt6NyggyszaI7n9g6WN nCO3Bb8yEglHqrisJbeNw0wwaR+N3pbNYmiqw7Tb60httS2MtuvaruOVZswIUiVfMQH+ x+vw== X-Gm-Message-State: AEkoousOd6ZWtuXBPEP4wlX7hYfttEuv8ebHW3HQ2IZ24SMQrQ7gECzbUJz4LCwCgL0gdw== X-Received: by 10.55.159.135 with SMTP id i129mr4653674qke.190.1470839606022; Wed, 10 Aug 2016 07:33:26 -0700 (PDT) Received: from [172.31.26.254] (gzac12-mdf2-1.aoa.twosigma.com. [208.77.215.155]) by smtp.gmail.com with ESMTPSA id j38sm23439264qtj.35.2016.08.10.07.33.24 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 10 Aug 2016 07:33:24 -0700 (PDT) Sender: Matteo Riondato From: Matteo Riondato X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_28127554-3AAD-4F5E-A143-93908123A1E3"; protocol="application/pgp-signature"; micalg=pgp-sha256 Subject: Signal 12 on make update (or any target in /usrc/src) Date: Wed, 10 Aug 2016 10:33:23 -0400 Message-Id: <72EC5BF8-C383-4F75-B47F-213613584BA7@FreeBSD.org> To: FreeBSD Current Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 10 Aug 2016 14:33:27 -0000 --Apple-Mail=_28127554-3AAD-4F5E-A143-93908123A1E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, I recently upgraded from a late June (pre 11-branch, as far as I can = tell) revision to r303771. Now, running =E2=80=9Cmake update=E2=80=9D (or buildworld, =E2=80=A6) in = /usr/src fails with a signal 12: matteo@triton:/usr/src$ sudo make update Password: *** Signal 12 Stop. make: stopped in /usr/src .ERROR_TARGET=3D'update' .ERROR_META_FILE=3D'' .MAKE.LEVEL=3D'0' MAKEFILE=3D'' .MAKE.MODE=3D'normal' .CURDIR=3D'/usr/src' .MAKE=3D'make' .OBJDIR=3D'/usr/obj/usr/src' .TARGETS=3D'update' DESTDIR=3D'' LD_LIBRARY_PATH=3D'' MACHINE=3D'amd64' MACHINE_ARCH=3D'amd64' MAKEOBJDIRPREFIX=3D'/usr/obj' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20160606' PATH=3D'/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP=3D'/usr/src' OBJTOP=3D'/usr/obj/usr/src Installing ports using =E2=80=9Cmake install=E2=80=9D works. Relevant (?) section of src.conf: WITH_CCACHE_BUILD=3Dy WITH_SYSTEM_COMPILER=3Dy src-env.conf: WITH_META_MODE=3Dyes make.conf: KERNCONF=3DTRITON CPUTYPE?=3Dk8-sse3 SVN_UPDATE=3Dy COPTFLAGS=3D-O2 -pipe MALLOC_PRODUCTION=3Dy Any hints? Thanks, Matteo --Apple-Mail=_28127554-3AAD-4F5E-A143-93908123A1E3 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----- iQIcBAEBCAAGBQJXqzs0AAoJEJ/Xw+PLA1Gfz1gQAI2V2BlagpZAeqCItQyHL3OQ LS2OYQWED4ViJ8Lf1+v+fKae1sH3WzEQHpUWqe7W2gwZR151i/WG45Q7s9Efa/gP zSCEtzwgPWZPpxlpjkrrkURATo8KdVLXYM9CqLaUGX0JQ93nlemTAuPxcchJrSHx k/sKx4YMMLaArT0ddNn++peCJvvq4oXV+0p46tu25IhwBW88gPNWpq85tNGvQMjp 3AwNPrGj7loYY/XqmBmThG75k0pn9bSELpTE3/aYrULyuTsN+2XK8zHrHrSJqiYY uVf8Bl8d6XcBM3eN/mBf3ZFJJXMGxFpMyS8Frz7ydw56lc66bMQELSeZvPXjN37B aHM/pq0C4RrDw5Ais0eOi+8TrT9SiVCU/E9z2oB4hX79CKO0Fn7PD4EDsDp+2mf7 wxfqkc0WaW394U3u1FIMaomez+iqsinsGjiirv5DjM0sX5/cPMtDtzxrjb5DXgGu be8kDgnNKGVB8UGy2KyixbBnWYkn75TrYGUW4d7yfB/z2MyE6/vB4Qm11GaVCCgB RZkxz+yuyJU+J+TEV7wAibP7QMS7B064G68YpSjLe6DQp4CW2FeBF60hclZQMF4U h5mv3qiywodzANOogx1cJbso+dL0z7TcdDiguVlKoClzo699HXfVeN0dMkJOVZUn R72gvnV4o87EbkMulpSY =ryYM -----END PGP SIGNATURE----- --Apple-Mail=_28127554-3AAD-4F5E-A143-93908123A1E3-- From owner-freebsd-current@freebsd.org Wed Aug 10 14:41:46 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1855CBB53F8 for ; Wed, 10 Aug 2016 14:41:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5C45D18F8; Wed, 10 Aug 2016 14:41:45 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u7AEfd4f052291 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 10 Aug 2016 17:41:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u7AEfd4f052291 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u7AEfd1I052290; Wed, 10 Aug 2016 17:41:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 10 Aug 2016 17:41:39 +0300 From: Konstantin Belousov To: Matteo Riondato Cc: FreeBSD Current Subject: Re: Signal 12 on make update (or any target in /usrc/src) Message-ID: <20160810144139.GR83214@kib.kiev.ua> References: <72EC5BF8-C383-4F75-B47F-213613584BA7@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <72EC5BF8-C383-4F75-B47F-213613584BA7@FreeBSD.org> User-Agent: Mutt/1.6.1 (2016-04-27) 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.22 Precedence: 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, 10 Aug 2016 14:41:46 -0000 On Wed, Aug 10, 2016 at 10:33:23AM -0400, Matteo Riondato wrote: > Hi all, > > I recently upgraded from a late June (pre 11-branch, as far as I can tell) revision to r303771. > > Now, running ???make update??? (or buildworld, ???) in /usr/src fails with a signal 12: > > matteo@triton:/usr/src$ sudo make update > Password: > *** Signal 12 You did not updated, I think. You, most likely, inly updated the kernel, but left the old userspace in place, at least libc. Signal 12 is SIGSYS, which means that the program tries to use a syscall not implemented by the kernel. My guess is that your kernel lacks option COMPAT_FREEBSD10, and the failing syscall is pipe(2). From owner-freebsd-current@freebsd.org Wed Aug 10 14:49:43 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AC7D4BB5620 for ; Wed, 10 Aug 2016 14:49:43 +0000 (UTC) (envelope-from rionda@gmail.com) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 61DCB1DAE for ; Wed, 10 Aug 2016 14:49:43 +0000 (UTC) (envelope-from rionda@gmail.com) Received: by mail-qk0-x236.google.com with SMTP id p186so45718952qkd.1 for ; Wed, 10 Aug 2016 07:49:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:from:in-reply-to:date:cc:message-id :references:to; bh=6XFOJ5Au+hQs3DXb2EOCZhxY7tTOZemi1WG6dGfeq4c=; b=HI7Jlg5+5/Lt3LFnukvNzKIKK2UlJqFj/M9pXGxubXlHnXrxSv9SS9CpuHMfgQp0ev fgUe1vYPL20GSCjxZ+1EVYoMy/7oBqF1Jt4jPzZNcnIu77ncyJa0qzg7/w8T+sfI9gyB +T8je4CmXA3Px9WTNVb1jXPaRQ81MzkE19cpRGAJo3NpooZgqOGPM3JOW+nqKSb+elMN OJiMa5d3ww0e31sVXQnHA9tRwUhs9tH31DS28gAIF94au0RMNz+3yuVmYG95JOE0f8fP GeYwSRRO0Kfo2sj8K46actF35C/kl2n20HWCNrjwUe6nHTdXSYd3uvViTHu6hDmiJLBU JJpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:from:in-reply-to :date:cc:message-id:references:to; bh=6XFOJ5Au+hQs3DXb2EOCZhxY7tTOZemi1WG6dGfeq4c=; b=SbL9/w55vvvBkDpzE/mTNny0juyZjhZpaGM3Ib97IWOsh52qqf4Au/w98IsemCcf3U cpSZQp5IsrT2UTDELDmscZv8jPrdxPeHns7/C/VOtWGHOoF00XeSVz2RQb8TO+P4gWqV 7PbbBKTGJdHDLvTJrNAQ35Fjbi+XPZcEu/US4RUvpfpT4Cc8yc7Yw94lB4aR0rgo8Fy8 eLtd9XCtOwshFX6DQcA7G4H+NSQVvTL6PNfmb8onaCPRxfAExTUEGTgXYvtegNNadzLo aTVVZGnSIjmy/8LbkiYXjdyXGiJZzePe6QCFGeYYxjIG69UBIf8gclkKAh3m2s5vtiRa ydbQ== X-Gm-Message-State: AEkoousuW6kn4tZSEgTyDi6HiSrchlhoBtL0b7yzoiE8UlTBdc9I08oNqINwB5Iny4uKSg== X-Received: by 10.55.81.68 with SMTP id f65mr4603084qkb.65.1470840582490; Wed, 10 Aug 2016 07:49:42 -0700 (PDT) Received: from [172.31.26.254] (gzac12-mdf2-1.aoa.twosigma.com. [208.77.215.155]) by smtp.gmail.com with ESMTPSA id x42sm23446291qtc.29.2016.08.10.07.49.41 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 10 Aug 2016 07:49:41 -0700 (PDT) Sender: Matteo Riondato Subject: Re: Signal 12 on make update (or any target in /usrc/src) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_B2448404-8F65-475B-B380-08999BFED1E0"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail From: Matteo Riondato In-Reply-To: <20160810144139.GR83214@kib.kiev.ua> Date: Wed, 10 Aug 2016 10:49:40 -0400 Cc: FreeBSD Current Message-Id: <07F8C5E5-3768-4848-A0EE-7963C8657286@FreeBSD.org> References: <72EC5BF8-C383-4F75-B47F-213613584BA7@FreeBSD.org> <20160810144139.GR83214@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 10 Aug 2016 14:49:43 -0000 --Apple-Mail=_B2448404-8F65-475B-B380-08999BFED1E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 10, 2016, at 10:41 AM, Konstantin Belousov = wrote: > On Wed, Aug 10, 2016 at 10:33:23AM -0400, Matteo Riondato wrote: >> Hi all, >>=20 >> I recently upgraded from a late June (pre 11-branch, as far as I can = tell) revision to r303771. >>=20 >> Now, running ???make update??? (or buildworld, ???) in /usr/src fails = with a signal 12: >>=20 >> matteo@triton:/usr/src$ sudo make update >> Password: >> *** Signal 12 >=20 > You did not updated, I think. You, most likely, inly updated the = kernel, > but left the old userspace in place, at least libc. That would be surprising but it may have happened, as I don=E2=80=99t = remember without doubts to have run installworld :/ > Signal 12 is SIGSYS, which means that the program tries to use a = syscall > not implemented by the kernel. My guess is that your kernel lacks = option > COMPAT_FREEBSD10, and the failing syscall is pipe(2). Indeed I do not have COMPAT_FREEBSD10, because I believed my previous = world revision was >302092, as noted by the entry about pipe(2) in = UPDATING. Any suggestion on how to fix this? Boot the old kernel, add COMPAT_FREEBSD10 to kernel config, and = rebuild/install world and kernel perhaps? Thanks for the help! Matteo --Apple-Mail=_B2448404-8F65-475B-B380-08999BFED1E0 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----- iQIcBAEBCAAGBQJXqz8FAAoJEJ/Xw+PLA1GfzWQP/2SV4pm3eXHdELubhGKtinkg KUWa0p4rJnfLSxP050pekZxeK/dCwdigNaJhb6hoTCLZAo8qhRo4oJVFH6s66Evi v9QJoiUl44OxWjCUtPVSY7p/EZfNKrtoEBoy20GDdORHja711Ys2qZpyF/3m5kDE KjPM4tMPCfuWCaMsgpOJXujQZYUlWm7jgGIaEg/0aj4BqF65Jk2oFrn0eAcLiJ8W RMzvo51q0EsSPWTvv5Ize2IV9s4oyeiGzHT6ycvSoKjoVET/AN/qT708AohcUSW2 eNzbd6P5WQtUL8L3c3EPa5CrvdqL3X76wDrKtPYB+nFOdLj1X/49uGcW5++5BTFw 23lJmoiVCNsV28um+X79hiObpVD+DZk4AdTJcOYPdNkLryv+zbqYQghTWMOEVdUG cbj9KfiOwiD66vs8PhjwihcasYDOi+FWdXQ+oEFzKIdi13CGJnHSHqSlfJYAPxGi 74R4HC/RoR7VztpFTL1Q0cTfJk3vzARaDNwD7wWkVUfY1+8dJgQfnpEx9MFaMHJZ /5+3h9pAcmh9dAsO5ZW7CoBpGM5FiIbJnQqy2i+/6dp9AGw745Y0dSkqDYhkRkO3 m9SVnxNLsYZalMaPq9JAk6rEWRFqNn94DZ/0tsr92zPu38nbF4tjSrMxwjzQ1VAt U7x6EN5zeZQOIhdQ8omb =6mjH -----END PGP SIGNATURE----- --Apple-Mail=_B2448404-8F65-475B-B380-08999BFED1E0-- From owner-freebsd-current@freebsd.org Wed Aug 10 15:03:58 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EED82BB5C72 for ; Wed, 10 Aug 2016 15:03:58 +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 20D4B19CD; Wed, 10 Aug 2016 15:03:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u7AF3qdr057150 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 10 Aug 2016 18:03:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u7AF3qdr057150 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u7AF3p0p057149; Wed, 10 Aug 2016 18:03:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 10 Aug 2016 18:03:51 +0300 From: Konstantin Belousov To: Matteo Riondato Cc: FreeBSD Current Subject: Re: Signal 12 on make update (or any target in /usrc/src) Message-ID: <20160810150351.GT83214@kib.kiev.ua> References: <72EC5BF8-C383-4F75-B47F-213613584BA7@FreeBSD.org> <20160810144139.GR83214@kib.kiev.ua> <07F8C5E5-3768-4848-A0EE-7963C8657286@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <07F8C5E5-3768-4848-A0EE-7963C8657286@FreeBSD.org> User-Agent: Mutt/1.6.1 (2016-04-27) 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.22 Precedence: 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, 10 Aug 2016 15:03:59 -0000 On Wed, Aug 10, 2016 at 10:49:40AM -0400, Matteo Riondato wrote: > > > On Aug 10, 2016, at 10:41 AM, Konstantin Belousov wrote: > > On Wed, Aug 10, 2016 at 10:33:23AM -0400, Matteo Riondato wrote: > >> Hi all, > >> > >> I recently upgraded from a late June (pre 11-branch, as far as I can tell) revision to r303771. > >> > >> Now, running ???make update??? (or buildworld, ???) in /usr/src fails with a signal 12: > >> > >> matteo@triton:/usr/src$ sudo make update > >> Password: > >> *** Signal 12 > > > > You did not updated, I think. You, most likely, inly updated the kernel, > > but left the old userspace in place, at least libc. > > That would be surprising but it may have happened, as I don???t remember without doubts to have run installworld :/ > > > Signal 12 is SIGSYS, which means that the program tries to use a syscall > > not implemented by the kernel. My guess is that your kernel lacks option > > COMPAT_FREEBSD10, and the failing syscall is pipe(2). > > Indeed I do not have COMPAT_FREEBSD10, because I believed my previous world revision was >302092, as noted by the entry about pipe(2) in UPDATING. > > Any suggestion on how to fix this? > Boot the old kernel, add COMPAT_FREEBSD10 to kernel config, and rebuild/install world and kernel perhaps? > If old kernel works, then this would allow you to recover. Take libc.so.7 from the BETA-4, and put it into /lib, taking backup of your current libc first. I suspect this is the easiest route if old kernel does not match with your world. From owner-freebsd-current@freebsd.org Wed Aug 10 16:53:35 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 28F16BB513E for ; Wed, 10 Aug 2016 16:53:35 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002: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 DBBB918A7; Wed, 10 Aug 2016 16:53:34 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: by mail-yw0-x230.google.com with SMTP id z8so28807793ywa.1; Wed, 10 Aug 2016 09:53:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+5/cZII9/KTXeU0bSHA5RkOosfiroR+aAW2DScxYW9U=; b=awLwJOqjPNU66MaBYcXXK+kncIO9hvSGfr0KLKvMlET9omnPpR7Sw9x3puYaon83UZ aNGLmOK7w+lrNN6PQg/OfPFUjOwJhKnSPFDK6qFn0BF4U7bVOXZxxa2vfDMX0pLpO7/S EPcZy8p1Za1yYxLJg9/MaQZCKhUgfLVrK68tUNFVfMjcTLfXvU8V52/SHf6zw81JjABQ KPdTyfPdyiXRrY0KkvD7qB5+L3/OpJbb79CBQLPJTVkPNVF+UjpStoWubBdcqlYWND2T b1Wym8uQG7eUFv0WqzaZsyexBaiAwt+D+28qyiYycXRqhOQpVbVgoUN89mTHS2u0NJFZ H9+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+5/cZII9/KTXeU0bSHA5RkOosfiroR+aAW2DScxYW9U=; b=Hcd1khntGUGJejVjX8yrnM95p4Gxka0uV15EukcYdnv7ep0accapaIfKc7+y4dRDoW O2qJOEVYh2AOP0UP9m4ngvm3/LYzHJeQgYUSrATPRdseW1y6KZjPc0c/MUjYBzMyRdiL v5hFcE31jBmUQHJgMMwM8VMVH7Dcqil2YmefC6hHRvIImPN0GVax+7+84ibGCM2D1dDu RC7wi7YEAEbN+BqPhEVb9oPE6EeOVeiBCNCpQ2wtMaLhRAlNcTpWS4v3FM0HBvVuE9Xt fp9shZG6w+nvKf9E2jMXnq82PpLwB5PfK+Xue++wqApl/M2EeE/OyUTcN24lSJ7HDrim lOyw== X-Gm-Message-State: AEkoout+wjiaA5julH8knEaVQjzfR/utkJVqcNGZRWhVn/Irza7n0hYii0Zy428UsdlDP5vYlghuYnVvFocPng== X-Received: by 10.129.164.9 with SMTP id b9mr3495573ywh.145.1470848013834; Wed, 10 Aug 2016 09:53:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.51.150 with HTTP; Wed, 10 Aug 2016 09:53:33 -0700 (PDT) In-Reply-To: <196319fe-8113-bb2d-74b7-fbdd3369d988@freebsd.org> References: <196319fe-8113-bb2d-74b7-fbdd3369d988@freebsd.org> From: Ultima Date: Wed, 10 Aug 2016 12:53:33 -0400 Message-ID: Subject: Re: Possible zpool online, resilvering issue To: Stefan Esser Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 10 Aug 2016 16:53:35 -0000 Hello, > I didn't see any reply on the list, so I thought I might let you know Sorry, never received this reply (till now) xD >what I assume is happening: > ZFS never updates data in place, which affects inode updates, e.g. if > a file has been read and access times must be updated. (For that reason, > many ZFS file systems are configured to ignore access time updates). > Even if there were only R/O accesses to files in the pool, there will > have been updates to the inodes, which were missed by the offlined > drives (unless you ignore atime updates). > But even if there are no access time updates, ZFS might have written > new uberblocks and other meta information. Check the POOL history and > see if there were any TXGs created during the scrub. > If you scrub the pooll while it is off-line, it should stay stable > (but if any information about the scrub, the offlining of drives etc. > is recorded in the pool's history log, differences are to be expected). > Just my $.02 ... > Regards, STefan Thanks for the reply, I'm not completely sure what would be considered a TXG. Maintained normal operations during most this noise and this pool has quite a bit of activity during normal operations. My zpool history looks like it gos on forever and the last scrub is showing it repaired 9.48G. That was for all these access time updates? I guess that would be a little less then 2.5G per disk worth. The zpool history looks like it gos on forever (733373 lines). This pool has much of this activity with poudriere. All the entries I see are clone, destroy, rollback and snapshotting. I can't really say how much but at least 500 (prob much more than that) entries between the last two scrubs. Atime is off on all datasets. So to be clear, this is expected behavior with atime=off + TXGs during offline time? I had thought that the resilver after onlining the disk would bring that disk up-to-date with the pool. I guess my understanding was a bit off. Ultima From owner-freebsd-current@freebsd.org Wed Aug 10 17:49:04 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3F297BB5653 for ; Wed, 10 Aug 2016 17:49:04 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1AC301F9B for ; Wed, 10 Aug 2016 17:49:03 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [10.1.1.2]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 16BC71D25 for ; Wed, 10 Aug 2016 17:48:57 +0000 (UTC) Subject: Re: Possible zpool online, resilvering issue To: freebsd-current@freebsd.org References: <196319fe-8113-bb2d-74b7-fbdd3369d988@freebsd.org> From: Allan Jude Message-ID: <6fa613f2-6087-fa5d-c75b-d1a80ce9f06a@freebsd.org> Date: Wed, 10 Aug 2016 13:48:53 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UDQeGERPu927LMjKpAmMVrPr0OMCGgM8F" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 10 Aug 2016 17:49:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UDQeGERPu927LMjKpAmMVrPr0OMCGgM8F Content-Type: multipart/mixed; boundary="ExWA3k3LH01dnjuH05vQPVbIUEaOsdgq5" From: Allan Jude To: freebsd-current@freebsd.org Message-ID: <6fa613f2-6087-fa5d-c75b-d1a80ce9f06a@freebsd.org> Subject: Re: Possible zpool online, resilvering issue References: <196319fe-8113-bb2d-74b7-fbdd3369d988@freebsd.org> In-Reply-To: --ExWA3k3LH01dnjuH05vQPVbIUEaOsdgq5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2016-08-10 12:53, Ultima wrote: > Hello, >=20 >> I didn't see any reply on the list, so I thought I might let you know >=20 > Sorry, never received this reply (till now) xD >=20 >> what I assume is happening: >=20 >> ZFS never updates data in place, which affects inode updates, e.g. if >> a file has been read and access times must be updated. (For that reaso= n, >> many ZFS file systems are configured to ignore access time updates). >=20 >> Even if there were only R/O accesses to files in the pool, there will >> have been updates to the inodes, which were missed by the offlined >> drives (unless you ignore atime updates). >=20 >> But even if there are no access time updates, ZFS might have written >> new uberblocks and other meta information. Check the POOL history and >> see if there were any TXGs created during the scrub. >=20 >> If you scrub the pooll while it is off-line, it should stay stable >> (but if any information about the scrub, the offlining of drives etc. >> is recorded in the pool's history log, differences are to be expected)= =2E >=20 >> Just my $.02 ... >=20 >> Regards, STefan >=20 > Thanks for the reply, I'm not completely sure what would be considered = a > TXG. Maintained normal operations during most this noise and this pool = has > quite a bit of activity during normal operations. My zpool history look= s > like it gos on forever and the last scrub is showing it repaired 9.48G.= > That was for all these access time updates? I guess that would be a lit= tle > less then 2.5G per disk worth. >=20 > The zpool history looks like it gos on forever (733373 lines). This poo= l > has much of this activity with poudriere. All the entries I see are clo= ne, > destroy, rollback and snapshotting. I can't really say how much but at > least 500 (prob much more than that) entries between the last two scrub= s. > Atime is off on all datasets. >=20 > So to be clear, this is expected behavior with atime=3Doff + TXGs duri= ng > offline time? I had thought that the resilver after onlining the disk w= ould > bring that disk up-to-date with the pool. I guess my understanding was = a > bit off. >=20 > Ultima > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 A new transaction group (TXG) is created at LEAST every vfs.zfs.txg.timeout (defaults to 5) seconds. If you offline a drive for hours or more, it must have all blocks with a 'birth time' newer than the last transaction that was recorded on the offlined drive replayed to catch that drive up to the other drives in the pool. As long as you have enough redundancy, the checksum errors can be corrected without concern. In the end, the checksum errors can be written off as being caused by the bad hardware. After you finish the scrub and everything is OK, do: 'zpool clear poolname', and it will reset all of the error and checksum counts to 0, so you can track if any more ever show up. --=20 Allan Jude --ExWA3k3LH01dnjuH05vQPVbIUEaOsdgq5-- --UDQeGERPu927LMjKpAmMVrPr0OMCGgM8F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJXq2kIAAoJEBmVNT4SmAt+kRgP/i39xNRJ6ify5UIoa1CXEWJ6 iygjGvW3JUDWrW3VMgeCCMk1O+2J4eSQs8b2X4DyIDngTtsA33/6G2VRzh+9TgUU bz2NDNf0icfrnkhd9ry6rdYk6dgzn6kj7UZtlWzxTlWh4JL0asZMON0nBvWjPpwW eX5b6kClECVHZYo8XUA/1Ozw5KtfurTsryHS2zIw4Qttpq1+mPRK0kaUUv8MHXrm 2uNyI3Vi7+lfqjMuEao1gyurIC5UKHut3AvpQQSFE3sNegkYHmV3POJp8GKM1qTM vDimh4F6+UwQUsgsnb0D7/71iNSUUJEAb8cb2R5WFkcwqrNl1QKuFdXcnIcEh8JC 1FUZqzOSO53vOk5uCtyHu/yufSEVQ5/nElwTsqZi+G0V36j1fjP7OXuZt3kpu+X0 5KM8K+icRPor5tBB14qxJeohdfDKTqytOVL9aD6RkfAdNarzuYJvD3DnaxgWyF5k diyqP4WxY6UyEDux1xEyLwk9HB+XlKyKK8A0LpGi0xlkskIIk0z6bG1truy6+qBS 9DlVl23dtF8MsMsNJ12EnSiX79TciaqbZW6lZfBS6ibKV0bxcqf6VWaRWEPJu6aI yT20UMsYKy/LIaS0tq2uzm2YULbxAsN36VrsWb/YRbL234Lb06ab7+gMIz4Fv1XS TqpWrAkoid9ilmXbuhA7 =D+au -----END PGP SIGNATURE----- --UDQeGERPu927LMjKpAmMVrPr0OMCGgM8F-- From owner-freebsd-current@freebsd.org Wed Aug 10 18:09:01 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 04980BB5BD5 for ; Wed, 10 Aug 2016 18:09:01 +0000 (UTC) (envelope-from se@freebsd.org) Received: from mailout08.t-online.de (mailout08.t-online.de [194.25.134.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BCDC71AA0; Wed, 10 Aug 2016 18:09:00 +0000 (UTC) (envelope-from se@freebsd.org) Received: from fwd12.aul.t-online.de (fwd12.aul.t-online.de [172.20.26.241]) by mailout08.t-online.de (Postfix) with SMTP id CAE1841DCDA9; Wed, 10 Aug 2016 20:08:50 +0200 (CEST) Received: from [192.168.119.34] (G-d9nuZlrhJJosGR4ypUaAGHsHjQlLLYBzgk6ti5Vwak3Z7Cht4q7qppfdIS6o4gB6@[87.151.219.230]) by fwd12.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1bXXvs-264xP60; Wed, 10 Aug 2016 20:08:48 +0200 Subject: Re: Possible zpool online, resilvering issue To: Ultima References: <196319fe-8113-bb2d-74b7-fbdd3369d988@freebsd.org> Cc: freebsd-current@freebsd.org From: Stefan Esser Message-ID: <2f93e8dd-83d5-c8e1-1dd2-5c8ee98597a6@freebsd.org> Date: Wed, 10 Aug 2016 20:08:46 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ID: G-d9nuZlrhJJosGR4ypUaAGHsHjQlLLYBzgk6ti5Vwak3Z7Cht4q7qppfdIS6o4gB6 X-TOI-MSGID: 4918bb5f-e91f-4b03-a675-efbce737f488 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 10 Aug 2016 18:09:01 -0000 Am 10.08.2016 um 18:53 schrieb Ultima: > Hello, > >> I didn't see any reply on the list, so I thought I might let you know > > Sorry, never received this reply (till now) xD > >>what I assume is happening: > >> ZFS never updates data in place, which affects inode updates, e.g. if >> a file has been read and access times must be updated. (For that reason, >> many ZFS file systems are configured to ignore access time updates). > >> Even if there were only R/O accesses to files in the pool, there will >> have been updates to the inodes, which were missed by the offlined >> drives (unless you ignore atime updates). > >> But even if there are no access time updates, ZFS might have written >> new uberblocks and other meta information. Check the POOL history and >> see if there were any TXGs created during the scrub. > >> If you scrub the pooll while it is off-line, it should stay stable >> (but if any information about the scrub, the offlining of drives etc. >> is recorded in the pool's history log, differences are to be expected). > >> Just my $.02 ... > >> Regards, STefan > > Thanks for the reply, I'm not completely sure what would be considered a > TXG. Maintained normal operations during most this noise and this pool > has quite a bit of activity during normal operations. My zpool history > looks like it gos on forever and the last scrub is showing it repaired > 9.48G. That was for all these access time updates? I guess that would be > a little less then 2.5G per disk worth. > > The zpool history looks like it gos on forever (733373 lines). This pool > has much of this activity with poudriere. All the entries I see are > clone, destroy, rollback and snapshotting. I can't really say how much > but at least 500 (prob much more than that) entries between the last two > scrubs. Atime is off on all datasets. > > So to be clear, this is expected behavior with atime=off + TXGs during > offline time? I had thought that the resilver after onlining the disk > would bring that disk up-to-date with the pool. I guess my understanding > was a bit off. Sorry, you'll have to ask somebody more familiar with ZFS internals than me. I just wanted to point out, that scrub might change the state of the drives, even though no file data is modified. Some 10 GB "repaired" on a 35000 GB pool is not much, it is about what I'd expect to be required for meta-data. BTW: The pool history is chronologically sorted, you need only check the last few lines (written after the start time of the scrub, or rather written after offlining some of the disk drives). Regards, STefan From owner-freebsd-current@freebsd.org Wed Aug 10 18:46:57 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 42D67BB5AEF; Wed, 10 Aug 2016 18:46:57 +0000 (UTC) (envelope-from cgull@glup.org) Received: from glup.org (216-15-121-172.c3-0.smr-ubr2.sbo-smr.ma.static.cable.rcn.com [216.15.121.172]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 008C51762; Wed, 10 Aug 2016 18:46:57 +0000 (UTC) (envelope-from cgull@glup.org) Received: from minipixel.i.glup.org (unknown [198.206.215.1]) by glup.org (Postfix) with ESMTPSA id D0C65854C4; Wed, 10 Aug 2016 14:46:55 -0400 (EDT) Authentication-Results: glup.org; dmarc=none header.from=glup.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=glup.org; s=201009; t=1470854815; bh=vRNvSvKsy1Xn0ZDMzGEd/foVVUl5eJlH2Ur3uGm//wA=; h=From:Subject:To:References:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=HQTnDB7JKaHIONYd60sRSUzJtR254tI5/T0Hvywbq6uZp9hXFALyp1iux3zha/t3T tUzzBWgyLG8wlUisHC51UwvpBHhDMd+XyVEKB6g8mC3IgmJYjmSPoXQXy96M8arF/T 2PMT1dO9uuGIaz5Y4MBv2MXa7G0ADDyeI8KYFQb5kgWKL6I+Liq/kbO9V3swmrZJ9k u9qdPIG1of9fjr9oKtA+VbzURZTxRk+j9wohVTQXWh0JDtkPJdoojSm/KC2AwnLrzJ RTPxndr+6fseEjx+He159r83r9F8/nwE+zbBTnlMJNviBT/YSH5dahEeD6IqkvDs5/ 3pSM3ZUNnr5gA== From: john hood Subject: Re: Mosh regression between 10.x and 11-stable To: Peter Jeremy , freebsd-ports@freebsd.org, freebsd-current@freebsd.org, mosh-devel@mit.edu, John Hood References: <20160810081831.GA65184@server.rulingia.com> Message-ID: <0daf3b02-55dd-6397-d64d-10a525d4b478@glup.org> Date: Wed, 10 Aug 2016 14:46:55 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160810081831.GA65184@server.rulingia.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 10 Aug 2016 18:46:57 -0000 On 8/10/16 4:18 AM, Peter Jeremy wrote: > I recently updated one of my VPS hosts from 10.3-RELEASE-p5 to 11.0-BETA4 > r303811 and mosh to that host from my Linux laptop stopped working. All > I get on the laptop is: > $ mosh remotehost > Connection to remotehost closed. > /usr/bin/mosh: Did not find mosh server startup message. > > I've tried rebuilding mosh (and all dependencies) on the host to no avail. I'm a mosh maintainer. mosh 1.2.5 (from ports) and mosh master (just last night tagged as 1.2.6, alas) work fine for me on my two 11.0-BETA4 systems, one local and one remote. > This isn't the DSA change that's been discussed elsewhere: I can SSH from my > laptop to the host without problem. I can also manually invoke mosh-client > and mosh-server and it works. Unfortunately, mosh has no provision for > debugging. I've tried hacking the mosh perl script to make it more verbose > and that shows that: > 1) the "MOSH CONNECT" message isn't making it out of the local ssh process. Do you know if the message is getting out of mosh-server? into sshd? Do you know if mosh-server is actually running? (It will log utmp entries on startup.) Mosh's debugging/logging isn't very good, but 'mosh-server new -v 2> logfile' does produce some useful info (mostly logging of network traffic). > 2) it's racy because I can get it from "always fails" to "sometimes works". How do you get it there? > My suspicion is that something has changed in either sshd or TCP that > is resulting in the connection going away before the stdout from the > remote mosh-server makes it out from the local ssh process. mosh does 'ssh -t' and uses ptys. That's another potential point the message could get dropped. > I've looked at tcpdump's of both successful and failed SSH sessions > but don't see anything obviously different (encryption makes it > difficult to decode the session). > > Has anyone else seen this behaviour or have any ideas what might be > causing it? Common suspects include issues with shell login/invocation of mosh (are you making sure it's reachable in /usr/local/bin with $PATH or '--server=/usr/local/bin/mosh'? are your login shell and its login scripts unusual?) On Linux we've had issues with ecryptfs and systemd breaking mosh-server when the ssh session ends, but I don't think that applies here. regards, --jh From owner-freebsd-current@freebsd.org Wed Aug 10 18:56:21 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3553CBB5E00 for ; Wed, 10 Aug 2016 18:56:21 +0000 (UTC) (envelope-from ohauer@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 9E00B1E90 for ; Wed, 10 Aug 2016 18:56:19 +0000 (UTC) (envelope-from ohauer@gmx.de) Received: from [192.168.100.100] ([87.139.233.65]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LabZr-1anjnx3XPr-00mMC3; Wed, 10 Aug 2016 20:56:10 +0200 Subject: Re: Possible zpool online, resilvering issue To: freebsd-current@freebsd.org References: From: olli hauer Cc: Ultima Message-ID: Date: Wed, 10 Aug 2016 20:56:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:n3EixQ+C89zSZRA59bL29IRSAfnG9kRRK+N1LBxbF2vOgdeHwzG Li/fTdSOk9Ilqwt7NDalAuF1XZfX/7xwEOcib7cD3PnGWy/BqECSxgC7QeNcN/l+zSTxJfL hDtT+IltcBRezFGCmc1SStQUhYB7NVE7D4YMoo2AypYVwpLBEH7Lkonx+yD6D0pNsUePNr8 M/LK+ku/dprVkYOfh+vtg== X-UI-Out-Filterresults: notjunk:1;V01:K0:0EIEyQc+Jdc=:s5+ZXuEOdyyK3t50cQgCdW slpZhIeg+ycpHEnP4+nWBilQ8e/D/FYsL7qb2yDryHZ3Iigj9zZclk+/a332jezuvSopb6JQ+ 86sVkqJZ2h6XcoD0YTMnzXwDynwSq73zpAYuV0p4babNvKJu85iqdYejqjTwMbrRVdAQ7q8dt rii1AjxsDXFb7VQjn6/ALjx89Tsig1MVMauckmFZs9BCD+RBEzFyZTk0kbm3sN91RZQw2rwHo govr8hRTgEVFcY7Bf3oKDtX2bkC67+dklVObz8PYEj2KxtvsThTJfEqZ0Z4bSlMY1EwVbMelK wWHjb5hZPib2zHklWzrq9n653U5ynVNCeYUTkl6l6FA1bJYFvt+N8VYPxZir+qRMzPx49HdT7 Rx4NeiDTpSQbhRBZVdmBnemh9qtbuRc5T/BXsy1sJqxlRZnrAlOh2dagvgiyO57pFuzGhK3Z4 Dd7l+GlfapL2DTDmxOTmsaknA8LNIgs0/dt20mizZC9cFtoj4rG6MzPvTvFGfq1LofP5jEaqa B5MkcJcZEWi/gpn7Ol+nPaoTUtJgRK73LsrA0ZVLLM/GJXuCnx4g59cI1cQ505lTAFTWIFy4X boQo1KzZEl6aA8rbbFrSW5k8EuVtQvNgrpaIvRTgwKmKp8sNxLKL7kcuNGTkpX9oj+wl56I5y mkEhofAkExNY0zZfYxRri+l1dfcJ1NAQMK0R3C/WtM5WdqcSK8Wo1RyHOKOXTNW+XIw6RYI+J JiK/Cr74BmIBTv8DBEfSMSoPsHYGEQqdM2Ft9Un2PX/BNl8bWDfEEVoxtSUwIo9vCjW6jEIn5 2UV35fo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 10 Aug 2016 18:56:21 -0000 On 2016-08-04 07:22, Ultima wrote: > Hello, > > I recently had some issue with a PSU and ran several scrubs on a pool with > around 35T. Random drives would drop and require a zpool online, this found > checksum errors. (as expected) However, after all the scrubs I ran, I think > I may have found a bug with zpool online resilvering process. > > 24 disks total, 4 vdevs raidz2 (6 drives each). > > Before this next part... I had a backup PSU, however it was also going bad > and waiting for RMA. The current one seemed to be dieing but ran fine with > less drives. So I decided I would run the server short 4 drives. > > Started by offline(or already removed from psu) 4 drives from different > vdevs, then ran a scrub to verify everything. Many sum errors were present > on some of the drives, but this was expected due to faulty psu. Then > offlined 4 different drives and onlined the other 4 and scrubbed once > again. After resilver, again, many sum errors on these drives as expected. > > After the scrub completed, I decided to offline 4 different drives, then > online the ones that were out of pool for awhile. During the resilver, > checksum errors were once again found. I was surprised due to the recent > scrub, So I decided to run another scrub, and it found even more checksum > errors on these recently onlined drives. I didn't think much about it, > however after the replacement PSU arrived, I onlined all the drives out of > pool and again, resilver had checksum errors as well as another scrub with > more sum errors. > > Is this issue known? Is it common for a scrub to be required after onlining > a disk that was out of pool for some time? > > The drives are ST4000NM0033, and until recent have never had a single > checksum error in they're lifetime.(at least with zfs) > FreeBSD S1 12.0-CURRENT FreeBSD 12.0-CURRENT #19 r303224: Sat Jul 23 > 10:41:12 EDT 2016 > root@S1:/usr/src/head/obj/usr/src/head/src/sys/MYKERNEL-NODEBUG > amd64 > > > Sorry for the wall of text, but I hope this helps in tracking down this > possible bug. > Perhaps on or more of the drives running out of Realloc Sectors? I had once a case where smartctl showed no issues but zfs scrubbing showed a defect, some weeks later smartctl was showing some reallocated sectors and one week later the HD was out of spare sectors. Have you already tested every single HD for smart issues? -- olli From owner-freebsd-current@freebsd.org Wed Aug 10 18:39:35 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0D512BB5639; Wed, 10 Aug 2016 18:39:35 +0000 (UTC) (envelope-from cgull@glup.org) Received: from glup.org (216-15-121-172.c3-0.smr-ubr2.sbo-smr.ma.static.cable.rcn.com [216.15.121.172]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C4C221A8A; Wed, 10 Aug 2016 18:39:34 +0000 (UTC) (envelope-from cgull@glup.org) Received: from minipixel.i.glup.org (unknown [198.206.215.1]) by glup.org (Postfix) with ESMTPSA id 7A1E5854C4; Wed, 10 Aug 2016 14:32:15 -0400 (EDT) Authentication-Results: glup.org; dmarc=none header.from=glup.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=glup.org; s=201009; t=1470853935; bh=vRNvSvKsy1Xn0ZDMzGEd/foVVUl5eJlH2Ur3uGm//wA=; h=Subject:To:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=T0Ay7S6xOEvZ3to038UPJEyPMkinrDripQvOo+eYKGmlb1/6Uxm5x2keph5BkYq5Q wNuNgmfROp+TrPO2fjsMySJMD9sXOZWGVUwpwGDp+WJ5cX0Eerjxm5LthjlBrXTh9l KQniE7vJ6XPk5jo9v5oz3568hvKu3N1k0KfWROYPEgwIJaRyHZemypGDnL3L6D1bMm GqyIYoFqmfB3xOGIh/i44hxlVHPZXbU/0VvzQGm3hUWugloap5KhFwK83Qw9r2WVhE Fq35Vrb95RryQjAjUuRLTJoN6Vy0LRNk8fSNJoHgm0qHzycQHQcDLKf/GTjpsT29q6 vF5nO87rVSZvw== Subject: Re: Mosh regression between 10.x and 11-stable To: Peter Jeremy , freebsd-ports@freebsd.org, freebsd-current@freebsd.org, mosh-devel@mit.edu References: <20160810081831.GA65184@server.rulingia.com> From: john hood Message-ID: Date: Wed, 10 Aug 2016 14:32:15 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160810081831.GA65184@server.rulingia.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 10 Aug 2016 19:03:58 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 10 Aug 2016 18:39:35 -0000 On 8/10/16 4:18 AM, Peter Jeremy wrote: > I recently updated one of my VPS hosts from 10.3-RELEASE-p5 to 11.0-BETA4 > r303811 and mosh to that host from my Linux laptop stopped working. All > I get on the laptop is: > $ mosh remotehost > Connection to remotehost closed. > /usr/bin/mosh: Did not find mosh server startup message. > > I've tried rebuilding mosh (and all dependencies) on the host to no avail. I'm a mosh maintainer. mosh 1.2.5 (from ports) and mosh master (just last night tagged as 1.2.6, alas) work fine for me on my two 11.0-BETA4 systems, one local and one remote. > This isn't the DSA change that's been discussed elsewhere: I can SSH from my > laptop to the host without problem. I can also manually invoke mosh-client > and mosh-server and it works. Unfortunately, mosh has no provision for > debugging. I've tried hacking the mosh perl script to make it more verbose > and that shows that: > 1) the "MOSH CONNECT" message isn't making it out of the local ssh process. Do you know if the message is getting out of mosh-server? into sshd? Do you know if mosh-server is actually running? (It will log utmp entries on startup.) Mosh's debugging/logging isn't very good, but 'mosh-server new -v 2> logfile' does produce some useful info (mostly logging of network traffic). > 2) it's racy because I can get it from "always fails" to "sometimes works". How do you get it there? > My suspicion is that something has changed in either sshd or TCP that > is resulting in the connection going away before the stdout from the > remote mosh-server makes it out from the local ssh process. mosh does 'ssh -t' and uses ptys. That's another potential point the message could get dropped. > I've looked at tcpdump's of both successful and failed SSH sessions > but don't see anything obviously different (encryption makes it > difficult to decode the session). > > Has anyone else seen this behaviour or have any ideas what might be > causing it? Common suspects include issues with shell login/invocation of mosh (are you making sure it's reachable in /usr/local/bin with $PATH or '--server=/usr/local/bin/mosh'? are your login shell and its login scripts unusual?) On Linux we've had issues with ecryptfs and systemd breaking mosh-server when the ssh session ends, but I don't think that applies here. regards, --jh From owner-freebsd-current@freebsd.org Wed Aug 10 23:20:29 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F2D84BB5EC1 for ; Wed, 10 Aug 2016 23:20:29 +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 D635E143F; Wed, 10 Aug 2016 23:20:29 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id CA6A5134B; Wed, 10 Aug 2016 23:20:29 +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 7D76D1D2CC; Wed, 10 Aug 2016 23:20: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 ApOkLb7WVsMR; Wed, 10 Aug 2016 23:20:25 +0000 (UTC) Subject: Re: PORTS_MODULES breakage on HEAD DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com DCBE51D2C6 To: Don Lewis , freebsd-current@FreeBSD.org References: <201608080044.u780iEuP026615@gw.catspoiler.org> From: Bryan Drewery Organization: FreeBSD Message-ID: Date: Wed, 10 Aug 2016 16:20:23 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <201608080044.u780iEuP026615@gw.catspoiler.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="XNaxvic0GobLdAWKtuVFkdsavi3cBG7aV" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 10 Aug 2016 23:20:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XNaxvic0GobLdAWKtuVFkdsavi3cBG7aV Content-Type: multipart/mixed; boundary="M6pmrDTCcc70hCPEK43Pf1EHtAAmDfqvK" From: Bryan Drewery To: Don Lewis , freebsd-current@FreeBSD.org Message-ID: Subject: Re: PORTS_MODULES breakage on HEAD References: <201608080044.u780iEuP026615@gw.catspoiler.org> In-Reply-To: <201608080044.u780iEuP026615@gw.catspoiler.org> --M6pmrDTCcc70hCPEK43Pf1EHtAAmDfqvK Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 8/7/16 5:44 PM, Don Lewis wrote: > Adding PORTS_MODULES=3Demulators/virtualbox-ose-kmod recently broke on > HEAD. When I do that I get this failure: >=20 > =3D=3D=3D> Ports module emulators/virtualbox-ose-kmod (all) > cd ${PORTSDIR:-/usr/ports}/emulators/virtualbox-ose-kmod; PATH=3D/usr/o= bj/usr/src/ > tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/sr= c/tmp/leg > acy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbi= n:/bin:/u > sr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin SRC_BASE=3D/usr/src O= SVERSION=3D12 > 00000 WRKDIRPREFIX=3D/usr/obj/usr/src/sys/ make -B clean all > =3D=3D=3D> Cleaning for virtualbox-ose-kmod-5.0.26_1 > =3D=3D=3D> License GPLv2 accepted by the user > =3D=3D=3D> Found saved configuration for virtualbox-ose-kmod-4.3.34 > =3D=3D=3D> virtualbox-ose-kmod-5.0.26_1 depends on file: /usr/local/s= bin/pkg - found > =3D=3D=3D> Fetching all distfiles required by virtualbox-ose-kmod-5.0.2= 6_1 for buildin > g > =3D=3D=3D> Extracting for virtualbox-ose-kmod-5.0.26_1 > =3D> SHA256 Checksum OK for VirtualBox-5.0.26.tar.bz2. > =3D=3D=3D> Patching for virtualbox-ose-kmod-5.0.26_1 > =3D=3D=3D> Applying FreeBSD patches for virtualbox-ose-kmod-5.0.26_1 > =3D=3D=3D> virtualbox-ose-kmod-5.0.26_1 depends on executable: kmk - = found > =3D=3D=3D> Configuring for virtualbox-ose-kmod-5.0.26_1 > Checking for environment: Determined build machine: freebsd.amd64, targ= et machin > e: freebsd.amd64, OK. > Checking for kBuild: found, OK. > Checking for gcc: > ** cc -target x86_64-unknown-freebsd12.0 --sysroot (variable CC) not = found! > Check /usr/obj/usr/src/sys/usr/ports/emulators/virtualbox-ose-kmod/work= /VirtualB > ox-5.0.26/configure.log for details > =3D=3D=3D> Script "configure" failed unexpectedly. > Please report the problem to vbox@FreeBSD.org [maintainer] and attach t= he > "/usr/obj/usr/src/sys//usr/ports/emulators/virtualbox-ose-kmod/work/Vir= tualBox-5 > .0.26/config.log" >=20 >=20 > It appears that the problem is due to CC being set to: > cc -target x86_64-unknown-freebsd12.0 --sysroot > and the Makefile for the port passes this: > --with-gcc=3D"${CC}" > to configure. The configure script passes $CC to check_avail, which > does a -z test on it. >=20 > I think that CC should just be set to "cc" and the rest should get adde= d > to CFLAGS. I suspect this got broken by the recent crossbuild changes.= >=20 It's a SYSTEM_COMPILER bug. I'll look into fixing it. For now you can try passing WITHOUT_SYSTEM_COMPILER=3Dyes as a workaround= =2E --=20 Regards, Bryan Drewery --M6pmrDTCcc70hCPEK43Pf1EHtAAmDfqvK-- --XNaxvic0GobLdAWKtuVFkdsavi3cBG7aV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXq7a4AAoJEDXXcbtuRpfPQr8H/jzeGph7Epn2M3kbbqCvQTvG qWM1GwhMGKpcz3UxpNZRD6ICfnpebZ4ep3OnDc+K6I4wvcifw1o6trwCs8mXxYBk J8P0BxN2jtXJtrQDRYYQi2hyg5dsmpxIBjssNvuml9mhuqhv8qnkIPA18weHThWr ymmGMki760fW1xOczJfjDFgfh0zwOUeqr7mwWpCg0FnYpUO5tGRqMlpuI0WCecig Xu0NnBwHldW5EDNQidHVrxMyG/rdE/0DItKpZ/CLL5T2WzcgcB3FyCKfHYobLKjE RXbzxYGuL8jcPshbNCfFdNixIJNF7CI2Sg25E3AvgZ3lfvSuKxCuT8MmxlnZphI= =ycJ7 -----END PGP SIGNATURE----- --XNaxvic0GobLdAWKtuVFkdsavi3cBG7aV-- From owner-freebsd-current@freebsd.org Wed Aug 10 23:40:36 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6F58FBB5287 for ; Wed, 10 Aug 2016 23:40:36 +0000 (UTC) (envelope-from jkim@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 ECBFA1D1F; Wed, 10 Aug 2016 23:40:35 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Subject: Re: kernel panic caused by virtualbox(?) To: Konstantin Belousov , Don Lewis References: <20160808183743.GL83214@kib.kiev.ua> <201608082344.u78NiK1V030408@gw.catspoiler.org> <20160809091230.GQ83214@kib.kiev.ua> Cc: freebsd-current@freebsd.org, jhb@freebsd.org From: Jung-uk Kim Message-ID: Date: Wed, 10 Aug 2016 19:40:31 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160809091230.GQ83214@kib.kiev.ua> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ccdJQC0AGf00xMkxKCAAkJtOsNtXJ4wpS" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 10 Aug 2016 23:40:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ccdJQC0AGf00xMkxKCAAkJtOsNtXJ4wpS Content-Type: multipart/mixed; boundary="0mSLbSBcI8Q4u5xdTcVVRBScbAuqUDecg" From: Jung-uk Kim To: Konstantin Belousov , Don Lewis Cc: freebsd-current@freebsd.org, jhb@freebsd.org Message-ID: Subject: Re: kernel panic caused by virtualbox(?) References: <20160808183743.GL83214@kib.kiev.ua> <201608082344.u78NiK1V030408@gw.catspoiler.org> <20160809091230.GQ83214@kib.kiev.ua> In-Reply-To: <20160809091230.GQ83214@kib.kiev.ua> --0mSLbSBcI8Q4u5xdTcVVRBScbAuqUDecg Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 08/09/16 05:12 AM, Konstantin Belousov wrote: > On Mon, Aug 08, 2016 at 04:44:20PM -0700, Don Lewis wrote: >> On 8 Aug, Konstantin Belousov wrote: >>> On Mon, Aug 08, 2016 at 10:22:44AM -0700, John Baldwin wrote: >>>> On Thursday, August 04, 2016 05:10:29 PM Don Lewis wrote: >>>>> Reposted to -current to get some more eyes on this ... >>>>> >>>>> I just got a kernel panic when I started up a CentOS 7 VM in virtua= lbox. >>>>> The host is: >>>>> FreeBSD 12.0-CURRENT #17 r302500 GENERIC amd64 >>>>> The virtualbox version is: >>>>> virtualbox-ose-5.0.26 >>>>> virtualbox-ose-kmod-5.0.26_1 >>>>> >>>>> The panic message is: >>>>> >>>>> panic: Unregistered use of FPU in kernel >>>>> cpuid =3D 1 >>>>> KDB: stack backtrace: >>>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffff= e085a55d030 >>>>> vpanic() at vpanic+0x182/frame 0xfffffe085a55d0b0 >>>>> kassert_panic() at kassert_panic+0x126/frame 0xfffffe085a55d120 >>>>> trap() at trap+0x7ae/frame 0xfffffe085a55d330 >>>>> calltrap() at calltrap+0x8/frame 0xfffffe085a55d330 >>>>> --- trap 0x16, rip =3D 0xffffffff827dd3a9, rsp =3D 0xfffffe085a55d4= 08, rbp =3D 0xfffffe085a55d430 --- >>>>> g_pLogger() at 0xffffffff827dd3a9/frame 0xfffffe085a55d430 >>>>> g_pLogger() at 0xffffffff8274e5c7/frame 0x3 >>>>> KDB: enter: panic >>>>> >>>>> Since g_pLogger is a symbol in vboxdrv.ko, it looks like virtualbox= is >>>>> the trigger. >>>>> >>>>> There are no symbols for the virtualbox kmods, possibly because I >>>>> installed them as an upgrade using packages (built with the same so= urce >>>>> tree version) instead of by using PORTS_MODULES in make.conf, so po= rts >>>>> kgdb didn't have anything useful to say about what happened before = the >>>>> trap. >>>>> >>>>> This panic is very repeatable. I just got another one when startin= g the >>>>> same VM., but this time the two calls before the trap were >>>>> null_bug_bypass(). Hmn, that symbol is in nullfs ... >>>>> >>>>> I don't see this with a Windows 7 VM. >>>>> >>>>> All of the virtualbox kmod files are compiled with -mno-mmx -mno-ss= e >>>>> -msoft-float -mno-aes -mno-avx >>> Your disassemble listed fxrstor instruction that failing, or did I >>> mis-remembered ? This is most likely some context switch code, either= >>> by virtual machine or erronously executed guest code. It is not a >>> spontaneous use of FPU, but more likely something different. Can you >>> confirm ? >>> >>> In either case, I do not remember any KBI changes around PCB layout o= r >>> fpu_enter() KPI recently. >>> >>>> >>>> I suspect head packages are quite likely built against the a "wrong"= KBI >>>> and are too fragile to use for kmods vs compiling from ports. :-/ I= would >>>> try a built-from-ports kmod to see if the panics go away. >>> >>> FWIW, I will commit the following change shortly. Since third-party >>> modules break the invariant, either due to bugs (ndis wrappers) or >>> possibly due to KBI breakage, it is worth to have the detection enabl= ed >>> for production kernels. >> >> Interesting ... I tried running virtualbox on recent 10.3-STABLE with = a >> GENERIC kernel and the guest seemed to operate properly. Then I enabl= ed >> INVARIANTS and got the panic. I suspect that is why nobody has stumbl= ed >> across this before. >> > This is yet another reason to promote KASSERT to the full panic. > I expect that the vbox source lacks fpu_kern_enter() calls around the > FPU state restoration. Unfortunately, the code is in MI source as it is unnecessary for supported OSes (read: FreeBSD is not supported) and it's not easy to inject fpu_kern_enter()/fpu_kern_leave() calls there. :-( Jung-uk Kim --0mSLbSBcI8Q4u5xdTcVVRBScbAuqUDecg-- --ccdJQC0AGf00xMkxKCAAkJtOsNtXJ4wpS 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 iQEcBAEBCAAGBQJXq7tvAAoJEHyflib82/FGUIIH/3Iwm/g/qCesL+GvokRPPKBV qyW3vvcNKggNIVovOkQgMkK62LRHEOWxor3CBAJIJ2pvt9XvaQVnz/u/NdcR5eOk 22/9rBZRn50nKM4zfQ04kMPo5EE3gS+dQXz/SK7S8AQogsav/DNMBOP84iYPbSmY KN42i/7jek9tmqVkqYCTUh1IxDCHns3b30TUPDQP/1A6eRxinapadxOUaKF90r3I uYILXhfZaumHqrA1njY20HR5AhFBmL1KZ1LM4vfarMzZoxtHSG840qTKepdPlSNB H9Cpgq5iepvwkuXLd0C1H2+x8fqN/cTeNm+IV3LxEuVuiC9HZQGco5R7phyP1Sg= =K4oD -----END PGP SIGNATURE----- --ccdJQC0AGf00xMkxKCAAkJtOsNtXJ4wpS-- From owner-freebsd-current@freebsd.org Wed Aug 10 23:47:27 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 617FFBB54D3 for ; Wed, 10 Aug 2016 23:47:27 +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 3C0801226; Wed, 10 Aug 2016 23:47:27 +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 u7ANlFhl038491; Wed, 10 Aug 2016 16:47:19 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201608102347.u7ANlFhl038491@gw.catspoiler.org> Date: Wed, 10 Aug 2016 16:47:15 -0700 (PDT) From: Don Lewis Subject: Re: kernel panic caused by virtualbox(?) To: jkim@FreeBSD.org cc: kostikbel@gmail.com, freebsd-current@freebsd.org, jhb@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 10 Aug 2016 23:47:27 -0000 On 10 Aug, Jung-uk Kim wrote: > On 08/09/16 05:12 AM, Konstantin Belousov wrote: >> On Mon, Aug 08, 2016 at 04:44:20PM -0700, Don Lewis wrote: >>> On 8 Aug, Konstantin Belousov wrote: >>>> On Mon, Aug 08, 2016 at 10:22:44AM -0700, John Baldwin wrote: >>>>> On Thursday, August 04, 2016 05:10:29 PM Don Lewis wrote: >>>>>> Reposted to -current to get some more eyes on this ... >>>>>> >>>>>> I just got a kernel panic when I started up a CentOS 7 VM in virtualbox. >>>>>> The host is: >>>>>> FreeBSD 12.0-CURRENT #17 r302500 GENERIC amd64 >>>>>> The virtualbox version is: >>>>>> virtualbox-ose-5.0.26 >>>>>> virtualbox-ose-kmod-5.0.26_1 >>>>>> >>>>>> The panic message is: >>>>>> >>>>>> panic: Unregistered use of FPU in kernel >>>>>> cpuid = 1 >>>>>> KDB: stack backtrace: >>>>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe085a55d030 >>>>>> vpanic() at vpanic+0x182/frame 0xfffffe085a55d0b0 >>>>>> kassert_panic() at kassert_panic+0x126/frame 0xfffffe085a55d120 >>>>>> trap() at trap+0x7ae/frame 0xfffffe085a55d330 >>>>>> calltrap() at calltrap+0x8/frame 0xfffffe085a55d330 >>>>>> --- trap 0x16, rip = 0xffffffff827dd3a9, rsp = 0xfffffe085a55d408, rbp = 0xfffffe085a55d430 --- >>>>>> g_pLogger() at 0xffffffff827dd3a9/frame 0xfffffe085a55d430 >>>>>> g_pLogger() at 0xffffffff8274e5c7/frame 0x3 >>>>>> KDB: enter: panic >>>>>> >>>>>> Since g_pLogger is a symbol in vboxdrv.ko, it looks like virtualbox is >>>>>> the trigger. >>>>>> >>>>>> There are no symbols for the virtualbox kmods, possibly because I >>>>>> installed them as an upgrade using packages (built with the same source >>>>>> tree version) instead of by using PORTS_MODULES in make.conf, so ports >>>>>> kgdb didn't have anything useful to say about what happened before the >>>>>> trap. >>>>>> >>>>>> This panic is very repeatable. I just got another one when starting the >>>>>> same VM., but this time the two calls before the trap were >>>>>> null_bug_bypass(). Hmn, that symbol is in nullfs ... >>>>>> >>>>>> I don't see this with a Windows 7 VM. >>>>>> >>>>>> All of the virtualbox kmod files are compiled with -mno-mmx -mno-sse >>>>>> -msoft-float -mno-aes -mno-avx >>>> Your disassemble listed fxrstor instruction that failing, or did I >>>> mis-remembered ? This is most likely some context switch code, either >>>> by virtual machine or erronously executed guest code. It is not a >>>> spontaneous use of FPU, but more likely something different. Can you >>>> confirm ? >>>> >>>> In either case, I do not remember any KBI changes around PCB layout or >>>> fpu_enter() KPI recently. >>>> >>>>> >>>>> I suspect head packages are quite likely built against the a "wrong" KBI >>>>> and are too fragile to use for kmods vs compiling from ports. :-/ I would >>>>> try a built-from-ports kmod to see if the panics go away. >>>> >>>> FWIW, I will commit the following change shortly. Since third-party >>>> modules break the invariant, either due to bugs (ndis wrappers) or >>>> possibly due to KBI breakage, it is worth to have the detection enabled >>>> for production kernels. >>> >>> Interesting ... I tried running virtualbox on recent 10.3-STABLE with a >>> GENERIC kernel and the guest seemed to operate properly. Then I enabled >>> INVARIANTS and got the panic. I suspect that is why nobody has stumbled >>> across this before. >>> >> This is yet another reason to promote KASSERT to the full panic. >> I expect that the vbox source lacks fpu_kern_enter() calls around the >> FPU state restoration. > > Unfortunately, the code is in MI source as it is unnecessary for > supported OSes (read: FreeBSD is not supported) and it's not easy to > inject fpu_kern_enter()/fpu_kern_leave() calls there. :-( It's a headache, but our ports can use patch files for that sort of thing ... From owner-freebsd-current@freebsd.org Thu Aug 11 01:52:05 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D5E3BBB32B7 for ; Thu, 11 Aug 2016 01:52:05 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::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 88DAC1335 for ; Thu, 11 Aug 2016 01:52:05 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: by mail-yb0-x230.google.com with SMTP id g133so19969277ybf.2 for ; Wed, 10 Aug 2016 18:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9RDLpM4NZECtV2/0Q1u0BI0S1oQonexjCrcs7hy9gPo=; b=fAqRN2xda53ABDsY2ufopFGjKoZHYtxUND0MuTriyoAaA2ynzBVTRd6pOuevS9s8Z/ keWOeJHbIBTaop2T6qwvYJAcUIkHihcSEf33DaKWfQ4MRBpa322BolGybMpfSS43+UIm TZjjAQHPUlFOXyXWt6NVCEywnwsPGahrB9FA9EcDCA1xLGD6h/7HdauhLWT/l+GeZ0Ug W7bxtS/B1917T4arD8qo+7+XXjocraV3B3pOTfUYlvHvmQn/U4yJn6nDwEVLZYytAppi FkIzVyc18R/fAMxZPloCdkJzdHL4MWkEXf8zsXRlR48LrPcdPOYsO238YlvWnemBZ5Al Lvuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9RDLpM4NZECtV2/0Q1u0BI0S1oQonexjCrcs7hy9gPo=; b=mPg7SH17o1oekhXaT9NwY/u7eVTHGu65XaptePvHuPaeGAuqZTN/hjpYkWB7c3xoL6 iZ5FAmXFHjnI0qF9Y3287C1BFUkEUaBupcdMnkSOJuzULoDdPlbAL+7SG4E0hMBYo3dg P8UhZ60B67WxTRUzH6J+JXubQXsJ3wpPumu5aasYJnoucfNYMJOUheRpNUlkj52kXyJT 2R3KPI3gnV2uKZ2XbR0XDia9sjD4t5fqEM0H06U42FYoCKj9U0VTiQzsAq1hC/C7mx/1 6qapoh76XgaBBtrVjdu2ZEAorovbEvl9bwNkvPeSbqTJ4nFcx130Ug89NYA9QMI61JBr csuA== X-Gm-Message-State: AEkoouvpZ19Kba6enh9H437wPRZESIIEerC6KwS4k/stB6v+Gv+p551bATGRuOz1FrZiHkuBpxQCohfYsNzf/A== X-Received: by 10.37.201.131 with SMTP id z125mr4371141ybf.183.1470880324449; Wed, 10 Aug 2016 18:52:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.51.150 with HTTP; Wed, 10 Aug 2016 18:52:03 -0700 (PDT) In-Reply-To: References: From: Ultima Date: Wed, 10 Aug 2016 21:52:03 -0400 Message-ID: Subject: Re: Possible zpool online, resilvering issue To: olli hauer Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 Aug 2016 01:52:05 -0000 > A new transaction group (TXG) is created at LEAST every > vfs.zfs.txg.timeout (defaults to 5) seconds. > f you offline a drive for hours or more, it must have all blocks with a > 'birth time' newer than the last transaction that was recorded on the > offlined drive replayed to catch that drive up to the other drives in > the pool. > As long as you have enough redundancy, the checksum errors can be > corrected without concern. > In the end, the checksum errors can be written off as being caused by > the bad hardware. After you finish the scrub and everything is OK, do: > 'zpool clear poolname', and it will reset all of the error and checksum > counts to 0, so you can track if any more ever show up. Thanks Allan, can always count on you for crystal clear answers =]. I'm surprised tho that it would be concluded as bad hardware(assuming you mean hd?). Just seems like its too much of a coincidence. I always ran zpool clear each time after the resilver/scrub was completed. > Perhaps on or more of the drives running out of Realloc Sectors? > I had once a case where smartctl showed no issues but zfs scrubbing showed > a defect, some weeks later smartctl was showing some reallocated sectors > and one week later the HD was out of spare sectors. > Have you already tested every single HD for smart issues? Smartd is set to run a short test weekly on Tuesday Thursday and Saturday. Extended test is performed weekly on Tuesday an hour after the short test. This occurs on all 24 drives. A scrub is performed once per month on Saturday an hour after the short test. 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0 This is the value of Reallocated sectors on all the drives(I think this is the normal value?). This drives smart looks like the worst of the lot. === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED See vendor-specific Attribute list for marginal Attributes. General SMART Values: Offline data collection status: (0x82) Offline data collection activity was completed without error. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: ( 592) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 1) minutes. Extended self-test routine recommended polling time: ( 491) minutes. Conveyance self-test routine recommended polling time: ( 2) minutes. SCT capabilities: (0x50bd) SCT Status supported. SCT Error Recovery Control supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 072 063 044 Pre-fail Always - 20189561 3 Spin_Up_Time 0x0003 091 091 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 188 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 092 085 030 Pre-fail Always - 1802626788 9 Power_On_Hours 0x0032 081 081 000 Old_age Always - 17457 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 158 184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 188 Command_Timeout 0x0032 100 099 000 Old_age Always - 65537 189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 055 045 045 Old_age Always In_the_past 45 (Min/Max 34/51) 191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 0 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 157 193 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 867 194 Temperature_Celsius 0x0022 045 055 000 Old_age Always - 45 (0 22 0 0 0) 195 Hardware_ECC_Recovered 0x001a 053 011 000 Old_age Always - 20189561 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed without error 00% 17423 - # 2 Short offline Completed without error 00% 17412 - # 3 Short offline Completed without error 00% 17340 - # 4 Short offline Completed without error 00% 17293 - # 5 Extended offline Completed without error 00% 17261 - # 6 Short offline Completed without error 00% 17245 - # 7 Short offline Completed without error 00% 17173 - # 8 Short offline Completed without error 00% 17125 - # 9 Extended offline Completed without error 00% 17101 - #10 Short offline Completed without error 00% 17084 - #11 Short offline Completed without error 00% 17012 - #12 Short offline Completed without error 00% 16964 - #13 Extended offline Completed without error 00% 16927 - #14 Short offline Completed without error 00% 16916 - #15 Short offline Completed without error 00% 16916 - #16 Short offline Completed without error 00% 16844 - #17 Short offline Completed without error 00% 16805 - #18 Extended offline Completed without error 00% 16775 - #19 Short offline Completed without error 00% 16757 - #20 Short offline Completed without error 00% 16685 - #21 Short offline Completed without error 00% 16637 - SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. On Wed, Aug 10, 2016 at 2:56 PM, olli hauer wrote: > On 2016-08-04 07:22, Ultima wrote: > > Hello, > > > > I recently had some issue with a PSU and ran several scrubs on a pool > with > > around 35T. Random drives would drop and require a zpool online, this > found > > checksum errors. (as expected) However, after all the scrubs I ran, I > think > > I may have found a bug with zpool online resilvering process. > > > > 24 disks total, 4 vdevs raidz2 (6 drives each). > > > > Before this next part... I had a backup PSU, however it was also going > bad > > and waiting for RMA. The current one seemed to be dieing but ran fine > with > > less drives. So I decided I would run the server short 4 drives. > > > > Started by offline(or already removed from psu) 4 drives from different > > vdevs, then ran a scrub to verify everything. Many sum errors were > present > > on some of the drives, but this was expected due to faulty psu. Then > > offlined 4 different drives and onlined the other 4 and scrubbed once > > again. After resilver, again, many sum errors on these drives as > expected. > > > > After the scrub completed, I decided to offline 4 different drives, then > > online the ones that were out of pool for awhile. During the resilver, > > checksum errors were once again found. I was surprised due to the recent > > scrub, So I decided to run another scrub, and it found even more checksum > > errors on these recently onlined drives. I didn't think much about it, > > however after the replacement PSU arrived, I onlined all the drives out > of > > pool and again, resilver had checksum errors as well as another scrub > with > > more sum errors. > > > > Is this issue known? Is it common for a scrub to be required after > onlining > > a disk that was out of pool for some time? > > > > The drives are ST4000NM0033, and until recent have never had a single > > checksum error in they're lifetime.(at least with zfs) > > FreeBSD S1 12.0-CURRENT FreeBSD 12.0-CURRENT #19 r303224: Sat Jul 23 > > 10:41:12 EDT 2016 > > root@S1:/usr/src/head/obj/usr/src/head/src/sys/MYKERNEL-NODEBUG > > amd64 > > > > > > Sorry for the wall of text, but I hope this helps in tracking down this > > possible bug. > > > > Perhaps on or more of the drives running out of Realloc Sectors? > I had once a case where smartctl showed no issues but zfs scrubbing showed > a defect, some weeks later smartctl was showing some reallocated sectors > and one week later the HD was out of spare sectors. > > Have you already tested every single HD for smart issues? > > -- > olli > From owner-freebsd-current@freebsd.org Thu Aug 11 05:05:15 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BFDEFBB5631; Thu, 11 Aug 2016 05:05:15 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 857E31C07; Thu, 11 Aug 2016 05:05:15 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1bXiB6-000JeY-MK>; Thu, 11 Aug 2016 07:05:12 +0200 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=freyja.zeit4.iv.bundesimmobilien.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1bXiB6-000WkZ-DP>; Thu, 11 Aug 2016 07:05:12 +0200 Date: Thu, 11 Aug 2016 07:05:05 +0200 From: "O. Hartmann" To: freebsd-current , freebsd-ports Subject: Passwordless accounts vi ports! Message-ID: <20160811070505.2c1a1466@freyja.zeit4.iv.bundesimmobilien.de> Organization: FU Berlin X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 87.138.105.249 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 Aug 2016 05:05:15 -0000 I just checked the security scanning outputs of FreeBSD and found this surprising result: [...] Checking for passwordless accounts: polkitd::565:565::0:0:Polkit Daemon User:/var/empty:/usr/sbin/nologin pulse::563:563::0:0:PulseAudio System User:/nonexistent:/usr/sbin/nologin saned::194:194::0:0:SANE Scanner Daemon:/nonexistent:/bin/sh clamav::106:106::0:0:Clamav Antivirus:/nonexistent:/usr/sbin/nologin bacula::910:910::0:0:Bacula Daemon:/var/db/bacula:/usr/sbin/nologin [...] Obviously, some ports install accounts but do not secure them as there is an empty password. I consider this not a feature, but a bug. Regards, Oliver From owner-freebsd-current@freebsd.org Thu Aug 11 05:16:49 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1A0B2BB5976; Thu, 11 Aug 2016 05:16:49 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::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 DF8601200; Thu, 11 Aug 2016 05:16:48 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pf0-x229.google.com with SMTP id y134so23036313pfg.0; Wed, 10 Aug 2016 22:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=idZzVd3ovuN36y0bXipkN2D54EEvo6aF2v/8CXgPbM8=; b=kE8AM7l0zJDdnHX33MmaaRmGneRAd3oDaGAKwSqZrcZLdXkQ6H41W49Wmw8XC2woqp P332IlAehUU7URmlS5oe5hhMm5FMeUutooaejAE9iH27JfIxxwW1FN2pOcRGdO8DHRnD wbKRf/3VPy7dl0XxU5AHmJp0dakS7o1b0tyaBBvvJel7fGYkdHclRlndJIEtjDtsczS9 swC1aqrELjd5VN1GQiLgm+q0hmSmDHbUct7oAOQWqW2+WTLSTFerr7IwZrhYTclSJqwo bs/lSxK6V72/tBrWwgCKLoYU6kWzf2mC9Z0D0iHOPXLx+ANLAHHdchDUYa4tuF30MuZu yp8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=idZzVd3ovuN36y0bXipkN2D54EEvo6aF2v/8CXgPbM8=; b=nHNuWL/bYZqIVbMBsxSArGdPgJzmCKUKY7cUvzS7xBO8bYTblHNsjqdTubd/Mvo823 +vQAkW8zqF6INilDcEwqe7BEN7hacxqjdjFIDgNc+Hj4ZeSC3Jlf5J9rdPdhnOj7Fwnz z8Ec/jAJMTdsuHYUPU+V1BukX+0yc4XVwgYuyVyZK0WurXgMqTr4pL/YtQDvNFbwG3/1 by8vcfFRnhDeuVLYJTeGwe7CNSlMRNvva1+V/GWqvpUOKMkQpbmImcMl7P+1Ye50YfUK 2DQTWcQSoRaco+p4L8Si8ZLJpaWdDieqvU+ciA2IF+2ilfXI+nW28PQyyKNaHbya7znn m9Zg== X-Gm-Message-State: AEkoous0WaTlR3kRIkrQMwbh/IUfVpszl/WA764Skme/A8Tot85hxgAfr+jbARLZDDteQQ== X-Received: by 10.98.130.137 with SMTP id w131mr13723259pfd.5.1470892608334; Wed, 10 Aug 2016 22:16:48 -0700 (PDT) Received: from [21.178.125.54] ([172.56.42.110]) by smtp.gmail.com with ESMTPSA id t80sm1263123pfj.38.2016.08.10.22.16.47 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 10 Aug 2016 22:16:47 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Passwordless accounts vi ports! From: Ngie Cooper X-Mailer: iPhone Mail (13G35) In-Reply-To: <20160811070505.2c1a1466@freyja.zeit4.iv.bundesimmobilien.de> Date: Wed, 10 Aug 2016 22:16:46 -0700 Cc: freebsd-current , freebsd-ports Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160811070505.2c1a1466@freyja.zeit4.iv.bundesimmobilien.de> To: "O. Hartmann" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 Aug 2016 05:16:49 -0000 > On Aug 10, 2016, at 22:05, O. Hartmann wrote= : >=20 > I just checked the security scanning outputs of FreeBSD and found this > surprising result: >=20 > [...] > Checking for passwordless accounts: > polkitd::565:565::0:0:Polkit Daemon User:/var/empty:/usr/sbin/nologin > pulse::563:563::0:0:PulseAudio System User:/nonexistent:/usr/sbin/nologin > saned::194:194::0:0:SANE Scanner Daemon:/nonexistent:/bin/sh > clamav::106:106::0:0:Clamav Antivirus:/nonexistent:/usr/sbin/nologin > bacula::910:910::0:0:Bacula Daemon:/var/db/bacula:/usr/sbin/nologin > [...] >=20 > Obviously, some ports install accounts but do not secure them as there is a= n > empty password. >=20 > I consider this not a feature, but a bug. saned is the only one that might concern me because the login shell isn't no= login(1). Cheers, -Ngie= From owner-freebsd-current@freebsd.org Thu Aug 11 05:17:44 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 20580BB5AD1; Thu, 11 Aug 2016 05:17:44 +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 D7B8713E5; Thu, 11 Aug 2016 05:17:43 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.87 (FreeBSD)) (envelope-from ) id 1bXiNC-000Jef-Kr; Thu, 11 Aug 2016 07:17:42 +0200 Date: Thu, 11 Aug 2016 07:17:42 +0200 From: Kurt Jaeger To: "O. Hartmann" Cc: freebsd-current , freebsd-ports Subject: Re: Passwordless accounts vi ports! Message-ID: <20160811051742.GB96200@home.opsec.eu> References: <20160811070505.2c1a1466@freyja.zeit4.iv.bundesimmobilien.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160811070505.2c1a1466@freyja.zeit4.iv.bundesimmobilien.de> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 Aug 2016 05:17:44 -0000 Hi! > I just checked the security scanning outputs of FreeBSD and found this > surprising result: > > [...] > Checking for passwordless accounts: > polkitd::565:565::0:0:Polkit Daemon User:/var/empty:/usr/sbin/nologin > pulse::563:563::0:0:PulseAudio System User:/nonexistent:/usr/sbin/nologin > saned::194:194::0:0:SANE Scanner Daemon:/nonexistent:/bin/sh > clamav::106:106::0:0:Clamav Antivirus:/nonexistent:/usr/sbin/nologin > bacula::910:910::0:0:Bacula Daemon:/var/db/bacula:/usr/sbin/nologin > [...] > > Obviously, some ports install accounts but do not secure them as there is an > empty password. > > I consider this not a feature, but a bug. Indeed, but I can't reproduce it on my hosts. There must be some reason for this to happen ? -- pi@opsec.eu +49 171 3101372 4 years to go ! From owner-freebsd-current@freebsd.org Thu Aug 11 05:59:06 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D0D82BB637C; Thu, 11 Aug 2016 05:59:06 +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 92EBC1A19; Thu, 11 Aug 2016 05:59:06 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1bXj1D-000TFX-T0>; Thu, 11 Aug 2016 07:59:03 +0200 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=freyja.zeit4.iv.bundesimmobilien.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1bXj1D-000aFO-LA>; Thu, 11 Aug 2016 07:59:03 +0200 Date: Thu, 11 Aug 2016 07:59:03 +0200 From: "O. Hartmann" To: Dewayne Geraghty Cc: Kurt Jaeger , freebsd-current , freebsd-ports Subject: Re: Passwordless accounts vi ports! Message-ID: <20160811075903.794706c3@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: References: <20160811070505.2c1a1466@freyja.zeit4.iv.bundesimmobilien.de> <20160811051742.GB96200@home.opsec.eu> Organization: FU Berlin X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 87.138.105.249 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 Aug 2016 05:59:06 -0000 On Thu, 11 Aug 2016 15:29:03 +1000 Dewayne Geraghty wrote: > Olivier, > I've checked my 10.3Stable systems and they all have '*' as their password, > which is consistent with /usr/ports/Mk/UIDs. You might like to check the > age of the latter. > Regards, Dewayne. > PS Both ports and src were built from updated src and ports from 2016-08-09 The system is a most recent CURRENT as compiled yesterday last time. The ports tree is also up to date and updated on a daily basis, so are the ports. Interestingly, the problem shows up only on one box so far, although all other systems are also CURRENT and updated the very same way. On another system, only user "bacula" has an empty password, were this user is set correctly with a "*"-password on another system, on which I installed bacula months earlier. I checked the installation of the ports and their installating the password-result again and all I tested (polkit, bacula, sane) did set the "*" as expected (I deleted manually the password entry via vipw before). I guess this "problem" is due to the fact I install ports and world on a daily basis on such systems and the likelyhood hitting a interim bug is very high. Regards, Oliver From owner-freebsd-current@freebsd.org Thu Aug 11 06:07:41 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EFEC7BB65C3; Thu, 11 Aug 2016 06:07:41 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by mx1.freebsd.org (Postfix) with ESMTP id 5D57C1F09; Thu, 11 Aug 2016 06:07:40 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ppp118-210-89-177.lns20.adl2.internode.on.net (HELO midget.dons.net.au) ([118.210.89.177]) by ipmail06.adl2.internode.on.net with ESMTP; 11 Aug 2016 15:37:38 +0930 Received: from [IPv6:::1] (ns.dons.net.au [10.0.2.1]) (authenticated bits=0) by midget.dons.net.au (8.15.1/8.14.9) with ESMTPSA id u7B67ZdE040308 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Aug 2016 15:37:36 +0930 (CST) (envelope-from darius@dons.net.au) X-Authentication-Warning: midget.dons.net.au: Host ns.dons.net.au [10.0.2.1] claimed to be [IPv6:::1] Subject: Re: Passwordless accounts vi ports! Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=us-ascii From: "O'Connor, Daniel" In-Reply-To: <3284EB4D-C546-42D8-971E-1778F0E0B02C@dons.net.au> Date: Thu, 11 Aug 2016 15:37:37 +0930 Cc: freebsd-current , freebsd-ports Content-Transfer-Encoding: quoted-printable Message-Id: <703B6B59-16D8-48B6-AC58-128EBDA13D92@dons.net.au> References: <20160811070505.2c1a1466@freyja.zeit4.iv.bundesimmobilien.de> <3284EB4D-C546-42D8-971E-1778F0E0B02C@dons.net.au> To: "O. Hartmann" X-Mailer: Apple Mail (2.3124) X-Spam-Score: -3.331 () ALL_TRUSTED,BAYES_00,RP_MATCHES_RCVD,URIBL_BLOCKED X-Scanned-By: MIMEDefang 2.75 on 10.0.2.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 Aug 2016 06:07:42 -0000 > On 11 Aug 2016, at 15:36, O'Connor, Daniel wrote: > My clamav and pulse users have a password field of * - i.e. they're = disabled (AND the shell is nologin) >=20 > I suspect this is a bug in the check not the ports. Sorry, I just saw your next email, please disregard. It does indeed look like a bug then, I don't have a -current box handy = to repro though sorry :( -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-current@freebsd.org Thu Aug 11 06:11:40 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E3426BB6751; Thu, 11 Aug 2016 06:11:40 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by mx1.freebsd.org (Postfix) with ESMTP id 50A56131D; Thu, 11 Aug 2016 06:11:39 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ppp118-210-89-177.lns20.adl2.internode.on.net (HELO midget.dons.net.au) ([118.210.89.177]) by ipmail06.adl2.internode.on.net with ESMTP; 11 Aug 2016 15:36:29 +0930 Received: from [IPv6:::1] (ns.dons.net.au [10.0.2.1]) (authenticated bits=0) by midget.dons.net.au (8.15.1/8.14.9) with ESMTPSA id u7B66RP8040292 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Aug 2016 15:36:28 +0930 (CST) (envelope-from darius@dons.net.au) X-Authentication-Warning: midget.dons.net.au: Host ns.dons.net.au [10.0.2.1] claimed to be [IPv6:::1] Subject: Re: Passwordless accounts vi ports! Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=us-ascii From: "O'Connor, Daniel" In-Reply-To: <20160811070505.2c1a1466@freyja.zeit4.iv.bundesimmobilien.de> Date: Thu, 11 Aug 2016 15:36:28 +0930 Cc: freebsd-current , freebsd-ports Content-Transfer-Encoding: quoted-printable Message-Id: <3284EB4D-C546-42D8-971E-1778F0E0B02C@dons.net.au> References: <20160811070505.2c1a1466@freyja.zeit4.iv.bundesimmobilien.de> To: "O. Hartmann" X-Mailer: Apple Mail (2.3124) X-Spam-Score: -3.331 () ALL_TRUSTED,BAYES_00,RP_MATCHES_RCVD,URIBL_BLOCKED X-Scanned-By: MIMEDefang 2.75 on 10.0.2.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 Aug 2016 06:11:41 -0000 > On 11 Aug 2016, at 14:35, O. Hartmann = wrote: > [...] > Checking for passwordless accounts: > polkitd::565:565::0:0:Polkit Daemon User:/var/empty:/usr/sbin/nologin > pulse::563:563::0:0:PulseAudio System = User:/nonexistent:/usr/sbin/nologin > saned::194:194::0:0:SANE Scanner Daemon:/nonexistent:/bin/sh > clamav::106:106::0:0:Clamav Antivirus:/nonexistent:/usr/sbin/nologin > bacula::910:910::0:0:Bacula Daemon:/var/db/bacula:/usr/sbin/nologin > [...] My clamav and pulse users have a password field of * - i.e. they're = disabled (AND the shell is nologin) I suspect this is a bug in the check not the ports. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-current@freebsd.org Thu Aug 11 06:33:29 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 399D1BB6D28; Thu, 11 Aug 2016 06:33:29 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 17CB712B7; Thu, 11 Aug 2016 06:33:28 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-226-8.lns20.per1.internode.on.net [121.45.226.8]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u7B6XNpT035239 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 10 Aug 2016 23:33:26 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: Passwordless accounts vi ports! To: Ngie Cooper , "O. Hartmann" References: <20160811070505.2c1a1466@freyja.zeit4.iv.bundesimmobilien.de> Cc: freebsd-current , freebsd-ports From: Julian Elischer Message-ID: Date: Thu, 11 Aug 2016 14:33:17 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.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.22 Precedence: 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, 11 Aug 2016 06:33:29 -0000 On 11/08/2016 1:16 PM, Ngie Cooper wrote: >> On Aug 10, 2016, at 22:05, O. Hartmann wrote: >> >> I just checked the security scanning outputs of FreeBSD and found this >> surprising result: >> >> [...] >> Checking for passwordless accounts: >> polkitd::565:565::0:0:Polkit Daemon User:/var/empty:/usr/sbin/nologin >> pulse::563:563::0:0:PulseAudio System User:/nonexistent:/usr/sbin/nologin >> saned::194:194::0:0:SANE Scanner Daemon:/nonexistent:/bin/sh >> clamav::106:106::0:0:Clamav Antivirus:/nonexistent:/usr/sbin/nologin >> bacula::910:910::0:0:Bacula Daemon:/var/db/bacula:/usr/sbin/nologin >> [...] >> >> Obviously, some ports install accounts but do not secure them as there is an >> empty password. >> >> I consider this not a feature, but a bug. > saned is the only one that might concern me because the login shell isn't nologin(1). but other tools use the password database.. e.g. ftp > > Cheers, > -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 Thu Aug 11 07:19:10 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 24790BB65E0 for ; Thu, 11 Aug 2016 07:19:10 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5089916D7; Thu, 11 Aug 2016 07:19:09 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA15010; Thu, 11 Aug 2016 10:19:07 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1bXkGh-0008XD-E9; Thu, 11 Aug 2016 10:19:07 +0300 Subject: Re: Boot environments and zfs canmount=noauto To: Allan Jude , freebsd-current@FreeBSD.org, rwestlun@gmail.com References: <20160728020548.GD26793@gmail.com> <5e49ab87-65ff-fe20-1e50-387e3484cc47@FreeBSD.org> From: Andriy Gapon Message-ID: <6164b037-3441-556e-c168-ec0ccc71d162@FreeBSD.org> Date: Thu, 11 Aug 2016 10:17:46 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <5e49ab87-65ff-fe20-1e50-387e3484cc47@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 Aug 2016 07:19:10 -0000 On 28/07/2016 13:34, Andriy Gapon wrote: > Locally I have the following rc script to handle subordinate datasets of > a boot environment: http://dpaste.com/0Q0JPGN.txt > It is designed for exactly the scenario described above. > The script is automatically enabled when zfs_enable is enabled. > > It would probably make sense to include the script into the OS after > some testing and a review. For posterity, as the paste has expired, I've placed it here: https://people.freebsd.org/~avg/zfsbe.sh -- Andriy Gapon From owner-freebsd-current@freebsd.org Thu Aug 11 08:04:19 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 06093BB54A8 for ; Thu, 11 Aug 2016 08:04:19 +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 BE2A01D65 for ; Thu, 11 Aug 2016 08:04:18 +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) for freebsd-current@freebsd.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1bXkyO-0011Tt-Gn>; Thu, 11 Aug 2016 10:04:16 +0200 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=freyja.zeit4.iv.bundesimmobilien.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1bXkyO-000jXT-6N>; Thu, 11 Aug 2016 10:04:16 +0200 Date: Thu, 11 Aug 2016 10:04:11 +0200 From: "O. Hartmann" To: freebsd-current Subject: CURRENT: NFSv4/autofs and ZFS weirdness: permission denied Message-ID: <20160811100411.2d30546f@freyja.zeit4.iv.bundesimmobilien.de> Organization: FU Berlin X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 87.138.105.249 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 Aug 2016 08:04:19 -0000 Both server and clients are running most recent 12-CURRENT. The server is exporting a ZFS volume via NFSv4. I recently copied that volume from another volume via zfs send/receive from one vilume on the same server to another volume, created on another sorage device. The specific volume worked before in the environment I use. It is exported via NFSv4 by the server with -maproot=www:www and read/writeable by only one specific host and imported via NFSv4 autofs by that specific host. The purpose is to synchronize via "rsync -rv" packages created via poudriere on a very fast smaller machine to the fileserver. The owner of the volume's folder hierarchy is "www:www" with unaltered, proper access rights. The last time the sync worked was July, 20th. Now, since a couple of days or weeks, I get an error: permission denied. root is the user trying to rsync from the poudriere creator host to write the packages folder hierarchy and packages to the autofs volume, but the procedure fails. I have no clue what changed. I checked whether the ZFS volume is locked in any way after it has been sent/received, but it isn't. It looks like an ordinary volume and locally (from the perspective of the fileserver) creation and deletion of files is possible. What do I miss here? The fact that this procedure worked with 11-CURRENT and 11-ALPHA weeks ago as it is, makes me suspect a bug or fundamentaly change in the bahviour or - there is a hidden lock when zfs send/receive is used I didn't realizes to relief. Thanks in advance for help and considerations, Oliver From owner-freebsd-current@freebsd.org Thu Aug 11 08:06:42 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5581CBB5698 for ; Thu, 11 Aug 2016 08:06:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F164F1F14; Thu, 11 Aug 2016 08:06:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u7B86aDR008576 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 11 Aug 2016 11:06:36 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u7B86aDR008576 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u7B86Zbk008575; Thu, 11 Aug 2016 11:06:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 11 Aug 2016 11:06:35 +0300 From: Konstantin Belousov To: Don Lewis Cc: jkim@FreeBSD.org, freebsd-current@freebsd.org, jhb@freebsd.org Subject: Re: kernel panic caused by virtualbox(?) Message-ID: <20160811080635.GE83214@kib.kiev.ua> References: <201608102347.u7ANlFhl038491@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201608102347.u7ANlFhl038491@gw.catspoiler.org> User-Agent: Mutt/1.6.1 (2016-04-27) 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.22 Precedence: 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, 11 Aug 2016 08:06:42 -0000 On Wed, Aug 10, 2016 at 04:47:15PM -0700, Don Lewis wrote: > On 10 Aug, Jung-uk Kim wrote: > > On 08/09/16 05:12 AM, Konstantin Belousov wrote: > >> On Mon, Aug 08, 2016 at 04:44:20PM -0700, Don Lewis wrote: > >>> On 8 Aug, Konstantin Belousov wrote: > >>>> On Mon, Aug 08, 2016 at 10:22:44AM -0700, John Baldwin wrote: > >>>>> On Thursday, August 04, 2016 05:10:29 PM Don Lewis wrote: > >>>>>> Reposted to -current to get some more eyes on this ... > >>>>>> > >>>>>> I just got a kernel panic when I started up a CentOS 7 VM in virtualbox. > >>>>>> The host is: > >>>>>> FreeBSD 12.0-CURRENT #17 r302500 GENERIC amd64 > >>>>>> The virtualbox version is: > >>>>>> virtualbox-ose-5.0.26 > >>>>>> virtualbox-ose-kmod-5.0.26_1 > >>>>>> > >>>>>> The panic message is: > >>>>>> > >>>>>> panic: Unregistered use of FPU in kernel > >>>>>> cpuid = 1 > >>>>>> KDB: stack backtrace: > >>>>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe085a55d030 > >>>>>> vpanic() at vpanic+0x182/frame 0xfffffe085a55d0b0 > >>>>>> kassert_panic() at kassert_panic+0x126/frame 0xfffffe085a55d120 > >>>>>> trap() at trap+0x7ae/frame 0xfffffe085a55d330 > >>>>>> calltrap() at calltrap+0x8/frame 0xfffffe085a55d330 > >>>>>> --- trap 0x16, rip = 0xffffffff827dd3a9, rsp = 0xfffffe085a55d408, rbp = 0xfffffe085a55d430 --- > >>>>>> g_pLogger() at 0xffffffff827dd3a9/frame 0xfffffe085a55d430 > >>>>>> g_pLogger() at 0xffffffff8274e5c7/frame 0x3 > >>>>>> KDB: enter: panic > >>>>>> > >>>>>> Since g_pLogger is a symbol in vboxdrv.ko, it looks like virtualbox is > >>>>>> the trigger. > >>>>>> > >>>>>> There are no symbols for the virtualbox kmods, possibly because I > >>>>>> installed them as an upgrade using packages (built with the same source > >>>>>> tree version) instead of by using PORTS_MODULES in make.conf, so ports > >>>>>> kgdb didn't have anything useful to say about what happened before the > >>>>>> trap. > >>>>>> > >>>>>> This panic is very repeatable. I just got another one when starting the > >>>>>> same VM., but this time the two calls before the trap were > >>>>>> null_bug_bypass(). Hmn, that symbol is in nullfs ... > >>>>>> > >>>>>> I don't see this with a Windows 7 VM. > >>>>>> > >>>>>> All of the virtualbox kmod files are compiled with -mno-mmx -mno-sse > >>>>>> -msoft-float -mno-aes -mno-avx > >>>> Your disassemble listed fxrstor instruction that failing, or did I > >>>> mis-remembered ? This is most likely some context switch code, either > >>>> by virtual machine or erronously executed guest code. It is not a > >>>> spontaneous use of FPU, but more likely something different. Can you > >>>> confirm ? > >>>> > >>>> In either case, I do not remember any KBI changes around PCB layout or > >>>> fpu_enter() KPI recently. > >>>> > >>>>> > >>>>> I suspect head packages are quite likely built against the a "wrong" KBI > >>>>> and are too fragile to use for kmods vs compiling from ports. :-/ I would > >>>>> try a built-from-ports kmod to see if the panics go away. > >>>> > >>>> FWIW, I will commit the following change shortly. Since third-party > >>>> modules break the invariant, either due to bugs (ndis wrappers) or > >>>> possibly due to KBI breakage, it is worth to have the detection enabled > >>>> for production kernels. > >>> > >>> Interesting ... I tried running virtualbox on recent 10.3-STABLE with a > >>> GENERIC kernel and the guest seemed to operate properly. Then I enabled > >>> INVARIANTS and got the panic. I suspect that is why nobody has stumbled > >>> across this before. > >>> > >> This is yet another reason to promote KASSERT to the full panic. > >> I expect that the vbox source lacks fpu_kern_enter() calls around the > >> FPU state restoration. > > > > Unfortunately, the code is in MI source as it is unnecessary for > > supported OSes (read: FreeBSD is not supported) and it's not easy to > > inject fpu_kern_enter()/fpu_kern_leave() calls there. :-( > > It's a headache, but our ports can use patch files for that sort of > thing ... Note that it is, most likely, completely useless to wrap single FXRSTOR instruction into the fpu_kern_enter() braces. The purpose of the instruction is to load ('legacy', as they call it, no AVX+) FPU state into the machine context. If you put fpu_kern_leave() right after the instruction, the context is flushed. There must be some larger scope where the braces do make sense. And since some other OSes do require similar precautions around the in-kernel FPU access, I suspect that there should be some common place to put our KPI calls. From owner-freebsd-current@freebsd.org Thu Aug 11 09:27:01 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9CB9EBB6D51; Thu, 11 Aug 2016 09:27:01 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from prod2.absolight.net (mx3.absolight.net [IPv6:2a01:678:2:100::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "plouf.absolight.net", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6AB891AA6; Thu, 11 Aug 2016 09:27:01 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from prod2.absolight.net (localhost [127.0.0.1]) by prod2.absolight.net (Postfix) with ESMTP id 204CABDD04; Thu, 11 Aug 2016 11:26:59 +0200 (CEST) Received: from atuin.in.mat.cc (atuin.in.mat.cc [79.143.241.205]) by prod2.absolight.net (Postfix) with ESMTPA id 028ECBDD03; Thu, 11 Aug 2016 11:26:58 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by atuin.in.mat.cc (Postfix) with ESMTP id AB2A3667804E; Thu, 11 Aug 2016 11:26:58 +0200 (CEST) Date: Thu, 11 Aug 2016 11:26:58 +0200 From: Mathieu Arnold To: "O. Hartmann" , freebsd-current , freebsd-ports Subject: Re: Passwordless accounts vi ports! Message-ID: <660CDD44B902B2A0C050ACDD@atuin.in.mat.cc> In-Reply-To: <20160811070505.2c1a1466@freyja.zeit4.iv.bundesimmobilien.de> References: <20160811070505.2c1a1466@freyja.zeit4.iv.bundesimmobilien.de> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========B6449D206AE5EBE03813==========" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 Aug 2016 09:27:01 -0000 --==========B6449D206AE5EBE03813========== Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline +--On 11 ao=C3=BBt 2016 07:05:05 +0200 "O. Hartmann" wrote: | I just checked the security scanning outputs of FreeBSD and found this | surprising result: |=20 | [...] | Checking for passwordless accounts: | polkitd::565:565::0:0:Polkit Daemon User:/var/empty:/usr/sbin/nologin | pulse::563:563::0:0:PulseAudio System User:/nonexistent:/usr/sbin/nologin | saned::194:194::0:0:SANE Scanner Daemon:/nonexistent:/bin/sh | clamav::106:106::0:0:Clamav Antivirus:/nonexistent:/usr/sbin/nologin | bacula::910:910::0:0:Bacula Daemon:/var/db/bacula:/usr/sbin/nologin | [...] |=20 | Obviously, some ports install accounts but do not secure them as there is | an empty password. |=20 | I consider this not a feature, but a bug. Mmmm, I rewrote the user/group creation thingie a few months back, a bug may have crept in, I'll have a look at it today. --=20 Mathieu Arnold --==========B6449D206AE5EBE03813========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJXrETiXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzQUI2OTc4OUQyRUQxMjEwNjQ0MEJBNUIz QTQ1MTZGMzUxODNDRTQ4AAoJEDpFFvNRg85IOb0P/1S5U8VdyHHUg/Rr2k5VUwzN dJTwtf1KGz7eOYnLwLNlXtOn8F853u51ujtleiPvPs5auyN8Rcb4ahVMvziYVxMs KsQTtQQUai2tAX+36G8sBK0MuVCCaA8zIdJ/KiuN/F0mGwmxs/Hq6W2gncLHy/r1 vNfqQ3RAHkbBQtiziwoaEv8ovHekRpjYWoqIaBhF/NeKkZdyPuNlGylNt8Gy0OHS 8aoVET+yS7BKn85Y4RHlDGskZrcC3bdF3x2z7ZlsaFHRw/OMMHyJeZDNxBchLCTA ApBiUErc9r2xCjkZHaqqh9S7RcjIG7kf5/zRU7DMhn5oh1NJR6RAoGBwte5oifO5 s/d5dsTn72U6ItXJb1ZxMNRVh/aBT14WjT3OKVMc+hzx2L/on84sNLQu8QTFbu0R p8VaiiVFJpwADYyvcflMPhn5Iipn5ASx7kPgyJk/NS5tFfyEeYkgYYfuxH97q6Cm sIhEzUxmjLDZkbkrT1i75Z/CHq4Un20YglFCkkLlf/i+HKoZomlsrg97ozRxRCkm BwUUG5geL1UDV+BonJ+YMsAS5stMF1sotPd4opabpbl8ciIB2AHqDWNKK/O3RYjZ yyV448XWVfiiMTpGuJxec5M8HsrV6JYdXGrpjgW5UuwsF47/GDvRUmyWnBpdVR/E V7rWkFJC4adnTnUChuiI =IYcA -----END PGP SIGNATURE----- --==========B6449D206AE5EBE03813==========-- From owner-freebsd-current@freebsd.org Thu Aug 11 09:30:42 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA2FBBB6FB3 for ; Thu, 11 Aug 2016 09:30:42 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from smtp.rlwinm.de (smtp.rlwinm.de [IPv6:2a01:4f8:201:31ef::e]) (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 5D99C1188 for ; Thu, 11 Aug 2016 09:30:41 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from vader9.bultmann.eu (unknown [87.253.189.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.rlwinm.de (Postfix) with ESMTPSA id C4DD02D8B for ; Thu, 11 Aug 2016 11:30:38 +0200 (CEST) Subject: Re: Passwordless accounts vi ports! To: freebsd-current@freebsd.org References: <20160811070505.2c1a1466@freyja.zeit4.iv.bundesimmobilien.de> From: Jan Bramkamp Message-ID: <84687796-5113-152c-cf34-9f8e891c3ea2@rlwinm.de> Date: Thu, 11 Aug 2016 11:30:37 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160811070505.2c1a1466@freyja.zeit4.iv.bundesimmobilien.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.22 Precedence: 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, 11 Aug 2016 09:30:42 -0000 On 11/08/16 07:05, O. Hartmann wrote: > I just checked the security scanning outputs of FreeBSD and found this > surprising result: > > [...] > Checking for passwordless accounts: > polkitd::565:565::0:0:Polkit Daemon User:/var/empty:/usr/sbin/nologin > pulse::563:563::0:0:PulseAudio System User:/nonexistent:/usr/sbin/nologin > saned::194:194::0:0:SANE Scanner Daemon:/nonexistent:/bin/sh > clamav::106:106::0:0:Clamav Antivirus:/nonexistent:/usr/sbin/nologin > bacula::910:910::0:0:Bacula Daemon:/var/db/bacula:/usr/sbin/nologin > [...] > > Obviously, some ports install accounts but do not secure them as there is an > empty password. Are you certain that the ports didn't use "*" as crypted hash which isn't a valid hash for any supported algorithm and prevents password based authentication for the account? FreeBSD also uses two passwd files (and compiles them into databases for fast lookups). The old /etc/passwd is world readable but contains no passwords and the real /etc/master.passwd which is only accessible by root. If you run `getent passwd` the missing password field is replaced with "*" which can confuse buggy scripts. From owner-freebsd-current@freebsd.org Thu Aug 11 10:05:36 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 762E5BB5D95 for ; Thu, 11 Aug 2016 10:05:36 +0000 (UTC) (envelope-from kostikbel@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 6118C158D for ; Thu, 11 Aug 2016 10:05:36 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 607BABB5D93; Thu, 11 Aug 2016 10:05:36 +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 600B6BB5D92; Thu, 11 Aug 2016 10:05:36 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EE2041579; Thu, 11 Aug 2016 10:05:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u7BA5RiG042720 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 11 Aug 2016 13:05:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u7BA5RiG042720 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u7BA5R2W042717; Thu, 11 Aug 2016 13:05:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 11 Aug 2016 13:05:27 +0300 From: Konstantin Belousov To: current@freebsd.org Cc: amd64@freebsd.org Subject: HPETs and userspace gettimeofday() Message-ID: <20160811100527.GG83214@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) 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.22 Precedence: 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, 11 Aug 2016 10:05:36 -0000 I implemented fast userspace gettimeofday(2) support for machines which have to use HPET for timecounters. Details and measurements, as well as the patch, are put at https://reviews.freebsd.org/D7473 . I am interested in the testing by people using Core2 and older hardware. Thanks. From owner-freebsd-current@freebsd.org Thu Aug 11 10:19:54 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BBEABBB0390; Thu, 11 Aug 2016 10:19:54 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "rulingia.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 514F41F4E; Thu, 11 Aug 2016 10:19:53 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (ppp59-167-167-3.static.internode.on.net [59.167.167.3]) by vps.rulingia.com (8.15.2/8.15.2) with ESMTPS id u7BAJaxa081966 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 11 Aug 2016 20:19:43 +1000 (AEST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id u7BAJTKY055830 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 Aug 2016 20:19:29 +1000 (AEST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id u7BAJSeA055829; Thu, 11 Aug 2016 20:19:28 +1000 (AEST) (envelope-from peter) Date: Thu, 11 Aug 2016 20:19:28 +1000 From: Peter Jeremy To: john hood Cc: freebsd-ports@freebsd.org, freebsd-current@freebsd.org, mosh-devel@mit.edu Subject: Re: Mosh regression between 10.x and 11-stable Message-ID: <20160811101928.GC65184@server.rulingia.com> References: <20160810081831.GA65184@server.rulingia.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IrhDeMKUP4DT/M7F" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 Aug 2016 10:19:54 -0000 --IrhDeMKUP4DT/M7F Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2016-Aug-10 14:32:15 -0400, john hood wrote: >On 8/10/16 4:18 AM, Peter Jeremy wrote: >> I recently updated one of my VPS hosts from 10.3-RELEASE-p5 to 11.0-BETA4 >> r303811 and mosh to that host from my Linux laptop stopped working. All >> I get on the laptop is: >> $ mosh remotehost >> Connection to remotehost closed. >> /usr/bin/mosh: Did not find mosh server startup message. >> 1) the "MOSH CONNECT" message isn't making it out of the local ssh proce= ss. > >Do you know if the message is getting out of mosh-server? into sshd? >Do you know if mosh-server is actually running? (It will log utmp >entries on startup.) mosh-server is running - I can see it from another session and redirecting verbose output into a file, I get: ---- mosh-server (mosh 1.2.5) [build mosh 1.2.5] Copyright 2012 Keith Winstein License GPLv3+: GNU GPL version 3 or later . This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. [mosh-server detached, pid =3D 4202] Warning: termios IUTF8 flag not defined. Character-erase of multibyte character sequence probably does not work properly on this platform. ---- I can't tell if it's actually writing into the remote ssh process. >> 2) it's racy because I can get it from "always fails" to "sometimes work= s". > >How do you get it there? - Add '-v' to the local ssh command. - ktrace the remote mosh-server process (this seems to make it consistently= work). --=20 Peter Jeremy --IrhDeMKUP4DT/M7F Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJXrFEwXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs0iXwP/3vXsKv8AfNOmkfLaFMk+u+F klqaGmXwUh8mbmWconCnfozYf0aiwIPNQI+L765P6MUSCIsebpPinwk76AGMfj0t FuuqTUXJmHmufso6A7FmiaVamUBX59zlxlnBniD9LF07bUaA6UGxhI4jjwulMx7W QIvflOhIPcAaRgq3j02olVFUsVf62or3Y83flqmzosutHZC2aeJCh3ojUmHWOyiu sumrukkzHy86dItPBx0x585RrsMr5qnyhzUhEWj/iqurm3JrWlql5dQbUg04yy9b ok7GPjVOOEH3jOSjg27BjIeNVnlKfMJIiOn9kp1PFlbEYaNr+SgiTQc16NbRR8RE h0yoR7zmKap+W+GYsYuEPGAj+e7HyZfAf77WfJREIkc9R0CaZF6MaEHJgYchIuhT CeWNEfgt0hazBdNe05SY1X3HhBUelh234PRdbIuXsfdShnOkn16j8QuyKVEbHKZP ppUQ2RdilBbevLmjsLQuGahSFIpJYoOcxAboN4/uNcHc+VkwUL04cGkAheFL+i4v hNQkeV7VQaZZpYrMJciQ95yUHsu3A4Nf7BFfIv35AnG21zVZ1/56R7Ljul7UBRx2 eYI5n6zn0QQcW83ss7WPd0c3/5BpPawF/5KlJq01OyfunA2+OsRCQOykwpmaxe1B zVpJz09SuL46ANstnuOm =EiH0 -----END PGP SIGNATURE----- --IrhDeMKUP4DT/M7F-- From owner-freebsd-current@freebsd.org Thu Aug 11 11:17:28 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D72DDBB593A for ; Thu, 11 Aug 2016 11:17:28 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 8F15815D9; Thu, 11 Aug 2016 11:17:28 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: by mail-ua0-x235.google.com with SMTP id k90so853459uak.1; Thu, 11 Aug 2016 04:17:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=onTH/PHkDmelhUFujIO8PdHvDTIObvNRLYmmBtsO+ro=; b=FulDu3Kq7kMM0/SoZMZf9LXjmVmK/DNbXPLqJ65eOD9ArJ5SlNPCuii65RknQvsllP KyLvPKh+9B5TM5Hu8kFWhFg2dncNBsC/w/hX8gL9ejy06zzUMpw1U1dMzIffkrdX5mKK XBwOwQ/E4O5gJ4ouizT0pzZSWlYTQk2nC4xa96lLRtbW/Dd7e60nkDUrLxdmouv1bHz/ qAJiwO3Z9XscH2QHWL4ugvAy/CaplYhRLO4FLmWjFo+mdHq87imUMOC3jtH8KHQl44UA L7sDuKIoJXjJeJsNNs3xON7XhNsaBzB+tSqma8Zu2Cyd5RC/nS0va6cYwPtIJeuN7eLV 1oHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=onTH/PHkDmelhUFujIO8PdHvDTIObvNRLYmmBtsO+ro=; b=YwDUiIr5oA/K9GuHLNbVQ7880mZUXWHLEOL5q73WtdS298c4NqByeJuqyHHaSmk6Lp 8VI2uAaixw0nN30YGlPonfVEZFIyzb0KCJTF7E2XNvYTfBejk99y/7YdwyjIx+tj5aeh q6iJps4Eec7OvFmL+VlUJnHaLhmFWvP1Ew7LX/JWAAupgLmdHWri697/F2xqghzhPKJh 6o0IIHKDdOqLdOf/pACoKbhikRzuztuLMYLZKyUXT9aqCx5PjCxNcdON0KkyukDwrkhM 1uf65PjtdptwZlylFj28jYgZfmJz9gEBMpr5MdMVQnbE8q0oQPONH0km2Jz6RDtDb+lv Q1MA== X-Gm-Message-State: AEkoousBPlWntfrypde3VXg2uWDOtcQhGZGA3IQk/wbTiegHCTylxGtFh/LnGtyG9qy2XZdjAJ6+wyJMgzqq8g== X-Received: by 10.31.164.13 with SMTP id n13mr4491956vke.15.1470914247501; Thu, 11 Aug 2016 04:17:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Howard Su Date: Thu, 11 Aug 2016 11:17:17 +0000 Message-ID: Subject: Re: Fwd: Failed to boot -Current snapshot memstick img with EFI To: Allan Jude , freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 Aug 2016 11:17:28 -0000 This is fixed by r303944. On Fri, Jul 29, 2016 at 1:24 AM Howard Su wrote: > It turns out a USB driver problem. the usb disk size is not correctly > detected. But the disk works fine in BIOS. > > Here is dmesg information: > ugen7.2: at usbus7 > umass0: on > usbus7 > umass0: SCSI over Bulk-Only; quirks =3D 0x8100 > umass0:6:0: Attached to scbus6 > da0 at umass-sim0 bus 0 scbus6 target 0 lun 0 > da0: Removable Direct Access SPC-4 SCSI > device > da0: Serial Number 137161312223005B > da0: 40.000MB/s transfers > da0: 0MB (1 512 byte sectors) <---------------- > da0: quirks=3D0x2 > GEOM_PART: integrity check failed (da0, MBR) > GEOM_PART: integrity check failed (diskid/DISK-137161312223005B, MBR) > > Anyone has idea how this happen? > > -Howard > > On Wed, Jul 27, 2016 at 12:21 PM Howard Su wrote: > >> 8GB >> >> Allan Jude =E4=BA=8E2016=E5=B9=B47=E6=9C=8827=E6= =97=A5=E5=91=A8=E4=B8=89 =E4=B8=8A=E5=8D=8811:35=E5=86=99=E9=81=93=EF=BC=9A >> >>> On 2016-07-26 23:33, Howard Su wrote: >>> > The same issue is still there in 11-BETA2. I tried the memstick image >>> for >>> > amd64. I got the exact same error (with boot -v). >>> > =E2=80=8BGEOM_PART: last LBA is below first LBA: 0 < 32 >>> > GEOM_PART: integrity check failed (da0, MBR) >>> > >>> > This make mem stick image totally useless. Anyone take a look? I am >>> happy >>> > to provide more information. >>> > >>> > Thanks, >>> > >>> > Howard >>> > >>> > ---------- Forwarded message ---------- >>> > From: Howard Su >>> > Date: Sat, Apr 23, 2016 at 10:40 PM >>> > Subject: Failed to boot -Current snapshot memstick img with EFI >>> > To: "freebsd-current@freebsd.org" >>> > >>> > >>> > The issue is partition table in img is wrong so that GEOM cannot >>> discover >>> > the partitions. >>> > >>> > Detailed error: >>> > =E2=80=8B=E2=80=8B >>> > GEOM_PART: last LBA is below first LBA: 0 < 32 >>> > GEOM_PART: integrity check failed (da0, MBR) >>> > >>> > I tried this month and last month memstick img. both has same problem= . >>> Any >>> > idea on the issue? >>> > >>> > -Howard >>> > >>> >>> The last LBA is being reported as 0, which is obviously bogus. >>> >>> How big is the USB device you have written the memstick to? >>> >>> -- >>> Allan Jude >>> >>> -- >> -Howard >> > -- > -Howard > --=20 -Howard From owner-freebsd-current@freebsd.org Thu Aug 11 13:17:57 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 08C5CBB4982; Thu, 11 Aug 2016 13:17:57 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from prod2.absolight.net (mx3.absolight.net [IPv6:2a01:678:2:100::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "plouf.absolight.net", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C6F771A2A; Thu, 11 Aug 2016 13:17:56 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from prod2.absolight.net (localhost [127.0.0.1]) by prod2.absolight.net (Postfix) with ESMTP id A6274BDC93; Thu, 11 Aug 2016 15:17:54 +0200 (CEST) Received: from gw.in.absolight.net (gw-ecl.in.absolight.net [79.143.241.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.in.absolight.net", Issuer "CA Cert Signing Authority" (not verified)) by prod2.absolight.net (Postfix) with ESMTPSA id 7A2A2BDC7F; Thu, 11 Aug 2016 15:17:54 +0200 (CEST) Received: from ogg.in.absolight.net (ogg.in.absolight.net [79.143.241.239]) by gw.in.absolight.net (Postfix) with ESMTP id 3CFB26145; Thu, 11 Aug 2016 15:17:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by ogg.in.absolight.net (Postfix) with ESMTP id 54AD02DA3513; Thu, 11 Aug 2016 15:17:52 +0200 (CEST) Date: Thu, 11 Aug 2016 15:17:51 +0200 From: Mathieu Arnold To: "O. Hartmann" , freebsd-current , freebsd-ports Subject: Re: Passwordless accounts vi ports! Message-ID: <9567532A811EA9735990943A@ogg.in.absolight.net> In-Reply-To: <660CDD44B902B2A0C050ACDD@atuin.in.mat.cc> References: <20160811070505.2c1a1466@freyja.zeit4.iv.bundesimmobilien.de> <660CDD44B902B2A0C050ACDD@atuin.in.mat.cc> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========87B141FE2C7FC6DD5925==========" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 Aug 2016 13:17:57 -0000 --==========87B141FE2C7FC6DD5925========== Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline +--On 11 ao=C3=BBt 2016 11:26:58 +0200 Mathieu Arnold = wrote: |=20 |=20 | +--On 11 ao=C3=BBt 2016 07:05:05 +0200 "O. Hartmann" | wrote: || I just checked the security scanning outputs of FreeBSD and found this || surprising result: ||=20 || [...] || Checking for passwordless accounts: || polkitd::565:565::0:0:Polkit Daemon User:/var/empty:/usr/sbin/nologin || pulse::563:563::0:0:PulseAudio System = User:/nonexistent:/usr/sbin/nologin || saned::194:194::0:0:SANE Scanner Daemon:/nonexistent:/bin/sh || clamav::106:106::0:0:Clamav Antivirus:/nonexistent:/usr/sbin/nologin || bacula::910:910::0:0:Bacula Daemon:/var/db/bacula:/usr/sbin/nologin || [...] ||=20 || Obviously, some ports install accounts but do not secure them as there = is || an empty password. ||=20 || I consider this not a feature, but a bug. |=20 | Mmmm, I rewrote the user/group creation thingie a few months back, a bug | may have crept in, I'll have a look at it today. I've tested things on 9, 10 and 11, I can't reproduce that. --=20 Mathieu Arnold --==========87B141FE2C7FC6DD5925========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJXrHr/XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzQUI2OTc4OUQyRUQxMjEwNjQ0MEJBNUIz QTQ1MTZGMzUxODNDRTQ4AAoJEDpFFvNRg85IWqUP/RAqCSehseLB5WjTiyMu0TMe l1QJXn5KZDEgvZacLPV3wjDF/N7uFMT5ntNPY9z4/8keJRV7s4RJdEmGDc5IdHkY AVmOHW61V1yIdbFJobHaH0GEKOIAuYnMjxG5WvJ0ILw5d8bzkZ95c9z2jJ+Kq0B0 ku60M0j85ZrgZ2NA81iXK0B2XOZYBMeYMkQthY68xXGdnbelGZ1dc6pkz2q65RtU +V/aDZZS8pumazulwiTF2oWCFVJvakEU0uy2qobpJb1gr8aH7/j48ryfUd+onJJY dZSnvyXH8+I4dRKfE28rzb22HHtphmRT4rJEx+H2d6EJpkodw3AmMfQKE5wuktyS iXI8CSJXi8bi9KNF3XOSB0VWzhdanrtAMvGjm5MojWyqxq8DoeulXP8oQIoEkgkR Pn8S6iIZvayX28OPHG7dHct/0oFeDL3m+ymbRGw4voG4FJZ+Fff6p6bLKlnJzy/t 7GmRxUqOuac77x0dS+YVv4RNOE/53Dre1q+1/LvzKaUtyR5rL9beDN2g+zbgPatn QGVOhW08aIHYHPwne6CCSwfHJtNVRN5BLU+NOY9bXVKACs6OHR68zJdif6beCwSu eHRHmDdyx+l/m1E7+/tMRxjoABOyv/ORgfrs9WBUnFdbXX3guKdOlVtQXxBGlJat 97pxVCO3wx1+nyElkdNg =evw4 -----END PGP SIGNATURE----- --==========87B141FE2C7FC6DD5925==========-- From owner-freebsd-current@freebsd.org Thu Aug 11 16:30:26 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7F676BB6F33; Thu, 11 Aug 2016 16:30:26 +0000 (UTC) (envelope-from cgull@glup.org) Received: from glup.org (216-15-121-172.c3-0.smr-ubr2.sbo-smr.ma.static.cable.rcn.com [216.15.121.172]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 033F41F28; Thu, 11 Aug 2016 16:30:25 +0000 (UTC) (envelope-from cgull@glup.org) Received: from lister.boston.niksun.com (unknown [4.16.10.2]) by glup.org (Postfix) with ESMTPSA id 09C78854C4; Thu, 11 Aug 2016 12:30:24 -0400 (EDT) Authentication-Results: glup.org; dmarc=none header.from=glup.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=glup.org; s=201009; t=1470933024; bh=1GQSLXptTwR303b6mLxHNlQOcMMQTmnsxVWiWcB7YDc=; h=Subject:To:References:Cc:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type; b=WGWwWUVq9qEQBqK2AwayZ6ZVPYT2+AWwyOHwnrkFFw3p3saiIhc9VQ5k1YYo3lgTS n/TfHWGLzRaJzuci1khQOCaNFTMYznAY1vCAfGjaafW9jWu+W+fGmFcNXQ8k4F8ICG mFSRJq333/y1rRmeq0H6oChl1bVDELdGLirNp+/WzltekuW/BAFeV8WjLUTVycJ749 hacl6d4jfvcw0QEdR9TGWrXLVl2ljn/HY67hOXdD14zbD0LrQTpRMyK9U/Au/GNvYw hXMJbxF1Ep2gt0yvarKTHoBHKzLzlSg37Wl+9evYFsCO5uIcbViC/Jlyw9EO9ue7Df ZzrXeNs3x0TMA== Subject: Re: Mosh regression between 10.x and 11-stable To: Peter Jeremy References: <20160810081831.GA65184@server.rulingia.com> <20160811101928.GC65184@server.rulingia.com> Cc: freebsd-ports@freebsd.org, freebsd-current@freebsd.org, mosh-devel@mit.edu From: John Hood Message-ID: <68d0a6d4-2078-000c-6e22-b0b8721dfd2b@glup.org> Date: Thu, 11 Aug 2016 12:30:23 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160811101928.GC65184@server.rulingia.com> Content-Type: multipart/mixed; boundary="------------0B8B2C5FE966D46E2227F80E" X-Mailman-Approved-At: Thu, 11 Aug 2016 16:42:32 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 Aug 2016 16:30:26 -0000 This is a multi-part message in MIME format. --------------0B8B2C5FE966D46E2227F80E Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit I still can't reproduce this on 3 different 11.0-BETA4 servers and a variety of clients and networks. Can you try and identify a more portable repro or at least figure out why it fails on your system? Please try applying this patch, too. It's a shot in the dark, though. regards, --jh --------------0B8B2C5FE966D46E2227F80E Content-Type: text/x-patch; name="0001-Ensure-MOSH-CONNECT-message-reaches-sshd.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0001-Ensure-MOSH-CONNECT-message-reaches-sshd.patch" >From 4c4d2193af37f4375d9f7d52c109bbcdb873d9fc Mon Sep 17 00:00:00 2001 From: John Hood Date: Thu, 11 Aug 2016 12:25:55 -0400 Subject: [PATCH] Ensure MOSH CONNECT message reaches sshd. --- src/frontend/mosh-server.cc | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/frontend/mosh-server.cc b/src/frontend/mosh-server.cc index a88a8d2..cd25a14 100644 --- a/src/frontend/mosh-server.cc +++ b/src/frontend/mosh-server.cc @@ -410,6 +410,9 @@ static int run_server( const char *desired_ip, const char *desired_port, printf( "\nMOSH CONNECT %s %s\n", network->port().c_str(), network->get_key().c_str() ); fflush( stdout ); + if ( isatty( fileno( stdout ))) { + tcdrain( fileno( stdout )); + } /* don't let signals kill us */ struct sigaction sa; -- 2.9.2 --------------0B8B2C5FE966D46E2227F80E-- From owner-freebsd-current@freebsd.org Thu Aug 11 17:06:40 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 64EA1BB6C19; Thu, 11 Aug 2016 17:06:40 +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 349C61E97; Thu, 11 Aug 2016 17:06:40 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pa0-x22b.google.com with SMTP id i5so413571pat.2; Thu, 11 Aug 2016 10:06:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6NDAohXGNXnyrUbp+IsP0szgX67MAvA58EcpYuIkIr4=; b=E8kLrBzokm1SOnCy8EmAsG9nItSr8UYQtY0yr61VanEcAHKE2gqX5rL9SwKnuMW6jo DX4y6+Pnusta2ZDk13h/4hUBuW2JOKGDna2b44zAyz41MpTBO7V4hf6+cAiNj4cnxjAq N8WbYXo/TcPKbQaKCRTlk0f2elIteQPYOdJEo0rjJna2B3LosjoEACENNTk53MdW41sn In4DwgPWJims7fsdy9/Cy/uLWb3nY+NdBGUhoObHJBcZ63Odu6KWaSY4IGtW9/bGXAx1 f8FpkGfKiqbi74tdICDBMW/h+BJ0eI7ZfGa1LEDB2hRvlDsd+UqWvuxRk3PjhhZQ2fSI /e6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6NDAohXGNXnyrUbp+IsP0szgX67MAvA58EcpYuIkIr4=; b=Cd+KJHfLQbq8leUwo6N9j7ewKkrLbFiE+s4FJIQPxg+ou6aiKtL5ezNn3LVE2d4LuV RDLmKporwIhVTSgq4JWEo8cD4K3tm0sCtfQGB+BmvIoXFH1B4o8Ww/8rWZ6IK5MqXYAj kI+I118TEnwLS7lAiS/tbX22kw6SSZZS30y2Pcvb7HpptJAEtk83mwd0IEdATpd3zK0V M303smKMVtTwTQOWrH4eONaFxTgtSPMYIgVVQXGBURszIORi5Rha51Zd4hbqKJC+ywsK rVimTaPk/fc4GTN58so69uHKaqcyFtOfqF6pUVFzk7YyrZsEFArWmcKgzXL6Uza0mxhD DEmg== X-Gm-Message-State: AEkoouu6AJxsk7R9PCxBbGdy/ym6YYrtTyJNE6N0VtB2FR8SoH90+iglA+19DSoZ3m8RhA== X-Received: by 10.66.248.10 with SMTP id yi10mr18920033pac.31.1470935196497; Thu, 11 Aug 2016 10:06:36 -0700 (PDT) Received: from [192.168.20.15] (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id bx9sm6697531pab.17.2016.08.11.10.06.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 11 Aug 2016 10:06:35 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Mosh regression between 10.x and 11-stable From: Ngie Cooper X-Mailer: iPhone Mail (13G35) In-Reply-To: <68d0a6d4-2078-000c-6e22-b0b8721dfd2b@glup.org> Date: Thu, 11 Aug 2016 10:06:35 -0700 Cc: Peter Jeremy , freebsd-ports@freebsd.org, freebsd-current@freebsd.org, mosh-devel@mit.edu Content-Transfer-Encoding: 7bit Message-Id: References: <20160810081831.GA65184@server.rulingia.com> <20160811101928.GC65184@server.rulingia.com> <68d0a6d4-2078-000c-6e22-b0b8721dfd2b@glup.org> To: John Hood X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 Aug 2016 17:06:40 -0000 > On Aug 11, 2016, at 09:30, John Hood wrote: > > I still can't reproduce this on 3 different 11.0-BETA4 servers and a > variety of clients and networks. Can you try and identify a more > portable repro or at least figure out why it fails on your system? > > Please try applying this patch, too. It's a shot in the dark, though. Dumb question: what ssh key type(s) (dsa, rsa, etc) are you using Peter :)? Thanks, -Ngie From owner-freebsd-current@freebsd.org Thu Aug 11 17:45:59 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 196E5BB55B2 for ; Thu, 11 Aug 2016 17:45:59 +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 CFD841562 for ; Thu, 11 Aug 2016 17:45: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 esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1bXu3C-0049zE-2F>; Thu, 11 Aug 2016 19:45:50 +0200 Received: from x4e34060c.dyn.telefonica.de ([78.52.6.12] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1bXu3B-001UFR-Np>; Thu, 11 Aug 2016 19:45:49 +0200 Date: Thu, 11 Aug 2016 19:47:14 +0200 From: "O. Hartmann" To: Jan Bramkamp Cc: freebsd-current@freebsd.org Subject: Re: Passwordless accounts vi ports! Message-ID: <20160811194714.4eda9cd4.ohartman@zedat.fu-berlin.de> In-Reply-To: <84687796-5113-152c-cf34-9f8e891c3ea2@rlwinm.de> References: <20160811070505.2c1a1466@freyja.zeit4.iv.bundesimmobilien.de> <84687796-5113-152c-cf34-9f8e891c3ea2@rlwinm.de> Organization: FU Berlin X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/ZSAKFRxupUHoY=8JWAK5c+F"; protocol="application/pgp-signature" X-Originating-IP: 78.52.6.12 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 Aug 2016 17:45:59 -0000 --Sig_/ZSAKFRxupUHoY=8JWAK5c+F Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Thu, 11 Aug 2016 11:30:37 +0200 Jan Bramkamp schrieb: > On 11/08/16 07:05, O. Hartmann wrote: > > I just checked the security scanning outputs of FreeBSD and found this > > surprising result: > > > > [...] > > Checking for passwordless accounts: > > polkitd::565:565::0:0:Polkit Daemon User:/var/empty:/usr/sbin/nologin > > pulse::563:563::0:0:PulseAudio System User:/nonexistent:/usr/sbin/nolog= in > > saned::194:194::0:0:SANE Scanner Daemon:/nonexistent:/bin/sh > > clamav::106:106::0:0:Clamav Antivirus:/nonexistent:/usr/sbin/nologin > > bacula::910:910::0:0:Bacula Daemon:/var/db/bacula:/usr/sbin/nologin > > [...] > > > > Obviously, some ports install accounts but do not secure them as there = is an > > empty password. =20 >=20 > Are you certain that the ports didn't use "*" as crypted hash which=20 > isn't a valid hash for any supported algorithm and prevents password=20 > based authentication for the account? I checked the culprit system's master.passwd with "vipw" and I'm quite sure= , vipw (called as root) is showing a password - or empty if empty. And the password field = was empty as complained by the periodic scripts. >=20 > FreeBSD also uses two passwd files (and compiles them into databases for= =20 > fast lookups). The old /etc/passwd is world readable but contains no=20 > passwords and the real /etc/master.passwd which is only accessible by=20 > root. If you run `getent passwd` the missing password field is replaced= =20 > with "*" which can confuse buggy scripts. > _______________________________________________ > 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_/ZSAKFRxupUHoY=8JWAK5c+F Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXrLoiAAoJEOgBcD7A/5N8UaEIAIblVxI5LYLaOwlNjMlhGgT8 Kuy/b4Y/dv3Opsvb3HpOhWxJEpHyPIVCnA8A1mOtkN3Vm01cPd+9aQbk82/3xoZd CGjE1N7+GtAKJynX/f8qNMOjjMXMIes/YfB/Aq1FxermHN6FPiGTXteLONakgoZE xflUTeFvFJ5PKpl4Lthz5bhDDbyEBTEcx2RHab8YiqIh2+8GozIAIC9U+HyN44aq p4DeXC9S6iniGImsTEEqJWc5ghwOgUIr4XjdMm+TxhqGs/zTFgV4eMz+K951o/rg 1dqUZ+UgChNUMEB733hXUKYFZKy8cOiG+qjLwdVqdLzRQxP2GUNwBSJ8sPAT35w= =VY4B -----END PGP SIGNATURE----- --Sig_/ZSAKFRxupUHoY=8JWAK5c+F-- From owner-freebsd-current@freebsd.org Thu Aug 11 19:54:07 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0A476BB6F3F; Thu, 11 Aug 2016 19:54:07 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "rulingia.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7DAAA1CB7; Thu, 11 Aug 2016 19:54:05 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (ppp59-167-167-3.static.internode.on.net [59.167.167.3]) by vps.rulingia.com (8.15.2/8.15.2) with ESMTPS id u7BJrtZp084767 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 12 Aug 2016 05:54:01 +1000 (AEST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id u7BJrn9A047348 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 Aug 2016 05:53:49 +1000 (AEST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id u7BJrm5t047347; Fri, 12 Aug 2016 05:53:48 +1000 (AEST) (envelope-from peter) Date: Fri, 12 Aug 2016 05:53:48 +1000 From: Peter Jeremy To: John Hood Cc: mosh-devel@mit.edu, freebsd-current@freebsd.org, freebsd-ports@freebsd.org Subject: Re: Mosh regression between 10.x and 11-stable Message-ID: <20160811195348.GD65184@server.rulingia.com> References: <20160810081831.GA65184@server.rulingia.com> <20160811101928.GC65184@server.rulingia.com> <68d0a6d4-2078-000c-6e22-b0b8721dfd2b@glup.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gr/z0/N6AeWAPJVB" Content-Disposition: inline In-Reply-To: <68d0a6d4-2078-000c-6e22-b0b8721dfd2b@glup.org> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 Aug 2016 19:54:07 -0000 --gr/z0/N6AeWAPJVB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2016-Aug-11 12:30:23 -0400, John Hood wrote: >I still can't reproduce this on 3 different 11.0-BETA4 servers and a >variety of clients and networks. Can you try and identify a more >portable repro or at least figure out why it fails on your system? > >Please try applying this patch, too. It's a shot in the dark, though. That patch seems to fix the problem I'm seeing. Not waiting for output to drain is consistent with the symptoms I'm seeing, though I have no idea why only my Linux client is affected. --=20 Peter Jeremy --gr/z0/N6AeWAPJVB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJXrNfMXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs0ozYP/0A8mpzaZEe0ykfy385kjR4C WkzSfLZQnJ0C2gGH9vYIJeJOUkB4zg29eMAMObOssy6HyxBDPrknMijdDSUY1Y/H cH8RQITdb9xFYCIDpNFdlCbQcM0ARVRjHLm5blYr+u5VFMmse6WDm3mNocaP+7WP Ey1evN3rp09g+0lr40JV7RBStAXZgHibh++0Y0AhRQeMmLEx0oVV2kTr6CM+wgUZ 3z7rUX44m50t+e14A16so7tsai28bvHpYFYroEMCz+OGdioNrXIsffNA9SHC6uzS zdx52/cVfwCqKM15STsrht7Snd8m0bPagIPAGg0DHlXvcFSVo3gzbyrVi76hqQJ2 kdfWZ3NfPxAtcoZizAs+y061SOSL+PI88LLxa0ZmCQC6CjSbMfy00wVF2Mn0h5DD TpbAQkazd/vrwAvYcPkuxMAPWmfVov8QrbYJw7hC/E32EM+MsLyoWx16SCu4YY7q Btrx4FkKuS3BYdiQLww7JexujHslRPLe65D/QLywFuHfz0D6rArevh/tcbbrOF3B +PEgzeq6c5gOl2zaduWQLDVPByTMGiSy3L58hy3EYZb/Pd3c4LuPIOAfNcnrHC/S fUVms8IUFwM/ywImqLC/tDpM+ZFUsahoRdQ19cDXqUxhidNRXDLrOe0qzVsD0ETh r4a4ih1wmDNW0TDBE0l7 =P6zo -----END PGP SIGNATURE----- --gr/z0/N6AeWAPJVB-- From owner-freebsd-current@freebsd.org Thu Aug 11 20:22:54 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34BD4BB670E; Thu, 11 Aug 2016 20:22:54 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "rulingia.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C0CFD11D0; Thu, 11 Aug 2016 20:22:53 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (ppp59-167-167-3.static.internode.on.net [59.167.167.3]) by vps.rulingia.com (8.15.2/8.15.2) with ESMTPS id u7BKMhBG084865 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 12 Aug 2016 06:22:48 +1000 (AEST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id u7BKMbWq047501 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 Aug 2016 06:22:37 +1000 (AEST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id u7BKMasB047500; Fri, 12 Aug 2016 06:22:36 +1000 (AEST) (envelope-from peter) Date: Fri, 12 Aug 2016 06:22:35 +1000 From: Peter Jeremy To: Ngie Cooper Cc: John Hood , freebsd-ports@freebsd.org, freebsd-current@freebsd.org, mosh-devel@mit.edu Subject: Re: Mosh regression between 10.x and 11-stable Message-ID: <20160811202235.GE65184@server.rulingia.com> References: <20160810081831.GA65184@server.rulingia.com> <20160811101928.GC65184@server.rulingia.com> <68d0a6d4-2078-000c-6e22-b0b8721dfd2b@glup.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fOHHtNG4YXGJ0yqR" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 Aug 2016 20:22:54 -0000 --fOHHtNG4YXGJ0yqR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2016-Aug-11 10:06:35 -0700, Ngie Cooper wrote: > >> On Aug 11, 2016, at 09:30, John Hood wrote: >>=20 >> I still can't reproduce this on 3 different 11.0-BETA4 servers and a >> variety of clients and networks. Can you try and identify a more >> portable repro or at least figure out why it fails on your system? >>=20 >> Please try applying this patch, too. It's a shot in the dark, though. > >Dumb question: what ssh key type(s) (dsa, rsa, etc) are you using Peter :)? I'm using ECDSA for both the host and user keys. --=20 Peter Jeremy --fOHHtNG4YXGJ0yqR Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJXrN6LXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs0RCwP/i+C2XmctJ6CGMiXOU2x9kVs x/ePWCVa00oklCJe085XgAYcihaJX5adFaWUwYx2NsB1AzqI95KOtIBRZn3TQ6iv A/msUVfFFZaKZGC4XRKVKVV0fpxJXiLYXlRaHnQaiqDhfy+2P3gSoHwJTZ0LEugZ hkXB1Kz/wzhDApm63f7lel/D9z2rZmpV8F0B0kVhzf3fk6QthUE0KLdVvZ7j7fi1 DasLeZsTIAyOgPM2L3BQUY7qPpK6d1z889OXlmYVmISwiOrz3w6boEBEMWw0sNll 311lz0DO9oBmvXhdS4u+1Yr5wsGcevsDPNmjO9Uy7yWiPW0wOZed5yNT+iZITtU2 Ogg9jWEQ4IavhQ3nR7LEmqMMEVPgCeEVgGzgxuwEQrvuivv+5g/U//osoA2U/5S0 XQ9nYQr9V3cBnVKiBm9GKkFSjop7yvUTZozv5OyjO1QGEGPQfvVCJZEY5+g0UVlJ TcmGcn/mBoKUoAV3n6q6FxVt8VNt/GNpOsE7jzadWjUo+iERr2enGX2mmKi5sxV0 OLBF8STRHoEQNa0y4cl25yQAyX7qwk/3+y4VukDGyYeoiItV7ePSls9RK/Ymhoj/ 1XPXaGcoAKnQiMh8vrzOMF+o1sKFWxHASV7e0/B5BZTRysAO8+EFlzeYIhI6Lb3E qF9Rujo+aDGLfSeDzdS/ =BiVR -----END PGP SIGNATURE----- --fOHHtNG4YXGJ0yqR-- From owner-freebsd-current@freebsd.org Thu Aug 11 22:22:56 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 422BCBB73BF for ; Thu, 11 Aug 2016 22:22:56 +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 03F7D1E30; Thu, 11 Aug 2016 22:22:55 +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 u7BMMiTI042234; Thu, 11 Aug 2016 15:22:48 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201608112222.u7BMMiTI042234@gw.catspoiler.org> Date: Thu, 11 Aug 2016 15:22:44 -0700 (PDT) From: Don Lewis Subject: Re: kernel panic caused by virtualbox(?) To: kostikbel@gmail.com cc: jkim@FreeBSD.org, freebsd-current@freebsd.org, jhb@freebsd.org In-Reply-To: <20160811080635.GE83214@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.22 Precedence: 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, 11 Aug 2016 22:22:56 -0000 On 11 Aug, Konstantin Belousov wrote: > On Wed, Aug 10, 2016 at 04:47:15PM -0700, Don Lewis wrote: >> On 10 Aug, Jung-uk Kim wrote: >> > On 08/09/16 05:12 AM, Konstantin Belousov wrote: >> >> On Mon, Aug 08, 2016 at 04:44:20PM -0700, Don Lewis wrote: >> >>> On 8 Aug, Konstantin Belousov wrote: >> >>>> On Mon, Aug 08, 2016 at 10:22:44AM -0700, John Baldwin wrote: >> >>>>> On Thursday, August 04, 2016 05:10:29 PM Don Lewis wrote: >> >>>>>> Reposted to -current to get some more eyes on this ... >> >>>>>> >> >>>>>> I just got a kernel panic when I started up a CentOS 7 VM in virtualbox. >> >>>>>> The host is: >> >>>>>> FreeBSD 12.0-CURRENT #17 r302500 GENERIC amd64 >> >>>>>> The virtualbox version is: >> >>>>>> virtualbox-ose-5.0.26 >> >>>>>> virtualbox-ose-kmod-5.0.26_1 >> >>>>>> >> >>>>>> The panic message is: >> >>>>>> >> >>>>>> panic: Unregistered use of FPU in kernel >> >>>>>> cpuid = 1 >> >>>>>> KDB: stack backtrace: >> >>>>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe085a55d030 >> >>>>>> vpanic() at vpanic+0x182/frame 0xfffffe085a55d0b0 >> >>>>>> kassert_panic() at kassert_panic+0x126/frame 0xfffffe085a55d120 >> >>>>>> trap() at trap+0x7ae/frame 0xfffffe085a55d330 >> >>>>>> calltrap() at calltrap+0x8/frame 0xfffffe085a55d330 >> >>>>>> --- trap 0x16, rip = 0xffffffff827dd3a9, rsp = 0xfffffe085a55d408, rbp = 0xfffffe085a55d430 --- >> >>>>>> g_pLogger() at 0xffffffff827dd3a9/frame 0xfffffe085a55d430 >> >>>>>> g_pLogger() at 0xffffffff8274e5c7/frame 0x3 >> >>>>>> KDB: enter: panic >> >>>>>> >> >>>>>> Since g_pLogger is a symbol in vboxdrv.ko, it looks like virtualbox is >> >>>>>> the trigger. >> >>>>>> >> >>>>>> There are no symbols for the virtualbox kmods, possibly because I >> >>>>>> installed them as an upgrade using packages (built with the same source >> >>>>>> tree version) instead of by using PORTS_MODULES in make.conf, so ports >> >>>>>> kgdb didn't have anything useful to say about what happened before the >> >>>>>> trap. >> >>>>>> >> >>>>>> This panic is very repeatable. I just got another one when starting the >> >>>>>> same VM., but this time the two calls before the trap were >> >>>>>> null_bug_bypass(). Hmn, that symbol is in nullfs ... >> >>>>>> >> >>>>>> I don't see this with a Windows 7 VM. >> >>>>>> >> >>>>>> All of the virtualbox kmod files are compiled with -mno-mmx -mno-sse >> >>>>>> -msoft-float -mno-aes -mno-avx >> >>>> Your disassemble listed fxrstor instruction that failing, or did I >> >>>> mis-remembered ? This is most likely some context switch code, either >> >>>> by virtual machine or erronously executed guest code. It is not a >> >>>> spontaneous use of FPU, but more likely something different. Can you >> >>>> confirm ? >> >>>> >> >>>> In either case, I do not remember any KBI changes around PCB layout or >> >>>> fpu_enter() KPI recently. >> >>>> >> >>>>> >> >>>>> I suspect head packages are quite likely built against the a "wrong" KBI >> >>>>> and are too fragile to use for kmods vs compiling from ports. :-/ I would >> >>>>> try a built-from-ports kmod to see if the panics go away. >> >>>> >> >>>> FWIW, I will commit the following change shortly. Since third-party >> >>>> modules break the invariant, either due to bugs (ndis wrappers) or >> >>>> possibly due to KBI breakage, it is worth to have the detection enabled >> >>>> for production kernels. >> >>> >> >>> Interesting ... I tried running virtualbox on recent 10.3-STABLE with a >> >>> GENERIC kernel and the guest seemed to operate properly. Then I enabled >> >>> INVARIANTS and got the panic. I suspect that is why nobody has stumbled >> >>> across this before. >> >>> >> >> This is yet another reason to promote KASSERT to the full panic. >> >> I expect that the vbox source lacks fpu_kern_enter() calls around the >> >> FPU state restoration. >> > >> > Unfortunately, the code is in MI source as it is unnecessary for >> > supported OSes (read: FreeBSD is not supported) and it's not easy to >> > inject fpu_kern_enter()/fpu_kern_leave() calls there. :-( >> >> It's a headache, but our ports can use patch files for that sort of >> thing ... > > Note that it is, most likely, completely useless to wrap single > FXRSTOR instruction into the fpu_kern_enter() braces. The purpose of > the instruction is to load ('legacy', as they call it, no AVX+) FPU state > into the machine context. If you put fpu_kern_leave() right after > the instruction, the context is flushed. Since it looks like the code is preparing to re-enter the guest, then calling fpu_kern_leave() doesn't make sense. > There must be some larger scope where the braces do make sense. And since > some other OSes do require similar precautions around the in-kernel FPU > access, I suspect that there should be some common place to put our KPI > calls. CPUMSetGuestXcr0() is the first stack frame. It wouldn't seem to make sense to call fpu_kern_enter() unless ASMXRstor() is going to be called, and the tests for that are right before the call. However, the comments above this function say: * Will load additional state if the FPU state is already loaded (in ring-0 & * raw-mode context). so it does look like something wasn't done before we got to this point. From owner-freebsd-current@freebsd.org Thu Aug 11 23:19:00 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 22AD0BB631F for ; Thu, 11 Aug 2016 23:19:00 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 C9B1C1803 for ; Thu, 11 Aug 2016 23:18:59 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: by mail-ua0-x22d.google.com with SMTP id 74so17487108uau.0 for ; Thu, 11 Aug 2016 16:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brilliantservice-co-jp.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=VSaMSpbVKSn5vorq8ODzBEkjtA4x0882KhH78Pi6X8w=; b=w6Pn98Ijm66VHEDqmuMGIkvkBWzElw4I16aEEMWDJbxa2axnUQ8EqvmYfJ6tpwDFFj 1Bby4WYTK+3rQbFXNHkjpIsrF+mzz1AP8dzbWjTPVvEOYF42p/zNw9OkFIuZztHgHBQW FS4NZDoN0gaF9ei2iOKRJtcaP6IIIcXWTJY3KjKaubpCMNuiD61klwE9a9d8xIEhfcjf OFZi27VQZ7fh27m5P6MO08Ey9u2YnDzR402lQR3otgvyK+gw/7ijUaMIn7BjTtfY8Akz fs687sGuUFhSfhXaf/2KYg5S6jUrX+Epf0xzBI9HpBvUo6a6UhZog8vx5q9Awvw028Ic Lt3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=VSaMSpbVKSn5vorq8ODzBEkjtA4x0882KhH78Pi6X8w=; b=JnWe0dqFW9s3yNrWCXfsggAPXO2UIoYhSkFy7KA21GQdkuncIQ3cIs22LH6NRrwLxj dc0xvRDpM0gbASm4RL1U/q0ZzvivmAG73EzyDg1dgOeYndQnTLBfdQ5UFJtJcR+98oXS ucZot6+AakgWc0rziApbrtLtu+0p6eVF+BjKwQFFUomfn1KY20Ul918Y3zUmcN+jx8Zo RU5QH0g0bWenQgSqCy1CS8cP5800kjpP8rUQ4NN7VtdwN1WFr6+jioQa9Ee6BeebKRfA lG8ulvdh1Q3x2my5q3zhn5Tfw2EYqEns7AKa3MpqYctFDU2cm/lGiztiQF1r8u36GsXA BE0A== X-Gm-Message-State: AEkoouuG9QPj0bMs2GAcR09odecy1M/k840oIF5F6gM/V6FX79+juxNi74SdcDbA8RbhHT4xRG0CQUXJJZl7795a/2cEY6MkM4eiV6cN8pbSlguCGuDFVsCFgFgPl3nYhS4ndtsgbgDZO0IvohBPj7bLtks= X-Received: by 10.176.69.175 with SMTP id u44mr4463841uau.61.1470957537998; Thu, 11 Aug 2016 16:18:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.7.33 with HTTP; Thu, 11 Aug 2016 16:18:42 -0700 (PDT) From: "Lundberg, Johannes" Date: Thu, 11 Aug 2016 16:18:42 -0700 Message-ID: Subject: Wayland work status To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 Aug 2016 23:19:00 -0000 Hi Here's a status update of my work and some questions. SETUP: System: FreeBSD 12-CURRENT ( https://github.com/FreeBSDDesktop/freebsd-base-graphics/tree/drm-next-4.6) Ports: https://github.com/freebsd/freebsd-ports-graphics/tree/wayland Package installed from this tree graphics/wayland (built without modification) x11/libinput (removed udev-stubs and linked to libudev-devd) Mesa-related (libEGL libGL libglesv2 libglapi libdrm) libudev-devd: https://github.com/wulf7/libudev-devd evdev: https://reviews.freebsd.org/D6998 Needed to update patches a bit to have them patch cleanly. =E2=80=8Bwlc: https://github.com/Cloudef/wlc I'm using this compositor library and the example implementation that comes with it. I've patched it to run on FreeBSD and will try to push the changes upstream this week. Maybe we can even make a port for this very excellent library? =E2=80=8BI will not do any work on porting Weston. WIP: =E2=80=8BWayland relies on kqueue which is not implemented in drm's 3.8 or = 4.6 branches. I'm working on this now for drm-next-4.6 and it is almost complete. I will probably implement it also in the 3.8 =E2=80=8Bbranch to be able to = run Wayland on both to compare and find bugs in linuxkpi more easily. Will share patch for 3.8 branch when done. =E2=80=8BCURRENT STATUS: My personal Wayland clients (built on Linux) compile and run nicely with udev and libinput in a Wayland window with X11 backend (wlc-based compositor). There is a problem with rendering updates when running with drm backend but will most likely be solved soon. Input devices and rendering is functional in native KMS (no X11), just a few small issues to iron out related to kqueue and linuxkpi. QUESTIONS: Currently by default evdev create /dev/input/eventX devices with 600 permission. These need to be accessible for non-root users. What is the best solution? Should we create a "input" group similar to "video" group is being used for rights to access /dev/drm devices? Best regards Johannes =E2=80=8B --=20 =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- =E7=A7=98=E5=AF=86=E4=BF=9D=E6=8C=81=E3=81=AB=E3=81=A4=E3=81=84=E3=81=A6=EF= =BC=9A=E3=81=93=E3=81=AE=E9=9B=BB=E5=AD=90=E3=83=A1=E3=83=BC=E3=83=AB=E3=81= =AF=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E3=81=AB=E9=80=81=E4=BF=A1=E3=81=97= =E3=81=9F=E3=82=82=E3=81=AE=E3=81=A7=E3=81=82=E3=82=8A=E3=80=81=E7=A7=98=E5= =8C=BF=E7=89=B9=E6=A8=A9=E3=81=AE=E5=AF=BE=E8=B1=A1=E3=81=A8=E3=81=AA=E3=82= =8B=E6=83=85=E5=A0=B1=E3=82=92=E5=90=AB=E3=82=93=E3=81=A7=E3=81=84=E3=81=BE= =E3=81=99=E3=80=82 =E3=82=82=E3=81=97=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E4=BB=A5=E5=A4=96=E3= =81=AE=E6=96=B9=E3=81=8C=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E5=A0= =B4=E5=90=88=E3=80=81=E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AE= =E7=A0=B4=E6=A3=84=E3=80=81=E3=81=8A=E3=82=88=E3=81=B3=E3=81=93=E3=81=AE=E3= =83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E9=96=A2=E3=81=99=E3=82=8B=E4=B8=80=E5=88= =87=E3=81=AE=E9=96=8B=E7=A4=BA=E3=80=81 =E8=A4=87=E5=86=99=E3=80=81=E9=85=8D=E5=B8=83=E3=80=81=E3=81=9D=E3=81=AE=E4= =BB=96=E3=81=AE=E5=88=A9=E7=94=A8=E3=80=81=E3=81=BE=E3=81=9F=E3=81=AF=E8=A8= =98=E8=BC=89=E5=86=85=E5=AE=B9=E3=81=AB=E5=9F=BA=E3=81=A5=E3=81=8F=E3=81=84= =E3=81=8B=E3=81=AA=E3=82=8B=E8=A1=8C=E5=8B=95=E3=82=82=E3=81=95=E3=82=8C=E3= =81=AA=E3=81=84=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81= =97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82 --- CONFIDENTIALITY NOTE: The information in this email is confidential and intended solely for the addressee. Disclosure, copying, distribution or any other action of use of this email by person other than intended recipient, is prohibited. If you are not the intended recipient and have received this email in error, please destroy the original message. From owner-freebsd-current@freebsd.org Thu Aug 11 23:51:45 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E22CBBB51A3; Thu, 11 Aug 2016 23:51:45 +0000 (UTC) (envelope-from cgull@glup.org) Received: from glup.org (216-15-121-172.c3-0.smr-ubr2.sbo-smr.ma.static.cable.rcn.com [216.15.121.172]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A248D1619; Thu, 11 Aug 2016 23:51:45 +0000 (UTC) (envelope-from cgull@glup.org) Received: from lister.boston.niksun.com (unknown [4.16.10.2]) by glup.org (Postfix) with ESMTPSA id A4595854C4; Thu, 11 Aug 2016 19:51:38 -0400 (EDT) Authentication-Results: glup.org; dmarc=none header.from=glup.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=glup.org; s=201009; t=1470959498; bh=beyw0oerXH2M/hp8m7Jg2IbJjxy6Qn7HvWezE3UPoLs=; h=Subject:To:References:Cc:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=JDOXsvII2HEtipKwMDqk9Lq41PNv6627W0ODIuZ0c1u9nWKz5ehSO7LX/oIdlJ+QG flGh7IBGo/ngml7iFcAAKa9a0Ji6y7FmbmjxBMoNbpbKIyMOoByYUXebHiOr59A4Zr o1i9hiEl8q7tpHQ/jGJVEgvPmfvbvd/zMpH53oOMEFuVJEmJydNqQC/vvD8s98mq1e s/PR8DAo8YO4eNUy8JQAc9+jX7nySasokfO8ygoGcvCfLjuVhzAjcM2hhZSuA6XUGx HJryVY+JtEg8d2qxU4tQng0Sr4tn4Is7k6BDurEUk1FzwHW2QRzDS8aWHw6BfNAkv+ +CbM8c/LG+Kkw== Subject: Re: Mosh regression between 10.x and 11-stable To: Peter Jeremy References: <20160810081831.GA65184@server.rulingia.com> <20160811101928.GC65184@server.rulingia.com> <68d0a6d4-2078-000c-6e22-b0b8721dfd2b@glup.org> <20160811195348.GD65184@server.rulingia.com> Cc: mosh-devel@mit.edu, freebsd-current@freebsd.org, freebsd-ports@freebsd.org From: John Hood Message-ID: <971e1e82-1b95-d1e4-6053-a8548fc1d109@glup.org> Date: Thu, 11 Aug 2016 19:51:37 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160811195348.GD65184@server.rulingia.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 12 Aug 2016 00:44:38 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 Aug 2016 23:51:46 -0000 That's interesting (not in a good way). Next thing to try: mosh --server='/usr/local/bin/mosh-server 2>/dev/null' peter@VPS (with an unmodified mosh-server) Mosh prints the 'MOSH CONNECT ...' message on stdout, then forks. The parent exits immediately, and the child prints verbose and copyright info to stderr. I'm wondering if the race is that the parent and child writes appear mixed together, corrupting the expected message. You might try adding a 'print;' in the while loop that digests this input in the mosh script. That'll tell us whether the script is not getting 'MOSH CONNECT...' at all, or if it's corrupted. You'll have to run mosh inside /usr/bin/script to capture that. regards, --jh On 08/11/16 03:53 PM, Peter Jeremy wrote: > On 2016-Aug-11 12:30:23 -0400, John Hood wrote: >> I still can't reproduce this on 3 different 11.0-BETA4 servers and a >> variety of clients and networks. Can you try and identify a more >> portable repro or at least figure out why it fails on your system? >> >> Please try applying this patch, too. It's a shot in the dark, though. > That patch seems to fix the problem I'm seeing. Not waiting for output > to drain is consistent with the symptoms I'm seeing, though I have no > idea why only my Linux client is affected. > From owner-freebsd-current@freebsd.org Fri Aug 12 06:23:25 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BFD49BB77E9 for ; Fri, 12 Aug 2016 06:23:25 +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 4FC5D11CD; Fri, 12 Aug 2016 06:23:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u7C6NFdC041418 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 12 Aug 2016 09:23:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u7C6NFdC041418 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u7C6NFbx041417; Fri, 12 Aug 2016 09:23:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 12 Aug 2016 09:23:15 +0300 From: Konstantin Belousov To: Don Lewis Cc: jkim@FreeBSD.org, freebsd-current@freebsd.org, jhb@freebsd.org Subject: Re: kernel panic caused by virtualbox(?) Message-ID: <20160812062315.GN83214@kib.kiev.ua> References: <20160811080635.GE83214@kib.kiev.ua> <201608112222.u7BMMiTI042234@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201608112222.u7BMMiTI042234@gw.catspoiler.org> User-Agent: Mutt/1.6.1 (2016-04-27) 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.22 Precedence: 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, 12 Aug 2016 06:23:25 -0000 On Thu, Aug 11, 2016 at 03:22:44PM -0700, Don Lewis wrote: > On 11 Aug, Konstantin Belousov wrote: > > On Wed, Aug 10, 2016 at 04:47:15PM -0700, Don Lewis wrote: > >> On 10 Aug, Jung-uk Kim wrote: > >> > On 08/09/16 05:12 AM, Konstantin Belousov wrote: > >> >> On Mon, Aug 08, 2016 at 04:44:20PM -0700, Don Lewis wrote: > >> >>> On 8 Aug, Konstantin Belousov wrote: > >> >>>> On Mon, Aug 08, 2016 at 10:22:44AM -0700, John Baldwin wrote: > >> >>>>> On Thursday, August 04, 2016 05:10:29 PM Don Lewis wrote: > >> >>>>>> Reposted to -current to get some more eyes on this ... > >> >>>>>> > >> >>>>>> I just got a kernel panic when I started up a CentOS 7 VM in virtualbox. > >> >>>>>> The host is: > >> >>>>>> FreeBSD 12.0-CURRENT #17 r302500 GENERIC amd64 > >> >>>>>> The virtualbox version is: > >> >>>>>> virtualbox-ose-5.0.26 > >> >>>>>> virtualbox-ose-kmod-5.0.26_1 > >> >>>>>> > >> >>>>>> The panic message is: > >> >>>>>> > >> >>>>>> panic: Unregistered use of FPU in kernel > >> >>>>>> cpuid = 1 > >> >>>>>> KDB: stack backtrace: > >> >>>>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe085a55d030 > >> >>>>>> vpanic() at vpanic+0x182/frame 0xfffffe085a55d0b0 > >> >>>>>> kassert_panic() at kassert_panic+0x126/frame 0xfffffe085a55d120 > >> >>>>>> trap() at trap+0x7ae/frame 0xfffffe085a55d330 > >> >>>>>> calltrap() at calltrap+0x8/frame 0xfffffe085a55d330 > >> >>>>>> --- trap 0x16, rip = 0xffffffff827dd3a9, rsp = 0xfffffe085a55d408, rbp = 0xfffffe085a55d430 --- > >> >>>>>> g_pLogger() at 0xffffffff827dd3a9/frame 0xfffffe085a55d430 > >> >>>>>> g_pLogger() at 0xffffffff8274e5c7/frame 0x3 > >> >>>>>> KDB: enter: panic > >> >>>>>> > >> >>>>>> Since g_pLogger is a symbol in vboxdrv.ko, it looks like virtualbox is > >> >>>>>> the trigger. > >> >>>>>> > >> >>>>>> There are no symbols for the virtualbox kmods, possibly because I > >> >>>>>> installed them as an upgrade using packages (built with the same source > >> >>>>>> tree version) instead of by using PORTS_MODULES in make.conf, so ports > >> >>>>>> kgdb didn't have anything useful to say about what happened before the > >> >>>>>> trap. > >> >>>>>> > >> >>>>>> This panic is very repeatable. I just got another one when starting the > >> >>>>>> same VM., but this time the two calls before the trap were > >> >>>>>> null_bug_bypass(). Hmn, that symbol is in nullfs ... > >> >>>>>> > >> >>>>>> I don't see this with a Windows 7 VM. > >> >>>>>> > >> >>>>>> All of the virtualbox kmod files are compiled with -mno-mmx -mno-sse > >> >>>>>> -msoft-float -mno-aes -mno-avx > >> >>>> Your disassemble listed fxrstor instruction that failing, or did I > >> >>>> mis-remembered ? This is most likely some context switch code, either > >> >>>> by virtual machine or erronously executed guest code. It is not a > >> >>>> spontaneous use of FPU, but more likely something different. Can you > >> >>>> confirm ? > >> >>>> > >> >>>> In either case, I do not remember any KBI changes around PCB layout or > >> >>>> fpu_enter() KPI recently. > >> >>>> > >> >>>>> > >> >>>>> I suspect head packages are quite likely built against the a "wrong" KBI > >> >>>>> and are too fragile to use for kmods vs compiling from ports. :-/ I would > >> >>>>> try a built-from-ports kmod to see if the panics go away. > >> >>>> > >> >>>> FWIW, I will commit the following change shortly. Since third-party > >> >>>> modules break the invariant, either due to bugs (ndis wrappers) or > >> >>>> possibly due to KBI breakage, it is worth to have the detection enabled > >> >>>> for production kernels. > >> >>> > >> >>> Interesting ... I tried running virtualbox on recent 10.3-STABLE with a > >> >>> GENERIC kernel and the guest seemed to operate properly. Then I enabled > >> >>> INVARIANTS and got the panic. I suspect that is why nobody has stumbled > >> >>> across this before. > >> >>> > >> >> This is yet another reason to promote KASSERT to the full panic. > >> >> I expect that the vbox source lacks fpu_kern_enter() calls around the > >> >> FPU state restoration. > >> > > >> > Unfortunately, the code is in MI source as it is unnecessary for > >> > supported OSes (read: FreeBSD is not supported) and it's not easy to > >> > inject fpu_kern_enter()/fpu_kern_leave() calls there. :-( > >> > >> It's a headache, but our ports can use patch files for that sort of > >> thing ... > > > > Note that it is, most likely, completely useless to wrap single > > FXRSTOR instruction into the fpu_kern_enter() braces. The purpose of > > the instruction is to load ('legacy', as they call it, no AVX+) FPU state > > into the machine context. If you put fpu_kern_leave() right after > > the instruction, the context is flushed. > > Since it looks like the code is preparing to re-enter the guest, then > calling fpu_kern_leave() doesn't make sense. > > > There must be some larger scope where the braces do make sense. And since > > some other OSes do require similar precautions around the in-kernel FPU > > access, I suspect that there should be some common place to put our KPI > > calls. > > CPUMSetGuestXcr0() is the first stack frame. It wouldn't seem to make > sense to call fpu_kern_enter() unless ASMXRstor() is going to be called, > and the tests for that are right before the call. However, the comments > above this function say: > > * Will load additional state if the FPU state is already loaded (in ring-0 & > * raw-mode context). > > so it does look like something wasn't done before we got to this point. > In fact, VMM must save old FPU state and load the guest state somewhere. This must be done on all operating systems. We do not consistently clear CR0.TS bit when entering the kernel, but if the thread never used FPU in usermode, the bit will be set. OTOH, the bit is set on the context switch. You need to use fpu_kern_enter() (preferred) instead of the code which saves current FPU state, and fpu_kern_leave() on returning control to the host OS. From owner-freebsd-current@freebsd.org Fri Aug 12 07:21:12 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 09317BB65A9; Fri, 12 Aug 2016 07:21:12 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F0BB21E4B; Fri, 12 Aug 2016 07:21:11 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1470986462434533.3074407486148; Fri, 12 Aug 2016 00:21:02 -0700 (PDT) Date: Fri, 12 Aug 2016 00:21:02 -0700 From: Matthew Macy To: "freebsd-x11@freebsd.org" , "freebsd-current@freebsd.org" Message-ID: <1567da024af.bfcdfbc455906.5120985150976586422@nextbsd.org> Subject: drm-4.7-rc1 tagged MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 12 Aug 2016 07:21:12 -0000 A few days ago I branched drm-next-4.6 in to drm-next and synced it with Torvalds' tree as of the v4.6 tag. I then integrated the ~800 commits to drm / i915 / radeon / amdgpu , testing periodically along the way and updating the linuxkpi as needed. I've just tagged the drm-next branch with drm-4.7-rc1 to indicate that it is in sync with 4.7-rc1 upstream. If any of you are feeling adventurous I would appreciate it if you would try it and report any regressions with respect to drm-next-4.6. I'm aware that there are a number of issues with drm-next-4.6 so I'm only really interested in _new_ issues. If you're feeling really adventurous - run the piglit test suite from the ports' xserver-next branch and do a root cause analysis on test failures. As always the repo is at: https://github.com/FreeBSDDesktop/freebsd-base-graphics Look through the existing open issues before filing a report and check the wiki first to address any problems. Cheers. -M From owner-freebsd-current@freebsd.org Fri Aug 12 07:58:27 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2F794BB71E7 for ; Fri, 12 Aug 2016 07:58:27 +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 DV Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 10CA315E7 for ; Fri, 12 Aug 2016 07:58:26 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.0.7] (cpc91230-cmbg18-2-0-cust661.5-4.cable.virginm.net [82.1.230.150]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id u7C7wFcd094955 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Aug 2016 07:58:19 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host cpc91230-cmbg18-2-0-cust661.5-4.cable.virginm.net [82.1.230.150] claimed to be [192.168.0.7] Content-Type: multipart/signed; boundary="Apple-Mail=_9E23D2B0-78A5-4BF5-8DDF-29758977C114"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Wayland work status From: David Chisnall In-Reply-To: Date: Fri, 12 Aug 2016 08:58:31 +0100 Cc: FreeBSD Current Message-Id: <4D6E4D70-210B-439F-AC9E-F09B79C5A3A1@FreeBSD.org> References: To: "Lundberg, Johannes" X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 12 Aug 2016 07:58:27 -0000 --Apple-Mail=_9E23D2B0-78A5-4BF5-8DDF-29758977C114 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 12 Aug 2016, at 00:18, Lundberg, Johannes = wrote: >=20 > Currently by default evdev create /dev/input/eventX devices with 600 > permission. These need to be accessible for non-root users. What is = the > best solution? Should we create a "input" group similar to "video" = group is > being used for rights to access /dev/drm devices? There is a similar problem for the drm devices (by default, users = can=E2=80=99t use 3D acceleration). A devfs.conf policy can change the = permissions. I=E2=80=99d suggest that we create a default group called = something like console or local, put new users there by default, and = make drm and evdev devices accessible by this group. David --Apple-Mail=_9E23D2B0-78A5-4BF5-8DDF-29758977C114 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK5jCCBPww ggPkoAMCAQICECJrrb9nBol9MHok/UZg/AYwDQYJKoZIhvcNAQELBQAwdTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTAeFw0xNjA0MTkw OTI3NDJaFw0xNzA0MTkwOTI3NDJaMEQxHTAbBgNVBAMMFHRoZXJhdmVuQGZyZWVic2Qub3JnMSMw IQYJKoZIhvcNAQkBFhR0aGVyYXZlbkBmcmVlYnNkLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALsL5pEhrGjrswHVdMHWhgxb8ARKDYRePSqpDLmjJ40bpx+n1zrvIwjC2Vk2IpoD 04rg5Pog2IrhnX+Qk2NSXzBXWj2JAaTc9OtSeAY0BtgJYXONGONQbRKVy97QBdzd1SbMEzDrOgH5 UDI+5sF1PboOTmLyTAPI9273XdfZ0BnstUXs8NXr/7p9E5CWJOsO1iQcINbm4XiwC1PLNMeWUknE Nji/hFKwcE8IFtaUe1ymbw6yA3rBpDu3KewIRD1T66FPTZJeIzvUoBIqWd+GAOfCBG2QYmbc3y/x K2hCtcXThcB1uVFA2q39koLKA8wHyqv4Jhm3wzhAqKDsWK4bGW0CAwEAAaOCAbcwggGzMA4GA1Ud DwEB/wQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwCQYDVR0TBAIwADAdBgNV HQ4EFgQU5J3Kc8GeW8pEGxBkcMoA7eUOPRwwHwYDVR0jBBgwFoAUJIFsOWG+SQ+PtxtGK8kotSdI bWgwbwYIKwYBBQUHAQEEYzBhMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20w OQYIKwYBBQUHMAKGLWh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3NjYS5jbGllbnQxLmNy dDA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zY2EtY2xpZW50MS5j cmwwHwYDVR0RBBgwFoEUdGhlcmF2ZW5AZnJlZWJzZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgUwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQBSBDH+kZf5 bZkNFcMSPdfnGC7F8utBIxs2bi3JQjsBoQTm1vnXdwgINSfO9At6iQZHoEyj8ZE6PcMFuEU0+bk0 aE8aYcW59WnxfWx943upZoMhX0YVaJcFK01EHFrddRAP44sh7Eu6JtdFuAG+6btDReMcg35Qm65X 7/280aVm7awadJ+IQs8r9qBVk2NFqkvHCETtJjNWXd7M6mcsfXstvykbubPQH/VNW/zrX6yzIcI4 aoz+Sn8RJmHNkk6cImqe1KvsdDLXmqCoeoMwos62pT18RaI//jwTdmnf5EHFMlevnxOr7rzA++71 OSZfdYf6+nvHOod1F721rNuy6lxFMIIF4jCCA8qgAwIBAgIQa6eKfQrXiNZRCvlZ5Oe04TANBgkq hkiG9w0BAQsFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTUxMjE2MDEwMDA1WhcNMzAxMjE2MDEwMDA1WjB1 MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50 IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvX3a98OifYP2W4L921tfrh4bdcC1 Ga+YJKy7V3nYNewJHnzMlBsK0Hb8Dm4Wo3FZpylcYa1MJGT10QMGWaLER3xCIuRR+8eklf/EqeZW RLojJ7zBRtjMywPOCelrOU+DX12dKp+Ez4J6919rz1UudTO1GvZyCYJ/I7062uHsskM8b7gPxmcC oO1UHwwpgkvpCArJWGFoFzjLdsZbErJcS3HtAhlkbE/BKTMrdYg35Uo12SLBO5tbk8h2imbKTC8i Ms+pskrvI/AVlh6QoTTXk6xboVX6zgMgzxSVVLymQiygYYm0y5aMsvi2raFhC643SOGvErWWPPnS EfbeAD1xswIDAQABo4IBZDCCAWAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/AgEAMDIGA1UdHwQrMCkwJ6AloCOGIWh0dHA6Ly9j cmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDBmBggrBgEFBQcBAQRaMFgwJAYIKwYBBQUHMAGGGGh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTAwBggrBgEFBQcwAoYkaHR0cDovL2FpYS5zdGFydHNzbC5j b20vY2VydHMvY2EuY3J0MB0GA1UdDgQWBBQkgWw5Yb5JD4+3G0YrySi1J0htaDAfBgNVHSMEGDAW gBROC+8apEBbpRdphzDKNGhD0EGu8jA/BgNVHSAEODA2MDQGBFUdIAAwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4ICAQCL4/eH7AGL hK0PAQJbnOEjJyMEvTTwcAJuUh/bodjQl06u4putYOxdSyIjSP/sKt+31LmjG8+IO1WqykE4H/Lm 7NKezWVnCHuwb3ptgFmlwbMbGkU2MOZBtwzfKXdYUhFLhaE2uw5jXhXvLYitQay962wP5uPI6eAI hV4L8aaya1u4s7MnrTq0Rz25FuGNO79vTHYWj797tSRC8rM16js4yGKOLFpQvIg0F8IElv57b1st p+C7omqM5Qn15dePbSnqr8Jb65WtmJJbnv6rlqfY/aLuE/zmNAlzLmPgfMDStKIXdg+EoYBZTEo8 wBUaBxihfNbJ069ndQOxMNNqBelEMgpAtmjTbCuXFjqIwWq+XOx6ZV/Wh2FAmaLsSHlNvEjjSQMZ wE4EeHCdo66ZmEs/5JYlCeOkulKVQ6P3m5/XOj2jP17Q2AgmjP+11+sHN7PvrG0OwrQp9QMe3X+r n0G8MjtFfqBWvR9CgLIxzM3MJNxFdgdjS2rYnShP5uxvqwfZvhZVYCIkqdJhpYON0DvSodfiar0w iM79mySZJjzC0CTbiisBzS/BeBhqeo2wFfli/iw3hn1XKvAx0ty6w/scmBF0AYqmRHYj1TjMSw0l Al7AztLglqWjUPI+sukvadMRPxmtKXlS2nVR4an/Z16imsZ69+fFYH68c1CK7zmjozGCA04wggNK AgEBMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3Mg MSBDbGllbnQgQ0ECECJrrb9nBol9MHok/UZg/AYwCQYFKw4DAhoFAKCCAZkwGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwODEyMDc1ODMyWjAjBgkqhkiG9w0BCQQx FgQUgKZiZkisfxz/tIiARYhXwxqAB9EwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJ TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAia62/ZwaJ fTB6JP1GYPwGMIGcBgsqhkiG9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkx IzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAia62/ZwaJfTB6JP1GYPwGMA0G CSqGSIb3DQEBAQUABIIBAFvHPnVT9BHzd250YsdObLZyv4PVtTQF1QNg5fxupcXxvGYFwAUd4cRA 5fzH4CgHp/cwJ6GwDNXfZBb8zm2vPaHakQODd32AF+3MfGPKlqd7f1jOPCKse2rRIEwrBBsqulRC se5lZg83o5j1Xys3gt6vaWowmr2qXjQZVv6N4CeD9oGinrltQLG+niioV7OVgUJozaCK4nkCfE3k se0uyOVmbKrOBKxK5JG/iIAMWXpcA2QG14Ig6dmBD3xAB009tYanzhNpwwOINIJEcfzKZBsRTD/z 6lKEFZBcjc/H1U51/8Y+s5kb3emwQMy3T1Ils02oXWk3um1kPEipHy9Lzo8AAAAAAAA= --Apple-Mail=_9E23D2B0-78A5-4BF5-8DDF-29758977C114-- From owner-freebsd-current@freebsd.org Fri Aug 12 11:07:50 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B6D55BB7B90 for ; Fri, 12 Aug 2016 11:07:50 +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 9E5DD1D4E; Fri, 12 Aug 2016 11:07:50 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 9105E1195; Fri, 12 Aug 2016 11:07:50 +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 3FEB571D3; Fri, 12 Aug 2016 11:07:50 +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 J2M7r37FHUoJ; Fri, 12 Aug 2016 11:07:46 +0000 (UTC) Subject: Re: PORTS_MODULES breakage on HEAD DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com ACD7271CE To: Don Lewis , freebsd-current@FreeBSD.org, Kevin Oberman References: <201608080044.u780iEuP026615@gw.catspoiler.org> From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <896880bc-3ac8-8cf9-bf25-7cf270571019@FreeBSD.org> Date: Fri, 12 Aug 2016 04:07:45 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="w5EGPaNNJ271k50qm0N6JOK7JNDxHx18w" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 12 Aug 2016 11:07:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --w5EGPaNNJ271k50qm0N6JOK7JNDxHx18w Content-Type: multipart/mixed; boundary="bbbSLFEJNxERx69FRelQSeJHELRhHw2sG" From: Bryan Drewery To: Don Lewis , freebsd-current@FreeBSD.org, Kevin Oberman Message-ID: <896880bc-3ac8-8cf9-bf25-7cf270571019@FreeBSD.org> Subject: Re: PORTS_MODULES breakage on HEAD References: <201608080044.u780iEuP026615@gw.catspoiler.org> In-Reply-To: --bbbSLFEJNxERx69FRelQSeJHELRhHw2sG Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 8/10/2016 4:20 PM, Bryan Drewery wrote: > On 8/7/16 5:44 PM, Don Lewis wrote: >> Adding PORTS_MODULES=3Demulators/virtualbox-ose-kmod recently broke on= >> HEAD. When I do that I get this failure: >> >> =3D=3D=3D> Ports module emulators/virtualbox-ose-kmod (all) >> cd ${PORTSDIR:-/usr/ports}/emulators/virtualbox-ose-kmod; PATH=3D/usr/= obj/usr/src/ >> tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/s= rc/tmp/leg >> acy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sb= in:/bin:/u >> sr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin SRC_BASE=3D/usr/src = OSVERSION=3D12 >> 00000 WRKDIRPREFIX=3D/usr/obj/usr/src/sys/ make -B clean all >> =3D=3D=3D> Cleaning for virtualbox-ose-kmod-5.0.26_1 >> =3D=3D=3D> License GPLv2 accepted by the user >> =3D=3D=3D> Found saved configuration for virtualbox-ose-kmod-4.3.34 >> =3D=3D=3D> virtualbox-ose-kmod-5.0.26_1 depends on file: /usr/local/= sbin/pkg - found >> =3D=3D=3D> Fetching all distfiles required by virtualbox-ose-kmod-5.0.= 26_1 for buildin >> g >> =3D=3D=3D> Extracting for virtualbox-ose-kmod-5.0.26_1 >> =3D> SHA256 Checksum OK for VirtualBox-5.0.26.tar.bz2. >> =3D=3D=3D> Patching for virtualbox-ose-kmod-5.0.26_1 >> =3D=3D=3D> Applying FreeBSD patches for virtualbox-ose-kmod-5.0.26_1 >> =3D=3D=3D> virtualbox-ose-kmod-5.0.26_1 depends on executable: kmk -= found >> =3D=3D=3D> Configuring for virtualbox-ose-kmod-5.0.26_1 >> Checking for environment: Determined build machine: freebsd.amd64, tar= get machin >> e: freebsd.amd64, OK. >> Checking for kBuild: found, OK. >> Checking for gcc: >> ** cc -target x86_64-unknown-freebsd12.0 --sysroot (variable CC) not= found! >> Check /usr/obj/usr/src/sys/usr/ports/emulators/virtualbox-ose-kmod/wor= k/VirtualB >> ox-5.0.26/configure.log for details >> =3D=3D=3D> Script "configure" failed unexpectedly. >> Please report the problem to vbox@FreeBSD.org [maintainer] and attach = the >> "/usr/obj/usr/src/sys//usr/ports/emulators/virtualbox-ose-kmod/work/Vi= rtualBox-5 >> .0.26/config.log" >> >> >> It appears that the problem is due to CC being set to: >> cc -target x86_64-unknown-freebsd12.0 --sysroot >> and the Makefile for the port passes this: >> --with-gcc=3D"${CC}" >> to configure. The configure script passes $CC to check_avail, which >> does a -z test on it. >> >> I think that CC should just be set to "cc" and the rest should get add= ed >> to CFLAGS. I suspect this got broken by the recent crossbuild changes= =2E >> >=20 >=20 > It's a SYSTEM_COMPILER bug. I'll look into fixing it. >=20 > For now you can try passing WITHOUT_SYSTEM_COMPILER=3Dyes as a workarou= nd. >=20 >=20 I've committed a fix to head in r304005. I will MFC it to stable/11 in about a week. --=20 Regards, Bryan Drewery --bbbSLFEJNxERx69FRelQSeJHELRhHw2sG-- --w5EGPaNNJ271k50qm0N6JOK7JNDxHx18w 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 iQEcBAEBAgAGBQJXra4BAAoJEDXXcbtuRpfPtCgIAL2elshP7PgpIjDtS+H8gw+V 6A2qn/VktFeR7iOOPeDWFYv+DWUpkR2ZEbpwmJxtPR3XGv+BNvph2gxlSFFTKSit ggrtp3XvjvoEn4S14BQSM53KhnCqjXhmkPlCThBOxteWsywwRcGeJ4JwsBpFFc2V dO+w/e/XajunUBt9+gJb/irjjK3KLJbHtpMJmeB2AlWy2WGsg6ovlXZ66p9GuK05 vBJjMLFN76tvdjQwD0TxK/k4xI/lbxUqyLa349icxMGbw9/X8QnjkwE+tWNr3Ngi M3aGI32O6d5oBBxg2FCrgVT0J443aaEsD+4b3WQn7XWe8cvrAH1BShdPF/iO7J4= =0fQT -----END PGP SIGNATURE----- --w5EGPaNNJ271k50qm0N6JOK7JNDxHx18w-- From owner-freebsd-current@freebsd.org Fri Aug 12 14:32:52 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D9E8DBB7895 for ; Fri, 12 Aug 2016 14:32:52 +0000 (UTC) (envelope-from jan.kokemueller@gmail.com) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6CEEC1695 for ; Fri, 12 Aug 2016 14:32:52 +0000 (UTC) (envelope-from jan.kokemueller@gmail.com) Received: by mail-wm0-x22a.google.com with SMTP id q128so31711117wma.1 for ; Fri, 12 Aug 2016 07:32:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=zg3NcKagTdzGCZqZP4BtuA5FkDeYjcu9j39XhhW6Oa4=; b=kDlq2lRFUy62qOLq56oD1CIZuIsGOOeEFt3w7oQSd8XOI1E+YTkWVNTmQA2oWPlxyB 0IBE+9bz1XjvCtj9KseEOL0vy9MO1mmiSmaobYzg3rjHIA2sDsFbnLh3B8r19Vys/KWC hfeLm9GUOLHyqKxHPFUATJ1JdT/Wr1DwxreRaVtHH+D0lEDKHBtWJIAM6MKVUWu0IRTF WxKiWHQxUvuuFsfSXMKOpMCTHyXOtRUdqXZex/E+0TYcB4HPmBZilkHQiksYSng7JYgd U3Lv8DHsERbOEexTQ7IUK28eSzi/S+QY1l7G4UajTgRa+tg7lPOJM5wWHJxFvT7V0R2b T3Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=zg3NcKagTdzGCZqZP4BtuA5FkDeYjcu9j39XhhW6Oa4=; b=EzaihjwG3K+gdnNt0Swg+pN+63sI3WbmpwWXdPzCHtdwKtgnuPTB+ZCXrUT5zzD9E1 /0IP8lVljMBksWXtEWrWFPGLY4JhDuRpByS1kbLlSqCOXYNAUmIb0OvksSqNU43mX6QB KFos1mM4cbaSQnfZfzlylzz+ZllDiRc4QLM4+iN5WEYCVVzF/Rmpras+ZpqJG9SjnVA6 DHKLZkQr+3qNdg5bZhV3N9H14DlMSecXrpX5EmwzcoYdKoxy6tGP5m9Xkj9rvZp37qhS n6Hp16WP7YZqpMIDdGApPNXKBkXrokgwFwsyvyPHdNa1UVnPQqzqfFAlHir8Uqy62Mis UCJQ== X-Gm-Message-State: AEkoouvWdkfKH1lui1bxuO91+cvPBXwmxi6JUi2ETV734J7YUTYmnnNlGRJgI4UDLni55g== X-Received: by 10.194.149.113 with SMTP id tz17mr19110534wjb.64.1471012370712; Fri, 12 Aug 2016 07:32:50 -0700 (PDT) Received: from ?IPv6:2001:470:1f15:b1f:bdb3:7df:2a05:22c7? ([2001:470:1f15:b1f:bdb3:7df:2a05:22c7]) by smtp.googlemail.com with ESMTPSA id wc3sm7783912wjc.47.2016.08.12.07.32.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Aug 2016 07:32:49 -0700 (PDT) Subject: Re: Wayland work status To: "Lundberg, Johannes" , FreeBSD Current References: From: =?UTF-8?Q?Jan_Kokem=c3=bcller?= Message-ID: <1df3c73a-dab3-d688-c56a-ed7c4361a9bf@gmail.com> Date: Fri, 12 Aug 2016 16:32:49 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 12 Aug 2016 14:32:52 -0000 Hi, On 12.08.16 01:18, Lundberg, Johannes wrote: > x11/libinput (removed udev-stubs and linked to libudev-devd) If you feel adventurous, you can try out the current state of the libinput port here (1.4.0): https://github.com/jiixyj/libinput I haven't yet tested the port with the evdev kernel work, though. I've been using my evdev implementation in userspace which uses cuse to create /dev/input/event* devices (https://github.com/jiixyj/evdevfbsd). I needed to adjust a few ioctl defines from the linux/input.h header to make some features work. The way Linux defines EVIOCGMTSLOTS and EVIOCGRAB didn't work with cuse. The kernel evdev implementation may work slightly differently, so that's something to look out for. I've moved the udev-stubs.{c,h} out of the port into a separate library, but libudev-devd (https://github.com/wulf7/libudev-devd) certainly looks more mature! The libinput code itself isn't that different from upstream anymore. I've removed the epoll->kqueue porting work and written a small epoll wrapper instead that implements everything libinput/libevdev and possibly wayland needs (https://github.com/jiixyj/epoll-shim). This isn't integrated yet into the build system of the libinput port, though. So you have to do something like 'CFLAGS="-I ~/git/epoll-shim/include -L ~/git/epoll-shim -lepoll-shim -pthread" LDFLAGS="-pthread -lrt"' when configuring libinput. All this can be used with the xf86-input-libinput driver to get smooth and horizontal scrolling in X, which is awesome! -- Jan From owner-freebsd-current@freebsd.org Fri Aug 12 16:50:05 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1B0B7BB76F4 for ; Fri, 12 Aug 2016 16:50:05 +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 D1A51170E; Fri, 12 Aug 2016 16:50:04 +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 u7CGnsva044815; Fri, 12 Aug 2016 09:49:58 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201608121649.u7CGnsva044815@gw.catspoiler.org> Date: Fri, 12 Aug 2016 09:49:54 -0700 (PDT) From: Don Lewis Subject: Re: PORTS_MODULES breakage on HEAD To: bdrewery@FreeBSD.org cc: freebsd-current@FreeBSD.org, rkoberman@gmail.com In-Reply-To: <896880bc-3ac8-8cf9-bf25-7cf270571019@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 12 Aug 2016 16:50:05 -0000 On 12 Aug, Bryan Drewery wrote: > On 8/10/2016 4:20 PM, Bryan Drewery wrote: >> On 8/7/16 5:44 PM, Don Lewis wrote: >>> Adding PORTS_MODULES=emulators/virtualbox-ose-kmod recently broke on >>> HEAD. When I do that I get this failure: >>> >>> ===> Ports module emulators/virtualbox-ose-kmod (all) >>> cd ${PORTSDIR:-/usr/ports}/emulators/virtualbox-ose-kmod; PATH=/usr/obj/usr/src/ >>> tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/leg >>> acy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/u >>> sr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin SRC_BASE=/usr/src OSVERSION=12 >>> 00000 WRKDIRPREFIX=/usr/obj/usr/src/sys/ make -B clean all >>> ===> Cleaning for virtualbox-ose-kmod-5.0.26_1 >>> ===> License GPLv2 accepted by the user >>> ===> Found saved configuration for virtualbox-ose-kmod-4.3.34 >>> ===> virtualbox-ose-kmod-5.0.26_1 depends on file: /usr/local/sbin/pkg - found >>> ===> Fetching all distfiles required by virtualbox-ose-kmod-5.0.26_1 for buildin >>> g >>> ===> Extracting for virtualbox-ose-kmod-5.0.26_1 >>> => SHA256 Checksum OK for VirtualBox-5.0.26.tar.bz2. >>> ===> Patching for virtualbox-ose-kmod-5.0.26_1 >>> ===> Applying FreeBSD patches for virtualbox-ose-kmod-5.0.26_1 >>> ===> virtualbox-ose-kmod-5.0.26_1 depends on executable: kmk - found >>> ===> Configuring for virtualbox-ose-kmod-5.0.26_1 >>> Checking for environment: Determined build machine: freebsd.amd64, target machin >>> e: freebsd.amd64, OK. >>> Checking for kBuild: found, OK. >>> Checking for gcc: >>> ** cc -target x86_64-unknown-freebsd12.0 --sysroot (variable CC) not found! >>> Check /usr/obj/usr/src/sys/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualB >>> ox-5.0.26/configure.log for details >>> ===> Script "configure" failed unexpectedly. >>> Please report the problem to vbox@FreeBSD.org [maintainer] and attach the >>> "/usr/obj/usr/src/sys//usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-5 >>> .0.26/config.log" >>> >>> >>> It appears that the problem is due to CC being set to: >>> cc -target x86_64-unknown-freebsd12.0 --sysroot >>> and the Makefile for the port passes this: >>> --with-gcc="${CC}" >>> to configure. The configure script passes $CC to check_avail, which >>> does a -z test on it. >>> >>> I think that CC should just be set to "cc" and the rest should get added >>> to CFLAGS. I suspect this got broken by the recent crossbuild changes. >>> >> >> >> It's a SYSTEM_COMPILER bug. I'll look into fixing it. >> >> For now you can try passing WITHOUT_SYSTEM_COMPILER=yes as a workaround. >> >> > > I've committed a fix to head in r304005. I will MFC it to stable/11 in > about a week. Thanks! From owner-freebsd-current@freebsd.org Fri Aug 12 17:09:28 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8A11DBB7EF3 for ; Fri, 12 Aug 2016 17:09:28 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (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 4B2871464 for ; Fri, 12 Aug 2016 17:09:28 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: by mail-ua0-x22f.google.com with SMTP id 74so51718500uau.0 for ; Fri, 12 Aug 2016 10:09:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brilliantservice-co-jp.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dD3CjMb0Cx0Za5mEFhHefujvkxRcZ/MA14diOh2eZN8=; b=0mvs1PdWYJ3k1Fc/v6HUqua3V/l1EAe8A4C3vffKcNYZQ21WjKChoMe07nraTJ/CuR c2wus7KzJzWPJPh7POvp2lpuieWAcyhZTq0FHFdeD97Tq9hTZhHrlWTrlYNraKFL0lDa r0bVAbtbCFycX+scsgh1TISJ3UBjoA00J00DkAyHsx3otTflEZ4iKBLPPGTGgsCue/Ca o0w2RAjSLu94erjxO5WzJpTkDAAIl2qJsEQ4uF6miHcjAksxsdYiyj9pmgDpP8MnQBxv CWRBghj28h8L0fwsD7C2b7PNFXQWWW1TJ5PCzLQrT9R9XYcL5ELOZ4x5I5a1MiJMqX/9 6TPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dD3CjMb0Cx0Za5mEFhHefujvkxRcZ/MA14diOh2eZN8=; b=PUprOzJX9a6O0d7PuQVY2UZMq6QeqTLrCHeWqYTUYv5hUTgEouD0qAE+8yj/DC7b3V YhkJIxRiuvgbYqMXXMN2MMkraJiA50fBJEzU3uM9Pi7f8TzSCrDl7CUg2zAbAEglRRud bZge0enzykgQdR09SaIOnCHlDyG8X2plJ+cUW9apW92MbnxcfpcuJeUxCOy+OXw8/5L/ HDjPW7/7kJw0bBMu6RCoIi2EwB2U6sh9CH8FKreDBd6fgcS1MTcWTv/aVAy7FcO+Uon3 qjdTlLnZoZXZmA38iMn6lGIKoqVe6P2+Qimu5G+syqAZvrf8qmg0VsuE60/5I9+ORBU3 KHvw== X-Gm-Message-State: AEkoouuvL8OJmlwLZwNaGGsNaTTOaMIAyjYxs99dwe1w5K6QTLmwzTH5DvyfHduQvEiiuIOVYjHBFHh/ZF+V17DqqEOjrrKiGBw31v7UVsK4IizSA8PGuTVO+/UpiXsDAnNqmNekAGohndGdww284wOWz5U= X-Received: by 10.31.167.133 with SMTP id q127mr8498057vke.101.1471021767144; Fri, 12 Aug 2016 10:09:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.7.33 with HTTP; Fri, 12 Aug 2016 10:09:11 -0700 (PDT) In-Reply-To: <4D6E4D70-210B-439F-AC9E-F09B79C5A3A1@FreeBSD.org> References: <4D6E4D70-210B-439F-AC9E-F09B79C5A3A1@FreeBSD.org> From: "Lundberg, Johannes" Date: Fri, 12 Aug 2016 10:09:11 -0700 Message-ID: Subject: Re: Wayland work status To: David Chisnall Cc: FreeBSD Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 12 Aug 2016 17:09:28 -0000 PiBUaGVyZSBpcyBhIHNpbWlsYXIgcHJvYmxlbSBmb3IgdGhlIGRybSBkZXZpY2VzIChieSBkZWZh dWx0LCB1c2VycyBjYW7igJl0DQo+IHVzZSAzRCBhY2NlbGVyYXRpb24pLiAgQSBkZXZmcy5jb25m IHBvbGljeSBjYW4gY2hhbmdlIHRoZSBwZXJtaXNzaW9ucy4gIEnigJlkDQo+IHN1Z2dlc3QgdGhh dCB3ZSBjcmVhdGUgYSBkZWZhdWx0IGdyb3VwIGNhbGxlZCBzb21ldGhpbmcgbGlrZSBjb25zb2xl IG9yDQo+IGxvY2FsLCBwdXQgbmV3IHVzZXJzIHRoZXJlIGJ5IGRlZmF1bHQsIGFuZCBtYWtlIGRy bSBhbmQgZXZkZXYgZGV2aWNlcw0KPiBhY2Nlc3NpYmxlIGJ5IHRoaXMgZ3JvdXAuDQo+DQo+IERh dmlkDQo+DQo+DQoNCuKAi0FjdHVhbGx5IGluIExpbnV4IHdsYyBhbmQgSSB0aGluayBhbHNvIFdl c3RvbiByZWNvbW1lbmQgdXNpbmcgc2V0dWlkIGZvcg0KdGhlIGNvbXBvc2l0b3IuIEl0IHRoZW4g Zm9ya3MgYW5kIGRyb3BzIHBlcm1pc3Npb24uIEFsbCBkZXZpY2VzIGFyZSBvcGVuZWQNCmFzIHN1 cGVydXNlciBhbmQgdGhlbiBzZW50IHRvIHRoZSBjaGlsZCBwcm9jZXNzLiBUaGlzIHdvcmtzIGZp bmUgZm9yIG1lDQp3aXRoIHR0eSBhbmQgZHJtLCBob3dldmVyLCBsaWJpbnB1dCBjb21wbGFpbnMg YWJvdXQgZGV2aWNlcyBub3QgYmVpbmcNCnRhZ2dlZCBhcyBpbnB1dCBkZXZpY2UgYnV0IHRoZXkg YXJlIG9wZW5lZCBzdWNjZXNzZnVsbHkuIEkgaGF2ZW4ndCBsb29rZWQNCmRlZXBlciBpbnRvIHdo eS4uLg0KDQpBcyBmb3IgWDExLCBtYXliZSB0aGlzIGFwcHJvYWNoIGRvZXMgbm90IHdvcmsgYW5k IHdlIG5lZWQgZ3JvdXAgcGVybWlzc2lvbnMuDQoKLS0gCj0tPS09LT0tPS09LT0tPS09LT0tPS09 LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LQrnp5jlr4bkv53mjIHjgavjgaTjgYTjgabv vJrjgZPjga7pm7vlrZDjg6Hjg7zjg6vjga/jgIHlkI3lrpvkurrjgavpgIHkv6HjgZfjgZ/jgoLj ga7jgafjgYLjgorjgIHnp5jljL/nibnmqKnjga7lr77osaHjgajjgarjgovmg4XloLHjgpLlkKvj gpPjgafjgYTjgb7jgZnjgIIK44KC44GX44CB5ZCN5a6b5Lq65Lul5aSW44Gu5pa544GM5Y+X5L+h 44GV44KM44Gf5aC05ZCI44CB44GT44Gu44Oh44O844Or44Gu56C05qOE44CB44GK44KI44Gz44GT 44Gu44Oh44O844Or44Gr6Zai44GZ44KL5LiA5YiH44Gu6ZaL56S644CBCuikh+WGmeOAgemFjeW4 g+OAgeOBneOBruS7luOBruWIqeeUqOOAgeOBvuOBn+OBr+iomOi8ieWGheWuueOBq+WfuuOBpeOB j+OBhOOBi+OBquOCi+ihjOWLleOCguOBleOCjOOBquOBhOOCiOOBhuOBiumhmOOBhOeUs+OBl+S4 iuOBkuOBvuOBmeOAggotLS0KQ09ORklERU5USUFMSVRZIE5PVEU6IFRoZSBpbmZvcm1hdGlvbiBp biB0aGlzIGVtYWlsIGlzIGNvbmZpZGVudGlhbAphbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUg YWRkcmVzc2VlLgpEaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgYW55IG90aGVy IGFjdGlvbiBvZiB1c2Ugb2YgdGhpcwplbWFpbCBieSBwZXJzb24gb3RoZXIgdGhhbiBpbnRlbmRl ZCByZWNpcGllbnQsIGlzIHByb2hpYml0ZWQuCklmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQgYW5kIGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbgplcnJvciwgcGxlYXNlIGRl c3Ryb3kgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuCg== From owner-freebsd-current@freebsd.org Fri Aug 12 17:22:44 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 52153BB825C for ; Fri, 12 Aug 2016 17:22:44 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 095FC1BE6 for ; Fri, 12 Aug 2016 17:22:44 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: by mail-ua0-x22a.google.com with SMTP id n59so52056376uan.2 for ; Fri, 12 Aug 2016 10:22:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brilliantservice-co-jp.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oVuLZYv/7xmEcOev6appwc8SrAJQSRGmXuRIMFEITtw=; b=IEc9P6nZKD2s0kLBv+xD4fXeS+EAW6evTwGHxTx1LslVKzYpXFhPZtXKxb6zaXttII 0JwnuLvOn6tIWct97hpUQS92zo6YZjS392iCX+yZObsyc46tLEfiR0SC+i5DlZpL2ChZ VZ489snD7qU7WYE7mU5Vf4O2QNE5dhTFtwa0Uv0gzq+1ZnuZdCXl6Yb9yzSFyXjWl81N N7T9UxwljWtr8M/BmHv5nd+4jqNAJyztdtSLMuVo4TgxgaPzHjHNTO2TpaSu5tIKhCQR pUxE8b86q5ZCTMSA5/X8bRUBfvIz5vAeTfqL5uNBHH20uhpMdn3Igqe6CcDTYcFoUmqV l/zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oVuLZYv/7xmEcOev6appwc8SrAJQSRGmXuRIMFEITtw=; b=eQHfvopmIGZeDcl9bA8LaA3KrN2o3i7cnjubE+5KnrHsYefLGu1UCW/qBcL2Nog+CF eiDWBB5ZnkREjTeEelw1Iu5jLwqIoeoi8UoDu0VCZWD3VVDGasDmrknURr59ljTG9bix 80FcW6HTqjAQ0t3VVCDxpJLFvOCkQVIUi1+ZIi1rh5SdHgiFJjHFOJs2ilQq3xJIBi13 P9a546M6vOczaqbifu67fE4kUjJj6IQJmbs2eTqa5pa6+2uLIyMWh+FV8MA55FS8xxE5 /YyzbzYWjLbK+Xktx6tmDhTy3HmUOtUmBDGcxnR95peXXjBZAuG0fzzRwHfSoQhPrq7S x/LQ== X-Gm-Message-State: AEkoouum/o9lc+J9X9kSKsNtLi9n+MMEJ0c+03FnrvuW1Upsvd+U7r0iHZzV22K5niPMjUNWk5wULV1bmj2MCv1qXZI2frlfpyzqx2hPvvTJLfiBeabmeqFJfAnasmKm2JBpls2wz4GgeEEjzRuvL8r6kao= X-Received: by 10.176.81.2 with SMTP id e2mr8115267uaa.122.1471022563116; Fri, 12 Aug 2016 10:22:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.7.33 with HTTP; Fri, 12 Aug 2016 10:22:27 -0700 (PDT) In-Reply-To: <1df3c73a-dab3-d688-c56a-ed7c4361a9bf@gmail.com> References: <1df3c73a-dab3-d688-c56a-ed7c4361a9bf@gmail.com> From: "Lundberg, Johannes" Date: Fri, 12 Aug 2016 10:22:27 -0700 Message-ID: Subject: Re: Wayland work status To: =?UTF-8?Q?Jan_Kokem=C3=BCller?= Cc: FreeBSD Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 12 Aug 2016 17:22:44 -0000 Pg0KPiBJZiB5b3UgZmVlbCBhZHZlbnR1cm91cywgeW91IGNhbiB0cnkgb3V0IHRoZSBjdXJyZW50 IHN0YXRlIG9mIHRoZSBsaWJpbnB1dA0KPiBwb3J0IGhlcmUgKDEuNC4wKToNCj4gaHR0cHM6Ly9n aXRodWIuY29tL2ppaXh5ai9saWJpbnB1dA0KPg0KPg0K4oCLR3JlYXQhIFdpbGwgY2hlY2sgaXQg b3V0Lg0K4oCLDQoNCg0KPiBJIGhhdmVuJ3QgeWV0IHRlc3RlZCB0aGUgcG9ydCB3aXRoIHRoZSBl dmRldiBrZXJuZWwgd29yaywgdGhvdWdoLiBJJ3ZlDQo+IGJlZW4gdXNpbmcgbXkgZXZkZXYgaW1w bGVtZW50YXRpb24gaW4gdXNlcnNwYWNlIHdoaWNoIHVzZXMgY3VzZSB0byBjcmVhdGUNCj4gL2Rl di9pbnB1dC9ldmVudCogZGV2aWNlcyAoaHR0cHM6Ly9naXRodWIuY29tL2ppaXh5ai9ldmRldmZi c2QpLiBJIG5lZWRlZA0KPiB0byBhZGp1c3QgYSBmZXcgaW9jdGwgZGVmaW5lcyBmcm9tIHRoZSBs aW51eC9pbnB1dC5oIGhlYWRlciB0byBtYWtlIHNvbWUNCj4gZmVhdHVyZXMgd29yay4gVGhlIHdh eSBMaW51eCBkZWZpbmVzIEVWSU9DR01UU0xPVFMgYW5kIEVWSU9DR1JBQiBkaWRuJ3QNCj4gd29y ayB3aXRoIGN1c2UuIFRoZSBrZXJuZWwgZXZkZXYgaW1wbGVtZW50YXRpb24gbWF5IHdvcmsgc2xp Z2h0bHkNCj4gZGlmZmVyZW50bHksIHNvIHRoYXQncyBzb21ldGhpbmcgdG8gbG9vayBvdXQgZm9y Lg0KPg0KPg0K4oCLS2VybmVsIGV2ZGV2IGltcGxlbWVudGF0aW9uIHNlZW1zIHRvIHdvcmsgZ3Jl YXQuIEl0IGlzIGZhaXJseSBlYXN5IHRvIGFkZA0KZXZkZXYgZnVuY3Rpb25hbGl0eSB0byBleGlz dGluZyBkcml2ZXJzLiBJIGp1c3QgcGF0Y2hlZCB0aGUgd3NwIChmb3INCk1hY2Jvb2sncyB0b3Vj aHBhZCkgZHJpdmVyIHRvIGFkZCBpdCB0byBldmRldi4gSSBtb2RpZmllZCBpdCBhIGJpdCB0byBh ZGQNCnR3byBmaW5nZXIgeC15IHNjcm9sbCBsaWtlIG9uIG1hY09TLiBJIGNhbid0IHdhaXQgdG8g dHJ5IGl0IG9uIFggc28gSSdtDQpnb25uYSB0cnkgZ2V0IGxpYmlucHV0IHdvcmtpbmcgd2l0aCBY IHRvZGF5Lg0K4oCLDQoNCg0KPiBJJ3ZlIG1vdmVkIHRoZSB1ZGV2LXN0dWJzLntjLGh9IG91dCBv ZiB0aGUgcG9ydCBpbnRvIGEgc2VwYXJhdGUgbGlicmFyeSwNCj4gYnV0IGxpYnVkZXYtZGV2ZCAo aHR0cHM6Ly9naXRodWIuY29tL3d1bGY3L2xpYnVkZXYtZGV2ZCkgY2VydGFpbmx5IGxvb2tzDQo+ IG1vcmUgbWF0dXJlIQ0KPg0KPg0K4oCLSSBjb3VsZG4ndCBnZXQgaXQgd29ya2luZyB3aXRoIHlv dXIgdWRldi1zdHVicyBhbmQgSSBmb3VuZCBsaWJ1ZGV2LWRldmQNCndoaWNoIHNlZW1lZCB0byBi ZSBtb3JlIG1hdHVyZS4gSXQgd29ya3MgZ3JlYXQgc28gZmFyIeKAiw0KDQoNCj4gQWxsIHRoaXMg Y2FuIGJlIHVzZWQgd2l0aCB0aGUgeGY4Ni1pbnB1dC1saWJpbnB1dCBkcml2ZXIgdG8gZ2V0IHNt b290aCBhbmQNCj4gaG9yaXpvbnRhbCBzY3JvbGxpbmcgaW4gWCwgd2hpY2ggaXMgYXdlc29tZSEN Cj4NCg0K4oCLV2hlcmUgY2FuIEkgZmluZCB4Zjg2LWlucHV0LWxpYmlucHV0IGZvciBGcmVlQlNE PyBXaWxsIHRoZSBvcmlnaW5hbCBzb3VyY2UNCmJ1aWxkPw0KCi0tIAo9LT0tPS09LT0tPS09LT0t PS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS0K56eY5a+G5L+d5oyB44Gr44Gk 44GE44Gm77ya44GT44Gu6Zu75a2Q44Oh44O844Or44Gv44CB5ZCN5a6b5Lq644Gr6YCB5L+h44GX 44Gf44KC44Gu44Gn44GC44KK44CB56eY5Yy/54m55qip44Gu5a++6LGh44Go44Gq44KL5oOF5aCx 44KS5ZCr44KT44Gn44GE44G+44GZ44CCCuOCguOBl+OAgeWQjeWum+S6uuS7peWkluOBruaWueOB jOWPl+S/oeOBleOCjOOBn+WgtOWQiOOAgeOBk+OBruODoeODvOODq+OBruegtOajhOOAgeOBiuOC iOOBs+OBk+OBruODoeODvOODq+OBq+mWouOBmeOCi+S4gOWIh+OBrumWi+ekuuOAgQropIflhpnj gIHphY3luIPjgIHjgZ3jga7ku5bjga7liKnnlKjjgIHjgb7jgZ/jga/oqJjovInlhoXlrrnjgavl n7rjgaXjgY/jgYTjgYvjgarjgovooYzli5XjgoLjgZXjgozjgarjgYTjgojjgYbjgYrpoZjjgYTn lLPjgZfkuIrjgZLjgb7jgZnjgIIKLS0tCkNPTkZJREVOVElBTElUWSBOT1RFOiBUaGUgaW5mb3Jt YXRpb24gaW4gdGhpcyBlbWFpbCBpcyBjb25maWRlbnRpYWwKYW5kIGludGVuZGVkIHNvbGVseSBm b3IgdGhlIGFkZHJlc3NlZS4KRGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIGFu eSBvdGhlciBhY3Rpb24gb2YgdXNlIG9mIHRoaXMKZW1haWwgYnkgcGVyc29uIG90aGVyIHRoYW4g aW50ZW5kZWQgcmVjaXBpZW50LCBpcyBwcm9oaWJpdGVkLgpJZiB5b3UgYXJlIG5vdCB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50IGFuZCBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4KZXJyb3IsIHBs ZWFzZSBkZXN0cm95IHRoZSBvcmlnaW5hbCBtZXNzYWdlLgo= From owner-freebsd-current@freebsd.org Fri Aug 12 20:12:39 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E928BB7488 for ; Fri, 12 Aug 2016 20:12:39 +0000 (UTC) (envelope-from jan.kokemueller@gmail.com) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 1068F13B7 for ; Fri, 12 Aug 2016 20:12:39 +0000 (UTC) (envelope-from jan.kokemueller@gmail.com) Received: by mail-wm0-x22b.google.com with SMTP id i5so55715868wmg.0 for ; Fri, 12 Aug 2016 13:12:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=W88EJLgIuxjN5MXCZA0RqqbqbiAfiojeE/F08C458as=; b=qoxp8KpCeE4i0atUlX8XAmeUZ35dgQf7j64GDQlydjJR7/qIJjSeCs5s43EIKAo5Sy WjPlFBa3oRTlmIQ91iHpVgvX6odYdJ82XJLz4OFjiZxD2MuUqpufzg4aWIvuB9vzA0cz E+xmjpHgUGw8ifrbQkhP9JGkg5Y2Ou0zaKqsiJKvp+t+RQcvMlRDIWpGlCsbhqUb+5RD BuYn7fJDqMgPddBuMGUELKY6TlEb4ytt+x1tvBh33uF/e4jDjRpGsHEZdTz+m19lXctO 5H2rR0n4bgz8tA51Er7QGXAAflXQLNqWs+z5GzuHMvK+L9meyqJdtlY7gEIhiVtP6LNq iJUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=W88EJLgIuxjN5MXCZA0RqqbqbiAfiojeE/F08C458as=; b=Q/14YqsZg04MEvxXZcJ5repCGMY/y65awpN9C3XGx3e8La9EcFALLwgs8Y4DPmx4ML rzGBgd4CWDmtZDbawQoVm16kE7ar4R/jUsKXJeVaVn8pPE750LYZS9oyDjtjAknIfsII NTNUvGQZQIK/4nrVvanSahQ+eACfIsC7fdVFjaxjDfMRpBwsXDAG+UttSV+CRHa1qW0I mAiBBYELgxm0EBBmgWyEQMW7bh6LIbwgTCjdIw+qYlBUoqV9Nept5F9lwp55b1IafgUx hfJIJUDHECt9k8BXX9ktjs0Y/FJb5Y56YMJXxrwoOAquxrDQVXzCaB501wd3vvv60KDd eiTw== X-Gm-Message-State: AEkoousmIerBvOgIiFz9SoSSxk/pa07qNV1cXgkZ0MV77BJNzTzL15jwrzS+PWil1tS4BQ== X-Received: by 10.194.81.137 with SMTP id a9mr17471782wjy.106.1471032757401; Fri, 12 Aug 2016 13:12:37 -0700 (PDT) Received: from ?IPv6:2001:470:1f15:b1f:e9b6:76a9:2217:e40f? ([2001:470:1f15:b1f:e9b6:76a9:2217:e40f]) by smtp.googlemail.com with ESMTPSA id b186sm3964267wmg.23.2016.08.12.13.12.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Aug 2016 13:12:36 -0700 (PDT) Subject: Re: Wayland work status To: "Lundberg, Johannes" References: <1df3c73a-dab3-d688-c56a-ed7c4361a9bf@gmail.com> Cc: FreeBSD Current From: =?UTF-8?Q?Jan_Kokem=c3=bcller?= Message-ID: Date: Fri, 12 Aug 2016 22:12:35 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 12 Aug 2016 20:12:39 -0000 Hi, On 12.08.16 19:22, Lundberg, Johannes wrote: > ​Where can I find xf86-input-libinput for FreeBSD? Will the original > source build? Yes, the original source (https://cgit.freedesktop.org/xorg/driver/xf86-input-libinput/) will build unmodified. I've copied libinput_drv.so to /usr/local/lib/xorg/modules/input/libinput_drv.so and installed "99-libinput.conf" into /usr/local/etc/X11/xorg.conf.d so that X will use libinput for the /dev/input/event* devices by default and not xf86-input-evdev or -synaptics. Libinput has pretty advanced multitouch scrolling and gesture support that relies on evdev multitouch packets (https://www.kernel.org/doc/Documentation/input/multi-touch-protocol.txt). Are you already sending these packets, or are you sending relative (EV_REL) packets? Looking at the wmt driver in the wulf7/evdev branch sending EV_ABS packets does not seem too hard for USB based touchpads. It is probably easiest to boot Linux, dump all evdev packets from the touchpad with the libevdev-events tool from libevdev, and then try to emulate that output with the wsp driver. For testing smooth scrolling, gtk3-demo is pretty good; or recent versions of Firefox with the MOZ_USE_XINPUT2 environment variable set to 1. -Jan From owner-freebsd-current@freebsd.org Fri Aug 12 20:48:17 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3F7C2BB7FC4 for ; Fri, 12 Aug 2016 20:48:17 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EC2BA1939 for ; Fri, 12 Aug 2016 20:48:16 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: by mail-ua0-x22a.google.com with SMTP id n59so60100324uan.2 for ; Fri, 12 Aug 2016 13:48:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brilliantservice-co-jp.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xGbpvR5d8q/HoWITbbQHdkKvgGCkv+njltTTkq5PeUo=; b=IRqFzNZ8JC9WPfudrRbdwYzmc9ikxYT3F3cH17mqTYUeZWenVnsB5yFAucK8EK8FAW pzfUy5qsWyMKLexP7dGXOcDn5Hnt4U653uqlNeb54n8U033AE1eReI9gDYItUaGQVNUT HHZxb1JNBsdhMVy4QOhgmsE2RGpwB0ZOljuWToN16k3GOXWnfOQGOAwYAEbXMMkgbTyu /7ZO5UbAEw+2xRNOS4uOlC47tvZRoSgkumqHMZJYcBLge6u0hZgh8DoHlCuEUc1Tzk3d 9+txMW3v1UaKKNnuStjNaoM3fsxTUHZ72wlNMFId9qEa09+fgnR5R3SnKIRn68nXDjgx CXbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xGbpvR5d8q/HoWITbbQHdkKvgGCkv+njltTTkq5PeUo=; b=g0jcFWmFA0JsgdLeMWkqZFjUwfqmJYhu4sH97TuyWTRCEHOsbAfhXbrTCD08IGhC+Y ZIyHvMpkmcC2tLx41be/3SA/Pw+xCjeOlO7KGpU16vuOEOffdGjFLDjsl7dSLt9Pw5pQ trGY1s4UVrh4A0NI9NcUvXTiXf4nT8Vf7y41LfmwCfGYLS+bIhbCT9AeXGUqkWfAHTYW tS/u1M6xu2rCAVJMfh3IjudUw1G3MqweqnFVe1ISBDFgKquefNXUMdft8OvdRkNwSGBo AXCBanoSevkmYzdIg+4/+LDaaKtWiYjYd+wIXypITOpTDryh7NO7nwIKnc+bCEWWs7M4 2GFQ== X-Gm-Message-State: AEkoouvwtQpxC42J1IZpncRMN7kCsxcg6DagXDYzaBFCew1tX9jrINxn0U0w7tPcDPE0VJnIEjHhBTa35AbreEBa+i71DDc8aBzXcan+wnmy4cSf0i35vsRdKMHFYJY+Hcxk6njG8+bAFG1TqLUvBXkpw+8= X-Received: by 10.176.81.2 with SMTP id e2mr8565139uaa.122.1471034895744; Fri, 12 Aug 2016 13:48:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.7.33 with HTTP; Fri, 12 Aug 2016 13:48:00 -0700 (PDT) In-Reply-To: References: <1df3c73a-dab3-d688-c56a-ed7c4361a9bf@gmail.com> From: "Lundberg, Johannes" Date: Fri, 12 Aug 2016 13:48:00 -0700 Message-ID: Subject: Re: Wayland work status To: =?UTF-8?Q?Jan_Kokem=C3=BCller?= Cc: FreeBSD Current Content-Type: multipart/mixed; boundary=94eb2c18f43c69faca0539e600da X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 12 Aug 2016 20:48:17 -0000 --94eb2c18f43c69faca0539e600da Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi I followed the instructions for evdev enabled kernel here https://github.com/wulf7/libudev-devd and it works fine! I needed to update libinput to latest version since it was required by xf86-input-libinput so I'm using latest version from https://github.com/jiixyj/libinput. As for the wsp driver I've simply added REL_HWHEEL to get x/y scrolling and changed the back/forward events to x axis scrolling. See the attached patch. It's still really simple but adds a bit more functionality compared to what is allowed by the old mouse protocol. Of course, if you want advanced multi-touch gestures, it's need to be rewritten a lot. Although, I don't know how many X apps actually support this so maybe it's a lot of work for nothing... I also needed to change the order of horizontal scroll wheel and buttons with xinput set-button-map 6 3 2 1 4 5 7 6 =E2=80=8B =E2=80=8BI think wsp already puts out vertical scroll in opposite direction= by default. =E2=80=8B =E2=80=8BI'm using xfce4 as desktop environment.=E2=80=8B On Fri, Aug 12, 2016 at 1:12 PM, Jan Kokem=C3=BCller wrote: > Hi, > > On 12.08.16 19:22, Lundberg, Johannes wrote: > >> =E2=80=8BWhere can I find xf86-input-libinput for FreeBSD? Will the orig= inal >> source build? >> > > Yes, the original source (https://cgit.freedesktop.org/ > xorg/driver/xf86-input-libinput/) will build unmodified. > > I've copied libinput_drv.so to /usr/local/lib/xorg/modules/input/libinput= _drv.so > and installed "99-libinput.conf" into /usr/local/etc/X11/xorg.conf.d so > that X will use libinput for the /dev/input/event* devices by default and > not xf86-input-evdev or -synaptics. > > Libinput has pretty advanced multitouch scrolling and gesture support tha= t > relies on evdev multitouch packets (https://www.kernel.org/doc/Do > cumentation/input/multi-touch-protocol.txt). Are you already sending > these packets, or are you sending relative (EV_REL) packets? Looking at t= he > wmt driver in the wulf7/evdev branch sending EV_ABS packets does not seem > too hard for USB based touchpads. > > It is probably easiest to boot Linux, dump all evdev packets from the > touchpad with the libevdev-events tool from libevdev, and then try to > emulate that output with the wsp driver. > > For testing smooth scrolling, gtk3-demo is pretty good; or recent version= s > of Firefox with the MOZ_USE_XINPUT2 environment variable set to 1. > > -Jan > --=20 =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- =E7=A7=98=E5=AF=86=E4=BF=9D=E6=8C=81=E3=81=AB=E3=81=A4=E3=81=84=E3=81=A6=EF= =BC=9A=E3=81=93=E3=81=AE=E9=9B=BB=E5=AD=90=E3=83=A1=E3=83=BC=E3=83=AB=E3=81= =AF=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E3=81=AB=E9=80=81=E4=BF=A1=E3=81=97= =E3=81=9F=E3=82=82=E3=81=AE=E3=81=A7=E3=81=82=E3=82=8A=E3=80=81=E7=A7=98=E5= =8C=BF=E7=89=B9=E6=A8=A9=E3=81=AE=E5=AF=BE=E8=B1=A1=E3=81=A8=E3=81=AA=E3=82= =8B=E6=83=85=E5=A0=B1=E3=82=92=E5=90=AB=E3=82=93=E3=81=A7=E3=81=84=E3=81=BE= =E3=81=99=E3=80=82 =E3=82=82=E3=81=97=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E4=BB=A5=E5=A4=96=E3= =81=AE=E6=96=B9=E3=81=8C=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E5=A0= =B4=E5=90=88=E3=80=81=E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AE= =E7=A0=B4=E6=A3=84=E3=80=81=E3=81=8A=E3=82=88=E3=81=B3=E3=81=93=E3=81=AE=E3= =83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E9=96=A2=E3=81=99=E3=82=8B=E4=B8=80=E5=88= =87=E3=81=AE=E9=96=8B=E7=A4=BA=E3=80=81 =E8=A4=87=E5=86=99=E3=80=81=E9=85=8D=E5=B8=83=E3=80=81=E3=81=9D=E3=81=AE=E4= =BB=96=E3=81=AE=E5=88=A9=E7=94=A8=E3=80=81=E3=81=BE=E3=81=9F=E3=81=AF=E8=A8= =98=E8=BC=89=E5=86=85=E5=AE=B9=E3=81=AB=E5=9F=BA=E3=81=A5=E3=81=8F=E3=81=84= =E3=81=8B=E3=81=AA=E3=82=8B=E8=A1=8C=E5=8B=95=E3=82=82=E3=81=95=E3=82=8C=E3= =81=AA=E3=81=84=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81= =97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82 --- CONFIDENTIALITY NOTE: The information in this email is confidential and intended solely for the addressee. Disclosure, copying, distribution or any other action of use of this email by person other than intended recipient, is prohibited. If you are not the intended recipient and have received this email in error, please destroy the original message. --94eb2c18f43c69faca0539e600da Content-Type: text/plain; charset=US-ASCII; name="wsp.c.diff" Content-Disposition: attachment; filename="wsp.c.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_irs7ty5f0 ZGlmZiAtLWdpdCBhL3N5cy9kZXYvdXNiL2lucHV0L3dzcC5jIGIvc3lzL2Rldi91c2IvaW5wdXQv d3NwLmMKaW5kZXggNjk0ZTBkOS4uMjFjYzUxOCAxMDA2NDQKLS0tIGEvc3lzL2Rldi91c2IvaW5w dXQvd3NwLmMKKysrIGIvc3lzL2Rldi91c2IvaW5wdXQvd3NwLmMKQEAgLTI3LDYgKzI3LDggQEAK ICNpbmNsdWRlIDxzeXMvY2RlZnMuaD4KIF9fRkJTRElEKCIkRnJlZUJTRCQiKTsKIAorI2luY2x1 ZGUgIm9wdF9ldmRldi5oIgorCiAjaW5jbHVkZSA8c3lzL3BhcmFtLmg+CiAjaW5jbHVkZSA8c3lz L3N5c3RtLmg+CiAjaW5jbHVkZSA8c3lzL2tlcm5lbC5oPgpAQCAtNTQsNiArNTYsMTEgQEAgX19G QlNESUQoIiRGcmVlQlNEJCIpOwogCiAjaW5jbHVkZSA8c3lzL21vdXNlLmg+CiAKKyNpZmRlZiBF VkRFVgorI2luY2x1ZGUgPGRldi9ldmRldi9pbnB1dC5oPgorI2luY2x1ZGUgPGRldi9ldmRldi9l dmRldi5oPgorI2VuZGlmCisKICNkZWZpbmUJV1NQX0RSSVZFUl9OQU1FICJ3c3AiCiAjZGVmaW5l CVdTUF9CVUZGRVJfTUFYCTEwMjQKIApAQCAtODMsNiArOTAsNyBAQCBTWVNDVExfSU5UKF9od191 c2Jfd3NwLCBPSURfQVVUTywgZGVidWcsIENUTEZMQUdfUldUVU4sCiBzdGF0aWMgc3RydWN0IHdz cF90dW5pbmcgewogCWludAlzY2FsZV9mYWN0b3I7CiAJaW50CXpfZmFjdG9yOworCWludAl0X2Zh Y3RvcjsKIAlpbnQJcHJlc3N1cmVfdG91Y2hfdGhyZXNob2xkOwogCWludAlwcmVzc3VyZV91bnRv dWNoX3RocmVzaG9sZDsKIAlpbnQJcHJlc3N1cmVfdGFwX3RocmVzaG9sZDsKQEAgLTkyLDYgKzEw MCw3IEBAIHN0YXRpYyBzdHJ1Y3Qgd3NwX3R1bmluZyB7CiB7CiAJLnNjYWxlX2ZhY3RvciA9IDEy LAogCS56X2ZhY3RvciA9IDUsCisJLnRfZmFjdG9yID0gNSwKIAkucHJlc3N1cmVfdG91Y2hfdGhy ZXNob2xkID0gNTAsCiAJLnByZXNzdXJlX3VudG91Y2hfdGhyZXNob2xkID0gMTAsCiAJLnByZXNz dXJlX3RhcF90aHJlc2hvbGQgPSAxMjAsCkBAIC0xMTMsNiArMTIyLDggQEAgU1lTQ1RMX0lOVChf aHdfdXNiX3dzcCwgT0lEX0FVVE8sIHNjYWxlX2ZhY3RvciwgQ1RMRkxBR19SV1RVTiwKICAgICAm d3NwX3R1bmluZy5zY2FsZV9mYWN0b3IsIDAsICJtb3ZlbWVudCBzY2FsZSBmYWN0b3IiKTsKIFNZ U0NUTF9JTlQoX2h3X3VzYl93c3AsIE9JRF9BVVRPLCB6X2ZhY3RvciwgQ1RMRkxBR19SV1RVTiwK ICAgICAmd3NwX3R1bmluZy56X2ZhY3RvciwgMCwgIlotYXhpcyBzY2FsZSBmYWN0b3IiKTsKK1NZ U0NUTF9JTlQoX2h3X3VzYl93c3AsIE9JRF9BVVRPLCB0X2ZhY3RvciwgQ1RMRkxBR19SV1RVTiwK KyAgICAmd3NwX3R1bmluZy50X2ZhY3RvciwgMCwgIlQtYXhpcyBzY2FsZSBmYWN0b3IiKTsKIFNZ U0NUTF9JTlQoX2h3X3VzYl93c3AsIE9JRF9BVVRPLCBwcmVzc3VyZV90b3VjaF90aHJlc2hvbGQs IENUTEZMQUdfUldUVU4sCiAgICAgJndzcF90dW5pbmcucHJlc3N1cmVfdG91Y2hfdGhyZXNob2xk LCAwLCAidG91Y2ggcHJlc3N1cmUgdGhyZXNob2xkIik7CiBTWVNDVExfSU5UKF9od191c2Jfd3Nw LCBPSURfQVVUTywgcHJlc3N1cmVfdW50b3VjaF90aHJlc2hvbGQsIENUTEZMQUdfUldUVU4sCkBA IC01NDEsNyArNTUyLDEyIEBAIHN0cnVjdCB3c3Bfc29mdGMgewogCXVfaW50CXNjX3BvbGxyYXRl OwogCW1vdXNlc3RhdHVzX3Qgc2Nfc3RhdHVzOwogCXVfaW50CXNjX3N0YXRlOworCXVfaW50CXNj X2ZmbGFnczsKICNkZWZpbmUJV1NQX0VOQUJMRUQJICAgICAgIDB4MDEKKyNpZmRlZiBFVkRFVgor CWludCBzY19ldmZsYWdzOworI2RlZmluZQlXU1BfRVZERVZfT1BFTkVECTEKKyNlbmRpZgogCiAJ c3RydWN0IHRwX2ZpbmdlciAqaW5kZXhbTUFYX0ZJTkdFUlNdOwkvKiBmaW5nZXIgaW5kZXggZGF0 YSAqLwogCWludDE2X3QJcG9zX3hbTUFYX0ZJTkdFUlNdOwkvKiBwb3NpdGlvbiBhcnJheSAqLwpA QCAtNTU5LDkgKzU3NSwxMiBAQCBzdHJ1Y3Qgd3NwX3NvZnRjIHsKIAlpbnQJZHpfY291bnQ7CiAj ZGVmaW5lCVdTUF9EWl9NQVhfQ09VTlQJMzIKIAlpbnQJZHRfc3VtOwkJCS8qIFQtYXhpcyBjdW11 bGF0aXZlIG1vdmVtZW50ICovCisJaW50CWR0X2NvdW50OworI2RlZmluZQlXU1BfRFRfTUFYX0NP VU5UCTMyCiAJaW50CXJkeDsJCQkvKiB4IGF4aXMgcmVtYWluZGVyIG9mIGRpdmlkZSBieSBzY2Fs ZV9mYWN0b3IgKi8KIAlpbnQJcmR5OwkJCS8qIHkgYXhpcyByZW1haW5kZXIgb2YgZGl2aWRlIGJ5 IHNjYWxlX2ZhY3RvciAqLwogCWludAlyZHo7CQkJLyogeiBheGlzIHJlbWFpbmRlciBvZiBkaXZp ZGUgYnkgc2NhbGVfZmFjdG9yICovCisJaW50CXJkdDsJCQkvKiB0IGF4aXMgcmVtYWluZGVyIG9m IGRpdmlkZSBieSBzY2FsZV9mYWN0b3IgKi8KIAlpbnQJdHBfZGF0YWxlbjsKIAl1aW50OF90IG9f bnRvdWNoOwkJLyogb2xkIHRvdWNoIGZpbmdlciBzdGF0dXMgKi8KIAl1aW50OF90CWZpbmdlcjsJ CQkvKiAwIG9yIDEgKiwgY2hlY2sgd2hpY2ggZmluZ2VyIG1vdmluZyAqLwpAQCAtNTcyLDExICs1 OTEsMTUgQEAgc3RydWN0IHdzcF9zb2Z0YyB7CiAjZGVmaW5lCU1BWF9ESVNUQU5DRQkJMjUwMAkv KiB0aGUgbWF4IGFsbG93ZWQgZGlzdGFuY2UgKi8KIAl1aW50OF90CWlidG47CQkJLyogYnV0dG9u IHN0YXR1cyBpbiB0YXBwaW5nICovCiAJdWludDhfdAludGFwczsJCQkvKiBmaW5nZXIgc3RhdHVz IGluIHRhcHBpbmcgKi8KLQl1aW50OF90CXNjcl9tb2RlOwkJLyogc2Nyb2xsIHN0YXR1cyBpbiBt b3ZlbWVudCAqLwotI2RlZmluZQlXU1BfU0NSX05PTkUJCTAKLSNkZWZpbmUJV1NQX1NDUl9WRVIJ CTEKLSNkZWZpbmUJV1NQX1NDUl9IT1IJCTIKKwl1aW50OF90CXNjcm9sbF9tb2RlOwkJLyogc2Ny b2xsIHN0YXR1cyBpbiBtb3ZlbWVudCAqLworI2RlZmluZQlXU1BfU0NST0xMX05PTkUJCTAKKyNk ZWZpbmUJV1NQX1NDUk9MTF9WRVIJCTEKKyNkZWZpbmUJV1NQX1NDUk9MTF9IT1IJCTIKIAl1aW50 OF90IHRwX2RhdGFbV1NQX0JVRkZFUl9NQVhdIF9fYWxpZ25lZCg0KTsJCS8qIHRyYWNrcGFkIHRy YW5zZmVycmVkIGRhdGEgKi8KKworI2lmZGVmIEVWREVWCisJc3RydWN0IGV2ZGV2X2RldiAqc2Nf ZXZkZXY7CisjZW5kaWYKIH07CiAKIC8qCkBAIC01ODgsNiArNjExLDE0IEBAIHN0YXRpYyB1c2Jf Zmlmb19vcGVuX3Qgd3NwX29wZW47CiBzdGF0aWMgdXNiX2ZpZm9fY2xvc2VfdCB3c3BfY2xvc2U7 CiBzdGF0aWMgdXNiX2ZpZm9faW9jdGxfdCB3c3BfaW9jdGw7CiAKK3N0YXRpYyB2b2lkIHdzcF9z dGFydF9yeChzdHJ1Y3Qgd3NwX3NvZnRjICpzYyk7CitzdGF0aWMgdm9pZCB3c3Bfc3RvcF9yeChz dHJ1Y3Qgd3NwX3NvZnRjICpzYyk7CisKKyNpZmRlZiBFVkRFVgorc3RhdGljIGV2ZGV2X29wZW5f dCB3c3BfZXZfb3BlbjsKK3N0YXRpYyBldmRldl9jbG9zZV90IHdzcF9ldl9jbG9zZTsKKyNlbmRp ZgorCiBzdGF0aWMgc3RydWN0IHVzYl9maWZvX21ldGhvZHMgd3NwX2ZpZm9fbWV0aG9kcyA9IHsK IAkuZl9vcGVuID0gJndzcF9vcGVuLAogCS5mX2Nsb3NlID0gJndzcF9jbG9zZSwKQEAgLTU5Nywx MyArNjI4LDIwIEBAIHN0YXRpYyBzdHJ1Y3QgdXNiX2ZpZm9fbWV0aG9kcyB3c3BfZmlmb19tZXRo b2RzID0gewogCS5iYXNlbmFtZVswXSA9IFdTUF9EUklWRVJfTkFNRSwKIH07CiAKKyNpZmRlZiBF VkRFVgorc3RhdGljIHN0cnVjdCBldmRldl9tZXRob2RzIHdzcF9ldmRldl9tZXRob2RzID0gewor CS5ldl9vcGVuID0gJndzcF9ldl9vcGVuLAorCS5ldl9jbG9zZSA9ICZ3c3BfZXZfY2xvc2UsCit9 OworI2VuZGlmCisKIC8qIGRldmljZSBpbml0aWFsaXphdGlvbiBhbmQgc2h1dGRvd24gKi8KIHN0 YXRpYyBpbnQgd3NwX2VuYWJsZShzdHJ1Y3Qgd3NwX3NvZnRjICpzYyk7CiBzdGF0aWMgdm9pZCB3 c3BfZGlzYWJsZShzdHJ1Y3Qgd3NwX3NvZnRjICpzYyk7CiAKIC8qIHVwZGF0aW5nIGZpZm8gKi8K IHN0YXRpYyB2b2lkIHdzcF9yZXNldF9idWYoc3RydWN0IHdzcF9zb2Z0YyAqc2MpOwotc3RhdGlj IHZvaWQgd3NwX2FkZF90b19xdWV1ZShzdHJ1Y3Qgd3NwX3NvZnRjICosIGludCwgaW50LCBpbnQs IHVpbnQzMl90KTsKK3N0YXRpYyB2b2lkIHdzcF9hZGRfdG9fcXVldWUoc3RydWN0IHdzcF9zb2Z0 YyAqLCBpbnQsIGludCwgaW50LCBpbnQsIHVpbnQzMl90KTsKIAogLyogRGV2aWNlIG1ldGhvZHMu ICovCiBzdGF0aWMgZGV2aWNlX3Byb2JlX3Qgd3NwX3Byb2JlOwpAQCAtNzk5LDcgKzgzNywyOSBA QCB3c3BfYXR0YWNoKGRldmljZV90IGRldikKIAlzYy0+c2NfbW9kZS5zeW5jbWFza1sxXSA9IE1P VVNFX01TQ19TWU5DOwogCiAJc2MtPnNjX3RvdWNoID0gV1NQX1VOVE9VQ0g7Ci0Jc2MtPnNjcl9t b2RlID0gV1NQX1NDUl9OT05FOworCXNjLT5zY3JvbGxfbW9kZSA9IFdTUF9TQ1JPTExfTk9ORTsK KworI2lmZGVmIEVWREVWCisJc2MtPnNjX2V2ZGV2ID0gZXZkZXZfYWxsb2MoKTsKKwlldmRldl9z ZXRfbmFtZShzYy0+c2NfZXZkZXYsIGRldmljZV9nZXRfZGVzYyhkZXYpKTsKKwlldmRldl9zZXRf c2VyaWFsKHNjLT5zY19ldmRldiwgIjAiKTsKKwlldmRldl9zZXRfbWV0aG9kcyhzYy0+c2NfZXZk ZXYsIHNjLCAmd3NwX2V2ZGV2X21ldGhvZHMpOworCWV2ZGV2X3N1cHBvcnRfcHJvcChzYy0+c2Nf ZXZkZXYsIElOUFVUX1BST1BfUE9JTlRFUik7CisJZXZkZXZfc3VwcG9ydF9ldmVudChzYy0+c2Nf ZXZkZXYsIEVWX1NZTik7CisJZXZkZXZfc3VwcG9ydF9ldmVudChzYy0+c2NfZXZkZXYsIEVWX1JF TCk7CisJZXZkZXZfc3VwcG9ydF9ldmVudChzYy0+c2NfZXZkZXYsIEVWX0tFWSk7CisJZXZkZXZf c3VwcG9ydF9yZWwoc2MtPnNjX2V2ZGV2LCBSRUxfWCk7CisJZXZkZXZfc3VwcG9ydF9yZWwoc2Mt PnNjX2V2ZGV2LCBSRUxfWSk7CisJZXZkZXZfc3VwcG9ydF9yZWwoc2MtPnNjX2V2ZGV2LCBSRUxf V0hFRUwpOworCWV2ZGV2X3N1cHBvcnRfcmVsKHNjLT5zY19ldmRldiwgUkVMX0hXSEVFTCk7CisK Kwlmb3IoaW50IGkgPSAwOyBpIDwgc2MtPnNjX2h3LmJ1dHRvbnM7IGkrKykKKwkJZXZkZXZfc3Vw cG9ydF9rZXkoc2MtPnNjX2V2ZGV2LCBCVE5fTU9VU0UgKyBpKTsKKworCWVyciA9IGV2ZGV2X3Jl Z2lzdGVyKGRldiwgc2MtPnNjX2V2ZGV2KTsKKwlpZiAoZXJyKQorCQlnb3RvIGRldGFjaDsKKyNl bmRpZgogCiAJcmV0dXJuICgwKTsKIApAQCAtODIyLDYgKzg4MiwxMSBAQCB3c3BfZGV0YWNoKGRl dmljZV90IGRldikKIAogCXVzYl9maWZvX2RldGFjaCgmc2MtPnNjX2ZpZm8pOwogCisjaWZkZWYg RVZERVYKKwlldmRldl91bnJlZ2lzdGVyKGRldiwgc2MtPnNjX2V2ZGV2KTsKKwlldmRldl9mcmVl KHNjLT5zY19ldmRldik7CisjZW5kaWYKKwogCXVzYmRfdHJhbnNmZXJfdW5zZXR1cChzYy0+c2Nf eGZlciwgV1NQX05fVFJBTlNGRVIpOwogCiAJbXR4X2Rlc3Ryb3koJnNjLT5zY19tdXRleCk7CkBA IC04NDIsMTAgKzkwNywxMiBAQCB3c3BfaW50cl9jYWxsYmFjayhzdHJ1Y3QgdXNiX3hmZXIgKnhm ZXIsIHVzYl9lcnJvcl90IGVycm9yKQogCWludCBpYnQgPSAwOwkJCS8qIGJ1dHRvbiBzdGF0dXMg Ki8KIAlpbnQgZHggPSAwOwogCWludCBkeSA9IDA7Ci0JaW50IGR6ID0gMDsKKwlpbnQgZHogPSAw OwkKKwlpbnQgZHQgPSAwOwogCWludCByZHggPSAwOwogCWludCByZHkgPSAwOwogCWludCByZHog PSAwOworCWludCByZHQgPSAwOwogCWludCBsZW47CiAJaW50IGk7CiAKQEAgLTg1NCw2ICs5MjEs OSBAQCB3c3BfaW50cl9jYWxsYmFjayhzdHJ1Y3QgdXNiX3hmZXIgKnhmZXIsIHVzYl9lcnJvcl90 IGVycm9yKQogCWlmIChzYy0+ZHpfY291bnQgPT0gMCkKIAkJc2MtPmR6X2NvdW50ID0gV1NQX0Ra X01BWF9DT1VOVDsKIAorCWlmIChzYy0+ZHRfY291bnQgPT0gMCkKKwkJc2MtPmR0X2NvdW50ID0g V1NQX0RUX01BWF9DT1VOVDsKKwogCXVzYmRfeGZlcl9zdGF0dXMoeGZlciwgJmxlbiwgTlVMTCwg TlVMTCwgTlVMTCk7CiAKIAlzd2l0Y2ggKFVTQl9HRVRfU1RBVEUoeGZlcikpIHsKQEAgLTk2Nyw3 ICsxMDM3LDcgQEAgd3NwX2ludHJfY2FsbGJhY2soc3RydWN0IHVzYl94ZmVyICp4ZmVyLCB1c2Jf ZXJyb3JfdCBlcnJvcikKIAkJCQlzd2l0Y2ggKHNjLT5udGFwcykgewogCQkJCWNhc2UgMToKIAkJ CQkJaWYgKCEocGFyYW1zLT5jYXBzICYgSEFTX0lOVEVHUkFURURfQlVUVE9OKSkgewotCQkJCQkJ d3NwX2FkZF90b19xdWV1ZShzYywgMCwgMCwgMCwgTU9VU0VfQlVUVE9OMURPV04pOworCQkJCQkJ d3NwX2FkZF90b19xdWV1ZShzYywgMCwgMCwgMCwgMCwgTU9VU0VfQlVUVE9OMURPV04pOwogCQkJ CQkJRFBSSU5URk4oV1NQX0xMRVZFTF9JTkZPLCAiTEVGVCBDTElDSyFcbiIpOwogCQkJCQl9CiAJ CQkJCWJyZWFrOwpAQCAtOTc2LDIxICsxMDQ2LDIzIEBAIHdzcF9pbnRyX2NhbGxiYWNrKHN0cnVj dCB1c2JfeGZlciAqeGZlciwgdXNiX2Vycm9yX3QgZXJyb3IpCiAJCQkJCSAgICBzYy0+ZHhfc3Vt LCBzYy0+ZHlfc3VtKTsKIAkJCQkJaWYgKHNjLT5kaXN0YW5jZSA8IE1BWF9ESVNUQU5DRSAmJiBh YnMoc2MtPmR4X3N1bSkgPCA1ICYmCiAJCQkJCSAgICBhYnMoc2MtPmR5X3N1bSkgPCA1KSB7Ci0J CQkJCQl3c3BfYWRkX3RvX3F1ZXVlKHNjLCAwLCAwLCAwLCBNT1VTRV9CVVRUT04zRE9XTik7CisJ CQkJCQl3c3BfYWRkX3RvX3F1ZXVlKHNjLCAwLCAwLCAwLCAwLCBNT1VTRV9CVVRUT04zRE9XTik7 CiAJCQkJCQlEUFJJTlRGTihXU1BfTExFVkVMX0lORk8sICJSSUdIVCBDTElDSyFcbiIpOwogCQkJ CQl9CiAJCQkJCWJyZWFrOwogCQkJCWNhc2UgMzoKLQkJCQkJd3NwX2FkZF90b19xdWV1ZShzYywg MCwgMCwgMCwgTU9VU0VfQlVUVE9OMkRPV04pOworCQkJCQl3c3BfYWRkX3RvX3F1ZXVlKHNjLCAw LCAwLCAwLCAwLCBNT1VTRV9CVVRUT04yRE9XTik7CiAJCQkJCWJyZWFrOwogCQkJCWRlZmF1bHQ6 CiAJCQkJCS8qIHdlIGRvbid0IGhhbmRsZSB0YXBzIG9mIG1vcmUgdGhhbiB0aHJlZSBmaW5nZXJz ICovCiAJCQkJCWJyZWFrOwogCQkJCX0KLQkJCQl3c3BfYWRkX3RvX3F1ZXVlKHNjLCAwLCAwLCAw LCAwKTsJLyogYnV0dG9uIHJlbGVhc2UgKi8KKwkJCQl3c3BfYWRkX3RvX3F1ZXVlKHNjLCAwLCAw LCAwLCAwLCAwKTsJLyogYnV0dG9uIHJlbGVhc2UgKi8KIAkJCX0KKworI2lmIDAgLy8gUmVwbGFj ZSBiYWNrL2ZvcndhcmQgd2l0aCBob3Jpem9udGFsIHNjcm9sbAogCQkJaWYgKChzYy0+ZHRfc3Vt IC8gdHVuLnNjcl9ob3JfdGhyZXNob2xkKSAhPSAwICYmCi0JCQkgICAgc2MtPm50YXBzID09IDIg JiYgc2MtPnNjcl9tb2RlID09IFdTUF9TQ1JfSE9SKSB7CisJCQkgICAgc2MtPm50YXBzID09IDIg JiYgc2MtPnNjcm9sbF9tb2RlID09IFdTUF9TQ1JPTExfSE9SKSB7CiAKIAkJCQkvKgogCQkJCSAq IHRyYW5zbGF0ZSBULWF4aXMgaW50byBidXR0b24gcHJlc3NlcwpAQCAtMTAwMSwyMCArMTA3Mywy MyBAQCB3c3BfaW50cl9jYWxsYmFjayhzdHJ1Y3QgdXNiX3hmZXIgKnhmZXIsIHVzYl9lcnJvcl90 IGVycm9yKQogCQkJCWVsc2UgaWYgKHNjLT5kdF9zdW0gPCAwKQogCQkJCQl3c3BfYWRkX3RvX3F1 ZXVlKHNjLCAwLCAwLCAwLCAxVUwgPDwgNCk7CiAJCQl9CisjZW5kaWYKIAkJCXNjLT5kel9jb3Vu dCA9IFdTUF9EWl9NQVhfQ09VTlQ7Ci0JCQlzYy0+ZHpfc3VtID0gMDsKKwkJCXNjLT5kdF9jb3Vu dCA9IFdTUF9EVF9NQVhfQ09VTlQ7CiAJCQlzYy0+aW50cl9jb3VudCA9IDA7CiAJCQlzYy0+aWJ0 biA9IDA7CiAJCQlzYy0+bnRhcHMgPSAwOwogCQkJc2MtPmZpbmdlciA9IDA7CiAJCQlzYy0+ZGlz dGFuY2UgPSAwOwotCQkJc2MtPmR0X3N1bSA9IDA7CiAJCQlzYy0+ZHhfc3VtID0gMDsKIAkJCXNj LT5keV9zdW0gPSAwOworCQkJc2MtPmR6X3N1bSA9IDA7CisJCQlzYy0+ZHRfc3VtID0gMDsKIAkJ CXNjLT5yZHggPSAwOwogCQkJc2MtPnJkeSA9IDA7CiAJCQlzYy0+cmR6ID0gMDsKLQkJCXNjLT5z Y3JfbW9kZSA9IFdTUF9TQ1JfTk9ORTsKKwkJCXNjLT5yZHQgPSAwOworCQkJc2MtPnNjcm9sbF9t b2RlID0gV1NQX1NDUk9MTF9OT05FOwogCQl9IGVsc2UgaWYgKHNjLT5pbmRleFswXS0+dG91Y2hf bWFqb3IgPj0gdHVuLnByZXNzdXJlX3RvdWNoX3RocmVzaG9sZCAmJgogCQkgICAgc2MtPnNjX3Rv dWNoID09IFdTUF9VTlRPVUNIKSB7CS8qIGlnbm9yZSBmaXJzdCB0b3VjaCAqLwogCQkJc2MtPnNj X3RvdWNoID0gV1NQX0ZJUlNUX1RPVUNIOwpAQCAtMTA3OSw2ICsxMTU0LDcgQEAgd3NwX2ludHJf Y2FsbGJhY2soc3RydWN0IHVzYl94ZmVyICp4ZmVyLCB1c2JfZXJyb3JfdCBlcnJvcikKIAkJCQkJ RFBSSU5URk4oV1NQX0xMRVZFTF9JTkZPLCAiZHg9JTVkLCBkeT0lNWQsIG1vdj0lNWRcbiIsCiAJ CQkJCSAgICBkeCwgZHksIHNjLT5maW5nZXIpOwogCQkJCX0KKwkJCQkKIAkJCQlpZiAoc2MtPmR6 X2NvdW50LS0pIHsKIAkJCQkJcmR6ID0gKGR5ICsgc2MtPnJkeikgJSB0dW4uc2NhbGVfZmFjdG9y OwogCQkJCQlzYy0+ZHpfc3VtIC09IChkeSArIHNjLT5yZHopIC8gdHVuLnNjYWxlX2ZhY3RvcjsK QEAgLTEwODYsNiArMTE2MiwxNCBAQCB3c3BfaW50cl9jYWxsYmFjayhzdHJ1Y3QgdXNiX3hmZXIg KnhmZXIsIHVzYl9lcnJvcl90IGVycm9yKQogCQkJCX0KIAkJCQlpZiAoKHNjLT5kel9zdW0gLyB0 dW4uel9mYWN0b3IpICE9IDApCiAJCQkJCXNjLT5kel9jb3VudCA9IDA7CisKKwkJCQlpZiAoc2Mt PmR0X2NvdW50LS0pIHsKKwkJCQkJcmR0ID0gKGR4ICsgc2MtPnJkdCkgJSB0dW4uc2NhbGVfZmFj dG9yOworCQkJCQlzYy0+ZHRfc3VtICs9IChkeCArIHNjLT5yZHQpIC8gdHVuLnNjYWxlX2ZhY3Rv cjsKKwkJCQkJc2MtPnJkdCA9IHJkdDsKKwkJCQl9CisJCQkJaWYgKChzYy0+ZHRfc3VtIC8gdHVu LnRfZmFjdG9yKSAhPSAwKQorCQkJCQlzYy0+ZHRfY291bnQgPSAwOwogCQkJfQogCQkJcmR4ID0g KGR4ICsgc2MtPnJkeCkgJSB0dW4uc2NhbGVfZmFjdG9yOwogCQkJZHggPSAoZHggKyBzYy0+cmR4 KSAvIHR1bi5zY2FsZV9mYWN0b3I7CkBAIC0xMDk5LDQ1ICsxMTgzLDQ5IEBAIHdzcF9pbnRyX2Nh bGxiYWNrKHN0cnVjdCB1c2JfeGZlciAqeGZlciwgdXNiX2Vycm9yX3QgZXJyb3IpCiAJCQlzYy0+ ZHlfc3VtICs9IGR5OwogCiAJCQlpZiAobnRvdWNoID09IDIgJiYgc2MtPnNjX3N0YXR1cy5idXR0 b24gPT0gMCkgewotCQkJCWlmIChzYy0+c2NyX21vZGUgPT0gV1NQX1NDUl9OT05FICYmCisKKwkJ CQlpZiAoc2MtPnNjcm9sbF9tb2RlID09IFdTUF9TQ1JPTExfTk9ORSAmJgogCQkJCSAgICBhYnMo c2MtPmR4X3N1bSkgKyBhYnMoc2MtPmR5X3N1bSkgPiB0dW4uc2NyX2hvcl90aHJlc2hvbGQpCi0J CQkJCXNjLT5zY3JfbW9kZSA9IGFicyhzYy0+ZHhfc3VtKSA+Ci0JCQkJCSAgICBhYnMoc2MtPmR5 X3N1bSkgKiAyID8gV1NQX1NDUl9IT1IgOiBXU1BfU0NSX1ZFUjsKLQkJCQlEUFJJTlRGTihXU1Bf TExFVkVMX0lORk8sICJzY3JfbW9kZT0lNWQsIGNvdW50PSVkLCBkeF9zdW09JWQsIGR5X3N1bT0l ZFxuIiwKLQkJCQkgICAgc2MtPnNjcl9tb2RlLCBzYy0+aW50cl9jb3VudCwgc2MtPmR4X3N1bSwg c2MtPmR5X3N1bSk7Ci0JCQkJaWYgKHNjLT5zY3JfbW9kZSA9PSBXU1BfU0NSX0hPUikKLQkJCQkJ c2MtPmR0X3N1bSArPSBkeDsKLQkJCQllbHNlCi0JCQkJCXNjLT5kdF9zdW0gPSAwOworCQkJCQlz Yy0+c2Nyb2xsX21vZGUgPSBhYnMoc2MtPmR4X3N1bSkgPgorCQkJCQkJYWJzKHNjLT5keV9zdW0p ICogMiA/IFdTUF9TQ1JPTExfSE9SIDogV1NQX1NDUk9MTF9WRVI7CisKKwkJCQlEUFJJTlRGTihX U1BfTExFVkVMX0lORk8sICJzY3JvbGxfbW9kZT0lNWQsIGNvdW50PSVkLCBkeF9zdW09JWQsIGR5 X3N1bT0lZFxuIiwKKwkJCQkgICAgc2MtPnNjcm9sbF9tb2RlLCBzYy0+aW50cl9jb3VudCwgc2Mt PmR4X3N1bSwgc2MtPmR5X3N1bSk7CiAKIAkJCQlkeCA9IGR5ID0gMDsKLQkJCQlpZiAoc2MtPmR6 X2NvdW50ID09IDApCisJCQkJaWYgKHNjLT5kel9jb3VudCA9PSAwKSB7CiAJCQkJCWR6ID0gc2Mt PmR6X3N1bSAvIHR1bi56X2ZhY3RvcjsKLQkJCQlpZiAoc2MtPnNjcl9tb2RlID09IFdTUF9TQ1Jf SE9SIHx8IAotCQkJCSAgICBhYnMoc2MtPnBvc194WzBdIC0gc2MtPnBvc194WzFdKSA+IE1BWF9E SVNUQU5DRSB8fAotCQkJCSAgICBhYnMoc2MtPnBvc195WzBdIC0gc2MtPnBvc195WzFdKSA+IE1B WF9ESVNUQU5DRSkKLQkJCQkJZHogPSAwOworCQkJCX0KKwkJCQlpZiAoc2MtPmR0X2NvdW50ID09 IDApIHsKKwkJCQkJZHQgPSBzYy0+ZHRfc3VtIC8gdHVuLnRfZmFjdG9yOworCQkJCX0KIAkJCX0K IAkJCWlmIChudG91Y2ggPT0gMykKLQkJCQlkeCA9IGR5ID0gZHogPSAwOworCQkJCWR4ID0gZHkg PSBkeiA9IGR0ID0gMDsKIAkJCWlmIChzYy0+aW50cl9jb3VudCA8IFdTUF9UQVBfTUFYX0NPVU5U ICYmCi0JCQkgICAgYWJzKGR4KSA8IDMgJiYgYWJzKGR5KSA8IDMgJiYgYWJzKGR6KSA8IDMpCi0J CQkJZHggPSBkeSA9IGR6ID0gMDsKKwkJCSAgICBhYnMoZHgpIDwgMyAmJiBhYnMoZHkpIDwgMyAm JiBhYnMoZHopIDwgMyAmJiBhYnMoZHQpIDwgMykKKwkJCQlkeCA9IGR5ID0gZHogPSBkdCA9IDA7 CiAJCQllbHNlCiAJCQkJc2MtPmludHJfY291bnQgPSBXU1BfVEFQX01BWF9DT1VOVDsKLQkJCWlm IChkeCB8fCBkeSB8fCBkeikKKwkJCWlmIChkeCB8fCBkeSB8fCBkeiB8fCBkdCkKIAkJCQlzYy0+ c2Nfc3RhdHVzLmZsYWdzIHw9IE1PVVNFX1BPU0NIQU5HRUQ7Ci0JCQlEUFJJTlRGTihXU1BfTExF VkVMX0lORk8sICJkeD0lNWQsIGR5PSU1ZCwgZHo9JTVkLCBzY190b3VjaD0leCwgYnRuPSV4XG4i LAotCQkJICAgIGR4LCBkeSwgZHosIHNjLT5zY190b3VjaCwgc2MtPnNjX3N0YXR1cy5idXR0b24p OworCQkJRFBSSU5URk4oV1NQX0xMRVZFTF9JTkZPLCAiZHg9JTVkLCBkeT0lNWQsIGR6PSU1ZCwg ZHQ9JTVkLHNjX3RvdWNoPSV4LCBidG49JXhcbiIsCisJCQkJCSBkeCwgZHksIGR6LCBkdCwgc2Mt PnNjX3RvdWNoLCBzYy0+c2Nfc3RhdHVzLmJ1dHRvbik7CiAJCQlzYy0+c2Nfc3RhdHVzLmR4ICs9 IGR4OwogCQkJc2MtPnNjX3N0YXR1cy5keSArPSBkeTsKIAkJCXNjLT5zY19zdGF0dXMuZHogKz0g ZHo7CisJCQkvKiBObyBzdXBwb3J0IGZvciBkdCB0aGlzICh5ZXQpICovCisJCQkvKiBzYy0+c2Nf c3RhdHVzLmR0ICs9IGR0OyAqLwogCi0JCQl3c3BfYWRkX3RvX3F1ZXVlKHNjLCBkeCwgLWR5LCBk eiwgc2MtPnNjX3N0YXR1cy5idXR0b24pOworCQkJd3NwX2FkZF90b19xdWV1ZShzYywgZHgsIC1k eSwgZHosIGR0LCBzYy0+c2Nfc3RhdHVzLmJ1dHRvbik7CiAJCQlpZiAoc2MtPmR6X2NvdW50ID09 IDApIHsKIAkJCQlzYy0+ZHpfc3VtID0gMDsKIAkJCQlzYy0+cmR6ID0gMDsKIAkJCX0KKwkJCWlm IChzYy0+ZHRfY291bnQgPT0gMCkgeworCQkJCXNjLT5kdF9zdW0gPSAwOworCQkJCXNjLT5yZHQg PSAwOworCQkJfQogCiAJCX0KIAkJc2MtPnByZV9wb3NfeCA9IHNjLT5wb3NfeFswXTsKQEAgLTEx NTIsMTQgKzEyNDAsMTcgQEAgd3NwX2ludHJfY2FsbGJhY2soc3RydWN0IHVzYl94ZmVyICp4ZmVy LCB1c2JfZXJyb3JfdCBlcnJvcikKIAljYXNlIFVTQl9TVF9TRVRVUDoKIHRyX3NldHVwOgogCQkv KiBjaGVjayBpZiB3ZSBjYW4gcHV0IG1vcmUgZGF0YSBpbnRvIHRoZSBGSUZPICovCi0JCWlmICh1 c2JfZmlmb19wdXRfYnl0ZXNfbWF4KAotCQkgICAgc2MtPnNjX2ZpZm8uZnBbVVNCX0ZJRk9fUlhd KSAhPSAwKSB7Ci0JCQl1c2JkX3hmZXJfc2V0X2ZyYW1lX2xlbih4ZmVyLCAwLAotCQkJICAgIHNj LT50cF9kYXRhbGVuKTsKLQkJCXVzYmRfdHJhbnNmZXJfc3VibWl0KHhmZXIpOworCQlpZiAodXNi X2ZpZm9fcHV0X2J5dGVzX21heChzYy0+c2NfZmlmby5mcFtVU0JfRklGT19SWF0pID09IDApIHsK KyNpZmRlZiBFVkRFVgorCQkJaWYgKHNjLT5zY19ldmZsYWdzID09IDApCisJCQkJYnJlYWs7Cisj ZWxzZQorCQkJYnJlYWs7CisjZW5kaWYKIAkJfQorCQl1c2JkX3hmZXJfc2V0X2ZyYW1lX2xlbih4 ZmVyLCAwLCBzYy0+dHBfZGF0YWxlbik7CisJCXVzYmRfdHJhbnNmZXJfc3VibWl0KHhmZXIpOwog CQlicmVhazsKLQogCWRlZmF1bHQ6CQkJLyogRXJyb3IgKi8KIAkJaWYgKGVycm9yICE9IFVTQl9F UlJfQ0FOQ0VMTEVEKSB7CiAJCQkvKiB0cnkgY2xlYXIgc3RhbGwgZmlyc3QgKi8KQEAgLTExNzIs NyArMTI2Myw3IEBAIHRyX3NldHVwOgogCiBzdGF0aWMgdm9pZAogd3NwX2FkZF90b19xdWV1ZShz dHJ1Y3Qgd3NwX3NvZnRjICpzYywgaW50IGR4LCBpbnQgZHksIGludCBkeiwKLSAgICB1aW50MzJf dCBidXR0b25zX2luKQorCQkJCSBpbnQgZHQsIHVpbnQzMl90IGJ1dHRvbnNfaW4pCiB7CiAJdWlu dDMyX3QgYnV0dG9uc19vdXQ7CiAJdWludDhfdCBidWZbOF07CkBAIC0xMTgzLDYgKzEyNzQsOCBA QCB3c3BfYWRkX3RvX3F1ZXVlKHN0cnVjdCB3c3Bfc29mdGMgKnNjLCBpbnQgZHgsIGludCBkeSwg aW50IGR6LAogCWR5ID0gaW1heChkeSwgLTI1Nik7CiAJZHogPSBpbWluKGR6LCAxMjYpOwogCWR6 ID0gaW1heChkeiwgLTEyOCk7CisJZHQgPSBpbWluKGR0LCAxMjYpOworCWR0ID0gaW1heChkdCwg LTEyOCk7CiAKIAlidXR0b25zX291dCA9IE1PVVNFX01TQ19CVVRUT05TOwogCWlmIChidXR0b25z X2luICYgTU9VU0VfQlVUVE9OMURPV04pCkBAIC0xMjA3LDcgKzEzMDAsNjMgQEAgd3NwX2FkZF90 b19xdWV1ZShzdHJ1Y3Qgd3NwX3NvZnRjICpzYywgaW50IGR4LCBpbnQgZHksIGludCBkeiwKIAl9 CiAJdXNiX2ZpZm9fcHV0X2RhdGFfbGluZWFyKHNjLT5zY19maWZvLmZwW1VTQl9GSUZPX1JYXSwg YnVmLAogCSAgICBzYy0+c2NfbW9kZS5wYWNrZXRzaXplLCAxKTsKKworI2lmZGVmIEVWREVWCisJ LyogUHVzaCBldmRldiBldmVudCAqLworCWlmIChkeCAhPSAwIHx8IGR5ICE9IDApIHsKKwkJZXZk ZXZfcHVzaF9ldmVudChzYy0+c2NfZXZkZXYsIEVWX1JFTCwgUkVMX1gsIGR4KTsKKwkJZXZkZXZf cHVzaF9ldmVudChzYy0+c2NfZXZkZXYsIEVWX1JFTCwgUkVMX1ksIC1keSk7CisJfQorCWlmIChk eiAhPSAwKQorCQlldmRldl9wdXNoX2V2ZW50KHNjLT5zY19ldmRldiwgRVZfUkVMLCBSRUxfV0hF RUwsIC1keik7CisJaWYgKGR0ICE9IDApIHsKKwkJZXZkZXZfcHVzaF9ldmVudChzYy0+c2NfZXZk ZXYsIEVWX1JFTCwgUkVMX0hXSEVFTCwgZHQpOworCX0KKwlldmRldl9wdXNoX21vdXNlX2J0bihz Yy0+c2NfZXZkZXYsCisJCQkJCQkgKGJ1dHRvbnNfaW4gJiB+TU9VU0VfU1REQlVUVE9OUykgfAor CQkJCQkJIChidXR0b25zX2luICYgKDEgPDwgMikgPyBNT1VTRV9CVVRUT04xRE9XTiA6IDApIHwK KwkJCQkJCSAoYnV0dG9uc19pbiAmICgxIDw8IDEpID8gTU9VU0VfQlVUVE9OMkRPV04gOiAwKSB8 CisJCQkJCQkgKGJ1dHRvbnNfaW4gJiAoMSA8PCAwKSA/IE1PVVNFX0JVVFRPTjNET1dOIDogMCkp OworCWV2ZGV2X3N5bmMoc2MtPnNjX2V2ZGV2KTsKKyNlbmRpZgorCit9CisKKyNpZmRlZiBFVkRF Vgorc3RhdGljIGludAord3NwX2V2X29wZW4oc3RydWN0IGV2ZGV2X2RldiAqZXZkZXYsIHZvaWQg KmV2X3NvZnRjKQoreworCXN0cnVjdCB3c3Bfc29mdGMgKnNjID0gKHN0cnVjdCB3c3Bfc29mdGMg Killdl9zb2Z0YzsKKworCW10eF9sb2NrKCZzYy0+c2NfbXV0ZXgpOworCisJc2MtPnNjX2V2Zmxh Z3MgPSBXU1BfRVZERVZfT1BFTkVEOworCisJaWYgKHNjLT5zY19mZmxhZ3MgPT0gMCkgeworCQkv KiB3c3BfcmVzZXQoc2MpOyAqLworCQl3c3Bfc3RhcnRfcngoc2MpOworCX0KKworCW10eF91bmxv Y2soJnNjLT5zY19tdXRleCk7CisKKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgdm9pZAord3Nw X2V2X2Nsb3NlKHN0cnVjdCBldmRldl9kZXYgKmV2ZGV2LCB2b2lkICpldl9zb2Z0YykKK3sKKwlz dHJ1Y3Qgd3NwX3NvZnRjICpzYyA9IChzdHJ1Y3Qgd3NwX3NvZnRjICopZXZfc29mdGM7CisKKwlt dHhfbG9jaygmc2MtPnNjX211dGV4KTsKKworCXNjLT5zY19ldmZsYWdzID0gMDsKKworCWlmIChz Yy0+c2NfZmZsYWdzID09IDApCisJCXdzcF9zdG9wX3J4KHNjKTsKKworCW10eF91bmxvY2soJnNj LT5zY19tdXRleCk7CiB9CisjZW5kaWYKIAogc3RhdGljIHZvaWQKIHdzcF9yZXNldF9idWYoc3Ry dWN0IHdzcF9zb2Z0YyAqc2MpCkBAIC0xMjE3LDkgKzEzNjYsOCBAQCB3c3BfcmVzZXRfYnVmKHN0 cnVjdCB3c3Bfc29mdGMgKnNjKQogfQogCiBzdGF0aWMgdm9pZAotd3NwX3N0YXJ0X3JlYWQoc3Ry dWN0IHVzYl9maWZvICpmaWZvKQord3NwX3N0YXJ0X3J4KHN0cnVjdCB3c3Bfc29mdGMgKnNjKQog ewotCXN0cnVjdCB3c3Bfc29mdGMgKnNjID0gdXNiX2ZpZm9fc29mdGMoZmlmbyk7CiAJaW50IHJh dGU7CiAKIAkvKiBDaGVjayBpZiB3ZSBzaG91bGQgb3ZlcnJpZGUgdGhlIGRlZmF1bHQgcG9sbGlu ZyBpbnRlcnZhbCAqLwpAQCAtMTI0MCwxMyArMTM4OCwyNSBAQCB3c3Bfc3RhcnRfcmVhZChzdHJ1 Y3QgdXNiX2ZpZm8gKmZpZm8pCiB9CiAKIHN0YXRpYyB2b2lkCi13c3Bfc3RvcF9yZWFkKHN0cnVj dCB1c2JfZmlmbyAqZmlmbykKK3dzcF9zdGFydF9yZWFkKHN0cnVjdCB1c2JfZmlmbyAqZmlmbykK IHsKIAlzdHJ1Y3Qgd3NwX3NvZnRjICpzYyA9IHVzYl9maWZvX3NvZnRjKGZpZm8pOworCXdzcF9z dGFydF9yeChzYyk7Cit9CiAKK3N0YXRpYyB2b2lkCit3c3Bfc3RvcF9yeChzdHJ1Y3Qgd3NwX3Nv ZnRjICpzYykKK3sKIAl1c2JkX3RyYW5zZmVyX3N0b3Aoc2MtPnNjX3hmZXJbV1NQX0lOVFJfRFRd KTsKIH0KIAorc3RhdGljIHZvaWQKK3dzcF9zdG9wX3JlYWQoc3RydWN0IHVzYl9maWZvICpmaWZv KQoreworCXN0cnVjdCB3c3Bfc29mdGMgKnNjID0gdXNiX2ZpZm9fc29mdGMoZmlmbyk7CisJd3Nw X3N0b3Bfcngoc2MpOworfQorCiAKIHN0YXRpYyBpbnQKIHdzcF9vcGVuKHN0cnVjdCB1c2JfZmlm byAqZmlmbywgaW50IGZmbGFncykKQEAgLTEyNTUsNiArMTQxNSw3IEBAIHdzcF9vcGVuKHN0cnVj dCB1c2JfZmlmbyAqZmlmbywgaW50IGZmbGFncykKIAogCWlmIChmZmxhZ3MgJiBGUkVBRCkgewog CQlzdHJ1Y3Qgd3NwX3NvZnRjICpzYyA9IHVzYl9maWZvX3NvZnRjKGZpZm8pOworCQlzYy0+c2Nf ZmZsYWdzID0gZmZsYWdzOwogCQlpbnQgcmM7CiAKIAkJaWYgKHNjLT5zY19zdGF0ZSAmIFdTUF9F TkFCTEVEKQo= --94eb2c18f43c69faca0539e600da-- From owner-freebsd-current@freebsd.org Sat Aug 13 01:30:58 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 94C7CBB6E37; Sat, 13 Aug 2016 01:30:58 +0000 (UTC) (envelope-from gjb@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 883DE185B; Sat, 13 Aug 2016 01:30:58 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id 34B781E8D; Sat, 13 Aug 2016 01:30:58 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Sat, 13 Aug 2016 01:30:56 +0000 From: Glen Barber To: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, freebsd-snapshots@FreeBSD.org Cc: FreeBSD Release Engineering Team Subject: FreeBSD 11.0-RC1 Now Available Message-ID: <20160813013056.GS11079@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 13 Aug 2016 01:30:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The first RC build of the 11.0-RELEASE release cycle is now available. Installation images are available for: o 11.0-RC1 amd64 GENERIC o 11.0-RC1 i386 GENERIC o 11.0-RC1 powerpc GENERIC o 11.0-RC1 powerpc64 GENERIC64 o 11.0-RC1 sparc64 GENERIC o 11.0-RC1 armv6 BANANAPI o 11.0-RC1 armv6 BEAGLEBONE o 11.0-RC1 armv6 CUBIEBOARD o 11.0-RC1 armv6 CUBIEBOARD2 o 11.0-RC1 armv6 CUBOX-HUMMINGBOARD o 11.0-RC1 armv6 GUMSTIX o 11.0-RC1 armv6 RPI-B o 11.0-RC1 armv6 RPI2 o 11.0-RC1 armv6 PANDABOARD o 11.0-RC1 armv6 WANDBOARD o 11.0-RC1 aarch64 GENERIC Note regarding arm/armv6 images: For convenience for those without console access to the system, a freebsd user with a password of freebsd is available by default for ssh(1) access. Additionally, the root user password is set to root, which it is strongly recommended to change the password for both users after gaining access to the system. Installer images and memory stick images are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/11.0/ The image checksums follow at the end of this e-mail. If you notice problems you can report them through the Bugzilla PR system or on the -stable mailing list. If you would like to use SVN to do a source based update of an existing system, use the "releng/11.0" branch. A summary of changes since BETA4 includes: o A NULL pointer dereference in IPSEC has been fixed. o Support for SSH Protocol 1 has been removed. o OpenSSH DSA keys have been disabled by default. Users upgrading from prior FreeBSD versions are urged to update their SSH keys to DSA or ECDSA keys before upgrading to 11.0-RC1. o PCI-e hotplug on bridges with power controllers has been disabled. o A loader tunable (hw.pci.enable_pcie_hp) to disable PCI-e HotPlug has been added. o A VESA panic on suspend has been fixed. o Google Compute Engine image publication has been fixed. o An AES-ICM heap corruption typo bug has been fixed. o A regression in pf.conf while parsing the 'interval' keyword has been fixed. o A ZFS/VFS deadlock has been fixed. A list of changes since 10.0-RELEASE are available on the releng/11.0 release notes: https://www.freebsd.org/releases/11.0R/relnotes.html Please note, the release notes page is not yet complete, and will be updated on an ongoing basis as the 11.0-RELEASE cycle progresses. === Virtual Machine Disk Images === VM disk images are available for the amd64 and i386 architectures. Disk images may be downloaded from the following URL (or any of the FreeBSD FTP mirrors): ftp://ftp.freebsd.org/pub/FreeBSD/releases/VM-IMAGES/11.0-RC1/ The partition layout is: ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label) ~ 1 GB - freebsd-swap GPT partition type (swapfs GPT label) ~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label) The disk images are available in QCOW2, VHD, VMDK, and raw disk image formats. The image download size is approximately 135 MB and 165 MB respectively (amd64/i386), decompressing to a 21 GB sparse image. Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI loader file is needed for qemu-system-aarch64 to be able to boot the virtual machine images. See this page for more information: https://wiki.freebsd.org/arm64/QEMU To boot the VM image, run: % qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt \ -bios QEMU_EFI.fd -serial telnet::4444,server -nographic \ -drive if=none,file=VMDISK,id=hd0 \ -device virtio-blk-device,drive=hd0 \ -device virtio-net-device,netdev=net0 \ -netdev user,id=net0 Be sure to replace "VMDISK" with the path to the virtual machine image. === Amazon EC2 AMI Images === FreeBSD/amd64 EC2 AMIs are available in the following regions: us-east-1 region: ami-1f128b08 us-west-1 region: ami-73baf913 us-west-2 region: ami-9062a9f0 sa-east-1 region: ami-daaf39b6 eu-west-1 region: ami-424d2731 eu-central-1 region: ami-ca7284a5 ap-northeast-1 region: ami-3ae6255b ap-northeast-2 region: ami-dc5c96b2 ap-southeast-1 region: ami-0f875e6c ap-southeast-2 region: ami-c3d6e2a0 === Vagrant Images === FreeBSD/amd64 images are available on the Hashicorp Atlas site, and can be installed by running: % vagrant init freebsd/FreeBSD-11.0-RC1 % vagrant up === Upgrading === The freebsd-update(8) utility supports binary upgrades of amd64 and i386 systems running earlier FreeBSD releases. Systems running earlier FreeBSD releases can upgrade as follows: # freebsd-update upgrade -r 11.0-RC1 During this process, freebsd-update(8) may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install It is recommended to rebuild and install all applications if possible, especially if upgrading from an earlier FreeBSD release, for example, FreeBSD 9.x. Alternatively, the user can install misc/compat9x and other compatibility libraries, afterwards the system must be rebooted into the new userland: # shutdown -r now Finally, after rebooting, freebsd-update needs to be run again to remove stale files: # freebsd-update install == ISO CHECKSUMS == o 11.0-RC1 amd64 GENERIC: SHA512 (FreeBSD-11.0-RC1-amd64-bootonly.iso) = ff68595cd2418ab2aeada88c01be0aa34cbab282ca217fb39529a10fecf4da9884bc5cc3f76f7da2acf11edb3a9c839050234cfefa2618095decca33c7b7a393 SHA512 (FreeBSD-11.0-RC1-amd64-bootonly.iso.xz) = 215a7a58ed92cccfa7ae5345472a6b6a88a5136f2d88bc679c1a015c9efaff4945408ce0e909dcba0ca030709e328a839b549dbfea0dc1439ca1c399cb27b228 SHA512 (FreeBSD-11.0-RC1-amd64-disc1.iso) = 405929bbf0dbd5d6b4d1f1aeb44a2dff31c00f7ce52dafb43d57ae88c98e090c7c3bcf2c801de9b4d0972650ea79cb4d320866e96e53fcea2d73e646fd45b1b9 SHA512 (FreeBSD-11.0-RC1-amd64-disc1.iso.xz) = b1e1e9e6c67efea651fcbdb4dc45d8fa4382e165795af87a643447ef5c24828b233a4ca46cdc823d341ee4700349d74e71350af938422e77f5e916bbe7f80301 SHA512 (FreeBSD-11.0-RC1-amd64-dvd1.iso) = 3a01f637b46ea62eac9bbe94f367df4df2d9875c00385a078615bbe0fea13e56a1d3c8d0d8b9c4de10aec5b95eebfc6fd60e28f405eebe218ed3bf47c0e7f68f SHA512 (FreeBSD-11.0-RC1-amd64-dvd1.iso.xz) = 54473c88d00b5292f8bedec5bca20c29ec67d727668e7358971fc3ca8b53427a413eeb08fbd656109c0dac35efe2d860da290b2cc78527eb26eb8204657a988a SHA512 (FreeBSD-11.0-RC1-amd64-memstick.img) = 261fd4687d68501209711514f9e8f0a96a04a8ded423288ac08d1203d0f878a05705c73edccd282e28b4185ff5c6b30c1563c3a92f6f8a415f2676ab29214603 SHA512 (FreeBSD-11.0-RC1-amd64-memstick.img.xz) = 397af893f80a0be64ab77165c5395783b1586f8e6bdb75333c00b671b5a178e441300cd28e2b54068c8bbf203da193182b59d59e510639471bab4cfb76b0d68b SHA512 (FreeBSD-11.0-RC1-amd64-mini-memstick.img) = a56325ffce3eb10fc78cbcab4ea90dd6f879fadb05a1a57a17a35a63cc4580f938aeaf04ab1a97fa10526db0d3d9c2c16f833b91a0dbdae76ce878447b019d7a SHA512 (FreeBSD-11.0-RC1-amd64-mini-memstick.img.xz) = 0fc8fc19ae0cb9287e229f59f411ef766d205974e5e597b2118c31e37125c8f36327746c259f678c571429bf0c3cb2e0323287751eceaf92fe4336c35ab660d2 SHA256 (FreeBSD-11.0-RC1-amd64-bootonly.iso) = c1acefa855900d998d469953ddff74758e6843bf6a3e409ea3a41c9635ba9a23 SHA256 (FreeBSD-11.0-RC1-amd64-bootonly.iso.xz) = d872fc97bf17c1f8c4ecf90b55992956511316f1d96ba72527ff10b64331f97b SHA256 (FreeBSD-11.0-RC1-amd64-disc1.iso) = e0b72c94cc6d4fdde06604c3867fd4a6b5d1c34cbe8c736f93dbfab329536858 SHA256 (FreeBSD-11.0-RC1-amd64-disc1.iso.xz) = 6b000117daab2e4fb42d577a221869b165909f559f306ff4433f347cba2b15f7 SHA256 (FreeBSD-11.0-RC1-amd64-dvd1.iso) = ee76a5590d10f5125ccb8e332df1252c4f484bd8b76ac51e3571175e50d37c4b SHA256 (FreeBSD-11.0-RC1-amd64-dvd1.iso.xz) = 1444593402d6290b8782a1221a6ebe835c796d3f4d0dcb4f6af7aff222f941ee SHA256 (FreeBSD-11.0-RC1-amd64-memstick.img) = ae144fd1898b0ad2ed2ce360f0c0d2c6e2ee19edcb8d75325cb8936c7e82b3b4 SHA256 (FreeBSD-11.0-RC1-amd64-memstick.img.xz) = aea7616b1a377f99c453d8711dd421d87d8b574ae0285148a607b8e9ff45c826 SHA256 (FreeBSD-11.0-RC1-amd64-mini-memstick.img) = 2e2488581aaed7cef5103c9b5322b9c6d1321c3f2656074f2927ee15924da313 SHA256 (FreeBSD-11.0-RC1-amd64-mini-memstick.img.xz) = 02452d01bc0c1785f4db29bd1770543f807481f44612b1449853b5bbf330e359 o 11.0-RC1 i386 GENERIC: SHA512 (FreeBSD-11.0-RC1-i386-bootonly.iso) = b3fe0545e0c761623bf15e8d1c44f7b290eac99fdccbedc52c4ef73df9d1fde5c798f042ffa1c667b209bce1735071721b83c3f62051d68778a586d7234def85 SHA512 (FreeBSD-11.0-RC1-i386-bootonly.iso.xz) = 10a65c2f6b45c9ec2f321591b8a338cc5d5ad2b9426a9ebfad83c972d96852fbcb1748e1465c75f61fd106ec4a3f552328f42cc5ae7c80d3226fee139e3d438c SHA512 (FreeBSD-11.0-RC1-i386-disc1.iso) = af87157ce41293bdfd4affbd8915b840fce27219d381058ab0335ae476b6e5aa1343af308ee61b206039e5ee5933add780e20b9a3e87317eb85389b1c3d014cb SHA512 (FreeBSD-11.0-RC1-i386-disc1.iso.xz) = 3858341018ea91ba47bcb89c5155af47d5bbc7c93352d5b775af92c981d08eed120dc440509ab228c1d217997a914342864ab50bd78b7b6085ad86c17d3ce517 SHA512 (FreeBSD-11.0-RC1-i386-dvd1.iso) = 80fdfbdd03915241bb83b6e460669fc1ee60f477beb25df2bb4d783609c81a99637cd831dcad73464a7dbb46fb29eaa1a27320d931133153b1d4c92ee02d29cb SHA512 (FreeBSD-11.0-RC1-i386-dvd1.iso.xz) = a7b1d449ab7a5bf47b2ba9744d536e799a84d0ce4ccd42e0792fd8ee4d617100d961c9809a832f5dd5976e2cb7e4249bc7e81efb688ee305df40c47414162c9d SHA512 (FreeBSD-11.0-RC1-i386-memstick.img) = c6c8e54ac877c76b600695e6c8f2739e3dabd24364e9e746fe2702c2242d0cb2ec3c542fa4c1c1ef4d65c2e0ea75ac9fb1ed996c994a9b94ed2f8ffb7a2fcd8f SHA512 (FreeBSD-11.0-RC1-i386-memstick.img.xz) = efafc65845ff818bf83dedf4f052be1d162613827b23ebeb96700b28e009ae0417cbdca4b7f4580eae9af0fd34d7e6e652ad2ec95881bebf8d22d33bdb861808 SHA512 (FreeBSD-11.0-RC1-i386-mini-memstick.img) = 1fbd2e6fc21570a8abef107942e46df9b766a1daa18a827442f412efe0b41fa5f4732105e7be8f02c937f2800211cf50025e1b914fecbe49f9079157bdeb7411 SHA512 (FreeBSD-11.0-RC1-i386-mini-memstick.img.xz) = d80ef8216cb8936d09a751b276f304a99859f6516fe126ebc91e1757c8c7e4f4cce8be779ea7b59915a99c0567d26793f173eeaa00e7bb40077a7806f2c94ed6 SHA256 (FreeBSD-11.0-RC1-i386-bootonly.iso) = e269b1406ae5a4d69da90c2456350d9da2facf2b1813cb5ea082636fc2d5b809 SHA256 (FreeBSD-11.0-RC1-i386-bootonly.iso.xz) = 6a40b6685d5c5244a662ee9edcc334cdb4c025fb2bf7354019d4b0d76d3c52ec SHA256 (FreeBSD-11.0-RC1-i386-disc1.iso) = fb7122ccd4943478b3523dc7d6aa6d5f78ad1b249911b865dc2379f3192250c1 SHA256 (FreeBSD-11.0-RC1-i386-disc1.iso.xz) = 5aa45c7c9559f9125379efc157b6d1937e6dfdd749eb182755ba4f3cab3a07ae SHA256 (FreeBSD-11.0-RC1-i386-dvd1.iso) = 958d5a5572d277e47e8d465b36d215743cd730094ed5a8b64d4b29d65e1c0a86 SHA256 (FreeBSD-11.0-RC1-i386-dvd1.iso.xz) = 7e7f79bfacd7040c7bf13475eff78067de4ce8b9dc453cf81c39130e23a87e10 SHA256 (FreeBSD-11.0-RC1-i386-memstick.img) = 854d8fb5e7054a4d2ca0802e60b461fd6f775105949aa1ef9953aa2c809fdce9 SHA256 (FreeBSD-11.0-RC1-i386-memstick.img.xz) = a6f718bd1e64668d52df71ba7ba145b9dc2970db6ae834415af52a2d7e4ba664 SHA256 (FreeBSD-11.0-RC1-i386-mini-memstick.img) = a7bcde6fdd39f465d1ba614c2215a6f82ab32ab8744a18e796e4685a745c2a81 SHA256 (FreeBSD-11.0-RC1-i386-mini-memstick.img.xz) = 4ddf74ce9be35d82e38f04e2f417bb4d6c338a8d4de0a6086176021b6eaa5d69 o 11.0-RC1 powerpc GENERIC: SHA512 (FreeBSD-11.0-RC1-powerpc-bootonly.iso) = e4a8e288db652b714796a3c1c1d30c9183de268cfe2fdb6068ab0d77a9149edb9e59ea6e556c98e93136990c2b33fb1e9a41e6f7877692800df34af4918f662e SHA512 (FreeBSD-11.0-RC1-powerpc-bootonly.iso.xz) = 11174e5c4b81809650398f794aeb96a54eebc7d7f3af1b259ef29aeb9e800491c458a17dcd8a31b184c2b71083b6f790f1cf5887332cbf78dfb8b78c61290c27 SHA512 (FreeBSD-11.0-RC1-powerpc-disc1.iso) = bd4bec8c8a5a67089d91a5343f3c5c9bcf9a6af002d67d99f2d1e1535888ce5cfdfad6a6e66a143200c084d91265a525ec9322044772c0bf627b96f3911229ee SHA512 (FreeBSD-11.0-RC1-powerpc-disc1.iso.xz) = c72ae822fa2dacb37904f12c6577c83ba25c7b1a33c978bb15b727b776bb7a7533a7edc0b6b97a89362b9981ab757e713b91accd33e7abbb35d52f35d052f3d9 SHA512 (FreeBSD-11.0-RC1-powerpc-memstick.img) = 7cb253c005b24711c19da7a63801b0a4611755f43ecf7bab1e68f6d294dd310b49f227002ce800b2b1eca1b4d7dc4a9e227cdd7da370308169d68c069f721189 SHA512 (FreeBSD-11.0-RC1-powerpc-memstick.img.xz) = 21ab54b84cbf95cc6c0baf61d81028c3ec0f81cd5cdfba713619d0e48e0369b2223502209222823b5ae0a6238484733dc3c9d2d16a6c09d66f3436143f13ecd4 SHA512 (FreeBSD-11.0-RC1-powerpc-mini-memstick.img) = ad8d3e0b00ef61968a82dcab8bb876e60a368baf5fc4c00566a8cb27832cd67aafa12736e002809a2a4dc96e829ce524864854a40365e8c86ec09c46dd703234 SHA512 (FreeBSD-11.0-RC1-powerpc-mini-memstick.img.xz) = 54150fa273c9bcce1c96aa943c768eda0c45853c5a9b7cfc1c1c7f84c07e63d7a5511f8d0632822f294c1607b1b33ab95065e6849fdb9848b2467db69f6dae59 SHA256 (FreeBSD-11.0-RC1-powerpc-bootonly.iso) = f7219d759ae66c792fb2d15d0c74f730f9be2904a30f638048da44a639c07b2a SHA256 (FreeBSD-11.0-RC1-powerpc-bootonly.iso.xz) = 91bec51977f1d86e51e2abe1f8666946b30b02f338ec0767ed5872b197513957 SHA256 (FreeBSD-11.0-RC1-powerpc-disc1.iso) = 547b88577c0a5a6675087216e2028bafa4a3b9855ee1d9b9283ce1c358f5668f SHA256 (FreeBSD-11.0-RC1-powerpc-disc1.iso.xz) = 01b8ee988a304e6b910db73d0c20a2a0419090a878e1ebc90eb29b4774dd631b SHA256 (FreeBSD-11.0-RC1-powerpc-memstick.img) = 012cfb1f819447298641c9292a3d584a52398a8f588e9bff0d36f9f7488095c7 SHA256 (FreeBSD-11.0-RC1-powerpc-memstick.img.xz) = eb64b13f663ff1b32eeddd1d8e365a8608b15ff0d8d1c9a791559cd65b21afb1 SHA256 (FreeBSD-11.0-RC1-powerpc-mini-memstick.img) = d284534a5c73a66bc6ccab61bb750f2111e67de69e75d0db137696143465fad1 SHA256 (FreeBSD-11.0-RC1-powerpc-mini-memstick.img.xz) = 37e03a3975a6ae3f2c22e43afaf804a83fd482df9e7313ba5c0e69bb5f21d98d o 11.0-RC1 powerpc64 GENERIC64: SHA512 (FreeBSD-11.0-RC1-powerpc-powerpc64-bootonly.iso) = 33dd76a7092fc7432e225bb0e00165948239941c0109914de3eb19160de97400389fb0be42418417b59d2bb2e0992527518e58ecab1415114d3853b8cc95e91c SHA512 (FreeBSD-11.0-RC1-powerpc-powerpc64-bootonly.iso.xz) = 40e1293a25fca47526ffeaabe83bfa472ba12b7b0563299dc756af2570be02f461ecba4183333cd9b009c80c410905f3459eca97f4cfafcfb8b57e2a27c6a6c2 SHA512 (FreeBSD-11.0-RC1-powerpc-powerpc64-disc1.iso) = c83412058d7273838cd75a6ca238081083e472eae78ec5bc57dd23ae4585809260948974e8f174ea565b201292261a455f5172e6881b6cebc23996f79deb3e65 SHA512 (FreeBSD-11.0-RC1-powerpc-powerpc64-disc1.iso.xz) = b58c1199e37553a169c0353552541793e4bc01b9ec4ae2d0b5616a7989c476e0969ce990249008e435c6da9e2aa94b42358490e7b08d6060c8e2b8e095b460ca SHA512 (FreeBSD-11.0-RC1-powerpc-powerpc64-memstick.img) = 443a921447ea985fbe587b41ecb87a109d7f75c00b0331ae5659daeacff19f809429e96c423cd96393093c295c5fde5185a7c14ba5b809cf6a0aa96a5410be0d SHA512 (FreeBSD-11.0-RC1-powerpc-powerpc64-memstick.img.xz) = b1e7fa2d0a0f66822cc6017a554c58b38cacd9dbb53dc57419de496f22f172513a5c52684f78967933736f2d57d3c854242986f4b7dcd25437cc72b7ffed999b SHA512 (FreeBSD-11.0-RC1-powerpc-powerpc64-mini-memstick.img) = 039bb416776605f42fad14f28e9446a245c40ba6db4496a7d93b59bfa4e664d33b3ec95230f59d77b0048e9808490e32bcb7d959745dcdc01909aba94193103f SHA512 (FreeBSD-11.0-RC1-powerpc-powerpc64-mini-memstick.img.xz) = 43996720a13f7d559ea7b2ee538a866f3707cb053a5d11503542f47b8670e9a405a314a4c31fd0d55d29b63d23c9ff5972c43294938b3ee432aaea4eec82b1bf SHA256 (FreeBSD-11.0-RC1-powerpc-powerpc64-bootonly.iso) = 8f2bc236bc53f8df2324efaf1e15b085f4471b33996545803d080840a9bd03aa SHA256 (FreeBSD-11.0-RC1-powerpc-powerpc64-bootonly.iso.xz) = 6d091cdaf53882a09abcca9c8829bfe95a9aea5a8323ded8b869c114168ec945 SHA256 (FreeBSD-11.0-RC1-powerpc-powerpc64-disc1.iso) = 38c1fbc771284450befbd3ba444d0059bc17913a09132c995c73615b27b71fb2 SHA256 (FreeBSD-11.0-RC1-powerpc-powerpc64-disc1.iso.xz) = 83d603e79e149e77b9a939a940777055ce5c6cd1ef2e0beda168a1037a5c5ced SHA256 (FreeBSD-11.0-RC1-powerpc-powerpc64-memstick.img) = fa653fa47f4f20ece8e9b3571bf611bbf0976d8319b0a837d3becf7b9703e292 SHA256 (FreeBSD-11.0-RC1-powerpc-powerpc64-memstick.img.xz) = 910de6691f65be107c4c22df6b8ec0587b4f081b1f3bee05f0e761e443290bd9 SHA256 (FreeBSD-11.0-RC1-powerpc-powerpc64-mini-memstick.img) = 58a8e603e433d60de27437bcf22299cd810c1bdc74a201218e3a93a0e78b03f6 SHA256 (FreeBSD-11.0-RC1-powerpc-powerpc64-mini-memstick.img.xz) = 7e904e9f11d3ccf8840142e2c87669c5cc044a29d9eb177be72e7a23f9cd3d5a o 11.0-RC1 sparc64 GENERIC: SHA512 (FreeBSD-11.0-RC1-sparc64-bootonly.iso) = 9c6b96bffe3c0a28f02b48cf64d7cec70d48813ac793c1153d926899cc5c4b1a1dd13045c20e5af43564b61289cc630a490ef817f5f0f35ff2fc6600f1875571 SHA512 (FreeBSD-11.0-RC1-sparc64-bootonly.iso.xz) = d3118119cc3134544a3f359dbe4adcd5ceced2579a3a94ed08739cc1cf7346302c975fc66ce38f8168d56a2423ffa01c5cbf0e30eed32ec46fb40a029a5d93d1 SHA512 (FreeBSD-11.0-RC1-sparc64-disc1.iso) = 1aeaa357d733790d7e143ccaf7377870c466f8769871ff2247cd2810e151940c725fc22703d5414e8d6edffd28141c388dc5a6b2f981684b20c7cff86d45a228 SHA512 (FreeBSD-11.0-RC1-sparc64-disc1.iso.xz) = 6a052e2e8167c9778743602428872b86a5e3628428348c41b3ba12a6d000b5a6c9acd8842a1f79c1f75263c8982b9dd4ccf30c293647791f50357b17c0341efc SHA256 (FreeBSD-11.0-RC1-sparc64-bootonly.iso) = b63e2a4ac5c020ae052f145078f35999589cf41db778cfe2c83c93504e9e92b4 SHA256 (FreeBSD-11.0-RC1-sparc64-bootonly.iso.xz) = 41f774c6df2ec2fabeeaad7adf1f1419851f3fc81dd1f379ac70577d43598a29 SHA256 (FreeBSD-11.0-RC1-sparc64-disc1.iso) = a4dd14503a9693af74ef3351ac20fa5921d98f2c8fdea8852fc1964cb60ecc10 SHA256 (FreeBSD-11.0-RC1-sparc64-disc1.iso.xz) = 58ff32bce9275ec998886dd6e2f6130693ca01ee57098a7aa6ead8eaa90f1f26 o 11.0-RC1 armv6 BANANAPI: SHA512 (FreeBSD-11.0-RC1-arm-armv6-BANANAPI.img.xz) = 2de36d6e6991666317a4a08d257786b3f0a636d1b811b16d620fb99e59de3bf993447b01dfc6e2874bafd34d172468755155c11fb164184527dd51f0d9401d1b SHA256 (FreeBSD-11.0-RC1-arm-armv6-BANANAPI.img.xz) = baaa50a3794548785fa37e01d6c56c81a7156d1b476d772fa7ea4da0bd6fccff o 11.0-RC1 armv6 BEAGLEBONE: SHA512 (FreeBSD-11.0-RC1-arm-armv6-BEAGLEBONE.img.xz) = b18287c813f1666cf34a48ba6423bc5bee997af6d1fcfe1ad217ad4e20a99e0a844355063b4ce14f5ffd203c0d3189e5cce4038a98932ce3f0c75b8966c4ef13 SHA256 (FreeBSD-11.0-RC1-arm-armv6-BEAGLEBONE.img.xz) = fc6d2e712afff77ff5db2b1522b41d43fefe42abdd50e7d6553e5c9f4046c456 o 11.0-RC1 armv6 CUBIEBOARD: SHA512 (FreeBSD-11.0-RC1-arm-armv6-CUBIEBOARD.img.xz) = 70610d45c82ae1fe89dc1c7afa5a2401a5182932cc1627a9af1c56ef3743b68f5349d2cb30f78d50e164186f0c4ef470343e8638bb290249b992b1fc2fa9dc09 SHA256 (FreeBSD-11.0-RC1-arm-armv6-CUBIEBOARD.img.xz) = e4434996081d914d415d7c102df1b588d55022ce9f4025ab6e42a92919a01895 o 11.0-RC1 armv6 CUBIEBOARD2: SHA512 (FreeBSD-11.0-RC1-arm-armv6-CUBIEBOARD2.img.xz) = 38ea0439543e49658b8eb7003ac9ced116f8fbf833d09894cfb387758c4771f8d1e7733509cbc537f3f9baf0fd74a697793d257cc48d91fe3c6f15562316086c SHA256 (FreeBSD-11.0-RC1-arm-armv6-CUBIEBOARD2.img.xz) = 4f35e269de6c0e4a75b30e82138db9955546a64194462823abae2f3e0e1f1e20 o 11.0-RC1 armv6 CUBOX-HUMMINGBOARD: SHA512 (FreeBSD-11.0-RC1-arm-armv6-CUBOX-HUMMINGBOARD.img.xz) = 94ed80218e11c346bddc767bf974c344dddc7dabe3fa5323450c7d4bed1cbfd1d2d125eeb317270c94f3cb3204cec2e6b45e379b1f523f2c0dcacbdfcdad1d62 SHA256 (FreeBSD-11.0-RC1-arm-armv6-CUBOX-HUMMINGBOARD.img.xz) = 6c7a31a1827df5c6f584f364a4962a40c90ce8822fa516f80f6b6c15a60fc73c o 11.0-RC1 armv6 GUMSTIX: SHA512 (FreeBSD-11.0-RC1-arm-armv6-GUMSTIX.img.xz) = 1f3bc2319e66e1bde458e392456b86a6673cd1824c5f465067e072c99164922ab39e774696f17be776eedcebabf08a3c2cce999764decd2260c821b84a5c4a89 SHA256 (FreeBSD-11.0-RC1-arm-armv6-GUMSTIX.img.xz) = beaf5a3df3cf13a618752d64dc1ff35084d1c5fb4db15fcdc54317acecfa00f4 o 11.0-RC1 armv6 RPI-B: SHA512 (FreeBSD-11.0-RC1-arm-armv6-RPI-B.img.xz) = 1a83f40f74a4a3796f3a005c1c06aeb8d9c86362602a3286a30eb06f05e3d7d72e72b76a6568d0dd2152824ce94c773761c6f9700df7d04ece006f796d83265d SHA256 (FreeBSD-11.0-RC1-arm-armv6-RPI-B.img.xz) = 47c0eb0626870b494187637b0ad1bd8d722ec3a6b35321ee6839a58dff8f7e3d o 11.0-RC1 armv6 RPI2: SHA512 (FreeBSD-11.0-RC1-arm-armv6-RPI2.img.xz) = 2cc9ad47de4fc7cc1c199896b9fb1957923a03f0d3682e00cb342b1430aa183a375eec26115a437b3decb12a4c6a4a893ea16dd98c01d37fbbdc018801e98612 SHA256 (FreeBSD-11.0-RC1-arm-armv6-RPI2.img.xz) = d972e2802e86759ffb8714f432e6d05ba1d253a783b6dd2b7c2487dfdb06da6e o 11.0-RC1 armv6 PANDABOARD: SHA512 (FreeBSD-11.0-RC1-arm-armv6-PANDABOARD.img.xz) = 747acca3fb373558a954b18648b0e2018e4bdbd6296c1f419bbcf5916515a6a83a1fd598c3c9976412cf008efabaf8bf1bbf1f5bc9e03865e7cfabe3746f9210 SHA256 (FreeBSD-11.0-RC1-arm-armv6-PANDABOARD.img.xz) = 4fe2339a799951d978d87e5d214d4ad33876cc15070805263a5023b7b0da43bd o 11.0-RC1 armv6 WANDBOARD: SHA512 (FreeBSD-11.0-RC1-arm-armv6-WANDBOARD.img.xz) = d9f198fd236c293bc48057b9398cb5ac1b393eb0f430333313504bf910c772d36ef714143ae74682be2081828e0e86079ab958b7425a8dae6afd2f6cd08da9ae SHA256 (FreeBSD-11.0-RC1-arm-armv6-WANDBOARD.img.xz) = fd0d910932d1bc79448dd8f429d252796307aeb108020bb76a13ea88e760f026 o 11.0-RC1 aarch64 GENERIC: SHA512 (FreeBSD-11.0-RC1-arm64-aarch64-memstick.img) = aa9f9d0cd38b8b0c936d2181197468ee35aac0c3ecb2ae068c408d859e1d317a3f6a202766dec9dbb48e08373ca49d6eab6b49d551c7bc0a54a79e154391b74a SHA512 (FreeBSD-11.0-RC1-arm64-aarch64-memstick.img.xz) = e0d5553cd064ed58dd5ba79871b08e92311128da558feff7d2103aa21c4fe04176c1302ae39bf5f69f087d076a7081b3707cb6667d65cf1accd613640b9ae3c2 SHA512 (FreeBSD-11.0-RC1-arm64-aarch64-mini-memstick.img) = 90eaec8a96156f0b65caef06ee27b5da8cc3703fc791e54644ac4fc30cf9c44d2440c4165a928d66baa7d5377e227c9147ca31a6b5a1f543d335478bbd068778 SHA512 (FreeBSD-11.0-RC1-arm64-aarch64-mini-memstick.img.xz) = b528f8eb0d95dd20bb8d45f7596658eddfeee8cbb3aeaf3ca77c432838ac4027d045ce66e9c0810c1642a0c70f0dd363883e0e6963b0851dd89bbfce15af2f9e SHA256 (FreeBSD-11.0-RC1-arm64-aarch64-memstick.img) = f46779bf8ad37ba429f2d43bb76b3ba103e719270f384e86313b6b5a0ff52e6d SHA256 (FreeBSD-11.0-RC1-arm64-aarch64-memstick.img.xz) = 514f83d1e50c52a178345d0abc84529db720ad02ca662577d7e96949f30767b1 SHA256 (FreeBSD-11.0-RC1-arm64-aarch64-mini-memstick.img) = b9745208f836fbe6b52953b14a5cbebd84504d92cc4907f753e130b5f3a6ff62 SHA256 (FreeBSD-11.0-RC1-arm64-aarch64-mini-memstick.img.xz) = b54e88f3cf197e64fa9f60c76dd99f45c16e00578fe54d567738baf9aaea9fda == VM IMAGE CHECKSUMS == o 11.0-RC1 amd64: SHA512 (FreeBSD-11.0-RC1-amd64.qcow2.xz) = b29fd97285b4768181a84eceeed9ea57787f385e7cf33ae738314ea90ed209ef802802f3a9aa1b5a3e1a7c46b9100117c5a43c09da849bd291f02a3c183b4df2 SHA512 (FreeBSD-11.0-RC1-amd64.raw.xz) = d577ddef2045e0cfe8180a4b68e13b4dac7821ed49ea2bd7f2128eadfcc7beb2c957474702519c6d8899d18d3650e5094de65713f73e936f9387231d132ae2fe SHA512 (FreeBSD-11.0-RC1-amd64.vhd.xz) = a59e58aa308b1b1a80298d0cf1673a343c16e57872300d8dda692d0e4c21a0394a89ab48df9246c36eefd01d8c703405c619029c574c0ffa38c88cf4bed4b65d SHA512 (FreeBSD-11.0-RC1-amd64.vmdk.xz) = 3b68200a3ad860c7912c6264c69be4c8f7124ae47cf42f04c08e6e46fdfd79a9003f518fe64599b1cb9ca14cd9fb13340a3cc27694f19246a3c87cdc4b5c92d1 SHA256 (FreeBSD-11.0-RC1-amd64.qcow2.xz) = 3e32279b55e4c023032488fe13090c0c2f31fbddb80407c9cb5615c758c1507d SHA256 (FreeBSD-11.0-RC1-amd64.raw.xz) = 74eb82b5a75c2f339797b8a89f50c12a0d2abc40b6565796d75ef875a339b6bc SHA256 (FreeBSD-11.0-RC1-amd64.vhd.xz) = a940b084547a068aef7a3962e8e02ce5f859de3bae1e731da590d3a2e9cb3009 SHA256 (FreeBSD-11.0-RC1-amd64.vmdk.xz) = 684a7622460b1c840cbc62cf327070676b37c4792c12d933aac17e9e91305027 o 11.0-RC1 i386: SHA512 (FreeBSD-11.0-RC1-i386.qcow2.xz) = a10462400c590a8baa11c86a2300e1d6572e6937f9659c11012c88839467caa159af9c3e101a6ece3c0aae2a667891b833bb5899783db13c54a24e4cf0d6910d SHA512 (FreeBSD-11.0-RC1-i386.raw.xz) = 1937f10fe1b1d79b50fabc192b659469462b5ef394b401db7d84c611f9bcaf6b7e9f47b76e09321d544065064070d0b8ed98c0e05471eecfb62db28d105a1f6c SHA512 (FreeBSD-11.0-RC1-i386.vhd.xz) = 7980c1b9b2c0a4cf3dafbb5b35f549c696c7f239af73c1a906ee802e400ef801d7e94ec4a071e0074b01a39c4c13c8caf874dc37020ae3e0cc3893a486cfe33d SHA512 (FreeBSD-11.0-RC1-i386.vmdk.xz) = d05aff6ff3e6c75d09af819ab16f4447cc588a3ab1f7189cf40995e3c6edd67fda63fc3d498b7ce778bde3f7f14c91bdf84f258fd72bdb485c2680b7f7b63eff SHA256 (FreeBSD-11.0-RC1-i386.qcow2.xz) = 7bbf601ddfb861f35a7829b1ad4da74c59f88a84167a33a7b3d8e0ce76c60979 SHA256 (FreeBSD-11.0-RC1-i386.raw.xz) = fa8cdc1264622dc6e93b648bae9a6ca25a6f60734bc548c4a250db75fff3c87e SHA256 (FreeBSD-11.0-RC1-i386.vhd.xz) = 1706561a67caee4541444effc100d78c08330cf0ec768f39932af0448d2e85ac SHA256 (FreeBSD-11.0-RC1-i386.vmdk.xz) = 8994cbb907e7a6dbc27e1b8a7fc7a062182c1daa8fb0203df0fa5a4bfc2b0e7a o 11.0-RC1 aarch64: SHA512 (FreeBSD-11.0-RC1-arm64-aarch64.qcow2.xz) = df8730f7eb960101c8d8866479dc62b947f3a3948a2f2acf12156bdbed89ade6c39c3fecc626fc017cfeb0b7b3321264df7ae6c3be3c175d0cc2730b509b43fa SHA512 (FreeBSD-11.0-RC1-arm64-aarch64.raw.xz) = 1ea4fed48315b01a2deaca7a316e94d4be7e2fe8abeefe0b88e43529b497093def3cf0412433022044e382f81e0cec61b2b285552b038d05c2dace7142eaa084 SHA512 (FreeBSD-11.0-RC1-arm64-aarch64.vhd.xz) = 34b9aae1f465f2ddd77ba1e7b74851084d08da58217fab295b2b8d92de62048a0bf00a274df18fa21b4b4a75ef5062ad2aba28ef10e1887bacc4dc53f2ad3a22 SHA512 (FreeBSD-11.0-RC1-arm64-aarch64.vmdk.xz) = 188490bb83dc192b40e973102eaa66a9e62afe9544b4e4784f45306483bb6ac16bca6e113dbe7329478d854e0a1ffee601490ef675047e2f04739645fb2939c5 SHA256 (FreeBSD-11.0-RC1-arm64-aarch64.qcow2.xz) = 9af903c8091f2592ab42f9f2543960717da5eaca44dfd287cb3fec0c5383ec58 SHA256 (FreeBSD-11.0-RC1-arm64-aarch64.raw.xz) = bbb169fca5602622f28a751fa4dd86457853b721f68002004b8da2f50f6bc9cf SHA256 (FreeBSD-11.0-RC1-arm64-aarch64.vhd.xz) = acc3600525299ac69d725c98e031fa97448aa891f007f6387780cd22351f9c2f SHA256 (FreeBSD-11.0-RC1-arm64-aarch64.vmdk.xz) = 3be80fd295e3c71dd32a5ed45460aaddaf3a6bcab45823df3d25aea0608afe16 Regards, Glen Love FreeBSD? Support this and future releases with a donation to the FreeBSD Foundation! https://www.freebsdfoundation.org/donate/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXrnhQAAoJEAMUWKVHj+KTSIAP/30a9B45IaaleMOCKtjBQEc0 oTnzhBwXQLGB4ODvyHiroQu/QvU+Rm5LP7UV8nDX522NA+3gzc84dvm3n5vwhNAf j453zZujcvoZ/OT4D+8FUBOcRLGHd9MxL5tj9X1bqcvJlnTnPMjRxDjWVLaGGRaH dBCJhl4pMuqLDkR4zEnnw+pna7yf0pWcwftw8PQnQgjwB2VhV48YkxUk4E3kQepj H1Vt82LzljvFoEYBFv4wtUALEqYLhHChkoz2GxIQyCI7vX1r91yRqISdbkBhu6HP zeNnp8sua1YzgR4fvHHDyISYG9JM04ZfEQhGkGQrHgbRJX87Erq3oWE10r0gKqNJ SJZWuNn+oofWP1rA2Q7AqoManFDEpZPdmtuQUoAuanugkqTiUrW+PIQmgzVNo+lD mAwnpgTsef3b46fKJNcvQEzp4tf+VHsb5z33WL6Kbf/oaW56dFA7a4Tz97ege0ku n9y7Mm3vNfm87v5zr8geGzaSaoa9WL7+8WhFDU+3cPWrlenSksJgCEy0bXznRNzl zu9cOrA63W3w7pndb8YYSjFxSp3V7heS7UCA8CgVA/2QDMLW5yabsDjVh6rWLhAR MmWhM1VT/HqohGuivGIW4TksIVHK3i/lFLi4jQsDeAq3ao3XyWeCJ0LK+AnlXxA7 Oc+ItprI+s+1J/0LIv6M =hIev -----END PGP SIGNATURE----- From owner-freebsd-current@freebsd.org Sat Aug 13 06:35:39 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 702D5BB8933; Sat, 13 Aug 2016 06:35:39 +0000 (UTC) (envelope-from gjb@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 611B511E2; Sat, 13 Aug 2016 06:35:39 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id BF4FB1A79; Sat, 13 Aug 2016 06:35:38 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Sat, 13 Aug 2016 06:35:37 +0000 From: Glen Barber To: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, freebsd-snapshots@FreeBSD.org Cc: FreeBSD Release Engineering Team Subject: [REVISED] Re: FreeBSD 11.0-RC1 Now Available Message-ID: <20160813063537.GX11079@FreeBSD.org> References: <20160813013056.GS11079@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="07KgZKBWke2i7lgQ" Content-Disposition: inline In-Reply-To: <20160813013056.GS11079@FreeBSD.org> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 13 Aug 2016 06:35:39 -0000 --07KgZKBWke2i7lgQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 13, 2016 at 01:30:56AM +0000, Glen Barber wrote: > o OpenSSH DSA keys have been disabled by default. Users upgrading from > prior FreeBSD versions are urged to update their SSH keys to DSA or > ECDSA keys before upgrading to 11.0-RC1. >=20 Note, this should have suggested to update SSH keys to RSA or ECDSA, not DSA or ECDSA. Apologies for any confusion. Glen --07KgZKBWke2i7lgQ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXrr+5AAoJEAMUWKVHj+KTUL4P/0u0AszhmsbIGU/VzQikQRSo kBZJF+88pyeGHJ7mto4lPB57zqihapCZfL7F76cmSn+xJuijGa/5csHgtkwkS+Kb v7vT+i0hqNRz+Y1mV4I7ncUXjKvgfa4OxU1ks8mGWkFkBvBwalLHnc2Ki2ZU26zQ HtMlhjRuyLJI4aozMi3pi3kADeebjxBhbx+AsXK0jFHx/F78Cn3T9CMXH944Evk9 pFYQsq40bWTITRER5/Hq7lKRiRyuO4vEklEUyapqge5YuEVOxhcRk2eoUNW+dVTL iWWcVrMkpv0WtvOQemrhaqe2oijc/8CUvFAjZu3KfwxsheNGv7V7Im9zbPOTAZrg Ot5NMpZymrIBXl5V3glJ2LuoVMhBy8S+0JKxZUABPMyW1m91bjg5cc5puzJuujuI nSCmbgjrntfpeQqUjhna7ry/8ds+blBJ5jPP9fJ/bvWpqHpDMCZ0PBGtOXdJwPgU P9X97AOm5IWjMpT578wrOCBVeP3H0angagGMzk2IoxvS0v3Jju219Gh1fLvaCfFM wVkmVaWFRSq26WJdvxDm927ftmWElc9aW5l/jW8ZhSnYRCKOTLU4P0ZZCGIYCjTQ queoX3DCiv6nwnCgl/CsjPu8oBti+Ri9EKFcq9cQqeu2YJBUzoEZUSF7ZgyQGY/G oizNVHppRKM2+/HcGDnm =a7ui -----END PGP SIGNATURE----- --07KgZKBWke2i7lgQ-- From owner-freebsd-current@freebsd.org Sat Aug 13 07:26:30 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 879DABB8258 for ; Sat, 13 Aug 2016 07:26:30 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7AD381696 for ; Sat, 13 Aug 2016 07:26:30 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1471073181901813.6290259503966; Sat, 13 Aug 2016 00:26:21 -0700 (PDT) Date: Sat, 13 Aug 2016 00:26:21 -0700 From: Matthew Macy To: "Lundberg, Johannes" Cc: "FreeBSD Current" Message-ID: <15682cb6097.af30fe2f123452.8740060224087388607@nextbsd.org> In-Reply-To: References: Subject: Re: Wayland work status MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 13 Aug 2016 07:26:30 -0000 >=20 > =E2=80=8BWayland relies on kqueue which is not implemented in drm's 3.8 = or 4.6 > branches. I'm working on this now for drm-next-4.6 and it is almost > complete. > I will probably implement it also in the 3.8 =E2=80=8Bbranch to be able = to run > Wayland on both to compare and find bugs in linuxkpi more easily. Will > share patch for 3.8 branch when done. >=20 drm-next has working kevent support following shortly after the drm-v4.7 ta= g. Your kqfilter implementation would be ideal for 3.8 but is not suitable = for drm-next as it substantially modifies vendor code. I think your impleme= ntation does in fact work or is very close. Your apparent problem stemmed f= rom an index overwrite in your modified kmscube.c test case. A working kmscube.c can be found at: https://github.com/FreeBSDDesktop/kmscube With no arguments it will use select. If you pass -k it will use kevent. -M From owner-freebsd-current@freebsd.org Sat Aug 13 13:54:07 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D8C49BB8541 for ; Sat, 13 Aug 2016 13:54:07 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [202.12.127.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protected-networks.net", Issuer "Protected Networks CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AB0501F4D; Sat, 13 Aug 2016 13:54:07 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding:content-type :content-type:mime-version:user-agent:date:date:message-id :subject:subject:from:from; s=201508; t=1471096444; bh=14ulMt12v Du/I5qViK6+GER1o1bm0CJ97sJVDNAyz4E=; b=S1eSk0zcLxMyRApp7C7R7eDTA wHxAgrF87c//LIcMFyZC6BrN15TmlUb0Q6D2ENuMWuqH7a/tWA84UWTs2hX+S/IT wakpMvWI0mrlaVw82zTw+y078n9Y5R6H0fnJmP2Iogfsq7st0iwAeDMkRoV1af8X 5zG3BDtwwlg4gGyNF8= Received: from toshi.auburn.protected-networks.net (gw.auburn.protected-networks.net [192.168.1.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id 0792D6095; Sat, 13 Aug 2016 09:54:04 -0400 (EDT) To: freebsd-current Cc: rmacklem@freebsd.org From: Michael Butler Subject: build fails post SVN r304026 Openpgp: id=6F63E6399DCC8E3E94D60F0642FF6BAE0442D492 Message-ID: <2699323b-54dc-b994-354a-00531f5f63b4@protected-networks.net> Date: Sat, 13 Aug 2016 09:54:02 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.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.22 Precedence: 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, 13 Aug 2016 13:54:07 -0000 Is anyone else seeing this? ===> usr.bin/nfsstat (all) Building /usr/obj/usr/src/usr.bin/nfsstat/nfsstat.o /usr/src/usr.bin/nfsstat/nfsstat.c:301:4: error: array index 72 is past the end of the array (which contains 49 elements) [-Werror,-Warray-bounds] ext_nfsstats.srvrpccnt[NFSV4OP_SYMLINK], ^ ~~~~~~~~~~~~~~~ /usr/obj/usr/src/tmp/usr/include/fs/nfs/nfsport.h:457:2: note: array 'srvrpccnt' declared here int srvrpccnt[NFSV4OP_NOPS + NFSV4OP_FAKENOPS]; ^ /usr/src/usr.bin/nfsstat/nfsstat.c:302:4: error: array index 73 is past the end of the array (which contains 49 elements) [-Werror,-Warray-bounds] ext_nfsstats.srvrpccnt[NFSV4OP_MKDIR], ^ ~~~~~~~~~~~~~ /usr/obj/usr/src/tmp/usr/include/fs/nfs/nfsport.h:457:2: note: array 'srvrpccnt' declared here int srvrpccnt[NFSV4OP_NOPS + NFSV4OP_FAKENOPS]; ^ /usr/src/usr.bin/nfsstat/nfsstat.c:303:4: error: array index 74 is past the end of the array (which contains 49 elements) [-Werror,-Warray-bounds] ext_nfsstats.srvrpccnt[NFSV4OP_RMDIR], ^ ~~~~~~~~~~~~~ /usr/obj/usr/src/tmp/usr/include/fs/nfs/nfsport.h:457:2: note: array 'srvrpccnt' declared here int srvrpccnt[NFSV4OP_NOPS + NFSV4OP_FAKENOPS]; [ .. ] imb From owner-freebsd-current@freebsd.org Sat Aug 13 14:00:46 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ACF96BB876C for ; Sat, 13 Aug 2016 14:00:46 +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 DB7EC12C1; Sat, 13 Aug 2016 14:00:43 +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 u7DE0RcS058325; Sat, 13 Aug 2016 14:00:27 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id u7DE0RpF058324; Sat, 13 Aug 2016 07:00:27 -0700 (PDT) (envelope-from david) Date: Sat, 13 Aug 2016 07:00:27 -0700 From: David Wolfskill To: Michael Butler Cc: freebsd-current , rmacklem@freebsd.org Subject: Re: build fails post SVN r304026 Message-ID: <20160813140027.GQ1112@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Michael Butler , freebsd-current , rmacklem@freebsd.org References: <2699323b-54dc-b994-354a-00531f5f63b4@protected-networks.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="K3awxsxIuSNw2oFG" Content-Disposition: inline In-Reply-To: <2699323b-54dc-b994-354a-00531f5f63b4@protected-networks.net> User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 13 Aug 2016 14:00:46 -0000 --K3awxsxIuSNw2oFG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 13, 2016 at 09:54:02AM -0400, Michael Butler wrote: > Is anyone else seeing this? >=20 > =3D=3D=3D> usr.bin/nfsstat (all) > Building /usr/obj/usr/src/usr.bin/nfsstat/nfsstat.o > /usr/src/usr.bin/nfsstat/nfsstat.c:301:4: error: array index 72 is past > the end of the array (which contains 49 elements) [-Werror,-Warray-bounds] > ext_nfsstats.srvrpccnt[NFSV4OP_SYMLINK], > .... I am, as of r304040 (src upgrading from r304004), yes. 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. --K3awxsxIuSNw2oFG Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJXryf7XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XUqUH+wVFJW/9U92W8j369t1GVCzW 6UZyHaW3VjkmFET2BDShUCSWJLXtsc8eYR51vCdzKVNH2E6iNXTLkaMh2DYDy/s9 H4vk8TaNTrYsM/pxgpW47McdGDzH6aVRPeZ9BwygD/SNZoAANvMmf20fMkwpNwAP vCplwTtjL5czikf80xOX32ey1QNc4SVYS2AQUhI0oTNhepqebs4Fq6v5wtM5BflJ JNx6UcOt4Lu0/CcRZHi3HSAz86ETERn4878pKSPtPQmvDi9+5Gna+J7WHRfCu9+X rKUXJgiLVC0+1g0Pdj5rGvV99nndpk/GlA8tBtKv3o42AidMynF379feuO1CvNM= =O9tB -----END PGP SIGNATURE----- --K3awxsxIuSNw2oFG-- From owner-freebsd-current@freebsd.org Sat Aug 13 14:17:37 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C0DAEBB89EE for ; Sat, 13 Aug 2016 14:17:37 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:201:6350::2]) by mx1.freebsd.org (Postfix) with ESMTP id 890C2192C for ; Sat, 13 Aug 2016 14:17:37 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [IPv6:2001:470:923f:2:a976:d7ad:b132:8c3d] (unknown [IPv6:2001:470:923f:2:a976:d7ad:b132:8c3d]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id EFC9BBAF for ; Sat, 13 Aug 2016 17:17:34 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: build fails post SVN r304026 References: <2699323b-54dc-b994-354a-00531f5f63b4@protected-networks.net> To: freebsd-current@freebsd.org From: Lev Serebryakov Organization: FreeBSD Message-ID: <57AF2BFA.9070802@FreeBSD.org> Date: Sat, 13 Aug 2016 17:17:30 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <2699323b-54dc-b994-354a-00531f5f63b4@protected-networks.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UW1e3d8t475G5ngNMqJxcA7FK1gFwjPFW" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 13 Aug 2016 14:17:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UW1e3d8t475G5ngNMqJxcA7FK1gFwjPFW Content-Type: multipart/mixed; boundary="uHHMMVN0gbleLwuM0BCH7HVOr7E1DrHPQ" From: Lev Serebryakov Reply-To: lev@FreeBSD.org To: freebsd-current@freebsd.org Message-ID: <57AF2BFA.9070802@FreeBSD.org> Subject: Re: build fails post SVN r304026 References: <2699323b-54dc-b994-354a-00531f5f63b4@protected-networks.net> In-Reply-To: <2699323b-54dc-b994-354a-00531f5f63b4@protected-networks.net> --uHHMMVN0gbleLwuM0BCH7HVOr7E1DrHPQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 13.08.2016 16:54, Michael Butler wrote: > Is anyone else seeing this? Yes, I've posted message to fs@, as it is r304026 for sure (and author was CC:ed too). --=20 // Lev Serebryakov AKA Black Lion --uHHMMVN0gbleLwuM0BCH7HVOr7E1DrHPQ-- --UW1e3d8t475G5ngNMqJxcA7FK1gFwjPFW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJXrywAXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EeP5EQP/3Ic2JW23o3L4bV7qhyLSPi9 fSBI7uZDVaJxVhYxZ/nbKxjL75QW7BBdIxHHpvKympgnnWzx8PTxFaXgJGEWTq6M eaRIeB3DznSlia+C1xCXjpBOi4m65Ri4X8G5trJYRaX+Ef7eibw6aLtt1wkMD7/+ RW6OcNLxDp1Yg3qXwnF2m4YFuvCpCtmLy0BvsnVFRAJrr6MyaLlLp9aEhFD9Ebdd OSPLh/ZjuqsqhqLcq0MwbfambtFYb+S98nXayaHAYyJ4SW/aZv4nEYCg3e1bDQLJ PbiDY61ncCcLsA/UFI82j47KstF+9H0Ed9RV4s2ltJvOu+5Yjn8Ni22EqKBQNqw9 t2Yn754lYH2QqLVO7/DRw5lzyVLiD8JXBky2ANHTWdI8oeURMF9D9IFdl1XqpIkz YukDs3fLY5snBeFl9PXfB/TvOPIxzhbpY+bWx+UDPTF9XOuouhNKCT5Sq1U4k5YD SYeAWbP7a07CxJtzfqc9eBNRJc2sNd2plsbfdCBnP2kMkgKybYYUIfS1FMl9l4VW lr1aanLohISNeMdz0wen5sZ1NIyvnTvCJPfHjCyO505xaP2Tol4HJwc+F78eCBQw o0TixhL36Wbo93uyYQaN+H3Zzrqkoz6Klvb+p4RMp1oH4xnoZkMLJtB77YXigl/L sIe59Ve69yOW8Yb5tEGW =oKpL -----END PGP SIGNATURE----- --UW1e3d8t475G5ngNMqJxcA7FK1gFwjPFW-- From owner-freebsd-current@freebsd.org Sat Aug 13 17:15:28 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3DA42BB87B8 for ; Sat, 13 Aug 2016 17:15:28 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::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 F2A2A1A6B for ; Sat, 13 Aug 2016 17:15:27 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: by mail-ua0-x233.google.com with SMTP id 97so22738706uav.3 for ; Sat, 13 Aug 2016 10:15:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brilliantservice-co-jp.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Nin0QOL2JxjF7mqA5+gPWcGvx37+ricY+CNqgjIuz3g=; b=eOwQIGbpZwh7JnneqM2kPv4BjMrrxf6q8I8EMWof3iYg02GUNccsMocbyRCsGRNxOs JAyiDMbnuaC6zxjSmx9aERAE2DolrmaldrjofAjeGkZ1OhkUccu+b5BTpfOOF95am25s xm3bTg1ygLv1A4KrDwtpa+3uLnJMF4ZAy02wyE3j/kHG1u22tJ/r2mA50TgtyUiP4txo LUb79Wl7frBZhZ+9QWUZqvnBfUQmXYQi3MuBP97/IG+JggZq5VJEKNJqbyXGeLA7wk3W RC7O92kOy3tu9XSVu13tO7sqZqTCEeeinm7lwsmf+LPUnZUVvB3vi/7RzF2YdaNrsG55 an/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Nin0QOL2JxjF7mqA5+gPWcGvx37+ricY+CNqgjIuz3g=; b=J31iyu/sYlqc7sDOcx0ZkjnAsERb0nkPCk30PZ4og04pYWZMjYN/lV/T4uXUz7n+nY bd0oCVb+SX5n71etbykN8NbYC0g2eOhFBpxLaNDxo+iLtU6VQywY0NEyyOpHxj+FspX6 XTvROOXYTpRYRXc/UCHpfWsGF8E6GP5AKNnbNdWng5l2CN7jhGgW5P7RXIO+3IdNoM7w ydKl4gVaOOetK4eF3aQ+R/sIs41Av1nJWa4Kp/J9/hjhWedXxDPdLHT+YAFbcfSVs86r WTl4HLUbonbQ0U5/YqYJM3VfsikhSUqF0bCGIJzmKxAne8+JOyW20lBwAxwmQR6MKlm6 penw== X-Gm-Message-State: AEkooutZnmFqd0mkXOo1V1MUxbhbyo/Pfe3EzaY3BC8ECsj6iH+utKj5yU7kOGowRhMTfZLLC/FDA2sGYtcXAI9X8F1wg6z1/DcAglgt/ixs905jx/DINWiEWQ+Y4sJ4xwGG/6UPM475Vi2aeBJApvwSihw= X-Received: by 10.31.75.2 with SMTP id y2mr8407716vka.130.1471108527048; Sat, 13 Aug 2016 10:15:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.7.33 with HTTP; Sat, 13 Aug 2016 10:15:11 -0700 (PDT) In-Reply-To: <15682cb6097.af30fe2f123452.8740060224087388607@nextbsd.org> References: <15682cb6097.af30fe2f123452.8740060224087388607@nextbsd.org> From: "Lundberg, Johannes" Date: Sat, 13 Aug 2016 10:15:11 -0700 Message-ID: Subject: Re: Wayland work status To: Matthew Macy Cc: FreeBSD Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 13 Aug 2016 17:15:28 -0000 VGhhbmtzIGZvciB0aGUgaGVscCBNYXR0aGV3Li4NClllYWgsIEkgY2FuJ3QgYmVsaWV2ZSBpdCB3 YXMgd29ya2luZyBhbGwgYWxvbmcgYW5kIGEgc3R1cGlkIGNvcHkvcGFzdGUNCmVycm9yIGdhdmUg dXMgc28gbXVjaCB0cm91YmxlLi4uDQoNCk9uIFNhdCwgQXVnIDEzLCAyMDE2IGF0IDEyOjI2IEFN LCBNYXR0aGV3IE1hY3kgPG1tYWN5QG5leHRic2Qub3JnPiB3cm90ZToNCg0KPg0KPiAgPg0KPiAg PiDigItXYXlsYW5kIHJlbGllcyBvbiBrcXVldWUgd2hpY2ggaXMgbm90IGltcGxlbWVudGVkIGlu IGRybSdzIDMuOCBvciA0LjYNCj4gID4gYnJhbmNoZXMuIEknbSB3b3JraW5nIG9uIHRoaXMgbm93 IGZvciBkcm0tbmV4dC00LjYgYW5kIGl0IGlzIGFsbW9zdA0KPiAgPiBjb21wbGV0ZS4NCj4gID4g SSB3aWxsIHByb2JhYmx5IGltcGxlbWVudCBpdCBhbHNvIGluIHRoZSAzLjgg4oCLYnJhbmNoIHRv IGJlIGFibGUgdG8gcnVuDQo+ICA+IFdheWxhbmQgb24gYm90aCB0byBjb21wYXJlIGFuZCBmaW5k IGJ1Z3MgaW4gbGludXhrcGkgbW9yZSBlYXNpbHkuIFdpbGwNCj4gID4gc2hhcmUgcGF0Y2ggZm9y IDMuOCBicmFuY2ggd2hlbiBkb25lLg0KPiAgPg0KPg0KPiBkcm0tbmV4dCBoYXMgd29ya2luZyBr ZXZlbnQgc3VwcG9ydCBmb2xsb3dpbmcgc2hvcnRseSBhZnRlciB0aGUgZHJtLXY0LjcNCj4gdGFn LiBZb3VyIGtxZmlsdGVyIGltcGxlbWVudGF0aW9uIHdvdWxkIGJlIGlkZWFsIGZvciAzLjggYnV0 IGlzIG5vdA0KPiBzdWl0YWJsZSBmb3IgZHJtLW5leHQgYXMgaXQgc3Vic3RhbnRpYWxseSBtb2Rp ZmllcyB2ZW5kb3IgY29kZS4gSSB0aGluaw0KPiB5b3VyIGltcGxlbWVudGF0aW9uIGRvZXMgaW4g ZmFjdCB3b3JrIG9yIGlzIHZlcnkgY2xvc2UuIFlvdXIgYXBwYXJlbnQNCj4gcHJvYmxlbSBzdGVt bWVkIGZyb20gYW4gaW5kZXggb3ZlcndyaXRlIGluIHlvdXIgbW9kaWZpZWQga21zY3ViZS5jIHRl c3QNCj4gY2FzZS4NCj4NCj4gQSB3b3JraW5nIGttc2N1YmUuYyBjYW4gYmUgZm91bmQgYXQ6DQo+ DQo+IGh0dHBzOi8vZ2l0aHViLmNvbS9GcmVlQlNERGVza3RvcC9rbXNjdWJlDQo+DQo+IFdpdGgg bm8gYXJndW1lbnRzIGl0IHdpbGwgdXNlIHNlbGVjdC4gSWYgeW91IHBhc3MgLWsgaXQgd2lsbCB1 c2Uga2V2ZW50Lg0KPiAtTQ0KPg0KPg0KCi0tIAo9LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0t PS09LT0tPS09LT0tPS09LT0tPS09LT0tPS0K56eY5a+G5L+d5oyB44Gr44Gk44GE44Gm77ya44GT 44Gu6Zu75a2Q44Oh44O844Or44Gv44CB5ZCN5a6b5Lq644Gr6YCB5L+h44GX44Gf44KC44Gu44Gn 44GC44KK44CB56eY5Yy/54m55qip44Gu5a++6LGh44Go44Gq44KL5oOF5aCx44KS5ZCr44KT44Gn 44GE44G+44GZ44CCCuOCguOBl+OAgeWQjeWum+S6uuS7peWkluOBruaWueOBjOWPl+S/oeOBleOC jOOBn+WgtOWQiOOAgeOBk+OBruODoeODvOODq+OBruegtOajhOOAgeOBiuOCiOOBs+OBk+OBruOD oeODvOODq+OBq+mWouOBmeOCi+S4gOWIh+OBrumWi+ekuuOAgQropIflhpnjgIHphY3luIPjgIHj gZ3jga7ku5bjga7liKnnlKjjgIHjgb7jgZ/jga/oqJjovInlhoXlrrnjgavln7rjgaXjgY/jgYTj gYvjgarjgovooYzli5XjgoLjgZXjgozjgarjgYTjgojjgYbjgYrpoZjjgYTnlLPjgZfkuIrjgZLj gb7jgZnjgIIKLS0tCkNPTkZJREVOVElBTElUWSBOT1RFOiBUaGUgaW5mb3JtYXRpb24gaW4gdGhp cyBlbWFpbCBpcyBjb25maWRlbnRpYWwKYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJl c3NlZS4KRGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIGFueSBvdGhlciBhY3Rp b24gb2YgdXNlIG9mIHRoaXMKZW1haWwgYnkgcGVyc29uIG90aGVyIHRoYW4gaW50ZW5kZWQgcmVj aXBpZW50LCBpcyBwcm9oaWJpdGVkLgpJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50IGFuZCBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4KZXJyb3IsIHBsZWFzZSBkZXN0cm95 IHRoZSBvcmlnaW5hbCBtZXNzYWdlLgo= From owner-freebsd-current@freebsd.org Sat Aug 13 17:42:55 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3CA01BB82D0 for ; Sat, 13 Aug 2016 17:42:55 +0000 (UTC) (envelope-from jbeich@vfemail.net) Received: from vfemail.net (onethreetwo.vfemail.net [199.16.11.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D6CA61A38 for ; Sat, 13 Aug 2016 17:42:54 +0000 (UTC) (envelope-from jbeich@vfemail.net) Received: (qmail 39880 invoked by uid 89); 13 Aug 2016 17:36:13 -0000 Received: from localhost (HELO freequeue.vfemail.net) (127.0.0.1) by localhost with (DHE-RSA-AES256-SHA encrypted) SMTP; 13 Aug 2016 17:36:13 -0000 Received: (qmail 39783 invoked by uid 89); 13 Aug 2016 17:35:55 -0000 Received: by simscan 1.3.1 ppid: 39777, pid: 39780, t: 0.0033s scanners:none Received: from unknown (HELO smtp102-2.vfemail.net) (172.16.100.62) by FreeQueue with SMTP; 13 Aug 2016 17:35:55 -0000 Received: (qmail 11410 invoked by uid 89); 13 Aug 2016 17:35:55 -0000 Received: by simscan 1.4.0 ppid: 11384, pid: 11404, t: 0.9579s scanners:none Received: from unknown (HELO nil) (amJlaWNoQHZmZW1haWwubmV0@172.16.100.27) by mail.vfemail.net with ESMTPA; 13 Aug 2016 17:35:55 -0000 From: Jan Beich To: Glen Barber Cc: freebsd-current@FreeBSD.org, FreeBSD Release Engineering Team Subject: Re: FreeBSD 11.0-RC1 Now Available References: <20160813013056.GS11079@FreeBSD.org> Date: Sat, 13 Aug 2016 19:35:45 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Mailman-Approved-At: Sat, 13 Aug 2016 18:19:17 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 13 Aug 2016 17:42:55 -0000 --=-=-= Content-Type: text/plain Glen Barber writes: > The first RC build of the 11.0-RELEASE release cycle is now available. > > Installation images are available for: > > o 11.0-RC1 amd64 GENERIC > o 11.0-RC1 i386 GENERIC > o 11.0-RC1 powerpc GENERIC > o 11.0-RC1 powerpc64 GENERIC64 > o 11.0-RC1 sparc64 GENERIC > o 11.0-RC1 armv6 BANANAPI > o 11.0-RC1 armv6 BEAGLEBONE > o 11.0-RC1 armv6 CUBIEBOARD > o 11.0-RC1 armv6 CUBIEBOARD2 > o 11.0-RC1 armv6 CUBOX-HUMMINGBOARD > o 11.0-RC1 armv6 GUMSTIX > o 11.0-RC1 armv6 RPI-B > o 11.0-RC1 armv6 RPI2 > o 11.0-RC1 armv6 PANDABOARD > o 11.0-RC1 armv6 WANDBOARD > o 11.0-RC1 aarch64 GENERIC What about granular sets? sparc64 is N/A while amd64 is missing lib32.txz, src.txz, ports.txz, tests.txz. Regressed since 11.0-BETA4. I've waited a day to see if the issue would disappear after mirrors catch up but no joy, even via Tor. $ poudriere jail -cj 110amd64 -a amd64 -v 11.0-RC1 [00:00:01] ====>> Creating 110amd64 fs... done [00:00:01] ====>> Fetching MANIFEST for FreeBSD 11.0-RC1 amd64 /poudriere/jails/110amd64/fromftp/MANIFEST 100% of 1157 B 21 MBps 00m00s [00:00:02] ====>> Fetching base.txz for FreeBSD 11.0-RC1 amd64 /poudriere/jails/110amd64/fromftp/base.txz 100% of 95 MB 3554 kBps 00m27s [00:00:30] ====>> Extracting base.txz... done [00:00:37] ====>> Fetching src.txz for FreeBSD 11.0-RC1 amd64 fetch: https://download.FreeBSD.org/ftp/releases/amd64/amd64/11.0-RC1/src.txz: Not Found fetch: https://download.FreeBSD.org/ftp/releases/amd64/amd64/11.0-RC1/src.txz: Not Found [00:00:37] ====>> Error: Failed to fetch from https://download.FreeBSD.org/ftp/releases/amd64/amd64/11.0-RC1/src.txz [00:00:37] ====>> Error while creating jail, cleaning up. [00:00:37] ====>> Removing 110amd64 jail... done $ poudriere jail -cj 110sparc64 -a sparc64 -v 11.0-RC1 [00:00:00] ====>> Creating 110sparc64 fs... done [00:00:00] ====>> Fetching MANIFEST for FreeBSD 11.0-RC1 sparc64 fetch: https://download.FreeBSD.org/ftp/releases/sparc64/sparc64/11.0-RC1/MANIFEST: Forbidden fetch: https://download.FreeBSD.org/ftp/releases/sparc64/sparc64/11.0-RC1/MANIFEST: Forbidden [00:00:00] ====>> Error: Failed to fetch from https://download.FreeBSD.org/ftp/releases/sparc64/sparc64/11.0-RC1/MANIFEST [00:00:00] ====>> Error while creating jail, cleaning up. [00:00:00] ====>> Removing 110sparc64 jail... done --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQF8BAEBCgBmBQJXr1pxXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXREQjQ0MzY3NEM3RDIzNTc4NkUxNDkyQ0VF NEM3Nzg4MzQ3OURCRERCAAoJEOTHeINHnb3bfqEH/RbnvkHlkgJAuMvbShi/pNTf DZmbIUqz3zQGmYSMb/bsLbVotMbCRi+xKQnFVCEFgk2BvDnlTcv5XyM0Z+dKLIyg Vb1Bq7XqTu9/dNFbYRqioljPAzdR1hoSkSghqB3RirBBAKWEVaSqLgr7jWf1lv68 hDGE+Hrjxoihg7COvMsr/n/eUCNTmdkaMHM83/HiLXpnAIwWGcRMpqpUz/OMqP4R d/kiC9E/Bn0SCY65A4QANX2seCjR7wcCEGpix6/Vj4ydBTgfXTELQ8f0h4+cMAdU lAxH5YtTOLlGQo6Z5AhvRGvrWsZ1mSDUba7d5gLRMD1fx7M+IEbwgzFWQv5idc4= =sg1j -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-current@freebsd.org Sat Aug 13 20:47:53 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5EC0BBB627E for ; Sat, 13 Aug 2016 20:47:53 +0000 (UTC) (envelope-from gjb@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 4FEE916BE; Sat, 13 Aug 2016 20:47:53 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id 07639195B; Sat, 13 Aug 2016 20:47:52 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Sat, 13 Aug 2016 20:47:52 +0000 From: Glen Barber To: Jan Beich Cc: freebsd-current@FreeBSD.org, FreeBSD Release Engineering Team Subject: Re: FreeBSD 11.0-RC1 Now Available Message-ID: <20160813204752.GB11079@FreeBSD.org> References: <20160813013056.GS11079@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Ca0e2zgpnh8/XhnM" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 13 Aug 2016 20:47:53 -0000 --Ca0e2zgpnh8/XhnM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 13, 2016 at 07:35:45PM +0200, Jan Beich wrote: > Glen Barber writes: >=20 > > The first RC build of the 11.0-RELEASE release cycle is now available. > > > > Installation images are available for: > > > > o 11.0-RC1 amd64 GENERIC > > o 11.0-RC1 i386 GENERIC > > o 11.0-RC1 powerpc GENERIC > > o 11.0-RC1 powerpc64 GENERIC64 > > o 11.0-RC1 sparc64 GENERIC > > o 11.0-RC1 armv6 BANANAPI > > o 11.0-RC1 armv6 BEAGLEBONE > > o 11.0-RC1 armv6 CUBIEBOARD > > o 11.0-RC1 armv6 CUBIEBOARD2 > > o 11.0-RC1 armv6 CUBOX-HUMMINGBOARD > > o 11.0-RC1 armv6 GUMSTIX > > o 11.0-RC1 armv6 RPI-B > > o 11.0-RC1 armv6 RPI2 > > o 11.0-RC1 armv6 PANDABOARD > > o 11.0-RC1 armv6 WANDBOARD > > o 11.0-RC1 aarch64 GENERIC >=20 > What about granular sets? sparc64 is N/A while amd64 is missing > lib32.txz, src.txz, ports.txz, tests.txz. Regressed since 11.0-BETA4. > I've waited a day to see if the issue would disappear after mirrors > catch up but no joy, even via Tor. >=20 > [...] Thanks for letting us know. This isn't an re@ issue, it's an admins@ issue, and we thought this was fixed. Give me a bit to investigate. Glen --Ca0e2zgpnh8/XhnM Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXr4d4AAoJEAMUWKVHj+KTT3oP/3W/Z0HRTTWftdHCxtBzamS5 syr8VDD133t56JuC6/qOaH627mEu9kIzVR7NuTwFNze6oKHvSQdXPc2w0Zd4WFlf P9kAZ+SqcL/UmnLSCvp0vPzPA4iF1+uv3KKkx7rf522p0ydYWJhTmM6kXFcp63up namUOz58QMpst6qUPbfFrRpnHrWf45qUyhJTEGsAK8CLoRzfYs3CdY7LaQmpUb6E 9SXR3XE4A3EapD51jCHK+ZopaOQoeo4cdY13MAJWviE6FYUWPdQuHrv+DpUEBHYb jCu9wiZpyIFYM2DycPMNhPNpbY4eGaBe+yZIrmgEqDUkke7UY3Lm7tVDk422II9F 3JP4+YkbeqTQi8Q2kRALZW06l79vJlWXeEN4NMlf2sTxFjhPkHoF5xY9Rg+LL5Z7 PFu3rTUL4sgYW0g4V0rLvAlLP2UzA4NYQKwmj1+3Nx0w9+3o8YM8kV9GdUpVSv12 gVMlw3TXvdhW1Y9gvnh/hD64QnPRRwFZj/w5lYdjn8OE48fOUYf/p1plr+wY80Lq QejUOQOUrq4qlA7kPzxkEgkf1MPqu/KyQmedxsDySQEJEhH45NSwmSsE6wql08Dn CoSJaeum3ZY3DFNJ5aX0s50PReiinppEHdUF8olv7mX2Ad8JHQewlxz9qxPirM6q 0itWRaDgidr/6QrPnw3D =3O1M -----END PGP SIGNATURE----- --Ca0e2zgpnh8/XhnM-- From owner-freebsd-current@freebsd.org Sat Aug 13 21:30:12 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4064CBB6D6B for ; Sat, 13 Aug 2016 21:30:12 +0000 (UTC) (envelope-from gjb@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 30A2118D6; Sat, 13 Aug 2016 21:30:12 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id C7D821FC4; Sat, 13 Aug 2016 21:30:11 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Sat, 13 Aug 2016 21:30:10 +0000 From: Glen Barber To: Jan Beich Cc: freebsd-current@FreeBSD.org, FreeBSD Release Engineering Team Subject: Re: FreeBSD 11.0-RC1 Now Available Message-ID: <20160813213010.GC11079@FreeBSD.org> References: <20160813013056.GS11079@FreeBSD.org> <20160813204752.GB11079@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZilngB4jitXEoqOO" Content-Disposition: inline In-Reply-To: <20160813204752.GB11079@FreeBSD.org> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 13 Aug 2016 21:30:12 -0000 --ZilngB4jitXEoqOO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 13, 2016 at 08:47:52PM +0000, Glen Barber wrote: > On Sat, Aug 13, 2016 at 07:35:45PM +0200, Jan Beich wrote: > > Glen Barber writes: > >=20 > > > The first RC build of the 11.0-RELEASE release cycle is now available. > > > > > > Installation images are available for: > > > > > > o 11.0-RC1 amd64 GENERIC > > > o 11.0-RC1 i386 GENERIC > > > o 11.0-RC1 powerpc GENERIC > > > o 11.0-RC1 powerpc64 GENERIC64 > > > o 11.0-RC1 sparc64 GENERIC > > > o 11.0-RC1 armv6 BANANAPI > > > o 11.0-RC1 armv6 BEAGLEBONE > > > o 11.0-RC1 armv6 CUBIEBOARD > > > o 11.0-RC1 armv6 CUBIEBOARD2 > > > o 11.0-RC1 armv6 CUBOX-HUMMINGBOARD > > > o 11.0-RC1 armv6 GUMSTIX > > > o 11.0-RC1 armv6 RPI-B > > > o 11.0-RC1 armv6 RPI2 > > > o 11.0-RC1 armv6 PANDABOARD > > > o 11.0-RC1 armv6 WANDBOARD > > > o 11.0-RC1 aarch64 GENERIC > >=20 > > What about granular sets? sparc64 is N/A while amd64 is missing > > lib32.txz, src.txz, ports.txz, tests.txz. Regressed since 11.0-BETA4. > > I've waited a day to see if the issue would disappear after mirrors > > catch up but no joy, even via Tor. > >=20 > > [...] >=20 > Thanks for letting us know. This isn't an re@ issue, it's an admins@ > issue, and we thought this was fixed. Give me a bit to investigate. >=20 I forced the mirrors to re-sync from the master. My initial test (amd64 lib32.txz) seems to have worked. We need to investigate this further, as the issues we've seen with this in the past should have been fixed. Give it about an hour or so to be sure, but I think everything will be fine this time. Sorry about that, and thank you again for bringing it to our attention. Glen --ZilngB4jitXEoqOO Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXr5FiAAoJEAMUWKVHj+KTbVQP/1hgVNVVTPrCPoHKZUH4e3GF piJzR+Za2leN+ZKpb567qTqcmlyWOGg2eR57A2udKvtbnF0FdvNWQ3ZJNQK9T6yg N5+zi++bO/+jPE0rsLe3f8QrROeisTkzF0VtTsyQ8PW8NS0WUBBiAnqbpIU4GLXu Fc32jEn6DD/A9JmkrdGgInr4E2rYayvlWz9m89TPRr90dJ6cBEs/Jl6O0Ly5JoM4 p1NbdDMsnqtYnd5KIQAGKEH1yvQKnGIaoUMQdRqSV0cjL08X0pcJpthlTg/b5wsb U/qI/khrpdSQ4EaFSTo8PaQmKHAYbBWPHURhd5c1lesdvEz2Gz3f85S4wZAf1zXS GyV1pk2wGSEgx7dZ4DzvAIjGZpz8eBvaUwO5ojKorAbLWl8o83v2pGyJ37qzzLbT jnmTj7emC55PSJRanji43gZT9qAP2jAd9YfnvNA8FnsopeSpPxdRKhGGQ+//EUGC 4rVH0rNHi5JXNA+OkSV/q4Emp0h5HPa2IxZUAUnKsyaant73PfNShyAw3kxKO55h Z6pBUpqhlkxOlcrwwYec+Nz7vhMxG3XhKApk8aV4IBVPgRwuShKWA6G/D10Gdb3x fYaFejf6asOQnroRGfEtIGBc6noGhP7aNMGSnKCgII2emyb6He1ArQe5C6roLFOp mTz63GEHWUfM5GON7pa+ =FzTG -----END PGP SIGNATURE----- --ZilngB4jitXEoqOO-- From owner-freebsd-current@freebsd.org Sat Aug 13 22:12:52 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D61BFBB7E60 for ; Sat, 13 Aug 2016 22:12:52 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::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 99D371D65 for ; Sat, 13 Aug 2016 22:12:52 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: by mail-ua0-x232.google.com with SMTP id n59so28232878uan.2 for ; Sat, 13 Aug 2016 15:12:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brilliantservice-co-jp.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=r8zYj4oj5n2a99nKQ3V7pN8gaL0879juOmvMKo0ne74=; b=xOvztyqGIzM46BE1OmD163PBP+xsGSChwh+o066I+3ZCNtVHqY48ZI34PmcJTJTetD 1O+GHAKD+CMSa36lBXkgk7zFjZ/wFu+Vd80TB9m/JPcxFQqbphcVhH6zFca/yvmsD3T7 AhdkwKJW3eTEkZpXfpJQpCkVyjZplHy2b2DGmHoI8TvfCV/Oikn/itYTHb5JHVI4RzcV AhYzPn7Qn+qjmj9CAazcP+yqnnina+ovSoWortqc+sxQ4Z4Y4oM5F588VJadMlferNJL cLxuBqh0FS509GauBP6Cbcda0s7sPjHgG12Owa17MLbWHqb7NKtGivaMlX2TXUVMKSnl wFbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=r8zYj4oj5n2a99nKQ3V7pN8gaL0879juOmvMKo0ne74=; b=WagMw6lyIh+liX6/P8nOca/geD5VdYYRSPHYt43yZAosGsBA/CKxtqY7+wyoTUiQgM jAZVS3bN6ZSUUXmirYRq8jWWUa2dEDpVPzZRT/b0dLqArgtVT/jaAw1Kzm0EjW3RRFUf fIl1tF3ZKO95zmHrory7OeD7GRtXANrAExSE2achLv76kh/1SU2MLEIqHhC8pRB1ITFT k2N8SDSCyjTfCXsrrvlkXBOUGuGQnADiGF7KGVF0VKkiPRU7iOrmwhRCY1ZWJUM+JgXT 5mNHdz6ANVJ66FkTQ3cQW5juOk02bZIKYRhfJ0860hqhzaKi2GFrfZvzeDy9Q3F0CO9T tpVw== X-Gm-Message-State: AEkoouvyDXUvnDDq/zDqCZ9c8a6oP+tj6ZQqZjo367sSS71Uzamd11eNPX9yYFhkARfksxbEeFd/UhyTizwLHPX7gzR250sWI7c0XV+OcsmBxsVmp7BHvzENgI1Z21THVCWzp6PdHAv1cX+0cTFmBO8P+6Q= X-Received: by 10.31.173.6 with SMTP id w6mr10865797vke.24.1471126370632; Sat, 13 Aug 2016 15:12:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.7.33 with HTTP; Sat, 13 Aug 2016 15:12:35 -0700 (PDT) From: "Lundberg, Johannes" Date: Sat, 13 Aug 2016 15:12:35 -0700 Message-ID: Subject: kevent support to drm To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 13 Aug 2016 22:12:52 -0000 4oCLSGkNCg0KSSd2ZSBqdXN0IHBvc3RlZCBhIHBhdGNoIHRoYXQgYWRkcyBrZXZlbnQgdG8gZHJt IDMuOCBicmFuY2guIFRoaXMgaXMgbmVlZGVkDQpmb3IgV2F5bGFuZCAoYWxvbmcgd2l0aCBldmRl dikuDQoNCkkgcG9zdGVkIGl0IG9uIHBoYWJyaWNhdG9yIGZvciBub3cuDQoNCmh0dHBzOi8vcmV2 aWV3cy5mcmVlYnNkLm9yZy9ENzQ5Ng0KDQoNClBoYWJyaWNhdG9yIGdhdmUgbWUgYSBob3JyaWJs ZSB1c2VybmFtZSBiZWNhdXNlIEkgdXNlZCBhbiBvbGQgZW1haWwsIGlzDQp0aGVyZSBhbnl3YXkg dG8gY2hhbmdlIGl0Pw0KDQpCZXN0IHJlZ2FyZHMNCgotLSAKPS09LT0tPS09LT0tPS09LT0tPS09 LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tCuenmOWvhuS/neaMgeOBq+OBpOOBhOOB pu+8muOBk+OBrumbu+WtkOODoeODvOODq+OBr+OAgeWQjeWum+S6uuOBq+mAgeS/oeOBl+OBn+OC guOBruOBp+OBguOCiuOAgeenmOWMv+eJueaoqeOBruWvvuixoeOBqOOBquOCi+aDheWgseOCkuWQ q+OCk+OBp+OBhOOBvuOBmeOAggrjgoLjgZfjgIHlkI3lrpvkurrku6XlpJbjga7mlrnjgYzlj5fk v6HjgZXjgozjgZ/loLTlkIjjgIHjgZPjga7jg6Hjg7zjg6vjga7noLTmo4TjgIHjgYrjgojjgbPj gZPjga7jg6Hjg7zjg6vjgavplqLjgZnjgovkuIDliIfjga7plovnpLrjgIEK6KSH5YaZ44CB6YWN 5biD44CB44Gd44Gu5LuW44Gu5Yip55So44CB44G+44Gf44Gv6KiY6LyJ5YaF5a6544Gr5Z+644Gl 44GP44GE44GL44Gq44KL6KGM5YuV44KC44GV44KM44Gq44GE44KI44GG44GK6aGY44GE55Sz44GX 5LiK44GS44G+44GZ44CCCi0tLQpDT05GSURFTlRJQUxJVFkgTk9URTogVGhlIGluZm9ybWF0aW9u IGluIHRoaXMgZW1haWwgaXMgY29uZmlkZW50aWFsCmFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRo ZSBhZGRyZXNzZWUuCkRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciBhbnkgb3Ro ZXIgYWN0aW9uIG9mIHVzZSBvZiB0aGlzCmVtYWlsIGJ5IHBlcnNvbiBvdGhlciB0aGFuIGludGVu ZGVkIHJlY2lwaWVudCwgaXMgcHJvaGliaXRlZC4KSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk IHJlY2lwaWVudCBhbmQgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluCmVycm9yLCBwbGVhc2Ug ZGVzdHJveSB0aGUgb3JpZ2luYWwgbWVzc2FnZS4K