From owner-freebsd-current@freebsd.org Sun Jul 31 00:07: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 4F8D2BA215A for ; Sun, 31 Jul 2016 00:07:00 +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 321841E29; Sun, 31 Jul 2016 00:07:00 +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 64C3C1C1; Sun, 31 Jul 2016 00:07:00 +0000 (UTC) Date: Sun, 31 Jul 2016 00:06:59 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <204586098.74.1469923619826.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <228045260.73.1469913100361.JavaMail.jenkins@jenkins-9.freebsd.org> References: <228045260.73.1469913100361.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_HEAD #508 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 31 Jul 2016 00:07:00 -0000 See From owner-freebsd-current@freebsd.org Sun Jul 31 01:40: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 730C2BA217E for ; Sun, 31 Jul 2016 01:40:00 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm50-vm2.bullet.mail.bf1.yahoo.com (nm50-vm2.bullet.mail.bf1.yahoo.com [216.109.115.221]) (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 29D661ED4 for ; Sun, 31 Jul 2016 01:40:00 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1469929193; bh=JyEzUCBRlIUZtOdeznKYDPKdpE3vpDV+aRVy1Io7+WQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=C6aJFrVaKjOiC2V5O10FC0ZzZ8herkvnN9UAq7/tc2+ji+ImA9Hogv41SbuZG0DOJrhwzsTk5IlzvctQb2oLe4+zRSO8ZiHGyAlB/PnUryn+5WphQHXt30Gb+vvbnm12hfS70OOZPTD3rS/s1tz7LHxUGP54IpgXT0rtJ0hPvX9c8mlwp422FuShpdI/D9d+1e48m6FbPhOZ1srsA7bUixUUFcgxE0exblcE/S7mU8RzsMANs0SoIVPdawbMdPY4DH/B/bmqSUmE1+xdQQQAIGpSq2PwQKD554Ifx6v5rV+nnySoaJPebAy4McK0yxVaiZKECndpYspY3aeOwZ5QIg== Received: from [66.196.81.174] by nm50.bullet.mail.bf1.yahoo.com with NNFMP; 31 Jul 2016 01:39:53 -0000 Received: from [68.142.230.77] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 31 Jul 2016 01:39:53 -0000 Received: from [127.0.0.1] by smtp234.mail.bf1.yahoo.com with NNFMP; 31 Jul 2016 01:39:53 -0000 X-Yahoo-Newman-Id: 741414.72150.bm@smtp234.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: EwPrS3QVM1k2Y6hrnkPuZSI1JqGzPi3Sz0BJY2TzPRabPhf pUPWBOSLtjrqSCMDNQ4LYVjm3dLURhFbpWrJG8IQ_PUp9Jr1igxt42p4IQio bj1TOiY.X7ZmZo4lLtRhf_ex1Zv0jj54RQZI7PWF_21WafsCq_._jfYBYg9T EPQKtselc1v8nPAZHNNefnD2p2nAkg4VELR0PWXnoJrLQm3HhRJBEXztHwic VO3UHL5tru9SVgsme5_nnBtu95N5I4I3GYVHwJN6sLQTMjlmaEFW2R7Sbee6 xERRvaKLrcJm5yzNfGp5h0Y6qqDfODI5dx80mxKv_V5nPxI7zNKNAm8qekR2 XTi9wTjeb69VY1t3yKnJF_A8M4cqyaaCYf9YyshniNlylOnBkAXhzBEw.YjJ LRKvK7wEOtoJuSmejS2Qg8D7AHcgS8YwFDAhY8vbBx.7c2eVVPK4c14XfPIC LxscbUaOF9Hfh5k7cYM3AaqqNgGQyT2T9fV6bmxnsSoOIeXLD6euEUJaBQy4 Qzixl6p2wlu4MLW.yvDNFoBG1LQYwDKMzntkrqtixGMNnRA-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Subject: Re: resolvconf needs @RESTARTCMD@ to be replaced after r303062 To: Guy Yur , freebsd-current References: Cc: Glen Barber From: Pedro Giffuni Message-ID: Date: Sat, 30 Jul 2016 20:40:02 -0500 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: multipart/mixed; boundary="------------7C20F263BA11AFA65996691B" 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, 31 Jul 2016 01:40:00 -0000 This is a multi-part message in MIME format. --------------7C20F263BA11AFA65996691B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit (CC'ing Glen for review, since he was the last to touch that file and may know better). Hi Guy; On 07/30/16 17:37, Guy Yur wrote: > Hi, > > openresolv 3.8.1 added RESTARTCMD=@RESTARTCMD@ in > contrib/openresolv/resolvconf.in. > It is not replaced by the sed expressions in sbin/resolvconf/Makefile. > > Error seen is "eval: @RESTARTCMD@: not found". > > Current @RESTARTCMD \(.*\)@ sed expression needs to be kept for > pdns_recursor.in and a new expression added to replace @RESTARTCMD@. > I see, you mean here: https://svnweb.freebsd.org/base/head/sbin/resolvconf/Makefile?revision=298107&view=markup#l32 > The following worked for me: > RESTARTCMD_= "/usr/sbin/service \\$$1 onestatus >/dev/null 2>\&1 > \&\& /usr/sbin/service \\$$1 restart" > > sed ... \ > ... \ > -e 's:@RESTARTCMD@:${RESTARTCMD_}:g' \ > ... And perhaps something like the attached patch (is the underscore a typo?). I don't see the error message though. so I need some confirmation that this fixes the issue. Pedro. --------------7C20F263BA11AFA65996691B Content-Type: text/x-patch; name="resolvconf-restartcmd.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="resolvconf-restartcmd.diff" Index: sbin/resolvconf/Makefile =================================================================== --- sbin/resolvconf/Makefile (revision 303557) +++ sbin/resolvconf/Makefile (working copy) @@ -30,6 +30,7 @@ -e 's:@LIBEXECDIR@:${FILESDIR}:g' \ -e 's:@VARDIR@:${VARDIR}:g' \ -e 's:@RESTARTCMD \(.*\)@:${RESTARTCMD}:g' \ + -e 's:@RESTARTCMD@:${RESTARTCMD}:g' \ -e 's:@RCDIR@:${RCDIR}:g' \ -e 's: vpn : ng[0-9]*&:g' \ ${DIST}/$@.in > $@ --------------7C20F263BA11AFA65996691B-- From owner-freebsd-current@freebsd.org Sun Jul 31 02:35: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 7B7A0BA70C3 for ; Sun, 31 Jul 2016 02:35:52 +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 61AAA161B; Sun, 31 Jul 2016 02:35:52 +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 17A201F6E; Sun, 31 Jul 2016 02:35:52 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Sun, 31 Jul 2016 02:35:50 +0000 From: Glen Barber To: Pedro Giffuni Cc: Guy Yur , freebsd-current Subject: Re: resolvconf needs @RESTARTCMD@ to be replaced after r303062 Message-ID: <20160731023550.GF1532@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DEfZqDS1MPR2ysog" 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: Sun, 31 Jul 2016 02:35:52 -0000 --DEfZqDS1MPR2ysog Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 30, 2016 at 08:40:02PM -0500, Pedro Giffuni wrote: > (CC'ing Glen for review, since he was the last to touch that file and > may know better). >=20 Unfortunately, I don't know better. I only touched the file last in order to close a PR prior to the final 10.2-RELEASE (if I remember correctly). > Hi Guy; >=20 >=20 > On 07/30/16 17:37, Guy Yur wrote: > >Hi, > > > >openresolv 3.8.1 added RESTARTCMD=3D@RESTARTCMD@ in > >contrib/openresolv/resolvconf.in. > >It is not replaced by the sed expressions in sbin/resolvconf/Makefile. > > > >Error seen is "eval: @RESTARTCMD@: not found". > > > >Current @RESTARTCMD \(.*\)@ sed expression needs to be kept for > >pdns_recursor.in and a new expression added to replace @RESTARTCMD@. > > >=20 > I see, you mean here: >=20 > https://svnweb.freebsd.org/base/head/sbin/resolvconf/Makefile?revision=3D= 298107&view=3Dmarkup#l32 >=20 > >The following worked for me: > >RESTARTCMD_=3D "/usr/sbin/service \\$$1 onestatus >/dev/null 2>\&1 > >\&\& /usr/sbin/service \\$$1 restart" > > > >sed ... \ > > ... \ > > -e 's:@RESTARTCMD@:${RESTARTCMD_}:g' \ > > ... >=20 > And perhaps something like the attached patch (is the underscore > a typo?). >=20 > I don't see the error message though. so I need some confirmation that > this fixes the issue. >=20 Likewise, I do not see the error either, so would like definitive confirmation the patch resolves the issue. > Index: sbin/resolvconf/Makefile > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sbin/resolvconf/Makefile (revision 303557) > +++ sbin/resolvconf/Makefile (working copy) > @@ -30,6 +30,7 @@ > -e 's:@LIBEXECDIR@:${FILESDIR}:g' \ > -e 's:@VARDIR@:${VARDIR}:g' \ > -e 's:@RESTARTCMD \(.*\)@:${RESTARTCMD}:g' \ > + -e 's:@RESTARTCMD@:${RESTARTCMD}:g' \ > -e 's:@RCDIR@:${RCDIR}:g' \ > -e 's: vpn : ng[0-9]*&:g' \ > ${DIST}/$@.in > $@ Glen --DEfZqDS1MPR2ysog Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXnWQBAAoJEAMUWKVHj+KTQRwQAJ17DQbplXtfec6QUC0C+mGH 3zxX29MJ3+g7A8fJm7YlV32yU0IM8XPpoMZYCowMSMbqeH9aU0Qn6b9jYX4uJ3GX QlKoCP/HQ2rteIb7rbKJeOuFiaCNqH1UhrtO6kDNzlhwGrABlVWDRscgE3IsRVA4 rVPxGA20NAAXbR24wd5Bk9AZaZjZxKAb8S8He+fUJJJnGRZZUs4Ysv/cdbIw09UL 62J8HHttowT116ws7KjVsqcv+ua8SHGcKcV837KizGuzBXci2DaWzGwMPhXTzeJY 1Mw2kN50FCleRtcDtjCEuLwDA6F/v5kzbKnsBsb8n1USdGYbk8Aj5PAxDvLYP4CR o0bDhTARF3LUx9VeJljiDDPvgFIkk5l9oROxt6j5hQs/lzVeLbc6EW+nEiTK4Toj WFPdvEFkxi3jOMHsYCoN5Q4lXxTcMsE6Wy6VMIMFy/2Ikd5Qutzo/t/SBTo6SQKE HDFlz/P0MuoGAhsQGC7ZbwDNrVqXOFbMJxfPOnC9C/yfc1leP1obDWP4rIT1WZ5l XHTEClyz5hAQGvpT55r2WJwKzdme/7/YWxIrEl0KYI0EorJEXksELqMxjXuSir/E fnLWmC4Qz20bOwsPDj6JNdzQ6dWlqDbadXHvqwNADMw6r311q5Kuye2LugRWT4sM HMRM5gEcYOHABxEnIQuJ =MEzA -----END PGP SIGNATURE----- --DEfZqDS1MPR2ysog-- From owner-freebsd-current@freebsd.org Sun Jul 31 02:46: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 54B53BA737D for ; Sun, 31 Jul 2016 02:46:55 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm20.bullet.mail.bf1.yahoo.com (nm20.bullet.mail.bf1.yahoo.com [98.139.212.179]) (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 010F11B6A for ; Sun, 31 Jul 2016 02:46:54 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1469933206; bh=6hvAFyEii1jVuLQJNuD25H1oQz0zzZgOv1wVQVyOaZ4=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=bhj0V2/Sy3vaqK82dK6QADMyWmaePEEOIyE/PN8djy8i0RRS9XFcBMiUEJfoHhT/QKdoVB7AY00iYhRYfT9uXU9hZdTv1zdTIo723MAhc8MuHRe3p6qTrVl0sSsx5fV3npKFBL5rqEELoJlxndt0JC1PgFiUSPGh5/1sGdpvkrCWRnvUXFLFiLrCHEY8tZDjOZrMJmU9KYNEhayt2450HIWKZ0BUzV9GBdAozBmde9dTdU3CrAaG2N+YcYnOhStyETftdcOzT2UIQKwXQwRcdC1JEeWLGJiWobOaQxsR8xVDEOicCEBAu173IQ2uwI17X8kELBTbcem91jkcCVPF7A== Received: from [98.139.214.32] by nm20.bullet.mail.bf1.yahoo.com with NNFMP; 31 Jul 2016 02:46:46 -0000 Received: from [98.139.211.196] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 31 Jul 2016 02:46:46 -0000 Received: from [127.0.0.1] by smtp205.mail.bf1.yahoo.com with NNFMP; 31 Jul 2016 02:46:46 -0000 X-Yahoo-Newman-Id: 887007.42106.bm@smtp205.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: LNqGhosVM1kH5QI7o5ObB5K9POfG7iREsVt5CDP6rKZ_rCY o8KxNUvoBMlE.6.cCnWg1uebg7jaSZLSWEUdUVUqOjgahgZbFvshsumWTpCR mgzNoIUDkrOFdE6mBIM6HZ4XEUF4Fx1DIt.L8cCimzemEb6jTxYaZSLg9rjT zdxLEMiUrmdp97w1GATzirS3.xmnOfIjI4UvJIVP7s2POa7AwDsW.DfgbL21 nzay6BOL8X_nOvyw98aMb98jvH3bbzdxeW2uTwcjUFA7FczXU877onK1mfRQ G8.9DfnR84cukWnL6a5G2g2Pu98YQFvBwNCwADm.47WJGJIvrW4Qo0xdJJlC utL50KEyFyEuxobsDR0nrfabKjFZ6IcgU9vPrP..RD9LhKMkJQl8iAiSWWyj Oj3UqhE9qKE_KjT1uIpe.2DyjWgzXj2cI2a8PMCXFe5nSFoMYEJDg_Fcw5hV iPa2v4I9lfCmx6i4mNMPfqr0cZfarF3aqd9wC9OT5q.cAIEyvo1kaMvgmAz8 W6m6ptuUJANe46a2KfzLB4jXwayY9oXpt0uuEmvfUhzHr3A-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Subject: Re: resolvconf needs @RESTARTCMD@ to be replaced after r303062 To: Glen Barber References: <20160731023550.GF1532@FreeBSD.org> Cc: Guy Yur , freebsd-current From: Pedro Giffuni Message-ID: Date: Sat, 30 Jul 2016 21:46:55 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160731023550.GF1532@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 31 Jul 2016 02:46:55 -0000 On 07/30/16 21:35, Glen Barber wrote: ... >> >> I don't see the error message though. so I need some confirmation that >> this fixes the issue. >> > > Likewise, I do not see the error either, so would like definitive > confirmation the patch resolves the issue. > OK, I don't see the error message but I can reproduce it: % grep @RESTARTCMD@ * resolvconf:RESTARTCMD=@RESTARTCMD@ >> Index: sbin/resolvconf/Makefile >> =================================================================== >> --- sbin/resolvconf/Makefile (revision 303557) >> +++ sbin/resolvconf/Makefile (working copy) >> @@ -30,6 +30,7 @@ >> -e 's:@LIBEXECDIR@:${FILESDIR}:g' \ >> -e 's:@VARDIR@:${VARDIR}:g' \ >> -e 's:@RESTARTCMD \(.*\)@:${RESTARTCMD}:g' \ >> + -e 's:@RESTARTCMD@:${RESTARTCMD}:g' \ >> -e 's:@RCDIR@:${RCDIR}:g' \ >> -e 's: vpn : ng[0-9]*&:g' \ >> ${DIST}/$@.in > $@ > And the underscore was not a typo. Thanks Guy! Pedro. From owner-freebsd-current@freebsd.org Sun Jul 31 03:10: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 131DFBA7941 for ; Sun, 31 Jul 2016 03:10:21 +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 057381B16; Sun, 31 Jul 2016 03:10:21 +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 7377E1C6; Sun, 31 Jul 2016 03:10:17 +0000 (UTC) Date: Sun, 31 Jul 2016 03:10:12 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <875526055.75.1469934612974.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <204586098.74.1469923619826.JavaMail.jenkins@jenkins-9.freebsd.org> References: <204586098.74.1469923619826.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_HEAD #509 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 31 Jul 2016 03:10:21 -0000 See From owner-freebsd-current@freebsd.org Sun Jul 31 05:43: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 B5958BA95EB for ; Sun, 31 Jul 2016 05:43:50 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 68C2715CC for ; Sun, 31 Jul 2016 05:43:50 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: by mail-yw0-x232.google.com with SMTP id r9so147995435ywg.0 for ; Sat, 30 Jul 2016 22:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=OUOfDPS/uSWhkr+lrfOgkYGvRHRFYxWb8SjKAFA/J0k=; b=v1jirM7Ez0AkzSZzwkCO1TCTvFQ9sfJJ5KU25cvd9t/1XXq/fi8Jk9A+HQbKex+t86 2DF9fQ+q+lNybRGHr3cV3pLKd9RbeWtNQ0Mi4a/AbmBSchoK0wPaOB6EXXoFVNY8BCT2 i0j9IOn9x5qOAaOCc1rha7EK5o2JXNGYKdF+Y1xjrXcwhiKY9zKWEN1arNnGLQCsSFc+ CMUKLkOdGJnpH73H+lJ9s0buzXV4yPlaT3vYbq9f8KJNiXaGtjdHWENtzEiyt0ZgKsWD yPQORzWTUuImkY8wGibjO4SrR+UuWyDto28BRAzUBOuChcDwG/I06Fhu9lFlfYCG0h/9 a1sg== 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=OUOfDPS/uSWhkr+lrfOgkYGvRHRFYxWb8SjKAFA/J0k=; b=OICvHwV6gTZmhW+B5PMtVXDRktJccvcGV9osxNCTFioKsh6Woa1kiNp+gGNqRAtDFs mw9CYsbO60q3sxSFH0xPD4E+gd7BKa7eoZ1xu0a2+bk7c3V8G+vdAWdspPt0yoCC9Fiy kQm3bZNzuHB6o0+x9F0OFFfa1H9g5Khep50h+F+Nv8bJOb7+nGHc5grg9eUQiRs6WwIA pkdj5ih1fiAdPMIy0Y/e+ZjQGKk0ukq2mJ6S6pGQ5rZXg3kctFNpJ4smhGbyHxLBSoXU hzaXDQ4R6PXPf95qq4djxMEZQzyb6h7iJGd0BHPyv45QMus4eg4KEUsdMVGq7P7/JI6P QZ5g== X-Gm-Message-State: AEkooutbr0Ctu6AaEXMpYbXuiExv/jaz9tmjgOB938ZazPphi+ThgYexh/AgPxX0OONGdJeLTzedsgPDHpI67Q== X-Received: by 10.129.130.198 with SMTP id s189mr30201017ywf.101.1469943829035; Sat, 30 Jul 2016 22:43:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.199.65 with HTTP; Sat, 30 Jul 2016 22:43:48 -0700 (PDT) From: Ben Woods Date: Sun, 31 Jul 2016 13:43:48 +0800 Message-ID: Subject: ACPI errors when booting laptop To: FreeBSD Current Content-Type: multipart/mixed; boundary=94eb2c07c694c51b0f0538e7f712 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: Sun, 31 Jul 2016 05:43:50 -0000 --94eb2c07c694c51b0f0538e7f712 Content-Type: text/plain; charset=UTF-8 Hi everyone, I get the following ACPI errors in my dmesg when booting my NEC Lavie HZ750 laptop with FreeBSD 12-current. I have noticed things not functioning correct (except suspend/resume not working), but then again I don't really know much about ACPI or what I should expect to see. Any ideas what the problem is? Full dmesg is also attached. acpi0: on motherboard acpi_ec_ecdt_probe: can't get handle ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC._REG] (Node 0xfffff80005494980), AE_NOT_EXIST (20160527/psparse-559) acpi0: Power Button (fixed) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.BAT1._STA] (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.BAT1._STA] (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.BAT1._STA] (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.BAT1._STA] (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.BAT1._STA] (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.BAT1._STA] (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.BAT1._STA] (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.BAT1._STA] (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.BAT1._STA] (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.CIND._STA] (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.CIND._STA] (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.CIND._STA] (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.CIND._STA] (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.CIND._STA] (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.CIND._STA] (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.CIND._STA] (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.CIND._STA] (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.CIND._STA] (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.CIND._STA] (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.CIND._STA] (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.CIND._STA] (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.CIND._STA] (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.CIND._STA] (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.CIND._STA] (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.CIND._STA] (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.CIND._STA] (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.CIND._STA] (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.VGBI._STA] (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.VGBI._STA] (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.VGBI._STA] (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.VGBI._STA] (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.VGBI._STA] (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.VGBI._STA] (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.VGBI._STA] (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.VGBI._STA] (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.VGBI._STA] (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.VGBI._STA] (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.VGBI._STA] (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.VGBI._STA] (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.VGBI._STA] (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.VGBI._STA] (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.VGBI._STA] (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.VGBI._STA] (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.VGBI._STA] (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.VGBI._STA] (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.BAT1._STA] (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.BAT1._STA] (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.CIND._STA] (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.CIND._STA] (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.CIND._STA] (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.CIND._STA] (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.VGBI._STA] (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.VGBI._STA] (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.VGBI._STA] (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.VGBI._STA] (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.BAT1._STA] (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.BAT1._STA] (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.CIND._STA] (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.CIND._STA] (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.CIND._STA] (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.CIND._STA] (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.VGBI._STA] (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.VGBI._STA] (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.VGBI._STA] (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.VGBI._STA] (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.BAT1._STA] (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.CIND._STA] (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.CIND._STA] (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/uteval-111) ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) [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.EC.VGBI._STA] (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/psparse-559) ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.VGBI._STA] (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/uteval-111) Regards, Ben -- From: Benjamin Woods woodsb02@gmail.com --94eb2c07c694c51b0f0538e7f712 Content-Type: text/plain; charset=US-ASCII; name="dmesg.txt" Content-Disposition: attachment; filename="dmesg.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ira6lg460 Q29weXJpZ2h0IChjKSAxOTkyLTIwMTYgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCAxMi4wLUNVUlJFTlQgIzAgcjMwMzMzNk06IFdlZCBK dWwgMjcgMDA6NDY6MzMgQVdTVCAyMDE2CiAgICB3b29kc2IwMkBzaGludG8ud29vZHMuYW06L3Vz ci9vYmovdXNyL3NyYy9zeXMvR0VORVJJQy1OT0RFQlVHIGFtZDY0CkZyZWVCU0QgY2xhbmcgdmVy c2lvbiAzLjguMCAodGFncy9SRUxFQVNFXzM4MC9maW5hbCAyNjI1NjQpIChiYXNlZCBvbiBMTFZN IDMuOC4wKQpWVChlZmlmYik6IHJlc29sdXRpb24gMjU2MHgxNDQwCkNQVTogSW50ZWwoUikgQ29y ZShUTSkgaTctNTUwMFUgQ1BVIEAgMi40MEdIeiAoMjM5NC41MS1NSHogSzgtY2xhc3MgQ1BVKQog IE9yaWdpbj0iR2VudWluZUludGVsIiAgSWQ9MHgzMDZkNCAgRmFtaWx5PTB4NiAgTW9kZWw9MHgz ZCAgU3RlcHBpbmc9NAogIEZlYXR1cmVzPTB4YmZlYmZiZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1T UixQQUUsTUNFLENYOCxBUElDLFNFUCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsQ0xGTFVT SCxEVFMsQUNQSSxNTVgsRlhTUixTU0UsU1NFMixTUyxIVFQsVE0sUEJFPgogIEZlYXR1cmVzMj0w eDdmZmFmYmJmPFNTRTMsUENMTVVMUURRLERURVM2NCxNT04sRFNfQ1BMLFZNWCxFU1QsVE0yLFNT U0UzLFNEQkcsRk1BLENYMTYseFRQUixQRENNLFBDSUQsU1NFNC4xLFNTRTQuMix4MkFQSUMsTU9W QkUsUE9QQ05ULFRTQ0RMVCxBRVNOSSxYU0FWRSxPU1hTQVZFLEFWWCxGMTZDLFJEUkFORD4KICBB TUQgRmVhdHVyZXM9MHgyYzEwMDgwMDxTWVNDQUxMLE5YLFBhZ2UxR0IsUkRUU0NQLExNPgogIEFN RCBGZWF0dXJlczI9MHgxMjE8TEFIRixBQk0sUHJlZmV0Y2g+CiAgU3RydWN0dXJlZCBFeHRlbmRl ZCBGZWF0dXJlcz0weDIxYzI3YWI8RlNHU0JBU0UsVFNDQURKLEJNSTEsQVZYMixTTUVQLEJNSTIs RVJNUyxJTlZQQ0lELE5GUFVTRyxSRFNFRUQsQURYLFNNQVAsUFJPQ1RSQUNFPgogIFhTQVZFIEZl YXR1cmVzPTB4MTxYU0FWRU9QVD4KICBWVC14OiBQQVQsSExULE1URixQQVVTRSxFUFQsVUcsVlBJ RAogIFRTQzogUC1zdGF0ZSBpbnZhcmlhbnQsIHBlcmZvcm1hbmNlIHN0YXRpc3RpY3MKcmVhbCBt ZW1vcnkgID0gODU4OTkzNDU5MiAoODE5MiBNQikKYXZhaWwgbWVtb3J5ID0gODE3MDUwODI4OCAo Nzc5MiBNQikKRXZlbnQgdGltZXIgIkxBUElDIiBxdWFsaXR5IDYwMApBQ1BJIEFQSUMgVGFibGU6 IDxORUMgICAgTkQwMDAyMzU+CkZyZWVCU0QvU01QOiBNdWx0aXByb2Nlc3NvciBTeXN0ZW0gRGV0 ZWN0ZWQ6IDQgQ1BVcwpGcmVlQlNEL1NNUDogMSBwYWNrYWdlKHMpIHggMiBjb3JlKHMpIHggMiBo YXJkd2FyZSB0aHJlYWRzCnJhbmRvbTogdW5ibG9ja2luZyBkZXZpY2UuCldBUk5JTkc6IEJvZ3Vz IEludGVycnVwdCBUcmlnZ2VyIE1vZGUuIEFzc3VtZSBDT05GT1JNUy4KV0FSTklORzogQm9ndXMg SW50ZXJydXB0IFBvbGFyaXR5LiBBc3N1bWUgQ09ORk9STVMKaW9hcGljMCA8VmVyc2lvbiAyLjA+ IGlycXMgMC0zOSBvbiBtb3RoZXJib2FyZApyYW5kb206IGVudHJvcHkgZGV2aWNlIGV4dGVybmFs IGludGVyZmFjZQprYmQxIGF0IGtiZG11eDAKbmV0bWFwOiBsb2FkZWQgbW9kdWxlCm1vZHVsZV9y ZWdpc3Rlcl9pbml0OiBNT0RfTE9BRCAodmVzYSwgMHhmZmZmZmZmZjgxMDNjMmQwLCAwKSBlcnJv ciAxOQpyYW5kb206IHJlZ2lzdGVyaW5nIGZhc3Qgc291cmNlIEludGVsIFNlY3VyZSBLZXkgUk5H CnJhbmRvbTogZmFzdCBwcm92aWRlcjogIkludGVsIFNlY3VyZSBLZXkgUk5HIgpjcnlwdG9zb2Z0 MDogPHNvZnR3YXJlIGNyeXB0bz4gb24gbW90aGVyYm9hcmQKYWVzbmkwOiA8QUVTLUNCQyxBRVMt WFRTLEFFUy1HQ00sQUVTLUlDTT4gb24gbW90aGVyYm9hcmQKYWNwaTA6IDxORUMgTkQwMDAyMzU+ IG9uIG1vdGhlcmJvYXJkCmFjcGlfZWNfZWNkdF9wcm9iZTogY2FuJ3QgZ2V0IGhhbmRsZQpBQ1BJ IEVycm9yOiBObyBoYW5kbGVyIGZvciBSZWdpb24gW0VDX19dICgweGZmZmZmODAwMDU0OGZjODAp IFtFbWJlZGRlZENvbnRyb2xdICgyMDE2MDUyNy9ldnJlZ2lvbi0xODApCkFDUEkgRXJyb3I6IFJl Z2lvbiBFbWJlZGRlZENvbnRyb2wgKElEPTMpIGhhcyBubyBoYW5kbGVyICgyMDE2MDUyNy9leGZs ZGlvLTMyMCkKQUNQSSBFcnJvcjogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1wxMzRf U0IuUENJMC5MUENCLkVDLl9SRUddIChOb2RlIDB4ZmZmZmY4MDAwNTQ5NDk4MCksIEFFX05PVF9F WElTVCAoMjAxNjA1MjcvcHNwYXJzZS01NTkpCmFjcGkwOiBQb3dlciBCdXR0b24gKGZpeGVkKQpB Q1BJIEVycm9yOiBObyBoYW5kbGVyIGZvciBSZWdpb24gW0VDX19dICgweGZmZmZmODAwMDU0OGZj ODApIFtFbWJlZGRlZENvbnRyb2xdICgyMDE2MDUyNy9ldnJlZ2lvbi0xODApCkFDUEkgRXJyb3I6 IFJlZ2lvbiBFbWJlZGRlZENvbnRyb2wgKElEPTMpIGhhcyBubyBoYW5kbGVyICgyMDE2MDUyNy9l eGZsZGlvLTMyMCkKQUNQSSBFcnJvcjogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1wx MzRfU0IuUENJMC5MUENCLkVDLkJBVDEuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhNjQwKSwg QUVfTk9UX0VYSVNUICgyMDE2MDUyNy9wc3BhcnNlLTU1OSkKQUNQSSBFcnJvcjogTWV0aG9kIGV4 ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLkJBVDEuX1NUQV0gKE5vZGUgMHhm ZmZmZjgwMDA1NDlhNjQwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy91dGV2YWwtMTExKQpBQ1BJ IEVycm9yOiBObyBoYW5kbGVyIGZvciBSZWdpb24gW0VDX19dICgweGZmZmZmODAwMDU0OGZjODAp IFtFbWJlZGRlZENvbnRyb2xdICgyMDE2MDUyNy9ldnJlZ2lvbi0xODApCkFDUEkgRXJyb3I6IFJl Z2lvbiBFbWJlZGRlZENvbnRyb2wgKElEPTMpIGhhcyBubyBoYW5kbGVyICgyMDE2MDUyNy9leGZs ZGlvLTMyMCkKQUNQSSBFcnJvcjogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1wxMzRf U0IuUENJMC5MUENCLkVDLkJBVDEuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhNjQwKSwgQUVf Tk9UX0VYSVNUICgyMDE2MDUyNy9wc3BhcnNlLTU1OSkKQUNQSSBFcnJvcjogTWV0aG9kIGV4ZWN1 dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLkJBVDEuX1NUQV0gKE5vZGUgMHhmZmZm ZjgwMDA1NDlhNjQwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy91dGV2YWwtMTExKQpBQ1BJIEVy cm9yOiBObyBoYW5kbGVyIGZvciBSZWdpb24gW0VDX19dICgweGZmZmZmODAwMDU0OGZjODApIFtF bWJlZGRlZENvbnRyb2xdICgyMDE2MDUyNy9ldnJlZ2lvbi0xODApCkFDUEkgRXJyb3I6IFJlZ2lv biBFbWJlZGRlZENvbnRyb2wgKElEPTMpIGhhcyBubyBoYW5kbGVyICgyMDE2MDUyNy9leGZsZGlv LTMyMCkKQUNQSSBFcnJvcjogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0Iu UENJMC5MUENCLkVDLkJBVDEuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhNjQwKSwgQUVfTk9U X0VYSVNUICgyMDE2MDUyNy9wc3BhcnNlLTU1OSkKQUNQSSBFcnJvcjogTWV0aG9kIGV4ZWN1dGlv biBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLkJBVDEuX1NUQV0gKE5vZGUgMHhmZmZmZjgw MDA1NDlhNjQwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy91dGV2YWwtMTExKQpBQ1BJIEVycm9y OiBObyBoYW5kbGVyIGZvciBSZWdpb24gW0VDX19dICgweGZmZmZmODAwMDU0OGZjODApIFtFbWJl ZGRlZENvbnRyb2xdICgyMDE2MDUyNy9ldnJlZ2lvbi0xODApCkFDUEkgRXJyb3I6IFJlZ2lvbiBF bWJlZGRlZENvbnRyb2wgKElEPTMpIGhhcyBubyBoYW5kbGVyICgyMDE2MDUyNy9leGZsZGlvLTMy MCkKQUNQSSBFcnJvcjogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJ MC5MUENCLkVDLkJBVDEuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhNjQwKSwgQUVfTk9UX0VY SVNUICgyMDE2MDUyNy9wc3BhcnNlLTU1OSkKQUNQSSBFcnJvcjogTWV0aG9kIGV4ZWN1dGlvbiBm YWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLkJBVDEuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1 NDlhNjQwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy91dGV2YWwtMTExKQpBQ1BJIEVycm9yOiBO byBoYW5kbGVyIGZvciBSZWdpb24gW0VDX19dICgweGZmZmZmODAwMDU0OGZjODApIFtFbWJlZGRl ZENvbnRyb2xdICgyMDE2MDUyNy9ldnJlZ2lvbi0xODApCkFDUEkgRXJyb3I6IFJlZ2lvbiBFbWJl ZGRlZENvbnRyb2wgKElEPTMpIGhhcyBubyBoYW5kbGVyICgyMDE2MDUyNy9leGZsZGlvLTMyMCkK QUNQSSBFcnJvcjogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5M UENCLkVDLkJBVDEuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhNjQwKSwgQUVfTk9UX0VYSVNU ICgyMDE2MDUyNy9wc3BhcnNlLTU1OSkKQUNQSSBFcnJvcjogTWV0aG9kIGV4ZWN1dGlvbiBmYWls ZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLkJBVDEuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlh NjQwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy91dGV2YWwtMTExKQpBQ1BJIEVycm9yOiBObyBo YW5kbGVyIGZvciBSZWdpb24gW0VDX19dICgweGZmZmZmODAwMDU0OGZjODApIFtFbWJlZGRlZENv bnRyb2xdICgyMDE2MDUyNy9ldnJlZ2lvbi0xODApCkFDUEkgRXJyb3I6IFJlZ2lvbiBFbWJlZGRl ZENvbnRyb2wgKElEPTMpIGhhcyBubyBoYW5kbGVyICgyMDE2MDUyNy9leGZsZGlvLTMyMCkKQUNQ SSBFcnJvcjogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENC LkVDLkJBVDEuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhNjQwKSwgQUVfTk9UX0VYSVNUICgy MDE2MDUyNy9wc3BhcnNlLTU1OSkKQUNQSSBFcnJvcjogTWV0aG9kIGV4ZWN1dGlvbiBmYWlsZWQg W1wxMzRfU0IuUENJMC5MUENCLkVDLkJBVDEuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhNjQw KSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy91dGV2YWwtMTExKQpBQ1BJIEVycm9yOiBObyBoYW5k bGVyIGZvciBSZWdpb24gW0VDX19dICgweGZmZmZmODAwMDU0OGZjODApIFtFbWJlZGRlZENvbnRy b2xdICgyMDE2MDUyNy9ldnJlZ2lvbi0xODApCkFDUEkgRXJyb3I6IFJlZ2lvbiBFbWJlZGRlZENv bnRyb2wgKElEPTMpIGhhcyBubyBoYW5kbGVyICgyMDE2MDUyNy9leGZsZGlvLTMyMCkKQUNQSSBF cnJvcjogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVD LkJBVDEuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhNjQwKSwgQUVfTk9UX0VYSVNUICgyMDE2 MDUyNy9wc3BhcnNlLTU1OSkKQUNQSSBFcnJvcjogTWV0aG9kIGV4ZWN1dGlvbiBmYWlsZWQgW1wx MzRfU0IuUENJMC5MUENCLkVDLkJBVDEuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhNjQwKSwg QUVfTk9UX0VYSVNUICgyMDE2MDUyNy91dGV2YWwtMTExKQpBQ1BJIEVycm9yOiBObyBoYW5kbGVy IGZvciBSZWdpb24gW0VDX19dICgweGZmZmZmODAwMDU0OGZjODApIFtFbWJlZGRlZENvbnRyb2xd ICgyMDE2MDUyNy9ldnJlZ2lvbi0xODApCkFDUEkgRXJyb3I6IFJlZ2lvbiBFbWJlZGRlZENvbnRy b2wgKElEPTMpIGhhcyBubyBoYW5kbGVyICgyMDE2MDUyNy9leGZsZGlvLTMyMCkKQUNQSSBFcnJv cjogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLkJB VDEuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhNjQwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUy Ny9wc3BhcnNlLTU1OSkKQUNQSSBFcnJvcjogTWV0aG9kIGV4ZWN1dGlvbiBmYWlsZWQgW1wxMzRf U0IuUENJMC5MUENCLkVDLkJBVDEuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhNjQwKSwgQUVf Tk9UX0VYSVNUICgyMDE2MDUyNy91dGV2YWwtMTExKQpBQ1BJIEVycm9yOiBObyBoYW5kbGVyIGZv ciBSZWdpb24gW0VDX19dICgweGZmZmZmODAwMDU0OGZjODApIFtFbWJlZGRlZENvbnRyb2xdICgy MDE2MDUyNy9ldnJlZ2lvbi0xODApCkFDUEkgRXJyb3I6IFJlZ2lvbiBFbWJlZGRlZENvbnRyb2wg KElEPTMpIGhhcyBubyBoYW5kbGVyICgyMDE2MDUyNy9leGZsZGlvLTMyMCkKQUNQSSBFcnJvcjog TWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLkJBVDEu X1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhNjQwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy9w c3BhcnNlLTU1OSkKQUNQSSBFcnJvcjogTWV0aG9kIGV4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0Iu UENJMC5MUENCLkVDLkJBVDEuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhNjQwKSwgQUVfTk9U X0VYSVNUICgyMDE2MDUyNy91dGV2YWwtMTExKQpBQ1BJIEVycm9yOiBObyBoYW5kbGVyIGZvciBS ZWdpb24gW0VDX19dICgweGZmZmZmODAwMDU0OGZjODApIFtFbWJlZGRlZENvbnRyb2xdICgyMDE2 MDUyNy9ldnJlZ2lvbi0xODApCkFDUEkgRXJyb3I6IFJlZ2lvbiBFbWJlZGRlZENvbnRyb2wgKElE PTMpIGhhcyBubyBoYW5kbGVyICgyMDE2MDUyNy9leGZsZGlvLTMyMCkKQUNQSSBFcnJvcjogTWV0 aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLkNJTkQuX1NU QV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhMmMwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy9wc3Bh cnNlLTU1OSkKQUNQSSBFcnJvcjogTWV0aG9kIGV4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJ MC5MUENCLkVDLkNJTkQuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhMmMwKSwgQUVfTk9UX0VY SVNUICgyMDE2MDUyNy91dGV2YWwtMTExKQpBQ1BJIEVycm9yOiBObyBoYW5kbGVyIGZvciBSZWdp b24gW0VDX19dICgweGZmZmZmODAwMDU0OGZjODApIFtFbWJlZGRlZENvbnRyb2xdICgyMDE2MDUy Ny9ldnJlZ2lvbi0xODApCkFDUEkgRXJyb3I6IFJlZ2lvbiBFbWJlZGRlZENvbnRyb2wgKElEPTMp IGhhcyBubyBoYW5kbGVyICgyMDE2MDUyNy9leGZsZGlvLTMyMCkKQUNQSSBFcnJvcjogTWV0aG9k IHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLkNJTkQuX1NUQV0g KE5vZGUgMHhmZmZmZjgwMDA1NDlhMmMwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy9wc3BhcnNl LTU1OSkKQUNQSSBFcnJvcjogTWV0aG9kIGV4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5M UENCLkVDLkNJTkQuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhMmMwKSwgQUVfTk9UX0VYSVNU ICgyMDE2MDUyNy91dGV2YWwtMTExKQpBQ1BJIEVycm9yOiBObyBoYW5kbGVyIGZvciBSZWdpb24g W0VDX19dICgweGZmZmZmODAwMDU0OGZjODApIFtFbWJlZGRlZENvbnRyb2xdICgyMDE2MDUyNy9l dnJlZ2lvbi0xODApCkFDUEkgRXJyb3I6IFJlZ2lvbiBFbWJlZGRlZENvbnRyb2wgKElEPTMpIGhh cyBubyBoYW5kbGVyICgyMDE2MDUyNy9leGZsZGlvLTMyMCkKQUNQSSBFcnJvcjogTWV0aG9kIHBh cnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLkNJTkQuX1NUQV0gKE5v ZGUgMHhmZmZmZjgwMDA1NDlhMmMwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy9wc3BhcnNlLTU1 OSkKQUNQSSBFcnJvcjogTWV0aG9kIGV4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENC LkVDLkNJTkQuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhMmMwKSwgQUVfTk9UX0VYSVNUICgy MDE2MDUyNy91dGV2YWwtMTExKQpBQ1BJIEVycm9yOiBObyBoYW5kbGVyIGZvciBSZWdpb24gW0VD X19dICgweGZmZmZmODAwMDU0OGZjODApIFtFbWJlZGRlZENvbnRyb2xdICgyMDE2MDUyNy9ldnJl Z2lvbi0xODApCkFDUEkgRXJyb3I6IFJlZ2lvbiBFbWJlZGRlZENvbnRyb2wgKElEPTMpIGhhcyBu byBoYW5kbGVyICgyMDE2MDUyNy9leGZsZGlvLTMyMCkKQUNQSSBFcnJvcjogTWV0aG9kIHBhcnNl L2V4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLkNJTkQuX1NUQV0gKE5vZGUg MHhmZmZmZjgwMDA1NDlhMmMwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy9wc3BhcnNlLTU1OSkK QUNQSSBFcnJvcjogTWV0aG9kIGV4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVD LkNJTkQuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhMmMwKSwgQUVfTk9UX0VYSVNUICgyMDE2 MDUyNy91dGV2YWwtMTExKQpBQ1BJIEVycm9yOiBObyBoYW5kbGVyIGZvciBSZWdpb24gW0VDX19d ICgweGZmZmZmODAwMDU0OGZjODApIFtFbWJlZGRlZENvbnRyb2xdICgyMDE2MDUyNy9ldnJlZ2lv bi0xODApCkFDUEkgRXJyb3I6IFJlZ2lvbiBFbWJlZGRlZENvbnRyb2wgKElEPTMpIGhhcyBubyBo YW5kbGVyICgyMDE2MDUyNy9leGZsZGlvLTMyMCkKQUNQSSBFcnJvcjogTWV0aG9kIHBhcnNlL2V4 ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLkNJTkQuX1NUQV0gKE5vZGUgMHhm ZmZmZjgwMDA1NDlhMmMwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy9wc3BhcnNlLTU1OSkKQUNQ SSBFcnJvcjogTWV0aG9kIGV4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLkNJ TkQuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhMmMwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUy Ny91dGV2YWwtMTExKQpBQ1BJIEVycm9yOiBObyBoYW5kbGVyIGZvciBSZWdpb24gW0VDX19dICgw eGZmZmZmODAwMDU0OGZjODApIFtFbWJlZGRlZENvbnRyb2xdICgyMDE2MDUyNy9ldnJlZ2lvbi0x ODApCkFDUEkgRXJyb3I6IFJlZ2lvbiBFbWJlZGRlZENvbnRyb2wgKElEPTMpIGhhcyBubyBoYW5k bGVyICgyMDE2MDUyNy9leGZsZGlvLTMyMCkKQUNQSSBFcnJvcjogTWV0aG9kIHBhcnNlL2V4ZWN1 dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLkNJTkQuX1NUQV0gKE5vZGUgMHhmZmZm ZjgwMDA1NDlhMmMwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy9wc3BhcnNlLTU1OSkKQUNQSSBF cnJvcjogTWV0aG9kIGV4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLkNJTkQu X1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhMmMwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy91 dGV2YWwtMTExKQpBQ1BJIEVycm9yOiBObyBoYW5kbGVyIGZvciBSZWdpb24gW0VDX19dICgweGZm ZmZmODAwMDU0OGZjODApIFtFbWJlZGRlZENvbnRyb2xdICgyMDE2MDUyNy9ldnJlZ2lvbi0xODAp CkFDUEkgRXJyb3I6IFJlZ2lvbiBFbWJlZGRlZENvbnRyb2wgKElEPTMpIGhhcyBubyBoYW5kbGVy ICgyMDE2MDUyNy9leGZsZGlvLTMyMCkKQUNQSSBFcnJvcjogTWV0aG9kIHBhcnNlL2V4ZWN1dGlv biBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLkNJTkQuX1NUQV0gKE5vZGUgMHhmZmZmZjgw MDA1NDlhMmMwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy9wc3BhcnNlLTU1OSkKQUNQSSBFcnJv cjogTWV0aG9kIGV4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLkNJTkQuX1NU QV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhMmMwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy91dGV2 YWwtMTExKQpBQ1BJIEVycm9yOiBObyBoYW5kbGVyIGZvciBSZWdpb24gW0VDX19dICgweGZmZmZm ODAwMDU0OGZjODApIFtFbWJlZGRlZENvbnRyb2xdICgyMDE2MDUyNy9ldnJlZ2lvbi0xODApCkFD UEkgRXJyb3I6IFJlZ2lvbiBFbWJlZGRlZENvbnRyb2wgKElEPTMpIGhhcyBubyBoYW5kbGVyICgy MDE2MDUyNy9leGZsZGlvLTMyMCkKQUNQSSBFcnJvcjogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBm YWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLkNJTkQuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1 NDlhMmMwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy9wc3BhcnNlLTU1OSkKQUNQSSBFcnJvcjog TWV0aG9kIGV4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLkNJTkQuX1NUQV0g KE5vZGUgMHhmZmZmZjgwMDA1NDlhMmMwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy91dGV2YWwt MTExKQpBQ1BJIEVycm9yOiBObyBoYW5kbGVyIGZvciBSZWdpb24gW0VDX19dICgweGZmZmZmODAw MDU0OGZjODApIFtFbWJlZGRlZENvbnRyb2xdICgyMDE2MDUyNy9ldnJlZ2lvbi0xODApCkFDUEkg RXJyb3I6IFJlZ2lvbiBFbWJlZGRlZENvbnRyb2wgKElEPTMpIGhhcyBubyBoYW5kbGVyICgyMDE2 MDUyNy9leGZsZGlvLTMyMCkKQUNQSSBFcnJvcjogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWls ZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLkNJTkQuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlh MmMwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy9wc3BhcnNlLTU1OSkKQUNQSSBFcnJvcjogTWV0 aG9kIGV4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLkNJTkQuX1NUQV0gKE5v ZGUgMHhmZmZmZjgwMDA1NDlhMmMwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy91dGV2YWwtMTEx KQpBQ1BJIEVycm9yOiBObyBoYW5kbGVyIGZvciBSZWdpb24gW0VDX19dICgweGZmZmZmODAwMDU0 OGZjODApIFtFbWJlZGRlZENvbnRyb2xdICgyMDE2MDUyNy9ldnJlZ2lvbi0xODApCkFDUEkgRXJy b3I6IFJlZ2lvbiBFbWJlZGRlZENvbnRyb2wgKElEPTMpIGhhcyBubyBoYW5kbGVyICgyMDE2MDUy Ny9leGZsZGlvLTMyMCkKQUNQSSBFcnJvcjogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQg W1wxMzRfU0IuUENJMC5MUENCLkVDLlZHQkkuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhMTgw KSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy9wc3BhcnNlLTU1OSkKQUNQSSBFcnJvcjogTWV0aG9k IGV4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLlZHQkkuX1NUQV0gKE5vZGUg MHhmZmZmZjgwMDA1NDlhMTgwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy91dGV2YWwtMTExKQpB Q1BJIEVycm9yOiBObyBoYW5kbGVyIGZvciBSZWdpb24gW0VDX19dICgweGZmZmZmODAwMDU0OGZj ODApIFtFbWJlZGRlZENvbnRyb2xdICgyMDE2MDUyNy9ldnJlZ2lvbi0xODApCkFDUEkgRXJyb3I6 IFJlZ2lvbiBFbWJlZGRlZENvbnRyb2wgKElEPTMpIGhhcyBubyBoYW5kbGVyICgyMDE2MDUyNy9l eGZsZGlvLTMyMCkKQUNQSSBFcnJvcjogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1wx MzRfU0IuUENJMC5MUENCLkVDLlZHQkkuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhMTgwKSwg QUVfTk9UX0VYSVNUICgyMDE2MDUyNy9wc3BhcnNlLTU1OSkKQUNQSSBFcnJvcjogTWV0aG9kIGV4 ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLlZHQkkuX1NUQV0gKE5vZGUgMHhm ZmZmZjgwMDA1NDlhMTgwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy91dGV2YWwtMTExKQpBQ1BJ IEVycm9yOiBObyBoYW5kbGVyIGZvciBSZWdpb24gW0VDX19dICgweGZmZmZmODAwMDU0OGZjODAp IFtFbWJlZGRlZENvbnRyb2xdICgyMDE2MDUyNy9ldnJlZ2lvbi0xODApCkFDUEkgRXJyb3I6IFJl Z2lvbiBFbWJlZGRlZENvbnRyb2wgKElEPTMpIGhhcyBubyBoYW5kbGVyICgyMDE2MDUyNy9leGZs ZGlvLTMyMCkKQUNQSSBFcnJvcjogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1wxMzRf U0IuUENJMC5MUENCLkVDLlZHQkkuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhMTgwKSwgQUVf Tk9UX0VYSVNUICgyMDE2MDUyNy9wc3BhcnNlLTU1OSkKQUNQSSBFcnJvcjogTWV0aG9kIGV4ZWN1 dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLlZHQkkuX1NUQV0gKE5vZGUgMHhmZmZm ZjgwMDA1NDlhMTgwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy91dGV2YWwtMTExKQpBQ1BJIEVy cm9yOiBObyBoYW5kbGVyIGZvciBSZWdpb24gW0VDX19dICgweGZmZmZmODAwMDU0OGZjODApIFtF bWJlZGRlZENvbnRyb2xdICgyMDE2MDUyNy9ldnJlZ2lvbi0xODApCkFDUEkgRXJyb3I6IFJlZ2lv biBFbWJlZGRlZENvbnRyb2wgKElEPTMpIGhhcyBubyBoYW5kbGVyICgyMDE2MDUyNy9leGZsZGlv LTMyMCkKQUNQSSBFcnJvcjogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0Iu UENJMC5MUENCLkVDLlZHQkkuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhMTgwKSwgQUVfTk9U X0VYSVNUICgyMDE2MDUyNy9wc3BhcnNlLTU1OSkKQUNQSSBFcnJvcjogTWV0aG9kIGV4ZWN1dGlv biBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLlZHQkkuX1NUQV0gKE5vZGUgMHhmZmZmZjgw MDA1NDlhMTgwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy91dGV2YWwtMTExKQpBQ1BJIEVycm9y OiBObyBoYW5kbGVyIGZvciBSZWdpb24gW0VDX19dICgweGZmZmZmODAwMDU0OGZjODApIFtFbWJl ZGRlZENvbnRyb2xdICgyMDE2MDUyNy9ldnJlZ2lvbi0xODApCkFDUEkgRXJyb3I6IFJlZ2lvbiBF bWJlZGRlZENvbnRyb2wgKElEPTMpIGhhcyBubyBoYW5kbGVyICgyMDE2MDUyNy9leGZsZGlvLTMy MCkKQUNQSSBFcnJvcjogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJ MC5MUENCLkVDLlZHQkkuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhMTgwKSwgQUVfTk9UX0VY SVNUICgyMDE2MDUyNy9wc3BhcnNlLTU1OSkKQUNQSSBFcnJvcjogTWV0aG9kIGV4ZWN1dGlvbiBm YWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLlZHQkkuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1 NDlhMTgwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy91dGV2YWwtMTExKQpBQ1BJIEVycm9yOiBO byBoYW5kbGVyIGZvciBSZWdpb24gW0VDX19dICgweGZmZmZmODAwMDU0OGZjODApIFtFbWJlZGRl ZENvbnRyb2xdICgyMDE2MDUyNy9ldnJlZ2lvbi0xODApCkFDUEkgRXJyb3I6IFJlZ2lvbiBFbWJl ZGRlZENvbnRyb2wgKElEPTMpIGhhcyBubyBoYW5kbGVyICgyMDE2MDUyNy9leGZsZGlvLTMyMCkK QUNQSSBFcnJvcjogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5M UENCLkVDLlZHQkkuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhMTgwKSwgQUVfTk9UX0VYSVNU ICgyMDE2MDUyNy9wc3BhcnNlLTU1OSkKQUNQSSBFcnJvcjogTWV0aG9kIGV4ZWN1dGlvbiBmYWls ZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLlZHQkkuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlh MTgwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy91dGV2YWwtMTExKQpBQ1BJIEVycm9yOiBObyBo YW5kbGVyIGZvciBSZWdpb24gW0VDX19dICgweGZmZmZmODAwMDU0OGZjODApIFtFbWJlZGRlZENv bnRyb2xdICgyMDE2MDUyNy9ldnJlZ2lvbi0xODApCkFDUEkgRXJyb3I6IFJlZ2lvbiBFbWJlZGRl ZENvbnRyb2wgKElEPTMpIGhhcyBubyBoYW5kbGVyICgyMDE2MDUyNy9leGZsZGlvLTMyMCkKQUNQ SSBFcnJvcjogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENC LkVDLlZHQkkuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhMTgwKSwgQUVfTk9UX0VYSVNUICgy MDE2MDUyNy9wc3BhcnNlLTU1OSkKQUNQSSBFcnJvcjogTWV0aG9kIGV4ZWN1dGlvbiBmYWlsZWQg W1wxMzRfU0IuUENJMC5MUENCLkVDLlZHQkkuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhMTgw KSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy91dGV2YWwtMTExKQpBQ1BJIEVycm9yOiBObyBoYW5k bGVyIGZvciBSZWdpb24gW0VDX19dICgweGZmZmZmODAwMDU0OGZjODApIFtFbWJlZGRlZENvbnRy b2xdICgyMDE2MDUyNy9ldnJlZ2lvbi0xODApCkFDUEkgRXJyb3I6IFJlZ2lvbiBFbWJlZGRlZENv bnRyb2wgKElEPTMpIGhhcyBubyBoYW5kbGVyICgyMDE2MDUyNy9leGZsZGlvLTMyMCkKQUNQSSBF cnJvcjogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVD LlZHQkkuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhMTgwKSwgQUVfTk9UX0VYSVNUICgyMDE2 MDUyNy9wc3BhcnNlLTU1OSkKQUNQSSBFcnJvcjogTWV0aG9kIGV4ZWN1dGlvbiBmYWlsZWQgW1wx MzRfU0IuUENJMC5MUENCLkVDLlZHQkkuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhMTgwKSwg QUVfTk9UX0VYSVNUICgyMDE2MDUyNy91dGV2YWwtMTExKQpBQ1BJIEVycm9yOiBObyBoYW5kbGVy IGZvciBSZWdpb24gW0VDX19dICgweGZmZmZmODAwMDU0OGZjODApIFtFbWJlZGRlZENvbnRyb2xd ICgyMDE2MDUyNy9ldnJlZ2lvbi0xODApCkFDUEkgRXJyb3I6IFJlZ2lvbiBFbWJlZGRlZENvbnRy b2wgKElEPTMpIGhhcyBubyBoYW5kbGVyICgyMDE2MDUyNy9leGZsZGlvLTMyMCkKQUNQSSBFcnJv cjogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLlZH QkkuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhMTgwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUy Ny9wc3BhcnNlLTU1OSkKQUNQSSBFcnJvcjogTWV0aG9kIGV4ZWN1dGlvbiBmYWlsZWQgW1wxMzRf U0IuUENJMC5MUENCLkVDLlZHQkkuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhMTgwKSwgQUVf Tk9UX0VYSVNUICgyMDE2MDUyNy91dGV2YWwtMTExKQpBQ1BJIEVycm9yOiBObyBoYW5kbGVyIGZv ciBSZWdpb24gW0VDX19dICgweGZmZmZmODAwMDU0OGZjODApIFtFbWJlZGRlZENvbnRyb2xdICgy MDE2MDUyNy9ldnJlZ2lvbi0xODApCkFDUEkgRXJyb3I6IFJlZ2lvbiBFbWJlZGRlZENvbnRyb2wg KElEPTMpIGhhcyBubyBoYW5kbGVyICgyMDE2MDUyNy9leGZsZGlvLTMyMCkKQUNQSSBFcnJvcjog TWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLkJBVDEu X1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhNjQwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy9w c3BhcnNlLTU1OSkKQUNQSSBFcnJvcjogTWV0aG9kIGV4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0Iu UENJMC5MUENCLkVDLkJBVDEuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhNjQwKSwgQUVfTk9U X0VYSVNUICgyMDE2MDUyNy91dGV2YWwtMTExKQpBQ1BJIEVycm9yOiBObyBoYW5kbGVyIGZvciBS ZWdpb24gW0VDX19dICgweGZmZmZmODAwMDU0OGZjODApIFtFbWJlZGRlZENvbnRyb2xdICgyMDE2 MDUyNy9ldnJlZ2lvbi0xODApCkFDUEkgRXJyb3I6IFJlZ2lvbiBFbWJlZGRlZENvbnRyb2wgKElE PTMpIGhhcyBubyBoYW5kbGVyICgyMDE2MDUyNy9leGZsZGlvLTMyMCkKQUNQSSBFcnJvcjogTWV0 aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLkJBVDEuX1NU QV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhNjQwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy9wc3Bh cnNlLTU1OSkKQUNQSSBFcnJvcjogTWV0aG9kIGV4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJ MC5MUENCLkVDLkJBVDEuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhNjQwKSwgQUVfTk9UX0VY SVNUICgyMDE2MDUyNy91dGV2YWwtMTExKQpBQ1BJIEVycm9yOiBObyBoYW5kbGVyIGZvciBSZWdp b24gW0VDX19dICgweGZmZmZmODAwMDU0OGZjODApIFtFbWJlZGRlZENvbnRyb2xdICgyMDE2MDUy Ny9ldnJlZ2lvbi0xODApCkFDUEkgRXJyb3I6IFJlZ2lvbiBFbWJlZGRlZENvbnRyb2wgKElEPTMp IGhhcyBubyBoYW5kbGVyICgyMDE2MDUyNy9leGZsZGlvLTMyMCkKQUNQSSBFcnJvcjogTWV0aG9k IHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLkNJTkQuX1NUQV0g KE5vZGUgMHhmZmZmZjgwMDA1NDlhMmMwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy9wc3BhcnNl LTU1OSkKQUNQSSBFcnJvcjogTWV0aG9kIGV4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5M UENCLkVDLkNJTkQuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhMmMwKSwgQUVfTk9UX0VYSVNU ICgyMDE2MDUyNy91dGV2YWwtMTExKQpBQ1BJIEVycm9yOiBObyBoYW5kbGVyIGZvciBSZWdpb24g W0VDX19dICgweGZmZmZmODAwMDU0OGZjODApIFtFbWJlZGRlZENvbnRyb2xdICgyMDE2MDUyNy9l dnJlZ2lvbi0xODApCkFDUEkgRXJyb3I6IFJlZ2lvbiBFbWJlZGRlZENvbnRyb2wgKElEPTMpIGhh cyBubyBoYW5kbGVyICgyMDE2MDUyNy9leGZsZGlvLTMyMCkKQUNQSSBFcnJvcjogTWV0aG9kIHBh cnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLkNJTkQuX1NUQV0gKE5v ZGUgMHhmZmZmZjgwMDA1NDlhMmMwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy9wc3BhcnNlLTU1 OSkKQUNQSSBFcnJvcjogTWV0aG9kIGV4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENC LkVDLkNJTkQuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhMmMwKSwgQUVfTk9UX0VYSVNUICgy MDE2MDUyNy91dGV2YWwtMTExKQpBQ1BJIEVycm9yOiBObyBoYW5kbGVyIGZvciBSZWdpb24gW0VD X19dICgweGZmZmZmODAwMDU0OGZjODApIFtFbWJlZGRlZENvbnRyb2xdICgyMDE2MDUyNy9ldnJl Z2lvbi0xODApCkFDUEkgRXJyb3I6IFJlZ2lvbiBFbWJlZGRlZENvbnRyb2wgKElEPTMpIGhhcyBu byBoYW5kbGVyICgyMDE2MDUyNy9leGZsZGlvLTMyMCkKQUNQSSBFcnJvcjogTWV0aG9kIHBhcnNl L2V4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLlZHQkkuX1NUQV0gKE5vZGUg MHhmZmZmZjgwMDA1NDlhMTgwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy9wc3BhcnNlLTU1OSkK QUNQSSBFcnJvcjogTWV0aG9kIGV4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVD LlZHQkkuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhMTgwKSwgQUVfTk9UX0VYSVNUICgyMDE2 MDUyNy91dGV2YWwtMTExKQpBQ1BJIEVycm9yOiBObyBoYW5kbGVyIGZvciBSZWdpb24gW0VDX19d ICgweGZmZmZmODAwMDU0OGZjODApIFtFbWJlZGRlZENvbnRyb2xdICgyMDE2MDUyNy9ldnJlZ2lv bi0xODApCkFDUEkgRXJyb3I6IFJlZ2lvbiBFbWJlZGRlZENvbnRyb2wgKElEPTMpIGhhcyBubyBo YW5kbGVyICgyMDE2MDUyNy9leGZsZGlvLTMyMCkKQUNQSSBFcnJvcjogTWV0aG9kIHBhcnNlL2V4 ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLlZHQkkuX1NUQV0gKE5vZGUgMHhm ZmZmZjgwMDA1NDlhMTgwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy9wc3BhcnNlLTU1OSkKQUNQ SSBFcnJvcjogTWV0aG9kIGV4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLlZH QkkuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhMTgwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUy Ny91dGV2YWwtMTExKQpBQ1BJIEVycm9yOiBObyBoYW5kbGVyIGZvciBSZWdpb24gW0VDX19dICgw eGZmZmZmODAwMDU0OGZjODApIFtFbWJlZGRlZENvbnRyb2xdICgyMDE2MDUyNy9ldnJlZ2lvbi0x ODApCkFDUEkgRXJyb3I6IFJlZ2lvbiBFbWJlZGRlZENvbnRyb2wgKElEPTMpIGhhcyBubyBoYW5k bGVyICgyMDE2MDUyNy9leGZsZGlvLTMyMCkKQUNQSSBFcnJvcjogTWV0aG9kIHBhcnNlL2V4ZWN1 dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLkJBVDEuX1NUQV0gKE5vZGUgMHhmZmZm ZjgwMDA1NDlhNjQwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy9wc3BhcnNlLTU1OSkKQUNQSSBF cnJvcjogTWV0aG9kIGV4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLkJBVDEu X1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhNjQwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy91 dGV2YWwtMTExKQpBQ1BJIEVycm9yOiBObyBoYW5kbGVyIGZvciBSZWdpb24gW0VDX19dICgweGZm ZmZmODAwMDU0OGZjODApIFtFbWJlZGRlZENvbnRyb2xdICgyMDE2MDUyNy9ldnJlZ2lvbi0xODAp CkFDUEkgRXJyb3I6IFJlZ2lvbiBFbWJlZGRlZENvbnRyb2wgKElEPTMpIGhhcyBubyBoYW5kbGVy ICgyMDE2MDUyNy9leGZsZGlvLTMyMCkKQUNQSSBFcnJvcjogTWV0aG9kIHBhcnNlL2V4ZWN1dGlv biBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLkJBVDEuX1NUQV0gKE5vZGUgMHhmZmZmZjgw MDA1NDlhNjQwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy9wc3BhcnNlLTU1OSkKQUNQSSBFcnJv cjogTWV0aG9kIGV4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLkJBVDEuX1NU QV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhNjQwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy91dGV2 YWwtMTExKQpBQ1BJIEVycm9yOiBObyBoYW5kbGVyIGZvciBSZWdpb24gW0VDX19dICgweGZmZmZm ODAwMDU0OGZjODApIFtFbWJlZGRlZENvbnRyb2xdICgyMDE2MDUyNy9ldnJlZ2lvbi0xODApCkFD UEkgRXJyb3I6IFJlZ2lvbiBFbWJlZGRlZENvbnRyb2wgKElEPTMpIGhhcyBubyBoYW5kbGVyICgy MDE2MDUyNy9leGZsZGlvLTMyMCkKQUNQSSBFcnJvcjogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBm YWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLkNJTkQuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1 NDlhMmMwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy9wc3BhcnNlLTU1OSkKQUNQSSBFcnJvcjog TWV0aG9kIGV4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLkNJTkQuX1NUQV0g KE5vZGUgMHhmZmZmZjgwMDA1NDlhMmMwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy91dGV2YWwt MTExKQpBQ1BJIEVycm9yOiBObyBoYW5kbGVyIGZvciBSZWdpb24gW0VDX19dICgweGZmZmZmODAw MDU0OGZjODApIFtFbWJlZGRlZENvbnRyb2xdICgyMDE2MDUyNy9ldnJlZ2lvbi0xODApCkFDUEkg RXJyb3I6IFJlZ2lvbiBFbWJlZGRlZENvbnRyb2wgKElEPTMpIGhhcyBubyBoYW5kbGVyICgyMDE2 MDUyNy9leGZsZGlvLTMyMCkKQUNQSSBFcnJvcjogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWls ZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLkNJTkQuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlh MmMwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy9wc3BhcnNlLTU1OSkKQUNQSSBFcnJvcjogTWV0 aG9kIGV4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLkNJTkQuX1NUQV0gKE5v ZGUgMHhmZmZmZjgwMDA1NDlhMmMwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy91dGV2YWwtMTEx KQpBQ1BJIEVycm9yOiBObyBoYW5kbGVyIGZvciBSZWdpb24gW0VDX19dICgweGZmZmZmODAwMDU0 OGZjODApIFtFbWJlZGRlZENvbnRyb2xdICgyMDE2MDUyNy9ldnJlZ2lvbi0xODApCkFDUEkgRXJy b3I6IFJlZ2lvbiBFbWJlZGRlZENvbnRyb2wgKElEPTMpIGhhcyBubyBoYW5kbGVyICgyMDE2MDUy Ny9leGZsZGlvLTMyMCkKQUNQSSBFcnJvcjogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQg W1wxMzRfU0IuUENJMC5MUENCLkVDLlZHQkkuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhMTgw KSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy9wc3BhcnNlLTU1OSkKQUNQSSBFcnJvcjogTWV0aG9k IGV4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLlZHQkkuX1NUQV0gKE5vZGUg MHhmZmZmZjgwMDA1NDlhMTgwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy91dGV2YWwtMTExKQpB Q1BJIEVycm9yOiBObyBoYW5kbGVyIGZvciBSZWdpb24gW0VDX19dICgweGZmZmZmODAwMDU0OGZj ODApIFtFbWJlZGRlZENvbnRyb2xdICgyMDE2MDUyNy9ldnJlZ2lvbi0xODApCkFDUEkgRXJyb3I6 IFJlZ2lvbiBFbWJlZGRlZENvbnRyb2wgKElEPTMpIGhhcyBubyBoYW5kbGVyICgyMDE2MDUyNy9l eGZsZGlvLTMyMCkKQUNQSSBFcnJvcjogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1wx MzRfU0IuUENJMC5MUENCLkVDLlZHQkkuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhMTgwKSwg QUVfTk9UX0VYSVNUICgyMDE2MDUyNy9wc3BhcnNlLTU1OSkKQUNQSSBFcnJvcjogTWV0aG9kIGV4 ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLlZHQkkuX1NUQV0gKE5vZGUgMHhm ZmZmZjgwMDA1NDlhMTgwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy91dGV2YWwtMTExKQpBQ1BJ IEVycm9yOiBObyBoYW5kbGVyIGZvciBSZWdpb24gW0VDX19dICgweGZmZmZmODAwMDU0OGZjODAp IFtFbWJlZGRlZENvbnRyb2xdICgyMDE2MDUyNy9ldnJlZ2lvbi0xODApCkFDUEkgRXJyb3I6IFJl Z2lvbiBFbWJlZGRlZENvbnRyb2wgKElEPTMpIGhhcyBubyBoYW5kbGVyICgyMDE2MDUyNy9leGZs ZGlvLTMyMCkKQUNQSSBFcnJvcjogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1wxMzRf U0IuUENJMC5MUENCLkVDLkJBVDEuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhNjQwKSwgQUVf Tk9UX0VYSVNUICgyMDE2MDUyNy9wc3BhcnNlLTU1OSkKQUNQSSBFcnJvcjogTWV0aG9kIGV4ZWN1 dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLkJBVDEuX1NUQV0gKE5vZGUgMHhmZmZm ZjgwMDA1NDlhNjQwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy91dGV2YWwtMTExKQpBQ1BJIEVy cm9yOiBObyBoYW5kbGVyIGZvciBSZWdpb24gW0VDX19dICgweGZmZmZmODAwMDU0OGZjODApIFtF bWJlZGRlZENvbnRyb2xdICgyMDE2MDUyNy9ldnJlZ2lvbi0xODApCkFDUEkgRXJyb3I6IFJlZ2lv biBFbWJlZGRlZENvbnRyb2wgKElEPTMpIGhhcyBubyBoYW5kbGVyICgyMDE2MDUyNy9leGZsZGlv LTMyMCkKQUNQSSBFcnJvcjogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0Iu UENJMC5MUENCLkVDLkNJTkQuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhMmMwKSwgQUVfTk9U X0VYSVNUICgyMDE2MDUyNy9wc3BhcnNlLTU1OSkKQUNQSSBFcnJvcjogTWV0aG9kIGV4ZWN1dGlv biBmYWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLkNJTkQuX1NUQV0gKE5vZGUgMHhmZmZmZjgw MDA1NDlhMmMwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy91dGV2YWwtMTExKQpBQ1BJIEVycm9y OiBObyBoYW5kbGVyIGZvciBSZWdpb24gW0VDX19dICgweGZmZmZmODAwMDU0OGZjODApIFtFbWJl ZGRlZENvbnRyb2xdICgyMDE2MDUyNy9ldnJlZ2lvbi0xODApCkFDUEkgRXJyb3I6IFJlZ2lvbiBF bWJlZGRlZENvbnRyb2wgKElEPTMpIGhhcyBubyBoYW5kbGVyICgyMDE2MDUyNy9leGZsZGlvLTMy MCkKQUNQSSBFcnJvcjogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1wxMzRfU0IuUENJ MC5MUENCLkVDLlZHQkkuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1NDlhMTgwKSwgQUVfTk9UX0VY SVNUICgyMDE2MDUyNy9wc3BhcnNlLTU1OSkKQUNQSSBFcnJvcjogTWV0aG9kIGV4ZWN1dGlvbiBm YWlsZWQgW1wxMzRfU0IuUENJMC5MUENCLkVDLlZHQkkuX1NUQV0gKE5vZGUgMHhmZmZmZjgwMDA1 NDlhMTgwKSwgQUVfTk9UX0VYSVNUICgyMDE2MDUyNy91dGV2YWwtMTExKQpjcHUwOiA8QUNQSSBD UFU+IG9uIGFjcGkwCmNwdTE6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1MjogPEFDUEkgQ1BVPiBv biBhY3BpMApjcHUzOiA8QUNQSSBDUFU+IG9uIGFjcGkwCmhwZXQwOiA8SGlnaCBQcmVjaXNpb24g RXZlbnQgVGltZXI+IGlvbWVtIDB4ZmVkMDAwMDAtMHhmZWQwMDNmZiBvbiBhY3BpMApUaW1lY291 bnRlciAiSFBFVCIgZnJlcXVlbmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkgOTUwCkV2ZW50IHRpbWVy ICJIUEVUIiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA1NTAKRXZlbnQgdGltZXIgIkhQ RVQxIiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA0NDAKRXZlbnQgdGltZXIgIkhQRVQy IiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA0NDAKRXZlbnQgdGltZXIgIkhQRVQzIiBm cmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA0NDAKRXZlbnQgdGltZXIgIkhQRVQ0IiBmcmVx dWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA0NDAKYXRydGMwOiA8QVQgcmVhbHRpbWUgY2xvY2s+ IHBvcnQgMHg3MC0weDc3IGlycSA4IG9uIGFjcGkwCmF0cnRjMDogV2FybmluZzogQ291bGRuJ3Qg bWFwIEkvTy4KRXZlbnQgdGltZXIgIlJUQyIgZnJlcXVlbmN5IDMyNzY4IEh6IHF1YWxpdHkgMAph dHRpbWVyMDogPEFUIHRpbWVyPiBwb3J0IDB4NDAtMHg0MywweDUwLTB4NTMgaXJxIDAgb24gYWNw aTAKVGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDAKRXZl bnQgdGltZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDEwMApUaW1lY291 bnRlciAiQUNQSS1zYWZlIiBmcmVxdWVuY3kgMzU3OTU0NSBIeiBxdWFsaXR5IDg1MAphY3BpX3Rp bWVyMDogPDI0LWJpdCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDE4MDgtMHgxODBiIG9u IGFjcGkwCmFjcGlfZWMwOiA8RW1iZWRkZWQgQ29udHJvbGxlcjogR1BFIDB4MzQ+IHBvcnQgMHg2 MiwweDY2IG9uIGFjcGkwCnBjaWIwOiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IHBvcnQgMHhjZjgt MHhjZmYgb24gYWNwaTAKcGNpYjA6IF9PU0MgcmV0dXJuZWQgZXJyb3IgMHg0CnBjaTA6IDxBQ1BJ IFBDSSBidXM+IG9uIHBjaWIwCnZnYXBjaTA6IDxWR0EtY29tcGF0aWJsZSBkaXNwbGF5PiBwb3J0 IDB4ZjAwMC0weGYwM2YgbWVtIDB4ZjYwMDAwMDAtMHhmNmZmZmZmZiwweGUwMDAwMDAwLTB4ZWZm ZmZmZmYgYXQgZGV2aWNlIDIuMCBvbiBwY2kwCnZnYXBjaTA6IEJvb3QgdmlkZW8gZGV2aWNlCmhk YWMwOiA8SW50ZWwgQnJvYWR3ZWxsIEhEQSBDb250cm9sbGVyPiBtZW0gMHhmNzMxNDAwMC0weGY3 MzE3ZmZmIGF0IGRldmljZSAzLjAgb24gcGNpMAp4aGNpMDogPEJyb2Fkd2VsbCBJbnRlZ3JhdGVk IFBDSC1MUCBjaGlwc2V0IFVTQiAzLjAgY29udHJvbGxlcj4gbWVtIDB4ZjczMDAwMDAtMHhmNzMw ZmZmZiBhdCBkZXZpY2UgMjAuMCBvbiBwY2kwCnhoY2kwOiAzMiBieXRlcyBjb250ZXh0IHNpemUs IDY0LWJpdCBETUEKeGhjaTA6IFBvcnQgcm91dGluZyBtYXNrIHNldCB0byAweGZmZmZmZmZmCnVz YnVzMCBvbiB4aGNpMApwY2kwOiA8c2ltcGxlIGNvbW1zPiBhdCBkZXZpY2UgMjIuMCAobm8gZHJp dmVyIGF0dGFjaGVkKQpoZGFjMTogPEludGVsIEJyb2Fkd2VsbCBIREEgQ29udHJvbGxlcj4gbWVt IDB4ZjczMTAwMDAtMHhmNzMxM2ZmZiBhdCBkZXZpY2UgMjcuMCBvbiBwY2kwCnBjaWIxOiA8QUNQ SSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDI4LjAgb24gcGNpMApwY2liMTogW0dJQU5ULUxP Q0tFRF0KcGNpYjI6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMjguMiBvbiBwY2kw CnBjaTE6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIyCml3bTA6IDxJbnRlbCBEdWFsIEJhbmQgV2ly ZWxlc3MgQUMgNzI2NT4gbWVtIDB4ZjcyMDAwMDAtMHhmNzIwMWZmZiBhdCBkZXZpY2UgMC4wIG9u IHBjaTEKcGNpYjM6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMjguMyBvbiBwY2kw CnBjaTI6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIzCnBjaTI6IDx1bmtub3duPiBhdCBkZXZpY2Ug MC4wIChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaWI0OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQg ZGV2aWNlIDI4LjUgb24gcGNpMApwY2kzOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNAphaGNpMDog PEFIQ0kgU0FUQSBjb250cm9sbGVyPiBtZW0gMHhmNzAxMDAwMC0weGY3MDExZmZmIGF0IGRldmlj ZSAwLjAgb24gcGNpMwphaGNpMDogQUhDSSB2MS4zMCB3aXRoIDEgNkdicHMgcG9ydHMsIFBvcnQg TXVsdGlwbGllciBub3Qgc3VwcG9ydGVkCmFoY2ljaDA6IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5u ZWwgMCBvbiBhaGNpMAplaGNpMDogPEVIQ0kgKGdlbmVyaWMpIFVTQiAyLjAgY29udHJvbGxlcj4g bWVtIDB4ZjczMTkwMDAtMHhmNzMxOTNmZiBhdCBkZXZpY2UgMjkuMCBvbiBwY2kwCnVzYnVzMTog RUhDSSB2ZXJzaW9uIDEuMAp1c2J1czEgb24gZWhjaTAKaXNhYjA6IDxQQ0ktSVNBIGJyaWRnZT4g YXQgZGV2aWNlIDMxLjAgb24gcGNpMAppc2EwOiA8SVNBIGJ1cz4gb24gaXNhYjAKYWNwaV9idXR0 b24wOiA8UG93ZXIgQnV0dG9uPiBvbiBhY3BpMAphY3BpX3R6MDogPFRoZXJtYWwgWm9uZT4gb24g YWNwaTAKYWNwaV90ejE6IDxUaGVybWFsIFpvbmU+IG9uIGFjcGkwCmFjcGlfdHoyOiA8VGhlcm1h bCBab25lPiBvbiBhY3BpMAphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBw b3J0IDB4NjAsMHg2NCBpcnEgMSBvbiBhY3BpMAphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEg b24gYXRrYmRjMAprYmQwIGF0IGF0a2JkMAphdGtiZDA6IFtHSUFOVC1MT0NLRURdCnBzbTA6IDxQ Uy8yIE1vdXNlPiBpcnEgMTIgb24gYXRrYmRjMApwc20wOiBbR0lBTlQtTE9DS0VEXQpwc20wOiBt b2RlbCBFbGFudGVjaCBUb3VjaHBhZCwgZGV2aWNlIElEIDAKYWNwaV9hY2FkMDogPEFDIEFkYXB0 ZXI+IG9uIGFjcGkwCmJhdHRlcnkwOiA8QUNQSSBDb250cm9sIE1ldGhvZCBCYXR0ZXJ5PiBvbiBh Y3BpMAphY3BpX2xpZDA6IDxDb250cm9sIE1ldGhvZCBMaWQgU3dpdGNoPiBvbiBhY3BpMApwcGMw OiBjYW5ub3QgcmVzZXJ2ZSBJL08gcG9ydCByYW5nZQpjb3JldGVtcDA6IDxDUFUgT24tRGllIFRo ZXJtYWwgU2Vuc29ycz4gb24gY3B1MAplc3QwOiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5j eSBDb250cm9sPiBvbiBjcHUwCmNvcmV0ZW1wMTogPENQVSBPbi1EaWUgVGhlcm1hbCBTZW5zb3Jz PiBvbiBjcHUxCmVzdDE6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9u IGNwdTEKY29yZXRlbXAyOiA8Q1BVIE9uLURpZSBUaGVybWFsIFNlbnNvcnM+IG9uIGNwdTIKZXN0 MjogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1Mgpjb3JldGVt cDM6IDxDUFUgT24tRGllIFRoZXJtYWwgU2Vuc29ycz4gb24gY3B1Mwplc3QzOiA8RW5oYW5jZWQg U3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUzCnVzYnVzMDogNS4wR2JwcyBTdXBl ciBTcGVlZCBVU0IgdjMuMApaRlMgZmlsZXN5c3RlbSB2ZXJzaW9uOiA1ClpGUyBzdG9yYWdlIHBv b2wgdmVyc2lvbjogZmVhdHVyZXMgc3VwcG9ydCAoNTAwMCkKVGltZWNvdW50ZXJzIHRpY2sgZXZl cnkgMS4wMDAgbXNlYwpoZGFjYzA6IDxJbnRlbCBCcm9hZHdlbGwgSERBIENPREVDPiBhdCBjYWQg MCBvbiBoZGFjMApoZGFhMDogPEludGVsIEJyb2Fkd2VsbCBBdWRpbyBGdW5jdGlvbiBHcm91cD4g YXQgbmlkIDEgb24gaGRhY2MwCnBjbTA6IDxJbnRlbCBCcm9hZHdlbGwgKEhETUkvRFAgOGNoKT4g YXQgbmlkIDMgb24gaGRhYTAKaGRhY2MxOiA8UmVhbHRlayAoMHgwMjg2KSBIREEgQ09ERUM+IGF0 IGNhZCAwIG9uIGhkYWMxCmhkYWExOiA8UmVhbHRlayAoMHgwMjg2KSBBdWRpbyBGdW5jdGlvbiBH cm91cD4gYXQgbmlkIDEgb24gaGRhY2MxCnBjbTE6IDxSZWFsdGVrICgweDAyODYpIChJbnRlcm5h bCBBbmFsb2cpPiBhdCBuaWQgMjAgYW5kIDE4IG9uIGhkYWExCnBjbTI6IDxSZWFsdGVrICgweDAy ODYpIChSaWdodCBBbmFsb2cpPiBhdCBuaWQgMzMgYW5kIDI0IG9uIGhkYWExCnVzYnVzMTogNDgw TWJwcyBIaWdoIFNwZWVkIFVTQiB2Mi4wCnVnZW4wLjE6IDwweDgwODY+IGF0IHVzYnVzMAp1aHVi MDogPDB4ODA4NiBYSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAzLjAwLzEuMDAsIGFkZHIg MT4gb24gdXNidXMwCnVnZW4xLjE6IDxJbnRlbD4gYXQgdXNidXMxCnVodWIxOiA8SW50ZWwgRUhD SSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMQph ZGEwIGF0IGFoY2ljaDAgYnVzIDAgc2NidXMwIHRhcmdldCAwIGx1biAwCmFkYTA6IDxTQU1TVU5H IE1aSFBVNTEySENHTC0wMDBMMSBVWE02NUwxUT4gQUNTLTIgQVRBIFNBVEEgMy54IGRldmljZQph ZGEwOiBTZXJpYWwgTnVtYmVyIFMxSlROWUFHMzAwMTk3CmFkYTA6IDYwMC4wMDBNQi9zIHRyYW5z ZmVycyAoU0FUQSAzLngsIFVETUE2LCBQSU8gODE5MmJ5dGVzKQphZGEwOiBDb21tYW5kIFF1ZXVl aW5nIGVuYWJsZWQKYWRhMDogNDg4Mzg2TUIgKDEwMDAyMTUyMTYgNTEyIGJ5dGUgc2VjdG9ycykK dWh1YjA6IDE1IHBvcnRzIHdpdGggMTUgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKaXdtMDogaHcg cmV2IDB4MjEwLCBmdyB2ZXIgMTYuMjQyNDE0LjAsIGFkZHJlc3MgMzQ6MDI6ODY6MzQ6MTM6MTgK U01QOiBBUCBDUFUgIzEgTGF1bmNoZWQhClNNUDogQVAgQ1BVICMyIExhdW5jaGVkIQpTTVA6IEFQ IENQVSAjMyBMYXVuY2hlZCEKVGltZWNvdW50ZXIgIlRTQy1sb3ciIGZyZXF1ZW5jeSAxMTk3MjUz NjE4IEh6IHF1YWxpdHkgMTAwMApUcnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIHpmczp6cm9vdC9S T09UL3IzMDMzMzYgW10uLi4KUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXMxIHVzYnVzMAp1 aHViMTogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWdlbjAuMjogPHZl bmRvciAweDgwODc+IGF0IHVzYnVzMAp1Z2VuMS4yOiA8dmVuZG9yIDB4ODA4Nz4gYXQgdXNidXMx CnVodWIyOiA8dmVuZG9yIDB4ODA4NyBwcm9kdWN0IDB4ODAwMSwgY2xhc3MgOS8wLCByZXYgMi4w MC8wLjAzLCBhZGRyIDI+IG9uIHVzYnVzMQpSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czEg dXNidXMwCnVnZW4wLjM6IDxTdVlpbj4gYXQgdXNidXMwCnVodWIyOiA4IHBvcnRzIHdpdGggOCBy ZW1vdmFibGUsIHNlbGYgcG93ZXJlZApHRU9NX0VMSTogRGV2aWNlIGFkYTBwNy5lbGkgY3JlYXRl ZC4KR0VPTV9FTEk6IEVuY3J5cHRpb246IEFFUy1YVFMgMTI4CkdFT01fRUxJOiAgICAgQ3J5cHRv OiBoYXJkd2FyZQp3bGFuMDogRXRoZXJuZXQgYWRkcmVzczogMzQ6MDI6ODY6MzQ6MTM6MTgKdWJ0 MDogPHZlbmRvciAweDgwODcgcHJvZHVjdCAweDBhMmEsIGNsYXNzIDIyNC8xLCByZXYgMi4wMS8w LjAxLCBhZGRyIDE+IG9uIHVzYnVzMApXQVJOSU5HOiBhdHRlbXB0IHRvIGRvbWFpbl9hZGQoYmx1 ZXRvb3RoKSBhZnRlciBkb21haW5maW5hbGl6ZSgpCldBUk5JTkc6IGF0dGVtcHQgdG8gZG9tYWlu X2FkZChuZXRncmFwaCkgYWZ0ZXIgZG9tYWluZmluYWxpemUoKQppd20wOiBpd21fdXBkYXRlX2Vk Y2E6IGNhbGxlZAppd20wOiBpd21fdXBkYXRlX2VkY2E6IGNhbGxlZAp3bGFuMDogbGluayBzdGF0 ZSBjaGFuZ2VkIHRvIFVQCnBpZCAxMDUzICh4ZmNlNC1wb3dlci1tYW5hZ2VyKSwgdWlkIDEwMDE6 IGV4aXRlZCBvbiBzaWduYWwgMTEK --94eb2c07c694c51b0f0538e7f712-- From owner-freebsd-current@freebsd.org Sun Jul 31 05:51: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 02387BA97B5 for ; Sun, 31 Jul 2016 05:51:31 +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 E5DB618CF; Sun, 31 Jul 2016 05:51:30 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id D97B81D3; Sun, 31 Jul 2016 05:51:30 +0000 (UTC) Date: Sun, 31 Jul 2016 05:51:30 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <1297226687.76.1469944290553.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <875526055.75.1469934612974.JavaMail.jenkins@jenkins-9.freebsd.org> References: <875526055.75.1469934612974.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_HEAD #510 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 31 Jul 2016 05:51:31 -0000 See From owner-freebsd-current@freebsd.org Sun Jul 31 06:21: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 3DBF4BA9FDB for ; Sun, 31 Jul 2016 06:21:03 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 DV Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 27AC6158B for ; Sun, 31 Jul 2016 06:21:03 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from Xins-MBP.home.us.delphij.net (unknown [IPv6:2601:646:8880:a197:3410:fdc4:99b2:fa31]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id C01B61CB18; Sat, 30 Jul 2016 23:21:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1469946062; x=1469960462; bh=mG5WDXlG2RcsOkxfAE2ItPjliLxte5UznJuaql6ThfY=; h=Cc:To:From:Subject:Date; b=i+xdsc6vxAwwQMFhatXQOomR22gTV1tbOKkHqa06ecX7X3P2vk/wrgraIE7XBPLb3 p7N1LNaS5dDyOCLvh1KqHvb+gMQzCJnRjX8bPWHrfPHP/1jxgWBOYZt1KYnCBN1DP5 S2G1sf0sLMkhLsL60aMQGoNf/RUrasIs7HbtEMxM= Cc: d@delphij.net To: FreeBSD Current From: Xin Li Subject: EFI boot: can we make loader.efi work as BOOT{x64, aa64, arm, ia32}.efi? Message-ID: <5bf35d8a-9941-9c6e-ea0a-20827ad26466@delphij.net> Date: Sat, 30 Jul 2016 23:20:55 -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 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rPuI7bTM0iJvKv2IX5pBIJno1HpmTjfb6" 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, 31 Jul 2016 06:21:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rPuI7bTM0iJvKv2IX5pBIJno1HpmTjfb6 Content-Type: multipart/mixed; boundary="6Wk2O7v37x9ioVdbH0DFUM1ulters44fB" From: Xin Li To: FreeBSD Current Cc: d@delphij.net Message-ID: <5bf35d8a-9941-9c6e-ea0a-20827ad26466@delphij.net> Subject: EFI boot: can we make loader.efi work as BOOT{x64,aa64,arm,ia32}.efi? --6Wk2O7v37x9ioVdbH0DFUM1ulters44fB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I finally got some time to explore the UEFI boot process (kudos to everyone who made this work!) and getting myself familiarize with the basics. One quick question -- Is there some technical restriction that prevents us from merging boot1.efi and loader.efi into one binary? Cheers, --6Wk2O7v37x9ioVdbH0DFUM1ulters44fB-- --rPuI7bTM0iJvKv2IX5pBIJno1HpmTjfb6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXnZjNAAoJEJW2GBstM+ns/2cP/1k45CKlQKpTqBwrJzLv+b9s YpUOmEoofDsZeNUfkMTBS1v3Tsc8bSvhqjDvx1wXkSWmcEuNsdV1CJr9JejyODiM gcVeOHsxB50Yqdx321fLKYeHdcM08qkvey4q90V7trqwlOnxfMwmXmTD298AS92K yEg7e/gg49FtBGGdcCWTNC39dR/qYmysA3aNE8IuAK5a0Jx8hqJ7/AnhvXJ5c51t AGlaarM/yBF0kI44dNvCw8zRaqJ4XOpIAEoqSIwP4Xbm8JrLxubD89x6zNIbbkIN 0neXfhubo9D8puzOZl4QkV32uDMaBHv9/U65F/Yfb5ihMoJV6UrDASXBhWezcec8 epcUS2Hawh5Ogd15tP7HQ7nCMDrw08C0l16VmJLgo25BKR3WbZpafBDYNifbvSuZ irjRbP/n38SYg0HdXCNV/i6pyEsxBNHVybWhsZyYfOpUrLg5IeSyS/4MJO2i3tHX 2rg9POMJh6eP8PzDnjjAJjWpFpv9mQBTUKChB/Mvv18an6yF0CwyeMT2ilHDphvY 8cqKJNMjVVzjP1RPefOFt+ZyW65SEI+RvMPSJhHarjrQb0njTxXwyZPDmr9ZKQN8 oU2mQmMCr/V7YxX3UnDOK4CV8Bh8FSzit02ig0X+cHM81rcjJMyu+A+PlsgLv/cH N56YdpWvRAI5lYFsM5iv =nfjY -----END PGP SIGNATURE----- --rPuI7bTM0iJvKv2IX5pBIJno1HpmTjfb6-- From owner-freebsd-current@freebsd.org Sun Jul 31 06:51: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 56DF1BA9A70 for ; Sun, 31 Jul 2016 06:51:36 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (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 456E41DB8 for ; Sun, 31 Jul 2016 06:51:35 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u6V6pXSg021028 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sat, 30 Jul 2016 23:51:34 -0700 Subject: Re: EFI boot: can we make loader.efi work as BOOT{x64, aa64, arm, ia32}.efi? To: freebsd-current@freebsd.org References: <5bf35d8a-9941-9c6e-ea0a-20827ad26466@delphij.net> From: Nathan Whitehorn Message-ID: <5489f1ff-d6db-c0e3-2be3-d3ae115a1f85@freebsd.org> Date: Sat, 30 Jul 2016 23:51:33 -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: <5bf35d8a-9941-9c6e-ea0a-20827ad26466@delphij.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVZdbkwf1vBqircHmv/cDS2dQEfrGZMRxzNu4p3AJSqgKA4wcB45txF+HecY2K5t2lJHuPdZff6zESeH81XwyKviWnZEs6+UsXM= X-Sonic-ID: C;vNoaOOtW5hGm1q/hcgQksw== M;mn1YOOtW5hGm1q/hcgQksw== 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: Sun, 31 Jul 2016 06:51:36 -0000 On 07/30/16 23:20, Xin Li wrote: > Hi, > > I finally got some time to explore the UEFI boot process (kudos to > everyone who made this work!) and getting myself familiarize with the > basics. > > One quick question -- Is there some technical restriction that prevents > us from merging boot1.efi and loader.efi into one binary? > > Cheers, > No technical reason (and, in fact, when you boot from CD, that's how it works). The reason they are different is that we traditionally don't mount the EFI partition and so make installworld can't replace things there. boot1.efi is a basically static piece of code that doesn't need updates and can load loader, which does get updates, from a UFS/ZFS system. loader.efi additionally assumes that it is started from the same partition that contains the kernel, loader.conf, fstab, etc., which are also generally not on the EFI partition (except in the CD case). -Nathan From owner-freebsd-current@freebsd.org Sun Jul 31 09:04: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 5B6C0BA8B57 for ; Sun, 31 Jul 2016 09:04:42 +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 4DC6B1C1B; Sun, 31 Jul 2016 09:04:42 +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 6F9961D7; Sun, 31 Jul 2016 09:04:42 +0000 (UTC) Date: Sun, 31 Jul 2016 09:04:41 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <646480984.77.1469955881629.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1297226687.76.1469944290553.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1297226687.76.1469944290553.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to stable : FreeBSD_HEAD #511 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: Sun, 31 Jul 2016 09:04:42 -0000 See From owner-freebsd-current@freebsd.org Sun Jul 31 09:29:20 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7AD66BA9091 for ; Sun, 31 Jul 2016 09:29:20 +0000 (UTC) (envelope-from gljennjohn@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 57E281643 for ; Sun, 31 Jul 2016 09:29:20 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 53BF8BA9090; Sun, 31 Jul 2016 09:29:20 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 50FF7BA908D for ; Sun, 31 Jul 2016 09:29:20 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C1C661641; Sun, 31 Jul 2016 09:29:19 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm0-x241.google.com with SMTP id i5so21874021wmg.2; Sun, 31 Jul 2016 02:29:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=mFuS5HPOXNsETAw/Gih3v76/pxblVA6ApY0KAo8Cw9g=; b=AMfdNS5KL+H/HJLfyllSyMmEfPOsWqIE3vLygb4SzlGXEEq/CW8/LGkVmjCb5lWQmW xAMoxWeaNAOu2ZQeHy098ymUhnemcG127hW62yrMe3WeNUg1w4ajA71UzgsblxTkJ8kv NtwnWMjT0TLhjeHER4JoT3qBoY9dG6DAKrFXZC5Sc9qPMNB43LHfophlY2+44bq4Hzuy 2dBp9qRnahE4GPxpsCWsUS4NuVDBIS2sCJgLarOvR4IOHUoCn67eyigdsYZChHdS6KbP LrN+dg2twSnICeJDu90qPOWcTqv0rMqEGKpBikG8zzZAh8pN0alZI0n/1XZF6KSwFwRT WqjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=mFuS5HPOXNsETAw/Gih3v76/pxblVA6ApY0KAo8Cw9g=; b=AjpEIyy4y2cMQ5wfbKDv51uo7Z6u0Vlc0zJvE8gW8lW7o1XjS9qlGHP4NskHcy5DrR 2MDXar5d01v6B/K9SrSn4lRvW9NKgO3epeMoUyGlvKrg1BNHxSEK70FuP9d3g3AWcujI ZzBj5WU+awi2li81DuH3O6LsDK41+mAMwPxAQ61NC4eNX0R2YXHfZFUpnoDLOm88ihvq Mt97PDKqbLnGQ6Fw5gIuQ9ywJO/R1//yW0ETL07YvIn5H+EYooVOjkaBJA9IsT6IB7cC 4sHZJ6++3X028G1y5SNylU5FHr/M54eY4c5QVzh8/QJgiTIy/LPz3Qae2UQIIwLK0eFe sEyw== X-Gm-Message-State: AEkoouvx/weww+nhgZc2WvG9P2RKcIP9Z6qH9YscUQkOujX7c0BQ2Sxi+TdSmZA0SeIkhg== X-Received: by 10.194.23.39 with SMTP id j7mr46523578wjf.4.1469957357230; Sun, 31 Jul 2016 02:29:17 -0700 (PDT) Received: from ernst.home (p578E192D.dip0.t-ipconnect.de. [87.142.25.45]) by smtp.gmail.com with ESMTPSA id r13sm11347320wmf.12.2016.07.31.02.29.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 31 Jul 2016 02:29:16 -0700 (PDT) Date: Sun, 31 Jul 2016 11:29:14 +0200 From: Gary Jennejohn To: John Baldwin Cc: current@freebsd.org Subject: Re: EARLY_AP_STARTUP hangs during boot Message-ID: <20160731112914.58bd9765@ernst.home> In-Reply-To: <8097239.52FCHCROUA@ralph.baldwin.cx> References: <20160516122242.39249a54@ernst.home> <2732687.Cf9hD9SkSs@ralph.baldwin.cx> <20160730094422.68e1b8db@ernst.home> <8097239.52FCHCROUA@ralph.baldwin.cx> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 31 Jul 2016 09:29:20 -0000 On Sat, 30 Jul 2016 12:03:59 -0700 John Baldwin wrote: > On Saturday, July 30, 2016 09:44:22 AM Gary Jennejohn wrote: > > On Fri, 29 Jul 2016 13:17:42 -0700 > > John Baldwin wrote: > > > > > On Thursday, July 28, 2016 12:31:31 AM Gary Jennejohn wrote: > > > > Well, now I know that ULE is a prerequiste for EARLY_AP_STARTUP! I > > > > wasn't aware of that. I prefer BSD and that's the scheduler I did > > > > the first tests with. > > > > > > > > But with the ULE scheduler the system comes up all the way. > > > > > > > > It would be nice if the BSD scheduler could also be modified to > > > > work with EARLY_AP_STARTUP. > > > > > > I wasn't able to reproduce your hang with 4BSD, but I think I see a > > > possible problem. Try this: > > > > > > diff --git a/sys/kern/sched_4bsd.c b/sys/kern/sched_4bsd.c > > > index 7de56b6..d53331a 100644 > > > --- a/sys/kern/sched_4bsd.c > > > +++ b/sys/kern/sched_4bsd.c > > > @@ -327,7 +327,6 @@ maybe_preempt(struct thread *td) > > > * - The current thread has a higher (numerically lower) or > > > * equivalent priority. Note that this prevents curthread from > > > * trying to preempt to itself. > > > - * - It is too early in the boot for context switches (cold is set). > > > * - The current thread has an inhibitor set or is in the process of > > > * exiting. In this case, the current thread is about to switch > > > * out anyways, so there's no point in preempting. If we did, > > > @@ -348,7 +347,7 @@ maybe_preempt(struct thread *td) > > > ("maybe_preempt: trying to run inhibited thread")); > > > pri = td->td_priority; > > > cpri = ctd->td_priority; > > > - if (panicstr != NULL || pri >= cpri || cold /* || dumping */ || > > > + if (panicstr != NULL || pri >= cpri /* || dumping */ || > > > TD_IS_INHIBITED(ctd)) > > > return (0); > > > #ifndef FULL_PREEMPTION > > > @@ -1127,7 +1126,7 @@ forward_wakeup(int cpunum) > > > if ((!forward_wakeup_enabled) || > > > (forward_wakeup_use_mask == 0 && forward_wakeup_use_loop == 0)) > > > return (0); > > > - if (!smp_started || cold || panicstr) > > > + if (!smp_started || panicstr) > > > return (0); > > > > > > forward_wakeups_requested++; > > > > > > > Thanks, but with this patch the kernel hangs in exactly the same > > place as before - after the HPET output. > > > > Maybe I'm missing some kernel option which ULE works around, or > > something like that. > > Hmm, ok. Please add KTR_RUNQ and KTR_SMP to the KTR masks, that is > 'options KTR_COMPILE=(KTR_PROC|KTR_RUNQ|KTR_SMP)' and > 'options KTR_MASK=(KTR_PROC|KTR_RUNQ|KTR_SMP)' > > Please also add this patch (on top of the previous patch): > > diff --git a/sys/kern/sched_4bsd.c b/sys/kern/sched_4bsd.c > index 2973a23..bab2278 100644 > --- a/sys/kern/sched_4bsd.c > +++ b/sys/kern/sched_4bsd.c > @@ -1278,6 +1278,8 @@ sched_add(struct thread *td, int flags) > KASSERT(td->td_flags & TDF_INMEM, > ("sched_add: thread swapped out")); > > + CTR2(KTR_PROC, "sched_add: thread %d (%s)", td->td_tid, > + sched_tdname(td)); > KTR_STATE2(KTR_SCHED, "thread", sched_tdname(td), "runq add", > "prio:%d", td->td_priority, KTR_ATTR_LINKED, > sched_tdname(curthread)); > diff --git a/sys/x86/x86/cpu_machdep.c b/sys/x86/x86/cpu_machdep.c > index f07b97e..1f418f1 100644 > --- a/sys/x86/x86/cpu_machdep.c > +++ b/sys/x86/x86/cpu_machdep.c > @@ -440,6 +440,7 @@ cpu_idle_wakeup(int cpu) > return (0); > if (*state == STATE_MWAIT) > *state = STATE_RUNNING; > + CTR1(KTR_PROC, "cpu_idle_wakeup: wokeup CPU %d", cpu); > return (1); > } > > (I haven't tried compiling it, you might have to add the sys/ktr.h > header to cpu_machdep.c if it doesn't build.) > > Hopefully we will get some better trace messages before it hangs > with this added info. The root issue seems to be that 4BSD is > pinning thread0 to some other CPU (due to sched_bind that happens > inside of bus_bind_intr() when the HPET driver pins IRQs to CPUs) > and that other CPU isn't waking up to realize it needs to run thread0. > It compiled with no changes needed. Even though I set MAXCPU to a mere 2, the boot still hadn't completed after 90 minutes and I broke it off. I still have the kernel, so I can try it another time when I have less need for my FreeBSD box. -- Gary Jennejohn From owner-freebsd-current@freebsd.org Sun Jul 31 09:57: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 B3F0EBA958A for ; Sun, 31 Jul 2016 09:57:12 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2B17D135B; Sun, 31 Jul 2016 09:57:12 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-wm0-x244.google.com with SMTP id o80so21931564wme.0; Sun, 31 Jul 2016 02:57:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:mime-version :content-disposition:user-agent; bh=hiUtBbGbBMdWzWRp56EtbsHyVImADhjIzbJnuMUmT5o=; b=GS3FRAq+PVBy9wHBRhcocrxl03L5j6EuXsZH1m9PA0szCmlXeKhuG5sXuKhkqSqAWW isjY9KdgmI540DKsUItiN/bmUjy23BDiiHQecNRNpGg0AP8gUBST8gSB3V2Fnjf6TefB Lew8c7S5nhBwawom2ErCHaquZlJefh7LcSd5NaQixP+jP82Z5my/ZURSHPyuRTukZuQZ IoXZEInj9mPY434TfVJ5dYw7p5kVK0EAY/Plt381g4t+/0HQu+nSozrOmbOzzhyKIBlj f0PePAcf5TfRAeu9guHzGstaPF9CWJ50P3zQXijNstbEa4a0utnocuzORGdBtPMhKEAh KH2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:mime-version:content-disposition:user-agent; bh=hiUtBbGbBMdWzWRp56EtbsHyVImADhjIzbJnuMUmT5o=; b=OqnEZyig0zZwcUYEdA+LtrTdxWx0rfh/r0PUK0GjoP32ZVwJhspNR76q4PxH9xnoh6 n4WkQ9OzfnzaXVw+zDXT9DOJgccMMLZG04O89pMDz3R4JXBRQM5RtXYhdqPmLMNKP8yg rz/2o1ZIGLz1hjy1OMM99/zDA8O8bzY2YqiZzURJUO2sbEALPMrw+RsnZhu1GGz3UxSH TACU5gHBJX75g0B70woLky/hl/STTvMFH1LguM0GBV3l1NJQFQhSbcH3NxrNegLf0X0q Hz88sPGc2rPkQE2JsF2/eibHJ4AIDNwWps8F+iTrlNPpejGnZ8l0HUeSr/gEz6AabGfV LKBw== X-Gm-Message-State: AEkooutA7Wtr+mhR/8M13BFvn5Jfxa/CnvFIn9WViNXuZurtyIJ9f1sukSWjCPZjnC69cQ== X-Received: by 10.28.197.68 with SMTP id v65mr9308172wmf.2.1469959029943; Sun, 31 Jul 2016 02:57:09 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by smtp.gmail.com with ESMTPSA id s6sm24873571wjm.25.2016.07.31.02.57.08 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Sun, 31 Jul 2016 02:57:09 -0700 (PDT) Date: Sun, 31 Jul 2016 11:57:06 +0200 From: Mateusz Guzik To: jhb@freebsd.org Cc: freebsd-current@freebsd.org, kib@freebsd.org Subject: [PATCH] randomized delay in locking primitives, take 2 Message-ID: <20160731095706.GB9408@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , jhb@freebsd.org, freebsd-current@freebsd.org, kib@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) 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, 31 Jul 2016 09:57:12 -0000 The patch can be found inline below and also here: https://people.freebsd.org/~mjg/lock_backoff_complete.diff The previous version of the patch was posted here: https://lists.freebsd.org/pipermail/freebsd-current/2016-July/062320.html This time around instead of a total hack I have something of reasonable quality. Problem description and the way to fix it stands, to quote: > If the lock is contended, primitives like __mtx_lock_sleep will spin > checking if the owner is running or the lock was freed. The problem is > that once it is discovered that the lock is free, multiple CPUs are > likely to try to do the atomic op which will make it more costly for > everyone and throughput suffers. > The standard thing to do is to have some sort of a randomized delay so > that this kind of behaviour is reduced. So, this time around lock_delay primitive accepts configuration including min/max spin count per iteration, incrementation step per lock_delay invocation and total spins allowed during one execution of the locking primitive. The code "autotunes" with mp_ncpus on boot. Current values were determined after testing the code on a 80-way and a 40-way system. There is definitely room for improvement there, but the biggest gain as it is is sufficient to get the patch in. Parameters are settable by lock type. Converted locks are: mtx, sx, rwlocks. Trivial loops spinning as long as the lock owner is running are modified. The rest was left untouched in order to keep the patch simpler. The following locks were not touched: spin mutexes, thread locks and lockmgr. First two could be, but I don't have any suitable benchmarks for them. lockmgr has support for spinning, but is compiled out. In terms of results, this time around I got my hands on an 80-way machine (pig1 in the testing cluster). Vanilla kernel performance drops significantly with increased contention. For instance, the following is make -j 80 buildkernel of 11.0 tree on a tmpfs: 7681.08s user 17040.02s system 7014% cpu 5:52.43 total And this is with the patched kernel: 4585.85s user 2365.95s system 5675% cpu 2:02.48 total Both results are reproducible. I would like to get this in as fast as possible. Note: lock_delay has a .cap parameter which is currently set to 0 and has no sysctl to control it. It is there for later when it will replace the unmodified spinning code in sx and rwlocks. diff --git a/sys/kern/kern_mutex.c b/sys/kern/kern_mutex.c index 453add4..ca9319c 100644 --- a/sys/kern/kern_mutex.c +++ b/sys/kern/kern_mutex.c @@ -55,6 +55,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -138,6 +139,37 @@ struct lock_class lock_class_mtx_spin = { #endif }; +#ifdef ADAPTIVE_MUTEXES +static SYSCTL_NODE(_debug, OID_AUTO, mtx, CTLFLAG_RD, NULL, "mtx debugging"); + +static struct lock_delay_config mtx_delay = { + .initial = 1000, + .step = 500, + .cap = 0, + .min = 100, + .max = 5000, +}; + +SYSCTL_INT(_debug_mtx, OID_AUTO, delay_initial, CTLFLAG_RW, &mtx_delay.initial, + 0, ""); +SYSCTL_INT(_debug_mtx, OID_AUTO, delay_step, CTLFLAG_RW, &mtx_delay.step, + 0, ""); +SYSCTL_INT(_debug_mtx, OID_AUTO, delay_min, CTLFLAG_RW, &mtx_delay.min, + 0, ""); +SYSCTL_INT(_debug_mtx, OID_AUTO, delay_max, CTLFLAG_RW, &mtx_delay.max, + 0, ""); + +static void +mtx_delay_sysinit(void *dummy) +{ + + mtx_delay.initial = mp_ncpus * 25; + mtx_delay.min = mp_ncpus * 5; + mtx_delay.max = mp_ncpus * 25 * 10; +} +LOCK_DELAY_SYSINIT(mtx_delay_sysinit); +#endif + /* * System-wide mutexes */ @@ -408,8 +440,11 @@ __mtx_lock_sleep(volatile uintptr_t *c, uintptr_t tid, int opts, int contested = 0; uint64_t waittime = 0; #endif -#ifdef KDTRACE_HOOKS +#if defined(ADAPTIVE_MUTEXES) || defined(KDTRACE_HOOKS) uint64_t spin_cnt = 0; + uint64_t delay = 0; +#endif +#ifdef KDTRACE_HOOKS uint64_t sleep_cnt = 0; int64_t sleep_time = 0; int64_t all_time = 0; @@ -471,12 +506,8 @@ __mtx_lock_sleep(volatile uintptr_t *c, uintptr_t tid, int opts, "spinning", "lockname:\"%s\"", m->lock_object.lo_name); while (mtx_owner(m) == owner && - TD_IS_RUNNING(owner)) { - cpu_spinwait(); -#ifdef KDTRACE_HOOKS - spin_cnt++; -#endif - } + TD_IS_RUNNING(owner)) + lock_delay(&delay, &mtx_delay, &spin_cnt); KTR_STATE0(KTR_SCHED, "thread", sched_tdname((struct thread *)tid), "running"); diff --git a/sys/kern/kern_rwlock.c b/sys/kern/kern_rwlock.c index 496738d..cd93520 100644 --- a/sys/kern/kern_rwlock.c +++ b/sys/kern/kern_rwlock.c @@ -44,6 +44,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -65,15 +66,6 @@ PMC_SOFT_DECLARE( , , lock, failed); */ #define rwlock2rw(c) (__containerof(c, struct rwlock, rw_lock)) -#ifdef ADAPTIVE_RWLOCKS -static int rowner_retries = 10; -static int rowner_loops = 10000; -static SYSCTL_NODE(_debug, OID_AUTO, rwlock, CTLFLAG_RD, NULL, - "rwlock debugging"); -SYSCTL_INT(_debug_rwlock, OID_AUTO, retry, CTLFLAG_RW, &rowner_retries, 0, ""); -SYSCTL_INT(_debug_rwlock, OID_AUTO, loops, CTLFLAG_RW, &rowner_loops, 0, ""); -#endif - #ifdef DDB #include @@ -100,6 +92,42 @@ struct lock_class lock_class_rw = { #endif }; +#ifdef ADAPTIVE_RWLOCKS +static int rowner_retries = 10; +static int rowner_loops = 10000; +static SYSCTL_NODE(_debug, OID_AUTO, rwlock, CTLFLAG_RD, NULL, + "rwlock debugging"); +SYSCTL_INT(_debug_rwlock, OID_AUTO, retry, CTLFLAG_RW, &rowner_retries, 0, ""); +SYSCTL_INT(_debug_rwlock, OID_AUTO, loops, CTLFLAG_RW, &rowner_loops, 0, ""); + +static struct lock_delay_config rw_delay = { + .initial = 1000, + .step = 500, + .cap = 0, + .min = 100, + .max = 5000, +}; + +SYSCTL_INT(_debug_rwlock, OID_AUTO, delay_initial, CTLFLAG_RW, &rw_delay.initial, + 0, ""); +SYSCTL_INT(_debug_rwlock, OID_AUTO, delay_step, CTLFLAG_RW, &rw_delay.step, + 0, ""); +SYSCTL_INT(_debug_rwlock, OID_AUTO, delay_min, CTLFLAG_RW, &rw_delay.min, + 0, ""); +SYSCTL_INT(_debug_rwlock, OID_AUTO, delay_max, CTLFLAG_RW, &rw_delay.max, + 0, ""); + +static void +rw_delay_sysinit(void *dummy) +{ + + rw_delay.initial = mp_ncpus * 25; + rw_delay.min = mp_ncpus * 5; + rw_delay.max = mp_ncpus * 25 * 10; +} +LOCK_DELAY_SYSINIT(rw_delay_sysinit); +#endif + /* * Return a pointer to the owning thread if the lock is write-locked or * NULL if the lock is unlocked or read-locked. @@ -355,9 +383,12 @@ __rw_rlock(volatile uintptr_t *c, const char *file, int line) int contested = 0; #endif uintptr_t v; +#if defined(ADAPTIVE_RWLOCKS) || defined(KDTRACE_HOOKS) + uint64_t spin_cnt = 0; + uint64_t delay = 0; +#endif #ifdef KDTRACE_HOOKS uintptr_t state; - uint64_t spin_cnt = 0; uint64_t sleep_cnt = 0; int64_t sleep_time = 0; int64_t all_time = 0; @@ -437,12 +468,8 @@ __rw_rlock(volatile uintptr_t *c, const char *file, int line) sched_tdname(curthread), "spinning", "lockname:\"%s\"", rw->lock_object.lo_name); while ((struct thread*)RW_OWNER(rw->rw_lock) == - owner && TD_IS_RUNNING(owner)) { - cpu_spinwait(); -#ifdef KDTRACE_HOOKS - spin_cnt++; -#endif - } + owner && TD_IS_RUNNING(owner)) + lock_delay(&delay, &rw_delay, &spin_cnt); KTR_STATE0(KTR_SCHED, "thread", sched_tdname(curthread), "running"); continue; @@ -740,9 +767,12 @@ __rw_wlock_hard(volatile uintptr_t *c, uintptr_t tid, const char *file, uint64_t waittime = 0; int contested = 0; #endif +#if defined(ADAPTIVE_RWLOCKS) || defined(KDTRACE_HOOKS) + uint64_t spin_cnt = 0; + uint64_t delay = 0; +#endif #ifdef KDTRACE_HOOKS uintptr_t state; - uint64_t spin_cnt = 0; uint64_t sleep_cnt = 0; int64_t sleep_time = 0; int64_t all_time = 0; @@ -798,12 +828,8 @@ __rw_wlock_hard(volatile uintptr_t *c, uintptr_t tid, const char *file, "spinning", "lockname:\"%s\"", rw->lock_object.lo_name); while ((struct thread*)RW_OWNER(rw->rw_lock) == owner && - TD_IS_RUNNING(owner)) { - cpu_spinwait(); -#ifdef KDTRACE_HOOKS - spin_cnt++; -#endif - } + TD_IS_RUNNING(owner)) + lock_delay(&delay, &rw_delay, &spin_cnt); KTR_STATE0(KTR_SCHED, "thread", sched_tdname(curthread), "running"); continue; diff --git a/sys/kern/kern_sx.c b/sys/kern/kern_sx.c index a84df52..9a3465f 100644 --- a/sys/kern/kern_sx.c +++ b/sys/kern/kern_sx.c @@ -53,6 +53,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #if defined(SMP) && !defined(NO_ADAPTIVE_SX) @@ -145,6 +146,33 @@ static u_int asx_loops = 10000; static SYSCTL_NODE(_debug, OID_AUTO, sx, CTLFLAG_RD, NULL, "sxlock debugging"); SYSCTL_UINT(_debug_sx, OID_AUTO, retries, CTLFLAG_RW, &asx_retries, 0, ""); SYSCTL_UINT(_debug_sx, OID_AUTO, loops, CTLFLAG_RW, &asx_loops, 0, ""); + +static struct lock_delay_config sx_delay = { + .initial = 1000, + .step = 500, + .cap = 0, + .min = 100, + .max = 5000, +}; + +SYSCTL_INT(_debug_sx, OID_AUTO, delay_initial, CTLFLAG_RW, &sx_delay.initial, + 0, ""); +SYSCTL_INT(_debug_sx, OID_AUTO, delay_step, CTLFLAG_RW, &sx_delay.step, + 0, ""); +SYSCTL_INT(_debug_sx, OID_AUTO, delay_min, CTLFLAG_RW, &sx_delay.min, + 0, ""); +SYSCTL_INT(_debug_sx, OID_AUTO, delay_max, CTLFLAG_RW, &sx_delay.max, + 0, ""); + +static void +sx_delay_sysinit(void *dummy) +{ + + sx_delay.initial = mp_ncpus * 25; + sx_delay.min = mp_ncpus * 5; + sx_delay.max = mp_ncpus * 25 * 10; +} +LOCK_DELAY_SYSINIT(sx_delay_sysinit); #endif void @@ -513,9 +541,12 @@ _sx_xlock_hard(struct sx *sx, uintptr_t tid, int opts, const char *file, int contested = 0; #endif int error = 0; +#if defined(ADAPTIVE_SX) || defined(KDTRACE_HOOKS) + uint64_t spin_cnt = 0; + uint64_t delay = 0; +#endif #ifdef KDTRACE_HOOKS uintptr_t state; - uint64_t spin_cnt = 0; uint64_t sleep_cnt = 0; int64_t sleep_time = 0; int64_t all_time = 0; @@ -578,12 +609,8 @@ _sx_xlock_hard(struct sx *sx, uintptr_t tid, int opts, const char *file, sx->lock_object.lo_name); GIANT_SAVE(); while (SX_OWNER(sx->sx_lock) == x && - TD_IS_RUNNING(owner)) { - cpu_spinwait(); -#ifdef KDTRACE_HOOKS - spin_cnt++; -#endif - } + TD_IS_RUNNING(owner)) + lock_delay(&delay, &sx_delay, &spin_cnt); KTR_STATE0(KTR_SCHED, "thread", sched_tdname(curthread), "running"); continue; @@ -818,9 +845,12 @@ _sx_slock_hard(struct sx *sx, int opts, const char *file, int line) #endif uintptr_t x; int error = 0; +#if defined(ADAPTIVE_SX) || defined(KDTRACE_HOOKS) + uint64_t spin_cnt = 0; + uint64_t delay = 0; +#endif #ifdef KDTRACE_HOOKS uintptr_t state; - uint64_t spin_cnt = 0; uint64_t sleep_cnt = 0; int64_t sleep_time = 0; int64_t all_time = 0; @@ -888,12 +918,8 @@ _sx_slock_hard(struct sx *sx, int opts, const char *file, int line) "lockname:\"%s\"", sx->lock_object.lo_name); GIANT_SAVE(); while (SX_OWNER(sx->sx_lock) == x && - TD_IS_RUNNING(owner)) { - cpu_spinwait(); -#ifdef KDTRACE_HOOKS - spin_cnt++; -#endif - } + TD_IS_RUNNING(owner)) + lock_delay(&delay, &sx_delay, &spin_cnt); KTR_STATE0(KTR_SCHED, "thread", sched_tdname(curthread), "running"); continue; diff --git a/sys/kern/subr_lock.c b/sys/kern/subr_lock.c index e78d5a9..546881f 100644 --- a/sys/kern/subr_lock.c +++ b/sys/kern/subr_lock.c @@ -103,6 +103,37 @@ lock_destroy(struct lock_object *lock) lock->lo_flags &= ~LO_INITIALIZED; } +uint64_t +lock_delay(uint64_t *delayp, struct lock_delay_config *l, uint64_t *spin_cntp) +{ + uint64_t i, delay, backoff, min, max, cap; + + delay = *delayp; + + if (delay == 0) + delay = l->initial; + else { + delay += l->step; + max = l->max; + if (delay > max) + delay = max; + } + + backoff = cpu_ticks() % delay; + min = l->min; + if (backoff < min) + backoff = min; + cap = l->cap; + if (cap > 0 && backoff > cap - *spin_cntp) + backoff = cap - *spin_cntp; + for (i = 0; i < backoff; i++) + cpu_spinwait(); + + *delayp = delay; + *spin_cntp += backoff; + return (cap - *spin_cntp); +} + #ifdef DDB DB_SHOW_COMMAND(lock, db_show_lock) { diff --git a/sys/sys/lock.h b/sys/sys/lock.h index 8d7a068..ffac5ba 100644 --- a/sys/sys/lock.h +++ b/sys/sys/lock.h @@ -201,9 +201,23 @@ extern struct lock_class lock_class_lockmgr; extern struct lock_class *lock_classes[]; +extern int lock_delay_enabled; + +struct lock_delay_config { + u_int initial; + u_int step; + u_int cap; + u_int min; + u_int max; +}; + +#define LOCK_DELAY_SYSINIT(func) \ + SYSINIT(func##_ld, SI_SUB_LOCK, SI_ORDER_ANY, func, NULL) + void lock_init(struct lock_object *, struct lock_class *, const char *, const char *, int); void lock_destroy(struct lock_object *); +uint64_t lock_delay(uint64_t *, struct lock_delay_config *, uint64_t *); void spinlock_enter(void); void spinlock_exit(void); void witness_init(struct lock_object *, const char *); From owner-freebsd-current@freebsd.org Sun Jul 31 10:49:36 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 409CDBA9671 for ; Sun, 31 Jul 2016 10:49: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 89D9F167A; Sun, 31 Jul 2016 10:49:35 +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 u6VAnSOo004164 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 31 Jul 2016 13:49:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u6VAnSOo004164 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u6VAnSfc004163; Sun, 31 Jul 2016 13:49:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 31 Jul 2016 13:49:28 +0300 From: Konstantin Belousov To: Mateusz Guzik Cc: jhb@freebsd.org, freebsd-current@freebsd.org Subject: Re: [PATCH] randomized delay in locking primitives, take 2 Message-ID: <20160731104928.GW83214@kib.kiev.ua> References: <20160731095706.GB9408@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160731095706.GB9408@dft-labs.eu> 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: Sun, 31 Jul 2016 10:49:36 -0000 On Sun, Jul 31, 2016 at 11:57:06AM +0200, Mateusz Guzik wrote: > The patch can be found inline below and also here: > https://people.freebsd.org/~mjg/lock_backoff_complete.diff > > The previous version of the patch was posted here: > https://lists.freebsd.org/pipermail/freebsd-current/2016-July/062320.html > > This time around instead of a total hack I have something of reasonable > quality. > > Problem description and the way to fix it stands, to quote: > > If the lock is contended, primitives like __mtx_lock_sleep will spin > > checking if the owner is running or the lock was freed. The problem is > > that once it is discovered that the lock is free, multiple CPUs are > > likely to try to do the atomic op which will make it more costly for > > everyone and throughput suffers. > > > The standard thing to do is to have some sort of a randomized delay so > > that this kind of behaviour is reduced. > > So, this time around lock_delay primitive accepts configuration including > min/max spin count per iteration, incrementation step per lock_delay > invocation and total spins allowed during one execution of the locking > primitive. The code "autotunes" with mp_ncpus on boot. Current values > were determined after testing the code on a 80-way and a 40-way system. > There is definitely room for improvement there, but the biggest gain as > it is is sufficient to get the patch in. > > Parameters are settable by lock type. > > Converted locks are: mtx, sx, rwlocks. > > Trivial loops spinning as long as the lock owner is running are > modified. The rest was left untouched in order to keep the patch > simpler. > > The following locks were not touched: spin mutexes, thread locks and > lockmgr. First two could be, but I don't have any suitable benchmarks > for them. lockmgr has support for spinning, but is compiled out. > > In terms of results, this time around I got my hands on an 80-way > machine (pig1 in the testing cluster). Vanilla kernel performance drops > significantly with increased contention. For instance, the following is > make -j 80 buildkernel of 11.0 tree on a tmpfs: > 7681.08s user 17040.02s system 7014% cpu 5:52.43 total > > And this is with the patched kernel: > 4585.85s user 2365.95s system 5675% cpu 2:02.48 total > > Both results are reproducible. > > I would like to get this in as fast as possible. > > Note: lock_delay has a .cap parameter which is currently set to 0 and > has no sysctl to control it. It is there for later when it will replace > the unmodified spinning code in sx and rwlocks. > > diff --git a/sys/kern/kern_mutex.c b/sys/kern/kern_mutex.c > index 453add4..ca9319c 100644 > --- a/sys/kern/kern_mutex.c > +++ b/sys/kern/kern_mutex.c > @@ -55,6 +55,7 @@ __FBSDID("$FreeBSD$"); > #include > #include > #include > +#include > #include > #include > #include > @@ -138,6 +139,37 @@ struct lock_class lock_class_mtx_spin = { > #endif > }; > > +#ifdef ADAPTIVE_MUTEXES > +static SYSCTL_NODE(_debug, OID_AUTO, mtx, CTLFLAG_RD, NULL, "mtx debugging"); > + > +static struct lock_delay_config mtx_delay = { > + .initial = 1000, > + .step = 500, > + .cap = 0, > + .min = 100, > + .max = 5000, > +}; > + > +SYSCTL_INT(_debug_mtx, OID_AUTO, delay_initial, CTLFLAG_RW, &mtx_delay.initial, > + 0, ""); > +SYSCTL_INT(_debug_mtx, OID_AUTO, delay_step, CTLFLAG_RW, &mtx_delay.step, > + 0, ""); > +SYSCTL_INT(_debug_mtx, OID_AUTO, delay_min, CTLFLAG_RW, &mtx_delay.min, > + 0, ""); > +SYSCTL_INT(_debug_mtx, OID_AUTO, delay_max, CTLFLAG_RW, &mtx_delay.max, > + 0, ""); > + > +static void > +mtx_delay_sysinit(void *dummy) > +{ > + > + mtx_delay.initial = mp_ncpus * 25; > + mtx_delay.min = mp_ncpus * 5; > + mtx_delay.max = mp_ncpus * 25 * 10; > +} > +LOCK_DELAY_SYSINIT(mtx_delay_sysinit); > +#endif > + > /* > * System-wide mutexes > */ > @@ -408,8 +440,11 @@ __mtx_lock_sleep(volatile uintptr_t *c, uintptr_t tid, int opts, > int contested = 0; > uint64_t waittime = 0; > #endif > -#ifdef KDTRACE_HOOKS > +#if defined(ADAPTIVE_MUTEXES) || defined(KDTRACE_HOOKS) > uint64_t spin_cnt = 0; > + uint64_t delay = 0; > +#endif > +#ifdef KDTRACE_HOOKS > uint64_t sleep_cnt = 0; > int64_t sleep_time = 0; > int64_t all_time = 0; > @@ -471,12 +506,8 @@ __mtx_lock_sleep(volatile uintptr_t *c, uintptr_t tid, int opts, > "spinning", "lockname:\"%s\"", > m->lock_object.lo_name); > while (mtx_owner(m) == owner && > - TD_IS_RUNNING(owner)) { > - cpu_spinwait(); > -#ifdef KDTRACE_HOOKS > - spin_cnt++; > -#endif > - } > + TD_IS_RUNNING(owner)) > + lock_delay(&delay, &mtx_delay, &spin_cnt); > KTR_STATE0(KTR_SCHED, "thread", > sched_tdname((struct thread *)tid), > "running"); > diff --git a/sys/kern/kern_rwlock.c b/sys/kern/kern_rwlock.c > index 496738d..cd93520 100644 > --- a/sys/kern/kern_rwlock.c > +++ b/sys/kern/kern_rwlock.c > @@ -44,6 +44,7 @@ __FBSDID("$FreeBSD$"); > #include > #include > #include > +#include > #include > #include > #include > @@ -65,15 +66,6 @@ PMC_SOFT_DECLARE( , , lock, failed); > */ > #define rwlock2rw(c) (__containerof(c, struct rwlock, rw_lock)) > > -#ifdef ADAPTIVE_RWLOCKS > -static int rowner_retries = 10; > -static int rowner_loops = 10000; > -static SYSCTL_NODE(_debug, OID_AUTO, rwlock, CTLFLAG_RD, NULL, > - "rwlock debugging"); > -SYSCTL_INT(_debug_rwlock, OID_AUTO, retry, CTLFLAG_RW, &rowner_retries, 0, ""); > -SYSCTL_INT(_debug_rwlock, OID_AUTO, loops, CTLFLAG_RW, &rowner_loops, 0, ""); > -#endif > - > #ifdef DDB > #include > > @@ -100,6 +92,42 @@ struct lock_class lock_class_rw = { > #endif > }; > > +#ifdef ADAPTIVE_RWLOCKS > +static int rowner_retries = 10; > +static int rowner_loops = 10000; > +static SYSCTL_NODE(_debug, OID_AUTO, rwlock, CTLFLAG_RD, NULL, > + "rwlock debugging"); > +SYSCTL_INT(_debug_rwlock, OID_AUTO, retry, CTLFLAG_RW, &rowner_retries, 0, ""); > +SYSCTL_INT(_debug_rwlock, OID_AUTO, loops, CTLFLAG_RW, &rowner_loops, 0, ""); > + > +static struct lock_delay_config rw_delay = { > + .initial = 1000, > + .step = 500, > + .cap = 0, > + .min = 100, > + .max = 5000, > +}; > + > +SYSCTL_INT(_debug_rwlock, OID_AUTO, delay_initial, CTLFLAG_RW, &rw_delay.initial, > + 0, ""); > +SYSCTL_INT(_debug_rwlock, OID_AUTO, delay_step, CTLFLAG_RW, &rw_delay.step, > + 0, ""); > +SYSCTL_INT(_debug_rwlock, OID_AUTO, delay_min, CTLFLAG_RW, &rw_delay.min, > + 0, ""); > +SYSCTL_INT(_debug_rwlock, OID_AUTO, delay_max, CTLFLAG_RW, &rw_delay.max, > + 0, ""); > + > +static void > +rw_delay_sysinit(void *dummy) > +{ > + > + rw_delay.initial = mp_ncpus * 25; > + rw_delay.min = mp_ncpus * 5; > + rw_delay.max = mp_ncpus * 25 * 10; > +} > +LOCK_DELAY_SYSINIT(rw_delay_sysinit); > +#endif > + > /* > * Return a pointer to the owning thread if the lock is write-locked or > * NULL if the lock is unlocked or read-locked. > @@ -355,9 +383,12 @@ __rw_rlock(volatile uintptr_t *c, const char *file, int line) > int contested = 0; > #endif > uintptr_t v; > +#if defined(ADAPTIVE_RWLOCKS) || defined(KDTRACE_HOOKS) > + uint64_t spin_cnt = 0; > + uint64_t delay = 0; > +#endif > #ifdef KDTRACE_HOOKS > uintptr_t state; > - uint64_t spin_cnt = 0; > uint64_t sleep_cnt = 0; > int64_t sleep_time = 0; > int64_t all_time = 0; > @@ -437,12 +468,8 @@ __rw_rlock(volatile uintptr_t *c, const char *file, int line) > sched_tdname(curthread), "spinning", > "lockname:\"%s\"", rw->lock_object.lo_name); > while ((struct thread*)RW_OWNER(rw->rw_lock) == > - owner && TD_IS_RUNNING(owner)) { > - cpu_spinwait(); > -#ifdef KDTRACE_HOOKS > - spin_cnt++; > -#endif > - } > + owner && TD_IS_RUNNING(owner)) > + lock_delay(&delay, &rw_delay, &spin_cnt); > KTR_STATE0(KTR_SCHED, "thread", > sched_tdname(curthread), "running"); > continue; > @@ -740,9 +767,12 @@ __rw_wlock_hard(volatile uintptr_t *c, uintptr_t tid, const char *file, > uint64_t waittime = 0; > int contested = 0; > #endif > +#if defined(ADAPTIVE_RWLOCKS) || defined(KDTRACE_HOOKS) > + uint64_t spin_cnt = 0; > + uint64_t delay = 0; > +#endif > #ifdef KDTRACE_HOOKS > uintptr_t state; > - uint64_t spin_cnt = 0; > uint64_t sleep_cnt = 0; > int64_t sleep_time = 0; > int64_t all_time = 0; > @@ -798,12 +828,8 @@ __rw_wlock_hard(volatile uintptr_t *c, uintptr_t tid, const char *file, > "spinning", "lockname:\"%s\"", > rw->lock_object.lo_name); > while ((struct thread*)RW_OWNER(rw->rw_lock) == owner && > - TD_IS_RUNNING(owner)) { > - cpu_spinwait(); > -#ifdef KDTRACE_HOOKS > - spin_cnt++; > -#endif > - } > + TD_IS_RUNNING(owner)) > + lock_delay(&delay, &rw_delay, &spin_cnt); > KTR_STATE0(KTR_SCHED, "thread", sched_tdname(curthread), > "running"); > continue; > diff --git a/sys/kern/kern_sx.c b/sys/kern/kern_sx.c > index a84df52..9a3465f 100644 > --- a/sys/kern/kern_sx.c > +++ b/sys/kern/kern_sx.c > @@ -53,6 +53,7 @@ __FBSDID("$FreeBSD$"); > #include > #include > #include > +#include > #include > > #if defined(SMP) && !defined(NO_ADAPTIVE_SX) > @@ -145,6 +146,33 @@ static u_int asx_loops = 10000; > static SYSCTL_NODE(_debug, OID_AUTO, sx, CTLFLAG_RD, NULL, "sxlock debugging"); > SYSCTL_UINT(_debug_sx, OID_AUTO, retries, CTLFLAG_RW, &asx_retries, 0, ""); > SYSCTL_UINT(_debug_sx, OID_AUTO, loops, CTLFLAG_RW, &asx_loops, 0, ""); > + > +static struct lock_delay_config sx_delay = { > + .initial = 1000, > + .step = 500, > + .cap = 0, > + .min = 100, > + .max = 5000, > +}; > + > +SYSCTL_INT(_debug_sx, OID_AUTO, delay_initial, CTLFLAG_RW, &sx_delay.initial, > + 0, ""); > +SYSCTL_INT(_debug_sx, OID_AUTO, delay_step, CTLFLAG_RW, &sx_delay.step, > + 0, ""); > +SYSCTL_INT(_debug_sx, OID_AUTO, delay_min, CTLFLAG_RW, &sx_delay.min, > + 0, ""); > +SYSCTL_INT(_debug_sx, OID_AUTO, delay_max, CTLFLAG_RW, &sx_delay.max, > + 0, ""); > + > +static void > +sx_delay_sysinit(void *dummy) > +{ > + > + sx_delay.initial = mp_ncpus * 25; > + sx_delay.min = mp_ncpus * 5; > + sx_delay.max = mp_ncpus * 25 * 10; > +} > +LOCK_DELAY_SYSINIT(sx_delay_sysinit); > #endif > > void > @@ -513,9 +541,12 @@ _sx_xlock_hard(struct sx *sx, uintptr_t tid, int opts, const char *file, > int contested = 0; > #endif > int error = 0; > +#if defined(ADAPTIVE_SX) || defined(KDTRACE_HOOKS) > + uint64_t spin_cnt = 0; > + uint64_t delay = 0; > +#endif > #ifdef KDTRACE_HOOKS > uintptr_t state; > - uint64_t spin_cnt = 0; > uint64_t sleep_cnt = 0; > int64_t sleep_time = 0; > int64_t all_time = 0; > @@ -578,12 +609,8 @@ _sx_xlock_hard(struct sx *sx, uintptr_t tid, int opts, const char *file, > sx->lock_object.lo_name); > GIANT_SAVE(); > while (SX_OWNER(sx->sx_lock) == x && > - TD_IS_RUNNING(owner)) { > - cpu_spinwait(); > -#ifdef KDTRACE_HOOKS > - spin_cnt++; > -#endif > - } > + TD_IS_RUNNING(owner)) > + lock_delay(&delay, &sx_delay, &spin_cnt); > KTR_STATE0(KTR_SCHED, "thread", > sched_tdname(curthread), "running"); > continue; > @@ -818,9 +845,12 @@ _sx_slock_hard(struct sx *sx, int opts, const char *file, int line) > #endif > uintptr_t x; > int error = 0; > +#if defined(ADAPTIVE_SX) || defined(KDTRACE_HOOKS) > + uint64_t spin_cnt = 0; > + uint64_t delay = 0; > +#endif IMO it would be more maintainable to pack the local parameters for spin iteration into some opaque structure. You would also provide a function to initialize the local structure, and pass it to lock_delay() together with &lock_delay_config. > #ifdef KDTRACE_HOOKS > uintptr_t state; > - uint64_t spin_cnt = 0; > uint64_t sleep_cnt = 0; > int64_t sleep_time = 0; > int64_t all_time = 0; > @@ -888,12 +918,8 @@ _sx_slock_hard(struct sx *sx, int opts, const char *file, int line) > "lockname:\"%s\"", sx->lock_object.lo_name); > GIANT_SAVE(); > while (SX_OWNER(sx->sx_lock) == x && > - TD_IS_RUNNING(owner)) { > - cpu_spinwait(); > -#ifdef KDTRACE_HOOKS > - spin_cnt++; > -#endif > - } > + TD_IS_RUNNING(owner)) > + lock_delay(&delay, &sx_delay, &spin_cnt); > KTR_STATE0(KTR_SCHED, "thread", > sched_tdname(curthread), "running"); > continue; > diff --git a/sys/kern/subr_lock.c b/sys/kern/subr_lock.c > index e78d5a9..546881f 100644 > --- a/sys/kern/subr_lock.c > +++ b/sys/kern/subr_lock.c > @@ -103,6 +103,37 @@ lock_destroy(struct lock_object *lock) > lock->lo_flags &= ~LO_INITIALIZED; > } > > +uint64_t > +lock_delay(uint64_t *delayp, struct lock_delay_config *l, uint64_t *spin_cntp) > +{ > + uint64_t i, delay, backoff, min, max, cap; I am just curious there, are these locals indeed help ? Why not use l->xxx members directly ? > + > + delay = *delayp; > + > + if (delay == 0) > + delay = l->initial; > + else { > + delay += l->step; > + max = l->max; > + if (delay > max) > + delay = max; > + } > + > + backoff = cpu_ticks() % delay; Did you tested this on any 32bit architecture ? 64bit division done on each spin loop iteration there might give much larger delay than intended, and heat the core. I.e., it would be useful to ensure that there is no regression on small 32bit machines. > + min = l->min; > + if (backoff < min) > + backoff = min; > + cap = l->cap; > + if (cap > 0 && backoff > cap - *spin_cntp) > + backoff = cap - *spin_cntp; > + for (i = 0; i < backoff; i++) > + cpu_spinwait(); > + > + *delayp = delay; > + *spin_cntp += backoff; > + return (cap - *spin_cntp); What is the purpose of this calculation ? All callers seems to ignore the return value. > +} > + > #ifdef DDB > DB_SHOW_COMMAND(lock, db_show_lock) > { > diff --git a/sys/sys/lock.h b/sys/sys/lock.h > index 8d7a068..ffac5ba 100644 > --- a/sys/sys/lock.h > +++ b/sys/sys/lock.h > @@ -201,9 +201,23 @@ extern struct lock_class lock_class_lockmgr; > > extern struct lock_class *lock_classes[]; > > +extern int lock_delay_enabled; > + > +struct lock_delay_config { > + u_int initial; > + u_int step; > + u_int cap; > + u_int min; > + u_int max; > +}; > + > +#define LOCK_DELAY_SYSINIT(func) \ > + SYSINIT(func##_ld, SI_SUB_LOCK, SI_ORDER_ANY, func, NULL) > + > void lock_init(struct lock_object *, struct lock_class *, > const char *, const char *, int); > void lock_destroy(struct lock_object *); > +uint64_t lock_delay(uint64_t *, struct lock_delay_config *, uint64_t *); > void spinlock_enter(void); > void spinlock_exit(void); > void witness_init(struct lock_object *, const char *); From owner-freebsd-current@freebsd.org Sun Jul 31 10:58: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 28514BA9885 for ; Sun, 31 Jul 2016 10:58:42 +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 1A1C41B82; Sun, 31 Jul 2016 10:58:42 +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 E5DB81DA; Sun, 31 Jul 2016 10:58:41 +0000 (UTC) Date: Sun, 31 Jul 2016 10:58:37 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <1972570985.78.1469962719638.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <415985081.15.1468979103757.JavaMail.jenkins@jenkins-9.freebsd.org> References: <415985081.15.1468979103757.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD_sparc64 #185 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_sparc64 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: Sun, 31 Jul 2016 10:58:42 -0000 See From owner-freebsd-current@freebsd.org Sun Jul 31 12:41:18 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 94AAEBA9035 for ; Sun, 31 Jul 2016 12:41:18 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 17D7D1193; Sun, 31 Jul 2016 12:41:18 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-wm0-x243.google.com with SMTP id x83so22270471wma.3; Sun, 31 Jul 2016 05:41:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=uo3Ebugv3FHGaTcE3KdfLlJIfRCF8hqhcKgE1Qu48Sc=; b=PaFuocZ0IXvN6Sxrckw3xapYeAFhrIE75MP8Hqdb8jtHAvwDczUnv4+ytCbfFcu7ue zDRchpKmQ6vZIoUQcz6zRe3gexvsBk1kCPPUCVP3IlwVOgh5jfcCDQUuRmG/l8U+qGLL HNJ9H0lO1JahRaxdrSC15V8TvMGhBZuQbaEUVCU/vKZbLItdgvkX/tcK+MNxx+kH8y8n EdqEGLOdAaSMzL+9a3vHcZi1lCJQ0DyFhIpWS6LJwrrDHJnhtmhnsnz/CvD5Wk8ed6X7 zeUSShcQtvaHtQOHk/2U1KcBV8lBmuHZ5QRrSLtbX5+isUZWqsLywXusZjG6tNlY9qD2 Z2wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=uo3Ebugv3FHGaTcE3KdfLlJIfRCF8hqhcKgE1Qu48Sc=; b=f3FX7Ugr2Org8zhYFWYyoS2x4ilqkjGjt6TsE4kOfsQIAFJo6w3aKnLNkgUl/r1h2n KBwTc3M7HoRKF5tN+fuJhotqjF//zS9MyIJr2Eu8qjd+I4vGpNWeAE+gjhqyN7P7wdSW v5T6Qa27YaSDSfF45ofWaKsZ2wGK0dj0taqlXAhBUDScLzIKyAtcilEjMpfTR+6bCpCP HQpcGr6ZI+2UkIB9d6oo22QoZ1+Rg5tYAMdfjzpvu33w7a8V5bs2dnSOo0ALX5fkytKO SqZDIP432O12aYzntueFCj6r0Up+sOpl1BFBNuPwl0Mvntd9m8pOfzeBU9eSnEYYDrMm 6Prw== X-Gm-Message-State: AEkoouvrD/yO/KxbqXHym2rIXYGSAird1p42c8g9iWXUSCNbVg6pnc8N11I+HWHgdl8zog== X-Received: by 10.28.154.21 with SMTP id c21mr54032045wme.63.1469968876459; Sun, 31 Jul 2016 05:41:16 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by smtp.gmail.com with ESMTPSA id g67sm12047925wme.5.2016.07.31.05.41.15 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Sun, 31 Jul 2016 05:41:15 -0700 (PDT) Date: Sun, 31 Jul 2016 14:41:13 +0200 From: Mateusz Guzik To: Konstantin Belousov Cc: jhb@freebsd.org, freebsd-current@freebsd.org Subject: Re: [PATCH] randomized delay in locking primitives, take 2 Message-ID: <20160731124113.GE9408@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Konstantin Belousov , jhb@freebsd.org, freebsd-current@freebsd.org References: <20160731095706.GB9408@dft-labs.eu> <20160731104928.GW83214@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160731104928.GW83214@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) 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, 31 Jul 2016 12:41:18 -0000 On Sun, Jul 31, 2016 at 01:49:28PM +0300, Konstantin Belousov wrote: [snip] After an irc discussion, the following was produced (also available at: https://people.freebsd.org/~mjg/lock_backoff_complete4.diff): Differences: - uint64_t usage was converted to u_int (also see r303584) - currently unused features (cap limit and return value) were removed - lock_delay args got packed into a dedicated structure Note this patch requires the tree to be at least at r303584. diff --git a/sys/kern/kern_mutex.c b/sys/kern/kern_mutex.c index 0555a78..9b07b8b 100644 --- a/sys/kern/kern_mutex.c +++ b/sys/kern/kern_mutex.c @@ -55,6 +55,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -138,6 +139,36 @@ struct lock_class lock_class_mtx_spin = { #endif }; +#ifdef ADAPTIVE_MUTEXES +static SYSCTL_NODE(_debug, OID_AUTO, mtx, CTLFLAG_RD, NULL, "mtx debugging"); + +static struct lock_delay_config mtx_delay = { + .initial = 1000, + .step = 500, + .min = 100, + .max = 5000, +}; + +SYSCTL_INT(_debug_mtx, OID_AUTO, delay_initial, CTLFLAG_RW, &mtx_delay.initial, + 0, ""); +SYSCTL_INT(_debug_mtx, OID_AUTO, delay_step, CTLFLAG_RW, &mtx_delay.step, + 0, ""); +SYSCTL_INT(_debug_mtx, OID_AUTO, delay_min, CTLFLAG_RW, &mtx_delay.min, + 0, ""); +SYSCTL_INT(_debug_mtx, OID_AUTO, delay_max, CTLFLAG_RW, &mtx_delay.max, + 0, ""); + +static void +mtx_delay_sysinit(void *dummy) +{ + + mtx_delay.initial = mp_ncpus * 25; + mtx_delay.min = mp_ncpus * 5; + mtx_delay.max = mp_ncpus * 25 * 10; +} +LOCK_DELAY_SYSINIT(mtx_delay_sysinit); +#endif + /* * System-wide mutexes */ @@ -408,8 +439,10 @@ __mtx_lock_sleep(volatile uintptr_t *c, uintptr_t tid, int opts, int contested = 0; uint64_t waittime = 0; #endif +#if defined(ADAPTIVE_MUTEXES) || defined(KDTRACE_HOOKS) + struct lock_delay_arg lda; +#endif #ifdef KDTRACE_HOOKS - u_int spin_cnt = 0; u_int sleep_cnt = 0; int64_t sleep_time = 0; int64_t all_time = 0; @@ -418,6 +451,9 @@ __mtx_lock_sleep(volatile uintptr_t *c, uintptr_t tid, int opts, if (SCHEDULER_STOPPED()) return; +#if defined(ADAPTIVE_MUTEXES) || defined(KDTRACE_HOOKS) + lock_delay_arg_init(&lda, &mtx_delay); +#endif m = mtxlock2mtx(c); if (mtx_owned(m)) { @@ -451,7 +487,7 @@ __mtx_lock_sleep(volatile uintptr_t *c, uintptr_t tid, int opts, if (m->mtx_lock == MTX_UNOWNED && _mtx_obtain_lock(m, tid)) break; #ifdef KDTRACE_HOOKS - spin_cnt++; + lda.spin_cnt++; #endif #ifdef ADAPTIVE_MUTEXES /* @@ -471,12 +507,8 @@ __mtx_lock_sleep(volatile uintptr_t *c, uintptr_t tid, int opts, "spinning", "lockname:\"%s\"", m->lock_object.lo_name); while (mtx_owner(m) == owner && - TD_IS_RUNNING(owner)) { - cpu_spinwait(); -#ifdef KDTRACE_HOOKS - spin_cnt++; -#endif - } + TD_IS_RUNNING(owner)) + lock_delay(&lda); KTR_STATE0(KTR_SCHED, "thread", sched_tdname((struct thread *)tid), "running"); @@ -570,7 +602,7 @@ __mtx_lock_sleep(volatile uintptr_t *c, uintptr_t tid, int opts, /* * Only record the loops spinning and not sleeping. */ - if (spin_cnt > sleep_cnt) + if (lda.spin_cnt > sleep_cnt) LOCKSTAT_RECORD1(adaptive__spin, m, all_time - sleep_time); #endif } diff --git a/sys/kern/kern_rwlock.c b/sys/kern/kern_rwlock.c index d4cae61..363b042 100644 --- a/sys/kern/kern_rwlock.c +++ b/sys/kern/kern_rwlock.c @@ -44,6 +44,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -65,15 +66,6 @@ PMC_SOFT_DECLARE( , , lock, failed); */ #define rwlock2rw(c) (__containerof(c, struct rwlock, rw_lock)) -#ifdef ADAPTIVE_RWLOCKS -static int rowner_retries = 10; -static int rowner_loops = 10000; -static SYSCTL_NODE(_debug, OID_AUTO, rwlock, CTLFLAG_RD, NULL, - "rwlock debugging"); -SYSCTL_INT(_debug_rwlock, OID_AUTO, retry, CTLFLAG_RW, &rowner_retries, 0, ""); -SYSCTL_INT(_debug_rwlock, OID_AUTO, loops, CTLFLAG_RW, &rowner_loops, 0, ""); -#endif - #ifdef DDB #include @@ -100,6 +92,41 @@ struct lock_class lock_class_rw = { #endif }; +#ifdef ADAPTIVE_RWLOCKS +static int rowner_retries = 10; +static int rowner_loops = 10000; +static SYSCTL_NODE(_debug, OID_AUTO, rwlock, CTLFLAG_RD, NULL, + "rwlock debugging"); +SYSCTL_INT(_debug_rwlock, OID_AUTO, retry, CTLFLAG_RW, &rowner_retries, 0, ""); +SYSCTL_INT(_debug_rwlock, OID_AUTO, loops, CTLFLAG_RW, &rowner_loops, 0, ""); + +static struct lock_delay_config rw_delay = { + .initial = 1000, + .step = 500, + .min = 100, + .max = 5000, +}; + +SYSCTL_INT(_debug_rwlock, OID_AUTO, delay_initial, CTLFLAG_RW, &rw_delay.initial, + 0, ""); +SYSCTL_INT(_debug_rwlock, OID_AUTO, delay_step, CTLFLAG_RW, &rw_delay.step, + 0, ""); +SYSCTL_INT(_debug_rwlock, OID_AUTO, delay_min, CTLFLAG_RW, &rw_delay.min, + 0, ""); +SYSCTL_INT(_debug_rwlock, OID_AUTO, delay_max, CTLFLAG_RW, &rw_delay.max, + 0, ""); + +static void +rw_delay_sysinit(void *dummy) +{ + + rw_delay.initial = mp_ncpus * 25; + rw_delay.min = mp_ncpus * 5; + rw_delay.max = mp_ncpus * 25 * 10; +} +LOCK_DELAY_SYSINIT(rw_delay_sysinit); +#endif + /* * Return a pointer to the owning thread if the lock is write-locked or * NULL if the lock is unlocked or read-locked. @@ -355,9 +382,11 @@ __rw_rlock(volatile uintptr_t *c, const char *file, int line) int contested = 0; #endif uintptr_t v; +#if defined(ADAPTIVE_MUTEXES) || defined(KDTRACE_HOOKS) + struct lock_delay_arg lda; +#endif #ifdef KDTRACE_HOOKS uintptr_t state; - u_int spin_cnt = 0; u_int sleep_cnt = 0; int64_t sleep_time = 0; int64_t all_time = 0; @@ -366,6 +395,9 @@ __rw_rlock(volatile uintptr_t *c, const char *file, int line) if (SCHEDULER_STOPPED()) return; +#if defined(ADAPTIVE_MUTEXES) || defined(KDTRACE_HOOKS) + lock_delay_arg_init(&lda, &rw_delay); +#endif rw = rwlock2rw(c); KASSERT(kdb_active != 0 || !TD_IS_IDLETHREAD(curthread), @@ -412,7 +444,7 @@ __rw_rlock(volatile uintptr_t *c, const char *file, int line) continue; } #ifdef KDTRACE_HOOKS - spin_cnt++; + lda.spin_cnt++; #endif #ifdef HWPMC_HOOKS PMC_SOFT_CALL( , , lock, failed); @@ -437,12 +469,8 @@ __rw_rlock(volatile uintptr_t *c, const char *file, int line) sched_tdname(curthread), "spinning", "lockname:\"%s\"", rw->lock_object.lo_name); while ((struct thread*)RW_OWNER(rw->rw_lock) == - owner && TD_IS_RUNNING(owner)) { - cpu_spinwait(); -#ifdef KDTRACE_HOOKS - spin_cnt++; -#endif - } + owner && TD_IS_RUNNING(owner)) + lock_delay(&lda); KTR_STATE0(KTR_SCHED, "thread", sched_tdname(curthread), "running"); continue; @@ -459,7 +487,7 @@ __rw_rlock(volatile uintptr_t *c, const char *file, int line) cpu_spinwait(); } #ifdef KDTRACE_HOOKS - spin_cnt += rowner_loops - i; + lda.spin_cnt += rowner_loops - i; #endif KTR_STATE0(KTR_SCHED, "thread", sched_tdname(curthread), "running"); @@ -552,7 +580,7 @@ __rw_rlock(volatile uintptr_t *c, const char *file, int line) (state & RW_LOCK_READ) == 0 ? 0 : RW_READERS(state)); /* Record only the loops spinning and not sleeping. */ - if (spin_cnt > sleep_cnt) + if (lda.spin_cnt > sleep_cnt) LOCKSTAT_RECORD4(rw__spin, rw, all_time - sleep_time, LOCKSTAT_READER, (state & RW_LOCK_READ) == 0, (state & RW_LOCK_READ) == 0 ? 0 : RW_READERS(state)); @@ -740,9 +768,11 @@ __rw_wlock_hard(volatile uintptr_t *c, uintptr_t tid, const char *file, uint64_t waittime = 0; int contested = 0; #endif +#if defined(ADAPTIVE_MUTEXES) || defined(KDTRACE_HOOKS) + struct lock_delay_arg lda; +#endif #ifdef KDTRACE_HOOKS uintptr_t state; - u_int spin_cnt = 0; u_int sleep_cnt = 0; int64_t sleep_time = 0; int64_t all_time = 0; @@ -751,6 +781,9 @@ __rw_wlock_hard(volatile uintptr_t *c, uintptr_t tid, const char *file, if (SCHEDULER_STOPPED()) return; +#if defined(ADAPTIVE_MUTEXES) || defined(KDTRACE_HOOKS) + lock_delay_arg_init(&lda, &rw_delay); +#endif rw = rwlock2rw(c); if (rw_wlocked(rw)) { @@ -775,7 +808,7 @@ __rw_wlock_hard(volatile uintptr_t *c, uintptr_t tid, const char *file, if (rw->rw_lock == RW_UNLOCKED && _rw_write_lock(rw, tid)) break; #ifdef KDTRACE_HOOKS - spin_cnt++; + lda.spin_cnt++; #endif #ifdef HWPMC_HOOKS PMC_SOFT_CALL( , , lock, failed); @@ -798,12 +831,8 @@ __rw_wlock_hard(volatile uintptr_t *c, uintptr_t tid, const char *file, "spinning", "lockname:\"%s\"", rw->lock_object.lo_name); while ((struct thread*)RW_OWNER(rw->rw_lock) == owner && - TD_IS_RUNNING(owner)) { - cpu_spinwait(); -#ifdef KDTRACE_HOOKS - spin_cnt++; -#endif - } + TD_IS_RUNNING(owner)) + lock_delay(&lda); KTR_STATE0(KTR_SCHED, "thread", sched_tdname(curthread), "running"); continue; @@ -828,7 +857,7 @@ __rw_wlock_hard(volatile uintptr_t *c, uintptr_t tid, const char *file, KTR_STATE0(KTR_SCHED, "thread", sched_tdname(curthread), "running"); #ifdef KDTRACE_HOOKS - spin_cnt += rowner_loops - i; + lda.spin_cnt += rowner_loops - i; #endif if (i != rowner_loops) continue; @@ -918,7 +947,7 @@ __rw_wlock_hard(volatile uintptr_t *c, uintptr_t tid, const char *file, (state & RW_LOCK_READ) == 0 ? 0 : RW_READERS(state)); /* Record only the loops spinning and not sleeping. */ - if (spin_cnt > sleep_cnt) + if (lda.spin_cnt > sleep_cnt) LOCKSTAT_RECORD4(rw__spin, rw, all_time - sleep_time, LOCKSTAT_WRITER, (state & RW_LOCK_READ) == 0, (state & RW_LOCK_READ) == 0 ? 0 : RW_READERS(state)); diff --git a/sys/kern/kern_sx.c b/sys/kern/kern_sx.c index 78d207d..42878110 100644 --- a/sys/kern/kern_sx.c +++ b/sys/kern/kern_sx.c @@ -53,6 +53,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #if defined(SMP) && !defined(NO_ADAPTIVE_SX) @@ -145,6 +146,32 @@ static u_int asx_loops = 10000; static SYSCTL_NODE(_debug, OID_AUTO, sx, CTLFLAG_RD, NULL, "sxlock debugging"); SYSCTL_UINT(_debug_sx, OID_AUTO, retries, CTLFLAG_RW, &asx_retries, 0, ""); SYSCTL_UINT(_debug_sx, OID_AUTO, loops, CTLFLAG_RW, &asx_loops, 0, ""); + +static struct lock_delay_config sx_delay = { + .initial = 1000, + .step = 500, + .min = 100, + .max = 5000, +}; + +SYSCTL_INT(_debug_sx, OID_AUTO, delay_initial, CTLFLAG_RW, &sx_delay.initial, + 0, ""); +SYSCTL_INT(_debug_sx, OID_AUTO, delay_step, CTLFLAG_RW, &sx_delay.step, + 0, ""); +SYSCTL_INT(_debug_sx, OID_AUTO, delay_min, CTLFLAG_RW, &sx_delay.min, + 0, ""); +SYSCTL_INT(_debug_sx, OID_AUTO, delay_max, CTLFLAG_RW, &sx_delay.max, + 0, ""); + +static void +sx_delay_sysinit(void *dummy) +{ + + sx_delay.initial = mp_ncpus * 25; + sx_delay.min = mp_ncpus * 5; + sx_delay.max = mp_ncpus * 25 * 10; +} +LOCK_DELAY_SYSINIT(sx_delay_sysinit); #endif void @@ -513,9 +540,11 @@ _sx_xlock_hard(struct sx *sx, uintptr_t tid, int opts, const char *file, int contested = 0; #endif int error = 0; +#if defined(ADAPTIVE_MUTEXES) || defined(KDTRACE_HOOKS) + struct lock_delay_arg lda; +#endif #ifdef KDTRACE_HOOKS uintptr_t state; - u_int spin_cnt = 0; u_int sleep_cnt = 0; int64_t sleep_time = 0; int64_t all_time = 0; @@ -524,6 +553,10 @@ _sx_xlock_hard(struct sx *sx, uintptr_t tid, int opts, const char *file, if (SCHEDULER_STOPPED()) return (0); +#if defined(ADAPTIVE_MUTEXES) || defined(KDTRACE_HOOKS) + lock_delay_arg_init(&lda, &sx_delay); +#endif + /* If we already hold an exclusive lock, then recurse. */ if (sx_xlocked(sx)) { KASSERT((sx->lock_object.lo_flags & LO_RECURSABLE) != 0, @@ -549,7 +582,7 @@ _sx_xlock_hard(struct sx *sx, uintptr_t tid, int opts, const char *file, atomic_cmpset_acq_ptr(&sx->sx_lock, SX_LOCK_UNLOCKED, tid)) break; #ifdef KDTRACE_HOOKS - spin_cnt++; + lda.spin_cnt++; #endif #ifdef HWPMC_HOOKS PMC_SOFT_CALL( , , lock, failed); @@ -578,12 +611,8 @@ _sx_xlock_hard(struct sx *sx, uintptr_t tid, int opts, const char *file, sx->lock_object.lo_name); GIANT_SAVE(); while (SX_OWNER(sx->sx_lock) == x && - TD_IS_RUNNING(owner)) { - cpu_spinwait(); -#ifdef KDTRACE_HOOKS - spin_cnt++; -#endif - } + TD_IS_RUNNING(owner)) + lock_delay(&lda); KTR_STATE0(KTR_SCHED, "thread", sched_tdname(curthread), "running"); continue; @@ -605,7 +634,7 @@ _sx_xlock_hard(struct sx *sx, uintptr_t tid, int opts, const char *file, break; cpu_spinwait(); #ifdef KDTRACE_HOOKS - spin_cnt++; + lda.spin_cnt++; #endif } KTR_STATE0(KTR_SCHED, "thread", @@ -725,7 +754,7 @@ _sx_xlock_hard(struct sx *sx, uintptr_t tid, int opts, const char *file, LOCKSTAT_RECORD4(sx__block, sx, sleep_time, LOCKSTAT_WRITER, (state & SX_LOCK_SHARED) == 0, (state & SX_LOCK_SHARED) == 0 ? 0 : SX_SHARERS(state)); - if (spin_cnt > sleep_cnt) + if (lda.spin_cnt > sleep_cnt) LOCKSTAT_RECORD4(sx__spin, sx, all_time - sleep_time, LOCKSTAT_WRITER, (state & SX_LOCK_SHARED) == 0, (state & SX_LOCK_SHARED) == 0 ? 0 : SX_SHARERS(state)); @@ -818,9 +847,11 @@ _sx_slock_hard(struct sx *sx, int opts, const char *file, int line) #endif uintptr_t x; int error = 0; +#if defined(ADAPTIVE_MUTEXES) || defined(KDTRACE_HOOKS) + struct lock_delay_arg lda; +#endif #ifdef KDTRACE_HOOKS uintptr_t state; - u_int spin_cnt = 0; u_int sleep_cnt = 0; int64_t sleep_time = 0; int64_t all_time = 0; @@ -829,6 +860,9 @@ _sx_slock_hard(struct sx *sx, int opts, const char *file, int line) if (SCHEDULER_STOPPED()) return (0); +#if defined(ADAPTIVE_MUTEXES) || defined(KDTRACE_HOOKS) + lock_delay_arg_init(&lda, &sx_delay); +#endif #ifdef KDTRACE_HOOKS state = sx->sx_lock; all_time -= lockstat_nsecs(&sx->lock_object); @@ -840,7 +874,7 @@ _sx_slock_hard(struct sx *sx, int opts, const char *file, int line) */ for (;;) { #ifdef KDTRACE_HOOKS - spin_cnt++; + lda.spin_cnt++; #endif x = sx->sx_lock; @@ -888,12 +922,8 @@ _sx_slock_hard(struct sx *sx, int opts, const char *file, int line) "lockname:\"%s\"", sx->lock_object.lo_name); GIANT_SAVE(); while (SX_OWNER(sx->sx_lock) == x && - TD_IS_RUNNING(owner)) { - cpu_spinwait(); -#ifdef KDTRACE_HOOKS - spin_cnt++; -#endif - } + TD_IS_RUNNING(owner)) + lock_delay(&lda); KTR_STATE0(KTR_SCHED, "thread", sched_tdname(curthread), "running"); continue; @@ -989,7 +1019,7 @@ _sx_slock_hard(struct sx *sx, int opts, const char *file, int line) LOCKSTAT_RECORD4(sx__block, sx, sleep_time, LOCKSTAT_READER, (state & SX_LOCK_SHARED) == 0, (state & SX_LOCK_SHARED) == 0 ? 0 : SX_SHARERS(state)); - if (spin_cnt > sleep_cnt) + if (lda.spin_cnt > sleep_cnt) LOCKSTAT_RECORD4(sx__spin, sx, all_time - sleep_time, LOCKSTAT_READER, (state & SX_LOCK_SHARED) == 0, (state & SX_LOCK_SHARED) == 0 ? 0 : SX_SHARERS(state)); diff --git a/sys/kern/subr_lock.c b/sys/kern/subr_lock.c index e78d5a9..bfe189d 100644 --- a/sys/kern/subr_lock.c +++ b/sys/kern/subr_lock.c @@ -103,6 +103,34 @@ lock_destroy(struct lock_object *lock) lock->lo_flags &= ~LO_INITIALIZED; } +void +lock_delay(struct lock_delay_arg *la) +{ + u_int i, delay, backoff, min, max; + struct lock_delay_config *lc = la->config; + + delay = la->delay; + + if (delay == 0) + delay = lc->initial; + else { + delay += lc->step; + max = lc->max; + if (delay > max) + delay = max; + } + + backoff = cpu_ticks() % delay; + min = lc->min; + if (backoff < min) + backoff = min; + for (i = 0; i < backoff; i++) + cpu_spinwait(); + + la->delay = delay; + la->spin_cnt += backoff; +} + #ifdef DDB DB_SHOW_COMMAND(lock, db_show_lock) { diff --git a/sys/sys/lock.h b/sys/sys/lock.h index 8d7a068..bd66aad 100644 --- a/sys/sys/lock.h +++ b/sys/sys/lock.h @@ -201,9 +201,35 @@ extern struct lock_class lock_class_lockmgr; extern struct lock_class *lock_classes[]; +extern int lock_delay_enabled; + +struct lock_delay_config { + u_int initial; + u_int step; + u_int min; + u_int max; +}; + +struct lock_delay_arg { + struct lock_delay_config *config; + u_int delay; + u_int spin_cnt; +}; + +static inline void +lock_delay_arg_init(struct lock_delay_arg *la, struct lock_delay_config *lc) { + la->config = lc; + la->delay = 0; + la->spin_cnt = 0; +} + +#define LOCK_DELAY_SYSINIT(func) \ + SYSINIT(func##_ld, SI_SUB_LOCK, SI_ORDER_ANY, func, NULL) + void lock_init(struct lock_object *, struct lock_class *, const char *, const char *, int); void lock_destroy(struct lock_object *); +void lock_delay(struct lock_delay_arg *); void spinlock_enter(void); void spinlock_exit(void); void witness_init(struct lock_object *, const char *); From owner-freebsd-current@freebsd.org Sun Jul 31 14:03:10 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C30CBA950F for ; Sun, 31 Jul 2016 14:03:10 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1092C1604; Sun, 31 Jul 2016 14:03:10 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x243.google.com with SMTP id y34so12748842ioi.3; Sun, 31 Jul 2016 07:03:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=LcrmU5sV0DnIIFW2IWWFpeaJmzBlUQya+Sxmc+mNgs4=; b=0ReeCUzVBW2v1II4pkydsU5hp0JAAmV6urGuekXU6+jwHNF5tGN6ViXdbQqTtOzaJr j9r/6p9jdbWXFckNmHNIALW4d2SDmklCinv59OBdFzMksN6qF4nHsXpb5MQ0SyHQP4dM Rmh2Z15kwMMmArc362QTZUxgXqjSQqs+ZsztMScL5s2aFuBc/xeq2emQSN7gtdwy6NTF ordlkdtnUg+SYfCsDrVUwkxrqI63Lun2rOV+xxtt/ArWG7PMlMfSlqh426LLhzK46VPa mDGwwS2ZH7Xn26/SWuiVN7idbQc4QlQHweB0Dd5HRj0X2lYMxINtf60oZUQTP6zmJNBK tVXw== 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; bh=LcrmU5sV0DnIIFW2IWWFpeaJmzBlUQya+Sxmc+mNgs4=; b=KVeel5HV14wfgtgZhveAOBSJDwIWOGAzs9f70q7pTuOgHWAXyVVLy1svJVCBvzXlr4 NlGv/bNzTxxzq7UmHrP0hKuoP1cyX4VvMfuLcrDmQmK7JqD9IDKz3+XOaUMc6ppqtG8z jZaErOBu6ZN4D0maQ5IRh+jzCrxm44w7AXRHRf43vrgMDHFyBUqKqrYFYMyNgnsdRw+H AK5Nsfjo5N0c+MDoCOK/dCjE/22Ep4q3aCPHJDhFZi5hcTY3ED8++dHrEEu9RxspnGqd urrjLzeKofqtQmm9QtTZHOIisVYxXgwtdf0SR9JjI96PexJo6rfBQ0qj+t7BqqMjZe1j BbdA== X-Gm-Message-State: AEkoouveHQbvRclBO1EjzED0/PmWX6adLOY8FBAy4HrzGukFTwvDBmvVLpZaNmi7QU7ogy7qleNpR+5PzHqm0w== X-Received: by 10.107.15.229 with SMTP id 98mr8235192iop.123.1469973789213; Sun, 31 Jul 2016 07:03:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.141.129 with HTTP; Sun, 31 Jul 2016 07:03:08 -0700 (PDT) In-Reply-To: <20160731095706.GB9408@dft-labs.eu> References: <20160731095706.GB9408@dft-labs.eu> From: Adrian Chadd Date: Sun, 31 Jul 2016 07:03:08 -0700 Message-ID: Subject: Re: [PATCH] randomized delay in locking primitives, take 2 To: Mateusz Guzik , John Baldwin , freebsd-current , Konstantin Belousov 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: Sun, 31 Jul 2016 14:03:10 -0000 Hi, Did you test on any 1, 2, 4, 8 cpu machines? just to see if there are any performance degredations on lower count CPUs? Also, yeah, the MOD operator in each loop could get spendy on older CPUs (eg my MIPS CPUs, older ARM stuff, etc.) Is it possible to achieve much the same autotuning with pow2 operations instead of divide/mod? -a From owner-freebsd-current@freebsd.org Sun Jul 31 15:54: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 27D0EBAA5D3 for ; Sun, 31 Jul 2016 15:54:04 +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 1B9B31CA4; Sun, 31 Jul 2016 15:54:04 +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 B61041E3; Sun, 31 Jul 2016 15:54:03 +0000 (UTC) Date: Sun, 31 Jul 2016 15:54:02 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <38068636.80.1469980442527.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build became unstable: FreeBSD_HEAD #513 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 31 Jul 2016 15:54:04 -0000 See From owner-freebsd-current@freebsd.org Sun Jul 31 16:56: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 488E3BA9202 for ; Sun, 31 Jul 2016 16:56:29 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0389A19FB; Sun, 31 Jul 2016 16:56:28 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: by mail-wm0-x22d.google.com with SMTP id o80so213651215wme.1; Sun, 31 Jul 2016 09:56:28 -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=iVdIs5byTn+8A+2e6naVK9xReObYoiTjIO1BFC1zBNE=; b=XQzewAgkfEAJ0Vn4ydwRcNc9T7EeiZNaoxvkUcWFpV7K3ddz+Gb0PAR3UQ65DoF1f8 d1ODnR+JM8YTMR2Rkxch0CfeXAOheRHG63t3v0bRnP4m4UuablkUcVzbgqjlUWtOFHi+ 2CMgjpV9bojGdTS3gKCUFw/5lTXtc/+O/0iE6Bm5qo8Y+hiC/Rb1+IwOoRBULJmHdULm Dry8yzOv+DUJKeJKpHpeL9QOlMcc62xjHMYYOLLDPDskZvAok7qMApV+Na+s4E4nHKlW n04PV66SIPmUGmIGW9cyNMEcuuSQ8U3autYxUZpPqghkaUM4YR31KjH3Ale2luh/9UPH QsgA== 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=iVdIs5byTn+8A+2e6naVK9xReObYoiTjIO1BFC1zBNE=; b=k3y2hSzG1sprgmTGAssYr7H+6CPqfhhwY3gRsrdRaaREjn9r6B+ofbMVfy6f2RlEYH /7eWe9m0zM9kVxSoWLq1prj8YzQmguCTaX6CY1VzeMM2w0VYcmZczt3IMfD5J1VN2CzF hFNsHy7+Xk9tp0oNHd9bdKmExgIwzneO1Jht/04y7liTTFR0Ue05Dh4v3OYMKUEIrKSU cwQCLMzvpfM/V4YgcPMSba+ZGXsXySHeIEGriltV/F/tIifzIRjTMILkYkGxlJGdwd40 gVaPFHddkBEbowEkxYaevrTT9Ee1vXMYgiK7qIfjjTL8XbBUogITkw62lS8SR+gnknfz qUOQ== X-Gm-Message-State: AEkoouudTq80KcQx6BCujQNJSNKpu6kPzQfvdXMhuU9CRlvEXS/0csinqSWhOedJkWMAxSH9U4rOhJXWYo42CA== X-Received: by 10.194.85.18 with SMTP id d18mr47124671wjz.43.1469984187122; Sun, 31 Jul 2016 09:56:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.19.203 with HTTP; Sun, 31 Jul 2016 09:56:26 -0700 (PDT) In-Reply-To: References: <20160731023550.GF1532@FreeBSD.org> From: Guy Yur Date: Sun, 31 Jul 2016 19:56:26 +0300 Message-ID: Subject: Re: resolvconf needs @RESTARTCMD@ to be replaced after r303062 To: Pedro Giffuni Cc: Glen Barber , freebsd-current Content-Type: multipart/mixed; boundary=089e0103e05c4ca9100538f15d69 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, 31 Jul 2016 16:56:29 -0000 --089e0103e05c4ca9100538f15d69 Content-Type: text/plain; charset=UTF-8 On Sun, Jul 31, 2016 at 5:46 AM, Pedro Giffuni wrote: > > >>> Index: sbin/resolvconf/Makefile >>> =================================================================== >>> --- sbin/resolvconf/Makefile (revision 303557) >>> +++ sbin/resolvconf/Makefile (working copy) >>> @@ -30,6 +30,7 @@ >>> -e 's:@LIBEXECDIR@:${FILESDIR}:g' \ >>> -e 's:@VARDIR@:${VARDIR}:g' \ >>> -e 's:@RESTARTCMD \(.*\)@:${RESTARTCMD}:g' \ >>> + -e 's:@RESTARTCMD@:${RESTARTCMD}:g' \ >>> -e 's:@RCDIR@:${RCDIR}:g' \ >>> -e 's: vpn : ng[0-9]*&:g' \ >>> ${DIST}/$@.in > $@ >> >> > > And the underscore was not a typo. > Thanks Guy! > > Pedro. Hi, I meant for the RESTARTCMD_= statement to be added too. I should have sent a patch file. Issue could be seen during boot if using dhcpcd which invokes resolvconf or by running 'resolvconf -r SERVICENAME' With r303567, RESTARTCMD is now empty in the script so dynamic detection for service command is done. Attaching new patch. 1. Renaming RESTARTCMD, CMD1, CMD2 to _WITH_ARG since it is only used by pdns_recursor.in. The other files have all moved to use $RESTARTCMD passed from resolvconf. I will send a patch upstream to do the same for pdns_recursor.in. The ugly _WITH_ARG vars can be removed when pdns_recursor.in is updated to new style. 2. Renaming RESTARTCMD_ to RESTARTCMD and adding the lines for new CMD1, CMD2, RESTARTCMD statements. Thanks, Guy --089e0103e05c4ca9100538f15d69 Content-Type: application/octet-stream; name="resolvconf_RESTARTCMD.patch" Content-Disposition: attachment; filename="resolvconf_RESTARTCMD.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_iraudptw0 SW5kZXg6IE1ha2VmaWxlCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIE1ha2VmaWxlCShyZXZpc2lvbiAzMDM1OTEp CisrKyBNYWtlZmlsZQkod29ya2luZyBjb3B5KQpAQCAtMTksOSArMTksMTIgQEAgVkFSRElSPQkJ L3Zhci9ydW4vcmVzb2x2Y29uZgogCiAjIFdlIGRvbid0IGFzc3VtZSB0byByZXN0YXJ0IHRoZSBz ZXJ2aWNlcyBpbiAvc2Jpbi4gIFNvLCB0aG91Z2gKICMgb3VyIHNlcnZpY2UoOCkgaXMgaW4gL3Vz ci9zYmluLCB3ZSBjYW4gdXNlIGl0LCBoZXJlLgotQ01EMT0JCVwxIG9uZXN0YXR1cyA+L2Rldi9u dWxsIDI+XCYxCi1DTUQyPQkJXDEgcmVzdGFydAotUkVTVEFSVENNRD0JL3Vzci9zYmluL3NlcnZp Y2UgJHtDTUQxfSBcJlwmIC91c3Ivc2Jpbi9zZXJ2aWNlICR7Q01EMn0KK0NNRDFfV0lUSF9BUkc9 CQlcMSBvbmVzdGF0dXMgPi9kZXYvbnVsbCAyPlwmMQorQ01EMl9XSVRIX0FSRz0JCVwxIHJlc3Rh cnQKK1JFU1RBUlRDTURfV0lUSF9BUkc9CS91c3Ivc2Jpbi9zZXJ2aWNlICR7Q01EMV9XSVRIX0FS R30gXCZcJiAvdXNyL3NiaW4vc2VydmljZSAke0NNRDJfV0lUSF9BUkd9CitDTUQxPQkJXFwkJDEg b25lc3RhdHVzID4vZGV2L251bGwgMj5cJjEKK0NNRDI9CQlcXCQkMSByZXN0YXJ0CitSRVNUQVJU Q01EPQkiL3Vzci9zYmluL3NlcnZpY2UgJHtDTUQxfSBcJlwmIC91c3Ivc2Jpbi9zZXJ2aWNlICR7 Q01EMn0iCiAKIC5mb3IgZiBpbiAke1NDUklQVFN9ICR7RklMRVN9ICR7TUFOfQogJHtmfToJJHtm fS5pbgpAQCAtMjksOCArMzIsOCBAQCAke2Z9Ogkke2Z9LmluCiAJCS1lICdzOkBTWVNDT05GRElS QDoke1NZU0NPTkZESVJ9OmcnIFwKIAkJLWUgJ3M6QExJQkVYRUNESVJAOiR7RklMRVNESVJ9Omcn IFwKIAkJLWUgJ3M6QFZBUkRJUkA6JHtWQVJESVJ9OmcnIFwKLQkJLWUgJ3M6QFJFU1RBUlRDTUQg XCguKlwpQDoke1JFU1RBUlRDTUR9OmcnIFwKLQkJLWUgJ3M6QFJFU1RBUlRDTURAOiR7UkVTVEFS VENNRF99OmcnIFwKKwkJLWUgJ3M6QFJFU1RBUlRDTUQgXCguKlwpQDoke1JFU1RBUlRDTURfV0lU SF9BUkd9OmcnIFwKKwkJLWUgJ3M6QFJFU1RBUlRDTURAOiR7UkVTVEFSVENNRH06ZycgXAogCQkt ZSAnczpAUkNESVJAOiR7UkNESVJ9OmcnIFwKIAkJLWUgJ3M6IHZwbiA6IG5nWzAtOV0qJjpnJyBc CiAJCSR7RElTVH0vJEAuaW4gPiAkQAo= --089e0103e05c4ca9100538f15d69-- From owner-freebsd-current@freebsd.org Sun Jul 31 15:53: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 A7075BAA57B; Sun, 31 Jul 2016 15:53:40 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8FDDB1C8D; Sun, 31 Jul 2016 15:53:40 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id u6VFbcBN033651 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 31 Jul 2016 08:37:38 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id u6VFbcaZ033650; Sun, 31 Jul 2016 08:37:38 -0700 (PDT) (envelope-from sgk) Date: Sun, 31 Jul 2016 08:37:38 -0700 From: Steve Kargl To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: BSD grep dumps core Message-ID: <20160731153738.GA33643@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) X-Mailman-Approved-At: Sun, 31 Jul 2016 17:58:14 +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: Sun, 31 Jul 2016 15:53:40 -0000 Script started on Sun Jul 31 08:30:56 2016 troutmask:sgk[200] cd gcc/gcc7 troutmask:sgk[201] svn status ? 7.diff ? decl.c.diff ? gcc/fortran/old ? gcc/fortran/pr38351.diff ? gcc/fortran/pr41922.diff ? gcc/fortran/pr69860.diff ? trans-decl.c.diff ? typescript ? z1.diff troutmask:sgk[202] svn status | grep -v -E ^\? Segmentation fault (core dumped) troutmask:sgk[203] svn status | grep -v -E ^"\?" troutmask:sgk[204] exit exit Script done on Sun Jul 31 08:31:54 2016 The core dump happens with both tcsh and sh. The following works as expected troutmask:sgk[202] svn status | gnugrep -v -E ^\? -- Steve From owner-freebsd-current@freebsd.org Sun Jul 31 18:09: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 1170DBAA2BD for ; Sun, 31 Jul 2016 18:09:40 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm6.bullet.mail.bf1.yahoo.com (nm6.bullet.mail.bf1.yahoo.com [98.139.212.165]) (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 BCACB1A79 for ; Sun, 31 Jul 2016 18:09:39 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1469988577; bh=mv+2hEskLiBAita0ohIGMAwe5wr4tN19aCHlCCFNtX8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=TTOs65FhShl6YnMmZ3TeJu1XQLsYEx0Q1O6NM7kVWYTTmUeeW5E3OgUp2K/Qi+dsZylHx+gKmLCucJUN/+1+35d0mx8muhaBEB6zN0KBcmQmahMsqVAiL5he1LATnkerh4PyawIcizEkKJEWki5VWfz8JWmtfSpqqJT/UEMmhRzj/ww0A/CxYFdvzByGLOaIVq4IqzXKkLWg/K3xYZpktVkLn4bjJxBxX/ug4bUUKHYhzT2wMWw5rURmxBaJ5efaZcXUHKVK1C0rbw1DJ70e4KC42GIKZRkBFRCvyEn/X61PTOaGg1UjbFdHuR2n1kZ20AcRlXtkN16P6nfb8Z3oOw== Received: from [66.196.81.171] by nm6.bullet.mail.bf1.yahoo.com with NNFMP; 31 Jul 2016 18:09:37 -0000 Received: from [98.139.211.203] by tm17.bullet.mail.bf1.yahoo.com with NNFMP; 31 Jul 2016 18:09:37 -0000 Received: from [127.0.0.1] by smtp212.mail.bf1.yahoo.com with NNFMP; 31 Jul 2016 18:09:37 -0000 X-Yahoo-Newman-Id: 559340.51809.bm@smtp212.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: j1Bb0dQVM1mdfzTGllqFQp9gDQDS2IL_ioiumkkO5aPDrKJ 82U9kLw1S9lJw9XxOjbLkGQqO91ImRKu2fJgf9poaHN7VmFohz0FPdSto0dT sTAqYJjzfydn6JyvQovZDP1hz5Ix.3.ifwD6QJdhK_sEeF.RM3YPy5QPx1zh zsKJc.qxLl_fRc8z2YojQSQJWiLojotFhUaCYMtyw7zzBy3M68Ff5kCa9URs FmmzLNOS3Gw5baK_0O.hnuQVI0xJJ37EEz0gN4Xgt71p9jLIsgadMrI42Eey mdhheaO3clczvF0arrT.LHik_bDIErXnNoqK_Nnv.FIzVF76k_1nOrgYXff1 ZEF6fWcLoDzJMoK3NeR0zSP41x4lycsWFwqG39d9cQiYjOEO2h6JToNEdlSa ViH5cd5kl_nxbKkttYQSTVFJuRfG6u_HOq_kG2QfSITOcFwvUB.EgOG7dyFt vKuUsD7GJLEWVhUYIq8Bu_4JEaiSbJBn5gIdBo0nkeJ1oaNpp5qrEGulV4Us 6rZdWV9AzuKMA0vlruswtSRgfFgIlUrgtahvaCiaHuK9CKg-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Subject: Re: resolvconf needs @RESTARTCMD@ to be replaced after r303062 To: Guy Yur References: <20160731023550.GF1532@FreeBSD.org> Cc: Glen Barber , freebsd-current From: Pedro Giffuni Message-ID: Date: Sun, 31 Jul 2016 13:09:47 -0500 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: Sun, 31 Jul 2016 18:09:40 -0000 On 07/31/16 11:56, Guy Yur wrote: > On Sun, Jul 31, 2016 at 5:46 AM, Pedro Giffuni wrote: >> >> >>>> Index: sbin/resolvconf/Makefile >>>> =================================================================== >>>> --- sbin/resolvconf/Makefile (revision 303557) >>>> +++ sbin/resolvconf/Makefile (working copy) >>>> @@ -30,6 +30,7 @@ >>>> -e 's:@LIBEXECDIR@:${FILESDIR}:g' \ >>>> -e 's:@VARDIR@:${VARDIR}:g' \ >>>> -e 's:@RESTARTCMD \(.*\)@:${RESTARTCMD}:g' \ >>>> + -e 's:@RESTARTCMD@:${RESTARTCMD}:g' \ >>>> -e 's:@RCDIR@:${RCDIR}:g' \ >>>> -e 's: vpn : ng[0-9]*&:g' \ >>>> ${DIST}/$@.in > $@ >>> >>> >> >> And the underscore was not a typo. >> Thanks Guy! >> >> Pedro. > > Hi, > > I meant for the RESTARTCMD_= statement to be added too. > I should have sent a patch file. > Ugh ... yeah I am really bad at "guessing" patches. I will play with your patch. Thanks. Pedro. From owner-freebsd-current@freebsd.org Sun Jul 31 18:35: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 48331BAAE00 for ; Sun, 31 Jul 2016 18:35:27 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 3A6A51D98; Sun, 31 Jul 2016 18:35:27 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 044C61E7; Sun, 31 Jul 2016 18:35:27 +0000 (UTC) Date: Sun, 31 Jul 2016 18:35:26 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <1241645319.81.1469990126906.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <38068636.80.1469980442527.JavaMail.jenkins@jenkins-9.freebsd.org> References: <38068636.80.1469980442527.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to stable : FreeBSD_HEAD #514 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: Sun, 31 Jul 2016 18:35:27 -0000 See From owner-freebsd-current@freebsd.org Sun Jul 31 18:41: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 7FD52BAA034 for ; Sun, 31 Jul 2016 18:41:30 +0000 (UTC) (envelope-from bergerkos@yahoo.co.uk) Received: from nm19-vm4.bullet.mail.ir2.yahoo.com (nm19-vm4.bullet.mail.ir2.yahoo.com [212.82.96.237]) (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 E286D137F for ; Sun, 31 Jul 2016 18:41:29 +0000 (UTC) (envelope-from bergerkos@yahoo.co.uk) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1469990481; bh=z0UJ4Gj/uHuTALBp68Tuf5vXBvfbj2JUn3P8kEqQPKA=; h=Date:From:Reply-To:To:Subject:References:From:Subject; b=CO2RJQECGmQ0cFyY3cNe7OS4TYU2q7ua0P7LODWi8rJA6wuBQcvouJHWg8zqzDsceNwQeELChmWaFfkAztxal/0enUH2KndER/iE8DVcjzSTtHqsP7+mVp1LHa9m4s/vY49spGT12HNctuv8vvafLwt2agdtxpeMnaIelJTSYDpQSbP40M5bdHDHAqtu3zBfJ6AT04Rp1PH5JGZUlSgAhu+VCKwUT+IP29M3WvJaRzJh0CWk91nqpYe2sLI8jZ8qHe8E5MtRglYn4DPU3wjZD2z2AoNoLtDj/HoXZ5wEzyD9OnM0UdJO99LB5+NJkkiMNRUSgj6IQ7AEwlEYvoC2Kw== Received: from [212.82.98.56] by nm19.bullet.mail.ir2.yahoo.com with NNFMP; 31 Jul 2016 18:41:21 -0000 Received: from [212.82.98.77] by tm9.bullet.mail.ir2.yahoo.com with NNFMP; 31 Jul 2016 18:41:21 -0000 Received: from [127.0.0.1] by omp1014.mail.ir2.yahoo.com with NNFMP; 31 Jul 2016 18:41:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 654871.47168.bm@omp1014.mail.ir2.yahoo.com Received: from jws11188.mail.ir2.yahoo.com by sendmailws169.mail.ir2.yahoo.com; Sun, 31 Jul 2016 18:41:21 +0000; 1469990481.127 Date: Sun, 31 Jul 2016 18:41:20 +0000 (UTC) From: Kostya Berger Reply-To: "bergerkos@yahoo.co.uk" To: FreeBSD Current Message-ID: <1647344805.12798604.1469990480731.JavaMail.yahoo@mail.yahoo.com> Subject: release name MIME-Version: 1.0 References: <1647344805.12798604.1469990480731.JavaMail.yahoo.ref@mail.yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.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: Sun, 31 Jul 2016 18:41:30 -0000 Could somebody, please, explain this: Am I right to assume that CURRENT or "head" release number is now 12.0?For in that case I'll have to reduild the ports in case of upgrading my system to the current head, right?Because my current system was build well before the 11.0-alpfha releases statred appearing. Sent from Yahoo Mail on Android From owner-freebsd-current@freebsd.org Sun Jul 31 18:43: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 601D7BAA251 for ; Sun, 31 Jul 2016 18:43:26 +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 2790E173E for ; Sun, 31 Jul 2016 18:43:26 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.87 (FreeBSD)) (envelope-from ) id 1bTvhv-000HtU-Hd; Sun, 31 Jul 2016 20:43:27 +0200 Date: Sun, 31 Jul 2016 20:43:27 +0200 From: Kurt Jaeger To: Kostya Berger Cc: FreeBSD Current Subject: Re: release name Message-ID: <20160731184327.GI96200@home.opsec.eu> References: <1647344805.12798604.1469990480731.JavaMail.yahoo.ref@mail.yahoo.com> <1647344805.12798604.1469990480731.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1647344805.12798604.1469990480731.JavaMail.yahoo@mail.yahoo.com> 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, 31 Jul 2016 18:43:26 -0000 Hi! > Could somebody, please, explain this: > Am I right to assume that CURRENT or "head" release number is now > 12.0? Yes. > For in that case I'll have to reduild the ports in case of > upgrading my system to the current head, right? Because my current > system was build well before the 11.0-alpha releases statred > appearing. If you build them on 11.0-alpha, they are good enough. You only need to rebuild those that no longer work. -- pi@opsec.eu +49 171 3101372 4 years to go ! From owner-freebsd-current@freebsd.org Sun Jul 31 20:36:18 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 23050BA85A9 for ; Sun, 31 Jul 2016 20:36:18 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A8FB91CFA; Sun, 31 Jul 2016 20:36:17 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-wm0-x22c.google.com with SMTP id o80so217783823wme.1; Sun, 31 Jul 2016 13:36:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=WQzI2hAoTF7M0FSMP5P7hA+im197Z7KTxL6MnJMtCEM=; b=fZfDVTAKaxDjQuwtyZIWQN2OzsBwBjXUM/+k7/zqOaYw6IkCm0HN00xlf6BckYqk41 GSR8qdI2k6X6QNIxmXtxpTu0a7H3zfR7ZCcyy9t3y21+uGBHQ/FxkHZ88WY188MrpW7/ uwoaVsphprO4jUIdvChVpRMStd30lHN7mFE7m4xMCoMx94AhoVpKcWNzL/pnkgC4q5fl yDOKd2qXz3GmuK3IiKxtgn2Ad2Wxfxa428GVBnFTHkpLk1ra/B0TdFNeiI5Onvpn4HZ+ tzLRLdzW7e6oN8pUEoTrRMV7VrMNZYMXLKnkAI00N+wkm64k4zimV+bu7VCCb1tdGd8s hrJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=WQzI2hAoTF7M0FSMP5P7hA+im197Z7KTxL6MnJMtCEM=; b=dtJL4kCP2rbNOSGiU7hZxtSBHXM7YhKes8g4tUwMIUPX8PAmLwpBhNMVbqoA3eaPZ1 +qCUch8hg8VaN3C5gmb3l6vQhLBfN/pznHHzfiUzH/mg9u1LVcfVoedS8prZJf3VTTgF wjRwlJDiX2DDGXp6F8Izi7sDep/E7TEM/u5LDQXGdt+t16zfExpyyj33SRPN1vt/TAUo v2Wv0ScCC20sujSZb1Q0P5NkMiMsjfAGJUShHX8TMWFN9hyLi5vki9Q1BQ1c2h60/j0I afE+HAySOL+tZdb0BlFJlg9xAZP4xTCX2uTE95rntLoQJv1d5Jv6JK4ll0ahutK0mBZP kELQ== X-Gm-Message-State: AEkoouusge0NSpWeDlYV7F6jdb9uX6oJd+JFcUmHBZkmbPXLGu84qolfD8AzsOdvwC+kvQ== X-Received: by 10.194.248.198 with SMTP id yo6mr20989267wjc.66.1469997375237; Sun, 31 Jul 2016 13:36:15 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by smtp.gmail.com with ESMTPSA id x203sm13602761wmg.0.2016.07.31.13.36.14 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Sun, 31 Jul 2016 13:36:14 -0700 (PDT) Date: Sun, 31 Jul 2016 22:36:12 +0200 From: Mateusz Guzik To: Adrian Chadd Cc: John Baldwin , freebsd-current , Konstantin Belousov Subject: Re: [PATCH] randomized delay in locking primitives, take 2 Message-ID: <20160731203612.GH9408@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Adrian Chadd , John Baldwin , freebsd-current , Konstantin Belousov References: <20160731095706.GB9408@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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, 31 Jul 2016 20:36:18 -0000 On Sun, Jul 31, 2016 at 07:03:08AM -0700, Adrian Chadd wrote: > Hi, > > Did you test on any 1, 2, 4, 8 cpu machines? just to see if there are > any performance degredations on lower count CPUs? > I did not test on machines which physically that few cpus, but I did test the impact on microbenchmark with 2 and 4 threads on the 80-way machine. There was no difference. For this iteration of the patch, given limited time I tried to be very conservative as to not intoduce additional latency. In fact I would argue the patch is undertuned (as in, it can do better in certain workloads). That said, I think it is safe to use. > Also, yeah, the MOD operator in each loop could get spendy on older > CPUs (eg my MIPS CPUs, older ARM stuff, etc.) Is it possible to > achieve much the same autotuning with pow2 operations instead of > divide/mod? > The % operation acts a randomizer. It is optional and I'm happy to ifdef it based on the architecture. It does seem to be useful at least on amd64. As a side note, exponential backoff is not used to keep things smaller (see above). It is definitely subject to change later. -- Mateusz Guzik From owner-freebsd-current@freebsd.org Sun Jul 31 20:51: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 DDBE7BA8AAE for ; Sun, 31 Jul 2016 20:51:07 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from kif.fubar.geek.nz (kif.fubar.geek.nz [178.62.119.249]) by mx1.freebsd.org (Postfix) with ESMTP id AF3F2188F for ; Sun, 31 Jul 2016 20:51:07 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from zapp (bcdf0033.skybroadband.com [188.223.0.51]) by kif.fubar.geek.nz (Postfix) with ESMTPSA id 0E097D838C; Sun, 31 Jul 2016 20:50:31 +0000 (UTC) Date: Sun, 31 Jul 2016 21:50:29 +0100 From: Andrew Turner To: Xin Li Cc: FreeBSD Current , d@delphij.net Subject: Re: EFI boot: can we make loader.efi work as BOOT{x64, aa64, arm, ia32}.efi? Message-ID: <20160731215029.6d04169b@zapp> In-Reply-To: <5bf35d8a-9941-9c6e-ea0a-20827ad26466@delphij.net> References: <5bf35d8a-9941-9c6e-ea0a-20827ad26466@delphij.net> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 31 Jul 2016 20:51:08 -0000 On Sat, 30 Jul 2016 23:20:55 -0700 Xin Li wrote: > Hi, > > I finally got some time to explore the UEFI boot process (kudos to > everyone who made this work!) and getting myself familiarize with the > basics. > > One quick question -- Is there some technical restriction that > prevents us from merging boot1.efi and loader.efi into one binary? The only issue I know about is loader.efi will use the wrong partition to load the kernel. This is because it assumes the kernel is to be loaded from the same filesystem as it was. Andrew From owner-freebsd-current@freebsd.org Sun Jul 31 21:25:20 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 227A8BAA2A6 for ; Sun, 31 Jul 2016 21:25:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 0FAD61A58 for ; Sun, 31 Jul 2016 21:25:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 0B6BCBAA2A5; Sun, 31 Jul 2016 21:25:20 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0B100BAA2A4 for ; Sun, 31 Jul 2016 21:25:20 +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 C011F1A57 for ; Sun, 31 Jul 2016 21:25:19 +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 59D2AB96E; Sun, 31 Jul 2016 17:25:18 -0400 (EDT) From: John Baldwin To: gljennjohn@gmail.com Cc: current@freebsd.org Subject: Re: EARLY_AP_STARTUP hangs during boot Date: Sun, 31 Jul 2016 14:22:35 -0700 Message-ID: <1944919.bPt123bEA6@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.3-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20160731112914.58bd9765@ernst.home> References: <20160516122242.39249a54@ernst.home> <8097239.52FCHCROUA@ralph.baldwin.cx> <20160731112914.58bd9765@ernst.home> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Sun, 31 Jul 2016 17:25:18 -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: Sun, 31 Jul 2016 21:25:20 -0000 On Sunday, July 31, 2016 11:29:14 AM Gary Jennejohn wrote: > On Sat, 30 Jul 2016 12:03:59 -0700 > John Baldwin wrote: > > > On Saturday, July 30, 2016 09:44:22 AM Gary Jennejohn wrote: > > > On Fri, 29 Jul 2016 13:17:42 -0700 > > > John Baldwin wrote: > > > > > > > On Thursday, July 28, 2016 12:31:31 AM Gary Jennejohn wrote: > > > > > Well, now I know that ULE is a prerequiste for EARLY_AP_STARTUP! I > > > > > wasn't aware of that. I prefer BSD and that's the scheduler I did > > > > > the first tests with. > > > > > > > > > > But with the ULE scheduler the system comes up all the way. > > > > > > > > > > It would be nice if the BSD scheduler could also be modified to > > > > > work with EARLY_AP_STARTUP. > > > > > > > > I wasn't able to reproduce your hang with 4BSD, but I think I see a > > > > possible problem. Try this: > > > > > > > > diff --git a/sys/kern/sched_4bsd.c b/sys/kern/sched_4bsd.c > > > > index 7de56b6..d53331a 100644 > > > > --- a/sys/kern/sched_4bsd.c > > > > +++ b/sys/kern/sched_4bsd.c > > > > @@ -327,7 +327,6 @@ maybe_preempt(struct thread *td) > > > > * - The current thread has a higher (numerically lower) or > > > > * equivalent priority. Note that this prevents curthread from > > > > * trying to preempt to itself. > > > > - * - It is too early in the boot for context switches (cold is set). > > > > * - The current thread has an inhibitor set or is in the process of > > > > * exiting. In this case, the current thread is about to switch > > > > * out anyways, so there's no point in preempting. If we did, > > > > @@ -348,7 +347,7 @@ maybe_preempt(struct thread *td) > > > > ("maybe_preempt: trying to run inhibited thread")); > > > > pri = td->td_priority; > > > > cpri = ctd->td_priority; > > > > - if (panicstr != NULL || pri >= cpri || cold /* || dumping */ || > > > > + if (panicstr != NULL || pri >= cpri /* || dumping */ || > > > > TD_IS_INHIBITED(ctd)) > > > > return (0); > > > > #ifndef FULL_PREEMPTION > > > > @@ -1127,7 +1126,7 @@ forward_wakeup(int cpunum) > > > > if ((!forward_wakeup_enabled) || > > > > (forward_wakeup_use_mask == 0 && forward_wakeup_use_loop == 0)) > > > > return (0); > > > > - if (!smp_started || cold || panicstr) > > > > + if (!smp_started || panicstr) > > > > return (0); > > > > > > > > forward_wakeups_requested++; > > > > > > > > > > Thanks, but with this patch the kernel hangs in exactly the same > > > place as before - after the HPET output. > > > > > > Maybe I'm missing some kernel option which ULE works around, or > > > something like that. > > > > Hmm, ok. Please add KTR_RUNQ and KTR_SMP to the KTR masks, that is > > 'options KTR_COMPILE=(KTR_PROC|KTR_RUNQ|KTR_SMP)' and > > 'options KTR_MASK=(KTR_PROC|KTR_RUNQ|KTR_SMP)' > > > > Please also add this patch (on top of the previous patch): > > > > diff --git a/sys/kern/sched_4bsd.c b/sys/kern/sched_4bsd.c > > index 2973a23..bab2278 100644 > > --- a/sys/kern/sched_4bsd.c > > +++ b/sys/kern/sched_4bsd.c > > @@ -1278,6 +1278,8 @@ sched_add(struct thread *td, int flags) > > KASSERT(td->td_flags & TDF_INMEM, > > ("sched_add: thread swapped out")); > > > > + CTR2(KTR_PROC, "sched_add: thread %d (%s)", td->td_tid, > > + sched_tdname(td)); > > KTR_STATE2(KTR_SCHED, "thread", sched_tdname(td), "runq add", > > "prio:%d", td->td_priority, KTR_ATTR_LINKED, > > sched_tdname(curthread)); > > diff --git a/sys/x86/x86/cpu_machdep.c b/sys/x86/x86/cpu_machdep.c > > index f07b97e..1f418f1 100644 > > --- a/sys/x86/x86/cpu_machdep.c > > +++ b/sys/x86/x86/cpu_machdep.c > > @@ -440,6 +440,7 @@ cpu_idle_wakeup(int cpu) > > return (0); > > if (*state == STATE_MWAIT) > > *state = STATE_RUNNING; > > + CTR1(KTR_PROC, "cpu_idle_wakeup: wokeup CPU %d", cpu); > > return (1); > > } > > > > (I haven't tried compiling it, you might have to add the sys/ktr.h > > header to cpu_machdep.c if it doesn't build.) > > > > Hopefully we will get some better trace messages before it hangs > > with this added info. The root issue seems to be that 4BSD is > > pinning thread0 to some other CPU (due to sched_bind that happens > > inside of bus_bind_intr() when the HPET driver pins IRQs to CPUs) > > and that other CPU isn't waking up to realize it needs to run thread0. > > > > It compiled with no changes needed. > > Even though I set MAXCPU to a mere 2, the boot still hadn't > completed after 90 minutes and I broke it off. I still have > the kernel, so I can try it another time when I have less need > for my FreeBSD box. Did you have the KTR options enabled from before? I don't expect this to fix the issue, this is more about getting better debug info when it hangs. -- John Baldwin From owner-freebsd-current@freebsd.org Sun Jul 31 21:38: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 8F9B9BAA676 for ; Sun, 31 Jul 2016 21:38:16 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 5A0471505 for ; Sun, 31 Jul 2016 21:38:16 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by mail-it0-x22f.google.com with SMTP id u186so230833226ita.0 for ; Sun, 31 Jul 2016 14:38:16 -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=qKE/+nolKxPMiGhtfde9z9uGdZho6bA+VJ0Zg+U+qk0=; b=09OMfTjwyyihTec/r1TYNk56Fii8BMLGJnilRVeNJAoDrn0cuwrJXdUIsuprn6+9U7 jYRvMvPYLPn9Um0GAaH9haQmAMh/UeKZ+vhzCNvQUbypAwrcsbQgkSRxRtwzCeIombdm 3KhmBdWv1d9xGgqOW41YRbWye4vH6N0zdHERhuiPuYwL/myjzCxpy72LpWKA+TksMQ5+ bLn85Auc5ll87sxGHA6Xz81WJCikPk34jJjR/LAovyUTRnzXmIBsmsFddGe369U2dwre UuynS7qVet8lv+7wC28HDCGaUJRpkgPVL9m8AgeuaN90EyfduL6yGfKwa94gio+u26dV 65WA== 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=qKE/+nolKxPMiGhtfde9z9uGdZho6bA+VJ0Zg+U+qk0=; b=ggfEYbWp9U+DVopu8RwXJT+qohm8FMsb1MfkcrW+VIeCcLRb8h/WKgaHaOExeqplE7 pok1B6BTJmOgyfqAtxTnH5AHiySYSioM4KctJP3FYtoD21jw6XslRZk70rrWZKPIuypA 5KSd0/PqcyHC0CDYyJh564L/3r289OYk65MiZKaYNtWejcvDiWWvL/kuA614jXn4+J1j igQ/intje1xpVgQsDMf74ca1nHs8BuxkJtgwf/Q5W16Qsdr5GxSriGjqlw4C7yrLQaH2 mpoFvsYtw4BAWUFxmEusWt3R7utQ8xQaNxwjmwK2E7WXsXD1Lf3/Wh39Wm3X0rzny/vR 5vmg== X-Gm-Message-State: AEkoouvZVwlT4hyyXlZFaTp6d/fZ1gZPzeWIN6daWf3QALygUjaJZpNLx0J7NSqlQamlCoK5qU5OOTJ7WFTEMA== X-Received: by 10.36.43.88 with SMTP id h85mr11083419ita.57.1470001095525; Sun, 31 Jul 2016 14:38:15 -0700 (PDT) MIME-Version: 1.0 Sender: kmacybsd@gmail.com Received: by 10.107.143.11 with HTTP; Sun, 31 Jul 2016 14:38:15 -0700 (PDT) In-Reply-To: References: From: "K. Macy" Date: Sun, 31 Jul 2016 14:38:15 -0700 X-Google-Sender-Auth: WWw0d0VHAIhS_u3YXYGkeKrys5Q Message-ID: Subject: Re: ACPI errors when booting laptop To: Ben Woods Cc: 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: Sun, 31 Jul 2016 21:38:16 -0000 Have you checked for BIOS updates? The BIOS on recent Skylake laptops have been a running disaster. At least the Dell XPS laptops had ACPI errors be fixed by an update. -M On Sat, Jul 30, 2016 at 10:43 PM, Ben Woods wrote: > Hi everyone, > > I get the following ACPI errors in my dmesg when booting my NEC Lavie HZ750 > laptop with FreeBSD 12-current. I have noticed things not functioning > correct (except suspend/resume not working), but then again I don't really > know much about ACPI or what I should expect to see. Any ideas what the > problem is? > > Full dmesg is also attached. > > acpi0: on motherboard > acpi_ec_ecdt_probe: can't get handle > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC._REG] (Node > 0xfffff80005494980), AE_NOT_EXIST (20160527/psparse-559) > acpi0: Power Button (fixed) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.BAT1._STA] > (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node > 0xfffff8000549a640), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.BAT1._STA] > (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node > 0xfffff8000549a640), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.BAT1._STA] > (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node > 0xfffff8000549a640), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.BAT1._STA] > (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node > 0xfffff8000549a640), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.BAT1._STA] > (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node > 0xfffff8000549a640), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.BAT1._STA] > (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node > 0xfffff8000549a640), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.BAT1._STA] > (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node > 0xfffff8000549a640), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.BAT1._STA] > (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node > 0xfffff8000549a640), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.BAT1._STA] > (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node > 0xfffff8000549a640), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.CIND._STA] > (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.CIND._STA] (Node > 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.CIND._STA] > (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.CIND._STA] (Node > 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.CIND._STA] > (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.CIND._STA] (Node > 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.CIND._STA] > (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.CIND._STA] (Node > 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.CIND._STA] > (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.CIND._STA] (Node > 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.CIND._STA] > (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.CIND._STA] (Node > 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.CIND._STA] > (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.CIND._STA] (Node > 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.CIND._STA] > (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.CIND._STA] (Node > 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.CIND._STA] > (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.CIND._STA] (Node > 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.VGBI._STA] > (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.VGBI._STA] (Node > 0xfffff8000549a180), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.VGBI._STA] > (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.VGBI._STA] (Node > 0xfffff8000549a180), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.VGBI._STA] > (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.VGBI._STA] (Node > 0xfffff8000549a180), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.VGBI._STA] > (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.VGBI._STA] (Node > 0xfffff8000549a180), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.VGBI._STA] > (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.VGBI._STA] (Node > 0xfffff8000549a180), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.VGBI._STA] > (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.VGBI._STA] (Node > 0xfffff8000549a180), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.VGBI._STA] > (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.VGBI._STA] (Node > 0xfffff8000549a180), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.VGBI._STA] > (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.VGBI._STA] (Node > 0xfffff8000549a180), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.VGBI._STA] > (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.VGBI._STA] (Node > 0xfffff8000549a180), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.BAT1._STA] > (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node > 0xfffff8000549a640), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.BAT1._STA] > (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node > 0xfffff8000549a640), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.CIND._STA] > (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.CIND._STA] (Node > 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.CIND._STA] > (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.CIND._STA] (Node > 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.VGBI._STA] > (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.VGBI._STA] (Node > 0xfffff8000549a180), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.VGBI._STA] > (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.VGBI._STA] (Node > 0xfffff8000549a180), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.BAT1._STA] > (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node > 0xfffff8000549a640), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.BAT1._STA] > (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node > 0xfffff8000549a640), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.CIND._STA] > (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.CIND._STA] (Node > 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.CIND._STA] > (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.CIND._STA] (Node > 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.VGBI._STA] > (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.VGBI._STA] (Node > 0xfffff8000549a180), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.VGBI._STA] > (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.VGBI._STA] (Node > 0xfffff8000549a180), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.BAT1._STA] > (Node 0xfffff8000549a640), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node > 0xfffff8000549a640), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.CIND._STA] > (Node 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.CIND._STA] (Node > 0xfffff8000549a2c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80) > [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.EC.VGBI._STA] > (Node 0xfffff8000549a180), AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.VGBI._STA] (Node > 0xfffff8000549a180), AE_NOT_EXIST (20160527/uteval-111) > > Regards, > Ben > > -- > From: Benjamin Woods > woodsb02@gmail.com > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Sun Jul 31 21:57: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 82A65BAAB85 for ; Sun, 31 Jul 2016 21:57:59 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BB391FA1; Sun, 31 Jul 2016 21:57:59 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by mail-io0-x22e.google.com with SMTP id b62so171702636iod.3; Sun, 31 Jul 2016 14:57:59 -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=mIFydDtWJecLQKs5KAlm6MZTois+KDYFyD3w8t6aB6g=; b=02jWUEC/03WR24/6/W77TJ8c07Uz05AgbXmQpFTgeiTPz6aWEiD8SmQlMu6nH2GKxI KS+cIGc8QwiFfwH5sbpLAfsUH8vYK+nbPzlrN3EphFdsU0k0Pj3KaY2nAUrkiDYuDKn6 J1+VXd7Vl/0odF19JCQyibaAQXoo5Ra/RndxO1SOGZVQyk+yxpfPN5nmPFC70HxvTdxk 3wYqF7V2axEtprKdVZjVpGcuE8FZPcRMnMS+runEjcMeNMiqxQWGp1UmyLtTOb2t3J5z wo3uXYP795epELeKj+Dg9bMD4j3aE6nJdxz2g/ZIeAKyNZD5Zn9Y4r4nCFwlf/a8umLV 61yw== 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=mIFydDtWJecLQKs5KAlm6MZTois+KDYFyD3w8t6aB6g=; b=FHx/Pgkk7QTIAEs4UJkYWZ6U0gFd/0mDy0bLGiMWTaNQwXJHsKO+M0uymiEpwxf5Cz gZWg7B2zy3s1jSfEGTYmiMDHPbm12MGipc97M9oeeGAcKiu62JyrI1HseUklbfW5DrTm w+lgR+uKIF0sVlQDJ/LLo0tjTlx0LMDGVSVRxHuPgFNSdK/SoeO6186OTJUJB4gkQ/Ke HV4WQQSvrIGJa018sY0ndf+1bcUqxeZCjOPeI5sPNqKqcFQPVq+RL5BF2UQDMnQmxLu9 K5wWWatrD6608L4pFtH6T7q9MAXPQbce42V3D6K6gCvR218U6cTcs1XUHHdIjCoEqHIG yo5Q== X-Gm-Message-State: AEkoouuEoqMIGwqCILDV9RoMRC+FXbF4UdD0bXNzzx9tusTBYhrxPbc4NtbSW5/YxiGkTuiHpKXhMuGPbOvsgQ== X-Received: by 10.107.140.205 with SMTP id o196mr59656509iod.42.1470002278744; Sun, 31 Jul 2016 14:57:58 -0700 (PDT) MIME-Version: 1.0 Sender: kmacybsd@gmail.com Received: by 10.107.143.11 with HTTP; Sun, 31 Jul 2016 14:57:58 -0700 (PDT) In-Reply-To: References: <20160731095706.GB9408@dft-labs.eu> From: "K. Macy" Date: Sun, 31 Jul 2016 14:57:58 -0700 X-Google-Sender-Auth: S0ovMhtGAtOHb0UYbxfkFPoIkTQ Message-ID: Subject: Re: [PATCH] randomized delay in locking primitives, take 2 To: Adrian Chadd Cc: Mateusz Guzik , John Baldwin , freebsd-current , Konstantin Belousov 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: Sun, 31 Jul 2016 21:57:59 -0000 On Sun, Jul 31, 2016 at 7:03 AM, Adrian Chadd wrote: > Hi, > > Did you test on any 1, 2, 4, 8 cpu machines? just to see if there are > any performance degredations on lower count CPUs? The adaptive spinning path will never run on a uniprocessor. Except for potential i-cache displacement you're not going to actually see any effect unless there is substantial contention. You'll need all threads consistently contending for the same lock. A potential workload to exercise this would be to run ncpu threads sending small UDP packets on a driver with a legacy mutex protected IFQ interface. > Also, yeah, the MOD operator in each loop could get spendy on older > CPUs (eg my MIPS CPUs, older ARM stuff, etc.) Is it possible to > achieve much the same autotuning with pow2 operations instead of > divide/mod? > > > -a > _______________________________________________ > 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 1 01:36: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 0B9F4BAA4F1; Mon, 1 Aug 2016 01:36:51 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DA6DA100C; Mon, 1 Aug 2016 01:36:50 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=6lfQX42BdBYtw3CjLfjEYBtJP0GTd/UZ4C335xElPJ0=; b=J7GFjffyvJUdwhuzBJ7/8M8N2q q8KSA3xiA8FwZ/ZQxte021ZvfzYUe056reTlHnkMgtIO1egUy5PV3w4W6+wn8t8ONwpItjV+EPllD xicpbrpS5+0t0QicJB5k2/Cv56IOEQLINew8jwN49i0qjj9wRtxkwdOaffbqAH57voks=; Received: from [2001:470:1f0f:42c:2247:47ff:fe73:75f] (port=17583 helo=pita) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1bU29x-000Is7-QG; Sun, 31 Jul 2016 20:36:49 -0500 Date: Sun, 31 Jul 2016 20:36:47 -0500 From: Larry Rosenman To: Adrian Chadd Cc: Imre Vad??sz , Andriy Voskoboinyk , "freebsd-wireless@freebsd.org" , freebsd-current , owner-freebsd-current@freebsd.org Subject: Re: IWM(7260), no connect Message-ID: <20160801013647.GA1294@pita> Mail-Followup-To: Adrian Chadd , Imre Vad??sz , Andriy Voskoboinyk , "freebsd-wireless@freebsd.org" , freebsd-current , owner-freebsd-current@freebsd.org References: <20160728023954.GA1321@pita> <20160728233504.GA1226@pita> <4ee03d28cc2711ed9bc56a725cac344a@thebighonker.lerctr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Mon, 01 Aug 2016 01:36:51 -0000 Even with that reverted, I'm still having iffy connections. Current code: FreeBSD pita 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r303597M: Sun Jul 31 16:02:39 CDT 2016 root@pita:/usr/obj/usr/src/sys/IWM-DEBUG amd64 1200001 1200001 Current diff to that SVN Rev: Index: sys/dev/iwm/if_iwm.c =================================================================== --- sys/dev/iwm/if_iwm.c (revision 303597) +++ sys/dev/iwm/if_iwm.c (working copy) @@ -3357,15 +3357,12 @@ uint8_t subtype = wh->i_fc[0] & IEEE80211_FC0_SUBTYPE_MASK; if (subtype == IEEE80211_FC0_SUBTYPE_ASSOC_REQ || - subtype == IEEE80211_FC0_SUBTYPE_REASSOC_REQ) { - tx->pm_frame_timeout = htole16(IWM_PM_FRAME_ASSOC); - } else if (subtype == IEEE80211_FC0_SUBTYPE_ACTION) { - tx->pm_frame_timeout = htole16(IWM_PM_FRAME_NONE); - } else { - tx->pm_frame_timeout = htole16(IWM_PM_FRAME_MGMT); - } + subtype == IEEE80211_FC0_SUBTYPE_REASSOC_REQ) + tx->pm_frame_timeout = htole16(3); + else + tx->pm_frame_timeout = htole16(2); } else { - tx->pm_frame_timeout = htole16(IWM_PM_FRAME_NONE); + tx->pm_frame_timeout = htole16(0); } if (hdrlen & 3) { Index: sys/dev/iwm/if_iwmreg.h =================================================================== --- sys/dev/iwm/if_iwmreg.h (revision 303597) +++ sys/dev/iwm/if_iwmreg.h (working copy) @@ -4244,18 +4244,6 @@ IWM_TX_CMD_FLG_HCCA_CHUNK = (1 << 31) }; /* IWM_TX_FLAGS_BITS_API_S_VER_1 */ -/** - * enum iwm_tx_pm_timeouts - pm timeout values in TX command - * @IWM_PM_FRAME_NONE: no need to suspend sleep mode - * @IWM_PM_FRAME_MGMT: fw suspend sleep mode for 100TU - * @IWM_PM_FRAME_ASSOC: fw suspend sleep mode for 10sec - */ -enum iwm_tx_pm_timeouts { - IWM_PM_FRAME_NONE = 0, - IWM_PM_FRAME_MGMT = 2, - IWM_PM_FRAME_ASSOC = 3, -}; - /* * TX command security control */ Scan Debug: http://www.lerctr.org/~ler/FreeBSD/WIFI-Scan.txt What next? On Thu, Jul 28, 2016 at 06:06:47PM -0700, Adrian Chadd wrote: > +imre, > > Hi! Larry is having issues with r303418. Would you be able to help him out? > > (If it's not too bad, can we back this out until you figure out what's > going on?) > > Thanks! > > > -a > > > On 28 July 2016 at 18:05, Larry Rosenman wrote: > > On 2016-07-28 20:02, Adrian Chadd wrote: > >> > >> Hi, > >> > >> Which commit(s) did you revert? > >> > >> > >> > >> -a > > > > > > revert r303418 > > > > and now it connects again. > > > > > > -- > > Larry Rosenman http://www.lerctr.org/~ler > > Phone: +1 214-642-9640 E-Mail: ler@lerctr.org > > US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 From owner-freebsd-current@freebsd.org Mon Aug 1 02:19: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 51323BAAE08; Mon, 1 Aug 2016 02:19:05 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2C18B12A6; Mon, 1 Aug 2016 02:19:05 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=QSDkfRIhJ6ZldVwgBzofx7OmwJJ27GpsAzT1atYw7II=; b=ikV+jcHbpLcTsHSyLEaZuHiEhH pPEnirHDnJaGVI6tyyLEWECAACrtpPW0hPisyRk4TaejxC48kMXSbclZsfiHFRZKgFJgOIcOpx7Go EILdH/YrNdddTMYHDYgA+x4U9V2agckxiZ87WQCGirx+23VPATYV70D5ewSpm8Czij4U=; Received: from [74.196.221.212] (port=58593 helo=pita) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1bU2oq-000K8u-6I; Sun, 31 Jul 2016 21:19:04 -0500 Date: Sun, 31 Jul 2016 21:19:02 -0500 From: Larry Rosenman To: Adrian Chadd Cc: Imre Vad??sz , Andriy Voskoboinyk , "freebsd-wireless@freebsd.org" , freebsd-current , owner-freebsd-current@freebsd.org Subject: Re: IWM(7260), no connect Message-ID: <20160801021902.GA1998@pita> Mail-Followup-To: Adrian Chadd , Imre Vad??sz , Andriy Voskoboinyk , "freebsd-wireless@freebsd.org" , freebsd-current , owner-freebsd-current@freebsd.org References: <20160728023954.GA1321@pita> <20160728233504.GA1226@pita> <4ee03d28cc2711ed9bc56a725cac344a@thebighonker.lerctr.org> <20160801013647.GA1294@pita> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160801013647.GA1294@pita> 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: Mon, 01 Aug 2016 02:19:05 -0000 I recompiled security/wpa_supplicant and seem to be able to get associated. I'm not sure what is going on. Any suggestions? On Sun, Jul 31, 2016 at 08:36:47PM -0500, Larry Rosenman wrote: > Even with that reverted, I'm still having iffy connections. > > Current code: > > FreeBSD pita 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r303597M: Sun Jul 31 16:02:39 CDT 2016 root@pita:/usr/obj/usr/src/sys/IWM-DEBUG amd64 1200001 1200001 > > Current diff to that SVN Rev: > > Index: sys/dev/iwm/if_iwm.c > =================================================================== > --- sys/dev/iwm/if_iwm.c (revision 303597) > +++ sys/dev/iwm/if_iwm.c (working copy) > @@ -3357,15 +3357,12 @@ > uint8_t subtype = wh->i_fc[0] & IEEE80211_FC0_SUBTYPE_MASK; > > if (subtype == IEEE80211_FC0_SUBTYPE_ASSOC_REQ || > - subtype == IEEE80211_FC0_SUBTYPE_REASSOC_REQ) { > - tx->pm_frame_timeout = htole16(IWM_PM_FRAME_ASSOC); > - } else if (subtype == IEEE80211_FC0_SUBTYPE_ACTION) { > - tx->pm_frame_timeout = htole16(IWM_PM_FRAME_NONE); > - } else { > - tx->pm_frame_timeout = htole16(IWM_PM_FRAME_MGMT); > - } > + subtype == IEEE80211_FC0_SUBTYPE_REASSOC_REQ) > + tx->pm_frame_timeout = htole16(3); > + else > + tx->pm_frame_timeout = htole16(2); > } else { > - tx->pm_frame_timeout = htole16(IWM_PM_FRAME_NONE); > + tx->pm_frame_timeout = htole16(0); > } > > if (hdrlen & 3) { > Index: sys/dev/iwm/if_iwmreg.h > =================================================================== > --- sys/dev/iwm/if_iwmreg.h (revision 303597) > +++ sys/dev/iwm/if_iwmreg.h (working copy) > @@ -4244,18 +4244,6 @@ > IWM_TX_CMD_FLG_HCCA_CHUNK = (1 << 31) > }; /* IWM_TX_FLAGS_BITS_API_S_VER_1 */ > > -/** > - * enum iwm_tx_pm_timeouts - pm timeout values in TX command > - * @IWM_PM_FRAME_NONE: no need to suspend sleep mode > - * @IWM_PM_FRAME_MGMT: fw suspend sleep mode for 100TU > - * @IWM_PM_FRAME_ASSOC: fw suspend sleep mode for 10sec > - */ > -enum iwm_tx_pm_timeouts { > - IWM_PM_FRAME_NONE = 0, > - IWM_PM_FRAME_MGMT = 2, > - IWM_PM_FRAME_ASSOC = 3, > -}; > - > /* > * TX command security control > */ > > > > Scan Debug: > http://www.lerctr.org/~ler/FreeBSD/WIFI-Scan.txt > > What next? > > On Thu, Jul 28, 2016 at 06:06:47PM -0700, Adrian Chadd wrote: > > +imre, > > > > Hi! Larry is having issues with r303418. Would you be able to help him out? > > > > (If it's not too bad, can we back this out until you figure out what's > > going on?) > > > > Thanks! > > > > > > -a > > > > > > On 28 July 2016 at 18:05, Larry Rosenman wrote: > > > On 2016-07-28 20:02, Adrian Chadd wrote: > > >> > > >> Hi, > > >> > > >> Which commit(s) did you revert? > > >> > > >> > > >> > > >> -a > > > > > > > > > revert r303418 > > > > > > and now it connects again. > > > > > > > > > -- > > > Larry Rosenman http://www.lerctr.org/~ler > > > Phone: +1 214-642-9640 E-Mail: ler@lerctr.org > > > US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 > > -- > Larry Rosenman http://www.lerctr.org/~ler > Phone: +1 214-642-9640 E-Mail: ler@lerctr.org > US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 From owner-freebsd-current@freebsd.org Mon Aug 1 05:52:32 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 11734BABA8B for ; Mon, 1 Aug 2016 05:52:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::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 CF3DB1717 for ; Mon, 1 Aug 2016 05:52:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x235.google.com with SMTP id f6so235354730ith.1 for ; Sun, 31 Jul 2016 22:52:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=3e0iRSDq5mh7OP9vtKicWros8IJDzooncCby/GmCTvE=; b=CzrtQz6qw2jkWxILQYUwpHn/Rb7naZDfW+BYQYb7BN5DQmTQ9A5CJruWmBLoeYbpOt B37CFs4U7elLjCiGt5HfIjxT4cWTIwmZYsq/133fYgNWCrNccgzYwgacI8VKzkKFoqYH JN0TXml+g1g2Y5cjhnLDkQdJIfiO2w/MizOLZyuAYShsl7upNVwmjnJ0617Po8rZMfen wtQ4tJ1WhRTMYC5Nk7oeOtqn8PWZYVgfK5ssHXOyyh3qYOheXxXLdY+Td0A7fIli3i5a mYitN8iA2TMRq2ZQmvqBbTkNKcTot3GP14BsKJIde9d0RCfJpxH2Vs8EUrEq4Ryi47oy xOXQ== 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=3e0iRSDq5mh7OP9vtKicWros8IJDzooncCby/GmCTvE=; b=mNCnAiYCttKpiCGAcelMYbEIuohdzj8hxsdKVv3jn6P4Q/bUF9d+dPbnS8Ij/tfp5R gvtgtmKr8TCiPHCotIgVlz6QiG4LZCygQMemL3BxX5c7Y/Kjk4XqjCCTCCusfVpufhx3 7ms38yprCD3TxtOdS2ObCyLKwK24fcGpb+15ienHrtLwzuiXgTKLAinrNQ3ZofBOJq0m 3m/JKHDXKer3QbhiPZCV6bMmJbHWNY5pEZXvlsnJhmHdappLP8ZLtXX5X99fcmBL1s6x dWKwBYq4M0h9kAbCJeyxGFTjxTh0xaF8TpNnhHaTEdidjxw1jOnIh6MChqgOVpHf6lwv TvDQ== X-Gm-Message-State: AEkoous9JvTLPclcywc310WiRSlGnaGZWUn+jtJojhD0OqlIdem+e7SWTGcoA6aYkkKv9rm8MT4CiN3YWl0fGg== X-Received: by 10.36.69.36 with SMTP id y36mr11637346ita.72.1470030751224; Sun, 31 Jul 2016 22:52:31 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.137.131 with HTTP; Sun, 31 Jul 2016 22:52:30 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <5489f1ff-d6db-c0e3-2be3-d3ae115a1f85@freebsd.org> References: <5bf35d8a-9941-9c6e-ea0a-20827ad26466@delphij.net> <5489f1ff-d6db-c0e3-2be3-d3ae115a1f85@freebsd.org> From: Warner Losh Date: Sun, 31 Jul 2016 23:52:30 -0600 X-Google-Sender-Auth: 5si01ciZShQBeNY1m2AYxbGLdNk Message-ID: Subject: Re: EFI boot: can we make loader.efi work as BOOT{x64, aa64, arm, ia32}.efi? To: Nathan Whitehorn Cc: 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, 01 Aug 2016 05:52:32 -0000 On Sun, Jul 31, 2016 at 12:51 AM, Nathan Whitehorn wrote: > > > On 07/30/16 23:20, Xin Li wrote: >> >> Hi, >> >> I finally got some time to explore the UEFI boot process (kudos to >> everyone who made this work!) and getting myself familiarize with the >> basics. >> >> One quick question -- Is there some technical restriction that prevents >> us from merging boot1.efi and loader.efi into one binary? >> >> Cheers, >> > > No technical reason (and, in fact, when you boot from CD, that's how it > works). The reason they are different is that we traditionally don't mount > the EFI partition and so make installworld can't replace things there. > boot1.efi is a basically static piece of code that doesn't need updates and > can load loader, which does get updates, from a UFS/ZFS system. boot1.efi is anything *BUT* a static piece of code. It was written to be such, but it's functionality is so limited that it is severely limiting what we can do on systems that want to, for example, boot off one partition after updating from another. That cannot be in loader.efi since that's part of the installed package. > loader.efi additionally assumes that it is started from the same partition > that contains the kernel, loader.conf, fstab, etc., which are also generally > not on the EFI partition (except in the CD case). That's likely one of several issues. Our EFI support is immature still. It works great if you have one disk that you want to boot off of. Once you stray far beyond that, there are many dragons. I think trying to merge the two is premature. Warner From owner-freebsd-current@freebsd.org Mon Aug 1 05:45: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 048E1BA7B4E for ; Mon, 1 Aug 2016 05:45:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 C287611BE for ; Mon, 1 Aug 2016 05:45:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22d.google.com with SMTP id f6so157770254ith.0 for ; Sun, 31 Jul 2016 22:45:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=OGmqLfEYJh7RM48dlwbbfuND+XVkf0B+uK8gR9kKn+0=; b=M7PBBx4mC+Fnf8i4K/V9l2QfqAg9xs55SDwB7XJA4RSxguQMRtV1MlfTocc66B8iiS RxxB3B6743rCUWp/lmuVPmgIBd3Hf7nYuyNi4nxQsqUg5ebdqBhGj1Al3YNEd+ZsNLzT YA+Ra3MO3EMO6+WoDRzmu7HvmuzRKsammO7jsd7nNVzTu7LeE07/yJNrWS69Icxobwyo 4n7cpO0bhaomAVlG4U966I4/p7eE2wjh5ueEaj8qIlm8VAJUCY93INdqtyFRBDA77oMS 9hfycnbC1S54z3OnsS1UBw53yOCq1gPucyyro6cx5WZfEojh0eTb/3DCUvFhjQ1EP/qd Xhew== 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=OGmqLfEYJh7RM48dlwbbfuND+XVkf0B+uK8gR9kKn+0=; b=I/HQ7JBUEGajD7X44ZOZ78K3h+QRGaAalKeE6MYAm1KmlO524cxyvGn5oooLkXuHYY JwTBgT3wyA4kAe71J+IrtX4alqk92cj4+zCXVtuExXUU0ZYDF/B3B0ybe7+ZbpazwcG4 /VeF5evy8K6z3xmUsCFlxVR4YkK0v/rLOKerhHFzUfxpGSEH+TbA40hwrh5nTFFCNuLJ 6NhgrnDM4RLM4X6BMcHC8e58Ki20Gkvl/bkY0UKQHh3mLeZJ5MPYUwwT4aKbJF6LF0gh c38gM2IDmsNNexKx2WU4Idc3KHzKvLQ1ycbICVuj7qpziuxT58Q9I5o+7AhaxflN5FBs +DRg== X-Gm-Message-State: AEkoousbB8S0Wz4oMCFsHjGR5iGWRpZeGm4VlK7ejD0N1bAMYxJ1WED57LXFaacIzOaIqze1wnCRDsxK5C48+g== X-Received: by 10.36.69.36 with SMTP id y36mr11622618ita.72.1470030353422; Sun, 31 Jul 2016 22:45:53 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.137.131 with HTTP; Sun, 31 Jul 2016 22:45:52 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <5bf35d8a-9941-9c6e-ea0a-20827ad26466@delphij.net> References: <5bf35d8a-9941-9c6e-ea0a-20827ad26466@delphij.net> From: Warner Losh Date: Sun, 31 Jul 2016 23:45:52 -0600 X-Google-Sender-Auth: gYvN7u7yF3ue3Goz1cAJOuDP6hg Message-ID: Subject: Re: EFI boot: can we make loader.efi work as BOOT{x64, aa64, arm, ia32}.efi? To: Xin Li Cc: FreeBSD Current , Xin LI 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, 01 Aug 2016 05:45:55 -0000 On Sun, Jul 31, 2016 at 12:20 AM, Xin Li wrote: > Hi, > > I finally got some time to explore the UEFI boot process (kudos to > everyone who made this work!) and getting myself familiarize with the > basics. > > One quick question -- Is there some technical restriction that prevents > us from merging boot1.efi and loader.efi into one binary? Yes. There's many technical reasons. Don't do it. loader.efi loads all the forth stuff from the partition it was loaded from. If you merge, it cannot do that. boot.efi should implement the UEFI boot manager protocol, but doesn't. Once it does, it can't be merged with loader.efi. We have deep issues with loader.efi if you have any system that's even a little complex. As these issues have come up, some have been fixed, but others haven't. It hasn't been possible, without ugly hacks, to boot off ping / pong partitions on the same disk for example. Please do not do this. It is a really bad idea. Warner From owner-freebsd-current@freebsd.org Mon Aug 1 06:34:14 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 133A8BADFF5 for ; Mon, 1 Aug 2016 06:34:14 +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 86A9F11D7; Mon, 1 Aug 2016 06:34:13 +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 u716Y8YQ015559 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 1 Aug 2016 09:34:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u716Y8YQ015559 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u716Y8C2015558; Mon, 1 Aug 2016 09:34:08 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 1 Aug 2016 09:34:08 +0300 From: Konstantin Belousov To: Mateusz Guzik Cc: Adrian Chadd , John Baldwin , freebsd-current Subject: Re: [PATCH] randomized delay in locking primitives, take 2 Message-ID: <20160801063408.GB83214@kib.kiev.ua> References: <20160731095706.GB9408@dft-labs.eu> <20160731203612.GH9408@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160731203612.GH9408@dft-labs.eu> 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, 01 Aug 2016 06:34:14 -0000 On Sun, Jul 31, 2016 at 10:36:12PM +0200, Mateusz Guzik wrote: > On Sun, Jul 31, 2016 at 07:03:08AM -0700, Adrian Chadd wrote: > > Also, yeah, the MOD operator in each loop could get spendy on older > > CPUs (eg my MIPS CPUs, older ARM stuff, etc.) Is it possible to > > achieve much the same autotuning with pow2 operations instead of > > divide/mod? > > > > The % operation acts a randomizer. It is optional and I'm happy to ifdef > it based on the architecture. It does seem to be useful at least on > amd64. > > As a side note, exponential backoff is not used to keep things smaller > (see above). It is definitely subject to change later. I asked for removal of the 64bit divide in the backoff precalculation, because the calculation is relatively intensive on 32bit i386 or arm, and loop consists of the calculation heating CPU and only then the loop starts issuing the PAUSE instructions, encoded as cpu_spinwait(). On the other hand, on e.g. MIPS, this is not true. cpu_spinwait() on MIPS is empty, so the backoff loop consists of heating CPU anyway. It does not matter if we heat it using divide instruction or branch instruction. I do not know is this fixable on MIPS, but it is definitely a bug on ARM to have empty cpu_spinwait(). It is additionally the bug that ARM MD code uses cpu_spinwait() in tight loops as well, without providing an implementation. From owner-freebsd-current@freebsd.org Mon Aug 1 07:34: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 7CBD5BAA184 for ; Mon, 1 Aug 2016 07:34:53 +0000 (UTC) (envelope-from gljennjohn@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 59DC5135D for ; Mon, 1 Aug 2016 07:34:53 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 5911DBAA183; Mon, 1 Aug 2016 07:34:53 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 58B5CBAA182 for ; Mon, 1 Aug 2016 07:34:53 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D9C0D135C; Mon, 1 Aug 2016 07:34:52 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm0-x243.google.com with SMTP id o80so24930123wme.0; Mon, 01 Aug 2016 00:34:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=kfYsHQYTbadGklCF85SD6LuNTaDTAOYzEQgmyZT9D8k=; b=Zuy9plVv4iHABikUCl8ek3vktFig9VGwwUFvm3+fcqSyDQ891gMcSv3o1uwEWJ8cqh STjHEdbvYirSee7ITeKhmqa4Mu/c6qGUbmVAekmpO4G0gOr3367Bm7bs6+Lp4VCAxS0l se+dA7uZxtj5bwZ0d+W4yZv16B6ysF91hcFG51vqcLBCMvOBeqXPFsam1j2yhJHz6yML 6klykCDin93orAFU/IXWkMwYI8bZ0nyy/Q9z1fnGYbBA0Z7lFOmULzNrMdXGiiHFsuVE Yh+jbS4Kx8XcfRpOFZiDcThxjsGGb24kcs6RafNW+QtRFfzeABhVDRINWAGEfjGebCWX LN8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=kfYsHQYTbadGklCF85SD6LuNTaDTAOYzEQgmyZT9D8k=; b=h+D4NbrwFV3buEfJVmiGU0mKoB42CDmgqT2QaXDQpMbD8eZUBZglTa8gulrNz0N201 UGF8xGMX5km3MQ/gZRNqn9W4/vfMMYtTAkwFDYVWLvhmGSmha47Rk0ct9ASlHLr6wjqY COps0NaLTm6CUn52IA67T+k+6H0rvsDYNNdw6fmoRnzmBK7rkvrwl6zV1/fmLxeVwyBE cyxpY0wswXVY5iLLtMbrr39pVV/vV1c/EJ7wd3slRosaF6Fxul0Kdtzl2UgVZeBFgAmU 7zwy55RNcFMqHgS1RUFn2W+csJjBMLgR527FuSFNpIHN7SmQuj9ql8gBb0RFHM+xadwk 3bVg== X-Gm-Message-State: AEkoouup0Nrn/s+uD+cvr3AcD93MaOLoBmkrzgXQnF6ZaddIihN+9f8q2Z7rxKWPp4n30A== X-Received: by 10.28.27.143 with SMTP id b137mr13048948wmb.12.1470036890574; Mon, 01 Aug 2016 00:34:50 -0700 (PDT) Received: from ernst.home (p578E09C6.dip0.t-ipconnect.de. [87.142.9.198]) by smtp.gmail.com with ESMTPSA id a203sm17055053wma.0.2016.08.01.00.34.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Aug 2016 00:34:44 -0700 (PDT) Date: Mon, 1 Aug 2016 09:34:34 +0200 From: Gary Jennejohn To: John Baldwin Cc: current@freebsd.org Subject: Re: EARLY_AP_STARTUP hangs during boot Message-ID: <20160801093434.410032f4@ernst.home> In-Reply-To: <1944919.bPt123bEA6@ralph.baldwin.cx> References: <20160516122242.39249a54@ernst.home> <8097239.52FCHCROUA@ralph.baldwin.cx> <20160731112914.58bd9765@ernst.home> <1944919.bPt123bEA6@ralph.baldwin.cx> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 01 Aug 2016 07:34:53 -0000 On Sun, 31 Jul 2016 14:22:35 -0700 John Baldwin wrote: > On Sunday, July 31, 2016 11:29:14 AM Gary Jennejohn wrote: > > On Sat, 30 Jul 2016 12:03:59 -0700 > > John Baldwin wrote: > > > > > On Saturday, July 30, 2016 09:44:22 AM Gary Jennejohn wrote: > > > > On Fri, 29 Jul 2016 13:17:42 -0700 > > > > John Baldwin wrote: > > > > > > > > > On Thursday, July 28, 2016 12:31:31 AM Gary Jennejohn wrote: > > > > > > Well, now I know that ULE is a prerequiste for EARLY_AP_STARTUP! I > > > > > > wasn't aware of that. I prefer BSD and that's the scheduler I did > > > > > > the first tests with. > > > > > > > > > > > > But with the ULE scheduler the system comes up all the way. > > > > > > > > > > > > It would be nice if the BSD scheduler could also be modified to > > > > > > work with EARLY_AP_STARTUP. > > > > > > > > > > I wasn't able to reproduce your hang with 4BSD, but I think I see a > > > > > possible problem. Try this: > > > > > > > > > > diff --git a/sys/kern/sched_4bsd.c b/sys/kern/sched_4bsd.c > > > > > index 7de56b6..d53331a 100644 > > > > > --- a/sys/kern/sched_4bsd.c > > > > > +++ b/sys/kern/sched_4bsd.c > > > > > @@ -327,7 +327,6 @@ maybe_preempt(struct thread *td) > > > > > * - The current thread has a higher (numerically lower) or > > > > > * equivalent priority. Note that this prevents curthread from > > > > > * trying to preempt to itself. > > > > > - * - It is too early in the boot for context switches (cold is set). > > > > > * - The current thread has an inhibitor set or is in the process of > > > > > * exiting. In this case, the current thread is about to switch > > > > > * out anyways, so there's no point in preempting. If we did, > > > > > @@ -348,7 +347,7 @@ maybe_preempt(struct thread *td) > > > > > ("maybe_preempt: trying to run inhibited thread")); > > > > > pri = td->td_priority; > > > > > cpri = ctd->td_priority; > > > > > - if (panicstr != NULL || pri >= cpri || cold /* || dumping */ || > > > > > + if (panicstr != NULL || pri >= cpri /* || dumping */ || > > > > > TD_IS_INHIBITED(ctd)) > > > > > return (0); > > > > > #ifndef FULL_PREEMPTION > > > > > @@ -1127,7 +1126,7 @@ forward_wakeup(int cpunum) > > > > > if ((!forward_wakeup_enabled) || > > > > > (forward_wakeup_use_mask == 0 && forward_wakeup_use_loop == 0)) > > > > > return (0); > > > > > - if (!smp_started || cold || panicstr) > > > > > + if (!smp_started || panicstr) > > > > > return (0); > > > > > > > > > > forward_wakeups_requested++; > > > > > > > > > > > > > Thanks, but with this patch the kernel hangs in exactly the same > > > > place as before - after the HPET output. > > > > > > > > Maybe I'm missing some kernel option which ULE works around, or > > > > something like that. > > > > > > Hmm, ok. Please add KTR_RUNQ and KTR_SMP to the KTR masks, that is > > > 'options KTR_COMPILE=(KTR_PROC|KTR_RUNQ|KTR_SMP)' and > > > 'options KTR_MASK=(KTR_PROC|KTR_RUNQ|KTR_SMP)' > > > > > > Please also add this patch (on top of the previous patch): > > > > > > diff --git a/sys/kern/sched_4bsd.c b/sys/kern/sched_4bsd.c > > > index 2973a23..bab2278 100644 > > > --- a/sys/kern/sched_4bsd.c > > > +++ b/sys/kern/sched_4bsd.c > > > @@ -1278,6 +1278,8 @@ sched_add(struct thread *td, int flags) > > > KASSERT(td->td_flags & TDF_INMEM, > > > ("sched_add: thread swapped out")); > > > > > > + CTR2(KTR_PROC, "sched_add: thread %d (%s)", td->td_tid, > > > + sched_tdname(td)); > > > KTR_STATE2(KTR_SCHED, "thread", sched_tdname(td), "runq add", > > > "prio:%d", td->td_priority, KTR_ATTR_LINKED, > > > sched_tdname(curthread)); > > > diff --git a/sys/x86/x86/cpu_machdep.c b/sys/x86/x86/cpu_machdep.c > > > index f07b97e..1f418f1 100644 > > > --- a/sys/x86/x86/cpu_machdep.c > > > +++ b/sys/x86/x86/cpu_machdep.c > > > @@ -440,6 +440,7 @@ cpu_idle_wakeup(int cpu) > > > return (0); > > > if (*state == STATE_MWAIT) > > > *state = STATE_RUNNING; > > > + CTR1(KTR_PROC, "cpu_idle_wakeup: wokeup CPU %d", cpu); > > > return (1); > > > } > > > > > > (I haven't tried compiling it, you might have to add the sys/ktr.h > > > header to cpu_machdep.c if it doesn't build.) > > > > > > Hopefully we will get some better trace messages before it hangs > > > with this added info. The root issue seems to be that 4BSD is > > > pinning thread0 to some other CPU (due to sched_bind that happens > > > inside of bus_bind_intr() when the HPET driver pins IRQs to CPUs) > > > and that other CPU isn't waking up to realize it needs to run thread0. > > > > > > > It compiled with no changes needed. > > > > Even though I set MAXCPU to a mere 2, the boot still hadn't > > completed after 90 minutes and I broke it off. I still have > > the kernel, so I can try it another time when I have less need > > for my FreeBSD box. > > Did you have the KTR options enabled from before? I don't expect this > to fix the issue, this is more about getting better debug info when it > hangs. > Yes, all the options from before were enabled. Maybe I should have disabled KTR_VERBOSE=1? I'll try it without that. I reduced MAXCPU because that reduced the amount of CPU core-related output by a factor of 3. I'm aware that you're just trying to get more information, but I use my FreeBSD box for pretty much everything and, after 90 minutes, I wanted to use it for something other than booting. -- Gary Jennejohn From owner-freebsd-current@freebsd.org Mon Aug 1 06:45:23 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 67342BACD35; Mon, 1 Aug 2016 06:45:23 +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 281C81A8F; Mon, 1 Aug 2016 06:45:22 +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 <1bU6yM-000mWX-2P>; Mon, 01 Aug 2016 08:45:10 +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 <1bU6yL-001051-PK>; Mon, 01 Aug 2016 08:45:09 +0200 Date: Mon, 1 Aug 2016 08:45:04 +0200 From: "O. Hartmann" To: Borja Marcos Cc: Jason Zhang , freebsd-performance@freebsd.org, freebsd-current@freebsd.org, freebsd-hardware@freebsd.org, freebsd-stable@freebsd.org Subject: Re: mfi driver performance too bad on LSI MegaRAID SAS 9260-8i Message-ID: <20160801084504.563c79cf@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: References: <16CD100A-3BD0-47BA-A91E-F445E5DF6DBC@cyphytech.com> <1466527001.2694442.644278905.18E236CD@webmail.messagingengine.com> <1790833A-9292-4A46-B43C-BF41C7C801BE@cyphytech.com> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Mon, 01 Aug 2016 06:45:23 -0000 On Wed, 22 Jun 2016 08:58:08 +0200 Borja Marcos wrote: > > On 22 Jun 2016, at 04:08, Jason Zhang wrote: > >=20 > > Mark, > >=20 > > Thanks > >=20 > > We have same RAID setting both on FreeBSD and CentOS including cache > > setting. In FreeBSD, I enabled the write cache but the performance is = the > > same. =20 > >=20 > > We don=E2=80=99t use ZFS or UFS, and test the performance on the RAW GE= OM disk > > =E2=80=9Cmfidx=E2=80=9D exported by mfi driver. We observed the =E2=80= =9Cgstat=E2=80=9D result and found > > that the write latency is too high. When we =E2=80=9Cdd" the disk with= 8k, it is > > lower than 1ms, but it is 6ms on 64kb write. It seems that each single > > write operation is very slow. But I don=E2=80=99t know whether it is a = driver > > problem or not. =20 >=20 > There is an option you can use (I do it all the time!) to make the card > behave as a plain HBA so that the disks are handled by the =E2=80=9Cda=E2= =80=9D driver.=20 >=20 > Add this to /boot/loader.conf >=20 > hw.mfi.allow_cam_disk_passthrough=3D1 > mfip_load=3D=E2=80=9CYES" >=20 > And do the tests accessing the disks as =E2=80=9Cda=E2=80=9D. To avoid co= nfusions, it=E2=80=99s > better to make sure the disks are not part of a =E2=80=9Cjbod=E2=80=9D or= logical volume > configuration. >=20 >=20 >=20 >=20 > Borja. [...] How is this supposed to work when ALL disks (including boot device) are set= tled with the mfi (in our case, it is a Fujitsu CP400i, based upon LSI3008 and detected within FreeBSD 11-BETA and 12-CURRENT) controller itself? I did not find any solution to force the CP400i into a mode making itself acting as a HBA (we intend to use all drives with ZFS and let FreeBSD kernel/ZFS control everything). The boot device is a 256 GB Samsung SSD for enterprise use and putting the = UEFI load onto a EFI partition from 11-CURRENT-ALPHA4 is worse: dd takes up to almost a minute to put the image onto the SSD. The SSD active LED is blinki= ng alle the time indicating activity. Caches are off. I tried to enable the ca= che via the mfiutil command by 'mfiutil cache mfid0 enable', but it failed ... = It failed also on all other attached drives. I didn't further go into more investigations right now, since the experience with the EFI boot loader makes me suspect bad performance and that is harsh= so to speak. Glad to have found this thread anyway. I cross post this also to CURRENT as it might be an issue with CURRENT ... Kind regards, Oliver Hartmann From owner-freebsd-current@freebsd.org Mon Aug 1 09:05: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 98965BAB303 for ; Mon, 1 Aug 2016 09:05:57 +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 5D43D18A3 for ; Mon, 1 Aug 2016 09:05:57 +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 <1bU9AZ-001blx-9Q>; Mon, 01 Aug 2016 11:05:55 +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 <1bU9AZ-001CK3-0C>; Mon, 01 Aug 2016 11:05:55 +0200 Date: Mon, 1 Aug 2016 11:05:54 +0200 From: "O. Hartmann" To: freebsd-current Subject: CURRENT: [USB] : GEOM_PART: da4 was automatically resized. Message-ID: <20160801110554.289d040d@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: Mon, 01 Aug 2016 09:05:57 -0000 On every(!) USB drive which worked well with 11-CURRENT up to 11-BETA, I fail to access with 12-CURRENT (12.0-CURRENT FreeBSD 12.0-CURRENT #14 r303475: Fri Jul 29 11:59:11 CEST 2016) with the error shown below. On USB flash drives I created myself, the suggested gpart command solved the problem, but I can not do this with drives I was given by a vendor or supplier. What is wrong? Kind regards and thank you very much in advance, O. Hartmann On console, I get the report: [...] GEOM_PART: da4 was automatically resized. Use `gpart commit da4` to save changes or `gpart undo da4` to revert them. From owner-freebsd-current@freebsd.org Mon Aug 1 09:19: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 568C6BAA650 for ; Mon, 1 Aug 2016 09:19:43 +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 4A6DB14CE; Mon, 1 Aug 2016 09:19:43 +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 CD8C81FF; Mon, 1 Aug 2016 09:19:42 +0000 (UTC) Date: Mon, 1 Aug 2016 09:19:41 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <521753929.83.1470043181156.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build became unstable: FreeBSD_HEAD #519 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 01 Aug 2016 09:19:43 -0000 See From owner-freebsd-current@freebsd.org Mon Aug 1 09:56: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 AD56EBAA2C5; Mon, 1 Aug 2016 09:56:44 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from cu01176b.smtpx.saremail.com (cu01176b.smtpx.saremail.com [195.16.151.151]) (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 3AE8E1812; Mon, 1 Aug 2016 09:56:43 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from [172.16.8.36] (izaro.sarenet.es [192.148.167.11]) by proxypop01.sare.net (Postfix) with ESMTPSA id 5B5319DC575; Mon, 1 Aug 2016 11:48:31 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: mfi driver performance too bad on LSI MegaRAID SAS 9260-8i From: Borja Marcos In-Reply-To: <20160801084504.563c79cf@freyja.zeit4.iv.bundesimmobilien.de> Date: Mon, 1 Aug 2016 11:48:30 +0200 Cc: Jason Zhang , freebsd-performance@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-hardware@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <1519EC23-0DBC-4139-96F6-250EF872A14B@sarenet.es> References: <16CD100A-3BD0-47BA-A91E-F445E5DF6DBC@cyphytech.com> <1466527001.2694442.644278905.18E236CD@webmail.messagingengine.com> <1790833A-9292-4A46-B43C-BF41C7C801BE@cyphytech.com> <20160801084504.563c79cf@freyja.zeit4.iv.bundesimmobilien.de> To: "O. Hartmann" 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: Mon, 01 Aug 2016 09:56:44 -0000 > On 01 Aug 2016, at 08:45, O. Hartmann = wrote: >=20 > On Wed, 22 Jun 2016 08:58:08 +0200 > Borja Marcos wrote: >=20 >> There is an option you can use (I do it all the time!) to make the = card >> behave as a plain HBA so that the disks are handled by the =E2=80=9Cda=E2= =80=9D driver.=20 >>=20 >> Add this to /boot/loader.conf >>=20 >> hw.mfi.allow_cam_disk_passthrough=3D1 >> mfip_load=3D=E2=80=9CYES" >>=20 >> And do the tests accessing the disks as =E2=80=9Cda=E2=80=9D. To = avoid confusions, it=E2=80=99s >> better to make sure the disks are not part of a =E2=80=9Cjbod=E2=80=9D = or logical volume >> configuration. >>=20 >>=20 >>=20 >>=20 >> Borja. > [...] >=20 > How is this supposed to work when ALL disks (including boot device) = are settled > with the mfi (in our case, it is a Fujitsu CP400i, based upon LSI3008 = and > detected within FreeBSD 11-BETA and 12-CURRENT) controller itself? >=20 > I did not find any solution to force the CP400i into a mode making = itself > acting as a HBA (we intend to use all drives with ZFS and let FreeBSD > kernel/ZFS control everything). Have you tried that particular option?=20 With kinda recent LSI based cards you have three options: - The most usual and definitely NOT RECOMMENDED option is to define a = logical volume per disk which actually LSI Logic called before JBOD mode. It=E2=80=99s not = recommended at all if you want to run ZFS. - Recent cards, I think I saw this first on the LSI3008, have a JBOD = mode that exposes the drives as =E2=80=9Cmfisyspd=E2=80=9D devices. I don=E2=80=99t recommend it either, because the syspd drives are a sort = of limited version of a disk device. With SSDs, especially, you don=E2=80=99t have access to the TRIM command. - The third option is to make the driver expose the SAS devices like a = HBA would do, so that they are visible to the CAM layer, and disks are handled by the stock =E2=80=9Cda=E2=80=9D = driver, which is the ideal solution.=20 However, this third option might not be available in some custom = firmware versions for certain manufacturers? I don=C2=B4t know. And I would hesitate to make the conversion on a production = machine unless you have a complete and reliable full backup of all the data in case you need to rebuild it. In order to do it you need a couple of things. You need to set the = variable hw.mfi.allow_cam_disk_passthrough=3D1 and to load the mfip.ko module. When booting installation media, enter command mode and use these = commands: ----- set hw.mfi.allow_cam_disk_passthrough=3D1 load mfip boot =E2=80=94=E2=80=94=E2=80=94 Remember that after installation you need to update /boot/loader.conf in = the system you just installed with the following contents: hw.mfi.allow_cam_disk_passthrough=3D1 mfip_load=3D=E2=80=9CYES=E2=80=9D A note regarding CAM and MFI visibility: On some old firmware versions = for the LSI2008 I=E2=80=99ve even seen the disks available both as =E2=80=9Cmfi=E2=80=9D and =E2=80=9Cda=E2=80=9D = drivers. If possible, you should try to set them up as =E2=80=9Cunconfigur= ed good=E2=80=9D on the RAID firmware. Use the RAID firmware set up or maybe mfiutil(8) Also, make sure you don=E2=80=99t create any logical volumes on the = disks you want exposed to CAM. You should delete the logical volumes so that the MFI firmware doesn=E2=80=99t do anything = with them.=20 AND BEWARE: Doing these changes to a system in production with valuable = data is dangerous. Make sure you have a full and sound backup before making these changes. As a worst case, the card could expose the devices both as =E2=80=9Csyspd=E2= =80=9D and CAM (i.e., =E2=80=9Cda=E2=80=9D drives) but as long as you = don=E2=80=99t touch the syspd devices the card won=E2=80=99t do anything to them as = far as I know. It could be a serious problem, however, if you=20 access a drive part of a logical volume through CAM, as RAID cards tend = do to =E2=80=9Cpatrol reads=E2=80=9D and other stuff on them.=20 Provided it=E2=80=99s safe to do what I recommended, try it and follow = up by email.=20 Borja. From owner-freebsd-current@freebsd.org Mon Aug 1 11:19: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 3DA08BABF11 for ; Mon, 1 Aug 2016 11:19:42 +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 566BB160C for ; Mon, 1 Aug 2016 11:19:40 +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 OAA06554; Mon, 01 Aug 2016 14:19:33 +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 1bUBFS-000KJb-9J; Mon, 01 Aug 2016 14:19:32 +0300 Subject: Re: [PATCH] randomized delay in locking primitives, take 2 To: Mateusz Guzik References: <20160731095706.GB9408@dft-labs.eu> Cc: freebsd-current@FreeBSD.org From: Andriy Gapon Message-ID: <32aa8f7f-8096-740c-13e3-d51e0cb57c23@FreeBSD.org> Date: Mon, 1 Aug 2016 14:16:59 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160731095706.GB9408@dft-labs.eu> 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, 01 Aug 2016 11:19:42 -0000 Mateusz, just out of curiosity, have you tried to explore alternative spinlock implementations like a ticket lock? It would be interesting to see if there are any improvements to be gained there. -- Andriy Gapon From owner-freebsd-current@freebsd.org Mon Aug 1 11:25:09 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A8117BA322D for ; Mon, 1 Aug 2016 11:25:09 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6EB571A4B; Mon, 1 Aug 2016 11:25:09 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1bUBLG-000PfX-Ai; Mon, 01 Aug 2016 14:25:06 +0300 Date: Mon, 1 Aug 2016 14:25:06 +0300 From: Slawa Olhovchenkov To: Andriy Gapon Cc: Mateusz Guzik , freebsd-current@FreeBSD.org Subject: Re: [PATCH] randomized delay in locking primitives, take 2 Message-ID: <20160801112506.GB22212@zxy.spb.ru> References: <20160731095706.GB9408@dft-labs.eu> <32aa8f7f-8096-740c-13e3-d51e0cb57c23@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32aa8f7f-8096-740c-13e3-d51e0cb57c23@FreeBSD.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 01 Aug 2016 11:25:09 -0000 On Mon, Aug 01, 2016 at 02:16:59PM +0300, Andriy Gapon wrote: > > Mateusz, > > just out of curiosity, have you tried to explore alternative spinlock > implementations like a ticket lock? It would be interesting to see if > there are any improvements to be gained there. Effective ticket lock implementation as I see limited to 256 (255?) concurent locks. And anyway may be need randomize delay (QPI bus on x86 have very limited performance). From owner-freebsd-current@freebsd.org Mon Aug 1 13:12:09 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 31D76BA7AFD; Mon, 1 Aug 2016 13:12:09 +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 E526F15E9; Mon, 1 Aug 2016 13:12:08 +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 <1bUD0m-0037tt-6I>; Mon, 01 Aug 2016 15:12:04 +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 <1bUD0l-001Y2q-Rz>; Mon, 01 Aug 2016 15:12:04 +0200 Date: Mon, 1 Aug 2016 15:12:03 +0200 From: "O. Hartmann" To: Borja Marcos Cc: Jason Zhang , freebsd-performance@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: mfi driver performance too bad on LSI MegaRAID SAS 9260-8i Message-ID: <20160801151203.14a7a67d@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <1519EC23-0DBC-4139-96F6-250EF872A14B@sarenet.es> References: <16CD100A-3BD0-47BA-A91E-F445E5DF6DBC@cyphytech.com> <1466527001.2694442.644278905.18E236CD@webmail.messagingengine.com> <1790833A-9292-4A46-B43C-BF41C7C801BE@cyphytech.com> <20160801084504.563c79cf@freyja.zeit4.iv.bundesimmobilien.de> <1519EC23-0DBC-4139-96F6-250EF872A14B@sarenet.es> 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=utf-8 Content-Transfer-Encoding: quoted-printable 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: Mon, 01 Aug 2016 13:12:09 -0000 On Mon, 1 Aug 2016 11:48:30 +0200 Borja Marcos wrote: Hello. First, thanks for responding so quickly. > > On 01 Aug 2016, at 08:45, O. Hartmann wro= te: > >=20 > > On Wed, 22 Jun 2016 08:58:08 +0200 > > Borja Marcos wrote: > > =20 > >> There is an option you can use (I do it all the time!) to make the card > >> behave as a plain HBA so that the disks are handled by the =E2=80=9Cda= =E2=80=9D driver.=20 > >>=20 > >> Add this to /boot/loader.conf > >>=20 > >> hw.mfi.allow_cam_disk_passthrough=3D1 > >> mfip_load=3D=E2=80=9CYES" > >>=20 > >> And do the tests accessing the disks as =E2=80=9Cda=E2=80=9D. To avoid= confusions, it=E2=80=99s > >> better to make sure the disks are not part of a =E2=80=9Cjbod=E2=80=9D= or logical volume > >> configuration. > >>=20 > >>=20 > >>=20 > >>=20 > >> Borja. =20 > > [...] > >=20 > > How is this supposed to work when ALL disks (including boot device) are > > settled with the mfi (in our case, it is a Fujitsu CP400i, based upon > > LSI3008 and detected within FreeBSD 11-BETA and 12-CURRENT) controller > > itself? > >=20 > > I did not find any solution to force the CP400i into a mode making itse= lf > > acting as a HBA (we intend to use all drives with ZFS and let FreeBSD > > kernel/ZFS control everything). =20 >=20 > Have you tried that particular option?=20 I have, indeed, used the "JBOD" function of the PRAID CP400i controller and= the intention of my posting regards to the suspicion, that this is, as mentione= d in many posts concerning RAID controllers and ZFS, the reason for the worse performance. And as I can see, it has been confirmed, sadly. >=20 > With kinda recent LSI based cards you have three options: >=20 > - The most usual and definitely NOT RECOMMENDED option is to define a log= ical > volume per disk which actually LSI Logic called before JBOD mode. It=E2= =80=99s not > recommended at all if you want to run ZFS. This is the only way to expose each disk as it is to the OS with the PRAID CP400i built-in into our RX1330-M2 server (XEON Skylake based). I ordered t= hat specific box with a HBA capable controller. Searching the net reveals that there is another one, called PSAS CP400i, which is also based on LSI/Avago SAS3008 and the possibility to expose drives as-is is explicitely mentioned= . I do not know whether this is a software feature - as I suspect - or something which has been hardwired to the controller. >=20 > - Recent cards, I think I saw this first on the LSI3008, have a JBOD mode > that exposes the drives as =E2=80=9Cmfisyspd=E2=80=9D devices. I don=E2= =80=99t recommend it either, > because the syspd drives are a sort of limited version of a disk device. = With > SSDs, especially, you don=E2=80=99t have access to the TRIM command. They expose the drives as "mfidX" if setup as JBOD. >=20 > - The third option is to make the driver expose the SAS devices like a HBA > would do, so that they are visible to the CAM layer, and disks are handle= d by > the stock =E2=80=9Cda=E2=80=9D driver, which is the ideal solution.=20 I didn't find any switch which offers me the opportunity to put the PRAID CP400i into a simple HBA mode. =20 >=20 > However, this third option might not be available in some custom firmware > versions for certain manufacturers? I don=C2=B4t know. And I would hesita= te to > make the conversion on a production machine unless you have a complete and > reliable full backup of all the data in case you need to rebuild it. The boxes are empty and ready-for-installation, so I do not worry. It is mo= re worrying about this stupid software-based strangulations of options by Fuji= tsu - if any. i do not want to blame them before I haven't double-checked. >=20 > In order to do it you need a couple of things. You need to set the variab= le > hw.mfi.allow_cam_disk_passthrough=3D1 and to load the mfip.ko module. >=20 > When booting installation media, enter command mode and use these command= s: >=20 > ----- > set hw.mfi.allow_cam_disk_passthrough=3D1 > load mfip > boot > =E2=80=94=E2=80=94=E2=80=94 Well, I'm truly aware of this problemacy and solution (now), but I run into= a henn-egg-problem, literally. As long as I can boot off of the installation medium, I have a kernel which deals with the setting. But the boot medium is supposed to be a SSD sitting with the PRAID CP400i controller itself! So, I never be able to boot off the system without crippling the ability to have a fullspeed ZFS configuration which I suppose to have with HBA mode, but not with any of the forced RAID modes offered by the controller.=20 I will check with Fujitsu for a solution. Maybe the PRAID CP400i is capable somehow of being a PSAS CP400i also, even if not exposed by the recent/installed firmware. Kind regards, Oliver=20 =20 >=20 >=20 > Remember that after installation you need to update /boot/loader.conf in = the > system you just installed with the following contents: >=20 > hw.mfi.allow_cam_disk_passthrough=3D1 > mfip_load=3D=E2=80=9CYES=E2=80=9D >=20 >=20 > A note regarding CAM and MFI visibility: On some old firmware versions for > the LSI2008 I=E2=80=99ve even seen the disks available both as =E2=80=9Cm= fi=E2=80=9D and =E2=80=9Cda=E2=80=9D > drivers. If possible, you should try to set them up as =E2=80=9Cunconfigu= red good=E2=80=9D on > the RAID firmware. Use the RAID firmware set up or maybe mfiutil(8) >=20 > Also, make sure you don=E2=80=99t create any logical volumes on the disks= you want > exposed to CAM. You should delete the logical volumes so that the MFI > firmware doesn=E2=80=99t do anything with them.=20 >=20 > AND BEWARE: Doing these changes to a system in production with valuable d= ata > is dangerous. Make sure you have a full and sound backup before making th= ese > changes. >=20 > As a worst case, the card could expose the devices both as =E2=80=9Csyspd= =E2=80=9D and CAM > (i.e., =E2=80=9Cda=E2=80=9D drives) but as long as you don=E2=80=99t touc= h the syspd devices the card > won=E2=80=99t do anything to them as far as I know. It could be a serious= problem, > however, if you access a drive part of a logical volume through CAM, as R= AID > cards tend do to =E2=80=9Cpatrol reads=E2=80=9D and other stuff on them.= =20 >=20 > Provided it=E2=80=99s safe to do what I recommended, try it and follow up= by email.=20 >=20 >=20 >=20 >=20 >=20 > Borja. >=20 >=20 >=20 >=20 > _______________________________________________ > freebsd-performance@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd= .org" From owner-freebsd-current@freebsd.org Mon Aug 1 13:30:09 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 816A2BA7F48; Mon, 1 Aug 2016 13:30:09 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from cu01176b.smtpx.saremail.com (cu01176b.smtpx.saremail.com [195.16.151.151]) (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 06F271D5B; Mon, 1 Aug 2016 13:30:08 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from [172.16.8.36] (izaro.sarenet.es [192.148.167.11]) by proxypop01.sare.net (Postfix) with ESMTPSA id D14279DCCC2; Mon, 1 Aug 2016 15:29:58 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: mfi driver performance too bad on LSI MegaRAID SAS 9260-8i From: Borja Marcos In-Reply-To: <20160801151203.14a7a67d@freyja.zeit4.iv.bundesimmobilien.de> Date: Mon, 1 Aug 2016 15:29:58 +0200 Cc: Jason Zhang , freebsd-performance@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-hardware@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <0CA1A1F1-AFDD-4763-84C3-2FC059F44789@sarenet.es> References: <16CD100A-3BD0-47BA-A91E-F445E5DF6DBC@cyphytech.com> <1466527001.2694442.644278905.18E236CD@webmail.messagingengine.com> <1790833A-9292-4A46-B43C-BF41C7C801BE@cyphytech.com> <20160801084504.563c79cf@freyja.zeit4.iv.bundesimmobilien.de> <1519EC23-0DBC-4139-96F6-250EF872A14B@sarenet.es> <20160801151203.14a7a67d@freyja.zeit4.iv.bundesimmobilien.de> To: "O. Hartmann" 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: Mon, 01 Aug 2016 13:30:09 -0000 > On 01 Aug 2016, at 15:12, O. Hartmann = wrote: >=20 > First, thanks for responding so quickly. >=20 >> - The third option is to make the driver expose the SAS devices like = a HBA >> would do, so that they are visible to the CAM layer, and disks are = handled by >> the stock =E2=80=9Cda=E2=80=9D driver, which is the ideal solution.=20= >=20 > I didn't find any switch which offers me the opportunity to put the = PRAID > CP400i into a simple HBA mode. The switch is in the FreeBSD mfi driver, the loader tunable I mentioned, = regardless of what the card firmware does or pretends to do. It=E2=80=99s not visible doing a "sysctl -a=E2=80=9D, but it exists and = it=E2=80=99s unique even. It=E2=80=99s defined here: = https://svnweb.freebsd.org/base/stable/10/sys/dev/mfi/mfi_cam.c?revision=3D= 267084&view=3Dmarkup (line 93) >> In order to do it you need a couple of things. You need to set the = variable >> hw.mfi.allow_cam_disk_passthrough=3D1 and to load the mfip.ko module. >>=20 >> When booting installation media, enter command mode and use these = commands: >>=20 >> ----- >> set hw.mfi.allow_cam_disk_passthrough=3D1 >> load mfip >> boot >> =E2=80=94=E2=80=94=E2=80=94 >=20 > Well, I'm truly aware of this problemacy and solution (now), but I run = into a > henn-egg-problem, literally. As long as I can boot off of the = installation > medium, I have a kernel which deals with the setting. But the boot = medium is > supposed to be a SSD sitting with the PRAID CP400i controller itself! = So, I > never be able to boot off the system without crippling the ability to = have a > fullspeed ZFS configuration which I suppose to have with HBA mode, but = not > with any of the forced RAID modes offered by the controller.=20 Been there plenty of times, even argued quite strongly about the = advantages of ZFS against hardware based RAID 5 cards. :) I remember when the Dell salesmen couldn=E2=80=99t possibly = understand why I wanted a =E2=80=9Csoftware based RAID rather than a robust, hardware based solution=E2=80=9D :D=20 At worst, you can set up a simple boot from a thumb drive or, even = better, a SATADOM installed inside the server. I guess it will have SATA ports on the mainboard. That=E2=80=99s what I use to do. = FreeNAS uses a similar approach as well. And some modern servers also can boot from a SD card which you can use just to load the kernel. Depending on the number of disks you have, you can also sacrifice two to = set up a mirror with a =E2=80=9Cnomal=E2=80=9D boot system, and using the rest of the disks for ZFS. Actually I=E2=80=99ve got an old server I = set up in 2012. It has 16 disks, and I created a logical volume (mirror) with 2 disks for boot, the other 14 disks for ZFS. If I installed this server now I would do it different, booting off a = thumb drive. But I was younger and naiver :) Borja. From owner-freebsd-current@freebsd.org Mon Aug 1 13:31:18 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8251EBAA307 for ; Mon, 1 Aug 2016 13:31:18 +0000 (UTC) (envelope-from gljennjohn@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 5EDA412AF for ; Mon, 1 Aug 2016 13:31:18 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 5DD4CBAA303; Mon, 1 Aug 2016 13:31:18 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5D7CCBAA301 for ; Mon, 1 Aug 2016 13:31:18 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DEF5812A7; Mon, 1 Aug 2016 13:31:17 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm0-x244.google.com with SMTP id x83so26159720wma.3; Mon, 01 Aug 2016 06:31:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=2fCFMhcAAdI3fbfZdCHLVZRwpEeMI/rbEYiD4FtXnN4=; b=qHyhz6BVe6vlaSioDrABSPgkZjT6ejwXhpqRn64Hkr3Vvx/8nmWdTE1ScpkAevnk08 5vPJRcVyABvTOLAHuHbIZE+zh7K/Xj3S/duGGYaDK0fbTLI7+oZA+EWiRlG9Jd/qDLwK hVFlcBlMhJqAInERFcb4I/gOwEFNlnBaCZ19RYfHfJaS0lkZtkDme/NLglSgBDzCXbYE 7qj+cDl+Yht6HxDcjB+WE9Yj3IVcZW/t0AJOGFEymfYzJ6NUCoC4RTWgpWe/XwhgMNdp /YaK0Sfu/lrZpYSaFbopkvK5UxK6S8sUGw/U+5n/K7CPTmZw3Q6knonPvKRESsqooCEd wpGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=2fCFMhcAAdI3fbfZdCHLVZRwpEeMI/rbEYiD4FtXnN4=; b=M3MbeBWsWIHIah8ALLTrvFUqsDpnTCJBqvC2H+IzDfJZSoAUOPBGRTjh049CQWi3qi iss5Sq7CQT0Rwrt/6EULkr88n82uS1h5Rf4aXfk05go8OPx+IJ3MOmZynuszoTSi7UxJ f3Hl59FJwZn0VZ063OwzbXiv6SzA7ccEJosu7AYwxSxG2dEYNlUVgjF9OblJpl9OebWX Z43EKXJSfpMRumuHCG/XzXoj7+Vj1aa9KYrCo19rzOw6I80YAlTu1bKshoP8b3sq5RqH Rcow2sXw9hMcQfxCgjea0Jq/batm0qCV5eHaBGldAunOGaB/FYdWHqkX9uxH5cehjDAy ni2A== X-Gm-Message-State: AEkooutcsoZp6oM7KcFsGZlaH5NMtt0/GZXV5jQDHGBtsHgFxz5lgoiyu/Mro/NO+vn0BA== X-Received: by 10.28.131.199 with SMTP id f190mr14083305wmd.30.1470058275265; Mon, 01 Aug 2016 06:31:15 -0700 (PDT) Received: from ernst.home (p578E09C6.dip0.t-ipconnect.de. [87.142.9.198]) by smtp.gmail.com with ESMTPSA id n2sm30660998wjd.1.2016.08.01.06.31.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Aug 2016 06:31:14 -0700 (PDT) Date: Mon, 1 Aug 2016 15:31:11 +0200 From: Gary Jennejohn To: John Baldwin Cc: current@freebsd.org Subject: Re: EARLY_AP_STARTUP hangs during boot Message-ID: <20160801153111.5e59d3ce@ernst.home> In-Reply-To: <20160801093434.410032f4@ernst.home> References: <20160516122242.39249a54@ernst.home> <8097239.52FCHCROUA@ralph.baldwin.cx> <20160731112914.58bd9765@ernst.home> <1944919.bPt123bEA6@ralph.baldwin.cx> <20160801093434.410032f4@ernst.home> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 01 Aug 2016 13:31:18 -0000 On Mon, 1 Aug 2016 09:34:34 +0200 Gary Jennejohn wrote: > On Sun, 31 Jul 2016 14:22:35 -0700 > John Baldwin wrote: > > > On Sunday, July 31, 2016 11:29:14 AM Gary Jennejohn wrote: > > > On Sat, 30 Jul 2016 12:03:59 -0700 > > > John Baldwin wrote: > > > > > > > On Saturday, July 30, 2016 09:44:22 AM Gary Jennejohn wrote: > > > > > On Fri, 29 Jul 2016 13:17:42 -0700 > > > > > John Baldwin wrote: > > > > > > > > > > > On Thursday, July 28, 2016 12:31:31 AM Gary Jennejohn wrote: > > > > > > > Well, now I know that ULE is a prerequiste for EARLY_AP_STARTUP! I > > > > > > > wasn't aware of that. I prefer BSD and that's the scheduler I did > > > > > > > the first tests with. > > > > > > > > > > > > > > But with the ULE scheduler the system comes up all the way. > > > > > > > > > > > > > > It would be nice if the BSD scheduler could also be modified to > > > > > > > work with EARLY_AP_STARTUP. > > > > > > > > > > > > I wasn't able to reproduce your hang with 4BSD, but I think I see a > > > > > > possible problem. Try this: > > > > > > > > > > > > diff --git a/sys/kern/sched_4bsd.c b/sys/kern/sched_4bsd.c > > > > > > index 7de56b6..d53331a 100644 > > > > > > --- a/sys/kern/sched_4bsd.c > > > > > > +++ b/sys/kern/sched_4bsd.c > > > > > > @@ -327,7 +327,6 @@ maybe_preempt(struct thread *td) > > > > > > * - The current thread has a higher (numerically lower) or > > > > > > * equivalent priority. Note that this prevents curthread from > > > > > > * trying to preempt to itself. > > > > > > - * - It is too early in the boot for context switches (cold is set). > > > > > > * - The current thread has an inhibitor set or is in the process of > > > > > > * exiting. In this case, the current thread is about to switch > > > > > > * out anyways, so there's no point in preempting. If we did, > > > > > > @@ -348,7 +347,7 @@ maybe_preempt(struct thread *td) > > > > > > ("maybe_preempt: trying to run inhibited thread")); > > > > > > pri = td->td_priority; > > > > > > cpri = ctd->td_priority; > > > > > > - if (panicstr != NULL || pri >= cpri || cold /* || dumping */ || > > > > > > + if (panicstr != NULL || pri >= cpri /* || dumping */ || > > > > > > TD_IS_INHIBITED(ctd)) > > > > > > return (0); > > > > > > #ifndef FULL_PREEMPTION > > > > > > @@ -1127,7 +1126,7 @@ forward_wakeup(int cpunum) > > > > > > if ((!forward_wakeup_enabled) || > > > > > > (forward_wakeup_use_mask == 0 && forward_wakeup_use_loop == 0)) > > > > > > return (0); > > > > > > - if (!smp_started || cold || panicstr) > > > > > > + if (!smp_started || panicstr) > > > > > > return (0); > > > > > > > > > > > > forward_wakeups_requested++; > > > > > > > > > > > > > > > > Thanks, but with this patch the kernel hangs in exactly the same > > > > > place as before - after the HPET output. > > > > > > > > > > Maybe I'm missing some kernel option which ULE works around, or > > > > > something like that. > > > > > > > > Hmm, ok. Please add KTR_RUNQ and KTR_SMP to the KTR masks, that is > > > > 'options KTR_COMPILE=(KTR_PROC|KTR_RUNQ|KTR_SMP)' and > > > > 'options KTR_MASK=(KTR_PROC|KTR_RUNQ|KTR_SMP)' > > > > > > > > Please also add this patch (on top of the previous patch): > > > > > > > > diff --git a/sys/kern/sched_4bsd.c b/sys/kern/sched_4bsd.c > > > > index 2973a23..bab2278 100644 > > > > --- a/sys/kern/sched_4bsd.c > > > > +++ b/sys/kern/sched_4bsd.c > > > > @@ -1278,6 +1278,8 @@ sched_add(struct thread *td, int flags) > > > > KASSERT(td->td_flags & TDF_INMEM, > > > > ("sched_add: thread swapped out")); > > > > > > > > + CTR2(KTR_PROC, "sched_add: thread %d (%s)", td->td_tid, > > > > + sched_tdname(td)); > > > > KTR_STATE2(KTR_SCHED, "thread", sched_tdname(td), "runq add", > > > > "prio:%d", td->td_priority, KTR_ATTR_LINKED, > > > > sched_tdname(curthread)); > > > > diff --git a/sys/x86/x86/cpu_machdep.c b/sys/x86/x86/cpu_machdep.c > > > > index f07b97e..1f418f1 100644 > > > > --- a/sys/x86/x86/cpu_machdep.c > > > > +++ b/sys/x86/x86/cpu_machdep.c > > > > @@ -440,6 +440,7 @@ cpu_idle_wakeup(int cpu) > > > > return (0); > > > > if (*state == STATE_MWAIT) > > > > *state = STATE_RUNNING; > > > > + CTR1(KTR_PROC, "cpu_idle_wakeup: wokeup CPU %d", cpu); > > > > return (1); > > > > } > > > > > > > > (I haven't tried compiling it, you might have to add the sys/ktr.h > > > > header to cpu_machdep.c if it doesn't build.) > > > > > > > > Hopefully we will get some better trace messages before it hangs > > > > with this added info. The root issue seems to be that 4BSD is > > > > pinning thread0 to some other CPU (due to sched_bind that happens > > > > inside of bus_bind_intr() when the HPET driver pins IRQs to CPUs) > > > > and that other CPU isn't waking up to realize it needs to run thread0. > > > > > > > > > > It compiled with no changes needed. > > > > > > Even though I set MAXCPU to a mere 2, the boot still hadn't > > > completed after 90 minutes and I broke it off. I still have > > > the kernel, so I can try it another time when I have less need > > > for my FreeBSD box. > > > > Did you have the KTR options enabled from before? I don't expect this > > to fix the issue, this is more about getting better debug info when it > > hangs. > > > > Yes, all the options from before were enabled. Maybe I should have > disabled KTR_VERBOSE=1? I'll try it without that. > KTR_VERBOSE=1 is necessary. OK, after about 5 hours it landed in an infinite loop emitting: cpu_0 ipi_cpu: cpu: 1 to 5 ipi: 2 (my CPU has 6 cores) -- Gary Jennejohn From owner-freebsd-current@freebsd.org Mon Aug 1 14:08: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 E9D87BAAD95 for ; Mon, 1 Aug 2016 14:08:08 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9F9711892 for ; Mon, 1 Aug 2016 14:08:08 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qt0-x22e.google.com with SMTP id 52so104849256qtq.3 for ; Mon, 01 Aug 2016 07:08:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :user-agent; bh=tVYBL4JMjI+PeohjXBV5FCMPF1XoMDN7lJu10xJEBYw=; b=CbQuJFoT0aYQkCX51+sTMkQ2ruGyZNuteIHbdRsh3unIK7Zq8m4nPG6PnUD3NYT8K3 O6j1T7G0RT5rw5UK1tCCNG5gEc7xfg+Ni1uiE2y6fW10tR0Fdq94DZrSEUV/cZ9AUnQ1 TE33hAJfCPknoW5Rg7Fab2W2BiZnZ38kEzejUmQVgzI24klXynk2aAPKbIqVbAddAkNF WWNEnq9kXiP9fTjguMfeggkTAwgPi0+CrL/dlbCLyf9afFd4XmMZmHa+lPPZnXvkD/PB 0h0MpWAKzUiuYFIxEgrJFn7I/CftyTnkNTzfg5EWy7OTQ3/6tKCWdnqVNOH+YL4RczRi FBeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:user-agent; bh=tVYBL4JMjI+PeohjXBV5FCMPF1XoMDN7lJu10xJEBYw=; b=VcNzMcPgtJ7w/M7S7ejHi+RqVQNhATGfQF8Uic6l+7Af2Of9s4NnDKdzEF9wlGlg19 Bv5+xEjU5XFaOKz6HZqEZ566m37OTR4aAnNLCgv4EIgtZGTx4aXexK4fnnRv1hs8wKjQ 9T646phBGRaSh3v5K6AesszsDnTPdzcMSYIz3xBfPRsUigpPz0brJeRJb9hj1QQLx62y Oa6Jx8e8y9g8LPQXi+nynWNaNTI9GfsDQ0uI+W00bNaDa9BX1ADC21Ox5QpupZIKO34z inkbubcDrkWKVi5uoR8XcEHDDRgmDMW8zd+6ggioksVMoTxs58uZKA3X7H6SMhQo0mNm R0cg== X-Gm-Message-State: AEkoouurFORSRd8TWezOqPC5rKTX6glvb664XHokzFiDBSMLJixvruPGzL8czY7QtJ2YNRIZcRLvXrDPxq6979s5iSXfPVzWU4ue2S7y4euDx7kbBuC661pThp1MlOEbQ0fRHWCrLfZc+n5HXMOVQspDvJQYA/fIQRUld1Mfs7ACWemGZkoYxG6iiG7yYPUA4sU/iozU X-Received: by 10.200.45.8 with SMTP id n8mr89100254qta.57.1470060487638; Mon, 01 Aug 2016 07:08:07 -0700 (PDT) Received: from mutt-hardenedbsd (pool-100-16-217-171.bltmmd.fios.verizon.net. [100.16.217.171]) by smtp.gmail.com with ESMTPSA id 22sm17688054qtw.21.2016.08.01.07.08.05 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 01 Aug 2016 07:08:06 -0700 (PDT) Date: Mon, 1 Aug 2016 10:08:04 -0400 From: Shawn Webb To: freebsd-current@freebsd.org Cc: freebsd-ports@freebsd.org, mandree@freebsd.org Subject: security/openvpn build failure on 12-CURRENT/amd64 Message-ID: <20160801140804.GD7956@mutt-hardenedbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ylS2wUBXLOxYXZFQ" Content-Disposition: inline X-Operating-System: FreeBSD mutt-hardenedbsd 12.0-CURRENT-HBSD FreeBSD 12.0-CURRENT-HBSD X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE 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: Mon, 01 Aug 2016 14:08:09 -0000 --ylS2wUBXLOxYXZFQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey All, It looks like security/openvpn fails to build on 12-CURRENT/amd64 on both FreeBSD's and HardenedBSD's build infrastructure. I've verified that it builds fine on latest 11-STABLE/amd64. Would this be a regression in 12-CURRENT? Log file from FreeBSD's build: http://beefy4.nyi.freebsd.org/data/head-amd64-default/p419204_s303419/logs/= errors/openvpn-2.3.11.log Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --ylS2wUBXLOxYXZFQ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXn1fBAAoJEGqEZY9SRW7ukFgP/RY5XtRontIb1hlGy0V3hRqG r2soltjqrvJl4FGRanrWcHlOWVg7fGGhXzxwIFfmUNB3evSc+c7LiN2TRqEyDI2A cuYutmCc/nR5bRJEAIFA0RFquokpXuA0VREQIjMe2lAHcERuCqV3I1SCwkkJNcUR AUXxBMHU5OeiH8Ky7ubv3Ysyvx/wnnspUA1Yt3ir+X3swOmdV5NcZcWbA8AC/epy whmnoH1d2jqBUG0+AWgnYEj6jbjykSSJZz7GaRsrj/vtpo4qJHvF48DAFFf7iDKq 5ZFF+IH/ENL189mhsXquEBgr2ai9GBXYCWHctx4q7KcwmL9vYeihQjqZqJhKc2E1 wAWjc0fZBnlM35klyUPxf9Abvi84+efhiCQMCv1xL1Wk8qoqJS8HAU2+8Vs05W2x bhfMyJQsp4F/2DLNfcNfba3QGjgBZJotyG2fhy+MuvWpmt3S35wAaY0MIY4CSVR5 sajroZDq1t5wMnE2q+nbI67/8j4OQqyLbbs2Bc9rFDwPvZiq649SfX6RzYnnlIYl 1mmuQGHruV3I4J4za5gNTmLL8bYJHcEATVjdb8mjr8xuG4ISBrO00NHxMeaaNLgS WqjouTUeQR4w8tYYXuA3dg6PCwHca+Q+MQS9IbESwrqt7+1MUhBwHQMhLDiGriDK uIZrEWXaCMnM4nh1e8e3 =uZn3 -----END PGP SIGNATURE----- --ylS2wUBXLOxYXZFQ-- From owner-freebsd-current@freebsd.org Mon Aug 1 14:31:23 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 64864BAA369 for ; Mon, 1 Aug 2016 14:31:23 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::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 194031462 for ; Mon, 1 Aug 2016 14:31:23 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qk0-x22f.google.com with SMTP id v123so14076658qkh.3 for ; Mon, 01 Aug 2016 07:31:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=NlgYni9fitJAqvmihUDyhHnrIZln4tU+xtXOVpTFNTA=; b=o/chVPOpG0tGRjTAqKd3oy0uDwIMXObCPXAKVtYO/xtOpmXES9n6BKu77EaONT7+hx CmLUEQ1qDxeD5HXt1NP68fkTRxPbQHs/uPuJzkCqaO2z0/Pt7XsHTETT/gy1FzwtdJPe w4x5+gjdZ9C5SSDAur4xhVuxBdv7wvWhg3Cd1KqRAaLhyYy+M9Xjh5D1iDJF0JztaMBb Xuibb1uGrdwC0lqKXJ1uNCAaFAL7jCCb2oaoL8JPFEyWqxlozt1gj5LYFgPYwNcJp18H hcHQLVwu2tksBtXREiNac38+tRGTVTjemmHHJAb9tYV1mX5bvTb7xeHc6QBwRiYVxoOD yP4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=NlgYni9fitJAqvmihUDyhHnrIZln4tU+xtXOVpTFNTA=; b=iXHmoFtWi4mfRYgMWJyPbotAJIDjZMH11YvLWHa52+9on7ahrCnbLCjvvyPN9Fyc8o DyNxJPlOGg2QPwEQ72LEWAYropqAl6ZWxskucn77/1F3+I5rQFVhP+OfWRfybkqBEIcz bXNhSvSnkr9G8FwECEG2TcCUDp5458j3q8/9OWxK9Hi+TWQaVUDcxBaNgldtJTzAFV5x rb1w/NI2S1gaf2tqKEVgsndtvr9siJKm8qXY4vTLY9fs+PQiHkRyID4E/drkQ3IJn+Dc OvRrnguFxj4Gak2M2+dsOcthC+d4i88ESDKyA4ytBvPTbVCIvNmL8N884/tr9floYLLo J4+w== X-Gm-Message-State: AEkoouuKbKdkdzZBy2xliUE08mM2OlgbO/jJZhz8SzVs/8nEz8h6yAKSq9C6GrEDzSgeJobE X-Received: by 10.55.73.148 with SMTP id w142mr70572467qka.77.1470061881926; Mon, 01 Aug 2016 07:31:21 -0700 (PDT) Received: from mutt-hardenedbsd (pool-100-16-217-171.bltmmd.fios.verizon.net. [100.16.217.171]) by smtp.gmail.com with ESMTPSA id j7sm17713202qkf.11.2016.08.01.07.31.20 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 01 Aug 2016 07:31:20 -0700 (PDT) Date: Mon, 1 Aug 2016 10:31:18 -0400 From: Shawn Webb To: Matthias Andree Cc: freebsd-current@freebsd.org, freebsd-ports@freebsd.org Subject: Re: security/openvpn build failure on 12-CURRENT/amd64 Message-ID: <20160801143118.GE7956@mutt-hardenedbsd> References: <20160801140804.GD7956@mutt-hardenedbsd> <2061B016-057C-44E9-A982-C0B689861E40@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BQPnanjtCNWHyqYD" Content-Disposition: inline In-Reply-To: <2061B016-057C-44E9-A982-C0B689861E40@freebsd.org> X-Operating-System: FreeBSD mutt-hardenedbsd 12.0-CURRENT-HBSD FreeBSD 12.0-CURRENT-HBSD X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE 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: Mon, 01 Aug 2016 14:31:23 -0000 --BQPnanjtCNWHyqYD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 01, 2016 at 02:26:39PM +0000, Matthias Andree wrote: > Hi Shawn, >=20 > The compilation attempt was done on an invalid configuration and has zero= relevance whatsoever. As the log says: >=20 > !!! Jail is newer than host. (Jail: 1200001, Host: 1100116) !!!=20 > !!! This is not supported. !!!=20 > !!! Host kernel must be same or newer than jail. !!!=20 > !!! Expect build failures. !!! >=20 > I wish the builders would stop even trying to build a package on a kernel= that is too old, it's just confusing and wasteful. >=20 Hey Matthias, HardenedBSD's kernel and world matched and still had the very same build error. Here's the build log: http://pastebin.com/TEBih1Sx Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --BQPnanjtCNWHyqYD Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXn100AAoJEGqEZY9SRW7umH4P/0zUI4MLobjIXpFHfH5NzeVH DMRnFFmZH9Lo+MGleOfTv5C+qlmAvc5Ft2icrjLtnBKHD1YTfEnD2IZ0RMcRrPvY D2AyAZPVP2eLlwAeLXjjZ2gn2McKzqT95jKoLvAm9iqViVH2gFCy8XcihGEMtyF6 sVrn1qPoyFdv/Dk3xIQzrgVZdbXe0hDoXNPh5VB8WiU/KiVzPE4p1cyYvoJraC9L jGmy6vZiZilodylsbvB7ZHeCCS6gdZYYXsZqdI8/7GQ3ObJDuiyDG3E5KhUY94yc AiAztzyCoyjVTHJiKRlPn9KSamDejZu3mq1pnSuWkzrZ8oI0EJM4wzN8V6JXvsIG NRHA9p2ACeNPoI1WHmv/lGTV/BvUQr9rf2eXdvCtgwfBOOdpSjZzFyYTysR/C9NK OBY2DYaAishRjncozVQZvo8DIr0fHqu6xgDSIaIvP53exM9o7GgdA9mS483zHMka k3I5cVYj3ZEmppRJthUbd2Dj9+yot9iRyVnpJYvd2NBW3UKnLkHJzYTkquaawDyo Z6q1FkuIPe9WS/MzodYL2gpI837ijhHnH0Kcu1dIeifDCt8aP78p8DR1ka+4QqNA djCLLS20bdfyAJ3q7j/xSnzVlJ1qD3AaKu4MLLk5UOXe4kXhaYwuDUCo/KzPIYYM W5CCgkP11LV5vM1wJtEV =oGV2 -----END PGP SIGNATURE----- --BQPnanjtCNWHyqYD-- From owner-freebsd-current@freebsd.org Mon Aug 1 15:05: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 43DF7BAAD68 for ; Mon, 1 Aug 2016 15:05:54 +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 35B56155F; Mon, 1 Aug 2016 15:05:54 +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 04323207; Mon, 1 Aug 2016 15:05:53 +0000 (UTC) Date: Mon, 1 Aug 2016 15:05:53 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <449343806.85.1470063953904.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <521753929.83.1470043181156.JavaMail.jenkins@jenkins-9.freebsd.org> References: <521753929.83.1470043181156.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to stable : FreeBSD_HEAD #520 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: Mon, 01 Aug 2016 15:05:54 -0000 See From owner-freebsd-current@freebsd.org Mon Aug 1 16:21: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 70868BAA326; Mon, 1 Aug 2016 16:21:59 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 38DF2192B; Mon, 1 Aug 2016 16:21:59 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::d857:c5e3:f7:85c] (unknown [IPv6:2001:7b8:3a7:0:d857:c5e3:f7:85c]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 431B514D3D; Mon, 1 Aug 2016 18:21:56 +0200 (CEST) Subject: Re: BSD grep dumps core Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_56E280E6-6C8C-4D30-B32E-3A3B0932FE1F"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6.1 From: Dimitry Andric In-Reply-To: <20160731153738.GA33643@troutmask.apl.washington.edu> Date: Mon, 1 Aug 2016 18:22:16 +0200 Cc: FreeBSD Current , FreeBSD Hackers Message-Id: <54B0B5B7-25CF-4B7D-9874-73D33481CC1C@FreeBSD.org> References: <20160731153738.GA33643@troutmask.apl.washington.edu> To: Steve Kargl 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: Mon, 01 Aug 2016 16:21:59 -0000 --Apple-Mail=_56E280E6-6C8C-4D30-B32E-3A3B0932FE1F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 31 Jul 2016, at 17:37, Steve Kargl = wrote: >=20 > Script started on Sun Jul 31 08:30:56 2016 > troutmask:sgk[200] cd gcc/gcc7 > troutmask:sgk[201] svn status > ? 7.diff > ? decl.c.diff > ? gcc/fortran/old > ? gcc/fortran/pr38351.diff > ? gcc/fortran/pr41922.diff > ? gcc/fortran/pr69860.diff > ? trans-decl.c.diff > ? typescript > ? z1.diff > troutmask:sgk[202] svn status | grep -v -E ^\? > Segmentation fault (core dumped) > troutmask:sgk[203] svn status | grep -v -E ^"\?" > troutmask:sgk[204] exit > exit >=20 > Script done on Sun Jul 31 08:31:54 2016 >=20 > The core dump happens with both tcsh and sh. >=20 > The following works as expected >=20 > troutmask:sgk[202] svn status | gnugrep -v -E ^\? Yes, '^?' is an invalid extended regular expression, but GNU grep does not complain about it, and simply discards the '?' character. Our BSD grep dies because it also attempts to discard, but then some later logic goes beyond the end of the buffer. Please try this fix: Index: usr.bin/grep/regex/tre-fastmatch.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- usr.bin/grep/regex/tre-fastmatch.c (revision 303551) +++ usr.bin/grep/regex/tre-fastmatch.c (working copy) @@ -621,7 +621,7 @@ tre_compile_fast(fastmatch_t *fg, const tre_char_t case TRE_CHAR('+'): case TRE_CHAR('?'): if ((cflags & REG_EXTENDED) && (i =3D=3D 0)) - continue; + goto badpat; else if ((cflags & REG_EXTENDED) ^ !escaped) STORE_CHAR; else After this, bsdgrep errors out with: % bsdgrep -E '^?' bsdgrep: Invalid preceding regular expression which is much saner IMHO. -Dimitry --Apple-Mail=_56E280E6-6C8C-4D30-B32E-3A3B0932FE1F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAlefdzwACgkQsF6jCi4glqN/fACguF9Gh9i4kCUA936CLMlMHnCZ +4oAn1iuihtI/htbER4YTHFqym/hQbJ3 =zfdm -----END PGP SIGNATURE----- --Apple-Mail=_56E280E6-6C8C-4D30-B32E-3A3B0932FE1F-- From owner-freebsd-current@freebsd.org Mon Aug 1 16:38: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 E5253BAA925 for ; Mon, 1 Aug 2016 16:38:10 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 B36E51833 for ; Mon, 1 Aug 2016 16:38:10 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-it0-x231.google.com with SMTP id f6so175888835ith.0 for ; Mon, 01 Aug 2016 09:38:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=4bTPUAdYH1+Lg5yKhdzaTOyT/HDfGgJNE4kpc5K3aYU=; b=DASR2FxzxJ4EMYHndDL+ijLuUiBToFELrYE1mt6M4F1KKgir9o1vOGsP3nNrTcewLV 7DaEdrFmpVm9+GJwcPDV701rFgMXx/XBhBeSEeQu1fYq3vfzAGrmVNdCX49pgNyCjQ/+ FnWNGLnlWfSNQnwIL049j/JUEPT/pD87UlrC1eji9lpwTEj/x1bvJ63KgeAmQQ7pM4/G 1rqO+Vo7KDczePMwWghDYjKMynWNB3/cpSIXCzNIvuEg/AKB43Y3HutGFBfPs2cEhXEQ tC974oFhdKVR9p0hTMsJlzc2V5ebYaUfjlakyZtgSGXHKUuQUp+tVtiD9d49buf6XORt W+6A== 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; bh=4bTPUAdYH1+Lg5yKhdzaTOyT/HDfGgJNE4kpc5K3aYU=; b=gogrPRXv4jlyoj6uqE7aYTHZHh+uTJRz+VQuzbx0Ee2Qn6L118sJNQHuiMfuy6CmRR zEfYXzyC4IYFeM6MmIIakmR6nkHWII052wUBk2zGDd7vO8yBfTG43HpMHCVz2jiT9T8+ l1lt3joVmawL5EOHWw3eDsFM7N/Y1Tpq+FNH1ogJgGrH5KrZjBKDLueZ3YIeZ5er/DLI b91HG921bek/LUFahMMu6TpmbVCCuiEVKFVSkADxrscRlgQJeX3hMfabeVS7oYaE8vYm GuOalmxrJK8UIr9aKeR5TmUT/eFaulh57NcJ/D3g+H8mwTyiMGOOrTPpc2TaHO/oSYU6 lh3A== X-Gm-Message-State: AEkoouuV+Bixh7he1SRH2ynpEGjC5GquaA+puUmMBaDkbdoN0DRQ4j2kdF8DuAmQjxsm9q9XnqmkdHmibkpDamAk X-Received: by 10.36.90.79 with SMTP id v76mr55442487ita.16.1470069489795; Mon, 01 Aug 2016 09:38:09 -0700 (PDT) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.36.13.139 with HTTP; Mon, 1 Aug 2016 09:38:09 -0700 (PDT) In-Reply-To: <20160731203612.GH9408@dft-labs.eu> References: <20160731095706.GB9408@dft-labs.eu> <20160731203612.GH9408@dft-labs.eu> From: Maxim Sobolev Date: Mon, 1 Aug 2016 09:38:09 -0700 X-Google-Sender-Auth: UwqdkXZc2FzQ-zB1HPTwiY-6bjg Message-ID: Subject: Re: [PATCH] randomized delay in locking primitives, take 2 To: Mateusz Guzik , Adrian Chadd , John Baldwin , freebsd-current , Konstantin Belousov 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, 01 Aug 2016 16:38:11 -0000 On Sun, Jul 31, 2016 at 1:36 PM, Mateusz Guzik wrote: > On Sun, Jul 31, 2016 at 07:03:08AM -0700, Adrian Chadd wrote: > > Hi, > > > > Did you test on any 1, 2, 4, 8 cpu machines? just to see if there are > > any performance degredations on lower count CPUs? > > > > I did not test on machines which physically that few cpus, but I did > test the impact on microbenchmark with 2 and 4 threads on the 80-way > machine. There was no difference. > Well, arguably running 4 threads on a 80-way machine is not quite the same as running the same 4 threads on 4-way or 8-way machine. Unless you actually bind your test threads to a specific CPUs, on a bigger system scheduler is free to migrate your thread on another CPU if all 4 are spinning, this might not the option for smaller box. I suggest you at very least re-run your benchmark on a virtual machine with small CPUs count assigned, it should be quite easy to do so on your monster box. -Maxim From owner-freebsd-current@freebsd.org Mon Aug 1 16:43:47 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 22167BAAC6A for ; Mon, 1 Aug 2016 16:43:47 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A9FEF11B2; Mon, 1 Aug 2016 16:43:46 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-wm0-x242.google.com with SMTP id o80so26951020wme.0; Mon, 01 Aug 2016 09:43:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=uG9Uq90yphB65SHQMkqq5faoVwMb4LE2z5SJ2LJUJms=; b=cKtlWoIA1plCVty1BRoXMQo8+NhJRRe99qr1/tAyrrGBbxPP7ybcWfz7A+iMTa//gc +U1naJdV69PAfCXUetuw6R1GKWFX6AMnM9R/a12Su2oN7zOkpis0q21TEQ6I49i0mGVv XD3B/ruhxjvPv/zux7pN+91VggK7aFlSb628wSzSc7aWZAAF2V9+6+1WJvl/V9k3rHw2 aCzAibjCupBmOfs0vmBnb24GoRQ8q2SLWpUCNquoS8nufTYvAVIN8jFNZK5/09NGPsl/ misXsuI36yfVpraDUSMxsix+BAiKIcqVsFGOZw8ifG4Kn+hRN0Iro111Pa/fl1imVPWW XBgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=uG9Uq90yphB65SHQMkqq5faoVwMb4LE2z5SJ2LJUJms=; b=nAcS6loognXolydFS78qJmuwEg6gBI6V0OQVQJJOHogC+nPPDVMBSUKV0AvvDE0AMY DM0cU1vst9dliLw6Js5qcwl3GAGBLdnqQqZKKzt17dTT+x1MJ4QpPjdLoGTwFYSxi0H1 eOxrg97H1cuFWFSKjLgzvHBwz4StzMFKXXf7NeAcakKiKG6S0ax5JyObjrJDNyi26BqL qNip8F6h1Sl5axlt68qZ2S1y9wy5pz2R1WG1xQFgLY2JLnuz4ptv3t0CqP6JQdyLXJHp BHlL+CTs7K2I3ognSdlj1Qdu5WlZXchh2bQeFSoVSkao+NqvVydXJ9xJ97pIsAPbm40t vWbw== X-Gm-Message-State: AEkooutDetQMRucRq/dRNvHQxBuyQCU4zte2dfSYtGMkSeAYL07ehicj+owGSyJA/9BasQ== X-Received: by 10.194.77.97 with SMTP id r1mr55509416wjw.83.1470069824090; Mon, 01 Aug 2016 09:43:44 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by smtp.gmail.com with ESMTPSA id 3sm17894041wms.1.2016.08.01.09.43.43 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Mon, 01 Aug 2016 09:43:43 -0700 (PDT) Date: Mon, 1 Aug 2016 18:43:40 +0200 From: Mateusz Guzik To: Andriy Gapon Cc: freebsd-current@FreeBSD.org Subject: Re: [PATCH] randomized delay in locking primitives, take 2 Message-ID: <20160801164340.GA24633@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Andriy Gapon , freebsd-current@FreeBSD.org References: <20160731095706.GB9408@dft-labs.eu> <32aa8f7f-8096-740c-13e3-d51e0cb57c23@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <32aa8f7f-8096-740c-13e3-d51e0cb57c23@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) 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, 01 Aug 2016 16:43:47 -0000 On Mon, Aug 01, 2016 at 02:16:59PM +0300, Andriy Gapon wrote: > > Mateusz, > > just out of curiosity, have you tried to explore alternative spinlock > implementations like a ticket lock? It would be interesting to see if > there are any improvements to be gained there. > The patch is the simplest hack possible so that this has a chance of getting into 11.0 as it helps /a lot/ even in the simplest form. Revamping this stuff in a more "here to stay" manner is a much longer endeavor. -- Mateusz Guzik From owner-freebsd-current@freebsd.org Mon Aug 1 16:55: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 71FE6BAAF8B for ; Mon, 1 Aug 2016 16:55:27 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 1247719BB; Mon, 1 Aug 2016 16:55:27 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-wm0-x229.google.com with SMTP id f65so377763785wmi.0; Mon, 01 Aug 2016 09:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=22KdzTdkkVCMmg0TyV/SqawbdKmJSg3B4RuK3H41kVA=; b=gkvi5jKJAERfSLQkGHIEP676qa8qwJVTzc2D5x7uS3AFiTCS5yMhV3U+OpD934Oo2W vOPqTTWHXDYhxmNpPiREPZHqzSH4lIbjHxvSU7lDqbtXXoSHA79oAjMpuwjTH5ZIdVDr EHVBi0AdpmQrtLFBYuQ0/QJWZI6L4jxD8a++iFrRVacqoMRxGXdooqRwWjxj4FGxlixd SwSxBDlabR67RjsfpCl7+/e18jiNizGGWkeJUZgw3sJtoBCrsVIOz5sazaRNZCpn4p1N cpBYzXq8zxZfm2WNpj7x42s2zh5Z/LsMpLqtweEny21kdmosCHy8ZFA7HHCI1Cqq8GKY otZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=22KdzTdkkVCMmg0TyV/SqawbdKmJSg3B4RuK3H41kVA=; b=W2pKq+Sml6CYUB2rVzY/whpoEzINYgsn7nfeNUywiBJsjsEZ79YCk3NylZBFMAhmVl IqbYHnCM/14gt+Fqmnjuc2rSFFlO8aknS1WkNJYjfgOQSCliKL2RmmdFCHGvsY7Xi1ts KZRtQPTnpiIua2XbXbGMEVxZD8ZmrLaJ81RG+FVZvSOl3XVasuEsTbO7+UpuHp8lSQJo 4ocAUmz82rH9T+ieVpjndRCfy470oeW/qq39UDOtyWRPi1d2GUUyS1OIlxQrBoatQnJ4 Lxbd/k9o8Gkn7dvg4oOOZogrJBHCTCG/2ox65802SEwapBIocn6kCPCTWPa65GMnHhrl JUXg== X-Gm-Message-State: AEkoouvOQrFjG6oIclfy0aUhtLGy9qFudT6nAUX9dBEJrW9o96B1BXKgV56RvhQVoHeNbg== X-Received: by 10.194.65.72 with SMTP id v8mr57076716wjs.103.1470070525457; Mon, 01 Aug 2016 09:55:25 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by smtp.gmail.com with ESMTPSA id ub8sm25101172wjc.39.2016.08.01.09.55.24 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Mon, 01 Aug 2016 09:55:24 -0700 (PDT) Date: Mon, 1 Aug 2016 18:55:22 +0200 From: Mateusz Guzik To: Maxim Sobolev Cc: Adrian Chadd , John Baldwin , freebsd-current , Konstantin Belousov Subject: Re: [PATCH] randomized delay in locking primitives, take 2 Message-ID: <20160801165522.GB24633@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Maxim Sobolev , Adrian Chadd , John Baldwin , freebsd-current , Konstantin Belousov References: <20160731095706.GB9408@dft-labs.eu> <20160731203612.GH9408@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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, 01 Aug 2016 16:55:27 -0000 On Mon, Aug 01, 2016 at 09:38:09AM -0700, Maxim Sobolev wrote: > On Sun, Jul 31, 2016 at 1:36 PM, Mateusz Guzik wrote: > > > On Sun, Jul 31, 2016 at 07:03:08AM -0700, Adrian Chadd wrote: > > > Hi, > > > > > > Did you test on any 1, 2, 4, 8 cpu machines? just to see if there are > > > any performance degredations on lower count CPUs? > > > > > > > I did not test on machines which physically that few cpus, but I did > > test the impact on microbenchmark with 2 and 4 threads on the 80-way > > machine. There was no difference. > > > > Well, arguably running 4 threads on a 80-way machine is not quite the same > as running the same 4 threads on 4-way or 8-way machine. Unless you > actually bind your test threads to a specific CPUs, on a bigger system > scheduler is free to migrate your thread on another CPU if all 4 are > spinning, this might not the option for smaller box. I suggest you at very > least re-run your benchmark on a virtual machine with small CPUs count > assigned, it should be quite easy to do so on your monster box. > The test does bind threads to cpus. Further, the dealy is autotuned based on the number of cpus in the system. I also once more stress that the backoff is extremely small and we don't take full advantage of it specifically so that detrimental behaviour is very unlikely. So here even on the 80-way machine with 80 * 25 initial delay there was no performance loss with only few threads competing. The worry could have been it helps only if all cpu threads compete and hurts performance otherwise. On an actual 4-way machine will have only 4 * 25 delays configured with 4 * 25 * 10 upper limit. But note the actual delay is cpu_ticks() % that value, so even that is often smaller. tl;dr this is really a simple patch and at least on amd64 a pure win -- Mateusz Guzik From owner-freebsd-current@freebsd.org Mon Aug 1 17:40: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 DACE5BABAC8 for ; Mon, 1 Aug 2016 17:40:39 +0000 (UTC) (envelope-from rwestlun@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 90DCA135A for ; Mon, 1 Aug 2016 17:40:39 +0000 (UTC) (envelope-from rwestlun@gmail.com) Received: by mail-qk0-x236.google.com with SMTP id p74so152185933qka.0 for ; Mon, 01 Aug 2016 10:40:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=LasT4tdaqnhBQZdLG5X/acLih4U7YHsY6b8Z5hHvMBQ=; b=S6qQXo5gdC5iAHrjlHCuJLduZi+dJ2EpakjUUfw5balw6vp3CelrT/BW1bRCws89fc LD+iKFdiOQ9lSeSIvdRiqbYuuyoSkP+JRMJ9Vj70MrLcAMTprVbPbpl5nWHCbo0H3mwM 7/swgjvC0WAvhlzujc2zA/uEFMznZTq2IB4h8i+J4zteO8/OHb6NGrtxAqNm48vCrGlE p26RRukT3V3XJjVRcAdH+wkn5TecVxJsmRvFXy9Z45BD52WJ9ZM+LO5VKqv2sqGAJAeA cZb6PNMvm3/8jHtrtE4NwxDHKbZASXdHWhbk4SXVcVb3dmUFWgqOl3OKAzQSEihLm8dl vwIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=LasT4tdaqnhBQZdLG5X/acLih4U7YHsY6b8Z5hHvMBQ=; b=CLweFKI5+Y79hyNe8wW1Bh/MLfVwsfmULtZrloTlKBRUruiIgWgEXq0jTY7VxyCYva VfuECypDZ9uZjflvxKmHOfE8tfq1fTuac0oKGzGHiU+eLkqy0puxyX3C/GE62e6w5/Ib pzO/9ErXjAaywA0/bAIJHY0htzyb6IVkVPBjDU0N09yto0Jf9jf7irkcttRuwIF0VXMm U0OmOF+nwt3iSCiLqt/E4t9KdvRRvQ2hCDNWWgpSmYQn/B3poFdVhydWaK/81X/eUaka hq1229Jy4t4lT9o5vmt2BwXzkxc9B7YzuA2O6bZ2ozZwgXI8PQg9qNAMKPN9HtZ+PNEK yl1w== X-Gm-Message-State: AEkoouthKfTZgynU8vR9yHPLjxe9JK4z8zvb4EKN3hAWEyYA7HLEyw+rmcAxSd7EkxUnLw== X-Received: by 10.55.42.199 with SMTP id q68mr30892313qkq.30.1470073238688; Mon, 01 Aug 2016 10:40:38 -0700 (PDT) Received: from gmail.com (c-98-216-247-110.hsd1.ma.comcast.net. [98.216.247.110]) by smtp.gmail.com with ESMTPSA id l22sm18182034qtl.34.2016.08.01.10.40.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Aug 2016 10:40:37 -0700 (PDT) Date: Mon, 1 Aug 2016 13:40:35 -0400 From: Randy Westlund To: "O. Hartmann" Cc: freebsd-current Subject: Re: CURRENT: [USB] : GEOM_PART: da4 was automatically resized. Message-ID: <20160801174035.GI74453@gmail.com> References: <20160801110554.289d040d@freyja.zeit4.iv.bundesimmobilien.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="enLffk0M6cffIOOh" Content-Disposition: inline In-Reply-To: <20160801110554.289d040d@freyja.zeit4.iv.bundesimmobilien.de> 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: Mon, 01 Aug 2016 17:40:40 -0000 --enLffk0M6cffIOOh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 01, 2016 at 11:05:54AM +0200, O. Hartmann wrote: > On every(!) USB drive which worked well with 11-CURRENT up to 11-BETA, I = fail > to access with 12-CURRENT (12.0-CURRENT FreeBSD 12.0-CURRENT #14 r303475:= Fri > Jul 29 11:59:11 CEST 2016) with the error shown below. >=20 > On USB flash drives I created myself, the suggested gpart command solved = the > problem, but I can not do this with drives I was given by a vendor or sup= plier. >=20 > What is wrong? >=20 > Kind regards and thank you very much in advance, >=20 > O. Hartmann >=20 >=20 > On console, I get the report: >=20 > [...] > GEOM_PART: da4 was automatically resized. > Use `gpart commit da4` to save changes or `gpart undo da4` to revert th= em. I noticed something similar when I was trying to dd a more recent memstick installer to a USB drive on 12-CURRENT. When I plugged in the flash drive I couldn't dd to it until I noticed that message in syslog and ran 'gpart undo da0'. Looks like something is unhelpfully auto-resizing partitions. --enLffk0M6cffIOOh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXn4mTAAoJEGaweXjzNsmpsqgH/1ezU67opCeNUuQ4wGkrDxkR wQL0/zaR3F269EjnNprFObDgL1lVRX/sURJBo1amjl20S/h5mTwC4IqKC9kYdT10 zrZMy/tlZ23fqs/k14UXQtTyOAeByDMpSEAGRxy6ODZjj/sfWmQsvHBEcyJvFZzM Ml9yJF8KeH7Q08Jl1FDTggTkCe/89tmJ30VUyV+dJ1LhA+GfXuT2+kW120kLr3yA xzdlVtoLrzfG8AQWGvybyS2Vm2ucL6r28NwYkm05HSrH0gNALHDdaXVCWP14nYjd 3J6iOnjtUKIbBnyRenMOt7E+xZ+FFv6II6di3d7lRLwDC3LOBGpamxB3tHUpIJc= =okjD -----END PGP SIGNATURE----- --enLffk0M6cffIOOh-- From owner-freebsd-current@freebsd.org Mon Aug 1 18:23:47 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7A7D3BAB6A6; Mon, 1 Aug 2016 18:23:47 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5E0B81ECA; Mon, 1 Aug 2016 18:23:47 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id u71Ggjs5032137 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 1 Aug 2016 09:42:45 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id u71GgjRb032136; Mon, 1 Aug 2016 09:42:45 -0700 (PDT) (envelope-from sgk) Date: Mon, 1 Aug 2016 09:42:45 -0700 From: Steve Kargl To: Dimitry Andric Cc: FreeBSD Current , FreeBSD Hackers Subject: Re: BSD grep dumps core Message-ID: <20160801164245.GA31972@troutmask.apl.washington.edu> Reply-To: kargl@uw.edu References: <20160731153738.GA33643@troutmask.apl.washington.edu> <54B0B5B7-25CF-4B7D-9874-73D33481CC1C@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54B0B5B7-25CF-4B7D-9874-73D33481CC1C@FreeBSD.org> User-Agent: Mutt/1.6.1 (2016-04-27) X-Mailman-Approved-At: Mon, 01 Aug 2016 18:36:11 +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, 01 Aug 2016 18:23:47 -0000 On Mon, Aug 01, 2016 at 06:22:16PM +0200, Dimitry Andric wrote: > On 31 Jul 2016, at 17:37, Steve Kargl wrote: > > Script started on Sun Jul 31 08:30:56 2016 > > troutmask:sgk[200] cd gcc/gcc7 > > troutmask:sgk[201] svn status > > ? 7.diff > > ? decl.c.diff > > ? gcc/fortran/old > > ? gcc/fortran/pr38351.diff > > ? gcc/fortran/pr41922.diff > > ? gcc/fortran/pr69860.diff > > ? trans-decl.c.diff > > ? typescript > > ? z1.diff > > troutmask:sgk[202] svn status | grep -v -E ^\? > > Segmentation fault (core dumped) > > troutmask:sgk[203] svn status | grep -v -E ^"\?" > > troutmask:sgk[204] exit > > exit > > > > Script done on Sun Jul 31 08:31:54 2016 > > > > The core dump happens with both tcsh and sh. > > > > The following works as expected > > > > troutmask:sgk[202] svn status | gnugrep -v -E ^\? > > Yes, '^?' is an invalid extended regular expression, but GNU grep does > not complain about it, and simply discards the '?' character. Our BSD > grep dies because it also attempts to discard, but then some later logic > goes beyond the end of the buffer. > > Please try this fix: > > Index: usr.bin/grep/regex/tre-fastmatch.c > =================================================================== > --- usr.bin/grep/regex/tre-fastmatch.c (revision 303551) > +++ usr.bin/grep/regex/tre-fastmatch.c (working copy) > @@ -621,7 +621,7 @@ tre_compile_fast(fastmatch_t *fg, const tre_char_t > case TRE_CHAR('+'): > case TRE_CHAR('?'): > if ((cflags & REG_EXTENDED) && (i == 0)) > - continue; > + goto badpat; > else if ((cflags & REG_EXTENDED) ^ !escaped) > STORE_CHAR; > else > > After this, bsdgrep errors out with: > > % bsdgrep -E '^?' > bsdgrep: Invalid preceding regular expression > > which is much saner IMHO. > Dimitry, Thanks for the quick patch. Yes, the patch works as advertised. I agree that an error message is preferredi/saner than a segfault. -- Steve From owner-freebsd-current@freebsd.org Mon Aug 1 19:00: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 3DCE1BAB398 for ; Mon, 1 Aug 2016 19:00:25 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mx1.shrew.net (mx1.shrew.net [38.97.5.131]) (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 14D571827 for ; Mon, 1 Aug 2016 19:00:24 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx1.shrew.net (8.14.7/8.14.7) with ESMTP id u71Ipv3Z049721 for ; Mon, 1 Aug 2016 13:51:57 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.16.32.30] (unknown [172.126.77.65]) by mail.shrew.net (Postfix) with ESMTPSA id 781CA18D019 for ; Mon, 1 Aug 2016 13:51:52 -0500 (CDT) Subject: Re: CURRENT: [USB] : GEOM_PART: da4 was automatically resized. To: freebsd-current@freebsd.org References: <20160801110554.289d040d@freyja.zeit4.iv.bundesimmobilien.de> <20160801174035.GI74453@gmail.com> From: Matthew Grooms Message-ID: <0b4f142a-7c44-832d-5fe2-c2a6264383cc@shrew.net> Date: Mon, 1 Aug 2016 13:55:13 -0500 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: <20160801174035.GI74453@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx1.shrew.net [10.24.10.10]); Mon, 01 Aug 2016 13:51:57 -0500 (CDT) 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, 01 Aug 2016 19:00:25 -0000 On 8/1/2016 12:40 PM, Randy Westlund wrote: > On Mon, Aug 01, 2016 at 11:05:54AM +0200, O. Hartmann wrote: >> On every(!) USB drive which worked well with 11-CURRENT up to 11-BETA, I fail >> to access with 12-CURRENT (12.0-CURRENT FreeBSD 12.0-CURRENT #14 r303475: Fri >> Jul 29 11:59:11 CEST 2016) with the error shown below. >> >> On USB flash drives I created myself, the suggested gpart command solved the >> problem, but I can not do this with drives I was given by a vendor or supplier. >> >> What is wrong? >> >> Kind regards and thank you very much in advance, >> >> O. Hartmann >> >> >> On console, I get the report: >> >> [...] >> GEOM_PART: da4 was automatically resized. >> Use `gpart commit da4` to save changes or `gpart undo da4` to revert them. > > I noticed something similar when I was trying to dd a more recent > memstick installer to a USB drive on 12-CURRENT. When I plugged in the > flash drive I couldn't dd to it until I noticed that message in syslog > and ran 'gpart undo da0'. Looks like something is unhelpfully > auto-resizing partitions. > Do you have growfs_enable in your rc.conf file? I think this is added to certain flash images by default so it will automatically grow to your device capacity. See ... /etc/rc.d/growfs ... and ... https://lists.freebsd.org/pipermail/freebsd-rc/2014-May/003497.html -Matthew From owner-freebsd-current@freebsd.org Mon Aug 1 19:16:05 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 276B5BAB8FB; Mon, 1 Aug 2016 19:16:05 +0000 (UTC) (envelope-from mandree@freebsd.org) Received: from unimail.uni-dortmund.de (mx1.HRZ.tu-dortmund.de [129.217.128.51]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "unimail.tu-dortmund.de", Issuer "TU Dortmund CA - G01" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8EECF11BB; Mon, 1 Aug 2016 19:16:03 +0000 (UTC) (envelope-from mandree@freebsd.org) Received: from [192.168.1.27] ([88.117.234.38]) (authenticated bits=0) by unimail.uni-dortmund.de (8.16.0.16/8.16.0.16) with ESMTPSA id u71EQdqp015457 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Aug 2016 16:26:40 +0200 (CEST) User-Agent: K-9 Mail for Android In-Reply-To: <20160801140804.GD7956@mutt-hardenedbsd> References: <20160801140804.GD7956@mutt-hardenedbsd> MIME-Version: 1.0 Subject: Re: security/openvpn build failure on 12-CURRENT/amd64 From: Matthias Andree Date: Mon, 01 Aug 2016 14:26:39 +0000 To: Shawn Webb , freebsd-current@freebsd.org CC: freebsd-ports@freebsd.org Message-ID: <2061B016-057C-44E9-A982-C0B689861E40@freebsd.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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, 01 Aug 2016 19:16:05 -0000 Hi Shawn, The compilation attempt was done on an invalid configuration and has zero relevance whatsoever. As the log says: !!! Jail is newer than host. (Jail: 1200001, Host: 1100116) !!! !!! This is not supported. !!! !!! Host kernel must be same or newer than jail. !!! !!! Expect build failures. !!! I wish the builders would stop even trying to build a package on a kernel that is too old, it's just confusing and wasteful. Am 1. August 2016 16:08:04 MESZ, schrieb Shawn Webb : >Hey All, > >It looks like security/openvpn fails to build on 12-CURRENT/amd64 on >both FreeBSD's and HardenedBSD's build infrastructure. I've verified >that it builds fine on latest 11-STABLE/amd64. Would this be a >regression in 12-CURRENT? > >Log file from FreeBSD's build: >http://beefy4.nyi.freebsd.org/data/head-amd64-default/p419204_s303419/logs/errors/openvpn-2.3.11.log > >Thanks, > >-- >Shawn Webb >Cofounder and Security Engineer >HardenedBSD > >GPG Key ID: 0x6A84658F52456EEE >GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE From owner-freebsd-current@freebsd.org Mon Aug 1 19:31: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 5E8BEBABFC2 for ; Mon, 1 Aug 2016 19:31:45 +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 3F4BE1D06 for ; Mon, 1 Aug 2016 19:31:45 +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 56AB7B990; Mon, 1 Aug 2016 15:31:44 -0400 (EDT) From: John Baldwin To: Mateusz Guzik Cc: Konstantin Belousov , freebsd-current@freebsd.org Subject: Re: [PATCH] randomized delay in locking primitives, take 2 Date: Mon, 01 Aug 2016 11:37:50 -0700 Message-ID: <15005477.9uZ5EJCdhW@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.3-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20160731124113.GE9408@dft-labs.eu> References: <20160731095706.GB9408@dft-labs.eu> <20160731104928.GW83214@kib.kiev.ua> <20160731124113.GE9408@dft-labs.eu> 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, 01 Aug 2016 15:31:44 -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, 01 Aug 2016 19:31:45 -0000 On Sunday, July 31, 2016 02:41:13 PM Mateusz Guzik wrote: > On Sun, Jul 31, 2016 at 01:49:28PM +0300, Konstantin Belousov wrote: > [snip] > > After an irc discussion, the following was produced (also available at: > https://people.freebsd.org/~mjg/lock_backoff_complete4.diff): > > Differences: > - uint64_t usage was converted to u_int (also see r303584) > - currently unused features (cap limit and return value) were removed > - lock_delay args got packed into a dedicated structure lock_delay_enabled declaration seems to be stale? I would maybe just provide a "standard" lock_delay_init function that the sysinit's use rather than duplicating the same exact code 3 times. I'm not sure we really want to use different tunables for different lock types anyway. (Alternatively we could even just have a single 'config' variable that is a global. We can always revisit this in the future if we find that we need that granularity, but it would remove an extra pointer indirection if you just had a single 'lock_delay_config' that was exported as a global for now and initialized in a single SYSINIT.) I think the idea is fine. I'm less worried about the overhead of the divide as you are only doing it when you are contesting (so you are already sort of hosed anyway). Long delays in checking the lock cookie can be bad (see my local APIC snafu which only polled once per microsecond). I don't really think a divide is going to be that long? -- John Baldwin From owner-freebsd-current@freebsd.org Mon Aug 1 19:37: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 228F9BAB431 for ; Mon, 1 Aug 2016 19:37:59 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 07AC317A6 for ; Mon, 1 Aug 2016 19:37:58 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 77e5f87f-581f-11e6-8929-8ded99d5e9d7 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Mon, 1 Aug 2016 19:38:05 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u71JaoEs034534; Mon, 1 Aug 2016 13:36:50 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1470080210.1283.36.camel@freebsd.org> Subject: Re: CURRENT: [USB] : GEOM_PART: da4 was automatically resized. From: Ian Lepore To: Matthew Grooms , freebsd-current@freebsd.org Date: Mon, 01 Aug 2016 13:36:50 -0600 In-Reply-To: <0b4f142a-7c44-832d-5fe2-c2a6264383cc@shrew.net> References: <20160801110554.289d040d@freyja.zeit4.iv.bundesimmobilien.de> <20160801174035.GI74453@gmail.com> <0b4f142a-7c44-832d-5fe2-c2a6264383cc@shrew.net> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 01 Aug 2016 19:37:59 -0000 On Mon, 2016-08-01 at 13:55 -0500, Matthew Grooms wrote: > On 8/1/2016 12:40 PM, Randy Westlund wrote: > > On Mon, Aug 01, 2016 at 11:05:54AM +0200, O. Hartmann wrote: > > > On every(!) USB drive which worked well with 11-CURRENT up to 11 > > > -BETA, I fail > > > to access with 12-CURRENT (12.0-CURRENT FreeBSD 12.0-CURRENT #14 > > > r303475: Fri > > > Jul 29 11:59:11 CEST 2016) with the error shown below. > > > > > > On USB flash drives I created myself, the suggested gpart command > > > solved the > > > problem, but I can not do this with drives I was given by a > > > vendor or supplier. > > > > > > What is wrong? > > > > > > Kind regards and thank you very much in advance, > > > > > > O. Hartmann > > > > > > > > > On console, I get the report: > > > > > > [...] > > > GEOM_PART: da4 was automatically resized. > > > Use `gpart commit da4` to save changes or `gpart undo da4` to > > > revert them. > > > > I noticed something similar when I was trying to dd a more recent > > memstick installer to a USB drive on 12-CURRENT. When I plugged in > > the > > flash drive I couldn't dd to it until I noticed that message in > > syslog > > and ran 'gpart undo da0'. Looks like something is unhelpfully > > auto-resizing partitions. > > > > Do you have growfs_enable in your rc.conf file? I think this is added > to > certain flash images by default so it will automatically grow to your > device capacity. See ... > > /etc/rc.d/growfs > > ... and ... > > https://lists.freebsd.org/pipermail/freebsd-rc/2014-May/003497.html > > -Matthew I think rather than being related to growfs, this is fallout from r303019 [*] which automatically resizes the device geom based on what the device reports. I suspect the intent was to make gpt backup partition data appear at the right place on the device even when the original image is created on a device of a different size. Unfortunately, leaving an uncommited geom change lurking in the system is going to lead to a fair amount of confusion, since it makes other attempts to work with the device fail, usually with no clue about why it's failing. Uncommitted geom changes are a bit like an invisible time bomb in your system; it wouldn't be so bad if they weren't so invisible, and weren't so hard to figure out how to properly get out of the situation. Something like a "gpart undo -r " to recursively undo all uncommitted changes would go a long way towards fixing the "what to do" part. I'm not sure how to make pending changes more visible. Maybe it would work to have gpart show flag uncommitted changes somehow. * https://svnweb.freebsd.org/base/head/sys/geom/geom_disk.c?view=log -- Ian From owner-freebsd-current@freebsd.org Mon Aug 1 19:47:14 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 55B12BAB825 for ; Mon, 1 Aug 2016 19:47:14 +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 16CA51D3E for ; Mon, 1 Aug 2016 19:47:13 +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 <1bUJB9-000rzo-0i>; Mon, 01 Aug 2016 21:47:11 +0200 Received: from x5ce12f66.dyn.telefonica.de ([92.225.47.102] 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 <1bUJB8-0023C8-Or>; Mon, 01 Aug 2016 21:47:10 +0200 Date: Mon, 1 Aug 2016 21:48:07 +0200 From: "O. Hartmann" To: Matthew Grooms Cc: freebsd-current@freebsd.org Subject: Re: CURRENT: [USB] : GEOM_PART: da4 was automatically resized. Message-ID: <20160801214807.332baebf.ohartman@zedat.fu-berlin.de> In-Reply-To: <0b4f142a-7c44-832d-5fe2-c2a6264383cc@shrew.net> References: <20160801110554.289d040d@freyja.zeit4.iv.bundesimmobilien.de> <20160801174035.GI74453@gmail.com> <0b4f142a-7c44-832d-5fe2-c2a6264383cc@shrew.net> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/bRiTF5.u2RgqxY0u5Kn3oG."; protocol="application/pgp-signature" X-Originating-IP: 92.225.47.102 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: Mon, 01 Aug 2016 19:47:14 -0000 --Sig_/bRiTF5.u2RgqxY0u5Kn3oG. Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Mon, 1 Aug 2016 13:55:13 -0500 Matthew Grooms schrieb: > On 8/1/2016 12:40 PM, Randy Westlund wrote: > > On Mon, Aug 01, 2016 at 11:05:54AM +0200, O. Hartmann wrote: =20 > >> On every(!) USB drive which worked well with 11-CURRENT up to 11-BETA,= I fail > >> to access with 12-CURRENT (12.0-CURRENT FreeBSD 12.0-CURRENT #14 r3034= 75: Fri > >> Jul 29 11:59:11 CEST 2016) with the error shown below. > >> > >> On USB flash drives I created myself, the suggested gpart command solv= ed the > >> problem, but I can not do this with drives I was given by a vendor or = supplier. > >> > >> What is wrong? > >> > >> Kind regards and thank you very much in advance, > >> > >> O. Hartmann > >> > >> > >> On console, I get the report: > >> > >> [...] > >> GEOM_PART: da4 was automatically resized. > >> Use `gpart commit da4` to save changes or `gpart undo da4` to revert= them. =20 > > > > I noticed something similar when I was trying to dd a more recent > > memstick installer to a USB drive on 12-CURRENT. When I plugged in the > > flash drive I couldn't dd to it until I noticed that message in syslog > > and ran 'gpart undo da0'. Looks like something is unhelpfully > > auto-resizing partitions. > > =20 >=20 > Do you have growfs_enable in your rc.conf file? I think this is added to= =20 > certain flash images by default so it will automatically grow to your=20 > device capacity. See ... >=20 > /etc/rc.d/growfs >=20 > ... and ... >=20 > https://lists.freebsd.org/pipermail/freebsd-rc/2014-May/003497.html No, I do not. This weird dmesg output occured immediately after the 12-CURR= ENT branch was created - somehow. 11-ALPHA3 doesn't show up this problem. I haven't tested= ALPHA6 or the most recent BETA. The nasty thing is that I can't write to the USB flash drive in some cases = - although this worked flawless before. I did not change anything in the config (rc.conf[.XXX]). The problem occure= d with one of the patchesets placed via svn in the strain of moving to 12-CURRENT. And it occurs an ALL CURRENT systems I run. Oliver --Sig_/bRiTF5.u2RgqxY0u5Kn3oG. Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXn6d3AAoJEOgBcD7A/5N8goEIAIvVPeYkG+dzUY3/Xq0pEfnM GorQZlKV2ZQnMvHAItrtzOF5r4uJQeMvDuYavjwuDQYZIYrBGZEBue1g0ZifG6gs F0e6prjop6PLOhX8X7J1LdFLP+qPAcYIgNLb93md9IrcvP5PQGoanxgblywbeOAS WsFjVumntNBM+SNrv8fWowHVkVXEzzx84SI9Bf1dlf5bU/JsYQOt/7wUCVjWlNwe VqHsTjmr4fwYKcSgjrqYLx/II9/BUv84al/bvGY14aidnaUTqaNzG92slrzlBxgX HE9i1CQRZ7o8QpFEPWxxsEpUC/edO+E/hBCPoUNbMhRyl8+L1X+IV5n3EGe3tIA= =NhMk -----END PGP SIGNATURE----- --Sig_/bRiTF5.u2RgqxY0u5Kn3oG.-- From owner-freebsd-current@freebsd.org Mon Aug 1 19:52: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 5BA36BABA54 for ; Mon, 1 Aug 2016 19:52:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 23F2D17DE for ; Mon, 1 Aug 2016 19:52:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x236.google.com with SMTP id b62so192999012iod.3 for ; Mon, 01 Aug 2016 12:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=hHftmhshxhis8hl7TkZAoQtcsBf0mf8uzs4Ea1qKk7w=; b=nOBAbm1IiFzV1k4pw+2WXi88nQE72IXlbd/Vd5LMi4auK0ttjHZIsKBwFCMn8UESlD Uhh23d/TuOumAlP1KW81ShXfsaMu/UOIAq3bBu31INS53jDTEGUDIY9QyET1jVb4xKTt j8cQdv6ZHjlIktdcV6FbhZWP9fG2xxSkSpi6o6v1hcEO7aHF2arkpyLUW19Zl6crC08b +SVzONo0pUnEc9l3rSkgh/x5QljV+1KXPCF/WviiyMAvfz66xVChTT0mT4Uawg5ipJ+d +i6btUEXIkHuFNcgTIa7ELO7Sm/5drf8teeIrVkPtTpO16y9O4pSORDlhRKayoyiCEpb C35w== 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=hHftmhshxhis8hl7TkZAoQtcsBf0mf8uzs4Ea1qKk7w=; b=aLsiuUz+OgtX5BMI3nFmQ3XDITJ8QZfHR+5lc26SeGknwvSwyZZ+CavBFx2yM4zb+m IivJ7pjEYFamhJ6u0cequJ+6kVw0uF6/4P2qpoN5fmRzT0fy9WLpJmcdhzmSimehBp5w 6XBWWbDAmaz+iMJEOHvE38QnNW2JcLOn+Ru5a+qK4tj+rHSahkEYwNtuO6tn8iBz71kz dMSKfx5WraunnonmzV3dEFghJB6ACSvmGihWHTX95dZjJtm4cmr14Q/FLgqVhKNeGT9g duOR/G/AGufNsqUE9gnex0ALgOdh7ACINwe2X7qFUdzZFFFVDzU09I2wSr8qwTaaxx8X UeHA== X-Gm-Message-State: AEkooutPiuJcqJ4I8SGy8haXGUN8xNgZtFYGSvENsMoIg+3gE07fMr0XaqDV1awzUnPjjjCy5P1XgAKGBsIYDg== X-Received: by 10.107.167.206 with SMTP id q197mr58855313ioe.197.1470081126422; Mon, 01 Aug 2016 12:52:06 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.137.131 with HTTP; Mon, 1 Aug 2016 12:52:05 -0700 (PDT) X-Originating-IP: [69.53.245.200] In-Reply-To: <1470080210.1283.36.camel@freebsd.org> References: <20160801110554.289d040d@freyja.zeit4.iv.bundesimmobilien.de> <20160801174035.GI74453@gmail.com> <0b4f142a-7c44-832d-5fe2-c2a6264383cc@shrew.net> <1470080210.1283.36.camel@freebsd.org> From: Warner Losh Date: Mon, 1 Aug 2016 13:52:05 -0600 X-Google-Sender-Auth: OGRHZBtIYOnbS3d547RSHIAVDZ4 Message-ID: Subject: Re: CURRENT: [USB] : GEOM_PART: da4 was automatically resized. To: Ian Lepore , "Andrey V. Elsukov" Cc: Matthew Grooms , 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, 01 Aug 2016 19:52:07 -0000 On Mon, Aug 1, 2016 at 1:36 PM, Ian Lepore wrote: > On Mon, 2016-08-01 at 13:55 -0500, Matthew Grooms wrote: >> On 8/1/2016 12:40 PM, Randy Westlund wrote: >> > On Mon, Aug 01, 2016 at 11:05:54AM +0200, O. Hartmann wrote: >> > > On every(!) USB drive which worked well with 11-CURRENT up to 11 >> > > -BETA, I fail >> > > to access with 12-CURRENT (12.0-CURRENT FreeBSD 12.0-CURRENT #14 >> > > r303475: Fri >> > > Jul 29 11:59:11 CEST 2016) with the error shown below. >> > > >> > > On USB flash drives I created myself, the suggested gpart command >> > > solved the >> > > problem, but I can not do this with drives I was given by a >> > > vendor or supplier. >> > > >> > > What is wrong? >> > > >> > > Kind regards and thank you very much in advance, >> > > >> > > O. Hartmann >> > > >> > > >> > > On console, I get the report: >> > > >> > > [...] >> > > GEOM_PART: da4 was automatically resized. >> > > Use `gpart commit da4` to save changes or `gpart undo da4` to >> > > revert them. >> > >> > I noticed something similar when I was trying to dd a more recent >> > memstick installer to a USB drive on 12-CURRENT. When I plugged in >> > the >> > flash drive I couldn't dd to it until I noticed that message in >> > syslog >> > and ran 'gpart undo da0'. Looks like something is unhelpfully >> > auto-resizing partitions. >> > >> >> Do you have growfs_enable in your rc.conf file? I think this is added >> to >> certain flash images by default so it will automatically grow to your >> device capacity. See ... >> >> /etc/rc.d/growfs >> >> ... and ... >> >> https://lists.freebsd.org/pipermail/freebsd-rc/2014-May/003497.html >> >> -Matthew > > I think rather than being related to growfs, this is fallout from > r303019 [*] which automatically resizes the device geom based on what > the device reports. I suspect the intent was to make gpt backup > partition data appear at the right place on the device even when the > original image is created on a device of a different size. > > Unfortunately, leaving an uncommited geom change lurking in the system > is going to lead to a fair amount of confusion, since it makes other > attempts to work with the device fail, usually with no clue about why > it's failing. Uncommitted geom changes are a bit like an invisible > time bomb in your system; it wouldn't be so bad if they weren't so > invisible, and weren't so hard to figure out how to properly get out of > the situation. > > Something like a "gpart undo -r " to recursively undo all > uncommitted changes would go a long way towards fixing the "what to do" > part. I'm not sure how to make pending changes more visible. Maybe it > would work to have gpart show flag uncommitted changes somehow. > > * https://svnweb.freebsd.org/base/head/sys/geom/geom_disk.c?view=log Yea, this change "looks" ok, but if it has this side effect it should be backed out ASAP. I've CC'd Andrey for comment. I can't imagine that this was his intent with the change, since the commit log makes no mention of it and I'm having trouble understanding the justification for the 'pend change' bit... Warner From owner-freebsd-current@freebsd.org Mon Aug 1 20:08: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 4A9B0BAA1AB for ; Mon, 1 Aug 2016 20:08:49 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D141C160A; Mon, 1 Aug 2016 20:08:48 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-wm0-x241.google.com with SMTP id x83so27651099wma.3; Mon, 01 Aug 2016 13:08:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=/CNRVVYSM8FHt3YsnHme0b0vk1VNCE8uoo9m5mllkt8=; b=HugIoeJ7/3KaPGqaEAVHte+uZ7iDL8nfqFgZubdCrO/MObaFTVrR/363zLZuUphdO0 07NnI0DOgmZL1Rd4lE6TPYbUulLxhXzVjzCgXwXyXTn31BFsFoRYd4cQLoexHakBTX5e GZOec4RUXfQf+2hXrHGAIdClIUUmyaxXl4ObmdGIhjZtIhsS70x3/RNWtH8ozmsEZNmQ B55KbiVYRX4BtlHFeShPuppcfNdGgTGzQm6++H6+aOndZ0hqQCjwyJ4zAgeDYIdPRi3Z iAcvRwYT2dJD+BX3264+TuR4Fjt8jez3sfReVyMmk9ADW/sCBz1NNCHE2OnqmhmAc2Mt HSrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=/CNRVVYSM8FHt3YsnHme0b0vk1VNCE8uoo9m5mllkt8=; b=e+dMxN2PW0QHtw6ramAcIupgNNT9tFD61aBR/BAFXHNBLdSgJTr73f5ovGdVzIj0Eo Xahf5ZV5112hkbsJ7QpZe0QRX2cpD4LlPHuu2WeRfB8r2qpzEgj4tMhTKXxX1vvpGm8S Alby4d8KRvHpHpaeOyS25dyUGF7qLjxBjFWcSHFsAaz5dQGY8IO/rXPqvDcGi1aWUYd2 eo0jYcLnWFa2PU27bUzR0+Q2lzsHF4wOEH4duJwRTs1ABPJFXKhcgLw7TJckeZ78eDsN rxNCaOv+cw4pTrdukq2L7p+AvResMs1iHA2FjqjhvhXX5ePWkbfCe3B/odCSX9xKX+Yx jCYQ== X-Gm-Message-State: AEkoouvZFKflvbgyUhfF5VLP7/mouLMqitVwHFCzWpFEr83OHAubiWCUoHSPHcmikF1zew== X-Received: by 10.194.48.39 with SMTP id i7mr58192906wjn.173.1470082126483; Mon, 01 Aug 2016 13:08:46 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by smtp.gmail.com with ESMTPSA id r127sm18537632wmf.23.2016.08.01.13.08.44 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Mon, 01 Aug 2016 13:08:45 -0700 (PDT) Date: Mon, 1 Aug 2016 22:08:43 +0200 From: Mateusz Guzik To: John Baldwin Cc: Konstantin Belousov , freebsd-current@freebsd.org Subject: Re: [PATCH] randomized delay in locking primitives, take 2 Message-ID: <20160801200842.GC24633@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , John Baldwin , Konstantin Belousov , freebsd-current@freebsd.org References: <20160731095706.GB9408@dft-labs.eu> <20160731104928.GW83214@kib.kiev.ua> <20160731124113.GE9408@dft-labs.eu> <15005477.9uZ5EJCdhW@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <15005477.9uZ5EJCdhW@ralph.baldwin.cx> User-Agent: Mutt/1.5.21 (2010-09-15) 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, 01 Aug 2016 20:08:49 -0000 On Mon, Aug 01, 2016 at 11:37:50AM -0700, John Baldwin wrote: > On Sunday, July 31, 2016 02:41:13 PM Mateusz Guzik wrote: > > On Sun, Jul 31, 2016 at 01:49:28PM +0300, Konstantin Belousov wrote: > > [snip] > > > > After an irc discussion, the following was produced (also available at: > > https://people.freebsd.org/~mjg/lock_backoff_complete4.diff): > > > > Differences: > > - uint64_t usage was converted to u_int (also see r303584) > > - currently unused features (cap limit and return value) were removed > > - lock_delay args got packed into a dedicated structure > > lock_delay_enabled declaration seems to be stale? > Oops, thanks. > I would maybe just provide a "standard" lock_delay_init function that the > sysinit's use rather than duplicating the same exact code 3 times. I'm > not sure we really want to use different tunables for different lock types > anyway. (Alternatively we could even just have a single 'config' variable > that is a global. We can always revisit this in the future if we find that > we need that granularity, but it would remove an extra pointer indirection > if you just had a single 'lock_delay_config' that was exported as a global > for now and initialized in a single SYSINIT.) > The per-lock type config is partially an artifact of the real version of the patch which has different configs per state of the lock, see loops with rowner_loops in the current implementation of rw and sx locks and this is were it mattered. It was cut off from this patch for simplicity (90% of the benefit for 10% of the work). That said, fine tuned it does matter for "mere" spinning as well but here I put very low values on purpose. Putting them all in one config makes for a small compatibility issue, where debug.lock.delay_* sysctls would disappear later. So I would prefer to just keep this as I don't think it matters much. I have further optimisation to primitives not related to spinning. They boil down to the fact that KDTRACE_HOOKS-enabled kernels contain an unconditional function call to lockstat_nsecs even with the lock held. > I think the idea is fine. I'm less worried about the overhead of the > divide as you are only doing it when you are contesting (so you are already > sort of hosed anyway). Long delays in checking the lock cookie can be > bad (see my local APIC snafu which only polled once per microsecond). I > don't really think a divide is going to be that long? > This should be perfectly fine. One could argue the time wasted should be wasted efficiently, i.e. the more cpu_spinwait, the better, at least on amd64. -- Mateusz Guzik From owner-freebsd-current@freebsd.org Mon Aug 1 20:16:13 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BE2C8BAA721 for ; Mon, 1 Aug 2016 20:16:13 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c: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 532801D0C; Mon, 1 Aug 2016 20:16:13 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: by mail-wm0-x230.google.com with SMTP id o80so260330084wme.1; Mon, 01 Aug 2016 13:16:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WU1C5wBw3t0g5X3fBDhiFKFoeoiwFNkEhKHn2coh6XA=; b=pY80TFia9xd7YiVwrJDBL0MEijBE/Vl1qz84w81qbVh8qNvJW1DEI2yQ4VstiZ0YTO 0b/4pdENinBWuS2iTzz96qU3aHMcnBSoiC4mwFBzhTYWlRxvUcQhgcYfpxAdgv1z4fAK uow8JAtPDN8TrMBQIDzdmSttMP7ZYk2JisnJb5g4D3oNWmeaUXhgS2kXWiPLvlO5AKzq XRmz6+XoyKQ10DJZu9U6SxFpnIco49rV4JWaijdlAm/IDU6RVmsTMvUxlE6U6MaQd4Xn B0G0oscZhQeerrwfX13GY94R4YRnamzbu041K7sej70pEzyLOXy4KMTEFM594RfKyt+0 wTxw== 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=WU1C5wBw3t0g5X3fBDhiFKFoeoiwFNkEhKHn2coh6XA=; b=CdzBldCkBFK2R5IC2SzJjB+j0E8xr0TK5YVB6QWDakYiYRyeVnjAz7FkDe2nm5L7X/ AfRak+Clta/o3xmDccZMH9LG9bzZoZUnb5/V37UwgTvQNMJ/btmVRD1M6r9L/H8oWPzK 15/L6+AmBFZo/3g41+2dz/iQe0n0VdfA/oBk20ekSrMLXOEAB7HEgHSsacar9yAuCdGv IQ/tVONgxmpW0Dk0Z6Ht+VN8vGka+0W8Gl7S1jO5aaIYvUfcOqsYBtH5jcN888DrvAex nLQvGdh78lercyBdpZaB3Yv3ddr8GAs6RpzyU00hWmwHXlf2q0rv9Xb54NY6au3D+7C8 uxYg== X-Gm-Message-State: AEkoouvuwRUxxLQ67xEB38WRdZAMPErhP+/p6sYBuP72Y0O58MvHsX3wyfkxuEEWLw5ZbJINFJz0UCp4dQrIyQ== X-Received: by 10.28.238.154 with SMTP id j26mr16596116wmi.94.1470082571411; Mon, 01 Aug 2016 13:16:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.19.203 with HTTP; Mon, 1 Aug 2016 13:16:10 -0700 (PDT) In-Reply-To: References: <20160731023550.GF1532@FreeBSD.org> From: Guy Yur Date: Mon, 1 Aug 2016 23:16:10 +0300 Message-ID: Subject: Re: resolvconf needs @RESTARTCMD@ to be replaced after r303062 To: Pedro Giffuni Cc: Glen Barber , 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, 01 Aug 2016 20:16:13 -0000 On Sun, Jul 31, 2016 at 9:09 PM, Pedro Giffuni wrote: > > > On 07/31/16 11:56, Guy Yur wrote: >> >> Hi, >> >> I meant for the RESTARTCMD_= statement to be added too. >> I should have sent a patch file. >> > > Ugh ... yeah I am really bad at "guessing" patches. > > I will play with your patch. Thanks. > > Pedro. Thanks. fix for pdns_recursor was applied upstream. http://roy.marples.name/projects/openresolv/info/4bb3467d4ac799f2 When a new openresolv release is made it will be possible to drop the _WITH_ARG vars. Guy. From owner-freebsd-current@freebsd.org Mon Aug 1 20:21:48 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 57526BAAB45 for ; Mon, 1 Aug 2016 20:21:48 +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 37B921619 for ; Mon, 1 Aug 2016 20:21:48 +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 2764DB97D; Mon, 1 Aug 2016 16:21:47 -0400 (EDT) From: John Baldwin To: Mateusz Guzik Cc: Konstantin Belousov , freebsd-current@freebsd.org Subject: Re: [PATCH] randomized delay in locking primitives, take 2 Date: Mon, 01 Aug 2016 13:21:44 -0700 Message-ID: <3455593.kNdxUc5UIq@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.3-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20160801200842.GC24633@dft-labs.eu> References: <20160731095706.GB9408@dft-labs.eu> <15005477.9uZ5EJCdhW@ralph.baldwin.cx> <20160801200842.GC24633@dft-labs.eu> 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, 01 Aug 2016 16:21:47 -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, 01 Aug 2016 20:21:48 -0000 On Monday, August 01, 2016 10:08:43 PM Mateusz Guzik wrote: > On Mon, Aug 01, 2016 at 11:37:50AM -0700, John Baldwin wrote: > > On Sunday, July 31, 2016 02:41:13 PM Mateusz Guzik wrote: > > > On Sun, Jul 31, 2016 at 01:49:28PM +0300, Konstantin Belousov wrote: > > > [snip] > > > > > > After an irc discussion, the following was produced (also available at: > > > https://people.freebsd.org/~mjg/lock_backoff_complete4.diff): > > > > > > Differences: > > > - uint64_t usage was converted to u_int (also see r303584) > > > - currently unused features (cap limit and return value) were removed > > > - lock_delay args got packed into a dedicated structure > > > > lock_delay_enabled declaration seems to be stale? > > > > Oops, thanks. > > > I would maybe just provide a "standard" lock_delay_init function that the > > sysinit's use rather than duplicating the same exact code 3 times. I'm > > not sure we really want to use different tunables for different lock types > > anyway. (Alternatively we could even just have a single 'config' variable > > that is a global. We can always revisit this in the future if we find that > > we need that granularity, but it would remove an extra pointer indirection > > if you just had a single 'lock_delay_config' that was exported as a global > > for now and initialized in a single SYSINIT.) > > > > The per-lock type config is partially an artifact of the real version of > the patch which has different configs per state of the lock, see loops > with rowner_loops in the current implementation of rw and sx locks and > this is were it mattered. It was cut off from this patch for simplicity > (90% of the benefit for 10% of the work). > > That said, fine tuned it does matter for "mere" spinning as well but > here I put very low values on purpose. > > Putting them all in one config makes for a small compatibility issue, > where debug.lock.delay_* sysctls would disappear later. > > So I would prefer to just keep this as I don't think it matters much. Ok. This is also something we can change later if need to. It doesn't affect the ABI, etc. -- John Baldwin From owner-freebsd-current@freebsd.org Mon Aug 1 20:21: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 BF470BAAB50 for ; Mon, 1 Aug 2016 20:21:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id AC8C01622 for ; Mon, 1 Aug 2016 20:21:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id ABE3BBAAB4F; Mon, 1 Aug 2016 20:21:49 +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 AB8BABAAB4E for ; Mon, 1 Aug 2016 20:21:49 +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 86A931621 for ; Mon, 1 Aug 2016 20:21:49 +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 9DDD8B923; Mon, 1 Aug 2016 16:21:48 -0400 (EDT) From: John Baldwin To: gljennjohn@gmail.com Cc: current@freebsd.org Subject: Re: EARLY_AP_STARTUP hangs during boot Date: Mon, 01 Aug 2016 13:19:16 -0700 Message-ID: <9937686.eTkQvkYRyu@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.3-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20160801153111.5e59d3ce@ernst.home> References: <20160516122242.39249a54@ernst.home> <20160801093434.410032f4@ernst.home> <20160801153111.5e59d3ce@ernst.home> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 01 Aug 2016 16:21:48 -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, 01 Aug 2016 20:21:49 -0000 On Monday, August 01, 2016 03:31:11 PM Gary Jennejohn wrote: > On Mon, 1 Aug 2016 09:34:34 +0200 > Gary Jennejohn wrote: > > > On Sun, 31 Jul 2016 14:22:35 -0700 > > John Baldwin wrote: > > > > > On Sunday, July 31, 2016 11:29:14 AM Gary Jennejohn wrote: > > > > On Sat, 30 Jul 2016 12:03:59 -0700 > > > > John Baldwin wrote: > > > > > > > > > On Saturday, July 30, 2016 09:44:22 AM Gary Jennejohn wrote: > > > > > > On Fri, 29 Jul 2016 13:17:42 -0700 > > > > > > John Baldwin wrote: > > > > > > > > > > > > > On Thursday, July 28, 2016 12:31:31 AM Gary Jennejohn wrote: > > > > > > > > Well, now I know that ULE is a prerequiste for EARLY_AP_STARTUP! I > > > > > > > > wasn't aware of that. I prefer BSD and that's the scheduler I did > > > > > > > > the first tests with. > > > > > > > > > > > > > > > > But with the ULE scheduler the system comes up all the way. > > > > > > > > > > > > > > > > It would be nice if the BSD scheduler could also be modified to > > > > > > > > work with EARLY_AP_STARTUP. > > > > > > > > > > > > > > I wasn't able to reproduce your hang with 4BSD, but I think I see a > > > > > > > possible problem. Try this: > > > > > > > > > > > > > > diff --git a/sys/kern/sched_4bsd.c b/sys/kern/sched_4bsd.c > > > > > > > index 7de56b6..d53331a 100644 > > > > > > > --- a/sys/kern/sched_4bsd.c > > > > > > > +++ b/sys/kern/sched_4bsd.c > > > > > > > @@ -327,7 +327,6 @@ maybe_preempt(struct thread *td) > > > > > > > * - The current thread has a higher (numerically lower) or > > > > > > > * equivalent priority. Note that this prevents curthread from > > > > > > > * trying to preempt to itself. > > > > > > > - * - It is too early in the boot for context switches (cold is set). > > > > > > > * - The current thread has an inhibitor set or is in the process of > > > > > > > * exiting. In this case, the current thread is about to switch > > > > > > > * out anyways, so there's no point in preempting. If we did, > > > > > > > @@ -348,7 +347,7 @@ maybe_preempt(struct thread *td) > > > > > > > ("maybe_preempt: trying to run inhibited thread")); > > > > > > > pri = td->td_priority; > > > > > > > cpri = ctd->td_priority; > > > > > > > - if (panicstr != NULL || pri >= cpri || cold /* || dumping */ || > > > > > > > + if (panicstr != NULL || pri >= cpri /* || dumping */ || > > > > > > > TD_IS_INHIBITED(ctd)) > > > > > > > return (0); > > > > > > > #ifndef FULL_PREEMPTION > > > > > > > @@ -1127,7 +1126,7 @@ forward_wakeup(int cpunum) > > > > > > > if ((!forward_wakeup_enabled) || > > > > > > > (forward_wakeup_use_mask == 0 && forward_wakeup_use_loop == 0)) > > > > > > > return (0); > > > > > > > - if (!smp_started || cold || panicstr) > > > > > > > + if (!smp_started || panicstr) > > > > > > > return (0); > > > > > > > > > > > > > > forward_wakeups_requested++; > > > > > > > > > > > > > > > > > > > Thanks, but with this patch the kernel hangs in exactly the same > > > > > > place as before - after the HPET output. > > > > > > > > > > > > Maybe I'm missing some kernel option which ULE works around, or > > > > > > something like that. > > > > > > > > > > Hmm, ok. Please add KTR_RUNQ and KTR_SMP to the KTR masks, that is > > > > > 'options KTR_COMPILE=(KTR_PROC|KTR_RUNQ|KTR_SMP)' and > > > > > 'options KTR_MASK=(KTR_PROC|KTR_RUNQ|KTR_SMP)' > > > > > > > > > > Please also add this patch (on top of the previous patch): > > > > > > > > > > diff --git a/sys/kern/sched_4bsd.c b/sys/kern/sched_4bsd.c > > > > > index 2973a23..bab2278 100644 > > > > > --- a/sys/kern/sched_4bsd.c > > > > > +++ b/sys/kern/sched_4bsd.c > > > > > @@ -1278,6 +1278,8 @@ sched_add(struct thread *td, int flags) > > > > > KASSERT(td->td_flags & TDF_INMEM, > > > > > ("sched_add: thread swapped out")); > > > > > > > > > > + CTR2(KTR_PROC, "sched_add: thread %d (%s)", td->td_tid, > > > > > + sched_tdname(td)); > > > > > KTR_STATE2(KTR_SCHED, "thread", sched_tdname(td), "runq add", > > > > > "prio:%d", td->td_priority, KTR_ATTR_LINKED, > > > > > sched_tdname(curthread)); > > > > > diff --git a/sys/x86/x86/cpu_machdep.c b/sys/x86/x86/cpu_machdep.c > > > > > index f07b97e..1f418f1 100644 > > > > > --- a/sys/x86/x86/cpu_machdep.c > > > > > +++ b/sys/x86/x86/cpu_machdep.c > > > > > @@ -440,6 +440,7 @@ cpu_idle_wakeup(int cpu) > > > > > return (0); > > > > > if (*state == STATE_MWAIT) > > > > > *state = STATE_RUNNING; > > > > > + CTR1(KTR_PROC, "cpu_idle_wakeup: wokeup CPU %d", cpu); > > > > > return (1); > > > > > } > > > > > > > > > > (I haven't tried compiling it, you might have to add the sys/ktr.h > > > > > header to cpu_machdep.c if it doesn't build.) > > > > > > > > > > Hopefully we will get some better trace messages before it hangs > > > > > with this added info. The root issue seems to be that 4BSD is > > > > > pinning thread0 to some other CPU (due to sched_bind that happens > > > > > inside of bus_bind_intr() when the HPET driver pins IRQs to CPUs) > > > > > and that other CPU isn't waking up to realize it needs to run thread0. > > > > > > > > > > > > > It compiled with no changes needed. > > > > > > > > Even though I set MAXCPU to a mere 2, the boot still hadn't > > > > completed after 90 minutes and I broke it off. I still have > > > > the kernel, so I can try it another time when I have less need > > > > for my FreeBSD box. > > > > > > Did you have the KTR options enabled from before? I don't expect this > > > to fix the issue, this is more about getting better debug info when it > > > hangs. > > > > > > > Yes, all the options from before were enabled. Maybe I should have > > disabled KTR_VERBOSE=1? I'll try it without that. > > > > KTR_VERBOSE=1 is necessary. Yes. > OK, after about 5 hours it landed in an infinite loop emitting: > > cpu_0 ipi_cpu: cpu: 1 to 5 ipi: 2 (my CPU has 6 cores) Humm, can you capture a picture right when it hangs? Those interrupts are due to clock interrupts (IPI_HARDCLOCK) and are noise. More what I'm trying to see is if we send IPI_AST/IPI_PREEMPT to the CPU after binding to it. -- John Baldwin From owner-freebsd-current@freebsd.org Mon Aug 1 20:53: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 2A17FBAB7D3; Mon, 1 Aug 2016 20:53:49 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::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 D9F9A1D48; Mon, 1 Aug 2016 20:53:48 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-qt0-x232.google.com with SMTP id u25so111791735qtb.1; Mon, 01 Aug 2016 13:53:48 -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=74sHITmnD1Uy8NQx9N5Bzp/QSCal0ooiqZ9oQdqHrk0=; b=MeNBj+Ny3Fmta5xZOhQYXWhmfY4hiYzIn1sanmlojQ3ZsGP2sGWCB5AmFCM8yDkyJv DJ81Fyr7XbA9P/oS+ZARn6gSZQKrpd7Zz7xu5/WSgXjuF+mbiXbD9an3MIfCOM+zpj4v LmuMMKSUn9hnr/QS9uCPcKF3XbOzYDnNTnxjd4NxGsNSlCA8oRQYe2KL4+kvCROg/Zga 0X9QBjrAqxbuUzN2MMSwdHNlebXQf/KWXI+bGHzzbFunF9iHZzVUhlMCjYFY+4kZ+mj8 8cgeoDadqtUILQ/e5XDarIPppg7Bf0YxxmQvNhOL6vQ3zJWGFKLd4/0t0G02VPP+rV6N SweQ== 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=74sHITmnD1Uy8NQx9N5Bzp/QSCal0ooiqZ9oQdqHrk0=; b=FzBjbL/0N6LjbDZ4t6Bp+3+aWUYcmsRiwr6jvaBzTPBh4Ftbh5XHKmj/vxVhG95B6W qe/KR1vBkcasJto2bBPaUd/18+BiScOTli+/gcg7mrnnPu436K7NmoWLrlgWNRvomqxj k1JOqMsSC+a4lIROFr1+bnYBlaOCKbxXwNS4gr4qZw3pZPPA3SjnJ2qgoYxC0xgghlck ZBP0T+oAn7aPfKIhNYGrf0BjdKPubb9dZWbp1hKLj3GiSu2U/amXLEAQi3PxlF9goF9J dX22FtD66A2YShxhw9IRuZpaT+7/V7Xqz5zSPVvGJpJP8wE0wMXYABD7njSrpx50xIGF SOXA== X-Gm-Message-State: AEkooutYn7ant4Pl8sez/Ws1DDaSucBmerlMxUourPRlZcoOVkybtmImJiIQLvYEvVi4uzwdpgWl+ip/N7XKnw== X-Received: by 10.200.49.129 with SMTP id h1mr92620742qte.103.1470084827881; Mon, 01 Aug 2016 13:53:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.233.216.194 with HTTP; Mon, 1 Aug 2016 13:53:47 -0700 (PDT) In-Reply-To: <20160801143118.GE7956@mutt-hardenedbsd> References: <20160801140804.GD7956@mutt-hardenedbsd> <2061B016-057C-44E9-A982-C0B689861E40@freebsd.org> <20160801143118.GE7956@mutt-hardenedbsd> From: Ngie Cooper Date: Mon, 1 Aug 2016 13:53:47 -0700 Message-ID: Subject: Re: security/openvpn build failure on 12-CURRENT/amd64 To: Shawn Webb Cc: Matthias Andree , FreeBSD Current , ports 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, 01 Aug 2016 20:53:49 -0000 On Mon, Aug 1, 2016 at 7:31 AM, Shawn Webb wrote: ... > HardenedBSD's kernel and world matched and still had the very same > build error. > > Here's the build log: http://pastebin.com/TEBih1Sx Confirmed -- why's it looking for tcp6local/udp6local though (this isn't a valid protocol, and for some odd reason it's being picked up from the sample config file..?)? Looks like a port bug... Thanks, -Ngie $ sudo make -C /usr/ports/security/openvpn build ... PASS: t_lpback.sh The following test will take about two minutes. If the addresses are in use, this test will retry up to two times. Options error: Bad protocol: 'udp6local'. Allowed protocols with --proto option: [proto-uninitialized] [udp] [tcp-server] [tcp-client] [tcp] [udp6] [tcp6-server] [tcp6-client] [tcp6] Use --help for more information. Options error: Bad protocol: 'udp6local'. Allowed protocols with --proto option: [proto-uninitialized] [udp] [tcp-server] [tcp-client] [tcp] [udp6] [tcp6-server] [tcp6-client] [tcp6] Use --help for more information. FAIL: t_cltsrv.sh ==================================================== 1 of 2 tests failed (1 test was not run) Please report to openvpn-users@lists.sourceforge.net ==================================================== *** [check-TESTS] Error code 1 $ grep -r udp6local work/ work/openvpn-2.3.11/sample/sample-config-files/loopback-client.test:proto udp6local ::1 work/openvpn-2.3.11/sample/sample-config-files/loopback-server.test:proto udp6local ::1 From owner-freebsd-current@freebsd.org Mon Aug 1 21:04: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 03465BABADB for ; Mon, 1 Aug 2016 21:04:42 +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 DA7051608; Mon, 1 Aug 2016 21:04:42 +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 2B3D6210; Mon, 1 Aug 2016 21:04:43 +0000 (UTC) Date: Mon, 1 Aug 2016 21:04:42 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <804528599.90.1470085482714.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD #522 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: Mon, 01 Aug 2016 21:04:43 -0000 See From owner-freebsd-current@freebsd.org Mon Aug 1 21:18: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 21ECBBABDCB; Mon, 1 Aug 2016 21:18:41 +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 E16AB1CB5; Mon, 1 Aug 2016 21:18:40 +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:in-reply-to:mime-version:user-agent:date:date :message-id:from:from:references:subject:subject; s=201508; t= 1470086318; bh=3oBWQ3VitIa6r5mVSXxIihmfFPvTgRsp2WlNpcKmDys=; b=M L9uIdxKuys0X4S8VPSm8FL9qVIRGrdyeHNbK7S0zeEe8eEobmdGYTo5nQoZSNrCL FQXHzgfZSh1gIfR9xvaEtEtxiaygat2l/sNNXhbwEI4dS91C4zYyt07EamHjc6BZ HdkjKFLS3mWJu0FWrZP0Hp2Blfm1Gfzyp+YfEK3pGs= 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 CE3291CE26; Mon, 1 Aug 2016 17:18:38 -0400 (EDT) Subject: Re: security/openvpn build failure on 12-CURRENT/amd64 To: Ngie Cooper , Shawn Webb References: <20160801140804.GD7956@mutt-hardenedbsd> <2061B016-057C-44E9-A982-C0B689861E40@freebsd.org> <20160801143118.GE7956@mutt-hardenedbsd> Cc: Matthias Andree , FreeBSD Current , ports From: Michael Butler Message-ID: Date: Mon, 1 Aug 2016 17:18: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: 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, 01 Aug 2016 21:18:41 -0000 On 08/01/16 16:53, Ngie Cooper wrote: > On Mon, Aug 1, 2016 at 7:31 AM, Shawn Webb wrote: > >> HardenedBSD's kernel and world matched and still had the very same >> build error. >> >> Here's the build log: http://pastebin.com/TEBih1Sx > > Confirmed -- why's it looking for tcp6local/udp6local though (this > isn't a valid protocol, and for some odd reason it's being picked up > from the sample config file..?)? Looks like a port bug... > Thanks, > -Ngie Built just fine for me today on AMD64 "FreeBSD 12.0-CURRENT #165 r303601: Sun Jul 31 20:34:50 EDT 2016", imb From owner-freebsd-current@freebsd.org Mon Aug 1 21:54:18 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A7048BABB18; Mon, 1 Aug 2016 21:54:18 +0000 (UTC) (envelope-from mandree@freebsd.org) Received: from unimail.uni-dortmund.de (mx1.HRZ.tu-dortmund.de [129.217.128.51]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "unimail.tu-dortmund.de", Issuer "TU Dortmund CA - G01" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DCE01B79; Mon, 1 Aug 2016 21:54:17 +0000 (UTC) (envelope-from mandree@freebsd.org) Received: from [192.168.1.27] ([88.117.234.38]) (authenticated bits=0) by unimail.uni-dortmund.de (8.16.0.16/8.16.0.16) with ESMTPSA id u71LsDJQ002180 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Aug 2016 23:54:14 +0200 (CEST) User-Agent: K-9 Mail for Android In-Reply-To: References: <20160801140804.GD7956@mutt-hardenedbsd> <2061B016-057C-44E9-A982-C0B689861E40@freebsd.org> <20160801143118.GE7956@mutt-hardenedbsd> MIME-Version: 1.0 Subject: Re: security/openvpn build failure on 12-CURRENT/amd64 From: Matthias Andree Date: Mon, 01 Aug 2016 21:54:12 +0000 To: Ngie Cooper , Shawn Webb CC: FreeBSD Current , ports Message-ID: <9D61CE5E-9194-434A-A1AE-79DC21D04DC2@freebsd.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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, 01 Aug 2016 21:54:18 -0000 Hi Ngie, Quite possibly an incompatibility between the port or the upstream software build/self-test rigging with the rather new FreeBSD 12-CURRENT. Since I do not have the latter, I am soliciting patches (through Bugzilla). I am staring at ff. and it does not make sense to me that or why it is failing. I am wondering if it is something specific to 12-CURRENT that does additional patching, or if sed(1) behaves in a different way. Insights welcome. Cheers, Matthias Am 1. August 2016 22:53:47 MESZ, schrieb Ngie Cooper : >On Mon, Aug 1, 2016 at 7:31 AM, Shawn Webb >wrote: > >... > >> HardenedBSD's kernel and world matched and still had the very same >> build error. >> >> Here's the build log: http://pastebin.com/TEBih1Sx > >Confirmed -- why's it looking for tcp6local/udp6local though (this >isn't a valid protocol, and for some odd reason it's being picked up >from the sample config file..?)? Looks like a port bug... >Thanks, >-Ngie > >$ sudo make -C /usr/ports/security/openvpn build >... >PASS: t_lpback.sh >The following test will take about two minutes. >If the addresses are in use, this test will retry up to two times. >Options error: Bad protocol: 'udp6local'. Allowed protocols with >--proto option: [proto-uninitialized] [udp] [tcp-server] [tcp-client] >[tcp] [udp6] [tcp6-server] [tcp6-client] [tcp6] >Use --help for more information. >Options error: Bad protocol: 'udp6local'. Allowed protocols with >--proto option: [proto-uninitialized] [udp] [tcp-server] [tcp-client] >[tcp] [udp6] [tcp6-server] [tcp6-client] [tcp6] >Use --help for more information. >FAIL: t_cltsrv.sh >==================================================== >1 of 2 tests failed >(1 test was not run) >Please report to openvpn-users@lists.sourceforge.net >==================================================== >*** [check-TESTS] Error code 1 >$ grep -r udp6local work/ >work/openvpn-2.3.11/sample/sample-config-files/loopback-client.test:proto >udp6local ::1 >work/openvpn-2.3.11/sample/sample-config-files/loopback-server.test:proto >udp6local ::1 From owner-freebsd-current@freebsd.org Mon Aug 1 22:55: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 D2451BACA6D for ; Mon, 1 Aug 2016 22:55:27 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id C5F151382; Mon, 1 Aug 2016 22:55:27 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 54BA9214; Mon, 1 Aug 2016 22:55:23 +0000 (UTC) Date: Mon, 1 Aug 2016 22:55:07 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <391438486.92.1470092107026.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD_sparc64 #193 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_sparc64 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: Mon, 01 Aug 2016 22:55:27 -0000 See From owner-freebsd-current@freebsd.org Tue Aug 2 01:49: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 65D4BBAA9BA for ; Tue, 2 Aug 2016 01:49:52 +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 3A6B3181B; Tue, 2 Aug 2016 01:49:52 +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=1470102564; bh=Ej0ECmiPT 4hTpQFryzgVHRGsEVr+pFsE+wqiiiSMXxg=; b=dv8P5Rd55pBbPCk4Xq8ngqOU7 07HmwuBSCOdIeN5TGniPM9bk9PkOE4Pr3Wo+2WawPSQauw+/qtsPhBIMjIDLtJPO CYVgKbqCYiIRiFUqb36vs8MV5mXEe4d+oS0WCOb3pbMyJ8EG2ELUJQIiWIhhJ0li r6UcgUqDCUOHRPk/Rg= 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 D864B8EB1; Mon, 1 Aug 2016 21:49:24 -0400 (EDT) To: mjg@freebsd.org Cc: freebsd-current From: Michael Butler Subject: SVN r303643 breaks non-SMP compilation Message-ID: <6a9f68a7-8b1c-92cd-1409-fe574602a005@protected-networks.net> Date: Mon, 1 Aug 2016 21:49:03 -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, 02 Aug 2016 01:49:52 -0000 In the non-SMP case, ADAPTIVE_MUTEXES is not defined and a subsequent reference to mtx_delay causes compilation of kern_mutex.c to fail because KDTRACE_HOOKS may be, imb From owner-freebsd-current@freebsd.org Tue Aug 2 03:06: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 63CB4BABEB4 for ; Tue, 2 Aug 2016 03:06:30 +0000 (UTC) (envelope-from mjguzik@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 EB017136A for ; Tue, 2 Aug 2016 03:06:29 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-wm0-x234.google.com with SMTP id f65so391450317wmi.0 for ; Mon, 01 Aug 2016 20:06:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=5o9pgT8Zn/XpR47x/6ocfdXeL1ufVcjMj5S6q62aupM=; b=x5YKsoC7myT9rOWR6Xnzd54PbUxBQssuDbdPB71jDR8IyySVc5GQXp10u7hO55Ionq QQOJd4Kg4G/eimzK/hh1NPWrm/lzu38150+ZQFOCdh/lFn82pl3jxZKuowWTgEa9Wx34 qPPs2vukVlgRzVRj2yt7g4YbusbiXBw9vRSPpiXIIRvm+8KYKGndIgWN2ef521r2dZ7U raoVFW3iC/TRV8Ti636F8ReAQWN/8FSAcXjf9KHQ4+YV/iEq22mqz06ltPQYQEaSqvOq aL8UZeRRa7cgAaNoJwC45HaANAaf7ha3qKCa8cyYUqQsthe/JHb8B/scFElfA+v26uD8 Wq5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=5o9pgT8Zn/XpR47x/6ocfdXeL1ufVcjMj5S6q62aupM=; b=Ub+Tus90qzEPfOhjszu0Vur13DqsG8c8y8w1saVLTFnWKE7o/mPxg6UpcG0S3YUVEW w5+lWGxBgJes6ULh5RliTbKxgzgnzLlPFzSSZaqceqS+/xzIDhGcmiiTBs+0ud1/87+A bkHgwE/iI2wrhO+BrfxK1HCuE41dqSM5+2ReEEbST+4thitkT/QS1bvGMLrGJ3SUngRc Vj6wLMBQYox99248jqcQnhTFyed3Iak9Actcm9DQhdzxrD0NpMrKhVN9YD3CEBjP4JQs r2T3VyLA9TEx3rUcB86NWblqA8ByrjBLOArrJXukE9iogd+GdaaUefG3qulLOC0lPyN/ L0Sw== X-Gm-Message-State: AEkooutIeDoX3LDXIchdTk54jED9nS6txLGL8XL05Jr8dXgnY62ooA1ssC+GGUNu+FkjWw== X-Received: by 10.194.185.116 with SMTP id fb20mr28091274wjc.32.1470107188008; Mon, 01 Aug 2016 20:06:28 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by smtp.gmail.com with ESMTPSA id yt6sm290316wjc.23.2016.08.01.20.06.26 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Mon, 01 Aug 2016 20:06:27 -0700 (PDT) Date: Tue, 2 Aug 2016 05:06:24 +0200 From: Mateusz Guzik To: Michael Butler Cc: freebsd-current Subject: Re: SVN r303643 breaks non-SMP compilation Message-ID: <20160802030624.GA24961@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Michael Butler , freebsd-current References: <6a9f68a7-8b1c-92cd-1409-fe574602a005@protected-networks.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <6a9f68a7-8b1c-92cd-1409-fe574602a005@protected-networks.net> User-Agent: Mutt/1.5.21 (2010-09-15) 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, 02 Aug 2016 03:06:30 -0000 On Mon, Aug 01, 2016 at 09:49:03PM -0400, Michael Butler wrote: > In the non-SMP case, ADAPTIVE_MUTEXES is not defined and a subsequent > reference to mtx_delay causes compilation of kern_mutex.c to fail > because KDTRACE_HOOKS may be, > Indeed, fixed in r303655. Thanks for reporting. -- Mateusz Guzik From owner-freebsd-current@freebsd.org Tue Aug 2 03:22: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 5C906BAC19A; Tue, 2 Aug 2016 03:22:39 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1487F19F7; Tue, 2 Aug 2016 03:22:39 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: by mail-yw0-x22e.google.com with SMTP id r9so190568492ywg.0; Mon, 01 Aug 2016 20:22:39 -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=EhBNUcs8lgqhpBnZ5R5QKsQsfkBSkZLt4s92Cr+/9VQ=; b=h8/1FO4JPGOd+vLjNn4QO7CdoT5S2QiLxwnh7WrLzBEAa7dJYWsu9zpb//sbon9XKw n4yRbYKeOkbV+aYMqNXBZKdob8L7VYEiXpA0ZmDOhfkYq/aaDQB406i89nyex+AO1euN cLXtzW85+S9izeALjMWBayd09JRlg+kA0AgQvzZhtXsSzWBkneNvbjoix3CDlC4jabtr +2cHPZZkSSXLKyLS+tXXekyfteYcgBC4NPGRaEy+mcAlBiNukgEMs0x9tmODmuK8ukyr 86uFcRJU5Ven8S3zygEgIifI9eMAQO1SmosrcHm8mPaaec2+6eEb7oZgIvZU0pwZ+d7Y 1+jA== 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=EhBNUcs8lgqhpBnZ5R5QKsQsfkBSkZLt4s92Cr+/9VQ=; b=OW6HfflMb8+jvPf9JZTOHhMf25nkyHdgqiPxEVELPz3HUxbVXXJD9qs9khC6gbZ7DD /h+Vc7aj+Z2xENhKZUZhfbcRUnqAieLUWnzQVdgo8PdBxNHD00Wav9GpZJTL8wzw11Wt gB+icUDGGTDIc5UZFqW9gsa8gs6EVxPYTaZ9srJinwC/etl0V/9tx3flDdQV1EzJULH9 xyppIgQVe29ZlqCIYL912f/34d4VmAV41x4YZMGU7O5oI8sSoDgTy8wnD6v3BpbTHNBq xlkIXiOTgCT9FL/3XaKHmzdk3YgYql8w/TnCI73e62zc6np7k6dyRwQ1WzmMfo8r+7Fw G6ZA== X-Gm-Message-State: AEkoouulBy9374uIPj/TnlS4RZ9vZ+R/mPKnGIzZpAOA4eD7nZt4XUXBrh62cy8BY8Nt5dXcE+COzQ3QOMfQpw== X-Received: by 10.37.201.131 with SMTP id z125mr43845470ybf.183.1470108158170; Mon, 01 Aug 2016 20:22:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.51.150 with HTTP; Mon, 1 Aug 2016 20:22:37 -0700 (PDT) In-Reply-To: <579F8743.8030104@sorbs.net> References: <16CD100A-3BD0-47BA-A91E-F445E5DF6DBC@cyphytech.com> <1466527001.2694442.644278905.18E236CD@webmail.messagingengine.com> <1790833A-9292-4A46-B43C-BF41C7C801BE@cyphytech.com> <20160801084504.563c79cf@freyja.zeit4.iv.bundesimmobilien.de> <1519EC23-0DBC-4139-96F6-250EF872A14B@sarenet.es> <20160801151203.14a7a67d@freyja.zeit4.iv.bundesimmobilien.de> <0CA1A1F1-AFDD-4763-84C3-2FC059F44789@sarenet.es> <579F8743.8030104@sorbs.net> From: Ultima Date: Mon, 1 Aug 2016 23:22:37 -0400 Message-ID: Subject: Re: mfi driver performance too bad on LSI MegaRAID SAS 9260-8i To: Michelle Sullivan Cc: Borja Marcos , "O. Hartmann" , Jason Zhang , freebsd-performance@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-hardware@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, 02 Aug 2016 03:22:39 -0000 If anyone is interested, as Michelle Sullivan just mentioned. One problem I found when looking for an HBA is that they are not so easy to find. Scoured the internet for a backup HBA I came across these - http://www.avagotech.com/products/server-storage/host-bus-adapters/#tab-12G= b1 Can only speak for sas-9305-24i. All 24 bays are occupied and quite pleased with the performance compared to its predecessor. It was originally going to be a backup unit, however that changed after running a scrub and the amount of hours to complete cut in half (around 30ish to 15 for 35T). And of course, the reason for this post, it replaced a raid card in passthrough mode. Another note, because it is an HBA, the ability to flash firmware is once again possible! (yay!) +1 to HBA's + ZFS, if possible replace it for an HBA. On Mon, Aug 1, 2016 at 1:30 PM, Michelle Sullivan wrote: > Borja Marcos wrote: > >> On 01 Aug 2016, at 15:12, O. Hartmann >>> wrote: >>> >>> First, thanks for responding so quickly. >>> >>> - The third option is to make the driver expose the SAS devices like a >>>> HBA >>>> would do, so that they are visible to the CAM layer, and disks are >>>> handled by >>>> the stock =E2=80=9Cda=E2=80=9D driver, which is the ideal solution. >>>> >>> I didn't find any switch which offers me the opportunity to put the PRA= ID >>> CP400i into a simple HBA mode. >>> >> The switch is in the FreeBSD mfi driver, the loader tunable I mentioned, >> regardless of what the card >> firmware does or pretends to do. >> >> It=E2=80=99s not visible doing a "sysctl -a=E2=80=9D, but it exists and = it=E2=80=99s unique even. >> It=E2=80=99s defined here: >> >> >> https://svnweb.freebsd.org/base/stable/10/sys/dev/mfi/mfi_cam.c?revision= =3D267084&view=3Dmarkup >> (line 93) >> >> In order to do it you need a couple of things. You need to set the >>>> variable >>>> hw.mfi.allow_cam_disk_passthrough=3D1 and to load the mfip.ko module. >>>> >>>> When booting installation media, enter command mode and use these >>>> commands: >>>> >>>> ----- >>>> set hw.mfi.allow_cam_disk_passthrough=3D1 >>>> load mfip >>>> boot >>>> =E2=80=94=E2=80=94=E2=80=94 >>>> >>> Well, I'm truly aware of this problemacy and solution (now), but I run >>> into a >>> henn-egg-problem, literally. As long as I can boot off of the >>> installation >>> medium, I have a kernel which deals with the setting. But the boot >>> medium is >>> supposed to be a SSD sitting with the PRAID CP400i controller itself! >>> So, I >>> never be able to boot off the system without crippling the ability to >>> have a >>> fullspeed ZFS configuration which I suppose to have with HBA mode, but >>> not >>> with any of the forced RAID modes offered by the controller. >>> >> Been there plenty of times, even argued quite strongly about the >> advantages of ZFS against hardware based RAID >> 5 cards. :) I remember when the Dell salesmen couldn=E2=80=99t possibly >> understand why I wanted a =E2=80=9Csoftware based RAID rather than a >> robust, hardware based solution=E2=80=9D :D >> > > There are reasons for using either... > > Nowadays its seems the conversations have degenerated into those like > Windows vs Linux vs Mac where everyone thinks their answer is the right o= ne > (just as you suggested you (Borja Marcos) did with the Dell salesman), > where in reality each has its own advantages and disadvantages. Eg: I'm > running 2 zfs servers on 'LSI 9260-16i's... big mistake! (the ZFS, not > LSI's)... one is a 'movie server' the other a 'postgresql database' > server... The latter most would agree is a bad use of zfs, the die-hards > won't but then they don't understand database servers and how they work o= n > disk. The former has mixed views, some argue that zfs is the only way to > ensure the movies will always work, personally I think of all the years > before zfs when my data on disk worked without failure until the disks > themselves failed... and RAID stopped that happening... what suddenly > changed, are disks and ram suddenly not reliable at transferring data? .. > anyhow back to the issue there is another part with this particular > hardware that people just throw away... > > The LSI 9260-* controllers have been designed to provide on hardware > RAID. The caching whether using the Cachecade SSD or just oneboard ECC > memory is *ONLY* used when running some sort of RAID set and LVs... this = is > why LSI recommend 'MegaCli -CfgEachDskRaid0' because it does enable > caching.. A good read on how to setup something similar is here: > https://calomel.org/megacli_lsi_commands.html (disclaimer, I haven't > parsed it all so the author could be clueless, but it seems to give > generally good advice.) Going the way of 'JBOD' is a bad thing to do, ju= st > don't, performance sucks. As for the recommended command above, can't > comment because currently I don't use it nor will I need to in the near > future... but... > > If you (O Hartmann) want to use or need to use ZFS with any OS including > FreeBSD don't go with the LSI 92xx series controllers, its just the wrong > thing to do.. Pick an HBA that is designed to give you direct access to > the drives not one you have to kludge and cajole.. Including LSI > controllers with caches that use the mfi driver, just not those that are > not designed to work in a non RAID mode (with or without the passthru > command/mode above.) > > > > >> At worst, you can set up a simple boot from a thumb drive or, even >> better, a SATADOM installed inside the server. I guess it will >> have SATA ports on the mainboard. That=E2=80=99s what I use to do. FreeN= AS uses a >> similar approach as well. And some modern servers >> also can boot from a SD card which you can use just to load the kernel. >> >> Depending on the number of disks you have, you can also sacrifice two to >> set up a mirror with a =E2=80=9Cnomal=E2=80=9D boot system, and using >> the rest of the disks for ZFS. Actually I=E2=80=99ve got an old server I= set up >> in 2012. It has 16 disks, and I created a logical volume (mirror) >> with 2 disks for boot, the other 14 disks for ZFS. >> >> If I installed this server now I would do it different, booting off a >> thumb drive. But I was younger and naiver :) >> >> >> > If I installed mine now I would do them differently as well... neither > would run ZFS, both would use their on card RAID kernels and UFS on top o= f > them... ZFS would be reserved for the multi-user NFS file servers. (and > trust me here, when it comes to media servers - where the media is just > stored not changed/updated/edited - the 16i with a good highspeed SSD as > 'Cachecade' really performs well... and on a moderately powerful MB/CPU > combo with good RAM and several gigabit interfaces it's surprising how ma= ny > unicast transcoded media streams it can handle... (read: my twin fibres a= re > saturated before the machine reaches anywhere near full load, and I can > still write at 13MBps from my old Mac Mini over NFS... which is about all > it can do without any load either.) > > So moral of the story/choices. Don't go with ZFS because people tell you > its best, because it isn't, go with ZFS if it suits your hardware and > application, and if ZFS suits your application, get hardware for it. > > Regards, > > -- > Michelle Sullivan > http://www.mhix.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 Tue Aug 2 06:50: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 8016ABAAA79 for ; Tue, 2 Aug 2016 06:50:21 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id 5F8021E91; Tue, 2 Aug 2016 06:50:21 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from Alfreds-MacBook-Pro-2.local (unknown [IPv6:2601:645:8003:a4d6:95aa:bcf2:f3f:7b75]) by elvis.mu.org (Postfix) with ESMTPSA id E22D3346DDE2; Mon, 1 Aug 2016 23:50:14 -0700 (PDT) Subject: Re: [PATCH] randomized delay in locking primitives, take 2 To: Mateusz Guzik , Konstantin Belousov , jhb@freebsd.org, freebsd-current@freebsd.org References: <20160731095706.GB9408@dft-labs.eu> <20160731104928.GW83214@kib.kiev.ua> <20160731124113.GE9408@dft-labs.eu> From: Alfred Perlstein Organization: FreeBSD Message-ID: <188759ab-214a-3d21-17ad-ccfe559ef0f4@freebsd.org> Date: Mon, 1 Aug 2016 23:52:06 -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: <20160731124113.GE9408@dft-labs.eu> 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: Tue, 02 Aug 2016 06:50:21 -0000 Why is +struct lock_delay_config { + u_int initial; + u_int step; + u_int min; + u_int max; +}; missing comments for its members? Are they documented anywhere else? -Alfred On 7/31/16 5:41 AM, Mateusz Guzik wrote: > On Sun, Jul 31, 2016 at 01:49:28PM +0300, Konstantin Belousov wrote: > [snip] > > After an irc discussion, the following was produced (also available at: > https://people.freebsd.org/~mjg/lock_backoff_complete4.diff): > > Differences: > - uint64_t usage was converted to u_int (also see r303584) > - currently unused features (cap limit and return value) were removed > - lock_delay args got packed into a dedicated structure > > Note this patch requires the tree to be at least at r303584. > > diff --git a/sys/kern/kern_mutex.c b/sys/kern/kern_mutex.c > index 0555a78..9b07b8b 100644 > --- a/sys/kern/kern_mutex.c > +++ b/sys/kern/kern_mutex.c > @@ -55,6 +55,7 @@ __FBSDID("$FreeBSD$"); > #include > #include > #include > +#include > #include > #include > #include > @@ -138,6 +139,36 @@ struct lock_class lock_class_mtx_spin = { > #endif > }; > > +#ifdef ADAPTIVE_MUTEXES > +static SYSCTL_NODE(_debug, OID_AUTO, mtx, CTLFLAG_RD, NULL, "mtx debugging"); > + > +static struct lock_delay_config mtx_delay = { > + .initial = 1000, > + .step = 500, > + .min = 100, > + .max = 5000, > +}; > + > +SYSCTL_INT(_debug_mtx, OID_AUTO, delay_initial, CTLFLAG_RW, &mtx_delay.initial, > + 0, ""); > +SYSCTL_INT(_debug_mtx, OID_AUTO, delay_step, CTLFLAG_RW, &mtx_delay.step, > + 0, ""); > +SYSCTL_INT(_debug_mtx, OID_AUTO, delay_min, CTLFLAG_RW, &mtx_delay.min, > + 0, ""); > +SYSCTL_INT(_debug_mtx, OID_AUTO, delay_max, CTLFLAG_RW, &mtx_delay.max, > + 0, ""); > + > +static void > +mtx_delay_sysinit(void *dummy) > +{ > + > + mtx_delay.initial = mp_ncpus * 25; > + mtx_delay.min = mp_ncpus * 5; > + mtx_delay.max = mp_ncpus * 25 * 10; > +} > +LOCK_DELAY_SYSINIT(mtx_delay_sysinit); > +#endif > + > /* > * System-wide mutexes > */ > @@ -408,8 +439,10 @@ __mtx_lock_sleep(volatile uintptr_t *c, uintptr_t tid, int opts, > int contested = 0; > uint64_t waittime = 0; > #endif > +#if defined(ADAPTIVE_MUTEXES) || defined(KDTRACE_HOOKS) > + struct lock_delay_arg lda; > +#endif > #ifdef KDTRACE_HOOKS > - u_int spin_cnt = 0; > u_int sleep_cnt = 0; > int64_t sleep_time = 0; > int64_t all_time = 0; > @@ -418,6 +451,9 @@ __mtx_lock_sleep(volatile uintptr_t *c, uintptr_t tid, int opts, > if (SCHEDULER_STOPPED()) > return; > > +#if defined(ADAPTIVE_MUTEXES) || defined(KDTRACE_HOOKS) > + lock_delay_arg_init(&lda, &mtx_delay); > +#endif > m = mtxlock2mtx(c); > > if (mtx_owned(m)) { > @@ -451,7 +487,7 @@ __mtx_lock_sleep(volatile uintptr_t *c, uintptr_t tid, int opts, > if (m->mtx_lock == MTX_UNOWNED && _mtx_obtain_lock(m, tid)) > break; > #ifdef KDTRACE_HOOKS > - spin_cnt++; > + lda.spin_cnt++; > #endif > #ifdef ADAPTIVE_MUTEXES > /* > @@ -471,12 +507,8 @@ __mtx_lock_sleep(volatile uintptr_t *c, uintptr_t tid, int opts, > "spinning", "lockname:\"%s\"", > m->lock_object.lo_name); > while (mtx_owner(m) == owner && > - TD_IS_RUNNING(owner)) { > - cpu_spinwait(); > -#ifdef KDTRACE_HOOKS > - spin_cnt++; > -#endif > - } > + TD_IS_RUNNING(owner)) > + lock_delay(&lda); > KTR_STATE0(KTR_SCHED, "thread", > sched_tdname((struct thread *)tid), > "running"); > @@ -570,7 +602,7 @@ __mtx_lock_sleep(volatile uintptr_t *c, uintptr_t tid, int opts, > /* > * Only record the loops spinning and not sleeping. > */ > - if (spin_cnt > sleep_cnt) > + if (lda.spin_cnt > sleep_cnt) > LOCKSTAT_RECORD1(adaptive__spin, m, all_time - sleep_time); > #endif > } > diff --git a/sys/kern/kern_rwlock.c b/sys/kern/kern_rwlock.c > index d4cae61..363b042 100644 > --- a/sys/kern/kern_rwlock.c > +++ b/sys/kern/kern_rwlock.c > @@ -44,6 +44,7 @@ __FBSDID("$FreeBSD$"); > #include > #include > #include > +#include > #include > #include > #include > @@ -65,15 +66,6 @@ PMC_SOFT_DECLARE( , , lock, failed); > */ > #define rwlock2rw(c) (__containerof(c, struct rwlock, rw_lock)) > > -#ifdef ADAPTIVE_RWLOCKS > -static int rowner_retries = 10; > -static int rowner_loops = 10000; > -static SYSCTL_NODE(_debug, OID_AUTO, rwlock, CTLFLAG_RD, NULL, > - "rwlock debugging"); > -SYSCTL_INT(_debug_rwlock, OID_AUTO, retry, CTLFLAG_RW, &rowner_retries, 0, ""); > -SYSCTL_INT(_debug_rwlock, OID_AUTO, loops, CTLFLAG_RW, &rowner_loops, 0, ""); > -#endif > - > #ifdef DDB > #include > > @@ -100,6 +92,41 @@ struct lock_class lock_class_rw = { > #endif > }; > > +#ifdef ADAPTIVE_RWLOCKS > +static int rowner_retries = 10; > +static int rowner_loops = 10000; > +static SYSCTL_NODE(_debug, OID_AUTO, rwlock, CTLFLAG_RD, NULL, > + "rwlock debugging"); > +SYSCTL_INT(_debug_rwlock, OID_AUTO, retry, CTLFLAG_RW, &rowner_retries, 0, ""); > +SYSCTL_INT(_debug_rwlock, OID_AUTO, loops, CTLFLAG_RW, &rowner_loops, 0, ""); > + > +static struct lock_delay_config rw_delay = { > + .initial = 1000, > + .step = 500, > + .min = 100, > + .max = 5000, > +}; > + > +SYSCTL_INT(_debug_rwlock, OID_AUTO, delay_initial, CTLFLAG_RW, &rw_delay.initial, > + 0, ""); > +SYSCTL_INT(_debug_rwlock, OID_AUTO, delay_step, CTLFLAG_RW, &rw_delay.step, > + 0, ""); > +SYSCTL_INT(_debug_rwlock, OID_AUTO, delay_min, CTLFLAG_RW, &rw_delay.min, > + 0, ""); > +SYSCTL_INT(_debug_rwlock, OID_AUTO, delay_max, CTLFLAG_RW, &rw_delay.max, > + 0, ""); > + > +static void > +rw_delay_sysinit(void *dummy) > +{ > + > + rw_delay.initial = mp_ncpus * 25; > + rw_delay.min = mp_ncpus * 5; > + rw_delay.max = mp_ncpus * 25 * 10; > +} > +LOCK_DELAY_SYSINIT(rw_delay_sysinit); > +#endif > + > /* > * Return a pointer to the owning thread if the lock is write-locked or > * NULL if the lock is unlocked or read-locked. > @@ -355,9 +382,11 @@ __rw_rlock(volatile uintptr_t *c, const char *file, int line) > int contested = 0; > #endif > uintptr_t v; > +#if defined(ADAPTIVE_MUTEXES) || defined(KDTRACE_HOOKS) > + struct lock_delay_arg lda; > +#endif > #ifdef KDTRACE_HOOKS > uintptr_t state; > - u_int spin_cnt = 0; > u_int sleep_cnt = 0; > int64_t sleep_time = 0; > int64_t all_time = 0; > @@ -366,6 +395,9 @@ __rw_rlock(volatile uintptr_t *c, const char *file, int line) > if (SCHEDULER_STOPPED()) > return; > > +#if defined(ADAPTIVE_MUTEXES) || defined(KDTRACE_HOOKS) > + lock_delay_arg_init(&lda, &rw_delay); > +#endif > rw = rwlock2rw(c); > > KASSERT(kdb_active != 0 || !TD_IS_IDLETHREAD(curthread), > @@ -412,7 +444,7 @@ __rw_rlock(volatile uintptr_t *c, const char *file, int line) > continue; > } > #ifdef KDTRACE_HOOKS > - spin_cnt++; > + lda.spin_cnt++; > #endif > #ifdef HWPMC_HOOKS > PMC_SOFT_CALL( , , lock, failed); > @@ -437,12 +469,8 @@ __rw_rlock(volatile uintptr_t *c, const char *file, int line) > sched_tdname(curthread), "spinning", > "lockname:\"%s\"", rw->lock_object.lo_name); > while ((struct thread*)RW_OWNER(rw->rw_lock) == > - owner && TD_IS_RUNNING(owner)) { > - cpu_spinwait(); > -#ifdef KDTRACE_HOOKS > - spin_cnt++; > -#endif > - } > + owner && TD_IS_RUNNING(owner)) > + lock_delay(&lda); > KTR_STATE0(KTR_SCHED, "thread", > sched_tdname(curthread), "running"); > continue; > @@ -459,7 +487,7 @@ __rw_rlock(volatile uintptr_t *c, const char *file, int line) > cpu_spinwait(); > } > #ifdef KDTRACE_HOOKS > - spin_cnt += rowner_loops - i; > + lda.spin_cnt += rowner_loops - i; > #endif > KTR_STATE0(KTR_SCHED, "thread", sched_tdname(curthread), > "running"); > @@ -552,7 +580,7 @@ __rw_rlock(volatile uintptr_t *c, const char *file, int line) > (state & RW_LOCK_READ) == 0 ? 0 : RW_READERS(state)); > > /* Record only the loops spinning and not sleeping. */ > - if (spin_cnt > sleep_cnt) > + if (lda.spin_cnt > sleep_cnt) > LOCKSTAT_RECORD4(rw__spin, rw, all_time - sleep_time, > LOCKSTAT_READER, (state & RW_LOCK_READ) == 0, > (state & RW_LOCK_READ) == 0 ? 0 : RW_READERS(state)); > @@ -740,9 +768,11 @@ __rw_wlock_hard(volatile uintptr_t *c, uintptr_t tid, const char *file, > uint64_t waittime = 0; > int contested = 0; > #endif > +#if defined(ADAPTIVE_MUTEXES) || defined(KDTRACE_HOOKS) > + struct lock_delay_arg lda; > +#endif > #ifdef KDTRACE_HOOKS > uintptr_t state; > - u_int spin_cnt = 0; > u_int sleep_cnt = 0; > int64_t sleep_time = 0; > int64_t all_time = 0; > @@ -751,6 +781,9 @@ __rw_wlock_hard(volatile uintptr_t *c, uintptr_t tid, const char *file, > if (SCHEDULER_STOPPED()) > return; > > +#if defined(ADAPTIVE_MUTEXES) || defined(KDTRACE_HOOKS) > + lock_delay_arg_init(&lda, &rw_delay); > +#endif > rw = rwlock2rw(c); > > if (rw_wlocked(rw)) { > @@ -775,7 +808,7 @@ __rw_wlock_hard(volatile uintptr_t *c, uintptr_t tid, const char *file, > if (rw->rw_lock == RW_UNLOCKED && _rw_write_lock(rw, tid)) > break; > #ifdef KDTRACE_HOOKS > - spin_cnt++; > + lda.spin_cnt++; > #endif > #ifdef HWPMC_HOOKS > PMC_SOFT_CALL( , , lock, failed); > @@ -798,12 +831,8 @@ __rw_wlock_hard(volatile uintptr_t *c, uintptr_t tid, const char *file, > "spinning", "lockname:\"%s\"", > rw->lock_object.lo_name); > while ((struct thread*)RW_OWNER(rw->rw_lock) == owner && > - TD_IS_RUNNING(owner)) { > - cpu_spinwait(); > -#ifdef KDTRACE_HOOKS > - spin_cnt++; > -#endif > - } > + TD_IS_RUNNING(owner)) > + lock_delay(&lda); > KTR_STATE0(KTR_SCHED, "thread", sched_tdname(curthread), > "running"); > continue; > @@ -828,7 +857,7 @@ __rw_wlock_hard(volatile uintptr_t *c, uintptr_t tid, const char *file, > KTR_STATE0(KTR_SCHED, "thread", sched_tdname(curthread), > "running"); > #ifdef KDTRACE_HOOKS > - spin_cnt += rowner_loops - i; > + lda.spin_cnt += rowner_loops - i; > #endif > if (i != rowner_loops) > continue; > @@ -918,7 +947,7 @@ __rw_wlock_hard(volatile uintptr_t *c, uintptr_t tid, const char *file, > (state & RW_LOCK_READ) == 0 ? 0 : RW_READERS(state)); > > /* Record only the loops spinning and not sleeping. */ > - if (spin_cnt > sleep_cnt) > + if (lda.spin_cnt > sleep_cnt) > LOCKSTAT_RECORD4(rw__spin, rw, all_time - sleep_time, > LOCKSTAT_WRITER, (state & RW_LOCK_READ) == 0, > (state & RW_LOCK_READ) == 0 ? 0 : RW_READERS(state)); > diff --git a/sys/kern/kern_sx.c b/sys/kern/kern_sx.c > index 78d207d..42878110 100644 > --- a/sys/kern/kern_sx.c > +++ b/sys/kern/kern_sx.c > @@ -53,6 +53,7 @@ __FBSDID("$FreeBSD$"); > #include > #include > #include > +#include > #include > > #if defined(SMP) && !defined(NO_ADAPTIVE_SX) > @@ -145,6 +146,32 @@ static u_int asx_loops = 10000; > static SYSCTL_NODE(_debug, OID_AUTO, sx, CTLFLAG_RD, NULL, "sxlock debugging"); > SYSCTL_UINT(_debug_sx, OID_AUTO, retries, CTLFLAG_RW, &asx_retries, 0, ""); > SYSCTL_UINT(_debug_sx, OID_AUTO, loops, CTLFLAG_RW, &asx_loops, 0, ""); > + > +static struct lock_delay_config sx_delay = { > + .initial = 1000, > + .step = 500, > + .min = 100, > + .max = 5000, > +}; > + > +SYSCTL_INT(_debug_sx, OID_AUTO, delay_initial, CTLFLAG_RW, &sx_delay.initial, > + 0, ""); > +SYSCTL_INT(_debug_sx, OID_AUTO, delay_step, CTLFLAG_RW, &sx_delay.step, > + 0, ""); > +SYSCTL_INT(_debug_sx, OID_AUTO, delay_min, CTLFLAG_RW, &sx_delay.min, > + 0, ""); > +SYSCTL_INT(_debug_sx, OID_AUTO, delay_max, CTLFLAG_RW, &sx_delay.max, > + 0, ""); > + > +static void > +sx_delay_sysinit(void *dummy) > +{ > + > + sx_delay.initial = mp_ncpus * 25; > + sx_delay.min = mp_ncpus * 5; > + sx_delay.max = mp_ncpus * 25 * 10; > +} > +LOCK_DELAY_SYSINIT(sx_delay_sysinit); > #endif > > void > @@ -513,9 +540,11 @@ _sx_xlock_hard(struct sx *sx, uintptr_t tid, int opts, const char *file, > int contested = 0; > #endif > int error = 0; > +#if defined(ADAPTIVE_MUTEXES) || defined(KDTRACE_HOOKS) > + struct lock_delay_arg lda; > +#endif > #ifdef KDTRACE_HOOKS > uintptr_t state; > - u_int spin_cnt = 0; > u_int sleep_cnt = 0; > int64_t sleep_time = 0; > int64_t all_time = 0; > @@ -524,6 +553,10 @@ _sx_xlock_hard(struct sx *sx, uintptr_t tid, int opts, const char *file, > if (SCHEDULER_STOPPED()) > return (0); > > +#if defined(ADAPTIVE_MUTEXES) || defined(KDTRACE_HOOKS) > + lock_delay_arg_init(&lda, &sx_delay); > +#endif > + > /* If we already hold an exclusive lock, then recurse. */ > if (sx_xlocked(sx)) { > KASSERT((sx->lock_object.lo_flags & LO_RECURSABLE) != 0, > @@ -549,7 +582,7 @@ _sx_xlock_hard(struct sx *sx, uintptr_t tid, int opts, const char *file, > atomic_cmpset_acq_ptr(&sx->sx_lock, SX_LOCK_UNLOCKED, tid)) > break; > #ifdef KDTRACE_HOOKS > - spin_cnt++; > + lda.spin_cnt++; > #endif > #ifdef HWPMC_HOOKS > PMC_SOFT_CALL( , , lock, failed); > @@ -578,12 +611,8 @@ _sx_xlock_hard(struct sx *sx, uintptr_t tid, int opts, const char *file, > sx->lock_object.lo_name); > GIANT_SAVE(); > while (SX_OWNER(sx->sx_lock) == x && > - TD_IS_RUNNING(owner)) { > - cpu_spinwait(); > -#ifdef KDTRACE_HOOKS > - spin_cnt++; > -#endif > - } > + TD_IS_RUNNING(owner)) > + lock_delay(&lda); > KTR_STATE0(KTR_SCHED, "thread", > sched_tdname(curthread), "running"); > continue; > @@ -605,7 +634,7 @@ _sx_xlock_hard(struct sx *sx, uintptr_t tid, int opts, const char *file, > break; > cpu_spinwait(); > #ifdef KDTRACE_HOOKS > - spin_cnt++; > + lda.spin_cnt++; > #endif > } > KTR_STATE0(KTR_SCHED, "thread", > @@ -725,7 +754,7 @@ _sx_xlock_hard(struct sx *sx, uintptr_t tid, int opts, const char *file, > LOCKSTAT_RECORD4(sx__block, sx, sleep_time, > LOCKSTAT_WRITER, (state & SX_LOCK_SHARED) == 0, > (state & SX_LOCK_SHARED) == 0 ? 0 : SX_SHARERS(state)); > - if (spin_cnt > sleep_cnt) > + if (lda.spin_cnt > sleep_cnt) > LOCKSTAT_RECORD4(sx__spin, sx, all_time - sleep_time, > LOCKSTAT_WRITER, (state & SX_LOCK_SHARED) == 0, > (state & SX_LOCK_SHARED) == 0 ? 0 : SX_SHARERS(state)); > @@ -818,9 +847,11 @@ _sx_slock_hard(struct sx *sx, int opts, const char *file, int line) > #endif > uintptr_t x; > int error = 0; > +#if defined(ADAPTIVE_MUTEXES) || defined(KDTRACE_HOOKS) > + struct lock_delay_arg lda; > +#endif > #ifdef KDTRACE_HOOKS > uintptr_t state; > - u_int spin_cnt = 0; > u_int sleep_cnt = 0; > int64_t sleep_time = 0; > int64_t all_time = 0; > @@ -829,6 +860,9 @@ _sx_slock_hard(struct sx *sx, int opts, const char *file, int line) > if (SCHEDULER_STOPPED()) > return (0); > > +#if defined(ADAPTIVE_MUTEXES) || defined(KDTRACE_HOOKS) > + lock_delay_arg_init(&lda, &sx_delay); > +#endif > #ifdef KDTRACE_HOOKS > state = sx->sx_lock; > all_time -= lockstat_nsecs(&sx->lock_object); > @@ -840,7 +874,7 @@ _sx_slock_hard(struct sx *sx, int opts, const char *file, int line) > */ > for (;;) { > #ifdef KDTRACE_HOOKS > - spin_cnt++; > + lda.spin_cnt++; > #endif > x = sx->sx_lock; > > @@ -888,12 +922,8 @@ _sx_slock_hard(struct sx *sx, int opts, const char *file, int line) > "lockname:\"%s\"", sx->lock_object.lo_name); > GIANT_SAVE(); > while (SX_OWNER(sx->sx_lock) == x && > - TD_IS_RUNNING(owner)) { > - cpu_spinwait(); > -#ifdef KDTRACE_HOOKS > - spin_cnt++; > -#endif > - } > + TD_IS_RUNNING(owner)) > + lock_delay(&lda); > KTR_STATE0(KTR_SCHED, "thread", > sched_tdname(curthread), "running"); > continue; > @@ -989,7 +1019,7 @@ _sx_slock_hard(struct sx *sx, int opts, const char *file, int line) > LOCKSTAT_RECORD4(sx__block, sx, sleep_time, > LOCKSTAT_READER, (state & SX_LOCK_SHARED) == 0, > (state & SX_LOCK_SHARED) == 0 ? 0 : SX_SHARERS(state)); > - if (spin_cnt > sleep_cnt) > + if (lda.spin_cnt > sleep_cnt) > LOCKSTAT_RECORD4(sx__spin, sx, all_time - sleep_time, > LOCKSTAT_READER, (state & SX_LOCK_SHARED) == 0, > (state & SX_LOCK_SHARED) == 0 ? 0 : SX_SHARERS(state)); > diff --git a/sys/kern/subr_lock.c b/sys/kern/subr_lock.c > index e78d5a9..bfe189d 100644 > --- a/sys/kern/subr_lock.c > +++ b/sys/kern/subr_lock.c > @@ -103,6 +103,34 @@ lock_destroy(struct lock_object *lock) > lock->lo_flags &= ~LO_INITIALIZED; > } > > +void > +lock_delay(struct lock_delay_arg *la) > +{ > + u_int i, delay, backoff, min, max; > + struct lock_delay_config *lc = la->config; > + > + delay = la->delay; > + > + if (delay == 0) > + delay = lc->initial; > + else { > + delay += lc->step; > + max = lc->max; > + if (delay > max) > + delay = max; > + } > + > + backoff = cpu_ticks() % delay; > + min = lc->min; > + if (backoff < min) > + backoff = min; > + for (i = 0; i < backoff; i++) > + cpu_spinwait(); > + > + la->delay = delay; > + la->spin_cnt += backoff; > +} > + > #ifdef DDB > DB_SHOW_COMMAND(lock, db_show_lock) > { > diff --git a/sys/sys/lock.h b/sys/sys/lock.h > index 8d7a068..bd66aad 100644 > --- a/sys/sys/lock.h > +++ b/sys/sys/lock.h > @@ -201,9 +201,35 @@ extern struct lock_class lock_class_lockmgr; > > extern struct lock_class *lock_classes[]; > > +extern int lock_delay_enabled; > + > +struct lock_delay_config { > + u_int initial; > + u_int step; > + u_int min; > + u_int max; > +}; > + > +struct lock_delay_arg { > + struct lock_delay_config *config; > + u_int delay; > + u_int spin_cnt; > +}; > + > +static inline void > +lock_delay_arg_init(struct lock_delay_arg *la, struct lock_delay_config *lc) { > + la->config = lc; > + la->delay = 0; > + la->spin_cnt = 0; > +} > + > +#define LOCK_DELAY_SYSINIT(func) \ > + SYSINIT(func##_ld, SI_SUB_LOCK, SI_ORDER_ANY, func, NULL) > + > void lock_init(struct lock_object *, struct lock_class *, > const char *, const char *, int); > void lock_destroy(struct lock_object *); > +void lock_delay(struct lock_delay_arg *); > void spinlock_enter(void); > void spinlock_exit(void); > void witness_init(struct lock_object *, const char *); > > _______________________________________________ > 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 2 07:03: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 CB9E3BAAE80 for ; Tue, 2 Aug 2016 07:03:15 +0000 (UTC) (envelope-from gljennjohn@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 A8A6A1769 for ; Tue, 2 Aug 2016 07:03:15 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id A7BDABAAE7F; Tue, 2 Aug 2016 07:03:15 +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 A75D1BAAE7E for ; Tue, 2 Aug 2016 07:03:15 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 349221768; Tue, 2 Aug 2016 07:03:15 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm0-x241.google.com with SMTP id i5so29202572wmg.2; Tue, 02 Aug 2016 00:03:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=C+bc38tBKFIXPZvl0MIdxWKP0UXS63tKrqWPrvVmL/c=; b=TyPN9vR1tQX3ZNHP8MwllAP9jvSAQGMkz4iNPC1K10aMtEV3depo82454XmoiiainF qL1qE3z5jgunX12EsGhADTrpphdFkEjfSEgRShbD2kDLEfKlviZzPLYLa3GdYqAX+YvA AbcWWdV5uF4TanY17CFS7tndjqXFnsoXkgdS3AXe7c9ziCxk/w/ZQrlaJvFtaLTQYjpD r/i3Ln+4KqCrSBt29WDblvRC/6I4KzY9Mw9LhsCNKoRwNpa/AT9TlsRrDHKXAvasVoxl cqHeY7eG7UuADKPS5waYq6oog3h45dnXyq5dCcOTN3uEbdoYNd4UvoKOz/ExU/pdbsbi WsuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=C+bc38tBKFIXPZvl0MIdxWKP0UXS63tKrqWPrvVmL/c=; b=j9uQ7fijvoK9E4NRk3NxfCJE0ytHAnLeY1gfwJ6cYRbc70OynaIhK4mSglWKx3/Uhp 7tzs1LrjzvLYmTU0+8EiyxdFnQnSmzykoFbaL3EOxFIty7SN3U3yJdFlX2ZVDy8gY/De vHB0tzhbWdfWED1Yz++Q8iX5H56ZCJHpJheklv1zpMyqSgbItaKZcuZ0JDbfNBT4dKxh U376TFuuMY+W/abds9ikMJWpqlrJYGDi5fBlJ8Z7ZO30GU7j4vizFkC4o2tbUu8Uq1Fg X0UIujG6ORjc91PZgmmiBvCqszJUu2lJdxNj7dVXOz38ule4OXmUDziOd5yiO04fnuTb ysMQ== X-Gm-Message-State: AEkoouvOJivuGa75yYkChE2z28wIe8bgKn/ZRxB8Er9oMDKzh5UxKz7Bw6wgqWoEDJ+nCw== X-Received: by 10.194.223.99 with SMTP id qt3mr1963442wjc.148.1470121392890; Tue, 02 Aug 2016 00:03:12 -0700 (PDT) Received: from ernst.home (p578E3AA3.dip0.t-ipconnect.de. [87.142.58.163]) by smtp.gmail.com with ESMTPSA id q137sm20472339wmd.19.2016.08.02.00.03.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Aug 2016 00:03:12 -0700 (PDT) Date: Tue, 2 Aug 2016 09:03:10 +0200 From: Gary Jennejohn To: John Baldwin Cc: current@freebsd.org Subject: Re: EARLY_AP_STARTUP hangs during boot Message-ID: <20160802090310.7a03d6d0@ernst.home> In-Reply-To: <9937686.eTkQvkYRyu@ralph.baldwin.cx> References: <20160516122242.39249a54@ernst.home> <20160801093434.410032f4@ernst.home> <20160801153111.5e59d3ce@ernst.home> <9937686.eTkQvkYRyu@ralph.baldwin.cx> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 02 Aug 2016 07:03:15 -0000 On Mon, 01 Aug 2016 13:19:16 -0700 John Baldwin wrote: > On Monday, August 01, 2016 03:31:11 PM Gary Jennejohn wrote: > > On Mon, 1 Aug 2016 09:34:34 +0200 > > Gary Jennejohn wrote: > > > > > On Sun, 31 Jul 2016 14:22:35 -0700 > > > John Baldwin wrote: > > > > > > > On Sunday, July 31, 2016 11:29:14 AM Gary Jennejohn wrote: > > > > > On Sat, 30 Jul 2016 12:03:59 -0700 > > > > > John Baldwin wrote: > > > > > > > > > > > On Saturday, July 30, 2016 09:44:22 AM Gary Jennejohn wrote: > > > > > > > On Fri, 29 Jul 2016 13:17:42 -0700 > > > > > > > John Baldwin wrote: > > > > > > > > > > > > > > > On Thursday, July 28, 2016 12:31:31 AM Gary Jennejohn wrote: > > > > > > > > > Well, now I know that ULE is a prerequiste for EARLY_AP_STARTUP! I > > > > > > > > > wasn't aware of that. I prefer BSD and that's the scheduler I did > > > > > > > > > the first tests with. > > > > > > > > > > > > > > > > > > But with the ULE scheduler the system comes up all the way. > > > > > > > > > > > > > > > > > > It would be nice if the BSD scheduler could also be modified to > > > > > > > > > work with EARLY_AP_STARTUP. > > > > > > > > > > > > > > > > I wasn't able to reproduce your hang with 4BSD, but I think I see a > > > > > > > > possible problem. Try this: > > > > > > > > > > > > > > > > diff --git a/sys/kern/sched_4bsd.c b/sys/kern/sched_4bsd.c > > > > > > > > index 7de56b6..d53331a 100644 > > > > > > > > --- a/sys/kern/sched_4bsd.c > > > > > > > > +++ b/sys/kern/sched_4bsd.c > > > > > > > > @@ -327,7 +327,6 @@ maybe_preempt(struct thread *td) > > > > > > > > * - The current thread has a higher (numerically lower) or > > > > > > > > * equivalent priority. Note that this prevents curthread from > > > > > > > > * trying to preempt to itself. > > > > > > > > - * - It is too early in the boot for context switches (cold is set). > > > > > > > > * - The current thread has an inhibitor set or is in the process of > > > > > > > > * exiting. In this case, the current thread is about to switch > > > > > > > > * out anyways, so there's no point in preempting. If we did, > > > > > > > > @@ -348,7 +347,7 @@ maybe_preempt(struct thread *td) > > > > > > > > ("maybe_preempt: trying to run inhibited thread")); > > > > > > > > pri = td->td_priority; > > > > > > > > cpri = ctd->td_priority; > > > > > > > > - if (panicstr != NULL || pri >= cpri || cold /* || dumping */ || > > > > > > > > + if (panicstr != NULL || pri >= cpri /* || dumping */ || > > > > > > > > TD_IS_INHIBITED(ctd)) > > > > > > > > return (0); > > > > > > > > #ifndef FULL_PREEMPTION > > > > > > > > @@ -1127,7 +1126,7 @@ forward_wakeup(int cpunum) > > > > > > > > if ((!forward_wakeup_enabled) || > > > > > > > > (forward_wakeup_use_mask == 0 && forward_wakeup_use_loop == 0)) > > > > > > > > return (0); > > > > > > > > - if (!smp_started || cold || panicstr) > > > > > > > > + if (!smp_started || panicstr) > > > > > > > > return (0); > > > > > > > > > > > > > > > > forward_wakeups_requested++; > > > > > > > > > > > > > > > > > > > > > > Thanks, but with this patch the kernel hangs in exactly the same > > > > > > > place as before - after the HPET output. > > > > > > > > > > > > > > Maybe I'm missing some kernel option which ULE works around, or > > > > > > > something like that. > > > > > > > > > > > > Hmm, ok. Please add KTR_RUNQ and KTR_SMP to the KTR masks, that is > > > > > > 'options KTR_COMPILE=(KTR_PROC|KTR_RUNQ|KTR_SMP)' and > > > > > > 'options KTR_MASK=(KTR_PROC|KTR_RUNQ|KTR_SMP)' > > > > > > > > > > > > Please also add this patch (on top of the previous patch): > > > > > > > > > > > > diff --git a/sys/kern/sched_4bsd.c b/sys/kern/sched_4bsd.c > > > > > > index 2973a23..bab2278 100644 > > > > > > --- a/sys/kern/sched_4bsd.c > > > > > > +++ b/sys/kern/sched_4bsd.c > > > > > > @@ -1278,6 +1278,8 @@ sched_add(struct thread *td, int flags) > > > > > > KASSERT(td->td_flags & TDF_INMEM, > > > > > > ("sched_add: thread swapped out")); > > > > > > > > > > > > + CTR2(KTR_PROC, "sched_add: thread %d (%s)", td->td_tid, > > > > > > + sched_tdname(td)); > > > > > > KTR_STATE2(KTR_SCHED, "thread", sched_tdname(td), "runq add", > > > > > > "prio:%d", td->td_priority, KTR_ATTR_LINKED, > > > > > > sched_tdname(curthread)); > > > > > > diff --git a/sys/x86/x86/cpu_machdep.c b/sys/x86/x86/cpu_machdep.c > > > > > > index f07b97e..1f418f1 100644 > > > > > > --- a/sys/x86/x86/cpu_machdep.c > > > > > > +++ b/sys/x86/x86/cpu_machdep.c > > > > > > @@ -440,6 +440,7 @@ cpu_idle_wakeup(int cpu) > > > > > > return (0); > > > > > > if (*state == STATE_MWAIT) > > > > > > *state = STATE_RUNNING; > > > > > > + CTR1(KTR_PROC, "cpu_idle_wakeup: wokeup CPU %d", cpu); > > > > > > return (1); > > > > > > } > > > > > > > > > > > > (I haven't tried compiling it, you might have to add the sys/ktr.h > > > > > > header to cpu_machdep.c if it doesn't build.) > > > > > > > > > > > > Hopefully we will get some better trace messages before it hangs > > > > > > with this added info. The root issue seems to be that 4BSD is > > > > > > pinning thread0 to some other CPU (due to sched_bind that happens > > > > > > inside of bus_bind_intr() when the HPET driver pins IRQs to CPUs) > > > > > > and that other CPU isn't waking up to realize it needs to run thread0. > > > > > > > > > > > > > > > > It compiled with no changes needed. > > > > > > > > > > Even though I set MAXCPU to a mere 2, the boot still hadn't > > > > > completed after 90 minutes and I broke it off. I still have > > > > > the kernel, so I can try it another time when I have less need > > > > > for my FreeBSD box. > > > > > > > > Did you have the KTR options enabled from before? I don't expect this > > > > to fix the issue, this is more about getting better debug info when it > > > > hangs. > > > > > > > > > > Yes, all the options from before were enabled. Maybe I should have > > > disabled KTR_VERBOSE=1? I'll try it without that. > > > > > > > KTR_VERBOSE=1 is necessary. > > Yes. > > > OK, after about 5 hours it landed in an infinite loop emitting: > > > > cpu_0 ipi_cpu: cpu: 1 to 5 ipi: 2 (my CPU has 6 cores) > > Humm, can you capture a picture right when it hangs? Those interrupts > are due to clock interrupts (IPI_HARDCLOCK) and are noise. More what > I'm trying to see is if we send IPI_AST/IPI_PREEMPT to the CPU after > binding to it. > I can't tell when it hangs due to the amount of trace coming out. The hang is hidden in the noise and I have no way to suppress the trace that I'm aware of. The trace is coming so fast that even a photo of the screen looks smeared. Is there a way to limit the trace to IPI_AST/IPI_PREEMPT? I have, however, now switched to ULE and I'm running with EARLY_AP_STARTUP, but I'm willing run more tests with 4BSD. -- Gary Jennejohn From owner-freebsd-current@freebsd.org Tue Aug 2 08:27: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 BE388BAC21B; Tue, 2 Aug 2016 08:27:08 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from cu01176b.smtpx.saremail.com (cu01176b.smtpx.saremail.com [195.16.151.151]) (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 64B0518E3; Tue, 2 Aug 2016 08:27:07 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from [172.16.8.36] (izaro.sarenet.es [192.148.167.11]) by proxypop01.sare.net (Postfix) with ESMTPSA id B555C9DD613; Tue, 2 Aug 2016 10:27:03 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: mfi driver performance too bad on LSI MegaRAID SAS 9260-8i From: Borja Marcos In-Reply-To: <579F8743.8030104@sorbs.net> Date: Tue, 2 Aug 2016 10:27:02 +0200 Cc: "O. Hartmann" , Jason Zhang , freebsd-performance@freebsd.org, freebsd-current , FreeBSD-STABLE Mailing List , freebsd-hardware@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <16CD100A-3BD0-47BA-A91E-F445E5DF6DBC@cyphytech.com> <1466527001.2694442.644278905.18E236CD@webmail.messagingengine.com> <1790833A-9292-4A46-B43C-BF41C7C801BE@cyphytech.com> <20160801084504.563c79cf@freyja.zeit4.iv.bundesimmobilien.de> <1519EC23-0DBC-4139-96F6-250EF872A14B@sarenet.es> <20160801151203.14a7a67d@freyja.zeit4.iv.bundesimmobilien.de> <0CA1A1F1-AFDD-4763-84C3-2FC059F44789@sarenet.es> <579F8743.8030104@sorbs.net> To: Michelle Sullivan 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: Tue, 02 Aug 2016 08:27:08 -0000 > On 01 Aug 2016, at 19:30, Michelle Sullivan = wrote: >=20 > There are reasons for using either=E2=80=A6 Indeed, but my decision was to run ZFS. And getting a HBA in some = configurations can be difficult because vendors insist on using=20 RAID adapters. After all, that=E2=80=99s what most of their customers = demand. Fortunately, at least some Avago/LSI cards can work as HBAs pretty well. = An example is the now venerable LSI2008. > Nowadays its seems the conversations have degenerated into those like = Windows vs Linux vs Mac where everyone thinks their answer is the right = one (just as you suggested you (Borja Marcos) did with the Dell = salesman), where in reality each has its own advantages and = disadvantages. I know, but this is not the case. But it=E2=80=99s quite frustrating to = try to order a server with a HBA rather than a RAID and receiving an = answer such as =E2=80=9Cthe HBA option is not available=E2=80=9D. That=E2=80=99s why = people are zapping, flashing and, generally, torturing HBA cards rather = cruelly ;) So, in my case, it=E2=80=99s not about what=E2=80=99s better or worse. = It=E2=80=99s just a simpler issue. Customer (myself) has made a = decision, which can be right or wrong. Manufacturer fails to deliver = what I need. If it was only one manufacturer, well, off with them, but = the issue is widespread in industry.=20 > Eg: I'm running 2 zfs servers on 'LSI 9260-16i's... big mistake! (the = ZFS, not LSI's)... one is a 'movie server' the other a 'postgresql = database' server... The latter most would agree is a bad use of zfs, = the die-hards won't but then they don't understand database servers and = how they work on disk. The former has mixed views, some argue that zfs = is the only way to ensure the movies will always work, personally I = think of all the years before zfs when my data on disk worked without = failure until the disks themselves failed... and RAID stopped that = happening... what suddenly changed, are disks and ram suddenly not = reliable at transferring data? .. anyhow back to the issue there is = another part with this particular hardware that people just throw = away=E2=80=A6 Well, silent corruption can happen. I=E2=80=99ve seen it once caused by = a flaky HBA and ZFS saved the cake. Yes. there were reliable replicas. = Still, rebuilding would be a pain in the ass.=20 > The LSI 9260-* controllers have been designed to provide on hardware = RAID. The caching whether using the Cachecade SSD or just oneboard ECC = memory is *ONLY* used when running some sort of RAID set and LVs... this = is why LSI recommend 'MegaCli -CfgEachDskRaid0' because it does enable = caching.. A good read on how to setup something similar is here: = https://calomel.org/megacli_lsi_commands.html (disclaimer, I haven't = parsed it all so the author could be clueless, but it seems to give = generally good advice.) Going the way of 'JBOD' is a bad thing to do, = just don't, performance sucks. As for the recommended command above, = can't comment because currently I don't use it nor will I need to in the = near future... but=E2=80=A6 Actually it=E2=80=99s not a good idea to use heavy disk caching when = running ZFS. Its reliability depends on being able to commit metadata to = disk. So I don=E2=80=99t care about that caching option. Provided you = have enough RAM, ZFS is very effective caching data itself. > If you (O Hartmann) want to use or need to use ZFS with any OS = including FreeBSD don't go with the LSI 92xx series controllers, its = just the wrong thing to do.. Pick an HBA that is designed to give you = direct access to the drives not one you have to kludge and cajole.. = Including LSI controllers with caches that use the mfi driver, just not = those that are not designed to work in a non RAID mode (with or without = the passthru command/mode above.) As I said, the problem is, sometimes it=E2=80=99s not so easy to find = the right HBA.=20 > So moral of the story/choices. Don't go with ZFS because people tell = you its best, because it isn't, go with ZFS if it suits your hardware = and application, and if ZFS suits your application, get hardware for it. Indeed, I second this. But really, "hardware for it" covers a rather = broad cathegory ;) ZFS can even manage to work on hardware _against_ it. Borja. From owner-freebsd-current@freebsd.org Tue Aug 2 10:58: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 E5756BAC6AD for ; Tue, 2 Aug 2016 10:58:11 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward4j.cmail.yandex.net (forward4j.cmail.yandex.net [5.255.227.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 98D7C1D3C for ; Tue, 2 Aug 2016 10:58:11 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp3m.mail.yandex.net (smtp3m.mail.yandex.net [77.88.61.130]) by forward4j.cmail.yandex.net (Yandex) with ESMTP id 97E1F20F45; Tue, 2 Aug 2016 13:58:01 +0300 (MSK) Received: from smtp3m.mail.yandex.net (localhost.localdomain [127.0.0.1]) by smtp3m.mail.yandex.net (Yandex) with ESMTP id 962412841034; Tue, 2 Aug 2016 13:58:01 +0300 (MSK) Received: by smtp3m.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id CJX98immS4-w1B8MUXo; Tue, 02 Aug 2016 13:58:01 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1470135481; bh=tT1MMZCqPAE6+qgkaEkewh/D4SNxoG0xfJ/pdTK3vAE=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=gjAnH1Ss+9evFdf3uEF6ur87rUM2O57/kSYDWht8LhRUXkUwvz0EUU9iovtV71WoL ZCl2lPTbG2eoG9uRWY7XXPHarEXHXpTQa3Y2tnUcBrHi+DsZaBlyf33n9AQcFpvraz BUDjCbe8pr7C5O2MfxvG/VNPgVYvs0oj+g77zQeA= Authentication-Results: smtp3m.mail.yandex.net; dkim=pass header.i=@yandex.ru X-Yandex-Suid-Status: 1 0,1 0 Subject: Re: CURRENT: [USB] : GEOM_PART: da4 was automatically resized. To: "O. Hartmann" , freebsd-current References: <20160801110554.289d040d@freyja.zeit4.iv.bundesimmobilien.de> From: "Andrey V. Elsukov" Message-ID: <1d12ccb1-d77d-b2e0-1b89-b20b4a035ffb@yandex.ru> Date: Tue, 2 Aug 2016 13:56:17 +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: <20160801110554.289d040d@freyja.zeit4.iv.bundesimmobilien.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uPMrSk6xk3q6rwCQdDrqSLmsaqPfDGANe" 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, 02 Aug 2016 10:58:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uPMrSk6xk3q6rwCQdDrqSLmsaqPfDGANe Content-Type: multipart/mixed; boundary="ljEmQVK7cuoe4SJCOb40IVuTvtLxBKPiO" From: "Andrey V. Elsukov" To: "O. Hartmann" , freebsd-current Message-ID: <1d12ccb1-d77d-b2e0-1b89-b20b4a035ffb@yandex.ru> Subject: Re: CURRENT: [USB] : GEOM_PART: da4 was automatically resized. References: <20160801110554.289d040d@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <20160801110554.289d040d@freyja.zeit4.iv.bundesimmobilien.de> --ljEmQVK7cuoe4SJCOb40IVuTvtLxBKPiO Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 01.08.16 12:05, O. Hartmann wrote: > On every(!) USB drive which worked well with 11-CURRENT up to 11-BETA, = I fail > to access with 12-CURRENT (12.0-CURRENT FreeBSD 12.0-CURRENT #14 r30347= 5: Fri > Jul 29 11:59:11 CEST 2016) with the error shown below. >=20 > On USB flash drives I created myself, the suggested gpart command solve= d the > problem, but I can not do this with drives I was given by a vendor or s= upplier. JFYI, r303637 fixes this problem for me. --=20 WBR, Andrey V. Elsukov --ljEmQVK7cuoe4SJCOb40IVuTvtLxBKPiO-- --uPMrSk6xk3q6rwCQdDrqSLmsaqPfDGANe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEvBAEBCAAZBQJXoHxREhxidTdjaGVyQHlhbmRleC5ydQAKCRABxeoEEMihelB6 B/9MIMoQzKtZCFKHeVf1ISKTBHBgkIplRLvGkr15pQe00QlKO4dVUlkAdPpgnhw0 RILSYoZ7HZBpdNlSQ+/+EHx7VoNPzYtqJz2a686EsAW+CJHQ/CY4KfjBDshc1JHh bykw0bJczj5pNpemrEZkD/nzp+X+5G1lCspMZmoKaWY0EB5aP5R6JpiG/cuYX5Wj OBUTlXHUAJ2AQa4a5FoscIBKoDShvj404cM1LMYLmrO5wgBvVYrPhYqvsDz0LAiJ LmOKEPOeo13Kq2y1mHqcZ+UfqG5uvLKVS6zLxVSaJYk8kF2cT712gma389TiUooq dF7qv7A7FhHhntkXcndlF+yZ =5aA9 -----END PGP SIGNATURE----- --uPMrSk6xk3q6rwCQdDrqSLmsaqPfDGANe-- From owner-freebsd-current@freebsd.org Tue Aug 2 12:53: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 868FABAC5A2 for ; Tue, 2 Aug 2016 12:53:39 +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 E2C2919B2 for ; Tue, 2 Aug 2016 12:53:38 +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 PAA11856 for ; Tue, 02 Aug 2016 15:53:31 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1bUZCN-000LhR-0o for freebsd-current@freebsd.org; Tue, 02 Aug 2016 15:53:31 +0300 To: FreeBSD Current From: Andriy Gapon Subject: amd64-xtoolchain-gcc: small kernel compilation issue Message-ID: <0889f99f-b6fd-3768-818e-5b4ca9788229@FreeBSD.org> Date: Tue, 2 Aug 2016 15:52:11 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; 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, 02 Aug 2016 12:53:39 -0000 /usr/src/sys/modules/vmm/../../amd64/vmm/vmm_dev.c: In function 'alloc_memseg': /usr/src/sys/modules/vmm/../../amd64/vmm/vmm_dev.c:261:3: error: null argument where non-null required (argument 1) [-Werror=nonnull] error = copystr(VM_MEMSEG_NAME(mseg), name, SPECNAMELEN + 1, 0); This is with amd64-xtoolchain-gcc-0.1, which seems to install gcc version 5.3.0, and optimization level set to O1. It seems that in that case gcc is not smart enough to figure out that if VM_MEMSEG_NAME(mseg) is not NULL in a condition, then it can not be NULL in a block guarded by the condition. So, the following trivial patch should not be necessary but makes gcc a bit happier: --- a/sys/amd64/vmm/vmm_dev.c +++ b/sys/amd64/vmm/vmm_dev.c @@ -258,7 +258,7 @@ alloc_memseg if (VM_MEMSEG_NAME(mseg)) { sysmem = false; name = malloc(SPECNAMELEN + 1, M_VMMDEV, M_WAITOK); - error = copystr(VM_MEMSEG_NAME(mseg), name, SPECNAMELEN + 1, 0); + error = copystr(mseg->name, name, SPECNAMELEN + 1, 0); if (error) goto done; } -- Andriy Gapon From owner-freebsd-current@freebsd.org Tue Aug 2 14:52: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 B880FBACF2D for ; Tue, 2 Aug 2016 14:52:57 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (grunt.madpilot.net [78.47.145.38]) (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 7AFB51A4F for ; Tue, 2 Aug 2016 14:52:56 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3s3fM34F4gzZrR; Tue, 2 Aug 2016 16:52:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :mime-version:user-agent:date:date:message-id:from:from :references:subject:subject:received:received; s=mail; t= 1470149565; x=1471963966; bh=rrqnbb26RP5MtN/9UD8mX1SNBxWpoT6Jsf5 WoU4Qw4U=; b=omTHN6193V5ZniFdTf/2/xiU7TSOqs0OH4WkX2ZrbUPKXmQfiFx kFkUEyRbb+s2BvB8rapN8Rpvq1REnQ9BlrPOIvyUnBhhJmVUyLqM28wvrPApaZRC RvW/57ljMe0NPESMqOkQre46h6MYJCkV5HTTdEzVAVGJy+rBmFLYWO9o= Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10024) with ESMTP id FF79sFnVqaLW; Tue, 2 Aug 2016 16:52:45 +0200 (CEST) Received: from marvin.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA; Tue, 2 Aug 2016 16:52:45 +0200 (CEST) Subject: Re: SVN r303643 breaks non-SMP compilation To: Mateusz Guzik , Michael Butler , freebsd-current References: <6a9f68a7-8b1c-92cd-1409-fe574602a005@protected-networks.net> <20160802030624.GA24961@dft-labs.eu> From: Guido Falsi Message-ID: Date: Tue, 2 Aug 2016 16:52:45 +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: <20160802030624.GA24961@dft-labs.eu> 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: Tue, 02 Aug 2016 14:52:57 -0000 On 08/02/16 05:06, Mateusz Guzik wrote: > On Mon, Aug 01, 2016 at 09:49:03PM -0400, Michael Butler wrote: >> In the non-SMP case, ADAPTIVE_MUTEXES is not defined and a subsequent >> reference to mtx_delay causes compilation of kern_mutex.c to fail >> because KDTRACE_HOOKS may be, >> > > Indeed, fixed in r303655. > > Thanks for reporting. > I've noticed another failure in the same file, caused by r303643. It's failing to compile here due to errors about SYSINIT(9), it looks like #include is missing. I have made a local patch which compiles and afdter a reboot seems to work fine: Index: head/sys/kern/kern_sx.c =================================================================== --- head/sys/kern/kern_sx.c (revision 303658) +++ head/sys/kern/kern_sx.c (working copy) @@ -58,6 +58,7 @@ #if defined(SMP) && !defined(NO_ADAPTIVE_SX) #include +#include #endif #ifdef DDB -- Guido Falsi From owner-freebsd-current@freebsd.org Tue Aug 2 17:41: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 6BE5DBAA9AA for ; Tue, 2 Aug 2016 17:41:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 58C9B164E for ; Tue, 2 Aug 2016 17:41:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 581D8BAA9A9; Tue, 2 Aug 2016 17:41:28 +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 57BBEBAA9A8 for ; Tue, 2 Aug 2016 17:41:28 +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 327CA164D for ; Tue, 2 Aug 2016 17:41:28 +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 D43FDB94A; Tue, 2 Aug 2016 13:41:26 -0400 (EDT) From: John Baldwin To: gljennjohn@gmail.com Cc: current@freebsd.org Subject: Re: EARLY_AP_STARTUP hangs during boot Date: Tue, 02 Aug 2016 10:41:23 -0700 Message-ID: <4473265.DhpanzHFA4@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.3-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20160802090310.7a03d6d0@ernst.home> References: <20160516122242.39249a54@ernst.home> <9937686.eTkQvkYRyu@ralph.baldwin.cx> <20160802090310.7a03d6d0@ernst.home> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 02 Aug 2016 13:41:26 -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: Tue, 02 Aug 2016 17:41:28 -0000 On Tuesday, August 02, 2016 09:03:10 AM Gary Jennejohn wrote: > On Mon, 01 Aug 2016 13:19:16 -0700 > John Baldwin wrote: > > > On Monday, August 01, 2016 03:31:11 PM Gary Jennejohn wrote: > > > On Mon, 1 Aug 2016 09:34:34 +0200 > > > Gary Jennejohn wrote: > > > > > > > On Sun, 31 Jul 2016 14:22:35 -0700 > > > > John Baldwin wrote: > > > > > > > > > On Sunday, July 31, 2016 11:29:14 AM Gary Jennejohn wrote: > > > > > > On Sat, 30 Jul 2016 12:03:59 -0700 > > > > > > John Baldwin wrote: > > > > > > > > > > > > > On Saturday, July 30, 2016 09:44:22 AM Gary Jennejohn wrote: > > > > > > > > On Fri, 29 Jul 2016 13:17:42 -0700 > > > > > > > > John Baldwin wrote: > > > > > > > > > > > > > > > > > On Thursday, July 28, 2016 12:31:31 AM Gary Jennejohn wrote: > > > > > > > > > > Well, now I know that ULE is a prerequiste for EARLY_AP_STARTUP! I > > > > > > > > > > wasn't aware of that. I prefer BSD and that's the scheduler I did > > > > > > > > > > the first tests with. > > > > > > > > > > > > > > > > > > > > But with the ULE scheduler the system comes up all the way. > > > > > > > > > > > > > > > > > > > > It would be nice if the BSD scheduler could also be modified to > > > > > > > > > > work with EARLY_AP_STARTUP. > > > > > > > > > > > > > > > > > > I wasn't able to reproduce your hang with 4BSD, but I think I see a > > > > > > > > > possible problem. Try this: > > > > > > > > > > > > > > > > > > diff --git a/sys/kern/sched_4bsd.c b/sys/kern/sched_4bsd.c > > > > > > > > > index 7de56b6..d53331a 100644 > > > > > > > > > --- a/sys/kern/sched_4bsd.c > > > > > > > > > +++ b/sys/kern/sched_4bsd.c > > > > > > > > > @@ -327,7 +327,6 @@ maybe_preempt(struct thread *td) > > > > > > > > > * - The current thread has a higher (numerically lower) or > > > > > > > > > * equivalent priority. Note that this prevents curthread from > > > > > > > > > * trying to preempt to itself. > > > > > > > > > - * - It is too early in the boot for context switches (cold is set). > > > > > > > > > * - The current thread has an inhibitor set or is in the process of > > > > > > > > > * exiting. In this case, the current thread is about to switch > > > > > > > > > * out anyways, so there's no point in preempting. If we did, > > > > > > > > > @@ -348,7 +347,7 @@ maybe_preempt(struct thread *td) > > > > > > > > > ("maybe_preempt: trying to run inhibited thread")); > > > > > > > > > pri = td->td_priority; > > > > > > > > > cpri = ctd->td_priority; > > > > > > > > > - if (panicstr != NULL || pri >= cpri || cold /* || dumping */ || > > > > > > > > > + if (panicstr != NULL || pri >= cpri /* || dumping */ || > > > > > > > > > TD_IS_INHIBITED(ctd)) > > > > > > > > > return (0); > > > > > > > > > #ifndef FULL_PREEMPTION > > > > > > > > > @@ -1127,7 +1126,7 @@ forward_wakeup(int cpunum) > > > > > > > > > if ((!forward_wakeup_enabled) || > > > > > > > > > (forward_wakeup_use_mask == 0 && forward_wakeup_use_loop == 0)) > > > > > > > > > return (0); > > > > > > > > > - if (!smp_started || cold || panicstr) > > > > > > > > > + if (!smp_started || panicstr) > > > > > > > > > return (0); > > > > > > > > > > > > > > > > > > forward_wakeups_requested++; > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, but with this patch the kernel hangs in exactly the same > > > > > > > > place as before - after the HPET output. > > > > > > > > > > > > > > > > Maybe I'm missing some kernel option which ULE works around, or > > > > > > > > something like that. > > > > > > > > > > > > > > Hmm, ok. Please add KTR_RUNQ and KTR_SMP to the KTR masks, that is > > > > > > > 'options KTR_COMPILE=(KTR_PROC|KTR_RUNQ|KTR_SMP)' and > > > > > > > 'options KTR_MASK=(KTR_PROC|KTR_RUNQ|KTR_SMP)' > > > > > > > > > > > > > > Please also add this patch (on top of the previous patch): > > > > > > > > > > > > > > diff --git a/sys/kern/sched_4bsd.c b/sys/kern/sched_4bsd.c > > > > > > > index 2973a23..bab2278 100644 > > > > > > > --- a/sys/kern/sched_4bsd.c > > > > > > > +++ b/sys/kern/sched_4bsd.c > > > > > > > @@ -1278,6 +1278,8 @@ sched_add(struct thread *td, int flags) > > > > > > > KASSERT(td->td_flags & TDF_INMEM, > > > > > > > ("sched_add: thread swapped out")); > > > > > > > > > > > > > > + CTR2(KTR_PROC, "sched_add: thread %d (%s)", td->td_tid, > > > > > > > + sched_tdname(td)); > > > > > > > KTR_STATE2(KTR_SCHED, "thread", sched_tdname(td), "runq add", > > > > > > > "prio:%d", td->td_priority, KTR_ATTR_LINKED, > > > > > > > sched_tdname(curthread)); > > > > > > > diff --git a/sys/x86/x86/cpu_machdep.c b/sys/x86/x86/cpu_machdep.c > > > > > > > index f07b97e..1f418f1 100644 > > > > > > > --- a/sys/x86/x86/cpu_machdep.c > > > > > > > +++ b/sys/x86/x86/cpu_machdep.c > > > > > > > @@ -440,6 +440,7 @@ cpu_idle_wakeup(int cpu) > > > > > > > return (0); > > > > > > > if (*state == STATE_MWAIT) > > > > > > > *state = STATE_RUNNING; > > > > > > > + CTR1(KTR_PROC, "cpu_idle_wakeup: wokeup CPU %d", cpu); > > > > > > > return (1); > > > > > > > } > > > > > > > > > > > > > > (I haven't tried compiling it, you might have to add the sys/ktr.h > > > > > > > header to cpu_machdep.c if it doesn't build.) > > > > > > > > > > > > > > Hopefully we will get some better trace messages before it hangs > > > > > > > with this added info. The root issue seems to be that 4BSD is > > > > > > > pinning thread0 to some other CPU (due to sched_bind that happens > > > > > > > inside of bus_bind_intr() when the HPET driver pins IRQs to CPUs) > > > > > > > and that other CPU isn't waking up to realize it needs to run thread0. > > > > > > > > > > > > > > > > > > > It compiled with no changes needed. > > > > > > > > > > > > Even though I set MAXCPU to a mere 2, the boot still hadn't > > > > > > completed after 90 minutes and I broke it off. I still have > > > > > > the kernel, so I can try it another time when I have less need > > > > > > for my FreeBSD box. > > > > > > > > > > Did you have the KTR options enabled from before? I don't expect this > > > > > to fix the issue, this is more about getting better debug info when it > > > > > hangs. > > > > > > > > > > > > > Yes, all the options from before were enabled. Maybe I should have > > > > disabled KTR_VERBOSE=1? I'll try it without that. > > > > > > > > > > KTR_VERBOSE=1 is necessary. > > > > Yes. > > > > > OK, after about 5 hours it landed in an infinite loop emitting: > > > > > > cpu_0 ipi_cpu: cpu: 1 to 5 ipi: 2 (my CPU has 6 cores) > > > > Humm, can you capture a picture right when it hangs? Those interrupts > > are due to clock interrupts (IPI_HARDCLOCK) and are noise. More what > > I'm trying to see is if we send IPI_AST/IPI_PREEMPT to the CPU after > > binding to it. > > > > I can't tell when it hangs due to the amount of trace coming out. > The hang is hidden in the noise and I have no way to suppress the > trace that I'm aware of. The trace is coming so fast that even > a photo of the screen looks smeared. > > Is there a way to limit the trace to IPI_AST/IPI_PREEMPT? Yes: diff --git a/sys/x86/x86/mp_x86.c b/sys/x86/x86/mp_x86.c index 91c119a..6c57b20 100644 --- a/sys/x86/x86/mp_x86.c +++ b/sys/x86/x86/mp_x86.c @@ -1160,7 +1160,8 @@ ipi_cpu(int cpu, u_int ipi) if (ipi == IPI_STOP_HARD) CPU_SET_ATOMIC(cpu, &ipi_stop_nmi_pending); - CTR3(KTR_SMP, "%s: cpu: %d ipi: %x", __func__, cpu, ipi); + if (ipi == IPI_AST || ipi == IPI_PREEMPT) + CTR3(KTR_SMP, "%s: cpu: %d ipi: %x", __func__, cpu, ipi); ipi_send_cpu(cpu, ipi); } -- John Baldwin From owner-freebsd-current@freebsd.org Tue Aug 2 18:12: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 4B8F2BAC149 for ; Tue, 2 Aug 2016 18:12:45 +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 1262D1BF6 for ; Tue, 2 Aug 2016 18:12:44 +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 u72ICdSh000894 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 2 Aug 2016 11:12:42 -0700 (PDT) (envelope-from julian@freebsd.org) To: freebsd-current From: Julian Elischer Subject: Xen networking problems in -current with xn driver? Message-ID: <0b90d4f0-fc02-7a07-6ce1-135a61cbc352@freebsd.org> Date: Wed, 3 Aug 2016 02:12:33 +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 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: Tue, 02 Aug 2016 18:12:45 -0000 I upgraded my VPS machine to today's current, and on reboot I couldn't get into it by network. A quick switch to the VNC console showed that it was up but that it couldn't get out. The xn interfaces said they were UP but attempts to get out were met with "network is down". if I did 'tcpdump -n -i xn0' (and xn1) hten all was fine again. tcpdump saw packets, and in fact ipfw saw some packets coming in even before that but it was not possible to send. Has anyone seen similar? some relevant parts of the dmesg output.: T(vga): text 80x25 XEN: Hypervisor version 3.4 detected. CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (2400.05-MHz 686-class CPU) Origin="GenuineIntel" Id=0x206c2 Family=0x6 Model=0x2c Stepping=2 Features=0x1781fbff Features2=0x80982201 AMD Features=0x20100000 AMD Features2=0x1 Hypervisor: Origin = "XenVMMXenVMM" real memory = 536870912 (512 MB) avail memory = 503783424 (480 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: WARNING: L1 data cache covers less APIC IDs than a core 0 < 1 WARNING: L2 data cache covers less APIC IDs than a core 0 < 1 WARNING: L3 data cache covers less APIC IDs than a core 0 < 1 ipfw2 (+ipv6) initialized, divert loadable, nat enabled, default to deny, logging disabled xs_dev0: on xenstore0 xenbusb_front0: on xenstore0 xn0: at device/vif/0 on xenbusb_front0 xn0: Ethernet address: 00:16:3e:01:99:54 xn1: at device/vif/1 on xenbusb_front0 xn1: Ethernet address: 00:16:3e:01:9a:54 xenbusb_back0: on xenstore0 xenballoon0: on xenstore0 xctrl0: on xenstore0 xn0: backend features: feature-sg feature-gso-tcp4 xn1: backend features: feature-sg feature-gso-tcp4 xbd0: 20480MB at device/vbd/768 on xenbusb_front0 xbd0: attaching as ada0 xbd0: features: write_barrier xbd0: synchronize cache commands enabled. From owner-freebsd-current@freebsd.org Tue Aug 2 23:52: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 9050EBAD241 for ; Tue, 2 Aug 2016 23:52:11 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5A1261154; Tue, 2 Aug 2016 23:52:11 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-io0-x22d.google.com with SMTP id 38so227920857iol.0; Tue, 02 Aug 2016 16:52:11 -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=qlPOW5U2vyBeyZu/9quYEgZq2j0fELy5RawSz9dF/Xo=; b=y5B/SivCweRw6Sa5Hi9t2c+lYHu5c/8V1FCqrOj6kdCh1cKtt5/me4wkhYLxGvE39h emBlO4fymAa8jqysb7jsT+PeCXhvs3IDUGNYvFDe6CRgEjZ3+CQwZEhJvlC4RcHR3lxR qXtXCJfnDprViTfprTGbfsBULdD2S7WKVDhM33R7+KV7XNrC23PCp6WKf1nNtEeTozbB tg7+nUJ06F1ewHYRjpf6Ev84hDMgz8305nlcvD5LxZv5Sd8LxTwIHiOX9w37tNQtdleM SbSJQsmB6dksM2Q42AUkjgfZVVQGNQeIXjbCGfFNZpssabdC2MK5FRz+qv9h4oP0y98U A/9A== 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=qlPOW5U2vyBeyZu/9quYEgZq2j0fELy5RawSz9dF/Xo=; b=ET4QeEW+g/T6TLHzixOwendMkO8uWbTToMFwLZ5Yi59MxcAMvvDAhhv0eWEPW4ais8 5ui15rNXX6JEJkcvg7KdLtVzJ/Oyu1kqkCncYi5XjmJDbkfwSh4piA7fzmevQ5InQNLT qNxwrerjVVWfWYHteVHU/+Q1YMz8MsZDP7G7t1zsJdY4PvnZPlB5fOXBq4o+qhDQU5H5 zIcuE3KMbhSLOmp/Cgw2nmLBO2em8wqdk+Fs6bH58yylLL+G5ZOCYKQBUnOwA20muQR3 QlbelsuU1yhZMZ/5Rm/mu+prpUL+jPUx1fr9Ro4/iNhDkzEj0MISFRRzs1yB+ddZSoIC kuAg== X-Gm-Message-State: AEkoouutI2W6EfZEsZ/wPf436kApESbjGCDailRODqcujGmbvcorB0TxNJ+n5eq+0Ok8ydcZOFZpDNSDsuxv5A== X-Received: by 10.107.129.152 with SMTP id l24mr64314584ioi.179.1470181930563; Tue, 02 Aug 2016 16:52:10 -0700 (PDT) MIME-Version: 1.0 Sender: kob6558@gmail.com Received: by 10.79.119.144 with HTTP; Tue, 2 Aug 2016 16:52:10 -0700 (PDT) In-Reply-To: <0b90d4f0-fc02-7a07-6ce1-135a61cbc352@freebsd.org> References: <0b90d4f0-fc02-7a07-6ce1-135a61cbc352@freebsd.org> From: Kevin Oberman Date: Tue, 2 Aug 2016 16:52:10 -0700 X-Google-Sender-Auth: NPq77uJURJsIDMyCU2yoWtJ7ljA Message-ID: Subject: Re: Xen networking problems in -current with xn driver? To: Julian Elischer 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: Tue, 02 Aug 2016 23:52:11 -0000 On Tue, Aug 2, 2016 at 11:12 AM, Julian Elischer wrote: > I upgraded my VPS machine to today's current, and on reboot I couldn't get > into it by network. > > A quick switch to the VNC console showed that it was up but that it > couldn't get out. > > > The xn interfaces said they were UP but attempts to get out were met with > "network is down". > > if I did 'tcpdump -n -i xn0' (and xn1) hten all was fine again. > > tcpdump saw packets, and in fact ipfw saw some packets coming in even > before that but it was not possible to send. > > > Has anyone seen similar? > > some relevant parts of the dmesg output.: > > [...] A bit of a guess, but the obvious thing that I see is that when you start tcpdump you are placing the interface in promiscuous mode. Looks like the "device" fails to properly see packet addressed to it. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 From owner-freebsd-current@freebsd.org Wed Aug 3 03:37: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 37A8CBACD51 for ; Wed, 3 Aug 2016 03:37:05 +0000 (UTC) (envelope-from alive4ever@live.com) Received: from BAY004-OMC2S6.hotmail.com (bay004-omc2s6.hotmail.com [65.54.190.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "*.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0E43F123D for ; Wed, 3 Aug 2016 03:37:04 +0000 (UTC) (envelope-from alive4ever@live.com) Received: from APC01-HK2-obe.outbound.protection.outlook.com ([65.54.190.124]) by BAY004-OMC2S6.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 2 Aug 2016 20:35:58 -0700 Received: from SG2APC01FT112.eop-APC01.prod.protection.outlook.com (10.152.250.55) by SG2APC01HT031.eop-APC01.prod.protection.outlook.com (10.152.251.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.5; Wed, 3 Aug 2016 03:35:47 +0000 Received: from SIXPR06MB1022.apcprd06.prod.outlook.com (10.152.250.53) by SG2APC01FT112.mail.protection.outlook.com (10.152.250.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.5 via Frontend Transport; Wed, 3 Aug 2016 03:35:47 +0000 Received: from SIXPR06MB1022.apcprd06.prod.outlook.com ([10.160.239.156]) by SIXPR06MB1022.apcprd06.prod.outlook.com ([10.160.239.156]) with mapi id 15.01.0549.023; Wed, 3 Aug 2016 03:35:46 +0000 From: Alive 4ever To: "freebsd-current@freebsd.org" Subject: uuid/label based fstab during bsdinstall Thread-Topic: uuid/label based fstab during bsdinstall Thread-Index: AQHR7TgeVJU8LI6iEU6mcJ6KXdfNbA== Date: Wed, 3 Aug 2016 03:35:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=softfail (sender IP is 10.152.250.53) smtp.mailfrom=live.com; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=live.com; received-spf: SoftFail (protection.outlook.com: domain of transitioning live.com discourages use of 10.152.250.53 as permitted sender) x-ms-exchange-messagesentrepresentingtype: 1 x-eopattributedmessage: 0 x-forefront-antispam-report: CIP:10.152.250.53; IPV:NLI; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:SG2APC01HT031; H:SIXPR06MB1022.apcprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; x-microsoft-exchange-diagnostics: 1; SG2APC01HT031; 6:gI0F7H8aEQmGXnSxZuvKwo/yWrVwzvg1bzgVXjt21GVDcaXDDoADu5Z3AdlS8mnkyf/SJmbnGqSjb62lwdYBxBL4LJnyE1bITmls14E1QdJBu4EO3TNNH7H+p7+zX1jzHeJwKMVIJGEzGBs+MjoiRU4v67J2IkT3uJxnzXUboQ73UO9ZdrHn/60F3d1ErnB9g2FvGNjONhdlhlMPSXsAhUShDxYx81e56LcGecNNRJ/bS0rPd/UAy0MDQjpaYMWwL6Kwm+WLVzMn9lTcjVswBAeogiomlgE/8cE+YeJ1VQkmXJJfOX8EcM5fcg3QeCMv; 5:+7qgSF4kYjj8iV9/6Zs4jfL5ePR+IYj0nKQy4rzS5RGOu0eYAwZpJSLlEiOnQBqRROahmlU/MOr7FqIe77a3/QpnO0lxEGxtG3wG8njY3eR9fuPKFMxMB8rxJpJ1Vtf6+vJBVA4SA6FkzRhsFEtxow==; 24:Vv9bHbCK2+Y3UdOSSYJbJkf17rltGRJpozhhGXP4RrTyLMFgFbKqHeCCk+Xgip2gVbvOOHkCurrYfa/uq6th5iKPJB73zxNU5jy5FbS/QFM=; 7:Ic/qy66C9PEOZ2YZtjE/KF5hChMlop8Brgi/8gI8gKX9iUMjhK9u4JGZ/Ve0pu3nEyyGH98EFxdJ0HkSUS1O4IV92/Y8KBV5GwCCeVXqzB/MEO0DHyag1pNmQxOk/fZfnpY+D/zM5xdaHjfhgnFHBYI9WcTQieMsSw/tpSd+OMEW1UucJhH6Te1ofEBac76pcb1pLG6z4X4tg+cDvDEoXKOEUpmrAqjVUlcJYQTklPIQp6bAbdggnyZWbmU0Nu63 x-ms-office365-filtering-correlation-id: 660ed49a-84ef-4281-6afa-08d3bb4f3fe5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(1601124038)(1601125047); SRVR:SG2APC01HT031; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:SG2APC01HT031; BCL:0; PCL:0; RULEID:; SRVR:SG2APC01HT031; x-forefront-prvs: 00235A1EEF spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <159E43E1039AFC4F925AD6DC74F118EE@apcprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: live.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2016 03:35:46.1560 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2APC01HT031 X-OriginalArrivalTime: 03 Aug 2016 03:35:58.0762 (UTC) FILETIME=[2656A8A0:01D1ED38] 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, 03 Aug 2016 03:37:05 -0000 Greetings, everyone. I am testing FreeBSD 11.0-BETA3 release on a virtual machine (qemu, with edkII ovmf). Currently, bsdinstall creates device path based block device driver scheme instead of uuid/label based device scheme. bsdinstall-generated fstab has some drawback. For example, when switching from ide to virtio on qemu, freebsd can't find its root partition because the path name has changed from 'da0' to 'vtbd0'. I suggest adding an option during bsdinstall to select fstab block device pointer scheme. User will choose a scheme based on fs-uuid, fs-label, geom label (glabel), gpt id, gpt label, or driver based numbering scheme (da0/vtbd0 style). If fstab scheme choice is too hard to implement, it would be better to just switch default fstab generation to label based scheme, so that FreeBSD kernel will be able to find its rootfs in different circumstances. I hope this will be implemented soon. From owner-freebsd-current@freebsd.org Wed Aug 3 03:47:18 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 64BD1BAB0AE for ; Wed, 3 Aug 2016 03:47:18 +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 534D617B3 for ; Wed, 3 Aug 2016 03:47:17 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (ma45036d0.tmodns.net [208.54.80.164]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u733lDU8010920 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 2 Aug 2016 20:47:15 -0700 Subject: Re: uuid/label based fstab during bsdinstall To: freebsd-current@freebsd.org References: From: Nathan Whitehorn Message-ID: <8f929142-8956-2cc6-bb10-3fcb2983702c@freebsd.org> Date: Tue, 2 Aug 2016 20:47:13 -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: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVaCJtqxK/CEzKdB0PRgzzcMKlLdA50r0CaIdVB1FnhGwu/ZB5qmT9dsKXk7NE98yc5GHWc+A1acmrKA5k9dtRr13IZiL153kPE= X-Sonic-ID: C;zB7n9ixZ5hGNsaDx2xNB0g== M;pPq+9yxZ5hGNsaDx2xNB0g== 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: Wed, 03 Aug 2016 03:47:18 -0000 Unfortunately, the glabel and (especially) GPT partition ID labelling has in-kernel race conditions that make it impossible to rely on in the installer. This has been an open problem since FreeBSD 9; hopefully it will be solved soon. -Nathan On 08/02/16 20:35, Alive 4ever wrote: > Greetings, everyone. > > I am testing FreeBSD 11.0-BETA3 release on a virtual machine (qemu, > with > edkII ovmf). > > Currently, bsdinstall creates device path based block device driver > scheme instead of uuid/label based device scheme. > > bsdinstall-generated fstab has some drawback. For example, when > switching from ide to virtio on qemu, freebsd can't find its root > partition because the path name has changed from 'da0' to 'vtbd0'. > > I suggest adding an option during bsdinstall to select fstab block > device pointer scheme. User will choose a scheme based on fs-uuid, > fs-label, geom label (glabel), gpt id, gpt label, or driver based > numbering scheme (da0/vtbd0 style). > > If fstab scheme choice is too hard to implement, it would be better to > just switch default fstab generation to label based scheme, so that > FreeBSD kernel will be able to find its rootfs in different > circumstances. > > I hope this will be implemented soon. > > _______________________________________________ > 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 Wed Aug 3 08:20: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 1C023BACF25; Wed, 3 Aug 2016 08:20:31 +0000 (UTC) (envelope-from prvs=016a9660e=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 95BB01B0C; Wed, 3 Aug 2016 08:20:29 +0000 (UTC) (envelope-from prvs=016a9660e=roger.pau@citrix.com) X-IronPort-AV: E=Sophos;i="5.28,465,1464652800"; d="scan'208";a="377111758" Date: Wed, 3 Aug 2016 10:20:19 +0200 From: Roger Pau =?iso-8859-1?Q?Monn=E9?= To: Julian Elischer CC: freebsd-current , Subject: Re: Xen networking problems in -current with xn driver? Message-ID: <20160803082018.jrqienhyewjjjmmb@mac> References: <0b90d4f0-fc02-7a07-6ce1-135a61cbc352@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <0b90d4f0-fc02-7a07-6ce1-135a61cbc352@freebsd.org> 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: Wed, 03 Aug 2016 08:20:31 -0000 On Wed, Aug 03, 2016 at 02:12:33AM +0800, Julian Elischer wrote: > I upgraded my VPS machine to today's current, and on reboot I couldn't get > into it by network. > > A quick switch to the VNC console showed that it was up but that it couldn't > get out. > > > The xn interfaces said they were UP but attempts to get out were met with > "network is down". > > if I did 'tcpdump -n -i xn0' (and xn1) hten all was fine again. > > tcpdump saw packets, and in fact ipfw saw some packets coming in even before > that but it was not possible to send. > > > Has anyone seen similar? Hello, I've tested current less than one week ago and didn't find any issues, I'm currently updating to see if it's something that has been introduced in the last few days. There have also been reports of it working fine on the freebsd-xen mailing list, but I guess there's something different with your setup: https://lists.freebsd.org/pipermail/freebsd-xen/2016-July/002779.html > some relevant parts of the dmesg output.: > > > T(vga): text 80x25 > XEN: Hypervisor version 3.4 detected. > CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (2400.05-MHz 686-class > CPU) > Origin="GenuineIntel" Id=0x206c2 Family=0x6 Model=0x2c Stepping=2 > Features=0x1781fbff > Features2=0x80982201 > AMD Features=0x20100000 > AMD Features2=0x1 > Hypervisor: Origin = "XenVMMXenVMM" > real memory = 536870912 (512 MB) > avail memory = 503783424 (480 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: > WARNING: L1 data cache covers less APIC IDs than a core > 0 < 1 > WARNING: L2 data cache covers less APIC IDs than a core > 0 < 1 > WARNING: L3 data cache covers less APIC IDs than a core > 0 < 1 > > ipfw2 (+ipv6) initialized, divert loadable, nat enabled, default to deny, You seem to be using ipfw, I guess you have firewall_enable="YES" on you rc.conf, are you also using IPv6? Anything else net related on your rc.conf? Roger. From owner-freebsd-current@freebsd.org Wed Aug 3 09:25: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 C7714BAB07D; Wed, 3 Aug 2016 09:25:38 +0000 (UTC) (envelope-from prvs=016a9660e=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 0836B1F8B; Wed, 3 Aug 2016 09:25:37 +0000 (UTC) (envelope-from prvs=016a9660e=roger.pau@citrix.com) X-IronPort-AV: E=Sophos;i="5.28,465,1464652800"; d="scan'208";a="370008481" Date: Wed, 3 Aug 2016 11:24:24 +0200 From: Roger Pau =?iso-8859-1?Q?Monn=E9?= To: Julian Elischer , freebsd-current , Subject: Re: Xen networking problems in -current with xn driver? Message-ID: <20160803092424.6crhc3arij7txpzq@mac> References: <0b90d4f0-fc02-7a07-6ce1-135a61cbc352@freebsd.org> <20160803082018.jrqienhyewjjjmmb@mac> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160803082018.jrqienhyewjjjmmb@mac> 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: Wed, 03 Aug 2016 09:25:38 -0000 On Wed, Aug 03, 2016 at 10:20:19AM +0200, Roger Pau Monné wrote: > On Wed, Aug 03, 2016 at 02:12:33AM +0800, Julian Elischer wrote: > > I upgraded my VPS machine to today's current, and on reboot I couldn't get > > into it by network. > > > > A quick switch to the VNC console showed that it was up but that it couldn't > > get out. > > > > > > The xn interfaces said they were UP but attempts to get out were met with > > "network is down". > > > > if I did 'tcpdump -n -i xn0' (and xn1) hten all was fine again. > > > > tcpdump saw packets, and in fact ipfw saw some packets coming in even before > > that but it was not possible to send. > > > > > > Has anyone seen similar? > > Hello, > > I've tested current less than one week ago and didn't find any issues, I'm > currently updating to see if it's something that has been introduced in the > last few days. There have also been reports of it working fine on the > freebsd-xen mailing list, but I guess there's something different with your > setup: > > https://lists.freebsd.org/pipermail/freebsd-xen/2016-July/002779.html > > > some relevant parts of the dmesg output.: > > > > > > T(vga): text 80x25 > > XEN: Hypervisor version 3.4 detected. > > CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (2400.05-MHz 686-class > > CPU) > > Origin="GenuineIntel" Id=0x206c2 Family=0x6 Model=0x2c Stepping=2 > > Features=0x1781fbff > > Features2=0x80982201 > > AMD Features=0x20100000 > > AMD Features2=0x1 > > Hypervisor: Origin = "XenVMMXenVMM" > > real memory = 536870912 (512 MB) > > avail memory = 503783424 (480 MB) > > Event timer "LAPIC" quality 400 > > ACPI APIC Table: > > WARNING: L1 data cache covers less APIC IDs than a core > > 0 < 1 > > WARNING: L2 data cache covers less APIC IDs than a core > > 0 < 1 > > WARNING: L3 data cache covers less APIC IDs than a core > > 0 < 1 > > > > ipfw2 (+ipv6) initialized, divert loadable, nat enabled, default to deny, > > You seem to be using ipfw, I guess you have firewall_enable="YES" on you > rc.conf, are you also using IPv6? Anything else net related on your rc.conf? FWIW, I've added: firewall_enable="YES" firewall_type="open" To my rc.conf and I'm still not able to reproduce, this is all with IPv4. Roger. From owner-freebsd-current@freebsd.org Wed Aug 3 08:06: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 2A97BBACCA9 for ; Wed, 3 Aug 2016 08:06:00 +0000 (UTC) (envelope-from cheffo@freebsd-bg.org) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B222616CC for ; Wed, 3 Aug 2016 08:05:59 +0000 (UTC) (envelope-from cheffo@freebsd-bg.org) Received: by mail-lf0-x234.google.com with SMTP id g62so155309837lfe.3 for ; Wed, 03 Aug 2016 01:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd-bg-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=OuVgYaongUZJLpyDm/qhUlNElQ6G1RJOHj5EZ6wrYNA=; b=2PeRwfR0+TC66QoKVgk+sskjf3GXXAUBjP+WfKjP9e95QpXgwxsfqu0h2nlPqCKlmp /esQ8ESY6sikyYkn5Wmz0PLT7G2b3jFPQpvF9yq3dWS/x971/dp642HMI/o8mUpYdyQ8 eyRn4I75GT9UjWaIuUWI3PWtAnpRp1QX0pu2d2uCNs/hc9oQW42MOypCOZqAahyGGCb0 86tgEWJhx/uJQlPUSgI3PjK4hsIZFuLHisY6D3Z1Qh3jBXkYpaUXqnXRiwGiZWCvGsvu IpGt9Isa3Z8jYw/xXsh80vi/36Rh36verov+9ft9/Cx5s1ocH1vmFv2JgkOvgbUFdlX9 PV9A== 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=OuVgYaongUZJLpyDm/qhUlNElQ6G1RJOHj5EZ6wrYNA=; b=mWBQggtcMDL/nqgF3UimfxusCXbIylAKYeoB4ibwKleAewXKN3dYpo/KkXx69/Pxpe fm7TUkK/MeK4iOfqC1x7G/fTlqDckRWKkuqodX6LI7KgurlTWCSZNMeW3GOKJMPiJKVa Dosa8J1+z7WPPHh1bOMVAKhVJl0yghotHFFbjtZPm/3xAnHKj9SNtoJey8hIamrKLOHI Dtqv+O+2dUioRISts0LBTleaUG5KfQcRzyaqc5YoNIJvB66wwg13+UxIaSwEsBQRvvHH tmDkTIeEKYjYu/miviFvbH6UnmhOCcDiUJeIE03TC7AVzhXNcrz0AdzBQgrltqvDrgMt HYYQ== X-Gm-Message-State: AEkoouuo/1qdRKbCP6JQ1hC9J6ML4DafpVg1FYmwu2zs+PK7OWqikjwt4tOQ/myVJR7cuaSbzJlDFCSfjhx3Yw== X-Received: by 10.46.9.216 with SMTP id 207mr18609694ljj.62.1470211557556; Wed, 03 Aug 2016 01:05:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.44.201 with HTTP; Wed, 3 Aug 2016 01:05:57 -0700 (PDT) From: Stefan Lambrev Date: Wed, 3 Aug 2016 11:05:57 +0300 Message-ID: Subject: Wierd issues with wifi in hostap mode in FreeBSD 11 To: freebsd-current@freebsd.org X-Mailman-Approved-At: Wed, 03 Aug 2016 11:32:40 +0000 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, 03 Aug 2016 08:06:00 -0000 Greetings, I've just installed FreeBSD 11 on Soekris net5501 with the following wifi card: root@soekris:~ # dmesg |grep ath0 ath0: mem 0xa0010000-0xa001ffff irq 15 at device 17.0 on pci0 ath0: AR5413 mac 10.5 RF5413 phy 6.1 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0063 ath0@pci0:0:17:0: class=0x020000 card=0x110719b6 chip=0x001b168c rev=0x01 hdr=0x00 vendor = 'Qualcomm Atheros' device = 'AR5413/AR5414 Wireless Network Adapter [AR5006X(S) 802.11abg]' class = network subclass = ethernet But wat is very strange for me is that I do not see ath0 device on ifconfig: root@soekris:~ # ifconfig ath0 ifconfig: interface ath0 does not exist At the same time if I crate wlan0 to list caps it works: root@soekris:~ # ifconfig wlan0 create wlandev ath0 root@soekris:~ # ifconfig wlan0 list caps drivercaps=4f8defc1 cryptocaps=1f root@soekris:~ # The issues is that when I try to start wlan0 in hostap mode - FreeBSD freezes, unfortunatelly I cannot find my serial port cable atm and cannot see what exactly is displayed on the console but it's a hard freeze and the device do not reboot after it e.g. power cycle is required. When configured from rc.conf it boots and do not freeze but still says status: no carrier and hostapd complains that the device is not configured. snippet from rc.conf: cloned_interfaces="bridge0" wlans_ath0="wlan0" create_args_wlan0="wlanmod hostap" ifconfig_wlan0="ssid cheffo country bg up" ifconfig_bridge0="addm vr0 addm vr1 addm vr2 addm vr3 addm wlan0 up" ifconfig_bridge0_alias0="inet 10.1.1.2 netmask 255.255.255.0" I'm still with GENERIC kernel and there are no changes or custom cpu optimizations done so far: root@soekris:~ # uname -a FreeBSD soekris.ziops-security.org 11.0-BETA3 FreeBSD 11.0-BETA3 #0 r303469: Fri Jul 29 04:28:58 UTC 2016 root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386 root@soekris:~ # cat /boot/loader.conf dcons_load="YES" dcons_crom="YES" crypto_load="YES" cryptodev_load="YES" glxsb_load="YES" if_bridge_load="YES" wlan_xauth_load="YES" root@soekris:~ # kldstat Id Refs Address Size Name 1 19 0xc0400000 1a9313c kernel 2 1 0xc1e95000 80d4 geom_label.ko 3 1 0xc1e9e000 bc80 if_bridge.ko 4 2 0xc1eaa000 6ce0 bridgestp.ko 5 1 0xc1eb1000 3a70 dcons.ko 6 1 0xc1eb5000 5978 cryptodev.ko 7 1 0xc1ebb000 548c glxsb.ko 8 1 0xc1ec1000 1d6c wlan_xauth.ko I have to mention that I've tried with 11-BETA2 first and there were the same behaviour, and also I have used this soekris setup for few years with FreeBSD 7 and 8 for a home wifi router so I do know that the hardware is supported and OK, as it worked rock solid just before reinstalling it with FreeBSD 11. Any advice on how to get wifi working again? Thanks! From owner-freebsd-current@freebsd.org Wed Aug 3 11:52: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 EB3E5BAD069 for ; Wed, 3 Aug 2016 11:52:17 +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 B19EB1D9E for ; Wed, 3 Aug 2016 11:52:17 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.87 (FreeBSD)) (envelope-from ) id 1bUuie-000OQT-HK; Wed, 03 Aug 2016 13:52:16 +0200 Date: Wed, 3 Aug 2016 13:52:16 +0200 From: Kurt Jaeger To: Stefan Lambrev Cc: freebsd-current@freebsd.org Subject: Re: Wierd issues with wifi in hostap mode in FreeBSD 11 Message-ID: <20160803115216.GP96200@home.opsec.eu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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, 03 Aug 2016 11:52:18 -0000 Hi! > But wat is very strange for me is that I do not see ath0 device on ifconfig: The listing of the hardware specific interfaces, like ath0 etc was removed in 11. There's a sysctl for it now, I don't remember which one 8-( -- pi@opsec.eu +49 171 3101372 4 years to go ! From owner-freebsd-current@freebsd.org Wed Aug 3 12:03: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 0FC0BBADB9A for ; Wed, 3 Aug 2016 12:03:45 +0000 (UTC) (envelope-from me@cschwarz.com) Received: from orion.uberspace.de (orion.uberspace.de [95.143.172.79]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7F55617C3 for ; Wed, 3 Aug 2016 12:03:43 +0000 (UTC) (envelope-from me@cschwarz.com) Received: (qmail 5572 invoked from network); 3 Aug 2016 12:03:33 -0000 Received: from localhost (HELO csarch) (127.0.0.1) by orion.uberspace.de with SMTP; 3 Aug 2016 12:03:33 -0000 Date: Wed, 3 Aug 2016 14:03:31 +0200 From: Christian Schwarz To: freebsd-current@freebsd.org Subject: Re: Wierd issues with wifi in hostap mode in FreeBSD 11 Message-ID: <20160803120331.GA26444@csarch> References: <20160803115216.GP96200@home.opsec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160803115216.GP96200@home.opsec.eu> User-Agent: Mutt/1.6.2 (2016-07-01) 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, 03 Aug 2016 12:03:45 -0000 On Wed, Aug 03, 2016 at 01:52:16PM +0200, Kurt Jaeger wrote: > Hi! > > > But wat is very strange for me is that I do not see ath0 device on ifconfig: > > The listing of the hardware specific interfaces, like ath0 etc > was removed in 11. > > There's a sysctl for it now, I don't remember which one 8-( > > -- > pi@opsec.eu +49 171 3101372 4 years to go ! See freebsd-stable: > sysctl net.wlan.devices -- Christian Schwarz ---- From: Ben Woods Date: Tue, 2 Aug 2016 07:02:05 +0800 Message-ID: Subject: Release notes and handbook changes for identifying wireless adapters To: freebsd-stable@freebsd.org List-Id: Production branch of FreeBSD source code ender: owner-freebsd-stable@freebsd.org Hi, FreeBSD wireless users who are upgrading to FreeBSD 11.0 will likely get a surprise when they try and identify which wireless adapters are available in their computer by using ifconfig. Neither the FreeBSD 11 release notes or the FreeBSD handbook currently explain this change. For example, if you have an atheros wireless driver, you would previously be able to see it using ifconfig, even before configuring the wlan0 clone device. % ifconfig | grep -B3 -i wireless That was changed with commit r287197: https://svnweb.freebsd.org/base?view=revision&revision=287197 The new way to show which wireless adapter is available is: % sysctl net.wlan.devices Whilst the configuration in /etc/rc.conf required to activate a wireless adapter has not changed, people may run into the hurdle of not even finding which wireless adapter to configure in the first place. This can be seen here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203271 Regards, Ben From owner-freebsd-current@freebsd.org Wed Aug 3 12:05: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 E9787BADC88 for ; Wed, 3 Aug 2016 12:05:30 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 9D8D0194B for ; Wed, 3 Aug 2016 12:05:30 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from bach.cs.huji.ac.il ([132.65.81.13]) by kabab.cs.huji.ac.il with esmtp id 1bUuvI-000GzE-7j; Wed, 03 Aug 2016 15:05:20 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Wierd issues with wifi in hostap mode in FreeBSD 11 From: Daniel Braniss In-Reply-To: <20160803115216.GP96200@home.opsec.eu> Date: Wed, 3 Aug 2016 15:05:20 +0300 Cc: Stefan Lambrev , freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160803115216.GP96200@home.opsec.eu> To: Kurt Jaeger 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, 03 Aug 2016 12:05:31 -0000 > On 3 Aug 2016, at 14:52, Kurt Jaeger wrote: >=20 > Hi! >=20 >> But wat is very strange for me is that I do not see ath0 device on = ifconfig: >=20 > The listing of the hardware specific interfaces, like ath0 etc > was removed in 11. >=20 > There's a sysctl for it now, I don't remember which one 8-( sysctl net.wlan.devices >=20 > --=20 > pi@opsec.eu +49 171 3101372 4 years = to go ! > _______________________________________________ > 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 Wed Aug 3 14: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 21070BADB71; Wed, 3 Aug 2016 14:26:30 +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 1EAEE1A02; Wed, 3 Aug 2016 14:26:28 +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 RAA16480; Wed, 03 Aug 2016 17:26:20 +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 1bUx7k-000NAA-FN; Wed, 03 Aug 2016 17:26:20 +0300 To: FreeBSD Filesystems , FreeBSD Current From: Andriy Gapon Subject: some [big] changes to ZPL (ZFS<->VFS ) Message-ID: <3f79e88d-a519-0c8d-f16a-7c83460a37c1@FreeBSD.org> Date: Wed, 3 Aug 2016 17:25:45 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; 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: Wed, 03 Aug 2016 14:26:30 -0000 I would like to get more comments about the following review request: https://reviews.freebsd.org/D6533 Both about the code changes and about the general direction of the changes. I've been asked to try to get this change into 11.0 because of https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209158 So, there is some urgency to my request. To be honest I've never wanted to rush in this change, but I probably have been sitting on it for too long. ZFS POSIX Layer is originally written for Solaris VFS which is very different from FreeBSD VFS. Many things that FreeBSD VFS manages on behalf of all filesystems are also (re-)implemented in ZPL in a different way. As a result, ZPL contains code that is redundant on FreeBSD or duplicates VFS functionality or, in the worst cases, badly interacts / interferes with VFS. I am talking mostly about the operations that work on a filesystem namespace rather than on contents and properties of files. The former operations typically work on 2 or more vnodes. The vnodes are usually locked in a particular way or are expected to be locked in a particular way by the filesystem. ZPL on the other hand has quite an elaborate locking system of its own. It includes a lock that protects a znode, a lock that protects the znode's notion of its parent, locks that protect a name to znode relationship for the znode's children. So, we have two competing locking systems for the filesystem nodes and they are not aware of each other. The most prominent problem is a deadlock caused by the lock order reversal of vnode locks that may happen with concurrent zfs_rename() and lookup(). The deadlock is a result of zfs_rename() not observing the vnode locking contract expected by the VFS. I should mention here that VOP_RENAME is the weirdest method with respect to locking requirements. Every filesystem implementation is expected to perform quite an elaborate locking "dance" in VOP_RENAME. This is in contrast to all other operations where all necessary locking is done by the VFS before calling into the filesystem code. So, I started by fixing zfs_rename() but that required to make some changes to the "bottom half" of the ZPL (the "upper half" being the code that implements the vnode and VFS operations). And that required making changes in other VOPs anyway. And so the next step was to remove redundant re-lookup of child nodes in methods like zfs_rmdir and zfs_remove. Before I could stop I removed all ZPL internal locking that was supposed to protect parent-child relationships of filesystem nodes. Those relationships are now protected exclusively by the vnode locks and the code is changed to take advantage of that fact and to properly interact with VFS. As a minor detail, the removal of the internal locking allowed all ZPL dmu_tx_assign calls to use TXG_WAIT mode. 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. On a more general level, I decided that the upper half of ZPL would necessarily be quite different between different VFS models and so it does not make much sense to keep huge chunks of ifdef-ed out code (or compiled in, but never reached code) that's not useful in FreeBSD at all. I think that keeping that code makes it harder to maintain the FreeBSD code and to _correctly_ merge upstream changes. E.g., if a change can be merged without conflicts to an ifdef-ed out blocked, that does not mean that the merge is correct. Last, but not least, the work was sponsored by HybridCluster / ClusterHQ Inc back in 2013. -- Andriy Gapon From owner-freebsd-current@freebsd.org Wed Aug 3 15:44: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 9DAAFBAEF47 for ; Wed, 3 Aug 2016 15:44:33 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 66FFC1E59 for ; Wed, 3 Aug 2016 15:44:33 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1bUyLO-0004YT-LJ for freebsd-current@freebsd.org; Wed, 03 Aug 2016 17:44:31 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-current@freebsd.org Subject: Re: Wierd issues with wifi in hostap mode in FreeBSD 11 References: Date: Wed, 03 Aug 2016 17:44:30 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.4.0 X-Scan-Signature: e6bdf1242ae0fe6211617ef395c8efe5 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, 03 Aug 2016 15:44:33 -0000 On Wed, 03 Aug 2016 10:05:57 +0200, Stefan Lambrev wrote: > Greetings, > > > I've just installed FreeBSD 11 on Soekris net5501 with the following wifi > card: > > > root@soekris:~ # dmesg |grep ath0 > ath0: mem 0xa0010000-0xa001ffff irq 15 at device 17.0 on > pci0 > ath0: AR5413 mac 10.5 RF5413 phy 6.1 > ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0063 > > ath0@pci0:0:17:0: class=0x020000 card=0x110719b6 chip=0x001b168c > rev=0x01 hdr=0x00 > vendor = 'Qualcomm Atheros' > device = 'AR5413/AR5414 Wireless Network Adapter [AR5006X(S) > 802.11abg]' > class = network > subclass = ethernet > > > But wat is very strange for me is that I do not see ath0 device on > ifconfig: > > > root@soekris:~ # ifconfig ath0 > ifconfig: interface ath0 does not exist > > At the same time if I crate wlan0 to list caps it works: > > root@soekris:~ # ifconfig wlan0 create wlandev ath0 > root@soekris:~ # ifconfig wlan0 list caps > drivercaps=4f8defc1 > LE,MONITOR,MBSS,WPA1,WPA2,BURST,WME,WDS,TXFRAG> > cryptocaps=1f > root@soekris:~ # > > > The issues is that when I try to start wlan0 in hostap mode - FreeBSD > freezes, unfortunatelly I cannot find my serial port cable atm and cannot > see what exactly is displayed on the console but it's a hard freeze and > the > device do not reboot after it e.g. power cycle is required. > > > When configured from rc.conf it boots and do not freeze but still says > status: no carrier and hostapd complains that the device is not > configured. > > snippet from rc.conf: > > cloned_interfaces="bridge0" > wlans_ath0="wlan0" > create_args_wlan0="wlanmod hostap" > ifconfig_wlan0="ssid cheffo country bg up" Hi, I don't know how people should know, but after some mails in the past (when 11 was still CURRENT) I learned that the 'country' statement is moved to create_args_wlan0 too. I don't know about ssid. Oh!!! Cheer! The man page of ifconfig says 'The following parameters are specific to cloning IEEE 802.11 wireless interfaces with the create request:' and than has a very long list of parameters. Cheers, Ronald. > ifconfig_bridge0="addm vr0 addm vr1 addm vr2 addm vr3 addm wlan0 up" > ifconfig_bridge0_alias0="inet 10.1.1.2 netmask 255.255.255.0" > > I'm still with GENERIC kernel and there are no changes or custom cpu > optimizations done so far: > > root@soekris:~ # uname -a > FreeBSD soekris.ziops-security.org 11.0-BETA3 FreeBSD 11.0-BETA3 #0 > r303469: Fri Jul 29 04:28:58 UTC 2016 > root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC > i386 > > root@soekris:~ # cat /boot/loader.conf > dcons_load="YES" > dcons_crom="YES" > crypto_load="YES" > cryptodev_load="YES" > glxsb_load="YES" > if_bridge_load="YES" > wlan_xauth_load="YES" > > > root@soekris:~ # kldstat > Id Refs Address Size Name > 1 19 0xc0400000 1a9313c kernel > 2 1 0xc1e95000 80d4 geom_label.ko > 3 1 0xc1e9e000 bc80 if_bridge.ko > 4 2 0xc1eaa000 6ce0 bridgestp.ko > 5 1 0xc1eb1000 3a70 dcons.ko > 6 1 0xc1eb5000 5978 cryptodev.ko > 7 1 0xc1ebb000 548c glxsb.ko > 8 1 0xc1ec1000 1d6c wlan_xauth.ko > > > I have to mention that I've tried with 11-BETA2 first and there were the > same behaviour, and also I have used this soekris setup for few years > with > FreeBSD 7 and 8 for a home wifi router so I do know that the hardware is > supported and OK, as it worked rock solid just before reinstalling it > with > FreeBSD 11. > > Any advice on how to get wifi working again? > > Thanks! > _______________________________________________ > 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 Wed Aug 3 16:54: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 492D8BAE789 for ; Wed, 3 Aug 2016 16:54:33 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c: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 10F491C21 for ; Wed, 3 Aug 2016 16:54:33 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: by mail-vk0-x230.google.com with SMTP id w127so150758259vkh.2 for ; Wed, 03 Aug 2016 09:54:32 -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=rpIKf4xjK7NYK6ZkUwyNuwMFkgKBRC/1ctBSrTmkWmE=; b=jyeV57mm9vF8+02I4GzGghDfG5R9f3bYQ3KR+bAqN849jkBGP0vZvXRdRPr9C+/AEq x3z65LqkGVrE0g5pPuJhGrkkTpPmkcTNQF+ogQT6lh8mCVJZZGBacQoHxBnVQC9N0Tec rywWr2adnF3zc19qobBEdx8Rvjxo+kX6n7ByhqZTeKlG4c+WcseLsEFoKklMOR0WvH2f iRWVVoYCQ33rsO4awUFQcFWOuF0OzdcQ8cGpSA1JCrB2E2KTsUWFJKZK79uwSwB/ZVd5 JZnQM9IRYJ7xskKDmZuj4r7ujCqhb97dZaEVRNXUOqQU+oBy4a5TZ7jRM07lXjPay5Fd Y7Aw== 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=rpIKf4xjK7NYK6ZkUwyNuwMFkgKBRC/1ctBSrTmkWmE=; b=XWPOcotcKZ5Z+xuI8i/q3vJdp6BLVE4Dp1rKOHzJ9TsIGzsCE7+sZr0JdHTB8ESmKV 94YxzT+nM3FVtyrTBIWqUO8S6vDMTCHr8RrHjo8ji1FeeasP2FoeyyPySIU7qcwrp+GO oER/DQ11nyn7SdYTLmo5PDPLHkQ36W3YjUdTgx2WZ+qHB+m/X3mgoJ1FgkwO4tiTpbYe vfFSItg47RUWyksFYCxoaRcz6yiueIk1W99KhPAOz26cMK4iqt89cGUE95GuX/xbN0So STU6NVhxo7kkYdRiuP51UPA1ndiuTp+LNxYOg9V2NkZBKkFqCB4zBO8JR8qjtm2wULu+ ADRw== X-Gm-Message-State: AEkoousV+I9ofHhtIavD80uXsidPQXgP7sG9BXCVs4q6Rr9Ybz9ApM60KUOQcMzbULvPnIaijXKXaN7/o/Ad/YZmCnSX10BNdSfV4m6Nc2ErafAP3Tg9hFOhDOY4iO5Fi2aHuX1YoNNiukBucU01R954Fdk= X-Received: by 10.31.93.129 with SMTP id r123mr33910115vkb.149.1470243271019; Wed, 03 Aug 2016 09:54:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.38.132 with HTTP; Wed, 3 Aug 2016 09:54:15 -0700 (PDT) From: "Lundberg, Johannes" Date: Wed, 3 Aug 2016 09:54:15 -0700 Message-ID: Subject: Socket sendmsg() porting question 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: Wed, 03 Aug 2016 16:54:33 -0000 SGkNCg0KSSdtIHBvcnRpbmcgYSBwcm9qZWN0IHRvIGZic2QgYW5kIEkgaGF2ZSBwcm9ibGVtIHdp dGggdGhpcyBwYXJ0IHRoYXQgd29ya3MNCmluIGxpbnV4IGJ1dCBub3QgZmJzZCB3aGVuIGZkID0g LTEuDQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9DbG91ZGVmL3dsYy9ibG9iL21hc3Rlci9zcmMvc2Vz c2lvbi9mZC5jI0w4MC1MMTA4DQoNCkkgZ2V0ICJpbnZhbGlkIGFyZ3VtZW50IiBmcm9tIHNlbmRt c2coKSB3aGVuIHNldHRpbmcgQ01TR19MRU4oMCkuDQoNCkFueW9uZSBoYXZlIGEgY2x1ZSBob3cg dG8gY29ycmVjdGx5IGRvIHRoaXMgb24gZmJzZD8NCg0KVGhhbmtzIQ0KDQpKb2hhbm5lcw0KCi0t IAo9LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS0K 56eY5a+G5L+d5oyB44Gr44Gk44GE44Gm77ya44GT44Gu6Zu75a2Q44Oh44O844Or44Gv44CB5ZCN 5a6b5Lq644Gr6YCB5L+h44GX44Gf44KC44Gu44Gn44GC44KK44CB56eY5Yy/54m55qip44Gu5a++ 6LGh44Go44Gq44KL5oOF5aCx44KS5ZCr44KT44Gn44GE44G+44GZ44CCCuOCguOBl+OAgeWQjeWu m+S6uuS7peWkluOBruaWueOBjOWPl+S/oeOBleOCjOOBn+WgtOWQiOOAgeOBk+OBruODoeODvOOD q+OBruegtOajhOOAgeOBiuOCiOOBs+OBk+OBruODoeODvOODq+OBq+mWouOBmeOCi+S4gOWIh+OB rumWi+ekuuOAgQropIflhpnjgIHphY3luIPjgIHjgZ3jga7ku5bjga7liKnnlKjjgIHjgb7jgZ/j ga/oqJjovInlhoXlrrnjgavln7rjgaXjgY/jgYTjgYvjgarjgovooYzli5XjgoLjgZXjgozjgarj gYTjgojjgYbjgYrpoZjjgYTnlLPjgZfkuIrjgZLjgb7jgZnjgIIKLS0tCkNPTkZJREVOVElBTElU WSBOT1RFOiBUaGUgaW5mb3JtYXRpb24gaW4gdGhpcyBlbWFpbCBpcyBjb25maWRlbnRpYWwKYW5k IGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZS4KRGlzY2xvc3VyZSwgY29weWluZywg ZGlzdHJpYnV0aW9uIG9yIGFueSBvdGhlciBhY3Rpb24gb2YgdXNlIG9mIHRoaXMKZW1haWwgYnkg cGVyc29uIG90aGVyIHRoYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBpcyBwcm9oaWJpdGVkLgpJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGFuZCBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4KZXJyb3IsIHBsZWFzZSBkZXN0cm95IHRoZSBvcmlnaW5hbCBtZXNzYWdlLgo= From owner-freebsd-current@freebsd.org Wed Aug 3 17:12:23 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5C221BAEE97 for ; Wed, 3 Aug 2016 17:12:23 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003: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 1E0161C5C for ; Wed, 3 Aug 2016 17:12:23 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi0-x229.google.com with SMTP id l65so289231870oib.1 for ; Wed, 03 Aug 2016 10:12:23 -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=KT13Eor/+WJc7SZP+nZXfczOdnGbXRbbCisR5kPbtH4=; b=gK8Lqt7s+BH0HY0/R2oGf5ynsqCCPWTcKUNP7Fg9tCGqN++InT51UBHFV2GuUOmdj6 W1aF+tkK/51EbC5zMSfxNVKl0ajEO1gnB8oExBdCvF58rI5oSXtwcOPqe+Ri92K0RpGG Z7X8EZK2nflW/tY45lVaMf2a9n84hSjLyh5PUJd+fQGUMr6U2LhD0Dt75AS2vW4RXML9 lqcNc1pRpL4ZL7ry+J5EQ9sWJypw4wXG1fULIhoDsaAWF8WQTA5p36uqE9swyWils4MH 7kR2l7/j+F2W7A+83y+5K2VcQri021JYkcxvSJ+gXwQpeeSV368CpfQoJFumaivcU6vK v5+g== 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=KT13Eor/+WJc7SZP+nZXfczOdnGbXRbbCisR5kPbtH4=; b=LM+Sdw3MY3AH9emAGszRDPsfM9A1LUMeWJpUNd/+0HagykBoYu5fnI0zFPusfofyvX p6qNB7GDux2kU68bPaWVSVemzsg63nMptBov2Y95aM9EXTQ5VXY0+veH7Wr+qHvYiTrO aUU59q1fmRKGFKb+21l0PBq06g1CEcrKiAvgxc63gcF+o/SdkdqhkRO6m3dPcdM80mFG poofLdUZ1RPOzFNZoiQb3loAaDOB/AXBnqToPc6FMLevqSm7bMQsZsDtmwTDYv5VVvQr bfVZF9hfv5+tc9yD8xMxKBCQpS8FiAEIPNB+ax97WQC7Q+8jyI1MMHIvzAkEHdRI+dax RNKg== X-Gm-Message-State: AEkoouvYOyFNlRdAh+jgRyDAujMYc/Rg+0iK4WW2tHI6I2e/G9PpjkPq1CIJDgUHFtBnHjz50jcIi/08BnPvdA== X-Received: by 10.202.0.80 with SMTP id 77mr1631744oia.173.1470244342432; Wed, 03 Aug 2016 10:12:22 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.202.196.149 with HTTP; Wed, 3 Aug 2016 10:12:21 -0700 (PDT) In-Reply-To: References: From: Alan Somers Date: Wed, 3 Aug 2016 11:12:21 -0600 X-Google-Sender-Auth: QrNcQN2Y4cVF8IfQ1s-yHWEkv4I Message-ID: Subject: Re: Socket sendmsg() porting question To: "Lundberg, Johannes" Cc: 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: Wed, 03 Aug 2016 17:12:23 -0000 On Wed, Aug 3, 2016 at 10:54 AM, Lundberg, Johannes wrote: > Hi > > I'm porting a project to fbsd and I have problem with this part that works > in linux but not fbsd when fd = -1. > > https://github.com/Cloudef/wlc/blob/master/src/session/fd.c#L80-L108 > > I get "invalid argument" from sendmsg() when setting CMSG_LEN(0). > > Anyone have a clue how to correctly do this on fbsd? > > Thanks! > > Johannes > It sounds like you're trying to send an empty cmsg. The error may happen because your msg_controllen field is inconsistent with your cmsg_len field. You're setting msg_controllen as if there were a full cmsg, but then cmsg_len says that there is no cmsg. Or maybe the error is because (just guessing) FreeBSD doesn't allow sending empty or undefined cmsgs. Notice that cmsg_level and cmsg_type are undefined in the case where fd == -1. POSIX doesn't say whether sendmsg supports empty cmsgs, but why bother? You could just use send instead of sendmsg if you're not sending a file descriptor. -Alan From owner-freebsd-current@freebsd.org Wed Aug 3 17:18: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 47EC8BAD0A3 for ; Wed, 3 Aug 2016 17:18:39 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::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 F0ADE1237 for ; Wed, 3 Aug 2016 17:18:38 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: by mail-vk0-x229.google.com with SMTP id n129so150498853vke.3 for ; Wed, 03 Aug 2016 10:18:38 -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=FONgSy11vPG6VGqfSWVsOyjaSiqgRnvfcSdDeS/Gz+Q=; b=cL3FJ6zEPZqFnmzv6rquHq3ZzIq5dKWGAoD36XTmata8J/Os4usndYJyK1VYqIZ7dE Ibw9ttQYjmY9Cg/gRsrwe9U2TIK56meeDgGzXuexVwsv7d45pedy/8xAf8IySQDxVRwd 919Hx3er+FXzLppmozQvmC2CFjehNSLUybXJmLLMNFdPrLD+YdDuOxiU27iYYYkE3ukf POw/Fujlf6DvcraoBAtWGheaBmDcRdz+Hmi3rt1G66yr21q0NIStmJvt1VfDC1ay041E jJC9Qx9OIzXMXVEojZeymLfANJU0JGvhPiss7h8otjY0NLbzt3+wRM898iNanwWrobgY GC1w== 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=FONgSy11vPG6VGqfSWVsOyjaSiqgRnvfcSdDeS/Gz+Q=; b=b+gv5dCvlj3+LLkkHmL5UpJ86vaYo6hTx4y+qTal5jmMPrhszq5srtXxdphVSv1ljo BXhA0vQ35uWNjzaOT1jzWGFmihNLV9H2w6qZqV04gHv+46HtbUdOEIXmmRSxRHt4khVF pv3XPtGG/wRCcD3cTHYR7fEzmRv6dJ+Y2g+cZXl8tHIcCoLblZjwIBQX3eKO50XJ5W4q rYjNK6lofbtalcsFLPUXJ/Hf2v+ERTP74+dfnzb7j3H/z3ZmQsMqSwrE9wko4w3SA21P ubv8KvxWoNTYAN/nI83Y78tuDw/XMU2WlRqHQHLayGOvSTXlVaEtx3sVyLJZk6vAeAXl Ittg== X-Gm-Message-State: AEkoouum+OA9McNfcYHHymMWBKRi8SJpeKocXfexgfRefZ44YtgkdrOBHNwiU0NQ1eWuq8P5PERPXr7IpeMrX3DFQtSTV7C6f8Vbr5Kmnn1Iyv05WbMv+oKJ2L/Qb0jM2TOA6a8g/prABJQ98URwZqsdng4= X-Received: by 10.31.61.15 with SMTP id k15mr34449527vka.105.1470244717975; Wed, 03 Aug 2016 10:18:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.38.132 with HTTP; Wed, 3 Aug 2016 10:18:22 -0700 (PDT) In-Reply-To: References: From: "Lundberg, Johannes" Date: Wed, 3 Aug 2016 10:18:22 -0700 Message-ID: Subject: Re: Socket sendmsg() porting question To: Alan Somers 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: Wed, 03 Aug 2016 17:18:39 -0000 4oCLSGkgQWxhbg0KDQpUaGFua3MgZm9yIHRoZSByZXBseS4NCg0KQ2FuIEkgc3RpbGwgdXNlIHRo ZSBzYW1lIHJlY2VpdmluZyBmdW5jdGlvbiBmb3Igc2VuZG1zZy9zZW5kIGFuZCB0ZWxsIHdoYXQN CmtpbmQgb2YgbWVzc2FnZSBpcyBjb21pbmc/DQpIb3cgd291bGQgSSB0ZWxsIGlmIHRoZXJlIGlz IGFuIGZkIGF0dGFjaGVkIG9yIG5vdD8NCg0KRXZlbiBpZiBJIHNldCBjbXNnX2xldmVsIGFuZCBj bXNnX3R5cGUgaXQgd29uJ3QgbGV0IG1lIHNlbmQgaXQuIFRoZSBwcm9ibGVtDQppcyBoYXZpbmcg YSB6ZXJvIGxlbmd0aCBhdHRhY2htZW50IG9uIGZyZWVic2QuLi4uDQpJIGNhbid0IHNlbmQgLTEg YXMgZmQgYmVjYXVzZSB0aGF0IGVycm9ycyB0byBpbnZhbGlkIGZpbGUgZGVzY3JpcHRvci4NCg0K DQpPbiBXZWQsIEF1ZyAzLCAyMDE2IGF0IDEwOjEyIEFNLCBBbGFuIFNvbWVycyA8YXNvbWVyc0Bm cmVlYnNkLm9yZz4gd3JvdGU6DQoNCj4gT24gV2VkLCBBdWcgMywgMjAxNiBhdCAxMDo1NCBBTSwg THVuZGJlcmcsIEpvaGFubmVzDQo+IDxqb2hhbm5lc0BicmlsbGlhbnRzZXJ2aWNlLmNvLmpwPiB3 cm90ZToNCj4gPiBIaQ0KPiA+DQo+ID4gSSdtIHBvcnRpbmcgYSBwcm9qZWN0IHRvIGZic2QgYW5k IEkgaGF2ZSBwcm9ibGVtIHdpdGggdGhpcyBwYXJ0IHRoYXQNCj4gd29ya3MNCj4gPiBpbiBsaW51 eCBidXQgbm90IGZic2Qgd2hlbiBmZCA9IC0xLg0KPiA+DQo+ID4gaHR0cHM6Ly9naXRodWIuY29t L0Nsb3VkZWYvd2xjL2Jsb2IvbWFzdGVyL3NyYy9zZXNzaW9uL2ZkLmMjTDgwLUwxMDgNCj4gPg0K PiA+IEkgZ2V0ICJpbnZhbGlkIGFyZ3VtZW50IiBmcm9tIHNlbmRtc2coKSB3aGVuIHNldHRpbmcg Q01TR19MRU4oMCkuDQo+ID4NCj4gPiBBbnlvbmUgaGF2ZSBhIGNsdWUgaG93IHRvIGNvcnJlY3Rs eSBkbyB0aGlzIG9uIGZic2Q/DQo+ID4NCj4gPiBUaGFua3MhDQo+ID4NCj4gPiBKb2hhbm5lcw0K PiA+DQo+DQo+IEl0IHNvdW5kcyBsaWtlIHlvdSdyZSB0cnlpbmcgdG8gc2VuZCBhbiBlbXB0eSBj bXNnLiAgVGhlIGVycm9yIG1heQ0KPiBoYXBwZW4gYmVjYXVzZSB5b3VyIG1zZ19jb250cm9sbGVu IGZpZWxkIGlzIGluY29uc2lzdGVudCB3aXRoIHlvdXINCj4gY21zZ19sZW4gZmllbGQuICBZb3Un cmUgc2V0dGluZyBtc2dfY29udHJvbGxlbiBhcyBpZiB0aGVyZSB3ZXJlIGEgZnVsbA0KPiBjbXNn LCBidXQgIHRoZW4gY21zZ19sZW4gc2F5cyB0aGF0IHRoZXJlIGlzIG5vIGNtc2cuICBPciBtYXli ZSB0aGUNCj4gZXJyb3IgaXMgYmVjYXVzZSAoanVzdCBndWVzc2luZykgRnJlZUJTRCBkb2Vzbid0 IGFsbG93IHNlbmRpbmcgZW1wdHkNCj4gb3IgdW5kZWZpbmVkIGNtc2dzLiAgTm90aWNlIHRoYXQg Y21zZ19sZXZlbCBhbmQgY21zZ190eXBlIGFyZQ0KPiB1bmRlZmluZWQgaW4gdGhlIGNhc2Ugd2hl cmUgZmQgPT0gLTEuICBQT1NJWCBkb2Vzbid0IHNheSB3aGV0aGVyDQo+IHNlbmRtc2cgc3VwcG9y dHMgZW1wdHkgY21zZ3MsIGJ1dCB3aHkgYm90aGVyPyAgWW91IGNvdWxkIGp1c3QgdXNlIHNlbmQN Cj4gaW5zdGVhZCBvZiBzZW5kbXNnIGlmIHlvdSdyZSBub3Qgc2VuZGluZyBhIGZpbGUgZGVzY3Jp cHRvci4NCj4NCj4gLUFsYW4NCj4NCgotLSAKPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0t PS09LT0tPS09LT0tPS09LT0tPS09LT0tCuenmOWvhuS/neaMgeOBq+OBpOOBhOOBpu+8muOBk+OB rumbu+WtkOODoeODvOODq+OBr+OAgeWQjeWum+S6uuOBq+mAgeS/oeOBl+OBn+OCguOBruOBp+OB guOCiuOAgeenmOWMv+eJueaoqeOBruWvvuixoeOBqOOBquOCi+aDheWgseOCkuWQq+OCk+OBp+OB hOOBvuOBmeOAggrjgoLjgZfjgIHlkI3lrpvkurrku6XlpJbjga7mlrnjgYzlj5fkv6HjgZXjgozj gZ/loLTlkIjjgIHjgZPjga7jg6Hjg7zjg6vjga7noLTmo4TjgIHjgYrjgojjgbPjgZPjga7jg6Hj g7zjg6vjgavplqLjgZnjgovkuIDliIfjga7plovnpLrjgIEK6KSH5YaZ44CB6YWN5biD44CB44Gd 44Gu5LuW44Gu5Yip55So44CB44G+44Gf44Gv6KiY6LyJ5YaF5a6544Gr5Z+644Gl44GP44GE44GL 44Gq44KL6KGM5YuV44KC44GV44KM44Gq44GE44KI44GG44GK6aGY44GE55Sz44GX5LiK44GS44G+ 44GZ44CCCi0tLQpDT05GSURFTlRJQUxJVFkgTk9URTogVGhlIGluZm9ybWF0aW9uIGluIHRoaXMg ZW1haWwgaXMgY29uZmlkZW50aWFsCmFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNz ZWUuCkRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciBhbnkgb3RoZXIgYWN0aW9u IG9mIHVzZSBvZiB0aGlzCmVtYWlsIGJ5IHBlcnNvbiBvdGhlciB0aGFuIGludGVuZGVkIHJlY2lw aWVudCwgaXMgcHJvaGliaXRlZC4KSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCBhbmQgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluCmVycm9yLCBwbGVhc2UgZGVzdHJveSB0 aGUgb3JpZ2luYWwgbWVzc2FnZS4K From owner-freebsd-current@freebsd.org Wed Aug 3 17:28: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 5B049BAD317; Wed, 3 Aug 2016 17:28:57 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 34EE81836; Wed, 3 Aug 2016 17:28:57 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:To:From:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=pRrANeZKtBMoF9HMh/UHYUgUxrMBFw7bMjtRq90gbQ0=; b=Gff+KJEXbgrkykzioDQeaCxcrd 6MOxByRo4NPloRHo1HmIsjsgnx7jIseuYMGF9N61GaDs8LhrLiyiLUFAr0MGPiCqwDLjPKTDMpLhR Vo5aLR2noB2x1onxL4hKbkgoEjIuVfUReM32u+kA/B2RIa2pZaOClBpX6Gi3egWMjSKo=; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]:60851) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1bUzyR-0007tC-Mj; Wed, 03 Aug 2016 12:28:56 -0500 Date: Wed, 3 Aug 2016 12:28:54 -0500 From: Larry Rosenman To: Adrian Chadd , Imre Vad??sz , Andriy Voskoboinyk , "freebsd-wireless@freebsd.org" , freebsd-current , owner-freebsd-current@freebsd.org Subject: Re: IWM(7260), no connect Message-ID: <20160803172854.GA30265@thebighonker.lerctr.org> Mail-Followup-To: Adrian Chadd , Imre Vad??sz , Andriy Voskoboinyk , "freebsd-wireless@freebsd.org" , freebsd-current , owner-freebsd-current@freebsd.org References: <20160728023954.GA1321@pita> <20160728233504.GA1226@pita> <4ee03d28cc2711ed9bc56a725cac344a@thebighonker.lerctr.org> <20160801013647.GA1294@pita> <20160801021902.GA1998@pita> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160801021902.GA1998@pita> 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, 03 Aug 2016 17:28:57 -0000 Anyone? On Sun, Jul 31, 2016 at 09:19:02PM -0500, Larry Rosenman wrote: > I recompiled security/wpa_supplicant and seem to be able to get > associated. > > I'm not sure what is going on. > > Any suggestions? > > On Sun, Jul 31, 2016 at 08:36:47PM -0500, Larry Rosenman wrote: > > Even with that reverted, I'm still having iffy connections. > > > > Current code: > > > > FreeBSD pita 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r303597M: Sun Jul 31 16:02:39 CDT 2016 root@pita:/usr/obj/usr/src/sys/IWM-DEBUG amd64 1200001 1200001 > > > > Current diff to that SVN Rev: > > > > Index: sys/dev/iwm/if_iwm.c > > =================================================================== > > --- sys/dev/iwm/if_iwm.c (revision 303597) > > +++ sys/dev/iwm/if_iwm.c (working copy) > > @@ -3357,15 +3357,12 @@ > > uint8_t subtype = wh->i_fc[0] & IEEE80211_FC0_SUBTYPE_MASK; > > > > if (subtype == IEEE80211_FC0_SUBTYPE_ASSOC_REQ || > > - subtype == IEEE80211_FC0_SUBTYPE_REASSOC_REQ) { > > - tx->pm_frame_timeout = htole16(IWM_PM_FRAME_ASSOC); > > - } else if (subtype == IEEE80211_FC0_SUBTYPE_ACTION) { > > - tx->pm_frame_timeout = htole16(IWM_PM_FRAME_NONE); > > - } else { > > - tx->pm_frame_timeout = htole16(IWM_PM_FRAME_MGMT); > > - } > > + subtype == IEEE80211_FC0_SUBTYPE_REASSOC_REQ) > > + tx->pm_frame_timeout = htole16(3); > > + else > > + tx->pm_frame_timeout = htole16(2); > > } else { > > - tx->pm_frame_timeout = htole16(IWM_PM_FRAME_NONE); > > + tx->pm_frame_timeout = htole16(0); > > } > > > > if (hdrlen & 3) { > > Index: sys/dev/iwm/if_iwmreg.h > > =================================================================== > > --- sys/dev/iwm/if_iwmreg.h (revision 303597) > > +++ sys/dev/iwm/if_iwmreg.h (working copy) > > @@ -4244,18 +4244,6 @@ > > IWM_TX_CMD_FLG_HCCA_CHUNK = (1 << 31) > > }; /* IWM_TX_FLAGS_BITS_API_S_VER_1 */ > > > > -/** > > - * enum iwm_tx_pm_timeouts - pm timeout values in TX command > > - * @IWM_PM_FRAME_NONE: no need to suspend sleep mode > > - * @IWM_PM_FRAME_MGMT: fw suspend sleep mode for 100TU > > - * @IWM_PM_FRAME_ASSOC: fw suspend sleep mode for 10sec > > - */ > > -enum iwm_tx_pm_timeouts { > > - IWM_PM_FRAME_NONE = 0, > > - IWM_PM_FRAME_MGMT = 2, > > - IWM_PM_FRAME_ASSOC = 3, > > -}; > > - > > /* > > * TX command security control > > */ > > > > > > > > Scan Debug: > > http://www.lerctr.org/~ler/FreeBSD/WIFI-Scan.txt > > > > What next? > > > > On Thu, Jul 28, 2016 at 06:06:47PM -0700, Adrian Chadd wrote: > > > +imre, > > > > > > Hi! Larry is having issues with r303418. Would you be able to help him out? > > > > > > (If it's not too bad, can we back this out until you figure out what's > > > going on?) > > > > > > Thanks! > > > > > > > > > -a > > > > > > > > > On 28 July 2016 at 18:05, Larry Rosenman wrote: > > > > On 2016-07-28 20:02, Adrian Chadd wrote: > > > >> > > > >> Hi, > > > >> > > > >> Which commit(s) did you revert? > > > >> > > > >> > > > >> > > > >> -a > > > > > > > > > > > > revert r303418 > > > > > > > > and now it connects again. > > > > > > > > > > > > -- > > > > Larry Rosenman http://www.lerctr.org/~ler > > > > Phone: +1 214-642-9640 E-Mail: ler@lerctr.org > > > > US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 > > > > -- > > Larry Rosenman http://www.lerctr.org/~ler > > Phone: +1 214-642-9640 E-Mail: ler@lerctr.org > > US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 > > -- > Larry Rosenman http://www.lerctr.org/~ler > Phone: +1 214-642-9640 E-Mail: ler@lerctr.org > US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 From owner-freebsd-current@freebsd.org Wed Aug 3 17:36:18 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5A6EABAD576; Wed, 3 Aug 2016 17:36:18 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 220051D64; Wed, 3 Aug 2016 17:36:18 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x22a.google.com with SMTP id m101so249688352ioi.2; Wed, 03 Aug 2016 10:36:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=0KO+31uu85z/Vy05Ot64xaa82Q+ds0O+qwbyXWmOZR4=; b=sOcUtOPLToFVBOvuirv1IGKAnkOoWvMYPMOQJl47tKI1+5ezAB7z3V9utJA01qHELz HwvsLTlNEX4FiVh6gjw41Tj0PFm7am0+DkbSl/KOb6gCLhZ+ZbsyUPbgcHQSUQbiYCfR WQVhxIuLYLxkgZzLmX5qzwzdW7M/eOimnZL139Jp7Sgnq6mxYkOVNGEEaVMLPzRxtVgv ORiGZ2yTKVyac9gDUsYf+eBKqLHzqj4b+v/qC6Ea0FCtiVLatR0RJYnCe5y6LMI+zYeM HgEGcVhRXW7c/GwzS+wy7WwNDXmpArB3LeduhBrHeDrAHiGpNYkKh67NQCJdoSvtGwsu ySzw== 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; bh=0KO+31uu85z/Vy05Ot64xaa82Q+ds0O+qwbyXWmOZR4=; b=mGO1hAtADfw0QfZywcBV4xfym2xs68VgJPHeevlPA1yuexmiaHqwFeEoxX4S+NQtfF 0eC9a+mh28ZhiAZv9THwrhBfOMGinrUCmfP57PCxDXjLDOYBOeJfaPtjAQZDOA8nz2VI ISqW9sGp3vi7G/cEgh6Gs9NtbG8jyMhi9pZxVypO+FTsZrTmbEMR6I9azf65ow6IA8PR Hp2lJDA1dVWTzp2LXJL5Flg3gD14O4yrCfNc2pvmGwvdlYHLUbf1FK6bpt8+vi0HjgxA DgFdGeHKeqqjbGL45ZCiq2wv0Ak1s7P1j8G93VzFFX054dpPEgrzl1L6xPXfzkbpn0QF QgTQ== X-Gm-Message-State: AEkoouuflpwo0fmLXglpW5VDQ3zRnjT+EfOBCx9AfH2GxjfsF7hp/f/treMVeI4xae6vG3qLJ1fIaMfmYnVWjQ== X-Received: by 10.107.144.10 with SMTP id s10mr65908331iod.165.1470245777436; Wed, 03 Aug 2016 10:36:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.141.129 with HTTP; Wed, 3 Aug 2016 10:36:16 -0700 (PDT) In-Reply-To: <20160803172854.GA30265@thebighonker.lerctr.org> References: <20160728023954.GA1321@pita> <20160728233504.GA1226@pita> <4ee03d28cc2711ed9bc56a725cac344a@thebighonker.lerctr.org> <20160801013647.GA1294@pita> <20160801021902.GA1998@pita> <20160803172854.GA30265@thebighonker.lerctr.org> From: Adrian Chadd Date: Wed, 3 Aug 2016 10:36:16 -0700 Message-ID: Subject: Re: IWM(7260), no connect To: Adrian Chadd , "Imre Vad??sz" , Andriy Voskoboinyk , "freebsd-wireless@freebsd.org" , freebsd-current , owner-freebsd-current@freebsd.org 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: Wed, 03 Aug 2016 17:36:18 -0000 I've no idea, sorry. :( Imre's out for another week, so let him finish his holiday first. :) -a On 3 August 2016 at 10:28, Larry Rosenman wrote: > Anyone? > On Sun, Jul 31, 2016 at 09:19:02PM -0500, Larry Rosenman wrote: >> I recompiled security/wpa_supplicant and seem to be able to get >> associated. >> >> I'm not sure what is going on. >> >> Any suggestions? >> >> On Sun, Jul 31, 2016 at 08:36:47PM -0500, Larry Rosenman wrote: >> > Even with that reverted, I'm still having iffy connections. >> > >> > Current code: >> > >> > FreeBSD pita 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r303597M: Sun Jul 31 16:02:39 CDT 2016 root@pita:/usr/obj/usr/src/sys/IWM-DEBUG amd64 1200001 1200001 >> > >> > Current diff to that SVN Rev: >> > >> > Index: sys/dev/iwm/if_iwm.c >> > =================================================================== >> > --- sys/dev/iwm/if_iwm.c (revision 303597) >> > +++ sys/dev/iwm/if_iwm.c (working copy) >> > @@ -3357,15 +3357,12 @@ >> > uint8_t subtype = wh->i_fc[0] & IEEE80211_FC0_SUBTYPE_MASK; >> > >> > if (subtype == IEEE80211_FC0_SUBTYPE_ASSOC_REQ || >> > - subtype == IEEE80211_FC0_SUBTYPE_REASSOC_REQ) { >> > - tx->pm_frame_timeout = htole16(IWM_PM_FRAME_ASSOC); >> > - } else if (subtype == IEEE80211_FC0_SUBTYPE_ACTION) { >> > - tx->pm_frame_timeout = htole16(IWM_PM_FRAME_NONE); >> > - } else { >> > - tx->pm_frame_timeout = htole16(IWM_PM_FRAME_MGMT); >> > - } >> > + subtype == IEEE80211_FC0_SUBTYPE_REASSOC_REQ) >> > + tx->pm_frame_timeout = htole16(3); >> > + else >> > + tx->pm_frame_timeout = htole16(2); >> > } else { >> > - tx->pm_frame_timeout = htole16(IWM_PM_FRAME_NONE); >> > + tx->pm_frame_timeout = htole16(0); >> > } >> > >> > if (hdrlen & 3) { >> > Index: sys/dev/iwm/if_iwmreg.h >> > =================================================================== >> > --- sys/dev/iwm/if_iwmreg.h (revision 303597) >> > +++ sys/dev/iwm/if_iwmreg.h (working copy) >> > @@ -4244,18 +4244,6 @@ >> > IWM_TX_CMD_FLG_HCCA_CHUNK = (1 << 31) >> > }; /* IWM_TX_FLAGS_BITS_API_S_VER_1 */ >> > >> > -/** >> > - * enum iwm_tx_pm_timeouts - pm timeout values in TX command >> > - * @IWM_PM_FRAME_NONE: no need to suspend sleep mode >> > - * @IWM_PM_FRAME_MGMT: fw suspend sleep mode for 100TU >> > - * @IWM_PM_FRAME_ASSOC: fw suspend sleep mode for 10sec >> > - */ >> > -enum iwm_tx_pm_timeouts { >> > - IWM_PM_FRAME_NONE = 0, >> > - IWM_PM_FRAME_MGMT = 2, >> > - IWM_PM_FRAME_ASSOC = 3, >> > -}; >> > - >> > /* >> > * TX command security control >> > */ >> > >> > >> > >> > Scan Debug: >> > http://www.lerctr.org/~ler/FreeBSD/WIFI-Scan.txt >> > >> > What next? >> > >> > On Thu, Jul 28, 2016 at 06:06:47PM -0700, Adrian Chadd wrote: >> > > +imre, >> > > >> > > Hi! Larry is having issues with r303418. Would you be able to help him out? >> > > >> > > (If it's not too bad, can we back this out until you figure out what's >> > > going on?) >> > > >> > > Thanks! >> > > >> > > >> > > -a >> > > >> > > >> > > On 28 July 2016 at 18:05, Larry Rosenman wrote: >> > > > On 2016-07-28 20:02, Adrian Chadd wrote: >> > > >> >> > > >> Hi, >> > > >> >> > > >> Which commit(s) did you revert? >> > > >> >> > > >> >> > > >> >> > > >> -a >> > > > >> > > > >> > > > revert r303418 >> > > > >> > > > and now it connects again. >> > > > >> > > > >> > > > -- >> > > > Larry Rosenman http://www.lerctr.org/~ler >> > > > Phone: +1 214-642-9640 E-Mail: ler@lerctr.org >> > > > US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 >> > >> > -- >> > Larry Rosenman http://www.lerctr.org/~ler >> > Phone: +1 214-642-9640 E-Mail: ler@lerctr.org >> > US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 >> >> -- >> Larry Rosenman http://www.lerctr.org/~ler >> Phone: +1 214-642-9640 E-Mail: ler@lerctr.org >> US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 > > -- > Larry Rosenman http://www.lerctr.org/~ler > Phone: +1 214-642-9640 E-Mail: ler@lerctr.org > US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 From owner-freebsd-current@freebsd.org Wed Aug 3 17:41: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 A7A12BAD6A7; Wed, 3 Aug 2016 17:41:19 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8162A11E6; Wed, 3 Aug 2016 17:41:19 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date: Content-Transfer-Encoding:Content-Type:MIME-Version:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=iRST4J8XSDYkt2FL/PFHnfxOMWWXFXjuHoH3tPtZovM=; b=SQ9k+5EJyStZLDNklA0FNISAfm 7PcbcXj1UQHvx7BkKlHUySZ00dj4hdotJuudfk+pveVPu2ij9YHWCMB3R4E/fBIo2Kb4eM9lhQ8IA m3IZh6jxuLQwrP3njbYJQmMQtSQL/vOoJ1GKUvcPZ7Ja4wu7uphB0IFvO0FLn3ePSAL4=; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]:54395 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1bV0AQ-0008K8-P4; Wed, 03 Aug 2016 12:41:18 -0500 Received: from proxy.na.alcatel-lucent.com ([135.245.48.72]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Wed, 03 Aug 2016 12:41:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 03 Aug 2016 12:41:18 -0500 From: Larry Rosenman To: Adrian Chadd Cc: Imre Vad??sz , Andriy Voskoboinyk , freebsd-wireless@freebsd.org, freebsd-current , owner-freebsd-current@freebsd.org Subject: Re: IWM(7260), no connect In-Reply-To: References: <20160728023954.GA1321@pita> <20160728233504.GA1226@pita> <4ee03d28cc2711ed9bc56a725cac344a@thebighonker.lerctr.org> <20160801013647.GA1294@pita> <20160801021902.GA1998@pita> <20160803172854.GA30265@thebighonker.lerctr.org> Message-ID: <0fa5c63f757644782ee8fcf55056344c@thebighonker.lerctr.org> X-Sender: ler@lerctr.org 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: Wed, 03 Aug 2016 17:41:19 -0000 I didn't (realize|know) Imre was on vacation. Thanks Adrian! On 2016-08-03 12:36, Adrian Chadd wrote: > I've no idea, sorry. :( > > Imre's out for another week, so let him finish his holiday first. :) > > > -a > > > On 3 August 2016 at 10:28, Larry Rosenman wrote: >> Anyone? >> On Sun, Jul 31, 2016 at 09:19:02PM -0500, Larry Rosenman wrote: >>> I recompiled security/wpa_supplicant and seem to be able to get >>> associated. >>> >>> I'm not sure what is going on. >>> >>> Any suggestions? >>> >>> On Sun, Jul 31, 2016 at 08:36:47PM -0500, Larry Rosenman wrote: >>> > Even with that reverted, I'm still having iffy connections. >>> > >>> > Current code: >>> > >>> > FreeBSD pita 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r303597M: Sun Jul 31 16:02:39 CDT 2016 root@pita:/usr/obj/usr/src/sys/IWM-DEBUG amd64 1200001 1200001 >>> > >>> > Current diff to that SVN Rev: >>> > >>> > Index: sys/dev/iwm/if_iwm.c >>> > =================================================================== >>> > --- sys/dev/iwm/if_iwm.c (revision 303597) >>> > +++ sys/dev/iwm/if_iwm.c (working copy) >>> > @@ -3357,15 +3357,12 @@ >>> > uint8_t subtype = wh->i_fc[0] & IEEE80211_FC0_SUBTYPE_MASK; >>> > >>> > if (subtype == IEEE80211_FC0_SUBTYPE_ASSOC_REQ || >>> > - subtype == IEEE80211_FC0_SUBTYPE_REASSOC_REQ) { >>> > - tx->pm_frame_timeout = htole16(IWM_PM_FRAME_ASSOC); >>> > - } else if (subtype == IEEE80211_FC0_SUBTYPE_ACTION) { >>> > - tx->pm_frame_timeout = htole16(IWM_PM_FRAME_NONE); >>> > - } else { >>> > - tx->pm_frame_timeout = htole16(IWM_PM_FRAME_MGMT); >>> > - } >>> > + subtype == IEEE80211_FC0_SUBTYPE_REASSOC_REQ) >>> > + tx->pm_frame_timeout = htole16(3); >>> > + else >>> > + tx->pm_frame_timeout = htole16(2); >>> > } else { >>> > - tx->pm_frame_timeout = htole16(IWM_PM_FRAME_NONE); >>> > + tx->pm_frame_timeout = htole16(0); >>> > } >>> > >>> > if (hdrlen & 3) { >>> > Index: sys/dev/iwm/if_iwmreg.h >>> > =================================================================== >>> > --- sys/dev/iwm/if_iwmreg.h (revision 303597) >>> > +++ sys/dev/iwm/if_iwmreg.h (working copy) >>> > @@ -4244,18 +4244,6 @@ >>> > IWM_TX_CMD_FLG_HCCA_CHUNK = (1 << 31) >>> > }; /* IWM_TX_FLAGS_BITS_API_S_VER_1 */ >>> > >>> > -/** >>> > - * enum iwm_tx_pm_timeouts - pm timeout values in TX command >>> > - * @IWM_PM_FRAME_NONE: no need to suspend sleep mode >>> > - * @IWM_PM_FRAME_MGMT: fw suspend sleep mode for 100TU >>> > - * @IWM_PM_FRAME_ASSOC: fw suspend sleep mode for 10sec >>> > - */ >>> > -enum iwm_tx_pm_timeouts { >>> > - IWM_PM_FRAME_NONE = 0, >>> > - IWM_PM_FRAME_MGMT = 2, >>> > - IWM_PM_FRAME_ASSOC = 3, >>> > -}; >>> > - >>> > /* >>> > * TX command security control >>> > */ >>> > >>> > >>> > >>> > Scan Debug: >>> > http://www.lerctr.org/~ler/FreeBSD/WIFI-Scan.txt >>> > >>> > What next? >>> > >>> > On Thu, Jul 28, 2016 at 06:06:47PM -0700, Adrian Chadd wrote: >>> > > +imre, >>> > > >>> > > Hi! Larry is having issues with r303418. Would you be able to help him out? >>> > > >>> > > (If it's not too bad, can we back this out until you figure out what's >>> > > going on?) >>> > > >>> > > Thanks! >>> > > >>> > > >>> > > -a >>> > > >>> > > >>> > > On 28 July 2016 at 18:05, Larry Rosenman wrote: >>> > > > On 2016-07-28 20:02, Adrian Chadd wrote: >>> > > >> >>> > > >> Hi, >>> > > >> >>> > > >> Which commit(s) did you revert? >>> > > >> >>> > > >> >>> > > >> >>> > > >> -a >>> > > > >>> > > > >>> > > > revert r303418 >>> > > > >>> > > > and now it connects again. >>> > > > >>> > > > >>> > > > -- >>> > > > Larry Rosenman http://www.lerctr.org/~ler >>> > > > Phone: +1 214-642-9640 E-Mail: ler@lerctr.org >>> > > > US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 >>> > >>> > -- >>> > Larry Rosenman http://www.lerctr.org/~ler >>> > Phone: +1 214-642-9640 E-Mail: ler@lerctr.org >>> > US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 >>> >>> -- >>> Larry Rosenman http://www.lerctr.org/~ler >>> Phone: +1 214-642-9640 E-Mail: ler@lerctr.org >>> US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 >> >> -- >> Larry Rosenman http://www.lerctr.org/~ler >> Phone: +1 214-642-9640 E-Mail: ler@lerctr.org >> US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 > _______________________________________________ > 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" -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 From owner-freebsd-current@freebsd.org Wed Aug 3 20:56: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 34E04BAE1E6 for ; Wed, 3 Aug 2016 20:56:31 +0000 (UTC) (envelope-from cheffo@freebsd-bg.org) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AF5F81E27 for ; Wed, 3 Aug 2016 20:56:30 +0000 (UTC) (envelope-from cheffo@freebsd-bg.org) Received: by mail-lf0-x234.google.com with SMTP id f93so169972423lfi.2 for ; Wed, 03 Aug 2016 13:56:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd-bg-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=X/RaW9pIE61UrrGcbiB1wXLv+OkUPjfZefhYhA8slXc=; b=CG6KN+XSPRIFIfa8RUwq7jCL4rMKz6rEsLLFHi5MzjpzwnY1K2IrxqvDhyynz2ZWsN TBIG5jJ6NXmXx3dfVL1j48zLHJhgRMpgQmytdUdaLELo4eOO0h2qVXOLzE+JhO0Ldrre ds2/na86HiMkWMjujg9S+3ITnDJs8JFL4EmtfshLwQBDwFLys8ZZhcmZs+dPMmjZ4xbq H6SI3Z6hyrHW5NmE4HvPGerTtWtqRlB7LZTo1uF5bTIHmWpE7Nt9S4VdvoXPxb/M+FNv 8xkgxUgFeQ+87B6WuljWyJcnu4Mifg/AHC6jGvkRWYDYFP6q6x7X91NKMXZ22YCPog4z 9DQQ== 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; bh=X/RaW9pIE61UrrGcbiB1wXLv+OkUPjfZefhYhA8slXc=; b=HQmDYFw1/ZUwAgcn/p4fue7q5oznVck6oMnSG6rrsVERv7FssxtkiRNDbH7DzVe64S TqbbHnc2GpnQPzGh1CAP+ObruffRtwOitMvDYSgUYiihUoirkXTzq6QhJFjf8fq+TRti 3a/L7F1y4Fqz6FApf799fU3KBvtHmJbzdYU1h7NXPbdhNpSLLrsFwUwN8hJZK8JC2k9g 2nqBIbY5hrverlIR5ka0APYeRUh6ksQxlF1syXITXf24VUaVSexNKDqlXNMdrcrnghe/ I5/5pFddwTdC0RE3QppF50ppKJbOaMY5PaYeQDoi+sJ074YtswrsuRcbF0HmeTIhEiYs K4Rw== X-Gm-Message-State: AEkooutYhUFWHjqGuMPw0lcDPSXbBDMDmdtpxB5H8E7hhT0oNQDwgqF2tJHynVfcVFgzUjbRY2Smjq1bIShLGQ== X-Received: by 10.25.146.85 with SMTP id u82mr18343926lfd.222.1470257788503; Wed, 03 Aug 2016 13:56:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.44.201 with HTTP; Wed, 3 Aug 2016 13:56:27 -0700 (PDT) In-Reply-To: References: From: Stefan Lambrev Date: Wed, 3 Aug 2016 23:56:27 +0300 Message-ID: Subject: Re: Wierd issues with wifi in hostap mode in FreeBSD 11 To: 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, 03 Aug 2016 20:56:31 -0000 Hi, Looks like I have made a typo in the configuration "wlanmod" instead of "wlanmode". Just for the record I have changed rc.conf as follows: #network cloned_interfaces="bridge0" wlans_ath0="wlan0" create_args_wlan0="wlanmode hostap country bg" ifconfig_wlan0="ssid cheffo channel 5:g txpower 30 protmode rtscts dturbo up" and now wlan0 works. wlan0: flags=8943 metric 0 mtu 1500 ether 00:0c:42:26:3d:b7 nd6 options=29 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: running ssid cheffo channel 5 (2432 MHz 11g) bssid 00:0c:42:26:3d:b7 regdomain ETSI country BG ecm authmode WPA privacy MIXED deftxkey 2 AES-CCM 2:128-bit txpower 30 scanvalid 60 protmode RTSCTS wme burst dtimperiod 1 -dfs groups: wlan But still this does not explains the freezes when I was doing this manually. On Wed, Aug 3, 2016 at 6:44 PM, Ronald Klop wrote: > On Wed, 03 Aug 2016 10:05:57 +0200, Stefan Lambrev > wrote: > > Greetings, >> >> >> I've just installed FreeBSD 11 on Soekris net5501 with the following wifi >> card: >> >> >> root@soekris:~ # dmesg |grep ath0 >> ath0: mem 0xa0010000-0xa001ffff irq 15 at device 17.0 on >> pci0 >> ath0: AR5413 mac 10.5 RF5413 phy 6.1 >> ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0063 >> >> ath0@pci0:0:17:0: class=0x020000 card=0x110719b6 chip=0x001b168c >> rev=0x01 hdr=0x00 >> vendor = 'Qualcomm Atheros' >> device = 'AR5413/AR5414 Wireless Network Adapter [AR5006X(S) >> 802.11abg]' >> class = network >> subclass = ethernet >> >> >> But wat is very strange for me is that I do not see ath0 device on >> ifconfig: >> >> >> root@soekris:~ # ifconfig ath0 >> ifconfig: interface ath0 does not exist >> >> At the same time if I crate wlan0 to list caps it works: >> >> root@soekris:~ # ifconfig wlan0 create wlandev ath0 >> root@soekris:~ # ifconfig wlan0 list caps >> >> drivercaps=4f8defc1> >> LE,MONITOR,MBSS,WPA1,WPA2,BURST,WME,WDS,TXFRAG> >> cryptocaps=1f >> root@soekris:~ # >> >> >> The issues is that when I try to start wlan0 in hostap mode - FreeBSD >> freezes, unfortunatelly I cannot find my serial port cable atm and cannot >> see what exactly is displayed on the console but it's a hard freeze and >> the >> device do not reboot after it e.g. power cycle is required. >> >> >> When configured from rc.conf it boots and do not freeze but still says >> status: no carrier and hostapd complains that the device is not >> configured. >> >> snippet from rc.conf: >> >> cloned_interfaces="bridge0" >> wlans_ath0="wlan0" >> create_args_wlan0="wlanmod hostap" >> ifconfig_wlan0="ssid cheffo country bg up" >> > > > Hi, > > I don't know how people should know, but after some mails in the past > (when 11 was still CURRENT) I learned that the 'country' statement is moved > to create_args_wlan0 too. I don't know about ssid. > > Oh!!! Cheer! The man page of ifconfig says 'The following parameters are > specific to cloning IEEE 802.11 wireless interfaces with the create > request:' and than has a very long list of parameters. > > Cheers, > Ronald. > > > ifconfig_bridge0="addm vr0 addm vr1 addm vr2 addm vr3 addm wlan0 up" >> ifconfig_bridge0_alias0="inet 10.1.1.2 netmask 255.255.255.0" >> >> I'm still with GENERIC kernel and there are no changes or custom cpu >> optimizations done so far: >> >> root@soekris:~ # uname -a >> FreeBSD soekris.ziops-security.org 11.0-BETA3 FreeBSD 11.0-BETA3 #0 >> r303469: Fri Jul 29 04:28:58 UTC 2016 >> root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC >> i386 >> >> root@soekris:~ # cat /boot/loader.conf >> dcons_load="YES" >> dcons_crom="YES" >> crypto_load="YES" >> cryptodev_load="YES" >> glxsb_load="YES" >> if_bridge_load="YES" >> wlan_xauth_load="YES" >> >> >> root@soekris:~ # kldstat >> Id Refs Address Size Name >> 1 19 0xc0400000 1a9313c kernel >> 2 1 0xc1e95000 80d4 geom_label.ko >> 3 1 0xc1e9e000 bc80 if_bridge.ko >> 4 2 0xc1eaa000 6ce0 bridgestp.ko >> 5 1 0xc1eb1000 3a70 dcons.ko >> 6 1 0xc1eb5000 5978 cryptodev.ko >> 7 1 0xc1ebb000 548c glxsb.ko >> 8 1 0xc1ec1000 1d6c wlan_xauth.ko >> >> >> I have to mention that I've tried with 11-BETA2 first and there were the >> same behaviour, and also I have used this soekris setup for few years with >> FreeBSD 7 and 8 for a home wifi router so I do know that the hardware is >> supported and OK, as it worked rock solid just before reinstalling it with >> FreeBSD 11. >> >> Any advice on how to get wifi working again? >> >> Thanks! >> _______________________________________________ >> 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 Wed Aug 3 23:24:09 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6CD78BAEF94 for ; Wed, 3 Aug 2016 23:24:09 +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 28ABA133D for ; Wed, 3 Aug 2016 23:24:08 +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 3s4TfX5pvWzYx for ; Thu, 4 Aug 2016 01:24:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:organization:subject:subject:from:from :date:date:content-transfer-encoding:content-type:content-type :mime-version:received:received:received:received; s=jakla4; t= 1470266641; x=1472858642; bh=/wVndb1BzKWoo5ohZ/ZZQguvT2V8ebfGZRR TVylwqLQ=; b=cvN0SHk5umD0y0pWXlPv6JoJDVwk7jL+Rd13loHIHo6XVE8GLug n1m4rp0MwGk7jQPfFvjv/0aJRu9byIu0OY+SR5aY1oN9FUQ2LF/oz7DeKacEwx4i 0GVl3ABcDaueMCSQBLec3LWa/bv6xksYTGvJJ+pJ4uoLKkjxes0GlzEY= 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 EAuN4ILBp4jc for ; Thu, 4 Aug 2016 01:24:01 +0200 (CEST) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP id 3s4TfT6PpPzYw for ; Thu, 4 Aug 2016 01:24:01 +0200 (CEST) Received: from nabiralnik.ijs.si (nabiralnik.ijs.si [IPv6:2001:1470:ff80::80:16]) by mildred.ijs.si (Postfix) with ESMTP id 3s4TfT2TCxz151 for ; Thu, 4 Aug 2016 01:24:01 +0200 (CEST) Received: from sleepy.ijs.si (2001:1470:ff80:e001::1:1) by webmail.ijs.si with HTTP (HTTP/1.1 POST); Thu, 04 Aug 2016 01:24:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 04 Aug 2016 01:24:01 +0200 From: Mark Martinec To: freebsd-current@freebsd.org Subject: date(1) default format changed between 10.3 and 11.0-BETA3 Organization: Jozef Stefan Institute Message-ID: 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: Wed, 03 Aug 2016 23:24:09 -0000 Is it normal/expected/documented that the date(1) command in 11.0 now produces a timestamp in substantially different format in an "en_US.UTF-8" locale (long names, commas, 12 vs. 24h hour time): Thursday, August 4, 2016 at 12:50:43 AM CEST vs: Thu Aug 4 00:52:29 CEST 2016 Setting LC_TIME does not help: $ LC_TIME="C" date Thursday, August 4, 2016 at 01:13:37 AM CEST although LC_ALL="C" _does_ help. This is funny too, especially regarding commas: $ LC_ALL="en_GB.UTF-8" date Thursday 4 August 2016 at 01:16:45 CEST $ LC_ALL="en_US.UTF-8" date Thursday, August 4, 2016 at 01:16:54 AM CEST The date(1) man page states: The date utility is expected to be compatible with IEEE Std 1003.2 (“POSIX.2â€). What does POSIX.2 say about date(1) following a locale? ====== 11.0-BETA3: $ date Thursday, August 4, 2016 at 12:50:43 AM CEST $ uname -a FreeBSD xxx.ijs.si 11.0-BETA3 FreeBSD 11.0-BETA3 #0 r303469: Fri Jul 29 02:27:28 UTC 2016 root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 $ locale LANG= LC_CTYPE="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_ALL=en_US.UTF-8 ====== 10.3-RELEASE-p6 : $ date Thu Aug 4 00:52:29 CEST 2016 $ freebsd-version 10.3-RELEASE-p6 $ uname -a FreeBSD yyy.ijs.si 10.3-RELEASE-p4 FreeBSD 10.3-RELEASE-p4 #0: Sat May 28 12:23:44 UTC 2016 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 $ locale LANG= LC_CTYPE="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_ALL=en_US.UTF-8 Mark From owner-freebsd-current@freebsd.org Thu Aug 4 02:32: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 7993FBADD1D for ; Thu, 4 Aug 2016 02:32:36 +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 3FEDE18FE for ; Thu, 4 Aug 2016 02:32:35 +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 u742WUia038929 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 3 Aug 2016 19:32:32 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: date(1) default format changed between 10.3 and 11.0-BETA3 To: Mark Martinec , freebsd-current@freebsd.org References: From: Julian Elischer Message-ID: <3629a441-ee6d-2407-fa13-5ebd8db8d802@freebsd.org> Date: Thu, 4 Aug 2016 10:32:24 +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=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: Thu, 04 Aug 2016 02:32:36 -0000 On 4/08/2016 7:24 AM, Mark Martinec wrote: > Is it normal/expected/documented that the date(1) command in 11.0 > now produces a timestamp in substantially different format > in an "en_US.UTF-8" locale (long names, commas, 12 vs. 24h hour time): > > Thursday, August 4, 2016 at 12:50:43 AM CEST > vs: > Thu Aug 4 00:52:29 CEST 2016 > one of those is a bug. the formats are defined in posix I believe. > > Setting LC_TIME does not help: > > $ LC_TIME="C" date > Thursday, August 4, 2016 at 01:13:37 AM CEST > > although LC_ALL="C" _does_ help. > > > This is funny too, especially regarding commas: > $ LC_ALL="en_GB.UTF-8" date > Thursday 4 August 2016 at 01:16:45 CEST > $ LC_ALL="en_US.UTF-8" date > Thursday, August 4, 2016 at 01:16:54 AM CEST > > > The date(1) man page states: > The date utility is expected to be compatible with IEEE Std 1003.2 > (“POSIX.2â€). > What does POSIX.2 say about date(1) following a locale? > > > > ====== > 11.0-BETA3: > > $ date > Thursday, August 4, 2016 at 12:50:43 AM CEST > > $ uname -a > FreeBSD xxx.ijs.si 11.0-BETA3 FreeBSD 11.0-BETA3 #0 r303469: Fri Jul > 29 02:27:28 UTC 2016 > root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 > > $ locale > LANG= > LC_CTYPE="en_US.UTF-8" > LC_COLLATE="en_US.UTF-8" > LC_TIME="en_US.UTF-8" > LC_NUMERIC="en_US.UTF-8" > LC_MONETARY="en_US.UTF-8" > LC_MESSAGES="en_US.UTF-8" > LC_ALL=en_US.UTF-8 > > ====== > 10.3-RELEASE-p6 : > > $ date > Thu Aug 4 00:52:29 CEST 2016 > > $ freebsd-version > 10.3-RELEASE-p6 > > $ uname -a > FreeBSD yyy.ijs.si 10.3-RELEASE-p4 FreeBSD 10.3-RELEASE-p4 #0: Sat > May 28 12:23:44 UTC 2016 > root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 > > $ locale > LANG= > LC_CTYPE="en_US.UTF-8" > LC_COLLATE="en_US.UTF-8" > LC_TIME="en_US.UTF-8" > LC_NUMERIC="en_US.UTF-8" > LC_MONETARY="en_US.UTF-8" > LC_MESSAGES="en_US.UTF-8" > LC_ALL=en_US.UTF-8 > > > > Mark > _______________________________________________ > 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 4 05:22:53 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0E46CBADBD3 for ; Thu, 4 Aug 2016 05:22:53 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: from mail-yw0-x242.google.com (mail-yw0-x242.google.com [IPv6:2607:f8b0:4002:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C4D1617E2 for ; Thu, 4 Aug 2016 05:22:52 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: by mail-yw0-x242.google.com with SMTP id j12so18675809ywb.1 for ; Wed, 03 Aug 2016 22:22:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=nAvocbrYq60SleyGRfo2FzZ+s0+h/1/y1Z8hnSWpL4E=; b=a2nl9i5JXR2JvabtpCqbpOv4Rl0SB8hWOw3XiDe6k7ON1vtj2vSzc6gRMk5oFtr7L/ uy+A0XcnymQgsvxgbG9wV6P+tP/QBZfH9K0EauQiV7gktAC+3PffRwvBNT10eIPF5Gku z1k0F8+EFLjAk2oDxDBhdvqeKkAv4oVimA46EDI5nD7bApRjMT66T81uSzg3oyC6J3Dc TE1LCC8cCq8nu+kP51slKur0qf/tS5JuxvHtyxI4FkmjiqaIJH2PRcw3nWZ74C5Arm+s OJYXFIWRQ3s8ED1KzQHeeXROtLs3yTN1EZXsUlBGU5EGsgvG1lIMJyXknyCY/IRw5q0c kxgw== 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=nAvocbrYq60SleyGRfo2FzZ+s0+h/1/y1Z8hnSWpL4E=; b=WN1rO+jW0qpS63WpNf/tGTp1gVAVUdQ0Nrjs341+vmxtpnqzz5plig0EKkch7JBIIg SscSrriAGpiIcSP7RGmqooFbWLvNzVEgVQNLQ3Vp20oLgTa2e5KWwXqabETL7I4ac/qc miT8M8RBKg3pOamXH/cO+TMK3Ur8Tb+Ubua5MJqx5oLyWQdIHWawENGDsFbU8YR/2Tdx EcqMCMbj3EvYgDKeXk04AvV5eKo3GjWNFih0t0TdCQUwDsSQWwJTz6Tkyf3cubp+cQR1 DBCsjzAlqnNqD8KjeEx1jmv0gTYH5NOyLIhtP71WB4kyUMZygn7dAWmC201mns/UBDk6 cDPQ== X-Gm-Message-State: AEkoouu7uvBN4agymLv0itPiOa+SWkseGMwB8d24pFzF2jtrpgRP5KQruyAzL5UrXVTkBDnWwXGWhxkea8Bobg== X-Received: by 10.129.129.134 with SMTP id r128mr46420121ywf.179.1470288171800; Wed, 03 Aug 2016 22:22:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.51.150 with HTTP; Wed, 3 Aug 2016 22:22:51 -0700 (PDT) From: Ultima Date: Thu, 4 Aug 2016 01:22:51 -0400 Message-ID: Subject: Possible zpool online, resilvering issue To: 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, 04 Aug 2016 05:22:53 -0000 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. Ultima From owner-freebsd-current@freebsd.org Thu Aug 4 06:59: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 379F2BAE173 for ; Thu, 4 Aug 2016 06:59:12 +0000 (UTC) (envelope-from gljennjohn@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 146D21EC0 for ; Thu, 4 Aug 2016 06:59:12 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 044ADBAE172; Thu, 4 Aug 2016 06:59:12 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 03EA2BAE171 for ; Thu, 4 Aug 2016 06:59:12 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8526D1EBD; Thu, 4 Aug 2016 06:59:11 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm0-x22e.google.com with SMTP id q128so473448270wma.1; Wed, 03 Aug 2016 23:59:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=hplOsfB3c4o3K4rrGCEgPTJ0dW+jHZPPQKJl5Qa78nk=; b=qB2kCKcjGoStSJPa+HUwJZt65dtuHLU3AC6D75pEK+gNN83oNRckU/BbhQMFzBDyBb ovLQfBg/x2VLLCfaLtOkANzcnGXa+6L37yVVoXFHvNzxP56AqxR9WGhibDNicmIyH1Yy DcyR97Dty924bsIM5XPXNIdHORQryWysHKU4n32AfVBgnv3yTYoJ+1QoMGu7Z6nDcHKv 6fvU+zjWI8YdueG95l31LMZ4ilZbxhmr9DEwzFMxcSyCstX03sMBnOyTR857VEtmD+t9 Cqz6lQpyTtPcdOSYCcQ3jnZ1YicscU7AW3Y3B/A5G/83ZRXX00G0pHX8GnA5Mm/oDlew y4Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=hplOsfB3c4o3K4rrGCEgPTJ0dW+jHZPPQKJl5Qa78nk=; b=c1gGlHFZo5APzgXlPuLwt5VjBm+G8wAzm1ZK3xuUJwLsnBbFr+hHKZBX9BUtoAeVx6 Ly8IzI4TAQ+f+cSOBoUrhhAuG5ioEemHInRvBVkGwkW9YAC0ksfNrrttaP/JFmqZpn3g vIFfry5FWOoM/TPfyDByi/tj42WU08mBueyMy86KehS0J7VZV9mgILXAGOkqbPY6N5pD RKcXyssjWvcOd13tMTK827dT5ejZeOhUvycXYcwO5fsik2bhZc2MNiTe2CWp7txrAeDC +4w60Z1CNp1lr35g02O+u7naK62PwwG3QxVKHvAG7s0h4bKVtWb0CNLpYCaNsZ7BHm+J YxvA== X-Gm-Message-State: AEkoouuTZ51+W13ass3f/OHBsdtz1rwmmPx04oj4H6cpV3SDjSpx4Khlv/4samDIuLDPww== X-Received: by 10.194.88.137 with SMTP id bg9mr35251321wjb.155.1470293949654; Wed, 03 Aug 2016 23:59:09 -0700 (PDT) Received: from ernst.home (p578E1507.dip0.t-ipconnect.de. [87.142.21.7]) by smtp.gmail.com with ESMTPSA id iw1sm11258657wjb.20.2016.08.03.23.59.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Aug 2016 23:59:08 -0700 (PDT) Date: Thu, 4 Aug 2016 08:59:06 +0200 From: Gary Jennejohn To: John Baldwin Cc: current@freebsd.org Subject: Re: EARLY_AP_STARTUP hangs during boot Message-ID: <20160804085906.2228aa0b@ernst.home> In-Reply-To: <4473265.DhpanzHFA4@ralph.baldwin.cx> References: <20160516122242.39249a54@ernst.home> <9937686.eTkQvkYRyu@ralph.baldwin.cx> <20160802090310.7a03d6d0@ernst.home> <4473265.DhpanzHFA4@ralph.baldwin.cx> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 04 Aug 2016 06:59:12 -0000 On Tue, 02 Aug 2016 10:41:23 -0700 John Baldwin wrote: > On Tuesday, August 02, 2016 09:03:10 AM Gary Jennejohn wrote: > > On Mon, 01 Aug 2016 13:19:16 -0700 > > John Baldwin wrote: > > > > > On Monday, August 01, 2016 03:31:11 PM Gary Jennejohn wrote: > > > > On Mon, 1 Aug 2016 09:34:34 +0200 > > > > Gary Jennejohn wrote: > > > > > > > > > On Sun, 31 Jul 2016 14:22:35 -0700 > > > > > John Baldwin wrote: > > > > > > > > > > > On Sunday, July 31, 2016 11:29:14 AM Gary Jennejohn wrote: > > > > > > > On Sat, 30 Jul 2016 12:03:59 -0700 > > > > > > > John Baldwin wrote: > > > > > > > > > > > > > > > On Saturday, July 30, 2016 09:44:22 AM Gary Jennejohn wrote: > > > > > > > > > On Fri, 29 Jul 2016 13:17:42 -0700 > > > > > > > > > John Baldwin wrote: > > > > > > > > > > > > > > > > > > > On Thursday, July 28, 2016 12:31:31 AM Gary Jennejohn wrote: > > > > > > > > > > > Well, now I know that ULE is a prerequiste for EARLY_AP_STARTUP! I > > > > > > > > > > > wasn't aware of that. I prefer BSD and that's the scheduler I did > > > > > > > > > > > the first tests with. > > > > > > > > > > > > > > > > > > > > > > But with the ULE scheduler the system comes up all the way. > > > > > > > > > > > > > > > > > > > > > > It would be nice if the BSD scheduler could also be modified to > > > > > > > > > > > work with EARLY_AP_STARTUP. > > > > > > > > > > > > > > > > > > > > I wasn't able to reproduce your hang with 4BSD, but I think I see a > > > > > > > > > > possible problem. Try this: > > > > > > > > > > > > > > > > > > > > diff --git a/sys/kern/sched_4bsd.c b/sys/kern/sched_4bsd.c > > > > > > > > > > index 7de56b6..d53331a 100644 > > > > > > > > > > --- a/sys/kern/sched_4bsd.c > > > > > > > > > > +++ b/sys/kern/sched_4bsd.c > > > > > > > > > > @@ -327,7 +327,6 @@ maybe_preempt(struct thread *td) > > > > > > > > > > * - The current thread has a higher (numerically lower) or > > > > > > > > > > * equivalent priority. Note that this prevents curthread from > > > > > > > > > > * trying to preempt to itself. > > > > > > > > > > - * - It is too early in the boot for context switches (cold is set). > > > > > > > > > > * - The current thread has an inhibitor set or is in the process of > > > > > > > > > > * exiting. In this case, the current thread is about to switch > > > > > > > > > > * out anyways, so there's no point in preempting. If we did, > > > > > > > > > > @@ -348,7 +347,7 @@ maybe_preempt(struct thread *td) > > > > > > > > > > ("maybe_preempt: trying to run inhibited thread")); > > > > > > > > > > pri = td->td_priority; > > > > > > > > > > cpri = ctd->td_priority; > > > > > > > > > > - if (panicstr != NULL || pri >= cpri || cold /* || dumping */ || > > > > > > > > > > + if (panicstr != NULL || pri >= cpri /* || dumping */ || > > > > > > > > > > TD_IS_INHIBITED(ctd)) > > > > > > > > > > return (0); > > > > > > > > > > #ifndef FULL_PREEMPTION > > > > > > > > > > @@ -1127,7 +1126,7 @@ forward_wakeup(int cpunum) > > > > > > > > > > if ((!forward_wakeup_enabled) || > > > > > > > > > > (forward_wakeup_use_mask == 0 && forward_wakeup_use_loop == 0)) > > > > > > > > > > return (0); > > > > > > > > > > - if (!smp_started || cold || panicstr) > > > > > > > > > > + if (!smp_started || panicstr) > > > > > > > > > > return (0); > > > > > > > > > > > > > > > > > > > > forward_wakeups_requested++; > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, but with this patch the kernel hangs in exactly the same > > > > > > > > > place as before - after the HPET output. > > > > > > > > > > > > > > > > > > Maybe I'm missing some kernel option which ULE works around, or > > > > > > > > > something like that. > > > > > > > > > > > > > > > > Hmm, ok. Please add KTR_RUNQ and KTR_SMP to the KTR masks, that is > > > > > > > > 'options KTR_COMPILE=(KTR_PROC|KTR_RUNQ|KTR_SMP)' and > > > > > > > > 'options KTR_MASK=(KTR_PROC|KTR_RUNQ|KTR_SMP)' > > > > > > > > > > > > > > > > Please also add this patch (on top of the previous patch): > > > > > > > > > > > > > > > > diff --git a/sys/kern/sched_4bsd.c b/sys/kern/sched_4bsd.c > > > > > > > > index 2973a23..bab2278 100644 > > > > > > > > --- a/sys/kern/sched_4bsd.c > > > > > > > > +++ b/sys/kern/sched_4bsd.c > > > > > > > > @@ -1278,6 +1278,8 @@ sched_add(struct thread *td, int flags) > > > > > > > > KASSERT(td->td_flags & TDF_INMEM, > > > > > > > > ("sched_add: thread swapped out")); > > > > > > > > > > > > > > > > + CTR2(KTR_PROC, "sched_add: thread %d (%s)", td->td_tid, > > > > > > > > + sched_tdname(td)); > > > > > > > > KTR_STATE2(KTR_SCHED, "thread", sched_tdname(td), "runq add", > > > > > > > > "prio:%d", td->td_priority, KTR_ATTR_LINKED, > > > > > > > > sched_tdname(curthread)); > > > > > > > > diff --git a/sys/x86/x86/cpu_machdep.c b/sys/x86/x86/cpu_machdep.c > > > > > > > > index f07b97e..1f418f1 100644 > > > > > > > > --- a/sys/x86/x86/cpu_machdep.c > > > > > > > > +++ b/sys/x86/x86/cpu_machdep.c > > > > > > > > @@ -440,6 +440,7 @@ cpu_idle_wakeup(int cpu) > > > > > > > > return (0); > > > > > > > > if (*state == STATE_MWAIT) > > > > > > > > *state = STATE_RUNNING; > > > > > > > > + CTR1(KTR_PROC, "cpu_idle_wakeup: wokeup CPU %d", cpu); > > > > > > > > return (1); > > > > > > > > } > > > > > > > > > > > > > > > > (I haven't tried compiling it, you might have to add the sys/ktr.h > > > > > > > > header to cpu_machdep.c if it doesn't build.) > > > > > > > > > > > > > > > > Hopefully we will get some better trace messages before it hangs > > > > > > > > with this added info. The root issue seems to be that 4BSD is > > > > > > > > pinning thread0 to some other CPU (due to sched_bind that happens > > > > > > > > inside of bus_bind_intr() when the HPET driver pins IRQs to CPUs) > > > > > > > > and that other CPU isn't waking up to realize it needs to run thread0. > > > > > > > > > > > > > > > > > > > > > > It compiled with no changes needed. > > > > > > > > > > > > > > Even though I set MAXCPU to a mere 2, the boot still hadn't > > > > > > > completed after 90 minutes and I broke it off. I still have > > > > > > > the kernel, so I can try it another time when I have less need > > > > > > > for my FreeBSD box. > > > > > > > > > > > > Did you have the KTR options enabled from before? I don't expect this > > > > > > to fix the issue, this is more about getting better debug info when it > > > > > > hangs. > > > > > > > > > > > > > > > > Yes, all the options from before were enabled. Maybe I should have > > > > > disabled KTR_VERBOSE=1? I'll try it without that. > > > > > > > > > > > > > KTR_VERBOSE=1 is necessary. > > > > > > Yes. > > > > > > > OK, after about 5 hours it landed in an infinite loop emitting: > > > > > > > > cpu_0 ipi_cpu: cpu: 1 to 5 ipi: 2 (my CPU has 6 cores) > > > > > > Humm, can you capture a picture right when it hangs? Those interrupts > > > are due to clock interrupts (IPI_HARDCLOCK) and are noise. More what > > > I'm trying to see is if we send IPI_AST/IPI_PREEMPT to the CPU after > > > binding to it. > > > > > > > I can't tell when it hangs due to the amount of trace coming out. > > The hang is hidden in the noise and I have no way to suppress the > > trace that I'm aware of. The trace is coming so fast that even > > a photo of the screen looks smeared. > > > > Is there a way to limit the trace to IPI_AST/IPI_PREEMPT? > > Yes: > > diff --git a/sys/x86/x86/mp_x86.c b/sys/x86/x86/mp_x86.c > index 91c119a..6c57b20 100644 > --- a/sys/x86/x86/mp_x86.c > +++ b/sys/x86/x86/mp_x86.c > @@ -1160,7 +1160,8 @@ ipi_cpu(int cpu, u_int ipi) > if (ipi == IPI_STOP_HARD) > CPU_SET_ATOMIC(cpu, &ipi_stop_nmi_pending); > > - CTR3(KTR_SMP, "%s: cpu: %d ipi: %x", __func__, cpu, ipi); > + if (ipi == IPI_AST || ipi == IPI_PREEMPT) > + CTR3(KTR_SMP, "%s: cpu: %d ipi: %x", __func__, cpu, ipi); > ipi_send_cpu(cpu, ipi); > } > > I limited output to KTR_SMP and used only the patch above. The last lines which appear are: hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 cpu0: smp_targeted_tlb_shootdown: cpu: 1 ipi: f6 cpu0: smp_targeted_tlb_shootdown: cpu: 2 ipi: f6 cpu0: smp_targeted_tlb_shootdown: cpu: 3 ipi: f6 cpu0: smp_targeted_tlb_shootdown: cpu: 4 ipi: f6 cpu0: smp_targeted_tlb_shootdown: cpu: 5 ipi: f6 Timecounter "HPET" frequency 14318180 Hz qualty 950 -- Gary Jennejohn From owner-freebsd-current@freebsd.org Thu Aug 4 07:15:02 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 50EE9BAE73F for ; Thu, 4 Aug 2016 07:15:02 +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 2E3F61827; Thu, 4 Aug 2016 07:15:01 +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 u747Esae000893 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 4 Aug 2016 00:14:58 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: Socket sendmsg() porting question To: "Lundberg, Johannes" , Alan Somers References: Cc: FreeBSD Current From: Julian Elischer Message-ID: Date: Thu, 4 Aug 2016 15:14:49 +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=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: Thu, 04 Aug 2016 07:15:02 -0000 On 4/08/2016 1:18 AM, Lundberg, Johannes wrote: > ​Hi Alan > > Thanks for the reply. > > Can I still use the same receiving function for sendmsg/send and tell what > kind of message is coming? > How would I tell if there is an fd attached or not? > > Even if I set cmsg_level and cmsg_type it won't let me send it. The problem > is having a zero length attachment on freebsd.... > I can't send -1 as fd because that errors to invalid file descriptor. > > > On Wed, Aug 3, 2016 at 10:12 AM, Alan Somers wrote: > >> On Wed, Aug 3, 2016 at 10:54 AM, Lundberg, Johannes >> wrote: >>> Hi >>> >>> I'm porting a project to fbsd and I have problem with this part that >> works >>> in linux but not fbsd when fd = -1. >>> >>> https://github.com/Cloudef/wlc/blob/master/src/session/fd.c#L80-L108 >>> >>> I get "invalid argument" from sendmsg() when setting CMSG_LEN(0). >>> >>> Anyone have a clue how to correctly do this on fbsd? >>> >>> Thanks! >>> >>> Johannes >>> >> It sounds like you're trying to send an empty cmsg. The error may >> happen because your msg_controllen field is inconsistent with your >> cmsg_len field. You're setting msg_controllen as if there were a full >> cmsg, but then cmsg_len says that there is no cmsg. Or maybe the >> error is because (just guessing) FreeBSD doesn't allow sending empty >> or undefined cmsgs. Notice that cmsg_level and cmsg_type are >> undefined in the case where fd == -1. POSIX doesn't say whether >> sendmsg supports empty cmsgs, but why bother? You could just use send >> instead of sendmsg if you're not sending a file descriptor. >> >> -Alan >> I think it's a standards interpretation thing. what data do you send WITH the message? I assume you have some in-band data as well. if you have no FD, just use "sendto()." the other end will still be able to do a recvmesg() but will discover no added info. From owner-freebsd-current@freebsd.org Thu Aug 4 07:15: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 1E85BBAE754 for ; Thu, 4 Aug 2016 07:15:06 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C94361899 for ; Thu, 4 Aug 2016 07:15:05 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: by mail-yw0-x234.google.com with SMTP id u134so246339352ywg.3 for ; Thu, 04 Aug 2016 00:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuxi-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pRi8MD35VdpxTfj38xA+lv2WIiW2wHBoskvjb/L6ER8=; b=zrAykTFYnKQfmI12jUwMskWllp+0+Crte4BuvGE7Ko+WX2JE0BzkIPy+u2f0v7NTWE NsaqmapFKFhnMPb9H3O+F0+IDB9q5u+18LwyEN00gwBS7UBI6G5B4J6RbxSPOvRzV2a8 7ZGiKhbxp1eXrwmeFvL7/ITXVpBAioKYjFUKQLuOXHX2vLJbbS5gzg0TACaii7I74Aek D8tebJi1T6w9XoFgrZIkrE6v8bK/PkC6XYs9W++a/4k9vv16CVFdVdAFBu4Gb+4xnCAG K82JwXvkhEhJoBCKj4fFB0tldoM4Kq83bdC/cmQx2RlfQga6I3lK/F9XMUJXSTZlA5aX vzkA== 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=pRi8MD35VdpxTfj38xA+lv2WIiW2wHBoskvjb/L6ER8=; b=Jai5v1TrjRgzNiBowssouCfITZnlzq0/nOmWanlEs+HxxXcwh1cyPHX1U3XTDIghu4 njVBFM+2V6GYhy5Zzzlsq8yiXK9ySfl6ONJ64VJ6vq96p8KINrhY+elKXmcvSWyXt2nh T6b9xzQm9S+GPlTCa1KaW0azZy20Vw97CKrXpvymeIRAt2ZCkCJGSfdntIlrHT02ykqH /1bnpoKufcZk0BVsdL6trm1udh+HdKMU+pOeOx8ArEm25aOj8SGyZbpXy7RQgXPKqBCq jl+2Cxl3pmiBxsIPLUuHfbaivdlYpIzZqU9TXKfn2sb25lYl+B5uMgXeNjwfjawLVrZT 7VCQ== X-Gm-Message-State: AEkoousSp6J6ggMG4idtr1Ym3dd5WVNQnSvvXKjbbrKNrqMY5NzmNoQEoGc9uojFUjweQDolE6pCCz21/o1o4Q== X-Received: by 10.13.229.1 with SMTP id o1mr58028323ywe.95.1470294904747; Thu, 04 Aug 2016 00:15:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.201.71 with HTTP; Thu, 4 Aug 2016 00:15:03 -0700 (PDT) In-Reply-To: References: From: Ed Schouten Date: Thu, 4 Aug 2016 09:15:03 +0200 Message-ID: Subject: Re: Socket sendmsg() porting question To: "Lundberg, Johannes" Cc: Alan Somers , 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: Thu, 04 Aug 2016 07:15:06 -0000 2016-08-03 19:18 GMT+02:00 Lundberg, Johannes : > Even if I set cmsg_level and cmsg_type it won't let me send it. The problem > is having a zero length attachment on freebsd.... > I can't send -1 as fd because that errors to invalid file descriptor. Well, it makes sense. If you're attaching a message to a sendmsg() call, it should have contents that make sense. Also, msg_controllen should correspond with the actual space consumed by the message. Not a single byte more. Change the logic to one of the following two. Solution 1: Simply set msg_controllen to zero entirely, so there is no message attached when sending. struct cmsghdr *cmsg = CMSG_FIRSTHDR(&message); if (fd >= 0) { message.msg_controllen = CMSG_SPACE(sizeof(fd)); cmsg->cmsg_len = CMSG_LEN(sizeof(fd)); cmsg->cmsg_level = SOL_SOCKET; cmsg->cmsg_type = SCM_RIGHTS; memcpy(CMSG_DATA(cmsg), &fd, sizeof(fd)); } else { message.msg_controllen = 0; } Solution 2: Send a SCM_RIGHTS message that contains no file descriptors. struct cmsghdr *cmsg = CMSG_FIRSTHDR(&message); cmsg->cmsg_level = SOL_SOCKET; cmsg->cmsg_type = SCM_RIGHTS; if (fd >= 0) { message.msg_controllen = CMSG_SPACE(sizeof(fd)); cmsg->cmsg_len = CMSG_LEN(sizeof(fd)); memcpy(CMSG_DATA(cmsg), &fd, sizeof(fd)); } else { message.msg_controllen = CMSG_SPACE(0); cmsg->cmsg_len = CMSG_LEN(0); } Also worth mentioning: char control[CMSG_SPACE(sizeof(int))]; That line is incorrect. The reason for this is that it may not be sufficiently aligned. You have to make sure that the control message buffer is aligned to at least 'struct cmsghdr', as CMSG_FIRSTHDR() will do nothing more than return the buffer directly. Change that line to one of the following two: #include alignas(struct cmsghdr) char control[CMSG_SPACE(sizeof(int))]; Or: union { struct cmsghdr a; char b[CMSG_SPACE(sizeof(int))]; } control; Best regards, -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 From owner-freebsd-current@freebsd.org Thu Aug 4 07:56: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 2B1C2BAE774; Thu, 4 Aug 2016 07:56:53 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 EC1FB1F77; Thu, 4 Aug 2016 07:56:52 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by mail-it0-x236.google.com with SMTP id u186so316976897ita.0; Thu, 04 Aug 2016 00:56:52 -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=d5/uh7CGZrBIoHGOke4fIFhM+qp9Zgzigl1Ijpw2tUk=; b=KtpZyNkII2Q2VojdCe4bFDjQOIuAl2cLn/XtKKMQL/zX4pQv0Uxej1EXz541Ru4RHR /NtAodMzmQnyVzgXTJKNKbfdo9sMKRa/BO84S4WHJVTvpT35h3UHu7KCAq5xiC30yKsk Bkvm79uL8uJiBjTBCCEs/u450ophJlyGthtZMZ0owFE4q3EDaFlLq3EWFmSl3a4w1gHl cLVN9EB6hFJBxGYHIB1g7cxpXMuRzApUsnzDe60tXKHkluoi5EZg8D08No6LMvvSDCZe HL146XHcmOlCv77UjWY47cjnyt/+H67lBCl6ElO3IoDad6Kln++Ej4+CpplWKTmQGDai sRqQ== 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=d5/uh7CGZrBIoHGOke4fIFhM+qp9Zgzigl1Ijpw2tUk=; b=AtC9zpR7lrH9wCCpU/Jlqj/eY7rAIgOILWYZjMcFT6bPEUWUTtHYQuT+XhSw6SJ2Yz 8p3Kz/v/Ptag18oXEc0LIxLDxEyLKPY9//dWTCaAChxP5236oC7Z9Q2z1+exV0Md12QG MA9fruE+E4N4QOaP9jxn2mJ9/gvTRFzUpoF7sn+ygoanFMDkx+ti17Dbf5DlB19uH33C Hriq8iT+V0lv5b2xQ2Y3RhwV5MvGizGpssO5k0Igu2uYwpNN+aOolZ7Zv6SUcwZkKeWJ XMQ/vl4LwUVwZ6xzql1jdKz3aPX5fTYtgCQabba2kcC4LttFmRAFUlN9m6n6r+autINk tHkQ== X-Gm-Message-State: AEkoouvaRs0mfs8EWmPyr/1Yv6r8AJPnJgJSgv7dHvACrznFH73YI6lId0saKjdPBPgX8VcXX9kOSGq25LND0g== X-Received: by 10.36.214.209 with SMTP id o200mr29059783itg.56.1470297411987; Thu, 04 Aug 2016 00:56:51 -0700 (PDT) MIME-Version: 1.0 Sender: kmacybsd@gmail.com Received: by 10.107.143.11 with HTTP; Thu, 4 Aug 2016 00:56:51 -0700 (PDT) From: "K. Macy" Date: Thu, 4 Aug 2016 00:56:51 -0700 X-Google-Sender-Auth: 23JC8GXRsyTBAiDrNqJifBG3vxw Message-ID: Subject: iwm load panic To: FreeBSD Current , "freebsd-net@freebsd.org" 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: Thu, 04 Aug 2016 07:56:53 -0000 I get this panic periodically at iwm load time: (kgdb) p ic->ic_tq value has been optimized out (kgdb) down #12 taskqueue_drain (queue=0x0, task=0xfffffe004fc17150) at /usr/home/mmacy/drm-next-4.6/sys/kern/subr_taskqueue.c:554 554 TQ_LOCK(queue); (kgdb) bt #0 __curthread () at ./machine/pcpu.h:221 #1 doadump (textdump=0) at /usr/home/mmacy/drm-next-4.6/sys/kern/kern_shutdown.c:298 #2 0xffffffff82703ac9 in vt_kms_postswitch (arg=) at /usr/home/mmacy/drm-next-4.6/sys/modules/drm2/drm2/../../../dev/drm2/linux_fb.c:82 #3 0xffffffff8093fb55 in vt_window_switch (vw=0xffffffff817e87d0 ) at /usr/home/mmacy/drm-next-4.6/sys/dev/vt/vt_core.c:540 #4 0xffffffff8093c9b0 in vtterm_cngrab (tm=) at /usr/home/mmacy/drm-next-4.6/sys/dev/vt/vt_core.c:1465 #5 0xffffffff80a78f12 in cngrab () at /usr/home/mmacy/drm-next-4.6/sys/kern/kern_cons.c:368 #6 0xffffffff80ae88c6 in vpanic (fmt=0xffffffff810f771b "%s", ap=0xfffffe0461098e70) at /usr/home/mmacy/drm-next-4.6/sys/kern/kern_shutdown.c:745 #7 0xffffffff80ae87b3 in panic (fmt=) at /usr/home/mmacy/drm-next-4.6/sys/kern/kern_shutdown.c:690 #8 0xffffffff80fc0361 in trap_fatal (frame=0xfffffe0461099170, eva=100) at /usr/home/mmacy/drm-next-4.6/sys/amd64/amd64/trap.c:841 #9 0xffffffff80fc0553 in trap_pfault (frame=0xfffffe0461099170, usermode=0) at /usr/home/mmacy/drm-next-4.6/sys/amd64/amd64/trap.c:691 #10 0xffffffff80fbfafc in trap (frame=0xfffffe0461099170) at /usr/home/mmacy/drm-next-4.6/sys/amd64/amd64/trap.c:442 #11 #12 taskqueue_drain (queue=0x0, task=0xfffffe004fc17150) at /usr/home/mmacy/drm-next-4.6/sys/kern/subr_taskqueue.c:554 #13 0xffffffff827823bb in ieee80211_draintask (ic=, task=0xfffffe004fc17150) at /usr/home/mmacy/drm-next-4.6/sys/net80211/ieee80211_var.h:796 #14 iwm_detach_local (sc=, do_net80211=) at /usr/home/mmacy/drm-next-4.6/sys/modules/iwm/../../dev/iwm/if_iwm.c:6121 #15 0xffffffff80b21e8c in run_interrupt_driven_config_hooks () at /usr/home/mmacy/drm-next-4.6/sys/kern/subr_autoconf.c:118 #16 0xffffffff80b21ccb in config_intrhook_establish (hook=) at /usr/home/mmacy/drm-next-4.6/sys/kern/subr_autoconf.c:182 #17 0xffffffff82781d03 in iwm_attach (dev=) at /usr/home/mmacy/drm-next-4.6/sys/modules/iwm/../../dev/iwm/if_iwm.c:5825 #18 0xffffffff80b26340 in DEVICE_ATTACH (dev=0xfffff8000744f700) at ./device_if.h:180 #19 device_attach (dev=0xfffff8000744f700) at /usr/home/mmacy/drm-next-4.6/sys/kern/subr_bus.c:2900 #20 0xffffffff8071730d in pci_driver_added (dev=, driver=) at /usr/home/mmacy/drm-next-4.6/sys/dev/pci/pci.c:4330 #21 0xffffffff80b23e9d in BUS_DRIVER_ADDED (_dev=0xfffff8000744f800, _driver=0xffffffff82790c08 ) at ./bus_if.h:204 #22 devclass_driver_added (dc=, driver=) at /usr/home/mmacy/drm-next-4.6/sys/kern/subr_bus.c:1099 #23 0xffffffff80b23e02 in devclass_add_driver (dc=, driver=, pass=, dcp=) at /usr/home/mmacy/drm-next-4.6/sys/kern/subr_bus.c:1172 #24 0xffffffff80ac2300 in module_register_init (arg=) at /usr/home/mmacy/drm-next-4.6/sys/kern/kern_module.c:123 #25 0xffffffff80ab3f14 in linker_file_sysinit (lf=) at /usr/home/mmacy/drm-next-4.6/sys/kern/kern_linker.c:234 #26 linker_load_file (filename=, result=) at /usr/home/mmacy/drm-next-4.6/sys/kern/kern_linker.c:434 #27 linker_load_module (kldname=, modname=0xfffff8000f0a8000 "if_iwm", parent=, verinfo=, lfpp=) at /usr/home/mmacy/drm-next-4.6/sys/kern/kern_linker.c:2024 #28 0xffffffff80ab5d48 in kern_kldload (td=, file=, fileid=0xfffffe0461099874) at /usr/home/mmacy/drm-next-4.6/sys/kern/kern_linker.c:1041 #29 0xffffffff80ab5eab in sys_kldload (td=0xfffff800966f1500, uap=) at /usr/home/mmacy/drm-next-4.6/sys/kern/kern_linker.c:1067 #30 0xffffffff80fc0cc8 in syscallenter (td=, sa=) at /usr/home/mmacy/drm-next-4.6/sys/amd64/amd64/../../kern/subr_syscall.c:135 #31 amd64_syscall (td=, traced=0) at /usr/home/mmacy/drm-next-4.6/sys/amd64/amd64/trap.c:942 #32 #33 0x000000080086d38a in ?? () From owner-freebsd-current@freebsd.org Thu Aug 4 07:59: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 47F62BAE9C7; Thu, 4 Aug 2016 07:59:54 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 14B0F14A9; Thu, 4 Aug 2016 07:59:54 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 35ED41FE022; Thu, 4 Aug 2016 09:59:52 +0200 (CEST) Subject: Re: iwm load panic To: "K. Macy" , FreeBSD Current , "freebsd-net@freebsd.org" References: From: Hans Petter Selasky Message-ID: Date: Thu, 4 Aug 2016 10:04:10 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.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, 04 Aug 2016 07:59:54 -0000 On 08/04/16 09:56, K. Macy wrote: > #12 taskqueue_drain (queue=0x0, task=0xfffffe004fc17150) at Hi, Looks like a NULL pointer, queue=NULL --HPS From owner-freebsd-current@freebsd.org Thu Aug 4 08:10: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 37CCCBAC089; Thu, 4 Aug 2016 08:10:50 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 024541C8C; Thu, 4 Aug 2016 08:10:50 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by mail-it0-x22b.google.com with SMTP id j124so256633711ith.1; Thu, 04 Aug 2016 01:10:49 -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=Fe7bJYFQ4S0gwbi/c6mBmabAM7a7dCE3VRhM7RA66Eg=; b=HoWTpm4ReE7CEL44h3AXVG0J9rz4FnHMc4PnUayovHG5qQxDLNRDGEkQkCxUd4GJ7O Qmvrincq/LP/bF9NA4ENO4Mtu/1OwLB2zI5GKLBa8/J/UYUPeL4ZbSVcGJHB/cKjNo8A wsC4fOS3om6iPBgU8KncQCtJE2T5etBSX6eaVQBve1x/5sXLRK+h8p1G+O/jMtXgbrf1 ouTtSINk70A31vFeDuUTwYFzXIT036wwuUpRZ6CpYyqz+xavEYkKVgYuy71yjVqmUf4g DGwoTO56X+bQ0DEWb8F83giplXCe3qXyf2aLpV3yGwlGYnGASBQYAtfjWHlbB8Z9sNb7 8X9g== 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=Fe7bJYFQ4S0gwbi/c6mBmabAM7a7dCE3VRhM7RA66Eg=; b=EGjpSvYMwJ09968z2jKGeu++fC9+MLBL2m8orMSWdo8nS5O48RPnuvMAgmlrbQwLF5 lJsT1XdsiS0KYHKKpJkLULrJ0HqQOMFp6rwPwQgUFMJXYsJ6pnHWvkHU1Ety+m+8ZL1T 6laom0hirwIO1E6Mvn7NZ5Sxqku4KUgsThULl3ZzheXlJBhAyJxNra6XpFlh7D1KKShJ RCQUxNz7/R4Zo4NdoM/fomCrtgJLSXLqYaFoIo/o5Tj7K8lLn1tXgTwhNX4o9p0qHew7 oAdKcTzmsaRuV6dgcj9guNXJwGaRu4cNRo84xlktq4mh0Q77TMpYi86x4cm08yn2nJMp Ni9w== X-Gm-Message-State: AEkoouuUixaM0Yma7mPE/csT/6ZRWQCtzwMZnDz1zTzxxLc/6NPd8Bky67JwGH9GDURYvvyC2e//I34igB19gQ== X-Received: by 10.36.14.68 with SMTP id 65mr34277334ite.99.1470298249497; Thu, 04 Aug 2016 01:10:49 -0700 (PDT) MIME-Version: 1.0 Sender: kmacybsd@gmail.com Received: by 10.107.143.11 with HTTP; Thu, 4 Aug 2016 01:10:49 -0700 (PDT) In-Reply-To: References: From: "K. Macy" Date: Thu, 4 Aug 2016 01:10:49 -0700 X-Google-Sender-Auth: Biqd4xiepADdGr0OGr6WpKh-6WA Message-ID: Subject: Re: iwm load panic To: Hans Petter Selasky Cc: FreeBSD Current , "freebsd-net@freebsd.org" 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: Thu, 04 Aug 2016 08:10:50 -0000 Uhm, yes. I can read that too. I'm suggesting that someone working on the iwm driver can fix it. On the boot immediately prior to this my system panicked with an assert in idr - which is much more my bailiwick. -M On Thu, Aug 4, 2016 at 1:04 AM, Hans Petter Selasky wrote: > On 08/04/16 09:56, K. Macy wrote: >> >> #12 taskqueue_drain (queue=0x0, task=0xfffffe004fc17150) at > > > Hi, > > Looks like a NULL pointer, queue=NULL > > --HPS From owner-freebsd-current@freebsd.org Thu Aug 4 16:23: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 DF729BAF0B7 for ; Thu, 4 Aug 2016 16:23:34 +0000 (UTC) (envelope-from me@cschwarz.com) Received: from orion.uberspace.de (orion.uberspace.de [95.143.172.79]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 378F71E87 for ; Thu, 4 Aug 2016 16:23:33 +0000 (UTC) (envelope-from me@cschwarz.com) Received: (qmail 27497 invoked from network); 4 Aug 2016 16:23:22 -0000 Received: from localhost (HELO csarch) (127.0.0.1) by orion.uberspace.de with SMTP; 4 Aug 2016 16:23:22 -0000 Date: Thu, 4 Aug 2016 18:23:20 +0200 From: Christian Schwarz To: freebsd-current@freebsd.org Subject: Re: iwm load panic Message-ID: <20160804162320.GC26444@csarch> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.2 (2016-07-01) 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, 04 Aug 2016 16:23:35 -0000 Any idea which revision/commit introduced this regression? (I want to test iwm + freebsd-base-graphics on my laptop tonight and hence avoid crashers like this one in advance.) @mmacy: is the revision in the current drm-next-4.6 branch of https://github.com/FreeBSDDesktop/freebsd-base-graphics.git Thanks, -- Christian Schwarz From owner-freebsd-current@freebsd.org Thu Aug 4 17:53: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 28B71BADAE8 for ; Thu, 4 Aug 2016 17:53:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 15C391FB0 for ; Thu, 4 Aug 2016 17:53:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 151EABADAE7; Thu, 4 Aug 2016 17:53:19 +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 14C53BADAE6 for ; Thu, 4 Aug 2016 17:53:19 +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 CAFF21FAF for ; Thu, 4 Aug 2016 17:53:18 +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 E55E4B98C; Thu, 4 Aug 2016 13:53:17 -0400 (EDT) From: John Baldwin To: gljennjohn@gmail.com Cc: current@freebsd.org Subject: Re: EARLY_AP_STARTUP hangs during boot Date: Thu, 04 Aug 2016 10:34:48 -0700 Message-ID: <3133061.id72CNzR69@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.3-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20160804085906.2228aa0b@ernst.home> References: <20160516122242.39249a54@ernst.home> <4473265.DhpanzHFA4@ralph.baldwin.cx> <20160804085906.2228aa0b@ernst.home> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 04 Aug 2016 13:53:18 -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: Thu, 04 Aug 2016 17:53:19 -0000 On Thursday, August 04, 2016 08:59:06 AM Gary Jennejohn wrote: > On Tue, 02 Aug 2016 10:41:23 -0700 > John Baldwin wrote: > > > On Tuesday, August 02, 2016 09:03:10 AM Gary Jennejohn wrote: > > > On Mon, 01 Aug 2016 13:19:16 -0700 > > > John Baldwin wrote: > > > > > > > On Monday, August 01, 2016 03:31:11 PM Gary Jennejohn wrote: > > > > > On Mon, 1 Aug 2016 09:34:34 +0200 > > > > > Gary Jennejohn wrote: > > > > > > > > > > > On Sun, 31 Jul 2016 14:22:35 -0700 > > > > > > John Baldwin wrote: > > > > > > > > > > > > > On Sunday, July 31, 2016 11:29:14 AM Gary Jennejohn wrote: > > > > > > > > On Sat, 30 Jul 2016 12:03:59 -0700 > > > > > > > > John Baldwin wrote: > > > > > > > > > > > > > > > > > On Saturday, July 30, 2016 09:44:22 AM Gary Jennejohn wrote: > > > > > > > > > > On Fri, 29 Jul 2016 13:17:42 -0700 > > > > > > > > > > John Baldwin wrote: > > > > > > > > > > > > > > > > > > > > > On Thursday, July 28, 2016 12:31:31 AM Gary Jennejohn wrote: > > > > > > > > > > > > Well, now I know that ULE is a prerequiste for EARLY_AP_STARTUP! I > > > > > > > > > > > > wasn't aware of that. I prefer BSD and that's the scheduler I did > > > > > > > > > > > > the first tests with. > > > > > > > > > > > > > > > > > > > > > > > > But with the ULE scheduler the system comes up all the way. > > > > > > > > > > > > > > > > > > > > > > > > It would be nice if the BSD scheduler could also be modified to > > > > > > > > > > > > work with EARLY_AP_STARTUP. > > > > > > > > > > > > > > > > > > > > > > I wasn't able to reproduce your hang with 4BSD, but I think I see a > > > > > > > > > > > possible problem. Try this: > > > > > > > > > > > > > > > > > > > > > > diff --git a/sys/kern/sched_4bsd.c b/sys/kern/sched_4bsd.c > > > > > > > > > > > index 7de56b6..d53331a 100644 > > > > > > > > > > > --- a/sys/kern/sched_4bsd.c > > > > > > > > > > > +++ b/sys/kern/sched_4bsd.c > > > > > > > > > > > @@ -327,7 +327,6 @@ maybe_preempt(struct thread *td) > > > > > > > > > > > * - The current thread has a higher (numerically lower) or > > > > > > > > > > > * equivalent priority. Note that this prevents curthread from > > > > > > > > > > > * trying to preempt to itself. > > > > > > > > > > > - * - It is too early in the boot for context switches (cold is set). > > > > > > > > > > > * - The current thread has an inhibitor set or is in the process of > > > > > > > > > > > * exiting. In this case, the current thread is about to switch > > > > > > > > > > > * out anyways, so there's no point in preempting. If we did, > > > > > > > > > > > @@ -348,7 +347,7 @@ maybe_preempt(struct thread *td) > > > > > > > > > > > ("maybe_preempt: trying to run inhibited thread")); > > > > > > > > > > > pri = td->td_priority; > > > > > > > > > > > cpri = ctd->td_priority; > > > > > > > > > > > - if (panicstr != NULL || pri >= cpri || cold /* || dumping */ || > > > > > > > > > > > + if (panicstr != NULL || pri >= cpri /* || dumping */ || > > > > > > > > > > > TD_IS_INHIBITED(ctd)) > > > > > > > > > > > return (0); > > > > > > > > > > > #ifndef FULL_PREEMPTION > > > > > > > > > > > @@ -1127,7 +1126,7 @@ forward_wakeup(int cpunum) > > > > > > > > > > > if ((!forward_wakeup_enabled) || > > > > > > > > > > > (forward_wakeup_use_mask == 0 && forward_wakeup_use_loop == 0)) > > > > > > > > > > > return (0); > > > > > > > > > > > - if (!smp_started || cold || panicstr) > > > > > > > > > > > + if (!smp_started || panicstr) > > > > > > > > > > > return (0); > > > > > > > > > > > > > > > > > > > > > > forward_wakeups_requested++; > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, but with this patch the kernel hangs in exactly the same > > > > > > > > > > place as before - after the HPET output. > > > > > > > > > > > > > > > > > > > > Maybe I'm missing some kernel option which ULE works around, or > > > > > > > > > > something like that. > > > > > > > > > > > > > > > > > > Hmm, ok. Please add KTR_RUNQ and KTR_SMP to the KTR masks, that is > > > > > > > > > 'options KTR_COMPILE=(KTR_PROC|KTR_RUNQ|KTR_SMP)' and > > > > > > > > > 'options KTR_MASK=(KTR_PROC|KTR_RUNQ|KTR_SMP)' > > > > > > > > > > > > > > > > > > Please also add this patch (on top of the previous patch): > > > > > > > > > > > > > > > > > > diff --git a/sys/kern/sched_4bsd.c b/sys/kern/sched_4bsd.c > > > > > > > > > index 2973a23..bab2278 100644 > > > > > > > > > --- a/sys/kern/sched_4bsd.c > > > > > > > > > +++ b/sys/kern/sched_4bsd.c > > > > > > > > > @@ -1278,6 +1278,8 @@ sched_add(struct thread *td, int flags) > > > > > > > > > KASSERT(td->td_flags & TDF_INMEM, > > > > > > > > > ("sched_add: thread swapped out")); > > > > > > > > > > > > > > > > > > + CTR2(KTR_PROC, "sched_add: thread %d (%s)", td->td_tid, > > > > > > > > > + sched_tdname(td)); > > > > > > > > > KTR_STATE2(KTR_SCHED, "thread", sched_tdname(td), "runq add", > > > > > > > > > "prio:%d", td->td_priority, KTR_ATTR_LINKED, > > > > > > > > > sched_tdname(curthread)); > > > > > > > > > diff --git a/sys/x86/x86/cpu_machdep.c b/sys/x86/x86/cpu_machdep.c > > > > > > > > > index f07b97e..1f418f1 100644 > > > > > > > > > --- a/sys/x86/x86/cpu_machdep.c > > > > > > > > > +++ b/sys/x86/x86/cpu_machdep.c > > > > > > > > > @@ -440,6 +440,7 @@ cpu_idle_wakeup(int cpu) > > > > > > > > > return (0); > > > > > > > > > if (*state == STATE_MWAIT) > > > > > > > > > *state = STATE_RUNNING; > > > > > > > > > + CTR1(KTR_PROC, "cpu_idle_wakeup: wokeup CPU %d", cpu); > > > > > > > > > return (1); > > > > > > > > > } > > > > > > > > > > > > > > > > > > (I haven't tried compiling it, you might have to add the sys/ktr.h > > > > > > > > > header to cpu_machdep.c if it doesn't build.) > > > > > > > > > > > > > > > > > > Hopefully we will get some better trace messages before it hangs > > > > > > > > > with this added info. The root issue seems to be that 4BSD is > > > > > > > > > pinning thread0 to some other CPU (due to sched_bind that happens > > > > > > > > > inside of bus_bind_intr() when the HPET driver pins IRQs to CPUs) > > > > > > > > > and that other CPU isn't waking up to realize it needs to run thread0. > > > > > > > > > > > > > > > > > > > > > > > > > It compiled with no changes needed. > > > > > > > > > > > > > > > > Even though I set MAXCPU to a mere 2, the boot still hadn't > > > > > > > > completed after 90 minutes and I broke it off. I still have > > > > > > > > the kernel, so I can try it another time when I have less need > > > > > > > > for my FreeBSD box. > > > > > > > > > > > > > > Did you have the KTR options enabled from before? I don't expect this > > > > > > > to fix the issue, this is more about getting better debug info when it > > > > > > > hangs. > > > > > > > > > > > > > > > > > > > Yes, all the options from before were enabled. Maybe I should have > > > > > > disabled KTR_VERBOSE=1? I'll try it without that. > > > > > > > > > > > > > > > > KTR_VERBOSE=1 is necessary. > > > > > > > > Yes. > > > > > > > > > OK, after about 5 hours it landed in an infinite loop emitting: > > > > > > > > > > cpu_0 ipi_cpu: cpu: 1 to 5 ipi: 2 (my CPU has 6 cores) > > > > > > > > Humm, can you capture a picture right when it hangs? Those interrupts > > > > are due to clock interrupts (IPI_HARDCLOCK) and are noise. More what > > > > I'm trying to see is if we send IPI_AST/IPI_PREEMPT to the CPU after > > > > binding to it. > > > > > > > > > > I can't tell when it hangs due to the amount of trace coming out. > > > The hang is hidden in the noise and I have no way to suppress the > > > trace that I'm aware of. The trace is coming so fast that even > > > a photo of the screen looks smeared. > > > > > > Is there a way to limit the trace to IPI_AST/IPI_PREEMPT? > > > > Yes: > > > > diff --git a/sys/x86/x86/mp_x86.c b/sys/x86/x86/mp_x86.c > > index 91c119a..6c57b20 100644 > > --- a/sys/x86/x86/mp_x86.c > > +++ b/sys/x86/x86/mp_x86.c > > @@ -1160,7 +1160,8 @@ ipi_cpu(int cpu, u_int ipi) > > if (ipi == IPI_STOP_HARD) > > CPU_SET_ATOMIC(cpu, &ipi_stop_nmi_pending); > > > > - CTR3(KTR_SMP, "%s: cpu: %d ipi: %x", __func__, cpu, ipi); > > + if (ipi == IPI_AST || ipi == IPI_PREEMPT) > > + CTR3(KTR_SMP, "%s: cpu: %d ipi: %x", __func__, cpu, ipi); > > ipi_send_cpu(cpu, ipi); > > } > > > > > > I limited output to KTR_SMP and used only the patch above. > > The last lines which appear are: > hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 > on acpi0 > cpu0: smp_targeted_tlb_shootdown: cpu: 1 ipi: f6 > cpu0: smp_targeted_tlb_shootdown: cpu: 2 ipi: f6 > cpu0: smp_targeted_tlb_shootdown: cpu: 3 ipi: f6 > cpu0: smp_targeted_tlb_shootdown: cpu: 4 ipi: f6 > cpu0: smp_targeted_tlb_shootdown: cpu: 5 ipi: f6 > Timecounter "HPET" frequency 14318180 Hz qualty 950 Hmm, no lines with mi_switch like you saw before? -- John Baldwin From owner-freebsd-current@freebsd.org Thu Aug 4 21:17: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 95B85BAFD41; Thu, 4 Aug 2016 21:17: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 8867F15F3; Thu, 4 Aug 2016 21:17: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 3E80418E1; Thu, 4 Aug 2016 21:17:10 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Thu, 4 Aug 2016 21:17:09 +0000 From: Glen Barber To: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Cc: FreeBSD Release Engineering Team Subject: 11.0-RELEASE schedule update Message-ID: <20160804211709.GA58642@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uAKRQypu60I7Lcqm" Content-Disposition: inline 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: Thu, 04 Aug 2016 21:17:10 -0000 --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline As those of you tracking our PR system are probably aware, re@ is aware of an issue related to ZFS and VFS that we feel is urgent enough to have fixed for 11.0-RELEASE. https://lists.freebsd.org/pipermail/freebsd-current/2016-August/062829.html As such, instead of branching releng/11.0 today and starting 11.0-RC1 builds, BETA4 will be added to the 11.0 release schedule, since the level of possible intrusiveness would be extremely difficult to fix with an Errata Notice after 11.0-RELEASE. The 11.0-RELEASE schedule has been updated on the website to account for the BETA4 addition: https://www.freebsd.org/releases/11.0R/schedule.html Thank you for your patience. Glen On behalf of: re@ --uAKRQypu60I7Lcqm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXo7DVAAoJEAMUWKVHj+KTjYgQAJSGMO60B7+QROuYDs2d44QU qPHrU9AWEaHn0xCZnkc3fVonIafh3tjl6WSZbgHJBPQon4DNz6sqhfXl6ydV8AQA ZjwLYwy6rCVPsLxPkRp9hiaXSdOCmCyqqZwECdyXevMAuSRCcNs+a5eshLVO/H/S mwyIKwO1tLKxD5G3olX9eJRwsT0ilntBRnWslXG4CZZlyEgYPSbjyCWEUlAosoaJ hnp9KoYWiSlQkJYXLfTTVgmYHDCSOxlHQAOEGLMJIfvabja/h2akAUrL87omeCvQ 4/yXhktHyEvgSY60VrQyxK66kESCp8psLEgJ5uIq2qsJGaCzHaIdeBtOJlpasnvB UxiNmrIdONYylxVxa3A4rkewJYIzTDpZ6Q0cPJR8GHc8vk1WaPn4ouNmuPkMmHc4 L7Tqw8TAyCuyPiOIm0WzC0ru2sA2n1rUqD1Tl5jwacttOqJftOdUxmcZPWXyGcTX cem2sfOH3uZkvPIEOk5KDOXpxJZcMaTlpoAhW5x12XzzcbObWnFy3CSKMBqznyWx YenFC+SfRz+W8ck7XWzBZPL9T4uOLziMBdF99jgnBHA/j9KDFBehFYrJxmG4Pr5a z//gxHE6nITU+QGz2aFOblrP6VB1prnLwOBaUZvszLTz3CWhrXqYF+lFW4zbCdkL 52jHZdkEq0Bd7BZNpZch =4pQT -----END PGP SIGNATURE----- --uAKRQypu60I7Lcqm-- From owner-freebsd-current@freebsd.org Thu Aug 4 21:40: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 B7B54BAF285 for ; Thu, 4 Aug 2016 21:40:40 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::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 7FAE713B0 for ; Thu, 4 Aug 2016 21:40:40 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by mail-io0-x230.google.com with SMTP id 38so283434276iol.0 for ; Thu, 04 Aug 2016 14:40:40 -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=7IcgAgYh/mhrRtOzGeFqLhg386tAbxnvW/roDaIZvuY=; b=BSLlYj9EKJOXCuLdQw4S3Tthdy920xE0jXZVm+zw+7inB+skS3MV7w9mgI/796UuNc aLTEFJvJUQFgwlTPbtcYG+V8EUs80Mm5fkoirdZ9BN0IB3b0W836rf0D+SJORjHSMaQX AjX90lDxN7SXBdRzqRUEneKn2hgy448aNg3wbxc8UPCb1ua8biGD1eaCuTsL2h6/VBnG 1n7/1juvoYYNpJC2ypIENSYnCmp1CYiRYN5fLqs96+NLrcVG1TSE/kBrPXE7jMCRWywX ZIcu1DP5k2TogSwkbKMbGFM/WYUUZConWQVG1t6bR1AnXFvyQSF01GiQ1kpQC8MKrjH7 pHLg== 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=7IcgAgYh/mhrRtOzGeFqLhg386tAbxnvW/roDaIZvuY=; b=K00RndGtYQlAlH/mapAOus75OdK/5nQyuF9i+vTjmEpI1HqMpWgLYGhgCowfqK9NMT sBudzCs1Mq8JRHFM0Jh16B0TVzttsp0AlbeDSL/idHIY6wG4Q1FBSQvBanf5ywJ34W4B EsXxX9f0ANqEZ/O7VaRunJAzobZug57/6jqPSaLFvRVbDVx6k34xc7IsgSaXy8G3/K9k fE2UZBtmPG5FpRGhYD3Akemj5GxllJVUpHnti5FwhCPP9VJDRy0XtAFx9lTKoh3J6T90 FsIlsaoytVbfJwigPTjo9QdhKA8Wz4s1gCkH9jzdm2sPUwZEkbhY6Hr0x5OGX/C9aHNA eM8A== X-Gm-Message-State: AEkoouuKcyofNZo25/S6b+ncLs90jD93oeaSTYpB30ZPYyJxjY3BIGEAx2U2LYYxkmSeipYzUv1CpDAj4K0h9w== X-Received: by 10.107.29.67 with SMTP id d64mr73792020iod.138.1470346839461; Thu, 04 Aug 2016 14:40:39 -0700 (PDT) MIME-Version: 1.0 Sender: kmacybsd@gmail.com Received: by 10.107.143.11 with HTTP; Thu, 4 Aug 2016 14:40:38 -0700 (PDT) In-Reply-To: <20160804162320.GC26444@csarch> References: <20160804162320.GC26444@csarch> From: "K. Macy" Date: Thu, 4 Aug 2016 14:40:38 -0700 X-Google-Sender-Auth: VHbmxfnLGmSTuxp4XZMjxUo-cRk Message-ID: Subject: Re: iwm load panic To: Christian Schwarz 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, 04 Aug 2016 21:40:40 -0000 On Thursday, August 4, 2016, Christian Schwarz wrote: > Any idea which revision/commit introduced this regression? > > (I want to test iwm + freebsd-base-graphics on my laptop tonight and > hence avoid crashers like this one in advance.) > > @mmacy: is the revision in the current drm-next-4.6 branch of > https://github.com/FreeBSDDesktop/freebsd-base-graphics.git > > Yes. That is what I run on my Skylake based gen4 carbon x1. 8260 support was just added, so I don't know if it's possible to use new hardware without exposing one's self to this bug. In fairness, 80-85% of the time it loads just fine, and this bug looks much easier to fix than the various issues I am looking at right now. Once loaded the driver has worked quite satisfactorily. -M > Thanks, > > -- > Christian Schwarz > > > _______________________________________________ > 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 4 21:44: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 CC9B3BAF3C9 for ; Thu, 4 Aug 2016 21:44:16 +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 6153B17A5 for ; Thu, 4 Aug 2016 21:44:16 +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 3s53Ns57v2z16q for ; Thu, 4 Aug 2016 23:44:13 +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=1470347050; x=1472939051; bh=/E9 2ywG7fN3n4mVpfMJE4Iv7HOhfsQWimqRYrZJpmxQ=; b=FCTRvbDVkqsM3X9qMew f67iKF7l4scu8oFNnMVPWpvYrk69frpauDM2ktXDZj5c2/wsU6v5YhR2SCSuWNol ILRhWNNdZsRG6kK40eqVtULEGusybju9MGgSr+U020HdSp3pTTn/LFf5oT5LUnSZ HAlsID5sNAoxEYhMYaB4cS+E= 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 v-EQy3lDxF-O for ; Thu, 4 Aug 2016 23:44:10 +0200 (CEST) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP id 3s53Np3bqVz16n for ; Thu, 4 Aug 2016 23:44:10 +0200 (CEST) Received: from nabiralnik.ijs.si (nabiralnik.ijs.si [IPv6:2001:1470:ff80::80:16]) by mildred.ijs.si (Postfix) with ESMTP id 3s53Np2llszb for ; Thu, 4 Aug 2016 23:44:10 +0200 (CEST) Received: from sleepy.ijs.si (2001:1470:ff80:e001::1:1) by webmail.ijs.si with HTTP (HTTP/1.1 POST); Thu, 04 Aug 2016 23:44:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 04 Aug 2016 23:44:10 +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: <3629a441-ee6d-2407-fa13-5ebd8db8d802@freebsd.org> References: <3629a441-ee6d-2407-fa13-5ebd8db8d802@freebsd.org> Message-ID: <000c29ee0f3dbd1d433c565023d69e25@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: Thu, 04 Aug 2016 21:44:16 -0000 Should I open a bug report, or has the problem been noted? Mark On 2016-08-04 04:32, Julian Elischer wrote: > On 4/08/2016 7:24 AM, Mark Martinec wrote: >> Is it normal/expected/documented that the date(1) command in 11.0 >> now produces a timestamp in substantially different format >> in an "en_US.UTF-8" locale (long names, commas, 12 vs. 24h hour time): >> >> Thursday, August 4, 2016 at 12:50:43 AM CEST >> vs: >> Thu Aug 4 00:52:29 CEST 2016 >> > one of those is a bug. the formats are defined in posix I believe. > >> >> Setting LC_TIME does not help: >> >> $ LC_TIME="C" date >> Thursday, August 4, 2016 at 01:13:37 AM CEST >> >> although LC_ALL="C" _does_ help. >> >> >> This is funny too, especially regarding commas: >> $ LC_ALL="en_GB.UTF-8" date >> Thursday 4 August 2016 at 01:16:45 CEST >> $ LC_ALL="en_US.UTF-8" date >> Thursday, August 4, 2016 at 01:16:54 AM CEST >> >> >> The date(1) man page states: >> The date utility is expected to be compatible with IEEE Std 1003.2 >> (“POSIX.2â€). >> What does POSIX.2 say about date(1) following a locale? >> >> >> >> ====== >> 11.0-BETA3: >> >> $ date >> Thursday, August 4, 2016 at 12:50:43 AM CEST >> >> $ uname -a >> FreeBSD xxx.ijs.si 11.0-BETA3 FreeBSD 11.0-BETA3 #0 r303469: Fri Jul >> 29 02:27:28 UTC 2016 >> root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 >> >> $ locale >> LANG= >> LC_CTYPE="en_US.UTF-8" >> LC_COLLATE="en_US.UTF-8" >> LC_TIME="en_US.UTF-8" >> LC_NUMERIC="en_US.UTF-8" >> LC_MONETARY="en_US.UTF-8" >> LC_MESSAGES="en_US.UTF-8" >> LC_ALL=en_US.UTF-8 >> >> ====== >> 10.3-RELEASE-p6 : >> >> $ date >> Thu Aug 4 00:52:29 CEST 2016 >> >> $ freebsd-version >> 10.3-RELEASE-p6 >> >> $ uname -a >> FreeBSD yyy.ijs.si 10.3-RELEASE-p4 FreeBSD 10.3-RELEASE-p4 #0: Sat May >> 28 12:23:44 UTC 2016 >> root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 >> >> $ locale >> LANG= >> LC_CTYPE="en_US.UTF-8" >> LC_COLLATE="en_US.UTF-8" >> LC_TIME="en_US.UTF-8" >> LC_NUMERIC="en_US.UTF-8" >> LC_MONETARY="en_US.UTF-8" >> LC_MESSAGES="en_US.UTF-8" >> LC_ALL=en_US.UTF-8 >> >> >> >> Mark From owner-freebsd-current@freebsd.org Fri Aug 5 01:32: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 4621ABAC70E for ; Fri, 5 Aug 2016 01:32: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 273711FCB for ; Fri, 5 Aug 2016 01:32: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 u751WE75016607 for ; Thu, 4 Aug 2016 18:32:18 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201608050132.u751WE75016607@gw.catspoiler.org> Date: Thu, 4 Aug 2016 17:10:29 -0700 (PDT) From: Don Lewis Subject: kernel panic caused by virtualbox(?) 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: Fri, 05 Aug 2016 01:32:21 -0000 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 From owner-freebsd-current@freebsd.org Fri Aug 5 01:59: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 90377BACDC1; Fri, 5 Aug 2016 01:59:19 +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 84C401B22; Fri, 5 Aug 2016 01:59:19 +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 3A29516F5; Fri, 5 Aug 2016 01:59:19 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Fri, 5 Aug 2016 01:59:18 +0000 From: Glen Barber To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-announce@freebsd.org Subject: HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0 Message-ID: <20160805015918.GI43509@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: Fri, 05 Aug 2016 01:59:19 -0000 -----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----- From owner-freebsd-current@freebsd.org Fri Aug 5 02:09: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 25B69BAF62C; Fri, 5 Aug 2016 02:09:52 +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 170DE1631; Fri, 5 Aug 2016 02:09:52 +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 BF4C31939; Fri, 5 Aug 2016 02:09:51 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Fri, 5 Aug 2016 02:09:50 +0000 From: Glen Barber To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-announce@freebsd.org Subject: Re: HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0 Message-ID: <20160805020950.GJ43509@FreeBSD.org> References: <20160805015918.GI43509@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="J+eNKFoVC4T1DV3f" Content-Disposition: inline In-Reply-To: <20160805015918.GI43509@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: Fri, 05 Aug 2016 02:09:52 -0000 --J+eNKFoVC4T1DV3f Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 05, 2016 at 01:59:18AM +0000, 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). >=20 Stupid editor mistake. OpenSSH DSA keys are deprecated upstream. Sorry for any confusion. > 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@ --J+eNKFoVC4T1DV3f Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXo/VuAAoJEAMUWKVHj+KT8/AP/14kAQTyL++trYzTgp+6cUJ2 Y8jJPg6agpXHHJMCjyfkbEnFUQnlPk4+SSfHxVP95VgHzukpJqJA4oQL7tWL8Vna 3LFU2Wg3TAMbh5TE9fSZ610NTRgNt0uLmeXEojgON4lH0JE9ju8dqWja6UNyHvgU yRv7RRorUarA3qGDWUm0u73o+OabYmcUhQ7/ghNi3hij90mvbbuOllK2aYRAZRCI n2rN6fErnCEpYetvwOUuordx5u0pU9ta2dwOTPDOmoFQ5mKYCTeSj+IXhzJV7hS2 SyUTYtfhqL8t0+p9SG5ZWQl/5CRnxPlamvs7/FRARTNZudX9r9fCXE622z13eZe/ 1Xc8FDCfMHaW9VNirSsMT5pPh3O+cCREgWdyUB94rKONllpBInAZhvAaiHxjddZ9 VFFAoo9VOPmrwtM+66RSifqJ3BUNDa+vRxiX+3/46D0VPARENhgu15BXNp3BNx1/ UihNZ0hSaSn9M279zlAcvVVPbLYmqlCf28URlopC2ug+Y6GYC+KvwdEZAJg0yANO sYvAbVmAXMuvMTq4AaKAMPW/84q+n90oTqjjQErAZfGPycL7LBJRRULQ2hLmSdbe L8KdR2trq0SDYG385ROyf4CaK4BuE2XaCgWdIG+3+KgI03lLX6dhXlFkMzJLbIpb qD4d24HR1OMzOuDlwbig =ORzJ -----END PGP SIGNATURE----- --J+eNKFoVC4T1DV3f-- From owner-freebsd-current@freebsd.org Fri Aug 5 05:00: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 239BCBAEE51 for ; Fri, 5 Aug 2016 05:00:39 +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 EB54713B6 for ; Fri, 5 Aug 2016 05:00:38 +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 u7550XPu004515 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 4 Aug 2016 22:00:36 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: date(1) default format changed between 10.3 and 11.0-BETA3 To: Mark Martinec , freebsd-current@freebsd.org References: <3629a441-ee6d-2407-fa13-5ebd8db8d802@freebsd.org> <000c29ee0f3dbd1d433c565023d69e25@mailbox.ijs.si> From: Julian Elischer Message-ID: Date: Fri, 5 Aug 2016 13:00:28 +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: <000c29ee0f3dbd1d433c565023d69e25@mailbox.ijs.si> 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, 05 Aug 2016 05:00:39 -0000 On 5/08/2016 5:44 AM, Mark Martinec wrote: > Should I open a bug report, or has the problem been noted? it's not clear without reading the standard whether the bug is in the old or new version. have you tried other systems? In particular I'd check OSX sh-3.2$ export LC_CTYPE="en_US.UTF-8" sh-3.2$ export LC_TIME="en_US.UTF-8" sh-3.2$ export LC_ALL="en_US.UTF-8" sh-3.2$ export LC_NUMERIC="en_US.UTF-8" sh-3.2$ date Fri Aug 5 12:57:47 AWST 2016 if it IS a bug then yes, file a report with full reproduction steps. > > Mark > > > On 2016-08-04 04:32, Julian Elischer wrote: >> On 4/08/2016 7:24 AM, Mark Martinec wrote: >>> Is it normal/expected/documented that the date(1) command in 11.0 >>> now produces a timestamp in substantially different format >>> in an "en_US.UTF-8" locale (long names, commas, 12 vs. 24h hour >>> time): >>> >>> Thursday, August 4, 2016 at 12:50:43 AM CEST >>> vs: >>> Thu Aug 4 00:52:29 CEST 2016 >>> >> one of those is a bug. the formats are defined in posix I believe. >> >>> >>> Setting LC_TIME does not help: >>> >>> $LC_TIME="C" date >>> Thursday, August 4, 2016 at 01:13:37 AM CEST >>> >>> although LC_ALL="C" _does_ help. >>> >>> >>> This is funny too, especially regarding commas: >>> $ LC_ALL="en_GB.UTF-8" date >>> Thursday 4 August 2016 at 01:16:45 CEST >>> $ LC_ALL="en_US.UTF-8" date >>> Thursday, August 4, 2016 at 01:16:54 AM CEST >>> >>> >>> The date(1) man page states: >>> The date utility is expected to be compatible with IEEE Std 1003.2 >>> (“POSIX.2â€). >>> What does POSIX.2 say about date(1) following a locale? >>> >>> >>> >>> ====== >>> 11.0-BETA3: >>> >>> $ date >>> Thursday, August 4, 2016 at 12:50:43 AM CEST >>> >>> $ uname -a >>> FreeBSD xxx.ijs.si 11.0-BETA3 FreeBSD 11.0-BETA3 #0 r303469: Fri >>> Jul 29 02:27:28 UTC 2016 >>> root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 >>> >>> $ locale >>> LANG= >>> LC_CTYPE="en_US.UTF-8" >>> LC_COLLATE="en_US.UTF-8" >>> LC_TIME="en_US.UTF-8" >>> LC_NUMERIC="en_US.UTF-8" >>> LC_MONETARY="en_US.UTF-8" >>> LC_MESSAGES="en_US.UTF-8" >>> LC_ALL=en_US.UTF-8 >>> >>> ====== >>> 10.3-RELEASE-p6 : >>> >>> $ date >>> Thu Aug 4 00:52:29 CEST 2016 >>> >>> $ freebsd-version >>> 10.3-RELEASE-p6 >>> >>> $ uname -a >>> FreeBSD yyy.ijs.si 10.3-RELEASE-p4 FreeBSD 10.3-RELEASE-p4 #0: Sat >>> May 28 12:23:44 UTC 2016 >>> root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 >>> >>> $ locale >>> LANG= >>> LC_CTYPE="en_US.UTF-8" >>> LC_COLLATE="en_US.UTF-8" >>> LC_TIME="en_US.UTF-8" >>> LC_NUMERIC="en_US.UTF-8" >>> LC_MONETARY="en_US.UTF-8" >>> LC_MESSAGES="en_US.UTF-8" >>> LC_ALL=en_US.UTF-8 >>> >>> >>> >>> Mark > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@freebsd.org Fri Aug 5 06:37: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 E2208BAF554; Fri, 5 Aug 2016 06:37:37 +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 0F7541259; Fri, 5 Aug 2016 06:37:36 +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 JAA23291; Fri, 05 Aug 2016 09:37:28 +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 1bVYl6-000PPh-LR; Fri, 05 Aug 2016 09:37:28 +0300 Subject: Re: some [big] changes to ZPL (ZFS<->VFS ) To: FreeBSD Filesystems , FreeBSD Current References: <3f79e88d-a519-0c8d-f16a-7c83460a37c1@FreeBSD.org> From: Andriy Gapon Message-ID: <04a12279-ab01-5f5c-d8d3-5571db07c229@FreeBSD.org> Date: Fri, 5 Aug 2016 09:36:35 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <3f79e88d-a519-0c8d-f16a-7c83460a37c1@FreeBSD.org> 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: Fri, 05 Aug 2016 06:37:38 -0000 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 From owner-freebsd-current@freebsd.org Fri Aug 5 08:48:20 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6BD94BAE485 for ; Fri, 5 Aug 2016 08:48:20 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [IPv6:2001:8b0:151:1:c4ea:bd49:619b:6cb3]) (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 EFC2F11DE for ; Fri, 5 Aug 2016 08:48:19 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from ox-dell39.ox.adestra.com (unknown [85.199.232.226]) (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 EC57B8E85 for ; Fri, 5 Aug 2016 08:48:14 +0000 (UTC) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=infracaninophile.co.uk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infracaninophile.co.uk; s=201601-infracaninophile; t=1470386895; bh=UYoq3ALLgbwPKOvZ+lhzRzXQorXi7UWYVPfM3DsUDLc=; h=Subject:To:References:From:Date:In-Reply-To; z=Subject:=20Re:=20HEADS-UP:=20OpenSSH=20DSA=20keys=20are=20depreca ted=20in=2012.0=20and=2011.0|To:=20freebsd-current@freebsd.org|Ref erences:=20<20160805015918.GI43509@FreeBSD.org>=0D=0A=20<201608050 20950.GJ43509@FreeBSD.org>|From:=20Matthew=20Seaman=20|Date:=20Fri,=205=20Aug=202016=2009:48:02=20+ 0100|In-Reply-To:=20<20160805020950.GJ43509@FreeBSD.org>; b=dZO5pXxfWbM0CF5pFIK8B1rAi29tj25qPWQMpWneHqa/NZA6tHT4Nzb8aBdH0dBUp FCYk1/43jRPWEmFYaqB1Plmh1wyLYT4Wzc6vW18nt+q7lFscqly6UovjMVm3OmlC29 U2yUdFczrlZ1oZCv5JwGX4qXbt81ftamxCKVH4Kk= Subject: Re: HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0 To: freebsd-current@freebsd.org References: <20160805015918.GI43509@FreeBSD.org> <20160805020950.GJ43509@FreeBSD.org> From: Matthew Seaman Message-ID: <688e5574-10e3-05a6-3346-6ad8150c998b@infracaninophile.co.uk> Date: Fri, 5 Aug 2016 09:48:02 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160805020950.GJ43509@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WKsnPtME8PjevS7v1cSVPoaNErM8fesnu" X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,RDNS_NONE,SPF_FAIL 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: Fri, 05 Aug 2016 08:48:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WKsnPtME8PjevS7v1cSVPoaNErM8fesnu Content-Type: multipart/mixed; boundary="I37ufUA64XKIENJMpQcNXMgkgjTioFc1f" From: Matthew Seaman To: freebsd-current@freebsd.org Message-ID: <688e5574-10e3-05a6-3346-6ad8150c998b@infracaninophile.co.uk> Subject: Re: HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0 References: <20160805015918.GI43509@FreeBSD.org> <20160805020950.GJ43509@FreeBSD.org> In-Reply-To: <20160805020950.GJ43509@FreeBSD.org> --I37ufUA64XKIENJMpQcNXMgkgjTioFc1f Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 08/05/16 03:09, Glen Barber wrote: > On Fri, Aug 05, 2016 at 01:59:18AM +0000, Glen Barber wrote: >> This is a heads-up that OpenSSH keys are deprecated upstream by OpenSS= H, >> and will be deprecated effective 11.0-RELEASE (and preceeding RCs). >> >=20 > Stupid editor mistake. OpenSSH DSA keys are deprecated upstream. Sorr= y > for any confusion. >=20 >> Please see r303716 for details on the relevant commit, but upstream no= >> longer considers them secure. Please replace DSA keys with ECDSA or R= SA I believe ED25519 keys are also a preferred type. >> keys as soon as possible, otherwise there will be issues when upgradin= g >> 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 Cheers, Matthew --I37ufUA64XKIENJMpQcNXMgkgjTioFc1f-- --WKsnPtME8PjevS7v1cSVPoaNErM8fesnu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXpFLJAAoJEABRPxDgqeTnJv4QAIWmYUtJnkQD9J94qqZqRlCq GQWKO2QmhSPej3NPwhmACY43CYXUSVTwbFEtMXkXyi/O89xHvV9l8o2R2SIB/dCe LNmXoH40syJUgl3TeCH5BFVtUZWYW0DSFsD8m8RBB7xVVPhwggsKRsgN5ragjYf3 Mfx8Cc2+8HCev+7jA/AAyR2NCpGmMEDuznYeCx+X/7lGTs45C0f8sqk3yQywYpfD BPkGGVi+9qBveDegLh7MXNzx9mKdFuaKFgAOIYdEjAmTbZmz0aRNyJBJJv4PfV69 /ZvgnmGYNp/iuL2Lo01IKcSwtM6TXh90+AnPLGEhQCcotU/83nJWUCcXieN0pxui 9ybm1wkrPq79RXtx97ZOwHEDqbBC87AAtsRNPh8w2/4Yioq1fpGKWhWpBZ3N6EJZ m0GjbewK4O/VD+fPNHhfQMiLyfUiYnKhDPgAtuUJo15uvReyssgO7tzcOG9kILDe vd/aoyUVT6apLf/eNkQRHUvVVGOS/e0IDSy3gz7V91xnqpNtF+zwpVIuVqeJfN7C RdbIGsOMjncBf5C8TjHIPBb8yEYbCWO6ChhKf9yejbupf3sPjLGyD938rFWAni46 fMDgUGxDI22TF19xw7K3XMNZQiMZ9okb5SsKvkoDT5k4J0kkPv1LOW+Y7shmvihy FG6bURPthmkfA5lx5ObH =iOmW -----END PGP SIGNATURE----- --WKsnPtME8PjevS7v1cSVPoaNErM8fesnu-- From owner-freebsd-current@freebsd.org Fri Aug 5 14:47:24 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 00CD1BAF351 for ; Fri, 5 Aug 2016 14:47:24 +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 9F6C7167A for ; Fri, 5 Aug 2016 14:47:23 +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 3s5V5N5WsLzdr for ; Fri, 5 Aug 2016 16:47:20 +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=1470408437; x=1473000438; bh=BeH 6PTWnfnrhlvRp5rGR06Dw5puNkmY2nsc+Y1xSp10=; b=fRKttLDliyIAxMu8vjP mISVOg5wFH9VT/NhKQzS9pq20ecJA3qyhstKd3ewwE8XUqtapOs9up+G5YLx5F5V XHrsX2BsXBSCJHwyH5FkMoP/dDBFQG+CHWk5snkky6jqBOGD1khw9ckbrlDMbVrh +GPex9luUsDfWapYjFcQMGVI= 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 HZ44vvr_jj3m for ; Fri, 5 Aug 2016 16:47:17 +0200 (CEST) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP id 3s5V5J6pHczdq for ; Fri, 5 Aug 2016 16:47:16 +0200 (CEST) Received: from nabiralnik.ijs.si (nabiralnik.ijs.si [IPv6:2001:1470:ff80::80:16]) by mildred.ijs.si (Postfix) with ESMTP id 3s5V5J5tVnzg6 for ; Fri, 5 Aug 2016 16:47:16 +0200 (CEST) Received: from neli.ijs.si (2001:1470:ff80:88:21c:c0ff:feb1:8c91) by webmail.ijs.si with HTTP (HTTP/1.1 POST); Fri, 05 Aug 2016 16:47:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 05 Aug 2016 16:47:16 +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: References: <3629a441-ee6d-2407-fa13-5ebd8db8d802@freebsd.org> <000c29ee0f3dbd1d433c565023d69e25@mailbox.ijs.si> Message-ID: 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: Fri, 05 Aug 2016 14:47:24 -0000 On 2016-08-05 07:00, Julian Elischer wrote: > On 5/08/2016 5:44 AM, Mark Martinec wrote: >> Should I open a bug report, or has the problem been noted? > it's not clear without reading the standard whether the bug is in the > old or new version. > have you tried other systems? In particular I'd check OSX Did some research, opened a PR against 11.0-BETA3: [Bug 211598] date(1) default format in en_EN locale breaks compatibility with 10.3 and violates POSIX https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211598 Mark On 2016-08-05 07:00, Julian Elischer wrote: [...] > sh-3.2$ export LC_CTYPE="en_US.UTF-8" > sh-3.2$ export LC_TIME="en_US.UTF-8" > sh-3.2$ export LC_ALL="en_US.UTF-8" > sh-3.2$ export LC_NUMERIC="en_US.UTF-8" > sh-3.2$ date > Fri Aug 5 12:57:47 AWST 2016 > > if it IS a bug then yes, file a report with full reproduction steps. >> On 2016-08-04 04:32, Julian Elischer wrote: >>> On 4/08/2016 7:24 AM, Mark Martinec wrote: >>>> Is it normal/expected/documented that the date(1) command in 11.0 >>>> now produces a timestamp in substantially different format >>>> in an "en_US.UTF-8" locale (long names, commas, 12 vs. 24h hour >>>> time): >>>> >>>> Thursday, August 4, 2016 at 12:50:43 AM CEST >>>> vs: >>>> Thu Aug 4 00:52:29 CEST 2016 >>>> >>> one of those is a bug. the formats are defined in posix I believe. >>> >>>> >>>> Setting LC_TIME does not help: >>>> >>>> $LC_TIME="C" date >>>> Thursday, August 4, 2016 at 01:13:37 AM CEST >>>> >>>> although LC_ALL="C" _does_ help. >>>> >>>> >>>> This is funny too, especially regarding commas: >>>> $ LC_ALL="en_GB.UTF-8" date >>>> Thursday 4 August 2016 at 01:16:45 CEST >>>> $ LC_ALL="en_US.UTF-8" date >>>> Thursday, August 4, 2016 at 01:16:54 AM CEST >>>> >>>> >>>> The date(1) man page states: >>>> The date utility is expected to be compatible with IEEE Std 1003.2 >>>> (“POSIX.2â€). >>>> What does POSIX.2 say about date(1) following a locale? >>>> >>>> >>>> >>>> ====== >>>> 11.0-BETA3: >>>> >>>> $ date >>>> Thursday, August 4, 2016 at 12:50:43 AM CEST >>>> >>>> $ uname -a >>>> FreeBSD xxx.ijs.si 11.0-BETA3 FreeBSD 11.0-BETA3 #0 r303469: Fri Jul >>>> 29 02:27:28 UTC 2016 >>>> root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 >>>> >>>> $ locale >>>> LANG= >>>> LC_CTYPE="en_US.UTF-8" >>>> LC_COLLATE="en_US.UTF-8" >>>> LC_TIME="en_US.UTF-8" >>>> LC_NUMERIC="en_US.UTF-8" >>>> LC_MONETARY="en_US.UTF-8" >>>> LC_MESSAGES="en_US.UTF-8" >>>> LC_ALL=en_US.UTF-8 >>>> >>>> ====== >>>> 10.3-RELEASE-p6 : >>>> >>>> $ date >>>> Thu Aug 4 00:52:29 CEST 2016 >>>> >>>> $ freebsd-version >>>> 10.3-RELEASE-p6 >>>> >>>> $ uname -a >>>> FreeBSD yyy.ijs.si 10.3-RELEASE-p4 FreeBSD 10.3-RELEASE-p4 #0: Sat >>>> May 28 12:23:44 UTC 2016 >>>> root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC >>>> amd64 >>>> >>>> $ locale >>>> LANG= >>>> LC_CTYPE="en_US.UTF-8" >>>> LC_COLLATE="en_US.UTF-8" >>>> LC_TIME="en_US.UTF-8" >>>> LC_NUMERIC="en_US.UTF-8" >>>> LC_MONETARY="en_US.UTF-8" >>>> LC_MESSAGES="en_US.UTF-8" >>>> LC_ALL=en_US.UTF-8 >>>> >>>> >>>> >>>> Mark From owner-freebsd-current@freebsd.org Fri Aug 5 15:10: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 7C824BAFC5D for ; Fri, 5 Aug 2016 15:10:28 +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 6F3B715EF; Fri, 5 Aug 2016 15:10:28 +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 5FEE282; Fri, 5 Aug 2016 15:10:28 +0000 (UTC) Date: Fri, 5 Aug 2016 15:10:18 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <1141654619.0.1470409828108.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #533 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: Fri, 05 Aug 2016 15:10:28 -0000 See ------------------------------------------ [...truncated 322940 lines...] [192.168.10.2] out: lib/msun/log_test:log10f_zero_pos -> passed [0.016s] [192.168.10.2] out: lib/msun/log_test:log1p_inf_neg -> passed [0.016s] [192.168.10.2] out: lib/msun/log_test:log1p_inf_pos -> passed [0.014s] [192.168.10.2] out: lib/msun/log_test:log1p_nan -> passed [0.014s] [192.168.10.2] out: lib/msun/log_test:log1p_one_neg -> passed [0.014s] [192.168.10.2] out: lib/msun/log_test:log1p_zero_neg -> passed [0.014s] [192.168.10.2] out: lib/msun/log_test:log1p_zero_pos -> passed [0.015s] [192.168.10.2] out: lib/msun/log_test:log1pf_inf_neg -> passed [0.014s] [192.168.10.2] out: lib/msun/log_test:log1pf_inf_pos -> passed [0.015s] [192.168.10.2] out: lib/msun/log_test:log1pf_nan -> passed [0.014s] [192.168.10.2] out: lib/msun/log_test:log1pf_one_neg -> passed [0.014s] [192.168.10.2] out: lib/msun/log_test:log1pf_zero_neg -> passed [0.016s] [192.168.10.2] out: lib/msun/log_test:log1pf_zero_pos -> passed [0.015s] [192.168.10.2] out: lib/msun/log_test:log2_base -> passed [0.016s] [192.168.10.2] out: lib/msun/log_test:log2_inf_neg -> passed [0.015s] [192.168.10.2] out: lib/msun/log_test:log2_inf_pos -> passed [0.015s] [192.168.10.2] out: lib/msun/log_test:log2_nan -> passed [0.015s] [192.168.10.2] out: lib/msun/log_test:log2_one_pos -> passed [0.015s] [192.168.10.2] out: lib/msun/log_test:log2_zero_neg -> passed [0.016s] [192.168.10.2] out: lib/msun/log_test:log2_zero_pos -> passed [0.015s] [192.168.10.2] out: lib/msun/log_test:log2f_base -> passed [0.017s] [192.168.10.2] out: lib/msun/log_test:log2f_inf_neg -> passed [0.028s] [192.168.10.2] out: lib/msun/log_test:log2f_inf_pos -> passed [0.015s] [192.168.10.2] out: lib/msun/log_test:log2f_nan -> passed [0.015s] [192.168.10.2] out: lib/msun/log_test:log2f_one_pos -> passed [0.015s] [192.168.10.2] out: lib/msun/log_test:log2f_zero_neg -> passed [0.016s] [192.168.10.2] out: lib/msun/log_test:log2f_zero_pos -> passed [0.021s] [192.168.10.2] out: lib/msun/log_test:log_base -> passed [0.015s] [192.168.10.2] out: lib/msun/log_test:log_inf_neg -> passed [0.014s] [192.168.10.2] out: lib/msun/log_test:log_inf_pos -> passed [0.015s] [192.168.10.2] out: lib/msun/log_test:log_nan -> passed [0.015s] [192.168.10.2] out: lib/msun/log_test:log_one_pos -> passed [0.018s] [192.168.10.2] out: lib/msun/log_test:log_zero_neg -> passed [0.016s] [192.168.10.2] out: lib/msun/log_test:log_zero_pos -> passed [0.015s] [192.168.10.2] out: lib/msun/log_test:logf_base -> passed [0.015s] [192.168.10.2] out: lib/msun/log_test:logf_inf_neg -> passed [0.015s] [192.168.10.2] out: lib/msun/log_test:logf_inf_pos -> passed [0.017s] [192.168.10.2] out: lib/msun/log_test:logf_nan -> passed [0.016s] [192.168.10.2] out: lib/msun/log_test:logf_one_pos -> passed [0.015s] [192.168.10.2] out: lib/msun/log_test:logf_zero_neg -> passed [0.015s] [192.168.10.2] out: lib/msun/log_test:logf_zero_pos -> passed [0.015s] [192.168.10.2] out: lib/msun/pow_test:pow_inf_neg_x -> passed [0.018s] [192.168.10.2] out: lib/msun/pow_test:pow_inf_neg_y -> passed [0.016s] [192.168.10.2] out: lib/msun/pow_test:pow_inf_pos_x -> passed [0.015s] [192.168.10.2] out: lib/msun/pow_test:pow_inf_pos_y -> passed [0.014s] [192.168.10.2] out: lib/msun/pow_test:pow_nan_x -> passed [0.015s] [192.168.10.2] out: lib/msun/pow_test:pow_nan_y -> passed [0.016s] [192.168.10.2] out: lib/msun/pow_test:pow_one_neg_x -> passed [0.014s] [192.168.10.2] out: lib/msun/pow_test:pow_one_pos_x -> passed [0.015s] [192.168.10.2] out: lib/msun/pow_test:pow_zero_x -> passed [0.016s] [192.168.10.2] out: lib/msun/pow_test:pow_zero_y -> passed [0.014s] [192.168.10.2] out: lib/msun/pow_test:powf_inf_neg_x -> passed [0.014s] [192.168.10.2] out: lib/msun/pow_test:powf_inf_neg_y -> passed [0.014s] [192.168.10.2] out: lib/msun/pow_test:powf_inf_pos_x -> passed [0.014s] [192.168.10.2] out: lib/msun/pow_test:powf_inf_pos_y -> passed [0.013s] [192.168.10.2] out: lib/msun/pow_test:powf_nan_x -> passed [0.014s] [192.168.10.2] out: lib/msun/pow_test:powf_nan_y -> passed [0.013s] [192.168.10.2] out: lib/msun/pow_test:powf_one_neg_x -> passed [0.013s] [192.168.10.2] out: lib/msun/pow_test:powf_one_pos_x -> passed [0.013s] [192.168.10.2] out: lib/msun/pow_test:powf_zero_x -> passed [0.013s] [192.168.10.2] out: lib/msun/pow_test:powf_zero_y -> passed [0.014s] [192.168.10.2] out: lib/msun/precision_test:t_precision -> passed [0.013s] [192.168.10.2] out: lib/msun/round_test:round_dir -> passed [0.016s] [192.168.10.2] out: lib/msun/scalbn_test:scalbn_inf_neg -> passed [0.017s] [192.168.10.2] out: lib/msun/scalbn_test:scalbn_inf_pos -> passed [0.015s] [192.168.10.2] out: lib/msun/scalbn_test:scalbn_ldexp -> passed [0.016s] [192.168.10.2] out: lib/msun/scalbn_test:scalbn_nan -> passed [0.015s] [192.168.10.2] out: lib/msun/scalbn_test:scalbn_val -> passed [0.014s] [192.168.10.2] out: lib/msun/scalbn_test:scalbn_zero_neg -> passed [0.015s] [192.168.10.2] out: lib/msun/scalbn_test:scalbn_zero_pos -> passed [0.015s] [192.168.10.2] out: lib/msun/scalbn_test:scalbnf_inf_neg -> passed [0.015s] [192.168.10.2] out: lib/msun/scalbn_test:scalbnf_inf_pos -> passed [0.015s] [192.168.10.2] out: lib/msun/scalbn_test:scalbnf_ldexpf -> passed [0.014s] [192.168.10.2] out: lib/msun/scalbn_test:scalbnf_nan -> passed [0.016s] [192.168.10.2] out: lib/msun/scalbn_test:scalbnf_val -> passed [0.015s] [192.168.10.2] out: lib/msun/scalbn_test:scalbnf_zero_neg -> passed [0.016s] [192.168.10.2] out: lib/msun/scalbn_test:scalbnf_zero_pos -> passed [0.016s] [192.168.10.2] out: lib/msun/scalbn_test:scalbnl_inf_neg -> passed [0.015s] [192.168.10.2] out: lib/msun/scalbn_test:scalbnl_inf_pos -> passed [0.015s] [192.168.10.2] out: lib/msun/scalbn_test:scalbnl_nan -> passed [0.015s] [192.168.10.2] out: lib/msun/scalbn_test:scalbnl_val -> passed [0.016s] [192.168.10.2] out: lib/msun/scalbn_test:scalbnl_zero_neg -> passed [0.015s] [192.168.10.2] out: lib/msun/scalbn_test:scalbnl_zero_pos -> passed [0.016s] [192.168.10.2] out: lib/msun/sin_test:sin_angles -> passed [0.016s] [192.168.10.2] out: lib/msun/sin_test:sin_inf_neg -> passed [0.014s] [192.168.10.2] out: lib/msun/sin_test:sin_inf_pos -> passed [0.013s] [192.168.10.2] out: lib/msun/sin_test:sin_nan -> passed [0.015s] [192.168.10.2] out: lib/msun/sin_test:sin_zero_neg -> passed [0.015s] [192.168.10.2] out: lib/msun/sin_test:sin_zero_pos -> passed [0.014s] [192.168.10.2] out: lib/msun/sin_test:sinf_angles -> passed [0.015s] [192.168.10.2] out: lib/msun/sin_test:sinf_inf_neg -> passed [0.015s] [192.168.10.2] out: lib/msun/sin_test:sinf_inf_pos -> passed [0.014s] [192.168.10.2] out: lib/msun/sin_test:sinf_nan -> passed [0.014s] [192.168.10.2] out: lib/msun/sin_test:sinf_zero_neg -> passed [0.015s] [192.168.10.2] out: lib/msun/sin_test:sinf_zero_pos -> passed [0.015s] [192.168.10.2] out: lib/msun/sinh_test:sinh_inf_neg -> passed [0.017s] [192.168.10.2] out: lib/msun/sinh_test:sinh_inf_pos -> passed [0.015s] [192.168.10.2] out: lib/msun/sinh_test:sinh_inrange -> passed [0.015s] [192.168.10.2] out: lib/msun/sinh_test:sinh_nan -> passed [0.015s] [192.168.10.2] out: lib/msun/sinh_test:sinh_zero_neg -> passed [0.014s] [192.168.10.2] out: lib/msun/sinh_test:sinh_zero_pos -> passed [0.015s] [192.168.10.2] out: lib/msun/sinh_test:sinhf_inf_neg -> passed [0.014s] [192.168.10.2] out: lib/msun/sinh_test:sinhf_inf_pos -> passed [0.014s] [192.168.10.2] out: lib/msun/sinh_test:sinhf_inrange -> passed [0.014s] [192.168.10.2] out: lib/msun/sinh_test:sinhf_nan -> passed [0.014s] [192.168.10.2] out: lib/msun/sinh_test:sinhf_zero_neg -> passed [0.014s] [192.168.10.2] out: lib/msun/sinh_test:sinhf_zero_pos -> passed [0.015s] [192.168.10.2] out: lib/msun/sqrt_test:sqrt_inf_neg -> passed [0.018s] [192.168.10.2] out: lib/msun/sqrt_test:sqrt_inf_pos -> passed [0.017s] [192.168.10.2] out: lib/msun/sqrt_test:sqrt_nan -> passed [0.015s] [192.168.10.2] out: lib/msun/sqrt_test:sqrt_pow -> passed [0.015s] [192.168.10.2] out: lib/msun/sqrt_test:sqrt_zero_neg -> passed [0.015s] [192.168.10.2] out: lib/msun/sqrt_test:sqrt_zero_pos -> passed [0.018s] [192.168.10.2] out: lib/msun/sqrt_test:sqrtf_inf_neg -> passed [0.016s] [192.168.10.2] out: lib/msun/sqrt_test:sqrtf_inf_pos -> passed [0.015s] [192.168.10.2] out: lib/msun/sqrt_test:sqrtf_nan -> passed [0.015s] [192.168.10.2] out: lib/msun/sqrt_test:sqrtf_powf -> passed [0.016s] [192.168.10.2] out: lib/msun/sqrt_test:sqrtf_zero_neg -> passed [0.014s] [192.168.10.2] out: lib/msun/sqrt_test:sqrtf_zero_pos -> passed [0.016s] [192.168.10.2] out: lib/msun/sqrt_test:sqrtl_inf_neg -> passed [0.015s] [192.168.10.2] out: lib/msun/sqrt_test:sqrtl_inf_pos -> passed [0.015s] [192.168.10.2] out: lib/msun/sqrt_test:sqrtl_nan -> passed [0.014s] [192.168.10.2] out: lib/msun/sqrt_test:sqrtl_powl -> passed [0.015s] [192.168.10.2] out: lib/msun/sqrt_test:sqrtl_zero_neg -> passed [0.016s] [192.168.10.2] out: lib/msun/sqrt_test:sqrtl_zero_pos -> passed [0.016s] [192.168.10.2] out: lib/msun/tan_test:tan_angles -> passed [0.019s] [192.168.10.2] out: lib/msun/tan_test:tan_inf_neg -> passed [0.015s] [192.168.10.2] out: lib/msun/tan_test:tan_inf_pos -> passed [0.015s] [192.168.10.2] out: lib/msun/tan_test:tan_nan -> passed [0.015s] [192.168.10.2] out: lib/msun/tan_test:tan_zero_neg -> passed [0.016s] [192.168.10.2] out: lib/msun/tan_test:tan_zero_pos -> passed [0.015s] [192.168.10.2] out: lib/msun/tan_test:tanf_angles -> passed [0.015s] [192.168.10.2] out: lib/msun/tan_test:tanf_inf_neg -> passed [0.015s] [192.168.10.2] out: lib/msun/tan_test:tanf_inf_pos -> passed [0.014s] [192.168.10.2] out: lib/msun/tan_test:tanf_nan -> passed [0.014s] [192.168.10.2] out: lib/msun/tan_test:tanf_zero_neg -> passed [0.013s] [192.168.10.2] out: lib/msun/tan_test:tanf_zero_pos -> passed [0.014s] [192.168.10.2] out: lib/msun/tanh_test:tanh_inf_neg -> passed [0.015s] [192.168.10.2] out: lib/msun/tanh_test:tanh_inf_pos -> passed [0.014s] [192.168.10.2] out: lib/msun/tanh_test:tanh_nan -> passed [0.012s] [192.168.10.2] out: lib/msun/tanh_test:tanh_zero_neg -> passed [0.013s] [192.168.10.2] out: lib/msun/tanh_test:tanh_zero_pos -> passed [0.013s] [192.168.10.2] out: lib/msun/tanh_test:tanhf_inf_neg -> passed [0.015s] [192.168.10.2] out: lib/msun/tanh_test:tanhf_inf_pos -> passed [0.014s] [192.168.10.2] out: lib/msun/tanh_test:tanhf_nan -> passed [0.013s] [192.168.10.2] out: lib/msun/tanh_test:tanhf_zero_neg -> passed [0.013s] [192.168.10.2] out: lib/msun/tanh_test:tanhf_zero_pos -> passed [0.013s] [192.168.10.2] out: lib/msun/cexp_test:main -> passed [0.033s] [192.168.10.2] out: lib/msun/conj_test:main -> passed [0.018s] [192.168.10.2] out: lib/msun/csqrt_test:main -> passed [0.020s] [192.168.10.2] out: lib/msun/ctrig_test:main -> passed [0.054s] [192.168.10.2] out: lib/msun/exponential_test:main -> passed [0.019s] [192.168.10.2] out: lib/msun/fenv_test:main -> passed [0.028s] [192.168.10.2] out: lib/msun/fma_test:main -> passed [0.022s] [192.168.10.2] out: lib/msun/ilogb_test:main -> passed [0.048s] [192.168.10.2] out: lib/msun/invtrig_test:main -> passed [0.098s] [192.168.10.2] out: lib/msun/invctrig_test:main -> passed [0.037s] [192.168.10.2] out: lib/msun/logarithm_test:main -> passed [0.018s] [192.168.10.2] out: lib/msun/lrint_test:main -> passed [0.014s] [192.168.10.2] out: lib/msun/nan_test:main -> passed [0.024s] [192.168.10.2] out: lib/msun/nearbyint_test:main -> passed [0.017s] [192.168.10.2] out: lib/msun/next_test:main -> passed [0.016s] [192.168.10.2] out: lib/msun/rem_test:main -> passed [0.014s] [192.168.10.2] out: lib/msun/trig_test:main -> passed [0.017s] [192.168.10.2] out: lib/libarchive/functional_test:test_acl_freebsd_nfs4 -> passed [0.175s] [192.168.10.2] out: lib/libarchive/functional_test:test_acl_freebsd_posix1e -> passed [0.107s] [192.168.10.2] out: lib/libarchive/functional_test:test_acl_nfs4 -> passed [0.105s] [192.168.10.2] out: lib/libarchive/functional_test:test_acl_pax -> passed [0.133s] [192.168.10.2] out: lib/libarchive/functional_test:test_acl_posix1e -> passed [0.093s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_api_feature -> passed [0.087s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_clear_error -> passed [0.179s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_cmdline -> passed [0.088s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_getdate -> passed [0.094s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_match_owner -> passed [0.094s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_match_path -> passed [0.130s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_match_time -> passed [2.256s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_md5 -> passed [0.131s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_pathmatch -> passed [0.092s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_read_add_passphrase -> passed [0.092s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_read_add_passphrase_incorrect_sequance -> passed [0.091s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_read_add_passphrase_multiple -> passed [0.091s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_read_add_passphrase_multiple_with_callback -> passed [0.087s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_read_add_passphrase_multiple_with_callback2 -> passed [0.090s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_read_add_passphrase_set_callback1 -> passed [0.093s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_read_add_passphrase_set_callback2 -> passed [0.091s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_read_add_passphrase_set_callback3 -> passed [0.088s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_read_add_passphrase_single -> passed [0.090s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_read_close_twice -> passed [0.085s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_read_close_twice_open_fd -> passed [0.090s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_read_close_twice_open_filename -> passed [0.090s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_read_multiple_data_objects -> passed [0.752s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_read_next_header_empty -> passed [0.091s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_read_next_header_raw -> passed [0.087s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_read_open2 -> passed [0.088s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_read_set_filter_option -> passed [0.088s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_read_set_format_option -> passed [0.091s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_read_set_option -> passed [0.090s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_read_set_options -> passed [0.088s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_read_support -> passed [0.089s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_set_error -> passed [0.091s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_sha1 -> passed [0.113s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_sha256 -> passed [0.108s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_sha512 -> passed [0.107s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_string -> passed [0.092s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_string_conversion -> passed [0.391s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_string_sort -> passed [0.099s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_write_add_filter_by_name_b64encode -> passed [0.090s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_write_add_filter_by_name_bzip2 -> passed [0.107s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_write_add_filter_by_name_compress -> passed [0.094s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_write_add_filter_by_name_grzip -> passed [0.165s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_write_add_filter_by_name_gzip -> passed [0.100s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_write_add_filter_by_name_lrzip -> passed [0.102s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_write_add_filter_by_name_lz4 -> passed [0.093s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_write_add_filter_by_name_lzip -> No handlers could be found for logger "paramiko.transport" Warning: run() received nonzero return code -1 while executing 'kyua test'! [192.168.10.2] run: kyua report --verbose --results-filter passed,skipped,xfail,broken,failed --output test-report.txt Traceback (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 184, in runTest fabric.api.run("kyua report --verbose --results-filter passed,skipped,xfail,broken,failed --output test-report.txt") File "/usr/local/lib/python2.7/site-packages/fabric/network.py", line 649, in host_prompting_wrapper return func(*args, **kwargs) File "/usr/local/lib/python2.7/site-packages/fabric/operations.py", line 1056, in run shell_escape=shell_escape) File "/usr/local/lib/python2.7/site-packages/fabric/operations.py", line 923, in _run_command channel=default_channel(), command=wrapped_command, pty=pty, File "/usr/local/lib/python2.7/site-packages/fabric/state.py", line 402, in default_channel chan = _open_session() File "/usr/local/lib/python2.7/site-packages/fabric/state.py", line 389, in _open_session return connections[env.host_string].get_transport().open_session() File "/usr/local/lib/python2.7/site-packages/fabric/network.py", line 159, in __getitem__ self.connect(key) File "/usr/local/lib/python2.7/site-packages/fabric/network.py", line 151, in connect user, host, port, cache=self, seek_gateway=seek_gateway) File "/usr/local/lib/python2.7/site-packages/fabric/network.py", line 575, in connect raise NetworkError(msg, e) fabric.exceptions.NetworkError: Timed out trying to connect to 192.168.10.2 (tried 1 time) [Pipeline] } [Pipeline] // node [Pipeline] node Running on master in /usr/local/jenkins/workspace/FreeBSD_HEAD [Pipeline] { [Pipeline] step From owner-freebsd-current@freebsd.org Fri Aug 5 15:23: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 56899BB0092 for ; Fri, 5 Aug 2016 15:23:27 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f45.google.com (mail-lf0-f45.google.com [209.85.215.45]) (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 DA1761F03 for ; Fri, 5 Aug 2016 15:23:26 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lf0-f45.google.com with SMTP id g62so205937316lfe.3 for ; Fri, 05 Aug 2016 08:23:26 -0700 (PDT) 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=lu7VQ+44XP+5L6xdoAd+A90eqeaMOyrAfLqkD86Bp9I=; b=SAWT7LoVV4qUQB2sHpmjJoesp6UoesoidIcyidURMFEvAMNZYnf119Iukxv3Thr1vT IA9o4Yapr6cAqYxkqkLcrRWqewOlMUFb/faBmh3JZqLOrsr0obQI/bsJOG3YoQfQJIKJ oEyFgePp7gmnEbgL0w46/HE509HOSoAnO909Sw0yTLpLInTB0W8f+9ayL/X6LoNzCKhO r9RbR1kYW818StOyNXoHy7DfQ6FNricz8dDm6NkCz8PPEjU0sLzOtzspCyKMQV6gGIF6 jttDdo4S93GEQ1vyxyXbEuH7UNe7TWK5Rgl0bLdEb2Wxqmdo5daJhKE+MM9eSExqs301 rA0A== X-Gm-Message-State: AEkoouvLdkc/weFq6pQPmpzjLeXIFt/nUfrak9KGYf9clCSMRpTCG7OsJhOK3iPiOZ2gqg== X-Received: by 10.25.154.19 with SMTP id c19mr25186939lfe.188.1470410598845; Fri, 05 Aug 2016 08:23:18 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id h203sm3292873lfg.29.2016.08.05.08.23.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Aug 2016 08:23:18 -0700 (PDT) Subject: Re: date(1) default format changed between 10.3 and 11.0-BETA3 To: Mark Martinec , freebsd-current@freebsd.org References: <3629a441-ee6d-2407-fa13-5ebd8db8d802@freebsd.org> <000c29ee0f3dbd1d433c565023d69e25@mailbox.ijs.si> From: Andrey Chernov Message-ID: <279e9b67-da23-cdd6-3a77-b084ad8269eb@freebsd.org> Date: Fri, 5 Aug 2016 18:23:17 +0300 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=us-ascii 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, 05 Aug 2016 15:23:27 -0000 On 05.08.2016 17:47, Mark Martinec wrote: > [Bug 211598] > date(1) default format in en_EN locale breaks compatibility with 10.3 > and violates POSIX > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211598 It breaks compatibility but not violates POSIX. POSIX care of only its own POSIX (or C) locale. From owner-freebsd-current@freebsd.org Fri Aug 5 15:45: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 8EFCABB071B for ; Fri, 5 Aug 2016 15:45:04 +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 490621014 for ; Fri, 5 Aug 2016 15:45:04 +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 3s5WMy5W7bz17N for ; Fri, 5 Aug 2016 17:45:02 +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=1470411899; x=1473003900; bh=t98 pTUYxtwg/NPmyXC5b83/xfBKZiUTt8lSLgGJPJ1g=; b=id0QhcOIPwwkCEv/9Zy SaOdia5WjZXodmdpTb5gpLW1KKVMzVx4qX8eC5bBHeRNwMIwQb4AWV4FzjxjUVy1 pIYaetOc4GsIaC/6nfu1U0rtNkhyc+2wBgzdtQi79/jHBRAuGbOswrtmp2WLjVYT p9+HEP1MLqoKoIUyVYCaVphk= 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 gxysZGflx0Y2 for ; Fri, 5 Aug 2016 17:44:59 +0200 (CEST) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP id 3s5WMv3w4sz17L for ; Fri, 5 Aug 2016 17:44:59 +0200 (CEST) Received: from nabiralnik.ijs.si (nabiralnik.ijs.si [IPv6:2001:1470:ff80::80:16]) by mildred.ijs.si (Postfix) with ESMTP id 3s5WMv3484ztK for ; Fri, 5 Aug 2016 17:44:59 +0200 (CEST) Received: from neli.ijs.si (2001:1470:ff80:88:21c:c0ff:feb1:8c91) by webmail.ijs.si with HTTP (HTTP/1.1 POST); Fri, 05 Aug 2016 17:44:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 05 Aug 2016 17:44:59 +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: <279e9b67-da23-cdd6-3a77-b084ad8269eb@freebsd.org> References: <3629a441-ee6d-2407-fa13-5ebd8db8d802@freebsd.org> <000c29ee0f3dbd1d433c565023d69e25@mailbox.ijs.si> <279e9b67-da23-cdd6-3a77-b084ad8269eb@freebsd.org> Message-ID: 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: Fri, 05 Aug 2016 15:45:04 -0000 On 2016-08-05 17:23, Andrey Chernov wrote: > On 05.08.2016 17:47, Mark Martinec wrote: >> [Bug 211598] >> date(1) default format in en_EN locale breaks compatibility with >> 10.3 >> and violates POSIX >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211598 > > It breaks compatibility but not violates POSIX. POSIX care of only its > own POSIX (or C) locale. 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 may not say what an abbreviated name really looks like in a particular locale, but it does distinguish between full and abbreviated names. Mark From owner-freebsd-current@freebsd.org Fri Aug 5 16:02: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 CAC8DBB0D9C for ; Fri, 5 Aug 2016 16:02:39 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 75E641F6F; Fri, 5 Aug 2016 16:02:39 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: by mail-wm0-x22c.google.com with SMTP id o80so43423073wme.1; Fri, 05 Aug 2016 09:02:39 -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=BfqAzD/unGUwvH1JOOURMl+vH1xn3hb6j2SSj64fk0o=; b=MwLY9U1UKF05t63petR8Il8sRVv+WNyJ3kUT3wDZLsFNnQ8lrLxYJcw17iJNKkbaqM Fnjlu6jvJCDptg5T/956jhS3jcubIGHqQ4d85xTcQXUwShAfaoU2OPZuaXTEvJfS7T26 pGVdQxRS8CYQZwZSqKHoLEVhTVuPdxmZG0DZz1wwgZoRHYqsSw/abF3ppEJ9MBACPny5 RDQeEyCQdubpvlz7du601GlOd8656LIO1X0ZKyhfrT5S1W+14wY4cIO6teWjOw2Amt7j RTdWaIN2UCec7BcWKeRkAVbri2Jr2kL5btVMFcLwZLIq+RrEwe3ft/6TBsIDprDp2h8M VDhg== 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=BfqAzD/unGUwvH1JOOURMl+vH1xn3hb6j2SSj64fk0o=; b=YeqYDe3/4KyI/NtOSe2vYk2KOMXFtG0gE2GYSzSsizaJAS/w35L05EqmFaWJ3Ud4QJ Mc1gpV7ikMBlXKLhFI4jxUacs3Q7QavmdnAEQ1E5WoRAdE6ud88gmuX58RCirbylXvIa B8FSSROqZfWQTMMyQYm4AJqIBwIbIu+SyXlNM1GVDegZ7d+8zEnX26G8POtD/t9PCwLg QOwJ1WpqccfgJRHl1w9+vajPQfZ3zp+hN6rPkR1gJ2DPMFwD69K6UC/bSOrQRAM4/x43 tn++GGtO3b/5ZsjqCQfaXk+ZR1HLGQVFdnpMo6+1fsHE94TJpofQn7YVRuhdn+LFr8zc JYNg== X-Gm-Message-State: AEkoouvhZ/DFlRt5iOYaJLkr9/fNOZ+5sLqbEjhFZrwMK6fmjnSrHbqPv3M6qkxRDM9XQrWROycgI47NrbHlYg== X-Received: by 10.194.87.66 with SMTP id v2mr80153197wjz.40.1470412957184; Fri, 05 Aug 2016 09:02:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.19.203 with HTTP; Fri, 5 Aug 2016 09:02:36 -0700 (PDT) In-Reply-To: <1317681458882873@web18g.yandex.ru> References: <1317681458882873@web18g.yandex.ru> From: Guy Yur Date: Fri, 5 Aug 2016 19:02:36 +0300 Message-ID: Subject: Re: panic "wlock already held" when changing ipv6 default route To: "Alexander V. Chernikov" Cc: freebsd-current , "Bjoern A. Zeeb" 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: Fri, 05 Aug 2016 16:02:39 -0000 On Fri, Mar 25, 2016 at 8:14 AM, Alexander V. Chernikov wrote: > 25.03.2016, 02:11, "Guy Yur" : >> Hi, >> >> When changing the ipv6 default route I get a panic on wlock already held. >> Could be related to r293424 lock changes, haven't checked an older version yet. > Hi, > Yes, there is a problem when the default route next hop is filled in incorrectly, so lookup fails (e.g. matches previous one). > Will be fixed soon. > > Thanks for the report. >> >> route add -inet6 default fe80::7 >> route change -inet6 default fe80::7 >> >> panic: rw_rlock: wlock already held for rib head lock @ >> /usr/src/sys/net/route.c:445 >> cpuid = 0 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0050ee01d0 >> vpanic() at vpanic+0x182/frame 0xfffffe0050ee0250 >> kassert_panic() at kassert_panic+0x126/frame 0xfffffe0050ee02c0 >> __rw_rlock() at __rw_rlock+0xe7/frame 0xfffffe0050ee0360 >> rtalloc1_fib() at rtalloc1_fib+0x86/frame 0xfffffe0050ee0420 >> ifa_ifwithroute() at ifa_ifwithroute+0x83/frame 0xfffffe0050ee0460 >> rt_getifa_fib() at rt_getifa_fib+0xe7/frame 0xfffffe0050ee0480 >> rtrequest1_fib() at rtrequest1_fib+0x59c/frame 0xfffffe0050ee0570 >> route_output() at route_output+0x653/frame 0xfffffe0050ee07c0 >> sosend_generic() at sosend_generic+0x436/frame 0xfffffe0050ee0880 >> soo_write() at soo_write+0x42/frame 0xfffffe0050ee08b0 >> dofilewrite() at dofilewrite+0x87/frame 0xfffffe0050ee0900 >> kern_writev() at kern_writev+0x68/frame 0xfffffe0050ee0950 >> sys_write() at sys_write+0x60/frame 0xfffffe0050ee09a0 >> amd64_syscall() at amd64_syscall+0x2db/frame 0xfffffe0050ee0ab0 >> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0050ee0ab0 >> --- syscall (4, FreeBSD ELF64, sys_write), rip = 0x800977b7ba, rsp = >> 0x7fffffffe2d8, rbp = 0x7fffffffeb90 --- >> KDB: enter: panic >> [ thread pid 644 tid 100054 ] >> Stopped at kdb_enter+0x3b: movq $0,kdb_why >> Hi, Opened bug 211602 so this won't get lost. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211602 Also happens when the gateway route was deleted so not specific to link-local addresses. # route add -inet6 2001:db8:0::/64 fe80::7%lo0 # route add -inet6 2001:db8:1::/64 2001:db8:0::1 # route delete -inet6 2001:db8:0::/64 # route change -inet6 2001:db8:1::/64 2001:db8:0::1 I restored RTF_RNH_LOCKED locally as a workaround so rtalloc1_fib won't try to lock when rtrequest1_fib already took a lock before calling rtrequest1_fib_change. On a related note, also mentioned by Bjoern, should link-local gateway addresses without %IF zone index be accepted? This can be confusing when you forget the %IF and think you added the route correctly but it is acting as a black hole. I forgot the %IF when adding the default route and stumbled on this panic. On OpenBSD when the gateway is missing the zone index the route is rejected. # route add -inet6 default fe80::7 route: writing to routing socket: Network is unreachable add net default: gateway fe80::7: Network is unreachable Thanks, Guy From owner-freebsd-current@freebsd.org Fri Aug 5 16:03: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 5A6E3BB0DE6 for ; Fri, 5 Aug 2016 16:03:03 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f53.google.com (mail-lf0-f53.google.com [209.85.215.53]) (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 DD5A811E7 for ; Fri, 5 Aug 2016 16:03:02 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lf0-f53.google.com with SMTP id l69so206750924lfg.1 for ; Fri, 05 Aug 2016 09:03:02 -0700 (PDT) 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=g55zSeXtAN69FPfIVbYZcWJ1T9IQ9eyDMSkk4+ngmKs=; b=hWhA1YhoV591PmoOldBzZu9gWBJoZdRpJySn+klYqW6YRJQRVRPaUU+uUM/Xhjnv5P gtUYYCDMC5S+c1nMaY69NrYVhk582Dsu6emqmUWVMaDooOxTsv2VsCD5If4od8gLlFOZ ifDNAbZ+orGM2Edqm0iHl4VuJNNT9+xgIY4khVUXW5yfPrxTNHfNUjQIUFHFxOJ7eCmw lD1yFGIKaPdjm+Yn7u6J90dGOIuafPa9/5wbchw66nonv55z0cpkNJBD67eXk+WCIU4w LvfULPqDhSVhWSvd0XxoykOGDhHwRsi3iKfPyDAW/OTH5AucQPtkZ0GMqx30WSaN67IL 2hpQ== X-Gm-Message-State: AEkoouuOiGQvPRbOQ3OCAj9d9TiRc21IPuA0lP+VJ0DXGj6p1NIiKgRhSNszF5fPuGGy+Q== X-Received: by 10.25.207.129 with SMTP id f123mr21908647lfg.81.1470412594857; Fri, 05 Aug 2016 08:56:34 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id e79sm3274748lji.42.2016.08.05.08.56.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Aug 2016 08:56:33 -0700 (PDT) Subject: Re: date(1) default format changed between 10.3 and 11.0-BETA3 To: Mark Martinec , freebsd-current@freebsd.org References: <3629a441-ee6d-2407-fa13-5ebd8db8d802@freebsd.org> <000c29ee0f3dbd1d433c565023d69e25@mailbox.ijs.si> <279e9b67-da23-cdd6-3a77-b084ad8269eb@freebsd.org> From: Andrey Chernov Message-ID: <4a454eef-55ae-b90d-4441-2aa9708fc747@freebsd.org> Date: Fri, 5 Aug 2016 18:56:33 +0300 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=us-ascii 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, 05 Aug 2016 16:03:03 -0000 On 05.08.2016 18:44, Mark Martinec wrote: > On 2016-08-05 17:23, Andrey Chernov wrote: >> On 05.08.2016 17:47, Mark Martinec wrote: >>> [Bug 211598] >>> date(1) default format in en_EN locale breaks compatibility with 10.3 >>> and violates POSIX >>> >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211598 >> >> It breaks compatibility but not violates POSIX. POSIX care of only its >> own POSIX (or C) locale. > > 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 may not say what an abbreviated name really looks like > in a particular locale, but it does distinguish between > full and abbreviated names. It says nothing about other locales. Current format comes from CLDR, ask bapt@ From owner-freebsd-current@freebsd.org Fri Aug 5 18: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 43AC2BB0A0C for ; Fri, 5 Aug 2016 18:49:43 +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 35EAC1B6A; Fri, 5 Aug 2016 18:49:43 +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 8969887; Fri, 5 Aug 2016 18:49:43 +0000 (UTC) Date: Fri, 5 Aug 2016 18:49:43 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <1087614108.2.1470422983498.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1141654619.0.1470409828108.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1141654619.0.1470409828108.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD #534 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: Fri, 05 Aug 2016 18:49:43 -0000 See From owner-freebsd-current@freebsd.org Fri Aug 5 19: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 C6619BB077F for ; Fri, 5 Aug 2016 19:26:30 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::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 996AE1BD4 for ; Fri, 5 Aug 2016 19:26:30 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: by mail-vk0-x22f.google.com with SMTP id n129so198261867vke.3 for ; Fri, 05 Aug 2016 12:26:30 -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=+O4l+/uoSSOuJ4ArOdUVdbmQf9L+QxoUenYLZDAzy2w=; b=CzemewQMyyjbYIZNX1XyOcMvdQdirOtxin7pk9jck67rNLQ1S0aEv6A6nsxIo49/Yu PQE74UoDKSFzE492dmRCqpEuYFrwZHT50kZtaVYW179T1r1E8u+WjaVK+QTzXKVDLBd2 ILAUOUy2S99Lj0PoqEL7lQ/QLrt/zxi6mK/IIzkQflkeJqDEUKOOv4gP8vB9TEFSQvsC QnTysLKh6T9GBtpYHvm+USv+1Zu/U6x850HDKHN2YQnWnTjOAtRIjADv66K/YHwfj3zn odLyCSprS7/JmGuccvi23OirRJ+9lmA1FUf6PMyzWbTGqwz6QtYIFdnoHaJ5q20q4zq8 qupg== 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=+O4l+/uoSSOuJ4ArOdUVdbmQf9L+QxoUenYLZDAzy2w=; b=b8kfvKX/kExnXGCYykgaGCXTFSYaAaM7SIy/yGxOhjRtCBZBcbEcp8dLvufN0GYCSm kkI+K6Ub+tuUVgUCKg/nuiCKAjBKa5wXLTKTntwsgk+V7fv/rlYZztwrZPD/yNV/X9av J8fA6NWbJvg0bGyth/dyyPjv0nW1rpaSTgyPr9k6ZLRczrFh0WuXZe4Ca/hxR6+1skg/ qciq84GWwoIdgh/MFGUZ+ZxOxfNJPUAQJKERiKmrFwbJqI4CUeYOzhUB5l5Knm3ljreV nEDxkcK6NODxOGHeMVH03yowtMlK6awj/4zto829a/gT0N0nKfMJQ1i39ytIog9Cjgjq xmjw== X-Gm-Message-State: AEkoouttL+llWUuscNBB1ThypEPiErKgeIgxeF3Xx1KuxQwtqfzOpxFBXruzp6KEf6NU0fP4/duS4m3dpSL96JpZSErb8DgEo74AqXid/xzrN9ILpZis1ijyrGWQ9JTXqOYF/dgPrVYtYpwWssbUhH+YFKg= X-Received: by 10.31.93.129 with SMTP id r123mr41018848vkb.149.1470425189387; Fri, 05 Aug 2016 12:26:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.38.132 with HTTP; Fri, 5 Aug 2016 12:26:13 -0700 (PDT) From: "Lundberg, Johannes" Date: Fri, 5 Aug 2016 12:26:13 -0700 Message-ID: Subject: evdev patches 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: Fri, 05 Aug 2016 19:26:30 -0000 4oCLSGkNCg0KVGhlIGV2ZGV2IHBhdGNoZWQga2VybmVsIGZvdW5kIGhlcmUNCmh0dHBzOi8vd2lr aS5mcmVlYnNkLm9yZy9TdW1tZXJPZkNvZGUyMDE0L2V2ZGV2X1RvdWNoc2NyZWVucw0KaXMgb3Zl ciBhIHllYXIgb2xkIGFuZCBkb2VzIG5vdCBwYXRjaCBjbGVhbmx5IHRvIGN1cnJlbnQuDQoNCkRv ZXMgYW55b25lIGhhdmUgYSBzZXQgb2YgcGF0Y2hlcyBmb3IgZXZkZXYgdGhhdCB3aWxsIGFwcGx5 IG9uIGN1cnJlbnQgaGVhZD8NCg0KSWYgbm90IEkgd2lsbCB0cnkgdG8gY2xlYW4gdGhlbSB1cCBz byB0aGV5IGFwcGx5IHRvIGN1cnJlbnQuDQoNCldoYXQgbmVlZHMgdG8gYmUgcGF0Y2hlZCBtYW51 YWxseSBpcw0KDQphdGtiZC5jDQpwc20uYw0Ka2JkbXV4LmMNCnVrYmQuYw0KdW1zLmMNCnVlcC5j DQoNClRoYW5rcyHigIsNCgotLSAKPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0t PS09LT0tPS09LT0tPS09LT0tCuenmOWvhuS/neaMgeOBq+OBpOOBhOOBpu+8muOBk+OBrumbu+Wt kOODoeODvOODq+OBr+OAgeWQjeWum+S6uuOBq+mAgeS/oeOBl+OBn+OCguOBruOBp+OBguOCiuOA geenmOWMv+eJueaoqeOBruWvvuixoeOBqOOBquOCi+aDheWgseOCkuWQq+OCk+OBp+OBhOOBvuOB meOAggrjgoLjgZfjgIHlkI3lrpvkurrku6XlpJbjga7mlrnjgYzlj5fkv6HjgZXjgozjgZ/loLTl kIjjgIHjgZPjga7jg6Hjg7zjg6vjga7noLTmo4TjgIHjgYrjgojjgbPjgZPjga7jg6Hjg7zjg6vj gavplqLjgZnjgovkuIDliIfjga7plovnpLrjgIEK6KSH5YaZ44CB6YWN5biD44CB44Gd44Gu5LuW 44Gu5Yip55So44CB44G+44Gf44Gv6KiY6LyJ5YaF5a6544Gr5Z+644Gl44GP44GE44GL44Gq44KL 6KGM5YuV44KC44GV44KM44Gq44GE44KI44GG44GK6aGY44GE55Sz44GX5LiK44GS44G+44GZ44CC Ci0tLQpDT05GSURFTlRJQUxJVFkgTk9URTogVGhlIGluZm9ybWF0aW9uIGluIHRoaXMgZW1haWwg aXMgY29uZmlkZW50aWFsCmFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUuCkRp c2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciBhbnkgb3RoZXIgYWN0aW9uIG9mIHVz ZSBvZiB0aGlzCmVtYWlsIGJ5IHBlcnNvbiBvdGhlciB0aGFuIGludGVuZGVkIHJlY2lwaWVudCwg aXMgcHJvaGliaXRlZC4KSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBhbmQg aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluCmVycm9yLCBwbGVhc2UgZGVzdHJveSB0aGUgb3Jp Z2luYWwgbWVzc2FnZS4K From owner-freebsd-current@freebsd.org Fri Aug 5 20:04: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 8D1F7BB0ED8 for ; Fri, 5 Aug 2016 20:04:53 +0000 (UTC) (envelope-from rwmaillists@googlemail.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 2C5281B4C for ; Fri, 5 Aug 2016 20:04:53 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: by mail-wm0-x22b.google.com with SMTP id q128so43406539wma.1 for ; Fri, 05 Aug 2016 13:04:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=P4b6Fpgg2CbJoA7o9JurqK4ljEMz1kM8FRrSGx9hAqo=; b=anS3LG34y0DXfBmqq/I9gQxDSaiiSa3ocmFdxpyQgUvTUQiZQdwK6HCiT6XsbRn5Wa 0I/MVQfBxeZbJTgMlrTi1adytfh4Rxs32MFg1scRclUlKQ7yly5HWr5lRkr5Tmf+ozWy vGNZ9Dp70JjMv3kKDse44tQrAWDB2Fhbyy1zclmriLfVdRRDtHLobgq0BZqfJvgCFJAs e5r81RGJsKoJZ2OUcolVRRwJKuBthoULpkgPyXpkJg/64yco81Ktaslr+8uBCsvGNFhp BLNuimpWNZOC36P4YYG3ZywUoBCVaAyKKalZUrH/oEf/p5VF/VQ753o90Cv2HQIwDgQD ALOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=P4b6Fpgg2CbJoA7o9JurqK4ljEMz1kM8FRrSGx9hAqo=; b=k+bip+JhOZHpmPhF6qJE7FSl2E2zDupfdx6pTqqs2T/dvLj0QT50jlifNBfjGrYEzD HoVb68CEbYBXgbK/kV6vc1vw4KqT8xmOHyV2FPX9SLoJCymVaBwsOs8J4M/4Irnzicyd 4ywjZV4s3x+S/brGndkQSMFRZkesVTgTfk43r6VKGbb1WiQAEFlzBHtyn7VMNoouWt56 ZeYKEZswD2crUA9tS3otp62aMthg7xrvldg86Z8AZFiEL31x15pUJJUNaB4puIoZhwGX rbOlpMIzayDXMDCtlVvPYlHoozilrH7MxNxW3p3REkMQL8NTqIszb3E8h0DRiHHVRzfX siwA== X-Gm-Message-State: AEkoouvzy0xIsoBDJABmqQwZCqz0TkTNcEuzSK1FQwDeW+OqjbF2vSGY/Moj72z84B1Ytg== X-Received: by 10.194.16.65 with SMTP id e1mr48168050wjd.143.1470427491581; Fri, 05 Aug 2016 13:04:51 -0700 (PDT) Received: from gumby.homeunix.com ([81.171.59.228]) by smtp.gmail.com with ESMTPSA id n2sm19369270wjd.1.2016.08.05.13.04.48 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 05 Aug 2016 13:04:50 -0700 (PDT) Date: Fri, 5 Aug 2016 21:04:45 +0100 From: RW To: freebsd-current@freebsd.org Cc: "bergerkos@yahoo.co.uk" Subject: Re: release name Message-ID: <20160805210445.42d88e7e@gumby.homeunix.com> In-Reply-To: <1647344805.12798604.1469990480731.JavaMail.yahoo@mail.yahoo.com> References: <1647344805.12798604.1469990480731.JavaMail.yahoo.ref@mail.yahoo.com> <1647344805.12798604.1469990480731.JavaMail.yahoo@mail.yahoo.com> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd10.2) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 05 Aug 2016 20:04:53 -0000 On Sun, 31 Jul 2016 18:41:20 +0000 (UTC) Kostya Berger wrote: > Could somebody, please, explain this: > Am I right to assume that CURRENT or "head" release number is now > 12.0?For in that case I'll have to reduild the ports in case of > upgrading my system to the current head, right?Because my current > system was build well before the 11.0-alpfha releases statred > appearing. With stable branches and releases you rebuild ports when crossing a major boundary because that's the only time ABI changes can break packages. With CURRENT the ABI can change, and break packages, at any time. From owner-freebsd-current@freebsd.org Fri Aug 5 19:22:13 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2F2C1BB061B for ; Fri, 5 Aug 2016 19:22:13 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B96E116BD for ; Fri, 5 Aug 2016 19:22:12 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id u75JM93C030131; Fri, 5 Aug 2016 21:22:09 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id A831F691; Fri, 5 Aug 2016 21:22:08 +0200 (CEST) Message-ID: <57A4E760.40209@omnilan.de> Date: Fri, 05 Aug 2016 21:22:08 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jan Bramkamp CC: FreeBSD current Subject: Re: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory References: <7c39e5ac-3ed7-f19a-e175-d27af07eea47@delphij.net> <575ACEB2.2030307@wemm.org> <6f2f1234-1d12-7796-f0b5-9da5a44585db@rlwinm.de> In-Reply-To: <6f2f1234-1d12-7796-f0b5-9da5a44585db@rlwinm.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Fri, 05 Aug 2016 21:22:09 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-Mailman-Approved-At: Fri, 05 Aug 2016 20:14: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: Fri, 05 Aug 2016 19:22:13 -0000 Bezüglich Jan Bramkamp's Nachricht vom 13.06.2016 14:46 (localtime): > > > On 10/06/16 16:29, Peter Wemm wrote: >> On 6/9/16 6:49 PM, Matthew Seaman wrote: >>> On 09/06/2016 18:34, Craig Rodrigues wrote: >>>> There is still value to ypldap as it is now, and getting feedback from >>>> users (especially Active Directory) would be very useful. >>>> If someone could document a configuration which uses IPSEC or OpenSSH >>>> forwarding, that would be nice. >>>> >>>> In future, maybe someone in OpenBSD or FreeBSD will implement things >>>> like >>>> LDAP over SSL. >>> >>> What advantages does ypldap offer over nss-pam-ldapd (in ports) ? >>> nss-pam-ldapd can use both ldap+STARTTLS or ldaps to encrypt data in >>> transit, and I find it works very well for using OpenLDAP as a central >>> account database. I believe it works with AD, but haven't tried that >>> myself. >>> >>> Cheers, >>> >>> Matthew >>> >>> >> >> We used nss-pam-ldapd quite successfully in the freebsd.org cluster >> during our transition away from YP/NIS, for what it's worth. > > Did you try the OpenLDAP nssov overlay? It replaces nslcd by > reimplementing the protocol spoken between nslcd and nss_ldap/pam_ldap > directly inside slapd. This allows slapd to cache or replicate the > data locally without resorting to the broken nscd. Hello, I was curious, so I made a patcheset which adds NSSOV config option to net/openldap24-server. Unfortunately I'm not getting results :( I decided to compile nssov.la with -DNSLCD_SOCKET=/var/run/nscld.ctl – the same as defined for net/nss-pam-ldapd. Just for testing, will consider reverting that because slapd drops priviledges before creating the socket, so ldap needs write access to /var/run... Starting nslcd makes 'id ldapuser' return correct results. Stopping nslcd and starting slapd (with verified configuration – ldapsearch works as expected) just doesn't utilize slapd at all, according to the logs. Have you compiled the nss_ldap library from contrib/slapd-modules/nssov/nss-pam-ldapd/ or do you also use the port? Thanks for hints, -harry From owner-freebsd-current@freebsd.org Fri Aug 5 20:31: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 C742ABAF7E7; Fri, 5 Aug 2016 20:31:25 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8A20E1BB3; Fri, 5 Aug 2016 20:31:25 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi0-x234.google.com with SMTP id 4so169151875oih.2; Fri, 05 Aug 2016 13:31:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=aUCkL52ZP6HE9i/blPFMWgeRjHG6wtN4jDGBkFv1rkU=; b=PBFteg3eOG+OWioZ6crd+uwdt5VeiJwoQtSR1at7PKMi8/eNYtuknmr2Ix0XJSV+Em 8eyPd5Oau7NMLJNh9LicDCQrDxHsX+1VJEoynAGIT6yCdF3FL1qYbzkHcOwZJAWnYf1x kgsv2SS4JqlFrdpvTVlnq5RvtFeHP70LCF/l3FCrdhxcPiWmmDY7dv/jLHcT0pREGZgg g4W3RtVhWgD1RmAy+AOmXWRG1pLangH2rYkIbh0s4Fr0yomZJQl/hmzLMfPAnwWj8nW1 LPzo3UqhNT+iiwwGcS3IeJnb/CY3G1yaP1r1AMFNSliWwLKl09T4fo2rjssbJvPDSSPz TIIw== 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=aUCkL52ZP6HE9i/blPFMWgeRjHG6wtN4jDGBkFv1rkU=; b=RdKpPcJBG1qTdZd1cNZ2ReAWgYcFJEKLWmTuEN7DK7twXFrTAbmfzLXynBbfta3AKH cl/pafBdt6BErVTxhysEbXLDE3qnM7lTzG8rOWyRlfcpiLahBw57qdD6z62GkA1mt/95 9MxXx0HAt5s6mJf34AX8SUWpE6WCLuyd0cPx0i2v/Fq2lA+YqskTzWviUiV5lysbDt+R HywIQw5U4Xj0k7+GEiqvrWOUp6dgxCmhLw81WajNvsv0FTbfKdspYFHuXRCd700rUc2w vF+mKdJXAT3sZCDoPdkF9dAeTQmFULJNKL+xCsIlKuDvusgBTtf1ascMWZydOcJJz/Rk 76Kw== X-Gm-Message-State: AEkoousp6Sa5xDqFgVcvGVXeNbOn2Q4hc+V9C0O2j9osnCvnhYDTKMBL2HKORORuKujIxSsvmfyvCCGwYIbeiQ== X-Received: by 10.157.14.5 with SMTP id c5mr51756662otc.55.1470429084674; Fri, 05 Aug 2016 13:31:24 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.202.196.149 with HTTP; Fri, 5 Aug 2016 13:31:24 -0700 (PDT) In-Reply-To: <04a12279-ab01-5f5c-d8d3-5571db07c229@FreeBSD.org> References: <3f79e88d-a519-0c8d-f16a-7c83460a37c1@FreeBSD.org> <04a12279-ab01-5f5c-d8d3-5571db07c229@FreeBSD.org> From: Alan Somers Date: Fri, 5 Aug 2016 14:31:24 -0600 X-Google-Sender-Auth: J8-f0HNy0CS4YjEA0TtoNjhUAbU 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: Fri, 05 Aug 2016 20:31:25 -0000 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. 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" From owner-freebsd-current@freebsd.org Sat Aug 6 00:10: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 8020ABAE6BD for ; Sat, 6 Aug 2016 00:10:04 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (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 63F751774 for ; Sat, 6 Aug 2016 00:10:04 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from [76.102.118.237] (helo=[10.0.1.2]) by id.bluezbox.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.86_2 (FreeBSD)) (envelope-from ) id 1bVpBb-000MOT-QX; Fri, 05 Aug 2016 17:09:56 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: evdev patches From: Oleksandr Tymoshenko In-Reply-To: Date: Fri, 5 Aug 2016 17:09:56 -0700 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <28564DC6-74AA-4690-B355-2E3C7ACAF727@bluezbox.com> References: To: "Lundberg, Johannes" X-Mailer: Apple Mail (2.3124) Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: > On Aug 5, 2016, at 12:26 PM, Lundberg, Johannes wrote: > > ​Hi > > The evdev patched kernel found here > https://wiki.freebsd.org/SummerOfCode2014/evdev_Touchscreens > is over a year old and does not patch cleanly to current. > > Does anyone have a set of patches for evdev that will apply on current head? > > If not I will try to clean them up so they apply to current. > > What needs to be patched manually is > > atkbd.c > psm.c > kbdmux.c > ukbd.c > ums.c > uep.c > > Thanks!​ [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: github.com] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.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, 06 Aug 2016 00:10:04 -0000 > On Aug 5, 2016, at 12:26 PM, Lundberg, Johannes = wrote: >=20 > =E2=80=8BHi >=20 > The evdev patched kernel found here > https://wiki.freebsd.org/SummerOfCode2014/evdev_Touchscreens > is over a year old and does not patch cleanly to current. >=20 > Does anyone have a set of patches for evdev that will apply on current = head? >=20 > If not I will try to clean them up so they apply to current. >=20 > What needs to be patched manually is >=20 > atkbd.c > psm.c > kbdmux.c > ukbd.c > ums.c > uep.c >=20 > Thanks!=E2=80=8B There is code review for initial evdev support: = https://reviews.freebsd.org/D6998 It stalled couple of weeks ago, probably now that freeze is over work = can be resumed.=20 It's based on Valdimir Kondratiev's evdev branch: = https://github.com/wulf7/freebsd From owner-freebsd-current@freebsd.org Sat Aug 6 04:15: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 86A74BB02EB for ; Sat, 6 Aug 2016 04:15:44 +0000 (UTC) (envelope-from grog@lemis.com) Received: from www.lemis.com (www.lemis.com [208.86.226.86]) by mx1.freebsd.org (Postfix) with ESMTP id 624FE15CF; Sat, 6 Aug 2016 04:15:43 +0000 (UTC) (envelope-from grog@lemis.com) Received: from eureka.lemis.com (www.lemis.com [208.86.226.86]) by www.lemis.com (Postfix) with ESMTP id 45F831B72803; Sat, 6 Aug 2016 04:15:37 +0000 (UTC) Received: by eureka.lemis.com (Postfix, from userid 1004) id 3C1B344948D; Sat, 6 Aug 2016 14:15:36 +1000 (AEST) Date: Sat, 6 Aug 2016 14:15:36 +1000 From: Greg 'groggy' Lehey To: Andrey Chernov Cc: Mark Martinec , freebsd-current@freebsd.org Subject: Re: date(1) default format changed between 10.3 and 11.0-BETA3 Message-ID: <20160806041536.GL86883@eureka.lemis.com> 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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k9xkV0rc9XGsukaG" Content-Disposition: inline In-Reply-To: <4a454eef-55ae-b90d-4441-2aa9708fc747@freebsd.org> Organization: The FreeBSD Project Phone: +61-3-5346-1370, +61-3-5309-0418 Mobile: 0401 265 606. Use only as instructed. WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 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, 06 Aug 2016 04:15:44 -0000 --k9xkV0rc9XGsukaG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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: >>> On 05.08.2016 17:47, Mark Martinec wrote: >>>> [Bug 211598] >>>> date(1) default format in en_EN locale breaks compatibility with 10.3 >>>> and violates POSIX >>>> >>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211598 >>> >>> It breaks compatibility but not violates POSIX. POSIX care of only its >>> own POSIX (or C) locale. >> >> 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. Greg -- Sent from my desktop computer. Finger grog@FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA --k9xkV0rc9XGsukaG Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlelZGgACgkQIubykFB6QiNpFgCgs8BvmK7uA/41CBqzWzc2NmtJ noYAnjsV/+wSPw0pkIkeZVSxxSpg78ee =9im0 -----END PGP SIGNATURE----- --k9xkV0rc9XGsukaG-- From owner-freebsd-current@freebsd.org Sat Aug 6 10:00: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 28A2FBB0CA2 for ; Sat, 6 Aug 2016 10:00:57 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B4DA21977; Sat, 6 Aug 2016 10:00:56 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by mail-wm0-x242.google.com with SMTP id x83so7044793wma.3; Sat, 06 Aug 2016 03:00:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=FmgDoEvmhZnjv2SvAfO9PJ1mmPGpDzqa+9yhC4s2YqQ=; b=d453am8wPp7NWIEfu6JGqZ/DcLunnkQ1V0wBxWiYJC7mN9Vy7E6GhSATLD3DJbn++c oJVU5IDcnjuIAjhh2XnZAcGbtSJAtqOmJVXy40rjo93seUMTGm5HO0ityuLuPqdwF1kM X4q2j5DEFzsDp4idZ73ZLqg6/xKC7mbYCQEGQ9eVJYNDvs0vdX8RmckSiYaVOgIyL2KY 6/XdTfUhUzSBpv+diQRkZ9lihV5UC1vwyaLZxFpeCfNcX9nN928utd44zDz2tRByQfcl pF0mNNT4r/LWPmQxzSxX9TuwMlAJShP8QL0y44SfT+aHIslndlRF/JPuVhZvreymdq18 IEaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=FmgDoEvmhZnjv2SvAfO9PJ1mmPGpDzqa+9yhC4s2YqQ=; b=L+j2kL2J+HQJKGo/FGng6hQSgbADLnqGaRpwtsQzAqvk0njYz0pQ5Oe6Uz/gpVl8to ZOlGVlTmbjOPfNzP2whPFzTxhKcj8zwW2VHHZZgCc5Qy1zXkynXNtaQfBfwgENJ1VFiY M9a8Xs1/UjAkEVj8fuhvTwk1Np2tXL28Wn8JO5OGrFyjav4/+JGmfpNW6MusKeSRFLhm x+U4QaBEm9GhVcEP3856n5JEqmfy6ZyDHXg/8VTs6kLjqFSu0hTt0pm6qA/DQHvb8N9s zYA0MjLMoAZOdb8DfBR8QcqAg7R0+o6dkx5kcHz/pxymzVmq+6e7gynRyidFtbqRaqD1 hgyw== X-Gm-Message-State: AEkoouttSE7lpkiwoaFLT2+T+NFzeVOgfYFe1gpMgt0qZqMvrozzW6ax8CAM6s6C+BzHtQ== X-Received: by 10.28.41.131 with SMTP id p125mr7152138wmp.15.1470477654804; Sat, 06 Aug 2016 03:00:54 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by smtp.gmail.com with ESMTPSA id p1sm22109806wjd.37.2016.08.06.03.00.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 Aug 2016 03:00:54 -0700 (PDT) Sender: Baptiste Daroussin Date: Sat, 6 Aug 2016 12:00:53 +0200 From: Baptiste Daroussin To: Greg 'groggy' Lehey Cc: Andrey Chernov , Mark Martinec , freebsd-current@freebsd.org Subject: Re: date(1) default format changed between 10.3 and 11.0-BETA3 Message-ID: <20160806100053.5fpf27pcgona7czp@ivaldir.etoilebsd.net> 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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="yvyxn2j2jf2min7h" Content-Disposition: inline In-Reply-To: <20160806041536.GL86883@eureka.lemis.com> User-Agent: Mutt/1.6.2-neo (2016-07-23) 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, 06 Aug 2016 10:00:57 -0000 --yvyxn2j2jf2min7h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: > >>> On 05.08.2016 17:47, Mark Martinec wrote: > >>>> [Bug 211598] > >>>> date(1) default format in en_EN locale breaks compatibility with 1= 0.3 > >>>> and violates POSIX > >>>> > >>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211598 > >>> > >>> It breaks compatibility but not violates POSIX. POSIX care of only its > >>> own POSIX (or C) locale. > >> > >> 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. >=20 > It still violates POLA. >=20 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 POSI= X. 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 a= nd 193 if we do count the encoding variants. locales are updated very often (f= or exemple cldr unicode make a new release of the data every 8 month or so) No locales defines the same date format and that was already the case befor= e the change we did Now if people have strong arguments for a specific locale I'm inclined to a= dd some hacks in our tool that generates our locales to make sure we fix the upstream data (http://cldr.unicode.org) we already committed some and I'm planning to report upstream (cldr) all the issues we have faced to improve. Best regards, Bapt --yvyxn2j2jf2min7h Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXpbVUAAoJEGOJi9zxtz5a2r0QAKpd1WnYZMMOHO311Ipp1qRh 6PQOxnzPiolfzKGpaOQvQI0ZNuQfNNNrWP37/J1XoCkv5ObqY0P/Nw/KrQ8JyQ70 MeYlf5V0TFt1OEcFLrtIhkwtjPwM4wQ80KOFFDwPsKjbAtJm0SXhVSGljkgxtm7d 8ey87vm7G508zLaT4hld7FmFwEbBTdkd/pFdDI5JWZESU7abHcZ29duk+4FZ6BHl KBrJreBp1AboYIyYHEEdNxtgyb+Jcc19Y8FextyPmGoICHmNJEnbySPhpe0A/AUR LsnJV7+ofMtZeYrxaJFVYHfwkyNt0EFNQH4N4ERilVlW6n8cvS6zoFTDpGz5m4zi pLqGDOWUBQx+q6m+oDxujeTIlxScbjoUSnJ5//TQ9gRdCvFUYfdJ+cTYGZ/bXkmD 20Tm7eo690HYBJyA8hAgDr1x1a8VNvQkOYlqjCWDI/YwQG48FTm+TO0xmtpeNdJT pu5+BGFt21/zCcbSwk5AbC+A6BOku0gOYXNyjei0CZzPqPzQnnmvlnVSsKi+neoz kx1maf5dyLVmcS7AYZ1VLPjn3rcKlW3A1wTXZ/3X4F52z+h1vJj1paEMsSJm6a8P 9QMaTHJeQeOpC2nQajpsHEIK/q96CBq2HOisASnaRtc5mikN+w41sCEHV/wP/Xqr eklY4chkV5qRI4RIqihG =AY8v -----END PGP SIGNATURE----- --yvyxn2j2jf2min7h-- From owner-freebsd-current@freebsd.org Sat Aug 6 11:08: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 389AEBAFCE0; Sat, 6 Aug 2016 11:08:45 +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 2564113C4; Sat, 6 Aug 2016 11:08:43 +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 OAA27688; Sat, 06 Aug 2016 14:06:46 +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 1bVzRG-0001q1-1X; Sat, 06 Aug 2016 14:06:46 +0300 Subject: Re: some [big] changes to ZPL (ZFS<->VFS ) To: Alan Somers References: <3f79e88d-a519-0c8d-f16a-7c83460a37c1@FreeBSD.org> <04a12279-ab01-5f5c-d8d3-5571db07c229@FreeBSD.org> Cc: FreeBSD Filesystems , FreeBSD Current From: Andriy Gapon Message-ID: <4bb4d0c0-fdbb-ed8c-1a47-0e789d777c1a@FreeBSD.org> Date: Sat, 6 Aug 2016 14:05:53 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.3; 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-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, 06 Aug 2016 11:08:45 -0000 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 Sat Aug 6 15:09: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 8E248BAF749 for ; Sat, 6 Aug 2016 15:09:36 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DE9A41CD0; Sat, 6 Aug 2016 15:09:35 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074423-417ff70000001b26-fb-57a5fdac8b39 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id AE.DB.06950.CADF5A75; Sat, 6 Aug 2016 11:09:33 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u76F9VFM021435; Sat, 6 Aug 2016 11:09:31 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u76F9PQu014803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 6 Aug 2016 11:09:30 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u76F9OqL007586; Sat, 6 Aug 2016 11:09:24 -0400 (EDT) Date: Sat, 6 Aug 2016 11:09:24 -0400 (EDT) From: Benjamin Kaduk To: Baptiste Daroussin cc: "Greg 'groggy' Lehey" , Andrey Chernov , Mark Martinec , freebsd-current@FreeBSD.org Subject: Re: date(1) default format changed between 10.3 and 11.0-BETA3 In-Reply-To: <20160806100053.5fpf27pcgona7czp@ivaldir.etoilebsd.net> Message-ID: 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> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrIIsWRmVeSWpSXmKPExsUixCmqrbv279Jwg5WPmC2Onehhsvj96yKr xZw3H5gsPn75x2zxr/kjqwOrx4xP81k8tryfyxrAFMVlk5Kak1mWWqRvl8CVcfrzP5aCU9wV /0/8ZW5gbObsYuTkkBAwkTi2/w9jFyMXh5BAG5PEvPYPTBDOBkaJxXthMgeZJL7MXc8E0iIk UC8x/8MhVhCbRUBLormhnQ3EZhNQkZj5ZiOYLSKgKbHx214WEJtZYCujxMQLjCC2sIC7RP+f hcwgNqeAi8SePb1gNq+Ag0Tzu5/sEMuaWSR+9DaCJUQFdCRW75/CAlEkKHFy5hOooVoSy6dv Y5nAKDALSWoWktQCRqZVjLIpuVW6uYmZOcWpybrFyYl5ealFumZ6uZkleqkppZsYQSHL7qK8 g/Fln/chRgEORiUe3gXrloQLsSaWFVfmHmKU5GBSEuU9fxkoxJeUn1KZkVicEV9UmpNafIhR goNZSYS34NvScCHelMTKqtSifJiUNAeLkjjv9m/t4UIC6YklqdmpqQWpRTBZGQ4OJQneJX+A GgWLUtNTK9Iyc0oQ0kwcnCDDeYCG+4HU8BYXJOYWZ6ZD5E8xKkqJ8zqDJARAEhmleXC94JSy m0n1FaM40CvCvPEgVTzAdATX/QpoMBPQ4I9WS0AGlyQipKQaGLPNOL29ql8GBLxeY3T987Fv kT1fj92afaopLHUn63kFGTGxpFNpe2oyjRrsmzu3xWm2Ld3JvtbA+ZroFIHkY5/3XL38cEfX /xPNa/6+Sr79+fnzNMYktufM+xglXB2bfkT+Yy5fUywe31SyZOPBV4vDUxp+K+1uc+D1uMqX xruh5wJj+vaGAiWW4oxEQy3mouJEALxGS5EEAwAA 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, 06 Aug 2016 15:09:36 -0000 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. > 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 From owner-freebsd-current@freebsd.org Sat Aug 6 17:10: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 F06AFBB0A1C for ; Sat, 6 Aug 2016 17:10:29 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B1F1B1B7C for ; Sat, 6 Aug 2016 17:10:29 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: by mail-yb0-x22e.google.com with SMTP id g133so24058899ybf.2 for ; Sat, 06 Aug 2016 10:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:cc; bh=m68CHGI8l9GncYGMDaL2S9+9SjSVgH2I3xgBDQpZp28=; b=inDmLOKamjPYWNRkPaBHGARxerXjV1Vnag35p/DwINzCwFTixvxpdxPufVlFajYGfk hh1Zp1KxYK+R9oXslh5PeCzPP4+TJ43XPtWRctjREk3EFZ6jwzlrr5hJEQnNw+ze2GUH h74DeIqlN3KZ76iC/t0h+6CjlBu9hEJ2ugMHxLwfr8Fkw4ApAqRiPmqBim0ICQWspB9s wOFnQCJUes9iDpBJtycCl30YdpxxX/06eP8MYIqzGkS5QwTD5fvxk67VoRuRlThAEspI tBmdqDqB39o6lxRohqPBMB+825XBKUlqfmsdCcn0o+UZLyHvQvh7NlS+idEG2UmVjUjx uDCg== 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:cc; bh=m68CHGI8l9GncYGMDaL2S9+9SjSVgH2I3xgBDQpZp28=; b=XpAZ9XXIj4haCmHd5BJpwhCv1v1a5hoXm/9uLj/IkJuDRj0d+QPB5k7COHm2U9Rkbu MrwvX+GVq8aDFVSTFPrpROC5tcHSLGUEp6S7q3CVeSCh10ZpDa+lu1UdF5cjmio+kgMc LQIMUVjMo3Snc3nT5n8K1HCEsu6nbCrW/hBijoh/d4AbzSPb8xk3vxlPnAMOneBRORfC kOb9oRVFTneCQnetJbJbAQM/4cM7RVUH/tPkUB6kumFH0HuhZgTsN+EN5Uj55FNKgHe/ bRVflXXYnj742FF+ocrCZfQi+01GNtoeGHt1ggRm6M+0wL1fCf+Rm1viSIlkxGx/5lGW 8U8g== X-Gm-Message-State: AEkooutDw/bildvFTAmSUpVJMR6dUkpc4OBsLZMM5oD7ghkvkrSUbm9JUU9kEFjbNB3a3oSJoVLC6qkWlngAoQ== X-Received: by 10.37.80.205 with SMTP id e196mt16282968ybb.55.1470503428684; Sat, 06 Aug 2016 10:10:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.51.150 with HTTP; Sat, 6 Aug 2016 10:10:28 -0700 (PDT) From: Ultima Date: Sat, 6 Aug 2016 13:10:28 -0400 Message-ID: Subject: rc scripts new login_class, default can break old rc scripts Cc: freebsd-current@freebsd.org, freebsd-stable@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: Sat, 06 Aug 2016 17:10:30 -0000 I recently upgraded one of my boxes to FreeBSD 11 r303750 (beta-3). After the upgrade I noticed that one of the services would no longer start... After digging into it, I found that the new var ${name}_login_class var's defaults to the daemon login class and by default, the daemon class resource limit on memory is set to 128M. This maybe an issue for old rc scripts. So my question is this, should old rc scripts adapt to this new default, or should the default be changed to avoid issues like I just found? The port this issue was found is audio/teamspeak3-server. If installed on FreeBSD 11+ it will fail to start with... 2016-08-06 17:07:27.946432|CRITICAL|ServerLibPriv | |Server() DatabaseError out of memory Ultima From owner-freebsd-current@freebsd.org Sat Aug 6 17:16: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 32877BB0CAD; Sat, 6 Aug 2016 17:16:34 +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 F142411B2; Sat, 6 Aug 2016 17:16:33 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.87 (FreeBSD)) (envelope-from ) id 1bW5D9-0006yZ-AO; Sat, 06 Aug 2016 19:16:35 +0200 Date: Sat, 6 Aug 2016 19:16:35 +0200 From: Kurt Jaeger To: Ultima Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: rc scripts new login_class, default can break old rc scripts Message-ID: <20160806171635.GT96200@home.opsec.eu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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, 06 Aug 2016 17:16:34 -0000 Hi! > So my question is this, should old rc scripts adapt to this new default, or > should the default be changed to avoid issues like I just found? There should be a PR about this, and please give it to re (release engineering). -- pi@opsec.eu +49 171 3101372 4 years to go ! From owner-freebsd-current@freebsd.org Sat Aug 6 19:08: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 D459DBB0AEA for ; Sat, 6 Aug 2016 19:08: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 2E7691A52; Sat, 6 Aug 2016 19:08:29 +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 u76J8GwN012658 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 6 Aug 2016 12:08:19 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: date(1) default format changed between 10.3 and 11.0-BETA3 To: Benjamin Kaduk , Baptiste Daroussin 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> Cc: "Greg 'groggy' Lehey" , Andrey Chernov , Mark Martinec , freebsd-current@FreeBSD.org From: Julian Elischer Message-ID: <3b68be24-7ec8-08be-53f4-a4b088840c35@freebsd.org> Date: Sun, 7 Aug 2016 03:08:11 +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: Sat, 06 Aug 2016 19:08:29 -0000 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 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Sat Aug 6 21:05: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 853A6BB18CC; Sat, 6 Aug 2016 21:05:28 +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 78F15159A; Sat, 6 Aug 2016 21:05:28 +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 2E0DD1F11; Sat, 6 Aug 2016 21:05:28 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Sat, 6 Aug 2016 21:05:26 +0000 From: Glen Barber To: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Cc: FreeBSD Release Engineering Team Subject: FreeBSD 11.0-BETA4 Now Available Message-ID: <20160806210526.GJ50364@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, 06 Aug 2016 21:05:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The fourth BETA build of the 11.0-RELEASE release cycle is now available. Installation images are available for: o 11.0-BETA4 amd64 GENERIC o 11.0-BETA4 i386 GENERIC o 11.0-BETA4 powerpc GENERIC o 11.0-BETA4 powerpc64 GENERIC64 o 11.0-BETA4 sparc64 GENERIC o 11.0-BETA4 armv6 BANANAPI o 11.0-BETA4 armv6 BEAGLEBONE o 11.0-BETA4 armv6 CUBIEBOARD o 11.0-BETA4 armv6 CUBIEBOARD2 o 11.0-BETA4 armv6 CUBOX-HUMMINGBOARD o 11.0-BETA4 armv6 GUMSTIX o 11.0-BETA4 armv6 RPI-B o 11.0-BETA4 armv6 RPI2 o 11.0-BETA4 armv6 PANDABOARD o 11.0-BETA4 armv6 WANDBOARD o 11.0-BETA4 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 "stable/11" branch. A summary of changes since 11.0-BETA3 includes: o The mtx_trylock_spin(9) kernel synchronization primitive was added. o The machdep.disable_msix_migration loader tunable has been re-enabled for EC2 AMIs. o The iwm(4) and iwmfw(4) drivers have been updated. o The new system hardening options have been fixed to avoid overwriting other options selected during install time. o Several build-related fixes. o Several miscellaneous bug fixes. A list of changes since 10.0-RELEASE are available on the stable/11 release notes: https://www.freebsd.org/relnotes/11-STABLE/relnotes/article.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-BETA4/ 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-fb65f7ec us-west-1 region: ami-befebede us-west-2 region: ami-4dab632d sa-east-1 region: ami-74dd4b18 eu-west-1 region: ami-6180e912 eu-central-1 region: ami-c940b7a6 ap-northeast-1 region: ami-99f137f8 ap-northeast-2 region: ami-b720ead9 ap-southeast-1 region: ami-9cf22cff ap-southeast-2 region: ami-675d6904 === Vagrant Images === FreeBSD/amd64 images are available on the Hashicorp Atlas site, and can be installed by running: % vagrant init freebsd/FreeBSD-11.0-BETA4 % 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-BETA4 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-BETA4 amd64 GENERIC: SHA512 (FreeBSD-11.0-BETA4-amd64-bootonly.iso) = c407f8c1fc71e3b40376be7038e055bddf6d2ed9eb61bfbc90055662e0324d4245653528f9a8427576a670f9ab62e610c526bf3641e6dda6b41a9867c821fed4 SHA512 (FreeBSD-11.0-BETA4-amd64-bootonly.iso.xz) = 0dfe1e2fdbdbdc457b23f766eab95125a269208ebd7f2212de57f9296ecbcecb949748a8902ae371f1abc8c3652b0431dafd7688eff8f044ceed3b17fc20f884 SHA512 (FreeBSD-11.0-BETA4-amd64-disc1.iso) = 85af891a92abe162e0169456753be731c1823f7ba274c1499a9d1259d30a6279e8d84d0bd42917141cd26b30bfe3fde621061297eca002a536159a4df6fc1a59 SHA512 (FreeBSD-11.0-BETA4-amd64-disc1.iso.xz) = 811688812a1526b2986af38736c254366b706b9ca769b92843a87292cb90f795683b6a40553c7f9c827337241c20cf02ea1e9400976d1639c5f4fe5d8706e530 SHA512 (FreeBSD-11.0-BETA4-amd64-dvd1.iso) = deadc6daa6aa2bae25846c96bbd0e477608095a8c14f6b1835953341094ff495362f2d211a64f0157c1aa1cafd1b6f8a6ab25f66e2eb001701803b5f666ceaa9 SHA512 (FreeBSD-11.0-BETA4-amd64-dvd1.iso.xz) = 1f79ef70e93f41db2b1bc5507d2668599235cb7eafd78294e767efb15ec9fe3773d68b716186ce83908d6df0b0456ffa97cf484a4b36a05006db92ee78e05fbe SHA512 (FreeBSD-11.0-BETA4-amd64-memstick.img) = bda7c66d9e8cbc67038d09412ca3eabca3348546072bb65c790dce990df03a59abbe2d68b00f993c162a1d48b0c6c2011bc217598d7c4de2ebf781fd12795b83 SHA512 (FreeBSD-11.0-BETA4-amd64-memstick.img.xz) = 82e769050aeda5e658600a297b389c3a38c1d8f11d5fc0f073f62281f6a6431aca9074deae174c511103cce4fa80eef6b9cc601f86e92f6c9f05ad593bf33d72 SHA512 (FreeBSD-11.0-BETA4-amd64-mini-memstick.img) = 774e269c8f4f4a38d9f7ad4bbae078f5b1f5e56cfd8ed623bcfb33054802f71ad9372ab70511ed652fceaf2ddf0dd4c63b26cdd09549e1361a673821c44fcb44 SHA512 (FreeBSD-11.0-BETA4-amd64-mini-memstick.img.xz) = 0417adf318b2b3428418926a241ed95d8c4fce1a70cf1d89426a9128dd3f43eb7894c12075fe5ebef85099e63fe98b78ab1eb42026535c30d82739f77a2849ce SHA256 (FreeBSD-11.0-BETA4-amd64-bootonly.iso) = 3f07b1d6d931e146d94bbab655f09331d1fed1e921b63bece295cadc6e8d839c SHA256 (FreeBSD-11.0-BETA4-amd64-bootonly.iso.xz) = f90faa464aef4221bcf2f8819f90c2c3bb84d830342f925cb22a4187632be6c9 SHA256 (FreeBSD-11.0-BETA4-amd64-disc1.iso) = 14227cf157f73b2e5228f379bc987364e0d36dba6e4686f1c5c1f9f3f2bb7357 SHA256 (FreeBSD-11.0-BETA4-amd64-disc1.iso.xz) = 9ddef985091ce54d9d1ff976ffbff4a48769bd97b51872c87795cb43039a3a39 SHA256 (FreeBSD-11.0-BETA4-amd64-dvd1.iso) = eeffe6b27a7640b2108dd96dbca4f929968c831551ef8e8c9e768bdb2fd096e4 SHA256 (FreeBSD-11.0-BETA4-amd64-dvd1.iso.xz) = 8cec67b65798c0770b2a7ab66ca6eab0962fbfe3afdaf3f2c9abd4ddd37f7477 SHA256 (FreeBSD-11.0-BETA4-amd64-memstick.img) = bb4a5b0fa253f0aee48958e48f087e68ff7209db84873d29f85c3e902dafee27 SHA256 (FreeBSD-11.0-BETA4-amd64-memstick.img.xz) = 4cd344811cb355811701b0fb06ec8013cab553d52743201542349c2e7a813548 SHA256 (FreeBSD-11.0-BETA4-amd64-mini-memstick.img) = 0b32b94ea2b3fccafcf8583b2f81208bc1fc8cc7629b90a17bb94c5328fde73d SHA256 (FreeBSD-11.0-BETA4-amd64-mini-memstick.img.xz) = 6939420fa58988f5bdc70d5fe05914cae8a5c1e3ca1c6021530e7b14190d1b88 o 11.0-BETA4 i386 GENERIC: SHA512 (FreeBSD-11.0-BETA4-i386-bootonly.iso) = b09038984abde08a7ba146f2e77a093104bd3e0d33de088814a2485432abf789d18757b4ad9fcac4f916999e6d4b051bbaf9d2e3e0d8947fc04553d8235400ec SHA512 (FreeBSD-11.0-BETA4-i386-bootonly.iso.xz) = 661ad95e94f25a2a61bfb62ba642d4aada2fae492780bca8b5230abf56425c16dedcc6126d263187d7ce02dcf4a1992d963818e4c6097868b71d9dd89c541622 SHA512 (FreeBSD-11.0-BETA4-i386-disc1.iso) = 8233453898594f798bfed87a8d733610d26c887a663edbc71a7c462eaed8db34a96268376de34f99004063ff6e3fb48967f1e43301987283a75a0ea6bbf0b8d3 SHA512 (FreeBSD-11.0-BETA4-i386-disc1.iso.xz) = 9210e3ae74a51df6efe714ed46fdfeeb5cdf0fd0ccee81520f36f745b66ec2b4375092a9775fbd16f850c69e66603213bb7181efef6d16bb353f5b97edd6b001 SHA512 (FreeBSD-11.0-BETA4-i386-dvd1.iso) = 8a466c3cb416247042db76ad17c71354e5c032de78476e5008d626693cffca4686325e86332b09031e691f5f3ae9c448ea1e7cc36c2c05679257aa0e92cf78a0 SHA512 (FreeBSD-11.0-BETA4-i386-dvd1.iso.xz) = 83d37a8653d2c1d300cc5346b36a842b623677888083aa74e42083db7e1dd0882df217777b917240679afeb1ab26ce8709f17f48047bfb70111b0bc4bfea2ac7 SHA512 (FreeBSD-11.0-BETA4-i386-memstick.img) = 69d726038c5f0973d352d9190eab1722a9b08e78e48f9923bc9e928b9524616011e02fa17c1524d09ba4cc60f093ba7056ca6ccb64ee4e831dd484330fc7e01a SHA512 (FreeBSD-11.0-BETA4-i386-memstick.img.xz) = 8dded70eb43aebe5ee463585b81bcb877bf998d2caf53f969a74e65fb6318da78ce6b3150e3f7fffcbbea238039604f719a55eb9ce9e9628ce6ee22971248c45 SHA512 (FreeBSD-11.0-BETA4-i386-mini-memstick.img) = ca8dec702c58c60c90366b3ce566b9add5a95b641ea0edd591e3535988c36e1db04a2fabef7638dfa7b0d053df55b4f8f0dedafaa99e5db4fb1319d6109242ee SHA512 (FreeBSD-11.0-BETA4-i386-mini-memstick.img.xz) = 14481e5ef9c1077f9a7e16aabd39e4835d146e6dcfe2a0d87d33de6b036c8e00d197c1c693cba6255681ca08ec197e540ed8b0d7eef561d1d585dca53bb7ae86 SHA256 (FreeBSD-11.0-BETA4-i386-bootonly.iso) = f0802c904e9e5f48ceea703bce5fc4cd951cccd7fd72bbb92e903749e1deb493 SHA256 (FreeBSD-11.0-BETA4-i386-bootonly.iso.xz) = c0e8a40533a8137355ae8b7b7e67e57654ae2cf444bda34a4492a9c31a7d7f70 SHA256 (FreeBSD-11.0-BETA4-i386-disc1.iso) = 69841a8499d306639bbe7a2f241efa0ccea5f7fd8f3f042c85bcf1481f797e96 SHA256 (FreeBSD-11.0-BETA4-i386-disc1.iso.xz) = e5c36e6c5b73ffad003333f7b62db5790ab471ac597bc534748a8160f1ae7a57 SHA256 (FreeBSD-11.0-BETA4-i386-dvd1.iso) = 080312e9e64f45794ac50c750933b00ef838cd757509b27bf24820b96f5ee18c SHA256 (FreeBSD-11.0-BETA4-i386-dvd1.iso.xz) = 5c574b4abeb0e22f85f3cc35354887498b909454d21413c7cd5383088cc7bab6 SHA256 (FreeBSD-11.0-BETA4-i386-memstick.img) = 955d6cab543abbcdbf36e4a577786cdba2f5f87657dfd2b682fa31842061274a SHA256 (FreeBSD-11.0-BETA4-i386-memstick.img.xz) = 5c1d4c9bd91ae93b99d838f886497f96e699362fbe7d58f85987f99bc032655a SHA256 (FreeBSD-11.0-BETA4-i386-mini-memstick.img) = d0bbe935086b9b694c5ef3689f627cf45c417fcbe001e27fe7cd433eb61ea788 SHA256 (FreeBSD-11.0-BETA4-i386-mini-memstick.img.xz) = 9d0c045d653fc878e8dd83e40e541617747603ec39046404846ab17a9bbd4756 o 11.0-BETA4 powerpc GENERIC: SHA512 (FreeBSD-11.0-BETA4-powerpc-bootonly.iso) = ac9a7832d39027f20dc836b2c5a51a2469eccd9d3f0a46b681f35e3f5ac28c42b93250a0c77580fd5744d4c4809838c2a86891110aeba70ee81d5f20e9b8ac3a SHA512 (FreeBSD-11.0-BETA4-powerpc-bootonly.iso.xz) = ea33b6147ef22fea8287b25bc210881f58094d168f77e90ea2ac9adf9f51566f47495754507ba69778035f522f17d18be0564fd9db16c7282c3842fdfb591984 SHA512 (FreeBSD-11.0-BETA4-powerpc-disc1.iso) = a453028e494f8952dd652c188f9c62fcfc79c5440350e44ab7b62f5da471a8c4966297ded66b35251d3c925251e4525bdf02d5f3b60188db74d86b93298721af SHA512 (FreeBSD-11.0-BETA4-powerpc-disc1.iso.xz) = 109254c3bb952eed06536df35c30bbfd566bc4bc2625d71a0a5af5f8ef1b40024dbd0db57dc8b82a9ed04ba0bbbf67af5b83de328a6a7f2d6baedc9b10192a53 SHA512 (FreeBSD-11.0-BETA4-powerpc-memstick.img) = a020e92e81452295b03da7e8c6311e6b66390b28730f15817e04d7e62ba699ebbf67fde6b655b838469004f876411533052cf96eb1c9f373d062fc8f21343f64 SHA512 (FreeBSD-11.0-BETA4-powerpc-memstick.img.xz) = 96bf24dbef2dfa3075874ed10366d4a7df216007944b5c5aef896591bd23de6e85e268aee331bd2f3c17dff91a1e7afd0f68a10369475dd4fe46aa270d3c6049 SHA512 (FreeBSD-11.0-BETA4-powerpc-mini-memstick.img) = f973482f19ad0b499897956c33c654acb39f86a3967005bf3ca3204cab4bba05f92c145b0ba1932249c60e008d37bb7492ade351203c7faa3187581604c71c76 SHA512 (FreeBSD-11.0-BETA4-powerpc-mini-memstick.img.xz) = 1b968733b68e574fb03467e643e9396741d78843cdec42e9d9faf46c4c913d15694f6a937d8ec0e9256d6bbcab9b40ee3d6bbd9dc6f0400d9de5cfe140c9566c SHA256 (FreeBSD-11.0-BETA4-powerpc-bootonly.iso) = 598a26536a547ba16c5a0b6c0112fdc3e1976bed64867111c43985ed0254023c SHA256 (FreeBSD-11.0-BETA4-powerpc-bootonly.iso.xz) = 1a401c255dd7008b989df95fc1afe067c7e378b3b89788feca3891749a6045a7 SHA256 (FreeBSD-11.0-BETA4-powerpc-disc1.iso) = 510a2ab851fbd3db42e80c4f562d3aff5fff8075f68403e720785d5aaed6d6f7 SHA256 (FreeBSD-11.0-BETA4-powerpc-disc1.iso.xz) = 29da6b687dddda1dbe0a0a84e90fb73a16b5cd151e5ff9d19d2253570bffdad2 SHA256 (FreeBSD-11.0-BETA4-powerpc-memstick.img) = 806e48645701d1ae0ca1d384eb833322093aa144b85577e7d3b953d98199e5d0 SHA256 (FreeBSD-11.0-BETA4-powerpc-memstick.img.xz) = b5351316ee71bc222347c560ce6163985d5ad90fd5b93f21990cb9b69e1157f7 SHA256 (FreeBSD-11.0-BETA4-powerpc-mini-memstick.img) = b55c62c5060277905c2331feeb0182637c3b41d63fb1ecce0099276c8683406e SHA256 (FreeBSD-11.0-BETA4-powerpc-mini-memstick.img.xz) = fac9f71545ae47d42b35dfeb554a7467acb2294bddbb9980c30df25fde7d42d4 o 11.0-BETA4 powerpc64 GENERIC64: SHA512 (FreeBSD-11.0-BETA4-powerpc-powerpc64-bootonly.iso) = 2fc74da54c5c4d4f276810eef3236dc1ec0667cfb58f62cd2775ed6141a026a420aa9d5d61feae1b327dcf7025bd095894fd83e9b280acf96254508833ffa3d0 SHA512 (FreeBSD-11.0-BETA4-powerpc-powerpc64-bootonly.iso.xz) = d1107a6618de1a7e88860c9881eb79f8767e0bfd9587aeda3d70649a80d223f7d16c399522e8082d2bd1698dfebf7eb60097014603fe4d6571e48604151163da SHA512 (FreeBSD-11.0-BETA4-powerpc-powerpc64-disc1.iso) = a82ed8b1d355583c568d4f78966b293ea880a40036da9cc509e1c7a8373297533a26bcb91ecf207718decf329c545f13c83aacdb508aea18d9c462a2e649fde7 SHA512 (FreeBSD-11.0-BETA4-powerpc-powerpc64-disc1.iso.xz) = 4de482d1ba5b099e69851c117a78c58e568bdf93866ce7ab4c84fc7796ac6d369e0cf0b74bd8c37cec1162ddf09a2cbed798ddd5931da4c338603b5c7fc72851 SHA512 (FreeBSD-11.0-BETA4-powerpc-powerpc64-memstick.img) = dad28e8b1fc86407b264a5e4ebac35bd26e2116f5b8338a274c1fc9338696a4fd0e19edc517b0ce5dae2b8a4ec2b75371d6ae3e7e7ff2bb8515df9150f98cc23 SHA512 (FreeBSD-11.0-BETA4-powerpc-powerpc64-memstick.img.xz) = b896ea28edc09d64708ec655e138361e64327bbdda78d3ea3d1ed2a67d52a126bf81c38738be9662ce8e0cd6f9533b441f55c80ac2593fe4cc407d95f819b08a SHA512 (FreeBSD-11.0-BETA4-powerpc-powerpc64-mini-memstick.img) = 9f9aa35481894a90a4693ca6666c91f3d58fee6281407993c516f3f50b2ec21992c20e89f414dfbb08e4e0f6a12620a44380784a11e8dc19ec6bea3665ff80ab SHA512 (FreeBSD-11.0-BETA4-powerpc-powerpc64-mini-memstick.img.xz) = e5f0b9c8318969d67039b313a5ef56ea8022ecf8c99a0cf5b952ec5d2c35ce0ddbdd468a5c826447ceed7a4b8d60b263f1a35c8e7581b159cfcad5140bfd0d17 SHA256 (FreeBSD-11.0-BETA4-powerpc-powerpc64-bootonly.iso) = 65cda0951fde8479670db2d580c9db959b6530435c6fd845f3b5f4283208b3c7 SHA256 (FreeBSD-11.0-BETA4-powerpc-powerpc64-bootonly.iso.xz) = 1908a669e0a9ca3b8e2f38af9eea48a9e5db35e93830287ec0ead6c42be2f897 SHA256 (FreeBSD-11.0-BETA4-powerpc-powerpc64-disc1.iso) = 047ef0d628d810b1f2814b778a89c75f0e5384b659396bf609cb315a92f5a718 SHA256 (FreeBSD-11.0-BETA4-powerpc-powerpc64-disc1.iso.xz) = 6716baa161fd249d6849076c5ad2a32c2f8bee30c171cbcd2f1d9fd2b0fe3e91 SHA256 (FreeBSD-11.0-BETA4-powerpc-powerpc64-memstick.img) = 90ae5c97c9cfd1ce8413ac107673d4cb2614aecb7a73b0e25a074c52fe6d771b SHA256 (FreeBSD-11.0-BETA4-powerpc-powerpc64-memstick.img.xz) = 8bc938a429b7657e84e589a5251cec058c5bf667934498a49ca438928a2ba830 SHA256 (FreeBSD-11.0-BETA4-powerpc-powerpc64-mini-memstick.img) = c75c28ebe82d00eaccdbbd9c33a1b52aac41368b5fdd0130939c2bc5c3c57f3f SHA256 (FreeBSD-11.0-BETA4-powerpc-powerpc64-mini-memstick.img.xz) = 1694e3bdfd0cd7dc74dde6de80578a8a9ffbcd58eb7890accad0c3edf09f7bc9 o 11.0-BETA4 sparc64 GENERIC: SHA512 (FreeBSD-11.0-BETA4-sparc64-bootonly.iso) = 0a71a836d0f87fc883f250b06d82abd36c06578ea87a1e123f3c42cc2fbc47eb0078b17f8e37710d1af76b36be8aaab686e3673ecfbc8bf73911e943825195cf SHA512 (FreeBSD-11.0-BETA4-sparc64-bootonly.iso.xz) = e16cbc7bc045d34b92fa5f8d84ce909ab7c49ffd43ef18fb935ed72c01b9e5a47b31695c9055683c93ef4c4b401546130d52378942ced450242f3e1b5e6fd347 SHA512 (FreeBSD-11.0-BETA4-sparc64-disc1.iso) = 2d131822be404e4354e0a9d5af7663c7660a46f13111e59983d4d0f53ec4518d5ea08080ce323a686ae370178a8dee80d86243b4baf1f8ffeccd05a533e9b580 SHA512 (FreeBSD-11.0-BETA4-sparc64-disc1.iso.xz) = ac7cc94e79b07c96140726167113df30640e7569423911fff92d8e32056bcd2c2a96b7e854bebac0e65fdc4888937be2892ca58cd4f698dd5b7339e1c7155867 SHA256 (FreeBSD-11.0-BETA4-sparc64-bootonly.iso) = 2ab751a8a9d7a5f7f4cb37e92926e834f73ba54e2717a9644d0627ac61648e6c SHA256 (FreeBSD-11.0-BETA4-sparc64-bootonly.iso.xz) = 5bf4a492b28310ef24ef27b090ca2aea00c689eb625d6e98a4d6a445a1717627 SHA256 (FreeBSD-11.0-BETA4-sparc64-disc1.iso) = 2e4675efb85530457db17f20ae072dc572cec70f72f1c6acdcc577f46f4f1e5f SHA256 (FreeBSD-11.0-BETA4-sparc64-disc1.iso.xz) = af5b68a4579084e3c124b9201106aadd7379842da316d04f912500d592c919e6 o 11.0-BETA4 armv6 BANANAPI: SHA512 (FreeBSD-11.0-BETA4-arm-armv6-BANANAPI.img.xz) = 8ededd5059062a836158c89f0076b8273f3137c1ac6729d841e88687c03b50c7a3ca2b09fbbfd9adb1574b360e2bb98d42518fe956332f8a3ab721c26fd830da SHA256 (FreeBSD-11.0-BETA4-arm-armv6-BANANAPI.img.xz) = de312046b3b8900b9df444467392efaf2f54dc9492581ac114e6e0ac41dcf0b0 o 11.0-BETA4 armv6 BEAGLEBONE: SHA512 (FreeBSD-11.0-BETA4-arm-armv6-BEAGLEBONE.img.xz) = 960b0ea73dee79411b4ec1727e9ef7f3ffca21791574156892a565054ca943e287e19764b33d39eb587559e9ce386ba9cb741884f58010fef3748cca21d0929b SHA256 (FreeBSD-11.0-BETA4-arm-armv6-BEAGLEBONE.img.xz) = 1d3f4d06e0ff5cb16a0b4407cd46813745c47136ef55e1498c3e04bf13c7a127 o 11.0-BETA4 armv6 CUBIEBOARD: SHA512 (FreeBSD-11.0-BETA4-arm-armv6-CUBIEBOARD.img.xz) = 31d51d1c936c626c8c61b01e16b2af64de797eedf37aa4108b165a183760a6a3ad3a225799faa22284bd29edea8a3e8dca865bcdb7b4010975da0a8f4bb8f84e SHA256 (FreeBSD-11.0-BETA4-arm-armv6-CUBIEBOARD.img.xz) = d1b06ad1ae0560f9863bf2df546c626f86b873415cc1eec16f5c3c83113a6221 o 11.0-BETA4 armv6 CUBIEBOARD2: SHA512 (FreeBSD-11.0-BETA4-arm-armv6-CUBIEBOARD2.img.xz) = a36895d975d9ae0d6dddfa4d7c0ce16646f78eef1f50a3ff56cd79603f1e78a7735e4662e9b8a50d9308cc5b07daad2ae3aa393d50a13c5812599ed57402cfeb SHA256 (FreeBSD-11.0-BETA4-arm-armv6-CUBIEBOARD2.img.xz) = 6ebfc32a340692490c3e5da8af8d73b66942df5bc0dda7818f68f4c3fea05f73 o 11.0-BETA4 armv6 CUBOX-HUMMINGBOARD: SHA512 (FreeBSD-11.0-BETA4-arm-armv6-CUBOX-HUMMINGBOARD.img.xz) = 92b7b8979b230b6dbc00166e7f3ff5a01356631dd7e0f8f39341abd08bec0cc5bc18f4badb3ee95b9423242e20f6d3ec87de183d780999c90871cf32cc0a5954 SHA256 (FreeBSD-11.0-BETA4-arm-armv6-CUBOX-HUMMINGBOARD.img.xz) = 13066ecc0b33acd9cb3acdce5248cfdca5f8fa49de9b038c767a12434489de2c o 11.0-BETA4 armv6 GUMSTIX: SHA512 (FreeBSD-11.0-BETA4-arm-armv6-GUMSTIX.img.xz) = eb0abc16daa76aafa6abb6526eb2022fa7d04008f6c090b9a6c66729637377e8113963257fb9564e4f5032d5f5eb698fe0f22479b8fa879dc5ae062f1b70267c SHA256 (FreeBSD-11.0-BETA4-arm-armv6-GUMSTIX.img.xz) = d9b79b5866015283437c47497e3475c43c42260f87dbe40fa9c84f379a37ed58 o 11.0-BETA4 armv6 RPI-B: SHA512 (FreeBSD-11.0-BETA4-arm-armv6-RPI-B.img.xz) = 4b0a36559bf6e28c706e0313dee9defddfb5a14379a8da57358bce69b7d7e0fdbf7290cbae6b8aab33848d6e9f5b7d3bf600122fdef4368d3ba820eea228c659 SHA256 (FreeBSD-11.0-BETA4-arm-armv6-RPI-B.img.xz) = c9b9ad0ba815469f896e83f1947fc2202e3e79a9da4f6d5f48c403264ff90ab5 o 11.0-BETA4 armv6 RPI2: SHA512 (FreeBSD-11.0-BETA4-arm-armv6-RPI2.img.xz) = f2668dad503de87aa6e69e3e98cd6d4f2aaba263c89e219252ec771708fce88314ad4a2103a85197b0bbd13f4545b1c7270644db91f0361a81f41fb95d5bfe4c SHA256 (FreeBSD-11.0-BETA4-arm-armv6-RPI2.img.xz) = 9d8a121bf2fb70fd89deca121981357d8667d4798f2a4b16d13847df9a99e7b9 o 11.0-BETA4 armv6 PANDABOARD: SHA512 (FreeBSD-11.0-BETA4-arm-armv6-PANDABOARD.img.xz) = 3fb81ca010685661a15363ed64c9ae0676b291c86679b83b3106d044f935ffc9f382e3d8a93bf35642fd3ca52013beee18b8b53700967740731ca969628b3bab SHA256 (FreeBSD-11.0-BETA4-arm-armv6-PANDABOARD.img.xz) = b881df2ecfb5383abd5e1dabf6992fffd5f8ee1990737ba3c1c2ba225b1ee248 o 11.0-BETA4 armv6 WANDBOARD: SHA512 (FreeBSD-11.0-BETA4-arm-armv6-WANDBOARD.img.xz) = 73b40b68e82004fbcf2975eaa58226bf6f21faf2ea8816b1f50d5d098c57b41002a9dccf055f7ab0789b2bba10dd1106b7d1850fde105a316cf9b2fc1a5b8696 SHA256 (FreeBSD-11.0-BETA4-arm-armv6-WANDBOARD.img.xz) = 9b40e73bb0841692dc99b044d8a66403ba9bdad464afc01a96362838083ebf70 o 11.0-BETA4 aarch64 GENERIC: SHA512 (FreeBSD-11.0-BETA4-arm64-aarch64-memstick.img) = 56c1ab1ce78987f53784038888ef306db4b0fd6640ef7488d7dcd870cca5764d7c15bcc187babbe586973e7e75e3328f2be9a35de24bfe0a00bd4e2d9ec3937e SHA512 (FreeBSD-11.0-BETA4-arm64-aarch64-memstick.img.xz) = 6d841d7a31d99b5d6ce514129d98130e0ee18ec66a51deb44eb043dcc3d79853ed3b9016dd038a429ebad6483fb91afb4f37370ff60a354af9c7e3e0bfdbc140 SHA512 (FreeBSD-11.0-BETA4-arm64-aarch64-mini-memstick.img) = a92ae3ec63a3efbb0347dc4f283b42df0f88f541e8df6f2a2842e8d0a2ecb6b3adaa4f775bdf4d8bd720562a48ace146ccbb1994fb95a2dcd0800d24cce23327 SHA512 (FreeBSD-11.0-BETA4-arm64-aarch64-mini-memstick.img.xz) = a2fc8c61195dbe991d1279a3f2591a214df083e0590fbefbf62c25efd7323064bc9022cb250206b6c45b19bbdc991353ddb7b93f879a07947ebaae60989e1829 SHA256 (FreeBSD-11.0-BETA4-arm64-aarch64-memstick.img) = d1a47add5710c12721d7a50f623cb8d6e495bdacdf56740eaeb6eee9b493be98 SHA256 (FreeBSD-11.0-BETA4-arm64-aarch64-memstick.img.xz) = 69f3f1388a08e1a1d30d739c50d0afcf615daa28315fbb8856d3951671aada4c SHA256 (FreeBSD-11.0-BETA4-arm64-aarch64-mini-memstick.img) = d884e16bcf4a8906ea98ee9c89732526ce072f89530e263b01a55926c6c37840 SHA256 (FreeBSD-11.0-BETA4-arm64-aarch64-mini-memstick.img.xz) = 06e1964b034f44004f930e1e4846c768cc5f7cba57142bfe87bc1c7f59582ff5 == VM IMAGE CHECKSUMS == o 11.0-BETA4 amd64: SHA512 (FreeBSD-11.0-BETA4-amd64.qcow2.xz) = 6abcfa0a575710944221c61e029c6911dda7c2e0fe9952767feb11a3347f68cf3886c66a4d940dbc29a35104e7f6f08b828f09e85d408b5b6e3dd72290c054fa SHA512 (FreeBSD-11.0-BETA4-amd64.raw.xz) = 2f9eec74f0d2b9afa119c26e3b0f8d1677fbe95549dfe303d3604d143e5069796cffc05e4e3c9544a683d049564bc1ec3a3856f74f57e9846224350776669f36 SHA512 (FreeBSD-11.0-BETA4-amd64.vhd.xz) = 042e4092329195171fa2b83a9f9a51628498efe9f0bb86c3ca196e3dc16459645d0ef81de1210d2bfacf32e2782c61f949b040dd73cf0f7f0e0e23e37e6c932b SHA512 (FreeBSD-11.0-BETA4-amd64.vmdk.xz) = 4c1c3727cec6640c8e605dfc3b50585f941764b97c8f1f0a8c9542f208e7e0c11a5020fda3b4683933f191e783bd2379839520e873568f912f49a7d93ec16365 SHA256 (FreeBSD-11.0-BETA4-amd64.qcow2.xz) = 8678a75c8030a67c76ecf3c2b0f590c2bfdf6019204536578c9f916a61561ac4 SHA256 (FreeBSD-11.0-BETA4-amd64.raw.xz) = 548388b5bce27ff1049d505626d1adc5e3db3b0ae392f86303f8e6d9aebb87fb SHA256 (FreeBSD-11.0-BETA4-amd64.vhd.xz) = e67238312de65bd5916e701275b57cd2f8a4765b3862cd542f833e0c9a28ae67 SHA256 (FreeBSD-11.0-BETA4-amd64.vmdk.xz) = 279c4ecd8b9859bb9a02705648722b072efba81be87c5b5424a609b9f67e9add o 11.0-BETA4 i386: SHA512 (FreeBSD-11.0-BETA4-i386.qcow2.xz) = 15235ded2c1a774f46a34e8c5e148b4c4e1563dbbf39318faaa19772bbdca3e2d0e1641b2b69a1a406b6c59d57d20de208497e7cf2b39e47a64b1683658757fb SHA512 (FreeBSD-11.0-BETA4-i386.raw.xz) = 1df7efc3eebd5282598b3b5992432f964fb3cae840e37206b003ec8fc749a67439bacf0e65df4c0ae5dd8ac43398ef6c14dd4d96e101fd148773adb94699da5c SHA512 (FreeBSD-11.0-BETA4-i386.vhd.xz) = 73488506f068b9e231e59fd670b7c999f8a0e7bd079db4fc51a12801268318e9e7b11ddb24cc577823020e1799f83f606619cc7a900993864c1a41c56a075aef SHA512 (FreeBSD-11.0-BETA4-i386.vmdk.xz) = 6282da374860b6a19fccc28974caf5d7f54ccb8f33e7a2def5330b33e80b9cdbe4b26f7b2738fffe4abe08c571b62b73aca14b1ba31016f392b3d76ee6e887af SHA256 (FreeBSD-11.0-BETA4-i386.qcow2.xz) = 2c1380abb0ae6ea970519fcc04d9b717c066854b647b626891a8819ae5d07846 SHA256 (FreeBSD-11.0-BETA4-i386.raw.xz) = c025d5bb0c3f915f41639c953b804eb8062983aea98b40d2fa3d2306b71a0c4a SHA256 (FreeBSD-11.0-BETA4-i386.vhd.xz) = 819ccbac8475155357fb41957b25ca8bea9493f13595dc68032d74d29202ffb7 SHA256 (FreeBSD-11.0-BETA4-i386.vmdk.xz) = 4a0f6453551da5a7ed8399b977c1eb21cd85ceca9ab40a9d8f39f589001f2afc o 11.0-BETA4 aarch64: SHA512 (FreeBSD-11.0-BETA4-arm64-aarch64.qcow2.xz) = 5896d5a5b8c4901cd479d7d11ea4152f600766c2b38158136100a6d2dfc8dc5ca241269288d3cd7b93038df5d68b894045aef54b74acc7c52e1384ed5ee29f6f SHA512 (FreeBSD-11.0-BETA4-arm64-aarch64.raw.xz) = 15c42bd7ce1141ec62a8589f6bd044da4ecf0c131b1ce8ded199ac40f5c464c194dc199557f5a8aa6940f9546397b3d9b25e065a0c465c48222ed72ab0d31542 SHA512 (FreeBSD-11.0-BETA4-arm64-aarch64.vhd.xz) = 6839f5d4fd07b10dd6fafa22add63a2b7048d1cc35ec0dd14b212822ed95d75ce8fa7dcdcac8b36654f292f07352cf21efbec58670cf7678f8520381446e57ad SHA512 (FreeBSD-11.0-BETA4-arm64-aarch64.vmdk.xz) = ef3b7442d27cfe54154756a5ccd260d3b5684a10e08cbd771325f2cf7449cd575a0cd63bee0f085a06cda19c18203436ee7801ca076027a1c21ec9505d5f26a8 SHA256 (FreeBSD-11.0-BETA4-arm64-aarch64.qcow2.xz) = 58e420755b398e30e0b85b208899a91f86412e027121a4abd034cb6ce3fdc89b SHA256 (FreeBSD-11.0-BETA4-arm64-aarch64.raw.xz) = 28c4620974f3d15cbd21714ab2bcc9d74edcb6951c79b9ee1dcf8c7a450b84b5 SHA256 (FreeBSD-11.0-BETA4-arm64-aarch64.vhd.xz) = 058ebac2e106e601e9ff2652a7bc3a3fabef8d9b36af1eaa872cc86eacd4997e SHA256 (FreeBSD-11.0-BETA4-arm64-aarch64.vmdk.xz) = 3c96b360f9f0ef70b68f0653290a2a0dae7e42a7c0781469315cfdefd3f8eb6e 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 iQIcBAEBCAAGBQJXplEWAAoJEAMUWKVHj+KT9oYP/ReekHxBWzObrWtQjD2rLE7p UN9PaIH3WxuhxZunW7B5VYyRCuuhGndYb7DdGOwQJrlmD/LpFnvAa3L38oeJ6zWf gr6qjCBEn8GcSazi/257IQgoXdW2aN8VTeEJz2aTZkm9fJ+3HhaTN/r4wGSVx009 uE8EUYVGTfsDPPKNgh5zpgiiL2iG7r6rVePM0EWHWVXvq/pBlA70GuXPXaEl8VN2 2gPHWMc9CYdzecXt9Wutbls4a5HCcmyii895yTVzwTWUebQuAVFiUPwWy6ogVUrr b44UXEXqVJV1yaxy9ks56vbi56Sy6/H/HDM3v8IhXSa4CvBbJD/c1nATltoMvbTl 94elcjOPAOe6REdU3AJJTLEKVULK8kTPJFemRPSpQGTfwPeiU9YcPKmNB9doq1Xv HCrz5T3i0riuOqWRjYbdIwXH8qWD7949gHDxgnRtM4GEjn18u0wnL3aOoeJZopdw kiGswj0CLG92qhHTKeCRfFKJ7v7/s0zpGj9ufSRRuJLgUElsTOb/fyVrxs3V3Hpz fiB8npkQ9S9Bh6WLriqpmtM+sEEOz9zyyk3BI2Rz975v3wyn97VX7+B7F1BMf1Go 1KdkZaaWVyK5k3/osBYmn5r8A7FCSYM6kFwl2L7lAwcpK4GGiJgxYro1lB+GvVIF 2fVW/Ye17ajQKjq5QT9F =WsA8 -----END PGP SIGNATURE-----