From owner-freebsd-current@freebsd.org Sun May 29 00:15: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 57299B4EFDE for ; Sun, 29 May 2016 00:15:01 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d: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 0E79C1B1A for ; Sun, 29 May 2016 00:15:01 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qk0-x234.google.com with SMTP id x7so102372113qkd.3 for ; Sat, 28 May 2016 17:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=from:subject:date:message-id:to:mime-version; bh=cSXtnHIoExfl8eExg52e0teNYGPbILNp6744tqm1X7A=; b=p/YZAApamw4chpZIOuOe0uQQyOUk5LgmMxnHfz/WiIv17gDtuv4LEw1VGCLW10XTtt X9DSSFeQQz7fKHr7uK5VNB1P/gSDZZo5jXuJrsXXMgu7sCmh+BrU9e4QmlbKLqpU3ikB Fb5LVnLVOiWtRjkbsJqgv39fZJzIChCCKgQh+eD/+hDxX+6dU8P/lUI2QMfDv3iOFo2+ HrLoVC+P9SIwVJ+R9Ipok9Ce3ie4ITp1zP9hxTNCmUXn9U7pEG9mrJwCUR3NYWKSIkiZ uDzvUAPZfXAPXXDtHSQZjOlM/q1YvkM4+e0vwKblQmWtgwZ7BxoCRQyxJLWDsYUwYDSs hvNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:date:message-id:to:mime-version; bh=cSXtnHIoExfl8eExg52e0teNYGPbILNp6744tqm1X7A=; b=dq/7Z/Z/I2iUgypdsaWktQH5B20ZiQq/H0a9KvqVW85BaVpkBR3LBnNm1OldHUcwAX mBfH9bNCWG+cf7TBXU2IarHzjd5Q30umIZfrvWrtEYpvsY3B3UbHaarppQjYTBMubi6t EBmgfEdxSc0zJkFPK6OGBLsmUYsxfaqrbj9vduuNEu2xynjoN8QlEk9fABradoN+0mB+ lTnffVkD7MYb/hH7X3ICgN4R+kTnPUkyLIAKy2vATSzRchRwbSIBaCqr6ur+7rixAzik 7/1a1uzUwZ11uNeI5GNhSE/l1P88i86nFqnmpnKctHiEtu1STsslDocmQ1Qzpc7DAI0o X6Ag== X-Gm-Message-State: ALyK8tJWhfikkoMm4T1qfHOCGJrOP14A72UEWLtudIb98pmoM/xqAlBEcTcrDzPwooEMVg/uFdJRSv6DmLZkOZo2C9yPBqgXi/+dM6Arkln/sy2BtWge168m3JHKfg925i1QYQP6MRndzXScti5XBdxWwIBSgn9CD24ZqWjy1ALu3rH1E8y9wro5DUdeZVxWkVGlUSeL X-Received: by 10.55.71.143 with SMTP id u137mr20604765qka.1.1464480900153; Sat, 28 May 2016 17:15:00 -0700 (PDT) Received: from ?IPv6:2001:470:e290:1:fd31:8ca2:3d07:f4dc? ([2001:470:e290:1:fd31:8ca2:3d07:f4dc]) by smtp.gmail.com with ESMTPSA id w110sm4665521qge.43.2016.05.28.17.14.58 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 28 May 2016 17:14:58 -0700 (PDT) From: Shawn Webb X-Pgp-Agent: GPGMail 2.6b2 Content-Type: multipart/signed; boundary="Apple-Mail=_EE25B9B6-C7EF-48C5-BB91-204F42B5E8A1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: installworld woes Date: Sat, 28 May 2016 20:14:54 -0400 Message-Id: To: freebsd-current Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 00:15:01 -0000 --Apple-Mail=_EE25B9B6-C7EF-48C5-BB91-204F42B5E8A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I haven=E2=80=99t had the time to properly diagnose this one. But = here=E2=80=99s a little installworld bug I=E2=80=99ve run into. When = performing the following, installworld fails: 1. Make sure /chroot doesn=E2=80=99t exist, if it does, then `rm -rf = /chroot` 2. mkdir /chroot 3. cd /usr/src 4. make installworld DESTDIR=3D/chroot I=E2=80=99m my case, the chroot is at /builds/updater/chroot. Below is a = link to the log of the error I=E2=80=99m getting. I=E2=80=99m using = HardenedBSD=E2=80=99s source, the hardened/current/master branch. Link to log: http://pastebin.com/titmiNCW Thanks, Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --Apple-Mail=_EE25B9B6-C7EF-48C5-BB91-204F42B5E8A1 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 iQIcBAEBCgAGBQJXSjSBAAoJEGqEZY9SRW7uV0QP/ilijDufCXVUC3Pnd6hvHb50 rn+zLVJ5cmzcDNMWT5m5w87hqIjY5+8I8UVrmhC7N7Cmp8wvXzCU83+bliJqrR8J m7Mm/cRU9wX7IoPizzbwJub0i9wjfB3FLzquZ//8iAdN/eiLahUyqsvZlAwAT+uq iQIeK6ZVSRuKtKw2Kmsl8SgrkrivcgNpddCY22bRrG8HHlNvWlUM2U0u2zA3yZU5 RNTxjk8eVAPJjXI4sDZmEItLI8dHoq5acbGKOVGBtMsiAiuuXKcCDMhJ3oBOXXR5 YEZQLR6MhtRY3bj2+Jv2NUYlJ0KeWFlwfWOs4fk9dY7wqV+VFg2BkQRAJz+wtO/M 1QuAcYMmWCSeBeuKhqZ1kF4P3JRsX9O4LT8By9m8Z+yJXcYKP32zIQnDKMIoYIb8 w2S8jJC4pdjGVz13pnozQpzO4kfbMTox6s/GVfpCyuLY1bYpuEMd5UKZYpVeyGoU YyMcGWxR6/D/50aCRL82gJhJQcjJM35ZACv/YupDnhNdkeFjgWlTxFuHp9JkDXFV EbmixlAeW3oSdeVOw+vb4na/TPTeYklSbV4fK02pVKuJJLqREVxUIoEVqpzVAvCd 2YSNDMaiS2BUKeaWffTMfwOeihMvQqZ7v7GIiszQvvrS4DxrKifilsKutunX8Zxf DjqWkIoW6pYIL93zEuc0 =8YbS -----END PGP SIGNATURE----- --Apple-Mail=_EE25B9B6-C7EF-48C5-BB91-204F42B5E8A1-- From owner-freebsd-current@freebsd.org Sun May 29 00:23:55 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2D63AB452E9 for ; Sun, 29 May 2016 00:23:55 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003: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 E929F1028 for ; Sun, 29 May 2016 00:23:54 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi0-x22c.google.com with SMTP id w184so218001724oiw.2 for ; Sat, 28 May 2016 17:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-transfer-encoding; bh=mDU0co2VIbhUHPx5Bxb+JAni29JGG84nZwlx5f4nS7E=; b=NwcLXotRvb+iiEhUSDTy8VOibC0lD/6HOF5UHM6LrQ46BBjpJGWMwgjbOGMp0dbuMy fXmN16HeEGoLPx4yOTFEH27HOb6y1XSiNH0evwiJ4fehL5EfeYeDyhz/3BuzMW5FAG6c HA9bCuPJgULt383d09yaFUcrl8wltEfuEey5xQzoZg0gpS4n6g6Mf+9Bt341Wqat/V1t DDoyqCBKbZDyMFlxwEGn8WhjY7WzBIY0rp+9Upzp/ijbw7DUtNVK3e14WPKbF6HU7jwp H0b8yK90ZoSRFMl+QkANftzZi7y/L53DXrQ8KBHGRAdHwDdrDwKHXzuRhaPVZD2lZxFO PesA== 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-transfer-encoding; bh=mDU0co2VIbhUHPx5Bxb+JAni29JGG84nZwlx5f4nS7E=; b=b5oxqIyDx7wpKZWBHCqUl1r9o3w1X/OW4/dK9I31A6OKX0JWoBC1gDOA2N6EWiSCf6 O9wpykcGzpSbSMZK2h1Ik9YWxmkhANG8mA3CEz8WDV0Z04GwO+UuQgCgFOOvoegxM9W3 L0jdT4ZKPME8R/ReniafdYo8GKYEJmgXnCgkctWKFec/t4wbO6pGSEPsjdjj+/K5TgJ/ ODD/xwAjSNPDpD9ucePl745WiqKy/3mjGCeX8P4avybKBMgD/CNM+qZT1aivQpMkJP8L A3C3BfKr36NUEworp6aENw9mLgoHAyHDuZWQnnHdLVtzGEqYGMRFdlAO8zg9k1bw+alo FjTQ== X-Gm-Message-State: ALyK8tLAEF51k76C1skxgyDdvIKBD1IwqLDHE7SYcy7/BbQX15Nmt9c0X9LPMDBEM5gTjgjeDC5q1cHUK7ka/A== MIME-Version: 1.0 X-Received: by 10.202.94.132 with SMTP id s126mr14126172oib.34.1464481434347; Sat, 28 May 2016 17:23:54 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.202.4.200 with HTTP; Sat, 28 May 2016 17:23:54 -0700 (PDT) In-Reply-To: References: Date: Sat, 28 May 2016 18:23:54 -0600 X-Google-Sender-Auth: 3bRhqxTO-NMmwozt0I52ZWkTwb8 Message-ID: Subject: Re: installworld woes From: Alan Somers To: Shawn Webb Cc: freebsd-current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 00:23:55 -0000 On Sat, May 28, 2016 at 6:14 PM, Shawn Webb wr= ote: > I haven=E2=80=99t had the time to properly diagnose this one. But here=E2= =80=99s a little installworld bug I=E2=80=99ve run into. When performing th= e following, installworld fails: > > 1. Make sure /chroot doesn=E2=80=99t exist, if it does, then `rm -rf /chr= oot` > 2. mkdir /chroot > 3. cd /usr/src > 4. make installworld DESTDIR=3D/chroot > > I=E2=80=99m my case, the chroot is at /builds/updater/chroot. Below is a = link to the log of the error I=E2=80=99m getting. I=E2=80=99m using Hardene= dBSD=E2=80=99s source, the hardened/current/master branch. > > Link to log: http://pastebin.com/titmiNCW > > Thanks, > > Shawn Webb > Cofounder and Security Engineer > HardenedBSD > > GPG Key ID: 0x6A84658F52456EEE > GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE > Can you please send me your copy of etc/mtree/BSD.tests.dist? And did you set anything like WITHOUT_TESTS=3D1 in /etc/src.conf? Also, what exact revision of HardenedBSD are you using? -Alan From owner-freebsd-current@freebsd.org Sun May 29 00:26: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 F342CB45418 for ; Sun, 29 May 2016 00:26:53 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ABA3C127B for ; Sun, 29 May 2016 00:26:53 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qk0-x22c.google.com with SMTP id x7so102455403qkd.3 for ; Sat, 28 May 2016 17:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=dN9x1KZ5Rfx8Hvvc2tMh7xCyNjXXdbPxjFGdk9Dxefs=; b=PLKYA3g9jI5XyEy1Nvo467z66soGCrYSZpSN5Mq4C2avXSaKzEMQB6JGbg1Uh2INQT 8kz60yfu2xqfl0Se6RuR43FjN0hsb+9e6QHtOc1VTDWyDeRXL2l/unpwa48c3uZqeAmL Lvo35wn98iPKkkldhz813c5KCUCUeK/46W35yqPluuEbhNXpp5STcGYiOrfPWZUorOtS QUY+z2UfTOR65oIqSu+EWucQU9I3uWGo23ZY382S59F+JcZHO5grdk2UNt+ACTCNd+8y k91fdAV01vMpUE9Rzk/sXdmUDFkrgH2t5+xlxbFKYTFgvsoU4JucfDgbgqAkqaFNfBLg Ys7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=dN9x1KZ5Rfx8Hvvc2tMh7xCyNjXXdbPxjFGdk9Dxefs=; b=PxVYEdXRrl0mJP41cd1/abQZ1aKau9J7lvceoakXInZjBMjmac6tNAJ9tE2nt9bzFg WXt2wCRDCC4JusIk/NLiVlUkHH+OPbkfDXeO+ZroCnCGFCYTSI+UOkY+k6OZtgAXbAcB ByWkpc9i3lk2L22U8Y3tpSY0RCFz1jKh89L4hw21MygCeSdFWPOHH1mzpkXZNg4+YkCD 81ZMDrKrqe63fX5+ii9/gyY1JFZNUCRPGh58LO+drrh8Ki3KnMH4etsNT6q77DdBsWU2 /ZjTKmOf16v0TSrvqeYyUWi3j23kAN8Eo/f3SbljIWamn2GedeBMExRsnYtV4XOqNuWk 9voQ== X-Gm-Message-State: ALyK8tI85oA1rtu4NGeCWnO0w/jMvt+I+evCKquB5Z1m2ZZoq5laCYyZiQsVLzatFD6YBXDL X-Received: by 10.55.54.85 with SMTP id d82mr20097149qka.57.1464481612769; Sat, 28 May 2016 17:26:52 -0700 (PDT) Received: from ?IPv6:2001:470:e290:1:fd31:8ca2:3d07:f4dc? ([2001:470:e290:1:fd31:8ca2:3d07:f4dc]) by smtp.gmail.com with ESMTPSA id 5sm7370444qty.48.2016.05.28.17.26.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 28 May 2016 17:26:51 -0700 (PDT) Subject: Re: installworld woes Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_B8972126-1634-493C-8740-FBC0DBF3B3E3"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Shawn Webb In-Reply-To: Date: Sat, 28 May 2016 20:26:46 -0400 Cc: freebsd-current Message-Id: <75323DF7-8112-47B8-9E9E-93FE90030A16@hardenedbsd.org> References: To: Alan Somers X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 00:26:54 -0000 --Apple-Mail=_B8972126-1634-493C-8740-FBC0DBF3B3E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On May 28, 2016, at 8:23 PM, Alan Somers wrote: >=20 > On Sat, May 28, 2016 at 6:14 PM, Shawn Webb = wrote: >> I haven=E2=80=99t had the time to properly diagnose this one. But = here=E2=80=99s a little installworld bug I=E2=80=99ve run into. When = performing the following, installworld fails: >>=20 >> 1. Make sure /chroot doesn=E2=80=99t exist, if it does, then `rm -rf = /chroot` >> 2. mkdir /chroot >> 3. cd /usr/src >> 4. make installworld DESTDIR=3D/chroot >>=20 >> I=E2=80=99m my case, the chroot is at /builds/updater/chroot. Below = is a link to the log of the error I=E2=80=99m getting. I=E2=80=99m using = HardenedBSD=E2=80=99s source, the hardened/current/master branch. >>=20 >> Link to log: http://pastebin.com/titmiNCW = >>=20 >> Thanks, >>=20 >> Shawn Webb >> Cofounder and Security Engineer >> HardenedBSD >>=20 >> GPG Key ID: 0x6A84658F52456EEE >> GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 = 6EEE >>=20 >=20 > Can you please send me your copy of etc/mtree/BSD.tests.dist? And did > you set anything like WITHOUT_TESTS=3D1 in /etc/src.conf? Also, what > exact revision of HardenedBSD are you using? >=20 > -Alan Hey Alan, Both make.conf and src.conf is empty. I=E2=80=99m at commit = 41e51b23103daca5c5cdbfa894f1166d07f87c15 in the hardened/current/master = branch. Here=E2=80=99s etc/mtree/BSD.tests.dist in my src tree: = http://ix.io/MiS Thanks, Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --Apple-Mail=_B8972126-1634-493C-8740-FBC0DBF3B3E3 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 iQIcBAEBCgAGBQJXSjdKAAoJEGqEZY9SRW7uL6cP/AqZIc1qK3KaaWJWDq8CBZ5Q OgQ8+z27OPJHmgPPXobrMPMbc+yA8frthwifuMPfV9BM0jB7EoHeBYdfkER/mFOb 22rbg7g2M+t+lWtUPaq0rQqH/8gaH+N0NPQq5MEBniloTbdX6ipUL5MV9fbIJUrx WlWZHhqgTS7Sb8VnjtD1YtTbtpeYzdqGtn7jxjmZHbXof3ENat8d3eBS51mAs6vA K2Oml83cauqR+FcDr3ov79e8Bkp4iDKxqw2S+cnHyS21R5BROsHbKmlEd0XrmHbi 7/hTYjHDFOyvrlVPI/NwehTMiBaLMUeGGi4uOA4VLdVJm/9D03wQ2Mph6nrrZni0 75RBX1k3eT2h54iYfXo49keB+buNLMgkxg2pYZubg3q2faCnd+EdTw+0+L2/Bne1 FAcae8NZTt8RZHxlMhyYMhJ3/1Y2mx0jp6nRE0WsAmiQtjGPgrHzWJnzlhJ2Xr0k bj18zRkFiJtupGqXUUERZ2WiZtF8bC65BcU0D3TVyFeNNOGahccwDzFNWyId2dbK nJZBMBY+Mp+h2DyCWhHGZt/qUkEofvN0DrCSdPVWk0XU8QZE6ujvYRhzrWjc+nfR g8FK9YQKO4yHeeqBWAo0Z9nVf43D2eVt/2txNhPZl+rnmumwM79K8feMgWhzsVnT BlFOnlAuYeonyndkcNqg =JhF8 -----END PGP SIGNATURE----- --Apple-Mail=_B8972126-1634-493C-8740-FBC0DBF3B3E3-- From owner-freebsd-current@freebsd.org Sun May 29 00:29: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 24E7CB454E2 for ; Sun, 29 May 2016 00:29:40 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::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 DEFB713E2 for ; Sun, 29 May 2016 00:29:39 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi0-x233.google.com with SMTP id w184so218083857oiw.2 for ; Sat, 28 May 2016 17:29:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-transfer-encoding; bh=FvH98AmRNW7m6kn3iSUxXBFusvJ9u8xaarrpYyUSfIw=; b=YkTsLFewFxwVmXZth4maiRwNzEdyOhMYrn+wy3WU19Nt8gQmcXu7M8QOJ9Z+Mo1/Iq ikNF8K59qxMBohYsuqgjnVTyR7rJCG2nI6zGW1JBYWiUz+rzSXvtyO1FwQYHj9/ewegv 6aRTg1QodEqNirJRJAPXxiKqxl7usyKosYFl97CCD5RJlBzPX4AsIrveDY7VM1PNBx/z hdfXPjUQwPDZY18bUMaMJ63RQTpor2PlLsMKAoSRedVX62UN+o5zChiSomZnfuHsmh9n eSaGh+7FfKOBm/peNV6jFL1IOcUbyHGKikpNDt6H61d3pTscHVxn2h+5Bj5bdv424aql 2Kow== 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-transfer-encoding; bh=FvH98AmRNW7m6kn3iSUxXBFusvJ9u8xaarrpYyUSfIw=; b=hgFN5AvYMJSj/VO0CwOOtHLdzxf4ubpQ5vIgRngyDk1SWyVFhwBQxrg2hvpRbOMzp8 9merVUM7pr8B1hPDFY9CCCacKxBKg2XBRxqanHtniy3IMNXf2ajE9ToAlaWcKt12Y5H2 yG6CqHtfJ55hzJ0CGjZD2DutroTpBLBgOtYUipSosqSt9YCVoehHRNpkYxiyoMF8qkaw yu9NnzDHyw1FemnFuFrVvxEHc2puoe+gNWSfSvyPaEU4t+cCA15FogD1f8uIhOTnXBUf xt0pa3We4ZDtgsNhHnG8ADWleFodErqYFBrUmnYR/BuYkZ+Z5g5nTQqdEr9j2pFEjuME WYVA== X-Gm-Message-State: ALyK8tL13fQFi+6YzXLA9UQR7U9hvih9jWYQ9LewZgBYy+pLbniua6VTVRtvXJy5hy2T5EdXqDIYXe+ZrXnuHw== MIME-Version: 1.0 X-Received: by 10.202.206.76 with SMTP id e73mr14369481oig.173.1464481779252; Sat, 28 May 2016 17:29:39 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.202.4.200 with HTTP; Sat, 28 May 2016 17:29:39 -0700 (PDT) In-Reply-To: <75323DF7-8112-47B8-9E9E-93FE90030A16@hardenedbsd.org> References: <75323DF7-8112-47B8-9E9E-93FE90030A16@hardenedbsd.org> Date: Sat, 28 May 2016 18:29:39 -0600 X-Google-Sender-Auth: d5X6s_KC1K7oDJf0BfMKt0RTVMY Message-ID: Subject: Re: installworld woes From: Alan Somers To: Shawn Webb Cc: freebsd-current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 00:29:40 -0000 On Sat, May 28, 2016 at 6:26 PM, Shawn Webb wr= ote: > On May 28, 2016, at 8:23 PM, Alan Somers wrote: >> >> On Sat, May 28, 2016 at 6:14 PM, Shawn Webb = wrote: >>> I haven=E2=80=99t had the time to properly diagnose this one. But here= =E2=80=99s a little installworld bug I=E2=80=99ve run into. When performing= the following, installworld fails: >>> >>> 1. Make sure /chroot doesn=E2=80=99t exist, if it does, then `rm -rf /c= hroot` >>> 2. mkdir /chroot >>> 3. cd /usr/src >>> 4. make installworld DESTDIR=3D/chroot >>> >>> I=E2=80=99m my case, the chroot is at /builds/updater/chroot. Below is = a link to the log of the error I=E2=80=99m getting. I=E2=80=99m using Harde= nedBSD=E2=80=99s source, the hardened/current/master branch. >>> >>> Link to log: http://pastebin.com/titmiNCW >>> >>> Thanks, >>> >>> Shawn Webb >>> Cofounder and Security Engineer >>> HardenedBSD >>> >>> GPG Key ID: 0x6A84658F52456EEE >>> GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE >>> >> >> Can you please send me your copy of etc/mtree/BSD.tests.dist? And did >> you set anything like WITHOUT_TESTS=3D1 in /etc/src.conf? Also, what >> exact revision of HardenedBSD are you using? >> >> -Alan > > Hey Alan, > > Both make.conf and src.conf is empty. I=E2=80=99m at commit 41e51b23103da= ca5c5cdbfa894f1166d07f87c15 in the hardened/current/master branch. Here=E2= =80=99s etc/mtree/BSD.tests.dist in my src tree: http://ix.io/MiS > > Thanks, > > Shawn Webb > Cofounder and Security Engineer > HardenedBSD > > GPG Key ID: 0x6A84658F52456EEE > GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE I'll fix it tonight after I get the kids into bed. In the meantime, you can roll back to before this commit. https://github.com/HardenedBSD/hardenedBSD/commit/442baa51845cf38dbcfdc44bd= 8493defdaad630a -Alan From owner-freebsd-current@freebsd.org Sun May 29 00:31: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 8D074B457E9 for ; Sun, 29 May 2016 00:31:39 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::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 4574418F0 for ; Sun, 29 May 2016 00:31:39 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qk0-x233.google.com with SMTP id h185so66384854qke.2 for ; Sat, 28 May 2016 17:31:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=PZhcRXHS5x5+xqpPJsLzgexNAMfw+itPDyEQFFRmaAw=; b=po4mPeWQ61R2CaQuOTZUBSW12CAPjEfW9vBdn3M3DvM1PLD/pwrI/9r8fyJs2PTo8K rwGABsr4yuoM2wRJodpnzCsxleEeXL6ya+C5S1t/V6q0+iGNYny+gXC1h7FG/K2QDFou a6Vn+HoIEbmRW/Va0+uqNIo8pOnOrJVn/9Mgw01eqeFvLs48Ky4KlvVn+AR0UgvfnmmF /0X/BzebprpRN2gAhbtbRt5hkGC6rVuCQUKyeF8OyWP6WeP4cs7tMKUxF8GSH/B55LAp BGyr1hv5m+0UPxrol5JSW8rHWyRQY6B3jt742pDax71Xg+Yx11NNB4bu7VtEGyS10OjR UHSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=PZhcRXHS5x5+xqpPJsLzgexNAMfw+itPDyEQFFRmaAw=; b=etUCDXfMeIJoxWB4UJ/P0U0cWunn6sI6y1QIqWxBx5nxjGRWmXAOG/c1fh4GptkCJ0 q422IC28ktscXjYBJKRDC+bA1E0rjD7t+f59RV0w9647G6pC46hg1FoD1Qj2gBWZ1v6P LAEBb0La7JWQ2/RkRHnokAZSsceS762gSle/ZmAwVyxzKzZcS0u6/ZDXDCW17PLPdfL5 y3/mc5qs6sBp1G2/jX+njA0BJE0+/JHmIs41cdrJ6ICcLalUN4Q+HTcxOojg75TbYC3s 9EJ3aHoGA6BnieuuviCQNprDwE+5Uj3vrwmYKOQM1RvWF2qNhtprJhN3O4qa3DHDWAxJ Gguw== X-Gm-Message-State: ALyK8tLmzkR6TOar9/qUaqoePLAXBo1uepv9fcj2vjah0GDkyb5UQeD2alxy3N58umnpGNd5 X-Received: by 10.55.178.6 with SMTP id b6mr21475326qkf.70.1464481898414; Sat, 28 May 2016 17:31:38 -0700 (PDT) Received: from ?IPv6:2001:470:e290:1:fd31:8ca2:3d07:f4dc? ([2001:470:e290:1:fd31:8ca2:3d07:f4dc]) by smtp.gmail.com with ESMTPSA id y186sm7384622qha.20.2016.05.28.17.31.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 28 May 2016 17:31:37 -0700 (PDT) Subject: Re: installworld woes Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_0CDF2133-9F85-4EBA-85EA-80053A25EEB8"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Shawn Webb In-Reply-To: Date: Sat, 28 May 2016 20:31:36 -0400 Cc: freebsd-current Message-Id: <6F250A1F-70FC-45C6-847A-3E8E07963E5F@hardenedbsd.org> References: <75323DF7-8112-47B8-9E9E-93FE90030A16@hardenedbsd.org> To: Alan Somers X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 00:31:39 -0000 --Apple-Mail=_0CDF2133-9F85-4EBA-85EA-80053A25EEB8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On May 28, 2016, at 8:29 PM, Alan Somers wrote: >=20 > On Sat, May 28, 2016 at 6:26 PM, Shawn Webb = wrote: >> On May 28, 2016, at 8:23 PM, Alan Somers wrote: >>>=20 >>> On Sat, May 28, 2016 at 6:14 PM, Shawn Webb = wrote: >>>> I haven=E2=80=99t had the time to properly diagnose this one. But = here=E2=80=99s a little installworld bug I=E2=80=99ve run into. When = performing the following, installworld fails: >>>>=20 >>>> 1. Make sure /chroot doesn=E2=80=99t exist, if it does, then `rm = -rf /chroot` >>>> 2. mkdir /chroot >>>> 3. cd /usr/src >>>> 4. make installworld DESTDIR=3D/chroot >>>>=20 >>>> I=E2=80=99m my case, the chroot is at /builds/updater/chroot. Below = is a link to the log of the error I=E2=80=99m getting. I=E2=80=99m using = HardenedBSD=E2=80=99s source, the hardened/current/master branch. >>>>=20 >>>> Link to log: http://pastebin.com/titmiNCW = >>>>=20 >>>> Thanks, >>>>=20 >>>> Shawn Webb >>>> Cofounder and Security Engineer >>>> HardenedBSD >>>>=20 >>>> GPG Key ID: 0x6A84658F52456EEE >>>> GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 = 6EEE >>>>=20 >>>=20 >>> Can you please send me your copy of etc/mtree/BSD.tests.dist? And = did >>> you set anything like WITHOUT_TESTS=3D1 in /etc/src.conf? Also, = what >>> exact revision of HardenedBSD are you using? >>>=20 >>> -Alan >>=20 >> Hey Alan, >>=20 >> Both make.conf and src.conf is empty. I=E2=80=99m at commit = 41e51b23103daca5c5cdbfa894f1166d07f87c15 in the hardened/current/master = branch. Here=E2=80=99s etc/mtree/BSD.tests.dist in my src tree: = http://ix.io/MiS >>=20 >> Thanks, >>=20 >> Shawn Webb >> Cofounder and Security Engineer >> HardenedBSD >>=20 >> GPG Key ID: 0x6A84658F52456EEE >> GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 = 6EEE >=20 > I'll fix it tonight after I get the kids into bed. In the meantime, > you can roll back to before this commit. > = https://github.com/HardenedBSD/hardenedBSD/commit/442baa51845cf38dbcfdc44b= d8493defdaad630a >=20 > -Alan No worries. No rush here. I appreciate the help! Can you add =E2=80=9CRepo= rted by: HardenedBSD=E2=80=9D to the commit log? Thanks, Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --Apple-Mail=_0CDF2133-9F85-4EBA-85EA-80053A25EEB8 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 iQIcBAEBCgAGBQJXSjhoAAoJEGqEZY9SRW7u23QQAL/F06cQFYElH0cVKkT1XFxv gvJzMxy+ue6BrV2OiDIxDDcfx420Imycr6+VlG98b+RiU45j/KQ+mjCFCe3oTMjE /TJLtkymUpUXg76+2q6hCuxtgvjskDtkZgGV4CB+JzZTcVMw9o3V1BHb7AnDMjl4 aibcoJpl5WmhnttihlL/l8+Y4/dA9wUrPqZ90F45sRcWxnGRIZVBwzQxrBe8sVPG oXv0c02ocTIsS4Y36n89dq46ALVKX5WAUY4vrdUfJp55AVurBjRiHgz7V0V8Ztu0 Plkclzl1aK0E7wIbKJ36KLCoYHopZ3noi5/25j1E8LVHdmt2f6nTrex6ICVYdnTa IKX0NU+VO8MQPTSy8xHG/8661CWz9pZdsgEyJKJDMKEF/ju0grK/3AeQb+7GcOay wOjLmxzuBli5Wv0OzRLWgmqPhY7ugDY+O/I6nMF+rYPWAg2w8GHD7yKlb/mS/061 39Ig0y6Ylr7m5QGUCgX5OOfJn0BD1nyjl4scce9DDEw7HirYZGK0r8PK1AE2bswW 5MfbDffpQz54Wnv/G51Kf0wzm0X6wcvziNrNpZnITlAX/xpGu4ovN7tk5Redn+GF Bn/a1zum2a/BB8QdVwC83MKa0dwagliygGwImjymcbCcgDZYcFNJG19GF2k03Imc S0dYRfETTl/1oLP5UXFL =csjC -----END PGP SIGNATURE----- --Apple-Mail=_0CDF2133-9F85-4EBA-85EA-80053A25EEB8-- From owner-freebsd-current@freebsd.org Sun May 29 01:38: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 8EA59B4FD8C for ; Sun, 29 May 2016 01:38:50 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 605BF1E63; Sun, 29 May 2016 01:38:50 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pa0-x234.google.com with SMTP id bz2so21500389pad.1; Sat, 28 May 2016 18:38:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=8aF7tNMn9YqNe25cTFlxHx+aCyvtYXThQmac/cR0dhs=; b=dV6oihLsRhqxf9FYf/HLc5rW7mGr6ohJFyA+snZJPLqBMQ08aWY9Ty1QY9hfAH8b6Z soYgCShWLjXlFkTLzqIwkAagrtC+R1vImVeB4OxKnuv5tpiqsak3ExdkBxvAqDFdfo1T XELjPIW5Q6QRz/Pc6q7OUIcX9n+F1n/lTu+tEGdWw9KcyFFlYsO0Rp2rB6ppeQwINS7V godTZQslOC7nOijwUCnIfiTUWZNcJvTuoqZ15tmzcpG3mZfwZXbBN8JkBkpG0dgbWW3f HUITnm2OdLK0ziWLNLyHCHRgEdNI37nDLWWCz/r2bj1XQLG4fmo1imBQAKFFL5g0bOdZ 25gQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=8aF7tNMn9YqNe25cTFlxHx+aCyvtYXThQmac/cR0dhs=; b=aaqVU59rZFfrM8xMh8SBxKZFNSsxy7+RDw8czt1Nl0Qgmem1GZzGCAfhOsJxihEIyz OdXs9kiEqGVkqoucwW29ZogAALnvrDkQxYkv52gotuJBwrrG0kgVgTmCWxd056IYP3M0 Iw+/8Nhl8uNkl/5UXQ4FUhh/ckg1RSaoyD6Prn0nMxrfkEpvoDyKiRaghuVP1Cgm6q/R MIEOX5XIEYYIp+eMRi/fpkTg423ny3yqV+5xs4S3IP5234nYrcoakU8a0uEAIb6xSeBY SGmGEvbbUESHFE8kdsEt0N6ArMBK0zeOXL/TP7aqUndhYeypioKizXYYbLsDy40PpMP3 nobQ== X-Gm-Message-State: ALyK8tK9jTY41uLFnqfOO4XglO3JqW65vn3U6xFVgFY1cBm5TD0G7v4q3CYadrDOLdHXSg== X-Received: by 10.66.27.231 with SMTP id w7mr34578976pag.45.1464485929831; Sat, 28 May 2016 18:38:49 -0700 (PDT) Received: from pinklady.local (c-73-97-222-46.hsd1.wa.comcast.net. [73.97.222.46]) by smtp.gmail.com with ESMTPSA id 66sm23162106pfb.64.2016.05.28.18.38.48 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 28 May 2016 18:38:49 -0700 (PDT) Subject: Re: installworld woes Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_C05F167E-FA6F-4B29-BFD3-7D8BD6C0821E"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: "Ngie Cooper (yaneurabeya)" In-Reply-To: <6F250A1F-70FC-45C6-847A-3E8E07963E5F@hardenedbsd.org> Date: Sat, 28 May 2016 18:38:45 -0700 Cc: Alan Somers , freebsd-current Message-Id: References: <75323DF7-8112-47B8-9E9E-93FE90030A16@hardenedbsd.org> <6F250A1F-70FC-45C6-847A-3E8E07963E5F@hardenedbsd.org> To: Shawn Webb X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 01:38:50 -0000 --Apple-Mail=_C05F167E-FA6F-4B29-BFD3-7D8BD6C0821E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 28, 2016, at 17:31, Shawn Webb = wrote: =E2=80=A6 > No worries. No rush here. I appreciate the help! Can you add = =E2=80=9CReported by: HardenedBSD=E2=80=9D to the commit log? Fixed in r300922 =E2=80=94 thanks! -Ngie --Apple-Mail=_C05F167E-FA6F-4B29-BFD3-7D8BD6C0821E 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 iQIcBAEBCgAGBQJXSkgmAAoJEPWDqSZpMIYV2hoQALr+5w+8QSMF3fga+KKE8NMN AlFjouGY8Qecaohhe8q2KAmC5GfarQz9AVYK8eoDh6Qp3SaSSyUZmk1fkZM00/DP 2vLTr1MkqTPr821qzYc6mFX+/NcEqjNMxcVqOFZS0bXR4Ddz4gdE0Bq/4cFQvflH Q9g6TyAhC5n+to5XorlAUe+XXEvenTcpRIK5Wow17baAlLmwMFBamgqXuUurZASG X/hszoxh5179K1ebxP985XETBueuzXpew0+D47tOd1ID6/CVolDVilaNpNpHcsDw sm0GgkVhgGtDI0K9Wq4D2h1fCPPlNrJyeV9zBaTmfySNgxH5TUwaxKKfUULGt/bD LLGy2I/JrCgqeksVhlNpO4RHX2a9Q765mmCMLO8sWGM665OKFfqLMBzHSfvGLTsD CCLim4NCqYVWRYYGU0Uc6JkRtLrCN4VySwDXn4f2pmfp6+16ZIYitaUpGW61hhpa HhHhoQ9wFhcuuNiQ2NNRxiayISr0m9jsENDuWN/9/Ftebv6jwse0U2QMtf7kcbg7 fdPzeDV6k0C6qanDtcpvk0DzEbReow5uTtyf+F+3Rkhns0fiSxMK36qvP01Khsws MiEiNnKHjnVHTM2xIjZnPMICrGouJxUnTDXva3eunx2ZG0OSYRlISYhLSBwjfvAV ai0UzyamwqjvEyzo5snQ =c/aQ -----END PGP SIGNATURE----- --Apple-Mail=_C05F167E-FA6F-4B29-BFD3-7D8BD6C0821E-- From owner-freebsd-current@freebsd.org Sun May 29 04:13:58 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CA077B532E9; Sun, 29 May 2016 04:13:58 +0000 (UTC) (envelope-from bryan-lists@shatow.net) Received: from mail.xzibition.com (mail.xzibition.com [52.11.127.251]) (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 A81BD1DAB; Sun, 29 May 2016 04:13:58 +0000 (UTC) (envelope-from bryan-lists@shatow.net) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 614D41E851; Sun, 29 May 2016 04:13:51 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id e5Wzyzv_T25p; Sun, 29 May 2016 04:13:48 +0000 (UTC) Subject: Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build) DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 28BC91E84A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=shatow.net; s=mxc204805312015; t=1464495228; bh=gHxuIR5q7ZWJFkMpm9CTZo55bX2XpwKg7/NmoyrlL9k=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=jDBzpZ5r8GoH4cuEky+0z8fBk6b36RXzg6l8WRkWoLz5Br5Ei/rwgVhe2zkPPfNPT arfzDsnzCy7WcO9Wic8HS9zPhG/h8kNfwKCXFdOJ5YFULnBGckTvPTV/8hC6Y65Elk qwODhTKVL6yFZY8D9fawnd0/X9nJSCcaLJY0kxwcwoGl3TrONLzIN48vczr909lFLT 0Mbz+sE3auTVvRJwTsbtIzebQeapFlXNCsOCgixR34ApzOFCUYBdYXK/tHHjY7iTJy OysPUuUUY+ka4uHXJsQoNxsTnSsQk0LRhSkgODNSHQwUJinaMJ2+no4txUy09iad8/ rI0nwroxlBhDw== To: Adrian Chadd , Mark Millard References: <5A0ACA76-6F1D-4975-9E59-2A64BB8EFC77@dsl-only.net> <56FD9757.6040709@FreeBSD.org> <9E3033D5-F416-4B78-97C2-0A0AABF5A49E@dsl-only.net> <56FDA5F9.1090601@FreeBSD.org> <481DA341-0DFC-4AF1-AD4D-56C5388FA8E3@dsl-only.net> <56FDBAA8.5060407@FreeBSD.org> <7DEF97EC-D970-4F64-AF72-8939609A1D48@dsl-only.net> <4953F764-FC4E-491F-A6B7-4CAF65EAAEB7@dsl-only.net> <70a54660-775d-c12c-b991-507d26ce1342@FreeBSD.org> <72F5F9FD-5854-455D-8844-C4E1887DCE9F@dsl-only.net> <0FA52C68-43C4-489D-9EB2-2339C2B812F5@dsl-only.net> <068D322F-E46F-4FD8-8DA0-BD7D17FD2A06@dsl-only.net> Cc: Bryan Drewery , FreeBSD Current , FreeBSD Toolchain , FreeBSD PowerPC ML , Gerald Pfeifer , Warner Losh , Dimitry Andric From: Bryan Drewery Message-ID: <0f681095-9876-cb42-b158-7420174c0409@shatow.net> Date: Sat, 28 May 2016 21:13:54 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 04:13:58 -0000 On 5/28/2016 12:03 PM, Adrian Chadd wrote: > [snip] I beg of you to *stop* snipping all context. > > hi, > > please don't patch the ports compiler assumptions about things like I said it was not right, and was an experiment. > this. We should be targeting external toolchains on OSes (eg macosx) > where it may already generate freebsd binaries and as such we should > be calling the compiler/linker with all the flags it needs. > > Having a patched compiler default for mips made things way, way harder > than it needed to be. > > -- Regards, Bryan Drewery bdrewery@freenode/EFNet From owner-freebsd-current@freebsd.org Sun May 29 03:55: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 5982BB500AC; Sun, 29 May 2016 03:55:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0BF221E9B; Sun, 29 May 2016 03:55:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x22e.google.com with SMTP id t40so92866533ioi.0; Sat, 28 May 2016 20:55:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=2GtFzeJ86K7vfz1Tgc3Gacxik7q8YBKpnHK6g/jBy4k=; b=BGNx56Wd8gIhs+XJQIdNadvCW5rTgSwUEAFq3s4UD7GQH5MN8bU0Gr1D2wpu3E51+q RNlAKQeHFBDEuWk8NTGQy2FVgOdCxj4dw8e2RLLuzPKnFzJyrbViIGt+gl3dFN35EojN OWyb9xlBd0noBldAEPzyJqrI+7meI2m2+VRBtS+QCCfgnSqVUeUuIgB+yD8+uBUltqIX S2jUa+IlLY5bjdrrBY/3LE0Zdu+OAtpQGzCGgsq/O7fhnamCyhpF2RGYrJHT5+KT30Tt PIKMGUnpQNgLUZIvFrplUezV78oncWB7FwsJGp+1md2ZLGblfUWBcNbMJqWmrt7YGCDS MhVA== 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; bh=2GtFzeJ86K7vfz1Tgc3Gacxik7q8YBKpnHK6g/jBy4k=; b=THS5P7yGlAeo389M0anwaHUZ1UH1tL8q2u/mjNjm/iN1Riw9Y8kilsyGd/kjwf7JqI z1iLfhQ2awKwtlsf1DiqcqaQxwgJyswll/p+n1yTmWIGJC891+TPGzMnnwQhkW2cOPRQ 8Fr+WkZiI99yHrigHAkXjoWV5FEbQ7LbBE21XiMCOFoxRXIIzXS/xsoh2zCc+rVsqEyB DygtN7K2aqymgfey6W9xZRQYnzdx856x2fxAe/tB4lW+TwgSkOi8xIViTBMDgp8owhRw 5GVkoeIuva7xPubYfR1Gv15aXqrmLpEEMo5gkySmLTSJ8ohHW8t8V29vb76xMgkUr/Nm w0Hg== X-Gm-Message-State: ALyK8tIwXq7wwYdytp8nxn5gLw3qyem0d6CNZvn5bLkBSm7s3Q6yRsiFbWBKtOC+PluVDbRuEczt1kPreCsM+g== MIME-Version: 1.0 X-Received: by 10.107.15.234 with SMTP id 103mr18461765iop.75.1464494156467; Sat, 28 May 2016 20:55:56 -0700 (PDT) Received: by 10.36.113.3 with HTTP; Sat, 28 May 2016 20:55:56 -0700 (PDT) In-Reply-To: References: <5A0ACA76-6F1D-4975-9E59-2A64BB8EFC77@dsl-only.net> <56FD9757.6040709@FreeBSD.org> <9E3033D5-F416-4B78-97C2-0A0AABF5A49E@dsl-only.net> <56FDA5F9.1090601@FreeBSD.org> <481DA341-0DFC-4AF1-AD4D-56C5388FA8E3@dsl-only.net> <56FDBAA8.5060407@FreeBSD.org> <7DEF97EC-D970-4F64-AF72-8939609A1D48@dsl-only.net> <4953F764-FC4E-491F-A6B7-4CAF65EAAEB7@dsl-only.net> <70a54660-775d-c12c-b991-507d26ce1342@FreeBSD.org> <72F5F9FD-5854-455D-8844-C4E1887DCE9F@dsl-only.net> <0FA52C68-43C4-489D-9EB2-2339C2B812F5@dsl-only.net> <068D322F-E46F-4FD8-8DA0-BD7D17FD2A06@dsl-only.net> Date: Sat, 28 May 2016 20:55:56 -0700 Message-ID: Subject: Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build) From: Adrian Chadd To: Mark Millard Cc: Bryan Drewery , FreeBSD Current , FreeBSD Toolchain , FreeBSD PowerPC ML , Gerald Pfeifer , Warner Losh , Dimitry Andric Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 03:55:57 -0000 On 28 May 2016 at 14:30, Mark Millard wrote: > On 2016-May-28, at 12:03 PM, Adrian Chadd wrote: > >> [snip] >> >> hi, >> >> please don't patch the ports compiler assumptions about things like >> this. We should be targeting external toolchains on OSes (eg macosx) >> where it may already generate freebsd binaries and as such we should >> be calling the compiler/linker with all the flags it needs. >> >> Having a patched compiler default for mips made things way, way harder >> than it needed to be. >> >> >> >> -adrian > > Are there specific technical examples of specific lessons learned from the "patched compiler default for mips" context? > > Is there an intent to use /usr/src/. . . materials for buildworld/buildkernel and the like from a non-FreeBSD context? Are there examples? Well, I'd like to be able to build it from non-freebsd environment. Eg, eventually from the macosx shipped clang/llvm, or various other external toolchains. Doubly so for whatever commercial / internal / bring-up compilers that are used during platform bringup. The hurt is that our Makefile stuff is still a bit messy. On the plus side, Brian, Warner in particular have done a great job undoing all of that and making things cleaner, so big props to them! -adrian From owner-freebsd-current@freebsd.org Sun May 29 08:37: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 046AAB4DA79 for ; Sun, 29 May 2016 08:37:22 +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 B8BBB181F; Sun, 29 May 2016 08:37:20 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1b6wDm-002Vud-SO>; Sun, 29 May 2016 10:37:18 +0200 Received: from x4e34a111.dyn.telefonica.de ([78.52.161.17] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (envelope-from ) id <1b6wDm-001QIA-Hj>; Sun, 29 May 2016 10:37:18 +0200 Date: Sun, 29 May 2016 10:39:49 +0200 From: "O. Hartmann" To: Alan Somers Cc: Bryan Drewery , FreeBSD CURRENT Subject: Re: r300912: compile failure in world: event.cc:438:45: error: invalid suffix on literal; Message-ID: <20160529103949.17a63e0e.ohartman@zedat.fu-berlin.de> In-Reply-To: References: <20160528230443.31ee2003.ohartman@zedat.fu-berlin.de> <20160529000706.1c1e582d.ohartman@zedat.fu-berlin.de> <813e1a9f-7a65-ffe6-6189-4067df57646a@FreeBSD.org> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/KDs0ISka2PD_BnLRa/O6vz3"; protocol="application/pgp-signature" X-Originating-IP: 78.52.161.17 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 08:37:22 -0000 --Sig_/KDs0ISka2PD_BnLRa/O6vz3 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Sat, 28 May 2016 17:27:29 -0600 Alan Somers schrieb: > On Sat, May 28, 2016 at 4:26 PM, Bryan Drewery wro= te: > > On 5/28/16 3:07 PM, O. Hartmann wrote: =20 > >> CXXFLAGS+=3D -std=3Dc++11 > >> > >> > >> As it has been earlier stated, there is no -std=3Dc++11 visible in the= cc options, only > >> -std=3Dgnu99. =20 > > > > I'm confused why -std=3Dc++11 *doesn't* show now. Whatever though, the > > problem is reproducible with GCC toolchains which always get -std=3Dc++= 11 > > added in. > > > > I'm committing a fix. > > > > -- > > Regards, > > Bryan Drewery =20 >=20 > It didn't show only because ohartman pasted the wrong context in his > original email. He pasted the compile command for a .c file, followed > the the error message from a .cc file. Thanks for fixing it, Bryan. >=20 > -Alan He seems right, I confused the error messages and took it from a wrong term= inal, where I didn't disable parallel build. The fix fixed the problem, thank you very much. oh --Sig_/KDs0ISka2PD_BnLRa/O6vz3 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXSqrVAAoJEOgBcD7A/5N8BGwIAJnwykko5mDo3wbJUIWN3r7u zzImNFv5Fkvu946CvxwXdcmlJa6VOPhAz1Trwqf3EcA7GJJXZvXgff+H5U4r/IDz 7tdgp+zf7FtTGcbR0cDEhmetMa4UIPaEvfOu/SZhovo2EaAekAyQedlxGbEviI/V djui9Ja9gT4SLgBoY1waZecelFGrSk3HSmkDF8maaLjPgkNGzTMGD6qSocn8rV6l 4nvKleTkgJbXhv4Ns41rAGgkB8003g1S5e6gM+MKhLuUy/QLuhcL+zgmU/yXHZmz dpw/cWrqKTEXC9KOCPJHtNdURmQOiL7bMdV0iIKPg4xVmXuZpUd35ttORyG6DAo= =NywJ -----END PGP SIGNATURE----- --Sig_/KDs0ISka2PD_BnLRa/O6vz3-- From owner-freebsd-current@freebsd.org Sun May 29 07:30: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 C45BEB519F0 for ; Sun, 29 May 2016 07:30:02 +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 87B2E1A08 for ; Sun, 29 May 2016 07:30:02 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1b6vAe-002KUD-4I>; Sun, 29 May 2016 09:30:00 +0200 Received: from x4e34a111.dyn.telefonica.de ([78.52.161.17] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (envelope-from ) id <1b6vAd-001LWg-RZ>; Sun, 29 May 2016 09:30:00 +0200 Date: Sun, 29 May 2016 09:32:30 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: r 300949: rpcbind rejects to start: couldn't create ip6 socket Message-ID: <20160529093230.68a5da55.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/eQG=PxJauJFYyRIKG7n5jvJ"; protocol="application/pgp-signature" X-Originating-IP: 78.52.161.17 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 07:30:02 -0000 --Sig_/eQG=PxJauJFYyRIKG7n5jvJ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable After updating sources and build- and installworld, I realize that all rpcb= ind related services, so far NFS, are not working. On a client I check the start of rpc= bind by setting option -d and receive the output shown below. Well, prior to r300949 rpcbind started without complains - as it did with r= 300901. [...] rpcbind not running? Starting rpcbind. rpcbind debugging enabled. can't get local ip6 address: hostname nor servname provided, or not known couldn't create ip6 socket/etc/rc.d/rpcbind: WARNING: failed to start rpcbi= nd Kind regards, O. Hartmann --Sig_/eQG=PxJauJFYyRIKG7n5jvJ Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXSpsOAAoJEOgBcD7A/5N86IkIAMCiXaiBpRh1lyKcgZTYN3LH tDW3T+pyffKO5Ebdudfz3469hvyaq676t7glAUyc3itlc3Kc1S9Ne41dEeZhNAA2 zN1GT4MGZuXRIgybiDQShwMgfPrdQX/l75w4m9pwSNFhY5EL3MkLNjzknTg6PIIe JPjrRl5bQH7fiuwAQUKGLpAi4wGPXi+D5y3w1NVNL6cx4NUeuRIGf8JB+6KdzSdz cx7Z9EdRZ37slnnobR4LYv6jfE49V6hcJXHcsKRNo6sMptX8ImZdX8aUQ6NNWod/ wuqUmEbfAfWEN70zMXtPs0aSoGo0K+PSLlBWS2MAl5RWswnqnqb7rtdOpuxM0Ss= =DMyL -----END PGP SIGNATURE----- --Sig_/eQG=PxJauJFYyRIKG7n5jvJ-- From owner-freebsd-current@freebsd.org Sun May 29 09:15:49 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 501A3B51F41 for ; Sun, 29 May 2016 09:15:49 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Received: from mail.madpilot.net (grunt.madpilot.net [78.47.145.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 19B021985 for ; Sun, 29 May 2016 09:15:48 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3rHYy874X1zZqp for ; Sun, 29 May 2016 11:15:44 +0200 (CEST) Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10024) with ESMTP id ecUzktMwgBrM for ; Sun, 29 May 2016 11:15:43 +0200 (CEST) Received: from marvin.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA for ; Sun, 29 May 2016 11:15:43 +0200 (CEST) To: FreeBSD CURRENT From: Guido Falsi Subject: clang crash while compiling a port on head i386 Message-ID: <46def834-2739-7848-ed69-1404ba500f7f@FreeBSD.org> Date: Sun, 29 May 2016 11:15:42 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 09:15:49 -0000 Hi, The port games/0ad which I maintain crashes during compilation on i386 with clang. It says an assertion failed: Assertion failed: (Subtarget->hasSSE2() && "Requires at least SSE2!"), function ReplaceNodeResults, file /poudriere/jails/11i386/usr/src/lib/clang/libllvmx86codegen/../../../contrib/llvm/lib/Target/X86/X86ISelLowering.cpp, line 20435. It's happening both on the cluster and on my system. Maybe it's showing up only when building in a i386 jail on an amd64 system? Is anyone able to give me some more insight on this? Maybe I should file a bug report in bugzilla? The full log can also be found on the cluster: http://beefy3.nyi.freebsd.org/data/head-i386-default/p415968_s300895/logs/0ad-0.0.20.log Thanks in advance. -- Guido Falsi From owner-freebsd-current@freebsd.org Sun May 29 10:01: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 5C8EEB4F2E1 for ; Sun, 29 May 2016 10:01:01 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 26A831CC0 for ; Sun, 29 May 2016 10:01:01 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pf0-x22d.google.com with SMTP id g64so55560438pfb.2 for ; Sun, 29 May 2016 03:01:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=54awucDWcqrf287YUVhL6ASUS2Wu+SnQXV/+1/BnBOQ=; b=jRyMt4HHH1DQTMrgu+vsD1J85RQijKj9k5f00Ud/OrzaCzxP/s8KMrkBNO2rQwSbPg ckPQRu6EsIp9Ulcx9IdggQcFcmpLf9xO0mUGHq5hgYyQFNSHQc/+ZJvJuR6HVj5f7k/p xUI9swZE6qxAIZBrk4rWi7/kVYoW2cyMAm33ljv0FRS7iTc8bBF8mBZpQKEJZEEiB21G RVsdJsdODtypizeORa/fMUI1mAw+KXYoGxlxkjjylm5AfPtyI4Tyu1/jBQ9hOB69j1Nb +ba9VEX39Fj5woNhk1fW5mfbBqjhNTPee6FUKyC1FPeirZBSyPxO96/5iA9Al1BwtMGl j1FQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=54awucDWcqrf287YUVhL6ASUS2Wu+SnQXV/+1/BnBOQ=; b=VtkXY18NceJBYWKEejDnLN6g3nJIiqb5BOfrZPOl+mc5uj8ph6sN+A4kzRwHreSWXW 43WrtlvE1bXdjOReUo9/lpOepmrF5iPPBDabtSrDveQpd/hu+YnRBMTZMtxJUdzlMXrY VI+CNnfTdKBFT/zdsB2PfyP8pPXYl3GzsUJ/N0kCbiC0w+ZMqYgYDpww4mkovWwn4riu 4sa6/9C60PixFowyMdXxZqXJhZt5qPM2NuYfe5P3JcXuVAEKRM2B6EkQ4asFWVpUBTmy KoxzlVJtwt4DP4eZKF73NC/lTrwsMVg0Ym4qDSdJVOU8MB/Wu0Tb+npfGVqduZd2c5Fv cvTQ== X-Gm-Message-State: ALyK8tL9IAWJ2eZpe0ON0w5anNXsxxMyVC65V6YNKb58pmZGxKNor/IFXLwMmgKfWRih/A== X-Received: by 10.98.93.145 with SMTP id n17mr16404583pfj.66.1464516060704; Sun, 29 May 2016 03:01:00 -0700 (PDT) Received: from pinklady.local (c-73-97-222-46.hsd1.wa.comcast.net. [73.97.222.46]) by smtp.gmail.com with ESMTPSA id a17sm25220179pfa.70.2016.05.29.03.00.59 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 May 2016 03:01:00 -0700 (PDT) Subject: Re: r 300949: rpcbind rejects to start: couldn't create ip6 socket Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_74C1E9E1-7F25-416B-85F7-D12EFADF154D"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: "Ngie Cooper (yaneurabeya)" In-Reply-To: <20160529093230.68a5da55.ohartman@zedat.fu-berlin.de> Date: Sun, 29 May 2016 03:00:56 -0700 Cc: FreeBSD CURRENT Message-Id: References: <20160529093230.68a5da55.ohartman@zedat.fu-berlin.de> To: "O. Hartmann" X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 10:01:01 -0000 --Apple-Mail=_74C1E9E1-7F25-416B-85F7-D12EFADF154D Content-Type: multipart/mixed; boundary="Apple-Mail=_29103CB4-30A9-41FC-89FB-6A205489E534" --Apple-Mail=_29103CB4-30A9-41FC-89FB-6A205489E534 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 29, 2016, at 00:32, O. Hartmann = wrote: >=20 > After updating sources and build- and installworld, I realize that all = rpcbind related > services, so far NFS, are not working. On a client I check the start = of rpcbind by > setting option -d and receive the output shown below. >=20 > Well, prior to r300949 rpcbind started without complains - as it did = with r300901. >=20 > [...] > rpcbind not running? > Starting rpcbind. > rpcbind debugging enabled. > can't get local ip6 address: hostname nor servname provided, or not = known > couldn't create ip6 socket/etc/rc.d/rpcbind: WARNING: failed to start = rpcbind Hi, Could you please try this patch with -d (it=E2=80=99ll continue = on instead of exiting=E2=80=A6 I=E2=80=99m curious as to why it was = failing before). Does IPv6 work in your environment? Thanks! -Ngie --Apple-Mail=_29103CB4-30A9-41FC-89FB-6A205489E534 Content-Disposition: attachment; filename=ohartmann-rpcbind-util-break.patch Content-Type: application/octet-stream; name="ohartmann-rpcbind-util-break.patch" Content-Transfer-Encoding: 7bit Index: usr.sbin/rpcbind/util.c =================================================================== --- usr.sbin/rpcbind/util.c (revision 300945) +++ usr.sbin/rpcbind/util.c (working copy) @@ -40,6 +40,7 @@ #include #include #include +#include #include #include #include @@ -363,13 +364,20 @@ return; mreq6.ipv6mr_interface = 0; - inet_pton(AF_INET6, RPCB_MULTICAST_ADDR, &mreq6.ipv6mr_multiaddr); + ecode = inet_pton(AF_INET6, RPCB_MULTICAST_ADDR, + &mreq6.ipv6mr_multiaddr); + if (ecode != 1) { + if (debugging) + fprintf(stderr, "inet_pton failed with rc=%d: %s", + ecode, strerror(errno)); + goto done_inet6; + } s = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP); if (s == -1) { if (debugging) fprintf(stderr, "couldn't create ip6 socket"); - exit(1); + goto done_inet6; } /* @@ -392,6 +400,7 @@ if (debugging) perror("setsockopt v6 multicast"); } +done_inet6: freeifaddrs(ifp); #endif --Apple-Mail=_29103CB4-30A9-41FC-89FB-6A205489E534-- --Apple-Mail=_74C1E9E1-7F25-416B-85F7-D12EFADF154D 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 iQIcBAEBCgAGBQJXSr3ZAAoJEPWDqSZpMIYVeeEQAJzS3KZKImcBWy2dZNcAJZ+F qt00H+abBeJm+ixOHPQbUoD85X3Ls8Ay5XKzicNrcy7IJuIj/Qe8B3OTjYNEMVFu 1MmXHkflpidmcKJ9J99pPaxCLuxTNjwzipv0liFjPgtBVSe6S5CLtKZYbEBYmLtb 4hLaZnm+j6KrHA7KgIrnM5zZpxFliVFT6CTt1RKTJ8oJ/Z0+kY0ycXG757OgM7ik 7xiUZdt6mXLp7/iskeh7BMxCrp5M/hFc6lRdnV9ByHqvyrU1sWf8ZRVmA8OyphRG b3t46Qhwy+4p3sUmGkA686jrKfLLamEBzfNtukFVKPam4BoY3dTy0wsdSVkUHYp6 fXxexCWzMh9i85PB3aLDqxuljl4JQTe58pdwAtRVSsRdplLdilWSMNnU52Cfi617 RKQJvdDiPm5FkwihSefllhHjPaCi8k7AjvmcreyRu0iaBCD4DgxkKxaoKB9OgYzG MjT9mWncmMqc94lGGz7GJHTcOmZYapgWrT9WkpAEqv8zpHmfTciKAf7C33wixsM9 wBRsRxEGjakfsRXf6z3i8SGp4wmAIgtUg9TJC/Hv62+zXLzQRM3BPVxj+rmN1zot zWHLb8pztIEEtaN8ZqxtU86xC7AEkKsNhzOWoce4IRmB3H+ynXD2+H2lZwrqJGgf K7fB3d3sd7msqxm+pQZm =v9BH -----END PGP SIGNATURE----- --Apple-Mail=_74C1E9E1-7F25-416B-85F7-D12EFADF154D-- From owner-freebsd-current@freebsd.org Sun May 29 11:01: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 AA6C0B526E3 for ; Sun, 29 May 2016 11:01:12 +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 6C85A1C83 for ; Sun, 29 May 2016 11:01:12 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1b6yT0-002v3e-3N>; Sun, 29 May 2016 13:01:10 +0200 Received: from x4e34a936.dyn.telefonica.de ([78.52.169.54] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (envelope-from ) id <1b6ySz-001aYH-PZ>; Sun, 29 May 2016 13:01:09 +0200 Date: Sun, 29 May 2016 13:03:43 +0200 From: "O. Hartmann" To: "Ngie Cooper (yaneurabeya)" Cc: FreeBSD CURRENT Subject: Re: r 300949: rpcbind rejects to start: couldn't create ip6 socket Message-ID: <20160529130343.2ed96648.ohartman@zedat.fu-berlin.de> In-Reply-To: References: <20160529093230.68a5da55.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/0QY7rfvJ14CzKeF5nXyYhfi"; protocol="application/pgp-signature" X-Originating-IP: 78.52.169.54 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 11:01:12 -0000 --Sig_/0QY7rfvJ14CzKeF5nXyYhfi Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Am Sun, 29 May 2016 03:00:56 -0700 "Ngie Cooper (yaneurabeya)" schrieb: > > On May 29, 2016, at 00:32, O. Hartmann wr= ote: > >=20 > > After updating sources and build- and installworld, I realize that all = rpcbind related > > services, so far NFS, are not working. On a client I check the start of= rpcbind by > > setting option -d and receive the output shown below. > >=20 > > Well, prior to r300949 rpcbind started without complains - as it did wi= th r300901. > >=20 > > [...] > > rpcbind not running? > > Starting rpcbind. > > rpcbind debugging enabled. > > can't get local ip6 address: hostname nor servname provided, or not kno= wn > > couldn't create ip6 socket/etc/rc.d/rpcbind: WARNING: failed to start r= pcbind =20 >=20 > Hi, > Could you please try this patch with -d (it=E2=80=99ll continue on inste= ad of exiting=E2=80=A6 > I=E2=80=99m curious as to why it was failing before). Does IPv6 work in y= our environment? > Thanks! > -Ngie Give me a second, will try ... I disabled IPv6 in kernel and we do not use IPv6 yet, so I'm wondering why = rpcbind now insists relying on IPv6 ... --Sig_/0QY7rfvJ14CzKeF5nXyYhfi Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXSsyPAAoJEOgBcD7A/5N860gH/2S9OJE+95DmpsEsYoUTtxXW xl9jdr7hpKxt++0bgvr05jdTEooNs+mGrLy7diFTMvJQSJVt/OtmFeKItOazxbYw 3J4ZabEEm2UYk7L4g6DZYss2JbxTwfyatglOUQGED4Fzk2OhNp+eRFSalwN9cI8C q3Itx+5umWNbfXAw6pJA9hcwr7ExF8Z7x4E4QGrPNMLmCBTKEmfiKduKDPeuiQEL dEtFfSueO44EgHlXhz/DDHSYj7qKVQ/o5SzH9ypp1mJgyg10YyErGwJ9fqeOZrhh Q9XhJJGURmlxI6Yp8lYgEfjbXaqQFASRe34ov4ROnBWCBvzejkwBPfFmRs3xqxI= =PL5x -----END PGP SIGNATURE----- --Sig_/0QY7rfvJ14CzKeF5nXyYhfi-- From owner-freebsd-current@freebsd.org Sun May 29 02:40:19 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8685FB4FF11 for ; Sun, 29 May 2016 02:40:19 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6D2631886 for ; Sun, 29 May 2016 02:40:19 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id u4T2R2d0057495 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 28 May 2016 19:27:02 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id u4T2R2ae057494 for freebsd-current@freebsd.org; Sat, 28 May 2016 19:27:02 -0700 (PDT) (envelope-from sgk) Date: Sat, 28 May 2016 19:27:02 -0700 From: Steve Kargl To: freebsd-current@freebsd.org Subject: Recent seems to have broken toolchain Message-ID: <20160529022702.GA57282@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-Mailman-Approved-At: Sun, 29 May 2016 11:23:09 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 02:40:19 -0000 I have a Fortran application that has built forever on FreeBSD-current; that is, until recently. It now dies with the following error: gfortran48 -O2 -pipe -march=native -mtune=native -static -funroll-loops \ --param max-unroll-times=4 -ftree-vectorize -Wall\ -rpath /usr/local/lib/gcc48 -I/home/kargl/modules -o acolor acolor.f90 \ globalm.o saxm.o -L/home/kargl/lib -L. -L/usr/local/lib -L. -ltgt -loa \ -L/home/kargl/lib -L. -L/usr/local/lib -lm90 -llapack -lblas ./liboa.a(pointm.o): In function `__pointm_MOD_l2norm2': pointm.f90:(.text+0x490): multiple definition of `__pointm_MOD_l2norm2' /home/kargl/lib/libtgt.a(pointm.o):pointm.f90:(.text+0x0): first defined here Yes, pointm.o is in both libtgt.a and liboa.a. In the past, during linking, the symbols are resolved from the first of -ltgt or -loa depending on the order on the command line. The system is amd64 FreeBSD 11.0-CURRENT r300782M. I tried scanning the svn-src-head mailing list archive for a possible candidate commit that is causing the problem. Unfortunately, there is large volume of commits silencing errors from static analysis tools.o Note, the above error does not occur on an i386 FreeBSD 11.0-CURRENT r300379 system. -- Steve From owner-freebsd-current@freebsd.org Sun May 29 11:36: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 AEE8FB533D4 for ; Sun, 29 May 2016 11:36:36 +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 720F612A0 for ; Sun, 29 May 2016 11:36:36 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1b6z1G-0030y2-CB>; Sun, 29 May 2016 13:36:34 +0200 Received: from x4e34a936.dyn.telefonica.de ([78.52.169.54] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (envelope-from ) id <1b6z1G-001d7t-04>; Sun, 29 May 2016 13:36:34 +0200 Date: Sun, 29 May 2016 13:39:07 +0200 From: "O. Hartmann" To: "Ngie Cooper (yaneurabeya)" Cc: FreeBSD CURRENT Subject: Re: r 300949: rpcbind rejects to start: couldn't create ip6 socket Message-ID: <20160529133907.4566f2bf.ohartman@zedat.fu-berlin.de> In-Reply-To: References: <20160529093230.68a5da55.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/HDaRHDw..qONuMI/MfgTMwA"; protocol="application/pgp-signature" X-Originating-IP: 78.52.169.54 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 11:36:36 -0000 --Sig_/HDaRHDw..qONuMI/MfgTMwA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Am Sun, 29 May 2016 03:00:56 -0700 "Ngie Cooper (yaneurabeya)" schrieb: > > On May 29, 2016, at 00:32, O. Hartmann wr= ote: > >=20 > > After updating sources and build- and installworld, I realize that all = rpcbind related > > services, so far NFS, are not working. On a client I check the start of= rpcbind by > > setting option -d and receive the output shown below. > >=20 > > Well, prior to r300949 rpcbind started without complains - as it did wi= th r300901. > >=20 > > [...] > > rpcbind not running? > > Starting rpcbind. > > rpcbind debugging enabled. > > can't get local ip6 address: hostname nor servname provided, or not kno= wn > > couldn't create ip6 socket/etc/rc.d/rpcbind: WARNING: failed to start r= pcbind =20 >=20 > Hi, > Could you please try this patch with -d (it=E2=80=99ll continue on inste= ad of exiting=E2=80=A6 > I=E2=80=99m curious as to why it was failing before). Does IPv6 work in y= our environment? > Thanks! > -Ngie Recompiled sources with flag -DNO_CLEAN (I mention this because it might ha= ve impact). After that, I tried restarting rpcbind via: root@localhost: [src] service rpcbind restart rpcbind not running? Starting rpcbind. rpcbind debugging enabled. can't get local ip6 address: hostname nor servname provided, or not known couldn't create ip6 socketSegmentation fault (core dumped) /etc/rc.d/rpcbind: WARNING: failed to start rpcbind Now the "segmentation fault" is new. I regret not having the core or any mo= re infos on that, I disabled all core dumping options and debugging facilities on that = host of mine ... Oliver --Sig_/HDaRHDw..qONuMI/MfgTMwA Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXStTcAAoJEOgBcD7A/5N8sigH/0bZpxIIph5uxoLgrAv9uboR lfzSGZFcFOPcabjs7lEtM7Cnm7zE7EgffhdYq/DFAF5pkiVwsRrNFisXokiEucw/ emoj+9g6nU4B/TIK3rzZqIlX96Bxl16SB8Fghg1iMNDXwpo1bnggDQgMmDhY2pc3 rDnj+kp3i0I+MxMQ3utjfi5apYlZT9pWdkmKt+AQtTX/8BRqOviWlLa2Vz4GXCT2 aHNpp+NRhPeNBEXhpSXUe/C/gE6QHxwCe2RWhAqn0S7rhxfI+TctxdQc79Clw/Xr aAWeV2vZ5nfRWlmkZYue3p5lXWGgcZTyFML2MJZuh5SyC5bmFjQA7xtgrWDhjBs= =cps4 -----END PGP SIGNATURE----- --Sig_/HDaRHDw..qONuMI/MfgTMwA-- From owner-freebsd-current@freebsd.org Sun May 29 12:10: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 D54A1B4E28D for ; Sun, 29 May 2016 12:10:36 +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 C6D0D1697; Sun, 29 May 2016 12:10:36 +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 6C354498; Sun, 29 May 2016 12:10:36 +0000 (UTC) Date: Sun, 29 May 2016 12:10:26 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: ngie@FreeBSD.org, asomers@FreeBSD.org, phil@FreeBSD.org, bapt@FreeBSD.org, truckman@FreeBSD.org, avos@FreeBSD.org, andrew@FreeBSD.org, ed@FreeBSD.org, allanjude@FreeBSD.org, mmel@FreeBSD.org, bdrewery@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <76237975.8.1464523836463.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1192362233.6.1464433043087.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1192362233.6.1464433043087.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_amd64_gcc - Build #1268 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_amd64_gcc X-Jenkins-Result: SUCCESS Precedence: bulk X-Mailman-Approved-At: Sun, 29 May 2016 12:57:58 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 12:10:36 -0000 FreeBSD_HEAD_amd64_gcc - Build #1268 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1268/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1268/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1268/console Change summaries: 300952 by ed: Invoke the dirname() function in a POSIX compliant way. POSIX requires that the argument of dirname() is of type "char *". In other words, the input buffer can be modified by the function to store the directory name. Pull a copy of the string before calling dirname(). We don't care about freeing up the memory afterwards, as this is done at the very bottom of main(), right before the program terminates. Reviewed by: bapt Differential Revision: https://reviews.freebsd.org/D6628 300951 by mmel: ARM GIC: Allow to setup interrupt without configuration data. In some cases, like for PCI devices, only interrupt numbers are enumerated from HW. In this case, use INTR_foo_CONFORM as level and trigger values. 300950 by truckman: Now that PIE is free of runtime floating point, revert r300853 to reconnect PIE to the build. 300949 by truckman: Cast some expressions that multiply a long long constant by a floating point constant to int64_t. This avoids the runtime conversion of the the other operand in a set of comparisons from int64_t to floating point and doing the comparisions in floating point. Suggested by: lidl Submitted by: Rasool Al-Saadi MFC after: 2 weeks (with r300779) 300947 by ngie: Staticize variables only used in rpcbind.c This is some low hanging fruit necessary for making this WARNS?= 6 clean MFC after: 3 days Sponsored by: EMC / Isilon Storage Division 300945 by ngie: Remove unnecessary caller_uaddr != NULL test before calling free on it MFC after: 3 days Sponsored by: EMC / Isilon Storage Division 300944 by bdrewery: Libcompat: Swap CXX/CFLAGS. This is the same as done for the native build in r300770 to ensure that the libc++ build reads from SYSROOT/usr/include/c++/v1 before reading from SYSROOT/usr/include. 300943 by bdrewery: GCC External: Revert r300886, r300904, r300917, r300918 The fix in r300873 is mostly enough. A fix for lib32 will be committed.separately. 300942 by ngie: Remove a useless if (x != NULL) check before calling free on allocated_uaddr MFC after: 3 days Sponsored by: EMC / Isilon Storage Division 300941 by ngie: Don't leak res in network_init(..) Call freeaddrinfo on it after it's been used MFC after: 1 week Reported by: Coverity CID: 1225050 Sponsored by: EMC / Isilon Storage Division 300940 by ngie: Remove yacc and the yacc tests if MK_TOOLCHAIN == no yacc's install is conditional based on MK_TOOLCHAIN != no MFC after: 1 week Sponsored by: EMC / Isilon Storage Division 300939 by ngie: Use require.progs with bc instead of require.files with /usr/bin/bc This will make things more flexible if the program path changes in the future, and the test in and of itself doesn't call /usr/bin/bc -- it just calls bc MFC after: 1 week Sponsored by: EMC / Isilon Storage Division 300938 by ngie: Remove the sa(8) tests if MK_ACCT == no when "make delete-old" is run sa(8) is conditionally installed based on MK_ACCT != no today MFC after: 1 week Sponsored by: EMC / Isilon Storage Division 300937 by ngie: Remove the etcupdate tests if MK_RCS == no when "make delete-old" is run etcupdate is conditionally installed based on MK_RCS != no today MFC after: 1 week Sponsored by: EMC / Isilon Storage Division 300936 by ngie: Remove the calendar tests if MK_CALENDAR == no when "make delete-old" is run MFC after: 1 week Sponsored by: EMC / Isilon Storage Division 300935 by ngie: Mark out_of_mem(..) and usage(..) with __dead2 as they both directly call exit as a hint to static analysis tools MFC after: 1 week Sponsored by: EMC / Isilon Storage Division 300934 by ngie: Plug leak with ifp by calling freeifaddrs after calling getifaddrs MFC after: 1 week Obtained from: NetBSD v1.18 Sponsored by: EMC / Isilon Storage Division 300933 by allanjude: Add Documentation for missing ifconfig(8) flags autoconf / -autoconf deprecated / -deprecated pltime vltime PR: 209822 Submitted by: Sevan Janiyan MFC after: 2 weeks 300932 by ngie: Catch malloc(3) errors and socket(2) errors - malloc failing will result in a delayed segfault - socket failing will result in delayed failures with setsockopt Exit in the event that either of these high-level conditions are met. Reported by: Coverity CID: 976288, 976321, 976858 Sponsored by: EMC / Isilon Storage Division 300931 by ngie: Make netif REQUIRE hostid As noted in the PR, if etc/rc.d/zvol is removed, netif will be run before hostid, and the MAC address generated for any bridge devices will be non-deterministic. Make the MAC address generated be deterministic for bridge devices by explicitly REQUIRE'ing hostid. This fixes up the rest of the PR, inadvertently committed in r299844 MFC after: 1 week PR: 195188 Sponsored by: EMC / Isilon Storage Division 300927 by ngie: Delete duplicate declaration for i40e_blink_phy_link_led(..) It was already declared on line 90 Differential Revision: https://reviews.freebsd.org/D6570 Reported by: gcc Reviewed by: sbruno Sponsored by: EMC / Isilon Storage Division 300926 by bdrewery: Libcompat: Set build tools in environment rather than make overrides. This allows the CXX hack in r300917 for external GCC to work for the lib32 build. It is also the same pattern as the native build uses by adding the tools into CROSSENV for external toolchain, rather than make overrides. Sponsored by: EMC / Isilon Storage Division 300925 by phil: Submitted by: phil Reviewed by: sjg (mentor) Approved by: sjg 300922 by ngie: Fix "make installworld" with MK_CDDL == no after r300906 by adding a missing entry for ${TESTSBASE}/cddl/sbin X-MFC with: r300906 Pointyhat to: asomers Reported by: Shawn Webb Sponsored by: EMC / Isilon Storage Division 300921 by allanjude: Import the skein hashing algorithm, based on the threefish block cipher Connect it to userland (libmd, libcrypt, sbin/md5) and kernel (crypto.ko) Support for skein as a ZFS checksum algorithm was introduced in r289422 but is disconnected because FreeBSD lacked a Skein implementation. A further commit will enable it in ZFS. Reviewed by: cem Sponsored by: ScaleEngine Inc. Differential Revision: https://reviews.freebsd.org/D6166 300920 by bdrewery: Fix with external GCC after r300886. Somehow the /usr/include path got lost in this particular case. Just pass it along from --sysroot as was already done for DIRDEPS_BUILD. Sponsored by: EMC / Isilon Storage Division 300919 by bdrewery: Avoid more literal-suffix errors with C++11 300918 by bdrewery: External GCC: Ensure our libstdc++ symlink to libc++ is found. Similar to r300917, the search path for our symlink hack must come before the =/usr/lib search path. This fixes the atf-check build after r300886. 300917 by bdrewery: GCC XCC -isystem hack: Ensure CXX search =/usr/include/c++1/v1 first. The C++ header files must be searched before /usr/include. The original code in Makefile.inc1 did this before the change in r297271 to use -isystem. The libc++ import in r300770 fixed the bug introduced in r297271 by swapping XCFLAGS and XCXXFLAGS ordering in CROSSENV. Moving the code from Makefile.inc1 to bsd.sys.mk in r300886 also made it more difficult to control the order of the flags. CXXFLAGS is based on CFLAGS, so any additions to it will come after CFLAGS. The CROSSENV code from Makefile.inc1 was such that it was ensured the CXXFLAGS came first by setting them directly in CXX. Using CXXFLAGS+=-I would work here, but instead continue to use -isystem by adding it to CXX so it comes before CFLAGS. Reported by: dim 300915 by bdrewery: Avoid literal-suffix error due to missing space. 300914 by bapt: Readd week day to default dates Requested by: many 300913 by bapt: Add a hack to readd the day of weeks in default date formats 300912 by phil: Undo meaningless local changes to libxo so we're in sync with the github repo. Submitted by: phil Reviewed by: sjg (mentor) Approved by: sjg 300911 by avos: net80211: replace m_getcl/m_gethdr pair with m_get2 in ieee80211_fragment() - Switch to m_get2() for mbuf allocation instead of manual mbuf size determination. - Reuse MIN() macro for mbuf size selection. 300910 by avos: net80211: fix use-after-free in frame defragmentation procedure. - Assign frame sequence/fragment number before frame concatenation; otherwise, frame header pointer (wh) will be invalid. - Move this code block upper and eliminate duplicate 'lwh = mtod()' assignment. Tested with wpi(4) (transmitter) (STA mode) and urtwn(4) (receiver) (HOSTAP mode). 300906 by asomers: zfsd(8), the ZFS fault management daemon Add zfsd, which deals with hard drive faults in ZFS pools. It manages hotspares and replements in drive slots that publish physical paths. cddl/usr.sbin/zfsd Add zfsd(8) and its unit tests cddl/usr.sbin/Makefile Add zfsd to the build lib/libdevdctl A C++ library that helps devd clients process events lib/Makefile share/mk/bsd.libnames.mk share/mk/src.libnames.mk Add libdevdctl to the build. It's a private library, unusable by out-of-tree software. etc/defaults/rc.conf By default, set zfsd_enable to NO etc/mtree/BSD.include.dist Add a directory for libdevdctl's include files etc/mtree/BSD.tests.dist Add a directory for zfsd's unit tests etc/mtree/BSD.var.dist Add /var/db/zfsd/cases, where zfsd stores case files while it's shut down. etc/rc.d/Makefile etc/rc.d/zfsd Add zfsd's rc script sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c Fix the resource.fs.zfs.statechange message. It had a number of problems: It was only being emitted on a transition to the HEALTHY state. That made it impossible for zfsd to take actions based on drives getting sicker. It compared the new state to vdev_prevstate, which is the state that the vdev had the last time it was opened. That doesn't make sense, because a vdev can change state multiple times without being reopened. vdev_set_state contains logic that will change the device's new state based on various conditions. However, the statechange event was being posted _before_ that logic took effect. Now it's being posted after. Submitted by: gibbs, asomers, mav, allanjude Reviewed by: mav, delphij Relnotes: yes Sponsored by: Spectra Logic Corp, iX Systems Differential Revision: https://reviews.freebsd.org/D6564 300905 by bdrewery: Use a relative symlink for proper --sysroot support. Sponsored by: EMC / Isilon Storage Division 300904 by bdrewery: Always export X_* vars. This fixes CROSS_TOOLCHAIN builds after r300886 since it relies on X_COMPILER_TYPE being set. The X_* vars will only represent the external compiler being used. Sponsored by: EMC / Isilon Storage Division 300903 by allanjude: Implement SHA-512 truncated (224 and 256 bits) This implements SHA-512/256, which generates a 256 bit hash by calculating the SHA-512 then truncating the result. A different initial value is used, making the result different from the first 256 bits of the SHA-512 of the same input. SHA-512 is ~50% faster than SHA-256 on 64bit platforms, so the result is a faster 256 bit hash. The main goal of this implementation is to enable support for this faster hashing algorithm in ZFS. The feature was introduced into ZFS in r289422, but is disconnected because SHA-512/256 support was missing. A further commit will enable it in ZFS. This is the follow on to r292782 Reviewed by: cem Sponsored by: ScaleEngine Inc. Differential Revision: https://reviews.freebsd.org/D6061 300902 by andrew: Don't panic in hwpmc when stopping sampling. When hwpmc stops sampling it will set the pm_state to something other than PMC_STATE_RUNNING. This means the following sequence can happen: CPU 0: Enter the interrupt handler CPU 0: Set the thread TDP_CALLCHAIN pflag CPU 1: Stop sampling CPU 0: Call pmc_process_samples, sampling is stopped so clears ps_nsamples CPU 0: Finishes interrupt processing with the TDP_CALLCHAIN flag set CPU 0: Call pmc_capture_user_callchain to capture the user call chain CPU 0: Find all the pmc sample are free so no call chains need to be captured CPU 0: KASSERT because of this This fixes the issue by checking if any of the samples have been stopped and including this in te KASSERT. PR: 204273 Reviewed by: bz, gnn Obtained from: ABT Systems Ltd Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D6581 From owner-freebsd-current@freebsd.org Sun May 29 13:03: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 A4288B4F1EB for ; Sun, 29 May 2016 13:03:18 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6A6D512E5 for ; Sun, 29 May 2016 13:03:18 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1b707P-0002h7-NY for freebsd-current@freebsd.org; Sun, 29 May 2016 14:47:00 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-current@freebsd.org Date: Sun, 29 May 2016 14:46:55 +0200 Subject: if_iwn dhcp troubles MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.4.0 X-Scan-Signature: d1a953a21ffc669abe60e3197ee38772 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 13:03:18 -0000 Hello, My laptop has troubles obtaining an ip address on the wlan0 (if_iwn). The interface has trouble staying up during dhcp resolving. Below some information from logs. *If* it obtains an IP address it seems quite stable afterwards. Before https://svnweb.freebsd.org/base?view=revision&revision=300732 I had to reboot a couple of times before it would happen to get an IP address. If I need to supply more information please tell. I'm willing to test patches also. Regards, Ronald. From uname -a: FreeBSD sjakie.klop.ws 11.0-ALPHA1 FreeBSD 11.0-ALPHA1 #7 r300901M: Sat May 28 16:54:00 CEST 2016 root@sjakie.klop.ws:/usr/obj/usr/src/sys/GENERIC-NODEBUG amd64 From dmesg: iwn0: mem 0xf8000000-0xf8001fff irq 17 at device 0.0 on pci2 From /etc/rc.conf. wlans_iwn0="wlan0" create_args_wlan0="wlanaddr 00:26:b9:12:40:a4 country NL" ifconfig_wlan0="WPA" ifconfig_wlan0="$ifconfig_wlan0 SYNCDHCP" From console.log: May 29 13:34:45 sjakie kernel: Created wlan(4) interfaces: wlan0. May 29 13:34:45 sjakie kernel: Starting wpa_supplicant. May 29 13:34:45 sjakie kernel: Starting dhclient. May 29 13:34:45 sjakie kernel: wlan0: no link ... May 29 13:34:45 sjakie kernel: .. May 29 13:34:45 sjakie kernel: ... May 29 13:34:45 sjakie kernel: got link May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 port 67 May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 port 67 May 29 13:34:45 sjakie kernel: wlan0 link state up -> down May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 port 67 May 29 13:34:45 sjakie kernel: wlan0 link state down -> up May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 port 67 May 29 13:34:45 sjakie kernel: wlan0 link state up -> down May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 port 67 May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 6 May 29 13:34:45 sjakie kernel: wlan0 link state down -> up May 29 13:34:45 sjakie kernel: May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 port 67 May 29 13:34:45 sjakie kernel: wlan0 link state up -> down May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 15 May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 port 67 May 29 13:34:45 sjakie kernel: wlan0 link state down -> up May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 port 67 May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 port 67 May 29 13:34:45 sjakie kernel: wlan0 link state up -> down May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 4 May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 9 May 29 13:34:45 sjakie kernel: wlan0 link state down -> up May 29 13:34:45 sjakie kernel: May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 port 67 May 29 13:34:45 sjakie kernel: wlan0 link state up -> down May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 16 May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 port 67 May 29 13:34:45 sjakie kernel: wlan0 link state down -> up May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 port 67 May 29 13:34:45 sjakie kernel: wlan0 link state up -> down May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 port 67 May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 5 May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 5 May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 11 May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 port 67 May 29 13:34:45 sjakie kernel: wlan0 link state down -> up May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 port 67 May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 12 May 29 13:34:45 sjakie kernel: DHCPACK from 192.168.1.1 May 29 13:34:45 sjakie kernel: bound to 192.168.1.109 -- renewal in 2147483647 seconds. From messages: May 29 13:34:45 sjakie kernel: wlan0: Ethernet address: 00:26:b9:12:40:a4 May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601 May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP May 29 13:34:45 sjakie kernel: iwn0: iwn_intr: fatal firmware error May 29 13:34:45 sjakie kernel: firmware error log: May 29 13:34:45 sjakie kernel: error type = "UNKNOWN" (0x00000038) May 29 13:34:45 sjakie kernel: program counter = 0x00009F64 May 29 13:34:45 sjakie kernel: source line = 0x000003C4 May 29 13:34:45 sjakie kernel: error data = 0x0000000000000000 May 29 13:34:45 sjakie kernel: branch link = 0x00009F6000009F60 May 29 13:34:45 sjakie kernel: interrupt link = 0x0000DBEA00000000 May 29 13:34:45 sjakie kernel: time = 54908 May 29 13:34:45 sjakie kernel: driver status: May 29 13:34:45 sjakie kernel: tx ring 0: qid=0 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 1: qid=1 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 2: qid=2 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 3: qid=3 cur=2 queued=0 May 29 13:34:45 sjakie kernel: tx ring 4: qid=4 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 5: qid=5 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 6: qid=6 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 7: qid=7 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 8: qid=8 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 9: qid=9 cur=81 queued=0 May 29 13:34:45 sjakie kernel: tx ring 10: qid=10 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 11: qid=11 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 12: qid=12 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 13: qid=13 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 14: qid=14 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 15: qid=15 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 16: qid=16 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 17: qid=17 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 18: qid=18 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 19: qid=19 cur=0 queued=0 May 29 13:34:45 sjakie kernel: rx ring: cur=39 May 29 13:34:45 sjakie kernel: iwn0: iwn_panicked: controller panicked, iv_state = 5; restarting May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601 May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN May 29 13:34:45 sjakie kernel: iwn0: scan timeout May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601 May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN May 29 13:34:45 sjakie kernel: iwn0: scan timeout May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601 May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP May 29 13:34:45 sjakie kernel: iwn0: iwn_intr: fatal firmware error May 29 13:34:45 sjakie kernel: firmware error log: May 29 13:34:45 sjakie kernel: error type = "UNKNOWN" (0x00000038) May 29 13:34:45 sjakie kernel: program counter = 0x00009F64 May 29 13:34:45 sjakie kernel: source line = 0x000003C4 May 29 13:34:45 sjakie kernel: error data = 0x0000000000000000 May 29 13:34:45 sjakie kernel: branch link = 0x00009F6000009F60 May 29 13:34:45 sjakie kernel: interrupt link = 0x0000DBEA00000000 May 29 13:34:45 sjakie kernel: time = 7464 May 29 13:34:45 sjakie kernel: driver status: May 29 13:34:45 sjakie kernel: tx ring 0: qid=0 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 1: qid=1 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 2: qid=2 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 3: qid=3 cur=2 queued=0 May 29 13:34:45 sjakie kernel: tx ring 4: qid=4 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 5: qid=5 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 6: qid=6 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 7: qid=7 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 8: qid=8 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 9: qid=9 cur=81 queued=0 May 29 13:34:45 sjakie kernel: tx ring 10: qid=10 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 11: qid=11 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 12: qid=12 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 13: qid=13 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 14: qid=14 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 15: qid=15 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 16: qid=16 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 17: qid=17 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 18: qid=18 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 19: qid=19 cur=0 queued=0 May 29 13:34:45 sjakie kernel: rx ring: cur=63 May 29 13:34:45 sjakie kernel: iwn0: iwn_panicked: controller panicked, iv_state = 5; restarting May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601 May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN May 29 13:34:45 sjakie kernel: iwn0: scan timeout May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601 May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP May 29 13:34:45 sjakie kernel: iwn0: iwn_intr: fatal firmware error May 29 13:34:45 sjakie kernel: firmware error log: May 29 13:34:45 sjakie kernel: error type = "UNKNOWN" (0x00000038) May 29 13:34:45 sjakie kernel: program counter = 0x00009F64 May 29 13:34:45 sjakie kernel: source line = 0x000003C4 May 29 13:34:45 sjakie kernel: error data = 0x0000000000000000 May 29 13:34:45 sjakie kernel: branch link = 0x00009F6000009F60 May 29 13:34:45 sjakie kernel: interrupt link = 0x0000DBEA00000000 May 29 13:34:45 sjakie kernel: time = 69923 May 29 13:34:45 sjakie kernel: driver status: May 29 13:34:45 sjakie kernel: tx ring 0: qid=0 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 1: qid=1 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 2: qid=2 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 3: qid=3 cur=2 queued=0 May 29 13:34:45 sjakie kernel: tx ring 4: qid=4 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 5: qid=5 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 6: qid=6 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 7: qid=7 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 8: qid=8 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 9: qid=9 cur=81 queued=0 May 29 13:34:45 sjakie kernel: tx ring 10: qid=10 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 11: qid=11 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 12: qid=12 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 13: qid=13 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 14: qid=14 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 15: qid=15 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 16: qid=16 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 17: qid=17 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 18: qid=18 cur=0 queued=0 May 29 13:34:45 sjakie kernel: tx ring 19: qid=19 cur=0 queued=0 May 29 13:34:45 sjakie kernel: rx ring: cur=61 May 29 13:34:45 sjakie kernel: iwn0: iwn_panicked: controller panicked, iv_state = 5; restarting May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601 May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN May 29 13:34:45 sjakie kernel: iwn0: scan timeout May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601 May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP From owner-freebsd-current@freebsd.org Sun May 29 15:56: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 5D508B535EA for ; Sun, 29 May 2016 15:56:06 +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 1550F14B3; Sun, 29 May 2016 15:56:06 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-225-151.lns20.per1.internode.on.net [121.45.225.151]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u4TFu1cW025151 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 29 May 2016 08:56:04 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: pkg chroot issues? To: "bapt@freebsd.org" , Tim Kientzle References: <9BC1A0E1-696D-4C00-B8C8-B57C4DB3A8EF@kientzle.com> <20160522203108.GE11189@ivaldir.etoilebsd.net> <20160522203243.GF11189@ivaldir.etoilebsd.net> Cc: FreeBSD current From: Julian Elischer Message-ID: <8886a4b1-492b-61ea-90ea-7e694311d03b@freebsd.org> Date: Sun, 29 May 2016 23:55:55 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160522203243.GF11189@ivaldir.etoilebsd.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 15:56:06 -0000 On 23/05/2016 4:32 AM, bapt@freebsd.org wrote: > On Sun, May 22, 2016 at 10:31:08PM +0200, bapt@freebsd.org wrote: >> On Sun, May 22, 2016 at 01:24:12PM -0700, Tim Kientzle wrote: >>> Crochet has some experimental hooks to install packages onto the system being built, but this seems to be hitting problems due to limitations in 'pkg -c'. In particular, it seems that pkg performs the chroot before it does any network lookups. This is a problem if the chroot is not a complete system environment (which it cannot be when you're building an image for another system). >>> >>> There's some further discussion on github: >>> >>> https://github.com/freebsd/crochet/issues/141 >>> >>> Any suggestions? >>> >> I'll reply directly to github thanks for pointing me to the ticket >> >> Best regards, >> Bapt > As people might only follow this thread and not the ticket here is what I > answered: > > pkg supports an option for that which is pkg -o NAMESERVER= to avoid having to > copy resolv.conf it was broken in 1.8 but I fixed it in pkg 1.8.0 which has been > released today. > > the problem with pkg -c is that it calls chroot very early. To avoid that > problem we have added pkg -r which does not perform any chroot at all therefore > having not network issue, but the ports tree are is not yet entirely aware of it > and some scripts (preinstall/postinstall) might cause some issues. > at least creating users from the script is safe in that regard. for most simple > case that should work. As Bapt knows (I've been harassing him) pkg needs an "install all this over there" mode. The answer is "-r" but it does suffer from the fact that it requires postinstall scripts to cooperate by knowing to look for the appropriate environment value (I forget its name). I've used three different methods to get around this.. 1/ use -c and prepopulate it with a copy of /rescue, and copying all the pkg files I need in first into /pkg, which I delete afterwards. I'd like clarification in the Man page about setting a good $PATH in the chrooted part of pkg currently I just copy /rescue into /bin but pkg seems to sometimes use full paths for things so that meant also /usr/bin and usr/sbin. (or maybe that was an install script.). (in my application I could just link all 4 locations to be the same place). 2/ use PKG_DBDIR=$(TARGET_DIR)/var/db/pkg pkg add --relocate $(TARGET_DIR) $(PKGFILE) Almost the same as -r from my perspective. 3/ because I need to work as non-root, and pkg doesn't have a -u and -g option like chroot does, there are times when I need to do: sudo chroot -u $ME -g $MYGROUP sh -c "INSTALL_AS_USER pkg add -f -M $(PKGFILE)" instead of using pkg -c. I worked up a patch for -u and -g but lost it.. it was only about 20 lines including the usage() change. I'm sure bapt could redo it much better. using -u automatically enabled install_as_user. I was thinking that in order to do this properly the chrooted child should do all it's fetch requests etc via the non-chrooted parent, but that would have probably been a bit too complicated. (including add requests) > > > Best regards, > Bapt From owner-freebsd-current@freebsd.org Sun May 29 16:34: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 8A2CBB5330B for ; Sun, 29 May 2016 16:34:06 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (kientzle.com [142.254.26.11]) (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 68BD512A8; Sun, 29 May 2016 16:34:05 +0000 (UTC) (envelope-from tim@kientzle.com) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id u4TGXw07046931; Sun, 29 May 2016 16:33:58 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.102] (192.168.1.101 [192.168.1.101]) by kientzle.com with SMTP id qa8irz9ve5agnhgj2g82fevjxi; Sun, 29 May 2016 16:33:58 +0000 (UTC) (envelope-from tim@kientzle.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: pkg chroot issues? From: Tim Kientzle In-Reply-To: <8886a4b1-492b-61ea-90ea-7e694311d03b@freebsd.org> Date: Sun, 29 May 2016 09:33:57 -0700 Cc: "bapt@freebsd.org" , FreeBSD current Content-Transfer-Encoding: quoted-printable Message-Id: <07425DF9-AD45-49FD-AC9B-DEF39BDAA10E@kientzle.com> References: <9BC1A0E1-696D-4C00-B8C8-B57C4DB3A8EF@kientzle.com> <20160522203108.GE11189@ivaldir.etoilebsd.net> <20160522203243.GF11189@ivaldir.etoilebsd.net> <8886a4b1-492b-61ea-90ea-7e694311d03b@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 16:34:06 -0000 > On May 29, 2016, at 8:55 AM, Julian Elischer = wrote: >=20 > I was thinking that in order to do this properly the chrooted child = should do all it's fetch requests etc via the non-chrooted parent, but = that would have probably been a bit too complicated. (including add = requests) How complex would it be to perform all of the fetch requests before = chroot? Tim From owner-freebsd-current@freebsd.org Sun May 29 17:59:06 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 39FFCB5456D for ; Sun, 29 May 2016 17:59:06 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 0BAF61F70 for ; Sun, 29 May 2016 17:59:06 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-it0-x22e.google.com with SMTP id z189so20440542itg.0 for ; Sun, 29 May 2016 10:59:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=v9ueL4zCOxZwnZmjbJF1tQNZL0YzusAMR4fS0ybyGUk=; b=zBPz9c5Kde/Ja6T7wufVzgInrh7szb3Jg6xldtX3PbD1BaGjDFxjOU1xnEakc7kDn+ 3RIEnbblbPRrJxwjXVY64UFP/eOOFXhy2uBovBt2+JLcPdYPmNfhAjrFQCwnWSS4rGQY 1hMZYIrEtBz3UYyuBpprIO38iDSGkf6fnY+hf5J+70xfswJX3AnMYSlGkkq+gaIcqw8o CKW+TXU7JW1XELdRZwRwFnI5Sdd5AmPec93q/QOHYZkb5B+YkFTItMq2bkNeNxMlYvR1 lT1JlvlG2k53FaBuqi5dmxOxSxPfHRdMSfsh+xg+gWH5vZSwlnH4jrVQQoLuWIiNp0it BlnQ== 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; bh=v9ueL4zCOxZwnZmjbJF1tQNZL0YzusAMR4fS0ybyGUk=; b=PhX3sNLIh6WDAT8KD/R/+fCmaYBstVZNj8q6Y8xftxrVaxfKKApSm+mdhDpnn8wRVf B3S1ZfgEDpB1bO9eNCG4W3Swl9Uvm86kKYkOxa1HHzWJAP/sxasTAglN4y7k5I/Z9GIq DQjfKgTiHXdhZmEb+jcXVCrZREZHUtqQ8AHKIc7jjob4zyfmPq1jMqRpXRboJmLzLeke vNn5IKvFI+zgcvAP/40ldpUgyJO57ya5DvRE4LmtPIcZsoNcPbHGj+yQwV2++okUcrV1 AVYgyZtkw1tVSH/OoPGwNLHvfpL0DuZII/tdNH61P+AuMoDnV7HWBqK3P9pFTaL73Xh1 b3+w== X-Gm-Message-State: ALyK8tLqXrosIl6Wwjh9lk7/bLHBIQu0Qnirk/y/TYopmD//KdTdU0t5fZ/mmc3BlezNnz4u8wSimUH/R0mRIw== MIME-Version: 1.0 X-Received: by 10.36.51.15 with SMTP id k15mr4920302itk.80.1464544745155; Sun, 29 May 2016 10:59:05 -0700 (PDT) Received: by 10.36.113.3 with HTTP; Sun, 29 May 2016 10:59:05 -0700 (PDT) In-Reply-To: References: Date: Sun, 29 May 2016 10:59:05 -0700 Message-ID: Subject: Re: if_iwn dhcp troubles From: Adrian Chadd To: Ronald Klop Cc: freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 17:59:06 -0000 hi, Do ifconfig wlan0 -ht (ie, disable 11n) see if that helps -a On 29 May 2016 at 05:46, Ronald Klop wrote: > Hello, > > My laptop has troubles obtaining an ip address on the wlan0 (if_iwn). The > interface has trouble staying up during dhcp resolving. Below some > information from logs. *If* it obtains an IP address it seems quite stable > afterwards. > Before https://svnweb.freebsd.org/base?view=revision&revision=300732 I had > to reboot a couple of times before it would happen to get an IP address. > > If I need to supply more information please tell. I'm willing to test > patches also. > > Regards, > Ronald. > > > From uname -a: > FreeBSD sjakie.klop.ws 11.0-ALPHA1 FreeBSD 11.0-ALPHA1 #7 r300901M: Sat May > 28 16:54:00 CEST 2016 > root@sjakie.klop.ws:/usr/obj/usr/src/sys/GENERIC-NODEBUG amd64 > > From dmesg: > iwn0: mem 0xf8000000-0xf8001fff irq 17 at > device 0.0 on pci2 > > From /etc/rc.conf. > wlans_iwn0="wlan0" > create_args_wlan0="wlanaddr 00:26:b9:12:40:a4 country NL" > ifconfig_wlan0="WPA" > ifconfig_wlan0="$ifconfig_wlan0 SYNCDHCP" > > From console.log: > May 29 13:34:45 sjakie kernel: Created wlan(4) interfaces: wlan0. > May 29 13:34:45 sjakie kernel: Starting wpa_supplicant. > May 29 13:34:45 sjakie kernel: Starting dhclient. > May 29 13:34:45 sjakie kernel: wlan0: no link ... > May 29 13:34:45 sjakie kernel: .. > May 29 13:34:45 sjakie kernel: ... > May 29 13:34:45 sjakie kernel: got link > May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 port > 67 > May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 port > 67 > May 29 13:34:45 sjakie kernel: wlan0 link state up -> down > May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 port > 67 > May 29 13:34:45 sjakie kernel: wlan0 link state down -> up > May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 port > 67 > May 29 13:34:45 sjakie kernel: wlan0 link state up -> down > May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 port > 67 > May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 port > 67 interval 6 > May 29 13:34:45 sjakie kernel: wlan0 link state down -> up > May 29 13:34:45 sjakie kernel: > May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 port > 67 > May 29 13:34:45 sjakie kernel: wlan0 link state up -> down > May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 port > 67 interval 15 > May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 port > 67 > May 29 13:34:45 sjakie kernel: wlan0 link state down -> up > May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 port > 67 > May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 port > 67 > May 29 13:34:45 sjakie kernel: wlan0 link state up -> down > May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 port > 67 interval 4 > May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 port > 67 interval 9 > May 29 13:34:45 sjakie kernel: wlan0 link state down -> up > May 29 13:34:45 sjakie kernel: > May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 port > 67 > May 29 13:34:45 sjakie kernel: wlan0 link state up -> down > May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 port > 67 interval 16 > May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 port > 67 > May 29 13:34:45 sjakie kernel: wlan0 link state down -> up > May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 port > 67 > May 29 13:34:45 sjakie kernel: wlan0 link state up -> down > May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 port > 67 > May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 port > 67 interval 5 > May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 port > 67 interval 5 > May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 port > 67 interval 11 > May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 port > 67 > May 29 13:34:45 sjakie kernel: wlan0 link state down -> up > May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 port > 67 > May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 port > 67 interval 12 > May 29 13:34:45 sjakie kernel: DHCPACK from 192.168.1.1 > May 29 13:34:45 sjakie kernel: bound to 192.168.1.109 -- renewal in > 2147483647 seconds. > > From messages: > May 29 13:34:45 sjakie kernel: wlan0: Ethernet address: 00:26:b9:12:40:a4 > May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601 > May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP > May 29 13:34:45 sjakie kernel: iwn0: iwn_intr: fatal firmware error > May 29 13:34:45 sjakie kernel: firmware error log: > May 29 13:34:45 sjakie kernel: error type = "UNKNOWN" (0x00000038) > May 29 13:34:45 sjakie kernel: program counter = 0x00009F64 > May 29 13:34:45 sjakie kernel: source line = 0x000003C4 > May 29 13:34:45 sjakie kernel: error data = 0x0000000000000000 > May 29 13:34:45 sjakie kernel: branch link = 0x00009F6000009F60 > May 29 13:34:45 sjakie kernel: interrupt link = 0x0000DBEA00000000 > May 29 13:34:45 sjakie kernel: time = 54908 > May 29 13:34:45 sjakie kernel: driver status: > May 29 13:34:45 sjakie kernel: tx ring 0: qid=0 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 1: qid=1 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 2: qid=2 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 3: qid=3 cur=2 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 4: qid=4 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 5: qid=5 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 6: qid=6 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 7: qid=7 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 8: qid=8 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 9: qid=9 cur=81 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 10: qid=10 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 11: qid=11 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 12: qid=12 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 13: qid=13 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 14: qid=14 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 15: qid=15 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 16: qid=16 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 17: qid=17 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 18: qid=18 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 19: qid=19 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: rx ring: cur=39 > May 29 13:34:45 sjakie kernel: iwn0: iwn_panicked: controller panicked, > iv_state = 5; restarting > May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN > May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601 > May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP > May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN > May 29 13:34:45 sjakie kernel: iwn0: scan timeout > May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601 > May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP > May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN > May 29 13:34:45 sjakie kernel: iwn0: scan timeout > May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601 > May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP > May 29 13:34:45 sjakie kernel: iwn0: iwn_intr: fatal firmware error > May 29 13:34:45 sjakie kernel: firmware error log: > May 29 13:34:45 sjakie kernel: error type = "UNKNOWN" (0x00000038) > May 29 13:34:45 sjakie kernel: program counter = 0x00009F64 > May 29 13:34:45 sjakie kernel: source line = 0x000003C4 > May 29 13:34:45 sjakie kernel: error data = 0x0000000000000000 > May 29 13:34:45 sjakie kernel: branch link = 0x00009F6000009F60 > May 29 13:34:45 sjakie kernel: interrupt link = 0x0000DBEA00000000 > May 29 13:34:45 sjakie kernel: time = 7464 > May 29 13:34:45 sjakie kernel: driver status: > May 29 13:34:45 sjakie kernel: tx ring 0: qid=0 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 1: qid=1 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 2: qid=2 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 3: qid=3 cur=2 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 4: qid=4 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 5: qid=5 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 6: qid=6 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 7: qid=7 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 8: qid=8 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 9: qid=9 cur=81 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 10: qid=10 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 11: qid=11 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 12: qid=12 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 13: qid=13 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 14: qid=14 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 15: qid=15 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 16: qid=16 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 17: qid=17 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 18: qid=18 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 19: qid=19 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: rx ring: cur=63 > May 29 13:34:45 sjakie kernel: iwn0: iwn_panicked: controller panicked, > iv_state = 5; restarting > May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN > May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601 > May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP > May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN > May 29 13:34:45 sjakie kernel: iwn0: scan timeout > May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601 > May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP > May 29 13:34:45 sjakie kernel: iwn0: iwn_intr: fatal firmware error > May 29 13:34:45 sjakie kernel: firmware error log: > May 29 13:34:45 sjakie kernel: error type = "UNKNOWN" (0x00000038) > May 29 13:34:45 sjakie kernel: program counter = 0x00009F64 > May 29 13:34:45 sjakie kernel: source line = 0x000003C4 > May 29 13:34:45 sjakie kernel: error data = 0x0000000000000000 > May 29 13:34:45 sjakie kernel: branch link = 0x00009F6000009F60 > May 29 13:34:45 sjakie kernel: interrupt link = 0x0000DBEA00000000 > May 29 13:34:45 sjakie kernel: time = 69923 > May 29 13:34:45 sjakie kernel: driver status: > May 29 13:34:45 sjakie kernel: tx ring 0: qid=0 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 1: qid=1 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 2: qid=2 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 3: qid=3 cur=2 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 4: qid=4 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 5: qid=5 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 6: qid=6 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 7: qid=7 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 8: qid=8 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 9: qid=9 cur=81 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 10: qid=10 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 11: qid=11 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 12: qid=12 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 13: qid=13 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 14: qid=14 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 15: qid=15 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 16: qid=16 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 17: qid=17 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 18: qid=18 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: tx ring 19: qid=19 cur=0 queued=0 > May 29 13:34:45 sjakie kernel: rx ring: cur=61 > May 29 13:34:45 sjakie kernel: iwn0: iwn_panicked: controller panicked, > iv_state = 5; restarting > May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN > May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601 > May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP > May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN > May 29 13:34:45 sjakie kernel: iwn0: scan timeout > May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601 > May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Sun May 29 19:50: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 4F8C4B53D90 for ; Sun, 29 May 2016 19:50:40 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 208271B58 for ; Sun, 29 May 2016 19:50:40 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pf0-x22d.google.com with SMTP id f144so44767774pfa.3 for ; Sun, 29 May 2016 12:50:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=wtx4S69HoWd8fIWwEcTrXPE9f6StJDHmsx5XZYQ4R4k=; b=0/qN/tQWnAmFl5EWYVZSD+2mDLjTZUO7stdvraAEAmyaneY9BOLHVPp1hzzH80i6jW A14GfCIymvhE4t5z/SHLjR9gI8YvoOHSv4dqFXmwYhngPoynH18IizVN07JzYUJ2bQ0E FASlq7esIc2w98O605dEoeJ3933+e04XUwXsvVu3KuDlVHAY8SYx39CQzlm6eP/P+JdY UAYEDwEMV+OouCW1AaTLmvsdSq6m0RbcsOImOCC3n4vHhoknu+91C9W/LaOMIXw1aHa/ pRxEJ5pj/j+arb3nXYONUxig3hGO5+3hY4XnL/pXxTHn95NMVS0DKyhI0GfoT+G85fsG mVow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=wtx4S69HoWd8fIWwEcTrXPE9f6StJDHmsx5XZYQ4R4k=; b=Jk8T+R8bKlHEOHVP2mkCuyvGmyaiE8JDXIZky1eMtHDN3YjWQtEHxv1n8rFWZURh9/ Rn56FwDagXenCz7JuqVIAby+OVqgn/0SNuehTkHqpthSQocXhuLO5OIxbUiNR6jhsQBK 3lSbBn/oiG1UMLJIh2l4XMzF5U/15XYDphspWnZ01rgPSiMI7UqMxUpLBoJIMFnmDUCK WiJhcfi6YG7qUi9VO7tuYPyKQA34BVXxgRuEodajhSAkU0U2j2cy+1KBatOvrSxKaD9Q /mAdcR9SvBvQu1GgdzxOoEt/wLtwX5KiCtNckDr+55Flh4iNBtIWTISOPUpIWVuycZds b/xw== X-Gm-Message-State: ALyK8tKYVSyIeYj99lTbrm1Oj5ev/VD2QNv+vs6yuelTSvG2TSzBenoyh58VtfNcuU3VIA== X-Received: by 10.98.91.198 with SMTP id p189mr40865312pfb.146.1464551439641; Sun, 29 May 2016 12:50:39 -0700 (PDT) Received: from raichu ([2604:4080:1102:0:ca60:ff:fe9d:3963]) by smtp.gmail.com with ESMTPSA id x88sm26385507pfa.47.2016.05.29.12.50.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 29 May 2016 12:50:39 -0700 (PDT) Sender: Mark Johnston Date: Sun, 29 May 2016 12:50:35 -0700 From: Mark Johnston To: "O. Hartmann" Cc: "Ngie Cooper (yaneurabeya)" , FreeBSD CURRENT Subject: Re: r 300949: rpcbind rejects to start: couldn't create ip6 socket Message-ID: <20160529195035.GA89115@raichu> References: <20160529093230.68a5da55.ohartman@zedat.fu-berlin.de> <20160529133907.4566f2bf.ohartman@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160529133907.4566f2bf.ohartman@zedat.fu-berlin.de> User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 19:50:40 -0000 On Sun, May 29, 2016 at 01:39:07PM +0200, O. Hartmann wrote: > Recompiled sources with flag -DNO_CLEAN (I mention this because it might have impact). > > After that, I tried restarting rpcbind via: > > root@localhost: [src] service rpcbind restart > rpcbind not running? > Starting rpcbind. > rpcbind debugging enabled. > can't get local ip6 address: hostname nor servname provided, or not known > couldn't create ip6 socketSegmentation fault (core dumped) > /etc/rc.d/rpcbind: WARNING: failed to start rpcbind > > > Now the "segmentation fault" is new. I regret not having the core or any more infos on > that, I disabled all core dumping options and debugging facilities on that host of > mine ... The segfault should be addressed by r300972 - could you give that revision a try? From owner-freebsd-current@freebsd.org Sun May 29 21:27: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 11D8FB535AD for ; Sun, 29 May 2016 21:27:33 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ABB931111 for ; Sun, 29 May 2016 21:27:31 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1b78F6-0001zo-00; Sun, 29 May 2016 23:27:28 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Adrian Chadd" Cc: freebsd-current Subject: Re: if_iwn dhcp troubles References: Date: Sun, 29 May 2016 23:27:26 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/1.0 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.4.0 X-Scan-Signature: cf11f9968c7da7cd662fb2acf70b10dd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 21:27:33 -0000 On Sun, 29 May 2016 19:59:05 +0200, Adrian Chadd wrote: > hi, > > Do ifconfig wlan0 -ht (ie, disable 11n) > > see if that helps Hi, This does make the errors go away and startup more smoothly. Regards, Ronald. > > > -a > > > On 29 May 2016 at 05:46, Ronald Klop wrote: >> Hello, >> >> My laptop has troubles obtaining an ip address on the wlan0 (if_iwn). >> The >> interface has trouble staying up during dhcp resolving. Below some >> information from logs. *If* it obtains an IP address it seems quite >> stable >> afterwards. >> Before https://svnweb.freebsd.org/base?view=revision&revision=300732 I >> had >> to reboot a couple of times before it would happen to get an IP address. >> >> If I need to supply more information please tell. I'm willing to test >> patches also. >> >> Regards, >> Ronald. >> >> >> From uname -a: >> FreeBSD sjakie.klop.ws 11.0-ALPHA1 FreeBSD 11.0-ALPHA1 #7 r300901M: Sat >> May >> 28 16:54:00 CEST 2016 >> root@sjakie.klop.ws:/usr/obj/usr/src/sys/GENERIC-NODEBUG amd64 >> >> From dmesg: >> iwn0: mem 0xf8000000-0xf8001fff irq 17 at >> device 0.0 on pci2 >> >> From /etc/rc.conf. >> wlans_iwn0="wlan0" >> create_args_wlan0="wlanaddr 00:26:b9:12:40:a4 country NL" >> ifconfig_wlan0="WPA" >> ifconfig_wlan0="$ifconfig_wlan0 SYNCDHCP" >> >> From console.log: >> May 29 13:34:45 sjakie kernel: Created wlan(4) interfaces: wlan0. >> May 29 13:34:45 sjakie kernel: Starting wpa_supplicant. >> May 29 13:34:45 sjakie kernel: Starting dhclient. >> May 29 13:34:45 sjakie kernel: wlan0: no link ... >> May 29 13:34:45 sjakie kernel: .. >> May 29 13:34:45 sjakie kernel: ... >> May 29 13:34:45 sjakie kernel: got link >> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >> port >> 67 >> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >> port >> 67 >> May 29 13:34:45 sjakie kernel: wlan0 link state up -> down >> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >> port >> 67 >> May 29 13:34:45 sjakie kernel: wlan0 link state down -> up >> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >> port >> 67 >> May 29 13:34:45 sjakie kernel: wlan0 link state up -> down >> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >> port >> 67 >> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 >> port >> 67 interval 6 >> May 29 13:34:45 sjakie kernel: wlan0 link state down -> up >> May 29 13:34:45 sjakie kernel: >> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >> port >> 67 >> May 29 13:34:45 sjakie kernel: wlan0 link state up -> down >> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 >> port >> 67 interval 15 >> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >> port >> 67 >> May 29 13:34:45 sjakie kernel: wlan0 link state down -> up >> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >> port >> 67 >> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >> port >> 67 >> May 29 13:34:45 sjakie kernel: wlan0 link state up -> down >> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 >> port >> 67 interval 4 >> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 >> port >> 67 interval 9 >> May 29 13:34:45 sjakie kernel: wlan0 link state down -> up >> May 29 13:34:45 sjakie kernel: >> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >> port >> 67 >> May 29 13:34:45 sjakie kernel: wlan0 link state up -> down >> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 >> port >> 67 interval 16 >> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >> port >> 67 >> May 29 13:34:45 sjakie kernel: wlan0 link state down -> up >> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >> port >> 67 >> May 29 13:34:45 sjakie kernel: wlan0 link state up -> down >> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >> port >> 67 >> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 >> port >> 67 interval 5 >> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 >> port >> 67 interval 5 >> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 >> port >> 67 interval 11 >> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >> port >> 67 >> May 29 13:34:45 sjakie kernel: wlan0 link state down -> up >> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >> port >> 67 >> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 >> port >> 67 interval 12 >> May 29 13:34:45 sjakie kernel: DHCPACK from 192.168.1.1 >> May 29 13:34:45 sjakie kernel: bound to 192.168.1.109 -- renewal in >> 2147483647 seconds. >> >> From messages: >> May 29 13:34:45 sjakie kernel: wlan0: Ethernet address: >> 00:26:b9:12:40:a4 >> May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode >> rev=0x12a80601 >> May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP >> May 29 13:34:45 sjakie kernel: iwn0: iwn_intr: fatal firmware error >> May 29 13:34:45 sjakie kernel: firmware error log: >> May 29 13:34:45 sjakie kernel: error type = "UNKNOWN" (0x00000038) >> May 29 13:34:45 sjakie kernel: program counter = 0x00009F64 >> May 29 13:34:45 sjakie kernel: source line = 0x000003C4 >> May 29 13:34:45 sjakie kernel: error data = 0x0000000000000000 >> May 29 13:34:45 sjakie kernel: branch link = 0x00009F6000009F60 >> May 29 13:34:45 sjakie kernel: interrupt link = 0x0000DBEA00000000 >> May 29 13:34:45 sjakie kernel: time = 54908 >> May 29 13:34:45 sjakie kernel: driver status: >> May 29 13:34:45 sjakie kernel: tx ring 0: qid=0 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 1: qid=1 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 2: qid=2 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 3: qid=3 cur=2 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 4: qid=4 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 5: qid=5 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 6: qid=6 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 7: qid=7 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 8: qid=8 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 9: qid=9 cur=81 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 10: qid=10 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 11: qid=11 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 12: qid=12 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 13: qid=13 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 14: qid=14 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 15: qid=15 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 16: qid=16 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 17: qid=17 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 18: qid=18 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 19: qid=19 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: rx ring: cur=39 >> May 29 13:34:45 sjakie kernel: iwn0: iwn_panicked: controller panicked, >> iv_state = 5; restarting >> May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN >> May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode >> rev=0x12a80601 >> May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP >> May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN >> May 29 13:34:45 sjakie kernel: iwn0: scan timeout >> May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode >> rev=0x12a80601 >> May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP >> May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN >> May 29 13:34:45 sjakie kernel: iwn0: scan timeout >> May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode >> rev=0x12a80601 >> May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP >> May 29 13:34:45 sjakie kernel: iwn0: iwn_intr: fatal firmware error >> May 29 13:34:45 sjakie kernel: firmware error log: >> May 29 13:34:45 sjakie kernel: error type = "UNKNOWN" (0x00000038) >> May 29 13:34:45 sjakie kernel: program counter = 0x00009F64 >> May 29 13:34:45 sjakie kernel: source line = 0x000003C4 >> May 29 13:34:45 sjakie kernel: error data = 0x0000000000000000 >> May 29 13:34:45 sjakie kernel: branch link = 0x00009F6000009F60 >> May 29 13:34:45 sjakie kernel: interrupt link = 0x0000DBEA00000000 >> May 29 13:34:45 sjakie kernel: time = 7464 >> May 29 13:34:45 sjakie kernel: driver status: >> May 29 13:34:45 sjakie kernel: tx ring 0: qid=0 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 1: qid=1 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 2: qid=2 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 3: qid=3 cur=2 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 4: qid=4 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 5: qid=5 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 6: qid=6 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 7: qid=7 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 8: qid=8 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 9: qid=9 cur=81 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 10: qid=10 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 11: qid=11 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 12: qid=12 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 13: qid=13 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 14: qid=14 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 15: qid=15 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 16: qid=16 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 17: qid=17 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 18: qid=18 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 19: qid=19 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: rx ring: cur=63 >> May 29 13:34:45 sjakie kernel: iwn0: iwn_panicked: controller panicked, >> iv_state = 5; restarting >> May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN >> May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode >> rev=0x12a80601 >> May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP >> May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN >> May 29 13:34:45 sjakie kernel: iwn0: scan timeout >> May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode >> rev=0x12a80601 >> May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP >> May 29 13:34:45 sjakie kernel: iwn0: iwn_intr: fatal firmware error >> May 29 13:34:45 sjakie kernel: firmware error log: >> May 29 13:34:45 sjakie kernel: error type = "UNKNOWN" (0x00000038) >> May 29 13:34:45 sjakie kernel: program counter = 0x00009F64 >> May 29 13:34:45 sjakie kernel: source line = 0x000003C4 >> May 29 13:34:45 sjakie kernel: error data = 0x0000000000000000 >> May 29 13:34:45 sjakie kernel: branch link = 0x00009F6000009F60 >> May 29 13:34:45 sjakie kernel: interrupt link = 0x0000DBEA00000000 >> May 29 13:34:45 sjakie kernel: time = 69923 >> May 29 13:34:45 sjakie kernel: driver status: >> May 29 13:34:45 sjakie kernel: tx ring 0: qid=0 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 1: qid=1 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 2: qid=2 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 3: qid=3 cur=2 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 4: qid=4 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 5: qid=5 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 6: qid=6 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 7: qid=7 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 8: qid=8 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 9: qid=9 cur=81 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 10: qid=10 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 11: qid=11 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 12: qid=12 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 13: qid=13 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 14: qid=14 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 15: qid=15 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 16: qid=16 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 17: qid=17 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 18: qid=18 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: tx ring 19: qid=19 cur=0 queued=0 >> May 29 13:34:45 sjakie kernel: rx ring: cur=61 >> May 29 13:34:45 sjakie kernel: iwn0: iwn_panicked: controller panicked, >> iv_state = 5; restarting >> May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN >> May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode >> rev=0x12a80601 >> May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP >> May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN >> May 29 13:34:45 sjakie kernel: iwn0: scan timeout >> May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode >> rev=0x12a80601 >> May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Sun May 29 21: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 A0016B53F73; Sun, 29 May 2016 21:59:44 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 9464D1226; Sun, 29 May 2016 21:59:44 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id 513771C2E; Sun, 29 May 2016 21:59:44 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Sun, 29 May 2016 21:59:40 +0000 From: Glen Barber To: freebsd-current@FreeBSD.org, freebsd-snapshots@FreeBSD.org Subject: New FreeBSD snapshots available: head (20160528 r300895) Message-ID: <20160529215940.GA11785@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 21:59:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 New FreeBSD development branch installation ISOs and virtual machine disk images have been uploaded to the FTP mirrors. As with any development branch, the installation snapshots are not intended for use on production systems. We do, however, encourage testing on non-production systems as much as possible. Please also consider installing the sysutils/panicmail port, which can help in providing FreeBSD developers the necessary information regarding system crashes. Checksums for the installation ISOs and the VM disk images follow at the end of this email. === Installation ISOs === Installation images are available for: o 11.0-ALPHA1 amd64 GENERIC o 11.0-ALPHA1 i386 GENERIC o 11.0-ALPHA1 powerpc GENERIC o 11.0-ALPHA1 powerpc64 GENERIC64 o 11.0-ALPHA1 sparc64 GENERIC o 11.0-ALPHA1 armv6 BANANAPI o 11.0-ALPHA1 armv6 BEAGLEBONE o 11.0-ALPHA1 armv6 CUBIEBOARD o 11.0-ALPHA1 armv6 CUBIEBOARD2 o 11.0-ALPHA1 armv6 CUBOX-HUMMINGBOARD o 11.0-ALPHA1 armv6 GUMSTIX o 11.0-ALPHA1 armv6 RPI-B o 11.0-ALPHA1 armv6 RPI2 o 11.0-ALPHA1 armv6 PANDABOARD o 11.0-ALPHA1 armv6 WANDBOARD o 11.0-ALPHA1 aarch64 GENERIC Note regarding arm/armv6 images: For convenience for those without console access to the system, a freebsd user with a password of freebsd is available by default for ssh(1) access. Additionally, the root user password is set to root, which it is strongly recommended to change the password for both users after gaining access to the system. Snapshots may be downloaded from the corresponding architecture directory from: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/ Please be patient if your local FTP mirror has not yet caught up with the changes. Problems, bug reports, or regression reports should be reported through the Bugzilla PR system or the appropriate mailing list such as -current@ or -stable@ . === Virtual Machine Disk Images === VM disk images are available for the following architectures: o 11.0-ALPHA1 amd64 o 11.0-ALPHA1 i386 o 11.0-ALPHA1 aarch64 Disk images may be downloaded from the following URL (or any of the FreeBSD FTP mirrors): ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/ Images are available in the following disk image formats: ~ RAW ~ QCOW2 (qemu) ~ VMDK (qemu, VirtualBox, VMWare) ~ VHD (qemu, xen) The partition layout is: ~ 512k - freebsd-boot GPT partition type (bootfs GPT label) ~ 1GB - freebsd-swap GPT partition type (swapfs GPT label) ~ ~17GB - freebsd-ufs GPT partition type (rootfs GPT label) === Vagrant Images === FreeBSD/amd64 images are available on the Hashicorp Atlas site for the VMWare Desktop and VirtualBox providers, and can be installed by running: % vagrant init freebsd/FreeBSD-11.0-ALPHA1 % vagrant up == ISO CHECKSUMS == o 11.0-ALPHA1 amd64 GENERIC: SHA512 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895-bootonly.iso) = ad487c7eb726b74e7270e08f205ed610fefcfc6e69d8323757dc6928fb786566f18a0f3cf064b3aef07c91d6dff5791d2e317a0d606fd45a2e79282593aaf29a SHA512 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895-bootonly.iso.xz) = 124298b5831d9b5c71845968b093c9c4427cef1323098e22c5d1ef85dadf8482a876664326d8c22265a72dfefda1cb46500d6a3de14fe4764222334cb43be7fe SHA512 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895-disc1.iso) = 9dd2d18d4cb3ac935d14e3e2211965e606baedb8a4af2c5b39a73de918bfa8516239ff4e04170a485fb6f83f2fbd045be7d1f05d4d49210bda6059f867897da5 SHA512 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895-disc1.iso.xz) = 632bbfe3da2edffca3b316edefd57098a19597ad56c9551c8ee1a47dae36d9e3e1a1958cfb9d62590f89a62302aeed4d39042f283918cdd25c4cf78ee9fe962a SHA512 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895-dvd1.iso) = 5afe04bcb267ff5a17aecb8eacafa4bf11394076da9ad13c73b364e4b5ac1418502430cd1cffbad9ee01c8b4312d2c42151df7d19d279e527518520d4346e2df SHA512 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895-dvd1.iso.xz) = 891c53b74c804b5dbd1045dc65b2ba1b5c302ada3746a8ae9da483822d56b153def225e87ae1e7fe942b8c9f07c281b8a5d8cdaab46f71e0825366b95a2aa168 SHA512 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895-memstick.img) = 217e101f8769654953502ca85cb4a34af8896704c2e1e0035840020942e813b977b92dd596df587705c4742aa6d2ae5fc5034ddfc2071db404d02a403b6d8bbe SHA512 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895-memstick.img.xz) = 8901473db12d3bb4fa76d4068fb5f19ab4b374b45636440a082e1b4d4cc63cf5c37ef168e513d5c0f04ae9dd46a99f2acf3c302ef488e614f4d2a98310198d98 SHA512 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895-mini-memstick.img) = b1962d6cd66f6899b8a45b2695c965d80bb5b90f910982b510b25d7d2bf6159b5e7bcae15296f6de6b497207d7e69afae07ae5abd82f6cdd513f918e63206c7c SHA512 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895-mini-memstick.img.xz) = a104c1f662a66757e64ddc60138f75ac31acc548bea386875a8b86aea307609f7c9cf88b7ffb5443f3fb4184079bb750aca435329bb2affc45e048cf1877ee10 SHA256 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895-bootonly.iso) = 009518e853f566a0d8ede802a2d6f92fc615ff88c01823e72ed90a0435412e03 SHA256 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895-bootonly.iso.xz) = d3a26ebd17e17a18b289a638bcf4c35735c8bd6a7d41cf61f9594cfe80f0e18f SHA256 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895-disc1.iso) = 755d0987c972713e7fbc88f81adb908ec1f5d7ea1db04abfc7ae0a4d5b28ca5e SHA256 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895-disc1.iso.xz) = 2bca5fe4ffaa28194b87ba1985e3d0c41d8e46e84b586edbb4baf81e0d354b81 SHA256 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895-dvd1.iso) = 68f87705cd0b4b3c17999f699d9a52dc88849b913a50fc6d7c69d1c979017729 SHA256 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895-dvd1.iso.xz) = abb79bfbca2289baa4e251d3c79814857af1cc5a8cd0082c2d2ffe66fe50155c SHA256 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895-memstick.img) = d6d158876a48bf7c68e8a57f2ab089d1b0d7b95d077a5883aadfd9b38c617db9 SHA256 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895-memstick.img.xz) = db61409e41af8b96d7d7e5ca93b46eb4f2d58b470364d1e9cbbb57ba8daca299 SHA256 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895-mini-memstick.img) = c80b0f57e7c1ee3ad1bcc5a0f7895f586f122da98b1903a5073c551fcf51711f SHA256 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895-mini-memstick.img.xz) = 0fba6ffc561a1e524e398e28c4b0eb43a28346ba7337d8ffb7a5b34e13bcbbed o 11.0-ALPHA1 i386 GENERIC: SHA512 (FreeBSD-11.0-ALPHA1-i386-20160528-r300895-bootonly.iso) = cf95d0ef88cb084f9ae7ffa133980a77a21e670f66d1d53c475bd9979cfccb7fe0d4707f5bb50f2bdbae0ab72d6806c13c1cecfe841512c0be07905c40e5017d SHA512 (FreeBSD-11.0-ALPHA1-i386-20160528-r300895-bootonly.iso.xz) = 5faf3ac263500a6c0abf349291d52fb1aec5209f60da3c9ccc19d9d4bb310d7f2536b898e96a9385d6a0ca120fec1694b9ed58648d7ecaea6c8d4cc00d850c27 SHA512 (FreeBSD-11.0-ALPHA1-i386-20160528-r300895-disc1.iso) = e32ea3ea264d38d1cdafbecd3c1807f040ad75fd7e861de9d525224ddcb4915502e538be60bc26c586989b463bd3d91abc342585d0f7cea51fd5ec2b14df564f SHA512 (FreeBSD-11.0-ALPHA1-i386-20160528-r300895-disc1.iso.xz) = d9bc842d47832cccee35b4f09fa7c8b15ee722444b9d4d52f3fcb016d1e399616ac8bc95415c95632a51b02578a02db7f41beb5a7fb61d594dac191a85d1ddaf SHA512 (FreeBSD-11.0-ALPHA1-i386-20160528-r300895-dvd1.iso) = 2d74fa7b77a87d9e00049ed334079740b5c7140736893e5b2de98cb1609e2a4993af524faff3615c692c02de4179cc550a74aca2538ba4c9766875faa353832d SHA512 (FreeBSD-11.0-ALPHA1-i386-20160528-r300895-dvd1.iso.xz) = 7e107ab70623fc0640bd06785c8a6b7b976d04d67de1c2a71a59324648fe5c9a14cb2a56ef43a582338206febba229f2decfba71edd8b53aa95b68d1e7d70d2d SHA512 (FreeBSD-11.0-ALPHA1-i386-20160528-r300895-memstick.img) = 4e724bdc307e3fa911cfd943b3be58c22e1304fe666fee267742416de86f44e5e98b63e323bf0efe26d02d79ed1c5ae37787030df782c51a29654646827bc99c SHA512 (FreeBSD-11.0-ALPHA1-i386-20160528-r300895-memstick.img.xz) = bc6f8f1099070ac18b1610683ef3ae83840e9def53319cfa3a32f40936946bdf93d96cb2eccda3bc567b17b323fb2e72507ede0ef63d0feab3965306f4207905 SHA512 (FreeBSD-11.0-ALPHA1-i386-20160528-r300895-mini-memstick.img) = 9a0d4980a733032e618a744862bdd2c5a8c5568575784fda93c134df848d2d89ea009cf641c26d82a75a2d6b61c81e9475ee9d382ad3a43df0d790c0d4edcca2 SHA512 (FreeBSD-11.0-ALPHA1-i386-20160528-r300895-mini-memstick.img.xz) = e93ad766cd6cd803b18771c4f7a95bcce72c6cb27b642c5076678bf26eaaff0c280958197b1844ab506e305ec9dc6b87df1e0b2cfab03197bbca998dd4c7f5b4 SHA256 (FreeBSD-11.0-ALPHA1-i386-20160528-r300895-bootonly.iso) = 14636491e3342ce5f89723a688319e69941fb1a611924ddc1ef24a3ffc34e369 SHA256 (FreeBSD-11.0-ALPHA1-i386-20160528-r300895-bootonly.iso.xz) = 9c8be8d817b8cf3d0628fb476f270125d2a26e62a4cf3cbab845b869f8eab401 SHA256 (FreeBSD-11.0-ALPHA1-i386-20160528-r300895-disc1.iso) = 83cccc7c2bee1e3d0fbfbd953c60c8b0bc3265e085885b16cc79329e6db2ca01 SHA256 (FreeBSD-11.0-ALPHA1-i386-20160528-r300895-disc1.iso.xz) = 1878a071630aa68f97788ebed80c8368dbe2b5c344f6064d25b7378de8eb34b4 SHA256 (FreeBSD-11.0-ALPHA1-i386-20160528-r300895-dvd1.iso) = d17a2d456eee14cb1c7af2a502ddbb170a91ef5b0cdc8981c30c1ecaf2d8571c SHA256 (FreeBSD-11.0-ALPHA1-i386-20160528-r300895-dvd1.iso.xz) = bee1f43359aba5f9a2cbeb7e4c066dd141563bf152fd45da9b2daa87dbad7028 SHA256 (FreeBSD-11.0-ALPHA1-i386-20160528-r300895-memstick.img) = 0bb4d9c58796d953387ffaa93188241be27a1d1dab168061a947eeca9d3cbd60 SHA256 (FreeBSD-11.0-ALPHA1-i386-20160528-r300895-memstick.img.xz) = 6451c48a647d52bee57f13d3b4504427cc6ebeaa8b41575782e123a979d0cac0 SHA256 (FreeBSD-11.0-ALPHA1-i386-20160528-r300895-mini-memstick.img) = 398caa89e198887d4e08b5c7303c43d1722a2e460ff26c5a66d75e1235584608 SHA256 (FreeBSD-11.0-ALPHA1-i386-20160528-r300895-mini-memstick.img.xz) = cde73a4931fc0f2856845e82e02e9794a7524ad505eae08fd811696e9cd2054f o 11.0-ALPHA1 powerpc GENERIC: SHA512 (FreeBSD-11.0-ALPHA1-powerpc-20160528-r300895-bootonly.iso) = 4df98eca7520565afb3713621d7cd2dd668facb8cba8fe2ff2e630a84d505b1a266a40c8592366aeed7dd9fe0e16083902416121021bf3c3e33dba8f59037241 SHA512 (FreeBSD-11.0-ALPHA1-powerpc-20160528-r300895-bootonly.iso.xz) = 0b42177662a13fd11b53fb544180f98108f403e67614611e676dafc55cc26aadd66215c3f2f3aa51e3632ccb9efcddafab3e17557759c38098c857b5f882fa16 SHA512 (FreeBSD-11.0-ALPHA1-powerpc-20160528-r300895-disc1.iso) = 2fbd9276ee7ea0a030ec81055e5498d72a8326e4d1a4d17c16d6665e118f866e9c5ab8023c0b3e2890d54619314d1f4749bf8c367dc8d9231ea4d0f237e4b21e SHA512 (FreeBSD-11.0-ALPHA1-powerpc-20160528-r300895-disc1.iso.xz) = 492045b91aabdc2f38a9fb4918e165bc53c4f3dddf7e778d2128552697dd3db199986c8db01fb005efed9a47f5c65c1d75af5b477ff3f1ce862741f75b211e17 SHA512 (FreeBSD-11.0-ALPHA1-powerpc-20160528-r300895-memstick.img) = 6580e8be4662c0fbe19c505a4f1eabb6500919231f86998c2c54e5072f80caceb667ddf390852209bc382b2ecc2dc2b20e9298e667423eb01c2fec17ab3147a8 SHA512 (FreeBSD-11.0-ALPHA1-powerpc-20160528-r300895-memstick.img.xz) = 5b2e33ad06dbb087343cf6c80dd23bbfe4d618d2afad889712b04f5275ce9ef5bcd16c48e101fbe6f3363b1a12c635adab3a8472bd0f80a9968227dcc22cd438 SHA512 (FreeBSD-11.0-ALPHA1-powerpc-20160528-r300895-mini-memstick.img) = 47eb3d9e9fedfa14b36fc69d7073242f7b58d855f4b586124e25b1631e0e748fe236b5f2bc177438593d11643ca26803ed78c780e1cf35b5b0b7ad34b3a472c2 SHA512 (FreeBSD-11.0-ALPHA1-powerpc-20160528-r300895-mini-memstick.img.xz) = 80314e60e26b332841cfffd592535697bcd32382fa4b004e75c6040978e7d0dcc5693175ba9d2ea0f097ab08bd35d727ff650f6d2f1fa8a70222ccafc21ca0dc SHA256 (FreeBSD-11.0-ALPHA1-powerpc-20160528-r300895-bootonly.iso) = aadd46370c499150e6453e7a3e2ca4ce4b3a37e0408b9f5542fefdf670e71ed6 SHA256 (FreeBSD-11.0-ALPHA1-powerpc-20160528-r300895-bootonly.iso.xz) = dd078ba6c91f53a790cf106e36c04f519c3d48b3d38f8f7094ba3fae5fafb890 SHA256 (FreeBSD-11.0-ALPHA1-powerpc-20160528-r300895-disc1.iso) = d99520b98950b32b17a2a68e6f0330a0749a52b7491ae495de6754bbda90909c SHA256 (FreeBSD-11.0-ALPHA1-powerpc-20160528-r300895-disc1.iso.xz) = b457a5651cb96cee9baf83c21c4abcebc21083112e5641eecb76533f8998e980 SHA256 (FreeBSD-11.0-ALPHA1-powerpc-20160528-r300895-memstick.img) = d595afb422b33d7a6f6eb1d6bde6a1ea58cc5b4f124dd390536637710c6956eb SHA256 (FreeBSD-11.0-ALPHA1-powerpc-20160528-r300895-memstick.img.xz) = a0db037e3f3dceb31c5db9bcf5eff01529b516a3e7c7e5daed57eade23279604 SHA256 (FreeBSD-11.0-ALPHA1-powerpc-20160528-r300895-mini-memstick.img) = e583c6dd9a1b17447911e769fb0b43959586e97f228ed24f5a889e725435c904 SHA256 (FreeBSD-11.0-ALPHA1-powerpc-20160528-r300895-mini-memstick.img.xz) = 2e2ec9f4c67f01b42e37e04add19fb5359c45de3819356803099493f8fd51804 o 11.0-ALPHA1 powerpc64 GENERIC64: SHA512 (FreeBSD-11.0-ALPHA1-powerpc-powerpc64-20160528-r300895-bootonly.iso) = 1f0bb46c8e833bbe0396b403cfc0685a4caa35fafea747f488b848a806befa82219f16edf01b43709b51af07257c3bb42b410bd6893f5455204cc6a500da1d90 SHA512 (FreeBSD-11.0-ALPHA1-powerpc-powerpc64-20160528-r300895-bootonly.iso.xz) = 71ccbd21e1db39bd42a6c797bfb50cd6fde3e643f2551c65a5bdbb8843b34671f6befef32fc50b99b53605954c1dfc9146767004b6ae7bdf384ee64dfa68fd5c SHA512 (FreeBSD-11.0-ALPHA1-powerpc-powerpc64-20160528-r300895-disc1.iso) = a60b6ed9ce6d98246d7f3591019d4ef37668df6dd7c52d267703d3158113207a5a9543f6b3209e8d4bec14035e7505d88c3a62bbd7bbe55349370fefb598c271 SHA512 (FreeBSD-11.0-ALPHA1-powerpc-powerpc64-20160528-r300895-disc1.iso.xz) = 24541201fb6bab8e4b1bad4b1f187364f26aeeaf96a481f315316e8d87eb39cfde88f3a79f7d190c7e03e28e05694b68b2dc1e6107287de64110338b5a852bd4 SHA512 (FreeBSD-11.0-ALPHA1-powerpc-powerpc64-20160528-r300895-memstick.img) = 1628f7d3d68d712b136dc1c05435dc099e7bb10b62f05df689fecadb63e9fb243c017e8700057f778ed3dba05b45a82bf724bcfc5f0dc5442a3d420b5078cfbc SHA512 (FreeBSD-11.0-ALPHA1-powerpc-powerpc64-20160528-r300895-memstick.img.xz) = f424b9b7c19d84de77e376a0ca39580c72f0b76abbc4620ccbf24d3eb7a29d20b02ebe1531b1f28f42a03425c85601d4ac1ceefd4b4da3dc5b1d055dba8c4819 SHA512 (FreeBSD-11.0-ALPHA1-powerpc-powerpc64-20160528-r300895-mini-memstick.img) = 1dfe70215cb497f39e83e9dca18492ec406e0c47f42a5ae4b88551db79d6151929f5ff14121186919f5e301a6a8a1216ddf8da4091a9b834dc720a67e1a6d57f SHA512 (FreeBSD-11.0-ALPHA1-powerpc-powerpc64-20160528-r300895-mini-memstick.img.xz) = 9a7f71c1370e86263f49d815428bec7bacd6cd7af39ffe904b28e9d10c8a4df2c24cdebbd222d215e29ed75c27f6b950ea150897911d4f1d483c9fa821b4efc1 SHA256 (FreeBSD-11.0-ALPHA1-powerpc-powerpc64-20160528-r300895-bootonly.iso) = 3cccdef6b250b27723e6b989d93840f5f03b3d4b40c8ac925948ec3581d13008 SHA256 (FreeBSD-11.0-ALPHA1-powerpc-powerpc64-20160528-r300895-bootonly.iso.xz) = dafe00e8ecbbd9440e2b4e9512b00e62e6449c9b5e9a4d41804741eccef6cc64 SHA256 (FreeBSD-11.0-ALPHA1-powerpc-powerpc64-20160528-r300895-disc1.iso) = 6fa71e99caa75966723b63b45ed52a7d31f322469e4683161f272dcda5ea79ae SHA256 (FreeBSD-11.0-ALPHA1-powerpc-powerpc64-20160528-r300895-disc1.iso.xz) = 1a8171ec9a123a0f8622f1e4987a593519e89acd065964661f4740d5a85b98df SHA256 (FreeBSD-11.0-ALPHA1-powerpc-powerpc64-20160528-r300895-memstick.img) = 3a8d08de344492120b9777d24576bb5d3a2649170bc50022575e345eaab82041 SHA256 (FreeBSD-11.0-ALPHA1-powerpc-powerpc64-20160528-r300895-memstick.img.xz) = feb90c305fc0d77693ebf8a50c8c81a851884cb889bc69a3aaee76761c793eba SHA256 (FreeBSD-11.0-ALPHA1-powerpc-powerpc64-20160528-r300895-mini-memstick.img) = 366be4ee56e6797faffc7d264382e89ec4787f92b85e149949731fbdfcda4e61 SHA256 (FreeBSD-11.0-ALPHA1-powerpc-powerpc64-20160528-r300895-mini-memstick.img.xz) = 8e8699be3625fbe600e692b1d579c90cf49f11d52a0405c66d2807ada140ea20 o 11.0-ALPHA1 sparc64 GENERIC: SHA512 (FreeBSD-11.0-ALPHA1-sparc64-20160528-r300895-bootonly.iso) = cb10c33db2cec9b6599fdb1797699dab945e64f8e01693ad99786e0a6ff806b780c0dd557d0fb90e13eb9d5ac2eb3d3705b141906854aedb0e96bd7f33fe4447 SHA512 (FreeBSD-11.0-ALPHA1-sparc64-20160528-r300895-bootonly.iso.xz) = 52c810ed95a3de0a835127f845c02c2d70c12107922c68f1e01e2ddfdd672eb4bf2eac65995dbc78fd7586e86c71ce66a12152aac1e33620153f1548fd16fb58 SHA512 (FreeBSD-11.0-ALPHA1-sparc64-20160528-r300895-disc1.iso) = 4cfaaf42a1e21c285c7cd2a28887dccb97e8d0ef616493bb61c0da077d0c4d3262781f71d6d31024973a8f53cc700ae5e90e96a62896eeac22bc73abfb7eb96a SHA512 (FreeBSD-11.0-ALPHA1-sparc64-20160528-r300895-disc1.iso.xz) = a628566d0b3354995f5c9811392b2b4c889313cd1c995d8d19eb3ddae5d5fdc9ee41119745e3adb75e81470e05d8f9da131c3bbabf0f4621928b3541bd960628 SHA256 (FreeBSD-11.0-ALPHA1-sparc64-20160528-r300895-bootonly.iso) = f68a4a582d9d63e16965eaa161f3d06c1fa549466576b045a97d56e851ec26bd SHA256 (FreeBSD-11.0-ALPHA1-sparc64-20160528-r300895-bootonly.iso.xz) = f61ff84abcd0f4965b1ee349df88ae0a5357c298326e5705e7a9627d1afef213 SHA256 (FreeBSD-11.0-ALPHA1-sparc64-20160528-r300895-disc1.iso) = de37f2b9ac0c3f20240d0b5a5f6f47e1cc99a04442bec5d5b6d6431042a517b0 SHA256 (FreeBSD-11.0-ALPHA1-sparc64-20160528-r300895-disc1.iso.xz) = 7d3bd0414a76c90c9234f33487dee2a0926214126f12ba3e8058ea0cf52bc490 o 11.0-ALPHA1 armv6 BANANAPI: SHA512 (FreeBSD-11.0-ALPHA1-arm-armv6-BANANAPI-20160528-r300895.img.xz) = d00663bd2dd09398ef731cdef8ee2328761c8605aa89cd6735f49a083b36828d0f5f463e3811bdc4cdf0a3362594cb8265672997ec8f927bf91e144a349a0b49 SHA256 (FreeBSD-11.0-ALPHA1-arm-armv6-BANANAPI-20160528-r300895.img.xz) = eaff5329df22825510dbff8efd5316c8942e701bd04ea102b2a6b41e403a13aa o 11.0-ALPHA1 armv6 BEAGLEBONE: SHA512 (FreeBSD-11.0-ALPHA1-arm-armv6-BEAGLEBONE-20160528-r300895.img.xz) = 25fb0091fdcda225953f9c71c61c702bdb3960a01c5bd5629a63b3d20e8505aefe6b9dff2b567cf67c3f9ef32d39c252e1fd5be6332b2885ff17365c4f06a7a2 SHA256 (FreeBSD-11.0-ALPHA1-arm-armv6-BEAGLEBONE-20160528-r300895.img.xz) = 70d6d96e32938fa2928b62a7a4a141e1b792ac25ff462e9ecc10941788974be0 o 11.0-ALPHA1 armv6 CUBIEBOARD: SHA512 (FreeBSD-11.0-ALPHA1-arm-armv6-CUBIEBOARD-20160528-r300895.img.xz) = 068a38f656b93cc7c42b9e9d5cd413c21f1f8583a069479c34c880697264f1aa498e6556dc82ed8ceb1eaf61252540bd30fbbc4fe5b1f0d09f5983aae6bf00a4 SHA256 (FreeBSD-11.0-ALPHA1-arm-armv6-CUBIEBOARD-20160528-r300895.img.xz) = 9856c0cb8e186b31c6de29d9fc7d63905b22bbce02bc6cae129c869b8da6637b o 11.0-ALPHA1 armv6 CUBIEBOARD2: SHA512 (FreeBSD-11.0-ALPHA1-arm-armv6-CUBIEBOARD2-20160528-r300895.img.xz) = 94f8c3b07920c42c3608d87eec475e12eb08b68a175b4b87c2d055076b9e830e448b35bd7fa710730187ca5c9de907ad5ba0a7a942a7fef6562aa5ba108d7a90 SHA256 (FreeBSD-11.0-ALPHA1-arm-armv6-CUBIEBOARD2-20160528-r300895.img.xz) = 2e3b1207802d64ce89446ec29b444961d2bb9f6222b101d81b50cc6f1a13ca26 o 11.0-ALPHA1 armv6 CUBOX-HUMMINGBOARD: SHA512 (FreeBSD-11.0-ALPHA1-arm-armv6-CUBOX-HUMMINGBOARD-20160528-r300895.img.xz) = e7127ec886a331d37bd3fee3a91647fd90dc8a47b26478713c52aa14fd4ea9541aaeb4f61a9784d0c8c45e560ecaee0f4e535f7df6e01dca45dac5a489370b17 SHA256 (FreeBSD-11.0-ALPHA1-arm-armv6-CUBOX-HUMMINGBOARD-20160528-r300895.img.xz) = 7a9fa295f3084c9e131d9463d98b88bd71f4176f8390a977c6c442d59b7b5c12 o 11.0-ALPHA1 armv6 GUMSTIX: SHA512 (FreeBSD-11.0-ALPHA1-arm-armv6-GUMSTIX-20160528-r300895.img.xz) = 6fd7928d0f6700a3639942f98a57bf36a7ef27eb7114ae8f56a21b510a10c7a05fa73d829fdbaa8b0550242b2cee68103566b39e7255507c1641a6484e70229e SHA256 (FreeBSD-11.0-ALPHA1-arm-armv6-GUMSTIX-20160528-r300895.img.xz) = a571f04e3dd43a97264b83c5d3f0f9b34e324bbd9a648760c1c27ea29226671e o 11.0-ALPHA1 armv6 RPI-B: SHA512 (FreeBSD-11.0-ALPHA1-arm-armv6-RPI-B-20160528-r300895.img.xz) = 5bd930ae694b9ce4eee731f0b3e6c2682aaa2c731f299aa2a4339245782bbc9265346abbb357f261f755b61f2ed516c2c2740fb0a2524960ad96b3572028f9dc SHA256 (FreeBSD-11.0-ALPHA1-arm-armv6-RPI-B-20160528-r300895.img.xz) = c4cc9fdd0407ba208bb2085b415db0caa745ed2febb1a9b05c4867ad6a89b7a2 o 11.0-ALPHA1 armv6 RPI2: SHA512 (FreeBSD-11.0-ALPHA1-arm-armv6-RPI2-20160528-r300895.img.xz) = 72808e63147d879dfa710a96431a268820e762fbd8895c4b096aed031f4bd475a7dca3999285e8b0127dd464f06585808e16d07360f1037395650c984230e936 SHA256 (FreeBSD-11.0-ALPHA1-arm-armv6-RPI2-20160528-r300895.img.xz) = e09e2d7fa1fc10940b83a1c5afdb13c8cf0d1e107eb789ac31e3333ba2575a5d o 11.0-ALPHA1 armv6 PANDABOARD: SHA512 (FreeBSD-11.0-ALPHA1-arm-armv6-PANDABOARD-20160528-r300895.img.xz) = fcb4c0654a9f86d6a25997646a2f2de743956573f77cc15f1b087238341495568b55b4c7638982f14b6c0f09ff4551256f93d65b3b89f250fc196dcdb619c1d5 SHA256 (FreeBSD-11.0-ALPHA1-arm-armv6-PANDABOARD-20160528-r300895.img.xz) = 1057717167b35cb1a38c3e071da8a5273ba5a3f4c2ec332e935610a7570910c0 o 11.0-ALPHA1 armv6 WANDBOARD: SHA512 (FreeBSD-11.0-ALPHA1-arm-armv6-WANDBOARD-20160528-r300895.img.xz) = b9d68734b35daea8a718f8cd5fbc040d74e55df11febaf1a9092841e1dc9149844d4b1ed3ae1776cc5ee534ca4c387a0b5780d8212780ad1e79c340a05de2d26 SHA256 (FreeBSD-11.0-ALPHA1-arm-armv6-WANDBOARD-20160528-r300895.img.xz) = 42d17771bbe35cc767cb7ce08d65ea34575efd027adfb003a16c46b7dbfc6628 o 11.0-ALPHA1 aarch64 GENERIC: SHA512 (FreeBSD-11.0-ALPHA1-arm64-aarch64-20160528-r300895-memstick.img) = f93fd05ab53512915a2423681f80445e22f8aa5b5314a257ec07834e6ee78023e56daac4678204d0fd4ea3b212e701c9c8b1e1d242106a2da0fa5b87fa93a2bc SHA512 (FreeBSD-11.0-ALPHA1-arm64-aarch64-20160528-r300895-memstick.img.xz) = 8f5693c31cf599624ba24746274a87ffe1d9181e28b4c30bfa766d766ad760065550c4d132a76860e5128bfc9c53db7d443346a4027ab4d17b4bc7e04e2048ee SHA512 (FreeBSD-11.0-ALPHA1-arm64-aarch64-20160528-r300895-mini-memstick.img) = b818d7a26c293b2576ded552f6a0993d28dcc9b15ae636c8da22dc15971f95424101ed2a5d517c203450d160bf57de2b4467cbf1e2c62b423ad344ea3d0114e0 SHA512 (FreeBSD-11.0-ALPHA1-arm64-aarch64-20160528-r300895-mini-memstick.img.xz) = 2d0a2c1705821a9f28f36596b1da7f3aeb6ad68e31041c11925b99367d8c6ec1d46f68d3b579b6e59ba3d31ff920f378b2043390420464718d65b166763a700b SHA256 (FreeBSD-11.0-ALPHA1-arm64-aarch64-20160528-r300895-memstick.img) = 92eb298247c80f46d614f7e3610a0593c4f94aa40085e2945f30bf4ef3fd0d41 SHA256 (FreeBSD-11.0-ALPHA1-arm64-aarch64-20160528-r300895-memstick.img.xz) = f69109c2cfe0ea59ee7eee48586f850d2c26708520a45b0847abd490efe285d5 SHA256 (FreeBSD-11.0-ALPHA1-arm64-aarch64-20160528-r300895-mini-memstick.img) = 31ec68546353eb967c58d2fb4df246d106ab11cbeb586c0db0ba9f35aceb57be SHA256 (FreeBSD-11.0-ALPHA1-arm64-aarch64-20160528-r300895-mini-memstick.img.xz) = 9a4e6c54ab16d5a39616993c9560da15788e817ce99f40a45a3aa1c609292cdd == VM IMAGE CHECKSUMS == o 11.0-ALPHA1 amd64: SHA512 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895.qcow2.xz) = 72c428afe9738124bc57af61439ef0ea311c1e11f1cab44cb051056bf3d34fd4f6355b53029250504c16e7bc515c65a548e86e3e36d7d8eefc688cc98530ea9e SHA512 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895.raw.xz) = d63c4ffbd11363daf07714d2cd685873a38bd3fa38925fb32008051315787e257dd652f0b07c7baf9fc3d0ce2aecd22e4b5fb0a6d70ba6a9dd19ee5d452aabae SHA512 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895.vhd.xz) = 5d5fe6883032adb1ef24b58cb913c14a387a2bafe5802e804e331ed9c1aa70f524ae58cfd155faac2aff81cb6fc897356467798499f94c4c9ac2a0eedda31f7e SHA512 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895.vmdk.xz) = 361ffcdea262b521145f3217110fa75d4e38ceae16d8a3baf6973a392405714ade2415892576f03545b2645db8a12ebeb87969c41c35839b2cf4598b9fc1c7e9 SHA256 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895.qcow2.xz) = 782f7391561aa69e5f7600994d12470d38dae8edd1a4326d7814d5021fe0b63b SHA256 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895.raw.xz) = e9127d8f35bc3b29f2c412bc9fba88680efb173bbb373e6ed75ad5988ff3a754 SHA256 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895.vhd.xz) = 111b042fe61c472fa622fc2037083465da49230c2e03abf24c6bc04004ac3df3 SHA256 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895.vmdk.xz) = 770a9f78f5d640e9f7c5e48d27a06e5d2f8494959fe0577ce590519c09afe25c o 11.0-ALPHA1 i386: SHA512 (FreeBSD-11.0-ALPHA1-i386-20160528-r300895.qcow2.xz) = f3a6852dd11f530dd2afd8448ffcc6c0716a1c2b0fe72abd591d7de8b29bd301941eac64c71e795233192be1ca91f003d15dd9bed6dcdcdde18003a2e12f0740 SHA512 (FreeBSD-11.0-ALPHA1-i386-20160528-r300895.raw.xz) = 41ab93847f84d158cfadabdade78106f0bcc00a2110126e6dcb636f2f65a15904c0893e582c6567fdc9c68492588a4ae6db48d4230f8e67cae0f503d02c5156b SHA512 (FreeBSD-11.0-ALPHA1-i386-20160528-r300895.vhd.xz) = b8138919b2143c0e3e846378d02240656a1060621e39b90e986f93622c77a97544aea1369582cb35aa58658f6f24071d1b084534330d195162ffac30835137fa SHA512 (FreeBSD-11.0-ALPHA1-i386-20160528-r300895.vmdk.xz) = c336edacf721b4093f16473563d0a4d7ac8819f2ad0373cd810111a0222b8ce1ca3ba50f93b4b7afc7c6902f4f222457ecdb9ff2daf27fd467e2ee6b7a7f2b43 SHA256 (FreeBSD-11.0-ALPHA1-i386-20160528-r300895.qcow2.xz) = a17458af3465980dced4e67690e24ee116b6f57927ee66c86fe372d644bbbfe9 SHA256 (FreeBSD-11.0-ALPHA1-i386-20160528-r300895.raw.xz) = 7e1a367603439bbf296983e6ee751fac74b0b8f24f1de7b4283cf8196710cee4 SHA256 (FreeBSD-11.0-ALPHA1-i386-20160528-r300895.vhd.xz) = 51e90a5d49e55db38f396cd0fa3ce089b0aed57cf815b4fd48475bea07846608 SHA256 (FreeBSD-11.0-ALPHA1-i386-20160528-r300895.vmdk.xz) = 04d55d5226039025a93566b2dcc180d8ac8acbe8dbc44c2405a2f53ddbe3f18b o 11.0-ALPHA1 aarch64: SHA512 (FreeBSD-11.0-ALPHA1-arm64-aarch64-20160528-r300895.qcow2.xz) = c2c87be03130cda7f675999f9a908afa49f829e7f26aca43ba806f5f9764ba9f260a6a3d38133c554fdd7f2d1c87ec883b14c9f42e4ef752648761143c801678 SHA512 (FreeBSD-11.0-ALPHA1-arm64-aarch64-20160528-r300895.raw.xz) = 62bf01d8444a757dba35cefd2fde03794972bb33c260f95b2ada7a38cc16688b699dbfedb3592ca04ddb30819b2bc48a333bda2ebee39307736d2fc9afe51abf SHA512 (FreeBSD-11.0-ALPHA1-arm64-aarch64-20160528-r300895.vhd.xz) = 17b8c38161d37985f4e53234800689a6b406a996e5c96ebd1a2d6af462a64399b41e5ed39634e5b903204acdcaf94f51001faadefd893cf2b7ec162db1e760c1 SHA512 (FreeBSD-11.0-ALPHA1-arm64-aarch64-20160528-r300895.vmdk.xz) = 8e5cc24ad8ba1b665384a39be6044dd2b24841dbb09738c50d768256511370d7e6645bc61beebc3dede4cd247175068a7f2441571eabdbb44dc2931868afc3eb SHA256 (FreeBSD-11.0-ALPHA1-arm64-aarch64-20160528-r300895.qcow2.xz) = ab7b47be909cfc0b38f94d4420770700b6ff4b90f04e89c0197ee77db04be4b6 SHA256 (FreeBSD-11.0-ALPHA1-arm64-aarch64-20160528-r300895.raw.xz) = 8efca3348479668b36680006087031d2c2fa8fdd5eb8b878eeb6ff91debf4eb5 SHA256 (FreeBSD-11.0-ALPHA1-arm64-aarch64-20160528-r300895.vhd.xz) = b43178fa3eeaf86c60d144db765213f6e5fd240ad9e49d64baa40f09e6928a52 SHA256 (FreeBSD-11.0-ALPHA1-arm64-aarch64-20160528-r300895.vmdk.xz) = 1f011126e9a98370b56563b46e3ac9057418731fa3ed3dc45f9401d6a10e85fa Regards, Glen Love FreeBSD? Support this and future releases with a donation to the FreeBSD Foundation! https://www.freebsdfoundation.org/donate/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXS2ZMAAoJEAMUWKVHj+KThgYP/i2EqMZ3xeTa4ngqSbvZlgDM 4whxAEZifhvYVAi4ZcnF7K8XhwQWvtX4GNiH+U6VwehWS54cDgbLCrCnj1fBPSjA jLOL11IoRoKcoJoU7YtOSm1tDKxc/z0bZrgoItBOAn3xdTcKhFedo350usqRPr4+ xNykXQG/Hamrnc7M1MhreV8hohmgxw6pgQAev/i/aUtnFppAj+TF+P8ZzR/7gCmt 67oA7M2jVu2zTAhDj+pTGWgF1fRxGfx85zabudZuE4Va0mSRObS8DJ/cxcmI956U +45U2rECK79dAL6+2t+iY5bpQ+wy4Qkwe8GEFCPeaq2S46o2zxARHAbPO3qBl6S3 b/qOY8VpKATQydXIJx3ZaUNacH7qqU4LsH9K5nFADxBpPt3RgFCFbFcGLSsQbeuT h60XLDaagQGcWFuMUcEVI4jChn7y8zihZ7ULxP9QJ4GweNle0uLeYfkLdyD3eUWD 3loomRqL0bJ5Tor4Dt2jl0aU04Z51G/DPfcmFyukXy0krf5zR+MGA13NTWV0UJcR NrX0Yx/+wZk5of5cBe4ZkhayGBjYTNE+XsrvQtqQvXlG9+JO4mMjuda8Wp0/xlFs pfVMExldMFK2TOiMOqGuHQQy8pNByTjHoR589ROBryz0bqDpLQ0sHcMjCX2+ipyk 07BD+Cx2z3q6mVsz+6Sc =CSH/ -----END PGP SIGNATURE----- From owner-freebsd-current@freebsd.org Sun May 29 22:30:07 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C1B39B545E3 for ; Sun, 29 May 2016 22:30:07 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5DD76199D for ; Sun, 29 May 2016 22:30:07 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: by mail-wm0-x22e.google.com with SMTP id n129so51302112wmn.1 for ; Sun, 29 May 2016 15:30:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=eh5rMSih6Lydn0o0VZFUTqj9Enwcn3tkgEdt8E0oDdA=; b=YWpLitksAVeeIY3DYbr+k/W9qF7sbWcriNqenLEfLW1sO2j4w3ZHedsHynZIGhUgeA tn8CVr37Xapl0mdOB+OBqKb9yraPW/FjvvK713YYRZkKQ8BzUir4F2ZNpQcVTs2jEvwb yOYPq2pA37mfrTRavoVtN6B3eMNE2yUn+OhNSB1AUXxLAaAaMLeAethvULwvPQIL5kFu N2BOujmfSP4rRmCiRoz1sGlPrDG8vJtWlzREfft1nRbTkXm5oG+jkTQ7CeiM8yd+EDeM P4E/Qn8lwyPvBeb+3e+X18YT8T3GTk+lHKcAYoBfYQnmMf8292VtfRRFolThkLI6oOnu 4aQQ== 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; bh=eh5rMSih6Lydn0o0VZFUTqj9Enwcn3tkgEdt8E0oDdA=; b=d65QgPKvah7L3pIbdrQYOBwxkdTrlTae6X9CUiKtsEaZ7R1I4XXWhK+fg5Tylz/B+4 tNuXy1Of3QyMs8JRLfJW/gX86OUPRfNwNp5dlZl6bb6BlvrwJPAs/sN5stoGX2dBMn64 t10swlkoZNksecwjvkCR+RJiAzzAQ6TeVpEfsCj2SL3PlKEyYbhPDOl0JPNvXy0mBaf8 25+esGtdhaaDzCUM075HMJVCGHKyFeYEgrQ9D3uxq4wbBBqtl09b8k7UpY77a4bS0+6T 2uPOvw8dXeaE3kXw6/YIPJ8LhqMUTyltrhs0AHI0bglBcEAZQ8NO5imRmrRu1hBIxDsA jhEA== X-Gm-Message-State: ALyK8tLx7hCilCGvin+kRv+NTwzqnHoMQrOU4naDQUp1bKVYmWzXtyZepkKnZfg6koJtZ8PHbUSRw0GwddjCZg== MIME-Version: 1.0 X-Received: by 10.194.79.69 with SMTP id h5mr26105249wjx.129.1464561005924; Sun, 29 May 2016 15:30:05 -0700 (PDT) Received: by 10.194.222.228 with HTTP; Sun, 29 May 2016 15:30:05 -0700 (PDT) Date: Mon, 30 May 2016 00:30:05 +0200 Message-ID: Subject: 2 config files not installed from recent 11-current snapshot From: Ben Woods To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 22:30:07 -0000 Hi everyone, I recently reinstalled my FreeBSD laptop using a 11-current snapshot from the end of April. Today I noticed that 2 cofiguration files were not install in the system: /etc/ppp/ppp.conf /etc/dma/dma.conf I have done 2 PkgBase upgrades since then (with an etcupdate run also after each upgrade), but PkgBase shouldn't have touched these files since config files are not included in packages yet. Given that FreeBSD 11 is nearing release, it might be worth double checking that this isn't a problem on the latest 11 snapshots (those 2 files are on the system after the installer is run). I would check myself, but am travelling and don't have the resources, sorry. Cheers, Ben -- -- From: Benjamin Woods woodsb02@gmail.com From owner-freebsd-current@freebsd.org Sun May 29 22:35: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 CDA7DB54742 for ; Sun, 29 May 2016 22:35:34 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id BF6691D23; Sun, 29 May 2016 22:35:34 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id 811F118E1; Sun, 29 May 2016 22:35:34 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Sun, 29 May 2016 22:35:33 +0000 From: Glen Barber To: Ben Woods Cc: FreeBSD Current Subject: Re: 2 config files not installed from recent 11-current snapshot Message-ID: <20160529223533.GF80759@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XIiC+We3v3zHqZ6Z" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 22:35:34 -0000 --XIiC+We3v3zHqZ6Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 30, 2016 at 12:30:05AM +0200, Ben Woods wrote: > Hi everyone, >=20 > I recently reinstalled my FreeBSD laptop using a 11-current snapshot from > the end of April. >=20 > Today I noticed that 2 cofiguration files were not install in the system: > /etc/ppp/ppp.conf > /etc/dma/dma.conf >=20 > I have done 2 PkgBase upgrades since then (with an etcupdate run also aft= er > each upgrade), but PkgBase shouldn't have touched these files since config > files are not included in packages yet. >=20 > Given that FreeBSD 11 is nearing release, it might be worth double checki= ng > that this isn't a problem on the latest 11 snapshots (those 2 files are on > the system after the installer is run). I would check myself, but am > travelling and don't have the resources, sorry. >=20 FWIW, the 11.0 snapshots do not use the pkgbase stuff for anything. The problem here, I *think*, is that dma.conf is part of the FreeBSD-dma package. This is primarily the underlying issue with everything else in /etc - for pkgbase, they are handled by "install*" targets, but the tools used to merge these files (etcupdate(8) and mergemaster(8)) deal with files handled by the "distrib*" targets ('make distribution'). I'm not sure why ppp.conf wasn't installed though. I'll look into this. Thank you for the report. Glen --XIiC+We3v3zHqZ6Z Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXS26rAAoJEAMUWKVHj+KT4ooP/1VtbryREc6CPBXx+fPUVGJN tioTwe2zh0RSnF9thnOc5D5AQEnuUOph10EMjuMy0XWgJ15PEROaEPP9AgmRJClD Z/SODQ9juLf+eU2AXXYExPAOcRuGhISz/X4gsYxTBHx60cy1isypaijWzI2UhSKH f1iVTWyxtQ4VbecurJSBw474evnFVIrUDUWcwUbjppgsr07m5WRTq4UjdK2PYnK8 nSMsTgfw/antbj+Ro1PCAOiU3FKV5OqRvS0//ImqYmdupetwFvxF6Aiy7Mcn+bsv 0wp6EQ8hFkv0IlezbiLKvC4wspe4mInnk9/SMOKOVhcLoL5kWwOHLsIH2k/3OAu4 iCOM2CULjsrOaPcmjoQVzw/7sQq9whjI1gFXSSR6SCewoGbcTNWDxId9KjRY0WAq jIOq92slQWWZht3CUEd/dni2z5p0WSAeqCe958Ex2PrCQwGsl3/l0QB7jyiSomYR BHYKo5I0dpseIm8z/uF14I4S9rIcIFnjaLWHitmYHLoXAHlQyuIoZi06/1XNsG6g k228pwlc12v+KiY88tk9m997gQ8+NUhNxIsBmb6V/wewZ7J9GYpx9dt9VrgULcGr Sbkq/IXHP8JcAsbD3AsR9id77B0lyCH9ZBw+en7/avzgXIgqpgmD6Zr9PXXordr1 2SgrSr0Wwa/qIlz2ki03 =ChmE -----END PGP SIGNATURE----- --XIiC+We3v3zHqZ6Z-- From owner-freebsd-current@freebsd.org Sun May 29 22:41: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 4C129B547E1 for ; Sun, 29 May 2016 22:41:17 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 2FAC31FB8; Sun, 29 May 2016 22:41:17 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id E626019CB; Sun, 29 May 2016 22:41:16 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Sun, 29 May 2016 22:41:16 +0000 From: Glen Barber To: Ben Woods Cc: FreeBSD Current Subject: Re: 2 config files not installed from recent 11-current snapshot Message-ID: <20160529224116.GG80759@FreeBSD.org> References: <20160529223533.GF80759@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XRI2XbIfl/05pQwm" Content-Disposition: inline In-Reply-To: <20160529223533.GF80759@FreeBSD.org> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 22:41:17 -0000 --XRI2XbIfl/05pQwm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 29, 2016 at 10:35:33PM +0000, Glen Barber wrote: > On Mon, May 30, 2016 at 12:30:05AM +0200, Ben Woods wrote: > > Hi everyone, > >=20 > > I recently reinstalled my FreeBSD laptop using a 11-current snapshot fr= om > > the end of April. > >=20 > > Today I noticed that 2 cofiguration files were not install in the syste= m: > > /etc/ppp/ppp.conf > > /etc/dma/dma.conf > >=20 > > I have done 2 PkgBase upgrades since then (with an etcupdate run also a= fter > > each upgrade), but PkgBase shouldn't have touched these files since con= fig > > files are not included in packages yet. > >=20 > > Given that FreeBSD 11 is nearing release, it might be worth double chec= king > > that this isn't a problem on the latest 11 snapshots (those 2 files are= on > > the system after the installer is run). I would check myself, but am > > travelling and don't have the resources, sorry. > >=20 >=20 > FWIW, the 11.0 snapshots do not use the pkgbase stuff for anything. >=20 > The problem here, I *think*, is that dma.conf is part of the FreeBSD-dma > package. This is primarily the underlying issue with everything else in > /etc - for pkgbase, they are handled by "install*" targets, but the > tools used to merge these files (etcupdate(8) and mergemaster(8)) deal > with files handled by the "distrib*" targets ('make distribution'). >=20 > I'm not sure why ppp.conf wasn't installed though. I'll look into this. >=20 I just checked the base.txz distribution used by bsdinstall(8), and both of these files are definitely non-existent outside of etcupdate(8). I'll look into this further. Thank you again for reporting this. Glen --XRI2XbIfl/05pQwm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXS3AMAAoJEAMUWKVHj+KT0m8P/jziZdVbjN3vtva6tK5BRc0m prCPhEXdzi6K20F6g6GK82bIED/Og9GIzkWQOE5cOeHdYh6l4lzKwNgd6b9B6adc axDFl6Hkfypfl9XkX/hq2//3aw7/RlQhCZqgn4dIktaKwecGdmDoSYKY9bQJa6co 64POHAWO6EGxRs5f0s3mTh4oQkKvv+D3Vb1yWb0tOpeGvJOHCOKOg388I3kkn/Zc kC1T9uZ/hu3KV7tlECPmFthPvOI4LrTZUeSnyZ5UMNiZKNGoVv5yrtrJwzl1SrNv xjHMo+sUYBEGjcdM+HRCnH/v282YZgN0PZWRkpaihSK2uFyQ8oScsmG5w3hBus2t Bwm/JzWoLlFuzu2+BiBOdnyIKCH1IS7gzGcVcYdlS6DeZKaQR8qOgzsv58dwDcS4 VoXx7Gj4edTx/pJaGqvF7SXNqdtVnyVoUdoFz/ZARe5OhZ7jqdNBOLfVQ+TQTxys XzP1HmxV4+RVlSaMW0PgZkp7VZAV9WuOnv0K+eXOBJE4zyrCvECc2UvrX8SLFH4G rdEB83/yELz34RWjo+FlIeaGDiKq8usauTylUbDX497f9J+1pjFnVD8TVPYy4pof oqT7fQ9Hg1HHZ11t45Kjk9EfMMwazf3hUpSwsE5yplRtQsiv+xxdbjUQ0fSVPl/8 Tx8XbQXQ79MWn5Ykj4ML =Q9Yd -----END PGP SIGNATURE----- --XRI2XbIfl/05pQwm-- From owner-freebsd-current@freebsd.org Sun May 29 22:53: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 2B356B54B08 for ; Sun, 29 May 2016 22:53:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-181.reflexion.net [208.70.211.181]) (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 D4B0217EE for ; Sun, 29 May 2016 22:53:23 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5282 invoked from network); 29 May 2016 22:53:12 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 29 May 2016 22:53:12 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Sun, 29 May 2016 18:53:14 -0400 (EDT) Received: (qmail 25425 invoked from network); 29 May 2016 22:53:13 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 29 May 2016 22:53:13 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 7ADE2B1E002; Sun, 29 May 2016 15:53:11 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [CFT] WITH_META_MODE: Working incremental build [only on i386 and amd64] Date: Sun, 29 May 2016 15:53:15 -0700 Message-Id: Cc: Bryan Drewery , FreeBSD PowerPC ML , freebsd-arm To: FreeBSD Current Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 22:53:24 -0000 Quoting the original note about WITH_META_MODE ( = https://lists.freebsd.org/pipermail/freebsd-current/2016-May/061481.html = ): > You will also need to load the filemon(4) module with 'kldload = filemon'. But head's sys/modules/Makefile says: > .if defined(MODULES_OVERRIDE) && !defined(ALL_MODULES) > SUBDIR=3D${MODULES_OVERRIDE} > .else > SUBDIR=3D \ . . . > ${_filemon} \ . . . > .if ${MACHINE_CPUARCH} =3D=3D "i386" || ${MACHINE_CPUARCH} =3D=3D = "amd64" . . . > _filemon=3D filemon . . . as the only contexts that provide a filemon.ko to use with kldload. Thus, for example, arm variants (32 bit and 64 bit) and powerpc variants = (32bit and 64 bit) do not have WITH_META_MODE as an option as things are = set up. I had been hoping to cut down on the time for clang-related rebuilds = during native buildworld runs on my slower buildworld contexts = (armv7a/cortex-a7, powerpc, powerpc64). But it was not to be. It appears that, once some arm variants are officially tier 1, = WITH_META_MODE will not span all tier 1 platforms. [Since I tend to use non-tier-1 platforms I tend to notice some of the = statements about FreeBSD that are true of only tier 1 without being = explicit about it. But initially it takes some research to discover that = status for each such point. WITH_META_MODE is an example.] =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sun May 29 22:56:44 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 66CBDB54CE5 for ; Sun, 29 May 2016 22:56:44 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 4D14A1B79; Sun, 29 May 2016 22:56:44 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id 0DA9A1EAB; Sun, 29 May 2016 22:56:44 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Sun, 29 May 2016 22:56:41 +0000 From: Glen Barber To: Ben Woods Cc: FreeBSD Current Subject: Re: 2 config files not installed from recent 11-current snapshot Message-ID: <20160529225641.GI80759@FreeBSD.org> References: <20160529223533.GF80759@FreeBSD.org> <20160529224116.GG80759@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Encpt1P6Mxii2VuT" Content-Disposition: inline In-Reply-To: <20160529224116.GG80759@FreeBSD.org> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 22:56:44 -0000 --Encpt1P6Mxii2VuT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 29, 2016 at 10:41:16PM +0000, Glen Barber wrote: > On Sun, May 29, 2016 at 10:35:33PM +0000, Glen Barber wrote: > > On Mon, May 30, 2016 at 12:30:05AM +0200, Ben Woods wrote: > > > Hi everyone, > > >=20 > > > I recently reinstalled my FreeBSD laptop using a 11-current snapshot = =66rom > > > the end of April. > > >=20 > > > Today I noticed that 2 cofiguration files were not install in the sys= tem: > > > /etc/ppp/ppp.conf > > > /etc/dma/dma.conf > > >=20 > > > I have done 2 PkgBase upgrades since then (with an etcupdate run also= after > > > each upgrade), but PkgBase shouldn't have touched these files since c= onfig > > > files are not included in packages yet. > > >=20 > > > Given that FreeBSD 11 is nearing release, it might be worth double ch= ecking > > > that this isn't a problem on the latest 11 snapshots (those 2 files a= re on > > > the system after the installer is run). I would check myself, but am > > > travelling and don't have the resources, sorry. > > >=20 > >=20 > > FWIW, the 11.0 snapshots do not use the pkgbase stuff for anything. > >=20 > > The problem here, I *think*, is that dma.conf is part of the FreeBSD-dma > > package. This is primarily the underlying issue with everything else in > > /etc - for pkgbase, they are handled by "install*" targets, but the > > tools used to merge these files (etcupdate(8) and mergemaster(8)) deal > > with files handled by the "distrib*" targets ('make distribution'). > >=20 > > I'm not sure why ppp.conf wasn't installed though. I'll look into this. > >=20 >=20 > I just checked the base.txz distribution used by bsdinstall(8), and both > of these files are definitely non-existent outside of etcupdate(8). >=20 > I'll look into this further. Thank you again for reporting this. >=20 Ugh, I see the problem. It's the problem as described above, but I was not aware these two files were still being handled this way. Working on a fix now, but it will take a bit of time since I need to go through commit logs to find what else is being handled like this that went unnoticed (there were a few similar cases that were fixed already). Glen --Encpt1P6Mxii2VuT Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXS3OpAAoJEAMUWKVHj+KT1mcP/21xrhlgfKhB8temhqzFSG/U TnUqBa0JPx6LCmJQrcgujOxCR1YURKIjTrHBp08AananKLzo4xFrrW8I3eLiwydo ZMuHFWm6aNs0i2Ndp3ldNQ9zRCGfXET1ExtBHCY11LseDOTG/DykiPvWU90dZWGe 2OLUuEAVYc2CtOIPvsHCVBTdIbC0Yljf8riEoCaRqUaWzrZrMonVkp+GkqePQ7xp 4Zf1UrX4b40x1InWQ6SEaWcD6mCZfvNRRvu+eW9nZ4gy7CX8T7UEWHjLcIMMlPD1 Eg0YHz9lp+s7wjAOspSSqO5ZV1fk4RxpM6nhexwAlyQdhtugLhm1d/qidqR7RcWG 62tsi5JOyRRzNvvvyi035q9up/NGsFF8hPYbWavzmRUPe13HntK62wP7PHk5caYE VMTejaRm6c/NnvV86SK/Q9CcTkAcSq6U0Urivl9ajrjdVvs4lva5HPvWa41QF4kZ c17tpNRGLC47NU9EyHv2Qy38E/Kj+jdPO8hxMieZ2nif4rhTejXv162pB6tY5hYU 0iQAxxCoDHBH124rKY6c01Gl1QKI3C5Q3R8mJ/IefIHMN6kJluVOBQLMhMbcna9V Ev0xDu4CxIepij9xW5zZSVZ26URIW/y1qwDJg/ndIxlJM88CzD3qCShb+ILBxwNj K3e2tHSejEoMKOrolU/A =Vfi6 -----END PGP SIGNATURE----- --Encpt1P6Mxii2VuT-- From owner-freebsd-current@freebsd.org Mon May 30 01:01: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 2BA83B4FAEF for ; Mon, 30 May 2016 01:01:12 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EBA4E10B8 for ; Mon, 30 May 2016 01:01:11 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-it0-x22f.google.com with SMTP id e62so26621890ita.1 for ; Sun, 29 May 2016 18:01:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=+Iw+Aovxqu6HzaVyDdxrHC/TYvS5PARQmwlyatAgL1s=; b=P1Rezzqdtfo1KV4VmXbMVSHCFnfDpziHOsRGrWCxZnHtsP2ZKh6I+O/k24UTYfE0TF vhpC7IA1I1MLtyxV9Rkvbp8BNrIagsKvjLsayD7VZ0Qyr5ecy8DzhJzcZEHx9PRvk2Q+ IA/T/dpmpT+ODo2+JuYzAIiqZ7d9eZWI0uMu5yPe76yyyrG5F1BaC6L61hlJA4JyiuHS Rn7tO46AuijOHphu4fmB2IdvQC20EJTMrUB9HNd86C/cLjyGkkD09w43xm5D1deGkkYA Hhqi7qqE9AmMSjjL6U9w2LGXnGBCHrMpp0TTYFRrmvoEscwyfs/KyTbSuYkIvhkVfJeP 3/SQ== 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; bh=+Iw+Aovxqu6HzaVyDdxrHC/TYvS5PARQmwlyatAgL1s=; b=W2OmxVguzdYzgYu3KZRe7m5+FXi48B8rsPwoQi7TZKqKaqTcCHDBz9t58Rflhk+sGw j+kd1aw55Ask3x8IWLkXusvWxBD0J46SPsv8baHbmigLwFvDzy9tZBkQ3iF+M8ewmek7 anWALO9bAu5Qs3V+Y3N3wBT/R5q/1AYBeQIIMF35T3e/E3CwJ3LrZ5I3bkV/Jl+YzWok bDA2f+SPwuLp7hNu0ZVcdmLEopOs+VfeYKJNW6nJsW/pWL/h0sKsjE1boiEifH27TJAs 6cotl9AozW0cPysrlC0ukgDQyJKCTy2vP1wJQFlgV43Onfa2Ha0mg2Lq+wfIquNTgihF h6BQ== X-Gm-Message-State: ALyK8tJwCo2SMHyJ+x7mSd3CYt9tuNBvBRPvPSgyIq6R3MbSyAQ7Kbfb45Wa8mCOl0+y74VGeiC3hdBMrWLhRA== MIME-Version: 1.0 X-Received: by 10.36.83.65 with SMTP id n62mr5434073itb.71.1464570071025; Sun, 29 May 2016 18:01:11 -0700 (PDT) Received: by 10.36.113.3 with HTTP; Sun, 29 May 2016 18:01:10 -0700 (PDT) In-Reply-To: References: Date: Sun, 29 May 2016 18:01:10 -0700 Message-ID: Subject: Re: if_iwn dhcp troubles From: Adrian Chadd To: Ronald Klop Cc: freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 01:01:12 -0000 ok, so there seem to be more lingering 802.11n issues. can you tell me mrore about the environment there, so I can try to duplicate it? I'd like to fix whatever 11n issues there are in iwn! Thanks! -a On 29 May 2016 at 14:27, Ronald Klop wrote: > On Sun, 29 May 2016 19:59:05 +0200, Adrian Chadd > wrote: > >> hi, >> >> Do ifconfig wlan0 -ht (ie, disable 11n) >> >> see if that helps > > > Hi, > > This does make the errors go away and startup more smoothly. > > Regards, > Ronald. > > > >> >> >> -a >> >> >> On 29 May 2016 at 05:46, Ronald Klop wrote: >>> >>> Hello, >>> >>> My laptop has troubles obtaining an ip address on the wlan0 (if_iwn). The >>> interface has trouble staying up during dhcp resolving. Below some >>> information from logs. *If* it obtains an IP address it seems quite >>> stable >>> afterwards. >>> Before https://svnweb.freebsd.org/base?view=revision&revision=300732 I >>> had >>> to reboot a couple of times before it would happen to get an IP address. >>> >>> If I need to supply more information please tell. I'm willing to test >>> patches also. >>> >>> Regards, >>> Ronald. >>> >>> >>> From uname -a: >>> FreeBSD sjakie.klop.ws 11.0-ALPHA1 FreeBSD 11.0-ALPHA1 #7 r300901M: Sat >>> May >>> 28 16:54:00 CEST 2016 >>> root@sjakie.klop.ws:/usr/obj/usr/src/sys/GENERIC-NODEBUG amd64 >>> >>> From dmesg: >>> iwn0: mem 0xf8000000-0xf8001fff irq 17 at >>> device 0.0 on pci2 >>> >>> From /etc/rc.conf. >>> wlans_iwn0="wlan0" >>> create_args_wlan0="wlanaddr 00:26:b9:12:40:a4 country NL" >>> ifconfig_wlan0="WPA" >>> ifconfig_wlan0="$ifconfig_wlan0 SYNCDHCP" >>> >>> From console.log: >>> May 29 13:34:45 sjakie kernel: Created wlan(4) interfaces: wlan0. >>> May 29 13:34:45 sjakie kernel: Starting wpa_supplicant. >>> May 29 13:34:45 sjakie kernel: Starting dhclient. >>> May 29 13:34:45 sjakie kernel: wlan0: no link ... >>> May 29 13:34:45 sjakie kernel: .. >>> May 29 13:34:45 sjakie kernel: ... >>> May 29 13:34:45 sjakie kernel: got link >>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>> port >>> 67 >>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>> port >>> 67 >>> May 29 13:34:45 sjakie kernel: wlan0 link state up -> down >>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>> port >>> 67 >>> May 29 13:34:45 sjakie kernel: wlan0 link state down -> up >>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>> port >>> 67 >>> May 29 13:34:45 sjakie kernel: wlan0 link state up -> down >>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>> port >>> 67 >>> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 >>> port >>> 67 interval 6 >>> May 29 13:34:45 sjakie kernel: wlan0 link state down -> up >>> May 29 13:34:45 sjakie kernel: >>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>> port >>> 67 >>> May 29 13:34:45 sjakie kernel: wlan0 link state up -> down >>> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 >>> port >>> 67 interval 15 >>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>> port >>> 67 >>> May 29 13:34:45 sjakie kernel: wlan0 link state down -> up >>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>> port >>> 67 >>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>> port >>> 67 >>> May 29 13:34:45 sjakie kernel: wlan0 link state up -> down >>> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 >>> port >>> 67 interval 4 >>> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 >>> port >>> 67 interval 9 >>> May 29 13:34:45 sjakie kernel: wlan0 link state down -> up >>> May 29 13:34:45 sjakie kernel: >>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>> port >>> 67 >>> May 29 13:34:45 sjakie kernel: wlan0 link state up -> down >>> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 >>> port >>> 67 interval 16 >>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>> port >>> 67 >>> May 29 13:34:45 sjakie kernel: wlan0 link state down -> up >>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>> port >>> 67 >>> May 29 13:34:45 sjakie kernel: wlan0 link state up -> down >>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>> port >>> 67 >>> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 >>> port >>> 67 interval 5 >>> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 >>> port >>> 67 interval 5 >>> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 >>> port >>> 67 interval 11 >>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>> port >>> 67 >>> May 29 13:34:45 sjakie kernel: wlan0 link state down -> up >>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>> port >>> 67 >>> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 >>> port >>> 67 interval 12 >>> May 29 13:34:45 sjakie kernel: DHCPACK from 192.168.1.1 >>> May 29 13:34:45 sjakie kernel: bound to 192.168.1.109 -- renewal in >>> 2147483647 seconds. >>> >>> From messages: >>> May 29 13:34:45 sjakie kernel: wlan0: Ethernet address: 00:26:b9:12:40:a4 >>> May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode >>> rev=0x12a80601 >>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP >>> May 29 13:34:45 sjakie kernel: iwn0: iwn_intr: fatal firmware error >>> May 29 13:34:45 sjakie kernel: firmware error log: >>> May 29 13:34:45 sjakie kernel: error type = "UNKNOWN" (0x00000038) >>> May 29 13:34:45 sjakie kernel: program counter = 0x00009F64 >>> May 29 13:34:45 sjakie kernel: source line = 0x000003C4 >>> May 29 13:34:45 sjakie kernel: error data = 0x0000000000000000 >>> May 29 13:34:45 sjakie kernel: branch link = 0x00009F6000009F60 >>> May 29 13:34:45 sjakie kernel: interrupt link = 0x0000DBEA00000000 >>> May 29 13:34:45 sjakie kernel: time = 54908 >>> May 29 13:34:45 sjakie kernel: driver status: >>> May 29 13:34:45 sjakie kernel: tx ring 0: qid=0 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 1: qid=1 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 2: qid=2 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 3: qid=3 cur=2 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 4: qid=4 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 5: qid=5 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 6: qid=6 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 7: qid=7 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 8: qid=8 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 9: qid=9 cur=81 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 10: qid=10 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 11: qid=11 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 12: qid=12 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 13: qid=13 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 14: qid=14 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 15: qid=15 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 16: qid=16 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 17: qid=17 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 18: qid=18 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 19: qid=19 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: rx ring: cur=39 >>> May 29 13:34:45 sjakie kernel: iwn0: iwn_panicked: controller panicked, >>> iv_state = 5; restarting >>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN >>> May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode >>> rev=0x12a80601 >>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP >>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN >>> May 29 13:34:45 sjakie kernel: iwn0: scan timeout >>> May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode >>> rev=0x12a80601 >>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP >>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN >>> May 29 13:34:45 sjakie kernel: iwn0: scan timeout >>> May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode >>> rev=0x12a80601 >>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP >>> May 29 13:34:45 sjakie kernel: iwn0: iwn_intr: fatal firmware error >>> May 29 13:34:45 sjakie kernel: firmware error log: >>> May 29 13:34:45 sjakie kernel: error type = "UNKNOWN" (0x00000038) >>> May 29 13:34:45 sjakie kernel: program counter = 0x00009F64 >>> May 29 13:34:45 sjakie kernel: source line = 0x000003C4 >>> May 29 13:34:45 sjakie kernel: error data = 0x0000000000000000 >>> May 29 13:34:45 sjakie kernel: branch link = 0x00009F6000009F60 >>> May 29 13:34:45 sjakie kernel: interrupt link = 0x0000DBEA00000000 >>> May 29 13:34:45 sjakie kernel: time = 7464 >>> May 29 13:34:45 sjakie kernel: driver status: >>> May 29 13:34:45 sjakie kernel: tx ring 0: qid=0 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 1: qid=1 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 2: qid=2 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 3: qid=3 cur=2 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 4: qid=4 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 5: qid=5 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 6: qid=6 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 7: qid=7 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 8: qid=8 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 9: qid=9 cur=81 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 10: qid=10 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 11: qid=11 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 12: qid=12 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 13: qid=13 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 14: qid=14 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 15: qid=15 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 16: qid=16 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 17: qid=17 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 18: qid=18 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 19: qid=19 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: rx ring: cur=63 >>> May 29 13:34:45 sjakie kernel: iwn0: iwn_panicked: controller panicked, >>> iv_state = 5; restarting >>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN >>> May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode >>> rev=0x12a80601 >>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP >>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN >>> May 29 13:34:45 sjakie kernel: iwn0: scan timeout >>> May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode >>> rev=0x12a80601 >>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP >>> May 29 13:34:45 sjakie kernel: iwn0: iwn_intr: fatal firmware error >>> May 29 13:34:45 sjakie kernel: firmware error log: >>> May 29 13:34:45 sjakie kernel: error type = "UNKNOWN" (0x00000038) >>> May 29 13:34:45 sjakie kernel: program counter = 0x00009F64 >>> May 29 13:34:45 sjakie kernel: source line = 0x000003C4 >>> May 29 13:34:45 sjakie kernel: error data = 0x0000000000000000 >>> May 29 13:34:45 sjakie kernel: branch link = 0x00009F6000009F60 >>> May 29 13:34:45 sjakie kernel: interrupt link = 0x0000DBEA00000000 >>> May 29 13:34:45 sjakie kernel: time = 69923 >>> May 29 13:34:45 sjakie kernel: driver status: >>> May 29 13:34:45 sjakie kernel: tx ring 0: qid=0 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 1: qid=1 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 2: qid=2 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 3: qid=3 cur=2 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 4: qid=4 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 5: qid=5 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 6: qid=6 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 7: qid=7 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 8: qid=8 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 9: qid=9 cur=81 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 10: qid=10 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 11: qid=11 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 12: qid=12 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 13: qid=13 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 14: qid=14 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 15: qid=15 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 16: qid=16 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 17: qid=17 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 18: qid=18 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: tx ring 19: qid=19 cur=0 queued=0 >>> May 29 13:34:45 sjakie kernel: rx ring: cur=61 >>> May 29 13:34:45 sjakie kernel: iwn0: iwn_panicked: controller panicked, >>> iv_state = 5; restarting >>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN >>> May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode >>> rev=0x12a80601 >>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP >>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN >>> May 29 13:34:45 sjakie kernel: iwn0: scan timeout >>> May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode >>> rev=0x12a80601 >>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to >>> "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Mon May 30 01:05:28 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 97871B4FCD1 for ; Mon, 30 May 2016 01:05:28 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.auburn.protected-networks.net", Issuer "Protected Networks Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6B33F146A for ; Mon, 30 May 2016 01:05:28 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: imb@mail.auburn.protected-networks.net) by mail.auburn.protected-networks.net (Postfix) with ESMTPSA id 44C5A1CC7D; Sun, 29 May 2016 21:05:26 -0400 (EDT) To: freebsd-current Cc: Rick Macklem From: Michael Butler Subject: NFSv4 compatibility with ESX6U2 Openpgp: id=6F63E6399DCC8E3E94D60F0642FF6BAE0442D492 Message-ID: <528532f8-69af-1180-6b7c-fc8ba227d0f6@protected-networks.net> Date: Sun, 29 May 2016 21:05:25 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 01:05:28 -0000 I was just fooling around with ESX this evening and trying to add an NFSv4 mount onto it as extra storage. Curiously, given the correct credentials, it will report the total volume size and free remaining but won't display either files or subdirectories :-( In this case, the underlying file-system is UFS but I was hoping to migrate to a ZFS share once this worked. Is there something I can do to identify the interoperability issue? imb From owner-freebsd-current@freebsd.org Mon May 30 01:20: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 6E879B510C5 for ; Mon, 30 May 2016 01:20:00 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.auburn.protected-networks.net", Issuer "Protected Networks Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 840A51ACB for ; Mon, 30 May 2016 01:19:59 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: imb@mail.auburn.protected-networks.net) by mail.auburn.protected-networks.net (Postfix) with ESMTPSA id 1554E1CC7D; Sun, 29 May 2016 21:19:58 -0400 (EDT) Subject: Re: NFSv4 compatibility with ESX6U2 To: freebsd-current References: <528532f8-69af-1180-6b7c-fc8ba227d0f6@protected-networks.net> Cc: Rick Macklem From: Michael Butler Openpgp: id=6F63E6399DCC8E3E94D60F0642FF6BAE0442D492 Message-ID: Date: Sun, 29 May 2016 21:19:57 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <528532f8-69af-1180-6b7c-fc8ba227d0f6@protected-networks.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 01:20:00 -0000 On 05/29/16 21:05, Michael Butler wrote: > I was just fooling around with ESX this evening and trying to add an > NFSv4 mount onto it as extra storage. Curiously, given the correct > credentials, it will report the total volume size and free remaining but > won't display either files or subdirectories :-( > > In this case, the underlying file-system is UFS but I was hoping to > migrate to a ZFS share once this worked. > > Is there something I can do to identify the interoperability issue? Never mind - I got it working with the username set to "user@domain" .. imb From owner-freebsd-current@freebsd.org Mon May 30 01:34: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 354A5B5151F for ; Mon, 30 May 2016 01:34:32 +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 84F4E12E7; Mon, 30 May 2016 01:34:31 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-225-151.lns20.per1.internode.on.net [121.45.225.151]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u4U1YPnB026904 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 29 May 2016 18:34:28 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: pkg chroot issues? To: Tim Kientzle References: <9BC1A0E1-696D-4C00-B8C8-B57C4DB3A8EF@kientzle.com> <20160522203108.GE11189@ivaldir.etoilebsd.net> <20160522203243.GF11189@ivaldir.etoilebsd.net> <8886a4b1-492b-61ea-90ea-7e694311d03b@freebsd.org> <07425DF9-AD45-49FD-AC9B-DEF39BDAA10E@kientzle.com> Cc: "bapt@freebsd.org" , FreeBSD current From: Julian Elischer Message-ID: Date: Mon, 30 May 2016 09:34:19 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <07425DF9-AD45-49FD-AC9B-DEF39BDAA10E@kientzle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 01:34:32 -0000 On 30/05/2016 12:33 AM, Tim Kientzle wrote: >> On May 29, 2016, at 8:55 AM, Julian Elischer wrote: >> >> I was thinking that in order to do this properly the chrooted child should do all it's fetch requests etc via the non-chrooted parent, but that would have probably been a bit too complicated. (including add requests) > How complex would it be to perform all of the fetch requests before chroot? I don't know but you'd have to read the DB in the chroot before knowing what dependencies you need to fix. > > Tim > > > From owner-freebsd-current@freebsd.org Mon May 30 03:05:03 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4B576B5341D for ; Mon, 30 May 2016 03:05:03 +0000 (UTC) (envelope-from jhunt@lynden.on.ca) Received: from mail-yw0-x244.google.com (mail-yw0-x244.google.com [IPv6:2607:f8b0:4002:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2022817F0 for ; Mon, 30 May 2016 03:05:03 +0000 (UTC) (envelope-from jhunt@lynden.on.ca) Received: by mail-yw0-x244.google.com with SMTP id n16so13405588ywd.2 for ; Sun, 29 May 2016 20:05:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lynden-on-ca.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=3VyC9YyAD9KIq9zCf0piS/AT+y921nFNFGGCvCeuFtc=; b=R21S8LujMHCXrKz7VwKsvvQMY7AoSqvovivsaJ59AQkZPS7XQntM4L8XX1f5yJkmh4 2ets5PiLhve/RwKiYdk9zfbaA0O8iO+hfgTi0sKkW9FZQD/nEfI+qu+E1V0hM/EWcGxP OrBX0rFKdUPwxn6fCjqEQPKCRhxRJLB/ELH31xWiizrcDMVtZadMj6IjY5wN3TqX8gKo p3xAZFf3jdv1LfCmWnpSlCdr6zJFP4XED4gP6o90IHOHiKeQ0/1+fHrW0uSq7m0PrN98 VEw5o4oI+ele0P9k1u7lKEkhxkgNKDybl3gN2718YmSRFR2hN0s1ZK9FBD67iNcQKlBf pF5g== 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; bh=3VyC9YyAD9KIq9zCf0piS/AT+y921nFNFGGCvCeuFtc=; b=OcnjzJGjv+gt148DUbKXrTH6Tp5bCLVQ/hwCm5tWBJMVnfCdCdxbgcIWjG6FOvuhkd 3NlZu11q4lJFuJibSF4nJxvsNp7pQ82uK5iRo5id45gUbJnGrbQ390G108fe7likxpAH Y8n5yNt1iJvwZ9ezpxB9Q+2w/fK/Coxrq5Ok6Im7z/K8cfbHS0OkCDzufwAdvyo2NOUD TQ2FRoONeIPaUQ3h0b5u1rJ8RQn9Gq05jijFLS3Qit+VaiEWAvN7HUyypJZWI9fYIzYq cggIspQLdVZA8tic+BCVgRYLoIjBITaK9E3PeU/vvkiqry59ZVjx4ne73+MXqBGBkvWW f/Lw== X-Gm-Message-State: ALyK8tLnp4dnOIxU4w0hQAiS3T2ALjd9pmF1+8wzQ9OLf64kvL7Bl8ADaOWDHNshgQWATeHuM7N1wnFvqg8eig== MIME-Version: 1.0 X-Received: by 10.129.95.84 with SMTP id t81mr2604630ywb.162.1464577502027; Sun, 29 May 2016 20:05:02 -0700 (PDT) Received: by 10.83.57.196 with HTTP; Sun, 29 May 2016 20:05:01 -0700 (PDT) X-Originating-IP: [173.33.69.78] Date: Sun, 29 May 2016 23:05:01 -0400 Message-ID: Subject: Intermittent EFI boot issue? From: Jason Hunt To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 03:05:03 -0000 Intermittently after building world/kernel and installing kernel, upon reboot I sometimes get stuck at: >> FreeBSD EFI boot block Loader path: /boot/loader.efi Initializing modules: ZFS UFS Probing 35 block devices ... done ZFS found the following pools: zroot UFS found no partitions Consoles: EFI console And that's it. Often times it's fixed by rebooting, but sometimes it takes numerous attempts. Patience and cold boot vs warm boot doesn't make a difference and unfortunately there doesn't seem to be any pattern as to how it fixes itself. Eventually the full boot screen appears and I can get in to single user mode to continue installing world. I've only been following current for a couple of months, so I can't say if this is a new problem, but it's happened most (but not every) times I've rebuilt the system. Normal day-to-day rebooting doesn't give me any issues; only when rebuilding. Do I potentially have a buggy EFI firmware (motherboard is an ASUS P8B75-M with latest firmware), or could it be a FreeBSD issue? I'm not even sure how to try diagnosing this or what information would be helpful? Any suggestions are appreciated. - Jason From owner-freebsd-current@freebsd.org Mon May 30 03:12:04 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1DE12B535DD for ; Mon, 30 May 2016 03:12:04 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 0AFFC1EF7; Mon, 30 May 2016 03:12:04 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id BF80B1590; Mon, 30 May 2016 03:12:03 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Mon, 30 May 2016 03:12:00 +0000 From: Glen Barber To: Jason Hunt Cc: freebsd-current@freebsd.org Subject: Re: Intermittent EFI boot issue? Message-ID: <20160530031200.GM80759@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pFpMklMRdxwSC3Yi" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 03:12:04 -0000 --pFpMklMRdxwSC3Yi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 29, 2016 at 11:05:01PM -0400, Jason Hunt wrote: > Intermittently after building world/kernel and installing kernel, upon > reboot I sometimes get stuck at: >=20 > >> FreeBSD EFI boot block > Loader path: /boot/loader.efi >=20 > Initializing modules: ZFS UFS > Probing 35 block devices ... done > ZFS found the following pools: zroot > UFS found no partitions > Consoles: EFI console >=20 > And that's it. >=20 > Often times it's fixed by rebooting, but sometimes it takes numerous > attempts. Patience and cold boot vs warm boot doesn't make a difference > and unfortunately there doesn't seem to be any pattern as to how it fixes > itself. Eventually the full boot screen appears and I can get in to sing= le > user mode to continue installing world. >=20 > I've only been following current for a couple of months, so I can't say if > this is a new problem, but it's happened most (but not every) times I've > rebuilt the system. Normal day-to-day rebooting doesn't give me any > issues; only when rebuilding. >=20 > Do I potentially have a buggy EFI firmware (motherboard is an ASUS P8B75-M > with latest firmware), or could it be a FreeBSD issue? I'm not even sure > how to try diagnosing this or what information would be helpful? >=20 > Any suggestions are appreciated. >=20 I've heard of an issue I've hit only a few times, without being able to=20 reproduce it reliably. When the machine passes POST, could you hold down the spacebar (or other non-character key)? Ideally, it will drop you to the loader prompt and/or ask you what you want to do. Typing 'boot' and hitting '[enter]', if the working theory is correct, should work. If not, we have more than one issue here. Thanks. Glen --pFpMklMRdxwSC3Yi Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXS696AAoJEAMUWKVHj+KToYYP+wevIGamQo/87es9HsyRd8s3 qqjuGbYzR/ZINe760yTXbZM5fcSsht0ts3DCPObSpkL48PC0XXa2FCHgWhqCBB0N 62Hfdr21puVYCkXOf7ntsS+DR1vDOMpe3gsrB9vnw9GrAtBsICVt8PmOezkrS8i8 +1RMZt3+NP/LjO04q7k4ptPMivdCwTJI7AVzJdYBmtOcPOF+VOGlWMNBSet7wx3M TPbEfNVVS5UzkzuHy1QCuBraubYJCnysZQrE/7FAAX/s8KprqTrN8bQhLPJZv1BH YqP5wwLCPXU8hFZsYSp7s7jNzBkz6jGkhuhdGXldN+g3HhU3tQy74dU4x/34dUk6 D3Cg2e7Fhl3JLhAJDyV/GZmtrRuo14kBYb5ZZjc90HcpipH31m9l69BU6B8Gm0bu dZcl5J286TEf8jXLHfPi9XVk68O8wbHIXk7+nH8jiUBHb2ROzdWgHhgVPNzyLsbh 98gXfweyRkM1xv0w9h2+VKpx8LcBt6vXVAWKYZG7tWP3lAbjETV7jCH/QpQa/DRD CPaLTVr66JPlyx05slxM5hzJLI3RXYREnJrggTwmpfxzGDASFLD87zHrqKXZcGJQ c3N9O9sC2tIPRsw/D9eFyzNpg7N3cIdfsYunAJzmQ+p/RHIT5Xpo3B8vbs4q2eFC o70/WryPRcwa+kmNwinV =4Xdy -----END PGP SIGNATURE----- --pFpMklMRdxwSC3Yi-- From owner-freebsd-current@freebsd.org Mon May 30 04:19:58 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 76E06B51479 for ; Mon, 30 May 2016 04:19:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-190.reflexion.net [208.70.211.190]) (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 3C6C21A9D for ; Mon, 30 May 2016 04:19:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 19247 invoked from network); 30 May 2016 04:20:28 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 30 May 2016 04:20:28 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Mon, 30 May 2016 00:20:01 -0400 (EDT) Received: (qmail 580 invoked from network); 30 May 2016 04:20:00 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 30 May 2016 04:20:00 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 38563B1E001; Sun, 29 May 2016 21:19:49 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: 11.0 -r300944 build attempted WITH_META_MODE failed [amd64 targeting powerpc64 via devel/powerpc64-gcc use] From: Mark Millard Date: Sun, 29 May 2016 21:19:54 -0700 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <8A197698-51C7-43F9-9927-465602E19AAE@dsl-only.net> To: FreeBSD Current , Bryan Drewery X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 04:19:58 -0000 This was my first-time-ever WITH_META_MODE attempt. I show a chunk of = the log later below. Retrying without WITH_META_MODE=3Dyes resulted in no problems, unlike = below. A self-hosted powerpc64 11.0 -r300944 build using devel/powerpc64-gcc as = the so-called "cross compiler" also did not have this problem =E2=80=94-bu= t powerpc64 does not have WITH_META_MODE (no filemon.ko to load). [The 2 "no problem" examples suggest that -r300944 has gotten to the = point that xtoolchain like contexts work again [non-META], even self = hosted ones.] Here is the part of the script log around the WITH_META_MODE failure. = The compiles had -v . . . --- ctld.full --- Using built-in specs. COLLECT_GCC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc = COLLECT_LTO_WRAPPER=3D/usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0= /5.3.0/lto-wrapper Target: powerpc64-portbld-freebsd11.0 Configured with: ./../gcc-5.3.0/configure = --target=3Dpowerpc64-portbld-freebsd11.0 --disable-nls = --enable-languages=3Dc,c++ --without-headers --with-gmp=3D/usr/local = --with-pkgversion=3D'FreeBSD Ports Collection for powerpc64' = --with-system-zlib --with-as=3D/usr/local/bin/powerpc64-freebsd-as = --with-ld=3D/usr/local/bin/powerpc64-freebsd-ld --prefix=3D/usr/local = --localstatedir=3D/var --mandir=3D/usr/local/man = --infodir=3D/usr/local/info/ --build=3Dx86_64-portbld-freebsd11.0 Thread model: posix gcc version 5.3.0 (FreeBSD Ports Collection for powerpc64)=20 = COMPILER_PATH=3D/usr/local/powerpc64-freebsd/bin/:/usr/local/libexec/gcc/p= owerpc64-portbld-freebsd11.0/5.3.0/:/usr/local/libexec/gcc/powerpc64-portb= ld-freebsd11.0/5.3.0/:/usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0= /:/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/:/usr/local/lib/g= cc/powerpc64-portbld-freebsd11.0/ = LIBRARY_PATH=3D/usr/local/powerpc64-freebsd/bin/:/usr/local/lib/gcc/powerp= c64-portbld-freebsd11.0/5.3.0/:/usr/obj/xtoolchain/powerpc.powerpc64/usr/s= rc/tmp/lib/:/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib/ COLLECT_GCC_OPTIONS=3D'-isystem' = '/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include' = '-L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib' '-B' = '/usr/local/powerpc64-freebsd/bin/' '-O2' '-pipe' '-I' = '/usr/src/usr.sbin/ctld/../../contrib/libucl/include' '-I' = '/usr/src/usr.sbin/ctld' '-I' '/usr/src/usr.sbin/ctld/../../sys' '-I' = '/usr/src/usr.sbin/ctld/../../sys/cam/ctl' '-I' = '/usr/src/usr.sbin/ctld/../../sys/dev/iscsi' '-g' '-std=3Dgnu99' = '-fstack-protector-strong' '-Wsystem-headers' '-Wall' '-Wno-format-y2k' = '-Wextra' '-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' '-Wno-error=3Dunused-function' = '-Wno-error=3Denum-compare' '-Wno-error=3Dlogical-not-parentheses' = '-Wno-error=3Dbool-compare' '-Wno-error=3Duninitialized' = '-Wno-error=3Darray-bounds' '-Wno-error=3Dclobbered' = '-Wno-error=3Dcast-align' '-Wno-error=3Dextra' '-Wno-error=3Dattributes' = '-Wno-error=3Dinline' '-Wno-error=3Dunused-but-set-variable' = '-Wno-error=3Dunused-value' '-Wno-error=3Dstrict-aliasing' = '-Wno-error=3Daddress' '-v' '-o' 'ctld.full' /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/5.3.0/collect2 = -plugin = /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/5.3.0/liblto_plugin.s= o = -plugin-opt=3D/usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/5.3.0/l= to-wrapper -plugin-opt=3D-fresolution=3D/tmp//ccDS76mK.res = -plugin-opt=3D-pass-through=3D-lgcc -plugin-opt=3D-pass-through=3D-lgcc_s = -plugin-opt=3D-pass-through=3D-lc -plugin-opt=3D-pass-through=3D-lgcc = -plugin-opt=3D-pass-through=3D-lgcc_s = --sysroot=3D/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp = --eh-frame-hdr -V -melf64ppc_fbsd -V -dynamic-linker = /libexec/ld-elf.so.1 -o ctld.full = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib/crt1.o = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib/crti.o = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib/crtbegin.o = -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib = -L/usr/local/powerpc64-freebsd/bin = -L/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0 = -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/lib = -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib chap.o = ctld.o discovery.o isns.o kernel.o keys.o log.o login.o parse.o pdu.o = token.o uclparse.o -lbsdxml -ll -lmd -lsbuf -lutil -lprivateucl -lm = -lssp_nonshared -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc = --as-needed -lgcc_s --no-as-needed = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib/crtend.o = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib/crtn.o GNU ld (GNU Binutils) 2.25.1 Supported emulations: elf64ppc_fbsd elf64ppc elf32ppc_fbsd elf32ppc GNU ld (GNU Binutils) 2.25.1 Supported emulations: elf64ppc_fbsd elf64ppc elf32ppc_fbsd elf32ppcuclparse.o: In function `uclparse_chap': /usr/src/usr.sbin/ctld/uclparse.c:61: undefined reference to = `ucl_object_find_key' /usr/src/usr.sbin/ctld/uclparse.c:68: undefined reference to = `ucl_object_find_key' uclparse.o: In function `uclparse_chap_mutual': /usr/src/usr.sbin/ctld/uclparse.c:91: undefined reference to = `ucl_object_find_key' /usr/src/usr.sbin/ctld/uclparse.c:98: undefined reference to = `ucl_object_find_key' /usr/src/usr.sbin/ctld/uclparse.c:105: undefined reference to = `ucl_object_find_key' uclparse.o:/usr/src/usr.sbin/ctld/uclparse.c:112: more undefined = references to `ucl_object_find_key' follow uclparse.o: In function `uclparse_toplevel': /usr/src/usr.sbin/ctld/uclparse.c:235: undefined reference to = `ucl_iterate_object' /usr/src/usr.sbin/ctld/uclparse.c:278: undefined reference to = `ucl_iterate_object' /usr/src/usr.sbin/ctld/uclparse.c:317: undefined reference to = `ucl_iterate_object' uclparse.o: In function `uclparse_auth_group': /usr/src/usr.sbin/ctld/uclparse.c:396: undefined reference to = `ucl_iterate_object' /usr/src/usr.sbin/ctld/uclparse.c:416: undefined reference to = `ucl_iterate_object' uclparse.o:/usr/src/usr.sbin/ctld/uclparse.c:431: more undefined = references to `ucl_iterate_object' follow uclparse.o: In function `uclparse_target_lun': /usr/src/usr.sbin/ctld/uclparse.c:202: undefined reference to = `ucl_object_find_key' /usr/src/usr.sbin/ctld/uclparse.c:203: undefined reference to = `ucl_object_find_key' uclparse.o: In function `uclparse_target': /usr/src/usr.sbin/ctld/uclparse.c:731: undefined reference to = `ucl_iterate_object' collect2: error: ld returned 1 exit status *** [ctld.full] Error code 1 make[4]: stopped in /usr/src/usr.sbin/ctld 1 error make[4]: stopped in /usr/src/usr.sbin/ctld *** [all_subdir_usr.sbin/ctld] Error code 2 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Mon May 30 05:44: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 C5CE0B5454A; Mon, 30 May 2016 05:44:32 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0143.outbound.protection.outlook.com [157.56.111.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E196A10B9; Mon, 30 May 2016 05:44:31 +0000 (UTC) (envelope-from sjg@juniper.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LqEPjbbTP8rvE6XAO4ecuzP1B1PqMSnVakqR/Tl0ZH8=; b=faUUKUdXPvJDpTL6BphIDgYdzJgqZIPuPa8pyH2oG+qJeCQsPOU+nXfzSPHV0r+lIi8sIwcSBNz2Jr+jcuONP7260lxzbCnRxlCk5N22LVOXHy8Fla0yyU14kYaj96GyavL9PQbf79u9E54QVP0VbPHcR1wYQp6Ct4D+YRk+J4o= Received: from CY1PR05CA0041.namprd05.prod.outlook.com (10.166.186.179) by CY1PR05MB2457.namprd05.prod.outlook.com (10.167.10.14) with Microsoft SMTP Server (TLS) id 15.1.501.7; Mon, 30 May 2016 01:10:50 +0000 Received: from BL2FFO11FD011.protection.gbl (2a01:111:f400:7c09::184) by CY1PR05CA0041.outlook.office365.com (2a01:111:e400:c5a4::51) with Microsoft SMTP Server (TLS) id 15.1.506.9 via Frontend Transport; Mon, 30 May 2016 01:10:50 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.19) smtp.mailfrom=juniper.net; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.19 as permitted sender) Received: from P-EMFE01C-SAC.jnpr.net (66.129.239.19) by BL2FFO11FD011.mail.protection.outlook.com (10.173.161.17) with Microsoft SMTP Server (TLS) id 15.1.497.8 via Frontend Transport; Mon, 30 May 2016 01:10:49 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMFE01C-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 29 May 2016 18:10:48 -0700 Received: from kaos.jnpr.net (kaos.jnpr.net [172.21.16.84]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id u4U1AmJ01535; Sun, 29 May 2016 18:10:48 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 0E19C385508; Sun, 29 May 2016 18:10:48 -0700 (PDT) To: Mark Millard CC: FreeBSD Current , Bryan Drewery , FreeBSD PowerPC ML , freebsd-arm , Subject: Re: [CFT] WITH_META_MODE: Working incremental build [only on i386 and amd64] In-Reply-To: References: Comments: In-reply-to: Mark Millard message dated "Sun, 29 May 2016 15:53:15 -0700." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1700.1464570647.1@kaos.jnpr.net> Date: Sun, 29 May 2016 18:10:48 -0700 Message-ID: <1702.1464570648@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.19; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(199003)(24454002)(189002)(9170700003)(2950100001)(87936001)(6806005)(47776003)(97756001)(92566002)(117636001)(19580405001)(23726003)(189998001)(76506005)(77096005)(81166006)(107886002)(110136002)(586003)(8936002)(86362001)(1220700001)(5003600100002)(8676002)(53416004)(5008740100001)(106466001)(76176999)(2906002)(19580395003)(50226002)(46406003)(105596002)(9686002)(11100500001)(2810700001)(50986999)(4326007)(4001430100002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2457; H:P-EMFE01C-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD011; 1:1vBTMqx58CTP980gKpBvvHODf8yODeotK4IZWKlRDGKygOF9Fld3avz//SO1gn2a1XVwWJmLs6S5vH8w3Pr+3skSU0CkL+oD+FVKyPId2sugjCO/jMKKP+ELacIofsO0navviag/dX4CMq7CKNhqvpCrdHXOf77hWb0guCxz8OeuBxNChI+6zQEeXVWVN0R+OYjmaH4r3KHQ0TUv7p8FNoK8tpHMqtYt55zkJm3Sawp3zeA/llKoE1gGVwLF/UUlyZlPN28QEkFeOEo8Z3fUmlOh5prAtA1Ftf3masfLnhJV6V9TCnRHYsZG3kVX8KnzOLG/LLfcQS0xvd5u7x9+kwVX/e56NLvBrwAGQzqKbm81A1VuozvOKxeTwNEae+hfCgU5CfLLbb+J5zP1iyyhud6EGXblUgAA+9DjgaBAYRHtCETo5CMgM2EnERxTxMN0yV+87CVF1oOFrSyOmD5evzQ0kuWCzwQcRZh1ATPQjklwXuH5Up2KxltshxZs8X+RMFfLUwIqM3mtYb7RyZtwdw== X-MS-Office365-Filtering-Correlation-Id: c02dccab-55ec-42cb-c49f-08d388273d41 X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2457; 2:cDV+jyR0nC9ghtPsFRq9WA+9k1m6GfHdpy8IG/ihvR7cWSNkQmQ4Oq3fmOedE2+bXC/VMD+8a0wOzPlHDoav1cblleskBkqAumZ52YLVl4Qz+bFEEVrhhQXMpYno4ywfug2cglu0KX8UhCJqKip6T36++5OloCREACTqEmpY+MVBJ729kRDVVrQ1+sBLLohf; 3:RNueR20buZ3vVbUpDuZGITIu7wTVRCqI8guNM4egLRj23JnnoYJz1PY843gfCMzXTNQKBzQVvEWcTlppEwrTEOTfZU6hhnLOAYRt+ba3iS7X9SEzn0nDjj0RIMht/rdBhiyWaALinY/whtuuMba7jnQUex5sbscMj37+FxJ21DS3/A41LXBmbxRB2FtH9WRu2Px4dv96c+m5NMKE4LKxyuTyb8gEv1Dld4Ezcj8uDGE= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR05MB2457; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2457; 25:SOUBUuyjE6RjzXo4M4pNwKuIUDcorZbLQ2i/WhImnQWvfHr8sUlv5H3mkeC48m3kbgfXCFdMFsIV8jczPiHktixTwAhZ3kUyWx+e8fjqsVlWSxysfw6zY7Oqh+IxD/BDLeqRcHUBD/J2YT9NRwJcGLw8816ka6YYFudKdJay+y5Wxjcn3wbM31LtF5LlpHHM2QQd6UZv3CYX6s7jO+DYzpu7nXvNhVJgMLiC8dKGvVxmFizJgyVrSRZd0GGFQPx8/hkLy/09NfkI0P66+rylznXF8L2cqJuoPZO9e1AZ7cIPQPha7e7wwE1qHgDLzM42KEvPto/+/Vlbq+JznY1WOMby8USDGd/hPe5H//VmfY3x++X1jpI4v6Nyki86/6UiBOPdKPHfgQ3ZBangAqqLgipyJNxwGt+m4oRKbeICRFgLUsbjQXOtkn4CpCPcl3xyc8QdZ0cb8T7SsGhgVLFgzzvrewn/o7or5c82c0H5wzxOryerG4whctp0wDU+FGtjK9ifXVoN9985U7b1lQsKBrwtE+E1Q844Vz/XF4ZuW+lMpHvCXbse+ZV7OTf0Rje4d9lrV0Diy+3MrtztAvfi1F9Mr8Ba3Obbp9mTJNFhjDDI9QfRUF2eSRh4ZKB8T+RWGBcQz2Xw3oMMtWb4HBLIwHX3NFTb8W9GB1y+qhcoUbIn/A72c9FcWTBQ1P3VveGnWJYMO5dyCWtcFZXpLYOQHox3mdkofHOd1WIqchyLYoU= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2457; 20:qgv2tkmlcV3+ixPvtYje4VVpYtnvuYr0VZGsX2cwpU5f3Zu4MYZU/bOGy429/gRgqGAM01pRCWtlI4DMupkJgUYq6sZCL/cdGQnvKM48x+g9PU6zDScI2lMsI23Hoy5wVLRfWbnf3sD1gh1ozH0MiDxSB74RLy7V7gMb3Et2dU8OFJk29gOVX/I23YRfsE1yBpko4pyzLVQJKDBEmFigA8OlMZJZS+iqXbXuMV2ry8WKb0nqF77SwCBHIl44YqyU6rY4XqPlri4obNOaRj/UzBnYiZFBlyD7nV6P73S2lkLZP1Ot6qLZukzYgZ5puxWJQQ4biXmdHmeh3V6oFIefbH1uR9ab98NvECrKd4IkrX85O8Sg4H1fFBpCOn+EAdDN0C9y5CrEO0/Ua12CJf4Gx7iSha0ey1N1OVyNjYwNgsb55qaHULD4fMAGuRg9o7WLGAnXERgUIPnbKC3JsugUK//qsqod/WU+Fe9reBHEN0ocZlsn1IjI5E8jGBeT9fjf X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13023025)(5005006)(13018025)(13017025)(13024025)(8121501046)(13015025)(10201501046)(3002001)(6055026); SRVR:CY1PR05MB2457; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2457; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2457; 4:WyvRhZ13W4I6hm8gtjddhmVTk8J1BUAGDiCj7KHhDSPIUGuPe+33S+CmvaP+nZoJRx7ReyReVOt0mw0eFHhwLUlp03gb8Z31JYyq3Z3XA76yATAnH9Vq44gr2OuxgUN91kpwDZ5CIKk9ndVs9miEbAI8YFGipXUvgyMHh/VOZ1ZskKhwqv3hVLBgUpTP/BJ9Fbp+Ve5wLievrfEzB0NtCe7Z+Qy5dvh1uy4o4gVAES2WGap0tomwSiDvIrb2RfC9Dkrrp8e9Ps79RyhUThD0HwNCRJDITyphIhU7A4Dvew9Xf5Ab9E6/ng6d0qhMhoCVEz1jMaMQuY6/aFMrhgUqqSNIawfkM+1FbQGCSIAHCJGyuOlj7hgl24UNqxBob4LPTcAogIvk4dEwsFM1cdtHKX4/GToNbekOqglxOdkWYAjMrwdbP7KNg0lpmbNAYIZPRWZpOoAaikPgZWd4eobecyfaRzDbbDtwRbJFAJA8QGc= X-Forefront-PRVS: 09583628E0 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2457; 23:qaPVNTH7up2uClGpWQRSDIMjDyy3WwHV6qSrYgcm0?= =?us-ascii?Q?l3RBRXoA1s/3yQOwQZ+RAV2/jtBjD98wuHFNUc4SBqNfSmLGh+wJ2/vrFWRA?= =?us-ascii?Q?0CQNuYN3cBCAI+8U9jfmxcnFmzGGPMVJbWwAMKa3DWiRt0lvIB1HRdj5dd0o?= =?us-ascii?Q?ckfjRFdEuPwJ5qzIRb0huKsQTSP7qOEy7sz9b/57DV962L7WpB5ype7UcRx3?= =?us-ascii?Q?pvWxwZByKEaqUNTPFEosxL6kJRpLRJEdNP/DEy2LfCD4a8so1i0e3mrg4JFf?= =?us-ascii?Q?QTZmFEIOFBkKZ9Cv1azWI+vlrFLHpQZa9EJhEKNbQmSJAYpCK2rlQoRy3caW?= =?us-ascii?Q?ZuBPC69xsni5RbWqJvQID+4vShTdJ/w6yV+swzzluQRQReMPEUQ+CHKbocG1?= =?us-ascii?Q?J5kupvcl8W7stMCA0ZxdS6PGQlgtcr89qz5LO0bbhsqo2uLUUGDli9l4EONZ?= =?us-ascii?Q?7u8d3Zwh5qrUce3+deXxMSacKrARhjN8i/2Ozlrv/pivCwDWp1ztwcs22/40?= =?us-ascii?Q?a9wHSOp8ew090cXnvSHenI6ze4bIDZGCGx4cliDZ0NBkiWayDhmJPj9R2Yrj?= =?us-ascii?Q?S5td392vy1YpmoD/gf/Ueo75v9DzncEaM1+HeF6rkA+EMLyX54o0ZSvncR8n?= =?us-ascii?Q?KWDEDJJBsmA+HW+yVC2s9XvI0RuUmVXVmKHqynM2GQTzQ/CDXUO2V0085F17?= =?us-ascii?Q?+kJTRhEzzRX5N6H47UmhZmz7yrgQvtuFdJEvm3dLV+7faFI9hpEWflUjFSJ8?= =?us-ascii?Q?wv2ipqkLlQzSwJcyBNgOT3FgVk0StMzJhLG+5T2NYsvcDW+G4wv/OEKQYQt7?= =?us-ascii?Q?gCRjv6StHwAtr+2hiR3kj4e7RHrddjmBPY3WSYk2aClIF7mEqJDLU44xGkf/?= =?us-ascii?Q?CsCK9/ti6DEUsZ9r/+Z6K3Y6kFATo0AENiUoD2lDdKggAWti4lNHaFnDlGL2?= =?us-ascii?Q?H+ZgkZvPwfcSB6B20FF+VvSWtqwVqeNhDMfjQzhYSxgmb7TlWzpbfhlZJSVV?= =?us-ascii?Q?y93t6uPK6rlAYYnFKdX8aPpicdwVWQxO1SSlLp/pJ/sZv6L3jkNUsY6DrZHi?= =?us-ascii?Q?mkrv7e4t2gaI6ur2k3K3oU1V+U7S1QfqvNsXfm+QGLuIRLDXyCmsd3JXXRdo?= =?us-ascii?Q?qpSY7ILKhk=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2457; 5:nA+WdqiGvneop5nNTdf4mvVqVMso/yujsvXn73WBgyAJcEGGcCVdDkfgbFYsOPO2w6HmZA9dIB1tIVCafkIOr1TEJhStZEEUT0p0NgFAZN2Z537kGpG5I/tI6m0U91YvK3oTllfw1u/lnhSn5IuI4A==; 24:g+zwhG/SKSoKZMQnWOp9P1P2hYqGmdR+WwK9+7RkEEvqScmKACZL/gOQF17qfw6GCLFMsx3TGSSRxKpHgXFz6UE7JPIbAa1sgBXb0Cs5h7g=; 7:erOxyp+4XEOVi93wE7vdAY9Wga9sB112UepQFd0+Ps0qbpIvtK0F7soSbXI4bl+iUiypoHFVsyKQVf6h9Eewv/UT588VwFIgq9Ml9VrAiMqrTADpCvzsCShUVWUoHHut4RvSx840luOM6Z8HlDEATmzvMViMiGpg5snVbEOINYSpwqBIcmFPOiTgG+6AU2EL SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2016 01:10:49.8450 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.19]; Helo=[P-EMFE01C-SAC.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2457 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 05:44:32 -0000 Mark Millard wrote: > > .if ${MACHINE_CPUARCH} == "i386" || ${MACHINE_CPUARCH} == "amd64" > . . . > > _filemon= filemon > . . . > > Thus, for example, arm variants (32 bit and 64 bit) and powerpc > variants (32bit and 64 bit) do not have WITH_META_MODE as an option as > things are set up. FWIW I'm not aware of any reason that filemon(4) wouldn't work on any architecture. I expect the above restriction is mostly just a reflection of expected build hosts. From owner-freebsd-current@freebsd.org Mon May 30 06:32: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 B493CB54D2D for ; Mon, 30 May 2016 06:32:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-190.reflexion.net [208.70.211.190]) (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 5654F13D8 for ; Mon, 30 May 2016 06:32:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14630 invoked from network); 30 May 2016 06:33:24 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 30 May 2016 06:33:24 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Mon, 30 May 2016 02:32:49 -0400 (EDT) Received: (qmail 3821 invoked from network); 30 May 2016 06:32:49 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 30 May 2016 06:32:49 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 7F73CB1E001; Sun, 29 May 2016 23:32:44 -0700 (PDT) Subject: 11.0 -r300944 buildworld attempt failed [amd64 targeting powerpc via system clang use] Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: Mark Millard In-Reply-To: <8A197698-51C7-43F9-9927-465602E19AAE@dsl-only.net> Date: Sun, 29 May 2016 23:32:50 -0700 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <8A197698-51C7-43F9-9927-465602E19AAE@dsl-only.net> To: FreeBSD Current , Bryan Drewery X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 06:32:59 -0000 [It may well be that powerpc is not an intended cross compile target via = clang since clang is insufficient for an FreeBSD/powerpc ABI compliant = buildworld as stands. Still I use this to illustrate the more general = points for clang use in cross builds.] The failure: > --- libc.so.7.full --- > /usr/bin/ld: unrecognised emulation mode: elf32ppc_fbsd > Supported emulations: elf_x86_64_fbsd elf_i386_fbsd > clang: error: linker command failed with exit code 1 (use -v to see = invocation) > *** [libc.so.7.full] Error code 1 >=20 > make[4]: stopped in /usr/src/lib/libc > 1 error >=20 > make[4]: stopped in /usr/src/lib/libc > *** [lib/libc__L] Error code 2 Note the /usr/bin/ld use: the host (amd64) linker for a powerpc link = operation. The log shows the ld command was via clang=E2=80=99s front end as far as = what the build did directly (just a prefix shown): > --- libc.so.7.full --- > /usr/bin/clang -target powerpc-unknown-freebsd11.0 = --sysroot=3D/usr/obj/clang/powerpc.powerpc/usr/src/tmp = -B/usr/obj/clang/powerpc.powerpc/usr/src/tmp/usr/bin -nodefaultlibs = -Wl,--version-script=3DVersion.map -shared -Wl,-x -Wl,--fatal-warnings = -Wl,--warn-shared-textrel -o libc.so.7.full -Wl,-soname,libc.so.7 = `NM=3D'nm' NMFLAGS=3D'' lorder trivial-vdso_tc.So bt_close.So bt_conv.So = bt_debug.So bt_delete.So bt_get.So bt_open.So bt_overflow.So bt_page.So . . . The -B does not point to a place with a powerpc specific ld command: > # ls -lt /usr/obj/clang/powerpc.powerpc/usr/src/tmp/usr/bin > total 1395 > -rwxr-xr-x 1 root wheel 827248 May 29 22:20 ctfmerge > -rwxr-xr-x 1 root wheel 534712 May 29 22:20 sysinit > -rwxr-xr-x 1 root wheel 960784 May 29 22:20 ctfconvert As far as I can tell a potentially proper path would have been: /usr/local/powerpc-freebsd/bin/ld if a devel/powerpc-binutils port existed and was installed. (No such = port exists.) I do not know if other TARGET_ARCH=E2=80=99s have similar problems or = not (even if they have a binutils port). This was not a WITH_META_MODE=3Dyes context. make.conf was empty and src.conf was: TO_TYPE=3Dpowerpc # KERNCONF=3DGENERICvtsc-NODEBUG TARGET=3D${TO_TYPE} .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITHOUT_CROSS_COMPILER=3D WITH_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D # lldb requires missing atomic 8-byte operations for powerpc (non-64) WITHOUT_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_DEBUG_FILES=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Mon May 30 08:54: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 6C92DB536A7 for ; Mon, 30 May 2016 08:54:36 +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 30D201F02; Mon, 30 May 2016 08:54:36 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1b7Ixv-003NYA-PY>; Mon, 30 May 2016 10:54:27 +0200 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=freyja.zeit4.iv.bundesimmobilien.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (envelope-from ) id <1b7Ixv-003Baz-Fz>; Mon, 30 May 2016 10:54:27 +0200 Date: Mon, 30 May 2016 10:54:21 +0200 From: "O. Hartmann" To: Mark Johnston Cc: "Ngie Cooper (yaneurabeya)" , FreeBSD CURRENT Subject: Re: r 300949: rpcbind rejects to start: couldn't create ip6 socket Message-ID: <20160530105421.75a44be4@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <20160529195035.GA89115@raichu> References: <20160529093230.68a5da55.ohartman@zedat.fu-berlin.de> <20160529133907.4566f2bf.ohartman@zedat.fu-berlin.de> <20160529195035.GA89115@raichu> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 87.138.105.249 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 08:54:36 -0000 On Sun, 29 May 2016 12:50:35 -0700 Mark Johnston wrote: > On Sun, May 29, 2016 at 01:39:07PM +0200, O. Hartmann wrote: > > Recompiled sources with flag -DNO_CLEAN (I mention this because it might > > have impact). > > > > After that, I tried restarting rpcbind via: > > > > root@localhost: [src] service rpcbind restart > > rpcbind not running? > > Starting rpcbind. > > rpcbind debugging enabled. > > can't get local ip6 address: hostname nor servname provided, or not known > > couldn't create ip6 socketSegmentation fault (core dumped) > > /etc/rc.d/rpcbind: WARNING: failed to start rpcbind > > > > > > Now the "segmentation fault" is new. I regret not having the core or any > > more infos on that, I disabled all core dumping options and debugging > > facilities on that host of mine ... > > The segfault should be addressed by r300972 - could you give that > revision a try? [...] I did, and on several systems, the upgrade from r300830 to r300985 went without problems, but the systems I discovered the problem are to be updated this evening. But so far, it seems to be fixed. Thank you very much. From owner-freebsd-current@freebsd.org Mon May 30 11:42: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 95000B5446B for ; Mon, 30 May 2016 11:42:08 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 546211497 for ; Mon, 30 May 2016 11:42:07 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:DhLxbh3j3O2+o7xusmDT+DRfVm0co7zxezQtwd8ZsegQKPad9pjvdHbS+e9qxAeQG96LurQZ0KGN4+jJYi8p39WoiDg6aptCVhsI2409vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6kO74TNaIBjjLw09fr2zQd6DyZnsnLvis7ToICx2xxOFKYtoKxu3qQiD/uI3uqBFbpgL9x3Sv3FTcP5Xz247bXianhL7+9vitMU7q3cY6Lod8JtlUK76dqk8BZZFEDArKShh5cjhnQHZSheC7WcRXiAQnwZXBBLG91f8U4un4QXgse8o4iiRPoXTRLs3XTmnp/NxTRbjiyMKMhYk927Kh8hojORQqUTy9FRE34fIbdTNZ7JFdaTHcIZCSA== X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2A0AgDwJUxX/61jaINTCoQSfQaDPbZBAQ2BeRcLhSVKAoFmFAEBAQEBAQEBZCeCMIIVAQEBAwEBAQEgBCcgCwULAgEIDgoCAg0ZAgInAQkmAgQIBwQBHASIBggOqkyRBgEBAQEBAQEBAQEBAQEBAQEBAQEZBYEBhSaETYQYCwEBBQKDHYJZBYgGkDGGAIUykgqPSgIeAQFCggYcgWcgMgeHcg8XH38BAQE X-IronPort-AV: E=Sophos;i="5.26,389,1459828800"; d="scan'208";a="284734905" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 30 May 2016 07:42:06 -0400 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 6BA9E15F56D; Mon, 30 May 2016 07:42:06 -0400 (EDT) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Hee_JXH9Fnd7; Mon, 30 May 2016 07:42:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id E558315F56E; Mon, 30 May 2016 07:42:05 -0400 (EDT) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id czaerqVRSGxe; Mon, 30 May 2016 07:42:05 -0400 (EDT) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id CB41015F56D; Mon, 30 May 2016 07:42:05 -0400 (EDT) Date: Mon, 30 May 2016 07:42:05 -0400 (EDT) From: Rick Macklem To: Michael Butler Cc: freebsd-current Message-ID: <201770704.121187014.1464608525790.JavaMail.zimbra@uoguelph.ca> In-Reply-To: References: <528532f8-69af-1180-6b7c-fc8ba227d0f6@protected-networks.net> Subject: Re: NFSv4 compatibility with ESX6U2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.10] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF46 (Win)/8.0.9_GA_6191) Thread-Topic: NFSv4 compatibility with ESX6U2 Thread-Index: 9zPZeX7Op0Q+tOgXaaWp7C9CuKlgQQ== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 11:42:08 -0000 Michael Butler wrote: > On 05/29/16 21:05, Michael Butler wrote: > > I was just fooling around with ESX this evening and trying to add an > > NFSv4 mount onto it as extra storage. Curiously, given the correct > > credentials, it will report the total volume size and free remaining but > > won't display either files or subdirectories :-( > > > > In this case, the underlying file-system is UFS but I was hoping to > > migrate to a ZFS share once this worked. > > > > Is there something I can do to identify the interoperability issue? > > Never mind - I got it working with the username set to "user@domain" .. > > If user<->uid mapping keeps giving you grief, you can: sysctl vfs.nfsd.enable_stringtouid=1 on the NFS server and then kill off the nfsuserd on both client and server. (After doing this, the user on the wire is just a string with the uid in it like "102". Same applies to groups.) Also, you need to avoid multiple username->same uid mappings. I delete "toor" from /etc/passwd for example. rick > imb > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Mon May 30 12:37: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 10AAFB517D0 for ; Mon, 30 May 2016 12:37:02 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id F0F481186 for ; Mon, 30 May 2016 12:37:01 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id EC9D3B517CC; Mon, 30 May 2016 12:37: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 EC47FB517CB for ; Mon, 30 May 2016 12:37:01 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B1D1F1185 for ; Mon, 30 May 2016 12:37:00 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id u4UCasAo014096 for ; Mon, 30 May 2016 12:36:54 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id u4UCasQ0014095 for current@freebsd.org; Mon, 30 May 2016 05:36:54 -0700 (PDT) (envelope-from david) Date: Mon, 30 May 2016 05:36:54 -0700 From: David Wolfskill To: current@freebsd.org Subject: Unable to load freshly-built nvidia.ko @r300994. Message-ID: <20160530123654.GW1080@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="DWqF7Vcvgq9cBwZ0" Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 12:37:02 -0000 --DWqF7Vcvgq9cBwZ0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Today's "daily update" for head was from: FreeBSD g1-252.catwhisker.org 11.0-ALPHA1 FreeBSD 11.0-ALPHA1 #432 r300951= M/300951:1100114: Sun May 29 04:44:37 PDT 2016 root@g1-252.catwhisker.o= rg:/common/S4/obj/usr/src/sys/CANARY amd64 to: FreeBSD g1-252.catwhisker.org 11.0-ALPHA1 FreeBSD 11.0-ALPHA1 #433 r300994= M/300994:1100115: Mon May 30 04:21:30 PDT 2016 root@g1-252.catwhisker.o= rg:/common/S4/obj/usr/src/sys/CANARY amd64 (See for the update history for FreeBSD-11 on this laptop.) The attempt to load nvidia.ko yielded (from dmesg.boot): linker_load_file: Unsupported file type lock order reversal: 1st 0xfffffe05c2224420 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3512 2nd 0xfffff80009619600 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhas= h.c:281 stack backtrace: #0 0xffffffff80a6a0d0 at witness_debugger+0x70 #1 0xffffffff80a69fc4 at witness_checkorder+0xe54 #2 0xffffffff80a13242 at _sx_xlock+0x72 #3 0xffffffff80d02857 at ufsdirhash_remove+0x37 #4 0xffffffff80d05a27 at ufs_dirremove+0x127 #5 0xffffffff80d0d04e at ufs_rename+0x135e #6 0xffffffff80f4c5a0 at VOP_RENAME_APV+0x100 #7 0xffffffff80ad7c78 at kern_renameat+0x4a8 #8 0xffffffff82c9e5b9 at filemon_wrapper_rename+0x19 #9 0xffffffff80e04c06 at amd64_syscall+0x2f6 #10 0xffffffff80de4bdb at Xfast_syscall+0xfb acquiring duplicate lock of same type: "os.lock_sx" 1st os.lock_sx @ nvidia_os.c:603 2nd os.lock_sx @ nvidia_os.c:603 stack backtrace: #0 0xffffffff80a6a0d0 at witness_debugger+0x70 #1 0xffffffff80a69fc4 at witness_checkorder+0xe54 #2 0xffffffff80a13242 at _sx_xlock+0x72 #3 0xffffffff826161e2 at os_acquire_mutex+0x32 #4 0xffffffff82600b38 at _nv010796rm+0x18 ACPI Warning: \134_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Foun= d [Buffer], ACPI requires [Package] (20160527/nsarguments-97) ACPI Warning: \134_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Foun= d [Buffer], ACPI requires [Package] (20160527/nsarguments-97) ACPI Warning: \134_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Foun= d [Buffer], ACPI requires [Package] (20160527/nsarguments-97) ACPI Warning: \134_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Foun= d [Buffer], ACPI requires [Package] (20160527/nsarguments-97) ACPI Warning: \134_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Foun= d [Buffer], ACPI requires [Package] (20160527/nsarguments-97) ACPI Warning: \134_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Foun= d [Buffer], ACPI requires [Package] (20160527/nsarguments-97) ACPI Warning: \134_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Foun= d [Buffer], ACPI requires [Package] (20160527/nsarguments-97) ACPI Warning: \134_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Foun= d [Buffer], ACPI requires [Package] (20160527/nsarguments-97) ACPI Warning: \134_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Foun= d [Buffer], ACPI requires [Package] (20160527/nsarguments-97) ACPI Warning: \134_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Foun= d [Buffer], ACPI requires [Package] (20160527/nsarguments-97) ACPI Warning: \134_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Foun= d [Buffer], ACPI requires [Package] (20160527/nsarguments-97) acquiring duplicate lock of same type: "os.lock_mtx" 1st os.lock_mtx @ nvidia_os.c:777 2nd os.lock_mtx @ nvidia_os.c:777 stack backtrace: #0 0xffffffff80a6a0d0 at witness_debugger+0x70 #1 0xffffffff80a69fc4 at witness_checkorder+0xe54 #2 0xffffffff809ec894 at __mtx_lock_flags+0xa4 #3 0xffffffff8261653b at os_acquire_spinlock+0x1b #4 0xffffffff823bacc5 at _nv012401rm+0xd75 and from /var/log/messages I see: =2E.. May 30 11:29:31 g1-252 kernel: iwn0: iwn_read_firmware: ucode rev=3D0x08530= 501 May 30 11:29:31 g1-252 kernel: wlan0: link state changed to UP May 30 11:29:31 g1-252 kernel: battery1: battery initialization failed, giv= ing up May 30 11:29:31 g1-252 root: /etc/rc: WARNING: Unable to load kernel module= linux64 May 30 11:29:31 g1-252 kernel: KLD linux64.ko: depends on kernel - not avai= lable or version mismatch May 30 11:29:31 g1-252 kernel: linker_load_file: Unsupported file type May 30 11:29:32 g1-252 dbus[165]: [system] Activating service name=3D'org.f= reedesktop.ConsoleKit' (using servicehelper) May 30 11:29:32 g1-252 dbus[165]: [system] Activating service name=3D'org.f= reedesktop.PolicyKit1' (using servicehelper) May 30 11:29:32 g1-252 dbus[165]: [system] Successfully activated service '= org.freedesktop.PolicyKit1' May 30 11:29:32 g1-252 dbus[165]: [system] Successfully activated service '= org.freedesktop.ConsoleKit' May 30 11:29:32 g1-252 console-kit-daemon[1100]: WARNING: kvm_getenvv faile= d:=20 May 30 11:29:33 g1-252 kernel: KLD rtc.ko: depends on kernel - not availabl= e or version mismatch May 30 11:29:33 g1-252 kernel: linker_load_file: Unsupported file type May 30 11:29:33 g1-252 kernel: lock order reversal: May 30 11:29:33 g1-252 kernel: 1st 0xfffffe05c44508e0 bufwait (bufwait) @ /= usr/src/sys/kern/vfs_bio.c:3512 May 30 11:29:33 g1-252 kernel: 2nd 0xfffff80009369600 dirhash (dirhash) @ /= usr/src/sys/ufs/ufs/ufs_dirhash.c:281 May 30 11:29:33 g1-252 kernel: stack backtrace: May 30 11:29:33 g1-252 kernel: #0 0xffffffff80a66880 at witness_debugger+0x= 70 May 30 11:29:33 g1-252 kernel: #1 0xffffffff80a66774 at witness_checkorder+= 0xe54 May 30 11:29:33 g1-252 kernel: #2 0xffffffff80a0f9f2 at _sx_xlock+0x72 May 30 11:29:33 g1-252 kernel: #3 0xffffffff80cff017 at ufsdirhash_remove+0= x37 May 30 11:29:33 g1-252 kernel: #4 0xffffffff80d021e7 at ufs_dirremove+0x127 May 30 11:29:33 g1-252 kernel: #5 0xffffffff80d0980e at ufs_rename+0x135e May 30 11:29:33 g1-252 kernel: #6 0xffffffff80f49610 at VOP_RENAME_APV+0x100 May 30 11:29:33 g1-252 kernel: #7 0xffffffff80ad4428 at kern_renameat+0x4a8 May 30 11:29:33 g1-252 kernel: #8 0xffffffff821335b9 at filemon_wrapper_ren= ame+0x19 May 30 11:29:33 g1-252 kernel: #9 0xffffffff80e01c06 at amd64_syscall+0x2f6 May 30 11:29:33 g1-252 kernel: #10 0xffffffff80de13ab at Xfast_syscall+0xfb May 30 11:29:34 g1-252 console-kit-daemon[1100]: WARNING: Error waiting for= native console 1 activation: Inappropriate ioctl for device May 30 11:30:07 g1-252 console-kit-daemon[1100]: WARNING: Error waiting for= native console 1 activation: Inappropriate ioctl for device May 30 11:30:07 g1-252 console-kit-daemon[1100]: WARNING: Error waiting for= native console 9 activation: Inappropriate ioctl for device May 30 11:30:22 g1-252 dhclient: /etc/dhclient-enter-hooks invoked with rea= son TIMEOUT May 30 11:30:22 g1-252 dhclient: Ignoring claimed TIMEOUT dhclient invocati= on May 30 11:32:41 g1-252 kernel: KLD nvidia.ko: depends on kernel - not avail= able or version mismatch May 30 11:32:41 g1-252 kernel: linker_load_file: Unsupported file type (I believe the whines at 11:32:41 were from my manual attempt to kldload nvidia.ko, vs. the initial whines from the /boot/loader.conf specification.) A bit more context: * I run xdm(1) on the laptop. Given the circumstances, that didn't work very well; I logged in on vty1 to poke around. * As may be seen from the update history (cited above), I've been doing this sort of thing for "a while", generaly successfully. * I mostly run stable/10 (also updated daily) on the laptop, and build the installed ports under stable/10 -- except for ports with kernel modules (such as nvidia.ko): those get rebuilt whenever I rebuild the kernel, as merely part of the build/install process. * Other than the mere update from r300951 --> r300994, the only difference that comes to mind is that this is the first time I built the system with 'WITH_META_MODE=3Dyes' specified in /etc/src-env.conf. (And yes, it was quite noticably faster to build: thanks, Bryan!) As a reality check: g1-252(10.3-S)[11] sudo find /S4/boot -name nvidia\* -ls Password: 240833 22720 -rwxr-xr-x 1 root wheel = 11592328 May 30 04:22 /S4/boot/modules/nvidia.ko 321843 22720 -rwxr-xr-x 1 root wheel = 11592328 May 29 04:45 /S4/boot/modules.old/nvidia.ko 244000 22720 -rwxr-xr-x 1 root wheel = 11573104 May 18 2015 /S4/boot/modules.save/nvidia.ko g1-252(10.3-S)[12]=20 I'm happy to provide more information (given a hint as to what would be useful) or test. 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. --DWqF7Vcvgq9cBwZ0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJXTDPmXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XjwwIALDCqESHoOYBk2P4fkJGvFqy s1Ywugkik5O3vXVbue/qKCEoRmW2amJ6R5pZqknzOhx6BrO5TbIpwm7fMQfs/4la lgkGlpX6bfopGzwqueKK8PdKvnzGwW/qOUeb/Ey8/+zdygqI/mTKwAAPTdDWcS8f mlSMOn/SPu/ymkFrKV3coWF7rZIO4/NRgtruvNwlljoxQup0qfPeJxom2sLEZKVn ChhOGx6em2mgNFq+qK19487kJShEhrWccLodp4ArZQdyoX6ftYgS7mP4vwSjs1p3 oK/kqIGoiXAUOTFdbEgqscHtWnjDm6RZi9Mmn91q5KT9ZS41uFvYQdFhLJ4ZaEE= =ZGVv -----END PGP SIGNATURE----- --DWqF7Vcvgq9cBwZ0-- From owner-freebsd-current@freebsd.org Mon May 30 14:37:41 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 77A25B54587 for ; Mon, 30 May 2016 14:37:41 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3DEB3105B for ; Mon, 30 May 2016 14:37:40 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [88.217.104.190] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1b7OJs-00047C-Ig for freebsd-current@freebsd.org; Mon, 30 May 2016 16:37:29 +0200 Received: from localhost.my.domain (c720-r292778-amd64 [127.0.0.1]) by localhost.unixarea.de (8.15.2/8.14.9) with ESMTPS id u4UEbRmk002457 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 30 May 2016 16:37:27 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.15.2/8.14.9/Submit) id u4UEbQ7R002456 for freebsd-current@freebsd.org; Mon, 30 May 2016 16:37:26 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Mon, 30 May 2016 16:37:26 +0200 From: Matthias Apitz To: freebsd-current@freebsd.org Subject: r300951 make buildworld duration 18h Message-ID: <20160530143726.GA2418@c720-r292778-amd64.oa.oclc.org> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Operating-System: FreeBSD 11.0-CURRENT r292778 (amd64) User-Agent: Mutt/1.5.24 (2015-08-30) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 88.217.104.190 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 14:37:41 -0000 Hello, Yesterday I pulled via svn co ... a fresh r300951 and started the buildworld as # make -j2 buildworld it ended today at lunchtime after 18 hours. The laptop has 2x Intel Atom 1.6GHz and 1 GByte RAM and was otherwise unused. Is this the normal buildworld time of today? I think it spent most of the time in building the llvm... Thx matthias -- Matthias Apitz, ✉ guru@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 "Die Verkaufsschlager des Buchmarkts geben Auskunft über den Zustand einer Gesellschaft bzw. sind, was diese Zeiten angeht, Gradmesser fortschreitenden Schwachsinns. ..." (jW 19.05.2016) From owner-freebsd-current@freebsd.org Mon May 30 15:09:45 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6E255B54BA1 for ; Mon, 30 May 2016 15:09:45 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.auburn.protected-networks.net", Issuer "Protected Networks Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 44FC21DA7 for ; Mon, 30 May 2016 15:09:45 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: imb@mail.auburn.protected-networks.net) by mail.auburn.protected-networks.net (Postfix) with ESMTPSA id 6E3D51CC37; Mon, 30 May 2016 11:09:42 -0400 (EDT) Subject: Re: r300951 make buildworld duration 18h To: Matthias Apitz , freebsd-current@freebsd.org References: <20160530143726.GA2418@c720-r292778-amd64.oa.oclc.org> From: Michael Butler Openpgp: id=6F63E6399DCC8E3E94D60F0642FF6BAE0442D492 Message-ID: <103248b5-4876-3db2-cb38-3f4a8f680703@protected-networks.net> Date: Mon, 30 May 2016 11:09:41 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160530143726.GA2418@c720-r292778-amd64.oa.oclc.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 15:09:45 -0000 On 05/30/16 10:37, Matthias Apitz wrote: > Yesterday I pulled via svn co ... a fresh r300951 and started the buildworld as > > # make -j2 buildworld > > it ended today at lunchtime after 18 hours. The laptop has 2x Intel Atom 1.6GHz > and 1 GByte RAM and was otherwise unused. Is this the normal buildworld time of > today? I think it spent most of the time in building the llvm... Sadly, this is pretty normal these days :-( It'd be cool if we could drop some of the cross-build targets (like AArch64, AMDGPU, ARM, AVR, Hexagon, MSP430, Mips, NVPTX, PowerPC, Sparc, SystemZ and XCore when on an x86) from machines not in need of them, imb From owner-freebsd-current@freebsd.org Mon May 30 15:22: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 E929EB54F50 for ; Mon, 30 May 2016 15:22:57 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) (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 8B60717BE for ; Mon, 30 May 2016 15:22:57 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from [194.32.164.16] ([194.32.164.16]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id u4UFBFuU030290; Mon, 30 May 2016 16:11:15 +0100 (BST) (envelope-from rb@gid.co.uk) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: r300951 make buildworld duration 18h From: Bob Bishop In-Reply-To: <20160530143726.GA2418@c720-r292778-amd64.oa.oclc.org> Date: Mon, 30 May 2016 16:11:15 +0100 Cc: freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160530143726.GA2418@c720-r292778-amd64.oa.oclc.org> To: Matthias Apitz X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 15:22:58 -0000 HI, > On 30 May 2016, at 15:37, Matthias Apitz wrote: >=20 >=20 > Hello, >=20 > Yesterday I pulled via svn co ... a fresh r300951 and started the = buildworld as >=20 > # make -j2 buildworld >=20 > it ended today at lunchtime after 18 hours. The laptop has 2x Intel = Atom 1.6GHz > and 1 GByte RAM and was otherwise unused. Is this the normal = buildworld time of > today? I think it spent most of the time in building the llvm=E2=80=A6 With 1GB it probably spent a lot of its time swapping. > Thx >=20 > matthias > --=20 > Matthias Apitz, =E2=9C=89 guru@unixarea.de, =E2=8C=82 = http://www.unixarea.de/ =E2=98=8E +49-176-38902045 > "Die Verkaufsschlager des Buchmarkts geben Auskunft =C3=BCber den = Zustand einer Gesellschaft bzw. > sind, was diese Zeiten angeht, Gradmesser fortschreitenden = Schwachsinns. ..." (jW 19.05.2016) > _______________________________________________ > 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" -- Bob Bishop rb@gid.co.uk From owner-freebsd-current@freebsd.org Mon May 30 15:29: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 8D439B54FE2; Mon, 30 May 2016 15:29:47 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 65BCB19A7; Mon, 30 May 2016 15:29:47 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 5211A1BDA; Mon, 30 May 2016 15:29:47 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id F01411D7F7; Mon, 30 May 2016 15:29:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id A446IqALvo5R; Mon, 30 May 2016 15:29:38 +0000 (UTC) Subject: Re: 11.0 -r300944 build attempted WITH_META_MODE failed [amd64 targeting powerpc64 via devel/powerpc64-gcc use] DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 6BE421D7F1 To: Mark Millard , FreeBSD Current References: <8A197698-51C7-43F9-9927-465602E19AAE@dsl-only.net> Cc: FreeBSD Toolchain , FreeBSD PowerPC ML From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: Date: Mon, 30 May 2016 08:29:40 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <8A197698-51C7-43F9-9927-465602E19AAE@dsl-only.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7LtOeSibHtIO8t59R5B8g4SBwcj8du689" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 15:29:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7LtOeSibHtIO8t59R5B8g4SBwcj8du689 Content-Type: multipart/mixed; boundary="lVaeJohqt2ddjA7OEtiafs3N49wEqwKMN" From: Bryan Drewery To: Mark Millard , FreeBSD Current Cc: FreeBSD Toolchain , FreeBSD PowerPC ML Message-ID: Subject: Re: 11.0 -r300944 build attempted WITH_META_MODE failed [amd64 targeting powerpc64 via devel/powerpc64-gcc use] References: <8A197698-51C7-43F9-9927-465602E19AAE@dsl-only.net> In-Reply-To: <8A197698-51C7-43F9-9927-465602E19AAE@dsl-only.net> --lVaeJohqt2ddjA7OEtiafs3N49wEqwKMN Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This failure is not likely related to META_MODE. I should have mentioned that to enable META_MODE after not having it on you should do a 'make cleanworld' first. On 5/29/2016 9:19 PM, Mark Millard wrote: > This was my first-time-ever WITH_META_MODE attempt. I show a chunk of t= he log later below. >=20 > Retrying without WITH_META_MODE=3Dyes resulted in no problems, unlike b= elow. >=20 > A self-hosted powerpc64 11.0 -r300944 build using devel/powerpc64-gcc a= s the so-called "cross compiler" also did not have this problem =E2=80=94= -but powerpc64 does not have WITH_META_MODE (no filemon.ko to load). >=20 > [The 2 "no problem" examples suggest that -r300944 has gotten to the po= int that xtoolchain like contexts work again [non-META], even self hosted= ones.] >=20 > Here is the part of the script log around the WITH_META_MODE failure. T= he compiles had -v . . . >=20 > --- ctld.full --- > Using built-in specs. > COLLECT_GCC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > COLLECT_LTO_WRAPPER=3D/usr/local/libexec/gcc/powerpc64-portbld-freebsd1= 1.0/5.3.0/lto-wrapper > Target: powerpc64-portbld-freebsd11.0 > Configured with: ./../gcc-5.3.0/configure --target=3Dpowerpc64-portbld-= freebsd11.0 --disable-nls --enable-languages=3Dc,c++ --without-headers --= with-gmp=3D/usr/local --with-pkgversion=3D'FreeBSD Ports Collection for p= owerpc64' --with-system-zlib --with-as=3D/usr/local/bin/powerpc64-freebsd= -as --with-ld=3D/usr/local/bin/powerpc64-freebsd-ld --prefix=3D/usr/local= --localstatedir=3D/var --mandir=3D/usr/local/man --infodir=3D/usr/local/= info/ --build=3Dx86_64-portbld-freebsd11.0 > Thread model: posix > gcc version 5.3.0 (FreeBSD Ports Collection for powerpc64)=20 > COMPILER_PATH=3D/usr/local/powerpc64-freebsd/bin/:/usr/local/libexec/gc= c/powerpc64-portbld-freebsd11.0/5.3.0/:/usr/local/libexec/gcc/powerpc64-p= ortbld-freebsd11.0/5.3.0/:/usr/local/libexec/gcc/powerpc64-portbld-freebs= d11.0/:/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/:/usr/local= /lib/gcc/powerpc64-portbld-freebsd11.0/ > LIBRARY_PATH=3D/usr/local/powerpc64-freebsd/bin/:/usr/local/lib/gcc/pow= erpc64-portbld-freebsd11.0/5.3.0/:/usr/obj/xtoolchain/powerpc.powerpc64/u= sr/src/tmp/lib/:/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib= / > COLLECT_GCC_OPTIONS=3D'-isystem' '/usr/obj/xtoolchain/powerpc.powerpc64= /usr/src/tmp/usr/include' '-L/usr/obj/xtoolchain/powerpc.powerpc64/usr/sr= c/tmp/usr/lib' '-B' '/usr/local/powerpc64-freebsd/bin/' '-O2' '-pipe' '-I= ' '/usr/src/usr.sbin/ctld/../../contrib/libucl/include' '-I' '/usr/src/us= r.sbin/ctld' '-I' '/usr/src/usr.sbin/ctld/../../sys' '-I' '/usr/src/usr.s= bin/ctld/../../sys/cam/ctl' '-I' '/usr/src/usr.sbin/ctld/../../sys/dev/is= csi' '-g' '-std=3Dgnu99' '-fstack-protector-strong' '-Wsystem-headers' '-= Wall' '-Wno-format-y2k' '-Wextra' '-Wstrict-prototypes' '-Wmissing-protot= ypes' '-Wpointer-arith' '-Wreturn-type' '-Wcast-qual' '-Wwrite-strings' '= -Wswitch' '-Wshadow' '-Wunused-parameter' '-Wcast-align' '-Wchar-subscrip= ts' '-Winline' '-Wnested-externs' '-Wredundant-decls' '-Wold-style-defini= tion' '-Wno-pointer-sign' '-Wno-error=3Dunused-function' '-Wno-error=3Den= um-compare' '-Wno-error=3Dlogical-not-parentheses' '-Wno-error=3Dbool-com= pare' '-Wno-error=3Duninitialized' '-Wno-error=3Darray-bounds' '-Wno-erro= r=3Dclobbered' '-Wno-error=3Dcast-align' '-Wno-error=3Dextra' '-Wno-error= =3Dattributes' '-Wno-error=3Dinline' '-Wno-error=3Dunused-but-set-variabl= e' '-Wno-error=3Dunused-value' '-Wno-error=3Dstrict-aliasing' '-Wno-error= =3Daddress' '-v' '-o' 'ctld.full' > /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/5.3.0/collect2 -p= lugin /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/5.3.0/liblto_p= lugin.so -plugin-opt=3D/usr/local/libexec/gcc/powerpc64-portbld-freebsd11= =2E0/5.3.0/lto-wrapper -plugin-opt=3D-fresolution=3D/tmp//ccDS76mK.res -p= lugin-opt=3D-pass-through=3D-lgcc -plugin-opt=3D-pass-through=3D-lgcc_s -= plugin-opt=3D-pass-through=3D-lc -plugin-opt=3D-pass-through=3D-lgcc -plu= gin-opt=3D-pass-through=3D-lgcc_s --sysroot=3D/usr/obj/xtoolchain/powerpc= =2Epowerpc64/usr/src/tmp --eh-frame-hdr -V -melf64ppc_fbsd -V -dynamic-li= nker /libexec/ld-elf.so.1 -o ctld.full /usr/obj/xtoolchain/powerpc.powerp= c64/usr/src/tmp/usr/lib/crt1.o /usr/obj/xtoolchain/powerpc.powerpc64/usr/= src/tmp/usr/lib/crti.o /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/= usr/lib/crtbegin.o -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/us= r/lib -L/usr/local/powerpc64-freebsd/bin -L/usr/local/lib/gcc/powerpc64-p= ortbld-freebsd11.0/5.3.0 -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/= tmp/lib -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib chap.= o ctld.o discovery.o isns.o kernel.o keys.o log.o login.o parse.o pdu.o t= oken.o uclparse.o -lbsdxml -ll -lmd -lsbuf -lutil -lprivateucl -lm -lssp_= nonshared -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed = -lgcc_s --no-as-needed /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/= usr/lib/crtend.o /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/li= b/crtn.o > GNU ld (GNU Binutils) 2.25.1 > Supported emulations: > elf64ppc_fbsd > elf64ppc > elf32ppc_fbsd > elf32ppc > GNU ld (GNU Binutils) 2.25.1 > Supported emulations: > elf64ppc_fbsd > elf64ppc > elf32ppc_fbsd > elf32ppcuclparse.o: In function `uclparse_chap': > /usr/src/usr.sbin/ctld/uclparse.c:61: undefined reference to `ucl_objec= t_find_key' > /usr/src/usr.sbin/ctld/uclparse.c:68: undefined reference to `ucl_objec= t_find_key' > uclparse.o: In function `uclparse_chap_mutual': > /usr/src/usr.sbin/ctld/uclparse.c:91: undefined reference to `ucl_objec= t_find_key' > /usr/src/usr.sbin/ctld/uclparse.c:98: undefined reference to `ucl_objec= t_find_key' > /usr/src/usr.sbin/ctld/uclparse.c:105: undefined reference to `ucl_obje= ct_find_key' > uclparse.o:/usr/src/usr.sbin/ctld/uclparse.c:112: more undefined refere= nces to `ucl_object_find_key' follow > uclparse.o: In function `uclparse_toplevel': > /usr/src/usr.sbin/ctld/uclparse.c:235: undefined reference to `ucl_iter= ate_object' > /usr/src/usr.sbin/ctld/uclparse.c:278: undefined reference to `ucl_iter= ate_object' > /usr/src/usr.sbin/ctld/uclparse.c:317: undefined reference to `ucl_iter= ate_object' > uclparse.o: In function `uclparse_auth_group': > /usr/src/usr.sbin/ctld/uclparse.c:396: undefined reference to `ucl_iter= ate_object' > /usr/src/usr.sbin/ctld/uclparse.c:416: undefined reference to `ucl_iter= ate_object' > uclparse.o:/usr/src/usr.sbin/ctld/uclparse.c:431: more undefined refere= nces to `ucl_iterate_object' follow > uclparse.o: In function `uclparse_target_lun': > /usr/src/usr.sbin/ctld/uclparse.c:202: undefined reference to `ucl_obje= ct_find_key' > /usr/src/usr.sbin/ctld/uclparse.c:203: undefined reference to `ucl_obje= ct_find_key' > uclparse.o: In function `uclparse_target': > /usr/src/usr.sbin/ctld/uclparse.c:731: undefined reference to `ucl_iter= ate_object' > collect2: error: ld returned 1 exit status >=20 > *** [ctld.full] Error code 1 >=20 > make[4]: stopped in /usr/src/usr.sbin/ctld > 1 error >=20 > make[4]: stopped in /usr/src/usr.sbin/ctld > *** [all_subdir_usr.sbin/ctld] Error code 2 >=20 >=20 >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 --=20 Regards, Bryan Drewery --lVaeJohqt2ddjA7OEtiafs3N49wEqwKMN-- --7LtOeSibHtIO8t59R5B8g4SBwcj8du689 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 iQEcBAEBAgAGBQJXTFxmAAoJEDXXcbtuRpfPuDEH/3xdXoTGLHD82ImCgBtRXbTA pnEBvllA1+vAVMX1EuqvFiN4kdQqQLM7vX6N5pHihmCFQMnXgTfhdTUBAghlTisT lwmv5doqM0WdBii+LXr6ePVY8cyNF51/grQ81j/oLmiTOMuUKs5QeK4Vg/+oXhjH io57WQ89rZ3Hp6vyW8bXCoeSGS2UkR3mZlwiU7hkGnXv6bFH8HuCwrxcN+wC0/d7 kjk3BRCCE9eftejIapVdoWBHpm1xncL+cLzJi8QarEXaLqO2Kmxh+E1rB2I6PnQ2 ev4LSZQp6Tv4DmvHo+5EabAHvniN+GUyymkHgkk/IGbsp061Bo+wQdcznFr3BWQ= =80kK -----END PGP SIGNATURE----- --7LtOeSibHtIO8t59R5B8g4SBwcj8du689-- From owner-freebsd-current@freebsd.org Mon May 30 15:31:05 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C4750B540BC for ; Mon, 30 May 2016 15:31:05 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id A94921B92 for ; Mon, 30 May 2016 15:31:05 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id A4E30B540B5; Mon, 30 May 2016 15:31:05 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A4861B540B4 for ; Mon, 30 May 2016 15:31:05 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 8EEDE1B91 for ; Mon, 30 May 2016 15:31:05 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 880BD1CA6 for ; Mon, 30 May 2016 15:31:05 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 57EC11D827 for ; Mon, 30 May 2016 15:31:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id StKOpOQMh5al for ; Mon, 30 May 2016 15:31:03 +0000 (UTC) Subject: Re: [CFT] WITH_META_MODE: Working incremental build DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com C18271D821 To: current@FreeBSD.org References: From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <2d25c98b-b166-bd36-f1e9-219744468bc6@FreeBSD.org> Date: Mon, 30 May 2016 08:31:08 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ipn8hceorm2k50sg8845aWDrJRVULuJvd" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 15:31:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ipn8hceorm2k50sg8845aWDrJRVULuJvd Content-Type: multipart/mixed; boundary="HNaOfhUXdfDQEwRKV7Lakd3BhWqeB6TL2" From: Bryan Drewery To: current@FreeBSD.org Message-ID: <2d25c98b-b166-bd36-f1e9-219744468bc6@FreeBSD.org> Subject: Re: [CFT] WITH_META_MODE: Working incremental build References: In-Reply-To: --HNaOfhUXdfDQEwRKV7Lakd3BhWqeB6TL2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 5/27/2016 5:16 PM, Bryan Drewery wrote: > To use this you must either add WITH_META_MODE=3Dyes to your environmen= t > or add it into /etc/src-env.conf (not /etc/src.conf or /etc/make.conf).= > You will also need to load the filemon(4) module with 'kldload filemon'= =2E You also need to 'make cleanworld' once. If objects don't have .meta files then META_MODE won't do the right thing on an incremental build. There is code in bmake to force a rebuild if a .meta file is missing, but it is only partially applied currently. I would like it to be enabled always. --=20 Regards, Bryan Drewery --HNaOfhUXdfDQEwRKV7Lakd3BhWqeB6TL2-- --ipn8hceorm2k50sg8845aWDrJRVULuJvd 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 iQEcBAEBAgAGBQJXTFy8AAoJEDXXcbtuRpfP4/kIAMaQLtbJUnPV+dvCAZBv3qf+ dO4Gzc9GiZQfoyGvTEi34En2dL6sL7vauvyDwsX2on4z8pA4hXpAJUMIvXJLxx5O UpYg8k2aLV7gAdnEg0e4ayEbAlgyktOMyYC7BZHKspiUp4eYDX+9s9hd6D3HYZYN RjGe2UK+GNK2Q2U38ODfM+y1scZ/5XW21ggLVFzL4K5jj2dCh1W9uy6Kx/m2Ourf XUFv4m/fT//dtHFNQ0q9mZU6XE2ds1xdqD1rn+XvEFy5HO8rwzyQf3VVe7cYeug3 wfIhS5Ig4ob1VBmGadNqrC7Pr/PQfLYVbX035S/lpacrHj2njEbmU14LctagTeM= =49kt -----END PGP SIGNATURE----- --ipn8hceorm2k50sg8845aWDrJRVULuJvd-- From owner-freebsd-current@freebsd.org Mon May 30 16:03: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 D3F3AB54800 for ; Mon, 30 May 2016 16:03:56 +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 BE4481D7E for ; Mon, 30 May 2016 16:03:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id BD81EB547FD; Mon, 30 May 2016 16:03: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 BD34BB547FC for ; Mon, 30 May 2016 16:03:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 406E01D7C for ; Mon, 30 May 2016 16:03:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u4UG3hYT030313 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 30 May 2016 19:03:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u4UG3hYT030313 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u4UG3h6i030312; Mon, 30 May 2016 19:03:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 30 May 2016 19:03:42 +0300 From: Konstantin Belousov To: David Wolfskill , current@freebsd.org Subject: Re: Unable to load freshly-built nvidia.ko @r300994. Message-ID: <20160530160342.GW38613@kib.kiev.ua> References: <20160530123654.GW1080@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160530123654.GW1080@albert.catwhisker.org> User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 16:03:56 -0000 On Mon, May 30, 2016 at 05:36:54AM -0700, David Wolfskill wrote: > Today's "daily update" for head was from: > > FreeBSD g1-252.catwhisker.org 11.0-ALPHA1 FreeBSD 11.0-ALPHA1 #432 r300951M/300951:1100114: Sun May 29 04:44:37 PDT 2016 root@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 > > to: > > FreeBSD g1-252.catwhisker.org 11.0-ALPHA1 FreeBSD 11.0-ALPHA1 #433 r300994M/300994:1100115: Mon May 30 04:21:30 PDT 2016 root@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 > > (See > > for the update history for FreeBSD-11 on this laptop.) > > The attempt to load nvidia.ko yielded (from dmesg.boot): > > linker_load_file: Unsupported file type > May 30 11:29:31 g1-252 root: /etc/rc: WARNING: Unable to load kernel module linux64 > May 30 11:29:31 g1-252 kernel: KLD linux64.ko: depends on kernel - not available or version mismatch > May 30 11:29:31 g1-252 kernel: linker_load_file: Unsupported file type Your kernel was built from older sources than you used to build the nvidia module. I mean, the kernel headers used for the module build where updated comparing with binaries that are installed into /boot/kernel. From owner-freebsd-current@freebsd.org Mon May 30 16: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 AAE64B54285 for ; Mon, 30 May 2016 16:31:24 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 9311B1FFB for ; Mon, 30 May 2016 16:31:24 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: by mailman.ysv.freebsd.org (Postfix) id 9260BB54284; Mon, 30 May 2016 16:31:24 +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 8FB8FB54283 for ; Mon, 30 May 2016 16:31:24 +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 4E92A1FFA for ; Mon, 30 May 2016 16:31:24 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1b7Q65-002Ux8-Be>; Mon, 30 May 2016 18:31:21 +0200 Received: from x4e34a275.dyn.telefonica.de ([78.52.162.117] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (envelope-from ) id <1b7Q65-003w9k-1O>; Mon, 30 May 2016 18:31:21 +0200 Date: Mon, 30 May 2016 18:33:57 +0200 From: "O. Hartmann" To: Konstantin Belousov Cc: David Wolfskill , current@freebsd.org Subject: Re: Unable to load freshly-built nvidia.ko @r300994. Message-ID: <20160530183357.2a8344be.ohartman@zedat.fu-berlin.de> In-Reply-To: <20160530160342.GW38613@kib.kiev.ua> References: <20160530123654.GW1080@albert.catwhisker.org> <20160530160342.GW38613@kib.kiev.ua> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/8hGkGGd=2G8U8RiqtKXqeTp"; protocol="application/pgp-signature" X-Originating-IP: 78.52.162.117 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 16:31:24 -0000 --Sig_/8hGkGGd=2G8U8RiqtKXqeTp Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Mon, 30 May 2016 19:03:42 +0300 Konstantin Belousov schrieb: > On Mon, May 30, 2016 at 05:36:54AM -0700, David Wolfskill wrote: > > Today's "daily update" for head was from: > >=20 > > FreeBSD g1-252.catwhisker.org 11.0-ALPHA1 FreeBSD 11.0-ALPHA1 #432 > > r300951M/300951:1100114: Sun May 29 04:44:37 PDT 2016 > > root@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 > >=20 > > to: > >=20 > > FreeBSD g1-252.catwhisker.org 11.0-ALPHA1 FreeBSD 11.0-ALPHA1 #433 > > r300994M/300994:1100115: Mon May 30 04:21:30 PDT 2016 > > root@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 > >=20 > > (See > > > > for the update history for FreeBSD-11 on this laptop.) > >=20 > > The attempt to load nvidia.ko yielded (from dmesg.boot): > >=20 > > linker_load_file: Unsupported file type =20 >=20 > > May 30 11:29:31 g1-252 root: /etc/rc: WARNING: Unable to load kernel mo= dule linux64 > > May 30 11:29:31 g1-252 kernel: KLD linux64.ko: depends on kernel - not = available or > > version mismatch May 30 11:29:31 g1-252 kernel: linker_load_file: Unsup= ported file > > type =20 >=20 > Your kernel was built from older sources than you used to build the nvidia > module. I mean, the kernel headers used for the module build where > updated comparing with binaries that are installed into /boot/kernel. > _______________________________________________ > 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 see another problem: After update from r300830 to r300998, recompiling the nvidia port with ever= y kernel build via /etc/src, my nVidia GPUs start blowing like hell as they were overheate= d. I use module/driver revision 367.18 with appropritae patches proposed here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D201340 Both, r300830 and r300998 use the same nvidia driver. --Sig_/8hGkGGd=2G8U8RiqtKXqeTp Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXTGt2AAoJEOgBcD7A/5N8nHgH/3+RH24qvCxqty4TO8DSULe2 V5skCmFTUhr0yzjzeqIng08AAjpUrR7M5PszmjDc0saF5BWtS4vSEWIo9QxG0jY1 SvSo2IOMLW6/Hg6wAHSZ6d2G25KHhAz4SmrgS7dLKKy0IgIRmTSXZkQtk9+nY9r6 Nv0AwrNzt/EI+yj9HJ2FM+FOSJcQ/weX15Iu1Elxcd8A3AdziI1oq7v8530gcG6E Is4OBvwozbDjT/PcHc853UeqcmRjVnMqGXLiwNQOzWz5rVJk9cB2qsuZX399aPXE xgL0l5eiiJudYBlkcqpD0Cty5KDkgXj8uqhtG3fsJleCvCziJY9lQksJPEXmqHk= =QoIx -----END PGP SIGNATURE----- --Sig_/8hGkGGd=2G8U8RiqtKXqeTp-- From owner-freebsd-current@freebsd.org Mon May 30 17:09: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 933AFB54D67 for ; Mon, 30 May 2016 17:09:38 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5241B1842 for ; Mon, 30 May 2016 17:09:37 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [88.217.104.190] (helo=[192.168.2.103]) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1b7Qh4-0002qN-OA for freebsd-current@freebsd.org; Mon, 30 May 2016 19:09:34 +0200 From: Matthias Apitz To: Subject: Re: r300951 make buildworld duration 18h Date: Mon, 30 May 2016 19:09:33 +0200 User-Agent: Dekko/0.6.20; Qt/5.4.1; ubuntumirclient; Linux; MIME-Version: 1.0 Message-ID: In-Reply-To: References: <20160530143726.GA2418@c720-r292778-amd64.oa.oclc.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 88.217.104.190 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 17:09:38 -0000 El lunes, 30 de mayo de 2016 17:11:15 (CEST), Bob Bishop =20 escribi=C3=B3: > HI, > >> On 30 May 2016, at 15:37, Matthias Apitz wrote: >>=20 >>=20 >> Hello, >>=20 >> Yesterday I pulled via svn co ... a fresh r300951 and started=20 >> the buildworld as >>=20 >> # make -j2 buildworld >>=20 >> it ended today at lunchtime after 18 hours. The laptop has 2x=20 >> Intel Atom 1.6GHz >> and 1 GByte RAM and was otherwise unused. Is this the normal=20 >> buildworld time of >> today? I think it spent most of the time in building the llvm=E2=80=A6 > > With 1GB it probably spent a lot of its time swapping. > the 'make -j2 buildkernel KERNCONF=3DGENERIC' lasted only 2:40h matthias --=20 Sent from my Ubuntu tablet http://www.unixarea.de/ From owner-freebsd-current@freebsd.org Mon May 30 18:01: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 4F44FB556BA for ; Mon, 30 May 2016 18:01:17 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-178.reflexion.net [208.70.211.178]) (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 14BC211C5 for ; Mon, 30 May 2016 18:01:16 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 8069 invoked from network); 30 May 2016 18:01:42 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 30 May 2016 18:01:42 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Mon, 30 May 2016 14:01:07 -0400 (EDT) Received: (qmail 1943 invoked from network); 30 May 2016 18:01:07 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 30 May 2016 18:01:07 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 342A21C439B; Mon, 30 May 2016 11:01:06 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: 11.0 -r300944 build attempted WITH_META_MODE failed [amd64 targeting powerpc64 via devel/powerpc64-gcc use] From: Mark Millard In-Reply-To: Date: Mon, 30 May 2016 11:01:08 -0700 Cc: FreeBSD Current , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <8A197698-51C7-43F9-9927-465602E19AAE@dsl-only.net> To: Bryan Drewery X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 18:01:17 -0000 On 2016-May-30, at 8:29 AM, Bryan Drewery = wrote: > This failure is not likely related to META_MODE. >=20 > I should have mentioned that to enable META_MODE after not having it = on > you should do a 'make cleanworld' first. >=20 > On 5/29/2016 9:19 PM, Mark Millard wrote: >> This was my first-time-ever WITH_META_MODE attempt. I show a chunk of = the log later below. >>=20 >> Retrying without WITH_META_MODE=3Dyes resulted in no problems, unlike = below. >>=20 >> A self-hosted powerpc64 11.0 -r300944 build using devel/powerpc64-gcc = as the so-called "cross compiler" also did not have this problem =E2=80=94= -but powerpc64 does not have WITH_META_MODE (no filemon.ko to load). >>=20 >> [The 2 "no problem" examples suggest that -r300944 has gotten to the = point that xtoolchain like contexts work again [non-META], even self = hosted ones.] >>=20 >> Here is the part of the script log around the WITH_META_MODE failure. = The compiles had -v . . . >>=20 >> --- ctld.full --- >> Using built-in specs. >> COLLECT_GCC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc >> = COLLECT_LTO_WRAPPER=3D/usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0= /5.3.0/lto-wrapper >> Target: powerpc64-portbld-freebsd11.0 >> Configured with: ./../gcc-5.3.0/configure = --target=3Dpowerpc64-portbld-freebsd11.0 --disable-nls = --enable-languages=3Dc,c++ --without-headers --with-gmp=3D/usr/local = --with-pkgversion=3D'FreeBSD Ports Collection for powerpc64' = --with-system-zlib --with-as=3D/usr/local/bin/powerpc64-freebsd-as = --with-ld=3D/usr/local/bin/powerpc64-freebsd-ld --prefix=3D/usr/local = --localstatedir=3D/var --mandir=3D/usr/local/man = --infodir=3D/usr/local/info/ --build=3Dx86_64-portbld-freebsd11.0 >> Thread model: posix >> gcc version 5.3.0 (FreeBSD Ports Collection for powerpc64)=20 >> = COMPILER_PATH=3D/usr/local/powerpc64-freebsd/bin/:/usr/local/libexec/gcc/p= owerpc64-portbld-freebsd11.0/5.3.0/:/usr/local/libexec/gcc/powerpc64-portb= ld-freebsd11.0/5.3.0/:/usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0= /:/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/:/usr/local/lib/g= cc/powerpc64-portbld-freebsd11.0/ >> = LIBRARY_PATH=3D/usr/local/powerpc64-freebsd/bin/:/usr/local/lib/gcc/powerp= c64-portbld-freebsd11.0/5.3.0/:/usr/obj/xtoolchain/powerpc.powerpc64/usr/s= rc/tmp/lib/:/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib/ >> COLLECT_GCC_OPTIONS=3D'-isystem' = '/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include' = '-L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib' '-B' = '/usr/local/powerpc64-freebsd/bin/' '-O2' '-pipe' '-I' = '/usr/src/usr.sbin/ctld/../../contrib/libucl/include' '-I' = '/usr/src/usr.sbin/ctld' '-I' '/usr/src/usr.sbin/ctld/../../sys' '-I' = '/usr/src/usr.sbin/ctld/../../sys/cam/ctl' '-I' = '/usr/src/usr.sbin/ctld/../../sys/dev/iscsi' '-g' '-std=3Dgnu99' = '-fstack-protector-strong' '-Wsystem-headers' '-Wall' '-Wno-format-y2k' = '-Wextra' '-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' '-Wno-error=3Dunused-function' = '-Wno-error=3Denum-compare' '-Wno-error=3Dlogical-not-parentheses' = '-Wno-error=3Dbool-compare' '-Wno-error=3Duninitialized' = '-Wno-error=3Darray-bounds' '-Wno-error=3Dclobbered' = '-Wno-error=3Dcast-align' '-Wno-error=3Dextra' '-Wno-error=3Dattributes' = '-Wno-error=3Dinline' '-Wno-error=3Dunused-but-set-variable' = '-Wno-error=3Dunused-value' '-Wno-error=3Dstrict-aliasing' = '-Wno-error=3Daddress' '-v' '-o' 'ctld.full' >> /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/5.3.0/collect2 = -plugin = /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/5.3.0/liblto_plugin.s= o = -plugin-opt=3D/usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/5.3.0/l= to-wrapper -plugin-opt=3D-fresolution=3D/tmp//ccDS76mK.res = -plugin-opt=3D-pass-through=3D-lgcc -plugin-opt=3D-pass-through=3D-lgcc_s = -plugin-opt=3D-pass-through=3D-lc -plugin-opt=3D-pass-through=3D-lgcc = -plugin-opt=3D-pass-through=3D-lgcc_s = --sysroot=3D/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp = --eh-frame-hdr -V -melf64ppc_fbsd -V -dynamic-linker = /libexec/ld-elf.so.1 -o ctld.full = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib/crt1.o = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib/crti.o = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib/crtbegin.o = -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib = -L/usr/local/powerpc64-freebsd/bin = -L/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0 = -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/lib = -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib chap.o = ctld.o discovery.o isns.o kernel.o keys.o log.o login.o parse.o pdu.o = token.o uclparse.o -lbsdxml -ll -lmd -lsbuf -lutil -lprivateucl -lm = -lssp_nonshared -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc = --as-needed -lgcc_s --no-as-needed = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib/crtend.o = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib/crtn.o >> GNU ld (GNU Binutils) 2.25.1 >> Supported emulations: >> elf64ppc_fbsd >> elf64ppc >> elf32ppc_fbsd >> elf32ppc >> GNU ld (GNU Binutils) 2.25.1 >> Supported emulations: >> elf64ppc_fbsd >> elf64ppc >> elf32ppc_fbsd >> elf32ppcuclparse.o: In function `uclparse_chap': >> /usr/src/usr.sbin/ctld/uclparse.c:61: undefined reference to = `ucl_object_find_key' >> /usr/src/usr.sbin/ctld/uclparse.c:68: undefined reference to = `ucl_object_find_key' >> uclparse.o: In function `uclparse_chap_mutual': >> /usr/src/usr.sbin/ctld/uclparse.c:91: undefined reference to = `ucl_object_find_key' >> /usr/src/usr.sbin/ctld/uclparse.c:98: undefined reference to = `ucl_object_find_key' >> /usr/src/usr.sbin/ctld/uclparse.c:105: undefined reference to = `ucl_object_find_key' >> uclparse.o:/usr/src/usr.sbin/ctld/uclparse.c:112: more undefined = references to `ucl_object_find_key' follow >> uclparse.o: In function `uclparse_toplevel': >> /usr/src/usr.sbin/ctld/uclparse.c:235: undefined reference to = `ucl_iterate_object' >> /usr/src/usr.sbin/ctld/uclparse.c:278: undefined reference to = `ucl_iterate_object' >> /usr/src/usr.sbin/ctld/uclparse.c:317: undefined reference to = `ucl_iterate_object' >> uclparse.o: In function `uclparse_auth_group': >> /usr/src/usr.sbin/ctld/uclparse.c:396: undefined reference to = `ucl_iterate_object' >> /usr/src/usr.sbin/ctld/uclparse.c:416: undefined reference to = `ucl_iterate_object' >> uclparse.o:/usr/src/usr.sbin/ctld/uclparse.c:431: more undefined = references to `ucl_iterate_object' follow >> uclparse.o: In function `uclparse_target_lun': >> /usr/src/usr.sbin/ctld/uclparse.c:202: undefined reference to = `ucl_object_find_key' >> /usr/src/usr.sbin/ctld/uclparse.c:203: undefined reference to = `ucl_object_find_key' >> uclparse.o: In function `uclparse_target': >> /usr/src/usr.sbin/ctld/uclparse.c:731: undefined reference to = `ucl_iterate_object' >> collect2: error: ld returned 1 exit status >>=20 >> *** [ctld.full] Error code 1 >>=20 >> make[4]: stopped in /usr/src/usr.sbin/ctld >> 1 error >>=20 >> make[4]: stopped in /usr/src/usr.sbin/ctld >> *** [all_subdir_usr.sbin/ctld] Error code 2 >>=20 >>=20 >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >=20 >=20 > --=20 > Regards, > Bryan Drewery Confirmed: after a cleanworld without WITH_META_MODE=3Dyes a (re-)build = with WITH_META_MODE=3Dyes based buidlworld buildkernel sequence = completed just fine. (I did not try a cleanworld with = WITH_META_MODE=3Dyes.) [My other note about "/usr/bin/ld: unrecognised emulation mode: = elf32ppc_fbsd" for an amd64 host to powerpc cross build via clang still = applies as it was without WITH_META_MODE=3Dyes in the first place.] Side note: devel/powerpc64-gcc has differing /usr/local/include related search path = behavior for: A) amd64 host -> powerpc64 cross builds: no /usr/local/include in the = search path. (No devel/powerpc64-gcc Makefile with-local-prefix addition = involved.) B) powerpc64 host -> powerpc64 "self hosted cross builds": has = /usr/local/include in the search path. (With or without = with-local-prefix in the Makefile.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Mon May 30 18:26:49 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 57854B55F52 for ; Mon, 30 May 2016 18:26:49 +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 1A2A517C5 for ; Mon, 30 May 2016 18:26:48 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1b7Rtm-0031mZ-53>; Mon, 30 May 2016 20:26:46 +0200 Received: from x5ce10b40.dyn.telefonica.de ([92.225.11.64] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (envelope-from ) id <1b7Rtl-0045jj-Qc>; Mon, 30 May 2016 20:26:46 +0200 Date: Mon, 30 May 2016 20:29:24 +0200 From: "O. Hartmann" To: "Ngie Cooper (yaneurabeya)" Cc: FreeBSD CURRENT Subject: Re: r 300949: rpcbind rejects to start: couldn't create ip6 socket Message-ID: <20160530202924.63629a4b.ohartman@zedat.fu-berlin.de> In-Reply-To: References: <20160529093230.68a5da55.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/WWXweY9JBCJK_uzFEr2Koh="; protocol="application/pgp-signature" X-Originating-IP: 92.225.11.64 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 18:26:49 -0000 --Sig_/WWXweY9JBCJK_uzFEr2Koh= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Am Sun, 29 May 2016 03:00:56 -0700 "Ngie Cooper (yaneurabeya)" schrieb: > > On May 29, 2016, at 00:32, O. Hartmann wr= ote: > >=20 > > After updating sources and build- and installworld, I realize that all = rpcbind related > > services, so far NFS, are not working. On a client I check the start of= rpcbind by > > setting option -d and receive the output shown below. > >=20 > > Well, prior to r300949 rpcbind started without complains - as it did wi= th r300901. > >=20 > > [...] > > rpcbind not running? > > Starting rpcbind. > > rpcbind debugging enabled. > > can't get local ip6 address: hostname nor servname provided, or not kno= wn > > couldn't create ip6 socket/etc/rc.d/rpcbind: WARNING: failed to start r= pcbind =20 >=20 > Hi, > Could you please try this patch with -d (it=E2=80=99ll continue on inste= ad of exiting=E2=80=A6 > I=E2=80=99m curious as to why it was failing before). Does IPv6 work in y= our environment? > Thanks! > -Ngie Well, funny is: staring rpcbind with options "-h 192.168.xxx.xxx -l -s -W" = does not make the rpcbind trying to create an IPv6 socket - which it fails due to absence= of IPv6 in kernel, but only "-h 192.168.xxx.xxx" does! I can reproduce this weird behaviour on several CURRENT systems on which IP= v6 is disabled by default. --Sig_/WWXweY9JBCJK_uzFEr2Koh= Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXTIaEAAoJEOgBcD7A/5N8HiwH/iZ6Que/lrs7eSgY/wfvR/4T +yXbts402qB1i0sE7HaMf/wBKM+KDPjC1MzsxDas+ZBnYQKZOnr300ZBFI7H8W77 BdIDt+wow+sCtboFG6Sp9FR6vjFwfTJN0cJ6P4wlYamyDMoWvt7TuQAHS8jG85V9 N9zSEb5Bj7BCwnFA/pt2NaO2Lo+F19cv1wHbsQzTFM+xVF/+xS1jMhZx8nrg1yBj hK0IiBQPwxvpbOD7i9dl0Cvtbbcqmq3gWlSjtIylW0JItBuijb5GVU+jD5j4U615 xh0GjeqYsWOZbo9pnzQqV7pvVzCIUOH5sHR0z0BQpB+9s86z3yKDX0GO136ZFts= =usF7 -----END PGP SIGNATURE----- --Sig_/WWXweY9JBCJK_uzFEr2Koh=-- From owner-freebsd-current@freebsd.org Mon May 30 18:52: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 C7841B546CC for ; Mon, 30 May 2016 18:52:30 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id B29CE1716 for ; Mon, 30 May 2016 18:52:30 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id B1B51B546CB; Mon, 30 May 2016 18:52:30 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B154BB546CA for ; Mon, 30 May 2016 18:52:30 +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 86AB61714 for ; Mon, 30 May 2016 18:52:29 +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 u4UIqRf9016380; Mon, 30 May 2016 18:52:27 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id u4UIqRlD016379; Mon, 30 May 2016 11:52:27 -0700 (PDT) (envelope-from david) Date: Mon, 30 May 2016 11:52:27 -0700 From: David Wolfskill To: Konstantin Belousov Cc: current@freebsd.org Subject: Re: Unable to load freshly-built nvidia.ko @r300994. Message-ID: <20160530185227.GZ1080@albert.catwhisker.org> Reply-To: current@freebsd.org Mail-Followup-To: current@freebsd.org, Konstantin Belousov References: <20160530123654.GW1080@albert.catwhisker.org> <20160530160342.GW38613@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rPF8rPXpDlNr1aSW" Content-Disposition: inline In-Reply-To: <20160530160342.GW38613@kib.kiev.ua> User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 18:52:30 -0000 --rPF8rPXpDlNr1aSW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 30, 2016 at 07:03:42PM +0300, Konstantin Belousov wrote: > ... > > May 30 11:29:31 g1-252 root: /etc/rc: WARNING: Unable to load kernel mo= dule linux64 > > May 30 11:29:31 g1-252 kernel: KLD linux64.ko: depends on kernel - not = available or version mismatch > > May 30 11:29:31 g1-252 kernel: linker_load_file: Unsupported file type >=20 > Your kernel was built from older sources than you used to build the nvidia > module. I mean, the kernel headers used for the module build where > updated comparing with binaries that are installed into /boot/kernel. Hmmm... I'm ... unlcear ... on how that could have happened. I've copied the typescript (from the build) to http://www.catwhisker.org/~david/FreeBSD/head/typescript_r300994; the "_bw" alias (ultimately) expands to: setenv TMPDIR /tmp && \ id && \ mount && \ cd /usr/src && \ uname -a && \ date && \ make -j16 buildworld && \ date && \ make -j16 buildkernel && \ date && \ rm -fr /boot/modules.old && \ cp -pr /boot/modules{,.old} && \ make installkernel && \ date && \ pushd /usr/ports && \ pushd x11/nvidia-driver && \ make clean ; popd ; popd && \ date && \ mergemaster -U -u 0022 -p && \ date && \ rm -fr /usr/include.old && \ date && \ mv /usr/include{,.old} && \ date && \ rm -fr /usr/share/man && \ date && \ make installworld && \ date && \ mergemaster -F -U -u 0022 -i && \ date && \ make delete-old && \ date && \ df -k I have some errands/chores to deal with so I won't be able to respond right away, but I would like to resolve the issue. I received one suggestion to try reverting r300990;, which I did (without a change in the symptoms). I then reverted the sources back to r300951 and performed exactly thhe same type of build (that is, with 'WITH_META_MODE=3Dyes' in /etc/src-env.conf; no attempt to use -DNO_CLEAN; build world; build kernel; install kernel; install world; mergemaster...). That's working Just fine; kldstat shows: g1-252(11.0)[6] kldstat=20 Id Refs Address Size Name 1 37 0xffffffff80200000 1e0a3a8 kernel 2 1 0xffffffff8200c000 232f8 geom_eli.ko 3 2 0xffffffff82030000 9d6d8 linux.ko 4 4 0xffffffff820ce000 d1f0 linux_common.ko 5 1 0xffffffff820dc000 4c58 coretemp.ko 6 1 0xffffffff820e1000 546b0 iwn5000fw.ko 7 1 0xffffffff82136000 b67b50 nvidia.ko 8 1 0xffffffff82c9e000 b838 filemon.ko 9 1 0xffffffff82e21000 f01c tmpfs.ko 10 1 0xffffffff82e31000 5959 fdescfs.ko 11 1 0xffffffff82e37000 a9e8 linprocfs.ko 12 1 0xffffffff82e42000 39671 linux64.ko g1-252(11.0)[7]=20 Note thaht linux64.ko shows up here, while in the r300994 case, linux64.ko would not load (which, I believe, is why nvidia.ko wouldn't load). 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. --rPF8rPXpDlNr1aSW Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJXTIvrXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XwgEH/0+VctBXjwLBMTvOSVvu8qt1 NwRFrsx8fCCHtFBhMiCsKMNRsHTbfTetvw3vEBpdUlNHPd/vs0XSSf61NlY1U/Ny WwigFZCLixlGwfA+CNbsmlO6uMCEPxCPTINCvMJP/oL+Pt6ImDOY/5ksvwpHTLBe +zZWp5Bs5jwgNlQ7fPDyXIJSAth9mXQQRXmqT8he8njIJ4gHc+gc84HcxorbljeT 4LkGOimifNSJXsqZnGnFBuF1varaJf/r15OtmZo7BY5ujQoayzuWfcE8YbhX7HTB V5cz0RaAXbNbwFFRxUE1fVVJm0dFZu3KJ/TFzQvzA3n9aJxeBgouUgElGoNbrBI= =tdJH -----END PGP SIGNATURE----- --rPF8rPXpDlNr1aSW-- From owner-freebsd-current@freebsd.org Mon May 30 19:29:58 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 00593B550AB for ; Mon, 30 May 2016 19:29:58 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (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 B92251B22 for ; Mon, 30 May 2016 19:29:57 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::80e4:dfeb:48d:c34] (unknown [IPv6:2001:7b8:3a7:0:80e4:dfeb:48d:c34]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 35D0B398D4; Mon, 30 May 2016 21:29:49 +0200 (CEST) Subject: Re: Recent seems to have broken toolchain Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_51DFDA6E-D0F0-44D4-9795-BA79C109B931"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 (ebbf3ef) From: Dimitry Andric In-Reply-To: <20160529022702.GA57282@troutmask.apl.washington.edu> Date: Mon, 30 May 2016 21:29:40 +0200 Cc: freebsd-current@freebsd.org Message-Id: <1EF864CF-12E8-4A48-B6E9-317D438B7B7C@FreeBSD.org> References: <20160529022702.GA57282@troutmask.apl.washington.edu> To: Steve Kargl X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 19:29:58 -0000 --Apple-Mail=_51DFDA6E-D0F0-44D4-9795-BA79C109B931 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 29 May 2016, at 04:27, Steve Kargl = wrote: >=20 > I have a Fortran application that has built forever on = FreeBSD-current; > that is, until recently. It now dies with the following error: >=20 > gfortran48 -O2 -pipe -march=3Dnative -mtune=3Dnative -static = -funroll-loops \ > --param max-unroll-times=3D4 -ftree-vectorize -Wall\ > -rpath /usr/local/lib/gcc48 -I/home/kargl/modules -o acolor = acolor.f90 \ > globalm.o saxm.o -L/home/kargl/lib -L. -L/usr/local/lib -L. -ltgt = -loa \ > -L/home/kargl/lib -L. -L/usr/local/lib -lm90 -llapack -lblas > ./liboa.a(pointm.o): In function `__pointm_MOD_l2norm2': > pointm.f90:(.text+0x490): multiple definition of = `__pointm_MOD_l2norm2' > /home/kargl/lib/libtgt.a(pointm.o):pointm.f90:(.text+0x0): first = defined here >=20 > Yes, pointm.o is in both libtgt.a and liboa.a. In the past, during > linking, the symbols are resolved from the first of -ltgt or -loa > depending on the order on the command line. If you run the above command line with -v, what linker does it use? I suspect this may be something caused by a newer binutils port, or even by a newer gfortran. If this is using /usr/local/bin/ld, you might want to try downgrading your binutils. -Dimitry --Apple-Mail=_51DFDA6E-D0F0-44D4-9795-BA79C109B931 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAldMlKwACgkQsF6jCi4glqM1cgCgkahSMxz4HINQWbM5EBVd1cPy RKoAn0zE7cQvCLL1m4+trlA7Dugbu+Iu =5QU7 -----END PGP SIGNATURE----- --Apple-Mail=_51DFDA6E-D0F0-44D4-9795-BA79C109B931-- From owner-freebsd-current@freebsd.org Mon May 30 21:40: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 78AB9B4F1C9 for ; Mon, 30 May 2016 21:40:27 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 23A721065 for ; Mon, 30 May 2016 21:40:26 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1b7Uv1-0007Lu-LF; Mon, 30 May 2016 23:40:17 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Adrian Chadd" Cc: freebsd-current Subject: Re: if_iwn dhcp troubles References: Date: Mon, 30 May 2016 23:15:55 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.4.0 X-Scan-Signature: 2aaff93d9ee6aa46ec6f80bef87cb890 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 21:40:27 -0000 On Mon, 30 May 2016 03:01:10 +0200, Adrian Chadd wrote: > ok, so there seem to be more lingering 802.11n issues. can you tell me > mrore about the environment there, so I can try to duplicate it? > > I'd like to fix whatever 11n issues there are in iwn! > > Thanks! > > > -a Hi Adrian, I don't know what you want to know, but it is just my laptop at home. I installed an Intel WiFi card, because the Broadcom it had didn't have support in FreeBSD. I normally have if_lagg configured, but disabled it to debug this. I connect with WiFi to a Ubiquiti Unifi AP AC Lite (https://www.ubnt.com/unifi/unifi-ap-ac-lite/). Other (non-freebsd) devices, like a phone, connect happily with the WiFi. pciconf -vl: ... iwn0@pci0:4:0:0: class=0x028000 card=0x40608086 chip=0x088e8086 rev=0x24 hdr=0x00 vendor = 'Intel Corporation' device = 'Centrino Advanced-N 6235' class = network ... ================= cat /etc/wpa_supplicant.conf (really plain) network={ ssid="xxxxxxxxx" psk="yyyyyyyy" } ================= cat /etc/rc.conf: # Kernel zfs_enable="YES" saver="green" accounting_enable="YES" powerd_enable="YES" devfs_system_ruleset="system" background_fsck="NO" dumpdev="AUTO" kld_list="coretemp ichsmb radeonkms fuse if_lagg vboxdrv cuse" keymap="/etc/keymap.test" # if_bwn bwn_v4_lp_ucode" # Networking hostname="sjakie.klop.ws" #wpa_supplicant_flags="$wpa_supplicant_flags -d" wlans_iwn0="wlan0" create_args_wlan0="wlanaddr 00:26:b9:12:40:a4 country NL" ifconfig_wlan0="-ht WPA" #ifconfig_bge0="up" #cloned_interfaces="lagg0" #ifconfig_lagg0="laggproto failover laggport bge0 laggport wlan0 SYNCDHCP" ifconfig_wlan0="$ifconfig_wlan0 DHCP" #ifconfig_DEFAULT="SYNCDHCP" #ifconfig_em0_alias0="inet 192.168.1.36 netmask 0xffffffff" firewall_enable="YES" firewall_type="/etc/ipfw.sjakie" #local_unbound_enable="YES" # Daemons ntpdate_enable="YES" ntpd_enable="YES" sshd_enable="YES" inetd_enable="YES" syslogd_flags="" sendmail_enable="NO" sendmail_submit_enable="NO" sendmail_outbound_enable="NO" sendmail_msp_queue_enable="NO" # Bluetooth #hcsecd_enable="YES" #sdpd_enable="YES" #bthidd_enable="YES" # Ports bsdstats_enable="YES" #postfix_enable="YES" #smtpd_enable="YES" #smtpd_flags="-v" cupsd_enable="YES" dbus_enable="YES" polkitd_enable="YES" #hald_enable="YES" smartd_enable="YES" #mdnsd_enable="YES" avahi_daemon_enable="YES" bruteblockd_enable="YES" bruteblockd_table="1" bruteblockd_flags="-s 5" #collectd_enable="YES" rpcbind_enable="YES" #nfs_client_enable="YES" mountd_enable="YES" nfs_server_enable="YES" panicmail_enable="YES" slim_enable="YES" webcamd_enable="YES" webcamd_flags="-m v4l2-dev.v4l_hflip=1" ============= dmesg: Copyright (c) 1992-2016 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-ALPHA1 #7 r300901M: Sat May 28 16:54:00 CEST 2016 root@sjakie.klop.ws:/usr/obj/usr/src/sys/GENERIC-NODEBUG amd64 FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0) can't re-use a leaf (ixl_rx_miss_bufs)! VT(vga): resolution 640x480 CPU: Pentium(R) Dual-Core CPU T4300 @ 2.10GHz (2094.80-MHz K8-class CPU) Origin="GenuineIntel" Id=0x1067a Family=0x6 Model=0x17 Stepping=10 Features=0xbfebfbff Features2=0xc00e39d AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 4047171584 (3859 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) random: unblocking device. ioapic0 irqs 0-23 on motherboard random: entropy device external interface kbd1 at kbdmux0 netmap: loaded module module_register_init: MOD_LOAD (vesa, 0xffffffff80fe16e0, 0) error 19 vtvga0: on motherboard cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 cpu0: on acpi0 cpu1: on acpi0 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pcib1: [GIANT-LOCKED] pci1: on pcib1 vgapci0: port 0x2000-0x20ff mem 0xd0000000-0xdfffffff,0xfc000000-0xfc00ffff irq 16 at device 0.0 on pci1 vgapci0: Boot video device hdac0: mem 0xfc010000-0xfc013fff irq 17 at device 0.1 on pci1 uhci0: port 0x1800-0x181f irq 16 at device 26.0 on pci0 usbus0 on uhci0 uhci1: port 0x1820-0x183f irq 21 at device 26.1 on pci0 usbus1 on uhci1 uhci2: port 0x1840-0x185f irq 19 at device 26.2 on pci0 usbus2 on uhci2 ehci0: mem 0xfc504800-0xfc504bff irq 19 at device 26.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 hdac1: mem 0xfc500000-0xfc503fff irq 22 at device 27.0 on pci0 pcib2: irq 17 at device 28.0 on pci0 pcib2: [GIANT-LOCKED] pcib3: irq 16 at device 28.1 on pci0 pcib3: [GIANT-LOCKED] pci2: on pcib3 iwn0: mem 0xf8000000-0xf8001fff irq 17 at device 0.0 on pci2 pcib4: irq 19 at device 28.3 on pci0 pcib4: [GIANT-LOCKED] pcib5: irq 16 at device 28.5 on pci0 pcib5: [GIANT-LOCKED] pci3: on pcib5 bge0: mem 0xfc100000-0xfc10ffff irq 17 at device 0.0 on pci3 bge0: CHIP ID 0x05784100; ASIC REV 0x5784; CHIP REV 0x57841; PCI-E miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: Using defaults for TSO: 65518/35/2048 bge0: Ethernet address: 00:26:b9:12:40:a4 uhci3: port 0x1860-0x187f irq 23 at device 29.0 on pci0 usbus4 on uhci3 uhci4: port 0x1880-0x189f irq 19 at device 29.1 on pci0 usbus5 on uhci4 uhci5: port 0x18a0-0x18bf irq 18 at device 29.2 on pci0 usbus6 on uhci5 ehci1: mem 0xfc504c00-0xfc504fff irq 23 at device 29.7 on pci0 usbus7: EHCI version 1.0 usbus7 on ehci1 pcib6: at device 30.0 on pci0 pci4: on pcib6 pci4: at device 1.0 (no driver attached) sdhci_pci0: mem 0xfc200800-0xfc2008ff irq 18 at device 1.1 on pci4 sdhci_pci0: 1 slot(s) allocated isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0x18f0-0x18f7,0x18e4-0x18e7,0x18e8-0x18ef,0x18e0-0x18e3,0x18c0-0x18df mem 0xfc504000-0xfc5047ff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.20 with 4 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich5: at channel 5 on ahci0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_lid0: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 acpi_tz0: on acpi0 acpi_tz1: on acpi0 acpi_tz2: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 ppc0: cannot reserve I/O port range est0: on cpu0 est1: on cpu1 ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 3 on hdaa0 hdacc1: at cad 0 on hdac1 hdaa1: at nid 1 on hdacc1 pcm1: at nid 13,10 and 14 on hdaa1 pcm2: at nid 15 and 19 on hdaa1 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ACS-2 ATA SATA 3.x device ada0: Serial Number S1DHNSAD914271K ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors) ada0: quirks=0x3<4K,NCQ_TRIM_BROKEN> cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI device cd0: Serial Number KZZ9B7E2004 cd0: 150.000MB/s transfers (SATA 1.x, UDMA6, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray open SMP: AP CPU #1 Launched! Timecounter "TSC" frequency 2094797271 Hz quality 1000 Trying to mount root from zfs:zroot/root []... Root mount waiting for: usbus7 usbus6 usbus5 usbus4 usbus3 usbus2 usbus1 usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered Root mount waiting for: usbus7 usbus3 Root mount waiting for: usbus7 usbus3 uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered Root mount waiting for: usbus3 ugen6.2: at usbus6 ugen0.2: at usbus0 uhub8: on usbus0 Root mount waiting for: usbus3 uhub8: 3 ports with 0 removable, self powered ugen3.2: at usbus3 ugen0.3: at usbus0 ukbd0: on usbus0 kbd2 at ukbd0 GEOM_ELI: Device gpt/swap0.eli created. GEOM_ELI: Encryption: AES-XTS 128 GEOM_ELI: Crypto: software ugen0.4: at usbus0 coretemp0: on cpu0 coretemp1: on cpu1 ichsmb0: port 0x1c00-0x1c1f irq 19 at device 31.3 on pci0 smbus0: on ichsmb0 info: [drm] Initialized drm 1.1.0 20060810 drmn0: on vgapci0 info: [drm] RADEON_IS_PCIE info: [drm] initializing kernel modesetting (RV710 0x1002:0x9553 0x1028:0x02BE). info: [drm] register mmio base: 0xFC000000 info: [drm] register mmio size: 65536 info: [drm] radeon_atrm_get_bios: ===> Try ATRM... info: [drm] radeon_atrm_get_bios: pci_find_class() found: 0:1:0:0, vendor=1002, device=9553 info: [drm] radeon_atrm_get_bios: Get ACPI device handle info: [drm] radeon_atrm_get_bios: Get ACPI handle for "ATRM" info: [drm] radeon_atrm_get_bios: Failed to get "ATRM" handle: AE_NOT_FOUND info: [drm] radeon_acpi_vfct_bios: ===> Try VFCT... info: [drm] radeon_acpi_vfct_bios: Get "VFCT" ACPI table info: [drm] radeon_acpi_vfct_bios: Failed to get "VFCT" table: AE_NOT_FOUND info: [drm] igp_read_bios_from_vram: ===> Try IGP's VRAM... info: [drm] igp_read_bios_from_vram: VRAM base address: 0xd0000000 info: [drm] igp_read_bios_from_vram: Map address: 0xfffff800d0000000 (262144 bytes) info: [drm] igp_read_bios_from_vram: Incorrect BIOS signature: 0x0000 info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM... info: [drm] radeon_read_bios: Map address: 0xfffff800000c0000 (131072 bytes) info: [drm] ATOM BIOS: BR32787 drmn0: info: VRAM: 512M 0x0000000000000000 - 0x000000001FFFFFFF (512M used) drmn0: info: GTT: 512M 0x0000000020000000 - 0x000000003FFFFFFF info: [drm] Detected VRAM RAM=512M, BAR=256M info: [drm] RAM width 64bits DDR [TTM] Zone kernel: Available graphics memory: 2059256 kiB [TTM] Initializing pool allocator info: [drm] radeon: 512M of VRAM memory ready info: [drm] radeon: 512M of GTT memory ready. info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. info: [drm] MSI enabled 1 message(s) drmn0: info: radeon: using MSI. info: [drm] radeon: irq initialized. info: [drm] GART: num cpu pages 131072, num gpu pages 131072 info: [drm] probing gen 2 caps for device 8086:2a41 = 1/0 info: [drm] Loading RV710 Microcode info: [drm] PCIE GART of 512M enabled (table at 0x0000000000040000). drmn0: info: WB enabled drmn0: info: fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu addr 0x0xfffff80014286c00 drmn0: info: fence driver on ring 3 use gpu addr 0x0000000020000c0c and cpu addr 0x0xfffff80014286c0c info: [drm] ring test on 0 succeeded in 1 usecs info: [drm] ring test on 3 succeeded in 1 usecs info: [drm] ib test on ring 0 succeeded in 0 usecs info: [drm] ib test on ring 3 succeeded in 0 usecs info: [drm] radeon_device_init: Taking over the fictitious range 0xd0000000-0xe0000000 iicbus0: on iicbb0 addr 0xff iic0: on iicbus0 iicbus1: on iicbb1 addr 0x0 iic1: on iicbus1 iicbus2: on iicbb2 addr 0x0 iic2: on iicbus2 iicbus3: on iicbb3 addr 0x0 iic3: on iicbus3 iicbus4: on iicbb4 addr 0x0 iic4: on iicbus4 iicbus5: on iicbb5 addr 0x0 iic5: on iicbus5 iicbus6: on iicbb6 addr 0x0 iic6: on iicbus6 info: [drm] Radeon Display Connectors info: [drm] Connector 0: info: [drm] VGA-1 info: [drm] DDC: 0x7fa0 0x7fa0 0x7fa4 0x7fa4 0x7fa8 0x7fa8 0x7fac 0x7fac info: [drm] Encoders: info: [drm] CRT1: INTERNAL_KLDSCP_DAC1 info: [drm] Connector 1: info: [drm] HDMI-A-1 info: [drm] HPD1 info: [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c info: [drm] Encoders: info: [drm] DFP1: INTERNAL_UNIPHY info: [drm] Connector 2: info: [drm] LVDS-1 info: [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c info: [drm] Encoders: info: [drm] LCD1: INTERNAL_UNIPHY2 info: [drm] Internal thermal controller with fan control info: [drm] radeon: power management initialized info: [drm] Connector VGA-1: get mode from tunables: info: [drm] - kern.vt.fb.modes.VGA-1 info: [drm] - kern.vt.fb.default_mode info: [drm] Connector HDMI-A-1: get mode from tunables: info: [drm] - kern.vt.fb.modes.HDMI-A-1 info: [drm] - kern.vt.fb.default_mode info: [drm] Connector LVDS-1: get mode from tunables: info: [drm] - kern.vt.fb.modes.LVDS-1 info: [drm] - kern.vt.fb.default_mode info: [drm] fb mappable at 0xD0142000 info: [drm] vram apper at 0xD0000000 info: [drm] size 8294400 info: [drm] fb depth is 24 info: [drm] pitch is 7680 fbd0 on drmn0 VT: Replacing driver "vga" with new "fb". info: [drm] Initialized radeon 2.29.0 20080528 for drmn0 on minor 0 fuse-freebsd: version 0.4.4, FUSE ABI 7.8 vboxdrv: fAsync=0 offMin=0x2a0 offMax=0xc05 Cuse v0.1.34 @ /dev/cuse wlan0: Ethernet address: 00:26:b9:12:40:a4 iwn0: iwn_read_firmware: ucode rev=0x12a80601 ubt0: on usbus6 ums0: on usbus0 ums0: 3 buttons and [XY] coordinates ID=2 wlan0: link state changed to UP WARNING: attempt to domain_add(bluetooth) after domainfinalize() WARNING: attempt to domain_add(netgraph) after domainfinalize() ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to deny, logging disabled Accounting enabled I hope this will give a hint. If anything else is needed, please tell. I can also start wpa_supplicant in debug mode or other things which might give info. Regards, Ronald. > > > On 29 May 2016 at 14:27, Ronald Klop wrote: >> On Sun, 29 May 2016 19:59:05 +0200, Adrian Chadd >> >> wrote: >> >>> hi, >>> >>> Do ifconfig wlan0 -ht (ie, disable 11n) >>> >>> see if that helps >> >> >> Hi, >> >> This does make the errors go away and startup more smoothly. >> >> Regards, >> Ronald. >> >> >> >>> >>> >>> -a >>> >>> >>> On 29 May 2016 at 05:46, Ronald Klop wrote: >>>> >>>> Hello, >>>> >>>> My laptop has troubles obtaining an ip address on the wlan0 (if_iwn). >>>> The >>>> interface has trouble staying up during dhcp resolving. Below some >>>> information from logs. *If* it obtains an IP address it seems quite >>>> stable >>>> afterwards. >>>> Before https://svnweb.freebsd.org/base?view=revision&revision=300732 I >>>> had >>>> to reboot a couple of times before it would happen to get an IP >>>> address. >>>> >>>> If I need to supply more information please tell. I'm willing to test >>>> patches also. >>>> >>>> Regards, >>>> Ronald. >>>> >>>> >>>> From uname -a: >>>> FreeBSD sjakie.klop.ws 11.0-ALPHA1 FreeBSD 11.0-ALPHA1 #7 r300901M: >>>> Sat >>>> May >>>> 28 16:54:00 CEST 2016 >>>> root@sjakie.klop.ws:/usr/obj/usr/src/sys/GENERIC-NODEBUG amd64 >>>> >>>> From dmesg: >>>> iwn0: mem 0xf8000000-0xf8001fff irq 17 >>>> at >>>> device 0.0 on pci2 >>>> >>>> From /etc/rc.conf. >>>> wlans_iwn0="wlan0" >>>> create_args_wlan0="wlanaddr 00:26:b9:12:40:a4 country NL" >>>> ifconfig_wlan0="WPA" >>>> ifconfig_wlan0="$ifconfig_wlan0 SYNCDHCP" >>>> >>>> From console.log: >>>> May 29 13:34:45 sjakie kernel: Created wlan(4) interfaces: wlan0. >>>> May 29 13:34:45 sjakie kernel: Starting wpa_supplicant. >>>> May 29 13:34:45 sjakie kernel: Starting dhclient. >>>> May 29 13:34:45 sjakie kernel: wlan0: no link ... >>>> May 29 13:34:45 sjakie kernel: .. >>>> May 29 13:34:45 sjakie kernel: ... >>>> May 29 13:34:45 sjakie kernel: got link >>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>>> port >>>> 67 >>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>>> port >>>> 67 >>>> May 29 13:34:45 sjakie kernel: wlan0 link state up -> down >>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>>> port >>>> 67 >>>> May 29 13:34:45 sjakie kernel: wlan0 link state down -> up >>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>>> port >>>> 67 >>>> May 29 13:34:45 sjakie kernel: wlan0 link state up -> down >>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>>> port >>>> 67 >>>> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to >>>> 255.255.255.255 >>>> port >>>> 67 interval 6 >>>> May 29 13:34:45 sjakie kernel: wlan0 link state down -> up >>>> May 29 13:34:45 sjakie kernel: >>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>>> port >>>> 67 >>>> May 29 13:34:45 sjakie kernel: wlan0 link state up -> down >>>> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to >>>> 255.255.255.255 >>>> port >>>> 67 interval 15 >>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>>> port >>>> 67 >>>> May 29 13:34:45 sjakie kernel: wlan0 link state down -> up >>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>>> port >>>> 67 >>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>>> port >>>> 67 >>>> May 29 13:34:45 sjakie kernel: wlan0 link state up -> down >>>> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to >>>> 255.255.255.255 >>>> port >>>> 67 interval 4 >>>> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to >>>> 255.255.255.255 >>>> port >>>> 67 interval 9 >>>> May 29 13:34:45 sjakie kernel: wlan0 link state down -> up >>>> May 29 13:34:45 sjakie kernel: >>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>>> port >>>> 67 >>>> May 29 13:34:45 sjakie kernel: wlan0 link state up -> down >>>> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to >>>> 255.255.255.255 >>>> port >>>> 67 interval 16 >>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>>> port >>>> 67 >>>> May 29 13:34:45 sjakie kernel: wlan0 link state down -> up >>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>>> port >>>> 67 >>>> May 29 13:34:45 sjakie kernel: wlan0 link state up -> down >>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>>> port >>>> 67 >>>> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to >>>> 255.255.255.255 >>>> port >>>> 67 interval 5 >>>> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to >>>> 255.255.255.255 >>>> port >>>> 67 interval 5 >>>> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to >>>> 255.255.255.255 >>>> port >>>> 67 interval 11 >>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>>> port >>>> 67 >>>> May 29 13:34:45 sjakie kernel: wlan0 link state down -> up >>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>>> port >>>> 67 >>>> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to >>>> 255.255.255.255 >>>> port >>>> 67 interval 12 >>>> May 29 13:34:45 sjakie kernel: DHCPACK from 192.168.1.1 >>>> May 29 13:34:45 sjakie kernel: bound to 192.168.1.109 -- renewal in >>>> 2147483647 seconds. >>>> >>>> From messages: >>>> May 29 13:34:45 sjakie kernel: wlan0: Ethernet address: >>>> 00:26:b9:12:40:a4 >>>> May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode >>>> rev=0x12a80601 >>>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP >>>> May 29 13:34:45 sjakie kernel: iwn0: iwn_intr: fatal firmware error >>>> May 29 13:34:45 sjakie kernel: firmware error log: >>>> May 29 13:34:45 sjakie kernel: error type = "UNKNOWN" >>>> (0x00000038) >>>> May 29 13:34:45 sjakie kernel: program counter = 0x00009F64 >>>> May 29 13:34:45 sjakie kernel: source line = 0x000003C4 >>>> May 29 13:34:45 sjakie kernel: error data = 0x0000000000000000 >>>> May 29 13:34:45 sjakie kernel: branch link = 0x00009F6000009F60 >>>> May 29 13:34:45 sjakie kernel: interrupt link = 0x0000DBEA00000000 >>>> May 29 13:34:45 sjakie kernel: time = 54908 >>>> May 29 13:34:45 sjakie kernel: driver status: >>>> May 29 13:34:45 sjakie kernel: tx ring 0: qid=0 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 1: qid=1 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 2: qid=2 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 3: qid=3 cur=2 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 4: qid=4 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 5: qid=5 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 6: qid=6 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 7: qid=7 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 8: qid=8 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 9: qid=9 cur=81 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 10: qid=10 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 11: qid=11 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 12: qid=12 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 13: qid=13 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 14: qid=14 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 15: qid=15 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 16: qid=16 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 17: qid=17 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 18: qid=18 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 19: qid=19 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: rx ring: cur=39 >>>> May 29 13:34:45 sjakie kernel: iwn0: iwn_panicked: controller >>>> panicked, >>>> iv_state = 5; restarting >>>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN >>>> May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode >>>> rev=0x12a80601 >>>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP >>>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN >>>> May 29 13:34:45 sjakie kernel: iwn0: scan timeout >>>> May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode >>>> rev=0x12a80601 >>>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP >>>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN >>>> May 29 13:34:45 sjakie kernel: iwn0: scan timeout >>>> May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode >>>> rev=0x12a80601 >>>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP >>>> May 29 13:34:45 sjakie kernel: iwn0: iwn_intr: fatal firmware error >>>> May 29 13:34:45 sjakie kernel: firmware error log: >>>> May 29 13:34:45 sjakie kernel: error type = "UNKNOWN" >>>> (0x00000038) >>>> May 29 13:34:45 sjakie kernel: program counter = 0x00009F64 >>>> May 29 13:34:45 sjakie kernel: source line = 0x000003C4 >>>> May 29 13:34:45 sjakie kernel: error data = 0x0000000000000000 >>>> May 29 13:34:45 sjakie kernel: branch link = 0x00009F6000009F60 >>>> May 29 13:34:45 sjakie kernel: interrupt link = 0x0000DBEA00000000 >>>> May 29 13:34:45 sjakie kernel: time = 7464 >>>> May 29 13:34:45 sjakie kernel: driver status: >>>> May 29 13:34:45 sjakie kernel: tx ring 0: qid=0 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 1: qid=1 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 2: qid=2 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 3: qid=3 cur=2 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 4: qid=4 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 5: qid=5 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 6: qid=6 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 7: qid=7 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 8: qid=8 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 9: qid=9 cur=81 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 10: qid=10 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 11: qid=11 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 12: qid=12 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 13: qid=13 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 14: qid=14 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 15: qid=15 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 16: qid=16 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 17: qid=17 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 18: qid=18 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 19: qid=19 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: rx ring: cur=63 >>>> May 29 13:34:45 sjakie kernel: iwn0: iwn_panicked: controller >>>> panicked, >>>> iv_state = 5; restarting >>>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN >>>> May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode >>>> rev=0x12a80601 >>>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP >>>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN >>>> May 29 13:34:45 sjakie kernel: iwn0: scan timeout >>>> May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode >>>> rev=0x12a80601 >>>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP >>>> May 29 13:34:45 sjakie kernel: iwn0: iwn_intr: fatal firmware error >>>> May 29 13:34:45 sjakie kernel: firmware error log: >>>> May 29 13:34:45 sjakie kernel: error type = "UNKNOWN" >>>> (0x00000038) >>>> May 29 13:34:45 sjakie kernel: program counter = 0x00009F64 >>>> May 29 13:34:45 sjakie kernel: source line = 0x000003C4 >>>> May 29 13:34:45 sjakie kernel: error data = 0x0000000000000000 >>>> May 29 13:34:45 sjakie kernel: branch link = 0x00009F6000009F60 >>>> May 29 13:34:45 sjakie kernel: interrupt link = 0x0000DBEA00000000 >>>> May 29 13:34:45 sjakie kernel: time = 69923 >>>> May 29 13:34:45 sjakie kernel: driver status: >>>> May 29 13:34:45 sjakie kernel: tx ring 0: qid=0 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 1: qid=1 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 2: qid=2 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 3: qid=3 cur=2 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 4: qid=4 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 5: qid=5 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 6: qid=6 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 7: qid=7 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 8: qid=8 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 9: qid=9 cur=81 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 10: qid=10 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 11: qid=11 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 12: qid=12 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 13: qid=13 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 14: qid=14 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 15: qid=15 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 16: qid=16 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 17: qid=17 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 18: qid=18 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: tx ring 19: qid=19 cur=0 queued=0 >>>> May 29 13:34:45 sjakie kernel: rx ring: cur=61 >>>> May 29 13:34:45 sjakie kernel: iwn0: iwn_panicked: controller >>>> panicked, >>>> iv_state = 5; restarting >>>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN >>>> May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode >>>> rev=0x12a80601 >>>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP >>>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN >>>> May 29 13:34:45 sjakie kernel: iwn0: scan timeout >>>> May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode >>>> rev=0x12a80601 >>>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP >>>> _______________________________________________ >>>> freebsd-current@freebsd.org mailing list >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>>> To unsubscribe, send any mail to >>>> "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Mon May 30 23:42: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 966E5B546CD; Mon, 30 May 2016 23:42:13 +0000 (UTC) (envelope-from rionda@gmail.com) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4F37C1E74; Mon, 30 May 2016 23:42:13 +0000 (UTC) (envelope-from rionda@gmail.com) Received: by mail-qk0-x235.google.com with SMTP id h185so91976273qke.2; Mon, 30 May 2016 16:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:from:in-reply-to:date:cc:message-id :references:to; bh=vlFuNRulj12hXbaTb9UvP7eLlYaMM1xDdwASShlV6SA=; b=yEkMAdQ5i/KnsIZDIYwK/H9MqqeGSCMMdJotsT2/Wo3LhjEkDW0/G+gMU0lhlrqpYq 3B2kVWMYvKZfUht1KAOSFUmEnlOn6S+IBBPnEYLaMUXZHDNZ0o9Z1drB9GO56i9DH9Q2 AepyVYZ6noj3K69oSwRufop0RdUB92rdgFZqF4oxrEYUYZKll8HdUKFOb2jK+idgt65d /q3YHjFeYAFx+8LxBhDug5swp9vMoR4+fonz+U7kYGa/3uvHeeW5ilWgW4p04Hya8kGz +ITK6cLDilskf5daX9a2O+jKygbOW/hrpL5ku7bZCgT9mf0kiozsSFAztfjMQEJkXGfl VCqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:from:in-reply-to :date:cc:message-id:references:to; bh=vlFuNRulj12hXbaTb9UvP7eLlYaMM1xDdwASShlV6SA=; b=fvcPY7q5+2PcZepY+BaO+7Od8V8m31vsPPGVWy2bRHFKw1MXOQcx+1THo3/T+E/E1L frOE60Wkr+xowgExrWBKWomX8/M9nnz/qnSzUJq3pcB4H3ThV4M7fV28M1VpHorxcw5D /RjygRMibj78+ghf8r63RhzQfN2b5rNjUQYkyECx+GDumvjkI6QWw4wRwCd0fqfCjyXs wrECNcuy4OaxOFN+ELtYi8vnbsOq78dGK+gllMPafNPCu4rgUEyZO3HVzi9AkmTqw5Aw VkdEcG3W9/vyTxd0lYCQmh4nVI/0aYgM4TYtkwiP5cV8znE2EgKw7OBTfzgkoT6u38vP D04A== X-Gm-Message-State: ALyK8tKtHwNVI33r0sgtJSUdwxgvaHjb0aW1a14EQiwZTDExnNYehLqJQP7eQ2tH9wxB3g== X-Received: by 10.55.173.84 with SMTP id w81mr2938569qke.115.1464651732527; Mon, 30 May 2016 16:42:12 -0700 (PDT) Received: from [10.78.107.164] ([64.94.31.206]) by smtp.gmail.com with ESMTPSA id s106sm7486638qge.3.2016.05.30.16.42.10 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 May 2016 16:42:11 -0700 (PDT) Sender: Matteo Riondato Subject: Re: 11.0 -r300944 build attempted WITH_META_MODE failed [amd64 targeting powerpc64 via devel/powerpc64-gcc use] Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_4A4C2305-76CE-49FE-86D9-33E44EB3E42F"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 From: Matteo Riondato In-Reply-To: Date: Mon, 30 May 2016 19:42:07 -0400 Cc: Mark Millard , FreeBSD Current , FreeBSD Toolchain , FreeBSD PowerPC ML Message-Id: References: <8A197698-51C7-43F9-9927-465602E19AAE@dsl-only.net> To: Bryan Drewery X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 23:42:13 -0000 --Apple-Mail=_4A4C2305-76CE-49FE-86D9-33E44EB3E42F Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > On May 30, 2016, at 11:29 AM, Bryan Drewery wrote: > > I should have mentioned that to enable META_MODE after not having it on > you should do a 'make cleanworld' first. This should probably be mentioned in src.conf(5) then. Best, Matteo --Apple-Mail=_4A4C2305-76CE-49FE-86D9-33E44EB3E42F 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----- iEYEARECAAYFAldMz88ACgkQ2Mp4pR7Fa+xgXACeOwMGgrSXFypvwkbQSYQtMcyX a2QAoIQuTpBpcMK4Im+cYkm3uEhTUHsm =8eEK -----END PGP SIGNATURE----- --Apple-Mail=_4A4C2305-76CE-49FE-86D9-33E44EB3E42F-- From owner-freebsd-current@freebsd.org Tue May 31 00:23: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 F06F6B5315C for ; Tue, 31 May 2016 00:23:37 +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 A30161ED4 for ; Tue, 31 May 2016 00:23:37 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 7C409B5315B; Tue, 31 May 2016 00:23:37 +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 7BBA5B5315A for ; Tue, 31 May 2016 00:23:37 +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 2EB2E1EAD; Tue, 31 May 2016 00:23:36 +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 u4V0NZ8E018088; Tue, 31 May 2016 00:23:35 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id u4V0NZgK018087; Mon, 30 May 2016 17:23:35 -0700 (PDT) (envelope-from david) Date: Mon, 30 May 2016 17:23:35 -0700 From: David Wolfskill To: current@freebsd.org, Konstantin Belousov Cc: gjb@freebsd.org, bdrewery@freebsd.org Subject: Re: 11.0 -r300944 build attempted WITH_META_MODE failed [amd64 targeting powerpc64 via devel/powerpc64-gcc use] Message-ID: <20160531002335.GA1080@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org, Konstantin Belousov , gjb@freebsd.org, bdrewery@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="M9u+pkcMrQJw6us1" Content-Disposition: inline In-Reply-To: <20160530185227.GZ1080@albert.catwhisker.org> User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 00:23:38 -0000 --M9u+pkcMrQJw6us1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 30, 2016 at 11:52:27AM -0700, David Wolfskill wrote: > ... > > > May 30 11:29:31 g1-252 root: /etc/rc: WARNING: Unable to load kernel = module linux64 > > > May 30 11:29:31 g1-252 kernel: KLD linux64.ko: depends on kernel - no= t available or version mismatch > > > May 30 11:29:31 g1-252 kernel: linker_load_file: Unsupported file type > >=20 > > Your kernel was built from older sources than you used to build the nvi= dia > > module. I mean, the kernel headers used for the module build where > > updated comparing with binaries that are installed into /boot/kernel. >=20 > Hmmm... I'm ... unlcear ... on how that could have happened. > ... Turns out that Bryan Drewery hit it (in a different thread): On Mon, May 30, 2016 at 08:29:40AM -0700, Bryan Drewery wrote: > This failure is not likely related to META_MODE. >=20 > I should have mentioned that to enable META_MODE after not having it on > you should do a 'make cleanworld' first. > .... Given that hint, in my r300994 source tree, I first did: cd /usr/src && make cleanworld then re-built everything again (while Spouse and I were at a neighbor's place for a cookout).... On reboot, everything looks good, and linux64.ko (and nvidia.ko) are loaded: g1-252(11.0)[1] uname -a FreeBSD g1-252.catwhisker.org 11.0-ALPHA1 FreeBSD 11.0-ALPHA1 #0 r300994M/= 300994:1100115: Mon May 30 14:42:29 PDT 2016 root@g1-252.catwhisker.org= :/common/S4/obj/usr/src/sys/CANARY amd64 g1-252(11.0)[2] kldstat=20 Id Refs Address Size Name 1 37 0xffffffff80200000 1e074a8 kernel 2 1 0xffffffff82009000 232f8 geom_eli.ko 3 2 0xffffffff8202d000 9d6d8 linux.ko 4 4 0xffffffff820cb000 d1f0 linux_common.ko 5 1 0xffffffff820d9000 4c50 coretemp.ko 6 1 0xffffffff820de000 546b0 iwn5000fw.ko 7 1 0xffffffff82133000 b67b50 nvidia.ko 8 1 0xffffffff82c9b000 b838 filemon.ko 9 1 0xffffffff82e21000 f01c tmpfs.ko 10 1 0xffffffff82e31000 595a fdescfs.ko 11 1 0xffffffff82e37000 a9e8 linprocfs.ko 12 1 0xffffffff82e42000 39672 linux64.ko g1-252(11.0)[3]=20 Sorry for the false alarm. 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. --M9u+pkcMrQJw6us1 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJXTNmHXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XO1sIAK6kSnT7MG7R6O2UAdizj/hx 9RBRkCq89DwmNjDljY7a9H0q8SJKoL6oQeYGimnj/87raY/rkZZA2X3kR9hQn1iN t7LGxY401ZRa9iFN+dhgMXNIihxAA2O2lr6DObBMRHCfrjKhii2Uho5ZwQUdF2Ye axhdJVbSGkspv/7g00Mj+uunx+OYftRtKlip4vUQbC8BvOoXMuDcK4GdWLw40OvS E1WlupU9v+N7EzbcKrbhH1cOyJll2JHqPWIazoDn6+t0OrNOAWblSzovuEPhwNDg irRXT0qBQDWVSV2XxJFyVLnWFvaMSiY09YzyC491s8Uvi2inrArN1yGdJAiVRjM= =do8G -----END PGP SIGNATURE----- --M9u+pkcMrQJw6us1-- From owner-freebsd-current@freebsd.org Tue May 31 00:26: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 2197EB532F5 for ; Tue, 31 May 2016 00:26:51 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 0CBEF113E for ; Tue, 31 May 2016 00:26:51 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 085CAB532F4; Tue, 31 May 2016 00:26: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 0803BB532F3 for ; Tue, 31 May 2016 00:26:51 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id E01DD113D; Tue, 31 May 2016 00:26:50 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id 8FBB717DC; Tue, 31 May 2016 00:26:50 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Tue, 31 May 2016 00:26:49 +0000 From: Glen Barber To: David Wolfskill Cc: current@freebsd.org, Konstantin Belousov , bdrewery@freebsd.org Subject: Re: 11.0 -r300944 build attempted WITH_META_MODE failed [amd64 targeting powerpc64 via devel/powerpc64-gcc use] Message-ID: <20160531002649.GW80759@FreeBSD.org> References: <20160530185227.GZ1080@albert.catwhisker.org> <20160531002335.GA1080@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="O7hm+SMpb/lu0d4d" Content-Disposition: inline In-Reply-To: <20160531002335.GA1080@albert.catwhisker.org> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 00:26:51 -0000 --O7hm+SMpb/lu0d4d Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 30, 2016 at 05:23:35PM -0700, David Wolfskill wrote: > On Mon, May 30, 2016 at 11:52:27AM -0700, David Wolfskill wrote: > > ... > > > > May 30 11:29:31 g1-252 root: /etc/rc: WARNING: Unable to load kerne= l module linux64 > > > > May 30 11:29:31 g1-252 kernel: KLD linux64.ko: depends on kernel - = not available or version mismatch > > > > May 30 11:29:31 g1-252 kernel: linker_load_file: Unsupported file t= ype > > >=20 > > > Your kernel was built from older sources than you used to build the n= vidia > > > module. I mean, the kernel headers used for the module build where > > > updated comparing with binaries that are installed into /boot/kernel. > >=20 > > Hmmm... I'm ... unlcear ... on how that could have happened. > > ... >=20 > Turns out that Bryan Drewery hit it (in a different thread): >=20 > On Mon, May 30, 2016 at 08:29:40AM -0700, Bryan Drewery wrote: > > This failure is not likely related to META_MODE. > >=20 > > I should have mentioned that to enable META_MODE after not having it on > > you should do a 'make cleanworld' first. > > .... >=20 > Given that hint, in my r300994 source tree, I first did: >=20 > cd /usr/src && make cleanworld >=20 > then re-built everything again (while Spouse and I were at a neighbor's > place for a cookout).... >=20 > On reboot, everything looks good, and linux64.ko (and nvidia.ko) are > loaded: >=20 > g1-252(11.0)[1] uname -a > FreeBSD g1-252.catwhisker.org 11.0-ALPHA1 FreeBSD 11.0-ALPHA1 #0 r300994= M/300994:1100115: Mon May 30 14:42:29 PDT 2016 root@g1-252.catwhisker.o= rg:/common/S4/obj/usr/src/sys/CANARY amd64 > g1-252(11.0)[2] kldstat=20 > Id Refs Address Size Name > 1 37 0xffffffff80200000 1e074a8 kernel > 2 1 0xffffffff82009000 232f8 geom_eli.ko > 3 2 0xffffffff8202d000 9d6d8 linux.ko > 4 4 0xffffffff820cb000 d1f0 linux_common.ko > 5 1 0xffffffff820d9000 4c50 coretemp.ko > 6 1 0xffffffff820de000 546b0 iwn5000fw.ko > 7 1 0xffffffff82133000 b67b50 nvidia.ko > 8 1 0xffffffff82c9b000 b838 filemon.ko > 9 1 0xffffffff82e21000 f01c tmpfs.ko > 10 1 0xffffffff82e31000 595a fdescfs.ko > 11 1 0xffffffff82e37000 a9e8 linprocfs.ko > 12 1 0xffffffff82e42000 39672 linux64.ko > g1-252(11.0)[3]=20 >=20 >=20 > Sorry for the false alarm. >=20 I'd much prefer a false alarm over an unreported true alarm. :-) Thanks for the followup, glad it is working now. Glen --O7hm+SMpb/lu0d4d Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXTNpDAAoJEAMUWKVHj+KTg4sP/icCwTTWdy1ud8bfqm7FG81c hCaY1nV+ZpxCO2q3JuqPsGlmLoQx0Ej25Yu0hCqSHAwPd0yFw4uZb+nMcZorNuEp nGZqQhv02ORRkn9U1ecVyERH3syQ8bLIQq+QX/BsUJDTCZelMnxR5oy4NFBz4U3v DTdJgSYUCEtgawgbEGsKuYdLZlvh3H14ERGGF2vYV+1c1JcXxlDscvlWlcbO7CCA OTDPAKZqibv6OC+UALUGBzbu566+ZRGuntAON3/k+3vjjRtqMfY5jCe9NiK4yRAq J6aTPD/qSrIJ04740NN2N7RAs+bTpcZr98NQiR6UUh+2lIxm8C+cyNGyFLHeY2HO Gs1rsJggOz3rn0pZPx9OEZR8XaHcMeQ2HAJQe5P9RabAN/8Iij4YBQMFtmK7uKi7 skz/LIkBnOEZIMgSdjosBmkJM7+PT+7KfxBZLyKpAFlV8OICAmRNQajyWw2E8PR2 7a/0Lm/x+UJXDV1trUx+aMnGvaiH8qaPlIUvLfpAKv0FWsdq2R613YuleeoU+Mdc uv1GaXAXTr2Xzm/IMMxhrR58CPfsFBLsLG7VDTUpX8QyOPjb+2QeWdyj+IZfNrBg Ao6reeS3Jn48i3OQrZX7DBacfYyqTKUmm7p3qnweARC8SOTVVJqbpwsqEr4i9G1U dQra1D2Vh5xqRz19GnZL =Liy8 -----END PGP SIGNATURE----- --O7hm+SMpb/lu0d4d-- From owner-freebsd-current@freebsd.org Tue May 31 00:38:41 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ED7E1B53495 for ; Tue, 31 May 2016 00:38:40 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C152E16E8 for ; Tue, 31 May 2016 00:38:40 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x22d.google.com with SMTP id p64so76463446ioi.2 for ; Mon, 30 May 2016 17:38:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=8JpMsdScglX2NsQQuOWQK3HjRIIBeFqlFlhwKxCPK90=; b=MqPOG5ARAPV5ScBLAVPOluY7JBa/1vH7IAMkDivwfczvsqvnMPUj+IBuu1xtVJpNfs S6IitkAghJb88WgzXahosGmKa96jRXrProvF559/beY1iA2Tt8oGEmZxwVxY3X9sxCFz rDKPaeizIz7yOJE5B9c0JUAj3BrkIifI//4rsp/IoA91RNH/UpNQ02rLrbywhltEKXz1 +g+Cf47gqANxMXDyzV94AnTA5dmnqhRlEteCuhgcILgBWENtCv2C+lSDIodS8s7U+QiB AeLsWdBAnY2SL0dfhOhAKt4xuMTCBt3CW8HZ8xqb5YrTTlRRjmw0pnQhN9gUEJDa/eMj MF+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=8JpMsdScglX2NsQQuOWQK3HjRIIBeFqlFlhwKxCPK90=; b=P42ZIcGbxOs9KEmN6nRNjbFu83FNIYyRiXFh34n/FPfyDyhbCLKJoa89fisFKLly/3 zTxTcqZ0hKV/zFnORriDIpoZ33rBeQFTX1YvYkZ5j3b4dq6HmwWZ8sqzolse/U4RgKgs VHvw5376fHxHRKjlzF6kDZc8eh0G4O5scKn/chcuXx4DdEydARWgjaVsQpTFvEyfCRfP SWcYjuvzFF+YQizpt7kd83Fh+Fr9DHXTHC2++uDaDK2FTiw8ga/ZHB5VqRRniFgtZcji w5mbBJ34PsEKyNQsxGzcuSOOqzlYmjczE0hn7sn8RcZO7A6NXlXCTUeFYBKD5hG47oWe eO8Q== X-Gm-Message-State: ALyK8tLYUA6tVWpFk4yz/e3Ntd0X6wR7XBwGraL7Rjl8rI3Hdg+6rm8m/QRlTgN0AvDOiBW5/h0YI5hXS+cj7A== MIME-Version: 1.0 X-Received: by 10.107.144.67 with SMTP id s64mr20939965iod.165.1464655118965; Mon, 30 May 2016 17:38:38 -0700 (PDT) Received: by 10.36.113.3 with HTTP; Mon, 30 May 2016 17:38:38 -0700 (PDT) In-Reply-To: References: Date: Mon, 30 May 2016 17:38:38 -0700 Message-ID: Subject: Re: if_iwn dhcp troubles From: Adrian Chadd To: Ronald Klop Cc: freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 00:38:41 -0000 hi, what's the output of 'ifconfig -v wlan0 list scan' ? -a On 30 May 2016 at 14:15, Ronald Klop wrote: > On Mon, 30 May 2016 03:01:10 +0200, Adrian Chadd > wrote: > >> ok, so there seem to be more lingering 802.11n issues. can you tell me >> mrore about the environment there, so I can try to duplicate it? >> >> I'd like to fix whatever 11n issues there are in iwn! >> >> Thanks! >> >> >> -a > > > Hi Adrian, > > I don't know what you want to know, but it is just my laptop at home. I > installed an Intel WiFi card, because the Broadcom it had didn't have > support in FreeBSD. I normally have if_lagg configured, but disabled it to > debug this. > I connect with WiFi to a Ubiquiti Unifi AP AC Lite > (https://www.ubnt.com/unifi/unifi-ap-ac-lite/). > Other (non-freebsd) devices, like a phone, connect happily with the WiFi. > > > pciconf -vl: > ... > iwn0@pci0:4:0:0: class=0x028000 card=0x40608086 chip=0x088e8086 > rev=0x24 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Centrino Advanced-N 6235' > class = network > ... > ================= > cat /etc/wpa_supplicant.conf (really plain) > network={ > ssid="xxxxxxxxx" > psk="yyyyyyyy" > } > ================= > cat /etc/rc.conf: > # Kernel > zfs_enable="YES" > saver="green" > accounting_enable="YES" > powerd_enable="YES" > devfs_system_ruleset="system" > background_fsck="NO" > dumpdev="AUTO" > kld_list="coretemp ichsmb radeonkms fuse if_lagg vboxdrv cuse" > keymap="/etc/keymap.test" > # if_bwn bwn_v4_lp_ucode" > > # Networking > hostname="sjakie.klop.ws" > #wpa_supplicant_flags="$wpa_supplicant_flags -d" > wlans_iwn0="wlan0" > create_args_wlan0="wlanaddr 00:26:b9:12:40:a4 country NL" > ifconfig_wlan0="-ht WPA" > #ifconfig_bge0="up" > #cloned_interfaces="lagg0" > #ifconfig_lagg0="laggproto failover laggport bge0 laggport wlan0 SYNCDHCP" > > ifconfig_wlan0="$ifconfig_wlan0 DHCP" > > #ifconfig_DEFAULT="SYNCDHCP" > #ifconfig_em0_alias0="inet 192.168.1.36 netmask 0xffffffff" > firewall_enable="YES" > firewall_type="/etc/ipfw.sjakie" > #local_unbound_enable="YES" > > # Daemons > ntpdate_enable="YES" > ntpd_enable="YES" > sshd_enable="YES" > inetd_enable="YES" > syslogd_flags="" > sendmail_enable="NO" > sendmail_submit_enable="NO" > sendmail_outbound_enable="NO" > sendmail_msp_queue_enable="NO" > > # Bluetooth > #hcsecd_enable="YES" > #sdpd_enable="YES" > #bthidd_enable="YES" > > # Ports > bsdstats_enable="YES" > #postfix_enable="YES" > #smtpd_enable="YES" > #smtpd_flags="-v" > cupsd_enable="YES" > dbus_enable="YES" > polkitd_enable="YES" > #hald_enable="YES" > smartd_enable="YES" > #mdnsd_enable="YES" > avahi_daemon_enable="YES" > bruteblockd_enable="YES" > bruteblockd_table="1" > bruteblockd_flags="-s 5" > #collectd_enable="YES" > > rpcbind_enable="YES" > #nfs_client_enable="YES" > mountd_enable="YES" > nfs_server_enable="YES" > > panicmail_enable="YES" > slim_enable="YES" > > webcamd_enable="YES" > webcamd_flags="-m v4l2-dev.v4l_hflip=1" > > > ============= > dmesg: > Copyright (c) 1992-2016 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 11.0-ALPHA1 #7 r300901M: Sat May 28 16:54:00 CEST 2016 > root@sjakie.klop.ws:/usr/obj/usr/src/sys/GENERIC-NODEBUG amd64 > FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM > 3.8.0) > can't re-use a leaf (ixl_rx_miss_bufs)! > VT(vga): resolution 640x480 > CPU: Pentium(R) Dual-Core CPU T4300 @ 2.10GHz (2094.80-MHz K8-class > CPU) > Origin="GenuineIntel" Id=0x1067a Family=0x6 Model=0x17 Stepping=10 > > Features=0xbfebfbff > > Features2=0xc00e39d > AMD Features=0x20100800 > AMD Features2=0x1 > TSC: P-state invariant, performance statistics > real memory = 4294967296 (4096 MB) > avail memory = 4047171584 (3859 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) > random: unblocking device. > ioapic0 irqs 0-23 on motherboard > random: entropy device external interface > kbd1 at kbdmux0 > netmap: loaded module > module_register_init: MOD_LOAD (vesa, 0xffffffff80fe16e0, 0) error 19 > vtvga0: on motherboard > cryptosoft0: on motherboard > acpi0: on motherboard > acpi0: Power Button (fixed) > Timecounter "HPET" frequency 14318180 Hz quality 950 > Event timer "HPET" frequency 14318180 Hz quality 450 > Event timer "HPET1" frequency 14318180 Hz quality 440 > Event timer "HPET2" frequency 14318180 Hz quality 440 > Event timer "HPET3" frequency 14318180 Hz quality 440 > cpu0: on acpi0 > cpu1: on acpi0 > atrtc0: port 0x70-0x77 irq 8 on acpi0 > atrtc0: Warning: Couldn't map I/O. > Event timer "RTC" frequency 32768 Hz quality 0 > attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > acpi_ec0: port 0x62,0x66 on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: irq 16 at device 1.0 on pci0 > pcib1: [GIANT-LOCKED] > pci1: on pcib1 > vgapci0: port 0x2000-0x20ff mem > 0xd0000000-0xdfffffff,0xfc000000-0xfc00ffff irq 16 at device 0.0 on pci1 > vgapci0: Boot video device > hdac0: mem 0xfc010000-0xfc013fff irq 17 at device > 0.1 on pci1 > uhci0: port 0x1800-0x181f irq 16 at > device 26.0 on pci0 > usbus0 on uhci0 > uhci1: port 0x1820-0x183f irq 21 at > device 26.1 on pci0 > usbus1 on uhci1 > uhci2: port 0x1840-0x185f irq 19 at > device 26.2 on pci0 > usbus2 on uhci2 > ehci0: mem 0xfc504800-0xfc504bff > irq 19 at device 26.7 on pci0 > usbus3: EHCI version 1.0 > usbus3 on ehci0 > hdac1: mem 0xfc500000-0xfc503fff irq 22 at > device 27.0 on pci0 > pcib2: irq 17 at device 28.0 on pci0 > pcib2: [GIANT-LOCKED] > pcib3: irq 16 at device 28.1 on pci0 > pcib3: [GIANT-LOCKED] > pci2: on pcib3 > iwn0: mem 0xf8000000-0xf8001fff irq 17 at > device 0.0 on pci2 > pcib4: irq 19 at device 28.3 on pci0 > pcib4: [GIANT-LOCKED] > pcib5: irq 16 at device 28.5 on pci0 > pcib5: [GIANT-LOCKED] > pci3: on pcib5 > bge0: 0x5784100> mem 0xfc100000-0xfc10ffff irq 17 at device 0.0 on pci3 > bge0: CHIP ID 0x05784100; ASIC REV 0x5784; CHIP REV 0x57841; PCI-E > miibus0: on bge0 > brgphy0: PHY 1 on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > bge0: Using defaults for TSO: 65518/35/2048 > bge0: Ethernet address: 00:26:b9:12:40:a4 > uhci3: port 0x1860-0x187f irq 23 at > device 29.0 on pci0 > usbus4 on uhci3 > uhci4: port 0x1880-0x189f irq 19 at > device 29.1 on pci0 > usbus5 on uhci4 > uhci5: port 0x18a0-0x18bf irq 18 at > device 29.2 on pci0 > usbus6 on uhci5 > ehci1: mem 0xfc504c00-0xfc504fff > irq 23 at device 29.7 on pci0 > usbus7: EHCI version 1.0 > usbus7 on ehci1 > pcib6: at device 30.0 on pci0 > pci4: on pcib6 > pci4: at device 1.0 (no driver attached) > sdhci_pci0: mem 0xfc200800-0xfc2008ff irq 18 at device 1.1 > on pci4 > sdhci_pci0: 1 slot(s) allocated > isab0: at device 31.0 on pci0 > isa0: on isab0 > ahci0: port > 0x18f0-0x18f7,0x18e4-0x18e7,0x18e8-0x18ef,0x18e0-0x18e3,0x18c0-0x18df mem > 0xfc504000-0xfc5047ff irq 19 at device 31.2 on pci0 > ahci0: AHCI v1.20 with 4 3Gbps ports, Port Multiplier supported > ahcich0: at channel 0 on ahci0 > ahcich1: at channel 1 on ahci0 > ahcich5: at channel 5 on ahci0 > acpi_button0: on acpi0 > acpi_button1: on acpi0 > acpi_lid0: on acpi0 > acpi_acad0: on acpi0 > battery0: on acpi0 > acpi_tz0: on acpi0 > acpi_tz1: on acpi0 > acpi_tz2: on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: model Generic PS/2 mouse, device ID 0 > ppc0: cannot reserve I/O port range > est0: on cpu0 > est1: on cpu1 > ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is > present; > to enable, add "vfs.zfs.prefetch_disable=0" to > /boot/loader.conf. > ZFS filesystem version: 5 > ZFS storage pool version: features support (5000) > Timecounters tick every 1.000 msec > hdacc0: at cad 0 on hdac0 > hdaa0: at nid 1 on hdacc0 > pcm0: at nid 3 on hdaa0 > hdacc1: at cad 0 on hdac1 > hdaa1: at nid 1 on hdacc1 > pcm1: at nid 13,10 and 14 on hdaa1 > pcm2: at nid 15 and 19 on hdaa1 > usbus0: 12Mbps Full Speed USB v1.0 > usbus1: 12Mbps Full Speed USB v1.0 > usbus2: 12Mbps Full Speed USB v1.0 > usbus3: 480Mbps High Speed USB v2.0 > ugen0.1: at usbus0 > uhub0: on usbus0 > ugen1.1: at usbus1 > uhub1: on usbus1 > ugen2.1: at usbus2 > uhub2: on usbus2 > ugen3.1: at usbus3 > uhub3: on usbus3 > usbus4: 12Mbps Full Speed USB v1.0 > usbus5: 12Mbps Full Speed USB v1.0 > usbus6: 12Mbps Full Speed USB v1.0 > usbus7: 480Mbps High Speed USB v2.0 > ugen4.1: at usbus4 > uhub4: on usbus4 > ugen5.1: at usbus5 > uhub5: on usbus5 > ugen6.1: at usbus6 > uhub6: on usbus6 > ugen7.1: at usbus7 > uhub7: on usbus7 > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ACS-2 ATA SATA 3.x device > ada0: Serial Number S1DHNSAD914271K > ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 476940MB (976773168 512 byte sectors) > ada0: quirks=0x3<4K,NCQ_TRIM_BROKEN> > cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 > cd0: Removable CD-ROM SCSI device > cd0: Serial Number KZZ9B7E2004 > cd0: 150.000MB/s transfers (SATA 1.x, UDMA6, ATAPI 12bytes, PIO 8192bytes) > cd0: Attempt to query device size failed: NOT READY, Medium not present - > tray open > SMP: AP CPU #1 Launched! > Timecounter "TSC" frequency 2094797271 Hz quality 1000 > Trying to mount root from zfs:zroot/root []... > Root mount waiting for: usbus7 usbus6 usbus5 usbus4 usbus3 usbus2 usbus1 > usbus0 > uhub0: 2 ports with 2 removable, self powered > uhub1: 2 ports with 2 removable, self powered > uhub2: 2 ports with 2 removable, self powered > uhub5: 2 ports with 2 removable, self powered > uhub4: 2 ports with 2 removable, self powered > uhub6: 2 ports with 2 removable, self powered > Root mount waiting for: usbus7 usbus3 > Root mount waiting for: usbus7 usbus3 > uhub3: 6 ports with 6 removable, self powered > uhub7: 6 ports with 6 removable, self powered > Root mount waiting for: usbus3 > ugen6.2: at usbus6 > ugen0.2: at usbus0 > uhub8: on usbus0 > Root mount waiting for: usbus3 > uhub8: 3 ports with 0 removable, self powered > ugen3.2: at usbus3 > ugen0.3: at usbus0 > ukbd0: on > usbus0 > kbd2 at ukbd0 > GEOM_ELI: Device gpt/swap0.eli created. > GEOM_ELI: Encryption: AES-XTS 128 > GEOM_ELI: Crypto: software > ugen0.4: at usbus0 > coretemp0: on cpu0 > coretemp1: on cpu1 > ichsmb0: port 0x1c00-0x1c1f irq 19 at > device 31.3 on pci0 > smbus0: on ichsmb0 > info: [drm] Initialized drm 1.1.0 20060810 > drmn0: on vgapci0 > info: [drm] RADEON_IS_PCIE > info: [drm] initializing kernel modesetting (RV710 0x1002:0x9553 > 0x1028:0x02BE). > info: [drm] register mmio base: 0xFC000000 > info: [drm] register mmio size: 65536 > info: [drm] radeon_atrm_get_bios: ===> Try ATRM... > info: [drm] radeon_atrm_get_bios: pci_find_class() found: 0:1:0:0, > vendor=1002, device=9553 > info: [drm] radeon_atrm_get_bios: Get ACPI device handle > info: [drm] radeon_atrm_get_bios: Get ACPI handle for "ATRM" > info: [drm] radeon_atrm_get_bios: Failed to get "ATRM" handle: AE_NOT_FOUND > info: [drm] radeon_acpi_vfct_bios: ===> Try VFCT... > info: [drm] radeon_acpi_vfct_bios: Get "VFCT" ACPI table > info: [drm] radeon_acpi_vfct_bios: Failed to get "VFCT" table: AE_NOT_FOUND > info: [drm] igp_read_bios_from_vram: ===> Try IGP's VRAM... > info: [drm] igp_read_bios_from_vram: VRAM base address: 0xd0000000 > info: [drm] igp_read_bios_from_vram: Map address: 0xfffff800d0000000 (262144 > bytes) > info: [drm] igp_read_bios_from_vram: Incorrect BIOS signature: 0x0000 > info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM... > info: [drm] radeon_read_bios: Map address: 0xfffff800000c0000 (131072 bytes) > info: [drm] ATOM BIOS: BR32787 > drmn0: info: VRAM: 512M 0x0000000000000000 - 0x000000001FFFFFFF (512M used) > drmn0: info: GTT: 512M 0x0000000020000000 - 0x000000003FFFFFFF > info: [drm] Detected VRAM RAM=512M, BAR=256M > info: [drm] RAM width 64bits DDR > [TTM] Zone kernel: Available graphics memory: 2059256 kiB > [TTM] Initializing pool allocator > info: [drm] radeon: 512M of VRAM memory ready > info: [drm] radeon: 512M of GTT memory ready. > info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). > info: [drm] Driver supports precise vblank timestamp query. > info: [drm] MSI enabled 1 message(s) > drmn0: info: radeon: using MSI. > info: [drm] radeon: irq initialized. > info: [drm] GART: num cpu pages 131072, num gpu pages 131072 > info: [drm] probing gen 2 caps for device 8086:2a41 = 1/0 > info: [drm] Loading RV710 Microcode > info: [drm] PCIE GART of 512M enabled (table at 0x0000000000040000). > drmn0: info: WB enabled > drmn0: info: fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu > addr 0x0xfffff80014286c00 > drmn0: info: fence driver on ring 3 use gpu addr 0x0000000020000c0c and cpu > addr 0x0xfffff80014286c0c > info: [drm] ring test on 0 succeeded in 1 usecs > info: [drm] ring test on 3 succeeded in 1 usecs > info: [drm] ib test on ring 0 succeeded in 0 usecs > info: [drm] ib test on ring 3 succeeded in 0 usecs > info: [drm] radeon_device_init: Taking over the fictitious range > 0xd0000000-0xe0000000 > iicbus0: on iicbb0 addr 0xff > iic0: on iicbus0 > iicbus1: on iicbb1 addr 0x0 > iic1: on iicbus1 > iicbus2: on iicbb2 addr 0x0 > iic2: on iicbus2 > iicbus3: on iicbb3 addr 0x0 > iic3: on iicbus3 > iicbus4: on iicbb4 addr 0x0 > iic4: on iicbus4 > iicbus5: on iicbb5 addr 0x0 > iic5: on iicbus5 > iicbus6: on iicbb6 addr 0x0 > iic6: on iicbus6 > info: [drm] Radeon Display Connectors > info: [drm] Connector 0: > info: [drm] VGA-1 > info: [drm] DDC: 0x7fa0 0x7fa0 0x7fa4 0x7fa4 0x7fa8 0x7fa8 0x7fac 0x7fac > info: [drm] Encoders: > info: [drm] CRT1: INTERNAL_KLDSCP_DAC1 > info: [drm] Connector 1: > info: [drm] HDMI-A-1 > info: [drm] HPD1 > info: [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c > info: [drm] Encoders: > info: [drm] DFP1: INTERNAL_UNIPHY > info: [drm] Connector 2: > info: [drm] LVDS-1 > info: [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c > info: [drm] Encoders: > info: [drm] LCD1: INTERNAL_UNIPHY2 > info: [drm] Internal thermal controller with fan control > info: [drm] radeon: power management initialized > info: [drm] Connector VGA-1: get mode from tunables: > info: [drm] - kern.vt.fb.modes.VGA-1 > info: [drm] - kern.vt.fb.default_mode > info: [drm] Connector HDMI-A-1: get mode from tunables: > info: [drm] - kern.vt.fb.modes.HDMI-A-1 > info: [drm] - kern.vt.fb.default_mode > info: [drm] Connector LVDS-1: get mode from tunables: > info: [drm] - kern.vt.fb.modes.LVDS-1 > info: [drm] - kern.vt.fb.default_mode > info: [drm] fb mappable at 0xD0142000 > info: [drm] vram apper at 0xD0000000 > info: [drm] size 8294400 > info: [drm] fb depth is 24 > info: [drm] pitch is 7680 > fbd0 on drmn0 > VT: Replacing driver "vga" with new "fb". > info: [drm] Initialized radeon 2.29.0 20080528 for drmn0 on minor 0 > fuse-freebsd: version 0.4.4, FUSE ABI 7.8 > vboxdrv: fAsync=0 offMin=0x2a0 offMax=0xc05 > Cuse v0.1.34 @ /dev/cuse > wlan0: Ethernet address: 00:26:b9:12:40:a4 > iwn0: iwn_read_firmware: ucode rev=0x12a80601 > ubt0: on > usbus6 > ums0: on > usbus0 > ums0: 3 buttons and [XY] coordinates ID=2 > wlan0: link state changed to UP > WARNING: attempt to domain_add(bluetooth) after domainfinalize() > WARNING: attempt to domain_add(netgraph) after domainfinalize() > ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to deny, > logging disabled > Accounting enabled > > > I hope this will give a hint. If anything else is needed, please tell. I can > also start wpa_supplicant in debug mode or other things which might give > info. > > Regards, > Ronald. > > > > >> >> >> On 29 May 2016 at 14:27, Ronald Klop wrote: >>> >>> On Sun, 29 May 2016 19:59:05 +0200, Adrian Chadd >>> wrote: >>> >>>> hi, >>>> >>>> Do ifconfig wlan0 -ht (ie, disable 11n) >>>> >>>> see if that helps >>> >>> >>> >>> Hi, >>> >>> This does make the errors go away and startup more smoothly. >>> >>> Regards, >>> Ronald. >>> >>> >>> >>>> >>>> >>>> -a >>>> >>>> >>>> On 29 May 2016 at 05:46, Ronald Klop wrote: >>>>> >>>>> >>>>> Hello, >>>>> >>>>> My laptop has troubles obtaining an ip address on the wlan0 (if_iwn). >>>>> The >>>>> interface has trouble staying up during dhcp resolving. Below some >>>>> information from logs. *If* it obtains an IP address it seems quite >>>>> stable >>>>> afterwards. >>>>> Before https://svnweb.freebsd.org/base?view=revision&revision=300732 I >>>>> had >>>>> to reboot a couple of times before it would happen to get an IP >>>>> address. >>>>> >>>>> If I need to supply more information please tell. I'm willing to test >>>>> patches also. >>>>> >>>>> Regards, >>>>> Ronald. >>>>> >>>>> >>>>> From uname -a: >>>>> FreeBSD sjakie.klop.ws 11.0-ALPHA1 FreeBSD 11.0-ALPHA1 #7 r300901M: Sat >>>>> May >>>>> 28 16:54:00 CEST 2016 >>>>> root@sjakie.klop.ws:/usr/obj/usr/src/sys/GENERIC-NODEBUG amd64 >>>>> >>>>> From dmesg: >>>>> iwn0: mem 0xf8000000-0xf8001fff irq 17 >>>>> at >>>>> device 0.0 on pci2 >>>>> >>>>> From /etc/rc.conf. >>>>> wlans_iwn0="wlan0" >>>>> create_args_wlan0="wlanaddr 00:26:b9:12:40:a4 country NL" >>>>> ifconfig_wlan0="WPA" >>>>> ifconfig_wlan0="$ifconfig_wlan0 SYNCDHCP" >>>>> >>>>> From console.log: >>>>> May 29 13:34:45 sjakie kernel: Created wlan(4) interfaces: wlan0. >>>>> May 29 13:34:45 sjakie kernel: Starting wpa_supplicant. >>>>> May 29 13:34:45 sjakie kernel: Starting dhclient. >>>>> May 29 13:34:45 sjakie kernel: wlan0: no link ... >>>>> May 29 13:34:45 sjakie kernel: .. >>>>> May 29 13:34:45 sjakie kernel: ... >>>>> May 29 13:34:45 sjakie kernel: got link >>>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>>>> port >>>>> 67 >>>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>>>> port >>>>> 67 >>>>> May 29 13:34:45 sjakie kernel: wlan0 link state up -> down >>>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>>>> port >>>>> 67 >>>>> May 29 13:34:45 sjakie kernel: wlan0 link state down -> up >>>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>>>> port >>>>> 67 >>>>> May 29 13:34:45 sjakie kernel: wlan0 link state up -> down >>>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>>>> port >>>>> 67 >>>>> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 >>>>> port >>>>> 67 interval 6 >>>>> May 29 13:34:45 sjakie kernel: wlan0 link state down -> up >>>>> May 29 13:34:45 sjakie kernel: >>>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>>>> port >>>>> 67 >>>>> May 29 13:34:45 sjakie kernel: wlan0 link state up -> down >>>>> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 >>>>> port >>>>> 67 interval 15 >>>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>>>> port >>>>> 67 >>>>> May 29 13:34:45 sjakie kernel: wlan0 link state down -> up >>>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>>>> port >>>>> 67 >>>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>>>> port >>>>> 67 >>>>> May 29 13:34:45 sjakie kernel: wlan0 link state up -> down >>>>> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 >>>>> port >>>>> 67 interval 4 >>>>> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 >>>>> port >>>>> 67 interval 9 >>>>> May 29 13:34:45 sjakie kernel: wlan0 link state down -> up >>>>> May 29 13:34:45 sjakie kernel: >>>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>>>> port >>>>> 67 >>>>> May 29 13:34:45 sjakie kernel: wlan0 link state up -> down >>>>> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 >>>>> port >>>>> 67 interval 16 >>>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>>>> port >>>>> 67 >>>>> May 29 13:34:45 sjakie kernel: wlan0 link state down -> up >>>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>>>> port >>>>> 67 >>>>> May 29 13:34:45 sjakie kernel: wlan0 link state up -> down >>>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>>>> port >>>>> 67 >>>>> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 >>>>> port >>>>> 67 interval 5 >>>>> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 >>>>> port >>>>> 67 interval 5 >>>>> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 >>>>> port >>>>> 67 interval 11 >>>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>>>> port >>>>> 67 >>>>> May 29 13:34:45 sjakie kernel: wlan0 link state down -> up >>>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255 >>>>> port >>>>> 67 >>>>> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255 >>>>> port >>>>> 67 interval 12 >>>>> May 29 13:34:45 sjakie kernel: DHCPACK from 192.168.1.1 >>>>> May 29 13:34:45 sjakie kernel: bound to 192.168.1.109 -- renewal in >>>>> 2147483647 seconds. >>>>> >>>>> From messages: >>>>> May 29 13:34:45 sjakie kernel: wlan0: Ethernet address: >>>>> 00:26:b9:12:40:a4 >>>>> May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode >>>>> rev=0x12a80601 >>>>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP >>>>> May 29 13:34:45 sjakie kernel: iwn0: iwn_intr: fatal firmware error >>>>> May 29 13:34:45 sjakie kernel: firmware error log: >>>>> May 29 13:34:45 sjakie kernel: error type = "UNKNOWN" (0x00000038) >>>>> May 29 13:34:45 sjakie kernel: program counter = 0x00009F64 >>>>> May 29 13:34:45 sjakie kernel: source line = 0x000003C4 >>>>> May 29 13:34:45 sjakie kernel: error data = 0x0000000000000000 >>>>> May 29 13:34:45 sjakie kernel: branch link = 0x00009F6000009F60 >>>>> May 29 13:34:45 sjakie kernel: interrupt link = 0x0000DBEA00000000 >>>>> May 29 13:34:45 sjakie kernel: time = 54908 >>>>> May 29 13:34:45 sjakie kernel: driver status: >>>>> May 29 13:34:45 sjakie kernel: tx ring 0: qid=0 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 1: qid=1 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 2: qid=2 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 3: qid=3 cur=2 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 4: qid=4 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 5: qid=5 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 6: qid=6 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 7: qid=7 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 8: qid=8 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 9: qid=9 cur=81 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 10: qid=10 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 11: qid=11 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 12: qid=12 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 13: qid=13 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 14: qid=14 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 15: qid=15 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 16: qid=16 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 17: qid=17 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 18: qid=18 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 19: qid=19 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: rx ring: cur=39 >>>>> May 29 13:34:45 sjakie kernel: iwn0: iwn_panicked: controller panicked, >>>>> iv_state = 5; restarting >>>>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN >>>>> May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode >>>>> rev=0x12a80601 >>>>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP >>>>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN >>>>> May 29 13:34:45 sjakie kernel: iwn0: scan timeout >>>>> May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode >>>>> rev=0x12a80601 >>>>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP >>>>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN >>>>> May 29 13:34:45 sjakie kernel: iwn0: scan timeout >>>>> May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode >>>>> rev=0x12a80601 >>>>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP >>>>> May 29 13:34:45 sjakie kernel: iwn0: iwn_intr: fatal firmware error >>>>> May 29 13:34:45 sjakie kernel: firmware error log: >>>>> May 29 13:34:45 sjakie kernel: error type = "UNKNOWN" (0x00000038) >>>>> May 29 13:34:45 sjakie kernel: program counter = 0x00009F64 >>>>> May 29 13:34:45 sjakie kernel: source line = 0x000003C4 >>>>> May 29 13:34:45 sjakie kernel: error data = 0x0000000000000000 >>>>> May 29 13:34:45 sjakie kernel: branch link = 0x00009F6000009F60 >>>>> May 29 13:34:45 sjakie kernel: interrupt link = 0x0000DBEA00000000 >>>>> May 29 13:34:45 sjakie kernel: time = 7464 >>>>> May 29 13:34:45 sjakie kernel: driver status: >>>>> May 29 13:34:45 sjakie kernel: tx ring 0: qid=0 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 1: qid=1 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 2: qid=2 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 3: qid=3 cur=2 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 4: qid=4 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 5: qid=5 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 6: qid=6 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 7: qid=7 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 8: qid=8 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 9: qid=9 cur=81 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 10: qid=10 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 11: qid=11 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 12: qid=12 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 13: qid=13 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 14: qid=14 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 15: qid=15 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 16: qid=16 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 17: qid=17 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 18: qid=18 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 19: qid=19 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: rx ring: cur=63 >>>>> May 29 13:34:45 sjakie kernel: iwn0: iwn_panicked: controller panicked, >>>>> iv_state = 5; restarting >>>>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN >>>>> May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode >>>>> rev=0x12a80601 >>>>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP >>>>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN >>>>> May 29 13:34:45 sjakie kernel: iwn0: scan timeout >>>>> May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode >>>>> rev=0x12a80601 >>>>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP >>>>> May 29 13:34:45 sjakie kernel: iwn0: iwn_intr: fatal firmware error >>>>> May 29 13:34:45 sjakie kernel: firmware error log: >>>>> May 29 13:34:45 sjakie kernel: error type = "UNKNOWN" (0x00000038) >>>>> May 29 13:34:45 sjakie kernel: program counter = 0x00009F64 >>>>> May 29 13:34:45 sjakie kernel: source line = 0x000003C4 >>>>> May 29 13:34:45 sjakie kernel: error data = 0x0000000000000000 >>>>> May 29 13:34:45 sjakie kernel: branch link = 0x00009F6000009F60 >>>>> May 29 13:34:45 sjakie kernel: interrupt link = 0x0000DBEA00000000 >>>>> May 29 13:34:45 sjakie kernel: time = 69923 >>>>> May 29 13:34:45 sjakie kernel: driver status: >>>>> May 29 13:34:45 sjakie kernel: tx ring 0: qid=0 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 1: qid=1 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 2: qid=2 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 3: qid=3 cur=2 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 4: qid=4 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 5: qid=5 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 6: qid=6 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 7: qid=7 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 8: qid=8 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 9: qid=9 cur=81 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 10: qid=10 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 11: qid=11 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 12: qid=12 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 13: qid=13 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 14: qid=14 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 15: qid=15 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 16: qid=16 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 17: qid=17 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 18: qid=18 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: tx ring 19: qid=19 cur=0 queued=0 >>>>> May 29 13:34:45 sjakie kernel: rx ring: cur=61 >>>>> May 29 13:34:45 sjakie kernel: iwn0: iwn_panicked: controller panicked, >>>>> iv_state = 5; restarting >>>>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN >>>>> May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode >>>>> rev=0x12a80601 >>>>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP >>>>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to DOWN >>>>> May 29 13:34:45 sjakie kernel: iwn0: scan timeout >>>>> May 29 13:34:45 sjakie kernel: iwn0: iwn_read_firmware: ucode >>>>> rev=0x12a80601 >>>>> May 29 13:34:45 sjakie kernel: wlan0: link state changed to UP >>>>> _______________________________________________ >>>>> 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 May 31 00:40: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 54353B5354B for ; Tue, 31 May 2016 00:40:50 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-193.reflexion.net [208.70.211.193]) (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 199B71896 for ; Tue, 31 May 2016 00:40:49 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31334 invoked from network); 31 May 2016 00:41:13 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 31 May 2016 00:41:13 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Mon, 30 May 2016 20:40:47 -0400 (EDT) Received: (qmail 5876 invoked from network); 31 May 2016 00:40:47 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 31 May 2016 00:40:47 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 2522DB1E001; Mon, 30 May 2016 17:40:37 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: 11.0 -r300944 buildworld attempt failed [amd64 targeting powerpc or armv6 via system clang use] From: Mark Millard In-Reply-To: Date: Mon, 30 May 2016 17:40:41 -0700 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <137F75C8-F81A-44EE-B036-D7ABA7C75684@dsl-only.net> References: <8A197698-51C7-43F9-9927-465602E19AAE@dsl-only.net> To: FreeBSD Current , Bryan Drewery X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 00:40:50 -0000 [This adds armv6 information to a prior note that was just powerpc = based. The powerpc example material is listed first then it is noted = that armv6 ended up similar in my attempt.] On 2016-May-29, at 11:32 PM, Mark Millard = wrote: > [It may well be that powerpc is not an intended cross compile target = via clang since clang is insufficient for an FreeBSD/powerpc ABI = compliant buildworld as stands. Still I use this to illustrate the more = general points for clang use in cross builds.] >=20 > The failure: >=20 >> --- libc.so.7.full --- >> /usr/bin/ld: unrecognised emulation mode: elf32ppc_fbsd >> Supported emulations: elf_x86_64_fbsd elf_i386_fbsd >> clang: error: linker command failed with exit code 1 (use -v to see = invocation) >> *** [libc.so.7.full] Error code 1 >>=20 >> make[4]: stopped in /usr/src/lib/libc >> 1 error >>=20 >> make[4]: stopped in /usr/src/lib/libc >> *** [lib/libc__L] Error code 2 >=20 > Note the /usr/bin/ld use: the host (amd64) linker for a powerpc link = operation. >=20 > The log shows the ld command was via clang=E2=80=99s front end as far = as what the build did directly (just a prefix shown): >=20 >> --- libc.so.7.full --- >> /usr/bin/clang -target powerpc-unknown-freebsd11.0 = --sysroot=3D/usr/obj/clang/powerpc.powerpc/usr/src/tmp = -B/usr/obj/clang/powerpc.powerpc/usr/src/tmp/usr/bin -nodefaultlibs = -Wl,--version-script=3DVersion.map -shared -Wl,-x -Wl,--fatal-warnings = -Wl,--warn-shared-textrel -o libc.so.7.full -Wl,-soname,libc.so.7 = `NM=3D'nm' NMFLAGS=3D'' lorder trivial-vdso_tc.So bt_close.So bt_conv.So = bt_debug.So bt_delete.So bt_get.So bt_open.So bt_overflow.So bt_page.So > . . . >=20 > The -B does not point to a place with a powerpc specific ld command: >=20 >> # ls -lt /usr/obj/clang/powerpc.powerpc/usr/src/tmp/usr/bin >> total 1395 >> -rwxr-xr-x 1 root wheel 827248 May 29 22:20 ctfmerge >> -rwxr-xr-x 1 root wheel 534712 May 29 22:20 sysinit >> -rwxr-xr-x 1 root wheel 960784 May 29 22:20 ctfconvert >=20 > As far as I can tell a potentially proper path would have been: >=20 > /usr/local/powerpc-freebsd/bin/ld >=20 > if a devel/powerpc-binutils port existed and was installed. (No such = port exists.) >=20 > I do not know if other TARGET_ARCH=E2=80=99s have similar problems or = not (even if they have a binutils port). >=20 >=20 > This was not a WITH_META_MODE=3Dyes context. >=20 >=20 > make.conf was empty and src.conf was: >=20 > TO_TYPE=3Dpowerpc > # > KERNCONF=3DGENERICvtsc-NODEBUG > TARGET=3D${TO_TYPE} > .if ${.MAKE.LEVEL} =3D=3D 0 > TARGET_ARCH=3D${TO_TYPE} > .export TARGET_ARCH > .endif > # > WITHOUT_CROSS_COMPILER=3D > WITH_SYSTEM_COMPILER=3D > # > WITH_LIBCPLUSPLUS=3D > WITH_BINUTILS_BOOTSTRAP=3D > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_CLANG_EXTRAS=3D > # lldb requires missing atomic 8-byte operations for powerpc (non-64) > WITHOUT_LLDB=3D > # > WITH_BOOT=3D > WITHOUT_LIB32=3D > # > WITHOUT_GCC_BOOTSTRAP=3D > WITHOUT_GCC=3D > WITHOUT_GCC_IS_CC=3D > WITHOUT_GNUCXX=3D > # > NO_WERROR=3D > #WERROR=3D > MALLOC_PRODUCTION=3D > # > WITH_DEBUG_FILES=3D >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net I finally tried a amd64 host -> armv6 (rpi2) cross build for freebsd = 11.0. amd64 -> armv6 for freebsd 11.0 also ended up with linker vs. file = format/content mismatches: in this case what was reported was about the = crti.o format when attempting to link libc.so.7.full . The error = messages were not explicit about the linker path used, unfortunately. = .../tmp/usr/bin as listed in the -B had only the same 3 file names (and = no ld) as was shown above for the powerpc context. Again it is a context of using the clang front end to indirectly get to = the linker with "-target" needing to guide details if the selection of = the linker is to be automatic. (Otherwise -B likely needs to point to = where an appropriate tool set is to be found [including ld].) armv6 for freebsd 11.0 is likely intended to be supported, unlike = powerpc possibly being viewed as irrelevant currently because of clang's = code generation issues for powerpc variants. armv6-gnueabihf-freebsd11.0 for modern hardfloat vs. = armv6-gnueabi-freebsd11.0 for temporary softfloat may need distinct = linkers (or other tools)? (Possibly via distinct -B's?) I'm not sure if the following additional item is a potential issue or = not: While there is a devel/arm-gnueabi-binutils there is no = devel/arm-gnueabihf-binutils. But I notice that -target = armv6-gnueabihf-freebsd11.0 is in use now for freebsd 11.0. Targets of = the form armv6-gnueabi-freebsd10* are probably still needed to support = 10.x for rpi's and the like. (So is another port needed?) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Tue May 31 02:21: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 43E45B55954 for ; Tue, 31 May 2016 02:21:02 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-191.reflexion.net [208.70.211.191]) (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 06EF41F43 for ; Tue, 31 May 2016 02:21:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 16305 invoked from network); 31 May 2016 02:21:28 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 31 May 2016 02:21:28 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Mon, 30 May 2016 22:21:00 -0400 (EDT) Received: (qmail 8883 invoked from network); 31 May 2016 02:21:00 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 31 May 2016 02:21:00 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 644F5B1E001; Mon, 30 May 2016 19:20:49 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: 11.0 -r300944 buildworld amd64 -> armv6/armv7a cross build: Some XCPP and XCC use without -target specified so it rejects -march=armv7a From: Mark Millard Date: Mon, 30 May 2016 19:20:54 -0700 Cc: FreeBSD Toolchain , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <80DF38BA-CC08-4E58-9B19-CFBE72CF7262@dsl-only.net> To: Bryan Drewery , FreeBSD Current X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 02:21:02 -0000 [Warning: The following report is already based on trying to work around = prior problems already noted elsewhere. That makes these somewhat more = suspect. The -march=3Darmv7a that is rejected below is from = XCC/XCXX/XCPP content in my src.conf. I later list the src.conf content = used.] [WITH_META_MODE=3Dyes is in use. cleanworld had been done before hand.] Example failure: > # more = /usr/obj/clang/arm.armv6/usr/src/worldsoft/usr/src/include/rpcsvc/key_prot= .h.meta > # Meta data file = /usr/obj/clang/arm.armv6/usr/src/worldsoft/usr/src/include/rpcsvc/key_prot= .h.meta > CMD RPCGEN_CPP=3D/usr/bin/clang-cpp\ -march=3Darmv7a\ -mcpu=3Dcortex-a7\= -B/usr/local/arm-gnueabi-freebsd/bin\ -DCOMPAT_SOFTFP\ = -mfloat-abi=3Dsoftfp\ \ = -L/usr/obj/clang/arm.armv6/usr/src/libsoft/usr/libsoft\ \ = --sysroot=3D/usr/obj/clang/arm.armv6/usr/src/libsoft\ \ = -B/usr/obj/clang/arm.armv6/usr/src/tmp/usr/bin\ = -B/usr/obj/clang/arm.armv6/usr/src/libsoft/usr/libsoft rpcgen -C -h = -DWANT_NFS3 /usr/src/include/rpcsvc/key_prot.x -o key_prot.h > CWD /usr/obj/clang/arm.armv6/usr/src/worldsoft/usr/src/include/rpcsvc > TARGET key_prot.h > -- command output -- > clang-cpp: warning: argument unused during compilation: = '-mcpu=3Dcortex-a7' > clang-cpp: warning: argument unused during compilation: = '-mfloat-abi=3Dsoftfp' > clang-cpp: warning: argument unused during compilation: = '-L/usr/obj/clang/arm.armv6/usr/src/libsoft/usr/libsoft' > error: unknown target CPU 'armv7a' > *** Error code 1 . . . rpcb_prot.h was similar. These appear to be because -target armv6-???-freebsd11.0 was not = supplied to clang-cpp (given that -march=3Darmv7a was supplied to = clang-cpp via src.conf material but armv7a is not a variation of the = host (amd64) context). (I try to be sure that clang-cpp is always told the specific -march that = I=E2=80=99m targeting in case clang-cpp provides macro definitions on = that basis that might be used.) Adding a -target in XCPP and retrying got farther but failed for XCC not = getting a -target and so another rejection of -march=3Darmv7a happened: > # more = /usr/obj/clang/arm.armv6/usr/src/worldsoft/usr/src/gnu/lib/libssp/libssp_n= onshared/ssp-local.o* > # Meta data file = /usr/obj/clang/arm.armv6/usr/src/worldsoft/usr/src/gnu/lib/libssp/libssp_n= onshared/ssp-local.o.meta > CMD /usr/bin/clang -march=3Darmv7a -mcpu=3Dcortex-a7 = -B/usr/local/arm-gnueabi-freebsd/bin -DCOMPAT_SOFTFP -mfloat-abi=3Dsoftfp = -L/usr/obj/clang/arm.armv6/usr/src/libsoft/usr/libsoft = --sysroot=3D/usr/obj/clang/arm.armv6/usr/src/libsoft = -B/usr/obj/clang/arm.armv6/usr/src/tmp/usr/bin = -B/usr/obj/clang/arm.armv6/usr/src/libsoft/usr/libsoft -O -pipe = -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libssp/libssp_nonshared/.. = -I/usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/lib= ssp = -I/usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/inc= lude -fPIC -DPIC -fvisibility=3Dhidden -mfloat-abi=3Dsoftfp -std=3Dgnu99 = -Qunused-arguments -c = /usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libss= p/ssp-local.c -o ssp-local.o > CMD=20 > CWD = /usr/obj/clang/arm.armv6/usr/src/worldsoft/usr/src/gnu/lib/libssp/libssp_n= onshared > TARGET ssp-local.o > -- command output -- > error: unknown target CPU 'armv7a' > *** Error code 1 . . . Some of the other clang command line arguments (-mcpu and -B) are also = from my src.conf file. More is missing for a normal compile than just = -target material. [Note that having even just a "redundant" -march=3Darmv6 in = XCC/XCXX/XCPP is a good testing technique for proving that all the usage = has sufficient context to allow such an explicit specification from the = right family.] Supporting details. . . make.conf empty. src.conf (before forcing XCPP to have an armv6 family -target): TO_TYPE=3Darmv6 TOOLS_TO_TYPE=3Darm-gnueabi # KERNCONF=3DRPI2-NODBG TARGET=3Darm .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITHOUT_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # #CPUTYPE=3Dsoft WITH_LIBSOFT=3D WITH_LIBCPLUSPLUS=3D WITHOUT_BINUTILS_BOOTSTRAP=3D WITHOUT_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D # WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_DEBUG_FILES=3D # # # To based on clang (via system)... # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils... # .if ${.MAKE.LEVEL} =3D=3D 0 XCC=3D/usr/bin/clang -march=3Darmv7a -mcpu=3Dcortex-a7 = -B/usr/local/${TOOLS_TO_TYPE}-freebsd/bin XCXX=3D/usr/bin/clang++ -march=3Darmv7a -mcpu=3Dcortex-a7 = -B/usr/local/${TOOLS_TO_TYPE}-freebsd/bin XCPP=3D/usr/bin/clang-cpp -march=3Darmv7a -mcpu=3Dcortex-a7 = -B/usr/local/${TOOLS_TO_TYPE}-freebsd/bin .export XCC .export XCXX .export XCPP XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size #NO-SUCH: XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings XSTRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings .export XAS .export XAR .export XLD .export XNM .export XOBJCOPY .export XOBJDUMP .export XRANLIB .export XSIZE .export XSTRINGS .endif # # # =46rom based on clang (via system)... # #COMPILER_TYPE=3Dclang .if ${.MAKE.LEVEL} =3D=3D 0 CC=3D/usr/bin/clang CXX=3D/usr/bin/clang++ CPP=3D/usr/bin/clang-cpp .export CC .export CXX .export CPP .endif =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Mon May 30 14:43: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 99221B54738 for ; Mon, 30 May 2016 14:43:01 +0000 (UTC) (envelope-from pi@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 627F814A1 for ; Mon, 30 May 2016 14:43:01 +0000 (UTC) (envelope-from pi@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.87 (FreeBSD)) (envelope-from ) id 1b7OPE-000515-Rq; Mon, 30 May 2016 16:43:00 +0200 Date: Mon, 30 May 2016 16:43:00 +0200 From: Kurt Jaeger To: Matthias Apitz , freebsd-current@freebsd.org Subject: Re: r300951 make buildworld duration 18h Message-ID: <20160530144300.GW41922@home.opsec.eu> References: <20160530143726.GA2418@c720-r292778-amd64.oa.oclc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160530143726.GA2418@c720-r292778-amd64.oa.oclc.org> X-Mailman-Approved-At: Tue, 31 May 2016 04:01:23 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 14:43:01 -0000 Hi! > Yesterday I pulled via svn co ... a fresh r300951 and started the > buildworld as > > # make -j2 buildworld > > it ended today at lunchtime after 18 hours. The laptop has > 2x Intel Atom 1.6GHz and 1 GByte RAM and was otherwise unused. > Is this the normal buildworld time of today? Yes, this sounds in line with similar setups. > I think it spent most of the time in building the llvm... Yes, llvm is a real hog. That's why I normally build on amd64 boxes... -- pi@opsec.eu +49 171 3101372 4 years to go ! From owner-freebsd-current@freebsd.org Tue May 31 04: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 34DD1B55E1B for ; Tue, 31 May 2016 04:20:02 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-185.reflexion.net [208.70.211.185]) (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 E6EFC19CF for ; Tue, 31 May 2016 04:20:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 12428 invoked from network); 31 May 2016 04:20:26 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 31 May 2016 04:20:26 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Tue, 31 May 2016 00:20:00 -0400 (EDT) Received: (qmail 8665 invoked from network); 31 May 2016 04:20:00 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 31 May 2016 04:20:00 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id E3745B1E001; Mon, 30 May 2016 21:19:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: 11.0 -r300944 buildworld attempt failed [amd64 targeting powerpc or armv6 via system clang use] From: Mark Millard In-Reply-To: <137F75C8-F81A-44EE-B036-D7ABA7C75684@dsl-only.net> Date: Mon, 30 May 2016 21:19:54 -0700 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <311011FA-F5B0-499D-AE47-31D430257A8A@dsl-only.net> References: <8A197698-51C7-43F9-9927-465602E19AAE@dsl-only.net> <137F75C8-F81A-44EE-B036-D7ABA7C75684@dsl-only.net> To: FreeBSD Current , Bryan Drewery X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 04:20:02 -0000 On 2016-May-30, at 5:40 PM, Mark Millard wrote: > [This adds armv6 information to a prior note that was just powerpc = based. The powerpc example material is listed first then it is noted = that armv6 ended up similar in my attempt.] >=20 > On 2016-May-29, at 11:32 PM, Mark Millard = wrote: >=20 >> [It may well be that powerpc is not an intended cross compile target = via clang since clang is insufficient for an FreeBSD/powerpc ABI = compliant buildworld as stands. Still I use this to illustrate the more = general points for clang use in cross builds.] >>=20 >> The failure: >>=20 >>> --- libc.so.7.full --- >>> /usr/bin/ld: unrecognised emulation mode: elf32ppc_fbsd >>> Supported emulations: elf_x86_64_fbsd elf_i386_fbsd >>> clang: error: linker command failed with exit code 1 (use -v to see = invocation) >>> *** [libc.so.7.full] Error code 1 >>>=20 >>> make[4]: stopped in /usr/src/lib/libc >>> 1 error >>>=20 >>> make[4]: stopped in /usr/src/lib/libc >>> *** [lib/libc__L] Error code 2 >>=20 >> Note the /usr/bin/ld use: the host (amd64) linker for a powerpc link = operation. >>=20 >> The log shows the ld command was via clang=E2=80=99s front end as far = as what the build did directly (just a prefix shown): >>=20 >>> --- libc.so.7.full --- >>> /usr/bin/clang -target powerpc-unknown-freebsd11.0 = --sysroot=3D/usr/obj/clang/powerpc.powerpc/usr/src/tmp = -B/usr/obj/clang/powerpc.powerpc/usr/src/tmp/usr/bin -nodefaultlibs = -Wl,--version-script=3DVersion.map -shared -Wl,-x -Wl,--fatal-warnings = -Wl,--warn-shared-textrel -o libc.so.7.full -Wl,-soname,libc.so.7 = `NM=3D'nm' NMFLAGS=3D'' lorder trivial-vdso_tc.So bt_close.So bt_conv.So = bt_debug.So bt_delete.So bt_get.So bt_open.So bt_overflow.So bt_page.So >> . . . >>=20 >> The -B does not point to a place with a powerpc specific ld command: >>=20 >>> # ls -lt /usr/obj/clang/powerpc.powerpc/usr/src/tmp/usr/bin >>> total 1395 >>> -rwxr-xr-x 1 root wheel 827248 May 29 22:20 ctfmerge >>> -rwxr-xr-x 1 root wheel 534712 May 29 22:20 sysinit >>> -rwxr-xr-x 1 root wheel 960784 May 29 22:20 ctfconvert >>=20 >> As far as I can tell a potentially proper path would have been: >>=20 >> /usr/local/powerpc-freebsd/bin/ld >>=20 >> if a devel/powerpc-binutils port existed and was installed. (No such = port exists.) >>=20 >> I do not know if other TARGET_ARCH=E2=80=99s have similar problems or = not (even if they have a binutils port). >>=20 >>=20 >> This was not a WITH_META_MODE=3Dyes context. >>=20 >>=20 >> make.conf was empty and src.conf was: >>=20 >> TO_TYPE=3Dpowerpc >> # >> KERNCONF=3DGENERICvtsc-NODEBUG >> TARGET=3D${TO_TYPE} >> .if ${.MAKE.LEVEL} =3D=3D 0 >> TARGET_ARCH=3D${TO_TYPE} >> .export TARGET_ARCH >> .endif >> # >> WITHOUT_CROSS_COMPILER=3D >> WITH_SYSTEM_COMPILER=3D >> # >> WITH_LIBCPLUSPLUS=3D >> WITH_BINUTILS_BOOTSTRAP=3D >> WITH_CLANG=3D >> WITH_CLANG_IS_CC=3D >> WITH_CLANG_FULL=3D >> WITH_CLANG_EXTRAS=3D >> # lldb requires missing atomic 8-byte operations for powerpc (non-64) >> WITHOUT_LLDB=3D >> # >> WITH_BOOT=3D >> WITHOUT_LIB32=3D >> # >> WITHOUT_GCC_BOOTSTRAP=3D >> WITHOUT_GCC=3D >> WITHOUT_GCC_IS_CC=3D >> WITHOUT_GNUCXX=3D >> # >> NO_WERROR=3D >> #WERROR=3D >> MALLOC_PRODUCTION=3D >> # >> WITH_DEBUG_FILES=3D >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >=20 > I finally tried a amd64 host -> armv6 (rpi2) cross build for freebsd = 11.0. >=20 > amd64 -> armv6 for freebsd 11.0 also ended up with linker vs. file = format/content mismatches: in this case what was reported was about the = crti.o format when attempting to link libc.so.7.full . The error = messages were not explicit about the linker path used, unfortunately. = .../tmp/usr/bin as listed in the -B had only the same 3 file names (and = no ld) as was shown above for the powerpc context. >=20 > Again it is a context of using the clang front end to indirectly get = to the linker with "-target" needing to guide details if the selection = of the linker is to be automatic. (Otherwise -B likely needs to point to = where an appropriate tool set is to be found [including ld].) >=20 > armv6 for freebsd 11.0 is likely intended to be supported, unlike = powerpc possibly being viewed as irrelevant currently because of clang's = code generation issues for powerpc variants. >=20 > armv6-gnueabihf-freebsd11.0 for modern hardfloat vs. = armv6-gnueabi-freebsd11.0 for temporary softfloat may need distinct = linkers (or other tools)? (Possibly via distinct -B's?) >=20 >=20 > I'm not sure if the following additional item is a potential issue or = not: >=20 > While there is a devel/arm-gnueabi-binutils there is no = devel/arm-gnueabihf-binutils. But I notice that -target = armv6-gnueabihf-freebsd11.0 is in use now for freebsd 11.0. Targets of = the form armv6-gnueabi-freebsd10* are probably still needed to support = 10.x for rpi's and the like. (So is another port needed?) >=20 >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net I looked around some more and I think I've found one or two points = missed in some of the WITH_SYSTEM_COMPILER coverage. Such may explain = part of the above. A) The bootstrap clang compiler is built to automatically use the = WITH_BINUTILS_BOOTSTRAP instances of the binutils if I understand right. B) The system clang compiler is not. So, for example, it by default uses = /usr/bin/ld as the linker. C) =46rom what I've seen WITH_SYSTEM_COMPILER for cross-builds is not = building the WITH_BINUTILS_BOOTSTRAP binutils (and so is not putting the = them in a place that it would use via -B, which might then manage to = redirect the system clang to find those WITH_BINUTILS_BOOTSTRAP = binutils). D) This may get odder when hardfloat vs. libsoft is considered: what = tools need to be different tool instances for building libsoft? Are the = armv6-gnueabihf-freebsd11.0 related tools sufficient to cover = armv6-gnueabi-freebsd11.0 (libsoft's softfloat) without switching to any = other tool(s)? Side note: There is also another difference [this just mentions some material from = another, later report that I made on the lists]: E) The bootstrap clang compilers/cpp does not need -target and allows = selection of -march from the target family and tracks when such is done. = But there are contexts that still assume this status when = WITH_SYSTEM_COMPILER is in use but the system compiler does not have = this property for cross-build usage. The examples that I've noticed are = tied to building libsoft. An appropriate -target is always needed, = potentially even for clang-cpp to have the fully correct behavior. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Tue May 31 04:31: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 54BA6B550D2 for ; Tue, 31 May 2016 04:31:51 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48BE71F21 for ; Tue, 31 May 2016 04:31:50 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1464669100339478.16268605313167; Mon, 30 May 2016 21:31:40 -0700 (PDT) Date: Mon, 30 May 2016 21:31:40 -0700 From: Matthew Macy To: "Matthias Apitz" Cc: "" Message-ID: <1550514d8fe.cc2d189b33647.6378517539401453661@nextbsd.org> In-Reply-To: <20160530143726.GA2418@c720-r292778-amd64.oa.oclc.org> References: <20160530143726.GA2418@c720-r292778-amd64.oa.oclc.org> Subject: Re: r300951 make buildworld duration 18h MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 04:31:51 -0000 ---- On Mon, 30 May 2016 07:37:26 -0700 Matthias Apitz wrote ---- > > Hello, > > Yesterday I pulled via svn co ... a fresh r300951 and started the buildworld as > > # make -j2 buildworld > > it ended today at lunchtime after 18 hours. The laptop has 2x Intel Atom 1.6GHz > and 1 GByte RAM and was otherwise unused. Is this the normal buildworld time of > today? I think it spent most of the time in building the llvm... > I never build on any of my laptops. I have a 8-thread VM running FreeBSD on a new-ish 6-core Broadwell. It builds world in 35-45 minutes and a new kernel in ~3-5 minutes. I mount it over NFS and install to the laptops when I want to update. Obviously if you only have this Atom based machine then that's not a luxury you have. If that's the case I'd install llvm/clang from ports and skip both clangs from the build. I'd guess it's probably 70+% of the buildworld time on my system and possibly > 80% on yours due to the large C++ memory usage. -M From owner-freebsd-current@freebsd.org Tue May 31 04:47: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 6B1C3B553EE for ; Tue, 31 May 2016 04:47:17 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id 5EE0D1B1B for ; Tue, 31 May 2016 04:47:17 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from AlfredMacbookAir.local (unknown [IPv6:2601:645:8003:a4d6:5954:49d3:33ad:d196]) by elvis.mu.org (Postfix) with ESMTPSA id ACB8B346DE89 for ; Mon, 30 May 2016 21:47:11 -0700 (PDT) Subject: Re: r300951 make buildworld duration 18h To: freebsd-current@freebsd.org References: <20160530143726.GA2418@c720-r292778-amd64.oa.oclc.org> <20160530144300.GW41922@home.opsec.eu> From: Alfred Perlstein Organization: FreeBSD Message-ID: <574D174F.9030907@freebsd.org> Date: Mon, 30 May 2016 21:47:11 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160530144300.GW41922@home.opsec.eu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 04:47:17 -0000 It's too bad make(1) can't have a "max parallel jobs" for a particular directory. I believe that some of the llvm build winds up using nearly a gig of RAM per compiled .c file, so when you are running 2 jobs at once, LLVM will swap like mad. If we could add something under the llvm directory "max jobs = RAM/1GB" we could have much faster build worlds. -Alfred On 5/30/16 7:43 AM, Kurt Jaeger wrote: > Hi! > >> Yesterday I pulled via svn co ... a fresh r300951 and started the >> buildworld as >> >> # make -j2 buildworld >> >> it ended today at lunchtime after 18 hours. The laptop has >> 2x Intel Atom 1.6GHz and 1 GByte RAM and was otherwise unused. >> Is this the normal buildworld time of today? > Yes, this sounds in line with similar setups. > >> I think it spent most of the time in building the llvm... > Yes, llvm is a real hog. > > That's why I normally build on amd64 boxes... > From owner-freebsd-current@freebsd.org Tue May 31 07:20:31 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8240CB5528F for ; Tue, 31 May 2016 07:20:31 +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 2FB441A27 for ; Tue, 31 May 2016 07:20:30 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-225-151.lns20.per1.internode.on.net [121.45.225.151]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u4V7KPGs033143 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 31 May 2016 00:20:28 -0700 (PDT) (envelope-from julian@freebsd.org) To: freebsd-current From: Julian Elischer Subject: question on packaging base. Message-ID: Date: Tue, 31 May 2016 15:20:20 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 07:20:31 -0000 Given the work going on for incremental builds, together with the work in packaging the base, is it planned that we will be able to rebuild jut one package at a time? For example will be be able to rebuild just he openssl-base (or whatever it is called) package without recompiling everything else, even if we have not previously recompiled everything else? From owner-freebsd-current@freebsd.org Mon May 30 19:51: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 9F718B559DF for ; Mon, 30 May 2016 19:51:18 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 85E6C1BA5; Mon, 30 May 2016 19:51:18 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id u4UJpHew094127 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 30 May 2016 12:51:17 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id u4UJpHg9094126; Mon, 30 May 2016 12:51:17 -0700 (PDT) (envelope-from sgk) Date: Mon, 30 May 2016 12:51:16 -0700 From: Steve Kargl To: Dimitry Andric Cc: freebsd-current@freebsd.org Subject: Re: Recent seems to have broken toolchain Message-ID: <20160530195116.GA93546@troutmask.apl.washington.edu> References: <20160529022702.GA57282@troutmask.apl.washington.edu> <1EF864CF-12E8-4A48-B6E9-317D438B7B7C@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1EF864CF-12E8-4A48-B6E9-317D438B7B7C@FreeBSD.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Mailman-Approved-At: Tue, 31 May 2016 10:57:34 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 19:51:18 -0000 On Mon, May 30, 2016 at 09:29:40PM +0200, Dimitry Andric wrote: > On 29 May 2016, at 04:27, Steve Kargl wrote: > > > > I have a Fortran application that has built forever on FreeBSD-current; > > that is, until recently. It now dies with the following error: > > > > gfortran48 -O2 -pipe -march=native -mtune=native -static -funroll-loops \ > > --param max-unroll-times=4 -ftree-vectorize -Wall\ > > -rpath /usr/local/lib/gcc48 -I/home/kargl/modules -o acolor acolor.f90 \ > > globalm.o saxm.o -L/home/kargl/lib -L. -L/usr/local/lib -L. -ltgt -loa \ > > -L/home/kargl/lib -L. -L/usr/local/lib -lm90 -llapack -lblas > > ./liboa.a(pointm.o): In function `__pointm_MOD_l2norm2': > > pointm.f90:(.text+0x490): multiple definition of `__pointm_MOD_l2norm2' > > /home/kargl/lib/libtgt.a(pointm.o):pointm.f90:(.text+0x0): first defined here > > > > Yes, pointm.o is in both libtgt.a and liboa.a. In the past, during > > linking, the symbols are resolved from the first of -ltgt or -loa > > depending on the order on the command line. > > If you run the above command line with -v, what linker does it use? I > suspect this may be something caused by a newer binutils port, or even > by a newer gfortran. > > If this is using /usr/local/bin/ld, you might want to try downgrading > your binutils. > It happens with both /usr/bin/ld and /usr/local/bin/ld. I remove the binutils port and still had the issue. I tried reverting recent changes to elftoolchain/libelftc, the resulting tree would not build. For the record, % /usr/bin/ld -v GNU ld 2.17.50 % /usr/local/bin/ld -v GNU ld (GNU Binutils) 2.25.1 I forgot to note that the problem does not occur for amd64 FreeBSD at r299122. Unfortunately, I won't have time until the end of the week to try to bisect the src tree (which is going to be a monumental pain with keeping everything in sync). As a workaround, I have added -Wl,--allow-multiple-definition to the compiler options for gfortran48. -- Steve From owner-freebsd-current@freebsd.org Tue May 31 14:26: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 14558B54F7F for ; Tue, 31 May 2016 14:26:15 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 D38B218A6; Tue, 31 May 2016 14:26:14 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io0-x233.google.com with SMTP id p64so94278169ioi.2; Tue, 31 May 2016 07:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Sa1BCyNHh+vctcq5pVx4QcPPXq+T4+868ESPImbHzAg=; b=j4Npkm8m1d0kYl0kw+/2uZKEEBfQKAQdHEjFJBbc8innETEGL/HnfGwaLjok1zTNsN 0LdkA82qV7t0MIXtVGmls2cb1F/+uFsZ7rFBlTorDiNlCPcguowJPB1a13/U3zaWX+rY wQPmP6/buXQ54CH0+2r2FhO4D31s2TR8Jaz3MyrjLm6bJLVWfC0yA6doBD2wLuSdaoa9 Wi61J+T2V4XavlYOn2yWqemS0CEK9YRSpkeeuMhMth51dYhLl2sgbIB2qHhEvRIKZ1cU uNkTt0VRKx0bBxHheY16jbahrgmHxd334nITVcbTTPm5JGvRPtWuXIRZTRAPagO+XVWU NYaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Sa1BCyNHh+vctcq5pVx4QcPPXq+T4+868ESPImbHzAg=; b=BIro9sBxHhmBbKgYjC+pPCFtTqXcNfv1Cfint4+EoVVuTyhyzZNbqpkfmuTCWXiz3d AhtERBuM2H4biw77kuYVMjhZHnc6cf+4Js0II/IWguc/B+VbT6GgnnSZU6wmfMwWwyD4 IebZH+UkPikOJaVs+R6k4Nf2HKaVThnmY5F1h22Ms2rcx8Zy4APwgzO3BlQZek62aUJA S4qtcF4g9y2hcGtdB++hZpl6fUvz9+2wvFzAZoGOmKtSg8fK9vB0zXAJ0wgx0bLVz74x U58sOiGBRnf+jAZvoF68t0LP1+k9MIBGhcijOdah7vnTFCd++n/L+d5qFN1VnmVxZGKj ms8w== X-Gm-Message-State: ALyK8tLueGDRZlqaUr4liDjcSP9pKNThIjA0eybidIlEFMcrPTjAtKVdLE+5bl7bASKbjJoZivdUThs318geaw== X-Received: by 10.107.159.84 with SMTP id i81mr26346539ioe.29.1464704774148; Tue, 31 May 2016 07:26:14 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.27.197 with HTTP; Tue, 31 May 2016 07:25:54 -0700 (PDT) In-Reply-To: <20160530195116.GA93546@troutmask.apl.washington.edu> References: <20160529022702.GA57282@troutmask.apl.washington.edu> <1EF864CF-12E8-4A48-B6E9-317D438B7B7C@FreeBSD.org> <20160530195116.GA93546@troutmask.apl.washington.edu> From: Ed Maste Date: Tue, 31 May 2016 10:25:54 -0400 X-Google-Sender-Auth: VIcTsDPSbB001Vk_mybhC9HTCEY Message-ID: Subject: Re: Recent seems to have broken toolchain To: Steve Kargl Cc: Dimitry Andric , FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 14:26:15 -0000 On 30 May 2016 at 15:51, Steve Kargl wrote: > > It happens with both /usr/bin/ld and /usr/local/bin/ld. I remove the > binutils port and still had the issue. I tried reverting recent changes > to elftoolchain/libelftc, the resulting tree would not build. The elftoolchain changes are a good candidate to check, although they should have no impact at all on the linker. What error did you encounter when trying to build with them reverted? From owner-freebsd-current@freebsd.org Tue May 31 14:30: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 E60B6B55110 for ; Tue, 31 May 2016 14:30:51 +0000 (UTC) (envelope-from oleglelchuk@gmail.com) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 89EAD1B9C for ; Tue, 31 May 2016 14:30:51 +0000 (UTC) (envelope-from oleglelchuk@gmail.com) Received: by mail-wm0-x229.google.com with SMTP id z87so110638493wmh.0 for ; Tue, 31 May 2016 07:30:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=WzttgKsGfkt9SKDYcqHiPo0OGSl0IcPW/GA1hOJcQIw=; b=Ks2GBZwBv1+uWA1eIl/5G9b9V1ARWCKby8KjT2lBXPsOkm2NujO8lgrPyI6Kx0nAqZ SFEVe3C1KTYCWsBF+hdgNOaMbZRWNGTLV5xwZrjX2Ut3BZFMawXrsiaWTLYoozxp/Nqf Qg4dZ5MBsv2YEdN0dZAOjJnGlnp5W/cV07gwHswxdymngxLqm2SM3swZ8AyV2QscC5mS xa74LlEcTx1G/6qvMboqFCBs8WfFYlUCzXQbPCGbZGbaljt/WREDEpzoeCsXq6V5dIi0 jGuSDe64Ix3Yx7kqvsiUxkyVyvXlGN6Hocnv14+7GUUTbfYiuDX4MLnXLqfzKGsRCwU3 we+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=WzttgKsGfkt9SKDYcqHiPo0OGSl0IcPW/GA1hOJcQIw=; b=EXfugxaGYfAJgEBb0s4LVhRiq4pT/UWtVCT1gEz626zyOpDYtFeArUUMgkwPclIK9O 0iakG4lK2Vb+ZWM7v5h+leINsH56p0GPXQvZw+ORLTlC9KTwOKeePXicKh010+j1c4XI bgsZRwrXTrfxMbmE0Nf2RR8SXH3DEkMuWqurVnXUG5/wS4kZHuw5nYn4CgqC/W8wBAd/ 3sIWaxZ7rDhT9+G0/NEbHHT5mGgX8kaeSj7V/sjwTLQ1pZUl8V8WAFwIPfq2Xv16LMk/ sTx+H5z0ExIjx6uvmOYht3ayc84+WLlAqkSbFUdQnZ+Tt/1U+/wV87rw56NX4SNjPXc8 elBA== X-Gm-Message-State: ALyK8tLl1UvPUNZKL7m/Owv92scrOUA8eJIec/P1o3KXT/kiQRt34/r/QUd4OoUMOJ0itux4DWqojONA17BHUQ== MIME-Version: 1.0 X-Received: by 10.194.146.180 with SMTP id td20mr25340923wjb.86.1464705050090; Tue, 31 May 2016 07:30:50 -0700 (PDT) Received: by 10.194.174.230 with HTTP; Tue, 31 May 2016 07:30:50 -0700 (PDT) Date: Tue, 31 May 2016 10:30:50 -0400 Message-ID: Subject: Compiling vlc-qt4 gives me an error From: Oleg Lelchuk To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 14:30:52 -0000 Hi. When I attempt to build /usr/ports/multimedia/vlc-qt4 , I get the following error: In file included from /usr/include/c++/v1/memory:616: /usr/include/c++/v1/atomic:823:1: error: expected unqualified-id kill_dependency(_Tp __y) _NOEXCEPT ^ ../include/vlc_atomic.h:45:7: note: expanded from macro 'kill_dependency' ((void)0) ^ This error occurs on 11-ALPHA1 r300997M. From owner-freebsd-current@freebsd.org Tue May 31 14:40: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 C5BFBB55542 for ; Tue, 31 May 2016 14:40:38 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7645912D5 for ; Tue, 31 May 2016 14:40:38 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.87 (FreeBSD)) (envelope-from ) id 1b7kqV-0007Lv-W5; Tue, 31 May 2016 16:40:39 +0200 Date: Tue, 31 May 2016 16:40:39 +0200 From: Kurt Jaeger To: Oleg Lelchuk Cc: freebsd-current@freebsd.org Subject: Re: Compiling vlc-qt4 gives me an error Message-ID: <20160531144039.GY41922@home.opsec.eu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 14:40:39 -0000 Hi! > Hi. When I attempt to build /usr/ports/multimedia/vlc-qt4 , I get the > following error: > > In file included from /usr/include/c++/v1/memory:616: > /usr/include/c++/v1/atomic:823:1: error: expected unqualified-id > kill_dependency(_Tp __y) _NOEXCEPT > ^ > ../include/vlc_atomic.h:45:7: note: expanded from macro 'kill_dependency' > ((void)0) > ^ > This error occurs on 11-ALPHA1 r300997M. Have you seen https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209722 -- pi@opsec.eu +49 171 3101372 4 years to go ! From owner-freebsd-current@freebsd.org Tue May 31 15:57: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 017E2B563AF; Tue, 31 May 2016 15:57:24 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id E58E514DF; Tue, 31 May 2016 15:57:23 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id DC75D1ABA; Tue, 31 May 2016 15:57:23 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 5ADE41E9F7; Tue, 31 May 2016 15:57:23 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id hfek-rEoldbq; Tue, 31 May 2016 15:57:15 +0000 (UTC) Subject: Re: [CFT] WITH_META_MODE: Working incremental build [only on i386 and amd64] DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com D52881E9ED To: Mark Millard , FreeBSD Current References: Cc: FreeBSD PowerPC ML , freebsd-arm From: Bryan Drewery Organization: FreeBSD Message-ID: <8835f09a-4e52-5bd0-ba8e-763eb6a92db7@FreeBSD.org> Date: Tue, 31 May 2016 08:57:10 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 15:57:24 -0000 On 5/29/16 3:53 PM, Mark Millard wrote: > Quoting the original note about WITH_META_MODE ( https://lists.freebsd.org/pipermail/freebsd-current/2016-May/061481.html ): > >> You will also need to load the filemon(4) module with 'kldload filemon'. > > But head's sys/modules/Makefile says: > >> .if defined(MODULES_OVERRIDE) && !defined(ALL_MODULES) >> SUBDIR=${MODULES_OVERRIDE} >> .else >> SUBDIR= \ > > . . . >> ${_filemon} \ > > . . . >> .if ${MACHINE_CPUARCH} == "i386" || ${MACHINE_CPUARCH} == "amd64" > . . . >> _filemon= filemon > . . . > > as the only contexts that provide a filemon.ko to use with kldload. > > Thus, for example, arm variants (32 bit and 64 bit) and powerpc variants (32bit and 64 bit) do not have WITH_META_MODE as an option as things are set up. > > I had been hoping to cut down on the time for clang-related rebuilds during native buildworld runs on my slower buildworld contexts (armv7a/cortex-a7, powerpc, powerpc64). But it was not to be. > > It appears that, once some arm variants are officially tier 1, WITH_META_MODE will not span all tier 1 platforms. > > [Since I tend to use non-tier-1 platforms I tend to notice some of the statements about FreeBSD that are true of only tier 1 without being explicit about it. But initially it takes some research to discover that status for each such point. WITH_META_MODE is an example.] > Ah, I wasn't aware of the restriction. I am testing building it for other archs now. Most of the arch-dependent code has been removed since the restriction was added. -- Regards, Bryan Drewery From owner-freebsd-current@freebsd.org Tue May 31 16: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 2DF82B56BFE for ; Tue, 31 May 2016 16:21:17 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (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 E54DF1C4E; Tue, 31 May 2016 16:21:16 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::3cbe:aea7:5de8:a7e7] (unknown [IPv6:2001:7b8:3a7:0:3cbe:aea7:5de8:a7e7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 6138839D47; Tue, 31 May 2016 18:21:13 +0200 (CEST) Subject: Re: Recent seems to have broken toolchain Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_273B5466-BDC6-42C6-8289-EECADF00296E"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 (ebbf3ef) From: Dimitry Andric In-Reply-To: Date: Tue, 31 May 2016 18:21:06 +0200 Cc: Steve Kargl , FreeBSD Current Message-Id: <68FA9A9C-241A-4315-8DED-28359368B8A4@FreeBSD.org> References: <20160529022702.GA57282@troutmask.apl.washington.edu> <1EF864CF-12E8-4A48-B6E9-317D438B7B7C@FreeBSD.org> <20160530195116.GA93546@troutmask.apl.washington.edu> To: Ed Maste X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 16:21:17 -0000 --Apple-Mail=_273B5466-BDC6-42C6-8289-EECADF00296E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 31 May 2016, at 16:25, Ed Maste wrote: >=20 > On 30 May 2016 at 15:51, Steve Kargl = wrote: >>=20 >> It happens with both /usr/bin/ld and /usr/local/bin/ld. I remove the >> binutils port and still had the issue. I tried reverting recent = changes >> to elftoolchain/libelftc, the resulting tree would not build. >=20 > The elftoolchain changes are a good candidate to check, although they > should have no impact at all on the linker. >=20 > What error did you encounter when trying to build with them reverted? =46rom Steve's initial mail: > gfortran48 -O2 -pipe -march=3Dnative -mtune=3Dnative -static = -funroll-loops \ > --param max-unroll-times=3D4 -ftree-vectorize -Wall\ > -rpath /usr/local/lib/gcc48 -I/home/kargl/modules -o acolor = acolor.f90 \ > globalm.o saxm.o -L/home/kargl/lib -L. -L/usr/local/lib -L. -ltgt = -loa \ > -L/home/kargl/lib -L. -L/usr/local/lib -lm90 -llapack -lblas > ./liboa.a(pointm.o): In function `__pointm_MOD_l2norm2': > pointm.f90:(.text+0x490): multiple definition of = `__pointm_MOD_l2norm2' > /home/kargl/lib/libtgt.a(pointm.o):pointm.f90:(.text+0x0): first = defined here >=20 > Yes, pointm.o is in both libtgt.a and liboa.a. In the past, during > linking, the symbols are resolved from the first of -ltgt or -loa > depending on the order on the command line. Maybe elftoolchain's ar does something different? Assuming the .a files are built with the system ar, of course. -Dimitry --Apple-Mail=_273B5466-BDC6-42C6-8289-EECADF00296E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAldNufkACgkQsF6jCi4glqMj+wCg214HbfSXhBY0FRdfGEhcHWVO 0SEAoJj5Jptc279Dz0VKzN8hSac8V4UF =8hAj -----END PGP SIGNATURE----- --Apple-Mail=_273B5466-BDC6-42C6-8289-EECADF00296E-- From owner-freebsd-current@freebsd.org Tue May 31 16:36: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 2156AB5521E for ; Tue, 31 May 2016 16:36:52 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 013E31E20; Tue, 31 May 2016 16:36:51 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id u4VGaoQk014334 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 31 May 2016 09:36:50 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id u4VGaoKw014333; Tue, 31 May 2016 09:36:50 -0700 (PDT) (envelope-from sgk) Date: Tue, 31 May 2016 09:36:50 -0700 From: Steve Kargl To: Dimitry Andric Cc: Ed Maste , FreeBSD Current Subject: Re: Recent seems to have broken toolchain Message-ID: <20160531163650.GA14168@troutmask.apl.washington.edu> Reply-To: kargl@uw.edu References: <20160529022702.GA57282@troutmask.apl.washington.edu> <1EF864CF-12E8-4A48-B6E9-317D438B7B7C@FreeBSD.org> <20160530195116.GA93546@troutmask.apl.washington.edu> <68FA9A9C-241A-4315-8DED-28359368B8A4@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <68FA9A9C-241A-4315-8DED-28359368B8A4@FreeBSD.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Mailman-Approved-At: Tue, 31 May 2016 17:07:25 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 16:36:52 -0000 On Tue, May 31, 2016 at 06:21:06PM +0200, Dimitry Andric wrote: > > > > The elftoolchain changes are a good candidate to check, although they > > should have no impact at all on the linker. > > > > What error did you encounter when trying to build with them reverted? > Ed is referring to a different an error after I tried revert to a known good revision. 190 9:20 cd /usr/src 191 9:20 svn revert -R . 192 9:21 cd contrib/elftoolchain/libelftc 193 9:21 svn merge -r head:295577 . 194 9:21 cd /usr/src/lib/libelftc 197 9:22 svn merge -r head:295577 . 198 9:22 make This actually builds now. Previously, I go an error about a missing function (which I can't remember). > > Yes, pointm.o is in both libtgt.a and liboa.a. In the past, during > > linking, the symbols are resolved from the first of -ltgt or -loa > > depending on the order on the command line. > > Maybe elftoolchain's ar does something different? Assuming the .a files > are built with the system ar, of course. > I tried reverting ar to a previously known good revision. That did not help. I was hoping either you or Ed would have an 'Aha!' moment and recognize where to look in the source. Unfortunately, the problem appears on the master node of my small cluster, which in the middle of a fairly long computation. I won't be able to bisect the tree until at least Friday. -- Steve From owner-freebsd-current@freebsd.org Tue May 31 16:43: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 CCC05B5547E for ; Tue, 31 May 2016 16:43:12 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AEE271221; Tue, 31 May 2016 16:43:12 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id u4VGhBUE014483 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 31 May 2016 09:43:11 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id u4VGhBLN014482; Tue, 31 May 2016 09:43:11 -0700 (PDT) (envelope-from sgk) Date: Tue, 31 May 2016 09:43:11 -0700 From: Steve Kargl To: Ed Maste Cc: Dimitry Andric , FreeBSD Current Subject: Re: Recent seems to have broken toolchain Message-ID: <20160531164311.GA14370@troutmask.apl.washington.edu> Reply-To: kargl@uw.edu References: <20160529022702.GA57282@troutmask.apl.washington.edu> <1EF864CF-12E8-4A48-B6E9-317D438B7B7C@FreeBSD.org> <20160530195116.GA93546@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Mailman-Approved-At: Tue, 31 May 2016 17:19:49 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 16:43:12 -0000 On Tue, May 31, 2016 at 10:25:54AM -0400, Ed Maste wrote: > On 30 May 2016 at 15:51, Steve Kargl wrote: > > > > It happens with both /usr/bin/ld and /usr/local/bin/ld. I remove the > > binutils port and still had the issue. I tried reverting recent changes > > to elftoolchain/libelftc, the resulting tree would not build. > > The elftoolchain changes are a good candidate to check, although they > should have no impact at all on the linker. > > What error did you encounter when trying to build with them reverted? See my reply to dim@. I don't remember the error message, but it concerned a missing function with a cpp_ prefix. I just tried to reproduce the error and everything built as expected. I was hoping that you might have an 'Aha!' moment and know where to look. If I give gfortran48 the -Wl,--allow-multiple-definition the code builds without issue. So, it seems a compile-time option for ld (or loader script) has been flipped. -- Steve From owner-freebsd-current@freebsd.org Tue May 31 19:02: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 6B188B54B10 for ; Tue, 31 May 2016 19:02:09 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 35F251BB8; Tue, 31 May 2016 19:02:09 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io0-x235.google.com with SMTP id p194so152220iod.1; Tue, 31 May 2016 12:02:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=GrbcMWfR2IZ3EDwyK7vLkJ5AbempTWCh7zJIftL5okA=; b=oU4Bn7m4dc77WXwePEsVmeAIel626zNkpoetGnX0+rtP2Bu4cNOTYyc2lPZOawOhQf 7WFSMAi5nWqKNwq8WrM/4+l7yeYjbDqeduQzNikzT9YK8x2Tpm0cV4uZc6zRFyo0T07P Uu4PelL0Mvn+ZsYa5uVVfsBkBnOmkJITRZcHwT1WFUnpiVtA0YhBXMA4f1RKMfTa2yp+ QqcaunaOay8wxbHxAXqO3DuhcCRflvsSwq4SJ/cfU4E6HJ4Pnzp++SiKaFuKo12DU2BB gTilQJFLFo1LRD3sb3YVyLUBqWeUwTBSWaAVO8eyWDWSWaIFPndB77/TbVBU0o/jF66V 9EdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=GrbcMWfR2IZ3EDwyK7vLkJ5AbempTWCh7zJIftL5okA=; b=gJ1CjzJFn0qnVv70YXOHvwhbAtXS/XJv5D2zUsY/Th7wCaYq1zhUbmDEK7bkzyigiS Q6Dn3SBetcsmgBHXip6uug0qN+WRKMQA/vcpJmwOTLen4e80fuR/TXkTw/LqCsDxE/i+ ev721SM/LYIlMvvp+Z+tSjiUNNJ3UyBKKgtMXa1uX+Dcwluk9Koz9JRFos1z6qVjiM/d ytjNh0lkvev8lJluH/gQa8nlsJaS5kwNj0jntb+YuedOOxX+SZ2LQ/Nx2K/RIdvV0gx/ necjiF7+0v0EcElOyxXl2UTJ+lElmBFZaGYn0MDfUI6Vql2JhNgdo0lRx1EbDE7eonsU 2Q4g== X-Gm-Message-State: ALyK8tKFYOVeQ6HV7bch+ljxwmN6pynvkq7zwFFACXAfO3Zb8jecpB+FmN8PAkQI+VxlW1H/zOyUOYJ2Ywo6vQ== X-Received: by 10.107.159.84 with SMTP id i81mr101075ioe.29.1464721328691; Tue, 31 May 2016 12:02:08 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.27.197 with HTTP; Tue, 31 May 2016 12:01:49 -0700 (PDT) In-Reply-To: <68FA9A9C-241A-4315-8DED-28359368B8A4@FreeBSD.org> References: <20160529022702.GA57282@troutmask.apl.washington.edu> <1EF864CF-12E8-4A48-B6E9-317D438B7B7C@FreeBSD.org> <20160530195116.GA93546@troutmask.apl.washington.edu> <68FA9A9C-241A-4315-8DED-28359368B8A4@FreeBSD.org> From: Ed Maste Date: Tue, 31 May 2016 15:01:49 -0400 X-Google-Sender-Auth: k3nKsbu-MeKCVPqY128mQeCXT64 Message-ID: Subject: Re: Recent seems to have broken toolchain To: Dimitry Andric Cc: Steve Kargl , FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 19:02:09 -0000 On 31 May 2016 at 12:21, Dimitry Andric wrote: > > Maybe elftoolchain's ar does something different? Assuming the .a files > are built with the system ar, of course. We don't use the ELF Tool Chain ar yet so it won't be that. (ELF Tool Chain's ar, brandelf, elfdump are updated descendants of the ones in the base system, but there are still some changes that exist only in the FreeBSD version so I have not yet migrated them.) From owner-freebsd-current@freebsd.org Tue May 31 20:10: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 589ADB58BBD for ; Tue, 31 May 2016 20:10:12 +0000 (UTC) (envelope-from jhb@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 46B481808 for ; Tue, 31 May 2016 20:10:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 42777B58BBC; Tue, 31 May 2016 20:10: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 42254B58BBB for ; Tue, 31 May 2016 20:10:12 +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 1DA081807 for ; Tue, 31 May 2016 20:10:12 +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 4A19BB977; Tue, 31 May 2016 16:10:10 -0400 (EDT) From: John Baldwin To: gljennjohn@gmail.com Cc: current@freebsd.org Subject: Re: EARLY_AP_STARTUP hangs during boot Date: Tue, 31 May 2016 13:10:06 -0700 Message-ID: <8812233.S6jxPboLEa@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20160528141141.232185a9@ernst.home> References: <20160516122242.39249a54@ernst.home> <20160527095005.0e0dc1be@ernst.home> <20160528141141.232185a9@ernst.home> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 31 May 2016 16:10:10 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 20:10:12 -0000 On Saturday, May 28, 2016 02:11:41 PM Gary Jennejohn wrote: > On Fri, 27 May 2016 09:50:05 +0200 > Gary Jennejohn wrote: > > > On Thu, 26 May 2016 16:54:35 -0700 > > John Baldwin wrote: > > > > > On Tuesday, May 17, 2016 06:47:41 PM Gary Jennejohn wrote: > > > > On Mon, 16 May 2016 10:54:19 -0700 > > > > John Baldwin wrote: > > > > > > > > > On Monday, May 16, 2016 12:22:42 PM Gary Jennejohn wrote: > > > > > > I tried out EARLY_AP_STARTUP, but the kernel hangs and I can't > > > > > > break into DDB. > > > > > > > > > > > > I did a verbose boot and the last lines I see are related to routing > > > > > > MSI-X to various local APIC vectors. I copied the last few lines and > > > > > > they look like this: > > > > > > > > > > > > msi: routing MSI-X IRQ 256 to local APIC 2 vector 48 > > > > > > msi: routing MSI-X IRQ 257 to local APIC 3 vector 48 > > > > > > msi: routing MSI-X IRQ 258 to local APIC 4 vector 48 > > > > > > msi: routing MSI-X IRQ 256 to local APIC 0 vector 49 > > > > ^^^^^^^ Assigning > > > > > > > > > > > > I tried disabling msi and msix in /boot/loader.conf, but the settings > > > > > > were ignored (probabaly too early). > > > > > > > > > > No, those settings are not too early. However, the routing to different > > > > > CPUs now happens earlier than it used to. What is the line before the > > > > > MSI lines? You can take a picture with your phone/camera if that's simplest. > > > > > > > > > > > > > Here a few lines before the MSI routing happens: > > > > > > > > hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 > > > > hpet0: vendor 0x4353, rev 0x1, 14318180 Hz, 3 timers, legacy route > > > > hpet0: t0 : irqs 0x00c0ff (0), MSI, periodic > > > > hpet0: t1 : irqs 0x00c0ff (0), MSI, periodic > > > > hpet0: t2 : irqs 0x00c0ff (0), MSI, periodic > > > > Timecounter "HPET" frequency 14318180 Hz quality 950 > > > > > > The assigning message means it is in the loop using > > > bus_bind_intr() to setup per-CPU timers. Can you please try > > > setting 'hint.hpet.0.per_cpu=0' at the loader prompt to see if > > > disabling the use of per-CPU timers allows you to boot? > > > > > > > Something has changed since the last time I generated a kernel with > > this option. > > > > Now I get a NULL-pointer dereference in the kernel, doesn't matter > > whether I set the hint or not. > > > > OK, now that the startup has been fixed, I tried setting the hint at > the loader prompt, but the kenel hangs in exactly the same place as > before. I actually booted twice to make certain I hadn't made a > typo when setting the hint. Humm, it shouldn't be calling bus_bind_intr() if the hint is set. Actually, I guess it just binds them all to first CPU if per-CPU timers aren't set. Can you add debug printfs to hpet_attach() in sys/dev/acpica/acpi_hpet.c to narrow down which line in that function it hangs after? Another option to try is to add the following to your kernel config: options KTR options KTR_COMPILE=KTR_PROC options KTR_MASK=KTR_PROC options KTR_VERBOSE=1 this will spew a lot of crap to the screen, but if it stops spewing when it hangs then it might be tell us where the system is hung. If you have any way to configure a serial console then this would also be useful even if it spews constantly when it is hung (assuming you could log the output of the serial console). -- John Baldwin From owner-freebsd-current@freebsd.org Tue May 31 23:37:49 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DDEDBB559A7 for ; Tue, 31 May 2016 23:37:49 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C29841BD0 for ; Tue, 31 May 2016 23:37:49 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id BDFF4B559A6; Tue, 31 May 2016 23:37:49 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BDA33B559A5 for ; Tue, 31 May 2016 23:37:49 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id A7DBC1BCF for ; Tue, 31 May 2016 23:37:49 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id A10CD128F for ; Tue, 31 May 2016 23:37:49 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 9F7732154F for ; Tue, 31 May 2016 23:37:48 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id xAlaBezoBTPc for ; Tue, 31 May 2016 23:37:45 +0000 (UTC) Subject: Re: [CFT] WITH_META_MODE: Working incremental build DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 819FB21549 References: <20160531140608.GA24894@albert.catwhisker.org> To: current@FreeBSD.org From: Bryan Drewery Organization: FreeBSD Message-ID: <5c2283ef-def0-1bdd-4766-0d2a901e7580@FreeBSD.org> Date: Tue, 31 May 2016 16:37:41 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160531140608.GA24894@albert.catwhisker.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bTto6B9mUMvVmR1gusWN8pwjSoa85Kp6V" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 23:37:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bTto6B9mUMvVmR1gusWN8pwjSoa85Kp6V Content-Type: multipart/mixed; boundary="cLfPNa4bdkmARvg7Bp0WPHrHmCWwWBFlf" From: Bryan Drewery To: current@FreeBSD.org Message-ID: <5c2283ef-def0-1bdd-4766-0d2a901e7580@FreeBSD.org> Subject: Re: [CFT] WITH_META_MODE: Working incremental build References: <20160531140608.GA24894@albert.catwhisker.org> In-Reply-To: <20160531140608.GA24894@albert.catwhisker.org> --cLfPNa4bdkmARvg7Bp0WPHrHmCWwWBFlf Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 5/31/16 7:06 AM, David Wolfskill wrote: > Kernel build failed (on laptop). But siince the build machine had succ= eeded, > I tried "make cleanworld" on the laptop, taht re-tried the build... and= > it worked. > --- machine --- > machine -> /root/svn/base/sys/amd64/include > ln: machine/include: File exists > *** [machine] Error code 1 >=20 > make: stopped in /root/svn/base/sys/modules/accf_http I've figured out the root cause for this and will have a fix soon. --=20 Regards, Bryan Drewery --cLfPNa4bdkmARvg7Bp0WPHrHmCWwWBFlf-- --bTto6B9mUMvVmR1gusWN8pwjSoa85Kp6V Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXTiBGAAoJEDXXcbtuRpfPrm8IAIdtSVCYg9NRmDe1IsFMl1gX nc7JjUT2W8BC3o68vGQM62eaflTnH9tmu1+/REUpywJ2rqExpBCKnYcVzU410XXC Xo3vFwNXdNvXDW99oEmMYt5uT7ri27XOCxbI0KUwv2ZeSo2SfDOQLu7Ts61TyGot aTMEPKOO/jS4jQmcsWoDyy0FfJwXdUi4K6ayD354ppEWX3QRO/HvWFNXYyEDy4uq LC+ilvaFdu6Q7Js84nRCECEXsCIuGie7A+C5kDaRkh5MQLYuAS+y4g8e7BqUMtM2 CoaHhbiRf8HH9iigJtueP1NwBy/YWgJkgNYOk1d/wvqct46bdu4+pVHUBo5YD7Q= =Sokk -----END PGP SIGNATURE----- --bTto6B9mUMvVmR1gusWN8pwjSoa85Kp6V-- From owner-freebsd-current@freebsd.org Tue May 31 23:41:41 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 22370B55B0D for ; Tue, 31 May 2016 23:41:41 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 063A41048 for ; Tue, 31 May 2016 23:41:41 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 019C3B55B0C; Tue, 31 May 2016 23:41:41 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0144EB55B0B for ; Tue, 31 May 2016 23:41:41 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id DECDB1047 for ; Tue, 31 May 2016 23:41:40 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id D88BD14C3 for ; Tue, 31 May 2016 23:41:40 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 802B821575 for ; Tue, 31 May 2016 23:41:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id VO5qUXbrB6fS for ; Tue, 31 May 2016 23:41:38 +0000 (UTC) Subject: Re: [CFT] WITH_META_MODE: Working incremental build DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com DF2432156F To: current@FreeBSD.org References: <20160531140608.GA24894@albert.catwhisker.org> <5c2283ef-def0-1bdd-4766-0d2a901e7580@FreeBSD.org> From: Bryan Drewery Organization: FreeBSD Message-ID: Date: Tue, 31 May 2016 16:41:37 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <5c2283ef-def0-1bdd-4766-0d2a901e7580@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="q8XhvWuChse5jmvMDLA43vadKvrMxUOpb" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 23:41:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --q8XhvWuChse5jmvMDLA43vadKvrMxUOpb Content-Type: multipart/mixed; boundary="ONmOlLfJtEmJnFuLhHOV9OpIELQGlmJ0n" From: Bryan Drewery To: current@FreeBSD.org Message-ID: Subject: Re: [CFT] WITH_META_MODE: Working incremental build References: <20160531140608.GA24894@albert.catwhisker.org> <5c2283ef-def0-1bdd-4766-0d2a901e7580@FreeBSD.org> In-Reply-To: <5c2283ef-def0-1bdd-4766-0d2a901e7580@FreeBSD.org> --ONmOlLfJtEmJnFuLhHOV9OpIELQGlmJ0n Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 5/31/16 4:37 PM, Bryan Drewery wrote: > On 5/31/16 7:06 AM, David Wolfskill wrote: >> Kernel build failed (on laptop). But siince the build machine had suc= ceeded, >> I tried "make cleanworld" on the laptop, taht re-tried the build... an= d >> it worked. >> --- machine --- >> machine -> /root/svn/base/sys/amd64/include >> ln: machine/include: File exists >> *** [machine] Error code 1 >> >> make: stopped in /root/svn/base/sys/modules/accf_http >=20 >=20 > I've figured out the root cause for this and will have a fix soon. >=20 Should be fixed by r301088. If you hit a Linux64.ko issue, you forgot to cleanworld first. Sorry about that. I've added in a mitigation to rebuild in this case and am working to get a change into bmake to remove the cleanworld need. The last remaining failure reported is in sys/boot/efi/loader when running installworld. --=20 Regards, Bryan Drewery --ONmOlLfJtEmJnFuLhHOV9OpIELQGlmJ0n-- --q8XhvWuChse5jmvMDLA43vadKvrMxUOpb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXTiExAAoJEDXXcbtuRpfPDhQIAMOJCeIlobvacpKmRqHVK4uD RXIYZpA20UbX+ZoAirt0h86SvxCdWWo6fJFdXNLyjT4/ylWP43nBEdCi0JaG96P3 JDvTpXeSTSL4PyMX1OvycwlRd9jJiS126Snd+nr569Cdl63/r9qn+M4jojYEMtkt oHeP6/8F5yP7G7t1XP2mwpTnmAe62NbUZk8SoIXvbxoQ8hn7MozlyADlImIw076F Emj8dEDtBsd/znvz7qIX1Hq1GdF1CQAO75SZkNS2q04oftkk2PQuc0E6GQ0GR2AR gGhHYhQVaMfVypBMKWxMXmjxbwHDAYPF0Y5rMkQy3PVUdu8GYBo5AWpNi7ZDcB0= =/+N5 -----END PGP SIGNATURE----- --q8XhvWuChse5jmvMDLA43vadKvrMxUOpb-- From owner-freebsd-current@freebsd.org Tue May 31 23:51:55 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D156B55D0D for ; Tue, 31 May 2016 23:51:55 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 6FAEF14BE for ; Tue, 31 May 2016 23:51:55 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 6EA8FB55D0C; Tue, 31 May 2016 23:51:55 +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 6E4A8B55D0B for ; Tue, 31 May 2016 23:51:55 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 529DE14BD for ; Tue, 31 May 2016 23:51:55 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 4BCCE1600 for ; Tue, 31 May 2016 23:51:55 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 0962821593 for ; Tue, 31 May 2016 23:51:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id 6zFqOoGLOTJ2 for ; Tue, 31 May 2016 23:51:47 +0000 (UTC) Subject: Re: [CFT] WITH_META_MODE: Working incremental build DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 678772158E To: current@FreeBSD.org References: <20160531140608.GA24894@albert.catwhisker.org> <5c2283ef-def0-1bdd-4766-0d2a901e7580@FreeBSD.org> From: Bryan Drewery Organization: FreeBSD Message-ID: Date: Tue, 31 May 2016 16:51:46 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aBsCPTMdhiNL4BLxVX8x2TOucIkOnaPEp" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 23:51:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aBsCPTMdhiNL4BLxVX8x2TOucIkOnaPEp Content-Type: multipart/mixed; boundary="gksPEUntqjkN1ubctouJp13L2llsKVt2j" From: Bryan Drewery To: current@FreeBSD.org Message-ID: Subject: Re: [CFT] WITH_META_MODE: Working incremental build References: <20160531140608.GA24894@albert.catwhisker.org> <5c2283ef-def0-1bdd-4766-0d2a901e7580@FreeBSD.org> In-Reply-To: --gksPEUntqjkN1ubctouJp13L2llsKVt2j Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 5/31/16 4:41 PM, Bryan Drewery wrote: > On 5/31/16 4:37 PM, Bryan Drewery wrote: >> On 5/31/16 7:06 AM, David Wolfskill wrote: >>> Kernel build failed (on laptop). But siince the build machine had su= cceeded, >>> I tried "make cleanworld" on the laptop, taht re-tried the build... a= nd >>> it worked. >>> --- machine --- >>> machine -> /root/svn/base/sys/amd64/include >>> ln: machine/include: File exists >>> *** [machine] Error code 1 >>> >>> make: stopped in /root/svn/base/sys/modules/accf_http >> >> >> I've figured out the root cause for this and will have a fix soon. >> >=20 > Should be fixed by r301088. >=20 > If you hit a Linux64.ko issue, you forgot to cleanworld first. Sorry > about that. I've added in a mitigation to rebuild in this case and am > working to get a change into bmake to remove the cleanworld need. >=20 > The last remaining failure reported is in sys/boot/efi/loader when > running installworld. >=20 I'm thinking the installworld issue is actually fixed by r301088 as well. My theory is that the bad machine symlink being created in the source directory caused the symlink for sys/boot/efi/loader to be considered modified and it rebuilt on install. --=20 Regards, Bryan Drewery --gksPEUntqjkN1ubctouJp13L2llsKVt2j-- --aBsCPTMdhiNL4BLxVX8x2TOucIkOnaPEp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXTiOSAAoJEDXXcbtuRpfP3v0H/Rl2JWa5dPIfmELB9Cz56Jpc vl5N5ZTvoPc67sj+BiiMbloSj2J8Ct5blfiIaa6+RmfuVnwQiwFssiAnCyBQMRUR c0KAgqsFWptPB2/ltOcBVz/EStO1GEI0urjbry1j/0j9wzzhOESeXOb0zJU3btNw m1k3RDKuA8nU0BItVm7S8maqsymqB9QzD0YdfZKXgbBAyEluk62BrPPNDKijxTq3 L76PhAOLyZ8OQRhCcgX8k4D/vScMVw6g8UtaNo9swjd7FUrBguuhC2YXX+jfJ05c VCcw0FmlF/bdgC9/JpHX094Ooge2i8r8OvQwGwY6+uaWJZiyQqlzzdl7izpDovs= =g3H5 -----END PGP SIGNATURE----- --aBsCPTMdhiNL4BLxVX8x2TOucIkOnaPEp-- From owner-freebsd-current@freebsd.org Tue May 31 23:55: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 A44C2B55EDA for ; Tue, 31 May 2016 23:55:52 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 8674F17CA for ; Tue, 31 May 2016 23:55:52 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 81F93B55ED9; Tue, 31 May 2016 23:55:52 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 819FBB55ED7 for ; Tue, 31 May 2016 23:55:52 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 6675117C9 for ; Tue, 31 May 2016 23:55:52 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 5AA6D16E8 for ; Tue, 31 May 2016 23:55:52 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 13586215A6 for ; Tue, 31 May 2016 23:55:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id ErysN-5AS5Bz for ; Tue, 31 May 2016 23:55:48 +0000 (UTC) Subject: Re: [CFT] WITH_META_MODE: Working incremental build DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 5CDE4215A1 To: current@FreeBSD.org References: <20160531140608.GA24894@albert.catwhisker.org> <5c2283ef-def0-1bdd-4766-0d2a901e7580@FreeBSD.org> From: Bryan Drewery Organization: FreeBSD Message-ID: Date: Tue, 31 May 2016 16:55:47 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sNfuBEKkgk4BX3knmPkpM20Obgbj4Uk2p" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 23:55:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sNfuBEKkgk4BX3knmPkpM20Obgbj4Uk2p Content-Type: multipart/mixed; boundary="5ucpqIhP2SDLIwuVsJNk7L17fDsSVuEbJ" From: Bryan Drewery To: current@FreeBSD.org Message-ID: Subject: Re: [CFT] WITH_META_MODE: Working incremental build References: <20160531140608.GA24894@albert.catwhisker.org> <5c2283ef-def0-1bdd-4766-0d2a901e7580@FreeBSD.org> In-Reply-To: --5ucpqIhP2SDLIwuVsJNk7L17fDsSVuEbJ Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 5/31/16 4:51 PM, Bryan Drewery wrote: > On 5/31/16 4:41 PM, Bryan Drewery wrote: >> On 5/31/16 4:37 PM, Bryan Drewery wrote: >>> On 5/31/16 7:06 AM, David Wolfskill wrote: >>>> Kernel build failed (on laptop). But siince the build machine had s= ucceeded, >>>> I tried "make cleanworld" on the laptop, taht re-tried the build... = and >>>> it worked. >>>> --- machine --- >>>> machine -> /root/svn/base/sys/amd64/include >>>> ln: machine/include: File exists >>>> *** [machine] Error code 1 >>>> >>>> make: stopped in /root/svn/base/sys/modules/accf_http >>> >>> >>> I've figured out the root cause for this and will have a fix soon. >>> >> >> Should be fixed by r301088. >> >> If you hit a Linux64.ko issue, you forgot to cleanworld first. Sorry >> about that. I've added in a mitigation to rebuild in this case and am >> working to get a change into bmake to remove the cleanworld need. >> >> The last remaining failure reported is in sys/boot/efi/loader when >> running installworld. >> >=20 > I'm thinking the installworld issue is actually fixed by r301088 as > well. My theory is that the bad machine symlink being created in the > source directory caused the symlink for sys/boot/efi/loader to be > considered modified and it rebuilt on install. >=20 Another reported issue just now is that right after an installworld, everything rebuilds due to changed /bin/sh (-dM flag to make tells you why things rebuild). I'll look into some mitigations for this. --=20 Regards, Bryan Drewery --5ucpqIhP2SDLIwuVsJNk7L17fDsSVuEbJ-- --sNfuBEKkgk4BX3knmPkpM20Obgbj4Uk2p Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXTiSDAAoJEDXXcbtuRpfP244H/1ZC2aDkSm0nGf1rgSM1otIe kvHH5XJ1CGC29ieiC3xfh6KLkZNc5sPVF2Az3oEpq6qbk1XnMw9B//ksNFsGRS95 4xpdmDCuE9cpG+OTDO17MGjBr82UAES4J4O/zGogZRcmUac7es+yMCCzC6oAnqMH 2hr9ZVx/oKo2m+IO/imTMTLf8qXLKYauYP/+RxjtPbh1dw6K0JnaYtlHJ+ejlVah lWowJ3W9Rt8j6lrL55ByS8SwzKuBw7R8dhaUMwumDktDNJ5i0QHVcvW7J4sibR1V FluILwoYTVuwTemMzw1o8n8+wO2rOpzgULu9+d0xhwV7+Qej+AY9JSCy3nX/p28= =rEZJ -----END PGP SIGNATURE----- --sNfuBEKkgk4BX3knmPkpM20Obgbj4Uk2p-- From owner-freebsd-current@freebsd.org Wed Jun 1 00:32: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 C5C4EB57BB8 for ; Wed, 1 Jun 2016 00:32:51 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 6DC3B1A5A for ; Wed, 1 Jun 2016 00:32:51 +0000 (UTC) (envelope-from sjg@juniper.net) Received: by mailman.ysv.freebsd.org (Postfix) id 6D1E4B57BB6; Wed, 1 Jun 2016 00:32: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 6CBE6B57BB5 for ; Wed, 1 Jun 2016 00:32:51 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0131.outbound.protection.outlook.com [65.55.169.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A76221A58; Wed, 1 Jun 2016 00:32:50 +0000 (UTC) (envelope-from sjg@juniper.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OoA2aqgfYqTWFOgYLyRTeUz7uQ64eowv9++g2qNrL98=; b=QCew+pAGBaAHMivHLVue3d+qork4FM2U5+9W3R4cu3foqmUgijKrFSJWksL0QLZH28Zke2bIjxya9lgC4gI5jzj+Fdligyh7ZXr8pOaT3p7tIRxrZZhXjYl3Wkd4LCNuTHc+JXCMmYohRfgtMMDPLYGFtsqp1ag5ATQTiVWcP/o= Received: from SN1PR0501CA0042.namprd05.prod.outlook.com (10.163.126.180) by SN2PR05MB2495.namprd05.prod.outlook.com (10.166.213.16) with Microsoft SMTP Server (TLS) id 15.1.506.9; Wed, 1 Jun 2016 00:17:08 +0000 Received: from BN1BFFO11FD033.protection.gbl (2a01:111:f400:7c10::1:114) by SN1PR0501CA0042.outlook.office365.com (2a01:111:e400:52fe::52) with Microsoft SMTP Server (TLS) id 15.1.506.9 via Frontend Transport; Wed, 1 Jun 2016 00:17:08 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.19) smtp.mailfrom=juniper.net; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.19 as permitted sender) Received: from P-EMFE01C-SAC.jnpr.net (66.129.239.19) by BN1BFFO11FD033.mail.protection.outlook.com (10.58.144.96) with Microsoft SMTP Server (TLS) id 15.1.497.8 via Frontend Transport; Wed, 1 Jun 2016 00:17:07 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMFE01C-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 31 May 2016 17:17:03 -0700 Received: from kaos.jnpr.net (kaos.jnpr.net [172.21.16.84]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id u510H3J92591; Tue, 31 May 2016 17:17:03 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 1833C385508; Tue, 31 May 2016 17:17:03 -0700 (PDT) To: Bryan Drewery CC: , Subject: Re: [CFT] WITH_META_MODE: Working incremental build In-Reply-To: References: <20160531140608.GA24894@albert.catwhisker.org> <5c2283ef-def0-1bdd-4766-0d2a901e7580@FreeBSD.org> Comments: In-reply-to: Bryan Drewery message dated "Tue, 31 May 2016 16:55:47 -0700." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <48165.1464740222.1@kaos.jnpr.net> Date: Tue, 31 May 2016 17:17:03 -0700 Message-ID: <48166.1464740223@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.19; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(189002)(199003)(9170700003)(5008740100001)(586003)(76176999)(8676002)(2906002)(4326007)(23726003)(92566002)(19580395003)(50986999)(5003600100002)(77096005)(81166006)(50226002)(2950100001)(93886004)(450100001)(9686002)(2810700001)(4001430100002)(11100500001)(8936002)(558084003)(97756001)(87936001)(107886002)(86362001)(110136002)(189998001)(76506005)(47776003)(46406003)(50466002)(105596002)(6806005)(117636001)(53416004)(106466001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2495; H:P-EMFE01C-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD033; 1:vn8RxXlCE1WwnMdVhtNbeWtEsINLSBCdsIz+/gSd/1+DpSdlxiId3V3kIfJv+tMHHf3CgwiWuv0QvH7AB9+yfEqJjWbZjIxHHuR7smS6ML2Gv/FEiXeGkshg+E3B1fmvYSGow869Twe/mowoa2FLMJ8i+ymMKk2MI+pDbMTWFwOT9EGtgwcwzHNc9cOV/VXDgluWUH2H2rGKB5KLAY/V517US2q2OQoN8N3etFo6uTVZq8HO3pNrzCe2cVtEk2icHZ6vl4VMMKTLctcmlzJJHqRpUROdQK1JfL3TlMhZm/pJrXlicB/e6JMyoipKkgmv5yhA5hRSBeEZSVkvq0gAUQRdGsUHd1mGFv1xJwzof+X9b/FMe1RaDY8vcXa+mQgmwSc8Oz7B9tjuCiqOYgJpSTsOrJM5c3gDlH2t6mV2607gjd1FoajagOJvTybd1rYRbNmsDcCM22B/8fOVk+F/Twf4bAUHI0vTJgUdUY5kqMs= X-MS-Office365-Filtering-Correlation-Id: 1895eddf-1bcc-49d9-80e2-08d389b2117e X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2495; 2:8CLOh75xHKghkrVzJ4rAKdRv9KxLT1ggqaScaJkVMJHbZQ4SQ9JYYUyC3PlrqlT+VrrzKgVmGeTETOlaN1Cl10nWouHIb021f+ZvgGKo0B8oFYJBidVHX0SGntJSCuFImqSkaYwVkUGo8400WMPx/yANPDUa9wrC7SxMCBVoxx0vAa6ACx8P8nBPk0yGDSWY; 3:GBne9LBIWvyN3dc8Dk2XrM4oKpOiEZYZEpFbO1NkCGknlTcX6Ho2acQJliNZKXJC/3p2P/dZBmJuZBZYSbvwZR4hQhHDKidFyVV8GviNyqdgK2BxcDascLJw/MD6t+U/RQmM/ovlO6ozAZeQGBtOjW26cSj6uIw5dMWOqqoS6PVDM/gjkqqyQeTEyTBK8z2GKQ7VeCj2Kq9tTDL2eKqqsgZKlPN3B3zQy/jOsQLrxzA= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR05MB2495; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2495; 25:+lcYdi5mG+XsmGhf0tM1ht/iaXD5yjl1Ej2HCPTrvKc3i0UCRjlMnqtZ4+2vux0GJkZnbZ4FSY2lNX5gQ9zxvGUWy3dKRzqwvQTSlrTsPUjg3pXMdKnMNpEUVGvboAwFMvbgYfiRTc75/Xll/KxBTbA8fsgeYkE/ESgFcMaxXeLoQWxQ6e8BMllkQBTzBL8WhYDCwneMDx2OMggHZGc4z6Zwg4oQ/dKGD2wnS+o+dDlsEdRiM8YqHaytyj3ib7AZ0ZJYW+HnM4m26WlbwxE9lU3vu07OYbfyjZsN0ei/MwZxl9yCsF1m4535aLuygHjN4IXP6ZyQKsPfR5Fn1SUa9u3fL8p7CyiBrRoJNtDSxWEEfU6nFxbqT4kl6kHVbxQP1Da7rF6t9pMLEbE+ZXIMkDhDtM+hM0uL0XwFhidPbx/pFoo53uS4ivKo1q8rW1dHzYCuKuWE58H+p3X17+cnyuCOJEbRMnh7S4uDIl/6T1sJOEtNXXDs95rsQPIpmFUprCH18cX123l6KvrC878i2zChClKoKXSHqC7Bh9NR0ox2gLwk+jee5bOcQQNGYPxXeDf1sZufyBNYMFs/vpl02sHaepZztRyBOL53H28fTS3+g8Qo/oRfDin6nUaTM3xpPe+w5D1fYUUkT0aau/5TwChkTWoYaDpQHxXJaPaNKtTv0Hp4c19zWsT8rKvM+sO4uVBMMGQ2tzrY0gLIsx97n5XhMnfhk4eHqdO684UVvHo= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2495; 20:fsfFSFhKPoTfWMk5aIhaLyMBh3WbpXMA93e430Z6T15lLOA58vkP9qm2/8S7zqsXp+/0hsXhFvSQ+eSj6eI1lnc/o/qSSN36jCObwPhkOc00ZxlKG/32Q3tmGpWHgjH3lukc0KSd3Fz8kz7eFo9fI3hOV0i3Ns58JPLQ3vO2BnmGoXJIzEzl+Ipi6PUSC6L7VSfN2StrmASJLJu69i17nnVnV8VnKko2PizZjCUpB8N9pxxn2bNbsxhUvMEHC/dpXwD2pqcyeT7K8s8Cx/o8t0p6PB92/oLoTrACEk4s21l5+DskPJajbYBlCy3Tv4No1rrGqyU6OT0AFvsnqv1AF+vACAYlRZIQEWu3BrYk6IrUmZYdWoD32MnXkEhHtTJIPKqNmFJ15Ciyb8jDx59nrCd1Mfn64mR2XBEc/MMWicJJCVIy4FZZ1IlGuVEwFNex0MBhykUyxiWF6A1XxPXe1/vbUQQ5VAwD6KGhnQqil5rFQDpHSLV8U/o27DTb//iM X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13018025)(13024025)(8121501046)(5005006)(13015025)(13023025)(13017025)(3002001)(10201501046)(6055026); SRVR:SN2PR05MB2495; BCL:0; PCL:0; RULEID:; SRVR:SN2PR05MB2495; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2495; 4:5IU4OIaibntSsK2xGWe48LXqcyK6+Maj9gV7SV6eRD8DioLW5SBLzQHmjsvXSIbfLdiW1AMZf8SsJQ4z21txEBvvKzs5o3HkzSaOPya2nEC9bQes9o42itKZR0xX/Dj8IEbCtQ4lyYKq8IrUhdxXXyBccBh810HHWE1FyB93zLc0l6eCFMKkDAWQQTr0Jc05AtRnePpoMZRlYDThUiNXi6XuVTdJ0CKWhnFWbVRZ0bt0Gh0mH7/OiCnxofJrPsORNtJeoWf7bFo6/C4ryzYQEiMlOKFrl3bT94pNOMCT3oQdZ6MeRS8EVDRKN0uEq7mUhWarWPJqfmLSjUDjkF4KeDr+/+ijJ6Wag0VpTHG8UnwnvPDVU+G15nPO3FmeapL5ckXhhrwrP83YOPtsVZnvZH4nHaSpsJL3As44Llbrm8sMIwbhIJnnOgvBJHgoGPyqzpGnmierl10dzPjgiiXUtlfBsxmjpQH+qYIQu/NUUnI= X-Forefront-PRVS: 096029FF66 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2495; 23:nGhBQkSqylmbgs2FHarOU1xXXaRUv486h9QvFj+WO?= =?us-ascii?Q?j+uAJHHNImQp6nLWLCOk0qki9rN7I+HojhBH2bZcqSjg1chnRIf/5cLZMOxu?= =?us-ascii?Q?gWy+qZlj1aEhvHqktnYlpPYc5cmq2/1idONFoG6grWvmcztMBHucbL9UqNHe?= =?us-ascii?Q?ke1nxAlEC1uqcv7767463BWGrBUr2sAMyo6EIS+MJFWGOv1Qzu2LpOpFNDUj?= =?us-ascii?Q?wwaQnah7ygY2lewryzTUs3FqFVncXm8FVWjwORsHW4umAhOoItUQwr0BQUbo?= =?us-ascii?Q?WH0DZ2zfX6ASc8YE6SbDUCCp5n3OSOXBsxOdK03lu52wIRIf06+laQlB3mbU?= =?us-ascii?Q?+pT+NMAolVPPlsbXd02oy7CGvxPd2Lje9Cr+SenbSBRHai+h9FIT0HKxXTMy?= =?us-ascii?Q?uNQvs1YCHjbPSQN7wCymjykMuEvvWQKEhDyPBKFJAXOT0STYy01dFgbyzR9o?= =?us-ascii?Q?gsUvgfZheNo0+0rf7WnHh2D1ANG9LD64ubaPuv3iM2BVM+wK9qWOamg3ECLs?= =?us-ascii?Q?xpGsBiNzJQJlGw1yCPnRf9Fa3tXA6YNvfhrLxwK+lfkpCZTQ00BkEI80FrC0?= =?us-ascii?Q?foIN7MvXzXb1JSnCJ2RogTCTn19flVvEd9TZ514gd/pYIqlZyH5DLh0kDqoR?= =?us-ascii?Q?miaW2eTScQj7LUsAYhfn1FF/0RbfzMkt9bTWA4Hc7ko3q4X9xDOgLkwk+4M1?= =?us-ascii?Q?hUlJ5TOjkemb+W9sCIikCp5CVfMbii3xP55knBedGWbX2OK9Rm5zlkU/LbwM?= =?us-ascii?Q?RlnMcXSADgaa5Fx6sg3Fm0H8VEUcYpmosBFpo20dArxAfjqqKvIALAlyKPAS?= =?us-ascii?Q?wq4togNPFnDHITI7PHOfn/ZH9oObDc6rABTKUeXI4qqx18LOjFscHL0BL4sH?= =?us-ascii?Q?LvWNIR1DfMwTHCYUCCCsMD2OKpsaBK7y1sVwvyNNwG9dHspwo1r1TBxIW/uv?= =?us-ascii?Q?pJ6e4JHTo/hr0xXJf/YsgDj2lVb1oeJgJCwZdJ3BsaGwQuVqeV9MBWNX+Llx?= =?us-ascii?Q?B6+uedPxPMqozACSZbcXxG3JuK0o7kB1APs+xs+oXUtnT6D+gO0Gx7HXLAyH?= =?us-ascii?Q?lj+qVq4ixdIAuksnm7gVUb2SqXaH8bnIks7aQEWGgVJPN1dDmFxmWI6uFE+f?= =?us-ascii?Q?Mx4FJQ/MZh/+6uV/oVrT/BKUCxiDwCF?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2495; 5:g/SuOw8DDz88Sw12FkpGqZSf9mDAKebTxL5Gjra9DztoowpjgLdQ9pZPeeJAZHmpPlqDjy5xij5CWtJgfoCbpb8Ng7titwYky+/oZkxhvIKA3jMqCoRNYGRdnRRrTHbJuc0dVqTNp70ZapCQyo7JPA==; 24:2JgsAEsWQB41GtbWrAIkXk9HZcOXpbm47dzwdr/s17vvPAzShX2iOCoQde5U1IYDiPDsNXwqWnKST9sk7yjEpQfxVgble7ve8E42/Wd+DWY=; 7:3zVv8B60+MxocTepFGJoPbirFsU1CHxyM6sU5mLSAhNBhEaXN0u/aThSZcSa8b7NHYiLKKZXbYeKeNU6i8Dor7mOhY82jtm5yjE0InVDsy3fgV8ex3XL0zRP12ZCcMWDEKYFg7lmfIOMia/Ilft0bkXEnzYVhvDtu6TR5WG7KjaJXvl1jDKfC9gNaSEK3pPN SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jun 2016 00:17:07.5691 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.19]; Helo=[P-EMFE01C-SAC.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2495 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 00:32:51 -0000 > Another reported issue just now is that right after an installworld, > everything rebuilds due to changed /bin/sh (-dM flag to make tells you > why things rebuild). I'll look into some mitigations for this. It is probably sufficient to just add .MAKE.META.IGNORE_PATHS += ${__MAKE_SHELL} From owner-freebsd-current@freebsd.org Wed Jun 1 05:21: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 96922B5B6C3 for ; Wed, 1 Jun 2016 05:21:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-194.reflexion.net [208.70.211.194]) (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 4D023141A for ; Wed, 1 Jun 2016 05:21:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 27997 invoked from network); 1 Jun 2016 05:21:31 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 1 Jun 2016 05:21:31 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Wed, 01 Jun 2016 01:21:41 -0400 (EDT) Received: (qmail 14963 invoked from network); 1 Jun 2016 05:21:40 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 1 Jun 2016 05:21:40 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 312051C43E2; Tue, 31 May 2016 22:21:29 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 31 May 2016 22:21:35 -0700 Subject: 11.0 -r300944 buildworld via amd64-gcc fails for: .../dev/cxgb/ulp/tom/cxgb_listen.c:926:13: error: redundant redeclaration of 'tcp_dooptions' To: FreeBSD Current Message-Id: <1885ED2D-29CB-47EF-B746-7CAD52E91605@dsl-only.net> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 05:21:43 -0000 > --- all_subdir_cxgb --- > = /usr/src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_listen.c:926:= 13: error: redundant redeclaration of 'tcp_dooptions' = [-Werror=3Dredundant-decls] > extern void tcp_dooptions(struct tcpopt *, u_char *, int, int); > ^ > In file included from = /usr/src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_listen.c:49:0= : > /usr/src/sys/netinet/tcp_var.h:769:7: note: previous declaration of = 'tcp_dooptions' was here > void tcp_dooptions(struct tcpopt *, u_char *, int, int); > ^ . . . --- all_subdir_cxgb --- > cc1: all warnings being treated as errors > *** [cxgb_listen.o] Error code 1 I got this while experimenting with WITH_META_MODE=3Dyes for an external = toolchain. src.conf details: (Yes it has some redundancies.) TO_TYPE=3Damd64 TOOLS_TO_TYPE=3Dx86_64 VERSION_CONTEXT=3D11.0 # KERNCONF=3DGENERIC-NODEBUG TARGET=3D${TO_TYPE} .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITHOUT_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITHOUT_BINUTILS_BOOTSTRAP=3D WITHOUT_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLDB=3D #PORTS_MODULES=3Demulators/virtualbox-ose-additions # #WITH_BOOT=3D for amd64-xtoolschain-gcc/amd64-gcc gets...=20 # --- all_subdir_sys --- # -994 bytes available # *** [boot2] Error code 1 WITHOUT_BOOT=3D WITH_LIB32=3D # WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_DEBUG_FILES=3D # # # For TO (so-called "cross") stages . . . # So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . . # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . . # CROSS_TOOLCHAIN=3D${TO_TYPE}-gcc X_COMPILER_TYPE=3Dgcc CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ .if ${.MAKE.LEVEL} =3D=3D 0 = XCC=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-gc= c = XCXX=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-g= ++ = XCPP=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-c= pp .export XCC .export XCXX .export XCPP XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size #NO-SUCH: XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings XSTRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings .export XAS .export XAR .export XLD .export XNM .export XOBJCOPY .export XOBJDUMP .export XRANLIB .export XSIZE .export XSTRINGS .endif # # # =46rom based on clang (via system). . . # .if ${.MAKE.LEVEL} =3D=3D 0 CC=3D/usr/bin/clang CXX=3D/usr/bin/clang++ CPP=3D/usr/bin/clang-cpp .export CC .export CXX .export CPP .endif =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Wed Jun 1 05:49: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 B001DB5C5E8 for ; Wed, 1 Jun 2016 05:49:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-181.reflexion.net [208.70.211.181]) (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 7565411CB for ; Wed, 1 Jun 2016 05:49:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 19154 invoked from network); 1 Jun 2016 05:49:31 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 1 Jun 2016 05:49:31 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Wed, 01 Jun 2016 01:49:27 -0400 (EDT) Received: (qmail 8611 invoked from network); 1 Jun 2016 05:49:27 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 1 Jun 2016 05:49:27 -0000 X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 0C2BD1C43E2 for ; Tue, 31 May 2016 22:49:23 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: 11.0 -r300944 build*KERNEL* via amd64-gcc fails for: .../dev/cxgb/ulp/tom/cxgb_listen.c:926:13: error: redundant redeclaration of 'tcp_dooptions'; cxgbe has an issue too From: Mark Millard In-Reply-To: Date: Tue, 31 May 2016 22:49:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <086B90E6-2E0C-4AA9-B429-523685EF1459@dsl-only.net> References: <1885ED2D-29CB-47EF-B746-7CAD52E91605@dsl-only.net> To: FreeBSD Current X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 05:49:37 -0000 On 2016-May-31, at 10:31 PM, Mark Millard = wrote: > [I'm too used to typing "buildworld": The subject line should have = referenced buildkernel and this resend does.] >=20 > On 2016-May-31, at 10:21 PM, Mark Millard = wrote: >>=20 >>> --- all_subdir_cxgb --- >>> = /usr/src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_listen.c:926:= 13: error: redundant redeclaration of 'tcp_dooptions' = [-Werror=3Dredundant-decls] >>> extern void tcp_dooptions(struct tcpopt *, u_char *, int, int); >>> ^ >>> In file included from = /usr/src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_listen.c:49:0= : >>> /usr/src/sys/netinet/tcp_var.h:769:7: note: previous declaration of = 'tcp_dooptions' was here >>> void tcp_dooptions(struct tcpopt *, u_char *, int, int); >>> ^ >> . . . >> --- all_subdir_cxgb --- >>> cc1: all warnings being treated as errors >>> *** [cxgb_listen.o] Error code 1 >>=20 >>=20 >> I got this while experimenting with WITH_META_MODE=3Dyes for an = external toolchain. >>=20 >>=20 >> src.conf details: >> (Yes it has some redundancies.) >>=20 >> TO_TYPE=3Damd64 >> TOOLS_TO_TYPE=3Dx86_64 >> VERSION_CONTEXT=3D11.0 >> # >> KERNCONF=3DGENERIC-NODEBUG >> TARGET=3D${TO_TYPE} >> .if ${.MAKE.LEVEL} =3D=3D 0 >> TARGET_ARCH=3D${TO_TYPE} >> .export TARGET_ARCH >> .endif >> # >> WITHOUT_CROSS_COMPILER=3D >> WITHOUT_SYSTEM_COMPILER=3D >> # >> WITH_LIBCPLUSPLUS=3D >> WITHOUT_BINUTILS_BOOTSTRAP=3D >> WITHOUT_CLANG_BOOTSTRAP=3D >> WITH_CLANG=3D >> WITH_CLANG_IS_CC=3D >> WITH_CLANG_FULL=3D >> WITH_CLANG_EXTRAS=3D >> WITH_LLDB=3D >> #PORTS_MODULES=3Demulators/virtualbox-ose-additions >> # >> #WITH_BOOT=3D for amd64-xtoolschain-gcc/amd64-gcc gets...=20 >> # --- all_subdir_sys --- >> # -994 bytes available >> # *** [boot2] Error code 1 >> WITHOUT_BOOT=3D >> WITH_LIB32=3D >> # >> WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D >> WITHOUT_GCC_BOOTSTRAP=3D >> WITHOUT_GCC=3D >> WITHOUT_GCC_IS_CC=3D >> WITHOUT_GNUCXX=3D >> # >> NO_WERROR=3D >> #WERROR=3D >> MALLOC_PRODUCTION=3D >> # >> WITH_DEBUG_FILES=3D >> # >> # >> # For TO (so-called "cross") stages . . . >> # So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . . >> # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. = . . >> # >> CROSS_TOOLCHAIN=3D${TO_TYPE}-gcc >> X_COMPILER_TYPE=3Dgcc >> CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ >> .if ${.MAKE.LEVEL} =3D=3D 0 >> = XCC=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-gc= c >> = XCXX=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-g= ++ >> = XCPP=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-c= pp >> .export XCC >> .export XCXX >> .export XCPP >> XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as >> XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar >> XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld >> XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm >> XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy >> XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump >> XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib >> XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size >> #NO-SUCH: XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings >> XSTRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings >> .export XAS >> .export XAR >> .export XLD >> .export XNM >> .export XOBJCOPY >> .export XOBJDUMP >> .export XRANLIB >> .export XSIZE >> .export XSTRINGS >> .endif >> # >> # >> # =46rom based on clang (via system). . . >> # >> .if ${.MAKE.LEVEL} =3D=3D 0 >> CC=3D/usr/bin/clang >> CXX=3D/usr/bin/clang++ >> CPP=3D/usr/bin/clang-cpp >> .export CC >> .export CXX >> .export CPP >> .endif >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net If the offending declaration in cxgb_listen.c is commented out (or = removed) there is a "next problem" but for cxgbe: > --- all_subdir_cxgbe/tom --- > /usr/src/sys/modules/cxgbe/tom/../../../dev/cxgbe/tom/t4_listen.c: In = function 'do_pass_accept_req': > = /usr/src/sys/modules/cxgbe/tom/../../../dev/cxgbe/tom/t4_listen.c:640:1: = warning: inlining failed in call to 'release_synqe': call is unlikely = and code size would grow [-Winline] > release_synqe(struct synq_entry *synqe) > ^ > = /usr/src/sys/modules/cxgbe/tom/../../../dev/cxgbe/tom/t4_listen.c:1406:3: = warning: called from here [-Winline] > release_synqe(synqe); /* extra hold */ > ^ > = /usr/src/sys/modules/cxgbe/tom/../../../dev/cxgbe/tom/t4_listen.c:640:1: = warning: inlining failed in call to 'release_synqe': call is unlikely = and code size would grow [-Winline] > release_synqe(struct synq_entry *synqe) > ^ > = /usr/src/sys/modules/cxgbe/tom/../../../dev/cxgbe/tom/t4_listen.c:1411:2: = warning: called from here [-Winline] > release_synqe(synqe); /* extra hold */ > ^ . . . > --- all_subdir_cxgbe/tom --- > cc1: all warnings being treated as errors > *** [t4_listen.o] Error code 1 It looks like this code area has not been tried under devel/amd64-gcc = compiles. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209920 has the = material for these. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Wed Jun 1 05:31:58 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E2616B59A6C for ; Wed, 1 Jun 2016 05:31:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-185.reflexion.net [208.70.211.185]) (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 97BC01BC6 for ; Wed, 1 Jun 2016 05:31:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 30070 invoked from network); 1 Jun 2016 05:32:26 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 1 Jun 2016 05:32:26 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Wed, 01 Jun 2016 01:32:34 -0400 (EDT) Received: (qmail 29531 invoked from network); 1 Jun 2016 05:32:33 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 1 Jun 2016 05:32:33 -0000 X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 882CD1C43E2 for ; Tue, 31 May 2016 22:31:48 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: 11.0 -r300944 build*KERNEL* via amd64-gcc fails for: .../dev/cxgb/ulp/tom/cxgb_listen.c:926:13: error: redundant redeclaration of 'tcp_dooptions' From: Mark Millard In-Reply-To: <1885ED2D-29CB-47EF-B746-7CAD52E91605@dsl-only.net> Date: Tue, 31 May 2016 22:31:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1885ED2D-29CB-47EF-B746-7CAD52E91605@dsl-only.net> To: FreeBSD Current X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 05:31:59 -0000 [I'm too used to typing "buildworld": The subject line should have = referenced buildkernel and this resend does.] On 2016-May-31, at 10:21 PM, Mark Millard = wrote: >=20 >> --- all_subdir_cxgb --- >> = /usr/src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_listen.c:926:= 13: error: redundant redeclaration of 'tcp_dooptions' = [-Werror=3Dredundant-decls] >> extern void tcp_dooptions(struct tcpopt *, u_char *, int, int); >> ^ >> In file included from = /usr/src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_listen.c:49:0= : >> /usr/src/sys/netinet/tcp_var.h:769:7: note: previous declaration of = 'tcp_dooptions' was here >> void tcp_dooptions(struct tcpopt *, u_char *, int, int); >> ^ > . . . > --- all_subdir_cxgb --- >> cc1: all warnings being treated as errors >> *** [cxgb_listen.o] Error code 1 >=20 >=20 > I got this while experimenting with WITH_META_MODE=3Dyes for an = external toolchain. >=20 >=20 > src.conf details: > (Yes it has some redundancies.) >=20 > TO_TYPE=3Damd64 > TOOLS_TO_TYPE=3Dx86_64 > VERSION_CONTEXT=3D11.0 > # > KERNCONF=3DGENERIC-NODEBUG > TARGET=3D${TO_TYPE} > .if ${.MAKE.LEVEL} =3D=3D 0 > TARGET_ARCH=3D${TO_TYPE} > .export TARGET_ARCH > .endif > # > WITHOUT_CROSS_COMPILER=3D > WITHOUT_SYSTEM_COMPILER=3D > # > WITH_LIBCPLUSPLUS=3D > WITHOUT_BINUTILS_BOOTSTRAP=3D > WITHOUT_CLANG_BOOTSTRAP=3D > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_CLANG_EXTRAS=3D > WITH_LLDB=3D > #PORTS_MODULES=3Demulators/virtualbox-ose-additions > # > #WITH_BOOT=3D for amd64-xtoolschain-gcc/amd64-gcc gets...=20 > # --- all_subdir_sys --- > # -994 bytes available > # *** [boot2] Error code 1 > WITHOUT_BOOT=3D > WITH_LIB32=3D > # > WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D > WITHOUT_GCC_BOOTSTRAP=3D > WITHOUT_GCC=3D > WITHOUT_GCC_IS_CC=3D > WITHOUT_GNUCXX=3D > # > NO_WERROR=3D > #WERROR=3D > MALLOC_PRODUCTION=3D > # > WITH_DEBUG_FILES=3D > # > # > # For TO (so-called "cross") stages . . . > # So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . . > # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . = . > # > CROSS_TOOLCHAIN=3D${TO_TYPE}-gcc > X_COMPILER_TYPE=3Dgcc > CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ > .if ${.MAKE.LEVEL} =3D=3D 0 > = XCC=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-gc= c > = XCXX=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-g= ++ > = XCPP=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-c= pp > .export XCC > .export XCXX > .export XCPP > XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as > XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar > XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld > XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm > XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy > XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump > XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib > XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size > #NO-SUCH: XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings > XSTRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings > .export XAS > .export XAR > .export XLD > .export XNM > .export XOBJCOPY > .export XOBJDUMP > .export XRANLIB > .export XSIZE > .export XSTRINGS > .endif > # > # > # =46rom based on clang (via system). . . > # > .if ${.MAKE.LEVEL} =3D=3D 0 > CC=3D/usr/bin/clang > CXX=3D/usr/bin/clang++ > CPP=3D/usr/bin/clang-cpp > .export CC > .export CXX > .export CPP > .endif =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Wed Jun 1 07:36: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 E7E10B60EBE for ; Wed, 1 Jun 2016 07:36:15 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B7658129B for ; Wed, 1 Jun 2016 07:36:15 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: by mail-pf0-x22e.google.com with SMTP id 62so9998618pfd.1 for ; Wed, 01 Jun 2016 00:36:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=VsQyAD4dtJyS3xTOX12a3tqCYIU5re8bA9IIH18pjFE=; b=W8wxTTOHNtEIE+IoMCJAke5j7CnsbL8yCl9V/5QLSv8oLRZxBHfQa5crLaT0Vk0qj8 vS+BZqcc8+v57/d8s4Z3PYeWuCidg2qw99gyiTtHhjVcE/Lywidovnxzg+vQ0f80Eqtc HQfjsOSSmKK129iShj/cqOwUyiuy6MqZnnMMM0pEdf92EOCQLG1Gw6OrFB6J8yZuZGh0 dcWyzWTOHBiVpxXrTjzFaxs5huMGVeU8LvJ/eb5LaEW1JUYz+ZbsOEV5emK1VfJTOCp5 u1Cjfdo2acWM0xbdJtXHk94CQvujAiszLOE5cPvOMFUEsHDZD8lWBMzwWGZyPAwbgWkb MaTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=VsQyAD4dtJyS3xTOX12a3tqCYIU5re8bA9IIH18pjFE=; b=AtJJf2et/4Vc67QGPHjbsXlFBNyCo4d3VDPSJoIc0o15YWAFr6+4dDonI+/Y3Z8reF NV9yokjTxx8qS0d2xS83geThSZ5OS8+IyQbsuQNVBPtQV9yTu+CeRgclyefIVvhx9YlK OZ51TVxQTey7Np5XDac446EGjhIIz6ZI37RNa6YdgD9mDhKsYDigPKy3xhEp93F02TYQ 1iPwprxNY9LnhhWAEUXcLsUP+gvn2p0vcp6VlCKqyS/SoMLHQOFdl/dCbT6maN/UEsQ9 u5dopt9XJejpFqpUdszkYUYMfK+5huMJcYjWQedZX8FfwVTmy2qK0CKDUC7Fd+Iz2+3w 8eug== X-Gm-Message-State: ALyK8tLl0lL3fY9EqyOq2rCDTfVcbgXQe3IWG5rmwZktCyrPeTE9wa0FnoEkovMRI/SMTw== X-Received: by 10.98.4.195 with SMTP id 186mr345680pfe.98.1464766575261; Wed, 01 Jun 2016 00:36:15 -0700 (PDT) Received: from ox ([2601:641:c180:c600:adf2:ffc8:42b9:33e1]) by smtp.gmail.com with ESMTPSA id o1sm60071681pax.24.2016.06.01.00.36.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Jun 2016 00:36:14 -0700 (PDT) Date: Wed, 1 Jun 2016 00:36:12 -0700 From: Navdeep Parhar To: Mark Millard Cc: FreeBSD Current Subject: Re: 11.0 -r300944 build*KERNEL* via amd64-gcc fails for: .../dev/cxgb/ulp/tom/cxgb_listen.c:926:13: error: redundant redeclaration of 'tcp_dooptions'; cxgbe has an issue too Message-ID: <20160601073612.GB4400@ox> Mail-Followup-To: Mark Millard , FreeBSD Current References: <1885ED2D-29CB-47EF-B746-7CAD52E91605@dsl-only.net> <086B90E6-2E0C-4AA9-B429-523685EF1459@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <086B90E6-2E0C-4AA9-B429-523685EF1459@dsl-only.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 07:36:16 -0000 On Tue, May 31, 2016 at 10:49:29PM -0700, Mark Millard wrote: > On 2016-May-31, at 10:31 PM, Mark Millard wrote: > > > If the offending declaration in cxgb_listen.c is commented out (or removed) > there is a "next problem" but for cxgbe: > > > --- all_subdir_cxgbe/tom --- > > /usr/src/sys/modules/cxgbe/tom/../../../dev/cxgbe/tom/t4_listen.c: In function 'do_pass_accept_req': > > /usr/src/sys/modules/cxgbe/tom/../../../dev/cxgbe/tom/t4_listen.c:640:1: warning: inlining failed in call to 'release_synqe': call is unlikely and code size would grow [-Winline] Can you try removing the "inline" at line 639 in t4_listen.c and see if that makes a difference? Regards, Navdeep From owner-freebsd-current@freebsd.org Wed Jun 1 08:54: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 9058EB55E22 for ; Wed, 1 Jun 2016 08:54:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-190.reflexion.net [208.70.211.190]) (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 43AB91320 for ; Wed, 1 Jun 2016 08:54:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5546 invoked from network); 1 Jun 2016 08:54:24 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 1 Jun 2016 08:54:24 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Wed, 01 Jun 2016 04:53:58 -0400 (EDT) Received: (qmail 2060 invoked from network); 1 Jun 2016 08:53:58 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 1 Jun 2016 08:53:58 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 70EB61C43E2; Wed, 1 Jun 2016 01:53:52 -0700 (PDT) Subject: Re: 11.0 -r300944 build*KERNEL* via amd64-gcc fails for: .../dev/cxgb/ulp/tom/cxgb_listen.c:926:13: error: redundant redeclaration of 'tcp_dooptions'; cxgbe has an issue too Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=us-ascii From: Mark Millard In-Reply-To: <20160601073612.GB4400@ox> Date: Wed, 1 Jun 2016 01:53:52 -0700 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <0090BCEC-2937-42EC-B875-A06018BEB55D@dsl-only.net> References: <1885ED2D-29CB-47EF-B746-7CAD52E91605@dsl-only.net> <086B90E6-2E0C-4AA9-B429-523685EF1459@dsl-only.net> <20160601073612.GB4400@ox> To: Navdeep Parhar X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 08:54:01 -0000 On 2016-Jun-1, at 12:36 AM, Navdeep Parhar wrote: > On Tue, May 31, 2016 at 10:49:29PM -0700, Mark Millard wrote: >> On 2016-May-31, at 10:31 PM, Mark Millard = wrote: >>=20 > >>=20 >> If the offending declaration in cxgb_listen.c is commented out (or = removed) >> there is a "next problem" but for cxgbe: >>=20 >>> --- all_subdir_cxgbe/tom --- >>> /usr/src/sys/modules/cxgbe/tom/../../../dev/cxgbe/tom/t4_listen.c: = In function 'do_pass_accept_req': >>> = /usr/src/sys/modules/cxgbe/tom/../../../dev/cxgbe/tom/t4_listen.c:640:1: = warning: inlining failed in call to 'release_synqe': call is unlikely = and code size would grow [-Winline] >=20 > Can you try removing the "inline" at line 639 in t4_listen.c and see = if that > makes a difference? >=20 > Regards, > Navdeep I tried commenting out the inline. Looks like cxgbe code has the same sort of redundant declaration problem = as cxgb code: > --- t4_listen.o --- > = /usr/src/sys/modules/cxgbe/tom/../../../dev/cxgbe/tom/t4_listen.c:669:13: = error: redundant redeclaration of 'tcp_dooptions' = [-Werror=3Dredundant-decls] > extern void tcp_dooptions(struct tcpopt *, u_char *, int, int); > ^ > In file included from = /usr/src/sys/modules/cxgbe/tom/../../../dev/cxgbe/tom/t4_listen.c:61:0: > /usr/src/sys/netinet/tcp_var.h:769:7: note: previous declaration of = 'tcp_dooptions' was here > void tcp_dooptions(struct tcpopt *, u_char *, int, int); > ^ . . . > --- t4_listen.o --- > cc1: all warnings being treated as errors > *** [t4_listen.o] Error code 1 Commenting that out as well lead to a failure in a very different area = of code: > --- all_subdir_drm2/i915kms --- > In file included from = /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_drv.h:31:0,= > from = /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/dvo.h:35, > from = /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/dvo_ch7xxx.c:32: > /usr/src/sys/dev/drm2/i915/i915_drv.h:1621:6: error: redundant = redeclaration of 'i915_gem_dump_object' [-Werror=3Dredundant-decls] > void i915_gem_dump_object(struct drm_i915_gem_object *obj, int len, > ^ > /usr/src/sys/dev/drm2/i915/i915_drv.h:1612:6: note: previous = declaration of 'i915_gem_dump_object' was here > void i915_gem_dump_object(struct drm_i915_gem_object *obj, int len, > ^ > In file included from = /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/dvo.h:35:0, > from = /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/dvo_ch7xxx.c:32: > = /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_drv.h:671:1= 3: error: redundant redeclaration of 'intel_fbc_enabled' = [-Werror=3Dredundant-decls] > extern bool intel_fbc_enabled(struct drm_device *dev); > ^ > In file included from = /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_drv.h:31:0,= > from = /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/dvo.h:35, > from = /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/dvo_ch7xxx.c:32: > /usr/src/sys/dev/drm2/i915/i915_drv.h:1676:13: note: previous = declaration of 'intel_fbc_enabled' was here > extern bool intel_fbc_enabled(struct drm_device *dev); > ^ . . . > --- all_subdir_drm2 --- > cc1: all warnings being treated as errors > *** [dvo_ch7xxx.o] Error code 1 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Wed Jun 1 13:11: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 D5760B60B61 for ; Wed, 1 Jun 2016 13:11:34 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id BCF9513B6 for ; Wed, 1 Jun 2016 13:11:34 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mailman.ysv.freebsd.org (Postfix) id BC329B60B60; Wed, 1 Jun 2016 13:11:34 +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 B9898B60B5F for ; Wed, 1 Jun 2016 13:11:34 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f50.google.com (mail-lf0-f50.google.com [209.85.215.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4984913B4 for ; Wed, 1 Jun 2016 13:11:33 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lf0-f50.google.com with SMTP id k98so12542941lfi.1 for ; Wed, 01 Jun 2016 06:11:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=KQsZepwSTW9zoaPw7VHqGj56ZqAN4dT7FGf+gzoaa7Y=; b=K//Hq+q+bR0WRD85gggTHnxOY2eI9aXIZLucypZBy+Yc5sNBAHdVmV3Pbun3aWVPDr lh0PWXySabR/NZqVPls4RjQcLFP9DRVRdpWWdXSIj3HB+YpiKP9hnsXTsUKiykDPF4kP wjs5Iy2O3fPk5B4JPrK64xLSoXko6snA4jTkeStsVvj4UiJROvGim7nv36rDUp6L+EaA z2QCKbSt1ssSaJxYzeFRseUvhn3oSxBsbGitH26VV3NgjMfclMQEH9EZXxPO1cyxLrxT MNx+tJA3z+GpBbQbFPdBC3wINrCOV+IttwTU4bR6j2LEeR0Dk3bQSiznJyEwHoZkb5D2 l1ZA== X-Gm-Message-State: ALyK8tJw3VlP0d/IIWpJLqBdLvOeYs5TzBuBeujc8FdjzVeVzQ9S760cFGLdpzIC0jsO/A== X-Received: by 10.25.39.75 with SMTP id n72mr1733319lfn.91.1464786691663; Wed, 01 Jun 2016 06:11:31 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id 9sm764319lff.42.2016.06.01.06.11.30 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2016 06:11:31 -0700 (PDT) To: current@freebsd.org From: Andrey Chernov Subject: 'make depend' or 'make' bug on recent --current Message-ID: <092f5e98-dae8-dbc9-2a6e-7068b972278f@freebsd.org> Date: Wed, 1 Jun 2016 16:11:30 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 13:11:34 -0000 Steps to reproduce: cd /usr/src/lib/libc/stdlib touch *div*.c cd .. make depend make And see how imaxdiv.o only is recompiled. No div.o ldiv.o lldiv.o are recompiled. P.S. new make depend is simple disgusting. It tends to recompile everything in the system if some minor header file is touched, but completely forget to recompile source code changes. I suggest to back out all AI in that area. 'make depend' is not time-consuming task and good old way never made mistakes. From owner-freebsd-current@freebsd.org Wed Jun 1 15: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 05B43B610BD; Wed, 1 Jun 2016 15:20:13 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id DEB161893; Wed, 1 Jun 2016 15:20:12 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id D1F051CA5; Wed, 1 Jun 2016 15:20:12 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 98E1678B3; Wed, 1 Jun 2016 15:20:12 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id ZXNGl3KG8u4q; Wed, 1 Jun 2016 15:20:09 +0000 (UTC) Subject: Re: [CFT] WITH_META_MODE: Working incremental build [only on i386 and amd64] DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 6D1117851 To: Mark Millard , FreeBSD Current References: Cc: FreeBSD PowerPC ML , freebsd-arm From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <7748cc71-3788-22ae-fcb2-699eae529310@FreeBSD.org> Date: Wed, 1 Jun 2016 08:20:01 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MhaiRRG7KqV7nV4OBOmPR6Or5KQH8AphX" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 15:20:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MhaiRRG7KqV7nV4OBOmPR6Or5KQH8AphX Content-Type: multipart/mixed; boundary="efn7WqpkSn21QmU89igjEUlwG5g9FskmI" From: Bryan Drewery To: Mark Millard , FreeBSD Current Cc: FreeBSD PowerPC ML , freebsd-arm Message-ID: <7748cc71-3788-22ae-fcb2-699eae529310@FreeBSD.org> Subject: Re: [CFT] WITH_META_MODE: Working incremental build [only on i386 and amd64] References: In-Reply-To: --efn7WqpkSn21QmU89igjEUlwG5g9FskmI Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 5/29/2016 3:53 PM, Mark Millard wrote: > Quoting the original note about WITH_META_MODE ( https://lists.freebsd.= org/pipermail/freebsd-current/2016-May/061481.html ): >=20 >> You will also need to load the filemon(4) module with 'kldload filemon= '. >=20 > But head's sys/modules/Makefile says: >=20 >> .if defined(MODULES_OVERRIDE) && !defined(ALL_MODULES) >> SUBDIR=3D${MODULES_OVERRIDE} >> .else >> SUBDIR=3D \ >=20 > . . . >> ${_filemon} \ >=20 > . . . >> .if ${MACHINE_CPUARCH} =3D=3D "i386" || ${MACHINE_CPUARCH} =3D=3D "amd= 64" > . . . >> _filemon=3D filemon > . . . >=20 > as the only contexts that provide a filemon.ko to use with kldload. >=20 > Thus, for example, arm variants (32 bit and 64 bit) and powerpc variant= s (32bit and 64 bit) do not have WITH_META_MODE as an option as things ar= e set up. >=20 > I had been hoping to cut down on the time for clang-related rebuilds du= ring native buildworld runs on my slower buildworld contexts (armv7a/cort= ex-a7, powerpc, powerpc64). But it was not to be. >=20 > It appears that, once some arm variants are officially tier 1, WITH_MET= A_MODE will not span all tier 1 platforms. >=20 > [Since I tend to use non-tier-1 platforms I tend to notice some of the = statements about FreeBSD that are true of only tier 1 without being expli= cit about it. But initially it takes some research to discover that statu= s for each such point. WITH_META_MODE is an example.] >=20 I've just enabled the filemon(4) build on all architectures in r301130. --=20 Regards, Bryan Drewery --efn7WqpkSn21QmU89igjEUlwG5g9FskmI-- --MhaiRRG7KqV7nV4OBOmPR6Or5KQH8AphX 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 iQEcBAEBAgAGBQJXTv0nAAoJEDXXcbtuRpfPZxwH/i2GLWdM+/S1aUwg9Z5MZDT8 nlntlziN1Fugy/63L/CxgOC3E9ozWkr3eoToZqgkbREITaL/IdKnEjQQBaZI7KUT dNrfhKpmkCoeomx60+sFPfxVp+rpXTa2DAAwB8yoB3AqF4Hcwfsp1SQOqujiKa01 580svdN9P4pPEc8TBbk9ww5d4QvIRTTDaQ3olQE9oapVS/iL6QsyVMRgWY4p0WxO uyuVKuiJzmJdq86f93HAZN30srwBqb8UG52aegVuDCe1GPOBlFWA1fhuhrL3cAwu CAxJLs1bUmqFoJJUD0HlLtNX2FCihflz4P68tAbhhf9eDPLRjasMLzADUGWaNx0= =5kmo -----END PGP SIGNATURE----- --MhaiRRG7KqV7nV4OBOmPR6Or5KQH8AphX-- From owner-freebsd-current@freebsd.org Wed Jun 1 15:45: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 88285B61B4B for ; Wed, 1 Jun 2016 15:45:26 +0000 (UTC) (envelope-from mitya@cabletv.dp.ua) Received: from mail.cabletv.dp.ua (mail.cabletv.dp.ua [193.34.20.8]) (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 4755213A2 for ; Wed, 1 Jun 2016 15:45:25 +0000 (UTC) (envelope-from mitya@cabletv.dp.ua) Received: from [193.34.20.2] (helo=m18.cabletv.dp.ua) by mail.cabletv.dp.ua with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1b880L-000B24-Vb for freebsd-current@freebsd.org; Wed, 01 Jun 2016 18:24:21 +0300 To: freebsd-current@freebsd.org From: Mitya Subject: kernel panic Message-ID: Date: Wed, 1 Jun 2016 18:20:33 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 01 Jun 2016 16:06:53 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 15:45:26 -0000 Hi. I compile FreeBSD-CURRENT at 30 may and my server is not loading http://s33.postimg.org/5e1rk1lbz/20160531_123419.jpg Today, I fetch fresh sources and compile kernel again Server has loaded, but after some time I get kernel panic http://postimg.org/image/r78vxopkb/ http://postimg.org/image/7rtza7nu3/ http://postimg.org/image/adtblz97v/ From owner-freebsd-current@freebsd.org Wed Jun 1 16:30:07 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6E6E5B619AA for ; Wed, 1 Jun 2016 16:30:07 +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 4C6EF19AA for ; Wed, 1 Jun 2016 16:30:07 +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 621E6B977; Wed, 1 Jun 2016 12:30:06 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org, Konstantin Belousov Subject: Re: Unable to load freshly-built nvidia.ko @r300994. Date: Wed, 01 Jun 2016 09:21:38 -0700 Message-ID: <8607493.AginXhE5HD@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20160530185227.GZ1080@albert.catwhisker.org> References: <20160530123654.GW1080@albert.catwhisker.org> <20160530160342.GW38613@kib.kiev.ua> <20160530185227.GZ1080@albert.catwhisker.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, 01 Jun 2016 12:30:06 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 16:30:07 -0000 On Monday, May 30, 2016 11:52:27 AM David Wolfskill wrote: > On Mon, May 30, 2016 at 07:03:42PM +0300, Konstantin Belousov wrote: > > ... > > > May 30 11:29:31 g1-252 root: /etc/rc: WARNING: Unable to load kernel module linux64 > > > May 30 11:29:31 g1-252 kernel: KLD linux64.ko: depends on kernel - not available or version mismatch > > > May 30 11:29:31 g1-252 kernel: linker_load_file: Unsupported file type > > > > Your kernel was built from older sources than you used to build the nvidia > > module. I mean, the kernel headers used for the module build where > > updated comparing with binaries that are installed into /boot/kernel. > > Hmmm... I'm ... unlcear ... on how that could have happened. > > I've copied the typescript (from the build) to > http://www.catwhisker.org/~david/FreeBSD/head/typescript_r300994; the > "_bw" alias (ultimately) expands to: > > setenv TMPDIR /tmp && \ > id && \ > mount && \ > cd /usr/src && \ > uname -a && \ > date && \ > make -j16 buildworld && \ > date && \ > make -j16 buildkernel && \ > date && \ > rm -fr /boot/modules.old && \ > cp -pr /boot/modules{,.old} && \ > make installkernel && \ > date && \ > pushd /usr/ports && \ > pushd x11/nvidia-driver && \ > make clean ; popd ; popd && \ > date && \ > mergemaster -U -u 0022 -p && \ > date && \ > rm -fr /usr/include.old && \ > date && \ > mv /usr/include{,.old} && \ > date && \ > rm -fr /usr/share/man && \ > date && \ > make installworld && \ > date && \ > mergemaster -F -U -u 0022 -i && \ > date && \ > make delete-old && \ > date && \ > df -k Just as a followup, this sequeunce will result in the nvidia-drier always being stale. You have to build the nvidia-driver after installworld for it to use up-to-date kernel headers (installkernel only installs the kernel and modules, it does not update the headers in /usr/include). -- John Baldwin From owner-freebsd-current@freebsd.org Wed Jun 1 17:01: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 4166FB611C2 for ; Wed, 1 Jun 2016 17:01:12 +0000 (UTC) (envelope-from mikej@mikej.com) Received: from mx2.paymentallianceintl.com (mx2.paymentallianceintl.com [216.26.158.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx2.paymentallianceintl.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0D4BC12ED for ; Wed, 1 Jun 2016 17:01:11 +0000 (UTC) (envelope-from mikej@mikej.com) Received: from firewall.mikej.com (f [162.230.214.65]) by mx2.paymentallianceintl.com (8.15.1/8.15.1) with ESMTPS id u51GbqhJ009356 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 1 Jun 2016 12:37:53 -0400 (EDT) (envelope-from mikej@mikej.com) X-Authentication-Warning: mx2.paymentallianceintl.com: Host f [162.230.214.65] claimed to be firewall.mikej.com Received: from mail.mikej.com (firewall.mikej.com [192.168.6.63]) by firewall.mikej.com (8.15.2/8.15.2) with ESMTP id u51GbpKa088118 for ; Wed, 1 Jun 2016 12:37:51 -0400 (EDT) (envelope-from mikej@mikej.com) DMARC-Filter: OpenDMARC Filter v1.3.1 firewall.mikej.com u51GbpKa088118 Authentication-Results: mail.mikej.com; dmarc=none header.from=mikej.com DKIM-Filter: OpenDKIM Filter v2.10.3 firewall.mikej.com u51GbpKa088118 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mikej.com; s=mail; t=1464799071; bh=vg9PWJ/WCL+Mpbp27VdjLqx5qLBz2G7z60jmGefwJoM=; h=Date:From:To:Subject; b=mAFmZnk+5yvMnoG7XD390St0R9EBfh+6IE0VQrNGTPmlL6QAYP8eDZ9S3d+08JYUq GDk1Imc5okmcA5VMBNm6uizYr2YARaeLsKqlMiLwsLHvvzhp5Rx2rrIZ8Qq3/WOtXV m+M2FIuUL82fNGKA4M9uaJXDqleVwlyfW50yTMFOzGo4EczUZ5L9gJyEYkpZEBjzdY C6KUqV7m5w1AY8PPImEmfGr9OO5eE8UCPhlZQqRCJhJnf/vwz/mqpC4PxgRVEhfqXm je123L9Tg3+Hk49Hi4D0RRoiOEQFo/qe7BsZOawxCKvbLoZxIduUdUgByTNjnju3G6 DBosp+SWrNMTg== X-Authentication-Warning: firewall.mikej.com: Host firewall.mikej.com [192.168.6.63] claimed to be mail.mikej.com MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 01 Jun 2016 12:37:51 -0400 From: Michael Jung To: freebsd-current@freebsd.org Subject: head r30140 - Panic String: _mtx_lock_sleep: recursed on non-recursive mutex vm page @ /usr/src/sys/vm/vm_page.c:774 Message-ID: <96b9a1271d057fb8b67696623a6263c5@mail.mikej.com> X-Sender: mikej@mikej.com User-Agent: Roundcube Webmail/1.1.5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 17:01:12 -0000 Since upgrading to head r301040 I have started to get the above panic while running poudriere while building packages for 10.3-STABLE r301107. Unfortuately I can't tell you the previous version of head but it was from some months ago. https://charon.gopai.com/core.txt.7 https://charon.gopai.com/info.7 I also have the full core file if needed. Let me know what else I can provide. Thank you. From owner-freebsd-current@freebsd.org Wed Jun 1 17:27: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 7F502B61BD8 for ; Wed, 1 Jun 2016 17:27:24 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 5FF2C1C60 for ; Wed, 1 Jun 2016 17:27:24 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 5F3DDB61BD7; Wed, 1 Jun 2016 17:27:24 +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 5EE39B61BD6 for ; Wed, 1 Jun 2016 17:27:24 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 44D031C5F; Wed, 1 Jun 2016 17:27:24 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 3E89D14F8; Wed, 1 Jun 2016 17:27:24 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id F234D7E40; Wed, 1 Jun 2016 17:27:23 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id uD7YmqUJK9F3; Wed, 1 Jun 2016 17:27:21 +0000 (UTC) Subject: Re: [CFT] WITH_META_MODE: Working incremental build DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 6403C7E3A To: "Simon J. Gerraty" References: <20160531140608.GA24894@albert.catwhisker.org> <5c2283ef-def0-1bdd-4766-0d2a901e7580@FreeBSD.org> <48166.1464740223@kaos.jnpr.net> Cc: current@freebsd.org From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: Date: Wed, 1 Jun 2016 10:27:20 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <48166.1464740223@kaos.jnpr.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ewN246aJVPsSftjTN5JvQH6EMkl6JLX21" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 17:27:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ewN246aJVPsSftjTN5JvQH6EMkl6JLX21 Content-Type: multipart/mixed; boundary="UGKg3xHaFJi65VSKRsSssFCFSC6oojhDK" From: Bryan Drewery To: "Simon J. Gerraty" Cc: current@freebsd.org Message-ID: Subject: Re: [CFT] WITH_META_MODE: Working incremental build References: <20160531140608.GA24894@albert.catwhisker.org> <5c2283ef-def0-1bdd-4766-0d2a901e7580@FreeBSD.org> <48166.1464740223@kaos.jnpr.net> In-Reply-To: <48166.1464740223@kaos.jnpr.net> --UGKg3xHaFJi65VSKRsSssFCFSC6oojhDK Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 5/31/2016 5:17 PM, Simon J. Gerraty wrote: >> Another reported issue just now is that right after an installworld, >> everything rebuilds due to changed /bin/sh (-dM flag to make tells you= >> why things rebuild). I'll look into some mitigations for this. >=20 > It is probably sufficient to just add >=20 > .MAKE.META.IGNORE_PATHS +=3D ${__MAKE_SHELL} >=20 Yes but I need to test it fully to see if things like rtld and libmap.conf, etc, get caught up in the problem too. --=20 Regards, Bryan Drewery --UGKg3xHaFJi65VSKRsSssFCFSC6oojhDK-- --ewN246aJVPsSftjTN5JvQH6EMkl6JLX21 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 iQEcBAEBAgAGBQJXTxr4AAoJEDXXcbtuRpfP1ngH/38P2umXQRE6giWXdJOxJX7o yyoHWZUKxIYNdLvM9bxCWPTSzK9NPd0RMMG1rdUS99NVUyjGSQ59Z1J364q6RLls FEfzehLogrJzCijEKLsoAmspWWx7FYP/YG0CgDozd6TLtTKa8lkEMmDv9ZebnRwp DP3b1BxG4lMDgTBbGtCcTo8fSiz4IoGciYgx6lmh/b5B3yspvk38+v9rpzex8/gD asIEHcA+bJgo5OAOcltIFVecauEuWBYQzL6JBpOGxypIaoVDTIsGxJJhnpskCmYG Gyu3lEcYuAAvGE9FJc8asrf8GpOq6inlYmAp/WgNYYoZrwLlqc4mj+ZF1pA8BO8= =nzYK -----END PGP SIGNATURE----- --ewN246aJVPsSftjTN5JvQH6EMkl6JLX21-- From owner-freebsd-current@freebsd.org Wed Jun 1 18:19:04 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3165B61C27 for ; Wed, 1 Jun 2016 18:19:04 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 883011A17 for ; Wed, 1 Jun 2016 18:19:04 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 83927B61C26; Wed, 1 Jun 2016 18:19:04 +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 83330B61C25 for ; Wed, 1 Jun 2016 18:19:04 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 6CABE1A16; Wed, 1 Jun 2016 18:19:04 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 6610B1D66; Wed, 1 Jun 2016 18:19:04 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 1FAB71D02A; Wed, 1 Jun 2016 18:19:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id nUpr9B7JbJsN; Wed, 1 Jun 2016 18:18:57 +0000 (UTC) Subject: Re: 'make depend' or 'make' bug on recent --current DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 95C3D1D023 To: Andrey Chernov , current@freebsd.org References: <092f5e98-dae8-dbc9-2a6e-7068b972278f@freebsd.org> From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <311f3a82-b702-d375-170f-82ae39236ab0@FreeBSD.org> Date: Wed, 1 Jun 2016 11:18:56 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <092f5e98-dae8-dbc9-2a6e-7068b972278f@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eLVmTIGcVAkkbkiFnug92E23PGujPS5Uh" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 18:19:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eLVmTIGcVAkkbkiFnug92E23PGujPS5Uh Content-Type: multipart/mixed; boundary="ooFp2tckfnjxV8Lftt0vcltN3iCiV1gcB" From: Bryan Drewery To: Andrey Chernov , current@freebsd.org Message-ID: <311f3a82-b702-d375-170f-82ae39236ab0@FreeBSD.org> Subject: Re: 'make depend' or 'make' bug on recent --current References: <092f5e98-dae8-dbc9-2a6e-7068b972278f@freebsd.org> In-Reply-To: <092f5e98-dae8-dbc9-2a6e-7068b972278f@freebsd.org> --ooFp2tckfnjxV8Lftt0vcltN3iCiV1gcB Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 6/1/2016 6:11 AM, Andrey Chernov wrote: > Steps to reproduce: >=20 > cd /usr/src/lib/libc/stdlib > touch *div*.c > cd .. > make depend > make >=20 > And see how imaxdiv.o only is recompiled. > No div.o ldiv.o lldiv.o are recompiled. My dev system is busy at the moment. I'll test it and get back to you. >=20 > P.S. new make depend is simple disgusting. It tends to recompile > everything in the system if some minor header file is touched, but If the header is used by all source files then that is expected. However if you do not have a .depend.obj.o file then it is quite aggressive with building. If you touch any header it will rebuild everything. But you shouldn't get into that situation unless you rm -f =2Edepend* first. > completely forget to recompile source code changes. I suggest to back > out all AI in that area. > 'make depend' is not time-consuming task and good old way never made > mistakes. The graph in the original commit for WITH_FAST_DEPEND disagrees. https://svnweb.freebsd.org/base?view=3Drevision&revision=3D290433 We run the preprocessor once now, not twice. --=20 Regards, Bryan Drewery --ooFp2tckfnjxV8Lftt0vcltN3iCiV1gcB-- --eLVmTIGcVAkkbkiFnug92E23PGujPS5Uh 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 iQEcBAEBAgAGBQJXTycQAAoJEDXXcbtuRpfP5eAH+wet3DUxJhrCFcK1UOJaJMTy UTL+zH8D8FaYIDJDdmqhg5yhIDY+XHfSjitfNWTeqER+2N3er9TBX2V/Ej7EUtMl ytchGZqsYRtxM/P9ksUZLWv8XNEgDPdU7VQhMSoSedDVpg9BmdNRWRpfuF0jRIrI rOAhcPh/6eHBXguMnoaikSvseWW9N5HM4HvBhdPT0vEkpVR7YaknS6wwYN6kiSIm GYJt08FVgJU0xAgetJXOq4NbFnL52Ec0QMuXqm/j2JSYS7RbxGpl9I+uxmt7ERdJ XTYGtja35DI5N8N4aCFjkQaVEI0RfA8z5sTD7TPVdn6mFg9rvgnY37Ho1z7Ck+I= =xK2L -----END PGP SIGNATURE----- --eLVmTIGcVAkkbkiFnug92E23PGujPS5Uh-- From owner-freebsd-current@freebsd.org Wed Jun 1 18:43: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 B0D0BB611CA for ; Wed, 1 Jun 2016 18:43:51 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3A8EE196F; Wed, 1 Jun 2016 18:43:51 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-wm0-x242.google.com with SMTP id q62so9273756wmg.3; Wed, 01 Jun 2016 11:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=hkDCEJdLMGBs2LhM7ZieNoheq6jE2idUZwFaE77VUg0=; b=XEN+6JXMYehT2TZrnHd3wEaEjrvEIxFgbz4bKuJLQxOEoosGvfhlHdtTm9HNjJ8cn8 dKFIkkdJhaNRY07sHFWEP0DhtZ1WWlP3gecqD4Kg8KLHrX63Qy4Bv+f1OSun+rDDVGPE KQi16eo8XGyAmF477MjmW2fee6sJAi6HZfwy9IEVyAxgcWH/0lMSWzYaFAKKkBTioX12 P9PaH/bmJMAYiZsJAzk2mlqBcCShpvb3PRmk2rsXKOwLfYGGKEA63USeg93vPTKKWYCS 3MoLv8GwATm6clGxIqNaZwYcDBteECHDNGjehonug2fXH3qagfx2WwWqn0WkrVnEzrYC irww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=hkDCEJdLMGBs2LhM7ZieNoheq6jE2idUZwFaE77VUg0=; b=kz2G6xpsBaqboiLdoHQrzq5QaXdKPFuzsZ5bPEjjqIk+lfRtDaGP713aoNm8cH7i1D arcPmSTtXeWwCEs96ItK6714v71Xg82wVs9m3pXjr9qH3qCqQMlsVhIxKKtqoAwx1A8Y sDI8+Kscw3/f+zV4QznOXmqNUGCQuV5fMXr/mgJxNYJfk+5wKdGLPks9QWnCnwtWDmSs ZxQy3FLecRaXO5oCGCSHuauuoUimcBF3Dm+Lzb6mbDBCkfWnOlVydV4au5OBQ9Xrak3/ X1+rFEDIK1J8bA/gjiMjSi6u7a28qIG+JRtp2p2UIcml0sNTMBa7vJn3Okp6vrLoijoH UehA== X-Gm-Message-State: ALyK8tKdCXFLV2yqKDyyUQB6sDOvNofTKxwv2Dce3JBhRnrkj8J1cnXwYunz4K48WErUCw== X-Received: by 10.28.125.86 with SMTP id y83mr22090824wmc.8.1464806629407; Wed, 01 Jun 2016 11:43:49 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by smtp.gmail.com with ESMTPSA id c2sm36493101wme.4.2016.06.01.11.43.48 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Wed, 01 Jun 2016 11:43:48 -0700 (PDT) Date: Wed, 1 Jun 2016 20:43:46 +0200 From: Mateusz Guzik To: John Baldwin Cc: freebsd-current@freebsd.org Subject: Re: [PATCH] microoptimize locking primitives by avoiding unnecessary atomic ops Message-ID: <20160601184346.GA14712@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , John Baldwin , freebsd-current@freebsd.org References: <20160527191700.GA23039@dft-labs.eu> <1588845.bSUmdZtqRF@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1588845.bSUmdZtqRF@ralph.baldwin.cx> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 18:43:51 -0000 On Fri, May 27, 2016 at 04:21:11PM -0700, John Baldwin wrote: > On Friday, May 27, 2016 09:17:01 PM Mateusz Guzik wrote: > > Hello there, > > > > quite some time ago I posted a trivial patch to locking primitives. What > > they do is the inline part tries an atomic op and if that fails the > > actual function is called, which immediately tries the same op. > > > > The obvious optimisation checks for the availability of the lock first. > > > > There concerns about the way it was done previously by relying on > > volatile behaving in a specific way. > > > > Later a simplified version was posted which should not have the concern, > > but the thread died. > > > > I refer you to https://lists.freebsd.org/pipermail/freebsd-current/2015-November/058100.html > > for simple benchmark results. > > > > I would like to get the patch in before 11 freeze. > > I think this looks fine. Thanks for expanding the previous patch to cover > more primitives. > Thanks, committed in https://svnweb.freebsd.org/changeset/base/301157 -- Mateusz Guzik From owner-freebsd-current@freebsd.org Wed Jun 1 18:49: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 D2B93B61591 for ; Wed, 1 Jun 2016 18:49:59 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id B1A911D7B for ; Wed, 1 Jun 2016 18:49:59 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mailman.ysv.freebsd.org (Postfix) id AD294B61590; Wed, 1 Jun 2016 18:49: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 ACC85B6158F for ; Wed, 1 Jun 2016 18:49:59 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f52.google.com (mail-lf0-f52.google.com [209.85.215.52]) (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 461F91D7A for ; Wed, 1 Jun 2016 18:49:59 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lf0-f52.google.com with SMTP id k98so19068823lfi.1 for ; Wed, 01 Jun 2016 11:49:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=Hjqf4uFfO6cRx+KsdcAb4v9UIXXY3LNYPbM/EZMjWdc=; b=ULx9DKZdEcX1YQG6OgkuUE+37uGec+C8wxPYOejTOsC9p4tUljx2GfMuyAIoB1RqWj N6ucejiB1sYA6IrTZHVU4o16vob61I9yAWLN3xxW2OX+NjcSX0k7yCXKTbxWjE3063/b 7axjU9hv1ja8XH7RfjzaM67Zi77i8Bq/E0wPkOiRZPUDQQbRTj2X7Ez0UL6liXwvWCyJ rqxibsm4rBQZtypL/gBxi/hFCyeGkoq4TDzfsKYQzJ7rLhmmk4bX2sgL7DgO3mFsNeD7 PpoGJGI0L9Qabj54NnkAvE2BmV3j9tay5rss75nmk0SUHa6y9DNet7DWFnxOmiyk8g7z +Mzw== X-Gm-Message-State: ALyK8tKJUPu0W5sV7m/dVdJTjCOJkdC2MWF5GuxuK+oU+FeoJYiUGm/amw2IrtxZMTyjVw== X-Received: by 10.25.216.223 with SMTP id r92mr2589691lfi.122.1464806990836; Wed, 01 Jun 2016 11:49:50 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id j81sm3173431lfg.1.2016.06.01.11.49.49 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2016 11:49:50 -0700 (PDT) Subject: Re: 'make depend' or 'make' bug on recent --current To: Bryan Drewery , current@freebsd.org References: <092f5e98-dae8-dbc9-2a6e-7068b972278f@freebsd.org> <311f3a82-b702-d375-170f-82ae39236ab0@FreeBSD.org> From: Andrey Chernov Message-ID: Date: Wed, 1 Jun 2016 21:49:49 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <311f3a82-b702-d375-170f-82ae39236ab0@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8jNqIFH4PwimuQaBNpLe7tjQdW5s70omS" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 18:49:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8jNqIFH4PwimuQaBNpLe7tjQdW5s70omS Content-Type: multipart/mixed; boundary="nUMjutJv2e59cDmvHJ5GRn46pgaFPrVw6" From: Andrey Chernov To: Bryan Drewery , current@freebsd.org Message-ID: Subject: Re: 'make depend' or 'make' bug on recent --current References: <092f5e98-dae8-dbc9-2a6e-7068b972278f@freebsd.org> <311f3a82-b702-d375-170f-82ae39236ab0@FreeBSD.org> In-Reply-To: <311f3a82-b702-d375-170f-82ae39236ab0@FreeBSD.org> --nUMjutJv2e59cDmvHJ5GRn46pgaFPrVw6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 01.06.2016 21:18, Bryan Drewery wrote: > On 6/1/2016 6:11 AM, Andrey Chernov wrote: >> Steps to reproduce: >> >> cd /usr/src/lib/libc/stdlib >> touch *div*.c >> cd .. >> make depend >> make >> >> And see how imaxdiv.o only is recompiled. >> No div.o ldiv.o lldiv.o are recompiled. >=20 > My dev system is busy at the moment. I'll test it and get back to you. I need to add that I do 'make cleandepend/cleandir/cleanobj' + 'make obj' again and full rebuild with no old files, but the bug repeated again= =2E >> P.S. new make depend is simple disgusting. It tends to recompile >> everything in the system if some minor header file is touched, but >=20 > If the header is used by all source files then that is expected. >=20 > However if you do not have a .depend.obj.o file then it is quite > aggressive with building. If you touch any header it will rebuild > everything. But you shouldn't get into that situation unless you rm -f= > .depend* first. >=20 >> completely forget to recompile source code changes. I suggest to back >> out all AI in that area. >> 'make depend' is not time-consuming task and good old way never made >> mistakes. >=20 > The graph in the original commit for WITH_FAST_DEPEND disagrees. > https://svnweb.freebsd.org/base?view=3Drevision&revision=3D290433 >=20 > We run the preprocessor once now, not twice. It sounds good, just implemented bad. You measure some spherical chicken in vacuum, not what really happens. In the old times I almost never have clang libs rebuild (few files from there max when FreeBSD_version is increased), but now I got them fully rebuilt with any header change. That is the biggest slowdown and not what you try to measure. Don't ever use 'make world'. Try to rebuild the system incrementally and you'll see. --nUMjutJv2e59cDmvHJ5GRn46pgaFPrVw6-- --8jNqIFH4PwimuQaBNpLe7tjQdW5s70omS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXTy5NAAoJEKUckv0MjfbKNOcH/0kLuYNN+dkXiURb9E9fRZ+9 qfeyHOBIUxggqd20f01wpKZZtbjethI5FJgYpcus6gSMbz1kf1qmCi2Rd7byGaql 540am8ktwZ+lx/FlZ1uE88BbquB5dbyAs3ASFDCQavLOk+wgku4bAc47IhUBlrbm nbU8OHZ1gPXUO3Ctic1tibKPbBj9R33aNRbXpe3Jg9G7qaQNBQ/ZNi5KDRSgeS6C x2u5Ummu2UlR47ubeSHrDpTkdmeuoKGbjJIczzjr+EtRXsN1Ti9KPoj/3Fyzo4cx swNKS14BRRTubQqqomrXXBBhK8ivt7uog4/jonWGKGewPMqqtixtVqjdtlIB/6o= =gWVT -----END PGP SIGNATURE----- --8jNqIFH4PwimuQaBNpLe7tjQdW5s70omS-- From owner-freebsd-current@freebsd.org Wed Jun 1 19:35:27 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B6670B60168 for ; Wed, 1 Jun 2016 19:35:27 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-184.reflexion.net [208.70.211.184]) (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 645601765 for ; Wed, 1 Jun 2016 19:35:26 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1430 invoked from network); 1 Jun 2016 19:35:53 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 1 Jun 2016 19:35:53 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Wed, 01 Jun 2016 15:35:25 -0400 (EDT) Received: (qmail 28697 invoked from network); 1 Jun 2016 19:35:25 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 1 Jun 2016 19:35:25 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 510331C43E6; Wed, 1 Jun 2016 12:35:16 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Jun 2016 12:35:19 -0700 Subject: amd64 11.0 -r301139 installworld (WITH_META_MODE=yes) fails for "Unable to determine compiler type" To: Bryan Drewery , FreeBSD Current Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 19:35:27 -0000 Context: amd64 building for amd64 starting from: > # uname -apKU > FreeBSD FreeBSDx64 11.0-ALPHA1 FreeBSD 11.0-ALPHA1 #29 r300944M: Sun = May 29 14:39:47 PDT 2016 = markmi@FreeBSDx64:/usr/obj/clang/amd64.amd64/usr/src/sys/GENERIC-NODEBUG = amd64 amd64 1100114 1100114 After a successful WITH_META_MODE=3Dyes buildworld buildkernel sequence = and then installkernel sequence: installworld then failed with . . . > # = ~/sys_build_scripts.amd64-host/make_amd64_nodebug_clang_bootstrap-amd64-ho= st.sh installworld > Script started, output file is = /root/sys_typescripts/typescript_make_amd64_nodebug_clang_bootstrap-amd64-= host-2016-06-01:12:13:05 > mkdir -p /tmp/install.JwZJ3f9P > progs=3D$(for prog in [ awk cap_mkdb cat chflags chmod chown cmp cp = date echo egrep find grep id install ln make mkdir mtree mv pwd_mkdb = rm sed services_mkdb sh strip sysctl test true uname wc zic tzsetup = makewhatis; do if progpath=3D`which $prog`; then echo $progpath; else = echo "Required tool $prog not found in PATH." >&2; exit 1; fi; = done); libs=3D$(ldd -f "%o %p\n" -f "%o %p\n" $progs 2>/dev/null | sort = -u | while read line; do set -- $line; if [ "$2 $3" !=3D "not found" = ]; then echo $2; else echo "Required library $1 not found." >&2; = exit 1; fi; done); cp $libs $progs /tmp/install.JwZJ3f9P > cp -R ${PATH_LOCALE:-"/usr/share/locale"} /tmp/install.JwZJ3f9P/locale > cd /usr/src; MAKEOBJDIRPREFIX=3D/usr/obj/clang/amd64.amd64 = MACHINE_ARCH=3Damd64 MACHINE=3Damd64 CPUTYPE=3D = GROFF_BIN_PATH=3D/usr/obj/clang/amd64.amd64/usr/src/tmp/legacy/usr/bin = GROFF_FONT_PATH=3D/usr/obj/clang/amd64.amd64/usr/src/tmp/legacy/usr/share/= groff_font = GROFF_TMAC_PATH=3D/usr/obj/clang/amd64.amd64/usr/src/tmp/legacy/usr/share/= tmac CC=3D"cc -target x86_64-unknown-freebsd11.0 = --sysroot=3D/usr/obj/clang/amd64.amd64/usr/src/tmp = -B/usr/obj/clang/amd64.amd64/usr/src/tmp/usr/bin" CXX=3D"c++ -target = x86_64-unknown-freebsd11.0 = --sysroot=3D/usr/obj/clang/amd64.amd64/usr/src/tmp = -B/usr/obj/clang/amd64.amd64/usr/src/tmp/usr/bin" CPP=3D"cpp -target = x86_64-unknown-freebsd11.0 = --sysroot=3D/usr/obj/clang/amd64.amd64/usr/src/tmp = -B/usr/obj/clang/amd64.amd64/usr/src/tmp/usr/bin" AS=3D"as" AR=3D"ar" = LD=3D"ld" NM=3Dnm OBJDUMP=3Dobjdump OBJCOPY=3D"objcopy" RANLIB=3Dranlib = STRINGS=3D SIZE=3D"size" = PATH=3D/usr/obj/clang/amd64.amd64/usr/src/tmp/legacy/usr/sbin:/usr/obj/cla= ng/amd64.amd64/usr/src/tmp/legacy/usr/bin:/usr/obj/clang/amd64.amd64/usr/s= rc/tmp/legacy/bin:/usr/obj/clang/amd64.amd64/usr/src/tmp/usr/sbin:/usr/obj= /clang/amd64.amd64/usr/src/tmp/usr/bin:/tmp/install.JwZJ3f9P = LD_LIBRARY_PATH=3D/tmp/install.JwZJ3f9P = PATH_LOCALE=3D/tmp/install.JwZJ3f9P/locale make -f Makefile.inc1 = __MAKE_SHELL=3D/tmp/install.JwZJ3f9P/sh reinstall; = MAKEOBJDIRPREFIX=3D/usr/obj/clang/amd64.amd64 MACHINE_ARCH=3Damd64 = MACHINE=3Damd64 CPUTYPE=3D = GROFF_BIN_PATH=3D/usr/obj/clang/amd64.amd64/usr/src/tmp/legacy/usr/bin = GROFF_FONT_PATH=3D/usr/obj/clang/amd64.amd64/usr/src/tmp/legacy/usr/share/= groff_font = GROFF_TMAC_PATH=3D/usr/obj/clang/amd64.amd64/usr/src/tmp/legacy/usr/share/= tmac CC=3D"cc -target x86_64-unknown-freebsd11.0 = --sysroot=3D/usr/obj/clang/amd64.amd64/usr/src/tmp = -B/usr/obj/clang/amd64.amd64/usr/src/tmp/usr/bin" CXX=3D"c++ -target = x86_64-unknown-freebsd11.0 = --sysroot=3D/usr/obj/clang/amd64.amd64/usr/src/tmp = -B/usr/obj/clang/amd64.amd64/usr/src/tmp/usr/bin" CPP=3D"cpp -target = x86_64-unknown-freebsd11.0 = --sysroot=3D/usr/obj/clang/amd64.amd64/usr/src/tmp = -B/usr/obj/clang/amd64.amd64/usr/src/tmp/usr/bin" AS=3D"as" AR=3D"ar" = LD=3D"ld" NM=3Dnm OBJDUMP=3Dobjdump OBJCOPY=3D"objcopy" RANLIB=3Dranlib = STRINGS=3D SIZE=3D"size" = PATH=3D/usr/obj/clang/amd64.amd64/usr/src/tmp/legacy/usr/sbin:/usr/obj/cla= ng/amd64.amd64/usr/src/tmp/legacy/usr/bin:/usr/obj/clang/amd64.amd64/usr/s= rc/tmp/legacy/bin:/usr/obj/clang/amd64.amd64/usr/src/tmp/usr/sbin:/usr/obj= /clang/amd64.amd64/usr/src/tmp/usr/bin:/tmp/install.JwZJ3f9P = LD_LIBRARY_PATH=3D/tmp/install.JwZJ3f9P = PATH_LOCALE=3D/tmp/install.JwZJ3f9P/locale rm -rf /tmp/install.JwZJ3f9P > sh: cc: not found > make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 142: Unable to = determine compiler type for CC=3Dcc -target x86_64-unknown-freebsd11.0 = --sysroot=3D/usr/obj/clang/amd64.amd64/usr/src/tmp = -B/usr/obj/clang/amd64.amd64/usr/src/tmp/usr/bin. Consider setting = COMPILER_TYPE. > *** Error code 1 >=20 > Stop. > make[1]: stopped in /usr/src > *** Error code 1 >=20 > Stop. > make: stopped in /usr/src >=20 > Script done, output file is = /root/sys_typescripts/typescript_make_amd64_nodebug_clang_bootstrap-amd64-= host-2016-06-01:12:13:05 (I do not know if WITH_META_MODE=3Dyes matters here or not. = WITH_META_MODE=3Dyes was supplied the the script that I used.) make.conf was: CFLAGS.gcc+=3D -v (so effectively empty for clang use). src.conf was: TO_TYPE=3Damd64 # KERNCONF=3DGENERIC-NODEBUG TARGET=3D${TO_TYPE} .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITHOUT_CROSS_COMPILER=3D WITH_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITH_BINUTILS_BOOTSTRAP=3D #PORTS_MODULES=3Demulators/virtualbox-ose-additions #WITHOUT_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLDB=3D # WITH_BOOT=3D WITH_LIB32=3D # WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_DEBUG_FILES=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Wed Jun 1 19:36: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 97E1AB60261 for ; Wed, 1 Jun 2016 19:36:15 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 7B3E21BC6 for ; Wed, 1 Jun 2016 19:36:15 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 7A802B60260; Wed, 1 Jun 2016 19:36: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 7A1F6B6025F for ; Wed, 1 Jun 2016 19:36:15 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 631991BC5; Wed, 1 Jun 2016 19:36:15 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 524161203; Wed, 1 Jun 2016 19:36:15 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 0B6F51D23C; Wed, 1 Jun 2016 19:36:15 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id 2UmuYm_bpYdn; Wed, 1 Jun 2016 19:36:10 +0000 (UTC) Subject: Re: 'make depend' or 'make' bug on recent --current DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 4C4CA1D235 To: Andrey Chernov , current@freebsd.org References: <092f5e98-dae8-dbc9-2a6e-7068b972278f@freebsd.org> <311f3a82-b702-d375-170f-82ae39236ab0@FreeBSD.org> From: Bryan Drewery Organization: FreeBSD Message-ID: <7f325ac2-f722-c491-fca0-2e582773e780@FreeBSD.org> Date: Wed, 1 Jun 2016 12:36:05 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="r6heT2Xl3xlT5im5ACh5dO7QQqH1hCgPb" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 19:36:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --r6heT2Xl3xlT5im5ACh5dO7QQqH1hCgPb Content-Type: multipart/mixed; boundary="fNu2oeONVv8Kd0hFeRqDIeU09ltsktlmD" From: Bryan Drewery To: Andrey Chernov , current@freebsd.org Message-ID: <7f325ac2-f722-c491-fca0-2e582773e780@FreeBSD.org> Subject: Re: 'make depend' or 'make' bug on recent --current References: <092f5e98-dae8-dbc9-2a6e-7068b972278f@freebsd.org> <311f3a82-b702-d375-170f-82ae39236ab0@FreeBSD.org> In-Reply-To: --fNu2oeONVv8Kd0hFeRqDIeU09ltsktlmD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/1/16 11:49 AM, Andrey Chernov wrote: > On 01.06.2016 21:18, Bryan Drewery wrote: >> On 6/1/2016 6:11 AM, Andrey Chernov wrote: >>> Steps to reproduce: >>> >>> cd /usr/src/lib/libc/stdlib >>> touch *div*.c >>> cd .. >>> make depend >>> make >>> >>> And see how imaxdiv.o only is recompiled. >>> No div.o ldiv.o lldiv.o are recompiled. Because they never were compiled! lib/libc/stdlib/Makefile.inc MISRCS has div.c ldiv.c lldiv.c However, for at least amd64 it also includes: lib/libc/amd64/stdlib/Makefile.inc which has MDSRCS=3D div.S ldiv.S lldiv.S Note the .depend.lldiv.o file: > ~/git/freebsd/lib/libc/stdlib # cat /usr/obj/root/git/freebsd/lib/libc/= =2Edepend.lldiv.o > lldiv.o: /root/git/freebsd/lib/libc/amd64/stdlib/lldiv.S \ > /usr/obj/root/git/freebsd/tmp/usr/include/machine/asm.h \ > /usr/obj/root/git/freebsd/tmp/usr/include/sys/cdefs.h It's built from lldiv.S, not lldiv.c. No bug here. proof: > cc -O2 -pipe -I/root/git/freebsd/lib/libc/include -I/root/git/freebsd= /lib/libc/../../include -I/root/git/freebsd/lib/libc/amd64 -DNLS -D__DBI= NTERFACE_PRIVATE -I/root/git/freebsd/lib/libc/../../contrib/ > gdtoa -I/root/git/freebsd/lib/libc/../../contrib/libc-vis -DINET6 -I/us= r/obj/root/git/freebsd/lib/libc -I/root/git/freebsd/lib/libc/resolv -D_AC= L_PRIVATE -DPOSIX_MISTAKE -I/root/git/freebsd/lib/libc/../li > bmd -I/root/git/freebsd/lib/libc/../../contrib/jemalloc/include -DMALLO= C_PRODUCTION -I/root/git/freebsd/lib/libc/../../contrib/tzcode/stdtime -I= /root/git/freebsd/lib/libc/stdtime -I/root/git/freebsd/lib/l > ibc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/root/git/freebsd/lib= /libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -MD -MF.depend.lldiv.o -= MTlldiv.o -std=3Dgnu99 -fstack-protector-strong -Wsystem-heade > rs -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -= Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tauto= logical-compare -Wno-unused-value -Wno-parentheses-equality > -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wn= o-switch -Wno-switch-enum -Wno-knr-promoted-parameter -fcolor-diagnostic= s -Qunused-arguments -I/root/git/freebsd/lib/libutil -I/roo > t/git/freebsd/lib/msun/amd64 -I/root/git/freebsd/lib/msun/x86 -I/root/g= it/freebsd/lib/msun/src -c /root/git/freebsd/lib/libc/amd64/stdlib/lldi= v.S -o lldiv.o > cc -fpic -DPIC -O2 -pipe -I/root/git/freebsd/lib/libc/include -I/root= /git/freebsd/lib/libc/../../include -I/root/git/freebsd/lib/libc/amd64 -D= NLS -D__DBINTERFACE_PRIVATE -I/root/git/freebsd/lib/libc/.. > /../contrib/gdtoa -I/root/git/freebsd/lib/libc/../../contrib/libc-vis -= DINET6 -I/usr/obj/root/git/freebsd/lib/libc -I/root/git/freebsd/lib/libc/= resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/root/git/freebsd/li > b/libc/../libmd -I/root/git/freebsd/lib/libc/../../contrib/jemalloc/inc= lude -DMALLOC_PRODUCTION -I/root/git/freebsd/lib/libc/../../contrib/tzcod= e/stdtime -I/root/git/freebsd/lib/libc/stdtime -I/root/git/f > reebsd/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/root/git= /freebsd/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -MD -MF.depe= nd.lldiv.So -MTlldiv.So -std=3Dgnu99 -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-varia= ble -Wno-tautological-compare -Wno-unused-value -Wno-parenth > eses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-loc= al-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -fco= lor-diagnostics -Qunused-arguments -I/root/git/freebsd/lib/ > libutil -I/root/git/freebsd/lib/msun/amd64 -I/root/git/freebsd/lib/msun= /x86 -I/root/git/freebsd/lib/msun/src -c /root/git/freebsd/lib/libc/am= d64/stdlib/lldiv.S -o lldiv.So note lldiv.S in both. >> >> My dev system is busy at the moment. I'll test it and get back to you.= >=20 > I need to add that I do 'make cleandepend/cleandir/cleanobj' + 'make > obj' again and full rebuild with no old files, but the bug repeated aga= in. >=20 >>> P.S. new make depend is simple disgusting. It tends to recompile >>> everything in the system if some minor header file is touched, but >> >> If the header is used by all source files then that is expected. >> >> However if you do not have a .depend.obj.o file then it is quite >> aggressive with building. If you touch any header it will rebuild >> everything. But you shouldn't get into that situation unless you rm -= f >> .depend* first. >> >>> completely forget to recompile source code changes. I suggest to back= >>> out all AI in that area. >>> 'make depend' is not time-consuming task and good old way never made >>> mistakes. >> >> The graph in the original commit for WITH_FAST_DEPEND disagrees. >> https://svnweb.freebsd.org/base?view=3Drevision&revision=3D290433 >> >> We run the preprocessor once now, not twice. >=20 > It sounds good, just implemented bad. You measure some spherical chicke= n > in vacuum, not what really happens. In the old times I almost never hav= e > clang libs rebuild (few files from there max when FreeBSD_version is > increased), but now I got them fully rebuilt with any header change. > That is the biggest slowdown and not what you try to measure. > Don't ever use 'make world'. Try to rebuild the system incrementally an= d > you'll see. I cannot argue with a lack of solid evidence. The old 'make depend' ran 'mkdep' which ran 'cc -E -M' which produces *the same output* as 'cc foo.c -o foo.o -MD -MF .depend.foo.o -MT foo.o'. There's nothing different in the actual .depend file implementation/content. Clang rebuilds often because it is changing often! Just look at recent commit logs and you'll see r300984 which will cause a rebuild of clang. Or r301011 which modified sys/sys/param.h which will rebuild just about everything. These are normal and how the old system worked as well. There certainly are some issues with the new system. 1. Processing the split files can be slow over NFS 2. make cleandepend - will cause the next build to make a lot of guesses and not be very efficient. 3. make cleandepend - There is no way to generate the .depend* files again without rebuilding. 4. It doesn't fix all of the missing dependencies that have been missing forever such as crt, csu, libgcc, etc for static builds. 5. the csu builds don't use it yet but have workarounds for it 6. removing the 'make depend' tree-walk can hurt downstream builds which relied on having a multi-phase build to generate a .mk file to include (odd case I hit at work). No such case exists in the upstream FreeBSD tr= ee. --=20 Regards, Bryan Drewery --fNu2oeONVv8Kd0hFeRqDIeU09ltsktlmD-- --r6heT2Xl3xlT5im5ACh5dO7QQqH1hCgPb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXTzkmAAoJEDXXcbtuRpfPG3gH/2VJNdGriXkgDvJ/rYpbBSlk EO3TJzWgUicQGIcgyEp+tgLG7wP1k0vZ+fbTZBWA8mlmIfnBBX4TiYavQRzTACYL rb4Tp9VHiI9lFREpev6Lyw4LzDmnOgtc9RL3VZBaHr0T03JVciMfMV5jzo8PIN0f Z7u88XqRLgEk7LrdJJdvu0Qm9g4y9EIRTCuAt/K2gWgEfePW54n5HvCJLa9OCgAo wvAH2tMYL/W4PQg6iG8gd4o7vVvHi+t9Y+++bOvOrlzQJpBdCSiK8qGM5ZmeYKLl odQki1caX2eHCPHun08zPODI/8HBscXGZKQ+HVCUJ0FiVHjG6qR1FodicZTnqrM= =g4CW -----END PGP SIGNATURE----- --r6heT2Xl3xlT5im5ACh5dO7QQqH1hCgPb-- From owner-freebsd-current@freebsd.org Wed Jun 1 19: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 6AE7AB6036D for ; Wed, 1 Jun 2016 19:38:15 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 534891D4E; Wed, 1 Jun 2016 19:38:15 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 433BB12DF; Wed, 1 Jun 2016 19:38:15 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id F30E01D24C; Wed, 1 Jun 2016 19:38:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id A67VNpt-0cdo; Wed, 1 Jun 2016 19:38:11 +0000 (UTC) Subject: Re: amd64 11.0 -r301139 installworld (WITH_META_MODE=yes) fails for "Unable to determine compiler type" DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com C7B571D246 To: Mark Millard , FreeBSD Current References: From: Bryan Drewery Organization: FreeBSD Message-ID: <223a80c4-f57d-5636-2c0f-402d22fe631f@FreeBSD.org> Date: Wed, 1 Jun 2016 12:38:07 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: base64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 19:38:15 -0000 T24gNi8xLzE2IDEyOjM1IFBNLCBNYXJrIE1pbGxhcmQgd3JvdGU6DQo+IENvbnRleHQ6IGFt ZDY0IGJ1aWxkaW5nIGZvciBhbWQ2NCBzdGFydGluZyBmcm9tOg0KPiANCj4+ICMgdW5hbWUg LWFwS1UNCj4+IEZyZWVCU0QgRnJlZUJTRHg2NCAxMS4wLUFMUEhBMSBGcmVlQlNEIDExLjAt QUxQSEExICMyOSByMzAwOTQ0TTogU3VuIE1heSAyOSAxNDozOTo0NyBQRFQgMjAxNiAgICAg bWFya21pQEZyZWVCU0R4NjQ6L3Vzci9vYmovY2xhbmcvYW1kNjQuYW1kNjQvdXNyL3NyYy9z eXMvR0VORVJJQy1OT0RFQlVHICBhbWQ2NCBhbWQ2NCAxMTAwMTE0IDExMDAxMTQNCj4gDQo+ IA0KPiBBZnRlciBhIHN1Y2Nlc3NmdWwgV0lUSF9NRVRBX01PREU9eWVzIGJ1aWxkd29ybGQg YnVpbGRrZXJuZWwgc2VxdWVuY2UgYW5kIHRoZW4gaW5zdGFsbGtlcm5lbCBzZXF1ZW5jZTog aW5zdGFsbHdvcmxkIHRoZW4gZmFpbGVkIHdpdGggLiAuIC4NCj4gDQo+PiAjIH4vc3lzX2J1 aWxkX3NjcmlwdHMuYW1kNjQtaG9zdC9tYWtlX2FtZDY0X25vZGVidWdfY2xhbmdfYm9vdHN0 cmFwLWFtZDY0LWhvc3Quc2ggaW5zdGFsbHdvcmxkDQo+PiBTY3JpcHQgc3RhcnRlZCwgb3V0 cHV0IGZpbGUgaXMgL3Jvb3Qvc3lzX3R5cGVzY3JpcHRzL3R5cGVzY3JpcHRfbWFrZV9hbWQ2 NF9ub2RlYnVnX2NsYW5nX2Jvb3RzdHJhcC1hbWQ2NC1ob3N0LTIwMTYtMDYtMDE6MTI6MTM6 MDUNCj4+IG1rZGlyIC1wIC90bXAvaW5zdGFsbC5Kd1pKM2Y5UA0KPj4gcHJvZ3M9JChmb3Ig cHJvZyBpbiBbIGF3ayBjYXBfbWtkYiBjYXQgY2hmbGFncyBjaG1vZCBjaG93biBjbXAgY3Ag IGRhdGUgZWNobyBlZ3JlcCBmaW5kIGdyZXAgaWQgaW5zdGFsbCAgIGxuIG1ha2UgbWtkaXIg bXRyZWUgbXYgcHdkX21rZGIgIHJtIHNlZCBzZXJ2aWNlc19ta2RiIHNoIHN0cmlwIHN5c2N0 bCB0ZXN0IHRydWUgdW5hbWUgd2MgemljIHR6c2V0dXAgICBtYWtld2hhdGlzOyBkbyAgaWYg cHJvZ3BhdGg9YHdoaWNoICRwcm9nYDsgdGhlbiAgZWNobyAkcHJvZ3BhdGg7ICBlbHNlICBl Y2hvICJSZXF1aXJlZCB0b29sICRwcm9nIG5vdCBmb3VuZCBpbiBQQVRILiIgPiYyOyAgZXhp dCAxOyAgZmk7ICBkb25lKTsgIGxpYnM9JChsZGQgLWYgIiVvICVwXG4iIC1mICIlbyAlcFxu IiAkcHJvZ3MgMj4vZGV2L251bGwgfCBzb3J0IC11IHwgIHdoaWxlIHJlYWQgbGluZTsgZG8g IHNldCAtLSAkbGluZTsgIGlmIFsgIiQyICQzIiAhPSAibm90IGZvdW5kIiBdOyB0aGVuICBl Y2hvICQyOyAgZWxzZSAgZWNobyAiUmVxdWlyZWQgbGlicmFyeSAkMSBub3QgZm91bmQuIiA+ JjI7ICBleGl0IDE7ICBmaTsgIGRvbmUpOyAgY3AgJGxpYnMgJHByb2dzIC90bXAvaW5zdGFs bC5Kd1pKM2Y5UA0KPj4gY3AgLVIgJHtQQVRIX0xPQ0FMRTotIi91c3Ivc2hhcmUvbG9jYWxl In0gL3RtcC9pbnN0YWxsLkp3WkozZjlQL2xvY2FsZQ0KPj4gY2QgL3Vzci9zcmM7IE1BS0VP QkpESVJQUkVGSVg9L3Vzci9vYmovY2xhbmcvYW1kNjQuYW1kNjQgIE1BQ0hJTkVfQVJDSD1h bWQ2NCAgTUFDSElORT1hbWQ2NCAgQ1BVVFlQRT0gR1JPRkZfQklOX1BBVEg9L3Vzci9vYmov Y2xhbmcvYW1kNjQuYW1kNjQvdXNyL3NyYy90bXAvbGVnYWN5L3Vzci9iaW4gIEdST0ZGX0ZP TlRfUEFUSD0vdXNyL29iai9jbGFuZy9hbWQ2NC5hbWQ2NC91c3Ivc3JjL3RtcC9sZWdhY3kv dXNyL3NoYXJlL2dyb2ZmX2ZvbnQgIEdST0ZGX1RNQUNfUEFUSD0vdXNyL29iai9jbGFuZy9h bWQ2NC5hbWQ2NC91c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL3NoYXJlL3RtYWMgQ0M9ImNjIC10 YXJnZXQgeDg2XzY0LXVua25vd24tZnJlZWJzZDExLjAgLS1zeXNyb290PS91c3Ivb2JqL2Ns YW5nL2FtZDY0LmFtZDY0L3Vzci9zcmMvdG1wIC1CL3Vzci9vYmovY2xhbmcvYW1kNjQuYW1k NjQvdXNyL3NyYy90bXAvdXNyL2JpbiIgQ1hYPSJjKysgIC10YXJnZXQgeDg2XzY0LXVua25v d24tZnJlZWJzZDExLjAgLS1zeXNyb290PS91c3Ivb2JqL2NsYW5nL2FtZDY0LmFtZDY0L3Vz ci9zcmMvdG1wIC1CL3Vzci9vYmovY2xhbmcvYW1kNjQuYW1kNjQvdXNyL3NyYy90bXAvdXNy L2JpbiIgIENQUD0iY3BwIC10YXJnZXQgeDg2XzY0LXVua25vd24tZnJlZWJzZDExLjAgLS1z eXNyb290PS91c3Ivb2JqL2NsYW5nL2FtZDY0LmFtZDY0L3Vzci9zcmMvdG1wIC1CL3Vzci9v YmovY2xhbmcvYW1kNjQuYW1kNjQvdXNyL3NyYy90bXAvdXNyL2JpbiIgIEFTPSJhcyIgQVI9 ImFyIiBMRD0ibGQiIE5NPW5tICBPQkpEVU1QPW9iamR1bXAgT0JKQ09QWT0ib2JqY29weSIg IFJBTkxJQj1yYW5saWIgU1RSSU5HUz0gIFNJWkU9InNpemUiIFBBVEg9L3Vzci9vYmovY2xh bmcvYW1kNjQuYW1kNjQvdXNyL3NyYy90bXAvbGVnYWN5L3Vzci9zYmluOi91c3Ivb2JqL2Ns YW5nL2FtZDY0LmFtZDY0L3Vzci9zcmMvdG1wL2xlZ2FjeS91c3IvYmluOi91c3Ivb2JqL2Ns YW5nL2FtZDY0LmFtZDY0L3Vzci9zcmMvdG1wL2xlZ2FjeS9iaW46L3Vzci9vYmovY2xhbmcv YW1kNjQuYW1kNjQvdXNyL3NyYy90bXAvdXNyL3NiaW46L3Vzci9vYmovY2xhbmcvYW1kNjQu YW1kNjQvdXNyL3NyYy90bXAvdXNyL2JpbjovdG1wL2luc3RhbGwuSndaSjNmOVAgIExEX0xJ QlJBUllfUEFUSD0vdG1wL2luc3RhbGwuSndaSjNmOVAgIFBBVEhfTE9DQUxFPS90bXAvaW5z dGFsbC5Kd1pKM2Y5UC9sb2NhbGUgbWFrZSAtZiBNYWtlZmlsZS5pbmMxICAgIF9fTUFLRV9T SEVMTD0vdG1wL2luc3RhbGwuSndaSjNmOVAvc2ggcmVpbnN0YWxsOyAgTUFLRU9CSkRJUlBS RUZJWD0vdXNyL29iai9jbGFuZy9hbWQ2NC5hbWQ2NCAgTUFDSElORV9BUkNIPWFtZDY0ICBN QUNISU5FPWFtZDY0ICBDUFVUWVBFPSBHUk9GRl9CSU5fUEFUSD0vdXNyL29iai9jbGFuZy9h bWQ2NC5hbWQ2NC91c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL2JpbiAgR1JPRkZfRk9OVF9QQVRI PS91c3Ivb2JqL2NsYW5nL2FtZDY0LmFtZDY0L3Vzci9zcmMvdG1wL2xlZ2FjeS91c3Ivc2hh cmUvZ3JvZmZfZm9udCAgR1JPRkZfVE1BQ19QQVRIPS91c3Ivb2JqL2NsYW5nL2FtZDY0LmFt ZDY0L3Vzci9zcmMvdG1wL2xlZ2FjeS91c3Ivc2hhcmUvdG1hYyBDQz0iY2MgLXRhcmdldCB4 ODZfNjQtdW5rbm93bi1mcmVlYnNkMTEuMCAtLXN5c3Jvb3Q9L3Vzci9vYmovY2xhbmcvYW1k NjQuYW1kNjQvdXNyL3NyYy90bXAgLUIvdXNyL29iai9jbGFuZy9hbWQ2NC5hbWQ2NC91c3Iv c3JjL3RtcC91c3IvYmluIiBDWFg9ImMrKyAgLXRhcmdldCB4ODZfNjQtdW5rbm93bi1mcmVl YnNkMTEuMCAtLXN5c3Jvb3Q9L3Vzci9vYmovY2xhbmcvYW1kNjQuYW1kNjQvdXNyL3NyYy90 bXAgLUIvdXNyL29iai9jbGFuZy9hbWQ2NC5hbWQ2NC91c3Ivc3JjL3RtcC91c3IvYmluIiAg Q1BQPSJjcHAgLXRhcmdldCB4ODZfNjQtdW5rbm93bi1mcmVlYnNkMTEuMCAtLXN5c3Jvb3Q9 L3Vzci9vYmovY2xhbmcvYW1kNjQuYW1kNjQvdXNyL3NyYy90bXAgLUIvdXNyL29iai9jbGFu Zy9hbWQ2NC5hbWQ2NC91c3Ivc3JjL3RtcC91c3IvYmluIiAgQVM9ImFzIiBBUj0iYXIiIExE PSJsZCIgTk09bm0gIE9CSkRVTVA9b2JqZHVtcCBPQkpDT1BZPSJvYmpjb3B5IiAgUkFOTElC PXJhbmxpYiBTVFJJTkdTPSAgU0laRT0ic2l6ZSIgUEFUSD0vdXNyL29iai9jbGFuZy9hbWQ2 NC5hbWQ2NC91c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL3NiaW46L3Vzci9vYmovY2xhbmcvYW1k NjQuYW1kNjQvdXNyL3NyYy90bXAvbGVnYWN5L3Vzci9iaW46L3Vzci9vYmovY2xhbmcvYW1k NjQuYW1kNjQvdXNyL3NyYy90bXAvbGVnYWN5L2JpbjovdXNyL29iai9jbGFuZy9hbWQ2NC5h bWQ2NC91c3Ivc3JjL3RtcC91c3Ivc2JpbjovdXNyL29iai9jbGFuZy9hbWQ2NC5hbWQ2NC91 c3Ivc3JjL3RtcC91c3IvYmluOi90bXAvaW5zdGFsbC5Kd1pKM2Y5UCAgTERfTElCUkFSWV9Q QVRIPS90bXAvaW5zdGFsbC5Kd1pKM2Y5UCAgUEFUSF9MT0NBTEU9L3RtcC9pbnN0YWxsLkp3 WkozZjlQL2xvY2FsZSBybSAtcmYgL3RtcC9pbnN0YWxsLkp3WkozZjlQDQo+PiBzaDogY2M6 IG5vdCBmb3VuZA0KPj4gbWFrZVsyXTogIi91c3Ivc3JjL3NoYXJlL21rL2JzZC5jb21waWxl ci5tayIgbGluZSAxNDI6IFVuYWJsZSB0byBkZXRlcm1pbmUgY29tcGlsZXIgdHlwZSBmb3Ig Q0M9Y2MgLXRhcmdldCB4ODZfNjQtdW5rbm93bi1mcmVlYnNkMTEuMCAtLXN5c3Jvb3Q9L3Vz ci9vYmovY2xhbmcvYW1kNjQuYW1kNjQvdXNyL3NyYy90bXAgLUIvdXNyL29iai9jbGFuZy9h bWQ2NC5hbWQ2NC91c3Ivc3JjL3RtcC91c3IvYmluLiAgQ29uc2lkZXIgc2V0dGluZyBDT01Q SUxFUl9UWVBFLg0KPj4gKioqIEVycm9yIGNvZGUgMQ0KPj4NCg0KVGhlIGVycm9yIGlzIG5v dCByZWxhdGVkIHRvIFdJVEhfTUVUQV9NT0RFLg0KDQo+PiBTdG9wLg0KPj4gbWFrZVsxXTog c3RvcHBlZCBpbiAvdXNyL3NyYw0KPj4gKioqIEVycm9yIGNvZGUgMQ0KPj4NCj4+IFN0b3Au DQo+PiBtYWtlOiBzdG9wcGVkIGluIC91c3Ivc3JjDQo+Pg0KPj4gU2NyaXB0IGRvbmUsIG91 dHB1dCBmaWxlIGlzIC9yb290L3N5c190eXBlc2NyaXB0cy90eXBlc2NyaXB0X21ha2VfYW1k NjRfbm9kZWJ1Z19jbGFuZ19ib290c3RyYXAtYW1kNjQtaG9zdC0yMDE2LTA2LTAxOjEyOjEz OjA1DQo+IA0KPiAoSSBkbyBub3Qga25vdyBpZiBXSVRIX01FVEFfTU9ERT15ZXMgbWF0dGVy cyBoZXJlIG9yIG5vdC4gV0lUSF9NRVRBX01PREU9eWVzIHdhcyBzdXBwbGllZCB0aGUgdGhl IHNjcmlwdCB0aGF0IEkgdXNlZC4pDQo+IA0KPiBtYWtlLmNvbmYgd2FzOg0KPiANCj4gQ0ZM QUdTLmdjYys9IC12DQo+IA0KPiAoc28gZWZmZWN0aXZlbHkgZW1wdHkgZm9yIGNsYW5nIHVz ZSkuDQo+IA0KPiBzcmMuY29uZiB3YXM6DQo+IA0KPiBUT19UWVBFPWFtZDY0DQo+ICMNCj4g S0VSTkNPTkY9R0VORVJJQy1OT0RFQlVHDQo+IFRBUkdFVD0ke1RPX1RZUEV9DQo+IC5pZiAk ey5NQUtFLkxFVkVMfSA9PSAwDQo+IFRBUkdFVF9BUkNIPSR7VE9fVFlQRX0NCj4gLmV4cG9y dCBUQVJHRVRfQVJDSA0KPiAuZW5kaWYNCj4gIw0KPiBXSVRIT1VUX0NST1NTX0NPTVBJTEVS PQ0KDQpJdCdzIGxpa2VseSByZWxhdGVkIHRvIHRoaXMgZmxhZy4gIEknbGwgbG9vayBpbnRv IGl0Lg0KDQo+IFdJVEhfU1lTVEVNX0NPTVBJTEVSPQ0KDQpJZiB5b3UgYXJlIG5vdCBidWls ZGluZyB0aGUgY3Jvc3MgY29tcGlsZXIgdGhlbiBXSVRIX1NZU1RFTV9DT01QSUxFUiBpcw0K dXNlbGVzcy4gIEl0J3Mga2luZCBvZiB0aGUgc2FtZSBidXQgb25seSBzb21ldGltZXMuICBJ dCBjb3VsZCBiZSB0aGUgdHdvDQpvcHRpb25zIGNvbmZsaWN0IGF0IGluc3RhbGx3b3JsZCB0 aW1lLg0KDQo+ICMNCj4gV0lUSF9MSUJDUExVU1BMVVM9DQo+IFdJVEhfQklOVVRJTFNfQk9P VFNUUkFQPQ0KPiAjUE9SVFNfTU9EVUxFUz1lbXVsYXRvcnMvdmlydHVhbGJveC1vc2UtYWRk aXRpb25zDQo+ICNXSVRIT1VUX0NMQU5HX0JPT1RTVFJBUD0NCj4gV0lUSF9DTEFORz0NCj4g V0lUSF9DTEFOR19JU19DQz0NCj4gV0lUSF9DTEFOR19GVUxMPQ0KPiBXSVRIX0NMQU5HX0VY VFJBUz0NCj4gV0lUSF9MTERCPQ0KPiAjDQo+IFdJVEhfQk9PVD0NCj4gV0lUSF9MSUIzMj0N Cj4gIw0KPiBXSVRIT1VUX0VMRlRPT0xDSEFJTl9CT09UU1RSQVA9DQo+IFdJVEhPVVRfR0ND X0JPT1RTVFJBUD0NCj4gV0lUSE9VVF9HQ0M9DQo+IFdJVEhPVVRfR0NDX0lTX0NDPQ0KPiBX SVRIT1VUX0dOVUNYWD0NCj4gIw0KPiBOT19XRVJST1I9DQo+ICNXRVJST1I9DQo+IE1BTExP Q19QUk9EVUNUSU9OPQ0KPiAjDQo+IFdJVEhfREVCVUdfRklMRVM9DQo+IA0KPiANCj4gDQo+ ID09PQ0KPiBNYXJrIE1pbGxhcmQNCj4gbWFya21pIGF0IGRzbC1vbmx5Lm5ldA0KPiANCg0K DQotLSANClJlZ2FyZHMsDQpCcnlhbiBEcmV3ZXJ5DQo= From owner-freebsd-current@freebsd.org Wed Jun 1 19:58: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 D5B78B60ACF for ; Wed, 1 Jun 2016 19:58:14 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id B2C4B1CE5 for ; Wed, 1 Jun 2016 19:58:14 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mailman.ysv.freebsd.org (Postfix) id AEBA2B60ACE; Wed, 1 Jun 2016 19:58:14 +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 AC0C8B60ACD for ; Wed, 1 Jun 2016 19:58:14 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f45.google.com (mail-lf0-f45.google.com [209.85.215.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A87F1CE2 for ; Wed, 1 Jun 2016 19:58:13 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lf0-f45.google.com with SMTP id s64so20222537lfe.0 for ; Wed, 01 Jun 2016 12:58:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=Qbvcr1HOsytNvB6rHnoXtYtmK7E+2tX2SXI3B7O55uw=; b=ddt7yXalUKbTDFmbEqjJvOF+7vY5GSvWD6I0pf7f+GCPicXQ8reBtwFZhRvB1rGmO3 2+uJlCdmPOjbOB5OwRZtTgaPlPrc1tZvkFs9rWgsiXJbhbpWvWdQRjTlSMVMuIEiaGMr R5JwJiwgcgUSbjWtyOuNSplq6c9Sr02gmy6JJjRALda+CT+OAFUpqirOuOkD7L/D7Gej Vjr/JeID9+eFXv2+DK6+MzHk5WOV6soqM6bS7geTFIRgZdYL3TdR8DoK4sA2I80Q4Ce/ Sc/VOpJ914zuU1RhS4W6Rj3+JSo8Va0g7SAiZRnLmX6XDiSofL6Mx2c/VWLykm4+uxYF XfrA== X-Gm-Message-State: ALyK8tIkoXwSoYJrmhgcgxtRczB1ohpuBpNSs6AFNho7kwV3RZCCeIzOLUl0FFBDg61zmw== X-Received: by 10.25.91.211 with SMTP id p202mr2713925lfb.167.1464811085906; Wed, 01 Jun 2016 12:58:05 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id z63sm2662692lfa.41.2016.06.01.12.58.05 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2016 12:58:05 -0700 (PDT) Subject: Re: 'make depend' or 'make' bug on recent --current To: Bryan Drewery , current@freebsd.org References: <092f5e98-dae8-dbc9-2a6e-7068b972278f@freebsd.org> <311f3a82-b702-d375-170f-82ae39236ab0@FreeBSD.org> <7f325ac2-f722-c491-fca0-2e582773e780@FreeBSD.org> From: Andrey Chernov Message-ID: Date: Wed, 1 Jun 2016 22:58:04 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <7f325ac2-f722-c491-fca0-2e582773e780@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="aBuSrsc44c2ATrQ49vPoHPsRXt7VuMLF9" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 19:58:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aBuSrsc44c2ATrQ49vPoHPsRXt7VuMLF9 Content-Type: multipart/mixed; boundary="vXhEi6aPxV3tUFTUMaaSOCuc4P22q6AK9" From: Andrey Chernov To: Bryan Drewery , current@freebsd.org Message-ID: Subject: Re: 'make depend' or 'make' bug on recent --current References: <092f5e98-dae8-dbc9-2a6e-7068b972278f@freebsd.org> <311f3a82-b702-d375-170f-82ae39236ab0@FreeBSD.org> <7f325ac2-f722-c491-fca0-2e582773e780@FreeBSD.org> In-Reply-To: <7f325ac2-f722-c491-fca0-2e582773e780@FreeBSD.org> --vXhEi6aPxV3tUFTUMaaSOCuc4P22q6AK9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 01.06.2016 22:36, Bryan Drewery wrote: >>> The graph in the original commit for WITH_FAST_DEPEND disagrees. >>> https://svnweb.freebsd.org/base?view=3Drevision&revision=3D290433 >>> >>> We run the preprocessor once now, not twice. >> >> It sounds good, just implemented bad. You measure some spherical chick= en >> in vacuum, not what really happens. In the old times I almost never ha= ve >> clang libs rebuild (few files from there max when FreeBSD_version is >> increased), but now I got them fully rebuilt with any header change. >> That is the biggest slowdown and not what you try to measure. >> Don't ever use 'make world'. Try to rebuild the system incrementally a= nd >> you'll see. >=20 > I cannot argue with a lack of solid evidence. >=20 > The old 'make depend' ran 'mkdep' which ran 'cc -E -M' which produces > *the same output* as 'cc foo.c -o foo.o -MD -MF .depend.foo.o -MT > foo.o'. There's nothing different in the actual .depend file > implementation/content. Clang rebuilds often because it is changing > often! Just look at recent commit logs and you'll see r300984 which > will cause a rebuild of clang. Or r301011 which modified > sys/sys/param.h which will rebuild just about everything. These are > normal and how the old system worked as well. >=20 > There certainly are some issues with the new system. > 1. Processing the split files can be slow over NFS > 2. make cleandepend - will cause the next build to make a lot of guesse= s > and not be very efficient. > 3. make cleandepend - There is no way to generate the .depend* files > again without rebuilding. > 4. It doesn't fix all of the missing dependencies that have been missin= g > forever such as crt, csu, libgcc, etc for static builds. > 5. the csu builds don't use it yet but have workarounds for it > 6. removing the 'make depend' tree-walk can hurt downstream builds whic= h > relied on having a multi-phase build to generate a .mk file to include > (odd case I hit at work). No such case exists in the upstream FreeBSD = tree. >=20 There are two different things: pure recursive dependency (it is how make depends works now) and just nested include graph with dependencies marked directly by Makefile's rules (it is how old system works). Now it is enough to touch some low level include to rebuild everything, before only files which include it directly or have make rules for it are rebuil= t. --vXhEi6aPxV3tUFTUMaaSOCuc4P22q6AK9-- --aBuSrsc44c2ATrQ49vPoHPsRXt7VuMLF9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXTz5MAAoJEKUckv0MjfbKLvkIANWzjZ9y8SFkskZkhchAxv1M AuuYOsIbXJCAXFpCHQ0jBFeFNqPGNhnAj5EKOr/Gnwo5enGhSFA97QmA8pORRZCs c296ILUvlYyC1ZRD59ax2ykVQvgfnrtw8P/Xjo5RfI++xL0fgO0HTktxZSzhhFjA 4SzhLpvheEawGseENlqXHqkn8LyF1k6rZzMC8xx6mfpP0I2WwGWQ2UNw8zzSbQl0 RFHEc98KhLInJJsL6o31YGnBqX0EEHs7qtdxn5CAHT5VcanvNujMsCNxnffGd1wm 9Mmbogq0+iPD5A+H9+U66XvAEafmjckkNpkgdxw5qvMGDbKwpqDJEp/FC7/Bm8I= =dtcd -----END PGP SIGNATURE----- --aBuSrsc44c2ATrQ49vPoHPsRXt7VuMLF9-- From owner-freebsd-current@freebsd.org Wed Jun 1 20:04: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 114C9B60EE9 for ; Wed, 1 Jun 2016 20:04:12 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E770D1319 for ; Wed, 1 Jun 2016 20:04:11 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id E6BA8B60EE8; Wed, 1 Jun 2016 20:04:11 +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 E65DFB60EE7 for ; Wed, 1 Jun 2016 20:04:11 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id CD75D1318; Wed, 1 Jun 2016 20:04:11 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id BD5081C08; Wed, 1 Jun 2016 20:04:11 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 769241D2EB; Wed, 1 Jun 2016 20:04:11 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id 0rzfQ8olodkk; Wed, 1 Jun 2016 20:04:08 +0000 (UTC) Subject: Re: 'make depend' or 'make' bug on recent --current DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 243551D2E3 To: Andrey Chernov , current@freebsd.org References: <092f5e98-dae8-dbc9-2a6e-7068b972278f@freebsd.org> <311f3a82-b702-d375-170f-82ae39236ab0@FreeBSD.org> <7f325ac2-f722-c491-fca0-2e582773e780@FreeBSD.org> From: Bryan Drewery Organization: FreeBSD Message-ID: Date: Wed, 1 Jun 2016 13:04:07 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uI4colgDmiHCGoBqnq4vHn7Fgjc1TNnnU" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 20:04:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uI4colgDmiHCGoBqnq4vHn7Fgjc1TNnnU Content-Type: multipart/mixed; boundary="mWjNBtQCvHWjeJue6uD70R4rLuha3som4" From: Bryan Drewery To: Andrey Chernov , current@freebsd.org Message-ID: Subject: Re: 'make depend' or 'make' bug on recent --current References: <092f5e98-dae8-dbc9-2a6e-7068b972278f@freebsd.org> <311f3a82-b702-d375-170f-82ae39236ab0@FreeBSD.org> <7f325ac2-f722-c491-fca0-2e582773e780@FreeBSD.org> In-Reply-To: --mWjNBtQCvHWjeJue6uD70R4rLuha3som4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/1/16 12:58 PM, Andrey Chernov wrote: > On 01.06.2016 22:36, Bryan Drewery wrote: >>>> The graph in the original commit for WITH_FAST_DEPEND disagrees. >>>> https://svnweb.freebsd.org/base?view=3Drevision&revision=3D290433 >>>> >>>> We run the preprocessor once now, not twice. >>> >>> It sounds good, just implemented bad. You measure some spherical chic= ken >>> in vacuum, not what really happens. In the old times I almost never h= ave >>> clang libs rebuild (few files from there max when FreeBSD_version is >>> increased), but now I got them fully rebuilt with any header change. >>> That is the biggest slowdown and not what you try to measure. >>> Don't ever use 'make world'. Try to rebuild the system incrementally = and >>> you'll see. >> >> I cannot argue with a lack of solid evidence. >> >> The old 'make depend' ran 'mkdep' which ran 'cc -E -M' which produces >> *the same output* as 'cc foo.c -o foo.o -MD -MF .depend.foo.o -MT >> foo.o'. There's nothing different in the actual .depend file >> implementation/content. Clang rebuilds often because it is changing >> often! Just look at recent commit logs and you'll see r300984 which >> will cause a rebuild of clang. Or r301011 which modified >> sys/sys/param.h which will rebuild just about everything. These are >> normal and how the old system worked as well. >> >> There certainly are some issues with the new system. >> 1. Processing the split files can be slow over NFS >> 2. make cleandepend - will cause the next build to make a lot of guess= es >> and not be very efficient. >> 3. make cleandepend - There is no way to generate the .depend* files >> again without rebuilding. >> 4. It doesn't fix all of the missing dependencies that have been missi= ng >> forever such as crt, csu, libgcc, etc for static builds. >> 5. the csu builds don't use it yet but have workarounds for it >> 6. removing the 'make depend' tree-walk can hurt downstream builds whi= ch >> relied on having a multi-phase build to generate a .mk file to include= >> (odd case I hit at work). No such case exists in the upstream FreeBSD= tree. >> >=20 > There are two different things: pure recursive dependency (it is how > make depends works now) and just nested include graph with dependencies= > marked directly by Makefile's rules (it is how old system works). Now i= t > is enough to touch some low level include to rebuild everything, before= > only files which include it directly or have make rules for it are rebu= ilt. No. The build and how dependencies are generated and handled is still fundamentally the same. Open the .depend.* files and see. It is only simple dependencies for the target built. There's nothing new about its content. If foo.c includes stdlib.h then it includes sys/_types.h which includes sys/cdefs.h, etc. This graph is in the old (mkdep) and new =2Edepend* content. This is easily provable by just comparing mkdep output to the new versions. Without specific evidence of a bug I cannot help. --=20 Regards, Bryan Drewery --mWjNBtQCvHWjeJue6uD70R4rLuha3som4-- --uI4colgDmiHCGoBqnq4vHn7Fgjc1TNnnU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXTz+3AAoJEDXXcbtuRpfPt54H/j9GOy+5pBiutKaKev5NXCbB B3CrdcMbHJk8PxiJyv2mVUcGDkCoxUqVpuEvX7rttuS4JfeQhQznlT8aWIMSf+Sc Dqo/F209yJnLsDQe6urzoQUfp1MvXXbUnoNXQgKUlCStehUnP+v8FFsn8akoVp3H csqNhXYMAT0v5PHeioaxE/7Co285cQfUCZE3ZUWbotc+f4uK8RyRXh8FMyzjQg6s vg25jZYkCkxrgVUsLwXQBUOT5iSAxQk8HTxqiC+yJloCIBaox5DEkq2+ofxLPOmT SiXLwcUdfQ1IQQhDBiet+2KLM9og58CODc1rtHPGydy8m3Io9V51JMuu1aEJgf0= =0D3b -----END PGP SIGNATURE----- --uI4colgDmiHCGoBqnq4vHn7Fgjc1TNnnU-- From owner-freebsd-current@freebsd.org Wed Jun 1 22:41: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 7BC72B66C01 for ; Wed, 1 Jun 2016 22:41:29 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 5B05C1036 for ; Wed, 1 Jun 2016 22:41:29 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 5A534B66BFC; Wed, 1 Jun 2016 22:41: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 578C5B66BFB for ; Wed, 1 Jun 2016 22:41:29 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 3776F1035; Wed, 1 Jun 2016 22:41:29 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 294F0172F; Wed, 1 Jun 2016 22:41:29 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id DB2371D68E; Wed, 1 Jun 2016 22:41:28 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id 53gaiiG3Rq4Y; Wed, 1 Jun 2016 22:41:26 +0000 (UTC) Subject: Re: [CFT] WITH_META_MODE: Working incremental build DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com BBD001D688 To: current@freebsd.org References: <20160531140608.GA24894@albert.catwhisker.org> <5c2283ef-def0-1bdd-4766-0d2a901e7580@FreeBSD.org> <48166.1464740223@kaos.jnpr.net> Cc: "Simon J. Gerraty" From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: Date: Wed, 1 Jun 2016 15:41:23 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PejOhvVLuQsaK2Eo1joDCcafoATF1osPX" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 22:41:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PejOhvVLuQsaK2Eo1joDCcafoATF1osPX Content-Type: multipart/mixed; boundary="SDPW3H2WIGnESJi2TDOcKxE2SEBtwfvEI" From: Bryan Drewery To: current@freebsd.org Cc: "Simon J. Gerraty" Message-ID: Subject: Re: [CFT] WITH_META_MODE: Working incremental build References: <20160531140608.GA24894@albert.catwhisker.org> <5c2283ef-def0-1bdd-4766-0d2a901e7580@FreeBSD.org> <48166.1464740223@kaos.jnpr.net> In-Reply-To: --SDPW3H2WIGnESJi2TDOcKxE2SEBtwfvEI Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 6/1/2016 10:27 AM, Bryan Drewery wrote: > On 5/31/2016 5:17 PM, Simon J. Gerraty wrote: >>> Another reported issue just now is that right after an installworld, >>> everything rebuilds due to changed /bin/sh (-dM flag to make tells yo= u >>> why things rebuild). I'll look into some mitigations for this. >> >> It is probably sufficient to just add >> >> .MAKE.META.IGNORE_PATHS +=3D ${__MAKE_SHELL} >> >=20 > Yes but I need to test it fully to see if things like rtld and > libmap.conf, etc, get caught up in the problem too. >=20 Yup, it's not really simple to fix. This problem defeats the goal of the feature too. I had not ran into this case in all of my testing since I wasn't installing to /. For /bin/sh it uses libc.so.7, libedit.so.7, libncursesw.so.8, rtld, and /usr/share/locale. We could use /rescue/sh if it exists to remove a lot of that and still ignore __MAKE_SHELL and /usr/share/locale. The next problem is everything else. expr(1), awk(1), sed(1), rm(1). There's a /rescue version for those except for awk(1). Solving that we could add /rescue into the default PATH for the build, or build all of these tools in build-tools. Though any use of them to bootstrap building them could cause the same rebuild problem and a chain reaction of rebuilds. Even adding all of the build tools as static wouldn't be enough. Any tool that is used that is not easily changed to static still leaks in all of rtld and dynamic libraries. My build is running ccache which finds that /lib/libm.so.5 is newer. We can't just ignore /lib /usr/lib /bin, etc, because we need the compiler tools and other obscure tools to be considered in case they do get changes or fixes to them. If awk(1) gets a fix it may actually impact the build. It's too bad bmake is only doing a simple mtime comparison and not a content comparison like ccache does. That wouldn't solve much anyhow since a change to __FreeBSD_version would modify the hash of all of the binaries. Of course doing a content comparison means filemon needs to calculate and store that which is not ideal. --=20 Regards, Bryan Drewery --SDPW3H2WIGnESJi2TDOcKxE2SEBtwfvEI-- --PejOhvVLuQsaK2Eo1joDCcafoATF1osPX 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 iQEcBAEBAgAGBQJXT2STAAoJEDXXcbtuRpfPAoIH/10FY9A3QrIzhNaIh93JVf5M xzA903zCsSEndc4Qay3yvae3ckdwd7HS0Mq2qbunBd/q4QLcJNZpyA+CKf8nNfoI ZnYEXkAHHGKU9YJpiPDYOjrCfw/yoJhHWvURzMIM8XX9u99aNSiejvcQ3yplLSF8 dVVFwbIB67d1nTbtSoVYlK105TT6MTzvTiYKN7gNRfihjq+UOtDAxBBiP1ndVrO/ KwmhNtSzivBJEnSlYgLx2/KRJfr2zFtfU8I7ylDp5DDtDJvxMW+AiKyMnSu5fx6L rT9coc73gj39aBeZvmpbkh58nSSRRwI1CCitbqWQVb8IKdAeU/kLn9Y8JXAqaas= =U1M3 -----END PGP SIGNATURE----- --PejOhvVLuQsaK2Eo1joDCcafoATF1osPX-- From owner-freebsd-current@freebsd.org Wed Jun 1 23:53: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 C455AB67107 for ; Wed, 1 Jun 2016 23:53:38 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 6D4551B83 for ; Wed, 1 Jun 2016 23:53:38 +0000 (UTC) (envelope-from sjg@juniper.net) Received: by mailman.ysv.freebsd.org (Postfix) id 688B7B67106; Wed, 1 Jun 2016 23:53: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 682C3B67105 for ; Wed, 1 Jun 2016 23:53:38 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0117.outbound.protection.outlook.com [65.55.169.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A5CE41B81; Wed, 1 Jun 2016 23:53:37 +0000 (UTC) (envelope-from sjg@juniper.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uSvZV3NAidJIM+4IOb1ddWuB56xTx74K1HeiKYWetPM=; b=WmS7w1LbXV62f7w2tO475y7X1s1Sr+gjoWkpX6+p9qAaiQ4iSDu1O63MxK5F7KvEGGgpi8TJRsn50vu97GtgLz5dipsXie6E1EedRVpKMizJ6xTxrt1+ibHZHoz6o0TZDtzFprU15LVoQ6LybzKmbLR+f4GP+jhMKjUMQKmQZ5U= Received: from DM2PR0501CA0029.namprd05.prod.outlook.com (10.162.29.167) by SN2PR05MB2462.namprd05.prod.outlook.com (10.166.213.7) with Microsoft SMTP Server (TLS) id 15.1.506.9; Wed, 1 Jun 2016 23:38:45 +0000 Received: from BN1BFFO11FD054.protection.gbl (2a01:111:f400:7c10::1:122) by DM2PR0501CA0029.outlook.office365.com (2a01:111:e400:5148::39) with Microsoft SMTP Server (TLS) id 15.1.506.9 via Frontend Transport; Wed, 1 Jun 2016 23:38:45 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.19) smtp.mailfrom=juniper.net; FreeBSD.org; dkim=none (message not signed) header.d=none;FreeBSD.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.19 as permitted sender) Received: from P-EMFE01C-SAC.jnpr.net (66.129.239.19) by BN1BFFO11FD054.mail.protection.outlook.com (10.58.145.9) with Microsoft SMTP Server (TLS) id 15.1.497.8 via Frontend Transport; Wed, 1 Jun 2016 23:38:44 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMFE01C-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 1 Jun 2016 16:38:43 -0700 Received: from kaos.jnpr.net (kaos.jnpr.net [172.21.16.84]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id u51NchJ30462; Wed, 1 Jun 2016 16:38:43 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 061F1385551; Wed, 1 Jun 2016 16:38:43 -0700 (PDT) To: Bryan Drewery CC: , Subject: Re: [CFT] WITH_META_MODE: Working incremental build In-Reply-To: References: <20160531140608.GA24894@albert.catwhisker.org> <5c2283ef-def0-1bdd-4766-0d2a901e7580@FreeBSD.org> <48166.1464740223@kaos.jnpr.net> Comments: In-reply-to: Bryan Drewery message dated "Wed, 01 Jun 2016 15:41:23 -0700." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <74006.1464824322.1@kaos.jnpr.net> Date: Wed, 1 Jun 2016 16:38:42 -0700 Message-ID: <74007.1464824322@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.19; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(24454002)(189002)(199003)(9170700003)(92566002)(23726003)(81166006)(19580395003)(50466002)(76176999)(50986999)(19580405001)(2906002)(4001430100002)(2950100001)(8676002)(8936002)(107886002)(87936001)(4326007)(77096005)(93886004)(105596002)(117636001)(46406003)(47776003)(106466001)(110136002)(9686002)(11100500001)(2810700001)(450100001)(76506005)(189998001)(86362001)(53416004)(97756001)(6806005)(5003600100002)(586003)(50226002)(5008740100001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2462; H:P-EMFE01C-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD054; 1:8B274Q+XSLMRzSsOr/ZUszMMM3IVDXp5BoPnrIUXxRvWVjwKTPMpAqDgpfABHfvSX/EBxHN9bIlJMLYikZn4g3Fodei1CZYl1tWFo198xqxLc5MjwfwIwkNYbD+5aJ/j7xMbmWtiQt1grqrwfzrpcCO2+QZiIFX+NrGcnDlER7lLqLa5PypW0/1aXqSfG4f6zWmbZ9OPKyODxbK303Pp8LoMWN1iwT6pAzkLNbdiVAGAk6WsO2xjHw+XeYMb670NT4c417c2eR3K5fhCK+o0pHMI75ql3Ni5Gja8Ny7PSZSTbTnx48fPyjriEHIcb76cAFjUmmR8lGYuuHUyaOL5vRSNR447T0G7I+s+fcC81YNIfuBS4VkZ47FQcBzyA8UA9L+pRqmbuawglP9ufM6wDaG5fOLVa5WvZlvYnS7J0eUng5EsK07z5WGPKeYBFxTey2bUvlLmy+9JSfd8sOj7gjU23zFN+4DYCm29TTQ55TI= X-MS-Office365-Filtering-Correlation-Id: 454713eb-ed5c-4b3b-6696-08d38a75df21 X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2462; 2:I01GM7Oqy2JVRGk7CKPec6N0+h4ZVfkswhVH3IlLHOVB9mi3mimr60JgfT87yJUaFV3z4ZBzrWRr3dGvtzGtCVwjmpfcWOMZ7nh5+8MvXsbaltoe/jkEIAvflyU8s2u+mhQcAT7PTG/5Emi3wv+y2dGdKetrf+z4A20gyaNxS/LrYLGk91fYuzuXNTLpGUyA; 3:YeExZz2Xr+rnm0X3HmRdCSBLrQJPRkL8oa12owGz8YcIjPspj4R6xdUyESGHqXy4oCXJitzRz9X/MtGHPsOtOIFDXW/Zj/chIvhlxIb0AXb43ElnD9fK14ByzhuR5gIhs3/UVQoWf7u+593mK0weV8tK3KQ1oxaqir+49VHX8l+T5xkYYtaLzIExAWLzbftYukGrAr896HyMxbReQAcPMdj9UfY678PSrqEvEnSX4xQ=; 25:SR7IMLVyphzZNqEsrAH5Dw++oHy0lkSyaBfmbdwIdOrAR7LwzIoXDwXo//YR0M3GnFOkX5jVs6FB7Df4xwZbZWWqW/yKNBGE5yIaXNgRNfIeKp6KfPLcOgwuYx1EL7M4K6o/A3KW2oWybL0zjWrr54Y2ZBAYnYrGLwzlR5wJUr+spRZz7kdZ7t7t/1kbQFidnZLY6+WRK+ZBI8mOsX9091+g9RoihgpkaIdPxbH6ZRg/g+JYtI87dLiL+iNgsw5F49vpChKoM5dxv8laFX176oX/FA4BtGgBwt/794D/n1ISzeHK7Vz7tAVUQSV0m8l88ABsUd/jCFM8tjdjI4abXnghqxmyDpebIeflHhrIscFGPhTUp6J89y8yXE+O378q0F+vlz8+8gbkKp6SZgz7UQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR05MB2462; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2462; 20:65K9OVgS7alrmQj/AUC9wzIH5ffcBsPbCAFS8Tf4Ccsm6dXG4wAV8nFoVntcesfFWfEpEI0KkkeQj/ab9UWRKs+g3JSwV+aZ8h0wF4PxRyqGzeCKAY84cuGejHmimKpmmnFggcJTKQiU4B6ZBNgjBxRx8+1vwnhPJjyjQGwBSMHrdIJncNC2Ufso6qe2hRI5S/TLGbk01OGoUhnb95CMsDaKw7CPr5p0ZwRuaDwUnDDvwv/jIWE2pJ5oiuCVqMJimUV2z6jLvpyvyTwSVJjp6+EA6U/MXQCyc7fHrh3AxNdnI+rzsHfuq/nDOHVYfCSvPUnPo1rT+6WBUM6xbAnutc0jIawfznWDuxDA+MJX9R3TaintkQmoVyIoJVajWhrVy43q6o16I3VF3ml6YP2CJQvmPzDJPI5RX90ZS/tBBoyq4KJQwrqsV5erLvC5lZIik36TCq9D7VUad75h3HLliP/NWOSNt1CFyi0a+otH7JOBxFCpEJtOKdprzlhJBVAg X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13018025)(8121501046)(13015025)(13017025)(5005006)(13024025)(13023025)(3002001)(10201501046)(6055026); SRVR:SN2PR05MB2462; BCL:0; PCL:0; RULEID:; SRVR:SN2PR05MB2462; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2462; 4:zmZru1W/tBHKk9smwR6xfoFOrHtBs12HAHEgx5rD4IjNoJbsnfeJ31yLGavL99ItmNlvFLOhH02Ql+zgGjFrazi+/XVmR4WdjLyrgTLDN2wUVAbmx0Xrs+71JeLoHmVuifBot1ev7lWhE32aBvgO3YjrH+RQ9BJti/4c9Rw9D1cgGp996jP/1TkOGCsygTtT9fC4dWXE+4GSlA/9m/NvbueKwSDNZyrXvcgfsFAyynMv6Bbj1g7GmFDS0REDQWnkXSe0dzZOnJktoSje/RgSll6uE0uKtf7qDXEwcMjrhaXbtwjPHgGLrp9FHVY6fteWV0qCPLziIAsrI15Dlt3fJmdMwLhvjhCOUcFGKjfSd6XKfiFTmuJYbBuV47dIaQKZ34+Z/Rz6abOi2idEmrBdwVpduZHwqj23E68dC+fKHOX+uLHgYvHkF6cJM3tVDOMUp6plWBDaVf2mrjauZNd4HSFVcjLrwst+MBaVxjGekIw= X-Forefront-PRVS: 096029FF66 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2462; 23:/PQ5DXfcALRKn2/r1VlAMVVZKhXO9+m+k5iEszLZF?= =?us-ascii?Q?bfqUXr3lTtbu88+gZ0OxYSGFdryeiEU/+owEpxgGGVPeJogXPNs5ZS5EUVvI?= =?us-ascii?Q?K0dJ1M4b95rYHm3nMZQDJd/FinNKPHuIMsCSbCqy7VZ1GNGdfwr2kuxHLd/S?= =?us-ascii?Q?DQqHfcbZ6durulUuOsePKnN8gcUv0ikTQqrIqHYSsZ8fKY+Rg5KNmAyFuIUB?= =?us-ascii?Q?cRxSacg8byUy2LwqWI8bnx+Um+nOieLNPiQCHsJ2xewUaRolKNh2RuHuD4EL?= =?us-ascii?Q?dFMBYlFimFL4sZ9IpoCJCBt6hvCHjSiPLNMBAP74gqSu3sx8jPUsdo4i75Jt?= =?us-ascii?Q?WHDlRj8WG61a2YbLWnyboGtJViMpF7esZrWfiKl15u3yq134hzo5EkTzsy3x?= =?us-ascii?Q?KLNVc7/qVlRFHkRWo4rtnvU83CywNGARBuiiZ0y3mbMW0P97yr27NcV2uquZ?= =?us-ascii?Q?c1HijsLV9vpWOw9JMdT+qxBMKI0vZpIOeX/GyYHsiiKZ7M0TiAeJb115smQ+?= =?us-ascii?Q?MJqEvr2NaN2Gnc+VNsh61Kl3F6rbJK4Ya8m2oLZVRtnc/g8wlgf093Cv5hRq?= =?us-ascii?Q?fFwyDhcVHv2EEtBrP1aZmnaaomOdmMt7S75DJ7FDqhEXgvUuw+ebupS9EHJA?= =?us-ascii?Q?fL+xmGVY4rjHuE4dJvZJ0dRpFz+ezcZdXF1vt2yl9GqUyHJp+FOQ1o9BcfiG?= =?us-ascii?Q?uBVxgYJcBFqpsq3GwYQ0czKQ/c2Fno1Aw65zZ5VXuWa1aQLUDSJ/aSW1J9fu?= =?us-ascii?Q?E/kQzlY/MvGqObKkieeW7CeQR4qChgTLQY5Y0iLk01tbkPhzdzRs+qCMnpjK?= =?us-ascii?Q?cIp8Oss1K/eoNar9N6vuLa+ThSsmdIARkd8ivRo3uSYSb1QK7r0lrUpngO1u?= =?us-ascii?Q?FYSh9xRcQuV1qep3eS0hhkMB7NuyixXtwm9lpQSBnVUn5LAMGjDvO++Ps9cb?= =?us-ascii?Q?nphisNknpwk2V0l1jP4NmzjPxW/7w3hlqSw7iPcc38iuz5d9TcXuCoD+R9Jc?= =?us-ascii?Q?lQRXui7txMQYj9dgmhCnPaCE+mb6pfQeEk+juqH/xx67K+KTVoAfLhpd7YoU?= =?us-ascii?Q?i95+R7sUJHS0xL1Q87e6CmSerRlLVYUnxqm0oAA9lxFmxwuyOX5YGmmkckO8?= =?us-ascii?Q?nMOxgEcBkYQlHvADjaDpJ1kUqn4vhHF5XhUKW/4TO2IHSDWnTyFWw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2462; 5:HAFuxHkS4RYLf0/D7q5alXgR34yEZamcS9i3zvrW2xcaVOP80UOEUWpk6GYOV3NkywkLutO4f/4OLFh8JmvygU2jisP41fTpNmTdEiQwOwHxidatuhNtx3lMxkyw3ta0b0MZGdjhwcAIxrfQ7zAWXw==; 24:HnifsiZChqVXbA64W4KwE/Gi+Ow3kQo8hbz7TPOE/zguj8TO7uXuKax49oZmd++Ue3YvrE1WpCu/rD45yxvGeNJMDiq+XxT1os2W55fcQ1M=; 7:m+T4rZYqebDjRon9BB602SIU5k6cMpyyJaZbmp16AhAAGWbCBHUQcRlEBVYjQhc6WFl6jPdqtsdgcb3AR2RkyHVjex3Km2ieGRhcCVGy1xXvB4CvqmQuxyFBucbHGuTP552u/2ZjqYaE8CIz3w2To1ZbOJLw/J8kqV0cdeornfcaCAopJ/WjXYQOH3g68C5s SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jun 2016 23:38:44.5098 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.19]; Helo=[P-EMFE01C-SAC.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2462 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 23:53:38 -0000 Bryan Drewery wrote: > Yup, it's not really simple to fix. This problem defeats the goal of > the feature too. I had not ran into this case in all of my testing since > I wasn't installing to /. I never do that either (except for bmake). I'm guessing that installworld it is a rare event - compared to building. Touching everything in objtree as part of that might be a crude workaround. From owner-freebsd-current@freebsd.org Thu Jun 2 00:06:23 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 98E7EB67803 for ; Thu, 2 Jun 2016 00:06:23 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 77BE81FB9; Thu, 2 Jun 2016 00:06:23 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 6C0ED1B74; Thu, 2 Jun 2016 00:06:23 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 1EF421D7D7; Thu, 2 Jun 2016 00:06:23 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id MEzYjZhhtCnv; Thu, 2 Jun 2016 00:06:20 +0000 (UTC) Subject: Re: 11.0 -r301139: WITH_META_MODE=yes vs. "sh: ./make_keys: Exec format error"? DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com B84BC1D7D2 To: Mark Millard References: <890D3808-1939-4BEA-886F-324EBA8C8671@dsl-only.net> <0b75f448-047f-53b3-3e1b-7de17a2da949@FreeBSD.org> <943D8647-5894-4E6D-AB49-02EAF39433F4@dsl-only.net> Cc: FreeBSD Current From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <3f46eda7-0e66-a113-6f85-24f9c3fc4f4f@FreeBSD.org> Date: Wed, 1 Jun 2016 17:06:17 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <943D8647-5894-4E6D-AB49-02EAF39433F4@dsl-only.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="V6SLpJdpfj6pwX7ETuntmIEfJkFMDxVmk" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 00:06:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --V6SLpJdpfj6pwX7ETuntmIEfJkFMDxVmk Content-Type: multipart/mixed; boundary="09RPEgfqTInCHEmNli4LxnTwqeXafsv8H" From: Bryan Drewery To: Mark Millard Cc: FreeBSD Current Message-ID: <3f46eda7-0e66-a113-6f85-24f9c3fc4f4f@FreeBSD.org> Subject: Re: 11.0 -r301139: WITH_META_MODE=yes vs. "sh: ./make_keys: Exec format error"? References: <890D3808-1939-4BEA-886F-324EBA8C8671@dsl-only.net> <0b75f448-047f-53b3-3e1b-7de17a2da949@FreeBSD.org> <943D8647-5894-4E6D-AB49-02EAF39433F4@dsl-only.net> In-Reply-To: <943D8647-5894-4E6D-AB49-02EAF39433F4@dsl-only.net> --09RPEgfqTInCHEmNli4LxnTwqeXafsv8H Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/1/2016 4:48 PM, Mark Millard wrote: > On 2016-Jun-1, at 4:30 PM, Bryan Drewery wrot= e: >=20 >> On 6/1/2016 4:29 PM, Bryan Drewery wrote: >>> On 6/1/2016 4:25 PM, Mark Millard wrote: >>>> [The example context here for extracted materials is a amd64 -> armv= 6 cross build.] >>>> >>>> In my recent experimentation with WITH_META_MODE=3Dyes I=E2=80=99ve = had multiple occasions when after updating /usr/src I attempt buildworld = buildkernel and end up with something like: >>>>> --- lib/ncurses/ncursesw__L --- >>>>> Building /usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncursesw/init= _keytry.h >>>>> --- init_keytry.h --- >>>>> sh: ./make_keys: Exec format error >>>>> *** [init_keytry.h] Error code 126 >>>>> >>>>> make[4]: stopped in /usr/src/lib/ncurses/ncursesw >>>>> 1 error >>>>> >>>>> make[4]: stopped in /usr/src/lib/ncurses/ncursesw >>>>> *** [lib/ncurses/ncursesw__L] Error code 2 >>>> I=E2=80=99ve also had such for powerpc being the target and make too= lchain in use (preparing for buildkernel without buildworld). >>>> >>>> There are multiple instances of make_keys construction in the builds= =2E Here it looks like: >>>>> # grep make_keys ~/sys_typescripts/typescript_make_rpi2_nodebug_cla= ng_bootstrap-amd64-host-2016-06-01:15:17:28 >>>>> Building /usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncursesw/make= _keys >>>>> Building /usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncurses/make_= keys >>>>> Building /usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncursesw/make= _keys >>>>> sh: ./make_keys: Exec format error >>>> Note that ncursesw has two Building lines above with the same path l= isted. >>>> >>>> cleanworld and then retrying the sequence desired always seems to wo= rk but is a complete rebuild. >>> >>> I don't understand why you're hitting this. It's an issue that I ran >>> into and fixed and haven't run into again from several powerpc64 buil= d >>> tests. >>> >> >> It's possible r301079 reintroduced the bug. I'll find out. >> >> --=20 >> Regards, >> Bryan Drewery >=20 > [All the below is from an amd64 host context.] >=20 > As far as I remember I've not seen "sh: ./make_keys: Exec format error"= when powerpc64-gcc or amd64-gcc is in use (my xtoolchain experiments): m= y src.conf files for such have more in them and various other differences= for those because of binding to powerpc64-gcc or amd64-gcc and the relat= ed binutils. >=20 > [The below do not involve ports compilers/tools.] >=20 > I have seen "sh: ./make_keys: Exec format error" when clang or gcc 4.2.= 1 is being used for the cross compiles. My armv6 context has a clang base= d buildworld and buildkernel. My powerpc kernel builds have a gcc 4.2.1 b= ased buildkernel (no buildworld). >=20 > I've not seen the problem for amd64 targeting amd64 via clang as far as= I can remember. I've not tried WITH_META_MODE=3Dyes for any other self-t= argeting context yet. >=20 Yup it is due to r301079. Will have to think on this. It was a temporary workaround until bmake was fixed. --=20 Regards, Bryan Drewery --09RPEgfqTInCHEmNli4LxnTwqeXafsv8H-- --V6SLpJdpfj6pwX7ETuntmIEfJkFMDxVmk 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 iQEcBAEBAgAGBQJXT3h5AAoJEDXXcbtuRpfPa8cH/3WMfGlKu+UP8DqAJMxTrl9n EGaBpGaFATI2DmwYUtEjBFNFBLTZwdYfIIkw8GXx/mN57RHCAB5PiCY4O5T0zCmV hZRbipL69JrEcb5L6N35EDyxU6lZft41iXe9+FDa7OBmHrag8nChW47DBfJqFT7n ly9MzBmVep28q3DAZat6kZ5PjIeYKIyhbmZSddMq+WFOJIKPtXmKN1p6bvsLgYVD UTuX0/Wf0z6VKQmpuwndUrANIWT/5vAwmaM0yTgw2Z++zSmQb0CYGsCwp3XOeSXb qV4zwWkqx4rDJpvXDi0ZtS8PfifSnq3Mpsv9FcoEuZEo9AUEljTlJQw9o/duqYU= =/p19 -----END PGP SIGNATURE----- --V6SLpJdpfj6pwX7ETuntmIEfJkFMDxVmk-- From owner-freebsd-current@freebsd.org Thu Jun 2 01:07: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 35B77B6072F for ; Thu, 2 Jun 2016 01:07:59 +0000 (UTC) (envelope-from raycherng@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 0847B1E48 for ; Thu, 2 Jun 2016 01:07:59 +0000 (UTC) (envelope-from raycherng@gmail.com) Received: by mail-io0-x232.google.com with SMTP id t40so33417704ioi.0 for ; Wed, 01 Jun 2016 18:07:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=m8dNEsc+9pRjCAEUoQsp+fPCeb6LNOfozwDMUYY3lYA=; b=uX/aQTrLaLg6zQLtoKDaOvRBCgwkjYxmyobW5n0ipZIpePUHqgNjo9CDmHszL2Lm0T W46uU66tgVbgRLdW49SZ3S5DoQeZlIu43bW/zq8q3xr+CblM1IJRDTTSTphlKHWkBCbi CREf/tKjUIm0adbu75DNzS/2M2IWipYuCf+0SxRIvrfipg8EoKuS0ygNVMGtryk5rlGi AoScA4ex9Zg8+pPM321KMUUs7iUxrapUZB+ybneELyekt7zrhePwFLHiZULGHsOgY10E QU/k+FasZyDsryEtXc4ujsl7HQKw/bIDi0h9nJqDphYWEy1Kes59lN0AqzzDPhH/zQiW Fxfw== 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; bh=m8dNEsc+9pRjCAEUoQsp+fPCeb6LNOfozwDMUYY3lYA=; b=YuLIzrwkMfOm2Jujlr9d5OoXrIv9GdtVGktFXgZOXmesHLJUEEXK5f1cHHh9os5vo4 OcAYB1eClji8q90vzZM7Swt2gWndyo2ZSahSaGtlw5hRprWi7FxjqXyntFJb/8ex8Om+ x2Uc7ZOYbLzY3hiVN9SOFS3Ubh59yz/IcQJwep5I4G+suNM0g/fVMIssjOS1GNVjLPSG oRms+2evKgkZ35Tq56Laz4yFia1q/OYlAHGIyyQswN4DokAD3pwsL8l8NGLJzc+ZVD/B 6cLF6m0a1Nnr3Ih2LFHqYXvgGS++MSFc0nHxjJaRj///JdHlhhJkELshJ1+F8XzGS8cw 956g== X-Gm-Message-State: ALyK8tLePEJ0hY77ytygnnznE73lJDAIkU/GgA1e/oBx6OhGIVBXbaJtxEpfg9HSnxVHPEOfPgRPR8Wqqi3zbQ== MIME-Version: 1.0 X-Received: by 10.107.168.42 with SMTP id r42mr491259ioe.179.1464829678362; Wed, 01 Jun 2016 18:07:58 -0700 (PDT) Received: by 10.107.151.7 with HTTP; Wed, 1 Jun 2016 18:07:58 -0700 (PDT) Date: Thu, 2 Jun 2016 09:07:58 +0800 Message-ID: Subject: Suddenly poweroff in 11-Current r300097 From: RayCherng Yu To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 01:07:59 -0000 I got a suddenly poweroff in r300097 (and previous revision in April and May) when I built textproc/docproj. My machine is Macbook Pro 13 2011 early. I have checked the Apple website. My bios is the latest version. Actually it also happened in 10.3-STABLE. It happened when the machine load was heavy. Before it shutdown, the fan started to run very loudly. After several seconds (20 or 30 seconds), my laptop shutdown (poweroff directly) suddenly. It seems not happen with the AC power supply connected. I installed both Mac OSX and FreeBSD (dual boot). It never happened in Mac OSX. My dmesg: http://pastebin.com/QjZmbGCB My sysctl hw.acpi: hw.acpi.acline: 0 hw.acpi.battery.info_expire: 5 hw.acpi.battery.units: 1 hw.acpi.battery.state: 1 hw.acpi.battery.time: 87 hw.acpi.battery.life: 59 hw.acpi.cpu.cx_lowest: C8 hw.acpi.reset_video: 0 hw.acpi.handle_reboot: 1 hw.acpi.disable_on_reboot: 0 hw.acpi.verbose: 0 hw.acpi.s4bios: 0 hw.acpi.sleep_delay: 1 hw.acpi.suspend_state: S3 hw.acpi.standby_state: NONE hw.acpi.lid_switch_state: NONE hw.acpi.sleep_button_state: S3 hw.acpi.power_button_state: S5 hw.acpi.supported_sleep_state: S3 S4 S5 My acpidump: https://drive.google.com/open?id=3D0B143oZhcZhxMWHAtcGJ0VENwLTQ Thanks --=20 "Life is like a snowball. The important thing is finding wet snow and a really long hill." "Price is what you pay. Value is what you get." "The first rule of Investing is don't lose money; the second rule is don't forget rule #1..." "Wall Street is the only place that people ride to work in a Rolls-Royce to get advice from those who take the subway..." =E2=80=94 Warren Buffett. From owner-freebsd-current@freebsd.org Thu Jun 2 01:59: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 E1C8BB663FD; Thu, 2 Jun 2016 01:59:14 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id B945E1865; Thu, 2 Jun 2016 01:59:14 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id B21991184; Thu, 2 Jun 2016 01:59:14 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 680861D8CD; Thu, 2 Jun 2016 01:59:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id coMKWc2xRSp5; Thu, 2 Jun 2016 01:59:07 +0000 (UTC) Subject: Re: [CFT] WITH_META_MODE: Working incremental build [only on i386 and amd64] [filemon fails to load on powerpc64] DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 3A5601D8C6 To: Mark Millard References: <7748cc71-3788-22ae-fcb2-699eae529310@FreeBSD.org> <9A1A624D-9286-4C0F-A435-D590E07C1149@dsl-only.net> Cc: FreeBSD Current , FreeBSD PowerPC ML , freebsd-arm From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <0165aee5-cf6f-8f01-1690-fc51995e2109@FreeBSD.org> Date: Wed, 1 Jun 2016 18:59:06 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <9A1A624D-9286-4C0F-A435-D590E07C1149@dsl-only.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wpQhcBiSidSfWegMn1VnRbgBXKEm1xPb4" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 01:59:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wpQhcBiSidSfWegMn1VnRbgBXKEm1xPb4 Content-Type: multipart/mixed; boundary="KrapAqaNvAILWcq5lb62iVMsRoFsq67D0" From: Bryan Drewery To: Mark Millard Cc: FreeBSD Current , FreeBSD PowerPC ML , freebsd-arm Message-ID: <0165aee5-cf6f-8f01-1690-fc51995e2109@FreeBSD.org> Subject: Re: [CFT] WITH_META_MODE: Working incremental build [only on i386 and amd64] [filemon fails to load on powerpc64] References: <7748cc71-3788-22ae-fcb2-699eae529310@FreeBSD.org> <9A1A624D-9286-4C0F-A435-D590E07C1149@dsl-only.net> In-Reply-To: <9A1A624D-9286-4C0F-A435-D590E07C1149@dsl-only.net> --KrapAqaNvAILWcq5lb62iVMsRoFsq67D0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 6/1/2016 6:39 PM, Mark Millard wrote: > while filemon.ko now exists: >> # ls -l /boot/*/filemon* >> -r-xr-xr-x 1 root wheel 32064 Jun 1 17:59 /boot/kernel/filemon.ko > it does not load: >> # kldload -n filemon >> kldload: can't load filemon: No such file or directory >> # dmesg | grep link_elf >> link_elf: symbol elf64_freebsd_sysvec undefined There's 2 different ABI formats for powerpc64? > sys/powerpc/powerpc/elf64_machdep.c:INIT_SYSENTVEC(elf64_sysvec_v1, &el= f64_freebsd_sysvec_v1); > sys/powerpc/powerpc/elf64_machdep.c:INIT_SYSENTVEC(elf64_sysvec_v2, &el= f64_freebsd_sysvec_v2); What's up with that? --=20 Regards, Bryan Drewery --KrapAqaNvAILWcq5lb62iVMsRoFsq67D0-- --wpQhcBiSidSfWegMn1VnRbgBXKEm1xPb4 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 iQEcBAEBAgAGBQJXT5LqAAoJEDXXcbtuRpfPuJkIALXxZnfKFSpt4VutD4QcNNce wKBn0ZMx0D7y5m4bbPxQ18OcGZ3zMAuAxkOKl0ZLSS2v3nS9HgrYKdKAbBhzf7RT dyNORc3lnqfgXzDUM2YI506/PTzQoI0QjYNE5CrbLVqM59Hvq4vi7KClwIOTWbce rKklw++AiaQXa6TdvnoE8I6nNwWVW3maKPJzGLrSJELK4WUvsvVAwTgo+AfP3juF gUPhEe5Sf5ywZvhZtGh4+m7Fx3eLX6Y8QVO/0IC0enRp1Ppd2Vy8EeQh498ZMv4C lfgZHBYQn9MKY9rssWeDgLl67uORBApxTpxbLC8i+ZAiNik1uFogqg4Z7GdS29E= =rV7Y -----END PGP SIGNATURE----- --wpQhcBiSidSfWegMn1VnRbgBXKEm1xPb4-- From owner-freebsd-current@freebsd.org Thu Jun 2 07:17: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 384AEB63DFB for ; Thu, 2 Jun 2016 07:17:26 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 1C1DE110A for ; Thu, 2 Jun 2016 07:17:26 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mailman.ysv.freebsd.org (Postfix) id 17969B63DFA; Thu, 2 Jun 2016 07:17:26 +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 17406B63DF8 for ; Thu, 2 Jun 2016 07:17:26 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f54.google.com (mail-lf0-f54.google.com [209.85.215.54]) (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 BFCF21108 for ; Thu, 2 Jun 2016 07:17:25 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lf0-f54.google.com with SMTP id w16so27812047lfd.2 for ; Thu, 02 Jun 2016 00:17:25 -0700 (PDT) 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:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=3apO7YEzp5UVUgDyj/R1lncZuzTIFwlqzt77s68BcgQ=; b=Q2lbxZUNWF9b0qUgu6syFeG9aWq/WzUU9P5xSRU9bnYQJiYj87Y6XmZ6ouSCIyrX5U cuEgUT64Sibmqk1Iq85ldGjEdxCdBAVJK+40xElCkJJqUlJBB0KhcnVDGwZ0jgPEs5tb Q8qBMOJbN1FSGmD6kXsD9m9u8axaJpLODfUZvlRm1ouUv1FUCUQLsjzQPi2iQx3CRs5G DEUd3guE9NKSZ/SQEHuVt9pNHcg0yLsMsJflfA9vqSKYVK4C1C70oRuYntf2XbWZCRui yu+Hdr/l7ETGMd6/AfR5r2q8khqjOxgPiHbt4WnfiOyBR5TsRUwic78Q4BbsClWz8URF CLRA== X-Gm-Message-State: ALyK8tKEzCrJD12MnoZwKkvo8YOlu4ELhgsfDIhS0T6P/0CVK8J95ogI0oqSXAhBJxQj9A== X-Received: by 10.25.214.135 with SMTP id p7mr3465306lfi.92.1464851837544; Thu, 02 Jun 2016 00:17:17 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id u11sm3492217lja.16.2016.06.02.00.17.16 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Jun 2016 00:17:16 -0700 (PDT) From: Andrey Chernov Subject: Re: 'make depend' or 'make' bug on recent --current To: Bryan Drewery , current@freebsd.org References: <092f5e98-dae8-dbc9-2a6e-7068b972278f@freebsd.org> <311f3a82-b702-d375-170f-82ae39236ab0@FreeBSD.org> <7f325ac2-f722-c491-fca0-2e582773e780@FreeBSD.org> Message-ID: Date: Thu, 2 Jun 2016 10:17:15 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 07:17:26 -0000 On 01.06.2016 23:04, Bryan Drewery wrote: > No. The build and how dependencies are generated and handled is still > fundamentally the same. Open the .depend.* files and see. It is only > simple dependencies for the target built. There's nothing new about its > content. If foo.c includes stdlib.h then it includes sys/_types.h which > includes sys/cdefs.h, etc. This graph is in the old (mkdep) and new > .depend* content. This is easily provable by just comparing mkdep > output to the new versions. > > Without specific evidence of a bug I cannot help. Thanx for pointing me to MD *div sources, I overlook them. About 'make depend', I don't notice anything suspicious during simple tests and don't have time or energy to look deeper in that area. Probably several clang libs rebuilds during the single day while none usually expected cause my overreaction. From owner-freebsd-current@freebsd.org Thu Jun 2 01:39: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 421F5B62483 for ; Thu, 2 Jun 2016 01:39:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-175.reflexion.net [208.70.211.175]) (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 E98C51944 for ; Thu, 2 Jun 2016 01:39:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5091 invoked from network); 2 Jun 2016 01:39:33 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 2 Jun 2016 01:39:33 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Wed, 01 Jun 2016 21:40:10 -0400 (EDT) Received: (qmail 11417 invoked from network); 2 Jun 2016 01:40:10 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 2 Jun 2016 01:40:10 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 1C1B31C43D2; Wed, 1 Jun 2016 18:39:26 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [CFT] WITH_META_MODE: Working incremental build [only on i386 and amd64] [filemon fails to load on powerpc64] From: Mark Millard In-Reply-To: <7748cc71-3788-22ae-fcb2-699eae529310@FreeBSD.org> Date: Wed, 1 Jun 2016 18:39:30 -0700 Cc: FreeBSD Current , FreeBSD PowerPC ML , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <9A1A624D-9286-4C0F-A435-D590E07C1149@dsl-only.net> References: <7748cc71-3788-22ae-fcb2-699eae529310@FreeBSD.org> To: Bryan Drewery X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 01:39:39 -0000 [A top-posted error report for powerpc64.] On 2016-Jun-1, at 8:20 AM, Bryan Drewery = wrote: > I've just enabled the filemon(4) build on all architectures in = r301130. But on (built via powerpc64-gcc on the powerpc64 box): > # uname -apKU > FreeBSD FBSDG5C0 11.0-ALPHA1 FreeBSD 11.0-ALPHA1 #39 r301139M: Wed Jun = 1 17:37:17 PDT 2016 = root@FBSDG5C0:/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64v= tsc-NODEBUG powerpc powerpc64 1100116 1100116 while filemon.ko now exists: > # ls -l /boot/*/filemon* > -r-xr-xr-x 1 root wheel 32064 Jun 1 17:59 /boot/kernel/filemon.ko it does not load: > # kldload -n filemon > kldload: can't load filemon: No such file or directory > # dmesg | grep link_elf > link_elf: symbol elf64_freebsd_sysvec undefined So no WITH_META_MODE=3Dyes yet for powerpc64. I'm not sure when I get to trying the rpi2 (armv6). =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jun-1, at 8:20 AM, Bryan Drewery = wrote: > On 5/29/2016 3:53 PM, Mark Millard wrote: >> Quoting the original note about WITH_META_MODE ( = https://lists.freebsd.org/pipermail/freebsd-current/2016-May/061481.html = ): >>=20 >>> You will also need to load the filemon(4) module with 'kldload = filemon'. >>=20 >> But head's sys/modules/Makefile says: >>=20 >>> .if defined(MODULES_OVERRIDE) && !defined(ALL_MODULES) >>> SUBDIR=3D${MODULES_OVERRIDE} >>> .else >>> SUBDIR=3D \ >>=20 >> . . . >>> ${_filemon} \ >>=20 >> . . . >>> .if ${MACHINE_CPUARCH} =3D=3D "i386" || ${MACHINE_CPUARCH} =3D=3D = "amd64" >> . . . >>> _filemon=3D filemon >> . . . >>=20 >> as the only contexts that provide a filemon.ko to use with kldload. >>=20 >> Thus, for example, arm variants (32 bit and 64 bit) and powerpc = variants (32bit and 64 bit) do not have WITH_META_MODE as an option as = things are set up. >>=20 >> I had been hoping to cut down on the time for clang-related rebuilds = during native buildworld runs on my slower buildworld contexts = (armv7a/cortex-a7, powerpc, powerpc64). But it was not to be. >>=20 >> It appears that, once some arm variants are officially tier 1, = WITH_META_MODE will not span all tier 1 platforms. >>=20 >> [Since I tend to use non-tier-1 platforms I tend to notice some of = the statements about FreeBSD that are true of only tier 1 without being = explicit about it. But initially it takes some research to discover that = status for each such point. WITH_META_MODE is an example.] >>=20 >=20 > I've just enabled the filemon(4) build on all architectures in = r301130. >=20 > --=20 > Regards, > Bryan Drewery From owner-freebsd-current@freebsd.org Wed Jun 1 23:48: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 113F7B66E12 for ; Wed, 1 Jun 2016 23:48:47 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-182.reflexion.net [208.70.211.182]) (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 B9A1617AC for ; Wed, 1 Jun 2016 23:48:46 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 32738 invoked from network); 1 Jun 2016 23:49:10 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 1 Jun 2016 23:49:10 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Wed, 01 Jun 2016 19:48:36 -0400 (EDT) Received: (qmail 7351 invoked from network); 1 Jun 2016 23:48:36 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 1 Jun 2016 23:48:36 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id CBEAE1C43E2; Wed, 1 Jun 2016 16:48:33 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: 11.0 -r301139: WITH_META_MODE=yes vs. "sh: ./make_keys: Exec format error"? From: Mark Millard In-Reply-To: Date: Wed, 1 Jun 2016 16:48:38 -0700 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <943D8647-5894-4E6D-AB49-02EAF39433F4@dsl-only.net> References: <890D3808-1939-4BEA-886F-324EBA8C8671@dsl-only.net> <0b75f448-047f-53b3-3e1b-7de17a2da949@FreeBSD.org> To: Bryan Drewery X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 23:48:47 -0000 On 2016-Jun-1, at 4:30 PM, Bryan Drewery = wrote: > On 6/1/2016 4:29 PM, Bryan Drewery wrote: >> On 6/1/2016 4:25 PM, Mark Millard wrote: >>> [The example context here for extracted materials is a amd64 -> = armv6 cross build.] >>>=20 >>> In my recent experimentation with WITH_META_MODE=3Dyes I=E2=80=99ve = had multiple occasions when after updating /usr/src I attempt buildworld = buildkernel and end up with something like: >>>> --- lib/ncurses/ncursesw__L --- >>>> Building = /usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncursesw/init_keytry.h >>>> --- init_keytry.h --- >>>> sh: ./make_keys: Exec format error >>>> *** [init_keytry.h] Error code 126 >>>>=20 >>>> make[4]: stopped in /usr/src/lib/ncurses/ncursesw >>>> 1 error >>>>=20 >>>> make[4]: stopped in /usr/src/lib/ncurses/ncursesw >>>> *** [lib/ncurses/ncursesw__L] Error code 2 >>> I=E2=80=99ve also had such for powerpc being the target and make = toolchain in use (preparing for buildkernel without buildworld). >>>=20 >>> There are multiple instances of make_keys construction in the = builds. Here it looks like: >>>> # grep make_keys = ~/sys_typescripts/typescript_make_rpi2_nodebug_clang_bootstrap-amd64-host-= 2016-06-01:15:17:28 >>>> Building = /usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncursesw/make_keys >>>> Building = /usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncurses/make_keys >>>> Building = /usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncursesw/make_keys >>>> sh: ./make_keys: Exec format error >>> Note that ncursesw has two Building lines above with the same path = listed. >>>=20 >>> cleanworld and then retrying the sequence desired always seems to = work but is a complete rebuild. >>=20 >> I don't understand why you're hitting this. It's an issue that I ran >> into and fixed and haven't run into again from several powerpc64 = build >> tests. >>=20 >=20 > It's possible r301079 reintroduced the bug. I'll find out. >=20 > --=20 > Regards, > Bryan Drewery [All the below is from an amd64 host context.] As far as I remember I've not seen "sh: ./make_keys: Exec format error" = when powerpc64-gcc or amd64-gcc is in use (my xtoolchain experiments): = my src.conf files for such have more in them and various other = differences for those because of binding to powerpc64-gcc or amd64-gcc = and the related binutils. [The below do not involve ports compilers/tools.] I have seen "sh: ./make_keys: Exec format error" when clang or gcc 4.2.1 = is being used for the cross compiles. My armv6 context has a clang based = buildworld and buildkernel. My powerpc kernel builds have a gcc 4.2.1 = based buildkernel (no buildworld). I've not seen the problem for amd64 targeting amd64 via clang as far as = I can remember. I've not tried WITH_META_MODE=3Dyes for any other = self-targeting context yet. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Thu Jun 2 02:14: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 5EA5AB66DDE; Thu, 2 Jun 2016 02:14:25 +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 42F6D11A5; Thu, 2 Jun 2016 02:14:25 +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 3AFE7DDA; Thu, 2 Jun 2016 02:14:25 +0000 (UTC) Date: Thu, 2 Jun 2016 02:14:22 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: landonf@FreeBSD.org, truckman@FreeBSD.org, adrian@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <2144696675.14.1464833665255.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #3284 - 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.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 02:14:25 -0000 FreeBSD_HEAD_i386 - Build #3284 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3284/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3284/cha= nges Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3284/cons= ole Change summaries: 301181 by adrian: [ath] commit initial bluetooth coexistence support for the MCI NICs. This is the initial framework to call into the MCI HAL routines and drive the basic state engine. The MCI bluetooth coex model uses a command channel between wlan and bluetooth, rather than a 2-wire or 3-wire signaling protocol to control thi= ngs. This means the wlan and bluetooth chip exchange a lot more information and signaling, even at the per-packet level. The NICs in question can share the input LNA and output PA on the die, so they absolutely can't stomp on each other in a silly fashion. It also allows for the bluetooth side to signal when profiles come and go, so the driver can take appropriate control. There's also the possibility of dynamic bluetooth/wlan duty cycle control which I haven't yet really played with. It configures things up with a static "wlan wins everything" coexistence, configures up the available 2GHz channel map for bluetooth, sets a static duty cycle for bluetooth/wifi traffic priority and drives the basics needed= to keep the MCI HAL code happy. It doesn't do any actual coexistence except to default to "wlan wins everyt= hing", which at least demonstrates that things do indeed work. Bluetooth inquiry = frames still trump wifi (including beacons), so that demonstrates things really do indeed seem to work. Tested: * AR9462 (WB222), STA mode + bt * QCA9565 (WB335), STA mode + bt TODO: * .. the rest of coexistence. yes, bluetooth, not people. That stuff's ha= rd. * It doesn't do the initial BT side calibration, which requires a WLAN chip reset. I'll fix up the reset path a bit more first before I enable that. * The 1-ant and 2-ant configuration bits aren't being set correctly in if_ath_btcoex.c - I'll dig into that and fix it in a subsequent commit. * It's not enabled by default for WB222/WB225 even though I believe it now can be - I'll chase that up in a subsequent commit. Obtained from:=09Qualcomm Atheros, Linux ath9k 301180 by truckman: Belatedly bump .Dd date for Dummynet AQM import in r300779. 301179 by landonf: Add myself as src commiter. Approved by:=09adrian (mentor) Differential Revision:=09https://reviews.freebsd.org/D6686 The end of the build log: [...truncated 153335 lines...] cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -I. -I/usr/src/sys/modules/ath/../../dev/ath -I/usr/src/sys/modules/ath/= ../../dev/ath/ath_hal -I. -I/usr/src/sys/modules/ath/../../contrib/dev/ath/= ath_hal/ -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC= /opt_global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENE= RIC -MD -MF.depend.if_ath_tx_edma.o -MTif_ath_tx_edma.o -mno-mmx -mno-sse= -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wre= dundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -W= pointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__= =3D__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -= Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body = -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-poi= nter-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=3Diso989= 9:1999 -c /usr/src/sys/modules/ath/../../dev/ath/if_ath_tx_edma.c -o if_ath= _tx_edma.o --- all_subdir_ata --- --- all_subdir_ata/atapci/chipsets/atapromise --- =3D=3D=3D> ata/atapci/chipsets/atapromise (all) --- machine --- machine -> /usr/src/sys/i386/include --- x86 --- x86 -> /usr/src/sys/x86/include --- ata_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/ata/ata_if.m -h --- 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 --- pci_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/pci/pci_if.m -h --- ata-promise.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_= global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC = -MD -MF.depend.ata-promise.o -MTata-promise.o -mno-mmx -mno-sse -msoft-flo= at -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-dec= ls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ari= th -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__freebsd= _kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-= pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= no-error-shift-negative-value -mno-aes -mno-avx -std=3Diso9899:1999 -c /u= sr/src/sys/modules/ata/atapci/chipsets/atapromise/../../../../../dev/ata/ch= ipsets/ata-promise.c -o ata-promise.o --- all_subdir_ata/atapci/chipsets/atanvidia --- ctfconvert -L VERSION -g ata-nvidia.o --- atanvidia.kld --- ld -d -warn-common -r -d -o atanvidia.kld ata-nvidia.o ctfmerge -L VERSION -g -o atanvidia.kld ata-nvidia.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk atanvidia.kld export_syms | xargs -= J% objcopy % atanvidia.kld --- atanvidia.ko.full --- ld -Bshareable -d -warn-common -o atanvidia.ko.full atanvidia.kld --- atanvidia.ko.debug --- objcopy --only-keep-debug atanvidia.ko.full atanvidia.ko.debug --- atanvidia.ko --- objcopy --strip-debug --add-gnu-debuglink=3Datanvidia.ko.debug atanvidia.k= o.full atanvidia.ko --- all_subdir_bhnd --- =3D=3D=3D> bhnd (all) --- machine --- machine -> /usr/src/sys/i386/include --- x86 --- x86 -> /usr/src/sys/x86/include --- bhnd_nvram_map_data.h --- sh /usr/src/sys/dev/bhnd/tools/nvram_map_gen.sh /usr/src/sys/dev/bhnd/nvra= m/nvram_map -d --- all_subdir_ath --- ctfconvert -L VERSION -g if_ath_tx_edma.o --- if_ath_spectral.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -I. -I/usr/src/sys/modules/ath/../../dev/ath -I/usr/src/sys/modules/ath/= ../../dev/ath/ath_hal -I. -I/usr/src/sys/modules/ath/../../contrib/dev/ath/= ath_hal/ -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC= /opt_global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENE= RIC -MD -MF.depend.if_ath_spectral.o -MTif_ath_spectral.o -mno-mmx -mno-s= se -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -W= redundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes = -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf_= _=3D__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option = -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body= -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-po= inter-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=3Diso98= 99:1999 -c /usr/src/sys/modules/ath/../../dev/ath/if_ath_spectral.c -o if_a= th_spectral.o --- all_subdir_bhnd --- 396 variable records written to bhnd_nvram_map_data.h --- bhnd_bus_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/bhnd/bhnd_bus_if.= m -h --- bhnd_chipc_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/bhnd/cores/chipc/= bhnd_chipc_if.m -h --- bhnd_nvram_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/bhnd/nvram/bhnd_n= vram_if.m -h --- bhnd_nvram_map.h --- sh /usr/src/sys/dev/bhnd/tools/nvram_map_gen.sh /usr/src/sys/dev/bhnd/nvra= m/nvram_map -h --- all_subdir_ata --- --- all_subdir_ata/atapci/chipsets/atapromise --- ctfconvert -L VERSION -g ata-promise.o --- atapromise.kld --- ld -d -warn-common -r -d -o atapromise.kld ata-promise.o ctfmerge -L VERSION -g -o atapromise.kld ata-promise.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk atapromise.kld export_syms | xargs = -J% objcopy % atapromise.kld --- atapromise.ko.full --- ld -Bshareable -d -warn-common -o atapromise.ko.full atapromise.kld --- atapromise.ko.debug --- objcopy --only-keep-debug atapromise.ko.full atapromise.ko.debug --- atapromise.ko --- objcopy --strip-debug --add-gnu-debuglink=3Datapromise.ko.debug atapromise= .ko.full atapromise.ko --- all_subdir_ata/atapci/chipsets/ataserverworks --- =3D=3D=3D> ata/atapci/chipsets/ataserverworks (all) --- machine --- machine -> /usr/src/sys/i386/include --- x86 --- x86 -> /usr/src/sys/x86/include --- ata_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/ata/ata_if.m -h --- 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 --- all_subdir_bhnd --- 396 variable records written to bhnd_nvram_map.h --- bhnd_bus_if.c --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/bhnd/bhnd_bus_if.= m -c --- all_subdir_ath --- ctfconvert -L VERSION -g if_ath_spectral.o --- all_subdir_ata --- --- pci_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/pci/pci_if.m -h --- ata-serverworks.o --- --- all_subdir_bhnd --- --- bhnd_chipc_if.c --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/bhnd/cores/chipc/= bhnd_chipc_if.m -c --- all_subdir_ata --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_= global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC = -MD -MF.depend.ata-serverworks.o -MTata-serverworks.o -mno-mmx -mno-sse -m= soft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredun= dant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpoi= nter-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D_= _freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-= unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wn= o-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer= -sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=3Diso9899:19= 99 -c /usr/src/sys/modules/ata/atapci/chipsets/ataserverworks/../../../../.= ./dev/ata/chipsets/ata-serverworks.c -o ata-serverworks.o --- all_subdir_bhnd --- --- bhnd_nvram_if.c --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/bhnd/nvram/bhnd_n= vram_if.m -c --- 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 --- bhnd_subr.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_= global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC = -MD -MF.depend.bhnd_subr.o -MTbhnd_subr.o -mno-mmx -mno-sse -msoft-float -= ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -= Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -= Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__freebsd_kpr= intf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-prag= mas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-pare= ntheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-e= rror-shift-negative-value -mno-aes -mno-avx -std=3Diso9899:1999 -c /usr/s= rc/sys/modules/bhnd/../../dev/bhnd/bhnd_subr.c -o bhnd_subr.o --- all_subdir_ath --- --- if_ath_btcoex.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -I. -I/usr/src/sys/modules/ath/../../dev/ath -I/usr/src/sys/modules/ath/= ../../dev/ath/ath_hal -I. -I/usr/src/sys/modules/ath/../../contrib/dev/ath/= ath_hal/ -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC= /opt_global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENE= RIC -MD -MF.depend.if_ath_btcoex.o -MTif_ath_btcoex.o -mno-mmx -mno-sse -= msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredu= ndant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpo= inter-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D= __freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno= -unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -W= no-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointe= r-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=3Diso9899:1= 999 -c /usr/src/sys/modules/ath/../../dev/ath/if_ath_btcoex.c -o if_ath_btc= oex.o --- all_subdir_ata --- ctfconvert -L VERSION -g ata-serverworks.o --- ataserverworks.kld --- ld -d -warn-common -r -d -o ataserverworks.kld ata-serverworks.o ctfmerge -L VERSION -g -o ataserverworks.kld ata-serverworks.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk ataserverworks.kld export_syms | xa= rgs -J% objcopy % ataserverworks.kld --- ataserverworks.ko.full --- ld -Bshareable -d -warn-common -o ataserverworks.ko.full ataserverworks.kld --- ataserverworks.ko.debug --- objcopy --only-keep-debug ataserverworks.ko.full ataserverworks.ko.debug --- ataserverworks.ko --- objcopy --strip-debug --add-gnu-debuglink=3Dataserverworks.ko.debug ataser= verworks.ko.full ataserverworks.ko --- all_subdir_ata/atapci/chipsets/atasiliconimage --- =3D=3D=3D> ata/atapci/chipsets/atasiliconimage (all) --- machine --- machine -> /usr/src/sys/i386/include --- x86 --- x86 -> /usr/src/sys/x86/include --- ata_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/ata/ata_if.m -h --- 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 --- all_subdir_ath --- ctfconvert -L VERSION -g if_ath_btcoex.o --- all_subdir_ata --- --- pci_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/pci/pci_if.m -h --- ata-siliconimage.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_= global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC = -MD -MF.depend.ata-siliconimage.o -MTata-siliconimage.o -mno-mmx -mno-sse = -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wred= undant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wp= ointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__= =3D__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -= Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body = -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-poi= nter-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=3Diso989= 9:1999 -c /usr/src/sys/modules/ata/atapci/chipsets/atasiliconimage/../../..= /../../dev/ata/chipsets/ata-siliconimage.c -o ata-siliconimage.o --- all_subdir_ath --- --- if_ath_btcoex_mci.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -I. -I/usr/src/sys/modules/ath/../../dev/ath -I/usr/src/sys/modules/ath/= ../../dev/ath/ath_hal -I. -I/usr/src/sys/modules/ath/../../contrib/dev/ath/= ath_hal/ -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC= /opt_global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENE= RIC -MD -MF.depend.if_ath_btcoex_mci.o -MTif_ath_btcoex_mci.o -mno-mmx -m= no-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wal= l -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototy= pes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__pri= ntf__=3D__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-opti= on -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-= body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-erro= r-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=3Di= so9899:1999 -c /usr/src/sys/modules/ath/../../dev/ath/if_ath_btcoex_mci.c -= o if_ath_btcoex_mci.o --- all_subdir_bhnd --- ctfconvert -L VERSION -g bhnd_subr.o --- bhnd_sprom.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_= global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC = -MD -MF.depend.bhnd_sprom.o -MTbhnd_sprom.o -mno-mmx -mno-sse -msoft-float= -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls= -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith= -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__freebsd_k= printf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pr= agmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-pa= rentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno= -error-shift-negative-value -mno-aes -mno-avx -std=3Diso9899:1999 -c /usr= /src/sys/modules/bhnd/../../dev/bhnd/nvram/bhnd_sprom.c -o bhnd_sprom.o --- all_subdir_ata --- ctfconvert -L VERSION -g ata-siliconimage.o --- atasiliconimage.kld --- ld -d -warn-common -r -d -o atasiliconimage.kld ata-siliconimage.o --- all_subdir_ath --- /usr/src/sys/modules/ath/../../dev/ath/if_ath_btcoex_mci.c:610:11: error: u= nused variable 'value_dbm' [-Werror,-Wunused-variable] int8_t value_dbm =3D ath_hal_btcoex_mci_state(sc->s= c_ah, ^ --- all_subdir_ata --- ctfmerge -L VERSION -g -o atasiliconimage.kld ata-siliconimage.o --- all_subdir_ath --- 1 error generated. --- all_subdir_ata --- :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk atasiliconimage.kld export_syms | x= args -J% objcopy % atasiliconimage.kld --- all_subdir_ath --- *** [if_ath_btcoex_mci.o] Error code 1 bmake[4]: stopped in /usr/src/sys/modules/ath 1 error bmake[4]: stopped in /usr/src/sys/modules/ath *** [all_subdir_ath] Error code 2 bmake[3]: stopped in /usr/src/sys/modules --- all_subdir_ata --- A failure has been detected in another branch of the parallel make bmake[7]: stopped in /usr/src/sys/modules/ata/atapci/chipsets/atasiliconima= ge *** [all_subdir_ata/atapci/chipsets/atasiliconimage] Error code 2 bmake[6]: stopped in /usr/src/sys/modules/ata/atapci/chipsets 1 error bmake[6]: stopped in /usr/src/sys/modules/ata/atapci/chipsets *** [all_subdir_ata/atapci/chipsets] Error code 2 bmake[5]: stopped in /usr/src/sys/modules/ata/atapci 1 error bmake[5]: stopped in /usr/src/sys/modules/ata/atapci *** [all_subdir_ata/atapci] Error code 2 bmake[4]: stopped in /usr/src/sys/modules/ata 1 error bmake[4]: stopped in /usr/src/sys/modules/ata *** [all_subdir_ata] Error code 2 bmake[3]: stopped in /usr/src/sys/modules --- all_subdir_bhnd --- ctfconvert -L VERSION -g bhnd_sprom.o A failure has been detected in another branch of the parallel make bmake[4]: stopped in /usr/src/sys/modules/bhnd *** [all_subdir_bhnd] Error code 2 bmake[3]: stopped in /usr/src/sys/modules --- all_subdir_bge --- ctfconvert -L VERSION -g if_bge.o A failure has been detected in another branch of the parallel make bmake[4]: stopped in /usr/src/sys/modules/bge *** [all_subdir_bge] Error code 2 bmake[3]: stopped in /usr/src/sys/modules 4 errors bmake[3]: stopped in /usr/src/sys/modules *** [modules-all] Error code 2 bmake[2]: stopped in /usr/obj/usr/src/sys/GENERIC 1 error bmake[2]: stopped in /usr/obj/usr/src/sys/GENERIC *** [buildkernel] Error code 2 bmake[1]: stopped in /usr/src 1 error bmake[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/hudson2466617264196122383.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::104: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 Thu Jun 2 02:16:19 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2A248B66E67 for ; Thu, 2 Jun 2016 02:16:19 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-194.reflexion.net [208.70.211.194]) (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 E235311BE for ; Thu, 2 Jun 2016 02:16:18 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 16120 invoked from network); 2 Jun 2016 02:16:50 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 2 Jun 2016 02:16:50 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Wed, 01 Jun 2016 22:16:14 -0400 (EDT) Received: (qmail 9559 invoked from network); 2 Jun 2016 02:16:14 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 2 Jun 2016 02:16:14 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 131F81C43DB; Wed, 1 Jun 2016 19:16:11 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [CFT] WITH_META_MODE: Working incremental build [only on i386 and amd64] [filemon fails to load on powerpc64] From: Mark Millard In-Reply-To: <0165aee5-cf6f-8f01-1690-fc51995e2109@FreeBSD.org> Date: Wed, 1 Jun 2016 19:16:16 -0700 Cc: FreeBSD Current , FreeBSD PowerPC ML Message-Id: <35AFB7AC-7AD4-41D5-AA8D-87C37EB52455@dsl-only.net> References: <7748cc71-3788-22ae-fcb2-699eae529310@FreeBSD.org> <9A1A624D-9286-4C0F-A435-D590E07C1149@dsl-only.net> <0165aee5-cf6f-8f01-1690-fc51995e2109@FreeBSD.org> To: Nathan Whitehorn , Bryan Drewery X-Mailer: Apple Mail (2.3124) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 02:16:19 -0000 May be Nathan Whitehorn knows what is going on that prevents filemon.ko = from loading for powerpc64 based on how it is now built (added for more = than i386 and amd64 as of -r301130)? Nathan: See below if it sounds like something you might have a clue = about. As to why this comers up: Loading filemon.ko is required in order = for WITH_META_MODE=3Dyes to work for incremental builds. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jun-1, at 6:59 PM, Bryan Drewery = wrote: > On 6/1/2016 6:39 PM, Mark Millard wrote: >> while filemon.ko now exists: >>> # ls -l /boot/*/filemon* >>> -r-xr-xr-x 1 root wheel 32064 Jun 1 17:59 = /boot/kernel/filemon.ko >> it does not load: >>> # kldload -n filemon >>> kldload: can't load filemon: No such file or directory >>> # dmesg | grep link_elf >>> link_elf: symbol elf64_freebsd_sysvec undefined >=20 > There's 2 different ABI formats for powerpc64? >=20 >> sys/powerpc/powerpc/elf64_machdep.c:INIT_SYSENTVEC(elf64_sysvec_v1, = &elf64_freebsd_sysvec_v1); >> sys/powerpc/powerpc/elf64_machdep.c:INIT_SYSENTVEC(elf64_sysvec_v2, = &elf64_freebsd_sysvec_v2); >=20 > What's up with that? >=20 > --=20 > Regards, > Bryan Drewery From owner-freebsd-current@freebsd.org Wed Jun 1 23:31: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 E5DEDB66350 for ; Wed, 1 Jun 2016 23:31:00 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id C98641C94; Wed, 1 Jun 2016 23:31:00 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id B88EB1453; Wed, 1 Jun 2016 23:31:00 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 6D9721D78F; Wed, 1 Jun 2016 23:31:00 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id p8KrhWJWgOLF; Wed, 1 Jun 2016 23:30:57 +0000 (UTC) Subject: Re: 11.0 -r301139: WITH_META_MODE=yes vs. "sh: ./make_keys: Exec format error"? DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 5C9C41D778 To: Mark Millard References: <890D3808-1939-4BEA-886F-324EBA8C8671@dsl-only.net> <0b75f448-047f-53b3-3e1b-7de17a2da949@FreeBSD.org> Cc: FreeBSD Current From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: Date: Wed, 1 Jun 2016 16:30:57 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <0b75f448-047f-53b3-3e1b-7de17a2da949@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NiGPa4lTELv0AL9q6GuSwGUtpuUROV4jF" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 23:31:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NiGPa4lTELv0AL9q6GuSwGUtpuUROV4jF Content-Type: multipart/mixed; boundary="hx0GrcH4jeBWeqa7JompLhRhPnups2Sg0" From: Bryan Drewery To: Mark Millard Cc: FreeBSD Current Message-ID: Subject: Re: 11.0 -r301139: WITH_META_MODE=yes vs. "sh: ./make_keys: Exec format error"? References: <890D3808-1939-4BEA-886F-324EBA8C8671@dsl-only.net> <0b75f448-047f-53b3-3e1b-7de17a2da949@FreeBSD.org> In-Reply-To: <0b75f448-047f-53b3-3e1b-7de17a2da949@FreeBSD.org> --hx0GrcH4jeBWeqa7JompLhRhPnups2Sg0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/1/2016 4:29 PM, Bryan Drewery wrote: > On 6/1/2016 4:25 PM, Mark Millard wrote: >> [The example context here for extracted materials is a amd64 -> armv6 = cross build.] >> >> In my recent experimentation with WITH_META_MODE=3Dyes I=E2=80=99ve ha= d multiple occasions when after updating /usr/src I attempt buildworld bu= ildkernel and end up with something like: >>> --- lib/ncurses/ncursesw__L --- >>> Building /usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncursesw/init_k= eytry.h >>> --- init_keytry.h --- >>> sh: ./make_keys: Exec format error >>> *** [init_keytry.h] Error code 126 >>> >>> make[4]: stopped in /usr/src/lib/ncurses/ncursesw >>> 1 error >>> >>> make[4]: stopped in /usr/src/lib/ncurses/ncursesw >>> *** [lib/ncurses/ncursesw__L] Error code 2 >> I=E2=80=99ve also had such for powerpc being the target and make toolc= hain in use (preparing for buildkernel without buildworld). >> >> There are multiple instances of make_keys construction in the builds. = Here it looks like: >>> # grep make_keys ~/sys_typescripts/typescript_make_rpi2_nodebug_clang= _bootstrap-amd64-host-2016-06-01:15:17:28 >>> Building /usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncursesw/make_k= eys >>> Building /usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncurses/make_ke= ys >>> Building /usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncursesw/make_k= eys >>> sh: ./make_keys: Exec format error >> Note that ncursesw has two Building lines above with the same path lis= ted. >> >> cleanworld and then retrying the sequence desired always seems to work= but is a complete rebuild. >=20 > I don't understand why you're hitting this. It's an issue that I ran > into and fixed and haven't run into again from several powerpc64 build > tests. >=20 It's possible r301079 reintroduced the bug. I'll find out. --=20 Regards, Bryan Drewery --hx0GrcH4jeBWeqa7JompLhRhPnups2Sg0-- --NiGPa4lTELv0AL9q6GuSwGUtpuUROV4jF 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 iQEcBAEBAgAGBQJXT3AxAAoJEDXXcbtuRpfPR7gH/3eUQxGgREAgO5MX68QDgLEF X42uoaBgf46v3t8GAotkp6pQHUUhekJiNI5QHXa62wYP2hNh2xPw4Zdums03yCUO 1gEzbuW/XhMhWozic3vo57ovJFuTV8i9Vfq6vITyTVo88WT1fg2Q72ozSBfvLu89 NcYQiejitagWDDqCXwLdCAdf9f2DyV3b1UBQ91yrOqFw6TTZ7QIjY4NTYcJO4sxN hJijRLJJx8PNmq4Wr9WywpRp2FfuQiRmD6Oxxct7G/Eo0v7/kVKw4eMQMkll2kRi YvkQ/6e4H7mnI/P216wdp/LQd5JX0InVzXsq/bxjFqc8M2td5mAUIBjdnDtQ5Ro= =Nns4 -----END PGP SIGNATURE----- --NiGPa4lTELv0AL9q6GuSwGUtpuUROV4jF-- From owner-freebsd-current@freebsd.org Thu Jun 2 02:21:42 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4B29CB6214C; Thu, 2 Jun 2016 02:21:42 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 2ED2E1316; Thu, 2 Jun 2016 02:21:42 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 273FA1620; Thu, 2 Jun 2016 02:21:42 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id CAFFD1D907; Thu, 2 Jun 2016 02:21:41 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id IMYrhwYcEQ5Z; Thu, 2 Jun 2016 02:21:38 +0000 (UTC) Subject: Re: [CFT] WITH_META_MODE: Working incremental build [only on i386 and amd64] [filemon fails to load on powerpc64] DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 4592B1D8FE To: Mark Millard , Nathan Whitehorn References: <7748cc71-3788-22ae-fcb2-699eae529310@FreeBSD.org> <9A1A624D-9286-4C0F-A435-D590E07C1149@dsl-only.net> <0165aee5-cf6f-8f01-1690-fc51995e2109@FreeBSD.org> <35AFB7AC-7AD4-41D5-AA8D-87C37EB52455@dsl-only.net> Cc: FreeBSD Current , FreeBSD PowerPC ML From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <5ae8e248-904e-2c33-b76c-566890406b8c@FreeBSD.org> Date: Wed, 1 Jun 2016 19:21:37 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <35AFB7AC-7AD4-41D5-AA8D-87C37EB52455@dsl-only.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Jtq168a0P33B4DFhqBATxSODnEKdFG8Dj" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 02:21:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Jtq168a0P33B4DFhqBATxSODnEKdFG8Dj Content-Type: multipart/mixed; boundary="qfHe6El5c7HSDG6MF3WHjivET43WvFI4P" From: Bryan Drewery To: Mark Millard , Nathan Whitehorn Cc: FreeBSD Current , FreeBSD PowerPC ML Message-ID: <5ae8e248-904e-2c33-b76c-566890406b8c@FreeBSD.org> Subject: Re: [CFT] WITH_META_MODE: Working incremental build [only on i386 and amd64] [filemon fails to load on powerpc64] References: <7748cc71-3788-22ae-fcb2-699eae529310@FreeBSD.org> <9A1A624D-9286-4C0F-A435-D590E07C1149@dsl-only.net> <0165aee5-cf6f-8f01-1690-fc51995e2109@FreeBSD.org> <35AFB7AC-7AD4-41D5-AA8D-87C37EB52455@dsl-only.net> In-Reply-To: <35AFB7AC-7AD4-41D5-AA8D-87C37EB52455@dsl-only.net> --qfHe6El5c7HSDG6MF3WHjivET43WvFI4P Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The fix is easy, I am just wondering why there are 2 ABI formats supported. If only one is normally used and the default then I'll only support that one. Filemon hooks the syscall table. On 6/1/2016 7:16 PM, Mark Millard wrote: > May be Nathan Whitehorn knows what is going on that prevents filemon.ko= > from loading for powerpc64 based on how it is now built (added for more= > than i386 and amd64 as of -r301130)? >=20 > Nathan: See below if it sounds like something you might have a clue > about. As to why this comers up: Loading filemon.ko is required in orde= r > for WITH_META_MODE=3Dyes to work for incremental builds. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2016-Jun-1, at 6:59 PM, Bryan Drewery > wrote: >=20 >> On 6/1/2016 6:39 PM, Mark Millard wrote: >>> while filemon.ko now exists: >>>> # ls -l /boot/*/filemon* >>>> -r-xr-xr-x 1 root wheel 32064 Jun 1 17:59 /boot/kernel/filemon.k= o >>> it does not load: >>>> # kldload -n filemon >>>> kldload: can't load filemon: No such file or directory >>>> # dmesg | grep link_elf >>>> link_elf: symbol elf64_freebsd_sysvec undefined >> >> There's 2 different ABI formats for powerpc64? >> >>> sys/powerpc/powerpc/elf64_machdep.c:INIT_SYSENTVEC(elf64_sysvec_v1, >>> &elf64_freebsd_sysvec_v1); >>> sys/powerpc/powerpc/elf64_machdep.c:INIT_SYSENTVEC(elf64_sysvec_v2, >>> &elf64_freebsd_sysvec_v2); >> >> What's up with that? >> >> --=20 >> Regards, >> Bryan Drewery >=20 >=20 --=20 Regards, Bryan Drewery --qfHe6El5c7HSDG6MF3WHjivET43WvFI4P-- --Jtq168a0P33B4DFhqBATxSODnEKdFG8Dj 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 iQEcBAEBAgAGBQJXT5gyAAoJEDXXcbtuRpfP0UkIANnjL5JR3byD+RbIiU59V9O3 +Js1peju66sDE26J8Rgc2mc6tlchtxa6sXRE/sboCCom1KLInaGpBVucvNSt89/X 6FWC3uMrYavzCg7eWkCrXjK5G1bsbVQYzhxnl/udR9tBTC51DXjVSqitmUwZABLR 4LK2smVIflBbfzUZvV0sTeqbLChNeMpJ3uuIrG+zSO2CQbVaA9NJ/WFkgw5A8v4D Ypi5XxNX98EkxMnmV0JclVtvSShurRmVkq5f2eZbJ1WfxbpRxhpw3ABpL5uGgE2i dZRscYvI5yNydKi8iaLEOEBvSruFtLTpu1TB0FluaqtbDWxFM3xYhr2ELVWkk8A= =ZZAA -----END PGP SIGNATURE----- --Jtq168a0P33B4DFhqBATxSODnEKdFG8Dj-- From owner-freebsd-current@freebsd.org Thu Jun 2 02:31: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 8913CB6255B for ; Thu, 2 Jun 2016 02:31:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-195.reflexion.net [208.70.211.195]) (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 2C6CC18B8 for ; Thu, 2 Jun 2016 02:31:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 3549 invoked from network); 2 Jun 2016 02:32:23 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 2 Jun 2016 02:32:23 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Wed, 01 Jun 2016 22:31:55 -0400 (EDT) Received: (qmail 30399 invoked from network); 2 Jun 2016 02:31:55 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 2 Jun 2016 02:31:55 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 5521C1C43E6; Wed, 1 Jun 2016 19:31:44 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [CFT] WITH_META_MODE: Working incremental build [only on i386 and amd64] [filemon fails to load on powerpc64] From: Mark Millard In-Reply-To: <5ae8e248-904e-2c33-b76c-566890406b8c@FreeBSD.org> Date: Wed, 1 Jun 2016 19:31:49 -0700 Cc: Nathan Whitehorn , FreeBSD Current , FreeBSD PowerPC ML Content-Transfer-Encoding: 7bit Message-Id: <4F433A9C-2F3E-4C4A-A303-91E24069C367@dsl-only.net> References: <7748cc71-3788-22ae-fcb2-699eae529310@FreeBSD.org> <9A1A624D-9286-4C0F-A435-D590E07C1149@dsl-only.net> <0165aee5-cf6f-8f01-1690-fc51995e2109@FreeBSD.org> <35AFB7AC-7AD4-41D5-AA8D-87C37EB52455@dsl-only.net> <5ae8e248-904e-2c33-b76c-566890406b8c@FreeBSD.org> To: Bryan Drewery X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 02:31:57 -0000 On 2016-Jun-1, at 7:21 PM, Bryan Drewery wrote: > > The fix is easy, I am just wondering why there are 2 ABI formats > supported. If only one is normally used and the default then I'll only > support that one. > > Filemon hooks the syscall table. The only differences that I see are (_v1 then _v2 pairs): .sv_sigcode = sigcode64, .sv_szsigcode = &szsigcode64, .sv_name = "FreeBSD ELF64", vs. .sv_sigcode = sigcode64_elfv2, .sv_szsigcode = &szsigcode64_elfv2, .sv_name = "FreeBSD ELF64 V2", and: .sv_setregs = exec_setregs_funcdesc, vs. .sv_setregs = exec_setregs, Only for the _v1 case: .sv_trap = NULL, This appears to be two different ELF format versions. This is confirmed by: https://patchwork.ozlabs.org/patch/433747/ (from 2015-Jan-28) where Nathan wrote: Big-endian ELF64 ELF executables normally (the Linux kernel is an exception) have their entry point refer to a function descriptor instead of the first instruction. Distinguish between the Linux case and the function descriptor case, which is used for the FreeBSD kernel, by checking whether the entry point points into an executable section or not. This allows use of the FreeBSD kernel as a skiboot payload. === Mark Millard markmi at dsl-only.net Older material. . . On 6/1/2016 7:16 PM, Mark Millard wrote: > May be Nathan Whitehorn knows what is going on that prevents filemon.ko > from loading for powerpc64 based on how it is now built (added for more > than i386 and amd64 as of -r301130)? > > Nathan: See below if it sounds like something you might have a clue > about. As to why this comers up: Loading filemon.ko is required in order > for WITH_META_MODE=yes to work for incremental builds. > > === > Mark Millard > markmi at dsl-only.net > > On 2016-Jun-1, at 6:59 PM, Bryan Drewery > wrote: > >> On 6/1/2016 6:39 PM, Mark Millard wrote: >>> while filemon.ko now exists: >>>> # ls -l /boot/*/filemon* >>>> -r-xr-xr-x 1 root wheel 32064 Jun 1 17:59 /boot/kernel/filemon.ko >>> it does not load: >>>> # kldload -n filemon >>>> kldload: can't load filemon: No such file or directory >>>> # dmesg | grep link_elf >>>> link_elf: symbol elf64_freebsd_sysvec undefined >> >> There's 2 different ABI formats for powerpc64? >> >>> sys/powerpc/powerpc/elf64_machdep.c:INIT_SYSENTVEC(elf64_sysvec_v1, >>> &elf64_freebsd_sysvec_v1); >>> sys/powerpc/powerpc/elf64_machdep.c:INIT_SYSENTVEC(elf64_sysvec_v2, >>> &elf64_freebsd_sysvec_v2); >> >> What's up with that? >> >> -- >> Regards, >> Bryan Drewery > > -- Regards, Bryan Drewery From owner-freebsd-current@freebsd.org Wed Jun 1 23:25: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 CF720B661E7 for ; Wed, 1 Jun 2016 23:25:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-173.reflexion.net [208.70.211.173]) (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 850301B08 for ; Wed, 1 Jun 2016 23:25:36 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 3641 invoked from network); 1 Jun 2016 23:25:31 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 1 Jun 2016 23:25:31 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Wed, 01 Jun 2016 19:25:28 -0400 (EDT) Received: (qmail 4846 invoked from network); 1 Jun 2016 23:25:27 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 1 Jun 2016 23:25:27 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 687341C43DB; Wed, 1 Jun 2016 16:25:25 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: 11.0 -r301139: WITH_META_MODE=yes vs. "sh: ./make_keys: Exec format error"? Date: Wed, 1 Jun 2016 16:25:29 -0700 Message-Id: <890D3808-1939-4BEA-886F-324EBA8C8671@dsl-only.net> Cc: FreeBSD Current To: Bryan Drewery Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 23:25:37 -0000 [The example context here for extracted materials is a amd64 -> armv6 = cross build.] In my recent experimentation with WITH_META_MODE=3Dyes I=E2=80=99ve had = multiple occasions when after updating /usr/src I attempt buildworld = buildkernel and end up with something like: > --- lib/ncurses/ncursesw__L --- > Building = /usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncursesw/init_keytry.h > --- init_keytry.h --- > sh: ./make_keys: Exec format error > *** [init_keytry.h] Error code 126 >=20 > make[4]: stopped in /usr/src/lib/ncurses/ncursesw > 1 error >=20 > make[4]: stopped in /usr/src/lib/ncurses/ncursesw > *** [lib/ncurses/ncursesw__L] Error code 2 I=E2=80=99ve also had such for powerpc being the target and make = toolchain in use (preparing for buildkernel without buildworld). There are multiple instances of make_keys construction in the builds. = Here it looks like: > # grep make_keys = ~/sys_typescripts/typescript_make_rpi2_nodebug_clang_bootstrap-amd64-host-= 2016-06-01:15:17:28 > Building = /usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncursesw/make_keys > Building = /usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncurses/make_keys > Building = /usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncursesw/make_keys > sh: ./make_keys: Exec format error Note that ncursesw has two Building lines above with the same path = listed. cleanworld and then retrying the sequence desired always seems to work = but is a complete rebuild. As for src.conf (example is for the amd64 -> armv6 cross build): > # more ~/src.configs/src.conf.rpi2-clang-bootstrap.amd64-host=20 > TO_TYPE=3Darmv6 > # > KERNCONF=3DRPI2-NODBG > TARGET=3Darm > .if ${.MAKE.LEVEL} =3D=3D 0 > TARGET_ARCH=3D${TO_TYPE} > .export TARGET_ARCH > .endif > # > WITH_CROSS_COMPILER=3D > WITHOUT_SYSTEM_COMPILER=3D > # > #CPUTYPE=3Dsoft > WITH_LIBSOFT=3D > WITH_LIBCPLUSPLUS=3D > WITH_BINUTILS_BOOTSTRAP=3D > WITH_CLANG_BOOTSTRAP=3D > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_CLANG_EXTRAS=3D > WITH_LLDB=3D > # > WITH_BOOT=3D > WITHOUT_LIB32=3D > # > WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D > WITHOUT_GCC_BOOTSTRAP=3D > WITHOUT_GCC=3D > WITHOUT_GCC_IS_CC=3D > WITHOUT_GNUCXX=3D > # > NO_WERROR=3D > #WERROR=3D > MALLOC_PRODUCTION=3D > # > WITH_DEBUG_FILES=3D > # > XCFLAGS+=3D -march=3Darmv7a -mcpu=3Dcortex-a7 > XCXXFLAGS+=3D -march=3Darmv7a -mcpu=3Dcortex-a7 > # There is no XCPPFLAGS but XCPP ets XCFLAGS content. The amd64 context is at -r301139 and the rpi2/armv6 build was attempting = to update to -r301139 from -r300944. > # uname -apKU > FreeBSD FreeBSDx64 11.0-ALPHA1 FreeBSD 11.0-ALPHA1 #2 r301139M: Wed = Jun 1 11:38:44 PDT 2016 = markmi@FreeBSDx64:/usr/obj/clang/amd64.amd64/usr/src/sys/GENERIC-NODEBUG = amd64 amd64 1100116 1100116 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Wed Jun 1 23:29: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 B3FF7B662D9 for ; Wed, 1 Jun 2016 23:29:25 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 977AA1C2F; Wed, 1 Jun 2016 23:29:25 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 90867142F; Wed, 1 Jun 2016 23:29:25 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 4D9131D767; Wed, 1 Jun 2016 23:29:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id xf3F8m6HrT_X; Wed, 1 Jun 2016 23:29:21 +0000 (UTC) Subject: Re: 11.0 -r301139: WITH_META_MODE=yes vs. "sh: ./make_keys: Exec format error"? DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com A086B1D761 To: Mark Millard References: <890D3808-1939-4BEA-886F-324EBA8C8671@dsl-only.net> Cc: FreeBSD Current From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <0b75f448-047f-53b3-3e1b-7de17a2da949@FreeBSD.org> Date: Wed, 1 Jun 2016 16:29:21 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <890D3808-1939-4BEA-886F-324EBA8C8671@dsl-only.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mi2lngJoWnH0o4CgdmHFWGuU392EXWA13" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 23:29:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mi2lngJoWnH0o4CgdmHFWGuU392EXWA13 Content-Type: multipart/mixed; boundary="86E0wShOW1HwWt6F7R5DwnBbCJHbG0IdB" From: Bryan Drewery To: Mark Millard Cc: FreeBSD Current Message-ID: <0b75f448-047f-53b3-3e1b-7de17a2da949@FreeBSD.org> Subject: Re: 11.0 -r301139: WITH_META_MODE=yes vs. "sh: ./make_keys: Exec format error"? References: <890D3808-1939-4BEA-886F-324EBA8C8671@dsl-only.net> In-Reply-To: <890D3808-1939-4BEA-886F-324EBA8C8671@dsl-only.net> --86E0wShOW1HwWt6F7R5DwnBbCJHbG0IdB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/1/2016 4:25 PM, Mark Millard wrote: > [The example context here for extracted materials is a amd64 -> armv6 c= ross build.] >=20 > In my recent experimentation with WITH_META_MODE=3Dyes I=E2=80=99ve had= multiple occasions when after updating /usr/src I attempt buildworld bui= ldkernel and end up with something like: >> --- lib/ncurses/ncursesw__L --- >> Building /usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncursesw/init_ke= ytry.h >> --- init_keytry.h --- >> sh: ./make_keys: Exec format error >> *** [init_keytry.h] Error code 126 >> >> make[4]: stopped in /usr/src/lib/ncurses/ncursesw >> 1 error >> >> make[4]: stopped in /usr/src/lib/ncurses/ncursesw >> *** [lib/ncurses/ncursesw__L] Error code 2 > I=E2=80=99ve also had such for powerpc being the target and make toolch= ain in use (preparing for buildkernel without buildworld). >=20 > There are multiple instances of make_keys construction in the builds. H= ere it looks like: >> # grep make_keys ~/sys_typescripts/typescript_make_rpi2_nodebug_clang_= bootstrap-amd64-host-2016-06-01:15:17:28 >> Building /usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncursesw/make_ke= ys >> Building /usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncurses/make_key= s >> Building /usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncursesw/make_ke= ys >> sh: ./make_keys: Exec format error > Note that ncursesw has two Building lines above with the same path list= ed. >=20 > cleanworld and then retrying the sequence desired always seems to work = but is a complete rebuild. I don't understand why you're hitting this. It's an issue that I ran into and fixed and haven't run into again from several powerpc64 build tests. --=20 Regards, Bryan Drewery --86E0wShOW1HwWt6F7R5DwnBbCJHbG0IdB-- --mi2lngJoWnH0o4CgdmHFWGuU392EXWA13 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 iQEcBAEBAgAGBQJXT2/RAAoJEDXXcbtuRpfPyvYIAKKJsPtQ2tK1ItJBuK5sADPb 6k8SAdWnxwAJEJqr+KxkZkTb9BL/9x+oREGdJIby80UOe2FLfgGXTbz3Qy0xElc5 FkMFgYarZFLSp1j2ri3FGQk/HsylkGfs2qoCZnYqoOaPg2QSpgCeHyuyq2nBKty2 bylw/SMz1WGWn1hXXN0toJKNKxZVgutsZMOKq9+msQragz2y92LUO4EDbTL8JeWR SU6+O102A7dGLXkKWqSrYHuYRe65ohB8VPVpI6TPH3xBzpZ/9ZB6yGSIlUqxYJub KZkj2BFAcfUncVjTwdFXltDG9BCt+40Gplr/daXPqTLJTA4HoQiuYfftovUKUQk= =SPQS -----END PGP SIGNATURE----- --mi2lngJoWnH0o4CgdmHFWGuU392EXWA13-- From owner-freebsd-current@freebsd.org Thu Jun 2 14:38:23 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 84127B60B3B for ; Thu, 2 Jun 2016 14:38:23 +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 4EF631748 for ; Thu, 2 Jun 2016 14:38:22 +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 5DFAA1FE024; Thu, 2 Jun 2016 16:38:20 +0200 (CEST) Subject: Re: Suddenly poweroff in 11-Current r300097 To: RayCherng Yu , freebsd-current@freebsd.org References: From: Hans Petter Selasky Message-ID: <0448c751-8608-51ce-f47e-76280ebf14f2@selasky.org> Date: Thu, 2 Jun 2016 16:41:43 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 14:38:23 -0000 On 06/02/16 03:07, RayCherng Yu wrote: > I got a suddenly poweroff in r300097 (and previous revision in April and > May) when I built textproc/docproj. > My machine is Macbook Pro 13 2011 early. I have checked the Apple website. > My bios is the latest version. > Actually it also happened in 10.3-STABLE. > It happened when the machine load was heavy. Before it shutdown, the fan > started to run very loudly. After several seconds (20 or 30 seconds), my > laptop shutdown (poweroff directly) suddenly. It seems not happen with the > AC power supply connected. > > I installed both Mac OSX and FreeBSD (dual boot). It never happened in Mac > OSX. > > My dmesg: > http://pastebin.com/QjZmbGCB > > My sysctl hw.acpi: > > hw.acpi.acline: 0 > hw.acpi.battery.info_expire: 5 > hw.acpi.battery.units: 1 > hw.acpi.battery.state: 1 > hw.acpi.battery.time: 87 > hw.acpi.battery.life: 59 > hw.acpi.cpu.cx_lowest: C8 > hw.acpi.reset_video: 0 > hw.acpi.handle_reboot: 1 > hw.acpi.disable_on_reboot: 0 > hw.acpi.verbose: 0 > hw.acpi.s4bios: 0 > hw.acpi.sleep_delay: 1 > hw.acpi.suspend_state: S3 > hw.acpi.standby_state: NONE > hw.acpi.lid_switch_state: NONE > hw.acpi.sleep_button_state: S3 > hw.acpi.power_button_state: S5 > hw.acpi.supported_sleep_state: S3 S4 S5 > Hi, Do you have a temperature sysctl? Usually FreeBSD will shutdown the system if the ACPI temperature exceeds some value. Maybe it would be better to reduce the CPU load when the temperature goes up instead of facing a shutdown? --HPS From owner-freebsd-current@freebsd.org Thu Jun 2 03:03: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 BE753B665EF for ; Thu, 2 Jun 2016 03:03:12 +0000 (UTC) (envelope-from oleglelchuk@gmail.com) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 5B30A10F6 for ; Thu, 2 Jun 2016 03:03:12 +0000 (UTC) (envelope-from oleglelchuk@gmail.com) Received: by mail-wm0-x233.google.com with SMTP id a136so209236468wme.0 for ; Wed, 01 Jun 2016 20:03:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=+xaP496z9CqeKkjWQEqB/uAy+ysmTC35FqBm5URLsHg=; b=qzxdlKjxJp5xl84diDnRIxpjZW+cJAX6hjSOAoXot3+TGd7l5AcH8j0P02XYHY5mvp R3ggmAbPT3poMuU/GsPg5ZuSdCnTx5yeNJam7UTIXlIlQpnZxJENgdZBbBGiryrHNF1Q 7Wx84CvoybIFg0QUo1AyLt0305dfr0w7tU/kl95Q5+4VKzkn9mz9tSzPfObCXb4+Ds0y l54lV52OE0ffUP6ojUtEb2Z2WJCLTJbtiCaqy67tc+65sZq7YyUjG3bM7ufWuC+3k8LP CdsKdaMjhuSDhhDfK0ma9tHVHPv8gvuQTplZYeOEYSz+2CavaUpeWyyynnimPJacxGr0 R6SQ== 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; bh=+xaP496z9CqeKkjWQEqB/uAy+ysmTC35FqBm5URLsHg=; b=bXm1jLYY6exaCVVAxroaCRIvuaqovCL1NV47Qme99M3GjlRJMg2/0Gz01O6/J2kvqp /ILLO40P/XIiipY7gSlneZl9A6KALf1qHETLVanRW/LCR8QmOspYssgzGwu1SgEb+GWE 249Nqc+wTX2Xe1JTR6W5TjvfTJ2BhotCdA0dlcQX/WQ+QEUdHgeW6VI5I+VwBBcCqZ0p huNmI76WG/D5PVFvXPwZDeon4CfUR1lJjEPnWy4CZGuWqrh2XUqA/TvTywRg+ENdtICy fPPVpf4C1YBZyITV7ld1qu/rkVUttypJDQkyVSIJ7GM++dBTgTT4yqiK4UvkVBgwn4AU 7x4A== X-Gm-Message-State: ALyK8tJ/L+9titYFAIubO39vP+RkXLaXphAcaB3xc3c/h7JdXNg0OA15AVbxNBLP5/AXg5CrBgtXxk+K8CJPOA== MIME-Version: 1.0 X-Received: by 10.194.104.138 with SMTP id ge10mr5856151wjb.85.1464836590756; Wed, 01 Jun 2016 20:03:10 -0700 (PDT) Received: by 10.194.174.230 with HTTP; Wed, 1 Jun 2016 20:03:10 -0700 (PDT) Date: Wed, 1 Jun 2016 23:03:10 -0400 Message-ID: Subject: Streaming live tv over the udp protocol causes problems From: Oleg Lelchuk To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 03:03:12 -0000 Hi. On 11-ALPHA1, when I use vlc to stream live tv over the udp protocol, I see a garbled and choppy video. This issue doesn't occur on 10.3-STABLE. I am puzzled as to the cause of this problem. From owner-freebsd-current@freebsd.org Thu Jun 2 04:23: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 9CCCAB633D7; Thu, 2 Jun 2016 04:23:40 +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 838251269; Thu, 2 Jun 2016 04:23:40 +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 B57BFE28; Thu, 2 Jun 2016 04:23:40 +0000 (UTC) Date: Thu, 2 Jun 2016 04:23:38 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: gnn@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <1722957863.18.1464841420750.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <2144696675.14.1464833665255.JavaMail.jenkins@jenkins-9.freebsd.org> References: <2144696675.14.1464833665255.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #3285 - 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.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 04:23:40 -0000 FreeBSD_HEAD_i386 - Build #3285 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3285/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3285/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3285/console Change summaries: 301182 by gnn: Fix kernel build. Improper definition location of a variable. From owner-freebsd-current@freebsd.org Thu Jun 2 14:29:58 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 49D84B65D9E; Thu, 2 Jun 2016 14:29:58 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-oi0-x241.google.com (mail-oi0-x241.google.com [IPv6:2607:f8b0:4003:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0963D11D3; Thu, 2 Jun 2016 14:29:58 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-oi0-x241.google.com with SMTP id h125so11179736oib.2; Thu, 02 Jun 2016 07:29:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=FyQhYrfviUVTNtTNHcQo9+0RrSAhvrpwAo9IZUZvJgU=; b=uF4aRFQCCoa452ZqOB2Q7ejJ+n/1zxovZ4y8HYcEJS+IqQkzXb+BhcNmZZx9a2TP1P /cghnATzHGkBCsRMzSxD+Ykej62TipN4U6GrrvtgFL9BHIU9vg+UDR6d/cmP/IOFewq6 oDBhOgeSVcnb4d4oR5r7WU8ND1Qn7Fs00yK2Tgpqr87PfpMw7e+K7JcFPTHqvBSn4Acd ckUGTX5jmWoBP45Xhhgj0/6mUomi98335u/WaMSg+++dOSpqpIUUggIRsrMI6xfjGsi0 p+n0JadXiiEILsa/7tKwC1+PNebbi3TDv2/w9uEOvAInd9EO8K8jgpp2oMlcFF29/rJz tp/A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alumni-cwru-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=FyQhYrfviUVTNtTNHcQo9+0RrSAhvrpwAo9IZUZvJgU=; b=pswkwc/8HGqLaFaYFsbIYda2+h/dj96+X5abUA4QvQSp3dUO9H5JuUFoznXJYfBEem wh9G7bOiTpIvShXjPaKIjGN+AzOvz2DridCceUppugdq/Yt5Ic6CGOR5UAXeVosWEXuU LbILLpbwKvhFRyKdwbCsi0c+cuVDsomk4VLifjdVpq/uj36cuOF2FLVTsyvbPzF5vKB5 dHEIZ3450tPfXoC72AlVtm+wRTHQH9j8Vs163M2Lqq6dSW1A+MPlXJLzoRM6aXmXu51C fI9yTiAY05VSZKrlftghWVjQwRhmpOLu9+m5XXOStdyKp45E3VuIk+O7qkLEXFrST81m Z0rg== 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; bh=FyQhYrfviUVTNtTNHcQo9+0RrSAhvrpwAo9IZUZvJgU=; b=S4KcntGgJxvQZH0zVYPhZTsL825+7KWBbOH2y0U57xrmP3ASauuFOgnfEirTEtHzo7 0GKekDl2Ahc//hDUbBgi7DuCysAPqrvHVJuMJRqj+TbRUw84wULDKZ9/TK5Fo9uCgeAS 3PVKSCph3Egfyoo/S0psX5tFsd7nxtmkg65Wokoa+1x5Vm3LGxwe7NwLrPOyXcyMYVO1 +ndztfN7KZ18TaSHyanD12Dfabp3K2YvGGcLKr17R5h4DB9cgRnuMkRRgdJKDRzfPI+3 8SYHZ83AZwR1kscI241kHSffBuPpoeEKK63ny0lBuxf09HsPLCUCoaqdV7lJeQZO/YRw xcaA== X-Gm-Message-State: ALyK8tIdU6sILPxGanQrs8ynSiUsJUlT94yoSMAWuaa4ubcxroPquSXTVZq7G7rjCdepkGWZaMX0I2lFzwVbBw== MIME-Version: 1.0 X-Received: by 10.202.239.197 with SMTP id n188mr27734029oih.25.1464877797435; Thu, 02 Jun 2016 07:29:57 -0700 (PDT) Sender: chmeeedalf@gmail.com Received: by 10.182.105.74 with HTTP; Thu, 2 Jun 2016 07:29:57 -0700 (PDT) In-Reply-To: <0165aee5-cf6f-8f01-1690-fc51995e2109@FreeBSD.org> References: <7748cc71-3788-22ae-fcb2-699eae529310@FreeBSD.org> <9A1A624D-9286-4C0F-A435-D590E07C1149@dsl-only.net> <0165aee5-cf6f-8f01-1690-fc51995e2109@FreeBSD.org> Date: Thu, 2 Jun 2016 09:29:57 -0500 X-Google-Sender-Auth: utAd2s5BmDR3Fa1Gmx4DZ5z8E9U Message-ID: Subject: Re: [CFT] WITH_META_MODE: Working incremental build [only on i386 and amd64] [filemon fails to load on powerpc64] From: Justin Hibbits To: Bryan Drewery Cc: Mark Millard , FreeBSD Current , FreeBSD PowerPC ML , freebsd-arm Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 14:29:58 -0000 On Wed, Jun 1, 2016 at 8:59 PM, Bryan Drewery wrote: > On 6/1/2016 6:39 PM, Mark Millard wrote: >> while filemon.ko now exists: >>> # ls -l /boot/*/filemon* >>> -r-xr-xr-x 1 root wheel 32064 Jun 1 17:59 /boot/kernel/filemon.ko >> it does not load: >>> # kldload -n filemon >>> kldload: can't load filemon: No such file or directory >>> # dmesg | grep link_elf >>> link_elf: symbol elf64_freebsd_sysvec undefined > > There's 2 different ABI formats for powerpc64? > >> sys/powerpc/powerpc/elf64_machdep.c:INIT_SYSENTVEC(elf64_sysvec_v1, &elf64_freebsd_sysvec_v1); >> sys/powerpc/powerpc/elf64_machdep.c:INIT_SYSENTVEC(elf64_sysvec_v2, &elf64_freebsd_sysvec_v2); > > What's up with that? > > -- > Regards, > Bryan Drewery > Yes, powerpc64 has two ABIs now. ELFv1 is traditional ABI. ELFv2 was created IBM for their little-endian (POWER8 ppc64le) target. Nathan added support to use it in FreeBSD. It cleans up some of the silliness that's in ELFv1, such as function descriptors. - Justin From owner-freebsd-current@freebsd.org Thu Jun 2 15:47:03 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6CC65B686C8 for ; Thu, 2 Jun 2016 15:47:03 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) 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 2B99E179A for ; Thu, 2 Jun 2016 15:47:02 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: by mail-vk0-x22e.google.com with SMTP id c189so76595368vkb.1 for ; Thu, 02 Jun 2016 08:47:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brilliantservice-co-jp.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=QYokuNVRAgncfCz3LoeBnD2S6eIStuTIDiNcdmie8qg=; b=pnH/DdRWqil0PW9Ck76ybWFdb2AWUL74m9hk16y5YyWDApjGQGNqTSSI2fWDxgFpgI 1vAXAkkvV4mP8DyQqUtUzNAro6GqH7ZKaIqZB4G3cH5IXai1Ch6xH3kYKtFsCZZdO+mj yrSIocQcZebKVprfz32xQz3E2tOfnOpqIe8GiasAB3FKLepn/cSENSuyn7V3x1BcN+9H BeyjDVl8xzah7DGwMQf6Pxj4bosUZd+I+UMKkk08DDZjjcbFtIM4J1Cf1gKnOIwK3WDR eGnXOFfSEZwofOjU146NRzbZWV86QursHdVsVvce6j3CGXHgiJ2//XpGNi6csAaNaoK1 d/ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=QYokuNVRAgncfCz3LoeBnD2S6eIStuTIDiNcdmie8qg=; b=G3A0hIAiQmB7cLYDLJIcrDM4hoCGLH1RdLzY0PPXRGuWfO37PPesqu0pXT4PPNaUAO qYsMGuM3HSKdidTsovMlAZnAX0SI2Fv8hpM8/UKV1aILuebBlrkJHV6DvOXerbrritFK z7K4UdLmeEzDA76gwpk8hZBpKr9G4/5ewxhmGst7+JfVqq9cdiKXhrzadbc6N8doVFTD jGzxTO86Qy8SrBwWFdTt9i9omJZb3FrRuvEixcE2hGadmv/iFj/ayegPi3GuoewzsPam G3ijt9YiBuq55379aFKAq+jMuLAfCd9gZbfAXH3YSYPMHoF3xqwLK1xjfLu76Y8nX7O9 iPdg== X-Gm-Message-State: ALyK8tJkOFFmGrCkmiuHmR5EOd+k74D8HzD26y6C9R4X4tfqMfB3vRtuEcHqeVux8g8yvLz1H7hzI/GHSahhnRmSSeuBmYt+PBgjgoTkLUrdOyUspRx9Faj/8nnGKiUZFWhCl7rcreB2cgrZ54hFlCNSVhs= X-Received: by 10.176.65.105 with SMTP id j96mr4996362uad.21.1464882421861; Thu, 02 Jun 2016 08:47:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.0.13 with HTTP; Thu, 2 Jun 2016 08:46:47 -0700 (PDT) From: "Lundberg, Johannes" Date: Thu, 2 Jun 2016 08:46:47 -0700 Message-ID: Subject: Panic when doing installworld/kernel with DESTDIR=USB memory To: FreeBSD Current , "freebsd-usb@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 15:47:03 -0000 SGkNCg0KSSBoYXZlIGEgcmVwZWF0YWJsZSBidWcuIEkgZ2V0IGtlcm5lbCBwYW5pYyB3aGVuIGRv aW5nIGluc3RhbGx3b3JsZC9rZXJuZWwNCnRvIGEgVVNCIDMuMCBtZW1vcnkgb24gTWFjYm9vayBB aXIgKFVTQiAzLjAgcG9ydCBJIHRoaW5rKS4gRnJlZUJTRCBpcw0KMTEuMC1DVVJSRU5UIGZyb20g QXByIDI3dGguDQoNClRoaXMgY2FuIGJlIGF2b2lkZWQgYnkgbW91bnRpbmcgc3luY2hyb25pemVk IChtb3VudCAtbyBzeW5jKS4NCg0KSXMgdGhpcyBhIGtub3duIHByb2JsZW0/IElmIG5vdCBJIG1p Z2h0IGJlIGFibGUgdG8gdHJ5IGdldCBhIGNvcmUgZHVtcCBhbmQNCmludmVzdGlnYXRlIGZ1cnRo ZXIuDQoNCi9Kb2hhbm5lcw0KCi0tIAo9LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0t PS09LT0tPS09LT0tPS09LT0tPS0K56eY5a+G5L+d5oyB44Gr44Gk44GE44Gm77ya44GT44Gu6Zu7 5a2Q44Oh44O844Or44Gv44CB5ZCN5a6b5Lq644Gr6YCB5L+h44GX44Gf44KC44Gu44Gn44GC44KK 44CB56eY5Yy/54m55qip44Gu5a++6LGh44Go44Gq44KL5oOF5aCx44KS5ZCr44KT44Gn44GE44G+ 44GZ44CCCuOCguOBl+OAgeWQjeWum+S6uuS7peWkluOBruaWueOBjOWPl+S/oeOBleOCjOOBn+Wg tOWQiOOAgeOBk+OBruODoeODvOODq+OBruegtOajhOOAgeOBiuOCiOOBs+OBk+OBruODoeODvOOD q+OBq+mWouOBmeOCi+S4gOWIh+OBrumWi+ekuuOAgQropIflhpnjgIHphY3luIPjgIHjgZ3jga7k u5bjga7liKnnlKjjgIHjgb7jgZ/jga/oqJjovInlhoXlrrnjgavln7rjgaXjgY/jgYTjgYvjgarj govooYzli5XjgoLjgZXjgozjgarjgYTjgojjgYbjgYrpoZjjgYTnlLPjgZfkuIrjgZLjgb7jgZnj gIIKLS0tCkNPTkZJREVOVElBTElUWSBOT1RFOiBUaGUgaW5mb3JtYXRpb24gaW4gdGhpcyBlbWFp bCBpcyBjb25maWRlbnRpYWwKYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZS4K RGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIGFueSBvdGhlciBhY3Rpb24gb2Yg dXNlIG9mIHRoaXMKZW1haWwgYnkgcGVyc29uIG90aGVyIHRoYW4gaW50ZW5kZWQgcmVjaXBpZW50 LCBpcyBwcm9oaWJpdGVkLgpJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGFu ZCBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4KZXJyb3IsIHBsZWFzZSBkZXN0cm95IHRoZSBv cmlnaW5hbCBtZXNzYWdlLgo= From owner-freebsd-current@freebsd.org Thu Jun 2 16:39:10 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2E4CB62504; Thu, 2 Jun 2016 16:39:10 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6DB791BBE; Thu, 2 Jun 2016 16:39:10 +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 0D1A11FE024; Thu, 2 Jun 2016 18:39:08 +0200 (CEST) Subject: Re: Panic when doing installworld/kernel with DESTDIR=USB memory To: "Lundberg, Johannes" , FreeBSD Current , "freebsd-usb@freebsd.org" References: From: Hans Petter Selasky Message-ID: Date: Thu, 2 Jun 2016 18:42:31 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 16:39:10 -0000 On 06/02/16 17:46, Lundberg, Johannes wrote: > Hi > > I have a repeatable bug. I get kernel panic when doing installworld/kernel > to a USB 3.0 memory on Macbook Air (USB 3.0 port I think). FreeBSD is > 11.0-CURRENT from Apr 27th. > > This can be avoided by mounting synchronized (mount -o sync). > > Is this a known problem? If not I might be able to try get a core dump and > investigate further. > Can you get a backtrace of the panic w/ or w/o debug symbols? Possibly not USB related. Are you using fuse? --HPS From owner-freebsd-current@freebsd.org Thu Jun 2 17:13: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 46150B6540A for ; Thu, 2 Jun 2016 17:13:38 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F2DE614D1 for ; Thu, 2 Jun 2016 17:13:37 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: by mail-vk0-x22a.google.com with SMTP id c189so80149848vkb.1 for ; Thu, 02 Jun 2016 10:13:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brilliantservice-co-jp.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JCmhjQcKrGyp1UbEmUc89vC2QDJABVKvgrUYrDvnU3I=; b=gyB8VFc6//i5w5cRBhhH9HWgf5fNM7pdLMXgol4qKtM2WDAUptmEZqzLWagBvEcx3U 2lhTztc6t0Z5NzNz5Y85mRpozZIceLAvyK5TCwh0jjVfoWceUYC7iE5QTE7WB/sx35gh FrIsh9+t5oas31OzSY65S2AafjsJxwYCLDED7AFM31/yyWTLoTo59/vyq4jiq1gF1qwe LTCV5Wx1vS6jcd/rUYqFfjHUGgCwinci1SyLvluLHyvqQdvd1fZRh96S2fLmb9lB9+my S/nMfU6MYFqE7AphF/5IdbqRHCHzoCwhtMySYiOB4r6JryGBe2lZ5KUBY4mi/8htVJK7 83kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JCmhjQcKrGyp1UbEmUc89vC2QDJABVKvgrUYrDvnU3I=; b=RR6TFeBpJlmRUfd9InCcuZBmS8xad9qgRGbbkD5JyDpy3AlGb2KoZLB05uF/qOPfvL bYDElIyO2i2EK8S9doc19HQgKDMP1//9ap69HtCBRPJTZ1dGho3nIoOOlgUTAob0w9ra kJdHcuZgvEG/+Gkvc6MOFyQ3PluKZ/V3lIinNjicQTlZUuZwQp7Ma5rj7HHg18Irmarw VfA+aSWlmUFZ4hWn4QTX/x7gxdDIqFEpQPvTXgBl95FLbNYpQuXvDdRN8cQD6l5bFRWg Fh4BC0/WrYpV3S6qYLgfKiuyJmlO7YrchQrDUZmRfw7y/pxGMoEFopS8+G7kelF3ohLN bApQ== X-Gm-Message-State: ALyK8tL0tcdt5yUoIhEHN3OIVfhk3kwvu2QK1nrhzQq7iYzpODNjFcIa+98dKcnbDNsf28kefHlUPnNvUy8AMFQiFboNLIGrFefWVMNxDztZRR5afnRufqlHYOIsTAYGyIzFOKLHIMY8lzY5K8aI2AfIWek= X-Received: by 10.159.33.175 with SMTP id 44mr3021106uac.56.1464887616881; Thu, 02 Jun 2016 10:13:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.0.13 with HTTP; Thu, 2 Jun 2016 10:13:22 -0700 (PDT) In-Reply-To: References: From: "Lundberg, Johannes" Date: Thu, 2 Jun 2016 10:13:22 -0700 Message-ID: Subject: Re: Panic when doing installworld/kernel with DESTDIR=USB memory To: Hans Petter Selasky Cc: FreeBSD Current , "freebsd-usb@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 17:13:38 -0000 SSBkb24ndCB0aGluayBpdHMgVVNCIHJlbGF0ZWQgZWl0aGVyLg0KDQpUaGVyZSBzZWVtIHRvIGJl IHNvbWV0aGluZyB3ZWlyZCB3aXRoIG15IHNldHVwLi4NCkkgaGF2ZQ0KZHVtcGRldj0iQVVUTyIN CmRkYl9lbmFibGU9IllFUyINCmluIHJjLmNvbmYuDQoNCkFuZCBhIHN3YXAgcGFydGl0aW9uIGFj dGl2ZS4gQWZ0ZXIgcmVib290IHdoZW4gaXRzIGFib3V0IHRvIHNhdmUgdGhlIGNvcmUgSQ0KZ2V0 IGVycm9yIG1lc3NhZ2UNCi92YXIvY3Jhc2gvdm1jb3JlLjAgbm90IGZvdW5kDQoNClNvIEkgY2Fu J3QgZ2V0IGFueSBjb3JlIGR1bXAuLiBFdmVuIHdpdGggZGVidWcua2RiLnBhbmljPTEuLg0KDQpL bm93IHdoYXQgbWlnaHQgYmUgdGhlIHJlYXNvbj8NCg0KL3ZhciBpcyBzYW1lIGFzIHJvb3QgcGFy dGl0aW9uLCBwbGVudHkgb2YgZnJlZSBzcGFjZS4uDQpJIGRvIGdldCB0aGUgZmlsZXMNCmJvdW5k cw0KaW5mby4wDQp0ZXh0ZHVtcC50YXIuMA0KaW4gL3Zhci9jcmFzaC8NCg0KT24gVGh1LCBKdW4g MiwgMjAxNiBhdCA5OjQyIEFNLCBIYW5zIFBldHRlciBTZWxhc2t5IDxocHNAc2VsYXNreS5vcmc+ IHdyb3RlOg0KDQo+IE9uIDA2LzAyLzE2IDE3OjQ2LCBMdW5kYmVyZywgSm9oYW5uZXMgd3JvdGU6 DQo+DQo+PiBIaQ0KPj4NCj4+IEkgaGF2ZSBhIHJlcGVhdGFibGUgYnVnLiBJIGdldCBrZXJuZWwg cGFuaWMgd2hlbiBkb2luZyBpbnN0YWxsd29ybGQva2VybmVsDQo+PiB0byBhIFVTQiAzLjAgbWVt b3J5IG9uIE1hY2Jvb2sgQWlyIChVU0IgMy4wIHBvcnQgSSB0aGluaykuIEZyZWVCU0QgaXMNCj4+ IDExLjAtQ1VSUkVOVCBmcm9tIEFwciAyN3RoLg0KPj4NCj4+IFRoaXMgY2FuIGJlIGF2b2lkZWQg YnkgbW91bnRpbmcgc3luY2hyb25pemVkIChtb3VudCAtbyBzeW5jKS4NCj4+DQo+PiBJcyB0aGlz IGEga25vd24gcHJvYmxlbT8gSWYgbm90IEkgbWlnaHQgYmUgYWJsZSB0byB0cnkgZ2V0IGEgY29y ZSBkdW1wIGFuZA0KPj4gaW52ZXN0aWdhdGUgZnVydGhlci4NCj4+DQo+Pg0KPiBDYW4geW91IGdl dCBhIGJhY2t0cmFjZSBvZiB0aGUgcGFuaWMgdy8gb3Igdy9vIGRlYnVnIHN5bWJvbHM/DQo+DQo+ IFBvc3NpYmx5IG5vdCBVU0IgcmVsYXRlZC4gQXJlIHlvdSB1c2luZyBmdXNlPw0KPg0KPiAtLUhQ Uw0KPg0KPg0KCi0tIAo9LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09 LT0tPS09LT0tPS0K56eY5a+G5L+d5oyB44Gr44Gk44GE44Gm77ya44GT44Gu6Zu75a2Q44Oh44O8 44Or44Gv44CB5ZCN5a6b5Lq644Gr6YCB5L+h44GX44Gf44KC44Gu44Gn44GC44KK44CB56eY5Yy/ 54m55qip44Gu5a++6LGh44Go44Gq44KL5oOF5aCx44KS5ZCr44KT44Gn44GE44G+44GZ44CCCuOC guOBl+OAgeWQjeWum+S6uuS7peWkluOBruaWueOBjOWPl+S/oeOBleOCjOOBn+WgtOWQiOOAgeOB k+OBruODoeODvOODq+OBruegtOajhOOAgeOBiuOCiOOBs+OBk+OBruODoeODvOODq+OBq+mWouOB meOCi+S4gOWIh+OBrumWi+ekuuOAgQropIflhpnjgIHphY3luIPjgIHjgZ3jga7ku5bjga7liKnn lKjjgIHjgb7jgZ/jga/oqJjovInlhoXlrrnjgavln7rjgaXjgY/jgYTjgYvjgarjgovooYzli5Xj goLjgZXjgozjgarjgYTjgojjgYbjgYrpoZjjgYTnlLPjgZfkuIrjgZLjgb7jgZnjgIIKLS0tCkNP TkZJREVOVElBTElUWSBOT1RFOiBUaGUgaW5mb3JtYXRpb24gaW4gdGhpcyBlbWFpbCBpcyBjb25m aWRlbnRpYWwKYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZS4KRGlzY2xvc3Vy ZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIGFueSBvdGhlciBhY3Rpb24gb2YgdXNlIG9mIHRo aXMKZW1haWwgYnkgcGVyc29uIG90aGVyIHRoYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBpcyBwcm9o aWJpdGVkLgpJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGFuZCBoYXZlIHJl Y2VpdmVkIHRoaXMgZW1haWwgaW4KZXJyb3IsIHBsZWFzZSBkZXN0cm95IHRoZSBvcmlnaW5hbCBt ZXNzYWdlLgo= From owner-freebsd-current@freebsd.org Thu Jun 2 17:14: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 EF964B654C3 for ; Thu, 2 Jun 2016 17:14:27 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A752317AD for ; Thu, 2 Jun 2016 17:14:27 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: by mail-vk0-x230.google.com with SMTP id c189so80183646vkb.1 for ; Thu, 02 Jun 2016 10:14:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brilliantservice-co-jp.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RRZbMjRlCNNGjgmILZj/5aRoi8iWV0/huNAjgF4L768=; b=LLwPBcsPYYi76H8n8Kg2ebV1fJQRAEge2ebQitJFyO5oatF7SUZnhim3UWZLhP60iA grXnJPaV+Ta1ERrhJbXd/b3Y+Hd4ygv4TpLF7X9Tw+s7uexzhHQgYnnVe5KvloUs/Ubz FQzlk5doy9gqdkZx+6b9GxO7nUSQ1gRJwoBBY5c1PWfNi2wIHXi9QCqOiB2XFRWIy9qy /oABSCvzLSXxOoDSmpWz/GvulUvCeVppDSaFujV1P/oPHNrlLVxf05LwOYeNLxIOISQZ Azj8GPsNpWSfKb//Fr8bm8zWCtgpk0GuKFMB0K71UXB/Hnk47kJkNAT6CHQLihs6u95i hh6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RRZbMjRlCNNGjgmILZj/5aRoi8iWV0/huNAjgF4L768=; b=LjtzPAkRkpLt4dJOV5rHQbq8Moq+xUDACdEHmzV4CvrJdtR0pLOSNb3tCrel2CAjSy ZNETLTY6KRnC83/6ABZPOCA/kmdu98rm7xsV2VIgifhHeQl1VnCMiWKXx2pfQOYqnXi9 DLUChDyMqblUKRLvC2DvXY62J851gzHnvxkAuKnophTy5utz7pOxTnjJlWWqz/NWqNf9 Sg2v9Pkn72LCq/+4c9q6UiPF2fV3I/uQky7WWEcz+oy3t7ToXkVvXYWvrlqeqmvnZhBu e+CJeq6+j1WuDtJCqgFJInAYAKNbS5hysbzMcfsQMx1stOR8c1835iOaR+dzT4HUmzZj JGVw== X-Gm-Message-State: ALyK8tI3F7ckSsmS9tq0pNe1iUhcNEGst2QVT9j/+NWiaY4e5M4EdVy2Hak4Al+XDoVX5+eRHWrAKJ6nBaIjFtarj6eLDs1oAGJq2h9tAljJP7mgJMS5oPi/wI/Pd8ISRCsXEYT2ytK5PicHSvJb1IH/wFs= X-Received: by 10.159.40.103 with SMTP id c94mr4930814uac.122.1464887666768; Thu, 02 Jun 2016 10:14:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.0.13 with HTTP; Thu, 2 Jun 2016 10:14:12 -0700 (PDT) In-Reply-To: References: From: "Lundberg, Johannes" Date: Thu, 2 Jun 2016 10:14:12 -0700 Message-ID: Subject: Re: Panic when doing installworld/kernel with DESTDIR=USB memory To: Hans Petter Selasky Cc: FreeBSD Current , "freebsd-usb@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 17:14:28 -0000 QnR3LCBJIGRpZCBidWlsZCB3aXRoIEdFTkVSSUMtTk9ERUJVRyBrZXJuY29uZi4gRG8gSSBuZWVk IHRvIHJlYnVpbGQgd2l0aA0KR0VORVJJQz8NCg0KDQpPbiBUaHUsIEp1biAyLCAyMDE2IGF0IDEw OjEzIEFNLCBMdW5kYmVyZywgSm9oYW5uZXMgPA0Kam9oYW5uZXNAYnJpbGxpYW50c2VydmljZS5j by5qcD4gd3JvdGU6DQoNCj4gSSBkb24ndCB0aGluayBpdHMgVVNCIHJlbGF0ZWQgZWl0aGVyLg0K Pg0KPiBUaGVyZSBzZWVtIHRvIGJlIHNvbWV0aGluZyB3ZWlyZCB3aXRoIG15IHNldHVwLi4NCj4g SSBoYXZlDQo+IGR1bXBkZXY9IkFVVE8iDQo+IGRkYl9lbmFibGU9IllFUyINCj4gaW4gcmMuY29u Zi4NCj4NCj4gQW5kIGEgc3dhcCBwYXJ0aXRpb24gYWN0aXZlLiBBZnRlciByZWJvb3Qgd2hlbiBp dHMgYWJvdXQgdG8gc2F2ZSB0aGUgY29yZQ0KPiBJIGdldCBlcnJvciBtZXNzYWdlDQo+IC92YXIv Y3Jhc2gvdm1jb3JlLjAgbm90IGZvdW5kDQo+DQo+IFNvIEkgY2FuJ3QgZ2V0IGFueSBjb3JlIGR1 bXAuLiBFdmVuIHdpdGggZGVidWcua2RiLnBhbmljPTEuLg0KPg0KPiBLbm93IHdoYXQgbWlnaHQg YmUgdGhlIHJlYXNvbj8NCj4NCj4gL3ZhciBpcyBzYW1lIGFzIHJvb3QgcGFydGl0aW9uLCBwbGVu dHkgb2YgZnJlZSBzcGFjZS4uDQo+IEkgZG8gZ2V0IHRoZSBmaWxlcw0KPiBib3VuZHMNCj4gaW5m by4wDQo+IHRleHRkdW1wLnRhci4wDQo+IGluIC92YXIvY3Jhc2gvDQo+DQo+DQo+IE9uIFRodSwg SnVuIDIsIDIwMTYgYXQgOTo0MiBBTSwgSGFucyBQZXR0ZXIgU2VsYXNreSA8aHBzQHNlbGFza3ku b3JnPg0KPiB3cm90ZToNCj4NCj4+IE9uIDA2LzAyLzE2IDE3OjQ2LCBMdW5kYmVyZywgSm9oYW5u ZXMgd3JvdGU6DQo+Pg0KPj4+IEhpDQo+Pj4NCj4+PiBJIGhhdmUgYSByZXBlYXRhYmxlIGJ1Zy4g SSBnZXQga2VybmVsIHBhbmljIHdoZW4gZG9pbmcNCj4+PiBpbnN0YWxsd29ybGQva2VybmVsDQo+ Pj4gdG8gYSBVU0IgMy4wIG1lbW9yeSBvbiBNYWNib29rIEFpciAoVVNCIDMuMCBwb3J0IEkgdGhp bmspLiBGcmVlQlNEIGlzDQo+Pj4gMTEuMC1DVVJSRU5UIGZyb20gQXByIDI3dGguDQo+Pj4NCj4+ PiBUaGlzIGNhbiBiZSBhdm9pZGVkIGJ5IG1vdW50aW5nIHN5bmNocm9uaXplZCAobW91bnQgLW8g c3luYykuDQo+Pj4NCj4+PiBJcyB0aGlzIGEga25vd24gcHJvYmxlbT8gSWYgbm90IEkgbWlnaHQg YmUgYWJsZSB0byB0cnkgZ2V0IGEgY29yZSBkdW1wDQo+Pj4gYW5kDQo+Pj4gaW52ZXN0aWdhdGUg ZnVydGhlci4NCj4+Pg0KPj4+DQo+PiBDYW4geW91IGdldCBhIGJhY2t0cmFjZSBvZiB0aGUgcGFu aWMgdy8gb3Igdy9vIGRlYnVnIHN5bWJvbHM/DQo+Pg0KPj4gUG9zc2libHkgbm90IFVTQiByZWxh dGVkLiBBcmUgeW91IHVzaW5nIGZ1c2U/DQo+Pg0KPj4gLS1IUFMNCj4+DQo+Pg0KPg0KCi0tIAo9 LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS0K56eY 5a+G5L+d5oyB44Gr44Gk44GE44Gm77ya44GT44Gu6Zu75a2Q44Oh44O844Or44Gv44CB5ZCN5a6b 5Lq644Gr6YCB5L+h44GX44Gf44KC44Gu44Gn44GC44KK44CB56eY5Yy/54m55qip44Gu5a++6LGh 44Go44Gq44KL5oOF5aCx44KS5ZCr44KT44Gn44GE44G+44GZ44CCCuOCguOBl+OAgeWQjeWum+S6 uuS7peWkluOBruaWueOBjOWPl+S/oeOBleOCjOOBn+WgtOWQiOOAgeOBk+OBruODoeODvOODq+OB ruegtOajhOOAgeOBiuOCiOOBs+OBk+OBruODoeODvOODq+OBq+mWouOBmeOCi+S4gOWIh+OBrumW i+ekuuOAgQropIflhpnjgIHphY3luIPjgIHjgZ3jga7ku5bjga7liKnnlKjjgIHjgb7jgZ/jga/o qJjovInlhoXlrrnjgavln7rjgaXjgY/jgYTjgYvjgarjgovooYzli5XjgoLjgZXjgozjgarjgYTj gojjgYbjgYrpoZjjgYTnlLPjgZfkuIrjgZLjgb7jgZnjgIIKLS0tCkNPTkZJREVOVElBTElUWSBO T1RFOiBUaGUgaW5mb3JtYXRpb24gaW4gdGhpcyBlbWFpbCBpcyBjb25maWRlbnRpYWwKYW5kIGlu dGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZS4KRGlzY2xvc3VyZSwgY29weWluZywgZGlz dHJpYnV0aW9uIG9yIGFueSBvdGhlciBhY3Rpb24gb2YgdXNlIG9mIHRoaXMKZW1haWwgYnkgcGVy c29uIG90aGVyIHRoYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBpcyBwcm9oaWJpdGVkLgpJZiB5b3Ug YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGFuZCBoYXZlIHJlY2VpdmVkIHRoaXMgZW1h aWwgaW4KZXJyb3IsIHBsZWFzZSBkZXN0cm95IHRoZSBvcmlnaW5hbCBtZXNzYWdlLgo= From owner-freebsd-current@freebsd.org Thu Jun 2 17:26:23 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 40578B65C62 for ; Thu, 2 Jun 2016 17:26:23 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 09D4F17ED for ; Thu, 2 Jun 2016 17:26:23 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-it0-x229.google.com with SMTP id i127so57539987ita.1 for ; Thu, 02 Jun 2016 10:26:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=tpU9mICy7jzSAG21Y3eRzVBiqRp/4jLAx0xPk9l061c=; b=HB4Mf37iOVMw9dzyGYht2gGVAIXHRygrRlnYwsRyPFw9egQ47FYV2/WsdLXQluoCnk GXkhzrSXlDz8EZi4hUOhrtAelKw6p9NSF44qSCZxE32ZWRP/++kEicoILNzd712/qddR CA4chXx83wJh9vPCijMzlGB+iHmtzdj/TLxFP+nQEbuQmERXqmgwrO1UC7XymxETWO8N VCAq2Ho8P3j4v1/klR6PI8g0l1YRi+PDlcfSCfTiHsxmFKf+J4CxE/uVvLruPvxdkLDw O/ySW8R64R3W8ervx7yXkqr8el2PLCtG6OylTiduPNpwR4q0aPVsMygFwFj7nhjlZdN7 eBnA== 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; bh=tpU9mICy7jzSAG21Y3eRzVBiqRp/4jLAx0xPk9l061c=; b=DmI8yHbSqTnZwu2mULIGLrmgaAms4KuWlM6UMYLjR3zBXkgc8HQ1nyQQgB1mibrvQR JqvpievYwhDfHdDLgVZaKuLJ66GzJ+QJNthg7kssGp6fFC8GvusFOCKswkbBhtgG4zdj l2Y1MxhhoHiSlVP6QWpJx7c8AJGAuEJql7pkfCRq0fZ06kbMyHbZUxHRO+XF4OK4UJUq eZ3qIaZrDUf4sLK+e5vdPH44Jc5WzcXsTqCKI0c+EcRxZFQlWkk+HKixdJyI2tGJ23EJ yKno883QkZHq7JQyqijDbjpeVUdZWYImslmXpAuxUS9u3+ANRvQEG6A4pTxGixiIFey0 MWfQ== X-Gm-Message-State: ALyK8tLcqGV5o1dcPANdoWOKbeWmBlbcepfItrJBAS+1qbwR8nm0d1eV7zFtLklwP0jYNuxIMa/83+YoclJ9Ug== MIME-Version: 1.0 X-Received: by 10.36.89.4 with SMTP id p4mr4581707itb.44.1464888382302; Thu, 02 Jun 2016 10:26:22 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.79.20.70 with HTTP; Thu, 2 Jun 2016 10:26:22 -0700 (PDT) In-Reply-To: <0448c751-8608-51ce-f47e-76280ebf14f2@selasky.org> References: <0448c751-8608-51ce-f47e-76280ebf14f2@selasky.org> Date: Thu, 2 Jun 2016 10:26:22 -0700 X-Google-Sender-Auth: v2XXXD8dwNxRlmg56Uabf7QeR7c Message-ID: Subject: Re: Suddenly poweroff in 11-Current r300097 From: Kevin Oberman To: Hans Petter Selasky Cc: RayCherng Yu , FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 17:26:23 -0000 On Thu, Jun 2, 2016 at 7:41 AM, Hans Petter Selasky wrote: > On 06/02/16 03:07, RayCherng Yu wrote: > >> I got a suddenly poweroff in r300097 (and previous revision in April and >> May) when I built textproc/docproj. >> My machine is Macbook Pro 13 2011 early. I have checked the Apple website. >> My bios is the latest version. >> Actually it also happened in 10.3-STABLE. >> It happened when the machine load was heavy. Before it shutdown, the fan >> started to run very loudly. After several seconds (20 or 30 seconds), my >> laptop shutdown (poweroff directly) suddenly. It seems not happen with the >> AC power supply connected. >> >> I installed both Mac OSX and FreeBSD (dual boot). It never happened in Mac >> OSX. >> >> My dmesg: >> http://pastebin.com/QjZmbGCB >> >> My sysctl hw.acpi: >> >> hw.acpi.acline: 0 >> hw.acpi.battery.info_expire: 5 >> hw.acpi.battery.units: 1 >> hw.acpi.battery.state: 1 >> hw.acpi.battery.time: 87 >> hw.acpi.battery.life: 59 >> hw.acpi.cpu.cx_lowest: C8 >> hw.acpi.reset_video: 0 >> hw.acpi.handle_reboot: 1 >> hw.acpi.disable_on_reboot: 0 >> hw.acpi.verbose: 0 >> hw.acpi.s4bios: 0 >> hw.acpi.sleep_delay: 1 >> hw.acpi.suspend_state: S3 >> hw.acpi.standby_state: NONE >> hw.acpi.lid_switch_state: NONE >> hw.acpi.sleep_button_state: S3 >> hw.acpi.power_button_state: S5 >> hw.acpi.supported_sleep_state: S3 S4 S5 >> >> > Hi, > > Do you have a temperature sysctl? Usually FreeBSD will shutdown the system > if the ACPI temperature exceeds some value. Maybe it would be better to > reduce the CPU load when the temperature goes up instead of facing a > shutdown? > > --HPS The relevant information is probably found in dev.cpu. That is where all temperature information is located as it is per-CPU, not per-system. Of particular interest is dev.cpu.0.cx_lowest, dev.cpu.0.cx_supported, and dev.cpu.0.freq_levels. A snapshot of dev.cpu.0 when the fan has cranked up, but before shutdown would be nice, too. I see no hw.acpi.thermal information. This is very odd. These values indicate what the system will do and is doing if it starts getting too hot. Is coretemp loaded? It is required to see the core temperatures and those are almost certainly significant. It may account for the lack of thermal information. Finally, a dmesg might be useful as it will tell us more about just what thermal control techniques are enabled. Just to explain a bit on how this should work: when the temperature exceeds some BIOS defined point, the system should "throttle" by pausing one of every 8 clock cycles. If that does not fix the problem, the it rests for two of every 8 and so on until the temperature is reduced. If it continues to rise and reaches another BIOS set point, it will initiate an emergency shutdown. If it reaches a CPU defined temperature, the power will shut off immediately. Note that this is entirely a hardware function with no BIOS or OS involvement. It should NEVER happen in normal operation as it is triggered by a significant overtemp that threatens to destroy the CPU. I've only seen it once when the CPU heat sink came loose on an old P4 system several years ago. I should mention that I have zero experience with Apple hardware and it is possible that they do some things differently than I have seen on other hardware. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 From owner-freebsd-current@freebsd.org Thu Jun 2 17:29: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 AB6B9B65DC2 for ; Thu, 2 Jun 2016 17:29:47 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 775A51BA2 for ; Thu, 2 Jun 2016 17:29:47 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x22f.google.com with SMTP id k19so39189166ioi.3 for ; Thu, 02 Jun 2016 10:29:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=Qtoy6Qwr1U12nVpt6Ib2UMy1kDvSSL6U0vZoX2E5Wxo=; b=b0Gsm6FjQ8c3nHpKrZtjNbewk8KTh6wOWvbQv4ff+eVhaFAmbkgWNAyqke2/BXxZU9 RFe71aX64Jylox70BZJ4bSD829rSrGXt9ozve1sm/rm2E/uzSnEoTBLTGpYHqsbxA1wh lhi1e/ueYnKRZ3keeMDoovmCp8JGtYL7GZvs0hnJcOiDez5vKVWik/qY9O/utcisLs61 +xmOr3IfSTYiV8R1yh5wubeqA7L38DR/Irf5pUaKUjV76tVvXXzeJjQalCPoO7o+ENvz bBTm6f21JBwICRyX/zK7T8ZVWJcpISYD6KAuSln4b4CzSEdP62O3LUYlaogPKKjC1VNE ZpVQ== 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; bh=Qtoy6Qwr1U12nVpt6Ib2UMy1kDvSSL6U0vZoX2E5Wxo=; b=W3R+I1UBbjXmi4jmTOAklbJQlnTqXzhUP4dYfjZSjH4ioTVkF1GXbDgGpRIICJsxPa lLeA/9fU5wM4paJCPrqszVbBgJuNR9PFEtyQ3X0AjuSPqeDRaz/mj/OwqLyl01IIMcjW 5KtDHxohflr/7jO3E3Y123kMXGY7vv8mqRbEuOOC73ekLdDV2SLAehISGq61nMG/Dh2P 2tSAJ2zjDLgvimWVEYFEG6YYwA+CfAvo7k8T1fGskfzmNOmD/AZ31gD4w0k4Ztm9jWY/ y5gVufL1EyFjboP2ZXNgsWeYpTbXS6iPXaaVXR9pU0QHH5q2bmQ5hARvKBcxvcrOVc4J QfKA== X-Gm-Message-State: ALyK8tJDRhDesdW60vgqf2syK+OkbDuxMkt69w47SvkTZhTgMRZ4UXESy1QIey0jd1jW7caRzQgbGa2FxhkD5A== MIME-Version: 1.0 X-Received: by 10.107.144.67 with SMTP id s64mr4297376iod.165.1464888586806; Thu, 02 Jun 2016 10:29:46 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.113.3 with HTTP; Thu, 2 Jun 2016 10:29:46 -0700 (PDT) In-Reply-To: References: Date: Thu, 2 Jun 2016 10:29:46 -0700 X-Google-Sender-Auth: 8658ruvJIDfqDCAUwMeyPDfz5FI Message-ID: Subject: Re: Streaming live tv over the udp protocol causes problems From: Adrian Chadd To: Oleg Lelchuk Cc: freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 17:29:47 -0000 What are you streaming it over? wifi? ethernet? which chips? -a On 1 June 2016 at 20:03, Oleg Lelchuk wrote: > Hi. On 11-ALPHA1, when I use vlc to stream live tv over the udp protocol, I > see a garbled and choppy video. This issue doesn't occur on 10.3-STABLE. I > am puzzled as to the cause of this problem. > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Thu Jun 2 17:35: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 1FEA8B65054 for ; Thu, 2 Jun 2016 17:35: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 060C411E8 for ; Thu, 2 Jun 2016 17:35: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 2EF8DD012 for ; Thu, 2 Jun 2016 17:35:10 +0000 (UTC) Subject: Re: Streaming live tv over the udp protocol causes problems To: freebsd-current@freebsd.org References: From: Allan Jude Message-ID: <0ae227ae-0154-cc15-eb64-17984ae2012a@freebsd.org> Date: Thu, 2 Jun 2016 13:35:09 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 17:35:17 -0000 On 2016-06-01 23:03, Oleg Lelchuk wrote: > Hi. On 11-ALPHA1, when I use vlc to stream live tv over the udp protocol, I > see a garbled and choppy video. This issue doesn't occur on 10.3-STABLE. I > am puzzled as to the cause of this problem. > _______________________________________________ > 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" > Are both machines FreeBSD? Can you try running iperf in udp mode, something like this: pkg install iperf client: iperf -f m -i 1 -s -u server: iperf -f m -i 1 -t 20 -c -u -b 100m And give us the results -- Allan Jude From owner-freebsd-current@freebsd.org Thu Jun 2 17:51: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 35A08B652F2 for ; Thu, 2 Jun 2016 17:51:25 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0121.outbound.protection.outlook.com [65.55.169.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 936441CB2; Thu, 2 Jun 2016 17:51:23 +0000 (UTC) (envelope-from sjg@juniper.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oA7LXTA8SrJv7idm16cfNlAu9uQq4WMlhmelkg26rBs=; b=Eparg4YGBdUPXPYCGt280mH1OHoxUerFcKUDt6ExyhWG6hAFL/huZBpaUiNjMXYHfdJGK/FyswMrFrVsCo5tzyn6ZTT2HWcA/gz77YOUUQ//Y85LeOTS2ZcB+sRS+A8aAbnsfTWLEfc/jtFK2vhG1JDWBmhaNm2QwRSpPnP5S9Q= Received: from BY2PR05CA032.namprd05.prod.outlook.com (10.141.250.22) by BLUPR0501MB803.namprd05.prod.outlook.com (10.141.251.141) with Microsoft SMTP Server (TLS) id 15.1.506.9; Thu, 2 Jun 2016 17:35:34 +0000 Received: from BL2FFO11OLC007.protection.gbl (2a01:111:f400:7c09::198) by BY2PR05CA032.outlook.office365.com (2a01:111:e400:2c5f::22) with Microsoft SMTP Server (TLS) id 15.1.506.9 via Frontend Transport; Thu, 2 Jun 2016 17:35:34 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.19) smtp.mailfrom=juniper.net; dsl-only.net; dkim=none (message not signed) header.d=none;dsl-only.net; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.19 as permitted sender) Received: from P-EMFE01C-SAC.jnpr.net (66.129.239.19) by BL2FFO11OLC007.mail.protection.outlook.com (10.173.160.142) with Microsoft SMTP Server (TLS) id 15.1.497.8 via Frontend Transport; Thu, 2 Jun 2016 17:35:33 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMFE01C-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 2 Jun 2016 10:35:22 -0700 Received: from kaos.jnpr.net (kaos.jnpr.net [172.21.16.84]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id u52HZLJ97630; Thu, 2 Jun 2016 10:35:22 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id C42D3385551; Thu, 2 Jun 2016 10:35:21 -0700 (PDT) To: Mark Millard CC: Bryan Drewery , FreeBSD Current , Subject: Re: 11.0 -r301139: WITH_META_MODE=yes vs. "sh: ./make_keys: Exec format error"? In-Reply-To: <943D8647-5894-4E6D-AB49-02EAF39433F4@dsl-only.net> References: <890D3808-1939-4BEA-886F-324EBA8C8671@dsl-only.net> <0b75f448-047f-53b3-3e1b-7de17a2da949@FreeBSD.org> <943D8647-5894-4E6D-AB49-02EAF39433F4@dsl-only.net> Comments: In-reply-to: Mark Millard message dated "Wed, 01 Jun 2016 16:48:38 -0700." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <91707.1464888921.1@kaos.jnpr.net> Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Jun 2016 10:35:21 -0700 Message-ID: <91708.1464888921@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.19; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(199003)(189002)(24454002)(9170700003)(92566002)(117636001)(19580405001)(97756001)(76506005)(50466002)(53416004)(46406003)(19580395003)(105596002)(93886004)(86362001)(50986999)(106466001)(76176999)(87936001)(47776003)(6806005)(77096005)(4001430100002)(23726003)(586003)(5003600100002)(11100500001)(81166006)(4326007)(8936002)(189998001)(110136002)(107886002)(8746002)(8676002)(2906002)(2810700001)(9686002)(50226002)(2950100001)(5008740100001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB803; H:P-EMFE01C-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11OLC007; 1:mVXdvrhptHRo5boqF/ENSEx/pRtOPc0/9R6TFfkmzwCDleW9fnviPHGDfFhQyQhfgguIOR0fll0K2+farQrR8G0I0S4Tp/jP3hbWIh09CIH6nGYn2EcCU7BUm+pPDhxEi3V5K+N49wlTnn6B14SjRA34yNnv5ZCMn3W4lZT1wkoD7xkXvOrPe2qlbYB+PPTxKjfjFVIbujy+fO9NyvcIxjSF9lmZq2TsYNA3XfyaIjgIC896MUQWoRgipARWpRDIHYKzewPMvskcMDN1RN9ENvSJhiPl6WIH+sNdz1U7SDQGoZu37W0Knit6CE0dTZJkdD+bjpd/vBHJ0cT63GfVrS+9aYsMhID01vD6+52d0NaaLRuI9RzvkwpSAiABzHX7yNzTYSZMBSqirNvKPDi2ZwD9aIqRxGoiLmEGgzMgTIfT8EUkZMc3DuzEKTxpVZOhNvkKjP/3LrB9gq8ygLMlLsrdiHFB6rOmcqmJmNiJDrA= X-MS-Office365-Filtering-Correlation-Id: c6606ede-b831-4055-ac65-08d38b0c4cfb X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB803; 2:rZs0HgR9NqihZ2jfMNSZp8JXWsytG5s4EKXekFqMEPMLD+FjiyuSOD0+jRlGwMOqz9osRHSiS9FXuFEY+09bagHN7M+GjCfRcW6K92VhgttmL88ksCadJyzTagih3s7VD6vK6SuHJhLDgqZPFYkiVWL5fWmbbawucq94UjkeQxmg+6FTx/zGnqmz+rNtjL+g; 3:JSW0xvOBVkLWmA2+jdAsBaXM+OFaf+nJVYsUBalXy4xCZo6NWOU+C1+OgZ5j8Ul1L9i6iR5GdZPaHDITbU+EfPmfYZnpMpkoqicrelkt9dsICKJ/B/fi0fTM0zU4Dy4gmIv9TFWa9I34gDotrX9Zo9rCT/sFAkXTUfbeOqQntlqOGj/NvKTMqMLhPMMyyeSCznzTktvatSg25LxCnHWBp0jKPPxSbJIuvVzWPo1Y9A4= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB803; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB803; 25:Tly60j9KzPPA9kYlbByEksI/yzTE8nRZsCM7LQsHQJMaAvCkmCew9FDtCfPLkba/1RvZorInBz76mNug46zOsEhSBX05uP7uidOB2rk732wYiajT5qkw2OmI8QqMUJyeYaYT2dsf3JfR9BD1yQcqfxf4r2kTFkiraQICexcL5QwfLNAvTtrthP3LbyDYlHJWRTiDH8Tz0MHxDBARvJYOSuhxHeWKINXAp+eMRuS8+D4tccX6uQzUah/xUYzL2UeEXMoNs1yZRb+azR59m/LbnErHoOSeH7VcqBNbSRqxTPov5lkopIfKPx876hSycdQCwn7I1GBEUz6UDG/RJFuf1DmGKKQyt19JlLqHC5DucV+ptvE1cu+6D7DXoFzgW+I1RO1/SqtJgBI6sg8JlTrVdwlDV/zOI6pimT8gJXabLyHJbIfyJNapxbX8qv87ydVM1n1YnkGWslOwEUwLvF+/fg78DWz4PrP8f80FhYtSb3hijNWhN8PlNrLtB9CA8Unx9Dq81n7OAhQpI1wvct0mOQo6ak3Bnz2yTmHR50CqPg01OwhPI9go+mNM+1SIp6RaQGs2Zp1/cJoUIknkXtKYOz/A0tDmZRXbRVcvRLsNi62qomYOIjdamBGz8ERv7ANg8S9vgz3SMNSgGen8R25h8Nkoub1WkBOzbvD2XNTQHVl0xb2+hloAU8n95jwl/juqgnn49BhPIzxRNNmr2fziy8/XNgc9Kidk1iCAYG8VJlBe+7DYn0Q36y1NUyJ0ZYRz6Di/NjOA9ReyMUyzUW+mog== X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB803; 20:nMzGo9fA6gyTNn6pY0ZAVPN7lm4dje3aQeA3EimeUlcVLCfl/31hTeM55GL/IFxweXkjCOMPWFH1iBEWfWVHuefJuPiaOrSXKm4ZEB9PxwLGYZBYBoodDiRLUOJjVdW8s5iuX2g4VfN5CvUHP3NRKt4c29jV3cZk3QNBGg7ymp5/LKO/tHDcNPiw8yfWFm3aR0cClrFu8/tVeupIIeUBfWBVmPsOb8n//rF3R07WQmWEt8D7IAlYv6ku8KwsOi2h9Rq9YoGSuNCqtsvyvKL4x3RBavXhInyRJv6yJkMifFnCv9onuJ1hItB0k4b9IhIVgvjYfqD1NHx5CVCvqJHEi66sWVY15RW2T0vETVVzqsnbSiE5Q/+syTogpdr6kjHfQzY3fyslS7DnjQraf0q0wAPb5fnxklH9Myght1j0cUmxmaiY95GHiVTKBHu193zpm51jEcWzICWDnfz0hs7ogjkH9PpzKeandbIJFdbu34ip1wCeDwcT85BLjfupaTIp X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(13024025)(13017025)(13015025)(13018025)(8121501046)(13023025)(3002001)(10201501046)(6055026); SRVR:BLUPR0501MB803; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB803; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB803; 4:Rgw74kleKGANj7at1et2Z8uyGk9UoRWYxLz/gZNSnepCWHom+YD3oaPI0ZLoFemwKzqNbKsEUsn7UnDr7jV2YRcGbTkCnH1f3p4yn14ZIUiP0vwHgMiJgWazJaKHE3ChC5wd82OTf/BeKQ0jb52/LokxVcQ8J/xcERkaNltJhw8WCFZpaM71N6YFE1Y5vH54+20EeFcI9ayMAwkmb5Tbxu/XVzkIDl6U5WTdYm+GbsIQEJEmVEBp+ulmB/ZUJk1zdGCVoyGx5JOvUcQYSasUzLPy7W49ofHtYWQVd3UAzd1KIkkiAyJ+/9qTZZCWdjt8UcYIflRSUPhjo7VFKt/011CRgQQjDxkwWlJBpgohwrqgq2iFT5zYd8s/Q1ZgO2EOJtEYa22euFVJn/kiylUocKpW2RWnoqBq9wRq5Pd0r5V32GD2XaBwvUtjp0EiCRyjg/W80t1oAanbyRVoNTJuwR77CwJxmSEvCJjmRhN6xVY= X-Forefront-PRVS: 0961DF5286 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0501MB803; 23:vX4ftS+7xnN74Tu1aio4t6+mnWNKQ3jQAuXYN1sy?= =?us-ascii?Q?PIUJenEbgNQzvk4uc44g+uSso4sJnJRnstoccJn10BxjOa1rE2Qe6sMMmD+0?= =?us-ascii?Q?YtB4uYNhQ660vbmexJb+QMMKTvkcX+YcBvwgraL+Z3zcLnGFzXdxKKDbIgNS?= =?us-ascii?Q?oBXfkbqijtCby6hHsp5rxuBSYtLmX/5u9Xqk2wH8VaP5BexQXzrlQH0lwGdb?= =?us-ascii?Q?87++qgZS/phs3LYjZCNcJCGMMfJFFUEPGHohSr8LQgMq77MPm/8depjuSd4h?= =?us-ascii?Q?A5Em3WIWXdkSY84Dd1ET4MR1zA31Lb0ntfWYBCV1cPibbaYCERAN9rtHUXJr?= =?us-ascii?Q?1sER74xEWwGlBGwl74fQ1/bKIuZYf96OldwaYvtqLd4KWDGzLg+6SRxNnpSe?= =?us-ascii?Q?GL0Cn+rKLVbpnSB+QRmnMhsgqTCdS/vtHqvn8udoq8+pr3k5+d7P0drffz4O?= =?us-ascii?Q?8+Rb0kNT8AAZLlJFqfcub37aO8A+Hh2WZO3u6j6Vv2SizjbOBUQo86dePUWZ?= =?us-ascii?Q?rSg2v5lepD5IeGGpZI9ytaIIIH9KHAH3FrxIUacO9rKyNkxD44ChIIA2FU12?= =?us-ascii?Q?SDpVohxTimqlcs4ddFDWa+FGO09fMo4OuQikC6ZtUv3quZc17oWq20zo6dQS?= =?us-ascii?Q?O0vV1Wn9/FfEdJ3Q8Zul6XQDs6aiPpvkt7x9m+hPylf8y3dynpk00IL3AIYg?= =?us-ascii?Q?s1j9MI7nk+6Q2FqvejYfh4dUw61z1ZRXIGOUghnHg3kWzqQA69rkhfv0QLHb?= =?us-ascii?Q?E6zl4AkAMTkzcYqOyQ6LiUNOcLB9W6jBM27mtoMwd2dz9AZxqTXAgBdrIydO?= =?us-ascii?Q?4QcfPI0WMd6y+lVBteXwUi1aAdzFzVPGZi2lbKr+75qynhyrx7Y4VkyFgosn?= =?us-ascii?Q?Fu8OyI+oGI2Xpao3bCDtHxx5e1usAFdsUxyDIAzblvDmJ0qZfpVvKOSippLu?= =?us-ascii?Q?TCkwd3d2nWHBeEYLZi2e2AlWJiXACWtfQjcE6Y+/JBxIKCpQ6A6Ov7Ix7iZT?= =?us-ascii?Q?TbjwwtduvHDWWfnw9tt07ClGQbwGZEpVwFZ73r465KENC1zx7j7xYywSIJ6s?= =?us-ascii?Q?W4ggce0n2gMFcqMCKegAGyLfdSt30WuCATgfL175nn1TO1su9L4sq8CWjdzP?= =?us-ascii?Q?04NVxixIoroz0SQAeGSaQILTaGkyyiw5pszpz/Nlk8D4i0s2/DklTQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB803; 5:qf5VfuTVjAxMZfQsgRtMWy5b5yrhHq6Up0EcdPMEFOzLBtva8BBxHlYCX/8JKI0TUKXRNBAloRlnUCF5/FBq0RtXMYr/gWFfrMRDwZCd2hWCAfac8g3fD4ES/aZrGvJD+VBpop2iai1K3TM857ftYQ==; 24:K/XONPQwj37ZSOo9eQCeCdmNR47e4jEFZiV8go3pu17Zf3ngsNLP0cM76aghzQf9uSlw5MHZCNQSulz5fAv9ARHmWFnePVkuLhTC+CnI/yY=; 7:/yjt8sFADbmYRcJyYg/PvBCWpkUVjdmsw8fTKmhNvoYoyGgOjt4a+LhNp6SejYFLhl5430gBol6dPR+TKLJYHMx/YNO8TusVjCyb/G9tWb8uAFhquHZmwhYHlQHyfPPQpsIsAEYBjLGGUlHjfXTGeBKJjbXRFZS+F31sW6jKEU2J3VR7l1VvRH6iRMVN4toT SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jun 2016 17:35:33.3214 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.19]; Helo=[P-EMFE01C-SAC.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB803 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 17:51:25 -0000 Mark Millard wrote: > >>>> Building /usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncursesw/make= _keys > >>>> sh: ./make_keys: Exec format error This is an arm host or cross-building? The error suggests HOST_CC got the wrong value. You should be able to look at /usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncursesw/make_keys.meta to confirm whether the right toolchain was used. From owner-freebsd-current@freebsd.org Thu Jun 2 17:55: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 EDDFFB6551C for ; Thu, 2 Jun 2016 17:55:39 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0121.outbound.protection.outlook.com [65.55.169.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6D4511399; Thu, 2 Jun 2016 17:55:38 +0000 (UTC) (envelope-from sjg@juniper.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XLPLMzekXMmwMC+7PnAZCoKz9rY00k56sXWa4HghLqo=; b=GfU+TgXWwd4FXBCIQFaZ4iDKhkxOofbjv9IUQKebbX7klnm4DWf8M2HfWIOLzjHNmWJ2Kdta3HQWvDC4fJEg4Z5QR6G9bIodwUJ1fqv4AGm6CJ2Z/qVFQjYrreqDiMgYOWss+eQvnmkaYzg3aoQt/6VtB/0JZnlMfs9Udk/tGYU= Received: from CY1PR05CA0011.namprd05.prod.outlook.com (10.166.186.149) by SN2PR05MB2496.namprd05.prod.outlook.com (10.166.213.17) with Microsoft SMTP Server (TLS) id 15.1.506.9; Thu, 2 Jun 2016 17:55:36 +0000 Received: from BN1BFFO11FD023.protection.gbl (2a01:111:f400:7c10::1:171) by CY1PR05CA0011.outlook.office365.com (2a01:111:e400:c5a4::21) with Microsoft SMTP Server (TLS) id 15.1.506.9 via Frontend Transport; Thu, 2 Jun 2016 17:55:36 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.19) smtp.mailfrom=juniper.net; dsl-only.net; dkim=none (message not signed) header.d=none;dsl-only.net; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.19 as permitted sender) Received: from P-EMFE01C-SAC.jnpr.net (66.129.239.19) by BN1BFFO11FD023.mail.protection.outlook.com (10.58.144.86) with Microsoft SMTP Server (TLS) id 15.1.497.8 via Frontend Transport; Thu, 2 Jun 2016 17:55:35 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMFE01C-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 2 Jun 2016 10:53:58 -0700 Received: from kaos.jnpr.net (kaos.jnpr.net [172.21.16.84]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id u52HrwJ13274; Thu, 2 Jun 2016 10:53:58 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 23FBA385551; Thu, 2 Jun 2016 10:53:58 -0700 (PDT) To: Mark Millard CC: Bryan Drewery , FreeBSD Current , Subject: Re: 11.0 -r301139: WITH_META_MODE=yes vs. "sh: ./make_keys: Exec format error"? In-Reply-To: <890D3808-1939-4BEA-886F-324EBA8C8671@dsl-only.net> References: <890D3808-1939-4BEA-886F-324EBA8C8671@dsl-only.net> Comments: In-reply-to: Mark Millard message dated "Wed, 01 Jun 2016 16:25:29 -0700." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <92115.1464890038.1@kaos.jnpr.net> Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Jun 2016 10:53:58 -0700 Message-ID: <92116.1464890038@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.19; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(199003)(189002)(9170700003)(4326007)(77096005)(87936001)(53416004)(92566002)(97756001)(23726003)(86362001)(50466002)(47776003)(117636001)(76506005)(2810700001)(2906002)(189998001)(8676002)(5003600100002)(586003)(81166006)(2950100001)(46406003)(50986999)(4001430100002)(8746002)(76176999)(6806005)(5008740100001)(105596002)(50226002)(107886002)(106466001)(11100500001)(8936002)(110136002)(9686002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2496; H:P-EMFE01C-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD023; 1:PHp2rW57+YgFGWKrZw/ANUqVLqE9OZ5pRvIaB1incbHlhnxz7rraZKr+z0CtFQo65I0YcyJmNYGSxUnG81RyFvEaCYJ/sLFlJPQ6jkT2/lwW31YUzBRgYWHgYiFH80v1HXLBM64rvRblpUadv1F/eFcmTdBQX8X5dCK9gehvdhL55ezKK/Vu4htdkKv+TCANvuf2XfnJjW7GrA8oKGxETbsG1Z4Ko7XgeQVq0QtkIXcG5C2bA+zlNwm4ILWbqOX2VYJcfWazRUdYNxwPy2CdKc2CQb79vmb2xQtuIUGzzc41a70GA8HB9T1gSm8Inz/tgonLnRFm0qRecBfUQZc8ILxebQgtysl4dtnqxtepPbIktnCn1bVyaAO/Leg+4H7fLrBLjyHNYTfsxUVdrJe9PILWc9hX1n76ludS1nZohUYd5ZhLTIn3BXVVDumeYo7MFw83qx2uktBxRoxvrM30CLDyjSU97oe1l6eTqDzDLns= X-MS-Office365-Filtering-Correlation-Id: d94f3e89-f9ac-4117-464b-08d38b0f19d1 X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2496; 2:VN6N1mE/3mGEbjwSAZvH5R1kxaSziN9ZDpjph8crwIWwN2tNEq/dLUWi+ZlfMiIUYb7Ui2VQW7RZ29aw4BJ4uxu/dmDDNWH3KfF9B/Cdwb0quEvOMmY37qUogz+qfDgcsYIZBfHjPQk+aweuXGVaYJzG+nFtkAo9UQH+s6bGxAuXVjuLlXs7vAR3YNV/P2qy; 3:zq3PoiKDx4F2k1mBWZRVBq/qDZ6DzM63acq4VOdKluHLKAZABqsdI2n9mxWqsQTWgROhPTyFSVo86TBuaURSLCAP5c0rQhwAwIsehRGnhP7x1yqt/763v6CQSl7HlJhr5jlJzs7GJ4IzIEXT1Yf9LvhLkyQ7H8sxdssUxxFO/19DjsIpcwyWevqlouFBV6gXDS/zTE/0bhjzD7nkcJxb4eqWv+3hP14yo0IwuIIV4cw= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR05MB2496; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2496; 25:xVdEXQps2h5Kglf/G/dI1PhUdUqzgCKGcBBLZrl1cx5MLPD/5d3G/bGjvJIIIq1U5SMMrKEpOeeUkVMypKIcXv8HQD1uUhoY4R9wqDgZqE7OfSBAic5QcaS1aptHvy2jW5/v8lxsFKiK4mdF2qwxcXEshu0xOTGOFMz98Co7eK6CYrrfsFZvWNBIN7ru+3N3y4BW1i1AOXnAq8gau48omPLRj82LCz2L6k3D0y1Es7wX/MHSnpBiH1Sw/ruCDxqDHSdQ358XV96KmXqwWpO5NgI+5OE5jIi0CJ0/GC3RLciLwyTtSpUsGJZMoXuu6W9i/UOpQjN63rC+vPpRQymRdztXYN2oTb4AMvNXcX6aLi55zmZZ1JTKl1qdJvFKU6hsWpGMzhKqDqpMK3RKpUVE/21+1fNz3WFVnSnSVNvjuxrCbZoycviNVz9DJRyNpRfsdifJjinzFivdGcZ7EX15XWL6F8J340F8jc7G6YarnP2CPHFD82VLtH4e++ni9eQ6By02ToSLEdBYDmufOZZlAf/XDVJ5WS+O35Xob19UGutaMS3batykrasLhlGWxGv61MejfX4oc2TOUgYIIWxBrpROxtDUTi6fChyvD9hwEm0wruth0RoaeXdohYo9RPiePnmtwY/yLFweFLZWCqYvPzhfeaAE0SxmWgBW/sMcJz2rLRihJ3oV8lRC+nYtc8mPhPRF5qlu9Xf6W3lbLesZWn/ArDJUkmGeaGvcslok0OAS7Oqth8zsFIU++TbdOyln X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2496; 20:is3zkiITRadZgFx1qXCAWmWSi/xwn1vfeWpucgGNmZYcslLWACpTRBP0MAnSUD7VkzJA0pzN1D4vb+seqO5fkImL+aRfsBumHcHRCPE00NNqAmcjcXsj3a0lSEUIP3FgqsTjHpUNzjn9GY6EKuzoaEjn8y4l8yj20CZwrB4No08q/DsKX3VAv2IAAVvptQjO/y3kdIOPU0M3G++fveNdB45bvczYEawCSsaulhIJ73fd22bVcizgAgNbJrkFVVPvKkgRS90fw0UdacwNZZC/f7dCE+03pcTdC5RTBRdnRcT+hLgwDy25Cyk57IpHxLyM2u1kYEWc5Mxmz18jwJrxXKOnlgDfCP9TvTxWyQxxkCZeXKSAKlEihy2V3/tax61mRz0caKjOj2pWZE5uhp4pgv6oe6sWuXaJwAKilf9+JhsPSVdCHWHjiOqlIiQAkofYckfZL1ofsiDfOIGupcfuHOWERWm90K1PZ+ppftyztVN9tLkVla04GFZTdruxiReh X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13015025)(13024025)(13023025)(13017025)(5005006)(13018025)(8121501046)(10201501046)(3002001)(6055026); SRVR:SN2PR05MB2496; BCL:0; PCL:0; RULEID:; SRVR:SN2PR05MB2496; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2496; 4:xfRzGX7ByJBlq1tBOAQF0JE4QVMxsR7kTVewBKbfnePnbPpJ91UFfJU8DXUChSKRUxAYJPOEQl1zn1/F0pDGy5+X8axj+/9hylcPMAfBmQoX9iZpSJkkThcAEwOic5ycr1GqPjHpytowNfqM2alre6OR8RxOdl9xHV5whCqrvuT2GteR28rWZSzTVoVDKdRjdl6hbXGbXW/9mAAYpErAFDZDY95kPG5X22Syst9pLEY3t6dZ+rDl5PPS3+m6i4+o1TOxopOG2sYcy2qiCRRaJWlMaqGJ0GRD6fPINY9fY9lzKwrsk6/OcbZhmDocqG1AB1dqU0n7fYjmvTjHZw71V6jCCkzUlCjQRe9qRyLXXVRObMGsYHqBGWIJiBi8agILyZ4IPQNXwZV8V5bToeKC7ZCzPYHCZ/xNnr12uvr04Gv5YdmndvI+LFW5NdyoMx2TWWtBUDsTDAQzkdpGBu2uU5c5s/bOVd9bnFptNblKN7k= X-Forefront-PRVS: 0961DF5286 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2496; 23:i7OBoJcflPh0SOta3Ve3aEKdDyHFtjpXTRLRA1jWA?= =?us-ascii?Q?a7HJ96u8k+2AqrNfGse/H5egSvGrjRmVgb4C+gEtTzAhZYE1lbkP6IQt1OOK?= =?us-ascii?Q?2ZqHzmZbOWfzIBVdFkiU3imhreKSDhpi8WHWUO+PxaX0cVFJZtc9m+ffJakL?= =?us-ascii?Q?h4luzFxNpbk7lH4NOvFUc15x1lGMmonjk+TjrMnhig7wo3iBzO43pNSLzRJ+?= =?us-ascii?Q?+lIGvCyrhb8t6allFiA7Ja68qtud+ooGt9Vc/fHRnwAg/pPs/5TOmMlAEOGw?= =?us-ascii?Q?QKXjGBWerTHScUyythojOh3o1otxyDJGorWqTL75OvEyZVrGODSurYDnr4pJ?= =?us-ascii?Q?h2b6Fhl52XOy7Bz3vr5faQmS+swvGZ3yKNRl22fOnC0KGLTv3Q/1CvNNfsIy?= =?us-ascii?Q?PenmsV7lwCtoM5kg15lHTFklaBTEkNfb6kuAe9Tz71sJLGOw8v4PVad+yRYv?= =?us-ascii?Q?RaqAGDL+yEMDNk+R9dW2UelIiDeaMq0mJLaNxGTcMnVfs08B4HGnV4MyGbn8?= =?us-ascii?Q?2tBtNZfqGNookwfS1SOm0P8G2aqLcIGiaKxLjh13x7Fckx9gIY5CjYywnqZL?= =?us-ascii?Q?5NQYiD05SVCdPCGdbkD3yOHYTAuVvOuxVI9+SOKlqUoDtNaTZI1lzMyi/KWT?= =?us-ascii?Q?VjJmNRXc03Q9e7jrIdxRl6tYawNhMMcr3eEUxWY5TSY+nMFMAEcxiRHt6FWc?= =?us-ascii?Q?PuFoT5vvA6RlrYeiJjAzrD2SIZZttH8onIPQs04zNt9PivG9PFuTGMyLUHsk?= =?us-ascii?Q?1sgJa7YVauZ4/nJSe35y805e0qzcZiCHKTKEqTQ3HhVwYP0Lcqjivo8Y53iZ?= =?us-ascii?Q?Jm7SPomU/rtn3j9X9+/APsfyBBUhjw4HRFaNJxJ5TLYbvO5Ulg1V1SWP1SBg?= =?us-ascii?Q?94rLXr/tCOBmIZhQ2gRjW7FXEKl1nZU9FaJ2/1pG5Hcyaz4Vjn83Ht7gaWdy?= =?us-ascii?Q?PicBkSYjhtbjC3yp5jCdQmixH9J7sK7DCHb+S7jvR+ZCcgYLL1k6GWsR82Qs?= =?us-ascii?Q?7Rw7pQKUad37qL0MXrYPNTFSwk2GYbfc3Plk44dLpsbG23h6bQqmw5htn0LT?= =?us-ascii?Q?dbt5h3GyfuMjAY/kp+z2ccpStAq?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2496; 5:GVCewFZ30ES+waOzMcC/dThdxCyIxoxrsz1hbB5NHnNQgCCZhMHl4sDv1nklg5FMJdxmrL4uzs8VIsO1TGpHM2bEKeC8pLxIQgF4oWVJZ3IZdU8hrTuYs4LnUJsFL6qZN/i0OE67VBovSPlh4KHw4w==; 24:J239cYdb0q/sxNQGyrLf2mOQGb+Mn1qUa9AEePFSsOEGXNQIJYZv7W7KdSkrGwDMMH/1BQ1KhJ1BIuUGNHVT1trknv6os3ufYFMimdy3DDI=; 7:+MvpGoMgGkXFLq1R/fdDDW/+rYwMajihnDPdyRdPbb9pColGZAjU+fBjcM1iy4zo8j1YRsrkkNYKq4K6Bt6pSEL38zC77ITCa7yi0VplLrJj6QmcYTji8h3kSR88TeQi0lgBFmVeUP3gTl4foNM/DLkTVQ2pzmN6c0CPU8TY1KM1xeEz2X8/19Hk7By+Ok6Q SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jun 2016 17:55:35.9543 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.19]; Helo=[P-EMFE01C-SAC.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2496 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 17:55:40 -0000 BTW Mark, thanks very much for testing this. > > # grep make_keys ~/sys_typescripts/typescript_make_rpi2_nodebug_clang_= bootstrap-amd64-host-2016-06-01:15:17:28 > > Building /usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncursesw/make_ke= ys > > Building /usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncurses/make_key= s > > Building /usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncursesw/make_ke= ys > > sh: ./make_keys: Exec format error > = > Note that ncursesw has two Building lines above with the same path liste= d. This build is still using the normal orchestration (tree walks etc) so it it not at all out of the question for directories to be visited more than once. If curious; you can add -dM to have make explain why it built it again the 2nd time. The output can be copious, so you might want to only enable it in ncursesw eg. .MAKEFLAGS: -dM From owner-freebsd-current@freebsd.org Thu Jun 2 09:44: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 0530CB647F7 for ; Thu, 2 Jun 2016 09:44:31 +0000 (UTC) (envelope-from mitya@cabletv.dp.ua) Received: from mail.cabletv.dp.ua (mail.cabletv.dp.ua [193.34.20.8]) (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 ABA3E1C03 for ; Thu, 2 Jun 2016 09:44:30 +0000 (UTC) (envelope-from mitya@cabletv.dp.ua) Received: from [193.34.20.2] (helo=m18.cabletv.dp.ua) by mail.cabletv.dp.ua with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1b8PAv-000PaM-Ga for freebsd-current@freebsd.org; Thu, 02 Jun 2016 12:44:25 +0300 To: freebsd-current@freebsd.org From: Mitya Subject: head r31168 - Panic String: protosw_init: keysw[0] has no usrreqs! Message-ID: <7e43f5ff-1d30-f65a-f4a0-c3865afc6459@cabletv.dp.ua> Date: Thu, 2 Jun 2016 12:40:34 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 02 Jun 2016 18:02:10 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 09:44:31 -0000 I am now upgrade my machine to r31168, and get kernel panic during boot. Keyboard and remote console do not works. http://postimg.org/image/7j2aq6aqz/ From owner-freebsd-current@freebsd.org Thu Jun 2 18:11: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 C0FCFB65A35 for ; Thu, 2 Jun 2016 18:11:09 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id A4DB912D3; Thu, 2 Jun 2016 18:11:09 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 9E7E01D2B; Thu, 2 Jun 2016 18:11:09 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 5F208DBC3; Thu, 2 Jun 2016 18:11:09 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id 58nfybVB-QFr; Thu, 2 Jun 2016 18:11:07 +0000 (UTC) Subject: Re: 11.0 -r301139: WITH_META_MODE=yes vs. "sh: ./make_keys: Exec format error"? DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com B3907DBBE To: "Simon J. Gerraty" , Mark Millard References: <890D3808-1939-4BEA-886F-324EBA8C8671@dsl-only.net> <92116.1464890038@kaos.jnpr.net> Cc: FreeBSD Current From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <4a2034a9-a2e1-d951-aecf-43e043c48d75@FreeBSD.org> Date: Thu, 2 Jun 2016 11:11:09 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <92116.1464890038@kaos.jnpr.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VCBm04XMs2bFNKf7O3j9r20Gg0HCCuPfq" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 18:11:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VCBm04XMs2bFNKf7O3j9r20Gg0HCCuPfq Content-Type: multipart/mixed; boundary="QVI5pCEJDGX5f5oENDUoUPgaXbVtOa3k2" From: Bryan Drewery To: "Simon J. Gerraty" , Mark Millard Cc: FreeBSD Current Message-ID: <4a2034a9-a2e1-d951-aecf-43e043c48d75@FreeBSD.org> Subject: Re: 11.0 -r301139: WITH_META_MODE=yes vs. "sh: ./make_keys: Exec format error"? References: <890D3808-1939-4BEA-886F-324EBA8C8671@dsl-only.net> <92116.1464890038@kaos.jnpr.net> In-Reply-To: <92116.1464890038@kaos.jnpr.net> --QVI5pCEJDGX5f5oENDUoUPgaXbVtOa3k2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 6/2/2016 10:53 AM, Simon J. Gerraty wrote: > BTW Mark, thanks very much for testing this. >=20 >>> # grep make_keys ~/sys_typescripts/typescript_make_rpi2_nodebug_clang= _bootstrap-amd64-host-2016-06-01:15:17:28 >>> Building /usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncursesw/make_k= eys >>> Building /usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncurses/make_ke= ys >>> Building /usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncursesw/make_k= eys >>> sh: ./make_keys: Exec format error >> >> Note that ncursesw has two Building lines above with the same path lis= ted. >=20 > This build is still using the normal orchestration (tree walks etc) > so it it not at all out of the question for directories to be visited > more than once. >=20 > If curious; you can add -dM to have make explain why it built it again > the 2nd time. > The output can be copious, so you might want to only enable it in > ncursesw > eg. >=20 > .MAKEFLAGS: -dM >=20 r297997 was the original fix for it. It is visited twice (build-tools and everything). The problem came when I added .META to all suffix rules to work around the lack of default .META (the patch we're discussin= g). --=20 Regards, Bryan Drewery --QVI5pCEJDGX5f5oENDUoUPgaXbVtOa3k2-- --VCBm04XMs2bFNKf7O3j9r20Gg0HCCuPfq 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 iQEcBAEBAgAGBQJXUHa9AAoJEDXXcbtuRpfP11YH/3JKnNRK7NOpTzL9P9DaKdQO /S/Lmxwnofdn0sI3g7j6RZEsLQM7nwg/G5yQZXJ3Jdbk57SJ5VBzNdcXLF1FdObb QsnTB/4W9OEeRIP+3xqtH67vrQ6QOiSSowU4DQCFGQkPNmlLgg1cZodVXokqvvqO CoA6MuaDbgZwRTOMBGAbHOcgvjkXEW0DzR+xxSNSlaELXCO1hA/+ste0VgbhgPDT 3yQIl9xU/8CAuFHuR5w4ojPnf66xW0A0oK1SLm/bK3+6q2wBupfdrSCQwHfPFGuu wq+34Mrn49Qx4aDX8bvwywCldK5wx2xnC2i4RtscOZQl7mEkt2Ll7PzqIwqNdCQ= =fHaC -----END PGP SIGNATURE----- --VCBm04XMs2bFNKf7O3j9r20Gg0HCCuPfq-- From owner-freebsd-current@freebsd.org Thu Jun 2 18:27: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 820D5B65EFC for ; Thu, 2 Jun 2016 18:27:40 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3EE4911E1 for ; Thu, 2 Jun 2016 18:27:40 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: by mail-wm0-x229.google.com with SMTP id a136so242877741wme.0 for ; Thu, 02 Jun 2016 11:27:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bris-ac-uk.20150623.gappssmtp.com; s=20150623; h=date:from:message-id:to:subject:reply-to; bh=+tRWiZ04jS8MfPFi2Yu7D9Kvb6lNkMeZAhDvTbjPGFs=; b=1CFzdr7JkyDRvcfqgNWInplnQ7gHQ5+p16hFbgBByivl+fSoSInvgoSGTc/7qSFMOK 0FqwadFFMguu6OHBplzIgDO1MG9LxDa0V2P5n6kq9Wwha/SxnHElEftcjTnUBj7XqNIH vkRDK/0ZerZ3c6XJlxUcYOvfF26ZNwSIhjuX+PQdGQEBOkP3ciJq0v9/7VZAbUTnLdyI 7WHo3oRmnHuctGq4HFvXfkCYe1cErdKugLslA8GUCU4+YV5AMqw9mAtM1xoYZA1nts/9 m+ZwgADWujgqn5RwVSPK+37xC+T5mObVMV48TpISjC0r+oOy7i9pDIn2H/AW5uluM6yF I2fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:reply-to; bh=+tRWiZ04jS8MfPFi2Yu7D9Kvb6lNkMeZAhDvTbjPGFs=; b=kM1lt946u1IPB6e/AtzHf3Bfoy6kOKmvgjAyY2e/SwzEiCJXBGLNfZGkYqc7oujENN Z6zPwx9iW4EGb35Il7uIpwdHvFhYm1znuJLiQU9EMClTPWhf+AUaBTCX9O957sxZ6H8K Wau/9zgQUTmIlXpeMWui8688fBehI45bbH+r1W6OCWRprw8Lr2uIkGIPAuAf0tL61/AJ SWj72KFVoxQG9UD+xBoN67haUISmy97qFxqhiArK/YzlrbLTh/WRnhpBwyTtaH8RigJ9 AEIanhLbgMJvP4zC6KjDJYopEV7MJzaWmHeD53FJyW2evcd3+yoDjC+r/TKiSWLwGRJO Cjxw== X-Gm-Message-State: ALyK8tLSOC2y4FdCV4tAegIHt35d97rAiTGiuZG8dlzI3TmZgHW3gicEXN6/rsYRtMabcnDT X-Received: by 10.28.88.206 with SMTP id m197mr125533wmb.43.1464892058317; Thu, 02 Jun 2016 11:27:38 -0700 (PDT) Received: from mech-as222.men.bris.ac.uk (mech-as222.men.bris.ac.uk. [137.222.170.4]) by smtp.gmail.com with ESMTPSA id e1sm1828313wjv.9.2016.06.02.11.27.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Jun 2016 11:27:37 -0700 (PDT) Received: from mech-as222.men.bris.ac.uk (localhost [127.0.0.1]) by mech-as222.men.bris.ac.uk (8.15.2/8.15.2) with ESMTP id u52IRbPe002847 for ; Thu, 2 Jun 2016 19:27:37 +0100 (BST) (envelope-from mexas@mech-as222.men.bris.ac.uk) Received: (from mexas@localhost) by mech-as222.men.bris.ac.uk (8.15.2/8.15.2/Submit) id u52IRaOj002846 for freebsd-current@freebsd.org; Thu, 2 Jun 2016 19:27:36 +0100 (BST) (envelope-from mexas) Date: Thu, 2 Jun 2016 19:27:36 +0100 (BST) From: Anton Shterenlikht Message-Id: <201606021827.u52IRaOj002846@mech-as222.men.bris.ac.uk> To: freebsd-current@freebsd.org Subject: Thank you for iwm(4)! Reply-To: mexas@bris.ac.uk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 18:27:40 -0000 Found out only today that Intel Wireless 7260 is supported in -current. Rui, Adrian, (and others?) - many thanks for this. Anton From owner-freebsd-current@freebsd.org Thu Jun 2 18:52: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 563A6B657ED for ; Thu, 2 Jun 2016 18:52:33 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-182.reflexion.net [208.70.211.182]) (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 038631C9F for ; Thu, 2 Jun 2016 18:52:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17117 invoked from network); 2 Jun 2016 18:53:01 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 2 Jun 2016 18:53:01 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Thu, 02 Jun 2016 14:52:27 -0400 (EDT) Received: (qmail 10423 invoked from network); 2 Jun 2016 18:52:27 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 2 Jun 2016 18:52:27 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 93F3F1C43F7; Thu, 2 Jun 2016 11:52:26 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: 11.0 -r301139: WITH_META_MODE=yes vs. "sh: ./make_keys: Exec format error"? From: Mark Millard In-Reply-To: <92116.1464890038@kaos.jnpr.net> Date: Thu, 2 Jun 2016 11:52:29 -0700 Cc: Bryan Drewery , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <12D1F020-F1F1-464A-BAEA-18682E1ADA17@dsl-only.net> References: <890D3808-1939-4BEA-886F-324EBA8C8671@dsl-only.net> <92116.1464890038@kaos.jnpr.net> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 18:52:33 -0000 On 2016-Jun-2, at 10:35 AM, Simon J. Gerraty wrote: > Mark Millard wrote: >=20 >>>>>> Building = /usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncursesw/make_keys >>>>>> sh: ./make_keys: Exec format error >=20 > This is an arm host or cross-building? >=20 > The error suggests HOST_CC got the wrong value. > You should be able to look at >=20 > /usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncursesw/make_keys.meta >=20 > to confirm whether the right toolchain was used. Quoting what I originally wrote that has been dropped from the context = preserved in the recent list entries: > [The example context here for extracted materials is a amd64 -> armv6 = cross build.] On 2016-Jun-2, at 10:53 AM, Simon J. Gerraty wrote: > BTW Mark, thanks very much for testing this. >=20 >>> # grep make_keys = ~/sys_typescripts/typescript_make_rpi2_nodebug_clang_bootstrap-amd64-host-= 2016-06-01:15:17:28 >>> Building = /usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncursesw/make_keys >>> Building = /usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncurses/make_keys >>> Building = /usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncursesw/make_keys >>> sh: ./make_keys: Exec format error >>=20 >> Note that ncursesw has two Building lines above with the same path = listed. >=20 > This build is still using the normal orchestration (tree walks etc) > so it it not at all out of the question for directories to be visited > more than once. >=20 > If curious; you can add -dM to have make explain why it built it again > the 2nd time. > The output can be copious, so you might want to only enable it in > ncursesw > eg. >=20 > .MAKEFLAGS: -dM You dropped the note where Bryan Drewery reported already having found = the problem: On 2016-Jun-1, at 5:06 PM, Bryan Drewery = wrote: > Yup it is due to r301079. Will have to think on this. It was a = temporary > workaround until bmake was fixed. >=20 >=20 > --=20 > Regards, > Bryan Drewery There is also the issue that installworld to / and reboot results in the = next buildworld buildkernel for each TARGET_ARCH being essentially a = complete build. ( = https://lists.freebsd.org/pipermail/freebsd-current/2016-June/061606.html = ) For my use this last usually removes the most of the potential time gain = from WITH_META_MODE=3Dyes. And taking less time is why I was = experimenting with using it. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Thu Jun 2 19:36: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 74733B65BC6; Thu, 2 Jun 2016 19:36:09 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 592F612ED; Thu, 2 Jun 2016 19:36:09 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 4FE931619; Thu, 2 Jun 2016 19:36:09 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 0CC78DE5F; Thu, 2 Jun 2016 19:36:09 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id lqTVWh6HVVVQ; Thu, 2 Jun 2016 19:36:05 +0000 (UTC) Subject: Re: [CFT] WITH_META_MODE: Working incremental build [only on i386 and amd64] [filemon fails to load on powerpc64] DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 586E6DE59 To: Mark Millard References: <7748cc71-3788-22ae-fcb2-699eae529310@FreeBSD.org> <9A1A624D-9286-4C0F-A435-D590E07C1149@dsl-only.net> Cc: FreeBSD Current , FreeBSD PowerPC ML , freebsd-arm From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <39d3c132-cdac-8c9a-c580-82d18f071699@FreeBSD.org> Date: Thu, 2 Jun 2016 12:36:09 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <9A1A624D-9286-4C0F-A435-D590E07C1149@dsl-only.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wESkdwXxBQOxrd68BvXDLfCNJwVA0w0tp" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 19:36:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wESkdwXxBQOxrd68BvXDLfCNJwVA0w0tp Content-Type: multipart/mixed; boundary="eiPTIrTKS0FSc8CHtSXKThejDUR84vf9N" From: Bryan Drewery To: Mark Millard Cc: FreeBSD Current , FreeBSD PowerPC ML , freebsd-arm Message-ID: <39d3c132-cdac-8c9a-c580-82d18f071699@FreeBSD.org> Subject: Re: [CFT] WITH_META_MODE: Working incremental build [only on i386 and amd64] [filemon fails to load on powerpc64] References: <7748cc71-3788-22ae-fcb2-699eae529310@FreeBSD.org> <9A1A624D-9286-4C0F-A435-D590E07C1149@dsl-only.net> In-Reply-To: <9A1A624D-9286-4C0F-A435-D590E07C1149@dsl-only.net> --eiPTIrTKS0FSc8CHtSXKThejDUR84vf9N Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 6/1/2016 6:39 PM, Mark Millard wrote: > while filemon.ko now exists: >> # ls -l /boot/*/filemon* >> -r-xr-xr-x 1 root wheel 32064 Jun 1 17:59 /boot/kernel/filemon.ko > it does not load: >> # kldload -n filemon >> kldload: can't load filemon: No such file or directory >> # dmesg | grep link_elf >> link_elf: symbol elf64_freebsd_sysvec undefined > So no WITH_META_MODE=3Dyes yet for powerpc64. Please try this patch: http://dpaste.com/37VP5MD.txt And once you have filemon loaded please run this basic test script. It should return no output and a zero exit status. http://dpaste.com/23NTA0A.txt Just sh file it. --=20 Regards, Bryan Drewery --eiPTIrTKS0FSc8CHtSXKThejDUR84vf9N-- --wESkdwXxBQOxrd68BvXDLfCNJwVA0w0tp 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 iQEcBAEBAgAGBQJXUIqpAAoJEDXXcbtuRpfPqn8H/jYg89tMm/dWB0F8yets4Nov tAeXtyEDUGioAK0augp20HEQLKsP6qGzS9JDQjQjrc3OzQCm/LirdYMW3hRfI4/J 3A+GMa+4jvNwvmx7o5LSsoxbelKrlrYeudPCT45AIdY/0J39vrdI5jtN2XfOVCSI Ityw1x6SQsNaqRzr4vSXK0mW4nvcqEWcryxQ+D41yl7Lalmqi4v9/MptEq6XFwQ2 Z5myAkMFHLQt5grk/CJcp2ZbGFxw/r21lEyKq6kY7b6mu8V+o51AEqmIvz4qZHjN UG5PzmUEPBIiuI6wNTIL8IH+I9ITNsJCMZR8LCThowmd5jGmrSwh/nWBtCq0lfQ= =QtNb -----END PGP SIGNATURE----- --wESkdwXxBQOxrd68BvXDLfCNJwVA0w0tp-- From owner-freebsd-current@freebsd.org Thu Jun 2 19:58: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 38740B6647B for ; Thu, 2 Jun 2016 19:58:56 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 1F88816A6; Thu, 2 Jun 2016 19:58:56 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 187031F09; Thu, 2 Jun 2016 19:58:56 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id C07EADF4F; Thu, 2 Jun 2016 19:58:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id 7fOozdSaCjI0; Thu, 2 Jun 2016 19:58:53 +0000 (UTC) Subject: Re: 11.0 -r301139: WITH_META_MODE=yes vs. "sh: ./make_keys: Exec format error"? DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 129D0DF49 To: Mark Millard , "Simon J. Gerraty" References: <890D3808-1939-4BEA-886F-324EBA8C8671@dsl-only.net> <92116.1464890038@kaos.jnpr.net> <12D1F020-F1F1-464A-BAEA-18682E1ADA17@dsl-only.net> Cc: FreeBSD Current From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <92ec1878-c83b-5771-f9f7-52d3235a7330@FreeBSD.org> Date: Thu, 2 Jun 2016 12:58:57 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <12D1F020-F1F1-464A-BAEA-18682E1ADA17@dsl-only.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GN70LupbHPvVnBKUpkB4nxfk7iH7dItll" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 19:58:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GN70LupbHPvVnBKUpkB4nxfk7iH7dItll Content-Type: multipart/mixed; boundary="idLKpoJKcSedu1bRCfpmvJC1ikDxJrfXr" From: Bryan Drewery To: Mark Millard , "Simon J. Gerraty" Cc: FreeBSD Current Message-ID: <92ec1878-c83b-5771-f9f7-52d3235a7330@FreeBSD.org> Subject: Re: 11.0 -r301139: WITH_META_MODE=yes vs. "sh: ./make_keys: Exec format error"? References: <890D3808-1939-4BEA-886F-324EBA8C8671@dsl-only.net> <92116.1464890038@kaos.jnpr.net> <12D1F020-F1F1-464A-BAEA-18682E1ADA17@dsl-only.net> In-Reply-To: <12D1F020-F1F1-464A-BAEA-18682E1ADA17@dsl-only.net> --idLKpoJKcSedu1bRCfpmvJC1ikDxJrfXr Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 6/2/2016 11:52 AM, Mark Millard wrote: > There is also the issue that installworld to / and reboot results in th= e next buildworld buildkernel for each TARGET_ARCH being essentially a co= mplete build. ( https://lists.freebsd.org/pipermail/freebsd-current/2016-= June/061606.html ) >=20 > For my use this last usually removes the most of the potential time gai= n from WITH_META_MODE=3Dyes. And taking less time is why I was experiment= ing with using it. Yup. Covered in another sub-thread on the topic. I'm testing a patch to mitigate the problem. --=20 Regards, Bryan Drewery --idLKpoJKcSedu1bRCfpmvJC1ikDxJrfXr-- --GN70LupbHPvVnBKUpkB4nxfk7iH7dItll 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 iQEcBAEBAgAGBQJXUJABAAoJEDXXcbtuRpfP2dsH/2irfRUDUVoJ1/WrH1PjMlc2 1qMEo5DSkst3mxAOUnTrY78jqNioT7MPiWVd9+UvgbT0zeT2IoyzR5ALrBIxAHQJ OW6aSL1E5jL8tm6qxlNxVfGbXRfgO0ADj9jIIyCeJLrgFdbprsc5ijENQwX3z8Ly csHpN94vMeauhjLDHCZMmBInRDqeCEc/V+fvHgMkJOtCcslHSCNKVERewswck/Rs OCf8ar0UOIkuXMIz4LmTXe7Ue8FZAmtSd2GwS5RhWD39gddyVFVla9J+EU3vXS2b vEGILceUEFg5aOGHAyqop5itYdkkFxmQRXbBnBZuKbi2IM4kqGmfUwkFpKO65zA= =JqAe -----END PGP SIGNATURE----- --GN70LupbHPvVnBKUpkB4nxfk7iH7dItll-- From owner-freebsd-current@freebsd.org Thu Jun 2 20:15: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 D58B0B66B00 for ; Thu, 2 Jun 2016 20:15:40 +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 988C111CF for ; Thu, 2 Jun 2016 20:15:40 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1b8Z1f-000jXA-MH>; Thu, 02 Jun 2016 22:15:31 +0200 Received: from x5ce13ce8.dyn.telefonica.de ([92.225.60.232] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1b8Z1f-001kgh-BY>; Thu, 02 Jun 2016 22:15:31 +0200 Date: Thu, 2 Jun 2016 22:15:30 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: r301227: buildkernel fails in ibcore: error: too few arguments to function call, expected 7, have 6 Message-ID: <20160602221530.220cc8a2.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/WKjDQmDV5I67ceD.tRsPTt5"; protocol="application/pgp-signature" X-Originating-IP: 92.225.60.232 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 20:15:40 -0000 --Sig_/WKjDQmDV5I67ceD.tRsPTt5 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I receive this error while building a new kernel: [...] =3D=3D=3D> ibcore (all) cc -O2 -pipe -O3 -O3 -pipe -DINET6 -DINET -march=3Dnative -fno-strict-ali= asing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/usr/src/sys/modules/ibcore/../../ofed/drivers/infiniband/core -I/usr/src/sys/modules/ibcore/../../ofed/include -I/usr/src/sys/modules/ibcore/../../compat/linuxkpi/common/include -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GATE/opt_global.= h -I. -I/usr/src/sys -fno-common -fno-omit-frame-pointer -mno-omit-leaf-frame-po= inter -I/usr/obj/usr/src/sys/GATE -MD -MF.depend.addr.o -MTaddr.o -mcmodel=3Dke= rnel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tabl= es -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls -Wnested-e= xterns -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-q= ual -Wundef -Wno-pointer-sign -D__printf__=3D__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-co= mpare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-fu= nction -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=3Diso9899:1999 -Wno-cast-qual -Wno-pointer-arith -c /usr/src/sys/modules/ibcore/../../ofed/drivers/infiniband/core/addr.c -o addr.o /usr/src/sys/modules/ibcore/../../ofed/drivers/infiniband/core/addr.= c:398:51: error: too few arguments to function call, expected 7, have 6 is_gw ? rte->= rt_gateway : dst_in, edst, NULL); ^ /usr/src/sys/netinet/if_ether.h:121:1: note: 'arpres= olve' declared here int arpresolve(struct ifnet *ifp, int is_gw, struct mbuf *m, ^ /usr/src/sys/modules/ibcore/../../ofed/drivers/infiniband/core/addr.c:404= :51: error: too few arguments to function call, expected 7, have 6 is_gw ? rte->rt_gate= way : dst_in, edst, NULL); ^ /usr/src/sys/netinet6/nd6.h:430:1: note: 'nd6_resolve' decla= red here int nd6_resolve(struct ifnet *, int, struct mbuf *, ^ 2 errors generated. *** E= rror code 1 Stop. make[4]: stopped in /usr/src/sys/modules/ibcore --Sig_/WKjDQmDV5I67ceD.tRsPTt5 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXUJPiAAoJEOgBcD7A/5N81LoH+wXJ6wTqbx03y4GNn8iJ+WCc WtH5FyfgjTKCNeaDXp4gSf5Rs5baDalRr/KI7S8ZysGwoPVKU3Y7JKR+Y2HoEEDO lrA7wDKq2336Stafk8ebvoNdvESP8KS8HQIGv7Grqx5gvWNK+6QqE4O2LGIBfvi4 VUbiyJ8nmr+PsLER9ovePs60WooMRP1f4uB32psOmQIVMG9Em1zARAltU3AEy5JC AUAygYuYj0H6E81cYMmMWHXQC6Egx0TxIiGRQSn3azFTGiuds9cSFleaZsV7eLiM vKVvG4x7iia3F3kcx2tkMLUp6qW/Vtoy8hL0UVYTFX8psemIrFrkypWOxfWzfFY= =rsuo -----END PGP SIGNATURE----- --Sig_/WKjDQmDV5I67ceD.tRsPTt5-- From owner-freebsd-current@freebsd.org Thu Jun 2 20:21: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 C43D3B66DB2 for ; Thu, 2 Jun 2016 20:21:50 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 825B9182C; Thu, 2 Jun 2016 20:21:50 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-qk0-x22c.google.com with SMTP id i187so38822606qkd.3; Thu, 02 Jun 2016 13:21:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=ywxej56t6ORDpd4PoyMZj3NSWPcojLSa2U661vy9fwQ=; b=WL+Q4eY9O1WbFM+pZKHdyYFmpKYSwP21mU0CAMAAsv74vL9BGEWE3nBBjR6PXEfF60 sZZbIV+30FanZ4cUXLsdQWhHS7vp57edoMmsEKM0mPmhvwaM1LsgYbdb7Wm/3XYMgJKt sf31XxwcrNkW3J7FPQhElezOvn2JUPw4L9Lg1rnFt9SPJzTM3FACgRCp4yjR1yjrO094 7HORRXsJDM5nZafYp+cjNPeiuFtdUD/rPq+22iiiC5BkDknsg5OEqfb20eE/ftV1qF2X cQIYfq28dlCrtmouKA+tFLayYQzCpJFU3/H0/NLlYhWsTstzUHZoOOidQd3ZR8nxAGwU F3IQ== 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; bh=ywxej56t6ORDpd4PoyMZj3NSWPcojLSa2U661vy9fwQ=; b=EXsRnhqdhJpUSEtGq266aCuxFWHpokQ53R/YJBwRE+intry5i7EXPyGdXu5ibVPPI5 Hgvx60pDjYFz/i91jx55estpH4cb8w6kzlPxXeT51y890Scno1+F82QtWfYQUxlJqEJN zk9ZHYYliStehGVCXwS0LZEwp1hJivn8OKNP0df0Xihpaos1SVF381Q5yof2E3BlLdZX hN42utgFE8dygqsJAkvYUn6DgkurmZwsnMJ2DmngqLRzQ5/3EJwpYpP0QgbGYfbtSUxN gjfo5ktX4SM7y5XScwbly0o/Z6rm5AKJx2qYAeKBNgHNiUGVYYFb5xxIdWuyT5eeCqkP HC4A== X-Gm-Message-State: ALyK8tKv0MalijNM76R5CYgxOZSiPwJmWEOQ4e8nhgcP6jIaosCc1YNo+JF1NPrJF+80Jm0qQZG79i+NU3a1hA== MIME-Version: 1.0 X-Received: by 10.55.130.1 with SMTP id e1mr18907qkd.204.1464898908849; Thu, 02 Jun 2016 13:21:48 -0700 (PDT) Received: by 10.55.146.69 with HTTP; Thu, 2 Jun 2016 13:21:48 -0700 (PDT) In-Reply-To: <20160602221530.220cc8a2.ohartman@zedat.fu-berlin.de> References: <20160602221530.220cc8a2.ohartman@zedat.fu-berlin.de> Date: Thu, 2 Jun 2016 13:21:48 -0700 Message-ID: Subject: Re: r301227: buildkernel fails in ibcore: error: too few arguments to function call, expected 7, have 6 From: Ngie Cooper To: "O. Hartmann" Cc: FreeBSD CURRENT , George Neville-Neil Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 20:21:50 -0000 On Thu, Jun 2, 2016 at 1:15 PM, O. Hartmann wrote: > > I receive this error while building a new kernel: r301217 is the culprit. I've CCed gnn@ on another thread. Thanks, -Ngie From owner-freebsd-current@freebsd.org Thu Jun 2 20:29: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 34DA9B66F79 for ; Thu, 2 Jun 2016 20:29:13 +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 EB6FC1D00; Thu, 2 Jun 2016 20:29:12 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1b8ZEt-000nEH-1V>; Thu, 02 Jun 2016 22:29:11 +0200 Received: from x5ce13ce8.dyn.telefonica.de ([92.225.60.232] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1b8ZEs-001lig-Ob>; Thu, 02 Jun 2016 22:29:10 +0200 Date: Thu, 2 Jun 2016 22:29:09 +0200 From: "O. Hartmann" To: Ngie Cooper Cc: FreeBSD CURRENT , George Neville-Neil Subject: Re: r301227: buildkernel fails in ibcore: error: too few arguments to function call, expected 7, have 6 Message-ID: <20160602222909.0c1e2c07.ohartman@zedat.fu-berlin.de> In-Reply-To: References: <20160602221530.220cc8a2.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/vSbLZ19zTUrg5y+2bA9r+sA"; protocol="application/pgp-signature" X-Originating-IP: 92.225.60.232 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 20:29:13 -0000 --Sig_/vSbLZ19zTUrg5y+2bA9r+sA Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Thu, 2 Jun 2016 13:21:48 -0700 Ngie Cooper schrieb: > On Thu, Jun 2, 2016 at 1:15 PM, O. Hartmann = wrote: > > > > I receive this error while building a new kernel: =20 >=20 > r301217 is the culprit. I've CCed gnn@ on another thread. > Thanks, > -Ngie > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" Thank you. --Sig_/vSbLZ19zTUrg5y+2bA9r+sA Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXUJcVAAoJEOgBcD7A/5N8Mz0H/ix4XZ7E8RKOrjqCK7y719JW RgXBB+++V8h1YFRbvdOcReg3x55ii2HX/qHdXyaAMIu7Yz8ozA+OLnp9NtlTwCtG A3K6wxH/jJ/XygXo8MIdgmfsNM/d8JtMIpPy3ofWawQwRxDOZpDajeofeI/IdvRp C4Rx+pv51MzdVQJE09ZsHGi36db20L7y/tp4WpdRyrKM1gNC3ldzFFs5Ry5jZRdw pM9ztq2Rmm3X08P+sJ44To5S4A87Er2Af49vHFq9Jti5AFzEGmfqNewN7DvQIkiY lx9XcIESrd6jRPEFwiA5O1CnULRxUd1LH1rqxK5RYjoznSgGyKJrX3RtxkXQN2U= =POFv -----END PGP SIGNATURE----- --Sig_/vSbLZ19zTUrg5y+2bA9r+sA-- From owner-freebsd-current@freebsd.org Thu Jun 2 20:47:05 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5A8A5B65886 for ; Thu, 2 Jun 2016 20:47:05 +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 1C1F21B16 for ; Thu, 2 Jun 2016 20:47:04 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1b8ZWA-000rau-F9>; Thu, 02 Jun 2016 22:47:02 +0200 Received: from x5ce13ce8.dyn.telefonica.de ([92.225.60.232] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1b8ZWA-001n4L-4q>; Thu, 02 Jun 2016 22:47:02 +0200 Date: Thu, 2 Jun 2016 22:46:54 +0200 From: "O. Hartmann" To: Kevin Oberman Cc: Hans Petter Selasky , RayCherng Yu , FreeBSD Current Subject: Re: Suddenly poweroff in 11-Current r300097 Message-ID: <20160602224654.18927083.ohartman@zedat.fu-berlin.de> In-Reply-To: References: <0448c751-8608-51ce-f47e-76280ebf14f2@selasky.org> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/Z5RU72DxlV4dX1TVk1zpYpZ"; protocol="application/pgp-signature" X-Originating-IP: 92.225.60.232 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 20:47:05 -0000 --Sig_/Z5RU72DxlV4dX1TVk1zpYpZ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Thu, 2 Jun 2016 10:26:22 -0700 Kevin Oberman schrieb: > On Thu, Jun 2, 2016 at 7:41 AM, Hans Petter Selasky wro= te: >=20 > > On 06/02/16 03:07, RayCherng Yu wrote: > > =20 > >> I got a suddenly poweroff in r300097 (and previous revision in April a= nd > >> May) when I built textproc/docproj. > >> My machine is Macbook Pro 13 2011 early. I have checked the Apple webs= ite. > >> My bios is the latest version. > >> Actually it also happened in 10.3-STABLE. > >> It happened when the machine load was heavy. Before it shutdown, the f= an > >> started to run very loudly. After several seconds (20 or 30 seconds), = my > >> laptop shutdown (poweroff directly) suddenly. It seems not happen with= the > >> AC power supply connected. > >> > >> I installed both Mac OSX and FreeBSD (dual boot). It never happened in= Mac > >> OSX. > >> > >> My dmesg: > >> http://pastebin.com/QjZmbGCB > >> > >> My sysctl hw.acpi: > >> > >> hw.acpi.acline: 0 > >> hw.acpi.battery.info_expire: 5 > >> hw.acpi.battery.units: 1 > >> hw.acpi.battery.state: 1 > >> hw.acpi.battery.time: 87 > >> hw.acpi.battery.life: 59 > >> hw.acpi.cpu.cx_lowest: C8 > >> hw.acpi.reset_video: 0 > >> hw.acpi.handle_reboot: 1 > >> hw.acpi.disable_on_reboot: 0 > >> hw.acpi.verbose: 0 > >> hw.acpi.s4bios: 0 > >> hw.acpi.sleep_delay: 1 > >> hw.acpi.suspend_state: S3 > >> hw.acpi.standby_state: NONE > >> hw.acpi.lid_switch_state: NONE > >> hw.acpi.sleep_button_state: S3 > >> hw.acpi.power_button_state: S5 > >> hw.acpi.supported_sleep_state: S3 S4 S5 > >> > >> =20 > > Hi, > > > > Do you have a temperature sysctl? Usually FreeBSD will shutdown the sys= tem > > if the ACPI temperature exceeds some value. Maybe it would be better to > > reduce the CPU load when the temperature goes up instead of facing a > > shutdown? > > > > --HPS =20 >=20 >=20 > The relevant information is probably found in dev.cpu. That is where all > temperature information is located as it is per-CPU, not per-system. Of > particular interest is dev.cpu.0.cx_lowest, dev.cpu.0.cx_supported, and > dev.cpu.0.freq_levels. A snapshot of dev.cpu.0 when the fan has cranked u= p, > but before shutdown would be nice, too. >=20 > I see no hw.acpi.thermal information. This is very odd. These values > indicate what the system will do and is doing if it starts getting too ho= t. >=20 > Is coretemp loaded? It is required to see the core temperatures and those > are almost certainly significant. It may account for the lack of thermal > information. Finally, a dmesg might be useful as it will tell us more abo= ut > just what thermal control techniques are enabled. >=20 > Just to explain a bit on how this should work: when the temperature excee= ds > some BIOS defined point, the system should "throttle" by pausing one of > every 8 clock cycles. If that does not fix the problem, the it rests for > two of every 8 and so on until the temperature is reduced. If it continues > to rise and reaches another BIOS set point, it will initiate an emergency > shutdown. If it reaches a CPU defined temperature, the power will shut off > immediately. Note that this is entirely a hardware function with no BIOS = or > OS involvement. It should NEVER happen in normal operation as it is > triggered by a significant overtemp that threatens to destroy the CPU. I'= ve > only seen it once when the CPU heat sink came loose on an old P4 system > several years ago. >=20 > I should mention that I have zero experience with Apple hardware and it is > possible that they do some things differently than I have seen on other > hardware. > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkoberman@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 I have had such problems many times with older hardware. In most cases "dr= ied out" thermal conductive pad or grease was the reason overheating the CPU du to = a ineffective thermal conductivity from the CPU's surface to the heat spreader/cooler. I = had recently two laptops with such a phenomenon - using high-quality thermal grease solv= ed the problem for my. In both cases, the former high-viscous thermal grease has become li= ke dry mud. Same with pads.=20 --Sig_/Z5RU72DxlV4dX1TVk1zpYpZ Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXUJs+AAoJEOgBcD7A/5N8+pEH/0wkm1TNTzUuKOlZbFDDk1wS x0RaooNUiLXwvV1xtV5WG340UReIhOPyyQTekmAa3MpaJjKTtuw6gLuEsbavgC4i tnSxTLou/zk0f0YKXmABU/Smd6dZOeWaPtKvkuOfx/qlQn/AEDYizDS6+Bp4GBmH rfmAmzKQptRDL+ick4Cy2FiGWUleItn1hIdkhTM90TfOZbk/vavPE9FA3PPzNetf sTGsGnehflPI9uzWj3tBwmnTiyx3LLERlnTgSDjdrpHGDDSfx70KVC5EnZG+QQWg jyLc2NTIKtsphmWNTAB9SGoA75giPTmYR+2F99m1oHgz4hYPfMfo+GRsa/iNL6M= =lbfw -----END PGP SIGNATURE----- --Sig_/Z5RU72DxlV4dX1TVk1zpYpZ-- From owner-freebsd-current@freebsd.org Thu Jun 2 21:49: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 75C1CB67D24 for ; Thu, 2 Jun 2016 21:49:53 +0000 (UTC) (envelope-from oleglelchuk@gmail.com) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0478A1F72 for ; Thu, 2 Jun 2016 21:49:53 +0000 (UTC) (envelope-from oleglelchuk@gmail.com) Received: by mail-wm0-x22c.google.com with SMTP id z87so85820760wmh.0 for ; Thu, 02 Jun 2016 14:49:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=W+grqkRop3rXG5mUNO7JAfQjxVTNBtgDEdEYrrsb39A=; b=XL/wykm5cVGDusOQrlZd/j64hokPxCh6k30sbCd5ZMBFiyqziW7czm6UWb0EWU3gl5 WZjZB5K1zYRRAkzqPoTSefIygO+6+F6l4iqalWNN9pDblFj0yyA7LXwwAL52gQwVjvSj bi2rDr4ecLl/LDPWh5ZFuVWBTr6btbljeFV0Vc4HkN6VoilLN+XYRE6haWqfVRNjckgU 6fNlL8qYLLfoJIvRjacsEP9xHqq4wftLgiEPvbAE7pH19pCuxebFMFU5btZTkgfbj+pn 6x01Lynx/3Ee0ypol/qtgTGABFh66hrf1A1gpStTrewowNjlqtPacyAbNPzPx6/ff1Go gSQw== 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; bh=W+grqkRop3rXG5mUNO7JAfQjxVTNBtgDEdEYrrsb39A=; b=IDAKD1M2tHEWueATqJWHQsqIQZmZpvEKMlHOUJV/ql5a42Hlf5cNty51unqx8MRH5i Ex+EyCfwQ3GHXeawhGnPE+h7eP2t7yUe6520eNF18vGDIDG+wHErd2awJzG+Qv82/KiB ss4GAhP8MTlJvFAoDuI6tsieIAAjYw0bJshl0wu1Ek2tsz6FpWmgrAE/xvMKN2Xin96e eq1g9b0W7uAxgFw2LeLFzi8kyqlsucZpErWKqOglGPtvdArj+5m/yCFjCQWwqGV10ti+ 506MUdETRvFAqP19gLWys0+nCtl1Rt9j5LX3hyYnMFbAKGUQj92IfMOHBPHPXLWE0Fly LshA== X-Gm-Message-State: ALyK8tJaVp0qWDD/B98MDWY/A024kwyHEw3ylHofEH+FflIamhTsGqYCAtsqdpK3uRjPwmRtfhPlpsIK9OfaNA== MIME-Version: 1.0 X-Received: by 10.28.165.66 with SMTP id o63mr777128wme.102.1464904191481; Thu, 02 Jun 2016 14:49:51 -0700 (PDT) Received: by 10.194.174.230 with HTTP; Thu, 2 Jun 2016 14:49:51 -0700 (PDT) In-Reply-To: <0ae227ae-0154-cc15-eb64-17984ae2012a@freebsd.org> References: <0ae227ae-0154-cc15-eb64-17984ae2012a@freebsd.org> Date: Thu, 2 Jun 2016 17:49:51 -0400 Message-ID: Subject: Re: Streaming live tv over the udp protocol causes problems From: Oleg Lelchuk To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 21:49:53 -0000 I am a bit confused about this server/client thing. My networked tv tuner Hdhomerun has a wired connection to my router. It has a program called hdhomerun_config_gui. I open the program, choose a tv channel that I want to watch, then vlc opens, but the video that starts streaming is broken. Vlc shows me the message that the stream comes from udp://127.0.0.1:5000 . So, in this particular case, the tv tuner is the server and my computer is the client? If my computer is the client, then this is the output I get from "iperf -f m -i 1 -s -u": Server listening on UDP port 5001 Receiving 1470 byte datagrams UDP buffer size: 0.04 MByte (default) As I said earlier, I had no problems streaming live tv on 10.3-STABLE. On Thu, Jun 2, 2016 at 1:35 PM, Allan Jude wrote: > On 2016-06-01 23:03, Oleg Lelchuk wrote: > > Hi. On 11-ALPHA1, when I use vlc to stream live tv over the udp > protocol, I > > see a garbled and choppy video. This issue doesn't occur on 10.3-STABLE. > I > > am puzzled as to the cause of this problem. > > _______________________________________________ > > 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" > > > > Are both machines FreeBSD? > > Can you try running iperf in udp mode, something like this: > > pkg install iperf > > client: iperf -f m -i 1 -s -u > server: iperf -f m -i 1 -t 20 -c -u -b 100m > > And give us the results > > -- > Allan Jude > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Thu Jun 2 22:05:57 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D6F0BB68027; Thu, 2 Jun 2016 22:05:57 +0000 (UTC) (envelope-from mikej@mikej.com) Received: from mx2.paymentallianceintl.com (mx2.paymentallianceintl.com [216.26.158.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx2.paymentallianceintl.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 883F517C7; Thu, 2 Jun 2016 22:05:57 +0000 (UTC) (envelope-from mikej@mikej.com) Received: from firewall.mikej.com (f [162.230.214.65]) by mx2.paymentallianceintl.com (8.15.1/8.15.1) with ESMTPS id u52M5nSd004871 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 2 Jun 2016 18:05:50 -0400 (EDT) (envelope-from mikej@mikej.com) X-Authentication-Warning: mx2.paymentallianceintl.com: Host f [162.230.214.65] claimed to be firewall.mikej.com Received: from mail.mikej.com (firewall.mikej.com [192.168.6.63]) by firewall.mikej.com (8.15.2/8.15.2) with ESMTP id u52M5lRB031095; Thu, 2 Jun 2016 18:05:48 -0400 (EDT) (envelope-from mikej@mikej.com) DMARC-Filter: OpenDMARC Filter v1.3.1 firewall.mikej.com u52M5lRB031095 Authentication-Results: mail.mikej.com; dmarc=none header.from=mikej.com DKIM-Filter: OpenDKIM Filter v2.10.3 firewall.mikej.com u52M5lRB031095 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mikej.com; s=mail; t=1464905148; bh=cB0V0jO/CcrcYqRoVzFnwKnXu+cwo8IbEbKAwhiYgkc=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=j93oITnwO7gRUeR9vfzSTn6N4q0gEmlSECpKK0c4uwnAv0UzSPZ4Nlwa0OojCwXPi Y5Iir3BtgytuqDKGRuUoAkaOH42L7zNIkUTHO9m90R6K0rE+rT97aO6kyiwElN59/o xJX+l8pYs2Iln03QDDqawOD1cwVdAA7U+6Dc0Pew32cwHtqgv4RkiKSy0TNK2eMv1H jD0ofQRrJ78IlWtrDGiEC392PEW6yQ+09/RrLtlr6NCIHlslf3V38mj8A6DLUQ8dg5 QZNLd+ntj96wyZ5oQ3ONH857bQ42BXQw8VO68mx44tgOn2CUQ/QKy9g0lTfOFE7CIm mHgksxT7PRC6w== X-Authentication-Warning: firewall.mikej.com: Host firewall.mikej.com [192.168.6.63] claimed to be mail.mikej.com MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 02 Jun 2016 18:05:47 -0400 From: Michael Jung To: freebsd-current@freebsd.org Cc: owner-freebsd-current@freebsd.org Subject: Re: head r30140 - Panic String: _mtx_lock_sleep: recursed on non-recursive mutex vm page @ /usr/src/sys/vm/vm_page.c:774 In-Reply-To: <96b9a1271d057fb8b67696623a6263c5@mail.mikej.com> References: <96b9a1271d057fb8b67696623a6263c5@mail.mikej.com> Message-ID: <1827e9575941cf7c4bc82828ad00f431@mail.mikej.com> X-Sender: mikej@mikej.com User-Agent: Roundcube Webmail/1.1.5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 22:05:57 -0000 On 2016-06-01 12:37, Michael Jung wrote: > Since upgrading to head r301040 I have started to get the above panic > while running > poudriere while building packages for 10.3-STABLE r301107. > > Unfortuately I can't tell you the previous version of head but it was > from some > months ago. > > > https://charon.gopai.com/core.txt.7 > > https://charon.gopai.com/info.7 > > I also have the full core file if needed. > > Let me know what else I can provide. > > Thank you. > _______________________________________________ > 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" Ideas? - there was another report of the same panic in vm_page.c http://postimg.org/image/r78vxopkb/ I see from the web log 20+ people have looked at the core file.... I can bump my build server but I was awaiting a response to the panic before doing that. Thanks all. --mikej From owner-freebsd-current@freebsd.org Thu Jun 2 22:17: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 5416BB68340 for ; Thu, 2 Jun 2016 22:17:22 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::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 10D2E1E15; Thu, 2 Jun 2016 22:17:22 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-qg0-x236.google.com with SMTP id p34so3593045qgp.1; Thu, 02 Jun 2016 15:17:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=PFiNEGG1D8hVJV68fXzTCumxzwFX/PqjSDV+B++E8xc=; b=UA1ImXAPlQ4DaVE4dHylYSDpdYOn256RdJW71csWRlL4mwxsrFz7UO54D62l2+yU2A 3mqPxWgmmq7Yakxuf9cy4o9cpE5R1r0apZ7+wuhG2oJNYpBm/ewpMbzOFm1E3j/KGdNK hZRbYmmGsA/HlxVZ8T4HSc6+ysoq5U+phNX0K/YrU8uLT4cDNZDnW85kfET1suz74tER ms3aKYNfKtZIGEVYkDXGd9f1z+DpBl7q3itHQA2hUNyy+TqJDmOcLfUt5wBbklCOLOoj 7B2ArTasqT70fdzgo6l5KXMDAPJziWH6JNHFUS5RsECi0Xt3APZnGdlhizuZf8bveViZ z3Fw== 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; bh=PFiNEGG1D8hVJV68fXzTCumxzwFX/PqjSDV+B++E8xc=; b=Yg//8WM2t/N1CwAynIfLcpG1fGDRkpCqr5kHDWpfCSFTGGWnEVigODmNjIF7BEN4vb FkT7GQhrl3saBsdqxaLcIod6cjk0LUY0vDJdsKN8W6845pjx3RfL7ryP8q6xHrx/w70h +cF9N9himzwwdnYl17JYPOatx9iCD81WdtlLX2nki5WYwMCC2NQogn3qWiv78OCsqxks 3vOwAedg28Imq3BuMeepbvi5VniixEGEyiG5LJl7UjpKOuhVlOg6NWQ5GWFQzhWl2bhC yIz8RqiPRJzdfuJMJlVEeLormUYQxY0o13nBFUmi6ihehASiymRTk6T8HVszbxv+KBX8 SL6g== X-Gm-Message-State: ALyK8tIkGG8pFB05w/viUh7vGsLMFOQjLOyZTpU+S8DHuni3i+nMIx9g86O3aJQO5/LvHqjeYGmT7Aqdi+9Ppw== MIME-Version: 1.0 X-Received: by 10.140.20.162 with SMTP id 31mr442014qgj.106.1464905841155; Thu, 02 Jun 2016 15:17:21 -0700 (PDT) Received: by 10.55.146.69 with HTTP; Thu, 2 Jun 2016 15:17:21 -0700 (PDT) In-Reply-To: <1827e9575941cf7c4bc82828ad00f431@mail.mikej.com> References: <96b9a1271d057fb8b67696623a6263c5@mail.mikej.com> <1827e9575941cf7c4bc82828ad00f431@mail.mikej.com> Date: Thu, 2 Jun 2016 15:17:21 -0700 Message-ID: Subject: Re: head r30140 - Panic String: _mtx_lock_sleep: recursed on non-recursive mutex vm page @ /usr/src/sys/vm/vm_page.c:774 From: Ngie Cooper To: Michael Jung Cc: FreeBSD Current , "kib@FreeBSD.org" , Mark Johnston Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 22:17:22 -0000 On Thu, Jun 2, 2016 at 3:05 PM, Michael Jung wrote: > On 2016-06-01 12:37, Michael Jung wrote: >> >> Since upgrading to head r301040 I have started to get the above panic >> while running >> poudriere while building packages for 10.3-STABLE r301107. >> >> Unfortuately I can't tell you the previous version of head but it was from >> some >> months ago. >> >> >> https://charon.gopai.com/core.txt.7 >> >> https://charon.gopai.com/info.7 >> >> I also have the full core file if needed. >> >> Let me know what else I can provide. >> >> Thank you. > > Ideas? - there was another report of the same panic in vm_page.c > > http://postimg.org/image/r78vxopkb/ > > I see from the web log 20+ people have looked at the core file.... > > I can bump my build server but I was awaiting a response to the panic > before doing that. It might have been fixed by r301212. CCing Kostik/Mark. Thanks! -Ngie From owner-freebsd-current@freebsd.org Thu Jun 2 22:21:07 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5119BB6848C for ; Thu, 2 Jun 2016 22:21:07 +0000 (UTC) (envelope-from markjdb@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 210601FEC; Thu, 2 Jun 2016 22:21:07 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pf0-x236.google.com with SMTP id f144so36163046pfa.3; Thu, 02 Jun 2016 15:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=n8LUFm74PARPV7tNhDU1631uw5qTq7CAzAabPnnCAMs=; b=PV0nljg9mnmUzUBVaGj2ek3iwqwr5ulDrA/U9fWvxh3fjhsNNknU1pNE5rfc5r4yjA 9q/8scX28YuY+ny4+cRiiClgj5D4MGqBtPcKpZlIjgT044uD2P0bUsrfVc8B0WYGVJA3 4FTm2UM0PSswZeyfX3OJ4mBG3KnWzcrJvOLiiq5f+7Fp1b7VhG002yycMHp9VXsSZCGZ zmVRLI4wgBaDia1xFWv0TPz+S10Up3QRuLAGITY3GVFTR3oaAZLefSUJi1BBLLKKqn6e lgcGk5SE/QR6PhBLmnFUCB5l3075GIXVzVT3r8yRjg2fSGnFMJmZ09exGAIc/uNbM41l NN8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=n8LUFm74PARPV7tNhDU1631uw5qTq7CAzAabPnnCAMs=; b=LNsWgraoYO2PBCRyPOlSZKtAgSXfMDiZo4iWnyh30thxHXB/u0PPXtYNBMTF7QMY+L eb/z4gnnQLF6grqp3C8xIYub4jWAUscitiJNqmlRjV8W4PzzSXHS/KPAM2QUZBfPOe+5 5f7uom4Gq6vNtIsDl6n4Wm2lNm/oDDJYgv3XYzeTJFOM3abxVgdaYLGTU41xqhUmhNMI PkfsZLDC5/nGH4PK/xRf7dwssL9CQ7KoyV7pTylbYlztSv22Gd0cZFwTwlKhg5GK5CYi UAqeRQbvXethJFw/hBfm/uEWZwaxxsvu5pKaErepcAqy9QHZlhabiT/mBG2yV2FwkPa7 W8GQ== X-Gm-Message-State: ALyK8tIFZOAUUY7QO0LVW13MfyJ8N/lceYyqZ27hJsP5kAfVp5PuWbIRmmyaPXUeI3AR0A== X-Received: by 10.98.20.5 with SMTP id 5mr995921pfu.144.1464906066599; Thu, 02 Jun 2016 15:21:06 -0700 (PDT) Received: from wkstn-mjohnston.west.isilon.com (c-76-104-201-218.hsd1.wa.comcast.net. [76.104.201.218]) by smtp.gmail.com with ESMTPSA id y1sm3142932pfa.25.2016.06.02.15.21.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Jun 2016 15:21:06 -0700 (PDT) Sender: Mark Johnston Date: Thu, 2 Jun 2016 15:25:05 -0700 From: Mark Johnston To: Ngie Cooper Cc: Michael Jung , FreeBSD Current , "kib@FreeBSD.org" Subject: Re: head r30140 - Panic String: _mtx_lock_sleep: recursed on non-recursive mutex vm page @ /usr/src/sys/vm/vm_page.c:774 Message-ID: <20160602222504.GC7708@wkstn-mjohnston.west.isilon.com> References: <96b9a1271d057fb8b67696623a6263c5@mail.mikej.com> <1827e9575941cf7c4bc82828ad00f431@mail.mikej.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 22:21:07 -0000 On Thu, Jun 02, 2016 at 03:17:21PM -0700, Ngie Cooper wrote: > On Thu, Jun 2, 2016 at 3:05 PM, Michael Jung wrote: > > On 2016-06-01 12:37, Michael Jung wrote: > >> > >> Since upgrading to head r301040 I have started to get the above panic > >> while running > >> poudriere while building packages for 10.3-STABLE r301107. > >> > >> Unfortuately I can't tell you the previous version of head but it was from > >> some > >> months ago. > >> > >> > >> https://charon.gopai.com/core.txt.7 > >> > >> https://charon.gopai.com/info.7 > >> > >> I also have the full core file if needed. > >> > >> Let me know what else I can provide. > >> > >> Thank you. > > > > Ideas? - there was another report of the same panic in vm_page.c > > > > http://postimg.org/image/r78vxopkb/ > > > > I see from the web log 20+ people have looked at the core file.... > > > > I can bump my build server but I was awaiting a response to the panic > > before doing that. > > It might have been fixed by r301212. CCing Kostik/Mark. > Thanks! > -Ngie I believe this would have been addressed by r301165, rather. Michael, could you try updating to this revision or later? From owner-freebsd-current@freebsd.org Thu Jun 2 22:25: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 12A9EB68559 for ; Thu, 2 Jun 2016 22:25:29 +0000 (UTC) (envelope-from oleglelchuk@gmail.com) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::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 947291691 for ; Thu, 2 Jun 2016 22:25:28 +0000 (UTC) (envelope-from oleglelchuk@gmail.com) Received: by mail-wm0-x231.google.com with SMTP id n184so100174440wmn.1 for ; Thu, 02 Jun 2016 15:25:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=8EUquUJhRJRZcwA99KRcBsWGYcnQueVhkezoY5V7cY8=; b=AxRUebLF8rJ8MFa1MH/GsqimmTtn54UHjdfsJLomUVt4BNFmsTNM++nHgfjTQcgDdF wpZ0GQ18O0e17dDDG5JGOwI0F65O+X9MnF8sIs0dpTbEnNNkpRJTUTnBlP46R2cAodei Ili/q5vUGiL+YVqL+BCybza0g/WclGJtga1c/TijOwKDx9nzcmCveFunVHrQzTHVUvbL iEk5nP/hOAfUPI2pYWWUW8UoVuDq9UubzwJchHSV+BHxb3lxCHAORc5nnG6yBn8M3Vdb oc/dTXsgyaG+UEbA4DaPU9IvX/vewbCmo3PTCQduHtqZPQ83Y54EBrecVEd/a9hjJx5k ewVA== 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; bh=8EUquUJhRJRZcwA99KRcBsWGYcnQueVhkezoY5V7cY8=; b=VGdYFAYQqLnaafnO5kplrhsUMRTYQx+VN5O+ef1fkpnoL3mPje9MLP0fcgbpXyW6/s 9F/Mr0zLuhrjEi5EJqdXROqFPagmAvo3J5ORvRC/Kn/xgWByTAoN2A5Y2V9UdFzyS1M9 3vq67mhrocXquKWkwE0E1RnnMNb7hZv5q001FUDv2A8zkzCF2ALxZ9OdR72w60ZdsAKL zX3VwlObnYliqtFNDPpdeCc2gJ2KpBa4vFsVHXRqZxNpMaVwrOBD8HY8Z+vzgiIBAFaL y07+lbdz3t0h0rSbNRCeLCiucdiQqW5ESznyKACvRYLPJIzakadoe32B1E3Aqar9ob7X 10ug== X-Gm-Message-State: ALyK8tKEM4PyvbBZ+RmFiBig1B1VwWAaw+qimT9WsyM2+aGPOM3Vp7dwbefUf383n4yxYMoJbgNrbBVdf1MQ6g== MIME-Version: 1.0 X-Received: by 10.28.62.69 with SMTP id l66mr27598603wma.70.1464906327182; Thu, 02 Jun 2016 15:25:27 -0700 (PDT) Received: by 10.194.174.230 with HTTP; Thu, 2 Jun 2016 15:25:27 -0700 (PDT) In-Reply-To: References: <0ae227ae-0154-cc15-eb64-17984ae2012a@freebsd.org> Date: Thu, 2 Jun 2016 18:25:27 -0400 Message-ID: Subject: Re: Streaming live tv over the udp protocol causes problems From: Oleg Lelchuk To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 22:25:29 -0000 I just solved this problem! I had to tweak the tunables net.inet.udp.recvspace and kern.ipc.maxsockbuf . After setting them to a larger value, I had no more problems streaming live tv. But it's interesting that I never had to tweak those tunables on 10.3-STABLE. On Thu, Jun 2, 2016 at 5:49 PM, Oleg Lelchuk wrote: > I am a bit confused about this server/client thing. My networked tv tuner > Hdhomerun has a wired connection to my router. It has a program called > hdhomerun_config_gui. I open the program, choose a tv channel that I want > to watch, then vlc opens, but the video that starts streaming is broken. > Vlc shows me the message that the stream comes from udp://127.0.0.1:5000 > . So, in this particular case, the tv tuner is the server and my computer > is the client? If my computer is the client, then this is the output I get > from "iperf -f m -i 1 -s -u": > > Server listening on UDP port 5001 > Receiving 1470 byte datagrams > UDP buffer size: 0.04 MByte (default) > > As I said earlier, I had no problems streaming live tv on 10.3-STABLE. > > > On Thu, Jun 2, 2016 at 1:35 PM, Allan Jude wrote: > >> On 2016-06-01 23:03, Oleg Lelchuk wrote: >> > Hi. On 11-ALPHA1, when I use vlc to stream live tv over the udp >> protocol, I >> > see a garbled and choppy video. This issue doesn't occur on >> 10.3-STABLE. I >> > am puzzled as to the cause of this problem. >> > _______________________________________________ >> > 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" >> > >> >> Are both machines FreeBSD? >> >> Can you try running iperf in udp mode, something like this: >> >> pkg install iperf >> >> client: iperf -f m -i 1 -s -u >> server: iperf -f m -i 1 -t 20 -c -u -b 100m >> >> And give us the results >> >> -- >> Allan Jude >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org >> " >> > > From owner-freebsd-current@freebsd.org Thu Jun 2 22:34: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 D86ACB6871F for ; Thu, 2 Jun 2016 22:34:52 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 94C8E1CC4 for ; Thu, 2 Jun 2016 22:34:52 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-qt0-x232.google.com with SMTP id d51so7303391qte.2 for ; Thu, 02 Jun 2016 15:34:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=wZEA5L3Q7DlO7YwGBjxogtU5LAQKavzP168sblySYH8=; b=CywG3J2S/QhuK9NYNahr7ZcdWddEqEchSBjBxNNapPBa8Tt688vGGmY5U31e9cPGla VjBFY/xKzshO5lHWziOSwgTPJqKyFV7B2CXzOCledE/cYPladAC5msqhg8p2g2o2eV8z 5QemhPh7UJgSuvlZ3VGcvoP0+8ZB+gh8tf86/vBtIbqi5Nj3x1/Mu8zU4MztGqviRDIz taRSUurz3/N+L5EF28oRXAOAXu8gSr3Wek8Fmd6lB/k1DjY5LrgeoQnFes4epwlY5e1a 3p4d3Z7iTkO0fWsEdSNTLRQQJd7eafOVtg3Dc2z/w8n9Q/v07cXEKK7Hs0eHYbe7P7Ls I4cg== 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; bh=wZEA5L3Q7DlO7YwGBjxogtU5LAQKavzP168sblySYH8=; b=ZLu0EWo12K/a5c3YzStiVtN+eQaX2JC6UViGrVfHGrb08BSsAqSlROC+15i/QKY+H1 J+cfyEJf0I7r+OKlA+DZZbsij4ZExe+0n8NIFYkX4OTU9BH+Vddy2Sl/78BYzosxwZeo hZZXlZ5w+nb+19c79ORulVLfJDHQ7yuL9TlbINLAu6xKy8QTF8jcVYXbU1WVJEAbzF0C LHh/5YVXXXqqCwPdXdrhaxxoN8JtU92gM3+SziV1wCHjOEX5pju6gDwqb3JZg17JWRVW 5jj6Q15i3RdfaNOOBbwM6GEzuP/Kh4s9B9bn8tvFO6q6oNmxHlsGxwgL6ceQ9pNQPwKx RO+Q== X-Gm-Message-State: ALyK8tKAQ6XqUgJ/sgLAt2qArcqYpvBMA/YummQk9KBl0Iqsn9dtOHSw9GxLWx6zHPOv4P5PkQ9OXmaTwNaHZg== MIME-Version: 1.0 X-Received: by 10.237.41.5 with SMTP id s5mr492687qtd.71.1464906891777; Thu, 02 Jun 2016 15:34:51 -0700 (PDT) Received: by 10.55.146.69 with HTTP; Thu, 2 Jun 2016 15:34:51 -0700 (PDT) In-Reply-To: References: <0ae227ae-0154-cc15-eb64-17984ae2012a@freebsd.org> Date: Thu, 2 Jun 2016 15:34:51 -0700 Message-ID: Subject: Re: Streaming live tv over the udp protocol causes problems From: Ngie Cooper To: Oleg Lelchuk Cc: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 22:34:52 -0000 On Thu, Jun 2, 2016 at 3:25 PM, Oleg Lelchuk wrote: > I just solved this problem! I had to tweak the tunables > net.inet.udp.recvspace and kern.ipc.maxsockbuf . After setting them to a > larger value, I had no more problems streaming live tv. But it's > interesting that I never had to tweak those tunables on 10.3-STABLE. 11.0-ALPHA1 might be running GENERIC (INVARIANTS, etc on). If so, it kind of makes sense why the system was getting behind... Thanks! -Ngie From owner-freebsd-current@freebsd.org Thu Jun 2 22:43: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 D9714B6899B; Thu, 2 Jun 2016 22:43:52 +0000 (UTC) (envelope-from mikej@mikej.com) Received: from mx2.paymentallianceintl.com (mx2.paymentallianceintl.com [216.26.158.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx2.paymentallianceintl.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A01331186; Thu, 2 Jun 2016 22:43:52 +0000 (UTC) (envelope-from mikej@mikej.com) Received: from firewall.mikej.com (f [162.230.214.65]) by mx2.paymentallianceintl.com (8.15.1/8.15.1) with ESMTPS id u52Mhn2E007213 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 2 Jun 2016 18:43:50 -0400 (EDT) (envelope-from mikej@mikej.com) X-Authentication-Warning: mx2.paymentallianceintl.com: Host f [162.230.214.65] claimed to be firewall.mikej.com Received: from mail.mikej.com (firewall.mikej.com [192.168.6.63]) by firewall.mikej.com (8.15.2/8.15.2) with ESMTP id u52Mhltw064913; Thu, 2 Jun 2016 18:43:48 -0400 (EDT) (envelope-from mikej@mikej.com) DMARC-Filter: OpenDMARC Filter v1.3.1 firewall.mikej.com u52Mhltw064913 Authentication-Results: mail.mikej.com; dmarc=none header.from=mikej.com DKIM-Filter: OpenDKIM Filter v2.10.3 firewall.mikej.com u52Mhltw064913 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mikej.com; s=mail; t=1464907429; bh=7KAMFSt6PQ80TlhpZtkWmCkEDvF/aVORH1+qAuN70dg=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=XSTZqPZHWaBxH7Kr4gexWK2zp9z5AlIhYfy99E8WL8gW1PDbFry+zWG9u23p5/Amq x4rXQmO/G5jWcuhJ4KPrRZ+Cc3GDzYbOO0FEpfOZvBwHu1Mam2ENDgc215HXAEeACi HMoWBgS3OM7Ou2heky62sRZpl4FZ92q+le0kAFL9oUmoI7pxT29FDuZ4t9mtNd7J/u PAHa/xMvnJO4mAev3/5E540cmduhrTxoey7GQCeOk8YRYQMnEJoyqHRt7zIe71jdFT P18ULOlzwvy4e1VbHEArVrQ4acy5FUptX0kiEVFkn1mmvWJ/pTYff354bISpjlMk15 0zlZXSpVdow+A== X-Authentication-Warning: firewall.mikej.com: Host firewall.mikej.com [192.168.6.63] claimed to be mail.mikej.com MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 02 Jun 2016 18:43:47 -0400 From: Michael Jung To: Ngie Cooper Cc: FreeBSD Current , "kib@FreeBSD.org" , Mark Johnston , owner-freebsd-current@freebsd.org Subject: Re: head r30140 - Panic String: _mtx_lock_sleep: recursed on non-recursive mutex vm page @ /usr/src/sys/vm/vm_page.c:774 In-Reply-To: References: <96b9a1271d057fb8b67696623a6263c5@mail.mikej.com> <1827e9575941cf7c4bc82828ad00f431@mail.mikej.com> Message-ID: X-Sender: mikej@mikej.com User-Agent: Roundcube Webmail/1.1.5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 22:43:53 -0000 On 2016-06-02 18:17, Ngie Cooper wrote: > On Thu, Jun 2, 2016 at 3:05 PM, Michael Jung wrote: >> On 2016-06-01 12:37, Michael Jung wrote: >>> >>> Since upgrading to head r301040 I have started to get the above panic >>> while running >>> poudriere while building packages for 10.3-STABLE r301107. >>> >>> Unfortuately I can't tell you the previous version of head but it was >>> from >>> some >>> months ago. >>> >>> >>> https://charon.gopai.com/core.txt.7 >>> >>> https://charon.gopai.com/info.7 >>> >>> I also have the full core file if needed. >>> >>> Let me know what else I can provide. >>> >>> Thank you. >> >> Ideas? - there was another report of the same panic in vm_page.c >> >> http://postimg.org/image/r78vxopkb/ >> >> I see from the web log 20+ people have looked at the core file.... >> >> I can bump my build server but I was awaiting a response to the panic >> before doing that. > > It might have been fixed by r301212. CCing Kostik/Mark. > Thanks! > -Ngie > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org"\ I pulling latest head based on comments r301229 - and will report back in next 48 hours - The crashes where not predictable but would always seem to occur within 12 hours of running poudriere builds. Thanks! From owner-freebsd-current@freebsd.org Thu Jun 2 23:32: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 6E02BB681C6 for ; Thu, 2 Jun 2016 23:32:37 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.auburn.protected-networks.net", Issuer "Protected Networks Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1789C14BC for ; Thu, 2 Jun 2016 23:32:37 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: imb@mail.auburn.protected-networks.net) by mail.auburn.protected-networks.net (Postfix) with ESMTPSA id 07F3D1CC6A for ; Thu, 2 Jun 2016 19:32:27 -0400 (EDT) Subject: Re: repeatable panic on pageout with 945GM To: freebsd-current@freebsd.org References: <2490f1c7-8153-ece3-49ed-4b3886564fd7@protected-networks.net> From: Michael Butler Openpgp: id=6F63E6399DCC8E3E94D60F0642FF6BAE0442D492 Message-ID: <205d4423-b834-9a21-785f-fa15d44c78ec@protected-networks.net> Date: Thu, 2 Jun 2016 19:32:26 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 23:32:37 -0000 On 05/23/16 21:10, Michael Butler wrote: > On 05/22/16 09:58, Michael Butler wrote: >> With KDE and compositing enabled, I randomly get the following: >> >> (kgdb) info stack >> #0 doadump (textdump=) at pcpu.h:221 >> #1 0xffffffff8064e98e in kern_reboot (howto=260) at >> /usr/src/sys/kern/kern_shutdown.c:366 >> #2 0xffffffff8064eea1 in vpanic (fmt=, ap=> optimized out>) at /usr/src/sys/kern/kern_shutdown.c:759 >> #3 0xffffffff8064ed13 in panic (fmt=0x0) at >> /usr/src/sys/kern/kern_shutdown.c:690 >> #4 0xffffffff809d18ed in vm_fault_hold (map=, >> vaddr=, fault_type=, >> fault_flags=, m_hold=) at >> /usr/src/sys/vm/vm_fault.c:327 >> #5 0xffffffff809cf548 in vm_fault (map=0xfffff80002000000, vaddr=> optimized out>, fault_type=1 '\001', fault_flags=) >> at /usr/src/sys/vm/vm_fault.c:273 >> #6 0xffffffff80a1849f in trap_pfault (frame=, >> usermode=0) at /usr/src/sys/amd64/amd64/trap.c:741 >> #7 0xffffffff80a17b30 in trap (frame=0xfffffe00dbec5830) at >> /usr/src/sys/amd64/amd64/trap.c:442 >> #8 0xffffffff809fd5a1 in calltrap () at >> /usr/src/sys/amd64/amd64/exception.S:236 >> #9 0xffffffff80a0a3bb in pmap_remove_all (m=) at >> /usr/src/sys/amd64/amd64/pmap.c:3950 >> #10 0xffffffff809c0c57 in cdev_pager_free_page (object=> out>, m=0xfffffe0001e410d0) at /usr/src/sys/vm/device_pager.c:214 >> #11 0xffffffff816aff33 in i915_gem_release_mmap (obj=) at pcpu.h:221 #1 0xffffffff805cfe9a in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:366 #2 0xffffffff805d03e1 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:759 #3 0xffffffff805d0253 in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:690 #4 0xffffffff8096c56e in vm_fault_hold (map=, vaddr=, fault_type=, fault_flags=, m_hold=) at /usr/src/sys/vm/vm_fault.c:327 #5 0xffffffff80969f78 in vm_fault (map=0xfffff80002000000, vaddr=, fault_type=1 '\001', fault_flags=) at /usr/src/sys/vm/vm_fault.c:273 #6 0xffffffff809b556f in trap_pfault (frame=, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:741 #7 0xffffffff809b4c00 in trap (frame=0xfffffe00dc0ef310) at /usr/src/sys/amd64/amd64/trap.c:442 #8 0xffffffff80999d81 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:236 #9 0xffffffff809a6d4e in pmap_remove_all (m=) at /usr/src/sys/amd64/amd64/pmap.c:3950 #10 0xffffffff8095ab7b in cdev_pager_free_page (object=, m=0xfffffe0001e2c270) at /usr/src/sys/vm/device_pager.c:214 #11 0xffffffff816aff33 in i915_gem_release_mmap (obj=) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:1691 #12 0xffffffff816b15ba in i915_gem_object_get_fence (obj=) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:105 #13 0xffffffff816b7f2e in i915_gem_execbuffer_reserve_object (obj=0xfffff8009858f200, ring=) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem_execbuffer.c:368 #14 0xffffffff816b7d8f in i915_gem_execbuffer_reserve () at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem_execbuffer.c:491 #15 0xffffffff816b6bb5 in i915_gem_do_execbuffer () at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem_execbuffer.c:1036 #16 0xffffffff816b7ad1 in i915_gem_execbuffer2 (dev=0xfffff800059e9000, data=0xfffffe00dc0efa20, file=0xfffff80005db4a00) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem_execbuffer.c:1273 #17 0xffffffff812c7eae in drm_ioctl (kdev=, cmd=, data=0xfffffe00dc0efa20 "", flags=, p=) at /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_drv.c:467 #18 0xffffffff804c721f in devfs_ioctl_f (fp=0xfffff800afba1550, com=2151703657, data=0xfffffe00dc0efa20, cred=0xfffff800af2dc800, td=0xfffff80005e2ca00) at /usr/src/sys/fs/devfs/devfs_vnops.c:815 #19 0xffffffff806377fe in kern_ioctl (td=, fd=, com=, data=0xfffffe00dc0efa20 "") at file.h:327 #20 0xffffffff80637481 in sys_ioctl (td=0xfffff80005e2ca00, uap=0xfffffe00dc0efb80) at /usr/src/sys/kern/sys_generic.c:743 #21 0xffffffff809b5e79 in amd64_syscall (td=, traced=0) at subr_syscall.c:135 #22 0xffffffff8099a06b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:396 #23 0x00000008024f57ca in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal Any hints welcome, imb From owner-freebsd-current@freebsd.org Thu Jun 2 23:55:54 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1E02CB68561 for ; Thu, 2 Jun 2016 23:55:54 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CCFE91E2E for ; Thu, 2 Jun 2016 23:55:53 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by mail-io0-x22e.google.com with SMTP id k19so47535668ioi.3 for ; Thu, 02 Jun 2016 16:55:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=b6Iagk7YausGJSzmiwjOEnZyGpFhmQHl4BT2guDLE/U=; b=LbN0Wa5CWuLlxFV6vhO36t5kUnKALpdwBkDTTSw9Zm8sQnL8E0GYBTVJLAJgzVY5AI DnQGi3jhwtLK/L6pSz+iuAC3mtyg06/LTdAMvqVlkniNljMvMHuW2zzAjGE2Ln4anOUG V6HXzxZy1cYl19rfBh0ttZFOVBXBPOhJtGVL3JvlQA8sdSAlLQ+RP5lBdwa+jQpDqz94 e4ZdqG95anF6cQyCu9zg944OgG4j589dP/iphlRNbEuukvgpUtjKg+1c6992ozzl6OOG QWneJyvR76Av1Te7yTYzNUIiOHqkWTPzD/B81a85btawg11dfebnHbgcTKHXF1FvH/pl iGjg== 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; bh=b6Iagk7YausGJSzmiwjOEnZyGpFhmQHl4BT2guDLE/U=; b=Bx744oGsEpSpSUKK2sMoUZjJTBGSik230G5aF7lAwYr5XmMEd6YFLqLf9Lr/38hxZ0 9FRDLs0LQSRwazlV6esWH4J4/LSdyt9FbRRKf+IxWShrF1rKVaI3/ZmInOo9M6bhGcq+ +NLy5bUWYddZlXGN//stNOYabyOTtNFdqx5ssHCmHNA5J1k835NpvfXKRfd7lK9ZbP1U P/DOlaguGx7ijC1EiczLuOauHTWx9EZa3OIAJbLjO+7XrKsiQ3SURBGD6cMIGkKt4asA Xe2ruNeJt6rXHLLjeUWEs5+jDtFzKaXFKN//hpdchGCeuqgB9/VVVOkFa77C3lZi5C8V PMIg== X-Gm-Message-State: ALyK8tLAxvKFiq2tK+eRo+hLBjyJBZjjDMh+PsonGnhXrnIRja8xEAkXKXVACH4WhpBZ9OkjKx/f2xEVUXBFQw== MIME-Version: 1.0 X-Received: by 10.107.160.5 with SMTP id j5mr1769618ioe.42.1464911753086; Thu, 02 Jun 2016 16:55:53 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.107.132.212 with HTTP; Thu, 2 Jun 2016 16:55:53 -0700 (PDT) In-Reply-To: <205d4423-b834-9a21-785f-fa15d44c78ec@protected-networks.net> References: <2490f1c7-8153-ece3-49ed-4b3886564fd7@protected-networks.net> <205d4423-b834-9a21-785f-fa15d44c78ec@protected-networks.net> Date: Thu, 2 Jun 2016 16:55:53 -0700 X-Google-Sender-Auth: uxY_ihHyG5GsycjcwhIPThgFJ2g Message-ID: Subject: Re: repeatable panic on pageout with 945GM From: "K. Macy" To: Michael Butler Cc: "freebsd-current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 23:55:54 -0000 It looks like it might be trying to remove mappings for a page that doesn't have any. It's a bit odd. Likely a bug in cdev_pager_free_page or gem release mmap. Compile the kernel and driver with -O0 and look at the page. It's too bad I don't support AGP yet with DRM 4.6. Maybe in a week or two. -M On Thursday, June 2, 2016, Michael Butler wrote: > On 05/23/16 21:10, Michael Butler wrote: > > On 05/22/16 09:58, Michael Butler wrote: > >> With KDE and compositing enabled, I randomly get the following: > >> > >> (kgdb) info stack > >> #0 doadump (textdump=) at pcpu.h:221 > >> #1 0xffffffff8064e98e in kern_reboot (howto=260) at > >> /usr/src/sys/kern/kern_shutdown.c:366 > >> #2 0xffffffff8064eea1 in vpanic (fmt=, ap= >> optimized out>) at /usr/src/sys/kern/kern_shutdown.c:759 > >> #3 0xffffffff8064ed13 in panic (fmt=0x0) at > >> /usr/src/sys/kern/kern_shutdown.c:690 > >> #4 0xffffffff809d18ed in vm_fault_hold (map=, > >> vaddr=, fault_type=, > >> fault_flags=, m_hold=) at > >> /usr/src/sys/vm/vm_fault.c:327 > >> #5 0xffffffff809cf548 in vm_fault (map=0xfffff80002000000, vaddr= >> optimized out>, fault_type=1 '\001', fault_flags=) > >> at /usr/src/sys/vm/vm_fault.c:273 > >> #6 0xffffffff80a1849f in trap_pfault (frame=, > >> usermode=0) at /usr/src/sys/amd64/amd64/trap.c:741 > >> #7 0xffffffff80a17b30 in trap (frame=0xfffffe00dbec5830) at > >> /usr/src/sys/amd64/amd64/trap.c:442 > >> #8 0xffffffff809fd5a1 in calltrap () at > >> /usr/src/sys/amd64/amd64/exception.S:236 > >> #9 0xffffffff80a0a3bb in pmap_remove_all (m=) at > >> /usr/src/sys/amd64/amd64/pmap.c:3950 > >> #10 0xffffffff809c0c57 in cdev_pager_free_page (object= >> out>, m=0xfffffe0001e410d0) at /usr/src/sys/vm/device_pager.c:214 > >> #11 0xffffffff816aff33 in i915_gem_release_mmap (obj= > [ .. snip .. ] > > Even with the most recent mesa update - something is upsetting this > device :-( > > (kgdb) bt > #0 doadump (textdump=) at pcpu.h:221 > #1 0xffffffff805cfe9a in kern_reboot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:366 > #2 0xffffffff805d03e1 in vpanic (fmt=, ap= optimized out>) at /usr/src/sys/kern/kern_shutdown.c:759 > #3 0xffffffff805d0253 in panic (fmt=0x0) at > /usr/src/sys/kern/kern_shutdown.c:690 > #4 0xffffffff8096c56e in vm_fault_hold (map=, > vaddr=, fault_type=, > fault_flags=, m_hold=) at > /usr/src/sys/vm/vm_fault.c:327 > #5 0xffffffff80969f78 in vm_fault (map=0xfffff80002000000, vaddr= optimized out>, fault_type=1 '\001', fault_flags=) > at /usr/src/sys/vm/vm_fault.c:273 > #6 0xffffffff809b556f in trap_pfault (frame=, > usermode=0) at /usr/src/sys/amd64/amd64/trap.c:741 > #7 0xffffffff809b4c00 in trap (frame=0xfffffe00dc0ef310) at > /usr/src/sys/amd64/amd64/trap.c:442 > #8 0xffffffff80999d81 in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:236 > #9 0xffffffff809a6d4e in pmap_remove_all (m=) at > /usr/src/sys/amd64/amd64/pmap.c:3950 > #10 0xffffffff8095ab7b in cdev_pager_free_page (object= out>, m=0xfffffe0001e2c270) at /usr/src/sys/vm/device_pager.c:214 > #11 0xffffffff816aff33 in i915_gem_release_mmap (obj= out>) at > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:1691 > #12 0xffffffff816b15ba in i915_gem_object_get_fence (obj= optimized out>) at > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:105 > #13 0xffffffff816b7f2e in i915_gem_execbuffer_reserve_object > (obj=0xfffff8009858f200, ring=) > at > > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem_execbuffer.c:368 > #14 0xffffffff816b7d8f in i915_gem_execbuffer_reserve () at > > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem_execbuffer.c:491 > #15 0xffffffff816b6bb5 in i915_gem_do_execbuffer () at > > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem_execbuffer.c:1036 > #16 0xffffffff816b7ad1 in i915_gem_execbuffer2 (dev=0xfffff800059e9000, > data=0xfffffe00dc0efa20, file=0xfffff80005db4a00) > at > > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem_execbuffer.c:1273 > #17 0xffffffff812c7eae in drm_ioctl (kdev=, > cmd=, data=0xfffffe00dc0efa20 "", flags= optimized out>, > p=) at > /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_drv.c:467 > #18 0xffffffff804c721f in devfs_ioctl_f (fp=0xfffff800afba1550, > com=2151703657, data=0xfffffe00dc0efa20, cred=0xfffff800af2dc800, > td=0xfffff80005e2ca00) > at /usr/src/sys/fs/devfs/devfs_vnops.c:815 > #19 0xffffffff806377fe in kern_ioctl (td=, > fd=, com=, > data=0xfffffe00dc0efa20 "") at file.h:327 > #20 0xffffffff80637481 in sys_ioctl (td=0xfffff80005e2ca00, > uap=0xfffffe00dc0efb80) at /usr/src/sys/kern/sys_generic.c:743 > #21 0xffffffff809b5e79 in amd64_syscall (td=, > traced=0) at subr_syscall.c:135 > #22 0xffffffff8099a06b in Xfast_syscall () at > /usr/src/sys/amd64/amd64/exception.S:396 > #23 0x00000008024f57ca in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > > Any hints welcome, > > imb > > > > _______________________________________________ > 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 Jun 3 00:08:49 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0C926B68A8F for ; Fri, 3 Jun 2016 00:08:49 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 C80B31702 for ; Fri, 3 Jun 2016 00:08:48 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-it0-x233.google.com with SMTP id e62so141396981ita.1 for ; Thu, 02 Jun 2016 17:08:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=VggJGVvRJGvz30z5X8AVzkBj7j5eXYlSbtW6REOiuNs=; b=KyJk4XecN0EdGp7BLJsKvecvlrOyqf0ZrAM84XjsfxZLtbqNrZhZVOx9J1eQmuAPgT TYyE+4tDKP0L6x16uduvM1xrWXtLdUA7ZqONHByEl7h3yBMfvWo6RaETtLG2dueN8ov8 1ThISsbB6vJhgT1iIOhdsNPBEMy2WNF0GTh7DevKL8ao7z6JRq952PwjxBWM7DDn8g+I Exc2K9W8wgxOuxMB4uIgrC6mN9bUhp0ScO02dWz5GrvROl+PsMKLSLbtUHAxvhXM61Y8 kkkfNYvLzgFf87RVEkwNpuhkdnPrc912ECdY+OMbJb4/iuLkRnQDAdExxt/+3rxZxVwW yvcw== 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; bh=VggJGVvRJGvz30z5X8AVzkBj7j5eXYlSbtW6REOiuNs=; b=X8sZHxvMTMMJUhlmxeVCz7pLYd+aPPEOZA4t0WNL1cmWPqKEP3BmAji8l6xHxBYTi7 Iq9SIqrFieI65KzrsbUAhLCLzbWcsbRb/OOgkKPpXsbXBKWLlTZX+M/9hqHxSiGAK/f5 4kuCoZlJG9OtXpY3NYYbTr48uNcqNPbD4jpNGpGA1b04gfAp/PaW3e9QxPMKy52A37MQ SNKx5syVh6MDd/pzNuSVUbiZkKkFVgJoROQvpvL1K214163sGlOebvEWIPWEu62Fv7hZ CZ09PIL1Hihr5OMO5jwGDs7vTARAugJzVgAml2944pFbAi8lswcFy7GbB0gU6ezch1c7 I8ZA== X-Gm-Message-State: ALyK8tJBs4sM1bPc2eI+pGMnjXvRUahrfkrIAcXIeM3b1gGVRs+Vj1bKfu/il2SCf/uNDec71/QLCwsALd4gQQ== MIME-Version: 1.0 X-Received: by 10.36.64.14 with SMTP id n14mr6059774ita.53.1464912528136; Thu, 02 Jun 2016 17:08:48 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.79.20.70 with HTTP; Thu, 2 Jun 2016 17:08:48 -0700 (PDT) In-Reply-To: <20160602224654.18927083.ohartman@zedat.fu-berlin.de> References: <0448c751-8608-51ce-f47e-76280ebf14f2@selasky.org> <20160602224654.18927083.ohartman@zedat.fu-berlin.de> Date: Thu, 2 Jun 2016 17:08:48 -0700 X-Google-Sender-Auth: aaoHOv511vqOr-kpSNMGzQ-Q7s0 Message-ID: Subject: Re: Suddenly poweroff in 11-Current r300097 From: Kevin Oberman To: "O. Hartmann" Cc: Hans Petter Selasky , RayCherng Yu , FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 00:08:49 -0000 On Thu, Jun 2, 2016 at 1:46 PM, O. Hartmann wrote: > Am Thu, 2 Jun 2016 10:26:22 -0700 > Kevin Oberman schrieb: > > > On Thu, Jun 2, 2016 at 7:41 AM, Hans Petter Selasky > wrote: > > > > > On 06/02/16 03:07, RayCherng Yu wrote: > > > > > >> I got a suddenly poweroff in r300097 (and previous revision in April > and > > >> May) when I built textproc/docproj. > > >> My machine is Macbook Pro 13 2011 early. I have checked the Apple > website. > > >> My bios is the latest version. > > >> Actually it also happened in 10.3-STABLE. > > >> It happened when the machine load was heavy. Before it shutdown, the > fan > > >> started to run very loudly. After several seconds (20 or 30 seconds), > my > > >> laptop shutdown (poweroff directly) suddenly. It seems not happen > with the > > >> AC power supply connected. > > >> > > >> I installed both Mac OSX and FreeBSD (dual boot). It never happened > in Mac > > >> OSX. > > >> > > >> My dmesg: > > >> http://pastebin.com/QjZmbGCB > > >> > > >> My sysctl hw.acpi: > > >> > > >> hw.acpi.acline: 0 > > >> hw.acpi.battery.info_expire: 5 > > >> hw.acpi.battery.units: 1 > > >> hw.acpi.battery.state: 1 > > >> hw.acpi.battery.time: 87 > > >> hw.acpi.battery.life: 59 > > >> hw.acpi.cpu.cx_lowest: C8 > > >> hw.acpi.reset_video: 0 > > >> hw.acpi.handle_reboot: 1 > > >> hw.acpi.disable_on_reboot: 0 > > >> hw.acpi.verbose: 0 > > >> hw.acpi.s4bios: 0 > > >> hw.acpi.sleep_delay: 1 > > >> hw.acpi.suspend_state: S3 > > >> hw.acpi.standby_state: NONE > > >> hw.acpi.lid_switch_state: NONE > > >> hw.acpi.sleep_button_state: S3 > > >> hw.acpi.power_button_state: S5 > > >> hw.acpi.supported_sleep_state: S3 S4 S5 > > >> > > >> > > > Hi, > > > > > > Do you have a temperature sysctl? Usually FreeBSD will shutdown the > system > > > if the ACPI temperature exceeds some value. Maybe it would be better to > > > reduce the CPU load when the temperature goes up instead of facing a > > > shutdown? > > > > > > --HPS > > > > > > The relevant information is probably found in dev.cpu. That is where all > > temperature information is located as it is per-CPU, not per-system. Of > > particular interest is dev.cpu.0.cx_lowest, dev.cpu.0.cx_supported, and > > dev.cpu.0.freq_levels. A snapshot of dev.cpu.0 when the fan has cranked > up, > > but before shutdown would be nice, too. > > > > I see no hw.acpi.thermal information. This is very odd. These values > > indicate what the system will do and is doing if it starts getting too > hot. > > > > Is coretemp loaded? It is required to see the core temperatures and those > > are almost certainly significant. It may account for the lack of thermal > > information. Finally, a dmesg might be useful as it will tell us more > about > > just what thermal control techniques are enabled. > > > > Just to explain a bit on how this should work: when the temperature > exceeds > > some BIOS defined point, the system should "throttle" by pausing one of > > every 8 clock cycles. If that does not fix the problem, the it rests for > > two of every 8 and so on until the temperature is reduced. If it > continues > > to rise and reaches another BIOS set point, it will initiate an emergency > > shutdown. If it reaches a CPU defined temperature, the power will shut > off > > immediately. Note that this is entirely a hardware function with no BIOS > or > > OS involvement. It should NEVER happen in normal operation as it is > > triggered by a significant overtemp that threatens to destroy the CPU. > I've > > only seen it once when the CPU heat sink came loose on an old P4 system > > several years ago. > > > > I should mention that I have zero experience with Apple hardware and it > is > > possible that they do some things differently than I have seen on other > > hardware. > > -- > > Kevin Oberman, Part time kid herder and retired Network Engineer > > E-mail: rkoberman@gmail.com > > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > > I have had such problems many times with older hardware. In most cases > "dried out" > thermal conductive pad or grease was the reason overheating the CPU du to > a ineffective > thermal conductivity from the CPU's surface to the heat spreader/cooler. I > had recently > two laptops with such a phenomenon - using high-quality thermal grease > solved the problem > for my. In both cases, the former high-viscous thermal grease has become > like dry mud. > Same with pads. > Valid suggestion. If you have not worked with it, keep the layer of grease as thin as possible. Use quality grease, not pads or tape. They just don't work as well. Good silicone thermal grease should remain effective for at a minimum of 10 years. Also, clean your heat sinks! I clean the ones on my laptop about once a year (I have to remove the keyboard to blow them out) and I see the quiescent temperature drop by 10-15C and the temp under load can drop by 20C. As active cooling works on my laptop, it does not overheat, but it does slow down on "buildworld -j6" and building ports like chromium and libreoffice. Very significant. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 From owner-freebsd-current@freebsd.org Fri Jun 3 02:31:19 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DB68BB664A2 for ; Fri, 3 Jun 2016 02:31:19 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B07C31ED9; Fri, 3 Jun 2016 02:31:19 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1464921072153504.6953259897392; Thu, 2 Jun 2016 19:31:12 -0700 (PDT) Date: Thu, 02 Jun 2016 19:31:12 -0700 From: Matthew Macy To: "K. Macy" Cc: "Michael Butler" , "freebsd-current@freebsd.org" Message-ID: <1551419a1db.12929035f45012.326107747932338888@nextbsd.org> In-Reply-To: References: <2490f1c7-8153-ece3-49ed-4b3886564fd7@protected-networks.net> <205d4423-b834-9a21-785f-fa15d44c78ec@protected-networks.net> Subject: Re: repeatable panic on pageout with 945GM MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 02:31:20 -0000 Tell me if that makes any difference. -M ---- On Thu, 02 Jun 2016 16:55:53 -0700 K. Macy wrote ---- > It looks like it might be trying to remove mappings for a page that doesn't > have any. It's a bit odd. Likely a bug in cdev_pager_free_page or gem > release mmap. Compile the kernel and driver with -O0 and look at the page. > It's too bad I don't support AGP yet with DRM 4.6. Maybe in a week or two. diff --git a/sys/vm/device_pager.c b/sys/vm/device_pager.c index 013f0d5..917ece7 100644 --- a/sys/vm/device_pager.c +++ b/sys/vm/device_pager.c @@ -211,7 +211,8 @@ cdev_pager_free_page(vm_object_t object, vm_page_t m) VM_OBJECT_ASSERT_WLOCKED(object); if (object->type == OBJT_MGTDEVICE) { KASSERT((m->oflags & VPO_UNMANAGED) == 0, ("unmanaged %p", m)); - pmap_remove_all(m); + if (pmap_page_is_mapped(page)) + pmap_remove_all(m); vm_page_lock(m); vm_page_remove(m); vm_page_unlock(m); > > -M > > On Thursday, June 2, 2016, Michael Butler > wrote: > > > On 05/23/16 21:10, Michael Butler wrote: > > > On 05/22/16 09:58, Michael Butler wrote: > > >> With KDE and compositing enabled, I randomly get the following: > > >> > > >> (kgdb) info stack > > >> #0 doadump (textdump=) at pcpu.h:221 > > >> #1 0xffffffff8064e98e in kern_reboot (howto=260) at > > >> /usr/src/sys/kern/kern_shutdown.c:366 > > >> #2 0xffffffff8064eea1 in vpanic (fmt=, ap= > >> optimized out>) at /usr/src/sys/kern/kern_shutdown.c:759 > > >> #3 0xffffffff8064ed13 in panic (fmt=0x0) at > > >> /usr/src/sys/kern/kern_shutdown.c:690 > > >> #4 0xffffffff809d18ed in vm_fault_hold (map=, > > >> vaddr=, fault_type=, > > >> fault_flags=, m_hold=) at > > >> /usr/src/sys/vm/vm_fault.c:327 > > >> #5 0xffffffff809cf548 in vm_fault (map=0xfffff80002000000, vaddr= > >> optimized out>, fault_type=1 '\001', fault_flags=) > > >> at /usr/src/sys/vm/vm_fault.c:273 > > >> #6 0xffffffff80a1849f in trap_pfault (frame=, > > >> usermode=0) at /usr/src/sys/amd64/amd64/trap.c:741 > > >> #7 0xffffffff80a17b30 in trap (frame=0xfffffe00dbec5830) at > > >> /usr/src/sys/amd64/amd64/trap.c:442 > > >> #8 0xffffffff809fd5a1 in calltrap () at > > >> /usr/src/sys/amd64/amd64/exception.S:236 > > >> #9 0xffffffff80a0a3bb in pmap_remove_all (m=) at > > >> /usr/src/sys/amd64/amd64/pmap.c:3950 > > >> #10 0xffffffff809c0c57 in cdev_pager_free_page (object= > >> out>, m=0xfffffe0001e410d0) at /usr/src/sys/vm/device_pager.c:214 > > >> #11 0xffffffff816aff33 in i915_gem_release_mmap (obj= > > > [ .. snip .. ] > > > > Even with the most recent mesa update - something is upsetting this > > device :-( > > > > (kgdb) bt > > #0 doadump (textdump=) at pcpu.h:221 > > #1 0xffffffff805cfe9a in kern_reboot (howto=260) at > > /usr/src/sys/kern/kern_shutdown.c:366 > > #2 0xffffffff805d03e1 in vpanic (fmt=, ap= > optimized out>) at /usr/src/sys/kern/kern_shutdown.c:759 > > #3 0xffffffff805d0253 in panic (fmt=0x0) at > > /usr/src/sys/kern/kern_shutdown.c:690 > > #4 0xffffffff8096c56e in vm_fault_hold (map=, > > vaddr=, fault_type=, > > fault_flags=, m_hold=) at > > /usr/src/sys/vm/vm_fault.c:327 > > #5 0xffffffff80969f78 in vm_fault (map=0xfffff80002000000, vaddr= > optimized out>, fault_type=1 '\001', fault_flags=) > > at /usr/src/sys/vm/vm_fault.c:273 > > #6 0xffffffff809b556f in trap_pfault (frame=, > > usermode=0) at /usr/src/sys/amd64/amd64/trap.c:741 > > #7 0xffffffff809b4c00 in trap (frame=0xfffffe00dc0ef310) at > > /usr/src/sys/amd64/amd64/trap.c:442 > > #8 0xffffffff80999d81 in calltrap () at > > /usr/src/sys/amd64/amd64/exception.S:236 > > #9 0xffffffff809a6d4e in pmap_remove_all (m=) at > > /usr/src/sys/amd64/amd64/pmap.c:3950 > > #10 0xffffffff8095ab7b in cdev_pager_free_page (object= > out>, m=0xfffffe0001e2c270) at /usr/src/sys/vm/device_pager.c:214 > > #11 0xffffffff816aff33 in i915_gem_release_mmap (obj= > out>) at > > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:1691 > > #12 0xffffffff816b15ba in i915_gem_object_get_fence (obj= > optimized out>) at > > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:105 > > #13 0xffffffff816b7f2e in i915_gem_execbuffer_reserve_object > > (obj=0xfffff8009858f200, ring=) > > at > > > > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem_execbuffer.c:368 > > #14 0xffffffff816b7d8f in i915_gem_execbuffer_reserve () at > > > > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem_execbuffer.c:491 > > #15 0xffffffff816b6bb5 in i915_gem_do_execbuffer () at > > > > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem_execbuffer.c:1036 > > #16 0xffffffff816b7ad1 in i915_gem_execbuffer2 (dev=0xfffff800059e9000, > > data=0xfffffe00dc0efa20, file=0xfffff80005db4a00) > > at > > > > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem_execbuffer.c:1273 > > #17 0xffffffff812c7eae in drm_ioctl (kdev=, > > cmd=, data=0xfffffe00dc0efa20 "", flags= > optimized out>, > > p=) at > > /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_drv.c:467 > > #18 0xffffffff804c721f in devfs_ioctl_f (fp=0xfffff800afba1550, > > com=2151703657, data=0xfffffe00dc0efa20, cred=0xfffff800af2dc800, > > td=0xfffff80005e2ca00) > > at /usr/src/sys/fs/devfs/devfs_vnops.c:815 > > #19 0xffffffff806377fe in kern_ioctl (td=, > > fd=, com=, > > data=0xfffffe00dc0efa20 "") at file.h:327 > > #20 0xffffffff80637481 in sys_ioctl (td=0xfffff80005e2ca00, > > uap=0xfffffe00dc0efb80) at /usr/src/sys/kern/sys_generic.c:743 > > #21 0xffffffff809b5e79 in amd64_syscall (td=, > > traced=0) at subr_syscall.c:135 > > #22 0xffffffff8099a06b in Xfast_syscall () at > > /usr/src/sys/amd64/amd64/exception.S:396 > > #23 0x00000008024f57ca in ?? () > > Previous frame inner to this frame (corrupt stack?) > > Current language: auto; currently minimal > > > > Any hints welcome, > > > > imb > > > > > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org > > " > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Fri Jun 3 03:27: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 9D089B66F03 for ; Fri, 3 Jun 2016 03:27:56 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [202.12.127.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.auburn.protected-networks.net", Issuer "Protected Networks Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2D1A01D66; Fri, 3 Jun 2016 03:27:55 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: imb@mail.auburn.protected-networks.net) by mail.auburn.protected-networks.net (Postfix) with ESMTPSA id 486321CC6A; Thu, 2 Jun 2016 23:27:52 -0400 (EDT) Subject: Re: repeatable panic on pageout with 945GM To: Matthew Macy References: <2490f1c7-8153-ece3-49ed-4b3886564fd7@protected-networks.net> <205d4423-b834-9a21-785f-fa15d44c78ec@protected-networks.net> <1551419a1db.12929035f45012.326107747932338888@nextbsd.org> Cc: "K. Macy" , "freebsd-current@freebsd.org" From: Michael Butler Openpgp: id=6F63E6399DCC8E3E94D60F0642FF6BAE0442D492 Message-ID: <82cd3e80-b180-9823-7342-5069401cf11b@protected-networks.net> Date: Thu, 2 Jun 2016 23:27:51 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <1551419a1db.12929035f45012.326107747932338888@nextbsd.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 03:27:56 -0000 On 06/02/16 22:31, Matthew Macy wrote: > Tell me if that makes any difference. > > -M > > > ---- On Thu, 02 Jun 2016 16:55:53 -0700 K. Macy wrote ---- > > It looks like it might be trying to remove mappings for a page that doesn't > > have any. It's a bit odd. Likely a bug in cdev_pager_free_page or gem > > release mmap. Compile the kernel and driver with -O0 and look at the page. > > It's too bad I don't support AGP yet with DRM 4.6. Maybe in a week or two. > > > > diff --git a/sys/vm/device_pager.c b/sys/vm/device_pager.c > index 013f0d5..917ece7 100644 > --- a/sys/vm/device_pager.c > +++ b/sys/vm/device_pager.c > @@ -211,7 +211,8 @@ cdev_pager_free_page(vm_object_t object, vm_page_t m) > VM_OBJECT_ASSERT_WLOCKED(object); > if (object->type == OBJT_MGTDEVICE) { > KASSERT((m->oflags & VPO_UNMANAGED) == 0, ("unmanaged %p", m)); > - pmap_remove_all(m); > + if (pmap_page_is_mapped(page)) > + pmap_remove_all(m); > vm_page_lock(m); > vm_page_remove(m); > vm_page_unlock(m); Slight variation -won't build as above; trying with "pmap_page_is_mapped(m)" imb From owner-freebsd-current@freebsd.org Fri Jun 3 03:33: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 751E0B680B7 for ; Fri, 3 Jun 2016 03:33:00 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BABD123D; Fri, 3 Jun 2016 03:32:59 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1464924772301762.1686272126927; Thu, 2 Jun 2016 20:32:52 -0700 (PDT) Date: Thu, 02 Jun 2016 20:32:52 -0700 From: Matthew Macy To: "Michael Butler" Cc: "K. Macy" , "freebsd-current@freebsd.org" Message-ID: <15514521798.c83cb0fb46465.6717596356997564786@nextbsd.org> In-Reply-To: <82cd3e80-b180-9823-7342-5069401cf11b@protected-networks.net> References: <2490f1c7-8153-ece3-49ed-4b3886564fd7@protected-networks.net> <205d4423-b834-9a21-785f-fa15d44c78ec@protected-networks.net> <1551419a1db.12929035f45012.326107747932338888@nextbsd.org> <82cd3e80-b180-9823-7342-5069401cf11b@protected-networks.net> Subject: Re: repeatable panic on pageout with 945GM MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 03:33:00 -0000 > > Slight variation -won't build as above; trying with "pmap_page_is_mapped(m)" > Oops copy pasta + serious fatigue. But you got the right idea. -M From owner-freebsd-current@freebsd.org Fri Jun 3 04:16:48 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B3CABB68750 for ; Fri, 3 Jun 2016 04:16:48 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003: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 833661295 for ; Fri, 3 Jun 2016 04:16:48 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-oi0-x22c.google.com with SMTP id k23so109646144oih.0 for ; Thu, 02 Jun 2016 21:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:date:message-id:subject:from:to; bh=UuUa4dXL1nc6kcqGLYHhwZ8+IbnuB6uwDNezDYUB6qM=; b=PALyFcIuB5PPzuTvm9CxO1PXGTYU+vNmxXwUppovywJPTdjlZMmzmM/yhVyi3+TRQE hGdhzBU7O45vpIBMun7yM6/TfPlBItIXD8p+qscURFANU5wRAcESAkeagjNumkcpH7nG TRG4kK9hsz5qiv5jEs3C39v7O4/hp9KRry9gajx6fuu9fjY1ql3dBEuPcuQ4vPV2t/V1 z7t+vYZeeyAAOHbHVMYa70zy3UKWdoWzsmlqs75a8zhIvBvh8RXGj4QX8XGD/FvGS6zb pCEOGzbxiLFw1F/UDUjqgfqrP9fBO09XGFIKYPqqhVPpubYoEkLp28nefXrCCtEXiTWi gmmg== 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:date:message-id:subject:from :to; bh=UuUa4dXL1nc6kcqGLYHhwZ8+IbnuB6uwDNezDYUB6qM=; b=XGKWFu9onuCIbueqGeXDOIW43SOikAgBl8VOrHygxwMVZOrk2sXQ06BvFkWHlN+5P/ Af2TCBTsjtHzrzsR4Kei98jUaN2Q7auHPOuy8P5bpdxzlFmDWObwviQfpisz9pMHJkIM i/u0pW5YGI475bpQt50UdKw7cE91UF+esB161A/hry4VYm2hPeVgdVGwOVpf48yCfRKf CND+L9BQMX94LeMv4gtwnq69Bp1zrhSi2mvDuhf4ouaFqH18+5cYVC+DSUwp9hkEbXS2 NgAoUCoBxxsy6Gkc7r2mSO3p21G1xr3T7/2s086CJnh3zvPy9C3BtS8Cwjnu2mPCeN9e vToA== X-Gm-Message-State: ALyK8tIIhQvi7KWi71OThBS/8UYYZPVZ6O8Yyv1RcgDJlgGSagEpNgAsL7ForayVdUb+RYhJc51LQwtgDo8nWId/ MIME-Version: 1.0 X-Received: by 10.202.241.67 with SMTP id p64mr652858oih.197.1464927407613; Thu, 02 Jun 2016 21:16:47 -0700 (PDT) Sender: sobomax@sippysoft.com Received: by 10.157.56.70 with HTTP; Thu, 2 Jun 2016 21:16:47 -0700 (PDT) Date: Thu, 2 Jun 2016 21:16:47 -0700 X-Google-Sender-Auth: _pVd8Ya48XkdEhMcg4Hhyl0Z93I Message-ID: Subject: CLOCK_MONOTONIC / CLOCK_UPTIME is not really monotonic between threads From: Maxim Sobolev To: FreeBSD Current , freebsd-threads@freebsd.org, freebsd-questions@freebsd.org, freebsd-arch@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 04:16:48 -0000 Hi there, we have an application here which is trying to measure UDP command/response round-trip-time. It runs two posix threads (more actually, but that's probably irrelevant), one (let's call it A) that does high-level logic and the second one (B) that does network packet I/O. The sending side is done by first thread A forming the request, then calling the function clock_gettime(CLOCK_MONOTONIC) and passing the packet into the thread B. Obtained timestamp is stored with some logical transaction ID allowing us to pull that stored value later on when response arrives. Then we have a separate process that receives those requests, processing them and sending back some form of response. Upon receiving a response from the network, the network I/O thread (B) timestamps it by running clock_gettime(CLOCK_MONOTONIC) and passes the packet data along with that value via queue to the thread A for processing. So if we put things into timeline, what our app does would probably look something like the following: 1. Thread A generates request. 2. A calls clock_gettime(CLOCK_MONOTONIC), storing value as t1 internally 3. A passes packet to thread B 4. B sends out packet via sendto() to server process running on the same box (fully separate, not a thread) [some microseconds later] 5. B receives response from server with recvfrom() 6. B instantly calls clock_gettime(CLOCK_MONOTONIC), assigns returned value to t2 7. B passes packet data along with t2 to the A via queue 8. A picks up packet, parses it and retrieves corresponding t1 stored at step 2. 9. A calculates RTT by doing t2 - t1 assuming it's going to be positive... As you might have guessed if you are still reading, from time to time t2 - t1 comes out slightly negative! Provided it's not some obscure bug in our app, there is no way this could happen if clock_gettime(CLOCK_MONOTONIC) would work as advertised. Event (2) could not possibly happen earlier than (6), which is guaranteed by the fact that the request needs to be processed by the external entity first in order for the response to be seen by our app at all. I've added some logs and it seems to be confirming that the server only sees a single request, there is no chance for the client to receive some other packet and confuse it. I've also confirmed with tcpdump, which shows reasonable time delay between request and reply of few hundreds microseconds. I've checked all logic and I could not find any mistakes on my end here, so I added some logging for such events. The distribution appears to be centered around 0.00006s, but there are some events that go as far up as 0.012s. I've also tried using CLOCK_UPTIME_PRECISE instead, but it makes no difference whatsoever. My questions therefore are: 1. Is it intended/expected behavior of the said API? 2. Has anyone else bumped into this? 3. I know we are doing some clever optimizations using TSC to speed those APIs up, could be it related to that? 4. If the answer for (3) is yes, then what is the method to disable using TSC and use slower but possibly more reliable method? 5. Is there any way/plan to fix this long-term? 6. If the behavior is intended/expected, what is the maximum discrepancy we can expect from this effect? In general some time ago we've spend quite lot of time switching our app from using REALTIME into MONOTIME in the hope to eliminate any wizardry needed to deal with realtime possibly jumping back and forth due to NTP, leap seconds etc, it's shame that this is not working either. Apart from measuring command processing delay, that app does lot of high-volume voip call billing, so even such small discrepancy can easily build up into a bigger problem, not to mention the fact that every time we deal with duration we now need to have some check in place to make sure we don't have some negative values popping our of nowhere. Any hints, suggestions, pointers are appreciated. I can also give more debug information as needed. Thanks! -Max From owner-freebsd-current@freebsd.org Fri Jun 3 05:05: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 991DBB68FDA; Fri, 3 Jun 2016 05:05:29 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 653831B40; Fri, 3 Jun 2016 05:05:29 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x231.google.com with SMTP id o189so54931278ioe.2; Thu, 02 Jun 2016 22:05:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=HB2MCHDu3HgA9EshZyPtgWRG8azVzZUZFLIwjsNXc4A=; b=qvqAYuCxTCebd03wL9RXt5fe999NOWxcnFvdYKRzRmVqkS4CGskzREs/3cfjwk6ru0 ZDSEzO40J5bEzWG8vkvqT1t1XOIDvXOzvvouRCAPbBWPjLB0mCXsAIPFaZM2ZYMZU8ko 5qUTI40ph0s31Zh6pnVH3pROoVuXinWjckIXazrKqdClFvvVZhehbCbkfDVKsJOyeEOq Puislektl9aLQ1Awp4PmRRCu1CGd7tY0n6iuuFnKEA84L2ArB6LDJYSzMHl0Q8fDBlLE 9KqHo0H6YAiQ5nAOGE0/x+WCRWVyjpNfwpUPDdBWO4/8SzVxi+gxOsG/yGYugO+DPNdc 0IMg== 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; bh=HB2MCHDu3HgA9EshZyPtgWRG8azVzZUZFLIwjsNXc4A=; b=ltZi74TQWgTRBiw61zM5zUv4seayn9QIZH14veKSADSde8YGAJ05bifctH9i+xqf7M boQenHfwgAsQbrjcJh8TCMzHFlg/8pKXo6Pop1wg52KA/4WzsumKD9UX/z5lGAl1at8N fZSjr1urTbolfCgcRKbvKHogssam5CAO+oDpproJS6WI3SQVW5spRCP1ePUuooGDrqXN BKuqL3exOkwpCiMXvvi+n1PiFAq501/SW9bM+5Oe9hhkBjzR/1jJNeqsqVG8JPEu99HY CTOhlw0zfbuS1jZcOFJaYBg0pTG+vQoNHyWjht+bVCpqZV3FiuqHN7kT8n8t+LB/PYXb 6cuQ== X-Gm-Message-State: ALyK8tJV1p1JlAgAB38AkJzzF/PJxW8l+N7LhPSFP7HqE63f453TW51fEaNYZbBRKHYHb0SoocH5h92hPtlQuw== MIME-Version: 1.0 X-Received: by 10.107.48.203 with SMTP id w194mr2390958iow.123.1464930328822; Thu, 02 Jun 2016 22:05:28 -0700 (PDT) Received: by 10.36.113.3 with HTTP; Thu, 2 Jun 2016 22:05:28 -0700 (PDT) In-Reply-To: References: Date: Thu, 2 Jun 2016 22:05:28 -0700 Message-ID: Subject: Re: CLOCK_MONOTONIC / CLOCK_UPTIME is not really monotonic between threads From: Adrian Chadd To: Maxim Sobolev Cc: FreeBSD Current , freebsd-threads@freebsd.org, FreeBSD Questions , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 05:05:29 -0000 [snip] a) is it on one core, or multiple cores? b) CLOCK_MONOTONIC_FAST? c) is it on a system that /has/ invariant-TSC ? d) is this a multi-socket system? -adrian From owner-freebsd-current@freebsd.org Fri Jun 3 05: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 DCC35B68143 for ; Fri, 3 Jun 2016 05:06:43 +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 4731F1E3A; Fri, 3 Jun 2016 05:06:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u5356Thp069926 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 3 Jun 2016 08:06:29 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u5356Thp069926 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u5356Swv069925; Fri, 3 Jun 2016 08:06:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 3 Jun 2016 08:06:28 +0300 From: Konstantin Belousov To: Maxim Sobolev Cc: FreeBSD Current Subject: Re: CLOCK_MONOTONIC / CLOCK_UPTIME is not really monotonic between threads Message-ID: <20160603050628.GV38613@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 05:06:44 -0000 On Thu, Jun 02, 2016 at 09:16:47PM -0700, Maxim Sobolev wrote: > Hi there, we have an application here which is trying to measure UDP > command/response round-trip-time. It runs two posix threads (more actually, > but that's probably irrelevant), one (let's call it A) that does high-level > logic and the second one (B) that does network packet I/O. > > The sending side is done by first thread A forming the request, then > calling the function clock_gettime(CLOCK_MONOTONIC) and passing the packet > into the thread B. Obtained timestamp is stored with some logical > transaction ID allowing us to pull that stored value later on when response > arrives. Then we have a separate process that receives those requests, > processing them and sending back some form of response. > > Upon receiving a response from the network, the network I/O thread (B) > timestamps it by running clock_gettime(CLOCK_MONOTONIC) and passes the > packet data along with that value via queue to the thread A for processing. > > So if we put things into timeline, what our app does would probably look > something like the following: > > 1. Thread A generates request. > 2. A calls clock_gettime(CLOCK_MONOTONIC), storing value as t1 internally > 3. A passes packet to thread B > 4. B sends out packet via sendto() to server process running on the same > box (fully separate, not a thread) > > [some microseconds later] > > 5. B receives response from server with recvfrom() > 6. B instantly calls clock_gettime(CLOCK_MONOTONIC), assigns returned value > to t2 > 7. B passes packet data along with t2 to the A via queue > 8. A picks up packet, parses it and retrieves corresponding t1 stored at > step 2. > 9. A calculates RTT by doing t2 - t1 assuming it's going to be positive... > > As you might have guessed if you are still reading, from time to time t2 - > t1 comes out slightly negative! Provided it's not some obscure bug in our > app, there is no way this could happen if clock_gettime(CLOCK_MONOTONIC) > would work as advertised. Event (2) could not possibly happen earlier than > (6), which is guaranteed by the fact that the request needs to be processed > by the external entity first in order for the response to be seen by our > app at all. I've added some logs and it seems to be confirming that the > server only sees a single request, there is no chance for the client to > receive some other packet and confuse it. I've also confirmed with tcpdump, > which shows reasonable time delay between request and reply of few hundreds > microseconds. > > I've checked all logic and I could not find any mistakes on my end here, so > I added some logging for such events. The distribution appears to be > centered around 0.00006s, but there are some events that go as far up as > 0.012s. > > I've also tried using CLOCK_UPTIME_PRECISE instead, but it makes no > difference whatsoever. > > My questions therefore are: > > 1. Is it intended/expected behavior of the said API? No. > 2. Has anyone else bumped into this? Not that I am aware of. > 3. I know we are doing some clever optimizations using TSC to speed those > APIs up, could be it related to that? No idea. > 4. If the answer for (3) is yes, then what is the method to disable using > TSC and use slower but possibly more reliable method? Set sysctl kern.timecounter.fast_gettime to 0. > 5. Is there any way/plan to fix this long-term? Fix what ? > 6. If the behavior is intended/expected, what is the maximum discrepancy we > can expect from this effect? > > In general some time ago we've spend quite lot of time switching our app > from using REALTIME into MONOTIME in the hope to eliminate any wizardry > needed to deal with realtime possibly jumping back and forth due to NTP, > leap seconds etc, it's shame that this is not working either. Apart from > measuring command processing delay, that app does lot of high-volume voip > call billing, so even such small discrepancy can easily build up into a > bigger problem, not to mention the fact that every time we deal with > duration we now need to have some check in place to make sure we don't have > some negative values popping our of nowhere. > > Any hints, suggestions, pointers are appreciated. I can also give more > debug information as needed. Thanks! In fact, your rather long mail does not contain any facts except a statement that you possibly see clock_gettime(CLOCK_MONOTONIC) going backward. First obvious question is whether you did tried to reduce the testcase to some usable size ? That said, RDTSC going backward, or perceive of RDTSC value by processors going provable backward, was one of the concerns when userspace gettimeofday(2) code was developed. We have at least three things which should prevent that: 1. kernel tests TSC for SMP coherency on boot 2. since RDTSC is not serialized instruction, we bracket its execution with neccessary CPU-model specific fences to ensure that the counter is not read too early. 3. still, despite item 2, at least 1 lowest bit of the read counter is dropped to accomodate for jitter. When testing the userspace gettimeofday(2) code, I found the following program by Ingo Molnar. It verifies SMP-coherency for the bare TSC and for the library routines. I specifically tested with it on multi-socket Nehalems at that time, AFAIR. I am not asking for details about your machine config, system version and other neccessary information, before either the Ingo' program demostrates the back-stepping, or you provide tiny test which shows the problem. /* * Copyright (C) 2005, Ingo Molnar * * time-warp-test.c: check TSC synchronity on x86 CPUs. Also detects * gettimeofday()-level time warps. * * Compile with: gcc -Wall -O2 -o time-warp-test time-warp-test.c -lrt * $Id: time-warp-test.c,v 1.1 2012/07/25 19:11:05 kostik Exp kostik $ */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #define TEST_TSC 1 #define TEST_TOD 1 #define TEST_CLOCK 1 #if !TEST_TSC && !TEST_TOD && !TEST_CLOCK # error this setting makes no sense ... #endif #if DEBUG # define Printf(x...) printf(x) #else # define Printf(x...) do { } while (0) #endif /* * Shared locks and variables between the test tasks: */ enum { SHARED_LOCK = 0, SHARED_TSC = 2, SHARED_TOD = 4, SHARED_CLOCK = 6, SHARED_WORST_TSC = 8, SHARED_WORST_TOD = 10, SHARED_WORST_CLOCK = 12, SHARED_NR_TSC_LOOPS = 14, SHARED_NR_TSC_WARPS = 16, SHARED_NR_TOD_LOOPS = 18, SHARED_NR_TOD_WARPS = 20, SHARED_NR_CLOCK_LOOPS = 22, SHARED_NR_CLOCK_WARPS = 24, SHARED_END = 26, }; #define SHARED(x) (*(shared + SHARED_##x)) #define SHARED_LL(x) (*(long long *)(shared + SHARED_##x)) #define BUG_ON(c) assert(!(c)) typedef unsigned long long cycles_t; typedef unsigned long long usecs_t; typedef unsigned long long u64; #ifdef __x86_64__ #define DECLARE_ARGS(val, low, high) unsigned low, high #define EAX_EDX_VAL(val, low, high) ((low) | ((u64)(high) << 32)) #define EAX_EDX_ARGS(val, low, high) "a" (low), "d" (high) #define EAX_EDX_RET(val, low, high) "=a" (low), "=d" (high) #else #define DECLARE_ARGS(val, low, high) unsigned long long val #define EAX_EDX_VAL(val, low, high) (val) #define EAX_EDX_ARGS(val, low, high) "A" (val) #define EAX_EDX_RET(val, low, high) "=A" (val) #endif static inline unsigned long long __rdtscll(void) { DECLARE_ARGS(val, low, high); #if 0 asm volatile(/*"cpuid;" "lfence;*/"rdtsc" : EAX_EDX_RET(val, low, high)); #else asm volatile("lfence;rdtsc;"/* shrd $8,%%edx,%%eax"*/ : EAX_EDX_RET(val, low, high)); #endif return EAX_EDX_VAL(val, low, high); } #define rdtscll(val) do { (val) = __rdtscll(); } while (0) #define rdtod(val) \ do { \ struct timeval tv; \ \ gettimeofday(&tv, NULL); \ (val) = tv.tv_sec * 1000000ULL + tv.tv_usec; \ } while (0) #define rdclock(val) \ do { \ struct timespec ts; \ \ clock_gettime(CLOCK_MONOTONIC, &ts); \ (val) = ts.tv_sec * 1000000000ULL + ts.tv_nsec; \ } while (0) static unsigned long *setup_shared_var(void) { char zerobuff [4096] = { 0, }; int ret, fd; unsigned long *buf; fd = creat(".tmp_mmap", 0700); BUG_ON(fd == -1); close(fd); fd = open(".tmp_mmap", O_RDWR|O_CREAT|O_TRUNC); BUG_ON(fd == -1); ret = write(fd, zerobuff, 4096); BUG_ON(ret != 4096); buf = (void *)mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); BUG_ON(buf == (void *)-1); close(fd); unlink(".tmp_mmap"); return buf; } static inline void lock(unsigned long *flag) { #if 0 __asm__ __volatile__( "1: lock; btsl $0,%0\n" "jc 1b\n" : "=g"(*flag) : : "memory"); #else __asm__ __volatile__( "1: lock; btsl $0,%0\n\t" "jnc 3f\n" "2: testl $1,%0\n\t" "je 1b\n\t" "rep ; nop\n\t" "jmp 2b\n" "3:" : "+m"(*flag) : : "memory"); #endif } static inline void unlock(unsigned long *flag) { #if 0 __asm__ __volatile__( "lock; btrl $0,%0\n" : "=g"(*flag) :: "memory"); __asm__ __volatile__("rep; nop"); #else __asm__ __volatile__("movl $0,%0; rep; nop" : "=g"(*flag) :: "memory"); #endif } static void print_status(unsigned long *shared) { const char progress[] = "\\|/-"; static unsigned long long sum_tsc_loops, sum_tod_loops, sum_clock_loops, sum_tod; static unsigned int count1, count2; static usecs_t prev_tod; usecs_t tod; if (!prev_tod) rdtod(prev_tod); count1++; if (count1 < 1000) return; count1 = 0; rdtod(tod); if (abs(tod - prev_tod) < 100000ULL) return; sum_tod += tod - prev_tod; sum_tsc_loops += SHARED_LL(NR_TSC_LOOPS); sum_tod_loops += SHARED_LL(NR_TOD_LOOPS); sum_clock_loops += SHARED_LL(NR_CLOCK_LOOPS); SHARED_LL(NR_TSC_LOOPS) = 0; SHARED_LL(NR_TOD_LOOPS) = 0; SHARED_LL(NR_CLOCK_LOOPS) = 0; if (TEST_TSC) printf(" | TSC: %.2fus, fail:%ld", (double)sum_tod/(double)sum_tsc_loops, SHARED(NR_TSC_WARPS)); if (TEST_TOD) printf(" | TOD: %.2fus, fail:%ld", (double)sum_tod/(double)sum_tod_loops, SHARED(NR_TOD_WARPS)); if (TEST_CLOCK) printf(" | CLK: %.2fus, fail:%ld", (double)sum_tod/(double)sum_clock_loops, SHARED(NR_CLOCK_WARPS)); prev_tod = tod; count2++; printf(" %c\r", progress[count2 & 3]); fflush(stdout); } static inline void test_TSC(unsigned long *shared) { #if TEST_TSC cycles_t t0, t1; long long delta; lock(&SHARED(LOCK)); rdtscll(t1); t0 = SHARED_LL(TSC); SHARED_LL(TSC) = t1; SHARED_LL(NR_TSC_LOOPS)++; unlock(&SHARED(LOCK)); delta = t1-t0; if (delta < 0) { lock(&SHARED(LOCK)); SHARED(NR_TSC_WARPS)++; if (delta < SHARED_LL(WORST_TSC)) { SHARED_LL(WORST_TSC) = delta; fprintf(stderr, "\rnew TSC-warp maximum: %9Ld cycles, %016Lx -> %016Lx\n", delta, t0, t1); } unlock(&SHARED(LOCK)); } if (!((unsigned long)t0 & 31)) asm volatile ("rep; nop"); #endif } static inline void test_TOD(unsigned long *shared) { #if TEST_TOD usecs_t T0, T1; long long delta; lock(&SHARED(LOCK)); rdtod(T1); T0 = SHARED_LL(TOD); SHARED_LL(TOD) = T1; SHARED_LL(NR_TOD_LOOPS)++; unlock(&SHARED(LOCK)); delta = T1-T0; if (delta < 0) { lock(&SHARED(LOCK)); SHARED(NR_TOD_WARPS)++; if (delta < SHARED_LL(WORST_TOD)) { SHARED_LL(WORST_TOD) = delta; fprintf(stderr, "\rnew TOD-warp maximum: %9Ld usecs, %016Lx -> %016Lx\n", delta, T0, T1); } unlock(&SHARED(LOCK)); } #endif } static inline void test_CLOCK(unsigned long *shared) { #if TEST_CLOCK usecs_t T0, T1; long long delta; lock(&SHARED(LOCK)); rdclock(T1); T0 = SHARED_LL(CLOCK); SHARED_LL(CLOCK) = T1; SHARED_LL(NR_CLOCK_LOOPS)++; unlock(&SHARED(LOCK)); delta = T1-T0; if (delta < 0) { lock(&SHARED(LOCK)); SHARED(NR_CLOCK_WARPS)++; if (delta < SHARED_LL(WORST_CLOCK)) { SHARED_LL(WORST_CLOCK) = delta; fprintf(stderr, "\rnew CLOCK-warp maximum: %9Ld nsecs, %016Lx -> %016Lx\n", delta, T0, T1); } unlock(&SHARED(LOCK)); } #endif } int main(int argc, char **argv) { int i, parent, me; unsigned long *shared; unsigned long cpus, tasks; cpus = sysconf(_SC_NPROCESSORS_CONF); if (argc > 2) { usage: fprintf(stderr, "usage: tsc-sync-test \n"); exit(-1); } if (argc == 2) { tasks = atol(argv[1]); if (!tasks) goto usage; } else tasks = cpus; printf("%ld CPUs, running %ld parallel test-tasks.\n", cpus, tasks); printf("checking for time-warps via:\n" #if TEST_TSC "- read time stamp counter (RDTSC) instruction (cycle resolution)\n" #endif #if TEST_TOD "- gettimeofday (TOD) syscall (usec resolution)\n" #endif #if TEST_CLOCK "- clock_gettime(CLOCK_MONOTONIC) syscall (nsec resolution)\n" #endif "\n" ); shared = setup_shared_var(); parent = getpid(); for (i = 1; i < tasks; i++) { if (!fork()) break; } me = getpid(); while (1) { int i; for (i = 0; i < 10; i++) test_TSC(shared); for (i = 0; i < 10; i++) test_TOD(shared); for (i = 0; i < 10; i++) test_CLOCK(shared); if (me == parent) print_status(shared); } return 0; } From owner-freebsd-current@freebsd.org Fri Jun 3 05:29:45 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0AF5DB686CA for ; Fri, 3 Jun 2016 05:29:45 +0000 (UTC) (envelope-from raycherng@gmail.com) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CF7A01985 for ; Fri, 3 Jun 2016 05:29:44 +0000 (UTC) (envelope-from raycherng@gmail.com) Received: by mail-io0-x22d.google.com with SMTP id k19so52367560ioi.3 for ; Thu, 02 Jun 2016 22:29:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+NK/Y9Nq+Gvs4xMUzUqKr+wOozDd2Pa6Z+jLsLwVqn4=; b=W++ITXiB06pKlIMCOU5GWgC5FHtuQvSEqDiYo2MCp2Vgp+8t0Y1w1MvkFGwQ10B4X8 b2pqC7WZjgSvb4EYrtLFzwRpIT1Mit8ES0ShTa95z//Q36I7DsITB46Y9tSYGaR9fqwn KEJtyv9OdzEG3ejfRsMBiv/ztgNdxXK+2hyy6iei4/FgKOBNEkk6Fq44/hJgObwuOqaw dA0E2bXLLAVlG5gZohT1mq869rk/41+Lk2yNOZwegQhrvNJNqIbyzpcD6jqvKehwnCig RFmQuJqXfz//41i/M2ondzqtGX/n6HFyrO3rMlRkxp4G3T9AQEB1I/7iitkWs1McOXAS fNWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+NK/Y9Nq+Gvs4xMUzUqKr+wOozDd2Pa6Z+jLsLwVqn4=; b=doxpc2V4rS6Zo7gnDWVCPK5Rh9IreZG2RM3Dy3ZmYVBTUSowKxuveYLkI/HOUUKF9F ExcOi8K95K1qN7QGXseK7ZB4wHAImPGVd7hvlmgaanV1XzdLq0n1+yIpyYvGkQd4x6sw buGhxX8f20aHRYDoxfTal4DaMd4TpxrMZRzy0rVjcfAaflViNFTSmFmK39rtkbcQdF9q DWsYAudA0ofoTsY9qmc2XBGwPsBhdiL9BmHql1tteZqOXujlsijAjN1x/KwvbpFKpU5/ Ougrj8EEGvZ7qHNSzC4kl8IMMmR0EUKLE9oviVhtqFqHBFa5QhUVwpHVGpeDt05L+35g 5GbQ== X-Gm-Message-State: ALyK8tLNxj39yP6XJ50UkgkHQM8rQ2M/XmOYx6elm2jsaMbqOqswL077Hm1zq3pn8Miv36gL2FU1CKMzUIlVVQ== X-Received: by 10.107.168.42 with SMTP id r42mr2488764ioe.179.1464931783953; Thu, 02 Jun 2016 22:29:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.151.7 with HTTP; Thu, 2 Jun 2016 22:29:43 -0700 (PDT) In-Reply-To: References: <0448c751-8608-51ce-f47e-76280ebf14f2@selasky.org> <20160602224654.18927083.ohartman@zedat.fu-berlin.de> From: RayCherng Yu Date: Fri, 3 Jun 2016 13:29:43 +0800 Message-ID: Subject: Re: Suddenly poweroff in 11-Current r300097 To: Kevin Oberman Cc: "O. Hartmann" , Hans Petter Selasky , FreeBSD Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 05:29:45 -0000 OK, thanks. I will load coretemp to monitor the cpu temperature. I have enabled powerd to have cpu frequency adjustment automatically. And it won't happen when AC power supply connected. 2016-06-03 8:08 GMT+08:00 Kevin Oberman : > On Thu, Jun 2, 2016 at 1:46 PM, O. Hartmann > wrote: > >> Am Thu, 2 Jun 2016 10:26:22 -0700 >> Kevin Oberman schrieb: >> >> > On Thu, Jun 2, 2016 at 7:41 AM, Hans Petter Selasky >> wrote: >> > >> > > On 06/02/16 03:07, RayCherng Yu wrote: >> > > >> > >> I got a suddenly poweroff in r300097 (and previous revision in Apri= l >> and >> > >> May) when I built textproc/docproj. >> > >> My machine is Macbook Pro 13 2011 early. I have checked the Apple >> website. >> > >> My bios is the latest version. >> > >> Actually it also happened in 10.3-STABLE. >> > >> It happened when the machine load was heavy. Before it shutdown, th= e >> fan >> > >> started to run very loudly. After several seconds (20 or 30 >> seconds), my >> > >> laptop shutdown (poweroff directly) suddenly. It seems not happen >> with the >> > >> AC power supply connected. >> > >> >> > >> I installed both Mac OSX and FreeBSD (dual boot). It never happened >> in Mac >> > >> OSX. >> > >> >> > >> My dmesg: >> > >> http://pastebin.com/QjZmbGCB >> > >> >> > >> My sysctl hw.acpi: >> > >> >> > >> hw.acpi.acline: 0 >> > >> hw.acpi.battery.info_expire: 5 >> > >> hw.acpi.battery.units: 1 >> > >> hw.acpi.battery.state: 1 >> > >> hw.acpi.battery.time: 87 >> > >> hw.acpi.battery.life: 59 >> > >> hw.acpi.cpu.cx_lowest: C8 >> > >> hw.acpi.reset_video: 0 >> > >> hw.acpi.handle_reboot: 1 >> > >> hw.acpi.disable_on_reboot: 0 >> > >> hw.acpi.verbose: 0 >> > >> hw.acpi.s4bios: 0 >> > >> hw.acpi.sleep_delay: 1 >> > >> hw.acpi.suspend_state: S3 >> > >> hw.acpi.standby_state: NONE >> > >> hw.acpi.lid_switch_state: NONE >> > >> hw.acpi.sleep_button_state: S3 >> > >> hw.acpi.power_button_state: S5 >> > >> hw.acpi.supported_sleep_state: S3 S4 S5 >> > >> >> > >> >> > > Hi, >> > > >> > > Do you have a temperature sysctl? Usually FreeBSD will shutdown the >> system >> > > if the ACPI temperature exceeds some value. Maybe it would be better >> to >> > > reduce the CPU load when the temperature goes up instead of facing a >> > > shutdown? >> > > >> > > --HPS >> > >> > >> > The relevant information is probably found in dev.cpu. That is where a= ll >> > temperature information is located as it is per-CPU, not per-system. O= f >> > particular interest is dev.cpu.0.cx_lowest, dev.cpu.0.cx_supported, an= d >> > dev.cpu.0.freq_levels. A snapshot of dev.cpu.0 when the fan has cranke= d >> up, >> > but before shutdown would be nice, too. >> > >> > I see no hw.acpi.thermal information. This is very odd. These values >> > indicate what the system will do and is doing if it starts getting too >> hot. >> > >> > Is coretemp loaded? It is required to see the core temperatures and >> those >> > are almost certainly significant. It may account for the lack of therm= al >> > information. Finally, a dmesg might be useful as it will tell us more >> about >> > just what thermal control techniques are enabled. >> > >> > Just to explain a bit on how this should work: when the temperature >> exceeds >> > some BIOS defined point, the system should "throttle" by pausing one o= f >> > every 8 clock cycles. If that does not fix the problem, the it rests f= or >> > two of every 8 and so on until the temperature is reduced. If it >> continues >> > to rise and reaches another BIOS set point, it will initiate an >> emergency >> > shutdown. If it reaches a CPU defined temperature, the power will shut >> off >> > immediately. Note that this is entirely a hardware function with no >> BIOS or >> > OS involvement. It should NEVER happen in normal operation as it is >> > triggered by a significant overtemp that threatens to destroy the CPU. >> I've >> > only seen it once when the CPU heat sink came loose on an old P4 syste= m >> > several years ago. >> > >> > I should mention that I have zero experience with Apple hardware and i= t >> is >> > possible that they do some things differently than I have seen on othe= r >> > hardware. >> > -- >> > Kevin Oberman, Part time kid herder and retired Network Engineer >> > E-mail: rkoberman@gmail.com >> > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 >> >> I have had such problems many times with older hardware. In most cases >> "dried out" >> thermal conductive pad or grease was the reason overheating the CPU du >> to a ineffective >> thermal conductivity from the CPU's surface to the heat spreader/cooler. >> I had recently >> two laptops with such a phenomenon - using high-quality thermal grease >> solved the problem >> for my. In both cases, the former high-viscous thermal grease has become >> like dry mud. >> Same with pads. >> > > Valid suggestion. If you have not worked with it, keep the layer of greas= e > as thin as possible. Use quality grease, not pads or tape. They just don'= t > work as well. Good silicone thermal grease should remain effective for at= a > minimum of 10 years. > > Also, clean your heat sinks! I clean the ones on my laptop about once a > year (I have to remove the keyboard to blow them out) and I see the > quiescent temperature drop by 10-15C and the temp under load can drop by > 20C. As active cooling works on my laptop, it does not overheat, but it > does slow down on "buildworld -j6" and building ports like chromium and > libreoffice. Very significant. > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkoberman@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > > --=20 "Life is like a snowball. The important thing is finding wet snow and a really long hill." "Price is what you pay. Value is what you get." "The first rule of Investing is don't lose money; the second rule is don't forget rule #1..." "Wall Street is the only place that people ride to work in a Rolls-Royce to get advice from those who take the subway..." =E2=80=94 Warren Buffett. From owner-freebsd-current@freebsd.org Fri Jun 3 06:44: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 5F7B6B684B5 for ; Fri, 3 Jun 2016 06:44:18 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::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 160D31D5B for ; Fri, 3 Jun 2016 06:44:18 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-io0-x22b.google.com with SMTP id o189so56356033ioe.2 for ; Thu, 02 Jun 2016 23:44:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=s67qIG5/rw/v8JLjgVKflwO4f8noA3v47RBkd7eExPQ=; b=UDfrug2igETGOWqtedkF7SCsx6RhCvfR0zMDnqqYGs5K4RNbVi5i3SM9/klcAiH5zE 4NZF6RHuhfCR/2GyV50KwtbSeDY5Omu8p1ea8m7tX6+5CESphZel+HAnvl6S20iiok9k h1nBy2Raecw4qVv8pD9WWrcHA6lWqQowLJN8gZmyc595+mlGni8pevCTRmijpKM6Uteo ax5ACXOPApnHzgyuGnTH+VaMLYYNPOWzwUty4SHcLR0DeVXg/Xdof9OUnmah7LVOxZ8h ojfyCS7LqbiOQrWGvN9NUH9on2g6rX68FwulvbBU6KUO0Bw11XRqch8WPKl/peGIw7Mk uk/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:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=s67qIG5/rw/v8JLjgVKflwO4f8noA3v47RBkd7eExPQ=; b=XRHGK+eXiSGF34YR0aAD8Fd8bPa9zZYdigIFie3lkATD8LqZ4G02epri7uWRK8RoE/ RMaKgSGfudnzIkcK2sDMP0r9HU2j3R4EQJDRx57zHuz8hEHI+GcDFWmBGwO9GIIUK0U8 FWENAnCtJpGlaDAPbMmgoto3RQEIhMI4ehnFVvjUsrQxMyK9WwlCrxZRGn7wKTcd5vQX 1+nSlohO1Afl/Qv97HTBgG1mKvbJhCwDe2r3gR0XiZEkkDQsbSTvU+qUHh2kn5nUqws/ a3wTfaGUm4wdkRW8E2RcsAm1gmE84oh3P1fXl4K994TBVfPz2PN82azvibN3oKD1zxAF j0iA== X-Gm-Message-State: ALyK8tK2WXlwp14XFbg33eSKFVtv66etiADUgxqxkQ3hmTVN09XseCqp9SSPZ0MZtZlPjiPKpzhEAT8QqM8WnA== MIME-Version: 1.0 X-Received: by 10.107.47.41 with SMTP id j41mr517557ioo.168.1464936257341; Thu, 02 Jun 2016 23:44:17 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.79.20.70 with HTTP; Thu, 2 Jun 2016 23:44:17 -0700 (PDT) In-Reply-To: References: <0448c751-8608-51ce-f47e-76280ebf14f2@selasky.org> <20160602224654.18927083.ohartman@zedat.fu-berlin.de> Date: Thu, 2 Jun 2016 23:44:17 -0700 X-Google-Sender-Auth: tl15xaFrTQpRxlqAxSkrdjFmuQE Message-ID: Subject: Re: Suddenly poweroff in 11-Current r300097 From: Kevin Oberman To: RayCherng Yu Cc: "O. Hartmann" , Hans Petter Selasky , FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 06:44:18 -0000 On Thu, Jun 2, 2016 at 10:29 PM, RayCherng Yu wrote: > OK, thanks. > I will load coretemp to monitor the cpu temperature. > I have enabled powerd to have cpu frequency adjustment automatically. And > it won't happen when AC power supply connected. > This is why I suspect the power profile or Cx-states are involved as they are, by default, different for AC and battery power. But, also by default, they should make things worse when on AC, so I may be quite wrong. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 From owner-freebsd-current@freebsd.org Fri Jun 3 10:09:48 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5D01FB66AC4; Fri, 3 Jun 2016 10:09:48 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from degoeje.nl (degoeje.nl [81.169.238.128]) by mx1.freebsd.org (Postfix) with ESMTP id 245B41878; Fri, 3 Jun 2016 10:09:47 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from [192.168.1.250] (unknown [188.203.228.182]) by degoeje.nl (Postfix) with ESMTPSA id 1BD4115C0025; Fri, 3 Jun 2016 12:09:39 +0200 (CEST) Subject: Re: CLOCK_MONOTONIC / CLOCK_UPTIME is not really monotonic between threads To: Maxim Sobolev , FreeBSD Current , freebsd-threads@freebsd.org, freebsd-questions@freebsd.org, freebsd-arch@freebsd.org References: From: Pieter de Goeje Message-ID: Date: Fri, 3 Jun 2016 12:09:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=3.5 tests=ALL_TRUSTED autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on degoeje.nl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 10:09:48 -0000 Op 2016-06-03 om 06:16 schreef Maxim Sobolev: > 4. If the answer for (3) is yes, then what is the method to disable using > TSC and use slower but possibly more reliable method? sysctl kern.timecounter.choice lists the available timers. sysctl kern.timecounter.hardware selects the timer. Changes take effect immediately. - Pieter From owner-freebsd-current@freebsd.org Fri Jun 3 12:35:39 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1532FB68516 for ; Fri, 3 Jun 2016 12:35:39 +0000 (UTC) (envelope-from patryk.kubiak@intel.com) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mx1.freebsd.org (Postfix) with ESMTP id E7121122B for ; Fri, 3 Jun 2016 12:35:38 +0000 (UTC) (envelope-from patryk.kubiak@intel.com) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga101.fm.intel.com with ESMTP; 03 Jun 2016 05:34:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,412,1459839600"; d="scan'208,217";a="115469000" Received: from irsmsx109.ger.corp.intel.com ([163.33.3.23]) by fmsmga004.fm.intel.com with ESMTP; 03 Jun 2016 05:34:19 -0700 Received: from irsmsx112.ger.corp.intel.com (10.108.20.5) by IRSMSX109.ger.corp.intel.com (163.33.3.23) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 3 Jun 2016 13:34:19 +0100 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.240]) by irsmsx112.ger.corp.intel.com ([10.108.20.5]) with mapi id 14.03.0248.002; Fri, 3 Jun 2016 13:34:19 +0100 From: "Kubiak, Patryk" To: "freebsd-current@freebsd.org" Subject: MMap in FreeBSD 11 Thread-Topic: MMap in FreeBSD 11 Thread-Index: AdG9lDCnIfVzVXMES4y63ywoXjqPTw== Date: Fri, 3 Jun 2016 12:34:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.180] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 12:35:39 -0000 Hi , I have question about mmap and /dev/mem in the FreeBSD 11. We found, that o= urs applications does not work correct in the 11 - there is a problem with = mapping physical memory via mmap and /dev/mem device - we are receiving "Pe= rmission Denied" error. Is there any important change in the new version, t= hat prohibits this operation, or it is just a bug in the OS or App? Regards, Patryk -------------------------------------------------------------------- Intel Technology Poland sp. z o.o. ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydz= ial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-31= 6 | Kapital zakladowy 200.000 PLN. Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata= i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wi= adomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiek= olwiek przegladanie lub rozpowszechnianie jest zabronione. This e-mail and any attachments may contain confidential material for the s= ole use of the intended recipient(s). If you are not the intended recipient= , please contact the sender and delete all copies; any review or distributi= on by others is strictly prohibited. From owner-freebsd-current@freebsd.org Fri Jun 3 14:28: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 3CF7BB6856C for ; Fri, 3 Jun 2016 14:28:33 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::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 02D871AAE for ; Fri, 3 Jun 2016 14:28:33 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-oi0-x233.google.com with SMTP id e72so129300040oib.1 for ; Fri, 03 Jun 2016 07:28:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=/R1r4y9qtKUG1dHzy0HWyVDbah0Oa/cO79CxNqLFass=; b=x279AAiC/I/Tnt/vlSykudYqoId3KDJnLN5N64dcBjybxaYicygHPAUQKlfU+XhtSp aYhkB/ZbVO8Ipc+u4kIANOl1fMs3QZH0MrGYpVzL5runJ5AF/uC7UD98TDg8+L95CwAA YlF+4Lru9l1OSOEmCXYgdE/MwWK3O5IQJ3weBYI3dKpwEiz1Kfvf+guniqyEAnBsrgs5 x+unrPYfDeNk4BQ+RQf+yYb9y1fB2PaAkRxmjgZjHxvDXZBn3qi0oVH+uhXbeYoWhjaz BgNiW/60SjOysNd8EljJEqG6myMfTxgiFcxYz2nkLXEQlwYmfVySzUspF9B+m/zc625O ga2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=/R1r4y9qtKUG1dHzy0HWyVDbah0Oa/cO79CxNqLFass=; b=PLczXtumuivgB0LrAvT3ISENrQ0I6Gfz5qMksoopoecXeDI5iZnsWM+L29NvohRpKz bfcwykJdMtdgW2UmAP8EybHBwkLZtAbhbEde3u7FrZ57xRILNYg4aIpA3TFrByek9AF+ +8X63wjVacetqMRr4m86Ae0lBAGoRYkwyd+i4x/EbVRIy6tMLr+VgN8P5TPNt7bgof90 MOAIy6MqcuU5jlEm7sh4SWMUJxXzq+CQiP+ZHl3dpjES3In3TY1ekpqgPsDBRDpn19kO w/D0KyJnbCzz9lcGEVkunoxK3OBIlIt9ygEKVsKOImXMHJ6Ab3Q0eEvFg+sFBYs55TZ5 hC7Q== X-Gm-Message-State: ALyK8tJUZhBmXOnIkh5ly0LrM5gQ3ZCb9iP23IV2kTnULEhwk4M1FgrX6cj/SWTAJb3JpEYByyTxnJozZiyBenCI X-Received: by 10.157.31.78 with SMTP id x14mr2143800otx.15.1464964112288; Fri, 03 Jun 2016 07:28:32 -0700 (PDT) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.157.56.70 with HTTP; Fri, 3 Jun 2016 07:28:31 -0700 (PDT) In-Reply-To: References: From: Maxim Sobolev Date: Fri, 3 Jun 2016 07:28:31 -0700 X-Google-Sender-Auth: _Ht2eSLKxKB2HEHmY-rA1U04kUI Message-ID: Subject: Re: CLOCK_MONOTONIC / CLOCK_UPTIME is not really monotonic between threads To: Adrian Chadd Cc: FreeBSD Current , freebsd-threads@freebsd.org, FreeBSD Questions , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 14:28:33 -0000 a. multiple cores. b. makes no difference c. yes, I believe so kern.timecounter.tsc_shift: 1 kern.timecounter.smp_tsc_adjust: 0 kern.timecounter.smp_tsc: 1 kern.timecounter.invariant_tsc: 1 machdep.tsc_freq: 2658118740 machdep.disable_tsc_calibration: 0 machdep.disable_tsc: 0 d. no, single socket Intel Q6700. I've also seen this problem on core i7-4770 running virtualbox 5.x. I have a hints that this also happens on our bigger production boxes, but I have no specifics yet. On Thu, Jun 2, 2016 at 10:05 PM, Adrian Chadd wrote: > [snip] > > a) is it on one core, or multiple cores? > b) CLOCK_MONOTONIC_FAST? > c) is it on a system that /has/ invariant-TSC ? > d) is this a multi-socket system? > > > > -adrian > > From owner-freebsd-current@freebsd.org Fri Jun 3 15:04: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 16A24B6921D for ; Fri, 3 Jun 2016 15:04:31 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003: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 D3AA418A2 for ; Fri, 3 Jun 2016 15:04:30 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-oi0-x230.google.com with SMTP id k23so131011901oih.0 for ; Fri, 03 Jun 2016 08:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=M9993WVoBZueHhqfKfMuDp6AqA9ZG0QH56AA9Pprkuc=; b=QRoKYoZ5IC7nsUo7G7NKEn5ppai/yONbQA7eGrIujRLXh8as+R7A92G/Nmtjva4lH3 yRx7nAxk6+/goquFswAddTBgwhh+J7BVh/bp0R3Jf85LVB6Pa8RP+33epF5nWukVPb7I r/0fdmbKOVchw0lqcTNNpe0Z5f5mj/ZVGJBir71hx4TPaB5k424zO9zuhAqe7kYsFOnq 0OId1tVknzpg/1FW20/8GIHphXnZMuACbWEdbLIFlz3npR0Put8Y21MjpstCWY+2V3yK 2RaV0sdkd5mPpyFY8s0DKCboHI+Mc3Gx/s3AWq1OOSpwx5RY+n9zODm4t3kWO51ZlG8A 7Qfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=M9993WVoBZueHhqfKfMuDp6AqA9ZG0QH56AA9Pprkuc=; b=J0Gq6mTOsjCC67u6HJhYN6ZEwHzrzwxIIn5Dh0mYnGMzdEbkwCuRnrjCEiH754F9f1 ofeqaBZjjFPI4dEPINAehjXFUWowW6KZ1rscdbZ0vQpfGR3rJbmyX4rbub9zHlaIxnsq wlTCA8yBCsWIctMA2R6kxT442LiF8Ji7vrxPIR7v23MS732iCRoGkAG6lLI4i9c2Xx6e k+w+BQu+JMVwxhn9JE9ED8FJo/SHFpI8F+LWV53zdFFJBf5vPlXjqDkZOeoFlz+wEm8/ ephMVu4VVUX0OZAx2DZJHfk1QlJfqnmn3nI5RCwFfYx329aL2TPRT0bvhSiBKr4pGbEc vJdA== X-Gm-Message-State: ALyK8tLAxUK9/vT+MckM2gi1AIciwjDuczryVhvSwgrcDiDzPzkk7GNw1FHRk4fFccrUDzd90rOzs8X8j1uPMVIT X-Received: by 10.202.96.68 with SMTP id u65mr1945090oib.83.1464966269971; Fri, 03 Jun 2016 08:04:29 -0700 (PDT) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.157.56.70 with HTTP; Fri, 3 Jun 2016 08:04:29 -0700 (PDT) In-Reply-To: <20160603050628.GV38613@kib.kiev.ua> References: <20160603050628.GV38613@kib.kiev.ua> From: Maxim Sobolev Date: Fri, 3 Jun 2016 08:04:29 -0700 X-Google-Sender-Auth: qt82J4SZPGy5EaHNGnCwg1KHXL8 Message-ID: Subject: Re: CLOCK_MONOTONIC / CLOCK_UPTIME is not really monotonic between threads To: Konstantin Belousov Cc: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 15:04:31 -0000 Konstantin, Thanks for taking your time looking into it and sorry for somewhat messy problem report. I've been trying to fix that problem all day yesterday thinking it's just application logic that is broken and indeed has been able to find some bigger issues that were obscuring this one. But it got very frustrating when the bug popped out anew at a seemingly lower level now. The issue that triggered this is in some high level python code. Which makes it quite difficult to narrow and isolate. There is still slight chance that it's something about threading within the python that screws this up somehow, however I don't quite see how that could lead to a consistent result that is just off by few hundred microseconds and not in some random garbage. So, I take from you message, that high level clock_gettime(CLOCK_MONOTONIC*) is supposed to be monotonic with respect to the wall time even when called in different threads? I always though it is, but was not 100% sure about that and wanted to confirm it before I dive deeper into this and spend more time writing a test case to expose this. The test case you gave me is interesting, but somewhat low-level. What I would do if it comes to it, is to make something that uses pthreads and plain clock_gettime(2). Should not be too difficult to reproduce if it's real issue. P.S. I've also tried kern.timecounter.fast_gettime=0, made no difference. Assuming it does not take a reboot to test it. Neither does switching kern.timecounter.hardware, I've tested TSC-low(1000) ACPI-fast(900) HPET(950) i8254(0), all are the same. In any case thanks for your valuable input, I think I have enough information for now to investigate it further. -Max On Jun 2, 2016 10:06 PM, "Konstantin Belousov" wrote: > On Thu, Jun 02, 2016 at 09:16:47PM -0700, Maxim Sobolev wrote: > > Hi there, we have an application here which is trying to measure UDP > > command/response round-trip-time. It runs two posix threads (more > actually, > > but that's probably irrelevant), one (let's call it A) that does > high-level > > logic and the second one (B) that does network packet I/O. > > > > The sending side is done by first thread A forming the request, then > > calling the function clock_gettime(CLOCK_MONOTONIC) and passing the > packet > > into the thread B. Obtained timestamp is stored with some logical > > transaction ID allowing us to pull that stored value later on when > response > > arrives. Then we have a separate process that receives those requests, > > processing them and sending back some form of response. > > > > Upon receiving a response from the network, the network I/O thread (B) > > timestamps it by running clock_gettime(CLOCK_MONOTONIC) and passes the > > packet data along with that value via queue to the thread A for > processing. > > > > So if we put things into timeline, what our app does would probably look > > something like the following: > > > > 1. Thread A generates request. > > 2. A calls clock_gettime(CLOCK_MONOTONIC), storing value as t1 internally > > 3. A passes packet to thread B > > 4. B sends out packet via sendto() to server process running on the same > > box (fully separate, not a thread) > > > > [some microseconds later] > > > > 5. B receives response from server with recvfrom() > > 6. B instantly calls clock_gettime(CLOCK_MONOTONIC), assigns returned > value > > to t2 > > 7. B passes packet data along with t2 to the A via queue > > 8. A picks up packet, parses it and retrieves corresponding t1 stored at > > step 2. > > 9. A calculates RTT by doing t2 - t1 assuming it's going to be > positive... > > > > As you might have guessed if you are still reading, from time to time t2 > - > > t1 comes out slightly negative! Provided it's not some obscure bug in our > > app, there is no way this could happen if clock_gettime(CLOCK_MONOTONIC) > > would work as advertised. Event (2) could not possibly happen earlier > than > > (6), which is guaranteed by the fact that the request needs to be > processed > > by the external entity first in order for the response to be seen by our > > app at all. I've added some logs and it seems to be confirming that the > > server only sees a single request, there is no chance for the client to > > receive some other packet and confuse it. I've also confirmed with > tcpdump, > > which shows reasonable time delay between request and reply of few > hundreds > > microseconds. > > > > I've checked all logic and I could not find any mistakes on my end here, > so > > I added some logging for such events. The distribution appears to be > > centered around 0.00006s, but there are some events that go as far up as > > 0.012s. > > > > I've also tried using CLOCK_UPTIME_PRECISE instead, but it makes no > > difference whatsoever. > > > > My questions therefore are: > > > > 1. Is it intended/expected behavior of the said API? > No. > > > 2. Has anyone else bumped into this? > Not that I am aware of. > > > 3. I know we are doing some clever optimizations using TSC to speed those > > APIs up, could be it related to that? > No idea. > > > 4. If the answer for (3) is yes, then what is the method to disable using > > TSC and use slower but possibly more reliable method? > Set sysctl kern.timecounter.fast_gettime to 0. > > > 5. Is there any way/plan to fix this long-term? > Fix what ? > > > 6. If the behavior is intended/expected, what is the maximum discrepancy > we > > can expect from this effect? > > > > In general some time ago we've spend quite lot of time switching our app > > from using REALTIME into MONOTIME in the hope to eliminate any wizardry > > needed to deal with realtime possibly jumping back and forth due to NTP, > > leap seconds etc, it's shame that this is not working either. Apart from > > measuring command processing delay, that app does lot of high-volume voip > > call billing, so even such small discrepancy can easily build up into a > > bigger problem, not to mention the fact that every time we deal with > > duration we now need to have some check in place to make sure we don't > have > > some negative values popping our of nowhere. > > > > Any hints, suggestions, pointers are appreciated. I can also give more > > debug information as needed. Thanks! > > In fact, your rather long mail does not contain any facts except a > statement > that you possibly see clock_gettime(CLOCK_MONOTONIC) going backward. First > obvious question is whether you did tried to reduce the testcase to some > usable size ? > > That said, RDTSC going backward, or perceive of RDTSC value by > processors going provable backward, was one of the concerns when > userspace gettimeofday(2) code was developed. We have at least three > things which should prevent that: > 1. kernel tests TSC for SMP coherency on boot > 2. since RDTSC is not serialized instruction, we bracket its execution > with neccessary CPU-model specific fences to ensure that the counter > is not read too early. > 3. still, despite item 2, at least 1 lowest bit of the read counter is > dropped to accomodate for jitter. > > When testing the userspace gettimeofday(2) code, I found the following > program by Ingo Molnar. It verifies SMP-coherency for the bare TSC and > for the library routines. I specifically tested with it on multi-socket > Nehalems at that time, AFAIR. > > I am not asking for details about your machine config, system version and > other neccessary information, before either the Ingo' program demostrates > the back-stepping, or you provide tiny test which shows the problem. > > /* > * Copyright (C) 2005, Ingo Molnar > * > * time-warp-test.c: check TSC synchronity on x86 CPUs. Also detects > * gettimeofday()-level time warps. > * > * Compile with: gcc -Wall -O2 -o time-warp-test time-warp-test.c -lrt > * $Id: time-warp-test.c,v 1.1 2012/07/25 19:11:05 kostik Exp kostik $ > */ > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > > #define TEST_TSC 1 > #define TEST_TOD 1 > #define TEST_CLOCK 1 > > #if !TEST_TSC && !TEST_TOD && !TEST_CLOCK > # error this setting makes no sense ... > #endif > > #if DEBUG > # define Printf(x...) printf(x) > #else > # define Printf(x...) do { } while (0) > #endif > > /* > * Shared locks and variables between the test tasks: > */ > enum { > SHARED_LOCK = 0, > SHARED_TSC = 2, > SHARED_TOD = 4, > SHARED_CLOCK = 6, > SHARED_WORST_TSC = 8, > SHARED_WORST_TOD = 10, > SHARED_WORST_CLOCK = 12, > SHARED_NR_TSC_LOOPS = 14, > SHARED_NR_TSC_WARPS = 16, > SHARED_NR_TOD_LOOPS = 18, > SHARED_NR_TOD_WARPS = 20, > SHARED_NR_CLOCK_LOOPS = 22, > SHARED_NR_CLOCK_WARPS = 24, > SHARED_END = 26, > }; > > #define SHARED(x) (*(shared + SHARED_##x)) > #define SHARED_LL(x) (*(long long *)(shared + SHARED_##x)) > > #define BUG_ON(c) assert(!(c)) > > typedef unsigned long long cycles_t; > typedef unsigned long long usecs_t; > typedef unsigned long long u64; > > #ifdef __x86_64__ > #define DECLARE_ARGS(val, low, high) unsigned low, high > #define EAX_EDX_VAL(val, low, high) ((low) | ((u64)(high) << 32)) > #define EAX_EDX_ARGS(val, low, high) "a" (low), "d" (high) > #define EAX_EDX_RET(val, low, high) "=a" (low), "=d" (high) > #else > #define DECLARE_ARGS(val, low, high) unsigned long long val > #define EAX_EDX_VAL(val, low, high) (val) > #define EAX_EDX_ARGS(val, low, high) "A" (val) > #define EAX_EDX_RET(val, low, high) "=A" (val) > #endif > > static inline unsigned long long __rdtscll(void) > { > DECLARE_ARGS(val, low, high); > > #if 0 > asm volatile(/*"cpuid;" "lfence;*/"rdtsc" : EAX_EDX_RET(val, low, > high)); > #else > asm volatile("lfence;rdtsc;"/* shrd $8,%%edx,%%eax"*/ : > EAX_EDX_RET(val, low, high)); > #endif > > return EAX_EDX_VAL(val, low, high); > } > > #define rdtscll(val) do { (val) = __rdtscll(); } while (0) > > #define rdtod(val) \ > do { \ > struct timeval tv; \ > \ > gettimeofday(&tv, NULL); \ > (val) = tv.tv_sec * 1000000ULL + tv.tv_usec; \ > } while (0) > > #define rdclock(val) \ > do { \ > struct timespec ts; \ > \ > clock_gettime(CLOCK_MONOTONIC, &ts); \ > (val) = ts.tv_sec * 1000000000ULL + ts.tv_nsec; \ > } while (0) > > static unsigned long *setup_shared_var(void) > { > char zerobuff [4096] = { 0, }; > int ret, fd; > unsigned long *buf; > > fd = creat(".tmp_mmap", 0700); > BUG_ON(fd == -1); > close(fd); > > fd = open(".tmp_mmap", O_RDWR|O_CREAT|O_TRUNC); > BUG_ON(fd == -1); > ret = write(fd, zerobuff, 4096); > BUG_ON(ret != 4096); > > buf = (void *)mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, > 0); > BUG_ON(buf == (void *)-1); > > close(fd); > unlink(".tmp_mmap"); > > return buf; > } > > static inline void lock(unsigned long *flag) > { > #if 0 > __asm__ __volatile__( > "1: lock; btsl $0,%0\n" > "jc 1b\n" > : "=g"(*flag) : : "memory"); > #else > __asm__ __volatile__( > "1: lock; btsl $0,%0\n\t" > "jnc 3f\n" > "2: testl $1,%0\n\t" > "je 1b\n\t" > "rep ; nop\n\t" > "jmp 2b\n" > "3:" > : "+m"(*flag) : : "memory"); > #endif > } > > static inline void unlock(unsigned long *flag) > { > #if 0 > __asm__ __volatile__( > "lock; btrl $0,%0\n" > : "=g"(*flag) :: "memory"); > __asm__ __volatile__("rep; nop"); > #else > __asm__ __volatile__("movl $0,%0; rep; nop" : "=g"(*flag) :: > "memory"); > #endif > } > > static void print_status(unsigned long *shared) > { > const char progress[] = "\\|/-"; > > static unsigned long long sum_tsc_loops, sum_tod_loops, > sum_clock_loops, > sum_tod; > static unsigned int count1, count2; > static usecs_t prev_tod; > > usecs_t tod; > > if (!prev_tod) > rdtod(prev_tod); > > count1++; > if (count1 < 1000) > return; > count1 = 0; > > rdtod(tod); > if (abs(tod - prev_tod) < 100000ULL) > return; > > sum_tod += tod - prev_tod; > sum_tsc_loops += SHARED_LL(NR_TSC_LOOPS); > sum_tod_loops += SHARED_LL(NR_TOD_LOOPS); > sum_clock_loops += SHARED_LL(NR_CLOCK_LOOPS); > SHARED_LL(NR_TSC_LOOPS) = 0; > SHARED_LL(NR_TOD_LOOPS) = 0; > SHARED_LL(NR_CLOCK_LOOPS) = 0; > > if (TEST_TSC) > printf(" | TSC: %.2fus, fail:%ld", > (double)sum_tod/(double)sum_tsc_loops, > SHARED(NR_TSC_WARPS)); > > if (TEST_TOD) > printf(" | TOD: %.2fus, fail:%ld", > (double)sum_tod/(double)sum_tod_loops, > SHARED(NR_TOD_WARPS)); > > if (TEST_CLOCK) > printf(" | CLK: %.2fus, fail:%ld", > (double)sum_tod/(double)sum_clock_loops, > SHARED(NR_CLOCK_WARPS)); > > prev_tod = tod; > count2++; > printf(" %c\r", progress[count2 & 3]); > fflush(stdout); > } > > static inline void test_TSC(unsigned long *shared) > { > #if TEST_TSC > cycles_t t0, t1; > long long delta; > > lock(&SHARED(LOCK)); > rdtscll(t1); > t0 = SHARED_LL(TSC); > SHARED_LL(TSC) = t1; > SHARED_LL(NR_TSC_LOOPS)++; > unlock(&SHARED(LOCK)); > > delta = t1-t0; > if (delta < 0) { > lock(&SHARED(LOCK)); > SHARED(NR_TSC_WARPS)++; > if (delta < SHARED_LL(WORST_TSC)) { > SHARED_LL(WORST_TSC) = delta; > fprintf(stderr, "\rnew TSC-warp maximum: %9Ld > cycles, %016Lx -> %016Lx\n", > delta, t0, t1); > } > unlock(&SHARED(LOCK)); > } > if (!((unsigned long)t0 & 31)) > asm volatile ("rep; nop"); > #endif > } > > static inline void test_TOD(unsigned long *shared) > { > #if TEST_TOD > usecs_t T0, T1; > long long delta; > > lock(&SHARED(LOCK)); > rdtod(T1); > T0 = SHARED_LL(TOD); > SHARED_LL(TOD) = T1; > SHARED_LL(NR_TOD_LOOPS)++; > unlock(&SHARED(LOCK)); > > delta = T1-T0; > if (delta < 0) { > lock(&SHARED(LOCK)); > SHARED(NR_TOD_WARPS)++; > if (delta < SHARED_LL(WORST_TOD)) { > SHARED_LL(WORST_TOD) = delta; > fprintf(stderr, "\rnew TOD-warp maximum: %9Ld > usecs, %016Lx -> %016Lx\n", > delta, T0, T1); > } > unlock(&SHARED(LOCK)); > } > #endif > } > > static inline void test_CLOCK(unsigned long *shared) > { > #if TEST_CLOCK > usecs_t T0, T1; > long long delta; > > lock(&SHARED(LOCK)); > rdclock(T1); > T0 = SHARED_LL(CLOCK); > SHARED_LL(CLOCK) = T1; > SHARED_LL(NR_CLOCK_LOOPS)++; > unlock(&SHARED(LOCK)); > > delta = T1-T0; > if (delta < 0) { > lock(&SHARED(LOCK)); > SHARED(NR_CLOCK_WARPS)++; > if (delta < SHARED_LL(WORST_CLOCK)) { > SHARED_LL(WORST_CLOCK) = delta; > fprintf(stderr, "\rnew CLOCK-warp maximum: %9Ld > nsecs, %016Lx -> %016Lx\n", > delta, T0, T1); > } > unlock(&SHARED(LOCK)); > } > #endif > } > > int main(int argc, char **argv) > { > int i, parent, me; > unsigned long *shared; > unsigned long cpus, tasks; > > cpus = sysconf(_SC_NPROCESSORS_CONF); > > if (argc > 2) { > usage: > fprintf(stderr, > "usage: tsc-sync-test \n"); > exit(-1); > } > if (argc == 2) { > tasks = atol(argv[1]); > if (!tasks) > goto usage; > } else > tasks = cpus; > > printf("%ld CPUs, running %ld parallel test-tasks.\n", cpus, > tasks); > printf("checking for time-warps via:\n" > #if TEST_TSC > "- read time stamp counter (RDTSC) instruction (cycle > resolution)\n" > #endif > #if TEST_TOD > "- gettimeofday (TOD) syscall (usec resolution)\n" > #endif > #if TEST_CLOCK > "- clock_gettime(CLOCK_MONOTONIC) syscall (nsec resolution)\n" > #endif > "\n" > ); > shared = setup_shared_var(); > > parent = getpid(); > > for (i = 1; i < tasks; i++) { > if (!fork()) > break; > } > me = getpid(); > > while (1) { > int i; > > for (i = 0; i < 10; i++) > test_TSC(shared); > for (i = 0; i < 10; i++) > test_TOD(shared); > for (i = 0; i < 10; i++) > test_CLOCK(shared); > > if (me == parent) > print_status(shared); > } > > return 0; > } > > From owner-freebsd-current@freebsd.org Fri Jun 3 15:29: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 ACB8CB69800; Fri, 3 Jun 2016 15:29:18 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi0-x242.google.com (mail-oi0-x242.google.com [IPv6:2607:f8b0:4003:c06::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7228017EE; Fri, 3 Jun 2016 15:29:18 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi0-x242.google.com with SMTP id x130so17698796oia.3; Fri, 03 Jun 2016 08:29:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=R8j3nmiecM0IH9E9VcTwWXH3zVzgN1N9NL7TEGAnt7w=; b=ixob1NJUyj3njv9m6BAEO+3izmb17p3tN8uAcxkq08KZJ6r+kGHlfUQjIamym28RV+ z0I8BDbD1ynbI0/pkM52fbU6d8Tdo7B+Q2VSjr2+Z7ML1KmJNYQweUbT1wA57DP9VqB/ BM7wD6eEeSzBuj5eAVtNt0CXO7qiLIK7gZFp68VpchTe4Ir79BWucOpqrJE5UEcbNEEQ 8t+wPYwTFd5tgRkV+FyEaPo9Vu7P0N0JB92iq8kGqv8gGGNQPN7x2FKrlyrUdIlUe+FC 1R0qItA3kDgPaaM7EDBCciumdbsnzJBwRiPUVC5fBsZZyrX+860I/1UYH8aXYKFtBUJ/ yqmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=R8j3nmiecM0IH9E9VcTwWXH3zVzgN1N9NL7TEGAnt7w=; b=ITZpQMtnjXHVLG9hHTp/0TsarjSCG8vpN5LbyhPwImdOx4fDMRS0sjnx5a/SgCpVZj G29J84irKakymdetSH7NRbyAK9PIcHy2F+u2T6AEyj05o1AuXE+kJFeU+2u3iayI1Aet i3bjAlbLONPlbV3BS0cGxBtkXJ/+H05M6GwaFEL64JSB267J6Y1K54tmVt/KscVekYgc Mp4vDYroppmE/081qAiSK68DYk/jO7QAmr0jvdZaOrTgitQWS9W2KXKDY0oPVXzXWYhC Qn1CCfdQiJLdJseJNaklb/zpBImnRfL4CC69Vo5vee9MYhvj8UhaVuelzXIkFCRkKyss lFQw== X-Gm-Message-State: ALyK8tItL05yk6dpGYA73CVD6Xf2bWfUjj0E6F9nYfXptxldpQWXSwyzk+J/0964DPyIRu2unSGgcg0nznyTuQ== X-Received: by 10.157.29.177 with SMTP id y46mr2129684otd.164.1464967757168; Fri, 03 Jun 2016 08:29:17 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.202.4.200 with HTTP; Fri, 3 Jun 2016 08:29:16 -0700 (PDT) In-Reply-To: <53ECFDC8.1070200@rice.edu> References: <20140627125613.GT93733@kib.kiev.ua> <201408121409.40653.jhb@freebsd.org> <201408141147.45698.jhb@freebsd.org> <53ECFDC8.1070200@rice.edu> From: Alan Somers Date: Fri, 3 Jun 2016 09:29:16 -0600 X-Google-Sender-Auth: tL4nuLltg764HZURpLYW5yVGUBo Message-ID: Subject: Re: PostgreSQL performance on FreeBSD To: Alan Cox Cc: John Baldwin , alc@freebsd.org, Konstantin Belousov , Adrian Chadd , freebsd-current , performance@freebsd.org, "current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 15:29:18 -0000 On Thu, Aug 14, 2014 at 12:19 PM, Alan Cox wrote: > On 08/14/2014 10:47, John Baldwin wrote: >> On Wednesday, August 13, 2014 1:00:22 pm Alan Cox wrote: >>> On Tue, Aug 12, 2014 at 1:09 PM, John Baldwin wrote: >>> >>>> On Wednesday, July 16, 2014 1:52:45 pm Adrian Chadd wrote: >>>>> Hi! >>>>> >>>>> >>>>> On 16 July 2014 06:29, Konstantin Belousov wrote: >>>>>> On Fri, Jun 27, 2014 at 03:56:13PM +0300, Konstantin Belousov wrote: >>>>>>> Hi, >>>>>>> I did some measurements and hacks to see about the performance and >>>>>>> scalability of PostgreSQL 9.3 on FreeBSD, sponsored by The FreeBSD >>>>>>> Foundation. >>>>>>> >>>>>>> The results are described in https://kib.kiev.ua/kib/pgsql_perf.pdf. >>>>>>> The uncommitted patches, referenced in the article, are available as >>>>>>> https://kib.kiev.ua/kib/pig1.patch.txt >>>>>>> https://kib.kiev.ua/kib/patch-2 >>>>>> A followup to the original paper. >>>>>> >>>>>> Most importantly, I identified the cause for the drop on the graph >>>>>> after the 30 clients, which appeared to be the debugging version >>>>>> of malloc(3) in libc. >>>>>> >>>>>> Also there are some updates on the patches. >>>>>> >>>>>> New version of the paper is available at >>>>>> https://www.kib.kiev.ua/kib/pgsql_perf_v2.0.pdf >>>>>> The changes are marked as 'update for version 2.0'. >>>>> Would you mind trying a default (non-PRODUCTION) build, but with junk >>>>> filling turned off? >>>>> >>>>> adrian@adrian-hackbox:~ % ls -l /etc/malloc.conf >>>>> >>>>> lrwxr-xr-x 1 root wheel 10 Jun 24 04:37 /etc/malloc.conf -> junk:false >>>>> >>>>> That fixes almost all of the malloc debug performance issues that I >>>>> see without having to recompile. >>>>> >>>>> I'd like to know if you see any after that. >>>> OTOH, I have actually seen junk profiling _improve_ performance in certain >>>> cases as it forces promotion of allocated pages to superpages since all >>>> pages >>>> are dirtied. (I have a local hack that adds a new malloc option to >>>> explicitly >>>> memset() new pages allocated via mmap() that gives the same benefit without >>>> the junking overheadon each malloc() / free(), but it does increase >>>> physical >>>> RAM usage.) >>>> >>>> >>> John, >>> >>> A couple small steps have been taken toward eliminating the need for this >>> hack: the addition of the "page size index" field to struct vm_page and the >>> addition of a similarly named parameter to pmap_enter(). However, at the >>> moment, the only tangible effect is in the automatic prefaulting by >>> mmap(2). Instead of establishing 96 4KB page mappings, the automatic >>> prefaulting establishes 96 page mappings whose size is determined by the >>> size of the physical pages that it finds in the vm object. So, the >>> prefaulting overhead remains constant, but the coverage provided by the >>> automatic prefaulting will vary with the underlying page size. >> Yes, I think what we might actually want is what I mentioned in person at >> BSDCan: some sort of flag to mmap() that malloc() could use to assume that any >> reservations are fully used when they are reserved. This would avoid the need >> to wait for all pages to be dirtied before promotion provides a superpage >> mapping and would avoid demotions while still allowing the kernel to gracefully >> fall back to regular pages if a reservation can't be made. >> > > I agree. I notice that, with the exception of the VM_PHYSSEG_MAX change, these patches never made it into head or ports. Are they unsuitable for low core-count machines, or is there some other reason not to commit them? If not, what would it take to get these into 11.0 or 11.1 ? -Alan From owner-freebsd-current@freebsd.org Fri Jun 3 15:57: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 43381B68159 for ; Fri, 3 Jun 2016 15:57:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0F0781B91 for ; Fri, 3 Jun 2016 15:57:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-it0-x22d.google.com with SMTP id i127so1660694ita.1 for ; Fri, 03 Jun 2016 08:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=SDQP1VhedifBgRd7WBhw3httGg/WsVtr2iKZv1thtME=; b=wplcgN/0g2oOaqODAojHJkY7pnzWQCWpekQ+8zkq8vy4NKxRLl2cFzY0CjijnPae1j vbkxyrOiPTQiggzKHOxGDwYY59jgl1xLpme6UmP6Le/JteCFoYfdFE7gCS5PcxqyZnY2 8VvU0M+OVK+o+ehOKGU1EUHuRCiizTS1P/QQ7Dc5vc8gYpe8jIP5Z6Iha/hfERZjopIp 71UVfl1gJEY0xtzQGN0K79Ko3mUsyF68fllY5d6Rx3kaI25fPoddOdupbO+aKKRuWbuU ykytOeO1r/0isjM6oKEPNyR+19vfJS07JwtzN6NDki/zGr4lkaLoz8CV+bWLK9+BKVSG gKZA== 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-transfer-encoding; bh=SDQP1VhedifBgRd7WBhw3httGg/WsVtr2iKZv1thtME=; b=eAUYnmZ4TBYssNXK9l2WYcbufNwKLxuCnOYXFTIwhfSvhCDUol05JC2xpk/2vJk6sP ncbSub63K5qXXimX+83wpPN2MAe4hJ2/Ql4DCkG9VEQCoO+11F5VvDAfVTv6ahiDoWNF b8JIY16vpAh0C9nRGRQDdv3stNXp3oN0YM3DMj4CudknqzZeMcuFyKPPcAy8yNVrdPzc V0fGyPeZgNodcHF/hWX4owltzjh73v1O8p/Cj8AAzWs3roKLNOEMPA9w7OtZhRKhyiu8 Lt7dCu+/c/AF5P6h4moEZgjO3z72i1xcKEgEXmz/64/8Bm1wxZETVq8pea1U6zGpawuL 9rsA== X-Gm-Message-State: ALyK8tJR9jZP2tJxBR9unG7qfj9wjn5UD1xA0JXwT+Cly3YKmiNJ8YSvBTeY2IuIvgnDRD9/0Qq4iiPorTmlXQ== X-Received: by 10.36.81.79 with SMTP id s76mr344565ita.71.1464969471385; Fri, 03 Jun 2016 08:57:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.113.3 with HTTP; Fri, 3 Jun 2016 08:57:50 -0700 (PDT) In-Reply-To: References: From: Adrian Chadd Date: Fri, 3 Jun 2016 08:57:50 -0700 Message-ID: Subject: Re: MMap in FreeBSD 11 To: "Kubiak, Patryk" Cc: "freebsd-current@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 15:57:52 -0000 On 3 June 2016 at 05:34, Kubiak, Patryk wrote: > Hi , > > I have question about mmap and /dev/mem in the FreeBSD 11. We found, that= ours applications does not work correct in the 11 - there is a problem wit= h mapping physical memory via mmap and /dev/mem device - we are receiving "= Permission Denied" error. Is there any important change in the new version,= that prohibits this operation, or it is just a bug in the OS or App? Can you provide any further information? Maybe some example code? -adrian > Regards, > Patryk > -------------------------------------------------------------------- > > Intel Technology Poland sp. z o.o. > ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wy= dzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-= 316 | Kapital zakladowy 200.000 PLN. > > Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresa= ta i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej = wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jaki= ekolwiek > przegladanie lub rozpowszechnianie jest zabronione. > This e-mail and any attachments may contain confidential material for the= sole use of the intended recipient(s). If you are not the intended recipie= nt, please contact the sender and delete all copies; any review or distribu= tion by > others is strictly prohibited. > _______________________________________________ > 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 Jun 3 16:49: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 C04E3B68FEB for ; Fri, 3 Jun 2016 16:49:44 +0000 (UTC) (envelope-from vangyzen@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 B1B571C1A for ; Fri, 3 Jun 2016 16:49:44 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id AD672B68FEA; Fri, 3 Jun 2016 16:49:44 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AACD4B68FE9 for ; Fri, 3 Jun 2016 16:49:44 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) by mx1.freebsd.org (Postfix) with ESMTP id 9113A1C19 for ; Fri, 3 Jun 2016 16:49:44 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from sweettea.beer.town (unknown [76.164.8.130]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 098555648F for ; Fri, 3 Jun 2016 11:49:44 -0500 (CDT) To: "current@freebsd.org" From: Eric van Gyzen Subject: No debug info for statically linked stuff Message-ID: <066b3552-7961-c6ac-fa12-b8379fc71d0c@FreeBSD.org> Date: Fri, 3 Jun 2016 11:49:39 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 16:49:44 -0000 I'm running head from Tuesday (r301045). I just noticed that "ar" is missing the debuginfo for libarchive: $ /usr/local/bin/gdb /usr/bin/ar GNU gdb (GDB) 7.11 [GDB v7.11 for FreeBSD] [...] Reading symbols from /usr/bin/ar...Reading symbols from /usr/lib/debug//usr/bin/ar.debug...done. done. (gdb) ptype struct archive No struct type named archive. (gdb) p archive_write_open_filename $1 = {} 0x406be0 Is this a known issue? Has libarchive.a already been stripped when ar is linked? Eric From owner-freebsd-current@freebsd.org Fri Jun 3 17:12: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 2BFCFB69719 for ; Fri, 3 Jun 2016 17:12:40 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 0EAEC1DD6 for ; Fri, 3 Jun 2016 17:12:40 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 0DC5BB69718; Fri, 3 Jun 2016 17:12:40 +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 0D752B69717 for ; Fri, 3 Jun 2016 17:12:40 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CBC731DD4; Fri, 3 Jun 2016 17:12:39 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io0-x22a.google.com with SMTP id p194so80740345iod.1; Fri, 03 Jun 2016 10:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=nn7ckRuBZG8BSCTaXxuK40a8Z4brgP/jKv0KpMBLRKU=; b=WTuXKgMMgMOdWfJPDlJWQntn+uU2TGt+LOnSmHwxGR43VNHd5RYIEbqQhHrplMZYIX /x7rpX6+vYPxW0Tq6er+uV+DkOob6ntijcXq0O/exkoxd3ucLRsscsTzyTmPlk2xymrk 1vG7zRhHXPYmTE1p3oBDkzUlHrkcTNQv5VIYaTj7LlFK91gJf7CLj9YGW4oFuIRiLfbs 6qn4ltdcoLzJ8hrAMvQq/UfmxsVv75SVSD2KOAyTfiwuDv9WGzPKzct2eeCOHhQrneks 2h/twFmsxuPLvwIrMwFA0oNBMcZ0uf5Y/RgeXpmv1JwlrnDHJe5G6IUZ+pypPjvIeCLf SWOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=nn7ckRuBZG8BSCTaXxuK40a8Z4brgP/jKv0KpMBLRKU=; b=mY7VWg/DXDaYbz9G0S8LOueOplCxHc769NCPOFPiFbAiLSVFtFIBTbzAd6N2QeUw4E hybj1JvxRh/BsiwFBMnjFOrnle7xzwDN2jm0Q5A7Xw3aBZk6dEcumUDkG4jkKBTCzjmg /uHl+Guyg4idw2ApPuUH03FEQn4WmBwBaOfViIc6cpd+4bxDZAa95YAtTrbEsqn3EzgA fl9egaTEBC18RQhpyJJ4qYwShYvUBvJqQ55rFaa/X6xv0FgjYqkPk8xJnkMcYDkL/laD HJku8HTIZ4iFe+K0UNNUME8MOd/9XybJI9GQX41Aagv/xNJihopwbnhfbxDCWzq8hxEH fdJw== X-Gm-Message-State: ALyK8tJ2P9UKeeRVFRDAU+YGnCR62qjv4djyoU7hMqp0PZ6PGCGpiA5y7rUd6nmgwL/OKTjqNqyOW0yx38ODMg== X-Received: by 10.107.159.84 with SMTP id i81mr6405723ioe.29.1464973958924; Fri, 03 Jun 2016 10:12:38 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.27.197 with HTTP; Fri, 3 Jun 2016 10:12:18 -0700 (PDT) In-Reply-To: <066b3552-7961-c6ac-fa12-b8379fc71d0c@FreeBSD.org> References: <066b3552-7961-c6ac-fa12-b8379fc71d0c@FreeBSD.org> From: Ed Maste Date: Fri, 3 Jun 2016 13:12:18 -0400 X-Google-Sender-Auth: i616YfM0Cbwq9qfb-aQbcuNlArE Message-ID: Subject: Re: No debug info for statically linked stuff To: Eric van Gyzen Cc: "current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 17:12:40 -0000 On 3 June 2016 at 12:49, Eric van Gyzen wrote: > I'm running head from Tuesday (r301045). I just noticed that "ar" is > missing the debuginfo for libarchive: I discussed this with Eric off this thread, but for the sake of others this is happening because WITH_DEBUG_FILES enables -g when building binaries and shared libs, but doesn't make any change for static libraries. Presumably we want WITH_DEBUG_FILES to just enable -g when building static libs as well (and avoid stripping on install). Probably need to leave it disabled for the Clang/LLVM/LLDB libs, because enabling that would add a significant amount of time to buildworld. I think GNU ld 2.17.50 might not even be able to link a debug build of Clang on i386. From owner-freebsd-current@freebsd.org Fri Jun 3 17:13: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 D9D86B697BA; Fri, 3 Jun 2016 17:13:21 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C5DE91F14; Fri, 3 Jun 2016 17:13:21 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1464973993043178.94664369864552; Fri, 3 Jun 2016 10:13:13 -0700 (PDT) Date: Fri, 03 Jun 2016 10:13:12 -0700 From: Matthew Macy To: "Alan Somers" Cc: "Alan Cox" , "John Baldwin" , "" , "Konstantin Belousov" , "Adrian Chadd" , "freebsd-current" , "" , "current@freebsd.org" Message-ID: <15517412419.c1e94b0289020.2514233510095214876@nextbsd.org> In-Reply-To: References: <20140627125613.GT93733@kib.kiev.ua> <201408121409.40653.jhb@freebsd.org> <201408141147.45698.jhb@freebsd.org> <53ECFDC8.1070200@rice.edu> Subject: Re: PostgreSQL performance on FreeBSD MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 17:13:22 -0000 > >>> A couple small steps have been taken toward eliminating the need for this > >>> hack: the addition of the "page size index" field to struct vm_page and the > >>> addition of a similarly named parameter to pmap_enter(). However, at the > >>> moment, the only tangible effect is in the automatic prefaulting by > >>> mmap(2). Instead of establishing 96 4KB page mappings, the automatic > >>> prefaulting establishes 96 page mappings whose size is determined by the > >>> size of the physical pages that it finds in the vm object. So, the > >>> prefaulting overhead remains constant, but the coverage provided by the > >>> automatic prefaulting will vary with the underlying page size. > >> Yes, I think what we might actually want is what I mentioned in person at > >> BSDCan: some sort of flag to mmap() that malloc() could use to assume that any > >> reservations are fully used when they are reserved. This would avoid the need > >> to wait for all pages to be dirtied before promotion provides a superpage > >> mapping and would avoid demotions while still allowing the kernel to gracefully > >> fall back to regular pages if a reservation can't be made. > >> > > > > I agree. > > I notice that, with the exception of the VM_PHYSSEG_MAX change, these > patches never made it into head or ports. Are they unsuitable for low > core-count machines, or is there some other reason not to commit them? > If not, what would it take to get these into 11.0 or 11.1 ? > I think the two big issues are: a) there's a lot more work that needs to be done b) Adrian has had a lot of other things on his plate in the meantime. Adrian is hoping to get back to it post 11.0-RELEASE. From owner-freebsd-current@freebsd.org Fri Jun 3 17:18: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 316B9B699AF for ; Fri, 3 Jun 2016 17:18:17 +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 A541C1245; Fri, 3 Jun 2016 17:18:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u53HI9t0098921 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 3 Jun 2016 20:18:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u53HI9t0098921 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u53HI9QL098920; Fri, 3 Jun 2016 20:18:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 3 Jun 2016 20:18:09 +0300 From: Konstantin Belousov To: Maxim Sobolev Cc: FreeBSD Current Subject: Re: CLOCK_MONOTONIC / CLOCK_UPTIME is not really monotonic between threads Message-ID: <20160603171809.GX38613@kib.kiev.ua> References: <20160603050628.GV38613@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 17:18:17 -0000 On Fri, Jun 03, 2016 at 08:04:29AM -0700, Maxim Sobolev wrote: > Konstantin, > > Thanks for taking your time looking into it and sorry for somewhat messy > problem report. I've been trying to fix that problem all day yesterday > thinking it's just application logic that is broken and indeed has been > able to find some bigger issues that were obscuring this one. But it got > very frustrating when the bug popped out anew at a seemingly lower level > now. The issue that triggered this is in some high level python code. Which > makes it quite difficult to narrow and isolate. There is still slight > chance that it's something about threading within the python that screws > this up somehow, however I don't quite see how that could lead to a > consistent result that is just off by few hundred microseconds and not in > some random garbage. > > So, I take from you message, that high level > clock_gettime(CLOCK_MONOTONIC*) is supposed to be monotonic with respect to > the wall time even when called in different threads? I always though it is, > but was not 100% sure about that and wanted to confirm it before I dive > deeper into this and spend more time writing a test case to expose this. Yes, CLOCK_MONOTONIC should be monotonic across all processors. Until the time travel is made possible, of course. > The test case you gave me is interesting, but somewhat low-level. What I > would do if it comes to it, is to make something that uses pthreads and > plain clock_gettime(2). Should not be too difficult to reproduce if it's > real issue. The test I give you verifies clock_gettime() in several threads going backward. > > P.S. I've also tried kern.timecounter.fast_gettime=0, made no difference. > Assuming it does not take a reboot to test it. Neither does > switching kern.timecounter.hardware, I've tested TSC-low(1000) > ACPI-fast(900) HPET(950) i8254(0), all are the same. I am almost sure this is app-level issue. To make me confident, run the test I provided. From owner-freebsd-current@freebsd.org Fri Jun 3 17:23: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 A28B5B69B30 for ; Fri, 3 Jun 2016 17:23:24 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 940F61787 for ; Fri, 3 Jun 2016 17:23:24 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 9372AB69B2F; Fri, 3 Jun 2016 17:23:24 +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 931D6B69B2E for ; Fri, 3 Jun 2016 17:23:24 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) by mx1.freebsd.org (Postfix) with ESMTP id 80BE11786 for ; Fri, 3 Jun 2016 17:23:24 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from sweettea.beer.town (unknown [76.164.8.130]) by smtp.vangyzen.net (Postfix) with ESMTPSA id D7C605648F for ; Fri, 3 Jun 2016 12:23:23 -0500 (CDT) To: "current@freebsd.org" From: Eric van Gyzen Subject: buildworld: /usr/bin/ar segfault Message-ID: <1962f7f5-652a-a2f4-c443-0dfab7a3e80d@FreeBSD.org> Date: Fri, 3 Jun 2016 12:23:23 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 17:23:24 -0000 My buildworld just failed very early with a segfault from /usr/bin/ar: -------------------------------------------------------------- >>> stage 1.1: legacy release compatibility shims -------------------------------------------------------------- ... --- libegacy.a --- building static egacy library ar -crD libegacy.a `NM='nm' NMFLAGS='' lorder dummy.o | tsort -q` Segmentation fault (core dumped) *** [libegacy.a] Error code 139 In __archive_write_allocate_filter(), a->filter_last was pointing to archive_write_ar_header(). a->format_write_header should have pointed to this function. The offset between these two fields in struct archive is 48 bytes. Sure enough, that structure recently grew by 48 bytes. This would seem to indicate that ar (or libarchive.a) was built with mismatched objects. Unfortunately, I don't have good records of what build options and flags I used. I /think/ I used either -DWITH_SYSTEM_COMPILER or no options at all. Well, I always use -j4. The "ar" that segfaulted seems to be /usr/bin/ar, so it's from r300692. Thanks to my list of Boot Environments (yay), I'm pretty sure I was running r298525 when I built r300692 (and I was running r297692 when I built r298525). I installed r297692 from the snapshot memstick.img. I recovered by restoring ar (and ranlib) from an old BE (yay again!). I'm reporting this in case there is a bug in the build and someone is willing to go hunting for it based on this vague report. :) Eric From owner-freebsd-current@freebsd.org Fri Jun 3 17:26: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 6668AB69BDD; Fri, 3 Jun 2016 17:26:44 +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 D834E196D; Fri, 3 Jun 2016 17:26:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u53HQYuo001539 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 3 Jun 2016 20:26:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u53HQYuo001539 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u53HQXfA001538; Fri, 3 Jun 2016 20:26:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 3 Jun 2016 20:26:33 +0300 From: Konstantin Belousov To: Alan Somers Cc: Alan Cox , John Baldwin , alc@freebsd.org, Adrian Chadd , freebsd-current , performance@freebsd.org, "current@freebsd.org" Subject: Re: PostgreSQL performance on FreeBSD Message-ID: <20160603172633.GY38613@kib.kiev.ua> References: <20140627125613.GT93733@kib.kiev.ua> <201408121409.40653.jhb@freebsd.org> <201408141147.45698.jhb@freebsd.org> <53ECFDC8.1070200@rice.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 17:26:44 -0000 On Fri, Jun 03, 2016 at 09:29:16AM -0600, Alan Somers wrote: > I notice that, with the exception of the VM_PHYSSEG_MAX change, these > patches never made it into head or ports. Are they unsuitable for low > core-count machines, or is there some other reason not to commit them? > If not, what would it take to get these into 11.0 or 11.1 ? The fast page fault handler was redesigned and committed in r269728 and r270011 (with several follow-ups). Instead of lock-less buffer queues iterators, Jeff changed buffer allocator to use uma, see r289279. Other improvement to the buffer cache was committed as r267255. What was not committed is the aggressive pre-population of the phys objects mem queue, and a knob to further split NUMA domains into smaller domains. The later change is rotten. In fact, I think that with that load, what you would see right now on HEAD, is the contention on vm_page_queue_free_mtx. There are plans to handle it. From owner-freebsd-current@freebsd.org Fri Jun 3 17:29: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 47CF9B69CF3; Fri, 3 Jun 2016 17:29:15 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi0-x244.google.com (mail-oi0-x244.google.com [IPv6:2607:f8b0:4003:c06::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0CE151B82; Fri, 3 Jun 2016 17:29:15 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi0-x244.google.com with SMTP id f12so62123oig.0; Fri, 03 Jun 2016 10:29:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=0T/M7FVnkzUYPYnLcFH3kPoXbFfV5oq2CaxWWIOwniw=; b=iGIXdhv5SmpqGrEEZCVFu3LD7ILg0qyFsCnjvoyyCUNVGgoPIMXmiHZ6InzVvZZYe8 z5a8MAEbqW6kDWoFPXaDNL9L80otHF35ecgtT1o1q3MnQNoITA92bVs22Tygpbfp6N1j QDnND2TfE5KebI3FMLz8eRhwirJSilh2NsYQ6j41RkCfNpS4+lfvUPSkNYlSDOqOidgf /a2X03PKdqti2bRyXahVj5ApTk0eiTWy4MrEHfU4zcHDLzCtEDl59o6sEzmu7v9Tyrub MrQxcfw/aJoOh2rD//QDuR/3dBuC5Jl0KHCtR1F7JPT8RVFlgg9UIoO8KKf3UEbYB8zY H4eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=0T/M7FVnkzUYPYnLcFH3kPoXbFfV5oq2CaxWWIOwniw=; b=igA1+VTQfwzuxxL7zAOP6PBtBmvzHeP3xpE+CFaUSo5Xh20mEenrkgr+ggGdPBNSqA 9GipXy02AexaYH40qYsdnBgNqSkwYbWxMsmXIfJBsi5vQaV4zS7Yn/PLbcTTpD6wLvQK 6xHEel4tASrT/BqaFc378nMW9EbtOzEKVdk2ntn7U4NLrUCNjnO6dckswQjwPNZIieDf 5L6ITQUug8VXqRCgLElLk2B/heOUVp3V4oI4R9rmdcjc9xBOYTyyvp9IXbNoiIQmgkTJ YTthWQ131paVXPDLdAWZ/9tKpjJwzhlJAz3tcMAnzNP4SQaxe4hSGNyr29Ro5fAbYw2C 7UBQ== X-Gm-Message-State: ALyK8tI47ZOfVDuEd3EV+5y0D/nhK75H8/aws4EuHumEnDYHoPgKQ/13caFgRh1dBIxBTl+CJjRYlThn70aqtw== X-Received: by 10.202.212.19 with SMTP id l19mr2524272oig.182.1464974954443; Fri, 03 Jun 2016 10:29:14 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.202.4.200 with HTTP; Fri, 3 Jun 2016 10:29:13 -0700 (PDT) In-Reply-To: <20160603172633.GY38613@kib.kiev.ua> References: <20140627125613.GT93733@kib.kiev.ua> <201408121409.40653.jhb@freebsd.org> <201408141147.45698.jhb@freebsd.org> <53ECFDC8.1070200@rice.edu> <20160603172633.GY38613@kib.kiev.ua> From: Alan Somers Date: Fri, 3 Jun 2016 11:29:13 -0600 X-Google-Sender-Auth: BEUIntNPI2bGuyinfCcreiWpry4 Message-ID: Subject: Re: PostgreSQL performance on FreeBSD To: Konstantin Belousov Cc: Alan Cox , John Baldwin , alc@freebsd.org, Adrian Chadd , freebsd-current , performance@freebsd.org, "current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 17:29:15 -0000 On Fri, Jun 3, 2016 at 11:26 AM, Konstantin Belousov wrote: > On Fri, Jun 03, 2016 at 09:29:16AM -0600, Alan Somers wrote: >> I notice that, with the exception of the VM_PHYSSEG_MAX change, these >> patches never made it into head or ports. Are they unsuitable for low >> core-count machines, or is there some other reason not to commit them? >> If not, what would it take to get these into 11.0 or 11.1 ? > > The fast page fault handler was redesigned and committed in r269728 > and r270011 (with several follow-ups). > Instead of lock-less buffer queues iterators, Jeff changed buffer allocator > to use uma, see r289279. Other improvement to the buffer cache was > committed as r267255. > > What was not committed is the aggressive pre-population of the phys objects > mem queue, and a knob to further split NUMA domains into smaller domains. > The later change is rotten. > > In fact, I think that with that load, what you would see right now on > HEAD, is the contention on vm_page_queue_free_mtx. There are plans to > handle it. Thanks for the update. Is it still recommended to enable the multithreaded pagedaemon? From owner-freebsd-current@freebsd.org Fri Jun 3 17:55:55 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 99E20B68468; Fri, 3 Jun 2016 17:55:55 +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 435C91CF5; Fri, 3 Jun 2016 17:55:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u53HtlY6008405 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 3 Jun 2016 20:55:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u53HtlY6008405 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u53HtkQc008398; Fri, 3 Jun 2016 20:55:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 3 Jun 2016 20:55:46 +0300 From: Konstantin Belousov To: Alan Somers Cc: Alan Cox , John Baldwin , alc@freebsd.org, Adrian Chadd , freebsd-current , performance@freebsd.org, "current@freebsd.org" Subject: Re: PostgreSQL performance on FreeBSD Message-ID: <20160603175546.GZ38613@kib.kiev.ua> References: <20140627125613.GT93733@kib.kiev.ua> <201408121409.40653.jhb@freebsd.org> <201408141147.45698.jhb@freebsd.org> <53ECFDC8.1070200@rice.edu> <20160603172633.GY38613@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 17:55:55 -0000 On Fri, Jun 03, 2016 at 11:29:13AM -0600, Alan Somers wrote: > On Fri, Jun 3, 2016 at 11:26 AM, Konstantin Belousov > wrote: > > On Fri, Jun 03, 2016 at 09:29:16AM -0600, Alan Somers wrote: > >> I notice that, with the exception of the VM_PHYSSEG_MAX change, these > >> patches never made it into head or ports. Are they unsuitable for low > >> core-count machines, or is there some other reason not to commit them? > >> If not, what would it take to get these into 11.0 or 11.1 ? > > > > The fast page fault handler was redesigned and committed in r269728 > > and r270011 (with several follow-ups). > > Instead of lock-less buffer queues iterators, Jeff changed buffer allocator > > to use uma, see r289279. Other improvement to the buffer cache was > > committed as r267255. > > > > What was not committed is the aggressive pre-population of the phys objects > > mem queue, and a knob to further split NUMA domains into smaller domains. > > The later change is rotten. > > > > In fact, I think that with that load, what you would see right now on > > HEAD, is the contention on vm_page_queue_free_mtx. There are plans to > > handle it. > > Thanks for the update. Is it still recommended to enable the > multithreaded pagedaemon? Single-threaded pagedaemon cannot maintain the good system state even on non-NUMA systems, if machine has large memory. This was the motivation for the NUMA domain split patch. So yes, to get better performance you should enable VM_NUMA_ALLOC option. Unfortunately, there were some code changes of quite low quality which resulted in the NUMA-enabled system to randomly fail with NULL pointer deref in the vm page alloc path. Supposedly that was fixed, but you should try that yourself. One result of the mentioned changes was that nobody used/tested NUMA-enabled systems under any significant load, for quite long time. From owner-freebsd-current@freebsd.org Fri Jun 3 18:27:23 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CFCD3B68EA6; Fri, 3 Jun 2016 18:27:23 +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 982451702; Fri, 3 Jun 2016 18:27:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x230.google.com with SMTP id p194so83054702iod.1; Fri, 03 Jun 2016 11:27:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=KYSrGvKkDPpfkFFqk0QJVYR360zHdOdndByM16Z1gQc=; b=gYggnWB0Cd8noDUdzPNp1ckdilRl0/FPwbqnT26rDflwYzSCwqm1JcDx9dkzNlUmIg /V+di/CnlTf8vVLpVbQAp4OFVArWUZwaqLbn6JV69L7COoFOI1y9/ewmPE/H5YWUmgWM q4Y21zF9H9yhOBA3T+R/g0Pp0yXj202V4gDTx58+lwNPkRtSrQP5d/KZVNbDBgSM8es4 0KyPeguj9tOUty8H6vqhd8Y24a5RK1/GYtipz6c5uTYh5PdfucbHx3wR+zJ/J+kQ3eCo JE+6lLo6xPy/HEd8x38OusxC30i2HSnmhJTaXrDwWxXcrcNMh5xioNIAT0Hw09x5b7p9 mHUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=KYSrGvKkDPpfkFFqk0QJVYR360zHdOdndByM16Z1gQc=; b=LD+49TE2rWlO4Ck0WrOdsYdYSHL9BEPmIRP24okgb8iZR7ulqq1E+tv8svOhWdssRY gwk4IWYyoGzyYkM+D2Pwe1hC6NvllXBd+xSHuhAPVBX997yiq49WPn6rULdePoPgaRXQ d1aVrkuBGsLHuTUZZJjpjC1tg8LGTPFjJo9sRsCEzBP3GVtvGNK488EvHf0ixseZBpZl orKbicdZ91GLsEi/ZDDCHW2hm1oKsqc+U3kX5UiFe2yPIfKB6K3Yxa47nx/i8Ydh0/TA YkHBEd35pL2DD5HguDWdRfyXssCMsstqmQUYqzh/CQh3fBYVHrtqnTvoX5s+bVghghtp IPyQ== X-Gm-Message-State: ALyK8tL+kRhZjbYNGx/7RX1b5Cw6papnfiQKYiB+4SuNFa40/F65TywbDIYfgwkGEueAn58YPBBdFJiNvoR4mQ== X-Received: by 10.36.81.79 with SMTP id s76mr1333740ita.71.1464978442929; Fri, 03 Jun 2016 11:27:22 -0700 (PDT) MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.36.113.3 with HTTP; Fri, 3 Jun 2016 11:27:21 -0700 (PDT) In-Reply-To: <20160603175546.GZ38613@kib.kiev.ua> References: <20140627125613.GT93733@kib.kiev.ua> <201408121409.40653.jhb@freebsd.org> <201408141147.45698.jhb@freebsd.org> <53ECFDC8.1070200@rice.edu> <20160603172633.GY38613@kib.kiev.ua> <20160603175546.GZ38613@kib.kiev.ua> From: Adrian Chadd Date: Fri, 3 Jun 2016 11:27:21 -0700 X-Google-Sender-Auth: gR6yv1SFYVzC9Sqq7mfFCO6qbuI Message-ID: Subject: Re: PostgreSQL performance on FreeBSD To: Konstantin Belousov Cc: Alan Somers , Alan Cox , John Baldwin , Alan Cox , freebsd-current , performance@freebsd.org, "current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 18:27:23 -0000 On 3 June 2016 at 10:55, Konstantin Belousov wrote: > On Fri, Jun 03, 2016 at 11:29:13AM -0600, Alan Somers wrote: >> On Fri, Jun 3, 2016 at 11:26 AM, Konstantin Belousov >> wrote: >> > On Fri, Jun 03, 2016 at 09:29:16AM -0600, Alan Somers wrote: >> >> I notice that, with the exception of the VM_PHYSSEG_MAX change, these >> >> patches never made it into head or ports. Are they unsuitable for low >> >> core-count machines, or is there some other reason not to commit them? >> >> If not, what would it take to get these into 11.0 or 11.1 ? >> > >> > The fast page fault handler was redesigned and committed in r269728 >> > and r270011 (with several follow-ups). >> > Instead of lock-less buffer queues iterators, Jeff changed buffer allocator >> > to use uma, see r289279. Other improvement to the buffer cache was >> > committed as r267255. >> > >> > What was not committed is the aggressive pre-population of the phys objects >> > mem queue, and a knob to further split NUMA domains into smaller domains. >> > The later change is rotten. >> > >> > In fact, I think that with that load, what you would see right now on >> > HEAD, is the contention on vm_page_queue_free_mtx. There are plans to >> > handle it. >> >> Thanks for the update. Is it still recommended to enable the >> multithreaded pagedaemon? > > Single-threaded pagedaemon cannot maintain the good system state even > on non-NUMA systems, if machine has large memory. This was the motivation > for the NUMA domain split patch. So yes, to get better performance you > should enable VM_NUMA_ALLOC option. > > Unfortunately, there were some code changes of quite low quality which > resulted in the NUMA-enabled system to randomly fail with NULL pointer > deref in the vm page alloc path. Supposedly that was fixed, but you > should try that yourself. One result of the mentioned changes was that > nobody used/tested NUMA-enabled systems under any significant load, for > quite long time. The iterator bug was fixed, so it still behaves like it used to if NUMA is enabled circa what, freebsd-9? If you'd like that older behavior, you can totally flip back to the global policy being round-robin only, and it's then a glorified, configurable-at-runtime no-op. The difference now is that you can tickle imbalances if you have too many processes that need pages from a specific domain instead of round robin, because the underlying tracking mechanisms still assume a single global pool and global method of cleaning things. That and the other NUMA stuff is something to address in -12. -adrian From owner-freebsd-current@freebsd.org Fri Jun 3 18:29: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 8B0E2B69005 for ; Fri, 3 Jun 2016 18:29:06 +0000 (UTC) (envelope-from adrian.chadd@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 682A41940 for ; Fri, 3 Jun 2016 18:29:06 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 6742FB69003; Fri, 3 Jun 2016 18:29:06 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 668E0B69001; Fri, 3 Jun 2016 18:29:06 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A02C193F; Fri, 3 Jun 2016 18:29:06 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x229.google.com with SMTP id k19so69317676ioi.3; Fri, 03 Jun 2016 11:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=KKzenDbUPi7frWUiQAS7wiF9ApSqtIvscKaM1T0WR4o=; b=P46QW1thYnfpKsI/nzfsePIFB+NbaHpcwS74Kg5S1lxGc9L87ka+hKjYXE8bz/Ynb6 FDfjyJp+5BGgblh7zAH8GXREKPUVirfqe0K0soAa01YcmbNVtzKAVvI3gc/GRm8OmGgA VueE8Kss9rI8/qR5q5gv5TOzxovMmZZ6jkfbn+0/HeDIEvoOk9NNEiY0+hCVsoqoR6By isTMlj8hLklaYasfUqhZnyMY3OPQFt4VP+F3LBuySa1rzCXRdzWXEYofs1br4Dem9952 MOMWfWDukHEXTFliy+pRSgpvK5wKK3nY2R12of0pCyUQHVIwYZOpxWMBmRS2gUD37nej zgYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=KKzenDbUPi7frWUiQAS7wiF9ApSqtIvscKaM1T0WR4o=; b=INu6MMsgXjdkN1KQ9zuMxGGYwib6SSr8Vtg6z5pInCtgpuYbs3ETEKtAmimD81v0II 37PO+zEYgy913y32Rx/q+Lom0wI6eqcr2dGV6vulS/9mfgrJmO4W8vp+J7K06xfyM+FH kCB4Yc3k7vPi0pQIhKrQhjQ/R8eaFGcawG72NCqlHNvcVCjDsutdJJBlv15+XDYx5Pt5 5PyPzIdQsYfyIrJWdMUyRMJPa63xXSLDIcj5X+AfG+SxCB5n6Lj8Tz/v47avkyd1e2sR bzCqVQ+NcQNswv+cEV9m/obzwwPXUqzSMu6ZNHO9fbMdg9mY4giyj7VDH8M2PfvgjM5A m6eQ== X-Gm-Message-State: ALyK8tJ8Hj04ZRM8SI5P3y2xMtN58mef/5LHTc6lbhCo3a2hD+eIlWJG3oceQVISA0HWVBWXGQtcbOqoz9Kirg== X-Received: by 10.36.92.199 with SMTP id q190mr1399491itb.25.1464978544648; Fri, 03 Jun 2016 11:29:04 -0700 (PDT) MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.36.113.3 with HTTP; Fri, 3 Jun 2016 11:29:03 -0700 (PDT) In-Reply-To: References: <20140627125613.GT93733@kib.kiev.ua> <201408121409.40653.jhb@freebsd.org> <201408141147.45698.jhb@freebsd.org> <53ECFDC8.1070200@rice.edu> <20160603172633.GY38613@kib.kiev.ua> <20160603175546.GZ38613@kib.kiev.ua> From: Adrian Chadd Date: Fri, 3 Jun 2016 11:29:03 -0700 X-Google-Sender-Auth: e_d2MJ3KDnc3yC014PpWP85tZWA Message-ID: Subject: Re: PostgreSQL performance on FreeBSD To: Konstantin Belousov Cc: Alan Somers , Alan Cox , John Baldwin , Alan Cox , freebsd-current , performance@freebsd.org, "current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 18:29:06 -0000 On 3 June 2016 at 11:27, Adrian Chadd wrote: > That and the other NUMA stuff is something to address in -12. And, I completely welcome continued development in NUMA scaling in combination with discussion. The iterator changes I committed are a more generic version of a patch people were applying on top of -10 and -head for at least what, three years now? Maybe more if -9 also just did round-robin and not first-touch? -adrian From owner-freebsd-current@freebsd.org Fri Jun 3 20:52: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 D5195B68981 for ; Fri, 3 Jun 2016 20:52:29 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id BD5F91CCA; Fri, 3 Jun 2016 20:52:29 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id B6960138E; Fri, 3 Jun 2016 20:52:29 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 7594321DF1; Fri, 3 Jun 2016 20:52:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id W5r1fjXsGDOI; Fri, 3 Jun 2016 20:52:27 +0000 (UTC) Subject: Re: amd64 11.0 -r301139 installworld (WITH_META_MODE=yes) fails for "Unable to determine compiler type" DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 14E6721DEA To: Mark Millard , FreeBSD Current References: <223a80c4-f57d-5636-2c0f-402d22fe631f@FreeBSD.org> From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <1a4bcdaa-9642-6695-dc5a-7cdcf3cf3566@FreeBSD.org> Date: Fri, 3 Jun 2016 13:52:32 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <223a80c4-f57d-5636-2c0f-402d22fe631f@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="L9xOGTb7BCPEOhg5jwHt8687uSOGgkN1S" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 20:52:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --L9xOGTb7BCPEOhg5jwHt8687uSOGgkN1S Content-Type: multipart/mixed; boundary="XWI8P4Cidpnctt8cD4Kf1vUfFRJghLxQJ" From: Bryan Drewery To: Mark Millard , FreeBSD Current Message-ID: <1a4bcdaa-9642-6695-dc5a-7cdcf3cf3566@FreeBSD.org> Subject: Re: amd64 11.0 -r301139 installworld (WITH_META_MODE=yes) fails for "Unable to determine compiler type" References: <223a80c4-f57d-5636-2c0f-402d22fe631f@FreeBSD.org> In-Reply-To: <223a80c4-f57d-5636-2c0f-402d22fe631f@FreeBSD.org> --XWI8P4Cidpnctt8cD4Kf1vUfFRJghLxQJ Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 6/1/2016 12:38 PM, Bryan Drewery wrote: >> WITHOUT_CROSS_COMPILER=3D > It's likely related to this flag. I'll look into it. I've fixed this in r301287. --=20 Regards, Bryan Drewery --XWI8P4Cidpnctt8cD4Kf1vUfFRJghLxQJ-- --L9xOGTb7BCPEOhg5jwHt8687uSOGgkN1S 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 iQEcBAEBAgAGBQJXUe4QAAoJEDXXcbtuRpfPpbsH/3Z5uY58u8uAFGIGsxgJJ9mG 0BmQ6hS/WWnVwAxxD9fbU05iMJzKgwRzudSiXWTnFDyV/SdBfdLmxavOzvjEyLVj /ndt7uZHqsxq8E+l1tkuQGNm/6ZdmdHpm/yWq7tXVgLRiBcL+1BJx4uT+Y85s6d+ /fIuZF20tZbNonbpl4r9qQ4fdmlOaXG/w0Y+IG7tll+ffHcV34XeZry2R+NVbvoQ jbHUBv7CcXfnQZIt1HAWKeJVNJ12zCmvjYdPixP2Hcbn1H47yZLb1jQdHxAF+Ueu l9H7je9rgxl7KXb6TUPJv9IGaXekp+jk7UlwI0BnbG19mCdNPOsdiTxzNKAjXIQ= =GwtQ -----END PGP SIGNATURE----- --L9xOGTb7BCPEOhg5jwHt8687uSOGgkN1S-- From owner-freebsd-current@freebsd.org Fri Jun 3 22:31:54 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E5012B69BD2; Fri, 3 Jun 2016 22:31:54 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id C8C551FAA; Fri, 3 Jun 2016 22:31:54 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id 87BD718F4; Fri, 3 Jun 2016 22:31:54 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Fri, 3 Jun 2016 22:31:53 +0000 From: Glen Barber To: freebsd-snapshots@FreeBSD.org, freebsd-current@FreeBSD.org Subject: New FreeBSD snapshots available: head (20160528 r301230) Message-ID: <20160603223153.GA70896@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 22:31:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 New FreeBSD development branch installation ISOs and virtual machine disk images have been uploaded to the FTP mirrors. As with any development branch, the installation snapshots are not intended for use on production systems. We do, however, encourage testing on non-production systems as much as possible. Please also consider installing the sysutils/panicmail port, which can help in providing FreeBSD developers the necessary information regarding system crashes. Checksums for the installation ISOs and the VM disk images follow at the end of this email. === Installation ISOs === Installation images are available for: o 11.0-ALPHA2 amd64 GENERIC o 11.0-ALPHA2 powerpc GENERIC o 11.0-ALPHA2 powerpc64 GENERIC64 o 11.0-ALPHA2 sparc64 GENERIC o 11.0-ALPHA2 armv6 BANANAPI o 11.0-ALPHA2 armv6 BEAGLEBONE o 11.0-ALPHA2 armv6 CUBIEBOARD o 11.0-ALPHA2 armv6 CUBIEBOARD2 o 11.0-ALPHA2 armv6 CUBOX-HUMMINGBOARD o 11.0-ALPHA2 armv6 GUMSTIX o 11.0-ALPHA2 armv6 RPI-B o 11.0-ALPHA2 armv6 RPI2 o 11.0-ALPHA2 armv6 PANDABOARD o 11.0-ALPHA2 armv6 WANDBOARD o 11.0-ALPHA2 aarch64 GENERIC Note: The i386 build failed due to an issue generating the doc.txz distribution, which is still undergoing investigation. Note regarding arm/armv6 images: For convenience for those without console access to the system, a freebsd user with a password of freebsd is available by default for ssh(1) access. Additionally, the root user password is set to root, which it is strongly recommended to change the password for both users after gaining access to the system. Snapshots may be downloaded from the corresponding architecture directory from: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/ Please be patient if your local FTP mirror has not yet caught up with the changes. Problems, bug reports, or regression reports should be reported through the Bugzilla PR system or the appropriate mailing list such as -current@ or -stable@ . === Virtual Machine Disk Images === VM disk images are available for the following architectures: o 11.0-ALPHA2 amd64 o 11.0-ALPHA2 aarch64 Disk images may be downloaded from the following URL (or any of the FreeBSD FTP mirrors): ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/ Images are available in the following disk image formats: ~ RAW ~ QCOW2 (qemu) ~ VMDK (qemu, VirtualBox, VMWare) ~ VHD (qemu, xen) The partition layout is: ~ 512k - freebsd-boot GPT partition type (bootfs GPT label) ~ 1GB - freebsd-swap GPT partition type (swapfs GPT label) ~ ~17GB - freebsd-ufs GPT partition type (rootfs GPT label) Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI loader file is needed for qemu-system-aarch64 to be able to boot the virtual machine images. The file can be found here, for now, until various patches are available upstream: http://people.FreeBSD.org/~gjb/QEMU_EFI.fd The checksums for this file are: SHA256 (QEMU_EFI.fd) = a35335a418781fc0963c80ab12d548b6972d2c0b955f45664a4b780f4e5f48a2 MD5 (QEMU_EFI.fd) = ec03d51a3c4374a515cf32ab0c2721cf To boot the VM image, run: % qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt \\ -bios QEMU_EFI.fd -serial telnet::4444,server -nographic \\ -drive if=none,file=VMDISK,id=hd0 \\ -device virtio-blk-device,drive=hd0 \\ -device virtio-net-device,netdev=net0 \\ -netdev user,id=net0 Be sure to replace "VMDISK" with the path to the virtual machine image. === Vagrant Images === FreeBSD/amd64 images are available on the Hashicorp Atlas site for the VMWare Desktop and VirtualBox providers, and can be installed by running: % vagrant init freebsd/FreeBSD-11.0-ALPHA2 % vagrant up == ISO CHECKSUMS == o 11.0-ALPHA2 amd64 GENERIC: SHA512 (FreeBSD-11.0-ALPHA2-amd64-20160528-r301230-bootonly.iso) = b6ecbad09f01e1044343229ee93552c7c6adfc1c0cbe07d1a876a679544c626775be05534ec619ef5383b5419acc13110df7f47301522b6f0393e62626e0d3cb SHA512 (FreeBSD-11.0-ALPHA2-amd64-20160528-r301230-bootonly.iso.xz) = 3a5d9a57a38363d9c4def1df07ae13e814be72af77a1932e39c97ea11ffb28ac92c6290a50099ab8380cc6265f45214c307042a9f5c0727f87150a2b74479eb9 SHA512 (FreeBSD-11.0-ALPHA2-amd64-20160528-r301230-disc1.iso) = 105c02b3736a2b7453a16a72b75be528362be5ebe0c5e1bb0a28f36814f298cb683e5de83d6813e249bbb27b820f55e1c93bb5b5f86cf07006efd07cdc80379c SHA512 (FreeBSD-11.0-ALPHA2-amd64-20160528-r301230-disc1.iso.xz) = 8ded96a1fd3ff4d9456918db469d114df01f94222751ca5028a58b08b851bc365887e761d10b8b9f66234e832f1657223d1e09b00533210cf520aa5582c5fd5d SHA512 (FreeBSD-11.0-ALPHA2-amd64-20160528-r301230-dvd1.iso) = fb4af5a3fe0dc84c5768ae21e71bd21275a3bdd827acde2a36d2a610ae08113f24d60f6dc27a14ff2acac0b54a165385bbe75bedc2601a161df20a7e4630aeba SHA512 (FreeBSD-11.0-ALPHA2-amd64-20160528-r301230-dvd1.iso.xz) = 70f55770d4aa9c9964be562224935db1674ef7dd01062347ac6680cfa82ddf989d33ca6da2b4e7a51f4a539719aac2d824651deaeebdd634dbc6cc26ca8906fd SHA512 (FreeBSD-11.0-ALPHA2-amd64-20160528-r301230-memstick.img) = 8d90bdeb416ff3f321730b57e850f3490b6071678260e644efb074718e619173185ac6e8fc4dc455e45b151bcbc8334a1ffd90b2bb7bdfac238a8429e5d44ad1 SHA512 (FreeBSD-11.0-ALPHA2-amd64-20160528-r301230-memstick.img.xz) = d3000e80c3284bef7dda3261248a5ea39c1e829bdd1474975fb63de5035cc4010e3ef7cbca24eb68146cce4e647434541ead5abb287f53001729eadf3aff26bc SHA512 (FreeBSD-11.0-ALPHA2-amd64-20160528-r301230-mini-memstick.img) = 0441031626b6e3dbb385d95245ea780e7c941f20ab249ca383fdcd19b082b2f3a24c62b1075ab7f136ab78db893597fc89e9976ced57ef5984426f2bd63558c4 SHA512 (FreeBSD-11.0-ALPHA2-amd64-20160528-r301230-mini-memstick.img.xz) = b2281de53ec5db8d695eb04245335dbaa740fa78f8c145a09cc74b535f2a1d708c0b8b81909ad58a715513212399ada61d366e0eea137ab51d8096a2c94bfb96 SHA256 (FreeBSD-11.0-ALPHA2-amd64-20160528-r301230-bootonly.iso) = 55d8f469424891ca65348ed2ac691f8d721f54a07fcdee7ece3477be5bceb781 SHA256 (FreeBSD-11.0-ALPHA2-amd64-20160528-r301230-bootonly.iso.xz) = e2306de923f623ad43d10a6ff072e68f13d8110f9128fdc7b3be3053c1a6abbf SHA256 (FreeBSD-11.0-ALPHA2-amd64-20160528-r301230-disc1.iso) = e1a61349e10d08db8c351f1d7da682b305640ba7c4b7c98a4c0cf675842c5632 SHA256 (FreeBSD-11.0-ALPHA2-amd64-20160528-r301230-disc1.iso.xz) = d0af769ddf70dc4b1fdd0acf240f61b62c816b6dc4e44aafec189eddf37787d8 SHA256 (FreeBSD-11.0-ALPHA2-amd64-20160528-r301230-dvd1.iso) = cba741c8abff27a001976a2dcdf83e1818969dc0ed60417a99f8ed04ecaee4f7 SHA256 (FreeBSD-11.0-ALPHA2-amd64-20160528-r301230-dvd1.iso.xz) = 2326e1cb29f41877bd0522455df0d58b91147aa3796922b2d39293e90aa896ab SHA256 (FreeBSD-11.0-ALPHA2-amd64-20160528-r301230-memstick.img) = 5a6ab5d8e975a362084b659aba44c5630418d6bc31f2a1844be1f9eb3cd6a2e1 SHA256 (FreeBSD-11.0-ALPHA2-amd64-20160528-r301230-memstick.img.xz) = f2f24bf7f08c1291d11e5b53231943c830c83c947f8477b3747efc1c966f522c SHA256 (FreeBSD-11.0-ALPHA2-amd64-20160528-r301230-mini-memstick.img) = a9ea657777fc8f5972d16bbbb2e4953a485f983f0ec168fd08390c87ac464ab4 SHA256 (FreeBSD-11.0-ALPHA2-amd64-20160528-r301230-mini-memstick.img.xz) = 79bc96bc8faf6340b656fda1d5075aabac95f63cca7129cbc0d23a5c88004409 o 11.0-ALPHA2 powerpc GENERIC: SHA512 (FreeBSD-11.0-ALPHA2-powerpc-20160528-r301230-bootonly.iso) = 5f1de640cf3fdaecaf6d8710755fda9dbb4908f1b374a34f02f1494ce817cba7cffb6c87b74410d944bcfe0621d63e8b255cc2ab222ab4dacfca880a53b9de21 SHA512 (FreeBSD-11.0-ALPHA2-powerpc-20160528-r301230-bootonly.iso.xz) = 65e2aff7c657e6cf1f4ab5a57bd035c36acfc6e9dc19e855ea04691ac26e53a22d13794c5161fa3986282ee5d7132b21434af89dc1b6a18ee87b25381f260c9e SHA512 (FreeBSD-11.0-ALPHA2-powerpc-20160528-r301230-disc1.iso) = 6d329a2b499b2fbb6a2108bacabbff357e5b1802ad3c22eb0581a1c61fb439a4d2a4792611309cc3d85bd89d216d2499ed7948094de34f820ca5df2122f1d16b SHA512 (FreeBSD-11.0-ALPHA2-powerpc-20160528-r301230-disc1.iso.xz) = 6e0d9eaefe998edac246bd0ff922a092da8b4a8fe173dd4ba5795ede097584bbedd9370d793e7182ce65f7f61b5e24652328f7d6962fe8c52191de5ff32f5816 SHA512 (FreeBSD-11.0-ALPHA2-powerpc-20160528-r301230-memstick.img) = 58a360c309046102a8ff8593730c7bb4c34494dfb7c10f3c03bf52be6a3fd20f0537d78933ce5ec4098a81af7385a0bbf569c49fcc01587414d6fb571e169578 SHA512 (FreeBSD-11.0-ALPHA2-powerpc-20160528-r301230-memstick.img.xz) = 97276dddbd07db8246a6f28d86e7691a7d424395620a8e2e16bd8abedb7e75bc52c22c43bbb642d84e834c0282ef73d5de640411b3f5ae08b13791ad850f3e58 SHA512 (FreeBSD-11.0-ALPHA2-powerpc-20160528-r301230-mini-memstick.img) = 569cbcf47803db36a3c7ff7515bd3492f5ab089a1eab1b23a896636af968003d6ebbd7a76144918d3d978689359ca18e30f2b7cca0d59ac29757bacca5cbaf22 SHA512 (FreeBSD-11.0-ALPHA2-powerpc-20160528-r301230-mini-memstick.img.xz) = 69632c5d63b3c49700396674c9bd2e02938b92ef0293b178105118f94c09769db873824e501dade42f76b3a9a6d8b9ee42e9924ebd3784ee75694838081a5c61 SHA256 (FreeBSD-11.0-ALPHA2-powerpc-20160528-r301230-bootonly.iso) = 1883b52130411ac2cc93c15c782d94e89593bc5bbec71a741c6491a2190d99ee SHA256 (FreeBSD-11.0-ALPHA2-powerpc-20160528-r301230-bootonly.iso.xz) = 577b9b5c708f870525493b8ffca8f4607df587b9131e460ddce772c16036567c SHA256 (FreeBSD-11.0-ALPHA2-powerpc-20160528-r301230-disc1.iso) = a9a3f5aef34e34748c9ee3f206ac9e0a0e8d220d3cb8becb9b5be6d3ccbe6fe1 SHA256 (FreeBSD-11.0-ALPHA2-powerpc-20160528-r301230-disc1.iso.xz) = 943fc82acc79a7646720b4d4701297a845ed1930fb7460de8b99fbe60efa2f5f SHA256 (FreeBSD-11.0-ALPHA2-powerpc-20160528-r301230-memstick.img) = 4c48e1330572bcde660ea4955c09cadc150472f32eafe1b65c6b986f05c917fd SHA256 (FreeBSD-11.0-ALPHA2-powerpc-20160528-r301230-memstick.img.xz) = 81298786da6de8acbbafbfec054cad2ae272205818388fd735695f77d14701f2 SHA256 (FreeBSD-11.0-ALPHA2-powerpc-20160528-r301230-mini-memstick.img) = a12bad0f7e5fc740afb7951a4c7ec6be22332f5853b57a74077d9966708ee1d0 SHA256 (FreeBSD-11.0-ALPHA2-powerpc-20160528-r301230-mini-memstick.img.xz) = 927d30df67d6cacbd73825c94b98c107766056f37690450feaea209ef1debd82 o 11.0-ALPHA2 powerpc64 GENERIC64: SHA512 (FreeBSD-11.0-ALPHA2-powerpc-powerpc64-20160528-r301230-bootonly.iso) = 766395100b048a5e8bb522bc140b5ba8642fbc1dd2fc473f238fa3797dcf98c76c0033ceb5ce0f64e29a9599c530e3029a07547efc95a50a80f49936275a966e SHA512 (FreeBSD-11.0-ALPHA2-powerpc-powerpc64-20160528-r301230-bootonly.iso.xz) = 53e2cf27947c56f5d9a77bb54253f3baa627e5ac170af4e08c353056f1a8abead99d40cbaa37bcb49fe1e730fc2f77560631077cdc92d6033da9a9c485383eef SHA512 (FreeBSD-11.0-ALPHA2-powerpc-powerpc64-20160528-r301230-disc1.iso) = 101b5e9d1542fc2314f14b7ea5f24a97a2df53956b7798486f46d3826f418af05611342d04c3ee93afefebd3e8607d4c61bebf6ae78c5e64515537d3eafbffac SHA512 (FreeBSD-11.0-ALPHA2-powerpc-powerpc64-20160528-r301230-disc1.iso.xz) = a73f27c19b829aa05981feed74b42a805525c56b8f8fa19e9694b689b3e5b429f50105ff0ea052e826809007635c4f57287aba0fe06e99130363164ed3bdc523 SHA512 (FreeBSD-11.0-ALPHA2-powerpc-powerpc64-20160528-r301230-memstick.img) = 43686f60f8baa4134be2993ff40e9cbc5a345c802d92565927138a11d7facaa9d6cc2eb94c3989290aaba6fad788502f11e075e095552b3fac995e5dab507ec7 SHA512 (FreeBSD-11.0-ALPHA2-powerpc-powerpc64-20160528-r301230-memstick.img.xz) = 4e870e99d115787967715d8223209c1cf5bb494de103380c03522a6165b6e4b18d1a2ecc09972a1b2ef027ad748126bc1c9aaca596a01edb7503328cc3bbe20b SHA512 (FreeBSD-11.0-ALPHA2-powerpc-powerpc64-20160528-r301230-mini-memstick.img) = a1c7b2364ecfce09ef6e41be4509e797f8cf87c389592db726462f8c18e76d736da07de4100f94e0b04b48e2a1f54c80d11e7c31730b82c4703719b148331521 SHA512 (FreeBSD-11.0-ALPHA2-powerpc-powerpc64-20160528-r301230-mini-memstick.img.xz) = 66b124012eceb2ffa4e419e98e493d39a801ade2de9051a893e1d9cc4bc744c76d4da60495d5a67814c7efb0799bc86195475b4d77d5628a8ef837c2a07863d0 SHA256 (FreeBSD-11.0-ALPHA2-powerpc-powerpc64-20160528-r301230-bootonly.iso) = 575990d12f4fc690e1c96246ad77075211b4e241247c589a4ece95be58fc5fd3 SHA256 (FreeBSD-11.0-ALPHA2-powerpc-powerpc64-20160528-r301230-bootonly.iso.xz) = f33bcc9283865cc7da8629ffa85ab86bba44d07c4f5999c53ede711f0452eb36 SHA256 (FreeBSD-11.0-ALPHA2-powerpc-powerpc64-20160528-r301230-disc1.iso) = 5446ed7fc516d99600a47f98983e45a8a77d5eeeab7b203281ff2f3575a6db06 SHA256 (FreeBSD-11.0-ALPHA2-powerpc-powerpc64-20160528-r301230-disc1.iso.xz) = 8a5cfd62af02614f4e926de9a7c99fb5c2cea11cb6fc86554d20177bcba9acdd SHA256 (FreeBSD-11.0-ALPHA2-powerpc-powerpc64-20160528-r301230-memstick.img) = ec522100028ea95098c304a1d9d7c7c8dd0211c8c769959f6bb004d91a174171 SHA256 (FreeBSD-11.0-ALPHA2-powerpc-powerpc64-20160528-r301230-memstick.img.xz) = f183debd827a048692aaf4817eadc6b975763192575245c8c0dd348254609f5f SHA256 (FreeBSD-11.0-ALPHA2-powerpc-powerpc64-20160528-r301230-mini-memstick.img) = 114eefffd8157b22c5962549ba74680fd27a231e626cc5479cb0fd3c306157ab SHA256 (FreeBSD-11.0-ALPHA2-powerpc-powerpc64-20160528-r301230-mini-memstick.img.xz) = b9aa4d48b8c7ed36b91f187dde55f49ad73924d2cb1bcec5fc9363455590f386 o 11.0-ALPHA2 sparc64 GENERIC: SHA512 (FreeBSD-11.0-ALPHA2-sparc64-20160528-r301230-bootonly.iso) = dec52ee56e34afe974fee387ec546b9adcc1d63694af11a76930056fde44663c6aeb2027c677e2be4b6294a514d5018bf7fb316cef7287c03bd370e53ce3cb0a SHA512 (FreeBSD-11.0-ALPHA2-sparc64-20160528-r301230-bootonly.iso.xz) = da791928bc04b300eff5782b4c83b62c91926dda895de6ea8cdf633e265fdca268c4ee3efecb7aef210cbb1472025a211987eeb578ddce66755a2e41ab134044 SHA512 (FreeBSD-11.0-ALPHA2-sparc64-20160528-r301230-disc1.iso) = 9072343737d99a063ca33059812eba16ba09b771214d182d38205f40dd739b584f433e28f978182e4bf457aa822ef23e2ead0823225ba0e2547312ee293ee9ac SHA512 (FreeBSD-11.0-ALPHA2-sparc64-20160528-r301230-disc1.iso.xz) = bade27ee216b67875cced5866074dbf49fce71aaec3c9225bc256f50cada148c94e81800424a498eb51656931485c5b727c85e52b160ce998095d2f9b6c43a10 SHA256 (FreeBSD-11.0-ALPHA2-sparc64-20160528-r301230-bootonly.iso) = 33e1d2f35422899819e43ca9c1f37442e3d84d36ecc01fbc6c151a9299267d4d SHA256 (FreeBSD-11.0-ALPHA2-sparc64-20160528-r301230-bootonly.iso.xz) = b3c714eaf28d07868eec6286b9b2482f2a2369a02e00a733befdc78257509ddd SHA256 (FreeBSD-11.0-ALPHA2-sparc64-20160528-r301230-disc1.iso) = 73a8f9e01a6d84c0132c461e3a0e95ebd909f7f3c1fc9598800f6cae300bd497 SHA256 (FreeBSD-11.0-ALPHA2-sparc64-20160528-r301230-disc1.iso.xz) = 21d3c98e934da1189e056825402921db6e39c6f59c69f7e580c2681b23601c7f o 11.0-ALPHA2 armv6 BANANAPI: SHA512 (FreeBSD-11.0-ALPHA2-arm-armv6-BANANAPI-20160528-r301230.img.xz) = 0aee9946f0fdaa1dd3fe9577aad2392fa1beae188881c7c7b7d27086cff5e32b60778ec5a07b2d34e6461257eb87a3f8ab271172a4e8ad98665c91a779c13591 SHA256 (FreeBSD-11.0-ALPHA2-arm-armv6-BANANAPI-20160528-r301230.img.xz) = 348c219f3a25e2a23f42122d7a7cfe8e85010851c64f99e519a03781f9a3cd14 o 11.0-ALPHA2 armv6 BEAGLEBONE: SHA512 (FreeBSD-11.0-ALPHA2-arm-armv6-BEAGLEBONE-20160528-r301230.img.xz) = d5403b3d2df6f69d79b1a0f6d9c6a3fc51048b89a77f600936465e5d03bddba009a1f678b4625e416dc1fd22191c06b28daac13ebf03898e3858e884a627d621 SHA256 (FreeBSD-11.0-ALPHA2-arm-armv6-BEAGLEBONE-20160528-r301230.img.xz) = e90fbbf9796aae4d12d2fd74ae848c034e1debf2f35db3fbd26ce3a3ef8c9204 o 11.0-ALPHA2 armv6 CUBIEBOARD: SHA512 (FreeBSD-11.0-ALPHA2-arm-armv6-CUBIEBOARD-20160528-r301230.img.xz) = 4ce51f0067cbb4132c5a97abb744378b3610bf45d63c1917e499baeb9b98ee2f6fd99a9aeb120c478a1dba528f66957070cf02180266d237289cc50c6f0b7b61 SHA256 (FreeBSD-11.0-ALPHA2-arm-armv6-CUBIEBOARD-20160528-r301230.img.xz) = 76c66902b1a626cbfc449e4ef95240bb3598e26cd282e7117a4cbcfec42ab867 o 11.0-ALPHA2 armv6 CUBIEBOARD2: SHA512 (FreeBSD-11.0-ALPHA2-arm-armv6-CUBIEBOARD2-20160528-r301230.img.xz) = 2fbffdfe16e5143d5f6c7de089f36af86019f2b651dbc9ef06fde2b0c41c5e37b39324065a87ed26a47b2293d80bd8b0e79f51269906f198045a3b03a88b602c SHA256 (FreeBSD-11.0-ALPHA2-arm-armv6-CUBIEBOARD2-20160528-r301230.img.xz) = 9d1c8b1fc50a8da9eb0b5def26caf13b3979315cade8b364a2219f123231caf5 o 11.0-ALPHA2 armv6 CUBOX-HUMMINGBOARD: SHA512 (FreeBSD-11.0-ALPHA2-arm-armv6-CUBOX-HUMMINGBOARD-20160528-r301230.img.xz) = 5c69cf17003e2a04d5daac21daa0d8b42fa563bf5a147cd0e1e187b82a1e8b4495796db04f7d43a3061968bfe3998ce0a0a68da37a11fa455d6ba625039886b5 SHA256 (FreeBSD-11.0-ALPHA2-arm-armv6-CUBOX-HUMMINGBOARD-20160528-r301230.img.xz) = b9721fec7e87e592efcaf5f434e192fefe2b87af198a6ccb89142ce229539998 o 11.0-ALPHA2 armv6 GUMSTIX: SHA512 (FreeBSD-11.0-ALPHA2-arm-armv6-GUMSTIX-20160528-r301230.img.xz) = 6d5573195caf5e85077b2245dfa62ffb09d8307cc3e75e162fd6cf65c76541e55327340d2adb7efe7214d6f4d7f6e97586630274c1d7527c88d4e60cf3c5141e SHA256 (FreeBSD-11.0-ALPHA2-arm-armv6-GUMSTIX-20160528-r301230.img.xz) = a3cf2e92bc053963005a19e18ae12972fcf7f3a1812d7e86da36744c923f1ba0 o 11.0-ALPHA2 armv6 RPI-B: SHA512 (FreeBSD-11.0-ALPHA2-arm-armv6-RPI-B-20160528-r301230.img.xz) = 99db75a0ee8862030d25fa7620be422d0fe43124939782f17212a9bc69aa2cc8e0433c979c81ee7a122472f9e16f34ed1f679ec6993aee7f75f2285287d404e4 SHA256 (FreeBSD-11.0-ALPHA2-arm-armv6-RPI-B-20160528-r301230.img.xz) = d19679cd7e45763243c9450aecb6207968cdb3080455cb2e4f68fd714b19988f o 11.0-ALPHA2 armv6 RPI2: SHA512 (FreeBSD-11.0-ALPHA2-arm-armv6-RPI2-20160528-r301230.img.xz) = 6b8ce71a3f24af174bf083de2e96bb0b741773277df4e7abd33398e7c5b422ba5a453133dfbb4bfb5380972882466c2cf6f6141a1c610689cc0e5eaa858c4a33 SHA256 (FreeBSD-11.0-ALPHA2-arm-armv6-RPI2-20160528-r301230.img.xz) = ec4eed02846569c56584a41f5a767a9c88c2caec920c64772005b248cfc6d7c1 o 11.0-ALPHA2 armv6 PANDABOARD: SHA512 (FreeBSD-11.0-ALPHA2-arm-armv6-PANDABOARD-20160528-r301230.img.xz) = f0affe27982155564ae9ed0fe0bd666e8765f3eca78808c08f8cad6192d7658e1fc8b9499d5245f53ca5588dab82de385cb7fc37effa5b84f6c4480e4033bee7 SHA256 (FreeBSD-11.0-ALPHA2-arm-armv6-PANDABOARD-20160528-r301230.img.xz) = 73796013d21539c5e1c825d8389bf26ec144a81c9cd59f65545ecae857bb5c03 o 11.0-ALPHA2 armv6 WANDBOARD: SHA512 (FreeBSD-11.0-ALPHA2-arm-armv6-WANDBOARD-20160528-r301230.img.xz) = 9de2d90d6f9ec2da8461b04e411f85626bdee08de4bcf5221b0aa188118f63a932e5bd711a06e122cc53d0f663ea52634d9bc2332bcd650ea772e98168af56e1 SHA256 (FreeBSD-11.0-ALPHA2-arm-armv6-WANDBOARD-20160528-r301230.img.xz) = d00eb028760da445e776611606b9bf111de21736de3000a4aa59251926eb14b9 o 11.0-ALPHA2 aarch64 GENERIC: SHA512 (FreeBSD-11.0-ALPHA2-arm64-aarch64-20160528-r301230-memstick.img) = 3897f978011041b132932c75b6a2f308ac170f56d3392c7e13e4522c69b7c78f2f67d98383868f0b785dd7006d19704275946828d10c9e05ed0f3794a0ae6a2f SHA512 (FreeBSD-11.0-ALPHA2-arm64-aarch64-20160528-r301230-memstick.img.xz) = be70bc1de12b230ee237ebfba85525c1f9ed8a167ffc109b3510fad2baa8e0d958f6eb60b5a4b55cc9678a00f0a961a371e4917e7d92276feceb150294a9fc56 SHA512 (FreeBSD-11.0-ALPHA2-arm64-aarch64-20160528-r301230-mini-memstick.img) = 520d5a915c8093ffb76a5fe4f23f40ea2c19df8d7e4eee6eadc3e0f1acdc571ce3fd4d7e792c7a8dfe2d0299826dc4a8a32efef18c0e3bd4da79f4bf89c163b5 SHA512 (FreeBSD-11.0-ALPHA2-arm64-aarch64-20160528-r301230-mini-memstick.img.xz) = 5dcf0088e180856e30a83665163691f78aacfa0f4d7824f72a879b9dc88b9b24fb722370e015e6111e5561f08e69aca966808cc786dcd188027467dd7dbf213a SHA256 (FreeBSD-11.0-ALPHA2-arm64-aarch64-20160528-r301230-memstick.img) = 0b0a1d1da4db606e4b13fbebb29148b2f3ecc574c179073ad6908d921c9041cc SHA256 (FreeBSD-11.0-ALPHA2-arm64-aarch64-20160528-r301230-memstick.img.xz) = 24beafd685d21bddf4e9c6bab4d7181b7720d076255d194b03f9c2596f75c275 SHA256 (FreeBSD-11.0-ALPHA2-arm64-aarch64-20160528-r301230-mini-memstick.img) = 0e335b0e771b95928f0734d5e304d45d9a3130a6e8f78d654dee73cb7ad544d9 SHA256 (FreeBSD-11.0-ALPHA2-arm64-aarch64-20160528-r301230-mini-memstick.img.xz) = 9a410fbd43f8cd208591b8dac7f15003975e8f18f77b5898050a753b66c6ed45 == VM IMAGE CHECKSUMS == o 11.0-ALPHA2 amd64: SHA512 (FreeBSD-11.0-ALPHA2-amd64-20160528-r301230.qcow2.xz) = e90107401a769b76976a448062bd7d0986d5735745865c47de4f7dcb269238c6c7f95139e6b284d6580b3495b49663e7d2651050aba7acc0d0714aedbd98c7c0 SHA512 (FreeBSD-11.0-ALPHA2-amd64-20160528-r301230.raw.xz) = d17c470f5bced87c80de6ea847539c43852b72e1a4783234877ee7baaf7c64f180750388690b50b5da550307e8dc333978cddba92d909301935ae31e7075d85e SHA512 (FreeBSD-11.0-ALPHA2-amd64-20160528-r301230.vhd.xz) = 643fe7d36360b0666d71ff766fb02f36f8e384f5f45f853bb54e4b7bbb42d2fbdc281983c261a831e6d6ee57899622c0ff790e711e43be428597f41e5c0900bf SHA512 (FreeBSD-11.0-ALPHA2-amd64-20160528-r301230.vmdk.xz) = 900774271a64a87fe9f07c8936d9addd0090bd060d8394b20fe6f31b66f67020a4adc194f067fbea376b543df6127689b34a5e3eefabf6c47830145469e39195 SHA256 (FreeBSD-11.0-ALPHA2-amd64-20160528-r301230.qcow2.xz) = b995562fdb01bdb62b9a0c13726b728ef90d0f05eafa77944b39b1222803f54a SHA256 (FreeBSD-11.0-ALPHA2-amd64-20160528-r301230.raw.xz) = 80ff816dea6c051a7a8caf1384a264bc0906d4c3fa8fc1792add83f294a4da8a SHA256 (FreeBSD-11.0-ALPHA2-amd64-20160528-r301230.vhd.xz) = 0865fbb7279d04240902c2e63bd7f391af9eafcc91d64f915cc60b537d99f068 SHA256 (FreeBSD-11.0-ALPHA2-amd64-20160528-r301230.vmdk.xz) = 71c1706c3ce4cb9212fdb189ada3cc18478585415a0b3a7f9a71d01e2fb72b6e o 11.0-ALPHA2 aarch64: SHA512 (FreeBSD-11.0-ALPHA2-arm64-aarch64-20160528-r301230.qcow2.xz) = 067b5d43ca0309880594664126b77e653c723729798f60a98a1478f59c1513348f825e9bfb0091a5ff8f53a2258e897fa0e9f5826249a24b4c19c0e2a149d927 SHA512 (FreeBSD-11.0-ALPHA2-arm64-aarch64-20160528-r301230.raw.xz) = e0a380bf2b7649e44f82a1d2a5bdc1d4e0abbfe87dfaca1da52447f1a33c208772849982bf878684f28020655dfe8a851ff7d90943162e7326aa5c49850e2069 SHA512 (FreeBSD-11.0-ALPHA2-arm64-aarch64-20160528-r301230.vhd.xz) = e709d36f2419f153ce40788dc95b56d50dee42f40e45b6b542b129c1ae7b72bd479e331edd6d5ac2e7ec7888850e7de520df208e515489a381d982d7ab367ce6 SHA512 (FreeBSD-11.0-ALPHA2-arm64-aarch64-20160528-r301230.vmdk.xz) = fcb3a49ef940cd61b0956e85c2084c032d8517d3587f091cc57166efd44cb08f4cb846c585fdfa131cc66079d19e3b2039638b75914ee4d7c9eb38acd8c1b107 SHA256 (FreeBSD-11.0-ALPHA2-arm64-aarch64-20160528-r301230.qcow2.xz) = b7e6c2dad060e3c14a0eff03dda4a1d973b21fcb1ed1c24f091a73c92b2bd6af SHA256 (FreeBSD-11.0-ALPHA2-arm64-aarch64-20160528-r301230.raw.xz) = 8d89c387bb5485c5a12cf3a6926f353cae3414aa419ebc4d14f663370e583dd0 SHA256 (FreeBSD-11.0-ALPHA2-arm64-aarch64-20160528-r301230.vhd.xz) = e9a88d73f6c1b1f57ab5092f9393d0d495400131d5c04af3d6460e0021da8db8 SHA256 (FreeBSD-11.0-ALPHA2-arm64-aarch64-20160528-r301230.vmdk.xz) = 5f75c115b3bee034750b54817510e6e31cc2fca9b9fdaa6ca6914220fee7636b Regards, Glen Love FreeBSD? Support this and future releases with a donation to the FreeBSD Foundation! https://www.freebsdfoundation.org/donate/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXUgVZAAoJEAMUWKVHj+KTEnYP/0tsD0QFJK/89jDavxgykJlD G3uD7N8JOy15jfxEIEizxmm/Ue6svEIsWL0/tRvEeRZCayo6EQSqwwVXyhE4QDnS 5dFOIYx5aVBEH4CauzdumhBifh0bYiqOqkQP5w5NnJ7ex5t4lmACSYA+PRY1xmBg TI7+ZknNNxn2QWlYE5lwg6xEK4qKYg/BXAIUz6xnFu6Fz9HnSQ/6+ptBB2EyAjmT kKU882YJF9iU4X8wt1FIUklVv6jWGngZHSB436bQ9wvQ3FME9y4DBFrOaxBRqHVt USJHJAxiNXEfmYcxrIGiJWTBqeUj+v8pppjKF+mPb95XOFuB/SdsHQLO+/H2zcl4 gofkNFYsfBLR4JRTqg7Dksh+JP6N6dgJFqL4IQepfc5divFpgHPT+mr/pebpQdum e2Uf3sQNRIRvmh0Z6kyRl3CPDxDq/MRwYL9pG7+kLIEg8iZF2IuIAB2UO/5Kox9H 0nkaiPOaW8U7hdRuZ3T4R8vDbo4N53bS9XZLEnyQLT9AMQyheGc8/CAg6v/BGGjR +pJUk8lbRwYVw363pHTE2wWBxajOgujHH2t1we1h1wCZiz05dfzi3pSsxM4+qMnv eFzpdWpYex72fZPjrhbXO33TfTVmjpZ3IxZr9Tt23k9S8X7lGN5A9/JDoidNdJil UZXjx1kSxbhUo9G+3WUr =H+DH -----END PGP SIGNATURE----- From owner-freebsd-current@freebsd.org Sat Jun 4 00:11:35 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 48CCBB69F57; Sat, 4 Jun 2016 00:11:35 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2B7DE1849; Sat, 4 Jun 2016 00:11:32 +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 u540BODD045000; Fri, 3 Jun 2016 17:11:28 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201606040011.u540BODD045000@gw.catspoiler.org> Date: Fri, 3 Jun 2016 17:11:24 -0700 (PDT) From: Don Lewis Subject: VirtualBox network connectivity broken on recent -CURRENT To: freebsd-current@FreeBSD.org, freebsd-emulation@FreeBSD.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 00:11:35 -0000 It looks like something changed in -CURRENT to break network connectivity to VirtualBox guests. This was last known to work with r299139 (May 6th) and is definitely broken with r301229. The VirtualBox port revisions are: virtualbox-ose-4.3.38_1 virtualbox-ose-kmod-4.3.38 It looks like there was one change to the VirtualBox on May 9th, but it looks unlikely to be the cause of the problem. The network settings are: Attached to: Bridged Adapter Name: re0 Adapter Type: Paravirtualized Network (virtio-net) Promiscuous Mode: Deny MAC Address: [snip] Ifconfig says that the interface is up, but I am unable to ping either the host or anything else on the LAN from the guest. It looks like the problem is with outbound traffic. If I attempt to ping the guest, the source IP address and MAC address show up in the guest's arp table, but ping reports: ping: sendto: Host is down That makes me think that the arp responses from the guest are not getting transmitted. None of the machines involved are running firewalls. If I ping from the guest, I don't see any arp requests on the wire and the arp command shows the table entry as incomplete. The problem shows up with both FreeBSD -CURRENT and Debian guests. From owner-freebsd-current@freebsd.org Sat Jun 4 00:43: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 0981FB6565C; Sat, 4 Jun 2016 00:43:32 +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 DE5851996; Sat, 4 Jun 2016 00:43:31 +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 u540hOVq045060; Fri, 3 Jun 2016 17:43:28 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201606040043.u540hOVq045060@gw.catspoiler.org> Date: Fri, 3 Jun 2016 17:43:24 -0700 (PDT) From: Don Lewis Subject: Re: VirtualBox network connectivity broken on recent -CURRENT To: freebsd-current@FreeBSD.org cc: freebsd-emulation@FreeBSD.org In-Reply-To: <201606040011.u540BODD045000@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 00:43:32 -0000 On 3 Jun, Don Lewis wrote: > It looks like something changed in -CURRENT to break network > connectivity to VirtualBox guests. This was last known to work with > r299139 (May 6th) and is definitely broken with r301229. The VirtualBox > port revisions are: > virtualbox-ose-4.3.38_1 > virtualbox-ose-kmod-4.3.38 > It looks like there was one change to the VirtualBox on May 9th, but it > looks unlikely to be the cause of the problem. > > The network settings are: > Attached to: Bridged Adapter > Name: re0 > Adapter Type: Paravirtualized Network (virtio-net) > Promiscuous Mode: Deny > MAC Address: [snip] > Ifconfig says that the interface is up, but I am unable to ping either > the host or anything else on the LAN from the guest. It looks like the > problem is with outbound traffic. If I attempt to ping the guest, the > source IP address and MAC address show up in the guest's arp table, but > ping reports: > ping: sendto: Host is down > That makes me think that the arp responses from the guest are not > getting transmitted. None of the machines involved are running > firewalls. If I ping from the guest, I don't see any arp requests on > the wire and the arp command shows the table entry as incomplete. > > The problem shows up with both FreeBSD -CURRENT and Debian guests. I see the same behaviour if I set: Attached to: NAT or Adapter Type: 82540EM From owner-freebsd-current@freebsd.org Sat Jun 4 02:19:55 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B5952B686E6 for ; Sat, 4 Jun 2016 02:19:55 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::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 7B39919BD for ; Sat, 4 Jun 2016 02:19:55 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pf0-x230.google.com with SMTP id g64so49096247pfb.2 for ; Fri, 03 Jun 2016 19:19:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=p2jrID7WR+MEJ/bfjHesI02me3se74MIWu5TxqFlqps=; b=y24Tti6rawB6kb+cR/tUul1tzmy/aghjKj7TaeU70OGylMOWSpAe5EPmnhq8Z5OaHW m90mKWljqxextb4WV0w05gpsIYC3rrI+/fDPL239vMrtzt4uqHanMbiVOnj1qMWA2WmJ aw7YI9mmU9YFATFbHeLY08Y97hHRqYkBZgRiJ1JsuSHktIP4O5/pG9wGaySGtZqAk8N/ LklfCbKX14MLeNFwXzpBG3UXKjtDW4FJFLpn2FhLz3TZ+v5IqOMhm3YlyB+K2ck/qj6Z GKgY8IGyYPGKb8Kr/oFZCI0dEERqJAaZYIUgPA920SIOAZ9jUq3CvWRoQtoW2VDczmrV D12A== 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:subject:message-id :mime-version:content-disposition:user-agent; bh=p2jrID7WR+MEJ/bfjHesI02me3se74MIWu5TxqFlqps=; b=C9ywMlQ7xKykhNfKK5ytmn/kt1MxPC6SLqSnpwgEy0amL1p8fSOTk8cB/aIi8oRBM4 FqNYJhQcCklxPJdqNCni20fQR+DO9vXamUWTOaegTlAlZctUAWlLipYLv4GFjxV6hlAt YVaOLI/d086nFQl7+PYapwiDCUmmaMHarHncs4b8Bf+fQMUrdbXF8ewUer/7zq1fsIDC xcc5iCL+Avbu1b/JKn7nDwqGtc3k8rIaFuwcIEFnj5o3HEAxE6U98YcI1+0gI1lBdLwI K3bK2niPNEXZS1etI8PR2+9ysh71TQ25kpzuIE2CxPV547vvbvHoLEI3KsBaVdVi+Ih9 4loQ== X-Gm-Message-State: ALyK8tJAgd3I7WwGKOtIa7q3AJzl1QcC4HCdMkwScwJ95iN++22muXzMxVzIb4ZKxi86Rg== X-Received: by 10.98.73.214 with SMTP id r83mr9655422pfi.114.1465006794902; Fri, 03 Jun 2016 19:19:54 -0700 (PDT) Received: from wkstn-mjohnston.west.isilon.com (c-76-104-201-218.hsd1.wa.comcast.net. [76.104.201.218]) by smtp.gmail.com with ESMTPSA id x71sm11215164pfj.43.2016.06.03.19.19.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Jun 2016 19:19:54 -0700 (PDT) Sender: Mark Johnston Date: Fri, 3 Jun 2016 19:23:47 -0700 From: Mark Johnston To: freebsd-current@FreeBSD.org Subject: thread suspension when dumping core Message-ID: <20160604022347.GA1096@wkstn-mjohnston.west.isilon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 02:19:55 -0000 Hi, I've recently observed a hang in a multi-threaded process that had hit an assertion failure and was attempting to dump core. One thread was sleeping interruptibly on an advisory lock with TDF_SBDRY set (our filesystem sets VFCF_SBDRY). SIGABRT caused the receipient thread to suspend other threads with thread_single(SINGLE_NO_EXIT), which fails to interrupt the sleeping thread, resulting in the hang. My question is, why does the SA_CORE handler not force all threads to the user boundary before attempting to dump core? It must do so later anyway in order to exit. As I understand it, TDF_SBDRY is intended to avoid deadlocks that can occur when stopping a process, but in this case we don't stop the process with the intention of resuming it, so it seems erroneous to apply this flag. Thanks, -Mark From owner-freebsd-current@freebsd.org Sat Jun 4 04:41:19 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5DFB7B68467 for ; Sat, 4 Jun 2016 04:41:19 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4C9FE11AD for ; Sat, 4 Jun 2016 04:41:19 +0000 (UTC) (envelope-from tim@kientzle.com) Received: by mailman.ysv.freebsd.org (Postfix) id 4BA41B68466; Sat, 4 Jun 2016 04:41:19 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4B4CFB68465 for ; Sat, 4 Jun 2016 04:41:19 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (kientzle.com [142.254.26.11]) (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 2BD9011AA; Sat, 4 Jun 2016 04:41:18 +0000 (UTC) (envelope-from tim@kientzle.com) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id u544fBUS078250; Sat, 4 Jun 2016 04:41:11 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.102] (192.168.1.101 [192.168.1.101]) by kientzle.com with SMTP id nspwgekg47qxje9hzscm6kama2; Sat, 04 Jun 2016 04:41:10 +0000 (UTC) (envelope-from tim@kientzle.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: buildworld: /usr/bin/ar segfault From: Tim Kientzle In-Reply-To: <1962f7f5-652a-a2f4-c443-0dfab7a3e80d@FreeBSD.org> Date: Fri, 3 Jun 2016 21:41:10 -0700 Cc: "current@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8A7BD41B-4764-4C0F-990A-9677054761D8@kientzle.com> References: <1962f7f5-652a-a2f4-c443-0dfab7a3e80d@FreeBSD.org> To: Eric van Gyzen X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 04:41:19 -0000 > On Jun 3, 2016, at 10:23 AM, Eric van Gyzen = wrote: >=20 > My buildworld just failed very early with a segfault from /usr/bin/ar: >=20 > -------------------------------------------------------------- >>>> stage 1.1: legacy release compatibility shims > -------------------------------------------------------------- > ... > --- libegacy.a --- > building static egacy library > ar -crD libegacy.a `NM=3D'nm' NMFLAGS=3D'' lorder dummy.o | tsort = -q` > Segmentation fault (core dumped) > *** [libegacy.a] Error code 139 >=20 >=20 > In __archive_write_allocate_filter(), a->filter_last was pointing to > archive_write_ar_header(). a->format_write_header should have pointed > to this function. The offset between these two fields in struct = archive > is 48 bytes. Sure enough, that structure recently grew by 48 bytes. >=20 > This would seem to indicate that ar (or libarchive.a) was built with > mismatched objects. Unfortunately, I don't have good records of what > build options and flags I used. I /think/ I used either > -DWITH_SYSTEM_COMPILER or no options at all. The build of 'ar' shouldn't matter since it's a client of libarchive and libarchive clients do not ever see or manipulate the internals of struct archive_write. The problem would be with the build of the libarchive library. It sounds like you somehow had a stale archive_write_set_format_ar.o that did not get rebuilt when archive_write_private.h got updated = recently. If you still have the /usr/obj tree around, could you check the dates on = these files: archive_write_set_format_ar.o (in /usr/obj) archive_write_private.h (in /usr/src) If those dates are in the wrong order (the .o should be newer), then the make definitely went awry somewhere. Tim From owner-freebsd-current@freebsd.org Sat Jun 4 05:52: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 F1DA9B691F2 for ; Sat, 4 Jun 2016 05:52:31 +0000 (UTC) (envelope-from mmacy@nextbsd.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 E2B5E106D for ; Sat, 4 Jun 2016 05:52:31 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id E21A2B691F1; Sat, 4 Jun 2016 05:52:31 +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 E1CD2B691F0 for ; Sat, 4 Jun 2016 05:52:31 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BDE9B106B for ; Sat, 4 Jun 2016 05:52:31 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1465019544943630.8345131864884; Fri, 3 Jun 2016 22:52:24 -0700 (PDT) Date: Fri, 03 Jun 2016 22:52:24 -0700 From: Matthew Macy To: "current@freebsd.org" Message-ID: <15519f8353d.b6910d38109412.7320644652365100345@nextbsd.org> Subject: latest memstick image fails to mountroot by default on Thinkpad e565 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 05:52:32 -0000 In order to boot USB reliably on recent laptop hardware (both my thinkpad and XPS13 need this) you need to add the following to the installer images loader.conf: kern.cam.boot_delay="10000" kern.cam.scsi_delay="3000" From owner-freebsd-current@freebsd.org Sat Jun 4 06:58: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 526C2B682B4 for ; Sat, 4 Jun 2016 06:58:44 +0000 (UTC) (envelope-from kmacybsd@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 309CA1EA1 for ; Sat, 4 Jun 2016 06:58:44 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 2C208B682B2; Sat, 4 Jun 2016 06:58:44 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2BC9DB682B1 for ; Sat, 4 Jun 2016 06:58:44 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 EC5181E9E for ; Sat, 4 Jun 2016 06:58:43 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by mail-it0-x229.google.com with SMTP id f67so6555447ith.1 for ; Fri, 03 Jun 2016 23:58:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc; bh=0ZingX0SAIaWyNFekefv47gsup/sEkR51bs5ky7cvDo=; b=VnVTeTYb6Bk3B9efo3NFAcrAdW+G1e0dMM2SkoRukIO6Afv/fK63QUAAknVrCS+9OS SCq4sTNjvW26EMr2AvDJu7IBFvwSnyV+7IVfwnyy47FTBQjybM+pvSu4xHuimhL/HtvQ yBUTPrZSNm97hYPeEdhEDurxQUIMfdwdgVSW6Iu459Qvql9vXpR6lOwEs2MzQF3blCtG LnL+6HQmJiKolshowdl1qqR5Oq4TTfZWfarpioADiWSzhgBE6igaZyo2053Z/AsT6ArQ Mg4C46x4LUST695GdUafl4SU165Oz+sVrBjIWU47oRblNdhBBwY++VzjKNtTTgGBoGOs CMYQ== 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:date:message-id:subject:from :to:cc; bh=0ZingX0SAIaWyNFekefv47gsup/sEkR51bs5ky7cvDo=; b=G1kop5bgvVjXr4piW+891HmWv8Yha0YIP+inOY1Xv69EfA1pdnngdTiUtxREs7OSjT 1byGyHFxtjVAhvC+00tIXK3rx2hNDIrcInLHzgq3ygFUF3PXclRRxutM2FtFdJR4Vm0l wwnqttaJFLIb/s7uIB4bIMSkxFhbF/iRoaw2v+cB91RctlvMbcQipV+W1PoW2GNIpY7l AJrIBa2qPTPqdE5e8twKW5EdsvVVOCSsYy2W8Vi3VS4W0FV4iJY/qnoFvXRZ98O3VqSC oJ+a8IcMXnvWlzuQwaboCWHNzkJO/Rl33nhDW6FaTGe8y1fIO1wzIo4xnG0gh7atg2pV D3jQ== X-Gm-Message-State: ALyK8tIi2dfCB5NehsOIO0Ia29HzUzpw2ld1g+o6WmPy8SZQ1YJpmEmtlnI740AQMZB7Y5TOmszGYGpaVFjBuQ== MIME-Version: 1.0 X-Received: by 10.36.208.135 with SMTP id m129mr4176261itg.56.1465023523382; Fri, 03 Jun 2016 23:58:43 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.107.10.66 with HTTP; Fri, 3 Jun 2016 23:58:43 -0700 (PDT) Date: Fri, 3 Jun 2016 23:58:43 -0700 X-Google-Sender-Auth: SwnaYiimeZ4t2uh_mfEsoHuBlYs Message-ID: Subject: Latest freebsd installer memstick image fails to mountroot by default on Thinkpad e565 From: "K. Macy" To: Matthew Macy Cc: "current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 06:58:44 -0000 Just to clarify I'm talking about BSD install images, not my i915 tester. On Friday, June 3, 2016, Matthew Macy wrote: > > In order to boot USB reliably on recent laptop hardware (both my thinkpad > and XPS13 need this) you need to add the following to the installer images > loader.conf: > > kern.cam.boot_delay="10000" > kern.cam.scsi_delay="3000" > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org > " > From owner-freebsd-current@freebsd.org Sat Jun 4 07:17:41 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 945F4B68ED3 for ; Sat, 4 Jun 2016 07:17:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-180.reflexion.net [208.70.211.180]) (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 413DA1A3B for ; Sat, 4 Jun 2016 07:17:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17473 invoked from network); 4 Jun 2016 07:18:04 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 4 Jun 2016 07:18:04 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Sat, 04 Jun 2016 03:17:38 -0400 (EDT) Received: (qmail 25893 invoked from network); 4 Jun 2016 07:17:38 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 4 Jun 2016 07:17:38 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.104] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id C8580B1E001; Sat, 4 Jun 2016 00:17:32 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [CFT] WITH_META_MODE: Working incremental build [only on i386 and amd64] [filemon fails to load on powerpc64] From: Mark Millard In-Reply-To: <39d3c132-cdac-8c9a-c580-82d18f071699@FreeBSD.org> Date: Sat, 4 Jun 2016 00:17:31 -0700 Cc: FreeBSD Current , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <1D3FECB2-D7D9-491E-9BDD-C34436EFB333@dsl-only.net> References: <7748cc71-3788-22ae-fcb2-699eae529310@FreeBSD.org> <9A1A624D-9286-4C0F-A435-D590E07C1149@dsl-only.net> <39d3c132-cdac-8c9a-c580-82d18f071699@FreeBSD.org> To: Bryan Drewery X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 07:17:41 -0000 On 2016-Jun-2, at 12:36 PM, Bryan Drewery = wrote: > On 6/1/2016 6:39 PM, Mark Millard wrote: >> while filemon.ko now exists: >>> # ls -l /boot/*/filemon* >>> -r-xr-xr-x 1 root wheel 32064 Jun 1 17:59 = /boot/kernel/filemon.ko >> it does not load: >>> # kldload -n filemon >>> kldload: can't load filemon: No such file or directory >>> # dmesg | grep link_elf >>> link_elf: symbol elf64_freebsd_sysvec undefined >> So no WITH_META_MODE=3Dyes yet for powerpc64. >=20 >=20 > Please try this patch: http://dpaste.com/37VP5MD.txt >=20 > And once you have filemon loaded please run this basic test script. = It > should return no output and a zero exit status. >=20 > http://dpaste.com/23NTA0A.txt >=20 > Just sh file it. >=20 > --=20 > Regards, > Bryan Drewery Unfortunately other things interfered and I was unable to do this before = temporarily losing access to the powerpc and powerpc64 boxes --for what = will probably be weeks or months. So for now it is the end of my native-testing for powerpc64 and powerpc. I do not know if anyone else has an appropriate context and willingness = to do this specific test or not. For the duration I should still be able to do amd64 -> powerpc64 or = powerpc cross builds (buildworld buildkernel), although likely with less = time and more delay for doing so. I am hoping to still have rpi2 access for armv6/v7 native use. But I've = yet to make the soft-float to hard-float leap: I focused primarily on = the powerpc64 and powerpc use, knowing up front of the pending = temporarily-unavailable status. Thanks for all the work on the build system by you and others. = Originally I had a bunch of workarounds in my src.conf files to avoid = problems that occurred for the likes of a libc++-based, xtoolchain-based = so-called "cross build" (self-hosted), powerpc64 environment (no gcc = 4.2.1 and clang not working for such yet). Far more works implicitly in = src.conf files for such a context now. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sat Jun 4 07:18: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 20EAAB68F6C for ; Sat, 4 Jun 2016 07:18:36 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003: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 DB3821B9F for ; Sat, 4 Jun 2016 07:18:35 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-oi0-x230.google.com with SMTP id j1so158941816oih.3 for ; Sat, 04 Jun 2016 00:18:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=OBHWTDeArBkTWzCIzuAQjGAQVtG05fVWArCQgeOuV9k=; b=2FipbG0rD1vqW2Q5HL5os/zi5/VfnpopMflqhRYuDTE5RfTxa3awRpOLtWfXsRzFE/ seM/NU/8EhMIuxGwWV8O0e3w4d0A2mw9XQz8GDsuHfdxS3M0ZqCBiHPgAnFu0QDXBQ/g Ucck3XsQN9VBNmje1juvYf/JAHh6ZsgNvSNLb6jJfkIpUrYLd0/2FbVTYgdTt8u/VFmu rth5lD1syQM05avh3y7yO956orfXBGHSVi4VRJa5pPWpHf1lgVq+AasdSDlWexMAygCc MFyrxbroJAa6ZpsxjCkkfOCYq7pN9cvGdIqXkGSwBN8JqcrcAL/5iE9beb6Ueyr7Yteq /+OA== 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; bh=OBHWTDeArBkTWzCIzuAQjGAQVtG05fVWArCQgeOuV9k=; b=VLKlqMLFvzmYV1HdGBJ99K0OPDsG3CNCjYxGZpYrNBRfIz6v1pdgCKQxhB2enwxLUP dI7PZ905izcnwDqX8Lm59rJVlbHD8+8euvemszsuOYs9I6F3SeQMbWJz8H+JbavMNtUY 2Dloi7WvRJjSfRRkVhtQ6WpCL3b/2RzDBGOiTILyrEPC2SKypDHfnK1KavXJrEtYJz4Z 4XmX4jUa0Pf7P5vZKHvzqWuCrdmgetwbVDwm3oYyMpXGZq1rravUU89bRWotz8pyT+DV 3kjR+l8B5KPo4UBT/RBbwgntjmwGoTjJ3AxRrh24TmBMJKziTa7VLWSp8QQ/KC3SBAlk n18A== X-Gm-Message-State: ALyK8tKn7JigtFCOT7J73pq6kN/RKpzgL+Q6V2eWal36AKkcFgsCfvZncZ9JmXaMhm5gcxFTNPM7XGgtmUP+GiJn MIME-Version: 1.0 X-Received: by 10.157.15.73 with SMTP id 67mr549802ott.15.1465024715084; Sat, 04 Jun 2016 00:18:35 -0700 (PDT) Sender: sobomax@sippysoft.com Received: by 10.157.56.70 with HTTP; Sat, 4 Jun 2016 00:18:34 -0700 (PDT) Received: by 10.157.56.70 with HTTP; Sat, 4 Jun 2016 00:18:34 -0700 (PDT) In-Reply-To: <20160603171809.GX38613@kib.kiev.ua> References: <20160603050628.GV38613@kib.kiev.ua> <20160603171809.GX38613@kib.kiev.ua> Date: Sat, 4 Jun 2016 00:18:34 -0700 X-Google-Sender-Auth: 7Y1DwyWNkm8bt3LGpVvUbXDU4Gs Message-ID: Subject: Re: CLOCK_MONOTONIC / CLOCK_UPTIME is not really monotonic between threads From: Maxim Sobolev To: Konstantin Belousov , Adrian Chadd Cc: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 07:18:36 -0000 Yeah, indeed false positive, app error. Sorry for noise and thanks for feedback. -Max On Jun 3, 2016 10:18 AM, "Konstantin Belousov" wrote: > On Fri, Jun 03, 2016 at 08:04:29AM -0700, Maxim Sobolev wrote: > > Konstantin, > > > > Thanks for taking your time looking into it and sorry for somewhat messy > > problem report. I've been trying to fix that problem all day yesterday > > thinking it's just application logic that is broken and indeed has been > > able to find some bigger issues that were obscuring this one. But it got > > very frustrating when the bug popped out anew at a seemingly lower level > > now. The issue that triggered this is in some high level python code. > Which > > makes it quite difficult to narrow and isolate. There is still slight > > chance that it's something about threading within the python that screws > > this up somehow, however I don't quite see how that could lead to a > > consistent result that is just off by few hundred microseconds and not in > > some random garbage. > > > > So, I take from you message, that high level > > clock_gettime(CLOCK_MONOTONIC*) is supposed to be monotonic with respect > to > > the wall time even when called in different threads? I always though it > is, > > but was not 100% sure about that and wanted to confirm it before I dive > > deeper into this and spend more time writing a test case to expose this. > Yes, CLOCK_MONOTONIC should be monotonic across all processors. > Until the time travel is made possible, of course. > > > The test case you gave me is interesting, but somewhat low-level. What I > > would do if it comes to it, is to make something that uses pthreads and > > plain clock_gettime(2). Should not be too difficult to reproduce if it's > > real issue. > The test I give you verifies clock_gettime() in several threads going > backward. > > > > > P.S. I've also tried kern.timecounter.fast_gettime=0, made no difference. > > Assuming it does not take a reboot to test it. Neither does > > switching kern.timecounter.hardware, I've tested TSC-low(1000) > > ACPI-fast(900) HPET(950) i8254(0), all are the same. > I am almost sure this is app-level issue. > > To make me confident, run the test I provided. > > From owner-freebsd-current@freebsd.org Sat Jun 4 08:12:10 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9250CB69DA0 for ; Sat, 4 Jun 2016 08:12:10 +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 554A913AD for ; Sat, 4 Jun 2016 08:12:09 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1b96gc-001Vz0-31>; Sat, 04 Jun 2016 10:12:02 +0200 Received: from x55b3b9d1.dyn.telefonica.de ([85.179.185.209] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1b96gb-000D3A-OV>; Sat, 04 Jun 2016 10:12:01 +0200 Date: Sat, 4 Jun 2016 10:11:56 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: r301305: buildkernel fails in ATH driver: if_ath_btcoex.c:237:9: error: no member named 'bt_period' in 'HAL_BT_COEX_INFO Message-ID: <20160604101156.741882d8.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/AB.+R=ib6jLf7kMeeoil/GV"; protocol="application/pgp-signature" X-Originating-IP: 85.179.185.209 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 08:12:10 -0000 --Sig_/AB.+R=ib6jLf7kMeeoil/GV Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable r301305 fails to buildkernel this morning with the lates updates. See below [...] cc -O2 -pipe -O3 -O3 -pipe -march=3Dnative -fno-strict-aliasing -Werror -= D_KERNEL -DKLD_MODULE -nostdinc -I. -I/usr/src/sys/modules/ath/../../dev/ath -I/usr/src/sys/modules/ath/../../dev/ath/ath_hal -I. -I/usr/src/sys/modules/ath/../../contrib/dev/ath/ath_hal/ -DHAVE_KERNEL_OPT= ION_HEADERS -include /usr/obj/usr/src/sys/THOR/opt_global.h -I. -I/usr/src/sys -fno-com= mon -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/usr/obj/usr/src/sys= /THOR -MD -MF.depend.if_ath_btcoex_mci.o -MTif_ath_btcoex_mci.o -mcmodel=3Dkernel -mn= o-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestand= ing -fwrapv -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-poi= nter-sign -D__printf__=3D__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-sh= ow-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-poin= ter-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=3Diso9899:1999 -c /usr/src/sys/modules/ath/../../dev/ath/if_ath_btcoex_mci.c -o if_ath_btc= oex_mci.o --- if_ath_btcoex.o --- /usr/src/sys/modules/ath/../../dev/ath/if_ath_btcoex.c:= 236:9: error: no member named 'bt_dutyCycle' in 'HAL_BT_COEX_INFO' btinfo.bt_dutyCycle = =3D 55; ~~~~~~ ^ /usr/src/sys/modules/ath/../../dev/ath/if_ath_btcoex.c:237:9: error: no m= ember named 'bt_period' in 'HAL_BT_COEX_INFO' btinfo.bt_period =3D 40; ~~~~~~ ^ 2 error= s generated. Regards, o.h. --Sig_/AB.+R=ib6jLf7kMeeoil/GV Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXUo1MAAoJEOgBcD7A/5N8Is0IAK7M0ewexAAj0DQCjeqOyQeF n9Ku0Oj5t/pKpkpYUxezaiBEtfGk+wCkUQyInBjMLJ/D8atflOQSQ/SrNvPOJTm5 EGMkaek3Qi0w4RRmU34RPpbxkF1QFCyD4FvKjCvN13YQFKyr9S2zwtpUFxhJUJNB Eu608KcdsobFHMOe/EcqEy+SmI+FV1s8rTpv/ivWvr5fgcnSmvb87QTBL63Yb3Hl 8x6HlI3kDOsiq/lCfrDkmHGH7piq6skfAZ0sh4qLfKBMyVcLydPG8urkYhImqLyV jm/aziCrpRKnfnwo0vAfMQgaobdvHMf57XFmWTbJRf3V5D8tX5BKgcpB2S5YyTA= =57P/ -----END PGP SIGNATURE----- --Sig_/AB.+R=ib6jLf7kMeeoil/GV-- From owner-freebsd-current@freebsd.org Sat Jun 4 08:56:42 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 33471B68AF9 for ; Sat, 4 Jun 2016 08:56:42 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F2DC41C2B for ; Sat, 4 Jun 2016 08:56:41 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x22e.google.com with SMTP id o189so91972887ioe.2 for ; Sat, 04 Jun 2016 01:56:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=nu17uqLKX++cYQtAtauyZV26l7IwHJjfUo23PANcAzk=; b=z8DNm0T5JSpWm2jzflp8coa726m7l34bda1Ojt9lXWhikAWIvuXsAOR+lUHkR0mJTy SJr3AyuU1gX2hCJ/JRCMdp3hnUwHadDQuNK3kuOd2wKwxAiz3N0obAYEEjsLSsYJEiWU 4yXV5hBsm9Z5d0ABEAbNm5wFvifSJu0XsVlVkREdTfWc4v+sHhgHXBvPO/4162g6Kwi2 oSagZv+iT39vIE13XvIlS+9rECZ8cefuk8N3bgYRBwsqW130WH+T13ujNBOoZ+DgGJMG wHqihfBfnW3CuSYsZvVhPHP7XnVkPrShy7yeWKYkrDtuQYeU1iepPTf7lki0NE5zKx6F 9k4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=nu17uqLKX++cYQtAtauyZV26l7IwHJjfUo23PANcAzk=; b=dhlAT7itGozX3VxKeWWJPkJC0m8QwFi1HLBy/ezktGQIf6hJr8gGD81o7lJRrouh7S A7nb9iLm+K+PNJuwn2Qdy2QWkiV+WmuQ/1tdBEskFqXUZH059rZhy7PJpjjSNav7higz jLxoRcjrz6nq5oLGo7+CKCbDuM4QnGcvAM8sgHjXCRiIV3Mw8LafC97JmCur9qbtMfYP RDlKD0EtttAb21zvNhYXor2mKSjlBbvdoD98KqfK4c3jjWOEedVIFchRiPF97Vfi03+D FE22erNHMCTQ+PFlygXbiR5MqOFQ2NE/lIAlXgDIVspasUpb+aAIFPSwoZ8OKOca9pWA cCcQ== X-Gm-Message-State: ALyK8tJQ/uPUXdxkbDbPLaWyvvwHQ/3UdOE8DpKxVgLwcv3BfBRqoU67IDUA80xNZKb7lEb2/CJ27Mqv9vR9bQ== X-Received: by 10.107.144.67 with SMTP id s64mr9752228iod.165.1465030601411; Sat, 04 Jun 2016 01:56:41 -0700 (PDT) MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.36.113.3 with HTTP; Sat, 4 Jun 2016 01:56:40 -0700 (PDT) In-Reply-To: <20160604101156.741882d8.ohartman@zedat.fu-berlin.de> References: <20160604101156.741882d8.ohartman@zedat.fu-berlin.de> From: Adrian Chadd Date: Sat, 4 Jun 2016 01:56:40 -0700 X-Google-Sender-Auth: 1v4IjKTt65vYy2XhxJgdcpvPV1c Message-ID: Subject: Re: r301305: buildkernel fails in ATH driver: if_ath_btcoex.c:237:9: error: no member named 'bt_period' in 'HAL_BT_COEX_INFO To: "O. Hartmann" Cc: FreeBSD CURRENT Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 08:56:42 -0000 Fixed! -a On 4 June 2016 at 01:11, O. Hartmann wrote: > r301305 fails to buildkernel this morning with the lates updates. > > See below > > [...] > cc -O2 -pipe -O3 -O3 -pipe -march=native -fno-strict-aliasing -Werror -D_KERNEL > -DKLD_MODULE -nostdinc -I. -I/usr/src/sys/modules/ath/../../dev/ath > -I/usr/src/sys/modules/ath/../../dev/ath/ath_hal -I. > -I/usr/src/sys/modules/ath/../../contrib/dev/ath/ath_hal/ -DHAVE_KERNEL_OPTION_HEADERS > -include /usr/obj/usr/src/sys/THOR/opt_global.h -I. -I/usr/src/sys -fno-common > -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/usr/obj/usr/src/sys/THOR -MD > -MF.depend.if_ath_btcoex_mci.o -MTif_ath_btcoex_mci.o -mcmodel=kernel -mno-red-zone > -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv > -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign > -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option > -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body > -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign > -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 > -c /usr/src/sys/modules/ath/../../dev/ath/if_ath_btcoex_mci.c -o if_ath_btcoex_mci.o --- > if_ath_btcoex.o --- /usr/src/sys/modules/ath/../../dev/ath/if_ath_btcoex.c:236:9: error: > no member named 'bt_dutyCycle' in 'HAL_BT_COEX_INFO' btinfo.bt_dutyCycle = 55; ~~~~~~ > ^ /usr/src/sys/modules/ath/../../dev/ath/if_ath_btcoex.c:237:9: error: no member named > 'bt_period' in 'HAL_BT_COEX_INFO' btinfo.bt_period = 40; ~~~~~~ ^ 2 errors generated. > > > Regards, > > o.h. From owner-freebsd-current@freebsd.org Sat Jun 4 09:16: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 F3F20B6519E for ; Sat, 4 Jun 2016 09:16:32 +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 B5C611797; Sat, 4 Jun 2016 09:16:32 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1b97h0-001kLo-FZ>; Sat, 04 Jun 2016 11:16:30 +0200 Received: from x55b3b9d1.dyn.telefonica.de ([85.179.185.209] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1b97h0-000Ht6-4i>; Sat, 04 Jun 2016 11:16:30 +0200 Date: Sat, 4 Jun 2016 11:16:24 +0200 From: "O. Hartmann" To: Adrian Chadd Cc: FreeBSD CURRENT Subject: Re: r301305: buildkernel fails in ATH driver: if_ath_btcoex.c:237:9: error: no member named 'bt_period' in 'HAL_BT_COEX_INFO Message-ID: <20160604111624.52e8f997.ohartman@zedat.fu-berlin.de> In-Reply-To: References: <20160604101156.741882d8.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/k=oAgGc2dM=ic/5hjPaduvC"; protocol="application/pgp-signature" X-Originating-IP: 85.179.185.209 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 09:16:33 -0000 --Sig_/k=oAgGc2dM=ic/5hjPaduvC Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Sat, 4 Jun 2016 01:56:40 -0700 Adrian Chadd schrieb: > Fixed! >=20 >=20 > -a >=20 >=20 > On 4 June 2016 at 01:11, O. Hartmann wrote: > > r301305 fails to buildkernel this morning with the lates updates. > > > > See below > > > > [...] > > cc -O2 -pipe -O3 -O3 -pipe -march=3Dnative -fno-strict-aliasing -Werr= or -D_KERNEL > > -DKLD_MODULE -nostdinc -I. -I/usr/src/sys/modules/ath/../../dev/ath > > -I/usr/src/sys/modules/ath/../../dev/ath/ath_hal -I. > > -I/usr/src/sys/modules/ath/../../contrib/dev/ath/ath_hal/ -DHAVE_KERNEL= _OPTION_HEADERS > > -include /usr/obj/usr/src/sys/THOR/opt_global.h -I. -I/usr/src/sys -fno= -common > > -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/usr/obj/usr/src= /sys/THOR -MD > > -MF.depend.if_ath_btcoex_mci.o -MTif_ath_btcoex_mci.o -mcmodel=3Dkernel= -mno-red-zone > > -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffrees= tanding -fwrapv > > -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-pro= totypes > > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno= -pointer-sign > > -D__printf__=3D__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostic= s-show-option > > -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-= body > > -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-= pointer-sign > > -Wno-error-shift-negative-value -mno-aes -mno-avx -std=3Diso9899:1999 > > -c /usr/src/sys/modules/ath/../../dev/ath/if_ath_btcoex_mci.c -o if_ath= _btcoex_mci.o > > --- if_ath_btcoex.o --- /usr/src/sys/modules/ath/../../dev/ath/if_ath_b= tcoex.c:236:9: > > error: no member named 'bt_dutyCycle' in 'HAL_BT_COEX_INFO' btinfo.bt_d= utyCycle =3D 55; > > ~~~~~~ ^ /usr/src/sys/modules/ath/../../dev/ath/if_ath_btcoex.c:237:9: = error: no > > member named 'bt_period' in 'HAL_BT_COEX_INFO' btinfo.bt_period =3D 40;= ~~~~~~ ^ 2 > > errors generated. > > > > > > Regards, > > > > o.h. =20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" Great! Thank you. --Sig_/k=oAgGc2dM=ic/5hjPaduvC Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXUpxpAAoJEOgBcD7A/5N8q6cIAJ5mokAhKhJoC3kwz9IWnPLA SnCki9rH78V8xwOttiF3PQnO17BBej8fFKyt8jGv6Y43ahvx53cIEeBcx3jBKdim T6ldEYfgjFlsL79uay0+nROwtzlKjgpmagPPE3IpdnvyVBHrYqs2U9+4BMFqazc6 hJylqfSJGeXy0zk1fw+Pur6M7f8/AJSJ9WJngsyxPzCtC6BtKZrAv+Qw1ErPuB2f vDC5yr8ZCOmFLG1WNkqFH5jFcf0wxEZcPbcEcMWUmkt1Q/T6AQYZifi0XTGH5Aqi qkJTp0mCOhNS8uCEg21W2Res2cp/T4h2WhkttCjldIDVTeoZU+oZNkpwPVwwQD8= =Cw6S -----END PGP SIGNATURE----- --Sig_/k=oAgGc2dM=ic/5hjPaduvC-- From owner-freebsd-current@freebsd.org Sat Jun 4 09:32:41 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CB613B6579B for ; Sat, 4 Jun 2016 09:32:41 +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 76AF3118C; Sat, 4 Jun 2016 09:32:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u549Wamj043330 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 4 Jun 2016 12:32:36 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u549Wamj043330 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u549WaVQ043329; Sat, 4 Jun 2016 12:32:36 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 4 Jun 2016 12:32:36 +0300 From: Konstantin Belousov To: Mark Johnston Cc: freebsd-current@FreeBSD.org Subject: Re: thread suspension when dumping core Message-ID: <20160604093236.GA38613@kib.kiev.ua> References: <20160604022347.GA1096@wkstn-mjohnston.west.isilon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160604022347.GA1096@wkstn-mjohnston.west.isilon.com> User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 09:32:41 -0000 On Fri, Jun 03, 2016 at 07:23:47PM -0700, Mark Johnston wrote: > Hi, > > I've recently observed a hang in a multi-threaded process that had hit > an assertion failure and was attempting to dump core. One thread was > sleeping interruptibly on an advisory lock with TDF_SBDRY set (our > filesystem sets VFCF_SBDRY). SIGABRT caused the receipient thread to > suspend other threads with thread_single(SINGLE_NO_EXIT), which fails > to interrupt the sleeping thread, resulting in the hang. > > My question is, why does the SA_CORE handler not force all threads to > the user boundary before attempting to dump core? It must do so later > anyway in order to exit. As I understand it, TDF_SBDRY is intended to > avoid deadlocks that can occur when stopping a process, but in this > case we don't stop the process with the intention of resuming it, so it > seems erroneous to apply this flag. Does your fs both set TDF_SBDRY and call lf_advlock()/lf_advlockasync() ? This cannot work, regardless of the mode of single-threading. TDF_SBDRY makes such sleep non-interruptible by any single-threading request, on the promise that the thread owns some resources (typically vnode locks). I.e. changing the mode would not help. I see two reasons to use SINGLE_NO_EXIT for coredumping. It allows coredump writer to record more exact state of the process into the notes. Another one is that SINGLE_NO_EXIT is generally faster and more reliable than SINGLE_BOUNDARY. Some states are already good enough for SINGLE_NO_EXIT, while require more work to get into SINGLE_BOUNDARY. In other words, core dump write starts earlier. It might be not very significant reasons. >From what I see in the code, our NFS client has similar issue of calling lf_advlock() with TDF_SBDRY set. Below is the patch to fix that. Similar bug existed in our fifofs, see r277321. diff --git a/sys/fs/nfsclient/nfs_clvnops.c b/sys/fs/nfsclient/nfs_clvnops.c index 2a8afa9..98625ee 100644 --- a/sys/fs/nfsclient/nfs_clvnops.c +++ b/sys/fs/nfsclient/nfs_clvnops.c @@ -2992,7 +2992,7 @@ nfs_advlock(struct vop_advlock_args *ap) struct proc *p = (struct proc *)ap->a_id; struct thread *td = curthread; /* XXX */ struct vattr va; - int ret, error = EOPNOTSUPP; + int sbdry, ret, error = EOPNOTSUPP; u_quad_t size; if (NFS_ISV4(vp) && (ap->a_flags & (F_POSIX | F_FLOCK)) != 0) { @@ -3087,7 +3087,10 @@ nfs_advlock(struct vop_advlock_args *ap) if ((VFSTONFS(vp->v_mount)->nm_flag & NFSMNT_NOLOCKD) != 0) { size = VTONFS(vp)->n_size; NFSVOPUNLOCK(vp, 0); + sbdry = sigallowstop(); error = lf_advlock(ap, &(vp->v_lockf), size); + if (sbdry) + sigdeferstop(); } else { if (nfs_advlock_p != NULL) error = nfs_advlock_p(ap); @@ -3114,7 +3117,7 @@ nfs_advlockasync(struct vop_advlockasync_args *ap) { struct vnode *vp = ap->a_vp; u_quad_t size; - int error; + int error, sbdry; if (NFS_ISV4(vp)) return (EOPNOTSUPP); @@ -3124,7 +3127,10 @@ nfs_advlockasync(struct vop_advlockasync_args *ap) if ((VFSTONFS(vp->v_mount)->nm_flag & NFSMNT_NOLOCKD) != 0) { size = VTONFS(vp)->n_size; NFSVOPUNLOCK(vp, 0); + sbdry = sigallowstop(); error = lf_advlockasync(ap, &(vp->v_lockf), size); + if (sbdry) + sigdeferstop(); } else { NFSVOPUNLOCK(vp, 0); error = EOPNOTSUPP; From owner-freebsd-current@freebsd.org Sat Jun 4 10:18: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 2C852B69338 for ; Sat, 4 Jun 2016 10:18:37 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E7A78197E for ; Sat, 4 Jun 2016 10:18:36 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [88.217.102.110] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1b98ex-00013a-Vv for freebsd-current@freebsd.org; Sat, 04 Jun 2016 12:18:28 +0200 Received: from localhost.my.domain (c720-r292778-amd64 [127.0.0.1]) by localhost.unixarea.de (8.15.2/8.14.9) with ESMTPS id u54AIR2U004701 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 4 Jun 2016 12:18:27 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.15.2/8.14.9/Submit) id u54AIQDY004700 for freebsd-current@freebsd.org; Sat, 4 Jun 2016 12:18:26 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sat, 4 Jun 2016 12:18:26 +0200 From: Matthias Apitz To: freebsd-current@freebsd.org Subject: r300951: mountroot: waiting for device /dev/ad4s1a... Message-ID: <20160604101826.GA4660@c720-r292778-amd64> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Operating-System: FreeBSD 11.0-CURRENT r292778 (amd64) User-Agent: Mutt/1.5.24 (2015-08-30) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 88.217.102.110 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 10:18:37 -0000 Hello, I'm trying to update my laptop Acer Aspire One D250 from r269739 to r300951. After 'make installkernel' it hangs for ever on reboot, waiting for the device /dev/ad4s1a. The old kernel boots fine. What can I do? Thx matthias -- Matthias Apitz, ✉ guru@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 "Die Verkaufsschlager des Buchmarkts geben Auskunft über den Zustand einer Gesellschaft bzw. sind, was diese Zeiten angeht, Gradmesser fortschreitenden Schwachsinns. ..." (jW 19.05.2016) From owner-freebsd-current@freebsd.org Sat Jun 4 11:28: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 0B7EFB6949C for ; Sat, 4 Jun 2016 11:28:12 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C5B481782 for ; Sat, 4 Jun 2016 11:28:11 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [88.217.102.110] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1b99kN-0005QA-UA for freebsd-current@freebsd.org; Sat, 04 Jun 2016 13:28:08 +0200 Received: from localhost.my.domain (c720-r292778-amd64 [127.0.0.1]) by localhost.unixarea.de (8.15.2/8.14.9) with ESMTPS id u54BS7u2005138 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 4 Jun 2016 13:28:07 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.15.2/8.14.9/Submit) id u54BS6sj005137 for freebsd-current@freebsd.org; Sat, 4 Jun 2016 13:28:06 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sat, 4 Jun 2016 13:28:06 +0200 From: Matthias Apitz To: freebsd-current@freebsd.org Subject: Re: r300951: mountroot: waiting for device /dev/ad4s1a... Message-ID: <20160604112806.GA5079@c720-r292778-amd64> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , freebsd-current@freebsd.org References: <20160604101826.GA4660@c720-r292778-amd64> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160604101826.GA4660@c720-r292778-amd64> X-Operating-System: FreeBSD 11.0-CURRENT r292778 (amd64) User-Agent: Mutt/1.5.24 (2015-08-30) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 88.217.102.110 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 11:28:12 -0000 El día Saturday, June 04, 2016 a las 12:18:26PM +0200, Matthias Apitz escribió: > > Hello, > > I'm trying to update my laptop Acer Aspire One D250 from r269739 to > r300951. After 'make installkernel' it hangs for ever on reboot, waiting > for the device /dev/ad4s1a. The old kernel boots fine. short before mounting root are two error messages: taskqgroup_adjust failed cnt: 1 stride: 1 mp_ncpus: 1 smp_started: 0 taskqgroup_adjust failed cnt: 1 stride: 1 mp_ncpus: 1 smp_started: 0 Timecounter "TSC" frequency 1596219540 Hz quality 1000 Trying to mount root drom ufs:/dev/ad4s1a [rw]... mountroot: waiting for device /dev/ad4s1a ... Mounting from ufs:/dev/ad4s1a failed with error 19. Than it goes into the manual dialog to specify the root device but at the prompt mountroot> the kernel does not echo any typed chars; matthias -- Matthias Apitz, ✉ guru@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 "Die Verkaufsschlager des Buchmarkts geben Auskunft über den Zustand einer Gesellschaft bzw. sind, was diese Zeiten angeht, Gradmesser fortschreitenden Schwachsinns. ..." (jW 19.05.2016) From owner-freebsd-current@freebsd.org Sat Jun 4 11:47: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 E29D2B697B5 for ; Sat, 4 Jun 2016 11:47:33 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id 5531C1EAA for ; Sat, 4 Jun 2016 11:47:32 +0000 (UTC) (envelope-from freebsd@grem.de) Received: (qmail 97521 invoked by uid 89); 4 Jun 2016 11:40:49 -0000 Received: from unknown (HELO bsd64.grem.de) (mg@grem.de@88.217.181.157) by mail.grem.de with ESMTPA; 4 Jun 2016 11:40:49 -0000 Date: Sat, 4 Jun 2016 13:40:46 +0200 From: Michael Gmelin To: Matthias Apitz Cc: freebsd-current@freebsd.org Subject: Re: r300951: mountroot: waiting for device /dev/ad4s1a... Message-ID: <20160604134046.00fc182f@bsd64.grem.de> In-Reply-To: <20160604112806.GA5079@c720-r292778-amd64> References: <20160604101826.GA4660@c720-r292778-amd64> <20160604112806.GA5079@c720-r292778-amd64> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd10.2) X-Face: $wrgCtfdVw_H9WAY?S&9+/F"!41z'L$uo*WzT8miX?kZ~W~Lr5W7v?j0Sde\mwB&/ypo^}> +a'4xMc^^KroE~+v^&^#[B">soBo1y6(TW6#UZiC]o>C6`ej+i Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWJBwe5BQDl LASZU0/LTEWEfHbyj0Txi32+sKrp1Mv944X8/fm1rS+cAAAACXBIWXMAAAsTAAAL EwEAmpwYAAAAB3RJTUUH3wESCxwC7OBhbgAAACFpVFh0Q29tbWVudAAAAAAAQ3Jl YXRlZCB3aXRoIFRoZSBHSU1QbbCXAAAAAghJREFUOMu11DFvEzEUAGCfEhBVFzuq AKkLd0O6VrIQsLXVSZXoWE5N1K3DobBBA9fQpRWc8OkWouaIjedWKiyREOKs+3PY fvalCNjgLVHeF7/3bMtBzV8C/VsQ8tecEgCcDgrzjekwKZ7TwsJZd/ywEKwwP+ZM 8P3drTsAwWn2mpWuDDuYiK1bFs6De0KUUFw0tWxm+D4AIhuuvZqtyWYeO7jQ4Aea 7jUqI+ixhQoHex4WshEvSXdood7stlv4oSuFOC4tqGcr0NjEqXgV4mMJO38nld4+ xKNxRDon7khyKVqY7YR4d+Cg0OMrkWXZOM7YDkEfKiilCn1qYv4mighZiynuHHOA Wq9QJq+BIES7lMFUtcikMnkDGHUoncA+uHgrP0ctIEqfwLHzeSo+eUA66AqzwN6n 2ZHJhw6Qh/PoyC/QENyEyC/AyNjq74Bs+3UH0xYwzDUC4B97HgLocg1QLYgDDO1v f3UX9Y307Ew4AHh67YAFFsxEpkXwpXY3eIgMhAAE3R19L919nNnuD2wlPcDE3UeT L2ytEICQib9BXgS2fU8PrD82ToYO1OEmMSnYTjSqSv9wdC0tPYC+rQRQD9ESnldF CyqfmiYW+tlALt8gH2xrMdC/youbjzPXEun+/ReXsMCDyve3dZc09fn2Oas8oXGc Jj6/fOeK5UmSMPmf/jL+GD8BEj0k/Fn6IO4AAAAASUVORK5CYII= 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.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 11:47:34 -0000 Hi Matthias, Did you try to connect an external USB keyboard? i386 or amd64? Did you do a full clean build? GENERIC or custom kernel config? - m On Sat, 4 Jun 2016 13:28:06 +0200 Matthias Apitz wrote: > El d=C3=ADa Saturday, June 04, 2016 a las 12:18:26PM +0200, Matthias Apitz > escribi=C3=B3: >=20 > >=20 > > Hello, > >=20 > > I'm trying to update my laptop Acer Aspire One D250 from r269739 to > > r300951. After 'make installkernel' it hangs for ever on reboot, > > waiting for the device /dev/ad4s1a. The old kernel boots fine. =20 >=20 > short before mounting root are two error messages: >=20 > taskqgroup_adjust failed cnt: 1 stride: 1 mp_ncpus: 1 smp_started: 0 > taskqgroup_adjust failed cnt: 1 stride: 1 mp_ncpus: 1 smp_started: 0 > Timecounter "TSC" frequency 1596219540 Hz quality 1000 > Trying to mount root drom ufs:/dev/ad4s1a [rw]... > mountroot: waiting for device /dev/ad4s1a ... > Mounting from ufs:/dev/ad4s1a failed with error 19. >=20 > Than it goes into the manual dialog to specify the root device but at > the prompt=20 >=20 > mountroot> =20 >=20 > the kernel does not echo any typed chars; >=20 > matthias --=20 Michael Gmelin From owner-freebsd-current@freebsd.org Sat Jun 4 11:48:55 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82165B6988B for ; Sat, 4 Jun 2016 11:48:55 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 474921054 for ; Sat, 4 Jun 2016 11:48:55 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [88.217.102.110] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1b9A4T-00048K-7k for freebsd-current@freebsd.org; Sat, 04 Jun 2016 13:48:53 +0200 Received: from localhost.my.domain (c720-r292778-amd64 [127.0.0.1]) by localhost.unixarea.de (8.15.2/8.14.9) with ESMTPS id u54Bmqhp005311 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 4 Jun 2016 13:48:52 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.15.2/8.14.9/Submit) id u54Bmq1G005310 for freebsd-current@freebsd.org; Sat, 4 Jun 2016 13:48:52 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sat, 4 Jun 2016 13:48:52 +0200 From: Matthias Apitz To: freebsd-current@freebsd.org Subject: Re: r300951: mountroot: waiting for device /dev/ad4s1a... Message-ID: <20160604114852.GA5261@c720-r292778-amd64> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , freebsd-current@freebsd.org References: <20160604101826.GA4660@c720-r292778-amd64> <20160604112806.GA5079@c720-r292778-amd64> <20160604134046.00fc182f@bsd64.grem.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160604134046.00fc182f@bsd64.grem.de> X-Operating-System: FreeBSD 11.0-CURRENT r292778 (amd64) User-Agent: Mutt/1.5.24 (2015-08-30) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 88.217.102.110 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 11:48:55 -0000 Hi Michael, El día Saturday, June 04, 2016 a las 01:40:46PM +0200, Michael Gmelin escribió: > Hi Matthias, > > Did you try to connect an external USB keyboard? no; it uses the laptop onboard keyboard; > i386 or amd64? i386; > Did you do a full clean build? > GENERIC or custom kernel config? yes, clean 'make buildkernel KERNCONF=GENERIC' interestingly: I can type at the prompt 'mountroot> ' into the dark and always when I press Ctrl the chars are written to the screen and so I can specify 'ufs:/dev/ad4s1a' which than leads to the same error 19. I can as well boot an USB key with the old kernel r269739, mount /dev/ad4s1a to /mnt, all fine; I did even a fsck while booted from USB on /dev/ad4s1a. The FS is clean. matthias -- Matthias Apitz, ✉ guru@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 "Die Verkaufsschlager des Buchmarkts geben Auskunft über den Zustand einer Gesellschaft bzw. sind, was diese Zeiten angeht, Gradmesser fortschreitenden Schwachsinns. ..." (jW 19.05.2016) From owner-freebsd-current@freebsd.org Sat Jun 4 10:58: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 B7F41B69CC0 for ; Sat, 4 Jun 2016 10:58:12 +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 A91001A66; Sat, 4 Jun 2016 10:58:12 +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 8F9BD13D3; Sat, 4 Jun 2016 10:58:12 +0000 (UTC) Date: Sat, 4 Jun 2016 10:58:05 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: vangyzen@FreeBSD.org, garga@FreeBSD.org, skra@FreeBSD.org, zbb@FreeBSD.org, cy@FreeBSD.org, avg@FreeBSD.org, pfg@FreeBSD.org, royger@FreeBSD.org, dim@FreeBSD.org, cem@FreeBSD.org, mav@FreeBSD.org, adrian@FreeBSD.org, bz@FreeBSD.org, kib@FreeBSD.org, arybchik@FreeBSD.org, andrew@FreeBSD.org, bdrewery@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <190839510.24.1465037892652.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_amd64_gcc - Build #1274 - Failure MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_amd64_gcc X-Jenkins-Result: FAILURE Precedence: bulk X-Mailman-Approved-At: Sat, 04 Jun 2016 11:49:57 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 10:58:12 -0000 FreeBSD_HEAD_amd64_gcc - Build #1274 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1= 274/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/127= 4/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1274= /console Change summaries: 301309 by arybchik: sfxge(4): always be ready to receive batched events When the low-latency firmware variant is running, it is reported as not being capable of batching RX events, but it can still do so if the FORCE_EV_MERGING flag is set on an RXQ. Therefore we need to handle batched RX events even if the capability isn't set. If this bug is fixed in the firmware such that the capability is set even when running the low-latency firmware variant, it will almost always be reported so I don't think we lose much by removing the check. Submitted by: Mark Spender Sponsored by: Solarflare Communications, Inc. MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D6705 301308 by arybchik: sfxge(4): add helper to compute timer quantum This also adjusts the timer values used to match the Linux net driver implementation: a) non-zero time intervals should result in at least one quantum b) timer load/reload values are only zero biased for Falcon/Siena Submitted by: Andy Moreton Sponsored by: Solarflare Communications, Inc. MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D6704 301307 by adrian: [ath] remove now unused parameters. These will move to being part of the driver btcoex stuff I'm working on, since the HAL doesn't know what to do with them. 301306 by andrew: Use the UEFI event timer to update the time on arm and arm64. The current code uses the GetTime function from the Runtime Service, however this has been shown to not return a useable time on many arm64 UEFI implementations. Reviewed by:=09jhb, smh Sponsored by:=09ABT Systems Ltd Differential Revision:=09https://reviews.freebsd.org/D6709 301305 by adrian: [ath_hal] add STOMP_AUDIO for AR9462/QCA9565. Obtained from:=09Linux ath9k 301304 by adrian: [ath_hal] add placeholders for AUDIO stomp for Kite/Kiwi. It just stomps all; which is enough for some testing. 301303 by adrian: [ath_hal] add BTCOEX_STOMP_AUDIO; delete unused methods. 301302 by adrian: [run] fix TSF locking in RX radiotap. Submitted by:=09Imre Vadasz 301300 by cem: ioat(4): Always log capabilities on attach Different, relatively recent Intel Xeon hardware support radically differen= t features. E.g., BDX support CRC32 while BDX-DE does not. Reviewed by:=09rpokala (spiritually) Sponsored by:=09EMC / Isilon Storage Division 301297 by cem: ioat(4): Export the number of available channels Sponsored by:=09EMC / Isilon Storage Division 301296 by cem: ioat(4): Make channel indices unsigned Sponsored by:=09EMC / Isilon Storage Division 301295 by cy: Enable daily_ntpd_leapfile_enable by default. Otherwise an expired leapfile will be ignored and ntpd will behave as if it has no leapfile. While here, remove an extraneous blank line. Suggested by:=09ache MFC after:=091 week 301293 by mav: When negotiating NTB_SB01BASE_LOCKUP workaround, don't try to limit the BAR size to 1MB. According to Xeon v3 specifications and my tests, that size register is write-once and so not writeable after BIOS written it. Instead of that, make the code work with BAR of any sufficient size, properly calculating offset within its base. It also simplifies the code. Discussed with:=09cem MFC after:=092 weeks Sponsored by:=09iXsystems, Inc. 301292 by mav: When negotiating MSIX parameters, give other head time to see our NTB_MSIX_RECEIVED status, before making upper layers overwrite it. This is not completely perfect, but now it works better then before. MFC after:=092 weeks Sponsored by:=09iXsystems, Inc. 301291 by pfg: libiberty: prevent integer overflow. Take care of very old bug leading to heap-buffer overflow by processing certain file headers via bfd binary. PR:=09=09200888 Obtained from:=09OpenBSD MFC after:=092 weeks 301290 by bdrewery: WITH_META_MODE: Avoid "building" .depend if there is nothing to do. This avoids 'Building /path/.depend' when it will not actually produce a file. Sponsored by:=09EMC / Isilon Storage Division 301289 by pfg: MFV r300961: one-true-awk: replace 0 with NULL for pointers Also remove a redundant semicolon. 301288 by pfg: tegra124: use roundup/rounddown macros from . 301287 by bdrewery: WITHOUT_CROSS_COMPILER: Fix installworld. Since no WORLDTMP/usr/bin/cc is created, cc cannot be found during installworld time since /usr/bin is not in the PATH. Pass along the known compiler metadata to allow installworld to work. The same fix was used for WITH_SYSTEM_COMPILER. A better route would be to store a cookie in buildworld containing this compiler metadata and then using that at install time, rather than rerunning cc. Reported by:=09Mark Millard Sponsored by:=09EMC / Isilon Storage Division 301286 by bdrewery: WITH_CCACHE_BUILD + WITH_META_MODE: Ignore ccache changes. Ccache will not affect the output of the objects, so just ignore it for meta mode handling. This avoids having everything rebuild if ccache is updated. Sponsored by:=09EMC / Isilon Storage Division 301285 by bdrewery: WITH_META_MODE: Don't expect meta files for side-effect generated files. The first file in these lists will generate everything else so only it should be getting a .meta file. With bmake's missing=3Dyes meta feature these would otherwise cause a rebuild without the .NOMETA hint. Sponsored by:=09EMC / Isilon Storage Division 301284 by bdrewery: Revert r301079. This breaks cross-building with WITH_META_MODE since it will rebuild 'build-tools' during the 'everything' phase. A more proper fix is coming to bmake to implicitly require .META unless .NOMETA (and other restrictions) are in place. 301283 by bdrewery: DIRDEPS_BUILD: Connect new directories and update dependencies. Sponsored by:=09EMC / Isilon Storage Division 301282 by zbb: Use proper interface for FDT parsing and memory mapping in CESA Improvements after r301220. Bus space methods are not called so simple pmap_mapdev will suffice. Use OF_getencprop to get buffer with already converted endianess. Pointed out by: ian Submitted by: Michal Stanek Obtained from: Semihalf 301281 by zbb: Use nitems() macro instead of re-inventing it Fixed after r301221. Pointed out by:=09oshogbo Submitted by:=09Michal Stanek Obtained from:=09Semihalf 301280 by garga: One of the already implemented options in release/Makefile is NOSRC. When it's defined, installation image is shipped without source distribution (src.txz) Add the hability of defining NOSRC in release.conf and pass it to 'make release' argument Approved by:=09gjb Sponsored by:=09Rubicon Communications (Netgate) Differential Revision:=09https://reviews.freebsd.org/D6710 301279 by kib: Trim some spaces to record correct commit message for the r301278. Reduce number of iterations used for calibrating ICR read loop. The new number of iteration still gives the same ICR latency as before, tested on Intel SandyBridge and Haswell machines, and on AMD. But it significantly reduces the unneeded pause on boot in some VMs, from ~10 secs to less then 1 sec. It was reported to occur in bhyve on AMD host. Reported and tested by:=09avg Sponsored by:=09The FreeBSD Foundation MFC after:=091 week 301278 by kib: diff --git a/sys/x86/x86/local_apic.c b/sys/x86/x86/local_apic.c index d8bda77..bb15df0 100644 --- a/sys/x86/x86/local_apic.c +++ b/sys/x86/x86/local_apic.c @@ -511,7 +511,7 @@ native_lapic_init(vm_paddr_t addr) =09} #ifdef SMP -#define=09LOOPS=091000000 +#define=09LOOPS=09100000 =09/* =09 * Calibrate the busy loop waiting for IPI ack in xAPIC mode. =09 * lapic_ipi_wait_mult contains the number of iterations which 301277 by dim: For clang, move the definition of FREEBSD_CC_VERSION into its own header file, lib/clang/freebsd_cc_version.h, instead of reusing Version.inc. The header is only included from one .cpp file in the clang tree. This minimizes the number of .cpp files that need to be rebuilt if the version is bumped. Discussed with:=09bdrewery 301276 by pfg: nxge(4): Remove useless self-assignment. Apparently the original implementation brought a self-assignment to work around some bogus lint issue that is not relevant anymore. CID:=091347070 301275 by avg: zfs: set VROOT / VV_ROOT consistently and in a single place This is a followup to r300131. A filesystem's root vnode can be reached not only through VSF_ROOT, but by other means as well. For example, via a dot-dot lookup. Also, a root vnode can get reclaimed and then re-created. For these reasons it was insufficient to clear VV_ROOT flag from a root vnode of a snapshot mounted under .zfs in zfsctl_snapdir_lookup(). So, now we set the flag in zfs_znode_sa_init() only if a vnode represent a root of a filesystem or a standalone snapshot. That is, the flag is not set for snapshots mounted under .zfs. MFC after:=092 weeks 301274 by vangyzen: Improve errno documentation in pthread_create(3) and thr_new(2) Add some missing errno values to thr_new(2) and pthread_create(3). In particular, EDEADLK was not documented in the latter. While I'm here, improve some English and cross-references. Reviewed by:=09kib Sponsored by:=09Dell Inc. Differential Revision:=09https://reviews.freebsd.org/D6663 301273 by avg: zfs_root: fix a potential root vnode reference leak It could happen in an unlikely case that we fail to lock the root vnode with requested flags (which appear to never include LK_NOWAIT). MFC after:=091 week 301271 by avg: openssl: change SHLIB_VERSION_NUMBER to reflect the reality Some consumers actually use this definition. We probably need some procedure to ensure that SHLIB_VERSION_NUMBER is updated whenever we change the library version in secure/lib/libssl/Makefile. 301270 by bz: Introduce a per-VNET flag to enable/disable netisr prcessing on that VNET. Add accessor functions to toggle the state per VNET. The base system (vnet0) will always enable itself with the normal registration. We will share the registered protocol handlers in all VNETs minimising duplication and management. Upon disabling netisr processing for a VNET drain the netisr queue from packets for that VNET. Update netisr consumers to (de)register on a per-VNET start/teardown using VNET_SYS(UN)INIT functionality. The change should be transparent for non-VIMAGE kernels. Reviewed by:=09gnn (, hiren) Obtained from:=09projects/vnet MFC after:=092 weeks Sponsored by:=09The FreeBSD Foundation Differential Revision:=09https://reviews.freebsd.org/D6691 301269 by royger: xen-blkback: fix error path on failed attach The current error path in case of failure during attach/initialization is not correct and leaves blkback in a stuck state. This is due to blkback waiting for blkfront to switch to state XenbusStateClosed, but if blkfront never attached (because the guest is not even started) it cannot possibly make it to that state. Instead just wait for the frontend to be in a state different than XenbusStateConnected in order to proceed with the shutdown. Also, it is wrong to call xbb_detach directly because it destroys the lock which can still be used by xbb_frontend_changed. Sponsored by: Citrix Systems R&D 301268 by royger: blkback: add support for hotplug scripts Hotplug scripts are needed in order to use fancy disk configurations in xl, like iSCSI disks. The job of hotplug scripts is to locally attach the disk and present it to blkback as a block device or a regular file. This change introduces a new xenstore node in the blkback hierarchy, called "physical-device-path". This is a straigh replacement for the "params" node= , which was used before. Hotplug scripts will need to read the "params" node, perform whatever actions are necessary and then write the "physical-device-path" node. The hotplug script is also in charge of detaching the disk once the domain has been shutdown. Sponsored by: Citrix Systems R&D 301267 by skra: Define irq variable only in the block where used. 301266 by skra: Postpone allocation of IRQ resource to the time when interrupt controller devices are attached. This has already been done for bus_setup_intr(). There was no doubt that if someone wants to setup an interrupt, corresponding interrupt controller device must already be attached. However, the same must be valid for allocation of an interrupt resource unless the allocation is done blindly, without any information that such interrupt even exists. While it was done this blind way before, it won't be possible after next INTRNG change. The end of the build log: [...truncated 54815 lines...] --- includes_subdir_usr.sbin/rwhod --- =3D=3D=3D> usr.sbin/rwhod (includes) --- includes_subdir_usr.bin --- --- includes_subdir_usr.bin/svn/lib --- --- includes_subdir_usr.bin/svn/lib/libsvn_delta --- =3D=3D=3D> usr.bin/svn/lib/libsvn_delta (includes) --- includes_subdir_usr.bin/svn/svndumpfilter --- =3D=3D=3D> usr.bin/svn/svndumpfilter (includes) --- includes_subdir_usr.bin/svn/svnfsfs --- =3D=3D=3D> usr.bin/svn/svnfsfs (includes) --- includes_subdir_usr.sbin --- --- includes_subdir_usr.sbin/etcupdate --- =3D=3D=3D> usr.sbin/etcupdate (includes) --- includes_subdir_usr.bin --- --- includes_subdir_usr.bin/svn/lib --- --- includes_subdir_usr.bin/svn/lib/libsvn_diff --- =3D=3D=3D> usr.bin/svn/lib/libsvn_diff (includes) --- includes_subdir_usr.bin/svn/svnlook --- =3D=3D=3D> usr.bin/svn/svnlook (includes) --- includes_subdir_usr.sbin --- --- includes_subdir_usr.sbin/etcupdate/tests --- =3D=3D=3D> usr.sbin/etcupdate/tests (includes) --- includes_subdir_usr.sbin/editmap --- =3D=3D=3D> usr.sbin/editmap (includes) --- includes_subdir_usr.bin --- --- includes_subdir_usr.bin/svn/lib --- --- includes_subdir_usr.bin/svn/lib/libsvn_fs --- =3D=3D=3D> usr.bin/svn/lib/libsvn_fs (includes) --- includes_subdir_usr.sbin --- --- includes_subdir_usr.sbin/mailstats --- =3D=3D=3D> usr.sbin/mailstats (includes) --- includes_subdir_usr.sbin/makemap --- =3D=3D=3D> usr.sbin/makemap (includes) --- includes_subdir_usr.sbin/praliases --- =3D=3D=3D> usr.sbin/praliases (includes) --- includes_subdir_usr.bin --- --- includes_subdir_usr.bin/svn/lib/libsvn_fs_fs --- =3D=3D=3D> usr.bin/svn/lib/libsvn_fs_fs (includes) --- includes_subdir_usr.sbin --- --- includes_subdir_usr.sbin/sendmail --- =3D=3D=3D> usr.sbin/sendmail (includes) --- includes_subdir_usr.sbin/tcpdchk --- =3D=3D=3D> usr.sbin/tcpdchk (includes) --- includes_subdir_usr.sbin/tcpdmatch --- =3D=3D=3D> usr.sbin/tcpdmatch (includes) --- includes_subdir_usr.bin --- --- includes_subdir_usr.bin/svn/lib/libsvn_fs_util --- =3D=3D=3D> usr.bin/svn/lib/libsvn_fs_util (includes) --- includes_subdir_usr.sbin --- --- includes_subdir_usr.sbin/timed --- =3D=3D=3D> usr.sbin/timed (includes) --- includes_subdir_usr.sbin/config --- =3D=3D=3D> usr.sbin/config (includes) --- includes_subdir_usr.bin --- --- includes_subdir_usr.bin/svn/lib/libsvn_fs_x --- =3D=3D=3D> usr.bin/svn/lib/libsvn_fs_x (includes) --- includes_subdir_usr.sbin --- --- includes_subdir_usr.sbin/timed --- --- includes_subdir_usr.sbin/timed/timed --- =3D=3D=3D> usr.sbin/timed/timed (includes) --- includes_subdir_usr.sbin/timed/timedc --- =3D=3D=3D> usr.sbin/timed/timedc (includes) --- includes_subdir_usr.bin --- --- includes_subdir_usr.bin/svn/lib/libsvn_ra --- =3D=3D=3D> usr.bin/svn/lib/libsvn_ra (includes) --- includes_subdir_usr.bin/svn/svnserve --- =3D=3D=3D> usr.bin/svn/svnserve (includes) --- includes_subdir_usr.bin/svn/lib --- --- includes_subdir_usr.bin/svn/lib/libsvn_ra_local --- =3D=3D=3D> usr.bin/svn/lib/libsvn_ra_local (includes) --- includes_subdir_usr.sbin --- --- includes_subdir_usr.sbin/crunch --- =3D=3D=3D> usr.sbin/crunch (includes) --- includes_subdir_usr.sbin/crunch/crunchgen --- =3D=3D=3D> usr.sbin/crunch/crunchgen (includes) --- includes_subdir_usr.sbin/unbound --- =3D=3D=3D> usr.sbin/unbound (includes) --- includes_subdir_usr.bin --- --- includes_subdir_usr.bin/svn/svnsync --- =3D=3D=3D> usr.bin/svn/svnsync (includes) --- includes_subdir_usr.bin/svn/lib --- --- includes_subdir_usr.bin/svn/lib/libsvn_ra_serf --- =3D=3D=3D> usr.bin/svn/lib/libsvn_ra_serf (includes) --- includes_subdir_usr.sbin --- --- includes_subdir_usr.sbin/unbound/daemon --- =3D=3D=3D> usr.sbin/unbound/daemon (includes) --- includes_subdir_usr.sbin/crunch --- --- includes_subdir_usr.sbin/crunch/crunchide --- =3D=3D=3D> usr.sbin/crunch/crunchide (includes) --- includes_subdir_usr.sbin/unbound --- --- includes_subdir_usr.sbin/unbound/anchor --- =3D=3D=3D> usr.sbin/unbound/anchor (includes) --- includes_subdir_usr.bin --- --- includes_subdir_usr.bin/svn/lib/libsvn_ra_svn --- =3D=3D=3D> usr.bin/svn/lib/libsvn_ra_svn (includes) --- includes_subdir_usr.bin/svn/lib/libsvn_repos --- =3D=3D=3D> usr.bin/svn/lib/libsvn_repos (includes) --- includes_subdir_usr.bin/svn/lib/libsvn_subr --- =3D=3D=3D> usr.bin/svn/lib/libsvn_subr (includes) --- includes_subdir_usr.sbin --- --- includes_subdir_usr.sbin/unbound/checkconf --- =3D=3D=3D> usr.sbin/unbound/checkconf (includes) --- includes_subdir_usr.sbin/uathload --- =3D=3D=3D> usr.sbin/uathload (includes) --- includes_subdir_usr.bin --- --- includes_subdir_usr.bin/svn/svnversion --- =3D=3D=3D> usr.bin/svn/svnversion (includes) --- includes_subdir_usr.sbin --- --- includes_subdir_usr.sbin/unbound --- --- includes_subdir_usr.sbin/unbound/control --- =3D=3D=3D> usr.sbin/unbound/control (includes) --- includes_subdir_usr.sbin/unbound/local-setup --- =3D=3D=3D> usr.sbin/unbound/local-setup (includes) --- includes_subdir_usr.bin --- --- includes_subdir_usr.bin/svn/lib --- --- includes_subdir_usr.bin/svn/lib/libsvn_wc --- =3D=3D=3D> usr.bin/svn/lib/libsvn_wc (includes) --- includes_subdir_usr.bin/svn/svnmucc --- =3D=3D=3D> usr.bin/svn/svnmucc (includes) --- includes_subdir_usr.bin/svn/svnrdump --- =3D=3D=3D> usr.bin/svn/svnrdump (includes) --- includes_subdir_usr.sbin --- --- includes_subdir_usr.sbin/uhsoctl --- =3D=3D=3D> usr.sbin/uhsoctl (includes) --- includes_subdir_usr.sbin/usbconfig --- =3D=3D=3D> usr.sbin/usbconfig (includes) --- includes_subdir_usr.sbin/usbdump --- =3D=3D=3D> usr.sbin/usbdump (includes) --- includes_subdir_usr.sbin/ac --- =3D=3D=3D> usr.sbin/ac (includes) --- includes_subdir_usr.sbin/lastlogin --- =3D=3D=3D> usr.sbin/lastlogin (includes) --- includes_subdir_usr.sbin/utx --- =3D=3D=3D> usr.sbin/utx (includes) --- includes_subdir_usr.sbin/ancontrol --- =3D=3D=3D> usr.sbin/ancontrol (includes) --- includes_subdir_usr.sbin/wlandebug --- =3D=3D=3D> usr.sbin/wlandebug (includes) --- includes_subdir_usr.sbin/wpa --- =3D=3D=3D> usr.sbin/wpa (includes) --- includes_subdir_usr.sbin/tests --- =3D=3D=3D> usr.sbin/tests (includes) --- includes_subdir_usr.sbin/wpa --- --- includes_subdir_usr.sbin/wpa/wpa_supplicant --- =3D=3D=3D> usr.sbin/wpa/wpa_supplicant (includes) --- includes_subdir_usr.sbin/wpa/wpa_cli --- =3D=3D=3D> usr.sbin/wpa/wpa_cli (includes) --- includes_subdir_usr.sbin/wpa/wpa_passphrase --- =3D=3D=3D> usr.sbin/wpa/wpa_passphrase (includes) --- includes_subdir_usr.sbin/wpa/hostapd --- =3D=3D=3D> usr.sbin/wpa/hostapd (includes) --- includes_subdir_usr.sbin/wpa/hostapd_cli --- =3D=3D=3D> usr.sbin/wpa/hostapd_cli (includes) --- includes_subdir_usr.sbin/wpa/ndis_events --- =3D=3D=3D> usr.sbin/wpa/ndis_events (includes) --- _libraries --- -------------------------------------------------------------- >>> stage 4.2: building libraries -------------------------------------------------------------- cd /builds/FreeBSD_HEAD_amd64_gcc; CROSS_TOOLCHAIN=3D"amd64-gcc" COMPILER_= VERSION=3D30401 COMPILER_TYPE=3Dclang COMPILER_FREEBSD_VERSION=3D1000001 = MAKEOBJDIRPREFIX=3D/builds/FreeBSD_HEAD_amd64_gcc/obj MACHINE_ARCH=3Damd64= MACHINE=3Damd64 CPUTYPE=3D GROFF_BIN_PATH=3D/builds/FreeBSD_HEAD_amd64_g= cc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/legacy/usr/bin GROFF_FONT_PATH=3D= /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/legacy= /usr/share/groff_font GROFF_TMAC_PATH=3D/builds/FreeBSD_HEAD_amd64_gcc/obj= /builds/FreeBSD_HEAD_amd64_gcc/tmp/legacy/usr/share/tmac CC=3D"/usr/local/b= in/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD_amd64_gcc/o= bj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/FreeBSD_HEAD_amd= 64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysroot=3D/builds/Fr= eeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp -B/usr/local/x86= _64-freebsd/bin/" CXX=3D"/usr/local/bin/x86_64-portbld-freebsd10.1-g++ -isy= stem /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/u= sr/include/c++/v1 -std=3Dc++11 -nostdinc++ -L/builds/FreeBSD_HEAD_amd64_gc= c/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/../lib/libc++ -isystem /builds/Free= BSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/bui= lds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --= sysroot=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/= tmp -B/usr/local/x86_64-freebsd/bin/" CPP=3D"/usr/local/bin/x86_64-portbld= -freebsd10.1-cpp -isystem /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD= _HEAD_amd64_gcc/tmp/usr/include -L/builds/FreeBSD_HEAD_amd64_gcc/obj/builds= /FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysroot=3D/builds/FreeBSD_HEAD_amd64_= gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp -B/usr/local/x86_64-freebsd/bin/"= AS=3D"/usr/local/x86_64-freebsd/bin/as" AR=3D"/usr/local/x86_64-freebsd/b= in/ar" LD=3D"/usr/local/x86_64-freebsd/bin/ld" NM=3D/usr/local/x86_64-freeb= sd/bin/nm OBJDUMP=3D/usr/local/x86_64-freebsd/bin/objdump OBJCOPY=3D"/usr/= local/x86_64-freebsd/bin/objcopy" RANLIB=3D/usr/local/x86_64-freebsd/bin/r= anlib STRINGS=3D/usr/local/x86_64-freebsd/bin/ SIZE=3D"/usr/local/x86_64-f= reebsd/bin/size" INSTALL=3D"sh /builds/FreeBSD_HEAD_amd64_gcc/tools/instal= l.sh" PATH=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_= gcc/tmp/legacy/usr/sbin:/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_H= EAD_amd64_gcc/tmp/legacy/usr/bin:/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/= FreeBSD_HEAD_amd64_gcc/tmp/legacy/bin:/builds/FreeBSD_HEAD_amd64_gcc/obj/bu= ilds/FreeBSD_HEAD_amd64_gcc/tmp/usr/sbin:/builds/FreeBSD_HEAD_amd64_gcc/obj= /builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin /b= uilds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/make.amd64/b= make -f Makefile.inc1 DESTDIR=3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/= FreeBSD_HEAD_amd64_gcc/tmp -DNO_FSCHG MK_HTML=3Dno -DNO_LINT MK_MAN=3Dno M= K_PROFILE=3Dno MK_TESTS=3Dno MK_TESTS_SUPPORT=3Dyes libraries --- libraries --- cd /builds/FreeBSD_HEAD_amd64_gcc; /builds/FreeBSD_HEAD_amd64_gcc/obj/buil= ds/FreeBSD_HEAD_amd64_gcc/make.amd64/bmake -f Makefile.inc1 _prereq_libs; = /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/make.amd64= /bmake -f Makefile.inc1 _startup_libs; /builds/FreeBSD_HEAD_amd64_gcc/obj/= builds/FreeBSD_HEAD_amd64_gcc/make.amd64/bmake -f Makefile.inc1 _prebuild_l= ibs; /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/make= .amd64/bmake -f Makefile.inc1 _generic_libs --- gnu/lib/libssp/libssp_nonshared__PL --- --- gnu/lib/libgcc__PL --- --- lib/libcompiler_rt__PL --- --- gnu/lib/libssp/libssp_nonshared__PL --- =3D=3D=3D> gnu/lib/libssp/libssp_nonshared (obj,all,install) --- gnu/lib/libgcc__PL --- =3D=3D=3D> gnu/lib/libgcc (obj,all,install) --- lib/libcompiler_rt__PL --- =3D=3D=3D> lib/libcompiler_rt (obj,all,install) --- gnu/lib/libssp/libssp_nonshared__PL --- --- obj --- --- gnu/lib/libgcc__PL --- --- obj --- --- gnu/lib/libssp/libssp_nonshared__PL --- --- ssp-local.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include -L/builds/Free= BSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib --sysroot= =3D/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp -B/= usr/local/x86_64-freebsd/bin/ -O2 -pipe -DHAVE_CONFIG_H -I/builds/FreeBSD_= HEAD_amd64_gcc/gnu/lib/libssp/libssp_nonshared/.. -I/builds/FreeBSD_HEAD_a= md64_gcc/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp= -I/builds/FreeBSD_HEAD_amd64_gcc/gnu/lib/libssp/libssp_nonshared/../../..= /../contrib/gcclibs/include -fPIC -DPIC -fvisibility=3Dhidden -MD -MF.de= pend.ssp-local.o -MTssp-local.o -std=3Dgnu99 -fstack-protector -Qunused-= arguments -c /builds/FreeBSD_HEAD_amd64_gcc/gnu/lib/libssp/libssp_nonshare= d/../../../../contrib/gcclibs/libssp/ssp-local.c -o ssp-local.o --- gnu/lib/libgcc__PL --- --- tm.h --- --- tconfig.h --- --- tm.h --- TARGET_CPU_DEFAULT=3D"" HEADERS=3D"options.h i386/biarch64.h i386/i386.h i= 386/unix.h i386/att.h dbxelf.h elfos-undef.h elfos.h freebsd-native.h freeb= sd-spec.h freebsd.h i386/x86-64.h i386/freebsd.h i386/freebsd64.h defaults.= h" DEFINES=3D"" /bin/sh /builds/FreeBSD_HEAD_amd64_gcc/gnu/lib/libgcc/../= ../../contrib/gcc/mkconfig.sh tm.h --- tconfig.h --- TARGET_CPU_DEFAULT=3D"" HEADERS=3D"auto-host.h ansidecl.h" DEFINES=3D"USE= D_FOR_TARGET" /bin/sh /builds/FreeBSD_HEAD_amd64_gcc/gnu/lib/libgcc/../../= ../contrib/gcc/mkconfig.sh tconfig.h --- lib/libcompiler_rt__PL --- --- obj --- --- gnu/lib/libgcc__PL --- --- tm.h --- echo '#define EXTRA_MODES_FILE "i386/i386-modes.def"' >> tm.h --- optionlist --- --- gthr-default.h --- --- optionlist --- LC_ALL=3DC awk -f /builds/FreeBSD_HEAD_amd64_gcc/gnu/lib/libgcc/../../../co= ntrib/gcc/opt-gather.awk /builds/FreeBSD_HEAD_amd64_gcc/gnu/lib/libgcc/../.= ./../contrib/gcc/c.opt /builds/FreeBSD_HEAD_amd64_gcc/gnu/lib/libgcc/../../= ../contrib/gcc/common.opt /builds/FreeBSD_HEAD_amd64_gcc/gnu/lib/libgcc/../= ../../contrib/gcc/config/i386/i386.opt > optionlist --- gthr-default.h --- ln -sf /builds/FreeBSD_HEAD_amd64_gcc/gnu/lib/libgcc/../../../contrib/gcc/g= thr-posix.h gthr-default.h --- unwind.h --- ln -sf /builds/FreeBSD_HEAD_amd64_gcc/gnu/lib/libgcc/../../../contrib/gcc/u= nwind-generic.h unwind.h --- gnu/lib/libssp/libssp_nonshared__PL --- x86_64-portbld-freebsd10.1-gcc: error: unrecognized command line option '-Q= unused-arguments' *** [ssp-local.o] Error code 1 bmake[4]: stopped in /builds/FreeBSD_HEAD_amd64_gcc/gnu/lib/libssp/libssp_n= onshared 1 error bmake[4]: stopped in /builds/FreeBSD_HEAD_amd64_gcc/gnu/lib/libssp/libssp_n= onshared *** [gnu/lib/libssp/libssp_nonshared__PL] Error code 2 bmake[3]: stopped in /builds/FreeBSD_HEAD_amd64_gcc --- lib/libcompiler_rt__PL --- A failure has been detected in another branch of the parallel make bmake[4]: stopped in /builds/FreeBSD_HEAD_amd64_gcc/lib/libcompiler_rt *** [lib/libcompiler_rt__PL] Error code 2 bmake[3]: stopped in /builds/FreeBSD_HEAD_amd64_gcc --- gnu/lib/libgcc__PL --- A failure has been detected in another branch of the parallel make bmake[4]: stopped in /builds/FreeBSD_HEAD_amd64_gcc/gnu/lib/libgcc *** [gnu/lib/libgcc__PL] Error code 2 bmake[3]: stopped in /builds/FreeBSD_HEAD_amd64_gcc 3 errors bmake[3]: stopped in /builds/FreeBSD_HEAD_amd64_gcc *** [libraries] Error code 2 bmake[2]: stopped in /builds/FreeBSD_HEAD_amd64_gcc 1 error bmake[2]: stopped in /builds/FreeBSD_HEAD_amd64_gcc *** [_libraries] Error code 2 bmake[1]: stopped in /builds/FreeBSD_HEAD_amd64_gcc 1 error bmake[1]: stopped in /builds/FreeBSD_HEAD_amd64_gcc *** [buildworld] Error code 2 make: stopped in /builds/FreeBSD_HEAD_amd64_gcc 1 error make: stopped in /builds/FreeBSD_HEAD_amd64_gcc Build step 'Execute shell' marked build as failure [WARNINGS] Skipping publisher since build result is FAILURE IRC notifier plugin: Sending notification to: #freebsd-commits Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-current@freebsd.org Sat Jun 4 12:01:16 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 881D4B6943C for ; Sat, 4 Jun 2016 12:01:16 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id EEFC71C53 for ; Sat, 4 Jun 2016 12:01:15 +0000 (UTC) (envelope-from freebsd@grem.de) Received: (qmail 97684 invoked by uid 89); 4 Jun 2016 11:54:33 -0000 Received: from unknown (HELO bsd64.grem.de) (mg@grem.de@194.97.158.70) by mail.grem.de with ESMTPA; 4 Jun 2016 11:54:33 -0000 Date: Sat, 4 Jun 2016 13:54:30 +0200 From: Michael Gmelin To: Matthias Apitz Cc: freebsd-current@freebsd.org Subject: Re: r300951: mountroot: waiting for device /dev/ad4s1a... Message-ID: <20160604135430.42e2f849@bsd64.grem.de> In-Reply-To: <20160604114852.GA5261@c720-r292778-amd64> References: <20160604101826.GA4660@c720-r292778-amd64> <20160604112806.GA5079@c720-r292778-amd64> <20160604134046.00fc182f@bsd64.grem.de> <20160604114852.GA5261@c720-r292778-amd64> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd10.2) X-Face: $wrgCtfdVw_H9WAY?S&9+/F"!41z'L$uo*WzT8miX?kZ~W~Lr5W7v?j0Sde\mwB&/ypo^}> +a'4xMc^^KroE~+v^&^#[B">soBo1y6(TW6#UZiC]o>C6`ej+i Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWJBwe5BQDl LASZU0/LTEWEfHbyj0Txi32+sKrp1Mv944X8/fm1rS+cAAAACXBIWXMAAAsTAAAL EwEAmpwYAAAAB3RJTUUH3wESCxwC7OBhbgAAACFpVFh0Q29tbWVudAAAAAAAQ3Jl YXRlZCB3aXRoIFRoZSBHSU1QbbCXAAAAAghJREFUOMu11DFvEzEUAGCfEhBVFzuq AKkLd0O6VrIQsLXVSZXoWE5N1K3DobBBA9fQpRWc8OkWouaIjedWKiyREOKs+3PY fvalCNjgLVHeF7/3bMtBzV8C/VsQ8tecEgCcDgrzjekwKZ7TwsJZd/ywEKwwP+ZM 8P3drTsAwWn2mpWuDDuYiK1bFs6De0KUUFw0tWxm+D4AIhuuvZqtyWYeO7jQ4Aea 7jUqI+ixhQoHex4WshEvSXdood7stlv4oSuFOC4tqGcr0NjEqXgV4mMJO38nld4+ xKNxRDon7khyKVqY7YR4d+Cg0OMrkWXZOM7YDkEfKiilCn1qYv4mighZiynuHHOA Wq9QJq+BIES7lMFUtcikMnkDGHUoncA+uHgrP0ctIEqfwLHzeSo+eUA66AqzwN6n 2ZHJhw6Qh/PoyC/QENyEyC/AyNjq74Bs+3UH0xYwzDUC4B97HgLocg1QLYgDDO1v f3UX9Y307Ew4AHh67YAFFsxEpkXwpXY3eIgMhAAE3R19L919nNnuD2wlPcDE3UeT L2ytEICQib9BXgS2fU8PrD82ToYO1OEmMSnYTjSqSv9wdC0tPYC+rQRQD9ESnldF CyqfmiYW+tlALt8gH2xrMdC/youbjzPXEun+/ReXsMCDyve3dZc09fn2Oas8oXGc Jj6/fOeK5UmSMPmf/jL+GD8BEj0k/Fn6IO4AAAAASUVORK5CYII= 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.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 12:01:16 -0000 On Sat, 4 Jun 2016 13:48:52 +0200 Matthias Apitz wrote: > Hi Michael, >=20 > El d=C3=ADa Saturday, June 04, 2016 a las 01:40:46PM +0200, Michael Gmelin > escribi=C3=B3: >=20 > > Hi Matthias, > >=20 > > Did you try to connect an external USB keyboard? =20 >=20 > no; it uses the laptop onboard keyboard; >=20 > > i386 or amd64? =20 >=20 > i386; >=20 > > Did you do a full clean build? > > GENERIC or custom kernel config? =20 >=20 > yes, clean 'make buildkernel KERNCONF=3DGENERIC' And then 'make installkernel KERNCONF=3DGENERIC' I suppose. >=20 > interestingly: I can type at the prompt 'mountroot> ' into the dark > and always when I press Ctrl the chars are written to the screen and > so I can specify 'ufs:/dev/ad4s1a' which than leads to the same error > 19. Did you try ufs:/dev/ada0s1a? -m >=20 > I can as well boot an USB key with the old kernel r269739, mount > /dev/ad4s1a to /mnt, all fine; I did even a fsck while booted from USB > on /dev/ad4s1a. The FS is clean. >=20 > matthias >=20 --=20 Michael Gmelin From owner-freebsd-current@freebsd.org Sat Jun 4 12:01: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 065BDB694AB for ; Sat, 4 Jun 2016 12:01:40 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7CFBE1D6C for ; Sat, 4 Jun 2016 12:01:39 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [88.217.102.110] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1b9AGl-0005pr-Lw; Sat, 04 Jun 2016 14:01:36 +0200 Received: from localhost.my.domain (c720-r292778-amd64 [127.0.0.1]) by localhost.unixarea.de (8.15.2/8.14.9) with ESMTPS id u54C1YxI005452 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 4 Jun 2016 14:01:34 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.15.2/8.14.9/Submit) id u54C1Ynb005451; Sat, 4 Jun 2016 14:01:34 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sat, 4 Jun 2016 14:01:34 +0200 From: Matthias Apitz To: Michael Gmelin Cc: freebsd-current@freebsd.org Subject: Re: r300951: mountroot: waiting for device /dev/ad4s1a... Message-ID: <20160604120134.GA5402@c720-r292778-amd64> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , Michael Gmelin , freebsd-current@freebsd.org References: <20160604101826.GA4660@c720-r292778-amd64> <20160604112806.GA5079@c720-r292778-amd64> <20160604134046.00fc182f@bsd64.grem.de> <20160604114852.GA5261@c720-r292778-amd64> <20160604135430.42e2f849@bsd64.grem.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160604135430.42e2f849@bsd64.grem.de> X-Operating-System: FreeBSD 11.0-CURRENT r292778 (amd64) User-Agent: Mutt/1.5.24 (2015-08-30) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 88.217.102.110 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 12:01:40 -0000 El día Saturday, June 04, 2016 a las 01:54:30PM +0200, Michael Gmelin escribió: > > On Sat, 4 Jun 2016 13:48:52 +0200 > Matthias Apitz wrote: > > > > Did you do a full clean build? > > > GENERIC or custom kernel config? > > > > yes, clean 'make buildkernel KERNCONF=GENERIC' > And then 'make installkernel KERNCONF=GENERIC' I suppose. yes, ofc :-) > > interestingly: I can type at the prompt 'mountroot> ' into the dark > > and always when I press Ctrl the chars are written to the screen and > > so I can specify 'ufs:/dev/ad4s1a' which than leads to the same error > > 19. > > Did you try ufs:/dev/ada0s1a? no, but now and it worked; I will adjust /etc/fstab; but why is this? Thanks matthias -- Matthias Apitz, ✉ guru@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 "Die Verkaufsschlager des Buchmarkts geben Auskunft über den Zustand einer Gesellschaft bzw. sind, was diese Zeiten angeht, Gradmesser fortschreitenden Schwachsinns. ..." (jW 19.05.2016) From owner-freebsd-current@freebsd.org Sat Jun 4 12:48:34 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 11BE1B690C2 for ; Sat, 4 Jun 2016 12:48:34 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id 757E812CF for ; Sat, 4 Jun 2016 12:48:33 +0000 (UTC) (envelope-from freebsd@grem.de) Received: (qmail 98276 invoked by uid 89); 4 Jun 2016 12:41:51 -0000 Received: from unknown (HELO bsd64.grem.de) (mg@grem.de@194.97.158.70) by mail.grem.de with ESMTPA; 4 Jun 2016 12:41:51 -0000 Date: Sat, 4 Jun 2016 14:41:48 +0200 From: Michael Gmelin To: Matthias Apitz Cc: freebsd-current@freebsd.org Subject: Re: r300951: mountroot: waiting for device /dev/ad4s1a... Message-ID: <20160604144148.000a4fc3@bsd64.grem.de> In-Reply-To: <20160604120134.GA5402@c720-r292778-amd64> References: <20160604101826.GA4660@c720-r292778-amd64> <20160604112806.GA5079@c720-r292778-amd64> <20160604134046.00fc182f@bsd64.grem.de> <20160604114852.GA5261@c720-r292778-amd64> <20160604135430.42e2f849@bsd64.grem.de> <20160604120134.GA5402@c720-r292778-amd64> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd10.2) X-Face: $wrgCtfdVw_H9WAY?S&9+/F"!41z'L$uo*WzT8miX?kZ~W~Lr5W7v?j0Sde\mwB&/ypo^}> +a'4xMc^^KroE~+v^&^#[B">soBo1y6(TW6#UZiC]o>C6`ej+i Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWJBwe5BQDl LASZU0/LTEWEfHbyj0Txi32+sKrp1Mv944X8/fm1rS+cAAAACXBIWXMAAAsTAAAL EwEAmpwYAAAAB3RJTUUH3wESCxwC7OBhbgAAACFpVFh0Q29tbWVudAAAAAAAQ3Jl YXRlZCB3aXRoIFRoZSBHSU1QbbCXAAAAAghJREFUOMu11DFvEzEUAGCfEhBVFzuq AKkLd0O6VrIQsLXVSZXoWE5N1K3DobBBA9fQpRWc8OkWouaIjedWKiyREOKs+3PY fvalCNjgLVHeF7/3bMtBzV8C/VsQ8tecEgCcDgrzjekwKZ7TwsJZd/ywEKwwP+ZM 8P3drTsAwWn2mpWuDDuYiK1bFs6De0KUUFw0tWxm+D4AIhuuvZqtyWYeO7jQ4Aea 7jUqI+ixhQoHex4WshEvSXdood7stlv4oSuFOC4tqGcr0NjEqXgV4mMJO38nld4+ xKNxRDon7khyKVqY7YR4d+Cg0OMrkWXZOM7YDkEfKiilCn1qYv4mighZiynuHHOA Wq9QJq+BIES7lMFUtcikMnkDGHUoncA+uHgrP0ctIEqfwLHzeSo+eUA66AqzwN6n 2ZHJhw6Qh/PoyC/QENyEyC/AyNjq74Bs+3UH0xYwzDUC4B97HgLocg1QLYgDDO1v f3UX9Y307Ew4AHh67YAFFsxEpkXwpXY3eIgMhAAE3R19L919nNnuD2wlPcDE3UeT L2ytEICQib9BXgS2fU8PrD82ToYO1OEmMSnYTjSqSv9wdC0tPYC+rQRQD9ESnldF CyqfmiYW+tlALt8gH2xrMdC/youbjzPXEun+/ReXsMCDyve3dZc09fn2Oas8oXGc Jj6/fOeK5UmSMPmf/jL+GD8BEj0k/Fn6IO4AAAAASUVORK5CYII= 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.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 12:48:34 -0000 On Sat, 4 Jun 2016 14:01:34 +0200 Matthias Apitz wrote: > El d=C3=ADa Saturday, June 04, 2016 a las 01:54:30PM +0200, Michael Gmelin > escribi=C3=B3: >=20 > >=20 > > On Sat, 4 Jun 2016 13:48:52 +0200 > > Matthias Apitz wrote: > > =20 > > > > Did you do a full clean build? > > > > GENERIC or custom kernel config? =20 > > >=20 > > > yes, clean 'make buildkernel KERNCONF=3DGENERIC' =20 > > And then 'make installkernel KERNCONF=3DGENERIC' I suppose. =20 >=20 > yes, ofc :-) >=20 > > > interestingly: I can type at the prompt 'mountroot> ' into the > > > dark and always when I press Ctrl the chars are written to the > > > screen and so I can specify 'ufs:/dev/ad4s1a' which than leads to > > > the same error 19. =20 > >=20 > > Did you try ufs:/dev/ada0s1a? =20 >=20 > no, but now and it worked; I will adjust /etc/fstab; but why is this? >=20 The SATA subsystem was changed to use cam back in 2012 [1], which changed device numbering from adX to ada0, ada1. Back then, a sysctl called kern.cam.ada.legacy_aliases, which is enabled by default, was provided for backwards compatibility. Some research shows that this feature was removed in r289137 [2] It's also covered in UPDATING: 20151011: Compatibility shims for legacy ATA device names have been removed. It includes ATA_STATIC_ID kernel option, kern.cam.ada.legacy_aliases and kern.geom.raid.legacy_aliases loader tunables, kern.devalias.* environment variables, /dev/ad* and /dev/ar* symbolic links. - Michael [1] https://www.freebsd.org/releases/9.0R/relnotes-detailed.html (see 3.2.3) [2] https://svnweb.freebsd.org/base?view=3Drevision&revision=3D289137 --=20 Michael Gmelin From owner-freebsd-current@freebsd.org Sat Jun 4 13:03:54 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B6A08B69546 for ; Sat, 4 Jun 2016 13:03:54 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 965961C26 for ; Sat, 4 Jun 2016 13:03:54 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 95A3BB69545; Sat, 4 Jun 2016 13:03:54 +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 95490B69544 for ; Sat, 4 Jun 2016 13:03:54 +0000 (UTC) (envelope-from etnapierala@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 1B6091C25 for ; Sat, 4 Jun 2016 13:03:54 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-lf0-x22d.google.com with SMTP id s186so4926687lfs.1 for ; Sat, 04 Jun 2016 06:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=D9QNfVERVGdLhJ/VnBEzLrZ1XHc74yd3F5zx+TTVBt4=; b=Zc4jYOfIkyh+iTXwh8x1vw0JVftrUyYe6QDRCRNnCCb5XbXvCxwuYXpNu6A7AOIJuW wowJe2VHl47DcXfFur5PTQfk7w4dOafgsrpjWnGRzeu8cYpHm4S9sCsGWThLuJ/U2rh9 s+ElzGp/uyflAqTkrHpq5pWUWu3UM+/65BQekwO1w/qmT2jXdwM6+ctzvR+LZ2Vz6f6k LEB2L79Hclo9KP5cZuK5qN5EgblzQOhUKok6Wy1jwaCKpG1ML/e1KE6P6KnCPPfUTici bSMdbvOt+T63SD+rzw6d60G9xmL2tiSjdCr06UdPo5epJX+HHpfIADox6L1s9gNiA9KH NnMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=D9QNfVERVGdLhJ/VnBEzLrZ1XHc74yd3F5zx+TTVBt4=; b=IFJLll1zW0QHIS254piX4XeJnoxEb/r3HBnvG70eQB4wb3Cxm3ZjmKtUe22Bozkx0u k4yJ7q27fOWxy4UpJRNwYcOLvOezyl2igJO4mMq2bhxDXhj7ihnICEkZtYp3WHsSAt5C WrjNVdhqnLqAlImBPcbRwoNv081jR8hJ7xpFrnEGqBZ95X96+3P5GHKaQ6jUJt5HEzYA AhjNnJFrjLnTVG6jxnD3hv/eeKBCDfVVjyDb4Xj3fza4rIc7kOYUO0BekQd3REcBxjxM TIrU5xW8no3bdh0R87BVAppUOfvEDVz9DVGi4TH2c1HMtxaKE5axfr6kmo95hbmY1405 mDOA== X-Gm-Message-State: ALyK8tLlpNnsKw8tSxHxTnYGXCIWZZWe5sn7ZfevBjzwe4AD9gcT9R6uKqyMXiclyvp8KA== X-Received: by 10.46.32.162 with SMTP id g34mr2066598lji.53.1465045431628; Sat, 04 Jun 2016 06:03:51 -0700 (PDT) Received: from [10.125.156.220] ([31.0.8.219]) by smtp.gmail.com with ESMTPSA id 186sm842151ljf.9.2016.06.04.06.03.50 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 04 Jun 2016 06:03:50 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: latest memstick image fails to mountroot by default on Thinkpad e565 From: =?utf-8?Q?Edward_Tomasz_Napiera=C5=82a?= X-Mailer: iPhone Mail (13F69) In-Reply-To: <15519f8353d.b6910d38109412.7320644652365100345@nextbsd.org> Date: Sat, 4 Jun 2016 15:03:49 +0200 Cc: "current@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <1BA445CE-2BB5-45F0-A8C2-773561281CAD@FreeBSD.org> References: <15519f8353d.b6910d38109412.7320644652365100345@nextbsd.org> To: Matthew Macy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 13:03:54 -0000 Dnia 04.06.2016 o godz. 07:52 Matthew Macy napisa=C5=82(= a): >=20 > In order to boot USB reliably on recent laptop hardware (both my thinkpad = and XPS13 need this) you need to add the following to the installer images l= oader.conf: >=20 > kern.cam.boot_delay=3D"10000" > kern.cam.scsi_delay=3D"3000" What happens when you don't? I mean, what are the console messages? From owner-freebsd-current@freebsd.org Sat Jun 4 13:08:58 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1C869B698B0 for ; Sat, 4 Jun 2016 13:08:58 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [202.12.127.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.auburn.protected-networks.net", Issuer "Protected Networks Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E006D1F1B; Sat, 4 Jun 2016 13:08:57 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: imb@mail.auburn.protected-networks.net) by mail.auburn.protected-networks.net (Postfix) with ESMTPSA id E75C81CC5D; Sat, 4 Jun 2016 09:08:48 -0400 (EDT) Subject: Re: repeatable panic on pageout with 945GM To: Matthew Macy , "K. Macy" References: <2490f1c7-8153-ece3-49ed-4b3886564fd7@protected-networks.net> <205d4423-b834-9a21-785f-fa15d44c78ec@protected-networks.net> <1551419a1db.12929035f45012.326107747932338888@nextbsd.org> Cc: "freebsd-current@freebsd.org" From: Michael Butler Openpgp: id=6F63E6399DCC8E3E94D60F0642FF6BAE0442D492 Message-ID: <939f9d2b-e925-e8e0-0ff3-8d90623728c6@protected-networks.net> Date: Sat, 4 Jun 2016 09:08:45 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <1551419a1db.12929035f45012.326107747932338888@nextbsd.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 13:08:58 -0000 On 06/02/16 22:31, Matthew Macy wrote: > Tell me if that makes any difference. > > -M > > > ---- On Thu, 02 Jun 2016 16:55:53 -0700 K. Macy wrote ---- > > It looks like it might be trying to remove mappings for a page that doesn't > > have any. It's a bit odd. Likely a bug in cdev_pager_free_page or gem > > release mmap. Compile the kernel and driver with -O0 and look at the page. > > It's too bad I don't support AGP yet with DRM 4.6. Maybe in a week or two. > > > > diff --git a/sys/vm/device_pager.c b/sys/vm/device_pager.c > index 013f0d5..917ece7 100644 > --- a/sys/vm/device_pager.c > +++ b/sys/vm/device_pager.c > @@ -211,7 +211,8 @@ cdev_pager_free_page(vm_object_t object, vm_page_t m) > VM_OBJECT_ASSERT_WLOCKED(object); > if (object->type == OBJT_MGTDEVICE) { > KASSERT((m->oflags & VPO_UNMANAGED) == 0, ("unmanaged %p", m)); > - pmap_remove_all(m); > + if (pmap_page_is_mapped(page)) > + pmap_remove_all(m); > vm_page_lock(m); > vm_page_remove(m); > vm_page_unlock(m); > This "band-aid" seems to have worked. I haven't had a single panic since - Thanks! :-) I tried to compile with -O0 but, for some reason, it panics in the sound driver with a double-fault. When I get time, I'll recompile only the files involved and see if I can't get a decent trace (and dump) to identify the cause, imb From owner-freebsd-current@freebsd.org Sat Jun 4 14:08:41 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA9E4B6969A for ; Sat, 4 Jun 2016 14:08:41 +0000 (UTC) (envelope-from jhb@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 966161D4D for ; Sat, 4 Jun 2016 14:08:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 9105BB69698; Sat, 4 Jun 2016 14:08:41 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 90830B69697; Sat, 4 Jun 2016 14:08:41 +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 6F7061D4B; Sat, 4 Jun 2016 14:08:41 +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 71FADB917; Sat, 4 Jun 2016 10:08:39 -0400 (EDT) From: John Baldwin To: Adrian Chadd Cc: Konstantin Belousov , Alan Somers , Alan Cox , Alan Cox , freebsd-current , performance@freebsd.org, "current@freebsd.org" Subject: Re: PostgreSQL performance on FreeBSD Date: Fri, 03 Jun 2016 11:53:15 -0700 Message-ID: <1603235.2ShtoCfSqO@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: References: <20140627125613.GT93733@kib.kiev.ua> 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); Sat, 04 Jun 2016 10:08:39 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 14:08:41 -0000 On Friday, June 03, 2016 11:29:03 AM Adrian Chadd wrote: > On 3 June 2016 at 11:27, Adrian Chadd wrote: > > > That and the other NUMA stuff is something to address in -12. > > And, I completely welcome continued development in NUMA scaling in > combination with discussion. The iterator changes I committed are a > more generic version of a patch people were applying on top of -10 and > -head for at least what, three years now? Maybe more if -9 also just > did round-robin and not first-touch? 8 and 9 did first-touch. Only 10 did round-robin. -- John Baldwin From owner-freebsd-current@freebsd.org Sat Jun 4 14:24: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 03625B6A0FA for ; Sat, 4 Jun 2016 14:24:14 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BBAD011D2 for ; Sat, 4 Jun 2016 14:24:13 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [88.217.102.110] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1b9CUj-0008C1-7V; Sat, 04 Jun 2016 16:24:09 +0200 Received: from localhost.my.domain (c720-r292778-amd64 [127.0.0.1]) by localhost.unixarea.de (8.15.2/8.14.9) with ESMTPS id u54EO8FX006618 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 4 Jun 2016 16:24:08 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.15.2/8.14.9/Submit) id u54EO8mV006617; Sat, 4 Jun 2016 16:24:08 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sat, 4 Jun 2016 16:24:08 +0200 From: Matthias Apitz To: Michael Gmelin Cc: freebsd-current@freebsd.org Subject: Re: r300951: mountroot: waiting for device /dev/ad4s1a... Message-ID: <20160604142407.GA6594@c720-r292778-amd64> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , Michael Gmelin , freebsd-current@freebsd.org References: <20160604101826.GA4660@c720-r292778-amd64> <20160604112806.GA5079@c720-r292778-amd64> <20160604134046.00fc182f@bsd64.grem.de> <20160604114852.GA5261@c720-r292778-amd64> <20160604135430.42e2f849@bsd64.grem.de> <20160604120134.GA5402@c720-r292778-amd64> <20160604144148.000a4fc3@bsd64.grem.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160604144148.000a4fc3@bsd64.grem.de> X-Operating-System: FreeBSD 11.0-CURRENT r292778 (amd64) User-Agent: Mutt/1.5.24 (2015-08-30) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 88.217.102.110 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 14:24:14 -0000 El día Saturday, June 04, 2016 a las 02:41:48PM +0200, Michael Gmelin escribió: > It's also covered in UPDATING: > > 20151011: > Compatibility shims for legacy ATA device names have been > removed. It includes ATA_STATIC_ID kernel option, > kern.cam.ada.legacy_aliases and kern.geom.raid.legacy_aliases > loader tunables, kern.devalias.* environment variables, /dev/ad* > and /dev/ar* symbolic links. > Next time I will do read UPDATING. Thanks for your help. matthias -- Matthias Apitz, ✉ guru@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 "Die Verkaufsschlager des Buchmarkts geben Auskunft über den Zustand einer Gesellschaft bzw. sind, was diese Zeiten angeht, Gradmesser fortschreitenden Schwachsinns. ..." (jW 19.05.2016) From owner-freebsd-current@freebsd.org Sat Jun 4 17:02: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 785FCB69328 for ; Sat, 4 Jun 2016 17:02:47 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6929A1176 for ; Sat, 4 Jun 2016 17:02:46 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 146505975340394.02503519480842; Sat, 4 Jun 2016 10:02:33 -0700 (PDT) Date: Sat, 04 Jun 2016 10:02:33 -0700 From: Matthew Macy To: "Michael Butler" Cc: "freebsd-current@freebsd.org" Message-ID: <1551c5dbd86.c68532b5123717.566503881838650848@nextbsd.org> In-Reply-To: <939f9d2b-e925-e8e0-0ff3-8d90623728c6@protected-networks.net> References: <2490f1c7-8153-ece3-49ed-4b3886564fd7@protected-networks.net> <205d4423-b834-9a21-785f-fa15d44c78ec@protected-networks.net> <1551419a1db.12929035f45012.326107747932338888@nextbsd.org> <939f9d2b-e925-e8e0-0ff3-8d90623728c6@protected-networks.net> Subject: Re: repeatable panic on pageout with 945GM MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 17:02:47 -0000 > > This "band-aid" seems to have worked. I haven't had a single panic since > - Thanks! :-) > > I tried to compile with -O0 but, for some reason, it panics in the sound > driver with a double-fault. When I get time, I'll recompile only the > files involved and see if I can't get a decent trace (and dump) to > identify the cause, No need. Based on the line that it crashed at, the problem is that with no mappings no pv_entry has been allocated. Somehow on your laptop you're able to get in to a situation where fictitious pages have been added to the object that don't get mapped. This isn't a strange situation in and of itself, but you seem to be the only hitting this. In any event, the DRM 4.6 port will support AGP in about a week. It will probably have bugs, but this one isn't in any of its code paths. I'm glad your system works a bit better now. Cheers. -M From owner-freebsd-current@freebsd.org Sat Jun 4 17:16:16 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91A93B6996D for ; Sat, 4 Jun 2016 17:16:16 +0000 (UTC) (envelope-from mmacy@nextbsd.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 7E11B11E6 for ; Sat, 4 Jun 2016 17:16:16 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 78C57B6996C; Sat, 4 Jun 2016 17:16:16 +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 783C7B6996A for ; Sat, 4 Jun 2016 17:16:16 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6804611E5 for ; Sat, 4 Jun 2016 17:16:16 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1465060574131356.5916992402048; Sat, 4 Jun 2016 10:16:14 -0700 (PDT) Date: Sat, 04 Jun 2016 10:16:14 -0700 From: Matthew Macy To: =?UTF-8?Q?=22Edward_Tomasz_Napiera=C5=82a=22?= Cc: "current@freebsd.org" Message-ID: <1551c6a4372.d8ddcadc123945.3981381345074142949@nextbsd.org> In-Reply-To: <1BA445CE-2BB5-45F0-A8C2-773561281CAD@FreeBSD.org> References: <15519f8353d.b6910d38109412.7320644652365100345@nextbsd.org> <1BA445CE-2BB5-45F0-A8C2-773561281CAD@FreeBSD.org> Subject: Re: latest memstick image fails to mountroot by default on Thinkpad e565 MIME-Version: 1.0 X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-Zoho-Virus-Status: 1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 17:16:16 -0000 ---- On Sat, 04 Jun 2016 06:03:49 -0700 Edward Tomasz Napiera=C5=82a wrote ----=20 > Dnia 04.06.2016 o godz. 07:52 Matthew Macy napisa=C5= =82(a): >=20 > >=20 > > In order to boot USB reliably on recent laptop hardware (both my think= pad and XPS13 need this) you need to add the following to the installer im= ages loader.conf: > >=20 > > kern.cam.boot_delay=3D"10000" > > kern.cam.scsi_delay=3D"3000" >=20 > What happens when you don't? I mean, what are the console messages? =20 It times out on mountroot. It doesn't do it every time. The first time I tr= ied to reproduce this morning it actually worked. I've attached an image. -M From owner-freebsd-current@freebsd.org Sat Jun 4 17:22:16 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9F5D4B69F0F; Sat, 4 Jun 2016 17:22:16 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 83B161100; Sat, 4 Jun 2016 17:22:16 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 7805514C4; Sat, 4 Jun 2016 17:22:16 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 473C920373; Sat, 4 Jun 2016 17:22:16 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id 41Ls2CsCeRE6; Sat, 4 Jun 2016 17:22:13 +0000 (UTC) Subject: Re: [CFT] WITH_META_MODE: Working incremental build [only on i386 and amd64] [filemon fails to load on powerpc64] DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 152F22036D To: Mark Millard References: <7748cc71-3788-22ae-fcb2-699eae529310@FreeBSD.org> <9A1A624D-9286-4C0F-A435-D590E07C1149@dsl-only.net> <39d3c132-cdac-8c9a-c580-82d18f071699@FreeBSD.org> <1D3FECB2-D7D9-491E-9BDD-C34436EFB333@dsl-only.net> Cc: FreeBSD Current , FreeBSD PowerPC ML From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <7b911297-0399-573c-8021-8ac7ccf30648@FreeBSD.org> Date: Sat, 4 Jun 2016 10:22:20 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <1D3FECB2-D7D9-491E-9BDD-C34436EFB333@dsl-only.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="72HF2hvgu1repFASb5FaE97dOefkVoKam" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 17:22:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --72HF2hvgu1repFASb5FaE97dOefkVoKam Content-Type: multipart/mixed; boundary="KgkfTichcNnhlqTrhJBFI77SV5JEbSUGX" From: Bryan Drewery To: Mark Millard Cc: FreeBSD Current , FreeBSD PowerPC ML Message-ID: <7b911297-0399-573c-8021-8ac7ccf30648@FreeBSD.org> Subject: Re: [CFT] WITH_META_MODE: Working incremental build [only on i386 and amd64] [filemon fails to load on powerpc64] References: <7748cc71-3788-22ae-fcb2-699eae529310@FreeBSD.org> <9A1A624D-9286-4C0F-A435-D590E07C1149@dsl-only.net> <39d3c132-cdac-8c9a-c580-82d18f071699@FreeBSD.org> <1D3FECB2-D7D9-491E-9BDD-C34436EFB333@dsl-only.net> In-Reply-To: <1D3FECB2-D7D9-491E-9BDD-C34436EFB333@dsl-only.net> --KgkfTichcNnhlqTrhJBFI77SV5JEbSUGX Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 6/4/2016 12:17 AM, Mark Millard wrote: > On 2016-Jun-2, at 12:36 PM, Bryan Drewery wro= te: >=20 >> On 6/1/2016 6:39 PM, Mark Millard wrote: >>> while filemon.ko now exists: >>>> # ls -l /boot/*/filemon* >>>> -r-xr-xr-x 1 root wheel 32064 Jun 1 17:59 /boot/kernel/filemon.k= o >>> it does not load: >>>> # kldload -n filemon >>>> kldload: can't load filemon: No such file or directory >>>> # dmesg | grep link_elf >>>> link_elf: symbol elf64_freebsd_sysvec undefined >>> So no WITH_META_MODE=3Dyes yet for powerpc64. >> >> >> Please try this patch: http://dpaste.com/37VP5MD.txt >> >> And once you have filemon loaded please run this basic test script. I= t >> should return no output and a zero exit status. >> >> http://dpaste.com/23NTA0A.txt >> >> Just sh file it. >> >> --=20 >> Regards, >> Bryan Drewery >=20 > Unfortunately other things interfered and I was unable to do this befor= e temporarily losing access to the powerpc and powerpc64 boxes --for what= will probably be weeks or months. >=20 No problem... > So for now it is the end of my native-testing for powerpc64 and powerpc= =2E >=20 > I do not know if anyone else has an appropriate context and willingness= to do this specific test or not. >=20 > For the duration I should still be able to do amd64 -> powerpc64 or pow= erpc cross builds (buildworld buildkernel), although likely with less tim= e and more delay for doing so. >=20 > I am hoping to still have rpi2 access for armv6/v7 native use. But I've= yet to make the soft-float to hard-float leap: I focused primarily on th= e powerpc64 and powerpc use, knowing up front of the pending temporarily-= unavailable status. >=20 >=20 >=20 > Thanks for all the work on the build system by you and others. Original= ly I had a bunch of workarounds in my src.conf files to avoid problems th= at occurred for the likes of a libc++-based, xtoolchain-based so-called "= cross build" (self-hosted), powerpc64 environment (no gcc 4.2.1 and clang= not working for such yet). Far more works implicitly in src.conf files f= or such a context now. >=20 Thanks for all of the testing and feedback! --=20 Regards, Bryan Drewery --KgkfTichcNnhlqTrhJBFI77SV5JEbSUGX-- --72HF2hvgu1repFASb5FaE97dOefkVoKam 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 iQEcBAEBAgAGBQJXUw5MAAoJEDXXcbtuRpfPVGAIAKJEW5Tvv8qBHglkYGTR+baw JGtjE7SkFU9+ww9JPeEi2kgy4ipgBoopXL7o0Ibdclou7CU9KQ/9LX7skkFfangZ jhb7udssQIA/nqAiBjgi+CAo4iGeAPIguuBPSfdh0tjldbLlb8GwrKntdC0I8kKi hsxTL/9Lmoa3/r4NTRwVnPnSmTCLII95hIB38F6ugwmIN9jYCGux4JUqlvpEFKfZ f9Je18nnAQ1FXjgS6LhQDZo0GqLmad7CapBUq/mN8lU24khTEliaughNKSN3VxNc Yvhk9bkNDtkQeFtPn7cRWgoRj6gXNQZ+3YisvprIDkE9e91nQYak4Wi0SQTNmrs= =tGtf -----END PGP SIGNATURE----- --72HF2hvgu1repFASb5FaE97dOefkVoKam-- From owner-freebsd-current@freebsd.org Sat Jun 4 17:35: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 5EB33B6A2A2 for ; Sat, 4 Jun 2016 17:35:08 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2DB5C1D26 for ; Sat, 4 Jun 2016 17:35:08 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.15.2/8.15.2) with ESMTPS id u54HZ6ZZ084994 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 4 Jun 2016 11:35:06 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.15.2/8.15.2/Submit) with ESMTP id u54HZ6u3084991; Sat, 4 Jun 2016 11:35:06 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sat, 4 Jun 2016 11:35:06 -0600 (MDT) From: Warren Block To: Matthias Apitz cc: Michael Gmelin , freebsd-current@freebsd.org Subject: Re: r300951: mountroot: waiting for device /dev/ad4s1a... In-Reply-To: <20160604142407.GA6594@c720-r292778-amd64> Message-ID: References: <20160604101826.GA4660@c720-r292778-amd64> <20160604112806.GA5079@c720-r292778-amd64> <20160604134046.00fc182f@bsd64.grem.de> <20160604114852.GA5261@c720-r292778-amd64> <20160604135430.42e2f849@bsd64.grem.de> <20160604120134.GA5402@c720-r292778-amd64> <20160604144148.000a4fc3@bsd64.grem.de> <20160604142407.GA6594@c720-r292778-amd64> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sat, 04 Jun 2016 11:35:07 -0600 (MDT) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 17:35:08 -0000 On Sat, 4 Jun 2016, Matthias Apitz wrote: > El día Saturday, June 04, 2016 a las 02:41:48PM +0200, Michael Gmelin escribió: > >> It's also covered in UPDATING: >> >> 20151011: >> Compatibility shims for legacy ATA device names have been >> removed. It includes ATA_STATIC_ID kernel option, >> kern.cam.ada.legacy_aliases and kern.geom.raid.legacy_aliases >> loader tunables, kern.devalias.* environment variables, /dev/ad* >> and /dev/ar* symbolic links. >> > > Next time I will do read UPDATING. Thanks for your help. Use labels so there are no static device names at all. With MBR, the options are limited, but UFS labels work and have no metadata problems: http://www.wonkity.com/~wblock/docs/html/labels.html GPT has very nice partition labels that can be set with gpart -l. It works with i386 and BIOS booting. From owner-freebsd-current@freebsd.org Sat Jun 4 17:35:48 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2A48AB6A31B for ; Sat, 4 Jun 2016 17:35:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-172.reflexion.net [208.70.211.172]) (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 BBB161E4A for ; Sat, 4 Jun 2016 17:35:47 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31380 invoked from network); 4 Jun 2016 17:36:13 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 4 Jun 2016 17:36:13 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Sat, 04 Jun 2016 13:36:19 -0400 (EDT) Received: (qmail 1637 invoked from network); 4 Jun 2016 17:36:19 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 4 Jun 2016 17:36:19 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.104] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 73C5FB1E001; Sat, 4 Jun 2016 10:35:36 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: svn commit: r301394 - head [If X_COMPILER_TYPE is defined, do not use it, otherwise use it?] Message-Id: <23DACF49-E75D-4D49-BEB1-621500BC907A@dsl-only.net> Date: Sat, 4 Jun 2016 10:35:39 -0700 To: Bryan Drewery , FreeBSD Current Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 17:35:48 -0000 =46rom the commit report: > +.if defined(X_COMPILER_TYPE) > CROSSENV+=3D COMPILER_VERSION=3D${COMPILER_VERSION} \ > COMPILER_TYPE=3D${COMPILER_TYPE} \ > COMPILER_FREEBSD_VERSION=3D${COMPILER_FREEBSD_VERSION} This does not use X_COMPILER_TYPE when it is defined. > +.else > +CROSSENV+=3D COMPILER_VERSION=3D${X_COMPILER_VERSION} \ > + COMPILER_TYPE=3D${X_COMPILER_TYPE} \ > + COMPILER_FREEBSD_VERSION=3D${X_COMPILER_FREEBSD_VERSION} This tries to use the undefined X_COMPILER_TYPE. > +.endif Overall: A not seems to be missing or instead the nested code blocks need to be = swapped. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sat Jun 4 17:38: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 332A3B6A461 for ; Sat, 4 Jun 2016 17:38:29 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 1B88012B0; Sat, 4 Jun 2016 17:38:29 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 143A51E76; Sat, 4 Jun 2016 17:38:29 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id B7C5B203DF; Sat, 4 Jun 2016 17:38:28 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id GQfzghT1BbpH; Sat, 4 Jun 2016 17:38:26 +0000 (UTC) Subject: Re: svn commit: r301394 - head [If X_COMPILER_TYPE is defined, do not use it, otherwise use it?] DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 43E09203D1 To: Mark Millard , FreeBSD Current References: <23DACF49-E75D-4D49-BEB1-621500BC907A@dsl-only.net> From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: Date: Sat, 4 Jun 2016 10:38:33 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <23DACF49-E75D-4D49-BEB1-621500BC907A@dsl-only.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WXp4voTb2LoiTSe57PCdhIbSH7E1DMetM" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 17:38:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WXp4voTb2LoiTSe57PCdhIbSH7E1DMetM Content-Type: multipart/mixed; boundary="wfb4BhwW7tSAf7Dgo8U1W5cAuCQ8rRh4X" From: Bryan Drewery To: Mark Millard , FreeBSD Current Message-ID: Subject: Re: svn commit: r301394 - head [If X_COMPILER_TYPE is defined, do not use it, otherwise use it?] References: <23DACF49-E75D-4D49-BEB1-621500BC907A@dsl-only.net> In-Reply-To: <23DACF49-E75D-4D49-BEB1-621500BC907A@dsl-only.net> --wfb4BhwW7tSAf7Dgo8U1W5cAuCQ8rRh4X Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 6/4/2016 10:35 AM, Mark Millard wrote: > From the commit report: >=20 >> +.if defined(X_COMPILER_TYPE) >> CROSSENV+=3D COMPILER_VERSION=3D${COMPILER_VERSION} \ >> COMPILER_TYPE=3D${COMPILER_TYPE} \ >> COMPILER_FREEBSD_VERSION=3D${COMPILER_FREEBSD_VERSION} >=20 > This does not use X_COMPILER_TYPE when it is defined. >=20 >> +.else >> +CROSSENV+=3D COMPILER_VERSION=3D${X_COMPILER_VERSION} \ >> + COMPILER_TYPE=3D${X_COMPILER_TYPE} \ >> + COMPILER_FREEBSD_VERSION=3D${X_COMPILER_FREEBSD_VERSION} >=20 > This tries to use the undefined X_COMPILER_TYPE. >=20 >> +.endif >=20 >=20 >=20 > Overall: >=20 > A not seems to be missing or instead the nested code blocks need to be = swapped. >=20 I'm an idiot, thanks. --=20 Regards, Bryan Drewery --wfb4BhwW7tSAf7Dgo8U1W5cAuCQ8rRh4X-- --WXp4voTb2LoiTSe57PCdhIbSH7E1DMetM 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 iQEcBAEBAgAGBQJXUxIZAAoJEDXXcbtuRpfP4N4H/2Ag9YZEOC3EBID3OQwd/cKT 3D5mJ07IGr1FZ0Ol90PUfYM+JS4iFgpMI56lQ3EwtHWMcss0JGzFhwlr/s51aVxg LZm8l2gebwXUoWx/DlrAEOryU+I5u12kGd37Felrugmm8zMMWzmF1TxJU1IKBt9F AyBVmqFjY9GqJ7DU62qa5nSDtPZiH0QNighkdyv5i1RxQ/n+4Uf+lw4fw0+1W5gG ymBQXOMXhHswk3JL1PIt35KzbAdLEq4Makcf2kpFXkAfKOizixHdhDtO6+Z0ZYwY WZ+NILEUpCHZpczv55P3cyjaJ6OziPua/kHKJnnzGzJRDlRV8jXKKjzfQJ8d6bA= =W+HW -----END PGP SIGNATURE----- --WXp4voTb2LoiTSe57PCdhIbSH7E1DMetM-- From owner-freebsd-current@freebsd.org Sat Jun 4 17:47: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 BCC2DB6A804 for ; Sat, 4 Jun 2016 17:47:51 +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 4BE381BE7; Sat, 4 Jun 2016 17:47:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u54HljaH074165 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 4 Jun 2016 20:47:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u54HljaH074165 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u54Hlj6W074164; Sat, 4 Jun 2016 20:47:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 4 Jun 2016 20:47:45 +0300 From: Konstantin Belousov To: Matthew Macy Cc: Michael Butler , "freebsd-current@freebsd.org" , alc@freebsd.org Subject: Re: repeatable panic on pageout with 945GM Message-ID: <20160604174745.GB38613@kib.kiev.ua> References: <2490f1c7-8153-ece3-49ed-4b3886564fd7@protected-networks.net> <205d4423-b834-9a21-785f-fa15d44c78ec@protected-networks.net> <1551419a1db.12929035f45012.326107747932338888@nextbsd.org> <939f9d2b-e925-e8e0-0ff3-8d90623728c6@protected-networks.net> <1551c5dbd86.c68532b5123717.566503881838650848@nextbsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1551c5dbd86.c68532b5123717.566503881838650848@nextbsd.org> User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 17:47:51 -0000 On Sat, Jun 04, 2016 at 10:02:33AM -0700, Matthew Macy wrote: > > > > > > > > This "band-aid" seems to have worked. I haven't had a single panic since > > - Thanks! :-) > > > > I tried to compile with -O0 but, for some reason, it panics in the sound > > driver with a double-fault. When I get time, I'll recompile only the > > files involved and see if I can't get a decent trace (and dump) to > > identify the cause, > > No need. Based on the line that it crashed at, the problem is that with no mappings no pv_entry has been allocated. Somehow on your laptop you're able to get in to a situation where fictitious pages have been added to the object that don't get mapped. This isn't a strange situation in and of itself, but you seem to be the only hitting this. > > In any event, the DRM 4.6 port will support AGP in about a week. It will probably have bugs, but this one isn't in any of its code paths. > > > I'm glad your system works a bit better now. > I believe that this is a bug in amd64 pmap. Fictitious pages are not promoted, in particular, the pv_table array does not span over the dynamically registered fictitious ranges. As result, pa_to_pvh() returns garbage and pvh must not be accessed in the case of 'small_mappings' in several pmap functions. It is typically not accessed, except in case when we have to drop and reacquire pv lock, to avoid LOR with pmap. i386 does not have the issue, due to pvh_global_lock. Below is the supposed fix (not tested). diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c index 7a93e76..e514b07 100644 --- a/sys/amd64/amd64/pmap.c +++ b/sys/amd64/amd64/pmap.c @@ -3947,12 +3947,14 @@ small_mappings: while ((pv = TAILQ_FIRST(&m->md.pv_list)) != NULL) { pmap = PV_PMAP(pv); if (!PMAP_TRYLOCK(pmap)) { - pvh_gen = pvh->pv_gen; + if ((m->flags & PG_FICTITIOUS) == 0) + pvh_gen = pvh->pv_gen; md_gen = m->md.pv_gen; rw_wunlock(lock); PMAP_LOCK(pmap); rw_wlock(lock); - if (pvh_gen != pvh->pv_gen || md_gen != m->md.pv_gen) { + if (((m->flags & PG_FICTITIOUS) == 0 && + pvh_gen != pvh->pv_gen) || md_gen != m->md.pv_gen) { rw_wunlock(lock); PMAP_UNLOCK(pmap); goto retry; @@ -5775,13 +5777,14 @@ small_mappings: TAILQ_FOREACH(pv, &m->md.pv_list, pv_next) { pmap = PV_PMAP(pv); if (!PMAP_TRYLOCK(pmap)) { - pvh_gen = pvh->pv_gen; + if ((m->flags & PG_FICTITIOUS) == 0) + pvh_gen = pvh->pv_gen; md_gen = m->md.pv_gen; rw_wunlock(lock); PMAP_LOCK(pmap); rw_wlock(lock); - if (pvh_gen != pvh->pv_gen || - md_gen != m->md.pv_gen) { + if (((m->flags & PG_FICTITIOUS) == 0 && + pvh_gen != pvh->pv_gen) || md_gen != m->md.pv_gen) { PMAP_UNLOCK(pmap); rw_wunlock(lock); goto retry_pv_loop; @@ -5985,12 +5988,14 @@ small_mappings: pvf = pv; pmap = PV_PMAP(pv); if (!PMAP_TRYLOCK(pmap)) { - pvh_gen = pvh->pv_gen; + if ((m->flags & PG_FICTITIOUS) == 0) + pvh_gen = pvh->pv_gen; md_gen = m->md.pv_gen; rw_wunlock(lock); PMAP_LOCK(pmap); rw_wlock(lock); - if (pvh_gen != pvh->pv_gen || md_gen != m->md.pv_gen) { + if (((m->flags & PG_FICTITIOUS) == 0 && + pvh_gen != pvh->pv_gen) || md_gen != m->md.pv_gen) { PMAP_UNLOCK(pmap); goto retry; } @@ -6248,11 +6253,13 @@ small_mappings: pmap = PV_PMAP(pv); if (!PMAP_TRYLOCK(pmap)) { md_gen = m->md.pv_gen; - pvh_gen = pvh->pv_gen; + if ((m->flags & PG_FICTITIOUS) == 0) + pvh_gen = pvh->pv_gen; rw_wunlock(lock); PMAP_LOCK(pmap); rw_wlock(lock); - if (pvh_gen != pvh->pv_gen || md_gen != m->md.pv_gen) { + if (((m->flags & PG_FICTITIOUS) == 0 && + pvh_gen != pvh->pv_gen) || md_gen != m->md.pv_gen) { PMAP_UNLOCK(pmap); goto restart; } From owner-freebsd-current@freebsd.org Sat Jun 4 17:51: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 D47C1B6A99D for ; Sat, 4 Jun 2016 17:51:13 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C40101DEB; Sat, 4 Jun 2016 17:51:13 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 146506266813942.65633986838202; Sat, 4 Jun 2016 10:51:08 -0700 (PDT) Date: Sat, 04 Jun 2016 10:51:08 -0700 From: Matthew Macy To: "Konstantin Belousov" Cc: "Michael Butler" , "freebsd-current@freebsd.org" , "" Message-ID: <1551c8a3732.cbde57d0124455.2726151520830111171@nextbsd.org> In-Reply-To: <20160604174745.GB38613@kib.kiev.ua> References: <2490f1c7-8153-ece3-49ed-4b3886564fd7@protected-networks.net> <205d4423-b834-9a21-785f-fa15d44c78ec@protected-networks.net> <1551419a1db.12929035f45012.326107747932338888@nextbsd.org> <939f9d2b-e925-e8e0-0ff3-8d90623728c6@protected-networks.net> <1551c5dbd86.c68532b5123717.566503881838650848@nextbsd.org> <20160604174745.GB38613@kib.kiev.ua> Subject: Re: repeatable panic on pageout with 945GM MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 17:51:13 -0000 > > I believe that this is a bug in amd64 pmap. Fictitious pages are not > promoted, in particular, the pv_table array does not span over the > dynamically registered fictitious ranges. As result, pa_to_pvh() returns > garbage and pvh must not be accessed in the case of 'small_mappings' in > several pmap functions. It is typically not accessed, except in case > when we have to drop and reacquire pv lock, to avoid LOR with pmap. Cool. Thanks for explaining that. -M > i386 does not have the issue, due to pvh_global_lock. > > Below is the supposed fix (not tested). > > diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c > index 7a93e76..e514b07 100644 > --- a/sys/amd64/amd64/pmap.c > +++ b/sys/amd64/amd64/pmap.c > @@ -3947,12 +3947,14 @@ small_mappings: > while ((pv = TAILQ_FIRST(&m->md.pv_list)) != NULL) { > pmap = PV_PMAP(pv); > if (!PMAP_TRYLOCK(pmap)) { > - pvh_gen = pvh->pv_gen; > + if ((m->flags & PG_FICTITIOUS) == 0) > + pvh_gen = pvh->pv_gen; > md_gen = m->md.pv_gen; > rw_wunlock(lock); > PMAP_LOCK(pmap); > rw_wlock(lock); > - if (pvh_gen != pvh->pv_gen || md_gen != m->md.pv_gen) { > + if (((m->flags & PG_FICTITIOUS) == 0 && > + pvh_gen != pvh->pv_gen) || md_gen != m->md.pv_gen) { > rw_wunlock(lock); > PMAP_UNLOCK(pmap); > goto retry; > @@ -5775,13 +5777,14 @@ small_mappings: > TAILQ_FOREACH(pv, &m->md.pv_list, pv_next) { > pmap = PV_PMAP(pv); > if (!PMAP_TRYLOCK(pmap)) { > - pvh_gen = pvh->pv_gen; > + if ((m->flags & PG_FICTITIOUS) == 0) > + pvh_gen = pvh->pv_gen; > md_gen = m->md.pv_gen; > rw_wunlock(lock); > PMAP_LOCK(pmap); > rw_wlock(lock); > - if (pvh_gen != pvh->pv_gen || > - md_gen != m->md.pv_gen) { > + if (((m->flags & PG_FICTITIOUS) == 0 && > + pvh_gen != pvh->pv_gen) || md_gen != m->md.pv_gen) { > PMAP_UNLOCK(pmap); > rw_wunlock(lock); > goto retry_pv_loop; > @@ -5985,12 +5988,14 @@ small_mappings: > pvf = pv; > pmap = PV_PMAP(pv); > if (!PMAP_TRYLOCK(pmap)) { > - pvh_gen = pvh->pv_gen; > + if ((m->flags & PG_FICTITIOUS) == 0) > + pvh_gen = pvh->pv_gen; > md_gen = m->md.pv_gen; > rw_wunlock(lock); > PMAP_LOCK(pmap); > rw_wlock(lock); > - if (pvh_gen != pvh->pv_gen || md_gen != m->md.pv_gen) { > + if (((m->flags & PG_FICTITIOUS) == 0 && > + pvh_gen != pvh->pv_gen) || md_gen != m->md.pv_gen) { > PMAP_UNLOCK(pmap); > goto retry; > } > @@ -6248,11 +6253,13 @@ small_mappings: > pmap = PV_PMAP(pv); > if (!PMAP_TRYLOCK(pmap)) { > md_gen = m->md.pv_gen; > - pvh_gen = pvh->pv_gen; > + if ((m->flags & PG_FICTITIOUS) == 0) > + pvh_gen = pvh->pv_gen; > rw_wunlock(lock); > PMAP_LOCK(pmap); > rw_wlock(lock); > - if (pvh_gen != pvh->pv_gen || md_gen != m->md.pv_gen) { > + if (((m->flags & PG_FICTITIOUS) == 0 && > + pvh_gen != pvh->pv_gen) || md_gen != m->md.pv_gen) { > PMAP_UNLOCK(pmap); > goto restart; > } > From owner-freebsd-current@freebsd.org Sat Jun 4 18:59:06 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F105EB6A951 for ; Sat, 4 Jun 2016 18:59:06 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [202.12.127.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.auburn.protected-networks.net", Issuer "Protected Networks Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BCC2012B6; Sat, 4 Jun 2016 18:59:06 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: imb@mail.auburn.protected-networks.net) by mail.auburn.protected-networks.net (Postfix) with ESMTPSA id 23CB91CC10; Sat, 4 Jun 2016 14:59:04 -0400 (EDT) Subject: Re: repeatable panic on pageout with 945GM To: Konstantin Belousov , Matthew Macy References: <2490f1c7-8153-ece3-49ed-4b3886564fd7@protected-networks.net> <205d4423-b834-9a21-785f-fa15d44c78ec@protected-networks.net> <1551419a1db.12929035f45012.326107747932338888@nextbsd.org> <939f9d2b-e925-e8e0-0ff3-8d90623728c6@protected-networks.net> <1551c5dbd86.c68532b5123717.566503881838650848@nextbsd.org> <20160604174745.GB38613@kib.kiev.ua> Cc: "freebsd-current@freebsd.org" , alc@freebsd.org From: Michael Butler Openpgp: id=6F63E6399DCC8E3E94D60F0642FF6BAE0442D492 Message-ID: <88ad4228-2583-8a91-1751-d16f7a51de91@protected-networks.net> Date: Sat, 4 Jun 2016 14:59:01 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160604174745.GB38613@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 18:59:07 -0000 On 06/04/16 13:47, Konstantin Belousov wrote: [ .. snip .. ] > I believe that this is a bug in amd64 pmap. Fictitious pages are not > promoted, in particular, the pv_table array does not span over the > dynamically registered fictitious ranges. As result, pa_to_pvh() returns > garbage and pvh must not be accessed in the case of 'small_mappings' in > several pmap functions. It is typically not accessed, except in case > when we have to drop and reacquire pv lock, to avoid LOR with pmap. > > i386 does not have the issue, due to pvh_global_lock. > > Below is the supposed fix (not tested). [ .. snip .. ] Is this something I should test and, should it not introduce any other issues, might get committed? imb From owner-freebsd-current@freebsd.org Sat Jun 4 19:02: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 97C4BB6ABB9 for ; Sat, 4 Jun 2016 19:02:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 162111A8A; Sat, 4 Jun 2016 19:02:45 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u54J2bst091957 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 4 Jun 2016 22:02:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u54J2bst091957 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u54J2bmB091956; Sat, 4 Jun 2016 22:02:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 4 Jun 2016 22:02:37 +0300 From: Konstantin Belousov To: Michael Butler Cc: Matthew Macy , "freebsd-current@freebsd.org" , alc@freebsd.org Subject: Re: repeatable panic on pageout with 945GM Message-ID: <20160604190237.GD38613@kib.kiev.ua> References: <2490f1c7-8153-ece3-49ed-4b3886564fd7@protected-networks.net> <205d4423-b834-9a21-785f-fa15d44c78ec@protected-networks.net> <1551419a1db.12929035f45012.326107747932338888@nextbsd.org> <939f9d2b-e925-e8e0-0ff3-8d90623728c6@protected-networks.net> <1551c5dbd86.c68532b5123717.566503881838650848@nextbsd.org> <20160604174745.GB38613@kib.kiev.ua> <88ad4228-2583-8a91-1751-d16f7a51de91@protected-networks.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <88ad4228-2583-8a91-1751-d16f7a51de91@protected-networks.net> User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 19:02:46 -0000 On Sat, Jun 04, 2016 at 02:59:01PM -0400, Michael Butler wrote: > On 06/04/16 13:47, Konstantin Belousov wrote: > > [ .. snip .. ] > > > I believe that this is a bug in amd64 pmap. Fictitious pages are not > > promoted, in particular, the pv_table array does not span over the > > dynamically registered fictitious ranges. As result, pa_to_pvh() returns > > garbage and pvh must not be accessed in the case of 'small_mappings' in > > several pmap functions. It is typically not accessed, except in case > > when we have to drop and reacquire pv lock, to avoid LOR with pmap. > > > > i386 does not have the issue, due to pvh_global_lock. > > > > Below is the supposed fix (not tested). > > [ .. snip .. ] > > Is this something I should test and, should it not introduce any other > issues, might get committed? Would be nice to test. I expect that this patch is going to be committed, after the review. From owner-freebsd-current@freebsd.org Sat Jun 4 19:11: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 4A5F4B6AEF4 for ; Sat, 4 Jun 2016 19:11:24 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.auburn.protected-networks.net", Issuer "Protected Networks Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1A359115D; Sat, 4 Jun 2016 19:11:24 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: imb@mail.auburn.protected-networks.net) by mail.auburn.protected-networks.net (Postfix) with ESMTPSA id 085411CC10; Sat, 4 Jun 2016 15:11:21 -0400 (EDT) Subject: Re: repeatable panic on pageout with 945GM To: Konstantin Belousov References: <2490f1c7-8153-ece3-49ed-4b3886564fd7@protected-networks.net> <205d4423-b834-9a21-785f-fa15d44c78ec@protected-networks.net> <1551419a1db.12929035f45012.326107747932338888@nextbsd.org> <939f9d2b-e925-e8e0-0ff3-8d90623728c6@protected-networks.net> <1551c5dbd86.c68532b5123717.566503881838650848@nextbsd.org> <20160604174745.GB38613@kib.kiev.ua> <88ad4228-2583-8a91-1751-d16f7a51de91@protected-networks.net> <20160604190237.GD38613@kib.kiev.ua> Cc: Matthew Macy , "freebsd-current@freebsd.org" , alc@freebsd.org From: Michael Butler Openpgp: id=6F63E6399DCC8E3E94D60F0642FF6BAE0442D492 Message-ID: Date: Sat, 4 Jun 2016 15:11:21 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160604190237.GD38613@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 19:11:24 -0000 On 06/04/16 15:02, Konstantin Belousov wrote: > On Sat, Jun 04, 2016 at 02:59:01PM -0400, Michael Butler wrote: >> On 06/04/16 13:47, Konstantin Belousov wrote: >> >> [ .. snip .. ] >> >>> I believe that this is a bug in amd64 pmap. Fictitious pages are not >>> promoted, in particular, the pv_table array does not span over the >>> dynamically registered fictitious ranges. As result, pa_to_pvh() returns >>> garbage and pvh must not be accessed in the case of 'small_mappings' in >>> several pmap functions. It is typically not accessed, except in case >>> when we have to drop and reacquire pv lock, to avoid LOR with pmap. >>> >>> i386 does not have the issue, due to pvh_global_lock. >>> >>> Below is the supposed fix (not tested). >> >> [ .. snip .. ] >> >> Is this something I should test and, should it not introduce any other >> issues, might get committed? > > Would be nice to test. I expect that this patch is going to be committed, > after the review. > I will do so this evening and add a kprintf to the previous band-aid to see if it prevents the problematic condition from occurring. If it counts, my test laptop has a Core-2 Duo so it is entirely possible that multiple threads are running concurrently, imb From owner-freebsd-current@freebsd.org Sat Jun 4 19:50: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 C3D89B68BEC; Sat, 4 Jun 2016 19:50:47 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8C12F18A5; Sat, 4 Jun 2016 19:50:47 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi0-x22d.google.com with SMTP id w184so174234546oiw.2; Sat, 04 Jun 2016 12:50:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=kzY2ioC65hSth8Q02Bg5A6yr2V1W883JdoT4G2ilPfk=; b=LiX61+usvm7Eea41ooOnBRJGu8wvSq3C0zBVytLw5gMK9XzB/s5FyP2pcpsW//2w8f pmKBbFo/1PgrkcbG4by/vIpKhxo9NHEInxdGWcn7NHQkOVAnPCpQohfDAff7au3NgEs6 dWk8ItMHpkS/i4PyPIYvKVoS+gYoPhfm88FVmQnvWueI62BnB5yIzt+3oZh3y1JHD0e4 yLPGDUXJA3RjfBYmyZ/K/EV8f6K0cQcqeQyO2GcZzJfZrGY56kJ3on96bDTUDv+YUrWZ Sl4MreYZGz1N8YBijlT7Wc9S8TLF6McwwzrXyt/Ra7EkOTmqER+DkbO5DN/MLSilXysr /vUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=kzY2ioC65hSth8Q02Bg5A6yr2V1W883JdoT4G2ilPfk=; b=PpRotLRKKhuk3g9+QPPHVqx6BxY8P9dFRU/u4UIek599jc+ze+JGbaFY+K81gQMxAe QJsc54yFn1RASq5LDe4u2MkQ7h7cX8fnvRyszDlKMHmCCZ7HhUUkNzalM3pk1xSNtIHw nuwOk/DXgBwKG3ZusUZHGPmi0Zqnnd8Lr83nOSyZ6sn5VYIFhsm6ETuHz59vFFqL5i26 J/SOvgrMQqev4gkKCIXfeQpFDkt1GOPjzl7tsdNXjPmAM8sHe8yJ6AFwKl25sr2YfeJR /65efUqJb9EaSBbSxbfNlGGjl38VokjhFQxzeioYaCWBNc9PmTkEqiNEC2K+a+4rOUPS xcrA== X-Gm-Message-State: ALyK8tKO+YfCeQY4TLtvEx+4hwgK91qdk4Tlp3ZIbyxmNWfBKlW2G1mbsDy0BDAyQr78mzSwOzl61gkLWHrBBA== X-Received: by 10.157.32.19 with SMTP id n19mr5496856ota.108.1465069846569; Sat, 04 Jun 2016 12:50:46 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.202.4.200 with HTTP; Sat, 4 Jun 2016 12:50:46 -0700 (PDT) In-Reply-To: <201606040043.u540hOVq045060@gw.catspoiler.org> References: <201606040011.u540BODD045000@gw.catspoiler.org> <201606040043.u540hOVq045060@gw.catspoiler.org> From: Alan Somers Date: Sat, 4 Jun 2016 13:50:46 -0600 X-Google-Sender-Auth: pP0c0HpAw5gw6uJ0FlJrJShtybg Message-ID: Subject: Re: VirtualBox network connectivity broken on recent -CURRENT To: Don Lewis Cc: FreeBSD CURRENT , freebsd-emulation@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 19:50:47 -0000 On Fri, Jun 3, 2016 at 6:43 PM, Don Lewis wrote: > On 3 Jun, Don Lewis wrote: >> It looks like something changed in -CURRENT to break network >> connectivity to VirtualBox guests. This was last known to work with >> r299139 (May 6th) and is definitely broken with r301229. The VirtualBox >> port revisions are: >> virtualbox-ose-4.3.38_1 >> virtualbox-ose-kmod-4.3.38 >> It looks like there was one change to the VirtualBox on May 9th, but it >> looks unlikely to be the cause of the problem. >> >> The network settings are: >> Attached to: Bridged Adapter >> Name: re0 >> Adapter Type: Paravirtualized Network (virtio-net) >> Promiscuous Mode: Deny >> MAC Address: [snip] >> Ifconfig says that the interface is up, but I am unable to ping either >> the host or anything else on the LAN from the guest. It looks like the >> problem is with outbound traffic. If I attempt to ping the guest, the >> source IP address and MAC address show up in the guest's arp table, but >> ping reports: >> ping: sendto: Host is down >> That makes me think that the arp responses from the guest are not >> getting transmitted. None of the machines involved are running >> firewalls. If I ping from the guest, I don't see any arp requests on >> the wire and the arp command shows the table entry as incomplete. >> >> The problem shows up with both FreeBSD -CURRENT and Debian guests. > > I see the same behaviour if I set: > Attached to: NAT > or > Adapter Type: 82540EM > Might be related to this routing bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207831