From owner-freebsd-stable@FreeBSD.ORG Sun Mar 22 00:27:03 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 36D58BEF for ; Sun, 22 Mar 2015 00:27:03 +0000 (UTC) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EE4B8F4E for ; Sun, 22 Mar 2015 00:27:02 +0000 (UTC) Received: by ieclw3 with SMTP id lw3so13762003iec.2 for ; Sat, 21 Mar 2015 17:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=xI92Q3UFsqcnJdvzaO+YXTt/TYo/78s2tW439rAMDzM=; b=f3WM1plUvtXMQ+Ol+kMbQ69Mc8ozp0VVZyqIZxOqPF1Afhhm465q1TKuyJPvdei6VJ kUZARLTF7a9jB6Xm8RWcNW73uyoXSFntwNBFa6DSeL7MX+y9Qbo6/oiA6+OfzAw7KCEY PhgGS86YjIMHBSn4dU5JAh18MsgllRFXo2Kw8r3y749Thkwfi2nnV194ccdWIkK5pKRk 4YNqm7QATdbdFb8a70k/OA225r4SqM7lJzDv0H/NCXjSNkam1XDRDDiEmXIs6gPbolHw 7ZGSWYGtuF8QCCq1QDTjIW7vB93ReCHFozVIkGmLVGY97CuRtI+gFnsMfs3YUlDz/4g5 FxUg== MIME-Version: 1.0 X-Received: by 10.50.32.70 with SMTP id g6mr5733126igi.35.1426984022276; Sat, 21 Mar 2015 17:27:02 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.107.174.86 with HTTP; Sat, 21 Mar 2015 17:27:02 -0700 (PDT) In-Reply-To: References: Date: Sat, 21 Mar 2015 17:27:02 -0700 X-Google-Sender-Auth: 9_XCpe3vYm8S9B8_ZkORRnU87M8 Message-ID: Subject: Re: dev.cpu.0.freq disapeared From: Kevin Oberman To: Dmitry Sivachenko Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Stable ML X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 00:27:03 -0000 On Sat, Mar 21, 2015 at 2:58 PM, Dmitry Sivachenko wrote: > Hello! > > I have a machine with the following processor: > > CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (2400.14-MHz K8-class > CPU) > Origin="GenuineIntel" Id=0x206c2 Family=0x6 Model=0x2c Stepping=2 > > When running 10.1-STABLE #5 r276908 I have: > % sysctl dev.cpu.0.freq > dev.cpu.0.freq: 2400 > % > > After I upgraded to 10.1-STABLE #0 r279956, this sysctl disapeared. > % sysctl dev.cpu.0.freq > sysctl: unknown oid 'dev.cpu.0.freq': No such file or directory > % > > I did not change kernel config file. > > What can be the cause of this problem? > > Thanks. > > # uname -a FreeBSD rogue 10.1-STABLE FreeBSD 10.1-STABLE #0 r280293: Fri Mar 20 11:28:08 PDT 2015 root@rogue:/usr/obj/usr/src/sys/GENERIC amd64 # sysctl dev.cpu.0.freq dev.cpu.0.freq: 2501 # No idea why it is not working for you. I'm guessing that something is not starting up properly, but I have no idea what. -- Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-stable@FreeBSD.ORG Sun Mar 22 05:53:51 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A445C259 for ; Sun, 22 Mar 2015 05:53:51 +0000 (UTC) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps.rulingia.com", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3281B62 for ; Sun, 22 Mar 2015 05:53:49 +0000 (UTC) Received: from server.rulingia.com (c220-239-242-83.belrs5.nsw.optusnet.com.au [220.239.242.83]) by vps.rulingia.com (8.14.9/8.14.9) with ESMTP id t2M5rYKX071485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 22 Mar 2015 16:53:44 +1100 (AEDT) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.9/8.14.9) with ESMTP id t2M5rOf6077459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 22 Mar 2015 16:53:24 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.9/8.14.9/Submit) id t2M5rNdQ077452; Sun, 22 Mar 2015 16:53:23 +1100 (AEDT) (envelope-from peter) Date: Sun, 22 Mar 2015 16:53:23 +1100 From: Peter Jeremy To: Dmitry Sivachenko Subject: Re: dev.cpu.0.freq disapeared Message-ID: <20150322055323.GA48710@server.rulingia.com> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.23 (2014-03-12) Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 05:53:51 -0000 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2015-Mar-22 00:58:55 +0300, Dmitry Sivachenko wrot= e: >I have a machine with the following processor: > >CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (2400.14-MHz K8-class= CPU) > Origin=3D"GenuineIntel" Id=3D0x206c2 Family=3D0x6 Model=3D0x2c Stepp= ing=3D2 =2E.. >After I upgraded to 10.1-STABLE #0 r279956, this sysctl disapeared. >% sysctl dev.cpu.0.freq >sysctl: unknown oid 'dev.cpu.0.freq': No such file or directory >% What OIDs do you have? Does dev.cpu.0 exist? How about dev.cpu? Can you set 'debug.cpufreq.verbose=3D"1"' in /boot/loader.conf and post (or make available) the dmesg from a verbose boot. --=20 Peter Jeremy --YiEDa0DAkWCtVeE4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJVDljTXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs02ZwP/iLQKd9/p05EpJ4fayroFqEb GwgMVzTi14HbYAUbkEwb5BcQOPC1BV0m5OUjQBzpOl2gmL76bZBVB7DpBfOTsn6S utPhQqNdx6VpElWbJuHSvo/UsFsxtrwi8pjs5sUBvyknQTjcWOGvfik8utLtCo/x uYXrOW96lII4IpFjDz8mMGMu+YWA2SdV98nHmh89SN9wMstI33DAlYMfExys2Jr7 qxwx8kXvbpQEs/ThnxWPWAuS2Spn7pRmxAyUYe6f8JV0PMz3TKmP+OfR9eonHBVl uo/OugWcclwznRTZ6rL/jYaRp0n9Rq2jGF2oChzFYvUdRagWjIZzfTtvZBaznS+Z pB0ji3m23zJkNEcgp7gnvaZRIVFBbba3yMULBeb0LdjFy5FykeNBjZMAd0CT5kGc bKbY6MKnzttZVS2zl9ZWsrpioLbG8Yp2cccsPjM2nf+8izxb0N89TEIqRy4paIs7 VBTUwuhVFHZ30fJWv9lpgrNuZpatp7ViM9WJIpWCRFb416IukpWK8v43lkVrhsWU Q2++W8pgWFhrf8FHGPD5RoCI/kzD86P9pubjmH5piztxCJpO5d53bBNAa+L/3ASV umM3kv4ZZkXj8KdZmA0G8NSeTvwa0W71qRodjeIm0hlu7QLu9648gKv724oNbEkH ywo0HSNCBCtsoPzT/0lZ =+tuX -----END PGP SIGNATURE----- --YiEDa0DAkWCtVeE4-- From owner-freebsd-stable@FreeBSD.ORG Sun Mar 22 08:22:17 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 44B3818B for ; Sun, 22 Mar 2015 08:22:17 +0000 (UTC) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E8A97FDA for ; Sun, 22 Mar 2015 08:22:16 +0000 (UTC) Received: from th-04.cs.huji.ac.il ([132.65.80.125]) by kabab.cs.huji.ac.il with esmtp id 1YZb2l-000P18-Ob; Sun, 22 Mar 2015 10:15:35 +0200 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: dev.cpu.0.freq disapeared From: Daniel Braniss In-Reply-To: <20150322055323.GA48710@server.rulingia.com> Date: Sun, 22 Mar 2015 10:15:35 +0200 Message-Id: <77826117-EE4B-4268-9397-C7F9AA6FB8AD@cs.huji.ac.il> References: <20150322055323.GA48710@server.rulingia.com> To: Peter Jeremy X-Mailer: Apple Mail (2.2070.6) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: stable@freebsd.org, Dmitry Sivachenko X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 08:22:17 -0000 Hi Jeremy, I have a similar issue with an Sun Fire X2200: CPU: Dual-Core AMD Opteron(tm) Processor 2218 (2613.45-MHz K8-class CPU) Origin=3D"AuthenticAMD" Id=3D0x40f13 Family=3D0xf Model=3D0x41 = Stepping=3D3 = Features=3D0x178bfbff Features2=3D0x2001 AMD = Features=3D0xea500800 AMD Features2=3D0x1f SVM: NAsids=3D64 and setting debug.cpufreq.verbose=3D=E2=80=9C1" does not make a difference (ran diff with and without it) you can get it at: ftp://ftp.cs.huji.ac.il/users/danny/freebsd/dmesg.boot = cheers, danny > On Mar 22, 2015, at 7:53 AM, Peter Jeremy wrote: >=20 > On 2015-Mar-22 00:58:55 +0300, Dmitry Sivachenko = wrote: >> I have a machine with the following processor: >>=20 >> CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (2400.14-MHz = K8-class CPU) >> Origin=3D"GenuineIntel" Id=3D0x206c2 Family=3D0x6 Model=3D0x2c = Stepping=3D2 > ... >> After I upgraded to 10.1-STABLE #0 r279956, this sysctl disapeared. >> % sysctl dev.cpu.0.freq >> sysctl: unknown oid 'dev.cpu.0.freq': No such file or directory >> % >=20 > What OIDs do you have? Does dev.cpu.0 exist? How about dev.cpu? >=20 > Can you set 'debug. in /boot/loader.conf and post > (or make available) the dmesg from a verbose boot. >=20 > --=20 > Peter Jeremy From owner-freebsd-stable@FreeBSD.ORG Sun Mar 22 08:41:11 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6A377519 for ; Sun, 22 Mar 2015 08:41:11 +0000 (UTC) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DA07D1E6 for ; Sun, 22 Mar 2015 08:41:10 +0000 (UTC) Received: by lagg8 with SMTP id g8so114095394lag.1 for ; Sun, 22 Mar 2015 01:41:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZLKH5kkFyR/Inx6azLlk7OhkzPdtvBtWktZ/+JYHFgM=; b=itYtokl9dcje5R6ZkDl1Oqys9s+oWgYLvXDXt5fOokEStCvDH+ocxXW+s9Q6ltZv9J VREPkYLigfX5xnm368nI/aByST7F0or84+kzdTeBgs4ycn8JCn5+4bkbgB56aklXHYuM QdQ9OZdEsq6V9/CwgjKGxqzcEomDHNC3SFB03ZAm2ZhvKWP6lXtbk3ISVllXVZoswOQI qmu8l1Mnub5kFVahJUd7brtmzHcgza2w8/Ww9z+U5y1auTXiqUoMrtoHck8giljBeXrx hHxRGHm1PVkt79mdfUvJeWugerI1lZQWzRgl6sIrlvLTrSEEVKSkSiNd30oC4R1gn4v6 qqeQ== X-Received: by 10.152.37.69 with SMTP id w5mr79409624laj.15.1427013668463; Sun, 22 Mar 2015 01:41:08 -0700 (PDT) Received: from [10.0.1.7] (broadband-5-228-253-252.nationalcablenetworks.ru. [5.228.253.252]) by mx.google.com with ESMTPSA id n9sm1917236lbp.0.2015.03.22.01.41.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 22 Mar 2015 01:41:07 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: dev.cpu.0.freq disapeared From: Dmitry Sivachenko In-Reply-To: Date: Sun, 22 Mar 2015 11:41:05 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <23073B07-C090-4404-9C37-D289A137FF6D@gmail.com> References: To: Kevin Oberman X-Mailer: Apple Mail (2.2070.6) Cc: FreeBSD Stable ML X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 08:41:11 -0000 > On 22 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2015 =D0=B3., at 3:27, Kevin = Oberman wrote: >=20 >=20 > # uname -a FreeBSD rogue 10.1-STABLE FreeBSD 10.1-STABLE #0 r280293: = Fri Mar 20 11:28:08 PDT 2015 root@rogue:/usr/obj/usr/src/sys/GENERIC = amd64 > # sysctl dev.cpu.0.freq > dev.cpu.0.freq: 2501 > #=20 > No idea why it is not working for you. I'm guessing that something is = not starting up properly, but I have no idea what. This problem seems to be processor-specific: I have a lot of E5-2660 = machines which do not suffer this issue.= From owner-freebsd-stable@FreeBSD.ORG Sun Mar 22 09:05:54 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94086A24; Sun, 22 Mar 2015 09:05:54 +0000 (UTC) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::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 11F035E0; Sun, 22 Mar 2015 09:05:54 +0000 (UTC) Received: by labon10 with SMTP id on10so13655608lab.2; Sun, 22 Mar 2015 02:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1yolAFLEnDB2n0eENcdXA/U27k8HJpIY+MHbtNmyG58=; b=teP+Or2NrD9pAb13SX0nuDqAYfeN7RK1PphNdNdrtks/5VZX3E+XUSxLPyJVVYfBpn D/pmll5x9dm5sr/3Rt37UZI/5DUQfyV52geJdLDWXMkS8UMpVQOEPiLsgmacFwvv0TP6 HyUdfmNHGH9QBC5nBJ9NNbg2vc6EAIKVtDPLv81l5AByMJvb1uMHIbQCIFGcUc+HZwPR CLBTyfpOCPGjutXIEqX8hAzLCHHlGSbzn6UQgjOZbTQqDcxJO8leVgjiDQoB9Dy1wktu K/PLvUvBPPhAcoh5l7EnyQ1DV5luhQFvk3uwYtjTYpRY4/WtnyYtnY+M2TX7pPUH+Lvy x5wg== X-Received: by 10.112.64.2 with SMTP id k2mr80556778lbs.54.1427015151864; Sun, 22 Mar 2015 02:05:51 -0700 (PDT) Received: from [10.0.1.7] (broadband-5-228-253-252.nationalcablenetworks.ru. [5.228.253.252]) by mx.google.com with ESMTPSA id ed5sm1920421lbb.40.2015.03.22.02.05.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 22 Mar 2015 02:05:50 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: dev.cpu.0.freq disapeared From: Dmitry Sivachenko In-Reply-To: <20150322055323.GA48710@server.rulingia.com> Date: Sun, 22 Mar 2015 12:05:49 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <77C8F6F7-2C25-4BC5-B373-11441AB58FAD@gmail.com> References: <20150322055323.GA48710@server.rulingia.com> To: Peter Jeremy X-Mailer: Apple Mail (2.2070.6) Cc: FreeBSD Stable ML , nwhitehorn@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 09:05:54 -0000 > On 22 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2015 =D0=B3., at 8:53, Peter = Jeremy wrote: >=20 > On 2015-Mar-22 00:58:55 +0300, Dmitry Sivachenko = wrote: >> I have a machine with the following processor: >>=20 >> CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (2400.14-MHz = K8-class CPU) >> Origin=3D"GenuineIntel" Id=3D0x206c2 Family=3D0x6 Model=3D0x2c = Stepping=3D2 > ... >> After I upgraded to 10.1-STABLE #0 r279956, this sysctl disapeared. >> % sysctl dev.cpu.0.freq >> sysctl: unknown oid 'dev.cpu.0.freq': No such file or directory >> % >=20 > What OIDs do you have? Does dev.cpu.0 exist? How about dev.cpu? dev.cpu.0 does exist. =20 I found the problematic change: Author: nwhitehorn Date: Sun Jan 11 17:10:07 2015 New Revision: 276986 URL: https://svnweb.freebsd.org/changeset/base/276986 Log: MFC r265329: Disable ACPI and P4TCC throttling by default, following discussion on freebsd-current. These CPU speed control techniques are usually = unhelpful at best. For now, continue building the relevant code into GENERIC so = that it can trivially be re-enabled at runtime if anyone wants it. Modified: stable/10/sys/amd64/conf/GENERIC.hints = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- stable/10/sys/amd64/conf/GENERIC.hints Sun Jan 11 17:00:24 2015 = (r276985) +++ stable/10/sys/amd64/conf/GENERIC.hints Sun Jan 11 17:10:07 2015 = (r276986) @@ -31,3 +31,5 @@ hint.attimer.0.at=3D"isa" hint.attimer.0.port=3D"0x40" hint.attimer.0.irq=3D"0" hint.wbwd.0.at=3D"isa" +hint.acpi_throttle.0.disabled=3D"1" +hint.p4tcc.0.disabled=3D"1" If I remove that hint.p4tcc.0.disabled=3D"1" from device.hints, = dev.cpu.0.freq appears back again. I am using dev.cpu.0.freq to ensure that processor is running at = expected frequency (with some buggy BIOSes or buggy BIOS options = combinations it is possible to end up with machine running at half = frequency). Does it really hurt to have this sysctl available? Why it was disabled = by default? (I am not discussing hint.acpi_throttle.0.disabled here, just = hint.p4tcc.0.disabled). Thanks. From owner-freebsd-stable@FreeBSD.ORG Sun Mar 22 14:12:05 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 99F754AC; Sun, 22 Mar 2015 14:12:05 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (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 D347D402; Sun, 22 Mar 2015 14:12:03 +0000 (UTC) Received: from t23.smithi.id.au (ozone [115.70.72.192]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t2MEBkdj070816; Mon, 23 Mar 2015 01:11:52 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Message-ID: <550ECD9D.2030108@nimnet.asn.au> Date: Mon, 23 Mar 2015 01:11:41 +1100 From: Ian Smith Organization: Nimbin Network Association User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.23) Gecko/20091022 SeaMonkey/1.1.18 MIME-Version: 1.0 To: Dmitry Sivachenko Subject: Re: dev.cpu.0.freq disapeared References: <20150322055323.GA48710@server.rulingia.com> <77C8F6F7-2C25-4BC5-B373-11441AB58FAD@gmail.com> In-Reply-To: <77C8F6F7-2C25-4BC5-B373-11441AB58FAD@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Stable ML , Peter Jeremy , nwhitehorn@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 14:12:05 -0000 Dmitry Sivachenko wrote: >> On 22 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2015 =D0=B3., at 8:53, Peter Jere= my =20 >> wrote: >>=20 >> On 2015-Mar-22 00:58:55 +0300, Dmitry Sivachenko=20 >> wrote: >>> I have a machine with the following processor: >>>=20 >>> CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (2400.14-MHz >>> K8-class CPU) Origin=3D"GenuineIntel" Id=3D0x206c2 Family=3D0x6=20 >>> Model=3D0x2c Stepping=3D2 >> ... >>> After I upgraded to 10.1-STABLE #0 r279956, this sysctl=20 >>> disapeared. % sysctl dev.cpu.0.freq sysctl: unknown oid=20 >>> 'dev.cpu.0.freq': No such file or directory % >> What OIDs do you have? Does dev.cpu.0 exist? How about dev.cpu? >=20 > dev.cpu.0 does exist. It could be helpful to show all of: % sysctl dev.cpu % sysctl dev.est # if you have that? % sysctl -a | grep freq | grep -v time both before and after re-enabling p4tcc. > I found the problematic change: >=20 > Author: nwhitehorn Date: Sun Jan 11 17:10:07 2015 New Revision:=20 > 276986 URL: https://svnweb.freebsd.org/changeset/base/276986 >=20 > Log: MFC r265329: Disable ACPI and P4TCC throttling by default,=20 > following discussion on freebsd-current. These CPU speed control=20 > techniques are usually unhelpful at best. For now, continue building=20 > the relevant code into GENERIC so that it can trivially be re-enabled > at runtime if anyone wants it. >=20 > Modified: stable/10/sys/amd64/conf/GENERIC.hints=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > --- stable/10/sys/amd64/conf/GENERIC.hints Sun Jan 11 17:00:24 2015=20 > (r276985) +++ stable/10/sys/amd64/conf/GENERIC.hints Sun Jan 11=20 > 17:10:07 2015 (r276986) @@ -31,3 +31,5 @@ hint.attimer.0.at=3D"isa"=20 > hint.attimer.0.port=3D"0x40" hint.attimer.0.irq=3D"0"=20 > hint.wbwd.0.at=3D"isa" +hint.acpi_throttle.0.disabled=3D"1"=20 > +hint.p4tcc.0.disabled=3D"1" >=20 >=20 > If I remove that hint.p4tcc.0.disabled=3D"1" from device.hints,=20 > dev.cpu.0.freq appears back again. 'Trivial re-enabling' would be adding hint.p4tcc.0.disabled=3D"0" to /boot/loader.conf. This seems very strange though, if it really is due solely to disabling p4tcc and acpi_throttle. > I am using dev.cpu.0.freq to ensure that processor is running at=20 > expected frequency (with some buggy BIOSes or buggy BIOS options=20 > combinations it is possible to end up with machine running at half=20 > frequency). Are you not running powerd? Of course powerd won't start if it can't get dev.cpu.0.freq but you can ordinarily use it to set lowest and/or highest freqs. Once FreeBSD starts, BIOS settings should have little do with it, AFAIK, except how they might set freq before powerd starts. > Does it really hurt to have this sysctl available? Why it was=20 > disabled by default? It's a long story; (a) short story is using it to vary freqs doesn't save any power, but makes powerd work harder matching freq to load. > (I am not discussing hint.acpi_throttle.0.disabled here, just=20 > hint.p4tcc.0.disabled). Some or many systems will use ACPI throttling instead if p4tcc (or equivalent on AMD or other processors) isn't enabled, so they both need disabling to run 'raw' EST or equivalent. A link to a verbose boot would be good, before and after if possible. cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Sun Mar 22 16:29:42 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54132379; Sun, 22 Mar 2015 16:29:42 +0000 (UTC) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1289F2A2; Sun, 22 Mar 2015 16:29:42 +0000 (UTC) Received: by igbud6 with SMTP id ud6so24190240igb.1; Sun, 22 Mar 2015 09:29:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=byv4UzMH1OjunKu82xcttQ8HChs3T8DTBpDkMwxIGAY=; b=ZrpAyU3NGBLQHH4wIUuojcM2GJxjNVKFOYFXCKecs6sFoUU3SlzMQtS3579x2P92uW 6TRIsqbQAQ7FbzaeNtgfBr7go3a8dkufJ2cdCdauleScB/DFtPxg6ZbKvYMfImuJ1gna hx+L/VEViW7kd4SvIztd4sL6yrVT2rYz6ictoQytHe7KSUdbtSrAc6F2aR0LWL5i+QPU BqCLwSfW1EVRGP9W9U+MkW9pzHWbtQvCTREOF1mT9uhNauifWX5ThGMJ3PdtETAYijZr bPgjlGXVg1v5XCfKuF9NNwW6JvA9EaAFYoajfalb62VfZbdog7IbcpxfU1vo4KNEQoTi E/0Q== MIME-Version: 1.0 X-Received: by 10.50.143.36 with SMTP id sb4mr9323666igb.0.1427041781475; Sun, 22 Mar 2015 09:29:41 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.107.174.86 with HTTP; Sun, 22 Mar 2015 09:29:41 -0700 (PDT) In-Reply-To: <550ECD9D.2030108@nimnet.asn.au> References: <20150322055323.GA48710@server.rulingia.com> <77C8F6F7-2C25-4BC5-B373-11441AB58FAD@gmail.com> <550ECD9D.2030108@nimnet.asn.au> Date: Sun, 22 Mar 2015 09:29:41 -0700 X-Google-Sender-Auth: xufajubU7jVdKhWMFoVEejhRq4g Message-ID: Subject: Re: dev.cpu.0.freq disapeared From: Kevin Oberman To: Ian Smith Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Peter Jeremy , FreeBSD Stable ML , Dmitry Sivachenko , Nathan Whitehorn X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 16:29:42 -0000 On Sun, Mar 22, 2015 at 7:11 AM, Ian Smith wrote: > Dmitry Sivachenko wrote: > >> On 22 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2015 =D0=B3., at 8:53, Peter Jeremy= wrote: >>> >>> On 2015-Mar-22 00:58:55 +0300, Dmitry Sivachenko >>> wrote: >>> >>>> I have a machine with the following processor: >>>> >>>> CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (2400.14-MHz >>>> K8-class CPU) Origin=3D"GenuineIntel" Id=3D0x206c2 Family=3D0x6 >>>> Model=3D0x2c Stepping=3D2 >>>> >>> ... >>> >>>> After I upgraded to 10.1-STABLE #0 r279956, this sysctl disapeared. % >>>> sysctl dev.cpu.0.freq sysctl: unknown oid 'dev.cpu.0.freq': No such fi= le or >>>> directory % >>>> >>> > What OIDs do you have? Does dev.cpu.0 exist? How about dev.cpu? >>> >> >> dev.cpu.0 does exist. >> > > It could be helpful to show all of: > > % sysctl dev.cpu > % sysctl dev.est # if you have that? > % sysctl -a | grep freq | grep -v time > > both before and after re-enabling p4tcc. > > I found the problematic change: >> >> Author: nwhitehorn Date: Sun Jan 11 17:10:07 2015 New Revision: 276986 >> URL: https://svnweb.freebsd.org/changeset/base/276986 >> >> Log: MFC r265329: Disable ACPI and P4TCC throttling by default, followin= g >> discussion on freebsd-current. These CPU speed control techniques are >> usually unhelpful at best. For now, continue building the relevant code >> into GENERIC so that it can trivially be re-enabled >> at runtime if anyone wants it. >> >> Modified: stable/10/sys/amd64/conf/GENERIC.hints >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- stable/10/sys/amd64/conf/GENERIC.hints Sun Jan 11 17:00:24 2015 >> (r276985) +++ stable/10/sys/amd64/conf/GENERIC.hints Sun Jan 11 >> 17:10:07 2015 (r276986) @@ -31,3 +31,5 @@ hint.attimer.0.at=3D"is= a" >> hint.attimer.0.port=3D"0x40" hint.attimer.0.irq=3D"0" hint.wbwd.0.at=3D"= isa" >> +hint.acpi_throttle.0.disabled=3D"1" +hint.p4tcc.0.disabled=3D"1" >> >> >> If I remove that hint.p4tcc.0.disabled=3D"1" from device.hints, >> dev.cpu.0.freq appears back again. >> > > 'Trivial re-enabling' would be adding hint.p4tcc.0.disabled=3D"0" to > /boot/loader.conf. This seems very strange though, if it really is > due solely to disabling p4tcc and acpi_throttle. > > I am using dev.cpu.0.freq to ensure that processor is running at expecte= d >> frequency (with some buggy BIOSes or buggy BIOS options combinations it = is >> possible to end up with machine running at half frequency). >> > > Are you not running powerd? Of course powerd won't start if it can't > get dev.cpu.0.freq but you can ordinarily use it to set lowest and/or > highest freqs. Once FreeBSD starts, BIOS settings should have little > do with it, AFAIK, except how they might set freq before powerd starts. > > Does it really hurt to have this sysctl available? Why it was disabled >> by default? >> > > It's a long story; (a) short story is using it to vary freqs doesn't > save any power, but makes powerd work harder matching freq to load. > > (I am not discussing hint.acpi_throttle.0.disabled here, just >> hint.p4tcc.0.disabled). >> > > Some or many systems will use ACPI throttling instead if p4tcc (or > equivalent on AMD or other processors) isn't enabled, so they both > need disabling to run 'raw' EST or equivalent. > > A link to a verbose boot would be good, before and after if possible. > > cheers, Ian > > First, my system which does have powerd and dev.cpu.0.freq has been running without p4tcc for years. From my loader.conf file: # Disable CPU throttling hint.p4tcc.0.disabled=3D1 hint.acpi_throttle.0.disabled=3D1 But I do have EST. If that is missing, so is dev.cpu.0.freq. Do you see "sysctl dev.est"? It should include freq_settings for each CPU. Processors older than P4s did not have the more efficient TCC capability, so the more primitive throttling was used. By default, when TCC is available, it is used. If not, throttling is used. Of course, almost all i386 and all amd64 processors should have TCC, so, unless TCC is disabled, throttling is not used. TCC is the Thermal Control Circuit. Note that it was designed and intended to be a rather heavy handed way to prevent overheating of the CPU. It was never intended nor is it useful for power management. Worse, it can interfere with C-states, by far the most effective power management tool available, at least when used the way powerd uses it. This "unpleasant" interaction that lead to system lock-up resulted in C-states being disabled, just adding insult to injury. Head should now have the "correct" settings with throttling and p4tcc disabled and both performance and economy_cx_lowest defaulting to Cmax. The real issue appears to be that some systems seem to not have EST. I am suspicious that this may be the case for some or all non-i386/amd64 processors. Even if EST is not available, turning on TCC or throttling is not going to save any power. It just means that the system will not have the ability to have multiple CPU frequencies. If you want more details on power issues in FreeBSD, I would point you to the excellent article by mav@ at https://wiki.freebsd.org/TuningPowerConsumption. He covers all of the research I did independently back when I was at Lawrence Berkeley.Lab back in the 90s and extends it to cover most modern technologies not available when I did my research. -- Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-stable@FreeBSD.ORG Sun Mar 22 16:35:55 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D1A31782 for ; Sun, 22 Mar 2015 16:35:55 +0000 (UTC) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 AFD5D3B6 for ; Sun, 22 Mar 2015 16:35:55 +0000 (UTC) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t2MGZiqa030172 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 22 Mar 2015 09:35:45 -0700 Message-ID: <550EEF60.20406@freebsd.org> Date: Sun, 22 Mar 2015 09:35:44 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Kevin Oberman , Ian Smith Subject: Re: dev.cpu.0.freq disapeared References: <20150322055323.GA48710@server.rulingia.com> <77C8F6F7-2C25-4BC5-B373-11441AB58FAD@gmail.com> <550ECD9D.2030108@nimnet.asn.au> In-Reply-To: X-Sonic-CAuth: UmFuZG9tSVbhPMFUT6CXMEJEmJ6IXoKpJUW1iSErtxDHtbslkW6fx6ykBOEe3901CB8Exg4rDfBGInj2DyFBflD9EN+zEm7Vq0tVG88m08w= X-Sonic-ID: C;ELKFfLHQ5BGPlNBwQIsAyQ== M;xg4JfbHQ5BGPlNBwQIsAyQ== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Peter Jeremy , FreeBSD Stable ML , Dmitry Sivachenko X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 16:35:55 -0000 On 03/22/15 09:29, Kevin Oberman wrote: > On Sun, Mar 22, 2015 at 7:11 AM, Ian Smith > wrote: > > Dmitry Sivachenko wrote: > > On 22 марта 2015 г., at 8:53, Peter Jeremy > > wrote: > > On 2015-Mar-22 00:58:55 +0300, Dmitry Sivachenko > > wrote: > > I have a machine with the following processor: > > CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz > (2400.14-MHz > K8-class CPU) Origin="GenuineIntel" Id=0x206c2 > Family=0x6 Model=0x2c Stepping=2 > > ... > > After I upgraded to 10.1-STABLE #0 r279956, this > sysctl disapeared. % sysctl dev.cpu.0.freq sysctl: > unknown oid 'dev.cpu.0.freq': No such file or directory % > > > What OIDs do you have? Does dev.cpu.0 exist? How about > dev.cpu? > > > dev.cpu.0 does exist. > > > It could be helpful to show all of: > > % sysctl dev.cpu > % sysctl dev.est # if you have that? > % sysctl -a | grep freq | grep -v time > > both before and after re-enabling p4tcc. > > I found the problematic change: > > Author: nwhitehorn Date: Sun Jan 11 17:10:07 2015 New > Revision: 276986 URL: > https://svnweb.freebsd.org/changeset/base/276986 > > Log: MFC r265329: Disable ACPI and P4TCC throttling by > default, following discussion on freebsd-current. These CPU > speed control techniques are usually unhelpful at best. For > now, continue building the relevant code into GENERIC so that > it can trivially be re-enabled > at runtime if anyone wants it. > > Modified: stable/10/sys/amd64/conf/GENERIC.hints > ============================================================================== > --- stable/10/sys/amd64/conf/GENERIC.hints Sun Jan 11 > 17:00:24 2015 (r276985) +++ > stable/10/sys/amd64/conf/GENERIC.hints Sun Jan 11 17:10:07 > 2015 (r276986) @@ -31,3 +31,5 @@ hint.attimer.0.at > ="isa" hint.attimer.0.port="0x40" > hint.attimer.0.irq="0" hint.wbwd.0.at > ="isa" > +hint.acpi_throttle.0.disabled="1" +hint.p4tcc.0.disabled="1" > > > If I remove that hint.p4tcc.0.disabled="1" from device.hints, > dev.cpu.0.freq appears back again. > > > 'Trivial re-enabling' would be adding hint.p4tcc.0.disabled="0" to > /boot/loader.conf. This seems very strange though, if it really is > due solely to disabling p4tcc and acpi_throttle. > > I am using dev.cpu.0.freq to ensure that processor is running > at expected frequency (with some buggy BIOSes or buggy BIOS > options combinations it is possible to end up with machine > running at half frequency). > > > Are you not running powerd? Of course powerd won't start if it can't > get dev.cpu.0.freq but you can ordinarily use it to set lowest and/or > highest freqs. Once FreeBSD starts, BIOS settings should have little > do with it, AFAIK, except how they might set freq before powerd > starts. > > Does it really hurt to have this sysctl available? Why it was > disabled by default? > > > It's a long story; (a) short story is using it to vary freqs doesn't > save any power, but makes powerd work harder matching freq to load. > > (I am not discussing hint.acpi_throttle.0.disabled here, just > hint.p4tcc.0.disabled). > > > Some or many systems will use ACPI throttling instead if p4tcc (or > equivalent on AMD or other processors) isn't enabled, so they both > need disabling to run 'raw' EST or equivalent. > > A link to a verbose boot would be good, before and after if possible. > > cheers, Ian > > > First, my system which does have powerd and dev.cpu.0.freq has been > running without p4tcc for years. From my loader.conf file: > # Disable CPU throttling > hint.p4tcc.0.disabled=1 > hint.acpi_throttle.0.disabled=1 > But I do have EST. If that is missing, so is dev.cpu.0.freq. Do you > see "sysctl dev.est"? It should include freq_settings for each CPU. > > Processors older than P4s did not have the more efficient TCC > capability, so the more primitive throttling was used. By default, > when TCC is available, it is used. If not, throttling is used. Of > course, almost all i386 and all amd64 processors should have TCC, so, > unless TCC is disabled, throttling is not used. > > TCC is the Thermal Control Circuit. Note that it was designed and > intended to be a rather heavy handed way to prevent overheating of the > CPU. It was never intended nor is it useful for power management. > Worse, it can interfere with C-states, by far the most effective power > management tool available, at least when used the way powerd uses it. > This "unpleasant" interaction that lead to system lock-up resulted in > C-states being disabled, just adding insult to injury. Head should now > have the "correct" settings with throttling and p4tcc disabled and > both performance and economy_cx_lowest defaulting to Cmax. > > The real issue appears to be that some systems seem to not have EST. I > am suspicious that this may be the case for some or all non-i386/amd64 > processors. Even if EST is not available, turning on TCC or throttling > is not going to save any power. It just means that the system will not > have the ability to have multiple CPU frequencies. Thanks for the nice summary. We do in fact have non-x86 CPUs with real power management and EST-equivalent clock changing that are supported by FreeBSD. I think the P4-era stuff is the only hardware that uses throttling/TCC-type logic. -Nathan > If you want more details on power issues in FreeBSD, I would point you > to the excellent article by mav@ at > https://wiki.freebsd.org/TuningPowerConsumption. He covers all of the > research I did independently back when I was at Lawrence Berkeley.Lab > back in the 90s and extends it to cover most modern technologies not > available when I did my research. > -- > Kevin Oberman, Network Engineer, Retired > E-mail: rkoberman@gmail.com From owner-freebsd-stable@FreeBSD.ORG Sun Mar 22 17:11:42 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F18DD96; Sun, 22 Mar 2015 17:11:42 +0000 (UTC) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7379693F; Sun, 22 Mar 2015 17:11:41 +0000 (UTC) Received: by labon10 with SMTP id on10so17932588lab.2; Sun, 22 Mar 2015 10:11:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7IUcNdyYT10qmxMhIRxlXXj6tHD5206WSsVEZ3AG5iE=; b=B2dRmh/CWub73vQ2syHIvKUbM2E5CsHizXj/Wd/BJiOvnwY55XGaR5furSw7Y9dZ0Y FEBYCpHH43smCc+nVTtFr4OPdzEZmPvYOtLIfCRC7p0QaJeaIFPCKcaii+Ka3GAAw15h hnAt3BAGjnUzRxSd4dJrRl7oWH8P29paHqsvrMd91ogNqNhZ2ZH9TOIXE5LVPV7GuCSW EOHCmEbSAlLXqvgkS+98FfbRV7xj291Y18NEvgRawm/c1WPchLRhhNFgM552az4v8UrX 6g/c2l+ivWpUE6cIpMZv0emz8SQOi0coXD0v8rGMVTNMAEz0lobzHaYYuHFdP268Vi41 eIYg== X-Received: by 10.152.243.4 with SMTP id wu4mr81071160lac.33.1427044299327; Sun, 22 Mar 2015 10:11:39 -0700 (PDT) Received: from [10.0.1.7] (broadband-5-228-253-252.nationalcablenetworks.ru. [5.228.253.252]) by mx.google.com with ESMTPSA id ed5sm2116726lbb.40.2015.03.22.10.11.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 22 Mar 2015 10:11:38 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: dev.cpu.0.freq disapeared From: Dmitry Sivachenko In-Reply-To: <550ECD9D.2030108@nimnet.asn.au> Date: Sun, 22 Mar 2015 20:11:36 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <97279AFB-7718-4080-9F18-155287216A04@gmail.com> References: <20150322055323.GA48710@server.rulingia.com> <77C8F6F7-2C25-4BC5-B373-11441AB58FAD@gmail.com> <550ECD9D.2030108@nimnet.asn.au> To: Ian Smith X-Mailer: Apple Mail (2.2070.6) Cc: FreeBSD Stable ML , Peter Jeremy , nwhitehorn@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 17:11:42 -0000 > On 22 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2015 =D0=B3., at 17:11, Ian Smith = wrote: >=20 > Dmitry Sivachenko wrote: >>> On 22 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2015 =D0=B3., at 8:53, Peter = Jeremy wrote: >>> On 2015-Mar-22 00:58:55 +0300, Dmitry Sivachenko = wrote: >>>> I have a machine with the following processor: >>>> CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (2400.14-MHz >>>> K8-class CPU) Origin=3D"GenuineIntel" Id=3D0x206c2 Family=3D0x6 = Model=3D0x2c Stepping=3D2 >>> ... >>>> After I upgraded to 10.1-STABLE #0 r279956, this sysctl disapeared. = % sysctl dev.cpu.0.freq sysctl: unknown oid 'dev.cpu.0.freq': No such = file or directory % >=20 >>> What OIDs do you have? Does dev.cpu.0 exist? How about dev.cpu? >> dev.cpu.0 does exist. >=20 > It could be helpful to show all of: >=20 > % sysctl dev.cpu > % sysctl dev.est # if you have that? > % sysctl -a | grep freq | grep -v time >=20 > both before and after re-enabling p4tcc. Hello, With #hint.p4tcc.0.disabled=3D"1" commented out: % sysctl dev.cpu dev.cpu.%parent:=20 dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=3D\_PR_.P001 dev.cpu.0.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.0.%parent: acpi0 dev.cpu.0.coretemp.delta: 67 dev.cpu.0.coretemp.resolution: 1 dev.cpu.0.coretemp.tjmax: 95.0C dev.cpu.0.coretemp.throttle_log: 0 dev.cpu.0.temperature: 28.0C dev.cpu.0.freq: 2400 dev.cpu.0.freq_levels: 2400/-1 2100/-1 1800/-1 1500/-1 1200/-1 900/-1 = 600/-1 300/-1 dev.cpu.0.cx_supported: C1/1/32 C2/3/96 C3/3/128 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 261us dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=3D\_PR_.P002 dev.cpu.1.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.1.%parent: acpi0 dev.cpu.1.coretemp.delta: 67 dev.cpu.1.coretemp.resolution: 1 dev.cpu.1.coretemp.tjmax: 95.0C dev.cpu.1.coretemp.throttle_log: 0 dev.cpu.1.temperature: 28.0C dev.cpu.1.cx_supported: C1/1/32 C2/3/96 C3/3/128 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% 0.00% 0.00% last 71201us dev.cpu.2.%desc: ACPI CPU dev.cpu.2.%driver: cpu dev.cpu.2.%location: handle=3D\_PR_.P003 dev.cpu.2.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.2.%parent: acpi0 dev.cpu.2.coretemp.delta: 62 dev.cpu.2.coretemp.resolution: 1 dev.cpu.2.coretemp.tjmax: 95.0C dev.cpu.2.coretemp.throttle_log: 0 dev.cpu.2.temperature: 33.0C dev.cpu.2.cx_supported: C1/1/32 C2/3/96 C3/3/128 dev.cpu.2.cx_lowest: C1 dev.cpu.2.cx_usage: 100.00% 0.00% 0.00% last 124614us dev.cpu.3.%desc: ACPI CPU dev.cpu.3.%driver: cpu dev.cpu.3.%location: handle=3D\_PR_.P004 dev.cpu.3.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.3.%parent: acpi0 dev.cpu.3.coretemp.delta: 62 dev.cpu.3.coretemp.resolution: 1 dev.cpu.3.coretemp.tjmax: 95.0C dev.cpu.3.coretemp.throttle_log: 0 dev.cpu.3.temperature: 33.0C dev.cpu.3.cx_supported: C1/1/32 C2/3/96 C3/3/128 dev.cpu.3.cx_lowest: C1 dev.cpu.3.cx_usage: 100.00% 0.00% 0.00% last 101864us dev.cpu.4.%desc: ACPI CPU dev.cpu.4.%driver: cpu dev.cpu.4.%location: handle=3D\_PR_.P005 dev.cpu.4.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.4.%parent: acpi0 dev.cpu.4.coretemp.delta: 62 dev.cpu.4.coretemp.resolution: 1 dev.cpu.4.coretemp.tjmax: 95.0C dev.cpu.4.coretemp.throttle_log: 0 dev.cpu.4.temperature: 33.0C dev.cpu.4.cx_supported: C1/1/32 C2/3/96 C3/3/128 dev.cpu.4.cx_lowest: C1 dev.cpu.4.cx_usage: 100.00% 0.00% 0.00% last 127376us dev.cpu.5.%desc: ACPI CPU dev.cpu.5.%driver: cpu dev.cpu.5.%location: handle=3D\_PR_.P006 dev.cpu.5.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.5.%parent: acpi0 dev.cpu.5.coretemp.delta: 62 dev.cpu.5.coretemp.resolution: 1 dev.cpu.5.coretemp.tjmax: 95.0C dev.cpu.5.coretemp.throttle_log: 0 dev.cpu.5.temperature: 33.0C dev.cpu.5.cx_supported: C1/1/32 C2/3/96 C3/3/128 dev.cpu.5.cx_lowest: C1 dev.cpu.5.cx_usage: 100.00% 0.00% 0.00% last 107493us dev.cpu.6.%desc: ACPI CPU dev.cpu.6.%driver: cpu dev.cpu.6.%location: handle=3D\_PR_.P007 dev.cpu.6.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.6.%parent: acpi0 dev.cpu.6.coretemp.delta: 63 dev.cpu.6.coretemp.resolution: 1 dev.cpu.6.coretemp.tjmax: 95.0C dev.cpu.6.coretemp.throttle_log: 0 dev.cpu.6.temperature: 32.0C dev.cpu.6.cx_supported: C1/1/32 C2/3/96 C3/3/128 dev.cpu.6.cx_lowest: C1 dev.cpu.6.cx_usage: 100.00% 0.00% 0.00% last 155573us dev.cpu.7.%desc: ACPI CPU dev.cpu.7.%driver: cpu dev.cpu.7.%location: handle=3D\_PR_.P008 dev.cpu.7.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.7.%parent: acpi0 dev.cpu.7.coretemp.delta: 63 dev.cpu.7.coretemp.resolution: 1 dev.cpu.7.coretemp.tjmax: 95.0C dev.cpu.7.coretemp.throttle_log: 0 dev.cpu.7.temperature: 32.0C dev.cpu.7.cx_supported: C1/1/32 C2/3/96 C3/3/128 dev.cpu.7.cx_lowest: C1 dev.cpu.7.cx_usage: 100.00% 0.00% 0.00% last 32278us dev.cpu.8.%desc: ACPI CPU dev.cpu.8.%driver: cpu dev.cpu.8.%location: handle=3D\_PR_.P009 dev.cpu.8.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.8.%parent: acpi0 dev.cpu.8.coretemp.delta: 72 dev.cpu.8.coretemp.resolution: 1 dev.cpu.8.coretemp.tjmax: 95.0C dev.cpu.8.coretemp.throttle_log: 0 dev.cpu.8.temperature: 23.0C dev.cpu.8.cx_supported: C1/1/32 C2/3/96 C3/3/128 dev.cpu.8.cx_lowest: C1 dev.cpu.8.cx_usage: 100.00% 0.00% 0.00% last 163115us dev.cpu.9.%desc: ACPI CPU dev.cpu.9.%driver: cpu dev.cpu.9.%location: handle=3D\_PR_.P010 dev.cpu.9.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.9.%parent: acpi0 dev.cpu.9.coretemp.delta: 72 dev.cpu.9.coretemp.resolution: 1 dev.cpu.9.coretemp.tjmax: 95.0C dev.cpu.9.coretemp.throttle_log: 0 dev.cpu.9.temperature: 23.0C dev.cpu.9.cx_supported: C1/1/32 C2/3/96 C3/3/128 dev.cpu.9.cx_lowest: C1 dev.cpu.9.cx_usage: 100.00% 0.00% 0.00% last 168834us dev.cpu.10.%desc: ACPI CPU dev.cpu.10.%driver: cpu dev.cpu.10.%location: handle=3D\_PR_.P011 dev.cpu.10.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.10.%parent: acpi0 dev.cpu.10.coretemp.delta: 64 dev.cpu.10.coretemp.resolution: 1 dev.cpu.10.coretemp.tjmax: 95.0C dev.cpu.10.coretemp.throttle_log: 0 dev.cpu.10.temperature: 31.0C dev.cpu.10.cx_supported: C1/1/32 C2/3/96 C3/3/128 dev.cpu.10.cx_lowest: C1 dev.cpu.10.cx_usage: 100.00% 0.00% 0.00% last 141245us dev.cpu.11.%desc: ACPI CPU dev.cpu.11.%driver: cpu dev.cpu.11.%location: handle=3D\_PR_.P012 dev.cpu.11.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.11.%parent: acpi0 dev.cpu.11.coretemp.delta: 64 dev.cpu.11.coretemp.resolution: 1 dev.cpu.11.coretemp.tjmax: 95.0C dev.cpu.11.coretemp.throttle_log: 0 dev.cpu.11.temperature: 31.0C dev.cpu.11.cx_supported: C1/1/32 C2/3/96 C3/3/128 dev.cpu.11.cx_lowest: C1 dev.cpu.11.cx_usage: 100.00% 0.00% 0.00% last 133706us dev.cpu.12.%desc: ACPI CPU dev.cpu.12.%driver: cpu dev.cpu.12.%location: handle=3D\_PR_.P013 dev.cpu.12.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.12.%parent: acpi0 dev.cpu.12.coretemp.delta: 69 dev.cpu.12.coretemp.resolution: 1 dev.cpu.12.coretemp.tjmax: 95.0C dev.cpu.12.coretemp.throttle_log: 0 dev.cpu.12.temperature: 25.0C dev.cpu.12.cx_supported: C1/1/32 C2/3/96 C3/3/128 dev.cpu.12.cx_lowest: C1 dev.cpu.12.cx_usage: 100.00% 0.00% 0.00% last 112608us dev.cpu.13.%desc: ACPI CPU dev.cpu.13.%driver: cpu dev.cpu.13.%location: handle=3D\_PR_.P014 dev.cpu.13.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.13.%parent: acpi0 dev.cpu.13.coretemp.delta: 70 dev.cpu.13.coretemp.resolution: 1 dev.cpu.13.coretemp.tjmax: 95.0C dev.cpu.13.coretemp.throttle_log: 0 dev.cpu.13.temperature: 25.0C dev.cpu.13.cx_supported: C1/1/32 C2/3/96 C3/3/128 dev.cpu.13.cx_lowest: C1 dev.cpu.13.cx_usage: 100.00% 0.00% 0.00% last 58467us dev.cpu.14.%desc: ACPI CPU dev.cpu.14.%driver: cpu dev.cpu.14.%location: handle=3D\_PR_.P015 dev.cpu.14.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.14.%parent: acpi0 dev.cpu.14.coretemp.delta: 67 dev.cpu.14.coretemp.resolution: 1 dev.cpu.14.coretemp.tjmax: 95.0C dev.cpu.14.coretemp.throttle_log: 0 dev.cpu.14.temperature: 28.0C dev.cpu.14.cx_supported: C1/1/32 C2/3/96 C3/3/128 dev.cpu.14.cx_lowest: C1 dev.cpu.14.cx_usage: 100.00% 0.00% 0.00% last 41275us dev.cpu.15.%desc: ACPI CPU dev.cpu.15.%driver: cpu dev.cpu.15.%location: handle=3D\_PR_.P016 dev.cpu.15.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.15.%parent: acpi0 dev.cpu.15.coretemp.delta: 67 dev.cpu.15.coretemp.resolution: 1 dev.cpu.15.coretemp.tjmax: 95.0C dev.cpu.15.coretemp.throttle_log: 0 dev.cpu.15.temperature: 28.0C dev.cpu.15.cx_supported: C1/1/32 C2/3/96 C3/3/128 dev.cpu.15.cx_lowest: C1 dev.cpu.15.cx_usage: 100.00% 0.00% 0.00% last 249us % sysctl dev.est dev.est.%parent:=20 % sysctl -a | grep freq | grep -v time kern.acct_chkfreq: 15 device cpufreq net.inet.sctp.sack_freq: 2 debug.cpufreq.lowest: 0 debug.cpufreq.verbose: 0 machdep.i8254_freq: 1193182 machdep.tsc_freq: 2400132656 dev.cpu.0.freq: 2400 dev.cpu.0.freq_levels: 2400/-1 2100/-1 1800/-1 1500/-1 1200/-1 900/-1 = 600/-1 300/-1 dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 = 3750/-1 2500/-1 1250/-1 dev.p4tcc.1.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 = 3750/-1 2500/-1 1250/-1 dev.p4tcc.2.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 = 3750/-1 2500/-1 1250/-1 dev.p4tcc.3.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 = 3750/-1 2500/-1 1250/-1 dev.p4tcc.4.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 = 3750/-1 2500/-1 1250/-1 dev.p4tcc.5.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 = 3750/-1 2500/-1 1250/-1 dev.p4tcc.6.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 = 3750/-1 2500/-1 1250/-1 dev.p4tcc.7.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 = 3750/-1 2500/-1 1250/-1 dev.p4tcc.8.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 = 3750/-1 2500/-1 1250/-1 dev.p4tcc.9.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 = 3750/-1 2500/-1 1250/-1 dev.p4tcc.10.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 = 3750/-1 2500/-1 1250/-1 dev.p4tcc.11.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 = 3750/-1 2500/-1 1250/-1 dev.p4tcc.12.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 = 3750/-1 2500/-1 1250/-1 dev.p4tcc.13.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 = 3750/-1 2500/-1 1250/-1 dev.p4tcc.14.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 = 3750/-1 2500/-1 1250/-1 dev.p4tcc.15.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 = 3750/-1 2500/-1 1250/-1 dev.cpufreq.%parent:=20 dev.cpufreq.0.%desc:=20 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%location:=20 dev.cpufreq.0.%pnpinfo:=20 dev.cpufreq.0.%parent: cpu0 dev.cpufreq.1.%desc:=20 dev.cpufreq.1.%driver: cpufreq dev.cpufreq.1.%location:=20 dev.cpufreq.1.%pnpinfo:=20 dev.cpufreq.1.%parent: cpu1 dev.cpufreq.2.%desc:=20 dev.cpufreq.2.%driver: cpufreq dev.cpufreq.2.%location:=20 dev.cpufreq.2.%pnpinfo:=20 dev.cpufreq.2.%parent: cpu2 dev.cpufreq.3.%desc:=20 dev.cpufreq.3.%driver: cpufreq dev.cpufreq.3.%location:=20 dev.cpufreq.3.%pnpinfo:=20 dev.cpufreq.3.%parent: cpu3 dev.cpufreq.4.%desc:=20 dev.cpufreq.4.%driver: cpufreq dev.cpufreq.4.%location:=20 dev.cpufreq.4.%pnpinfo:=20 dev.cpufreq.4.%parent: cpu4 dev.cpufreq.5.%desc:=20 dev.cpufreq.5.%driver: cpufreq dev.cpufreq.5.%location:=20 dev.cpufreq.5.%pnpinfo:=20 dev.cpufreq.5.%parent: cpu5 dev.cpufreq.6.%desc:=20 dev.cpufreq.6.%driver: cpufreq dev.cpufreq.6.%location:=20 dev.cpufreq.6.%pnpinfo:=20 dev.cpufreq.6.%parent: cpu6 dev.cpufreq.7.%desc:=20 dev.cpufreq.7.%driver: cpufreq dev.cpufreq.7.%location:=20 dev.cpufreq.7.%pnpinfo:=20 dev.cpufreq.7.%parent: cpu7 dev.cpufreq.8.%desc:=20 dev.cpufreq.8.%driver: cpufreq dev.cpufreq.8.%location:=20 dev.cpufreq.8.%pnpinfo:=20 dev.cpufreq.8.%parent: cpu8 dev.cpufreq.9.%desc:=20 dev.cpufreq.9.%driver: cpufreq dev.cpufreq.9.%location:=20 dev.cpufreq.9.%pnpinfo:=20 dev.cpufreq.9.%parent: cpu9 dev.cpufreq.10.%desc:=20 dev.cpufreq.10.%driver: cpufreq dev.cpufreq.10.%location:=20 dev.cpufreq.10.%pnpinfo:=20 dev.cpufreq.10.%parent: cpu10 dev.cpufreq.11.%desc:=20 dev.cpufreq.11.%driver: cpufreq dev.cpufreq.11.%location:=20 dev.cpufreq.11.%pnpinfo:=20 dev.cpufreq.11.%parent: cpu11 dev.cpufreq.12.%desc:=20 dev.cpufreq.12.%driver: cpufreq dev.cpufreq.12.%location:=20 dev.cpufreq.12.%pnpinfo:=20 dev.cpufreq.12.%parent: cpu12 dev.cpufreq.13.%desc:=20 dev.cpufreq.13.%driver: cpufreq dev.cpufreq.13.%location:=20 dev.cpufreq.13.%pnpinfo:=20 dev.cpufreq.13.%parent: cpu13 dev.cpufreq.14.%desc:=20 dev.cpufreq.14.%driver: cpufreq dev.cpufreq.14.%location:=20 dev.cpufreq.14.%pnpinfo:=20 dev.cpufreq.14.%parent: cpu14 dev.cpufreq.15.%desc:=20 dev.cpufreq.15.%driver: cpufreq dev.cpufreq.15.%location:=20 dev.cpufreq.15.%pnpinfo:=20 dev.cpufreq.15.%parent: cpu15 With hint.p4tcc.0.disabled=3D"1" active (default in 10=3DSTABLE now): % sysctl dev.cpu dev.cpu.%parent:=20 dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=3D\_PR_.P001 dev.cpu.0.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.0.%parent: acpi0 dev.cpu.0.coretemp.delta: 66 dev.cpu.0.coretemp.resolution: 1 dev.cpu.0.coretemp.tjmax: 95.0C dev.cpu.0.coretemp.throttle_log: 0 dev.cpu.0.temperature: 29.0C dev.cpu.0.cx_supported: C1/1/32 C2/3/96 C3/3/128 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 428us dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=3D\_PR_.P002 dev.cpu.1.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.1.%parent: acpi0 dev.cpu.1.coretemp.delta: 66 dev.cpu.1.coretemp.resolution: 1 dev.cpu.1.coretemp.tjmax: 95.0C dev.cpu.1.coretemp.throttle_log: 0 dev.cpu.1.temperature: 29.0C dev.cpu.1.cx_supported: C1/1/32 C2/3/96 C3/3/128 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% 0.00% 0.00% last 223406us dev.cpu.2.%desc: ACPI CPU dev.cpu.2.%driver: cpu dev.cpu.2.%location: handle=3D\_PR_.P003 dev.cpu.2.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.2.%parent: acpi0 dev.cpu.2.coretemp.delta: 63 dev.cpu.2.coretemp.resolution: 1 dev.cpu.2.coretemp.tjmax: 95.0C dev.cpu.2.coretemp.throttle_log: 0 dev.cpu.2.temperature: 32.0C dev.cpu.2.cx_supported: C1/1/32 C2/3/96 C3/3/128 dev.cpu.2.cx_lowest: C1 dev.cpu.2.cx_usage: 100.00% 0.00% 0.00% last 179299us dev.cpu.3.%desc: ACPI CPU dev.cpu.3.%driver: cpu dev.cpu.3.%location: handle=3D\_PR_.P004 dev.cpu.3.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.3.%parent: acpi0 dev.cpu.3.coretemp.delta: 63 dev.cpu.3.coretemp.resolution: 1 dev.cpu.3.coretemp.tjmax: 95.0C dev.cpu.3.coretemp.throttle_log: 0 dev.cpu.3.temperature: 33.0C dev.cpu.3.cx_supported: C1/1/32 C2/3/96 C3/3/128 dev.cpu.3.cx_lowest: C1 dev.cpu.3.cx_usage: 100.00% 0.00% 0.00% last 108280us dev.cpu.4.%desc: ACPI CPU dev.cpu.4.%driver: cpu dev.cpu.4.%location: handle=3D\_PR_.P005 dev.cpu.4.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.4.%parent: acpi0 dev.cpu.4.coretemp.delta: 62 dev.cpu.4.coretemp.resolution: 1 dev.cpu.4.coretemp.tjmax: 95.0C dev.cpu.4.coretemp.throttle_log: 0 dev.cpu.4.temperature: 33.0C dev.cpu.4.cx_supported: C1/1/32 C2/3/96 C3/3/128 dev.cpu.4.cx_lowest: C1 dev.cpu.4.cx_usage: 100.00% 0.00% 0.00% last 120264us dev.cpu.5.%desc: ACPI CPU dev.cpu.5.%driver: cpu dev.cpu.5.%location: handle=3D\_PR_.P006 dev.cpu.5.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.5.%parent: acpi0 dev.cpu.5.coretemp.delta: 62 dev.cpu.5.coretemp.resolution: 1 dev.cpu.5.coretemp.tjmax: 95.0C dev.cpu.5.coretemp.throttle_log: 0 dev.cpu.5.temperature: 33.0C dev.cpu.5.cx_supported: C1/1/32 C2/3/96 C3/3/128 dev.cpu.5.cx_lowest: C1 dev.cpu.5.cx_usage: 100.00% 0.00% 0.00% last 53853us dev.cpu.6.%desc: ACPI CPU dev.cpu.6.%driver: cpu dev.cpu.6.%location: handle=3D\_PR_.P007 dev.cpu.6.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.6.%parent: acpi0 dev.cpu.6.coretemp.delta: 64 dev.cpu.6.coretemp.resolution: 1 dev.cpu.6.coretemp.tjmax: 95.0C dev.cpu.6.coretemp.throttle_log: 0 dev.cpu.6.temperature: 31.0C dev.cpu.6.cx_supported: C1/1/32 C2/3/96 C3/3/128 dev.cpu.6.cx_lowest: C1 dev.cpu.6.cx_usage: 100.00% 0.00% 0.00% last 126291us dev.cpu.7.%desc: ACPI CPU dev.cpu.7.%driver: cpu dev.cpu.7.%location: handle=3D\_PR_.P008 dev.cpu.7.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.7.%parent: acpi0 dev.cpu.7.coretemp.delta: 64 dev.cpu.7.coretemp.resolution: 1 dev.cpu.7.coretemp.tjmax: 95.0C dev.cpu.7.coretemp.throttle_log: 0 dev.cpu.7.temperature: 31.0C dev.cpu.7.cx_supported: C1/1/32 C2/3/96 C3/3/128 dev.cpu.7.cx_lowest: C1 dev.cpu.7.cx_usage: 100.00% 0.00% 0.00% last 39246us dev.cpu.8.%desc: ACPI CPU dev.cpu.8.%driver: cpu dev.cpu.8.%location: handle=3D\_PR_.P009 dev.cpu.8.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.8.%parent: acpi0 dev.cpu.8.coretemp.delta: 73 dev.cpu.8.coretemp.resolution: 1 dev.cpu.8.coretemp.tjmax: 95.0C dev.cpu.8.coretemp.throttle_log: 0 dev.cpu.8.temperature: 22.0C dev.cpu.8.cx_supported: C1/1/32 C2/3/96 C3/3/128 dev.cpu.8.cx_lowest: C1 dev.cpu.8.cx_usage: 100.00% 0.00% 0.00% last 237500us dev.cpu.9.%desc: ACPI CPU dev.cpu.9.%driver: cpu dev.cpu.9.%location: handle=3D\_PR_.P010 dev.cpu.9.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.9.%parent: acpi0 dev.cpu.9.coretemp.delta: 73 dev.cpu.9.coretemp.resolution: 1 dev.cpu.9.coretemp.tjmax: 95.0C dev.cpu.9.coretemp.throttle_log: 0 dev.cpu.9.temperature: 22.0C dev.cpu.9.cx_supported: C1/1/32 C2/3/96 C3/3/128 dev.cpu.9.cx_lowest: C1 dev.cpu.9.cx_usage: 100.00% 0.00% 0.00% last 48599us dev.cpu.10.%desc: ACPI CPU dev.cpu.10.%driver: cpu dev.cpu.10.%location: handle=3D\_PR_.P011 dev.cpu.10.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.10.%parent: acpi0 dev.cpu.10.coretemp.delta: 64 dev.cpu.10.coretemp.resolution: 1 dev.cpu.10.coretemp.tjmax: 95.0C dev.cpu.10.coretemp.throttle_log: 0 dev.cpu.10.temperature: 31.0C dev.cpu.10.cx_supported: C1/1/32 C2/3/96 C3/3/128 dev.cpu.10.cx_lowest: C1 dev.cpu.10.cx_usage: 100.00% 0.00% 0.00% last 276265us dev.cpu.11.%desc: ACPI CPU dev.cpu.11.%driver: cpu dev.cpu.11.%location: handle=3D\_PR_.P012 dev.cpu.11.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.11.%parent: acpi0 dev.cpu.11.coretemp.delta: 64 dev.cpu.11.coretemp.resolution: 1 dev.cpu.11.coretemp.tjmax: 95.0C dev.cpu.11.coretemp.throttle_log: 0 dev.cpu.11.temperature: 31.0C dev.cpu.11.cx_supported: C1/1/32 C2/3/96 C3/3/128 dev.cpu.11.cx_lowest: C1 dev.cpu.11.cx_usage: 100.00% 0.00% 0.00% last 45235us dev.cpu.12.%desc: ACPI CPU dev.cpu.12.%driver: cpu dev.cpu.12.%location: handle=3D\_PR_.P013 dev.cpu.12.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.12.%parent: acpi0 dev.cpu.12.coretemp.delta: 70 dev.cpu.12.coretemp.resolution: 1 dev.cpu.12.coretemp.tjmax: 95.0C dev.cpu.12.coretemp.throttle_log: 0 dev.cpu.12.temperature: 25.0C dev.cpu.12.cx_supported: C1/1/32 C2/3/96 C3/3/128 dev.cpu.12.cx_lowest: C1 dev.cpu.12.cx_usage: 100.00% 0.00% 0.00% last 176635us dev.cpu.13.%desc: ACPI CPU dev.cpu.13.%driver: cpu dev.cpu.13.%location: handle=3D\_PR_.P014 dev.cpu.13.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.13.%parent: acpi0 dev.cpu.13.coretemp.delta: 70 dev.cpu.13.coretemp.resolution: 1 dev.cpu.13.coretemp.tjmax: 95.0C dev.cpu.13.coretemp.throttle_log: 0 dev.cpu.13.temperature: 25.0C dev.cpu.13.cx_supported: C1/1/32 C2/3/96 C3/3/128 dev.cpu.13.cx_lowest: C1 dev.cpu.13.cx_usage: 100.00% 0.00% 0.00% last 86467us dev.cpu.14.%desc: ACPI CPU dev.cpu.14.%driver: cpu dev.cpu.14.%location: handle=3D\_PR_.P015 dev.cpu.14.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.14.%parent: acpi0 dev.cpu.14.coretemp.delta: 68 dev.cpu.14.coretemp.resolution: 1 dev.cpu.14.coretemp.tjmax: 95.0C dev.cpu.14.coretemp.throttle_log: 0 dev.cpu.14.temperature: 27.0C dev.cpu.14.cx_supported: C1/1/32 C2/3/96 C3/3/128 dev.cpu.14.cx_lowest: C1 dev.cpu.14.cx_usage: 100.00% 0.00% 0.00% last 151541us dev.cpu.15.%desc: ACPI CPU dev.cpu.15.%driver: cpu dev.cpu.15.%location: handle=3D\_PR_.P016 dev.cpu.15.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.15.%parent: acpi0 dev.cpu.15.coretemp.delta: 68 dev.cpu.15.coretemp.resolution: 1 dev.cpu.15.coretemp.tjmax: 95.0C dev.cpu.15.coretemp.throttle_log: 0 dev.cpu.15.temperature: 27.0C dev.cpu.15.cx_supported: C1/1/32 C2/3/96 C3/3/128 dev.cpu.15.cx_lowest: C1 dev.cpu.15.cx_usage: 100.00% 0.00% 0.00% last 7904us % sysctl dev.est dev.est.%parent:=20 % sysctl -a | grep freq | grep -v time kern.acct_chkfreq: 15 device cpufreq net.inet.sctp.sack_freq: 2 debug.cpufreq.lowest: 0 debug.cpufreq.verbose: 0 machdep.i8254_freq: 1193182 machdep.tsc_freq: 2400136744 Also I have this in dmesg which may be relevant: p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 12 device_attach: est1 attach returned 6 for each CPU. The line starting with p4tcc apears only when I remove = hint.p4tcc.0.disabled=3D"1"=20 >=20 > Are you not running powerd? Of course powerd won't start if it can't > get dev.cpu.0.freq but you can ordinarily use it to set lowest and/or > highest freqs. Once FreeBSD starts, BIOS settings should have little > do with it, AFAIK, except how they might set freq before powerd = starts. No, I don't use powerd. I want my processor to always run at max speed. But I encountered situations when sometime system is running at 1200GHz = instead of 2400 and it is fixed with BIOS updates. That is why I check dev.cpu.0.freq each time system reboot. My processor is Intel E5620 : = http://ark.intel.com/products/47925/Intel-Xeon-Processor-E5620-12M-Cache-2= _40-GHz-5_86-GTs-Intel-QPI It is not so ancient thing.= From owner-freebsd-stable@FreeBSD.ORG Sun Mar 22 21:41:31 2015 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F3A8B951 for ; Sun, 22 Mar 2015 21:41:30 +0000 (UTC) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (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 AD7C6AE4 for ; Sun, 22 Mar 2015 21:41:30 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 39DB72842D for ; Sun, 22 Mar 2015 22:41:26 +0100 (CET) Received: from illbsd.quip.test (ip-89-177-50-74.net.upcbroadband.cz [89.177.50.74]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 5EAB128422 for ; Sun, 22 Mar 2015 22:41:25 +0100 (CET) Message-ID: <550F3729.5020208@quip.cz> Date: Sun, 22 Mar 2015 22:42:01 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32 MIME-Version: 1.0 To: freebsd-stable Stable Subject: Re: rctl logs swapuse even if swap is empty References: <550CBCE3.6040908@quip.cz> In-Reply-To: <550CBCE3.6040908@quip.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 21:41:31 -0000 Miroslav Lachman wrote on 03/21/2015 01:35: > I tried RCTL for the first time, so maybe it is error on my side. [...] > Both jails are small webservers with PHP + Apache. They do not use much > memory and they really do not user any swap space. (according to top and > swapinfo) > > > # swapinfo -h > Device 1K-blocks Used Avail Capacity > /dev/mirror/gm0s1b 16777216 0B 16G 0% > > > # rctl -hu jail:fox | grep swap > swapuse=0 > > > Processes in both jails are logged as using more than 32MB of swap: > > Mar 21 01:18:55 neon kernel: rctl: rule "jail:fox:swapuse:log=33554432" > matched by pid 20783 (httpd), uid 80, jail fox > Mar 21 01:18:55 neon kernel: rctl: rule "jail:fox:swapuse:log=33554432" > matched by pid 20787 (httpd), uid 80, jail fox > Mar 21 01:18:58 neon kernel: rctl: rule "jail:fox:swapuse:log=33554432" > matched by pid 19207 (httpd), uid 80, jail fox > Mar 21 01:18:58 neon kernel: rctl: rule "jail:fox:swapuse:log=33554432" > matched by pid 20790 (sh), uid 0, jail fox > Mar 21 01:18:58 neon kernel: rctl: rule "jail:fox:swapuse:log=33554432" > matched by pid 20792 (sh), uid 0, jail fox > Mar 21 01:18:58 neon kernel: rctl: rule > "jail:olymp:swapuse:log=33554432" matched by pid 20793 (sh), uid 0, jail > olymp > Mar 21 01:18:58 neon kernel: rctl: rule > "jail:olymp:swapuse:log=33554432" matched by pid 20795 (sh), uid 0, jail > olymp > > Is it expected? I do not think so. > Or am I doing something wrong with rctl? This is really strange. FOP (Java application) in jail is failing unless rctl swapuse is set to 7GB or more. Does swapuse means anything completely different than what is swapinfo or top reporting? The same web services with FOP is running completely fine on real server with 2GB of physical RAM installed and less than 5GB of swap partition (swap is empty). But it is not working in jail if RCTL is set to swapuse:deny=4GB or memoryuse:deny=4GB. Can somebody explain it? Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Sun Mar 22 23:22:49 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 16A9741C; Sun, 22 Mar 2015 23:22:49 +0000 (UTC) Received: from roadkill.tharned.org (roadkill.tharned.org [75.145.12.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 AE443759; Sun, 22 Mar 2015 23:22:48 +0000 (UTC) Received: from angus.tharned.org (angus.tharned.org [10.10.10.7]) (authenticated bits=0) by roadkill.tharned.org (8.14.9/8.14.9) with ESMTP id t2MN5Z1F053137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 22 Mar 2015 18:05:40 -0500 (CDT) (envelope-from gcr+freebsd-stable@tharned.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tharned.org; s=2014; t=1427065541; bh=iXAja5i24Kugy0yzbtL+RSeRgcua4ioidJyG8wEbOwI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ixXnJVmhaOqW7GZzLIQ7kgPZ7iTp5b+YINI3FcY+UIubsyoCG0W+dg3/knCkGtgZD 92fQht3WY4ORL6kJa+jGU9kHmPr+QlnUw8unmXMDoJwPmFuGS9EDJLpVG7E4Tt3VGQ 9T1bBK3+JLRXB8Kyuye+AJ2r0NebNyxiYNHeiEXGlFIvzgBICoCz+7Vf8H6Tau7nuC SX3gpOLCPE8CgJT5rHvMFFJvIcOyLtrBIi0H6f+EOFAVr1u4Po8dIxIWrT1SA4q6ju U1d3RqRTx2Oty8mqIEigPPdRLW25Rfsp/JZD/INhoXJ5H9d3V5+hvSsoDul5TvSC/6 IA3sgqyKoSl2w== Date: Sun, 22 Mar 2015 18:05:35 -0500 (CDT) From: Greg Rivers To: John Baldwin Subject: Re: HP EliteBook EFI boot failure In-Reply-To: <4578914.pupgQQ80ch@ralph.baldwin.cx> Message-ID: References: <4578914.pupgQQ80ch@ralph.baldwin.cx> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (roadkill.tharned.org [75.145.12.185]); Sun, 22 Mar 2015 18:05:41 -0500 (CDT) Cc: freebsd-stable@freebsd.org, Oliver Pinter X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 23:22:49 -0000 On Mon, 16 Mar 2015, John Baldwin wrote: > I am curious if the redzone fix I committed to the EFI loader last week > might help. It was noticed because gzipped kernels were corrupted when > loaded from disk, but it might generate other random corruption even in > the non-gzip case. I think the chance that it helps is low, but it > isn't quite zero. > Snapshot FreeBSD-11.0-CURRENT-amd64-20150316-r280130-memstick.img.xz fails to boot the same way. I assume that has your redzone fix? Is there a debugging version of the loader that might shed more light on the problem? -- Greg From owner-freebsd-stable@FreeBSD.ORG Sun Mar 22 23:47:50 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34B3DC7D for ; Sun, 22 Mar 2015 23:47:50 +0000 (UTC) Received: from mail-yh0-f42.google.com (mail-yh0-f42.google.com [209.85.213.42]) (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 E8C7F972 for ; Sun, 22 Mar 2015 23:47:49 +0000 (UTC) Received: by yhjf44 with SMTP id f44so61346119yhj.3 for ; Sun, 22 Mar 2015 16:47:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yhrxS1vk0Gu0qP7FEwpjaYLpv6lTQy3n1vU30JvDR7g=; b=YdUtXWLcVLmygjP+C57NsIRcQuebF2MJrTwXMPpsiLz3xNVm9+SR2GenvFXrltjFqU ZNFL6qdeG3gbGEr9aeOzzwf93fI6Vh9cyxy9cNXSJalqUNQWNsH7BtN59THeV8KtEA6g x0wIVY0c07FBVnQrqfoixsBv/DQc7HLVBHNDrHWLSKSZe5nEIvUBBo7JQvw42XgaAWr1 /SS7ExQslkkB1K30hq7nE2zxBnyylXYjOLrJbgEn1khuef26TkzBgFx0x10eo10z4ObY WZKZ3zBpYH+jCO3JhtxWivHIRo4Vq1nOYoYzjEf01R8y9XSNMH6NYAHeM8+A/gNlQaLz hfGg== X-Gm-Message-State: ALoCoQlqnLA/wsRh2g9kJK8nMBHpR6EnZBuo66BRsmFhNcB6HqvvxnipB51ekuQYUM/my5wvd4Md MIME-Version: 1.0 X-Received: by 10.236.31.33 with SMTP id l21mr92546477yha.181.1427067626367; Sun, 22 Mar 2015 16:40:26 -0700 (PDT) Received: by 10.170.104.86 with HTTP; Sun, 22 Mar 2015 16:40:26 -0700 (PDT) In-Reply-To: References: <4578914.pupgQQ80ch@ralph.baldwin.cx> Date: Mon, 23 Mar 2015 00:40:26 +0100 Message-ID: Subject: Re: HP EliteBook EFI boot failure From: Oliver Pinter To: Greg Rivers Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-stable@freebsd.org" , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 23:47:50 -0000 On Mon, Mar 23, 2015 at 12:05 AM, Greg Rivers wrote: > On Mon, 16 Mar 2015, John Baldwin wrote: > >> I am curious if the redzone fix I committed to the EFI loader last week >> might help. It was noticed because gzipped kernels were corrupted when >> loaded from disk, but it might generate other random corruption even in the >> non-gzip case. I think the chance that it helps is low, but it isn't quite >> zero. >> > Snapshot FreeBSD-11.0-CURRENT-amd64-20150316-r280130-memstick.img.xz fails > to boot the same way. I assume that has your redzone fix? Is there a > debugging version of the loader that might shed more light on the problem? > Try to overwrite the loader from FreeBSD 9.3's memstick image. In my case this works. Other possible solution is to try to compile the loader with GCC - I not tested this case, but I think it could work. > -- > Greg From owner-freebsd-stable@FreeBSD.ORG Mon Mar 23 01:06:48 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9154C45 for ; Mon, 23 Mar 2015 01:06:48 +0000 (UTC) Received: from mtaout23.012.net.il (mtaout23.012.net.il [80.179.55.175]) by mx1.freebsd.org (Postfix) with ESMTP id 67D19C6 for ; Mon, 23 Mar 2015 01:06:48 +0000 (UTC) Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NLN00G003UJ5B00@a-mtaout23.012.net.il> for freebsd-stable@freebsd.org; Mon, 23 Mar 2015 03:01:40 +0200 (IST) Received: from 87.68.244.32.adsl.012.net.il ([87.68.244.32]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPSA id <0NLN00GER46P4220@a-mtaout23.012.net.il> for freebsd-stable@freebsd.org; Mon, 23 Mar 2015 03:01:40 +0200 (IST) Date: Mon, 23 Mar 2015 03:01:49 +0200 From: Rotem Hecht Subject: Music composer for film, games and Tv commercials X-012-Sender: rot185@012.net.il To: freebsd-stable Reply-to: "contact@rotemmusic.com" Message-id: <0NLN00GEY46R4220@a-mtaout23.012.net.il> Organization: Rotem Hecht MIME-version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 01:06:48 -0000 Hi=20 =20 I hope you well =20 I am Rotem Hecht. I work as a professional music composer and sound d= esigner, I'm based in Israel and in Los Angeles, California and working with production companies all over the world. I compose original music for movies, television commercials, video gam= es, events, corporate videos and I am open to other media scenarios. My portfolio includes projects performed for Microsoft, Hershey's, Kre= -O, Hasbro, Mercedes, Audi, Nickelodeon, Hop! TV Channel and more =20 I=E2=80=99m capable of delivering high quality products at decent rate= s and in short period of time. I would like to offer you my services. Please check my portfolio on my= website www.rotemmusic.com =20 Thank You for your time. =20 Best Regards , =20 Rotem Hecht Mob:+972-528-227726 rotemhecht@gmail.com Skype: rhecht1282=20 =20 Unsubscribe From owner-freebsd-stable@FreeBSD.ORG Mon Mar 23 05:25:37 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 158E3C1B; Mon, 23 Mar 2015 05:25:37 +0000 (UTC) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CE7E2DEB; Mon, 23 Mar 2015 05:25:36 +0000 (UTC) Received: by iedfl3 with SMTP id fl3so32674319ied.1; Sun, 22 Mar 2015 22:25:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=OAYdy5bZ33zn1GTgp6J+/msqgastkkCkvjyt4ACczZE=; b=qky5wRtS45Q/9PN3ghqvpvwX3WxMakHX+nkS1go0T1ApINQ79xnv0RqhCz7KhsuTmi D3qT2VUBD7rl2VSFEXQ/gzIiMsBbHvWjfDO7B+vsKTjbREa3bVHOf0cO8DmqBeKZ0m6s 2Yl3ZgweCm1tqcxtlzT+ehr6VpAkx+sNuC8RjMlAvZC/y0X6jvh96UGPH0jBcP1g8738 e0C0WXP5PqHctWy1hJRI9zLRGzv5ZJFDEMqfN2DZvIhbuyvMxEDCA9z2fX3jpiw7CSlI DpkW8+FCy02Dq91xiKnDx7r9Aqa5dXJZzbtgoKVJYbWRTsHyZi6ygLiBbgep4nTF6Bjt Qs3A== MIME-Version: 1.0 X-Received: by 10.107.25.68 with SMTP id 65mr66280994ioz.44.1427088335367; Sun, 22 Mar 2015 22:25:35 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.107.174.86 with HTTP; Sun, 22 Mar 2015 22:25:35 -0700 (PDT) In-Reply-To: <97279AFB-7718-4080-9F18-155287216A04@gmail.com> References: <20150322055323.GA48710@server.rulingia.com> <77C8F6F7-2C25-4BC5-B373-11441AB58FAD@gmail.com> <550ECD9D.2030108@nimnet.asn.au> <97279AFB-7718-4080-9F18-155287216A04@gmail.com> Date: Sun, 22 Mar 2015 22:25:35 -0700 X-Google-Sender-Auth: BxQc-yVlriO4B2cMKiE51QeUZ5A Message-ID: Subject: Re: dev.cpu.0.freq disapeared From: Kevin Oberman To: Dmitry Sivachenko Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Stable ML , Peter Jeremy , Ian Smith , Nathan Whitehorn X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 05:25:37 -0000 On Sun, Mar 22, 2015 at 10:11 AM, Dmitry Sivachenko wrote: > > > On 22 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2015 =D0=B3., at 17:11, Ian Smith = wrote: > > > > Dmitry Sivachenko wrote: > >>> On 22 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2015 =D0=B3., at 8:53, Peter Jer= emy wrote: > >>> On 2015-Mar-22 00:58:55 +0300, Dmitry Sivachenko > wrote: > >>>> I have a machine with the following processor: > >>>> CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (2400.14-MHz > >>>> K8-class CPU) Origin=3D"GenuineIntel" Id=3D0x206c2 Family=3D0x6 > Model=3D0x2c Stepping=3D2 > >>> ... > >>>> After I upgraded to 10.1-STABLE #0 r279956, this sysctl disapeared. = % > sysctl dev.cpu.0.freq sysctl: unknown oid 'dev.cpu.0.freq': No such file = or > directory % > > > >>> What OIDs do you have? Does dev.cpu.0 exist? How about dev.cpu? > >> dev.cpu.0 does exist. > > > > It could be helpful to show all of: > > > > % sysctl dev.cpu > > % sysctl dev.est # if you have that? > > % sysctl -a | grep freq | grep -v time > > > > both before and after re-enabling p4tcc. > > Hello, > > With #hint.p4tcc.0.disabled=3D"1" commented out: > > % sysctl dev.cpu > dev.cpu.%parent: > dev.cpu.0.%desc: ACPI CPU > dev.cpu.0.%driver: cpu > dev.cpu.0.%location: handle=3D\_PR_.P001 > dev.cpu.0.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.0.%parent: acpi0 > dev.cpu.0.coretemp.delta: 67 > dev.cpu.0.coretemp.resolution: 1 > dev.cpu.0.coretemp.tjmax: 95.0C > dev.cpu.0.coretemp.throttle_log: 0 > dev.cpu.0.temperature: 28.0C > dev.cpu.0.freq: 2400 > dev.cpu.0.freq_levels: 2400/-1 2100/-1 1800/-1 1500/-1 1200/-1 900/-1 > 600/-1 300/-1 > dev.cpu.0.cx_supported: C1/1/32 C2/3/96 C3/3/128 > dev.cpu.0.cx_lowest: C1 > dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 261us > dev.cpu.1.%desc: ACPI CPU > dev.cpu.1.%driver: cpu > dev.cpu.1.%location: handle=3D\_PR_.P002 > dev.cpu.1.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.1.%parent: acpi0 > dev.cpu.1.coretemp.delta: 67 > dev.cpu.1.coretemp.resolution: 1 > dev.cpu.1.coretemp.tjmax: 95.0C > dev.cpu.1.coretemp.throttle_log: 0 > dev.cpu.1.temperature: 28.0C > dev.cpu.1.cx_supported: C1/1/32 C2/3/96 C3/3/128 > dev.cpu.1.cx_lowest: C1 > dev.cpu.1.cx_usage: 100.00% 0.00% 0.00% last 71201us > dev.cpu.2.%desc: ACPI CPU > dev.cpu.2.%driver: cpu > dev.cpu.2.%location: handle=3D\_PR_.P003 > dev.cpu.2.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.2.%parent: acpi0 > dev.cpu.2.coretemp.delta: 62 > dev.cpu.2.coretemp.resolution: 1 > dev.cpu.2.coretemp.tjmax: 95.0C > dev.cpu.2.coretemp.throttle_log: 0 > dev.cpu.2.temperature: 33.0C > dev.cpu.2.cx_supported: C1/1/32 C2/3/96 C3/3/128 > dev.cpu.2.cx_lowest: C1 > dev.cpu.2.cx_usage: 100.00% 0.00% 0.00% last 124614us > dev.cpu.3.%desc: ACPI CPU > dev.cpu.3.%driver: cpu > dev.cpu.3.%location: handle=3D\_PR_.P004 > dev.cpu.3.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.3.%parent: acpi0 > dev.cpu.3.coretemp.delta: 62 > dev.cpu.3.coretemp.resolution: 1 > dev.cpu.3.coretemp.tjmax: 95.0C > dev.cpu.3.coretemp.throttle_log: 0 > dev.cpu.3.temperature: 33.0C > dev.cpu.3.cx_supported: C1/1/32 C2/3/96 C3/3/128 > dev.cpu.3.cx_lowest: C1 > dev.cpu.3.cx_usage: 100.00% 0.00% 0.00% last 101864us > dev.cpu.4.%desc: ACPI CPU > dev.cpu.4.%driver: cpu > dev.cpu.4.%location: handle=3D\_PR_.P005 > dev.cpu.4.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.4.%parent: acpi0 > dev.cpu.4.coretemp.delta: 62 > dev.cpu.4.coretemp.resolution: 1 > dev.cpu.4.coretemp.tjmax: 95.0C > dev.cpu.4.coretemp.throttle_log: 0 > dev.cpu.4.temperature: 33.0C > dev.cpu.4.cx_supported: C1/1/32 C2/3/96 C3/3/128 > dev.cpu.4.cx_lowest: C1 > dev.cpu.4.cx_usage: 100.00% 0.00% 0.00% last 127376us > dev.cpu.5.%desc: ACPI CPU > dev.cpu.5.%driver: cpu > dev.cpu.5.%location: handle=3D\_PR_.P006 > dev.cpu.5.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.5.%parent: acpi0 > dev.cpu.5.coretemp.delta: 62 > dev.cpu.5.coretemp.resolution: 1 > dev.cpu.5.coretemp.tjmax: 95.0C > dev.cpu.5.coretemp.throttle_log: 0 > dev.cpu.5.temperature: 33.0C > dev.cpu.5.cx_supported: C1/1/32 C2/3/96 C3/3/128 > dev.cpu.5.cx_lowest: C1 > dev.cpu.5.cx_usage: 100.00% 0.00% 0.00% last 107493us > dev.cpu.6.%desc: ACPI CPU > dev.cpu.6.%driver: cpu > dev.cpu.6.%location: handle=3D\_PR_.P007 > dev.cpu.6.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.6.%parent: acpi0 > dev.cpu.6.coretemp.delta: 63 > dev.cpu.6.coretemp.resolution: 1 > dev.cpu.6.coretemp.tjmax: 95.0C > dev.cpu.6.coretemp.throttle_log: 0 > dev.cpu.6.temperature: 32.0C > dev.cpu.6.cx_supported: C1/1/32 C2/3/96 C3/3/128 > dev.cpu.6.cx_lowest: C1 > dev.cpu.6.cx_usage: 100.00% 0.00% 0.00% last 155573us > dev.cpu.7.%desc: ACPI CPU > dev.cpu.7.%driver: cpu > dev.cpu.7.%location: handle=3D\_PR_.P008 > dev.cpu.7.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.7.%parent: acpi0 > dev.cpu.7.coretemp.delta: 63 > dev.cpu.7.coretemp.resolution: 1 > dev.cpu.7.coretemp.tjmax: 95.0C > dev.cpu.7.coretemp.throttle_log: 0 > dev.cpu.7.temperature: 32.0C > dev.cpu.7.cx_supported: C1/1/32 C2/3/96 C3/3/128 > dev.cpu.7.cx_lowest: C1 > dev.cpu.7.cx_usage: 100.00% 0.00% 0.00% last 32278us > dev.cpu.8.%desc: ACPI CPU > dev.cpu.8.%driver: cpu > dev.cpu.8.%location: handle=3D\_PR_.P009 > dev.cpu.8.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.8.%parent: acpi0 > dev.cpu.8.coretemp.delta: 72 > dev.cpu.8.coretemp.resolution: 1 > dev.cpu.8.coretemp.tjmax: 95.0C > dev.cpu.8.coretemp.throttle_log: 0 > dev.cpu.8.temperature: 23.0C > dev.cpu.8.cx_supported: C1/1/32 C2/3/96 C3/3/128 > dev.cpu.8.cx_lowest: C1 > dev.cpu.8.cx_usage: 100.00% 0.00% 0.00% last 163115us > dev.cpu.9.%desc: ACPI CPU > dev.cpu.9.%driver: cpu > dev.cpu.9.%location: handle=3D\_PR_.P010 > dev.cpu.9.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.9.%parent: acpi0 > dev.cpu.9.coretemp.delta: 72 > dev.cpu.9.coretemp.resolution: 1 > dev.cpu.9.coretemp.tjmax: 95.0C > dev.cpu.9.coretemp.throttle_log: 0 > dev.cpu.9.temperature: 23.0C > dev.cpu.9.cx_supported: C1/1/32 C2/3/96 C3/3/128 > dev.cpu.9.cx_lowest: C1 > dev.cpu.9.cx_usage: 100.00% 0.00% 0.00% last 168834us > dev.cpu.10.%desc: ACPI CPU > dev.cpu.10.%driver: cpu > dev.cpu.10.%location: handle=3D\_PR_.P011 > dev.cpu.10.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.10.%parent: acpi0 > dev.cpu.10.coretemp.delta: 64 > dev.cpu.10.coretemp.resolution: 1 > dev.cpu.10.coretemp.tjmax: 95.0C > dev.cpu.10.coretemp.throttle_log: 0 > dev.cpu.10.temperature: 31.0C > dev.cpu.10.cx_supported: C1/1/32 C2/3/96 C3/3/128 > dev.cpu.10.cx_lowest: C1 > dev.cpu.10.cx_usage: 100.00% 0.00% 0.00% last 141245us > dev.cpu.11.%desc: ACPI CPU > dev.cpu.11.%driver: cpu > dev.cpu.11.%location: handle=3D\_PR_.P012 > dev.cpu.11.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.11.%parent: acpi0 > dev.cpu.11.coretemp.delta: 64 > dev.cpu.11.coretemp.resolution: 1 > dev.cpu.11.coretemp.tjmax: 95.0C > dev.cpu.11.coretemp.throttle_log: 0 > dev.cpu.11.temperature: 31.0C > dev.cpu.11.cx_supported: C1/1/32 C2/3/96 C3/3/128 > dev.cpu.11.cx_lowest: C1 > dev.cpu.11.cx_usage: 100.00% 0.00% 0.00% last 133706us > dev.cpu.12.%desc: ACPI CPU > dev.cpu.12.%driver: cpu > dev.cpu.12.%location: handle=3D\_PR_.P013 > dev.cpu.12.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.12.%parent: acpi0 > dev.cpu.12.coretemp.delta: 69 > dev.cpu.12.coretemp.resolution: 1 > dev.cpu.12.coretemp.tjmax: 95.0C > dev.cpu.12.coretemp.throttle_log: 0 > dev.cpu.12.temperature: 25.0C > dev.cpu.12.cx_supported: C1/1/32 C2/3/96 C3/3/128 > dev.cpu.12.cx_lowest: C1 > dev.cpu.12.cx_usage: 100.00% 0.00% 0.00% last 112608us > dev.cpu.13.%desc: ACPI CPU > dev.cpu.13.%driver: cpu > dev.cpu.13.%location: handle=3D\_PR_.P014 > dev.cpu.13.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.13.%parent: acpi0 > dev.cpu.13.coretemp.delta: 70 > dev.cpu.13.coretemp.resolution: 1 > dev.cpu.13.coretemp.tjmax: 95.0C > dev.cpu.13.coretemp.throttle_log: 0 > dev.cpu.13.temperature: 25.0C > dev.cpu.13.cx_supported: C1/1/32 C2/3/96 C3/3/128 > dev.cpu.13.cx_lowest: C1 > dev.cpu.13.cx_usage: 100.00% 0.00% 0.00% last 58467us > dev.cpu.14.%desc: ACPI CPU > dev.cpu.14.%driver: cpu > dev.cpu.14.%location: handle=3D\_PR_.P015 > dev.cpu.14.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.14.%parent: acpi0 > dev.cpu.14.coretemp.delta: 67 > dev.cpu.14.coretemp.resolution: 1 > dev.cpu.14.coretemp.tjmax: 95.0C > dev.cpu.14.coretemp.throttle_log: 0 > dev.cpu.14.temperature: 28.0C > dev.cpu.14.cx_supported: C1/1/32 C2/3/96 C3/3/128 > dev.cpu.14.cx_lowest: C1 > dev.cpu.14.cx_usage: 100.00% 0.00% 0.00% last 41275us > dev.cpu.15.%desc: ACPI CPU > dev.cpu.15.%driver: cpu > dev.cpu.15.%location: handle=3D\_PR_.P016 > dev.cpu.15.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.15.%parent: acpi0 > dev.cpu.15.coretemp.delta: 67 > dev.cpu.15.coretemp.resolution: 1 > dev.cpu.15.coretemp.tjmax: 95.0C > dev.cpu.15.coretemp.throttle_log: 0 > dev.cpu.15.temperature: 28.0C > dev.cpu.15.cx_supported: C1/1/32 C2/3/96 C3/3/128 > dev.cpu.15.cx_lowest: C1 > dev.cpu.15.cx_usage: 100.00% 0.00% 0.00% last 249us > > % sysctl dev.est > dev.est.%parent: > > % sysctl -a | grep freq | grep -v time > kern.acct_chkfreq: 15 > device cpufreq > net.inet.sctp.sack_freq: 2 > debug.cpufreq.lowest: 0 > debug.cpufreq.verbose: 0 > machdep.i8254_freq: 1193182 > machdep.tsc_freq: 2400132656 > dev.cpu.0.freq: 2400 > dev.cpu.0.freq_levels: 2400/-1 2100/-1 1800/-1 1500/-1 1200/-1 900/-1 > 600/-1 300/-1 > dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 > 3750/-1 2500/-1 1250/-1 > dev.p4tcc.1.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 > 3750/-1 2500/-1 1250/-1 > dev.p4tcc.2.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 > 3750/-1 2500/-1 1250/-1 > dev.p4tcc.3.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 > 3750/-1 2500/-1 1250/-1 > dev.p4tcc.4.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 > 3750/-1 2500/-1 1250/-1 > dev.p4tcc.5.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 > 3750/-1 2500/-1 1250/-1 > dev.p4tcc.6.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 > 3750/-1 2500/-1 1250/-1 > dev.p4tcc.7.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 > 3750/-1 2500/-1 1250/-1 > dev.p4tcc.8.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 > 3750/-1 2500/-1 1250/-1 > dev.p4tcc.9.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 > 3750/-1 2500/-1 1250/-1 > dev.p4tcc.10.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 > 3750/-1 2500/-1 1250/-1 > dev.p4tcc.11.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 > 3750/-1 2500/-1 1250/-1 > dev.p4tcc.12.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 > 3750/-1 2500/-1 1250/-1 > dev.p4tcc.13.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 > 3750/-1 2500/-1 1250/-1 > dev.p4tcc.14.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 > 3750/-1 2500/-1 1250/-1 > dev.p4tcc.15.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 > 3750/-1 2500/-1 1250/-1 > dev.cpufreq.%parent: > dev.cpufreq.0.%desc: > dev.cpufreq.0.%driver: cpufreq > dev.cpufreq.0.%location: > dev.cpufreq.0.%pnpinfo: > dev.cpufreq.0.%parent: cpu0 > dev.cpufreq.1.%desc: > dev.cpufreq.1.%driver: cpufreq > dev.cpufreq.1.%location: > dev.cpufreq.1.%pnpinfo: > dev.cpufreq.1.%parent: cpu1 > dev.cpufreq.2.%desc: > dev.cpufreq.2.%driver: cpufreq > dev.cpufreq.2.%location: > dev.cpufreq.2.%pnpinfo: > dev.cpufreq.2.%parent: cpu2 > dev.cpufreq.3.%desc: > dev.cpufreq.3.%driver: cpufreq > dev.cpufreq.3.%location: > dev.cpufreq.3.%pnpinfo: > dev.cpufreq.3.%parent: cpu3 > dev.cpufreq.4.%desc: > dev.cpufreq.4.%driver: cpufreq > dev.cpufreq.4.%location: > dev.cpufreq.4.%pnpinfo: > dev.cpufreq.4.%parent: cpu4 > dev.cpufreq.5.%desc: > dev.cpufreq.5.%driver: cpufreq > dev.cpufreq.5.%location: > dev.cpufreq.5.%pnpinfo: > dev.cpufreq.5.%parent: cpu5 > dev.cpufreq.6.%desc: > dev.cpufreq.6.%driver: cpufreq > dev.cpufreq.6.%location: > dev.cpufreq.6.%pnpinfo: > dev.cpufreq.6.%parent: cpu6 > dev.cpufreq.7.%desc: > dev.cpufreq.7.%driver: cpufreq > dev.cpufreq.7.%location: > dev.cpufreq.7.%pnpinfo: > dev.cpufreq.7.%parent: cpu7 > dev.cpufreq.8.%desc: > dev.cpufreq.8.%driver: cpufreq > dev.cpufreq.8.%location: > dev.cpufreq.8.%pnpinfo: > dev.cpufreq.8.%parent: cpu8 > dev.cpufreq.9.%desc: > dev.cpufreq.9.%driver: cpufreq > dev.cpufreq.9.%location: > dev.cpufreq.9.%pnpinfo: > dev.cpufreq.9.%parent: cpu9 > dev.cpufreq.10.%desc: > dev.cpufreq.10.%driver: cpufreq > dev.cpufreq.10.%location: > dev.cpufreq.10.%pnpinfo: > dev.cpufreq.10.%parent: cpu10 > dev.cpufreq.11.%desc: > dev.cpufreq.11.%driver: cpufreq > dev.cpufreq.11.%location: > dev.cpufreq.11.%pnpinfo: > dev.cpufreq.11.%parent: cpu11 > dev.cpufreq.12.%desc: > dev.cpufreq.12.%driver: cpufreq > dev.cpufreq.12.%location: > dev.cpufreq.12.%pnpinfo: > dev.cpufreq.12.%parent: cpu12 > dev.cpufreq.13.%desc: > dev.cpufreq.13.%driver: cpufreq > dev.cpufreq.13.%location: > dev.cpufreq.13.%pnpinfo: > dev.cpufreq.13.%parent: cpu13 > dev.cpufreq.14.%desc: > dev.cpufreq.14.%driver: cpufreq > dev.cpufreq.14.%location: > dev.cpufreq.14.%pnpinfo: > dev.cpufreq.14.%parent: cpu14 > dev.cpufreq.15.%desc: > dev.cpufreq.15.%driver: cpufreq > dev.cpufreq.15.%location: > dev.cpufreq.15.%pnpinfo: > dev.cpufreq.15.%parent: cpu15 > > > With hint.p4tcc.0.disabled=3D"1" active (default in 10=3DSTABLE now): > > % sysctl dev.cpu > dev.cpu.%parent: > dev.cpu.0.%desc: ACPI CPU > dev.cpu.0.%driver: cpu > dev.cpu.0.%location: handle=3D\_PR_.P001 > dev.cpu.0.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.0.%parent: acpi0 > dev.cpu.0.coretemp.delta: 66 > dev.cpu.0.coretemp.resolution: 1 > dev.cpu.0.coretemp.tjmax: 95.0C > dev.cpu.0.coretemp.throttle_log: 0 > dev.cpu.0.temperature: 29.0C > dev.cpu.0.cx_supported: C1/1/32 C2/3/96 C3/3/128 > dev.cpu.0.cx_lowest: C1 > dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 428us > dev.cpu.1.%desc: ACPI CPU > dev.cpu.1.%driver: cpu > dev.cpu.1.%location: handle=3D\_PR_.P002 > dev.cpu.1.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.1.%parent: acpi0 > dev.cpu.1.coretemp.delta: 66 > dev.cpu.1.coretemp.resolution: 1 > dev.cpu.1.coretemp.tjmax: 95.0C > dev.cpu.1.coretemp.throttle_log: 0 > dev.cpu.1.temperature: 29.0C > dev.cpu.1.cx_supported: C1/1/32 C2/3/96 C3/3/128 > dev.cpu.1.cx_lowest: C1 > dev.cpu.1.cx_usage: 100.00% 0.00% 0.00% last 223406us > dev.cpu.2.%desc: ACPI CPU > dev.cpu.2.%driver: cpu > dev.cpu.2.%location: handle=3D\_PR_.P003 > dev.cpu.2.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.2.%parent: acpi0 > dev.cpu.2.coretemp.delta: 63 > dev.cpu.2.coretemp.resolution: 1 > dev.cpu.2.coretemp.tjmax: 95.0C > dev.cpu.2.coretemp.throttle_log: 0 > dev.cpu.2.temperature: 32.0C > dev.cpu.2.cx_supported: C1/1/32 C2/3/96 C3/3/128 > dev.cpu.2.cx_lowest: C1 > dev.cpu.2.cx_usage: 100.00% 0.00% 0.00% last 179299us > dev.cpu.3.%desc: ACPI CPU > dev.cpu.3.%driver: cpu > dev.cpu.3.%location: handle=3D\_PR_.P004 > dev.cpu.3.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.3.%parent: acpi0 > dev.cpu.3.coretemp.delta: 63 > dev.cpu.3.coretemp.resolution: 1 > dev.cpu.3.coretemp.tjmax: 95.0C > dev.cpu.3.coretemp.throttle_log: 0 > dev.cpu.3.temperature: 33.0C > dev.cpu.3.cx_supported: C1/1/32 C2/3/96 C3/3/128 > dev.cpu.3.cx_lowest: C1 > dev.cpu.3.cx_usage: 100.00% 0.00% 0.00% last 108280us > dev.cpu.4.%desc: ACPI CPU > dev.cpu.4.%driver: cpu > dev.cpu.4.%location: handle=3D\_PR_.P005 > dev.cpu.4.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.4.%parent: acpi0 > dev.cpu.4.coretemp.delta: 62 > dev.cpu.4.coretemp.resolution: 1 > dev.cpu.4.coretemp.tjmax: 95.0C > dev.cpu.4.coretemp.throttle_log: 0 > dev.cpu.4.temperature: 33.0C > dev.cpu.4.cx_supported: C1/1/32 C2/3/96 C3/3/128 > dev.cpu.4.cx_lowest: C1 > dev.cpu.4.cx_usage: 100.00% 0.00% 0.00% last 120264us > dev.cpu.5.%desc: ACPI CPU > dev.cpu.5.%driver: cpu > dev.cpu.5.%location: handle=3D\_PR_.P006 > dev.cpu.5.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.5.%parent: acpi0 > dev.cpu.5.coretemp.delta: 62 > dev.cpu.5.coretemp.resolution: 1 > dev.cpu.5.coretemp.tjmax: 95.0C > dev.cpu.5.coretemp.throttle_log: 0 > dev.cpu.5.temperature: 33.0C > dev.cpu.5.cx_supported: C1/1/32 C2/3/96 C3/3/128 > dev.cpu.5.cx_lowest: C1 > dev.cpu.5.cx_usage: 100.00% 0.00% 0.00% last 53853us > dev.cpu.6.%desc: ACPI CPU > dev.cpu.6.%driver: cpu > dev.cpu.6.%location: handle=3D\_PR_.P007 > dev.cpu.6.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.6.%parent: acpi0 > dev.cpu.6.coretemp.delta: 64 > dev.cpu.6.coretemp.resolution: 1 > dev.cpu.6.coretemp.tjmax: 95.0C > dev.cpu.6.coretemp.throttle_log: 0 > dev.cpu.6.temperature: 31.0C > dev.cpu.6.cx_supported: C1/1/32 C2/3/96 C3/3/128 > dev.cpu.6.cx_lowest: C1 > dev.cpu.6.cx_usage: 100.00% 0.00% 0.00% last 126291us > dev.cpu.7.%desc: ACPI CPU > dev.cpu.7.%driver: cpu > dev.cpu.7.%location: handle=3D\_PR_.P008 > dev.cpu.7.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.7.%parent: acpi0 > dev.cpu.7.coretemp.delta: 64 > dev.cpu.7.coretemp.resolution: 1 > dev.cpu.7.coretemp.tjmax: 95.0C > dev.cpu.7.coretemp.throttle_log: 0 > dev.cpu.7.temperature: 31.0C > dev.cpu.7.cx_supported: C1/1/32 C2/3/96 C3/3/128 > dev.cpu.7.cx_lowest: C1 > dev.cpu.7.cx_usage: 100.00% 0.00% 0.00% last 39246us > dev.cpu.8.%desc: ACPI CPU > dev.cpu.8.%driver: cpu > dev.cpu.8.%location: handle=3D\_PR_.P009 > dev.cpu.8.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.8.%parent: acpi0 > dev.cpu.8.coretemp.delta: 73 > dev.cpu.8.coretemp.resolution: 1 > dev.cpu.8.coretemp.tjmax: 95.0C > dev.cpu.8.coretemp.throttle_log: 0 > dev.cpu.8.temperature: 22.0C > dev.cpu.8.cx_supported: C1/1/32 C2/3/96 C3/3/128 > dev.cpu.8.cx_lowest: C1 > dev.cpu.8.cx_usage: 100.00% 0.00% 0.00% last 237500us > dev.cpu.9.%desc: ACPI CPU > dev.cpu.9.%driver: cpu > dev.cpu.9.%location: handle=3D\_PR_.P010 > dev.cpu.9.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.9.%parent: acpi0 > dev.cpu.9.coretemp.delta: 73 > dev.cpu.9.coretemp.resolution: 1 > dev.cpu.9.coretemp.tjmax: 95.0C > dev.cpu.9.coretemp.throttle_log: 0 > dev.cpu.9.temperature: 22.0C > dev.cpu.9.cx_supported: C1/1/32 C2/3/96 C3/3/128 > dev.cpu.9.cx_lowest: C1 > dev.cpu.9.cx_usage: 100.00% 0.00% 0.00% last 48599us > dev.cpu.10.%desc: ACPI CPU > dev.cpu.10.%driver: cpu > dev.cpu.10.%location: handle=3D\_PR_.P011 > dev.cpu.10.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.10.%parent: acpi0 > dev.cpu.10.coretemp.delta: 64 > dev.cpu.10.coretemp.resolution: 1 > dev.cpu.10.coretemp.tjmax: 95.0C > dev.cpu.10.coretemp.throttle_log: 0 > dev.cpu.10.temperature: 31.0C > dev.cpu.10.cx_supported: C1/1/32 C2/3/96 C3/3/128 > dev.cpu.10.cx_lowest: C1 > dev.cpu.10.cx_usage: 100.00% 0.00% 0.00% last 276265us > dev.cpu.11.%desc: ACPI CPU > dev.cpu.11.%driver: cpu > dev.cpu.11.%location: handle=3D\_PR_.P012 > dev.cpu.11.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.11.%parent: acpi0 > dev.cpu.11.coretemp.delta: 64 > dev.cpu.11.coretemp.resolution: 1 > dev.cpu.11.coretemp.tjmax: 95.0C > dev.cpu.11.coretemp.throttle_log: 0 > dev.cpu.11.temperature: 31.0C > dev.cpu.11.cx_supported: C1/1/32 C2/3/96 C3/3/128 > dev.cpu.11.cx_lowest: C1 > dev.cpu.11.cx_usage: 100.00% 0.00% 0.00% last 45235us > dev.cpu.12.%desc: ACPI CPU > dev.cpu.12.%driver: cpu > dev.cpu.12.%location: handle=3D\_PR_.P013 > dev.cpu.12.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.12.%parent: acpi0 > dev.cpu.12.coretemp.delta: 70 > dev.cpu.12.coretemp.resolution: 1 > dev.cpu.12.coretemp.tjmax: 95.0C > dev.cpu.12.coretemp.throttle_log: 0 > dev.cpu.12.temperature: 25.0C > dev.cpu.12.cx_supported: C1/1/32 C2/3/96 C3/3/128 > dev.cpu.12.cx_lowest: C1 > dev.cpu.12.cx_usage: 100.00% 0.00% 0.00% last 176635us > dev.cpu.13.%desc: ACPI CPU > dev.cpu.13.%driver: cpu > dev.cpu.13.%location: handle=3D\_PR_.P014 > dev.cpu.13.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.13.%parent: acpi0 > dev.cpu.13.coretemp.delta: 70 > dev.cpu.13.coretemp.resolution: 1 > dev.cpu.13.coretemp.tjmax: 95.0C > dev.cpu.13.coretemp.throttle_log: 0 > dev.cpu.13.temperature: 25.0C > dev.cpu.13.cx_supported: C1/1/32 C2/3/96 C3/3/128 > dev.cpu.13.cx_lowest: C1 > dev.cpu.13.cx_usage: 100.00% 0.00% 0.00% last 86467us > dev.cpu.14.%desc: ACPI CPU > dev.cpu.14.%driver: cpu > dev.cpu.14.%location: handle=3D\_PR_.P015 > dev.cpu.14.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.14.%parent: acpi0 > dev.cpu.14.coretemp.delta: 68 > dev.cpu.14.coretemp.resolution: 1 > dev.cpu.14.coretemp.tjmax: 95.0C > dev.cpu.14.coretemp.throttle_log: 0 > dev.cpu.14.temperature: 27.0C > dev.cpu.14.cx_supported: C1/1/32 C2/3/96 C3/3/128 > dev.cpu.14.cx_lowest: C1 > dev.cpu.14.cx_usage: 100.00% 0.00% 0.00% last 151541us > dev.cpu.15.%desc: ACPI CPU > dev.cpu.15.%driver: cpu > dev.cpu.15.%location: handle=3D\_PR_.P016 > dev.cpu.15.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.15.%parent: acpi0 > dev.cpu.15.coretemp.delta: 68 > dev.cpu.15.coretemp.resolution: 1 > dev.cpu.15.coretemp.tjmax: 95.0C > dev.cpu.15.coretemp.throttle_log: 0 > dev.cpu.15.temperature: 27.0C > dev.cpu.15.cx_supported: C1/1/32 C2/3/96 C3/3/128 > dev.cpu.15.cx_lowest: C1 > dev.cpu.15.cx_usage: 100.00% 0.00% 0.00% last 7904us > > % sysctl dev.est > dev.est.%parent: > > % sysctl -a | grep freq | grep -v time > kern.acct_chkfreq: 15 > device cpufreq > net.inet.sctp.sack_freq: 2 > debug.cpufreq.lowest: 0 > debug.cpufreq.verbose: 0 > machdep.i8254_freq: 1193182 > machdep.tsc_freq: 2400136744 > > > Also I have this in dmesg which may be relevant: > > p4tcc0: on cpu0 > coretemp1: on cpu1 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 12 > device_attach: est1 attach returned 6 > > for each CPU. The line starting with p4tcc apears only when I remove > hint.p4tcc.0.disabled=3D"1" > > > > > > Are you not running powerd? Of course powerd won't start if it can't > > get dev.cpu.0.freq but you can ordinarily use it to set lowest and/or > > highest freqs. Once FreeBSD starts, BIOS settings should have little > > do with it, AFAIK, except how they might set freq before powerd starts. > > No, I don't use powerd. I want my processor to always run at max speed. > But I encountered situations when sometime system is running at 1200GHz > instead of 2400 and it is fixed with BIOS updates. > That is why I check dev.cpu.0.freq each time system reboot. > > > My processor is Intel E5620 : > > http://ark.intel.com/products/47925/Intel-Xeon-Processor-E5620-12M-Cache-= 2_40-GHz-5_86-GTs-Intel-QPI > > It is not so ancient thing. > No, it's not ancient. With no capabilities that can set or report CPU frequency, the OID is undefined. I may be that the "CPU supports Enhanced Speedstep, but is not recognized." is really a problem. It says that FreeBSD does not have a table of the EST setting/energy saving values for that processor. This is not unusual as Intel at some point decided that these tables were proprietary and stopped releasing them to the open source community. ACPI should be able to provide the list of frequencies but it looks like it did not do so. This may be a bug in BIOS. Do you see similar messages for all est devices? I am guessing that they do, but your message does not actually say so. In any case, the problem is that EST is not attaching and that is cause of the lack of the OID when P4TCC and throttling are disabled. Since you are only using it to be sure that the system is running at full speed and re not running powerd, there is no reason not to enable P4TCC so the OID will be defined. TCC will not actually be used, so this is the simple solution. I am concerned that there is now a second report of this, though. It smells like a BIOS issue,but it seems to work under Windows. Perhaps you need a BIOS update? (N.B. This is really grasping at straws as I just don't know much beyond what I have said.) -- Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-stable@FreeBSD.ORG Mon Mar 23 06:03:43 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C1684452; Mon, 23 Mar 2015 06:03:43 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (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 D3DAB195; Mon, 23 Mar 2015 06:03:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t2N63YaM003229; Mon, 23 Mar 2015 17:03:34 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 23 Mar 2015 17:03:34 +1100 (EST) From: Ian Smith To: Dmitry Sivachenko Subject: Re: dev.cpu.0.freq disapeared In-Reply-To: <97279AFB-7718-4080-9F18-155287216A04@gmail.com> Message-ID: <20150323152431.W22641@sola.nimnet.asn.au> References: <20150322055323.GA48710@server.rulingia.com> <77C8F6F7-2C25-4BC5-B373-11441AB58FAD@gmail.com> <550ECD9D.2030108@nimnet.asn.au> <97279AFB-7718-4080-9F18-155287216A04@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Cc: Kevin Oberman , FreeBSD Stable ML , Peter Jeremy , nwhitehorn@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 06:03:43 -0000 On Sun, 22 Mar 2015 20:11:36 +0300, Dmitry Sivachenko wrote: > > On 22 2015 ., at 17:11, Ian Smith wrote: > > > > Dmitry Sivachenko wrote: > >>> On 22 2015 ., at 8:53, Peter Jeremy wrote: > >>> On 2015-Mar-22 00:58:55 +0300, Dmitry Sivachenko wrote: > >>>> I have a machine with the following processor: > >>>> CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (2400.14-MHz > >>>> K8-class CPU) Origin="GenuineIntel" Id=0x206c2 Family=0x6 Model=0x2c Stepping=2 > >>> ... > >>>> After I upgraded to 10.1-STABLE #0 r279956, this sysctl disapeared. % sysctl dev.cpu.0.freq sysctl: unknown oid 'dev.cpu.0.freq': No such file or directory % > > > >>> What OIDs do you have? Does dev.cpu.0 exist? How about dev.cpu? > >> dev.cpu.0 does exist. > > > > It could be helpful to show all of: > > > > % sysctl dev.cpu > > % sysctl dev.est # if you have that? > > % sysctl -a | grep freq | grep -v time > > > > both before and after re-enabling p4tcc. > > Hello, > > With #hint.p4tcc.0.disabled="1" commented out: > > % sysctl dev.cpu > dev.cpu.%parent: The parent should probably be listed. On mine it's acpi0 > dev.cpu.0.%desc: ACPI CPU > dev.cpu.0.%driver: cpu > dev.cpu.0.%location: handle=\_PR_.P001 > dev.cpu.0.%pnpinfo: _HID=none _UID=0 > dev.cpu.0.%parent: acpi0 > dev.cpu.0.coretemp.delta: 67 > dev.cpu.0.coretemp.resolution: 1 > dev.cpu.0.coretemp.tjmax: 95.0C > dev.cpu.0.coretemp.throttle_log: 0 > dev.cpu.0.temperature: 28.0C > dev.cpu.0.freq: 2400 > dev.cpu.0.freq_levels: 2400/-1 2100/-1 1800/-1 1500/-1 1200/-1 900/-1 600/-1 300/-1 > dev.cpu.0.cx_supported: C1/1/32 C2/3/96 C3/3/128 > dev.cpu.0.cx_lowest: C1 > dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 261us [..] > dev.cpu.15.%desc: ACPI CPU > dev.cpu.15.%driver: cpu > dev.cpu.15.%location: handle=\_PR_.P016 > dev.cpu.15.%pnpinfo: _HID=none _UID=0 > dev.cpu.15.%parent: acpi0 > dev.cpu.15.coretemp.delta: 67 > dev.cpu.15.coretemp.resolution: 1 > dev.cpu.15.coretemp.tjmax: 95.0C > dev.cpu.15.coretemp.throttle_log: 0 > dev.cpu.15.temperature: 28.0C > dev.cpu.15.cx_supported: C1/1/32 C2/3/96 C3/3/128 > dev.cpu.15.cx_lowest: C1 > dev.cpu.15.cx_usage: 100.00% 0.00% 0.00% last 249us > > % sysctl dev.est > dev.est.%parent: Right, so even with p4tcc enabled there's no dev.est, yet we then have dev.cpu.0.freq and freq_levels made available. Hmm .. > % sysctl -a | grep freq | grep -v time > kern.acct_chkfreq: 15 > device cpufreq > net.inet.sctp.sack_freq: 2 > debug.cpufreq.lowest: 0 > debug.cpufreq.verbose: 0 > machdep.i8254_freq: 1193182 > machdep.tsc_freq: 2400132656 > dev.cpu.0.freq: 2400 > dev.cpu.0.freq_levels: 2400/-1 2100/-1 1800/-1 1500/-1 1200/-1 900/-1 600/-1 300/-1 > dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 [..] > dev.p4tcc.15.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 > dev.cpufreq.%parent: > dev.cpufreq.0.%desc: > dev.cpufreq.0.%driver: cpufreq > dev.cpufreq.0.%location: > dev.cpufreq.0.%pnpinfo: > dev.cpufreq.0.%parent: cpu0 [..] > dev.cpufreq.15.%desc: > dev.cpufreq.15.%driver: cpufreq > dev.cpufreq.15.%location: > dev.cpufreq.15.%pnpinfo: > dev.cpufreq.15.%parent: cpu15 > With hint.p4tcc.0.disabled="1" active (default in 10=STABLE now): > > % sysctl dev.cpu > dev.cpu.%parent: > dev.cpu.0.%desc: ACPI CPU > dev.cpu.0.%driver: cpu > dev.cpu.0.%location: handle=\_PR_.P001 > dev.cpu.0.%pnpinfo: _HID=none _UID=0 > dev.cpu.0.%parent: acpi0 > dev.cpu.0.coretemp.delta: 66 > dev.cpu.0.coretemp.resolution: 1 > dev.cpu.0.coretemp.tjmax: 95.0C > dev.cpu.0.coretemp.throttle_log: 0 > dev.cpu.0.temperature: 29.0C > dev.cpu.0.cx_supported: C1/1/32 C2/3/96 C3/3/128 > dev.cpu.0.cx_lowest: C1 > dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 428us [..] > dev.cpu.1.temperature: 29.0C > dev.cpu.2.temperature: 32.0C > dev.cpu.3.temperature: 33.0C > dev.cpu.4.temperature: 33.0C > dev.cpu.5.temperature: 33.0C > dev.cpu.6.temperature: 31.0C > dev.cpu.7.temperature: 31.0C > dev.cpu.8.temperature: 22.0C > dev.cpu.9.temperature: 22.0C > dev.cpu.10.temperature: 31.0C > dev.cpu.11.temperature: 31.0C > dev.cpu.12.temperature: 25.0C > dev.cpu.13.temperature: 25.0C > dev.cpu.14.temperature: 27.0C The above all seem the same, except temperatures. The only difference I see is the lack of dev.cpu.0.freq and dev.cpu.0.freq_levels. > dev.cpu.15.%desc: ACPI CPU > dev.cpu.15.%driver: cpu > dev.cpu.15.%location: handle=\_PR_.P016 > dev.cpu.15.%pnpinfo: _HID=none _UID=0 > dev.cpu.15.%parent: acpi0 > dev.cpu.15.coretemp.delta: 68 > dev.cpu.15.coretemp.resolution: 1 > dev.cpu.15.coretemp.tjmax: 95.0C > dev.cpu.15.coretemp.throttle_log: 0 > dev.cpu.15.temperature: 27.0C > dev.cpu.15.cx_supported: C1/1/32 C2/3/96 C3/3/128 > dev.cpu.15.cx_lowest: C1 > dev.cpu.15.cx_usage: 100.00% 0.00% 0.00% last 7904us > > % sysctl dev.est > dev.est.%parent: Do you have Enhanced Speedstep (EST), disabled in your BIOS settings? If so, just turn it on. Then you should also be able to set running frequency to 'MAX performance' or similar there. If not disabled, ie you have EST enabled in BIOS, that points to a real issue of EST detection. And it still seems strange that enabling p4tcc is enough to have cpufreq(4) include OIDs for freq and freq_levels? > % sysctl -a | grep freq | grep -v time > kern.acct_chkfreq: 15 > device cpufreq > net.inet.sctp.sack_freq: 2 > debug.cpufreq.lowest: 0 > debug.cpufreq.verbose: 0 > machdep.i8254_freq: 1193182 > machdep.tsc_freq: 2400136744 > > > Also I have this in dmesg which may be relevant: > > p4tcc0: on cpu0 > coretemp1: on cpu1 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 12 > device_attach: est1 attach returned 6 > > for each CPU. The line starting with p4tcc apears only when I remove > hint.p4tcc.0.disabled="1" Right, this is still looking like you have EST disabled in BIOS. > > Are you not running powerd? Of course powerd won't start if it can't > > get dev.cpu.0.freq but you can ordinarily use it to set lowest and/or > > highest freqs. Once FreeBSD starts, BIOS settings should have little > > do with it, AFAIK, except how they might set freq before powerd starts. > > No, I don't use powerd. I want my processor to always run at max speed. Setting debug.cpufreq.lowest=2400 should also accomplish that without running powerd. Enabling higher C-states (C2, C3 .. Cmax) would save a lot of power (ie, heat) without compromising performance, but that's a separate issue. > But I encountered situations when sometime system is running at > 1200GHz instead of 2400 and it is fixed with BIOS updates. That is > why I check dev.cpu.0.freq each time system reboot. Well, your checking did expose this issue .. > My processor is Intel E5620 : > http://ark.intel.com/products/47925/Intel-Xeon-Processor-E5620-12M-Cache-2_40-GHz-5_86-GTs-Intel-QPI > > It is not so ancient thing. Right. Looks like your board has two of these packages, and indeed it does support EST. If you do have that enabled, we have a problem, and really need to see a verbose boot dmesg. If not, you have a problem that can be easily fixed in BIOS settings :) cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Mon Mar 23 09:18:51 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B6BE1BB2; Mon, 23 Mar 2015 09:18:51 +0000 (UTC) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 321FDA2D; Mon, 23 Mar 2015 09:18:51 +0000 (UTC) Received: by lbbug6 with SMTP id ug6so19338598lbb.3; Mon, 23 Mar 2015 02:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jXsbq4g/wEgqJRK9ErruNC3sJ5WmqUStgHJGtkQXNKc=; b=gILDaYiOnc5k3cfhc6/4jFIRzl3EVXWNefcescr34GvCESPXMT/3EeONrtsLB3/4lp Uss10nmhnAywF6JjpfNHPtlqG4yH546FctgwPpDIE00G03svF8XppwA6YTJVXYArb0pO Ozb/Ix8RzIxadc1pemv5JCMbaKAlc7R3WYm265BYAC1IWxUPBRAVxyUglq5O9rJH7ITv BG+EWK7wLUAFZVnhG3YBOTwJgxtpE2Kn0/IWL/Ie4YTP1BcaeLrDgahNr4eO8reqk/Kf 5s5QI+7EcmpHVu3S6okrs1JZkCACFEJTyt5TDnYwVZu0kpnHlEazqvB4HbnlNHn9z+eh YKYA== X-Received: by 10.152.30.103 with SMTP id r7mr78796819lah.76.1427102328994; Mon, 23 Mar 2015 02:18:48 -0700 (PDT) Received: from [10.0.1.7] (broadband-5-228-253-252.nationalcablenetworks.ru. [5.228.253.252]) by mx.google.com with ESMTPSA id m8sm60849laf.14.2015.03.23.02.18.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Mar 2015 02:18:47 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: dev.cpu.0.freq disapeared From: Dmitry Sivachenko In-Reply-To: <20150323152431.W22641@sola.nimnet.asn.au> Date: Mon, 23 Mar 2015 12:18:45 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150322055323.GA48710@server.rulingia.com> <77C8F6F7-2C25-4BC5-B373-11441AB58FAD@gmail.com> <550ECD9D.2030108@nimnet.asn.au> <97279AFB-7718-4080-9F18-155287216A04@gmail.com> <20150323152431.W22641@sola.nimnet.asn.au> To: Ian Smith X-Mailer: Apple Mail (2.2070.6) Cc: Kevin Oberman , FreeBSD Stable ML , Peter Jeremy , nwhitehorn@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 09:18:51 -0000 > On 23 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2015 =D0=B3., at 9:03, Ian Smith = wrote: >=20 >=20 > Do you have Enhanced Speedstep (EST), disabled in your BIOS settings? =20= > If so, just turn it on. Then you should also be able to set running=20= > frequency to 'MAX performance' or similar there. >=20 > If not disabled, ie you have EST enabled in BIOS, that points to a = real=20 > issue of EST detection. And it still seems strange that enabling = p4tcc=20 > is enough to have cpufreq(4) include OIDs for freq and freq_levels? >=20 Thanks to all who replied. This is called Intel SpeedStep Tech in that = BIOS and it was indeed disabled. I enabled it and now I have in dmesg est0: on cpu0 even with hint.p4tcc.0.disabled=3D"1"=20 for each CPU and dev.cpu.0.freq appeared back. Thanks for your help. From owner-freebsd-stable@FreeBSD.ORG Mon Mar 23 10:44:06 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79AFA98E for ; Mon, 23 Mar 2015 10:44:06 +0000 (UTC) Received: from io.ze.tum.de (w3projmail.ze.tum.de [129.187.39.2]) (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 0708C5F1 for ; Mon, 23 Mar 2015 10:44:04 +0000 (UTC) Received: from etustar.ze.tum.de (etustar.ze.tum.de [IPv6:2001:4ca0:2e03::16:1]) (authenticated bits=0) by io.ze.tum.de (8.14.5/8.14.5) with ESMTP id t2NAXAqh069778 for ; Mon, 23 Mar 2015 11:33:10 +0100 (CET) (envelope-from estartu@ze.tum.de) Message-ID: <550FEBE6.5090804@ze.tum.de> Date: Mon, 23 Mar 2015 11:33:10 +0100 From: Gerhard Schmidt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Problems with openssl 1.0.2 update Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 10:44:06 -0000 Hi, we experiencing a problem after upgrading the openssl port to openssl 1.0.2. /usr/bin/vi started to crash after some seconds with segfault. /rescue/vi works just fine. Deleting the openssl 1.0.2 package everything works just fine again. Installing the old openssl 1.0.1_18 package it still works just fine. it seams that besides vi the bash also has this problem. Anybody experiencing the same or is this something specific to my system. I'm running FreeBSD 10.1 updated tonight. Regards Estartu -- ---------------------------------------------------------- Gerhard Schmidt | E-Mail: schmidt@ze.tum.de Technische Universität München | Jabber: estartu@ze.tum.de WWW & Online Services | Tel: +49 89 289-25270 | PGP-PublicKey Fax: +49 89 289-25257 | on request From owner-freebsd-stable@FreeBSD.ORG Mon Mar 23 11:04:37 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 02FC1F84 for ; Mon, 23 Mar 2015 11:04:37 +0000 (UTC) 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 B60F7858 for ; Mon, 23 Mar 2015 11:04:36 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Ya09p-000Nas-Hx; Mon, 23 Mar 2015 12:04:33 +0100 Date: Mon, 23 Mar 2015 12:04:33 +0100 From: Kurt Jaeger To: Gerhard Schmidt Subject: Re: Problems with openssl 1.0.2 update Message-ID: <20150323110433.GA62590@home.opsec.eu> References: <550FEBE6.5090804@ze.tum.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <550FEBE6.5090804@ze.tum.de> Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 11:04:37 -0000 Hi! > we experiencing a problem after upgrading the openssl port to openssl > 1.0.2. I have 1.0.2 installed on my testbox. vi works fine. > /usr/bin/vi started to crash after some seconds with segfault. Do you have a coredump ? -- pi@opsec.eu +49 171 3101372 5 years to go ! From owner-freebsd-stable@FreeBSD.ORG Mon Mar 23 11:36:37 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 091505C9 for ; Mon, 23 Mar 2015 11:36:37 +0000 (UTC) Received: from mail.xtaz.uk (tao.xtaz.uk [IPv6:2001:8b0:202::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BF16EB90 for ; Mon, 23 Mar 2015 11:36:36 +0000 (UTC) Received: by mail.xtaz.uk (Postfix, from userid 1001) id E43D7209AF1A; Mon, 23 Mar 2015 11:36:32 +0000 (GMT) Date: Mon, 23 Mar 2015 11:36:32 +0000 From: Matt Smith To: Gerhard Schmidt Subject: Re: Problems with openssl 1.0.2 update Message-ID: <20150323113632.GA1258@xtaz.uk> Mail-Followup-To: Matt Smith , Gerhard Schmidt , freebsd-stable@freebsd.org References: <550FEBE6.5090804@ze.tum.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <550FEBE6.5090804@ze.tum.de> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 11:36:37 -0000 On Mar 23 11:33, Gerhard Schmidt wrote: >Hi, > >we experiencing a problem after upgrading the openssl port to openssl >1.0.2. > >/usr/bin/vi started to crash after some seconds with segfault. >/rescue/vi works just fine. Deleting the openssl 1.0.2 package >everything works just fine again. Installing the old openssl 1.0.1_18 >package it still works just fine. > >it seams that besides vi the bash also has this problem. Anybody >experiencing the same or is this something specific to my system. > >I'm running FreeBSD 10.1 updated tonight. > There is definitely something not right. See this too https://forums.freebsd.org/threads/postfix-does-not-start-build-anymore-since-upgrade-to-openssl-1-0-2.50959/ I haven't had a chance yet to test it again in more detail, but someone reported that postfix was broken, and I had PHP-FPM racing and taking up 50+ load average on my box which I guess was probably nginx hitting it with tons of requests. Mine is 10.1-STABLE amd64. -- Matt From owner-freebsd-stable@FreeBSD.ORG Mon Mar 23 12:40:40 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 733F7D31; Mon, 23 Mar 2015 12:40:40 +0000 (UTC) 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 2FB10353; Mon, 23 Mar 2015 12:40:39 +0000 (UTC) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3l9b0H2HvxzZrj; Mon, 23 Mar 2015 13:40:31 +0100 (CET) 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 GDWTnnr3hXT5; Mon, 23 Mar 2015 13:40:28 +0100 (CET) Received: from marvin.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA; Mon, 23 Mar 2015 13:40:28 +0100 (CET) Message-ID: <551009BB.9020906@FreeBSD.org> Date: Mon, 23 Mar 2015 13:40:27 +0100 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Gerhard Schmidt , freebsd-stable@freebsd.org, FreeBSD Ports Subject: Re: Problems with openssl 1.0.2 update References: <550FEBE6.5090804@ze.tum.de> In-Reply-To: <550FEBE6.5090804@ze.tum.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 12:40:40 -0000 On 03/23/15 11:33, Gerhard Schmidt wrote: > Hi, > > we experiencing a problem after upgrading the openssl port to openssl > 1.0.2. > > /usr/bin/vi started to crash after some seconds with segfault. > /rescue/vi works just fine. Deleting the openssl 1.0.2 package > everything works just fine again. Installing the old openssl 1.0.1_18 > package it still works just fine. > > it seams that besides vi the bash also has this problem. Anybody > experiencing the same or is this something specific to my system. > > I'm running FreeBSD 10.1 updated tonight. I am seeing runtime problems with asterisk13 (which I maintain), caused by the OpenSSL update fallout. In this case, after some analysis, I concluded the problem is the libsrtp port requiring OpenSSL from ports(for a reason), causing asterisk to link to that too, which would be correct. Asterisk also uses the security/trousers port, which links to system OpenSSL. This ensues a conflict which now results in asterisk segfaulting and stopping to work. I'm investigating what can be done about this. As a local solution I can force the trousers port to link against OpenSSL from ports, but this will not fix the general problem. As a port maintaner I ony see modifying the trousers port to depend on ports OpenSSL as a solution, is this acceptable? -- Guido Falsi From owner-freebsd-stable@FreeBSD.ORG Mon Mar 23 13:16:39 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 70C47873; Mon, 23 Mar 2015 13:16:39 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 5C3B3961; Mon, 23 Mar 2015 13:16:39 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 419848DE; Mon, 23 Mar 2015 13:16:39 +0000 (UTC) Date: Mon, 23 Mar 2015 13:16:38 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-stable@freebsd.org, mav@FreeBSD.org Message-ID: <1556030941.19.1427116599138.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_stable_10 #1302 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 13:16:39 -0000 See Changes: [mav] MFC r280293: Add missing variable initialization. Reported by: Coverity CID: 1288938 ------------------------------------------ [...truncated 181605 lines...] --- usr.sbin.all__D --- --- autounmountd.o --- cc -O2 -pipe -I -I -I -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c -o autounmountd.o --- all_subdir_bhyve --- --- atkbdc.o --- cc -O2 -pipe -g -O0 -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c -o atkbdc.o --- lib.all__D --- --- pam_tacplus.8.gz --- gzip -cn > pam_tacplus.8.gz --- usr.sbin.all__D --- --- acpi.o --- --- lib.all__D --- ===> lib/libpam/modules/pam_unix (all) --- usr.sbin.all__D --- cc -O2 -pipe -g -O0 -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c -o acpi.o --- all_subdir_autofs --- --- common.o --- cc -O2 -pipe -I -I -I -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c -o common.o --- lib.all__D --- --- pam_unix.8.gz --- gzip -cn > pam_unix.8.gz --- usr.sbin.all__D --- --- all_subdir_bhyve --- --- bhyverun.o --- --- lib.all__D --- ===> lib/libpam/libpam (all) --- usr.sbin.all__D --- cc -O2 -pipe -g -O0 -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c -o bhyverun.o --- block_if.o --- cc -O2 -pipe -g -O0 -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c -o block_if.o --- all_subdir_autofs --- --- defined.o --- cc -O2 -pipe -I -I -I -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c -o defined.o --- all_subdir_bhyve --- --- consport.o --- cc -O2 -pipe -g -O0 -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c -o consport.o --- all_subdir_autofs --- --- getmntopts.o --- cc -O2 -pipe -I -I -I -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c -o getmntopts.o --- all_subdir_bhyve --- --- dbgport.o --- cc -O2 -pipe -g -O0 -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c -o dbgport.o --- inout.o --- --- all_subdir_autofs --- --- log.o --- cc -O2 -pipe -I -I -I -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c -o log.o --- all_subdir_bhyve --- cc -O2 -pipe -g -O0 -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c -o inout.o --- lib.all__D --- --- openpam.3.gz --- gzip -cn > openpam.3.gz --- openpam_borrow_cred.3.gz --- gzip -cn > openpam_borrow_cred.3.gz --- openpam_free_data.3.gz --- gzip -cn > openpam_free_data.3.gz --- openpam_free_envlist.3.gz --- gzip -cn > openpam_free_envlist.3.gz --- usr.sbin.all__D --- --- ioapic.o --- cc -O2 -pipe -g -O0 -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c -o ioapic.o --- lib.all__D --- --- openpam_get_feature.3.gz --- gzip -cn > openpam_get_feature.3.gz --- openpam_get_option.3.gz --- gzip -cn > openpam_get_option.3.gz --- usr.sbin.all__D --- --- all_subdir_autofs --- --- popen.o --- cc -O2 -pipe -I -I -I -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c -o popen.o --- lib.all__D --- --- openpam_log.3.gz --- gzip -cn > openpam_log.3.gz --- usr.sbin.all__D --- --- all_subdir_bhyve --- --- mem.o --- --- lib.all__D --- --- openpam_nullconv.3.gz --- gzip -cn > openpam_nullconv.3.gz --- usr.sbin.all__D --- cc -O2 -pipe -g -O0 -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c -o mem.o --- lib.all__D --- --- openpam_readline.3.gz --- gzip -cn > openpam_readline.3.gz --- openpam_readlinev.3.gz --- gzip -cn > openpam_readlinev.3.gz --- usr.sbin.all__D --- --- all_subdir_autofs --- --- automount.8.gz --- --- lib.all__D --- --- openpam_readword.3.gz --- --- usr.sbin.all__D --- gzip -cn > automount.8.gz --- lib.all__D --- gzip -cn > openpam_readword.3.gz --- usr.sbin.all__D --- --- automountd.8.gz --- --- lib.all__D --- --- openpam_restore_cred.3.gz --- --- usr.sbin.all__D --- gzip -cn > automountd.8.gz --- lib.all__D --- gzip -cn > openpam_restore_cred.3.gz --- openpam_set_feature.3.gz --- --- usr.sbin.all__D --- --- autounmountd.8.gz --- --- lib.all__D --- gzip -cn > openpam_set_feature.3.gz --- usr.sbin.all__D --- gzip -cn > autounmountd.8.gz --- auto_master.5.gz --- --- lib.all__D --- --- openpam_set_option.3.gz --- --- usr.sbin.all__D --- gzip -cn > auto_master.5.gz --- lib.all__D --- gzip -cn > openpam_set_option.3.gz --- usr.sbin.all__D --- --- token.o --- cc -O2 -pipe -I -I -I -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c token.c -o token.o --- lib.all__D --- --- openpam_straddch.3.gz --- gzip -cn > openpam_straddch.3.gz --- usr.sbin.all__D --- --- all_subdir_bhyve --- --- mevent.o --- cc -O2 -pipe -g -O0 -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c -o mevent.o --- lib.all__D --- --- openpam_subst.3.gz --- gzip -cn > openpam_subst.3.gz --- openpam_ttyconv.3.gz --- --- usr.sbin.all__D --- --- mptbl.o --- --- lib.all__D --- gzip -cn > openpam_ttyconv.3.gz --- usr.sbin.all__D --- cc -O2 -pipe -g -O0 -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c -o mptbl.o --- lib.all__D --- --- pam.3.gz --- gzip -cn > pam.3.gz --- pam_acct_mgmt.3.gz --- gzip -cn > pam_acct_mgmt.3.gz --- usr.sbin.all__D --- --- pci_ahci.o --- --- lib.all__D --- --- pam_authenticate.3.gz --- gzip -cn > pam_authenticate.3.gz --- usr.sbin.all__D --- --- all_subdir_autofs --- --- automountd --- --- all_subdir_bhyve --- cc -O2 -pipe -g -O0 -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c -o pci_ahci.o --- all_subdir_autofs --- cc -O2 -pipe -I -I -I -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -o automountd automount.o automountd.o autounmountd.o common.o defined.o getmntopts.o log.o popen.o token.o -lutil --- lib.all__D --- --- pam_chauthtok.3.gz --- gzip -cn > pam_chauthtok.3.gz --- pam_close_session.3.gz --- --- usr.bin.all__D --- --- all_subdir_column --- ===> usr.bin/column (all) --- lib.all__D --- gzip -cn > pam_close_session.3.gz --- pam_conv.3.gz --- --- usr.sbin.all__D --- --- all_subdir_bhyve --- :1512:8: error: use of undeclared identifier 'dsm' ncq = dsm = 0; ^ --- lib.all__D --- gzip -cn > pam_conv.3.gz --- usr.sbin.all__D --- 1 error generated. *** [pci_ahci.o] Error code 1 make[4]: stopped in 1 error make[4]: stopped in *** [all_subdir_bhyve] Error code 2 make[3]: stopped in 1 error make[3]: stopped in *** [usr.sbin.all__D] Error code 2 make[2]: stopped in --- usr.bin.all__D --- A failure has been detected in another branch of the parallel make make[4]: stopped in *** [all_subdir_column] Error code 2 make[3]: stopped in --- lib.all__D --- A failure has been detected in another branch of the parallel make make[5]: stopped in *** [_sub.all] Error code 2 make[4]: stopped in 1 error make[4]: stopped in *** [all_subdir_libpam] Error code 2 make[3]: stopped in 1 error make[3]: stopped in *** [lib.all__D] Error code 2 make[2]: stopped in --- usr.bin.all__D --- --- all_subdir_clang --- A failure has been detected in another branch of the parallel make make[5]: stopped in *** [all_subdir_tblgen] Error code 2 make[4]: stopped in 1 error make[4]: stopped in *** [all_subdir_clang] Error code 2 make[3]: stopped in 2 errors make[3]: stopped in *** [usr.bin.all__D] Error code 2 make[2]: stopped in 3 errors make[2]: stopped in *** [everything] Error code 2 make[1]: stopped in 1 error make[1]: stopped in *** [buildworld] Error code 2 make: stopped in 1 error make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-stable@FreeBSD.ORG Mon Mar 23 13:16:44 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 95B60878 for ; Mon, 23 Mar 2015 13:16:44 +0000 (UTC) Received: from io.ze.tum.de (w3projmail.ze.tum.de [129.187.39.2]) (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 1A44D964 for ; Mon, 23 Mar 2015 13:16:42 +0000 (UTC) Received: from etustar.ze.tum.de (etustar.ze.tum.de [IPv6:2001:4ca0:2e03::16:1]) (authenticated bits=0) by io.ze.tum.de (8.14.5/8.14.5) with ESMTP id t2NDGcjK036839 for ; Mon, 23 Mar 2015 14:16:38 +0100 (CET) (envelope-from schmidt@ze.tum.de) Message-ID: <55101231.4080205@ze.tum.de> Date: Mon, 23 Mar 2015 14:16:33 +0100 From: Gerhard Schmidt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Problems with openssl 1.0.2 update References: <550FEBE6.5090804@ze.tum.de> <551009BB.9020906@FreeBSD.org> In-Reply-To: <551009BB.9020906@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MHcu8nFsoodu8o3oNsSwdv7uR8qCS7vop" X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 13:16:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MHcu8nFsoodu8o3oNsSwdv7uR8qCS7vop Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 23.03.2015 13:40, Guido Falsi wrote: > On 03/23/15 11:33, Gerhard Schmidt wrote: >> Hi, >> >> we experiencing a problem after upgrading the openssl port to openssl= >> 1.0.2. >> >> /usr/bin/vi started to crash after some seconds with segfault. >> /rescue/vi works just fine. Deleting the openssl 1.0.2 package >> everything works just fine again. Installing the old openssl 1.0.1_18 >> package it still works just fine. >> >> it seams that besides vi the bash also has this problem. Anybody >> experiencing the same or is this something specific to my system. >> >> I'm running FreeBSD 10.1 updated tonight. >=20 > I am seeing runtime problems with asterisk13 (which I maintain), caused= > by the OpenSSL update fallout. >=20 > In this case, after some analysis, I concluded the problem is the > libsrtp port requiring OpenSSL from ports(for a reason), causing > asterisk to link to that too, which would be correct. >=20 > Asterisk also uses the security/trousers port, which links to system > OpenSSL. This ensues a conflict which now results in asterisk > segfaulting and stopping to work. >=20 > I'm investigating what can be done about this. As a local solution I ca= n > force the trousers port to link against OpenSSL from ports, but this > will not fix the general problem. As a port maintaner I ony see > modifying the trousers port to depend on ports OpenSSL as a solution, i= s > this acceptable? >=20 Most Ports link against the port openssl if its installed and agains the system openssl if not. That should be the prefered way to handle problem.= I don't know if an incompatibility between system an port openssl is a problem. I've removed the portbuild openssl from this server completely. As far as i can see the problem is with openldap-client build agains the ports openssl and used by nss_ldap or pam_ldap modul. I will do some testing when my test host is ready. Testing on an Production server is not that good :-) Regards Estartu --=20 ------------------------------------------------- Gerhard Schmidt | E-Mail: schmidt@ze.tum.de TU-M=FCnchen | Jabber: estartu@ze.tum.de WWW & Online Services | Tel: 089/289-25270 | Fax: 089/289-25257 | PGP-Publickey auf Anfrage --MHcu8nFsoodu8o3oNsSwdv7uR8qCS7vop 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 iQIcBAEBCAAGBQJVEBI2AAoJEHTSQ8xFcA2j5TAP/33IlVaBAopyU62T8slC5LAM VPU3/PUtCYsqiYZcuSjyhFGwT3O+bu7+7x9UhzgNrF18tdQrtoz8/2Vr5BVhDXMF qYWr6ZBpt3Ej9TJCasH98B5kC2rqdw8Ff1h2xY3G59H0ZoFDbrhcYFuOOQ9iqEg9 UgMce+eVLz/gDNCZISjyRS2BB8N/qC8O4+5ce4/V6HKun/xmi3YrK9ctvFUpsaxo jp+mQkWmwI+5WYjrkeBpqYTcP3+XT58vRwFLrKg+sNraUvREkUKUfiezQJxksKJo +P91/Vw8EujP/cTkRv2H5YlvyYANgC3k2oEn291esRitum4HrjSbiKWkSEEujf2S sC/ck+IAC6heMttMqQccYDi9wTugn2FJUnIESMBr/OLaEFMstOXb8SyxumT87WVM RSIiRVJft0F5X1ztliCORhRHp7nQX+40OEwFlumoo5qKzJQ4HLhrM/HOuFURuVTi 1hjq/O7CZv+VcTcxzTEx8qpf74C0MekkOfFzfL8Zrvq7jpggPPf4O8lywfgAaeaD 8dPT687EEr1Yf9++omKboL7SLZUJZz45m67gpzMAqBzB9ruc28s2Z8j20uv+G7U+ Nf/+VdPa5l/MxrxfUiwpwG0FQuW9xhKYBUcP7O2kM6ihgE4HW4VEyEEW2UN0I7JY 8LcgmnJ03kQngT84POUf =gBd2 -----END PGP SIGNATURE----- --MHcu8nFsoodu8o3oNsSwdv7uR8qCS7vop-- From owner-freebsd-stable@FreeBSD.ORG Mon Mar 23 13:18:06 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D483BBE for ; Mon, 23 Mar 2015 13:18:06 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E99D3991 for ; Mon, 23 Mar 2015 13:18:05 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.9/8.14.9) with ESMTP id t2NDI0be071737; Mon, 23 Mar 2015 09:18:01 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <55101285.5000401@sentex.net> Date: Mon, 23 Mar 2015 09:17:57 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Gerhard Schmidt , freebsd-stable@freebsd.org Subject: Re: Problems with openssl 1.0.2 update References: <550FEBE6.5090804@ze.tum.de> In-Reply-To: <550FEBE6.5090804@ze.tum.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.75 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 13:18:06 -0000 On 3/23/2015 6:33 AM, Gerhard Schmidt wrote: > Hi, > > we experiencing a problem after upgrading the openssl port to openssl > 1.0.2. > > /usr/bin/vi started to crash after some seconds with segfault. Is you vi linked to openssl ? /usr/bin/vi: libutil.so.9 => /lib/libutil.so.9 (0x800883000) libncursesw.so.8 => /lib/libncursesw.so.8 (0x800a95000) libc.so.7 => /lib/libc.so.7 (0x800cea000) -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Mon Mar 23 13:53:54 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 05E99A55 for ; Mon, 23 Mar 2015 13:53:54 +0000 (UTC) Received: from io.ze.tum.de (w3projmail.ze.tum.de [129.187.39.2]) (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 86A58EC0 for ; Mon, 23 Mar 2015 13:53:52 +0000 (UTC) Received: from etustar.ze.tum.de (etustar.ze.tum.de [IPv6:2001:4ca0:2e03::16:1]) (authenticated bits=0) by io.ze.tum.de (8.14.5/8.14.5) with ESMTP id t2NDrp6i052129 for ; Mon, 23 Mar 2015 14:53:51 +0100 (CET) (envelope-from estartu@ze.tum.de) Message-ID: <55101AEF.1080003@ze.tum.de> Date: Mon, 23 Mar 2015 14:53:51 +0100 From: Gerhard Schmidt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Problems with openssl 1.0.2 update References: <550FEBE6.5090804@ze.tum.de> <55101285.5000401@sentex.net> In-Reply-To: <55101285.5000401@sentex.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 13:53:54 -0000 On 23.03.2015 14:17, Mike Tancsa wrote: > On 3/23/2015 6:33 AM, Gerhard Schmidt wrote: >> Hi, >> >> we experiencing a problem after upgrading the openssl port to openssl >> 1.0.2. >> >> /usr/bin/vi started to crash after some seconds with segfault. > > Is you vi linked to openssl ? > > /usr/bin/vi: > libutil.so.9 => /lib/libutil.so.9 (0x800883000) > libncursesw.so.8 => /lib/libncursesw.so.8 (0x800a95000) > libc.so.7 => /lib/libc.so.7 (0x800cea000) no but... I was finally able to repoduce this problem on my testserver. The problem is related to nss_ldap or pam_ldap used in the user authentication. The openldap-client, nss_ldap and pam_ldap are linked against the ports openssl lib. vi crashed when I tried to change a file. First change and vi crashes. if i remove ldap from /etc/nsswitch.conf and vi is running just fine. there is definitely a issue with openssl 1.0.2 somewhere Regards Estartu From owner-freebsd-stable@FreeBSD.ORG Mon Mar 23 13:56:10 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EDE21BAC for ; Mon, 23 Mar 2015 13:56:09 +0000 (UTC) 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 79ED2F09 for ; Mon, 23 Mar 2015 13:56:09 +0000 (UTC) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3l9cgK4lMrzZrj; Mon, 23 Mar 2015 14:55:57 +0100 (CET) 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 3Uzu__902JHB; Mon, 23 Mar 2015 14:55:42 +0100 (CET) Received: from marvin.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA; Mon, 23 Mar 2015 14:55:37 +0100 (CET) Message-ID: <55101B58.4070004@FreeBSD.org> Date: Mon, 23 Mar 2015 14:55:36 +0100 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Gerhard Schmidt , freebsd-stable@freebsd.org Subject: Re: Problems with openssl 1.0.2 update References: <550FEBE6.5090804@ze.tum.de> <551009BB.9020906@FreeBSD.org> <55101231.4080205@ze.tum.de> In-Reply-To: <55101231.4080205@ze.tum.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 13:56:10 -0000 On 03/23/15 14:16, Gerhard Schmidt wrote: > On 23.03.2015 13:40, Guido Falsi wrote: >> On 03/23/15 11:33, Gerhard Schmidt wrote: >>> Hi, >>> >>> we experiencing a problem after upgrading the openssl port to openssl >>> 1.0.2. >>> >>> /usr/bin/vi started to crash after some seconds with segfault. >>> /rescue/vi works just fine. Deleting the openssl 1.0.2 package >>> everything works just fine again. Installing the old openssl 1.0.1_18 >>> package it still works just fine. >>> >>> it seams that besides vi the bash also has this problem. Anybody >>> experiencing the same or is this something specific to my system. >>> >>> I'm running FreeBSD 10.1 updated tonight. >> >> I am seeing runtime problems with asterisk13 (which I maintain), caused >> by the OpenSSL update fallout. >> >> In this case, after some analysis, I concluded the problem is the >> libsrtp port requiring OpenSSL from ports(for a reason), causing >> asterisk to link to that too, which would be correct. >> >> Asterisk also uses the security/trousers port, which links to system >> OpenSSL. This ensues a conflict which now results in asterisk >> segfaulting and stopping to work. >> >> I'm investigating what can be done about this. As a local solution I can >> force the trousers port to link against OpenSSL from ports, but this >> will not fix the general problem. As a port maintaner I ony see >> modifying the trousers port to depend on ports OpenSSL as a solution, is >> this acceptable? >> > Most Ports link against the port openssl if its installed and agains the > system openssl if not. That should be the prefered way to handle problem. > Sorry, I forgot to mention this is happening when building in poudriere. in poudriere trousers will be unconditionally linked against base OpenSSL, since nothing will pull in ports openssl when building trousers (and others I'm discovering). When poudriere builds asterisk, it will pull in a dependency bringing OpenSSL from ports and asterisk will link against that, but the binary package for trousers knows nothing and will still depend on base openssl. So, the packages will build fine in most cases, but will fail in unexpected ways at runtime. I can fix this in my system by putting WITH_OPENSSL_PORT=yes in make.conf and link everything against that, but this isn't a viable solution for fixing it on the cluster. > I don't know if an incompatibility between system an port openssl is a > problem. I've removed the portbuild openssl from this server completely. Mostly depends on the port. My fear is there could be other similar problems lurking in binary packages. > > As far as i can see the problem is with openldap-client build agains the > ports openssl and used by nss_ldap or pam_ldap modul. I will do some > testing when my test host is ready. Testing on an Production server is > not that good :-) This is a similar problem. but also involves base, so it's even harder to solve. -- Guido Falsi From owner-freebsd-stable@FreeBSD.ORG Mon Mar 23 14:32:50 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 796B4DE8 for ; Mon, 23 Mar 2015 14:32:50 +0000 (UTC) Received: from hermes.heuristicsystems.com.au (hermes.heuristicsystems.com.au [203.41.22.115]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "hermes.heuristicsystems.com.au", Issuer "Heuristic Systems Type 4 Host CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DD73D64A for ; Mon, 23 Mar 2015 14:32:49 +0000 (UTC) Received: from [10.0.5.3] (ewsw01.hs [10.0.5.3]) (authenticated bits=0) by hermes.heuristicsystems.com.au (8.14.5/8.13.6) with ESMTP id t2NEEwnr086490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 24 Mar 2015 01:15:07 +1100 (EST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Message-ID: <55101FDF.3060308@heuristicsystems.com.au> Date: Tue, 24 Mar 2015 01:14:55 +1100 From: Dewayne Geraghty User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Gerhard Schmidt , freebsd-stable@freebsd.org Subject: Re: Problems with openssl 1.0.2 update References: <550FEBE6.5090804@ze.tum.de> <551009BB.9020906@FreeBSD.org> <55101231.4080205@ze.tum.de> In-Reply-To: <55101231.4080205@ze.tum.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 14:32:50 -0000 On 24/03/2015 12:16 AM, Gerhard Schmidt wrote: > On 23.03.2015 13:40, Guido Falsi wrote: >> On 03/23/15 11:33, Gerhard Schmidt wrote: >>> Hi, >>> >>> we experiencing a problem after upgrading the openssl port to openssl >>> 1.0.2. >>> >>> /usr/bin/vi started to crash after some seconds with segfault. >>> /rescue/vi works just fine. Deleting the openssl 1.0.2 package >>> everything works just fine again. Installing the old openssl 1.0.1_18 >>> package it still works just fine. >>> >>> it seams that besides vi the bash also has this problem. Anybody >>> experiencing the same or is this something specific to my system. >>> >>> I'm running FreeBSD 10.1 updated tonight. >> I am seeing runtime problems with asterisk13 (which I maintain), caused >> by the OpenSSL update fallout. >> >> In this case, after some analysis, I concluded the problem is the >> libsrtp port requiring OpenSSL from ports(for a reason), causing >> asterisk to link to that too, which would be correct. >> >> Asterisk also uses the security/trousers port, which links to system >> OpenSSL. This ensues a conflict which now results in asterisk >> segfaulting and stopping to work. >> >> I'm investigating what can be done about this. As a local solution I can >> force the trousers port to link against OpenSSL from ports, but this >> will not fix the general problem. As a port maintaner I ony see >> modifying the trousers port to depend on ports OpenSSL as a solution, is >> this acceptable? >> > Most Ports link against the port openssl if its installed and agains the > system openssl if not. That should be the prefered way to handle problem. > > I don't know if an incompatibility between system an port openssl is a > problem. I've removed the portbuild openssl from this server completely. > > As far as i can see the problem is with openldap-client build agains the > ports openssl and used by nss_ldap or pam_ldap modul. I will do some > testing when my test host is ready. Testing on an Production server is > not that good :-) > > Regards > Estartu > > I only use openssl from ports and have just completed a rebuild of 662 packages for server requirements and include: trousers, ldap client and server, and 71 other ports built without any issues on amd64 10.1Stable using clang. Not so successful on i386 but I don't believe its related to openssl. My 2c. Regards, Dewayne PS Of the ports I use, only ports-mgmt/pkg and sysutils/monit link against base openssl as they don't provide an option. :( From owner-freebsd-stable@FreeBSD.ORG Mon Mar 23 14:38:13 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D68AF391 for ; Mon, 23 Mar 2015 14:38:13 +0000 (UTC) Received: from io.ze.tum.de (w3projmail.ze.tum.de [129.187.39.2]) (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 729356A4 for ; Mon, 23 Mar 2015 14:38:12 +0000 (UTC) Received: from etustar.ze.tum.de (etustar.ze.tum.de [IPv6:2001:4ca0:2e03::16:1]) (authenticated bits=0) by io.ze.tum.de (8.14.5/8.14.5) with ESMTP id t2NEc9q9070432; Mon, 23 Mar 2015 15:38:09 +0100 (CET) (envelope-from estartu@ze.tum.de) Message-ID: <55102551.5000303@ze.tum.de> Date: Mon, 23 Mar 2015 15:38:09 +0100 From: Gerhard Schmidt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Dewayne Geraghty , freebsd-stable@freebsd.org Subject: Re: Problems with openssl 1.0.2 update References: <550FEBE6.5090804@ze.tum.de> <551009BB.9020906@FreeBSD.org> <55101231.4080205@ze.tum.de> <55101FDF.3060308@heuristicsystems.com.au> In-Reply-To: <55101FDF.3060308@heuristicsystems.com.au> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 14:38:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 23.03.2015 15:14, Dewayne Geraghty wrote: > > > On 24/03/2015 12:16 AM, Gerhard Schmidt wrote: >> On 23.03.2015 13:40, Guido Falsi wrote: >>> On 03/23/15 11:33, Gerhard Schmidt wrote: >>>> Hi, >>>> >>>> we experiencing a problem after upgrading the openssl port to openssl >>>> 1.0.2. >>>> >>>> /usr/bin/vi started to crash after some seconds with segfault. >>>> /rescue/vi works just fine. Deleting the openssl 1.0.2 package >>>> everything works just fine again. Installing the old openssl 1.0.1_18 >>>> package it still works just fine. >>>> >>>> it seams that besides vi the bash also has this problem. Anybody >>>> experiencing the same or is this something specific to my system. >>>> >>>> I'm running FreeBSD 10.1 updated tonight. >>> I am seeing runtime problems with asterisk13 (which I maintain), caused >>> by the OpenSSL update fallout. >>> >>> In this case, after some analysis, I concluded the problem is the >>> libsrtp port requiring OpenSSL from ports(for a reason), causing >>> asterisk to link to that too, which would be correct. >>> >>> Asterisk also uses the security/trousers port, which links to system >>> OpenSSL. This ensues a conflict which now results in asterisk >>> segfaulting and stopping to work. >>> >>> I'm investigating what can be done about this. As a local solution I can >>> force the trousers port to link against OpenSSL from ports, but this >>> will not fix the general problem. As a port maintaner I ony see >>> modifying the trousers port to depend on ports OpenSSL as a solution, is >>> this acceptable? >>> >> Most Ports link against the port openssl if its installed and agains the >> system openssl if not. That should be the prefered way to handle problem. >> >> I don't know if an incompatibility between system an port openssl is a >> problem. I've removed the portbuild openssl from this server completely. >> >> As far as i can see the problem is with openldap-client build agains the >> ports openssl and used by nss_ldap or pam_ldap modul. I will do some >> testing when my test host is ready. Testing on an Production server is >> not that good :-) >> >> Regards >> Estartu >> >> > I only use openssl from ports and have just completed a rebuild of 662 > packages for server requirements and include: trousers, ldap client and > server, and 71 other ports built without any issues on amd64 10.1Stable > using clang. Not so successful on i386 but I don't believe its related > to openssl. I never had an issue building anything. Using it is the problem. Setup authentication via ldap (nss_ldap) and you are in hell. Bash crashes when you try to login. vi crashes when you try to change a file. Anything that uses nsswitch has some problems. Regards Estartu -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVECVNAAoJEHTSQ8xFcA2jj6MP/ifZj6q3sK96ak6KQQezM466 kRC/YuCJymzSv30HbAu2P5i2Qmkaqz/72BCVZ+YhS1n4FBw9TxHrnCI77jO94y9P 55pfvSvYzKk6sLkWEOsbqWjPLQcrTUpfHjWHC3d0uvlzVNnyiYoHGBscWMpIvpoG Jz+yV8NsJEU5Zm4YSRzOd9VM2xaLi+dBSdSmOvWTp77Oa7Rd4vYrDypcPmA2RXa7 cfTU4OBj3XdYgKF0D4E3I0xcqhvlBAgB806oVeWS7xsI3T7X3ZABBWxPf6ErPDOr a3hSjl3ZyRMku+4wSvqclWQ1GCrUh33oP5UELD81nPnci7RCxIGoUo3OiZTXvzy+ Oh12eTmEpZrpYo0QALV8Z2oxhlzWm91/iIYnfx9wr6Hk9EHYyNWlckwndfFGVcC0 bJ6KmnX3CbcxKN6RPYG38bNFJ5X9v2gqsqJFKy98KHhBlJ3O49OBzHLzFsaN7r24 TbUzwPrK3qIntMgQF5Y8uD7a1mkjpcG0H/3iwB4QZnWS9WMiynIQqTow6EeIEBgj 0TMHFWkbPetn9h9kxbF+XWf10ARVr0kH9OrTZ+2iO2B+uQb65gC5qRno/WWHBmCp MSuez+SPv3JIu7ArX9nzpEtG1wQd+r3uiGjX2YB2/kw+a+cX3/B1kWk1R1R1F5Qv /ImcsZjxeR3aNKcDsz9F =TQFs -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Mon Mar 23 14:42:18 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 152DF63C for ; Mon, 23 Mar 2015 14:42:18 +0000 (UTC) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (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 9793B7D7 for ; Mon, 23 Mar 2015 14:42:17 +0000 (UTC) Received: by wibgn9 with SMTP id gn9so64870575wib.1 for ; Mon, 23 Mar 2015 07:42:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lNQ6b8SHQKvdPRvhEqgBwkh7voEe8MveyK+0TdKz3ps=; b=lt+9ucN5udd1jgy0mV2G6VELNaGP8yC3lYejP5PeeM83zaaM3xC8a1Yxns9GN6z+Th FA7yVVoFSr+ndJFWhexyitfgfdKEPvCjFndf0t/SNQ1oSrClkBQXuIELZieoMbJVPI6f CLOh/FBIlNgYTECKMQfchopzs5+DudoQfj9c49spkgyqUpwwDdWDZIW+HfCXqgThUY+y TuiF3nfOlg4m5NmBFOGzOChH9M6htHLLdk7/0KtVAeC+I33Di3PVFRZ1h88BjayUlmGg 0fmK09ogsu+1N+PF+wgGPCsqcUqWuOYo9FgpeQWjYnNe3YTqCyy5W3U6R1WwruTXvjl+ kk0g== X-Gm-Message-State: ALoCoQmbEN3S+9hZtety0tLv6oG4RDXUfu4M51zHsxxqnpELlR3EoqBEdXQmaUHpLCBMdL0ephCX X-Received: by 10.180.108.13 with SMTP id hg13mr19753785wib.7.1427121735250; Mon, 23 Mar 2015 07:42:15 -0700 (PDT) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id vq9sm1713559wjc.6.2015.03.23.07.42.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Mar 2015 07:42:14 -0700 (PDT) Message-ID: <55102641.8010105@multiplay.co.uk> Date: Mon, 23 Mar 2015 14:42:09 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Problems with openssl 1.0.2 update References: <550FEBE6.5090804@ze.tum.de> <551009BB.9020906@FreeBSD.org> <55101231.4080205@ze.tum.de> <55101FDF.3060308@heuristicsystems.com.au> <55102551.5000303@ze.tum.de> In-Reply-To: <55102551.5000303@ze.tum.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 14:42:18 -0000 On 23/03/2015 14:38, Gerhard Schmidt wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 23.03.2015 15:14, Dewayne Geraghty wrote: >> >> On 24/03/2015 12:16 AM, Gerhard Schmidt wrote: >>> On 23.03.2015 13:40, Guido Falsi wrote: >>>> On 03/23/15 11:33, Gerhard Schmidt wrote: >>>>> Hi, >>>>> >>>>> we experiencing a problem after upgrading the openssl port to openssl >>>>> 1.0.2. >>>>> >>>>> /usr/bin/vi started to crash after some seconds with segfault. >>>>> /rescue/vi works just fine. Deleting the openssl 1.0.2 package >>>>> everything works just fine again. Installing the old openssl 1.0.1_18 >>>>> package it still works just fine. >>>>> >>>>> it seams that besides vi the bash also has this problem. Anybody >>>>> experiencing the same or is this something specific to my system. >>>>> >>>>> I'm running FreeBSD 10.1 updated tonight. >>>> I am seeing runtime problems with asterisk13 (which I maintain), caused >>>> by the OpenSSL update fallout. >>>> >>>> In this case, after some analysis, I concluded the problem is the >>>> libsrtp port requiring OpenSSL from ports(for a reason), causing >>>> asterisk to link to that too, which would be correct. >>>> >>>> Asterisk also uses the security/trousers port, which links to system >>>> OpenSSL. This ensues a conflict which now results in asterisk >>>> segfaulting and stopping to work. >>>> >>>> I'm investigating what can be done about this. As a local solution I can >>>> force the trousers port to link against OpenSSL from ports, but this >>>> will not fix the general problem. As a port maintaner I ony see >>>> modifying the trousers port to depend on ports OpenSSL as a solution, is >>>> this acceptable? >>>> >>> Most Ports link against the port openssl if its installed and agains the >>> system openssl if not. That should be the prefered way to handle problem. >>> >>> I don't know if an incompatibility between system an port openssl is a >>> problem. I've removed the portbuild openssl from this server completely. >>> >>> As far as i can see the problem is with openldap-client build agains the >>> ports openssl and used by nss_ldap or pam_ldap modul. I will do some >>> testing when my test host is ready. Testing on an Production server is >>> not that good :-) >>> >>> Regards >>> Estartu >>> >>> >> I only use openssl from ports and have just completed a rebuild of 662 >> packages for server requirements and include: trousers, ldap client and >> server, and 71 other ports built without any issues on amd64 10.1Stable >> using clang. Not so successful on i386 but I don't believe its related >> to openssl. > I never had an issue building anything. Using it is the problem. Setup > authentication via ldap (nss_ldap) and you are in hell. Bash crashes > when you try to login. vi crashes when you try to change a file. > Anything that uses nsswitch has some problems. > Does rebuilding all ports with WITH_OPENSSL_PORT=yes set in /etc/make.conf help? Regards Steve From owner-freebsd-stable@FreeBSD.ORG Mon Mar 23 15:30:16 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E652DC93; Mon, 23 Mar 2015 15:30:16 +0000 (UTC) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by mx1.freebsd.org (Postfix) with ESMTP id E4DA6D63; Mon, 23 Mar 2015 15:30:15 +0000 (UTC) Received: from ppp118-210-45-229.lns20.adl2.internode.on.net (HELO leader.local) ([118.210.45.229]) by ipmail05.adl6.internode.on.net with ESMTP; 24 Mar 2015 01:55:05 +1030 Message-ID: <55103050.6030904@ShaneWare.Biz> Date: Tue, 24 Mar 2015 01:55:04 +1030 From: Shane Ambler User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Andriy Gapon , Hans Petter Selasky , freebsd-stable@FreeBSD.org Subject: Re: Help debugging stable/10 References: <5488F58D.7060708@ShaneWare.Biz> <201412161129.57704.jhb@freebsd.org> <549BC924.3050402@ShaneWare.Biz> <549BD90B.2050000@selasky.org> <549C042D.3090108@FreeBSD.org> In-Reply-To: <549C042D.3090108@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 15:30:17 -0000 On 25/12/2014 23:03, Andriy Gapon wrote: > On 25/12/2014 11:29, Hans Petter Selasky wrote: >> The cam_sim_free() is stuck, blocking the rest of that controller from >> enumerating. It might look like a non-USB stack issue. >> >> MAV: Do you have some ideas where to start looking, now we have a dump? Any >> refcounts to check in particular? > > Apparently sim->refcount > 0. > Not sure how to check who has the reference(s). > I am now running FreeBSD leader.local 10.1-STABLE FreeBSD 10.1-STABLE #4 r279865: Thu Mar 12 14:25:28 ACDT 2015 root@leader.local:/usr/obj/usr/src/sys /GENERIC amd64 I have just tried running with a custom kernel, GENERIC plus DDB GDB DEADLKRES INVARIANTS INVARIANT_SUPPORT WITNESS WITNESS_SKIPSPIN When starting Xorg I got a duplicate lock message coming from nvidia, after running for maybe 20 mins it just reset without warning. I then decided to go back to the GENERIC kernel and on restarting I got some lock reversal messages. nvidia-driver-346.47 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io vgapci0: Boot video device hdac0: mem 0xfb080000-0xfb083fff irq 17 at device 0.1 on pci1 Full dmesg and other kgdb outputs I have collected are at - http://shaneware.biz/freebsddebugdata/ Trying to mount root from zfs:zrpleader []... ums0: on usbus2 ums0: 3 buttons and [XYZ] coordinates ID=0 ums1: on usbus2 ums1: 6 buttons and [XY] coordinates ID=1 uhid0: on usbus2 uhid1: on usbus2 uhid0: at uhub5, port 2, addr 5 (disconnected) ums1: at uhub5, port 2, addr 5 (disconnected) ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to deny, logging disabled acquiring duplicate lock of same type: "os.lock_sx" 1st os.lock_sx @ nvidia_os.c:609 2nd os.lock_sx @ nvidia_os.c:609 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0238b8d400 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe0238b8d4b0 witness_checkorder() at witness_checkorder+0xdc2/frame 0xfffffe0238b8d540 _sx_xlock() at _sx_xlock+0x75/frame 0xfffffe0238b8d580 os_acquire_mutex() at os_acquire_mutex+0x32/frame 0xfffffe0238b8d5a0 _nv010785rm() at _nv010785rm+0x18/frame 0xfffffe000f2fee90 dmapbase() at 0xfffff8001cc40e80/frame 0xfffff8001cc40e18 kernphys() at 0xc1d00001/frame 0xfffff8001cc40e00 (null)() at 0xfffffe0000c5e000/frame 0xc1d0000100000001 acquiring duplicate lock of same type: "os.lock_mtx" 1st os.lock_mtx @ nvidia_os.c:783 2nd os.lock_mtx @ nvidia_os.c:783 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0238b8d0e0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe0238b8d190 witness_checkorder() at witness_checkorder+0xdc2/frame 0xfffffe0238b8d220 __mtx_lock_flags() at __mtx_lock_flags+0xa8/frame 0xfffffe0238b8d270 os_acquire_spinlock() at os_acquire_spinlock+0x1b/frame 0xfffffe0238b8d280 _nv012385rm() at _nv012385rm+0xd75/frame 0xfffffe0000bceef0 pid 3568 (gsettings-data-conv), uid 1001: exited on signal 5 Mar 24 00:24:25 leader kernel: Waiting (max 60 seconds) for system process `vnlru' to stop...done Mar 24 00:24:25 leader kernel: Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Mar 24 00:24:25 leader kernel: Waiting (max 60 seconds) for system process `syncer' to stop... Mar 24 00:24:25 leader kernel: Syncing disks, vnodes remaining...0 0 0 0 0 0 0 0 done Mar 24 00:24:25 leader kernel: All buffers synced. Mar 24 00:24:25 leader kernel: lock order reversal: Mar 24 00:24:25 leader kernel: 1st 0xfffff800224555f0 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1229 Mar 24 00:24:25 leader kernel: 2nd 0xfffff800222d67c8 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2268 Mar 24 00:24:25 leader kernel: KDB: stack backtrace: Mar 24 00:24:25 leader kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe022df6e4c0 Mar 24 00:24:25 leader kernel: kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe022df6e570 Mar 24 00:24:25 leader kernel: witness_checkorder() at witness_checkorder+0xdc2/frame 0xfffffe022df6e600 Mar 24 00:24:25 leader kernel: __lockmgr_args() at __lockmgr_args+0x9ea/frame 0xfffffe022df6e740 Mar 24 00:24:25 leader kernel: vop_stdlock() at vop_stdlock+0x3c/frame 0xfffffe022df6e760 Mar 24 00:24:25 leader kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfffffe022df6e790 Mar 24 00:24:25 leader kernel: _vn_lock() at _vn_lock+0xaa/frame 0xfffffe022df6e800 Mar 24 00:24:25 leader kernel: vputx() at vputx+0x232/frame 0xfffffe022df6e860 Mar 24 00:24:25 leader kernel: dounmount() at dounmount+0x301/frame 0xfffffe022df6e8e0 Mar 24 00:24:25 leader kernel: vfs_unmountall() at vfs_unmountall+0x61/frame 0xfffffe022df6e910 Mar 24 00:24:25 leader kernel: kern_reboot() at kern_reboot+0x540/frame 0xfffffe022df6e980 Mar 24 00:24:25 leader kernel: sys_reboot() at sys_reboot+0x5a/frame 0xfffffe022df6e9a0 Mar 24 00:24:25 leader kernel: amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe022df6eab0 Mar 24 00:24:25 leader kernel: Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe022df6eab0 Mar 24 00:24:25 leader kernel: --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x40f1bc, rsp = 0x7fffffffe6d8, rbp = 0x7fffffffe7d0 --- Mar 24 00:24:25 leader kernel: lock order reversal: Mar 24 00:24:25 leader kernel: 1st 0xfffff800222d6b78 zfs (zfs) @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1814 Mar 24 00:24:25 leader kernel: 2nd 0xffffffff818514a8 allproc (allproc) @ /usr/src/sys/kern/kern_descrip.c:2872 Mar 24 00:24:25 leader kernel: KDB: stack backtrace: Mar 24 00:24:25 leader kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe022df6e690 Mar 24 00:24:25 leader kernel: kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe022df6e740 Mar 24 00:24:25 leader kernel: witness_checkorder() at witness_checkorder+0xdc2/frame 0xfffffe022df6e7d0 Mar 24 00:24:25 leader kernel: _sx_slock() at _sx_slock+0x76/frame 0xfffffe022df6e810 Mar 24 00:24:25 leader kernel: mountcheckdirs() at mountcheckdirs+0x47/frame 0xfffffe022df6e860 Mar 24 00:24:25 leader kernel: dounmount() at dounmount+0x36f/frame 0xfffffe022df6e8e0 Mar 24 00:24:25 leader kernel: vfs_unmountall() at vfs_unmountall+0x61/frame 0xfffffe022df6e910 Mar 24 00:24:25 leader kernel: kern_reboot() at kern_reboot+0x540/frame 0xfffffe022df6e980 Mar 24 00:24:25 leader kernel: sys_reboot() at sys_reboot+0x5a/frame 0xfffffe022df6e9a0 Mar 24 00:24:25 leader kernel: amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe022df6eab0 Mar 24 00:24:25 leader kernel: Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe022df6eab0 Mar 24 00:24:25 leader kernel: --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x40f1bc, rsp = 0x7fffffffe6d8, rbp = 0x7fffffffe7d0 --- Mar 24 00:24:25 leader kernel: lock order reversal: Mar 24 00:24:25 leader kernel: 1st 0xfffff8001ca8e240 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1229 Mar 24 00:24:25 leader kernel: 2nd 0xfffff8001ca8e5f0 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2157 Mar 24 00:24:25 leader kernel: KDB: stack backtrace: Mar 24 00:24:25 leader kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe022df6e460 Mar 24 00:24:25 leader kernel: kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe022df6e510 Mar 24 00:24:25 leader kernel: witness_checkorder() at witness_checkorder+0xdc2/frame 0xfffffe022df6e5a0 Mar 24 00:24:25 leader kernel: __lockmgr_args() at __lockmgr_args+0x9ea/frame 0xfffffe022df6e6e0 Mar 24 00:24:25 leader kernel: vop_stdlock() at vop_stdlock+0x3c/frame 0xfffffe022df6e700 Mar 24 00:24:25 leader kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfffffe022df6e730 Mar 24 00:24:25 leader kernel: _vn_lock() at _vn_lock+0xaa/frame 0xfffffe022df6e7a0 Mar 24 00:24:25 leader kernel: vget() at vget+0x67/frame 0xfffffe022df6e7e0 Mar 24 00:24:25 leader kernel: devfs_allocv() at devfs_allocv+0xfd/frame 0xfffffe022df6e830 Mar 24 00:24:25 leader kernel: devfs_root() at devfs_root+0x43/frame 0xfffffe022df6e860 Mar 24 00:24:25 leader kernel: dounmount() at dounmount+0x345/frame 0xfffffe022df6e8e0 Mar 24 00:24:25 leader kernel: vfs_unmountall() at vfs_unmountall+0x61/frame 0xfffffe022df6e910 Mar 24 00:24:25 leader kernel: kern_reboot() at kern_reboot+0x540/frame 0xfffffe022df6e980 Mar 24 00:24:25 leader kernel: sys_reboot() at sys_reboot+0x5a/frame 0xfffffe022df6e9a0 Mar 24 00:24:25 leader kernel: amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe022df6eab0 Mar 24 00:24:25 leader kernel: Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe022df6eab0 Mar 24 00:24:25 leader kernel: --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x40f1bc, rsp = 0x7fffffffe6d8, rbp = 0x7fffffffe7d0 --- Mar 24 00:24:25 leader kernel: Uptime: 12m42s -- FreeBSD - the place to B...Software Developing Shane Ambler From owner-freebsd-stable@FreeBSD.ORG Mon Mar 23 15:57:23 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9F6E2CBF; Mon, 23 Mar 2015 15:57:23 +0000 (UTC) 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 5D1E7169; Mon, 23 Mar 2015 15:57:23 +0000 (UTC) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3l9gMB6R0CzZrj; Mon, 23 Mar 2015 16:57:10 +0100 (CET) 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 vqOOHdf4viqh; Mon, 23 Mar 2015 16:56:55 +0100 (CET) Received: from marvin.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA; Mon, 23 Mar 2015 16:56:50 +0100 (CET) Message-ID: <551037C2.9020507@FreeBSD.org> Date: Mon, 23 Mar 2015 16:56:50 +0100 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org, FreeBSD Ports Subject: Re: Problems with openssl 1.0.2 update References: <550FEBE6.5090804@ze.tum.de> <551009BB.9020906@FreeBSD.org> In-Reply-To: <551009BB.9020906@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 15:57:23 -0000 On 03/23/15 13:40, Guido Falsi wrote: > On 03/23/15 11:33, Gerhard Schmidt wrote: >> Hi, >> >> we experiencing a problem after upgrading the openssl port to openssl >> 1.0.2. >> >> /usr/bin/vi started to crash after some seconds with segfault. >> /rescue/vi works just fine. Deleting the openssl 1.0.2 package >> everything works just fine again. Installing the old openssl 1.0.1_18 >> package it still works just fine. >> >> it seams that besides vi the bash also has this problem. Anybody >> experiencing the same or is this something specific to my system. >> >> I'm running FreeBSD 10.1 updated tonight. > > I am seeing runtime problems with asterisk13 (which I maintain), caused > by the OpenSSL update fallout. > > In this case, after some analysis, I concluded the problem is the > libsrtp port requiring OpenSSL from ports(for a reason), causing > asterisk to link to that too, which would be correct. > > Asterisk also uses the security/trousers port, which links to system > OpenSSL. This ensues a conflict which now results in asterisk > segfaulting and stopping to work. > > I'm investigating what can be done about this. As a local solution I can > force the trousers port to link against OpenSSL from ports, but this > will not fix the general problem. As a port maintaner I ony see > modifying the trousers port to depend on ports OpenSSL as a solution, is > this acceptable? > Quick followup to keep anyone interested informed(and for ML archives just in case). The only "fix" I could commit to fix the binary package was removing the SRTP option from the defaults, avoiding to pull in the libsrtp port which itself pulled in OpenSSL from ports, causing the library mix. I'm not proud of such a solution, but was unable to do anything better right away. If someone has a better solution, please send patches. So for now anyone wanting to use SRTP with asterisk will have to build his own packages. :( -- Guido Falsi From owner-freebsd-stable@FreeBSD.ORG Mon Mar 23 16:41:29 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF5FCE95 for ; Mon, 23 Mar 2015 16:41:29 +0000 (UTC) Received: from mail-in-3.serv.Uni-Osnabrueck.DE (vm299.rz.uni-osnabrueck.de [131.173.16.215]) (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 39E60843 for ; Mon, 23 Mar 2015 16:41:28 +0000 (UTC) Received: from smtp-auth.serv.Uni-Osnabrueck.DE (vm136.rz.uni-osnabrueck.de [131.173.16.11]) by mail-in-3.serv.Uni-Osnabrueck.DE (8.14.4/8.14.4) with ESMTP id t2NGKYKS020818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Mar 2015 17:20:34 +0100 Received: from spock.drpetervoigt.private (p5DC4C6B6.dip0.t-ipconnect.de [93.196.198.182]) (authenticated bits=0) by smtp-auth.serv.Uni-Osnabrueck.DE (8.13.8/8.13.8) with ESMTP id t2NGKWOb028936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Mar 2015 17:20:33 +0100 Received: from kirk.drpetervoigt.private (kirk.drpetervoigt.private [192.168.1.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: pvoigt) by spock.drpetervoigt.private (Postfix) with ESMTPSA id 09CB54A03406 for ; Mon, 23 Mar 2015 17:20:31 +0100 (CET) Date: Mon, 23 Mar 2015 17:20:23 +0100 From: "Dr. Peter Voigt" To: freebsd-stable@freebsd.org Subject: Re: Problems with openssl 1.0.2 update Message-ID: <20150323172023.682e6c22@kirk.drpetervoigt.private> In-Reply-To: <20150323110433.GA62590@home.opsec.eu> References: <550FEBE6.5090804@ze.tum.de> <20150323110433.GA62590@home.opsec.eu> Organization: =?UTF-8?B?VW5pdmVyc2l0w6R0IE9zbmFicsO8Y2s=?= X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.23; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.3.23.160925 (Univ. Osnabrueck) X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report= EU_TLD 0.1, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, BODY_SIZE_700_799 0, FROM_NAME_PHRASE 0, RDNS_POOLED 0, RDNS_SUSP 0, RDNS_SUSP_SPECIFIC 0, REFERENCES 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __RDNS_POOLED_10 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __URI_NS X-PMX-Spam-Level: IIIIIIII X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 16:41:29 -0000 On Mon, 23 Mar 2015 12:04:33 +0100 Kurt Jaeger wrote: > Hi! > > > we experiencing a problem after upgrading the openssl port to > > openssl 1.0.2. > > I have 1.0.2 installed on my testbox. > > vi works fine. > > > /usr/bin/vi started to crash after some seconds with segfault. > > Do you have a coredump ? > Do you use openldap authentication? I do. I could even rebuild all ports depending on openssl - with the exception of postfix. I found that disabling openldap support for postfix sovled this. But after some time I found lots of programs and services core dumping - including vim and base vi. As I was not sure what and how to downgrade I restored my UFS2 root partition from a 24 h old dump. Regards, Peter From owner-freebsd-stable@FreeBSD.ORG Mon Mar 23 16:54:54 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6AF3E73A; Mon, 23 Mar 2015 16:54:54 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 59039A38; Mon, 23 Mar 2015 16:54:54 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 92917944; Mon, 23 Mar 2015 16:54:54 +0000 (UTC) Date: Mon, 23 Mar 2015 16:54:53 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-stable@freebsd.org, mav@FreeBSD.org, kib@FreeBSD.org Message-ID: <518236959.20.1427129694364.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1556030941.19.1427116599138.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1556030941.19.1427116599138.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_stable_10 #1303 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 16:54:54 -0000 See From owner-freebsd-stable@FreeBSD.ORG Mon Mar 23 19:32:35 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A7DEB1B1 for ; Mon, 23 Mar 2015 19:32:35 +0000 (UTC) Received: from sender1.zohomail.com (sender1.zohomail.com [74.201.84.155]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 93DA0C5 for ; Mon, 23 Mar 2015 19:32:35 +0000 (UTC) Received: from WorkBox.Home (67-4-199-120.mpls.qwest.net [67.4.199.120]) by mx.zohomail.com with SMTPS id 1427139152481898.4973626618728; Mon, 23 Mar 2015 12:32:32 -0700 (PDT) Date: Mon, 23 Mar 2015 14:32:29 -0500 From: Bigby James To: freebsd-stable@freebsd.org Subject: Re: On-going laptop brightness issues Message-ID: <20150323193229.GB4399@WorkBox.Home> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 19:32:35 -0000 I just saw that this feature got MFC'd in revision r280369 this afternoon. I've been keeping an eye on it, as it's pretty much the only feature that hasn't worked properly on my laptop and so the last remaining bit I needed for the "Golden FreeBSD Experience." I want to give my thanks to the developers involved, as well as to Kevin, who's been following this longer---and done more about it---than I have. Just another reason to love this OS, its community and its hard-working contributors. I've yet to update my systems in response to the OpenSSL security advisory, so I'll back up my local source tree and start with a clean pull this evening, and check back in a few days to report how things are working. Thanks again, all. Take care. -- "A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools." - Douglas Adams From owner-freebsd-stable@FreeBSD.ORG Mon Mar 23 22:26:14 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EED6E2CD for ; Mon, 23 Mar 2015 22:26:14 +0000 (UTC) Received: from mail.xtaz.uk (tao.xtaz.uk [IPv6:2001:8b0:202::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B06D9877 for ; Mon, 23 Mar 2015 22:26:14 +0000 (UTC) Received: by mail.xtaz.uk (Postfix, from userid 1001) id A8D14209B03D; Mon, 23 Mar 2015 22:26:10 +0000 (GMT) Date: Mon, 23 Mar 2015 22:26:10 +0000 From: Matt Smith To: Gerhard Schmidt , freebsd-stable@freebsd.org Subject: Re: Problems with openssl 1.0.2 update Message-ID: <20150323222610.GB1258@xtaz.uk> Mail-Followup-To: Matt Smith , Gerhard Schmidt , freebsd-stable@freebsd.org References: <550FEBE6.5090804@ze.tum.de> <20150323113632.GA1258@xtaz.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20150323113632.GA1258@xtaz.uk> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 22:26:15 -0000 On Mar 23 11:36, Matt Smith wrote: >On Mar 23 11:33, Gerhard Schmidt wrote: >>Hi, >> >>we experiencing a problem after upgrading the openssl port to openssl >>1.0.2. >> >>/usr/bin/vi started to crash after some seconds with segfault. >>/rescue/vi works just fine. Deleting the openssl 1.0.2 package >>everything works just fine again. Installing the old openssl 1.0.1_18 >>package it still works just fine. >> >>it seams that besides vi the bash also has this problem. Anybody >>experiencing the same or is this something specific to my system. >> >>I'm running FreeBSD 10.1 updated tonight. >> > >There is definitely something not right. See this too https://forums.freebsd.org/threads/postfix-does-not-start-build-anymore-since-upgrade-to-openssl-1-0-2.50959/ > >I haven't had a chance yet to test it again in more detail, but >someone reported that postfix was broken, and I had PHP-FPM racing and >taking up 50+ load average on my box which I guess was probably nginx >hitting it with tons of requests. Mine is 10.1-STABLE amd64. > I've just reinstalled openssl 1.0.2, and recompiled all ports that link to openssl. And I'm still getting huge problems. PHP-FPM races and starts loads of processes and uses 50+ load average making the machine unresponsive. And trying to run a /bin/sh shell script gives this: sh: environment corrupt; missing value for USERNAME This is clearly very dangerous and broken. Backing out to openssl 1.0.1 fixes everything. -- Matt From owner-freebsd-stable@FreeBSD.ORG Tue Mar 24 00:14:11 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1BA8FAC7 for ; Tue, 24 Mar 2015 00:14:11 +0000 (UTC) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::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 D8E5963C for ; Tue, 24 Mar 2015 00:14:10 +0000 (UTC) Received: by pdbop1 with SMTP id op1so202981858pdb.2 for ; Mon, 23 Mar 2015 17:14:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:reply-to:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=JhqiUA+8W7T/WmeHPTWcEYgZ/ZnWv2v+MJ7MrS2EWDo=; b=Nwu5TF+hpUPqAYRPdWSGCOXaRoQFUKupKpyNRgtd1T2A/KNrk1xEIUKIP8MVHRvDGI SRbSkoyMSa4SGQWcvarvUs9Dl/wYzCmevQYIOLIM5g2/vPZkZz/tCA+1/XZ6hyPoDNe6 g73cvzpbjXXzLyUz9fPupLxih+ntPka45K9+nqXXEhkm1OtKluTgQuMsWhvDEezCfpq0 /3o53caRrEmrUND+1hHQw8cU0rBxy+r9d5iosOlhJINsUjdEXmfXPF+rcj0LclndGULc PDRziC0bQP6bxN4ZfyGXcTYIgnKxlAMXbziqsS/9HGgzJj3AfOG7c7lYDXGb9lzJHr4k PeBQ== X-Received: by 10.66.146.6 with SMTP id sy6mr2732225pab.150.1427156050389; Mon, 23 Mar 2015 17:14:10 -0700 (PDT) Received: from [192.168.1.104] (ppp59-167-128-11.static.internode.on.net. [59.167.128.11]) by mx.google.com with ESMTPSA id or3sm2208752pdb.15.2015.03.23.17.14.08 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Mar 2015 17:14:09 -0700 (PDT) Sender: Kubilay Kocak Reply-To: koobs@FreeBSD.org Subject: Re: Problems with openssl 1.0.2 update references: <550FEBE6.5090804@ze.tum.de> <55101285.5000401@sentex.net> <55101AEF.1080003@ze.tum.de> To: Gerhard Schmidt , freebsd-stable@freebsd.org From: Kubilay Kocak message-id: <5510AC4B.8020000@FreeBSD.org> Date: Tue, 24 Mar 2015 11:14:03 +1100 user-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Thunderbird/37.0 mime-version: 1.0 in-reply-to: <55101AEF.1080003@ze.tum.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 00:14:11 -0000 On 24/03/2015 12:53 AM, Gerhard Schmidt wrote: > On 23.03.2015 14:17, Mike Tancsa wrote: >> On 3/23/2015 6:33 AM, Gerhard Schmidt wrote: >>> Hi, >>> >>> we experiencing a problem after upgrading the openssl port to openssl >>> 1.0.2. >>> >>> /usr/bin/vi started to crash after some seconds with segfault. >> >> Is you vi linked to openssl ? >> Let's get this into an issue report @ Bugzilla Please add this mailing lists threads URL to the issue report in the URL field as well Koobs From owner-freebsd-stable@FreeBSD.ORG Tue Mar 24 00:44:44 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4AC30507; Tue, 24 Mar 2015 00:44:44 +0000 (UTC) Received: from smtp-auth.serv.Uni-Osnabrueck.DE (vm135.rz.uni-osnabrueck.de [131.173.16.10]) (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 BCC6396D; Tue, 24 Mar 2015 00:44:42 +0000 (UTC) Received: from spock.drpetervoigt.private (p549B4469.dip0.t-ipconnect.de [84.155.68.105]) (authenticated bits=0) by smtp-auth.serv.Uni-Osnabrueck.DE (8.13.8/8.13.8) with ESMTP id t2O0iWwv015021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2015 01:44:33 +0100 Received: from kirk.drpetervoigt.private (kirk.drpetervoigt.private [192.168.1.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: pvoigt) by spock.drpetervoigt.private (Postfix) with ESMTPSA id C93774A03389; Tue, 24 Mar 2015 01:44:31 +0100 (CET) Date: Tue, 24 Mar 2015 01:44:27 +0100 From: "Dr. Peter Voigt" To: freebsd-stable@freebsd.org Subject: Re: Problems with openssl 1.0.2 update Message-ID: <20150324014427.438113ca@kirk.drpetervoigt.private> In-Reply-To: <5510AC4B.8020000@FreeBSD.org> References: <550FEBE6.5090804@ze.tum.de> <55101285.5000401@sentex.net> <55101AEF.1080003@ze.tum.de> <5510AC4B.8020000@FreeBSD.org> Organization: =?UTF-8?B?VW5pdmVyc2l0w6R0IE9zbmFicsO8Y2s=?= X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.23; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.3.23.233040 (Univ. Osnabrueck) X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report= HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, BODY_SIZE_900_999 0, FROM_NAME_PHRASE 0, RDNS_POOLED 0, RDNS_SUSP 0, RDNS_SUSP_SPECIFIC 0, REFERENCES 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CANPHARM_UNSUB_LINK 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __RDNS_POOLED_10 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_WWW 0, __URI_NS X-PMX-Spam-Level: IIIIIIII Cc: koobs@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 00:44:44 -0000 On Tue, 24 Mar 2015 11:14:03 +1100 Kubilay Kocak wrote: > On 24/03/2015 12:53 AM, Gerhard Schmidt wrote: > > On 23.03.2015 14:17, Mike Tancsa wrote: > >> On 3/23/2015 6:33 AM, Gerhard Schmidt wrote: > >>> Hi, > >>> > >>> we experiencing a problem after upgrading the openssl port to > >>> openssl 1.0.2. > >>> > >>> /usr/bin/vi started to crash after some seconds with segfault. > >> > >> Is you vi linked to openssl ? > >> > > Let's get this into an issue report @ Bugzilla > > Please add this mailing lists threads URL to the issue report in the > URL field as well > > Koobs > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org" Well, I have added already PR 198788 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198788 From owner-freebsd-stable@FreeBSD.ORG Tue Mar 24 23:26:10 2015 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B6EDBC5A; Tue, 24 Mar 2015 23:26:10 +0000 (UTC) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx2.freebsd.org (Postfix) with ESMTP id 0C483E5B; Tue, 24 Mar 2015 23:26:09 +0000 (UTC) Message-ID: <5511F291.3070202@FreeBSD.org> Date: Tue, 24 Mar 2015 19:26:09 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Konstantin Belousov , Mike Tancsa Subject: Re: RELENG_10 performance regression (was Re: 35-40% performance drop releng9 vs releng10 openvpn References: <5509D6C6.4050204@sentex.net> <20150318211457.GL51048@funkthat.com> <550B6950.8060806@sentex.net> <550C5AAF.9060502@sentex.net> <550C8AEE.4090408@sentex.net> <550CB306.7030405@delphij.net> <20150321001559.GB2379@kib.kiev.ua> <550CBF80.6030809@sentex.net> <550D93C7.9080709@FreeBSD.org> <550DB4B2.7080603@sentex.net> <20150321184238.GO2379@kib.kiev.ua> In-Reply-To: <20150321184238.GO2379@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: FreeBSD-STABLE Mailing List , John-Mark Gurney , d@delphij.net, John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 23:26:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/21/2015 14:42, Konstantin Belousov wrote: > It seems to be a consequnce of the code from r222869. The > test_tsc() does not trust the P-state invariant report and > explicitely check for the family. Your CPU family is 0x14, while > code only bumps TSC priority for family 0x15+. We need to find out whether the Bobcat cores have well-synchronized TSCs. If it does, we can white-list it, too. However, I doubt it. Sorry for the late response, Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVEfKMAAoJEHyflib82/FGZUgH/RZ8LBBeW2ue+0SIJj8Er9Ni uyEA3KJL7ZmdjuGUtOdDl3s3cwHcTxbKN39rdabjOyJy/OoNnJK3GfL8UgYSpERa ztdHHNLbxJK9Z3iN7rvjXxQMHBJy3D4LIQ9BXFau3xcO7K8WDXqdHjUZx/ujrSpU WwDoZRFohvUf2FT1J23NfWBOx0Mnls3PrQm4f6YLhVst6RojDgx8XA24LyIm+AkF WUZcPttydp9nde1Hc7qyFI5qB3ZMhT1tG9jp+J2jQWeqCn/SPR3VymF+Lyz/T0sC POEa6NTJf4lWXOHRZ21Fdkrtr1hBltdO1FImX9M2iNlyRwz57UsNW6yJawGhYJA= =w6Hk -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Wed Mar 25 04:56:48 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD7D2FD0 for ; Wed, 25 Mar 2015 04:56:48 +0000 (UTC) Received: from roadkill.tharned.org (roadkill.tharned.org [75.145.12.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 71F2B112 for ; Wed, 25 Mar 2015 04:56:47 +0000 (UTC) Received: from angus.tharned.org (angus.tharned.org [10.10.10.7]) (authenticated bits=0) by roadkill.tharned.org (8.14.9/8.14.9) with ESMTP id t2P4uZtA018670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 24 Mar 2015 23:56:41 -0500 (CDT) (envelope-from gcr+freebsd-stable@tharned.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tharned.org; s=2014; t=1427259401; bh=2me0idbDly8dSSBF59CLfHQc10OrgER1/E8VKIgCgZg=; h=Date:From:To:Subject; b=n0mZLgeAerOBELhKKTNS7nk+j/7XfD6ghN0ifbZYblERyXkouNllpZZnN1S9zAgfJ XjoXgZKh01Pzm2bjqW2rsRYj+mcTACHS17ONFhciw0V1lR3JrnQxOkiBfAwXMlliav 8UALseA8hHw4PQ1QAoJovQtHisOFhhnfvl0tSboeVvOoCENIx6575Axk9BAjUqfowm TzaBp716n35EOsv3PKuNTk5L8FwXxAXs65gMnzpt2DwKzdLLDs+jS6TQWyBI4XR70S IMpVxXBibV+0K0iHu7fjlhlMTm2dsROU/5ywcd1cz02BCBwYfly21TVp1PoxOqalWB mgCvSeHMPO3Aw== Date: Tue, 24 Mar 2015 23:56:34 -0500 (CDT) From: Greg Rivers To: freebsd-stable@freebsd.org Subject: Booting from ZFS Message-ID: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (roadkill.tharned.org [75.145.12.185]); Tue, 24 Mar 2015 23:56:41 -0500 (CDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 04:56:48 -0000 I'm trying to build a bootable ZFS system on a USB drive. Using the procedure below results in the following error when I try to boot: gptzfsboot: error 66 LBA 48 gptzfsboot: error 66 LBA 1 gptzfsboot: No ZFS pools located, can't boot I'm using the dist files from the latest STABLE snapshot on a system running 10.1-STABLE r279968 amd64. I've tried it with and without file system compression. I found a similar report[1] in the FreeBSD Forums, but there was no conclusion to that posting. What am I doing wrong? [1] https://forums.freebsd.org/threads/freebsd-10-w-fresh-root-on-zfs-fails-to-boot.47651/#post-266106 --------------------------------------------------------------------------- #!/bin/ksh set -x -e DISK=diskid/DISK-4C530009730530116424 TMPDIR=/mnt gpart destroy -F ${DISK} || : gpart create -s GPT ${DISK} gpart add -a 4k -s 512k -t freebsd-boot ${DISK} # p1 gpart add -a 4k -s 1g -t freebsd-swap ${DISK} # p2 gpart add -a 4k -t freebsd-zfs ${DISK} # p3 gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ${DISK} sysctl vfs.zfs.min_auto_ashift=12 zpool create -o altroot=${TMPDIR} -m none -f syspool ${DISK}p3 zfs create -o mountpoint=none syspool/ROOT zfs create -o mountpoint=/ -o compression=lz4 syspool/ROOT/default zpool set bootfs=syspool/ROOT/default syspool zfs create -o mountpoint=/var -o compression=lz4 syspool/var zfs create -o mountpoint=/usr -o compression=lz4 syspool/usr zfs create -o mountpoint=/home -o compression=lz4 syspool/home for DIST in base kernel lib32 games doc do fetch -o - ftp://ftp.freebsd.com/pub/FreeBSD/snapshots/amd64/amd64/10.1-STABLE/${DIST}.txz | tar -C ${TMPDIR} -x -f - done cat <<\! >${TMPDIR}/boot/loader.conf zfs_load="YES" ! cat <<\! >${TMPDIR}/etc/rc.conf zfs_enable="YES" ! cat <<\! >${TMPDIR}/etc/fstab # Device Mountpoint FStype Options Dump Pass# /dev/da0p2 none swap sw 0 0 tmpfs /tmp tmpfs rw 0 0 procfs /proc procfs rw 0 0 fdescfs /dev/fd fdescfs rw 0 0 ! zpool export syspool --------------------------------------------------------------------------- -- Greg Rivers From owner-freebsd-stable@FreeBSD.ORG Wed Mar 25 09:56:44 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E5DA9D1 for ; Wed, 25 Mar 2015 09:56:44 +0000 (UTC) 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 D9D911DD for ; Wed, 25 Mar 2015 09:56:43 +0000 (UTC) Received: from [194.32.164.24] (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id t2P9p7ZP032502; Wed, 25 Mar 2015 09:51:07 GMT (envelope-from rb@gid.co.uk) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: Booting from ZFS From: Bob Bishop In-Reply-To: Date: Wed, 25 Mar 2015 09:51:02 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Greg Rivers X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 09:56:44 -0000 Hi, > On 25 Mar 2015, at 04:56, Greg Rivers = wrote: >=20 > I'm trying to build a bootable ZFS system on a USB drive. Using the = procedure below results in the following error when I try to boot: >=20 > gptzfsboot: error 66 LBA 48 > gptzfsboot: error 66 LBA 1 > gptzfsboot: No ZFS pools located, can't boot Presumably gptzfsboot relies on the BIOS mapping the USB device into a = DOS device. Do you have that support turned on in the BIOS? > I'm using the dist files from the latest STABLE snapshot on a system = running 10.1-STABLE r279968 amd64. I've tried it with and without file = system compression. I found a similar report[1] in the FreeBSD Forums, = but there was no conclusion to that posting. >=20 > What am I doing wrong? >=20 > [1] = https://forums.freebsd.org/threads/freebsd-10-w-fresh-root-on-zfs-fails-to= -boot.47651/#post-266106 > = --------------------------------------------------------------------------= - > #!/bin/ksh > set -x -e >=20 > DISK=3Ddiskid/DISK-4C530009730530116424 > TMPDIR=3D/mnt >=20 > gpart destroy -F ${DISK} || : > gpart create -s GPT ${DISK} > gpart add -a 4k -s 512k -t freebsd-boot ${DISK} # p1 > gpart add -a 4k -s 1g -t freebsd-swap ${DISK} # p2 > gpart add -a 4k -t freebsd-zfs ${DISK} # p3 > gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ${DISK} >=20 > sysctl vfs.zfs.min_auto_ashift=3D12 > zpool create -o altroot=3D${TMPDIR} -m none -f syspool ${DISK}p3 > zfs create -o mountpoint=3Dnone syspool/ROOT > zfs create -o mountpoint=3D/ -o compression=3Dlz4 syspool/ROOT/default > zpool set bootfs=3Dsyspool/ROOT/default syspool > zfs create -o mountpoint=3D/var -o compression=3Dlz4 syspool/var > zfs create -o mountpoint=3D/usr -o compression=3Dlz4 syspool/usr > zfs create -o mountpoint=3D/home -o compression=3Dlz4 syspool/home >=20 > for DIST in base kernel lib32 games doc > do > fetch -o - = ftp://ftp.freebsd.com/pub/FreeBSD/snapshots/amd64/amd64/10.1-STABLE/${DIST= }.txz | tar -C ${TMPDIR} -x -f - > done >=20 > cat <<\! >${TMPDIR}/boot/loader.conf > zfs_load=3D"YES" > ! > cat <<\! >${TMPDIR}/etc/rc.conf > zfs_enable=3D"YES" > ! > cat <<\! >${TMPDIR}/etc/fstab > # Device Mountpoint FStype Options Dump Pass# > /dev/da0p2 none swap sw 0 0 > tmpfs /tmp tmpfs rw 0 0 > procfs /proc procfs rw 0 = 0 > fdescfs /dev/fd fdescfs rw 0 = 0 > ! >=20 > zpool export syspool > = --------------------------------------------------------------------------= - > --=20 > Greg Rivers > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" >=20 -- Bob Bishop rb@gid.co.uk From owner-freebsd-stable@FreeBSD.ORG Wed Mar 25 13:09:36 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB40B4AB for ; Wed, 25 Mar 2015 13:09:36 +0000 (UTC) Received: from mail.xtaz.uk (tao.xtaz.uk [IPv6:2001:8b0:202::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9A7DEE8F for ; Wed, 25 Mar 2015 13:09:35 +0000 (UTC) Received: by mail.xtaz.uk (Postfix, from userid 1001) id 8737A209AF2F; Wed, 25 Mar 2015 13:09:31 +0000 (GMT) Date: Wed, 25 Mar 2015 13:09:31 +0000 From: Matt Smith To: Gerhard Schmidt , freebsd-stable@freebsd.org Subject: Re: Problems with openssl 1.0.2 update Message-ID: <20150325130931.GA51823@xtaz.uk> Mail-Followup-To: Matt Smith , Gerhard Schmidt , freebsd-stable@freebsd.org References: <550FEBE6.5090804@ze.tum.de> <20150323113632.GA1258@xtaz.uk> <20150323222610.GB1258@xtaz.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20150323222610.GB1258@xtaz.uk> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 13:09:36 -0000 On Mar 23 22:26, Matt Smith wrote: >On Mar 23 11:36, Matt Smith wrote: >>On Mar 23 11:33, Gerhard Schmidt wrote: >>>Hi, >>> >>>we experiencing a problem after upgrading the openssl port to openssl >>>1.0.2. >>> >>>/usr/bin/vi started to crash after some seconds with segfault. >>>/rescue/vi works just fine. Deleting the openssl 1.0.2 package >>>everything works just fine again. Installing the old openssl 1.0.1_18 >>>package it still works just fine. >>> >>>it seams that besides vi the bash also has this problem. Anybody >>>experiencing the same or is this something specific to my system. >>> >>>I'm running FreeBSD 10.1 updated tonight. >>> >> >>There is definitely something not right. See this too https://forums.freebsd.org/threads/postfix-does-not-start-build-anymore-since-upgrade-to-openssl-1-0-2.50959/ >> >>I haven't had a chance yet to test it again in more detail, but >>someone reported that postfix was broken, and I had PHP-FPM racing >>and taking up 50+ load average on my box which I guess was probably >>nginx hitting it with tons of requests. Mine is 10.1-STABLE amd64. >> > >I've just reinstalled openssl 1.0.2, and recompiled all ports that >link to openssl. And I'm still getting huge problems. PHP-FPM races >and starts loads of processes and uses 50+ load average making the >machine unresponsive. And trying to run a /bin/sh shell script gives >this: > >sh: environment corrupt; missing value for USERNAME > >This is clearly very dangerous and broken. Backing out to openssl >1.0.1 fixes everything. > FYI. This is tracked down to ASM being enabled in the port config settings. Disable that option and it works fine. Details in the PR https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198788 -- Matt From owner-freebsd-stable@FreeBSD.ORG Wed Mar 25 15:22:19 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 235E0C2 for ; Wed, 25 Mar 2015 15:22:19 +0000 (UTC) Received: from fallback3.mail.ru (fallback3.mail.ru [94.100.181.189]) by mx1.freebsd.org (Postfix) with ESMTP id 60E003DD for ; Wed, 25 Mar 2015 15:22:18 +0000 (UTC) Received: from f273.i.mail.ru (f273.i.mail.ru [217.69.128.241]) by fallback3.mail.ru (mPOP.Fallback_MX) with ESMTP id 4759A148A3691 for ; Wed, 25 Mar 2015 18:08:19 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=inbox.ru; s=mail; h=Content-Type:Message-ID:Reply-To:Date:MIME-Version:Subject:To:From; bh=zuhWNgtuBtvtZY4t2DhABbsRiFxhbsqFfzeYg844ZRQ=; b=qEunEWnlyNLzX1Z55WCp8OuVClUzuJtisc9G6VLCHAdSpQjSZzJ8YBxgB7jH1/sBuSqgP5wAe4D5FmiKHWlhXH9yps4qNZBid9AYNRRfLHOOqg9tVSBqsWHSg4hpsuswuEor4cxHvbmY3G312ITIKVlFc54kNbo7NaV9Z7qaM8s=; Received: from [77.232.152.85] (ident=mail) by f273.i.mail.ru with local (envelope-from ) id 1Yamug-0001cA-1F for freebsd-stable@freebsd.org; Wed, 25 Mar 2015 18:08:10 +0300 Received: from [77.232.152.85] by e.mail.ru with HTTP; Wed, 25 Mar 2015 18:08:09 +0300 From: =?UTF-8?B?YXJtb25pYQ==?= To: freebsd-stable@freebsd.org Subject: =?UTF-8?B?WkZTIG91dCBvZiBzd2FwIHNwYWNl?= MIME-Version: 1.0 X-Mailer: Mail.Ru Mailer 1.0 X-Originating-IP: [77.232.152.85] Date: Wed, 25 Mar 2015 18:08:09 +0300 Reply-To: =?UTF-8?B?YXJtb25pYQ==?= X-Priority: 3 (Normal) Message-ID: <1427296089.943477941@f273.i.mail.ru> X-Mras: Ok X-Spam: undefined Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 15:22:19 -0000 CgoKLS0gSGVsbG8uIFBsZWFzZSBoZWxwIC4gSSBtaXJyb3IgWkZTIDkuMyAsIGFmdGVyIGFuIGFj dGl2ZSBpdCBieSB1c2luZyBteXNxbCByZWFkIFwgd3JpdGUgZnJvbSBhbiBleHRlcm5hbCBzY3Jp cHQgc29tZXRoaW5nIGJyb2tlbi4gVGhlIG9wZXJhdGluZyBzeXN0ZW0gaXMgbm90IGxvYWRlZCBh dCB0aGUgdGltZSBvZiAiTW91bnQgbG9jYWwgZmlsZXN5c3RlbXMiCgpwb29sIGNvbnNpc3RzIG9m IGEgbWlycm9yIChyYWlkIDEgKSArIGhvdCBzd2FwLCB6ZnMgcGFydGl0aW9ucyBvbiBhIHNlcGFy YXRlIC4KCnpwb29sIGltcG9ydCAtZiAtUiAvdG1wIHpyb290IGZyZWV6ZXMKCnRyeSB0byBpbXBv cnQgYSBwb29sIGZyb20gYSBMaXZlQ0QgKDEwLjEpIC0+IHpwb29sIGltcG9ydCAtZiAtUiAvIHRt cCB6cm9vdCBvdXQgYXMgaW4gZGVlcCB0aG91Z2h0IGFuZCB0aGVuIHdyb3RlIHNvbWV0aGluZyBs aWtlCgpwaWQgOTkyMTcgKHNoKSwgdWlkIDAsIHdhcyBraWxsZWQ6IG91dCBvZiBzd2FwIHNwYWNl CnBpZCA4OTYgKHNzaCksIHVpZCAwLCB3YXMga2lsbGVkOiBvdXQgb2Ygc3dhcCBzcGFjZQoKenBv b2wgbWFkZSBvZiAyIGRpc2tzIHRvIEdQVCBhbmQgb25lIGFzIGhvdC1zd2FwLgoKwqAgenBvb2wg c3RhdHVzIC12CsKgwqAgcG9vbDogenJvb3QKwqAgc3RhdGU6IE9OTElORQrCoMKgIHNjYW46IG5v bmUgcmVxdWVzdGVkCmNvbmZpZzoKCsKgwqDCoMKgwqDCoMKgwqAgTkFNRSBTVEFURSBSRUFEIFdS SVRFIENLU1VNCsKgwqDCoMKgwqDCoMKgwqAgenJvb3QgT05MSU5FIDAgMCAwCsKgwqDCoMKgwqDC oMKgwqDCoMKgIG1pcnJvci1PTkxJTkUgMCAwIDAgMArCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg Z3B0IC8gZGlzazAgT05MSU5FIDAgMCAwCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBncHQgLyBk aXNrMSBPTkxJTkUgMCAwIDAKwqDCoMKgwqDCoMKgwqDCoCBzcGFyZXMKwqDCoMKgwqDCoMKgwqDC oMKgwqAgZ3B0IC8gZGlzazIgQVZBSUwKCmVycm9yczogTm8ga25vd24gZGF0YSBlcnJvcnMKCk9u IHRoZSBzZXJ2ZXIgNDA5NiByYW0sIHpmcyBkYXRhc2V0cyBhcmUgZGl2aWRlZCBsaWtlIHRoaXM6 Cgp6cm9vdCA1Ny44RyAyMTJHIDE3ME0gLwp6cm9vdCAvIHRtcCAxOC4yTSAyMTJHIDE4LjJNIC8g dG1wCnpyb290IC8gdXNyIDE1LjRHIDIxMkcgNDA5TSAvIHVzcgp6cm9vdCAvIHVzciAvIGhvbWUg Ni41NEcgMjEyRyA2LjU0RyAvIHVzciAvIGhvbWUKenJvb3QgLyB1c3IgLyBsb2NhbCAzLjc4RyAy MTJHIDMuNzhHIC8gdXNyIC8gbG9jYWwKenJvb3QgLyB1c3IgLyBvYmogNDMySyAyMTJHIDQzMksg LyB1c3IgLyBvYmoKenJvb3QgLyB1c3IgLyBwb3J0cyAyLjYxRyAyMTJHIDEuNjlHIC8gdXNyIC8g cG9ydHMKenJvb3QgLyB1c3IgLyBwb3J0cyAvIGRpc3RmaWxlcyA4MTVNIDIxMkcgODE1TSAvIHVz ciAvIHBvcnRzIC8gZGlzdGZpbGVzCnpyb290IC8gdXNyIC8gcG9ydHMgLyBwYWNrYWdlcyAxMjZN IDIxMkcgMTI2TSAvIHVzciAvIHBvcnRzIC8gcGFja2FnZXMKenJvb3QgLyB1c3IgLyBzcmMgMi4w OEcgMjEyRyAyLjA4RyAvIHVzciAvIHNyYwp6cm9vdCAvIHZhciA0MS45RyAyMTJHIDE5NE0gLyB2 YXIKenJvb3QgLyB2YXIgLyBiYWNrdXBzIDE0N00gMjEyRyAxNDdNIC8gdmFyIC8gYmFja3Vwcwp6 cm9vdCAvIHZhciAvIGNyYXNoIDIyNEsgMjEyRyAyMjRLIC8gdmFyIC8gY3Jhc2gKenJvb3QgLyB2 YXIgLyBkYiA0MS42RyAyMTJHIDMzMU0gLyB2YXIgLyBkYgp6cm9vdCAvIHZhciAvIGRiIC8gbXlz cWwgNDEuMkcgMjEyRyA1My42TSAvIHZhciAvIGRiIC8gbXlzcWwKenJvb3QgLyB2YXIgLyBkYiAv IG15c3FsIC8gYmlsbGluZyAzNy44RyAyMTJHIDM3LjhHIC8gdmFyIC8gZGIgLyBteXNxbCAvIGJp bGxpbmcKenJvb3QgLyB2YXIgLyBkYiAvIG15c3FsIC8gaWJkYXRhIDMuMDVHIDIxMkcgMy4wNUcg LyB2YXIgLyBkYiAvIG15c3FsIC8gaWJkYXRhCnpyb290IC8gdmFyIC8gZGIgLyBteXNxbCAvIGxv Z3MgMjMwTSAyMTJHIDIzME0gLyB2YXIgLyBkYiAvIG15c3FsIC8gbG9ncwp6cm9vdCAvIHZhciAv IGRiIC8gcGtnIDkzLjBNIDIxMkcgOTMuME0gLyB2YXIgLyBkYiAvIHBrZwp6cm9vdCAvIHZhciAv IGVtcHR5IDIxNksgMjEyRyAyMTZLIC8gdmFyIC8gZW1wdHkKenJvb3QgLyB2YXIgLyBsb2cgMzku Mk0gMjEyRyAzOS4yTSAvIHZhciAvIGxvZwp6cm9vdCAvIHZhciAvIG1haWwgMjE2SyAyMTJHIDIx NksgLyB2YXIgLyBtYWlsCnpyb290IC8gdmFyIC8gcnVuIDQ1MksgMjEyRyA0NTJLIC8gdmFyIC8g cnVuCnpyb290IC8gdmFyIC8gdG1wIDQ3NksgMjEyRyA0NzZLIC8gdmFyIC8gdG1wCgpJIHRyaWVk IHRvIG1vdW50IHNlcGFyYXRlbHkgbW91bnQgLXQgemZzIHpyb290L3Zhci9kYi9teXNxbC9iaWxs aW5nwqAKClBsZWFzZSBzZWUgc2NyZWVuc2hvdAoKaHR0cDovL3MxNy5wb3N0aW1nLm9yZy9hbTRu dXc5cjMvZHNnLmpwZwoKTm93IEkgZGlkIHpwb29sIGltcG9ydCAtZiB6cm9vdCBhbmQgenBvb2wg c2NydWIgenJvb3QsICBJcyBhbHJlYWR5IDExIHBlcmNlbnQgb2YgMTEgZ2lnYWJ5dGVzIG9mIDEw NiAsIGJ1dCBJIGRvIG5vdCB0aGluayBpdCB3aWxsIGhlbHAgLiAKClNjcnViIHNob3dzIGhhdmUg MzI3ICUgMzQ4IGdpZ2FieXRlcyBmcm9tIDEwNiBnaWdhYnl0ZXMgYW5kIHNjYW4gaXMgc2xvdywg bm8gZXN0aW1hdGVkIHRpbWUuCgpQbGVhc2UgaGVscCBjb2xsZWFndWVz From owner-freebsd-stable@FreeBSD.ORG Wed Mar 25 15:35:10 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34B7D54C for ; Wed, 25 Mar 2015 15:35:10 +0000 (UTC) Received: from mta0.alb.inoc.net (mta0.alb.inoc.net [IPv6:2607:f058:110:2::1:0]) (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 EA74F77C for ; Wed, 25 Mar 2015 15:35:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=inoc.net; s=201501; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=hjSz5sJyEKDRsNLHmbpJWbsVeDvwoxRlPhjPo9kPDso=; b=DdztKmrL1LNvz4lXUBuJ9NvgoibX5hV4WMZ/eYbn6CHENJBxxaqbf9PmGlu8kjTlh3HoavfSAEv5m/u0r33TR16c+rQoZkc+75x27Zw68Nhyi+wMovTMDZNj/buvzaYBNgumMOl/yE43PkmoHUKanmfDN2YIPTdx4xvNbqNGpDAGG6u+p8ofjJCdW4ZOQl9QZHIbG98Ki1MNCC4nouH0YKljlsUYFw971GkB1WIJGP6RF5UN61COdRJH0ekJwfCYwuAOS56anHP86r/vtwpSgZ7ZA1m9jByswp/MFJ+crkPTrzNFYkODbsA8CfdVLJsvGlFRlfMrwr/FOufCvFmUNA==; Received: from [2607:f058:10:a:d0f:622b:2dc0:7abf] by mail.inoc.net with ESMTPA (Exim 4.85) (envelope-from ) id 1YanKm-000Ijh-F0 by authid ; Wed, 25 Mar 2015 15:35:08 +0000 Subject: Re: ZFS out of swap space Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=us-ascii From: Robert Blayzor X-Priority: 3 (Normal) In-Reply-To: <1427296089.943477941@f273.i.mail.ru> Date: Wed, 25 Mar 2015 11:35:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <623F60FA-DECA-44A5-8931-D79EFE67D5D9@inoc.net> References: <1427296089.943477941@f273.i.mail.ru> To: armonia X-Mailer: Apple Mail (2.2070.6) X-Auth-Info: cmJsYXl6b3JAaW5vYy5uZXQ= X-Virus-Scanned: ClamAV 0.98.6/20236/Wed Mar 25 04:48:31 2015 X-Origin-Country: US X-Anti-Abuse: Please report to abuse@inoc.net Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 15:35:10 -0000 On Mar 25, 2015, at 11:08 AM, armonia wrote: > -- Hello. Please help . I mirror ZFS 9.3 , after an active it by using = mysql read \ write from an external script something broken. The = operating system is not loaded at the time of "Mount local filesystems" >=20 > pool consists of a mirror (raid 1 ) + hot swap, zfs partitions on a = separate . >=20 > zpool import -f -R /tmp zroot freezes Where is your swap partition? My guess is you are hitting swap because you need to tune = vfs.zfs.arc_max to allow room for the OS and any running applications. = If you do not set arc_max then ZFS will basically consume all RAM save = for about 1GB for the OS and any apps.=20 Maybe something like the following to /boot/loader.conf may help... (or = not) vfs.zfs.arc_max=3D"2G" -- Robert inoc.net!rblayzor http://inoc.net/ From owner-freebsd-stable@FreeBSD.ORG Wed Mar 25 15:49:56 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5812629B for ; Wed, 25 Mar 2015 15:49:56 +0000 (UTC) Received: from hades.sorbs.net (mail.sorbs.net [67.231.146.200]) by mx1.freebsd.org (Postfix) with ESMTP id 43DE4969 for ; Wed, 25 Mar 2015 15:49:55 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from isux.com (firewall.isux.com [213.165.190.213]) by hades.sorbs.net (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPSA id <0NLR0021ZYVO4W00@hades.sorbs.net> for freebsd-stable@freebsd.org; Wed, 25 Mar 2015 08:55:01 -0700 (PDT) Message-id: <5512D918.9090602@sorbs.net> Date: Wed, 25 Mar 2015 16:49:44 +0100 From: Michelle Sullivan User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.24) Gecko/20100301 SeaMonkey/1.1.19 To: armonia Subject: Re: ZFS out of swap space References: <1427296089.943477941@f273.i.mail.ru> In-reply-to: <1427296089.943477941@f273.i.mail.ru> Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 15:49:56 -0000 armonia wrote: > > -- Hello. Please help . I mirror ZFS 9.3 , after an active it by using mysql read \ write from an external script something broken. The operating system is not loaded at the time of "Mount local filesystems" > > pool consists of a mirror (raid 1 ) + hot swap, zfs partitions on a separate . > > zpool import -f -R /tmp zroot freezes > > try to import a pool from a LiveCD (10.1) -> zpool import -f -R / tmp zroot out as in deep thought and then wrote something like > > pid 99217 (sh), uid 0, was killed: out of swap space > pid 896 (ssh), uid 0, was killed: out of swap space > > zpool made of 2 disks to GPT and one as hot-swap. > Write a 11-STABLE USB drive boot from it to single user, run your import, then run an export, then reboot into 9.3 and import without flags. Regards, -- Michelle Sullivan http://www.mhix.org/ From owner-freebsd-stable@FreeBSD.ORG Wed Mar 25 15:55:18 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CEF54812 for ; Wed, 25 Mar 2015 15:55:18 +0000 (UTC) Received: from f161.i.mail.ru (f161.i.mail.ru [94.100.178.81]) (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 61BFBA63 for ; Wed, 25 Mar 2015 15:55:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=inbox.ru; s=mail; h=References:In-Reply-To:Content-Type:Message-ID:Reply-To:Date:MIME-Version:Subject:Cc:To:From; bh=PWPnaQScBcBkJJE49sTmm65W0J9ckza6XVE/sXmEocE=; b=ncsOVkexXIDpOVexS5PMUXiyejY6Mm96MkQmm7gJsfY7XEhI971vzyF3uoP0Xk48VWPjM6JsuJwNynfLf3Uu8O/+ltkH6a+LmDoqY+kh4hU3dERkr9IoV5weziwwr/t1KbKmePOQAqCrfGn+YVL78WIcClYAKPFVu9cfj0xH8Xg=; Received: from [77.232.152.85] (ident=mail) by f161.i.mail.ru with local (envelope-from ) id 1Yane8-0003OH-5G; Wed, 25 Mar 2015 18:55:08 +0300 Received: from [77.232.152.85] by e.mail.ru with HTTP; Wed, 25 Mar 2015 18:55:08 +0300 From: =?UTF-8?B?YXJtb25pYQ==?= To: =?UTF-8?B?Um9iZXJ0IEJsYXl6b3I=?= Subject: =?UTF-8?B?UmVbMl06IFpGUyBvdXQgb2Ygc3dhcCBzcGFjZQ==?= MIME-Version: 1.0 X-Mailer: Mail.Ru Mailer 1.0 X-Originating-IP: [77.232.152.85] Date: Wed, 25 Mar 2015 18:55:08 +0300 Reply-To: =?UTF-8?B?YXJtb25pYQ==?= X-Priority: 3 (Normal) Message-ID: <1427298908.456380675@f161.i.mail.ru> X-Mras: Ok X-Spam: undefined In-Reply-To: <623F60FA-DECA-44A5-8931-D79EFE67D5D9@inoc.net> References: <1427296089.943477941@f273.i.mail.ru> <623F60FA-DECA-44A5-8931-D79EFE67D5D9@inoc.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 15:55:18 -0000 IE5vdyB0aGUgc3lzdGVtIGlzIGJvb3RlZCBmcm9tIHRoZSBMaXZlQ0QgKDEwLjEpIGFuZCBJIGlt cG9ydGVkIHRoZSBwb29sIHVzaW5nIHpwb29sIGltcG9ydCAtZiB6cm9vdCwgYnV0IGlmIHlvdSB0 cnkgdG8gbW91bnQgZXZlcnl0aGluZyBmcmVlemVzIC4gV2hhdCB3aWxsIHN3YXAgb24gdGhlIExp dmVDRCBpZiBJIGRpZCBub3QgZG8gaXQgdGhlcmUgPwoKcHNzdGF0IC1UCjM4LzEzMDAzMCBmaWxl cwowTSAvIDBNIHN3YXAgc3BhY2UKCnN3YXBpbmZvIC0gbm93IGVtcHR5LgoKU2NydWIgc2hvd3Mg NTQwICUgY29tcGxldGUgLCB3aGF0IHRoZSBoZWxsIGRvZXMgdGhhdCBtZWFuPwoKT2YgY291cnNl IEkgd2FzIHN0YW5kaW5nIG9uIGEgcnVubmluZyBzeXN0ZW0gZXhwbGFuYXRvcnkgdmFyaWFibGVz IHZmcy56ZnMuYXJjX21heCA9IDIxNDc0ODM2NDgKCk5vdyBMaXZlQ0QgaXMgc2V0IHZmcy56ZnMu YXJjX21heCA9IDMwNTAwODY0MDAKClRoZSBxdWVzdGlvbiBpcywgaG93IGRvIEkgcmVjb3ZlciB0 aGUgb3BlcmF0aW5nIHN5c3RlbSBub3c/CgoK0KHRgNC10LTQsCwgMjUg0LzQsNGA0YLQsCAyMDE1 LCAxMTozNSAtMDQ6MDAg0L7RgiBSb2JlcnQgQmxheXpvciA8cmJsYXl6b3IuYnVsa0Bpbm9jLm5l dD46Cj5PbiBNYXIgMjUsIDIwMTUsIGF0IDExOjA4IEFNLCBhcm1vbmlhIDwgYXJtb25pYUBpbmJv eC5ydSA+IHdyb3RlOgo+PiAtLSBIZWxsby4gUGxlYXNlIGhlbHAgLiBJIG1pcnJvciBaRlMgOS4z ICwgYWZ0ZXIgYW4gYWN0aXZlIGl0IGJ5IHVzaW5nIG15c3FsIHJlYWQgXCB3cml0ZSBmcm9tIGFu IGV4dGVybmFsIHNjcmlwdCBzb21ldGhpbmcgYnJva2VuLiBUaGUgb3BlcmF0aW5nIHN5c3RlbSBp cyBub3QgbG9hZGVkIGF0IHRoZSB0aW1lIG9mICJNb3VudCBsb2NhbCBmaWxlc3lzdGVtcyIKPj4g Cj4+IHBvb2wgY29uc2lzdHMgb2YgYSBtaXJyb3IgKHJhaWQgMSApICsgaG90IHN3YXAsIHpmcyBw YXJ0aXRpb25zIG9uIGEgc2VwYXJhdGUgLgo+PiAKPj4genBvb2wgaW1wb3J0IC1mIC1SIC90bXAg enJvb3QgZnJlZXplcwo+Cj4KPldoZXJlIGlzIHlvdXIgc3dhcCBwYXJ0aXRpb24/Cj4KPk15IGd1 ZXNzIGlzIHlvdSBhcmUgaGl0dGluZyBzd2FwIGJlY2F1c2UgeW91IG5lZWQgdG8gdHVuZSB2ZnMu emZzLmFyY19tYXggdG8gYWxsb3cgcm9vbSBmb3IgdGhlIE9TIGFuZCBhbnkgcnVubmluZyBhcHBs aWNhdGlvbnMuIElmIHlvdSBkbyBub3Qgc2V0IGFyY19tYXggdGhlbiBaRlMgd2lsbCBiYXNpY2Fs bHkgY29uc3VtZSBhbGwgUkFNIHNhdmUgZm9yIGFib3V0IDFHQiBmb3IgdGhlIE9TIGFuZCBhbnkg YXBwcy4gCj4KPk1heWJlIHNvbWV0aGluZyBsaWtlIHRoZSBmb2xsb3dpbmcgdG8gL2Jvb3QvbG9h ZGVyLmNvbmYgbWF5IGhlbHAuLi4gKG9yIG5vdCkKPgo+dmZzLnpmcy5hcmNfbWF4PSIyRyIKPgo+ Cj4tLQo+Um9iZXJ0Cj5pbm9jLm5ldCFyYmxheXpvcgo+aHR0cDovL2lub2MubmV0Lwo+Cj4KPgoK Ci0tIAo= From owner-freebsd-stable@FreeBSD.ORG Wed Mar 25 16:33:04 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD1A48B7 for ; Wed, 25 Mar 2015 16:33:04 +0000 (UTC) Received: from fallback8.mail.ru (fallback8.mail.ru [94.100.181.110]) by mx1.freebsd.org (Postfix) with ESMTP id 0A876F42 for ; Wed, 25 Mar 2015 16:33:01 +0000 (UTC) Received: from f373.i.mail.ru (f373.i.mail.ru [217.69.141.15]) by fallback8.mail.ru (mPOP.Fallback_MX) with ESMTP id 15E057F68A16 for ; Wed, 25 Mar 2015 18:57:37 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=inbox.ru; s=mail; h=References:In-Reply-To:Content-Type:Message-ID:Reply-To:Date:MIME-Version:Subject:Cc:To:From; bh=aoCYnhlKzD6wQxaavdrge4bkIyur/gdC7FfcMWuTqwg=; b=MUGIMX3rBi1QVXa6nmSDquZXQbr9nJHH6S8Ei/csiTPcKqmCuFXvYRNhk2fBkRV6FQsu8hB6vc4DBcmnjiYuLCK7AJd0ZbG+rijpNsKVHiaVK8GlUoR6+bgacSz6Gtd/2wVJy9SSLRCVTQtR5i1YUzcG+BdK358Iskod8qvEnp0=; Received: from [77.232.152.85] (ident=mail) by f373.i.mail.ru with local (envelope-from ) id 1YangN-0000Gj-DZ; Wed, 25 Mar 2015 18:57:27 +0300 Received: from [77.232.152.85] by e.mail.ru with HTTP; Wed, 25 Mar 2015 18:57:27 +0300 From: =?UTF-8?B?YXJtb25pYQ==?= To: =?UTF-8?B?TWljaGVsbGUgU3VsbGl2YW4=?= Subject: =?UTF-8?B?UmVbMl06IFpGUyBvdXQgb2Ygc3dhcCBzcGFjZQ==?= MIME-Version: 1.0 X-Mailer: Mail.Ru Mailer 1.0 X-Originating-IP: [77.232.152.85] Date: Wed, 25 Mar 2015 18:57:27 +0300 Reply-To: =?UTF-8?B?YXJtb25pYQ==?= X-Priority: 3 (Normal) Message-ID: <1427299047.144533218@f373.i.mail.ru> X-Mras: Ok X-Spam: undefined In-Reply-To: <5512D918.9090602@sorbs.net> References: <1427296089.943477941@f273.i.mail.ru> <5512D918.9090602@sorbs.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 16:33:04 -0000 IFRoYW5rcywgSSAnbGwgdHJ5IGFuZCBsZXQgeW91IGtub3cgdGhlIHJlc3VsdCAuCgoK0KHRgNC1 0LTQsCwgMjUg0LzQsNGA0YLQsCAyMDE1LCAxNjo0OSArMDE6MDAg0L7RgiBNaWNoZWxsZSBTdWxs aXZhbiA8bWljaGVsbGVAc29yYnMubmV0PjoKPmFybW9uaWEgd3JvdGU6Cj4+Cj4+IC0tIEhlbGxv LiBQbGVhc2UgaGVscCAuIEkgbWlycm9yIFpGUyA5LjMgLCBhZnRlciBhbiBhY3RpdmUgaXQgYnkg dXNpbmcgbXlzcWwgcmVhZCBcIHdyaXRlIGZyb20gYW4gZXh0ZXJuYWwgc2NyaXB0IHNvbWV0aGlu ZyBicm9rZW4uIFRoZSBvcGVyYXRpbmcgc3lzdGVtIGlzIG5vdCBsb2FkZWQgYXQgdGhlIHRpbWUg b2YgIk1vdW50IGxvY2FsIGZpbGVzeXN0ZW1zIgo+Pgo+PiBwb29sIGNvbnNpc3RzIG9mIGEgbWly cm9yIChyYWlkIDEgKSArIGhvdCBzd2FwLCB6ZnMgcGFydGl0aW9ucyBvbiBhIHNlcGFyYXRlIC4K Pj4KPj4genBvb2wgaW1wb3J0IC1mIC1SIC90bXAgenJvb3QgZnJlZXplcwo+Pgo+PiB0cnkgdG8g aW1wb3J0IGEgcG9vbCBmcm9tIGEgTGl2ZUNEICgxMC4xKSAtPiB6cG9vbCBpbXBvcnQgLWYgLVIg LyB0bXAgenJvb3Qgb3V0IGFzIGluIGRlZXAgdGhvdWdodCBhbmQgdGhlbiB3cm90ZSBzb21ldGhp bmcgbGlrZQo+Pgo+PiBwaWQgOTkyMTcgKHNoKSwgdWlkIDAsIHdhcyBraWxsZWQ6IG91dCBvZiBz d2FwIHNwYWNlCj4+IHBpZCA4OTYgKHNzaCksIHVpZCAwLCB3YXMga2lsbGVkOiBvdXQgb2Ygc3dh cCBzcGFjZQo+Pgo+PiB6cG9vbCBtYWRlIG9mIDIgZGlza3MgdG8gR1BUIGFuZCBvbmUgYXMgaG90 LXN3YXAuCj4+IAo+Cj5Xcml0ZSBhIDExLVNUQUJMRSBVU0IgZHJpdmUgYm9vdCBmcm9tIGl0IHRv IHNpbmdsZSB1c2VyLCBydW4geW91cgo+aW1wb3J0LCB0aGVuIHJ1biBhbiBleHBvcnQsIHRoZW4g cmVib290IGludG8gOS4zIGFuZCBpbXBvcnQgd2l0aG91dCBmbGFncy4KPgo+UmVnYXJkcywKPgo+ LS0gCj5NaWNoZWxsZSBTdWxsaXZhbgo+aHR0cDovL3d3dy5taGl4Lm9yZy8KPgo+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPmZyZWVic2Qtc3RhYmxlQGZy ZWVic2Qub3JnIG1haWxpbmcgbGlzdAo+aHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4v bGlzdGluZm8vZnJlZWJzZC1zdGFibGUKPlRvIHVuc3Vic2NyaWJlLCBzZW5kIGFueSBtYWlsIHRv ICIgZnJlZWJzZC1zdGFibGUtdW5zdWJzY3JpYmVAZnJlZWJzZC5vcmcgIgoKCi0tIAo= From owner-freebsd-stable@FreeBSD.ORG Wed Mar 25 19:02:04 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4369E475 for ; Wed, 25 Mar 2015 19:02:04 +0000 (UTC) Received: from roadkill.tharned.org (roadkill.tharned.org [75.145.12.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 0676C2C7 for ; Wed, 25 Mar 2015 19:02:03 +0000 (UTC) Received: from localhost (rad3.sac.fedex.com [199.81.192.61]) (authenticated bits=0) by roadkill.tharned.org (8.14.9/8.14.9) with ESMTP id t2PJ1q4F032154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 25 Mar 2015 14:02:01 -0500 (CDT) (envelope-from gcr+freebsd-stable@tharned.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tharned.org; s=2014; t=1427310122; bh=P7jEHDAjk9MRTu1uMdMWQkJSFc9w1ftxjzEYdTqHtN0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=fp1kc384yajc02ZE34icPCx7hYqc1jFSoUNH9jzeN80TU96PfLIKe9OgWhg1qCesr sqDYgqZTkhrNV2KoZ1+7P8oxpvN+QYAyZJrhmS1+F0WF4tl69aVwF3VrMuvzF14ZMC JJj0q9Fq/0IeSzW8i7VyJCca2Koe+mGNuk6GU9fCQTHDovsAL7eo9q6pC/fxYjnbP4 e19YbWtxdavS9GGrGItsF+ENSsx5Ip/mz0IxgCpN8cMpj/PfGxyq6uJSoO7E7vGPOn JydWXHdEZdLEYidEIp8uZC2Vzr1JD+25jQzsgTMW7PgrfmYVYsJZcHUh4MBBxiFbz7 3/UVpONptw3jA== Date: Wed, 25 Mar 2015 14:01:51 -0500 (CDT) From: Greg Rivers To: Bob Bishop Subject: Re: Booting from ZFS In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (roadkill.tharned.org [75.145.12.185]); Wed, 25 Mar 2015 14:02:02 -0500 (CDT) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 19:02:04 -0000 On Wed, 25 Mar 2015, Bob Bishop wrote: > Hi, > >> On 25 Mar 2015, at 04:56, Greg Rivers wrote: >> >> I'm trying to build a bootable ZFS system on a USB drive. Using the >> procedure below results in the following error when I try to boot: >> >> gptzfsboot: error 66 LBA 48 >> gptzfsboot: error 66 LBA 1 >> gptzfsboot: No ZFS pools located, can't boot > > Presumably gptzfsboot relies on the BIOS mapping the USB device into a > DOS device. Do you have that support turned on in the BIOS? > I was testing this on a 2010 vintage HP G71 laptop which has no BIOS settings for USB. I didn't think about it being a BIOS issue since it boots gptboot/UFS with no problem. So I tried booting the very same gptzfsboot/ZFS USB drive on a different machine and it boots fine, so I guess it is just a HP BIOS problem. Sorry for the false alarm. -- Greg Rivers From owner-freebsd-stable@FreeBSD.ORG Wed Mar 25 19:53:23 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4203C15B for ; Wed, 25 Mar 2015 19:53:23 +0000 (UTC) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::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 090C0A38 for ; Wed, 25 Mar 2015 19:53:23 +0000 (UTC) Received: by igcau2 with SMTP id au2so848073igc.1 for ; Wed, 25 Mar 2015 12:53:22 -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:content-type; bh=Ze6Rvx+H0ZaFy2ahZ5lrBd7isTB28Hdkj5f6ykOqbnk=; b=0z1WPDsccsV4aXkniRs5A66qYiyd7maRTQ5q7LW16pt78Po4pTjyeBAeW1T0XFti+K GM6vzvX+nrMZntiks6xNclZ554rFY4NCsAfRmbbbxZqWxM24dt4E0xAQ4+PvBJuGdWCR g5btZHgroF4zRl1FJmx9sL4sH0mU0M42n1d/sYT++M8fS5Jw2aiC+bOOkih9Ip3Z8b15 /UTEt2wgLPL0e3gi94935EAQ1g0SojtY9PNZot1OoTSmYsEW6FKB1ruCpO8rtDzA7hrC DNLqsqebRfI5ufosFE0DeDSBw9ARzZxQqS0BCDGS/1M3yrUDEWXXrrl6EPxJaTnrK0WY BQdA== MIME-Version: 1.0 X-Received: by 10.50.32.70 with SMTP id g6mr31512289igi.35.1427313202411; Wed, 25 Mar 2015 12:53:22 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.107.174.86 with HTTP; Wed, 25 Mar 2015 12:53:22 -0700 (PDT) Date: Wed, 25 Mar 2015 12:53:22 -0700 X-Google-Sender-Auth: 0d5MMLnj2E5m_xsCQC9LYU1CSUU Message-ID: Subject: 10-STABLE suspend failure From: Kevin Oberman To: FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 19:53:23 -0000 Sometime in the past 6 months I lost the ability to suspend my ThinkPad T520. I don't often suspend this system, so I just noticed it today when I had it away from AC power for a while. It used to work just fine. 10.1-STABLE FreeBSD 10.1-STABLE #0 r280293: Fri Mar 20 11:28:08 PDT 2015 root@rogue:/usr/obj/usr/src/sys/GENERIC amd64 When I attempt a suspend, I get errors from both graphics and disks. drmn0: GEM idle failed, resume might fail acpi0: device_suspend failed ahcich1: Timeout on slot 29 port 0 ahcich1: is 00000000 cs 60000000 ss 60000000 rs 60000000 tfd d0 serr 00000000 cmd 000cdd17 (ada1:ahcich1:0:0:0): READ_FPDMA_QUEUED. ACB: 60 08 70 51 dd 40 06 00 00 00 00 00 (ada1:ahcich1:0:0:0): CAM status: Command timeout (ada1:ahcich1:0:0:0): Retrying command ahcich0: Timeout on slot 31 port 0 ahcich0: is 00000000 cs 80000000 ss 00000000 rs 80000000 tfd d0 serr 00000000 cmd 0000ff17 (ada0:ahcich0:0:0:0): FLUSHCACHE48. ACB: ea 00 00 00 00 40 00 00 00 00 00 00 (ada0:ahcich0:0:0:0): CAM status: Command timeout (ada0:ahcich0:0:0:0): Error 5, Retries exhausted (ada0:ahcich0:0:0:0): Synchronize cache failed Anyone have any ideas on what broke? -- Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-stable@FreeBSD.ORG Wed Mar 25 20:13:39 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D494F6E2 for ; Wed, 25 Mar 2015 20:13:39 +0000 (UTC) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9B2F4C60 for ; Wed, 25 Mar 2015 20:13:39 +0000 (UTC) Received: by iedm5 with SMTP id m5so31238887ied.3 for ; Wed, 25 Mar 2015 13:13:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Mvews+VmvUtJ+IxUke7iWLFVaq7Qw/+IoZCekZY1CKo=; b=pB0YHGDAaG4KoBFiZ+R05ktuXx21mCf5gccVak1/6odlOicw0LadM4lNdTzglxcc/L q8ugK0Dt4M9I00/ZmAaSvTYBvAhMi7s7EVz8vYcmpM4odi+6cReAMBEC6EQ/Wz91/fw0 L9qde4kD/pJ1NtGGQlyVlGarlMqWsQPTW1uLTvizS8TjuuTL8H/6h6CbEZdYYjWq1SD3 wT/o8fkjPUABR8v29Ob7QBIlhSO1G2TEfqQBvziTqrXGJjjmSRstHbTYg1J/SKHk1tbC ffLdWepho5w1GVcBj5GKBZhaQgKMRrL52MHWoR3Qn/zwRZKfANEhJ5xkqCswahUN9r0D DJkw== MIME-Version: 1.0 X-Received: by 10.50.132.66 with SMTP id os2mr31564597igb.6.1427314419075; Wed, 25 Mar 2015 13:13:39 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.17.194 with HTTP; Wed, 25 Mar 2015 13:13:39 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 Mar 2015 13:13:39 -0700 X-Google-Sender-Auth: stY5FWvzyvJqhs0GgHUtdBHGj_E Message-ID: Subject: Re: 10-STABLE suspend failure From: Adrian Chadd To: Kevin Oberman Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD-STABLE Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 20:13:39 -0000 Hi, that GEM idle fail is problematic. Try backing it out say, 1 month or so? I think that's before the drm merge from head to stable/10. -a From owner-freebsd-stable@FreeBSD.ORG Wed Mar 25 23:37:13 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 65070B64; Wed, 25 Mar 2015 23:37:13 +0000 (UTC) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 282DD360; Wed, 25 Mar 2015 23:37:13 +0000 (UTC) Received: by iedfl3 with SMTP id fl3so38842094ied.1; Wed, 25 Mar 2015 16:37:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=9H6PTeY0FSBJbwGMGAHh8FDSPykLrdCDAQpcrYezsTI=; b=gTeRXimMC0Q3UKd5PJFp9zlL+vUWmSjKZDTTRLsxjHTvNWfHnuvf3B7BLC7wUjv4B3 0uBArw3W5CSciJd2hbF/AS6z60y0BjfAAE4aDraEf4XzSdIfOfxl3dV4oD4zYQJdcFHm K7zobl60KxlPXf/D8POR2MFMc6aTNSqqumP17lJD+VM2DtQkKwMPEI6uiZq8i50wFTOz cGUk9gy54kxu4WbfgN+mI6PxVVHZKSnX5e51LCkdTJUBe2g2K+EqIdHlQ77pEA4ijqNF 5gImyMbCflRQAjeUTOiPxyJNihJEFYTV9STuEVdEzhVAylM4FBu0XG1HmT7aGqyUPo4y oTTA== MIME-Version: 1.0 X-Received: by 10.107.27.143 with SMTP id b137mr17182491iob.76.1427326632649; Wed, 25 Mar 2015 16:37:12 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.107.174.86 with HTTP; Wed, 25 Mar 2015 16:37:12 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 Mar 2015 16:37:12 -0700 X-Google-Sender-Auth: 0qY2n3dhcM3d1x6_iI8I-PzTSss Message-ID: Subject: Re: 10-STABLE suspend failure From: Kevin Oberman To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD-STABLE Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 23:37:13 -0000 Adrian, Thanks! I can confirm that rolling back the intel_opregion commit 279961 restores suspend. I only rolled back this commit, so there is no doubt this is the culprit. Of course, rolling it back also breaks brightness control. Does it look like there is a reasonable explanation for this? Without looking at the Linux code (which I probably would not understand anyway), I'd guess something is missing that is needed for suspend to work. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com On Wed, Mar 25, 2015 at 1:13 PM, Adrian Chadd wrote: > Hi, > > that GEM idle fail is problematic. > > Try backing it out say, 1 month or so? I think that's before the drm > merge from head to stable/10. > > > -a > From owner-freebsd-stable@FreeBSD.ORG Thu Mar 26 01:44:46 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A6C1A75 for ; Thu, 26 Mar 2015 01:44:46 +0000 (UTC) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E1275287 for ; Thu, 26 Mar 2015 01:44:45 +0000 (UTC) Received: by igcxg11 with SMTP id xg11so42097359igc.0 for ; Wed, 25 Mar 2015 18:44:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=MiMPh8w2pMPf/5y6zmjgJ6NRuF9Smn9kV/utZzblZQk=; b=ApDSfnmAUPb9TVg5gwiPCFJcK/+T6toSGfwujSZJpMbAKz3S3U8KC5WKER8EtbRAZm aAXCtbVeqMOxsYYzf0YbrOoZQzzuZUlLqEJK5sVuEj4NVN95dIdSdpP2+BstqZFmW6z7 Bj1pngZ0uSgTTNLWwLDGs6Srgol+Y9KQgEilge61bufewIshK52dO+oxpcjL1O9f0Edk k/4BIaDUUNQNbkaN7JCdRJobgOB2LImF3vqM2Etuc6chH2nx3sXaEhz16pnSY+2CXNWn Z6NsPztv+atoMlAeehNyrbCxYfEtufzeJ80yJzl8oo/2K6S1OM02MifZBEi4D0U7kkVp JntA== MIME-Version: 1.0 X-Received: by 10.50.36.65 with SMTP id o1mr33262410igj.32.1427334285193; Wed, 25 Mar 2015 18:44:45 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.17.194 with HTTP; Wed, 25 Mar 2015 18:44:45 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 Mar 2015 18:44:45 -0700 X-Google-Sender-Auth: fDRrftxlGuZMeazOpLtqV4yWbQ8 Message-ID: Subject: Re: 10-STABLE suspend failure From: Adrian Chadd To: Kevin Oberman Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD-STABLE Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 01:44:46 -0000 I honestly have no idea, and this is kind of why I didn't want to commit it to stable/10 without it getting a whole lot more testing. Does -HEAD also fail to suspend for you? -a From owner-freebsd-stable@FreeBSD.ORG Thu Mar 26 02:49:26 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 444C2E20; Thu, 26 Mar 2015 02:49:26 +0000 (UTC) Received: from gddsn.org.cn (gddsn.org.cn [218.19.164.145]) (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 E77E2BBB; Thu, 26 Mar 2015 02:49:25 +0000 (UTC) Received: by gddsn.org.cn (Postfix, from userid 65534) id 6C8832E07F; Thu, 26 Mar 2015 10:49:13 +0800 (CST) Received: from lp.gddsn.org.cn (unknown [10.44.8.136]) (Authenticated sender: wsk) by gddsn.org.cn (Postfix) with ESMTPA id 2B91F2E055; Thu, 26 Mar 2015 10:41:41 +0800 (CST) Message-ID: <551371E7.2070402@gddsn.org.cn> Date: Thu, 26 Mar 2015 10:41:43 +0800 From: Wu ShuKun User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: stable@freebsd.org, questions@freebsd.org Subject: AGAIN 10.1-RELEASE BTX halted on DELL PER900 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 02:49:26 -0000 folks: zfsloader btx halt again on 10.1-RELEASE just like I posted before: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=12563100+0+archive/2014/freebsd-questions/20140716.freebsd-questions below is btx halted picture on 10.1-R http://sw.gddsn.org.cn/jopens/test/btx10.1.JPG It failed with 9.3's zfsloader due to unsupported new version of ZFS on 10.1 http://sw.gddsn.org.cn/jopens/test/btx9.3.JPG thanks with appreciate. From owner-freebsd-stable@FreeBSD.ORG Thu Mar 26 06:52:33 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 66CD936B; Thu, 26 Mar 2015 06:52:33 +0000 (UTC) Received: from gddsn.org.cn (gddsn.org.cn [218.19.164.145]) (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 79A0C7C3; Thu, 26 Mar 2015 06:52:30 +0000 (UTC) Received: by gddsn.org.cn (Postfix, from userid 65534) id C06BC2E0A5; Thu, 26 Mar 2015 14:52:09 +0800 (CST) Received: from lp.gddsn.org.cn (unknown [10.44.8.136]) (Authenticated sender: wsk) by gddsn.org.cn (Postfix) with ESMTPA id 7F6662E018; Thu, 26 Mar 2015 14:44:37 +0800 (CST) Message-ID: <5513AAD8.9060505@gddsn.org.cn> Date: Thu, 26 Mar 2015 14:44:40 +0800 From: Wu ShuKun User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: net@freebsd.org, current@freebsd.org, stable@freebsd.org, questions@freebsd.org Subject: SSH hung with an OpenSSH_6.6.1p1 --> OpenSSH_5.8p2_hpn13v11 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 06:52:33 -0000 greeting! ssh connection failed by using a new version SSH to and old one. Below is the symptoms which on a same network. Connection is Okay with old version SSH %ssh -V OpenSSH_5.4p1 FreeBSD-20100308, OpenSSL 0.9.8q 2 Dec 2010 %ssh -v 10.41.172.19 OpenSSH_5.4p1 FreeBSD-20100308, OpenSSL 0.9.8q 2 Dec 2010 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Connecting to 10.41.172.19 [10.41.172.19] port 22. debug1: Connection established. debug1: identity file /home/wsk/.ssh/id_rsa type -1 debug1: identity file /home/wsk/.ssh/id_rsa-cert type -1 debug1: identity file /home/wsk/.ssh/id_dsa type -1 debug1: identity file /home/wsk/.ssh/id_dsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p2_hpn13v11 FreeBSD-20110503 debug1: match: OpenSSH_5.8p2_hpn13v11 FreeBSD-20110503 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.4p1 FreeBSD-20100308 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY The authenticity of host '10.41.172.19 (10.41.172.19)' can't be established. RSA key fingerprint is ab:81:83:79:6a:d8:29:23:a0:51:1d:e6:f0:aa:ce:d6. Are you sure you want to continue connecting (yes/no)? --- failed with Latest SSH: % ssh -V OpenSSH_6.6.1p1, OpenSSL 1.0.1l-freebsd 15 Jan 2015 % ssh -v 10.41.172.19 OpenSSH_6.6.1p1, OpenSSL 1.0.1l-freebsd 15 Jan 2015 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Connecting to 10.41.172.19 [10.41.172.19] port 22. debug1: Connection established. debug1: identity file /home/wsk/.ssh/id_rsa type -1 debug1: identity file /home/wsk/.ssh/id_rsa-cert type -1 debug1: identity file /home/wsk/.ssh/id_dsa type -1 debug1: identity file /home/wsk/.ssh/id_dsa-cert type -1 debug1: identity file /home/wsk/.ssh/id_ecdsa type -1 debug1: identity file /home/wsk/.ssh/id_ecdsa-cert type -1 debug1: identity file /home/wsk/.ssh/id_ed25519 type -1 debug1: identity file /home/wsk/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.6.1_hpn13v11 FreeBSD-20140420 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p2_hpn13v11 FreeBSD-20110503 debug1: match: OpenSSH_5.8p2_hpn13v11 FreeBSD-20110503 pat OpenSSH_5* compat 0x0c000000 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY Connection closed by 10.41.172.19 any ideas? From owner-freebsd-stable@FreeBSD.ORG Thu Mar 26 10:12:36 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DDF769A2; Thu, 26 Mar 2015 10:12:36 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A4E5FE44; Thu, 26 Mar 2015 10:12:36 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.9/8.14.9) with ESMTP id t2QACPwt080238; Thu, 26 Mar 2015 06:12:26 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <5513DB89.2050801@sentex.net> Date: Thu, 26 Mar 2015 06:12:25 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Wu ShuKun , net@freebsd.org, current@freebsd.org, stable@freebsd.org, questions@freebsd.org Subject: Re: SSH hung with an OpenSSH_6.6.1p1 --> OpenSSH_5.8p2_hpn13v11 References: <5513AAD8.9060505@gddsn.org.cn> In-Reply-To: <5513AAD8.9060505@gddsn.org.cn> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.75 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 10:12:37 -0000 On 3/26/2015 2:44 AM, Wu ShuKun wrote: > OpenSSH_5.4p1 FreeBSD-20100308, OpenSSL 0.9.8q 2 Dec 2010 > failed with Latest SSH: > % ssh -V > OpenSSH_6.6.1p1, OpenSSL 1.0.1l-freebsd 15 Jan 2015 Hi, The latest is 1.0.1m, no? }# ssh -V OpenSSH_6.6.1p1, OpenSSL 1.0.1m-freebsd 19 Mar 2015 What version of FreeBSD are you using ? Ssh and Openssl from the ports ? or in the base ? ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Thu Mar 26 10:42:58 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 656BC3DB for ; Thu, 26 Mar 2015 10:42:58 +0000 (UTC) Received: from ms3.isat.co.za (ms3.isat.co.za [196.1.71.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 664861CC for ; Thu, 26 Mar 2015 10:42:54 +0000 (UTC) Received: from ms3 (ms3 [192.168.71.18]) by ms3.isat.co.za with ESMTP ; Thu, 26 Mar 2015 11:53:35 +0200 X-Mailer: iSAT accounts Thread-Topic: Improve your ADSL access now, breaking news from iSAT on a must have, game changing, new technology for you - MailRef#G38-1027496# thread-index: AdBnqroSyfA+aHRZR4eSLbbwh/w0qQ== From: "iSAT" To: Cc: Subject: Improve your ADSL access now, breaking news from iSAT on a must have, game changing, new technology for you - MailRef#G38-1027496# Date: Thu, 26 Mar 2015 11:53:35 +0200 Message-ID: MIME-Version: 1.0 Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 10:42:58 -0000 Internet Services And Technologies 26 March 2015 Improve your ADSL access now, breaking news from iSAT on a must have, game changing, new technology for you We are extremely proud to announce the release of our ADSL line monitoring and management system (ALMMS). This is a ground breaking technology that is improving ADSL access throughout South Africa. If you are using ADSL Internet access, you are relying on a Telkom ADSL line. Then there is absolutely no doubt that you need this ADSL line monitoring and management service from iSAT now. This type of product is unique in South Africa and only available from iSAT. And at only R20 a month, it really is a no-brainer. Telkom ADSL lines do not deliver a consistent performance. This is absolutely not a fault of Telkom's, it is the way that the ADSL technology works internationally, technically ADSL is known as a best effort service. And this is where ALMMS comes in, it monitors and helps keep your line stable and optimised. Your Internet connection is of course limited to the speed of your line. For example if your 10 Mbps line is only running at 1 Mbps, then your maximum Internet speed is 1 Mbps, no matter what speed connection you have. This situation is a regular occurrence on the Telkom ADSL network. If your ADSL line is not already with iSAT, get it moved today, it's an entirely painless process, and your service will not be interrupted at all. If you have other services with a different ISP, leave them as they are, they will continue working, just get the ADSL line moved now, and enable ALMMS immediately. Once ALMMS is running and it picks up any issues on your line, an email alert is sent you and a more detailed technical fault report is sent to our support team. A support incident is also automatically logged on your account in our support management system. We work directly with Telkom to get the problem resolved, and keep in touch with you along the way. Click here to see some actual examples of what ALMMS does. For an overview about ALMMS click here . For a detailed description of ALMMS click here . ALMMS is making our competitors nervous, please read some common objections and our responses here For frequently asked questions about ALMMS click here . Sign up now it will only take 5 minutes Sign up on-line (this is the quickest and easiest method, and completely secure), click here . Or Request a form to fill in and fax through to us, click here . It's time for change, help be part of the solution and not part of the problem. Kind Regards If you aren't using ADSL access, please forward this email on to someone who is, they will be grateful for your help. ALMMS is vital for ADSL users. And we apologise for taking up your time. Click Unsubscribe to send us a mail to remove yourself from our mailing list. If you are an ADSL user please do not unsubscribe, if you are unsure of something rather mail your questions to almms@isat.co.za From owner-freebsd-stable@FreeBSD.ORG Thu Mar 26 14:16:47 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 566F456B for ; Thu, 26 Mar 2015 14:16:47 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1F943E76 for ; Thu, 26 Mar 2015 14:16:46 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.9/8.14.9) with ESMTP id t2QEGaCe025894; Thu, 26 Mar 2015 10:16:36 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <551414C3.6020704@sentex.net> Date: Thu, 26 Mar 2015 10:16:35 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Wu ShuKun , stable@freebsd.org Subject: Re: SSH hung with an OpenSSH_6.6.1p1 --> OpenSSH_5.8p2_hpn13v11 References: <5513AAD8.9060505@gddsn.org.cn> In-Reply-To: <5513AAD8.9060505@gddsn.org.cn> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.75 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 14:16:47 -0000 On 3/26/2015 2:44 AM, Wu ShuKun wrote: > greeting! > ssh connection failed by using a new version SSH to and old one. > Below is the symptoms which on a same network. > Connection is Okay with old version SSH > %ssh -V > OpenSSH_5.4p1 FreeBSD-20100308, OpenSSL 0.9.8q 2 Dec 2010 > OpenSSH_6.6.1p1, OpenSSL 1.0.1l-freebsd 15 Jan 2015 > % ssh -v 10.41.172.19 > OpenSSH_6.6.1p1, OpenSSL 1.0.1l-freebsd 15 Jan 2015 Is it possible this user somehow got a package or port, or binary upgrade somehow built with OpenSSL when it was briefly broken between r280266 and r280274 ? (Trimming the other lists from this thread) ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Thu Mar 26 19:46:05 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DF18D8A0; Thu, 26 Mar 2015 19:46:05 +0000 (UTC) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A3401E92; Thu, 26 Mar 2015 19:46:05 +0000 (UTC) Received: by igcxg11 with SMTP id xg11so1817664igc.0; Thu, 26 Mar 2015 12:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=v4CpH3nIi14MWPQHaE725rhotM9U81oHmOz4AkhSxKY=; b=03L1BGyCkd4tVQlBINvmUjXy6BTSyfAzIRKOqFZQABMdJtVsruYjFUh36azpwwr2U+ ESmjxEEC7J7MB3UVb8hG/6JF2JIFJCyhCD2Gxt6T2AgYsYgMH0zOCmmNwHaKoI3lNKZ0 i3fDT/kPuREnZmJyW9n9le4iwEnbZtRc7gqGaZUwf5ot/N5HHvVw1pRbFuFI/6lx8n0g d7A1vf71kS+VphnpjQ8N2vTjgNhjnkLC+BkRFiqsOgMkZyrNXmxRpkCKNukZ4hM4yoS1 RRqoq9tExCOhT/ZQVEQjb2zFW/klOzqRRgVnfsyapzaRkbV1Dr7hJ96Cc6+R9PRklCol b1eQ== MIME-Version: 1.0 X-Received: by 10.50.30.130 with SMTP id s2mr39698547igh.11.1427399165096; Thu, 26 Mar 2015 12:46:05 -0700 (PDT) Sender: jdavidlists@gmail.com Received: by 10.36.67.139 with HTTP; Thu, 26 Mar 2015 12:46:05 -0700 (PDT) In-Reply-To: References: <20150316232404.GM2379@kib.kiev.ua> Date: Thu, 26 Mar 2015 15:46:05 -0400 X-Google-Sender-Auth: vZFI7aRJztBZXJqUcqlojPg1MA4 Message-ID: Subject: Re: Significant memory leak in 9.3p10? From: J David To: freebsd-stable Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-questions@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 19:46:06 -0000 On Mon, Mar 16, 2015 at 7:52 PM, J David wrote: > On Mon, Mar 16, 2015 at 7:24 PM, Konstantin Belousov > wrote: >> There are a lot of possibilities to create persistent anonymous shared >> memory objects. Not complete list is tmpfs mounts, swap-backed md disks, >> sysv shared memory, possibly posix shared memory (I do not remember which >> implementation is used in stable/9). > > If that's the explanation, how could it be > detected/measured/investigated/resolved/prevented? > > Under ordinary circumstances, machines will go run like this for days/weeks: > > Mem: 549M Active, 3623M Inact, 567M Wired, 3484K Cache, 827M Buf, 3156M Free > Swap: 1024M Total, 1024M Free > > Then, when this happens, it rapidly degrades from that to so bad that > processes start getting killed for being out of swap space. These FreeBSD machines running out of swap space and dying continues to be a daily problem causing outages and unscheduled reboots. Is there really no way to even research what might be causing the problem? (Widening the cross-posting in the hopes of eliciting more help, so the brief summary of the problem orginally posted to freebsd-stable is that an unknown actor consumes all the user-space memory in the system, including swap space, to the point where processes are killed for being out of swap space, but if every process on the machine is stopped, very little of the user-space memory in use is freed. Original message with more details is here: https://lists.freebsd.org/pipermail/freebsd-stable/2015-March/081986.html .) There are no tmpfs mounts or md disks, so it would have to be one of the other causes. How can FreeBSD's use of persistent, anonymous shared memory objects be investigated, measured, or controlled so we can get a handle on this issue? Thanks! From owner-freebsd-stable@FreeBSD.ORG Thu Mar 26 21:03:46 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 99C65505; Thu, 26 Mar 2015 21:03:46 +0000 (UTC) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5EC17A06; Thu, 26 Mar 2015 21:03:46 +0000 (UTC) Received: by igcau2 with SMTP id au2so3650765igc.0; Thu, 26 Mar 2015 14:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=lm6YCH4QGKFXtMhAQGYmxRQgkPvXVbfYDgUI/PEqNqc=; b=qKFaSTeOyJbwquO4GtB8cq8XMNrRtGmtHK/JVgqc6qTKcWd4Fgjb4NsyDTgs0OLl3b JJPp9LebaLREtf/QQEajud6Ohu4Mh7SGjVtErh6LfUcJqzsODhCfsUIUiP7ojwDL6d6p i7QabMObIDam2HC3qkgld73tMmVfHTSFpPmzPBwbYwW1OxYC3a/SxBq/aBGbJeef+sJv bBmM5c4Psglh+JILrsaPyPlvYxgm6g3yNVvKk5Ps+kr2T5gFCyn94gEXIW+JX5T178hr LEGHObhBrGpEcm0fOJ66xJwCn0J/vVisO4cxynfYlwfdYgUqe+Ttndrk7Zg7XxpudvWC Vy1A== MIME-Version: 1.0 X-Received: by 10.50.29.68 with SMTP id i4mr3769987igh.35.1427403825652; Thu, 26 Mar 2015 14:03:45 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.107.174.86 with HTTP; Thu, 26 Mar 2015 14:03:45 -0700 (PDT) In-Reply-To: References: <20150316232404.GM2379@kib.kiev.ua> Date: Thu, 26 Mar 2015 14:03:45 -0700 X-Google-Sender-Auth: qnnW-2Iq4OeJGmyAGshRxGHbcLg Message-ID: Subject: Re: Significant memory leak in 9.3p10? From: Kevin Oberman To: J David Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-stable , "freebsd-questions@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 21:03:46 -0000 On Thu, Mar 26, 2015 at 12:46 PM, J David wrote: > On Mon, Mar 16, 2015 at 7:52 PM, J David wrote: > > On Mon, Mar 16, 2015 at 7:24 PM, Konstantin Belousov > > wrote: > >> There are a lot of possibilities to create persistent anonymous shared > >> memory objects. Not complete list is tmpfs mounts, swap-backed md > disks, > >> sysv shared memory, possibly posix shared memory (I do not remember > which > >> implementation is used in stable/9). > > > > If that's the explanation, how could it be > > detected/measured/investigated/resolved/prevented? > > > > Under ordinary circumstances, machines will go run like this for > days/weeks: > > > > Mem: 549M Active, 3623M Inact, 567M Wired, 3484K Cache, 827M Buf, 3156M > Free > > Swap: 1024M Total, 1024M Free > > > > Then, when this happens, it rapidly degrades from that to so bad that > > processes start getting killed for being out of swap space. > > These FreeBSD machines running out of swap space and dying continues > to be a daily problem causing outages and unscheduled reboots. Is > there really no way to even research what might be causing the > problem? > > (Widening the cross-posting in the hopes of eliciting more help, so > the brief summary of the problem orginally posted to freebsd-stable is > that an unknown actor consumes all the user-space memory in the > system, including swap space, to the point where processes are killed > for being out of swap space, but if every process on the machine is > stopped, very little of the user-space memory in use is freed. > Original message with more details is here: > https://lists.freebsd.org/pipermail/freebsd-stable/2015-March/081986.html > .) > > There are no tmpfs mounts or md disks, so it would have to be one of > the other causes. How can FreeBSD's use of persistent, anonymous > shared memory objects be investigated, measured, or controlled so we > can get a handle on this issue? > This is just a shot in the dark and not a really likely one, but I have had issues with Firefox leaking memory badly. I can free the space by killing firefox and restarting it. It seems to be linked to certain web sites, probably javascript. I have not been able to confirm which one does it. It just will start growing until the system slows to a crawl as too many things are swapped out. Normally my system does not touch swap. If it is in user space, top should show it under RES. -- Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-stable@FreeBSD.ORG Thu Mar 26 23:47:44 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2364E30A; Thu, 26 Mar 2015 23:47:44 +0000 (UTC) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D9323D83; Thu, 26 Mar 2015 23:47:43 +0000 (UTC) Received: by igbud6 with SMTP id ud6so6686103igb.1; Thu, 26 Mar 2015 16:47:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4aq9CONvYpkVGEa8WjI0ztLXCrqR0JdhdlQWEd4Gxfk=; b=C1lAiJQ3tgDVF9WatacU3sL0zVxwj6gRqi7yZAxdui3BBRsE2F5zdbkb6w804O8rgD mK2sH331XPStae8uphS5a7X5fZvpp9Y30VkktPYzNkxcvaS3Ng9UcK/iaNxUVvG8TVxw K88Er+f09XXGZO+ay4fCLpiTBXjFvhXs6OnCK1QzPX6mK5yLQW/S6DuFdonl3CMHBIqP +gSoF5aC5NQHWNMM+g9CVeifzWVC7YklQbY7PqGCL/QBUygwOL1aA2c/5Xp7+k4CSTD1 NRsm6EwfCNRm9y+rClhH9uLbE9cKzS5d1HrAJTtjbP07dDKfnubaAv/Nrcqk+OZuNjAu JKJQ== MIME-Version: 1.0 X-Received: by 10.50.29.109 with SMTP id j13mr41127544igh.2.1427413663335; Thu, 26 Mar 2015 16:47:43 -0700 (PDT) Sender: jdavidlists@gmail.com Received: by 10.36.67.139 with HTTP; Thu, 26 Mar 2015 16:47:43 -0700 (PDT) In-Reply-To: References: <20150316232404.GM2379@kib.kiev.ua> Date: Thu, 26 Mar 2015 19:47:43 -0400 X-Google-Sender-Auth: S9qMFSAlrMC7reQGIB825L5YsMo Message-ID: Subject: Re: Significant memory leak in 9.3p10? From: J David To: Kevin Oberman Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable , "freebsd-questions@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 23:47:44 -0000 In our case, On Thu, Mar 26, 2015 at 5:03 PM, Kevin Oberman wrote: > This is just a shot in the dark and not a really likely one, but I have had > issues with Firefox leaking memory badly. I can free the space by killing > firefox and restarting it. In our case, we can log in from the console, kill every single user-mode process on the system except the init, login, and the console shell, and the memory is not recovered. Gigabytes and gigabytes user memory of it are being held by some un-findable anonymous persistent structure not linked to any process. Konstantin proposed that it was some sort of shared memory usage, but there appears to be no way to check or investigate most types of shared memory usage on FreeBSD. > If it is in user space, top should show it under RES. This is definitely *not* the case. Whatever is using the memory is not associated with any user-space process, and does not show up on top or ps. It also does not appear to be SysV shared memory, as that reports: $ ipcs -m Shared Memory: T ID KEY MODE OWNER GROUP $ Also, kern.ipc.shmmax is only 512MB whereas this problem is consuming usually 8-10GB. So I guess the remaining possibilities are anonymous mmap's that are somehow not associated with any process and Posix shared memory. Are there any ways to investigate either possibility? Thanks! From owner-freebsd-stable@FreeBSD.ORG Thu Mar 26 23:57:21 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7A8F9603; Thu, 26 Mar 2015 23:57:21 +0000 (UTC) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3BBFBEA5; Thu, 26 Mar 2015 23:57:21 +0000 (UTC) Received: by igbud6 with SMTP id ud6so6851122igb.1; Thu, 26 Mar 2015 16:57:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=EjN/UMjMuCVxOz1qT/x30pkoRpOIvph/jkbtM5MCJJM=; b=hN7Zm+0HLg45MbpAn3CehkkxWrgtExiHRkSFszTvAb2u5SrJV9hvnNwNLwhspQdn2T 2Ct0Df6bbgrX+kimXFmb6WyPhBNfi8Wd5GxyMSW57/KIZ6FSQY7pVrUEaziH80oPgu7I vxgQ1SZc/8kuTlU08Lni/W7NYvapYqBnaLsF2oSePWwlGNk4n6P7s0XS+1Fq9YlTO9kz ilGEZCcWGzfDyO+1i0OJZy9nBvQWYm07J9pa9KsylmIDidXT58WLGpNs08w698Q/PmvD sNYlYkltUG7JwQkYXQFg6GjssyWGPgNDIJK0AlJj4DcR6qhMsUh92WLGYal0/YFfAdJr ZKWg== MIME-Version: 1.0 X-Received: by 10.50.66.37 with SMTP id c5mr166400igt.26.1427414240660; Thu, 26 Mar 2015 16:57:20 -0700 (PDT) Sender: jdavidlists@gmail.com Received: by 10.36.67.139 with HTTP; Thu, 26 Mar 2015 16:57:20 -0700 (PDT) In-Reply-To: <79371E33-B999-4CAC-A8E4-8D5DDBF043E6@gmail.com> References: <20150316232404.GM2379@kib.kiev.ua> <79371E33-B999-4CAC-A8E4-8D5DDBF043E6@gmail.com> Date: Thu, 26 Mar 2015 19:57:20 -0400 X-Google-Sender-Auth: 2n6_9p_uZd-esWNkJLb-5PbAMO8 Message-ID: Subject: Re: Significant memory leak in 9.3p10? From: J David To: The Lost Admin , freebsd-stable Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-questions@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 23:57:21 -0000 On Thu, Mar 26, 2015 at 7:39 PM, The Lost Admin wr= ote: > Have you looked through the system shutdown scripts (part of init/rc) to = see what happens after the uptime is printed? that might give you a lead. All of that output is printed by the kernel (see sys/kern/kern_shutdown.c), not by scripts. It happens after any shutdown scripts are run. > The output from your PS seams to be much shorter than I would expect. Are= you sure it included everything? For example, I would expect to see proces= ses for cron, syslog, and normally sshd. Killed them all. Killed absolutely user process but init, login, and the shell. Memory not freed. > I=E2=80=99ve also got a few more kernel processes that you don=E2=80=99t = appear to have. Most notably is pagedaemon pagedaemon is on the list with pid 5. Thanks! From owner-freebsd-stable@FreeBSD.ORG Fri Mar 27 00:22:46 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B96FD312; Fri, 27 Mar 2015 00:22:46 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (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 831BB1F3; Fri, 27 Mar 2015 00:22:46 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id t2R0PMqt053074; Thu, 26 Mar 2015 17:25:28 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: J David , Kevin Oberman In-Reply-To: References: <20150316232404.GM2379@kib.kiev.ua> , From: "Chris H" Subject: Re: Significant memory leak in 9.3p10? Date: Thu, 26 Mar 2015 17:25:28 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <1a80c0a3a7a587eef36118fd736203d9@ultimatedns.net> Content-Transfer-Encoding: 8bit Cc: freebsd-stable , "freebsd-questions@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 00:22:46 -0000 On Thu, 26 Mar 2015 14:03:45 -0700 Kevin Oberman wrote > On Thu, Mar 26, 2015 at 12:46 PM, J David wrote: > > > On Mon, Mar 16, 2015 at 7:52 PM, J David wrote: > > > On Mon, Mar 16, 2015 at 7:24 PM, Konstantin Belousov > > > wrote: > > >> There are a lot of possibilities to create persistent anonymous shared > > >> memory objects. Not complete list is tmpfs mounts, swap-backed md > > disks, > > >> sysv shared memory, possibly posix shared memory (I do not remember > > which > > >> implementation is used in stable/9). > > > > > > If that's the explanation, how could it be > > > detected/measured/investigated/resolved/prevented? > > > > > > Under ordinary circumstances, machines will go run like this for > > days/weeks: > > > > > > Mem: 549M Active, 3623M Inact, 567M Wired, 3484K Cache, 827M Buf, 3156M > > Free > > > Swap: 1024M Total, 1024M Free > > > > > > Then, when this happens, it rapidly degrades from that to so bad that > > > processes start getting killed for being out of swap space. > > > > These FreeBSD machines running out of swap space and dying continues > > to be a daily problem causing outages and unscheduled reboots. Is > > there really no way to even research what might be causing the > > problem? > > > > (Widening the cross-posting in the hopes of eliciting more help, so > > the brief summary of the problem orginally posted to freebsd-stable is > > that an unknown actor consumes all the user-space memory in the > > system, including swap space, to the point where processes are killed > > for being out of swap space, but if every process on the machine is > > stopped, very little of the user-space memory in use is freed. > > Original message with more details is here: > > https://lists.freebsd.org/pipermail/freebsd-stable/2015-March/081986.html > > .) > > > > There are no tmpfs mounts or md disks, so it would have to be one of > > the other causes. How can FreeBSD's use of persistent, anonymous > > shared memory objects be investigated, measured, or controlled so we > > can get a handle on this issue? > > > > This is just a shot in the dark and not a really likely one, but I have had > issues with Firefox leaking memory badly. I can free the space by killing > firefox and restarting it. > > It seems to be linked to certain web sites, probably javascript. I have not > been able to confirm which one does it. It just will start growing until > the system slows to a crawl as too many things are swapped out. Normally my > system does not touch swap. I can confirm this -- both regular, as well as ESR. Upgrading firefox [ultimately] has little-to-no effect. I have experienced this for near 2yrs. I suspect the [firefoxes] js engine. Any one of any number of sites could/would/will cause it. As Kevin already noted; stopping firefox, and starting it again, seems the only solution. > > If it is in user space, top should show it under RES. > -- > Kevin Oberman, Network Engineer, Retired > E-mail: rkoberman@gmail.com > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" --Chris From owner-freebsd-stable@FreeBSD.ORG Fri Mar 27 00:28:16 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A2B08520; Fri, 27 Mar 2015 00:28:16 +0000 (UTC) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7336724A; Fri, 27 Mar 2015 00:28:16 +0000 (UTC) Received: by igbud6 with SMTP id ud6so7360411igb.1; Thu, 26 Mar 2015 17:28:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=fozeCqu6rCHBNUTXRzlNAUkgj6Y/snNvQrVqG18/588=; b=mlqdGGSyrX8Mewyh+rqtAaJbXkPp3+IKuOGjUdl1a6xuI0YenmqK4B9CAMPHLJP0Dp rQ4HMAv1bhpkqAEK5LUsaF/V1wwuBhtZcClJEQrqJDcUvS0qNm2As0OXm5+XcD5/alIn UJ3kJtPtPDcrKllP07n47+8K+jlv7ohP5GSoWIM09uAyIXSh0VUmFF/Mr6aGRzuwzL6V 7I4rAUbtWHX4SEJEcpdp7PD3PaIe5N5QlnA84js+AAl2SVG/kdPIC90/Xzs01Xyflmc1 kce7yWygXJvvXo7OCD36Zvc5JFl4S7NJQzB0hhXfiUVNyHa1X4+vZWWuQTezHlPe1xtZ w3SQ== MIME-Version: 1.0 X-Received: by 10.50.30.130 with SMTP id s2mr41217900igh.11.1427416095772; Thu, 26 Mar 2015 17:28:15 -0700 (PDT) Sender: jdavidlists@gmail.com Received: by 10.36.67.139 with HTTP; Thu, 26 Mar 2015 17:28:15 -0700 (PDT) In-Reply-To: <1a80c0a3a7a587eef36118fd736203d9@ultimatedns.net> References: <20150316232404.GM2379@kib.kiev.ua> <1a80c0a3a7a587eef36118fd736203d9@ultimatedns.net> Date: Thu, 26 Mar 2015 20:28:15 -0400 X-Google-Sender-Auth: 1hiY-wfYArA_Ugqw4y88XSrhP8w Message-ID: Subject: Re: Significant memory leak in 9.3p10? From: J David To: Chris H Content-Type: text/plain; charset=UTF-8 Cc: Kevin Oberman , freebsd-stable , "freebsd-questions@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 00:28:16 -0000 On Thu, Mar 26, 2015 at 8:25 PM, Chris H wrote: > As Kevin already noted; stopping firefox, and starting it again, > seems the only solution. The machines in questions are servers, they do not run Firefox or any GUI. And whatever is using the memory does not show up on ps or top. Thanks! From owner-freebsd-stable@FreeBSD.ORG Fri Mar 27 00:30:59 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 32C4F6C8 for ; Fri, 27 Mar 2015 00:30:59 +0000 (UTC) Received: from gddsn.org.cn (gddsn.org.cn [218.19.164.145]) (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 E82F9277 for ; Fri, 27 Mar 2015 00:30:58 +0000 (UTC) Received: by gddsn.org.cn (Postfix, from userid 65534) id 6F65E2E07B; Fri, 27 Mar 2015 08:30:56 +0800 (CST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on gddsn.org.cn X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=ham autolearn_force=no version=3.4.0 Received: from lp.gddsn.org.cn (unknown [10.44.8.136]) (Authenticated sender: wsk) by gddsn.org.cn (Postfix) with ESMTPA id C6AB52E035; Fri, 27 Mar 2015 08:30:55 +0800 (CST) Message-ID: <5514A4BF.5020509@gddsn.org.cn> Date: Fri, 27 Mar 2015 08:30:55 +0800 From: Wu ShuKun User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Mike Tancsa , stable@freebsd.org Subject: Re: SSH hung with an OpenSSH_6.6.1p1 --> OpenSSH_5.8p2_hpn13v11 References: <5513AAD8.9060505@gddsn.org.cn> <551414C3.6020704@sentex.net> In-Reply-To: <551414C3.6020704@sentex.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 00:30:59 -0000 Yep. I'm upgraded via freebsd-update. and I have no idea where i'm wrong either.:-[ Is it likely I have no luck in other words? 在 2015/03/26 22:16, Mike Tancsa 写道: > On 3/26/2015 2:44 AM, Wu ShuKun wrote: >> greeting! >> ssh connection failed by using a new version SSH to and old one. >> Below is the symptoms which on a same network. >> Connection is Okay with old version SSH >> %ssh -V >> OpenSSH_5.4p1 FreeBSD-20100308, OpenSSL 0.9.8q 2 Dec 2010 >> OpenSSH_6.6.1p1, OpenSSL 1.0.1l-freebsd 15 Jan 2015 >> % ssh -v 10.41.172.19 >> OpenSSH_6.6.1p1, OpenSSL 1.0.1l-freebsd 15 Jan 2015 > > > Is it possible this user somehow got a package or port, or binary > upgrade somehow built with OpenSSL when it was briefly broken between > r280266 and r280274 ? > > (Trimming the other lists from this thread) > > ---Mike > > > > From owner-freebsd-stable@FreeBSD.ORG Fri Mar 27 00:52:50 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 654B7D43 for ; Fri, 27 Mar 2015 00:52:50 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 48B4E6E4 for ; Fri, 27 Mar 2015 00:52:50 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [12.229.62.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id CAD62E4E8; Thu, 26 Mar 2015 17:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1427417569; x=1427431969; bh=oOhB+Tpi+J0OfIl5YWlOUVKsM3moB+FN9FaI62qHaHQ=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=3LbmBYpeEROYL8+ooS1bUdukry3wuB0HKdqvXN/sLLsi+yPTnP8mYosWWwFpl9W6s y9TlPUyYsO4zqnqzy29UsbDmnbPPf2SiV+0r29EngA4fZOnhtwmx497mEuYjBnvWc8 TC3V3/wAbhIpuv8mtaSTbcXaL5S1mvY4XpVRTdD8= Message-ID: <5514A9E1.8070001@delphij.net> Date: Thu, 26 Mar 2015 17:52:49 -0700 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: Wu ShuKun , Mike Tancsa , stable@freebsd.org Subject: Re: SSH hung with an OpenSSH_6.6.1p1 --> OpenSSH_5.8p2_hpn13v11 References: <5513AAD8.9060505@gddsn.org.cn> <551414C3.6020704@sentex.net> <5514A4BF.5020509@gddsn.org.cn> In-Reply-To: <5514A4BF.5020509@gddsn.org.cn> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 00:52:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 03/26/15 17:30, Wu ShuKun wrote: > Yep. I'm upgraded via freebsd-update. and I have no idea where > i'm wrong either.:-[ Is it likely I have no luck in other words? Can you try specifying -o "KexAlgorithms diffie-hellman-group-exchange-sha1" when ssh'ing and see if that would mitigate the problem? My gut feeling is that somehow the HPN patch have broke certain key exchange negotiation steps of OpenSSH, which was not exercised in earlier versions of FreeBSD due to the lack of ECDH key exchange? Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.2 (FreeBSD) iQIcBAEBCgAGBQJVFKndAAoJEJW2GBstM+ns83UQAIjsYGkaBJstCW1F/Rp1Q1mm Hg63DSYteIhOfAJ/m3M4qpfWJq3vf9ID0QjN0oPkfpKvwK35P3hgkT0y/hleRjpG YdcDqlW6Adm8ZmaI+9BdZSqga+plfXyjeyChgjXSfocT7Is+s0+zSS4km3rl91aR Jhv1uVr/gMKUTnXlCaNSDajzHpEYxaKu1ipp1OTfdwnSdoK1VpVN1dcDHFK0stts qdrFiOQWKaUXiXnfVTrGRowTBk46C429k+66YLKmYLfSj/0toiCGRlrwfCLTYFHM Uc0oGWTJbqyhd9lpf5Q90B7pvJ7sBaatvEt0i9LgyuyfZQieAX6hidgnEV5cI4nC CYfMwjXRSOChcvpBtjsC/Az+7FE0mOXN9NAmwPcQ5XO0JtipNrCKwN1oR6nG2Rk5 c1qBcc9fYZBYRwdnunEG3FlNgnzi5baoHszSoHGmkew4dbUZsTIYEknsMlP0B3BP k0RHnl/083JTDP55WR/IEJF0O0LVGnrI4UQEDq66hfNSNoLLJkMkyC95EIZpNHVo uo6TI9TP3QvJBp/iPIuIdQaux7DFD/ba1htXWwOsf4Sw2brHYyvLGfnHkFOBrFNt LkiYZf9CCsawDU+BGSn2OJCndDidLuJV4H2jtZFbJ+vo13nq0t+ZmA7ZtEOz4EMr v2DmLBOFU3jxsrAwmkhJ =HsH2 -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Fri Mar 27 00:59:58 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 35781F84; Fri, 27 Mar 2015 00:59:58 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (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 EAAA1786; Fri, 27 Mar 2015 00:59:57 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id t2R12YUM056338; Thu, 26 Mar 2015 18:02:40 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: J David In-Reply-To: References: <20150316232404.GM2379@kib.kiev.ua> <1a80c0a3a7a587eef36118fd736203d9@ultimatedns.net>, From: "Chris H" Subject: Re: Significant memory leak in 9.3p10? Date: Thu, 26 Mar 2015 18:02:40 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <8ff850e3a89d01436d3ab488a2f1f425@ultimatedns.net> Content-Transfer-Encoding: 8bit Cc: Kevin Oberman , freebsd-stable , "freebsd-questions@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 00:59:58 -0000 On Thu, 26 Mar 2015 20:28:15 -0400 J David wrote > On Thu, Mar 26, 2015 at 8:25 PM, Chris H wrote: > > As Kevin already noted; stopping firefox, and starting it again, > > seems the only solution. > > The machines in questions are servers, they do not run Firefox or any > GUI. And whatever is using the memory does not show up on ps or top. Fair enough. I'm still getting caught up, on the thread. Maybe another "shot in the dark". But speaking of Servers. We ran into trouble with a web server generating *enormous* error logs -- a runaway script. The result was, even tho there was far more than adequate space for the swelling log(s). Memory, and eventually Swap usage, began to climb quite steadily. Like I said; maybe a shot in the dark. But just thought I'd mention it. > > Thanks! --Chris -- From owner-freebsd-stable@FreeBSD.ORG Fri Mar 27 01:25:57 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54DB43DB for ; Fri, 27 Mar 2015 01:25:57 +0000 (UTC) Received: from gddsn.org.cn (gddsn.org.cn [218.19.164.145]) (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 00EEF9F8 for ; Fri, 27 Mar 2015 01:25:56 +0000 (UTC) Received: by gddsn.org.cn (Postfix, from userid 65534) id 257302E096; Fri, 27 Mar 2015 09:25:54 +0800 (CST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on gddsn.org.cn X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,HTML_MESSAGE autolearn=unavailable autolearn_force=no version=3.4.0 Received: from lp.gddsn.org.cn (unknown [10.44.8.136]) (Authenticated sender: wsk) by gddsn.org.cn (Postfix) with ESMTPA id A8DFD2E00B; Fri, 27 Mar 2015 09:25:51 +0800 (CST) Message-ID: <5514B19F.2070106@gddsn.org.cn> Date: Fri, 27 Mar 2015 09:25:51 +0800 From: Wu ShuKun User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: d@delphij.net, Mike Tancsa , stable@freebsd.org Subject: Re: SSH hung with an OpenSSH_6.6.1p1 --> OpenSSH_5.8p2_hpn13v11 References: <5513AAD8.9060505@gddsn.org.cn> <551414C3.6020704@sentex.net> <5514A4BF.5020509@gddsn.org.cn> <5514A9E1.8070001@delphij.net> In-Reply-To: <5514A9E1.8070001@delphij.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 01:25:57 -0000 Okay % ssh -v -o "KexAlgorithms diffie-hellman-group-exchange-sha1" 10.41.172.19 OpenSSH_6.6.1p1, OpenSSL 1.0.1l-freebsd 15 Jan 2015 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Connecting to 10.41.172.19 [10.41.172.19] port 22. debug1: Connection established. debug1: identity file /home/wsk/.ssh/id_rsa type -1 debug1: identity file /home/wsk/.ssh/id_rsa-cert type -1 debug1: identity file /home/wsk/.ssh/id_dsa type -1 debug1: identity file /home/wsk/.ssh/id_dsa-cert type -1 debug1: identity file /home/wsk/.ssh/id_ecdsa type -1 debug1: identity file /home/wsk/.ssh/id_ecdsa-cert type -1 debug1: identity file /home/wsk/.ssh/id_ed25519 type -1 debug1: identity file /home/wsk/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.6.1_hpn13v11 FreeBSD-20140420 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p2_hpn13v11 FreeBSD-20110503 debug1: match: OpenSSH_5.8p2_hpn13v11 FreeBSD-20110503 pat OpenSSH_5* compat 0x0c000000 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP Connection closed by 10.41.172.19 % 在 2015/03/27 08:52, Xin Li 写道: > On 03/26/15 17:30, Wu ShuKun wrote: > > Yep. I'm upgraded via freebsd-update. and I have no idea where > > i'm wrong either.:-[ Is it likely I have no luck in other words? > > Can you try specifying -o "KexAlgorithms > diffie-hellman-group-exchange-sha1" when ssh'ing and see if that would > mitigate the problem? > > My gut feeling is that somehow the HPN patch have broke certain key > exchange negotiation steps of OpenSSH, which was not exercised in > earlier versions of FreeBSD due to the lack of ECDH key exchange? > > Cheers, > From owner-freebsd-stable@FreeBSD.ORG Fri Mar 27 01:28:03 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D15624D4 for ; Fri, 27 Mar 2015 01:28:03 +0000 (UTC) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (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 6737CA13 for ; Fri, 27 Mar 2015 01:28:03 +0000 (UTC) Received: by wgra20 with SMTP id a20so83344526wgr.3 for ; Thu, 26 Mar 2015 18:28:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7EjLUgRuBFZ3IZB0SiFGRHLq4X3iPPryal270s/merw=; b=I+N3dxxfwAOkPHSO2ngmAbDxkxeuFE/vAWkhelEp7Bd3hwXuMoVLaDYT1VEfKLQqmn Sq4IM/nZQM2dVigqtXvefTjxXfMgQS9tcTks40aLSMU1ZNdvNnkhI0ao1jVVKpoUV1tK Jb0DzI6uGEQx8ZpeR4CeAxoeqQAkRzNH9TG26JziGe91Y/pIVySgWpvthvNp2mEmYBv3 aVWcVcXhS5JLWK1eQKaUQaDSO3EqCE4sSh49+s1F2tXoVgY3nOW86xJfUnymsLPnej/O AX5T3aR9H9XZY2rpSVi26y7jj8905vTwkUREw+FkHz+UalWPf6NgNKz1qAjQpUPZx7qz aotA== X-Gm-Message-State: ALoCoQmU6WE6FUbHIhNRWEGMm8QdIWJc4X5TWTnmguVMxzRAgoew9vVQF6PEBUPBTgGG8vLdlJYc X-Received: by 10.195.12.35 with SMTP id en3mr31802262wjd.129.1427419681761; Thu, 26 Mar 2015 18:28:01 -0700 (PDT) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id hj10sm606555wjc.48.2015.03.26.18.28.00 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Mar 2015 18:28:00 -0700 (PDT) Message-ID: <5514B220.6080308@multiplay.co.uk> Date: Fri, 27 Mar 2015 01:28:00 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Significant memory leak in 9.3p10? References: <20150316232404.GM2379@kib.kiev.ua> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 01:28:03 -0000 On 26/03/2015 23:47, J David wrote: > In our case, > > On Thu, Mar 26, 2015 at 5:03 PM, Kevin Oberman wrote: >> This is just a shot in the dark and not a really likely one, but I have had >> issues with Firefox leaking memory badly. I can free the space by killing >> firefox and restarting it. > In our case, we can log in from the console, kill every single > user-mode process on the system except the init, login, and the > console shell, and the memory is not recovered. Gigabytes and > gigabytes user memory of it are being held by some un-findable > anonymous persistent structure not linked to any process. Konstantin > proposed that it was some sort of shared memory usage, but there > appears to be no way to check or investigate most types of shared > memory usage on FreeBSD. > Does vmstat -m or vmstat -z shed any light? Regards Steve From owner-freebsd-stable@FreeBSD.ORG Fri Mar 27 00:05:30 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DF6ECAE3; Fri, 27 Mar 2015 00:05:30 +0000 (UTC) Received: from gddsn.org.cn (gddsn.org.cn [218.19.164.145]) (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 9CED7FB9; Fri, 27 Mar 2015 00:05:30 +0000 (UTC) Received: by gddsn.org.cn (Postfix, from userid 65534) id E4CD02E087; Fri, 27 Mar 2015 08:05:27 +0800 (CST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on gddsn.org.cn X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from lp.gddsn.org.cn (unknown [10.44.8.136]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: wsk) by gddsn.org.cn (Postfix) with ESMTPSA id B1EC92E035; Fri, 27 Mar 2015 08:05:07 +0800 (CST) Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: SSH hung with an OpenSSH_6.6.1p1 --> OpenSSH_5.8p2_hpn13v11 From: =?gb2312?B?zuLK5cCk?= In-Reply-To: <5513DB89.2050801@sentex.net> Date: Fri, 27 Mar 2015 08:05:06 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <108DC3D1-8B34-4221-B6ED-8700BAF08D2C@gddsn.org.cn> References: <5513AAD8.9060505@gddsn.org.cn> <5513DB89.2050801@sentex.net> To: Mike Tancsa X-Mailer: Apple Mail (2.2070.6) X-Mailman-Approved-At: Fri, 27 Mar 2015 01:34:57 +0000 Cc: stable@freebsd.org, questions@freebsd.org, current@freebsd.org, net@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 00:05:31 -0000 all set are in base. and I=A1=AFm using 10.1-RELEASE-p8 BTW > =D4=DA 2015=C4=EA3=D4=C226=C8=D5=A3=AC=CF=C2=CE=E76:12=A3=ACMike = Tancsa =D0=B4=B5=C0=A3=BA >=20 > On 3/26/2015 2:44 AM, Wu ShuKun wrote: >=20 >> OpenSSH_5.4p1 FreeBSD-20100308, OpenSSL 0.9.8q 2 Dec 2010 >> failed with Latest SSH: >> % ssh -V >> OpenSSH_6.6.1p1, OpenSSL 1.0.1l-freebsd 15 Jan 2015 >=20 > Hi, > The latest is 1.0.1m, no? >=20 > }# ssh -V > OpenSSH_6.6.1p1, OpenSSL 1.0.1m-freebsd 19 Mar 2015 >=20 > What version of FreeBSD are you using ? Ssh and Openssl from the = ports ? or in the base ? >=20 > ---Mike >=20 > --=20 > ------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet services since 1994 www.sentex.net > Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Fri Mar 27 01:36:40 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0E5A0960 for ; Fri, 27 Mar 2015 01:36:40 +0000 (UTC) Received: from mail.egr.msu.edu (boomhauer.egr.msu.edu [35.9.37.167]) by mx1.freebsd.org (Postfix) with ESMTP id D88FDB33 for ; Fri, 27 Mar 2015 01:36:39 +0000 (UTC) Received: from boomhauer (localhost [127.0.0.1]) by mail.egr.msu.edu (Postfix) with ESMTP id 7AFE433731 for ; Thu, 26 Mar 2015 21:36:31 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mail.egr.msu.edu ([127.0.0.1]) by boomhauer (boomhauer.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsGI2AVDlLhM for ; Thu, 26 Mar 2015 21:36:31 -0400 (EDT) Received: from EGR authenticated sender mcdouga9 Message-ID: <5514B41E.3040108@egr.msu.edu> Date: Thu, 26 Mar 2015 21:36:30 -0400 From: Adam McDougall User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: SSH hung with an OpenSSH_6.6.1p1 --> OpenSSH_5.8p2_hpn13v11 References: <5513AAD8.9060505@gddsn.org.cn> <551414C3.6020704@sentex.net> <5514A4BF.5020509@gddsn.org.cn> <5514A9E1.8070001@delphij.net> <5514B19F.2070106@gddsn.org.cn> In-Reply-To: <5514B19F.2070106@gddsn.org.cn> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 01:36:40 -0000 On 03/26/2015 21:25, Wu ShuKun wrote: > Okay > % ssh -v -o "KexAlgorithms diffie-hellman-group-exchange-sha1" 10.41.172.19 > OpenSSH_6.6.1p1, OpenSSL 1.0.1l-freebsd 15 Jan 2015 > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: Connecting to 10.41.172.19 [10.41.172.19] port 22. > debug1: Connection established. > debug1: identity file /home/wsk/.ssh/id_rsa type -1 > debug1: identity file /home/wsk/.ssh/id_rsa-cert type -1 > debug1: identity file /home/wsk/.ssh/id_dsa type -1 > debug1: identity file /home/wsk/.ssh/id_dsa-cert type -1 > debug1: identity file /home/wsk/.ssh/id_ecdsa type -1 > debug1: identity file /home/wsk/.ssh/id_ecdsa-cert type -1 > debug1: identity file /home/wsk/.ssh/id_ed25519 type -1 > debug1: identity file /home/wsk/.ssh/id_ed25519-cert type -1 > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_6.6.1_hpn13v11 FreeBSD-20140420 > debug1: Remote protocol version 2.0, remote software version > OpenSSH_5.8p2_hpn13v11 FreeBSD-20110503 > debug1: match: OpenSSH_5.8p2_hpn13v11 FreeBSD-20110503 pat OpenSSH_5* > compat 0x0c000000 > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > debug1: kex: server->client aes128-ctr hmac-md5 none > debug1: kex: client->server aes128-ctr hmac-md5 none > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<8192) sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP > Connection closed by 10.41.172.19 > % Can you try stopping sshd on the server side and run /usr/sbin/sshd -Dd then SSH in and see if the server provides a reason for disconnecting the client? From owner-freebsd-stable@FreeBSD.ORG Fri Mar 27 02:29:24 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 029D65A3; Fri, 27 Mar 2015 02:29:24 +0000 (UTC) Received: from zoom.lafn.org (zoom.lafn.org [108.92.93.123]) by mx1.freebsd.org (Postfix) with ESMTP id A5A02FB1; Fri, 27 Mar 2015 02:29:23 +0000 (UTC) Received: from [10.0.1.2] (static-71-177-216-148.lsanca.fios.verizon.net [71.177.216.148]) (authenticated bits=0) by zoom.lafn.org (8.14.7/8.14.9) with ESMTP id t2R2Oxi7032249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Mar 2015 19:24:59 -0700 (PDT) (envelope-from bc979@lafn.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: Significant memory leak in 9.3p10? From: Doug Hardie In-Reply-To: <8ff850e3a89d01436d3ab488a2f1f425@ultimatedns.net> Date: Thu, 26 Mar 2015 19:24:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1AA74AFB-EBB4-48EE-A4A8-F7E5597F16A7@lafn.org> References: <20150316232404.GM2379@kib.kiev.ua> <1a80c0a3a7a587eef36118fd736203d9@ultimatedns.net> <, > <8ff850e3a89d01436d3ab488a2f1f425@ultimatedns.net> To: Chris H X-Mailer: Apple Mail (2.2070.6) X-Virus-Scanned: clamav-milter 0.98 at zoom.lafn.org X-Virus-Status: Clean Cc: Kevin Oberman , J David , freebsd-stable , "freebsd-questions@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 02:29:24 -0000 > On 26 March 2015, at 18:02, Chris H wrote: >=20 > On Thu, 26 Mar 2015 20:28:15 -0400 J David = wrote >=20 >> On Thu, Mar 26, 2015 at 8:25 PM, Chris H = wrote: >>> As Kevin already noted; stopping firefox, and starting it again, >>> seems the only solution. >>=20 >> The machines in questions are servers, they do not run Firefox or any >> GUI. And whatever is using the memory does not show up on ps or top. > Fair enough. I'm still getting caught up, on the thread. >=20 > Maybe another "shot in the dark". But speaking of Servers. We > ran into trouble with a web server generating *enormous* error > logs -- a runaway script. The result was, even tho there was > far more than adequate space for the swelling log(s). Memory, > and eventually Swap usage, began to climb quite steadily. >=20 > Like I said; maybe a shot in the dark. But just thought I'd > mention it. I just encountered the same problem on a FreeBSD 8.2-RELEASE-p3 server = today. Swap was at 100% and processes were being killed. I used ps ax = and killed all the processes with W status that I could. Swap usage = went down to 99%. This was a production server so was forced to reboot. = After the reboot, the system came back up with the same process set and = zero swap used. Shortly after that a core image appeared and the root = filesystem was full. The core file was about 1 GB. However, none of my = processes are anywhere near that. The specific process that was dumped = is only about 140 lines of C code and doesn=E2=80=99t have any dynamic = storage used, just a couple of short character strings and one integer. = The binary file is 23KB. I couldn=E2=80=99t take time to run gdb on it = as it was affecting production. From owner-freebsd-stable@FreeBSD.ORG Fri Mar 27 02:58:55 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0526EBD; Fri, 27 Mar 2015 02:58:55 +0000 (UTC) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A14D32CE; Fri, 27 Mar 2015 02:58:55 +0000 (UTC) Received: by ignm3 with SMTP id m3so24660200ign.0; Thu, 26 Mar 2015 19:58:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=pSUoS/QMhWlm1Xv6O7SZZqqpmd1/N5hKGAQRXRO2wEE=; b=k2snxicHjiIZzZBf9xrUlQnV5a209XvWwknf+aGJGV8y9EPz/xTta7UFww/wAd34nZ m7xaFwP08tvM3C9XGz8EdIzxyLM0Fh3KM9B2x7TkF7XtQ13MEq1/zpLTPfS3aQbkJ/C4 FvjnV0J51Y6Lntluk9AiBN5xS6zbYa/ZZNKj+Dp9aVHzXUH8YZCJpomAbi/WFn01BQh/ mTlPTlKnvVOi3tZkMs84+oZJvCmyL6dOv9I1J8lJGTb8qYM2E6Wl4ykbtFmoWiJL/I3c UgNAX88TtDZ2kLb/yzZvDR1FhObjO3oC2lcv87/BUz5MQzyegEqiZ9eYz1XRb/O1MVpQ Ty5w== MIME-Version: 1.0 X-Received: by 10.42.123.77 with SMTP id q13mr8966336icr.29.1427425134999; Thu, 26 Mar 2015 19:58:54 -0700 (PDT) Sender: jdavidlists@gmail.com Received: by 10.36.67.139 with HTTP; Thu, 26 Mar 2015 19:58:54 -0700 (PDT) In-Reply-To: <5514B220.6080308@multiplay.co.uk> References: <20150316232404.GM2379@kib.kiev.ua> <5514B220.6080308@multiplay.co.uk> Date: Thu, 26 Mar 2015 22:58:54 -0400 X-Google-Sender-Auth: ZKKY5exEolGe8F8hZTp0T5Ml3K4 Message-ID: Subject: Re: Significant memory leak in 9.3p10? From: J David To: Steven Hartland , "freebsd-questions@freebsd.org" Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 02:58:56 -0000 On Thu, Mar 26, 2015 at 9:28 PM, Steven Hartland wrote: > Does vmstat -m or vmstat -z shed any light? None, as those show kernel memory usage, not user space. Looking at them anyway shows nothing unusual, consuming large amounts of memory, or disproportionate to the kernel memory shown as in-use. The list of suspects that can consume user memory without being associated with any user process is very short: some sort of anonymous, persistent shared memory object. Konstantin offered a partial list of some likely candidates in response to the initial message, including: - NO: tmpfs mounts (not used) - NO: swap-backed md disks (not used) - PROBABLY NO: sysv shared memory (believed not to be used) - MAYBE: possibly posix shared memory (unknown whether used) - MAYBE: anonymous mmap segments that have somehow got lost (i.e. file descriptor is hanging around in the kernel somewhere) -- proposed by someone off-list - MAYBE: others? Of the two remaining known possibilities, posix shared memory seems more likely than an unknown mmap bug. Unfortunately, I have not found any way to gather statistics and/or get/set limits on posix shared memory usage. Does such a method exist? Really, it would be great if there were a tool that could walk the entire list of VM blocks and generate some kind of report or statistics (like vmstat -z or vmstat -m, but for VM rather than kernel memory). As it is, we are reduced to guessing what might be going on, which is decidedly suboptimal. However, I have no idea if such a tool exists, if it is even possible to write, or (if it is) how to go about writing it. Thanks! From owner-freebsd-stable@FreeBSD.ORG Fri Mar 27 09:16:44 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D4BA43C; Fri, 27 Mar 2015 09:16:44 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E3EB9EA6; Fri, 27 Mar 2015 09:16:43 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t2R9Gc7e052295 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 27 Mar 2015 11:16:38 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t2R9Gc7e052295 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t2R9Gbbu052294; Fri, 27 Mar 2015 11:16:37 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 27 Mar 2015 11:16:37 +0200 From: Konstantin Belousov To: J David Subject: Re: Significant memory leak in 9.3p10? Message-ID: <20150327091637.GH2379@kib.kiev.ua> References: <20150316232404.GM2379@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-stable , "freebsd-questions@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 09:16:44 -0000 On Thu, Mar 26, 2015 at 03:46:05PM -0400, J David wrote: > On Mon, Mar 16, 2015 at 7:52 PM, J David wrote: > > On Mon, Mar 16, 2015 at 7:24 PM, Konstantin Belousov > > wrote: > >> There are a lot of possibilities to create persistent anonymous shared > >> memory objects. Not complete list is tmpfs mounts, swap-backed md disks, > >> sysv shared memory, possibly posix shared memory (I do not remember which > >> implementation is used in stable/9). > > > > If that's the explanation, how could it be > > detected/measured/investigated/resolved/prevented? > > > > Under ordinary circumstances, machines will go run like this for days/weeks: > > > > Mem: 549M Active, 3623M Inact, 567M Wired, 3484K Cache, 827M Buf, 3156M Free > > Swap: 1024M Total, 1024M Free > > > > Then, when this happens, it rapidly degrades from that to so bad that > > processes start getting killed for being out of swap space. > > These FreeBSD machines running out of swap space and dying continues > to be a daily problem causing outages and unscheduled reboots. Is > there really no way to even research what might be causing the > problem? > > (Widening the cross-posting in the hopes of eliciting more help, so > the brief summary of the problem orginally posted to freebsd-stable is > that an unknown actor consumes all the user-space memory in the > system, including swap space, to the point where processes are killed > for being out of swap space, but if every process on the machine is > stopped, very little of the user-space memory in use is freed. > Original message with more details is here: > https://lists.freebsd.org/pipermail/freebsd-stable/2015-March/081986.html > .) > > There are no tmpfs mounts or md disks, so it would have to be one of > the other causes. How can FreeBSD's use of persistent, anonymous > shared memory objects be investigated, measured, or controlled so we > can get a handle on this issue? Start by providing useful information about your system, not a description of the information. E.g., a consistent snapshot of the following: ps auxww swapinfo mount -v mdconfig -lv vmstat -z vmstat -m vmstat -s sysctl -a ipcs -a Collect this data both during the normal run, run while the problem appear but userspace is not killed, and after you killed the processes. Just in case, show kldstat. From owner-freebsd-stable@FreeBSD.ORG Fri Mar 27 10:29:22 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 883DA157; Fri, 27 Mar 2015 10:29:22 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 73B5F9ED; Fri, 27 Mar 2015 10:29:22 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 925E72A7; Fri, 27 Mar 2015 10:29:19 +0000 (UTC) Date: Fri, 27 Mar 2015 10:29:12 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-stable@freebsd.org, mav@FreeBSD.org Message-ID: <781335995.2.1427452155665.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_stable_10 #1321 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 10:29:22 -0000 See Changes: [mav] MFC r280286: Add comment explaining existing powerd behavior on SMP s= ystems. [mav] MFC r280154: Report that we may have write cache, and that we do support FLUSH. [mav] MFC r280133: Increase S/G list size of 32 to 33 entries. 32 entries are not enough for the worst case of misaligned 128KB request, that made FreeBSD to chunk large quests in odd pieces. [mav] MFC r280126: Pre-allocate one extra request per processing thread. Processing threads call callbacks before freeing requests. As result, new requests may arrive before old ones are freed. [mav] MFC r280044: According to Linux and QEMU, s/n equal to buffer is not zero-terminated. This makes same s/n reported for both virtio and AHCI drivers. [mav] MFC r280042: Close potential race on blockif_close(). Reported by:=09vangyzen [mav] MFC r280040: Give AHCI disk serial based on backing file path same as for virtio block. It is still not good that they may intersect on different hosts, but that is better then intersecting on the same host. [mav] MFC r280037: Rewrite virtio block device driver to work asynchronously and use the block I/O interface. Asynchronous operation, based on r280026 change, allows to not block virtua= l CPU during I/O processing, that on slow/busy storage can take seconds. Use of recently improved block I/O interface allows to process multiple requests same time, that improves random I/O performance on wide storages. Benchmarks of virtual disk, backed by ZVOL on RAID10 pool of 4 HDDs, show ~3.5 times random read performance improvements, while no degradation on linear I/O. Guest CPU usage during test dropped from 100% to almost zero. [mav] MFC r280026, r280041: Modify virtqueue helpers added in r253440 to allow queuing. Original virtqueue design allows queued and out-of-order processing, but helpers added in r253440 suppose only direct blocking in-order one. It could be fine for network, etc., but it is a huge limitation for storage devices. [mav] MFC r280004: Give block I/O interface multiple (8) execution threads. On parallel random I/O this allows better utilize wide storage pools. To not confuse prefetcher on linear I/O, consecutive requests are executed sequentially, following the same logic as was earlier implemented in CTL. Benchmarks of virtual AHCI disk, backed by ZVOL on RAID10 pool of 4 HDDs, show ~3.5 times random read performance improvements, while no degradation on linear I/O. [mav] MFC r279987: Add checksums to identify data and NCQ command error log= . [mav] MFC r279979: Slightly polish virtual AHCI CD reporting. [mav] MFC r279977: Fix NOP and IDLE commands for virtual AHCI disks. [mav] MFC r279976: Add support for NCQ variant of DSM TRIM for virtual AHCI= disks. The code is not really tested yet due to lack of initiator support. [mav] MFC r279975: Improve NCQ errors reporting for virtual AHCI disks. While this implementation is still not perfect, previous was just broken. [mav] MFC r279968: Remove incorrect SERR register setting. At this point we have nothing to report through that register. [mav] MFC r279967: Change prdbc value reporting. [mav] MFC r279965: Polish AHCI disk identify data and fix speed negotiation= . [mav] MFC r279960: Add support for PIO variants of READ/WRITE commands for AHCI disks. AHCI API hides all PIO specifics, so this functionality is almost free. [mav] MFC r279975: Use ahci_write_fis_d2h() for commands completion. ------------------------------------------ [...truncated 182279 lines...] --- all_subdir_libarchive --- --- archive_read_set_options.po --- cc -pg -O2 -pipe -DHAVE_BZLIB_H=3D1 -DHAVE_LIBLZMA=3D1 -DHAVE_LZMA_H=3D= 1 -DPLATFORM_CONFIG_H=3D\" -I -DWITH_OP= ENSSL -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -= Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -= Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strin= gs -Wswitch -Wshadow -Wunused-parameter -Wchar-subscripts -Winline -Wnested= -externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declar= ations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-c= onst-variable -c = -o archive_read_set_options.po --- usr.sbin.all__D --- --- common.o --- cc -O2 -pipe -I -I -I -std=3Dgnu99 -Qunused-argume= nts -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -W= no-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-para= meter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-= decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-s= ign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c = -o common.o --- lib.all__D --- --- archive_read_support_filter_all.po --- cc -pg -O2 -pipe -DHAVE_BZLIB_H=3D1 -DHAVE_LIBLZMA=3D1 -DHAVE_LZMA_H=3D= 1 -DPLATFORM_CONFIG_H=3D\" -I -DWITH_OP= ENSSL -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -= Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -= Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strin= gs -Wswitch -Wshadow -Wunused-parameter -Wchar-subscripts -Winline -Wnested= -externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declar= ations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-c= onst-variable -c -o archive_read_support_filter_all.po --- all_subdir_libmagic --- --- cdf.po --- cc -pg -O2 -pipe -DMAGIC=3D'"/usr/share/misc/magic"' -DHAVE_CONFIG_H -I= -I -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-head= ers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-si= gn -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tau= tological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-f= unction -Wno-enum-conversion -c -o cdf.po --- all_subdir_libarchive --- --- archive_read_support_filter_bzip2.po --- cc -pg -O2 -pipe -DHAVE_BZLIB_H=3D1 -DHAVE_LIBLZMA=3D1 -DHAVE_LZMA_H=3D= 1 -DPLATFORM_CONFIG_H=3D\" -I -DWITH_OP= ENSSL -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -= Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -= Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strin= gs -Wswitch -Wshadow -Wunused-parameter -Wchar-subscripts -Winline -Wnested= -externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declar= ations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-c= onst-variable -c -o archive_read_support_filter_bzip2.po --- archive_read_support_filter_compress.po --- cc -pg -O2 -pipe -DHAVE_BZLIB_H=3D1 -DHAVE_LIBLZMA=3D1 -DHAVE_LZMA_H=3D= 1 -DPLATFORM_CONFIG_H=3D\" -I -DWITH_OP= ENSSL -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -= Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -= Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strin= gs -Wswitch -Wshadow -Wunused-parameter -Wchar-subscripts -Winline -Wnested= -externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declar= ations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-c= onst-variable -c -o archive_read_support_filter_compress.po --- usr.sbin.all__D --- --- defined.o --- cc -O2 -pipe -I -I -I -std=3Dgnu99 -Qunused-argume= nts -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -W= no-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-para= meter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-= decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-s= ign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c -o defined.o --- lib.all__D --- --- archive_read_support_filter_gzip.po --- cc -pg -O2 -pipe -DHAVE_BZLIB_H=3D1 -DHAVE_LIBLZMA=3D1 -DHAVE_LZMA_H=3D= 1 -DPLATFORM_CONFIG_H=3D\" -I -DWITH_OP= ENSSL -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -= Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -= Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strin= gs -Wswitch -Wshadow -Wunused-parameter -Wchar-subscripts -Winline -Wnested= -externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declar= ations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-c= onst-variable -c -o archive_read_support_filter_gzip.po --- usr.sbin.all__D --- --- getmntopts.o --- cc -O2 -pipe -I -I -I -std=3Dgnu99 -Qunused-argume= nts -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -W= no-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-para= meter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-= decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-s= ign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c -o getmntopts.o --- lib.all__D --- --- all_subdir_libmagic --- --- cdf_time.po --- cc -pg -O2 -pipe -DMAGIC=3D'"/usr/share/misc/magic"' -DHAVE_CONFIG_H -I= -I -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-head= ers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-si= gn -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tau= tological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-f= unction -Wno-enum-conversion -c -o cdf_time.po --- usr.sbin.all__D --- --- log.o --- cc -O2 -pipe -I -I -I -std=3Dgnu99 -Qunused-argume= nts -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -W= no-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-para= meter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-= decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-s= ign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c -o= log.o --- lib.all__D --- --- all_subdir_libarchive --- --- archive_read_support_filter_grzip.po --- cc -pg -O2 -pipe -DHAVE_BZLIB_H=3D1 -DHAVE_LIBLZMA=3D1 -DHAVE_LZMA_H=3D= 1 -DPLATFORM_CONFIG_H=3D\" -I -DWITH_OP= ENSSL -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -= Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -= Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strin= gs -Wswitch -Wshadow -Wunused-parameter -Wchar-subscripts -Winline -Wnested= -externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declar= ations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-c= onst-variable -c -o archive_read_support_filter_grzip.po --- usr.sbin.all__D --- --- popen.o --- cc -O2 -pipe -I -I -I -std=3Dgnu99 -Qunused-argume= nts -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -W= no-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-para= meter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-= decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-s= ign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c = -o popen.o --- lib.all__D --- --- all_subdir_libmagic --- --- compress.po --- cc -pg -O2 -pipe -DMAGIC=3D'"/usr/share/misc/magic"' -DHAVE_CONFIG_H -I= -I -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-head= ers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-si= gn -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tau= tological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-f= unction -Wno-enum-conversion -c -o compress.po --- all_subdir_libarchive --- --- archive_read_support_filter_lrzip.po --- cc -pg -O2 -pipe -DHAVE_BZLIB_H=3D1 -DHAVE_LIBLZMA=3D1 -DHAVE_LZMA_H=3D= 1 -DPLATFORM_CONFIG_H=3D\" -I -DWITH_OP= ENSSL -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -= Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -= Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strin= gs -Wswitch -Wshadow -Wunused-parameter -Wchar-subscripts -Winline -Wnested= -externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declar= ations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-c= onst-variable -c -o archive_read_support_filter_lrzip.po --- usr.sbin.all__D --- --- automount.8.gz --- gzip -cn > automount.8.gz --- automountd.8.gz --- gzip -cn > automountd.8.gz --- autounmountd.8.gz --- gzip -cn > autounmountd.8.gz --- auto_master.5.gz --- gzip -cn > auto_master.5.gz --- lib.all__D --- --- all_subdir_libmagic --- --- encoding.po --- cc -pg -O2 -pipe -DMAGIC=3D'"/usr/share/misc/magic"' -DHAVE_CONFIG_H -I= -I -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-head= ers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-si= gn -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tau= tological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-f= unction -Wno-enum-conversion -c -o encoding.po --- usr.sbin.all__D --- --- token.o --- cc -O2 -pipe -I -I -I -std=3Dgnu99 -Qunused-argume= nts -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -W= no-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-para= meter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-= decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-s= ign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c toke= n.c -o token.o --- lib.all__D --- --- all_subdir_libarchive --- --- archive_read_support_filter_lzop.po --- cc -pg -O2 -pipe -DHAVE_BZLIB_H=3D1 -DHAVE_LIBLZMA=3D1 -DHAVE_LZMA_H=3D= 1 -DPLATFORM_CONFIG_H=3D\" -I -DWITH_OP= ENSSL -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -= Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -= Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strin= gs -Wswitch -Wshadow -Wunused-parameter -Wchar-subscripts -Winline -Wnested= -externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declar= ations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-c= onst-variable -c -o archive_read_support_filter_lzop.po --- all_subdir_libmagic --- --- fsmagic.po --- cc -pg -O2 -pipe -DMAGIC=3D'"/usr/share/misc/magic"' -DHAVE_CONFIG_H -I= -I -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-head= ers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-si= gn -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tau= tological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-f= unction -Wno-enum-conversion -c -o fsmagic.po --- all_subdir_libarchive --- --- archive_read_support_filter_none.po --- cc -pg -O2 -pipe -DHAVE_BZLIB_H=3D1 -DHAVE_LIBLZMA=3D1 -DHAVE_LZMA_H=3D= 1 -DPLATFORM_CONFIG_H=3D\" -I -DWITH_OP= ENSSL -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -= Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -= Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strin= gs -Wswitch -Wshadow -Wunused-parameter -Wchar-subscripts -Winline -Wnested= -externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declar= ations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-c= onst-variable -c -o archive_read_support_filter_none.po --- usr.sbin.all__D --- --- automountd --- cc -O2 -pipe -I -I -I -std=3Dgnu99 -Qunused-argume= nts -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -W= no-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-para= meter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-= decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-s= ign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -o aut= omountd automount.o automountd.o autounmountd.o common.o defined.o getmntop= ts.o log.o popen.o token.o -lutil --- lib.all__D --- --- archive_read_support_filter_program.po --- cc -pg -O2 -pipe -DHAVE_BZLIB_H=3D1 -DHAVE_LIBLZMA=3D1 -DHAVE_LZMA_H=3D= 1 -DPLATFORM_CONFIG_H=3D\" -I -DWITH_OP= ENSSL -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -= Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -= Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strin= gs -Wswitch -Wshadow -Wunused-parameter -Wchar-subscripts -Winline -Wnested= -externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declar= ations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-c= onst-variable -c -o archive_read_support_filter_program.po --- usr.sbin.all__D --- --- all_subdir_bhyve --- --- lib.all__D --- --- all_subdir_libmagic --- --- funcs.po --- --- usr.sbin.all__D --- =3D=3D=3D> usr.sbin/bhyve (all) --- lib.all__D --- cc -pg -O2 -pipe -DMAGIC=3D'"/usr/share/misc/magic"' -DHAVE_CONFIG_H -I= -I -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-head= ers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-si= gn -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tau= tological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-f= unction -Wno-enum-conversion -c -o funcs.po --- all_subdir_libarchive --- --- archive_read_support_filter_rpm.po --- cc -pg -O2 -pipe -DHAVE_BZLIB_H=3D1 -DHAVE_LIBLZMA=3D1 -DHAVE_LZMA_H=3D= 1 -DPLATFORM_CONFIG_H=3D\" -I -DWITH_OP= ENSSL -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -= Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -= Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strin= gs -Wswitch -Wshadow -Wunused-parameter -Wchar-subscripts -Winline -Wnested= -externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declar= ations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-c= onst-variable -c -o archive_read_support_filter_rpm.po --- usr.bin.all__D --- --- all_subdir_clang --- --- IntrinsicEmitter.o --- c++ -O2 -pipe -I -I -I -I. -I -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__ST= DC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -DCLANG_ENABLE_ARCMT -DCL= ANG_ENABLE_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing -DL= LVM_DEFAULT_TARGET_TRIPLE=3D\"x86_64-unknown-freebsd10.1\" -DLLVM_HOST_TRIP= LE=3D\"x86_64-unknown-freebsd10.1\" -DDEFAULT_SYSROOT=3D\"\" -Qunused-argum= ents -fstack-protector -fno-exceptions -fno-rtti -Wno-c++11-extensions -c= -o IntrinsicEmi= tter.o --- lib.all__D --- --- archive_read_support_filter_uu.po --- --- all_subdir_libmagic --- --- is_tar.po --- --- all_subdir_libarchive --- cc -pg -O2 -pipe -DHAVE_BZLIB_H=3D1 -DHAVE_LIBLZMA=3D1 -DHAVE_LZMA_H=3D= 1 -DPLATFORM_CONFIG_H=3D\" -I -DWITH_OP= ENSSL -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -= Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -= Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strin= gs -Wswitch -Wshadow -Wunused-parameter -Wchar-subscripts -Winline -Wnested= -externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declar= ations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-c= onst-variable -c -o archive_read_support_filter_uu.po --- all_subdir_libmagic --- cc -pg -O2 -pipe -DMAGIC=3D'"/usr/share/misc/magic"' -DHAVE_CONFIG_H -I= -I -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-head= ers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-si= gn -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tau= tological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-f= unction -Wno-enum-conversion -c -o is_tar.po --- usr.sbin.all__D --- --- atkbdc.o --- cc -O2 -pipe -g -O0 -std=3Dgnu99 -Qunused-arguments -fstack-protector -= Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-point= er-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wn= o-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unu= sed-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-pro= moted-parameter -c -o atkbdc.o --- lib.all__D --- --- magic.po --- cc -pg -O2 -pipe -DMAGIC=3D'"/usr/share/misc/magic"' -DHAVE_CONFIG_H -I= -I -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-head= ers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-si= gn -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tau= tological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-f= unction -Wno-enum-conversion -c -o magic.po --- all_subdir_libarchive --- --- archive_read_support_filter_xz.po --- cc -pg -O2 -pipe -DHAVE_BZLIB_H=3D1 -DHAVE_LIBLZMA=3D1 -DHAVE_LZMA_H=3D= 1 -DPLATFORM_CONFIG_H=3D\" -I -DWITH_OP= ENSSL -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -= Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -= Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strin= gs -Wswitch -Wshadow -Wunused-parameter -Wchar-subscripts -Winline -Wnested= -externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declar= ations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-c= onst-variable -c -o archive_read_support_filter_xz.po --- usr.sbin.all__D --- --- acpi.o --- cc -O2 -pipe -g -O0 -std=3Dgnu99 -Qunused-arguments -fstack-protector -= Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-point= er-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wn= o-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unu= sed-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-pro= moted-parameter -c -o acpi.o --- lib.all__D --- --- all_subdir_libmagic --- --- print.po --- cc -pg -O2 -pipe -DMAGIC=3D'"/usr/share/misc/magic"' -DHAVE_CONFIG_H -I= -I -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-head= ers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-si= gn -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tau= tological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-f= unction -Wno-enum-conversion -c -o print.po --- usr.sbin.all__D --- --- bhyverun.o --- cc -O2 -pipe -g -O0 -std=3Dgnu99 -Qunused-arguments -fstack-protector -= Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-point= er-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wn= o-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unu= sed-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-pro= moted-parameter -c -o bhyverun.o --- lib.all__D --- --- all_subdir_libarchive --- --- archive_read_support_format_7zip.po --- cc -pg -O2 -pipe -DHAVE_BZLIB_H=3D1 -DHAVE_LIBLZMA=3D1 -DHAVE_LZMA_H=3D= 1 -DPLATFORM_CONFIG_H=3D\" -I -DWITH_OP= ENSSL -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -= Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -= Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strin= gs -Wswitch -Wshadow -Wunused-parameter -Wchar-subscripts -Winline -Wnested= -externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declar= ations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-c= onst-variable -c -o archive_read_support_format_7zip.po --- all_subdir_libmagic --- --- readcdf.po --- cc -pg -O2 -pipe -DMAGIC=3D'"/usr/share/misc/magic"' -DHAVE_CONFIG_H -I= -I -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-head= ers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-si= gn -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tau= tological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-f= unction -Wno-enum-conversion -c -o readcdf.po --- readelf.po --- cc -pg -O2 -pipe -DMAGIC=3D'"/usr/share/misc/magic"' -DHAVE_CONFIG_H -I= -I -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-head= ers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-si= gn -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tau= tological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-f= unction -Wno-enum-conversion -c -o readelf.po --- usr.sbin.all__D --- --- block_if.o --- cc -O2 -pipe -g -O0 -std=3Dgnu99 -Qunused-arguments -fstack-protector -= Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-point= er-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wn= o-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unu= sed-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-pro= moted-parameter -c -o block_if.o --- consport.o --- cc -O2 -pipe -g -O0 -std=3Dgnu99 -Qunused-arguments -fstack-protector -= Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-point= er-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wn= o-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unu= sed-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-pro= moted-parameter -c -o consport.o --- dbgport.o --- cc -O2 -pipe -g -O0 -std=3Dgnu99 -Qunused-arguments -fstack-protector -= Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-point= er-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wn= o-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unu= sed-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-pro= moted-parameter -c -o dbgport.o --- inout.o --- cc -O2 -pipe -g -O0 -std=3Dgnu99 -Qunused-arguments -fstack-protector -= Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-point= er-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wn= o-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unu= sed-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-pro= moted-parameter -c -o inout.o --- lib.all__D --- --- softmagic.po --- cc -pg -O2 -pipe -DMAGIC=3D'"/usr/share/misc/magic"' -DHAVE_CONFIG_H -I= -I -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-head= ers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-si= gn -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tau= tological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-f= unction -Wno-enum-conversion -c -o softmagic.po --- usr.sbin.all__D --- --- ioapic.o --- cc -O2 -pipe -g -O0 -std=3Dgnu99 -Qunused-arguments -fstack-protector -= Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-point= er-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wn= o-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unu= sed-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-pro= moted-parameter -c -o ioapic.o --- lib.all__D --- --- all_subdir_libarchive --- --- archive_read_support_format_all.po --- cc -pg -O2 -pipe -DHAVE_BZLIB_H=3D1 -DHAVE_LIBLZMA=3D1 -DHAVE_LZMA_H=3D= 1 -DPLATFORM_CONFIG_H=3D\" -I -DWITH_OP= ENSSL -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -= Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -= Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strin= gs -Wswitch -Wshadow -Wunused-parameter -Wchar-subscripts -Winline -Wnested= -externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declar= ations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-c= onst-variable -c -o archive_read_support_format_all.po --- usr.sbin.all__D --- --- mem.o --- cc -O2 -pipe -g -O0 -std=3Dgnu99 -Qunused-arguments -fstack-protector -= Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-point= er-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wn= o-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unu= sed-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-pro= moted-parameter -c -o mem.o --- lib.all__D --- --- archive_read_support_format_ar.po --- cc -pg -O2 -pipe -DHAVE_BZLIB_H=3D1 -DHAVE_LIBLZMA=3D1 -DHAVE_LZMA_H=3D= 1 -DPLATFORM_CONFIG_H=3D\" -I -DWITH_OP= ENSSL -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -= Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -= Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strin= gs -Wswitch -Wshadow -Wunused-parameter -Wchar-subscripts -Winline -Wnested= -externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declar= ations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-c= onst-variable -c -o archive_read_support_format_ar.po --- usr.sbin.all__D --- --- mevent.o --- cc -O2 -pipe -g -O0 -std=3Dgnu99 -Qunused-arguments -fstack-protector -= Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-point= er-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wn= o-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unu= sed-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-pro= moted-parameter -c -o mevent.o --- mptbl.o --- cc -O2 -pipe -g -O0 -std=3Dgnu99 -Qunused-arguments -fstack-protector -= Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-point= er-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wn= o-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unu= sed-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-pro= moted-parameter -c -o mptbl.o --- pci_ahci.o --- cc -O2 -pipe -g -O0 -std=3Dgnu99 -Qunused-arguments -fstack-protector -= Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-point= er-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wn= o-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unu= sed-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-pro= moted-parameter -c -o pci_ahci.o --- lib.all__D --- --- archive_read_support_format_by_code.po --- cc -pg -O2 -pipe -DHAVE_BZLIB_H=3D1 -DHAVE_LIBLZMA=3D1 -DHAVE_LZMA_H=3D= 1 -DPLATFORM_CONFIG_H=3D\" -I -DWITH_OP= ENSSL -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -= Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -= Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strin= gs -Wswitch -Wshadow -Wunused-parameter -Wchar-subscripts -Winline -Wnested= -externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declar= ations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-c= onst-variable -c -o archive_read_support_format_by_code.po --- archive_read_support_format_cab.po --- cc -pg -O2 -pipe -DHAVE_BZLIB_H=3D1 -DHAVE_LIBLZMA=3D1 -DHAVE_LZMA_H=3D= 1 -DPLATFORM_CONFIG_H=3D\" -I -DWITH_OP= ENSSL -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -= Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -= Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strin= gs -Wswitch -Wshadow -Wunused-parameter -Wchar-subscripts -Winline -Wnested= -externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declar= ations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-c= onst-variable -c -o archive_read_support_format_cab.po --- usr.sbin.all__D --- :1633:28: error: use of undeclared identifier 'ATA_SFPDMA_DSM' if ((cfis[13] & 0x1f) =3D=3D ATA_SFPDMA_DSM && ^ :1777:28: error: use of undeclared identifier 'ATA_SFPDMA_DSM' (cfis[13] & 0x1f) =3D=3D ATA_SFPDMA_DSM)) ^ 2 errors generated. *** [pci_ahci.o] Error code 1 make[4]: stopped in 1 error make[4]: stopped in *** [all_subdir_bhyve] Error code 2 make[3]: stopped in 1 error make[3]: stopped in --- lib.all__D --- --- all_subdir_libmagic --- A failure has been detected in another branch of the parallel make make[4]: stopped in --- usr.sbin.all__D --- *** [usr.sbin.all__D] Error code 2 make[2]: stopped in --- lib.all__D --- *** [all_subdir_libmagic] Error code 2 make[3]: stopped in --- all_subdir_libarchive --- A failure has been detected in another branch of the parallel make make[4]: stopped in *** [all_subdir_libarchive] Error code 2 make[3]: stopped in 2 errors make[3]: stopped in *** [lib.all__D] Error code 2 make[2]: stopped in --- usr.bin.all__D --- A failure has been detected in another branch of the parallel make make[5]: stopped in *** [all_subdir_tblgen] Error code 2 make[4]: stopped in 1 error make[4]: stopped in *** [all_subdir_clang] Error code 2 make[3]: stopped in 1 error make[3]: stopped in *** [usr.bin.all__D] Error code 2 make[2]: stopped in 3 errors make[2]: stopped in *** [everything] Error code 2 make[1]: stopped in 1 error make[1]: stopped in *** [buildworld] Error code 2 make: stopped in 1 error make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-stable@FreeBSD.ORG Fri Mar 27 12:13:33 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 374BF23E for ; Fri, 27 Mar 2015 12:13:33 +0000 (UTC) Received: from f316.i.mail.ru (f316.i.mail.ru [128.140.169.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 BE50794A for ; Fri, 27 Mar 2015 12:13:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=inbox.ru; s=mail; h=References:In-Reply-To:Content-Type:Message-ID:Reply-To:Date:MIME-Version:Subject:Cc:To:From; bh=ihAM2CzSsLpzRR7BeTzNSzehIBQTRGE4lxs2RP2d884=; b=LXCmDqaoLNNIIaXfZ7Wm6BI0lTKT/OdMC1CCU2+HsKIBffH1g/bf7HTFf02ULqCeBkzY52aY2j8Hn+SX0Htc5YiiWnzF8quJmyCT+No+NfuJPe6c81FLhMIIBq2rpuegQ6GBUdocrXwdohkwyJgafDTX5Xk8yqtQFEpfsfS3Mzw=; Received: from [77.232.152.85] (ident=mail) by f316.i.mail.ru with local (envelope-from ) id 1YbT8b-0001BG-0Q; Fri, 27 Mar 2015 15:13:21 +0300 Received: from [77.232.152.85] by e.mail.ru with HTTP; Fri, 27 Mar 2015 15:13:20 +0300 From: =?UTF-8?B?YXJtb25pYQ==?= To: =?UTF-8?B?TWljaGVsbGUgU3VsbGl2YW4=?= Subject: =?UTF-8?B?UmVbMl06IFpGUyBvdXQgb2Ygc3dhcCBzcGFjZQ==?= MIME-Version: 1.0 X-Mailer: Mail.Ru Mailer 1.0 X-Originating-IP: [77.232.152.85] Date: Fri, 27 Mar 2015 15:13:20 +0300 Reply-To: =?UTF-8?B?YXJtb25pYQ==?= X-Priority: 3 (Normal) Message-ID: <1427458400.614211926@f316.i.mail.ru> X-Mras: Ok X-Spam: undefined In-Reply-To: <5512D918.9090602@sorbs.net> References: <1427296089.943477941@f273.i.mail.ru> <5512D918.9090602@sorbs.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 12:13:33 -0000 CldoZW4geW91IHRyeSB0byBpbXBvcnQKCnBpZCAzMiAoenBvb2wpLCB1aWQgMCwgd2FzIGtpbGxl ZDogb3V0IG9mIHN3YXAgc3BhY2UgCgpNYXliZSBoZWxwIHRvIGNyZWF0ZSBzd2FwIHBhcnRpdGlv biBkaXJlY3RseSBpbnRvIHRoZSBMaXZlVVNCID8gCgrQodGA0LXQtNCwLCAyNSDQvNCw0YDRgtCw IDIwMTUsIDE2OjQ5ICswMTowMCDQvtGCIE1pY2hlbGxlIFN1bGxpdmFuIDxtaWNoZWxsZUBzb3Ji cy5uZXQ+Ogo+YXJtb25pYSB3cm90ZToKPj4KPj4gLS0gSGVsbG8uIFBsZWFzZSBoZWxwIC4gSSBt aXJyb3IgWkZTIDkuMyAsIGFmdGVyIGFuIGFjdGl2ZSBpdCBieSB1c2luZyBteXNxbCByZWFkIFwg d3JpdGUgZnJvbSBhbiBleHRlcm5hbCBzY3JpcHQgc29tZXRoaW5nIGJyb2tlbi4gVGhlIG9wZXJh dGluZyBzeXN0ZW0gaXMgbm90IGxvYWRlZCBhdCB0aGUgdGltZSBvZiAiTW91bnQgbG9jYWwgZmls ZXN5c3RlbXMiCj4+Cj4+IHBvb2wgY29uc2lzdHMgb2YgYSBtaXJyb3IgKHJhaWQgMSApICsgaG90 IHN3YXAsIHpmcyBwYXJ0aXRpb25zIG9uIGEgc2VwYXJhdGUgLgo+Pgo+PiB6cG9vbCBpbXBvcnQg LWYgLVIgL3RtcCB6cm9vdCBmcmVlemVzCj4+Cj4+IHRyeSB0byBpbXBvcnQgYSBwb29sIGZyb20g YSBMaXZlQ0QgKDEwLjEpIC0+IHpwb29sIGltcG9ydCAtZiAtUiAvIHRtcCB6cm9vdCBvdXQgYXMg aW4gZGVlcCB0aG91Z2h0IGFuZCB0aGVuIHdyb3RlIHNvbWV0aGluZyBsaWtlCj4+Cj4+IHBpZCA5 OTIxNyAoc2gpLCB1aWQgMCwgd2FzIGtpbGxlZDogb3V0IG9mIHN3YXAgc3BhY2UKPj4gcGlkIDg5 NiAoc3NoKSwgdWlkIDAsIHdhcyBraWxsZWQ6IG91dCBvZiBzd2FwIHNwYWNlCj4+Cj4+IHpwb29s IG1hZGUgb2YgMiBkaXNrcyB0byBHUFQgYW5kIG9uZSBhcyBob3Qtc3dhcC4KPj4gCj4KPldyaXRl IGEgMTEtU1RBQkxFIFVTQiBkcml2ZSBib290IGZyb20gaXQgdG8gc2luZ2xlIHVzZXIsIHJ1biB5 b3VyCj5pbXBvcnQsIHRoZW4gcnVuIGFuIGV4cG9ydCwgdGhlbiByZWJvb3QgaW50byA5LjMgYW5k IGltcG9ydCB3aXRob3V0IGZsYWdzLgo+Cj5SZWdhcmRzLAo+Cj4tLSAKPk1pY2hlbGxlIFN1bGxp dmFuCj5odHRwOi8vd3d3Lm1oaXgub3JnLwo+Cj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwo+ZnJlZWJzZC1zdGFibGVAZnJlZWJzZC5vcmcgbWFpbGluZyBs aXN0Cj5odHRwOi8vbGlzdHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmVlYnNkLXN0 YWJsZQo+VG8gdW5zdWJzY3JpYmUsIHNlbmQgYW55IG1haWwgdG8gIiBmcmVlYnNkLXN0YWJsZS11 bnN1YnNjcmliZUBmcmVlYnNkLm9yZyAiCgoKLS0gCg== From owner-freebsd-stable@FreeBSD.ORG Fri Mar 27 12:32:55 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7248A7BD for ; Fri, 27 Mar 2015 12:32:55 +0000 (UTC) Received: from fallback1.mail.ru (fallback1.mail.ru [94.100.181.184]) by mx1.freebsd.org (Postfix) with ESMTP id 68CC1B9E for ; Fri, 27 Mar 2015 12:32:54 +0000 (UTC) Received: from f405.i.mail.ru (f405.i.mail.ru [185.5.136.76]) by fallback1.mail.ru (mPOP.Fallback_MX) with ESMTP id 3AAA0542FE00 for ; Fri, 27 Mar 2015 15:00:00 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=inbox.ru; s=mail; h=References:In-Reply-To:Content-Type:Message-ID:Reply-To:Date:MIME-Version:Subject:Cc:To:From; bh=DU1HQVl5iQ3PKq+bEKVfEiCE0V5ixtcBVt/83JWc+WE=; b=Quo+U3hNOgQJzHKgplxxxrLQf85ZfFwySe9uy6gQfBvESUUzL1t75/QduS2+46D7r15rqBVsYMBf/hzo/N9Ha7uAaiLjMDms85CAkhB7pa4Q0yZTppwrKMB4q2hCuENMfwLO60PNJdnRzJTkynLNbkeinX40UuySiMjWMvRKWTU=; Received: from [77.232.152.85] (ident=mail) by f405.i.mail.ru with local (envelope-from ) id 1YbSvV-0004Wa-Hq; Fri, 27 Mar 2015 14:59:50 +0300 Received: from [77.232.152.85] by e.mail.ru with HTTP; Fri, 27 Mar 2015 14:59:49 +0300 From: =?UTF-8?B?YXJtb25pYQ==?= To: =?UTF-8?B?TWljaGVsbGUgU3VsbGl2YW4=?= Subject: =?UTF-8?B?UmVbMl06IFpGUyBvdXQgb2Ygc3dhcCBzcGFjZQ==?= MIME-Version: 1.0 X-Mailer: Mail.Ru Mailer 1.0 X-Originating-IP: [77.232.152.85] Date: Fri, 27 Mar 2015 14:59:49 +0300 Reply-To: =?UTF-8?B?YXJtb25pYQ==?= X-Priority: 3 (Normal) Message-ID: <1427457589.268849505@f405.i.mail.ru> X-Mras: Ok X-Spam: undefined In-Reply-To: <5512D918.9090602@sorbs.net> References: <1427296089.943477941@f273.i.mail.ru> <5512D918.9090602@sorbs.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 12:32:55 -0000 IE5vdCBzb2x2ZSB0aGUgcHJvYmxlbSAsIEkgYm9vdGVkIGZyb20gMTEuMCBTVEFCTEUgYW5kIHdo ZW4geW91IHRyeSB0byBpbXBvcnQgYSBwb29sIHN5c3RlbSBnb2VzIGludG8gZnJlZXplIC4gKHpw b29sIGltcG9ydCAtZiB6cm9vdCkKCkp1c3QgaGFuZyB3aGVuIGF0dGVtcHRpbmcgdG8gbW91bnQg dGhlIHByb2JsZW1hdGljIHNlY3Rpb24genJvb3QgLyB2YXIgLyBkYiAvIG15c3FsIC8gYmlsbGlu ZwoKSW4gdGhpcyBob21lIGFyZSBpbnN0YWxsZWQgcHJvcGVybHkgLCBJIGV2ZW4gcmVtb3ZlZCB0 aHJvdWdoIHRydW5jYXRlIC1zIDAgMTUgZ2lncyBpbiB0aGUgZmlsZSAvIGhvbWUgLyB1c2VyLCBi dXQgaXQgZG9lcyBub3QgaGVscCAuCgpNb3JlIG9wdGlvbnMgPyBBbGwgYXR0ZW1wdHMgdG8gZnJl ZXplIG1vdW50IGxlYWQgYXMgd2VsbCBhcyBhdHRlbXB0cyB0byBib290IHRoZSBzeXN0ZW0uCgoK 0KHRgNC10LTQsCwgMjUg0LzQsNGA0YLQsCAyMDE1LCAxNjo0OSArMDE6MDAg0L7RgiBNaWNoZWxs ZSBTdWxsaXZhbiA8bWljaGVsbGVAc29yYnMubmV0PjoKPmFybW9uaWEgd3JvdGU6Cj4+Cj4+IC0t IEhlbGxvLiBQbGVhc2UgaGVscCAuIEkgbWlycm9yIFpGUyA5LjMgLCBhZnRlciBhbiBhY3RpdmUg aXQgYnkgdXNpbmcgbXlzcWwgcmVhZCBcIHdyaXRlIGZyb20gYW4gZXh0ZXJuYWwgc2NyaXB0IHNv bWV0aGluZyBicm9rZW4uIFRoZSBvcGVyYXRpbmcgc3lzdGVtIGlzIG5vdCBsb2FkZWQgYXQgdGhl IHRpbWUgb2YgIk1vdW50IGxvY2FsIGZpbGVzeXN0ZW1zIgo+Pgo+PiBwb29sIGNvbnNpc3RzIG9m IGEgbWlycm9yIChyYWlkIDEgKSArIGhvdCBzd2FwLCB6ZnMgcGFydGl0aW9ucyBvbiBhIHNlcGFy YXRlIC4KPj4KPj4genBvb2wgaW1wb3J0IC1mIC1SIC90bXAgenJvb3QgZnJlZXplcwo+Pgo+PiB0 cnkgdG8gaW1wb3J0IGEgcG9vbCBmcm9tIGEgTGl2ZUNEICgxMC4xKSAtPiB6cG9vbCBpbXBvcnQg LWYgLVIgLyB0bXAgenJvb3Qgb3V0IGFzIGluIGRlZXAgdGhvdWdodCBhbmQgdGhlbiB3cm90ZSBz b21ldGhpbmcgbGlrZQo+Pgo+PiBwaWQgOTkyMTcgKHNoKSwgdWlkIDAsIHdhcyBraWxsZWQ6IG91 dCBvZiBzd2FwIHNwYWNlCj4+IHBpZCA4OTYgKHNzaCksIHVpZCAwLCB3YXMga2lsbGVkOiBvdXQg b2Ygc3dhcCBzcGFjZQo+Pgo+PiB6cG9vbCBtYWRlIG9mIDIgZGlza3MgdG8gR1BUIGFuZCBvbmUg YXMgaG90LXN3YXAuCj4+IAo+Cj5Xcml0ZSBhIDExLVNUQUJMRSBVU0IgZHJpdmUgYm9vdCBmcm9t IGl0IHRvIHNpbmdsZSB1c2VyLCBydW4geW91cgo+aW1wb3J0LCB0aGVuIHJ1biBhbiBleHBvcnQs IHRoZW4gcmVib290IGludG8gOS4zIGFuZCBpbXBvcnQgd2l0aG91dCBmbGFncy4KPgo+UmVnYXJk cywKPgo+LS0gCj5NaWNoZWxsZSBTdWxsaXZhbgo+aHR0cDovL3d3dy5taGl4Lm9yZy8KPgo+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPmZyZWVic2Qtc3Rh YmxlQGZyZWVic2Qub3JnIG1haWxpbmcgbGlzdAo+aHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL21h aWxtYW4vbGlzdGluZm8vZnJlZWJzZC1zdGFibGUKPlRvIHVuc3Vic2NyaWJlLCBzZW5kIGFueSBt YWlsIHRvICIgZnJlZWJzZC1zdGFibGUtdW5zdWJzY3JpYmVAZnJlZWJzZC5vcmcgIgoKCi0tIAo= From owner-freebsd-stable@FreeBSD.ORG Fri Mar 27 12:42:09 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 90330A95 for ; Fri, 27 Mar 2015 12:42:09 +0000 (UTC) Received: from fallback3.mail.ru (fallback3.mail.ru [94.100.181.189]) by mx1.freebsd.org (Postfix) with ESMTP id F24A5CC1 for ; Fri, 27 Mar 2015 12:42:08 +0000 (UTC) Received: from f65.i.mail.ru (f65.i.mail.ru [94.100.178.231]) by fallback3.mail.ru (mPOP.Fallback_MX) with ESMTP id 6C30B148F4002 for ; Fri, 27 Mar 2015 15:26:33 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=inbox.ru; s=mail; h=References:In-Reply-To:Content-Type:Message-ID:Reply-To:Date:MIME-Version:Subject:Cc:To:From; bh=26zSbOvFKMFKMwi0PHAQbzw8fJXMgd7QM/kreoK8TNw=; b=mwPqrk3gUKKNK42xYaIvjAsgp3KUUh2TSFf/iViqDweBRA5L2l1M+iE8mY5hFA5tPZT5xI7eA9V7hOUWC49Qj1whWRiRPlr9wVBV2cnrkuBvTPfGlRbTYlAfQdHa1o2xjStDaKwPAmf/ixrw1caHMAuu0Mq1rZoanvgrPsVVnpM=; Received: from [77.232.152.85] (ident=mail) by f65.i.mail.ru with local (envelope-from ) id 1YbTLD-0006I3-MW; Fri, 27 Mar 2015 15:26:24 +0300 Received: from [77.232.152.85] by e.mail.ru with HTTP; Fri, 27 Mar 2015 15:26:23 +0300 From: =?UTF-8?B?YXJtb25pYQ==?= To: =?UTF-8?B?TWljaGVsbGUgU3VsbGl2YW4=?= Subject: =?UTF-8?B?UmVbMl06IFpGUyBvdXQgb2Ygc3dhcCBzcGFjZQ==?= MIME-Version: 1.0 X-Mailer: Mail.Ru Mailer 1.0 X-Originating-IP: [77.232.152.85] Date: Fri, 27 Mar 2015 15:26:23 +0300 Reply-To: =?UTF-8?B?YXJtb25pYQ==?= X-Priority: 3 (Normal) Message-ID: <1427459183.547453802@f65.i.mail.ru> X-Mras: Ok X-Spam: undefined In-Reply-To: <5512D918.9090602@sorbs.net> References: <1427296089.943477941@f273.i.mail.ru> <5512D918.9090602@sorbs.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 12:42:09 -0000 IEFmdGVyIGltcG9ydGluZyBJIHByZXNzIGN0cmwgKyB0IGFuZCBoZXJlJ3MgdGhlIGNvbmNsdXNp b246IAoKbG9hZDogMC4yMCBjbWQ6IHpwb29sIDcyNSBbdHgtPnR4X3N5bmNfZG9uZV9jdl0gMzIu NTByIDAuMDB5IDUuNTlzIDAlIDY0MzJrCgoK0KHRgNC10LTQsCwgMjUg0LzQsNGA0YLQsCAyMDE1 LCAxNjo0OSArMDE6MDAg0L7RgiBNaWNoZWxsZSBTdWxsaXZhbiA8bWljaGVsbGVAc29yYnMubmV0 PjoKPmFybW9uaWEgd3JvdGU6Cj4+Cj4+IC0tIEhlbGxvLiBQbGVhc2UgaGVscCAuIEkgbWlycm9y IFpGUyA5LjMgLCBhZnRlciBhbiBhY3RpdmUgaXQgYnkgdXNpbmcgbXlzcWwgcmVhZCBcIHdyaXRl IGZyb20gYW4gZXh0ZXJuYWwgc2NyaXB0IHNvbWV0aGluZyBicm9rZW4uIFRoZSBvcGVyYXRpbmcg c3lzdGVtIGlzIG5vdCBsb2FkZWQgYXQgdGhlIHRpbWUgb2YgIk1vdW50IGxvY2FsIGZpbGVzeXN0 ZW1zIgo+Pgo+PiBwb29sIGNvbnNpc3RzIG9mIGEgbWlycm9yIChyYWlkIDEgKSArIGhvdCBzd2Fw LCB6ZnMgcGFydGl0aW9ucyBvbiBhIHNlcGFyYXRlIC4KPj4KPj4genBvb2wgaW1wb3J0IC1mIC1S IC90bXAgenJvb3QgZnJlZXplcwo+Pgo+PiB0cnkgdG8gaW1wb3J0IGEgcG9vbCBmcm9tIGEgTGl2 ZUNEICgxMC4xKSAtPiB6cG9vbCBpbXBvcnQgLWYgLVIgLyB0bXAgenJvb3Qgb3V0IGFzIGluIGRl ZXAgdGhvdWdodCBhbmQgdGhlbiB3cm90ZSBzb21ldGhpbmcgbGlrZQo+Pgo+PiBwaWQgOTkyMTcg KHNoKSwgdWlkIDAsIHdhcyBraWxsZWQ6IG91dCBvZiBzd2FwIHNwYWNlCj4+IHBpZCA4OTYgKHNz aCksIHVpZCAwLCB3YXMga2lsbGVkOiBvdXQgb2Ygc3dhcCBzcGFjZQo+Pgo+PiB6cG9vbCBtYWRl IG9mIDIgZGlza3MgdG8gR1BUIGFuZCBvbmUgYXMgaG90LXN3YXAuCj4+IAo+Cj5Xcml0ZSBhIDEx LVNUQUJMRSBVU0IgZHJpdmUgYm9vdCBmcm9tIGl0IHRvIHNpbmdsZSB1c2VyLCBydW4geW91cgo+ aW1wb3J0LCB0aGVuIHJ1biBhbiBleHBvcnQsIHRoZW4gcmVib290IGludG8gOS4zIGFuZCBpbXBv cnQgd2l0aG91dCBmbGFncy4KPgo+UmVnYXJkcywKPgo+LS0gCj5NaWNoZWxsZSBTdWxsaXZhbgo+ aHR0cDovL3d3dy5taGl4Lm9yZy8KPgo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KPmZyZWVic2Qtc3RhYmxlQGZyZWVic2Qub3JnIG1haWxpbmcgbGlzdAo+ aHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWJzZC1zdGFibGUK PlRvIHVuc3Vic2NyaWJlLCBzZW5kIGFueSBtYWlsIHRvICIgZnJlZWJzZC1zdGFibGUtdW5zdWJz Y3JpYmVAZnJlZWJzZC5vcmcgIgoKCi0tIAo= From owner-freebsd-stable@FreeBSD.ORG Fri Mar 27 12:59:35 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8342BF8A for ; Fri, 27 Mar 2015 12:59:35 +0000 (UTC) Received: from hades.sorbs.net (mail.sorbs.net [67.231.146.200]) by mx1.freebsd.org (Postfix) with ESMTP id 6D884E10 for ; Fri, 27 Mar 2015 12:59:34 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=UTF-8 Received: from isux.com (firewall.isux.com [213.165.190.213]) by hades.sorbs.net (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPSA id <0NLV00908GBZEZ00@hades.sorbs.net> for freebsd-stable@freebsd.org; Fri, 27 Mar 2015 06:04:49 -0700 (PDT) Message-id: <55155433.7030400@sorbs.net> Date: Fri, 27 Mar 2015 13:59:31 +0100 From: Michelle Sullivan User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.24) Gecko/20100301 SeaMonkey/1.1.19 To: armonia Subject: Re: ZFS out of swap space References: <1427296089.943477941@f273.i.mail.ru> <5512D918.9090602@sorbs.net> <1427457589.268849505@f405.i.mail.ru> In-reply-to: <1427457589.268849505@f405.i.mail.ru> Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 12:59:35 -0000 armonia wrote: > Not solve the problem, I booted from 11.0 STABLE and when you try to > import a pool system goes into freeze. (zpool import -f zroot) > > Just hang when attempting to mount the problematic section zroot / var > / db / mysql / billing > > In this home are installed properly, I even removed through truncate > -s 0 15 gigs in the file / home / user, but it does not help. > > More options? All attempts to freeze mount lead as well as attempts to > boot the system. > All I can suggest is boot and wait - see if it comes back - if not I am out of suggestions - "zfs import -Ff storage" worked for me when I was running out of swap when trying to import on a 9.2 system (storage being my pool name) After the import I exported booted back to 9.2 and it all worked... issued a 'scrub' *after* booting back to 9.2 (don't do it before) Michelle > > Среда, 25 марта 2015, 16:49 +01:00 от Michelle Sullivan > : > > armonia wrote: > > > > -- Hello. Please help . I mirror ZFS 9.3 , after an active it by > using mysql read \ write from an external script something broken. > The operating system is not loaded at the time of "Mount local > filesystems" > > > > pool consists of a mirror (raid 1 ) + hot swap, zfs partitions > on a separate . > > > > zpool import -f -R /tmp zroot freezes > > > > try to import a pool from a LiveCD (10.1) -> zpool import -f -R > / tmp zroot out as in deep thought and then wrote something like > > > > pid 99217 (sh), uid 0, was killed: out of swap space > > pid 896 (ssh), uid 0, was killed: out of swap space > > > > zpool made of 2 disks to GPT and one as hot-swap. > > > > Write a 11-STABLE USB drive boot from it to single user, run your > import, then run an export, then reboot into 9.3 and import > without flags. > > Regards, > > -- > Michelle Sullivan > http://www.mhix.org/ > > _______________________________________________ > freebsd-stable@freebsd.org > mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org > " > > > > -- -- Michelle Sullivan http://www.mhix.org/ From owner-freebsd-stable@FreeBSD.ORG Fri Mar 27 13:36:53 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 55F26141 for ; Fri, 27 Mar 2015 13:36:53 +0000 (UTC) Received: from fallback6.mail.ru (fallback6.mail.ru [94.100.181.147]) by mx1.freebsd.org (Postfix) with ESMTP id 907942E5 for ; Fri, 27 Mar 2015 13:36:52 +0000 (UTC) Received: from f180.i.mail.ru (f180.i.mail.ru [217.69.128.221]) by fallback6.mail.ru (mPOP.Fallback_MX) with ESMTP id 6058B385D15 for ; Fri, 27 Mar 2015 16:19:34 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=inbox.ru; s=mail; h=References:In-Reply-To:Content-Type:Message-ID:Reply-To:Date:MIME-Version:Subject:Cc:To:From; bh=RiVOg0yT+85vqZOh7aVvGTNkxgDykBNxXF37HzKCRs0=; b=H9JBFJgy044LCyCPdAk5irPu4PLABQhNHNRGFscWM2J0QsipeuBXtqcMtaIp9quEC9HWV/1ep19BZGNGg0x1xIOiwoCsN/i22o3owHn/FYMOQGvQIpFgSA7Z21ePYrjXRlshN2lTgtQPrxwL6VYhjBjnKQFiH9H9Dw7587d4xbc=; Received: from [77.232.152.85] (ident=mail) by f180.i.mail.ru with local (envelope-from ) id 1YbUAW-0005Fc-3P; Fri, 27 Mar 2015 16:19:24 +0300 Received: from [77.232.152.85] by e.mail.ru with HTTP; Fri, 27 Mar 2015 16:19:23 +0300 From: =?UTF-8?B?YXJtb25pYQ==?= To: =?UTF-8?B?TWljaGVsbGUgU3VsbGl2YW4=?= Subject: =?UTF-8?B?UmVbMl06IFpGUyBvdXQgb2Ygc3dhcCBzcGFjZQ==?= MIME-Version: 1.0 X-Mailer: Mail.Ru Mailer 1.0 X-Originating-IP: [77.232.152.85] Date: Fri, 27 Mar 2015 16:19:23 +0300 Reply-To: =?UTF-8?B?YXJtb25pYQ==?= X-Priority: 3 (Normal) Message-ID: <1427462363.48516598@f180.i.mail.ru> X-Mras: Ok X-Spam: undefined In-Reply-To: <55155433.7030400@sorbs.net> References: <1427296089.943477941@f273.i.mail.ru> <1427457589.268849505@f405.i.mail.ru> <55155433.7030400@sorbs.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 13:36:53 -0000 IEhvdyBtdWNoIGFyZSB5b3Ugd2FpdGluZyB0aW1lIGFmdGVyIGltcG9ydCA/CgpMb29rIGEgc2Ny ZWVuc2hvdCA6CgpodHRwOi8vaTU4LnRpbnlwaWMuY29tL212a2owMC5qcGcKCkl0IGhlbHBlZCB5 b3UgYmVjYXVzZSB5b3UgY2VydGFpbmx5IGRvIGltcG9ydCAxMSBicmFuY2ggPwoKCtCf0Y/RgtC9 0LjRhtCwLCAyNyDQvNCw0YDRgtCwIDIwMTUsIDEzOjU5ICswMTowMCDQvtGCIE1pY2hlbGxlIFN1 bGxpdmFuIDxtaWNoZWxsZUBzb3Jicy5uZXQ+Ogo+YXJtb25pYSB3cm90ZToKPj4gTm90IHNvbHZl IHRoZSBwcm9ibGVtLCBJIGJvb3RlZCBmcm9tIDExLjAgU1RBQkxFIGFuZCB3aGVuIHlvdSB0cnkg dG8KPj4gaW1wb3J0IGEgcG9vbCBzeXN0ZW0gZ29lcyBpbnRvIGZyZWV6ZS4gKHpwb29sIGltcG9y dCAtZiB6cm9vdCkKPj4KPj4gSnVzdCBoYW5nIHdoZW4gYXR0ZW1wdGluZyB0byBtb3VudCB0aGUg cHJvYmxlbWF0aWMgc2VjdGlvbiB6cm9vdCAvIHZhcgo+PiAvIGRiIC8gbXlzcWwgLyBiaWxsaW5n Cj4+Cj4+IEluIHRoaXMgaG9tZSBhcmUgaW5zdGFsbGVkIHByb3Blcmx5LCBJIGV2ZW4gcmVtb3Zl ZCB0aHJvdWdoIHRydW5jYXRlCj4+IC1zIDAgMTUgZ2lncyBpbiB0aGUgZmlsZSAvIGhvbWUgLyB1 c2VyLCBidXQgaXQgZG9lcyBub3QgaGVscC4KPj4KPj4gTW9yZSBvcHRpb25zPyBBbGwgYXR0ZW1w dHMgdG8gZnJlZXplIG1vdW50IGxlYWQgYXMgd2VsbCBhcyBhdHRlbXB0cyB0bwo+PiBib290IHRo ZSBzeXN0ZW0uCj4+Cj5BbGwgSSBjYW4gc3VnZ2VzdCBpcyBib290IGFuZCB3YWl0IC0gc2VlIGlm IGl0IGNvbWVzIGJhY2sgLSBpZiBub3QgSSBhbQo+b3V0IG9mIHN1Z2dlc3Rpb25zIC0gInpmcyBp bXBvcnQgLUZmIHN0b3JhZ2UiIHdvcmtlZCBmb3IgbWUgd2hlbiBJIHdhcwo+cnVubmluZyBvdXQg b2Ygc3dhcCB3aGVuIHRyeWluZyB0byBpbXBvcnQgb24gYSA5LjIgc3lzdGVtIChzdG9yYWdlIGJl aW5nCj5teSBwb29sIG5hbWUpCj4KPkFmdGVyIHRoZSBpbXBvcnQgSSBleHBvcnRlZCBib290ZWQg YmFjayB0byA5LjIgYW5kIGl0IGFsbCB3b3JrZWQuLi4KPmlzc3VlZCBhICdzY3J1YicgKmFmdGVy KiBib290aW5nIGJhY2sgdG8gOS4yIChkb24ndCBkbyBpdCBiZWZvcmUpCj4KPk1pY2hlbGxlCj4K Pj4KPj4g0KHRgNC10LTQsCwgMjUg0LzQsNGA0YLQsCAyMDE1LCAxNjo0OSArMDE6MDAg0L7RgiBN aWNoZWxsZSBTdWxsaXZhbgo+PiA8IG1pY2hlbGxlQHNvcmJzLm5ldCA+Ogo+Pgo+PiAgICAgYXJt b25pYSB3cm90ZToKPj4gICAgID4KPj4gICAgID4gLS0gSGVsbG8uIFBsZWFzZSBoZWxwIC4gSSBt aXJyb3IgWkZTIDkuMyAsIGFmdGVyIGFuIGFjdGl2ZSBpdCBieQo+PiAgICAgdXNpbmcgbXlzcWwg cmVhZCBcIHdyaXRlIGZyb20gYW4gZXh0ZXJuYWwgc2NyaXB0IHNvbWV0aGluZyBicm9rZW4uCj4+ ICAgICBUaGUgb3BlcmF0aW5nIHN5c3RlbSBpcyBub3QgbG9hZGVkIGF0IHRoZSB0aW1lIG9mICJN b3VudCBsb2NhbAo+PiAgICAgZmlsZXN5c3RlbXMiCj4+ICAgICA+Cj4+ICAgICA+IHBvb2wgY29u c2lzdHMgb2YgYSBtaXJyb3IgKHJhaWQgMSApICsgaG90IHN3YXAsIHpmcyBwYXJ0aXRpb25zCj4+ ICAgICBvbiBhIHNlcGFyYXRlIC4KPj4gICAgID4KPj4gICAgID4genBvb2wgaW1wb3J0IC1mIC1S IC90bXAgenJvb3QgZnJlZXplcwo+PiAgICAgPgo+PiAgICAgPiB0cnkgdG8gaW1wb3J0IGEgcG9v bCBmcm9tIGEgTGl2ZUNEICgxMC4xKSAtPiB6cG9vbCBpbXBvcnQgLWYgLVIKPj4gICAgIC8gdG1w IHpyb290IG91dCBhcyBpbiBkZWVwIHRob3VnaHQgYW5kIHRoZW4gd3JvdGUgc29tZXRoaW5nIGxp a2UKPj4gICAgID4KPj4gICAgID4gcGlkIDk5MjE3IChzaCksIHVpZCAwLCB3YXMga2lsbGVkOiBv dXQgb2Ygc3dhcCBzcGFjZQo+PiAgICAgPiBwaWQgODk2IChzc2gpLCB1aWQgMCwgd2FzIGtpbGxl ZDogb3V0IG9mIHN3YXAgc3BhY2UKPj4gICAgID4KPj4gICAgID4genBvb2wgbWFkZSBvZiAyIGRp c2tzIHRvIEdQVCBhbmQgb25lIGFzIGhvdC1zd2FwLgo+PiAgICAgPgo+Pgo+PiAgICAgV3JpdGUg YSAxMS1TVEFCTEUgVVNCIGRyaXZlIGJvb3QgZnJvbSBpdCB0byBzaW5nbGUgdXNlciwgcnVuIHlv dXIKPj4gICAgIGltcG9ydCwgdGhlbiBydW4gYW4gZXhwb3J0LCB0aGVuIHJlYm9vdCBpbnRvIDku MyBhbmQgaW1wb3J0Cj4+ICAgICB3aXRob3V0IGZsYWdzLgo+Pgo+PiAgICAgUmVnYXJkcywKPj4K Pj4gICAgIC0tIAo+PiAgICAgTWljaGVsbGUgU3VsbGl2YW4KPj4gIGh0dHA6Ly93d3cubWhpeC5v cmcvCj4+Cj4+ICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwo+PiAgZnJlZWJzZC1zdGFibGVAZnJlZWJzZC5vcmcKPj4gICAgIDwgL2NvbXBvc2U/VG89 ZnJlZWJzZCUyZHN0YWJsZUBmcmVlYnNkLm9yZyA+IG1haWxpbmcgbGlzdAo+PiAgaHR0cDovL2xp c3RzLmZyZWVic2Qub3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWJzZC1zdGFibGUKPj4gICAgIFRv IHVuc3Vic2NyaWJlLCBzZW5kIGFueSBtYWlsIHRvCj4+ICAgICAiIGZyZWVic2Qtc3RhYmxlLXVu c3Vic2NyaWJlQGZyZWVic2Qub3JnCj4+ICAgICA8IC9jb21wb3NlP1RvPWZyZWVic2QlMmRzdGFi bGUlMmR1bnN1YnNjcmliZUBmcmVlYnNkLm9yZyA+Igo+Pgo+Pgo+Pgo+PiAtLSAKPgo+Cj4tLSAK Pk1pY2hlbGxlIFN1bGxpdmFuCj5odHRwOi8vd3d3Lm1oaXgub3JnLwo+CgoKLS0gCg== From owner-freebsd-stable@FreeBSD.ORG Fri Mar 27 14:20:08 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A945D70; Fri, 27 Mar 2015 14:20:08 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 7884CA76; Fri, 27 Mar 2015 14:20:08 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 251802F0; Fri, 27 Mar 2015 14:20:07 +0000 (UTC) Date: Fri, 27 Mar 2015 14:20:05 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-stable@freebsd.org, mav@FreeBSD.org Message-ID: <1439797068.3.1427466006420.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <781335995.2.1427452155665.JavaMail.jenkins@jenkins-9.freebsd.org> References: <781335995.2.1427452155665.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_stable_10 #1322 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 14:20:08 -0000 See From owner-freebsd-stable@FreeBSD.ORG Fri Mar 27 17:07:04 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6BDA2514 for ; Fri, 27 Mar 2015 17:07:04 +0000 (UTC) Received: from hades.sorbs.net (mail.sorbs.net [67.231.146.200]) by mx1.freebsd.org (Postfix) with ESMTP id 56C5A35B for ; Fri, 27 Mar 2015 17:07:03 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from isux.com (firewall.isux.com [213.165.190.213]) by hades.sorbs.net (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPSA id <0NLV0092CRSHEZ00@hades.sorbs.net> for freebsd-stable@freebsd.org; Fri, 27 Mar 2015 10:12:18 -0700 (PDT) Message-id: <55158E34.7080805@sorbs.net> Date: Fri, 27 Mar 2015 18:07:00 +0100 From: Michelle Sullivan User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.24) Gecko/20100301 SeaMonkey/1.1.19 To: armonia Subject: Re: ZFS out of swap space References: <1427296089.943477941@f273.i.mail.ru> <1427457589.268849505@f405.i.mail.ru> <55155433.7030400@sorbs.net> <1427462363.48516598@f180.i.mail.ru> In-reply-to: <1427462363.48516598@f180.i.mail.ru> Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 17:07:04 -0000 armonia wrote: > How much are you waiting time after import? I was waiting for 4 days for the import to complete - however I do have a 16 drive 48T pool. > > Look a screenshot: > > http://i58.tinypic.com/mvkj00.jpg > > It helped you because you certainly do import 11 branch? > It helped because there was some patches in the 11 branch that handle errors in the pool better than in 9.x... when it imported I was then able to export and restart back to 9.x which corrected the uncaught errors and it was importable straight back into 9.x.. I was then able to correct the rest of the errors by doing a scrub in 9.x (which ultimately was all caused by power, ups and battery failure whilst in the middle of a resilver. Regards, -- Michelle Sullivan http://www.mhix.org/ From owner-freebsd-stable@FreeBSD.ORG Sat Mar 28 02:51:11 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B4895BE; Sat, 28 Mar 2015 02:51:11 +0000 (UTC) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 770DDE05; Sat, 28 Mar 2015 02:51:11 +0000 (UTC) Received: by iedm5 with SMTP id m5so83957943ied.3; Fri, 27 Mar 2015 19:51:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=KGsUHhnNnB2Z0Iw6/5SWdA9I7lMiI12MR06UWeXxQvg=; b=p83lxohqsflZXy3+ZOdWhNPNMMqirBgJecWa9M2VRj18gSnTHYoLEZc2SqUv6zvkrM 2F2Or9YMqSlPmUNPb2DQGfjydeZESYUrWKr0ijQTPgU6y/Qf50Q2J0/vSYTSr09n9uDV fM4b+oJnJAUn+DBLOFG6wYmkS6BjHXnQuBp91in5efUQDCswUk8JV1SWBE9yDM+/1ZyN FD1jRl5Dh7CRSgY904HSZmgIgFtpuENbIBTDUpdhg8BSDQqitJC5VusgU8JhYMzafOEw 4jlF+BIMjuu/RtTjB2ikEjK2dp27CCTpiy4KnxVd0tl8MoxP4Jv5EBQp9zimJPCkoP0g EWUA== MIME-Version: 1.0 X-Received: by 10.50.67.100 with SMTP id m4mr2686244igt.32.1427511070555; Fri, 27 Mar 2015 19:51:10 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.107.174.86 with HTTP; Fri, 27 Mar 2015 19:51:10 -0700 (PDT) In-Reply-To: References: Date: Fri, 27 Mar 2015 19:51:10 -0700 X-Google-Sender-Auth: R-_mHKucfkUR-SAnhIFUN1PSJKo Message-ID: Subject: Re: 10-STABLE suspend failure From: Kevin Oberman To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD-STABLE Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2015 02:51:11 -0000 On Wed, Mar 25, 2015 at 6:44 PM, Adrian Chadd wrote: > I honestly have no idea, and this is kind of why I didn't want to > commit it to stable/10 without it getting a whole lot more testing. > > Does -HEAD also fail to suspend for you? > > > -a > Good news! Head works and, now that the latest DRM was committed to 10-STABLE on Monday, it works, too. While the DRM update touches all but four of the files in i915, it did not touch intel-opregion.c. In any case, all is well, now. Phew! -- Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-stable@FreeBSD.ORG Sat Mar 28 08:11:53 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F921B14 for ; Sat, 28 Mar 2015 08:11:53 +0000 (UTC) Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 51D6D186 for ; Sat, 28 Mar 2015 08:11:51 +0000 (UTC) Received: from martens-air.fritz.box ([80.101.129.129]) by smtp-cloud3.xs4all.net with ESMTP id 8wAd1q0052nez9401wAerp; Sat, 28 Mar 2015 09:10:38 +0100 From: Marten X-Pgp-Agent: GPGMail 2.5b6 Content-Type: multipart/signed; boundary="Apple-Mail=_10FEABD8-85BC-40D0-8B30-0BCE3D82EF45"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: boostrapping pkg and ipv6 Date: Sat, 28 Mar 2015 09:10:36 +0100 Message-Id: To: stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2015 08:11:53 -0000 --Apple-Mail=_10FEABD8-85BC-40D0-8B30-0BCE3D82EF45 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, While bootstrapping pkg a fresh jail on FreeBSD 10.1 with IPv6 enabled = the process stalls. #uname -a FreeBSD node.vijn.org 10.1-RELEASE-p5 FreeBSD 10.1-RELEASE-p5 #0: Tue = Jan 27 08:55:07 UTC 2015 = root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 -> /etc/jail.conf exec.start =3D "/bin/sh /etc/rc"; exec.stop =3D "/bin/sh /etc/rc.shutdown"; exec.clean; mount.devfs; path =3D "/data/jails/$name"; host.hostname=3D"$name.vijn.org"; node { ip4.addr=3D 192.x.x.22; ip6.addr=3D 2001:980:xxxx:x::22; } root@node:/ # ifconfig nfe0: flags=3D8843 metric 0 mtu = 1500 options=3D8210b ether 90:e6:ba:7a:44:e8 inet 192.x.x.22 netmask 0xffffff00 broadcast 192.x.x.255 inet6 2001:980:xxxx:x::22 prefixlen 64 nd6 options=3D21 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=3D8049 metric 0 mtu 16384 options=3D600003 nd6 options=3D21 root@http:/ # telnet pkg.freebsd.org 80 Trying 2001:41c8:112:8300::50:1... Connected to pkg.freebsd.org. Escape character is '^]'. ^CConnection closed by foreign host. root@http:/ # pkg search node The package management tool is not yet installed on your system. Do you want to fetch and install it now? [y/N]: y Bootstrapping pkg from = pkg+http://pkg.FreeBSD.org/freebsd:10:x86:64/latest, please wait... ^C root@http:/ # pkg -4 search node The package management tool is not yet installed on your system. Do you want to fetch and install it now? [y/N]: y Bootstrapping pkg from = pkg+http://pkg.FreeBSD.org/freebsd:10:x86:64/latest, please wait=E2=80=A6 ^C disabling IPv6 in /etc/jail.conf node { ip4.addr=3D 192.x.x.22; # ip6.addr=3D 2001:980:xxxx:x::22; } # /etc/rc.d/jail restart node # pkg search node The package management tool is not yet installed on your system. Do you want to fetch and install it now? [y/N]: y Bootstrapping pkg from = pkg+http://pkg.FreeBSD.org/freebsd:10:x86:64/latest, please wait... Verifying signature with trusted certificate = pkg.freebsd.org.2013102301... done [node.vijn.org] Installing pkg-1.4.12... [node.vijn.org] Extracting pkg-1.4.12: 100% Message for pkg-1.4.12: If you are upgrading from the old package format, first run: # pkg2ng drupal6-nodewords-6.x.1.14 gstreamer-plugins-annodex-0.10.31_1,3 leafnode-1.11.10_1 monodevelop-5.0.1 monodevelop-database-5.0.1 munin-node-2.0.25_4 node-0.12.0_1 node-devel-0.11.16_1 node-thrift-0.9.1_1 node010-0.10.38 p5-Tree-DAG_Node-1.25 p5-Tree-Node-0.08_2 p5-WebService-Linode-0.27 p5-XML-Node-0.11_1 p5-XML-NodeFilter-0.01_1 xnodecor-0.1_2 -> enabling IPv6 #pkg search node drupal6-nodewords-6.x.1.14 gstreamer-plugins-annodex-0.10.31_1,3 leafnode-1.11.10_1 monodevelop-5.0.1 monodevelop-database-5.0.1 munin-node-2.0.25_4 node-0.12.0_1 node-devel-0.11.16_1 node-thrift-0.9.1_1 node010-0.10.38 p5-Tree-DAG_Node-1.25 p5-Tree-Node-0.08_2 p5-WebService-Linode-0.27 p5-XML-Node-0.11_1 p5-XML-NodeFilter-0.01_1 xnodecor-0.1_2 Any hints to fix this are welcome.. Kind regards, Marten --Apple-Mail=_10FEABD8-85BC-40D0-8B30-0BCE3D82EF45 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 iQEcBAEBCgAGBQJVFmH9AAoJEDVSpuKT0yUEoY0H/jj/ZUlacP8VK+AJVQYyzFbe 9qLHaB71J1LbmjJ6ArRU8n+CXTJXZdJ3pFfgDZHmwkIo2YFUESHbpcXXPHvKErGK as5/KwqIjiio3mP1PceQULtSGYKOtyLPIaOVR2Q661o3he3fiZIgTf6lcBWcQAx/ 6Ej25DtprrIk+AWFliXgvZ25sj3E/yqMK4RwS31d5/VhyZxoYemyixgasOlH2gUy xrR2rk5ei1gFEr0DylQEpNvsQevuGJqeinAiEIrg6yrAejPcFG6AL8Tb3c9Kdgwb 2Fqj/q+Px7Gy9C4WMTkhT/E6X7aT38oyuPsubo1xMgGYL5lJh6wST1YE9+2/WU8= =ELKf -----END PGP SIGNATURE----- --Apple-Mail=_10FEABD8-85BC-40D0-8B30-0BCE3D82EF45--