From owner-freebsd-current@freebsd.org Sun Jan 17 14:14:26 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6CFABA864DB for ; Sun, 17 Jan 2016 14:14:26 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 137C81FB8 for ; Sun, 17 Jan 2016 14:14:25 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: by mail-vk0-x22e.google.com with SMTP id i129so181793987vkb.0 for ; Sun, 17 Jan 2016 06:14:25 -0800 (PST) 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=ZBEa9Gy06jhtyzwI8tQWAeuK7+EsJSqFMWrHRP1lr7w=; b=EzfkMyvRd7rWmIxlgxVGt4sER9YJOl9taHaHX0t+3ZR3w+vUW5L4JlGznFeT5dhonJ 2j9WBKkszTOz8x8tE7It0TBkRScqPElm4IJ4NIchFT+mcXBHi822OGQ6mfG3kD+mi4EK SrZLJNJ3u2kXc2LX6PxpBz+6ecn18X3Ia/mCgvvjGqQ1urhUHrYOxQNb1oTz58ARvEb3 4JJEi1l5i/NTsKfpWR5ru0f/QMAOCRpQGHUxfsjspNSKrFJibI5qYv9s7VNO+nSwHSXl aaggDBjUZd6oTgRObJscDXh4dDbfDFHbwv8Eqhrdbjs6UoDQGkfO091aPeTMbAVOuu3U 9E/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=ZBEa9Gy06jhtyzwI8tQWAeuK7+EsJSqFMWrHRP1lr7w=; b=KlwGjtV5+KZj3KoYfrfTaAPMlkQkN6u681GaxpOalNojW3b+6R3VozoArasi4rFpwK aUukj0tMq8diPen1wZK5JyoCRI+vNVRAHMBudjSgNgPf1QRlE9o4E7FFFxqqrkHGES5O fThHJPkrs426iDCPnl8Z4ABmJGtQr9HpJK3EJo4xAYliSZCEMG8rk2eNX4tz7ccUZNuF FqUUEykowl3jNNXepfH7ZfbkuGpsuCypLSjpKlhZOcsvaq4Q9r4Ha0tnJFChIZH8P3DX wQeIApjFtoBDs8mKFm787rwlWuMv7H4LXVYT0iS5O5owQJ4FzlfCQUcaqqgOlpPPuj7g QKew== X-Gm-Message-State: ALoCoQlFfkdZMYszIAyfZSWDqZbXYSDMKgwvbaS55zmr9nRNbLjUzR8WlF3NM5WBz7c6BC7iDsp8h17nwgugwRxQ/rqd1A04Wg== MIME-Version: 1.0 X-Received: by 10.31.130.199 with SMTP id e190mr12915005vkd.49.1453040063981; Sun, 17 Jan 2016 06:14:23 -0800 (PST) Received: by 10.31.76.133 with HTTP; Sun, 17 Jan 2016 06:14:23 -0800 (PST) Date: Sun, 17 Jan 2016 09:14:23 -0500 Message-ID: Subject: r294195: Kernel panic during installworld From: Ultima To: freebsd-current@freebsd.org X-Mailman-Approved-At: Sun, 17 Jan 2016 14:20:14 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2016 14:14:26 -0000 make installkernel KERNCONF=MYKERNEL reboot mergemaster -p make installworld -> attached MYKERNEL=GENERIC+ options VIMAGE options ROUTETABLES=2 Anything else that maybe helpful? Ultima From owner-freebsd-current@freebsd.org Sun Jan 17 15:02:28 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 69555A8582A for ; Sun, 17 Jan 2016 15:02:28 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0: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 24CD81E13 for ; Sun, 17 Jan 2016 15:02:28 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: by mail-vk0-x235.google.com with SMTP id i129so182080102vkb.0 for ; Sun, 17 Jan 2016 07:02:28 -0800 (PST) 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=BdKgc2bJmNYuYeIffT0ORbtIBkBemRPKQMW/mBfoqic=; b=aKsM8CFG5UIz0tyEPpNeVdNQp19MYHXzvF57tU57pMFey6ALTKiIBuSJpV1fbuf+oh p1prknffpH2CZDib2nDBdWmjDPHBAImjtO0BAmPC2bbz0qGiNWj8ygWPM4dEl7SER4W3 ivA7jeMlWvQjWib43/3zpRbK71p1YEdANbiRtNa/bpaYavBC3LZbeC//cFN7ST2TRtiL xH6qHiR//tGdfbSkUFK5ThpJHCzvvJcQYv5ArmkCZECPJx7iLb1LC3t15tOsaxjeI9Tn n7ZhNtbP8LaMqg/nt4IGZYUwMFoTey/yt05f2T4Wf7O0ARt+YmGf5F4aR6VdjxLD8llf xozg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BdKgc2bJmNYuYeIffT0ORbtIBkBemRPKQMW/mBfoqic=; b=ZNujnI8cbce7prtbAdxkwxl08wld2Fg4UtR6gXfa9FyCdDk/1RXIPyntZCdtwRWgNg fZyU63fEr2e1hXJy0z8EML8iw85kMQwXRIYT8I8vUhY1EpXqbQeLo85+++Z/oX9tw/Hf GHgpHboC2gaiOLj99ngGdN5yTfyDdy7k6dBpsTdMT/CNe1nLddulDhS2MfGVavrI6Epp 1vQmzOGHGKafSpawhEjgJdiq93n24tQKllDneLEbCYwHU5i5gMa5VOFQZ3A7uD5IwGLU zMSpHcYZrvOC5jtajGbbfPrBW2OpyVf43VGYuYbH24HaqIp26ieBeMa5i2Gg/rG9KB3P /vZg== X-Gm-Message-State: ALoCoQmk0vHZ/kPeBTnKgCXp16OirYO0Cpzs1L512Clm2qgurws65Dsf53kPl985mdO7zRl5vzk8h0GD9uXRhM+eFaKhRBjGlg== MIME-Version: 1.0 X-Received: by 10.31.58.74 with SMTP id h71mr14491050vka.151.1453042947296; Sun, 17 Jan 2016 07:02:27 -0800 (PST) Received: by 10.31.194.14 with HTTP; Sun, 17 Jan 2016 07:02:27 -0800 (PST) In-Reply-To: <20160117144542.GB46096@home.opsec.eu> References: <20160117144542.GB46096@home.opsec.eu> Date: Sun, 17 Jan 2016 10:02:27 -0500 Message-ID: Subject: Re: r294195: Kernel panic during installworld From: Ultima To: Kurt Jaeger Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2016 15:02:28 -0000 It builds fine, the issue is installing it. I think the panic is zfs related not actually installworld. On Sun, Jan 17, 2016 at 9:45 AM, Kurt Jaeger wrote: > Hi! > > > make installkernel KERNCONF=MYKERNEL > > reboot > > mergemaster -p > > make installworld -> attached > > > > MYKERNEL=GENERIC+ > > options VIMAGE > > options ROUTETABLES=2 > > > > Anything else that maybe helpful? > > I build a generic world at r294095, no problems. > > -- > pi@opsec.eu +49 171 3101372 4 years to > go ! > From owner-freebsd-current@freebsd.org Sun Jan 17 17:59:17 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2BAEEA862CB for ; Sun, 17 Jan 2016 17:59:17 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) by mx1.freebsd.org (Postfix) with ESMTP id 0E8E518C4 for ; Sun, 17 Jan 2016 17:59:16 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [10.1.1.2]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 646D3DA77 for ; Sun, 17 Jan 2016 17:59:15 +0000 (UTC) Subject: Re: r294195: Kernel panic during installworld To: freebsd-current@freebsd.org References: From: Allan Jude Message-ID: <569BD681.80608@freebsd.org> Date: Sun, 17 Jan 2016 12:59:29 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xvxAvDRkXRBNO9Ho2eDIWhGxprPMiP7D1" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2016 17:59:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xvxAvDRkXRBNO9Ho2eDIWhGxprPMiP7D1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2016-01-17 09:14, Ultima wrote: > make installkernel KERNCONF=3DMYKERNEL > reboot > mergemaster -p > make installworld -> attached >=20 > MYKERNEL=3DGENERIC+ > options VIMAGE > options ROUTETABLES=3D2 >=20 > Anything else that maybe helpful? >=20 > Ultima > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 Your attachment was stripped. Can you post it somewhere and include the u= rl? --=20 Allan Jude --xvxAvDRkXRBNO9Ho2eDIWhGxprPMiP7D1 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) iQIcBAEBAgAGBQJWm9aFAAoJEBmVNT4SmAt+5yAP/2ZrqTAcfc9pFNuSZZ7GMBip jTJPT+AdwXiS8hPU5uCj6tb6rzZ6Jyey1hOzUiUfKMce5KUKiY14pz/vYOpi8KNh c5Nsidc4XCReccFfDOUDSCzTJEDzyjlEZg3nTTemSUt5a9BZRPJrnLf4gDHHskq2 KWjUq6q0IYz3M4qhy+Vi1EzwcKieGlXH/su0szik58cjW9y/VhtQjS3ngLQtljbX MEexo01vjUYPDo28NJu0qf6GZdXHcDtyq4bt2d7DvqYj1z5cAf2GB3t2xWJx8RRs niRNX4NcPBoh4zijcQBBzMuTfrngFLV+oaFLkpWpz7isbuRzfDziQ/3S+fKhSTfX dw5BlGqm+istoM4HvdUWtMQI2oASG4WewlxVl5RnORzjRhxal11PoPaKgtBGN5Fw xLuICWnZ9jKksUeoMly7py/12JVoE8jGIIPOwlDZLQuCh1rEg/wsKKPDlb7xpLDS oUFIuGbxNJZlvdDwnWR3ggY///If69r2pSOMGPPxUae6VARUt3s0/oQLbnd/qFJp RP9F06mfj64eYI6u/WoEtgE0wKeoQRoTFLEbCMVECCkHAXAPWLHsLCd6mGyQzWUF HQ0+X3W1njiqzwxvWmPpOJwWAD/wNVeFs74IywvXJqRTa46kRmj48SqLg6lVK8WZ Em2bZjA+TsJKXW7cumJj =kzL1 -----END PGP SIGNATURE----- --xvxAvDRkXRBNO9Ho2eDIWhGxprPMiP7D1-- From owner-freebsd-current@freebsd.org Sun Jan 17 19:59:44 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E3721A86B02 for ; Sun, 17 Jan 2016 19:59:44 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c: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 96337164D for ; Sun, 17 Jan 2016 19:59:44 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: by mail-vk0-x233.google.com with SMTP id k1so322112173vkb.2 for ; Sun, 17 Jan 2016 11:59:44 -0800 (PST) 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 :content-type; bh=x4CcKrQYawDdxUT6lXS0/yl506vNFjmphQiXjkTmzvg=; b=a19v6WTF7UQmfVgla+PasH5E02pka277gvIzvZ3wbEeZm3m4VNaZCeLiElHEFoje0K 8Zw+/pjuTlYNyrB6kA+QumMmq56gHI7kkHF8GAj4Hz1ROYq4vbK3oTexuG8BetrQ1OJ/ MhvfZNs0ikJSsGKVxQ+emsnzkWAQPysVxbwFNLKNMvfWZfxttYzdOv3+9GWK7k/czS9y QbfRTmq5vSG0+baG6BA1BNBOp7DZgSQPy6aOgZoqw+3pwyR4355wrmg6Oi80vjO1pPQy pyDLkYm1iL/+d++NqYIq92ZrdPNI2stoZscWLfmrV+paaNbEwgTv9EtFBmri45LPOhyC J0dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=x4CcKrQYawDdxUT6lXS0/yl506vNFjmphQiXjkTmzvg=; b=QCZVM/yQ8iHT+lcImcqiZm1e/lAq4NQ9E84megV4jMq5Js/ARgy+nwAJ0dxEY4vUJ6 WVyssEndTrlU16iWu1iDZI7+q3D55rIeNBzVEos5q9b2I/4z+DFjsPQQ8CdjPmiT2i2n gxsQxx0sOsBh+HkEmc+kQL3e1WUqdakUCF+L+rRFfyg+ZXkOMHuX1c+A6MO79t7zb2BZ zCot1H0fgT93JDcSYQLZSiNB8quti/OiH0gZUYfqNX1XQEVmn01yCT1ym6rr4Ay5mXYf GiSXtEOHUZVcBmGljsp3wnBBRf5sRreFRk0WXnkIrMi+2XtQkKLfrn8O9BcVl46+Eftj MbFA== X-Gm-Message-State: ALoCoQnpDrBAlEmD75GJI8Y6uGRUV0pQv9ODK7/CFmqYJqVkKRHtrzIKZ2lKB+iRCtbLlQ1uPFXDLhJxQVQiZYi5cHO07A8xYA== MIME-Version: 1.0 X-Received: by 10.31.6.131 with SMTP id 125mr14693628vkg.140.1453060783740; Sun, 17 Jan 2016 11:59:43 -0800 (PST) Received: by 10.31.194.14 with HTTP; Sun, 17 Jan 2016 11:59:43 -0800 (PST) In-Reply-To: References: <569BD681.80608@freebsd.org> Date: Sun, 17 Jan 2016 14:59:43 -0500 Message-ID: Subject: Re: r294195: Kernel panic during installworld From: Ultima To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2016 19:59:45 -0000 https://puu.sh/mzmpL/b209da9263.jpgn I hope this is better, sorry I didn't know it would get stripped. Ultima On Sun, Jan 17, 2016 at 2:58 PM, Ultima wrote: > https://puu.sh/mzmpL/b209da9263.jpgn I hope this is better, sorry I > didn't know it would get stripped. > > Ultima > > On Sun, Jan 17, 2016 at 12:59 PM, Allan Jude > wrote: > >> On 2016-01-17 09:14, Ultima wrote: >> > make installkernel KERNCONF=MYKERNEL >> > reboot >> > mergemaster -p >> > make installworld -> attached >> > >> > MYKERNEL=GENERIC+ >> > options VIMAGE >> > options ROUTETABLES=2 >> > >> > Anything else that maybe helpful? >> > >> > Ultima >> > _______________________________________________ >> > freebsd-current@freebsd.org mailing list >> > https://lists.freebsd.org/mailman/listinfo/freebsd-current >> > To unsubscribe, send any mail to " >> freebsd-current-unsubscribe@freebsd.org" >> > >> >> Your attachment was stripped. Can you post it somewhere and include the >> url? >> >> -- >> Allan Jude >> >> > From owner-freebsd-current@freebsd.org Mon Jan 18 01:25:25 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3B1F0A867A2 for ; Mon, 18 Jan 2016 01:25:25 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (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 065A112E7 for ; Mon, 18 Jan 2016 01:25:24 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id u0I1Q6Gr037587 for ; Sun, 17 Jan 2016 17:26:12 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: "FreeBSD CURRENT" From: "Chris H" Subject: ATA_STATIC_ID removal Date: Sun, 17 Jan 2016 17:26:12 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <2244d431234bc14fe3b4695507c763be@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 01:25:25 -0000 Greetings, I just fired off a buildworld w/o *completely* reading UPDATING. Only to discover that ATA_STATIC_ID was removed between my last build on this box, and the one building now. Will the fact that my KERNCONF for this build contains ATA_STATIC_ID cause me any grief? Thanks for any input! --Chris -- From owner-freebsd-current@freebsd.org Mon Jan 18 06:20:14 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D33EEA878C6 for ; Mon, 18 Jan 2016 06:20:14 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 99E431A78 for ; Mon, 18 Jan 2016 06:20:14 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1aL3Ac-000MvZ-0P>; Mon, 18 Jan 2016 07:20:06 +0100 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=freyja.zeit4.iv.bundesimmobilien.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1aL3Ab-001qEh-Pm>; Mon, 18 Jan 2016 07:20:05 +0100 Date: Mon, 18 Jan 2016 07:20:00 +0100 From: "O. Hartmann" To: freebsd-current Subject: r294248: boot stuck: EFI loader doesn't proceed Message-ID: <20160118072000.4a03a4d2@freyja.zeit4.iv.bundesimmobilien.de> Organization: FU Berlin X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 87.138.105.249 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 06:20:14 -0000 Building NanoBSD images booting off from USB Flash drives and having two GPT partitions, booting is stuck in the UEFI loader, presenting me with something like: [...] Probing 6 block devices.....++. done ZFS found no pools UFS found 2 partitions And further nothing happens. A RESET is only possible by a hardreset - it seems the system is crashed/stuck/frozen or something similar. The last images working run r293654. The issue occurs with r294248. Any suggestions possible? Did I miss something? Thanks in advance, kind regards Oliver From owner-freebsd-current@freebsd.org Mon Jan 18 08:08:32 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 55574A87B71 for ; Mon, 18 Jan 2016 08:08:32 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 189B315F4; Mon, 18 Jan 2016 08:08:32 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::f97d:8323:c83:c4de] (unknown [IPv6:2001:7b8:3a7:0:f97d:8323:c83:c4de]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 6FDF51AE74; Mon, 18 Jan 2016 09:08:27 +0100 (CET) Subject: Re: r294248: boot stuck: EFI loader doesn't proceed Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_DD6F11F1-03F9-480F-986D-450C4AEAF0C2"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 (ebbf3ef) From: Dimitry Andric In-Reply-To: <20160118072000.4a03a4d2@freyja.zeit4.iv.bundesimmobilien.de> Date: Mon, 18 Jan 2016 09:10:33 +0100 Cc: Steven Hartland , freebsd-current Message-Id: <596CBFC9-275C-445F-9D2B-23B90DB9966A@FreeBSD.org> References: <20160118072000.4a03a4d2@freyja.zeit4.iv.bundesimmobilien.de> To: "O. Hartmann" X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 08:08:32 -0000 --Apple-Mail=_DD6F11F1-03F9-480F-986D-450C4AEAF0C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 18 Jan 2016, at 07:20, O. Hartmann = wrote: > Building NanoBSD images booting off from USB Flash drives and having = two GPT > partitions, booting is stuck in the UEFI loader, presenting me with = something > like: >=20 > [...] > Probing 6 block devices.....++. done >=20 > ZFS found no pools > UFS found 2 partitions >=20 > And further nothing happens. A RESET is only possible by a hardreset - = it seems > the system is crashed/stuck/frozen or something similar. >=20 > The last images working run r293654. The issue occurs with r294248. >=20 > Any suggestions possible? Did I miss something? Looks to me like fallout from the recent modularisation in r294060, and/or ZFS support in r294068. Steven, any clue? -Dimitry --Apple-Mail=_DD6F11F1-03F9-480F-986D-450C4AEAF0C2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.29 iEYEARECAAYFAlacngAACgkQsF6jCi4glqNrswCcDCXO1ZF9MV8PenXrc2dJdt2G cXUAoLvdWG1bjcUOq7NhkYLD3DlcQcHo =KngS -----END PGP SIGNATURE----- --Apple-Mail=_DD6F11F1-03F9-480F-986D-450C4AEAF0C2-- From owner-freebsd-current@freebsd.org Mon Jan 18 08:26:40 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70E86A860F0; Mon, 18 Jan 2016 08:26:40 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (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 54A7D1D4F; Mon, 18 Jan 2016 08:26:39 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id u0I8QXr5025898; Mon, 18 Jan 2016 00:26:39 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: "FreeBSD ports" , "FreeBSD CURRENT" From: "Chris H" Subject: Will pkg(8) *ever* play nice? Date: Mon, 18 Jan 2016 00:26:39 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <1951334c592f1ba416e9619d89b63f92@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 08:26:40 -0000 Greetings, I was in the process of updating one of my development boxes that runs -CURRENT. It's lagging a bit behind. So it required a fresh, new "world". World built as expected. But the kernel failed due to pkg(8). This box has an Nvidia video card. So src.conf(5) has [among other ports entries] PORTS_MODULES=x11/nvidia-driver-304 the [kernel] build failed due to pkg(8) ===> Ports module x11/nvidia-driver-304 (all) cd ${PORTSDIR:-/usr/ports}/x11/nvidia-driver-304; PATH=/usr/obj/usr/src/tmp/lega cy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin: /usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin: /usr/bin:/usr/local/bin:/usr/local/sbin SRC_BASE=/usr/src OSVERSION=1100062 W RKDIRPREFIX=/usr/obj/usr/src/sys/DEVBOX make -B clean all ===> Cleaning for nvidia-driver-304-304.128 ===> nvidia-driver-304-304.128 pkg(8) must be version 1.6.0 or greater, but you have 1.4.12. You must upgrade the ports-mgmt/pkg port first. *** Error code 1 Stop. make[3]: stopped in /usr/ports/x11/nvidia-driver-304 *** Error code 1 Stop. make[2]: stopped in /usr/obj/usr/src/sys/DEVBOX *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 .. Do I need to have FreeBSD-12 && ports/head from 12 installed *prior* to building (upgrading)?!? This feels like a chicken-v-egg thing. Is it possible to *remove* pkg(8) && any dependency on it. Is this a bug in pkg(8) or just a bug in my head? Please help. As most of you already know; building/installing world/kernel is a fairly time consuming process. Thanks! --Chris -- From owner-freebsd-current@freebsd.org Mon Jan 18 09:12:26 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 277A7A87786; Mon, 18 Jan 2016 09:12:26 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (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 0A60713C3; Mon, 18 Jan 2016 09:12:25 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id u0I9CKb8030926; Mon, 18 Jan 2016 01:12:26 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: "FreeBSD ports" , "FreeBSD CURRENT" In-Reply-To: <1951334c592f1ba416e9619d89b63f92@ultimatedns.net> References: <1951334c592f1ba416e9619d89b63f92@ultimatedns.net> From: "Chris H" Subject: Re: Will pkg(8) *ever* play nice? Date: Mon, 18 Jan 2016 01:12:26 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 09:12:26 -0000 On Mon, 18 Jan 2016 00:26:39 -0800 "Chris H" wrote > Greetings, > I was in the process of updating one of my development boxes > that runs -CURRENT. It's lagging a bit behind. So it required > a fresh, new "world". World built as expected. But the kernel > failed due to pkg(8). This box has an Nvidia video card. So > src.conf(5) has [among other ports entries] > > PORTS_MODULES=x11/nvidia-driver-304 > > the [kernel] build failed due to pkg(8) > > ===> Ports module x11/nvidia-driver-304 (all) > cd ${PORTSDIR:-/usr/ports}/x11/nvidia-driver-304; > PATH=/usr/obj/usr/src/tmp/lega > cy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/b > in: > /usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sb > in: /usr/bin:/usr/local/bin:/usr/local/sbin SRC_BASE=/usr/src > OSVERSION=1100062 W > RKDIRPREFIX=/usr/obj/usr/src/sys/DEVBOX make -B clean all > ===> Cleaning for nvidia-driver-304-304.128 > ===> nvidia-driver-304-304.128 pkg(8) must be version 1.6.0 or greater, but > you have 1.4.12. You must upgrade the ports-mgmt/pkg port first. > *** Error code 1 > > Stop. > make[3]: stopped in /usr/ports/x11/nvidia-driver-304 > *** Error code 1 > > Stop. > make[2]: stopped in /usr/obj/usr/src/sys/DEVBOX > *** Error code 1 > > Stop. > make[1]: stopped in /usr/src > *** Error code 1 > > .. > > Do I need to have FreeBSD-12 && ports/head from 12 installed *prior* > to building (upgrading)?!? > This feels like a chicken-v-egg thing. Is it possible to *remove* > pkg(8) && any dependency on it. Is this a bug in pkg(8) or just > a bug in my head? > > Please help. As most of you already know; building/installing > world/kernel is a fairly time consuming process. > > Thanks! > OK. It's late, and I'm ready to call it a day. It's probably a bug in my head. I *probably* should have upgraded pkg(8) after svn up'ing src && ports, and *prior* to making worls && kernel. So I'm going to take a chance, and: cd /usr/obj chflags -R noschg * cd / rm -r /usr/obj cd /usr/ports/ports-mgmt/pkg make; make deinstall && make resinstall clean cd /usr/src and make world, and kernel, and see how it goes. --Chris From owner-freebsd-current@freebsd.org Mon Jan 18 11:34:50 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 72A3DA86192 for ; Mon, 18 Jan 2016 11:34:50 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from kif.fubar.geek.nz (kif.fubar.geek.nz [178.62.119.249]) by mx1.freebsd.org (Postfix) with ESMTP id 42EC51AEB; Mon, 18 Jan 2016 11:34:49 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from zapp (host81-149-102-120.in-addr.btopenworld.com [81.149.102.120]) by kif.fubar.geek.nz (Postfix) with ESMTPSA id 90EC6D7A17; Mon, 18 Jan 2016 11:34:12 +0000 (UTC) Date: Mon, 18 Jan 2016 11:34:11 +0000 From: Andrew Turner To: Dimitry Andric Cc: "O. Hartmann" , Steven Hartland , freebsd-current Subject: Re: r294248: boot stuck: EFI loader doesn't proceed Message-ID: <20160118113411.2a4d3079@zapp> In-Reply-To: <596CBFC9-275C-445F-9D2B-23B90DB9966A@FreeBSD.org> References: <20160118072000.4a03a4d2@freyja.zeit4.iv.bundesimmobilien.de> <596CBFC9-275C-445F-9D2B-23B90DB9966A@FreeBSD.org> X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 11:34:50 -0000 On Mon, 18 Jan 2016 09:10:33 +0100 Dimitry Andric wrote: > On 18 Jan 2016, at 07:20, O. Hartmann > wrote: > > Building NanoBSD images booting off from USB Flash drives and > > having two GPT partitions, booting is stuck in the UEFI loader, > > presenting me with something like: > > > > [...] > > Probing 6 block devices.....++. done > > > > ZFS found no pools > > UFS found 2 partitions > > > > And further nothing happens. A RESET is only possible by a > > hardreset - it seems the system is crashed/stuck/frozen or > > something similar. > > > > The last images working run r293654. The issue occurs with r294248. > > > > Any suggestions possible? Did I miss something? > > Looks to me like fallout from the recent modularisation in r294060, > and/or ZFS support in r294068. Steven, any clue? > > -Dimitry > I found the same issue while working on nanobsd. I'm not sure it's due to the recent ZFS changes as I reverted them, but found boot1 still failed to load loader.efi. Andrew From owner-freebsd-current@freebsd.org Mon Jan 18 19:09:18 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 773EAA86C59 for ; Mon, 18 Jan 2016 19:09:18 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 42D5A1B21; Mon, 18 Jan 2016 19:09:18 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io0-x230.google.com with SMTP id 77so526868979ioc.2; Mon, 18 Jan 2016 11:09:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=LtcZeiJh6lFnuYu5A9xuUi3Rz8dKefQn6ikhUu2KXLA=; b=EgFN/a342T/LK3pYjJVY0WnfY5n0kgfLDzM0hnvC0kF1MdtON+Cl0H6lHbExg7LCN0 uckAIRX6DCisIGSy/u5IEWY/BZiu3KafWWzelXfDKALch1czhemOioif8a7l4GuXW/Et fhpq2xlxnrbBWhI8SX/I6ruR9zswrQGQIENOhyM+YTuiWBUEqTOj/bG9Yeg4bCKVGfbw V0/77iU5WVnRjj8EyGmaPBaaAP4QYCfjkS/Si/fa2/AcuPbVGtQrIrNRmmM7iYdrvbNE a+3vuSjWI3IKr54dBU+p1R4cdVNUouHQt8ldpF265qpp5pBNO5fX2l8nKmBE7wzYfbze YboQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=LtcZeiJh6lFnuYu5A9xuUi3Rz8dKefQn6ikhUu2KXLA=; b=Uby6VzxCQPgdC/4FvGiAtseVglMc6ELhsxxfGnvcFSBsJ968Hke8WmWWBOAukir9Ir ziryyzrkGuIO26YuWvb1ULRZuF+oVEAd2DBjvlXxkrwKHSHUXA97JJpljVcxXPo60Pod AXKlG2DVsS//slY7Q6x9myUOWcSJLeIPuonMmsfdfy3JZfjPLZNonlEJOyq60iksLhxP AhphryPUIe9IQAfSimDsS1P3qRHcsMhN/eDfwgmCAGH7pJpsdTSmxe85N0J6BREFPJYe E6W3N1ZQ1yV5Ai019y2YQ+9Zseu+PpUIw/k2sUSlznOD6RWxzhhRewY6penoD9cdWliN uI7A== X-Gm-Message-State: ALoCoQkrQPUO5tm7jDgPG2jnxeKzxcO0Ic3uAoHHvBJuo5ILzxHNBb7y3QDvZCxnsvY0bcgSLSYoymzUf7rU/0HVpl/9DyKEoQ== X-Received: by 10.107.136.226 with SMTP id s95mr21186906ioi.38.1453144157685; Mon, 18 Jan 2016 11:09:17 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.39.66 with HTTP; Mon, 18 Jan 2016 11:08:58 -0800 (PST) In-Reply-To: <596CBFC9-275C-445F-9D2B-23B90DB9966A@FreeBSD.org> References: <20160118072000.4a03a4d2@freyja.zeit4.iv.bundesimmobilien.de> <596CBFC9-275C-445F-9D2B-23B90DB9966A@FreeBSD.org> From: Ed Maste Date: Mon, 18 Jan 2016 14:08:58 -0500 X-Google-Sender-Auth: aKTK3vGIeMKIxvSYM_h2-FvpVCI Message-ID: Subject: Re: r294248: boot stuck: EFI loader doesn't proceed To: Dimitry Andric Cc: "O. Hartmann" , Steven Hartland , freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 19:09:18 -0000 On 18 January 2016 at 03:10, Dimitry Andric wrote: > On 18 Jan 2016, at 07:20, O. Hartmann wrote: >> Building NanoBSD images booting off from USB Flash drives and having two GPT >> partitions, booting is stuck in the UEFI loader, presenting me with something >> like: >> >> [...] >> Probing 6 block devices.....++. done >> >> ZFS found no pools >> UFS found 2 partitions >> >> And further nothing happens. A RESET is only possible by a hardreset - it seems >> the system is crashed/stuck/frozen or something similar. >> >> The last images working run r293654. The issue occurs with r294248. >> >> Any suggestions possible? Did I miss something? > > Looks to me like fallout from the recent modularisation in r294060, > and/or ZFS support in r294068. Steven, any clue? In QEMU boot1 failed for me with "Failed start image provided by UFS", and I can confirm that it's fixed by reverting those two commits. From owner-freebsd-current@freebsd.org Mon Jan 18 20:27:15 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 454ACA86798 for ; Mon, 18 Jan 2016 20:27:15 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from kif.fubar.geek.nz (kif.fubar.geek.nz [178.62.119.249]) by mx1.freebsd.org (Postfix) with ESMTP id 16DE71B3C; Mon, 18 Jan 2016 20:27:14 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from zapp (bcdd4360.skybroadband.com [188.221.67.96]) by kif.fubar.geek.nz (Postfix) with ESMTPSA id 19FD1D7A17; Mon, 18 Jan 2016 20:26:44 +0000 (UTC) Date: Mon, 18 Jan 2016 20:26:42 +0000 From: Andrew Turner To: Steven Hartland Cc: Dimitry Andric , "O. Hartmann" , freebsd-current Subject: Re: r294248: boot stuck: EFI loader doesn't proceed Message-ID: <20160118202642.4f52614b@zapp> In-Reply-To: <569CD4D6.50404@freebsd.org> References: <20160118072000.4a03a4d2@freyja.zeit4.iv.bundesimmobilien.de> <596CBFC9-275C-445F-9D2B-23B90DB9966A@FreeBSD.org> <20160118113411.2a4d3079@zapp> <569CD4D6.50404@freebsd.org> X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 20:27:15 -0000 On Mon, 18 Jan 2016 12:04:38 +0000 Steven Hartland wrote: > On 18/01/2016 11:34, Andrew Turner wrote: > > On Mon, 18 Jan 2016 09:10:33 +0100 > > Dimitry Andric wrote: > > > >> On 18 Jan 2016, at 07:20, O. Hartmann > >> wrote: > >>> Building NanoBSD images booting off from USB Flash drives and > >>> having two GPT partitions, booting is stuck in the UEFI loader, > >>> presenting me with something like: > >>> > >>> [...] > >>> Probing 6 block devices.....++. done > >>> > >>> ZFS found no pools > >>> UFS found 2 partitions > >>> > >>> And further nothing happens. A RESET is only possible by a > >>> hardreset - it seems the system is crashed/stuck/frozen or > >>> something similar. > >>> > >>> The last images working run r293654. The issue occurs with > >>> r294248. > >>> > >>> Any suggestions possible? Did I miss something? > >> Looks to me like fallout from the recent modularisation in r294060, > >> and/or ZFS support in r294068. Steven, any clue? > >> > >> -Dimitry > >> > > I found the same issue while working on nanobsd. I'm not sure it's > > due to the recent ZFS changes as I reverted them, but found boot1 > > still failed to load loader.efi. > > > Can you update to > r294265 and test with EFI_DEBUG defined e.g. > make buildenv -DEFI_DEBUG > cd sys/boot/efi/boot1 > make clean > make > > Then install the new boot1.efifat to your efi partition. > > Hopefully this will give some more information on what the problem > may be. the issue was we were caching reads from the first filesystem we looked at. I've committed the fix in r294291 to force the code to re-read on each filesystem it looks at. Andrew From owner-freebsd-current@freebsd.org Mon Jan 18 21:57:56 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 06B2BA87A11 for ; Mon, 18 Jan 2016 21:57:56 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 C688D15F5; Mon, 18 Jan 2016 21:57:55 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io0-x22c.google.com with SMTP id 1so515146066ion.1; Mon, 18 Jan 2016 13:57:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=zKzyP66Adit57Bnl16Bfz7pBw7LJY/2nnnZwjZ/j6Fg=; b=cnSQ96+Sc3DWVZoTTCJEdQQFHrh/vYh4HVftM9V5cD/5XxiutooMKxlDwgnQK+b5bW 3qsEkOGixu9z8oWt9NnLWED49F+z4w24FyO0ObDREpSD2J+IBrbxFM9BNFvPLVPKQQ5L t/pqPSXFBy+o4PDfOofechh39+5IMTiex1mlY2T+y+LGP322i9SapoHHYkM7py2k7Q8Q QwO4Kep0G6mDojaQoloyetvs2JalkaSzHGMM1KcAilI3sZeCEBlZMm2XBp9KqvA4W45M eLHvKVrNxggUwm5NlmGpG+B7QBiVg0TR682k1GhEUh00nWnVxjwSQyIpI7xRB/t0on9g C4mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=zKzyP66Adit57Bnl16Bfz7pBw7LJY/2nnnZwjZ/j6Fg=; b=HVAM/IgfOe9zdO8guv1P8FHaXnjRd/73CUnsl+pClnXhPEdfSdRldmIG2TPETSdR6p tQsyUke9ln/ZZrEetEwX/sPBMWPR1LjVRT3qISzzj3o7Tjq4yQPPvBIWrWPihZgYrl1X bLn7rji/eIGsgV21VcmWzJgzJc10iVaOeRY/taV62qg4wKSIdwcTLx4uycsAtFoA2nER sSZrzIBov/wiBH2kuV/R+5SD4UGPlGhhCcB58x+2ES3ISaLvzuJYFXG0C4CbwDjXWU5j g2zqapv+DCou/xIpDQ77KZjAir+9iZDbBtC4fNYCDyDnq7yKNwCUEPRN66xB4zFEU877 YjlQ== X-Gm-Message-State: ALoCoQnLQJlrjV3xF0GodCeWDDxgD4IKJnY2tMGmNePCQXXK1f4tEuIzTtNdwZ/3/JMTxdiwH+FzTM2+jd+KeFfk+jTomoe5ig== X-Received: by 10.107.136.226 with SMTP id s95mr21677490ioi.38.1453154275222; Mon, 18 Jan 2016 13:57:55 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.39.66 with HTTP; Mon, 18 Jan 2016 13:57:35 -0800 (PST) In-Reply-To: <20160118202642.4f52614b@zapp> References: <20160118072000.4a03a4d2@freyja.zeit4.iv.bundesimmobilien.de> <596CBFC9-275C-445F-9D2B-23B90DB9966A@FreeBSD.org> <20160118113411.2a4d3079@zapp> <569CD4D6.50404@freebsd.org> <20160118202642.4f52614b@zapp> From: Ed Maste Date: Mon, 18 Jan 2016 16:57:35 -0500 X-Google-Sender-Auth: Fm39op79a3pPCti8CX5jvCziBXE Message-ID: Subject: Re: r294248: boot stuck: EFI loader doesn't proceed To: Andrew Turner Cc: Steven Hartland , Dimitry Andric , "O. Hartmann" , freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 21:57:56 -0000 On 18 January 2016 at 15:26, Andrew Turner wrote: > > the issue was we were caching reads from the first filesystem we looked > at. I've committed the fix in r294291 to force the code to re-read on > each filesystem it looks at. Thanks Andrew - my QEMU boot failure is not reproducible on a build from a clean tree with this change included. From owner-freebsd-current@freebsd.org Mon Jan 18 22:37:08 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E40F3A86981 for ; Mon, 18 Jan 2016 22:37:07 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id CF1D31FB2 for ; Mon, 18 Jan 2016 22:37:07 +0000 (UTC) (envelope-from ken@kdm.org) Received: by mailman.ysv.freebsd.org (Postfix) id CDC3EA8697F; Mon, 18 Jan 2016 22:37:07 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD279A8697E; Mon, 18 Jan 2016 22:37:07 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (mithlond.kdm.org [96.89.93.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "A1-33714", Issuer "A1-33714" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D1C11FB1; Mon, 18 Jan 2016 22:37:07 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (localhost [127.0.0.1]) by mithlond.kdm.org (8.15.2/8.14.9) with ESMTPS id u0IMb4DH087661 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 18 Jan 2016 17:37:04 -0500 (EST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.15.2/8.14.9/Submit) id u0IMb4mE087660; Mon, 18 Jan 2016 17:37:04 -0500 (EST) (envelope-from ken) Date: Mon, 18 Jan 2016 17:37:04 -0500 From: "Kenneth D. Merry" To: scsi@freebsd.org, current@freebsd.org Subject: Re: CAM Shingled Disk support patches available Message-ID: <20160118223704.GA87506@mithlond.kdm.org> References: <20151118171309.GA3564@mithlond.kdm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151118171309.GA3564@mithlond.kdm.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [127.0.0.1]); Mon, 18 Jan 2016 17:37:04 -0500 (EST) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mithlond.kdm.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 22:37:08 -0000 I have a new set of SMR patches available. See below for the full explanation. The primary change here is that I have added SMR support to the ada(4) driver. I spent some time considering whether to try to make the da(4) and ada(4) probe infrastructure somewhat common, but in the end concluded it would be too involved with not enough code reduction (if any) in the end. So, although the ideas are similar, the probe logic is separate. Note that NCQ support for SMR commands (Report Zones, Reset Write Pointer, etc.) for SATA protocol shingled drives isn't active. For both the da(4) and ada(4) driver this is for lack of a way to plumb the ATA Auxiliary register down to the drive. In the ada(4) case, we need to add the register to struct ccb_ataio and add support in one or more of the underlying SATA drivers, e.g. ahci(4). In the da(4) case, it will require an update of the T-10 SAT spec to provide a way to pass the Auxiliary register down via the SCSI ATA PASS-THROUGH command, and then a subsquent update of the SAT layer in various vendors' SAS controller firmware. At that point, there may be an official mapping of the SCSI ZBC commands to the ATA ZAC commands, and we may be able to just issue the SCSI version of the commands instead of composing ATA commands in the da(4) driver. (We'll still need to keep the ATA passthrough version for a while at least to support controllers that don't have the updated translation code.) FreeBSD/head as of SVN revision 294105: https://people.freebsd.org/~ken/cam_smr.head.20160118.1.txt FreeBSD stable/10 as of SVN revision 294100: https://people.freebsd.org/~ken/cam_smr.stable10.20160118.1.txt Testing and comments are welcome. Ken On Wed, Nov 18, 2015 at 12:13:09 -0500, Kenneth D. Merry wrote: > > I have work in progress patches to add SMR (Shingled Magnetic Recording) > support to CAM and GEOM here: > > FreeBSD/head as of SVN revision 290997: > > https://people.freebsd.org/~ken/cam_smr.head.20151117.1.txt > > FreeBSD stable/10 as of SVN revision 290995: > > https://people.freebsd.org/~ken/cam_smr.stable10.20151117.1.txt > > This includes support for Host Managed, Host Aware and Drive Managed SMR > drives that are either SCSI (ZBC) or ATA (ZAC) attached via a SAS > controller. This does not include support for SMR ATA drives attched via > an ATA controller. Also, I have not yet figured out how to properly detect > a Host Managed ATA drive, so this code won't do that. > > The big drive vendors are moving to SMR for at least some of their drives. > The primary challenge with SMR is that it requires writing a relatively > large zone sequentially starting at the beginning of the zone. The usual > zone size is 256MB. It is conceptually almost like having a 256MB sector > size. > > We (Spectra Logic) are working on ZFS changes that will use this CAM and > GEOM infrastructure to make ZFS play well with SMR drives. Those changes > aren't yet done. > > The patches linked above include: > o A new 'camcontrol zone' command that allows displaying and managing > drive zones via SCSI/ATA passthrough. > o A new zonectl(8) utility that uses the new DIOCZONECMD ioctl to display > and manage zones via the da(4) (and later ada(4)) driver. > o Changes to diskinfo -v to display the zone mode of a drive. > o A new disk zone API, sys/sys/disk_zone.h. > o A new bio type, BIO_ZONE, and modifications to GEOM to support it. This > new bio will allow filesystems to query zone support in a drive and > manage zoned drives. > o Extensive modifications to the da(4) driver to handle probing SCSI and > SATA behind SAS SMR drives. > o Additional CAM CDB building functions for zone commands. > > The current issues that need to be addressed are: > o The da(4) driver now has 6 additional probe states, 5 of which are > needed for probing ATA drives behind SAS controllers. I have not yet > added support for BIO_ZONE bios to ada(4), but it will be very similar > to the da(4) driver version. The ATA probe code needs to be pulled > out of the da(4) driver and changed into a form that will allow it to > work for either the ada(4) or da(4) driver. Otherwise we'll have a fair > amount of code duplication between the two drivers. > > o There is a reasonable amount of code duplication between 'camcontrol zone' > and zonectl(8). This was done for speed / expediency's sake, but it may > be possible to make more of the code common there. > > o In order to add the new BIO_ZONE bio command, I had to change the bio_cmd > field in struct bio from a uint8_t to a uint16_t. This will cause > binary compatibility problems with any 3rd party loadable modules. > Advice on how to handle this would be welcome. > > o In the process of developing these changes, I discovered that the > dxfer_len paramter for scsi_ata_pass_16() was too small (uint16_t, and > it needed to be uint32_t). I increased it, but that will potentially > cause a binary incompatibility problem with any existing applications > that use the current API via libcam. Advice on how to handle that > would be welcome. > > If you look through the code, you'll notice that the disk_zone.h API is > separate from the SCSI and ATA APIs. The intent is to allow filesystems > and other consumers of the API to just talk to the disk zone API without > dealing with the SCSI and ATA specifics. Another reason behind all of this > is that even though the SCSI ZBC and ATA ZAC specs were developed in > concert, and are intended to be functionally identical, they are still SCSI > and ATA. As usual, SCSI is big endian and ATA is little endian. So to > present a common API to the filesystem, we give all of the zone data back > in native byte order, regardless of the underlying device protocol. > > Another thing to note is the extensive use of ATA passthrough in the da(4) > driver. This is necessary because the SCSI SAT (SCSI to ATA Translation) > specification has not yet caught up with translating SCSI zone commands > (ZBC) to ATA zone commands (ZAC). So, until the spec is updated and LSI > and other vendors update their SCSI to ATA translation layers, we'll have > to use the ATA version of the commands when talking to ATA drives via SAS > controllers. > > I have only tested the code so far with Seagate SATA Drive Managed and Host > Aware drives. I would appreciate testing with any drives. (And testing to > make sure that the patches don't cause problems with existing hardware.) > Right now, all you can really do is manage the zones manually using > camcontrol(8) or zonectl(8). Automatic management will come with the ZFS > changes. (Or changes to other filesysems if people want to do it.) > > If you have a SATA Host Aware drive, in theory camcontrol(8) should allow > you to manage the drive if you have it attached to a SATA controller. > > Here is an example of some of the commands. > > Get general zoning information: > > [root@sm4u-1 ~]# zonectl -c params -d /dev/da21 > Zone Mode: Host Aware > Command support: Report Zones, Open, Close, Finish, Reset Write Pointer > Unrestricted Read in Sequential Write Required Zone (URSWRZ): No > Optimal Number of Open Sequential Write Preferred Zones: 128 > Optimal Number of Non-Sequentially Written Sequential Write Preferred Zones: 8 > Maximum Number of Open Sequential Write Required Zones: Unlimited > > Look at information from the da(4) driver: > > [root@sm4u-1 ~]# sysctl kern.cam.da.21 > kern.cam.da.21.delete_method: NONE > kern.cam.da.21.delete_max: 1081344 > kern.cam.da.21.minimum_cmd_size: 6 > kern.cam.da.21.sort_io_queue: -1 > kern.cam.da.21.zone_mode: Host Aware > kern.cam.da.21.zone_support: Report Zones, Open, Close, Finish, Reset Write Pointer > kern.cam.da.21.optimal_seq_zones: 128 > kern.cam.da.21.optimal_nonseq_zones: 8 > kern.cam.da.21.max_seq_zones: 4294967295 > kern.cam.da.21.error_inject: 0 > > Display all of the zones with zonectl(8): > > [root@sm4u-1 ~]# zonectl -d /dev/da21 -c rz > 29809 zones, Maximum LBA 0x3a3812aaf (15628053167) > Zone lengths and types may vary > Start LBA Length WP LBA Zone Type Condition Sequential Reset > 0, 524288, 0x80000, Conventional, NWP, Sequential, No Reset Needed > 0x80000, 524288, 0x100000, Conventional, NWP, Sequential, No Reset Needed > 0x100000, 524288, 0x180000, Conventional, NWP, Sequential, No Reset Needed > 0x180000, 524288, 0x200000, Conventional, NWP, Sequential, No Reset Needed > 0x200000, 524288, 0x280000, Conventional, NWP, Sequential, No Reset Needed > 0x280000, 524288, 0x300000, Conventional, NWP, Sequential, No Reset Needed > 0x300000, 524288, 0x380000, Conventional, NWP, Sequential, No Reset Needed > 0x380000, 524288, 0x400000, Conventional, NWP, Sequential, No Reset Needed > 0x400000, 524288, 0x480000, Conventional, NWP, Sequential, No Reset Needed > 0x480000, 524288, 0x500000, Conventional, NWP, Sequential, No Reset Needed > 0x500000, 524288, 0x580000, Conventional, NWP, Sequential, No Reset Needed > 0x580000, 524288, 0x600000, Conventional, NWP, Sequential, No Reset Needed > 0x600000, 524288, 0x680000, Conventional, NWP, Sequential, No Reset Needed > 0x680000, 524288, 0x700000, Conventional, NWP, Sequential, No Reset Needed > 0x700000, 524288, 0x780000, Conventional, NWP, Sequential, No Reset Needed > [ ... ] > 0x1f00000, 524288, 0x1f80000, Conventional, NWP, Sequential, No Reset Needed > 0x1f80000, 524288, 0x2000000, Conventional, NWP, Sequential, No Reset Needed > 0x2000000, 524288, 0x2080000, Seq Preferred, Full, Sequential, No Reset Needed > 0x2080000, 524288, 0x2100000, Seq Preferred, Full, Sequential, No Reset Needed > 0x2100000, 524288, 0x2180000, Seq Preferred, Full, Sequential, No Reset Needed > 0x2180000, 524288, 0x2200000, Seq Preferred, Full, Sequential, No Reset Needed > 0x2200000, 524288, 0x2280000, Seq Preferred, Full, Sequential, No Reset Needed > 0x2280000, 524288, 0x2300000, Seq Preferred, Full, Sequential, No Reset Needed > [ ... ] > > Use camcontrol zone to reset the write pointer for the first shingled zone > listed above: > > [root@sm4u-1 ~]# camcontrol zone da21 -v -c rwp -l 0x2000000 > > Use camcontrol zone to ask the drive to report empty zones: > > [root@sm4u-1 ~]# camcontrol zone da21 -v -c rz -o empty > 1 zones, Maximum LBA 0x3a3812aaf (15628053167) > Zone lengths and types may vary > Start LBA Length WP LBA Zone Type Condition Sequential Reset > 0x2000000, 524288, 0x2000000, Seq Preferred, Empty, Sequential, No Reset Needed > > Get information on a Host Aware drive: > > root@sm4u-1 ~]# diskinfo -v da21 > da21 > 512 # sectorsize > 8001563222016 # mediasize in bytes (7.3T) > 15628053168 # mediasize in sectors > 4096 # stripesize > 0 # stripeoffset > 972801 # Cylinders according to firmware. > 255 # Heads according to firmware. > 63 # Sectors according to firmware. > Z84008NY # Disk ident. > enc@5003048001f311fd/elmtype@array_device/slot@22 # Physical path > Host Aware # Zone Mode > > Get information on a drive managed drive: > > [root@sm4u-1 ~]# diskinfo -v da20 > da20 > 512 # sectorsize > 8001563222016 # mediasize in bytes (7.3T) > 15628053168 # mediasize in sectors > 4096 # stripesize > 0 # stripeoffset > 972801 # Cylinders according to firmware. > 255 # Heads according to firmware. > 63 # Sectors according to firmware. > Z8405938 # Disk ident. > enc@5003048001f311fd/elmtype@array_device/slot@21 # Physical path > Drive Managed # Zone Mode > > Get information on a non-zoned drive: > > [root@sm4u-1 ~]# diskinfo -v da4 > da4 > 512 # sectorsize > 100030242816 # mediasize in bytes (93G) > 195371568 # mediasize in sectors > 0 # stripesize > 0 # stripeoffset > 12161 # Cylinders according to firmware. > 255 # Heads according to firmware. > 63 # Sectors according to firmware. > 124903574F36 # Disk ident. > enc@5003048001f311fd/elmtype@array_device/slot@5 # Physical path > Not Zoned # Zone Mode > > Testing and comments are welcome. > > Thanks, > > Ken > -- > Kenneth Merry > ken@FreeBSD.ORG -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-current@freebsd.org Mon Jan 18 22:41:24 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 77660A86B96 for ; Mon, 18 Jan 2016 22:41:24 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3566312B8 for ; Mon, 18 Jan 2016 22:41:24 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: by mail-wm0-x234.google.com with SMTP id 123so69765983wmz.0 for ; Mon, 18 Jan 2016 14:41:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=from:subject:to:references:cc:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=GvLt9WdAexuZSsYsm8WwTZWzjzC+PoITdOB/tc0gTsc=; b=zdXYWCg3Pncy6AMTeNQZpNYYSw7+JAEw9s1AJBRqHK8YOTAgksRERJs14df8UIpTmy LgbA20LCH9U7Myw4YoX5I369rFUG8Fw81BtTlXhcodDKYBj4cgYQFdA3AYu5XqhgJF/r piK7zPlnlFgWhpf99/Igd6xKtf4In/vE92GE03A4a6La1Qb7pZ2mfWxhjnvCjw7kiYvn JEH2eOXo+bUTGwMhrmF/hP38Nmd+Ld39GWyMWmI6mMR2vJf80GzStpXdooNheIsRkG4r NLfXfLywO/kmaz5y2jdethiSKOEKaBvmqcG/Cd40H8RpunFfBi12aSh+5Lc8CBB093nn xW5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:cc:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=GvLt9WdAexuZSsYsm8WwTZWzjzC+PoITdOB/tc0gTsc=; b=Hz6ep3nQYBmy8sA5PK7snQRKCDpJL4B+2yZkplxHR/qUiY4QJ1YzQ+31EU/K37d6CY DAAyWCuoWy/taXSj6bwjAUpPUvcLGwb5tH3YAh3pgtZuAVrLNXveyom7qD8DT91Qv3Zb Au1GxI6h4V2TuOdVKf9XRnre4d19pu3pnD6ooBcR45ZcWDZU8OJ0vKzSR+2VIY3brKdn hYrhN1r0D9TSA5I1GI6DK4/YqE6BpFOoIvv+56XTxW8o3xxbXye0BO/3qn68+gRUmxIL N1jXBj+/htBEE7ZvhdhJ5pBn4IgaRlUPbkNCwiIkvMZo4IsNlUc26LbRDJEw0gEIBdTw JSvQ== X-Gm-Message-State: ALoCoQnigHN8opAuR3QnwrgMyJtfRXpBYWWAvYGWL9wKsdmvbAkrZQmTtqJtgl61FcRal5sByaXxGSa9MJUp0UaSGY4cnnTtZQ== X-Received: by 10.194.105.99 with SMTP id gl3mr25586551wjb.90.1453156882580; Mon, 18 Jan 2016 14:41:22 -0800 (PST) Received: from [10.10.1.58] (liv3d.labs.multiplay.co.uk. [82.69.141.171]) by smtp.gmail.com with ESMTPSA id i63sm17659081wmf.24.2016.01.18.14.41.21 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Jan 2016 14:41:21 -0800 (PST) From: Steven Hartland X-Google-Original-From: Steven Hartland Subject: Re: r294248: boot stuck: EFI loader doesn't proceed To: Ed Maste , Dimitry Andric References: <20160118072000.4a03a4d2@freyja.zeit4.iv.bundesimmobilien.de> <596CBFC9-275C-445F-9D2B-23B90DB9966A@FreeBSD.org> Cc: "O. Hartmann" , freebsd-current Message-ID: <569D6A14.2080409@freebsd.org> Date: Mon, 18 Jan 2016 22:41:24 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 18 Jan 2016 22:48:20 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 22:41:24 -0000 On 18/01/2016 19:08, Ed Maste wrote: > On 18 January 2016 at 03:10, Dimitry Andric wrote: >> On 18 Jan 2016, at 07:20, O. Hartmann wrote: >>> Building NanoBSD images booting off from USB Flash drives and having two GPT >>> partitions, booting is stuck in the UEFI loader, presenting me with something >>> like: >>> >>> [...] >>> Probing 6 block devices.....++. done >>> >>> ZFS found no pools >>> UFS found 2 partitions >>> >>> And further nothing happens. A RESET is only possible by a hardreset - it seems >>> the system is crashed/stuck/frozen or something similar. >>> >>> The last images working run r293654. The issue occurs with r294248. >>> >>> Any suggestions possible? Did I miss something? >> Looks to me like fallout from the recent modularisation in r294060, >> and/or ZFS support in r294068. Steven, any clue? > In QEMU boot1 failed for me with "Failed start image provided by UFS", > and I can confirm that it's fixed by reverting those two commits. I believe this is an issue with UFS caching code introduced by the UFS modularisation. Andrew fixed some of it but not all in r294291, I believe the lookup results in try_load would still have been invalid. https://reviews.freebsd.org/D4989 should fix the rest, as well as resulting in much simpler flow IMO. If you could try this that would be great. Regards Steve From owner-freebsd-current@freebsd.org Mon Jan 18 22:46:18 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 44B3AA86E04 for ; Mon, 18 Jan 2016 22:46:18 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CE12515FF for ; Mon, 18 Jan 2016 22:46:17 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: by mail-wm0-x22b.google.com with SMTP id l65so116892313wmf.1 for ; Mon, 18 Jan 2016 14:46:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=dmssAWIhGzsHcM9ebfyNjr7Ug9rlxA/O2g1F/38Zxns=; b=cmaKOD2y8GY4n+uivFqKyrMEuq06Xod7medtehVb3XhDWDGphfG7BIQoEYWJTogBP3 TzuH01L3YPB0f+vvn2fMTAEc5F5ctJZbzhMveiuuo7CXXVXMtMrjdVhxjDGeGacyzkaN WQxGHco/y8AL3B3dFd/G3bQ9AjEGSzLcxWm/2NkDTsNy0HFK36T0QXgto/Z8/7iQ8uyL PW8dyCJZ7+c+eY8QhypsyhFZW0AmA3RjlQ4fTQENX2eAeTgzFVZNBb3EC178YBUR8clQ rtYmZKbskjxH2IbbkUK1iEA5w4EBhK7nz3DKFaunV/hSEV0BlNW6m7hNm829eI5IaK/N oyqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=dmssAWIhGzsHcM9ebfyNjr7Ug9rlxA/O2g1F/38Zxns=; b=jIq62yMafQ9wFHGAe7Dmu4o6xSzKrHVqVBtAQXJZaMufPhlqcXTfPXg1LfzPoe+jYk 9lTRGxKsHk4ZMCd+b8DPQM2OHFDnHXAnpwA446k8RhiUYP6W6nzHSGUlJpHyvbE0jWnO r/HcLL40BwcVlJmuM+aZkG57YK+kYPfJobilBZd+b4EBwm+o3oqunGzLYdJ7CJR++1TJ uZ+ssLRzl1gZUJBkwL4TMBmvZqq3iJbp9px1bLsDHPH7Tuwn3XYEs3ZkvK7eRwC3kng3 HKWa0gZRe4pl3AGbmGVBoRVDYtYpOAnLgvtfhOYcRcUgEdqVZnxeBQ70OxKv6V/R7h9I LE/Q== X-Gm-Message-State: AG10YOTAEVsp0gg2Y4LpBuuPq2h2htvoOvDJcKtQY/Orq/kGCxrcpqCHszUpNS7TOziV5/Gp X-Received: by 10.28.89.69 with SMTP id n66mr16464152wmb.63.1453157175798; Mon, 18 Jan 2016 14:46:15 -0800 (PST) Received: from [10.10.1.58] (liv3d.labs.multiplay.co.uk. [82.69.141.171]) by smtp.gmail.com with ESMTPSA id gb9sm25762589wjb.26.2016.01.18.14.46.14 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Jan 2016 14:46:14 -0800 (PST) Subject: Re: r294248: boot stuck: EFI loader doesn't proceed To: Ed Maste , Andrew Turner References: <20160118072000.4a03a4d2@freyja.zeit4.iv.bundesimmobilien.de> <596CBFC9-275C-445F-9D2B-23B90DB9966A@FreeBSD.org> <20160118113411.2a4d3079@zapp> <569CD4D6.50404@freebsd.org> <20160118202642.4f52614b@zapp> Cc: Dimitry Andric , "O. Hartmann" , freebsd-current From: Steven Hartland Message-ID: <569D6B3A.5090508@multiplay.co.uk> Date: Mon, 18 Jan 2016 22:46:18 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 18 Jan 2016 22:55:27 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 22:46:18 -0000 On 18/01/2016 21:57, Ed Maste wrote: > On 18 January 2016 at 15:26, Andrew Turner wrote: >> the issue was we were caching reads from the first filesystem we looked >> at. I've committed the fix in r294291 to force the code to re-read on >> each filesystem it looks at. > Thanks Andrew - my QEMU boot failure is not reproducible on a build > from a clean tree with this change included. I still think there are issues in there, specifically the lookup call in try_load, which calls fsread should be getting bad results. I believe the code here https://reviews.freebsd.org/D4989 fixes that as well as eliminating fsstat and all the duplicated code. Regards Steve From owner-freebsd-current@freebsd.org Mon Jan 18 23:30:44 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1D121A87E38 for ; Mon, 18 Jan 2016 23:30:44 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from kif.fubar.geek.nz (kif.fubar.geek.nz [178.62.119.249]) by mx1.freebsd.org (Postfix) with ESMTP id DEF731DEA; Mon, 18 Jan 2016 23:30:43 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from zapp (bcdd4360.skybroadband.com [188.221.67.96]) by kif.fubar.geek.nz (Postfix) with ESMTPSA id E1EC1D7A17; Mon, 18 Jan 2016 23:30:12 +0000 (UTC) Date: Mon, 18 Jan 2016 23:30:11 +0000 From: Andrew Turner To: Steven Hartland Cc: Ed Maste , Dimitry Andric , "O. Hartmann" , freebsd-current Subject: Re: r294248: boot stuck: EFI loader doesn't proceed Message-ID: <20160118233011.25314f89@zapp> In-Reply-To: <569D6B3A.5090508@multiplay.co.uk> References: <20160118072000.4a03a4d2@freyja.zeit4.iv.bundesimmobilien.de> <596CBFC9-275C-445F-9D2B-23B90DB9966A@FreeBSD.org> <20160118113411.2a4d3079@zapp> <569CD4D6.50404@freebsd.org> <20160118202642.4f52614b@zapp> <569D6B3A.5090508@multiplay.co.uk> X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 23:30:44 -0000 On Mon, 18 Jan 2016 22:46:18 +0000 Steven Hartland wrote: > On 18/01/2016 21:57, Ed Maste wrote: > > On 18 January 2016 at 15:26, Andrew Turner > > wrote: > >> the issue was we were caching reads from the first filesystem we > >> looked at. I've committed the fix in r294291 to force the code to > >> re-read on each filesystem it looks at. > > Thanks Andrew - my QEMU boot failure is not reproducible on a build > > from a clean tree with this change included. > I still think there are issues in there, specifically the lookup call > in try_load, which calls fsread should be getting bad results. How? fsread will be called with dsk_meta == 0 so it will call the force probe path. Andrew From owner-freebsd-current@freebsd.org Tue Jan 19 00:50:38 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8F3CCA869A8 for ; Tue, 19 Jan 2016 00:50:38 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 6AE2B1010 for ; Tue, 19 Jan 2016 00:50:38 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 68E2FA869A5; Tue, 19 Jan 2016 00:50:38 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4E8B0A869A3 for ; Tue, 19 Jan 2016 00:50:38 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::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 25F37100C for ; Tue, 19 Jan 2016 00:50:37 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: by mail-pa0-x230.google.com with SMTP id uo6so427609452pac.1 for ; Mon, 18 Jan 2016 16:50:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=aEphZJJ3jxGXp3xgtnMKJ827HqY0OFgxE7fQOIiHUW0=; b=KugDHZmdP0+WIV8JCvHIzuDB0wqXLj9tnu+u/okjKDrtLB3yrMnyhyTN5VgHrhXCn9 q1s6JLVlHmZcLBLhkBHtK+6nTEvv5mk0K9eiIm8tvoQ7B09FcTHWK9IQhBsZ94n6lTD2 Eq4CfC9lchpnDi/q4hhYLxADq3m2S0b/a+V1JXRNkd/PcvN6QguaBnxGKDGxFbnC5g/Y sm5SzmhmYPVt6HDOf6gJ7YuvMu5KGgSq4Q4FNQ0jFNaBWKZmfl45/C5xNehwY0UlBZkk F70eHKZPNiC9COm5R8HuVTorpU70zidxByrWiLF0NGJAc6bMcbkqTgwoLaGvMN8Jus3e Ygjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=aEphZJJ3jxGXp3xgtnMKJ827HqY0OFgxE7fQOIiHUW0=; b=ZVC20PJ7nfWWSnL6lzaix6trifggHx0iwmKNNyQHu2V01DHEyt/zGhyEk0gwZJi6TY lSZgfUo6lrUBY2QmaeIxTeOGy6ucmqV18hy1culjIEOJqdE4rxhUd2Mnp0c0Qg+aQPfS HpjR/2fQzVDvO6pbXcCF7XJNFLvvYVEPjTj0864f2DYEe8LLEXwARVaPfJ5+upiGTmZW fScpXIMSEWF7F1WcnTgkN/VT4pau7mqwsvlhtHOhAHmkOcMZ5GnSw5HQInSI5rH0Kt4N xMq6tgmpGeZcgld6rX7hn/McdNIUArNCX0qRfzQpGy7kE4q+kDFUElT+O3xD4d/yRyuH baBg== X-Gm-Message-State: ALoCoQkbpLz7TD/DESBY11lErizX6uk+fo+2qabRRXqB1O9SsBKP+MOD29sGCzzyu69lbm2gTfNOC6wkedxxqhqG3bl+xnSEww== X-Received: by 10.66.142.201 with SMTP id ry9mr41050287pab.89.1453164637357; Mon, 18 Jan 2016 16:50:37 -0800 (PST) Received: from [100.127.145.62] ([69.53.245.26]) by smtp.gmail.com with ESMTPSA id p20sm36580169pfi.86.2016.01.18.16.50.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 18 Jan 2016 16:50:36 -0800 (PST) Sender: Warner Losh Subject: Re: CAM Shingled Disk support patches available Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_D9B23743-1797-4D51-856D-5A96F7555BA3"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Warner Losh In-Reply-To: <20160118223704.GA87506@mithlond.kdm.org> Date: Mon, 18 Jan 2016 16:50:34 -0800 Cc: scsi@freebsd.org, current@freebsd.org Message-Id: <349FCA2B-8346-4EC2-8459-B174FDC2CDB3@bsdimp.com> References: <20151118171309.GA3564@mithlond.kdm.org> <20160118223704.GA87506@mithlond.kdm.org> To: "Kenneth D. Merry" X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 00:50:38 -0000 --Apple-Mail=_D9B23743-1797-4D51-856D-5A96F7555BA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 18, 2016, at 2:37 PM, Kenneth D. Merry wrote: >=20 > I have a new set of SMR patches available. See below for the full > explanation. >=20 > The primary change here is that I have added SMR support to the ada(4) > driver. I spent some time considering whether to try to make the = da(4) and > ada(4) probe infrastructure somewhat common, but in the end concluded = it > would be too involved with not enough code reduction (if any) in the = end. >=20 > So, although the ideas are similar, the probe logic is separate. >=20 > Note that NCQ support for SMR commands (Report Zones, Reset Write = Pointer, > etc.) for SATA protocol shingled drives isn't active. For both the = da(4) > and ada(4) driver this is for lack of a way to plumb the ATA Auxiliary > register down to the drive. I=E2=80=99ve plumbed it down, but in a gross, kludgy way to make NCQ = Trim work where the only value in the Auxiliary register needs to be 1. It only = takes up one bit, but it doesn=E2=80=99t change the size of the CCB. If the = NCQ Trim work wasn=E2=80=99t based on the I/O scheduler, I=E2=80=99d have pushed = it into head and would be happy to share code. AHCI can send it, but it turns out that LSI=E2=80=99s drivers (mpt, mps, = etc) can=E2=80=99t do it due to firmware inadequacies. The ability to send a = FIS in these firmwares looked promising, but it requires a full draining of other requests, which kind of defeats the purpose of NCQ. > In the ada(4) case, we need to add the register to struct ccb_ataio = and > add support in one or more of the underlying SATA drivers, e.g. = ahci(4). I believe that changes the size of the CCB, so I tried to avoid that since I didn=E2=80=99t want to force a recompile of camcontrol(8). Adding it to the atacmd structure wasn=E2=80=99t so bad, and the CCB = size didn=E2=80=99t completely change. The problem was that the atacmd = changed size and pushed all the other fields. > In the da(4) case, it will require an update of the T-10 SAT spec to > provide a way to pass the Auxiliary register down via the SCSI ATA > PASS-THROUGH command, and then a subsquent update of the SAT layer in > various vendors' SAS controller firmware. At that point, there may be > an official mapping of the SCSI ZBC commands to the ATA ZAC commands, = and > we may be able to just issue the SCSI version of the commands instead = of > composing ATA commands in the da(4) driver. (We'll still need to keep = the > ATA passthrough version for a while at least to support controllers = that > don't have the updated translation code.) I looked to implement things here, but didn=E2=80=99t want to invent = something that the T-10 would later reinvent. > FreeBSD/head as of SVN revision 294105: >=20 > https://people.freebsd.org/~ken/cam_smr.head.20160118.1.txt >=20 > FreeBSD stable/10 as of SVN revision 294100: >=20 > https://people.freebsd.org/~ken/cam_smr.stable10.20160118.1.txt >=20 > Testing and comments are welcome. So having said all that, I=E2=80=99m totally open to something better. Warner --Apple-Mail=_D9B23743-1797-4D51-856D-5A96F7555BA3 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 iQIcBAEBCgAGBQJWnYhbAAoJEGwc0Sh9sBEA8twQANJz9qBAsb9LsDw9OAD2j0YG 9/AICl2TX2KEYtVEjobIPzNGtAlsQVNzGquP7SrC6KXLwr6QJb7S92tUpQJczC+I JMx2/ggiA7jlzURlNOjaJCPaBTIMsgtG5RKQWebvElS6K9Iigm25DlbNcL/3b7VR 0WGRGSSmznomtYd8c6IEr3AjzMZlpiLF8Oqsftd080Sd+GpTCj6bEZfIbB++IUSW MxlufkbeWR2nq/LalFoJOTvX7zSOyZ68+1SDawz2A9RgugLkpa1TAdINEDJ0YlqJ 9qr5RJr05tPNnuDyJIeQWrReYBEUqasYefG3TEg3s73DIvvDMPfsWs6ablcKOjYV FXMozxVUHX94/WToMjYzZ65bFuDQv5U7SzF2Pl9KGg2aRpHrudkI8luFPEg6yVCU aHB8Jder83bp0UN1Ta+MPpVwiyq7JPlys4Bco2Bk7p2peR2hkjKIDQMtuOrKNPQB Hn3pgyUu5HfBXRPd3xtIDvBx68G0ezc84MXJZPf+BBffIBI4HKK7bCMMc5NJv74/ +u5eiSumhlPibETKiYChjSvZxUc3EQHv5Q8qYquXu81mxRAuWTIQbD6zkYz8nZOc 0rD70Acm/y8wTPjdik4b2TnYw8i0WqY25u0zBwXzILGa8lR6SrWbB/l8g52ZnDWE t4FbBBXkx8V2MaUh2/TM =xUcY -----END PGP SIGNATURE----- --Apple-Mail=_D9B23743-1797-4D51-856D-5A96F7555BA3-- From owner-freebsd-current@freebsd.org Tue Jan 19 11:45:33 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A837BA88F87 for ; Tue, 19 Jan 2016 11:45:33 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 97F731022 for ; Tue, 19 Jan 2016 11:45:33 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id 950A3A88F82; Tue, 19 Jan 2016 11:45:33 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 94896A88F80; Tue, 19 Jan 2016 11:45:33 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 555BF1020; Tue, 19 Jan 2016 11:45:33 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aLUiy-00072l-0q; Tue, 19 Jan 2016 14:45:24 +0300 Date: Tue, 19 Jan 2016 14:45:23 +0300 From: Slawa Olhovchenkov To: "Kenneth D. Merry" Cc: scsi@freebsd.org, current@freebsd.org Subject: Re: CAM Shingled Disk support patches available Message-ID: <20160119114523.GD37895@zxy.spb.ru> References: <20151118171309.GA3564@mithlond.kdm.org> <20160118223704.GA87506@mithlond.kdm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160118223704.GA87506@mithlond.kdm.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 11:45:33 -0000 On Mon, Jan 18, 2016 at 05:37:04PM -0500, Kenneth D. Merry wrote: > I have a new set of SMR patches available. See below for the full > explanation. > > The primary change here is that I have added SMR support to the ada(4) > driver. I spent some time considering whether to try to make the da(4) and > ada(4) probe infrastructure somewhat common, but in the end concluded it > would be too involved with not enough code reduction (if any) in the end. > > So, although the ideas are similar, the probe logic is separate. > > Note that NCQ support for SMR commands (Report Zones, Reset Write Pointer, > etc.) for SATA protocol shingled drives isn't active. For both the da(4) > and ada(4) driver this is for lack of a way to plumb the ATA Auxiliary > register down to the drive. > > In the ada(4) case, we need to add the register to struct ccb_ataio and > add support in one or more of the underlying SATA drivers, e.g. ahci(4). > > In the da(4) case, it will require an update of the T-10 SAT spec to > provide a way to pass the Auxiliary register down via the SCSI ATA > PASS-THROUGH command, and then a subsquent update of the SAT layer in > various vendors' SAS controller firmware. At that point, there may be > an official mapping of the SCSI ZBC commands to the ATA ZAC commands, and > we may be able to just issue the SCSI version of the commands instead of > composing ATA commands in the da(4) driver. (We'll still need to keep the > ATA passthrough version for a while at least to support controllers that > don't have the updated translation code.) Please, check me: currenly SMR lack of support in SCSI devices? On [hardvare] vendor level? Currenly only SATA controllers compatible with SMR (on command level)? (I am don't talk about FreeBSD support, question about common state). From owner-freebsd-current@freebsd.org Tue Jan 19 12:47:44 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 86865A88EB6 for ; Tue, 19 Jan 2016 12:47:44 +0000 (UTC) (envelope-from mueller6724@bellsouth.net) Received: from nm16-vm6.access.bullet.mail.gq1.yahoo.com (nm16-vm6.access.bullet.mail.gq1.yahoo.com [216.39.63.164]) (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 60A341022 for ; Tue, 19 Jan 2016 12:47:30 +0000 (UTC) (envelope-from mueller6724@bellsouth.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s2048; t=1453207457; bh=eMoWBtluPbMI5f34wqcC9dkwgpdcyfZFSjp6IxZ9pws=; h=Date:From:To:Subject:From:Subject; b=SkiU+3GmneiseJwG2hDsF5gfvn+AEyzDQqtjvaHe6e+tOk9dElAKYfqQuOlR0LMRSLl47M9XHU9aLewPEnV7/aOStFGCaE5kzd4HVHqPj6bsISlL9hAw2WPlRjML8AGEfiA2M4RGXOnKU/mBmggefnnvKfzjf7/RFeDn753W+w9A2XKMl48jG9p/SBKzSdGuOVp7kK/dtYKC5LHqDsVqoHa53fJG3zl/2vD5f/1i91usbLdgiWNJDcoW08hgOsiUVrDHBcLzN6SczfkZ8+wyHi8ABMuSbK9GZDoruVDo20L1Y2Aptb0lV2vdKzy/8hf8r8ezTgi/fEPVmxQ6Jx/ABA== Received: from [216.39.60.170] by nm16.access.bullet.mail.gq1.yahoo.com with NNFMP; 19 Jan 2016 12:44:17 -0000 Received: from [98.138.226.244] by tm6.access.bullet.mail.gq1.yahoo.com with NNFMP; 19 Jan 2016 12:44:17 -0000 Received: from [127.0.0.1] by smtp115.sbc.mail.ne1.yahoo.com with NNFMP; 19 Jan 2016 12:44:16 -0000 X-Yahoo-Newman-Id: 930546.92837.bm@smtp115.sbc.mail.ne1.yahoo.com Message-ID: <930546.92837.bm@smtp115.sbc.mail.ne1.yahoo.com> Date: Tue, 19 Jan 2016 12:44:16 +0000 (UTC) X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: gE25PKMVM1lrg4NZ6QCjrG8dBpb6ZtS9f2cwNaAya.QmJ5G BvkXoa4cQeThq5IzcQSYGTAfd0kjJ4Reju4dy.Ue8TTRKozE8Rgf9JU1sSAj 356CLpTDxk.s7las20c7p3oKdyktYjP_BP8A3pyXnaSzayrUtfQ2dvjop.XJ jhRtpQZkD.giw1BnibgV3G6t6TkrZetbi88rDrsdUVgfTsdCLL3BoW6_w8k7 tWM73f9u6WajHlGbBHpQXJLxrOSK4EFPnOSmiYjtSgZdwkQpN_E58gLR1q0g Kk3oHK3ZMdrKNz9tIsz0VBnmsB6L2CEgEh0CRtDyoTzua43YRBQx5y.VGPph IXOeXuNRVUvbk7lkSdPoJw8D7e2htJAO8q9PO6k6PNP9ALpouekRMnDuKM3f G14IZysEa_XizeJP7.chxUFTcxmvt_v2hA9Q0OKE3cUHUR9GkZ4G26RYnntx 6ZntKsqwXUTHtysWJyhUKDrLf_8DYdpN0tHw78AbjhBhXXxSyS_RUQPhcjRN sg9I8vSoYXKxHodTRIH7eWMvM.OQkqOaRexbVS6MQO63CeHFJcO_o8cKu1vG Swq0ZS2ta X-Yahoo-SMTP: Kz_aW1.swBBYof3zAD7.RWzXz9ZAQVDMml1VADsbgPT4Kq79LC0- From: "Thomas Mueller" To: freebsd-current@freebsd.org Subject: libcrypto.so.7 not found, needed (?) for X server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 12:47:44 -0000 I just updated FreeBSD-current to r294248, and can no longer startx. Error message is xauth: file /home/arlene/.serverauth.1177 does not exist Shared object "libcrypto.so.7" not found, required by "X" xinit: giving up xinit: unable to connect to X server: Connection refused xinit: server error There is /usr/lib/libcrypto.so but notlibcrypto.so.7. I also looked in /usr/local/lib, no libcrypto... files. Now I run pkg info -f xserver and get root@amelia:~ # pkg info -f xserver Shared object "libssl.so.7" not found, required by "pkg" What happened here? Bug in new FreeBSD? uname -a shows FreeBSD amelia 11.0-CURRENT FreeBSD 11.0-CURRENT #10 r294248: Mon Jan 18 11:28:40 UTC 2016 root@amelia:/usr/obj/usr/src/sys/SANDY11NC amd64 Tom From owner-freebsd-current@freebsd.org Tue Jan 19 13:15:13 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63E72A8791F for ; Tue, 19 Jan 2016 13:15:13 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2B6BD1EB4 for ; Tue, 19 Jan 2016 13:15:13 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2a03:fc02:2:1:61da:e08a:17fe:5653] (unknown [IPv6:2a03:fc02:2:1:61da:e08a:17fe:5653]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 33F501A8F1; Tue, 19 Jan 2016 14:15:09 +0100 (CET) Subject: Re: libcrypto.so.7 not found, needed (?) for X server Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_035DA157-2D00-4658-B8B7-C8494BE062A0"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 (ebbf3ef) From: Dimitry Andric In-Reply-To: <930546.92837.bm@smtp115.sbc.mail.ne1.yahoo.com> Date: Tue, 19 Jan 2016 14:17:11 +0100 Cc: freebsd-current@freebsd.org Message-Id: <26A67E1C-7E42-43B5-8433-D5551350B993@FreeBSD.org> References: <930546.92837.bm@smtp115.sbc.mail.ne1.yahoo.com> To: Thomas Mueller X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 13:15:13 -0000 --Apple-Mail=_035DA157-2D00-4658-B8B7-C8494BE062A0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 19 Jan 2016, at 13:44, Thomas Mueller wrote: > > I just updated FreeBSD-current to r294248, and can no longer startx. > > Error message is > > xauth: file /home/arlene/.serverauth.1177 does not exist > > Shared object "libcrypto.so.7" not found, required by "X" > xinit: giving up > xinit: unable to connect to X server: Connection refused > xinit: server error > > There is /usr/lib/libcrypto.so but notlibcrypto.so.7. > > I also looked in /usr/local/lib, no libcrypto... files. > > Now I run > > pkg info -f xserver and get > > root@amelia:~ # pkg info -f xserver > Shared object "libssl.so.7" not found, required by "pkg" > > What happened here? Bug in new FreeBSD? This is explained by the UPDATING entry of October 2015: 20151030: The OpenSSL has been upgraded to 1.0.2d. Any binaries requiring libcrypto.so.7 or libssl.so.7 must be recompiled. -Dimitry --Apple-Mail=_035DA157-2D00-4658-B8B7-C8494BE062A0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.29 iEYEARECAAYFAlaeN2YACgkQsF6jCi4glqMjvACfSxe+m6NkF8yrYTtDjgyigcqg hTwAoKKu9izVd7xL6JDUlWiHWnW5yhAu =2onb -----END PGP SIGNATURE----- --Apple-Mail=_035DA157-2D00-4658-B8B7-C8494BE062A0-- From owner-freebsd-current@freebsd.org Tue Jan 19 13:18:51 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 49637A87A9C for ; Tue, 19 Jan 2016 13:18:51 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1F561121F for ; Tue, 19 Jan 2016 13:18:50 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id u0JDIiYW026203; Tue, 19 Jan 2016 13:18:44 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id u0JDIiil026202; Tue, 19 Jan 2016 05:18:44 -0800 (PST) (envelope-from david) Date: Tue, 19 Jan 2016 05:18:44 -0800 From: David Wolfskill To: Thomas Mueller Cc: freebsd-current@freebsd.org Subject: Re: libcrypto.so.7 not found, needed (?) for X server Message-ID: <20160119131844.GS13446@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Thomas Mueller , freebsd-current@freebsd.org References: <930546.92837.bm@smtp115.sbc.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="O3bhLwMadv7h6/J9" Content-Disposition: inline In-Reply-To: <930546.92837.bm@smtp115.sbc.mail.ne1.yahoo.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 13:18:51 -0000 --O3bhLwMadv7h6/J9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 19, 2016 at 12:44:16PM +0000, Thomas Mueller wrote: > I just updated FreeBSD-current to r294248, and can no longer startx. >=20 > Error message is >=20 > xauth: file /home/arlene/.serverauth.1177 does not exist >=20 > Shared object "libcrypto.so.7" not found, required by "X" > xinit: giving up > xinit: unable to connect to X server: Connection refused > xinit: server error >=20 > There is /usr/lib/libcrypto.so but notlibcrypto.so.7. > .... On my laptop, in the "head" environment, I have: g1-252(10.3-P)[1] cd /S4 g1-252(10.3-P)[2] ls -ltrT usr/lib/libcrypto* -r--r--r-- 1 root wheel 4281880 Dec 28 05:50:18 2015 usr/lib/libcrypto.a -r--r--r-- 1 root wheel 4531590 Dec 28 05:50:18 2015 usr/lib/libcrypto_p= =2Ea lrwxr-xr-x 1 root wheel 24 Jan 19 05:02:24 2016 usr/lib/libcrypto.s= o -> ../../lib/libcrypto.so.8 g1-252(10.3-P)[3]=20 But I normally run -- and biuld my ports -- in a stable/10 environment, so: g1-252(10.3-P)[1] ldd `which X` | grep crypto libcrypto.so.7 =3D> /lib/libcrypto.so.7 (0x800c84000) g1-252(10.3-P)[2] ls -ltrT /lib/libcrypto* -r--r--r-- 1 root wheel 2039072 Jan 19 04:28:19 2016 /lib/libcrypto.so.7 g1-252(10.3-P)[3] ls -ltrT /usr/lib/libcrypto* -r--r--r-- 1 root wheel 3927330 Dec 4 04:36:08 2015 /usr/lib/libcrypto.a -r--r--r-- 1 root wheel 4158890 Dec 4 04:36:08 2015 /usr/lib/libcrypto_= p.a lrwxr-xr-x 1 root wheel 19 Jan 19 04:28:19 2016 /usr/lib/libcrypto.= so -> /lib/libcrypto.so.7 g1-252(10.3-P)[4]=20 Finally, something that you may find useful in all this nattering: g1-252(10.3-P)[4] pkg which /usr/local/lib/compat/libcrypto.so.7=20 /usr/local/lib/compat/libcrypto.so.7 was installed by package compat10x-amd= 64-10.2.1002000.20151116 g1-252(10.3-P)[5] pkg info -o compat10x-amd64-10.2.1002000.20151116 compat10x-amd64-10.2.1002000.20151116 misc/compat10x g1-252(10.3-P)[6]=20 That is, it looks as if you're trying to run X built under stable/10 while you're running head. You will almost certainly want to install misc/compat10x. Alternatively, delete & re-build/install all ports/packages under head. Peace, david --=20 David H. Wolfskill david@catwhisker.org Those who would murder in the name of God or prophet are blasphemous coward= s. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --O3bhLwMadv7h6/J9 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJWnje0XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XsqYIAKyXM0tmr9ScznV1LnurMC5O F8usgN+x6Ufjv5zY3UFWMIs7It02Ri4NHYg7J49edJSQRPR7sm+z5SRgC2/0z5L6 hScLQU3rpy8RIIKA+jW9sqxf0gDNFG8ZuCk2xAdCWk/P8nWjN3DdMLZY+6DEe8FQ w7BAphCTgdZnYL5Hg10DI42aLxBtpguMtE7iDsqE0K41zWZBXugtEfGQQClcV4pA 4m34BoKNcZcHUYZSVL+xiFQjkeR0eYU+ltdjA73DLPScP77gWBn0eEV2IMfc3pv5 +j6O/xhoFMyu+/FHKy1wx6+Sb84EjA7CfL3EvhQg88b0vjgADdXR1DN0mG8ZZUA= =V2Vy -----END PGP SIGNATURE----- --O3bhLwMadv7h6/J9-- From owner-freebsd-current@freebsd.org Tue Jan 19 11:30:37 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2AD5CA88995; Tue, 19 Jan 2016 11:30:37 +0000 (UTC) (envelope-from prvs=819158b4b=wei.liu2@citrix.com) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Verizon Public SureServer CA G14-SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 982201381; Tue, 19 Jan 2016 11:30:36 +0000 (UTC) (envelope-from prvs=819158b4b=wei.liu2@citrix.com) X-IronPort-AV: E=Sophos;i="5.22,317,1449532800"; d="scan'208";a="332371081" Date: Tue, 19 Jan 2016 11:30:28 +0000 From: Wei Liu To: Roger Pau =?iso-8859-1?Q?Monn=E9?= CC: Daisuke Aoyama , , , Wei Liu Subject: Re: Xen/dom0/FreeBSD + NAS4Free WebGUI. Message-ID: <20160119113028.GT1691@citrix.com> References: <86DF039090BD474AA2CB2795F6C7A0C7@ad.peach.ne.jp> <5681371F.6090007@FreeBSD.org> <5694FE5B.2070509@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5694FE5B.2070509@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-DLP: MIA2 X-Mailman-Approved-At: Tue, 19 Jan 2016 13:19:49 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 11:30:37 -0000 On Tue, Jan 12, 2016 at 02:23:39PM +0100, Roger Pau Monné wrote: [...] > I'm adding Wei to the Cc, he has been working on netfront improvements, > so maybe he also wants to take a stab at netback ;). It's on my radar but I don't have time for it in the near future. If anyone else who is watching FreeBSD Xen implementation have the desire to improve it I'm happy to help. Wei. From owner-freebsd-current@freebsd.org Tue Jan 19 13:20:36 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 010BAA87BD8 for ; Tue, 19 Jan 2016 13:20:36 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4ED4914D2 for ; Tue, 19 Jan 2016 13:20:35 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA09734 for ; Tue, 19 Jan 2016 15:17:24 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1aLWA0-0004QW-6N for freebsd-current@FreeBSD.org; Tue, 19 Jan 2016 15:17:24 +0200 Subject: Re: environment corrupt; missing value for QT_IM_MO To: FreeBSD Current References: <5514E5B0.1030509@rawbw.com> <568B8291.50700@FreeBSD.org> <568B84DC.7080705@FreeBSD.org> From: Andriy Gapon X-Enigmail-Draft-Status: N1110 Message-ID: <569E3713.1060601@FreeBSD.org> Date: Tue, 19 Jan 2016 15:16:03 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <568B84DC.7080705@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 13:20:36 -0000 On 05/01/2016 10:54, Andriy Gapon wrote: > On 05/01/2016 10:45, Andriy Gapon wrote: >> >> Very weird, this suddenly started happening to me but with libreoffice. I can >> not correlate the problem with any actions / events. >> >> stderr: >> soffice.bin: environment corrupt; missing value for QT_IM_MO >> >> gdb: >> Core was generated by `soffice.bin'. >> Program terminated with signal SIGABRT, Aborted. >> #0 thr_kill () at thr_kill.S:3 >> 3 RSYSCALL(thr_kill) >> [Current thread is 2 (Thread 816615000 (LWP 102134))] >> (gdb) bt >> #0 thr_kill () at thr_kill.S:3 >> #1 0x0000000800dc5ddb in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52 >> #2 0x0000000800dc5d49 in abort () at /usr/src/lib/libc/stdlib/abort.c:65 >> #3 0x0000000805231318 in tools::extendApplicationEnvironment() () from >> /usr/local/lib/libreoffice/program/libtllo.so >> >> Smells like a possible bug in libc... > > Is there a limit on the environment's size? > QT_IM_MODULE is reported by ps as the last variable. I have taken another look at the problem and I've discovered that the affected variable is corrupted in a peculiar way: (kgdb) p environ[61] $23 = 0x7fffffffef45 "QT_IM_MO" (kgdb) x/s 0x7fffffffef45 0x7fffffffef45: "QT_IM_MO" (kgdb) x/s 0x7fffffffef4d 0x7fffffffef4d: "" (kgdb) x/s 0x7fffffffef4e 0x7fffffffef4e: "" (kgdb) x/s 0x7fffffffef4f 0x7fffffffef4f: "" (kgdb) x/s 0x7fffffffef50 0x7fffffffef50: "" (kgdb) x/s 0x7fffffffef51 0x7fffffffef51: "=xim" (kgdb) p environ[62] $42 = 0x0 So, it's "QT_IM_MODULE=xim" with 4 bytes (corresponding to "DULE") replaced with zeroes. This is 100% reproducible in my current environment, so it could be a deterministic write to a wrong offset. -- Andriy Gapon From owner-freebsd-current@freebsd.org Tue Jan 19 12:54:00 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E540A8721B for ; Tue, 19 Jan 2016 12:54:00 +0000 (UTC) (envelope-from James@Lodge.me.uk) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0114.outbound.protection.outlook.com [157.55.234.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F352513CE for ; Tue, 19 Jan 2016 12:53:58 +0000 (UTC) (envelope-from James@Lodge.me.uk) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gavinlodge.onmicrosoft.com; s=selector1-Lodge-me-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NBo3TXmzk/5/GWpsFSL8URtxZ1M52add+FiiDUHM8Sc=; b=am6Ntt11kct4poiyBaacuC1cZnQ1fzHkJMwZCaDz/xAzAUaEwc5we8B62/yToCf3ZGpPD3XU3gKM079IMYQ3wp3G9sKNP9hStTqZUe7KOWQ9gy1l/fEucSBpSSyP0+PF7n3dexO6ZdCPmXhmE47+BK8ZDA5tOWty+u+l49bkUVg= Received: from VI1PR06MB1037.eurprd06.prod.outlook.com (10.162.123.156) by VI1PR06MB1037.eurprd06.prod.outlook.com (10.162.123.156) with Microsoft SMTP Server (TLS) id 15.1.365.19; Tue, 19 Jan 2016 12:53:50 +0000 Received: from VI1PR06MB1037.eurprd06.prod.outlook.com ([10.162.123.156]) by VI1PR06MB1037.eurprd06.prod.outlook.com ([10.162.123.156]) with mapi id 15.01.0365.023; Tue, 19 Jan 2016 12:53:50 +0000 From: James Lodge To: Thomas Mueller , "freebsd-current@freebsd.org" Subject: Re: libcrypto.so.7 not found, needed (?) for X server Thread-Topic: libcrypto.so.7 not found, needed (?) for X server Thread-Index: AQHRUrelamsHuKXkEkWwpxFCxS8Mrp8CygVV Date: Tue, 19 Jan 2016 12:53:49 +0000 Message-ID: References: <930546.92837.bm@smtp115.sbc.mail.ne1.yahoo.com> In-Reply-To: <930546.92837.bm@smtp115.sbc.mail.ne1.yahoo.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=James@Lodge.me.uk; x-originating-ip: [86.17.49.22] x-microsoft-exchange-diagnostics: 1; VI1PR06MB1037; 5:IrO8kyARyLjQi9hH/yfd+tSrD0+H2tOHQp0HCVku+xHLLgxEgfPpSaRdlzj0pBq/TVnwPn5oLfAJ2lOh0bYdEgw/LEY5Xdb4p3t4AICS6CZvdQzysZ0aJcBhidaogWVwE1MDzOOJ4fAIzfDH1igWUw==; 24:O6QGCngU9OpldEYB8gaLPurMHler7LP0gTGI06n782l0vG7pFn0zN4r9lzVawjJCIDCzzyXwiaosPBejqFusnBTCxAE8Qo7jk9dri+raUk8= x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42134001)(42139001); SRVR:VI1PR06MB1037; x-ms-office365-filtering-correlation-id: a3c9a701-4b70-4a33-deab-08d320cf9413 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:VI1PR06MB1037; BCL:0; PCL:0; RULEID:; SRVR:VI1PR06MB1037; x-forefront-prvs: 0826B2F01B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(45914002)(1096002)(50986999)(11100500001)(2900100001)(54356999)(5002640100001)(33656002)(586003)(87936001)(92566002)(77096005)(66066001)(2501003)(5001960100002)(74316001)(101416001)(80792005)(15975445007)(189998001)(107886002)(2950100001)(6116002)(10400500002)(5004730100002)(19580395003)(19580405001)(5003600100002)(2906002)(3846002)(5001770100001)(40100003)(86362001)(74482002)(76176999)(76576001)(106116001)(105586002)(5008740100001)(122556002)(1220700001)(81156007)(97736004)(102836003)(106356001)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR06MB1037; H:VI1PR06MB1037.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: Lodge.me.uk does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Lodge.me.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2016 12:53:49.9333 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ded56ae9-7c77-4cf6-bbfd-39e6a505742d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR06MB1037 X-Mailman-Approved-At: Tue, 19 Jan 2016 13:43:01 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 12:54:00 -0000 >I just updated FreeBSD-current to r294248, and can no longer startx. >Error message is >xauth: file /home/arlene/.serverauth.1177 does not exist >Shared object "libcrypto.so.7" not found, required by "X" >xinit: giving up >xinit: unable to connect to X server: Connection refused >xinit: server error >There is /usr/lib/libcrypto.so but notlibcrypto.so.7. >I also looked in /usr/local/lib, no libcrypto... files. >Now I run >pkg info -f xserver and get >root@amelia:~ # pkg info -f xserver >Shared object "libssl.so.7" not found, required by "pkg" >What happened here? Bug in new FreeBSD? > uname -a shows >FreeBSD amelia 11.0-CURRENT FreeBSD 11.0-CURRENT #10 r294248: Mon Jan 18 1= 1:28:40 UTC 2016 >root@amelia:/usr/obj/usr/src/sys/SANDY11NC amd64 >Tom >_______________________________________________ >freebsd-current@freebsd.org mailing list >https://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" I had exactly the same issue with 11.0-CURRENT r294227, libssl.so.7 missing= . I ended up building OpenSSL from ports to resolve.....Probably not the an= swer, but a work around.=20 =20 From owner-freebsd-current@freebsd.org Tue Jan 19 14:06:18 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F0C02A88EEE for ; Tue, 19 Jan 2016 14:06:18 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 933C71E11; Tue, 19 Jan 2016 14:06:18 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by mail-lb0-x22d.google.com with SMTP id cl12so146462222lbc.1; Tue, 19 Jan 2016 06:06:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=fC6LhgPDgXUgDx770bXRbPTTWKVeelxeH4D3xbFfVRs=; b=cJhgQpqEwbZJLr4Qa+riDgKBu+8tYV5TZevFeCpSninZL4HKUHoPUs6JdnplM7fEkr ffkKHZQmA8AUpr5VraiqqZdcaZjllcatd6YgEekLMIS/usGTcV6zsos1i4szFfhXrBee kmaSBda3fn4BPbOtsg/jk1oVD67ch6f51KVLp4ZN5UFbw0ryAEQYRY0DWzpDWSE22Mwb ufsdlqG977jtjj+vjBbwOOuSWdAhrtvWej4yn5QLvgLN6LZQJf50I83xRUMf7DGSP3Z6 mFlLCv7MDDdWHcIAOk7Huig1JrlbLOOQO6AZW+/uIEqGx02vvXHe7mpwncSJ049kgNW8 fuOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=fC6LhgPDgXUgDx770bXRbPTTWKVeelxeH4D3xbFfVRs=; b=jp5BOPkzLHfV5CXR384WGG1Y64FaPB7TTq25ZeFwiM9J9ylrBDtca4ZZkC1CoUaCW3 Dz6csCIFIS8/H6RVoiSr8/2YsvTLO97OjoT4qDRLCzLqgt65u6/NIyYZbA0kMpQdrBqz tltcdclZpjjNised8lGF+VeuiwkwyQyErRgSRlH0i+JSqhRyRBJbbbGZ5AlGBkxPIMkj uKJO+zOsMrxEczQR5ZOsZN+xCKZYHonfWjrzJZeDTHFZ2PDIzboP9HLXE8DIshunGPTo X1drmXEYKbm9dni8PqplEKidkbOUEDfJ5+14jGKpkk0Hn3i0QvrtPLST+2/oX9R/xRUi eelQ== X-Gm-Message-State: ALoCoQme3XLU2fzv98zelMCdRAQ+5A5hhFcxYUBdAaECF4+W3KxhVy40N35InA55+A8M19dsnMCyBfZ6cI0gMcMCVxggzZ+06g== X-Received: by 10.112.167.161 with SMTP id zp1mr10885330lbb.2.1453212375615; Tue, 19 Jan 2016 06:06:15 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by smtp.gmail.com with ESMTPSA id ot1sm3915323lbb.26.2016.01.19.06.06.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jan 2016 06:06:14 -0800 (PST) Sender: Baptiste Daroussin Date: Tue, 19 Jan 2016 15:06:12 +0100 From: Baptiste Daroussin To: Dimitry Andric Cc: Thomas Mueller , freebsd-current@freebsd.org Subject: Re: libcrypto.so.7 not found, needed (?) for X server Message-ID: <20160119140611.GC69902@ivaldir.etoilebsd.net> References: <930546.92837.bm@smtp115.sbc.mail.ne1.yahoo.com> <26A67E1C-7E42-43B5-8433-D5551350B993@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7gGkHNMELEOhSGF6" Content-Disposition: inline In-Reply-To: <26A67E1C-7E42-43B5-8433-D5551350B993@FreeBSD.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 14:06:19 -0000 --7gGkHNMELEOhSGF6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 19, 2016 at 02:17:11PM +0100, Dimitry Andric wrote: > On 19 Jan 2016, at 13:44, Thomas Mueller wrot= e: > >=20 > > I just updated FreeBSD-current to r294248, and can no longer startx. > >=20 > > Error message is > >=20 > > xauth: file /home/arlene/.serverauth.1177 does not exist > >=20 > > Shared object "libcrypto.so.7" not found, required by "X" > > xinit: giving up > > xinit: unable to connect to X server: Connection refused > > xinit: server error > >=20 > > There is /usr/lib/libcrypto.so but notlibcrypto.so.7. > >=20 > > I also looked in /usr/local/lib, no libcrypto... files. > >=20 > > Now I run > >=20 > > pkg info -f xserver and get > >=20 > > root@amelia:~ # pkg info -f xserver > > Shared object "libssl.so.7" not found, required by "pkg" > >=20 > > What happened here? Bug in new FreeBSD? >=20 > This is explained by the UPDATING entry of October 2015: >=20 > 20151030: > The OpenSSL has been upgraded to 1.0.2d. Any binaries requiring > libcrypto.so.7 or libssl.so.7 must be recompiled. >=20 Given how long ago this happen a simple pkg-static upgrade -f would do the = trick because all available packages has been rebuilt in the cluster since and ha= ve been published. All official packages for head are linked against newer libcrypto.so and libssl.so Best regards, Bapt --7gGkHNMELEOhSGF6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWnkLTAAoJEGOJi9zxtz5aXJMQAJtTxZwt3zuyL5eoPtyGNCoP 2KA2uhKTspHRyGg02FCZexwbKDnv6W/o0hDKfU1UBXgJ4P/630b7GblHhyxAo8My JSDdinduxlqm/W1oDqOKBbbGZZ+01Soy993gQAlcrkB3iNUkyb2h14X/3CEeJdO3 FW17fV3uHI/huLXYzOwS+OfIzUnI5PaJTSyk9eJ5Je2n1XN2/3TyNnvHBn1MBsO4 oKXwrAGT9WwdKxiM37y+0w0Zwz5OSRfJpDHZhgJb8sjt+21aQsdX8rMBbmHbdha8 ImbIPCEfGG3eZKSWXefKKfDxk42RRmK3E4rJlLGqCx92r5O6A1Aj+UrOjZPqhmrE HAum/75TVReu/dZ5QQRIll71MLt5bDrHtYFdr6nEsPQllWM60ekmT8d0B/5trK/m 90Jn5W34J5BEJoD53hDhbQEcpB9yB02nkm+Lw9Ww6Jbz/l1Tmxp2DzIofoD1IQOQ L6ZlRqkRddv5IAna4Rjh+82VWan+535E2PtTT9o+ZZypa0PShO5jTeo9Mi6c4NYT 6dacU8uMpKdQn1nFBCfhg16BvarkMh8K3kr3oIx0l315phvIqjr0V7wxJBwrNFoK 6sYq1sJl7LKQnqRKuDn0NCatY1QJWuwL5SmAaav+uEl9Cg+jKqaVhP0PvRRcOfB6 +0lxwsU7FQqRvxT0lrH3 =SoLH -----END PGP SIGNATURE----- --7gGkHNMELEOhSGF6-- From owner-freebsd-current@freebsd.org Tue Jan 19 16:25:59 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CE306A8910B for ; Tue, 19 Jan 2016 16:25:59 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B812D10FE for ; Tue, 19 Jan 2016 16:25:59 +0000 (UTC) (envelope-from ken@kdm.org) Received: by mailman.ysv.freebsd.org (Postfix) id B5745A89109; Tue, 19 Jan 2016 16:25:59 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B4E7DA89108; Tue, 19 Jan 2016 16:25:59 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (mithlond.kdm.org [96.89.93.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "A1-33714", Issuer "A1-33714" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 71BA110FD; Tue, 19 Jan 2016 16:25:59 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (localhost [127.0.0.1]) by mithlond.kdm.org (8.15.2/8.14.9) with ESMTPS id u0JGPuip001151 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 19 Jan 2016 11:25:56 -0500 (EST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.15.2/8.14.9/Submit) id u0JGPu1L001150; Tue, 19 Jan 2016 11:25:56 -0500 (EST) (envelope-from ken) Date: Tue, 19 Jan 2016 11:25:56 -0500 From: "Kenneth D. Merry" To: Warner Losh Cc: scsi@freebsd.org, current@freebsd.org Subject: Re: CAM Shingled Disk support patches available Message-ID: <20160119162555.GA99885@mithlond.kdm.org> References: <20151118171309.GA3564@mithlond.kdm.org> <20160118223704.GA87506@mithlond.kdm.org> <349FCA2B-8346-4EC2-8459-B174FDC2CDB3@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <349FCA2B-8346-4EC2-8459-B174FDC2CDB3@bsdimp.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [127.0.0.1]); Tue, 19 Jan 2016 11:25:56 -0500 (EST) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mithlond.kdm.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 16:26:00 -0000 On Mon, Jan 18, 2016 at 16:50:34 -0800, Warner Losh wrote: > > > On Jan 18, 2016, at 2:37 PM, Kenneth D. Merry wrote: > > > > I have a new set of SMR patches available. See below for the full > > explanation. > > > > The primary change here is that I have added SMR support to the ada(4) > > driver. I spent some time considering whether to try to make the da(4) and > > ada(4) probe infrastructure somewhat common, but in the end concluded it > > would be too involved with not enough code reduction (if any) in the end. > > > > So, although the ideas are similar, the probe logic is separate. > > > > Note that NCQ support for SMR commands (Report Zones, Reset Write Pointer, > > etc.) for SATA protocol shingled drives isn't active. For both the da(4) > > and ada(4) driver this is for lack of a way to plumb the ATA Auxiliary > > register down to the drive. > > I???ve plumbed it down, but in a gross, kludgy way to make NCQ Trim work > where the only value in the Auxiliary register needs to be 1. It only takes > up one bit, but it doesn???t change the size of the CCB. If the NCQ Trim > work wasn???t based on the I/O scheduler, I???d have pushed it into head > and would be happy to share code. Yeah, for SMR, we'll need to pass the full register down. That is how you specify the service action (open, close, finish, reset write pointer, report zones). > AHCI can send it, but it turns out that LSI???s drivers (mpt, mps, etc) > can???t do it due to firmware inadequacies. The ability to send a FIS > in these firmwares looked promising, but it requires a full draining of > other requests, which kind of defeats the purpose of NCQ. Yeah, that would kinda defeat the purpose. I'm sending a SCSI command (ATA PASS-THROUGH) to get the SATA zone commands down there. Those are treated like an ordered tag by the LSI firmware as well. Which is just as well, since there is no way to specify the Auxiliary register via that SCSI command, and so we can't do NCQ anyway. LSI/Avago said they're planning to support the zone commands in the SAT layer in the HBAs in the 12Gb boards. Phase 10 doesn't have it from what I understand, but hopefully that'll show up soon. The translation is in the latest SAT draft, and it is very straightforward to map from one to the other, because the SCSI and ATA commands and semantics are pretty much identical. > > In the ada(4) case, we need to add the register to struct ccb_ataio and > > add support in one or more of the underlying SATA drivers, e.g. ahci(4). > > I believe that changes the size of the CCB, so I tried to avoid > that since I didn???t want to force a recompile of camcontrol(8). > Adding it to the atacmd structure wasn???t so bad, and the CCB size > didn???t completely change. The problem was that the atacmd changed > size and pushed all the other fields. Yes. In order to do it, we'll need to add it to struct atacmd, and add compatibility shims. I don't see another way to do it unfortunately. > > In the da(4) case, it will require an update of the T-10 SAT spec to > > provide a way to pass the Auxiliary register down via the SCSI ATA > > PASS-THROUGH command, and then a subsquent update of the SAT layer in > > various vendors' SAS controller firmware. At that point, there may be > > an official mapping of the SCSI ZBC commands to the ATA ZAC commands, and > > we may be able to just issue the SCSI version of the commands instead of > > composing ATA commands in the da(4) driver. (We'll still need to keep the > > ATA passthrough version for a while at least to support controllers that > > don't have the updated translation code.) > > I looked to implement things here, but didn???t want to invent something that > the T-10 would later reinvent. Yeah. Is NCQ trim a new thing? Is that why you were looking at sending it down via a FIS? If so, it is likely that LSI will add it to the SCSI Unmap translation in the firmware. Of course if it isn't already in there, they're only going to put it in their 12Gb controllers and not in the 6Gb controllers at this point. Since the SAT spec has the mapping for the SCSI ZBC -> ZAC commands, it sounds like that'll make it into the LSI 12Gb firmware at some point. > > FreeBSD/head as of SVN revision 294105: > > > > https://people.freebsd.org/~ken/cam_smr.head.20160118.1.txt > > > > FreeBSD stable/10 as of SVN revision 294100: > > > > https://people.freebsd.org/~ken/cam_smr.stable10.20160118.1.txt > > > > Testing and comments are welcome. > > So having said all that, I???m totally open to something better. I think that for the ATA side, we'll just have to add the register to the CCB, bump the version and add compatibility shims. For the SCSI side, we just need a way to probe and see whether the translation is supported in the SAT layer (at least for the ZBC commands, I don't know about trim) and use the SCSI command if it is supported, otherwise use the ATA PASS-THROUGH command if it is not. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-current@freebsd.org Tue Jan 19 16:38:36 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F2EA3A894C1 for ; Tue, 19 Jan 2016 16:38:35 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id D87801896 for ; Tue, 19 Jan 2016 16:38:35 +0000 (UTC) (envelope-from ken@kdm.org) Received: by mailman.ysv.freebsd.org (Postfix) id D5C06A894C0; Tue, 19 Jan 2016 16:38:35 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BB400A894BE; Tue, 19 Jan 2016 16:38:35 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (mithlond.kdm.org [96.89.93.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "A1-33714", Issuer "A1-33714" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 964E91895; Tue, 19 Jan 2016 16:38:35 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (localhost [127.0.0.1]) by mithlond.kdm.org (8.15.2/8.14.9) with ESMTPS id u0JGcXBp001283 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 19 Jan 2016 11:38:33 -0500 (EST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.15.2/8.14.9/Submit) id u0JGcVuh001282; Tue, 19 Jan 2016 11:38:31 -0500 (EST) (envelope-from ken) Date: Tue, 19 Jan 2016 11:38:31 -0500 From: "Kenneth D. Merry" To: Slawa Olhovchenkov Cc: scsi@freebsd.org, current@freebsd.org Subject: Re: CAM Shingled Disk support patches available Message-ID: <20160119163831.GB99885@mithlond.kdm.org> References: <20151118171309.GA3564@mithlond.kdm.org> <20160118223704.GA87506@mithlond.kdm.org> <20160119114523.GD37895@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160119114523.GD37895@zxy.spb.ru> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [127.0.0.1]); Tue, 19 Jan 2016 11:38:33 -0500 (EST) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mithlond.kdm.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 16:38:36 -0000 On Tue, Jan 19, 2016 at 14:45:23 +0300, Slawa Olhovchenkov wrote: > On Mon, Jan 18, 2016 at 05:37:04PM -0500, Kenneth D. Merry wrote: > > > I have a new set of SMR patches available. See below for the full > > explanation. > > > > The primary change here is that I have added SMR support to the ada(4) > > driver. I spent some time considering whether to try to make the da(4) and > > ada(4) probe infrastructure somewhat common, but in the end concluded it > > would be too involved with not enough code reduction (if any) in the end. > > > > So, although the ideas are similar, the probe logic is separate. > > > > Note that NCQ support for SMR commands (Report Zones, Reset Write Pointer, > > etc.) for SATA protocol shingled drives isn't active. For both the da(4) > > and ada(4) driver this is for lack of a way to plumb the ATA Auxiliary > > register down to the drive. > > > > In the ada(4) case, we need to add the register to struct ccb_ataio and > > add support in one or more of the underlying SATA drivers, e.g. ahci(4). > > > > In the da(4) case, it will require an update of the T-10 SAT spec to > > provide a way to pass the Auxiliary register down via the SCSI ATA > > PASS-THROUGH command, and then a subsquent update of the SAT layer in > > various vendors' SAS controller firmware. At that point, there may be > > an official mapping of the SCSI ZBC commands to the ATA ZAC commands, and > > we may be able to just issue the SCSI version of the commands instead of > > composing ATA commands in the da(4) driver. (We'll still need to keep the > > ATA passthrough version for a while at least to support controllers that > > don't have the updated translation code.) > > Please, check me: currenly SMR lack of support in SCSI devices? On > [hardvare] vendor level? Currenly only SATA controllers compatible > with SMR (on command level)? (I am don't talk about FreeBSD support, > question about common state). No, there are SAS/SCSI SMR drives in development, and there is the SCSI ZBC spec that defines the command set. I don't know whether any vendors are shipping SAS/SCSI SMR drives yet. You can use SATA drives (SMR or not) with either a SATA controller or a SAS controller. But the way you talk to a SATA drive through a SAS controller is with SCSI commands. There is a SCSI spec (SAT) that defines the mapping of SCSI commands to ATA commands. It has recently been updated to support mapping SMR commands from SCSI to ATA, but most (all?) SAS controllers have not caught up with the spec. So to use a SATA SMR drive with a SAS controller that doesn't know how to map SMR commands from SCSI to ATA, you have to send the ATA SMR commands through the SCSI ATA PASS-THROUGH command. That just bypasses the usual translations, and allows sending ATA commands in something like their native form. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-current@freebsd.org Tue Jan 19 17:02:56 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C9D06A89C7D for ; Tue, 19 Jan 2016 17:02:56 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id AFA971ADC for ; Tue, 19 Jan 2016 17:02:56 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id ADE88A89C7B; Tue, 19 Jan 2016 17:02:56 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 93726A89C7A; Tue, 19 Jan 2016 17:02:56 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 51E091AD9; Tue, 19 Jan 2016 17:02:56 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aLZgC-000EMi-S8; Tue, 19 Jan 2016 20:02:52 +0300 Date: Tue, 19 Jan 2016 20:02:52 +0300 From: Slawa Olhovchenkov To: "Kenneth D. Merry" Cc: scsi@freebsd.org, current@freebsd.org Subject: Re: CAM Shingled Disk support patches available Message-ID: <20160119170252.GC88527@zxy.spb.ru> References: <20151118171309.GA3564@mithlond.kdm.org> <20160118223704.GA87506@mithlond.kdm.org> <20160119114523.GD37895@zxy.spb.ru> <20160119163831.GB99885@mithlond.kdm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160119163831.GB99885@mithlond.kdm.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 17:02:57 -0000 On Tue, Jan 19, 2016 at 11:38:31AM -0500, Kenneth D. Merry wrote: > On Tue, Jan 19, 2016 at 14:45:23 +0300, Slawa Olhovchenkov wrote: > > On Mon, Jan 18, 2016 at 05:37:04PM -0500, Kenneth D. Merry wrote: > > > > > I have a new set of SMR patches available. See below for the full > > > explanation. > > > > > > The primary change here is that I have added SMR support to the ada(4) > > > driver. I spent some time considering whether to try to make the da(4) and > > > ada(4) probe infrastructure somewhat common, but in the end concluded it > > > would be too involved with not enough code reduction (if any) in the end. > > > > > > So, although the ideas are similar, the probe logic is separate. > > > > > > Note that NCQ support for SMR commands (Report Zones, Reset Write Pointer, > > > etc.) for SATA protocol shingled drives isn't active. For both the da(4) > > > and ada(4) driver this is for lack of a way to plumb the ATA Auxiliary > > > register down to the drive. > > > > > > In the ada(4) case, we need to add the register to struct ccb_ataio and > > > add support in one or more of the underlying SATA drivers, e.g. ahci(4). > > > > > > In the da(4) case, it will require an update of the T-10 SAT spec to > > > provide a way to pass the Auxiliary register down via the SCSI ATA > > > PASS-THROUGH command, and then a subsquent update of the SAT layer in > > > various vendors' SAS controller firmware. At that point, there may be > > > an official mapping of the SCSI ZBC commands to the ATA ZAC commands, and > > > we may be able to just issue the SCSI version of the commands instead of > > > composing ATA commands in the da(4) driver. (We'll still need to keep the > > > ATA passthrough version for a while at least to support controllers that > > > don't have the updated translation code.) > > > > Please, check me: currenly SMR lack of support in SCSI devices? On > > [hardvare] vendor level? Currenly only SATA controllers compatible > > with SMR (on command level)? (I am don't talk about FreeBSD support, > > question about common state). > > No, there are SAS/SCSI SMR drives in development, and there is the SCSI ZBC > spec that defines the command set. I don't know whether any vendors are > shipping SAS/SCSI SMR drives yet. > > You can use SATA drives (SMR or not) with either a SATA controller or a SAS > controller. But the way you talk to a SATA drive through a SAS controller > is with SCSI commands. There is a SCSI spec (SAT) that defines the mapping > of SCSI commands to ATA commands. It has recently been updated to support > mapping SMR commands from SCSI to ATA, but most (all?) SAS controllers > have not caught up with the spec. > > So to use a SATA SMR drive with a SAS controller that doesn't know how to > map SMR commands from SCSI to ATA, you have to send the ATA SMR commands > through the SCSI ATA PASS-THROUGH command. That just bypasses the usual > translations, and allows sending ATA commands in something like their > native form. What in case of expanders an port replicatiors (SATA drives and HBA SAS controllers, of course)? Need expander be compatible with SMR? Or any expander with SATA support automaticly compatible? From owner-freebsd-current@freebsd.org Tue Jan 19 17:06:43 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F27E6A89D8B for ; Tue, 19 Jan 2016 17:06:43 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id DC2621D69 for ; Tue, 19 Jan 2016 17:06:43 +0000 (UTC) (envelope-from ken@kdm.org) Received: by mailman.ysv.freebsd.org (Postfix) id D98E6A89D8A; Tue, 19 Jan 2016 17:06:43 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D900CA89D88; Tue, 19 Jan 2016 17:06:43 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (mithlond.kdm.org [96.89.93.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "A1-33714", Issuer "A1-33714" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B3E521D68; Tue, 19 Jan 2016 17:06:43 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (localhost [127.0.0.1]) by mithlond.kdm.org (8.15.2/8.14.9) with ESMTPS id u0JH6fEf001714 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 19 Jan 2016 12:06:41 -0500 (EST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.15.2/8.14.9/Submit) id u0JH6fXv001713; Tue, 19 Jan 2016 12:06:41 -0500 (EST) (envelope-from ken) Date: Tue, 19 Jan 2016 12:06:41 -0500 From: "Kenneth D. Merry" To: Slawa Olhovchenkov Cc: scsi@freebsd.org, current@freebsd.org Subject: Re: CAM Shingled Disk support patches available Message-ID: <20160119170641.GA1669@mithlond.kdm.org> References: <20151118171309.GA3564@mithlond.kdm.org> <20160118223704.GA87506@mithlond.kdm.org> <20160119114523.GD37895@zxy.spb.ru> <20160119163831.GB99885@mithlond.kdm.org> <20160119170252.GC88527@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160119170252.GC88527@zxy.spb.ru> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [127.0.0.1]); Tue, 19 Jan 2016 12:06:41 -0500 (EST) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mithlond.kdm.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 17:06:44 -0000 On Tue, Jan 19, 2016 at 20:02:52 +0300, Slawa Olhovchenkov wrote: > On Tue, Jan 19, 2016 at 11:38:31AM -0500, Kenneth D. Merry wrote: > > > On Tue, Jan 19, 2016 at 14:45:23 +0300, Slawa Olhovchenkov wrote: > > > On Mon, Jan 18, 2016 at 05:37:04PM -0500, Kenneth D. Merry wrote: > > > > > > > I have a new set of SMR patches available. See below for the full > > > > explanation. > > > > > > > > The primary change here is that I have added SMR support to the ada(4) > > > > driver. I spent some time considering whether to try to make the da(4) and > > > > ada(4) probe infrastructure somewhat common, but in the end concluded it > > > > would be too involved with not enough code reduction (if any) in the end. > > > > > > > > So, although the ideas are similar, the probe logic is separate. > > > > > > > > Note that NCQ support for SMR commands (Report Zones, Reset Write Pointer, > > > > etc.) for SATA protocol shingled drives isn't active. For both the da(4) > > > > and ada(4) driver this is for lack of a way to plumb the ATA Auxiliary > > > > register down to the drive. > > > > > > > > In the ada(4) case, we need to add the register to struct ccb_ataio and > > > > add support in one or more of the underlying SATA drivers, e.g. ahci(4). > > > > > > > > In the da(4) case, it will require an update of the T-10 SAT spec to > > > > provide a way to pass the Auxiliary register down via the SCSI ATA > > > > PASS-THROUGH command, and then a subsquent update of the SAT layer in > > > > various vendors' SAS controller firmware. At that point, there may be > > > > an official mapping of the SCSI ZBC commands to the ATA ZAC commands, and > > > > we may be able to just issue the SCSI version of the commands instead of > > > > composing ATA commands in the da(4) driver. (We'll still need to keep the > > > > ATA passthrough version for a while at least to support controllers that > > > > don't have the updated translation code.) > > > > > > Please, check me: currenly SMR lack of support in SCSI devices? On > > > [hardvare] vendor level? Currenly only SATA controllers compatible > > > with SMR (on command level)? (I am don't talk about FreeBSD support, > > > question about common state). > > > > No, there are SAS/SCSI SMR drives in development, and there is the SCSI ZBC > > spec that defines the command set. I don't know whether any vendors are > > shipping SAS/SCSI SMR drives yet. > > > > You can use SATA drives (SMR or not) with either a SATA controller or a SAS > > controller. But the way you talk to a SATA drive through a SAS controller > > is with SCSI commands. There is a SCSI spec (SAT) that defines the mapping > > of SCSI commands to ATA commands. It has recently been updated to support > > mapping SMR commands from SCSI to ATA, but most (all?) SAS controllers > > have not caught up with the spec. > > > > So to use a SATA SMR drive with a SAS controller that doesn't know how to > > map SMR commands from SCSI to ATA, you have to send the ATA SMR commands > > through the SCSI ATA PASS-THROUGH command. That just bypasses the usual > > translations, and allows sending ATA commands in something like their > > native form. > > What in case of expanders an port replicatiors (SATA drives and HBA > SAS controllers, of course)? Need expander be compatible with SMR? Or > any expander with SATA support automaticly compatible? Expanders and port replicators shouldn't matter. The place where you need to know about SMR is the place where the native ATA or SCSI drive commands are generated. Expanders and port replicators typically just pass commands through. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-current@freebsd.org Tue Jan 19 17:59:29 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B17CFA87A65 for ; Tue, 19 Jan 2016 17:59:29 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 9F58813D7 for ; Tue, 19 Jan 2016 17:59:29 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id 9CC37A87A63; Tue, 19 Jan 2016 17:59:29 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 824C1A87A61; Tue, 19 Jan 2016 17:59:29 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 40E7813D5; Tue, 19 Jan 2016 17:59:29 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aLaYx-000Fbz-7s; Tue, 19 Jan 2016 20:59:27 +0300 Date: Tue, 19 Jan 2016 20:59:27 +0300 From: Slawa Olhovchenkov To: "Kenneth D. Merry" Cc: scsi@freebsd.org, current@freebsd.org Subject: Re: CAM Shingled Disk support patches available Message-ID: <20160119175927.GE37895@zxy.spb.ru> References: <20151118171309.GA3564@mithlond.kdm.org> <20160118223704.GA87506@mithlond.kdm.org> <20160119114523.GD37895@zxy.spb.ru> <20160119163831.GB99885@mithlond.kdm.org> <20160119170252.GC88527@zxy.spb.ru> <20160119170641.GA1669@mithlond.kdm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160119170641.GA1669@mithlond.kdm.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 17:59:29 -0000 On Tue, Jan 19, 2016 at 12:06:41PM -0500, Kenneth D. Merry wrote: > On Tue, Jan 19, 2016 at 20:02:52 +0300, Slawa Olhovchenkov wrote: > > On Tue, Jan 19, 2016 at 11:38:31AM -0500, Kenneth D. Merry wrote: > > > > > On Tue, Jan 19, 2016 at 14:45:23 +0300, Slawa Olhovchenkov wrote: > > > > On Mon, Jan 18, 2016 at 05:37:04PM -0500, Kenneth D. Merry wrote: > > > > > > > > > I have a new set of SMR patches available. See below for the full > > > > > explanation. > > > > > > > > > > The primary change here is that I have added SMR support to the ada(4) > > > > > driver. I spent some time considering whether to try to make the da(4) and > > > > > ada(4) probe infrastructure somewhat common, but in the end concluded it > > > > > would be too involved with not enough code reduction (if any) in the end. > > > > > > > > > > So, although the ideas are similar, the probe logic is separate. > > > > > > > > > > Note that NCQ support for SMR commands (Report Zones, Reset Write Pointer, > > > > > etc.) for SATA protocol shingled drives isn't active. For both the da(4) > > > > > and ada(4) driver this is for lack of a way to plumb the ATA Auxiliary > > > > > register down to the drive. > > > > > > > > > > In the ada(4) case, we need to add the register to struct ccb_ataio and > > > > > add support in one or more of the underlying SATA drivers, e.g. ahci(4). > > > > > > > > > > In the da(4) case, it will require an update of the T-10 SAT spec to > > > > > provide a way to pass the Auxiliary register down via the SCSI ATA > > > > > PASS-THROUGH command, and then a subsquent update of the SAT layer in > > > > > various vendors' SAS controller firmware. At that point, there may be > > > > > an official mapping of the SCSI ZBC commands to the ATA ZAC commands, and > > > > > we may be able to just issue the SCSI version of the commands instead of > > > > > composing ATA commands in the da(4) driver. (We'll still need to keep the > > > > > ATA passthrough version for a while at least to support controllers that > > > > > don't have the updated translation code.) > > > > > > > > Please, check me: currenly SMR lack of support in SCSI devices? On > > > > [hardvare] vendor level? Currenly only SATA controllers compatible > > > > with SMR (on command level)? (I am don't talk about FreeBSD support, > > > > question about common state). > > > > > > No, there are SAS/SCSI SMR drives in development, and there is the SCSI ZBC > > > spec that defines the command set. I don't know whether any vendors are > > > shipping SAS/SCSI SMR drives yet. > > > > > > You can use SATA drives (SMR or not) with either a SATA controller or a SAS > > > controller. But the way you talk to a SATA drive through a SAS controller > > > is with SCSI commands. There is a SCSI spec (SAT) that defines the mapping > > > of SCSI commands to ATA commands. It has recently been updated to support > > > mapping SMR commands from SCSI to ATA, but most (all?) SAS controllers > > > have not caught up with the spec. > > > > > > So to use a SATA SMR drive with a SAS controller that doesn't know how to > > > map SMR commands from SCSI to ATA, you have to send the ATA SMR commands > > > through the SCSI ATA PASS-THROUGH command. That just bypasses the usual > > > translations, and allows sending ATA commands in something like their > > > native form. > > > > What in case of expanders an port replicatiors (SATA drives and HBA > > SAS controllers, of course)? Need expander be compatible with SMR? Or > > any expander with SATA support automaticly compatible? > > Expanders and port replicators shouldn't matter. The place where you need > to know about SMR is the place where the native ATA or SCSI drive commands > are generated. Expanders and port replicators typically just pass commands > through. Thanks for clarification! From owner-freebsd-current@freebsd.org Tue Jan 19 17:20:02 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E559DA86580 for ; Tue, 19 Jan 2016 17:20:01 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C720717F6 for ; Tue, 19 Jan 2016 17:20:01 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: by mailman.ysv.freebsd.org (Postfix) id C3D41A8657E; Tue, 19 Jan 2016 17:20:01 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AAAEFA8657C for ; Tue, 19 Jan 2016 17:20:01 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm43-vm5.bullet.mail.gq1.yahoo.com (nm43-vm5.bullet.mail.gq1.yahoo.com [67.195.87.220]) (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 7188017F5 for ; Tue, 19 Jan 2016 17:20:01 +0000 (UTC) (envelope-from scott4long@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1453223618; bh=U8yG3IpWN4ie+PyrYQU3nDZa+4DZUEGe1+IY7/loVNo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=RJIbnmay/tI+J2qJgNLsKSq0C5IBHURpJKMc8CbmX6sJ0ZSS1FTTR7bRehXfuXoHOuHMHSa4e8Y2s80FIQWhlqlp0qoMHMTNFX3rFT1T13BfomAPMZVDnj/Ca4naNEI8YjQF8GsrnIpKRwXCr8LM7g14hjDh3n49I6LsiHqGqW/93tT3NeufmSm9GEnWtq58+emQe++2kbSTQ1iWrJeQw9PH5MTq0mavR61Sbr7WObHG3PGNgWPKf/jPU5VGEC8TjZ47FKcY9JTK8H3KDo59sNDLgC8k7VYOsWdnpFYDYiJ1L5LXpIjbH4QQ0tQAI/Ium501OGk0yQLLLwqenm9wyQ== Received: from [127.0.0.1] by nm43.bullet.mail.gq1.yahoo.com with NNFMP; 19 Jan 2016 17:13:38 -0000 Received: from [98.137.12.57] by nm43.bullet.mail.gq1.yahoo.com with NNFMP; 19 Jan 2016 17:10:51 -0000 Received: from [98.136.164.78] by tm2.bullet.mail.gq1.yahoo.com with NNFMP; 19 Jan 2016 17:10:51 -0000 Received: from [127.0.0.1] by smtp240.mail.gq1.yahoo.com with NNFMP; 19 Jan 2016 17:10:51 -0000 X-Yahoo-Newman-Id: 762227.92472.bm@smtp240.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-4 X-YMail-OSG: SUv.dT4VM1miuUV9Jva.u5fdfRVO3UeJqZTEFFvRqlT9BDz 2pMwid5EApaVaSOEUNzUr8nB0.Fu6g1V5DQMbasAb8_TQLFmnF84s5IE3TQl fadHcDogXiZUzHWaBW.dYz_oY88rHWjAoBZYA.RD78RvbFu0yvxnP2kvGqmL hZNw6Cgj8EcfrWGiMMfACzUAKDpbfoSgRKTdy2xVMpoPTDfVKxKN0kH2wVE6 wFg3LBMp8jGLY9HOMPd0p.BkaX3QwubMpmjA.3uRWanZ_pvjk4X6Oin03xG5 98WtH2W8tJbZgoiyZtIm6t2KkueB_8jawtE0q2FCprSRc6JxJ0ZB29wWjZLb ekFOOqPpJBEDYhBxlLU2N90gp6JmPgQmWrq2yTJrR9j6NxGd9p.rfA5P4Grb F115OYjDI8eG_7Vzrbwf9qxT_kiAU4N_dZcv0gemLgetnuUs6uWdnp_uYIxo 2.3pd0PV5e8ErB2Lhvvh9g13sPCtnTR.PD14FZdx8ZbGalFyIYbtGQ4VT0o8 63Ozmw1P_B2DYEbl5itV54fM921X.lNSzNkr0o5hit7dUW5Kux9p9 X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: CAM Shingled Disk support patches available From: Scott Long In-Reply-To: <20160119162555.GA99885@mithlond.kdm.org> Date: Tue, 19 Jan 2016 09:10:48 -0800 Cc: Warner Losh , current@freebsd.org, scsi@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <07A5702E-86FB-488C-92E8-850457DD8C17@yahoo.com> References: <20151118171309.GA3564@mithlond.kdm.org> <20160118223704.GA87506@mithlond.kdm.org> <349FCA2B-8346-4EC2-8459-B174FDC2CDB3@bsdimp.com> <20160119162555.GA99885@mithlond.kdm.org> To: "Kenneth D. Merry" X-Mailer: Apple Mail (2.3112) X-Mailman-Approved-At: Tue, 19 Jan 2016 18:27:37 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 17:20:02 -0000 > On Jan 19, 2016, at 8:25 AM, Kenneth D. Merry wrote: >=20 >=20 >>> In the ada(4) case, we need to add the register to struct ccb_ataio = and >>> add support in one or more of the underlying SATA drivers, e.g. = ahci(4). >>=20 >> I believe that changes the size of the CCB, so I tried to avoid >> that since I didn???t want to force a recompile of camcontrol(8). >> Adding it to the atacmd structure wasn???t so bad, and the CCB size >> didn???t completely change. The problem was that the atacmd changed >> size and pushed all the other fields. >=20 > Yes. In order to do it, we'll need to add it to struct atacmd, and = add > compatibility shims. I don't see another way to do it unfortunately. >=20 No, I object to changing the structure sizes and contents. It should be = a new CCB, XPT_ATA_IO_EXT, ccb_ataio_ext. If you want to add more future-looking fields than just the AUX register, maybe a way to define un-typed command and response register objects, that=E2=80=99s fine and = probably a good idea. The periph drivers can probe for the proper command to send based on whether the SIM returning CAM_FUNC_NOTAVAIL or via a PIM flag, or even better, via a KVP capability CCB. However I=E2=80=99m = firmly against changing the existing data structures; compat shims have been a pain and are a poor solution. Warner and I are pounding out a proposal for this, will share a diff = shortly. Scott From owner-freebsd-current@freebsd.org Tue Jan 19 19:18:01 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D13EAA899E2 for ; Tue, 19 Jan 2016 19:18:01 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 979BA1FFF for ; Tue, 19 Jan 2016 19:18:01 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1aLbmq-003f2K-I3>; Tue, 19 Jan 2016 20:17:52 +0100 Received: from f052068186.adsl.alicedsl.de ([78.52.68.186] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1aLbmq-000n7T-9c>; Tue, 19 Jan 2016 20:17:52 +0100 Date: Tue, 19 Jan 2016 20:17:46 +0100 From: "O. Hartmann" To: FreeBSD CURRENT Subject: network/ath: on CURRENT no connections possible on ath-based AP Message-ID: <20160119201746.13674c54.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/KN593u58KfbJHwrsa_Sd8Y3"; protocol="application/pgp-signature" X-Originating-IP: 78.52.68.186 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 19:18:02 -0000 --Sig_/KN593u58KfbJHwrsa_Sd8Y3 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Running hostapd and a Atheros based AP on recent CURRENT (FreeBSD 11.0-CURR= ENT #8 r294329: Tue Jan 19 18:23:20 CET 2016 amd64), clients do not connect anymor= e to that specific AP. They did a week or two ago (mobile phones, several notebooks). The WiFi adaptor is this one (dmesg): [...] ath0: mem 0xf7e00000-0xf7e1ffff irq 16 at device 0.0 on pc= i1 ar9300_attach: calling ar9300_hw_attach ar9300_hw_attach: calling ar9300_eeprom_attach ar9300_flash_map: unimplemented for now Restoring Cal data from DRAM Restoring Cal data from EEPROM ar9300_hw_attach: ar9300_eeprom_attach returned 0 ath0: [HT] enabling HT modes ath0: [HT] enabling short-GI in 20MHz mode ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 stream STBC transmit enabled ath0: [HT] 3 RX streams; 3 TX streams ath0: AR9380 mac 448.3 RF5110 phy 3276.12 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000 [...] and from ifconfig: [...] wlan0: flags=3D8943 metric = 0 mtu 1500 ether xx:xx:xx:xx:xx:xx inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255=20 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: running ssid Berghof channel 10 (2457 MHz 11g) bssid xx:xx:xx:xx:xx:xx regdomain ETSI country DE indoor ecm authmode WPA2/802.11i privacy MIXED deftxkey 2 AES-CCM 2:128-bit AES-CCM 3:128-bit txpower 30 scanvalid 60 protmode CTS wme burst dtimperiod 1 -dfs groups: wlan=20 [...] On some earlier dmesg outputs, I see the line=20 ath0: AR9380 mac 448.3 RF5110 phy 2457.9 instead of the most recent ath0: AR9380 mac 448.3 RF5110 phy 3276.12 I do not see any strange behaviour until clients fetch (successfully!) thei= r IP via isc-dhcp (isc-dhcp43-server-4.3.3P1_1), then they die or can not access th= e network any further. Has there been a change recently? Kind regards, Oliver --Sig_/KN593u58KfbJHwrsa_Sd8Y3 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWnovaAAoJEOgBcD7A/5N89FQH/3vqojuoVsoV21Y6Xw2SOGfM K70JsTvoXfVQL3Tu2yvkNKNtFn9SwGpxvqGrlpE59fVeTU7+b5t8iZ8otzXItmMQ 2ZcYR4fRep+O6XmdgUevHsyH4OzUZHU5jImuPLrMYcjjbT9Bwh7mNQLQTAQpvsMc om14s+zLNZaO3dmU/M189ZvuUkly680Cr/btGghS5JyM0ij+OPeDgceRx36+3ow8 tWMgJNeEDtHHe6HRhlCR0ZQaQzM/KmHPyhSVf3sl/fkwbRexneM86CQTa1oIhcxO IltDPq3W5c7WuO7sYsZg01+oUElV6BPgCHFv/QxVxX5EqFc8Afpf/oQ7vZrlABQ= =RRHo -----END PGP SIGNATURE----- --Sig_/KN593u58KfbJHwrsa_Sd8Y3-- From owner-freebsd-current@freebsd.org Tue Jan 19 19:27:08 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0AC89A89C67 for ; Tue, 19 Jan 2016 19:27:08 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::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 CB9261739 for ; Tue, 19 Jan 2016 19:27:07 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x232.google.com with SMTP id q21so592244925iod.0 for ; Tue, 19 Jan 2016 11:27:07 -0800 (PST) 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=npRHOTSepdaETZkPcr6XU5OJVDyoVy66grzyjFO2k04=; b=LZF7ElNSKXUHMXtUqFVWx5NkQfnJV9BpB80JcXOvwg67OrpKzw2A0lZai/MZxqtsNZ A+3p/FNtpW5n6E2vGvkL1u3HbY5dhfXaeKwgbRRiHfVzOKfbq4iMkZwtDZqwNpT6sihe qAoZs18+wZirYcrUodnF6P8nOP/MFeWkfuVKJZ90cX9M4BEkALr17vch3ROgbb3YvRVU IMaE7BptojbhgwXwfMTYyJO8doqRSCW+HQSMmwO4XKUn2RSjAIBEo5Bqf20PmlUaN+sO SyKLztwpmIBTNVwkbvyG4yXpLT0LzZ/Zj1kYah76hKy2//oKHHhXLdt3wN17Yyfk1swA QiXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=npRHOTSepdaETZkPcr6XU5OJVDyoVy66grzyjFO2k04=; b=CzqIqtrowp3NRw9G6iDX3xwVu1W7rRg1Nan9id4X3Lk2EuK+TUmG1zAJAtg7teXJGW 8IWPg6HSGqMpadRvFKkKmKrPSUw9eqVEEBk6DyTyIoESlDUzKfdE536He2K5A7GVJdj7 7sZtxisfpyiHTEeNFc9z9z6SlJsirpRBwkJhxGY90Fcgoph49OtJpM/v+eKVEwSKnG7d uB2D46Ug/mt1+t12+A2V72ntjZArizVIKtw41Gwkf8zUK5Y+bBd2w4z21K5tW3nesUJL oQz0ypE+N58zFD6OrLxlJslR3wOKjWbFt/z92Wl4c2C3oqSLZL5eZqzTlYcUamRe5Gc9 zv7g== X-Gm-Message-State: ALoCoQknN/HVqLGpRt6MYM9kdWI1fKs5VIbyxsdeQ71j5h/oH5sMsdgViHMAyqFZgbtCvyIv16c5q8H96yoZjvmR6nF5bDG20A== MIME-Version: 1.0 X-Received: by 10.107.162.146 with SMTP id l140mr26218985ioe.123.1453231627332; Tue, 19 Jan 2016 11:27:07 -0800 (PST) Received: by 10.36.121.16 with HTTP; Tue, 19 Jan 2016 11:27:07 -0800 (PST) In-Reply-To: <20160119201746.13674c54.ohartman@zedat.fu-berlin.de> References: <20160119201746.13674c54.ohartman@zedat.fu-berlin.de> Date: Tue, 19 Jan 2016 11:27:07 -0800 Message-ID: Subject: Re: network/ath: on CURRENT no connections possible on ath-based AP From: Adrian Chadd To: "O. Hartmann" Cc: FreeBSD CURRENT Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 19:27:08 -0000 Theres been nothing in the ath code that I can think of that'd do this. Can you get me "works" and "doesn't work" revisions? thanks, -a On 19 January 2016 at 11:17, O. Hartmann wrote: > Running hostapd and a Atheros based AP on recent CURRENT (FreeBSD 11.0-CURRENT #8 > r294329: Tue Jan 19 18:23:20 CET 2016 amd64), clients do not connect anymore to that > specific AP. They did a week or two ago (mobile phones, several notebooks). > > The WiFi adaptor is this one (dmesg): > > [...] > ath0: mem 0xf7e00000-0xf7e1ffff irq 16 at device 0.0 on pci1 > ar9300_attach: calling ar9300_hw_attach > ar9300_hw_attach: calling ar9300_eeprom_attach > ar9300_flash_map: unimplemented for now > Restoring Cal data from DRAM > Restoring Cal data from EEPROM > ar9300_hw_attach: ar9300_eeprom_attach returned 0 > ath0: [HT] enabling HT modes > ath0: [HT] enabling short-GI in 20MHz mode > ath0: [HT] 1 stream STBC receive enabled > ath0: [HT] 1 stream STBC transmit enabled > ath0: [HT] 3 RX streams; 3 TX streams > ath0: AR9380 mac 448.3 RF5110 phy 3276.12 > ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000 > [...] > > and from ifconfig: > > [...] > wlan0: flags=8943 metric 0 mtu 1500 > ether xx:xx:xx:xx:xx:xx > inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255 > media: IEEE 802.11 Wireless Ethernet autoselect mode 11g > status: running > ssid Berghof channel 10 (2457 MHz 11g) bssid xx:xx:xx:xx:xx:xx > regdomain ETSI country DE indoor ecm authmode WPA2/802.11i > privacy MIXED deftxkey 2 AES-CCM 2:128-bit AES-CCM 3:128-bit > txpower 30 scanvalid 60 protmode CTS wme burst dtimperiod 1 -dfs > groups: wlan > [...] > > On some earlier dmesg outputs, I see the line > > ath0: AR9380 mac 448.3 RF5110 phy 2457.9 > > instead of the most recent > > ath0: AR9380 mac 448.3 RF5110 phy 3276.12 > > I do not see any strange behaviour until clients fetch (successfully!) their IP via > isc-dhcp (isc-dhcp43-server-4.3.3P1_1), then they die or can not access the network any > further. > > Has there been a change recently? > > Kind regards, > > Oliver From owner-freebsd-current@freebsd.org Tue Jan 19 20:09:21 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9A406A88973 for ; Tue, 19 Jan 2016 20:09:21 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1E28F1D21 for ; Tue, 19 Jan 2016 20:09:21 +0000 (UTC) (envelope-from cochard@gmail.com) Received: by mail-lf0-x234.google.com with SMTP id c192so346176470lfe.2 for ; Tue, 19 Jan 2016 12:09:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=6+pgLpLZO+YzEIH3xC5d7N/nsl7ogCPTkQzRDKaKhjQ=; b=C+1MgEPrqXz2pZHwSiLHiIpAU0ADqYXupdjOOS5qxgnLLRThEN/YgOSYwe/Czt/Jvq NrSmk2dXMw6O1v14/e6IrFz9B9T9Z99PFYN3drH41Z8M8GJUsLZ6S5ussI0NC9DI4srB tinZd2uhTt2q0wHYeBmZxYOGpe8OrUgzfnpYNW/aHCcxK8K1HVWQWy0EpyqapSynOhN9 vk+m1KFH1NA+W5mJF2LvFD/Y0tBVe0hth8QwgQsfN7YwZmTiacfFelHNYDB3k9eAKso/ LL6sw/vAbeS4fRrtP7kS/qJpjr6lrs5yF3LuACvLniydUyIBSe4pbYxh5uTPiIxxGyKf 0oEw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cochard-me.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=6+pgLpLZO+YzEIH3xC5d7N/nsl7ogCPTkQzRDKaKhjQ=; b=z109SXT25nXWQQn8pqYUg79BBjL8BTi+mWGqn8vY0i1LmQcWkoQgD7ZYibxs61OgFn B+LLjGKX9rxx4HH49PloohbNq1USGhY2M6pqmtQzks9EgW2qgMAGOPQ4PtEM+HI9bD0e zSC2C5DRuoBrV4QBZhzaSNQ2YYcY1uq5oj8H4Ewwb5AVBNYk3TtkIKJfEZAze71/ZfQX VjEqrWj50rMuhqxRhdpDaY6ntQU9yUQEs0nerZvUX6fnWx+gjE3vFtjLMgyHC5fGrVPQ S2KxQIFWQgO4nlX82sk4vZj80t+972tz5KnI/jzQNW/bl5jUEHl1pFdlsJOa1tR/SxXf CcgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=6+pgLpLZO+YzEIH3xC5d7N/nsl7ogCPTkQzRDKaKhjQ=; b=SPC5M9AuQ602KB5ZoncBIwXN1LWD8LuYtl7q31/odtuV7LVJQwVwfUlChkABpUgdoV ipp9fO0N6L92aDdjtc7Pw4MSbvoqH8yPuZqleb0DXN1dtNUlEZDps60qnonYauRP2M1e 4kpoish6Jn47SLiW10lluKkuCAQ3wQ4eNa1NXG5BoVT3leZ1Z3udtekkQb0ANE5MVT0B cPuyOba7H4C8hn1thLeSpB++ZRZo24tI//ukvqSmXSC31Y4yC5R0mijhUuFz7YC1ux7t iXJ1T7QhBk9tF1LDur6Ii5tseskCAVSqLxwjg+31xgOVxgAOsS73jFzVb1Mb/6A6hQ2R oRkg== X-Gm-Message-State: ALoCoQnwUKWyikw1Vl7B2Y8lWkNeq9eso8nnyAYcxRwley2yxcdYR/C04v2L7wqd1KlokowH8CF8VCR6OJoo0PA1uUZeBIvcbQ== X-Received: by 10.25.33.198 with SMTP id h189mr11843790lfh.91.1453234158745; Tue, 19 Jan 2016 12:09:18 -0800 (PST) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.25.136.11 with HTTP; Tue, 19 Jan 2016 12:08:59 -0800 (PST) In-Reply-To: <20160119201746.13674c54.ohartman@zedat.fu-berlin.de> References: <20160119201746.13674c54.ohartman@zedat.fu-berlin.de> From: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Date: Tue, 19 Jan 2016 21:08:59 +0100 X-Google-Sender-Auth: 3Az3zv9edLnl8NoTS1knQv9BmIQ Message-ID: Subject: Re: network/ath: on CURRENT no connections possible on ath-based AP To: "O. Hartmann" Cc: FreeBSD CURRENT Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 20:09:21 -0000 On Tue, Jan 19, 2016 at 8:17 PM, O. Hartmann wrote: > Running hostapd and a Atheros based AP on recent CURRENT (FreeBSD > 11.0-CURRENT #8 > r294329: Tue Jan 19 18:23:20 CET 2016 amd64), clients do not connect > anymore to that > specific AP. They did a week or two ago (mobile phones, several notebooks= ). > =E2=80=8BHi, I've got no problem on r293631=E2=80=8B =E2=80=8Bin hostap mode ( ath0: AR9280 mac 128.2 RF5133 phy 13.0 =E2=80=8B). Regards, =E2=80=8BOlivier=E2=80=8B From owner-freebsd-current@freebsd.org Tue Jan 19 20:11:50 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 78D31A88B02 for ; Tue, 19 Jan 2016 20:11:50 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 440A41F22 for ; Tue, 19 Jan 2016 20:11:50 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-ig0-x232.google.com with SMTP id z14so85452697igp.0 for ; Tue, 19 Jan 2016 12:11:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=farT/XTrxsWDXe57qo97BzMK824vpxkw0t3PDVuxLpc=; b=U0qgrbE8uZTpWNwUyDePTWml3CMNFzyk5qBLWB8+xe1YNswg/QRny0yBO0v+e3c62t NylWA/EUab0BNHEPU+nQonK3Yl8K6WRnoUS/rpmx5FdveUNHzKXbgPqqQT39LcMONG2/ e8nsYe0J3I+kNZWmjFI4weW51Nt6EebKvdFHvWtzfAEqHkufxOfWTLMUW1EJQZFsLQnx pE2HoMzh9JAL27L7uzLWJx9OXluKhQokQElhGwhHDZKAiouopmAU1xFQF3Fu4ri7Go4s 7u0hagqdW9YGuRf+IQhkEhkJwjjj9rRyrDk2shrg5kJXuwVYhM8/Xavq129yEhLMHeZC DI1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=farT/XTrxsWDXe57qo97BzMK824vpxkw0t3PDVuxLpc=; b=Rp8K8b5EPrstdhXSm1Ljx+Af+o51mhEYzwyNnM1M+4/+vnmhpH5W+IOtItt3zs97H1 FYDYChVRW59JGRRMsDlbu3LTk1BMJbpq3G4CKyphu1YBifVhNisfQfIH3m4cOQhUJFhG gBOf/DRm5AYZHUuHD1qSigP/xWKt8GTpHne3TEBptnzdcOGoVDzGCVzGUqUnFlS/OZXj jZTMwb/NlT2he3oUPBrxJbHUSQEXiJ7WstqBUPyKzWcYProFlDEdYuNrp/0AfdBNYlT8 qnPmhjH5xLU8cggFa2dGxxVi3xBuu2AImiIKyDjWk2IMV7zh8B4e50xoMD4aHMzAUw0w pyJw== X-Gm-Message-State: AG10YOQif727eiOtDnHJ+OOy3H1ZgKigCVQnt5JWw/eOzPPJ7d+2S3UUjYm81hRHjqyy+nRkasUtfKbdgSakzw== MIME-Version: 1.0 X-Received: by 10.50.178.178 with SMTP id cz18mr5899034igc.37.1453234309723; Tue, 19 Jan 2016 12:11:49 -0800 (PST) Received: by 10.36.121.16 with HTTP; Tue, 19 Jan 2016 12:11:49 -0800 (PST) In-Reply-To: References: <20160119201746.13674c54.ohartman@zedat.fu-berlin.de> Date: Tue, 19 Jan 2016 12:11:49 -0800 Message-ID: Subject: Re: network/ath: on CURRENT no connections possible on ath-based AP From: Adrian Chadd To: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Cc: "O. Hartmann" , FreeBSD CURRENT Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 20:11:50 -0000 CAn you test AR9380 on that revision? That's -head, right? -adrian On 19 January 2016 at 12:08, Olivier Cochard-Labb=C3=A9 wrote: > On Tue, Jan 19, 2016 at 8:17 PM, O. Hartmann > wrote: > >> Running hostapd and a Atheros based AP on recent CURRENT (FreeBSD >> 11.0-CURRENT #8 >> r294329: Tue Jan 19 18:23:20 CET 2016 amd64), clients do not connect >> anymore to that >> specific AP. They did a week or two ago (mobile phones, several notebook= s). >> > > Hi, > > I've got no problem on r293631 > > in hostap mode ( > ath0: AR9280 mac 128.2 RF5133 phy 13.0 > ). > > Regards, > > Olivier > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-current@freebsd.org Tue Jan 19 20:28:26 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 17824A89176 for ; Tue, 19 Jan 2016 20:28:26 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8E55A1C7E for ; Tue, 19 Jan 2016 20:28:25 +0000 (UTC) (envelope-from cochard@gmail.com) Received: by mail-lf0-x234.google.com with SMTP id m198so199128448lfm.0 for ; Tue, 19 Jan 2016 12:28:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=/VgOTyas2+91XwmxEcJFp4bQ+htJlq0D3V89JXupKZU=; b=mIk8Z6OwyED0m4CiTfJe36JyBur5u9TtNlsb+TiuOGO+9DGAdqB5POFZjFhdcvmiBw DZxBNGBpAnvEG7v4S1tbHo2rGkPCH6MhUb8TODYs/+lBKDRhIcTxQRxYteBoTTg6k9ts g1Pbs4wjRt8uPp6K3+gAotsSdm+3sxkFCLmH8sfosN0EbYY3MelyBrG4+wzcL1/q93ta u2zb7HRT6Knd/o7EG/nj4DV7OMtrEOLj5h0NE+ZGq5rLKK+Hqb38goavR4dvoFf94i3w 6fvsXRDeUwl8lGSwmvvdhgf6DqUJqwoXlXZuKViJ2IEPhW/do0OG7VyNcuwSeshIwSrN quow== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cochard-me.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=/VgOTyas2+91XwmxEcJFp4bQ+htJlq0D3V89JXupKZU=; b=K0C31nvNiPe3o6NLUSD0TwLsM5nYXjac58GQzBanX6KDhDBkUjXyT9WaI7Mfnmz4uS bMuqCCneSyQaJc+IxPd3HcQQHL72Jz4slnz0E9IyKXwBe/jr0l7e7YLdmH050GFQoY3I O1/D4HWKluWOVeHclJE5NSD+x46gHwgZaEFGk/+VzacRBHI33gY0wQlHrORZRbM0tb4o CLL2VOLlSbI82nzEfBsTpNNRyH4HPFQCHINRRsT9v2LNQswahK2Th6m6FVXrSHpkZHx3 LyNqSYAq880AFpUvF/H/L8Ty9WAHXJI2AmB3B8GRB4eVUzHtF7wO7oOadEdqp3pnACxn QROQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=/VgOTyas2+91XwmxEcJFp4bQ+htJlq0D3V89JXupKZU=; b=Gu7fHHbmlj8FMkrmUUhcmZHZ3C/yHabvirc21uS32vLY04RbjmizBVPJFnxHxAHE8J mYrdB6M9lqGbo5AlgfZYP2V4SkhJIsthhfpdIrL/Fru6tu6cxtkM/pd2iX3JeYdPhmD1 BaLOIsIjWZOlgy5pOqC/I60vrhAtM99qrWQjt1UOaeiNbCePY3wV/jACWoFP4itScMXI F2T6crV7kCaKRc+W04yZdqzUHXsvujmVywPfT3P2D14E6ppL1tz2hY7Ke7pfvra2+alC gwliDRsAoanzplkg1raWEEVmPbgm/S4wb7AXfpDLvXM/Lwv3ov1OyjIOm6kNNHZUsm1o /1vQ== X-Gm-Message-State: ALoCoQkgry5Z5QcSkqyHoXzmEfdK5tLQi6J7ZSKsoSyDe6tH1HzZAZY7PC3cIn3LQdGPYnsBG66ChRcMQ8WY8kZ7zrOddlGEpA== X-Received: by 10.25.210.78 with SMTP id j75mr11794357lfg.101.1453235303483; Tue, 19 Jan 2016 12:28:23 -0800 (PST) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.25.136.11 with HTTP; Tue, 19 Jan 2016 12:28:03 -0800 (PST) In-Reply-To: References: <20160119201746.13674c54.ohartman@zedat.fu-berlin.de> From: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Date: Tue, 19 Jan 2016 21:28:03 +0100 X-Google-Sender-Auth: DzeOKaB7cdIssLHPR0dEPrygy_M Message-ID: Subject: Re: network/ath: on CURRENT no connections possible on ath-based AP To: Adrian Chadd Cc: "O. Hartmann" , FreeBSD CURRENT Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 20:28:26 -0000 On Tue, Jan 19, 2016 at 9:11 PM, Adrian Chadd wrote: > CAn you test AR9380 on that revision? That's -head, right? > =E2=80=8BNo, sorry: I've got only AR9280 based wifi card (=E2=80=8BCompex W= LE200NX 802.11a/b/g/n miniPCI). And yes: it's r293631 =E2=80=8B on =E2=80=8B -head. From owner-freebsd-current@freebsd.org Tue Jan 19 20:34:57 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EE8C4A8949E for ; Tue, 19 Jan 2016 20:34:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B9CA11270 for ; Tue, 19 Jan 2016 20:34:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x230.google.com with SMTP id 77so562461735ioc.2 for ; Tue, 19 Jan 2016 12:34:57 -0800 (PST) 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=2kGQf44UDUAgPTs2oVOGTeDFW4fDXTIlTR1e/u+kYxg=; b=FMtCSdoq1PLoyFs0wfiO4y5fq7HLcXdVhWb3bQLvdUFg8cigCxgHPhfiJ1CMhd8Ptt OF2XxpsuNEqsvqvu7T7m2Hg+jJCntZDnszFrrZy898+TI3KsIyZHpg0BJy01P3Psvxxe Gq3zAj0uFyJRpIPWzusJey3ziiO8QaeFwg4E6Fu6QWBMiKDb1/ppvTHObUloY5RsmgX2 Fr0G9T8hd1CoNdTBcFjFCZ/q3YbWJbCE72uSx6/OjW3PL/0VJjwg9HcytN4SIt1QT+Ac Vn8XhJgUXkmX5eU2T1LShhsFqV9qq0InXwwQR3EFDfIKA8jgm8c8D17hmdRsEM+49eSx rP7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2kGQf44UDUAgPTs2oVOGTeDFW4fDXTIlTR1e/u+kYxg=; b=hs3SkJ3kWi4RUrJLvyROKzeYiQPnbo9J+7OOsMSm0j+gu/gnccm27uBndBjC9/Otdu Yq2U7I3ocxmv+ZyCE9Izah0YQjifPSRDzQ2aOGmjuNFA4W4u/nYxZ3EyEAI34zY51M8F m0Fq/PcSGwDtGB8G4Hdf2z8MJm8+KyYgA4kXdNFi6zDijEkmtHWV2wc1LrJrCaI/24mx bEZsboNSYJCzNcMeb6eO0pqNtk95LHqMyDwTehx0YqqctRJrRoqKSvWeISHiIMIi6BlZ BeDN5OztmuRkVbKrDnveJbbZDfwYCMKoKG68xa3VMzrWVYwqfcX03uTtpYTF7QJUz9Yj BhAw== X-Gm-Message-State: ALoCoQnQVsa8BC4p/Rj9zzEHwqYl9kzvToye7+xidwrjD7m1Y//xaf8miDmiKfvmEdJ2D8vH6q9dGQ4Kl7cVh8Ri961REStR2g== MIME-Version: 1.0 X-Received: by 10.107.11.162 with SMTP id 34mr27036961iol.165.1453235697158; Tue, 19 Jan 2016 12:34:57 -0800 (PST) Received: by 10.36.121.16 with HTTP; Tue, 19 Jan 2016 12:34:57 -0800 (PST) In-Reply-To: References: <20160119201746.13674c54.ohartman@zedat.fu-berlin.de> Date: Tue, 19 Jan 2016 12:34:57 -0800 Message-ID: Subject: Re: network/ath: on CURRENT no connections possible on ath-based AP From: Adrian Chadd To: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Cc: "O. Hartmann" , FreeBSD CURRENT Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 20:34:58 -0000 okay -a From owner-freebsd-current@freebsd.org Tue Jan 19 22:36:14 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3C45CA89FD9 for ; Tue, 19 Jan 2016 22:36:14 +0000 (UTC) (envelope-from mueller6724@bellsouth.net) Received: from nm15-vm10.access.bullet.mail.bf1.yahoo.com (nm15-vm10.access.bullet.mail.bf1.yahoo.com [216.109.115.41]) (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 EDAEA1FAE for ; Tue, 19 Jan 2016 22:36:01 +0000 (UTC) (envelope-from mueller6724@bellsouth.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s2048; t=1453242758; bh=TzJcjBpniHbxvurKCgtrGkcORNkl1qu+w46ImbMG0/A=; h=Date:From:To:Subject:From:Subject; b=DQVdN4F3UySTcEg1MLVs3v2Sk2TSKDfpUnD7QIDulpZQUoKkE7cQzTRuMVFeMUAN0Mxl4/W2XfS4ae9GYykD2uDZt1wZUTUxtP1+PeiyelwkqVODH5jz3BR3t5gGW81FdpGfex17C/rhBTh45CVVqHD+GVjfgt/ORgqZ5G/eGpsINrVeqMgetOplLS83UfG7QEd0ZBLgW1TJI54PwSb0gh0U6zrB0yjmMfBD+Mn4d6IJ4Tx+0GvVXYxlJE3tVa5ZwOqV56yVwtuM4Qjjmsxk4boJUA4MZX1+RpkLFUa8eH5PGyNsffJNmyF2Z8UFIuY+jG3DRgB6geU2o39Vgoku4Q== Received: from [66.196.81.163] by nm15.access.bullet.mail.bf1.yahoo.com with NNFMP; 19 Jan 2016 22:32:38 -0000 Received: from [98.138.226.242] by tm9.access.bullet.mail.bf1.yahoo.com with NNFMP; 19 Jan 2016 22:32:38 -0000 Received: from [127.0.0.1] by smtp113.sbc.mail.ne1.yahoo.com with NNFMP; 19 Jan 2016 22:32:38 -0000 X-Yahoo-Newman-Id: 206770.43295.bm@smtp113.sbc.mail.ne1.yahoo.com Message-ID: <206770.43295.bm@smtp113.sbc.mail.ne1.yahoo.com> X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: abAZOZUVM1n8gdCFRz5L9MLCpp3uGTnhmmSqhcEd0JkCkp2 dvKA6VbLHxUH6aGiFfGG.7SmbKWG0y1pDhynJ2wLKTOw308gsPkFueFmqSkv PqMv2cRpg2w0rjsyJl_6xnKPbiZLjkmRVTS3hm8ZFBuXE64Na7E0SRiIjff. E7b.FO44jmxSP83Af9JVXxFJsjRB0oN.8B6Fvvi8zXgbCh_tqAo5DywjDhW2 uwyf4SnUCsac9goZOd_qtnKK7Mm0.D0PTCdDeZShmQ4oqHHVvqcSrjHZoeb9 metSjLZlB3CtnECs.BmiKHuS8YBNAIrsa3zrNZo5jPIp75M5Cp29mqn7M_1x ZevZT3yIcEzvbkWQDzoI68L5pRL4B9qqjnc6xrpQnFKtfMHUNVFrZSrIn7Os Ni9P4eaPvEn_yLnLqVeHZWeTY8076i4ZsWYWky.RESHKeftHC13nDa5Tvh93 3d7IpCMuUvAqrJHq8oAinHxNEM3bCfGsdUV0F4z8VFD6ZEvxxtQYJPfGzPWt n0CxGJLpkAYzd92lp5UC38BaEc0.wX_ZmPapA.WhvNEhQCtOuay3R.zh_87I - X-Yahoo-SMTP: Kz_aW1.swBBYof3zAD7.RWzXz9ZAQVDMml1VADsbgPT4Kq79LC0- Date: Tue, 19 Jan 2016 22:32:09 +0000 From: "Thomas Mueller" To: freebsd-current@freebsd.org Subject: Shared library version bump? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 22:36:14 -0000 Has there recently been a version bump in the shared libraries? I saw no warning on this in the src or ports UPDATING files. I can no longer startx and can no longer run many other ports, getting errors like Shared object "libcrypto.so.7" not found, required by "X" xinit: giving up xinit: unable to connect to X server: Connection refused xinit: server error and root@amelia:~ # pkg info -f xserver Shared object "libssl.so.7" not found, required by "pkg" Is this due to a version bump, or is it related to the messages I got in yesterday's kernel installation like "unknown metadata record 4 ..."? What do I do? Make buildworld and kernel again, or rebuild all ports? How do I find which ports need updating, or rebuild all except portmaster and pkg which I rebuilt after getting the errors? Tom From owner-freebsd-current@freebsd.org Tue Jan 19 23:03:22 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9CBD8A87CFA for ; Tue, 19 Jan 2016 23:03:22 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 62EE71C88 for ; Tue, 19 Jan 2016 23:03:22 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::118f:eb70:2b5f:8c94] (unknown [IPv6:2001:7b8:3a7:0:118f:eb70:2b5f:8c94]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 18DA91A129; Wed, 20 Jan 2016 00:03:10 +0100 (CET) Subject: Re: Shared library version bump? Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7CFD6C37-4956-414A-BC41-7C117E7500C7"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 (ebbf3ef) From: Dimitry Andric In-Reply-To: <206770.43295.bm@smtp113.sbc.mail.ne1.yahoo.com> Date: Wed, 20 Jan 2016 00:05:20 +0100 Cc: freebsd-current@freebsd.org Message-Id: References: <206770.43295.bm@smtp113.sbc.mail.ne1.yahoo.com> To: Thomas Mueller X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 23:03:22 -0000 --Apple-Mail=_7CFD6C37-4956-414A-BC41-7C117E7500C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 19 Jan 2016, at 23:32, Thomas Mueller = wrote: >=20 > Has there recently been a version bump in the shared libraries? I saw = no warning on this in the src or ports UPDATING files. This was already answered in reply to your previous post on this same issue. As mentioned in the reply, OpenSSL has been upgraded, and both of its shared libraries have been bumped, e.g. they are now named libcrypto.so.8 and libssl.so.8. (Apparently you deleted the old libcrypto.so.7 and libssl.so.7, even though you should never do so until your ports are upgraded.) > I can no longer startx and can no longer run many other ports, getting = errors like >=20 > Shared object "libcrypto.so.7" not found, required by "X" > xinit: giving up > xinit: unable to connect to X server: Connection refused > xinit: server error >=20 > and >=20 > root@amelia:~ # pkg info -f xserver > Shared object "libssl.so.7" not found, required by "pkg" >=20 > Is this due to a version bump, Yes. > or is it related to the messages I got in yesterday's kernel = installation like "unknown metadata record 4 ..."? No, that is something entirely different. It is mainly cosmetic, and you can ignore it, it will go away at the next kernel update, if your kldxref executable is new enough. > What do I do? Make buildworld and kernel again, or rebuild all ports? = How do I find which ports need updating, or rebuild all except = portmaster and pkg which I rebuilt after getting the errors? It is easiest to use pkg-static to reinstall your ports, e.g.: pkg-static update pkg-static upgrade Alternatively, rebuild all ports depending on OpenSSL. -Dimitry --Apple-Mail=_7CFD6C37-4956-414A-BC41-7C117E7500C7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.29 iEYEARECAAYFAlaewTgACgkQsF6jCi4glqNxRwCgyEwReiQ6zBZ2BEB7EJvjBRZW EYQAoOUSwjotg1SWsiQOKba8BpoyIGrU =n8x/ -----END PGP SIGNATURE----- --Apple-Mail=_7CFD6C37-4956-414A-BC41-7C117E7500C7-- From owner-freebsd-current@freebsd.org Tue Jan 19 23:31:46 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B3DA5A887D7; Tue, 19 Jan 2016 23:31:46 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id A2FC21FD6; Tue, 19 Jan 2016 23:31:46 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id A102C1154; Tue, 19 Jan 2016 23:31:46 +0000 (UTC) Date: Tue, 19 Jan 2016 23:31:45 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: bdrewery@FreeBSD.org, jilles@FreeBSD.org, jhb@FreeBSD.org, asomers@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <583836814.7.1453246306629.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <382444560.3.1453239215678.JavaMail.jenkins@jenkins-9.freebsd.org> References: <382444560.3.1453239215678.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #2145 - Still Failing MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 23:31:46 -0000 FreeBSD_HEAD_i386 - Build #2145 - Still Failing: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2145/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2145/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2145/console Change summaries: 294357 by bdrewery: Allow specifying an alternative LD_LIBRARY_PATH for the ldd(1) lookup. This is needed to be able to run check-links.sh against a "sysrooted" binary while ensuring that the ldd(1) call done on the host uses the host libc. It is not possible to set LD_LIBRARY_PATH before calling check-links.sh as then the "sysrooted" libc would be incorrectly used. A LD_PRELOAD=libc.so is used to ldd(1) as it needs to use the host libc to run. ldd(1) is a simple wrapper around execve(2) and dlopen(2) with env LD_TRACE_LOADED_OBJECTS set. Due to the dlopen(2) restriction on shared library tracing ldd(1) is still required for this lookup. Sponsored by: EMC / Isilon Storage Division 294356 by bdrewery: Add some documentation. Sponsored by: EMC / Isilon Storage Division 294355 by bdrewery: Validate that the file exists rather than obscure 'Not an elf file' error. Sponsored by: EMC / Isilon Storage Division 294354 by bdrewery: bsd.subdir.mk: Allow easier modification of [STANDALONE_]SUBDIR_TARGETS. This reworks r289254 and removes ALL_SUBDIR_TARGETS. Because there is an include guard in this file there is no need for LOCAL_ or ?= on SUBDIR_TARGETS or STANDALONE_SUBDIR_TARGETS. These can just be set via src.conf. By the time bsd.subdir.mk is included it will just append the values to the existing value and work fine. This allows a consistent way to append to these variables without introducing a LOCAL_ var for STANDALONE_SUBDIR_TARGETS or renaming the historical SUBDIR_TARGETS. Sponsored by: EMC / Isilon Storage Division 294353 by bdrewery: installconfig is PARALLEL_SUBDIR safe. Sponsored by: EMC / Isilon Storage Division 294352 by bdrewery: FAST_DEPEND: Add header dependency missed in r290629. Sponsored by: EMC / Isilon Storage Division 294351 by bdrewery: FAST_DEPEND: Still use if filemon is not used. If filemon is used then there is no need to generate dependency files during compilation as the .meta files will achieve the same result. This is a temporary solution until FAST_DEPEND is default. Once that is default there will be an option to disable dependency generation entirely as it is only useful if an incremental build is planned, thus META_MODE+filemon can enable that option to short-circuit all FAST_DEPEND-related logic. Sponsored by: EMC / Isilon Storage Division 294350 by bdrewery: META_MODE: Ensure bmake does not use filemon if it is not loaded. Sponsored by: EMC / Isilon Storage Division 294349 by bdrewery: Define .MAKE.MODE to normal to avoid the need for :U later. Sponsored by: EMC / Isilon Storage Division 294348 by jilles: sh: Simplify some code related to positional parameters. 294347 by asomers: Fix usr.bin.truncate.truncate_test.bad_truncate with ZFS /tmp. The bad_truncate test sets the uimmutable flag to produce an error in truncate, but that flag isn't supported by ZFS. If /tmp is on a ZFS filesystem, the test will fail. Change it to use readonly permissions and an unpriveleged user instead. Reviewed by: jilles MFC after: 1 week Sponsored by: Spectra Logic Corp Differential Revision: https://reviews.freebsd.org/D4862 294344 by jhb: Various cleanups to the main function for AIO kernel processes: - Pull the vmspace logic out into helper functions and reduce duplication. Operations on the vmspace are all isolated to vm_map.c, but it now exports a new 'vmspace_switch_aio' for use by AIO kernel processes. - When an AIO kernel process wants to exit, break out of the main loop and perform cleanup after the loop end. This reduces a lot of indentation and allows cleanup to more closely mirror setup actions before the loop starts. - Convert a DIAGNOSTIC to KASSERT(). - Replace mycp with more typical 'p'. Reviewed by: kib Sponsored by: Chelsio Communications Differential Revision: https://reviews.freebsd.org/D4990 The end of the build log: [...truncated 40522 lines...] cc -DOPENPAM_STATIC_MODULES -O2 -pipe -I/usr/src/lib/libpam/modules/pam_passwdqc/../../../../contrib/pam_modules/pam_passwdqc -I/usr/src/lib/libpam/modules/pam_passwdqc/../../../../contrib/openpam/include -I/usr/src/lib/libpam/modules/pam_passwdqc/../../libpam -DOPENPAM_DEBUG -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c /usr/src/lib/libpam/modules/pam_passwdqc/../../../../contrib/pam_modules/pam_passwdqc/passwdqc_check.c -o passwdqc_check.o --- lib/ncurses/ncurses__L --- --- define_key.o --- cc -O2 -pipe -I. -I/usr/obj/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/base/define_key.c -o define_key.o --- lib/libthr__L --- --- thr_condattr.So --- cc -fpic -DPIC -g -O2 -pipe -DPTHREAD_KERNEL -I/usr/src/lib/libthr/../libc/include -I/usr/src/lib/libthr/thread -I/usr/src/lib/libthr/../../include -I/usr/src/lib/libthr/arch/i386/include -I/usr/src/lib/libthr/sys -I/usr/src/lib/libthr/../../libexec/rtld-elf -I/usr/src/lib/libthr/../../libexec/rtld-elf/i386 -I/usr/src/lib/libthr/../libthread_db -Winline -fexceptions -D_PTHREAD_FORCED_UNWIND -D_PTHREADS_INVARIANTS -mno-mmx -mno-sse -mno-avx -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/libthr/thread/thr_condattr.c -o thr_condattr.So --- lib/ncurses/ncurses__L --- --- define_key.So --- cc -fpic -DPIC -g -O2 -pipe -I. -I/usr/obj/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/base/define_key.c -o define_key.So --- lib/libthr__L --- --- thr_create.So --- cc -fpic -DPIC -g -O2 -pipe -DPTHREAD_KERNEL -I/usr/src/lib/libthr/../libc/include -I/usr/src/lib/libthr/thread -I/usr/src/lib/libthr/../../include -I/usr/src/lib/libthr/arch/i386/include -I/usr/src/lib/libthr/sys -I/usr/src/lib/libthr/../../libexec/rtld-elf -I/usr/src/lib/libthr/../../libexec/rtld-elf/i386 -I/usr/src/lib/libthr/../libthread_db -Winline -fexceptions -D_PTHREAD_FORCED_UNWIND -D_PTHREADS_INVARIANTS -mno-mmx -mno-sse -mno-avx -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/libthr/thread/thr_create.c -o thr_create.So --- lib/libpam__L --- --- passwdqc_random.o --- cc -DOPENPAM_STATIC_MODULES -O2 -pipe -I/usr/src/lib/libpam/modules/pam_passwdqc/../../../../contrib/pam_modules/pam_passwdqc -I/usr/src/lib/libpam/modules/pam_passwdqc/../../../../contrib/openpam/include -I/usr/src/lib/libpam/modules/pam_passwdqc/../../libpam -DOPENPAM_DEBUG -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c /usr/src/lib/libpam/modules/pam_passwdqc/../../../../contrib/pam_modules/pam_passwdqc/passwdqc_random.c -o passwdqc_random.o --- lib/ncurses/ncurses__L --- --- key_defined.o --- cc -O2 -pipe -I. -I/usr/obj/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/base/key_defined.c -o key_defined.o --- lib/libpam__L --- --- wordset_4k.o --- cc -DOPENPAM_STATIC_MODULES -O2 -pipe -I/usr/src/lib/libpam/modules/pam_passwdqc/../../../../contrib/pam_modules/pam_passwdqc -I/usr/src/lib/libpam/modules/pam_passwdqc/../../../../contrib/openpam/include -I/usr/src/lib/libpam/modules/pam_passwdqc/../../libpam -DOPENPAM_DEBUG -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c /usr/src/lib/libpam/modules/pam_passwdqc/../../../../contrib/pam_modules/pam_passwdqc/wordset_4k.c -o wordset_4k.o --- lib/ncurses/ncurses__L --- --- key_defined.So --- cc -fpic -DPIC -g -O2 -pipe -I. -I/usr/obj/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/base/key_defined.c -o key_defined.So --- lib/libpam__L --- --- libpam_passwdqc.a --- building static pam_passwdqc library ar -crD libpam_passwdqc.a `NM='nm' NMFLAGS='' lorder pam_passwdqc.o passwdqc_check.o passwdqc_random.o wordset_4k.o | tsort -q` --- lib/libthr__L --- --- thr_ctrdtr.So --- cc -fpic -DPIC -g -O2 -pipe -DPTHREAD_KERNEL -I/usr/src/lib/libthr/../libc/include -I/usr/src/lib/libthr/thread -I/usr/src/lib/libthr/../../include -I/usr/src/lib/libthr/arch/i386/include -I/usr/src/lib/libthr/sys -I/usr/src/lib/libthr/../../libexec/rtld-elf -I/usr/src/lib/libthr/../../libexec/rtld-elf/i386 -I/usr/src/lib/libthr/../libthread_db -Winline -fexceptions -D_PTHREAD_FORCED_UNWIND -D_PTHREADS_INVARIANTS -mno-mmx -mno-sse -mno-avx -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/libthr/thread/thr_ctrdtr.c -o thr_ctrdtr.So --- lib/libpam__L --- ranlib -D libpam_passwdqc.a ===> lib/libpam/modules/pam_permit (all) --- pam_permit.o --- cc -DOPENPAM_STATIC_MODULES -O2 -pipe -I/usr/src/lib/libpam/modules/pam_permit/../../../../contrib/openpam/include -I/usr/src/lib/libpam/modules/pam_permit/../../libpam -DOPENPAM_DEBUG -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/lib/libpam/modules/pam_permit/pam_permit.c -o pam_permit.o --- lib/ncurses/ncurses__L --- --- keybound.o --- --- lib/libpam__L --- --- libpam_permit.a --- --- lib/ncurses/ncurses__L --- cc -O2 -pipe -I. -I/usr/obj/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/base/keybound.c -o keybound.o --- lib/libpam__L --- building static pam_permit library ar -crD libpam_permit.a `NM='nm' NMFLAGS='' lorder pam_permit.o | tsort -q` ranlib -D libpam_permit.a ===> lib/libpam/modules/pam_radius (all) --- lib/libthr__L --- --- thr_detach.So --- cc -fpic -DPIC -g -O2 -pipe -DPTHREAD_KERNEL -I/usr/src/lib/libthr/../libc/include -I/usr/src/lib/libthr/thread -I/usr/src/lib/libthr/../../include -I/usr/src/lib/libthr/arch/i386/include -I/usr/src/lib/libthr/sys -I/usr/src/lib/libthr/../../libexec/rtld-elf -I/usr/src/lib/libthr/../../libexec/rtld-elf/i386 -I/usr/src/lib/libthr/../libthread_db -Winline -fexceptions -D_PTHREAD_FORCED_UNWIND -D_PTHREADS_INVARIANTS -mno-mmx -mno-sse -mno-avx -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/libthr/thread/thr_detach.c -o thr_detach.So --- lib/libpam__L --- --- pam_radius.o --- cc -DOPENPAM_STATIC_MODULES -O2 -pipe -I/usr/src/lib/libpam/modules/pam_radius/../../../../contrib/openpam/include -I/usr/src/lib/libpam/modules/pam_radius/../../libpam -DOPENPAM_DEBUG -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/libpam/modules/pam_radius/pam_radius.c -o pam_radius.o --- lib/ncurses/ncurses__L --- --- keybound.So --- cc -fpic -DPIC -g -O2 -pipe -I. -I/usr/obj/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/base/keybound.c -o keybound.So --- lib/libthr__L --- --- thr_equal.So --- cc -fpic -DPIC -g -O2 -pipe -DPTHREAD_KERNEL -I/usr/src/lib/libthr/../libc/include -I/usr/src/lib/libthr/thread -I/usr/src/lib/libthr/../../include -I/usr/src/lib/libthr/arch/i386/include -I/usr/src/lib/libthr/sys -I/usr/src/lib/libthr/../../libexec/rtld-elf -I/usr/src/lib/libthr/../../libexec/rtld-elf/i386 -I/usr/src/lib/libthr/../libthread_db -Winline -fexceptions -D_PTHREAD_FORCED_UNWIND -D_PTHREADS_INVARIANTS -mno-mmx -mno-sse -mno-avx -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/libthr/thread/thr_equal.c -o thr_equal.So --- lib/ncurses/ncurses__L --- --- keyok.o --- cc -O2 -pipe -I. -I/usr/obj/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/base/keyok.c -o keyok.o --- lib/libpam__L --- --- libpam_radius.a --- building static pam_radius library ar -crD libpam_radius.a `NM='nm' NMFLAGS='' lorder pam_radius.o | tsort -q` ranlib -D libpam_radius.a ===> lib/libpam/modules/pam_rhosts (all) --- lib/libthr__L --- --- thr_event.So --- cc -fpic -DPIC -g -O2 -pipe -DPTHREAD_KERNEL -I/usr/src/lib/libthr/../libc/include -I/usr/src/lib/libthr/thread -I/usr/src/lib/libthr/../../include -I/usr/src/lib/libthr/arch/i386/include -I/usr/src/lib/libthr/sys -I/usr/src/lib/libthr/../../libexec/rtld-elf -I/usr/src/lib/libthr/../../libexec/rtld-elf/i386 -I/usr/src/lib/libthr/../libthread_db -Winline -fexceptions -D_PTHREAD_FORCED_UNWIND -D_PTHREADS_INVARIANTS -mno-mmx -mno-sse -mno-avx -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/libthr/thread/thr_event.c -o thr_event.So --- lib/libpam__L --- --- pam_rhosts.o --- cc -DOPENPAM_STATIC_MODULES -O2 -pipe -I/usr/src/lib/libpam/modules/pam_rhosts/../../../../contrib/openpam/include -I/usr/src/lib/libpam/modules/pam_rhosts/../../libpam -DOPENPAM_DEBUG -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/lib/libpam/modules/pam_rhosts/pam_rhosts.c -o pam_rhosts.o --- libpam_rhosts.a --- building static pam_rhosts library --- lib/ncurses/ncurses__L --- --- keyok.So --- cc -fpic -DPIC -g -O2 -pipe -I. -I/usr/obj/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/base/keyok.c -o keyok.So --- lib/libpam__L --- ar -crD libpam_rhosts.a `NM='nm' NMFLAGS='' lorder pam_rhosts.o | tsort -q` ranlib -D libpam_rhosts.a ===> lib/libpam/modules/pam_rootok (all) --- pam_rootok.o --- cc -DOPENPAM_STATIC_MODULES -O2 -pipe -I/usr/src/lib/libpam/modules/pam_rootok/../../../../contrib/openpam/include -I/usr/src/lib/libpam/modules/pam_rootok/../../libpam -DOPENPAM_DEBUG -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/lib/libpam/modules/pam_rootok/pam_rootok.c -o pam_rootok.o --- lib/libthr__L --- --- thr_exit.So --- cc -fpic -DPIC -g -O2 -pipe -DPTHREAD_KERNEL -I/usr/src/lib/libthr/../libc/include -I/usr/src/lib/libthr/thread -I/usr/src/lib/libthr/../../include -I/usr/src/lib/libthr/arch/i386/include -I/usr/src/lib/libthr/sys -I/usr/src/lib/libthr/../../libexec/rtld-elf -I/usr/src/lib/libthr/../../libexec/rtld-elf/i386 -I/usr/src/lib/libthr/../libthread_db -Winline -fexceptions -D_PTHREAD_FORCED_UNWIND -D_PTHREADS_INVARIANTS -mno-mmx -mno-sse -mno-avx -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/libthr/thread/thr_exit.c -o thr_exit.So --- lib/libpam__L --- --- libpam_rootok.a --- building static pam_rootok library ar -crD libpam_rootok.a `NM='nm' NMFLAGS='' lorder pam_rootok.o | tsort -q` ranlib -D libpam_rootok.a ===> lib/libpam/modules/pam_securetty (all) --- lib/ncurses/ncurses__L --- --- legacy_coding.o --- cc -O2 -pipe -I. -I/usr/obj/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/base/legacy_coding.c -o legacy_coding.o --- lib/libpam__L --- --- pam_securetty.o --- cc -DOPENPAM_STATIC_MODULES -O2 -pipe -I/usr/src/lib/libpam/modules/pam_securetty/../../../../contrib/openpam/include -I/usr/src/lib/libpam/modules/pam_securetty/../../libpam -DOPENPAM_DEBUG -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/lib/libpam/modules/pam_securetty/pam_securetty.c -o pam_securetty.o --- libpam_securetty.a --- building static pam_securetty library ar -crD libpam_securetty.a `NM='nm' NMFLAGS='' lorder pam_securetty.o | tsort -q` ranlib -D libpam_securetty.a --- lib/ncurses/ncurses__L --- --- legacy_coding.So --- cc -fpic -DPIC -g -O2 -pipe -I. -I/usr/obj/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/base/legacy_coding.c -o legacy_coding.So --- lib/libpam__L --- ===> lib/libpam/modules/pam_self (all) --- pam_self.o --- cc -DOPENPAM_STATIC_MODULES -O2 -pipe -I/usr/src/lib/libpam/modules/pam_self/../../../../contrib/openpam/include -I/usr/src/lib/libpam/modules/pam_self/../../libpam -DOPENPAM_DEBUG -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/lib/libpam/modules/pam_self/pam_self.c -o pam_self.o --- lib/libthr__L --- --- thr_fork.So --- cc -fpic -DPIC -g -O2 -pipe -DPTHREAD_KERNEL -I/usr/src/lib/libthr/../libc/include -I/usr/src/lib/libthr/thread -I/usr/src/lib/libthr/../../include -I/usr/src/lib/libthr/arch/i386/include -I/usr/src/lib/libthr/sys -I/usr/src/lib/libthr/../../libexec/rtld-elf -I/usr/src/lib/libthr/../../libexec/rtld-elf/i386 -I/usr/src/lib/libthr/../libthread_db -Winline -fexceptions -D_PTHREAD_FORCED_UNWIND -D_PTHREADS_INVARIANTS -mno-mmx -mno-sse -mno-avx -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/libthr/thread/thr_fork.c -o thr_fork.So --- lib/libpam__L --- --- libpam_self.a --- building static pam_self library ar -crD libpam_self.a `NM='nm' NMFLAGS='' lorder pam_self.o | tsort -q` ranlib -D libpam_self.a ===> lib/libpam/modules/pam_ssh (all) --- lib/ncurses/ncurses__L --- --- lib_addch.o --- cc -O2 -pipe -I. -I/usr/obj/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/base/lib_addch.c -o lib_addch.o --- lib/libpam__L --- --- pam_ssh.o --- cc -DOPENPAM_STATIC_MODULES -O2 -pipe -I/usr/src/lib/libpam/modules/pam_ssh/../../../../crypto/openssh -include ssh_namespace.h -I/usr/src/lib/libpam/modules/pam_ssh/../../../../contrib/openpam/include -I/usr/src/lib/libpam/modules/pam_ssh/../../libpam -DOPENPAM_DEBUG -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/libpam/modules/pam_ssh/pam_ssh.c -o pam_ssh.o --- lib/libthr__L --- --- thr_getprio.So --- cc -fpic -DPIC -g -O2 -pipe -DPTHREAD_KERNEL -I/usr/src/lib/libthr/../libc/include -I/usr/src/lib/libthr/thread -I/usr/src/lib/libthr/../../include -I/usr/src/lib/libthr/arch/i386/include -I/usr/src/lib/libthr/sys -I/usr/src/lib/libthr/../../libexec/rtld-elf -I/usr/src/lib/libthr/../../libexec/rtld-elf/i386 -I/usr/src/lib/libthr/../libthread_db -Winline -fexceptions -D_PTHREAD_FORCED_UNWIND -D_PTHREADS_INVARIANTS -mno-mmx -mno-sse -mno-avx -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/libthr/thread/thr_getprio.c -o thr_getprio.So --- lib/ncurses/ncurses__L --- --- lib_addch.So --- cc -fpic -DPIC -g -O2 -pipe -I. -I/usr/obj/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/base/lib_addch.c -o lib_addch.So --- lib/libthr__L --- --- thr_getcpuclockid.So --- cc -fpic -DPIC -g -O2 -pipe -DPTHREAD_KERNEL -I/usr/src/lib/libthr/../libc/include -I/usr/src/lib/libthr/thread -I/usr/src/lib/libthr/../../include -I/usr/src/lib/libthr/arch/i386/include -I/usr/src/lib/libthr/sys -I/usr/src/lib/libthr/../../libexec/rtld-elf -I/usr/src/lib/libthr/../../libexec/rtld-elf/i386 -I/usr/src/lib/libthr/../libthread_db -Winline -fexceptions -D_PTHREAD_FORCED_UNWIND -D_PTHREADS_INVARIANTS -mno-mmx -mno-sse -mno-avx -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/libthr/thread/thr_getcpuclockid.c -o thr_getcpuclockid.So --- lib/libpam__L --- /usr/src/lib/libpam/modules/pam_ssh/pam_ssh.c:324:2: error: use of undeclared identifier 'AuthenticationConnection' AuthenticationConnection *ac; ^ /usr/src/lib/libpam/modules/pam_ssh/pam_ssh.c:324:28: error: use of undeclared identifier 'ac' AuthenticationConnection *ac; ^ /usr/src/lib/libpam/modules/pam_ssh/pam_ssh.c:339:12: error: implicit declaration of function 'ssh_get_authentication_connection' is invalid in C99 [-Werror,-Wimplicit-function-declaration] if ((ac = ssh_get_authentication_connection()) == NULL) { ^ /usr/src/lib/libpam/modules/pam_ssh/pam_ssh.c:339:7: error: use of undeclared identifier 'ac' if ((ac = ssh_get_authentication_connection()) == NULL) { ^ /usr/src/lib/libpam/modules/pam_ssh/pam_ssh.c:350:25: error: use of undeclared identifier 'ac' if (ssh_add_identity(ac, psk->key, psk->comment)) ^ /usr/src/lib/libpam/modules/pam_ssh/pam_ssh.c:66:31: note: expanded from macro 'ssh_add_identity' ssh_add_identity_constrained(auth, key, comment, 0, 0) ^ /usr/src/lib/libpam/modules/pam_ssh/pam_ssh.c:363:6: error: use of undeclared identifier 'ac' if (ac != NULL) ^ /usr/src/lib/libpam/modules/pam_ssh/pam_ssh.c:364:3: error: implicit declaration of function 'ssh_close_authentication_connection' is invalid in C99 [-Werror,-Wimplicit-function-declaration] ssh_close_authentication_connection(ac); ^ /usr/src/lib/libpam/modules/pam_ssh/pam_ssh.c:364:3: note: did you mean 'ssh_get_authentication_connection'? /usr/src/lib/libpam/modules/pam_ssh/pam_ssh.c:339:12: note: 'ssh_get_authentication_connection' declared here if ((ac = ssh_get_authentication_connection()) == NULL) { ^ /usr/src/lib/libpam/modules/pam_ssh/pam_ssh.c:364:39: error: use of undeclared identifier 'ac' ssh_close_authentication_connection(ac); ^ 8 errors generated. *** [pam_ssh.o] Error code 1 make[6]: stopped in /usr/src/lib/libpam/modules/pam_ssh 1 error make[6]: stopped in /usr/src/lib/libpam/modules/pam_ssh *** [all] Error code 2 make[5]: stopped in /usr/src/lib/libpam/modules 1 error make[5]: stopped in /usr/src/lib/libpam/modules *** [all] Error code 2 make[4]: stopped in /usr/src/lib/libpam 1 error make[4]: stopped in /usr/src/lib/libpam *** [lib/libpam__L] Error code 2 make[3]: stopped in /usr/src --- lib/libthr__L --- A failure has been detected in another branch of the parallel make make[4]: stopped in /usr/src/lib/libthr *** [lib/libthr__L] Error code 2 make[3]: stopped in /usr/src --- lib/ncurses/ncurses__L --- A failure has been detected in another branch of the parallel make make[4]: stopped in /usr/src/lib/ncurses/ncurses *** [lib/ncurses/ncurses__L] Error code 2 make[3]: stopped in /usr/src --- lib/ncurses/ncursesw__L --- A failure has been detected in another branch of the parallel make make[4]: stopped in /usr/src/lib/ncurses/ncursesw *** [lib/ncurses/ncursesw__L] Error code 2 make[3]: stopped in /usr/src 4 errors make[3]: stopped in /usr/src *** [libraries] Error code 2 make[2]: stopped in /usr/src 1 error make[2]: stopped in /usr/src *** [_libraries] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildworld] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src Build step 'Execute shell' marked build as failure [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_i386] $ /bin/sh -xe /tmp/hudson3650006979430188652.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_i386' + echo 'clean up jail FreeBSD_HEAD_i386' clean up jail FreeBSD_HEAD_i386 + sudo jail -r FreeBSD_HEAD_i386 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::106:1 -alias + sudo umount FreeBSD_HEAD_i386/usr/src + sudo umount FreeBSD_HEAD_i386/dev + sudo rm -fr FreeBSD_HEAD_i386 + true + sudo chflags -R noschg FreeBSD_HEAD_i386 + sudo rm -fr FreeBSD_HEAD_i386 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-current@freebsd.org Tue Jan 19 23:49:09 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 53C42A8912E for ; Tue, 19 Jan 2016 23:49:09 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id F08AE1E31; Tue, 19 Jan 2016 23:49:08 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Subject: Re: Shared library version bump? To: Dimitry Andric , Thomas Mueller References: <206770.43295.bm@smtp113.sbc.mail.ne1.yahoo.com> Cc: freebsd-current@freebsd.org From: Jung-uk Kim X-Enigmail-Draft-Status: N1110 Message-ID: <569ECB74.5010901@FreeBSD.org> Date: Tue, 19 Jan 2016 18:49:08 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 23:49:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 01/19/16 06:05 PM, Dimitry Andric wrote: > On 19 Jan 2016, at 23:32, Thomas Mueller > wrote: >> >> Has there recently been a version bump in the shared libraries? >> I saw no warning on this in the src or ports UPDATING files. > > This was already answered in reply to your previous post on this > same issue. As mentioned in the reply, OpenSSL has been upgraded, > and both of its shared libraries have been bumped, e.g. they are > now named libcrypto.so.8 and libssl.so.8. > > (Apparently you deleted the old libcrypto.so.7 and libssl.so.7, > even though you should never do so until your ports are upgraded.) > > >> I can no longer startx and can no longer run many other ports, >> getting errors like >> >> Shared object "libcrypto.so.7" not found, required by "X" xinit: >> giving up xinit: unable to connect to X server: Connection >> refused xinit: server error >> >> and >> >> root@amelia:~ # pkg info -f xserver Shared object "libssl.so.7" >> not found, required by "pkg" >> >> Is this due to a version bump, > > Yes. > > >> or is it related to the messages I got in yesterday's kernel >> installation like "unknown metadata record 4 ..."? > > No, that is something entirely different. It is mainly cosmetic, > and you can ignore it, it will go away at the next kernel update, > if your kldxref executable is new enough. > > >> What do I do? Make buildworld and kernel again, or rebuild all >> ports? How do I find which ports need updating, or rebuild all >> except portmaster and pkg which I rebuilt after getting the >> errors? > > It is easiest to use pkg-static to reinstall your ports, e.g.: > > pkg-static update pkg-static upgrade > > Alternatively, rebuild all ports depending on OpenSSL. A crude way to find almost all the ports depending on old OpenSSL is: find /usr/local -type f -exec file '{}' ';' | \ awk -F: '{ if ($2~/ELF/) print $1 }' | \ xargs egrep -l 'lib(crypto|ssl)\.so\.7' | \ xargs pkg-static which -oq | sort -u Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWnstwAAoJEHyflib82/FGXboH+wdNOXZ7i5z140BEbMlFeAH9 OCKq7fgwqyEzWjw73yiTcyTHir8nIuaFKkljMJFahEWR2/HMdFmBEoUheCWiscjx cN+Ek2ICTD/ghgz1LGLVQtXw9EAGvAfqCSz+iGaSgSu1AHxwuirk3GMORRXoBWNv eSrWfcP0bFDfb9p9zVNiMTnsMX4yKvuvDuXUxPsZSJyqb5vcctedIgwgV/L3Tq/X vY/Nx+xvX/nJMRzePje9/9IziWlGZCK0ZI+aBnYcFb4y8OWg5gYvkr/XdBXSb+Ke sgZrMAfdmyxDHv7AxDyVRgykHP00UIs3q5tvIDNxp47BEhu++niejX7+UsNHjNU= =8Jb1 -----END PGP SIGNATURE----- From owner-freebsd-current@freebsd.org Wed Jan 20 00:05:53 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AD049A89A22 for ; Wed, 20 Jan 2016 00:05:53 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 5AAE51A93; Wed, 20 Jan 2016 00:05:53 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Subject: Re: Shared library version bump? To: Dimitry Andric , Thomas Mueller References: <206770.43295.bm@smtp113.sbc.mail.ne1.yahoo.com> <569ECB74.5010901@FreeBSD.org> Cc: freebsd-current@freebsd.org From: Jung-uk Kim Message-ID: <569ECF61.60505@FreeBSD.org> Date: Tue, 19 Jan 2016 19:05:53 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <569ECB74.5010901@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 00:05:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 01/19/16 06:49 PM, Jung-uk Kim wrote: > On 01/19/16 06:05 PM, Dimitry Andric wrote: >> On 19 Jan 2016, at 23:32, Thomas Mueller >> wrote: >>> >>> Has there recently been a version bump in the shared >>> libraries? I saw no warning on this in the src or ports >>> UPDATING files. > >> This was already answered in reply to your previous post on this >> same issue. As mentioned in the reply, OpenSSL has been >> upgraded, and both of its shared libraries have been bumped, e.g. >> they are now named libcrypto.so.8 and libssl.so.8. > >> (Apparently you deleted the old libcrypto.so.7 and libssl.so.7, >> even though you should never do so until your ports are >> upgraded.) > > >>> I can no longer startx and can no longer run many other ports, >>> getting errors like >>> >>> Shared object "libcrypto.so.7" not found, required by "X" >>> xinit: giving up xinit: unable to connect to X server: >>> Connection refused xinit: server error >>> >>> and >>> >>> root@amelia:~ # pkg info -f xserver Shared object >>> "libssl.so.7" not found, required by "pkg" >>> >>> Is this due to a version bump, > >> Yes. > > >>> or is it related to the messages I got in yesterday's kernel >>> installation like "unknown metadata record 4 ..."? > >> No, that is something entirely different. It is mainly >> cosmetic, and you can ignore it, it will go away at the next >> kernel update, if your kldxref executable is new enough. > > >>> What do I do? Make buildworld and kernel again, or rebuild >>> all ports? How do I find which ports need updating, or rebuild >>> all except portmaster and pkg which I rebuilt after getting >>> the errors? > >> It is easiest to use pkg-static to reinstall your ports, e.g.: > >> pkg-static update pkg-static upgrade > >> Alternatively, rebuild all ports depending on OpenSSL. > > A crude way to find almost all the ports depending on old OpenSSL > is: > > find /usr/local -type f -exec file '{}' ';' | \ awk -F: '{ if > ($2~/ELF/) print $1 }' | \ xargs egrep -l 'lib(crypto|ssl)\.so\.7' > | \ xargs pkg-static which -oq | sort -u A slightly improved version (to exclude non-native ELF binaries): find /usr/local -type f -exec file -e elf '{}' ';' | \ awk -F: '{ if ($2~/ELF.*FreeBSD/) print $1 }' | \ xargs egrep -l 'lib(crypto|ssl)\.so\.7' | \ xargs pkg-static which -oq | sort -u Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWns9cAAoJEHyflib82/FGgqgIAJGZ/pP+hW6if0OI1bsCuvc8 yAGtNe1ODOlryysqqc/hXh0kxNFz2jZgvf/wxJeRrV1FXsnvi6eyrmSxKJp/uVPp Ichrmyh46C7Rj2XPCzmuNrWM4oTjCy1flOMk9JubpAyL8OH+TKT6icooj8hXUvBp razc6crsqNlfcPVeo+8XLvM6zz+hCQDDYd2ScvYBfMeuUJAHbBZ3PN6uyD+L2bag LR4DU/6twvR/KozxjtLqNSQ/k42TMt4wKgRZa6V1uyWdWNVWiWlbu/fM6vNfHjxZ 4nug6SIm8Vt9y0479MW19yrNIoNwWONYL5uYW4pDSpMABnqtkH9qgGYzVymWTpQ= =So35 -----END PGP SIGNATURE----- From owner-freebsd-current@freebsd.org Wed Jan 20 01:21:47 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1CBC7A82EB8 for ; Wed, 20 Jan 2016 01:21:47 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A02C914EF for ; Wed, 20 Jan 2016 01:21:46 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: by mail-wm0-x22d.google.com with SMTP id n5so5481012wmn.0 for ; Tue, 19 Jan 2016 17:21:46 -0800 (PST) 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=z4eZAaSbTlkLvkCAKwJ2U153HsLFgNQ741fiZND18Bg=; b=ETzYhuXaSzZwMNclEkN1I3uD38HRBrWkvAUbGp0Rs+EWeZfogfSzQkSOewqgmEpa45 l5z8a/uMIf72IiTSFvrHEEHRQbkuMVy3otfkj3mseW3ICqgwF/r35Jx7aC1mWVAmuTxw aVkubcXmGGMfjYU+YAMP7G/ZXwc5Mnd0Py3zWZDe25HdioHms1Lt+ahLG2dqX6uccQX3 413/fKovjfGVAwaICHWg/SltzqjsjJPd/ZNsQQqi7EuVUfZ1RIpKiLAzB71FzRyPLnSc jahVBw95QF3HLzaPRzOo5HXy94GTZ/bFcrqMQGxwMh9ows1OHaF/vPktXIq5b6z09sRB iG4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=z4eZAaSbTlkLvkCAKwJ2U153HsLFgNQ741fiZND18Bg=; b=Hr5kq1KvOas4VXwpOMU5MuRquFCf0oBOhb5/9Fz2sLJuYEEOjE1jZzWrtwHBxlnUYk JlgoETdw8hB4Axv9jFlRYqA8Tdi1Vd2Tscl65WWfYZwieEYBA4moJ9r+lIqz8EvfsPrS ZiWBNWWW5IIzRkiLc03u8sbDIQTz/+yOn8TARhQaJzGnQwG2CTn2p2cqal5mcRwm+v12 EXXVuu8HRh3bH/eN8MLuwvEKBmthgp/Laq1P5SIkYz0wE6eOSjjBicIzOMyPwbIE0v+p C6HjDPZqq+tfkK4RfLTFWhimdSzx7eGe9Ha/FUWWUxPViBwJpMWNRxL9ubC2iHWLexYL lGnQ== X-Gm-Message-State: AG10YOSd7UF7dpr5xikT8SjZSQXAw2hTixiiTMg2CI8KMrjvjggB8PineghCPzegGLKGZjWoLDanrdZNnWhiiw== MIME-Version: 1.0 X-Received: by 10.194.89.72 with SMTP id bm8mr969067wjb.60.1453252904615; Tue, 19 Jan 2016 17:21:44 -0800 (PST) Received: by 10.194.28.136 with HTTP; Tue, 19 Jan 2016 17:21:44 -0800 (PST) Date: Tue, 19 Jan 2016 19:21:44 -0600 Message-ID: Subject: iwn wlan connection losses after recent upgrade from 10-stable to head From: Adam Vande More To: "freebsd-current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 01:21:47 -0000 Recently I upgraded my system to head from 10-stable: 11.0-CURRENT #0 r293760: iwn0: mem 0xe3c00000-0xe3c01fff irq 17 at device 0.0 on pci2 net.wlan.debug: 1 net.wlan.0.debug: 1 wlan0: flags=8843 metric 0 mtu 1500 ether 24:77:03:07:32:b8 inet 192.168.254.21 netmask 0xffffff00 broadcast 192.168.254.255 nd6 options=29 media: IEEE 802.11 Wireless Ethernet MCS mode 11ng status: associated ssid SSID channel 1 (2412 MHz 11g ht/20) bssid 28:c6:8e:e6:04:7c country US authmode WPA2/802.11i privacy ON deftxkey UNDEF AES-CCM 2:128-bit AES-CCM 3:128-bit powersavemode CAM powersavesleep 100 txpower 13 bmiss 10 scanvalid 60 protmode CTS ampdulimit 64k ampdudensity 8 -amsdutx amsdurx shortgi wme roaming MANUAL groups: wlan While the 10-STABLE setup was never a pillar of reliability, HEAD seems to have made things worse for my wifi setup. Now my connections drops out several times a day at least resulting in logs such as this: wpa_supplicant[81975]: wlan0: CTRL-EVENT-DISCONNECTED bssid=28:c6:8e:e6:04:7c reason=0 kernel: wlan0: link state changed to DOWN wpa_supplicant[81975]: wlan0: Trying to associate with 28:c6:8e:e6:04:7c (SSID='SSID' freq=2412 MHz) wpa_supplicant[81975]: wlan0: Authentication with 28:c6:8e:e6:04:7c timed out. wpa_supplicant[81975]: wlan0: CTRL-EVENT-DISCONNECTED bssid=28:c6:8e:e6:04:7c reason=3 locally_generated=1 wpa_supplicant[81975]: wlan0: Trying to associate with 28:c6:8e:e6:04:7c (SSID='SSID' freq=2412 MHz) wpa_supplicant[81975]: wlan0: Authentication with 28:c6:8e:e6:04:7c timed out. wpa_supplicant[81975]: wlan0: CTRL-EVENT-DISCONNECTED bssid=28:c6:8e:e6:04:7c reason=3 locally_generated=1 wpa_supplicant[81975]: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=1 ssid="SSID" auth_failures=1 duration=10 reason=CONN_FAILED wpa_supplicant[81975]: wlan0: CTRL-EVENT-SSID-REENABLED id=1 ssid="SSID" wpa_supplicant[81975]: wlan0: Trying to associate with 28:c6:8e:e6:04:7c (SSID='SSID' freq=2412 MHz) wpa_supplicant[81975]: wlan0: Authentication with 28:c6:8e:e6:04:7c timed out. wpa_supplicant[81975]: wlan0: CTRL-EVENT-DISCONNECTED bssid=28:c6:8e:e6:04:7c reason=3 locally_generated=1 wpa_supplicant[81975]: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=1 ssid="SSID" auth_failures=2 duration=23 reason=CONN_FAILED wpa_supplicant[81975]: wlan0: CTRL-EVENT-SSID-REENABLED id=1 ssid="SSID" wpa_supplicant[81975]: wlan0: Trying to associate with 28:c6:8e:e6:04:7c (SSID='SSID' freq=2412 MHz) wpa_supplicant[81975]: wlan0: Authentication with 28:c6:8e:e6:04:7c timed out. Under 10-STABLE, such events were usually only a few times a week. I've just disabled N to see if that helps, but is the decreased reliability expected? Is there anything I can do to improve stability and preserve N? Thanks, -- Adam From owner-freebsd-current@freebsd.org Wed Jan 20 02:21:17 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45748A893EF; Wed, 20 Jan 2016 02:21:17 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 298D411A9; Wed, 20 Jan 2016 02:21:17 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 855DD11AD; Wed, 20 Jan 2016 02:21:17 +0000 (UTC) Date: Wed, 20 Jan 2016 02:21:15 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jhibbits@FreeBSD.org, marius@FreeBSD.org, bdrewery@FreeBSD.org, jhb@FreeBSD.org, asomers@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <2068844315.11.1453256477513.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <583836814.7.1453246306629.JavaMail.jenkins@jenkins-9.freebsd.org> References: <583836814.7.1453246306629.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #2146 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 02:21:17 -0000 FreeBSD_HEAD_i386 - Build #2146 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2146/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2146/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2146/console Change summaries: 294367 by jhb: Update for API changes in OpenSSH 6.8p1. First, the authfd API now uses a direct file descriptor for the control socket instead of a more abstract AuthenticationConnection structure. Second, the functions now consistently return an error value. Reviewed by: bdrewery 294366 by jhb: Initialize vm_page_prot to VM_MEMATTR_DEFAULT instead of 0. If a driver's Linux mmap callback passed vm_page_prot through unchanged, then linux_dev_mmap_single() would try to apply whatever VM_MEMATTR_xxx value 0 is to the mapping. On x86, VM_MEMATTR_DEFAULT is the PAT value for write-back (WB) which is 6, while 0 maps to the PAT value for uncacheable (UC). Thus, any mmap request that did not explicitly set page_prot was tried to map memory as UC triggering the warning in sg_pager_getpages(). Tested by: np Reported by: Krishnamraju Eraparaju @ Chelsio MFC after: 3 days Sponsored by: Chelsio Communications 294365 by jhb: List source files (foo.c) instead of object files in SRCS. Reviewed by: bdrewery 294363 by jhibbits: Revert a printf change from r294307. Caused build failures with MPC85XX. Pointy-hat to: jhibbits 294362 by marius: Fix tty_drain() and, thus, TIOCDRAIN of the current tty(4) incarnation to actually wait until the TX FIFOs of UARTs have be drained before returning. This is done by bringing the equivalent of the TS_BUSY flag found in the previous implementation back in an ABI-preserving way. Reported and tested by: Patrick Powell Most likely, drivers for USB-serial-adapters likewise incorporating TX FIFOs as well as other terminal devices that buffer output in some form should also provide implementations of tsw_busy. MFC after: 3 days 294361 by bdrewery: FAST_DEPEND: Fix improperly depending all .So objects on all headers. This was a regression in r290629, which was revealed partly in r294360. Once 'make depend' has ran it will generate all headers already. Thus even with FAST_DEPEND lacking proper dependencies before building, it will not have any missing headers. Once objects are compiled the depend files will be generated with proper dependencies. Sponsored by: EMC / Isilon Storage Division 294360 by bdrewery: Revert r294352. Further research showed it was the wrong fix and revealed a bigger problem with the goal of skipping 'make depend'. 294358 by asomers: Quell harmless CID about unchecked return value in nvlist_get_guids. The return value doesn't need to be checked, because nvlist_get_guid's callers check the returned values of the guids. Coverity CID: 1341869 MFC after: 1 week X-MFC-With: 292066 Sponsored by: Spectra Logic Corp From owner-freebsd-current@freebsd.org Wed Jan 20 04:11:47 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91810A89CD8; Wed, 20 Jan 2016 04:11:47 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 7684B1D76; Wed, 20 Jan 2016 04:11:47 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 5ECA811D5; Wed, 20 Jan 2016 04:11:47 +0000 (UTC) Date: Wed, 20 Jan 2016 04:11:43 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: bdrewery@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <546968128.15.1453263107204.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #2147 - Failure MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 04:11:47 -0000 FreeBSD_HEAD_i386 - Build #2147 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2147/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2147/cha= nges Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2147/cons= ole Change summaries: 294370 by bdrewery: mkdep: Fix -include not being added for .depend tracking. This fixes incremental build of OpenSSH after the recent upgrade. For example, in secure/lib/libssh, -include ssh_namespace.h is used on all files. This is not tracked in the .depend file though due to MKDEP_CFLAGS not including it. The ssh example was broken in r291941 when not using FAST_DEPEND due to the .depend bug. FAST_DEPEND was not affected by this because it generates dependencies at compile time and thus sees the -include. This ugly make syntax could be simpler for bmake by using :tW but fmake-compatible syntax is used since this needs to be MFC'd all the way to stable/9. Also add a temporary hack to workaround existing checkouts building incrementally with a .depend file not having these headers. MFC after:=091 week Sponsored by:=09EMC / Isilon Storage Division The end of the build log: [...truncated 171045 lines...] --- iwn2030fw.c --- awk -f /usr/src/sys/tools/fw_stub.awk iwnwifi-2030-18.168.6.1.fw:iwn2030fw = -miwn2030fw -ciwn2030fw.c =20 --- depend_subdir_ix --- In file included from /usr/src/sys/modules/ix/../../dev/ixgbe/ix_txrx.c:42: In file included from /usr/src/sys/modules/ix/../../dev/ixgbe/ixgbe.h:98: /usr/src/sys/dev/pci/pci_iov.h:32:10: fatal error: 'pci_iov_if.h' file not = found #include "pci_iov_if.h" ^ --- depend_subdir_iwnfw --- --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KER= NEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/usr/src/sys/GENERIC -D__pr= intf__=3D__freebsd_kprintf__ -std=3Diso9899:1999 -include /usr/obj/usr/sr= c/sys/GENERIC/opt_global.h iwn2030fw.c --- depend_subdir_ix --- 1 error generated. --- depend_subdir_iwnfw --- --- depend_subdir_iwn4965 --- =3D=3D=3D> iwnfw/iwn4965 (depend) --- depend_subdir_iwn5000 --- =3D=3D=3D> iwnfw/iwn5000 (depend) --- depend_subdir_iwn4965 --- --- machine --- machine -> /usr/src/sys/i386/include --- x86 --- x86 -> /usr/src/sys/x86/include --- depend_subdir_ix --- In file included from /usr/src/sys/modules/ix/../../dev/ixgbe/ixgbe_osdep.c= :36: --- depend_subdir_iwnfw --- --- iwn4965fw.c --- --- depend_subdir_ix --- In file included from /usr/src/sys/modules/ix/../../dev/ixgbe/ixgbe.h:98: /usr/src/sys/dev/pci/pci_iov.h:32:10: fatal error: 'pci_iov_if.h' file not = found #include "pci_iov_if.h" ^ --- depend_subdir_iwnfw --- awk -f /usr/src/sys/tools/fw_stub.awk iwlwifi-4965-228.61.2.24.fw:iwn4965fw= -miwn4965fw -ciwn4965fw.c =20 --- depend_subdir_ix --- 1 error generated. --- depend_subdir_iwnfw --- --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KER= NEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/usr/src/sys/GENERIC -D__pr= intf__=3D__freebsd_kprintf__ -std=3Diso9899:1999 -include /usr/obj/usr/sr= c/sys/GENERIC/opt_global.h iwn4965fw.c --- depend_subdir_iwn5000 --- --- machine --- machine -> /usr/src/sys/i386/include --- x86 --- x86 -> /usr/src/sys/x86/include --- iwn5000fw.c --- awk -f /usr/src/sys/tools/fw_stub.awk iwlwifi-5000-8.83.5.1.fw:iwn5000fw -m= iwn5000fw -ciwn5000fw.c =20 --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KER= NEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/usr/src/sys/GENERIC -D__pr= intf__=3D__freebsd_kprintf__ -std=3Diso9899:1999 -include /usr/obj/usr/sr= c/sys/GENERIC/opt_global.h iwn5000fw.c --- depend_subdir_ixv --- =3D=3D=3D> ixv (depend) --- depend_subdir_iwnfw --- --- depend_subdir_iwn5150 --- =3D=3D=3D> iwnfw/iwn5150 (depend) --- depend_subdir_ixv --- --- machine --- machine -> /usr/src/sys/i386/include --- x86 --- x86 -> /usr/src/sys/x86/include --- opt_inet.h --- ln -sf /usr/obj/usr/src/sys/GENERIC/opt_inet.h opt_inet.h --- opt_inet6.h --- ln -sf /usr/obj/usr/src/sys/GENERIC/opt_inet6.h opt_inet6.h --- opt_rss.h --- ln -sf /usr/obj/usr/src/sys/GENERIC/opt_rss.h opt_rss.h --- device_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h --- depend_subdir_iwnfw --- --- machine --- machine -> /usr/src/sys/i386/include --- x86 --- --- depend_subdir_ixv --- --- bus_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h --- depend_subdir_iwnfw --- x86 -> /usr/src/sys/x86/include --- iwn5150fw.c --- awk -f /usr/src/sys/tools/fw_stub.awk iwlwifi-5150-8.24.2.2.fw:iwn5150fw -m= iwn5150fw -ciwn5150fw.c =20 --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KER= NEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/usr/src/sys/GENERIC -D__pr= intf__=3D__freebsd_kprintf__ -std=3Diso9899:1999 -include /usr/obj/usr/sr= c/sys/GENERIC/opt_global.h iwn5150fw.c --- depend_subdir_ixv --- --- pci_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/pci/pci_if.m -h --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -nostdinc -DSMP -D_KERNEL -DKLD_MODULE -I/u= sr/src/sys/modules/ixv/../../dev/ixgbe -DHAVE_KERNEL_OPTION_HEADERS -I. -I/= usr/src/sys -I/usr/obj/usr/src/sys/GENERIC -D__printf__=3D__freebsd_kprintf= __ -std=3Diso9899:1999 -include /usr/obj/usr/src/sys/GENERIC/opt_global.h= /usr/src/sys/modules/ixv/../../dev/ixgbe/if_ixv.c /usr/src/sys/modules/ixv= /../../dev/ixgbe/ix_txrx.c /usr/src/sys/modules/ixv/../../dev/ixgbe/ixgbe_o= sdep.c /usr/src/sys/modules/ixv/../../dev/ixgbe/ixgbe_common.c /usr/src/sys= /modules/ixv/../../dev/ixgbe/ixgbe_api.c /usr/src/sys/modules/ixv/../../dev= /ixgbe/ixgbe_phy.c /usr/src/sys/modules/ixv/../../dev/ixgbe/ixgbe_mbx.c /us= r/src/sys/modules/ixv/../../dev/ixgbe/ixgbe_vf.c /usr/src/sys/modules/ixv/.= ./../dev/ixgbe/ixgbe_dcb.c /usr/src/sys/modules/ixv/../../dev/ixgbe/ixgbe_d= cb_82598.c /usr/src/sys/modules/ixv/../../dev/ixgbe/ixgbe_dcb_82599.c /usr/= src/sys/modules/ixv/../../dev/ixgbe/ixgbe_82598.c /usr/src/sys/modules/ixv/= ../../dev/ixgbe/ixgbe_82599.c /usr/src/sys/modules/ixv/../../dev/ixgbe/ixgb= e_x540.c /usr/src/sys/modules/ixv/../../dev/ixgbe/ixgbe_x550.c --- depend_subdir_iwnfw --- --- depend_subdir_iwn6000 --- =3D=3D=3D> iwnfw/iwn6000 (depend) --- machine --- machine -> /usr/src/sys/i386/include --- x86 --- x86 -> /usr/src/sys/x86/include --- iwn6000fw.c --- awk -f /usr/src/sys/tools/fw_stub.awk iwlwifi-6000-9.221.4.1.fw:iwn6000fw -= miwn6000fw -ciwn6000fw.c =20 --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KER= NEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/usr/src/sys/GENERIC -D__pr= intf__=3D__freebsd_kprintf__ -std=3Diso9899:1999 -include /usr/obj/usr/sr= c/sys/GENERIC/opt_global.h iwn6000fw.c --- depend_subdir_ixv --- In file included from /usr/src/sys/modules/ixv/../../dev/ixgbe/if_ixv.c:41: In file included from /usr/src/sys/modules/ixv/../../dev/ixgbe/ixgbe.h:98: /usr/src/sys/dev/pci/pci_iov.h:32:10: fatal error: 'pci_iov_if.h' file not = found #include "pci_iov_if.h" ^ 1 error generated. --- depend_subdir_iwnfw --- --- depend_subdir_iwn6000g2a --- =3D=3D=3D> iwnfw/iwn6000g2a (depend) --- machine --- machine -> /usr/src/sys/i386/include --- x86 --- x86 -> /usr/src/sys/x86/include --- iwn6000g2afw.c --- awk -f /usr/src/sys/tools/fw_stub.awk iwlwifi-6000g2a-18.168.6.1.fw:iwn6000= g2afw -miwn6000g2afw -ciwn6000g2afw.c =20 --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KER= NEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/usr/src/sys/GENERIC -D__pr= intf__=3D__freebsd_kprintf__ -std=3Diso9899:1999 -include /usr/obj/usr/sr= c/sys/GENERIC/opt_global.h iwn6000g2afw.c --- depend_subdir_ixv --- In file included from /usr/src/sys/modules/ixv/../../dev/ixgbe/ix_txrx.c:42= : In file included from /usr/src/sys/modules/ixv/../../dev/ixgbe/ixgbe.h:98: /usr/src/sys/dev/pci/pci_iov.h:32:10: fatal error: 'pci_iov_if.h' file not = found #include "pci_iov_if.h" ^ 1 error generated. --- depend_subdir_iwnfw --- --- depend_subdir_iwn6000g2b --- =3D=3D=3D> iwnfw/iwn6000g2b (depend) --- machine --- machine -> /usr/src/sys/i386/include --- x86 --- x86 -> /usr/src/sys/x86/include --- iwn6000g2bfw.c --- awk -f /usr/src/sys/tools/fw_stub.awk iwlwifi-6000g2b-18.168.6.1.fw:iwn6000= g2bfw -miwn6000g2bfw -ciwn6000g2bfw.c =20 --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KER= NEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/usr/src/sys/GENERIC -D__pr= intf__=3D__freebsd_kprintf__ -std=3Diso9899:1999 -include /usr/obj/usr/sr= c/sys/GENERIC/opt_global.h iwn6000g2bfw.c --- depend_subdir_ixv --- In file included from /usr/src/sys/modules/ixv/../../dev/ixgbe/ixgbe_osdep.= c:36: In file included from /usr/src/sys/modules/ixv/../../dev/ixgbe/ixgbe.h:98: /usr/src/sys/dev/pci/pci_iov.h:32:10: fatal error: 'pci_iov_if.h' file not = found #include "pci_iov_if.h" ^ 1 error generated. --- depend_subdir_iwnfw --- --- depend_subdir_iwn6050 --- =3D=3D=3D> iwnfw/iwn6050 (depend) --- machine --- machine -> /usr/src/sys/i386/include --- x86 --- x86 -> /usr/src/sys/x86/include --- iwn6050fw.c --- awk -f /usr/src/sys/tools/fw_stub.awk iwlwifi-6050-41.28.5.1.fw:iwn6050fw -= miwn6050fw -ciwn6050fw.c =20 --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KER= NEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/usr/src/sys/GENERIC -D__pr= intf__=3D__freebsd_kprintf__ -std=3Diso9899:1999 -include /usr/obj/usr/sr= c/sys/GENERIC/opt_global.h iwn6050fw.c --- depend_subdir_jme --- =3D=3D=3D> jme (depend) --- machine --- machine -> /usr/src/sys/i386/include --- x86 --- x86 -> /usr/src/sys/x86/include --- device_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h --- bus_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h --- pci_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/pci/pci_if.m -h --- miibus_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/mii/miibus_if.m -= h --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KER= NEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/usr/src/sys/GENERIC -D__pr= intf__=3D__freebsd_kprintf__ -std=3Diso9899:1999 -include /usr/obj/usr/sr= c/sys/GENERIC/opt_global.h /usr/src/sys/modules/jme/../../dev/jme/if_jme.c --- depend_subdir_ix --- mkdep: compile failed *** [.depend] Error code 1 make[4]: stopped in /usr/src/sys/modules/ix 1 error make[4]: stopped in /usr/src/sys/modules/ix *** [depend_subdir_ix] Error code 2 make[3]: stopped in /usr/src/sys/modules --- depend_subdir_jme --- A failure has been detected in another branch of the parallel make make[4]: stopped in /usr/src/sys/modules/jme *** [depend_subdir_jme] Error code 2 make[3]: stopped in /usr/src/sys/modules --- depend_subdir_ixv --- mkdep: compile failed *** [.depend] Error code 1 make[4]: stopped in /usr/src/sys/modules/ixv 1 error make[4]: stopped in /usr/src/sys/modules/ixv *** [depend_subdir_ixv] Error code 2 make[3]: stopped in /usr/src/sys/modules --- depend_subdir_isci --- A failure has been detected in another branch of the parallel make make[4]: stopped in /usr/src/sys/modules/isci *** [depend_subdir_isci] Error code 2 make[3]: stopped in /usr/src/sys/modules 4 errors make[3]: stopped in /usr/src/sys/modules *** [modules-depend] Error code 2 make[2]: stopped in /usr/obj/usr/src/sys/GENERIC 1 error make[2]: stopped in /usr/obj/usr/src/sys/GENERIC *** [buildkernel] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildkernel] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src Build step 'Execute shell' marked build as failure [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_i386] $ /bin/sh -xe /tmp/hudson3923108925302119213.sh + export 'PATH=3D/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/b= in' + export 'jname=3DFreeBSD_HEAD_i386' + echo 'clean up jail FreeBSD_HEAD_i386' clean up jail FreeBSD_HEAD_i386 + sudo jail -r FreeBSD_HEAD_i386 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::106:1 -alias + sudo umount FreeBSD_HEAD_i386/usr/src + sudo umount FreeBSD_HEAD_i386/dev + sudo rm -fr FreeBSD_HEAD_i386 + true + sudo chflags -R noschg FreeBSD_HEAD_i386 + sudo rm -fr FreeBSD_HEAD_i386 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-current@freebsd.org Wed Jan 20 04:39:14 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 199AEA87678 for ; Wed, 20 Jan 2016 04:39:14 +0000 (UTC) (envelope-from mueller6724@bellsouth.net) Received: from nm13-vm9.access.bullet.mail.gq1.yahoo.com (nm13-vm9.access.bullet.mail.gq1.yahoo.com [216.39.63.251]) (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 E442918FC for ; Wed, 20 Jan 2016 04:39:01 +0000 (UTC) (envelope-from mueller6724@bellsouth.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s2048; t=1453264582; bh=cP+iKwNPDpm5Or2ruAXOvaz2iRshNzPYMDYXwFGIOGI=; h=Date:From:To:Subject:References:From:Subject; b=N7R+0bJFTifzlLXgyiqJiy2pnbKSVvnSR6xuyXoJega7rcPbZ6R2zplj2RRKRUC6IDriZI79HVVFopHMzYvhZUlru4lOz6Pf0cFJnO9isRNZ61Ln1U1RDU+g/+Nm/NqsnL3TYslDTgrwv+wTJXwdcKcQrqf6CQzCPdiCwsUt3o7kH/aYkDhy5245+HDOq7jRGIsNeTwotKW3HSYU4d/LRx/J1f7BCNwax7eX0RdJv63wQT8Jrf/jMxaDVFV968G9o7nKTANJI2dpBkiWqPaP84lfOQpV+hiIkamcJfspYaVyExNHv5YHlHlFdmF4LLDvtzuWVh4hasC5A2suA1shDw== Received: from [216.39.60.175] by nm13.access.bullet.mail.gq1.yahoo.com with NNFMP; 20 Jan 2016 04:36:22 -0000 Received: from [98.138.104.98] by tm11.access.bullet.mail.gq1.yahoo.com with NNFMP; 20 Jan 2016 04:36:22 -0000 Received: from [127.0.0.1] by smtp118.sbc.mail.ne1.yahoo.com with NNFMP; 20 Jan 2016 04:36:22 -0000 X-Yahoo-Newman-Id: 620388.53050.bm@smtp118.sbc.mail.ne1.yahoo.com Message-ID: <620388.53050.bm@smtp118.sbc.mail.ne1.yahoo.com> X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: PyAPDRYVM1kCsCjxCPU6t4sBIWxSneHWvc2Sxa8ytqjnvhj 2lWQWGa5piVA11VjCNpUjjw8Nw89cInQDP92pwcf0lRvfBRvasvHgj39Twm4 Sju7uKwwMAU4o3OahkQnyw0YWPpDuhqZAxv92RMtCDkhQa.WgKmvWfjX3fva 9CiEED.zVFno6US7NZnPgNFpAUHr9rRJDhKDh0efO8qUdbnWITqtWWq7B.rX F_G.jJnkMllQH6SHdJLUVHVf5eazIwpOHQ1wkZ7eu773t.elVuBPX3n8bNyo TtH4tVRrzOimufdCiUAbaAjR2JZZxu7MbAwep7V3bcMz7neTAZJgYCC2Lrwq Z1jvJ1EmeP0czGMawO5Nua1JGd.LnKCmZ3PWQoUFH40HQmYV91CPn613q3Ui .Mwe3o5drIgFIFXLacqUZ_Yd.nRA7yNi84KfMFGXtvZ1xmPYeHbjntimQBaQ BYk.d_H_UeZboEEGu3M_owPHPZcDabxraX5oz6Eaw6esaahTD07vtEvGCG9j zfE2cfb4xcXGHt00Qa3Z7Vc0jdUYuGkMszZZFKkeAvcUeomr17e5Y2QJdlaY - X-Yahoo-SMTP: Kz_aW1.swBBYof3zAD7.RWzXz9ZAQVDMml1VADsbgPT4Kq79LC0- Date: Wed, 20 Jan 2016 04:35:52 +0000 From: "Thomas Mueller" To: freebsd-current@freebsd.org Subject: Re: libcrypto.so.7 not found, needed (?) for X server References: <930546.92837.bm@smtp115.sbc.mail.ne1.yahoo.com> <26A67E1C-7E42-43B5-8433-D5551350B993@FreeBSD.org> <20160119131844.GS13446@albert.catwhisker.org> <1975711404.11815108.1453209798928.JavaMail.yahoo@mail.yahoo.com> <20160119140611.GC69902@ivaldir.etoilebsd.net> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 04:39:14 -0000 Thanks for helpful advice, too much to quote, and I am too tired anyway after a sleepless night and day, was up too late with the HP LaserJet printer. It looks like I might have to rebuild all ports except for portmaster and pkg, already done; update perl to perl5.22, check the list of ports for desired deletions and additions. pkg and "pkg check" seem to know nothing about required shared libraries in base system. Everything was built under FreeBSD-head, though I have 10.2-STABLE in a separate partition, can use that for subversion; also some USB-stick installations of FreeBSD and NetBSD that include subversion. Tom From owner-freebsd-current@freebsd.org Wed Jan 20 08:11:33 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3EC2A89BE2; Wed, 20 Jan 2016 08:11:33 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id A98611141; Wed, 20 Jan 2016 08:11:33 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 575331242; Wed, 20 Jan 2016 08:11:33 +0000 (UTC) Date: Wed, 20 Jan 2016 08:11:30 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: arybchik@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <615234885.17.1453277492788.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <546968128.15.1453263107204.JavaMail.jenkins@jenkins-9.freebsd.org> References: <546968128.15.1453263107204.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #2148 - Still Failing MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 08:11:34 -0000 FreeBSD_HEAD_i386 - Build #2148 - Still Failing: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2148/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2148/cha= nges Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2148/cons= ole Change summaries: 294372 by arybchik: sfxge: refresh version to note matching version of out-of-tree driver Sponsored by: Solarflare Communications, Inc. MFC after: 2 days 294371 by arybchik: sfxge: cleanup: support __out_bcount_part[_opt] PREfast annotations New annotation coming into use in the common code. Support its use by adding null macro definitions for non-Windows platforms. Submitted by: Richard Houldsworth Sponsored by: Solarflare Communications, Inc. X-MFC with: r293901 The end of the build log: [...truncated 171728 lines...] machine -> /usr/src/sys/i386/include --- depend_subdir_ixgb --- --- bus_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h --- depend_subdir_iwnfw --- --- x86 --- x86 -> /usr/src/sys/x86/include --- iwn5000fw.c --- awk -f /usr/src/sys/tools/fw_stub.awk iwlwifi-5000-8.83.5.1.fw:iwn5000fw -m= iwn5000fw -ciwn5000fw.c =20 --- depend_subdir_ix --- 1 error generated. --- depend_subdir_iwnfw --- --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KER= NEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/usr/src/sys/GENERIC -D__pr= intf__=3D__freebsd_kprintf__ -std=3Diso9899:1999 -include /usr/obj/usr/sr= c/sys/GENERIC/opt_global.h iwn5000fw.c --- depend_subdir_ixgb --- --- pci_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/pci/pci_if.m -h --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KER= NEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/usr/src/sys/GENERIC -D__pr= intf__=3D__freebsd_kprintf__ -std=3Diso9899:1999 -include /usr/obj/usr/sr= c/sys/GENERIC/opt_global.h /usr/src/sys/modules/ixgb/../../dev/ixgb/if_ixgb= .c /usr/src/sys/modules/ixgb/../../dev/ixgb/ixgb_hw.c /usr/src/sys/modules/= ixgb/../../dev/ixgb/ixgb_ee.c --- depend_subdir_iwnfw --- --- depend_subdir_iwn5150 --- =3D=3D=3D> iwnfw/iwn5150 (depend) --- depend_subdir_ix --- In file included from /usr/src/sys/modules/ix/../../dev/ixgbe/ixgbe_osdep.c= :36: In file included from /usr/src/sys/modules/ix/../../dev/ixgbe/ixgbe.h:98: /usr/src/sys/dev/pci/pci_iov.h:32:10: fatal error: 'pci_iov_if.h' file not = found #include "pci_iov_if.h" ^ 1 error generated. --- depend_subdir_iwnfw --- --- machine --- machine -> /usr/src/sys/i386/include --- x86 --- x86 -> /usr/src/sys/x86/include --- iwn5150fw.c --- awk -f /usr/src/sys/tools/fw_stub.awk iwlwifi-5150-8.24.2.2.fw:iwn5150fw -m= iwn5150fw -ciwn5150fw.c =20 --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KER= NEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/usr/src/sys/GENERIC -D__pr= intf__=3D__freebsd_kprintf__ -std=3Diso9899:1999 -include /usr/obj/usr/sr= c/sys/GENERIC/opt_global.h iwn5150fw.c --- depend_subdir_iwn6000 --- =3D=3D=3D> iwnfw/iwn6000 (depend) --- machine --- machine -> /usr/src/sys/i386/include --- x86 --- x86 -> /usr/src/sys/x86/include --- iwn6000fw.c --- awk -f /usr/src/sys/tools/fw_stub.awk iwlwifi-6000-9.221.4.1.fw:iwn6000fw -= miwn6000fw -ciwn6000fw.c =20 --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KER= NEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/usr/src/sys/GENERIC -D__pr= intf__=3D__freebsd_kprintf__ -std=3Diso9899:1999 -include /usr/obj/usr/sr= c/sys/GENERIC/opt_global.h iwn6000fw.c --- depend_subdir_iwn6000g2a --- =3D=3D=3D> iwnfw/iwn6000g2a (depend) --- depend_subdir_ixv --- =3D=3D=3D> ixv (depend) --- depend_subdir_iwnfw --- --- machine --- machine -> /usr/src/sys/i386/include --- x86 --- x86 -> /usr/src/sys/x86/include --- iwn6000g2afw.c --- awk -f /usr/src/sys/tools/fw_stub.awk iwlwifi-6000g2a-18.168.6.1.fw:iwn6000= g2afw -miwn6000g2afw -ciwn6000g2afw.c =20 --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KER= NEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/usr/src/sys/GENERIC -D__pr= intf__=3D__freebsd_kprintf__ -std=3Diso9899:1999 -include /usr/obj/usr/sr= c/sys/GENERIC/opt_global.h iwn6000g2afw.c --- depend_subdir_ixv --- --- machine --- machine -> /usr/src/sys/i386/include --- x86 --- x86 -> /usr/src/sys/x86/include --- opt_inet.h --- ln -sf /usr/obj/usr/src/sys/GENERIC/opt_inet.h opt_inet.h --- opt_inet6.h --- ln -sf /usr/obj/usr/src/sys/GENERIC/opt_inet6.h opt_inet6.h --- opt_rss.h --- ln -sf /usr/obj/usr/src/sys/GENERIC/opt_rss.h opt_rss.h --- device_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h --- bus_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h --- depend_subdir_iwnfw --- --- depend_subdir_iwn6000g2b --- =3D=3D=3D> iwnfw/iwn6000g2b (depend) --- depend_subdir_ixv --- --- pci_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/pci/pci_if.m -h --- .depend --- --- depend_subdir_iwnfw --- --- machine --- --- depend_subdir_ixv --- rm -f .depend --- depend_subdir_iwnfw --- machine -> /usr/src/sys/i386/include --- depend_subdir_ixv --- CC=3D'cc' mkdep -f .depend -a -nostdinc -DSMP -D_KERNEL -DKLD_MODULE -I/u= sr/src/sys/modules/ixv/../../dev/ixgbe -DHAVE_KERNEL_OPTION_HEADERS -I. -I/= usr/src/sys -I/usr/obj/usr/src/sys/GENERIC -D__printf__=3D__freebsd_kprintf= __ -std=3Diso9899:1999 -include /usr/obj/usr/src/sys/GENERIC/opt_global.h= /usr/src/sys/modules/ixv/../../dev/ixgbe/if_ixv.c /usr/src/sys/modules/ixv= /../../dev/ixgbe/ix_txrx.c /usr/src/sys/modules/ixv/../../dev/ixgbe/ixgbe_o= sdep.c /usr/src/sys/modules/ixv/../../dev/ixgbe/ixgbe_common.c /usr/src/sys= /modules/ixv/../../dev/ixgbe/ixgbe_api.c /usr/src/sys/modules/ixv/../../dev= /ixgbe/ixgbe_phy.c /usr/src/sys/modules/ixv/../../dev/ixgbe/ixgbe_mbx.c /us= r/src/sys/modules/ixv/../../dev/ixgbe/ixgbe_vf.c /usr/src/sys/modules/ixv/.= ./../dev/ixgbe/ixgbe_dcb.c /usr/src/sys/modules/ixv/../../dev/ixgbe/ixgbe_d= cb_82598.c /usr/src/sys/modules/ixv/../../dev/ixgbe/ixgbe_dcb_82599.c /usr/= src/sys/modules/ixv/../../dev/ixgbe/ixgbe_82598.c /usr/src/sys/modules/ixv/= ../../dev/ixgbe/ixgbe_82599.c /usr/src/sys/modules/ixv/../../dev/ixgbe/ixgb= e_x540.c /usr/src/sys/modules/ixv/../../dev/ixgbe/ixgbe_x550.c --- depend_subdir_iwnfw --- --- x86 --- x86 -> /usr/src/sys/x86/include --- iwn6000g2bfw.c --- awk -f /usr/src/sys/tools/fw_stub.awk iwlwifi-6000g2b-18.168.6.1.fw:iwn6000= g2bfw -miwn6000g2bfw -ciwn6000g2bfw.c =20 --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KER= NEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/usr/src/sys/GENERIC -D__pr= intf__=3D__freebsd_kprintf__ -std=3Diso9899:1999 -include /usr/obj/usr/sr= c/sys/GENERIC/opt_global.h iwn6000g2bfw.c --- depend_subdir_iwn6050 --- =3D=3D=3D> iwnfw/iwn6050 (depend) --- machine --- machine -> /usr/src/sys/i386/include --- x86 --- x86 -> /usr/src/sys/x86/include --- iwn6050fw.c --- awk -f /usr/src/sys/tools/fw_stub.awk iwlwifi-6050-41.28.5.1.fw:iwn6050fw -= miwn6050fw -ciwn6050fw.c =20 --- depend_subdir_ixv --- In file included from /usr/src/sys/modules/ixv/../../dev/ixgbe/if_ixv.c:41: --- depend_subdir_iwnfw --- --- .depend --- rm -f .depend --- depend_subdir_ixv --- In file included from /usr/src/sys/modules/ixv/../../dev/ixgbe/ixgbe.h:98: /usr/src/sys/dev/pci/pci_iov.h:32:10: fatal error: 'pci_iov_if.h' file not = found #include "pci_iov_if.h" ^ --- depend_subdir_iwnfw --- CC=3D'cc' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KER= NEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/usr/src/sys/GENERIC -D__pr= intf__=3D__freebsd_kprintf__ -std=3Diso9899:1999 -include /usr/obj/usr/sr= c/sys/GENERIC/opt_global.h iwn6050fw.c --- depend_subdir_ixv --- 1 error generated. --- depend_subdir_jme --- =3D=3D=3D> jme (depend) --- depend_subdir_ixv --- In file included from /usr/src/sys/modules/ixv/../../dev/ixgbe/ix_txrx.c:42= : In file included from /usr/src/sys/modules/ixv/../../dev/ixgbe/ixgbe.h:98: /usr/src/sys/dev/pci/pci_iov.h:32:10: fatal error: 'pci_iov_if.h' file not = found #include "pci_iov_if.h" ^ --- depend_subdir_jme --- --- machine --- machine -> /usr/src/sys/i386/include --- x86 --- x86 -> /usr/src/sys/x86/include --- device_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h --- depend_subdir_ixv --- 1 error generated. --- depend_subdir_jme --- --- bus_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h --- pci_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/pci/pci_if.m -h --- miibus_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/mii/miibus_if.m -= h --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KER= NEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/usr/src/sys/GENERIC -D__pr= intf__=3D__freebsd_kprintf__ -std=3Diso9899:1999 -include /usr/obj/usr/sr= c/sys/GENERIC/opt_global.h /usr/src/sys/modules/jme/../../dev/jme/if_jme.c --- depend_subdir_ixv --- In file included from /usr/src/sys/modules/ixv/../../dev/ixgbe/ixgbe_osdep.= c:36: In file included from /usr/src/sys/modules/ixv/../../dev/ixgbe/ixgbe.h:98: /usr/src/sys/dev/pci/pci_iov.h:32:10: fatal error: 'pci_iov_if.h' file not = found #include "pci_iov_if.h" ^ 1 error generated. --- depend_subdir_joy --- =3D=3D=3D> joy (depend) --- machine --- machine -> /usr/src/sys/i386/include --- x86 --- x86 -> /usr/src/sys/x86/include --- bus_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h --- device_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h --- isa_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/isa/isa_if.m -h --- depend_subdir_ix --- mkdep: compile failed *** [.depend] Error code 1 make[4]: stopped in /usr/src/sys/modules/ix 1 error make[4]: stopped in /usr/src/sys/modules/ix *** [depend_subdir_ix] Error code 2 make[3]: stopped in /usr/src/sys/modules --- depend_subdir_joy --- --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KER= NEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/usr/src/sys/GENERIC -D__pr= intf__=3D__freebsd_kprintf__ -std=3Diso9899:1999 -include /usr/obj/usr/sr= c/sys/GENERIC/opt_global.h /usr/src/sys/modules/joy/../../dev/joy/joy.c /us= r/src/sys/modules/joy/../../dev/joy/joy_isa.c A failure has been detected in another branch of the parallel make make[4]: stopped in /usr/src/sys/modules/joy *** [depend_subdir_joy] Error code 2 make[3]: stopped in /usr/src/sys/modules --- depend_subdir_ixv --- mkdep: compile failed *** [.depend] Error code 1 make[4]: stopped in /usr/src/sys/modules/ixv 1 error make[4]: stopped in /usr/src/sys/modules/ixv *** [depend_subdir_ixv] Error code 2 make[3]: stopped in /usr/src/sys/modules --- depend_subdir_isci --- A failure has been detected in another branch of the parallel make make[4]: stopped in /usr/src/sys/modules/isci *** [depend_subdir_isci] Error code 2 make[3]: stopped in /usr/src/sys/modules 4 errors make[3]: stopped in /usr/src/sys/modules *** [modules-depend] Error code 2 make[2]: stopped in /usr/obj/usr/src/sys/GENERIC 1 error make[2]: stopped in /usr/obj/usr/src/sys/GENERIC *** [buildkernel] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildkernel] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src Build step 'Execute shell' marked build as failure [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_i386] $ /bin/sh -xe /tmp/hudson5302813901894997177.sh + export 'PATH=3D/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/b= in' + export 'jname=3DFreeBSD_HEAD_i386' + echo 'clean up jail FreeBSD_HEAD_i386' clean up jail FreeBSD_HEAD_i386 + sudo jail -r FreeBSD_HEAD_i386 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::106:1 -alias + sudo umount FreeBSD_HEAD_i386/usr/src + sudo umount FreeBSD_HEAD_i386/dev + sudo rm -fr FreeBSD_HEAD_i386 + true + sudo chflags -R noschg FreeBSD_HEAD_i386 + sudo rm -fr FreeBSD_HEAD_i386 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-current@freebsd.org Wed Jan 20 12:16:31 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2858BA8A498 for ; Wed, 20 Jan 2016 12:16:31 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3E322158F; Wed, 20 Jan 2016 12:16:29 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA01437; Wed, 20 Jan 2016 14:16:27 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1aLrgZ-0005xj-Cw; Wed, 20 Jan 2016 14:16:27 +0200 Subject: Re: environment corrupt; missing value for QT_IM_MO To: Ryan Stone , Andriy Gapon References: <5514E5B0.1030509@rawbw.com> <568B8291.50700@FreeBSD.org> <568B84DC.7080705@FreeBSD.org> Cc: FreeBSD Current From: Andriy Gapon Message-ID: <569F7A4A.7000901@FreeBSD.org> Date: Wed, 20 Jan 2016 14:15:06 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 12:16:31 -0000 On 05/01/2016 21:36, Ryan Stone wrote: > On Tue, Jan 5, 2016 at 3:54 AM, Andriy Gapon wrote: > >> Is there a limit on the environment's size? >> > > If memory serves, this is bounded by ARG_MAX in sys/syslimits.h. The value > is not tunable as far as I know, so if you want to experiment with changing > it you will have to change syslimits.h and recompile your kernel. The total arguments and environment size seems to be much smaller than ARG_MAX of 256K. -- Andriy Gapon From owner-freebsd-current@freebsd.org Wed Jan 20 13:11:32 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6077DA8A14B for ; Wed, 20 Jan 2016 13:11:32 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 449EE12E1 for ; Wed, 20 Jan 2016 13:11:32 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 43E88A8A14A; Wed, 20 Jan 2016 13:11:32 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 29A58A8A149 for ; Wed, 20 Jan 2016 13:11:32 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DB49212E0; Wed, 20 Jan 2016 13:11:30 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id u0KDBOVJ037518; Wed, 20 Jan 2016 13:11:24 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id u0KDBOYb037517; Wed, 20 Jan 2016 05:11:24 -0800 (PST) (envelope-from david) Date: Wed, 20 Jan 2016 05:11:24 -0800 From: David Wolfskill To: current@freebsd.org Subject: head/amd64 @r294411: panic: Assertion tty_gone(tp) failed at /usr/src/sys/sys/ttydevsw.h:191 Message-ID: <20160120131124.GB13446@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="hqsgWuDCGoNNiKsj" Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 13:11:32 -0000 --hqsgWuDCGoNNiKsj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable This is on my build machine (laptop is still building its kernel), so kernel here is GENERIC. Copy/paste from serial console: panic: Assertion tty_gone(tp) failed at /usr/src/sys/sys/ttydevsw.h:191 cpuid =3D 7 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe085de54= 430 vpanic() at vpanic+0x182/frame 0xfffffe085de544b0 kassert_panic() at kassert_panic+0x126/frame 0xfffffe085de54520 tty_drain() at tty_drain+0x80/frame 0xfffffe085de54560 ttydev_leave() at ttydev_leave+0x8d/frame 0xfffffe085de54580 ttydev_close() at ttydev_close+0xaf/frame 0xfffffe085de545a0 devfs_close() at devfs_close+0x223/frame 0xfffffe085de54610 VOP_CLOSE_APV() at VOP_CLOSE_APV+0xf1/frame 0xfffffe085de54640 vn_close() at vn_close+0xcd/frame 0xfffffe085de546b0 vn_closefile() at vn_closefile+0x4a/frame 0xfffffe085de54730 devfs_close_f() at devfs_close_f+0x2c/frame 0xfffffe085de54760 _fdrop() at _fdrop+0x1a/frame 0xfffffe085de54780 closef() at closef+0x1e1/frame 0xfffffe085de54810 fdescfree_fds() at fdescfree_fds+0x9d/frame 0xfffffe085de54850 fdescfree() at fdescfree+0x46c/frame 0xfffffe085de54910 exit1() at exit1+0x4e6/frame 0xfffffe085de54990 ys_sys_exit() at sys_sys_exit+0xd/frame 0xfffffe085de549a0 amd64_syscall() at amd64_syscall+0x2db/frame 0xfffffe085de54ab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe085de54ab0 --- syscall (1, FreeBSD ELF64, sys_sys_exit), rip =3D 0x80090801a, rsp =3D = 0x7fffffffc248, rbp =3D 0x7fffffffc260 --- KDB: enter: panic [ thread pid 305 tid 100103 ] Stopped at kdb_enter+0x3b: movq $0,kdb_why db>=20 /etc/src.conf includes 'WITH_FAST_DEPEND=3D1', and world & kernel were built in-place while the system had been running @r294319, using -DNO_CLEAN. I can probably get a crash dump; if so, I can make it available. I am also willing to poke at the debugger via serial console, given guidance. Peace, david --=20 David H. Wolfskill david@catwhisker.org Those who would murder in the name of God or prophet are blasphemous coward= s. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --hqsgWuDCGoNNiKsj Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJWn4d8XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XII0H/2w4XsWratP1w9IsE4qTW54f hI7ccoHftJa2Xm6aZnSYpB7pzX8AOCoZNyTgla0hK8YvZqoa7ShL9vTyGucNMoqz tnosThUncLd1y5TOjWz8aDHv8ajZLp5xBPePXNZXCeWBOtcjIeEhnHpq66Y/mCSu yG1Jj36Y1TFjAb93Zys1wO55HA6k51y17nui+deZyrATEFR87Kn+2W2AO6PmhVki j7Nsio5pzOHWDy6kc1t3zHzybN3PKkldER/VD1+MRic6pCYOuMlsNXM2KHLul1wG MDjir0kOE6OIQGPg4OESC4fb6XrZAMWwXhwhr+Q+86QkOBi9vrAQCoTrWsE2jnA= =qL5P -----END PGP SIGNATURE----- --hqsgWuDCGoNNiKsj-- From owner-freebsd-current@freebsd.org Wed Jan 20 13:38:15 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 65BAFA8B000 for ; Wed, 20 Jan 2016 13:38:15 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 53EBB1A47 for ; Wed, 20 Jan 2016 13:38:15 +0000 (UTC) (envelope-from hps@selasky.org) Received: by mailman.ysv.freebsd.org (Postfix) id 5362EA8AFFE; Wed, 20 Jan 2016 13:38:15 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 52E42A8AFFD for ; Wed, 20 Jan 2016 13:38:15 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1DB901A45 for ; Wed, 20 Jan 2016 13:38:14 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 0D8061FE024; Wed, 20 Jan 2016 14:38:12 +0100 (CET) Subject: Re: head/amd64 @r294411: panic: Assertion tty_gone(tp) failed at /usr/src/sys/sys/ttydevsw.h:191 To: David Wolfskill , current@freebsd.org References: <20160120131124.GB13446@albert.catwhisker.org> From: Hans Petter Selasky Message-ID: <569F8E4D.6050206@selasky.org> Date: Wed, 20 Jan 2016 14:40:29 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20160120131124.GB13446@albert.catwhisker.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 13:38:15 -0000 On 01/20/16 14:11, David Wolfskill wrote: > This is on my build machine (laptop is still building its kernel), so > kernel here is GENERIC. Copy/paste from serial console: > > panic: Assertion tty_gone(tp) failed at /usr/src/sys/sys/ttydevsw.h:191 > cpuid = 7 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe085de54430 > vpanic() at vpanic+0x182/frame 0xfffffe085de544b0 > kassert_panic() at kassert_panic+0x126/frame 0xfffffe085de54520 > tty_drain() at tty_drain+0x80/frame 0xfffffe085de54560 > ttydev_leave() at ttydev_leave+0x8d/frame 0xfffffe085de54580 > ttydev_close() at ttydev_close+0xaf/frame 0xfffffe085de545a0 > devfs_close() at devfs_close+0x223/frame 0xfffffe085de54610 > VOP_CLOSE_APV() at VOP_CLOSE_APV+0xf1/frame 0xfffffe085de54640 > vn_close() at vn_close+0xcd/frame 0xfffffe085de546b0 > vn_closefile() at vn_closefile+0x4a/frame 0xfffffe085de54730 > devfs_close_f() at devfs_close_f+0x2c/frame 0xfffffe085de54760 > _fdrop() at _fdrop+0x1a/frame 0xfffffe085de54780 > closef() at closef+0x1e1/frame 0xfffffe085de54810 > fdescfree_fds() at fdescfree_fds+0x9d/frame 0xfffffe085de54850 > fdescfree() at fdescfree+0x46c/frame 0xfffffe085de54910 > exit1() at exit1+0x4e6/frame 0xfffffe085de54990 > ys_sys_exit() at sys_sys_exit+0xd/frame 0xfffffe085de549a0 > amd64_syscall() at amd64_syscall+0x2db/frame 0xfffffe085de54ab0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe085de54ab0 > --- syscall (1, FreeBSD ELF64, sys_sys_exit), rip = 0x80090801a, rsp = 0x7fffffffc248, rbp = 0x7fffffffc260 --- > KDB: enter: panic > [ thread pid 305 tid 100103 ] > Stopped at kdb_enter+0x3b: movq $0,kdb_why > db> > > > /etc/src.conf includes 'WITH_FAST_DEPEND=1', and world & kernel were built > in-place while the system had been running @r294319, using -DNO_CLEAN. > > I can probably get a crash dump; if so, I can make it available. I am > also willing to poke at the debugger via serial console, given guidance. > Can you "svn up" ? https://svnweb.freebsd.org/changeset/base/294414 --HPS From owner-freebsd-current@freebsd.org Wed Jan 20 13:57:59 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E887A89A4F for ; Wed, 20 Jan 2016 13:57:59 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 895F9182A for ; Wed, 20 Jan 2016 13:57:59 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 86CD8A89A4E; Wed, 20 Jan 2016 13:57:59 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 86658A89A4D for ; Wed, 20 Jan 2016 13:57:59 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 395481829; Wed, 20 Jan 2016 13:57:58 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id u0KDvvFv038990; Wed, 20 Jan 2016 13:57:57 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id u0KDvv96038989; Wed, 20 Jan 2016 05:57:57 -0800 (PST) (envelope-from david) Date: Wed, 20 Jan 2016 05:57:57 -0800 From: David Wolfskill To: Hans Petter Selasky Cc: current@freebsd.org Subject: Re: head/amd64 @r294411: panic: Assertion tty_gone(tp) failed at /usr/src/sys/sys/ttydevsw.h:191 Message-ID: <20160120135757.GD13446@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Hans Petter Selasky , current@freebsd.org References: <20160120131124.GB13446@albert.catwhisker.org> <569F8E4D.6050206@selasky.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xFHWmGwbilGjB8dh" Content-Disposition: inline In-Reply-To: <569F8E4D.6050206@selasky.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 13:57:59 -0000 --xFHWmGwbilGjB8dh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 20, 2016 at 02:40:29PM +0100, Hans Petter Selasky wrote: > .... > > /etc/src.conf includes 'WITH_FAST_DEPEND=3D1', and world & kernel were = built > > in-place while the system had been running @r294319, using -DNO_CLEAN. > > > > I can probably get a crash dump; if so, I can make it available. I am > > also willing to poke at the debugger via serial console, given guidance. > > >=20 > Can you "svn up" ? >=20 > https://svnweb.freebsd.org/changeset/base/294414 > .... I just hand-applied r294414, then re-built/installed the kernel; no panic: FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1967 r= 294411M/294411:1100095: Wed Jan 20 05:51:33 PST 2016 root@freebeast.cat= whisker.org:/common/S4/obj/usr/src/sys/GENERIC amd64 Peace, david --=20 David H. Wolfskill david@catwhisker.org Those who would murder in the name of God or prophet are blasphemous coward= s. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --xFHWmGwbilGjB8dh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJWn5JlXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XAukIAMm8tKh3ggRDU+MaFefrkivW s1nV3qEsqXDJC3xamPKmlmAkDilQSHAke4GrIgh+G+7imyyNMAPljDqGAFfgs+aB /gGu2G8D3rmOy7b8hL0BxXlMwE7+qrRZOuw20Sim1T4Fv1CPk8pdhE6fmEaB2TJk lPDhBQ9Ouucf0J+CIGHwrZ8WX/ZyeQVFVE/ud9Wn6wCvunNNZj5yYcRQzyslyYYD D0r37649XAuyIDdZZrzzz2CSef2IGj2c1/V+fExQqUtGe+++X0EDwfti1JYUqSlu O7Be+9t3/FntSZXSk4lg0GopKfAXvtTHT9IX9qnKhYIwydwc1U0o3joGpd/R2+k= =fpWD -----END PGP SIGNATURE----- --xFHWmGwbilGjB8dh-- From owner-freebsd-current@freebsd.org Wed Jan 20 16:38:00 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A977FA8AD04 for ; Wed, 20 Jan 2016 16:38:00 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DCFC01D70 for ; Wed, 20 Jan 2016 16:37:59 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA05937 for ; Wed, 20 Jan 2016 18:37:50 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1aLvlW-0006HX-Gz for freebsd-current@FreeBSD.org; Wed, 20 Jan 2016 18:37:50 +0200 Subject: Re: environment corrupt; missing value for QT_IM_MO To: FreeBSD Current References: <5514E5B0.1030509@rawbw.com> <568B8291.50700@FreeBSD.org> <568B84DC.7080705@FreeBSD.org> <569E3713.1060601@FreeBSD.org> From: Andriy Gapon X-Enigmail-Draft-Status: N1110 Message-ID: <569FB7A5.4070106@FreeBSD.org> Date: Wed, 20 Jan 2016 18:36:53 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <569E3713.1060601@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 16:38:00 -0000 On 19/01/2016 15:16, Andriy Gapon wrote: > So, it's "QT_IM_MODULE=xim" with 4 bytes (corresponding to "DULE") replaced with > zeroes. This is 100% reproducible in my current environment, so it could be a > deterministic write to a wrong offset. Okay, I've debugged and fixed the problem, but I do not have any exciting discoveries. just another lesson that problems with an environment (in the general sense of that word) could manifest themselves in very strange ways. In the following debugging session it's LSCOLORS variable that was corrupted: (gdb) p environ[81] $3 = 0x7fffffffef32 "LSCOLORS" (gdb) p environ[82] $4 = 0x0 (gdb) x/s 0x7fffffffef32 0x7fffffffef32: "LSCOLORS" (gdb) x/s 0x7fffffffef3a 0x7fffffffef3a: "" (gdb) x/s 0x7fffffffef3b 0x7fffffffef3b: "" (gdb) x/s 0x7fffffffef3c 0x7fffffffef3c: "" (gdb) x/s 0x7fffffffef3d 0x7fffffffef3d: "" (gdb) x/s 0x7fffffffef3e 0x7fffffffef3e: "xcxdxbxegedabagacad" (gdb) watch -l *(int *)0x7fffffffef3a Hardware watchpoint 2: -location *(int *)0x7fffffffef3a Old value = 1719158077 New value = 0 OPENSSL_ia32_cpuid () at /usr/src/secure/lib/libcrypto/amd64/x86_64cpuid.S:45 45 movl %eax,%r11d (gdb) p/x 1719158077 $7 = 0x6678453d (gdb) bt #0 OPENSSL_ia32_cpuid () at /usr/src/secure/lib/libcrypto/amd64/x86_64cpuid.S:45 #1 0x00000008160e5b1d in OPENSSL_cpuid_setup () at /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/cryptlib.c:699 #2 0x0000000815fe7dde in _init () from /lib/libcrypto.so.7 #3 0x00007fffffffdae0 in ?? () #4 0x00000008006049c8 in objlist_call_init (list=, lockstate=0x7fffffffdb68) at /usr/src/libexec/rtld-elf/rtld.c:2438 #5 0x000000080060407f in _rtld (sp=, exit_proc=0x7fffffffe130, objp=0x7fffffffe138) at /usr/src/libexec/rtld-elf/rtld.c:665 #6 0x0000000800602439 in .rtld_start () at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:39 (kgdb) list 40 movq %rbx,%r8 41 42 xorl %eax,%eax 43 movl %eax,8(%rdi) 44 cpuid 45 movl %eax,%r11d 46 47 xorl %eax,%eax 48 cmpl $1970169159,%ebx 49 setne %al (kgdb) p/x $rdi $11 = 0x7fffffffef32 It did not make sense to me that libcrypto would have such a bug and then I noticed that libcrypto.so.7 was involved. The current version is libcrypto.so.8, but I have forgotten to run make delete-old-libs, so I had both installed. And it turned out that libreoffice executable was linked to both because one of libraries, libtspi.so.1 from trousers-tddl-0.3.10_7, hadn't been updated since libcrypto.so.8 was introduced. -- Andriy Gapon From owner-freebsd-current@freebsd.org Wed Jan 20 19:40:37 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4747BA8A82C; Wed, 20 Jan 2016 19:40:37 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 38A0E1FF8; Wed, 20 Jan 2016 19:40:37 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id C74D81289; Wed, 20 Jan 2016 10:22:59 +0000 (UTC) Date: Wed, 20 Jan 2016 10:22:55 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: kib@FreeBSD.org, des@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <1003201386.21.1453285378942.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <615234885.17.1453277492788.JavaMail.jenkins@jenkins-9.freebsd.org> References: <615234885.17.1453277492788.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #2149 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 19:40:37 -0000 FreeBSD_HEAD_i386 - Build #2149 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2149/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2149/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2149/console Change summaries: 294407 by des: MFV (r285035): fix props (no content changes) 294373 by kib: Do not call callbacks for dl_iterate_phdr(3) with the rtld bind and phdr locks locked. This allows to call rtld services from the callback, which is only reasonable for dlopen(path, RTLD_NOLOAD) to test existence of the library in the image, and for dlsym(). The later might still be not quite safe, due to the lazy resolution of filters. To allow dropping the locks around iteration in dl_iterate_phdr(3), we insert markers to track current position between relocks. The global objects list is converted to tailq and all iterators skip markers, globallist_next() and globallist_curr() helpers are added. Reported and tested by: davide Reviewed by: kan Sponsored by: The FreeBSD Foundation MFC after: 3 weeks From owner-freebsd-current@freebsd.org Wed Jan 20 23:15:15 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 938DFA8B387 for ; Wed, 20 Jan 2016 23:15:15 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 63F491595; Wed, 20 Jan 2016 23:15:15 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id u0KNF687077387; Wed, 20 Jan 2016 15:15:10 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201601202315.u0KNF687077387@gw.catspoiler.org> Date: Wed, 20 Jan 2016 15:15:06 -0800 (PST) From: Don Lewis Subject: Re: panic: sbuf_vprintf called with a NULL sbuf pointer To: jhb@freebsd.org cc: freebsd-current@freebsd.org In-Reply-To: <2246380.LId0aa2Jcy@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 23:15:15 -0000 On 8 Dec, John Baldwin wrote: > On Tuesday, December 08, 2015 11:39:56 AM Don Lewis wrote: >> On 8 Dec, John Baldwin wrote: >> > On Monday, December 07, 2015 10:10:51 PM Don Lewis wrote: >> >> On 2 Dec, John Baldwin wrote: >> >> > On Wednesday, December 02, 2015 01:25:56 PM Don Lewis wrote: >> >> >> > If you want to look at this further, try going to frame 16 and dissassembling the >> >> >> > instructions before the call to see if you can spot which register the first >> >> >> > parameter (saved in %rdi IIRC) comes from. >> >> >> >> >> >> Dump of assembler code for function sbuf_printf: >> >> >> 0xffffffff80a673e0 <+0>: push %rbp >> >> >> 0xffffffff80a673e1 <+1>: mov %rsp,%rbp >> >> >> 0xffffffff80a673e4 <+4>: push %r14 >> >> >> 0xffffffff80a673e6 <+6>: push %rbx >> >> >> 0xffffffff80a673e7 <+7>: sub $0x50,%rsp >> >> >> 0xffffffff80a673eb <+11>: mov %rsi,%r14 >> >> >> 0xffffffff80a673ee <+14>: mov %rdi,%rbx >> >> >> 0xffffffff80a673f1 <+17>: mov %r9,-0x38(%rbp) >> >> >> 0xffffffff80a673f5 <+21>: mov %r8,-0x40(%rbp) >> >> >> 0xffffffff80a673f9 <+25>: mov %rcx,-0x48(%rbp) >> >> >> 0xffffffff80a673fd <+29>: mov %rdx,-0x50(%rbp) >> >> >> 0xffffffff80a67401 <+33>: lea -0x60(%rbp),%rax >> >> >> 0xffffffff80a67405 <+37>: mov %rax,-0x20(%rbp) >> >> >> 0xffffffff80a67409 <+41>: lea 0x10(%rbp),%rax >> >> >> 0xffffffff80a6740d <+45>: mov %rax,-0x28(%rbp) >> >> >> 0xffffffff80a67411 <+49>: movl $0x30,-0x2c(%rbp) >> >> >> 0xffffffff80a67418 <+56>: movl $0x10,-0x30(%rbp) >> >> >> 0xffffffff80a6741f <+63>: mov $0xffffffff8137bdf8,%rdi >> >> >> 0xffffffff80a67426 <+70>: mov %rbx,%rsi >> >> >> 0xffffffff80a67429 <+73>: callq 0xffffffff80a66c00 <_assert_sbuf_integrity> >> >> >> >> >> >> >> >> >> 0xffffffff80a237b9 <+825>: jmpq 0xffffffff80a236fd >> >> >> 0xffffffff80a237be <+830>: mov $0xffffffff80fd8ad3,%rsi >> >> >> 0xffffffff80a237c5 <+837>: xor %eax,%eax >> >> >> 0xffffffff80a237c7 <+839>: mov %r12,%rdi >> >> >> 0xffffffff80a237ca <+842>: mov -0x228(%rbp),%rdx >> >> >> 0xffffffff80a237d1 <+849>: callq 0xffffffff80a673e0 >> >> >> => 0xffffffff80a237d6 <+854>: inc %r14d >> >> >> 0xffffffff80a237d9 <+857>: jmpq 0xffffffff80a236fd >> >> > >> >> > So maybe try 'p $r12' in the corefile_open() frame. >> >> >> >> #17 0xffffffff80a237d6 in corefile_open (compress=0, comm=, >> >> uid=, pid=, td=, >> >> vpp=, namep=) >> >> at /usr/src/sys/kern/kern_sig.c:3188 >> >> 3188 sbuf_printf(&sb, "%s", comm); >> >> (kgdb) p $r12 >> >> $1 = 0 >> > >> > So it's definitely zero. :( The next step is probably to disassemble the >> > corefile_open function (ugh) and walk backwards to find where %r12 is read >> > from. It might be from a local variable on the stack, so then you would >> > want to examine that memory in the stack and the surrounding memory to see >> > if there is memory corruption and perhaps if there is anything recognizable >> > about it (e.g. if the corruption contains some sort of data you recognize, >> > or if the corruption is bounded by a certain length, etc.). It's a bit of >> > a shot in the dark though. >> > >> > Is this reproducible? >> >> No it's not. The only time it happened was when there was a swap >> timeout, probably because of a lengthy deep recovery on one of the >> mirrored swap devices. >> >> The code in question is: >> struct sbuf sb; >> [snip] >> (void)sbuf_new(&sb, name, MAXPATHLEN, SBUF_FIXEDLEN); >> [snip] >> for (i = 0; format[i] != '\0'; i++) { >> switch (format[i]) { >> case '%': /* Format character */ >> i++; >> switch (format[i]) { >> [snip] >> case 'N': /* process name */ >> sbuf_printf(&sb, "%s", comm); >> break; >> >> >> &sb is used in a bunch of places, so the compiler probably computes its >> value once by adding the proper offset to the stack pointer and stashing >> the result in a register. Since kern.corefile is "%N.core", the failure >> is happening on the first interation of the loop, so there isn't much >> opportunity for things to get corrupted. Also, the control flow in this >> function only depends on the format, so there shouldn't be anything >> special about a swap timeout vs. a segfault generated core. > > Yes, r12 is call-safe (IIRC), so I expect it only computes it once as well, > but I've sometimes seen the compiler spill local vars onto the stack due to > register pressure. That said, I think it is unlikely it would have to spill > &sb during the early part of the function. :( I had some more time to look at this. It's a bit messy because corefile_open() and coredump() both get inlined into sig_exit(). Here's the section of code from the malloc() call and sbuf_new() to the failing sbuf_printf() call: 0xffffffff80a23685 <+517>: callq 0xffffffff80a00680 0xffffffff80a2368a <+522>: mov %rax,-0x238(%rbp) 0xffffffff80a23691 <+529>: lea -0x138(%rbp),%r12 0xffffffff80a23698 <+536>: mov $0x400,%edx 0xffffffff80a2369d <+541>: xor %ecx,%ecx 0xffffffff80a2369f <+543>: mov %r12,%rdi 0xffffffff80a236a2 <+546>: mov %rax,%rsi 0xffffffff80a236a5 <+549>: callq 0xffffffff80a66830 0xffffffff80a236aa <+554>: mov $0xffffffff81ccd6f0,%rdi 0xffffffff80a236b1 <+561>: xor %esi,%esi 0xffffffff80a236b3 <+563>: mov $0xffffffff813757c7,%rdx 0xffffffff80a236ba <+570>: mov $0xc5d,%ecx 0xffffffff80a236bf <+575>: callq 0xffffffff80a27d00 <_sx_slock> 0xffffffff80a236c4 <+580>: mov $0xffffffff,%ebx 0xffffffff80a236c9 <+585>: xor %r14d,%r14d 0xffffffff80a236cc <+588>: xor %r15d,%r15d 0xffffffff80a236cf <+591>: jmp 0xffffffff80a236fd 0xffffffff80a236d1 <+593>: data16 data16 data16 data16 data16 nopw %cs:0x0( %rax,%rax,1) 0xffffffff80a236e0 <+608>: mov $0x3,%edi 0xffffffff80a236e5 <+613>: mov $0xffffffff81375c89,%rsi 0xffffffff80a236ec <+620>: mov $0xffffffff8186d900,%rcx 0xffffffff80a236f3 <+627>: xor %eax,%eax 0xffffffff80a236f3 <+627>: xor %eax,%eax 0xffffffff80a236f5 <+629>: callq 0xffffffff80a61a20 0xffffffff80a236fa <+634>: inc %r14d 0xffffffff80a236fd <+637>: movslq %r14d,%rax 0xffffffff80a23700 <+640>: movsbl -0x7e792700(%rax),%esi 0xffffffff80a23707 <+647>: cmp $0x25,%esi 0xffffffff80a2370a <+650>: jne 0xffffffff80a2380f 0xffffffff80a23710 <+656>: inc %r14d 0xffffffff80a23713 <+659>: movslq %r14d,%rax 0xffffffff80a23716 <+662>: movsbl -0x7e792700(%rax),%edx 0xffffffff80a2371d <+669>: lea -0x48(%rdx),%eax 0xffffffff80a23720 <+672>: cmp $0x8,%eax 0xffffffff80a23723 <+675>: jbe 0xffffffff80a23740 0xffffffff80a23725 <+677>: cmp $0x55,%edx 0xffffffff80a23728 <+680>: je 0xffffffff80a237ef 0xffffffff80a2372e <+686>: cmp $0x25,%edx 0xffffffff80a23731 <+689>: jne 0xffffffff80a236e0 0xffffffff80a23733 <+691>: mov $0x25,%esi 0xffffffff80a23738 <+696>: jmpq 0xffffffff80a23814 0xffffffff80a2373d <+701>: nopl (%rax) 0xffffffff80a23740 <+704>: jmpq *-0x7ec8a8b8(,%rax,8) 0xffffffff80a23747 <+711>: test %r15,%r15 0xffffffff80a2374a <+714>: jne 0xffffffff80a23765 0xffffffff80a2374c <+716>: mov $0x100,%edi 0xffffffff80a23751 <+721>: mov $0xffffffff818668a0,%rsi 0xffffffff80a23758 <+728>: mov $0x2,%edx 0xffffffff80a2375d <+733>: callq 0xffffffff80a00680 0xffffffff80a23762 <+738>: mov %rax,%r15 0xffffffff80a23765 <+741>: mov -0x220(%rbp),%rax 0xffffffff80a2376c <+748>: mov 0x140(%rax),%rdi 0xffffffff80a23773 <+755>: mov $0x100,%edx 0xffffffff80a23778 <+760>: mov %r15,%rsi 0xffffffff80a2377b <+763>: callq 0xffffffff809f0ef0 0xffffffff80a23780 <+768>: mov $0xffffffff80fd8ad3,%rsi 0xffffffff80a23787 <+775>: xor %eax,%eax 0xffffffff80a23789 <+777>: mov %r12,%rdi 0xffffffff80a2378c <+780>: mov %r15,%rdx 0xffffffff80a2378f <+783>: jmp 0xffffffff80a237d1 0xffffffff80a23791 <+785>: mov $0xffffffff81373ba2,%rsi 0xffffffff80a23798 <+792>: xor %eax,%eax 0xffffffff80a2379a <+794>: mov %r12,%rdi 0xffffffff80a2379d <+797>: callq 0xffffffff80a673e0 0xffffffff80a237a2 <+802>: mov %r12,%rdi 0xffffffff80a237a5 <+805>: callq 0xffffffff80a67760 0xffffffff80a237aa <+810>: mov $0xfffff103,%ecx 0xffffffff80a237af <+815>: lea 0xefc(%rcx,%rax,1),%ebx 0xffffffff80a237b6 <+822>: inc %r14d 0xffffffff80a237b9 <+825>: jmpq 0xffffffff80a236fd 0xffffffff80a237be <+830>: mov $0xffffffff80fd8ad3,%rsi 0xffffffff80a237c5 <+837>: xor %eax,%eax 0xffffffff80a237c7 <+839>: mov %r12,%rdi 0xffffffff80a237ca <+842>: mov -0x228(%rbp),%rdx 0xffffffff80a237d1 <+849>: callq 0xffffffff80a673e0 => 0xffffffff80a237d6 <+854>: inc %r14d 0xffffffff80a237d9 <+857>: jmpq 0xffffffff80a236fd 0xffffffff80a237de <+862>: mov $0xffffffff81361469,%rsi Basically it's: lea -0x138(%rbp),%r12 [ snip ] mov %r12,%rdi callq sbuf_printf From owner-freebsd-current@freebsd.org Thu Jan 21 01:15:36 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5E82AA89E63 for ; Thu, 21 Jan 2016 01:15:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1EA641F2A; Thu, 21 Jan 2016 01:15:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B77DEB94B; Wed, 20 Jan 2016 20:15:34 -0500 (EST) From: John Baldwin To: Don Lewis Cc: freebsd-current@freebsd.org Subject: Re: panic: sbuf_vprintf called with a NULL sbuf pointer Date: Wed, 20 Jan 2016 17:14:56 -0800 Message-ID: <2064398.31Gqv7eiJr@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <201601202315.u0KNF687077387@gw.catspoiler.org> References: <201601202315.u0KNF687077387@gw.catspoiler.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 20 Jan 2016 20:15:34 -0500 (EST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 01:15:36 -0000 On Wednesday, January 20, 2016 03:15:06 PM Don Lewis wrote: > On 8 Dec, John Baldwin wrote: > > On Tuesday, December 08, 2015 11:39:56 AM Don Lewis wrote: > >> On 8 Dec, John Baldwin wrote: > >> > On Monday, December 07, 2015 10:10:51 PM Don Lewis wrote: > >> >> On 2 Dec, John Baldwin wrote: > >> >> > On Wednesday, December 02, 2015 01:25:56 PM Don Lewis wrote: > >> >> >> > If you want to look at this further, try going to frame 16 and dissassembling the > >> >> >> > instructions before the call to see if you can spot which register the first > >> >> >> > parameter (saved in %rdi IIRC) comes from. > >> >> >> > >> >> >> Dump of assembler code for function sbuf_printf: > >> >> >> 0xffffffff80a673e0 <+0>: push %rbp > >> >> >> 0xffffffff80a673e1 <+1>: mov %rsp,%rbp > >> >> >> 0xffffffff80a673e4 <+4>: push %r14 > >> >> >> 0xffffffff80a673e6 <+6>: push %rbx > >> >> >> 0xffffffff80a673e7 <+7>: sub $0x50,%rsp > >> >> >> 0xffffffff80a673eb <+11>: mov %rsi,%r14 > >> >> >> 0xffffffff80a673ee <+14>: mov %rdi,%rbx > >> >> >> 0xffffffff80a673f1 <+17>: mov %r9,-0x38(%rbp) > >> >> >> 0xffffffff80a673f5 <+21>: mov %r8,-0x40(%rbp) > >> >> >> 0xffffffff80a673f9 <+25>: mov %rcx,-0x48(%rbp) > >> >> >> 0xffffffff80a673fd <+29>: mov %rdx,-0x50(%rbp) > >> >> >> 0xffffffff80a67401 <+33>: lea -0x60(%rbp),%rax > >> >> >> 0xffffffff80a67405 <+37>: mov %rax,-0x20(%rbp) > >> >> >> 0xffffffff80a67409 <+41>: lea 0x10(%rbp),%rax > >> >> >> 0xffffffff80a6740d <+45>: mov %rax,-0x28(%rbp) > >> >> >> 0xffffffff80a67411 <+49>: movl $0x30,-0x2c(%rbp) > >> >> >> 0xffffffff80a67418 <+56>: movl $0x10,-0x30(%rbp) > >> >> >> 0xffffffff80a6741f <+63>: mov $0xffffffff8137bdf8,%rdi > >> >> >> 0xffffffff80a67426 <+70>: mov %rbx,%rsi > >> >> >> 0xffffffff80a67429 <+73>: callq 0xffffffff80a66c00 <_assert_sbuf_integrity> > >> >> >> > >> >> >> > >> >> >> 0xffffffff80a237b9 <+825>: jmpq 0xffffffff80a236fd > >> >> >> 0xffffffff80a237be <+830>: mov $0xffffffff80fd8ad3,%rsi > >> >> >> 0xffffffff80a237c5 <+837>: xor %eax,%eax > >> >> >> 0xffffffff80a237c7 <+839>: mov %r12,%rdi > >> >> >> 0xffffffff80a237ca <+842>: mov -0x228(%rbp),%rdx > >> >> >> 0xffffffff80a237d1 <+849>: callq 0xffffffff80a673e0 > >> >> >> => 0xffffffff80a237d6 <+854>: inc %r14d > >> >> >> 0xffffffff80a237d9 <+857>: jmpq 0xffffffff80a236fd > >> >> > > >> >> > So maybe try 'p $r12' in the corefile_open() frame. > >> >> > >> >> #17 0xffffffff80a237d6 in corefile_open (compress=0, comm=, > >> >> uid=, pid=, td=, > >> >> vpp=, namep=) > >> >> at /usr/src/sys/kern/kern_sig.c:3188 > >> >> 3188 sbuf_printf(&sb, "%s", comm); > >> >> (kgdb) p $r12 > >> >> $1 = 0 > >> > > >> > So it's definitely zero. :( The next step is probably to disassemble the > >> > corefile_open function (ugh) and walk backwards to find where %r12 is read > >> > from. It might be from a local variable on the stack, so then you would > >> > want to examine that memory in the stack and the surrounding memory to see > >> > if there is memory corruption and perhaps if there is anything recognizable > >> > about it (e.g. if the corruption contains some sort of data you recognize, > >> > or if the corruption is bounded by a certain length, etc.). It's a bit of > >> > a shot in the dark though. > >> > > >> > Is this reproducible? > >> > >> No it's not. The only time it happened was when there was a swap > >> timeout, probably because of a lengthy deep recovery on one of the > >> mirrored swap devices. > >> > >> The code in question is: > >> struct sbuf sb; > >> [snip] > >> (void)sbuf_new(&sb, name, MAXPATHLEN, SBUF_FIXEDLEN); > >> [snip] > >> for (i = 0; format[i] != '\0'; i++) { > >> switch (format[i]) { > >> case '%': /* Format character */ > >> i++; > >> switch (format[i]) { > >> [snip] > >> case 'N': /* process name */ > >> sbuf_printf(&sb, "%s", comm); > >> break; > >> > >> > >> &sb is used in a bunch of places, so the compiler probably computes its > >> value once by adding the proper offset to the stack pointer and stashing > >> the result in a register. Since kern.corefile is "%N.core", the failure > >> is happening on the first interation of the loop, so there isn't much > >> opportunity for things to get corrupted. Also, the control flow in this > >> function only depends on the format, so there shouldn't be anything > >> special about a swap timeout vs. a segfault generated core. > > > > Yes, r12 is call-safe (IIRC), so I expect it only computes it once as well, > > but I've sometimes seen the compiler spill local vars onto the stack due to > > register pressure. That said, I think it is unlikely it would have to spill > > &sb during the early part of the function. :( > > I had some more time to look at this. It's a bit messy because > corefile_open() and coredump() both get inlined into sig_exit(). Here's > the section of code from the malloc() call and sbuf_new() to the failing > sbuf_printf() call: > > 0xffffffff80a23685 <+517>: callq 0xffffffff80a00680 > 0xffffffff80a2368a <+522>: mov %rax,-0x238(%rbp) > 0xffffffff80a23691 <+529>: lea -0x138(%rbp),%r12 > .... > 0xffffffff80a237b9 <+825>: jmpq 0xffffffff80a236fd > 0xffffffff80a237be <+830>: mov $0xffffffff80fd8ad3,%rsi > 0xffffffff80a237c5 <+837>: xor %eax,%eax > 0xffffffff80a237c7 <+839>: mov %r12,%rdi > 0xffffffff80a237ca <+842>: mov -0x228(%rbp),%rdx > 0xffffffff80a237d1 <+849>: callq 0xffffffff80a673e0 > => 0xffffffff80a237d6 <+854>: inc %r14d > 0xffffffff80a237d9 <+857>: jmpq 0xffffffff80a236fd > 0xffffffff80a237de <+862>: mov $0xffffffff81361469,%rsi > > Basically it's: > lea -0x138(%rbp),%r12 > [ snip ] > mov %r12,%rdi > callq sbuf_printf Yeah, at this point I can only think of bizarre-o things like a trap clobbering %r12 in the saved trapframe or the like. I can't imagine why that would happen though. If we had a bug that clobbered saved registers in the trapframe you would expect it to happen far more often. OTOH, if some code had a stale pointer that was later reused by a kthread's stack and the thread was interrupted (e.g. by a device interrupt) while in this routine, _and_ the stale pointer was indirected and trashed the saved %r12, then that would explain this. I just feel like I have better odds of seeing a unicorn in my driveway tonight. :-/ -- John Baldwin From owner-freebsd-current@freebsd.org Thu Jan 21 02:23:39 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 54375A8BB84; Thu, 21 Jan 2016 02:23:39 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 48A6D1A9C; Thu, 21 Jan 2016 02:23:39 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 85789DE; Thu, 21 Jan 2016 02:23:39 +0000 (UTC) Date: Thu, 21 Jan 2016 02:23:38 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <760605379.3.1453343019513.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #2152 - Successful MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 02:23:39 -0000 FreeBSD_HEAD_i386 - Build #2152 - Successful: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2152/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2152/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2152/console Change summaries: No changes From owner-freebsd-current@freebsd.org Thu Jan 21 09:50:08 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EF16DA898CD for ; Thu, 21 Jan 2016 09:50:08 +0000 (UTC) (envelope-from cmt@burggraben.net) Received: from smtp.burggraben.net (smtp.burggraben.net [IPv6:2a01:4f8:140:50a2::3:1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "ns.exwg.net", Issuer "Christoph Moench-Tegeder" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B5A3B154E for ; Thu, 21 Jan 2016 09:50:08 +0000 (UTC) (envelope-from cmt@burggraben.net) Received: from localhost (localhost [127.0.0.1]) by smtp.burggraben.net (Postfix) with ESMTP id 8310F6002EB for ; Thu, 21 Jan 2016 10:50:06 +0100 (CET) X-Spam-Scanned: by amavisd-new at exwg.net Received: from smtp.burggraben.net ([127.0.0.1]) by localhost (ns.burggraben.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-+DyUjs9PTJ for ; Thu, 21 Jan 2016 10:50:06 +0100 (CET) Received: from elch.exwg.net (dslb-088-066-000-049.088.066.pools.vodafone-ip.de [88.66.0.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "elch.exwg.net", Issuer "Christoph Moench-Tegeder" (verified OK)) by smtp.burggraben.net (Postfix) with ESMTPS for ; Thu, 21 Jan 2016 10:50:06 +0100 (CET) Received: by elch.exwg.net (Postfix, from userid 1000) id C5E933021C; Thu, 21 Jan 2016 10:50:05 +0100 (CET) Date: Thu, 21 Jan 2016 10:50:05 +0100 From: Christoph Moench-Tegeder To: freebsd-current@freebsd.org Subject: Re: environment corrupt; missing value for QT_IM_MO Message-ID: <20160121095005.GA2029@elch.exwg.net> References: <5514E5B0.1030509@rawbw.com> <568B8291.50700@FreeBSD.org> <568B84DC.7080705@FreeBSD.org> <569E3713.1060601@FreeBSD.org> <569FB7A5.4070106@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <569FB7A5.4070106@FreeBSD.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 09:50:09 -0000 ## Andriy Gapon (avg@FreeBSD.org): > It did not make sense to me that libcrypto would have such a bug and then I > noticed that libcrypto.so.7 was involved. Now that you mention libcrypto... There was a similar (the same?) issue about a year ago in VirtualBox, which ended up being linked against base system (libcrypto.so.7) and ports (libcrypto.so.8) openssl. At the risk of citing myself: https://lists.freebsd.org/pipermail/freebsd-emulation/2015-March/012390.html Sorry, I didn't spot this thread earlier... Regards, Christoph -- Spare Space From owner-freebsd-current@freebsd.org Thu Jan 21 16:02:50 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 31605A8B46A for ; Thu, 21 Jan 2016 16:02:50 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F182E134C; Thu, 21 Jan 2016 16:02:49 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io0-x236.google.com with SMTP id 77so58559551ioc.2; Thu, 21 Jan 2016 08:02:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=doc20XLQdzngXkRzCi4LWZ4WU7Y3HOH5qz4BlqK3vLs=; b=id/4iP50bRFjRQr1D105gr1U9XIA4WK9npVmm6N7coTbmGQR3LzeNYVUsulgULzL4s 6bY7bsojGmsKNsLsEJcYcUFF7kMPuAMiT35dtXJtn+1NAEa1aCxueKBTnvAlns/PJdea 9+XGuqNnECOY9fTppVE5TlShZDhrk6pF0SS0ZjwSoI4GPKFlec8qbEV3zaK4yGaSjSI2 RYbdhbQta9DTiCapVRUwz25T2XuaQdYuQQZLIg8VGJvcyJ69PjSmFxFrI9O/p7qINaVB 6p2NpqgxPC6zryqUAA1TFIG+t3grV3/idPiQyRy+rZTT0d5ACF1GoS8XCdKC7RqeCkCi lLlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=doc20XLQdzngXkRzCi4LWZ4WU7Y3HOH5qz4BlqK3vLs=; b=QRyui1FZY+ZTTmjiIRS0tcWWyvf/kVpv16WCv7hIorPXn4SndBYqOhbZEG6r5Ttx24 fe+O98CZzm/OT1X3j/gXrT5JPdtHbtq1orGgtvmCafC5EpSfsMMoxlBDykbmLbJB8Qek U/QPkFx0Ufi073HWJdcz4FLmrU4OzCOpAKKnDmrVbhnR6nhIOWOUSGQOngfdglMPQ1MT vQI/HTZu5O9j2KsrjTqxQB38nlhMqKI+vcK4bvpVb3Je5j1h5Ixr3wrUzEbxl1aPyCRo 3HXtgD4UGGIUsV3EZKy3Q7gzUyZB0nQy/yLdwnkiHV5PDCeMnQyJPZEtfFvrVwTueHKl P7ZQ== X-Gm-Message-State: AG10YOQbSEhAlPp3vV6/ukY6HHqIA9pAdz3WHgQiXwnm5z6Qc+DkpOaXoOgbcL6oeizz+Y4+a29e/LZPdWZ+9w== X-Received: by 10.107.62.5 with SMTP id l5mr14092075ioa.180.1453392169482; Thu, 21 Jan 2016 08:02:49 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.39.66 with HTTP; Thu, 21 Jan 2016 08:02:29 -0800 (PST) In-Reply-To: <913B1E7A-5192-430F-ABAF-576DFCFF98E6@FreeBSD.org> References: <531F42CD.8020307@citrix.com> <913B1E7A-5192-430F-ABAF-576DFCFF98E6@FreeBSD.org> From: Ed Maste Date: Thu, 21 Jan 2016 11:02:30 -0500 X-Google-Sender-Auth: N-0cbH7xbDxaFyCJtmtHtm9ALEI Message-ID: Subject: Re: Too low PTHREAD_STACK_MIN value? To: David Chisnall Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , FreeBSD Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 16:02:50 -0000 On 11 March 2014 at 20:38, David Chisnall wrote: > On 12 Mar 2014, at 02:07, Roger Pau Monn=C3=A9 wro= te: > >> I've found out that the value PTHREAD_STACK_MIN is currently set (2048 >> bytes) seems to be way too low > > This looks like an error in your code. The spec says: > >> PTHREAD_STACK_MIN >> Minimum size in bytes of thread stack storage. >> Minimum Acceptable Value: 0 > > It is meant to be the minimum value that the system can give for a thread= stack. The purpose of this constant is for languages that do their own st= ack management bit some chain of activation records of segmented stacks, bu= t want to use pthreads for threading, so that they can allocate the smalles= t possible stack that allows pthread cleanup to work. > > Using it from C code is very likely to be a mistake. I found that lang/polyml uses PTHREAD_STACK_MIN for a trivial signal handler thread it creates[1]. They found it was too small and implemented a 4K minimum bound to fix polyml on FreeBSD[2]. Even if this isn't really the intended use of PTHREAD_STACK_MIN it suggests the 2K x86 minimum may indeed be too low. I ran into this while trying LLVM's libunwind, which requires more stack space. 2K is certainly too low with LLVM libunwind. Is it reasonable to just increase it to say 8K? [1] https://github.com/polyml/polyml/blob/6c8add163fc39271da1056e43387a3d33= ebd62c6/libpolyml/sighandler.cpp#L527 [2] https://github.com/polyml/polyml/commit/c59360ba74ac99bd9e3d342af214ced= 39cf0568b From owner-freebsd-current@freebsd.org Thu Jan 21 16:20:13 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3ABC7A8BB2D for ; Thu, 21 Jan 2016 16:20:13 +0000 (UTC) (envelope-from mathieu.prevot@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 1F4731EBD for ; Thu, 21 Jan 2016 16:20:13 +0000 (UTC) (envelope-from mathieu.prevot@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 1B59BA8BB2B; Thu, 21 Jan 2016 16:20:13 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1AD8DA8BB29; Thu, 21 Jan 2016 16:20:13 +0000 (UTC) (envelope-from mathieu.prevot@gmail.com) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::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 9A6B61EBA; Thu, 21 Jan 2016 16:20:12 +0000 (UTC) (envelope-from mathieu.prevot@gmail.com) Received: by mail-lf0-x22d.google.com with SMTP id c192so29907966lfe.2; Thu, 21 Jan 2016 08:20:12 -0800 (PST) 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:content-type; bh=0u3tUkc6l4c4dzE9qbTbke+OZxXkklAyQ0828s8SXaU=; b=Z0ovXqNp8kSyUQtxRE3eEaItV+KC9vlP+xGN7WnSFc23sR0loGw/QUvEgAKYI0zg8n CusZeCJNoGp1v5SeKPlu6ogKWBv1ycflxk9uukds2h/cXz9vD+Qq7PZWSXGj0HrJU8iB XMO+WfVSj3NRFZ3xVSsLHQpwy3nhBco3fN4e4NHthuz1AvTNIvjOXzqyF0UZrVol2D5M PiJoKUNTP1Jt27wBW7XRPrzDsjmgHvbut8evUNLUKy1YJ+DS5oxeWUivqlNm3r6tOVgo iJ6qqLruOxQaCbLQHSmMkTzRpdH6x7z6DOQUgNSVEKCOWcZhWN/0DTuQrmdn9P5NNcb1 Q3IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:content-type; bh=0u3tUkc6l4c4dzE9qbTbke+OZxXkklAyQ0828s8SXaU=; b=Uy0rbKX3sq/gwnfH4i2F3lcmNaP87PYXXCcBM4h9W4jcBL5RL7Um96iRHyCpH9fuXo 62YrSiD4OL3BSXhOlOsXTjRX/S+tMQKsfntQJv9InJ0hOC2Y4oSmGh6Hm4FTDqnkK1Qo W6OIS3tT2lehWfaqb4bn3Qwmk+/XioA+BvjVP6OJAHJzqqsZHA3BKQUlnN0BPHEw+GeA ndNneSwO/QIXTOC7zPQtRsjda+Q4ZwrAZwiCgINF/0glh10xWOb86oFaFFtd4/nBU8/y sDyHXnBgCLU/pLJJaDQTuF0IbEW8gzkJekItpqmV1HCfl5aRbBnauWNTl3bcJfje15+U 4LSQ== X-Gm-Message-State: ALoCoQlYOno0oeWdnsUO+xxG/gRFWb3a+62/Vy4WoeJHf0Q/HgVyJMt+swZEPqqbcVURBmgsv83rTGDiVvI6+tchjueP+FYSQg== X-Received: by 10.25.81.133 with SMTP id f127mr13873156lfb.141.1453393210516; Thu, 21 Jan 2016 08:20:10 -0800 (PST) MIME-Version: 1.0 Sender: mathieu.prevot@gmail.com Received: by 10.25.89.75 with HTTP; Thu, 21 Jan 2016 08:19:50 -0800 (PST) From: Mathieu Prevot Date: Thu, 21 Jan 2016 17:19:50 +0100 X-Google-Sender-Auth: VqlTYe2dw76L9mJ9VDS4Qu1__60 Message-ID: Subject: IoT OS To: current@freebsd.org, hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 16:20:13 -0000 Dear all, I would like to connect several connected object (with homogeneous or heterogenous hardare: intel edison, samsung artik, apple AX, intel core, etc) so the calculation needs, the storage/memory, the connection, etc are decoupled; hence we can reach an ecosystem with several clouds. How do you recommend to reach that ? from the kernel, a module, or eventually a software ? Thanks M From owner-freebsd-current@freebsd.org Thu Jan 21 16:34:30 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 69512A8C1CF; Thu, 21 Jan 2016 16:34:30 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from smtp.rlwinm.de (smtp.rlwinm.de [IPv6:2a01:4f8:201:31ef::e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 38DA21AA7; Thu, 21 Jan 2016 16:34:30 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from crest.local (unknown [87.253.189.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.rlwinm.de (Postfix) with ESMTPSA id 31CEAF930; Thu, 21 Jan 2016 17:34:27 +0100 (CET) Subject: Re: IoT OS To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org References: From: Jan Bramkamp Message-ID: <56A10892.2090308@rlwinm.de> Date: Thu, 21 Jan 2016 17:34:26 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 16:34:30 -0000 On 21/01/16 17:19, Mathieu Prevot wrote: > Dear all, > > I would like to connect several connected object (with homogeneous or > heterogenous hardare: intel edison, samsung artik, apple AX, intel core, > etc) so the calculation needs, the storage/memory, the connection, etc are > decoupled; hence we can reach an ecosystem with several clouds. > > How do you recommend to reach that ? from the kernel, a module, or > eventually a software ? Your message contains neither enough information nor a precise enough question for anyone to provide you a helpful answer. Please describe your problem in sufficient detail and reformulate your question. If you still think these mailing lists (current@ and hackers@) are a good audience for your question afterward ask them again. From owner-freebsd-current@freebsd.org Thu Jan 21 16:38:09 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BD5C9A8C375; Thu, 21 Jan 2016 16:38:09 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::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 83C351E5F; Thu, 21 Jan 2016 16:38:09 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-ob0-x22b.google.com with SMTP id yo10so14306299obb.2; Thu, 21 Jan 2016 08:38:09 -0800 (PST) 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=KEd0q7kthVeO5mA8L9gFLv/ZlIdjHpNMSzgp+kxr4j8=; b=NhOt8Lx32rFQkRr4TOZVSAWY5BVfW5p4nGSg4kUPbXgHljhAIZi8WPCaJ4P1RY2LON +91P0CuxFVJuUhmO5MLFMlaBGp2QbmPQ0STvlcNmZFaLWk354o1bGlrEshPb6omLRV79 8hPCUerOfASZvnNfJ2LAwuzEgbkljCT+rmY8uwNmujEupGzYkKiT0KzpGQaTs6+SHRgu i4bKEP/SRk1gjl4QbXdmXtIKdu1IfzoQWehFeLsSx/dp/iyzsIeX2awyCa7jqLVz5DBU fuctmMa/Z5s4VYxI0HautFtu9hX+cnzgqAE1sqZbp7Ul1WHSDVNGZyFkOaJmOynpsEYa B/rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=KEd0q7kthVeO5mA8L9gFLv/ZlIdjHpNMSzgp+kxr4j8=; b=O/y4rJn/cM0W+toPKy8ho+rLMyelKjL/Pc1RV2GB0Q6QzL48D4nYodRdEjQcpu0zFc MCqQAjFNcO1XfdqQv/AaYICj8sZ2ggqP2RWSu3szZbx4Z5L23ueUo2a8NZ0+mISgH6aL TtEzIWcF+XDLfO3uWA81OGOpYPw480EiEE1IRwGmpVCwzgEYwSdyc7GKEGOc+EdwbBfQ 4LhgNgb6OcRRbb8WjYQY/WnseQIYRQDti1X69E5jYw0+Pywjwt99na+nsXyg8okezchS Ccv9PUY1ZsM8WddbSb1ieJhALmZbE7WbGz0DWXvBGSzTndcs+P2zO6/o3zz8JxqR6wQK iYDw== X-Gm-Message-State: ALoCoQmudsXj3XrGf/EjS/w5yqEQh48RbIhaaNpwW5r7ShlUoX7Qq85DPOyFTv4IH3J8hahUX7Oex3+zaweuevIu9A0/9Pgo+Q== X-Received: by 10.60.233.103 with SMTP id tv7mr34399696oec.13.1453394288876; Thu, 21 Jan 2016 08:38:08 -0800 (PST) Received: from ?IPv6:2601:601:800:126d:b4e7:9c6b:5d99:23b0? ([2601:601:800:126d:b4e7:9c6b:5d99:23b0]) by smtp.gmail.com with ESMTPSA id z190sm865924oig.25.2016.01.21.08.38.06 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Jan 2016 08:38:07 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: IoT OS From: NGie Cooper X-Mailer: iPhone Mail (13C75) In-Reply-To: <56A10892.2090308@rlwinm.de> Date: Thu, 21 Jan 2016 08:38:05 -0800 Cc: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <56A10892.2090308@rlwinm.de> To: Jan Bramkamp X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 16:38:09 -0000 > On Jan 21, 2016, at 08:34, Jan Bramkamp wrote: >=20 >> On 21/01/16 17:19, Mathieu Prevot wrote: >> Dear all, >>=20 >> I would like to connect several connected object (with homogeneous or >> heterogenous hardare: intel edison, samsung artik, apple AX, intel core,= >> etc) so the calculation needs, the storage/memory, the connection, etc ar= e >> decoupled; hence we can reach an ecosystem with several clouds. >>=20 >> How do you recommend to reach that ? from the kernel, a module, or >> eventually a software ? >=20 > Your message contains neither enough information nor a precise enough ques= tion for anyone to provide you a helpful answer. >=20 > Please describe your problem in sufficient detail and reformulate your que= stion. If you still think these mailing lists (current@ and hackers@) are a g= ood audience for your question afterward ask them again. It depends on your workload and hardware requirements (there isn't a simple a= nswer to your question because you didn't describe what you needed with conc= rete requirements). I would talk to cem@. He's working on ioat(4) on head for us ($work). Thanks, -NGie= From owner-freebsd-current@freebsd.org Thu Jan 21 18:08:26 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B55FEA8C523; Thu, 21 Jan 2016 18:08:26 +0000 (UTC) (envelope-from mathieu.prevot@gmail.com) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 21D3D1C7E; Thu, 21 Jan 2016 18:08:26 +0000 (UTC) (envelope-from mathieu.prevot@gmail.com) Received: by mail-lb0-x229.google.com with SMTP id x4so28298161lbm.0; Thu, 21 Jan 2016 10:08:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=8q1TV4DIeLTyJiDk5pejvJj/6DtM7nF5GFucoIkY4xU=; b=rqBG3YQNuT0sTORCjQBdww3z7vUX27mEWqxKVCvNl9hc4mvj9cC1DnTugVVVSHDJ6a 9KnyX2/w4pMTXlRbJbiaQ1q5wz5Y9rC94p3Pfo9QHybAurG7oR2HJkguELuMBb527S8k TskY+0jZEh67dFauaJXJdZS6kYxxssYfk9hXbl4oDV9nm5l+bhBgPNy/KBEIOYydbvmi XWg2zM9CxcFLuJ0ZGKHTG1oWAfZymy3ZmRF1nbPz48D7M41DuRNVjElFB/LpvuPQoIjV WGsui0bVzHrKvMoacVfM5emFtoLTOac8/6a87a5z6JRVpr2tGcJIKuP5Jl9E1QtyhI1v 3DLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=8q1TV4DIeLTyJiDk5pejvJj/6DtM7nF5GFucoIkY4xU=; b=OIzKo8EOu9lP/8E+kr2Gvatl2fbxLDosybKgHedI2cCXnlEimxfXJzY2kEA18spCHg wbyBSjXaGgp+uJUBZXaTppayoGQhQfItEIwNqcyQDVZYIZmHrIyu3zXlGCrsh+eAx+po JQ64GX0xkq85gDT/vPCwRotOsGMgpqpVNBIa1d3iGAaHdSWqQdnaRSYQZ7Y7TH/y1Ptb +ZbaWnQPHXEQk/AsymII8GSHKSKoWONxdAwlSOKYmdY4RAGTTQOg0NRZ69WiNI5YmtHC dZ+8nlhkIicxRNEoyJYTCWCeha7Alu4QBEB6O5XUNqK0MW0gZ/zi+wHHpQRLnvCXfcV6 E9JQ== X-Gm-Message-State: ALoCoQmIliW41DFofE5XRSxDMZqQ7isbXgvkmt1cJB5W+c85Eibsien1+IvPsuAffYTSww19D4pCnfq/jIT73Ecul52vA/4A/A== X-Received: by 10.112.184.133 with SMTP id eu5mr12761674lbc.99.1453399702612; Thu, 21 Jan 2016 10:08:22 -0800 (PST) MIME-Version: 1.0 Sender: mathieu.prevot@gmail.com Received: by 10.25.89.75 with HTTP; Thu, 21 Jan 2016 10:08:02 -0800 (PST) In-Reply-To: References: <56A10892.2090308@rlwinm.de> From: Mathieu Prevot Date: Thu, 21 Jan 2016 19:08:02 +0100 X-Google-Sender-Auth: vCwnxy6ZDYeksTPCVSxKOVIT5AQ Message-ID: Subject: Re: IoT OS To: NGie Cooper Cc: Jan Bramkamp , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 18:08:26 -0000 2016-01-21 17:38 GMT+01:00 NGie Cooper : > > > On Jan 21, 2016, at 08:34, Jan Bramkamp wrote: > > > >> On 21/01/16 17:19, Mathieu Prevot wrote: > >> Dear all, > >> > >> I would like to connect several connected object (with homogeneous or > >> heterogenous hardare: intel edison, samsung artik, apple AX, intel > core, > >> etc) so the calculation needs, the storage/memory, the connection, etc > are > >> decoupled; hence we can reach an ecosystem with several clouds. > >> > >> How do you recommend to reach that ? from the kernel, a module, or > >> eventually a software ? > > > > Your message contains neither enough information nor a precise enough > question for anyone to provide you a helpful answer. > > > > Please describe your problem in sufficient detail and reformulate your > question. If you still think these mailing lists (current@ and hackers@) > are a good audience for your question afterward ask them again. > > It depends on your workload and hardware requirements (there isn't a > simple answer to your question because you didn't describe what you needed > with concrete requirements). > > I would talk to cem@. He's working on ioat(4) on head for us ($work). > Thanks, > -NGie > Say all objects are connected peer to peer with wifi, some of them are connected to internet through gsm network or wifi to a box. These object are moving in space, and for some reasons, connections are dynamical and can be severely impaired or lost. They have incoming local streams of data (eg HD videos, accelerometer, GPS, other wifi and gsm signals, etc). I would like to abstract the CPU layer, storage layer, and internet connection so that in realtime results of one of my objects are saved if this object dies, so that if one of the object giving internet access to the group loose its connection, the redundancy allows the group of object not to lose internet connection. Can I consider these as different load balancing layers ? Do you recommend to implement this at the kernel layer or at an API layer ? Can I see that as a lightweight cluster ? I think the API is more flexible, especially if I have an heterogeneous (by CPU, OS) set of connected object. However, working at the kernel level allows existing programs not to be rewritten. What are your thoughts ? Do you recommend another list ? Thanks From owner-freebsd-current@freebsd.org Thu Jan 21 18:05:21 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 80C6FA8C49F; Thu, 21 Jan 2016 18:05:21 +0000 (UTC) (envelope-from mathieu.prevot@gmail.com) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 090391C36; Thu, 21 Jan 2016 18:05:21 +0000 (UTC) (envelope-from mathieu.prevot@gmail.com) Received: by mail-lf0-x231.google.com with SMTP id h129so32253549lfh.3; Thu, 21 Jan 2016 10:05:20 -0800 (PST) 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=yJFKHqCUGFz2/5rDBVrd11JyQpSJvsrF53ouKvsPTLM=; b=YJda+Z8tTsmWTVev2KUXyoCx/PBZd9vCMYhhsKPq8DrIVeFKSrIPpmtV4ZMHOKHnHg yA8et4B9WgYpq+R5/e5JQDFCsgepdcUqzs/0PomU4XSb6DiV2nO+1JFkJcjmEI/p3W0h hCeZEkDNlreY2dmOx0Xp3PxaQHt3RiF7q97bNv/jtjFENQJ7XK7tQJbjBu63aZDJcO/9 CA11ufQbwgEKXWqrUJe0V8oTC2uDygznh+MMVME+Sg4xVCfwYWYCmpRyMHj1nkmsCEq7 fSMJShDvFuQkFuSgBv3pzylCnLJ/V28zCnesGFweBJesL3TMt3F5vCeWjuadVfrhf2JG wXrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yJFKHqCUGFz2/5rDBVrd11JyQpSJvsrF53ouKvsPTLM=; b=asqt6l1Pj7f/Mlpd71J/R/OsgYrICds78TgoM0ktONBv7gkHYeRNHeCafH1aSh4O2v rVttbO4AwzEh0DIcrYWx6/a+5UjYIEL+81H+7FrEviMLv3fw2pwURDAX/wTsPUwWgyJZ I6YJoee9kTg4VrGdN+rSa+KCSxImkhEbTs3gj7KLH2wq9dbzfcESOwkZLA4YOsaHWAao 4cbTOZNzgsxvS8fdB8NpFPvffPXoBE3Y9mhCYnlPPP17VFJ+e1l1NG0kcwc2J4oRzkfY UFaqMvFdeCKVTMGrTzTUPonKzXzocB7J9VYV4BMdywkUIg196QDCPSHEK0ZwfSfoQjON 9rIw== X-Gm-Message-State: ALoCoQmziFiRx2yWfYH+tbhuufpH5N0SvJEXBGF+tfnJUgjOaN+bXvN7v1fWjfGxiDPDyoUfbxcfGTBMlT0Ul6YSz/4AQyQtjg== X-Received: by 10.25.170.129 with SMTP id t123mr16068606lfe.103.1453399519030; Thu, 21 Jan 2016 10:05:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.89.75 with HTTP; Thu, 21 Jan 2016 10:04:59 -0800 (PST) In-Reply-To: References: <56A10892.2090308@rlwinm.de> From: Mathieu Prevot Date: Thu, 21 Jan 2016 19:04:59 +0100 Message-ID: Subject: Re: IoT OS To: NGie Cooper Cc: Jan Bramkamp , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org X-Mailman-Approved-At: Thu, 21 Jan 2016 18:11:45 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 18:05:21 -0000 2016-01-21 17:38 GMT+01:00 NGie Cooper : > > > On Jan 21, 2016, at 08:34, Jan Bramkamp wrote: > > > >> On 21/01/16 17:19, Mathieu Prevot wrote: > >> Dear all, > >> > >> I would like to connect several connected object (with homogeneous or > >> heterogenous hardare: intel edison, samsung artik, apple AX, intel > core, > >> etc) so the calculation needs, the storage/memory, the connection, etc > are > >> decoupled; hence we can reach an ecosystem with several clouds. > >> > >> How do you recommend to reach that ? from the kernel, a module, or > >> eventually a software ? > > > > Your message contains neither enough information nor a precise enough > question for anyone to provide you a helpful answer. > > > > Please describe your problem in sufficient detail and reformulate your > question. If you still think these mailing lists (current@ and hackers@) > are a good audience for your question afterward ask them again. > > It depends on your workload and hardware requirements (there isn't a > simple answer to your question because you didn't describe what you needed > with concrete requirements). > > I would talk to cem@. He's working on ioat(4) on head for us ($work). > Thanks, > -NGie > Say all objects are connected peer to peer with wifi, some of them are connected to internet through gsm network or wifi to a box. These object are moving in space, and for some reasons, connections are dynamical and can be severely impaired or lost. They have incoming local streams of data (eg HD videos, accelerometer, GPS, other wifi and gsm signals, etc). I would like to abstract the CPU layer, storage layer, and internet connection so that in realtime results of one of my objects are saved if this object dies, so that if one of the object giving internet access to the group loose its connection, the redundancy allows the group of object not to lose internet connection. Can I consider these as different load balancing layers ? Do you recommend to implement this at the kernel layer or at an API layer ? Can I see that as a lightweight cluster ? I think the API is more flexible, especially if I have an heterogeneous (by CPU, OS) set of connected object. However, working at the kernel level allows existing programs not to be rewritten. What are your thoughts ? Do you recommend another list ? Thanks M From owner-freebsd-current@freebsd.org Fri Jan 22 00:20:52 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D84ADA8C671; Fri, 22 Jan 2016 00:20:52 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::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 637B8108D; Fri, 22 Jan 2016 00:20:52 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-lf0-x22d.google.com with SMTP id 17so37290740lfz.1; Thu, 21 Jan 2016 16:20:52 -0800 (PST) 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=K/DIjz4NnIwgYkpEtM5csnTNcQdJl+uGd7ij3sQkxcg=; b=H1LlgfI8xFeETvmTq6i9Ge5NeHycSJBagPdjss1UjBswag5fQUepgw28k4+oPLrnCm FSDLUXRxoVnbEom4CSbVHFqyT7doUp+1AUo8vULbwLCEVoIlqZQG+sA6kIRoTa19Tq4G ql2eaPL61ltuD5Aj20aP2KqNlDQ2o8cgtn3dkvL8UTv4FG/sOGVpcIGqyLtEMOBl9L2v yYHbD2MNrO4N3XSuoxLw4L9DN1J9dcHmSNuQdwjF9vRTsw4nBsfanDjVPzN8QCOLrmJT jVVNB5f+NmOyHMX/3Kt8bTTsVKAyX/8N5o/PVXBHga2iSYaJVNES0MuthL5+Ztco0y7t BaKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=K/DIjz4NnIwgYkpEtM5csnTNcQdJl+uGd7ij3sQkxcg=; b=eAFwLbG6KHDvV9hHDFnRBWQSVm/0bz4YmfPKNp4afE7xS5sh9apHel/g6wKCAf+Rnd Vkp108saZjV1BrRAq/DhdWerkWErLTgVkzPnLi6R5XmCuv+YgOr4avju3VqGK6tQDlCU NKlYb4lwQv7fqfVBKeL8K0IbDqpt1B7G8uE/+aEQZLLUoUJ53p0dAEm+RQeM4IBv5iyL wiGI5reCL3g4MwRfgjKE7Zgk8S/7uUNZ+oCyVcPhZEVEIOSr+1TDBjJGLZsf+r6T2yao z+yg+/ud9J7z+Mld/TlBSk1S0LsXqIlqvdpemMVl/lbmCjRKkzoLA/L/ZRQFVbB8cZal MW+w== X-Gm-Message-State: AG10YORKJyHFl3okDK4j3pWY+cY+aZavHsf4dmHGwV858YRnEXgL+Y1Nt8khfcNE16YrwrATaGwNnV3X5PbEQw== MIME-Version: 1.0 X-Received: by 10.25.155.81 with SMTP id d78mr37760lfe.77.1453422050184; Thu, 21 Jan 2016 16:20:50 -0800 (PST) Received: by 10.112.160.133 with HTTP; Thu, 21 Jan 2016 16:20:50 -0800 (PST) In-Reply-To: References: <56A10892.2090308@rlwinm.de> Date: Thu, 21 Jan 2016 16:20:50 -0800 Message-ID: Subject: Re: IoT OS From: NGie Cooper To: Jan Bramkamp Cc: FreeBSD Current , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 00:20:52 -0000 On Thu, Jan 21, 2016 at 8:38 AM, NGie Cooper wrote: ... > I would talk to cem@. He's working on ioat(4) on head for us ($work). I misunderstood the terms a bit. IoT (Internet of Things) != iaot(4) ( Intel I/O Acceleration Technology ). Thanks, -NGie From owner-freebsd-current@freebsd.org Fri Jan 22 08:17:12 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7F807A8CA81 for ; Fri, 22 Jan 2016 08:17:12 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 6296917C0 for ; Fri, 22 Jan 2016 08:17:12 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 5E5E5A8CA80; Fri, 22 Jan 2016 08:17:12 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 43FF1A8CA7F for ; Fri, 22 Jan 2016 08:17:12 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C12CB17BE for ; Fri, 22 Jan 2016 08:17:11 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: by mail-lb0-x22e.google.com with SMTP id cl12so36848758lbc.1 for ; Fri, 22 Jan 2016 00:17:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=/5vf/CuLWfO70/VLHVG28gSydqliaYHLpIVptsFhE3c=; b=eYIw5rbzq2Rmw+6Vwj/dg8n7Adz1xwfT6WKZCblmJIxo12NUcPU7e2Ch6I69i/12I7 L7PiMS5+EOIWL2jLd5Ix6a5PqW70jMTzIRN0OSd99yuw8lZjz68UmaQdmdImkfo2SBN5 e5jSg7+hunYXWmgcMTPUoybmeeE3X26+YXj2pIA60yctjuygvt09EbccOVbxy7ffv+Ei gCqF8JvhXdouh9RpjbNDd7HysKX5iDB+iQzUt+Co9NayLckLroAnoKDIgkN6TU4IPcz9 KZe2i2vFIG5sTbZ0qnVTJfBHbKvEc3NKof6h3Qr+rcD5Mi7uO5ArVY7QjIZi78YYEtBQ vw/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-type:content-disposition:user-agent; bh=/5vf/CuLWfO70/VLHVG28gSydqliaYHLpIVptsFhE3c=; b=k4coVyv3tN7uwvDoCUAWVarFt2v0H91484ilut4/BB3QCAgpWlItl/Hkf43EuFQg6t KcY14NWGR2NSrC+gVXHb0meXeT3IObQj/6LANmLntOR4G72lvgDyoT0ogHOXAlYpoTEm bH/8aTis3CJkMP2y9F8/B4ZJohtFDwxuMezAUGbVrNcWeABONsgFH0zHcrGhKHlwPDga lyLppmfilLZ+5pe/9j91XBUbPYx2o0fvIEVGQ3/I4EUfDdPbwp2Bx2vE2Ilmco94KPVY t/daZgNrr2xfi4p1XDEkcZJF2d1ANowT0fPIgBUW3HtsvnO8/gyDoIRMC1Y9WDPV2Lk8 ilaQ== X-Gm-Message-State: AG10YORLQu/oZJfVKCsaorqu8TYajlFyl7tzPaUQ3qL30N1Q3WOZNNDLzUdhwakVgwcEKw== X-Received: by 10.112.168.5 with SMTP id zs5mr715935lbb.56.1453450629964; Fri, 22 Jan 2016 00:17:09 -0800 (PST) Received: from localhost ([81.19.73.103]) by smtp.gmail.com with ESMTPSA id m21sm726492lfe.29.2016.01.22.00.17.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jan 2016 00:17:09 -0800 (PST) Date: Fri, 22 Jan 2016 11:17:08 +0300 From: Vladimir Zakharov To: current@freebsd.org Subject: LibreOffice doesn't work anymore Message-ID: <20160122081708.GA3416@vzakharov> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 08:17:12 -0000 Hello! Updating from r294203 to r294460 has broken LibreOffice. Now LO core dumps with the following message: GLib (gthread-posix.c): Unexpected error from C library during 'pthread_key_create': Function not implemented. Aborting. Here is the backtrace: GNU gdb 6.1.1 [FreeBSD] ... This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... Core was generated by `soffice.bin'. Program terminated with signal 6, Aborted. Reading symbols from /usr/local/lib/libreoffice/program/libuno_sal.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libreoffice/program/libuno_sal.so.3 ... (skipped lots of "Reading symbols ... (no debugging symbols found)" and "Loaded symbols ..." strings) ... Reading symbols from /usr/local/lib/libtasn1.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libtasn1.so.6 Reading symbols from /usr/local/lib/libnettle.so.4...Error while reading shared library symbols: Dwarf Error: wrong version in compilation unit header (is 3, should be 2) [in module /usr/local/lib/libnettle.so.4] Reading symbols from /usr/local/lib/libhogweed.so.2...Error while reading shared library symbols: Dwarf Error: wrong version in compilation unit header (is 3, should be 2) [in module /usr/local/lib/libhogweed.so.2] Reading symbols from /usr/local/lib/libgmp.so.10...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgmp.so.10 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x0000000800dc9b0a in thr_kill () from /lib/libc.so.7 [New LWP 100189] (gdb) -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra From owner-freebsd-current@freebsd.org Fri Jan 22 08:25:34 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 04DD7A8CE2F for ; Fri, 22 Jan 2016 08:25:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E51C61D30 for ; Fri, 22 Jan 2016 08:25:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id E1368A8CE2E; Fri, 22 Jan 2016 08:25:33 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E0D66A8CE2C for ; Fri, 22 Jan 2016 08:25:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7ED171D2F for ; Fri, 22 Jan 2016 08:25:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u0M8PNux057604 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 22 Jan 2016 10:25:24 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u0M8PNux057604 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u0M8PND5057603; Fri, 22 Jan 2016 10:25:23 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 22 Jan 2016 10:25:23 +0200 From: Konstantin Belousov To: Vladimir Zakharov Cc: current@freebsd.org Subject: Re: LibreOffice doesn't work anymore Message-ID: <20160122082523.GP3942@kib.kiev.ua> References: <20160122081708.GA3416@vzakharov> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160122081708.GA3416@vzakharov> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 08:25:34 -0000 On Fri, Jan 22, 2016 at 11:17:08AM +0300, Vladimir Zakharov wrote: > Hello! > > Updating from r294203 to r294460 has broken LibreOffice. Now LO core > dumps with the following message: > > GLib (gthread-posix.c): Unexpected error from C library during 'pthread_key_create': Function not implemented. Aborting. > > Here is the backtrace: > > GNU gdb 6.1.1 [FreeBSD] > ... > This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... > Core was generated by `soffice.bin'. > Program terminated with signal 6, Aborted. > Reading symbols from /usr/local/lib/libreoffice/program/libuno_sal.so.3...(no debugging symbols found)...done. > Loaded symbols for /usr/local/lib/libreoffice/program/libuno_sal.so.3 > ... > (skipped lots of "Reading symbols ... (no debugging symbols found)" and "Loaded symbols ..." strings) > ... Did you skipped the message about libthr.so.3 ? If yes, update to at least r294470. From owner-freebsd-current@freebsd.org Fri Jan 22 08:40:52 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E8B58A8D2F5 for ; Fri, 22 Jan 2016 08:40:51 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id CA0F715CC for ; Fri, 22 Jan 2016 08:40:51 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id C6242A8D2F4; Fri, 22 Jan 2016 08:40:51 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ABEA3A8D2F3 for ; Fri, 22 Jan 2016 08:40:51 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 34A2215CA for ; Fri, 22 Jan 2016 08:40:51 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: by mail-lf0-x230.google.com with SMTP id 17so42500383lfz.1 for ; Fri, 22 Jan 2016 00:40:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=VhhtBBj/lAPT3R2U2mBr1cf7kO6m+t92WE/8SXmT3/4=; b=vw4T3YddmAab782ITidu2UiGigl2d+F8R/1+c0TA8ePdxQsnS2wlLY6y92j0uHgRHG fgYk/G443uP6ylBE49MiUOfax6dEo9YIt38qGFoaDGxmh/SNezIzgVwGIz6q/hdMBPiA riaaxDKAKGLC+mJqOmvxmWUVgVxE9zHvwthg1TSsqqXMY76lNnjIuVv0GMnsD9WWYa0/ dx68lXNWlWfvHbLAAAbBKXW5XVeT2fFuV4MnU35lVCN4xykfr/kybdJTnDKo6oetgOSt zySdhPbBc3Yd6T4iZoFBCW1HVeMc/9P5T7p+n2PHjVauWoUChoVCG8JWuXJYo8MY69hn T1tQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=VhhtBBj/lAPT3R2U2mBr1cf7kO6m+t92WE/8SXmT3/4=; b=AbVGAN/DD5oHcddpNUtDajp9UJl/LyLhAYoM+W51JwP87X//y+dFu3Q2IssaSkTzfO psIDo7sbyTHV4DdbX7CuXACM0nQiRbF2hwrApoHxkxDqE6MrBuvjAotSqNSwkxjHA68q GPKok1rsFbdXYGUPHe8w6KbGQcMpe/sawhYX/UK/fH5bmgwSGsbiHV5XPUj/YvgvDqIV G3FCo22lb6sKDQOWOI6aNVvVINXx6j0uKOwTZhSqtPqiBI/g44zqGbOOt+fQaBtsVhka eH+fTONopC98BdkyXXwpTSyZESD4tqsoEfOf9AleSpAIPP7ZmgoSFetCB/9fWqA/sn/V 8t/A== X-Gm-Message-State: AG10YOTRvo2Na4DTilRWqTYKWeiXSaZ0g6+ypFVypYBmLllm+OJINgFTHZE/3xxXNzzvTQ== X-Received: by 10.25.18.162 with SMTP id 34mr650276lfs.52.1453452049161; Fri, 22 Jan 2016 00:40:49 -0800 (PST) Received: from localhost ([81.19.73.103]) by smtp.gmail.com with ESMTPSA id ei4sm714041lbb.18.2016.01.22.00.40.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jan 2016 00:40:48 -0800 (PST) Date: Fri, 22 Jan 2016 11:40:47 +0300 From: Vladimir Zakharov To: Konstantin Belousov Cc: current@freebsd.org Subject: Re: LibreOffice doesn't work anymore Message-ID: <20160122084047.GA5370@vzakharov> References: <20160122081708.GA3416@vzakharov> <20160122082523.GP3942@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160122082523.GP3942@kib.kiev.ua> X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 08:40:52 -0000 On Fri, Jan 22, 2016, Konstantin Belousov wrote: > On Fri, Jan 22, 2016 at 11:17:08AM +0300, Vladimir Zakharov wrote: > > Hello! > > > > Updating from r294203 to r294460 has broken LibreOffice. Now LO core > > dumps with the following message: > > > > GLib (gthread-posix.c): Unexpected error from C library during 'pthread_key_create': Function not implemented. Aborting. > > > > Here is the backtrace: > > > > GNU gdb 6.1.1 [FreeBSD] > > ... > > This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... > > Core was generated by `soffice.bin'. > > Program terminated with signal 6, Aborted. > > Reading symbols from /usr/local/lib/libreoffice/program/libuno_sal.so.3...(no debugging symbols found)...done. > > Loaded symbols for /usr/local/lib/libreoffice/program/libuno_sal.so.3 > > ... > > (skipped lots of "Reading symbols ... (no debugging symbols found)" and "Loaded symbols ..." strings) > > ... > Did you skipped the message about libthr.so.3 ? Yes, there was message about libthr.so.3 in omitted part. > > If yes, update to at least r294470. > Ok. Started updating to r294556. -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra From owner-freebsd-current@freebsd.org Fri Jan 22 10:24:47 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BFA43A8D27C; Fri, 22 Jan 2016 10:24:47 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7BAFF14CF; Fri, 22 Jan 2016 10:24:47 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-229-231.lns20.per1.internode.on.net [121.45.229.231]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u0MAOY0b068866 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 22 Jan 2016 02:24:37 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: IoT OS To: Mathieu Prevot , NGie Cooper References: <56A10892.2090308@rlwinm.de> Cc: Jan Bramkamp , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org From: Julian Elischer Message-ID: <56A2035D.7030201@freebsd.org> Date: Fri, 22 Jan 2016 18:24:29 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 10:24:47 -0000 On 22/01/2016 2:08 AM, Mathieu Prevot wrote: > 2016-01-21 17:38 GMT+01:00 NGie Cooper : > >>> On Jan 21, 2016, at 08:34, Jan Bramkamp wrote: >>> >>>> On 21/01/16 17:19, Mathieu Prevot wrote: >>>> Dear all, >>>> >>>> I would like to connect several connected object (with homogeneous or >>>> heterogenous hardare: intel edison, samsung artik, apple AX, intel >> core, >>>> etc) so the calculation needs, the storage/memory, the connection, etc >> are >>>> decoupled; hence we can reach an ecosystem with several clouds. >>>> >>>> How do you recommend to reach that ? from the kernel, a module, or >>>> eventually a software ? >>> Your message contains neither enough information nor a precise enough >> question for anyone to provide you a helpful answer. >>> Please describe your problem in sufficient detail and reformulate your >> question. If you still think these mailing lists (current@ and hackers@) >> are a good audience for your question afterward ask them again. >> >> It depends on your workload and hardware requirements (there isn't a >> simple answer to your question because you didn't describe what you needed >> with concrete requirements). >> >> I would talk to cem@. He's working on ioat(4) on head for us ($work). >> Thanks, >> -NGie >> > Say all objects are connected peer to peer with wifi, some of them are > connected to internet through gsm network or wifi to a box. These object > are moving in space, and for some reasons, connections are dynamical and > can be severely impaired or lost. > > They have incoming local streams of data (eg HD videos, accelerometer, GPS, > other wifi and gsm signals, etc). > > I would like to abstract the CPU layer, storage layer, and internet > connection so that in realtime results of one of my objects are saved if > this object dies, so that if one of the object giving internet access to > the group loose its connection, the redundancy allows the group of object > not to lose internet connection. > > Can I consider these as different load balancing layers ? Do you recommend > to implement this at the kernel layer or at an API layer ? Can I see that > as a lightweight cluster ? > > I think the API is more flexible, especially if I have an heterogeneous (by > CPU, OS) set of connected object. However, working at the kernel level > allows existing programs not to be rewritten. What are your thoughts ? > > Do you recommend another list ? This is still very hard to understand. Are you planning to work with some API that is described in a document somewhere? if so please give links. > > Thanks > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Fri Jan 22 11:07:21 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 71A85A8DF08 for ; Fri, 22 Jan 2016 11:07:21 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 5127C1ABE for ; Fri, 22 Jan 2016 11:07:21 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 4F0D4A8DF07; Fri, 22 Jan 2016 11:07:21 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 33BF1A8DF06 for ; Fri, 22 Jan 2016 11:07:21 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A9BCB1ABC for ; Fri, 22 Jan 2016 11:07:20 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: by mail-lf0-x22c.google.com with SMTP id h129so45158590lfh.3 for ; Fri, 22 Jan 2016 03:07:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=4l4ksaA723nZkbBQEhYlvdRNSLp7pcnNedKr6KkuRkY=; b=1GN1neYo3FBYaVdS4TM2krh0H+ZFenP4NcqAA2Y1qmQ++uyPE9X4uq5umqiULOvXB0 xwX/8ScRo86B8hPOdXvtQzybnCHZgvJGfxYzOdilKC+bGOw3m5g4niRkSY56x1Ed1VjQ Sh3jR1hxay1G0eZJr2zskSclIe02weG05CVplqkVoC1+V6mKWSrSx35LOAlDv+BVwMrt PXihkMiKk/p3dPLkIKQrVc++f6+SMlLuP8xaKJbreLCiccAAiT5z2ip/x4bO4Gq/wYGl th0gGBxGdPVNSI1yIqCZhAm4ST7dgh1KbtYH9YTXQBpWvc45QtGuKMTWppBFUlTdixqE GQqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=4l4ksaA723nZkbBQEhYlvdRNSLp7pcnNedKr6KkuRkY=; b=WMGOc9JQe+yNel4vBxIDN3b7JbkKIyPXoTBr3J6DGKR3B3Tvdwd3x0icxoXVEIy6Ri 6lg1V/1k/Y0poNeqzTv7MvagYBs7ZK35a/9nQwFu6hR9fyf7lT/B4heBruy1bMaR6lnt atl7nyXaYwM98skflyKNnr2pkP/IzUDbm2OvnS0YLxVMTTVsvHiV27hAsEnDQW+UGmHx 6tkFrYySSAF8A/qRBsClG/28yZ1y0kUkC2476I+GwU0P7gp9PQjagUlFzpVlouEhEbZI riHwN4iA6ese5kmJWYgPsl7PBRN5LTmsqKjcB17ztKTNMyasas6n4zF3+qGFH6ygfG8C VYmw== X-Gm-Message-State: AG10YOTXb5O0ozF2OFsuU/6dcIH2u05Q4FDx24L4eTYNim3tg6wuzaVXJl6JcOAlG+6MPQ== X-Received: by 10.25.158.136 with SMTP id h130mr969766lfe.136.1453460838767; Fri, 22 Jan 2016 03:07:18 -0800 (PST) Received: from localhost ([81.19.73.103]) by smtp.gmail.com with ESMTPSA id bn3sm816761lbc.15.2016.01.22.03.07.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jan 2016 03:07:18 -0800 (PST) Date: Fri, 22 Jan 2016 14:07:17 +0300 From: Vladimir Zakharov To: Konstantin Belousov Cc: current@freebsd.org Subject: Re: LibreOffice doesn't work anymore Message-ID: <20160122110717.GA1987@vzakharov> References: <20160122081708.GA3416@vzakharov> <20160122082523.GP3942@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160122082523.GP3942@kib.kiev.ua> X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 11:07:21 -0000 On Fri, Jan 22, 2016, Konstantin Belousov wrote: > On Fri, Jan 22, 2016 at 11:17:08AM +0300, Vladimir Zakharov wrote: > > Hello! > > > > Updating from r294203 to r294460 has broken LibreOffice. Now LO core > > dumps with the following message: > > > > GLib (gthread-posix.c): Unexpected error from C library during 'pthread_key_create': Function not implemented. Aborting. > > > > Here is the backtrace: > > > > GNU gdb 6.1.1 [FreeBSD] > > ... > > This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... > > Core was generated by `soffice.bin'. > > Program terminated with signal 6, Aborted. > > Reading symbols from /usr/local/lib/libreoffice/program/libuno_sal.so.3...(no debugging symbols found)...done. > > Loaded symbols for /usr/local/lib/libreoffice/program/libuno_sal.so.3 > > ... > > (skipped lots of "Reading symbols ... (no debugging symbols found)" and "Loaded symbols ..." strings) > > ... > Did you skipped the message about libthr.so.3 ? > > If yes, update to at least r294470. Works for me again on r294556. Thanks. -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra From owner-freebsd-current@freebsd.org Fri Jan 22 12:10:01 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A23A6A8B1A5 for ; Fri, 22 Jan 2016 12:10:01 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7557110BF; Fri, 22 Jan 2016 12:10:01 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.0.7] (cpc91230-cmbg18-2-0-cust661.5-4.cable.virginm.net [82.1.230.150]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id u0MC9kXA061290 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jan 2016 12:09:48 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host cpc91230-cmbg18-2-0-cust661.5-4.cable.virginm.net [82.1.230.150] claimed to be [192.168.0.7] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Too low PTHREAD_STACK_MIN value? From: David Chisnall In-Reply-To: Date: Fri, 22 Jan 2016 12:09:40 +0000 Cc: =?utf-8?Q?Roger_Pau_Monn=C3=A9?= , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <531F42CD.8020307@citrix.com> <913B1E7A-5192-430F-ABAF-576DFCFF98E6@FreeBSD.org> To: Ed Maste X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 12:10:01 -0000 On 21 Jan 2016, at 16:02, Ed Maste wrote: >=20 > I found that lang/polyml uses PTHREAD_STACK_MIN for a trivial signal > handler thread it creates[1]. They found it was too small and > implemented a 4K minimum bound to fix polyml on FreeBSD[2]. Even if > this isn't really the intended use of PTHREAD_STACK_MIN it suggests > the 2K x86 minimum may indeed be too low. >=20 > I ran into this while trying LLVM's libunwind, which requires more > stack space. 2K is certainly too low with LLVM libunwind. Is it > reasonable to just increase it to say 8K? I don=E2=80=99t really like this solution. PTHREAD_STACK_MIN is the = size for a stack that does not do anything. You should never use it = without adding the amount that you are going to need (which might be = nothing if you are running code from a language that does not use a = conventional C-style stack, but still wants to use OS threads). Making = it larger because a specific kind of thing that some consumers want to = do with it needs more space is definitely against the spirit of the = value and potentially harmful as it means that people using it correctly = will be using a lot more memory per thread. David From owner-freebsd-current@freebsd.org Fri Jan 22 14:31:24 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9CD61A8CEF0; Fri, 22 Jan 2016 14:31:24 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 6B9361D3E; Fri, 22 Jan 2016 14:31:23 +0000 (UTC) (envelope-from des@des.no) Received: from desk.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 118B45FB3; Fri, 22 Jan 2016 14:31:22 +0000 (UTC) Received: by desk.des.no (Postfix, from userid 1001) id 838974807A; Fri, 22 Jan 2016 15:31:22 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-security@freebsd.org Subject: HPN and None options in OpenSSH Date: Fri, 22 Jan 2016 15:31:22 +0100 Message-ID: <86mvrxvg79.fsf@desk.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 14:31:24 -0000 The HPN and None cipher patches have been removed from FreeBSD-CURRENT. I intend to remove them from FreeBSD-STABLE this weekend. The HPN patches were of limited usefulness and required a great deal of effort to maintain in our tree. The None cipher patch was less onerous, but it was a terrible idea with a very small user base since it was a compile-time option and off by default. The HPN-related configuration variables have been marked deprecated, while those related to the None cipher have been marked unsupported. This means that the former will be accepted with a warning, whereas the latter will result in an error. Most users will not be affected by this change. Those who are should switch to the openssh-portable port, which still offers both patches, with HPN enabled by default. It is expected that FreeBSD 10.3 will ship with OpenSSH 7.1p2, with a number of modifications intended to reduce the impact of upstream changes on existing systems. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@freebsd.org Fri Jan 22 17:08:56 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BE081A8D12A; Fri, 22 Jan 2016 17:08:56 +0000 (UTC) (envelope-from anton.rang@isilon.com) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailuogwprd51.lss.emc.com", Issuer "RSA Corporate Server CA v2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7B6091539; Fri, 22 Jan 2016 17:08:56 +0000 (UTC) (envelope-from anton.rang@isilon.com) Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u0MH8jPQ023465 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 22 Jan 2016 12:08:46 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com u0MH8jPQ023465 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=isilon.com; s=jan2013; t=1453482526; bh=oARnOmVavDJPlXFZZ37Qc5XncHU=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=figiBiZKDexuWu9jSgkwCmt7fg0ngzECxuBX+R0w45XG6/SbeQsNtjEkUA1NdS0dZ bdZjydq591w6Xn+M2rIWslCUFXAsiCLmWWo0qfXnRmwyUDCFsRbSEby+lLDQzm9DKI +r12KcZx93cz+pDCnRccFFI9I8v+UPrtPOi/BN9A= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com u0MH8jPQ023465 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd52.lss.emc.com (RSA Interceptor); Fri, 22 Jan 2016 12:08:25 -0500 Received: from MXHUB217.corp.emc.com (MXHUB217.corp.emc.com [10.253.68.87]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u0MH8XOn020707 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 22 Jan 2016 12:08:33 -0500 Received: from MX104CL01.corp.emc.com ([169.254.7.159]) by MXHUB217.corp.emc.com ([10.253.68.87]) with mapi id 14.03.0266.001; Fri, 22 Jan 2016 12:08:32 -0500 From: "Rang, Anton" To: Mathieu Prevot , NGie Cooper CC: Jan Bramkamp , "freebsd-hackers@freebsd.org" , "freebsd-current@freebsd.org" Subject: RE: IoT OS Thread-Topic: IoT OS Thread-Index: AQHRVGer4Z6ZjBEe40iiSuO3vjQwlJ8GfjEAgAABBYCAABhHgIABKbng Date: Fri, 22 Jan 2016 17:08:32 +0000 Message-ID: References: <56A10892.2090308@rlwinm.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.55.14] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: public X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 17:08:56 -0000 >Say all objects are connected peer to peer with wifi, some of them are con= nected to internet through gsm network or wifi to a box. >These object are moving in space, and for some reasons, connections are dy= namical and can be severely impaired or lost. > >They have incoming local streams of data (eg HD videos, accelerometer, GPS= , other wifi and gsm signals, etc). > >I would like to abstract the CPU layer, storage layer, and internet connec= tion so that in realtime results of one of my objects are saved >if this object dies, so that if one of the object giving internet access t= o the group loose its connection, the redundancy allows the group of object= not to lose internet connection. > >Can I consider these as different load balancing layers ? Do you recommend= to implement this at the kernel layer or at an API layer ? >Can I see that as a lightweight cluster ? > >I think the API is more flexible, especially if I have an heterogeneous (b= y CPU, OS) set of connected object. However, working at the kernel level al= lows existing programs not to be rewritten. >What are your thoughts ? =3D=3D=3D OK, I think I understand your question now. This isn't the right list for it, though I'm not sure where the right place= to go would be -- it's not FreeBSD-specific, in any case. There are academ= ic research groups looking into this type of problem; for instance, in the = area of sensor networks (ACM Transactions on Sensor Networks covers some of= these areas). There may be USENET groups which cover this area. To cover your three areas, which I think require somewhat different solutio= ns -- (a) CPU layer. I don't really recommend trying to abstract this. You coul= d use a virtual machine to hide the underlying architecture, and checkpoint= state periodically, but this is likely to slow down execution too much to = be useful. If the issue that a service may become unavailable, I'd recomme= nd a middleware layer which can detect this and recover by starting a new i= nstance of the service. Middleware layers like ZeroMQ, and clustering softw= are, may be a useful starting point. This does mean that stateful connecti= ons (like reading a video stream) won't recover cleanly, though; the client= would need to reconnect to attach to the new instance of the service. If = you really need that, it's going to be hard. (b) Storage layer. Look into highly-available clustered storage solutions.= If you can use key-value or some other simplified storage model, do it. = There are clustered file systems but probably none freely available that wo= uld work on the scale you envision and give decent performance. There are = more alternatives if you're flexible about the format in which you're stori= ng data (e.g. replicated object stores). (c) Networking layer; or internet. If you can drop & re-establish a connect= ion, or if every node has its own IP address (IPv6), this should be pretty = straightforward; software could detect loss of connection and change the ro= uting used to go through a different system. If not, you'll be a bit limite= d since mirroring TCP state between nodes would be too slow. This is a case= where the existing operating system kernels are likely to do most of what = you need; you simply need to add a layer to detect routing problems and sel= ect a new internet gateway appropriately. I'd avoid implementing any clustering within the kernel, in part because if= you have a wide variety of objects you may not want the same kernel on all= of them, and in part because debugging & recovery is much harder. You're u= nlikely to want to run most existing software on such a system anyway (espe= cially if they have relatively weak processors); you're better off writing = to a set of clustering APIs for storage and state, at least. For networking= , as mentioned, you can likely use the existing TCP stack & just add contro= ls to redirect traffic as needed. -- Anton From owner-freebsd-current@freebsd.org Sat Jan 23 01:59:00 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BCA98A8DA06; Sat, 23 Jan 2016 01:59:00 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 92DA81D93; Sat, 23 Jan 2016 01:59:00 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-229-231.lns20.per1.internode.on.net [121.45.229.231]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u0N1wn9J071906 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 22 Jan 2016 17:58:52 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: HPN and None options in OpenSSH To: =?UTF-8?Q?Dag-Erling_Sm=c3=b8rgrav?= , freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-security@freebsd.org References: <86mvrxvg79.fsf@desk.des.no> From: Julian Elischer Message-ID: <56A2DE54.6070603@freebsd.org> Date: Sat, 23 Jan 2016 09:58:44 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <86mvrxvg79.fsf@desk.des.no> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 01:59:00 -0000 On 22/01/2016 10:31 PM, Dag-Erling Smørgrav wrote: > The HPN and None cipher patches have been removed from FreeBSD-CURRENT. > I intend to remove them from FreeBSD-STABLE this weekend. > > The HPN patches were of limited usefulness and required a great deal of > effort to maintain in our tree. The None cipher patch was less onerous, > but it was a terrible idea with a very small user base since it was a > compile-time option and off by default. > > The HPN-related configuration variables have been marked deprecated, > while those related to the None cipher have been marked unsupported. > This means that the former will be accepted with a warning, whereas the > latter will result in an error. > > Most users will not be affected by this change. Those who are should > switch to the openssh-portable port, which still offers both patches, > with HPN enabled by default. > > It is expected that FreeBSD 10.3 will ship with OpenSSH 7.1p2, with a > number of modifications intended to reduce the impact of upstream > changes on existing systems. what is the internal window size in the new ssh? > > DES From owner-freebsd-current@freebsd.org Sat Jan 23 06:41:08 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B876DA8EE95 for ; Sat, 23 Jan 2016 06:41:08 +0000 (UTC) (envelope-from luzar722@gmail.com) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::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 8A2541DCB; Sat, 23 Jan 2016 06:41:08 +0000 (UTC) (envelope-from luzar722@gmail.com) Received: by mail-pf0-x236.google.com with SMTP id e65so53896558pfe.0; Fri, 22 Jan 2016 22:41:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=gerDityTNDTO0s7dnBTPzvE+7cSPrA0+62E04qIJJB8=; b=BdR8Qv02GWgysZn7oGx8j0jk8+iNT+cZvwOudX+gHWbn4rO/GLJaDP6URRkqfSX8OH TH6fuOi7z8o8YkjLuvDpoenjztB8Ehs02ajYqYx/5WQjczlfvfbMi+qnXs01h8johF9A NjaXyMPL79tO3aypry5DMZD9oTpn3CQeHQHOQ2DdoqL4Y6lcXbEwWUhE8fnkfWaYKrok RRzB8pzAMGDwLBM/UHY8eKvrBODWt993AoP/wL7acHW98YTs0Adr8Ho71vq373xKIZfP lIPRqpI4frXf7hcXH/fpMovr9dcyqH7Pp6PAeX5zfDXxLghp/nltqkvtLb5zvfTcDgFC 4RzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gerDityTNDTO0s7dnBTPzvE+7cSPrA0+62E04qIJJB8=; b=i1qEAMzw5pG1SHoRyvZm8GpsXhLO6YjoDlrl95rTN9iNsiB18Em/8yhoHDC7LDrX+G rpqOahrtS5LCqMAzXL6JQ2hYMBlXVhJ7AiByGtzbOSo4NbVDnSPFPQXgMgvk8FwNhXXz E6rpCU2MGxZqxducSj2GHzQcIXbmXjcY4Rr6UNC68I5NAlkp9YjmjFUgg/0GLBDA1p4w +QfJEygTn5zmOg4Ds/6NZ2mbeaMSJwX4VmBfA6RCRMC2fSOWUuMAQqrCyIx1zKBIY4SG IpR+boxBHmGsWmnbgoGxZtvfOBTKTebEnKl6PrHdoVMmQk/BXMAhxw08+GcA94Y7Jgb6 DP7g== X-Gm-Message-State: AG10YORYMdAyhiNHyo0pc5q2xDQdHGrfRG6CKfcDJHNhAWAc223qgSQwDDeRJ0D4ylKw7w== X-Received: by 10.98.72.132 with SMTP id q4mr9899901pfi.53.1453531268167; Fri, 22 Jan 2016 22:41:08 -0800 (PST) Received: from [192.168.114.100] ([120.29.76.9]) by smtp.googlemail.com with ESMTPSA id o75sm13888491pfi.17.2016.01.22.22.41.05 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Jan 2016 22:41:07 -0800 (PST) Message-ID: <56A3209A.4080703@gmail.com> Date: Sat, 23 Jan 2016 14:41:30 +0800 From: Ernie Luzar User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Bjoern A. Zeeb" CC: Mark Felder , freebsd-current@freebsd.org Subject: Re: RCTL and VIMAGE for 11.0-RELEASE References: <1440443338.1828791.364761057.5F263CEC@webmail.messagingengine.com> <4EE0EEFA-EDAB-4A88-B959-458C1D89900F@FreeBSD.org> In-Reply-To: <4EE0EEFA-EDAB-4A88-B959-458C1D89900F@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 06:41:08 -0000 Bjoern A. Zeeb wrote: >> On 24 Aug 2015, at 19:08 , Mark Felder wrote: >> >> What is preventing RCTL from being enabled right now? Any known/serious >> blockers? > > It’s enabled in GENERIC. > > >> And the same for VIMAGE? I know there were issues with some firewalls, >> but I'm not sure where that stands today. Does it degrade network >> performance in a measurable way? > > Ignoring performance for a second, there is more than just firewalls that needs to be done. I started writing a plan for the next 4 months yesterday. Most of this was done a few years ago and never made it to HEAD. It needs to be re-validated. If my plan comes together we’ll have another 4 month window before the 11 release cycle will start. > > /bz > It's been 5 months since the above was posted. What is the status of VIMAGE as part of base in 11.0-RELEASE? From owner-freebsd-current@freebsd.org Sat Jan 23 11:10:21 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 97F65A8E731 for ; Sat, 23 Jan 2016 11:10:21 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5B1151B4A for ; Sat, 23 Jan 2016 11:10:21 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 7D3DC25D38A4; Sat, 23 Jan 2016 11:10:18 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 91846C76FE7; Sat, 23 Jan 2016 11:10:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id HJG4JvbUCoLA; Sat, 23 Jan 2016 11:10:16 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4410:35ea:81f9:7462:46a9] (unknown [IPv6:fde9:577b:c1a9:4410:35ea:81f9:7462:46a9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id AE051C76FE6; Sat, 23 Jan 2016 11:10:15 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: RCTL and VIMAGE for 11.0-RELEASE From: "Bjoern A. Zeeb" In-Reply-To: <56A3209A.4080703@gmail.com> Date: Sat, 23 Jan 2016 11:09:55 +0000 Cc: freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <1440443338.1828791.364761057.5F263CEC@webmail.messagingengine.com> <4EE0EEFA-EDAB-4A88-B959-458C1D89900F@FreeBSD.org> <56A3209A.4080703@gmail.com> To: Ernie Luzar X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 11:10:21 -0000 > On 23 Jan 2016, at 06:41 , Ernie Luzar wrote: >=20 > Bjoern A. Zeeb wrote: >>> On 24 Aug 2015, at 19:08 , Mark Felder wrote: >>>=20 >>> What is preventing RCTL from being enabled right now? Any = known/serious >>> blockers? >> It=E2=80=99s enabled in GENERIC. >>> And the same for VIMAGE? I know there were issues with some = firewalls, >>> but I'm not sure where that stands today. Does it degrade network >>> performance in a measurable way? >> Ignoring performance for a second, there is more than just firewalls = that needs to be done. I started writing a plan for the next 4 months=20= > yesterday. Most of this was done a few years ago and never made it to = HEAD. It needs to be re-validated. If my plan comes together we=E2=80=99= ll have another 4 month window before the 11 release cycle will start. >> /bz >=20 > It's been 5 months since the above was posted. What is the status of = VIMAGE as part of base in 11.0-RELEASE? There is ongoing work; it was slightly delayed to the original plan. = Hope it all hits HEAD before early/mid March. Expect more patches soon. /bz= From owner-freebsd-current@freebsd.org Sat Jan 23 08:59:01 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7405CA8DEF0 for ; Sat, 23 Jan 2016 08:59:01 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 27F8E1BF9 for ; Sat, 23 Jan 2016 08:59:01 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-wm0-x235.google.com with SMTP id b14so13355418wmb.1 for ; Sat, 23 Jan 2016 00:59:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+ujSLe0HZkmlR/oRoE2iTuBcBLNqDE3m/v/8DMuAf2U=; b=l5UWPUxlCEQT1VGKEWb+Nzj1w3DpM1t+jQXE8VhUgVA3RelcUK8G/5eqbRzI47qRAg 2/ZcGrITmYBWion+HHY3Ce37+VIWVi7+yo4cnnfq3pbwF2oytsTuF5pwg3livkrC7i/l H948GUjZ0HGRO2bpt4B6WCK9vqQRq2MwbmJ8pg5SQfWcG7VjNyoGHQSHO0snLm9x+eTS sgJADVo2qdHwQbtFaoWitu+wQiGrKp1JhnSuiulQyzZVPh/hdyjTKVw186Urvl8IBdra 2DGwC97OouheYWMN7Ul5VpQC8rzn4TwrN5ZhK3mI26/ZYm4GaaR3CpYcHrE4kEW6dIPU dC1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+ujSLe0HZkmlR/oRoE2iTuBcBLNqDE3m/v/8DMuAf2U=; b=VOfS2X1RQAG4Wt16jCBC/lKLotjiGvOwl+kkcqmXy9r7BE1ynHN9WgKs5J0GY58P/K Ciwy7ZyiTxXvEQRanT1sJqP+LZEAVUV29JvOElf/Re1BI/Ls0rftT9TZt9l7DMFXKFiN DyDv1GwOc1VmqLX/VtomX06p94UPAGaambMHoeex57BQo57YlLhqap4YsZGfI0jUzzCM wwK2KZoY86V+hhLcJVS/YaQY3ykjKHhIpJYq3IP7AZNS1FPiJz4mTePfv7moWmaPrOod n7jXiLeN6ywhQl4+szEtNKsgXygPPMcmtq2OMDvjWayxoYDiVXgUjTl0XeWopo2gru3Y NoCg== X-Gm-Message-State: AG10YOQvE4JY8JFt9ZCyGI3K/NvqygmkWelxiyiFiNbnIGKxfT1XgxDJuiylJoU8qA90g2lexHYWGEaFwRsZPpEM MIME-Version: 1.0 X-Received: by 10.28.23.73 with SMTP id 70mr7444942wmx.37.1453539539604; Sat, 23 Jan 2016 00:58:59 -0800 (PST) Received: by 10.27.39.195 with HTTP; Sat, 23 Jan 2016 00:58:59 -0800 (PST) In-Reply-To: References: <531F42CD.8020307@citrix.com> <913B1E7A-5192-430F-ABAF-576DFCFF98E6@FreeBSD.org> Date: Sat, 23 Jan 2016 00:58:59 -0800 Message-ID: Subject: Re: Too low PTHREAD_STACK_MIN value? From: Maxim Sobolev To: David Chisnall Cc: Ed Maste , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , FreeBSD Current X-Mailman-Approved-At: Sat, 23 Jan 2016 12:18:36 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 08:59:01 -0000 For what it's worth, I agree with David. This looks like definite misuse of the constant. If app X requires min size of stack of Y, it's fullish of it if to expect our PTHREAD_STACK_MIN somehow accommodate that. It should be really using MAX(PTHREAD_STACK_MIN, Y) to set its stack instead. Should be easy to patch and it needs to be reported to the upstream vendor(s) instead. Don't forget that bumping this limit, no matter how small, will get multiplied by the number of threads running, which could be in many thousands. On Fri, Jan 22, 2016 at 4:09 AM, David Chisnall wrote: > On 21 Jan 2016, at 16:02, Ed Maste wrote: > > > > I found that lang/polyml uses PTHREAD_STACK_MIN for a trivial signal > > handler thread it creates[1]. They found it was too small and > > implemented a 4K minimum bound to fix polyml on FreeBSD[2]. Even if > > this isn't really the intended use of PTHREAD_STACK_MIN it suggests > > the 2K x86 minimum may indeed be too low. > > > > I ran into this while trying LLVM's libunwind, which requires more > > stack space. 2K is certainly too low with LLVM libunwind. Is it > > reasonable to just increase it to say 8K? > > I don=E2=80=99t really like this solution. PTHREAD_STACK_MIN is the size= for a > stack that does not do anything. You should never use it without adding > the amount that you are going to need (which might be nothing if you are > running code from a language that does not use a conventional C-style > stack, but still wants to use OS threads). Making it larger because a > specific kind of thing that some consumers want to do with it needs more > space is definitely against the spirit of the value and potentially harmf= ul > as it means that people using it correctly will be using a lot more memor= y > per thread. > > David > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > --=20 Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts Tel (Canada): +1-778-783-0474 Tel (Toll-Free): +1-855-747-7779 Fax: +1-866-857-6942 Web: http://www.sippysoft.com MSN: sales@sippysoft.com Skype: SippySoft From owner-freebsd-current@freebsd.org Sat Jan 23 10:51:11 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4227FA8E29A for ; Sat, 23 Jan 2016 10:51:11 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 0356C1240; Sat, 23 Jan 2016 10:51:11 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 6B5329BA; Sat, 23 Jan 2016 10:51:05 +0000 (UTC) Date: Sat, 23 Jan 2016 10:49:02 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: wblock@FreeBSD.org, des@FreeBSD.org, br@FreeBSD.org, emaste@FreeBSD.org, adrian@FreeBSD.org, kib@FreeBSD.org, smh@FreeBSD.org, andrew@FreeBSD.org, bz@FreeBSD.org, fanf@FreeBSD.org, araujo@FreeBSD.org, avos@FreeBSD.org, np@FreeBSD.org, dchagin@FreeBSD.org, jilles@FreeBSD.org, bjk@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <50060661.1.1453546257283.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <794548768.5.1453458693217.JavaMail.jenkins@jenkins-9.freebsd.org> References: <794548768.5.1453458693217.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_amd64_gcc4.9 - Build #1038 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_amd64_gcc4.9 X-Jenkins-Result: SUCCESS Precedence: bulk X-Mailman-Approved-At: Sat, 23 Jan 2016 12:18:48 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 10:51:11 -0000 FreeBSD_HEAD_amd64_gcc4.9 - Build #1038 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/1038/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/1038/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/1038/console Change summaries: 294621 by dchagin: Remove obsolete comment. MFC after: 3 days 294620 by dchagin: Fix a typo. MFC after: 3 days 294617 by adrian: Now that the flashmap code knows about SPI flash, add it in builds. PR: kern/206227 Submitted by: Stanislav Galabov 294616 by adrian: Teach the flashmap code about the SPI flash. PR: kern/206227 Submitted by: Stanislav Galabov 294615 by araujo: Add an IOCTL rr_limit to let users fine tuning the number of packets to be sent using roundrobin protocol and set a better granularity and distribution among the interfaces. Tuning the number of packages sent by interface can increase throughput and reduce unordered packets as well as reduce SACK. Example of usage: # ifconfig bge0 up # ifconfig bge1 up # ifconfig lagg0 create # ifconfig lagg0 laggproto roundrobin laggport bge0 laggport bge1 \ 192.168.1.1 netmask 255.255.255.0 # ifconfig lagg0 rr_limit 500 Reviewed by: thompsa, glebius, adrian (old patch) Approved by: bapt (mentor) Relnotes: Yes Differential Revision: https://reviews.freebsd.org/D540 294613 by fanf: Fix a regression in the .de and .dk whois special cases Ensure the special cases trigger whether we come via a referral or via the -c option. Match host names case-insensitively. Use the default character set supported by .de (UTF-8) since that is more compatible with the modern world than ISO 8859-1. Persuade them to give us a useful answer whether an internationalized domain name is given in UTF-8 or in punycode. 294611 by fanf: A lot of the cleverness in whois is no longer needed! The IANA whois server has the right referral information for domain names, IP addresses, and AS numbers, so whois does not need to be able to choose servers itself (except for a few cases where referrals do not work). We can delete a chunk of code, which is always fun. This change improves the referral handling to be less sensitive to all the various formats, and to allow multi-hop referral chains, such as IANA -> registry -> registrar. ARIN queries have the "+" flag added if no flags are present, so we get full details if the query matches multiple objects. The Verisign anti-spam logic is also now suppressed if the user provided a non- trivial query string. Uninformative rubric is now trimmed by default. The -S option turns off trimming, and disables query fettling. The -i option is back to its traditional pre-1999 hostname, since whois.internic.net is more useful than whois.networksolutions.com. Note that the old fallback/default server whois.crsnic.net is an alias for whois.internic.net. The manual is more informative about query syntax. 294610 by np: Fix for iWARP servers that listen on INADDR_ANY. The iWARP Connection Manager (CM) on FreeBSD creates a TCP socket to represent an iWARP endpoint when the connection is over TCP. For servers the current approach is to invoke create_listen callback for each iWARP RNIC registered with the CM. This doesn't work too well for INADDR_ANY because a listen on any TCP socket already notifies all hardware TOEs/RNICs of the new listener. This patch fixes the server side of things for FreeBSD. We've tried to keep all these modifications in the iWARP/TCP specific parts of the OFED infrastructure as much as possible. Submitted by: Krishnamraju Eraparaju @ Chelsio (with design inputs from Steve Wise) Sponsored by: Chelsio Communications Differential Revision: https://reviews.freebsd.org/D4801 294608 by emaste: Use MAN= to specify that no man page is provided NO_MAN is deprecated. Reviewed by: imp 294600 by avos: tools/tools/ath/ath_ee_v4k_print: reflect changes from r220589 Fix printf() arguments + sort includes Approved by: adrian (mentor) Differential Revision: https://reviews.freebsd.org/D4045 294598 by kib: In tty_dealloc(), clear the queues. See the comment for a scenario which explains why ttydev_leave() cleanup might not happen. Submitted by: bde MFC after: 3 weeks 294597 by wblock: Add a standards compliance note for strtok_r as suggested by cpercival. Reviewed by: cpercival MFC after: 1 week 294596 by kib: The struct file f_advice member is overlaid with the devfs f_cdevpriv data. If vnode bypass for devfs file failed, vn_read/vn_write are called and might try to dereference f_advice. Limit the accesses to f_advice to VREG vnodes only, which is the type ensured by posix_fadvise(). The f_advice for regular files is protected by mtxpool lock. Recheck that f_advice is not NULL after lock is taken. Reported and tested by: bde Sponsored by: The FreeBSD Foundation MFC after: 3 weeks 294595 by kib: When devfs dirent is freed, a vnode might still keep a pointer to it, apparently. Interlock and clear the pointer to avoid free memory dereference. Submitted by: bde (previous version) MFC after: 3 weeks 294594 by kib: Remove printf only useful for debugging. Requested by: bde Sponsored by: The FreeBSD Foundation MFC after: 3 weeks 294593 by jilles: sh: Clean a readonly local, even if the variable does not exist outside. If a local variable has been made read-only, this should not prevent its removal when the function returns. 294591 by fanf: Update whois synopsis and usage with new options 294590 by emaste: Restore libunwind.cpp to LLVM libunwind build (reverts r294576) The unw_* functions are not exported, but are used internally. 294582 by jilles: sh: Add already working test for local-readonly interaction. 294579 by bjk: Bump .Dd after r294575 294578 by smh: Fix ix advertise value after media change When ifconfig sets media then the values displayed by the advertise_speed value are invalidated. Fix this by setting the bits correctly including setting advertise to 0 for media = auto. Reviewed by: sbruno MFC after: 1 week Sponsored by: Multiplay Differential Revision: https://reviews.freebsd.org/D5034 294577 by br: Add support for RISC-V ISA. Reviewed by: emaste Sponsored by: DARPA, AFRL Sponsored by: HEIF5 Differential Revision: https://reviews.freebsd.org/D5021 294576 by emaste: Drop HP libunwind (unw_*) functions from LLVM libunwind They are not needed for exception handling. 294575 by fanf: A few `whois` usability improvements Look up AS numbers at ARIN. Handle more referral formats. Suppress spammy nameserver objects when querying the .com and .net whois servers by explicitly querying for domain names by default. 294574 by br: Add stubs for RISC-V ISA so libunwind can be compiled. Reviewed by: emaste Sponsored by: DARPA, AFRL Sponsored by: HEIF5 Differential Revision: https://reviews.freebsd.org/D5035 294573 by br: Add configuration for RISC-V ISA. Reviewed by: emaste Sponsored by: DARPA, AFRL Sponsored by: HEIF5 Differential Revision: https://reviews.freebsd.org/D5020 294572 by andrew: Stop including fdt_common.h in the arm64 code. We don't use anything from it, however may have relied on header pollution to pull in the needed headers through it Sponsored by: ABT Systems Ltd 294571 by br: Add support for RISC-V ISA. Reviewed by: andrew Sponsored by: DARPA, AFRL Sponsored by: HEIF5 Differential Revision: https://reviews.freebsd.org/D5014 294567 by bz: Change the variable to a #define in order to make gcc happy which otherwise will complain about "variably modified 'alias' at file scope". Unbreaks the build on gcc platforms. 294565 by jilles: sem: Don't free nameinfo that is still in list when open() fails. This bug could be reproduced easily by calling sem_open() with O_CREAT | O_EXCL on a semaphore that is already open in the process. The struct sem_nameinfo would be freed while still in sem_list and later calls to sem_open() or sem_close() could access freed memory. PR: 206396 MFC after: 5 days 294564 by des: r294563 was incomplete; re-add the client-side options as well. 294563 by des: Instead of removing the NoneEnabled option, mark it as unsupported. (should have done this in r291198, but didn't think of it until now) 294562 by andrew: Only define fdt_pic_table on arm, and when not using intrng as this is the only place that uses it. 294561 by andrew: Stop defining fdt_pic_table with ARM_INTRNG, it's unused. 294560 by des: Do not generate RSA1 or DSA keys by default. 294559 by andrew: Stop calling fdt_immr_addr from the xlp startup code. It's used to set fdt_immr_{va,pa,size}, but these are not used outside a single ARM SoC. From owner-freebsd-current@freebsd.org Sat Jan 23 12:37:27 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EF4B2A8BD1A for ; Sat, 23 Jan 2016 12:37:27 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B90751B1F; Sat, 23 Jan 2016 12:37:26 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.0.7] (cpc91230-cmbg18-2-0-cust661.5-4.cable.virginm.net [82.1.230.150]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id u0NCbH2d068956 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Jan 2016 12:37:18 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host cpc91230-cmbg18-2-0-cust661.5-4.cable.virginm.net [82.1.230.150] claimed to be [192.168.0.7] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Too low PTHREAD_STACK_MIN value? From: David Chisnall In-Reply-To: Date: Sat, 23 Jan 2016 12:37:10 +0000 Cc: Ed Maste , =?utf-8?Q?Roger_Pau_Monn=C3=A9?= , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <91D206B9-C030-4A7F-AEEF-1C2F141A53E3@FreeBSD.org> References: <531F42CD.8020307@citrix.com> <913B1E7A-5192-430F-ABAF-576DFCFF98E6@FreeBSD.org> To: Maxim Sobolev X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 12:37:28 -0000 On 23 Jan 2016, at 08:58, Maxim Sobolev wrote: >=20 > For what it's worth, I agree with David. This looks like definite = misuse of the constant. If app X requires min size of stack of Y, it's = fullish of it if to expect our PTHREAD_STACK_MIN somehow accommodate = that. It should be really using MAX(PTHREAD_STACK_MIN, Y) to set its = stack instead. Should be easy to patch and it needs to be reported to = the upstream vendor(s) instead. Don't forget that bumping this limit, no = matter how small, will get multiplied by the number of threads running, = which could be in many thousands After talking to Ed, I=E2=80=99m not sure I was correct in my initial = assessment. The code in pthread=E2=80=99s thread exit routine is = calling the unwinder, and that=E2=80=99s what=E2=80=99s exhausting the = stack space. This means that a thread function that just does return 0 = will run out of stack space. That said, existing values of PTHREAD_STACK_MIN are part of the ABI and = if we=E2=80=99re going to bump it then we need to make sure that we do = something clever with existing binaries to ensure that, when they ask = for 2KB of stack, we give them more (which can be problematic if = they=E2=80=99re allocating their own stack). I=E2=80=99d much prefer a = solution where we don=E2=80=99t expose the HP unwind interfaces from = libeh (it=E2=80=99s fine to do so from a separate libunwind) and we = don=E2=80=99t allocate that much space in the unwinder. David From owner-freebsd-current@freebsd.org Sat Jan 23 13:06:27 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6FDAEA8C899 for ; Sat, 23 Jan 2016 13:06:27 +0000 (UTC) (envelope-from mueller6724@bellsouth.net) Received: from nm16-vm3.access.bullet.mail.gq1.yahoo.com (nm16-vm3.access.bullet.mail.gq1.yahoo.com [216.39.63.74]) (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 47B8F10E2 for ; Sat, 23 Jan 2016 13:06:26 +0000 (UTC) (envelope-from mueller6724@bellsouth.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s2048; t=1453554226; bh=YQcbAANK3lxidlVTOYoR/8eAbGMk0gua2xiT71nkBrs=; h=Date:From:To:Subject:References:From:Subject; b=Ecwlx4xt8t3OtZ42DUaTxMkJiYQflog32Phc/x/qcaZY0+o2GtOtxP0y9A1y7RM95ZGmCYkQ51M7ZeFgw5qLMjkvu/6vb0wHkSG+Iu31L8M3sc3ZnCxa8M6tsugWdJM6tQGDSglqUqLOsobP9XoEPBVqnkOS6R5JiGP7HIGMt4iwZXeHjtBFWlaA8C32QxbkziH/3W/Kc8CFkzuuY5fv1cCD6/7HC9kzMNT92pBWbDfb1yD9bOJMKLWDPXr11yr2obkTVtPqRHWjAUmqXnFMEFbCXdOqieEOnCdBttPl1mi1qONY2g2egr1TqXzu+YjWy/DJkcHx7LyljcfOvQgGbw== Received: from [216.39.60.167] by nm16.access.bullet.mail.gq1.yahoo.com with NNFMP; 23 Jan 2016 13:03:46 -0000 Received: from [98.138.226.240] by tm3.access.bullet.mail.gq1.yahoo.com with NNFMP; 23 Jan 2016 13:03:46 -0000 Received: from [127.0.0.1] by smtp111.sbc.mail.ne1.yahoo.com with NNFMP; 23 Jan 2016 13:03:46 -0000 X-Yahoo-Newman-Id: 623047.3268.bm@smtp111.sbc.mail.ne1.yahoo.com Message-ID: <623047.3268.bm@smtp111.sbc.mail.ne1.yahoo.com> X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: sduQaRUVM1mLMOnThM2WR_qPJRiirpR.1rpdQ6mVXbzoEm3 kv9sBxhM5W8sL_bPCPIs51h3prqjPO22W9OnNHU4J0TlxEnH2pRK7NS8c6a4 X7bt24LNiuuHnJWtHox0LnObrJU.gbV6M66VG0_edGf4LzLJqdZqhyAGfhdd o56AiESeiwYXfJ02N0iams2W7TB9XHf6MnscnnXbzmpwihXIW8kisHJKtgXg hWe3YzoPKxzu5.peyzxBF3DdsE_PFWBawCFiFCzUTDh1mAwQcj2c7iv_EXQG SNVwloLmg8o0qXxbjW0PJrbdmZy9J1yfCs6cxttE3rObXy4.S.kxnNzGFAgR UkFmCCJfcZ039QkCsC87DlVV3tTR4vECFmMw1mm0PhRRSmjc2FGa8fHKLSO6 ICcikb1bsV23Znyj7HcrG2LZ8bHQu8A2UjmXS0ZUYk5kUvrhEERYKcRfHL8U rtyaoFCMex79E7tAIwFXmGpkfsiwRsMQ7buxyPf7TEcD4Ay1BY0yoZHYOuU9 ZUq6WXgrWYTt00UN2hGe7ZfU- X-Yahoo-SMTP: Kz_aW1.swBBYof3zAD7.RWzXz9ZAQVDMml1VADsbgPT4Kq79LC0- Date: Sat, 23 Jan 2016 13:02:56 +0000 From: "Thomas Mueller" To: freebsd-current@freebsd.org Subject: Re: libcrypto.so.7 not found, needed (?) for X server References: <930546.92837.bm@smtp115.sbc.mail.ne1.yahoo.com> <26A67E1C-7E42-43B5-8433-D5551350B993@FreeBSD.org> <20160119131844.GS13446@albert.catwhisker.org> <1975711404.11815108.1453209798928.JavaMail.yahoo@mail.yahoo.com> <20160119140611.GC69902@ivaldir.etoilebsd.net> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 13:06:27 -0000 > > root@amelia:~ # pkg info -f xserver > > Shared object "libssl.so.7" not found, required by "pkg" > > What happened here? Bug in new FreeBSD? > This is explained by the UPDATING entry of October 2015: > 20151030: > The OpenSSL has been upgraded to 1.0.2d. Any binaries requiring > libcrypto.so.7 or libssl.so.7 must be recompiled. > -Dimitry I found this but not on the first attempt. Why the #$%^&* couldn't the message have said how to find which binaries require a certain shared library? It's not obvious! pkg shows only those shared libraries that come from added packages but not from base OS. I notice on this list there was a possible plan to make the whole base OS into a package, maybe for FreeBSD 12? Now I could follow the example given under "man ldd". I have updated many of the old ports but have many more to go, don't want to rebuild those already done. I can't find any options/flags in pkg or portmaster to show those ports/packages installed after or before a specified date. I believe portupgrade had such a facility. Tom From owner-freebsd-current@freebsd.org Sat Jan 23 15:55:21 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C97DCA8EAA0; Sat, 23 Jan 2016 15:55:21 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 9439D1297; Sat, 23 Jan 2016 15:55:21 +0000 (UTC) (envelope-from des@des.no) Received: from desk.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 78B445540; Sat, 23 Jan 2016 15:55:14 +0000 (UTC) Received: by desk.des.no (Postfix, from userid 1001) id ED2B5481C2; Sat, 23 Jan 2016 16:55:14 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Julian Elischer Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-security@freebsd.org Subject: Re: HPN and None options in OpenSSH References: <86mvrxvg79.fsf@desk.des.no> <56A2DE54.6070603@freebsd.org> Date: Sat, 23 Jan 2016 16:55:14 +0100 In-Reply-To: <56A2DE54.6070603@freebsd.org> (Julian Elischer's message of "Sat, 23 Jan 2016 09:58:44 +0800") Message-ID: <861t98e1el.fsf@desk.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 15:55:21 -0000 Julian Elischer writes: > what is the internal window size in the new ssh? 64 kB. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@freebsd.org Sat Jan 23 17:15:38 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 41952A8EBBA; Sat, 23 Jan 2016 17:15:38 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::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 0690313B6; Sat, 23 Jan 2016 17:15:38 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-ob0-x22e.google.com with SMTP id yo10so61677394obb.2; Sat, 23 Jan 2016 09:15:37 -0800 (PST) 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=te6EBV6lvTesJvqPRwk1a299/rFdFg3WK4O9b1y/RI8=; b=AuBXXbKimsmhs7EIPkfqX0UJwvaw4Gj4I97YKGbTH8G2dozZB0xjhhKxk/rTx/90xO CFqbg4WNNeO3haC2cSSwQdU+SRqAgr3bPgFrQ2o89+GZ2A2vjGlzDy2eB9VJZ4alNU2M eu/TePVFuXKmdqP5a8qY9Hkr4j6FcgMnHM9BraBMSNdjx0aHKi4ABgBuAJXA5nX3JTbD 45Y83pqR50QVdouv0zGFPUBmXr+U4bXERBxMWZOcuksxgMttpyXbxk+xCt0+yZGcY84g eN8Qa/N5ZTMcXK/VdwounlyPpdZY33pHFAT6dcnFt0srkbXMrhpqZTYw83f3BKBj2EXj wQcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=te6EBV6lvTesJvqPRwk1a299/rFdFg3WK4O9b1y/RI8=; b=WyAet1D6tmMxG2vYxMQ37IaC4fgRAiuSLUq0ATZ1+WSVXbhzOu6bHnfrAot+m+YvZe 1YpGpEsPq7XPO2BW0oBsGZNLQGPtbGTEQuAhSu0c9Cx5eP0Uq30IwGzLTM44fILS1Ebj SUXcmibPX8ljqUxeZ2vlxb6+PELYhcIjGCfTYEzvvUQN80vsWvBTQHQNSgK8t+Ao10EA o35giv+sdLdWklPIiIwo3yG5xzxMSzdmr5obLw9GVELCe9WlqepVeDXpjt8xbYHDiDDc DAcH3izhPoU9JvKDnf9A9ZvulCMMzXuKGWCJ/B3AX42qPXVY6RnPFFexwgy/i77XCcvJ ExTQ== X-Gm-Message-State: AG10YOS5hPZ8MvcHlCuKyE5VHv9LEUvzJZqhWrl+sNHZ7DtBdUGvGFPnfBNYqvj91Yx+rQ5l5AhN38bGkkUeXQ== MIME-Version: 1.0 X-Received: by 10.182.254.34 with SMTP id af2mr7432415obd.60.1453569337032; Sat, 23 Jan 2016 09:15:37 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.202.98.131 with HTTP; Sat, 23 Jan 2016 09:15:36 -0800 (PST) In-Reply-To: <861t98e1el.fsf@desk.des.no> References: <86mvrxvg79.fsf@desk.des.no> <56A2DE54.6070603@freebsd.org> <861t98e1el.fsf@desk.des.no> Date: Sat, 23 Jan 2016 09:15:36 -0800 X-Google-Sender-Auth: YcJCvY639XWh9rYNm2-jkt97KFs Message-ID: Subject: Re: HPN and None options in OpenSSH From: Kevin Oberman To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= Cc: Julian Elischer , FreeBSD Current , FreeBSD-STABLE Mailing List , freebsd-security@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 17:15:38 -0000 On Sat, Jan 23, 2016 at 7:55 AM, Dag-Erling Sm=C3=B8rgrav wrot= e: > Julian Elischer writes: > > what is the internal window size in the new ssh? > > 64 kB. > > DES > -- > Dag-Erling Sm=C3=B8rgrav - des@des.no Are you sure of this? I have not looked at the code, but my former colleagues at the high performance research network ESnet claim at http://fasterdata.es.net/data-transfer-tools/say-no-to-scp/ that the internal buffers and effective window size have recently been increased from 64KB to 1MB an allow for transfer rates of up to 140 Mbps over a link with 53 ms. latency. With the HPN patches, they report 1.2 Gbps, making HPN patches still significant over high latency paths. That said, scp still performed poorly when compared to other technologies (i.e. GridFTP) for bulk data transfer over high-latency high-bandwidth links. (ESnet provides links of up to 400 Gbps between the US and Europe as well as within the US, so this sort of thing is quite important to them.) -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 From owner-freebsd-current@freebsd.org Sat Jan 23 17:16:22 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 30D9CA8ECC4 for ; Sat, 23 Jan 2016 17:16:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 1C215178F for ; Sat, 23 Jan 2016 17:16:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 196B4A8ECC3; Sat, 23 Jan 2016 17:16:22 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 19062A8ECC2 for ; Sat, 23 Jan 2016 17:16:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 09D27178D for ; Sat, 23 Jan 2016 17:16:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0NHGLJg020206 for ; Sat, 23 Jan 2016 17:16:21 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: current@FreeBSD.org Subject: [Bug 194744] [PATCH] allow to specify custom keymap when kbdmux used Date: Sat, 23 Jan 2016 17:16:21 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: op@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: emaste@freebsd.org X-Bugzilla-Flags: mfc-stable10? X-Bugzilla-Changed-Fields: flagtypes.name Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Mailman-Approved-At: Sat, 23 Jan 2016 17:36:13 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 17:16:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D194744 Oliver Pinter changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |mfc-stable10? --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-current@freebsd.org Sat Jan 23 20:33:06 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4FCDDA8FF23; Sat, 23 Jan 2016 20:33:06 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 1B0A510D7; Sat, 23 Jan 2016 20:33:05 +0000 (UTC) (envelope-from des@des.no) Received: from desk.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id AE5195765; Sat, 23 Jan 2016 20:33:04 +0000 (UTC) Received: by desk.des.no (Postfix, from userid 1001) id 2A9B5481E4; Sat, 23 Jan 2016 21:33:05 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Kevin Oberman Cc: Julian Elischer , FreeBSD Current , FreeBSD-STABLE Mailing List , freebsd-security@freebsd.org Subject: Re: HPN and None options in OpenSSH References: <86mvrxvg79.fsf@desk.des.no> <56A2DE54.6070603@freebsd.org> <861t98e1el.fsf@desk.des.no> Date: Sat, 23 Jan 2016 21:33:05 +0100 In-Reply-To: (Kevin Oberman's message of "Sat, 23 Jan 2016 09:15:36 -0800") Message-ID: <86wpr0c9z2.fsf@desk.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 20:33:06 -0000 Kevin Oberman writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Julian Elischer writes: > > > what is the internal window size in the new ssh? > > 64 kB. > Are you sure of this? Sorry, I was thinking of 6.6 (in stable/10). The buffer code in 7.1 supports dynamically-sized buffers with a hard limit of 128 MB. The default window size for client sessions is 2 MB, or 1 MB if associated with a tty. I'm not sure what the maximum size is. Note that scp, sftp etc. count as client sessions. X11 and agent forwarding use different (smaller) windows which improve latency at the cost of throughput. > [...] scp still performed poorly when compared to other technologies scp is a horrible protocol, use sftp or (preferably) rsync over ssh. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@freebsd.org Sat Jan 23 21:23:29 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EFE0AA8F118; Sat, 23 Jan 2016 21:23:29 +0000 (UTC) (envelope-from michael+lists@burnttofu.net) Received: from burnttofu.net (burnttofu.net [IPv6:2607:fc50:1:9d00::9977]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "burnttofu.net", Issuer "burnttofu.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C7ECC1F91; Sat, 23 Jan 2016 21:23:29 +0000 (UTC) (envelope-from michael+lists@burnttofu.net) Received: from kimberton.burnttofu.net ([IPv6:2601:643:8400:3e00::7777]) (authenticated bits=0) by burnttofu.net (8.15.2/8.14.9) with ESMTPSA id u0NLNOgi037999 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 23 Jan 2016 16:23:25 -0500 (EST) (envelope-from michael+lists@burnttofu.net) Subject: Re: HPN and None options in OpenSSH To: Kevin Oberman , =?UTF-8?Q?Dag-Erling_Sm=c3=b8rgrav?= References: <86mvrxvg79.fsf@desk.des.no> <56A2DE54.6070603@freebsd.org> <861t98e1el.fsf@desk.des.no> Cc: FreeBSD-STABLE Mailing List , FreeBSD Current , Julian Elischer , freebsd-security@freebsd.org From: Michael Sinatra X-Enigmail-Draft-Status: N1110 Message-ID: <56A3EF4C.20403@burnttofu.net> Date: Sat, 23 Jan 2016 13:23:24 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (burnttofu.net [IPv6:2607:fc50:1:9d00::9977]); Sat, 23 Jan 2016 16:23:26 -0500 (EST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 21:23:30 -0000 On 01/23/16 09:15, Kevin Oberman wrote: > Are you sure of this? I have not looked at the code, but my former > colleagues at the high performance research network ESnet claim at > http://fasterdata.es.net/data-transfer-tools/say-no-to-scp/ that the > internal buffers and effective window size have recently been increased > from 64KB to 1MB an allow for transfer rates of up to 140 Mbps over a link > with 53 ms. latency. With the HPN patches, they report 1.2 Gbps, making HPN > patches still significant over high latency paths. DES wrote: > The buffer code in 7.1 > supports dynamically-sized buffers with a hard limit of 128 MB. The > default window size for client sessions is 2 MB, or 1 MB if associated > with a tty. I'm not sure what the maximum size is. I'll try to do some cross-country or trans-Atlantic testing this weekend or next week, using a mix of ssh versions and HPN-patched versus not (and CentOS vs. FreeBSD vs. possibly Debian unstable with the 4.2+ kernel as yet another degree of freedom). I'll see what basic results I can get and we can update fasterdata.es.net as necessary. > That said, scp still performed poorly when compared to other technologies > (i.e. GridFTP) for bulk data transfer over high-latency high-bandwidth > links. (ESnet provides links of up to 400 Gbps between the US and Europe as > well as within the US, so this sort of thing is quite important to them.) That it is! > scp is a horrible protocol, use sftp or (preferably) rsync over ssh. I still think over ssh transport is lousy for bulk-data transfers, but it is the one thing that's generally installed by default on every OS and and is allowed by many firewalls. And, of course, it encrypts in flight. Certainly gridFTP, aspera (if you can afford it!) and other packages optimized for bulk data transfer will work better. michael ESnet