From owner-freebsd-current@FreeBSD.ORG Sun Mar 15 10:00:00 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 690896A7 for ; Sun, 15 Mar 2015 10:00:00 +0000 (UTC) Received: from nm23-vm9.access.bullet.mail.gq1.yahoo.com (nm23-vm9.access.bullet.mail.gq1.yahoo.com [216.39.62.70]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2E028A15 for ; Sun, 15 Mar 2015 09:59:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s2048; t=1426413233; bh=ARldOe6DVCypz7ZxBJoWT5MqTocbvU5jzmbYNt2QH2s=; h=Date:From:To:CC:Subject:References:From:Subject; b=bJaAtdNgeKV4llpsFferXEAJk9SRUlXl4hgGIzqax5ECQTRKiGa8XtH/njRMA5I3RHSHl80pf+M1CUxCLkeUdFcQKT55r5BQKIic4LfarcxepcxEyrP0j4s8G0jgF+FCdWTjEvv0ttuPcB+3P8Q3PnPWR44BrbTXNjHoCgUTn2OSO4ECw5+CgoLR43KP+PkEJ0QPpxHWxwQ7URzywt4u/f6i4UjLlacT4hNb1O5bz7Xc1wpkAOPbAFKAuFnCqO4l/nmjcKl8TPSME6fUMwnPboPZae03CazHAAR/zzABQCuth/8GaFqqLmKBAKANgfRZQTLihHOUIdeoiJmwEGg32Q== Received: from [216.39.60.172] by nm23.access.bullet.mail.gq1.yahoo.com with NNFMP; 15 Mar 2015 09:53:53 -0000 Received: from [98.138.104.97] by tm8.access.bullet.mail.gq1.yahoo.com with NNFMP; 15 Mar 2015 09:53:53 -0000 Received: from [127.0.0.1] by smtp117.sbc.mail.ne1.yahoo.com with NNFMP; 15 Mar 2015 09:53:52 -0000 X-Yahoo-Newman-Id: 981488.10076.bm@smtp117.sbc.mail.ne1.yahoo.com Message-ID: <981488.10076.bm@smtp117.sbc.mail.ne1.yahoo.com> Date: Sun, 15 Mar 2015 09:53:52 +0000 (UTC) X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Y2G56DEVM1kuLczPs309pEblcbPFT0FNTW9Li.VXZY_Uhre ujMuGCXWeWjiAyoFS6VCVCPf0a9ZqRyf3_3ybQbDdbeGZWHvK_Oh4mdb9Ft_ oAeWzLswRrQs2CmkoMjh4ojBJ.0UA_NAuX0vMMfiEpv8gMy4vr3qGwqRdFW9 1lkAarIi7G3YdonpyHlrnCc1KVxbz2CYy3lxVCH0RHihUEYGd53OUZRuLZ5f V9oITr2ihNGeWk3sEEEFnRO0vz7HtJY6JAwjZr8tGt2.E0xpoNG3BR9CYK5x KLyj__npAGyqKGZsCmEh1Cncrem_qhDITgNlySVkTEzqYiEM2SxXV_CWo4T5 McpNAsrJOWJz63NsTRv9nujuTNN6o01W20m7Zz4wd9PXqbFodFtHvLp1ICe7 m2xILVwd6SmPmjYCYBf8PZA9bPRf6HWk6OEH1J9jNaBTq5BZ0BxIPNsYJDMT eMy78E767Dwdz_WzbJwo.VrJYphYkoLhZ5mt4xE8AblYYjKPh1mT_3JIJj9Z YiD5Xaha7GIsGRn.Q1Id_AoXxRQ.PCioD3Wrs1JZwlgxRtP1IZbdthX10mkN 1ZeEjyaIJLk0f_2AjdVxgHbgPncTC.A1eFwW50bAq5lmadke_jJb7kA8OicT htSqTNCQfOdUAez1YUmfijdNGiLgdpwyL6ndaUx.DWsq_K1hJNUUcI5cj_vq 5T0ex X-Yahoo-SMTP: Kz_aW1.swBBYof3zAD7.RWzXz9ZAQVDMml1VADsbgPT4Kq79LC0- From: "Thomas Mueller" To: freebsd-current@freebsd.org Subject: Re: make installworld for i386 fails on Kyuafile References: <54EFDFB8.6020404@protected-networks.net> <20150227180746.GP17947@glebius.int.ru> Cc: Michael Butler , freebsd-ports@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 15 Mar 2015 10:00:00 -0000 > On Thu, Feb 26, 2015 at 10:08:40PM -0500, Michael Butler wrote: > M> The recent changes which served to hide "struct ifaddr" have broken > M> net-snmp: > I know and slowly working on that: > https://lists.freebsd.org/pipermail/svn-src-head/2015-February/068674.html > Totus tuus, Glebius. How will users know when this bug is fixed so that net-snmp will build on current? I was snagged on this as a dependency in trying to build print/hplip. Tom From owner-freebsd-current@FreeBSD.ORG Mon Mar 16 18:03:54 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2437EFAB for ; Mon, 16 Mar 2015 18:03:54 +0000 (UTC) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) (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 D0ED8AA7 for ; Mon, 16 Mar 2015 18:03:53 +0000 (UTC) Received: by qcyi15 with SMTP id i15so51327308qcy.0 for ; Mon, 16 Mar 2015 11:03:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:to:date:organization :content-type:mime-version; bh=r15ex2OABMzOtSO9oSkcfFlwS3Y3XwUoucSRbz6unbk=; b=Ry7KeyMRPi5hNbQEp1MQ5RkKU9Xy71dCus2bazRkZ/nDYOBi4Wuu5piljyzpYtZbEf YRku9rGjrjTtEdmouLs+tBmvAJuJ49ad6lypjfbAkntDY2bxTaYt48j2L1Y6q3sXuUk2 W8G5Xe/I2cPOMRwdUciTtE29LbmTNc/TDdX/1JNjQ2at86ekw2XIC3O+WuKTX6czHFln fyWGC89dESZXjnWzX4dXqL+J4MCeSNfoCjUeSMCfwDL3X79I4cqkXtQhj9sU+svqyMvN gXKciDLGBTTEmSdkZjXAYblk9zR3b3e5R1vtOzY1uL4WmUtYwmQZMvW8i066QQsQoEG1 c2Ig== X-Gm-Message-State: ALoCoQlPAdHFdczSrxp4JQgUb8OEUX2JBOnEI9ur0DnHpXjhKjGyIJBqdqUBbPkUABEMhM5RHEfKmP40OJbIaAO4An8MOgSY3MdWIRDGGMuBdDhpewZaHx25aAuzCZQaVebFnGihtqfOMuF5NaKjggQvvMJZrC3CFgjJtt1FbYC+fU8zlwm2C2is0lRI7GIozzp71fbSUJSU X-Received: by 10.140.22.234 with SMTP id 97mr74717549qgn.52.1426529026926; Mon, 16 Mar 2015 11:03:46 -0700 (PDT) Received: from [10.3.0.21] ([63.88.83.66]) by mx.google.com with ESMTPSA id i185sm7873722qhc.49.2015.03.16.11.03.44 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Mar 2015 11:03:46 -0700 (PDT) Message-ID: <1426529019.4766.1.camel@hardenedbsd.org> Subject: sbuf-related panic From: Shawn Webb To: "freebsd-current@freebsd.org" Date: Mon, 16 Mar 2015 14:03:39 -0400 Organization: HardenedBSD Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-IqDlyXAOl2hfP0+Up2Y7" X-Mailer: Evolution 3.12.10-0ubuntu1~14.10.1 Mime-Version: 1.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 16 Mar 2015 18:03:54 -0000 --=-IqDlyXAOl2hfP0+Up2Y7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On amd64, doing a Poudriere run. On r280133: (kgdb) bt #0 doadump (textdump=3DUnhandled dwarf expression opcode 0x93 ) at pcpu.h:219 #1 0xffffffff809726a5 in kern_reboot (howto=3DUnhandled dwarf expression o= pcode 0x93 ) at /usr/src/sys/kern/kern_shutdown.c:448 #2 0xffffffff80972c98 in vpanic (fmt=3D, ap=3D) at /usr/src/sys/kern/kern_shutdown.c:747 #3 0xffffffff80972ac2 in kassert_panic (fmt=3D) at /u= sr/src/sys/kern/kern_shutdown.c:635 #4 0xffffffff809bd5bd in sbuf_delete (s=3D0xfffffe085d468750) at /usr/src/= sys/kern/subr_sbuf.c:103 #5 0xffffffff809669dd in sysctl_kern_proc_args (oidp=3D, arg1=3D, arg2=3D, req=3D0xfff= ffe085d468868) at /usr/src/sys/kern/kern_proc.c:1858 #6 0xffffffff8097e7b4 in sysctl_root_handler_locked (oid=3D0xffffffff81533= 738, arg1=3D0xfffffe085d46893c, arg2=3D1, req=3D0xfffffe085d468868) at /usr= /src/sys/kern/kern_sysctl.c:183 #7 0xffffffff8097e038 in sysctl_root (arg1=3D, arg2= =3D) at /usr/src/sys/kern/kern_sysctl.c:1660 #8 0xffffffff8097e5b2 in userland_sysctl (td=3D, name= =3D0xfffffe085d468930, namelen=3D, old=3D, oldlenp=3D, inkernel=3D= ,=20 new=3D, newlen=3D, retval=3D<= value optimized out>, flags=3D0) at /usr/src/sys/kern/kern_sysctl.c:1764 #9 0xffffffff8097e3e4 in sys___sysctl (td=3D0xfffff802521324b0, uap=3D0xff= fffe085d468a40) at /usr/src/sys/kern/kern_sysctl.c:1690 #10 0xffffffff80da1bca in amd64_syscall (td=3D0xfffff802521324b0, traced=3D= 0) at subr_syscall.c:133 #11 0xffffffff80d7f3cb in Xfast_syscall () at /usr/src/sys/amd64/amd64/exce= ption.S:395 #12 0x000002759e502b7a in ?? () --=-IqDlyXAOl2hfP0+Up2Y7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVBxr/AAoJEGqEZY9SRW7u5asP/0cPVvzOorT27IWKNfPDX2+8 HqsBsEFmZt4BS0kHNFTIecStuN+J/AwsIWIAzAtpAfTnfyS0yYhfwNxNUKUK0fhs deEOd7CUnrq8UVPg+MlpY+h7XzulZOFD/zhja9gwpnfa4kRdJJ6pU2mdVJQmW00q gJ0QRhFrMHE23ebNw4g82m1MCJMLaf3YpstWsY6pVOyjH+OV2K1XNl957mJUvI8w Ga+Jf4gmAbDVMEJBi7Wdf66vArKeZ1quvDVmAG0GDJy2DkXOzMtM/Bmng28WKlBT A9DDT4I+fGfCtB6GvXIkm6uZJICc5I0uuJSYvdvwazt1SMxourwWERw1knv6UYrJ B2MER3aFM7PD7ph6HlzHROANnwUe/vkRc9UnUeOWzmVAslmIc4CK+AMPXwAGpSng o47WlH3Xs/7vtwUNJnlCLm5lduXWbMtk1JqJQIIstaQjIuvQV/6cD9k/vLqPS1LC xVDaFAzU7ZQilbTCgIvnU1bOxBUn+ANU9lYpnVNmXRBSZ3zqniQwZxVrqoLOFNjs 6CeS4TVYTz3U2GZKineVGnLNSSJjrSlhiwdnJZX1sGt9ycxOhaGvK6oBrgHYiusX WcR05HXasOnZoX06QCU0vVYMiaecaL4sBm+6g1OQzeAw5fC23lGagAqDgxH26eq0 z4xmzMaMx/RqzgS6Llde =q1hm -----END PGP SIGNATURE----- --=-IqDlyXAOl2hfP0+Up2Y7-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 16 18:23:44 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94DB9766 for ; Mon, 16 Mar 2015 18:23:44 +0000 (UTC) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 487E3DA4 for ; Mon, 16 Mar 2015 18:23:44 +0000 (UTC) Received: by qgez64 with SMTP id z64so48044312qge.2 for ; Mon, 16 Mar 2015 11:23:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=zj2Dw0UdCt0IXQ7H/aNPH4SfcfZlR6Unv+amJEIJhAo=; b=GcdgIjrB3DkG2L/Cn76DHE9N1ZSwUnU4pKKJasWh9T+5y2rvYu8LcmohsjM8Ma0MPK IUnUpt7d1Wi/fJUIeGxFaHLDEO9W8Ae7tcV6oV3lQNKgx2vo3LSGS1kGN0u/60ypOU2/ BweFolokgu9jdzimZVj9IzJNZo60yDOpBX+plpEXuvCuL+c2pT3fTP4iMCh9B1udK5nH I0hJHPEnUUVWBpFjxqksJAG5yGHKhI7C4hT7vZ3mRHXFKEHKzyvt7QRcxrvCsqItcWI7 ITQ+vaP4NkRSaFl2tbf5nwbqfVdhjylCqfpFhvPhjXyfdRnSyRSMffvjvsZWZuvMcwzc kJTw== X-Received: by 10.140.201.8 with SMTP id w8mr81020431qha.51.1426530223410; Mon, 16 Mar 2015 11:23:43 -0700 (PDT) Received: from [192.168.5.247] (ip-64-134-70-83.public.wayport.net. [64.134.70.83]) by mx.google.com with ESMTPSA id m68sm7106027qge.15.2015.03.16.11.23.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Mar 2015 11:23:42 -0700 (PDT) References: <1426529019.4766.1.camel@hardenedbsd.org> Mime-Version: 1.0 (1.0) In-Reply-To: <1426529019.4766.1.camel@hardenedbsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (12D508) From: Garrett Cooper Subject: Re: sbuf-related panic Date: Mon, 16 Mar 2015 14:23:39 -0400 To: Shawn Webb Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 16 Mar 2015 18:23:44 -0000 > On Mar 16, 2015, at 14:03, Shawn Webb wrote: >=20 > On amd64, doing a Poudriere run. On r280133: >=20 > (kgdb) bt > #0 doadump (textdump=3DUnhandled dwarf expression opcode 0x93 > ) at pcpu.h:219 > #1 0xffffffff809726a5 in kern_reboot (howto=3DUnhandled dwarf expression o= pcode 0x93 > ) at /usr/src/sys/kern/kern_shutdown.c:448 > #2 0xffffffff80972c98 in vpanic (fmt=3D, ap=3D) at /usr/src/sys/kern/kern_shutdown.c:747 > #3 0xffffffff80972ac2 in kassert_panic (fmt=3D) at /= usr/src/sys/kern/kern_shutdown.c:635 > #4 0xffffffff809bd5bd in sbuf_delete (s=3D0xfffffe085d468750) at /usr/src= /sys/kern/subr_sbuf.c:103 > #5 0xffffffff809669dd in sysctl_kern_proc_args (oidp=3D, arg1=3D, arg2=3D, req=3D0xfff= ffe085d468868) at /usr/src/sys/kern/kern_proc.c:1858 > #6 0xffffffff8097e7b4 in sysctl_root_handler_locked (oid=3D0xffffffff8153= 3738, arg1=3D0xfffffe085d46893c, arg2=3D1, req=3D0xfffffe085d468868) at /usr= /src/sys/kern/kern_sysctl.c:183 > #7 0xffffffff8097e038 in sysctl_root (arg1=3D, arg2=3D= ) at /usr/src/sys/kern/kern_sysctl.c:1660 > #8 0xffffffff8097e5b2 in userland_sysctl (td=3D, nam= e=3D0xfffffe085d468930, namelen=3D, old=3D, oldlenp=3D, inkernel=3D,= =20 > new=3D, newlen=3D, retval=3D<= value optimized out>, flags=3D0) at /usr/src/sys/kern/kern_sysctl.c:1764 > #9 0xffffffff8097e3e4 in sys___sysctl (td=3D0xfffff802521324b0, uap=3D0xf= ffffe085d468a40) at /usr/src/sys/kern/kern_sysctl.c:1690 > #10 0xffffffff80da1bca in amd64_syscall (td=3D0xfffff802521324b0, traced=3D= 0) at subr_syscall.c:133 > #11 0xffffffff80d7f3cb in Xfast_syscall () at /usr/src/sys/amd64/amd64/exc= eption.S:395 > #12 0x000002759e502b7a in ?? () Ian's working on a few issues that have been reported to him by jhb, kib, an= d a few others.= From owner-freebsd-current@FreeBSD.ORG Mon Mar 16 18:52:53 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C28C2E2 for ; Mon, 16 Mar 2015 18:52:53 +0000 (UTC) Received: from relay.mailchannels.net (tkt-001-i373.relay.mailchannels.net [174.136.5.175]) by mx1.freebsd.org (Postfix) with ESMTP id 7A856154 for ; Mon, 16 Mar 2015 18:52:51 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp4.ore.mailhop.org (ip-10-33-12-218.us-west-2.compute.internal [10.33.12.218]) by relay.mailchannels.net (Postfix) with ESMTPA id 4510560385; Mon, 16 Mar 2015 18:52:48 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp4.ore.mailhop.org (smtp4.ore.mailhop.org [10.21.145.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.8); Mon, 16 Mar 2015 18:52:49 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: duocircle|x-authuser|hippie X-MailChannels-Auth-Id: duocircle X-MC-Loop-Signature: 1426531969357:3506624996 X-MC-Ingress-Time: 1426531969357 Received: from c-73-34-117-227.hsd1.co.comcast.net ([73.34.117.227] helo=ilsoft.org) by smtp4.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YXa83-0007Dr-80; Mon, 16 Mar 2015 18:52:43 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t2GIqd10023729; Mon, 16 Mar 2015 12:52:39 -0600 (MDT) (envelope-from ian@freebsd.org) X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX1++TRiIe+7s9HSC+1bWNjSi Message-ID: <1426531959.95554.11.camel@freebsd.org> Subject: Re: sbuf-related panic From: Ian Lepore To: Shawn Webb Date: Mon, 16 Mar 2015 12:52:39 -0600 In-Reply-To: <1426529019.4766.1.camel@hardenedbsd.org> References: <1426529019.4766.1.camel@hardenedbsd.org> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-AuthUser: hippie Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 16 Mar 2015 18:52:53 -0000 On Mon, 2015-03-16 at 14:03 -0400, Shawn Webb wrote: > On amd64, doing a Poudriere run. On r280133: > > (kgdb) bt > #0 doadump (textdump=Unhandled dwarf expression opcode 0x93 > ) at pcpu.h:219 > #1 0xffffffff809726a5 in kern_reboot (howto=Unhandled dwarf expression opcode 0x93 > ) at /usr/src/sys/kern/kern_shutdown.c:448 > #2 0xffffffff80972c98 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:747 > #3 0xffffffff80972ac2 in kassert_panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:635 > #4 0xffffffff809bd5bd in sbuf_delete (s=0xfffffe085d468750) at /usr/src/sys/kern/subr_sbuf.c:103 > #5 0xffffffff809669dd in sysctl_kern_proc_args (oidp=, arg1=, arg2=, req=0xfffffe085d468868) at /usr/src/sys/kern/kern_proc.c:1858 > #6 0xffffffff8097e7b4 in sysctl_root_handler_locked (oid=0xffffffff81533738, arg1=0xfffffe085d46893c, arg2=1, req=0xfffffe085d468868) at /usr/src/sys/kern/kern_sysctl.c:183 > #7 0xffffffff8097e038 in sysctl_root (arg1=, arg2=) at /usr/src/sys/kern/kern_sysctl.c:1660 > #8 0xffffffff8097e5b2 in userland_sysctl (td=, name=0xfffffe085d468930, namelen=, old=, oldlenp=, inkernel=, > new=, newlen=, retval=, flags=0) at /usr/src/sys/kern/kern_sysctl.c:1764 > #9 0xffffffff8097e3e4 in sys___sysctl (td=0xfffff802521324b0, uap=0xfffffe085d468a40) at /usr/src/sys/kern/kern_sysctl.c:1690 > #10 0xffffffff80da1bca in amd64_syscall (td=0xfffff802521324b0, traced=0) at subr_syscall.c:133 > #11 0xffffffff80d7f3cb in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:395 > #12 0x000002759e502b7a in ?? () That one should be fixed in r280149, sorry about that. For some reason I never hit the triggering condition in testing, but it seems that just about everyone else in the world did. :/ There are a couple locking-related fixes still needed which might trigger a witness warning, they should be fixed soon as well. -- Ian From owner-freebsd-current@FreeBSD.ORG Tue Mar 17 01:37:49 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D5C435F6 for ; Tue, 17 Mar 2015 01:37:49 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id B6B0B7C5 for ; Tue, 17 Mar 2015 01:37:49 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 6D2E2194C for ; Tue, 17 Mar 2015 01:37:49 +0000 (UTC) Date: Tue, 17 Mar 2015 01:37:49 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1889957864.12.1426556269286.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD-tests2 #851 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 17 Mar 2015 01:37:50 -0000 See ------------------------------------------ [...truncated 1235 lines...] lib/libc/regex/regex_test:backref -> passed [2.167s] lib/libc/regex/regex_test:basic -> passed [0.554s] lib/libc/regex/regex_test:bracket -> passed [0.276s] lib/libc/regex/regex_test:c_comments -> passed [0.159s] lib/libc/regex/regex_test:complex -> passed [0.124s] lib/libc/regex/regex_test:error -> passed [0.133s] lib/libc/regex/regex_test:meta -> passed [0.120s] lib/libc/regex/regex_test:nospec -> passed [0.151s] lib/libc/regex/regex_test:paren -> passed [0.148s] lib/libc/regex/regex_test:regress -> passed [0.167s] lib/libc/regex/regex_test:repet_bounded -> passed [0.170s] lib/libc/regex/regex_test:repet_multi -> passed [0.122s] lib/libc/regex/regex_test:repet_ordinary -> passed [0.134s] lib/libc/regex/regex_test:startend -> passed [0.115s] lib/libc/regex/regex_test:subexp -> passed [0.135s] lib/libc/regex/regex_test:subtle -> passed [0.228s] lib/libc/regex/regex_test:word_bound -> passed [0.153s] lib/libc/regex/regex_test:zero -> passed [0.132s] lib/libc/stdio/fmemopen2_test:test_append_binary_pos -> passed [0.014s] lib/libc/stdio/fmemopen2_test:test_autoalloc -> passed [0.015s] lib/libc/stdio/fmemopen2_test:test_binary -> passed [0.015s] lib/libc/stdio/fmemopen2_test:test_data_length -> passed [0.015s] lib/libc/stdio/fmemopen2_test:test_preexisting -> passed [0.015s] lib/libc/stdio/fmemopen2_test:test_size_0 -> passed [0.015s] lib/libc/stdio/clearerr_test:clearerr_basic -> passed [0.016s] lib/libc/stdio/clearerr_test:clearerr_err -> passed [0.015s] lib/libc/stdio/fflush_test:fflush_err -> expected_failure: the EOF invariant fails on FreeBSD; this is new: /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/stdio/t_fflush.c:70: Expected true value in fflush(f) == EOF [0.018s] lib/libc/stdio/fflush_test:fflush_seek -> passed [0.018s] lib/libc/stdio/fflush_test:fpurge_err -> passed [0.018s] lib/libc/stdio/fmemopen_test:test00 -> passed [0.015s] lib/libc/stdio/fmemopen_test:test01 -> passed [0.016s] lib/libc/stdio/fmemopen_test:test02 -> passed [0.015s] lib/libc/stdio/fmemopen_test:test03 -> passed [0.015s] lib/libc/stdio/fmemopen_test:test04 -> passed [0.016s] lib/libc/stdio/fmemopen_test:test05 -> passed [0.014s] lib/libc/stdio/fmemopen_test:test06 -> passed [0.015s] lib/libc/stdio/fmemopen_test:test07 -> passed [0.015s] lib/libc/stdio/fmemopen_test:test08 -> passed [0.015s] lib/libc/stdio/fmemopen_test:test09 -> passed [0.016s] lib/libc/stdio/fmemopen_test:test10 -> passed [0.016s] lib/libc/stdio/fmemopen_test:test11 -> passed [0.016s] lib/libc/stdio/fmemopen_test:test13 -> passed [0.014s] lib/libc/stdio/fmemopen_test:test14 -> passed [0.014s] lib/libc/stdio/fopen_test:fdopen_close -> passed [0.019s] lib/libc/stdio/fopen_test:fdopen_err -> passed [0.019s] lib/libc/stdio/fopen_test:fdopen_seek -> passed [0.019s] lib/libc/stdio/fopen_test:fopen_append -> passed [0.020s] lib/libc/stdio/fopen_test:fopen_err -> passed [0.019s] lib/libc/stdio/fopen_test:fopen_mode -> passed [0.019s] lib/libc/stdio/fopen_test:fopen_perm -> passed [0.015s] lib/libc/stdio/fopen_test:fopen_seek -> passed [0.018s] lib/libc/stdio/fopen_test:freopen_std -> passed [0.020s] lib/libc/stdio/fputc_test:fputc_basic -> passed [0.019s] lib/libc/stdio/fputc_test:fputc_err -> passed [0.018s] lib/libc/stdio/fputc_test:putc_basic -> passed [0.020s] lib/libc/stdio/fputc_test:putc_err -> passed [0.019s] lib/libc/stdio/fputc_test:putc_unlocked_basic -> passed [0.020s] lib/libc/stdio/fputc_test:putc_unlocked_err -> passed [0.019s] lib/libc/stdio/mktemp_test:mktemp_not_exist -> passed [0.015s] lib/libc/stdio/popen_test:popen_zeropad -> passed [0.969s] lib/libc/stdio/printf_test:snprintf_c99 -> passed [0.017s] lib/libc/stdio/printf_test:snprintf_dotzero -> passed [0.015s] lib/libc/stdio/printf_test:snprintf_float -> passed [0.089s] lib/libc/stdio/printf_test:snprintf_posarg -> passed [0.016s] lib/libc/stdio/printf_test:snprintf_posarg_error -> expected_failure: some non-NetBSD platforms including FreeBSD don't validate negative size; testcase blows up with SIGSEGV [0.925s] lib/libc/stdio/printf_test:snprintf_posarg_width -> passed [0.016s] lib/libc/stdio/printf_test:sprintf_zeropad -> passed [0.013s] lib/libc/stdio/scanf_test:sscanf_neghex -> passed [0.014s] lib/libc/stdio/scanf_test:sscanf_whitespace -> expected_failure: fails on FreeBSD and some variants of Linux: /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/stdio/t_scanf.c:74: c == 'z' not met [0.015s] lib/libc/stdlib/abs_test:abs_basic -> passed [0.015s] lib/libc/stdlib/abs_test:imaxabs_basic -> passed [0.015s] lib/libc/stdlib/abs_test:labs_basic -> passed [0.014s] lib/libc/stdlib/abs_test:llabs_basic -> passed [0.014s] lib/libc/stdlib/atoi_test:atof_strtod -> passed [0.013s] lib/libc/stdlib/atoi_test:atoi_strtol -> passed [0.014s] lib/libc/stdlib/atoi_test:atol_strtol -> passed [0.015s] lib/libc/stdlib/atoi_test:atoll_strtoll -> passed [0.015s] lib/libc/stdlib/div_test:div_basic -> passed [0.014s] lib/libc/stdlib/div_test:ldiv_basic -> passed [0.014s] lib/libc/stdlib/div_test:lldiv_basic -> passed [0.014s] lib/libc/stdlib/getenv_test:clearenv_basic -> passed [0.024s] lib/libc/stdlib/getenv_test:getenv_basic -> passed [0.016s] lib/libc/stdlib/getenv_test:putenv_basic -> passed [0.015s] lib/libc/stdlib/getenv_test:setenv_basic -> expected_failure: FreeBSD does not validate the second argument to setenv(3); see bin/189805 [2.356s] lib/libc/stdlib/getenv_test:setenv_mixed -> passed [0.016s] lib/libc/stdlib/exit_test:exit_atexit -> passed [0.015s] lib/libc/stdlib/exit_test:exit_basic -> passed [0.015s] lib/libc/stdlib/exit_test:exit_status -> passed [0.021s] lib/libc/stdlib/exit_test:exit_tmpfile -> passed [0.016s] lib/libc/stdlib/hsearch_test:hsearch_duplicate -> passed [0.014s] lib/libc/stdlib/hsearch_test:hsearch_nonexistent -> passed [0.014s] lib/libc/stdlib/hsearch_test:hsearch_two -> passed [0.013s] lib/libc/stdlib/posix_memalign_test:posix_memalign_basic -> passed [0.014s] lib/libc/stdlib/random_test:random_same -> passed [0.015s] lib/libc/stdlib/strtod_test:strtod_basic -> passed [0.015s] lib/libc/stdlib/strtod_test:strtod_gherman_bug -> passed [0.015s] lib/libc/stdlib/strtod_test:strtod_hex -> passed [0.015s] lib/libc/stdlib/strtod_test:strtod_inf -> passed [0.015s] lib/libc/stdlib/strtod_test:strtod_nan -> passed [0.015s] lib/libc/stdlib/strtod_test:strtod_round -> passed [0.015s] lib/libc/stdlib/strtod_test:strtod_underflow -> passed [0.016s] lib/libc/stdlib/strtod_test:strtof_inf -> passed [0.015s] lib/libc/stdlib/strtod_test:strtof_nan -> passed [0.015s] lib/libc/stdlib/strtod_test:strtold_inf -> passed [0.015s] lib/libc/stdlib/strtod_test:strtold_nan -> passed [0.016s] lib/libc/stdlib/strtol_test:strtol_base -> passed [0.014s] lib/libc/stdlib/strtol_test:strtol_case -> passed [0.014s] lib/libc/stdlib/strtol_test:strtol_range -> passed [0.015s] lib/libc/stdlib/strtol_test:strtol_signed -> passed [0.015s] lib/libc/stdlib/system_test:system_basic -> passed [0.031s] lib/libc/stdlib/getopt_test:getopt -> passed [0.610s] lib/libc/stdlib/getopt_test:getopt_long -> passed [0.269s] lib/libc/string/memchr:memchr_basic -> passed [0.015s] lib/libc/string/memchr:memchr_simple -> passed [0.014s] lib/libc/string/memchr:memrchr_simple -> passed [0.016s] lib/libc/string/memcpy:memccpy_simple -> passed [0.015s] lib/libc/string/memcpy:memcpy_basic -> passed [0.187s] lib/libc/string/memcpy:memcpy_return -> passed [0.015s] lib/libc/string/memmem:memmem_basic -> passed [0.015s] lib/libc/string/memset:memset_array -> passed [0.014s] lib/libc/string/memset:memset_basic -> passed [0.014s] lib/libc/string/memset:memset_nonzero -> passed [0.015s] lib/libc/string/memset:memset_return -> passed [0.014s] lib/libc/string/memset:memset_struct -> passed [0.014s] lib/libc/string/strcat:strcat_basic -> passed [0.023s] lib/libc/string/strcat:strncat_simple -> passed [0.014s] lib/libc/string/strchr:strchr_basic -> passed [0.014s] lib/libc/string/strcmp:strcmp_basic -> passed [0.015s] lib/libc/string/strcmp:strcmp_simple -> passed [0.015s] lib/libc/string/strcpy:strcpy_basic -> passed [0.014s] lib/libc/string/strcspn:strcspn -> passed [0.014s] lib/libc/string/strerror:strerror_basic -> passed [0.015s] lib/libc/string/strerror:strerror_err -> passed [0.014s] lib/libc/string/strerror:strerror_r_basic -> passed [0.014s] lib/libc/string/strerror:strerror_r_err -> passed [0.014s] lib/libc/string/strlen:strlen_basic -> passed [0.015s] lib/libc/string/strlen:strlen_huge -> passed [0.033s] lib/libc/string/strlen:strnlen_basic -> passed [0.015s] lib/libc/string/strpbrk:strpbrk -> passed [0.015s] lib/libc/string/strrchr:strrchr_basic -> passed [0.015s] lib/libc/string/strspn:strspn -> passed [0.014s] lib/libc/string/swab:swab_basic -> passed [0.015s] lib/libc/sys/access_test:access_access -> passed [0.019s] lib/libc/sys/access_test:access_fault -> passed [0.015s] lib/libc/sys/access_test:access_inval -> passed [0.015s] lib/libc/sys/access_test:access_notdir -> passed [0.014s] lib/libc/sys/access_test:access_notexist -> passed [0.014s] lib/libc/sys/access_test:access_toolong -> passed [0.014s] lib/libc/sys/chroot_test:chroot_basic -> passed [0.021s] lib/libc/sys/chroot_test:chroot_err -> passed [0.015s] lib/libc/sys/chroot_test:chroot_perm -> passed [0.016s] lib/libc/sys/clock_gettime_test:clock_gettime_real -> panic: wrote past end of sbuf (0 >= 0) cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe009746d760 vpanic() at vpanic+0x189/frame 0xfffffe009746d7e0 kassert_panic() at kassert_panic+0x132/frame 0xfffffe009746d850 sbuf_set_drain() at sbuf_set_drain+0x28/frame 0xfffffe009746d880 sbuf_new_for_sysctl() at sbuf_new_for_sysctl+0x29/frame 0xfffffe009746d8a0 sysctl_kern_timecounter_choice() at sysctl_kern_timecounter_choice+0x18/frame 0xfffffe009746d900 sysctl_root_handler_locked() at sysctl_root_handler_locked+0x94/frame 0xfffffe009746d940 sysctl_root() at sysctl_root+0x188/frame 0xfffffe009746d990 userland_sysctl() at userland_sysctl+0x192/frame 0xfffffe009746da30 sys___sysctl() at sys___sysctl+0x74/frame 0xfffffe009746dae0 amd64_syscall() at amd64_syscall+0x27f/frame 0xfffffe009746dbf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe009746dbf0 --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x800b77b0a, rsp = 0x7fffffffa938, rbp = 0x7fffffffa970 --- KDB: enter: panic [ thread pid 8183 tid 100056 ] Stopped at kdb_enter+0x3e: movq $0,kdb_why db> Traceback (most recent call last): File "/vm/freebsd-ci/scripts/test/run-tests.py", line 152, in main(sys.argv) File "/vm/freebsd-ci/scripts/test/run-tests.py", line 80, in main runTest() File "/vm/freebsd-ci/scripts/test/run-tests.py", line 124, in runTest child2.expect(prompt, timeout=7200) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1451, in expect timeout, searchwindowsize) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1466, in expect_list timeout, searchwindowsize) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1568, in expect_loop raise TIMEOUT(str(err) + '\n' + str(self)) pexpect.TIMEOUT: Timeout exceeded. version: 3.3 command: /usr/sbin/bhyve args: [u'/usr/sbin/bhyve', u'-c', u'2', u'-m', u'2G', u'-AI', u'-H', u'-P', u'-g', u'0', u'-s', u'0:0,hostbridge', u'-s', u'1:0,lpc', u'-s', u'2:0,virtio-net,tap0,mac=58:9c:fc:00:00:2e', u'-s', u'3:0,ahci-hd,/net/jenkins-10.freebsd.org/builds/Build-UFS-image/image/FreeBSD_HEAD/test.img', u'-l', u'com1,stdio', u'vm_test'] searcher: buffer (last 100 chars): 'ter: panic\r\n[ thread pid 8183 tid 100056 ]\r\nStopped at kdb_enter+0x3e: movq $0,kdb_why\r\ndb> ' before (last 100 chars): 'ter: panic\r\n[ thread pid 8183 tid 100056 ]\r\nStopped at kdb_enter+0x3e: movq $0,kdb_why\r\ndb> ' after: match: None match_index: None exitstatus: None flag_eof: False pid: 20385 child_fd: 4 closed: False timeout: 30 delimiter: logfile: ', mode 'w' at 0x800670150> logfile_read: None logfile_send: None maxread: 2000 ignorecase: False searchwindowsize: None delaybeforesend: 0.05 delayafterclose: 0.1 delayafterterminate: 0.1 Build step 'Execute shell' marked build as failure Recording test results ERROR: Publisher hudson.tasks.junit.JUnitResultArchiver aborted due to exception hudson.AbortException: Test reports were found but none of them are new. Did tests run? For example, is 2 days 0 hr old at hudson.tasks.junit.TestResult.parse(TestResult.java:178) at hudson.tasks.junit.TestResult.parse(TestResult.java:146) at hudson.tasks.junit.TestResult.(TestResult.java:122) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:119) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:92) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2688) at hudson.remoting.UserRequest.perform(UserRequest.java:121) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at hudson.remoting.Request$2.run(Request.java:324) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) at ......remote call to havoc.ysv.freebsd.org(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1356) at hudson.remoting.UserResponse.retrieve(UserRequest.java:221) at hudson.remoting.Channel.call(Channel.java:752) at hudson.FilePath.act(FilePath.java:978) at hudson.FilePath.act(FilePath.java:967) at hudson.tasks.junit.JUnitParser.parseResult(JUnitParser.java:89) at hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:120) at hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:137) at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:74) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:761) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:721) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:670) at hudson.model.Run.execute(Run.java:1742) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240) From owner-freebsd-current@FreeBSD.ORG Tue Mar 17 05:56:45 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EB9A4F05 for ; Tue, 17 Mar 2015 05:56:44 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id C3E912DF for ; Tue, 17 Mar 2015 05:56:44 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id DBB7D19C1 for ; Tue, 17 Mar 2015 05:56:44 +0000 (UTC) Date: Tue, 17 Mar 2015 05:56:44 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <93824666.13.1426571804793.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1889957864.12.1426556269286.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1889957864.12.1426556269286.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD-tests2 #852 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 17 Mar 2015 05:56:45 -0000 See ------------------------------------------ [...truncated 2025 lines...] lib/libc/regex/regex_test:backref -> passed [0.096s] lib/libc/regex/regex_test:basic -> passed [0.081s] lib/libc/regex/regex_test:bracket -> passed [0.085s] lib/libc/regex/regex_test:c_comments -> passed [0.196s] lib/libc/regex/regex_test:complex -> passed [0.086s] lib/libc/regex/regex_test:error -> passed [0.080s] lib/libc/regex/regex_test:meta -> passed [0.082s] lib/libc/regex/regex_test:nospec -> passed [0.080s] lib/libc/regex/regex_test:paren -> passed [0.081s] lib/libc/regex/regex_test:regress -> passed [0.084s] lib/libc/regex/regex_test:repet_bounded -> passed [0.094s] lib/libc/regex/regex_test:repet_multi -> passed [0.082s] lib/libc/regex/regex_test:repet_ordinary -> passed [0.081s] lib/libc/regex/regex_test:startend -> passed [0.078s] lib/libc/regex/regex_test:subexp -> passed [0.085s] lib/libc/regex/regex_test:subtle -> passed [0.082s] lib/libc/regex/regex_test:word_bound -> passed [0.080s] lib/libc/regex/regex_test:zero -> passed [0.073s] lib/libc/stdio/fmemopen2_test:test_append_binary_pos -> passed [0.014s] lib/libc/stdio/fmemopen2_test:test_autoalloc -> passed [0.014s] lib/libc/stdio/fmemopen2_test:test_binary -> passed [0.014s] lib/libc/stdio/fmemopen2_test:test_data_length -> passed [0.015s] lib/libc/stdio/fmemopen2_test:test_preexisting -> passed [0.015s] lib/libc/stdio/fmemopen2_test:test_size_0 -> passed [0.015s] lib/libc/stdio/clearerr_test:clearerr_basic -> passed [0.016s] lib/libc/stdio/clearerr_test:clearerr_err -> passed [0.015s] lib/libc/stdio/fflush_test:fflush_err -> expected_failure: the EOF invariant fails on FreeBSD; this is new: /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/stdio/t_fflush.c:70: Expected true value in fflush(f) == EOF [0.019s] lib/libc/stdio/fflush_test:fflush_seek -> passed [0.019s] lib/libc/stdio/fflush_test:fpurge_err -> passed [0.019s] lib/libc/stdio/fmemopen_test:test00 -> passed [0.015s] lib/libc/stdio/fmemopen_test:test01 -> passed [0.015s] lib/libc/stdio/fmemopen_test:test02 -> passed [1.591s] lib/libc/stdio/fmemopen_test:test03 -> passed [0.017s] lib/libc/stdio/fmemopen_test:test04 -> passed [0.014s] lib/libc/stdio/fmemopen_test:test05 -> passed [0.014s] lib/libc/stdio/fmemopen_test:test06 -> passed [0.014s] lib/libc/stdio/fmemopen_test:test07 -> passed [0.015s] lib/libc/stdio/fmemopen_test:test08 -> passed [0.015s] lib/libc/stdio/fmemopen_test:test09 -> passed [0.018s] lib/libc/stdio/fmemopen_test:test10 -> passed [0.018s] lib/libc/stdio/fmemopen_test:test11 -> passed [0.016s] lib/libc/stdio/fmemopen_test:test13 -> passed [0.015s] lib/libc/stdio/fmemopen_test:test14 -> passed [0.016s] lib/libc/stdio/fopen_test:fdopen_close -> passed [0.018s] lib/libc/stdio/fopen_test:fdopen_err -> passed [0.018s] lib/libc/stdio/fopen_test:fdopen_seek -> passed [0.019s] lib/libc/stdio/fopen_test:fopen_append -> passed [0.020s] lib/libc/stdio/fopen_test:fopen_err -> passed [0.018s] lib/libc/stdio/fopen_test:fopen_mode -> passed [0.020s] lib/libc/stdio/fopen_test:fopen_perm -> passed [0.015s] lib/libc/stdio/fopen_test:fopen_seek -> passed [0.019s] lib/libc/stdio/fopen_test:freopen_std -> passed [0.019s] lib/libc/stdio/fputc_test:fputc_basic -> passed [0.019s] lib/libc/stdio/fputc_test:fputc_err -> passed [0.019s] lib/libc/stdio/fputc_test:putc_basic -> passed [0.018s] lib/libc/stdio/fputc_test:putc_err -> passed [0.017s] lib/libc/stdio/fputc_test:putc_unlocked_basic -> passed [0.018s] lib/libc/stdio/fputc_test:putc_unlocked_err -> passed [0.018s] lib/libc/stdio/mktemp_test:mktemp_not_exist -> passed [0.014s] lib/libc/stdio/popen_test:popen_zeropad -> passed [0.050s] lib/libc/stdio/printf_test:snprintf_c99 -> passed [0.015s] lib/libc/stdio/printf_test:snprintf_dotzero -> passed [0.014s] lib/libc/stdio/printf_test:snprintf_float -> passed [0.091s] lib/libc/stdio/printf_test:snprintf_posarg -> passed [0.016s] lib/libc/stdio/printf_test:snprintf_posarg_error -> expected_failure: some non-NetBSD platforms including FreeBSD don't validate negative size; testcase blows up with SIGSEGV [1.458s] lib/libc/stdio/printf_test:snprintf_posarg_width -> passed [0.017s] lib/libc/stdio/printf_test:sprintf_zeropad -> passed [0.015s] lib/libc/stdio/scanf_test:sscanf_neghex -> passed [0.015s] lib/libc/stdio/scanf_test:sscanf_whitespace -> expected_failure: fails on FreeBSD and some variants of Linux: /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/stdio/t_scanf.c:74: c == 'z' not met [0.014s] lib/libc/stdlib/abs_test:abs_basic -> passed [0.014s] lib/libc/stdlib/abs_test:imaxabs_basic -> passed [0.014s] lib/libc/stdlib/abs_test:labs_basic -> passed [0.014s] lib/libc/stdlib/abs_test:llabs_basic -> passed [0.015s] lib/libc/stdlib/atoi_test:atof_strtod -> passed [0.015s] lib/libc/stdlib/atoi_test:atoi_strtol -> passed [0.016s] lib/libc/stdlib/atoi_test:atol_strtol -> passed [0.015s] lib/libc/stdlib/atoi_test:atoll_strtoll -> passed [0.014s] lib/libc/stdlib/div_test:div_basic -> passed [0.014s] lib/libc/stdlib/div_test:ldiv_basic -> passed [0.014s] lib/libc/stdlib/div_test:lldiv_basic -> passed [0.015s] lib/libc/stdlib/getenv_test:clearenv_basic -> passed [0.023s] lib/libc/stdlib/getenv_test:getenv_basic -> passed [0.015s] lib/libc/stdlib/getenv_test:putenv_basic -> passed [0.015s] lib/libc/stdlib/getenv_test:setenv_basic -> expected_failure: FreeBSD does not validate the second argument to setenv(3); see bin/189805 [3.837s] lib/libc/stdlib/getenv_test:setenv_mixed -> passed [0.027s] lib/libc/stdlib/exit_test:exit_atexit -> passed [0.015s] lib/libc/stdlib/exit_test:exit_basic -> passed [0.015s] lib/libc/stdlib/exit_test:exit_status -> passed [0.021s] lib/libc/stdlib/exit_test:exit_tmpfile -> passed [0.016s] lib/libc/stdlib/hsearch_test:hsearch_duplicate -> passed [0.014s] lib/libc/stdlib/hsearch_test:hsearch_nonexistent -> passed [0.014s] lib/libc/stdlib/hsearch_test:hsearch_two -> passed [0.015s] lib/libc/stdlib/posix_memalign_test:posix_memalign_basic -> passed [0.014s] lib/libc/stdlib/random_test:random_same -> passed [0.410s] lib/libc/stdlib/strtod_test:strtod_basic -> passed [0.015s] lib/libc/stdlib/strtod_test:strtod_gherman_bug -> passed [0.016s] lib/libc/stdlib/strtod_test:strtod_hex -> passed [0.015s] lib/libc/stdlib/strtod_test:strtod_inf -> passed [0.015s] lib/libc/stdlib/strtod_test:strtod_nan -> passed [0.014s] lib/libc/stdlib/strtod_test:strtod_round -> passed [0.014s] lib/libc/stdlib/strtod_test:strtod_underflow -> passed [0.015s] lib/libc/stdlib/strtod_test:strtof_inf -> passed [0.014s] lib/libc/stdlib/strtod_test:strtof_nan -> passed [0.016s] lib/libc/stdlib/strtod_test:strtold_inf -> passed [0.016s] lib/libc/stdlib/strtod_test:strtold_nan -> passed [0.015s] lib/libc/stdlib/strtol_test:strtol_base -> passed [0.015s] lib/libc/stdlib/strtol_test:strtol_case -> passed [0.014s] lib/libc/stdlib/strtol_test:strtol_range -> passed [0.015s] lib/libc/stdlib/strtol_test:strtol_signed -> passed [0.015s] lib/libc/stdlib/system_test:system_basic -> passed [0.032s] lib/libc/stdlib/getopt_test:getopt -> passed [0.171s] lib/libc/stdlib/getopt_test:getopt_long -> passed [0.154s] lib/libc/string/memchr:memchr_basic -> passed [0.015s] lib/libc/string/memchr:memchr_simple -> passed [0.015s] lib/libc/string/memchr:memrchr_simple -> passed [0.015s] lib/libc/string/memcpy:memccpy_simple -> passed [0.015s] lib/libc/string/memcpy:memcpy_basic -> passed [0.191s] lib/libc/string/memcpy:memcpy_return -> passed [0.015s] lib/libc/string/memmem:memmem_basic -> passed [0.014s] lib/libc/string/memset:memset_array -> passed [0.014s] lib/libc/string/memset:memset_basic -> passed [0.015s] lib/libc/string/memset:memset_nonzero -> passed [0.015s] lib/libc/string/memset:memset_return -> passed [0.015s] lib/libc/string/memset:memset_struct -> passed [0.015s] lib/libc/string/strcat:strcat_basic -> passed [0.024s] lib/libc/string/strcat:strncat_simple -> passed [0.015s] lib/libc/string/strchr:strchr_basic -> passed [0.014s] lib/libc/string/strcmp:strcmp_basic -> passed [0.014s] lib/libc/string/strcmp:strcmp_simple -> passed [0.015s] lib/libc/string/strcpy:strcpy_basic -> passed [0.014s] lib/libc/string/strcspn:strcspn -> passed [0.015s] lib/libc/string/strerror:strerror_basic -> passed [0.015s] lib/libc/string/strerror:strerror_err -> passed [0.015s] lib/libc/string/strerror:strerror_r_basic -> passed [0.015s] lib/libc/string/strerror:strerror_r_err -> passed [0.014s] lib/libc/string/strlen:strlen_basic -> passed [0.015s] lib/libc/string/strlen:strlen_huge -> passed [0.032s] lib/libc/string/strlen:strnlen_basic -> passed [0.015s] lib/libc/string/strpbrk:strpbrk -> passed [0.015s] lib/libc/string/strrchr:strrchr_basic -> passed [0.014s] lib/libc/string/strspn:strspn -> passed [0.014s] lib/libc/string/swab:swab_basic -> passed [0.014s] lib/libc/sys/access_test:access_access -> passed [0.017s] lib/libc/sys/access_test:access_fault -> passed [0.013s] lib/libc/sys/access_test:access_inval -> passed [0.014s] lib/libc/sys/access_test:access_notdir -> passed [0.014s] lib/libc/sys/access_test:access_notexist -> passed [0.014s] lib/libc/sys/access_test:access_toolong -> passed [0.014s] lib/libc/sys/chroot_test:chroot_basic -> passed [0.018s] lib/libc/sys/chroot_test:chroot_err -> passed [0.014s] lib/libc/sys/chroot_test:chroot_perm -> passed [0.014s] lib/libc/sys/clock_gettime_test:clock_gettime_real -> panic: wrote past end of sbuf (0 >= 0) cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0097440760 vpanic() at vpanic+0x189/frame 0xfffffe00974407e0 kassert_panic() at kassert_panic+0x132/frame 0xfffffe0097440850 sbuf_set_drain() at sbuf_set_drain+0x28/frame 0xfffffe0097440880 sbuf_new_for_sysctl() at sbuf_new_for_sysctl+0x29/frame 0xfffffe00974408a0 sysctl_kern_timecounter_choice() at sysctl_kern_timecounter_choice+0x18/frame 0xfffffe0097440900 sysctl_root_handler_locked() at sysctl_root_handler_locked+0x94/frame 0xfffffe0097440940 sysctl_root() at sysctl_root+0x188/frame 0xfffffe0097440990 userland_sysctl() at userland_sysctl+0x192/frame 0xfffffe0097440a30 sys___sysctl() at sys___sysctl+0x74/frame 0xfffffe0097440ae0 amd64_syscall() at amd64_syscall+0x27f/frame 0xfffffe0097440bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0097440bf0 --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x800b77b0a, rsp = 0x7fffffffa938, rbp = 0x7fffffffa970 --- KDB: enter: panic [ thread pid 34733 tid 100047 ] Stopped at kdb_enter+0x3e: movq $0,kdb_why db> Traceback (most recent call last): File "/vm/freebsd-ci/scripts/test/run-tests.py", line 152, in main(sys.argv) File "/vm/freebsd-ci/scripts/test/run-tests.py", line 80, in main runTest() File "/vm/freebsd-ci/scripts/test/run-tests.py", line 124, in runTest child2.expect(prompt, timeout=7200) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1451, in expect timeout, searchwindowsize) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1466, in expect_list timeout, searchwindowsize) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1568, in expect_loop raise TIMEOUT(str(err) + '\n' + str(self)) pexpect.TIMEOUT: Timeout exceeded. version: 3.3 command: /usr/sbin/bhyve args: [u'/usr/sbin/bhyve', u'-c', u'2', u'-m', u'2G', u'-AI', u'-H', u'-P', u'-g', u'0', u'-s', u'0:0,hostbridge', u'-s', u'1:0,lpc', u'-s', u'2:0,virtio-net,tap0,mac=58:9c:fc:00:00:2e', u'-s', u'3:0,ahci-hd,/net/jenkins-10.freebsd.org/builds/Build-UFS-image/image/FreeBSD_HEAD/test.img', u'-l', u'com1,stdio', u'vm_test'] searcher: buffer (last 100 chars): 'er: panic\r\n[ thread pid 34733 tid 100047 ]\r\nStopped at kdb_enter+0x3e: movq $0,kdb_why\r\ndb> ' before (last 100 chars): 'er: panic\r\n[ thread pid 34733 tid 100047 ]\r\nStopped at kdb_enter+0x3e: movq $0,kdb_why\r\ndb> ' after: match: None match_index: None exitstatus: None flag_eof: False pid: 81787 child_fd: 4 closed: False timeout: 30 delimiter: logfile: ', mode 'w' at 0x800670150> logfile_read: None logfile_send: None maxread: 2000 ignorecase: False searchwindowsize: None delaybeforesend: 0.05 delayafterclose: 0.1 delayafterterminate: 0.1 Build step 'Execute shell' marked build as failure Recording test results ERROR: Publisher hudson.tasks.junit.JUnitResultArchiver aborted due to exception hudson.AbortException: Test reports were found but none of them are new. Did tests run? For example, is 2 days 4 hr old at hudson.tasks.junit.TestResult.parse(TestResult.java:178) at hudson.tasks.junit.TestResult.parse(TestResult.java:146) at hudson.tasks.junit.TestResult.(TestResult.java:122) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:119) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:92) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2688) at hudson.remoting.UserRequest.perform(UserRequest.java:121) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at hudson.remoting.Request$2.run(Request.java:324) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) at ......remote call to havoc.ysv.freebsd.org(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1356) at hudson.remoting.UserResponse.retrieve(UserRequest.java:221) at hudson.remoting.Channel.call(Channel.java:752) at hudson.FilePath.act(FilePath.java:978) at hudson.FilePath.act(FilePath.java:967) at hudson.tasks.junit.JUnitParser.parseResult(JUnitParser.java:89) at hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:120) at hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:137) at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:74) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:761) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:721) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:670) at hudson.model.Run.execute(Run.java:1742) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240) From owner-freebsd-current@FreeBSD.ORG Tue Mar 17 08:46:42 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3F40CF9A for ; Tue, 17 Mar 2015 08:46:42 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 2AAB78E2 for ; Tue, 17 Mar 2015 08:46:42 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 3478A19F3 for ; Tue, 17 Mar 2015 08:46:42 +0000 (UTC) Date: Tue, 17 Mar 2015 08:46:42 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <615255742.14.1426582002157.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <93824666.13.1426571804793.JavaMail.jenkins@jenkins-9.freebsd.org> References: <93824666.13.1426571804793.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD-tests2 #853 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 17 Mar 2015 08:46:42 -0000 See ------------------------------------------ [...truncated 400 lines...] lib/libc/gen/posix_spawn/spawn_test:t_spawn_zero -> passed [0.016s] lib/libc/gen/posix_spawn/spawn_test:t_spawnp_ls -> passed [0.015s] lib/libc/hash/sha2_test:t_sha256 -> passed [0.015s] lib/libc/hash/sha2_test:t_sha384 -> passed [0.014s] lib/libc/hash/sha2_test:t_sha512 -> passed [0.014s] lib/libc/hash/hash_test:md5 -> passed [0.576s] lib/libc/hash/hash_test:sha1 -> passed [0.343s] lib/libc/inet/inet_network_test:inet_addr_basic -> passed [0.015s] lib/libc/inet/inet_network_test:inet_addr_err -> passed [0.015s] lib/libc/inet/inet_network_test:inet_network_basic -> passed [0.014s] lib/libc/inet/inet_network_test:inet_network_err -> passed [0.015s] lib/libc/net/getprotoent_test:endprotoent_rewind -> passed [0.190s] lib/libc/net/getprotoent_test:getprotobyname_basic -> passed [0.017s] lib/libc/net/getprotoent_test:getprotobyname_err -> passed [0.016s] lib/libc/net/getprotoent_test:getprotobynumber_basic -> passed [0.017s] lib/libc/net/getprotoent_test:getprotobynumber_err -> passed [0.065s] lib/libc/net/getprotoent_test:getprotoent_next -> passed [0.017s] lib/libc/net/getprotoent_test:setprotoent_rewind -> passed [0.015s] lib/libc/net/ether_aton_test:tc_ether_aton -> passed [0.014s] lib/libc/net/nsdispatch_test:recurse -> passed [0.201s] lib/libc/net/protoent_test:protoent -> passed [0.079s] lib/libc/net/servent_test:servent -> passed [0.513s] lib/libc/regex/exhaust_test:regcomp_too_big -> passed [0.629s] lib/libc/regex/regex_att_test:basic -> passed [0.028s] lib/libc/regex/regex_att_test:categorization -> passed [0.017s] lib/libc/regex/regex_att_test:forcedassoc -> passed [0.018s] lib/libc/regex/regex_att_test:leftassoc -> expected_failure: The expected and matched groups are mismatched on FreeBSD: 12 checks failed as expected; see output for more details [0.018s] lib/libc/regex/regex_att_test:nullsubexpr -> passed [0.018s] lib/libc/regex/regex_att_test:repetition -> passed [0.019s] lib/libc/regex/regex_att_test:rightassoc -> passed [0.017s] lib/libc/regex/regex_test:anchor -> passed [0.319s] lib/libc/regex/regex_test:backref -> passed [0.189s] lib/libc/regex/regex_test:basic -> passed [0.669s] lib/libc/regex/regex_test:bracket -> passed [0.184s] lib/libc/regex/regex_test:c_comments -> passed [0.169s] lib/libc/regex/regex_test:complex -> passed [0.354s] lib/libc/regex/regex_test:error -> passed [0.217s] lib/libc/regex/regex_test:meta -> passed [0.148s] lib/libc/regex/regex_test:nospec -> passed [0.145s] lib/libc/regex/regex_test:paren -> passed [0.117s] lib/libc/regex/regex_test:regress -> passed [0.125s] lib/libc/regex/regex_test:repet_bounded -> passed [0.153s] lib/libc/regex/regex_test:repet_multi -> passed [0.118s] lib/libc/regex/regex_test:repet_ordinary -> passed [0.128s] lib/libc/regex/regex_test:startend -> passed [0.114s] lib/libc/regex/regex_test:subexp -> passed [0.165s] lib/libc/regex/regex_test:subtle -> passed [0.138s] lib/libc/regex/regex_test:word_bound -> passed [0.118s] lib/libc/regex/regex_test:zero -> passed [0.114s] lib/libc/stdio/fmemopen2_test:test_append_binary_pos -> passed [0.024s] lib/libc/stdio/fmemopen2_test:test_autoalloc -> passed [0.016s] lib/libc/stdio/fmemopen2_test:test_binary -> passed [0.014s] lib/libc/stdio/fmemopen2_test:test_data_length -> passed [0.014s] lib/libc/stdio/fmemopen2_test:test_preexisting -> passed [0.016s] lib/libc/stdio/fmemopen2_test:test_size_0 -> passed [0.014s] lib/libc/stdio/clearerr_test:clearerr_basic -> passed [0.017s] lib/libc/stdio/clearerr_test:clearerr_err -> passed [0.016s] lib/libc/stdio/fflush_test:fflush_err -> expected_failure: the EOF invariant fails on FreeBSD; this is new: /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/stdio/t_fflush.c:70: Expected true value in fflush(f) == EOF [0.058s] lib/libc/stdio/fflush_test:fflush_seek -> passed [0.018s] lib/libc/stdio/fflush_test:fpurge_err -> passed [0.016s] lib/libc/stdio/fmemopen_test:test00 -> passed [0.013s] lib/libc/stdio/fmemopen_test:test01 -> passed [0.013s] lib/libc/stdio/fmemopen_test:test02 -> passed [0.013s] lib/libc/stdio/fmemopen_test:test03 -> passed [0.013s] lib/libc/stdio/fmemopen_test:test04 -> passed [0.013s] lib/libc/stdio/fmemopen_test:test05 -> passed [0.013s] lib/libc/stdio/fmemopen_test:test06 -> passed [0.013s] lib/libc/stdio/fmemopen_test:test07 -> passed [0.013s] lib/libc/stdio/fmemopen_test:test08 -> passed [0.013s] lib/libc/stdio/fmemopen_test:test09 -> passed [0.090s] lib/libc/stdio/fmemopen_test:test10 -> passed [0.018s] lib/libc/stdio/fmemopen_test:test11 -> passed [0.017s] lib/libc/stdio/fmemopen_test:test13 -> passed [0.015s] lib/libc/stdio/fmemopen_test:test14 -> passed [0.014s] lib/libc/stdio/fopen_test:fdopen_close -> passed [0.019s] lib/libc/stdio/fopen_test:fdopen_err -> passed [0.018s] lib/libc/stdio/fopen_test:fdopen_seek -> passed [0.019s] lib/libc/stdio/fopen_test:fopen_append -> passed [0.019s] lib/libc/stdio/fopen_test:fopen_err -> passed [0.017s] lib/libc/stdio/fopen_test:fopen_mode -> passed [0.019s] lib/libc/stdio/fopen_test:fopen_perm -> passed [0.014s] lib/libc/stdio/fopen_test:fopen_seek -> passed [0.019s] lib/libc/stdio/fopen_test:freopen_std -> passed [0.020s] lib/libc/stdio/fputc_test:fputc_basic -> passed [0.019s] lib/libc/stdio/fputc_test:fputc_err -> passed [0.018s] lib/libc/stdio/fputc_test:putc_basic -> passed [0.019s] lib/libc/stdio/fputc_test:putc_err -> passed [0.018s] lib/libc/stdio/fputc_test:putc_unlocked_basic -> passed [0.019s] lib/libc/stdio/fputc_test:putc_unlocked_err -> passed [0.018s] lib/libc/stdio/mktemp_test:mktemp_not_exist -> passed [0.014s] lib/libc/stdio/popen_test:popen_zeropad -> passed [0.389s] lib/libc/stdio/printf_test:snprintf_c99 -> passed [0.016s] lib/libc/stdio/printf_test:snprintf_dotzero -> passed [0.015s] lib/libc/stdio/printf_test:snprintf_float -> passed [0.090s] lib/libc/stdio/printf_test:snprintf_posarg -> passed [0.015s] lib/libc/stdio/printf_test:snprintf_posarg_error -> expected_failure: some non-NetBSD platforms including FreeBSD don't validate negative size; testcase blows up with SIGSEGV [1.324s] lib/libc/stdio/printf_test:snprintf_posarg_width -> passed [0.015s] lib/libc/stdio/printf_test:sprintf_zeropad -> passed [0.012s] lib/libc/stdio/scanf_test:sscanf_neghex -> passed [0.012s] lib/libc/stdio/scanf_test:sscanf_whitespace -> expected_failure: fails on FreeBSD and some variants of Linux: /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/stdio/t_scanf.c:74: c == 'z' not met [0.120s] lib/libc/stdlib/abs_test:abs_basic -> passed [0.013s] lib/libc/stdlib/abs_test:imaxabs_basic -> passed [0.014s] lib/libc/stdlib/abs_test:labs_basic -> passed [0.013s] lib/libc/stdlib/abs_test:llabs_basic -> passed [0.012s] lib/libc/stdlib/atoi_test:atof_strtod -> passed [0.014s] lib/libc/stdlib/atoi_test:atoi_strtol -> passed [0.016s] lib/libc/stdlib/atoi_test:atol_strtol -> passed [0.014s] lib/libc/stdlib/atoi_test:atoll_strtoll -> passed [0.014s] lib/libc/stdlib/div_test:div_basic -> passed [0.202s] lib/libc/stdlib/div_test:ldiv_basic -> passed [0.015s] lib/libc/stdlib/div_test:lldiv_basic -> passed [0.014s] lib/libc/stdlib/getenv_test:clearenv_basic -> passed [0.022s] lib/libc/stdlib/getenv_test:getenv_basic -> passed [0.014s] lib/libc/stdlib/getenv_test:putenv_basic -> passed [0.014s] lib/libc/stdlib/getenv_test:setenv_basic -> expected_failure: FreeBSD does not validate the second argument to setenv(3); see bin/189805 [2.033s] lib/libc/stdlib/getenv_test:setenv_mixed -> passed [0.015s] lib/libc/stdlib/exit_test:exit_atexit -> passed [0.015s] lib/libc/stdlib/exit_test:exit_basic -> passed [0.014s] lib/libc/stdlib/exit_test:exit_status -> passed [0.020s] lib/libc/stdlib/exit_test:exit_tmpfile -> passed [0.016s] lib/libc/stdlib/hsearch_test:hsearch_duplicate -> passed [0.014s] lib/libc/stdlib/hsearch_test:hsearch_nonexistent -> passed [0.014s] lib/libc/stdlib/hsearch_test:hsearch_two -> passed [0.015s] lib/libc/stdlib/posix_memalign_test:posix_memalign_basic -> passed [0.015s] lib/libc/stdlib/random_test:random_same -> passed [0.015s] lib/libc/stdlib/strtod_test:strtod_basic -> passed [0.014s] lib/libc/stdlib/strtod_test:strtod_gherman_bug -> passed [0.013s] lib/libc/stdlib/strtod_test:strtod_hex -> passed [0.013s] lib/libc/stdlib/strtod_test:strtod_inf -> passed [0.013s] lib/libc/stdlib/strtod_test:strtod_nan -> passed [0.013s] lib/libc/stdlib/strtod_test:strtod_round -> passed [0.013s] lib/libc/stdlib/strtod_test:strtod_underflow -> passed [0.014s] lib/libc/stdlib/strtod_test:strtof_inf -> passed [0.015s] lib/libc/stdlib/strtod_test:strtof_nan -> passed [0.015s] lib/libc/stdlib/strtod_test:strtold_inf -> passed [0.014s] lib/libc/stdlib/strtod_test:strtold_nan -> passed [0.014s] lib/libc/stdlib/strtol_test:strtol_base -> passed [0.014s] lib/libc/stdlib/strtol_test:strtol_case -> passed [0.014s] lib/libc/stdlib/strtol_test:strtol_range -> passed [0.014s] lib/libc/stdlib/strtol_test:strtol_signed -> passed [0.014s] lib/libc/stdlib/system_test:system_basic -> passed [0.030s] lib/libc/stdlib/getopt_test:getopt -> passed [1.430s] lib/libc/stdlib/getopt_test:getopt_long -> passed [0.327s] lib/libc/string/memchr:memchr_basic -> passed [0.014s] lib/libc/string/memchr:memchr_simple -> passed [0.015s] lib/libc/string/memchr:memrchr_simple -> passed [0.015s] lib/libc/string/memcpy:memccpy_simple -> passed [0.013s] lib/libc/string/memcpy:memcpy_basic -> passed [0.193s] lib/libc/string/memcpy:memcpy_return -> passed [0.014s] lib/libc/string/memmem:memmem_basic -> passed [0.013s] lib/libc/string/memset:memset_array -> passed [0.014s] lib/libc/string/memset:memset_basic -> passed [0.015s] lib/libc/string/memset:memset_nonzero -> passed [0.015s] lib/libc/string/memset:memset_return -> passed [0.015s] lib/libc/string/memset:memset_struct -> passed [0.015s] lib/libc/string/strcat:strcat_basic -> passed [0.025s] lib/libc/string/strcat:strncat_simple -> passed [0.015s] lib/libc/string/strchr:strchr_basic -> passed [0.014s] lib/libc/string/strcmp:strcmp_basic -> passed [0.014s] lib/libc/string/strcmp:strcmp_simple -> passed [0.015s] lib/libc/string/strcpy:strcpy_basic -> passed [0.014s] lib/libc/string/strcspn:strcspn -> passed [0.014s] lib/libc/string/strerror:strerror_basic -> passed [0.014s] lib/libc/string/strerror:strerror_err -> passed [0.014s] lib/libc/string/strerror:strerror_r_basic -> passed [0.014s] lib/libc/string/strerror:strerror_r_err -> passed [0.014s] lib/libc/string/strlen:strlen_basic -> passed [0.015s] lib/libc/string/strlen:strlen_huge -> passed [0.033s] lib/libc/string/strlen:strnlen_basic -> passed [0.014s] lib/libc/string/strpbrk:strpbrk -> passed [0.013s] lib/libc/string/strrchr:strrchr_basic -> passed [0.013s] lib/libc/string/strspn:strspn -> passed [0.013s] lib/libc/string/swab:swab_basic -> passed [0.014s] lib/libc/sys/access_test:access_access -> passed [0.018s] lib/libc/sys/access_test:access_fault -> passed [0.015s] lib/libc/sys/access_test:access_inval -> passed [0.017s] lib/libc/sys/access_test:access_notdir -> passed [0.014s] lib/libc/sys/access_test:access_notexist -> passed [0.014s] lib/libc/sys/access_test:access_toolong -> passed [0.014s] lib/libc/sys/chroot_test:chroot_basic -> passed [0.017s] lib/libc/sys/chroot_test:chroot_err -> passed [0.015s] lib/libc/sys/chroot_test:chroot_perm -> passed [0.015s] lib/libc/sys/clock_gettime_test:clock_gettime_real -> panic: wrote past end of sbuf (0 >= 0) cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe009748b760 vpanic() at vpanic+0x189/frame 0xfffffe009748b7e0 kassert_panic() at kassert_panic+0x132/frame 0xfffffe009748b850 sbuf_set_drain() at sbuf_set_drain+0x28/frame 0xfffffe009748b880 sbuf_new_for_sysctl() at sbuf_new_for_sysctl+0x29/frame 0xfffffe009748b8a0 sysctl_kern_timecounter_choice() at sysctl_kern_timecounter_choice+0x18/frame 0xfffffe009748b900 sysctl_root_handler_locked() at sysctl_root_handler_locked+0x94/frame 0xfffffe009748b940 sysctl_root() at sysctl_root+0x188/frame 0xfffffe009748b990 userland_sysctl() at userland_sysctl+0x192/frame 0xfffffe009748ba30 sys___sysctl() at sys___sysctl+0x74/frame 0xfffffe009748bae0 amd64_syscall() at amd64_syscall+0x27f/frame 0xfffffe009748bbf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe009748bbf0 --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x800b77b0a, rsp = 0x7fffffffa938, rbp = 0x7fffffffa970 --- KDB: enter: panic [ thread pid 4557 tid 100062 ] Stopped at kdb_enter+0x3e: movq $0,kdb_why db> Slave went offline during the build ERROR: Connection was broken: java.io.IOException: Unexpected reader termination at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:76) Caused by: java.lang.OutOfMemoryError: PermGen space at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2585) at java.lang.Class.getConstructor0(Class.java:2885) at java.lang.Class.newInstance(Class.java:350) at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:399) at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:396) at java.security.AccessController.doPrivileged(Native Method) at sun.reflect.MethodAccessorGenerator.generate(MethodAccessorGenerator.java:395) at sun.reflect.MethodAccessorGenerator.generateSerializationConstructor(MethodAccessorGenerator.java:113) at sun.reflect.ReflectionFactory.newConstructorForSerialization(ReflectionFactory.java:331) at java.io.ObjectStreamClass.getSerializableConstructor(ObjectStreamClass.java:1376) at java.io.ObjectStreamClass.access$1500(ObjectStreamClass.java:72) at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:493) at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:468) at java.security.AccessController.doPrivileged(Native Method) at java.io.ObjectStreamClass.(ObjectStreamClass.java:468) at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:365) at java.io.ObjectStreamClass.initProxy(ObjectStreamClass.java:562) at java.io.ObjectInputStream.readProxyDesc(ObjectInputStream.java:1575) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1514) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1771) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1990) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1915) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370) at hudson.remoting.Command.readFrom(Command.java:92) at hudson.remoting.AbstractSynchronousByteArrayCommandTransport.read(AbstractSynchronousByteArrayCommandTransport.java:34) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) Build step 'Execute shell' marked build as failure ERROR: Publisher hudson.tasks.junit.JUnitResultArchiver aborted due to exception hudson.AbortException: no workspace for FreeBSD_HEAD-tests2 #853 at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:72) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:761) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:721) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:670) at hudson.model.Run.execute(Run.java:1742) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240) From owner-freebsd-current@FreeBSD.ORG Tue Mar 17 17:22:01 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 62EC133F; Tue, 17 Mar 2015 17:22:01 +0000 (UTC) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::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 27F4AD06; Tue, 17 Mar 2015 17:22:01 +0000 (UTC) Received: by pdbcz9 with SMTP id cz9so15258804pdb.3; Tue, 17 Mar 2015 10:22:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=1nWwjq+7U64aqS4B22cKB3oxnBW0fzaL9PLEq+n96/0=; b=AscsuP7sMo1wDy9peIFocyYMawlHK5pTHJEbaW7MDTNpmQTOFrsxbaGC5pfB20EBf8 6nN8y8hrH/RBCJF28dYgKHOU61ICWPnSx6Rch7fAOnsCgqhFGw7T4teP1lVnVzAjMVXH bBV8R1t7NGwXkInVRJf1Q4JG3Xp/aIn5R3WknFezXACdcBOgkRXzTeJbOfLH98xbN9Zr tH+Z83yFDqpp2of1PPcwwEh+5VlAY1TcxBRRNWckUV3QM34D/sl4K51S7eYDqHw/2TtK ZWcERC0tK4X/IrKN77VoG4B85QNtbQl/1aZem90eu+2M9w8qIXr5TUmBOdgMCMaylliX 7NCg== X-Received: by 10.70.53.170 with SMTP id c10mr82673202pdp.148.1426612920770; Tue, 17 Mar 2015 10:22:00 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:7cd0:fcc6:fc9d:1ad4? ([2601:8:ab80:7d6:7cd0:fcc6:fc9d:1ad4]) by mx.google.com with ESMTPSA id zi10sm23448206pab.35.2015.03.17.10.21.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Mar 2015 10:21:59 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_F4D02BBD-C7AB-4901-AFD1-1CAC827E1985"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Build failed in Jenkins: FreeBSD_HEAD-tests2 #853 From: Garrett Cooper In-Reply-To: <615255742.14.1426582002157.JavaMail.jenkins@jenkins-9.freebsd.org> Date: Tue, 17 Mar 2015 10:21:57 -0700 Message-Id: <57E8F0F0-CA8E-4546-B807-423167F76E71@gmail.com> References: <93824666.13.1426571804793.JavaMail.jenkins@jenkins-9.freebsd.org> <615255742.14.1426582002157.JavaMail.jenkins@jenkins-9.freebsd.org> To: jenkins-admin@freebsd.org X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 17 Mar 2015 17:22:01 -0000 --Apple-Mail=_F4D02BBD-C7AB-4901-AFD1-1CAC827E1985 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Mar 17, 2015, at 1:46, jenkins-admin@freebsd.org wrote: > See =85 > lib/libc/sys/clock_gettime_test:clock_gettime_real -> panic: wrote = past end of sbuf (0 >=3D 0) > cpuid =3D 0 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame = 0xfffffe009748b760 > vpanic() at vpanic+0x189/frame 0xfffffe009748b7e0 > kassert_panic() at kassert_panic+0x132/frame 0xfffffe009748b850 > sbuf_set_drain() at sbuf_set_drain+0x28/frame 0xfffffe009748b880 > sbuf_new_for_sysctl() at sbuf_new_for_sysctl+0x29/frame = 0xfffffe009748b8a0 > sysctl_kern_timecounter_choice() at = sysctl_kern_timecounter_choice+0x18/frame 0xfffffe009748b900 > sysctl_root_handler_locked() at sysctl_root_handler_locked+0x94/frame = 0xfffffe009748b940 > sysctl_root() at sysctl_root+0x188/frame 0xfffffe009748b990 > userland_sysctl() at userland_sysctl+0x192/frame 0xfffffe009748ba30 > sys___sysctl() at sys___sysctl+0x74/frame 0xfffffe009748bae0 > amd64_syscall() at amd64_syscall+0x27f/frame 0xfffffe009748bbf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe009748bbf0 > --- syscall (202, FreeBSD ELF64, sys___sysctl), rip =3D 0x800b77b0a, = rsp =3D 0x7fffffffa938, rbp =3D 0x7fffffffa970 --- > KDB: enter: panic > [ thread pid 4557 tid 100062 ] > Stopped at kdb_enter+0x3e: movq $0,kdb_why > db> Slave went offline during the build > ERROR: Connection was broken: java.io.IOException: Unexpected reader = termination > at = hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCo= mmandTransport.java:76) > Caused by: java.lang.OutOfMemoryError: PermGen space > at java.lang.Class.getDeclaredConstructors0(Native Method) > at = java.lang.Class.privateGetDeclaredConstructors(Class.java:2585) > at java.lang.Class.getConstructor0(Class.java:2885) > at java.lang.Class.newInstance(Class.java:350) > at = sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:399= ) > at = sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:396= ) > at java.security.AccessController.doPrivileged(Native Method) > at = sun.reflect.MethodAccessorGenerator.generate(MethodAccessorGenerator.java:= 395) > at = sun.reflect.MethodAccessorGenerator.generateSerializationConstructor(Metho= dAccessorGenerator.java:113) > at = sun.reflect.ReflectionFactory.newConstructorForSerialization(ReflectionFac= tory.java:331) > at = java.io.ObjectStreamClass.getSerializableConstructor(ObjectStreamClass.jav= a:1376) > at = java.io.ObjectStreamClass.access$1500(ObjectStreamClass.java:72) > at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:493) > at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:468) > at java.security.AccessController.doPrivileged(Native Method) > at java.io.ObjectStreamClass.(ObjectStreamClass.java:468) > at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:365) > at = java.io.ObjectStreamClass.initProxy(ObjectStreamClass.java:562) > at = java.io.ObjectInputStream.readProxyDesc(ObjectInputStream.java:1575) > at = java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1514) > at = java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1771) > at = java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350) > at = java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1990) > at = java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1915) > at = java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798) > at = java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350) > at = java.io.ObjectInputStream.readObject(ObjectInputStream.java:370) > at hudson.remoting.Command.readFrom(Command.java:92) > at = hudson.remoting.AbstractSynchronousByteArrayCommandTransport.read(Abstract= SynchronousByteArrayCommandTransport.java:34) > at = hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCo= mmandTransport.java:48) >=20 > Build step 'Execute shell' marked build as failure > ERROR: Publisher hudson.tasks.junit.JUnitResultArchiver aborted due to = exception > hudson.AbortException: no workspace for FreeBSD_HEAD-tests2 #853 > at = hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLay= er.java:72) > at = hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) > at = hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.ja= va:761) > at = hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(Abs= tractBuild.java:721) > at hudson.model.Build$BuildExecution.post2(Build.java:183) > at = hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:= 670) > at hudson.model.Run.execute(Run.java:1742) > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) > at = hudson.model.ResourceController.execute(ResourceController.java:89) > at hudson.model.Executor.run(Executor.java:240) Hi Ian, It seems that things are still broken with sbuf(9). I filed = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D198663 to track the = issue. Thanks! --Apple-Mail=_F4D02BBD-C7AB-4901-AFD1-1CAC827E1985 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVCGK1AAoJEMZr5QU6S73esWoH/1IXj1NgqZlT77MY8cHeBzhs 5l2psotDP9V6AA9neUCkG9dQZJdnJrsleL2fN6rgF7tmBFRVFEZFcmtlLvl8Jpj9 LZ3o3ijKuxsWNuMPPmSv2pse4jx5E83IPZqGWN/Ay6ccO+InDf6koGvA1orG5Gh5 CdH8AStxXNv+aj+9UOaQZ4incGGi3yVZtZr7dNjte6sd56DuFinG1mnlsdw33YLa vA7fg1PKDKSyc/6EblnMhOm737rYD1V2MqX/AhyRXDCFn33SdRIntC9V6mQA6ZQw cUzA8iSaYIeAGRWMoCeZ12hWN1GCmQiuNghz6Fx7QtQHwzqtsitZynQ/aAhPh1E= =Gwm4 -----END PGP SIGNATURE----- --Apple-Mail=_F4D02BBD-C7AB-4901-AFD1-1CAC827E1985-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 17 18:49:59 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D20EB6C3 for ; Tue, 17 Mar 2015 18:49:59 +0000 (UTC) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (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 A2ECE891 for ; Tue, 17 Mar 2015 18:49:59 +0000 (UTC) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 56836206F9 for ; Tue, 17 Mar 2015 14:49:55 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute4.internal (MEProxy); Tue, 17 Mar 2015 14:49:57 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:x-sasl-enc:from:to :mime-version:content-transfer-encoding:content-type:subject :date:in-reply-to:references; s=smtpout; bh=YkPtRjVzrsXzHcqDmVg6 tgnQ4jE=; b=me7ntviUsCyqwJ0KB/bi4Onp2iVrTRXSXV4hCxwbQ26xY1Ha+Axd 4HMDfG/ZfUOSZX5Prwlp8oEnzfHj3XqiS51lqL4a/j9fVTXSp/z3WEXJKO1cavlB o/R4P3oPoZRF4o25T79pu40srffQXoLtm9ER+z0AQC5PYXxtXgRViX0= Received: by web3.nyi.internal (Postfix, from userid 99) id 40FA810F6BC; Tue, 17 Mar 2015 14:49:57 -0400 (EDT) Message-Id: <1426618197.670703.241661961.0D1A6F14@webmail.messagingengine.com> X-Sasl-Enc: DmdlSSrUO/Kr4s3MaZmdvUs81UwAlW6dC7fqZr2Tv5Yt 1426618197 From: Mark Felder To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-15db86eb Subject: Re: sbuf-related panic Date: Tue, 17 Mar 2015 13:49:57 -0500 In-Reply-To: <1426529019.4766.1.camel@hardenedbsd.org> References: <1426529019.4766.1.camel@hardenedbsd.org> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 17 Mar 2015 18:49:59 -0000 On Mon, Mar 16, 2015, at 13:03, Shawn Webb wrote: > On amd64, doing a Poudriere run. On r280133: > I appeared to be hitting this on 280130, the most recent CURRENT snapshot. I'm going to build the latest since some sbuf fixes have landed and see if I can finish a poudriere build run. From owner-freebsd-current@FreeBSD.ORG Tue Mar 17 18:58:32 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF780ABB; Tue, 17 Mar 2015 18:58:32 +0000 (UTC) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 472AE9A0; Tue, 17 Mar 2015 18:58:32 +0000 (UTC) Received: by ladw1 with SMTP id w1so17052985lad.0; Tue, 17 Mar 2015 11:58:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=nNHEv6s8J80Ezx5zAIjlADV1rWgk1aY71hVh/i9wi2E=; b=uFSxszkTV/SqhSBfMBp6PEXFwFxoqAMHF0YbtU7wq+JnC/HzrXSVa6OSBzc1F4/99K 8s6FR8H/kI4mly12/P4OaYuAdK8xgPSgrCbNbaSzVTEU0cNDj+ifquszDg3sFYq0Mwy7 +f7NUX0qjyFAl/ffua4pam5vpNLdncUs715n/RR1CAfapDSieoLXwPVfV+lvp3Pmnz7W hk2cdnNMI0/xOuArluKtEDsLJyraVKe2X8evPtx66XuKAIAM2n/Gaoc775ys1GAlUvT3 zPEEd8fC/75cI5pINxdiNPHu/oM+XukwElc1sQgKBE+eAUqFpS2qCqjcl3QUnKh1F38g e8Xw== MIME-Version: 1.0 X-Received: by 10.112.26.209 with SMTP id n17mr55809857lbg.84.1426618710290; Tue, 17 Mar 2015 11:58:30 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.82.164 with HTTP; Tue, 17 Mar 2015 11:58:29 -0700 (PDT) In-Reply-To: <1426618197.670703.241661961.0D1A6F14@webmail.messagingengine.com> References: <1426529019.4766.1.camel@hardenedbsd.org> <1426618197.670703.241661961.0D1A6F14@webmail.messagingengine.com> Date: Tue, 17 Mar 2015 11:58:29 -0700 X-Google-Sender-Auth: CGG4l05AnOM6cftKC_LsZMhr56Y Message-ID: Subject: Re: sbuf-related panic From: Craig Rodrigues To: Mark Felder Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 17 Mar 2015 18:58:32 -0000 On Tue, Mar 17, 2015 at 11:49 AM, Mark Felder wrote: > > > On Mon, Mar 16, 2015, at 13:03, Shawn Webb wrote: > > On amd64, doing a Poudriere run. On r280133: > > > > I appeared to be hitting this on 280130, the most recent CURRENT > snapshot. I'm going to build the latest since some sbuf fixes have > landed and see if I can finish a poudriere build run. > The Jenkins build which boots a VM and runs the kyua tests is kernel panicking in sbuf as well: https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/853/console You might want to see if that build passes before updating. -- Craig From owner-freebsd-current@FreeBSD.ORG Tue Mar 17 19:08:10 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 782A3219; Tue, 17 Mar 2015 19:08:10 +0000 (UTC) Received: from relay.mailchannels.net (aso-006-i435.relay.mailchannels.net [23.91.64.116]) by mx1.freebsd.org (Postfix) with ESMTP id 7C7C1AD2; Tue, 17 Mar 2015 19:08:05 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp1.ore.mailhop.org (ip-10-237-13-110.us-west-2.compute.internal [10.237.13.110]) by relay.mailchannels.net (Postfix) with ESMTPA id 4CEEC1208FE; Tue, 17 Mar 2015 19:07:58 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp1.ore.mailhop.org (smtp1.ore.mailhop.org [10.45.8.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.8); Tue, 17 Mar 2015 19:07:58 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: duocircle|x-authuser|hippie X-MailChannels-Auth-Id: duocircle X-MC-Loop-Signature: 1426619278379:2446173595 X-MC-Ingress-Time: 1426619278379 Received: from c-73-34-117-227.hsd1.co.comcast.net ([73.34.117.227] helo=ilsoft.org) by smtp1.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YXwqM-0006K1-6Q; Tue, 17 Mar 2015 19:07:58 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t2HIvO6q026130; Tue, 17 Mar 2015 12:57:24 -0600 (MDT) (envelope-from ian@freebsd.org) X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX18cbBjPN7fPGoCA1tANIVZe Message-ID: <1426618644.62241.4.camel@freebsd.org> Subject: Re: sbuf-related panic From: Ian Lepore To: Mark Felder Date: Tue, 17 Mar 2015 12:57:24 -0600 In-Reply-To: <1426618197.670703.241661961.0D1A6F14@webmail.messagingengine.com> References: <1426529019.4766.1.camel@hardenedbsd.org> <1426618197.670703.241661961.0D1A6F14@webmail.messagingengine.com> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-AuthUser: hippie Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 17 Mar 2015 19:08:10 -0000 On Tue, 2015-03-17 at 13:49 -0500, Mark Felder wrote: > > On Mon, Mar 16, 2015, at 13:03, Shawn Webb wrote: > > On amd64, doing a Poudriere run. On r280133: > > > > I appeared to be hitting this on 280130, the most recent CURRENT > snapshot. I'm going to build the latest since some sbuf fixes have > landed and see if I can finish a poudriere build run. There is still a panic, one that I can't yet figure out why it wasn't panicking before my changes, but I'm working on it. -- Ian From owner-freebsd-current@FreeBSD.ORG Tue Mar 17 19:14:33 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E01B75F4; Tue, 17 Mar 2015 19:14:33 +0000 (UTC) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7A37FC09; Tue, 17 Mar 2015 19:14:33 +0000 (UTC) Received: by labjg1 with SMTP id jg1so17383052lab.2; Tue, 17 Mar 2015 12:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=cAt5sVoaLiNV3Ehek4nnslve94mychg/r3Myd+0yXZc=; b=p3YSlOlB0+P3RlwrEMecmzbx/Q7sNpWRgEY0CZK6R5YYPAkXPvlwWNGcXrG91JOE0w 5X1rK7QSghlEd3ByBnA9HTUD99mIjGLNXCxjgewFegqj1AI+FPsn8zou7M9LJJ8bSheC y2H3NnVXbDW5I1ULb8irvotcXkoOSNgRjs69fmoolz4ZrVFDIB3omf/edF7mwgBXodEN tIOFLqKS8RFxWm3aPHNryDSfZjyFlpNkKM6yMq46Fb6sH5Qg9OgF0Szcj5FyD6o6CgBq +x+oj9SNFjUbmreDzkdYFXLzFEvh4wzTXEsgBH2iVDVWRjXIVmuZiDDN27Hvpsjd76NJ FswQ== MIME-Version: 1.0 X-Received: by 10.152.3.42 with SMTP id 10mr60833377laz.84.1426619671401; Tue, 17 Mar 2015 12:14:31 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.82.164 with HTTP; Tue, 17 Mar 2015 12:14:31 -0700 (PDT) In-Reply-To: <1426618644.62241.4.camel@freebsd.org> References: <1426529019.4766.1.camel@hardenedbsd.org> <1426618197.670703.241661961.0D1A6F14@webmail.messagingengine.com> <1426618644.62241.4.camel@freebsd.org> Date: Tue, 17 Mar 2015 12:14:31 -0700 X-Google-Sender-Auth: _o-v5nzt96cjaWz_fbHoDwnud28 Message-ID: Subject: Re: sbuf-related panic From: Craig Rodrigues To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 17 Mar 2015 19:14:34 -0000 On Tue, Mar 17, 2015 at 11:57 AM, Ian Lepore wrote: > > There is still a panic, one that I can't yet figure out why it wasn't > panicking before my changes, but I'm working on it. > > Can you run the kyua tests on your system? https://wiki.freebsd.org/201411DevAndVendorSummit?action=AttachFile&do=view&target=kyua_jenkins.pdf Those tests seem to be reproducibly triggering the problem. -- Craig From owner-freebsd-current@FreeBSD.ORG Tue Mar 17 19:14:41 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3577E6F2 for ; Tue, 17 Mar 2015 19:14:41 +0000 (UTC) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (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 03B25C11 for ; Tue, 17 Mar 2015 19:14:40 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id DF01C20BA3 for ; Tue, 17 Mar 2015 15:14:37 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute3.internal (MEProxy); Tue, 17 Mar 2015 15:14:39 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:x-sasl-enc:from:to:cc :mime-version:content-transfer-encoding:content-type:in-reply-to :references:subject:date; s=smtpout; bh=o6EECGfDYuU+C4aQlA5RdAZA tiI=; b=MdcXWP0Z1lhH9ACkuuEBxWigMm5WM1Ggt4FER+zmSOl1k0oz/TQcaCrY v2ELaHyg+hXqrNidvq44iK8HX3ofBV10hpHo9r603HHYQIcIq3UtsTOO8PJ8AQXI G4aNkaj2oEvXV2m9OLuH25z9+7Xh8MlMCFfcv7t0G9AI/e0Gf2M= Received: by web3.nyi.internal (Postfix, from userid 99) id C2D9A10F8F1; Tue, 17 Mar 2015 15:14:39 -0400 (EDT) Message-Id: <1426619679.676332.241672369.5773381C@webmail.messagingengine.com> X-Sasl-Enc: /ISGZUQ8aUJpd+ewU5Zh6/LloGTJSaOSi1kZyLH2sSgg 1426619679 From: Mark Felder To: Ian Lepore MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-15db86eb In-Reply-To: <1426618644.62241.4.camel@freebsd.org> References: <1426529019.4766.1.camel@hardenedbsd.org> <1426618197.670703.241661961.0D1A6F14@webmail.messagingengine.com> <1426618644.62241.4.camel@freebsd.org> Subject: Re: sbuf-related panic Date: Tue, 17 Mar 2015 14:14:39 -0500 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 17 Mar 2015 19:14:41 -0000 On Tue, Mar 17, 2015, at 13:57, Ian Lepore wrote: > On Tue, 2015-03-17 at 13:49 -0500, Mark Felder wrote: > > > > On Mon, Mar 16, 2015, at 13:03, Shawn Webb wrote: > > > On amd64, doing a Poudriere run. On r280133: > > > > > > > I appeared to be hitting this on 280130, the most recent CURRENT > > snapshot. I'm going to build the latest since some sbuf fixes have > > landed and see if I can finish a poudriere build run. > > There is still a panic, one that I can't yet figure out why it wasn't > panicking before my changes, but I'm working on it. > Is the previous snapshot -- r279813 -- old enough to have missed the related changes? I'm just trying to get a machine up from 10.1-RELEASE to relatively CURRENT quickly. From owner-freebsd-current@FreeBSD.ORG Tue Mar 17 19:33:20 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E88816AB for ; Tue, 17 Mar 2015 19:33:20 +0000 (UTC) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003: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 ADB75EAE for ; Tue, 17 Mar 2015 19:33:20 +0000 (UTC) Received: by oibu204 with SMTP id u204so17845288oib.0 for ; Tue, 17 Mar 2015 12:33:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=YnBQ+nlXPJWJPpdE2tztFsNK2EvPJ7L5+0LOXjvOVP0=; b=NLt1111SNg14qayLxjY8piX2b1yeagOQE6cPmIYaxVzlCL0cMcUfayHmDLQzhpSeBZ 05hCSc0q4xJsfxq1KN5e7qMjNnbdjtVwqM8aPsKhWUq5RHS0OsVw1RwuaVA14M5kDdv0 MLViw8uVVuNI6p39vEMXK5qGgOAG7K0PTigdvvfLM6ooLQ5+NWhX5GwjcFuEK6YxpYjJ zuWNduc0OtgGQbzCEVyrRCpWN+IkiB8EWYNgDMSP8bo85BW52XyVTgy8lb4ZlyIFjPK6 xm3HbbqKI0/LMpvUqoibe+rcGV5GxAgif8XZIt0RcDILM3UXSoXmeAecSTZ90GG8nNuV SLKQ== MIME-Version: 1.0 X-Received: by 10.60.73.38 with SMTP id i6mr47233240oev.27.1426620800049; Tue, 17 Mar 2015 12:33:20 -0700 (PDT) Received: by 10.76.86.42 with HTTP; Tue, 17 Mar 2015 12:33:19 -0700 (PDT) Date: Tue, 17 Mar 2015 19:33:19 +0000 Message-ID: Subject: Adding the -O option to pax(1) From: "Sevan / Venture37" To: freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 17 Mar 2015 19:33:21 -0000 Hi folks, Can I get some feedback on Bug 198481 which adds the -O option to pax(1). https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198481 Regards Sevan / Venture37 From owner-freebsd-current@FreeBSD.ORG Tue Mar 17 20:39:00 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03CAAB56 for ; Tue, 17 Mar 2015 20:39:00 +0000 (UTC) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::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 84759877 for ; Tue, 17 Mar 2015 20:38:59 +0000 (UTC) Received: by wggv3 with SMTP id v3so18300404wgg.1 for ; Tue, 17 Mar 2015 13:38:58 -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-type:content-disposition:in-reply-to :user-agent; bh=2FkVxEncXjhnQ+9s35oO+gc+1hFXT+65MptKZJIqZrU=; b=MRMAfOE3KaYIxnDshS419gAmknAnw1I/nTUiDoZYbiGnOuABbMS1pgD0MGgcHRcvuP f2aYcHkQzSwD0JEUnG5jXBBL5+/w+9WOeznkM7n8TSVpGvPYfvQGbYL0e87Q2jsQ6hgw bSatU6RCVT0S0Y6qUmkLuxtuG1cuD8HzVbH/mfrej71Q0IsxMcNzfbZoce9DU4/TD3Ty urusC3b/93YYUaKdmI8F6/ek+sA6ze8hYKTmn6GddJm7zrIGg/kV7umc10zp58Z0evFQ tqkUlMLT2wywwGVzM5vvLQGgKLRELJvBG99yEefM8OhfFQ01wM0KqUO37WHB3LFHWqa9 Y5cA== X-Received: by 10.180.81.7 with SMTP id v7mr903190wix.27.1426624737997; Tue, 17 Mar 2015 13:38:57 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id ga8sm158124wib.11.2015.03.17.13.38.54 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 17 Mar 2015 13:38:55 -0700 (PDT) Date: Tue, 17 Mar 2015 21:38:52 +0100 From: Mateusz Guzik To: Ryan Stone Subject: Re: [PATCH] Convert the VFS cache lock to an rmlock Message-ID: <20150317203852.GA30391@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Ryan Stone , FreeBSD Current References: <20150312173635.GB9153@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) Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 17 Mar 2015 20:39:00 -0000 On Fri, Mar 13, 2015 at 11:23:06AM -0400, Ryan Stone wrote: > On Thu, Mar 12, 2015 at 1:36 PM, Mateusz Guzik wrote: > > > Workloads like buildworld and the like (i.e. a lot of forks + execs) run > > into very severe contention in vm, which is orders of magnitude bigger > > than anything else. > > > > As such your result seems quite suspicious. > > > > You're right, I did mess up the testing somewhere (I have no idea how). As > you suggested, I switched to using a separate partition for the objdir, and > ran each build with a freshly newfsed filesystem. I scripted it to be sure > that I was following the same procedure with each run: > [..] > The difference is due to a significant increase in system time. Write > locks on an rmlock are extremely expensive (they involve an > smp_rendezvous), and the cost likely scales with the number of cores: > > x 32core/orig.log > + 32core/rmlock.log > +--------------------------------------------------------------------------+ > |xxx x + +++ +| > ||_MA__| |____MA______| | > +--------------------------------------------------------------------------+ > N Min Max Median Avg Stddev > x 5 5616.63 5715.7 5641.5 5661.72 48.511545 > + 5 6502.51 6781.84 6596.5 6612.39 103.06568 > Difference at 95.0% confidence > 950.67 +/- 117.474 > 16.7912% +/- 2.07489% > (Student's t, pooled s = 80.5478) > > > At this point I'm pretty much at an impasse. The real-time behaviour is > critical to me, but a 5% performance degradation isn't likely to be > acceptable to many people. I'll see what I can do with this. Well, you can see that the entire cache is protected by one lock. It also has other shortcomings which basically ask for a complete rewrite, so I would say spending significant amount of time on it is not worth discouraged. Brief look suggests that while just protecting each hash bucket by a separate lock may require a lot of work, it should be quite doable to do it with an additional lock which makes deletions exclusive, while insertions and lookups take the same lock shared and then lock specific buckets. Also cache_purge could be micro-optimized to not take the lock if we did not have any entries for given vnode (and we don't in a lot of cases). With this in place I would not be surprised if the thing was faster even with rmlock, which would justify it until the cache is rewritten. -- Mateusz Guzik From owner-freebsd-current@FreeBSD.ORG Tue Mar 17 21:08:26 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93523507; Tue, 17 Mar 2015 21:08:26 +0000 (UTC) Received: from relay.mailchannels.net (si-002-i77.relay.mailchannels.net [184.154.112.252]) by mx1.freebsd.org (Postfix) with ESMTP id 63912C37; Tue, 17 Mar 2015 21:08:23 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp7.ore.mailhop.org (ip-10-229-11-165.us-west-2.compute.internal [10.229.11.165]) by relay.mailchannels.net (Postfix) with ESMTPA id D5D8F120855; Tue, 17 Mar 2015 21:08:17 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp7.ore.mailhop.org (smtp7.ore.mailhop.org [10.21.145.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.8); Tue, 17 Mar 2015 21:08:20 +0000 X-MC-Relay: Bad X-MailChannels-SenderId: duocircle|x-authuser|hippie X-MailChannels-Auth-Id: duocircle X-MC-Loop-Signature: 1426626499997:672116081 X-MC-Ingress-Time: 1426626499996 Received: from c-73-34-117-227.hsd1.co.comcast.net ([73.34.117.227] helo=ilsoft.org) by smtp7.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YXyik-00018m-8E; Tue, 17 Mar 2015 21:08:14 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t2HL8773026353; Tue, 17 Mar 2015 15:08:07 -0600 (MDT) (envelope-from ian@freebsd.org) X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX1+J/qkcCBGxguBJ264WcUez Message-ID: <1426626487.62241.15.camel@freebsd.org> Subject: Re: sbuf-related panic From: Ian Lepore To: Craig Rodrigues Date: Tue, 17 Mar 2015 15:08:07 -0600 In-Reply-To: References: <1426529019.4766.1.camel@hardenedbsd.org> <1426618197.670703.241661961.0D1A6F14@webmail.messagingengine.com> <1426618644.62241.4.camel@freebsd.org> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-AuthUser: hippie Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 17 Mar 2015 21:08:26 -0000 On Tue, 2015-03-17 at 12:14 -0700, Craig Rodrigues wrote: > On Tue, Mar 17, 2015 at 11:57 AM, Ian Lepore wrote: > > > > > There is still a panic, one that I can't yet figure out why it wasn't > > panicking before my changes, but I'm working on it. > > > > > Can you run the kyua tests on your system? > > > https://wiki.freebsd.org/201411DevAndVendorSummit?action=AttachFile&do=view&target=kyua_jenkins.pdf > > Those tests seem to be reproducibly triggering the problem. > Triggering it wasn't the problem, understanding why it didn't used to fail and now it does was the tricky bit. :) It turns out it never failed before because nobody had tried to use default allocations (pointer and size zero) with sbuf_new_for_sysctl() before, and it didn't fail for me while I was testing my changes because I had commented-out INVARIANTS in my kernel config and forgotten that (doh!) so none of the assertions were actually being tested. So I fixed my test environment, then I fixed the code. Hopefully it's all better now. -- Ian From owner-freebsd-current@FreeBSD.ORG Tue Mar 17 21:22:49 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 28672A26; Tue, 17 Mar 2015 21:22:49 +0000 (UTC) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::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 E0532E00; Tue, 17 Mar 2015 21:22:48 +0000 (UTC) Received: by igbue6 with SMTP id ue6so83854204igb.1; Tue, 17 Mar 2015 14:22: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:date:message-id:subject:from:to :cc:content-type; bh=nmuLGkbV9fnLCGKeg8Bg81/NUm1tc+n2N71cWEx4Igs=; b=s4PUnzlwYMOS5pVpOzW8PJnHN/VHJKsReMghvfmL2RaDBEjU4DzQ0Gk3e93ZK13GxZ IOujFXcY0g28ebU+f9HPGqqUCKbGOYYYqFx40y6kA3Xn/ZnkQbpJWFEQnBDKDq7WzHKK 8/1w/P8fM6he4lr5+BK+xNOxcLNR0yrTIWZ9uBUBAqKjWnM+dM28dunzrnfU8hrc5jPd H7tWs6SjMdBi/T8o/QlkwIXkoYausGWRw3L82YdUMNEuSYAFQ8oea7Oi8avA2qjPSHYL k3M0TPJL672D11hsGBA4zVGW1kmgaCg+t3+fwq5nDZXSoagsJAk0VFBUkBQQ4od/i5Sb FQ8g== MIME-Version: 1.0 X-Received: by 10.50.39.65 with SMTP id n1mr1374093igk.37.1426627368206; Tue, 17 Mar 2015 14:22:48 -0700 (PDT) Received: by 10.107.156.75 with HTTP; Tue, 17 Mar 2015 14:22:48 -0700 (PDT) In-Reply-To: <1426626487.62241.15.camel@freebsd.org> References: <1426529019.4766.1.camel@hardenedbsd.org> <1426618197.670703.241661961.0D1A6F14@webmail.messagingengine.com> <1426618644.62241.4.camel@freebsd.org> <1426626487.62241.15.camel@freebsd.org> Date: Tue, 17 Mar 2015 17:22:48 -0400 Message-ID: Subject: Re: sbuf-related panic From: Ryan Stone To: Ian Lepore Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 17 Mar 2015 21:22:49 -0000 On Tue, Mar 17, 2015 at 5:08 PM, Ian Lepore wrote: > I had commented-out INVARIANTS in my kernel config and forgotten that > (doh!) so none of the assertions were actually being tested. > FYI: there is now a GENERIC-NODEBUG kernel config checked into head so you can just buildkernel/installkernel with KERNCONF=GENERIC-NODEBUG when you want to run without invariants/witness/etc. From owner-freebsd-current@FreeBSD.ORG Tue Mar 17 22:45:59 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 980AA128; Tue, 17 Mar 2015 22:45:59 +0000 (UTC) Received: from relay.mailchannels.net (ar-005-i194.relay.mailchannels.net [162.253.144.76]) by mx1.freebsd.org (Postfix) with ESMTP id 390CBAAA; Tue, 17 Mar 2015 22:45:56 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp5.ore.mailhop.org (ip-10-229-11-165.us-west-2.compute.internal [10.229.11.165]) by relay.mailchannels.net (Postfix) with ESMTPA id 2C9CC1D0350; Tue, 17 Mar 2015 19:17:54 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp5.ore.mailhop.org (smtp5.ore.mailhop.org [10.21.145.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.8); Tue, 17 Mar 2015 19:17:55 +0000 X-MC-Relay: Bad X-MailChannels-SenderId: duocircle|x-authuser|hippie X-MailChannels-Auth-Id: duocircle X-MC-Loop-Signature: 1426619875247:912503956 X-MC-Ingress-Time: 1426619875247 Received: from c-73-34-117-227.hsd1.co.comcast.net ([73.34.117.227] helo=ilsoft.org) by smtp5.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YXwzv-0000eq-Po; Tue, 17 Mar 2015 19:17:51 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t2HJHorn026199; Tue, 17 Mar 2015 13:17:50 -0600 (MDT) (envelope-from ian@freebsd.org) X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX18QmaueKsk7NDKGsve4Kot4 Message-ID: <1426619869.62241.5.camel@freebsd.org> Subject: Re: sbuf-related panic From: Ian Lepore To: Mark Felder Date: Tue, 17 Mar 2015 13:17:49 -0600 In-Reply-To: <1426619679.676332.241672369.5773381C@webmail.messagingengine.com> References: <1426529019.4766.1.camel@hardenedbsd.org> <1426618197.670703.241661961.0D1A6F14@webmail.messagingengine.com> <1426618644.62241.4.camel@freebsd.org> <1426619679.676332.241672369.5773381C@webmail.messagingengine.com> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-AuthUser: hippie Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 17 Mar 2015 22:45:59 -0000 On Tue, 2015-03-17 at 14:14 -0500, Mark Felder wrote: > > On Tue, Mar 17, 2015, at 13:57, Ian Lepore wrote: > > On Tue, 2015-03-17 at 13:49 -0500, Mark Felder wrote: > > > > > > On Mon, Mar 16, 2015, at 13:03, Shawn Webb wrote: > > > > On amd64, doing a Poudriere run. On r280133: > > > > > > > > > > I appeared to be hitting this on 280130, the most recent CURRENT > > > snapshot. I'm going to build the latest since some sbuf fixes have > > > landed and see if I can finish a poudriere build run. > > > > There is still a panic, one that I can't yet figure out why it wasn't > > panicking before my changes, but I'm working on it. > > > > Is the previous snapshot -- r279813 -- old enough to have missed the > related changes? I'm just trying to get a machine up from 10.1-RELEASE > to relatively CURRENT quickly. That should be safe, my series of sbuf changes that broke things started at r279992. -- Ian From owner-freebsd-current@FreeBSD.ORG Wed Mar 18 07:12:36 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 128BB713; Wed, 18 Mar 2015 07:12:36 +0000 (UTC) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A1F98773; Wed, 18 Mar 2015 07:12:35 +0000 (UTC) Received: by ladw1 with SMTP id w1so28375244lad.0; Wed, 18 Mar 2015 00:12:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZkinbVmyx2QUSq6LZJKYEaix8iZQAoGdXINjUCWNz5I=; b=wEMln9L6sqIRxgZ7SpDdSrDEND8cYOzTkwAelUCz88FiNaQq6EbT5Jud3K3LZRLjpY 6fk1XjYz9zDN+DgzlbrlzWMuGXVmU+g0AhAtlMpy/H4tW5rOL4y64uzjAcNZGNYt/vlk VNEmoTKaEmgMatk9EikHnL+n09Nm7i4igocpgPNl8FqcLeKlYH2poINOE4pYGfiYl8Yv W8iKpSDfu39WcIEP4oCpyQl7atnfNWJNfeqpEkFqP29zAnXKIyFNAWxKofpy5wStAtpN 1lrHhTa/ajvzvzhf7PUpBCkbB9dpsHr92WLkLF24ir4OOjdCpe9K73RvL8xu4Et8OwxA 5xjQ== X-Received: by 10.152.19.9 with SMTP id a9mr63943659lae.80.1426662753587; Wed, 18 Mar 2015 00:12:33 -0700 (PDT) Received: from [192.168.1.31] (gero.in. [77.37.212.15]) by mx.google.com with ESMTPSA id dq7sm3203734lac.25.2015.03.18.00.12.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Mar 2015 00:12:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: Request for testing an alternate branch From: lausgans@gmail.com In-Reply-To: Date: Wed, 18 Mar 2015 10:12:30 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Justin Hibbits , hrs@FreeBSD.org X-Mailer: Apple Mail (2.2070.6) X-Mailman-Approved-At: Wed, 18 Mar 2015 11:17:15 +0000 Cc: FreeBSD Current , FreeBSD PowerPC ML X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 18 Mar 2015 07:12:36 -0000 > 6 =D0=B4=D0=B5=D0=BA. 2013 =D0=B3., =D0=B2 23:40, Justin Hibbits = =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0):= >=20 > On Wed, Dec 4, 2013 at 10:19 PM, Justin Hibbits = wrote: >> I've been working on the projects/pmac_pmu branch for some time now = to >> add suspend/resume as well as CPU speed change for certain PowerPC >> machines, about a year since I created the branch, and now it's = stable >> enough that I want to merge it into HEAD, hence this request. Thanks for your work! What is the estimated time when it will go HEAD? May I expect that my powerbook4,1 machine will get ability to sleep = under the FreeBSD now? >> However, >> it does touch several drivers, turning them into "early drivers", = such >> that they can be initialized, and suspended and resumed at a = different >> time. Saying that, I do need testing from other architectures, to = make >> sure I haven't broken anything. >>=20 >> The technical details: >>=20 >> To get proper ordering, I've extended the bus_generic_suspend() and >> bus_generic_resume() to do multiple passes. Devices which cannot be >> enabled or disabled at the current pass level would return an EAGAIN. >> This could possibly cause problems, since it's an addition to an >> existing API rather than a new API to run along side it, so it needs = a >> great deal of testing. It works fine on PowerPC, but I don't have = any >> i386/amd64 or sparc64 hardware to test it on, so would like others = who >> do to test it. I don't thin >>=20 >> Also, any comments are of course welcome. Technical concerns are >> obviously welcome, and I will try to address everything. >>=20 >> Thanks, >>=20 >> Justin >=20 > Thanks to hrs@, images are now available for the pmac_pmu project on > allbsd for i386, amd64, sparc64, and ia64: > https://pub.allbsd.org/FreeBSD-snapshots/ . I understand that you provided these so people with another archs could = test whether it doesn't break anything, but what about actual PPC users? = ;) Considering that powerpc is a Tier 2 these days, it's not that easy even = to get svn quickly for it to grab your tree, so I would ask adding = projects_pmac_pmu to the powerpc building. Thanks. >=20 > - Justin > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current >=20 From owner-freebsd-current@FreeBSD.ORG Wed Mar 18 08:04:42 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7A8B2A2 for ; Wed, 18 Mar 2015 08:04:42 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1F4FBD24 for ; Wed, 18 Mar 2015 08:04:41 +0000 (UTC) Received: by wifj2 with SMTP id j2so32120204wif.1 for ; Wed, 18 Mar 2015 01:04:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gooddata.com; s=google; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=xoRt7i+lViPFtD0ynh92TCEiP2nsE+yV2LiV1VMqFC8=; b=OZBjEZv+tjaqKrU7KDizvZCp9FMzqnRevSHp410qk/+ahUlb0k563OnYEXSG5of6aK 5dYc3lcUhk4UukhjCklwl+hg8rNJjitJXAl62j42eQyiIcY4U9xSnkdNXMBZCd4MTvGa K3r5SVAA85ZZLmaQn+w22DDKVO2oUrnlDYTWg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=xoRt7i+lViPFtD0ynh92TCEiP2nsE+yV2LiV1VMqFC8=; b=fCKf7y+YTUme+Xgs/PQRjLsLEP9rx2y/6COo+TYDrGQPZ88848nuwaMJ2cPNMe3qBN hgX4C80lahDHzPGPXjwPXcmcGxerDj6BazKJGFWISNn+g9WxJWeGZtBN1u3rWBPxffhG 1wBGdUPecfHo20Lpe4Xtt+395I5ByDl/r3eTyqgFh2PMN9XJwPMon8kVip9205eA9K8m uu9k8B0nfKjBxirkjl5kjkgvMwXMdJ8qe0tqAv/INU5tMGGY8LSemryoiceuK3EbTX5e UnSBAi1GMl2fquRxJwhqKIaWr0MeTa9deykv4qvfL5v2Vi1pevNcw1pbGiMI/wpyP4dr aYLA== X-Gm-Message-State: ALoCoQku3Gnlj680DEc6UyrOL33iuhIrW7onsCJAHGydlXpidzSjbAqO0d6hzQlSy3t4U7ru6G+m X-Received: by 10.194.222.197 with SMTP id qo5mr137503956wjc.142.1426665880378; Wed, 18 Mar 2015 01:04:40 -0700 (PDT) Received: from npa.gooddata.com (gw-brno.gooddata.com. [194.213.40.134]) by mx.google.com with ESMTPSA id s5sm2004060wia.1.2015.03.18.01.04.39 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Mar 2015 01:04:39 -0700 (PDT) From: Nikola Pajkovsky To: Craig Rodrigues Subject: Re: sbuf-related panic References: <1426529019.4766.1.camel@hardenedbsd.org> <1426618197.670703.241661961.0D1A6F14@webmail.messagingengine.com> Date: Wed, 18 Mar 2015 09:04:38 +0100 In-Reply-To: (Craig Rodrigues's message of "Tue, 17 Mar 2015 11:58:29 -0700") Message-ID: <87fv92zq7d.fsf@npa.gooddata.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Mailman-Approved-At: Wed, 18 Mar 2015 11:30:10 +0000 Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 18 Mar 2015 08:04:42 -0000 Craig Rodrigues writes: > On Tue, Mar 17, 2015 at 11:49 AM, Mark Felder wrote: > >> >> >> On Mon, Mar 16, 2015, at 13:03, Shawn Webb wrote: >> > On amd64, doing a Poudriere run. On r280133: >> > >> >> I appeared to be hitting this on 280130, the most recent CURRENT >> snapshot. I'm going to build the latest since some sbuf fixes have >> landed and see if I can finish a poudriere build run. >> > > The Jenkins build which boots a VM and runs the kyua tests is kernel > panicking in sbuf as well: > > https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/853/console Why those builds do not contain svn revision or git commit? FreeBSD 11.0-CURRENT #26: Tue Mar 17 08:06:04 UTC 2015 jenkins@jenkins-10.freebsd.org:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/sys/GENERIC amd64 Maybe I have overlooked something, but with svn or git revision/commit bisection would be very simple. -- Nikola From owner-freebsd-current@FreeBSD.ORG Wed Mar 18 14:46:53 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3678E432; Wed, 18 Mar 2015 14:46:53 +0000 (UTC) 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 0EFC95FA; Wed, 18 Mar 2015 14:46:53 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 06770B997; Wed, 18 Mar 2015 10:46:52 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: [PATCH] Convert the VFS cache lock to an rmlock Date: Wed, 18 Mar 2015 10:17:22 -0400 Message-ID: <6376695.VOvhinOncy@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <20150313053203.GC9153@dft-labs.eu> References: <20150313053203.GC9153@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); Wed, 18 Mar 2015 10:46:52 -0400 (EDT) Cc: alc@freebsd.org, Mateusz Guzik , Ryan Stone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 18 Mar 2015 14:46:53 -0000 On Friday, March 13, 2015 06:32:03 AM Mateusz Guzik wrote: > On Thu, Mar 12, 2015 at 06:13:00PM -0500, Alan Cox wrote: > > Below is partial results from a profile of a parallel (-j7) "buildworld" on > > a 6-core machine that I did after the introduction of pmap_advise, so this > > is not a new profile. The results are sorted by total waiting time and > > only the top 20 entries are listed. > > > > Well, I ran stuff on lynx2 in the zoo on fresh -head with debugging > disabled (MALLOC_PRODUCTION included) and got quite different results. > > The machine is Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz > 2 package(s) x 10 core(s) x 2 SMT threads > > 32GB of ram > > Stuff was built in a chroot with world hosted on zfs. > > > max wait_max total wait_total count avg wait_avg > > cnt_hold cnt_lock name > > > > 1027 208500 16292932 1658585700 5297163 3 313 0 > > 3313855 kern/vfs_cache.c:629 (rw:Name Cache) > > > > 208564 186514 19080891106 1129189627 355575930 53 3 0 > > 1323051 kern/vfs_subr.c:2099 (lockmgr:ufs) > > > > 169241 148057 193721142 419075449 13819553 14 30 0 > > 110089 kern/vfs_subr.c:2210 (lockmgr:ufs) > > > > 187092 191775 1923061952 257319238 328416784 5 0 0 > > 5106537 kern/vfs_cache.c:488 (rw:Name Cache) > > > > make -j 12 buildworld on freshly booted system (i.e. the most namecache insertions): > > 32 292 3042019 33400306 8419725 0 3 0 2578026 kern/sys_pipe.c:1438 (sleep mutex:pipe mutex) > 170608 152572 642385744 27054977 202605015 3 0 0 1306662 kern/vfs_subr.c:2176 (lockmgr:zfs) You are using ZFS, Alan was using UFS. It would not surprise me that those would perform quite differently, and it would not surprise me that UFS is more efficient in terms of its interactions with the VM. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Mar 18 14:46:52 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 67FA2431 for ; Wed, 18 Mar 2015 14:46:52 +0000 (UTC) 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 4054D5F9 for ; Wed, 18 Mar 2015 14:46:52 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3376AB98F; Wed, 18 Mar 2015 10:46:51 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: What parts of UMA are part of the stable ABI? Date: Wed, 18 Mar 2015 10:24:09 -0400 Message-ID: <2085699.T9kJlc0rkf@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 18 Mar 2015 10:46:51 -0400 (EDT) Cc: Ryan Stone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 18 Mar 2015 14:46:52 -0000 On Friday, March 13, 2015 07:48:38 PM Ryan Stone wrote: > In this freebsd-hackers thread[1], a user reported that 10.1-RELEASE > crashes during boot on a system with 3TB of RAM. As it turns out, when you > have that much RAM ZFS autotunes itself to allocate a 6GB hash table. This > triggers a nasty 32-bit integer truncation bug in malloc(9). malloc() > calls uma_large_malloc(), but uma_large_malloc() accepts an int instead of > a size_t and all kinds of hilarity can ensure from there. The user has > confirmed that the page in [2] fixed the kernel from instantly panicking > once zfs.ko was loaded. I'm a bit concerned about whether the patch as > written is an MFC candidate though. > > uma_large_malloc() calls page_alloc() to actuallly allocate the memory, and > page_alloc() also accepts an int size parameter. This is where things get > tricky. The signature for page_alloc() is governed by the uma_alloc() > typedef, as uma also uses it internally for allocating memory for > uma_zones. There is even a uma_zone_set_allocf() API for overriding the > default allocation function. So there's definitely an argument to be made > the the signature of page_alloc() being a part of the stable ABI. > > I have no hesitation in saying that uma_large_malloc() is not a stable API > and changing it is fair game. If uma_alloc() is a part of the stable API, > then it's simple enough to commit a 64-bit safe allocation function for > uma_large_malloc() to call and changing page_alloc() to call it instead. > That commit can be MFC'ed, and a follow-up commit could convert the UMA > APIs to use size_t everywhere. I think uma_zone_set_allocf() is most likely obscure enough to not be used outside of the places in the kernel where it is used. From that, I think you are fine to change uma_alloc()'s signature. > While I am at this, I'd like to also change the uma init/fini/ctor/dtor to > also use size_t. I'm a little torn on this because this will definitely > cause a lot of churn, both in the tree and for downstream consumers, and > there's not necessarily going to be a big benefit to it. However, I > suppose that the existence of machines where 4GB is less than 1% of system > memory may mean that allocating 4GB at a time may not that outlandish. I > can definitely be talked out of this though. I do think the normal zone callbacks passed to uma_zcreate() are too public to change. Or at least, you would need to do some crazy ABI shim where you have a uma_zcreate_new() that you map to uma_zcreate() via a #define for the API, but include a legacy uma_zcreate() symbol that older modules can call (and then somehow tag the old function pointers via an internal flag in the zone and patch UMA to cast to the old function signatures for zones with that flag). Note that if you are really paranoid you could do the same thing with uma_zone_set_allocf(). It would break the API, but would preserve the ABI (i.e. leave an existing uma_zone_set_allocf() function that accepts the old prototype but have a uma_zone_set_allocf_new() that gets mapped to uma_zone_set_allocf via a #define). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Mar 18 14:57:53 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B12ACD2 for ; Wed, 18 Mar 2015 14:57:53 +0000 (UTC) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (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 8464D79D for ; Wed, 18 Mar 2015 14:57:51 +0000 (UTC) Received: by lbcgn8 with SMTP id gn8so31572637lbc.2 for ; Wed, 18 Mar 2015 07:57:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:to:date:content-type :mime-version:content-transfer-encoding; bh=zzPTJSISsNsA5oo3QoZBtM3xy8r3/aZuDPBGSf302Zw=; b=LJfudyhCbzstMDCZf3mUdxMmK8od/3oq2zdDRo9kaDq3aF0yiZnmgllBJ0Ut5rvRVs C306SWnV8H0VD2KUfTO+bQstnziNQMKaiGD/fdgSckGCsviGDAv7Cl90RlwGLMNqZCwg h1dPymtZ79LEdoRq3NbYASMxg2FCugjlzcJEdURqsefJmCSFeG/oNfbfO50C1ctL4rZN DIVfM7UITY543kqtosL3cl54AJpnFMAOmDSu5cMgpQfv9ZUFR7Uq+VUsJn1vM3D7gVH/ JEOH3DhVb1um2Mka8803yogGhBDIrLLXx+jfLCzdTnaGg3N9u0mgmuUXDKHs/aPDtHYT IrSA== X-Gm-Message-State: ALoCoQnvJCpgt+CBgDVyfoXrHdiOGVp+d3sCZrS7tSxOGReSsqSnO0j+8bLGAa7BrfU8so8hEcUy X-Received: by 10.152.7.212 with SMTP id l20mr53167861laa.68.1426689126586; Wed, 18 Mar 2015 07:32:06 -0700 (PDT) Received: from [10.0.2.124] ([80.82.22.190]) by mx.google.com with ESMTPSA id kd7sm3419739lbc.42.2015.03.18.07.32.05 for (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128/128); Wed, 18 Mar 2015 07:32:05 -0700 (PDT) Message-ID: <1426689130.4058.34.camel@HP10> Subject: Clang 3.6.0 for ARMv7 failure From: Jakub Palider To: freebsd-current@freebsd.org Date: Wed, 18 Mar 2015 15:32:10 +0100 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 18 Mar 2015 14:57:53 -0000 Hi, every couple of days I rebase to the head of the -current and this time I encountered a problem during toolchain build related probably to the recent compiler changes. As I am mainly interested in building kernel I just switched to kernel-toolchain which worked fine for me, but anyway, this looks like a wider problem. Maybe I am missing some transition option - previous builds were fine - if so I would be happy to hear any pointers to fix it locally. Below is the error report. Thank you, Jakub Palider Unexpected member type for HA UNREACHABLE executed at /root/jpa/anpa-fbsd/lib/clang/libllvmarmcodegen/../../../contrib/llvm/li= b/Target/ARM/ARMCallingConv.h:209! Stack dump: 0. Program arguments: /home/jpa/anpa-build/arm.arm/root/jpa/anpa-fbsd/tmp/usr/bin/cc -= cc1 -triple armv6--freebsd11.0-gnueabi -emit-obj -disable-free -main-file-n= ame b_tgamma.c -mrelocation-model pic -pic-level 1 -mthread-model posix -md= isable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu arm1176jzf-s= -target-feature +soft-float -target-feature +soft-float-abi -target-featur= e -neon -target-feature -crypto -target-abi aapcs-linux -msoft-float -mfloa= t-abi soft -dwarf-column-info -coverage-file /home/jpa/anpa-build/arm.arm/r= oot/jpa/anpa-fbsd/lib/msun/b_tgamma.So -resource-dir /home/jpa/anpa-build/a= rm.arm/root/jpa/anpa-fbsd/tmp/usr/bin/../lib/clang/3.6.0 -D PIC -D ARM_ARCH= _6=3D1 -I /home/jpa/anpa-fbsd/lib/msun/src -I /home/jpa/anpa-fbsd/lib/msun/= ../libc/include -I /home/jpa/anpa-fbsd/lib/msun/../libc/arm -isysroot /home= /jpa/anpa-build/arm.arm/root/jpa/anpa-fbsd/tmp -O2 -Wsystem-headers -Werror= -Wno-pointer-sign -Wno-unknown-pragmas -Wno-empty-body -Wno-string-plus-in= t -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -W= no-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unus= ed-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -= Wno-parentheses -std=3Dgnu99 -fdebug-compilation-dir /home/jpa/anpa-build/a= rm.arm/root/jpa/anpa-fbsd/lib/msun -ferror-limit 19 -fmessage-length 0 -mst= ackrealign -fno-signed-char -fobjc-runtime=3Dgnustep -fdiagnostics-show-opt= ion -vectorize-loops -vectorize-slp -o b_tgamma.So -x c /home/jpa/anpa-fbsd= /lib/msun/bsdsrc/b_tgamma.c=20 From owner-freebsd-current@FreeBSD.ORG Wed Mar 18 15:19:22 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A95FB6C2; Wed, 18 Mar 2015 15:19:22 +0000 (UTC) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E6649D0; Wed, 18 Mar 2015 15:19:22 +0000 (UTC) Received: by igbue6 with SMTP id ue6so102916249igb.1; Wed, 18 Mar 2015 08:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=q8L/EsaH71tkVW6MYQxb6FQ0Ow3QSs3iMIBXc7d7UbE=; b=bY4u/6ZaEEwpanKH610k1ouUfXoV8BduWB/IoH7YJVKDIqd3qMDnhIC5hS0wMz6+Ul dYXhqR5PCR5Zzu5LckTXNJ59oGN28AXXxFXhGwsC/NQjemsSNjV3wkA0tefilK22cXpy rVLLQzOLl8oVMsd7aSI/1a+GDBdNFkXu10m8CDFtiZjgZn/Hf0XCtdTIjEJ9gwJviuTz vMLCgpM5nSKkeQWdWnmpZujAo00qp+3rH7u2i9HG4b7c4WLWftpwjNbmYGDFHN1g6KpD QESG8P7B7FcPavVobP7apw4yN51n8SY3Qq+dALOX9KcN+eJsJ+K3VKfLn0WH80IJOGp4 oxdA== MIME-Version: 1.0 X-Received: by 10.50.39.65 with SMTP id n1mr7696138igk.37.1426691961857; Wed, 18 Mar 2015 08:19:21 -0700 (PDT) Received: by 10.107.156.75 with HTTP; Wed, 18 Mar 2015 08:19:21 -0700 (PDT) In-Reply-To: <2085699.T9kJlc0rkf@ralph.baldwin.cx> References: <2085699.T9kJlc0rkf@ralph.baldwin.cx> Date: Wed, 18 Mar 2015 11:19:21 -0400 Message-ID: Subject: Re: What parts of UMA are part of the stable ABI? From: Ryan Stone To: John Baldwin Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 18 Mar 2015 15:19:22 -0000 On Wed, Mar 18, 2015 at 10:24 AM, John Baldwin wrote: > I do think the normal zone callbacks passed to uma_zcreate() are too public > to change. Or at least, you would need to do some crazy ABI shim where you > have a uma_zcreate_new() that you map to uma_zcreate() via a #define for > the API, but include a legacy uma_zcreate() symbol that older modules can > call (and then somehow tag the old function pointers via an internal flag > in the zone and patch UMA to cast to the old function signatures for zones > with that flag). > I really wasn't clear here. I definitely don't think that changing the ctor, etc to accept a size_t is MFC'able, and I don't think that the problem (which is really only theoretical at this point) warrants an MFC to -stable. I was talking about potentially doing it in a separate commit to head, but that does leave -stable and head with a different API. This can be painful for downstream consumers to deal with, which is why I wanted comments. From owner-freebsd-current@FreeBSD.ORG Wed Mar 18 15:59:57 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0B29DCD for ; Wed, 18 Mar 2015 15:59:57 +0000 (UTC) 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 C6FCFED0 for ; Wed, 18 Mar 2015 15:59:57 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 78C32B93A; Wed, 18 Mar 2015 11:59:56 -0400 (EDT) From: John Baldwin To: Ryan Stone Subject: Re: What parts of UMA are part of the stable ABI? Date: Wed, 18 Mar 2015 11:23:15 -0400 Message-ID: <3923303.nkjJO958qy@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: References: <2085699.T9kJlc0rkf@ralph.baldwin.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 18 Mar 2015 11:59:56 -0400 (EDT) Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 18 Mar 2015 15:59:58 -0000 On Wednesday, March 18, 2015 11:19:21 AM Ryan Stone wrote: > On Wed, Mar 18, 2015 at 10:24 AM, John Baldwin wrote: > > > I do think the normal zone callbacks passed to uma_zcreate() are too public > > to change. Or at least, you would need to do some crazy ABI shim where you > > have a uma_zcreate_new() that you map to uma_zcreate() via a #define for > > the API, but include a legacy uma_zcreate() symbol that older modules can > > call (and then somehow tag the old function pointers via an internal flag > > in the zone and patch UMA to cast to the old function signatures for zones > > with that flag). > > > > I really wasn't clear here. I definitely don't think that changing the > ctor, etc to accept a size_t is MFC'able, and I don't think that the > problem (which is really only theoretical at this point) warrants an MFC to > -stable. I was talking about potentially doing it in a separate commit to > head, but that does leave -stable and head with a different API. This can > be painful for downstream consumers to deal with, which is why I wanted > comments. I actually think the API change to fix the zone callbacks is fine to change in HEAD. I don't think that is too disruptive for folks who might be sharing code across branches (they can use a local typedef to work around it or some such). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Mar 18 16:41:55 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B4E3AA17; Wed, 18 Mar 2015 16:41:55 +0000 (UTC) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::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 4F78766E; Wed, 18 Mar 2015 16:41:55 +0000 (UTC) Received: by lbblx11 with SMTP id lx11so11832964lbb.3; Wed, 18 Mar 2015 09:41:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=VtIGoK++tXVqUzw3ml/pLfGbCGgHEb7zm5RGhCReSHY=; b=fb2V+PId9lfrzMeqoZqor9aldrzPtgh7f/PSozdu4EVwbdzb7If0/tgZ3/EvV9+2ID jpUq5Qqtd+Wt0FS87+5qcN6jOwgLf2V/nM+8VrG3G6NG8jvpdTy1KCTlIa7f1Q7eHnnM V/PATO6hNp+pZQ4NnwjSy1I4L72HKkX6TtscgdSlAObRez7VhaKw+Kfhw9Oj7nBw4K03 KxfjgkHft5pm9ZPf6bfcvqt6pnvYTGBVM5WtWjqQcLatggZZbzTm19T5R0UrX3UyG5UD VorrX8KZzs+JmyazeC/y7xWpm184bsv6hHHk/+ZfoDcxtMy8VjrDRCfTxewFPtYJPuLf XCcA== MIME-Version: 1.0 X-Received: by 10.112.25.38 with SMTP id z6mr14606916lbf.106.1426696912983; Wed, 18 Mar 2015 09:41:52 -0700 (PDT) Sender: chmeeedalf@gmail.com Received: by 10.25.145.65 with HTTP; Wed, 18 Mar 2015 09:41:52 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Mar 2015 09:41:52 -0700 X-Google-Sender-Auth: NQyTjgIPYrY4ilrnHuU_8jfiNrU Message-ID: Subject: Re: Request for testing an alternate branch From: Justin Hibbits To: lausgans@gmail.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD PowerPC ML , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 18 Mar 2015 16:41:55 -0000 On Wed, Mar 18, 2015 at 12:12 AM, wrote: > >> 6 =D0=B4=D0=B5=D0=BA. 2013 =D0=B3., =D0=B2 23:40, Justin Hibbits =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0): >> >> On Wed, Dec 4, 2013 at 10:19 PM, Justin Hibbits w= rote: >>> I've been working on the projects/pmac_pmu branch for some time now to >>> add suspend/resume as well as CPU speed change for certain PowerPC >>> machines, about a year since I created the branch, and now it's stable >>> enough that I want to merge it into HEAD, hence this request. > > Thanks for your work! What is the estimated time when it will go HEAD? > May I expect that my powerbook4,1 machine will get ability to sleep under= the FreeBSD now? > >>> However, >>> it does touch several drivers, turning them into "early drivers", such >>> that they can be initialized, and suspended and resumed at a different >>> time. Saying that, I do need testing from other architectures, to make >>> sure I haven't broken anything. >>> >>> The technical details: >>> >>> To get proper ordering, I've extended the bus_generic_suspend() and >>> bus_generic_resume() to do multiple passes. Devices which cannot be >>> enabled or disabled at the current pass level would return an EAGAIN. >>> This could possibly cause problems, since it's an addition to an >>> existing API rather than a new API to run along side it, so it needs a >>> great deal of testing. It works fine on PowerPC, but I don't have any >>> i386/amd64 or sparc64 hardware to test it on, so would like others who >>> do to test it. I don't thin >>> >>> Also, any comments are of course welcome. Technical concerns are >>> obviously welcome, and I will try to address everything. >>> >>> Thanks, >>> >>> Justin >> >> Thanks to hrs@, images are now available for the pmac_pmu project on >> allbsd for i386, amd64, sparc64, and ia64: >> https://pub.allbsd.org/FreeBSD-snapshots/ . > > I understand that you provided these so people with another archs could t= est whether it doesn't break anything, but what about actual PPC users? ;) > Considering that powerpc is a Tier 2 these days, it's not that easy even = to get svn quickly for it to grab your tree, so I would ask adding projects= _pmac_pmu to the powerpc building. Thanks. There were some design decisions that people took issue with, so I've been working on that. I plan to merge the bulk of the work into HEAD soon, but only the driver suspend/resume routines. The additional updates for suspending the system as a whole won't be made for some time, due to the intrusiveness of the change. I'm still planning for this to be completed for the 11.0 release, and with the bulk of the work completed, that should be feasible. I don't have a PowerBook4,1 to test with, but I think it should work, but some drivers may not resume properly. - Justin From owner-freebsd-current@FreeBSD.ORG Wed Mar 18 17:58:18 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 946BFC73; Wed, 18 Mar 2015 17:58:18 +0000 (UTC) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1F012FB9; Wed, 18 Mar 2015 17:58:18 +0000 (UTC) Received: by wifj2 with SMTP id j2so46745281wif.1; Wed, 18 Mar 2015 10:58:16 -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-type:content-disposition:in-reply-to :user-agent; bh=CZMpJenexYnooUTSa5ZE5HoCzPqoPKmDyctpfUXznG8=; b=pykcOgoD7iYQWdLXqqEULrN434dOLngLccuF7Rf+VeF70gztNSiMKOSPpU1pfUFSLC mJ53y6xEV8TR0drex8dTwMn1fbhM6uWp8b7zfjGIY7Mr7z1YBeRlYkTxnjTbC9QUG9bk 3sJtcCy08wNL3hVZyRk0ozo816j5CgVqAXIW9EKG5+zTX+L93aT30HHc5at/s0snpk1p yUY30KWvHLmPnA4I0m/J/0I2PWkZoc5DWa5yX4QBbM2js6g2nr78TUuc6T9qHdmxA277 5ZYhEoMe9SPK9TC8eiTAsoNiSBc3hlG812TBnxsmsuAEESw/pk5NGQgbJTfX0QJxt6nv FCpw== X-Received: by 10.194.174.164 with SMTP id bt4mr110296493wjc.155.1426701496635; Wed, 18 Mar 2015 10:58:16 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id gz3sm4183919wib.1.2015.03.18.10.58.15 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 18 Mar 2015 10:58:15 -0700 (PDT) Date: Wed, 18 Mar 2015 18:58:13 +0100 From: Mateusz Guzik To: John Baldwin Subject: Re: [PATCH] Convert the VFS cache lock to an rmlock Message-ID: <20150318175812.GA3512@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , John Baldwin , freebsd-current@freebsd.org, alc@freebsd.org, Ryan Stone References: <20150313053203.GC9153@dft-labs.eu> <6376695.VOvhinOncy@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <6376695.VOvhinOncy@ralph.baldwin.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: alc@freebsd.org, freebsd-current@freebsd.org, Ryan Stone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 18 Mar 2015 17:58:18 -0000 On Wed, Mar 18, 2015 at 10:17:22AM -0400, John Baldwin wrote: > On Friday, March 13, 2015 06:32:03 AM Mateusz Guzik wrote: > > On Thu, Mar 12, 2015 at 06:13:00PM -0500, Alan Cox wrote: > > > Below is partial results from a profile of a parallel (-j7) "buildworld" on > > > a 6-core machine that I did after the introduction of pmap_advise, so this > > > is not a new profile. The results are sorted by total waiting time and > > > only the top 20 entries are listed. > > > > > > > Well, I ran stuff on lynx2 in the zoo on fresh -head with debugging > > disabled (MALLOC_PRODUCTION included) and got quite different results. > > > > The machine is Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz > > 2 package(s) x 10 core(s) x 2 SMT threads > > > > 32GB of ram > > > > Stuff was built in a chroot with world hosted on zfs. > > > > > max wait_max total wait_total count avg wait_avg > > > cnt_hold cnt_lock name > > > > > > 1027 208500 16292932 1658585700 5297163 3 313 0 > > > 3313855 kern/vfs_cache.c:629 (rw:Name Cache) > > > > > > 208564 186514 19080891106 1129189627 355575930 53 3 0 > > > 1323051 kern/vfs_subr.c:2099 (lockmgr:ufs) > > > > > > 169241 148057 193721142 419075449 13819553 14 30 0 > > > 110089 kern/vfs_subr.c:2210 (lockmgr:ufs) > > > > > > 187092 191775 1923061952 257319238 328416784 5 0 0 > > > 5106537 kern/vfs_cache.c:488 (rw:Name Cache) > > > > > > > make -j 12 buildworld on freshly booted system (i.e. the most namecache insertions): > > > > 32 292 3042019 33400306 8419725 0 3 0 2578026 kern/sys_pipe.c:1438 (sleep mutex:pipe mutex) > > 170608 152572 642385744 27054977 202605015 3 0 0 1306662 kern/vfs_subr.c:2176 (lockmgr:zfs) > > You are using ZFS, Alan was using UFS. It would not surprise me that those > would perform quite differently, and it would not surprise me that UFS is > more efficient in terms of its interactions with the VM. > This is lots of forks + execs and page queue has only one lock. Fwiw, ufs world backed by dedidacted parition, other conditions unchanged First build: 52 411 3327572 36528102 8508545 0 4 0 2587337 kern/sys_pipe.c:1438 (sleep mutex:pipe mutex) 308102 308099 430348158 36163333 203246241 2 0 0 459200 kern/vfs_subr.c:2176 (lockmgr:ufs) 78 818 44308162 29968440 165009282 0 0 0 22053854 vm/vm_page.c:1502 (sleep mutex:vm page free queue) 48 238 18872405 28456578 164327020 0 0 0 22512151 vm/vm_page.c:2294 (sleep mutex:vm page free queue) 208 1486 69780863 17484511 144970085 0 0 0 134429 amd64/amd64/pmap.c:4204 (rw:pmap pv global) 52 1263 19390169 8186840 142392234 0 0 0 11151398 vm/vm_page.c:2053 (sleep mutex:vm active pagequeue) 27 1801 19754927 8092312 142403798 0 0 0 9993164 vm/vm_page.c:2097 (sleep mutex:vm active pagequeue) 1145 1300 19872450 7158951 7690094 2 0 0 269930 vm/vm_fault.c:785 (rw:vm object) 25579 1636 10955717 5962336 12620413 0 0 0 96691 vm/vm_map.c:2883 (rw:vm object) 39 54994 1428266 5141221 368787 3 13 0 13391 kern/kern_exec.c:590 (lockmgr:ufs) 311470 311513 67241105 3971357 30997102 2 0 0 5094 kern/vfs_lookup.c:509 (lockmgr:ufs) 55 568 64300400 3821394 214921016 0 0 0 2699822 kern/vfs_cache.c:487 (rw:Name Cache) 14 2224 31486 3784823 266762 0 14 0 43516 amd64/amd64/pmap.c:3767 (rw:pmap pv global) 15 1179 184521 2651974 2126398 0 1 0 31955 vm/vm_object.c:646 (rw:vm object) 43267 54635 56190811 2228815 368787 152 6 0 10399 kern/imgact_elf.c:829 (lockmgr:ufs) 1802 3276 55104622 2042552 142404165 0 0 0 543434 vm/vm_fault.c:997 (sleep mutex:vm page) 29 54 50897307 1792095 199350363 0 0 0 2305326 kern/vfs_cache.c:668 (sleep mutex:vnode interlock) 1051 1252 3640803 1792074 1030592 3 1 0 18897 vm/vm_object.c:1703 (rw:vm object) 17 1389 269455 1778764 2828515 0 0 0 106843 vm/vm_object.c:1222 (rw:vm object) 472 1444 14742782 1731247 6851167 2 0 0 20011 amd64/amd64/pmap.c:3620 (rw:pmap pv global) reset + rm -r /usr/obj/* 230791 100799 405140208 51092446 203312369 1 0 0 472299 kern/vfs_subr.c:2176 (lockmgr:ufs) 188 8046 69993327 41591950 144943809 0 0 0 175226 amd64/amd64/pmap.c:4204 (rw:pmap pv global) 76 647 45324624 35204587 164788099 0 0 0 22749884 vm/vm_page.c:1502 (sleep mutex:vm page free queue) 40 237 19428445 33209934 164266257 0 0 0 22973810 vm/vm_page.c:2294 (sleep mutex:vm page free queue) 52 298 3038837 32813929 8418613 0 3 0 2587957 kern/sys_pipe.c:1438 (sleep mutex:pipe mutex) 1939 3216 19524902 14623470 7688013 2 1 0 274392 vm/vm_fault.c:785 (rw:vm object) 21696 2861 11773227 13246477 12617163 0 1 0 106342 vm/vm_map.c:2883 (rw:vm object) 54 7664 1445280 10079322 368785 3 27 0 15598 kern/kern_exec.c:590 (lockmgr:ufs) 22 2736 19935005 9087069 142381462 0 0 0 10214061 vm/vm_page.c:2097 (sleep mutex:vm active pagequeue) 36 885 19540659 8825819 142378309 0 0 0 11305041 vm/vm_page.c:2053 (sleep mutex:vm active pagequeue) 15 3045 33404 7922947 267066 0 29 0 48667 amd64/amd64/pmap.c:3767 (rw:pmap pv global) 13 2605 194977 6294921 2126083 0 2 0 36096 vm/vm_object.c:646 (rw:vm object) 82 2269 269861 4506215 2827953 0 1 0 107885 vm/vm_object.c:1222 (rw:vm object) 2179 6501 82846723 4123049 368785 224 11 0 13145 kern/imgact_elf.c:829 (lockmgr:ufs) 81 722 64614191 4099711 214861181 0 0 0 2763484 kern/vfs_cache.c:487 (rw:Name Cache) 3925 2851 3900231 3909417 1031608 3 3 0 22052 vm/vm_object.c:1703 (rw:vm object) 483 3335 14875079 3554944 6850151 2 0 0 24182 amd64/amd64/pmap.c:3620 (rw:pmap pv global) 187 129 103680324 2146404 250760755 0 0 0 1630451 amd64/amd64/pmap.c:5362 (rw:pmap pv list) 30468 2402 126229130 2042062 158088931 0 0 0 71708 vm/vm_object.c:517 (rw:vm object) 28 76 51334143 1892757 199327513 0 0 0 2384837 kern/vfs_cache.c:668 (sleep mutex:vnode interlock) -- Mateusz Guzik From owner-freebsd-current@FreeBSD.ORG Wed Mar 18 17:07:37 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F0742F4 for ; Wed, 18 Mar 2015 17:07:37 +0000 (UTC) Received: from work.netasq.com (gwlille.netasq.com [91.212.116.1]) by mx1.freebsd.org (Postfix) with ESMTP id A84B59BF for ; Wed, 18 Mar 2015 17:07:36 +0000 (UTC) Received: from work.netasq.com (localhost.localdomain [127.0.0.1]) by work.netasq.com (Postfix) with ESMTP id 1B30A27050B4 for ; Wed, 18 Mar 2015 18:00:37 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by work.netasq.com (Postfix) with ESMTP id F33D52703B8D for ; Wed, 18 Mar 2015 18:00:36 +0100 (CET) Received: from work.netasq.com ([127.0.0.1]) by localhost (work.netasq.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id vs6LwitCcqta for ; Wed, 18 Mar 2015 18:00:36 +0100 (CET) Received: from pc-alex.localnet (unknown [10.2.200.254]) by work.netasq.com (Postfix) with ESMTP id D520427050B4 for ; Wed, 18 Mar 2015 18:00:35 +0100 (CET) From: Alexandre Martins To: 'freebsd-current' Subject: Possible race in IPv6 Date: Wed, 18 Mar 2015 18:01:42 +0100 Message-ID: <95157304.ieSUkydfeD@pc-alex> Organization: NETASQ User-Agent: KMail/4.14.2 (FreeBSD/10.0-RELEASE-p12; KDE/4.14.2; amd64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7323170.F8fcClRqky"; micalg="sha1"; protocol="application/pkcs7-signature" X-Mailman-Approved-At: Wed, 18 Mar 2015 18:06:44 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 18 Mar 2015 17:07:37 -0000 --nextPart7323170.F8fcClRqky Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Dear, I'm facing some crash around manipulations of IPv6 address. I already found that the commit 275593 will fix my issue. However, after some code review, i see a possible race in the function=20= nd6_na_input: https://svnweb.freebsd.org/base/head/sys/netinet6/nd6_nbr.c?annotate=3D= 279676#l750 =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D if (ifa && (((struct in6_ifaddr *)ifa)->ia6_flags & IN6_IFF_TENTATIVE)) { ifa_free(ifa); nd6_dad_na_input(ifa); goto freeit; } =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D As you can see, the function drop its reference on the address and pass= it to=20 nd6_dad_na_input. It should be better to release the reference after the call. What about you? Regards =2D-=20 Alexandre Martins STORMSHIELD --nextPart7323170.F8fcClRqky Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIhDCCBIYw ggJuoAMCAQICBQDbzPDtMA0GCSqGSIb3DQEBCwUAMEgxCzAJBgNVBAYTAkZSMRQwEgYDVQQKDAtT VE9STVNISUVMRDEjMCEGA1UEAwwaU3Rvcm1zaGllbGQgUm9vdCBBdXRob3JpdHkwHhcNMTQwOTA0 MTUwNzEwWhcNMjQwOTAxMTUwNzEwWjBJMQswCQYDVQQGEwJGUjEUMBIGA1UECgwLU1RPUk1TSElF TEQxJDAiBgNVBAMMG1N0b3Jtc2hpZWxkIFVzZXJzIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMKHBaAL/pVYovuOBYjd4DaxW9F07C4dxexEABdVZ2UwLTKCDu7jkTvw aECel2XxBsi7vH9DbM6roq22ynAMQiOSgwtNmeAsuUaNglk9+5KgLqGX1Hu9F3l/wWG7e/TFD/u/ MpjPgLzfogYKuTfWCas87QfR/GTLEIx+GhNPO57ehdbUiyZDAKs4867ZjzZAA0OFuJ9YuMhYl62e PnxhEpHzYoGzcWVurG2nSaL34izAy8IJFKhP45EHvcKXpRG3tCbsFwP6qeQn27CVQL3h0iVPaFfj Jtj/D+ywDXsTDjXx+DJEJZBfOCNmBn9dRzDZY/10iCADs+D5z/F5E4kfXO8CAwEAAaN2MHQwHQYD VR0OBBYEFKFthGyigIUFfHx1dYA0wRNbl9eBMB8GA1UdIwQYMBaAFLhCqfpnRPB/02GM7KXHUK60 veyjMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMBEGCWCGSAGG+EIBAQQEAwIBBjAN BgkqhkiG9w0BAQsFAAOCAgEAToL3OS3Ynp0+bYotvNFLqsEhhk0WLRfn2Dd6RDZJzhRayr4Hcvzq PnGdBJGcgz8MpXX5DZQdtT+qyHhy2jZ/BNXpX5onTtW79skTWsA3gAjhXbrK1/tWgFwGNVkmrykc 4yn8bZ5AfsXXGrOaXrwOkqS7rppRqWRwL0gzzabsBbdgDK8OhgQByG/irIvyqFUsunos2u7xk6Ew QuFktaXi6XD9IUMyFwFLojjALqJyPvUwsZKuvrW8yS0x3BD4IYVDnPkltrEzrVWDMprLz6CXD7FN umeK2sN+GTMezZ93A466ve+02c2yt0FaJg+x4naThUYPui/mQhNBlySZnIX9X4iv/9qAlAZW7CEN kJeBc6+uN74Utinu1D2mBK8tuW6HUD7LB/IecUjifq1nL1IPcwgOBZHgrAUszVCa3c1Bvfa2Sr1W bSNRxBcV9udYosD2SvDebw2YKqEvk/Ol856Bg5zRAlZ8xBqbF5bFcwuTq4qKxL//5Wp+kJrknHne 370Oag3X6hviM6ms9pfq18EGvl2NqHbLM8aMcQHnZWBZfEgX2UIzbPtDD7MVvY8h015KMiQ0QWD/ WisoABrmBBcBDKc3YnsT5ot/ZcuEdxLS/73KiKw8TD35NvkXW5CH6DNgPklRRhxhadydfyA/yTpf 4XmZD/zUig0v8h6PEmDL8ugwggP2MIIC3qADAgECAgUAhSjIwzANBgkqhkiG9w0BAQUFADBJMQsw CQYDVQQGEwJGUjEUMBIGA1UECgwLU1RPUk1TSElFTEQxJDAiBgNVBAMMG1N0b3Jtc2hpZWxkIFVz ZXJzIEF1dGhvcml0eTAeFw0xNDA5MDQxNTEwMzhaFw0xNTA5MDQxNTEwMzhaMHAxCzAJBgNVBAYT AkZSMRQwEgYDVQQKDAtTVE9STVNISUVMRDEaMBgGA1UEAwwRQWxleGFuZHJlIE1BUlRJTlMxLzAt BgkqhkiG9w0BCQEWIGFsZXhhbmRyZS5tYXJ0aW5zQHN0b3Jtc2hpZWxkLmV1MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAva7AtO0nbBUoYsRPeAP+85Lv4zx5bPdpxLuQVJmFJL6VDH28 Qxoxlq0j/3HGdfFR2sFe+utPledu6F79SCJDYRQ5ZQuS+TFgyvVzCSuVqpw6z0LQdTh4pouCh71B Bb8RSUXX2zx7Fu5IlSpLjGIf0prk1xrz/YyHJLQo2mSusnogi6hF2GsEVViUZtemK+uPqVToJ5oR AAJ4mU/Xl3aCOd7O3UzNT3T0clrfpNHKrcWcyqgE6g/gY/7NiJESRov3De8xzcczLxJFO51ODlaw y8yT1AHyWIDEkcbgX1Gk4s1ImXQDoq6pQEq2O5cIr59GlSd/YBq36Av6J3LGcmVnQwIDAQABo4G9 MIG6MB0GA1UdDgQWBBTL/0iutSuRsFLRxja4yiLlnMg2rTAfBgNVHSMEGDAWgBShbYRsooCFBXx8 dXWANMETW5fXgTAJBgNVHRMEAjAAMA4GA1UdDwEB/wQEAwID6DArBgNVHREEJDAigSBhbGV4YW5k cmUubWFydGluc0BzdG9ybXNoaWVsZC5ldTARBglghkgBhvhCAQEEBAMCBLAwHQYDVR0lBBYwFAYI KwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBQUAA4IBAQBHvjAZNyBp1pfsgV5R2oECDTsU vzfyvrj1CVTbOCXtg036DS7Tms7oybwsxUv6kQg9iq5eAklfyuz53VkL9IArm/iWn9QwecxANeMq k3Lc1LIMPhqqg6WZDze1G2PfYlwBkputKyQlhifQ8Xx6wJ+avt1lum5P1EFcQfG6zreyOxfai99a QcAxP1Ry3nXQMbUzP5UZkK0+PhYvy9mTv4b1vPWxeUMMXSO1TPXN1IkuPzzvR86MDHFO17l/aqJV Mr6Ea2A/deI7JilI48fb8jTsAaxBWL5RwrreXLXBjKDsEYzrANB4Kn/uQzkjnRM1NVRS+SMro3tk hzfdSmUFXs5tMYICAzCCAf8CAQEwUjBJMQswCQYDVQQGEwJGUjEUMBIGA1UECgwLU1RPUk1TSElF TEQxJDAiBgNVBAMMG1N0b3Jtc2hpZWxkIFVzZXJzIEF1dGhvcml0eQIFAIUoyMMwCQYFKw4DAhoF AKCBhzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTAzMTgxNzAx NDJaMCMGCSqGSIb3DQEJBDEWBBTXCYYWcWQdzVCBNC29qYuoERzUyjAoBgkqhkiG9w0BCQ8xGzAZ MAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzANBgkqhkiG9w0BAQEFAASCAQBAwZF+KzSmOygYeJW3 A1pS6U2rVDPPnJidgz84KzuzIC2NzjI9oA/DM4j/s8+XaWT0ABSPabnhh2zEZ+6CQimqOM4d2ZiL wfebxcTSi92hXDQiARJQSymE/o0HH6n/Eh2vR12ihMXYXgUqCnBFhbytVLMvzwbbedApf9vdP3w7 RUvO+ucfBo6V6hqznw2AjwYcxNbAp7eyAugQY1HMScoGq5ez/HH8TpwFR7mPs4cwx9fdJ7lK2wuP j/U0BAx8wGBelF+mDBFUKDr0+akpfi5iDPhXbZaFeiicfheO8ng64yTq2UcA00Bz1K/70OTrvpYo UY2V7bD+yupLNXKILUUIAAAAAAAA --nextPart7323170.F8fcClRqky-- From owner-freebsd-current@FreeBSD.ORG Wed Mar 18 19:04:15 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D650DCDE; Wed, 18 Mar 2015 19:04:15 +0000 (UTC) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 97F7BA16; Wed, 18 Mar 2015 19:04:15 +0000 (UTC) Received: by iecvj10 with SMTP id vj10so47758766iec.0; Wed, 18 Mar 2015 12:04:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=v8s+2MYVmgXGoW+F23xmBIpFE55P3VtT9ubAEQ1k7bk=; b=eECv/jgFX2zHeYIsifoOoy3+5uzdoz/3jgjqIFHuv49u4FFh/Mdh1bjOFSSRJrYhY4 6GOSUyx6tITxMuEEKS014PnAsHxge2ABu0nvVYST44mdPzyxL3MYgvf+uQJM68/hpnQG xrTYiWd6KSs0LLxB65C3G6WTYmTBZ7M8Udst6nauNIGexfCeyhVDtC1VYAGJSRw5oHtM BszXT7YlgyknUlhReRPgD3KZPBSCFt9oadkWnxpE7EsWtajIE+sLM6T/tT0jodn2AKyv Zm/qV65Zb5Io4lpaJt8BrSQf0rfoRngdeMhAl4uPYTk5PYX8AjDv2CacgprHWY8PYScb 6Hfw== MIME-Version: 1.0 X-Received: by 10.107.5.211 with SMTP id 202mr96260596iof.88.1426705454981; Wed, 18 Mar 2015 12:04:14 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.17.194 with HTTP; Wed, 18 Mar 2015 12:04:14 -0700 (PDT) In-Reply-To: <20150318175812.GA3512@dft-labs.eu> References: <20150313053203.GC9153@dft-labs.eu> <6376695.VOvhinOncy@ralph.baldwin.cx> <20150318175812.GA3512@dft-labs.eu> Date: Wed, 18 Mar 2015 12:04:14 -0700 X-Google-Sender-Auth: ij-RiKjbN8NHPFKq4S7mtmARUks Message-ID: Subject: Re: [PATCH] Convert the VFS cache lock to an rmlock From: Adrian Chadd To: Mateusz Guzik , John Baldwin , freebsd-current , Alan Cox , Ryan Stone Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 18 Mar 2015 19:04:15 -0000 [snip] Hihi! Do you have a shell script or something that I can run on the power8 box to see if nathan's pmap locking changes eliminate at least that global pmap lock we're seeing on amd64? -a From owner-freebsd-current@FreeBSD.ORG Wed Mar 18 19:28:08 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD3393D7; Wed, 18 Mar 2015 19:28:08 +0000 (UTC) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6EFBCD2C; Wed, 18 Mar 2015 19:28:08 +0000 (UTC) Received: by ieclw3 with SMTP id lw3so47631233iec.2; Wed, 18 Mar 2015 12:28:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=LlrzV+9gtZomexC5Y288eoQ7RUB/sQleqQ21Z0veGak=; b=EchrURWjVs1TOps0DmcXOtLL2o7ocjmMztgtqrblW7hUVvRjGWF+rOKH9Tgsh78DZs Svy5Lx2WDoyuLphfsfxSydtXj+YWmYlP1elnWkc6UkEVCmWyNtnfqkF1/Jg99bHjx9DM bD0lHAtT/VsjOc4OBLjlZVsXhnZoEH9jqYax+u7KOY5zr65xkwK7uTv4/XlZAYVRt1A2 8y1cXnL9YcNnVpTUXXDlCWEJ/vjVTmVu+6rq0OjXE13WoApxp7GPhJaw23Ve7ZTfj2Ra 4zd26l8kJ/H8v5t3pTJwqxet1pI1hqU+VNgH7D7VKzhe514aJsQ5k8hZ8HYog4ro0Yuv Lqsw== MIME-Version: 1.0 X-Received: by 10.50.132.66 with SMTP id os2mr9989911igb.6.1426706887866; Wed, 18 Mar 2015 12:28:07 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.17.194 with HTTP; Wed, 18 Mar 2015 12:28:07 -0700 (PDT) In-Reply-To: <3923303.nkjJO958qy@ralph.baldwin.cx> References: <2085699.T9kJlc0rkf@ralph.baldwin.cx> <3923303.nkjJO958qy@ralph.baldwin.cx> Date: Wed, 18 Mar 2015 12:28:07 -0700 X-Google-Sender-Auth: IzYsK92v7LrsmGHB_X5zzigDRtw Message-ID: Subject: Re: What parts of UMA are part of the stable ABI? From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Current , Ryan Stone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 18 Mar 2015 19:28:08 -0000 On 18 March 2015 at 08:23, John Baldwin wrote: > On Wednesday, March 18, 2015 11:19:21 AM Ryan Stone wrote: >> On Wed, Mar 18, 2015 at 10:24 AM, John Baldwin wrote: >> >> > I do think the normal zone callbacks passed to uma_zcreate() are too public >> > to change. Or at least, you would need to do some crazy ABI shim where you >> > have a uma_zcreate_new() that you map to uma_zcreate() via a #define for >> > the API, but include a legacy uma_zcreate() symbol that older modules can >> > call (and then somehow tag the old function pointers via an internal flag >> > in the zone and patch UMA to cast to the old function signatures for zones >> > with that flag). >> > >> >> I really wasn't clear here. I definitely don't think that changing the >> ctor, etc to accept a size_t is MFC'able, and I don't think that the >> problem (which is really only theoretical at this point) warrants an MFC to >> -stable. I was talking about potentially doing it in a separate commit to >> head, but that does leave -stable and head with a different API. This can >> be painful for downstream consumers to deal with, which is why I wanted >> comments. > > I actually think the API change to fix the zone callbacks is fine to change > in HEAD. I don't think that is too disruptive for folks who might be > sharing code across branches (they can use a local typedef to work around > it or some such). +1. This isn't exposed to userland, right? So I wouldn't worry about. Kernel progress can't be held back because we're afraid of kernel ABI changes that fix actual bugs. -adrian From owner-freebsd-current@FreeBSD.ORG Wed Mar 18 19:28:30 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 617AD4D8; Wed, 18 Mar 2015 19:28:30 +0000 (UTC) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 24B33D37; Wed, 18 Mar 2015 19:28:30 +0000 (UTC) Received: by igcau2 with SMTP id au2so1776141igc.1; Wed, 18 Mar 2015 12:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=wD4iXpau74h0+meCUQPUMUyJY1gjZO4hoh9WNdesDSI=; b=ixTYlhLs5ZKSCg0Rix9OhSY4h/bsHNW0cPgaBKsk1BAB952a57KzthDRd4q3soriZP ldzKJpR70xkmv/fKJe+yDk/WzAJTWNyH+5HciupiD2W/nYtls5Bfl/ohJlSvsAfJT+Gl 4RordA4YIL2YN6F3lYAUyf+gSCHl2ZdNbjpmR2agyIiLIS4g9mumzErsBnC6lhbyDZX/ zzv9GiglH++zb1W7BJr0A6vRdULG9mWLUcryOv2vLQmbFwZcWKkIouHpJCJxPqdY+5BA 5UtgFrIvCPQwkXDZ5Spr8yTmhCI4yqKKWNLjGTA/PA0fM8XnN09lnGAFg5/S+JHoN0Qx n5LA== MIME-Version: 1.0 X-Received: by 10.50.107.7 with SMTP id gy7mr9884726igb.49.1426706909511; Wed, 18 Mar 2015 12:28:29 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.17.194 with HTTP; Wed, 18 Mar 2015 12:28:29 -0700 (PDT) In-Reply-To: References: <2085699.T9kJlc0rkf@ralph.baldwin.cx> <3923303.nkjJO958qy@ralph.baldwin.cx> Date: Wed, 18 Mar 2015 12:28:29 -0700 X-Google-Sender-Auth: fJuWltjLjd4CuKuCtwNHAbxKhqQ Message-ID: Subject: Re: What parts of UMA are part of the stable ABI? From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Current , Ryan Stone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 18 Mar 2015 19:28:30 -0000 [snip] So yes, I'd like to see this in -HEAD sooner rather than later. You did the great work of chasing it down, so let's get it in -HEAD. :) -a From owner-freebsd-current@FreeBSD.ORG Wed Mar 18 23:33:50 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E64EF2C0; Wed, 18 Mar 2015 23:33:50 +0000 (UTC) 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 9A50BE14; Wed, 18 Mar 2015 23:33:50 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-255-201.lns20.per4.internode.on.net [121.45.255.201]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t2INXj7p049235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 18 Mar 2015 16:33:48 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <550A0B53.9020201@freebsd.org> Date: Thu, 19 Mar 2015 07:33:39 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Adrian Chadd , John Baldwin Subject: Re: What parts of UMA are part of the stable ABI? References: <2085699.T9kJlc0rkf@ralph.baldwin.cx> <3923303.nkjJO958qy@ralph.baldwin.cx> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Ryan Stone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 18 Mar 2015 23:33:51 -0000 On 3/19/15 3:28 AM, Adrian Chadd wrote: > On 18 March 2015 at 08:23, John Baldwin wrote: >> On Wednesday, March 18, 2015 11:19:21 AM Ryan Stone wrote: >>> On Wed, Mar 18, 2015 at 10:24 AM, John Baldwin wrote: >>> >>>> I do think the normal zone callbacks passed to uma_zcreate() are too public >>>> to change. Or at least, you would need to do some crazy ABI shim where you >>>> have a uma_zcreate_new() that you map to uma_zcreate() via a #define for >>>> the API, but include a legacy uma_zcreate() symbol that older modules can >>>> call (and then somehow tag the old function pointers via an internal flag >>>> in the zone and patch UMA to cast to the old function signatures for zones >>>> with that flag). >>>> >>> I really wasn't clear here. I definitely don't think that changing the >>> ctor, etc to accept a size_t is MFC'able, and I don't think that the >>> problem (which is really only theoretical at this point) warrants an MFC to >>> -stable. I was talking about potentially doing it in a separate commit to >>> head, but that does leave -stable and head with a different API. This can >>> be painful for downstream consumers to deal with, which is why I wanted >>> comments. >> I actually think the API change to fix the zone callbacks is fine to change >> in HEAD. I don't think that is too disruptive for folks who might be >> sharing code across branches (they can use a local typedef to work around >> it or some such). > +1. This isn't exposed to userland, right? So I wouldn't worry about. > > Kernel progress can't be held back because we're afraid of kernel ABI > changes that fix actual bugs. I don't think we've ever aid we'd maintain kernel internal ABI across different code lines. We have said we'd try keep changes to some things "easy to fix" (e.g. network driver API) but a recompile is pretty much always needed. > > > > -adrian > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://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 Mar 18 23:55:50 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A74A39E7 for ; Wed, 18 Mar 2015 23:55:50 +0000 (UTC) Received: from forward4l.mail.yandex.net (forward4l.mail.yandex.net [IPv6:2a02:6b8:0:1819::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5F61C7A for ; Wed, 18 Mar 2015 23:55:50 +0000 (UTC) Received: from smtp3h.mail.yandex.net (smtp3h.mail.yandex.net [84.201.186.20]) by forward4l.mail.yandex.net (Yandex) with ESMTP id 952431441647; Thu, 19 Mar 2015 02:55:38 +0300 (MSK) Received: from smtp3h.mail.yandex.net (localhost [127.0.0.1]) by smtp3h.mail.yandex.net (Yandex) with ESMTP id 179231B42CB6; Thu, 19 Mar 2015 02:55:37 +0300 (MSK) Received: from unknown (unknown [2a02:6b8:0:6::bb]) by smtp3h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id PVtnZki0cj-tbMqZbeD; Thu, 19 Mar 2015 02:55:37 +0300 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1426722937; bh=asURlY1F4rU/eLc3IpKsoMheZAIzsmjFHJt+r54jtRI=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=GqnhC0yDjlvvoN4DU5l4a/bQCF7JyLPAuDM7EbEWSkhFCy1TimZhbHwGWS+SrGkra FvcpcDcLiU4l8UTXcBqIJoW42cX1vuyTaAXlzxyTJIniYI/t1+SIuEMeMZa04C1uiS WM6YGB1NfhviL5KVHXtwnOS1Er++BS7H4ALHnTLY= Authentication-Results: smtp3h.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <550A1027.4010807@yandex.ru> Date: Thu, 19 Mar 2015 02:54:15 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Alexandre Martins , 'freebsd-current' Subject: Re: Possible race in IPv6 References: <95157304.ieSUkydfeD@pc-alex> In-Reply-To: <95157304.ieSUkydfeD@pc-alex> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 18 Mar 2015 23:55:50 -0000 On 18.03.2015 20:01, Alexandre Martins wrote: > Dear, > > I'm facing some crash around manipulations of IPv6 address. > > I already found that the commit 275593 will fix my issue. > > However, after some code review, i see a possible race in the function > nd6_na_input: > > https://svnweb.freebsd.org/base/head/sys/netinet6/nd6_nbr.c?annotate=279676#l750 > > =-=-=-=-=-=-=-=-=-= > if (ifa > && (((struct in6_ifaddr *)ifa)->ia6_flags & IN6_IFF_TENTATIVE)) { > ifa_free(ifa); > nd6_dad_na_input(ifa); > goto freeit; > } > =-=-=-=-=-=-=-=-=-= > > As you can see, the function drop its reference on the address and pass it to > nd6_dad_na_input. > It should be better to release the reference after the call. > > What about you? Hi, Actually nd6_dad_na_input() uses ifa only for addresses comparison, so there shouldn't be some negative impact in this race. But for the better code logic I'll commit this change. Thanks. -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Thu Mar 19 11:31:06 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F4DDB9; Thu, 19 Mar 2015 11:31:06 +0000 (UTC) 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 654DD1B7; Thu, 19 Mar 2015 11:31:06 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4BC90B945; Thu, 19 Mar 2015 07:31:04 -0400 (EDT) From: John Baldwin To: Adrian Chadd Subject: Re: What parts of UMA are part of the stable ABI? Date: Wed, 18 Mar 2015 18:16:21 -0400 Message-ID: <5300497.pLlpQqgG2T@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: References: <3923303.nkjJO958qy@ralph.baldwin.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 19 Mar 2015 07:31:04 -0400 (EDT) Cc: FreeBSD Current , Ryan Stone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 19 Mar 2015 11:31:06 -0000 On Wednesday, March 18, 2015 12:28:07 PM Adrian Chadd wrote: > On 18 March 2015 at 08:23, John Baldwin wrote: > > On Wednesday, March 18, 2015 11:19:21 AM Ryan Stone wrote: > >> On Wed, Mar 18, 2015 at 10:24 AM, John Baldwin wrote: > >> > >> > I do think the normal zone callbacks passed to uma_zcreate() are too public > >> > to change. Or at least, you would need to do some crazy ABI shim where you > >> > have a uma_zcreate_new() that you map to uma_zcreate() via a #define for > >> > the API, but include a legacy uma_zcreate() symbol that older modules can > >> > call (and then somehow tag the old function pointers via an internal flag > >> > in the zone and patch UMA to cast to the old function signatures for zones > >> > with that flag). > >> > > >> > >> I really wasn't clear here. I definitely don't think that changing the > >> ctor, etc to accept a size_t is MFC'able, and I don't think that the > >> problem (which is really only theoretical at this point) warrants an MFC to > >> -stable. I was talking about potentially doing it in a separate commit to > >> head, but that does leave -stable and head with a different API. This can > >> be painful for downstream consumers to deal with, which is why I wanted > >> comments. > > > > I actually think the API change to fix the zone callbacks is fine to change > > in HEAD. I don't think that is too disruptive for folks who might be > > sharing code across branches (they can use a local typedef to work around > > it or some such). > > +1. This isn't exposed to userland, right? So I wouldn't worry about. > > Kernel progress can't be held back because we're afraid of kernel ABI > changes that fix actual bugs. I think that's a bit too cavalier. Just because it fixes a bug doesn't mean we don't care about the ABI implications in general. (That is, I think your blanket implication that it's ok to break the kernel ABI at anytime if the change fixes a bug is wrong.) It is possible to fix bugs while preserving the ABI, it just requires more work. Our ABI constraints are not just for userland, we do also try to preserve the ABI of a subset of kernel symbols as well (mostly those used by device drivers). The stickler though is which symbols fall into that category since the line for the kernel is much fuzzier than for userland. In general I would err on the side of caution and provide shims if they are feasible. I do think that the uma_alloc case is obscure enough to not be one we care about for ABI compat. I couldn't find the bpf example I was thinking of earlier, but this commit includes the shim method I described previously to preserve the ABI for old modules while fixing the API for new ones (and this was to fix a bug): https://svnweb.freebsd.org/base?view=revision&revision=196006 -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Mar 19 14:01:10 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2BA2D940; Thu, 19 Mar 2015 14:01:10 +0000 (UTC) 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 F325B60C; Thu, 19 Mar 2015 14:01:09 +0000 (UTC) Received: from new-host-4.home (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 56B92B926; Thu, 19 Mar 2015 10:01:08 -0400 (EDT) Message-ID: <550AD6A3.1020406@FreeBSD.org> Date: Thu, 19 Mar 2015 10:01:07 -0400 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Julian Elischer , Adrian Chadd Subject: Re: What parts of UMA are part of the stable ABI? References: <2085699.T9kJlc0rkf@ralph.baldwin.cx> <3923303.nkjJO958qy@ralph.baldwin.cx> <550A0B53.9020201@freebsd.org> In-Reply-To: <550A0B53.9020201@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 19 Mar 2015 10:01:08 -0400 (EDT) Cc: FreeBSD Current , Ryan Stone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 19 Mar 2015 14:01:10 -0000 On 3/18/15 7:33 PM, Julian Elischer wrote: > On 3/19/15 3:28 AM, Adrian Chadd wrote: >> On 18 March 2015 at 08:23, John Baldwin wrote: >>> On Wednesday, March 18, 2015 11:19:21 AM Ryan Stone wrote: >>>> On Wed, Mar 18, 2015 at 10:24 AM, John Baldwin wrote: >>>> >>>>> I do think the normal zone callbacks passed to uma_zcreate() are too public >>>>> to change. Or at least, you would need to do some crazy ABI shim where you >>>>> have a uma_zcreate_new() that you map to uma_zcreate() via a #define for >>>>> the API, but include a legacy uma_zcreate() symbol that older modules can >>>>> call (and then somehow tag the old function pointers via an internal flag >>>>> in the zone and patch UMA to cast to the old function signatures for zones >>>>> with that flag). >>>>> >>>> I really wasn't clear here. I definitely don't think that changing the >>>> ctor, etc to accept a size_t is MFC'able, and I don't think that the >>>> problem (which is really only theoretical at this point) warrants an MFC to >>>> -stable. I was talking about potentially doing it in a separate commit to >>>> head, but that does leave -stable and head with a different API. This can >>>> be painful for downstream consumers to deal with, which is why I wanted >>>> comments. >>> I actually think the API change to fix the zone callbacks is fine to change >>> in HEAD. I don't think that is too disruptive for folks who might be >>> sharing code across branches (they can use a local typedef to work around >>> it or some such). >> +1. This isn't exposed to userland, right? So I wouldn't worry about. >> >> Kernel progress can't be held back because we're afraid of kernel ABI >> changes that fix actual bugs. > > I don't think we've ever aid we'd maintain kernel internal ABI across > different code lines. > We have said we'd try keep changes to some things > "easy to fix" (e.g. network driver API) but a recompile is pretty much > always needed. This is not about maintaining the ABI across branches. This is about whether or not a change can be merged to stable/10 and what kinds of ABI breakages are acceptable in stable/10. As I said three quote levels up, I am _in favor_ of changing the API in HEAD and that that level of API change is not too disruptive for folks who try to keep a single code base that compiles across multiple branches. For these folks, ABI changes don't really matter, but API changes do have to be coped with. For a prime example, grep for FreeBSD_version in the Intel NIC drivers (several storage drivers from external vendors such as twa and hpt* also have various local compat shims to handle API changes). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Mar 19 14:23:22 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E563ABD for ; Thu, 19 Mar 2015 14:23:21 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8927A8E9 for ; Thu, 19 Mar 2015 14:23:20 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id t2JENJXp032464 for ; Thu, 19 Mar 2015 07:23:19 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id t2JENJJr032463 for current@freebsd.org; Thu, 19 Mar 2015 07:23:19 -0700 (PDT) (envelope-from david) Date: Thu, 19 Mar 2015 07:23:19 -0700 From: David Wolfskill To: current@freebsd.org Subject: Early panic at boot: exclusive sleep mutex hdac1 (HDA driver mutex) ... Message-ID: <20150319142319.GH1215@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5MRs3DbAxHy5wbhc" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 19 Mar 2015 14:23:22 -0000 --5MRs3DbAxHy5wbhc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable As noted in a thread on -mobile yesterday, I'm replacing my long-serving Dell M4400 laptop with a newer model (M4800) -- you can see -mobile archives for additional details if you're interested. What prompted this note was: * When I tried to boot head/i386, I got a rather quick panic (well before any file systems were mounted -- and before any swap space was allocated, so I didn't have a place for a crash dump. * Much to my (positive) surprise, when I looked at /var/run/dmesg.bo0t (after having rebooted from my stable/10 slice, and in the process of reviewing my kernel config to see if I could configure around the panic)), I found some verbose boot messages from the attempted boot under head. So that latter actually provided a bit of information that might be useful for debugging, so I copied it to , as dmesg.boot. Here's an excerpt from it, in case that's useful. (I didn't want to spam the world with the whole 74KB thing....): FreeBSD 11.0-CURRENT #1544 r280166M/280167:1100065: Tue Mar 17 07:04:10 PD= T 2015 root@g1-251.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 FreeBSD clang version 3.6.0 (tags/RELEASE_360/final 230434) 20150225 WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. MEMGUARD DEBUGGING ALLOCATOR INITIALIZED: MEMGUARD map base: 0xc7c00000 MEMGUARD map size: 104964 KBytes VT: running with driver "vga". CPU: Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz (2793.59-MHz 686-class CPU) Origin=3D"GenuineIntel" Id=3D0x306c3 Family=3D0x6 Model=3D0x3c Steppi= ng=3D3 Features=3D0xbfebfbff Features2=3D0x7ffafbff AMD Features=3D0x2c100000 AMD Features2=3D0x21 Structured Extended Features=3D0x27ab XSAVE Features=3D0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory =3D 8589934592 (8192 MB) avail memory =3D 3368755200 (3212 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard =2E.. hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 hdaa0: Subsystem ID: 0x102805cc hdaa0: NumGPIO=3D0 NumGPO=3D0 NumGPI=3D0 GPIWake=3D0 GPIUnsol=3D0 hdaa0: Original pins configuration: hdaa0: nid 0x as seq device conn jack loc color misc hdaa0: 4 585600f0 15 0 Digital-out None Digital 0x18 Unknown 0 hdaa0: 5 185600f0 15 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa0: 6 585600f0 15 0 Digital-out None Digital 0x18 Unknown 0 hdaa0: 7 185600f0 15 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa0: Patched pins configuration: hdaa0: nid 0x as seq device conn jack loc color misc hdaa0: 4 585600f0 15 0 Digital-out None Digital 0x18 Unknown 0 D= ISA hdaa0: 5 185600f0 15 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa0: 6 585600f0 15 0 Digital-out None Digital 0x18 Unknown 0 D= ISA hdaa0: 7 185600f0 15 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa0: 2 associations found: hdaa0: Association 0 (15) out: hdaa0: Pin nid=3D5 seq=3D0 hdaa0: Association 1 (15) out: hdaa0: Pin nid=3D7 seq=3D0 hdaa0: Tracing association 0 (15) hdaa0: Pin 5 traced to DAC 8 hdaa0: Association 0 (15) trace succeeded hdaa0: Tracing association 1 (15) hdaa0: Pin 7 traced to DAC 9 hdaa0: Association 1 (15) trace succeeded hdaa0: Looking for additional DAC for association 0 (15) hdaa0: Looking for additional DAC for association 1 (15) hdaa0: Tracing input monitor hdaa0: Tracing other input monitors hdaa0: Tracing beeper hdaa0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref pcm0: at nid 5 on hdaa0 pcm0: Playback: pcm0: Stream cap: 0x00000005 AC3 PCM pcm0: PCM cap: 0x000e07f0 16 20 24 bits, 32 44 48 88 96 176 192 KHz pcm0: DAC: 8 pcm0:=20 pcm0: nid=3D5 [pin: Digital-out (Jack)] pcm0: + <- nid=3D8 [audio output] [src: pcm] pcm0:=20 pcm0: Mixer "vol" -> "none": child=3D0x00000010 pcm0: Mixer "pcm": parent=3D"vol" pcm0: Soft PCM mixer ENABLED pcm0: Playback channel matrix is: unknown, assuming 7.1 (disconnected) pcm1: at nid 7 on hdaa0 pcm1: Playback: pcm1: Stream cap: 0x00000005 AC3 PCM pcm1: PCM cap: 0x000e07f0 16 20 24 bits, 32 44 48 88 96 176 192 KHz pcm1: DAC: 9 pcm1:=20 pcm1: nid=3D7 [pin: Digital-out (Jack)] pcm1: + <- nid=3D9 [audio output] [src: pcm] pcm1:=20 pcm1: Mixer "vol" -> "none": child=3D0x00000010 pcm1: Mixer "pcm": parent=3D"vol" pcm1: Soft PCM mixer ENABLED pcm1: Playback channel matrix is: unknown, assuming 7.1 (disconnected) hdacc1: at cad 0 on hdac1 hdaa1: at nid 1 on hdacc1 hdaa1: Subsystem ID: 0x102805cc hdaa1: NumGPIO=3D5 NumGPO=3D0 NumGPI=3D0 GPIWake=3D0 GPIUnsol=3D1 hdaa1: GPIO0: disabled hdaa1: GPIO1: disabled hdaa1: GPIO2: disabled hdaa1: GPIO3: disabled hdaa1: GPIO4: disabled hdaa1: Original pins configuration: hdaa1: nid 0x as seq device conn jack loc color misc hdaa1: 18 90a60140 4 0 Mic Fixed Digital Internal Unknown 1 hdaa1: 19 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa1: 20 90170110 1 0 Speaker Fixed Analog Internal Unknown 1 hdaa1: 21 0221401f 1 15 Headphones Jack 1/8 Front Green 0 hdaa1: 22 01014020 2 0 Line-out Jack 1/8 Rear Green 0 hdaa1: 24 02a19031 3 1 Mic Jack 1/8 Front Pink 0 hdaa1: 25 01a1903e 3 14 Mic Jack 1/8 Rear Pink 0 hdaa1: 26 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa1: 27 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa1: 29 40700001 0 1 Modem-handset None Unknown 0x00 Unknown 0 hdaa1: 30 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa1: Patching widget caps nid=3D29 0x00400400 -> 0x00700400 hdaa1: Patched pins configuration: hdaa1: nid 0x as seq device conn jack loc color misc hdaa1: 18 90a60140 4 0 Mic Fixed Digital Internal Unknown 1 hdaa1: 19 411111f0 15 0 Speaker None 1/8 Rear Black 1 D= ISA hdaa1: 20 90170110 1 0 Speaker Fixed Analog Internal Unknown 1 hdaa1: 21 0221401f 1 15 Headphones Jack 1/8 Front Green 0 hdaa1: 22 01014020 2 0 Line-out Jack 1/8 Rear Green 0 hdaa1: 24 02a19031 3 1 Mic Jack 1/8 Front Pink 0 hdaa1: 25 01a1903e 3 14 Mic Jack 1/8 Rear Pink 0 hdaa1: 26 411111f0 15 0 Speaker None 1/8 Rear Black 1 D= ISA hdaa1: 27 411111f0 15 0 Speaker None 1/8 Rear Black 1 D= ISA hdaa1: 30 411111f0 15 0 Speaker None 1/8 Rear Black 1 D= ISA Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex hdac1 (HDA driver mutex) r =3D 0 (0xcffa8c80) locked = @ /usr/src/sys/dev/sound/pci/hda/hdaa.c:1571 KDB: stack backtrace: db_trace_self_wrapper(c112e1d4,0,0,3,c14e1064,...) at 0xc0531bca =3D db_tra= ce_self_wrapper+0x2a/frame 0xc2420500 kdb_backtrace(c1132951,0,cffa8c80,c10e0d7e,623,...) at 0xc0b6233d =3D kdb_b= acktrace+0x2d/frame 0xc2420568 witness_warn(5,0,c12eb2f1,c1562788,c116b27a,...) at 0xc0b851cf =3D witness_= warn+0x40f/frame 0xc24205b8 trap_pfault(d05c8077,2,c242067c,c0e0222b,c2792710,...) at 0xc0fb6098 =3D tr= ap_pfault+0x58/frame 0xc2420630 trap(c242077c) at 0xc0fb5a0e =3D trap+0x6be/frame 0xc2420770 calltrap() at 0xc0f9fefc =3D calltrap+0x6/frame 0xc2420770 --- trap 0xc, eip =3D 0xc08cbfff, esp =3D 0xc24207bc, ebp =3D 0xc24208d4 --- hdaa_configure(d058b880,c10e13ec,1e,411111f0,f,...) at 0xc08cbfff =3D hdaa_= configure+0x14af/frame 0xc24208d4 hdaa_attach(d058b880,d058b880,c2420a00,c112d5c6,80000003,...) at 0xc08c7959= =3D hdaa_attach+0x12c9/frame 0xc24209c0 device_attach(d058b880,4,c112cfa0,afd,d052de00,...) at 0xc0b57527 =3D devic= e_attach+0x457/frame 0xc2420a14 bus_generic_attach(d058bb80,cfd0ce80,ffffffff,1be,c0b588ac,...) at 0xc0b585= 6f =3D bus_generic_attach+0x4f/frame 0xc2420a30 hdacc_attach(d058bb80,d058bb80,c2420ab0,c112d5c6,80000003,...) at 0xc08d9cf= b =3D hdacc_attach+0x36b/frame 0xc2420a70 device_attach(d058bb80,4,c112cfa0,afd,cffaac00,...) at 0xc0b57527 =3D devic= e_attach+0x457/frame 0xc2420ac8 bus_generic_attach(cfd94680,0,ffffffff,5f3,c14ad45c,...) at 0xc0b5856f =3D = bus_generic_attach+0x4f/frame 0xc2420ae4 hdac_attach2(cffaac00,0,c112ccb7,75,cf684690,...) at 0xc08d91e6 =3D hdac_at= tach2+0x2f6/frame 0xc2420b2c run_interrupt_driven_config_hooks(0,c1120963,48,c2420b9c,d0140b00,...) at 0= xc0b53244 =3D run_interrupt_driven_config_hooks+0x84/frame 0xc2420b48 boot_run_interrupt_driven_config_hooks(0,0,0,0,cf684710,...) at 0xc0b534a6 = =3D boot_run_interrupt_driven_config_hooks+0x16/frame 0xc2420bcc mi_startup() at 0xc0ac8fd7 =3D mi_startup+0x107/frame 0xc2420bf8 begin() at 0xc04b808d =3D begin+0x22 Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0xd05c8077 fault code =3D supervisor read, page not present instruction pointer =3D 0x20:0xc08cbfff stack pointer =3D 0x28:0xc24207bc frame pointer =3D 0x28:0xc24208d4 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 0 (swapper) =2E... Peace, david --=20 David H. Wolfskill david@catwhisker.org Those who murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --5MRs3DbAxHy5wbhc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJVCtvWXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk77eAP/1Q+Fe+8hwoLNsaV4oZzy0bF ZV90R1GVf+8LAwNa2x0UAKXQQYJ0xqiZfWuwOnBaNkOihIKTgcw8Qpe5FJ+T7/aS gAZvYbqOHDIyfoha2sA1kGVVa6b+S2FMCq3nlFUy0nUuM0QpumAp66cM78Y/rd7N JbWabf1+OauCbuenXCi1OMY820ACaTc1JN8tAamzCkwAVeiCFG2sr5yQdFp5ITvP pgfFWKjoTC+4NJ6FHcJxO85shVeHVmJggsFJ9m28DqnjHXJd9CdPLozSzti/V9if M79v9tX4Ri9KzZAEhvttpXeiiRsO958+wIFq28L0zucdY5mSBZuvQoRtHC8cPgC/ mdqFCFItRZYfzeEgmOYl/r2b6xmdlmsK7yOxk7RrxfHmdQ9eSBkzLCJ6A09SqLNU p8DAce4vvEJunFpo7yF5JJXi0CSMpY2FT3bkstUb/Ivcq4Mvz0ETqXTqljYk6XEn AwW7y/U1TFNqetgOAS+KQaXBG9sQteymJNXlln6kM3/Bv9XZBP0hyKNL4VvnWdrD pf50VBac6P0EmOuCBboy7kH+f04OaZy3AQBmvnLmOrSr2baNXuePzO7bWkjc0e7N +ny0ipzXJXQjF9KFSIGR+2lG71Bhk6rxEHEt4cBCZDz8UANC+ADycjbWqf5Edpp8 aftoZIUdYhOf3l1nywzV =UOws -----END PGP SIGNATURE----- --5MRs3DbAxHy5wbhc-- From owner-freebsd-current@FreeBSD.ORG Thu Mar 19 14:56:58 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 62353C15 for ; Thu, 19 Mar 2015 14:56:58 +0000 (UTC) Received: from courriel.site.uottawa.ca (eecsmail.engineering.uottawa.ca [137.122.24.224]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.site.uottawa.ca", Issuer "PositiveSSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0E548CB0 for ; Thu, 19 Mar 2015 14:56:57 +0000 (UTC) Received: from admin16.site.uottawa.ca (admin16.site.uottawa.ca [137.122.90.250]) (authenticated bits=0) by courriel.site.uottawa.ca (8.14.5/8.14.5) with ESMTP id t2JEY43A013235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 19 Mar 2015 10:34:04 -0400 (EDT) (envelope-from kwhite@site.uottawa.ca) Date: Thu, 19 Mar 2015 10:34:04 -0400 (EDT) From: Keith White To: freebsd-current@freebsd.org Subject: panic: UMA: Increase vm.boot_pages on Dell R920 r279210 Message-ID: <20150319095306.C7719@admin16.site.uottawa.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 19 Mar 2015 14:56:58 -0000 I (temporarily) have a Dell R920 with 1T RAM, and 4 CPUs with 15 cores. I get a kernel panic when attempting to boot FreeBSD-11.0-CURRENT-amd64-20150223-r279210-memstick.img: ... Dell System PowerEdge R920 www.dell.com ... Four 2.30 GHz Fifteen-core Processors, L2/L3 Cache:3.75 MB/30 MB System running at 2.30 GHz System Bus Speed: 8.00 GT/s System Memory Size: 1024.0 GB, System Memory Speed: 1333 MHz, Voltage: 1.35V ... Booting... GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2015 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #0 r279210: Mon Feb 23 19:14:12 UTC 2015 root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.5.1 (tags/RELEASE_351/final 225668) 20150115 WARNING: WITNESS option enabled, expect reduced performance. panic: UMA: Increase vm.boot_pages cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffffff81bfe7a0 vpanic() at vpanic+0x189/frame 0xffffffff81bfe820 panic() at panic+0x43/frame 0xffffffff81bfe880 startup_alloc() at startup_alloc+0x1da/frame 0xffffffff81bfe8d0 keg_alloc_slab() at keg_alloc_slab+0xce/frame 0xffffffff81bfe930 keg_fetch_slab() at keg_fetch_slab+0x171/frame 0xffffffff81bfe980 zone_fetch_slab() at zone_fetch_slab+0x6e/frame 0xffffffff81bfe9c0 zone_import() at zone_import+0x40/frame 0xffffffff81bfea30 zone_alloc_item() at zone_alloc_item+0x36/frame 0xffffffff81bfea70 uma_zcreate() at uma_zcreate+0x8a/frame 0xffffffff81bfeb10 vm_map_startup() at vm_map_startup+0x52/frame 0xffffffff81bfeb30 vm_mem_init() at vm_mem_init+0x31/frame 0xffffffff81bfeb50 mi_startup() at mi_startup+0x118/frame 0xffffffff81bfeb70 btext() at btext+0x2c KDB: enter: panic [ thread pid 0 tid 0 ] Stopped at kdb_enter+0x3e: movq $0,kdb_why db> I tried the suggestion "Increase vm.boot_pages" but am unsure how much. I tried doubling to 128, and even excessive(?) values like 102400; but got the same panic. If, however, I reduce the number of active cores to 10 in the BIOS, I am able to boot with the original value of vm.boot_pages. I have serial console and sneaker net access for the next couple of days. Any suggestions? ...keith -- Keith White, genie.uottawa.ca engineering.uottawa.ca kwhite@uottawa.ca [+1 613 562 5800 x6681] From owner-freebsd-current@FreeBSD.ORG Thu Mar 19 18:02:44 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6C65BF3E; Thu, 19 Mar 2015 18:02:44 +0000 (UTC) Received: from pp1.rice.edu (proofpoint1.mail.rice.edu [128.42.201.100]) (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 324DFBEE; Thu, 19 Mar 2015 18:02:44 +0000 (UTC) Received: from pps.filterd (pp1.rice.edu [127.0.0.1]) by pp1.rice.edu (8.14.5/8.14.5) with SMTP id t2JI2hXk007057; Thu, 19 Mar 2015 13:02:43 -0500 Received: from mh1.mail.rice.edu (mh1.mail.rice.edu [128.42.201.20]) by pp1.rice.edu with ESMTP id 1t6v5h9871-1; Thu, 19 Mar 2015 13:02:42 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh1.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh1.mail.rice.edu (Postfix) with ESMTPSA id C65AC4602A2; Thu, 19 Mar 2015 13:02:37 -0500 (CDT) Message-ID: <550B0F3D.8070500@rice.edu> Date: Thu, 19 Mar 2015 13:02:37 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Mateusz Guzik , John Baldwin , freebsd-current@freebsd.org, alc@freebsd.org, Ryan Stone Subject: Re: [PATCH] Convert the VFS cache lock to an rmlock References: <20150313053203.GC9153@dft-labs.eu> <6376695.VOvhinOncy@ralph.baldwin.cx> <20150318175812.GA3512@dft-labs.eu> In-Reply-To: <20150318175812.GA3512@dft-labs.eu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=11 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1503190161 X-Proofpoint-SSN: Sensitivity3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 19 Mar 2015 18:02:44 -0000 On 03/18/2015 12:58, Mateusz Guzik wrote: > On Wed, Mar 18, 2015 at 10:17:22AM -0400, John Baldwin wrote: >> On Friday, March 13, 2015 06:32:03 AM Mateusz Guzik wrote: >>> On Thu, Mar 12, 2015 at 06:13:00PM -0500, Alan Cox wrote: >>>> Below is partial results from a profile of a parallel (-j7) "buildwo= rld" on >>>> a 6-core machine that I did after the introduction of pmap_advise, s= o this >>>> is not a new profile. The results are sorted by total waiting time = and >>>> only the top 20 entries are listed. >>>> >>> Well, I ran stuff on lynx2 in the zoo on fresh -head with debugging >>> disabled (MALLOC_PRODUCTION included) and got quite different results= =2E >>> >>> The machine is Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz >>> 2 package(s) x 10 core(s) x 2 SMT threads >>> >>> 32GB of ram >>> >>> Stuff was built in a chroot with world hosted on zfs. >>> >>>> max wait_max total wait_total count avg wait_a= vg >>>> cnt_hold cnt_lock name >>>> >>>> 1027 208500 16292932 1658585700 5297163 3 313= 0 >>>> 3313855 kern/vfs_cache.c:629 (rw:Name Cache) >>>> >>>> 208564 186514 19080891106 1129189627 355575930 53 3= 0 >>>> 1323051 kern/vfs_subr.c:2099 (lockmgr:ufs) >>>> >>>> 169241 148057 193721142 419075449 13819553 14 30= 0 >>>> 110089 kern/vfs_subr.c:2210 (lockmgr:ufs) >>>> >>>> 187092 191775 1923061952 257319238 328416784 5 0= 0 >>>> 5106537 kern/vfs_cache.c:488 (rw:Name Cache) >>>> >>> make -j 12 buildworld on freshly booted system (i.e. the most namecac= he insertions): >>> >>> 32 292 3042019 33400306 8419725 0 3 = 0 2578026 kern/sys_pipe.c:1438 (sleep mutex:pipe mutex) >>> 170608 152572 642385744 27054977 202605015 3 0 = 0 1306662 kern/vfs_subr.c:2176 (lockmgr:zfs) >> You are using ZFS, Alan was using UFS. It would not surprise me that = those >> would perform quite differently, and it would not surprise me that UFS= is >> more efficient in terms of its interactions with the VM. >> > This is lots of forks + execs and page queue has only one lock. > > Fwiw, ufs world backed by dedidacted parition, other conditions unchang= ed > > First build: > 52 411 3327572 36528102 8508545 0 4 0= 2587337 kern/sys_pipe.c:1438 (sleep mutex:pipe mutex) > 308102 308099 430348158 36163333 203246241 2 0 0= 459200 kern/vfs_subr.c:2176 (lockmgr:ufs) > 78 818 44308162 29968440 165009282 0 0 0= 22053854 vm/vm_page.c:1502 (sleep mutex:vm page free queue) > 48 238 18872405 28456578 164327020 0 0 0= 22512151 vm/vm_page.c:2294 (sleep mutex:vm page free queue) > 208 1486 69780863 17484511 144970085 0 0 0= 134429 amd64/amd64/pmap.c:4204 (rw:pmap pv global) > 52 1263 19390169 8186840 142392234 0 0 0= 11151398 vm/vm_page.c:2053 (sleep mutex:vm active pagequeue) > 27 1801 19754927 8092312 142403798 0 0 0= 9993164 vm/vm_page.c:2097 (sleep mutex:vm active pagequeue) > 1145 1300 19872450 7158951 7690094 2 0 0= 269930 vm/vm_fault.c:785 (rw:vm object) > 25579 1636 10955717 5962336 12620413 0 0 0= 96691 vm/vm_map.c:2883 (rw:vm object) > 39 54994 1428266 5141221 368787 3 13 0= 13391 kern/kern_exec.c:590 (lockmgr:ufs) > 311470 311513 67241105 3971357 30997102 2 0 0= 5094 kern/vfs_lookup.c:509 (lockmgr:ufs) > 55 568 64300400 3821394 214921016 0 0 0= 2699822 kern/vfs_cache.c:487 (rw:Name Cache) > 14 2224 31486 3784823 266762 0 14 0= 43516 amd64/amd64/pmap.c:3767 (rw:pmap pv global) This is pmap_remove_all, which is the only amd64 pmap function that still acquires the global lock in exclusive mode. This entry shows that we're calling pmap_remove_all about 80% more often than we used to and this is causing pmap_enter (line 4204) above to wait. I'm curious to see what the profile looks like if you change this acquisition to a read acquire. Such a change hasn't been committed because of a race involving the completion of TLB shootdown. However, it's extremely improbable that the race will come out badly for a parallel "buildworld". > 15 1179 184521 2651974 2126398 0 1 0= 31955 vm/vm_object.c:646 (rw:vm object) > 43267 54635 56190811 2228815 368787 152 6 0= 10399 kern/imgact_elf.c:829 (lockmgr:ufs) > 1802 3276 55104622 2042552 142404165 0 0 0= 543434 vm/vm_fault.c:997 (sleep mutex:vm page) > 29 54 50897307 1792095 199350363 0 0 0= 2305326 kern/vfs_cache.c:668 (sleep mutex:vnode interlock) > 1051 1252 3640803 1792074 1030592 3 1 0= 18897 vm/vm_object.c:1703 (rw:vm object) > 17 1389 269455 1778764 2828515 0 0 0= 106843 vm/vm_object.c:1222 (rw:vm object) > 472 1444 14742782 1731247 6851167 2 0 0= 20011 amd64/amd64/pmap.c:3620 (rw:pmap pv global) > > reset + rm -r /usr/obj/* > > 230791 100799 405140208 51092446 203312369 1 0 0= 472299 kern/vfs_subr.c:2176 (lockmgr:ufs) > 188 8046 69993327 41591950 144943809 0 0 0= 175226 amd64/amd64/pmap.c:4204 (rw:pmap pv global) > 76 647 45324624 35204587 164788099 0 0 0= 22749884 vm/vm_page.c:1502 (sleep mutex:vm page free queue) > 40 237 19428445 33209934 164266257 0 0 0= 22973810 vm/vm_page.c:2294 (sleep mutex:vm page free queue) > 52 298 3038837 32813929 8418613 0 3 0= 2587957 kern/sys_pipe.c:1438 (sleep mutex:pipe mutex) > 1939 3216 19524902 14623470 7688013 2 1 0= 274392 vm/vm_fault.c:785 (rw:vm object) > 21696 2861 11773227 13246477 12617163 0 1 0= 106342 vm/vm_map.c:2883 (rw:vm object) > 54 7664 1445280 10079322 368785 3 27 0= 15598 kern/kern_exec.c:590 (lockmgr:ufs) > 22 2736 19935005 9087069 142381462 0 0 0= 10214061 vm/vm_page.c:2097 (sleep mutex:vm active pagequeue) > 36 885 19540659 8825819 142378309 0 0 0= 11305041 vm/vm_page.c:2053 (sleep mutex:vm active pagequeue) > 15 3045 33404 7922947 267066 0 29 0= 48667 amd64/amd64/pmap.c:3767 (rw:pmap pv global) > 13 2605 194977 6294921 2126083 0 2 0= 36096 vm/vm_object.c:646 (rw:vm object) > 82 2269 269861 4506215 2827953 0 1 0= 107885 vm/vm_object.c:1222 (rw:vm object) > 2179 6501 82846723 4123049 368785 224 11 0= 13145 kern/imgact_elf.c:829 (lockmgr:ufs) > 81 722 64614191 4099711 214861181 0 0 0= 2763484 kern/vfs_cache.c:487 (rw:Name Cache) > 3925 2851 3900231 3909417 1031608 3 3 0= 22052 vm/vm_object.c:1703 (rw:vm object) > 483 3335 14875079 3554944 6850151 2 0 0= 24182 amd64/amd64/pmap.c:3620 (rw:pmap pv global) > 187 129 103680324 2146404 250760755 0 0 0= 1630451 amd64/amd64/pmap.c:5362 (rw:pmap pv list) > 30468 2402 126229130 2042062 158088931 0 0 0= 71708 vm/vm_object.c:517 (rw:vm object) > 28 76 51334143 1892757 199327513 0 0 0= 2384837 kern/vfs_cache.c:668 (sleep mutex:vnode interlock) > > From owner-freebsd-current@FreeBSD.ORG Thu Mar 19 18:43:45 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 49222ED for ; Thu, 19 Mar 2015 18:43:45 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 263F7236 for ; Thu, 19 Mar 2015 18:43:45 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id t2JIhjFS059594 for ; Thu, 19 Mar 2015 18:43:45 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id t2JIhi9r059593 for freebsd-current@freebsd.org; Thu, 19 Mar 2015 18:43:44 GMT (envelope-from bdrewery) Received: (qmail 74251 invoked from network); 19 Mar 2015 13:43:40 -0500 Received: from unknown (HELO ?10.10.1.139?) (freebsd@shatow.net@10.10.1.139) by sweb.xzibition.com with ESMTPA; 19 Mar 2015 13:43:40 -0500 Message-ID: <550B18E0.3080203@FreeBSD.org> Date: Thu, 19 Mar 2015 13:43:44 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ryan Stone , Mateusz Guzik , FreeBSD Current Subject: Re: [PATCH] Convert the VFS cache lock to an rmlock References: <20150312173635.GB9153@dft-labs.eu> In-Reply-To: OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WgNKJIxef3qssxpqFR0G2emlbkieBOeQq" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 19 Mar 2015 18:43:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WgNKJIxef3qssxpqFR0G2emlbkieBOeQq Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3/13/2015 10:23 AM, Ryan Stone wrote: > It's almost 5% > on the 32 core machine: This likely will harm package building. --=20 Regards, Bryan Drewery --WgNKJIxef3qssxpqFR0G2emlbkieBOeQq 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 iQEcBAEBAgAGBQJVCxjgAAoJEDXXcbtuRpfP/kIH/RYvbpRG5i7pxzzwBn3DdQeC muMTbNrcoWamD7LWzYD8sh9Gq0BYNTt4vXqueZ1HvStilzz0yvSL7wG00ef/i4tC KhCyV8/ThFYJTIA7You94WUZsVkSxEIcJduDd+3YN42KBXJwT3pevVaEEgMILNkR +q30ueBIHaCn/Yd3VAYoLThZGe+qrjrD1o53ihoMkxaowWdh26cqepJbpMBsrnOG ZYjfekgtECrza2PRPW5yCVlJV4EzCJAgRpTjd7QeHQIQCGSxp7buVgH/f8vsZ6Dm SjNfQrqlalnR/P7nVnDmQnq+fCF6BP25UqPethtWq0IRCVmyYnXx4HNfIcoBSHI= =h2hl -----END PGP SIGNATURE----- --WgNKJIxef3qssxpqFR0G2emlbkieBOeQq-- From owner-freebsd-current@FreeBSD.ORG Fri Mar 20 02:08:25 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46C9A2C7 for ; Fri, 20 Mar 2015 02:08:25 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 278F9CA8 for ; Fri, 20 Mar 2015 02:08:25 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id EBDD6F8 for ; Fri, 20 Mar 2015 02:08:24 +0000 (UTC) Date: Fri, 20 Mar 2015 02:08:23 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <812621580.0.1426817304110.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <615255742.14.1426582002157.JavaMail.jenkins@jenkins-9.freebsd.org> References: <615255742.14.1426582002157.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD-tests2 #854 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Mar 2015 02:08:25 -0000 See ------------------------------------------ [...truncated 1227 lines...] lib/libc/string/strspn:strspn -> passed [0.014s] lib/libc/string/swab:swab_basic -> passed [0.015s] lib/libc/sys/access_test:access_access -> passed [0.018s] lib/libc/sys/access_test:access_fault -> passed [0.013s] lib/libc/sys/access_test:access_inval -> passed [0.013s] lib/libc/sys/access_test:access_notdir -> passed [0.019s] lib/libc/sys/access_test:access_notexist -> passed [0.013s] lib/libc/sys/access_test:access_toolong -> passed [0.013s] lib/libc/sys/chroot_test:chroot_basic -> passed [0.017s] lib/libc/sys/chroot_test:chroot_err -> passed [0.013s] lib/libc/sys/chroot_test:chroot_perm -> passed [0.015s] lib/libc/sys/clock_gettime_test:clock_gettime_real -> passed [0.024s] lib/libc/sys/connect_test:connect_low_port -> passed [0.016s] lib/libc/sys/dup_test:dup2_basic -> passed [0.014s] lib/libc/sys/dup_test:dup2_err -> passed [0.014s] lib/libc/sys/dup_test:dup2_max -> passed [0.015s] lib/libc/sys/dup_test:dup2_mode -> passed [0.030s] lib/libc/sys/dup_test:dup3_err -> passed [0.015s] lib/libc/sys/dup_test:dup3_max -> passed [0.014s] lib/libc/sys/dup_test:dup3_mode -> passed [0.032s] lib/libc/sys/dup_test:dup_err -> passed [0.014s] lib/libc/sys/dup_test:dup_max -> passed [0.018s] lib/libc/sys/dup_test:dup_mode -> passed [0.029s] lib/libc/sys/fsync_test:fsync_err -> passed [0.014s] lib/libc/sys/fsync_test:fsync_sync -> passed [0.038s] lib/libc/sys/getcontext_test:getcontext_err -> passed [0.014s] lib/libc/sys/getcontext_test:setcontext_err -> passed [0.014s] lib/libc/sys/getcontext_test:setcontext_link -> passed [0.013s] lib/libc/sys/getgroups_test:getgroups_err -> expected_failure: Reported as kern/189941: /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/sys/t_getgroups.c:63: getgroups(-1, gidset) == -1 not met [0.014s] lib/libc/sys/getgroups_test:getgroups_getgid -> passed [0.014s] lib/libc/sys/getgroups_test:getgroups_setgid -> passed [0.016s] lib/libc/sys/getgroups_test:getgroups_zero -> passed [0.014s] lib/libc/sys/getitimer_test:getitimer_empty -> passed [0.014s] lib/libc/sys/getitimer_test:getitimer_err -> passed [0.014s] lib/libc/sys/getitimer_test:setitimer_basic -> passed [0.015s] lib/libc/sys/getitimer_test:setitimer_err -> passed [0.015s] lib/libc/sys/getitimer_test:setitimer_old -> passed [0.015s] lib/libc/sys/getlogin_test:getlogin_r_err -> passed [0.014s] lib/libc/sys/getlogin_test:getlogin_same -> passed [0.014s] lib/libc/sys/getlogin_test:setlogin_basic -> passed [0.015s] lib/libc/sys/getlogin_test:setlogin_err -> passed [0.016s] lib/libc/sys/getlogin_test:setlogin_perm -> passed [0.015s] lib/libc/sys/getpid_test:getpid_process -> passed [0.023s] lib/libc/sys/getpid_test:getpid_thread -> passed [0.017s] lib/libc/sys/getrusage_test:getrusage_err -> passed [0.015s] lib/libc/sys/getrusage_test:getrusage_sig -> passed [0.025s] lib/libc/sys/getrusage_test:getrusage_utime_back -> passed [2.193s] lib/libc/sys/getrusage_test:getrusage_utime_zero -> skipped: this testcase passes/fails sporadically on FreeBSD/i386 @ r273153 (at least) [0.014s] lib/libc/sys/getsid_test:getsid_current -> passed [0.015s] lib/libc/sys/getsid_test:getsid_err -> passed [0.014s] lib/libc/sys/getsid_test:getsid_process -> passed [0.015s] lib/libc/sys/gettimeofday_test:gettimeofday_err -> passed [0.014s] lib/libc/sys/gettimeofday_test:gettimeofday_mono -> passed [0.016s] lib/libc/sys/issetugid_test:issetugid_egid -> passed [0.018s] lib/libc/sys/issetugid_test:issetugid_euid -> passed [0.017s] lib/libc/sys/issetugid_test:issetugid_rgid -> passed [0.018s] lib/libc/sys/issetugid_test:issetugid_ruid -> passed [0.017s] lib/libc/sys/kevent_test:kevent_zerotimer -> passed [0.016s] lib/libc/sys/kevent_test:kqueue_desc_passing -> passed [0.016s] lib/libc/sys/kevent_test:kqueue_unsupported_fd -> skipped: no /nonexistent available for testing [0.014s] lib/libc/sys/kill_test:kill_basic -> passed [0.016s] lib/libc/sys/kill_test:kill_err -> passed [0.015s] lib/libc/sys/kill_test:kill_perm -> passed [1.098s] lib/libc/sys/kill_test:kill_pgrp_neg -> passed [0.017s] lib/libc/sys/kill_test:kill_pgrp_zero -> passed [0.017s] lib/libc/sys/link_test:link_count -> passed [0.021s] lib/libc/sys/link_test:link_err -> passed [0.020s] lib/libc/sys/link_test:link_perm -> passed [0.015s] lib/libc/sys/link_test:link_stat -> passed [0.021s] lib/libc/sys/listen_test:listen_err -> passed [0.019s] lib/libc/sys/listen_test:listen_low_port -> passed [0.016s] lib/libc/sys/mincore_test:mincore_err -> passed [0.015s] lib/libc/sys/mincore_test:mincore_resid -> passed [0.041s] lib/libc/sys/mincore_test:mincore_shmseg -> passed [0.018s] lib/libc/sys/mkdir_test:mkdir_err -> passed [0.015s] lib/libc/sys/mkdir_test:mkdir_mode -> passed [1.064s] lib/libc/sys/mkdir_test:mkdir_perm -> passed [0.018s] lib/libc/sys/mkdir_test:mkdir_trail -> passed [0.026s] lib/libc/sys/mkfifo_test:mkfifo_block -> passed [1.023s] lib/libc/sys/mkfifo_test:mkfifo_err -> passed [0.019s] lib/libc/sys/mkfifo_test:mkfifo_nonblock -> passed [1.047s] lib/libc/sys/mkfifo_test:mkfifo_perm -> passed [0.021s] lib/libc/sys/mkfifo_test:mkfifo_stat -> passed [0.037s] lib/libc/sys/mknod_test:mknod_err -> passed [0.018s] lib/libc/sys/mknod_test:mknod_exist -> passed [0.019s] lib/libc/sys/mknod_test:mknod_perm -> passed [0.019s] lib/libc/sys/mknod_test:mknod_stat -> expected_failure: mknod does not allow S_IFREG: /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/sys/t_mknod.c:179: mknod(path, S_IFREG, 0) == 0 not met [0.020s] lib/libc/sys/mlock_test:mlock_clip -> passed [0.015s] lib/libc/sys/mlock_test:mlock_err -> passed [0.015s] lib/libc/sys/mlock_test:mlock_limits -> passed [0.016s] lib/libc/sys/mlock_test:mlock_mmap -> passed [0.015s] lib/libc/sys/mlock_test:mlock_nested -> passed [0.016s] lib/libc/sys/mmap_test:mmap_err -> passed [0.015s] lib/libc/sys/mmap_test:mmap_loan -> passed [0.020s] lib/libc/sys/mmap_test:mmap_prot_1 -> passed [0.018s] lib/libc/sys/mmap_test:mmap_prot_2 -> passed [0.016s] lib/libc/sys/mmap_test:mmap_prot_3 -> passed [0.019s] lib/libc/sys/mmap_test:mmap_truncate -> passed [0.026s] lib/libc/sys/mmap_test:mmap_va0 -> passed [0.015s] lib/libc/sys/mprotect_test:mprotect_access -> passed [0.019s] lib/libc/sys/mprotect_test:mprotect_err -> passed [0.015s] lib/libc/sys/mprotect_test:mprotect_pax -> passed [0.015s] lib/libc/sys/mprotect_test:mprotect_write -> passed [0.016s] lib/libc/sys/msgctl_test:msgctl_err -> passed [0.018s] lib/libc/sys/msgctl_test:msgctl_perm -> passed [0.020s] lib/libc/sys/msgctl_test:msgctl_pid -> passed [2.102s] lib/libc/sys/msgctl_test:msgctl_set -> passed [0.020s] lib/libc/sys/msgctl_test:msgctl_time -> passed [0.017s] lib/libc/sys/msgget_test:msgget_excl -> passed [0.016s] lib/libc/sys/msgget_test:msgget_exit -> passed [0.018s] lib/libc/sys/msgget_test:msgget_init -> passed [0.018s] lib/libc/sys/msgget_test:msgget_limit -> passed [0.016s] lib/libc/sys/msgget_test:msgget_mode -> passed [0.019s] lib/libc/sys/msgrcv_test:msgrcv_basic -> passed [0.018s] lib/libc/sys/msgrcv_test:msgrcv_block -> passed [2.149s] lib/libc/sys/msgrcv_test:msgrcv_err -> passed [0.017s] lib/libc/sys/msgrcv_test:msgrcv_mtype -> passed [0.019s] lib/libc/sys/msgrcv_test:msgrcv_nonblock -> passed [2.103s] lib/libc/sys/msgrcv_test:msgrcv_truncate -> passed [0.018s] lib/libc/sys/msgsnd_test:msgsnd_block -> passed [2.085s] lib/libc/sys/msgsnd_test:msgsnd_count -> passed [0.018s] lib/libc/sys/msgsnd_test:msgsnd_err -> passed [0.018s] lib/libc/sys/msgsnd_test:msgsnd_nonblock -> passed [2.085s] lib/libc/sys/msgsnd_test:msgsnd_perm -> passed [0.021s] lib/libc/sys/msync_test:msync_async -> passed [0.019s] lib/libc/sys/msync_test:msync_err -> passed [0.022s] lib/libc/sys/msync_test:msync_invalidate -> passed [0.018s] lib/libc/sys/msync_test:msync_sync -> passed [0.018s] lib/libc/sys/nanosleep_test:nanosleep_basic -> passed [0.016s] lib/libc/sys/nanosleep_test:nanosleep_err -> passed [0.015s] lib/libc/sys/nanosleep_test:nanosleep_sig -> passed [1.039s] lib/libc/sys/pipe_test:pipe_restart -> passed [2.158s] lib/libc/sys/pipe2_test:pipe2_basic -> passed [0.015s] lib/libc/sys/pipe2_test:pipe2_cloexec -> passed [0.015s] lib/libc/sys/pipe2_test:pipe2_consume -> passed [0.015s] lib/libc/sys/pipe2_test:pipe2_einval -> passed [0.015s] lib/libc/sys/pipe2_test:pipe2_nonblock -> passed [0.014s] lib/libc/sys/poll_test:poll_3way -> passed [10.083s] lib/libc/sys/poll_test:poll_basic -> passed [0.016s] lib/libc/sys/poll_test:poll_err -> passed [0.015s] lib/libc/sys/revoke_test:revoke_basic -> skipped: revoke(2) is only implemented for devfs(5). [0.018s] lib/libc/sys/revoke_test:revoke_err -> skipped: revoke(2) is only implemented for devfs(5). [0.015s] lib/libc/sys/revoke_test:revoke_perm -> skipped: revoke(2) is only implemented for devfs(5). [0.017s] lib/libc/sys/select_test:pselect_sigmask -> passed [1.056s] lib/libc/sys/select_test:pselect_timeout -> passed [0.031s] lib/libc/sys/setrlimit_test:setrlimit_basic -> passed [0.014s] lib/libc/sys/setrlimit_test:setrlimit_current -> passed [0.014s] lib/libc/sys/setrlimit_test:setrlimit_err -> passed [0.015s] lib/libc/sys/setrlimit_test:setrlimit_fsize -> passed [0.019s] lib/libc/sys/setrlimit_test:setrlimit_memlock -> passed [0.015s] lib/libc/sys/setrlimit_test:setrlimit_nofile_1 -> passed [0.014s] lib/libc/sys/setrlimit_test:setrlimit_nofile_2 -> passed [0.015s] lib/libc/sys/setrlimit_test:setrlimit_nproc -> maxproc limit exceeded by uid 977 (pid 29170); see tuning(7) and login.conf(5) passed [0.551s] lib/libc/sys/setrlimit_test:setrlimit_perm -> panic: mutex process lock not owned at /builds/FreeBSD_HEAD/sys/kern/kern_prot.c:1974 cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe009749a8e0 vpanic() at vpanic+0x189/frame 0xfffffe009749a960 panic() at panic+0x43/frame 0xfffffe009749a9c0 __mtx_assert() at __mtx_assert+0xc2/frame 0xfffffe009749a9d0 proc_set_cred() at proc_set_cred+0x36/frame 0xfffffe009749a9f0 fork1() at fork1+0x27e/frame 0xfffffe009749aac0 sys_fork() at sys_fork+0x1f/frame 0xfffffe009749aae0 amd64_syscall() at amd64_syscall+0x27f/frame 0xfffffe009749abf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe009749abf0 --- syscall (0, FreeBSD ELF64, nosys), rip = 0x8019c216a, rsp = 0x7fffffffc2d8, rbp = 0x7fffffffc340 --- KDB: enter: panic [ thread pid 660 tid 100065 ] Stopped at kdb_enter+0x3e: movq $0,kdb_why db> Traceback (most recent call last): File "/vm/freebsd-ci/scripts/test/run-tests.py", line 152, in main(sys.argv) File "/vm/freebsd-ci/scripts/test/run-tests.py", line 80, in main runTest() File "/vm/freebsd-ci/scripts/test/run-tests.py", line 124, in runTest child2.expect(prompt, timeout=7200) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1451, in expect timeout, searchwindowsize) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1466, in expect_list timeout, searchwindowsize) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1568, in expect_loop raise TIMEOUT(str(err) + '\n' + str(self)) pexpect.TIMEOUT: Timeout exceeded. version: 3.3 command: /usr/sbin/bhyve args: [u'/usr/sbin/bhyve', u'-c', u'2', u'-m', u'2G', u'-AI', u'-H', u'-P', u'-g', u'0', u'-s', u'0:0,hostbridge', u'-s', u'1:0,lpc', u'-s', u'2:0,virtio-net,tap0,mac=58:9c:fc:00:00:2e', u'-s', u'3:0,ahci-hd,/net/jenkins-10.freebsd.org/builds/Build-UFS-image/image/FreeBSD_HEAD/test.img', u'-l', u'com1,stdio', u'vm_test'] searcher: buffer (last 100 chars): 'nter: panic\r\n[ thread pid 660 tid 100065 ]\r\nStopped at kdb_enter+0x3e: movq $0,kdb_why\r\ndb> ' before (last 100 chars): 'nter: panic\r\n[ thread pid 660 tid 100065 ]\r\nStopped at kdb_enter+0x3e: movq $0,kdb_why\r\ndb> ' after: match: None match_index: None exitstatus: None flag_eof: False pid: 29751 child_fd: 4 closed: False timeout: 30 delimiter: logfile: ', mode 'w' at 0x800670150> logfile_read: None logfile_send: None maxread: 2000 ignorecase: False searchwindowsize: None delaybeforesend: 0.05 delayafterclose: 0.1 delayafterterminate: 0.1 Build step 'Execute shell' marked build as failure Recording test results ERROR: Publisher hudson.tasks.junit.JUnitResultArchiver aborted due to exception hudson.AbortException: Test reports were found but none of them are new. Did tests run? For example, is 5 days 0 hr old at hudson.tasks.junit.TestResult.parse(TestResult.java:178) at hudson.tasks.junit.TestResult.parse(TestResult.java:146) at hudson.tasks.junit.TestResult.(TestResult.java:122) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:119) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:92) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2688) at hudson.remoting.UserRequest.perform(UserRequest.java:121) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at hudson.remoting.Request$2.run(Request.java:324) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) at ......remote call to havoc.ysv.freebsd.org(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1356) at hudson.remoting.UserResponse.retrieve(UserRequest.java:221) at hudson.remoting.Channel.call(Channel.java:752) at hudson.FilePath.act(FilePath.java:978) at hudson.FilePath.act(FilePath.java:967) at hudson.tasks.junit.JUnitParser.parseResult(JUnitParser.java:89) at hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:120) at hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:137) at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:74) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:761) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:721) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:670) at hudson.model.Run.execute(Run.java:1775) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240) From owner-freebsd-current@FreeBSD.ORG Fri Mar 20 02:20:31 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EDF98666; Fri, 20 Mar 2015 02:20:31 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7C70CD91; Fri, 20 Mar 2015 02:20:31 +0000 (UTC) Received: by wixw10 with SMTP id w10so19286000wix.0; Thu, 19 Mar 2015 19:20:30 -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-type:content-disposition:in-reply-to :user-agent; bh=jU2OhftITYfNWDbmry44MLaD7ma5i7mTJCgyOU+j7vs=; b=GzuTlc3bAmZJ0hPyObCSomPiMHa2saFgwWAZ4lj6oWqjcezitFZydDz5TYeHky1UeU mja7LvskoyaH0QgZqRISPqNHnlPAz9NlvvU7KYSdu4VhBVDJ+BYwcBAlOaSGdbuTwox3 cBg35UrTNBgEem505NmeIsajuh7EWmkDC2+mVmVhJYNe5dokIVgAp1+Fo21aRR2AB+hH QPd5NXjDNkbmG4zpB7faJFqh5ePQjx3CxhVJgJTiltOUKk4ZGbiZAkEds/JNSrv0bqNi Dxa35D+L4kNqdd+F36wI/XZlAd8xTamv4loa4aM2T8SWo6IQ9s1GrggfNIQFQK3f44X3 Eg+w== X-Received: by 10.194.193.99 with SMTP id hn3mr158449618wjc.148.1426818030066; Thu, 19 Mar 2015 19:20:30 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id cj9sm4309268wjc.42.2015.03.19.19.20.28 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 19 Mar 2015 19:20:29 -0700 (PDT) Date: Fri, 20 Mar 2015 03:20:26 +0100 From: Mateusz Guzik To: jenkins-admin@freebsd.org Subject: Re: Build failed in Jenkins: FreeBSD_HEAD-tests2 #854 Message-ID: <20150320022026.GA10296@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , jenkins-admin@freebsd.org, freebsd-current@freebsd.org References: <615255742.14.1426582002157.JavaMail.jenkins@jenkins-9.freebsd.org> <812621580.0.1426817304110.JavaMail.jenkins@jenkins-9.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <812621580.0.1426817304110.JavaMail.jenkins@jenkins-9.freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Mar 2015 02:20:32 -0000 On Fri, Mar 20, 2015 at 02:08:23AM +0000, jenkins-admin@freebsd.org wrote: > lib/libc/sys/setrlimit_test:setrlimit_nproc -> maxproc limit exceeded by uid 977 (pid 29170); see tuning(7) and login.conf(5) > passed [0.551s] > lib/libc/sys/setrlimit_test:setrlimit_perm -> panic: mutex process lock not owned at /builds/FreeBSD_HEAD/sys/kern/kern_prot.c:1974 > cpuid = 1 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe009749a8e0 > vpanic() at vpanic+0x189/frame 0xfffffe009749a960 > panic() at panic+0x43/frame 0xfffffe009749a9c0 > __mtx_assert() at __mtx_assert+0xc2/frame 0xfffffe009749a9d0 > proc_set_cred() at proc_set_cred+0x36/frame 0xfffffe009749a9f0 > fork1() at fork1+0x27e/frame 0xfffffe009749aac0 > sys_fork() at sys_fork+0x1f/frame 0xfffffe009749aae0 > amd64_syscall() at amd64_syscall+0x27f/frame 0xfffffe009749abf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe009749abf0 > --- syscall (0, FreeBSD ELF64, nosys), rip = 0x8019c216a, rsp = 0x7fffffffc2d8, rbp = 0x7fffffffc340 --- > KDB: enter: panic > [ thread pid 660 tid 100065 ] > Stopped at kdb_enter+0x3e: movq $0,kdb_why Weird, I'll look at that. -- Mateusz Guzik From owner-freebsd-current@FreeBSD.ORG Fri Mar 20 07:04:30 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 85A77C60; Fri, 20 Mar 2015 07:04:30 +0000 (UTC) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::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 2D439CBD; Fri, 20 Mar 2015 07:04:30 +0000 (UTC) Received: by wgra20 with SMTP id a20so81555882wgr.3; Fri, 20 Mar 2015 00:04:28 -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:cc:content-type; bh=AiMUui6O8aJ1tOYN321ACSfJQJp563e/hKQC3+VeKIQ=; b=ZYfJIk2JxQwu6v0aJoJFC2c3tLazyEz4nR+E4gBkz8jgKpcKGfNeUpoOkW3TN3PJZN zeELmVPWfFZad31wpNb7AuU41AkpdV/Opyl5haa/QmhbbfL7uIdqaZwux0VpuOocEjOL HW6+UQEEub+IEngqB/GPekU/EBOay59/E5PjI5+GuCVci+8XkoqoWixwZ9QxkSeuHx89 BbY4/jjMRRWXX/+Ul5ItnaLU3Ldr5ee7i6KaT5Ovyz0VEsiadJAT6gGfGIi/gCO0l1CZ FCEkYHfcREXPsqxhSdmhMNn/arnYI7AEVxMdsskkEmI5oPUMLZbozqcj7rbRzJrUWLy7 OhQw== X-Received: by 10.180.91.79 with SMTP id cc15mr21590516wib.37.1426835068455; Fri, 20 Mar 2015 00:04:28 -0700 (PDT) MIME-Version: 1.0 Sender: fedor.indutny@gmail.com Received: by 10.27.9.208 with HTTP; Fri, 20 Mar 2015 00:04:08 -0700 (PDT) From: Fedor Indutny Date: Fri, 20 Mar 2015 00:04:08 -0700 X-Google-Sender-Auth: H97mPTGqxPq8cUhBE40ItEA_6cY Message-ID: Subject: `SA_SIGINFO | SA_RESETHAND` fix backport (DUP) To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Mark Johnston X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Mar 2015 07:04:30 -0000 Hello people! While trying to fix node.js/io.js issue with signal handling on FreeBSD 10.1, I have found that the problem was due to a kernel bug. Luckily that bug is fixed in: https://github.com/freebsd/freebsd/commit/4501dadd00cece6d06392c42e5fc6af07731e451 But it looks like the fix wasn't backported to 10.x . Do you think it might be possible to do it? I'd really appreciate this. Thank you, Fedor. P.S. Sent the duplicate of this before, but I wasn't on the mailing list so it fell into the moderation list. From owner-freebsd-current@FreeBSD.ORG Fri Mar 20 07:36:17 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CFF5BF78 for ; Fri, 20 Mar 2015 07:36:17 +0000 (UTC) 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 8A167100 for ; Fri, 20 Mar 2015 07:36:17 +0000 (UTC) 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 esmtp (envelope-from ) id <1YYrTV-000Lhn-AW>; Fri, 20 Mar 2015 08:36:09 +0100 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=prometheus) by inpost2.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1YYrTV-002eFQ-66>; Fri, 20 Mar 2015 08:36:09 +0100 Date: Fri, 20 Mar 2015 08:33:54 +0100 From: "O. Hartmann" To: freebsd-current Subject: clang/tblgen: undefined reference to `futimens' c++: error: linker command failed with exit Message-ID: <20150320083354.5efc5fa6@prometheus> Organization: FU Berlin X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: base64 X-Originating-IP: 87.138.105.249 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Mar 2015 07:36:18 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMjU2DQoNClJ1bm5p bmcgDQoNCjExLjAtQ1VSUkVOVCBGcmVlQlNEIDExLjAtQ1VSUkVOVCAjMiByMjc3MzgyOiBNb24g SmFuIDE5IDE2OjEwOjM0IENFVCAyMDE1DQphbWQ2NA0KDQp3aXRoIHNvdXJjZSB0cmVlIGF0IHJl dmlzaW9uIA0KPj4+IFVwZGF0aW5nIC91c3Ivc3JjIHVzaW5nIFN1YnZlcnNpb24NCi0gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N ClVwZGF0aW5nICcuJzoNCkF0IHJldmlzaW9uIDI4MDI3NS4NCg0KYW5kICJtYWtlIGJ1aWxkb3Js ZCBidWlsZGtlcm5lbCINCg0KZmFpbHMgYXQgdGhlIGJlbG93IHNob3duIHBvaW50Lg0KDQpUaGUg L3Vzci9vYmogdHJlZSBpcyBjbGVhbiAtIEkgZGVsZXRlIGl0IHByaW9yIHRvIGVhY2ggYnVpbGQg cnVuLg0KDQpTb21ldGhpbmcgaXMgb3V0IG9mIHN5bmMsIHNuIGVhcmxpZXIgdXBkYXRlIHByb2Nl c3MgKG1ha2UgaW5zdGFsbHdvcmxkKSBjcmFzaGVkDQphbmQgSSB0aGluayB0aGUga2VybmVsLCBi aW5hcnkgdG9vbHMgYW5kIHJlc3Qgb2Ygc291cmNlcyBhcmUgc29tZSBraW5kIG9mIG91dA0Kb2Yg c3luYy4NCg0KSXMgdGhlcmUgYSB3YXkgLSBmcm9tIHRoZSBkYXRhIHNob3duIC0gdG8gcmVzb2x2 ZSB0aGUgcHJvYmxlbT8NCg0KQnVpbGRpbmcgYSBrZXJuZWwgd29ya3MgZ3JlYXQsIGJ1aWxkaW5n IHRvb2xjaGFpbnMgZmFpbCBhbHNvIGF0IHRoZSB2ZXJ5IHNhbWUNCnBvaW50Lg0KDQpUaGFua3Mg aW4gYWR2YW5jZSwNCg0Kb2gNCg0KDQpbLi4uXQ0KLSAtLS0gX2Jvb3RzdHJhcC10b29scy11c3Iu YmluL2NsYW5nL3RibGdlbiAtLS0NCi0gLS0tIFRhYmxlR2VuLm8gLS0tDQpjKysgLU8yIC1waXBl IC1PMyAtcGlwZSAtTzMNCi0gLUkvdXNyL3NyYy91c3IuYmluL2NsYW5nL3RibGdlbi8uLi8uLi8u Li9jb250cmliL2xsdm0vaW5jbHVkZQ0KLSAtSS91c3Ivc3JjL3Vzci5iaW4vY2xhbmcvdGJsZ2Vu Ly4uLy4uLy4uL2NvbnRyaWIvbGx2bS90b29scy9jbGFuZy9pbmNsdWRlDQotIC1JL3Vzci9zcmMv dXNyLmJpbi9jbGFuZy90YmxnZW4vLi4vLi4vLi4vY29udHJpYi9sbHZtL3V0aWxzL1RhYmxlR2Vu IC1JLg0KLSAtSS91c3Ivc3JjL3Vzci5iaW4vY2xhbmcvdGJsZ2VuLy4uLy4uLy4uL2NvbnRyaWIv bGx2bS8uLi8uLi9saWIvY2xhbmcvaW5jbHVkZQ0KLSAtRExMVk1fT05fVU5JWCAtRExMVk1fT05f RlJFRUJTRCAtRF9fU1REQ19MSU1JVF9NQUNST1MgLURfX1NURENfQ09OU1RBTlRfTUFDUk9TDQot IC1mbm8tc3RyaWN0LWFsaWFzaW5nDQotIC1ETExWTV9ERUZBVUxUX1RBUkdFVF9UUklQTEU9XCJ4 ODZfNjQtdW5rbm93bi1mcmVlYnNkMTEuMFwiDQotIC1ETExWTV9IT1NUX1RSSVBMRT1cIng4Nl82 NC11bmtub3duLWZyZWVic2QxMS4wXCIgLURERUZBVUxUX1NZU1JPT1Q9XCJcIg0KLSAtUXVudXNl ZC1hcmd1bWVudHMgLUkvdXNyL29iai91c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUgLXN0 ZD1jKysxMQ0KLSAtc3RkPWMrKzExIC1mbm8tZXhjZXB0aW9ucyAtZm5vLXJ0dGkgLXN0ZGxpYj1s aWJjKysgLVduby1jKysxMS1leHRlbnNpb25zDQotIC1jIC91c3Ivc3JjL3Vzci5iaW4vY2xhbmcv dGJsZ2VuLy4uLy4uLy4uL2NvbnRyaWIvbGx2bS91dGlscy9UYWJsZUdlbi9UYWJsZUdlbi5jcHAN Ci0gLW8gVGFibGVHZW4ubyAtLS0gX2Jvb3RzdHJhcC10b29scy11c3IuYmluL2NsYW5nL2NsYW5n LXRibGdlbg0KLSAtLS0gL3Vzci9vYmovdXNyL3NyYy90bXAvdXNyL3NyYy91c3IuYmluL2NsYW5n L2NsYW5nLXRibGdlbi8uLi8uLi8uLi9saWIvY2xhbmcvbGlibGx2bXN1cHBvcnQvbGlibGx2bXN1 cHBvcnQuYShQYXRoLm8pOg0KSW4gZnVuY3Rpb24gYGxsdm06OnN5czo6ZnM6OnNldExhc3RNb2Rp ZmljYXRpb25BbmRBY2Nlc3NUaW1lKGludCwNCmxsdm06OnN5czo6VGltZVZhbHVlKSc6IC91c3Iv c3JjL2xpYi9jbGFuZy9saWJsbHZtc3VwcG9ydC8uLi8uLi8uLi9jb250cmliL2xsdm0vbGliL1N1 cHBvcnQvUGF0aC5jcHA6KC50ZXh0KzB4NDY0OSk6DQp1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBm dXRpbWVucycgYysrOiBlcnJvcjogbGlua2VyIGNvbW1hbmQgZmFpbGVkIHdpdGggZXhpdA0KY29k ZSAxICh1c2UgLXYgdG8gc2VlIGludm9jYXRpb24pICoqKiBbY2xhbmctdGJsZ2VuXSBFcnJvciBj b2RlIDENCg0KbWFrZVszXTogc3RvcHBlZCBpbiAvdXNyL3NyYy91c3IuYmluL2NsYW5nL2NsYW5n LXRibGdlbg0KMSBlcnJvcg0KLS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246 IEdudVBHIHYyDQoNCmlRRWNCQUVCQ0FBR0JRSlZDODFpQUFvSkVPZ0JjRDdBLzVOOENaUUgvMk90 c29QcGVsUnRQMjN3T1ovKzUvOWkNCjI2ano2NTd4UHBEamtCNjFUY2NVam8zaW9kQzVSejYzQVNI cHhFRVB3RVU1QmlNQkk0NkFpZUZJaFk0MXVMNFkNCkt3WFgwUGV3VVNwaWx0SmdOTURwNkZidDJO STVHNVFDMUloL1prZDhkWnBNV0lkWXR2a2cyS1ptbmFwaWFCdVANCktGaHVxYjNpRmhrYThHamxK ZElsYmFXbWd6VHV1ejhmQjlsOG9HS2hPYnBQMEg5VEJJQnVuRWdTcDY1bW9NSFUNCkt0WmlnVTd6 bWVCR3hSRWtxMmhCRXg1V0RMajk4YmF6aXVvdERBU2tlQ0pLSStUM0NCL2RMa0x6THp1ZFBmbjYN CmsvdUFwVFU5UFpVMitQQ1JrSkh6bk51VXI2TThLa05MVUFObVJnL1Y3SXNVTnhHOVB6Q2RHNklT enV2OEdDRT0NCj1JVmI2DQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0NCg== From owner-freebsd-current@FreeBSD.ORG Fri Mar 20 07:41:20 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C862E186 for ; Fri, 20 Mar 2015 07:41:20 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id A925D1D6 for ; Fri, 20 Mar 2015 07:41:20 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id D03F61AF for ; Fri, 20 Mar 2015 07:41:20 +0000 (UTC) Date: Fri, 20 Mar 2015 07:41:20 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <94841522.2.1426837280605.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <812621580.0.1426817304110.JavaMail.jenkins@jenkins-9.freebsd.org> References: <812621580.0.1426817304110.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD-tests2 #855 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Mar 2015 07:41:20 -0000 See ------------------------------------------ [...truncated 3430 lines...] lib/libc/string/strspn:strspn -> passed [0.016s] lib/libc/string/swab:swab_basic -> passed [0.016s] lib/libc/sys/access_test:access_access -> passed [0.020s] lib/libc/sys/access_test:access_fault -> passed [0.016s] lib/libc/sys/access_test:access_inval -> passed [0.016s] lib/libc/sys/access_test:access_notdir -> passed [0.016s] lib/libc/sys/access_test:access_notexist -> passed [0.016s] lib/libc/sys/access_test:access_toolong -> passed [0.015s] lib/libc/sys/chroot_test:chroot_basic -> passed [0.386s] lib/libc/sys/chroot_test:chroot_err -> passed [0.014s] lib/libc/sys/chroot_test:chroot_perm -> passed [0.016s] lib/libc/sys/clock_gettime_test:clock_gettime_real -> passed [0.016s] lib/libc/sys/connect_test:connect_low_port -> passed [0.017s] lib/libc/sys/dup_test:dup2_basic -> passed [0.016s] lib/libc/sys/dup_test:dup2_err -> passed [0.016s] lib/libc/sys/dup_test:dup2_max -> passed [0.015s] lib/libc/sys/dup_test:dup2_mode -> passed [0.033s] lib/libc/sys/dup_test:dup3_err -> passed [0.017s] lib/libc/sys/dup_test:dup3_max -> passed [0.016s] lib/libc/sys/dup_test:dup3_mode -> passed [0.032s] lib/libc/sys/dup_test:dup_err -> passed [0.016s] lib/libc/sys/dup_test:dup_max -> passed [0.020s] lib/libc/sys/dup_test:dup_mode -> passed [0.034s] lib/libc/sys/fsync_test:fsync_err -> passed [0.016s] lib/libc/sys/fsync_test:fsync_sync -> passed [0.311s] lib/libc/sys/getcontext_test:getcontext_err -> passed [0.017s] lib/libc/sys/getcontext_test:setcontext_err -> passed [0.015s] lib/libc/sys/getcontext_test:setcontext_link -> passed [0.016s] lib/libc/sys/getgroups_test:getgroups_err -> expected_failure: Reported as kern/189941: /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/sys/t_getgroups.c:63: getgroups(-1, gidset) == -1 not met [0.016s] lib/libc/sys/getgroups_test:getgroups_getgid -> passed [0.014s] lib/libc/sys/getgroups_test:getgroups_setgid -> passed [0.017s] lib/libc/sys/getgroups_test:getgroups_zero -> passed [0.016s] lib/libc/sys/getitimer_test:getitimer_empty -> passed [0.016s] lib/libc/sys/getitimer_test:getitimer_err -> passed [0.015s] lib/libc/sys/getitimer_test:setitimer_basic -> passed [0.016s] lib/libc/sys/getitimer_test:setitimer_err -> passed [0.017s] lib/libc/sys/getitimer_test:setitimer_old -> passed [0.015s] lib/libc/sys/getlogin_test:getlogin_r_err -> passed [0.015s] lib/libc/sys/getlogin_test:getlogin_same -> passed [0.016s] lib/libc/sys/getlogin_test:setlogin_basic -> passed [0.017s] lib/libc/sys/getlogin_test:setlogin_err -> passed [0.017s] lib/libc/sys/getlogin_test:setlogin_perm -> passed [0.017s] lib/libc/sys/getpid_test:getpid_process -> passed [0.025s] lib/libc/sys/getpid_test:getpid_thread -> passed [0.020s] lib/libc/sys/getrusage_test:getrusage_err -> passed [0.016s] lib/libc/sys/getrusage_test:getrusage_sig -> passed [0.016s] lib/libc/sys/getrusage_test:getrusage_utime_back -> passed [2.097s] lib/libc/sys/getrusage_test:getrusage_utime_zero -> skipped: this testcase passes/fails sporadically on FreeBSD/i386 @ r273153 (at least) [0.016s] lib/libc/sys/getsid_test:getsid_current -> passed [0.015s] lib/libc/sys/getsid_test:getsid_err -> passed [0.015s] lib/libc/sys/getsid_test:getsid_process -> passed [0.016s] lib/libc/sys/gettimeofday_test:gettimeofday_err -> passed [0.014s] lib/libc/sys/gettimeofday_test:gettimeofday_mono -> passed [0.015s] lib/libc/sys/issetugid_test:issetugid_egid -> passed [0.019s] lib/libc/sys/issetugid_test:issetugid_euid -> passed [0.018s] lib/libc/sys/issetugid_test:issetugid_rgid -> passed [0.019s] lib/libc/sys/issetugid_test:issetugid_ruid -> passed [0.019s] lib/libc/sys/kevent_test:kevent_zerotimer -> passed [0.018s] lib/libc/sys/kevent_test:kqueue_desc_passing -> passed [0.019s] lib/libc/sys/kevent_test:kqueue_unsupported_fd -> skipped: no /nonexistent available for testing [0.016s] lib/libc/sys/kill_test:kill_basic -> passed [0.018s] lib/libc/sys/kill_test:kill_err -> passed [0.017s] lib/libc/sys/kill_test:kill_perm -> passed [1.067s] lib/libc/sys/kill_test:kill_pgrp_neg -> passed [0.019s] lib/libc/sys/kill_test:kill_pgrp_zero -> passed [0.017s] lib/libc/sys/link_test:link_count -> passed [0.023s] lib/libc/sys/link_test:link_err -> passed [0.021s] lib/libc/sys/link_test:link_perm -> passed [0.017s] lib/libc/sys/link_test:link_stat -> passed [0.021s] lib/libc/sys/listen_test:listen_err -> passed [0.020s] lib/libc/sys/listen_test:listen_low_port -> passed [0.017s] lib/libc/sys/mincore_test:mincore_err -> passed [0.017s] lib/libc/sys/mincore_test:mincore_resid -> passed [0.041s] lib/libc/sys/mincore_test:mincore_shmseg -> passed [0.019s] lib/libc/sys/mkdir_test:mkdir_err -> passed [0.017s] lib/libc/sys/mkdir_test:mkdir_mode -> passed [1.055s] lib/libc/sys/mkdir_test:mkdir_perm -> passed [0.020s] lib/libc/sys/mkdir_test:mkdir_trail -> passed [0.047s] lib/libc/sys/mkfifo_test:mkfifo_block -> passed [1.089s] lib/libc/sys/mkfifo_test:mkfifo_err -> passed [0.022s] lib/libc/sys/mkfifo_test:mkfifo_nonblock -> passed [1.031s] lib/libc/sys/mkfifo_test:mkfifo_perm -> passed [0.021s] lib/libc/sys/mkfifo_test:mkfifo_stat -> passed [0.021s] lib/libc/sys/mknod_test:mknod_err -> passed [0.019s] lib/libc/sys/mknod_test:mknod_exist -> passed [0.020s] lib/libc/sys/mknod_test:mknod_perm -> passed [0.019s] lib/libc/sys/mknod_test:mknod_stat -> expected_failure: mknod does not allow S_IFREG: /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/sys/t_mknod.c:179: mknod(path, S_IFREG, 0) == 0 not met [0.022s] lib/libc/sys/mlock_test:mlock_clip -> passed [0.017s] lib/libc/sys/mlock_test:mlock_err -> passed [0.018s] lib/libc/sys/mlock_test:mlock_limits -> passed [0.020s] lib/libc/sys/mlock_test:mlock_mmap -> passed [0.016s] lib/libc/sys/mlock_test:mlock_nested -> passed [0.018s] lib/libc/sys/mmap_test:mmap_err -> passed [0.016s] lib/libc/sys/mmap_test:mmap_loan -> passed [0.022s] lib/libc/sys/mmap_test:mmap_prot_1 -> passed [0.022s] lib/libc/sys/mmap_test:mmap_prot_2 -> passed [0.017s] lib/libc/sys/mmap_test:mmap_prot_3 -> passed [0.041s] lib/libc/sys/mmap_test:mmap_truncate -> passed [1.014s] lib/libc/sys/mmap_test:mmap_va0 -> passed [0.016s] lib/libc/sys/mprotect_test:mprotect_access -> passed [0.021s] lib/libc/sys/mprotect_test:mprotect_err -> passed [0.016s] lib/libc/sys/mprotect_test:mprotect_pax -> passed [0.016s] lib/libc/sys/mprotect_test:mprotect_write -> passed [0.018s] lib/libc/sys/msgctl_test:msgctl_err -> passed [0.019s] lib/libc/sys/msgctl_test:msgctl_perm -> passed [0.022s] lib/libc/sys/msgctl_test:msgctl_pid -> passed [2.074s] lib/libc/sys/msgctl_test:msgctl_set -> passed [0.021s] lib/libc/sys/msgctl_test:msgctl_time -> passed [0.019s] lib/libc/sys/msgget_test:msgget_excl -> passed [0.020s] lib/libc/sys/msgget_test:msgget_exit -> passed [0.020s] lib/libc/sys/msgget_test:msgget_init -> passed [0.019s] lib/libc/sys/msgget_test:msgget_limit -> passed [0.019s] lib/libc/sys/msgget_test:msgget_mode -> passed [0.021s] lib/libc/sys/msgrcv_test:msgrcv_basic -> passed [0.020s] lib/libc/sys/msgrcv_test:msgrcv_block -> passed [2.120s] lib/libc/sys/msgrcv_test:msgrcv_err -> passed [0.019s] lib/libc/sys/msgrcv_test:msgrcv_mtype -> passed [0.020s] lib/libc/sys/msgrcv_test:msgrcv_nonblock -> passed [2.118s] lib/libc/sys/msgrcv_test:msgrcv_truncate -> passed [0.020s] lib/libc/sys/msgsnd_test:msgsnd_block -> passed [2.099s] lib/libc/sys/msgsnd_test:msgsnd_count -> passed [0.020s] lib/libc/sys/msgsnd_test:msgsnd_err -> passed [0.021s] lib/libc/sys/msgsnd_test:msgsnd_nonblock -> passed [2.095s] lib/libc/sys/msgsnd_test:msgsnd_perm -> passed [0.022s] lib/libc/sys/msync_test:msync_async -> passed [0.021s] lib/libc/sys/msync_test:msync_err -> passed [0.024s] lib/libc/sys/msync_test:msync_invalidate -> passed [0.021s] lib/libc/sys/msync_test:msync_sync -> passed [0.020s] lib/libc/sys/nanosleep_test:nanosleep_basic -> passed [0.017s] lib/libc/sys/nanosleep_test:nanosleep_err -> passed [0.016s] lib/libc/sys/nanosleep_test:nanosleep_sig -> passed [1.085s] lib/libc/sys/pipe_test:pipe_restart -> passed [2.062s] lib/libc/sys/pipe2_test:pipe2_basic -> passed [0.016s] lib/libc/sys/pipe2_test:pipe2_cloexec -> passed [0.016s] lib/libc/sys/pipe2_test:pipe2_consume -> passed [0.016s] lib/libc/sys/pipe2_test:pipe2_einval -> passed [0.016s] lib/libc/sys/pipe2_test:pipe2_nonblock -> passed [0.016s] lib/libc/sys/poll_test:poll_3way -> passed [10.100s] lib/libc/sys/poll_test:poll_basic -> passed [0.088s] lib/libc/sys/poll_test:poll_err -> passed [0.016s] lib/libc/sys/revoke_test:revoke_basic -> skipped: revoke(2) is only implemented for devfs(5). [0.019s] lib/libc/sys/revoke_test:revoke_err -> skipped: revoke(2) is only implemented for devfs(5). [0.017s] lib/libc/sys/revoke_test:revoke_perm -> skipped: revoke(2) is only implemented for devfs(5). [0.020s] lib/libc/sys/select_test:pselect_sigmask -> passed [1.072s] lib/libc/sys/select_test:pselect_timeout -> passed [0.018s] lib/libc/sys/setrlimit_test:setrlimit_basic -> passed [0.016s] lib/libc/sys/setrlimit_test:setrlimit_current -> passed [0.017s] lib/libc/sys/setrlimit_test:setrlimit_err -> passed [0.017s] lib/libc/sys/setrlimit_test:setrlimit_fsize -> passed [0.023s] lib/libc/sys/setrlimit_test:setrlimit_memlock -> passed [0.017s] lib/libc/sys/setrlimit_test:setrlimit_nofile_1 -> passed [0.017s] lib/libc/sys/setrlimit_test:setrlimit_nofile_2 -> passed [0.018s] lib/libc/sys/setrlimit_test:setrlimit_nproc -> maxproc limit exceeded by uid 977 (pid 60168); see tuning(7) and login.conf(5) passed [0.559s] lib/libc/sys/setrlimit_test:setrlimit_perm -> panic: mutex process lock not owned at /builds/FreeBSD_HEAD/sys/kern/kern_prot.c:1974 cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe009747c8e0 vpanic() at vpanic+0x189/frame 0xfffffe009747c960 panic() at panic+0x43/frame 0xfffffe009747c9c0 __mtx_assert() at __mtx_assert+0xc2/frame 0xfffffe009747c9d0 proc_set_cred() at proc_set_cred+0x36/frame 0xfffffe009747c9f0 fork1() at fork1+0x27e/frame 0xfffffe009747cac0 sys_fork() at sys_fork+0x1f/frame 0xfffffe009747cae0 amd64_syscall() at amd64_syscall+0x27f/frame 0xfffffe009747cbf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe009747cbf0 --- syscall (0, FreeBSD ELF64, nosys), rip = 0x8019c216a, rsp = 0x7fffffffc2d8, rbp = 0x7fffffffc340 --- KDB: enter: panic [ thread pid 660 tid 100059 ] Stopped at kdb_enter+0x3e: movq $0,kdb_why db> Traceback (most recent call last): File "/vm/freebsd-ci/scripts/test/run-tests.py", line 152, in main(sys.argv) File "/vm/freebsd-ci/scripts/test/run-tests.py", line 80, in main runTest() File "/vm/freebsd-ci/scripts/test/run-tests.py", line 124, in runTest child2.expect(prompt, timeout=7200) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1451, in expect timeout, searchwindowsize) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1466, in expect_list timeout, searchwindowsize) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1568, in expect_loop raise TIMEOUT(str(err) + '\n' + str(self)) pexpect.TIMEOUT: Timeout exceeded. version: 3.3 command: /usr/sbin/bhyve args: [u'/usr/sbin/bhyve', u'-c', u'2', u'-m', u'2G', u'-AI', u'-H', u'-P', u'-g', u'0', u'-s', u'0:0,hostbridge', u'-s', u'1:0,lpc', u'-s', u'2:0,virtio-net,tap0,mac=58:9c:fc:00:00:2e', u'-s', u'3:0,ahci-hd,/net/jenkins-10.freebsd.org/builds/Build-UFS-image/image/FreeBSD_HEAD/test.img', u'-l', u'com1,stdio', u'vm_test'] searcher: buffer (last 100 chars): 'nter: panic\r\n[ thread pid 660 tid 100059 ]\r\nStopped at kdb_enter+0x3e: movq $0,kdb_why\r\ndb> ' before (last 100 chars): 'nter: panic\r\n[ thread pid 660 tid 100059 ]\r\nStopped at kdb_enter+0x3e: movq $0,kdb_why\r\ndb> ' after: match: None match_index: None exitstatus: None flag_eof: False pid: 50744 child_fd: 4 closed: False timeout: 30 delimiter: logfile: ', mode 'w' at 0x800670150> logfile_read: None logfile_send: None maxread: 2000 ignorecase: False searchwindowsize: None delaybeforesend: 0.05 delayafterclose: 0.1 delayafterterminate: 0.1 Build step 'Execute shell' marked build as failure Recording test results ERROR: Publisher hudson.tasks.junit.JUnitResultArchiver aborted due to exception hudson.AbortException: Test reports were found but none of them are new. Did tests run? For example, is 5 days 6 hr old at hudson.tasks.junit.TestResult.parse(TestResult.java:178) at hudson.tasks.junit.TestResult.parse(TestResult.java:146) at hudson.tasks.junit.TestResult.(TestResult.java:122) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:119) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:92) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2688) at hudson.remoting.UserRequest.perform(UserRequest.java:121) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at hudson.remoting.Request$2.run(Request.java:324) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) at ......remote call to havoc.ysv.freebsd.org(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1356) at hudson.remoting.UserResponse.retrieve(UserRequest.java:221) at hudson.remoting.Channel.call(Channel.java:752) at hudson.FilePath.act(FilePath.java:978) at hudson.FilePath.act(FilePath.java:967) at hudson.tasks.junit.JUnitParser.parseResult(JUnitParser.java:89) at hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:120) at hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:137) at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:74) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:761) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:721) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:670) at hudson.model.Run.execute(Run.java:1775) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240) From owner-freebsd-current@FreeBSD.ORG Fri Mar 20 09:34:56 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9B842E7E; Fri, 20 Mar 2015 09:34:56 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 0A3ABFAB; Fri, 20 Mar 2015 09:34:55 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t2K9YpJE063957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Mar 2015 11:34:51 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t2K9YpJE063957 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t2K9YpmN063956; Fri, 20 Mar 2015 11:34:51 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 20 Mar 2015 11:34:51 +0200 From: Konstantin Belousov To: Mateusz Guzik , jenkins-admin@freebsd.org, freebsd-current@freebsd.org Subject: Re: Build failed in Jenkins: FreeBSD_HEAD-tests2 #854 Message-ID: <20150320093451.GN2379@kib.kiev.ua> References: <615255742.14.1426582002157.JavaMail.jenkins@jenkins-9.freebsd.org> <812621580.0.1426817304110.JavaMail.jenkins@jenkins-9.freebsd.org> <20150320022026.GA10296@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150320022026.GA10296@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) 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.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Mar 2015 09:34:56 -0000 On Fri, Mar 20, 2015 at 03:20:26AM +0100, Mateusz Guzik wrote: > On Fri, Mar 20, 2015 at 02:08:23AM +0000, jenkins-admin@freebsd.org wrote: > > lib/libc/sys/setrlimit_test:setrlimit_nproc -> maxproc limit exceeded by uid 977 (pid 29170); see tuning(7) and login.conf(5) > > passed [0.551s] > > lib/libc/sys/setrlimit_test:setrlimit_perm -> panic: mutex process lock not owned at /builds/FreeBSD_HEAD/sys/kern/kern_prot.c:1974 > > cpuid = 1 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe009749a8e0 > > vpanic() at vpanic+0x189/frame 0xfffffe009749a960 > > panic() at panic+0x43/frame 0xfffffe009749a9c0 > > __mtx_assert() at __mtx_assert+0xc2/frame 0xfffffe009749a9d0 > > proc_set_cred() at proc_set_cred+0x36/frame 0xfffffe009749a9f0 > > fork1() at fork1+0x27e/frame 0xfffffe009749aac0 > > sys_fork() at sys_fork+0x1f/frame 0xfffffe009749aae0 > > amd64_syscall() at amd64_syscall+0x27f/frame 0xfffffe009749abf0 > > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe009749abf0 > > --- syscall (0, FreeBSD ELF64, nosys), rip = 0x8019c216a, rsp = 0x7fffffffc2d8, rbp = 0x7fffffffc340 --- > > KDB: enter: panic > > [ thread pid 660 tid 100065 ] > > Stopped at kdb_enter+0x3e: movq $0,kdb_why > > Weird, I'll look at that. This is due to p_ucred not initialized on allocation of struc proc. The member is not in p_startzero/p_endzero region, so it contains garbage at the stage of the fork where proc_set_cred() is called, while the function makes assertion based on the p_ucred content. From owner-freebsd-current@FreeBSD.ORG Fri Mar 20 09:52:12 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E5674B8; Fri, 20 Mar 2015 09:52:12 +0000 (UTC) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::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 DAC981DF; Fri, 20 Mar 2015 09:52:11 +0000 (UTC) Received: by wgbcc7 with SMTP id cc7so84671660wgb.0; Fri, 20 Mar 2015 02:52:10 -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-type:content-disposition:in-reply-to :user-agent; bh=oKMlXH5KecNR32lFYRx9KzrXAYPovxcyh6Tvbko+1sY=; b=kYoaxidB6EabFdBCyXedylfcvXRfbFYcvuCdQPJxZke+VxdjltI1uAZgqUXxuVPQ0g w6e21rCUPmVxeuCRnLhJkPKxAJT0RB5k3J2l3Np26I1ThZ5rDYJlH+IOvgB8ShcDQ1nT Mdco16yoFf2/EQq6lWeFcI9F1JWS90T2dhNJPGU+jdLkIJNNDOEM8VhIQFjYYYUcc5Uk SeBU+PMNvQ0qOnMEXy6fic1vwTKu4sWL+3zUQHRx2kIL9jU6gSqyvkrO+ENZNbAIp6m4 ntD2Z4iuBS+Xo9Z57MmR0UxVezmpX1M7YNzqYGZ2xrYHW5jvVXd2HUc2hCpOKWOxSAdU ocsw== X-Received: by 10.180.187.19 with SMTP id fo19mr23511197wic.2.1426845130192; Fri, 20 Mar 2015 02:52:10 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id md2sm2237396wic.19.2015.03.20.02.52.08 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 20 Mar 2015 02:52:09 -0700 (PDT) Date: Fri, 20 Mar 2015 10:52:06 +0100 From: Mateusz Guzik To: Konstantin Belousov Subject: Re: Build failed in Jenkins: FreeBSD_HEAD-tests2 #854 Message-ID: <20150320095206.GA27736@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Konstantin Belousov , jenkins-admin@freebsd.org, freebsd-current@freebsd.org References: <615255742.14.1426582002157.JavaMail.jenkins@jenkins-9.freebsd.org> <812621580.0.1426817304110.JavaMail.jenkins@jenkins-9.freebsd.org> <20150320022026.GA10296@dft-labs.eu> <20150320093451.GN2379@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150320093451.GN2379@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, jenkins-admin@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Mar 2015 09:52:12 -0000 On Fri, Mar 20, 2015 at 11:34:51AM +0200, Konstantin Belousov wrote: > On Fri, Mar 20, 2015 at 03:20:26AM +0100, Mateusz Guzik wrote: > > On Fri, Mar 20, 2015 at 02:08:23AM +0000, jenkins-admin@freebsd.org wrote: > > > lib/libc/sys/setrlimit_test:setrlimit_nproc -> maxproc limit exceeded by uid 977 (pid 29170); see tuning(7) and login.conf(5) > > > passed [0.551s] > > > lib/libc/sys/setrlimit_test:setrlimit_perm -> panic: mutex process lock not owned at /builds/FreeBSD_HEAD/sys/kern/kern_prot.c:1974 > > > cpuid = 1 > > > KDB: stack backtrace: > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe009749a8e0 > > > vpanic() at vpanic+0x189/frame 0xfffffe009749a960 > > > panic() at panic+0x43/frame 0xfffffe009749a9c0 > > > __mtx_assert() at __mtx_assert+0xc2/frame 0xfffffe009749a9d0 > > > proc_set_cred() at proc_set_cred+0x36/frame 0xfffffe009749a9f0 > > > fork1() at fork1+0x27e/frame 0xfffffe009749aac0 > > > sys_fork() at sys_fork+0x1f/frame 0xfffffe009749aae0 > > > amd64_syscall() at amd64_syscall+0x27f/frame 0xfffffe009749abf0 > > > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe009749abf0 > > > --- syscall (0, FreeBSD ELF64, nosys), rip = 0x8019c216a, rsp = 0x7fffffffc2d8, rbp = 0x7fffffffc340 --- > > > KDB: enter: panic > > > [ thread pid 660 tid 100065 ] > > > Stopped at kdb_enter+0x3e: movq $0,kdb_why > > > > Weird, I'll look at that. > > This is due to p_ucred not initialized on allocation of struc proc. > The member is not in p_startzero/p_endzero region, so it contains > garbage at the stage of the fork where proc_set_cred() is called, > while the function makes assertion based on the p_ucred content. Yes I figured, but proc_init left me quite puzzled: static int proc_init(void *mem, int size, int flags) { struct proc *p; p = (struct proc *)mem; SDT_PROBE(proc, kernel, init, entry, p, size, flags, 0, 0); p->p_sched = (struct p_sched *)&p[1]; bzero(&p->p_mtx, sizeof(struct mtx)); mtx_init(&p->p_mtx, "process lock", NULL, MTX_DEF | MTX_DUPOK); We bzero only the first mutex to make sure mtx_init works? mtx_init(&p->p_slock, "process slock", NULL, MTX_SPIN); mtx_init(&p->p_statmtx, "pstatl", NULL, MTX_SPIN); mtx_init(&p->p_itimmtx, "pitiml", NULL, MTX_SPIN); mtx_init(&p->p_profmtx, "pprofl", NULL, MTX_SPIN); How about these? So the trivial fix would be to move p_ucred or explicitely NULL it here. All these mtx_init calls would use MTX_NEW flag and bzero could be eliminated. I'll commit a quick fix shortly. I'm really confused what's the purpose of checking for double initialisation of locks. I'm not aware of any actual bug caught by this, on the other hand I'm aware of quite a few cases where bzero or M_ZERO were used just to make sure mtx_init passes. So preferably I would just get rid of such a check and effectively make the behaviour as if MTX_NEW is always used. -- Mateusz Guzik From owner-freebsd-current@FreeBSD.ORG Fri Mar 20 05:00:27 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 818E9C87; Fri, 20 Mar 2015 05:00:27 +0000 (UTC) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::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 124A5F17; Fri, 20 Mar 2015 05:00:27 +0000 (UTC) Received: by wetk59 with SMTP id k59so73450180wet.3; Thu, 19 Mar 2015 22:00:25 -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:cc:content-type; bh=NRIZZ0vEbKaUHva6djanc4C9oXVlY+wI2P8uOXMnAsQ=; b=djwS+jeg2OOsIbmNTx2x5uUrMinuxwFsV3QfDYoQQWAKszmgrcUedyb/Qn1aV8AsAT UG0XdS8b4JPElnDSKkoujzutsmi33kOyTzfiAE6i7v4BPtMsLUXklcmJQyDjM7tpN/kJ t5UsfcpTYUF41rZRxIUwdbK7rv5d8JT2cWBkZ6f3uqZhzDqSPPT2XF2gzMOTa8vOVLiv ZAe44RTMxNQ/kb9OMUptaPtyxjVBsPBuntpH5dil+1TdDy/pYMB2j8RP41zF4bhn+90Q Zcv0t2+vqu47pOq1gMNWxtCog9FJFxNaD0JkyRL9j3Kw8XTMszPuOdwyoTP3z7ZQpt6p fPhw== X-Received: by 10.194.60.173 with SMTP id i13mr155074615wjr.124.1426827625121; Thu, 19 Mar 2015 22:00:25 -0700 (PDT) MIME-Version: 1.0 Sender: fedor.indutny@gmail.com Received: by 10.27.9.208 with HTTP; Thu, 19 Mar 2015 22:00:04 -0700 (PDT) From: Fedor Indutny Date: Thu, 19 Mar 2015 22:00:04 -0700 X-Google-Sender-Auth: flvQcAMapIYWSzT5ik5r_ojPgM8 Message-ID: Subject: SA_SIGINFO | SA_RESETHAND fix backport To: freebsd-current@freebsd.org X-Mailman-Approved-At: Fri, 20 Mar 2015 11:27:26 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Mark Johnston X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Mar 2015 05:00:27 -0000 Hello people! While trying to fix node.js/io.js issue with signal handling on FreeBSD 10.1, I have found that the problem was due to a kernel bug. Luckily that bug is fixed in: https://github.com/freebsd/freebsd/commit/4501dadd00cece6d06392c42e5fc6af07731e451 But it looks like the fix wasn't backported to 10.x . Do you think it might be possible to do it? I'd really appreciate this. Thank you, Fedor. From owner-freebsd-current@FreeBSD.ORG Fri Mar 20 12:21:33 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3911933A; Fri, 20 Mar 2015 12:21:33 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 B382D29A; Fri, 20 Mar 2015 12:21:32 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t2KCLQqu002927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Mar 2015 14:21:26 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t2KCLQqu002927 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t2KCLQkE002926; Fri, 20 Mar 2015 14:21:26 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 20 Mar 2015 14:21:26 +0200 From: Konstantin Belousov To: Mateusz Guzik , jenkins-admin@freebsd.org, freebsd-current@freebsd.org Subject: Re: Build failed in Jenkins: FreeBSD_HEAD-tests2 #854 Message-ID: <20150320122125.GP2379@kib.kiev.ua> References: <615255742.14.1426582002157.JavaMail.jenkins@jenkins-9.freebsd.org> <812621580.0.1426817304110.JavaMail.jenkins@jenkins-9.freebsd.org> <20150320022026.GA10296@dft-labs.eu> <20150320093451.GN2379@kib.kiev.ua> <20150320095206.GA27736@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150320095206.GA27736@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) 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.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Mar 2015 12:21:33 -0000 On Fri, Mar 20, 2015 at 10:52:06AM +0100, Mateusz Guzik wrote: > On Fri, Mar 20, 2015 at 11:34:51AM +0200, Konstantin Belousov wrote: > > On Fri, Mar 20, 2015 at 03:20:26AM +0100, Mateusz Guzik wrote: > > > On Fri, Mar 20, 2015 at 02:08:23AM +0000, jenkins-admin@freebsd.org wrote: > > > > lib/libc/sys/setrlimit_test:setrlimit_nproc -> maxproc limit exceeded by uid 977 (pid 29170); see tuning(7) and login.conf(5) > > > > passed [0.551s] > > > > lib/libc/sys/setrlimit_test:setrlimit_perm -> panic: mutex process lock not owned at /builds/FreeBSD_HEAD/sys/kern/kern_prot.c:1974 > > > > cpuid = 1 > > > > KDB: stack backtrace: > > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe009749a8e0 > > > > vpanic() at vpanic+0x189/frame 0xfffffe009749a960 > > > > panic() at panic+0x43/frame 0xfffffe009749a9c0 > > > > __mtx_assert() at __mtx_assert+0xc2/frame 0xfffffe009749a9d0 > > > > proc_set_cred() at proc_set_cred+0x36/frame 0xfffffe009749a9f0 > > > > fork1() at fork1+0x27e/frame 0xfffffe009749aac0 > > > > sys_fork() at sys_fork+0x1f/frame 0xfffffe009749aae0 > > > > amd64_syscall() at amd64_syscall+0x27f/frame 0xfffffe009749abf0 > > > > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe009749abf0 > > > > --- syscall (0, FreeBSD ELF64, nosys), rip = 0x8019c216a, rsp = 0x7fffffffc2d8, rbp = 0x7fffffffc340 --- > > > > KDB: enter: panic > > > > [ thread pid 660 tid 100065 ] > > > > Stopped at kdb_enter+0x3e: movq $0,kdb_why > > > > > > Weird, I'll look at that. > > > > This is due to p_ucred not initialized on allocation of struc proc. > > The member is not in p_startzero/p_endzero region, so it contains > > garbage at the stage of the fork where proc_set_cred() is called, > > while the function makes assertion based on the p_ucred content. > > Yes I figured, but proc_init left me quite puzzled: > > static int > proc_init(void *mem, int size, int flags) > { > struct proc *p; > > p = (struct proc *)mem; > SDT_PROBE(proc, kernel, init, entry, p, size, flags, 0, 0); > p->p_sched = (struct p_sched *)&p[1]; > bzero(&p->p_mtx, sizeof(struct mtx)); > mtx_init(&p->p_mtx, "process lock", NULL, MTX_DEF | MTX_DUPOK); > > We bzero only the first mutex to make sure mtx_init works? > > mtx_init(&p->p_slock, "process slock", NULL, MTX_SPIN); > mtx_init(&p->p_statmtx, "pstatl", NULL, MTX_SPIN); > mtx_init(&p->p_itimmtx, "pitiml", NULL, MTX_SPIN); > mtx_init(&p->p_profmtx, "pprofl", NULL, MTX_SPIN); > > How about these? > > So the trivial fix would be to move p_ucred or explicitely NULL it here. > > All these mtx_init calls would use MTX_NEW flag and bzero could be > eliminated. It is self-contradicional to initialize p_ucred to pacify assertion, while removing bzero to avoid doing extra work to silence too eager assert. > > I'll commit a quick fix shortly. > > I'm really confused what's the purpose of checking for double > initialisation of locks. I'm not aware of any actual bug caught by this, > on the other hand I'm aware of quite a few cases where bzero or M_ZERO > were used just to make sure mtx_init passes. There were bugs catched by this. > > So preferably I would just get rid of such a check and effectively make > the behaviour as if MTX_NEW is always used. From owner-freebsd-current@FreeBSD.ORG Fri Mar 20 12:33:04 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE22F600 for ; Fri, 20 Mar 2015 12:33:04 +0000 (UTC) Received: from mail.kronometrix.org (mail.kronometrix.org [54.72.43.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "kronometrix.org", Issuer "kronometrix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 720CB630 for ; Fri, 20 Mar 2015 12:33:03 +0000 (UTC) Received: from nereid (188-127-209-196.cust.suomicom.net [188.127.209.196]) (authenticated bits=0) by mail.kronometrix.org (8.14.9/8.14.9) with ESMTP id t2KCLPej012200 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 20 Mar 2015 12:21:26 GMT (envelope-from sparvu@kronometrix.org) Date: Fri, 20 Mar 2015 14:20:02 +0200 From: Stefan Parvu To: freebsd-current@freebsd.org Subject: cant use Xorg after r277486 on Asus Zenbook Message-Id: <20150320142002.bf6d7641ba65c7147af5b61e@kronometrix.org> Organization: kronometrix.org X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.25; 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.18-1 Precedence: 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, 20 Mar 2015 12:33:05 -0000 Hi, Im currently running 11.0-CURRENT #0 r277486 on Asus Zenbook laptop [1]. Im happy, there are some issues with iwn driver but it does work enough stable. Xorg, Sound, Networking functional. Even power management works enough decent to get 3hrs or so without a power adapter connected. Now I have discovered Im not able to update to any new snapshots after r277486. Xorg refuses to work, Im getting a blank screen with no possibility to have a functional vt restoration. I always need to reboot. The kernel is up I can use the keyboard so the only trouble seems to come from Xorg / vt. I have tried updating my laptop to: r278452, r278908, r279514, r279813. No luck. If I go back to use r277486 then my Xorg and vt start functioning correctly. Im using the i915 driver for Xorg and my config is in [1]. Any ideas what is this about ? Were any changes after r277486 regarding i915 or Xorg ? I tried to create a new xorg.conf, reuse the old one whatever. No luck. Many thanks, -- Stefan Parvu [1] - http://kronometrix.blogspot.fi/2014/10/asus-zenbook-and-freebsd-11.html From owner-freebsd-current@FreeBSD.ORG Fri Mar 20 14:07:24 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7FD081E5; Fri, 20 Mar 2015 14:07:24 +0000 (UTC) Received: from ivan-labs.com (ivan-labs.com [162.243.251.239]) by mx1.freebsd.org (Postfix) with ESMTP id 3D226B8; Fri, 20 Mar 2015 14:07:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by ivan-labs.com (Postfix) with ESMTP id 20213121108; Fri, 20 Mar 2015 17:00:01 +0300 (MSK) X-Virus-Scanned: Debian amavisd-new at Received: from ivan-labs.com ([127.0.0.1]) by localhost (ivan-labs.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuxQ27PWPNXZ; Fri, 20 Mar 2015 17:00:00 +0300 (MSK) Received: from [192.168.43.253] (unknown [149.62.201.153]) by ivan-labs.com (Postfix) with ESMTPSA id 1EFD81206B7; Fri, 20 Mar 2015 16:59:59 +0300 (MSK) Message-ID: <550C27D8.2010105@ivan-labs.com> Date: Fri, 20 Mar 2015 15:59:52 +0200 From: "Ivan A. Kosarev" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Use of chunksize before initialization Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Ed Maste X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Mar 2015 14:07:24 -0000 Hello everybody, The malloc_init_hard() function defined in jemalloc_jemalloc.c, FreeBSD 11 r277486 reads: static bool malloc_init_hard(void) { ... if (base_boot()) { malloc_mutex_unlock(&init_lock); eturn (true); } if (chunk_boot()) { malloc_mutex_unlock(&init_lock); return (true); } ... The second call initializes the 'chunksize' global variable defined in jemalloc_chunk.c: bool chunk_boot(void) { /* Set variables according to the value of opt_lg_chunk. */ chunksize = (ZU(1) << opt_lg_chunk); assert(chunksize >= PAGE); ... However, it seems the first call to base_boot() depends on that variable already: (gdb) bt #0 thr_kill () at thr_kill.S:3 #1 0x0000000801241408 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:51 #2 0x000000000041d817 in __interceptor_raise () at /usr/home/ik/llvm/llvm.current/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:2097 #3 0x000000080123f969 in abort () at /usr/src/lib/libc/stdlib/abort.c:65 #4 0x000000000041c5d9 in __interceptor_abort () at /usr/home/ik/llvm/llvm.current/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:1851 #5 0x00000008011a8d64 in __je_chunk_alloc (size=, alignment=, base=, zero=, dss_prec=dss_prec_disabled) at jemalloc_chunk.c:150 #6 0x00000008011a9bfc in base_pages_alloc (minsize=128) at jemalloc_base.c:35 #7 __je_base_alloc (size=) at jemalloc_base.c:57 #8 0x00000008011a9c96 in __je_base_calloc (number=, size=6) at jemalloc_base.c:74 #9 0x00000008008ae548 in mutex_init (calloc_cb=0x0, mutex=, mutex_attr=) at /usr/src/lib/libthr/thread/thr_mutex.c:145 #10 _pthread_mutex_init_calloc_cb (mutex=0x801487c90, calloc_cb=0x0) at /usr/src/lib/libthr/thread/thr_mutex.c:229 #11 0x00000008011a18da in __je_malloc_mutex_init (mutex=0x18744) at jemalloc_mutex.c:97 #12 0x00000008011b428d in malloc_init_hard () at jemalloc_jemalloc.c:698 #13 malloc_init () at jemalloc_jemalloc.c:296 #14 0x0000000801243ea2 in ?? () from /lib/libc.so.7 #15 0x00000008006a5400 in ?? () #16 0x000000080089e5b0 in ?? () from /libexec/ld-elf.so.1 #17 0x00007fffffffe0b0 in ?? () #18 0x0000000801139d06 in _init () from /lib/libc.so.7 #19 0x00007fffffffe0b0 in ?? () Note that base_pages() calls chunk_alloc() with chucksize used as the alignment value: static bool base_pages_alloc(size_t minsize) { ... base_pages = chunk_alloc(csize, chunksize, true, &zero, chunk_dss_prec_get()); ... and the latter tests it against zero: void * chunk_alloc(size_t size, size_t alignment, bool base, bool *zero, dss_prec_t dss_prec) { ... assert(alignment != 0); .... so we sometimes we end up with: : jemalloc_chunk.c:152: Failed assertion: "alignment != 0" Here's more of failures of this kind around: http://lab.llvm.org:8011/builders/sanitizer_x86_64-freebsd/builds/4758/steps/make-check-tsan/logs/stdio Can you please let me know if the analysis is correct and there's something to fix about initialization of the variable? Thanks. -- From owner-freebsd-current@FreeBSD.ORG Fri Mar 20 14:48:18 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8DF92DF6 for ; Fri, 20 Mar 2015 14:48:18 +0000 (UTC) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::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 41FD974C for ; Fri, 20 Mar 2015 14:48:18 +0000 (UTC) Received: by iecvj10 with SMTP id vj10so94598713iec.0 for ; Fri, 20 Mar 2015 07:48:17 -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:content-type; bh=jUdb69tWF361idFnXN+42xnl+VKfySV0OMgz2JDaAg0=; b=fWN9/0oD6NGDTT/pB3GiqE8o6EQKYFxEoYBzdPgLZ3rXlZxjAVLT4KABLsElJIOl+j rb9oHUD5NNpPulCcxf7S9FHMzID5ypOLUi5KxPshBsk5sQ0EwrQT2Ij6tolopmcUhZG8 NUlZ4X4fL9/8FKtVvS/PEJ2iocCIwxglxiNKQJtTPuNHXFMwYmv6938Ge3ZRkx+xvBbU OB95hy2CEAodxBMkA9hnAXwTOtxja1ZeBRP8UW4bAtsae/9J3fsnV5Ns9n9z9kFEm1br QIdFWqxEC3h7O/XFqmReqHbnGYxMlUYdPiVuy3qgRk0Lvo9kxLXr5Y0l4LCd2lMgGVqw Izfw== X-Received: by 10.107.18.226 with SMTP id 95mr131749208ios.84.1426862897685; Fri, 20 Mar 2015 07:48:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.55.167 with HTTP; Fri, 20 Mar 2015 07:47:57 -0700 (PDT) In-Reply-To: <2A8C0814-E644-4350-85B8-17B468D79BFF@gmail.com> References: <64AF7708-217B-4AC0-A47A-AD1B0BFF7EDC@gmail.com> <885DA4D0-9644-4F06-97C9-04EAD7B4958C@gmail.com> <98CF988A-D9DB-49AD-8CFF-3B438F892730@gmail.com> <2A8C0814-E644-4350-85B8-17B468D79BFF@gmail.com> From: Miguel Clara Date: Fri, 20 Mar 2015 14:47:57 +0000 Message-ID: Subject: Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Mar 2015 14:48:18 -0000 On Thu, Feb 26, 2015 at 2:52 AM, Garrett Cooper wrote: > > On Feb 25, 2015, at 18:08, Kevin Oberman wrote: > > On Wed, Feb 25, 2015 at 2:30 PM, Garrett Cooper > wrote: > >> On Feb 25, 2015, at 14:19, Miguel Clara wrote: >> >> ... >> >> > I noticed this too, but in that case why doesn't it affect all users? >> (or all the ones using dnscrypt+local_unbound) maybe something changed i= n >> "NETWORKING" recently? >> > >> > Hum: >> > >> https://svnweb.freebsd.org/base/head/etc/rc.d/NETWORKING?r1=3D275299&r2= =3D278704 >> > >> > Interesting, as I am using the most recent version which does not >> REQUIRE local_unbound >> > >> > I'm even more confused now :| >> > >> > >> > So it has to come after SERVERS but before local_unbound. But >> NETWORKING depends on local_unbound they are both dependent on NEWORKING >> which has to be after SERVERS. Can you say fubar! Clearly broken. And th= is >> means that removing SERVERS will re-shuffle the order more appropriately= . >> > >> > It seems that the behavior of rcorder is not as documented as well as >> being undefined when circular dependencies occur. The man page says that >> rcorder aborts when it encounters a circular dependency, but that is not >> the case. It probably is best that it not die, but that leaves things in= an >> unknown and inconsistant state, which is also a very bad idea. I guess w= hen >> a circular dependency is encountered, a dichotomy occurs. >> >> Now you know why I=E2=80=99m so curious about all of this stuff. >> >> When I was working on ^/projects/building-blocks, I was able to move mos= t >> of these pieces around by changing REQUIRE: to BEFORE:, but I noticed th= at >> it changes the rcorder a bit, so I haven=E2=80=99t been super gung ho in >> implementing my change. >> >> I think there are a couple bugs present on 9-STABLE/10-STABLE/11-CURRENT= : >> >> - Things go awry if named is removed/not installed. >> - Things go awry if local_unbound is removed (which would have been the >> case if the rc.d script was removed from your system, which existed befo= re >> my changes). >> - Other rc.d scripts not being present might break assumptions. >> >> I need to create dummy providers for certain logical stages (DNS is one >> of them) to solve part of this problem and provide third parties with a >> mechanism that can be depended on (I wish applications were written in a >> more robust manner to fail gracefully and retry instead of failing flat = on >> their face, but as I=E2=80=99ve seen at several jobs, getting developers= to fail, >> then retry is hard :(=E2=80=A6). >> >> Another short-term hack: >> >> Install dummy/no-op providers so the ordering is preserved, then remove >> the hacks after all of the bugs have been shaken out. >> >> Thanks! >> > > Garret, > > Also undocumented (except in rcorder.c) is that the lack of a provider is > not an error. This effectively makes a list of providers into an OR. So, > for name service the normal list is "named local_unbound unbound" and any > will work for ordering and having none is a no-op, so if you don't run an= y > nameserver (or kerberos or whatever provider), it is not an issue. As lon= g > as rcorder finds a provider, it will be used to set the order, but the la= ck > of any or all providers just means that the specified provider is ignored > and if a REQUIRES or BEFORE lists no existing providers, the statement is > simply ignored. > > The real problem is that there is no defined rule for behavior in the > event of a circular dependency and any change to any decision point in th= e > ordering process may change the way the ordering flips. That is why these > things are such a royal pain to debug. A change in any rc.d script may > cause the ordering of seemingly unrelated scripts to change, perhaps > drastically, and the error messages, while not misleading, is only a > starting point in tracking this down. This means there may be time bombs > that break working ports without their being touched or even re-installed= . > And the triggering change my, itself be correct. > > > Or etc/rc.d/named... > > PROVIDES: DNS > > I'm going to post a fix up for this on arch@/rc@ because it needs to be > solved in a saner way -- especially for systems that are pedantic about > rcorder, like our version at $work. > > I re-sync my source and noticed the change while doing the mergemaster part... with this I can now change dnscrypt to: @@ -4,7 +4,7 @@ # # PROVIDE: dnscrypt_proxy # REQUIRE: SERVERS cleanvar -# BEFORE: named local_unbound unbound +# BEFORE: DNS And this makes the rcorder ok for dnscrypt-proxy From owner-freebsd-current@FreeBSD.ORG Fri Mar 20 16:05:22 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 53398BFB; Fri, 20 Mar 2015 16:05:22 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 2BE62FF6; Fri, 20 Mar 2015 16:05:21 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 26BB99E327; Fri, 20 Mar 2015 16:05:15 +0000 (UTC) Message-ID: <550C4552.3030303@freebsd.org> Date: Fri, 20 Mar 2015 12:05:38 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Fedor Indutny , freebsd-current@freebsd.org Subject: Re: SA_SIGINFO | SA_RESETHAND fix backport References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="reBrtmH2nMsSn8KwbPThCUXUfFM8wqG2A" Cc: Mark Johnston X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Mar 2015 16:05:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --reBrtmH2nMsSn8KwbPThCUXUfFM8wqG2A Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2015-03-20 01:00, Fedor Indutny wrote: > Hello people! >=20 > While trying to fix node.js/io.js issue with signal handling > on FreeBSD 10.1, I have found that the problem was due to a kernel > bug. Luckily that bug is fixed in: >=20 > https://github.com/freebsd/freebsd/commit/4501dadd00cece6d06392c42e5fc6= af07731e451 >=20 > But it looks like the fix wasn't backported to 10.x . >=20 > Do you think it might be possible to do it? I'd really appreciate > this. >=20 > Thank you, > Fedor. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 That change was merged to the stable/10 branch in December https://svnweb.freebsd.org/base?view=3Drevision&revision=3D275456 --=20 Allan Jude --reBrtmH2nMsSn8KwbPThCUXUfFM8wqG2A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJVDEVVAAoJEJrBFpNRJZKffCYQALlORrDsJbis8qlffFz7np9W B180eF6QfB5qqoZxkw8XIdN9vgcx3ol4qNgS3uJVeBBIEnwGwXulO5YOyPHWR2eB 6fsE40+LvsuTcLtQn/vWw25qzkWJ6bwTHQaTgPpZHdYU6AWuqhx+r+/laV3VQL9f 1dJg3dGV+tYAiiaLPiAJy8Ub/MBQAjF2oPzA0jsWGqRSH7k2G91JQTKqYjtDBn68 ancc4UaMKedug9cYUqnp4bbKv+v9DSXKcgreCDWt1wxQmKz4OHbu6WbLdSGJbLLv J8uwfThDpqRO/D5xLA/9DTq7R0kcI+HKHkfTZgk1t73OH5M2+1grDKUxRpFhjTPO 8ZIY+OgSLbIilWS7Jr3P4eEDXGzMYG5KWOc3kvbxfKPGim7gJ9LBeU+QzbmMBw9c wF7EeY9OPsS0HIhmOCLgQT4maynvQ7G8tKub6JoOECvVlokCmu7qCqqIcIrp53o/ pXZm8jFo2P36dwhXuSdZXCtumkjLdK5b0F3ZrYbZgCTe5eR5mbdeBzH6ofTTvawP I/0gqb5w+IePsZLpXTtwbi0Rb0HW0xJ5JqxgSzV4zezJD3dRjqzQB/qGLC/e8TPB 1ZT/BIOGjEntHYo5FDBzoLbnDLzFzMt2aFE+KQBI1JvFT0Nnuu/qaxYsIMt+pCef wK2Qocy0k3IuQG2uamJt =S6T1 -----END PGP SIGNATURE----- --reBrtmH2nMsSn8KwbPThCUXUfFM8wqG2A-- From owner-freebsd-current@FreeBSD.ORG Fri Mar 20 16:14:38 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7472EF7C; Fri, 20 Mar 2015 16:14:38 +0000 (UTC) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::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 0500F173; Fri, 20 Mar 2015 16:14:38 +0000 (UTC) Received: by wgdm6 with SMTP id m6so93363683wgd.2; Fri, 20 Mar 2015 09:14:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ZOCNPZ4H06kX3iryw4vfzH2xEf+8sfVLRzpjLQVXjLQ=; b=uKL+kOBvBKw1NSSA2KgOezVlGg5efXUTGdnMIVaTaZ0B7LzmuwhmAbT33MI54MV0B1 fxOeBsd4d/wH9BAMY1hBttscnPIEVOodECyial8AM0J8Wjnf7XBta1r8LYYHOP9vkKKi 2BY6tNMvx+LAV4i0xiI3ZAXp6mvO/FJYwtVrQxJ2UaqZbLPjO8ESXw1vEYoLtIFYmQhX cyIjD2H3GlRqmEQDz4vlY3yUa056+ht4g1UTBDEzUfmcD6OAlr9dyZoMFOUWcUDEN11N GH79zcVtMxTt0+Qo0nvHr6INWpSX+FlXx4q1zSk+eImfexGJSWTh1HjmZLPpbgn8qTqc 3Ukg== MIME-Version: 1.0 X-Received: by 10.180.189.37 with SMTP id gf5mr26356148wic.86.1426868076412; Fri, 20 Mar 2015 09:14:36 -0700 (PDT) Sender: fedor.indutny@gmail.com Received: by 10.27.9.208 with HTTP; Fri, 20 Mar 2015 09:14:36 -0700 (PDT) In-Reply-To: <550C4552.3030303@freebsd.org> References: <550C4552.3030303@freebsd.org> Date: Fri, 20 Mar 2015 09:14:36 -0700 X-Google-Sender-Auth: 9aYf3TLaNxoIpp94x1F_YRz5zFw Message-ID: Subject: Re: SA_SIGINFO | SA_RESETHAND fix backport From: Fedor Indutny To: Allan Jude Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-current@freebsd.org" , Mark Johnston X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Mar 2015 16:14:38 -0000 Allan, Thank you for reply! And sorry, I didn't seen it. How long do you think it may take to get it released and will it be included in 10.2? Thank you, Fedor. On Friday, March 20, 2015, Allan Jude wrote: > On 2015-03-20 01:00, Fedor Indutny wrote: > > Hello people! > > > > While trying to fix node.js/io.js issue with signal handling > > on FreeBSD 10.1, I have found that the problem was due to a kernel > > bug. Luckily that bug is fixed in: > > > > > https://github.com/freebsd/freebsd/commit/4501dadd00cece6d06392c42e5fc6af07731e451 > > > > But it looks like the fix wasn't backported to 10.x . > > > > Do you think it might be possible to do it? I'd really appreciate > > this. > > > > Thank you, > > Fedor. > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscribe@freebsd.org " > > > > That change was merged to the stable/10 branch in December > > https://svnweb.freebsd.org/base?view=revision&revision=275456 > > -- > Allan Jude > > From owner-freebsd-current@FreeBSD.ORG Fri Mar 20 16:26:26 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DBAE04AC for ; Fri, 20 Mar 2015 16:26:25 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id B2D252EE for ; Fri, 20 Mar 2015 16:26:25 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id AF0499E3CE for ; Fri, 20 Mar 2015 16:26:23 +0000 (UTC) Message-ID: <550C4A48.30700@freebsd.org> Date: Fri, 20 Mar 2015 12:26:48 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: SA_SIGINFO | SA_RESETHAND fix backport References: <550C4552.3030303@freebsd.org> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LI5ewRkeo8aIgXqBgP8CQhQxkNQGKEMm6" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Mar 2015 16:26:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LI5ewRkeo8aIgXqBgP8CQhQxkNQGKEMm6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2015-03-20 12:14, Fedor Indutny wrote: > Allan, >=20 > Thank you for reply! And sorry, I didn't seen it. >=20 > How long do you think it may take to get it released and will it be > included in 10.2? >=20 > Thank you, > Fedor. >=20 > On Friday, March 20, 2015, Allan Jude wrote: >=20 >> On 2015-03-20 01:00, Fedor Indutny wrote: >>> Hello people! >>> >>> While trying to fix node.js/io.js issue with signal handling >>> on FreeBSD 10.1, I have found that the problem was due to a kernel >>> bug. Luckily that bug is fixed in: >>> >>> >> https://github.com/freebsd/freebsd/commit/4501dadd00cece6d06392c42e5fc= 6af07731e451 >>> >>> But it looks like the fix wasn't backported to 10.x . >>> >>> Do you think it might be possible to do it? I'd really appreciate >>> this. >>> >>> Thank you, >>> Fedor. >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to " >> freebsd-current-unsubscribe@freebsd.org " >>> >> >> That change was merged to the stable/10 branch in December >> >> https://svnweb.freebsd.org/base?view=3Drevision&revision=3D275456 >> >> -- >> Allan Jude >> >> > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 It will be included in 10.2 yes. However you can run 10-stable to get the fix today https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable= =2Ehtml#stable --=20 Allan Jude --LI5ewRkeo8aIgXqBgP8CQhQxkNQGKEMm6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJVDEpKAAoJEJrBFpNRJZKfonsP/0P/SWf3CY/oRk//6EwMCaVR GuifLuBrIX4wobk9BMB/R6AvxeoHDIErkXGtnbjaJRrIX7t/3ewTeP/Jru8FCZE/ dbof0p7EPSuVroGpqR2CAr3KBkBjZKBC0EtOB6d6PYFCwlLDSyhz54LS0B1ghpe8 M3zR5I5W1v7yrt24dekn9bg+BRGt0CSeDQhZiF4QxqfIB1dgfC+Rgx/RivQgtb3W RXrMM+fiaGj4MidlpQcZbQzH1AJxHjFjNQ4XO5UsuC/RQg/9qV9wVxOiVEv1JS5o atkakWMWa5rvF+MpPkCfRA2CEqS31CoystK2U0FfBYzhEMLWkVa5ZvryZStKIq9c pTjsTFHSY5YMGXVSMN6c/IYNkRvK9aZ+OjRDT/3yNG8A/rPEdgEHVgX4/1i0/gf+ 7N5iBlq+C/Y7/R4FfSMCLpTJJJzAoG3qvRpB+vO/U8lPqvMLjdm/4oEZ4ASC3NMm bjAsRx6BT1vtVI32HnWdDV0d/w8otk2mol6KhKoXzzMD0oGdtUOWkUN5cVBF7QpV NsP5wXj+nti60BDJ43mYfX1dTQpfA6dLPFnirE/YlPAANKSakTxfRIhVvrS6RwxU sctzovHwaNts1b/XfmxBZtbqUVW4u3CpJXt8cB3iO5FDa+e7ydnHeLPe24BI0Juj bkoL0RwLzdlT8odafEpY =mtZ2 -----END PGP SIGNATURE----- --LI5ewRkeo8aIgXqBgP8CQhQxkNQGKEMm6-- From owner-freebsd-current@FreeBSD.ORG Fri Mar 20 16:30:58 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A62197DD for ; Fri, 20 Mar 2015 16:30:58 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 873EC337 for ; Fri, 20 Mar 2015 16:30:58 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id CD9B927F for ; Fri, 20 Mar 2015 16:30:58 +0000 (UTC) Date: Fri, 20 Mar 2015 16:30:58 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1292972777.3.1426869058392.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <94841522.2.1426837280605.JavaMail.jenkins@jenkins-9.freebsd.org> References: <94841522.2.1426837280605.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD-tests2 #856 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Mar 2015 16:30:58 -0000 See ------------------------------------------ [...truncated 3009 lines...] lib/libc/string/strspn:strspn -> passed [0.015s] lib/libc/string/swab:swab_basic -> passed [0.016s] lib/libc/sys/access_test:access_access -> passed [0.020s] lib/libc/sys/access_test:access_fault -> passed [0.016s] lib/libc/sys/access_test:access_inval -> passed [0.016s] lib/libc/sys/access_test:access_notdir -> passed [0.016s] lib/libc/sys/access_test:access_notexist -> passed [0.016s] lib/libc/sys/access_test:access_toolong -> passed [0.015s] lib/libc/sys/chroot_test:chroot_basic -> passed [0.022s] lib/libc/sys/chroot_test:chroot_err -> passed [0.016s] lib/libc/sys/chroot_test:chroot_perm -> passed [0.017s] lib/libc/sys/clock_gettime_test:clock_gettime_real -> passed [0.017s] lib/libc/sys/connect_test:connect_low_port -> passed [0.018s] lib/libc/sys/dup_test:dup2_basic -> passed [0.016s] lib/libc/sys/dup_test:dup2_err -> passed [0.016s] lib/libc/sys/dup_test:dup2_max -> passed [0.016s] lib/libc/sys/dup_test:dup2_mode -> passed [0.034s] lib/libc/sys/dup_test:dup3_err -> passed [0.016s] lib/libc/sys/dup_test:dup3_max -> passed [0.015s] lib/libc/sys/dup_test:dup3_mode -> passed [0.029s] lib/libc/sys/dup_test:dup_err -> passed [0.015s] lib/libc/sys/dup_test:dup_max -> passed [0.021s] lib/libc/sys/dup_test:dup_mode -> passed [0.034s] lib/libc/sys/fsync_test:fsync_err -> passed [0.015s] lib/libc/sys/fsync_test:fsync_sync -> passed [0.037s] lib/libc/sys/getcontext_test:getcontext_err -> passed [0.014s] lib/libc/sys/getcontext_test:setcontext_err -> passed [0.016s] lib/libc/sys/getcontext_test:setcontext_link -> passed [0.016s] lib/libc/sys/getgroups_test:getgroups_err -> expected_failure: Reported as kern/189941: /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/sys/t_getgroups.c:63: getgroups(-1, gidset) == -1 not met [0.016s] lib/libc/sys/getgroups_test:getgroups_getgid -> passed [0.016s] lib/libc/sys/getgroups_test:getgroups_setgid -> passed [0.017s] lib/libc/sys/getgroups_test:getgroups_zero -> passed [0.016s] lib/libc/sys/getitimer_test:getitimer_empty -> passed [0.016s] lib/libc/sys/getitimer_test:getitimer_err -> passed [0.015s] lib/libc/sys/getitimer_test:setitimer_basic -> passed [0.016s] lib/libc/sys/getitimer_test:setitimer_err -> passed [0.015s] lib/libc/sys/getitimer_test:setitimer_old -> passed [0.014s] lib/libc/sys/getlogin_test:getlogin_r_err -> passed [0.016s] lib/libc/sys/getlogin_test:getlogin_same -> passed [0.016s] lib/libc/sys/getlogin_test:setlogin_basic -> passed [0.017s] lib/libc/sys/getlogin_test:setlogin_err -> passed [0.017s] lib/libc/sys/getlogin_test:setlogin_perm -> passed [0.017s] lib/libc/sys/getpid_test:getpid_process -> passed [0.025s] lib/libc/sys/getpid_test:getpid_thread -> passed [0.019s] lib/libc/sys/getrusage_test:getrusage_err -> passed [0.016s] lib/libc/sys/getrusage_test:getrusage_sig -> passed [0.016s] lib/libc/sys/getrusage_test:getrusage_utime_back -> passed [2.137s] lib/libc/sys/getrusage_test:getrusage_utime_zero -> skipped: this testcase passes/fails sporadically on FreeBSD/i386 @ r273153 (at least) [0.017s] lib/libc/sys/getsid_test:getsid_current -> passed [0.015s] lib/libc/sys/getsid_test:getsid_err -> passed [0.015s] lib/libc/sys/getsid_test:getsid_process -> passed [0.016s] lib/libc/sys/gettimeofday_test:gettimeofday_err -> passed [0.015s] lib/libc/sys/gettimeofday_test:gettimeofday_mono -> passed [0.016s] lib/libc/sys/issetugid_test:issetugid_egid -> passed [0.019s] lib/libc/sys/issetugid_test:issetugid_euid -> passed [0.019s] lib/libc/sys/issetugid_test:issetugid_rgid -> passed [0.019s] lib/libc/sys/issetugid_test:issetugid_ruid -> passed [0.018s] lib/libc/sys/kevent_test:kevent_zerotimer -> passed [0.017s] lib/libc/sys/kevent_test:kqueue_desc_passing -> passed [0.018s] lib/libc/sys/kevent_test:kqueue_unsupported_fd -> skipped: no /nonexistent available for testing [0.016s] lib/libc/sys/kill_test:kill_basic -> passed [0.018s] lib/libc/sys/kill_test:kill_err -> passed [0.015s] lib/libc/sys/kill_test:kill_perm -> passed [1.073s] lib/libc/sys/kill_test:kill_pgrp_neg -> passed [0.018s] lib/libc/sys/kill_test:kill_pgrp_zero -> passed [0.018s] lib/libc/sys/link_test:link_count -> passed [0.022s] lib/libc/sys/link_test:link_err -> passed [0.022s] lib/libc/sys/link_test:link_perm -> passed [0.016s] lib/libc/sys/link_test:link_stat -> passed [0.020s] lib/libc/sys/listen_test:listen_err -> passed [0.018s] lib/libc/sys/listen_test:listen_low_port -> passed [0.015s] lib/libc/sys/mincore_test:mincore_err -> passed [0.015s] lib/libc/sys/mincore_test:mincore_resid -> passed [0.038s] lib/libc/sys/mincore_test:mincore_shmseg -> passed [0.017s] lib/libc/sys/mkdir_test:mkdir_err -> passed [0.015s] lib/libc/sys/mkdir_test:mkdir_mode -> passed [1.063s] lib/libc/sys/mkdir_test:mkdir_perm -> passed [0.020s] lib/libc/sys/mkdir_test:mkdir_trail -> passed [0.027s] lib/libc/sys/mkfifo_test:mkfifo_block -> passed [1.092s] lib/libc/sys/mkfifo_test:mkfifo_err -> passed [0.021s] lib/libc/sys/mkfifo_test:mkfifo_nonblock -> passed [1.039s] lib/libc/sys/mkfifo_test:mkfifo_perm -> passed [0.022s] lib/libc/sys/mkfifo_test:mkfifo_stat -> passed [0.020s] lib/libc/sys/mknod_test:mknod_err -> passed [0.019s] lib/libc/sys/mknod_test:mknod_exist -> passed [0.019s] lib/libc/sys/mknod_test:mknod_perm -> passed [0.020s] lib/libc/sys/mknod_test:mknod_stat -> expected_failure: mknod does not allow S_IFREG: /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/sys/t_mknod.c:179: mknod(path, S_IFREG, 0) == 0 not met [0.020s] lib/libc/sys/mlock_test:mlock_clip -> passed [0.016s] lib/libc/sys/mlock_test:mlock_err -> passed [0.016s] lib/libc/sys/mlock_test:mlock_limits -> passed [0.018s] lib/libc/sys/mlock_test:mlock_mmap -> passed [0.016s] lib/libc/sys/mlock_test:mlock_nested -> passed [0.015s] lib/libc/sys/mmap_test:mmap_err -> passed [0.016s] lib/libc/sys/mmap_test:mmap_loan -> passed [0.022s] lib/libc/sys/mmap_test:mmap_prot_1 -> passed [0.020s] lib/libc/sys/mmap_test:mmap_prot_2 -> passed [0.016s] lib/libc/sys/mmap_test:mmap_prot_3 -> passed [0.021s] lib/libc/sys/mmap_test:mmap_truncate -> passed [0.364s] lib/libc/sys/mmap_test:mmap_va0 -> passed [0.016s] lib/libc/sys/mprotect_test:mprotect_access -> passed [0.020s] lib/libc/sys/mprotect_test:mprotect_err -> passed [0.015s] lib/libc/sys/mprotect_test:mprotect_pax -> passed [0.016s] lib/libc/sys/mprotect_test:mprotect_write -> passed [0.017s] lib/libc/sys/msgctl_test:msgctl_err -> passed [0.019s] lib/libc/sys/msgctl_test:msgctl_perm -> passed [0.021s] lib/libc/sys/msgctl_test:msgctl_pid -> passed [2.093s] lib/libc/sys/msgctl_test:msgctl_set -> passed [0.022s] lib/libc/sys/msgctl_test:msgctl_time -> passed [0.019s] lib/libc/sys/msgget_test:msgget_excl -> passed [0.019s] lib/libc/sys/msgget_test:msgget_exit -> passed [0.019s] lib/libc/sys/msgget_test:msgget_init -> passed [0.017s] lib/libc/sys/msgget_test:msgget_limit -> passed [0.017s] lib/libc/sys/msgget_test:msgget_mode -> passed [0.019s] lib/libc/sys/msgrcv_test:msgrcv_basic -> passed [0.018s] lib/libc/sys/msgrcv_test:msgrcv_block -> passed [2.152s] lib/libc/sys/msgrcv_test:msgrcv_err -> passed [0.020s] lib/libc/sys/msgrcv_test:msgrcv_mtype -> passed [0.018s] lib/libc/sys/msgrcv_test:msgrcv_nonblock -> passed [2.087s] lib/libc/sys/msgrcv_test:msgrcv_truncate -> passed [0.020s] lib/libc/sys/msgsnd_test:msgsnd_block -> passed [2.043s] lib/libc/sys/msgsnd_test:msgsnd_count -> passed [0.021s] lib/libc/sys/msgsnd_test:msgsnd_err -> passed [0.018s] lib/libc/sys/msgsnd_test:msgsnd_nonblock -> passed [2.024s] lib/libc/sys/msgsnd_test:msgsnd_perm -> passed [0.020s] lib/libc/sys/msync_test:msync_async -> passed [0.020s] lib/libc/sys/msync_test:msync_err -> passed [0.025s] lib/libc/sys/msync_test:msync_invalidate -> passed [0.020s] lib/libc/sys/msync_test:msync_sync -> passed [0.018s] lib/libc/sys/nanosleep_test:nanosleep_basic -> passed [0.018s] lib/libc/sys/nanosleep_test:nanosleep_err -> passed [0.015s] lib/libc/sys/nanosleep_test:nanosleep_sig -> passed [1.088s] lib/libc/sys/pipe_test:pipe_restart -> passed [2.040s] lib/libc/sys/pipe2_test:pipe2_basic -> passed [0.016s] lib/libc/sys/pipe2_test:pipe2_cloexec -> passed [0.016s] lib/libc/sys/pipe2_test:pipe2_consume -> passed [0.015s] lib/libc/sys/pipe2_test:pipe2_einval -> passed [0.015s] lib/libc/sys/pipe2_test:pipe2_nonblock -> passed [0.016s] lib/libc/sys/poll_test:poll_3way -> passed [10.116s] lib/libc/sys/poll_test:poll_basic -> passed [0.019s] lib/libc/sys/poll_test:poll_err -> passed [0.017s] lib/libc/sys/revoke_test:revoke_basic -> skipped: revoke(2) is only implemented for devfs(5). [0.019s] lib/libc/sys/revoke_test:revoke_err -> skipped: revoke(2) is only implemented for devfs(5). [0.016s] lib/libc/sys/revoke_test:revoke_perm -> skipped: revoke(2) is only implemented for devfs(5). [0.018s] lib/libc/sys/select_test:pselect_sigmask -> passed [1.028s] lib/libc/sys/select_test:pselect_timeout -> passed [0.018s] lib/libc/sys/setrlimit_test:setrlimit_basic -> passed [0.017s] lib/libc/sys/setrlimit_test:setrlimit_current -> passed [0.017s] lib/libc/sys/setrlimit_test:setrlimit_err -> passed [0.017s] lib/libc/sys/setrlimit_test:setrlimit_fsize -> passed [0.022s] lib/libc/sys/setrlimit_test:setrlimit_memlock -> passed [0.018s] lib/libc/sys/setrlimit_test:setrlimit_nofile_1 -> passed [0.018s] lib/libc/sys/setrlimit_test:setrlimit_nofile_2 -> passed [0.017s] lib/libc/sys/setrlimit_test:setrlimit_nproc -> maxproc limit exceeded by uid 977 (pid 44984); see tuning(7) and login.conf(5) passed [0.555s] lib/libc/sys/setrlimit_test:setrlimit_perm -> panic: mutex process lock not owned at /builds/FreeBSD_HEAD/sys/kern/kern_prot.c:1974 cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00974b88e0 vpanic() at vpanic+0x189/frame 0xfffffe00974b8960 panic() at panic+0x43/frame 0xfffffe00974b89c0 __mtx_assert() at __mtx_assert+0xc2/frame 0xfffffe00974b89d0 proc_set_cred() at proc_set_cred+0x36/frame 0xfffffe00974b89f0 fork1() at fork1+0x27e/frame 0xfffffe00974b8ac0 sys_fork() at sys_fork+0x1f/frame 0xfffffe00974b8ae0 amd64_syscall() at amd64_syscall+0x27f/frame 0xfffffe00974b8bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe00974b8bf0 --- syscall (0, FreeBSD ELF64, nosys), rip = 0x8019c516a, rsp = 0x7fffffffc2d8, rbp = 0x7fffffffc340 --- KDB: enter: panic [ thread pid 660 tid 100071 ] Stopped at kdb_enter+0x3e: movq $0,kdb_why db> Traceback (most recent call last): File "/vm/freebsd-ci/scripts/test/run-tests.py", line 152, in main(sys.argv) File "/vm/freebsd-ci/scripts/test/run-tests.py", line 80, in main runTest() File "/vm/freebsd-ci/scripts/test/run-tests.py", line 124, in runTest child2.expect(prompt, timeout=7200) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1451, in expect timeout, searchwindowsize) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1466, in expect_list timeout, searchwindowsize) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1568, in expect_loop raise TIMEOUT(str(err) + '\n' + str(self)) pexpect.TIMEOUT: Timeout exceeded. version: 3.3 command: /usr/sbin/bhyve args: [u'/usr/sbin/bhyve', u'-c', u'2', u'-m', u'2G', u'-AI', u'-H', u'-P', u'-g', u'0', u'-s', u'0:0,hostbridge', u'-s', u'1:0,lpc', u'-s', u'2:0,virtio-net,tap0,mac=58:9c:fc:00:00:2e', u'-s', u'3:0,ahci-hd,/net/jenkins-10.freebsd.org/builds/Build-UFS-image/image/FreeBSD_HEAD/test.img', u'-l', u'com1,stdio', u'vm_test'] searcher: buffer (last 100 chars): 'nter: panic\r\n[ thread pid 660 tid 100071 ]\r\nStopped at kdb_enter+0x3e: movq $0,kdb_why\r\ndb> ' before (last 100 chars): 'nter: panic\r\n[ thread pid 660 tid 100071 ]\r\nStopped at kdb_enter+0x3e: movq $0,kdb_why\r\ndb> ' after: match: None match_index: None exitstatus: None flag_eof: False pid: 82359 child_fd: 4 closed: False timeout: 30 delimiter: logfile: ', mode 'w' at 0x800670150> logfile_read: None logfile_send: None maxread: 2000 ignorecase: False searchwindowsize: None delaybeforesend: 0.05 delayafterclose: 0.1 delayafterterminate: 0.1 Build step 'Execute shell' marked build as failure Recording test results ERROR: Publisher hudson.tasks.junit.JUnitResultArchiver aborted due to exception hudson.AbortException: Test reports were found but none of them are new. Did tests run? For example, is 5 days 15 hr old at hudson.tasks.junit.TestResult.parse(TestResult.java:178) at hudson.tasks.junit.TestResult.parse(TestResult.java:146) at hudson.tasks.junit.TestResult.(TestResult.java:122) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:119) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:92) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2688) at hudson.remoting.UserRequest.perform(UserRequest.java:121) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at hudson.remoting.Request$2.run(Request.java:324) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) at ......remote call to havoc.ysv.freebsd.org(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1356) at hudson.remoting.UserResponse.retrieve(UserRequest.java:221) at hudson.remoting.Channel.call(Channel.java:752) at hudson.FilePath.act(FilePath.java:978) at hudson.FilePath.act(FilePath.java:967) at hudson.tasks.junit.JUnitParser.parseResult(JUnitParser.java:89) at hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:120) at hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:137) at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:74) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:761) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:721) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:670) at hudson.model.Run.execute(Run.java:1775) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240) From owner-freebsd-current@FreeBSD.ORG Fri Mar 20 17:52:59 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DF50FE44 for ; Fri, 20 Mar 2015 17:52:58 +0000 (UTC) Received: from st11p00mm-asmtp002.mac.com (st11p00mm-asmtpout002.mac.com [17.172.81.1]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B0434EEA for ; Fri, 20 Mar 2015 17:52:57 +0000 (UTC) Received: from [10.0.0.132] (ti0025a400-4054.bb.online.no [85.167.26.227]) by st11p00mm-asmtp002.mac.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NLI002TTS7YOS00@st11p00mm-asmtp002.mac.com> for freebsd-current@freebsd.org; Fri, 20 Mar 2015 16:52:51 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-03-20_06:2015-03-20,2015-03-20,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1503200172 Message-id: <550C505F.2030809@icloud.com> Date: Fri, 20 Mar 2015 17:52:47 +0100 From: Anders Bolt-Evensen User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-version: 1.0 To: freebsd-current@freebsd.org Subject: Atheros AR9460 and Acer Aspire V17 Nitro on FreeBSD 11 not working Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Mar 2015 17:52:59 -0000 Hello! Recently I had to buy a new computer as my Mac broke down. I ended up with an Acer Aspire V17 Nitro, which, except for a couple of problems, is all good. One of the problems is that wifi does not work. The wifi driver is an Atheros AR9460. The problem is that when I attempt to scan for my wireless network, nothing shows up at all. On my previous computer, where I used an external Atheros card, everything worked well. Could the following line from dmesg be a symptom of my problems? "ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000" I'm using FreeBSD 11-CURRENT with sources updated today. Hope you can help me, and thanks in advance. A zip file, ath_error.zip should be attached. If not, it is available here: https://www.dropbox.com/s/jfcjam3m63cmbcv/ath_error.zip?dl=0 Have a nice day, everyone. From owner-freebsd-current@FreeBSD.ORG Fri Mar 20 18:01:12 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 834211DD for ; Fri, 20 Mar 2015 18:01:12 +0000 (UTC) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 489CCFED for ; Fri, 20 Mar 2015 18:01:12 +0000 (UTC) Received: by ieclw3 with SMTP id lw3so98592171iec.2 for ; Fri, 20 Mar 2015 11:01: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:date:message-id:subject :from:to:cc:content-type; bh=ieHPlIV6beEdiz7FmJMdeF/Dp6ySwginh6h1J+FRMEI=; b=NqHcVwm/oG4fLMOZYE6mirw6/9KBtW+8Cbg1FNxYlpMfXBs0t4l6olB+BW6Tk1A5KI At4j6HV8q6zuLoVUV3pCSIvdL0X67ooGqKRFfeY5X0E4Tjh9VQJbpF9ygvTsazoC1PVn AFZpXw2fBnN7s4aQeRatVNyRJKYJMBCDYvvcrAh6ey9qkTZc6nap1wvTlxoWQssD6JIy JEzPXSpXhDe+w0LejY3wJ3HD4dCE99kXbVen7XorNDDXGg29UAd0/bt9DbkAFuRw/Y5I mGjl1o1sRP7L195YtHAjf8ib5Lr4zLbEFtmNQZnbXdfFqFUndqv+Znd3Oo1FgG99vdSi iQsA== MIME-Version: 1.0 X-Received: by 10.42.41.200 with SMTP id q8mr2473112ice.61.1426874471505; Fri, 20 Mar 2015 11:01:11 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.17.194 with HTTP; Fri, 20 Mar 2015 11:01:11 -0700 (PDT) In-Reply-To: <550C505F.2030809@icloud.com> References: <550C505F.2030809@icloud.com> Date: Fri, 20 Mar 2015 11:01:11 -0700 X-Google-Sender-Auth: bE_iKfpdd-aU1NRei0QvxdSgpGA Message-ID: Subject: Re: Atheros AR9460 and Acer Aspire V17 Nitro on FreeBSD 11 not working From: Adrian Chadd To: Anders Bolt-Evensen Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Mar 2015 18:01:12 -0000 On 20 March 2015 at 09:52, Anders Bolt-Evensen wrote: > Hello! > > Recently I had to buy a new computer as my Mac broke down. > I ended up with an Acer Aspire V17 Nitro, which, except for a couple of > problems, is all good. > One of the problems is that wifi does not work. The wifi driver is an > Atheros AR9460. > The problem is that when I attempt to scan for my wireless network, nothing > shows up at all. > On my previous computer, where I used an external Atheros card, everything > worked well. > Could the following line from dmesg be a symptom of my problems? > "ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000" > > I'm using FreeBSD 11-CURRENT with sources updated today. What else does it log? -adrian From owner-freebsd-current@FreeBSD.ORG Fri Mar 20 18:22:20 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD426E9A; Fri, 20 Mar 2015 18:22:20 +0000 (UTC) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A11362DA; Fri, 20 Mar 2015 18:22:20 +0000 (UTC) Received: by iedm5 with SMTP id m5so35217011ied.3; Fri, 20 Mar 2015 11:22:20 -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:content-type; bh=yJhsMqlZfmWahHM+kJ7yZ6tPsfOEe9/TysGkh4gjEOY=; b=yjLtUirQVGy5vymRNvQ/G/NuAAjDEEU+KTJkJrBMaaIiBMCh5VCJolM2YZb/u222Ad 0DrrHTNrQZxcDM9Sme5Mm74cd/yqMUVnjWwacUyXOT4ct1zEzcVd5Kh6/JGmUGJ5e6BZ ezVm1VBXiqSAwf1P84KUe3uu5X3S4gJ7DiWvlqk0mkd0ye6W1E0UgUUVHz8KVZ+QjhX7 0MbBTgHqHjnB/1f8BcGhbpfrHrtHdMiyvU8qYCst57bWxTOAxtFLYyzn3KFCRxwShjKT 5ZdyiRW/WJNCK/1ztKPFscnCdTEhtbgzXZNFOLR4QRLoFCeOea0rB4bUbnGKaRkaPSIj AmVQ== X-Received: by 10.107.134.219 with SMTP id q88mr103852879ioi.27.1426875740084; Fri, 20 Mar 2015 11:22:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.55.167 with HTTP; Fri, 20 Mar 2015 11:21:59 -0700 (PDT) In-Reply-To: References: <550C505F.2030809@icloud.com> From: Miguel Clara Date: Fri, 20 Mar 2015 18:21:59 +0000 Message-ID: Subject: Re: Atheros AR9460 and Acer Aspire V17 Nitro on FreeBSD 11 not working To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Anders Bolt-Evensen , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Mar 2015 18:22:21 -0000 On Fri, Mar 20, 2015 at 6:01 PM, Adrian Chadd wrote: > On 20 March 2015 at 09:52, Anders Bolt-Evensen > wrote: > > Hello! > > > > Recently I had to buy a new computer as my Mac broke down. > > I ended up with an Acer Aspire V17 Nitro, which, except for a couple of > > problems, is all good. > > One of the problems is that wifi does not work. The wifi driver is an > > Atheros AR9460. > > The problem is that when I attempt to scan for my wireless network, > nothing > > shows up at all. > > On my previous computer, where I used an external Atheros card, > everything > > worked well. > > Could the following line from dmesg be a symptom of my problems? > > "ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000" > > > > I'm using FreeBSD 11-CURRENT with sources updated today. > > > What else does it log? > I have this same card on a acer s3 (utltrabook) @adrian this is the one I reported the performance issues but now seems to be working ok. For the record this is with --> r280273 commit d7efe7e99e68d52fa754f4e935814c492d818ece Author: pfg Date: Fri Mar 20 01:07:48 2015 +0000 Permit multiple arguments for the nonnull attribute. This is very useful for non-trivial functions and doesn't affect existing uses. MFC after: 5 days Notes: svn path=/head/; revision=280273 I'm noticing something wron with "ifconfig scan" too, it listed fine as a normal user, but that's not really re-scanning... % ifconfig wlan0 scan SSID/MESH ID BSSID CHAN RATE S:N INT CAPS **** *:1c:68 1 54M -93:-96 100 EP RSN HTCAP WPS WPA WME **** *:13:c0 6 54M -80:-96 100 EP RSN HTCAP WPS WME **** *:e2:0c 6 54M -83:-96 100 EP RSN HTCAP WME **** *:f7:8c 6 54M -109:-96 100 EP RSN HTCAP WPS WPA WME **** *:4a:12 11 54M -91:-96 100 EP RSN HTCAP WPS WPA WME **** *:13:c4 48 54M -80:-96 100 EP RSN HTCAP WME Trying with sudo gets in a hanged state... [user@host:/usr/src ]% sudo ifconfig wlan0 scan load: 0.17 cmd: ifconfig 11320 [sbwait] 35.72r 0.00u 0.00s 0% 2132k load: 0.17 cmd: ifconfig 11320 [sbwait] 36.20r 0.00u 0.00s 0% 2132k load: 0.19 cmd: ifconfig 11320 [sbwait] 187.79r 0.00u 0.00s 0% 2132k load: 0.19 cmd: ifconfig 11320 [sbwait] 187.94r 0.00u 0.00s 0% 2132k load: 0.19 cmd: ifconfig 11320 [sbwait] 188.08r 0.00u 0.00s 0% 2132k ^C but after the ^C as a normal user again and: ifconfig wlan0 scan SSID/MESH ID BSSID CHAN RATE S:N INT CAPS ***** *:1c:68 1 54M -94:-96 100 EP RSN HTCAP WPS WPA WME ***** *:13:c0 6 54M -80:-96 100 EP RSN HTCAP WPS WME ***** *:e2:0c 6 54M -83:-96 100 EP RSN HTCAP WME ***** *:f7:8c 6 54M -130:-96 100 EP RSN HTCAP WPS WPA WME ***** *:4a:12 1 54M -91:-96 100 EP RSN HTCAP WPS WPA WME ***** *:13:c4 48 54M -80:-96 100 EP RSN HTCAP WME ***** ... *:99:01 6 54M -96:-96 100 E <------- This is new so it re-scanned I see nothing in dmesg > > -adrian > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://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 Mar 20 19:01:05 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2077E60F for ; Fri, 20 Mar 2015 19:01:05 +0000 (UTC) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001: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 C5AD19DB for ; Fri, 20 Mar 2015 19:01:04 +0000 (UTC) Received: by ignm3 with SMTP id m3so1406400ign.0 for ; Fri, 20 Mar 2015 12:01:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=fS/LjIvExOQtDL8UMO1zDpFRCvmGfOiVJgRNY+nHsn0=; b=n9ljrVGvRSTR4GxYUbvSRs7HKN19rSwZa8pu+Q2dx7iMGj6xzi/C3xsxplTiH8c2hK fvL4dVeow+zMLKsY/cqlSETk5pCAcPB8+Y6zOI4oHh9AEfp3uJkuAtjasEn/1Hc5yR+6 +0rcid13xAFU0ZiRYVw3rX37MMVuqSqMKaLYzeOyh2zx1Z8iMVQLRdTnahOW/EzxRGlG I2glFRIbjvbLOiZTzzJkhZarrHr2Hu5GsrNPbCXTbPJnKqFlQORT+pcMdQbX58ZP/jko zJL3jzP2/ZjMa4K+dMd6vBDrri1qvRwW5bwKWvvuHi9gfoPMD6oHQikhUKkBvU178I6p GLWQ== MIME-Version: 1.0 X-Received: by 10.42.120.2 with SMTP id d2mr6294566icr.5.1426878064094; Fri, 20 Mar 2015 12:01:04 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.107.174.86 with HTTP; Fri, 20 Mar 2015 12:01:03 -0700 (PDT) In-Reply-To: References: <64AF7708-217B-4AC0-A47A-AD1B0BFF7EDC@gmail.com> <885DA4D0-9644-4F06-97C9-04EAD7B4958C@gmail.com> <98CF988A-D9DB-49AD-8CFF-3B438F892730@gmail.com> <2A8C0814-E644-4350-85B8-17B468D79BFF@gmail.com> Date: Fri, 20 Mar 2015 12:01:03 -0700 X-Google-Sender-Auth: OJqD_uOLy9XPWCaGXZqrUmrIyqE Message-ID: Subject: Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" From: Kevin Oberman To: Miguel Clara Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current , Garrett Cooper X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Mar 2015 19:01:05 -0000 On Fri, Mar 20, 2015 at 7:47 AM, Miguel Clara wrote: > > On Thu, Feb 26, 2015 at 2:52 AM, Garrett Cooper > wrote: > >> >> On Feb 25, 2015, at 18:08, Kevin Oberman wrote: >> >> On Wed, Feb 25, 2015 at 2:30 PM, Garrett Cooper >> wrote: >> >>> On Feb 25, 2015, at 14:19, Miguel Clara wrote: >>> >>> ... >>> >>> > I noticed this too, but in that case why doesn't it affect all users? >>> (or all the ones using dnscrypt+local_unbound) maybe something changed = in >>> "NETWORKING" recently? >>> > >>> > Hum: >>> > >>> https://svnweb.freebsd.org/base/head/etc/rc.d/NETWORKING?r1=3D275299&r2= =3D278704 >>> > >>> > Interesting, as I am using the most recent version which does not >>> REQUIRE local_unbound >>> > >>> > I'm even more confused now :| >>> > >>> > >>> > So it has to come after SERVERS but before local_unbound. But >>> NETWORKING depends on local_unbound they are both dependent on NEWORKIN= G >>> which has to be after SERVERS. Can you say fubar! Clearly broken. And t= his >>> means that removing SERVERS will re-shuffle the order more appropriatel= y. >>> > >>> > It seems that the behavior of rcorder is not as documented as well as >>> being undefined when circular dependencies occur. The man page says tha= t >>> rcorder aborts when it encounters a circular dependency, but that is no= t >>> the case. It probably is best that it not die, but that leaves things i= n an >>> unknown and inconsistant state, which is also a very bad idea. I guess = when >>> a circular dependency is encountered, a dichotomy occurs. >>> >>> Now you know why I=E2=80=99m so curious about all of this stuff. >>> >>> When I was working on ^/projects/building-blocks, I was able to move >>> most of these pieces around by changing REQUIRE: to BEFORE:, but I noti= ced >>> that it changes the rcorder a bit, so I haven=E2=80=99t been super gung= ho in >>> implementing my change. >>> >>> I think there are a couple bugs present on 9-STABLE/10-STABLE/11-CURREN= T: >>> >>> - Things go awry if named is removed/not installed. >>> - Things go awry if local_unbound is removed (which would have been the >>> case if the rc.d script was removed from your system, which existed bef= ore >>> my changes). >>> - Other rc.d scripts not being present might break assumptions. >>> >>> I need to create dummy providers for certain logical stages (DNS is one >>> of them) to solve part of this problem and provide third parties with a >>> mechanism that can be depended on (I wish applications were written in = a >>> more robust manner to fail gracefully and retry instead of failing flat= on >>> their face, but as I=E2=80=99ve seen at several jobs, getting developer= s to fail, >>> then retry is hard :(=E2=80=A6). >>> >>> Another short-term hack: >>> >>> Install dummy/no-op providers so the ordering is preserved, then remove >>> the hacks after all of the bugs have been shaken out. >>> >>> Thanks! >>> >> >> Garret, >> >> Also undocumented (except in rcorder.c) is that the lack of a provider i= s >> not an error. This effectively makes a list of providers into an OR. So, >> for name service the normal list is "named local_unbound unbound" and an= y >> will work for ordering and having none is a no-op, so if you don't run a= ny >> nameserver (or kerberos or whatever provider), it is not an issue. As lo= ng >> as rcorder finds a provider, it will be used to set the order, but the l= ack >> of any or all providers just means that the specified provider is ignore= d >> and if a REQUIRES or BEFORE lists no existing providers, the statement i= s >> simply ignored. >> >> The real problem is that there is no defined rule for behavior in the >> event of a circular dependency and any change to any decision point in t= he >> ordering process may change the way the ordering flips. That is why thes= e >> things are such a royal pain to debug. A change in any rc.d script may >> cause the ordering of seemingly unrelated scripts to change, perhaps >> drastically, and the error messages, while not misleading, is only a >> starting point in tracking this down. This means there may be time bombs >> that break working ports without their being touched or even re-installe= d. >> And the triggering change my, itself be correct. >> >> >> Or etc/rc.d/named... >> >> PROVIDES: DNS >> >> I'm going to post a fix up for this on arch@/rc@ because it needs to be >> solved in a saner way -- especially for systems that are pedantic about >> rcorder, like our version at $work. >> >> > I re-sync my source and noticed the change while doing the mergemaster > part... with this I can now change dnscrypt to: > > @@ -4,7 +4,7 @@ > # > # PROVIDE: dnscrypt_proxy > # REQUIRE: SERVERS cleanvar > -# BEFORE: named local_unbound unbound > +# BEFORE: DNS > > And this makes the rcorder ok for dnscrypt-proxy > This is still broken and only works by random luck. At this time there appears to be nothing providing DNS. At least the default /etc/rc.d/local_unbound does not.nor does anything else in /etc/rc.d. It looks like this change effectively removes all BEFORE constraints, so it may start any time after SERVERS and cleanvar. But, it if really expects to start before name service comes up, it's not going to happen as those start before SERVERS. The effect is probably only that any DNS queries made prior to it starting are not encrypted. Since name service must start before SERVERS, I see no way to really prevent this, but I think the port should be corrected and a message added to warn that queries made while servers are starting may not be encrypted. "rcorder /etc/rc.d/* /usr/src/etc/rc.d/* > /dev/null" should report the lack of a provider for DNS. -- Kevin Oberman, Network Engineer, Retired From owner-freebsd-current@FreeBSD.ORG Fri Mar 20 19:02:40 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1ED60737 for ; Fri, 20 Mar 2015 19:02:40 +0000 (UTC) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D5E28A8C for ; Fri, 20 Mar 2015 19:02:39 +0000 (UTC) Received: by iedm5 with SMTP id m5so36082586ied.3 for ; Fri, 20 Mar 2015 12:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=vYwIpr4DWluwFPIKCUZM4IGnoVery4KCxO4Sx6L8EvQ=; b=O8PJJSweu2my3LI1GMXRbz9p5JSwWkola+a7A8kJJ4/wEQIopdM1PXUJZhi9VmXUoJ B1XSRRxGghC1uG7buc5bde+bE0GemXu8bjwWWqiucspUNOWu0v05qG0OmQI8l26T4g6h BpaZAtyz7Z8VIz/MvzrRp7q5SDAI+4Ef+MXnjbgTlISqgdUpT0C9ICAHoaErE1z+9VRQ h1edcOaW0Ip4Ex4SAjZtSagRkHzudQuWC3kghVfpVexD3O/lkFrgvLW8EFoFcnXo9dlo ObzDbNCRgxhqzFxLdJriD7ZLSh4TYGsEnWVZvP218Y7Q28Mtd58MH6DPPoUR8YmjYSOc kBzA== MIME-Version: 1.0 X-Received: by 10.50.36.65 with SMTP id o1mr27698478igj.32.1426878159297; Fri, 20 Mar 2015 12:02:39 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.17.194 with HTTP; Fri, 20 Mar 2015 12:02:39 -0700 (PDT) In-Reply-To: References: <550C505F.2030809@icloud.com> Date: Fri, 20 Mar 2015 12:02:39 -0700 X-Google-Sender-Auth: oe-BNzkhWtS_k4g-YjbuDe2enNA Message-ID: Subject: Re: Atheros AR9460 and Acer Aspire V17 Nitro on FreeBSD 11 not working From: Adrian Chadd To: Miguel Clara Content-Type: text/plain; charset=UTF-8 Cc: Anders Bolt-Evensen , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Mar 2015 19:02:40 -0000 compile in IEEE80211_DEBUG, then "wlandebug +scan", then do the scan. I wonder if you're hitting some scan bug where the sheer amount of traffic going on is causing problems. Also, seeing RX'ed frames at -130dB is .. oddly wrong for this NIC. Something odd is going on. -a On 20 March 2015 at 11:21, Miguel Clara wrote: > > On Fri, Mar 20, 2015 at 6:01 PM, Adrian Chadd wrote: >> >> On 20 March 2015 at 09:52, Anders Bolt-Evensen >> wrote: >> > Hello! >> > >> > Recently I had to buy a new computer as my Mac broke down. >> > I ended up with an Acer Aspire V17 Nitro, which, except for a couple of >> > problems, is all good. >> > One of the problems is that wifi does not work. The wifi driver is an >> > Atheros AR9460. >> > The problem is that when I attempt to scan for my wireless network, >> > nothing >> > shows up at all. >> > On my previous computer, where I used an external Atheros card, >> > everything >> > worked well. >> > Could the following line from dmesg be a symptom of my problems? >> > "ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000" >> > >> > I'm using FreeBSD 11-CURRENT with sources updated today. >> >> >> What else does it log? > > > I have this same card on a acer s3 (utltrabook) > > @adrian this is the one I reported the performance issues but now seems to > be working ok. > > For the record this is with --> r280273 > > commit d7efe7e99e68d52fa754f4e935814c492d818ece > Author: pfg > Date: Fri Mar 20 01:07:48 2015 +0000 > > Permit multiple arguments for the nonnull attribute. > > This is very useful for non-trivial functions and doesn't > affect existing uses. > > MFC after: 5 days > > Notes: > svn path=/head/; revision=280273 > > > I'm noticing something wron with "ifconfig scan" too, it listed fine as a > normal user, but that's not really re-scanning... > > % ifconfig wlan0 scan > SSID/MESH ID BSSID CHAN RATE S:N INT CAPS > **** *:1c:68 1 54M -93:-96 100 EP RSN HTCAP WPS WPA WME > **** *:13:c0 6 54M -80:-96 100 EP RSN HTCAP WPS WME > **** *:e2:0c 6 54M -83:-96 100 EP RSN HTCAP WME > **** *:f7:8c 6 54M -109:-96 100 EP RSN HTCAP WPS WPA WME > **** *:4a:12 11 54M -91:-96 100 EP RSN HTCAP WPS WPA WME > **** *:13:c4 48 54M -80:-96 100 EP RSN HTCAP WME > > Trying with sudo gets in a hanged state... > > [user@host:/usr/src ]% sudo ifconfig wlan0 scan > load: 0.17 cmd: ifconfig 11320 [sbwait] 35.72r 0.00u 0.00s 0% 2132k > load: 0.17 cmd: ifconfig 11320 [sbwait] 36.20r 0.00u 0.00s 0% 2132k > load: 0.19 cmd: ifconfig 11320 [sbwait] 187.79r 0.00u 0.00s 0% 2132k > load: 0.19 cmd: ifconfig 11320 [sbwait] 187.94r 0.00u 0.00s 0% 2132k > load: 0.19 cmd: ifconfig 11320 [sbwait] 188.08r 0.00u 0.00s 0% 2132k > > ^C > > but after the ^C as a normal user again and: > ifconfig wlan0 scan > SSID/MESH ID BSSID CHAN RATE S:N INT CAPS > ***** *:1c:68 1 54M -94:-96 100 EP RSN HTCAP WPS WPA WME > ***** *:13:c0 6 54M -80:-96 100 EP RSN HTCAP WPS WME > ***** *:e2:0c 6 54M -83:-96 100 EP RSN HTCAP WME > ***** *:f7:8c 6 54M -130:-96 100 EP RSN HTCAP WPS WPA WME > ***** *:4a:12 1 54M -91:-96 100 EP RSN HTCAP WPS WPA WME > ***** *:13:c4 48 54M -80:-96 100 EP RSN HTCAP WME > ***** ... *:99:01 6 54M -96:-96 100 E <------- This is new so it > re-scanned > > > I see nothing in dmesg > >> >> >> -adrian >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://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 Mar 20 20:22:35 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9FB6ACD for ; Fri, 20 Mar 2015 20:22:35 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id ACC556C1 for ; Fri, 20 Mar 2015 20:22:35 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 8DB4B2C8 for ; Fri, 20 Mar 2015 20:22:35 +0000 (UTC) Date: Fri, 20 Mar 2015 20:22:35 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1364578405.4.1426882955526.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1292972777.3.1426869058392.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1292972777.3.1426869058392.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD-tests2 #857 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Mar 2015 20:22:36 -0000 See ------------------------------------------ [...truncated 987 lines...] lib/libc/string/strspn:strspn -> passed [0.013s] lib/libc/string/swab:swab_basic -> passed [0.013s] lib/libc/sys/access_test:access_access -> passed [0.019s] lib/libc/sys/access_test:access_fault -> passed [0.014s] lib/libc/sys/access_test:access_inval -> passed [0.013s] lib/libc/sys/access_test:access_notdir -> passed [0.013s] lib/libc/sys/access_test:access_notexist -> passed [0.013s] lib/libc/sys/access_test:access_toolong -> passed [0.013s] lib/libc/sys/chroot_test:chroot_basic -> passed [0.016s] lib/libc/sys/chroot_test:chroot_err -> passed [0.013s] lib/libc/sys/chroot_test:chroot_perm -> passed [0.014s] lib/libc/sys/clock_gettime_test:clock_gettime_real -> passed [0.016s] lib/libc/sys/connect_test:connect_low_port -> passed [0.015s] lib/libc/sys/dup_test:dup2_basic -> passed [0.013s] lib/libc/sys/dup_test:dup2_err -> passed [0.013s] lib/libc/sys/dup_test:dup2_max -> passed [0.014s] lib/libc/sys/dup_test:dup2_mode -> passed [0.029s] lib/libc/sys/dup_test:dup3_err -> passed [0.015s] lib/libc/sys/dup_test:dup3_max -> passed [0.015s] lib/libc/sys/dup_test:dup3_mode -> passed [0.031s] lib/libc/sys/dup_test:dup_err -> passed [0.014s] lib/libc/sys/dup_test:dup_max -> passed [0.019s] lib/libc/sys/dup_test:dup_mode -> passed [0.032s] lib/libc/sys/fsync_test:fsync_err -> passed [0.014s] lib/libc/sys/fsync_test:fsync_sync -> passed [0.037s] lib/libc/sys/getcontext_test:getcontext_err -> passed [0.014s] lib/libc/sys/getcontext_test:setcontext_err -> passed [0.013s] lib/libc/sys/getcontext_test:setcontext_link -> passed [0.013s] lib/libc/sys/getgroups_test:getgroups_err -> expected_failure: Reported as kern/189941: /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/sys/t_getgroups.c:63: getgroups(-1, gidset) == -1 not met [0.014s] lib/libc/sys/getgroups_test:getgroups_getgid -> passed [0.014s] lib/libc/sys/getgroups_test:getgroups_setgid -> passed [0.016s] lib/libc/sys/getgroups_test:getgroups_zero -> passed [0.014s] lib/libc/sys/getitimer_test:getitimer_empty -> passed [0.014s] lib/libc/sys/getitimer_test:getitimer_err -> passed [0.014s] lib/libc/sys/getitimer_test:setitimer_basic -> passed [0.015s] lib/libc/sys/getitimer_test:setitimer_err -> passed [0.015s] lib/libc/sys/getitimer_test:setitimer_old -> passed [0.014s] lib/libc/sys/getlogin_test:getlogin_r_err -> passed [0.015s] lib/libc/sys/getlogin_test:getlogin_same -> passed [0.014s] lib/libc/sys/getlogin_test:setlogin_basic -> passed [0.015s] lib/libc/sys/getlogin_test:setlogin_err -> passed [0.015s] lib/libc/sys/getlogin_test:setlogin_perm -> passed [0.016s] lib/libc/sys/getpid_test:getpid_process -> passed [0.023s] lib/libc/sys/getpid_test:getpid_thread -> passed [0.018s] lib/libc/sys/getrusage_test:getrusage_err -> passed [0.015s] lib/libc/sys/getrusage_test:getrusage_sig -> passed [0.014s] lib/libc/sys/getrusage_test:getrusage_utime_back -> passed [2.149s] lib/libc/sys/getrusage_test:getrusage_utime_zero -> skipped: this testcase passes/fails sporadically on FreeBSD/i386 @ r273153 (at least) [0.015s] lib/libc/sys/getsid_test:getsid_current -> passed [0.014s] lib/libc/sys/getsid_test:getsid_err -> passed [0.015s] lib/libc/sys/getsid_test:getsid_process -> passed [0.016s] lib/libc/sys/gettimeofday_test:gettimeofday_err -> passed [0.014s] lib/libc/sys/gettimeofday_test:gettimeofday_mono -> passed [0.016s] lib/libc/sys/issetugid_test:issetugid_egid -> passed [0.017s] lib/libc/sys/issetugid_test:issetugid_euid -> passed [0.017s] lib/libc/sys/issetugid_test:issetugid_rgid -> passed [0.017s] lib/libc/sys/issetugid_test:issetugid_ruid -> passed [0.017s] lib/libc/sys/kevent_test:kevent_zerotimer -> passed [0.015s] lib/libc/sys/kevent_test:kqueue_desc_passing -> passed [0.016s] lib/libc/sys/kevent_test:kqueue_unsupported_fd -> skipped: no /nonexistent available for testing [0.014s] lib/libc/sys/kill_test:kill_basic -> passed [0.017s] lib/libc/sys/kill_test:kill_err -> passed [0.015s] lib/libc/sys/kill_test:kill_perm -> passed [1.046s] lib/libc/sys/kill_test:kill_pgrp_neg -> passed [0.016s] lib/libc/sys/kill_test:kill_pgrp_zero -> passed [0.017s] lib/libc/sys/link_test:link_count -> passed [0.019s] lib/libc/sys/link_test:link_err -> passed [0.018s] lib/libc/sys/link_test:link_perm -> passed [0.013s] lib/libc/sys/link_test:link_stat -> passed [0.018s] lib/libc/sys/listen_test:listen_err -> passed [0.019s] lib/libc/sys/listen_test:listen_low_port -> passed [0.014s] lib/libc/sys/mincore_test:mincore_err -> passed [0.013s] lib/libc/sys/mincore_test:mincore_resid -> passed [0.038s] lib/libc/sys/mincore_test:mincore_shmseg -> passed [0.017s] lib/libc/sys/mkdir_test:mkdir_err -> passed [0.014s] lib/libc/sys/mkdir_test:mkdir_mode -> passed [1.093s] lib/libc/sys/mkdir_test:mkdir_perm -> passed [0.018s] lib/libc/sys/mkdir_test:mkdir_trail -> passed [0.025s] lib/libc/sys/mkfifo_test:mkfifo_block -> passed [1.065s] lib/libc/sys/mkfifo_test:mkfifo_err -> passed [0.020s] lib/libc/sys/mkfifo_test:mkfifo_nonblock -> passed [1.086s] lib/libc/sys/mkfifo_test:mkfifo_perm -> passed [0.020s] lib/libc/sys/mkfifo_test:mkfifo_stat -> passed [0.019s] lib/libc/sys/mknod_test:mknod_err -> passed [0.017s] lib/libc/sys/mknod_test:mknod_exist -> passed [0.019s] lib/libc/sys/mknod_test:mknod_perm -> passed [0.017s] lib/libc/sys/mknod_test:mknod_stat -> expected_failure: mknod does not allow S_IFREG: /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/sys/t_mknod.c:179: mknod(path, S_IFREG, 0) == 0 not met [0.018s] lib/libc/sys/mlock_test:mlock_clip -> passed [0.015s] lib/libc/sys/mlock_test:mlock_err -> passed [0.016s] lib/libc/sys/mlock_test:mlock_limits -> passed [0.016s] lib/libc/sys/mlock_test:mlock_mmap -> passed [0.015s] lib/libc/sys/mlock_test:mlock_nested -> passed [0.015s] lib/libc/sys/mmap_test:mmap_err -> passed [0.014s] lib/libc/sys/mmap_test:mmap_loan -> passed [0.019s] lib/libc/sys/mmap_test:mmap_prot_1 -> passed [0.018s] lib/libc/sys/mmap_test:mmap_prot_2 -> passed [0.014s] lib/libc/sys/mmap_test:mmap_prot_3 -> passed [0.018s] lib/libc/sys/mmap_test:mmap_truncate -> passed [0.022s] lib/libc/sys/mmap_test:mmap_va0 -> passed [0.015s] lib/libc/sys/mprotect_test:mprotect_access -> passed [0.018s] lib/libc/sys/mprotect_test:mprotect_err -> passed [0.013s] lib/libc/sys/mprotect_test:mprotect_pax -> passed [0.014s] lib/libc/sys/mprotect_test:mprotect_write -> passed [0.014s] lib/libc/sys/msgctl_test:msgctl_err -> passed [0.405s] lib/libc/sys/msgctl_test:msgctl_perm -> passed [0.021s] lib/libc/sys/msgctl_test:msgctl_pid -> passed [2.088s] lib/libc/sys/msgctl_test:msgctl_set -> passed [0.020s] lib/libc/sys/msgctl_test:msgctl_time -> passed [0.017s] lib/libc/sys/msgget_test:msgget_excl -> passed [0.016s] lib/libc/sys/msgget_test:msgget_exit -> passed [0.017s] lib/libc/sys/msgget_test:msgget_init -> passed [0.016s] lib/libc/sys/msgget_test:msgget_limit -> passed [0.014s] lib/libc/sys/msgget_test:msgget_mode -> passed [0.016s] lib/libc/sys/msgrcv_test:msgrcv_basic -> passed [0.015s] lib/libc/sys/msgrcv_test:msgrcv_block -> passed [2.090s] lib/libc/sys/msgrcv_test:msgrcv_err -> passed [0.016s] lib/libc/sys/msgrcv_test:msgrcv_mtype -> passed [0.015s] lib/libc/sys/msgrcv_test:msgrcv_nonblock -> passed [2.104s] lib/libc/sys/msgrcv_test:msgrcv_truncate -> passed [0.017s] lib/libc/sys/msgsnd_test:msgsnd_block -> passed [2.096s] lib/libc/sys/msgsnd_test:msgsnd_count -> passed [0.019s] lib/libc/sys/msgsnd_test:msgsnd_err -> passed [0.018s] lib/libc/sys/msgsnd_test:msgsnd_nonblock -> passed [2.077s] lib/libc/sys/msgsnd_test:msgsnd_perm -> passed [0.019s] lib/libc/sys/msync_test:msync_async -> passed [0.018s] lib/libc/sys/msync_test:msync_err -> passed [0.023s] lib/libc/sys/msync_test:msync_invalidate -> passed [0.089s] lib/libc/sys/msync_test:msync_sync -> passed [0.018s] lib/libc/sys/nanosleep_test:nanosleep_basic -> passed [0.014s] lib/libc/sys/nanosleep_test:nanosleep_err -> passed [0.013s] lib/libc/sys/nanosleep_test:nanosleep_sig -> passed [1.040s] lib/libc/sys/pipe_test:pipe_restart -> passed [2.054s] lib/libc/sys/pipe2_test:pipe2_basic -> passed [0.014s] lib/libc/sys/pipe2_test:pipe2_cloexec -> passed [0.014s] lib/libc/sys/pipe2_test:pipe2_consume -> passed [0.014s] lib/libc/sys/pipe2_test:pipe2_einval -> passed [0.015s] lib/libc/sys/pipe2_test:pipe2_nonblock -> passed [0.015s] lib/libc/sys/poll_test:poll_3way -> passed [10.105s] lib/libc/sys/poll_test:poll_basic -> passed [0.017s] lib/libc/sys/poll_test:poll_err -> passed [0.016s] lib/libc/sys/revoke_test:revoke_basic -> skipped: revoke(2) is only implemented for devfs(5). [0.018s] lib/libc/sys/revoke_test:revoke_err -> skipped: revoke(2) is only implemented for devfs(5). [0.016s] lib/libc/sys/revoke_test:revoke_perm -> skipped: revoke(2) is only implemented for devfs(5). [0.018s] lib/libc/sys/select_test:pselect_sigmask -> passed [1.066s] lib/libc/sys/select_test:pselect_timeout -> passed [0.017s] lib/libc/sys/setrlimit_test:setrlimit_basic -> passed [0.014s] lib/libc/sys/setrlimit_test:setrlimit_current -> passed [0.015s] lib/libc/sys/setrlimit_test:setrlimit_err -> passed [0.015s] lib/libc/sys/setrlimit_test:setrlimit_fsize -> passed [0.020s] lib/libc/sys/setrlimit_test:setrlimit_memlock -> passed [0.016s] lib/libc/sys/setrlimit_test:setrlimit_nofile_1 -> passed [0.016s] lib/libc/sys/setrlimit_test:setrlimit_nofile_2 -> passed [0.017s] lib/libc/sys/setrlimit_test:setrlimit_nproc -> maxproc limit exceeded by uid 977 (pid 5273); see tuning(7) and login.conf(5) passed [0.552s] lib/libc/sys/setrlimit_test:setrlimit_perm -> panic: mutex process lock not owned at /builds/FreeBSD_HEAD/sys/kern/kern_prot.c:1974 cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00974b38e0 vpanic() at vpanic+0x189/frame 0xfffffe00974b3960 panic() at panic+0x43/frame 0xfffffe00974b39c0 __mtx_assert() at __mtx_assert+0xc2/frame 0xfffffe00974b39d0 proc_set_cred() at proc_set_cred+0x36/frame 0xfffffe00974b39f0 fork1() at fork1+0x27e/frame 0xfffffe00974b3ac0 sys_fork() at sys_fork+0x1f/frame 0xfffffe00974b3ae0 amd64_syscall() at amd64_syscall+0x27f/frame 0xfffffe00974b3bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe00974b3bf0 --- syscall (0, FreeBSD ELF64, nosys), rip = 0x8019c516a, rsp = 0x7fffffffc2d8, rbp = 0x7fffffffc340 --- KDB: enter: panic [ thread pid 660 tid 100070 ] Stopped at kdb_enter+0x3e: movq $0,kdb_why db> Traceback (most recent call last): File "/vm/freebsd-ci/scripts/test/run-tests.py", line 152, in main(sys.argv) File "/vm/freebsd-ci/scripts/test/run-tests.py", line 80, in main runTest() File "/vm/freebsd-ci/scripts/test/run-tests.py", line 124, in runTest child2.expect(prompt, timeout=7200) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1451, in expect timeout, searchwindowsize) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1466, in expect_list timeout, searchwindowsize) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1568, in expect_loop raise TIMEOUT(str(err) + '\n' + str(self)) pexpect.TIMEOUT: Timeout exceeded. version: 3.3 command: /usr/sbin/bhyve args: [u'/usr/sbin/bhyve', u'-c', u'2', u'-m', u'2G', u'-AI', u'-H', u'-P', u'-g', u'0', u'-s', u'0:0,hostbridge', u'-s', u'1:0,lpc', u'-s', u'2:0,virtio-net,tap0,mac=58:9c:fc:00:00:2e', u'-s', u'3:0,ahci-hd,/net/jenkins-10.freebsd.org/builds/Build-UFS-image/image/FreeBSD_HEAD/test.img', u'-l', u'com1,stdio', u'vm_test'] searcher: buffer (last 100 chars): 'nter: panic\r\n[ thread pid 660 tid 100070 ]\r\nStopped at kdb_enter+0x3e: movq $0,kdb_why\r\ndb> ' before (last 100 chars): 'nter: panic\r\n[ thread pid 660 tid 100070 ]\r\nStopped at kdb_enter+0x3e: movq $0,kdb_why\r\ndb> ' after: match: None match_index: None exitstatus: None flag_eof: False pid: 96940 child_fd: 4 closed: False timeout: 30 delimiter: logfile: ', mode 'w' at 0x800670150> logfile_read: None logfile_send: None maxread: 2000 ignorecase: False searchwindowsize: None delaybeforesend: 0.05 delayafterclose: 0.1 delayafterterminate: 0.1 Build step 'Execute shell' marked build as failure Recording test results ERROR: Publisher hudson.tasks.junit.JUnitResultArchiver aborted due to exception hudson.AbortException: Test reports were found but none of them are new. Did tests run? For example, is 5 days 18 hr old at hudson.tasks.junit.TestResult.parse(TestResult.java:178) at hudson.tasks.junit.TestResult.parse(TestResult.java:146) at hudson.tasks.junit.TestResult.(TestResult.java:122) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:119) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:92) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2688) at hudson.remoting.UserRequest.perform(UserRequest.java:121) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at hudson.remoting.Request$2.run(Request.java:324) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) at ......remote call to havoc.ysv.freebsd.org(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1356) at hudson.remoting.UserResponse.retrieve(UserRequest.java:221) at hudson.remoting.Channel.call(Channel.java:752) at hudson.FilePath.act(FilePath.java:978) at hudson.FilePath.act(FilePath.java:967) at hudson.tasks.junit.JUnitParser.parseResult(JUnitParser.java:89) at hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:120) at hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:137) at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:74) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:761) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:721) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:670) at hudson.model.Run.execute(Run.java:1775) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240) From owner-freebsd-current@FreeBSD.ORG Fri Mar 20 20:45:18 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 24C5B466 for ; Fri, 20 Mar 2015 20:45:18 +0000 (UTC) Received: from tensor.andric.com (unknown [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 BFF33982 for ; Fri, 20 Mar 2015 20:45:17 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::618c:d619:3565:7337] (unknown [IPv6:2001:7b8:3a7:0:618c:d619:3565:7337]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 2FCD65C4D; Fri, 20 Mar 2015 21:45:13 +0100 (CET) Subject: Re: clang/tblgen: undefined reference to `futimens' c++: error: linker command failed with exit Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_61F8DEF3-5085-41C2-8C63-A600973C8DDD"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b6 From: Dimitry Andric In-Reply-To: <20150320083354.5efc5fa6@prometheus> Date: Fri, 20 Mar 2015 21:44:51 +0100 Message-Id: <27E39060-1453-4F79-AE7A-F3F7D92FE325@FreeBSD.org> References: <20150320083354.5efc5fa6@prometheus> To: "O. Hartmann" X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Mar 2015 20:45:18 -0000 --Apple-Mail=_61F8DEF3-5085-41C2-8C63-A600973C8DDD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 20 Mar 2015, at 08:33, O. Hartmann = wrote: >=20 > Running >=20 > 11.0-CURRENT FreeBSD 11.0-CURRENT #2 r277382: Mon Jan 19 16:10:34 CET = 2015 > amd64 >=20 > with source tree at revision > >>> Updating /usr/src using Subversion > -------------------------------------------------------------- > Updating '.': > At revision 280275. >=20 > and "make buildorld buildkernel" >=20 > fails at the below shown point. >=20 > The /usr/obj tree is clean - I delete it prior to each build run. >=20 > Something is out of sync, sn earlier update process (make = installworld) crashed > and I think the kernel, binary tools and rest of sources are some kind = of out > of sync. >=20 > Is there a way - from the data shown - to resolve the problem? >=20 > Building a kernel works great, building toolchains fail also at the = very same > point. >=20 > Thanks in advance, >=20 > oh >=20 >=20 > [...] > --- _bootstrap-tools-usr.bin/clang/tblgen --- > --- TableGen.o --- > c++ -O2 -pipe -O3 -pipe -O3 > -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/include > = -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/tools/clang/include > -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen = -I. > = -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/../../lib/clang/incl= ude > -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS = -D__STDC_CONSTANT_MACROS > -fno-strict-aliasing > -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"x86_64-unknown-freebsd11.0\" > -DLLVM_HOST_TRIPLE=3D\"x86_64-unknown-freebsd11.0\" = -DDEFAULT_SYSROOT=3D\"\" > -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include = -std=3Dc++11 > -std=3Dc++11 -fno-exceptions -fno-rtti -stdlib=3Dlibc++ = -Wno-c++11-extensions > -c = /usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/TableGe= n.cpp > -o TableGen.o --- _bootstrap-tools-usr.bin/clang/clang-tblgen > --- = /usr/obj/usr/src/tmp/usr/src/usr.bin/clang/clang-tblgen/../../../lib/clang= /libllvmsupport/libllvmsupport.a(Path.o): > In function `llvm::sys::fs::setLastModificationAndAccessTime(int, > llvm::sys::TimeValue)': = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Path.c= pp:(.text+0x4649): > undefined reference to `futimens' c++: error: linker command failed = with exit > code 1 (use -v to see invocation) *** [clang-tblgen] Error code 1 Somehow, you seem to have messed up your libc, which provides futimens() since r277610 (about 7 weeks ago). Maybe you restored a very old version? In any case, you might be able to get around it by cheating with __FreeBSD_version. What does the following say on your system: grep "#define __FreeBSD_version" /usr/include/sys/param.h If the version is 1100056 or higher, you should have futimens(). You could try cheating by editing the file and resetting the version to e.g. 1100055. -Dimitry --Apple-Mail=_61F8DEF3-5085-41C2-8C63-A600973C8DDD 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.27 iEYEARECAAYFAlUMhtcACgkQsF6jCi4glqNejgCg1kv4ktkQS2R1J6AsTHAhvs1W suwAoIlJQoqjgAEPGPwqmLysaZMB7NeW =hzbc -----END PGP SIGNATURE----- --Apple-Mail=_61F8DEF3-5085-41C2-8C63-A600973C8DDD-- From owner-freebsd-current@FreeBSD.ORG Fri Mar 20 23:19:38 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A8D48FB; Fri, 20 Mar 2015 23:19:38 +0000 (UTC) Received: from st11p00mm-asmtp004.mac.com (st11p00mm-asmtp004.mac.com [17.172.81.3]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5C961BB4; Fri, 20 Mar 2015 23:19:37 +0000 (UTC) Received: from [10.0.0.14] (ti0025a400-4054.bb.online.no [85.167.26.227]) by st11p00mm-asmtp004.mac.com (Oracle Communications Messaging Server 7.0.5.33.0 64bit (built Aug 27 2014)) with ESMTPSA id <0NLJ004VS7CF3U50@st11p00mm-asmtp004.mac.com>; Fri, 20 Mar 2015 22:19:31 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-03-20_08:2015-03-20,2015-03-20,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1503200221 Message-id: <550C9CEF.4040302@icloud.com> Date: Fri, 20 Mar 2015 23:19:27 +0100 From: Anders Bolt-Evensen User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-version: 1.0 To: Adrian Chadd , freebsd-current@freebsd.org Subject: Re: Atheros AR9460 and Acer Aspire V17 Nitro on FreeBSD 11 not working References: <550C505F.2030809@icloud.com> 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.18-1 Precedence: 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, 20 Mar 2015 23:19:38 -0000 IEEE_80211_DEBUG is compiled into the kernel. When I ran "wlandebug +scan", I got the following output: net.wlan.0.debug: 0x0 => 0x200000 Then I ran "ifconfig wlan0 up" and then "ifconfig wlan0 scan". The scan now took a few seconds, but still nothing shows up. Then I took a look at dmesg -a which was now filled with a loop of the following messages: wlan0: ieee80211_start_scan_locked: active scan, duration 2147483647 mindwell 0 maxdwell 0, desired mode auto, append, nojoin, once wlan0: scan set 1g, 6g, 11g, 7g, 13g, 52a, 56a, 60a, 64a, 36a, 40a, 44a, 48a, 2g, 3g, 4g, 5g, 8g, 9g, 10g, 12g, 149a, 153a, 157a, 161a, 165a, 100a, 104a, 108a, 112a, 116a, 120a, 124a, 128a, 132a, 136a, 140a dwell min 20ms max 200ms wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 140a -> 1g [active, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 1g -> 6g [active, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 6g -> 11g [active, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 11g -> 7g [active, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 7g -> 13g [passive, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 13g -> 52a [passive, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 52a -> 56a [passive, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 56a -> 60a [passive, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 60a -> 64a [passive, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 64a -> 36a [passive, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 36a -> 40a [passive, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 40a -> 44a [passive, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 44a -> 48a [passive, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 48a -> 2g [active, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 2g -> 3g [active, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 3g -> 4g [active, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 4g -> 5g [active, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 5g -> 8g [active, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 8g -> 9g [active, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 9g -> 10g [active, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 10g -> 12g [passive, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 12g -> 149a [passive, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 149a -> 153a [passive, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 153a -> 157a [passive, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 157a -> 161a [passive, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 161a -> 165a [passive, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 165a -> 100a [passive, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 100a -> 104a [passive, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 104a -> 108a [passive, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 108a -> 112a [passive, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 112a -> 116a [passive, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 116a -> 120a [passive, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 120a -> 124a [passive, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 124a -> 128a [passive, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 128a -> 132a [passive, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 132a -> 136a [passive, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=0 wlan0: scan_task: chan 136a -> 140a [passive, dwell min 20ms max 200ms] wlan0: scan_curchan: calling; maxdwell=200 wlan0: scan_task: waiting wlan0: scan_task: loop start; scandone=1 wlan0: scan_task: out wlan0: sta_pick_bss: no scan candidate wlan0: scan_task: done, [ticks 2147275107, dwell min 20 scanend 4294748797] wlan0: notify scan done wlan0: ieee80211_scanreq: flags 0x20052 duration 0x7fffffff mindwell 0 maxdwell 0 nssid 1 wlan0: ieee80211_check_scan: active scan, append, nojoin, once wlan0: sta_pick_bss: no scan candidate The system kept on printing these messages until I rebooted this machine back to Windows (in order to write this reply). On 3/20/2015 8:02 PM, Adrian Chadd wrote: > compile in IEEE80211_DEBUG, then "wlandebug +scan", then do the scan. > > I wonder if you're hitting some scan bug where the sheer amount of > traffic going on is causing problems. > > Also, seeing RX'ed frames at -130dB is .. oddly wrong for this NIC. > Something odd is going on. > > > -a > > > On 20 March 2015 at 11:21, Miguel Clara wrote: >> On Fri, Mar 20, 2015 at 6:01 PM, Adrian Chadd wrote: >>> On 20 March 2015 at 09:52, Anders Bolt-Evensen >>> wrote: >>>> Hello! >>>> >>>> Recently I had to buy a new computer as my Mac broke down. >>>> I ended up with an Acer Aspire V17 Nitro, which, except for a couple of >>>> problems, is all good. >>>> One of the problems is that wifi does not work. The wifi driver is an >>>> Atheros AR9460. >>>> The problem is that when I attempt to scan for my wireless network, >>>> nothing >>>> shows up at all. >>>> On my previous computer, where I used an external Atheros card, >>>> everything >>>> worked well. >>>> Could the following line from dmesg be a symptom of my problems? >>>> "ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000" >>>> >>>> I'm using FreeBSD 11-CURRENT with sources updated today. >>> >>> What else does it log? >> >> I have this same card on a acer s3 (utltrabook) >> >> @adrian this is the one I reported the performance issues but now seems to >> be working ok. >> >> For the record this is with --> r280273 >> >> commit d7efe7e99e68d52fa754f4e935814c492d818ece >> Author: pfg >> Date: Fri Mar 20 01:07:48 2015 +0000 >> >> Permit multiple arguments for the nonnull attribute. >> >> This is very useful for non-trivial functions and doesn't >> affect existing uses. >> >> MFC after: 5 days >> >> Notes: >> svn path=/head/; revision=280273 >> >> >> I'm noticing something wron with "ifconfig scan" too, it listed fine as a >> normal user, but that's not really re-scanning... >> >> % ifconfig wlan0 scan >> SSID/MESH ID BSSID CHAN RATE S:N INT CAPS >> **** *:1c:68 1 54M -93:-96 100 EP RSN HTCAP WPS WPA WME >> **** *:13:c0 6 54M -80:-96 100 EP RSN HTCAP WPS WME >> **** *:e2:0c 6 54M -83:-96 100 EP RSN HTCAP WME >> **** *:f7:8c 6 54M -109:-96 100 EP RSN HTCAP WPS WPA WME >> **** *:4a:12 11 54M -91:-96 100 EP RSN HTCAP WPS WPA WME >> **** *:13:c4 48 54M -80:-96 100 EP RSN HTCAP WME >> >> Trying with sudo gets in a hanged state... >> >> [user@host:/usr/src ]% sudo ifconfig wlan0 scan >> load: 0.17 cmd: ifconfig 11320 [sbwait] 35.72r 0.00u 0.00s 0% 2132k >> load: 0.17 cmd: ifconfig 11320 [sbwait] 36.20r 0.00u 0.00s 0% 2132k >> load: 0.19 cmd: ifconfig 11320 [sbwait] 187.79r 0.00u 0.00s 0% 2132k >> load: 0.19 cmd: ifconfig 11320 [sbwait] 187.94r 0.00u 0.00s 0% 2132k >> load: 0.19 cmd: ifconfig 11320 [sbwait] 188.08r 0.00u 0.00s 0% 2132k >> >> ^C >> >> but after the ^C as a normal user again and: >> ifconfig wlan0 scan >> SSID/MESH ID BSSID CHAN RATE S:N INT CAPS >> ***** *:1c:68 1 54M -94:-96 100 EP RSN HTCAP WPS WPA WME >> ***** *:13:c0 6 54M -80:-96 100 EP RSN HTCAP WPS WME >> ***** *:e2:0c 6 54M -83:-96 100 EP RSN HTCAP WME >> ***** *:f7:8c 6 54M -130:-96 100 EP RSN HTCAP WPS WPA WME >> ***** *:4a:12 1 54M -91:-96 100 EP RSN HTCAP WPS WPA WME >> ***** *:13:c4 48 54M -80:-96 100 EP RSN HTCAP WME >> ***** ... *:99:01 6 54M -96:-96 100 E <------- This is new so it >> re-scanned >> >> >> I see nothing in dmesg >> >>> >>> -adrian >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://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 Mar 20 23:31:52 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 36857B98 for ; Fri, 20 Mar 2015 23:31:52 +0000 (UTC) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001: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 EC3F6D51 for ; Fri, 20 Mar 2015 23:31:51 +0000 (UTC) Received: by igcau2 with SMTP id au2so886499igc.0 for ; Fri, 20 Mar 2015 16:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ObH6O5sJSzdFwtkNqr99/QgUMgNccVehF+YIrHC9QMI=; b=mE97GkI0TK5UpbyF2PucjBYRD1mq7sqyzYLWmpOHoaCxE9zj8Lml1Jbal3RkEEwl1f ZEXKLSKCUg1Agb0ocRYSCCXN50Z7sHXkONswVI7WHNKb370x54+6AyOLIU5VANb6UtSW YUnAx00Jm/7Prfr6kNxfdPfPcNhY3s1RNyKI2wnL2unTcxz5pMj1zRnpmcQCAW5f82xL yxtmX8k/nwyJ42Cd9Ib4E2lzpvsLr1OgiyGNNQRPgfI/Gqwb6ecTnQMsYQUAB1IkxZyG K1RUQZUliQKp50TmQtf0JLrbmzAi0rpD0xsS9kKdIb3mSQDS7WAvNuBnT1JvS5YWOnqn V+AA== MIME-Version: 1.0 X-Received: by 10.42.41.200 with SMTP id q8mr4031259ice.61.1426894311465; Fri, 20 Mar 2015 16:31:51 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.17.194 with HTTP; Fri, 20 Mar 2015 16:31:51 -0700 (PDT) In-Reply-To: <550C9CEF.4040302@icloud.com> References: <550C505F.2030809@icloud.com> <550C9CEF.4040302@icloud.com> Date: Fri, 20 Mar 2015 16:31:51 -0700 X-Google-Sender-Auth: h7eRX05QdtkqKhZjEAxzr0nCrjo Message-ID: Subject: Re: Atheros AR9460 and Acer Aspire V17 Nitro on FreeBSD 11 not working From: Adrian Chadd To: Anders Bolt-Evensen Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Mar 2015 23:31:52 -0000 Hm, ok. either interrupts arne't working, or the thing is deaf. :( can you do that and then in another screen run vmstat -ia | grep ath0 ? I'd like to see if it's at least posting interrupts. -a On 20 March 2015 at 15:19, Anders Bolt-Evensen wrote: > > IEEE_80211_DEBUG is compiled into the kernel. > When I ran "wlandebug +scan", I got the following output: > net.wlan.0.debug: 0x0 => 0x200000 > Then I ran "ifconfig wlan0 up" and then "ifconfig wlan0 scan". > The scan now took a few seconds, but still nothing shows up. > Then I took a look at dmesg -a which was now filled with a loop of the > following messages: > > wlan0: ieee80211_start_scan_locked: active scan, duration 2147483647 > mindwell 0 maxdwell 0, desired mode auto, append, nojoin, once > wlan0: scan set 1g, 6g, 11g, 7g, 13g, 52a, 56a, 60a, 64a, 36a, 40a, 44a, > 48a, 2g, 3g, 4g, 5g, 8g, 9g, 10g, 12g, 149a, 153a, 157a, 161a, 165a, 100a, > 104a, 108a, 112a, 116a, 120a, 124a, 128a, 132a, 136a, 140a dwell min 20ms > max 200ms > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 140a -> 1g [active, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 1g -> 6g [active, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 6g -> 11g [active, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 11g -> 7g [active, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 7g -> 13g [passive, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 13g -> 52a [passive, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 52a -> 56a [passive, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 56a -> 60a [passive, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 60a -> 64a [passive, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 64a -> 36a [passive, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 36a -> 40a [passive, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 40a -> 44a [passive, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 44a -> 48a [passive, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 48a -> 2g [active, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 2g -> 3g [active, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 3g -> 4g [active, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 4g -> 5g [active, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 5g -> 8g [active, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 8g -> 9g [active, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 9g -> 10g [active, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 10g -> 12g [passive, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 12g -> 149a [passive, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 149a -> 153a [passive, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 153a -> 157a [passive, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 157a -> 161a [passive, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 161a -> 165a [passive, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 165a -> 100a [passive, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 100a -> 104a [passive, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 104a -> 108a [passive, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 108a -> 112a [passive, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 112a -> 116a [passive, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 116a -> 120a [passive, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 120a -> 124a [passive, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 124a -> 128a [passive, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 128a -> 132a [passive, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 132a -> 136a [passive, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=0 > wlan0: scan_task: chan 136a -> 140a [passive, dwell min 20ms max 200ms] > wlan0: scan_curchan: calling; maxdwell=200 > wlan0: scan_task: waiting > wlan0: scan_task: loop start; scandone=1 > wlan0: scan_task: out > wlan0: sta_pick_bss: no scan candidate > wlan0: scan_task: done, [ticks 2147275107, dwell min 20 scanend 4294748797] > wlan0: notify scan done > wlan0: ieee80211_scanreq: flags 0x20052 duration 0x7fffffff mindwell 0 > maxdwell 0 nssid 1 > wlan0: ieee80211_check_scan: active scan, append, nojoin, once > wlan0: sta_pick_bss: no scan candidate > > The system kept on printing these messages until I rebooted this machine > back to Windows (in order to write this reply). > > > On 3/20/2015 8:02 PM, Adrian Chadd wrote: >> >> compile in IEEE80211_DEBUG, then "wlandebug +scan", then do the scan. >> >> I wonder if you're hitting some scan bug where the sheer amount of >> traffic going on is causing problems. >> >> Also, seeing RX'ed frames at -130dB is .. oddly wrong for this NIC. >> Something odd is going on. >> >> >> -a >> >> >> On 20 March 2015 at 11:21, Miguel Clara wrote: >>> >>> On Fri, Mar 20, 2015 at 6:01 PM, Adrian Chadd wrote: >>>> >>>> On 20 March 2015 at 09:52, Anders Bolt-Evensen >>>> wrote: >>>>> >>>>> Hello! >>>>> >>>>> Recently I had to buy a new computer as my Mac broke down. >>>>> I ended up with an Acer Aspire V17 Nitro, which, except for a couple of >>>>> problems, is all good. >>>>> One of the problems is that wifi does not work. The wifi driver is an >>>>> Atheros AR9460. >>>>> The problem is that when I attempt to scan for my wireless network, >>>>> nothing >>>>> shows up at all. >>>>> On my previous computer, where I used an external Atheros card, >>>>> everything >>>>> worked well. >>>>> Could the following line from dmesg be a symptom of my problems? >>>>> "ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000" >>>>> >>>>> I'm using FreeBSD 11-CURRENT with sources updated today. >>>> >>>> >>>> What else does it log? >>> >>> >>> I have this same card on a acer s3 (utltrabook) >>> >>> @adrian this is the one I reported the performance issues but now seems >>> to >>> be working ok. >>> >>> For the record this is with --> r280273 >>> >>> commit d7efe7e99e68d52fa754f4e935814c492d818ece >>> Author: pfg >>> Date: Fri Mar 20 01:07:48 2015 +0000 >>> >>> Permit multiple arguments for the nonnull attribute. >>> >>> This is very useful for non-trivial functions and doesn't >>> affect existing uses. >>> >>> MFC after: 5 days >>> >>> Notes: >>> svn path=/head/; revision=280273 >>> >>> >>> I'm noticing something wron with "ifconfig scan" too, it listed fine as a >>> normal user, but that's not really re-scanning... >>> >>> % ifconfig wlan0 scan >>> SSID/MESH ID BSSID CHAN RATE S:N INT CAPS >>> **** *:1c:68 1 54M -93:-96 100 EP RSN HTCAP WPS WPA WME >>> **** *:13:c0 6 54M -80:-96 100 EP RSN HTCAP WPS WME >>> **** *:e2:0c 6 54M -83:-96 100 EP RSN HTCAP WME >>> **** *:f7:8c 6 54M -109:-96 100 EP RSN HTCAP WPS WPA WME >>> **** *:4a:12 11 54M -91:-96 100 EP RSN HTCAP WPS WPA WME >>> **** *:13:c4 48 54M -80:-96 100 EP RSN HTCAP WME >>> >>> Trying with sudo gets in a hanged state... >>> >>> [user@host:/usr/src ]% sudo ifconfig wlan0 scan >>> load: 0.17 cmd: ifconfig 11320 [sbwait] 35.72r 0.00u 0.00s 0% 2132k >>> load: 0.17 cmd: ifconfig 11320 [sbwait] 36.20r 0.00u 0.00s 0% 2132k >>> load: 0.19 cmd: ifconfig 11320 [sbwait] 187.79r 0.00u 0.00s 0% 2132k >>> load: 0.19 cmd: ifconfig 11320 [sbwait] 187.94r 0.00u 0.00s 0% 2132k >>> load: 0.19 cmd: ifconfig 11320 [sbwait] 188.08r 0.00u 0.00s 0% 2132k >>> >>> ^C >>> >>> but after the ^C as a normal user again and: >>> ifconfig wlan0 scan >>> SSID/MESH ID BSSID CHAN RATE S:N INT CAPS >>> ***** *:1c:68 1 54M -94:-96 100 EP RSN HTCAP WPS WPA WME >>> ***** *:13:c0 6 54M -80:-96 100 EP RSN HTCAP WPS WME >>> ***** *:e2:0c 6 54M -83:-96 100 EP RSN HTCAP WME >>> ***** *:f7:8c 6 54M -130:-96 100 EP RSN HTCAP WPS WPA WME >>> ***** *:4a:12 1 54M -91:-96 100 EP RSN HTCAP WPS WPA WME >>> ***** *:13:c4 48 54M -80:-96 100 EP RSN HTCAP WME >>> ***** ... *:99:01 6 54M -96:-96 100 E <------- This is new so it >>> re-scanned >>> >>> >>> I see nothing in dmesg >>> >>>> >>>> -adrian >>>> _______________________________________________ >>>> freebsd-current@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>> To unsubscribe, send any mail to >>>> "freebsd-current-unsubscribe@freebsd.org" >>> >>> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://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 Mar 20 23:52:11 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4427CA0 for ; Fri, 20 Mar 2015 23:52:11 +0000 (UTC) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001: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 0B53BF1E for ; Fri, 20 Mar 2015 23:52:11 +0000 (UTC) Received: by igcau2 with SMTP id au2so1154402igc.0 for ; Fri, 20 Mar 2015 16:52:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=3tseT3+WrNrzl3Hv+BMw/8m0Gw6S+C/uPAbwl+bBnG8=; b=dWa14iQY8x/81NbaRY90lvjvkGVmFsj82QfzyPpYlkFLXVR3TS/V68JH6zVNyAudMS 08iGk9dTwfP8NHWrNgXalwKnO2SodYLC4St5emfktQEDmaibwLg0wj3O8P3iE2+i1QTG IIwpVztwSPwu1UUxloOasfVYrFc0GY0ADKiHLoJVdxe80nSwY4LqoPIu/JBPoeT/DCxz wqQYdBtPrrVWNmE0HOmZ/4ti9qD6llB5dGf78kwz7tQrJPQdg+mHOG+trqKKDZW2rm4s vSUa6FkhT/ayigMDEl163z6XTGuDhkTXV/kI9QgOYTir0FclJ1mv4ysR/qmtiUZbGepW p5YA== MIME-Version: 1.0 X-Received: by 10.42.188.83 with SMTP id cz19mr6907325icb.69.1426895530484; Fri, 20 Mar 2015 16:52:10 -0700 (PDT) Received: by 10.107.156.75 with HTTP; Fri, 20 Mar 2015 16:52:10 -0700 (PDT) Date: Fri, 20 Mar 2015 19:52:10 -0400 Message-ID: Subject: What's the official method to test the build now? From: Ryan Stone To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Mar 2015 23:52:11 -0000 "make tinderbox" has been broken for weeks, so I presume it's not what I'm supposed to be using to test my commits anymore. What's the officially supported make target that I'm supposed to use? From owner-freebsd-current@FreeBSD.ORG Sat Mar 21 00:10:25 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 473BD610 for ; Sat, 21 Mar 2015 00:10:25 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 2A127EC for ; Sat, 21 Mar 2015 00:10:25 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 0AE9232B for ; Sat, 21 Mar 2015 00:10:25 +0000 (UTC) Date: Sat, 21 Mar 2015 00:10:24 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1397906661.5.1426896624987.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1364578405.4.1426882955526.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1364578405.4.1426882955526.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD-tests2 #858 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Mar 2015 00:10:25 -0000 See ------------------------------------------ [...truncated 2462 lines...] lib/libc/string/strspn:strspn -> passed [0.071s] lib/libc/string/swab:swab_basic -> passed [0.051s] lib/libc/sys/access_test:access_access -> passed [0.079s] lib/libc/sys/access_test:access_fault -> passed [0.069s] lib/libc/sys/access_test:access_inval -> passed [0.045s] lib/libc/sys/access_test:access_notdir -> passed [0.068s] lib/libc/sys/access_test:access_notexist -> passed [0.063s] lib/libc/sys/access_test:access_toolong -> passed [0.036s] lib/libc/sys/chroot_test:chroot_basic -> passed [0.076s] lib/libc/sys/chroot_test:chroot_err -> passed [0.053s] lib/libc/sys/chroot_test:chroot_perm -> passed [0.030s] lib/libc/sys/clock_gettime_test:clock_gettime_real -> passed [0.056s] lib/libc/sys/connect_test:connect_low_port -> passed [0.044s] lib/libc/sys/dup_test:dup2_basic -> passed [0.050s] lib/libc/sys/dup_test:dup2_err -> passed [0.030s] lib/libc/sys/dup_test:dup2_max -> passed [0.031s] lib/libc/sys/dup_test:dup2_mode -> passed [0.077s] lib/libc/sys/dup_test:dup3_err -> passed [0.022s] lib/libc/sys/dup_test:dup3_max -> passed [0.028s] lib/libc/sys/dup_test:dup3_mode -> passed [0.040s] lib/libc/sys/dup_test:dup_err -> passed [0.031s] lib/libc/sys/dup_test:dup_max -> passed [0.056s] lib/libc/sys/dup_test:dup_mode -> passed [0.085s] lib/libc/sys/fsync_test:fsync_err -> passed [0.062s] lib/libc/sys/fsync_test:fsync_sync -> passed [0.155s] lib/libc/sys/getcontext_test:getcontext_err -> passed [0.025s] lib/libc/sys/getcontext_test:setcontext_err -> passed [0.076s] lib/libc/sys/getcontext_test:setcontext_link -> passed [0.309s] lib/libc/sys/getgroups_test:getgroups_err -> expected_failure: Reported as kern/189941: /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/sys/t_getgroups.c:63: getgroups(-1, gidset) == -1 not met [0.345s] lib/libc/sys/getgroups_test:getgroups_getgid -> passed [0.109s] lib/libc/sys/getgroups_test:getgroups_setgid -> passed [0.030s] lib/libc/sys/getgroups_test:getgroups_zero -> passed [0.039s] lib/libc/sys/getitimer_test:getitimer_empty -> passed [0.029s] lib/libc/sys/getitimer_test:getitimer_err -> passed [0.041s] lib/libc/sys/getitimer_test:setitimer_basic -> passed [0.033s] lib/libc/sys/getitimer_test:setitimer_err -> passed [0.030s] lib/libc/sys/getitimer_test:setitimer_old -> passed [0.023s] lib/libc/sys/getlogin_test:getlogin_r_err -> passed [0.035s] lib/libc/sys/getlogin_test:getlogin_same -> passed [0.045s] lib/libc/sys/getlogin_test:setlogin_basic -> passed [0.033s] lib/libc/sys/getlogin_test:setlogin_err -> passed [0.031s] lib/libc/sys/getlogin_test:setlogin_perm -> passed [0.031s] lib/libc/sys/getpid_test:getpid_process -> passed [0.043s] lib/libc/sys/getpid_test:getpid_thread -> passed [0.036s] lib/libc/sys/getrusage_test:getrusage_err -> passed [0.032s] lib/libc/sys/getrusage_test:getrusage_sig -> passed [0.034s] lib/libc/sys/getrusage_test:getrusage_utime_back -> passed [2.178s] lib/libc/sys/getrusage_test:getrusage_utime_zero -> skipped: this testcase passes/fails sporadically on FreeBSD/i386 @ r273153 (at least) [0.053s] lib/libc/sys/getsid_test:getsid_current -> passed [0.076s] lib/libc/sys/getsid_test:getsid_err -> passed [0.046s] lib/libc/sys/getsid_test:getsid_process -> passed [0.034s] lib/libc/sys/gettimeofday_test:gettimeofday_err -> passed [0.054s] lib/libc/sys/gettimeofday_test:gettimeofday_mono -> passed [0.039s] lib/libc/sys/issetugid_test:issetugid_egid -> passed [0.056s] lib/libc/sys/issetugid_test:issetugid_euid -> passed [0.077s] lib/libc/sys/issetugid_test:issetugid_rgid -> passed [0.046s] lib/libc/sys/issetugid_test:issetugid_ruid -> passed [0.028s] lib/libc/sys/kevent_test:kevent_zerotimer -> passed [0.038s] lib/libc/sys/kevent_test:kqueue_desc_passing -> passed [0.030s] lib/libc/sys/kevent_test:kqueue_unsupported_fd -> skipped: no /nonexistent available for testing [0.023s] lib/libc/sys/kill_test:kill_basic -> passed [0.027s] lib/libc/sys/kill_test:kill_err -> passed [0.025s] lib/libc/sys/kill_test:kill_perm -> passed [1.131s] lib/libc/sys/kill_test:kill_pgrp_neg -> passed [0.029s] lib/libc/sys/kill_test:kill_pgrp_zero -> passed [0.035s] lib/libc/sys/link_test:link_count -> passed [0.063s] lib/libc/sys/link_test:link_err -> passed [0.056s] lib/libc/sys/link_test:link_perm -> passed [0.033s] lib/libc/sys/link_test:link_stat -> passed [0.036s] lib/libc/sys/listen_test:listen_err -> passed [0.038s] lib/libc/sys/listen_test:listen_low_port -> passed [0.025s] lib/libc/sys/mincore_test:mincore_err -> passed [0.027s] lib/libc/sys/mincore_test:mincore_resid -> passed [0.045s] lib/libc/sys/mincore_test:mincore_shmseg -> passed [0.025s] lib/libc/sys/mkdir_test:mkdir_err -> passed [0.045s] lib/libc/sys/mkdir_test:mkdir_mode -> passed [1.050s] lib/libc/sys/mkdir_test:mkdir_perm -> passed [0.028s] lib/libc/sys/mkdir_test:mkdir_trail -> passed [0.044s] lib/libc/sys/mkfifo_test:mkfifo_block -> passed [1.100s] lib/libc/sys/mkfifo_test:mkfifo_err -> passed [0.029s] lib/libc/sys/mkfifo_test:mkfifo_nonblock -> passed [1.098s] lib/libc/sys/mkfifo_test:mkfifo_perm -> passed [0.029s] lib/libc/sys/mkfifo_test:mkfifo_stat -> passed [0.043s] lib/libc/sys/mknod_test:mknod_err -> passed [0.033s] lib/libc/sys/mknod_test:mknod_exist -> passed [0.027s] lib/libc/sys/mknod_test:mknod_perm -> passed [0.033s] lib/libc/sys/mknod_test:mknod_stat -> expected_failure: mknod does not allow S_IFREG: /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/sys/t_mknod.c:179: mknod(path, S_IFREG, 0) == 0 not met [0.031s] lib/libc/sys/mlock_test:mlock_clip -> passed [0.053s] lib/libc/sys/mlock_test:mlock_err -> passed [0.024s] lib/libc/sys/mlock_test:mlock_limits -> passed [0.025s] lib/libc/sys/mlock_test:mlock_mmap -> passed [0.027s] lib/libc/sys/mlock_test:mlock_nested -> passed [0.029s] lib/libc/sys/mmap_test:mmap_err -> passed [0.057s] lib/libc/sys/mmap_test:mmap_loan -> passed [0.029s] lib/libc/sys/mmap_test:mmap_prot_1 -> passed [0.028s] lib/libc/sys/mmap_test:mmap_prot_2 -> passed [0.162s] lib/libc/sys/mmap_test:mmap_prot_3 -> passed [0.279s] lib/libc/sys/mmap_test:mmap_truncate -> passed [0.075s] lib/libc/sys/mmap_test:mmap_va0 -> passed [0.043s] lib/libc/sys/mprotect_test:mprotect_access -> passed [0.046s] lib/libc/sys/mprotect_test:mprotect_err -> passed [0.026s] lib/libc/sys/mprotect_test:mprotect_pax -> passed [0.043s] lib/libc/sys/mprotect_test:mprotect_write -> passed [0.078s] lib/libc/sys/msgctl_test:msgctl_err -> passed [0.074s] lib/libc/sys/msgctl_test:msgctl_perm -> passed [0.044s] lib/libc/sys/msgctl_test:msgctl_pid -> passed [2.091s] lib/libc/sys/msgctl_test:msgctl_set -> passed [0.038s] lib/libc/sys/msgctl_test:msgctl_time -> passed [0.033s] lib/libc/sys/msgget_test:msgget_excl -> passed [0.036s] lib/libc/sys/msgget_test:msgget_exit -> passed [0.048s] lib/libc/sys/msgget_test:msgget_init -> passed [0.046s] lib/libc/sys/msgget_test:msgget_limit -> passed [0.031s] lib/libc/sys/msgget_test:msgget_mode -> passed [0.031s] lib/libc/sys/msgrcv_test:msgrcv_basic -> passed [0.054s] lib/libc/sys/msgrcv_test:msgrcv_block -> passed [2.144s] lib/libc/sys/msgrcv_test:msgrcv_err -> passed [0.027s] lib/libc/sys/msgrcv_test:msgrcv_mtype -> passed [0.033s] lib/libc/sys/msgrcv_test:msgrcv_nonblock -> passed [2.068s] lib/libc/sys/msgrcv_test:msgrcv_truncate -> passed [0.036s] lib/libc/sys/msgsnd_test:msgsnd_block -> passed [2.109s] lib/libc/sys/msgsnd_test:msgsnd_count -> passed [0.057s] lib/libc/sys/msgsnd_test:msgsnd_err -> passed [0.038s] lib/libc/sys/msgsnd_test:msgsnd_nonblock -> passed [2.046s] lib/libc/sys/msgsnd_test:msgsnd_perm -> passed [0.054s] lib/libc/sys/msync_test:msync_async -> passed [0.072s] lib/libc/sys/msync_test:msync_err -> passed [0.058s] lib/libc/sys/msync_test:msync_invalidate -> passed [0.049s] lib/libc/sys/msync_test:msync_sync -> passed [0.042s] lib/libc/sys/nanosleep_test:nanosleep_basic -> passed [0.059s] lib/libc/sys/nanosleep_test:nanosleep_err -> passed [0.029s] lib/libc/sys/nanosleep_test:nanosleep_sig -> passed [1.116s] lib/libc/sys/pipe_test:pipe_restart -> passed [2.143s] lib/libc/sys/pipe2_test:pipe2_basic -> passed [0.061s] lib/libc/sys/pipe2_test:pipe2_cloexec -> passed [0.049s] lib/libc/sys/pipe2_test:pipe2_consume -> passed [0.036s] lib/libc/sys/pipe2_test:pipe2_einval -> passed [0.035s] lib/libc/sys/pipe2_test:pipe2_nonblock -> passed [0.043s] lib/libc/sys/poll_test:poll_3way -> passed [10.159s] lib/libc/sys/poll_test:poll_basic -> passed [0.049s] lib/libc/sys/poll_test:poll_err -> passed [0.036s] lib/libc/sys/revoke_test:revoke_basic -> skipped: revoke(2) is only implemented for devfs(5). [0.041s] lib/libc/sys/revoke_test:revoke_err -> skipped: revoke(2) is only implemented for devfs(5). [0.024s] lib/libc/sys/revoke_test:revoke_perm -> skipped: revoke(2) is only implemented for devfs(5). [0.028s] lib/libc/sys/select_test:pselect_sigmask -> passed [1.036s] lib/libc/sys/select_test:pselect_timeout -> passed [0.025s] lib/libc/sys/setrlimit_test:setrlimit_basic -> passed [0.047s] lib/libc/sys/setrlimit_test:setrlimit_current -> passed [0.023s] lib/libc/sys/setrlimit_test:setrlimit_err -> passed [0.023s] lib/libc/sys/setrlimit_test:setrlimit_fsize -> passed [0.029s] lib/libc/sys/setrlimit_test:setrlimit_memlock -> passed [0.024s] lib/libc/sys/setrlimit_test:setrlimit_nofile_1 -> passed [0.025s] lib/libc/sys/setrlimit_test:setrlimit_nofile_2 -> passed [0.024s] lib/libc/sys/setrlimit_test:setrlimit_nproc -> maxproc limit exceeded by uid 977 (pid 21454); see tuning(7) and login.conf(5) passed [0.565s] lib/libc/sys/setrlimit_test:setrlimit_perm -> panic: mutex process lock not owned at /builds/FreeBSD_HEAD/sys/kern/kern_prot.c:1974 cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00974bd8e0 vpanic() at vpanic+0x189/frame 0xfffffe00974bd960 panic() at panic+0x43/frame 0xfffffe00974bd9c0 __mtx_assert() at __mtx_assert+0xc2/frame 0xfffffe00974bd9d0 proc_set_cred() at proc_set_cred+0x36/frame 0xfffffe00974bd9f0 fork1() at fork1+0x27e/frame 0xfffffe00974bdac0 sys_fork() at sys_fork+0x1f/frame 0xfffffe00974bdae0 amd64_syscall() at amd64_syscall+0x27f/frame 0xfffffe00974bdbf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe00974bdbf0 --- syscall (0, FreeBSD ELF64, nosys), rip = 0x8019c516a, rsp = 0x7fffffffc2d8, rbp = 0x7fffffffc340 --- KDB: enter: panic [ thread pid 660 tid 100072 ] Stopped at kdb_enter+0x3e: movq $0,kdb_why db> Traceback (most recent call last): File "/vm/freebsd-ci/scripts/test/run-tests.py", line 152, in main(sys.argv) File "/vm/freebsd-ci/scripts/test/run-tests.py", line 80, in main runTest() File "/vm/freebsd-ci/scripts/test/run-tests.py", line 124, in runTest child2.expect(prompt, timeout=7200) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1451, in expect timeout, searchwindowsize) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1466, in expect_list timeout, searchwindowsize) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1568, in expect_loop raise TIMEOUT(str(err) + '\n' + str(self)) pexpect.TIMEOUT: Timeout exceeded. version: 3.3 command: /usr/sbin/bhyve args: [u'/usr/sbin/bhyve', u'-c', u'2', u'-m', u'2G', u'-AI', u'-H', u'-P', u'-g', u'0', u'-s', u'0:0,hostbridge', u'-s', u'1:0,lpc', u'-s', u'2:0,virtio-net,tap0,mac=58:9c:fc:00:00:2e', u'-s', u'3:0,ahci-hd,/net/jenkins-10.freebsd.org/builds/Build-UFS-image/image/FreeBSD_HEAD/test.img', u'-l', u'com1,stdio', u'vm_test'] searcher: buffer (last 100 chars): 'nter: panic\r\n[ thread pid 660 tid 100072 ]\r\nStopped at kdb_enter+0x3e: movq $0,kdb_why\r\ndb> ' before (last 100 chars): 'nter: panic\r\n[ thread pid 660 tid 100072 ]\r\nStopped at kdb_enter+0x3e: movq $0,kdb_why\r\ndb> ' after: match: None match_index: None exitstatus: None flag_eof: False pid: 10451 child_fd: 4 closed: False timeout: 30 delimiter: logfile: ', mode 'w' at 0x800670150> logfile_read: None logfile_send: None maxread: 2000 ignorecase: False searchwindowsize: None delaybeforesend: 0.05 delayafterclose: 0.1 delayafterterminate: 0.1 Build step 'Execute shell' marked build as failure Recording test results ERROR: Publisher hudson.tasks.junit.JUnitResultArchiver aborted due to exception hudson.AbortException: Test reports were found but none of them are new. Did tests run? For example, is 5 days 22 hr old at hudson.tasks.junit.TestResult.parse(TestResult.java:178) at hudson.tasks.junit.TestResult.parse(TestResult.java:146) at hudson.tasks.junit.TestResult.(TestResult.java:122) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:119) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:92) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2688) at hudson.remoting.UserRequest.perform(UserRequest.java:121) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at hudson.remoting.Request$2.run(Request.java:324) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) at ......remote call to havoc.ysv.freebsd.org(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1356) at hudson.remoting.UserResponse.retrieve(UserRequest.java:221) at hudson.remoting.Channel.call(Channel.java:752) at hudson.FilePath.act(FilePath.java:978) at hudson.FilePath.act(FilePath.java:967) at hudson.tasks.junit.JUnitParser.parseResult(JUnitParser.java:89) at hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:120) at hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:137) at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:74) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:761) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:721) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:670) at hudson.model.Run.execute(Run.java:1775) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240) From owner-freebsd-current@FreeBSD.ORG Sat Mar 21 01:00:45 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 45F8A330; Sat, 21 Mar 2015 01:00:45 +0000 (UTC) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::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 DCE428D4; Sat, 21 Mar 2015 01:00:44 +0000 (UTC) Received: by wgbcc7 with SMTP id cc7so102164420wgb.0; Fri, 20 Mar 2015 18:00:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=9sdzZF1vZ6uUxanKu0S+SEXCg9NnyeFjltdUIFVWQEw=; b=os2omYscDFBS1MNe4xCo+k1EMUjksHTjvAootZkm9mSdXlLUniMVFoMXcYIJL7Zd+1 yuvsx3tknRSt7K6MVcqsmltYbtVQlwayRXWI8NLBkIwv/1jb+6z7fJY2ewpHnifg2f+m WU5KiLgkdGb5W0+MSwA+KBNYEs6qswtiyiITUCA8F0l4BzuVvyjeOolVCXh48qJfCCcw KxoxEdCZh1PE95I2rdmX5rx6jZNwEMe8qii7t5CbD0OBT2JUs42ZKD55ipqS8/LYSACK LVW377Lx97dnL1rdsXwOYIRMigTnd/tZEkGmktHvzI0zq96+j+5rehw6LUgM46Z2Be4i xTiw== X-Received: by 10.180.74.135 with SMTP id t7mr686145wiv.72.1426899643337; Fri, 20 Mar 2015 18:00:43 -0700 (PDT) Received: from localhost.localdomain (ip-89-176-114-84.net.upcbroadband.cz. [89.176.114.84]) by mx.google.com with ESMTPSA id q6sm303207wix.3.2015.03.20.18.00.41 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Mar 2015 18:00:42 -0700 (PDT) From: Mateusz Guzik To: Konstantin Belousov Subject: [PATCH 0/3] fix up some recent proc fallout and more Date: Sat, 21 Mar 2015 02:00:37 +0100 Message-Id: <1426899640-6599-1-git-send-email-mjguzik@gmail.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <20150320122125.GP2379@kib.kiev.ua> References: <20150320122125.GP2379@kib.kiev.ua> Cc: freebsd-current@freebsd.org, jenkins-admin@freebsd.org, Mateusz Guzik X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Mar 2015 01:00:45 -0000 From: Mateusz Guzik Patches in this series fix a bug introduced in r280130 and deal with additional issues. I'm not happy with how sutff is being done at the moment. In particular we zero out various fields on process exit, which puts it into a state state which is not guaranteed when we deal when it is first allocated. But I guess we can leave it as it is for now. I don't believe we have a good solution at the moment which would poison memory returned by uma_zalloc, that would definitely make the issue apparent right of the bat. Adding such a feature sould be reasonably simple but fallout may take some time to deal with, I'll make a follow up thread. Mateusz Guzik (3): fork: assign refed credentials earlier cred: add proc_set_cred_init helper proc: use MTX_NEW flag in proc_init sys/kern/init_main.c | 2 +- sys/kern/kern_fork.c | 15 +++++++-------- sys/kern/kern_proc.c | 11 +++++------ sys/kern/kern_prot.c | 16 ++++++++++++++-- sys/sys/ucred.h | 1 + 5 files changed, 28 insertions(+), 17 deletions(-) -- 2.3.2 From owner-freebsd-current@FreeBSD.ORG Sat Mar 21 01:00:46 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C471B36D; Sat, 21 Mar 2015 01:00:46 +0000 (UTC) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5691A8D5; Sat, 21 Mar 2015 01:00:46 +0000 (UTC) Received: by wibdy8 with SMTP id dy8so1720128wib.0; Fri, 20 Mar 2015 18:00:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=c6UW0jqQpJmbe6VXmLgDJ0OZiJtr7ft3TXY9n8XVkWk=; b=zyK7orKS6y62BZV02mkoNW05Q6fkVSqtk8X7PsAlmNjxbP5S/Y6DcD1PYWQELdockp RYL19jMK54y4UW3jZJsy5RlUHWHKwUP7i9nDa6cDRafdbvJFKcRQ4GcVbsyFtbKVvAUE qePu5ngM0KRjyEREv2D9sPwlw0q6p2bhzf8Eqm1bybhrXotv23efhcDadlRObQA0VH56 Too4XuxKMHIS1TWPyuUw15H+xKVOEjL++G7HJxz82G5+HVDn1bNk3o7PIyULxzL1cXkc Q9vHbNlrVOPAvYvbccBs+oCVgdheFPOvd++7bCK5oOv5SaFE7c69x4CvHAyHORS5dGuQ 6BKg== X-Received: by 10.180.24.162 with SMTP id v2mr659912wif.80.1426899644727; Fri, 20 Mar 2015 18:00:44 -0700 (PDT) Received: from localhost.localdomain (ip-89-176-114-84.net.upcbroadband.cz. [89.176.114.84]) by mx.google.com with ESMTPSA id q6sm303207wix.3.2015.03.20.18.00.43 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Mar 2015 18:00:43 -0700 (PDT) From: Mateusz Guzik To: Konstantin Belousov Subject: [PATCH 1/3] fork: assign refed credentials earlier Date: Sat, 21 Mar 2015 02:00:38 +0100 Message-Id: <1426899640-6599-2-git-send-email-mjguzik@gmail.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1426899640-6599-1-git-send-email-mjguzik@gmail.com> References: <20150320122125.GP2379@kib.kiev.ua> <1426899640-6599-1-git-send-email-mjguzik@gmail.com> Cc: freebsd-current@freebsd.org, jenkins-admin@freebsd.org, Mateusz Guzik X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Mar 2015 01:00:47 -0000 From: Mateusz Guzik Prior to this change the kernel would take p1's credentials and assign them tempororarily to p2. But p1 could change credentials at that time and in effect give us a use-after-free. --- sys/kern/kern_fork.c | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/sys/kern/kern_fork.c b/sys/kern/kern_fork.c index ae86fe1..15833fd 100644 --- a/sys/kern/kern_fork.c +++ b/sys/kern/kern_fork.c @@ -410,9 +410,6 @@ do_fork(struct thread *td, int flags, struct proc *p2, struct thread *td2, bzero(&p2->p_startzero, __rangeof(struct proc, p_startzero, p_endzero)); - crhold(td->td_ucred); - proc_set_cred(p2, td->td_ucred); - /* Tell the prison that we exist. */ prison_proc_hold(p2->p_ucred->cr_prison); @@ -832,7 +829,7 @@ fork1(struct thread *td, int flags, int pages, struct proc **procp, td2 = thread_alloc(pages); if (td2 == NULL) { error = ENOMEM; - goto fail1; + goto fail2; } proc_linkup(newproc, td2); } else { @@ -841,7 +838,7 @@ fork1(struct thread *td, int flags, int pages, struct proc **procp, vm_thread_dispose(td2); if (!thread_alloc_stack(td2, pages)) { error = ENOMEM; - goto fail1; + goto fail2; } } } @@ -850,7 +847,7 @@ fork1(struct thread *td, int flags, int pages, struct proc **procp, vm2 = vmspace_fork(p1->p_vmspace, &mem_charged); if (vm2 == NULL) { error = ENOMEM; - goto fail1; + goto fail2; } if (!swap_reserve(mem_charged)) { /* @@ -861,7 +858,7 @@ fork1(struct thread *td, int flags, int pages, struct proc **procp, */ swap_reserve_force(mem_charged); error = ENOMEM; - goto fail1; + goto fail2; } } else vm2 = NULL; @@ -870,7 +867,7 @@ fork1(struct thread *td, int flags, int pages, struct proc **procp, * XXX: This is ugly; when we copy resource usage, we need to bump * per-cred resource counters. */ - proc_set_cred(newproc, p1->p_ucred); + proc_set_cred(newproc, crhold(td->td_ucred)); /* * Initialize resource accounting for the child process. @@ -946,6 +943,8 @@ fail: #endif racct_proc_exit(newproc); fail1: + crfree(proc_set_cred(newproc, NULL)); +fail2: if (vm2 != NULL) vmspace_free(vm2); uma_zfree(proc_zone, newproc); -- 2.3.2 From owner-freebsd-current@FreeBSD.ORG Sat Mar 21 01:00:48 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E97C423; Sat, 21 Mar 2015 01:00:48 +0000 (UTC) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::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 BC8568D7; Sat, 21 Mar 2015 01:00:47 +0000 (UTC) Received: by wgra20 with SMTP id a20so102221603wgr.3; Fri, 20 Mar 2015 18:00:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=Z2tEfOSHTCkUi4Cm8kzUt47r2yCE6TW86AgnwUNqE88=; b=e2eprLsslYV/9lkpVI4LWGrKrqgRb7AUZ/rhheyf2iCKdBRdSeK+sMIsqI9tPoUQ9J bmCE9QGbph3QWQmZGb4CKj+flciGVv476IQjph2eypwhaw3jI+0ZCPY8wTb7IuKuxF41 5IPfGFBYmbufv4DhfhIHDwHHPx8KyYBGqSygdyaxKuPQddFliFMY2NHX1FIbEDWc+fz5 i+aWYHGFd2vikck19m8hDMLOkgAWU99Z5P/oEmtjBv1sXHk9ZpZ9hbS/nkD6HZ8mxrfv XFP3mNHn6yNcbcPiyl+m1GLUPc6/KNWYHjpd3UBOX9v+JF/NllEFI1gVFT3DC41NbxWF o3ow== X-Received: by 10.180.103.166 with SMTP id fx6mr704038wib.4.1426899646015; Fri, 20 Mar 2015 18:00:46 -0700 (PDT) Received: from localhost.localdomain (ip-89-176-114-84.net.upcbroadband.cz. [89.176.114.84]) by mx.google.com with ESMTPSA id q6sm303207wix.3.2015.03.20.18.00.44 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Mar 2015 18:00:45 -0700 (PDT) From: Mateusz Guzik To: Konstantin Belousov Subject: [PATCH 2/3] cred: add proc_set_cred_init helper Date: Sat, 21 Mar 2015 02:00:39 +0100 Message-Id: <1426899640-6599-3-git-send-email-mjguzik@gmail.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1426899640-6599-1-git-send-email-mjguzik@gmail.com> References: <20150320122125.GP2379@kib.kiev.ua> <1426899640-6599-1-git-send-email-mjguzik@gmail.com> Cc: freebsd-current@freebsd.org, jenkins-admin@freebsd.org, Mateusz Guzik X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Mar 2015 01:00:48 -0000 From: Mateusz Guzik proc_set_cred_init can be used to set first credentials of a new process. Update proc_set_cred assertions so that it only expects already used processes. This fixes panics where p_ucred of a new process happens to be non-NULL. --- sys/kern/init_main.c | 2 +- sys/kern/kern_fork.c | 2 +- sys/kern/kern_prot.c | 16 ++++++++++++++-- sys/sys/ucred.h | 1 + 4 files changed, 17 insertions(+), 4 deletions(-) diff --git a/sys/kern/init_main.c b/sys/kern/init_main.c index 82cf63f..88cd44c 100644 --- a/sys/kern/init_main.c +++ b/sys/kern/init_main.c @@ -515,7 +515,7 @@ proc0_init(void *dummy __unused) newcred->cr_ruidinfo = uifind(0); newcred->cr_prison = &prison0; newcred->cr_loginclass = loginclass_find("default"); - proc_set_cred(p, newcred); + proc_set_cred_init(p, newcred); #ifdef AUDIT audit_cred_kproc0(newcred); #endif diff --git a/sys/kern/kern_fork.c b/sys/kern/kern_fork.c index 15833fd..a3a70b8 100644 --- a/sys/kern/kern_fork.c +++ b/sys/kern/kern_fork.c @@ -867,7 +867,7 @@ fork1(struct thread *td, int flags, int pages, struct proc **procp, * XXX: This is ugly; when we copy resource usage, we need to bump * per-cred resource counters. */ - proc_set_cred(newproc, crhold(td->td_ucred)); + proc_set_cred_init(newproc, crhold(td->td_ucred)); /* * Initialize resource accounting for the child process. diff --git a/sys/kern/kern_prot.c b/sys/kern/kern_prot.c index 72c9f65..9c49f71 100644 --- a/sys/kern/kern_prot.c +++ b/sys/kern/kern_prot.c @@ -1954,8 +1954,19 @@ cred_update_thread(struct thread *td) } /* + * Set initial process credentials. + * Callers are responsible for providing the reference for provided credentials. + */ +void +proc_set_cred_init(struct proc *p, struct ucred *newcred) +{ + + p->p_ucred = newcred; +} + +/* * Change process credentials. - * Callers are responsible for providing the reference for current credentials + * Callers are responsible for providing the reference for passed credentials * and for freeing old ones. * * Process has to be locked except when it does not have credentials (as it @@ -1968,9 +1979,10 @@ proc_set_cred(struct proc *p, struct ucred *newcred) { struct ucred *oldcred; + MPASS(p->p_ucred != NULL); if (newcred == NULL) MPASS(p->p_state == PRS_ZOMBIE); - else if (p->p_ucred != NULL) + else PROC_LOCK_ASSERT(p, MA_OWNED); oldcred = p->p_ucred; diff --git a/sys/sys/ucred.h b/sys/sys/ucred.h index 2b42b01..9a45308 100644 --- a/sys/sys/ucred.h +++ b/sys/sys/ucred.h @@ -106,6 +106,7 @@ void crcopy(struct ucred *dest, struct ucred *src); struct ucred *crcopysafe(struct proc *p, struct ucred *cr); struct ucred *crdup(struct ucred *cr); void cred_update_thread(struct thread *td); +void proc_set_cred_init(struct proc *p, struct ucred *cr); struct ucred *proc_set_cred(struct proc *p, struct ucred *cr); void crfree(struct ucred *cr); struct ucred *crget(void); -- 2.3.2 From owner-freebsd-current@FreeBSD.ORG Sat Mar 21 01:00:49 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E4374DA; Sat, 21 Mar 2015 01:00:49 +0000 (UTC) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::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 135158D8; Sat, 21 Mar 2015 01:00:49 +0000 (UTC) Received: by wgbcc7 with SMTP id cc7so102165266wgb.0; Fri, 20 Mar 2015 18:00:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=yOzA4tTs9EG9FpYpB6Q8LsIKrgipq4PA5GLsmZ2Cevo=; b=kWp2bks7gnv3Z4/QWcCpf8LfUsv7SVzKwkl03s3ClKPwb/4wO3ZIAp8ivSNhEeOzSH xRFGm69cYC/1fBz/9YsNqEbktacZw/9w8kBEofmkaaVERAM8ugQ8gDVL0lrlQefoOW9X kRRJ1sg6yDIgu8bPb92v5eHsboc3oOSWXj0nshxp3Q0TNlv9UrYjkWljabsi8sAcZvRS zg3eYePkMhNOiY3AF18ay6wWUqsVU3yuWPsrs5/WLhxpFjCdnD4aYO3ZHtPMW+azVX6j HTkIQNQB5cFpn5JleIfu2Fnb7ksZgjSxq4j4pvoO1SHTg91UE5ltJOu9xQUTKFG8dqlU U0CA== X-Received: by 10.180.75.233 with SMTP id f9mr654333wiw.5.1426899647587; Fri, 20 Mar 2015 18:00:47 -0700 (PDT) Received: from localhost.localdomain (ip-89-176-114-84.net.upcbroadband.cz. [89.176.114.84]) by mx.google.com with ESMTPSA id q6sm303207wix.3.2015.03.20.18.00.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Mar 2015 18:00:46 -0700 (PDT) From: Mateusz Guzik To: Konstantin Belousov Subject: [PATCH 3/3] proc: use MTX_NEW flag in proc_init Date: Sat, 21 Mar 2015 02:00:40 +0100 Message-Id: <1426899640-6599-4-git-send-email-mjguzik@gmail.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1426899640-6599-1-git-send-email-mjguzik@gmail.com> References: <20150320122125.GP2379@kib.kiev.ua> <1426899640-6599-1-git-send-email-mjguzik@gmail.com> Cc: freebsd-current@freebsd.org, jenkins-admin@freebsd.org, Mateusz Guzik X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Mar 2015 01:00:49 -0000 From: Mateusz Guzik This allows us to get rid of bzero which was added specifically to make mtx_init on p_mtx reliable. This also fixes a potential problem where mtx_init on other mutexes could trip over on unitialized memory and fire an assertion. --- sys/kern/kern_proc.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/sys/kern/kern_proc.c b/sys/kern/kern_proc.c index a607d7b1..f72269d 100644 --- a/sys/kern/kern_proc.c +++ b/sys/kern/kern_proc.c @@ -225,12 +225,11 @@ proc_init(void *mem, int size, int flags) p = (struct proc *)mem; SDT_PROBE(proc, kernel, init, entry, p, size, flags, 0, 0); p->p_sched = (struct p_sched *)&p[1]; - bzero(&p->p_mtx, sizeof(struct mtx)); - mtx_init(&p->p_mtx, "process lock", NULL, MTX_DEF | MTX_DUPOK); - mtx_init(&p->p_slock, "process slock", NULL, MTX_SPIN); - mtx_init(&p->p_statmtx, "pstatl", NULL, MTX_SPIN); - mtx_init(&p->p_itimmtx, "pitiml", NULL, MTX_SPIN); - mtx_init(&p->p_profmtx, "pprofl", NULL, MTX_SPIN); + mtx_init(&p->p_mtx, "process lock", NULL, MTX_DEF | MTX_DUPOK | MTX_NEW); + mtx_init(&p->p_slock, "process slock", NULL, MTX_SPIN | MTX_NEW); + mtx_init(&p->p_statmtx, "pstatl", NULL, MTX_SPIN | MTX_NEW); + mtx_init(&p->p_itimmtx, "pitiml", NULL, MTX_SPIN | MTX_NEW); + mtx_init(&p->p_profmtx, "pprofl", NULL, MTX_SPIN | MTX_NEW); cv_init(&p->p_pwait, "ppwait"); cv_init(&p->p_dbgwait, "dbgwait"); TAILQ_INIT(&p->p_threads); /* all threads in proc */ -- 2.3.2 From owner-freebsd-current@FreeBSD.ORG Sat Mar 21 01:02:25 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 279D973E; Sat, 21 Mar 2015 01:02:25 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 A30AC907; Sat, 21 Mar 2015 01:02:24 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t2L12Ia4010730 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 21 Mar 2015 03:02:19 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t2L12Ia4010730 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t2L12IX6010729; Sat, 21 Mar 2015 03:02:18 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 21 Mar 2015 03:02:18 +0200 From: Konstantin Belousov To: "Ivan A. Kosarev" Subject: Re: Use of chunksize before initialization Message-ID: <20150321010218.GD2379@kib.kiev.ua> References: <550C27D8.2010105@ivan-labs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <550C27D8.2010105@ivan-labs.com> User-Agent: Mutt/1.5.23 (2014-03-12) 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,WEIRD_PORT autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-current@freebsd.org, Ed Maste X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Mar 2015 01:02:25 -0000 On Fri, Mar 20, 2015 at 03:59:52PM +0200, Ivan A. Kosarev wrote: > Hello everybody, > > The malloc_init_hard() function defined in jemalloc_jemalloc.c, FreeBSD > 11 r277486 reads: > > static bool > malloc_init_hard(void) > { > ... > if (base_boot()) { > malloc_mutex_unlock(&init_lock); > eturn (true); > } > > if (chunk_boot()) { > malloc_mutex_unlock(&init_lock); > return (true); > } > ... > > The second call initializes the 'chunksize' global variable defined in > jemalloc_chunk.c: > > bool > chunk_boot(void) > { > /* Set variables according to the value of opt_lg_chunk. */ > chunksize = (ZU(1) << opt_lg_chunk); > assert(chunksize >= PAGE); > ... > > However, it seems the first call to base_boot() depends on that variable > already: > > (gdb) bt > #0 thr_kill () at thr_kill.S:3 > #1 0x0000000801241408 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:51 > #2 0x000000000041d817 in __interceptor_raise () at > /usr/home/ik/llvm/llvm.current/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:2097 > #3 0x000000080123f969 in abort () at /usr/src/lib/libc/stdlib/abort.c:65 > #4 0x000000000041c5d9 in __interceptor_abort () at > /usr/home/ik/llvm/llvm.current/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:1851 > #5 0x00000008011a8d64 in __je_chunk_alloc (size=, > alignment=, base=, zero=, > dss_prec=dss_prec_disabled) at jemalloc_chunk.c:150 > #6 0x00000008011a9bfc in base_pages_alloc (minsize=128) at > jemalloc_base.c:35 > #7 __je_base_alloc (size=) at jemalloc_base.c:57 > #8 0x00000008011a9c96 in __je_base_calloc (number=, > size=6) at jemalloc_base.c:74 > #9 0x00000008008ae548 in mutex_init (calloc_cb=0x0, mutex= out>, mutex_attr=) at > /usr/src/lib/libthr/thread/thr_mutex.c:145 > #10 _pthread_mutex_init_calloc_cb (mutex=0x801487c90, calloc_cb=0x0) at > /usr/src/lib/libthr/thread/thr_mutex.c:229 > #11 0x00000008011a18da in __je_malloc_mutex_init (mutex=0x18744) at > jemalloc_mutex.c:97 > #12 0x00000008011b428d in malloc_init_hard () at jemalloc_jemalloc.c:698 > #13 malloc_init () at jemalloc_jemalloc.c:296 > #14 0x0000000801243ea2 in ?? () from /lib/libc.so.7 > #15 0x00000008006a5400 in ?? () > #16 0x000000080089e5b0 in ?? () from /libexec/ld-elf.so.1 > #17 0x00007fffffffe0b0 in ?? () > #18 0x0000000801139d06 in _init () from /lib/libc.so.7 > #19 0x00007fffffffe0b0 in ?? () The backtrace is strange. Did you compiled malloc with the debugging symbols, while keep rest of libc without -g ? Does it happen always, on only for the early initialization of the mutexes ? It might be related to r276630. Can you test on, say, 10.1 ? > > Note that base_pages() calls chunk_alloc() with chucksize used as the > alignment value: > > static bool > base_pages_alloc(size_t minsize) > { > ... > base_pages = chunk_alloc(csize, chunksize, true, &zero, > chunk_dss_prec_get()); > ... > > and the latter tests it against zero: > > void * > chunk_alloc(size_t size, size_t alignment, bool base, bool *zero, > dss_prec_t dss_prec) > { > ... > assert(alignment != 0); > .... > > so we sometimes we end up with: > > : jemalloc_chunk.c:152: Failed assertion: "alignment != 0" > > Here's more of failures of this kind around: > > http://lab.llvm.org:8011/builders/sanitizer_x86_64-freebsd/builds/4758/steps/make-check-tsan/logs/stdio > > Can you please let me know if the analysis is correct and there's > something to fix about initialization of the variable? > Backtrace looks valid. From owner-freebsd-current@FreeBSD.ORG Sat Mar 21 01:31:30 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4B677C3A for ; Sat, 21 Mar 2015 01:31:30 +0000 (UTC) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::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 03BBCBDB for ; Sat, 21 Mar 2015 01:31:30 +0000 (UTC) Received: by qcay5 with SMTP id y5so17512499qca.1 for ; Fri, 20 Mar 2015 18:31:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qQvG4Ir+Bdkby7ZAqF4E8IAodaPRBmcVsMlkZCsr0Go=; b=TzV8APhZ8CmzcTuISppYwyh2humqa5HOpsqw2F4Q7/NOPFm1y9FfY1WqmOQzzFqfOU T2W+bhjZUoYUgx924N7LbF2XI4FM0TX52lNqDkDrw708CZDcjupbZikEJAY1Kn/D/Z9x sbYWpuykpg9YpWftFpG8l8d4pbfxrDwF3AVk6iklVEoYaLeP+Bf2G3M4C1y0ZVguaMme YCQ7TQFuuwdCmc2JwUEJYA1ukb79/To3WZMaHjO1cJlYGaL8cqJHExtsR5gkNwhDVDKU Jhgc4naJlV0qN1iUYE6fJyER9Nvsh5OM6qzK3DV7p5huuaBFvQGi1xszydDQ3eip6Gi4 alCQ== MIME-Version: 1.0 X-Received: by 10.55.23.6 with SMTP id i6mr114255110qkh.39.1426901489192; Fri, 20 Mar 2015 18:31:29 -0700 (PDT) Received: by 10.140.94.99 with HTTP; Fri, 20 Mar 2015 18:31:29 -0700 (PDT) In-Reply-To: References: Date: Fri, 20 Mar 2015 18:31:29 -0700 Message-ID: Subject: Re: What's the official method to test the build now? From: NGie Cooper To: Ryan Stone Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Mar 2015 01:31:30 -0000 On Fri, Mar 20, 2015 at 4:52 PM, Ryan Stone wrote: > "make tinderbox" has been broken for weeks, so I presume it's not what I'm > supposed to be using to test my commits anymore. What's the officially > supported make target that I'm supposed to use? It should work. If it doesn't, then we need to do a fixathon for it.. Folks might not have been setting SRCCONF / __MAKE_CONF to /dev/null before committing to head by accident :/.. From owner-freebsd-current@FreeBSD.ORG Sat Mar 21 01:51:58 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96226253; Sat, 21 Mar 2015 01:51:58 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 37E46D8A; Sat, 21 Mar 2015 01:51:58 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t2L1ppKv022487 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 21 Mar 2015 03:51:51 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t2L1ppKv022487 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t2L1ppLc022486; Sat, 21 Mar 2015 03:51:51 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 21 Mar 2015 03:51:51 +0200 From: Konstantin Belousov To: Mateusz Guzik Subject: Re: [PATCH 1/3] fork: assign refed credentials earlier Message-ID: <20150321015151.GF2379@kib.kiev.ua> References: <20150320122125.GP2379@kib.kiev.ua> <1426899640-6599-1-git-send-email-mjguzik@gmail.com> <1426899640-6599-2-git-send-email-mjguzik@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1426899640-6599-2-git-send-email-mjguzik@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) 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.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-current@freebsd.org, jenkins-admin@freebsd.org, Mateusz Guzik X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Mar 2015 01:51:58 -0000 On Sat, Mar 21, 2015 at 02:00:38AM +0100, Mateusz Guzik wrote: > From: Mateusz Guzik > > Prior to this change the kernel would take p1's credentials and assign > them tempororarily to p2. But p1 could change credentials at that time > and in effect give us a use-after-free. In which way could it change the credentials ? The assigned credentials are taken from td_ucred, which, I thought, are guaranteed to be stable for the duration of a syscall. Other two patches look fine. > --- > sys/kern/kern_fork.c | 15 +++++++-------- > 1 file changed, 7 insertions(+), 8 deletions(-) > > diff --git a/sys/kern/kern_fork.c b/sys/kern/kern_fork.c > index ae86fe1..15833fd 100644 > --- a/sys/kern/kern_fork.c > +++ b/sys/kern/kern_fork.c > @@ -410,9 +410,6 @@ do_fork(struct thread *td, int flags, struct proc *p2, struct thread *td2, > bzero(&p2->p_startzero, > __rangeof(struct proc, p_startzero, p_endzero)); > > - crhold(td->td_ucred); > - proc_set_cred(p2, td->td_ucred); > - > /* Tell the prison that we exist. */ > prison_proc_hold(p2->p_ucred->cr_prison); > > @@ -832,7 +829,7 @@ fork1(struct thread *td, int flags, int pages, struct proc **procp, > td2 = thread_alloc(pages); > if (td2 == NULL) { > error = ENOMEM; > - goto fail1; > + goto fail2; > } > proc_linkup(newproc, td2); > } else { > @@ -841,7 +838,7 @@ fork1(struct thread *td, int flags, int pages, struct proc **procp, > vm_thread_dispose(td2); > if (!thread_alloc_stack(td2, pages)) { > error = ENOMEM; > - goto fail1; > + goto fail2; > } > } > } > @@ -850,7 +847,7 @@ fork1(struct thread *td, int flags, int pages, struct proc **procp, > vm2 = vmspace_fork(p1->p_vmspace, &mem_charged); > if (vm2 == NULL) { > error = ENOMEM; > - goto fail1; > + goto fail2; > } > if (!swap_reserve(mem_charged)) { > /* > @@ -861,7 +858,7 @@ fork1(struct thread *td, int flags, int pages, struct proc **procp, > */ > swap_reserve_force(mem_charged); > error = ENOMEM; > - goto fail1; > + goto fail2; > } > } else > vm2 = NULL; > @@ -870,7 +867,7 @@ fork1(struct thread *td, int flags, int pages, struct proc **procp, > * XXX: This is ugly; when we copy resource usage, we need to bump > * per-cred resource counters. > */ > - proc_set_cred(newproc, p1->p_ucred); > + proc_set_cred(newproc, crhold(td->td_ucred)); > > /* > * Initialize resource accounting for the child process. > @@ -946,6 +943,8 @@ fail: > #endif > racct_proc_exit(newproc); > fail1: > + crfree(proc_set_cred(newproc, NULL)); > +fail2: > if (vm2 != NULL) > vmspace_free(vm2); > uma_zfree(proc_zone, newproc); > -- > 2.3.2 From owner-freebsd-current@FreeBSD.ORG Sat Mar 21 01:57:29 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6149D975; Sat, 21 Mar 2015 01:57:29 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450: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 E1972DCB; Sat, 21 Mar 2015 01:57:28 +0000 (UTC) Received: by wibgn9 with SMTP id gn9so3146867wib.1; Fri, 20 Mar 2015 18:57: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-type:content-disposition:in-reply-to :user-agent; bh=f+3VWkTfmbk3x1pUjcigGd9gibZPkNqsWQp8nmMXOuU=; b=JFLVqq12bd7MSMiJeZku4tVo34dYyCONt7/YZHntpOCYkWrNL/TW0SsGi7A2oLl2At zhOQdP2jaZ1fvb5z3pStygbbms7EqXsAY9z9/ZRJPdqPJhwZDGyDS4Ao8CsyW++9XcvZ 14XWZAct6FK5ueJh3Pkew420q9SbGM1iC6YhVJOJTdVhmwibhUAxgC7wip79D2m92ozR n6qYad3iFctEfLl2PWLIkjFVa3c0juuKO8IQavR7r/qB7P35v4rmAi9Dqa7M0QjBgCee 2zHMTEiFQ/TyHGdD0XrP18MGms9ZaWVUeAcFKe7tBL0DcVlgt2xdOWZEJZmZGl3Pm3lD yMmg== X-Received: by 10.194.76.69 with SMTP id i5mr25704844wjw.3.1426903046476; Fri, 20 Mar 2015 18:57:26 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id hl15sm508214wib.3.2015.03.20.18.57.24 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 20 Mar 2015 18:57:25 -0700 (PDT) Date: Sat, 21 Mar 2015 02:57:22 +0100 From: Mateusz Guzik To: Konstantin Belousov Subject: Re: [PATCH 1/3] fork: assign refed credentials earlier Message-ID: <20150321015722.GC27736@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Konstantin Belousov , jenkins-admin@freebsd.org, freebsd-current@freebsd.org, Mateusz Guzik References: <20150320122125.GP2379@kib.kiev.ua> <1426899640-6599-1-git-send-email-mjguzik@gmail.com> <1426899640-6599-2-git-send-email-mjguzik@gmail.com> <20150321015151.GF2379@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150321015151.GF2379@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, jenkins-admin@freebsd.org, Mateusz Guzik X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Mar 2015 01:57:29 -0000 On Sat, Mar 21, 2015 at 03:51:51AM +0200, Konstantin Belousov wrote: > On Sat, Mar 21, 2015 at 02:00:38AM +0100, Mateusz Guzik wrote: > > From: Mateusz Guzik > > > > Prior to this change the kernel would take p1's credentials and assign > > them tempororarily to p2. But p1 could change credentials at that time > > and in effect give us a use-after-free. > In which way could it change the credentials ? The assigned credentials > are taken from td_ucred, which, I thought, are guaranteed to be stable > for the duration of a syscall. > It takes thread's credential in do_fork. But initial copy is taken unlocked from struct proc. Relevant part of the diff: > > @@ -870,7 +867,7 @@ fork1(struct thread *td, int flags, int pages, struct proc **procp, > > * XXX: This is ugly; when we copy resource usage, we need to bump > > * per-cred resource counters. > > */ > > - proc_set_cred(newproc, p1->p_ucred); > > + proc_set_cred(newproc, crhold(td->td_ucred)); > > -- Mateusz Guzik From owner-freebsd-current@FreeBSD.ORG Sat Mar 21 02:14:59 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 43578BF2 for ; Sat, 21 Mar 2015 02:14:59 +0000 (UTC) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::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 03610F3F for ; Sat, 21 Mar 2015 02:14:58 +0000 (UTC) Received: by iedfl3 with SMTP id fl3so3254120ied.1 for ; Fri, 20 Mar 2015 19:14:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0Z5KhY5G7txjyiJT+ZYEI5l8gTI2ZAGIO0S9z9chm1A=; b=Kch85ZXIfaQK3x+G//eS/ikwDQJrRT3XKXDtyPWxXInHPCSJyvjUCw3VxDpsE6Cft9 bjvaIQVXuh8bR6ina3Wd9iZho3CgeLTCF86LK/iR14nmILxIqT1C8ui5LpFNQuI9MbFz 6U1XWffIxi/0wZ8p/NJGzBkbl9JzjpBGiOhR+JmCnh8cpqZA4ZTBOinA9Oy2M3TRBovt no+gZz2k6lunXRjUmt1hBvIW8x9/jvlVqhg0qwcTN1dhOHvBnt6zOHK8sOBSYmTq4G7s w+/vDRn+oUoZ1+WYJKpQz14fidzZvHk3VVs7XLOtSiY50DX9EU7orStli9MUVDaqY0eJ hD6w== X-Received: by 10.50.137.99 with SMTP id qh3mr821323igb.9.1426904098368; Fri, 20 Mar 2015 19:14:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.55.167 with HTTP; Fri, 20 Mar 2015 19:14:38 -0700 (PDT) In-Reply-To: References: <64AF7708-217B-4AC0-A47A-AD1B0BFF7EDC@gmail.com> <885DA4D0-9644-4F06-97C9-04EAD7B4958C@gmail.com> <98CF988A-D9DB-49AD-8CFF-3B438F892730@gmail.com> <2A8C0814-E644-4350-85B8-17B468D79BFF@gmail.com> From: Miguel Clara Date: Sat, 21 Mar 2015 02:14:38 +0000 Message-ID: Subject: Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" To: Kevin Oberman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current , Garrett Cooper X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Mar 2015 02:14:59 -0000 On Fri, Mar 20, 2015 at 7:01 PM, Kevin Oberman wrote: > On Fri, Mar 20, 2015 at 7:47 AM, Miguel Clara > wrote: > >> >> On Thu, Feb 26, 2015 at 2:52 AM, Garrett Cooper >> wrote: >> >>> >>> On Feb 25, 2015, at 18:08, Kevin Oberman wrote: >>> >>> On Wed, Feb 25, 2015 at 2:30 PM, Garrett Cooper >>> wrote: >>> >>>> On Feb 25, 2015, at 14:19, Miguel Clara wrote= : >>>> >>>> ... >>>> >>>> > I noticed this too, but in that case why doesn't it affect all users= ? >>>> (or all the ones using dnscrypt+local_unbound) maybe something changed= in >>>> "NETWORKING" recently? >>>> > >>>> > Hum: >>>> > >>>> https://svnweb.freebsd.org/base/head/etc/rc.d/NETWORKING?r1=3D275299&r= 2=3D278704 >>>> > >>>> > Interesting, as I am using the most recent version which does not >>>> REQUIRE local_unbound >>>> > >>>> > I'm even more confused now :| >>>> > >>>> > >>>> > So it has to come after SERVERS but before local_unbound. But >>>> NETWORKING depends on local_unbound they are both dependent on NEWORKI= NG >>>> which has to be after SERVERS. Can you say fubar! Clearly broken. And = this >>>> means that removing SERVERS will re-shuffle the order more appropriate= ly. >>>> > >>>> > It seems that the behavior of rcorder is not as documented as well a= s >>>> being undefined when circular dependencies occur. The man page says th= at >>>> rcorder aborts when it encounters a circular dependency, but that is n= ot >>>> the case. It probably is best that it not die, but that leaves things = in an >>>> unknown and inconsistant state, which is also a very bad idea. I guess= when >>>> a circular dependency is encountered, a dichotomy occurs. >>>> >>>> Now you know why I=E2=80=99m so curious about all of this stuff. >>>> >>>> When I was working on ^/projects/building-blocks, I was able to move >>>> most of these pieces around by changing REQUIRE: to BEFORE:, but I not= iced >>>> that it changes the rcorder a bit, so I haven=E2=80=99t been super gun= g ho in >>>> implementing my change. >>>> >>>> I think there are a couple bugs present on >>>> 9-STABLE/10-STABLE/11-CURRENT: >>>> >>>> - Things go awry if named is removed/not installed. >>>> - Things go awry if local_unbound is removed (which would have been th= e >>>> case if the rc.d script was removed from your system, which existed be= fore >>>> my changes). >>>> - Other rc.d scripts not being present might break assumptions. >>>> >>>> I need to create dummy providers for certain logical stages (DNS is on= e >>>> of them) to solve part of this problem and provide third parties with = a >>>> mechanism that can be depended on (I wish applications were written in= a >>>> more robust manner to fail gracefully and retry instead of failing fla= t on >>>> their face, but as I=E2=80=99ve seen at several jobs, getting develope= rs to fail, >>>> then retry is hard :(=E2=80=A6). >>>> >>>> Another short-term hack: >>>> >>>> Install dummy/no-op providers so the ordering is preserved, then remov= e >>>> the hacks after all of the bugs have been shaken out. >>>> >>>> Thanks! >>>> >>> >>> Garret, >>> >>> Also undocumented (except in rcorder.c) is that the lack of a provider >>> is not an error. This effectively makes a list of providers into an OR.= So, >>> for name service the normal list is "named local_unbound unbound" and a= ny >>> will work for ordering and having none is a no-op, so if you don't run = any >>> nameserver (or kerberos or whatever provider), it is not an issue. As l= ong >>> as rcorder finds a provider, it will be used to set the order, but the = lack >>> of any or all providers just means that the specified provider is ignor= ed >>> and if a REQUIRES or BEFORE lists no existing providers, the statement = is >>> simply ignored. >>> >>> The real problem is that there is no defined rule for behavior in the >>> event of a circular dependency and any change to any decision point in = the >>> ordering process may change the way the ordering flips. That is why the= se >>> things are such a royal pain to debug. A change in any rc.d script may >>> cause the ordering of seemingly unrelated scripts to change, perhaps >>> drastically, and the error messages, while not misleading, is only a >>> starting point in tracking this down. This means there may be time bomb= s >>> that break working ports without their being touched or even re-install= ed. >>> And the triggering change my, itself be correct. >>> >>> >>> Or etc/rc.d/named... >>> >>> PROVIDES: DNS >>> >>> I'm going to post a fix up for this on arch@/rc@ because it needs to be >>> solved in a saner way -- especially for systems that are pedantic about >>> rcorder, like our version at $work. >>> >>> >> I re-sync my source and noticed the change while doing the mergemaster >> part... with this I can now change dnscrypt to: >> >> @@ -4,7 +4,7 @@ >> # >> # PROVIDE: dnscrypt_proxy >> # REQUIRE: SERVERS cleanvar >> -# BEFORE: named local_unbound unbound >> +# BEFORE: DNS >> >> And this makes the rcorder ok for dnscrypt-proxy >> > > This is still broken and only works by random luck. At this time there > appears to be nothing providing DNS. At least the default > /etc/rc.d/local_unbound does not.nor does anything else in /etc/rc.d. It > looks like this change effectively removes all BEFORE constraints, so it > may start any time after SERVERS and cleanvar. But, it if really expects = to > start before name service comes up, it's not going to happen as those sta= rt > before SERVERS. The effect is probably only that any DNS queries made pri= or > to it starting are not encrypted. > > Since name service must start before SERVERS, I see no way to really > prevent this, but I think the port should be corrected and a message adde= d > to warn that queries made while servers are starting may not be encrypted= . > > "rcorder /etc/rc.d/* /usr/src/etc/rc.d/* > /dev/null" should report the > lack of a provider for DNS. > You're right about the order issue, still a lot to fix and indeed local_unbound doens't include the change so it seems that it works for me because I'm removing the need for local_unbound unbound or named, and one of those was probably introducing the issues. But I don't understand why this would affect encryption, unless local_unbound/unbound is not configured properly, if dnscrypt is stoped local_unbound can't forward the queries and so it won't work... In my case local_unbound would forward to 127.0.0.2 por 53... since that's not listening it will simply fail... so you don't really loose encryption it just fails... when dnscrypt start the queries start being forward and local_unbound does its job! This assumes ofc that the nameserver in resolv.conf is set to 127.0.0.1 *only* (local_unbound/unbound). The ultimate proof is that I never have internet when dnscrypt fails to start cause I don't really have dns, no matter if local_unbound is running or not, but again this is my case with my config. Back to the main issue... yes this is a mess and its something that I feel should really be fixed. -- > Kevin Oberman, Network Engineer, Retired > From owner-freebsd-current@FreeBSD.ORG Sat Mar 21 04:22:42 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 82961696; Sat, 21 Mar 2015 04:22:42 +0000 (UTC) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::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 432E3F43; Sat, 21 Mar 2015 04:22:42 +0000 (UTC) Received: by igcqo1 with SMTP id qo1so3694825igc.0; Fri, 20 Mar 2015 21:22:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3pXKkt6wz++WWQcEmMccc1Z3/56a2qyFNLtHHsJ/gcw=; b=G4A0BAagFnrLwta7Ac/tRUXfOPnCurJ0Lsb8Ee3ZzV+glVw0aSPPRJ8X/1QoIIe0bd t+gNpCQNp27vxQCBQppCOAiDVymbpYQHTuCojGXG/vFCp3RnGOg9pTLW60/OYnsrWw+h whLKVsKQV7EyjHsSbRmeQYx2auAUVkXKa4WFCEp8VRM3zdEehsTYTfBNVGvZbb2Zj5sO sbri90zu142nu3jzV4B7Aabk96Y6PzLi5lk8QDtrUJ1An00pZF4nAWfjuS+hMDifrlk6 0rBo3sj7npHCN01c5UOxdYoMClBxuPYk98cf6b59q108sVVXnB4++fqUbqSGFUT5zgZX CGAA== MIME-Version: 1.0 X-Received: by 10.50.66.198 with SMTP id h6mr1191412igt.35.1426911761734; Fri, 20 Mar 2015 21:22:41 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.107.174.86 with HTTP; Fri, 20 Mar 2015 21:22:41 -0700 (PDT) In-Reply-To: References: <550C505F.2030809@icloud.com> <550C9CEF.4040302@icloud.com> Date: Fri, 20 Mar 2015 21:22:41 -0700 X-Google-Sender-Auth: KOPloz3ga20LYRyJxQNxVcnetc0 Message-ID: Subject: Re: Atheros AR9460 and Acer Aspire V17 Nitro on FreeBSD 11 not working From: Kevin Oberman To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Anders Bolt-Evensen , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Mar 2015 04:22:42 -0000 On Fri, Mar 20, 2015 at 4:31 PM, Adrian Chadd wrote: > Hm, ok. either interrupts aren't working, or the thing is deaf. :( > > can you do that and then in another screen run vmstat -ia | grep ath0 ? > > I'd like to see if it's at least posting interrupts. > Could a bad antenna connection (loose plug/broken conductor/pinch to chassis shorting to ground) explain this? Or would the hardware notice and report this in all cases? -- Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Sat Mar 21 02:27:54 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 26C30D85; Sat, 21 Mar 2015 02:27:54 +0000 (UTC) Received: from st11p02mm-asmtp001.mac.com (st11p02mm-asmtpout001.mac.com [17.172.220.236]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ECCD586; Sat, 21 Mar 2015 02:27:53 +0000 (UTC) Received: from [10.10.10.33] (i207189.ppp.asahi-net.or.jp [61.125.207.189]) by st11p02mm-asmtp001.mac.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NLJ00B96ITEKV50@st11p02mm-asmtp001.mac.com>; Sat, 21 Mar 2015 02:27:47 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-03-20_08:2015-03-20,2015-03-20,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1503210023 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: Atheros AR9460 and Acer Aspire V17 Nitro on FreeBSD 11 not working From: Rui Paulo In-reply-to: Date: Sat, 21 Mar 2015 11:27:14 +0900 Content-transfer-encoding: quoted-printable Message-id: <043EB354-5925-4A24-BA62-3730DA67A44C@me.com> References: <550C505F.2030809@icloud.com> <550C9CEF.4040302@icloud.com> To: Adrian Chadd X-Mailer: Apple Mail (2.2070.6) X-Mailman-Approved-At: Sat, 21 Mar 2015 04:51:38 +0000 Cc: Anders Bolt-Evensen , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Mar 2015 02:27:54 -0000 It's worth noting that some laptops have special keys to enable/disable = WiFi and sometimes that just kills the radio. Do you have that function = key and does toggling it have any effect? -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Sat Mar 21 04:59:35 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 944AEC7D for ; Sat, 21 Mar 2015 04:59:35 +0000 (UTC) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001: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 42FF223F for ; Sat, 21 Mar 2015 04:59:35 +0000 (UTC) Received: by igbud6 with SMTP id ud6so4319198igb.1 for ; Fri, 20 Mar 2015 21:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=6KABM2ZU01H40Lf6bnSHtiCJcB9I3EYHI1Cox7sfa0U=; b=Vd21foxIsOUIRhlJVHpwLxf7UEJFSpdnUvtVFPrCEomultnl042huNzpoId6SYMX20 8YmGoBgDpfX1aPnnG0Ad+T2vOEhoAodRCDackXS3UwqcG9/GX23FFEZODY0y3l3Rn7Mh OTXYziHOC5qqnU0oA6Zwr2mk49cdru0w3ay/qRpa8SOqxuUOsu96NziBeobIXd48siIv m2g5PzfyZQrZlyoTw1lgbFHlKcREa/8inE0BIG4v/COAzsXAxKjrIKfRhIwAKUGitISJ 3RlgC3vsjvo2r7noZnp7+GLoQb3fsHWyMgSPCsYtdLDJiq6/ygTDtbP189V0dkiVB8EO 5nOQ== MIME-Version: 1.0 X-Received: by 10.43.157.67 with SMTP id lp3mr8502467icc.23.1426913974614; Fri, 20 Mar 2015 21:59:34 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.107.174.86 with HTTP; Fri, 20 Mar 2015 21:59:34 -0700 (PDT) In-Reply-To: References: <64AF7708-217B-4AC0-A47A-AD1B0BFF7EDC@gmail.com> <885DA4D0-9644-4F06-97C9-04EAD7B4958C@gmail.com> <98CF988A-D9DB-49AD-8CFF-3B438F892730@gmail.com> <2A8C0814-E644-4350-85B8-17B468D79BFF@gmail.com> Date: Fri, 20 Mar 2015 21:59:34 -0700 X-Google-Sender-Auth: SkS-0phhwO1TY9skBikokSitQxE Message-ID: Subject: Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" From: Kevin Oberman To: Miguel Clara Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current , Garrett Cooper X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Mar 2015 04:59:35 -0000 On Fri, Mar 20, 2015 at 7:14 PM, Miguel Clara wrote: > > On Fri, Mar 20, 2015 at 7:01 PM, Kevin Oberman > wrote: > >> On Fri, Mar 20, 2015 at 7:47 AM, Miguel Clara >> wrote: >> >>> >>> On Thu, Feb 26, 2015 at 2:52 AM, Garrett Cooper >>> wrote: >>> >>>> >>>> On Feb 25, 2015, at 18:08, Kevin Oberman wrote: >>>> >>>> On Wed, Feb 25, 2015 at 2:30 PM, Garrett Cooper >>>> wrote: >>>> >>>>> On Feb 25, 2015, at 14:19, Miguel Clara >>>>> wrote: >>>>> >>>>> ... >>>>> >>>>> > I noticed this too, but in that case why doesn't it affect all >>>>> users? (or all the ones using dnscrypt+local_unbound) maybe something >>>>> changed in "NETWORKING" recently? >>>>> > >>>>> > Hum: >>>>> > >>>>> https://svnweb.freebsd.org/base/head/etc/rc.d/NETWORKING?r1=3D275299&= r2=3D278704 >>>>> > >>>>> > Interesting, as I am using the most recent version which does not >>>>> REQUIRE local_unbound >>>>> > >>>>> > I'm even more confused now :| >>>>> > >>>>> > >>>>> > So it has to come after SERVERS but before local_unbound. But >>>>> NETWORKING depends on local_unbound they are both dependent on NEWORK= ING >>>>> which has to be after SERVERS. Can you say fubar! Clearly broken. And= this >>>>> means that removing SERVERS will re-shuffle the order more appropriat= ely. >>>>> > >>>>> > It seems that the behavior of rcorder is not as documented as well >>>>> as being undefined when circular dependencies occur. The man page say= s that >>>>> rcorder aborts when it encounters a circular dependency, but that is = not >>>>> the case. It probably is best that it not die, but that leaves things= in an >>>>> unknown and inconsistant state, which is also a very bad idea. I gues= s when >>>>> a circular dependency is encountered, a dichotomy occurs. >>>>> >>>>> Now you know why I=E2=80=99m so curious about all of this stuff. >>>>> >>>>> When I was working on ^/projects/building-blocks, I was able to move >>>>> most of these pieces around by changing REQUIRE: to BEFORE:, but I no= ticed >>>>> that it changes the rcorder a bit, so I haven=E2=80=99t been super gu= ng ho in >>>>> implementing my change. >>>>> >>>>> I think there are a couple bugs present on >>>>> 9-STABLE/10-STABLE/11-CURRENT: >>>>> >>>>> - Things go awry if named is removed/not installed. >>>>> - Things go awry if local_unbound is removed (which would have been >>>>> the case if the rc.d script was removed from your system, which exist= ed >>>>> before my changes). >>>>> - Other rc.d scripts not being present might break assumptions. >>>>> >>>>> I need to create dummy providers for certain logical stages (DNS is >>>>> one of them) to solve part of this problem and provide third parties = with a >>>>> mechanism that can be depended on (I wish applications were written i= n a >>>>> more robust manner to fail gracefully and retry instead of failing fl= at on >>>>> their face, but as I=E2=80=99ve seen at several jobs, getting develop= ers to fail, >>>>> then retry is hard :(=E2=80=A6). >>>>> >>>>> Another short-term hack: >>>>> >>>>> Install dummy/no-op providers so the ordering is preserved, then >>>>> remove the hacks after all of the bugs have been shaken out. >>>>> >>>>> Thanks! >>>>> >>>> >>>> Garret, >>>> >>>> Also undocumented (except in rcorder.c) is that the lack of a provider >>>> is not an error. This effectively makes a list of providers into an OR= . So, >>>> for name service the normal list is "named local_unbound unbound" and = any >>>> will work for ordering and having none is a no-op, so if you don't run= any >>>> nameserver (or kerberos or whatever provider), it is not an issue. As = long >>>> as rcorder finds a provider, it will be used to set the order, but the= lack >>>> of any or all providers just means that the specified provider is igno= red >>>> and if a REQUIRES or BEFORE lists no existing providers, the statement= is >>>> simply ignored. >>>> >>>> The real problem is that there is no defined rule for behavior in the >>>> event of a circular dependency and any change to any decision point in= the >>>> ordering process may change the way the ordering flips. That is why th= ese >>>> things are such a royal pain to debug. A change in any rc.d script may >>>> cause the ordering of seemingly unrelated scripts to change, perhaps >>>> drastically, and the error messages, while not misleading, is only a >>>> starting point in tracking this down. This means there may be time bom= bs >>>> that break working ports without their being touched or even re-instal= led. >>>> And the triggering change my, itself be correct. >>>> >>>> >>>> Or etc/rc.d/named... >>>> >>>> PROVIDES: DNS >>>> >>>> I'm going to post a fix up for this on arch@/rc@ because it needs to >>>> be solved in a saner way -- especially for systems that are pedantic a= bout >>>> rcorder, like our version at $work. >>>> >>>> >>> I re-sync my source and noticed the change while doing the mergemaster >>> part... with this I can now change dnscrypt to: >>> >>> @@ -4,7 +4,7 @@ >>> # >>> # PROVIDE: dnscrypt_proxy >>> # REQUIRE: SERVERS cleanvar >>> -# BEFORE: named local_unbound unbound >>> +# BEFORE: DNS >>> >>> And this makes the rcorder ok for dnscrypt-proxy >>> >> >> This is still broken and only works by random luck. At this time there >> appears to be nothing providing DNS. At least the default >> /etc/rc.d/local_unbound does not.nor does anything else in /etc/rc.d. It >> looks like this change effectively removes all BEFORE constraints, so it >> may start any time after SERVERS and cleanvar. But, it if really expects= to >> start before name service comes up, it's not going to happen as those st= art >> before SERVERS. The effect is probably only that any DNS queries made pr= ior >> to it starting are not encrypted. >> >> Since name service must start before SERVERS, I see no way to really >> prevent this, but I think the port should be corrected and a message add= ed >> to warn that queries made while servers are starting may not be encrypte= d. >> >> "rcorder /etc/rc.d/* /usr/src/etc/rc.d/* > /dev/null" should report the >> lack of a provider for DNS. >> > > You're right about the order issue, still a lot to fix and indeed > local_unbound doens't include the change so it seems that it works for me > because I'm removing the need for local_unbound unbound or named, and one > of those was probably introducing the issues. > > But I don't understand why this would affect encryption, unless > local_unbound/unbound is not configured properly, if dnscrypt is stoped > local_unbound can't forward the queries and so it won't work... > In my case local_unbound would forward to 127.0.0.2 port 53... since that's > not listening it will simply fail... so you don't really loose encryption > it just fails... when dnscrypt start the queries start being forward and > local_unbound does its job! > This assumes ofc that the nameserver in resolv.conf is set to 127.0.0.1 > *only* (local_unbound/unbound). > Sorry. I don't use dnscrypt_proxy and misunderstood how it works. You are right. -- Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Sat Mar 21 07:41:00 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 64A78485 for ; Sat, 21 Mar 2015 07:41:00 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 427D41A2 for ; Sat, 21 Mar 2015 07:41:00 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 5098A3C4 for ; Sat, 21 Mar 2015 07:40:59 +0000 (UTC) Date: Sat, 21 Mar 2015 07:40:54 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <757942770.6.1426923655363.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1397906661.5.1426896624987.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1397906661.5.1426896624987.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD-tests2 #859 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Mar 2015 07:41:00 -0000 See ------------------------------------------ [...truncated 2595 lines...] lib/libc/string/strspn:strspn -> passed [0.149s] lib/libc/string/swab:swab_basic -> passed [0.209s] lib/libc/sys/access_test:access_access -> passed [0.482s] lib/libc/sys/access_test:access_fault -> passed [0.170s] lib/libc/sys/access_test:access_inval -> passed [0.187s] lib/libc/sys/access_test:access_notdir -> passed [0.947s] lib/libc/sys/access_test:access_notexist -> passed [0.146s] lib/libc/sys/access_test:access_toolong -> passed [0.242s] lib/libc/sys/chroot_test:chroot_basic -> passed [0.584s] lib/libc/sys/chroot_test:chroot_err -> passed [0.163s] lib/libc/sys/chroot_test:chroot_perm -> passed [0.198s] lib/libc/sys/clock_gettime_test:clock_gettime_real -> passed [0.236s] lib/libc/sys/connect_test:connect_low_port -> passed [0.231s] lib/libc/sys/dup_test:dup2_basic -> passed [0.294s] lib/libc/sys/dup_test:dup2_err -> passed [0.175s] lib/libc/sys/dup_test:dup2_max -> passed [0.177s] lib/libc/sys/dup_test:dup2_mode -> passed [0.349s] lib/libc/sys/dup_test:dup3_err -> passed [0.171s] lib/libc/sys/dup_test:dup3_max -> passed [0.138s] lib/libc/sys/dup_test:dup3_mode -> passed [0.965s] lib/libc/sys/dup_test:dup_err -> passed [0.476s] lib/libc/sys/dup_test:dup_max -> passed [0.245s] lib/libc/sys/dup_test:dup_mode -> passed [0.346s] lib/libc/sys/fsync_test:fsync_err -> passed [0.678s] lib/libc/sys/fsync_test:fsync_sync -> passed [0.985s] lib/libc/sys/getcontext_test:getcontext_err -> passed [0.164s] lib/libc/sys/getcontext_test:setcontext_err -> passed [0.145s] lib/libc/sys/getcontext_test:setcontext_link -> passed [0.175s] lib/libc/sys/getgroups_test:getgroups_err -> expected_failure: Reported as kern/189941: /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/sys/t_getgroups.c:63: getgroups(-1, gidset) == -1 not met [0.312s] lib/libc/sys/getgroups_test:getgroups_getgid -> passed [0.300s] lib/libc/sys/getgroups_test:getgroups_setgid -> passed [0.205s] lib/libc/sys/getgroups_test:getgroups_zero -> passed [0.150s] lib/libc/sys/getitimer_test:getitimer_empty -> passed [0.642s] lib/libc/sys/getitimer_test:getitimer_err -> passed [0.331s] lib/libc/sys/getitimer_test:setitimer_basic -> passed [0.235s] lib/libc/sys/getitimer_test:setitimer_err -> passed [0.253s] lib/libc/sys/getitimer_test:setitimer_old -> passed [0.234s] lib/libc/sys/getlogin_test:getlogin_r_err -> passed [0.113s] lib/libc/sys/getlogin_test:getlogin_same -> passed [0.141s] lib/libc/sys/getlogin_test:setlogin_basic -> passed [0.187s] lib/libc/sys/getlogin_test:setlogin_err -> passed [0.099s] lib/libc/sys/getlogin_test:setlogin_perm -> passed [0.106s] lib/libc/sys/getpid_test:getpid_process -> passed [0.078s] lib/libc/sys/getpid_test:getpid_thread -> passed [0.076s] lib/libc/sys/getrusage_test:getrusage_err -> passed [0.255s] lib/libc/sys/getrusage_test:getrusage_sig -> passed [0.134s] lib/libc/sys/getrusage_test:getrusage_utime_back -> passed [2.538s] lib/libc/sys/getrusage_test:getrusage_utime_zero -> skipped: this testcase passes/fails sporadically on FreeBSD/i386 @ r273153 (at least) [0.146s] lib/libc/sys/getsid_test:getsid_current -> passed [0.241s] lib/libc/sys/getsid_test:getsid_err -> passed [0.345s] lib/libc/sys/getsid_test:getsid_process -> passed [0.216s] lib/libc/sys/gettimeofday_test:gettimeofday_err -> passed [0.178s] lib/libc/sys/gettimeofday_test:gettimeofday_mono -> passed [0.212s] lib/libc/sys/issetugid_test:issetugid_egid -> passed [0.139s] lib/libc/sys/issetugid_test:issetugid_euid -> passed [0.157s] lib/libc/sys/issetugid_test:issetugid_rgid -> passed [0.168s] lib/libc/sys/issetugid_test:issetugid_ruid -> passed [0.110s] lib/libc/sys/kevent_test:kevent_zerotimer -> passed [0.112s] lib/libc/sys/kevent_test:kqueue_desc_passing -> passed [0.193s] lib/libc/sys/kevent_test:kqueue_unsupported_fd -> skipped: no /nonexistent available for testing [0.134s] lib/libc/sys/kill_test:kill_basic -> passed [0.177s] lib/libc/sys/kill_test:kill_err -> passed [0.220s] lib/libc/sys/kill_test:kill_perm -> passed [1.467s] lib/libc/sys/kill_test:kill_pgrp_neg -> passed [0.453s] lib/libc/sys/kill_test:kill_pgrp_zero -> passed [0.203s] lib/libc/sys/link_test:link_count -> passed [0.485s] lib/libc/sys/link_test:link_err -> passed [0.226s] lib/libc/sys/link_test:link_perm -> passed [0.141s] lib/libc/sys/link_test:link_stat -> passed [0.262s] lib/libc/sys/listen_test:listen_err -> passed [0.108s] lib/libc/sys/listen_test:listen_low_port -> passed [0.143s] lib/libc/sys/mincore_test:mincore_err -> passed [0.086s] lib/libc/sys/mincore_test:mincore_resid -> passed [0.143s] lib/libc/sys/mincore_test:mincore_shmseg -> passed [0.136s] lib/libc/sys/mkdir_test:mkdir_err -> passed [0.169s] lib/libc/sys/mkdir_test:mkdir_mode -> passed [1.264s] lib/libc/sys/mkdir_test:mkdir_perm -> passed [0.127s] lib/libc/sys/mkdir_test:mkdir_trail -> passed [0.389s] lib/libc/sys/mkfifo_test:mkfifo_block -> passed [1.319s] lib/libc/sys/mkfifo_test:mkfifo_err -> passed [0.222s] lib/libc/sys/mkfifo_test:mkfifo_nonblock -> passed [1.326s] lib/libc/sys/mkfifo_test:mkfifo_perm -> passed [0.126s] lib/libc/sys/mkfifo_test:mkfifo_stat -> passed [0.102s] lib/libc/sys/mknod_test:mknod_err -> passed [0.130s] lib/libc/sys/mknod_test:mknod_exist -> passed [0.110s] lib/libc/sys/mknod_test:mknod_perm -> passed [0.128s] lib/libc/sys/mknod_test:mknod_stat -> expected_failure: mknod does not allow S_IFREG: /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/sys/t_mknod.c:179: mknod(path, S_IFREG, 0) == 0 not met [0.130s] lib/libc/sys/mlock_test:mlock_clip -> passed [0.145s] lib/libc/sys/mlock_test:mlock_err -> passed [0.166s] lib/libc/sys/mlock_test:mlock_limits -> passed [0.160s] lib/libc/sys/mlock_test:mlock_mmap -> passed [0.425s] lib/libc/sys/mlock_test:mlock_nested -> passed [0.414s] lib/libc/sys/mmap_test:mmap_err -> passed [0.595s] lib/libc/sys/mmap_test:mmap_loan -> passed [0.405s] lib/libc/sys/mmap_test:mmap_prot_1 -> passed [0.322s] lib/libc/sys/mmap_test:mmap_prot_2 -> passed [0.690s] lib/libc/sys/mmap_test:mmap_prot_3 -> passed [0.195s] lib/libc/sys/mmap_test:mmap_truncate -> passed [0.650s] lib/libc/sys/mmap_test:mmap_va0 -> passed [0.161s] lib/libc/sys/mprotect_test:mprotect_access -> passed [0.159s] lib/libc/sys/mprotect_test:mprotect_err -> passed [0.188s] lib/libc/sys/mprotect_test:mprotect_pax -> passed [0.152s] lib/libc/sys/mprotect_test:mprotect_write -> passed [0.118s] lib/libc/sys/msgctl_test:msgctl_err -> passed [0.149s] lib/libc/sys/msgctl_test:msgctl_perm -> passed [0.194s] lib/libc/sys/msgctl_test:msgctl_pid -> passed [2.199s] lib/libc/sys/msgctl_test:msgctl_set -> passed [0.138s] lib/libc/sys/msgctl_test:msgctl_time -> passed [0.198s] lib/libc/sys/msgget_test:msgget_excl -> passed [0.110s] lib/libc/sys/msgget_test:msgget_exit -> passed [0.146s] lib/libc/sys/msgget_test:msgget_init -> passed [0.141s] lib/libc/sys/msgget_test:msgget_limit -> passed [0.073s] lib/libc/sys/msgget_test:msgget_mode -> passed [0.101s] lib/libc/sys/msgrcv_test:msgrcv_basic -> passed [0.081s] lib/libc/sys/msgrcv_test:msgrcv_block -> passed [2.392s] lib/libc/sys/msgrcv_test:msgrcv_err -> passed [0.410s] lib/libc/sys/msgrcv_test:msgrcv_mtype -> passed [0.090s] lib/libc/sys/msgrcv_test:msgrcv_nonblock -> passed [2.250s] lib/libc/sys/msgrcv_test:msgrcv_truncate -> passed [0.311s] lib/libc/sys/msgsnd_test:msgsnd_block -> passed [2.460s] lib/libc/sys/msgsnd_test:msgsnd_count -> passed [0.140s] lib/libc/sys/msgsnd_test:msgsnd_err -> passed [0.248s] lib/libc/sys/msgsnd_test:msgsnd_nonblock -> passed [2.233s] lib/libc/sys/msgsnd_test:msgsnd_perm -> passed [0.090s] lib/libc/sys/msync_test:msync_async -> passed [0.103s] lib/libc/sys/msync_test:msync_err -> passed [0.132s] lib/libc/sys/msync_test:msync_invalidate -> passed [0.083s] lib/libc/sys/msync_test:msync_sync -> passed [0.126s] lib/libc/sys/nanosleep_test:nanosleep_basic -> passed [0.145s] lib/libc/sys/nanosleep_test:nanosleep_err -> passed [0.120s] lib/libc/sys/nanosleep_test:nanosleep_sig -> passed [1.440s] lib/libc/sys/pipe_test:pipe_restart -> passed [2.208s] lib/libc/sys/pipe2_test:pipe2_basic -> passed [0.187s] lib/libc/sys/pipe2_test:pipe2_cloexec -> passed [0.201s] lib/libc/sys/pipe2_test:pipe2_consume -> passed [0.158s] lib/libc/sys/pipe2_test:pipe2_einval -> passed [0.187s] lib/libc/sys/pipe2_test:pipe2_nonblock -> passed [0.220s] lib/libc/sys/poll_test:poll_3way -> passed [10.415s] lib/libc/sys/poll_test:poll_basic -> passed [0.163s] lib/libc/sys/poll_test:poll_err -> passed [0.136s] lib/libc/sys/revoke_test:revoke_basic -> skipped: revoke(2) is only implemented for devfs(5). [0.688s] lib/libc/sys/revoke_test:revoke_err -> skipped: revoke(2) is only implemented for devfs(5). [0.250s] lib/libc/sys/revoke_test:revoke_perm -> skipped: revoke(2) is only implemented for devfs(5). [0.249s] lib/libc/sys/select_test:pselect_sigmask -> passed [1.303s] lib/libc/sys/select_test:pselect_timeout -> passed [0.308s] lib/libc/sys/setrlimit_test:setrlimit_basic -> passed [0.187s] lib/libc/sys/setrlimit_test:setrlimit_current -> passed [0.121s] lib/libc/sys/setrlimit_test:setrlimit_err -> passed [0.177s] lib/libc/sys/setrlimit_test:setrlimit_fsize -> passed [0.177s] lib/libc/sys/setrlimit_test:setrlimit_memlock -> passed [0.153s] lib/libc/sys/setrlimit_test:setrlimit_nofile_1 -> passed [0.161s] lib/libc/sys/setrlimit_test:setrlimit_nofile_2 -> passed [0.154s] lib/libc/sys/setrlimit_test:setrlimit_nproc -> maxproc limit exceeded by uid 977 (pid 21299); see tuning(7) and login.conf(5) passed [0.741s] lib/libc/sys/setrlimit_test:setrlimit_perm -> panic: mutex process lock not owned at /builds/FreeBSD_HEAD/sys/kern/kern_prot.c:1974 cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe009742c8e0 vpanic() at vpanic+0x189/frame 0xfffffe009742c960 panic() at panic+0x43/frame 0xfffffe009742c9c0 __mtx_assert() at __mtx_assert+0xc2/frame 0xfffffe009742c9d0 proc_set_cred() at proc_set_cred+0x36/frame 0xfffffe009742c9f0 fork1() at fork1+0x27e/frame 0xfffffe009742cac0 sys_fork() at sys_fork+0x1f/frame 0xfffffe009742cae0 amd64_syscall() at amd64_syscall+0x27f/frame 0xfffffe009742cbf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe009742cbf0 --- syscall (0, FreeBSD ELF64, nosys), rip = 0x8019c516a, rsp = 0x7fffffffc2d8, rbp = 0x7fffffffc340 --- KDB: enter: panic [ thread pid 660 tid 100043 ] Stopped at kdb_enter+0x3e: movq $0,kdb_why db> Traceback (most recent call last): File "/vm/freebsd-ci/scripts/test/run-tests.py", line 152, in main(sys.argv) File "/vm/freebsd-ci/scripts/test/run-tests.py", line 80, in main runTest() File "/vm/freebsd-ci/scripts/test/run-tests.py", line 124, in runTest child2.expect(prompt, timeout=7200) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1451, in expect timeout, searchwindowsize) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1466, in expect_list timeout, searchwindowsize) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1568, in expect_loop raise TIMEOUT(str(err) + '\n' + str(self)) pexpect.TIMEOUT: Timeout exceeded. version: 3.3 command: /usr/sbin/bhyve args: [u'/usr/sbin/bhyve', u'-c', u'2', u'-m', u'2G', u'-AI', u'-H', u'-P', u'-g', u'0', u'-s', u'0:0,hostbridge', u'-s', u'1:0,lpc', u'-s', u'2:0,virtio-net,tap0,mac=58:9c:fc:00:00:2e', u'-s', u'3:0,ahci-hd,/net/jenkins-10.freebsd.org/builds/Build-UFS-image/image/FreeBSD_HEAD/test.img', u'-l', u'com1,stdio', u'vm_test'] searcher: buffer (last 100 chars): 'nter: panic\r\n[ thread pid 660 tid 100043 ]\r\nStopped at kdb_enter+0x3e: movq $0,kdb_why\r\ndb> ' before (last 100 chars): 'nter: panic\r\n[ thread pid 660 tid 100043 ]\r\nStopped at kdb_enter+0x3e: movq $0,kdb_why\r\ndb> ' after: match: None match_index: None exitstatus: None flag_eof: False pid: 38323 child_fd: 4 closed: False timeout: 30 delimiter: logfile: ', mode 'w' at 0x800670150> logfile_read: None logfile_send: None maxread: 2000 ignorecase: False searchwindowsize: None delaybeforesend: 0.05 delayafterclose: 0.1 delayafterterminate: 0.1 Build step 'Execute shell' marked build as failure Recording test results ERROR: Publisher hudson.tasks.junit.JUnitResultArchiver aborted due to exception hudson.AbortException: Test reports were found but none of them are new. Did tests run? For example, is 6 days 6 hr old at hudson.tasks.junit.TestResult.parse(TestResult.java:178) at hudson.tasks.junit.TestResult.parse(TestResult.java:146) at hudson.tasks.junit.TestResult.(TestResult.java:122) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:119) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:92) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2688) at hudson.remoting.UserRequest.perform(UserRequest.java:121) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at hudson.remoting.Request$2.run(Request.java:324) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) at ......remote call to havoc.ysv.freebsd.org(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1356) at hudson.remoting.UserResponse.retrieve(UserRequest.java:221) at hudson.remoting.Channel.call(Channel.java:752) at hudson.FilePath.act(FilePath.java:978) at hudson.FilePath.act(FilePath.java:967) at hudson.tasks.junit.JUnitParser.parseResult(JUnitParser.java:89) at hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:120) at hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:137) at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:74) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:761) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:721) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:670) at hudson.model.Run.execute(Run.java:1775) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240) From owner-freebsd-current@FreeBSD.ORG Sat Mar 21 08:17:59 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E995674B for ; Sat, 21 Mar 2015 08:17:59 +0000 (UTC) Received: from st11p00mm-asmtp001.mac.com (st11p00mm-asmtpout001.mac.com [17.172.81.0]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B88306E7 for ; Sat, 21 Mar 2015 08:17:59 +0000 (UTC) Received: from [10.0.0.132] (ti0025a400-4054.bb.online.no [85.167.26.227]) by st11p00mm-asmtp001.mac.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NLJ00MPUZ1VWU00@st11p00mm-asmtp001.mac.com> for freebsd-current@freebsd.org; Sat, 21 Mar 2015 08:17:58 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-03-21_01:2015-03-20,2015-03-21,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1503210089 Message-id: <550D2932.3090101@icloud.com> Date: Sat, 21 Mar 2015 09:17:54 +0100 From: Anders Bolt-Evensen User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-version: 1.0 To: Kevin Oberman , freebsd-current@freebsd.org Subject: Re: Atheros AR9460 and Acer Aspire V17 Nitro on FreeBSD 11 not working References: <550C505F.2030809@icloud.com> <550C9CEF.4040302@icloud.com> 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.18-1 Precedence: 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, 21 Mar 2015 08:18:00 -0000 Do you mean to check dmesg -a while doing "vmstat -ia | grep ath0"? I did run "wlandebug +scan", then ifconfig wlan0 up scan and then "vmstat -ia | grep ath0". The only output I got from "vmstat -ia | grep ath0" is: irq18: ath0 21 0 The second time I ran that last command I got irq18: ath0 22 0 It is worth mentioning that wifi with this Atheros card works just fine on Windows (I am using this wlan when typing this answer on Windows). There is a button that seems to enable airplane mode, but pressing this button does not seem to change anything as far as FreeBSD is concerned. Other than that button I can't find any button that enables or disables wifi. On 3/21/2015 5:22 AM, Kevin Oberman wrote: > On Fri, Mar 20, 2015 at 4:31 PM, Adrian Chadd wrote: > >> Hm, ok. either interrupts aren't working, or the thing is deaf. :( >> >> can you do that and then in another screen run vmstat -ia | grep ath0 ? >> >> I'd like to see if it's at least posting interrupts. >> > Could a bad antenna connection (loose plug/broken conductor/pinch to > chassis shorting to ground) explain this? Or would the hardware notice and > report this in all cases? > -- > Kevin Oberman, Network Engineer, Retired > E-mail: rkoberman@gmail.com > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://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 Mar 21 09:20:43 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B2B4D356; Sat, 21 Mar 2015 09:20:43 +0000 (UTC) Received: from ivan-labs.com (ivan-labs.com [162.243.251.239]) by mx1.freebsd.org (Postfix) with ESMTP id 8887CCFA; Sat, 21 Mar 2015 09:20:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by ivan-labs.com (Postfix) with ESMTP id 794F5121117; Sat, 21 Mar 2015 12:20:42 +0300 (MSK) X-Virus-Scanned: Debian amavisd-new at Received: from ivan-labs.com ([127.0.0.1]) by localhost (ivan-labs.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1DlbEx99VDg; Sat, 21 Mar 2015 12:20:41 +0300 (MSK) Received: from [192.168.1.143] (cable-84-43-203-116.mnet.bg [84.43.203.116]) by ivan-labs.com (Postfix) with ESMTPSA id 35D9712039E; Sat, 21 Mar 2015 12:20:41 +0300 (MSK) Message-ID: <550D37DA.7060105@ivan-labs.com> Date: Sat, 21 Mar 2015 11:20:26 +0200 From: "Ivan A. Kosarev" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Use of chunksize before initialization References: <550C27D8.2010105@ivan-labs.com> <20150321010218.GD2379@kib.kiev.ua> In-Reply-To: <20150321010218.GD2379@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Ed Maste X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Mar 2015 09:20:43 -0000 On 03/21/2015 03:02 AM, Konstantin Belousov wrote: > On Fri, Mar 20, 2015 at 03:59:52PM +0200, Ivan A. Kosarev wrote: >> #12 0x00000008011b428d in malloc_init_hard () at jemalloc_jemalloc.c:698 >> #13 malloc_init () at jemalloc_jemalloc.c:296 >> #14 0x0000000801243ea2 in ?? () from /lib/libc.so.7 >> #15 0x00000008006a5400 in ?? () >> #16 0x000000080089e5b0 in ?? () from /libexec/ld-elf.so.1 >> #17 0x00007fffffffe0b0 in ?? () >> #18 0x0000000801139d06 in _init () from /lib/libc.so.7 >> #19 0x00007fffffffe0b0 in ?? () > The backtrace is strange. Did you compiled malloc with the debugging > symbols, while keep rest of libc without -g ? I've just added the -g flag to CC_FLAGS in the Makefile and made sure to install an unstripped version of the .so . I could investigate more on why the early calls omit debug symbols, if it does any matter. > Does it happen always, on only for the early initialization of the > mutexes ? I'm not sure I understand the whole logic of the initialization process, but we could put a statement initializing the chunksize variable to 0 to the beginning of malloc_init_hard() and see if the assertion (or any other before it) fails. Since my suspicion is that the variable get random values at base_boot(), the presence of the failure depends on random factors. For a simple one-line program calling malloc() it is known to not to fail, of course. I should be able to to more tests on Mon. > It might be related to r276630. Can you test on, say, 10.1 ? The Tsan tests mentioned below that cause mass (alignment != 0) failures are known to work fine on 10.1. > : jemalloc_chunk.c:152: Failed assertion: "alignment != 0" > > Here's more of failures of this kind around: > > http://lab.llvm.org:8011/builders/sanitizer_x86_64-freebsd/builds/4758/steps/make-check-tsan/logs/stdio > > Can you please let me know if the analysis is correct and there's > something to fix about initialization of the variable? > > Backtrace looks valid. Thanks. -- From owner-freebsd-current@FreeBSD.ORG Sat Mar 21 11:52:13 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 78ADA7B3 for ; Sat, 21 Mar 2015 11:52:13 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 58976CD7 for ; Sat, 21 Mar 2015 11:52:13 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 51CC443E for ; Sat, 21 Mar 2015 11:52:13 +0000 (UTC) Date: Sat, 21 Mar 2015 11:52:13 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1209369086.7.1426938733235.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <757942770.6.1426923655363.JavaMail.jenkins@jenkins-9.freebsd.org> References: <757942770.6.1426923655363.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD-tests2 #860 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Mar 2015 11:52:13 -0000 See ------------------------------------------ [...truncated 1289 lines...] lib/libc/string/strspn:strspn -> passed [0.014s] lib/libc/string/swab:swab_basic -> passed [0.015s] lib/libc/sys/access_test:access_access -> passed [0.018s] lib/libc/sys/access_test:access_fault -> passed [0.015s] lib/libc/sys/access_test:access_inval -> passed [0.015s] lib/libc/sys/access_test:access_notdir -> passed [0.013s] lib/libc/sys/access_test:access_notexist -> passed [0.014s] lib/libc/sys/access_test:access_toolong -> passed [0.014s] lib/libc/sys/chroot_test:chroot_basic -> passed [0.017s] lib/libc/sys/chroot_test:chroot_err -> passed [0.014s] lib/libc/sys/chroot_test:chroot_perm -> passed [0.014s] lib/libc/sys/clock_gettime_test:clock_gettime_real -> passed [0.014s] lib/libc/sys/connect_test:connect_low_port -> passed [0.016s] lib/libc/sys/dup_test:dup2_basic -> passed [0.015s] lib/libc/sys/dup_test:dup2_err -> passed [0.015s] lib/libc/sys/dup_test:dup2_max -> passed [0.015s] lib/libc/sys/dup_test:dup2_mode -> passed [0.033s] lib/libc/sys/dup_test:dup3_err -> passed [0.015s] lib/libc/sys/dup_test:dup3_max -> passed [0.015s] lib/libc/sys/dup_test:dup3_mode -> passed [0.028s] lib/libc/sys/dup_test:dup_err -> passed [0.013s] lib/libc/sys/dup_test:dup_max -> passed [0.018s] lib/libc/sys/dup_test:dup_mode -> passed [0.032s] lib/libc/sys/fsync_test:fsync_err -> passed [0.015s] lib/libc/sys/fsync_test:fsync_sync -> passed [0.037s] lib/libc/sys/getcontext_test:getcontext_err -> passed [0.013s] lib/libc/sys/getcontext_test:setcontext_err -> passed [0.014s] lib/libc/sys/getcontext_test:setcontext_link -> passed [0.016s] lib/libc/sys/getgroups_test:getgroups_err -> expected_failure: Reported as kern/189941: /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/sys/t_getgroups.c:63: getgroups(-1, gidset) == -1 not met [0.015s] lib/libc/sys/getgroups_test:getgroups_getgid -> passed [0.015s] lib/libc/sys/getgroups_test:getgroups_setgid -> passed [0.017s] lib/libc/sys/getgroups_test:getgroups_zero -> passed [0.015s] lib/libc/sys/getitimer_test:getitimer_empty -> passed [0.015s] lib/libc/sys/getitimer_test:getitimer_err -> passed [0.014s] lib/libc/sys/getitimer_test:setitimer_basic -> passed [0.015s] lib/libc/sys/getitimer_test:setitimer_err -> passed [0.015s] lib/libc/sys/getitimer_test:setitimer_old -> passed [0.016s] lib/libc/sys/getlogin_test:getlogin_r_err -> passed [0.015s] lib/libc/sys/getlogin_test:getlogin_same -> passed [0.015s] lib/libc/sys/getlogin_test:setlogin_basic -> passed [0.016s] lib/libc/sys/getlogin_test:setlogin_err -> passed [0.016s] lib/libc/sys/getlogin_test:setlogin_perm -> passed [0.016s] lib/libc/sys/getpid_test:getpid_process -> passed [0.023s] lib/libc/sys/getpid_test:getpid_thread -> passed [0.018s] lib/libc/sys/getrusage_test:getrusage_err -> passed [0.016s] lib/libc/sys/getrusage_test:getrusage_sig -> passed [0.014s] lib/libc/sys/getrusage_test:getrusage_utime_back -> passed [2.142s] lib/libc/sys/getrusage_test:getrusage_utime_zero -> skipped: this testcase passes/fails sporadically on FreeBSD/i386 @ r273153 (at least) [0.017s] lib/libc/sys/getsid_test:getsid_current -> passed [0.014s] lib/libc/sys/getsid_test:getsid_err -> passed [0.014s] lib/libc/sys/getsid_test:getsid_process -> passed [0.014s] lib/libc/sys/gettimeofday_test:gettimeofday_err -> passed [0.015s] lib/libc/sys/gettimeofday_test:gettimeofday_mono -> passed [0.016s] lib/libc/sys/issetugid_test:issetugid_egid -> passed [0.017s] lib/libc/sys/issetugid_test:issetugid_euid -> passed [0.018s] lib/libc/sys/issetugid_test:issetugid_rgid -> passed [0.017s] lib/libc/sys/issetugid_test:issetugid_ruid -> passed [0.017s] lib/libc/sys/kevent_test:kevent_zerotimer -> passed [0.015s] lib/libc/sys/kevent_test:kqueue_desc_passing -> passed [0.017s] lib/libc/sys/kevent_test:kqueue_unsupported_fd -> skipped: no /nonexistent available for testing [0.015s] lib/libc/sys/kill_test:kill_basic -> passed [0.017s] lib/libc/sys/kill_test:kill_err -> passed [0.016s] lib/libc/sys/kill_test:kill_perm -> passed [1.048s] lib/libc/sys/kill_test:kill_pgrp_neg -> passed [0.016s] lib/libc/sys/kill_test:kill_pgrp_zero -> passed [0.016s] lib/libc/sys/link_test:link_count -> passed [0.020s] lib/libc/sys/link_test:link_err -> passed [0.020s] lib/libc/sys/link_test:link_perm -> passed [0.014s] lib/libc/sys/link_test:link_stat -> passed [0.019s] lib/libc/sys/listen_test:listen_err -> passed [0.020s] lib/libc/sys/listen_test:listen_low_port -> passed [0.015s] lib/libc/sys/mincore_test:mincore_err -> passed [0.016s] lib/libc/sys/mincore_test:mincore_resid -> passed [0.031s] lib/libc/sys/mincore_test:mincore_shmseg -> passed [0.016s] lib/libc/sys/mkdir_test:mkdir_err -> passed [0.014s] lib/libc/sys/mkdir_test:mkdir_mode -> passed [1.037s] lib/libc/sys/mkdir_test:mkdir_perm -> passed [0.018s] lib/libc/sys/mkdir_test:mkdir_trail -> passed [0.022s] lib/libc/sys/mkfifo_test:mkfifo_block -> passed [1.055s] lib/libc/sys/mkfifo_test:mkfifo_err -> passed [0.019s] lib/libc/sys/mkfifo_test:mkfifo_nonblock -> passed [1.090s] lib/libc/sys/mkfifo_test:mkfifo_perm -> passed [0.019s] lib/libc/sys/mkfifo_test:mkfifo_stat -> passed [0.020s] lib/libc/sys/mknod_test:mknod_err -> passed [0.018s] lib/libc/sys/mknod_test:mknod_exist -> passed [0.019s] lib/libc/sys/mknod_test:mknod_perm -> passed [0.016s] lib/libc/sys/mknod_test:mknod_stat -> expected_failure: mknod does not allow S_IFREG: /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/sys/t_mknod.c:179: mknod(path, S_IFREG, 0) == 0 not met [0.018s] lib/libc/sys/mlock_test:mlock_clip -> passed [0.015s] lib/libc/sys/mlock_test:mlock_err -> passed [0.017s] lib/libc/sys/mlock_test:mlock_limits -> passed [0.017s] lib/libc/sys/mlock_test:mlock_mmap -> passed [0.015s] lib/libc/sys/mlock_test:mlock_nested -> passed [0.015s] lib/libc/sys/mmap_test:mmap_err -> passed [0.014s] lib/libc/sys/mmap_test:mmap_loan -> passed [0.019s] lib/libc/sys/mmap_test:mmap_prot_1 -> passed [0.020s] lib/libc/sys/mmap_test:mmap_prot_2 -> passed [0.015s] lib/libc/sys/mmap_test:mmap_prot_3 -> passed [0.020s] lib/libc/sys/mmap_test:mmap_truncate -> passed [0.025s] lib/libc/sys/mmap_test:mmap_va0 -> passed [0.014s] lib/libc/sys/mprotect_test:mprotect_access -> passed [0.019s] lib/libc/sys/mprotect_test:mprotect_err -> passed [0.015s] lib/libc/sys/mprotect_test:mprotect_pax -> passed [0.014s] lib/libc/sys/mprotect_test:mprotect_write -> passed [0.015s] lib/libc/sys/msgctl_test:msgctl_err -> passed [0.016s] lib/libc/sys/msgctl_test:msgctl_perm -> passed [0.020s] lib/libc/sys/msgctl_test:msgctl_pid -> passed [2.110s] lib/libc/sys/msgctl_test:msgctl_set -> passed [0.018s] lib/libc/sys/msgctl_test:msgctl_time -> passed [0.016s] lib/libc/sys/msgget_test:msgget_excl -> passed [0.018s] lib/libc/sys/msgget_test:msgget_exit -> passed [0.018s] lib/libc/sys/msgget_test:msgget_init -> passed [0.017s] lib/libc/sys/msgget_test:msgget_limit -> passed [0.015s] lib/libc/sys/msgget_test:msgget_mode -> passed [0.017s] lib/libc/sys/msgrcv_test:msgrcv_basic -> passed [0.017s] lib/libc/sys/msgrcv_test:msgrcv_block -> passed [2.155s] lib/libc/sys/msgrcv_test:msgrcv_err -> passed [0.019s] lib/libc/sys/msgrcv_test:msgrcv_mtype -> passed [0.018s] lib/libc/sys/msgrcv_test:msgrcv_nonblock -> passed [2.044s] lib/libc/sys/msgrcv_test:msgrcv_truncate -> passed [0.018s] lib/libc/sys/msgsnd_test:msgsnd_block -> passed [2.027s] lib/libc/sys/msgsnd_test:msgsnd_count -> passed [0.017s] lib/libc/sys/msgsnd_test:msgsnd_err -> passed [0.017s] lib/libc/sys/msgsnd_test:msgsnd_nonblock -> passed [2.103s] lib/libc/sys/msgsnd_test:msgsnd_perm -> passed [0.021s] lib/libc/sys/msync_test:msync_async -> passed [0.019s] lib/libc/sys/msync_test:msync_err -> passed [0.022s] lib/libc/sys/msync_test:msync_invalidate -> passed [0.017s] lib/libc/sys/msync_test:msync_sync -> passed [0.018s] lib/libc/sys/nanosleep_test:nanosleep_basic -> passed [0.015s] lib/libc/sys/nanosleep_test:nanosleep_err -> passed [0.015s] lib/libc/sys/nanosleep_test:nanosleep_sig -> passed [1.082s] lib/libc/sys/pipe_test:pipe_restart -> passed [2.056s] lib/libc/sys/pipe2_test:pipe2_basic -> passed [0.015s] lib/libc/sys/pipe2_test:pipe2_cloexec -> passed [0.016s] lib/libc/sys/pipe2_test:pipe2_consume -> passed [0.014s] lib/libc/sys/pipe2_test:pipe2_einval -> passed [0.014s] lib/libc/sys/pipe2_test:pipe2_nonblock -> passed [0.015s] lib/libc/sys/poll_test:poll_3way -> passed [10.082s] lib/libc/sys/poll_test:poll_basic -> passed [0.021s] lib/libc/sys/poll_test:poll_err -> passed [0.017s] lib/libc/sys/revoke_test:revoke_basic -> skipped: revoke(2) is only implemented for devfs(5). [0.019s] lib/libc/sys/revoke_test:revoke_err -> skipped: revoke(2) is only implemented for devfs(5). [0.016s] lib/libc/sys/revoke_test:revoke_perm -> skipped: revoke(2) is only implemented for devfs(5). [0.017s] lib/libc/sys/select_test:pselect_sigmask -> passed [1.041s] lib/libc/sys/select_test:pselect_timeout -> passed [0.018s] lib/libc/sys/setrlimit_test:setrlimit_basic -> passed [0.016s] lib/libc/sys/setrlimit_test:setrlimit_current -> passed [0.016s] lib/libc/sys/setrlimit_test:setrlimit_err -> passed [0.016s] lib/libc/sys/setrlimit_test:setrlimit_fsize -> passed [0.021s] lib/libc/sys/setrlimit_test:setrlimit_memlock -> passed [0.016s] lib/libc/sys/setrlimit_test:setrlimit_nofile_1 -> passed [0.016s] lib/libc/sys/setrlimit_test:setrlimit_nofile_2 -> passed [0.016s] lib/libc/sys/setrlimit_test:setrlimit_nproc -> maxproc limit exceeded by uid 977 (pid 8443); see tuning(7) and login.conf(5) passed [0.554s] lib/libc/sys/setrlimit_test:setrlimit_perm -> panic: mutex process lock not owned at /builds/FreeBSD_HEAD/sys/kern/kern_prot.c:1974 cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00974ea8e0 vpanic() at vpanic+0x189/frame 0xfffffe00974ea960 panic() at panic+0x43/frame 0xfffffe00974ea9c0 __mtx_assert() at __mtx_assert+0xc2/frame 0xfffffe00974ea9d0 proc_set_cred() at proc_set_cred+0x36/frame 0xfffffe00974ea9f0 fork1() at fork1+0x27e/frame 0xfffffe00974eaac0 sys_fork() at sys_fork+0x1f/frame 0xfffffe00974eaae0 amd64_syscall() at amd64_syscall+0x27f/frame 0xfffffe00974eabf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe00974eabf0 --- syscall (2, FreeBSD ELF64, sys_fork), rip = 0x8008f84da, rsp = 0x7fffffffdd38, rbp = 0x7fffffffddc0 --- KDB: enter: panic [ thread pid 8444 tid 100081 ] Stopped at kdb_enter+0x3e: movq $0,kdb_why db> Traceback (most recent call last): File "/vm/freebsd-ci/scripts/test/run-tests.py", line 152, in main(sys.argv) File "/vm/freebsd-ci/scripts/test/run-tests.py", line 80, in main runTest() File "/vm/freebsd-ci/scripts/test/run-tests.py", line 124, in runTest child2.expect(prompt, timeout=7200) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1451, in expect timeout, searchwindowsize) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1466, in expect_list timeout, searchwindowsize) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1568, in expect_loop raise TIMEOUT(str(err) + '\n' + str(self)) pexpect.TIMEOUT: Timeout exceeded. version: 3.3 command: /usr/sbin/bhyve args: [u'/usr/sbin/bhyve', u'-c', u'2', u'-m', u'2G', u'-AI', u'-H', u'-P', u'-g', u'0', u'-s', u'0:0,hostbridge', u'-s', u'1:0,lpc', u'-s', u'2:0,virtio-net,tap0,mac=58:9c:fc:00:00:2e', u'-s', u'3:0,ahci-hd,/net/jenkins-10.freebsd.org/builds/Build-UFS-image/image/FreeBSD_HEAD/test.img', u'-l', u'com1,stdio', u'vm_test'] searcher: buffer (last 100 chars): 'ter: panic\r\n[ thread pid 8444 tid 100081 ]\r\nStopped at kdb_enter+0x3e: movq $0,kdb_why\r\ndb> ' before (last 100 chars): 'ter: panic\r\n[ thread pid 8444 tid 100081 ]\r\nStopped at kdb_enter+0x3e: movq $0,kdb_why\r\ndb> ' after: match: None match_index: None exitstatus: None flag_eof: False pid: 54154 child_fd: 4 closed: False timeout: 30 delimiter: logfile: ', mode 'w' at 0x800670150> logfile_read: None logfile_send: None maxread: 2000 ignorecase: False searchwindowsize: None delaybeforesend: 0.05 delayafterclose: 0.1 delayafterterminate: 0.1 Build step 'Execute shell' marked build as failure Recording test results ERROR: Publisher hudson.tasks.junit.JUnitResultArchiver aborted due to exception hudson.AbortException: Test reports were found but none of them are new. Did tests run? For example, is 6 days 10 hr old at hudson.tasks.junit.TestResult.parse(TestResult.java:178) at hudson.tasks.junit.TestResult.parse(TestResult.java:146) at hudson.tasks.junit.TestResult.(TestResult.java:122) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:119) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:92) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2688) at hudson.remoting.UserRequest.perform(UserRequest.java:121) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at hudson.remoting.Request$2.run(Request.java:324) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) at ......remote call to havoc.ysv.freebsd.org(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1356) at hudson.remoting.UserResponse.retrieve(UserRequest.java:221) at hudson.remoting.Channel.call(Channel.java:752) at hudson.FilePath.act(FilePath.java:978) at hudson.FilePath.act(FilePath.java:967) at hudson.tasks.junit.JUnitParser.parseResult(JUnitParser.java:89) at hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:120) at hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:137) at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:74) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:761) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:721) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:670) at hudson.model.Run.execute(Run.java:1775) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240) From owner-freebsd-current@FreeBSD.ORG Sat Mar 21 12:27:27 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 33C0E52D; Sat, 21 Mar 2015 12:27:27 +0000 (UTC) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E8DE3FBD; Sat, 21 Mar 2015 12:27:26 +0000 (UTC) Received: by igcqo1 with SMTP id qo1so7775935igc.0; Sat, 21 Mar 2015 05:27:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YPvNAe+nf6GO8dJbx1aoFJU2oUoX3wdchMyiivWdUHA=; b=bZOBXQNiBC8HX+XIdVDqv5CkeLT7dNbMbdXWrSot1NlIoU0fMTJRCSGQhDEMhkNjAb To3/P+E1g0U8eaJBjODRYUC4HvUAtW22G3B0BI46hWiMnJ8dV96bPrce1o5JvSidWf8r QGW1kyX7DCT8iTPr7yh1b6DJnTZ6RLAsgzh3IkH3V6fwso2jfaSF/yQw1nRDT2K7H380 LQ+MO2QpVEy8j5Zgw1h3QGm6BrlOzF7s9J1TTc2iCmjBi2vI3l4ORQU0toQrzP7BujI0 TK9PHQn3Q4j1Icbtyvb/NLSFRe1YWz/Z9yKsBamdGXrzQvzt089xkPMWv3oUp3yTazIf BHtQ== MIME-Version: 1.0 X-Received: by 10.107.34.210 with SMTP id i201mr34136803ioi.1.1426940846285; Sat, 21 Mar 2015 05:27:26 -0700 (PDT) Received: by 10.107.156.75 with HTTP; Sat, 21 Mar 2015 05:27:26 -0700 (PDT) In-Reply-To: <550AD6A3.1020406@FreeBSD.org> References: <2085699.T9kJlc0rkf@ralph.baldwin.cx> <3923303.nkjJO958qy@ralph.baldwin.cx> <550A0B53.9020201@freebsd.org> <550AD6A3.1020406@FreeBSD.org> Date: Sat, 21 Mar 2015 08:27:26 -0400 Message-ID: Subject: Re: What parts of UMA are part of the stable ABI? From: Ryan Stone To: John Baldwin Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Adrian Chadd , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Mar 2015 12:27:27 -0000 I've put the full patch to convert uma_malloc and uma_free to accept a vm_size_t up for review[1]. It ended up being more extensive than expected as a fair number of places do use uma_set_allocf(). I do plan on MFC'ing this patch. This survive a make tinderbox (ignoring some vt-related LINT kernel build failures) I haven't attempted converting the uma ctors, etc over to vm_size_t yet, but I do plan on doing that still. [1] https://reviews.freebsd.org/D2106 From owner-freebsd-current@FreeBSD.ORG Sat Mar 21 12:32:49 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB50E653 for ; Sat, 21 Mar 2015 12:32:49 +0000 (UTC) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8BFDEC1 for ; Sat, 21 Mar 2015 12:32:49 +0000 (UTC) Received: by iecvj10 with SMTP id vj10so7689051iec.0 for ; Sat, 21 Mar 2015 05:32:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TXA7QXdhrjVf/HN14tw0n/iK5d84ZzTcyQTdxVRiaqE=; b=HV2QCt+nqGwLqTkDx2bbvBq0zdpLZWVVKFHMQxJojjXtXcj/4c4f2X1j7yGbCo+xiD el2I3qKSUEofEtVr5opOqNbdlQSglFoi5ba93ga16jK2WIjKme2bBuX0ParEzwf7AQvA 7L0iGey5t6Gk2tACkjHq2vXXneUXcj9sqLejOlMb8u3doGSyIpk0rlhXeSLWC9b0Uze9 f1ynMnakz+AcCzAxK7JV+0rGTvNVmlw7qkQfPq36z77b+1yZk9uatrYuWHVcbad2La/c gJ6TEtdd05KDkyc6yLuZh73X/3Gz9ZeTfvvGEMU1YjmepIV+GefkxcnTEPR71GiJjtAn /6SA== MIME-Version: 1.0 X-Received: by 10.107.8.215 with SMTP id h84mr126355769ioi.89.1426941169002; Sat, 21 Mar 2015 05:32:49 -0700 (PDT) Received: by 10.107.156.75 with HTTP; Sat, 21 Mar 2015 05:32:48 -0700 (PDT) In-Reply-To: References: Date: Sat, 21 Mar 2015 08:32:48 -0400 Message-ID: Subject: Re: What's the official method to test the build now? From: Ryan Stone To: NGie Cooper Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Mar 2015 12:32:49 -0000 I still see the compile errors that I reported here: https://lists.freebsd.org/pipermail/freebsd-current/2015-February/054803.html It affects these builds: sparc64 LINT kernel failed, check _.sparc64.LINT for details powerpc LINT kernel failed, check _.powerpc.LINT for details powerpc LINT64 kernel failed, check _.powerpc.LINT64 for details i386 LINT-NOINET kernel failed, check _.i386.LINT-NOINET for details i386 LINT-NOINET6 kernel failed, check _.i386.LINT-NOINET6 for details i386 LINT kernel failed, check _.i386.LINT for details i386 LINT-NOIP kernel failed, check _.i386.LINT-NOIP for details i386 LINT-VIMAGE kernel failed, check _.i386.LINT-VIMAGE for details From owner-freebsd-current@FreeBSD.ORG Sat Mar 21 13:35:19 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4BDE6EAA for ; Sat, 21 Mar 2015 13:35:19 +0000 (UTC) Received: from relay.mailchannels.net (si-002-i158.relay.mailchannels.net [108.178.49.170]) by mx1.freebsd.org (Postfix) with ESMTP id 87EE8801 for ; Sat, 21 Mar 2015 13:35:17 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp7.ore.mailhop.org (ip-10-213-14-133.us-west-2.compute.internal [10.213.14.133]) by relay.mailchannels.net (Postfix) with ESMTPA id A5588120AE0; Sat, 21 Mar 2015 13:35:09 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp7.ore.mailhop.org (smtp7.ore.mailhop.org [10.83.15.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.8); Sat, 21 Mar 2015 13:35:10 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: duocircle|x-authuser|hippie X-MailChannels-Auth-Id: duocircle X-MC-Loop-Signature: 1426944909805:4281107351 X-MC-Ingress-Time: 1426944909805 Received: from c-73-34-117-227.hsd1.co.comcast.net ([73.34.117.227] helo=ilsoft.org) by smtp7.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YZJYS-0001XX-Nt; Sat, 21 Mar 2015 13:35:08 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t2LDZ57G034909; Sat, 21 Mar 2015 07:35:05 -0600 (MDT) (envelope-from ian@freebsd.org) X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX181XWNHyrxPAdQAvmq2akNU Message-ID: <1426944905.20654.5.camel@freebsd.org> Subject: Re: What's the official method to test the build now? From: Ian Lepore To: Ryan Stone Date: Sat, 21 Mar 2015 07:35:05 -0600 In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-AuthUser: hippie Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Mar 2015 13:35:19 -0000 On Fri, 2015-03-20 at 19:52 -0400, Ryan Stone wrote: > "make tinderbox" has been broken for weeks, so I presume it's not what I'm > supposed to be using to test my commits anymore. What's the officially > supported make target that I'm supposed to use? I use "make universe", sometimes with the -DMAKE_JUST_KERNELS option. But the LINT kernels for x86 and sparc have been broken since January. -- Ian From owner-freebsd-current@FreeBSD.ORG Sat Mar 21 14:18:39 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 18DA179D; Sat, 21 Mar 2015 14:18:39 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 79AA0BD0; Sat, 21 Mar 2015 14:18:38 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t2LEIW1p098992 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 21 Mar 2015 16:18:32 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t2LEIW1p098992 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t2LEIWVm098991; Sat, 21 Mar 2015 16:18:32 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 21 Mar 2015 16:18:32 +0200 From: Konstantin Belousov To: Mateusz Guzik , jenkins-admin@freebsd.org, freebsd-current@freebsd.org, Mateusz Guzik Subject: Re: [PATCH 1/3] fork: assign refed credentials earlier Message-ID: <20150321141832.GH2379@kib.kiev.ua> References: <20150320122125.GP2379@kib.kiev.ua> <1426899640-6599-1-git-send-email-mjguzik@gmail.com> <1426899640-6599-2-git-send-email-mjguzik@gmail.com> <20150321015151.GF2379@kib.kiev.ua> <20150321015722.GC27736@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150321015722.GC27736@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) 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.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Mar 2015 14:18:39 -0000 On Sat, Mar 21, 2015 at 02:57:22AM +0100, Mateusz Guzik wrote: > On Sat, Mar 21, 2015 at 03:51:51AM +0200, Konstantin Belousov wrote: > > On Sat, Mar 21, 2015 at 02:00:38AM +0100, Mateusz Guzik wrote: > > > From: Mateusz Guzik > > > > > > Prior to this change the kernel would take p1's credentials and assign > > > them tempororarily to p2. But p1 could change credentials at that time > > > and in effect give us a use-after-free. > > In which way could it change the credentials ? The assigned credentials > > are taken from td_ucred, which, I thought, are guaranteed to be stable > > for the duration of a syscall. > > > > It takes thread's credential in do_fork. But initial copy is taken > unlocked from struct proc. > > Relevant part of the diff: > > > @@ -870,7 +867,7 @@ fork1(struct thread *td, int flags, int pages, struct proc **procp, > > > * XXX: This is ugly; when we copy resource usage, we need to bump > > > * per-cred resource counters. > > > */ > > > - proc_set_cred(newproc, p1->p_ucred); > > > + proc_set_cred(newproc, crhold(td->td_ucred)); > > > I do not understand your note, nor I see the chunk above in the patches you send. Below is the citation from the patch 1: @@ -410,9 +410,6 @@ do_fork(struct thread *td, int flags, struct proc *p2, +struct thread *td2, bzero(&p2->p_startzero, __rangeof(struct proc, p_startzero, p_endzero)); - crhold(td->td_ucred); - proc_set_cred(p2, td->td_ucred); - From owner-freebsd-current@FreeBSD.ORG Sat Mar 21 15:08:20 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D4E364E for ; Sat, 21 Mar 2015 15:08:20 +0000 (UTC) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::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 BF75672 for ; Sat, 21 Mar 2015 15:08:19 +0000 (UTC) Received: by iedfl3 with SMTP id fl3so10715857ied.1 for ; Sat, 21 Mar 2015 08:08:19 -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:content-type; bh=AVmWooTrD/yRSWLmSkCHfaotKLjf66A3VR0HF42M8Dg=; b=yD3MDk7TGntamTIJZxxunavXoyYwIuMNMLYzUm0pmwnc3UBeBAnOAf/yYTLh+I/d5g PzVVXzKkUYK/2kACmXka4s3iPsNtdqTu4cNxkVHRHCyoa+QVOsIJFv6GhToy1Qf/e2rm iylQeScU5mok6n4A9AFKR6ggCsC+a1N+YFeINNpgtAauFWWThWqy01weVEJ0RHDs1ZMp EvjvMFy4nylNejrBcm2Glw8Yo7OvGNgFJscL753bdOR0p/lxkIJbgzG5Et+5XARfmfNg pbblenUoTAofsxhWiLeOWSHicKb75V25v3ApYy9g7PXXgkBQhQ13nkztwfJDyQ5Sv6NB WR7w== X-Received: by 10.50.143.36 with SMTP id sb4mr3733079igb.0.1426950499125; Sat, 21 Mar 2015 08:08:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.55.167 with HTTP; Sat, 21 Mar 2015 08:07:58 -0700 (PDT) In-Reply-To: <550D2932.3090101@icloud.com> References: <550C505F.2030809@icloud.com> <550C9CEF.4040302@icloud.com> <550D2932.3090101@icloud.com> From: Miguel Clara Date: Sat, 21 Mar 2015 15:07:58 +0000 Message-ID: Subject: Re: Atheros AR9460 and Acer Aspire V17 Nitro on FreeBSD 11 not working To: Anders Bolt-Evensen Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Mar 2015 15:08:20 -0000 On Sat, Mar 21, 2015 at 8:17 AM, Anders Bolt-Evensen wrote: > Do you mean to check dmesg -a while doing "vmstat -ia | grep ath0"? > I did run "wlandebug +scan", then ifconfig wlan0 up scan and then "vmstat > -ia | grep ath0". > The only output I got from "vmstat -ia | grep ath0" is: > irq18: ath0 21 0 > The second time I ran that last command I got > irq18: ath0 22 0 > > It is worth mentioning that wifi with this Atheros card works just fine on > Windows (I am using this wlan when typing this answer on Windows). > There is a button that seems to enable airplane mode, but pressing this > button does not seem to change anything as far as FreeBSD is concerned. > Other than that button I can't find any button that enables or disables > wifi. > > > On 3/21/2015 5:22 AM, Kevin Oberman wrote: > >> On Fri, Mar 20, 2015 at 4:31 PM, Adrian Chadd wrote: >> >> Hm, ok. either interrupts aren't working, or the thing is deaf. :( >>> >>> can you do that and then in another screen run vmstat -ia | grep ath0 ? >>> >>> I'd like to see if it's at least posting interrupts. >>> >>> Could a bad antenna connection (loose plug/broken conductor/pinch to >> chassis shorting to ground) explain this? Or would the hardware notice and >> report this in all cases? >> > Guess it depends on the laptop model, on my acer I do have Fn-F3 (antena icon) playing with with seems to have some effect: ugen1.4: at usbus1 (disconnected) ugen1.4: at usbus1 But I didn't loose connection. If relevant: ugen0.1: at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA) ugen1.1: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen2.1: at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen0.2: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA) ugen1.2: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen2.2: at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen0.3: <1.3M HD WebCam SuYin> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) ugen1.3: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) ugen1.4: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA) -- >> Kevin Oberman, Network Engineer, Retired >> E-mail: rkoberman@gmail.com >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org >> " >> > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://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 Mar 21 15:21:52 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03363A20 for ; Sat, 21 Mar 2015 15:21:52 +0000 (UTC) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001: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 B491C204 for ; Sat, 21 Mar 2015 15:21:51 +0000 (UTC) Received: by igcqo1 with SMTP id qo1so9692884igc.0 for ; Sat, 21 Mar 2015 08:21:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=8b/BufQf2diuroIFa6qPfzZWOh69+URkbT3ZoGq0NoY=; b=VFLvAiyZIPbeerONzS1ml/4pRcBZaerM5jzHE6BSBWAu6a2qTYO7Na6VOzYfDEU3Dq WYy2zSiLDbYgwwwoMROz3Drf5QHjnXP/IUg8F5P0Br1v1LXCupPwDRcL3nQ+ul+XLxUU iAltOpft3D+68byIezJT/h/6v7kowMzMeZlVYZ2zG3nTPkaWF4yxjsPa4JkjloKcHs7o 8ALPbd/cxWuswzCAXElwnuFYH83L0tVLNzr323xbNc7oY6amcbQAkefGx/rMEHYYzPpJ iRnyQtxYtW3Y/79HdPkSj1r8A1YTgT247BGfopW042teMTKEQG3Dz55uOxzReySGAeAm An8Q== MIME-Version: 1.0 X-Received: by 10.42.109.12 with SMTP id j12mr10581095icp.22.1426951311106; Sat, 21 Mar 2015 08:21:51 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.17.194 with HTTP; Sat, 21 Mar 2015 08:21:51 -0700 (PDT) In-Reply-To: References: <550C505F.2030809@icloud.com> <550C9CEF.4040302@icloud.com> <550D2932.3090101@icloud.com> Date: Sat, 21 Mar 2015 08:21:51 -0700 X-Google-Sender-Auth: paWv08enD974nZ4_tLhUIiYJGQI Message-ID: Subject: Re: Atheros AR9460 and Acer Aspire V17 Nitro on FreeBSD 11 not working From: Adrian Chadd To: Miguel Clara Content-Type: text/plain; charset=UTF-8 Cc: Anders Bolt-Evensen , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Mar 2015 15:21:52 -0000 Hi, It may be rfkill then. It may be that there's a GPIO pin wired up somewhere that needs updating. Erk. Someone buy me one of these laptops so I can see what's going on? :) -a From owner-freebsd-current@FreeBSD.ORG Sat Mar 21 16:21:53 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B7662B13 for ; Sat, 21 Mar 2015 16:21:53 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 98F7C996 for ; Sat, 21 Mar 2015 16:21:53 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 7A25B49B for ; Sat, 21 Mar 2015 16:21:53 +0000 (UTC) Date: Sat, 21 Mar 2015 16:21:53 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1839238505.8.1426954913275.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1209369086.7.1426938733235.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1209369086.7.1426938733235.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD-tests2 #861 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Mar 2015 16:21:53 -0000 See ------------------------------------------ [...truncated 1078 lines...] lib/libc/string/strspn:strspn -> passed [0.014s] lib/libc/string/swab:swab_basic -> passed [0.015s] lib/libc/sys/access_test:access_access -> passed [0.019s] lib/libc/sys/access_test:access_fault -> passed [0.015s] lib/libc/sys/access_test:access_inval -> passed [0.015s] lib/libc/sys/access_test:access_notdir -> passed [0.015s] lib/libc/sys/access_test:access_notexist -> passed [0.015s] lib/libc/sys/access_test:access_toolong -> passed [0.014s] lib/libc/sys/chroot_test:chroot_basic -> passed [0.018s] lib/libc/sys/chroot_test:chroot_err -> passed [0.015s] lib/libc/sys/chroot_test:chroot_perm -> passed [0.016s] lib/libc/sys/clock_gettime_test:clock_gettime_real -> passed [0.016s] lib/libc/sys/connect_test:connect_low_port -> passed [0.015s] lib/libc/sys/dup_test:dup2_basic -> passed [0.014s] lib/libc/sys/dup_test:dup2_err -> passed [0.014s] lib/libc/sys/dup_test:dup2_max -> passed [0.014s] lib/libc/sys/dup_test:dup2_mode -> passed [0.027s] lib/libc/sys/dup_test:dup3_err -> passed [0.013s] lib/libc/sys/dup_test:dup3_max -> passed [0.013s] lib/libc/sys/dup_test:dup3_mode -> passed [0.031s] lib/libc/sys/dup_test:dup_err -> passed [0.015s] lib/libc/sys/dup_test:dup_max -> passed [0.020s] lib/libc/sys/dup_test:dup_mode -> passed [0.031s] lib/libc/sys/fsync_test:fsync_err -> passed [0.013s] lib/libc/sys/fsync_test:fsync_sync -> passed [2.014s] lib/libc/sys/getcontext_test:getcontext_err -> passed [0.016s] lib/libc/sys/getcontext_test:setcontext_err -> passed [0.014s] lib/libc/sys/getcontext_test:setcontext_link -> passed [0.013s] lib/libc/sys/getgroups_test:getgroups_err -> expected_failure: Reported as kern/189941: /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/sys/t_getgroups.c:63: getgroups(-1, gidset) == -1 not met [0.014s] lib/libc/sys/getgroups_test:getgroups_getgid -> passed [0.014s] lib/libc/sys/getgroups_test:getgroups_setgid -> passed [0.015s] lib/libc/sys/getgroups_test:getgroups_zero -> passed [0.013s] lib/libc/sys/getitimer_test:getitimer_empty -> passed [0.013s] lib/libc/sys/getitimer_test:getitimer_err -> passed [0.013s] lib/libc/sys/getitimer_test:setitimer_basic -> passed [0.014s] lib/libc/sys/getitimer_test:setitimer_err -> passed [0.015s] lib/libc/sys/getitimer_test:setitimer_old -> passed [0.015s] lib/libc/sys/getlogin_test:getlogin_r_err -> passed [0.014s] lib/libc/sys/getlogin_test:getlogin_same -> passed [0.015s] lib/libc/sys/getlogin_test:setlogin_basic -> passed [0.016s] lib/libc/sys/getlogin_test:setlogin_err -> passed [0.015s] lib/libc/sys/getlogin_test:setlogin_perm -> passed [0.015s] lib/libc/sys/getpid_test:getpid_process -> passed [0.023s] lib/libc/sys/getpid_test:getpid_thread -> passed [0.019s] lib/libc/sys/getrusage_test:getrusage_err -> passed [0.013s] lib/libc/sys/getrusage_test:getrusage_sig -> passed [0.013s] lib/libc/sys/getrusage_test:getrusage_utime_back -> passed [2.107s] lib/libc/sys/getrusage_test:getrusage_utime_zero -> skipped: this testcase passes/fails sporadically on FreeBSD/i386 @ r273153 (at least) [0.014s] lib/libc/sys/getsid_test:getsid_current -> passed [0.014s] lib/libc/sys/getsid_test:getsid_err -> passed [0.015s] lib/libc/sys/getsid_test:getsid_process -> passed [0.015s] lib/libc/sys/gettimeofday_test:gettimeofday_err -> passed [0.015s] lib/libc/sys/gettimeofday_test:gettimeofday_mono -> passed [0.015s] lib/libc/sys/issetugid_test:issetugid_egid -> passed [0.018s] lib/libc/sys/issetugid_test:issetugid_euid -> passed [0.017s] lib/libc/sys/issetugid_test:issetugid_rgid -> passed [0.016s] lib/libc/sys/issetugid_test:issetugid_ruid -> passed [0.017s] lib/libc/sys/kevent_test:kevent_zerotimer -> passed [0.030s] lib/libc/sys/kevent_test:kqueue_desc_passing -> passed [0.017s] lib/libc/sys/kevent_test:kqueue_unsupported_fd -> skipped: no /nonexistent available for testing [0.014s] lib/libc/sys/kill_test:kill_basic -> passed [0.019s] lib/libc/sys/kill_test:kill_err -> passed [0.016s] lib/libc/sys/kill_test:kill_perm -> passed [1.019s] lib/libc/sys/kill_test:kill_pgrp_neg -> passed [0.017s] lib/libc/sys/kill_test:kill_pgrp_zero -> passed [0.016s] lib/libc/sys/link_test:link_count -> passed [0.019s] lib/libc/sys/link_test:link_err -> passed [0.019s] lib/libc/sys/link_test:link_perm -> passed [0.015s] lib/libc/sys/link_test:link_stat -> passed [0.020s] lib/libc/sys/listen_test:listen_err -> passed [0.018s] lib/libc/sys/listen_test:listen_low_port -> passed [0.014s] lib/libc/sys/mincore_test:mincore_err -> passed [0.015s] lib/libc/sys/mincore_test:mincore_resid -> passed [0.039s] lib/libc/sys/mincore_test:mincore_shmseg -> passed [0.018s] lib/libc/sys/mkdir_test:mkdir_err -> passed [0.016s] lib/libc/sys/mkdir_test:mkdir_mode -> passed [1.428s] lib/libc/sys/mkdir_test:mkdir_perm -> passed [0.018s] lib/libc/sys/mkdir_test:mkdir_trail -> passed [0.025s] lib/libc/sys/mkfifo_test:mkfifo_block -> passed [1.088s] lib/libc/sys/mkfifo_test:mkfifo_err -> passed [0.020s] lib/libc/sys/mkfifo_test:mkfifo_nonblock -> passed [1.064s] lib/libc/sys/mkfifo_test:mkfifo_perm -> passed [0.020s] lib/libc/sys/mkfifo_test:mkfifo_stat -> passed [0.020s] lib/libc/sys/mknod_test:mknod_err -> passed [0.017s] lib/libc/sys/mknod_test:mknod_exist -> passed [0.018s] lib/libc/sys/mknod_test:mknod_perm -> passed [0.018s] lib/libc/sys/mknod_test:mknod_stat -> expected_failure: mknod does not allow S_IFREG: /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/sys/t_mknod.c:179: mknod(path, S_IFREG, 0) == 0 not met [0.020s] lib/libc/sys/mlock_test:mlock_clip -> passed [0.015s] lib/libc/sys/mlock_test:mlock_err -> passed [0.015s] lib/libc/sys/mlock_test:mlock_limits -> passed [0.016s] lib/libc/sys/mlock_test:mlock_mmap -> passed [0.015s] lib/libc/sys/mlock_test:mlock_nested -> passed [0.015s] lib/libc/sys/mmap_test:mmap_err -> passed [0.015s] lib/libc/sys/mmap_test:mmap_loan -> passed [0.019s] lib/libc/sys/mmap_test:mmap_prot_1 -> passed [0.019s] lib/libc/sys/mmap_test:mmap_prot_2 -> passed [0.015s] lib/libc/sys/mmap_test:mmap_prot_3 -> passed [0.020s] lib/libc/sys/mmap_test:mmap_truncate -> passed [0.024s] lib/libc/sys/mmap_test:mmap_va0 -> passed [0.015s] lib/libc/sys/mprotect_test:mprotect_access -> passed [0.018s] lib/libc/sys/mprotect_test:mprotect_err -> passed [0.015s] lib/libc/sys/mprotect_test:mprotect_pax -> passed [0.014s] lib/libc/sys/mprotect_test:mprotect_write -> passed [0.015s] lib/libc/sys/msgctl_test:msgctl_err -> passed [0.018s] lib/libc/sys/msgctl_test:msgctl_perm -> passed [0.019s] lib/libc/sys/msgctl_test:msgctl_pid -> passed [2.093s] lib/libc/sys/msgctl_test:msgctl_set -> passed [0.020s] lib/libc/sys/msgctl_test:msgctl_time -> passed [0.017s] lib/libc/sys/msgget_test:msgget_excl -> passed [0.017s] lib/libc/sys/msgget_test:msgget_exit -> passed [0.018s] lib/libc/sys/msgget_test:msgget_init -> passed [0.018s] lib/libc/sys/msgget_test:msgget_limit -> passed [0.016s] lib/libc/sys/msgget_test:msgget_mode -> passed [0.019s] lib/libc/sys/msgrcv_test:msgrcv_basic -> passed [0.017s] lib/libc/sys/msgrcv_test:msgrcv_block -> passed [2.153s] lib/libc/sys/msgrcv_test:msgrcv_err -> passed [0.018s] lib/libc/sys/msgrcv_test:msgrcv_mtype -> passed [0.017s] lib/libc/sys/msgrcv_test:msgrcv_nonblock -> passed [2.079s] lib/libc/sys/msgrcv_test:msgrcv_truncate -> passed [0.018s] lib/libc/sys/msgsnd_test:msgsnd_block -> passed [2.111s] lib/libc/sys/msgsnd_test:msgsnd_count -> passed [0.017s] lib/libc/sys/msgsnd_test:msgsnd_err -> passed [0.018s] lib/libc/sys/msgsnd_test:msgsnd_nonblock -> passed [2.087s] lib/libc/sys/msgsnd_test:msgsnd_perm -> passed [0.018s] lib/libc/sys/msync_test:msync_async -> passed [0.018s] lib/libc/sys/msync_test:msync_err -> passed [0.021s] lib/libc/sys/msync_test:msync_invalidate -> passed [0.017s] lib/libc/sys/msync_test:msync_sync -> passed [0.018s] lib/libc/sys/nanosleep_test:nanosleep_basic -> passed [0.015s] lib/libc/sys/nanosleep_test:nanosleep_err -> passed [0.014s] lib/libc/sys/nanosleep_test:nanosleep_sig -> passed [1.084s] lib/libc/sys/pipe_test:pipe_restart -> passed [2.073s] lib/libc/sys/pipe2_test:pipe2_basic -> passed [0.015s] lib/libc/sys/pipe2_test:pipe2_cloexec -> passed [0.015s] lib/libc/sys/pipe2_test:pipe2_consume -> passed [0.015s] lib/libc/sys/pipe2_test:pipe2_einval -> passed [0.015s] lib/libc/sys/pipe2_test:pipe2_nonblock -> passed [0.016s] lib/libc/sys/poll_test:poll_3way -> passed [10.030s] lib/libc/sys/poll_test:poll_basic -> passed [0.016s] lib/libc/sys/poll_test:poll_err -> passed [0.014s] lib/libc/sys/revoke_test:revoke_basic -> skipped: revoke(2) is only implemented for devfs(5). [0.017s] lib/libc/sys/revoke_test:revoke_err -> skipped: revoke(2) is only implemented for devfs(5). [0.015s] lib/libc/sys/revoke_test:revoke_perm -> skipped: revoke(2) is only implemented for devfs(5). [0.017s] lib/libc/sys/select_test:pselect_sigmask -> passed [1.067s] lib/libc/sys/select_test:pselect_timeout -> passed [0.018s] lib/libc/sys/setrlimit_test:setrlimit_basic -> passed [0.015s] lib/libc/sys/setrlimit_test:setrlimit_current -> passed [0.015s] lib/libc/sys/setrlimit_test:setrlimit_err -> passed [0.015s] lib/libc/sys/setrlimit_test:setrlimit_fsize -> passed [0.020s] lib/libc/sys/setrlimit_test:setrlimit_memlock -> passed [0.015s] lib/libc/sys/setrlimit_test:setrlimit_nofile_1 -> passed [0.016s] lib/libc/sys/setrlimit_test:setrlimit_nofile_2 -> passed [0.016s] lib/libc/sys/setrlimit_test:setrlimit_nproc -> maxproc limit exceeded by uid 977 (pid 20393); see tuning(7) and login.conf(5) passed [0.553s] lib/libc/sys/setrlimit_test:setrlimit_perm -> panic: mutex process lock not owned at /builds/FreeBSD_HEAD/sys/kern/kern_prot.c:1974 cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00974598e0 vpanic() at vpanic+0x189/frame 0xfffffe0097459960 panic() at panic+0x43/frame 0xfffffe00974599c0 __mtx_assert() at __mtx_assert+0xc2/frame 0xfffffe00974599d0 proc_set_cred() at proc_set_cred+0x36/frame 0xfffffe00974599f0 fork1() at fork1+0x27e/frame 0xfffffe0097459ac0 sys_fork() at sys_fork+0x1f/frame 0xfffffe0097459ae0 amd64_syscall() at amd64_syscall+0x27f/frame 0xfffffe0097459bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0097459bf0 --- syscall (0, FreeBSD ELF64, nosys), rip = 0x8019c516a, rsp = 0x7fffffffc2d8, rbp = 0x7fffffffc340 --- KDB: enter: panic [ thread pid 660 tid 100052 ] Stopped at kdb_enter+0x3e: movq $0,kdb_why db> Traceback (most recent call last): File "/vm/freebsd-ci/scripts/test/run-tests.py", line 152, in main(sys.argv) File "/vm/freebsd-ci/scripts/test/run-tests.py", line 80, in main runTest() File "/vm/freebsd-ci/scripts/test/run-tests.py", line 124, in runTest child2.expect(prompt, timeout=7200) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1451, in expect timeout, searchwindowsize) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1466, in expect_list timeout, searchwindowsize) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1568, in expect_loop raise TIMEOUT(str(err) + '\n' + str(self)) pexpect.TIMEOUT: Timeout exceeded. version: 3.3 command: /usr/sbin/bhyve args: [u'/usr/sbin/bhyve', u'-c', u'2', u'-m', u'2G', u'-AI', u'-H', u'-P', u'-g', u'0', u'-s', u'0:0,hostbridge', u'-s', u'1:0,lpc', u'-s', u'2:0,virtio-net,tap0,mac=58:9c:fc:00:00:2e', u'-s', u'3:0,ahci-hd,/net/jenkins-10.freebsd.org/builds/Build-UFS-image/image/FreeBSD_HEAD/test.img', u'-l', u'com1,stdio', u'vm_test'] searcher: buffer (last 100 chars): 'nter: panic\r\n[ thread pid 660 tid 100052 ]\r\nStopped at kdb_enter+0x3e: movq $0,kdb_why\r\ndb> ' before (last 100 chars): 'nter: panic\r\n[ thread pid 660 tid 100052 ]\r\nStopped at kdb_enter+0x3e: movq $0,kdb_why\r\ndb> ' after: match: None match_index: None exitstatus: None flag_eof: False pid: 69957 child_fd: 4 closed: False timeout: 30 delimiter: logfile: ', mode 'w' at 0x800670150> logfile_read: None logfile_send: None maxread: 2000 ignorecase: False searchwindowsize: None delaybeforesend: 0.05 delayafterclose: 0.1 delayafterterminate: 0.1 Build step 'Execute shell' marked build as failure Recording test results ERROR: Publisher hudson.tasks.junit.JUnitResultArchiver aborted due to exception hudson.AbortException: Test reports were found but none of them are new. Did tests run? For example, is 6 days 14 hr old at hudson.tasks.junit.TestResult.parse(TestResult.java:178) at hudson.tasks.junit.TestResult.parse(TestResult.java:146) at hudson.tasks.junit.TestResult.(TestResult.java:122) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:119) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:92) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2688) at hudson.remoting.UserRequest.perform(UserRequest.java:121) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at hudson.remoting.Request$2.run(Request.java:324) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) at ......remote call to havoc.ysv.freebsd.org(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1356) at hudson.remoting.UserResponse.retrieve(UserRequest.java:221) at hudson.remoting.Channel.call(Channel.java:752) at hudson.FilePath.act(FilePath.java:978) at hudson.FilePath.act(FilePath.java:967) at hudson.tasks.junit.JUnitParser.parseResult(JUnitParser.java:89) at hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:120) at hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:137) at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:74) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:761) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:721) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:670) at hudson.model.Run.execute(Run.java:1775) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240) From owner-freebsd-current@FreeBSD.ORG Sat Mar 21 16:25:57 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C392D95; Sat, 21 Mar 2015 16:25:57 +0000 (UTC) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::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 06F389C5; Sat, 21 Mar 2015 16:25:57 +0000 (UTC) Received: by pdbni2 with SMTP id ni2so139215977pdb.1; Sat, 21 Mar 2015 09:25:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=EdHAsCPqY/s4N+7xf3rD4Z+gTB+bIj+Ytpvl2zwv1hg=; b=lApi7It86KOlm7giopo4sfHLEZO+eSBH8cR5qejnF23pCQNR+h8F/Xsox805liUY7/ 2Jrbf+HWixvN096iLqYt5/5tKhUneit7PJ0j69VfaQdSyO7ivgrWKRGrCh9N1jLpVEkP jk6xwx7PcGT+avVlGXhVFGQbapdolpmxfhJ+d7oIo4WtlAkWoYCXPlDyLoRAosv2qkin ctKZjFPR/wPKg4H/7Ee2oaQNbhAq8s52dX6LEMK3djmhQYGIFMJ04wNM1u8nkwn42Llt ADQ7Tq6G7moVARX8ShNVPyycuC8GA9z/lc5eWuzUTx5bhdWOgFp3qLYqFnErMnwDi/tZ 0uWg== X-Received: by 10.67.1.164 with SMTP id bh4mr193953051pad.129.1426955156693; Sat, 21 Mar 2015 09:25:56 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:e8eb:e141:6ee:f0b3? ([2601:8:ab80:7d6:e8eb:e141:6ee:f0b3]) by mx.google.com with ESMTPSA id x3sm12064116pdo.0.2015.03.21.09.25.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 21 Mar 2015 09:25:56 -0700 (PDT) References: <1426944905.20654.5.camel@freebsd.org> Mime-Version: 1.0 (1.0) In-Reply-To: <1426944905.20654.5.camel@freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (12D508) From: Garrett Cooper Subject: Re: What's the official method to test the build now? Date: Sat, 21 Mar 2015 09:25:54 -0700 To: Ian Lepore Cc: FreeBSD Current , Ryan Stone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Mar 2015 16:25:57 -0000 > On Mar 21, 2015, at 06:35, Ian Lepore wrote: > >> On Fri, 2015-03-20 at 19:52 -0400, Ryan Stone wrote: >> "make tinderbox" has been broken for weeks, so I presume it's not what I'm >> supposed to be using to test my commits anymore. What's the officially >> supported make target that I'm supposed to use? > > I use "make universe", sometimes with the -DMAKE_JUST_KERNELS option. make universe doesn't error out; make tinderbox does however. > But the LINT kernels for x86 and sparc have been broken since January. Cheers! From owner-freebsd-current@FreeBSD.ORG Sat Mar 21 18:19:37 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 42EA39D0; Sat, 21 Mar 2015 18:19:37 +0000 (UTC) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450: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 BE2657A5; Sat, 21 Mar 2015 18:19:36 +0000 (UTC) Received: by wixw10 with SMTP id w10so18750726wix.0; Sat, 21 Mar 2015 11:19:35 -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-type:content-disposition:in-reply-to :user-agent; bh=u7EpBLOHiM/qK5EsYbBnyR8O5JnaCvRVMy8aW8Im8Uw=; b=UpnTojmUmDZHV6xMdzlE5FqgMw3eI12moV+PMRYqgPF9Fcv7i570ge6t4cL0AoxdPB OMASXkhHJBNX4hKmXoC3S3GSTZwvOeXR8ooYRkfM3Gcfz1h0YTDOvar6wT+zoo8sIVXP SgIdVnV6cs8kxJyylHNot3uUoBPUgDX9HXXoH3CBvTxgrOKEgneoB36CvlGM4xtBd6iV h3iQ56KQ5PMnbSaI9yLXcedOu4pLK90qUGX8tll2zddDlAm2HjerV/Ho+8kPMPIQsAJY 9BSiXmtBxsoe4znYHTjrMWexx2KUKOwjfrs+k4w/mmH+PrOU7afOxQmvEPpBySwgA2N7 qpIw== X-Received: by 10.180.103.166 with SMTP id fx6mr5986835wib.4.1426961975171; Sat, 21 Mar 2015 11:19:35 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id n1sm3410366wib.11.2015.03.21.11.19.33 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 21 Mar 2015 11:19:33 -0700 (PDT) Date: Sat, 21 Mar 2015 19:19:31 +0100 From: Mateusz Guzik To: Konstantin Belousov Subject: Re: [PATCH 1/3] fork: assign refed credentials earlier Message-ID: <20150321181931.GA14650@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Konstantin Belousov , jenkins-admin@freebsd.org, freebsd-current@freebsd.org, Mateusz Guzik References: <20150320122125.GP2379@kib.kiev.ua> <1426899640-6599-1-git-send-email-mjguzik@gmail.com> <1426899640-6599-2-git-send-email-mjguzik@gmail.com> <20150321015151.GF2379@kib.kiev.ua> <20150321015722.GC27736@dft-labs.eu> <20150321141832.GH2379@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150321141832.GH2379@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, jenkins-admin@freebsd.org, Mateusz Guzik X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Mar 2015 18:19:37 -0000 On Sat, Mar 21, 2015 at 04:18:32PM +0200, Konstantin Belousov wrote: > On Sat, Mar 21, 2015 at 02:57:22AM +0100, Mateusz Guzik wrote: > > On Sat, Mar 21, 2015 at 03:51:51AM +0200, Konstantin Belousov wrote: > > > On Sat, Mar 21, 2015 at 02:00:38AM +0100, Mateusz Guzik wrote: > > > > From: Mateusz Guzik > > > > > > > > Prior to this change the kernel would take p1's credentials and assign > > > > them tempororarily to p2. But p1 could change credentials at that time > > > > and in effect give us a use-after-free. > > > In which way could it change the credentials ? The assigned credentials > > > are taken from td_ucred, which, I thought, are guaranteed to be stable > > > for the duration of a syscall. > > > > > > > It takes thread's credential in do_fork. But initial copy is taken > > unlocked from struct proc. > > > > Relevant part of the diff: > > > > @@ -870,7 +867,7 @@ fork1(struct thread *td, int flags, int pages, struct proc **procp, > > > > * XXX: This is ugly; when we copy resource usage, we need to bump > > > > * per-cred resource counters. > > > > */ > > > > - proc_set_cred(newproc, p1->p_ucred); > > > > + proc_set_cred(newproc, crhold(td->td_ucred)); > > > > > > I do not understand your note, nor I see the chunk above in the patches > you send. Below is the citation from the patch 1: > > @@ -410,9 +410,6 @@ do_fork(struct thread *td, int flags, struct proc *p2, > +struct thread *td2, > bzero(&p2->p_startzero, > __rangeof(struct proc, p_startzero, p_endzero)); > > - crhold(td->td_ucred); > - proc_set_cred(p2, td->td_ucred); > - fork1 does: proc_set_cred(newproc, p1->p_ucred); p1 is unlocked, so whatever memory p1->p_ucred points to may already be freed. /* * Initialize resource accounting for the child process. */ error = racct_proc_fork(p1, newproc); if (error != 0) { error = EAGAIN; goto fail1; } racct_proc_fork -> racct_add_locked results in accessing such now-possibly-freed credentials. do_fork which properly assigns credentials (from a stable source (td_ucred) + grabs a reference) is called later. The patch in question moves aforementioned assignent earlier to replace unsafe one with p1->p_ucred. -- Mateusz Guzik From owner-freebsd-current@FreeBSD.ORG Sat Mar 21 19:29:14 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B42D9136; Sat, 21 Mar 2015 19:29:14 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 3D1CEE37; Sat, 21 Mar 2015 19:29:14 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t2LJT4F2002174 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 21 Mar 2015 21:29:04 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t2LJT4F2002174 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t2LJT4Lm002173; Sat, 21 Mar 2015 21:29:04 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 21 Mar 2015 21:29:04 +0200 From: Konstantin Belousov To: Mateusz Guzik , jenkins-admin@freebsd.org, freebsd-current@freebsd.org, Mateusz Guzik Subject: Re: [PATCH 1/3] fork: assign refed credentials earlier Message-ID: <20150321192904.GQ2379@kib.kiev.ua> References: <20150320122125.GP2379@kib.kiev.ua> <1426899640-6599-1-git-send-email-mjguzik@gmail.com> <1426899640-6599-2-git-send-email-mjguzik@gmail.com> <20150321015151.GF2379@kib.kiev.ua> <20150321015722.GC27736@dft-labs.eu> <20150321141832.GH2379@kib.kiev.ua> <20150321181931.GA14650@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150321181931.GA14650@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) 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.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Mar 2015 19:29:14 -0000 On Sat, Mar 21, 2015 at 07:19:31PM +0100, Mateusz Guzik wrote: > On Sat, Mar 21, 2015 at 04:18:32PM +0200, Konstantin Belousov wrote: > > On Sat, Mar 21, 2015 at 02:57:22AM +0100, Mateusz Guzik wrote: > > > On Sat, Mar 21, 2015 at 03:51:51AM +0200, Konstantin Belousov wrote: > > > > On Sat, Mar 21, 2015 at 02:00:38AM +0100, Mateusz Guzik wrote: > > > > > From: Mateusz Guzik > > > > > > > > > > Prior to this change the kernel would take p1's credentials and assign > > > > > them tempororarily to p2. But p1 could change credentials at that time > > > > > and in effect give us a use-after-free. > > > > In which way could it change the credentials ? The assigned credentials > > > > are taken from td_ucred, which, I thought, are guaranteed to be stable > > > > for the duration of a syscall. > > > > > > > > > > It takes thread's credential in do_fork. But initial copy is taken > > > unlocked from struct proc. > > > > > > Relevant part of the diff: > > > > > @@ -870,7 +867,7 @@ fork1(struct thread *td, int flags, int pages, struct proc **procp, > > > > > * XXX: This is ugly; when we copy resource usage, we need to bump > > > > > * per-cred resource counters. > > > > > */ > > > > > - proc_set_cred(newproc, p1->p_ucred); > > > > > + proc_set_cred(newproc, crhold(td->td_ucred)); > > > > > > > > > I do not understand your note, nor I see the chunk above in the patches > > you send. Below is the citation from the patch 1: > > > > @@ -410,9 +410,6 @@ do_fork(struct thread *td, int flags, struct proc *p2, > > +struct thread *td2, > > bzero(&p2->p_startzero, > > __rangeof(struct proc, p_startzero, p_endzero)); > > > > - crhold(td->td_ucred); > > - proc_set_cred(p2, td->td_ucred); > > - > > fork1 does: > > proc_set_cred(newproc, p1->p_ucred); > > p1 is unlocked, so whatever memory p1->p_ucred points to may already be > freed. > > /* > * Initialize resource accounting for the child process. > */ > error = racct_proc_fork(p1, newproc); > if (error != 0) { > error = EAGAIN; > goto fail1; > } > > racct_proc_fork -> racct_add_locked results in accessing such > now-possibly-freed credentials. > > do_fork which properly assigns credentials (from a stable source > (td_ucred) + grabs a reference) is called later. > > The patch in question moves aforementioned assignent earlier to replace > unsafe one with p1->p_ucred. It seems that I understand now. If you instead assign td->td_ucred for the new process p_ucred temporary, would it allow to avoid introducing fail2 label ? I dislike even more contrived cleanup after the patch. From owner-freebsd-current@FreeBSD.ORG Sat Mar 21 19:37:59 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4A7876F; Sat, 21 Mar 2015 19:37:59 +0000 (UTC) Received: from tensor.andric.com (unknown [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 911E4F26; Sat, 21 Mar 2015 19:37:59 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::8b7:b034:6f55:4291] (unknown [IPv6:2001:7b8:3a7:0:8b7:b034:6f55:4291]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 3990C5C4D; Sat, 21 Mar 2015 20:37:56 +0100 (CET) Subject: Re: What's the official method to test the build now? Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_1126F200-5784-4379-9334-82A409A9BF5E"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b6 From: Dimitry Andric In-Reply-To: Date: Sat, 21 Mar 2015 20:37:49 +0100 Message-Id: <12C281DE-55EC-4ECF-95BD-DFA6FCAABA26@FreeBSD.org> References: <1426944905.20654.5.camel@freebsd.org> To: Garrett Cooper X-Mailer: Apple Mail (2.2070.6) Cc: FreeBSD Current , Ryan Stone , Ian Lepore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Mar 2015 19:37:59 -0000 --Apple-Mail=_1126F200-5784-4379-9334-82A409A9BF5E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 21 Mar 2015, at 17:25, Garrett Cooper wrote: >=20 >> On Mar 21, 2015, at 06:35, Ian Lepore wrote: >>=20 >>> On Fri, 2015-03-20 at 19:52 -0400, Ryan Stone wrote: >>> "make tinderbox" has been broken for weeks, so I presume it's not = what I'm >>> supposed to be using to test my commits anymore. What's the = officially >>> supported make target that I'm supposed to use? >>=20 >> I use "make universe", sometimes with the -DMAKE_JUST_KERNELS option. >=20 > make universe doesn't error out; make tinderbox does however. >=20 >> But the LINT kernels for x86 and sparc have been broken since = January. So what's the effective difference between universe and tinderbox then? I've built quite a number of universes recently, and I while I did get a few errors, they were usually fixed quite quickly. Also, universe generates LINT kernel configurations, and builds them. I didn't see errors there either... Does tinderbox generate LINT configs differently, somehow? -Dimitry --Apple-Mail=_1126F200-5784-4379-9334-82A409A9BF5E 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.27 iEYEARECAAYFAlUNyJIACgkQsF6jCi4glqMxvACgzdWOoH62GQY50L+O0Uc+NmK6 bbMAn3mAm9CD+tbveK1nRTf+IzfNkVS6 =SCPM -----END PGP SIGNATURE----- --Apple-Mail=_1126F200-5784-4379-9334-82A409A9BF5E-- From owner-freebsd-current@FreeBSD.ORG Sat Mar 21 19:49:24 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF8F4905; Sat, 21 Mar 2015 19:49:24 +0000 (UTC) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::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 84924C4; Sat, 21 Mar 2015 19:49:24 +0000 (UTC) Received: by pdbni2 with SMTP id ni2so142475462pdb.1; Sat, 21 Mar 2015 12:49:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=wtVM90nmF2N2zzQ2MhBbGjIn+2z19RNYmXjf7n1zkNg=; b=EEvIuF4d6AsxZJlk3TnohL7jGmXCqvsXehvFEMao6bB3q+4ihnnqUumdno3OnNdPiw IOvf8WKJ+sBXphgctLnmjbCWpx7jrVaoG7tCToOhPVpZ3W/4PX/eIGvX6BMwyZ2t/r49 CqRZgvkqk/F5g8kM9rZnAMuamOoMyU3mcC1vMCfiMstRUecJWaDbqxXv0XG1q+slv3jq P0O5C2PH2JTRN3nJcLDijM/RIS46yREhNqdA/UIXfvrEQniEHLSvD1dSykPdjEqrrJWu +aQGPlkAd1PGrzCsjLHoILYfbzwzmvcZp/aogei+Mz0Y8VM7sBhY3nqnmFUfjSmFkJVl xQhQ== X-Received: by 10.70.44.170 with SMTP id f10mr57418755pdm.155.1426967364115; Sat, 21 Mar 2015 12:49:24 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:30d5:fbe6:6087:4031? ([2601:8:ab80:7d6:30d5:fbe6:6087:4031]) by mx.google.com with ESMTPSA id x3sm12335328pdb.36.2015.03.21.12.49.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 21 Mar 2015 12:49:23 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_C90818CC-1DBE-4434-B292-0F5E5476596D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: What's the official method to test the build now? From: Garrett Cooper In-Reply-To: <12C281DE-55EC-4ECF-95BD-DFA6FCAABA26@FreeBSD.org> Date: Sat, 21 Mar 2015 12:49:20 -0700 Message-Id: <996EB15F-7F52-498A-9EC3-3FB570579575@gmail.com> References: <1426944905.20654.5.camel@freebsd.org> <12C281DE-55EC-4ECF-95BD-DFA6FCAABA26@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.1878.6) Cc: FreeBSD Current , Ryan Stone , Ian Lepore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Mar 2015 19:49:25 -0000 --Apple-Mail=_C90818CC-1DBE-4434-B292-0F5E5476596D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 21, 2015, at 12:37, Dimitry Andric wrote: > On 21 Mar 2015, at 17:25, Garrett Cooper = wrote: >>=20 >>> On Mar 21, 2015, at 06:35, Ian Lepore wrote: >>>=20 >>>> On Fri, 2015-03-20 at 19:52 -0400, Ryan Stone wrote: >>>> "make tinderbox" has been broken for weeks, so I presume it's not = what I'm >>>> supposed to be using to test my commits anymore. What's the = officially >>>> supported make target that I'm supposed to use? >>>=20 >>> I use "make universe", sometimes with the -DMAKE_JUST_KERNELS = option. >>=20 >> make universe doesn't error out; make tinderbox does however. >>=20 >>> But the LINT kernels for x86 and sparc have been broken since = January. >=20 > So what's the effective difference between universe and tinderbox = then? > I've built quite a number of universes recently, and I while I did get = a > few errors, they were usually fixed quite quickly. >=20 > Also, universe generates LINT kernel configurations, and builds them. = I > didn't see errors there either... Does tinderbox generate LINT = configs > differently, somehow? universe gets called by tinderbox. =46rom Makefile: 6 # universe - *Really* build *everything* (buildworld and 7 # all kernels on all architectures). 8 # tinderbox - Same as universe, but presents a list of = failed build 9 # targets and exits with an error if there = were any. --Apple-Mail=_C90818CC-1DBE-4434-B292-0F5E5476596D 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVDctAAAoJEMZr5QU6S73eyuMH/0qizZx+yMpQul03VYyl8GXM DQ4xawy+x0B81CHyRyHNw23LfjlJbeUQ6se4vIdMJtdXaSe4U+v86xOS6hnbJcLh oISnGVpc9eEqVJj+19BQRpNclwfW/348ZPEbiqpTYEBmg945CVHnwQfXCeDGWHso CvFrL0Gr+Mv2LNTsu2Iip9Bkur3Kc3I51Xclbixi2daiga2ieQotXuWtQD/KhYRg rihWGIwSH67YPTjvqmihbzoV/0RKwSVj8sS9rPV+KyKNlqrT4X8H9KrN5ZGEFEgr DqewnmFLjNhVX6TrdxqkDI+kFsmyu6qRJCp012cw8rRgCHlO1gKxyRZLjMcQGVU= =u3T2 -----END PGP SIGNATURE----- --Apple-Mail=_C90818CC-1DBE-4434-B292-0F5E5476596D-- From owner-freebsd-current@FreeBSD.ORG Sat Mar 21 19:57:02 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2179657C; Sat, 21 Mar 2015 19:57:02 +0000 (UTC) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c: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 A066F1C0; Sat, 21 Mar 2015 19:57:01 +0000 (UTC) Received: by wibgn9 with SMTP id gn9so20318494wib.1; Sat, 21 Mar 2015 12:57:00 -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-type:content-disposition:in-reply-to :user-agent; bh=lXsTr0SFCtHNFW+2PuMweZLQ3V3iERMBcQXAGSdGyj0=; b=VZKOFlj6/rj0fq4MrmfaFTIr0Vxt5rEB57qE/D56S09wo28tlmaaaGOnU2WN/KGCMp NEc7x1xdrp2O/BWGXTF0RnKq0FUJ0fVxe2cXWoIllugXHkllTghH2+GNt8QUr29CNcQC j3adgewkeXPXHxpHtm92j9eb5X0s2pnp0LKv+3E1KtpXCntucHvbdc4MsPn831LtaLvi 7n6VqaMPsD8diqtGHxtHj9jacqjXYu+MsWBIBd2UIyAOTNrJJNHRPNvF4huf8Deb+zk9 rQ1wRstEVZLgg1fgs6xsNdZbGwJUIvBFK1jKNfvS4AHDfHYRn+j9kyuCydpNnzi0rofP g8OA== X-Received: by 10.180.38.1 with SMTP id c1mr6675168wik.84.1426967820086; Sat, 21 Mar 2015 12:57:00 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id fo9sm3718328wib.16.2015.03.21.12.56.58 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 21 Mar 2015 12:56:59 -0700 (PDT) Date: Sat, 21 Mar 2015 20:56:56 +0100 From: Mateusz Guzik To: Konstantin Belousov Subject: Re: [PATCH 1/3] fork: assign refed credentials earlier Message-ID: <20150321195656.GB14650@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Konstantin Belousov , jenkins-admin@freebsd.org, freebsd-current@freebsd.org, Mateusz Guzik References: <20150320122125.GP2379@kib.kiev.ua> <1426899640-6599-1-git-send-email-mjguzik@gmail.com> <1426899640-6599-2-git-send-email-mjguzik@gmail.com> <20150321015151.GF2379@kib.kiev.ua> <20150321015722.GC27736@dft-labs.eu> <20150321141832.GH2379@kib.kiev.ua> <20150321181931.GA14650@dft-labs.eu> <20150321192904.GQ2379@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150321192904.GQ2379@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, jenkins-admin@freebsd.org, Mateusz Guzik X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Mar 2015 19:57:02 -0000 On Sat, Mar 21, 2015 at 09:29:04PM +0200, Konstantin Belousov wrote: > On Sat, Mar 21, 2015 at 07:19:31PM +0100, Mateusz Guzik wrote: > > On Sat, Mar 21, 2015 at 04:18:32PM +0200, Konstantin Belousov wrote: > > > On Sat, Mar 21, 2015 at 02:57:22AM +0100, Mateusz Guzik wrote: > > > > On Sat, Mar 21, 2015 at 03:51:51AM +0200, Konstantin Belousov wrote: > > > > > On Sat, Mar 21, 2015 at 02:00:38AM +0100, Mateusz Guzik wrote: > > > > > > From: Mateusz Guzik > > > > > > > > > > > > Prior to this change the kernel would take p1's credentials and assign > > > > > > them tempororarily to p2. But p1 could change credentials at that time > > > > > > and in effect give us a use-after-free. > > > > > In which way could it change the credentials ? The assigned credentials > > > > > are taken from td_ucred, which, I thought, are guaranteed to be stable > > > > > for the duration of a syscall. > > > > > > > > > > > > > It takes thread's credential in do_fork. But initial copy is taken > > > > unlocked from struct proc. > > > > > > > > Relevant part of the diff: > > > > > > @@ -870,7 +867,7 @@ fork1(struct thread *td, int flags, int pages, struct proc **procp, > > > > > > * XXX: This is ugly; when we copy resource usage, we need to bump > > > > > > * per-cred resource counters. > > > > > > */ > > > > > > - proc_set_cred(newproc, p1->p_ucred); > > > > > > + proc_set_cred(newproc, crhold(td->td_ucred)); > > > > > > > > > > > > I do not understand your note, nor I see the chunk above in the patches > > > you send. Below is the citation from the patch 1: > > > > > > @@ -410,9 +410,6 @@ do_fork(struct thread *td, int flags, struct proc *p2, > > > +struct thread *td2, > > > bzero(&p2->p_startzero, > > > __rangeof(struct proc, p_startzero, p_endzero)); > > > > > > - crhold(td->td_ucred); > > > - proc_set_cred(p2, td->td_ucred); > > > - > > > > fork1 does: > > > > proc_set_cred(newproc, p1->p_ucred); > > > > p1 is unlocked, so whatever memory p1->p_ucred points to may already be > > freed. > > > > /* > > * Initialize resource accounting for the child process. > > */ > > error = racct_proc_fork(p1, newproc); > > if (error != 0) { > > error = EAGAIN; > > goto fail1; > > } > > > > racct_proc_fork -> racct_add_locked results in accessing such > > now-possibly-freed credentials. > > > > do_fork which properly assigns credentials (from a stable source > > (td_ucred) + grabs a reference) is called later. > > > > The patch in question moves aforementioned assignent earlier to replace > > unsafe one with p1->p_ucred. > > It seems that I understand now. > > If you instead assign td->td_ucred for the new process p_ucred temporary, > would it allow to avoid introducing fail2 label ? I dislike even more > contrived cleanup after the patch. Yes but that seems like a hack awaiting for someone to trip over. For instance I would say it would be desirable to move stuff like freeing credentials into zone destructor handler. A hack like this would leave us with an extra crfree. Doing this work would require some care and making sure we have garbage only where we can afford it and I'm not interested in dealing with this right now. So tl;dr I strongly prefer the patch as it is. -- Mateusz Guzik From owner-freebsd-current@FreeBSD.ORG Sat Mar 21 20:14:43 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C866052C for ; Sat, 21 Mar 2015 20:14:43 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id AA3B3612 for ; Sat, 21 Mar 2015 20:14:43 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id D65E74F8 for ; Sat, 21 Mar 2015 20:14:43 +0000 (UTC) Date: Sat, 21 Mar 2015 20:14:43 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <2120073707.9.1426968883741.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1839238505.8.1426954913275.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1839238505.8.1426954913275.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD-tests2 #862 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Mar 2015 20:14:43 -0000 See ------------------------------------------ [...truncated 1411 lines...] lib/libc/string/strspn:strspn -> passed [0.013s] lib/libc/string/swab:swab_basic -> passed [0.012s] lib/libc/sys/access_test:access_access -> passed [0.019s] lib/libc/sys/access_test:access_fault -> passed [0.014s] lib/libc/sys/access_test:access_inval -> passed [0.015s] lib/libc/sys/access_test:access_notdir -> passed [0.015s] lib/libc/sys/access_test:access_notexist -> passed [0.014s] lib/libc/sys/access_test:access_toolong -> passed [0.015s] lib/libc/sys/chroot_test:chroot_basic -> passed [0.709s] lib/libc/sys/chroot_test:chroot_err -> passed [0.015s] lib/libc/sys/chroot_test:chroot_perm -> passed [0.016s] lib/libc/sys/clock_gettime_test:clock_gettime_real -> passed [0.016s] lib/libc/sys/connect_test:connect_low_port -> passed [0.014s] lib/libc/sys/dup_test:dup2_basic -> passed [0.015s] lib/libc/sys/dup_test:dup2_err -> passed [0.013s] lib/libc/sys/dup_test:dup2_max -> passed [0.013s] lib/libc/sys/dup_test:dup2_mode -> passed [0.031s] lib/libc/sys/dup_test:dup3_err -> passed [0.016s] lib/libc/sys/dup_test:dup3_max -> passed [0.015s] lib/libc/sys/dup_test:dup3_mode -> passed [0.033s] lib/libc/sys/dup_test:dup_err -> passed [0.015s] lib/libc/sys/dup_test:dup_max -> passed [0.019s] lib/libc/sys/dup_test:dup_mode -> passed [0.032s] lib/libc/sys/fsync_test:fsync_err -> passed [0.014s] lib/libc/sys/fsync_test:fsync_sync -> passed [0.248s] lib/libc/sys/getcontext_test:getcontext_err -> passed [0.015s] lib/libc/sys/getcontext_test:setcontext_err -> passed [0.015s] lib/libc/sys/getcontext_test:setcontext_link -> passed [0.015s] lib/libc/sys/getgroups_test:getgroups_err -> expected_failure: Reported as kern/189941: /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/sys/t_getgroups.c:63: getgroups(-1, gidset) == -1 not met [0.015s] lib/libc/sys/getgroups_test:getgroups_getgid -> passed [0.015s] lib/libc/sys/getgroups_test:getgroups_setgid -> passed [0.016s] lib/libc/sys/getgroups_test:getgroups_zero -> passed [0.015s] lib/libc/sys/getitimer_test:getitimer_empty -> passed [0.015s] lib/libc/sys/getitimer_test:getitimer_err -> passed [0.014s] lib/libc/sys/getitimer_test:setitimer_basic -> passed [0.014s] lib/libc/sys/getitimer_test:setitimer_err -> passed [0.016s] lib/libc/sys/getitimer_test:setitimer_old -> passed [0.015s] lib/libc/sys/getlogin_test:getlogin_r_err -> passed [0.015s] lib/libc/sys/getlogin_test:getlogin_same -> passed [0.015s] lib/libc/sys/getlogin_test:setlogin_basic -> passed [0.016s] lib/libc/sys/getlogin_test:setlogin_err -> passed [0.016s] lib/libc/sys/getlogin_test:setlogin_perm -> passed [0.016s] lib/libc/sys/getpid_test:getpid_process -> passed [0.023s] lib/libc/sys/getpid_test:getpid_thread -> passed [0.018s] lib/libc/sys/getrusage_test:getrusage_err -> passed [0.015s] lib/libc/sys/getrusage_test:getrusage_sig -> passed [0.015s] lib/libc/sys/getrusage_test:getrusage_utime_back -> passed [2.130s] lib/libc/sys/getrusage_test:getrusage_utime_zero -> skipped: this testcase passes/fails sporadically on FreeBSD/i386 @ r273153 (at least) [0.015s] lib/libc/sys/getsid_test:getsid_current -> passed [0.015s] lib/libc/sys/getsid_test:getsid_err -> passed [0.015s] lib/libc/sys/getsid_test:getsid_process -> passed [0.015s] lib/libc/sys/gettimeofday_test:gettimeofday_err -> passed [0.015s] lib/libc/sys/gettimeofday_test:gettimeofday_mono -> passed [0.017s] lib/libc/sys/issetugid_test:issetugid_egid -> passed [0.017s] lib/libc/sys/issetugid_test:issetugid_euid -> passed [0.017s] lib/libc/sys/issetugid_test:issetugid_rgid -> passed [0.017s] lib/libc/sys/issetugid_test:issetugid_ruid -> passed [0.017s] lib/libc/sys/kevent_test:kevent_zerotimer -> passed [0.016s] lib/libc/sys/kevent_test:kqueue_desc_passing -> passed [0.017s] lib/libc/sys/kevent_test:kqueue_unsupported_fd -> skipped: no /nonexistent available for testing [0.015s] lib/libc/sys/kill_test:kill_basic -> passed [0.017s] lib/libc/sys/kill_test:kill_err -> passed [0.015s] lib/libc/sys/kill_test:kill_perm -> passed [1.019s] lib/libc/sys/kill_test:kill_pgrp_neg -> passed [0.016s] lib/libc/sys/kill_test:kill_pgrp_zero -> passed [0.017s] lib/libc/sys/link_test:link_count -> passed [0.020s] lib/libc/sys/link_test:link_err -> passed [0.020s] lib/libc/sys/link_test:link_perm -> passed [0.015s] lib/libc/sys/link_test:link_stat -> passed [0.018s] lib/libc/sys/listen_test:listen_err -> passed [0.019s] lib/libc/sys/listen_test:listen_low_port -> passed [0.015s] lib/libc/sys/mincore_test:mincore_err -> passed [0.015s] lib/libc/sys/mincore_test:mincore_resid -> passed [0.035s] lib/libc/sys/mincore_test:mincore_shmseg -> passed [0.016s] lib/libc/sys/mkdir_test:mkdir_err -> passed [0.015s] lib/libc/sys/mkdir_test:mkdir_mode -> passed [1.091s] lib/libc/sys/mkdir_test:mkdir_perm -> passed [0.019s] lib/libc/sys/mkdir_test:mkdir_trail -> passed [0.033s] lib/libc/sys/mkfifo_test:mkfifo_block -> passed [1.086s] lib/libc/sys/mkfifo_test:mkfifo_err -> passed [0.022s] lib/libc/sys/mkfifo_test:mkfifo_nonblock -> passed [1.094s] lib/libc/sys/mkfifo_test:mkfifo_perm -> passed [0.023s] lib/libc/sys/mkfifo_test:mkfifo_stat -> passed [0.020s] lib/libc/sys/mknod_test:mknod_err -> passed [0.020s] lib/libc/sys/mknod_test:mknod_exist -> passed [0.020s] lib/libc/sys/mknod_test:mknod_perm -> passed [0.019s] lib/libc/sys/mknod_test:mknod_stat -> expected_failure: mknod does not allow S_IFREG: /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/sys/t_mknod.c:179: mknod(path, S_IFREG, 0) == 0 not met [0.022s] lib/libc/sys/mlock_test:mlock_clip -> passed [0.016s] lib/libc/sys/mlock_test:mlock_err -> passed [0.017s] lib/libc/sys/mlock_test:mlock_limits -> passed [0.018s] lib/libc/sys/mlock_test:mlock_mmap -> passed [0.016s] lib/libc/sys/mlock_test:mlock_nested -> passed [0.016s] lib/libc/sys/mmap_test:mmap_err -> passed [0.015s] lib/libc/sys/mmap_test:mmap_loan -> passed [0.020s] lib/libc/sys/mmap_test:mmap_prot_1 -> passed [0.021s] lib/libc/sys/mmap_test:mmap_prot_2 -> passed [0.016s] lib/libc/sys/mmap_test:mmap_prot_3 -> passed [0.020s] lib/libc/sys/mmap_test:mmap_truncate -> passed [0.069s] lib/libc/sys/mmap_test:mmap_va0 -> passed [0.017s] lib/libc/sys/mprotect_test:mprotect_access -> passed [0.020s] lib/libc/sys/mprotect_test:mprotect_err -> passed [0.016s] lib/libc/sys/mprotect_test:mprotect_pax -> passed [0.015s] lib/libc/sys/mprotect_test:mprotect_write -> passed [0.016s] lib/libc/sys/msgctl_test:msgctl_err -> passed [0.059s] lib/libc/sys/msgctl_test:msgctl_perm -> passed [0.082s] lib/libc/sys/msgctl_test:msgctl_pid -> passed [2.218s] lib/libc/sys/msgctl_test:msgctl_set -> passed [0.047s] lib/libc/sys/msgctl_test:msgctl_time -> passed [0.030s] lib/libc/sys/msgget_test:msgget_excl -> passed [0.033s] lib/libc/sys/msgget_test:msgget_exit -> passed [0.051s] lib/libc/sys/msgget_test:msgget_init -> passed [0.075s] lib/libc/sys/msgget_test:msgget_limit -> passed [0.058s] lib/libc/sys/msgget_test:msgget_mode -> passed [0.047s] lib/libc/sys/msgrcv_test:msgrcv_basic -> passed [0.067s] lib/libc/sys/msgrcv_test:msgrcv_block -> passed [2.157s] lib/libc/sys/msgrcv_test:msgrcv_err -> passed [0.078s] lib/libc/sys/msgrcv_test:msgrcv_mtype -> passed [0.057s] lib/libc/sys/msgrcv_test:msgrcv_nonblock -> passed [2.124s] lib/libc/sys/msgrcv_test:msgrcv_truncate -> passed [0.030s] lib/libc/sys/msgsnd_test:msgsnd_block -> passed [2.067s] lib/libc/sys/msgsnd_test:msgsnd_count -> passed [0.062s] lib/libc/sys/msgsnd_test:msgsnd_err -> passed [0.038s] lib/libc/sys/msgsnd_test:msgsnd_nonblock -> passed [2.058s] lib/libc/sys/msgsnd_test:msgsnd_perm -> passed [0.045s] lib/libc/sys/msync_test:msync_async -> passed [0.020s] lib/libc/sys/msync_test:msync_err -> passed [0.024s] lib/libc/sys/msync_test:msync_invalidate -> passed [0.019s] lib/libc/sys/msync_test:msync_sync -> passed [0.019s] lib/libc/sys/nanosleep_test:nanosleep_basic -> passed [0.016s] lib/libc/sys/nanosleep_test:nanosleep_err -> passed [0.016s] lib/libc/sys/nanosleep_test:nanosleep_sig -> passed [1.031s] lib/libc/sys/pipe_test:pipe_restart -> passed [2.064s] lib/libc/sys/pipe2_test:pipe2_basic -> passed [0.016s] lib/libc/sys/pipe2_test:pipe2_cloexec -> passed [0.015s] lib/libc/sys/pipe2_test:pipe2_consume -> passed [0.016s] lib/libc/sys/pipe2_test:pipe2_einval -> passed [0.015s] lib/libc/sys/pipe2_test:pipe2_nonblock -> passed [0.016s] lib/libc/sys/poll_test:poll_3way -> passed [10.052s] lib/libc/sys/poll_test:poll_basic -> passed [0.018s] lib/libc/sys/poll_test:poll_err -> passed [0.015s] lib/libc/sys/revoke_test:revoke_basic -> skipped: revoke(2) is only implemented for devfs(5). [0.018s] lib/libc/sys/revoke_test:revoke_err -> skipped: revoke(2) is only implemented for devfs(5). [0.015s] lib/libc/sys/revoke_test:revoke_perm -> skipped: revoke(2) is only implemented for devfs(5). [0.018s] lib/libc/sys/select_test:pselect_sigmask -> passed [1.050s] lib/libc/sys/select_test:pselect_timeout -> passed [0.016s] lib/libc/sys/setrlimit_test:setrlimit_basic -> passed [0.016s] lib/libc/sys/setrlimit_test:setrlimit_current -> passed [0.015s] lib/libc/sys/setrlimit_test:setrlimit_err -> passed [0.015s] lib/libc/sys/setrlimit_test:setrlimit_fsize -> passed [0.022s] lib/libc/sys/setrlimit_test:setrlimit_memlock -> passed [0.017s] lib/libc/sys/setrlimit_test:setrlimit_nofile_1 -> passed [0.017s] lib/libc/sys/setrlimit_test:setrlimit_nofile_2 -> passed [0.017s] lib/libc/sys/setrlimit_test:setrlimit_nproc -> maxproc limit exceeded by uid 977 (pid 31459); see tuning(7) and login.conf(5) passed [0.561s] lib/libc/sys/setrlimit_test:setrlimit_perm -> panic: mutex process lock not owned at /builds/FreeBSD_HEAD/sys/kern/kern_prot.c:1974 cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00974408e0 vpanic() at vpanic+0x189/frame 0xfffffe0097440960 panic() at panic+0x43/frame 0xfffffe00974409c0 __mtx_assert() at __mtx_assert+0xc2/frame 0xfffffe00974409d0 proc_set_cred() at proc_set_cred+0x36/frame 0xfffffe00974409f0 fork1() at fork1+0x27e/frame 0xfffffe0097440ac0 sys_fork() at sys_fork+0x1f/frame 0xfffffe0097440ae0 amd64_syscall() at amd64_syscall+0x27f/frame 0xfffffe0097440bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0097440bf0 --- syscall (0, FreeBSD ELF64, nosys), rip = 0x8019c516a, rsp = 0x7fffffffc2d8, rbp = 0x7fffffffc340 --- KDB: enter: panic [ thread pid 660 tid 100047 ] Stopped at kdb_enter+0x3e: movq $0,kdb_why db> Traceback (most recent call last): File "/vm/freebsd-ci/scripts/test/run-tests.py", line 152, in main(sys.argv) File "/vm/freebsd-ci/scripts/test/run-tests.py", line 80, in main runTest() File "/vm/freebsd-ci/scripts/test/run-tests.py", line 124, in runTest child2.expect(prompt, timeout=7200) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1451, in expect timeout, searchwindowsize) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1466, in expect_list timeout, searchwindowsize) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1568, in expect_loop raise TIMEOUT(str(err) + '\n' + str(self)) pexpect.TIMEOUT: Timeout exceeded. version: 3.3 command: /usr/sbin/bhyve args: [u'/usr/sbin/bhyve', u'-c', u'2', u'-m', u'2G', u'-AI', u'-H', u'-P', u'-g', u'0', u'-s', u'0:0,hostbridge', u'-s', u'1:0,lpc', u'-s', u'2:0,virtio-net,tap0,mac=58:9c:fc:00:00:2e', u'-s', u'3:0,ahci-hd,/net/jenkins-10.freebsd.org/builds/Build-UFS-image/image/FreeBSD_HEAD/test.img', u'-l', u'com1,stdio', u'vm_test'] searcher: buffer (last 100 chars): 'nter: panic\r\n[ thread pid 660 tid 100047 ]\r\nStopped at kdb_enter+0x3e: movq $0,kdb_why\r\ndb> ' before (last 100 chars): 'nter: panic\r\n[ thread pid 660 tid 100047 ]\r\nStopped at kdb_enter+0x3e: movq $0,kdb_why\r\ndb> ' after: match: None match_index: None exitstatus: None flag_eof: False pid: 84523 child_fd: 4 closed: False timeout: 30 delimiter: logfile: ', mode 'w' at 0x800670150> logfile_read: None logfile_send: None maxread: 2000 ignorecase: False searchwindowsize: None delaybeforesend: 0.05 delayafterclose: 0.1 delayafterterminate: 0.1 Build step 'Execute shell' marked build as failure Recording test results ERROR: Publisher hudson.tasks.junit.JUnitResultArchiver aborted due to exception hudson.AbortException: Test reports were found but none of them are new. Did tests run? For example, is 6 days 18 hr old at hudson.tasks.junit.TestResult.parse(TestResult.java:178) at hudson.tasks.junit.TestResult.parse(TestResult.java:146) at hudson.tasks.junit.TestResult.(TestResult.java:122) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:119) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:92) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2688) at hudson.remoting.UserRequest.perform(UserRequest.java:121) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at hudson.remoting.Request$2.run(Request.java:324) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) at ......remote call to havoc.ysv.freebsd.org(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1356) at hudson.remoting.UserResponse.retrieve(UserRequest.java:221) at hudson.remoting.Channel.call(Channel.java:752) at hudson.FilePath.act(FilePath.java:978) at hudson.FilePath.act(FilePath.java:967) at hudson.tasks.junit.JUnitParser.parseResult(JUnitParser.java:89) at hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:120) at hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:137) at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:74) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:761) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:721) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:670) at hudson.model.Run.execute(Run.java:1775) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240) From owner-freebsd-current@FreeBSD.ORG Sat Mar 21 20:26:54 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0EE86AF9; Sat, 21 Mar 2015 20:26:54 +0000 (UTC) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::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 8E64379E; Sat, 21 Mar 2015 20:26:53 +0000 (UTC) Received: by wegp1 with SMTP id p1so107211603weg.1; Sat, 21 Mar 2015 13:26: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:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=LfHc8YplR6rAgK7Gs0nmOJXclsxRz/bVqqObbhhO8mg=; b=1F3ATCLYt2tbw48bz9S0FpLlZMXtgUr94/NeOb2bvansdOR+X+QcYKgG9em6lf0MOJ 3+Hc1zYQGUP6OZ2ohmVSuRroeabTg2fHxWYI6KIzQrHmiOYed6nsvlSe9Tcvtcva66RD Tol6MjA3hYl6f9kpo/m8sq/u755dQ3AFYUu5taAMSB6tnNTWPNrW0IPnz0rGeNQVlVxm K0jxTHjKq2h7l/n4AG2c6+sHlRRy9irTY4LdYsl/Q5X0UWJfLgVSx4dAbbr5S3uZesJj megvWQHqmbfUxB2r1VDuO0cFKgn+VGtxU4PEvQz1oqDIAGbPVdEUetUgTO1QwpoMkZYf Kr6w== X-Received: by 10.194.94.1 with SMTP id cy1mr168223306wjb.127.1426969612028; Sat, 21 Mar 2015 13:26:52 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id n3sm12009186wja.36.2015.03.21.13.26.50 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 21 Mar 2015 13:26:51 -0700 (PDT) Date: Sat, 21 Mar 2015 21:26:48 +0100 From: Mateusz Guzik To: jenkins-admin@freebsd.org Subject: Re: Build failed in Jenkins: FreeBSD_HEAD-tests2 #862 Message-ID: <20150321202648.GD14650@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , jenkins-admin@freebsd.org, freebsd-current@freebsd.org References: <1839238505.8.1426954913275.JavaMail.jenkins@jenkins-9.freebsd.org> <2120073707.9.1426968883741.JavaMail.jenkins@jenkins-9.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <2120073707.9.1426968883741.JavaMail.jenkins@jenkins-9.freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Mar 2015 20:26:54 -0000 On Sat, Mar 21, 2015 at 08:14:43PM +0000, jenkins-admin@freebsd.org wrote: > lib/libc/sys/setrlimit_test:setrlimit_nproc -> maxproc limit exceeded by uid 977 (pid 31459); see tuning(7) and login.conf(5) > passed [0.561s] > lib/libc/sys/setrlimit_test:setrlimit_perm -> panic: mutex process lock not owned at /builds/FreeBSD_HEAD/sys/kern/kern_prot.c:1974 > cpuid = 1 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00974408e0 > vpanic() at vpanic+0x189/frame 0xfffffe0097440960 > panic() at panic+0x43/frame 0xfffffe00974409c0 > __mtx_assert() at __mtx_assert+0xc2/frame 0xfffffe00974409d0 > proc_set_cred() at proc_set_cred+0x36/frame 0xfffffe00974409f0 > fork1() at fork1+0x27e/frame 0xfffffe0097440ac0 > sys_fork() at sys_fork+0x1f/frame 0xfffffe0097440ae0 > amd64_syscall() at amd64_syscall+0x27f/frame 0xfffffe0097440bf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0097440bf0 > --- syscall (0, FreeBSD ELF64, nosys), rip = 0x8019c516a, rsp = 0x7fffffffc2d8, rbp = 0x7fffffffc340 --- Should be fixed starting with https://svnweb.freebsd.org/changeset/base/280331 -- Mateusz Guzik From owner-freebsd-current@FreeBSD.ORG Sat Mar 21 21:31:16 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D975CAD1; Sat, 21 Mar 2015 21:31:16 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 4A5DBDC9; Sat, 21 Mar 2015 21:31:16 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t2LLV704031123 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 21 Mar 2015 23:31:07 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t2LLV704031123 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t2LLV76Z031120; Sat, 21 Mar 2015 23:31:07 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 21 Mar 2015 23:31:07 +0200 From: Konstantin Belousov To: "Ivan A. Kosarev" Subject: Re: Use of chunksize before initialization Message-ID: <20150321213106.GV2379@kib.kiev.ua> References: <550C27D8.2010105@ivan-labs.com> <20150321010218.GD2379@kib.kiev.ua> <550D37DA.7060105@ivan-labs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <550D37DA.7060105@ivan-labs.com> User-Agent: Mutt/1.5.23 (2014-03-12) 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.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-current@freebsd.org, Ed Maste X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Mar 2015 21:31:16 -0000 On Sat, Mar 21, 2015 at 11:20:26AM +0200, Ivan A. Kosarev wrote: > > On 03/21/2015 03:02 AM, Konstantin Belousov wrote: > > On Fri, Mar 20, 2015 at 03:59:52PM +0200, Ivan A. Kosarev wrote: > >> #12 0x00000008011b428d in malloc_init_hard () at jemalloc_jemalloc.c:698 > >> #13 malloc_init () at jemalloc_jemalloc.c:296 > >> #14 0x0000000801243ea2 in ?? () from /lib/libc.so.7 > >> #15 0x00000008006a5400 in ?? () > >> #16 0x000000080089e5b0 in ?? () from /libexec/ld-elf.so.1 > >> #17 0x00007fffffffe0b0 in ?? () > >> #18 0x0000000801139d06 in _init () from /lib/libc.so.7 > >> #19 0x00007fffffffe0b0 in ?? () > > The backtrace is strange. Did you compiled malloc with the debugging > > symbols, while keep rest of libc without -g ? > > I've just added the -g flag to CC_FLAGS in the Makefile and made sure to > install an unstripped version of the .so . I could investigate more on > why the early calls omit debug symbols, if it does any matter. I want to understand at what stage of the initialization the access happens. This is why I want to see the complete backtrace. From owner-freebsd-current@FreeBSD.ORG Sat Mar 21 22:13:15 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EAC1736F for ; Sat, 21 Mar 2015 22:13:15 +0000 (UTC) Received: from frv158.fwdcdn.com (frv158.fwdcdn.com [212.42.77.158]) (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 ABE22169 for ; Sat, 21 Mar 2015 22:13:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=FhIMziWKlJaJDN7Sz7ZKyKknMz2tfNQ+jbWLKDjMMIs=; b=tf0z75KnxLvgrWkqwe3kwnfrNXs5JA0/BOX3e4EYa9Q4G6yLkFP9T75TlKpHPPibo79m3A+68ILI7JvOS4LDm8/l0ncfHhuFM3PD93NIHGibcth5rg/hpMwy+otQlR+G4P4DunQShONZtru+obgtNPQfLjmV/h+hQO3JoXfmJKQ=; Received: from [46.211.113.164] (helo=nonamehost.local) by frv158.fwdcdn.com with esmtpsa ID 1YZRdn-000GK5-VE for current@freebsd.org; Sun, 22 Mar 2015 00:13:12 +0200 Date: Sun, 22 Mar 2015 00:13:11 +0200 From: Ivan Klymenko To: current@freebsd.org Subject: >r280312 - r280332 VirtualBox is broken. Message-ID: <20150322001311.34994231@nonamehost.local> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Authentication-Result: IP=46.211.113.164; mail.from=fidaj@ukr.net; dkim=pass; header.d=ukr.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Mar 2015 22:13:16 -0000 After auditing the r280312 I just upgraded to revision r280332 and then discovered that my VirtualBox is broken. Thanks.