From owner-freebsd-stable@FreeBSD.ORG Sun Oct 19 18:37:40 2014 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 AD1C2A9B for ; Sun, 19 Oct 2014 18:37:40 +0000 (UTC) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (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 6C7B2886 for ; Sun, 19 Oct 2014 18:37:40 +0000 (UTC) Received: from 2a02-8428-011b-e000-0290-f5ff-fe9d-b78c.rev.sfr.net ([2a02:8428:11b:e000:290:f5ff:fe9d:b78c] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XfvMI-000OXR-Jw for freebsd-stable@freebsd.org; Sun, 19 Oct 2014 20:37:38 +0200 Message-ID: <544404EE.6070609@FreeBSD.org> Date: Sun, 19 Oct 2014 20:37:34 +0200 From: =?windows-1252?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: vt(4) "newcons" and 80x25 vty? (tested: 10.1-BETA2) References: <4490c8c4d489370c7617c0ace9e773be.squirrel@s4bysmmsnraf7eut.onion> <3d80542ccc73686094ddde4e18465e4a.squirrel@s4bysmmsnraf7eut.onion> <2ac3ccbb9ede61a99b0306107ad3846b.squirrel@s4bysmmsnraf7eut.onion> In-Reply-To: <2ac3ccbb9ede61a99b0306107ad3846b.squirrel@s4bysmmsnraf7eut.onion> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="a509DLANpDlBRteA30Qk9iBIOhUmfLCJr" 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, 19 Oct 2014 18:37:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --a509DLANpDlBRteA30Qk9iBIOhUmfLCJr Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi! On 29.09.2014 06:20, beeessdee@ruggedinbox.com wrote: > * hw.vga.textmode=3D1 not affect situation with kms driver loaded: Tin= y > characters, much too many lines/cols. Correct: loading a video driver changes the video mode to the "preferred" mode (usually the screen native resolution). > * VT in VGA textmode fonts loading broken (tested 10.1-BETA2). Tried > vidfont(1) and also vidcontrol -f [size] [filename]. For loading "VGA"= > fonts, screen weird/unusable (see below). For loading Gallant (12x22),= > the virtual terminal freeze (both other vty still ok). Still correct: there's a bug here. In VGA text mode, loading a font should be rejected. The purpose of text mode is to let the video card draw the text itself. > Obvious the 12x22 font (as gallant) will not expect working in > "textmode". And does not work (hangs vty). As stated in previous mail= , > with kms driver vidfont(1) has bug prevent gallant load (but vidcontrol= > -f works). I didn't know this vidfont(1) tool and obviously never tested it. This tools must be revisited for vt(4). Regarding your initial problem, yes, we still have work to do to allow a user to configure a readable font. This is known issue. Unfortunately, it won't make it to 10.1-RELEASE as you mentionned. --=20 Jean-S=E9bastien P=E9dron --a509DLANpDlBRteA30Qk9iBIOhUmfLCJr 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 iQJ8BAEBCgBmBQJURATyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTM/CsQAJ0kpXcVd+GOfe54Mmk9TBj0 pWC+BQDOwm2lecx+EmpR66a7DriJ47mO3YaQvTnDhKAMVJ6f1IYCLU2E5WlDM2eM +HaG75+rs4Pm+knTcmwphLCMwH8CdYfvYHW68DJ8B2MNHUudrE288zymmpYgVlYh 2t8d6TJEbU2M13LkfOht+0NX6LMIvUCN37rRhyYFKdueLcZEJL9Myy091/Rb3dfz W4n4xax0k0FfGEFrzu8cmlY+WhUrMqMuEolznqnA7xzZFaAQiR1Z8ZI2RgGTQiLw zJSJc9PJgTRaADQ5FJYydD27EezZ1koicqstoE6jm5IpXv3dnN15cZdt832bDeqK xZ3GiD9eJqN87pQdaii3BRvoRaYn+/Wq11OnGdGQwBLZUhyt662UAIVwPKNecElM V7SEC3eC8FpT2NyNbnRRBN0GghL+B7A3U5jhS7DGm8itLlyezCHciRnL+H5oG9+r 1go7zV7eTpTxlc5HmjP+MBOiPVjXqA4pGAWrhNd80bG72zEj08CckYAjytrH2Udd Xk6kCcnGYW1M97nSjldsleYSbKXcEl4tQUqeFmICnlSOwyCK2oZeQO8acF3gcFBi wrjSLICMSLBUQgqa5I/Y8zpzWVt9ToeByIQsa1k3TVWHMH5mc5sNq6lqUbR666Kg GaYiiyn+HOczBw570n/3 =epcM -----END PGP SIGNATURE----- --a509DLANpDlBRteA30Qk9iBIOhUmfLCJr-- From owner-freebsd-stable@FreeBSD.ORG Sun Oct 19 18:41:46 2014 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 BD8ADCD5 for ; Sun, 19 Oct 2014 18:41:46 +0000 (UTC) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (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 7D4B2953 for ; Sun, 19 Oct 2014 18:41:46 +0000 (UTC) Received: from 2a02-8428-011b-e000-0290-f5ff-fe9d-b78c.rev.sfr.net ([2a02:8428:11b:e000:290:f5ff:fe9d:b78c] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XfvQG-000OYM-Ok for freebsd-stable@freebsd.org; Sun, 19 Oct 2014 20:41:44 +0200 Message-ID: <544405E8.9010503@dumbbell.fr> Date: Sun, 19 Oct 2014 20:41:44 +0200 From: =?windows-1252?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: 10.1 kernel device config for drm2 and kms drivers References: <20140911064731.GA15930@rwpc15.gfn.riverwillow.net.au> <54115D2A.5020802@FreeBSD.org> <20140911084624.GK2737@kib.kiev.ua> <20140911211428.GA6247@anubis.morrow.me.uk> <20140913204209.GA18072@anubis.morrow.me.uk> In-Reply-To: <20140913204209.GA18072@anubis.morrow.me.uk> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wFv5fSQGSinvJ0TtqgX5qXN4H0DwQkUPA" 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, 19 Oct 2014 18:41:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wFv5fSQGSinvJ0TtqgX5qXN4H0DwQkUPA Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 13.09.2014 22:42, Ben Morrow wrote: > Previously, with syscons, I could usually scroll back after boot had > finished and the login: prompt appeared and get all the way up to the > start of the kernel messages (the Copyright line).=20 >=20 > Now, with vt, and loading radeonkms from rc.conf rather than > loader.conf, if I switch to the console, I can: scroll up through 8 > screens of kernel and userland console messages The history scrolling was rewritten in r271871 (HEAD) and r271973 (10.1). I believe your problem is fixed by this change. Can you confirm if 10.1-RC* works for you in this regard? --=20 Jean-S=E9bastien P=E9dron --wFv5fSQGSinvJ0TtqgX5qXN4H0DwQkUPA 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 iQJ8BAEBCgBmBQJURAXoXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTMGmgP+wRzXzP5Jo16tk8+aUDC25Ie eJKdOlai/1yjRP9jYqUqsCF+iukiZWJScMfX+8alP4VIA6TnOdVP2CaIxZmBOjL3 clxhoVhCWxodYESjNyq0P+qJmc8sYOu/jQ/zooGMVJo25DjSKiZv072EbXH144Jc 0bbS/ALv67nnSpA0gw+ElC3ZbzvhVYHTlZWT8pLXIYxqr8bjpYhk8jVFMP5lgcS0 YNSvkgqHltrpN2N7NVurZKRf1JqhpLF0TkSca29czRJvkvsBX4dg6usZT2xe1u9n Bre0zq6gDIuZ5VB4Y/fHpjSExLO6Au5Phg/4nGaVOwlZdhxgp1WdU6802F3WTHx/ fScZUcCTU4JwpaelICOipyRE2FyNqvsZFtBZnH0emV4NjYhLA38aFZpU3RgBNwJG 87a0KLlQZpDOOlxe8v01nHDVJMWv62gR3lP29nHOFcpvRknNlJBuvJjVxzTbRCzm aC6cmRZv2OE+lU58epzyympCSZxFuQdhlwCDdlIcZW7BGZ/3FS1AuXV/JxTWHB/e iU76kYGUC352SfYWwrfigpgBt+JcHFsJC0ZskEjTNgh69PhFl4ez5bYdg8L+xlOM bW+FzxRUGiEpYGr3p0w9HKtlotx8s8hspM33qB8qD/jGB+FJ9V/V3q+7duAEwPUE quD8feKnG6ObHpMRdPo3 =Pu7e -----END PGP SIGNATURE----- --wFv5fSQGSinvJ0TtqgX5qXN4H0DwQkUPA-- From owner-freebsd-stable@FreeBSD.ORG Sun Oct 19 20:26:26 2014 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 923F9D53 for ; Sun, 19 Oct 2014 20:26:26 +0000 (UTC) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 192651F6 for ; Sun, 19 Oct 2014 20:26:25 +0000 (UTC) Received: by mail-lb0-f175.google.com with SMTP id u10so2846283lbd.20 for ; Sun, 19 Oct 2014 13:26:18 -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:content-type:content-transfer-encoding; bh=JXanSm3UkeM/coDfRpX6QY0zexBHtAnH0UJG2DFz998=; b=HRrMn3ndoNZQNBby0kDJIKH7sxhP47Bsaa2620GU21EYdMVcqV98Eyy7YlQZ9u20OK +MebxGWkUUUgZYH38hwWitK0jOOBwYiL2PutHAv889zA5fuCJnpJmTjAaD8TBCsgWHGv 2N1VNcGwOB8+tE/nCAj7MAbq8mgakuGH6Ou3UH0nK6LwXmYrBaXXZ32VAt3OL9GAYSmN 5JT53FQxsDd7lOX8iWDkbFTwVYVC5u3ATnDXVMN7j5Hcr0RJ8dxZjhten0TnGbUZVV1H 25R5wAFLmWvwMtv6r8oyP8nQVKdWdDiGXJyz5CgTwsYkVMIL6RQpTxN5oruD63nhSbqW eTVA== X-Gm-Message-State: ALoCoQmQDgh4Nx7bQLe0Z9PIFJo9Yfc3tpFFv0R+oSHGUpPykvCiQnHL+PDUPhUAPISv26oGlN5T X-Received: by 10.112.162.73 with SMTP id xy9mr4266630lbb.94.1413750378396; Sun, 19 Oct 2014 13:26:18 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by mx.google.com with ESMTPSA id ry6sm2522005lbb.26.2014.10.19.13.26.17 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Oct 2014 13:26:17 -0700 (PDT) Message-ID: <54441E69.9000604@freebsd.org> Date: Mon, 20 Oct 2014 00:26:17 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "stable@freebsd.org" Subject: /etc/rc: WARNING: $kerberos5_server_enable is not set properly - see rc.conf(5). Content-Type: text/plain; charset=koi8-r 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, 19 Oct 2014 20:26:26 -0000 I don't have kerberos compiled in (WITHOUT_KERBEROS=yes) and don't touch $kerberos5_server_enable but still having this diagnostic from /etc/rc. Why it is not set properly in /etc/defaults/rc.conf by default? -- http://ache.vniz.net/ From owner-freebsd-stable@FreeBSD.ORG Sun Oct 19 20:55:16 2014 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 19A2A3A6; Sun, 19 Oct 2014 20:55:16 +0000 (UTC) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.allbsd.org", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5B454688; Sun, 19 Oct 2014 20:55:15 +0000 (UTC) Received: from alph.d.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=56) by mail.allbsd.org (8.14.9/8.14.8) with ESMTP id s9JKsoHB040231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Oct 2014 05:55:00 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.8/8.14.8) with ESMTP id s9JKsmJU052852; Mon, 20 Oct 2014 05:54:50 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Mon, 20 Oct 2014 05:54:30 +0900 (JST) Message-Id: <20141020.055430.2149763277890617999.hrs@allbsd.org> To: ache@freebsd.org Subject: Re: /etc/rc: WARNING: $kerberos5_server_enable is not set properly - see rc.conf(5). From: Hiroki Sato In-Reply-To: <54441E69.9000604@freebsd.org> References: <54441E69.9000604@freebsd.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.6 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Mon_Oct_20_05_54_30_2014_724)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Mon, 20 Oct 2014 05:55:08 +0900 (JST) X-Spam-Status: No, score=-97.9 required=13.0 tests=CONTENT_TYPE_PRESENT, RDNS_NONE,SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org 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, 19 Oct 2014 20:55:16 -0000 ----Security_Multipart(Mon_Oct_20_05_54_30_2014_724)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andrey Chernov wrote in <54441E69.9000604@freebsd.org>: ac> I don't have kerberos compiled in (WITHOUT_KERBEROS=yes) and don't touch ac> $kerberos5_server_enable but still having this diagnostic from /etc/rc. ac> Why it is not set properly in /etc/defaults/rc.conf by default? Do you have rc.d/kerberos script? I noticed that I forgot to add it to OLD_FILES after removing it. I committed a fix in r273285 and r273286 just now. -- Hiroki ----Security_Multipart(Mon_Oct_20_05_54_30_2014_724)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlREJQYACgkQTyzT2CeTzy10/ACfZZO7M9v7T/xJNIQouEsPRw5y vtAAnif1ke50uQj0OzZtm3nTtKuBmkOQ =/6O+ -----END PGP SIGNATURE----- ----Security_Multipart(Mon_Oct_20_05_54_30_2014_724)---- From owner-freebsd-stable@FreeBSD.ORG Sun Oct 19 21:01:57 2014 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 84E6A99E for ; Sun, 19 Oct 2014 21:01:57 +0000 (UTC) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0659B856 for ; Sun, 19 Oct 2014 21:01:56 +0000 (UTC) Received: by mail-la0-f46.google.com with SMTP id gi9so2983940lab.33 for ; Sun, 19 Oct 2014 14:01:49 -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 :cc:subject:references:in-reply-to:content-type; bh=4HhCD3r4IRyiuGj6GzdO/d19iMecxdvGoU2AXeF/cBE=; b=LIPcbbLpD9tiZuCHo3JyHANdvt7+GmQzXo0oUMwCpHvP1gvBy+JIOUm1qJ5ht0Ze/j 34sZvLjsrduG0NB8mlRp0ichFTE5djHWlOu+XEjexcT2drCxz0BlTdXP+blymXi9nioe MSsgRYaA2+y9BXpmOp1AdwKssvBbHNJcvb4GEur8OIn+IuCLMWY1+qiH+QoBlLyFhFqb BdcJ/oEEzlQVxR81NSLVEWd/HNV8RETXnc8cEzA3pk6hwIpX1UbAfLi5k5yihkjO/5w3 guCwWpDh9PDJrx7/gLY54IwerqYsP6vydjiJt091eDvUNg68Fbj3Bu+K6aA0sYHayMDm ZigA== X-Gm-Message-State: ALoCoQkGZs3CElk6/ErwPY2n3kZ+vMeVlZW7W21rQRIJ6nbqKHYLENeUfkC9+M673tOhAZZiszKL X-Received: by 10.112.130.41 with SMTP id ob9mr22642761lbb.74.1413752508975; Sun, 19 Oct 2014 14:01:48 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by mx.google.com with ESMTPSA id n10sm1789216laf.38.2014.10.19.14.01.47 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Oct 2014 14:01:48 -0700 (PDT) Message-ID: <544426B3.7060104@freebsd.org> Date: Mon, 20 Oct 2014 01:01:39 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Hiroki Sato Subject: Re: /etc/rc: WARNING: $kerberos5_server_enable is not set properly - see rc.conf(5). References: <54441E69.9000604@freebsd.org> <20141020.055430.2149763277890617999.hrs@allbsd.org> In-Reply-To: <20141020.055430.2149763277890617999.hrs@allbsd.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JloNepIES3m0or4xJNukU02THXcrNOjwv" 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, 19 Oct 2014 21:01:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JloNepIES3m0or4xJNukU02THXcrNOjwv Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable On 20.10.2014 0:54, Hiroki Sato wrote: > Andrey Chernov wrote > in <54441E69.9000604@freebsd.org>: >=20 > ac> I don't have kerberos compiled in (WITHOUT_KERBEROS=3Dyes) and don'= t touch > ac> $kerberos5_server_enable but still having this diagnostic from /etc= /rc. > ac> Why it is not set properly in /etc/defaults/rc.conf by default? >=20 > Do you have rc.d/kerberos script?=20 Yes. > I noticed that I forgot to add it > to OLD_FILES after removing it. I committed a fix in r273285 and > r273286 just now. Thanx, fixed now. --=20 http://ache.vniz.net/ --JloNepIES3m0or4xJNukU02THXcrNOjwv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJURCa7AAoJEKUckv0MjfbKueEIALeS2XM78R87eVJzvrY+zajJ PtfzS+wqInmvRrySisOt/HupTsDLhLrh2UwYp05LD9F57fXLWCHNdUzHs3B4ulFc lZxt4zKP3IC3gDaRoh2PwcbEZnxhe6+X/c+OEEeFSUfXmqNn70oKOmFpn1gTA2X9 8pMjuPIf2cds9YdlVP5mAni8OVlEzBT1GJjOfJeLPwY85LHMV/9+0h/9zp2isPEv UKpnn+haqNxipQlmmZytbCnDYloaLQIfWLvadSYlk7ZEobu/keHlXISa4hAwZkub 4CgJg5qiPejx9EF8vUivkrXHCJKQ5PXBdHl6slQrCfWOtWaBHAXEnrQkMNmOdNU= =N+Hg -----END PGP SIGNATURE----- --JloNepIES3m0or4xJNukU02THXcrNOjwv-- From owner-freebsd-stable@FreeBSD.ORG Sun Oct 19 23:36:27 2014 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 6559C33B for ; Sun, 19 Oct 2014 23:36:27 +0000 (UTC) Received: from ozzie.tundraware.com (ozzie.tundraware.com [75.145.138.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ozzie.tundraware.com", Issuer "ozzie.tundraware.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 30B428AA for ; Sun, 19 Oct 2014 23:36:26 +0000 (UTC) Received: from [192.168.0.2] (viper.tundraware.com [192.168.0.2]) (authenticated bits=0) by ozzie.tundraware.com (8.14.9/8.14.9) with ESMTP id s9JNY4No016792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sun, 19 Oct 2014 18:34:04 -0500 (CDT) (envelope-from tundra@tundraware.com) Message-ID: <54444A6C.4010407@tundraware.com> Date: Sun, 19 Oct 2014 18:34:04 -0500 From: Tim Daneliuk User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: FreeBSD Stable Subject: Problems After Today's STABLE Build Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (ozzie.tundraware.com [75.145.138.73]); Sun, 19 Oct 2014 18:34:04 -0500 (CDT) X-TundraWare-MailScanner-Information: Please contact the ISP for more information X-TundraWare-MailScanner-ID: s9JNY4No016792 X-TundraWare-MailScanner: Found to be clean X-TundraWare-MailScanner-From: tundra@tundraware.com X-Spam-Status: No 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, 19 Oct 2014 23:36:27 -0000 Just built and installed this: Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/stable/10 Relative URL: ^/stable/10 Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 273271 Node Kind: directory Schedule: normal Last Changed Author: pfg Last Changed Rev: 273265 Last Changed Date: 2014-10-18 14:22:59 -0500 (Sat, 18 Oct 2014) Problem #1 ---------- saslauthd is now complaining because it wants libopie.so.7 but the system bumped to so.8, Temporarily fixed with libmap.conf. Problem #2 ---------- For a week or so now, I am seeing errors like this when attempting to upgrade a port: ! security/sudo (sudo-1.8.10.p3_1) (could not find a temporary directory) Ideas> -- ---------------------------------------------------------------------------- Tim Daneliuk tundra@tundraware.com PGP Key: http://www.tundraware.com/PGP/ From owner-freebsd-stable@FreeBSD.ORG Mon Oct 20 08:35:35 2014 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 68DE76A8 for ; Mon, 20 Oct 2014 08:35:35 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E8557ECA for ; Mon, 20 Oct 2014 08:35:34 +0000 (UTC) Received: from mh0.gentlemail.de (mh0.gentlemail.de [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s9K8ZU4u037077 for ; Mon, 20 Oct 2014 10:35:30 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id B67483134; Mon, 20 Oct 2014 10:35:30 +0200 (CEST) Message-ID: <5444C94C.4050705@omnilan.de> Date: Mon, 20 Oct 2014 10:35:24 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: FreeBSD Stable Subject: ctld(8), multiple 'portal-group' on same socket (individual 'discovery-auth-group' restrictions) X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3E1F7EC4744638EF54E10C63" X-Greylist: ACL 119 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Mon, 20 Oct 2014 10:35:30 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) 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, 20 Oct 2014 08:35:35 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3E1F7EC4744638EF54E10C63 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hello, I'm trying to move from istgt(1) to ctld(8), but it seems my setup isn't possible with ctld. Besides missing support for virtual-DVDs ('UnitType DVD' in istgt) and real ODD-devices ('UnitType pass' in istgt), I guess it's impossible to define multiple "portal-group"s, listening on the same socket, but with different "discovery-auth-group". The idea is, to present initiators only targets at discovery, which they are allowed to connect to. Am I missing something which could provide such selective discovery with ctld(8)? Thanks, -Harry --------------enig3E1F7EC4744638EF54E10C63 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlREyVIACgkQLDqVQ9VXb8h2+QCfUl/JA3kfxjFdoffvmJdY/FH1 lH8AnRe+YWpgLVh6DWDbmbGxRfdGyugR =Qpv4 -----END PGP SIGNATURE----- --------------enig3E1F7EC4744638EF54E10C63-- From owner-freebsd-stable@FreeBSD.ORG Mon Oct 20 08:51:49 2014 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 DB3319E0 for ; Mon, 20 Oct 2014 08:51:49 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9D807FD for ; Mon, 20 Oct 2014 08:51:49 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Xg8gh-0005ra-8S for freebsd-stable@freebsd.org; Mon, 20 Oct 2014 10:51:41 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: freebsd-stable@freebsd.org Subject: Re: Problems After Today's STABLE Build References: <54444A6C.4010407@tundraware.com> Date: Mon, 20 Oct 2014 10:51:34 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <54444A6C.4010407@tundraware.com> User-Agent: Opera Mail/12.17 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: - X-Spam-Score: -1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, BAYES_40 autolearn=disabled version=3.3.2 X-Scan-Signature: a2d32f98be707cbcda8602d5fffa976a 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, 20 Oct 2014 08:51:49 -0000 On Mon, 20 Oct 2014 01:34:04 +0200, Tim Daneliuk wrote: > Just built and installed this: > > Path: . > Working Copy Root Path: /usr/src > URL: svn://svn.freebsd.org/base/stable/10 > Relative URL: ^/stable/10 > Repository Root: svn://svn.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 273271 > Node Kind: directory > Schedule: normal > Last Changed Author: pfg > Last Changed Rev: 273265 > Last Changed Date: 2014-10-18 14:22:59 -0500 (Sat, 18 Oct 2014) > > Problem #1 > ---------- > > saslauthd is now complaining because it wants libopie.so.7 but the > system bumped to so.8, Temporarily fixed with libmap.conf. Fixed in: https://svnweb.freebsd.org/changeset/base/273277 So upgrade again. > Problem #2 > ---------- > > For a week or so now, I am seeing errors like this when attempting to > upgrade a port: > > ! security/sudo (sudo-1.8.10.p3_1) (could not find a temporary > directory) > I don't know about this. Regards, Ronald. From owner-freebsd-stable@FreeBSD.ORG Mon Oct 20 09:04:36 2014 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 E1641B4 for ; Mon, 20 Oct 2014 09:04:36 +0000 (UTC) Received: from mta1.riverwillow.net.au (mta1.riverwillow.net.au [IPv6:2001:8000:1000:1801::36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mta1.riverwillow.net.au", Issuer "Riverwillow Root Certificate 2010-04-12" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3705D227 for ; Mon, 20 Oct 2014 09:04:35 +0000 (UTC) Received: from mail1.riverwillow.net.au (mail1.riverwillow.net.au [IPv6:2001:8000:1000:1801::46]) by mta1.riverwillow.net.au (8.14.9/8.14.9) with ESMTP id s9K94S5v034427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 20 Oct 2014 20:04:28 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=mta1002; t=1413795868; bh=jm+pmU++KHUKT99rcY9CuB8Go4KX/qk+8uaVBt+MFIY=; h=Date:From:To:Subject; b=VgKpOFqomWqjRUvo52tUVjIeiSUqomL1cCSBJNhCJNsrje8zV0MzmIydFn06Yw7Um fCU8NdubEehdvKOo4nfo2hfQ3y0wmCXCzG563o7qhXTkUEoz4B8FmQMam/Vv3Os1Ez THKwfOWwEgXXBOhSXANPM+XHfqSRdEeE+pJtpNF8= Received: from rwpc15.gfn.riverwillow.net.au (rwpc15.gfn.riverwillow.net.au [IPv6:2001:8000:1000:18e1:20c:76ff:fe0a:2117]) (authenticated bits=56) by mail1.riverwillow.net.au (8.14.9/8.14.9) with ESMTP id s9K94OtP034426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 20 Oct 2014 20:04:26 +1100 (AEDT) Date: Mon, 20 Oct 2014 20:04:24 +1100 From: John Marshall To: freebsd-stable@freebsd.org Subject: 10.1-RC1 tar(1) spurious directory traversal permission error Message-ID: <20141020090424.GB1120@rwpc15.gfn.riverwillow.net.au> Mail-Followup-To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline OpenPGP: id=A29A84A2; url=http://pki.riverwillow.com.au/pgp/johnmarshall.asc 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, 20 Oct 2014 09:04:37 -0000 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I don't know if tar(1) is the culprit or an innocent bystander but this is what I am seeing on 10.1-RC1 (r272468 amd64). The archive appears to be written properly prior to generation of the error message. Although the user is permitted to traverse the parent directory, tar(1) emits the complaint if the parent directory is not readable. Filesystem is UFS. $ tar -czf dtt.tgz -C /data/tftp/thlan . tar: .: Unable to continue traversing directory tree: Permission denied tar: Error exit delayed from previous errors. $=20 $ ls -ld /data /data/tftp /data/tftp/thlan drwxr-xr-x 33 root wheel 1024 2 Sep 20:13 /data drwxr-x--x 4 root wheel 512 23 Apr 09:00 /data/tftp drwxr-x--x 3 john wheel 512 23 Apr 10:28 /data/tftp/thlan # chmod o+r /data/tftp $ tar -czf dtt.tgz -C /data/tftp/thlan . $=20 I haven't played with 10.0 but this behaviour is different to other earlier releases (e.g. 9.3-RELEASE doesn't do this). I have filed a PR [Bug 194477]. --=20 John Marshall --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRE0BgACgkQw/tAaKKahKIXaACgwNjIHNscrTQ1ykuwFOtVDl8t zN0An3F6fMO2C1H5esOGkf2KzsGTDbCv =iWtY -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J-- From owner-freebsd-stable@FreeBSD.ORG Mon Oct 20 09:22:14 2014 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 C919550B for ; Mon, 20 Oct 2014 09:22:14 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8A368622 for ; Mon, 20 Oct 2014 09:22:14 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Xg9AE-0008Kn-K1 for freebsd-stable@freebsd.org; Mon, 20 Oct 2014 11:22:11 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: freebsd-stable@freebsd.org Subject: Re: 10.1-RC1 tar(1) spurious directory traversal permission error References: <20141020090424.GB1120@rwpc15.gfn.riverwillow.net.au> Date: Mon, 20 Oct 2014 11:22:05 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <20141020090424.GB1120@rwpc15.gfn.riverwillow.net.au> User-Agent: Opera Mail/12.17 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: - X-Spam-Score: -1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, BAYES_20 autolearn=disabled version=3.3.1 X-Scan-Signature: 5a1627636b35b65657045ef62631cd80 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, 20 Oct 2014 09:22:14 -0000 On Mon, 20 Oct 2014 11:04:24 +0200, John Marshall wrote: > I don't know if tar(1) is the culprit or an innocent bystander but this > is what I am seeing on 10.1-RC1 (r272468 amd64). The archive appears to > be written properly prior to generation of the error message. Although > the user is permitted to traverse the parent directory, tar(1) emits the > complaint if the parent directory is not readable. Filesystem is UFS. > > $ tar -czf dtt.tgz -C /data/tftp/thlan . > tar: .: Unable to continue traversing directory tree: Permission denied > tar: Error exit delayed from previous errors. > $ > > $ ls -ld /data /data/tftp /data/tftp/thlan > drwxr-xr-x 33 root wheel 1024 2 Sep 20:13 /data > drwxr-x--x 4 root wheel 512 23 Apr 09:00 /data/tftp > drwxr-x--x 3 john wheel 512 23 Apr 10:28 /data/tftp/thlan > > # chmod o+r /data/tftp > > $ tar -czf dtt.tgz -C /data/tftp/thlan . > $ > > I haven't played with 10.0 but this behaviour is different to other > earlier releases (e.g. 9.3-RELEASE doesn't do this). > > I have filed a PR [Bug 194477]. > Maybe the output of 'truss -o /tmp/truss.txt tar -czf dtt.tgz -C /data/tftp/thlan .' gives interesting information about what is exactly giving the permission denied. Ronald. From owner-freebsd-stable@FreeBSD.ORG Mon Oct 20 10:21:01 2014 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 D5EDD7FC; Mon, 20 Oct 2014 10:21:01 +0000 (UTC) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [31.24.6.74]) (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 2240AD8B; Mon, 20 Oct 2014 10:21:01 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Xg9lt-0008C4-Vn; Mon, 20 Oct 2014 10:01:02 +0000 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1Xg9lt-0002yh-TT; Mon, 20 Oct 2014 11:01:01 +0100 To: bapt@FreeBSD.org, ports@FreeBSD.org, stable@FreeBSD.org Subject: Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG) In-Reply-To: <20141003083051.GA52332@ivaldir.etoilebsd.net> Message-Id: From: Pete French Date: Mon, 20 Oct 2014 11:01:01 +0100 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, 20 Oct 2014 10:21:01 -0000 ..... > Note official packages reflecting this sitation will start building on > Wednesday 8th of October and hit your mirrors as soon as possible for both > quarterly branch and regular head. Has this happened ? I was expecting to see an ATI UMS port appeat, and for the non UMS port to move to version 7, but have been checking and I still get this: $ pkg search xf86-video-ati xf86-video-ati-6.14.6_4 xf86-video-ati-ums-6.14.6_4 The version in the new xorg respsiotory is xf86-video-ati-7.2.0_4 - did I misunderstand what was changing, or is this delayed for some reason ? thanks, -pete. From owner-freebsd-stable@FreeBSD.ORG Mon Oct 20 10:21:17 2014 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 C8F7896E for ; Mon, 20 Oct 2014 10:21:17 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 20CFBD91 for ; Mon, 20 Oct 2014 10:21:13 +0000 (UTC) Received: from [128.176.32.19] ([128.176.32.19]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LaJWs-1YPeG70i46-00m6t4 for ; Mon, 20 Oct 2014 12:21:05 +0200 Message-ID: <5444E1F5.3040100@gmx.de> Date: Mon, 20 Oct 2014 12:20:37 +0200 From: Norbert User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: FreeBSD-stable@FreeBSD.org Subject: FreeBSD 10.1 RC 2 on Supermicro H8QGi-F X-Provags-ID: V03:K0:S0vRlI4ADdbPihF8CctygfnzORr94AqHYslM5lYXeamcFlmKfBD +kF2/0OoL6m2Ng3ityQNUcT73vSwZQhMHym76qQTy/T8NwOn+XIycCoX70L5BskQf6Iv5sU u77ttHbN9jlTVUfuMiMO1EHSML1iNArPwVGWusDFgN3Hx61t7vp40Lwu22FHomKEXu3QZMw RsolpzRGnYccjMir4V35Q== X-UI-Out-Filterresults: notjunk:1; Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Mon, 20 Oct 2014 10:21:17 -0000 Hello, maybe it is worth to say something about running FreeBSD 10.1 RC2 on Supermicro H8QGi-F with 64 cores (4x16) and 512 GB RAM: first of all: it runs without troubles so far... I am working in the area of bioinformatics at University in Muenster - I run some test with blast, installed VirtualBox which is running Ubuntu 14.04.1... A look into the dmesg: Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.1-RC1 #0 r272463: Fri Oct 3 01:47:10 UTC 2014 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 CPU: AMD Opteron(tm) Processor 6378 (2400.05-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x600f20 Family = 0x15 Model = 0x2 Stepping = 0 Features=0x178bfbff Features2=0x3e98320b AMD Features=0x2e500800 AMD Features2=0x1ebbfff Structured Extended Features=0x8 TSC: P-state invariant, performance statistics real memory = 549755813888 (524288 MB) avail memory = 534557609984 (509793 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: <020113 APIC1548> FreeBSD/SMP: Multiprocessor System Detected: 64 CPUs FreeBSD/SMP: 4 package(s) x 16 core(s) cpu0 (BSP): APIC ID: 32 cpu1 (AP): APIC ID: 33 cpu2 (AP): APIC ID: 34 cpu3 (AP): APIC ID: 35 cpu4 (AP): APIC ID: 36 cpu5 (AP): APIC ID: 37 cpu6 (AP): APIC ID: 38 cpu7 (AP): APIC ID: 39 cpu8 (AP): APIC ID: 40 cpu9 (AP): APIC ID: 41 cpu10 (AP): APIC ID: 42 cpu11 (AP): APIC ID: 43 cpu12 (AP): APIC ID: 44 cpu13 (AP): APIC ID: 45 cpu14 (AP): APIC ID: 46 cpu15 (AP): APIC ID: 47 cpu16 (AP): APIC ID: 64 cpu17 (AP): APIC ID: 65 cpu18 (AP): APIC ID: 66 cpu19 (AP): APIC ID: 67 cpu20 (AP): APIC ID: 68 cpu21 (AP): APIC ID: 69 cpu22 (AP): APIC ID: 70 cpu23 (AP): APIC ID: 71 cpu24 (AP): APIC ID: 72 cpu25 (AP): APIC ID: 73 cpu26 (AP): APIC ID: 74 cpu27 (AP): APIC ID: 75 cpu28 (AP): APIC ID: 76 cpu29 (AP): APIC ID: 77 cpu30 (AP): APIC ID: 78 cpu31 (AP): APIC ID: 79 cpu32 (AP): APIC ID: 96 cpu33 (AP): APIC ID: 97 cpu34 (AP): APIC ID: 98 cpu35 (AP): APIC ID: 99 cpu36 (AP): APIC ID: 100 cpu37 (AP): APIC ID: 101 cpu38 (AP): APIC ID: 102 cpu39 (AP): APIC ID: 103 cpu40 (AP): APIC ID: 104 cpu41 (AP): APIC ID: 105 cpu42 (AP): APIC ID: 106 cpu43 (AP): APIC ID: 107 cpu44 (AP): APIC ID: 108 cpu45 (AP): APIC ID: 109 cpu46 (AP): APIC ID: 110 cpu47 (AP): APIC ID: 111 cpu48 (AP): APIC ID: 128 cpu49 (AP): APIC ID: 129 cpu50 (AP): APIC ID: 130 cpu51 (AP): APIC ID: 131 cpu52 (AP): APIC ID: 132 cpu53 (AP): APIC ID: 133 cpu54 (AP): APIC ID: 134 cpu55 (AP): APIC ID: 135 cpu56 (AP): APIC ID: 136 cpu57 (AP): APIC ID: 137 cpu58 (AP): APIC ID: 138 cpu59 (AP): APIC ID: 139 cpu60 (AP): APIC ID: 140 cpu61 (AP): APIC ID: 141 cpu62 (AP): APIC ID: 142 cpu63 (AP): APIC ID: 143 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-55 on motherboard ioapic2 irqs 56-87 on motherboard random: initialized kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) acpi0: reservation of fec00000, 1000 (3) failed acpi0: reservation of fee00000, 1000 (3) failed acpi0: reservation of ffb80000, 80000 (3) failed acpi0: reservation of fec10000, 20 (3) failed acpi0: reservation of 0, a0000 (3) failed cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 cpu8: on acpi0 cpu9: on acpi0 cpu10: on acpi0 cpu11: on acpi0 cpu12: on acpi0 cpu13: on acpi0 cpu14: on acpi0 cpu15: on acpi0 cpu16: on acpi0 cpu17: on acpi0 cpu18: on acpi0 cpu19: on acpi0 cpu20: on acpi0 cpu21: on acpi0 cpu22: on acpi0 cpu23: on acpi0 cpu24: on acpi0 cpu25: on acpi0 cpu26: on acpi0 cpu27: on acpi0 cpu28: on acpi0 cpu29: on acpi0 cpu30: on acpi0 cpu31: on acpi0 cpu32: on acpi0 cpu33: on acpi0 cpu34: on acpi0 cpu35: on acpi0 cpu36: on acpi0 cpu37: on acpi0 cpu38: on acpi0 cpu39: on acpi0 cpu40: on acpi0 cpu41: on acpi0 cpu42: on acpi0 cpu43: on acpi0 cpu44: on acpi0 cpu45: on acpi0 cpu46: on acpi0 cpu47: on acpi0 cpu48: on acpi0 cpu49: on acpi0 cpu50: on acpi0 cpu51: on acpi0 cpu52: on acpi0 cpu53: on acpi0 cpu54: on acpi0 cpu55: on acpi0 cpu56: on acpi0 cpu57: on acpi0 cpu58: on acpi0 cpu59: on acpi0 cpu60: on acpi0 cpu61: on acpi0 cpu62: on acpi0 cpu63: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 54 at device 11.0 on pci0 pci3: on pcib1 siis0: port 0xe800-0xe87f mem 0xdff7bc00-0xdff7bc7f,0xdff7c000-0xdff7ffff irq 32 at device 0.0 on pci3 siisch0: at channel 0 on siis0 siisch1: at channel 1 on siis0 pcib2: irq 54 at device 13.0 on pci0 pci2: on pcib2 igb0: port 0xd400-0xd41f mem 0xdfe60000-0xdfe7ffff,0xdfe40000-0xdfe5ffff,0xdfe1c000-0xdfe1ffff irq 40 at device 0.0 on pci2 igb0: Using MSIX interrupts with 9 vectors igb0: Ethernet address: 00:25:90:5a:0c:18 igb0: Bound queue 0 to cpu 0 igb0: Bound queue 1 to cpu 1 igb0: Bound queue 2 to cpu 2 igb0: Bound queue 3 to cpu 3 igb0: Bound queue 4 to cpu 4 igb0: Bound queue 5 to cpu 5 igb0: Bound queue 6 to cpu 6 igb0: Bound queue 7 to cpu 7 igb1: port 0xd800-0xd81f mem 0xdfee0000-0xdfefffff,0xdfec0000-0xdfedffff,0xdfe9c000-0xdfe9ffff irq 41 at device 0.1 on pci2 igb1: Using MSIX interrupts with 9 vectors igb1: Ethernet address: 00:25:90:5a:0c:19 igb1: Bound queue 0 to cpu 8 igb1: Bound queue 1 to cpu 9 igb1: Bound queue 2 to cpu 10 igb1: Bound queue 3 to cpu 11 igb1: Bound queue 4 to cpu 12 igb1: Bound queue 5 to cpu 13 igb1: Bound queue 6 to cpu 14 igb1: Bound queue 7 to cpu 15 ahci0: port 0xc000-0xc007,0xb000-0xb003,0xa000-0xa007,0x9000-0x9003,0x8000-0x800f mem 0xdfdfa400-0xdfdfa7ff irq 22 at device 17.0 on pci0 ahci0: AHCI v1.10 with 4 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ohci0: mem 0xdfdf6000-0xdfdf6fff irq 16 at device 18.0 on pci0 usbus0 on ohci0 ohci1: mem 0xdfdf7000-0xdfdf7fff irq 16 at device 18.1 on pci0 usbus1 on ohci1 ehci0: mem 0xdfdfa800-0xdfdfa8ff irq 17 at device 18.2 on pci0 usbus2: EHCI version 1.0 usbus2 on ehci0 ohci2: mem 0xdfdf8000-0xdfdf8fff irq 18 at device 19.0 on pci0 usbus3 on ohci2 ohci3: mem 0xdfdf9000-0xdfdf9fff irq 18 at device 19.1 on pci0 usbus4 on ohci3 ehci1: mem 0xdfdfac00-0xdfdfacff irq 19 at device 19.2 on pci0 usbus5: EHCI version 1.0 usbus5 on ehci1 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0 ata1: at channel 1 on atapci0 isab0: at device 20.3 on pci0 isa0: on isab0 pcib3: at device 20.4 on pci0 pci1: on pcib3 vgapci0: mem 0xdc000000-0xdcffffff,0xdeffc000-0xdeffffff,0xdf000000-0xdf7fffff irq 20 at device 4.0 on pci1 vgapci0: Boot video device ohci4: mem 0xdfdfb000-0xdfdfbfff irq 18 at device 20.5 on pci0 usbus6 on ohci4 pcib4: on acpi0 pci64: on pcib4 acpi_button0: on acpi0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart2: <16550 or compatible> port 0x3e8-0x3ef irq 5 on acpi0 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc8fff,0xc9000-0xcd7ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] ppc0: cannot reserve I/O port range acpi_throttle0: on cpu0 hwpstate0: on cpu0 (noperiph:siisch1:0:-1:ffffffff): rescan already queued random: unblocking device. usbus0: 12Mbps Full Speed USB v1.0 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 480Mbps High Speed USB v2.0 usbus6: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen2.1: at usbus2 uhub1: on usbus2 ugen1.1: at usbus1 uhub2: on usbus1 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen6.1: at usbus6 uhub5: on usbus6 ugen5.1: at usbus5 uhub6: on usbus5 uhub5: 2 ports with 2 removable, self powered uhub0: 3 ports with 3 removable, self powered uhub2: 3 ports with 3 removable, self powered uhub3: 3 ports with 3 removable, self powered uhub4: 3 ports with 3 removable, self powered ugen6.2: at usbus6 ukbd0: on usbus6 kbd2 at ukbd0 ada0 at ahcich0 bus 0 scbus2 target 0 lun 0 ada0: ATA-8 SATA 3.x device ada0: Serial Number WD-WCAW37677317 ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad8 ada1 at ahcich1 bus 0 scbus3 target 0 lun 0 ada1: ATA-8 SATA 3.x device ada1: Serial Number WD-WCAW37674036 ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad10 ada2 at ahcich2 bus 0 scbus4 target 0 lun 0 ada2: ATA-8 SATA 3.x device ada2: Serial Number WD-WCAW37678151 ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: Command Queueing enabled ada2: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada2: Previously was known as ad12 ada3 at ahcich3 bus 0 scbus5 target 0 lun 0 ada3: ATA-8 SATA 3.x device ada3: Serial Number WD-WCAW37678400 ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada3: Command Queueing enabled ada3: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada3: Previously was known as ad14 cd0 at siisch1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: Serial Number S1236YBF200V1L cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed SMP: AP CPU #1 Launched! SMP: AP CPU #12 Launched! SMP: AP CPU #13 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #15 Launched! SMP: AP CPU #14 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #22 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #10 Launched! SMP: AP CPU #11 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #9 Launched! SMP: AP CPU #8 Launched! SMP: AP CPU #20 Launched! SMP: AP CPU #28 Launched! SMP: AP CPU #63 Launched! SMP: AP CPU #46 Launched! SMP: AP CPU #37 Launched! SMP: AP CPU #24 Launched! SMP: AP CPU #47 Launched! SMP: AP CPU #30 Launched! SMP: AP CPU #41 Launched! SMP: AP CPU #53 Launched! SMP: AP CPU #25 Launched! SMP: AP CPU #54 Launched! SMP: AP CPU #55 Launched! SMP: AP CPU #21 Launched! SMP: AP CPU #23 Launched! SMP: AP CPU #56 Launched! SMP: AP CPU #31 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #58 Launched! SMP: AP CPU #51 Launched! SMP: AP CPU #42 Launched! SMP: AP CPU #29 Launched! SMP: AP CPU #40 Launched! SMP: AP CPU #62 Launched! SMP: AP CPU #61 Launched! SMP: AP CPU #18 Launched! SMP: AP CPU #57 Launched! SMP: AP CPU #19 Launched! SMP: AP CPU #44 Launched! SMP: AP CPU #50 Launched! SMP: AP CPU #48 Launched! SMP: AP CPU #32 Launched! SMP: AP CPU #36 Launched! SMP: AP CPU #17 Launched! SMP: AP CPU #35 Launched! SMP: AP CPU #52 Launched! SMP: AP CPU #60 Launched! SMP: AP CPU #38 Launched! SMP: AP CPU #26 Launched! SMP: AP CPU #16 Launched! SMP: AP CPU #49 Launched! SMP: AP CPU #34 Launched! SMP: AP CPU #45 Launched! SMP: AP CPU #59 Launched! SMP: AP CPU #27 Launched! SMP: AP CPU #39 Launched! SMP: AP CPU #33 Launched! SMP: AP CPU #43 Launched! Timecounter "TSC-low" frequency 1200026749 Hz quality 800 Root mount waiting for: usbus5 usbus2 uhub1: 6 ports with 6 removable, self powered uhub6: 6 ports with 6 removable, self powered Trying to mount root from zfs:zroot []... ugen0.2: at usbus0 ukbd1: on usbus0 kbd3 at ukbd1 ums0: on usbus6 Cheers, Norbert From owner-freebsd-stable@FreeBSD.ORG Mon Oct 20 10:23:24 2014 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 87D25AB2 for ; Mon, 20 Oct 2014 10:23:24 +0000 (UTC) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4002BDCC for ; Mon, 20 Oct 2014 10:23:23 +0000 (UTC) Received: by mail-qc0-f170.google.com with SMTP id m20so3387776qcx.15 for ; Mon, 20 Oct 2014 03:22:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=gcOEvTIYGueL3wO9W0lTOELNCIvweXg6ZC7RFhEpE/A=; b=wMu7wntTXPcI6UFyTEvMuor1D4k84Nh1LJooaLELxx/lHH0tLhEB1U2h8zudEnLYJi mD0t9DDCckjQzFl3R9zHONC67W14dbSo3CeGkaeS/jqusRlh5cf8HF7l9n9hqAGi7Hux 1XK4B/f1kqrBMcdjetvKZp7Et8Qd1EmCLT2VsRVTy5ONR5v1DRQ+hr9ULXIBNR7RDCo6 0pk3JYqFJGa87NXHvpwkjhTKY6BvmijCqac6lgfl3JAKXwOswFfv9pnX+lp+joKYk60E BCmn5uNbYPnHIFb4xzdFv2yzlPpITgp464HaLvfoYh7seqbZo02mQcpIybp358owuwAh Id8A== MIME-Version: 1.0 X-Received: by 10.224.21.133 with SMTP id j5mr34835696qab.51.1413800552406; Mon, 20 Oct 2014 03:22:32 -0700 (PDT) Received: by 10.141.18.135 with HTTP; Mon, 20 Oct 2014 03:22:32 -0700 (PDT) In-Reply-To: <201409091104.s89B4uhi067535@freefall.freebsd.org> References: <201409091104.s89B4uhi067535@freefall.freebsd.org> Date: Mon, 20 Oct 2014 13:22:32 +0300 Message-ID: Subject: Fwd: FreeBSD Security Advisory FreeBSD-SA-14:18.openssl From: tethys ocean To: freebsd-stable@freebsd.org 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: Mon, 20 Oct 2014 10:23:24 -0000 I am using FreeBSD 10.0-STABLE on my servers. But according to this mail I tried [FreeBSD 10.0] # fetch http://security.FreeBSD.org/patches/SA-14:18/openssl-10.0.patch # fetch http://security.FreeBSD.org/patches/SA-14:18/openssl-10.0.patch.asc # gpg --verify openssl-10.0.patch.asc But my server say this below: fetch http://security.FreeBSD.org/patches/SA-14:18/openssl-10.0.patch Certificate verification failed for /C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware 675119676:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s3_clnt.c:1180: fetch: http://security.FreeBSD.org/patches/SA-14:18/openssl-10.0.patch: Authentication error What should I do ? thanx ---------- Forwarded message ---------- From: FreeBSD Security Advisories Date: Tue, Sep 9, 2014 at 2:04 PM Subject: FreeBSD Security Advisory FreeBSD-SA-14:18.openssl To: FreeBSD Security Advisories -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-14:18.openssl Security Advisory The FreeBSD Project Topic: OpenSSL multiple vulnerabilities Category: contrib Module: openssl Announced: 2014-09-09 Affects: All supported versions of FreeBSD. Corrected: 2014-08-07 21:04:42 UTC (stable/10, 10.0-STABLE) 2014-09-09 10:09:46 UTC (releng/10.0, 10.0-RELEASE-p8) 2014-08-07 21:06:34 UTC (stable/9, 9.3-STABLE) 2014-09-09 10:13:46 UTC (releng/9.3, 9.3-RELEASE-p1) 2014-09-09 10:13:46 UTC (releng/9.2, 9.2-RELEASE-p11) 2014-09-09 10:13:46 UTC (releng/9.1, 9.1-RELEASE-p18) 2014-08-07 21:06:34 UTC (stable/8, 8.4-STABLE) 2014-09-09 10:13:46 UTC (releng/8.4, 8.4-RELEASE-p15) CVE Name: CVE-2014-3506, CVE-2014-3507, CVE-2014-3508, CVE-2014-3510, CVE-2014-3509, CVE-2014-3511, CVE-2014-3512, CVE-2014-5139 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background FreeBSD includes software from the OpenSSL Project. The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, full-featured Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library. II. Problem Description The receipt of a specifically crafted DTLS handshake message may cause OpenSSL to consume large amounts of memory. [CVE-2014-3506] The receipt of a specifically crafted DTLS packet could cause OpenSSL to leak memory. [CVE-2014-3507] A flaw in OBJ_obj2txt may cause pretty printing functions such as X509_name_oneline, X509_name_print_ex et al. to leak some information from the stack. [CVE-2014-3508] OpenSSL DTLS clients enabling anonymous (EC)DH ciphersuites are subject to a denial of service attack. [CVE-2014-3510] The following problems affect FreeBSD 10.0-RELEASE and later: If a multithreaded client connects to a malicious server using a resumed session and the server sends an ec point format extension it could write up to 255 bytes to freed memory. [CVE-2014-3509] A flaw in the OpenSSL SSL/TLS server code causes the server to negotiate TLS 1.0 instead of higher protocol versions when the ClientHello message is badly fragmented. [CVE-2014-3511] A malicious client or server can send invalid SRP parameters and overrun an internal buffer. [CVE-2014-3512] A malicious server can crash the client with a NULL pointer dereference by specifying a SRP ciphersuite even though it was not properly negotiated with the client. [CVE-2014-5139] III. Impact A remote attacker may be able to cause a denial of service (application crash, large memory consumption), obtain additional information, cause protocol downgrade. Additionally, a remote attacker may be able to run arbitrary code on a vulnerable system if the application has been set up for SRP. IV. Workaround No workaround is available. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. 2) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. [FreeBSD 10.0] # fetch http://security.FreeBSD.org/patches/SA-14:18/openssl-10.0.patch # fetch http://security.FreeBSD.org/patches/SA-14:18/openssl-10.0.patch.asc # gpg --verify openssl-10.0.patch.asc [FreeBSD 9.3] # fetch http://security.FreeBSD.org/patches/SA-14:18/openssl-9.3.patch # fetch http://security.FreeBSD.org/patches/SA-14:18/openssl-9.3.patch.asc # gpg --verify openssl-9.3.patch.asc [FreeBSD 9.2, 9.1, 8.4] # fetch http://security.FreeBSD.org/patches/SA-14:18/openssl-9.patch # fetch http://security.FreeBSD.org/patches/SA-14:18/openssl-9.patch.asc # gpg --verify openssl-9.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile the operating system using buildworld and installworld as described in . Restart all deamons using the library, or reboot the system. 3) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - ------------------------------------------------------------------------- stable/8/ r269687 releng/8.4/ r271305 stable/9/ r269687 releng/9.1/ r271305 releng/9.2/ r271305 releng/9.3/ r271305 stable/10/ r269686 releng/10.0/ r271304 - ------------------------------------------------------------------------- To see which files were modified by a particular revision, run the following command, replacing NNNNNN with the revision number, on a machine with Subversion installed: # svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base Or visit the following URL, replacing NNNNNN with the revision number: VII. References The latest revision of this advisory is available at -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUDtUBAAoJEO1n7NZdz2rnOUoP/jNoEEPVt1RoVPQoOQc6vno5 2HXcCDsu0ql3kCNIIZ7E6TddfduzV04EMzBrIgulg7eXft+Lnx6HlEgJOo7QLImc aWLWxjcbyby6wrbYOc+FLK11yx9/uZJF0VCdSeyzhy0EFD3tOZPsDMXKZmG7FRkg 6A7ENJU25Mx8V1myzHw/VfDwAHCtXHliFVVE0CUku55pYnlhMeetu/wuB6KYbmgV 1WUamiHEGl4Dh4Up7nGHYYm32kqZLaE+cf1Ovc2VGT98ZyXmCgDB4+8kkA/HZxxp DRgQlojeQhahee5MmzD+wMJXlq6dekoo+JVf22+Nb+oNmlKT6/UxtUhCwW11MLUV rnOMr3u1JCNvBc+3KroSmtFeEtqh7jx3Ag4w8lS5mJO+wX1/lilbsFxSS/9G65fy LqHUQSxkuDJ1bNzPfKreBPyUmQlG5t/3DonIDCF9r3sefDN+kxqe1+RwjdNRM0ov V7OH/AW1NBQtV/F/h0tKCcskvcJo9Q+inAohheLPnWkFj7F2tLNt5TAxsGy7WvFZ MuQSAXpZkdh7OkhAhBM3Xk+EOv7Qk7zZL5HJ1Lpm6kfJ8wSb4etoUV7oELaDMBz8 +9r+Vr9GtjSsec2a4tjNIixZKV9bzEhgKP5gsWD/JewhAzF+0bYNa9snOWxzpAYb j+eW9IT7pEAJK9DtIsDd =f4To -----END PGP SIGNATURE----- _______________________________________________ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" -- Share now a pigeon's flight Bluebound along the ancient skies, Its women forever hair and mammal, A Mediterranean town may arise If you rip apart a pigeon's heart. From owner-freebsd-stable@FreeBSD.ORG Mon Oct 20 10:29:39 2014 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 51C8FC1C for ; Mon, 20 Oct 2014 10:29:39 +0000 (UTC) Received: from mta1.riverwillow.net.au (mta1.riverwillow.net.au [IPv6:2001:8000:1000:1801::36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mta1.riverwillow.net.au", Issuer "Riverwillow Root Certificate 2010-04-12" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9B509E27 for ; Mon, 20 Oct 2014 10:29:37 +0000 (UTC) Received: from mail1.riverwillow.net.au (mail1.riverwillow.net.au [IPv6:2001:8000:1000:1801::46]) by mta1.riverwillow.net.au (8.14.9/8.14.9) with ESMTP id s9KAD8Lt037870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 20 Oct 2014 21:13:08 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=mta1002; t=1413799989; bh=bevhGgufBPpzjviObtZv02eSLO7U4Rq2/D6CTMyS5TQ=; h=Date:From:To:Subject:References:In-Reply-To; b=CUo1bL4H3CL3hsbX0eEpzYx1pHZwiwCwUC5lYogXO2JI4XIOIiRzJuPu8Xj5ZcTRc WjjiXigk9GtuVJAPRGvXjFrGGcuN0uvBSPpMUoY70o9b9bp1az0tyQV1NZ+VMfxjPJ jZnxqeu7oPmfk6q18Ld/F3mfqRYzfD1XlbZOI4Fc= Received: from rwpc15.gfn.riverwillow.net.au (rwpc15.gfn.riverwillow.net.au [IPv6:2001:8000:1000:18e1:20c:76ff:fe0a:2117]) (authenticated bits=56) by mail1.riverwillow.net.au (8.14.9/8.14.9) with ESMTP id s9KAD6FD037866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 20 Oct 2014 21:13:08 +1100 (AEDT) Date: Mon, 20 Oct 2014 21:13:06 +1100 From: John Marshall To: freebsd-stable@freebsd.org Subject: Re: 10.1-RC1 tar(1) spurious directory traversal permission error Message-ID: <20141020101306.GD1120@rwpc15.gfn.riverwillow.net.au> Mail-Followup-To: freebsd-stable@freebsd.org References: <20141020090424.GB1120@rwpc15.gfn.riverwillow.net.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qcHopEYAB45HaUaB" Content-Disposition: inline In-Reply-To: OpenPGP: id=A29A84A2; url=http://pki.riverwillow.com.au/pgp/johnmarshall.asc 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, 20 Oct 2014 10:29:39 -0000 --qcHopEYAB45HaUaB Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 20 Oct 2014, 11:22 +0200, Ronald Klop wrote: > Maybe the output of 'truss -o /tmp/truss.txt tar -czf dtt.tgz -C =20 > /data/tftp/thlan .' gives interesting information about what is exactly = =20 > giving the permission denied. I am not familiar with truss(1). The manual page doesn't indicate that I need to do anything other than issue the command suggested but the truss output file is empty and truss logs an error. $ truss -o /tmp/truss.txt tar -czf dtt.tgz -C /data/tftp/thlan . tar: .: Unable to continue traversing directory tree: Permission denied tar: Error exit delayed from previous errors. truss: can not get etype: No such process $=20 With with the parent directory set to o+r tar(1) is happy but truss(1) still does nothing. $ truss -o /tmp/truss.txt tar -czf dtt.tgz -C /data/tftp/thlan . truss: can not get etype: No such process $=20 --=20 John Marshall --qcHopEYAB45HaUaB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRE4DIACgkQw/tAaKKahKINbwCbB1X6tS8gvbQnpxp5gif0tRQH PDAAoKKT89JM6yqKXX5qAeICg33GWqK5 =xjDo -----END PGP SIGNATURE----- --qcHopEYAB45HaUaB-- From owner-freebsd-stable@FreeBSD.ORG Mon Oct 20 10:36:25 2014 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 4D84E1DD for ; Mon, 20 Oct 2014 10:36:25 +0000 (UTC) Received: from mta1.riverwillow.net.au (mta1.riverwillow.net.au [IPv6:2001:8000:1000:1801::36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mta1.riverwillow.net.au", Issuer "Riverwillow Root Certificate 2010-04-12" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 94BFFF38 for ; Mon, 20 Oct 2014 10:36:24 +0000 (UTC) Received: from mail1.riverwillow.net.au (mail1.riverwillow.net.au [IPv6:2001:8000:1000:1801::46]) by mta1.riverwillow.net.au (8.14.9/8.14.9) with ESMTP id s9KAaKK9038710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 20 Oct 2014 21:36:20 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=mta1002; t=1413801380; bh=/a87tX0+Z+0FJ92FiRST62mjMZ9y2WMaM5xDCDDgKnI=; h=Date:From:To:Subject:References:In-Reply-To; b=X+PSXxaSN+4C0SHsOtfdNJJvzqhQGXX/u/L4g+glWNpOW5ZVIO6jJxo1BuewHMRT3 RWJuFM2yoXPmtNxJbsheJ1uLm8MgXXlVOBtEwbnt/oH06xQlLC02EMXP2GVSIqFe0g LSPIcPkMTZbcve8pVu/O59+npTLJnSqZBU/tuICI= Received: from rwpc15.gfn.riverwillow.net.au (rwpc15.gfn.riverwillow.net.au [IPv6:2001:8000:1000:18e1:20c:76ff:fe0a:2117]) (authenticated bits=56) by mail1.riverwillow.net.au (8.14.9/8.14.9) with ESMTP id s9KAaHMV038708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 20 Oct 2014 21:36:18 +1100 (AEDT) Date: Mon, 20 Oct 2014 21:36:17 +1100 From: John Marshall To: freebsd-stable@freebsd.org Subject: Re: 10.1-RC1 tar(1) spurious directory traversal permission error Message-ID: <20141020103617.GE1120@rwpc15.gfn.riverwillow.net.au> Mail-Followup-To: freebsd-stable@freebsd.org References: <20141020090424.GB1120@rwpc15.gfn.riverwillow.net.au> <20141020101306.GD1120@rwpc15.gfn.riverwillow.net.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i7F3eY7HS/tUJxUd" Content-Disposition: inline In-Reply-To: <20141020101306.GD1120@rwpc15.gfn.riverwillow.net.au> OpenPGP: id=A29A84A2; url=http://pki.riverwillow.com.au/pgp/johnmarshall.asc 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, 20 Oct 2014 10:36:25 -0000 --i7F3eY7HS/tUJxUd Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 20 Oct 2014, 21:13 +1100, John Marshall wrote: > On Mon, 20 Oct 2014, 11:22 +0200, Ronald Klop wrote: > > Maybe the output of 'truss -o /tmp/truss.txt tar -czf dtt.tgz -C =20 > > /data/tftp/thlan .' gives interesting information about what is exactly= =20 > > giving the permission denied. > $ truss -o /tmp/truss.txt tar -czf dtt.tgz -C /data/tftp/thlan . > tar: .: Unable to continue traversing directory tree: Permission denied > tar: Error exit delayed from previous errors. > truss: can not get etype: No such process > $=20 Ahh,=20 # sysctl security.bsd.unprivileged_proc_debug=3D1 security.bsd.unprivileged_proc_debug: 0 -> 1 Copy of truss output available here: http://www.riverwillow.net.au/~john/10.1/tar_truss.txt --=20 John Marshall --i7F3eY7HS/tUJxUd Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRE5aEACgkQw/tAaKKahKJK6QCgpXZeDMDwkpBvswoy1JER6+Un uvkAoLTnjPakQarGj4amUkqUwquFEb2U =+fM0 -----END PGP SIGNATURE----- --i7F3eY7HS/tUJxUd-- From owner-freebsd-stable@FreeBSD.ORG Mon Oct 20 11:32:32 2014 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 9EEF71C2 for ; Mon, 20 Oct 2014 11:32:32 +0000 (UTC) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (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 6175F7BD for ; Mon, 20 Oct 2014 11:32:32 +0000 (UTC) Received: from 2a02-8428-011b-e000-0290-f5ff-fe9d-b78c.rev.sfr.net ([2a02:8428:11b:e000:290:f5ff:fe9d:b78c] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XgBCQ-0007ep-1F for freebsd-stable@freebsd.org; Mon, 20 Oct 2014 13:32:30 +0200 Message-ID: <5444F2C3.4060109@dumbbell.fr> Date: Mon, 20 Oct 2014 13:32:19 +0200 From: =?windows-1252?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG) References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IuWRFvKbHXp9WIRXtMoWOL03akfKgHabF" 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, 20 Oct 2014 11:32:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IuWRFvKbHXp9WIRXtMoWOL03akfKgHabF Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 20.10.2014 12:01, Pete French wrote: > Has this happened ? I was expecting to see an ATI UMS port appeat, and > for the non UMS port to move to version 7, but have been checking > and I still get this: >=20 > $ pkg search xf86-video-ati > xf86-video-ati-6.14.6_4 > xf86-video-ati-ums-6.14.6_4 Yes, WITH_NEW_XORG is enabled everywhere now. pkg search returns the correct packages for 11-CURRENT: $ pkg search xf86-video-ati xf86-video-ati-7.2.0_4 xf86-video-ati-ums-6.14.6_4 What version of FreeBSD do you use? --=20 Jean-S=E9bastien P=E9dron --IuWRFvKbHXp9WIRXtMoWOL03akfKgHabF 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 iQJ8BAEBCgBmBQJURPLIXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTMF0wP/jyRU64lJmOVttHKAbMVX0Pl /N+jJlKxjjVzUwvi4TD3PJRZphIhZn6WrVgEdwR31lKfuiASeXgfB47+wPaWQ3rW KqRhum5nhaHOmt7aLrqwnoHFCxyamvY8UIxiWX5WGa7bY5GLeVVpYHSAyIrCal8P HRJS2R7Yvrt8cabtguXlGeCEEUINSi8tSBWmnH0ck1jrGhSpuOUY69NPN3Is4kF4 m8NOWPv+8VN28mmtgUPRLuzt4ecUwhf7ypmRrSlUP3gQmWoTfKzpx5x2EWump1Z1 yR8hhDkGKaAUZd5of/xREahgJO46Gj+7Uk+n8gcPaYtXnL6dtsJd6shhdQPnoULN XmnHJGGwo9UIZ7IU6Dc+VVkfOZp6eerwmiEfDJxF3eum1ndfx1Y/CXPUocumxifh 2wh7WN0APjvfaHpjKKiBODbySz+bTmDXdNC3O0pHwzku3zePG3988CXyOSxIpJGM t8cPal291VuoQdDFqlcC5qLOR/9+p/HrYxMuST3f+O0CLDmauDe2vojvXiDDmWQ9 sVcTOriPxueIoqvnyiaaGWim/FoD+6RBNQ/8AQoxT2YR/8OYOwayw6G6i1gpZDK4 EGkW9Dr4A0TBMdmboazNB3UtG2x8VcTRDQohp39XJkQrmlMSSimqJLAHw1E8NUh/ U0o9MnRXFmgUdDgxAuuK =InV9 -----END PGP SIGNATURE----- --IuWRFvKbHXp9WIRXtMoWOL03akfKgHabF-- From owner-freebsd-stable@FreeBSD.ORG Mon Oct 20 11:36:01 2014 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 8ABBD407 for ; Mon, 20 Oct 2014 11:36:01 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 492757ED for ; Mon, 20 Oct 2014 11:36:00 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1XgBFf-0006i9-C1 for freebsd-stable@freebsd.org; Mon, 20 Oct 2014 13:35:57 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: freebsd-stable@freebsd.org Subject: Re: Fwd: FreeBSD Security Advisory FreeBSD-SA-14:18.openssl References: <201409091104.s89B4uhi067535@freefall.freebsd.org> Date: Mon, 20 Oct 2014 13:35:50 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.17 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.3.2 X-Scan-Signature: 6819b1e11a0bfca853cb5292ba4954a6 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, 20 Oct 2014 11:36:01 -0000 Install port security/ca_root_nss and use: fetch --ca-cert=/usr/local/share/certs/ca-root-nss.crt http://security.FreeBSD.org/patches/SA-14:18/openssl-10.0.patch That works. And still checks validity of the https server as long as you trust the ca_root_nss port. But I think it is kind of lame the default certificates from base don't work out of the box. Ronald. On Mon, 20 Oct 2014 12:22:32 +0200, tethys ocean wrote: > I am using FreeBSD 10.0-STABLE on my servers. But according to this > mail > I tried > > [FreeBSD 10.0] > # fetch http://security.FreeBSD.org/patches/SA-14:18/openssl-10.0.patch > # fetch > http://security.FreeBSD.org/patches/SA-14:18/openssl-10.0.patch.asc > # gpg --verify openssl-10.0.patch.asc > > But my server say this below: > > fetch http://security.FreeBSD.org/patches/SA-14:18/openssl-10.0.patch > Certificate verification failed for /C=US/ST=UT/L=Salt Lake City/O=The > USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware > 675119676:error:14090086:SSL > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify > failed:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s3_clnt.c:1180: > fetch: http://security.FreeBSD.org/patches/SA-14:18/openssl-10.0.patch: > Authentication error > > What should I do ? > > thanx > > > > ---------- Forwarded message ---------- > From: FreeBSD Security Advisories > Date: Tue, Sep 9, 2014 at 2:04 PM > Subject: FreeBSD Security Advisory FreeBSD-SA-14:18.openssl > To: FreeBSD Security Advisories > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > ============================================================================= > FreeBSD-SA-14:18.openssl Security > Advisory > The FreeBSD > Project > > Topic: OpenSSL multiple vulnerabilities > > Category: contrib > Module: openssl > Announced: 2014-09-09 > Affects: All supported versions of FreeBSD. > Corrected: 2014-08-07 21:04:42 UTC (stable/10, 10.0-STABLE) > 2014-09-09 10:09:46 UTC (releng/10.0, 10.0-RELEASE-p8) > 2014-08-07 21:06:34 UTC (stable/9, 9.3-STABLE) > 2014-09-09 10:13:46 UTC (releng/9.3, 9.3-RELEASE-p1) > 2014-09-09 10:13:46 UTC (releng/9.2, 9.2-RELEASE-p11) > 2014-09-09 10:13:46 UTC (releng/9.1, 9.1-RELEASE-p18) > 2014-08-07 21:06:34 UTC (stable/8, 8.4-STABLE) > 2014-09-09 10:13:46 UTC (releng/8.4, 8.4-RELEASE-p15) > CVE Name: CVE-2014-3506, CVE-2014-3507, CVE-2014-3508, > CVE-2014-3510, > CVE-2014-3509, CVE-2014-3511, CVE-2014-3512, > CVE-2014-5139 > > For general information regarding FreeBSD Security Advisories, > including descriptions of the fields above, security branches, and the > following sections, please visit . > > I. Background > > FreeBSD includes software from the OpenSSL Project. The OpenSSL Project > is > a collaborative effort to develop a robust, commercial-grade, > full-featured > Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) > and Transport Layer Security (TLS v1) protocols as well as a > full-strength > general purpose cryptography library. > > II. Problem Description > > The receipt of a specifically crafted DTLS handshake message may cause > OpenSSL > to consume large amounts of memory. [CVE-2014-3506] > > The receipt of a specifically crafted DTLS packet could cause OpenSSL to > leak > memory. [CVE-2014-3507] > > A flaw in OBJ_obj2txt may cause pretty printing functions such as > X509_name_oneline, X509_name_print_ex et al. to leak some information > from > the stack. [CVE-2014-3508] > > OpenSSL DTLS clients enabling anonymous (EC)DH ciphersuites are subject > to > a denial of service attack. [CVE-2014-3510] > > The following problems affect FreeBSD 10.0-RELEASE and later: > > If a multithreaded client connects to a malicious server using a resumed > session and the server sends an ec point format extension it could write > up to 255 bytes to freed memory. [CVE-2014-3509] > > A flaw in the OpenSSL SSL/TLS server code causes the server to negotiate > TLS 1.0 instead of higher protocol versions when the ClientHello message > is badly fragmented. [CVE-2014-3511] > > A malicious client or server can send invalid SRP parameters and overrun > an internal buffer. [CVE-2014-3512] > > A malicious server can crash the client with a NULL pointer dereference > by > specifying a SRP ciphersuite even though it was not properly negotiated > with the client. [CVE-2014-5139] > > III. Impact > > A remote attacker may be able to cause a denial of service (application > crash, large memory consumption), obtain additional information, > cause protocol downgrade. Additionally, a remote attacker may be able > to run arbitrary code on a vulnerable system if the application has been > set up for SRP. > > IV. Workaround > > No workaround is available. > > V. Solution > > Perform one of the following: > > 1) Upgrade your vulnerable system to a supported FreeBSD stable or > release / security branch (releng) dated after the correction date. > > 2) To update your vulnerable system via a source code patch: > > The following patches have been verified to apply to the applicable > FreeBSD release branches. > > a) Download the relevant patch from the location below, and verify the > detached PGP signature using your PGP utility. > > [FreeBSD 10.0] > # fetch http://security.FreeBSD.org/patches/SA-14:18/openssl-10.0.patch > # fetch > http://security.FreeBSD.org/patches/SA-14:18/openssl-10.0.patch.asc > # gpg --verify openssl-10.0.patch.asc > > [FreeBSD 9.3] > # fetch http://security.FreeBSD.org/patches/SA-14:18/openssl-9.3.patch > # fetch > http://security.FreeBSD.org/patches/SA-14:18/openssl-9.3.patch.asc > # gpg --verify openssl-9.3.patch.asc > > [FreeBSD 9.2, 9.1, 8.4] > # fetch http://security.FreeBSD.org/patches/SA-14:18/openssl-9.patch > # fetch http://security.FreeBSD.org/patches/SA-14:18/openssl-9.patch.asc > # gpg --verify openssl-9.patch.asc > > b) Apply the patch. Execute the following commands as root: > > # cd /usr/src > # patch < /path/to/patch > > c) Recompile the operating system using buildworld and installworld as > described in . > > Restart all deamons using the library, or reboot the system. > > 3) To update your vulnerable system via a binary patch: > > Systems running a RELEASE version of FreeBSD on the i386 or amd64 > platforms can be updated via the freebsd-update(8) utility: > > # freebsd-update fetch > # freebsd-update install > > VI. Correction details > > The following list contains the correction revision numbers for each > affected branch. > > Branch/path Revision > - > ------------------------------------------------------------------------- > stable/8/ r269687 > releng/8.4/ r271305 > stable/9/ r269687 > releng/9.1/ r271305 > releng/9.2/ r271305 > releng/9.3/ r271305 > stable/10/ r269686 > releng/10.0/ r271304 > - > ------------------------------------------------------------------------- > > To see which files were modified by a particular revision, run the > following command, replacing NNNNNN with the revision number, on a > machine with Subversion installed: > > # svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base > > Or visit the following URL, replacing NNNNNN with the revision number: > > > > VII. References > > > > > > > > > > > > > > > > > > > > The latest revision of this advisory is available at > > -----BEGIN PGP SIGNATURE----- > > iQIcBAEBCgAGBQJUDtUBAAoJEO1n7NZdz2rnOUoP/jNoEEPVt1RoVPQoOQc6vno5 > 2HXcCDsu0ql3kCNIIZ7E6TddfduzV04EMzBrIgulg7eXft+Lnx6HlEgJOo7QLImc > aWLWxjcbyby6wrbYOc+FLK11yx9/uZJF0VCdSeyzhy0EFD3tOZPsDMXKZmG7FRkg > 6A7ENJU25Mx8V1myzHw/VfDwAHCtXHliFVVE0CUku55pYnlhMeetu/wuB6KYbmgV > 1WUamiHEGl4Dh4Up7nGHYYm32kqZLaE+cf1Ovc2VGT98ZyXmCgDB4+8kkA/HZxxp > DRgQlojeQhahee5MmzD+wMJXlq6dekoo+JVf22+Nb+oNmlKT6/UxtUhCwW11MLUV > rnOMr3u1JCNvBc+3KroSmtFeEtqh7jx3Ag4w8lS5mJO+wX1/lilbsFxSS/9G65fy > LqHUQSxkuDJ1bNzPfKreBPyUmQlG5t/3DonIDCF9r3sefDN+kxqe1+RwjdNRM0ov > V7OH/AW1NBQtV/F/h0tKCcskvcJo9Q+inAohheLPnWkFj7F2tLNt5TAxsGy7WvFZ > MuQSAXpZkdh7OkhAhBM3Xk+EOv7Qk7zZL5HJ1Lpm6kfJ8wSb4etoUV7oELaDMBz8 > +9r+Vr9GtjSsec2a4tjNIixZKV9bzEhgKP5gsWD/JewhAzF+0bYNa9snOWxzpAYb > j+eW9IT7pEAJK9DtIsDd > =f4To > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to > "freebsd-security-unsubscribe@freebsd.org" > > From owner-freebsd-stable@FreeBSD.ORG Mon Oct 20 11:40:20 2014 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 C9351559 for ; Mon, 20 Oct 2014 11:40:20 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8870C82F for ; Mon, 20 Oct 2014 11:40:20 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1XgBJt-0006vi-2F for freebsd-stable@freebsd.org; Mon, 20 Oct 2014 13:40:19 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: freebsd-stable@freebsd.org Subject: Re: 10.1-RC1 tar(1) spurious directory traversal permission error References: <20141020090424.GB1120@rwpc15.gfn.riverwillow.net.au> <20141020101306.GD1120@rwpc15.gfn.riverwillow.net.au> <20141020103617.GE1120@rwpc15.gfn.riverwillow.net.au> Date: Mon, 20 Oct 2014 13:40:12 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <20141020103617.GE1120@rwpc15.gfn.riverwillow.net.au> User-Agent: Opera Mail/12.17 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: - X-Spam-Score: -1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, BAYES_20 autolearn=disabled version=3.3.2 X-Scan-Signature: 2ecd0b53b7de9511489f92806276a3d7 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, 20 Oct 2014 11:40:20 -0000 On Mon, 20 Oct 2014 12:36:17 +0200, John Marshall wrote: > On Mon, 20 Oct 2014, 21:13 +1100, John Marshall wrote: >> On Mon, 20 Oct 2014, 11:22 +0200, Ronald Klop wrote: >> > Maybe the output of 'truss -o /tmp/truss.txt tar -czf dtt.tgz -C >> > /data/tftp/thlan .' gives interesting information about what is >> exactly >> > giving the permission denied. > >> $ truss -o /tmp/truss.txt tar -czf dtt.tgz -C /data/tftp/thlan . >> tar: .: Unable to continue traversing directory tree: Permission >> denied >> tar: Error exit delayed from previous errors. >> truss: can not get etype: No such process >> $ > > Ahh, > > # sysctl security.bsd.unprivileged_proc_debug=1 > security.bsd.unprivileged_proc_debug: 0 -> 1 > > Copy of truss output available here: > > http://www.riverwillow.net.au/~john/10.1/tar_truss.txt > Interesting. Maybe the people at the mailinglists at http://www.libarchive.org/ are also interested. That is the source of the tar command in FreeBSD. Ronald. From owner-freebsd-stable@FreeBSD.ORG Mon Oct 20 12:16:40 2014 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 DF84AD6B for ; Mon, 20 Oct 2014 12:16:40 +0000 (UTC) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) (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 A8D9AC1C for ; Mon, 20 Oct 2014 12:16:40 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XgBt6-000FBg-Oq; Mon, 20 Oct 2014 12:16:36 +0000 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XgBt6-0004nO-MV; Mon, 20 Oct 2014 13:16:36 +0100 To: freebsd-stable@freebsd.org, jean-sebastien.pedron@dumbbell.fr Subject: Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG) In-Reply-To: <5444F2C3.4060109@dumbbell.fr> Message-Id: From: Pete French Date: Mon, 20 Oct 2014 13:16:36 +0100 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, 20 Oct 2014 12:16:41 -0000 > Yes, WITH_NEW_XORG is enabled everywhere now. pkg search returns the > correct packages for 11-CURRENT: > > $ pkg search xf86-video-ati > xf86-video-ati-7.2.0_4 > xf86-video-ati-ums-6.14.6_4 > > What version of FreeBSD do you use? 9.2 pete. From owner-freebsd-stable@FreeBSD.ORG Mon Oct 20 12:28:28 2014 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 51238C2 for ; Mon, 20 Oct 2014 12:28:28 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F0ACBD19 for ; Mon, 20 Oct 2014 12:28:27 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1XgC4M-0002Pe-33; Mon, 20 Oct 2014 14:28:25 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "tethys ocean" Subject: Re: Fwd: FreeBSD Security Advisory FreeBSD-SA-14:18.openssl References: <201409091104.s89B4uhi067535@freefall.freebsd.org> Date: Mon, 20 Oct 2014 14:28:13 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.17 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.3.2 X-Scan-Signature: 7d2773b323cdbb96061e7933c7784c4b 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, 20 Oct 2014 12:28:28 -0000 Can you do 'ls /usr/local/share/certs/ca-root-nss.crt'? Fetch does not complain if the cert-file does not exist (see below), but continues with no certificate chain. Using the -v option to fetch might also help in finding the cause. fetch -v --ca-cert=/yeahyeahyeah http://security.FreeBSD.org/patches/SA-14:18/openssl-10.0.patch looking up security.FreeBSD.org connecting to security.FreeBSD.org:80 requesting http://security.FreeBSD.org/patches/SA-14:18/openssl-10.0.patch 301 redirect to https://www.FreeBSD.org/security/patches/SA-14:18/openssl-10.0.patch looking up www.FreeBSD.org connecting to www.FreeBSD.org:443 SSL options: 81004bff Peer verification enabled Using CA cert file: /yeahyeahyeah Certificate verification failed for /C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware 34380945272:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s3_clnt.c:1180: fetch: http://security.FreeBSD.org/patches/SA-14:18/openssl-10.0.patch: Authentication error As a last resort (but 'unsafe') you can add the option '--no-verify-peer' to fetch. Ronald. On Mon, 20 Oct 2014 14:06:49 +0200, tethys ocean wrote: > Again same err. hust below > > fetch --ca-cert=/usr/local/share/certs/ca-root-nss.crt > http://security.FreeBSD.org/patches/SA-14:18/openssl-10.0.patch > Certificate verification failed for /C=US/ST=UT/L=Salt Lake City/O=The > USERTRUST Network/OU=http://www.usertrust.com/>CN=UTN-USERFirst-Hardware > 675119676:error:14090086:SSL > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify > failed:/usr/src/secure/lib/libssl/../../../>crypto/openssl/ssl/s3_clnt.c:1180: > fetch: http://security.FreeBSD.org/patches/SA-14:18/openssl-10.0.patch: > Authentication error > > > > On Mon, Oct 20, 2014 at 2:35 PM, Ronald Klop > wrote: >> Install port security/ca_root_nss and use: >> >> fetch --ca-cert=/usr/local/share/certs/ca-root-nss.crt >> http://security.FreeBSD.org/patches/SA-14:18/>>openssl-10.0.patch >> >> >> >> That works. And still checks validity of the https server as long as >> you trust the ca_root_nss port. >> >> >> >> But I think it is kind of lame the default certificates from base don't >> work out of the box. >> >> >> >> Ronald. >> >> >> >> >> >> >> >> >> On Mon, 20 Oct 2014 12:22:32 +0200, tethys ocean >> wrote: >> >> >> >>> >>> I am using FreeBSD 10.0-STABLE on my servers. But according to this >>> mail >>> >>> I tried >>> >>> >>> >>> [FreeBSD 10.0] >>> >>> # fetch http://security.FreeBSD.org/patches/SA-14:18/openssl-10.0.patch >>> >>> # fetch >>> http://security.FreeBSD.org/patches/SA-14:18/openssl-10.0.patch.asc >>> >>> # gpg --verify openssl-10.0.patch.asc >>> >>> >>> >>> But my server say this below: >>> >>> >>> >>> fetch http://security.FreeBSD.org/patches/SA-14:18/openssl-10.0.patch >>> >>> Certificate verification failed for /C=US/ST=UT/L=Salt Lake City/O=The >>> >>> USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware >>> >>> 675119676:error:14090086:SSL >>> >>> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify >>> >>> failed:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s3_clnt.c:1180: >>> >>> fetch: http://security.FreeBSD.org/patches/SA-14:18/openssl-10.0.patch: >>> >>> Authentication error >>> >>> >>> >>> What should I do ? >>> >>> >>> >>> thanx >>> >>> >>> >>> >>> >>> >>> >>> ---------- Forwarded message ---------- >>> >>> From: FreeBSD Security Advisories >>> >>> Date: Tue, Sep 9, 2014 at 2:04 PM >>> >>> Subject: FreeBSD Security Advisory FreeBSD-SA-14:18.openssl >>> >>> To: FreeBSD Security Advisories >>> >>> >>> >>> >>> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> >>> Hash: SHA512 >>> >>> >>> >>> ============================================================================= >>> >>> FreeBSD-SA-14:18.openssl Security >>> >>> Advisory >>> >>> The FreeBSD >>> >>> Project >>> >>> >>> >>> Topic: OpenSSL multiple vulnerabilities >>> >>> >>> >>> Category: contrib >>> >>> Module: openssl >>> >>> Announced: 2014-09-09 >>> >>> Affects: All supported versions of FreeBSD. >>> >>> Corrected: 2014-08-07 21:04:42 UTC (stable/10, 10.0-STABLE) >>> >>> 2014-09-09 10:09:46 UTC (releng/10.0, 10.0-RELEASE-p8) >>> >>> 2014-08-07 21:06:34 UTC (stable/9, 9.3-STABLE) >>> >>> 2014-09-09 10:13:46 UTC (releng/9.3, 9.3-RELEASE-p1) >>> >>> 2014-09-09 10:13:46 UTC (releng/9.2, 9.2-RELEASE-p11) >>> >>> 2014-09-09 10:13:46 UTC (releng/9.1, 9.1-RELEASE-p18) >>> >>> 2014-08-07 21:06:34 UTC (stable/8, 8.4-STABLE) >>> >>> 2014-09-09 10:13:46 UTC (releng/8.4, 8.4-RELEASE-p15) >>> >>> CVE Name: CVE-2014-3506, CVE-2014-3507, CVE-2014-3508, >>> CVE-2014-3510, >>> >>> CVE-2014-3509, CVE-2014-3511, CVE-2014-3512, >>> CVE-2014-5139 >>> >>> >>> >>> For general information regarding FreeBSD Security Advisories, >>> >>> including descriptions of the fields above, security branches, and the >>> >>> following sections, please visit . >>> >>> >>> >>> I. Background >>> >>> >>> >>> FreeBSD includes software from the OpenSSL Project. The OpenSSL >>> Project is >>> >>> a collaborative effort to develop a robust, commercial-grade, >>> full-featured >>> >>> Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) >>> >>> and Transport Layer Security (TLS v1) protocols as well as a >>> full-strength >>> >>> general purpose cryptography library. >>> >>> >>> >>> II. Problem Description >>> >>> >>> >>> The receipt of a specifically crafted DTLS handshake message may cause >>> >>> OpenSSL >>> >>> to consume large amounts of memory. [CVE-2014-3506] >>> >>> >>> >>> The receipt of a specifically crafted DTLS packet could cause OpenSSL >>> to >>> >>> leak >>> >>> memory. [CVE-2014-3507] >>> >>> >>> >>> A flaw in OBJ_obj2txt may cause pretty printing functions such as >>> >>> X509_name_oneline, X509_name_print_ex et al. to leak some information >>> from >>> >>> the stack. [CVE-2014-3508] >>> >>> >>> >>> OpenSSL DTLS clients enabling anonymous (EC)DH ciphersuites are >>> subject to >>> >>> a denial of service attack. [CVE-2014-3510] >>> >>> >>> >>> The following problems affect FreeBSD 10.0-RELEASE and later: >>> >>> >>> >>> If a multithreaded client connects to a malicious server using a >>> resumed >>> >>> session and the server sends an ec point format extension it could >>> write >>> >>> up to 255 bytes to freed memory. [CVE-2014-3509] >>> >>> >>> >>> A flaw in the OpenSSL SSL/TLS server code causes the server to >>> negotiate >>> >>> TLS 1.0 instead of higher protocol versions when the ClientHello >>> message >>> >>> is badly fragmented. [CVE-2014-3511] >>> >>> >>> >>> A malicious client or server can send invalid SRP parameters and >>> overrun >>> >>> an internal buffer. [CVE-2014-3512] >>> >>> >>> >>> A malicious server can crash the client with a NULL pointer >>> dereference by >>> >>> specifying a SRP ciphersuite even though it was not properly negotiated >>> >>> with the client. [CVE-2014-5139] >>> >>> >>> >>> III. Impact >>> >>> >>> >>> A remote attacker may be able to cause a denial of service (application >>> >>> crash, large memory consumption), obtain additional information, >>> >>> cause protocol downgrade. Additionally, a remote attacker may be able >>> >>> to run arbitrary code on a vulnerable system if the application has >>> been >>> >>> set up for SRP. >>> >>> >>> >>> IV. Workaround >>> >>> >>> >>> No workaround is available. >>> >>> >>> >>> V. Solution >>> >>> >>> >>> Perform one of the following: >>> >>> >>> >>> 1) Upgrade your vulnerable system to a supported FreeBSD stable or >>> >>> release / security branch (releng) dated after the correction date. >>> >>> >>> >>> 2) To update your vulnerable system via a source code patch: >>> >>> >>> >>> The following patches have been verified to apply to the applicable >>> >>> FreeBSD release branches. >>> >>> >>> >>> a) Download the relevant patch from the location below, and verify the >>> >>> detached PGP signature using your PGP utility. >>> >>> >>> >>> [FreeBSD 10.0] >>> >>> # fetch http://security.FreeBSD.org/patches/SA-14:18/openssl-10.0.patch >>> >>> # fetch >>> http://security.FreeBSD.org/patches/SA-14:18/openssl-10.0.patch.asc >>> >>> # gpg --verify openssl-10.0.patch.asc >>> >>> >>> >>> [FreeBSD 9.3] >>> >>> # fetch http://security.FreeBSD.org/patches/SA-14:18/openssl-9.3.patch >>> >>> # fetch >>> http://security.FreeBSD.org/patches/SA-14:18/openssl-9.3.patch.asc >>> >>> # gpg --verify openssl-9.3.patch.asc >>> >>> >>> >>> [FreeBSD 9.2, 9.1, 8.4] >>> >>> # fetch http://security.FreeBSD.org/patches/SA-14:18/openssl-9.patch >>> >>> # fetch >>> http://security.FreeBSD.org/patches/SA-14:18/openssl-9.patch.asc >>> >>> # gpg --verify openssl-9.patch.asc >>> >>> >>> >>> b) Apply the patch. Execute the following commands as root: >>> >>> >>> >>> # cd /usr/src >>> >>> # patch < /path/to/patch >>> >>> >>> >>> c) Recompile the operating system using buildworld and installworld as >>> >>> described in . >>> >>> >>> >>> Restart all deamons using the library, or reboot the system. >>> >>> >>> >>> 3) To update your vulnerable system via a binary patch: >>> >>> >>> >>> Systems running a RELEASE version of FreeBSD on the i386 or amd64 >>> >>> platforms can be updated via the freebsd-update(8) utility: >>> >>> >>> >>> # freebsd-update fetch >>> >>> # freebsd-update install >>> >>> >>> >>> VI. Correction details >>> >>> >>> >>> The following list contains the correction revision numbers for each >>> >>> affected branch. >>> >>> >>> >>> Branch/path >>> Revision >>> >>> - >>> ------------------------------------------------------------------------- >>> >>> stable/8/ >>> r269687 >>> >>> releng/8.4/ >>> r271305 >>> >>> stable/9/ >>> r269687 >>> >>> releng/9.1/ >>> r271305 >>> >>> releng/9.2/ >>> r271305 >>> >>> releng/9.3/ >>> r271305 >>> >>> stable/10/ >>> r269686 >>> >>> releng/10.0/ >>> r271304 >>> >>> - >>> ------------------------------------------------------------------------- >>> >>> >>> >>> To see which files were modified by a particular revision, run the >>> >>> following command, replacing NNNNNN with the revision number, on a >>> >>> machine with Subversion installed: >>> >>> >>> >>> # svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base >>> >>> >>> >>> Or visit the following URL, replacing NNNNNN with the revision number: >>> >>> >>> >>> >>> >>> >>> >>> VII. References >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> The latest revision of this advisory is available at >>> >>> >>> >>> -----BEGIN PGP SIGNATURE----- >>> >>> >>> >>> iQIcBAEBCgAGBQJUDtUBAAoJEO1n7NZdz2rnOUoP/jNoEEPVt1RoVPQoOQc6vno5 >>> >>> 2HXcCDsu0ql3kCNIIZ7E6TddfduzV04EMzBrIgulg7eXft+Lnx6HlEgJOo7QLImc >>> >>> aWLWxjcbyby6wrbYOc+FLK11yx9/uZJF0VCdSeyzhy0EFD3tOZPsDMXKZmG7FRkg >>> >>> 6A7ENJU25Mx8V1myzHw/VfDwAHCtXHliFVVE0CUku55pYnlhMeetu/wuB6KYbmgV >>> >>> 1WUamiHEGl4Dh4Up7nGHYYm32kqZLaE+cf1Ovc2VGT98ZyXmCgDB4+8kkA/HZxxp >>> >>> DRgQlojeQhahee5MmzD+wMJXlq6dekoo+JVf22+Nb+oNmlKT6/UxtUhCwW11MLUV >>> >>> rnOMr3u1JCNvBc+3KroSmtFeEtqh7jx3Ag4w8lS5mJO+wX1/lilbsFxSS/9G65fy >>> >>> LqHUQSxkuDJ1bNzPfKreBPyUmQlG5t/3DonIDCF9r3sefDN+kxqe1+RwjdNRM0ov >>> >>> V7OH/AW1NBQtV/F/h0tKCcskvcJo9Q+inAohheLPnWkFj7F2tLNt5TAxsGy7WvFZ >>> >>> MuQSAXpZkdh7OkhAhBM3Xk+EOv7Qk7zZL5HJ1Lpm6kfJ8wSb4etoUV7oELaDMBz8 >>> >>> +9r+Vr9GtjSsec2a4tjNIixZKV9bzEhgKP5gsWD/JewhAzF+0bYNa9snOWxzpAYb >>> >>> j+eW9IT7pEAJK9DtIsDd >>> >>> =f4To >>> >>> -----END PGP SIGNATURE----- >>> >>> _______________________________________________ >>> >>> freebsd-security@freebsd.org mailing list >>> >>> http://lists.freebsd.org/mailman/listinfo/freebsd-security >>> >>> To unsubscribe, send any mail to >>> "freebsd-security-unsubscribe@freebsd.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" >> > > > > --Share now a pigeon's flightBluebound along the ancient skies,Its women > forever hair and mammal,A Mediterranean town may ariseIf you rip apart a > pigeon's heart. From owner-freebsd-stable@FreeBSD.ORG Mon Oct 20 13:54:49 2014 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 3DB55B7E for ; Mon, 20 Oct 2014 13:54:49 +0000 (UTC) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (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 00F4C9A8 for ; Mon, 20 Oct 2014 13:54:49 +0000 (UTC) Received: from 2a02-8428-011b-e000-0290-f5ff-fe9d-b78c.rev.sfr.net ([2a02:8428:11b:e000:290:f5ff:fe9d:b78c] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XgDQ6-0009JX-Nn for freebsd-stable@freebsd.org; Mon, 20 Oct 2014 15:54:47 +0200 Message-ID: <54451422.1070403@FreeBSD.org> Date: Mon, 20 Oct 2014 15:54:42 +0200 From: =?windows-1252?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG) References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cQvBk5Mvqahckl0KtH4kocV9RiacSe1Rq" 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, 20 Oct 2014 13:54:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cQvBk5Mvqahckl0KtH4kocV9RiacSe1Rq Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 20.10.2014 14:16, Pete French wrote: >> What version of FreeBSD do you use? >=20 > 9.2 You're right, there seems to be something wrong. I'll discuss this with the graphics team. Thank you! --=20 Jean-S=E9bastien P=E9dron --cQvBk5Mvqahckl0KtH4kocV9RiacSe1Rq 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 iQJ8BAEBCgBmBQJURRQmXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTMp7EP/0Ozm2uuQequUuztcXc4cCXl CdAvYH+NcJhYuQndZSpLduFTOWkZOkGNejcj7hsSYvO0gnlLYyiv+abaUcz0q80e WWzaqiv+OxY8WHzgMntczp302E4po4K0EXdnuXVvWxQZ4DEvKCSZGdVLr/ltPGDI NOcbRILlxm4HRf/Agl9ZG0CEWAg+/a1XVpUNMYbek6WDVXV14LYQtI0Z50vo1NjS G16uP3XoEWt6vcml1VVsIllLxBeMggxOm1nIRpA3CJ9jakNzethVENXkP1FxyCE5 NYDN9OjcEnHrJhdf3Xbj6pVqyzt3yFjPuyZk12SkxxUH+cYVGzCqDGQhRdmFNCtL miy4ngsH+TqaYJPMFocCLp6wQvjwc+Oyx4SozICQ+UT/k00H/N+B3zVf57Rrop6G 0MUa/oaLBJc6TCLVR37e07Qj7ah6rGMJP9OnJjyQD5Nu5kQ5QNSUWdPhamHfs2c4 Tyk1VVCJKzqPVpNopjzzbeTlF9eVOGx0fcS3Ps07pqnip4MCvIrPJujtgCO8CVht pSG2D8eYB1JU/2CzmBir2zySG3vW3fB7Gl4ULjOyb79AbuJRvIiovfCyb63u49eB kN6UC0befJs7BiVzXLhxRsVmHUyuCUDCfyGflCLfFF7iQSjS7b5VPMq7hTItzH/i 543KYXK3grmmbB1pu6yR =TZFq -----END PGP SIGNATURE----- --cQvBk5Mvqahckl0KtH4kocV9RiacSe1Rq-- From owner-freebsd-stable@FreeBSD.ORG Mon Oct 20 14:32:28 2014 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 36D42B66 for ; Mon, 20 Oct 2014 14:32:28 +0000 (UTC) Received: from lena.kiev.ua (lena.kiev.ua [82.146.51.205]) (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 EF29A12C for ; Mon, 20 Oct 2014 14:32:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lena.kiev.ua; s=3; h=In-Reply-To:Content-Type:Mime-Version:References:Message-ID:Subject:To:From:Date; bh=2zfQSqwxopVrcG0RLbEtxbZZaCzlD4izZ5dqBrqoy4A=; b=LU32tWAv364cMvVUiyG3CZcXguKESlJHeNrSW6rJG7QqxadE+FTOURk6Wig7QcQ5s0Irg+OMw9sFrx6kqIyXjYC56cSH2I7gs4OSqYoIX9FPSHgu/3bidvGstBqxwF+XCDY5WqovtgvjcqS9uRWGvqinJUmh6mhqQH209uhfHEU=; Received: from ip-384c.rusanovka-net.kiev.ua ([94.244.56.76] helo=bedside.lena.kiev.ua) by lena.kiev.ua with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.83 (FreeBSD)) (envelope-from ) id 1XgE0W-0001pM-6E for freebsd-stable@freebsd.org; Mon, 20 Oct 2014 17:32:24 +0300 Received: from bedside.lena.kiev.ua (localhost.lena.kiev.ua [127.0.0.1]) by bedside.lena.kiev.ua (8.14.9/8.14.9) with ESMTP id s9KEWDgp006056 for ; Mon, 20 Oct 2014 17:32:13 +0300 (EEST) (envelope-from Lena@lena.kiev.ua) X-Authentication-Warning: bedside.lena.kiev.ua: Host localhost.lena.kiev.ua [127.0.0.1] claimed to be bedside.lena.kiev.ua Received: (from lena@localhost) by bedside.lena.kiev.ua (8.14.9/8.14.9/Submit) id s9KEWDeQ006055 for freebsd-stable@freebsd.org; Mon, 20 Oct 2014 17:32:13 +0300 (EEST) (envelope-from Lena@lena.kiev.ua) Date: Mon, 20 Oct 2014 17:32:13 +0300 From: Lena@lena.kiev.ua To: freebsd-stable@freebsd.org Subject: Re: vt(4) "newcons" and 80x25 vty? (tested: 10.1-BETA2) Message-ID: <20141020143213.GS817@lena.kiev> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <544404EE.6070609@FreeBSD.org> User-Agent: Mutt/1.4.2.3i 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, 20 Oct 2014 14:32:28 -0000 > From: Jean-S?bastien P?dron > > * VT in VGA textmode fonts loading broken (tested 10.1-BETA2). Tried > > vidfont(1) and also vidcontrol -f [size] [filename]. For loading "VGA" > > fonts, screen weird/unusable (see below). For loading Gallant (12x22), > > the virtual terminal freeze (both other vty still ok). > > Still correct: there's a bug here. In VGA text mode, loading a font > should be rejected. The purpose of text mode is to let the video card > draw the text itself. With sc(4), font is loaded into the video card. In rc.conf: font8x16="cp866u-8x16" scrnmap="koi8-u2cp866u" keymap="ru.koi8-r" allscreens_flags="80x30" ~ $ locale LANG=ru_RU.KOI8-R Please don't force people to change locale to Unicode in case of motherboard replacement to Intel video. From owner-freebsd-stable@FreeBSD.ORG Mon Oct 20 14:37:38 2014 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 3B400E02 for ; Mon, 20 Oct 2014 14:37:38 +0000 (UTC) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (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 F1F681BC for ; Mon, 20 Oct 2014 14:37:37 +0000 (UTC) Received: from 2a02-8428-011b-e000-0290-f5ff-fe9d-b78c.rev.sfr.net ([2a02:8428:11b:e000:290:f5ff:fe9d:b78c] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XgE5Y-0009oC-3H for freebsd-stable@freebsd.org; Mon, 20 Oct 2014 16:37:36 +0200 Message-ID: <54451E2A.1020309@FreeBSD.org> Date: Mon, 20 Oct 2014 16:37:30 +0200 From: =?windows-1252?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG) References: <54451422.1070403@FreeBSD.org> In-Reply-To: <54451422.1070403@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sisfJ60kqelviW65RSDMvxxBej1SqkNxN" 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, 20 Oct 2014 14:37:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sisfJ60kqelviW65RSDMvxxBej1SqkNxN Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 20.10.2014 15:54, Jean-S=E9bastien P=E9dron wrote: > On 20.10.2014 14:16, Pete French wrote: >>> What version of FreeBSD do you use? >> >> 9.2 >=20 > You're right, there seems to be something wrong. I'll discuss this with= > the graphics team. Koop Mast just committed a fix to the Ports tree. --=20 Jean-S=E9bastien P=E9dron --sisfJ60kqelviW65RSDMvxxBej1SqkNxN 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 iQJ8BAEBCgBmBQJURR4vXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTMPcIP/3dH4eg03wP7xLIHAHwpFyct CyYERu4TedQDwFD5CMJS4dGd60RMtTXoQxcgz5UtIR3s7PMHUQsqW9HHd6nS4Se0 Lx7I+Riz20/jxBJZnBY0s29uBDE0i958CWqBusjDE4gG3VNhms9BHAFUS3Ld/QkM UK+Xse2mJj1wyh3pv5FIOK6Fsc8hQFwmA4RIr/ZsfSkCw5tznJnCyAaQMgifwc1Z dWjZB50a+8XSW7UI6p4IbvGm2hfdZD6KB4ySVMDJ1ClQMu6Ox5s635Qn/02vQLlt tG4ONqFGH1pTTel51g0HAAzV4wTu4KqeqLywEWb541HdxY38845jUGjUrRebML8b 3ys41+TiYnH3qOwGZoXXjis0s3pGLGAmO9CHTpzwhubosWAgyjShgsG/0Ihwez7L d9mrOEkGJZyTeGU1972Elp7td6p/jQREiiLQEgFC0qDBjoTxl+IBAMJaABWWFqQG 0scUwsnlDyGbyOO1A+T5a0fP66BZdnZHst17KoZGXWMxO+K3TPdkZQZO2JM0LoW2 vxZn6Uas/M4PfbrzXv03H/Vq2EPTPf9A6YwjA9Re37zZ1nUN21/0Bbfndqf4ruu1 gIGDnVR5/DHvUCgCTtBub+kJfXFylK9rKRcEpGSorFMlKprMh+weaBfyPxE0nsQ6 fhjU7Gz1ReYV3/RJMMJK =vNKF -----END PGP SIGNATURE----- --sisfJ60kqelviW65RSDMvxxBej1SqkNxN-- From owner-freebsd-stable@FreeBSD.ORG Mon Oct 20 14:39:17 2014 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 943EA80 for ; Mon, 20 Oct 2014 14:39:17 +0000 (UTC) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (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 53D551E9 for ; Mon, 20 Oct 2014 14:39:17 +0000 (UTC) Received: from 2a02-8428-011b-e000-0290-f5ff-fe9d-b78c.rev.sfr.net ([2a02:8428:11b:e000:290:f5ff:fe9d:b78c] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XgE79-0009pA-Hu for freebsd-stable@freebsd.org; Mon, 20 Oct 2014 16:39:15 +0200 Message-ID: <54451E92.709@dumbbell.fr> Date: Mon, 20 Oct 2014 16:39:14 +0200 From: =?windows-1252?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: vt(4) "newcons" and 80x25 vty? (tested: 10.1-BETA2) References: <4490c8c4d489370c7617c0ace9e773be.squirrel@s4bysmmsnraf7eut.onion> <3d80542ccc73686094ddde4e18465e4a.squirrel@s4bysmmsnraf7eut.onion> <2ac3ccbb9ede61a99b0306107ad3846b.squirrel@s4bysmmsnraf7eut.onion> <544404EE.6070609@FreeBSD.org> In-Reply-To: <544404EE.6070609@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wFi87sILkIQSx5nJXs94mwBVGRMtXsTf6" 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, 20 Oct 2014 14:39:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wFi87sILkIQSx5nJXs94mwBVGRMtXsTf6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 19.10.2014 20:37, Jean-S=E9bastien P=E9dron wrote: >> * VT in VGA textmode fonts loading broken (tested 10.1-BETA2). Tried >> vidfont(1) and also vidcontrol -f [size] [filename]. For loading "VGA= " >> fonts, screen weird/unusable (see below). For loading Gallant (12x22)= , >> the virtual terminal freeze (both other vty still ok). >=20 > Still correct: there's a bug here. In VGA text mode, loading a font > should be rejected. The purpose of text mode is to let the video card > draw the text itself. This is fixed in HEAD: loading a font in textmode is rejected. --=20 Jean-S=E9bastien P=E9dron --wFi87sILkIQSx5nJXs94mwBVGRMtXsTf6 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 iQJ8BAEBCgBmBQJURR6SXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTMzlQQALtiktdp0TxzR+zs/cAb/5lB nxw154JXA5TCcBluYxmreeNSc5QER3M/tywQvL4hJYgdvWeXAP9YtxD77nea1N9O 0tn7tXrLPaTNhewU0R1Qq0+iwOocL3yAQhYAWCIWAQa6WqzK9Ef2EnKECYDOKWr3 iAqb2GVeyXBBFNzNjZkVuIOnjfKtYyv2kjdE6XcatP6OjFIXF9PdI22NNRjUZeEW 0A30/QA6HA0EDDZpsvJvIBAyFQwfTCTA5DiPD69HMcs86KAkzlPkaRVGaC+GwsHa 2ep2C9EO35WV2XkCY76qjmRRuLU/H9UmdBATeEALmHg3H8pKOdC6cvW2OCeSj93J YNteIrPlJqHk9Qg+MSMtYVP6tJipKDC7J7F2hi+LBKKZXlS4kOnaEga/OnzO1Svl td1A/7bUlQIiEHYmyMPAC5stLru2f53kw4U5UbsawUAM79rZCp1QS8JtQQNZFEF0 hONektICpQq00nFwmv2xSlG4Lkpq+TtQ7Z42km6oCeC9kpFXloOeVioO9GjUuYSO nLXi4NQS7BzfljDTEmkmM1G6+M4EWEI/WPlL0POyRWptWzAwE3AOtAc3emk7ZY3p 4tvj5qsuB8hmZk8YkGzmkg3KxrjhoRMgCnrIjT50UNzfTyah84bZ7zhms2E8JeAI Oc6s2c6khLplJjtUpaJK =vfEv -----END PGP SIGNATURE----- --wFi87sILkIQSx5nJXs94mwBVGRMtXsTf6-- From owner-freebsd-stable@FreeBSD.ORG Mon Oct 20 14:42:56 2014 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 5321A338 for ; Mon, 20 Oct 2014 14:42:56 +0000 (UTC) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (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 1539B2FE for ; Mon, 20 Oct 2014 14:42:56 +0000 (UTC) Received: from 2a02-8428-011b-e000-0290-f5ff-fe9d-b78c.rev.sfr.net ([2a02:8428:11b:e000:290:f5ff:fe9d:b78c] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XgEAg-0009rX-Be for freebsd-stable@freebsd.org; Mon, 20 Oct 2014 16:42:54 +0200 Message-ID: <54451F6D.9040600@dumbbell.fr> Date: Mon, 20 Oct 2014 16:42:53 +0200 From: =?windows-1252?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: vt(4) "newcons" and 80x25 vty? (tested: 10.1-BETA2) References: <20141020143213.GS817@lena.kiev> In-Reply-To: <20141020143213.GS817@lena.kiev> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bwavruLR5ALqK5qwAsAALvvTwD8EEpn83" 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, 20 Oct 2014 14:42:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bwavruLR5ALqK5qwAsAALvvTwD8EEpn83 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 20.10.2014 16:32, Lena@lena.kiev.ua wrote: > With sc(4), font is loaded into the video card. > In rc.conf: Unfortunately, this is not implemented in vt(4) yet. > Please don't force people to change locale to Unicode > in case of motherboard replacement to Intel video. What makes you prefer a non-Unicode locale? --=20 Jean-S=E9bastien P=E9dron --bwavruLR5ALqK5qwAsAALvvTwD8EEpn83 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 iQJ8BAEBCgBmBQJURR9uXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTMyn0QANF0qrtCzQxdSF4yqiwlQnrb AMEOpvEhslS8DqjmAW8kZl/bpc6g4Yi+KAOF+ZdJ7CmNlgklDfmtqHdTg0aZAw9x l3x0XlOx+BtK1PODjUooSAs3/GREvou3Y1kb0o8lG0xDJA06sVHjR6oLnzfJQpR8 Ffc4ABNuMyJcWqHBx2hztohi+S54O+Ar0W24ZtmcQ0jFDR2x8c0jnmBNRA4t0f+A 22orF9L0v5dAGsgoBuH7zalDfesDqwZl0Wk/kwoUpOJW6yS9Ji1xKEQfQNyFKSIY 2EgLX57uzdx9O26fWROkX/aq6+pQW0HrN3jBhT3ob9gA1UcTqsk6YvyjgftFaNj8 zW/zsI+2a6w6S0bhB2jiKxuDs2LhgllEEXgEDN25KyoJexR+9sNBxG5FZuzcUeHn 7KoCurp5AXVHqvUNvFYT3bgoZYqXqUtOVYUYoLTrnlbv2ELW8x9mXnc/guBNGr5F fxoTeNV16R1WBZnZzLOnoWU4DFrHALvju1hrvUu5BKwsbN2XCaE+kziQ/4/7VnIZ p1OJLpFzOJq8QirgNqHr9CpiolAlv0qLWqTXvTWAswfkySPuwDyV9tbRfFVwDkkQ xtX/7avg6a0pWFkZA/EoQPqRYcRGMCZ6PtkS6sP643S0YYU3bpNsnZypPgh+TCkv 9s5O23jYOHhXirMdnnkW =ng5p -----END PGP SIGNATURE----- --bwavruLR5ALqK5qwAsAALvvTwD8EEpn83-- From owner-freebsd-stable@FreeBSD.ORG Mon Oct 20 14:59:48 2014 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 E8FE0929 for ; Mon, 20 Oct 2014 14:59:48 +0000 (UTC) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B7A396E3 for ; Mon, 20 Oct 2014 14:59:48 +0000 (UTC) Received: by mail-ig0-f181.google.com with SMTP id r10so4727962igi.8 for ; Mon, 20 Oct 2014 07:59:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=VJ0KAdL91nuXup7IQUveuXfi8eM9/7ItDlT+9RljkT0=; b=vWvJ1gxIepP9jc3F6lWxCT/mijrylgeGGNz76EYNqVJk2tNkVc3JFqX1Tz8H9wwuO/ j3DqRFVQxQBlhVFsSdd1OBsnL1BoIiQrD48ZLlM7DPsjd7LbXfM+mkOPZ8O0OjPv8QVl RCa/RzzgDi0WnrQUvUcI2iM/gosDsnxWiGruGRjH8RtwkjjpzYB1I9mttN3YcB0id/c/ 8+4ayZ/OSkUh4XdYYENJtxPePjUVCk7KlDR/7gvkKFaAl/IBr2tGpnkq21lXTm6isnkf updXSQdhrhAgfemgpWXjw9HszG2iv/x5H0McM1CEqStwPXQ6txpy/T6jk0kOIoOgVQCv G4vQ== X-Received: by 10.107.40.136 with SMTP id o130mr29575806ioo.26.1413817188128; Mon, 20 Oct 2014 07:59:48 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.29.132 with HTTP; Mon, 20 Oct 2014 07:59:27 -0700 (PDT) In-Reply-To: <3d80542ccc73686094ddde4e18465e4a.squirrel@s4bysmmsnraf7eut.onion> References: <4490c8c4d489370c7617c0ace9e773be.squirrel@s4bysmmsnraf7eut.onion> <3d80542ccc73686094ddde4e18465e4a.squirrel@s4bysmmsnraf7eut.onion> From: Ed Maste Date: Mon, 20 Oct 2014 10:59:27 -0400 X-Google-Sender-Auth: e89rQrHLj-6AzJQCEfdiS_JD6sE Message-ID: Subject: Re: vt(4) "newcons" and 80x25 vty? (tested: 10.1-BETA2) To: beeessdee@ruggedinbox.com Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable 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: Mon, 20 Oct 2014 14:59:49 -0000 On 25 September 2014 18:51, wrote: > > For longer term, when there is time, I like to hack on font system for > other goals in my previous mail: Smooth fonts sized right at native/max > resolution provided with new(ish) kms driver stack. What a waste to stick > to vgamode. Any pointers toward where I should start? Documentation is > scarcer than the usual FreeBSD (not a criticism - it is new subsystem!). In fact, good documentation is even more important for new subsystems. Anyhow, as a result of your comment I noticed that a vtfontcvt(8) cross-reference was missing from vt(4); it's now added to HEAD in r273332. I've also put a quick example in the wiki (https://wiki.freebsd.org/Newcons) of using vtfontcvt(8) to create a larger console font, and include it here for feedback: 1. Fetch the Terminus font distribution and unpack it. It's available from http://sourceforge.net/projects/terminus-font/files/latest/download?source=files 2. Convert the 16x32 bitmap .bdf files to a vt(4) .fnt file: % vtfontcvt -w 16 -h 32 ter-u32n.bdf ter-u32b.bdf ter-u32.fnt 3. Load it from a console window to test: % vidcontrol -f ter-u32.fnt On my 1920x1200 LCD this font gives me a 120x37 terminal. A variant of Terminus is used as the default vt(4) console font, but only the 8x16 size is available to us under a BSD license. A future task is to integrate this with the terminus-font port, so that installing the port or package is sufficient to make the full set of sizes available to vt(4). -Ed From owner-freebsd-stable@FreeBSD.ORG Mon Oct 20 20:23:06 2014 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 34602ECF for ; Mon, 20 Oct 2014 20:23:06 +0000 (UTC) Received: from mail.oitsec.umn.edu (mail.oitsec.umn.edu [128.101.238.120]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.oitsec.umn.edu", Issuer "InCommon Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0E2D73E4 for ; Mon, 20 Oct 2014 20:23:05 +0000 (UTC) Received: from mail.oitsec.umn.edu (localhost [127.0.0.1]) by mail.oitsec.umn.edu (Postfix) with ESMTP id 02DFD5C80C for ; Mon, 20 Oct 2014 15:20:07 -0500 (CDT) X-Virus-Scanned: amavisd-new at oitsec.umn.edu Received: from mail.oitsec.umn.edu ([127.0.0.1]) by mail.oitsec.umn.edu (mail.oitsec.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTMjf8Trfxhj for ; Mon, 20 Oct 2014 15:20:06 -0500 (CDT) Received: from optimator.oitsec.umn.edu (optimator.oitsec.umn.edu [134.84.23.1]) (Authenticated sender: amesbury) by mail.oitsec.umn.edu (Postfix) with ESMTPSA id 76D225C824 for ; Mon, 20 Oct 2014 15:20:06 -0500 (CDT) From: Alan Amesbury Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Problem with libfetch, pkg, and proxying? Message-Id: <42CAA1B4-1DE8-4CA6-85A4-29773844B0E2@oitsec.umn.edu> Date: Mon, 20 Oct 2014 15:20:06 -0500 To: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.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, 20 Oct 2014 20:23:06 -0000 Given FreeBSD-9.1-RELEASE, 'pkg' installed from ports, and a pkg.conf = that points to a proxy, it appears 'pkg' is ignoring the proxy setting = for HTTPS URLs. The contents of /usr/local/etc/pkg.conf consists of: pkg_env { http_proxy: http://proxyhost.fqdn:3128/ } 'uname -srm' =3D "FreeBSD 9.1-RELEASE-p19 amd64". It's not running = GENERIC, but I don't think that's relevant. :-) Network traffic shows the host uses the proxy correctly for the initial = HTTP callout to the local package repository, but tries to connect = directly when it receives an HTTP redirect to HTTPS. This is borne out = in output from 'truss', which shows (with some data redacted): . . . 72869: connect(5,{ AF_INET [NAMESERVER]:53 },16) =3D 0 (0x0) 72869: sendto(5,"\M-)W\^A\0\0\^A\0\0\0\0\0\0\apro"...,44,0x0,NULL,0x0) =3D= 44 (0x2c) 72869: clock_gettime(0,{1413835372.386244672 }) =3D 0 (0x0) 72869: = kevent(4,{0x5,EVFILT_READ,EV_ADD|EV_ONESHOT,0,0x0,0x0},1,{0x5,EVFILT_READ,= EV_ONESHOT,0,0xcb,0x0},1,{5.000000000 }) =3D 1 (0x1) 72869: recvfrom(5,"\M-)W\M^A\M^@\0\^A\0\^A\0\^B\0"...,65536,0x0,{ = AF_INET 128.101.101.101:53 },0x7fffffff77dc) =3D 203 (0xcb) 72869: close(5) =3D 0 (0x0) 72869: close(4) =3D 0 (0x0) 72869: = kqueue(0x7e6bfa380,0x7e7496000,0x10000058,0x7e7486000,0x10000,0x1) =3D 4 = (0x4) 72869: socket(PF_INET,SOCK_DGRAM,0) =3D 5 (0x5) 72869: connect(5,{ AF_INET [NAMESERVER]:53 },16) =3D 0 (0x0) 72869: sendto(5,"\M-)X\^A\0\0\^A\0\0\0\0\0\0\apro"...,44,0x0,NULL,0x0) =3D= 44 (0x2c) 72869: clock_gettime(0,{1413835372.388397497 }) =3D 0 (0x0) 72869: = kevent(4,{0x5,EVFILT_READ,EV_ADD|EV_ONESHOT,0,0x0,0x0},1,{0x5,EVFILT_READ,= EV_ONESHOT,0,0x69,0x0},1,{5.000000000 }) =3D 1 (0x1) 72869: recvfrom(5,"\M-)X\M^A\M^@\0\^A\0\0\0\^A\0\0"...,65536,0x0,{ = AF_INET 128.101.101.101:53 },0x7fffffff77dc) =3D 105 (0x69) 72869: close(5) =3D 0 (0x0) 72869: close(4) =3D 0 (0x0) 72869: madvise(0x7e7496000,0x10000,0x5,0x95,0x7fffffff7830,0x62c1b0) =3D = 0 (0x0) 72869: madvise(0x7e7476000,0x10000,0x5,0x75,0x7fffffff7d10,0xffffffff) =3D= 0 (0x0) 72869: madvise(0x7e7486000,0x10000,0x5,0x85,0x7fffffff7d10,0x62c1b0) =3D = 0 (0x0) 72869: socket(PF_INET,SOCK_STREAM,6) =3D 4 (0x4) 72869: connect(4,{ AF_INET [PROXY]:3128 },16) =3D 0 (0x0) 72869: fcntl(4,F_SETFL,O_NONBLOCK) =3D 0 (0x0) 72869: fcntl(4,F_SETFD,FD_CLOEXEC) =3D 0 (0x0) 72869: setsockopt(0x4,0xffff,0x800,0x7fffffff9144,0x4,0x0) =3D 0 (0x0) 72869: setsockopt(0x4,0x6,0x4,0x7fffffff9458,0x4,0x0) =3D 0 (0x0) . . . 72869: connect(5,{ AF_INET [NAMESERVER]:53 },16) =3D 0 (0x0) 72869: sendto(5,"\M-)Y\^A\0\0\^A\0\0\0\0\0\0\thor"...,42,0x0,NULL,0x0) =3D= 42 (0x2a) 72869: clock_gettime(0,{1413835372.458693385 }) =3D 0 (0x0) 72869: = kevent(4,{0x5,EVFILT_READ,EV_ADD|EV_ONESHOT,0,0x0,0x0},1,{0x5,EVFILT_READ,= EV_ONESHOT,0,0xc9,0x0},1,{5.000000000 }) =3D 1 (0x1) 72869: recvfrom(5,"\M-)Y\M^A\M^@\0\^A\0\^A\0\^B\0"...,65536,0x0,{ = AF_INET 128.101.101.101:53 },0x7fffffff77dc) =3D 201 (0xc9) 72869: close(5) =3D 0 (0x0) 72869: close(4) =3D 0 (0x0) 72869: = kqueue(0x7e6bfa380,0x7e7496000,0x10000058,0x7e7486000,0x10000,0x1) =3D 4 = (0x4) 72869: socket(PF_INET,SOCK_DGRAM,0) =3D 5 (0x5) 72869: connect(5,{ AF_INET [NAMESERVER]:53 },16) =3D 0 (0x0) 72869: sendto(5,"\M-)Z\^A\0\0\^A\0\0\0\0\0\0\thor"...,42,0x0,NULL,0x0) =3D= 42 (0x2a) 72869: clock_gettime(0,{1413835372.461001593 }) =3D 0 (0x0) 72869: = kevent(4,{0x5,EVFILT_READ,EV_ADD|EV_ONESHOT,0,0x0,0x0},1,{0x5,EVFILT_READ,= EV_ONESHOT,0,0x67,0x0},1,{5.000000000 }) =3D 1 (0x1) 72869: recvfrom(5,"\M-)Z\M^A\M^@\0\^A\0\0\0\^A\0\0"...,65536,0x0,{ = AF_INET 128.101.101.101:53 },0x7fffffff77dc) =3D 103 (0x67) 72869: close(5) =3D 0 (0x0) 72869: close(4) =3D 0 (0x0) 72869: madvise(0x7e7496000,0x10000,0x5,0x95,0x7fffffff7830,0x62c1b0) =3D = 0 (0x0) 72869: madvise(0x7e7476000,0x10000,0x5,0x75,0x7fffffff7d10,0xffffffff) =3D= 0 (0x0) 72869: madvise(0x7e7486000,0x10000,0x5,0x85,0x7fffffff7d10,0x62c1b0) =3D = 0 (0x0) 72869: socket(PF_INET,SOCK_STREAM,6) =3D 4 (0x4) 72869: connect(4,{ AF_INET [NOT_PROXY]:443 },16) ERR#60 'Operation timed = out' . . . The connection timed out because connections to hosts other than the = proxy aren't allowed. However, my reading of fetch(3) and fetch(1) = suggests that the environment variable for http_proxy should cover HTTP = and HTTPS URLs. Tests using lynx were different; lynx apparently uses = ${PROTOCOL}_PROXY where ${PROTOCOL} is the URL type, and HTTP and HTTPS = are different. Is this behavior correct? I don't think it is. Regardless, is there a = way to get 'pkg' to use HTTPS URLs through a proxy? Thanks in advance for any help/insights you can provide! --=20 Alan Amesbury University Information Security= From owner-freebsd-stable@FreeBSD.ORG Tue Oct 21 01:20:47 2014 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 465A6C78 for ; Tue, 21 Oct 2014 01:20:47 +0000 (UTC) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 16322832 for ; Tue, 21 Oct 2014 01:20:47 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id rl12so201414iec.31 for ; Mon, 20 Oct 2014 18:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=s0XDczpmFS0n35M3PkciwSDiMsbUE9Hkh1XvLxBqn0c=; b=VU11KmkVXtxMWub9mNHXfOi/0hpT2ZOi8JGNoxnLJl8CptZNLJm3n1+1p1HD/oYunE qX76ZNO9WzYtkGdRVfuBKFbemM9hTPfC5PdhljCoiRs6NHkHDz2H+3MESBOSWaoPa/Tx P8grw38A+pR54qyfPSI12wOlMgjxhpSQ66IC1Nat8fLiVls3onhx904vesWbW97uol1o a6HfNmOQZbr8DiVNb1tNjMEyVF75ToKQfTffR996qwkXQlPrxVBXPuxBmrH5kugaHIly m6bOfU8pr6n2Y95CTU7uF3Yqsx4/J3Cv+O/e53VO9zRao+O2gfrobpupyNThNPTsdQt4 SOxA== X-Received: by 10.107.158.80 with SMTP id h77mr33662303ioe.41.1413854446470; Mon, 20 Oct 2014 18:20:46 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.29.132 with HTTP; Mon, 20 Oct 2014 18:20:25 -0700 (PDT) In-Reply-To: <4490c8c4d489370c7617c0ace9e773be.squirrel@s4bysmmsnraf7eut.onion> References: <4490c8c4d489370c7617c0ace9e773be.squirrel@s4bysmmsnraf7eut.onion> From: Ed Maste Date: Mon, 20 Oct 2014 21:20:25 -0400 X-Google-Sender-Auth: 6cd4wdbNnn3ALN85xrbvUQFqCg8 Message-ID: Subject: Re: vt(4) "newcons" and 80x25 vty? (tested: 10.1-BETA2) To: beeessdee@ruggedinbox.com Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable 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: Tue, 21 Oct 2014 01:20:47 -0000 On 25 September 2014 11:31, wrote: > > A. How to force 80x25 terminal, even if it does not use > whole screen? This will be the quick workaround! There are no tunables or configuration options at the moment to limit the terminal size, but I agree this would be a sensible addition to accomplish what you're looking for, especially in combination with a larger font. > B. Where are sources for Gallant? What program is used to > create it? A brief web search did not reveal this. We had a copy in FreeBSD, in sys/dev/fb/gallant12x22.c, which was obtained from NetBSD. http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/wsfont/gallant12x22.h?only_with_tag=MAIN To me it doesn't seem like a that great of a console font, but is notable for being (a) relatively large and (b) BSD licensed. > C. Any work in font besides Gallant? (Sorry, it is matter > of taste!) I would try make my own, but I am not font > talent. > > D. Any suggestions from font guys of non-Xorg program to > rasterize OpenType fonts, make Metafont rasters into > the appropriate format, etc.? As mentioned in my other recent email, vtfontcvt(8) can convert BDF format bitmap fonts for use by vt(4), and there are many to choose from. I'm happy to take a look at importing into the base system a larger font with a suitable license, if one is found. > E. Side question: Is vgl(3) being supported or replaced with > vt(4) newcons? (Have not tested; but at the brief look, it > all ioctls changed around.) Not yet. > F. How to set screen resolution, with not working vidcontrol(1)? Right now the resolution is set by the driver to match the attached display, or a fixed 640x480 for VGA, and there's no knob to change it. From owner-freebsd-stable@FreeBSD.ORG Tue Oct 21 02:32:41 2014 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 325CAA79 for ; Tue, 21 Oct 2014 02:32:41 +0000 (UTC) Received: from isis.morrow.me.uk (isis.morrow.me.uk [204.109.63.142]) by mx1.freebsd.org (Postfix) with ESMTP id 0AD89E62 for ; Tue, 21 Oct 2014 02:32:40 +0000 (UTC) Received: from anubis.morrow.me.uk (unknown [93.89.81.46]) (Authenticated sender: mauzo) by isis.morrow.me.uk (Postfix) with ESMTPSA id C61664508A; Tue, 21 Oct 2014 02:32:38 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 isis.morrow.me.uk C61664508A DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morrow.me.uk; s=dkim201101; t=1413858759; bh=rOIUocmsebBmtByKl94qacPCY6NxTUYUupa+GeijnB4=; h=Date:From:To:Subject:References:In-Reply-To; b=U5hfOv1uPGppY0HfZrK37zI6DiJKROymv/yVhwki23yQTVE4RO07INR5+xfIDXk5w sGlmwg3cwdSs0VjHjDiBs9yibnkzvS7+zWP0crH8aFM/kTJ7eRxxtqvji+GP6G247N TvkkfpGo5y0NGVxDw9DWsNMPeFLNimIhZP/5OjBY= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98.4 at isis.morrow.me.uk Received: by anubis.morrow.me.uk (Postfix, from userid 5001) id 3B7A8150A1; Tue, 21 Oct 2014 03:32:37 +0100 (BST) Date: Tue, 21 Oct 2014 03:32:37 +0100 From: Ben Morrow To: jean-sebastien.pedron@dumbbell.fr, freebsd-stable@freebsd.org Subject: Re: 10.1 kernel device config for drm2 and kms drivers Message-ID: <20141021023235.GA77122@anubis.morrow.me.uk> Mail-Followup-To: jean-sebastien.pedron@dumbbell.fr, freebsd-stable@freebsd.org References: <20140911064731.GA15930@rwpc15.gfn.riverwillow.net.au> <54115D2A.5020802@FreeBSD.org> <20140911084624.GK2737@kib.kiev.ua> <20140911211428.GA6247@anubis.morrow.me.uk> <20140913204209.GA18072@anubis.morrow.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <544405E8.9010503@dumbbell.fr> X-Newsgroups: gmane.os.freebsd.stable 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: Tue, 21 Oct 2014 02:32:41 -0000 Quoth =?windows-1252?Q?Jean-S=E9bastien_P=E9dron?= : > On 13.09.2014 22:42, Ben Morrow wrote: > > Previously, with syscons, I could usually scroll back after boot had > > finished and the login: prompt appeared and get all the way up to the > > start of the kernel messages (the Copyright line). > > > > Now, with vt, and loading radeonkms from rc.conf rather than > > loader.conf, if I switch to the console, I can: scroll up through 8 > > screens of kernel and userland console messages > > The history scrolling was rewritten in r271871 (HEAD) and r271973 > (10.1). I believe your problem is fixed by this change. > > Can you confirm if 10.1-RC* works for you in this regard? I'll check as soon as I can. Ben From owner-freebsd-stable@FreeBSD.ORG Tue Oct 21 10:43:15 2014 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 E8C59E1 for ; Tue, 21 Oct 2014 10:43:15 +0000 (UTC) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6D4898ED for ; Tue, 21 Oct 2014 10:43:15 +0000 (UTC) Received: by mail-lb0-f174.google.com with SMTP id p9so750406lbv.33 for ; Tue, 21 Oct 2014 03:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=6LyjgWbvM1UMgVIk9syaf8XAcVsIIcKLQtY95lbv3BM=; b=fBRue8qB+21l3IFkPZJZfPKPOmuGceHO8ZKR30LaH/gU/z8gII6pMaM9Dx/iP3y0vl 4bDGxqb2q5ekdid80HHwTnmpEB+gJn7zw0nU3HSzoJu1hBR4kb41NC5TDGTa3yTOPXJF nZY3H6LjmD40jMhjE46uGxkx8MWrC4lcqUmaV8BnZv/QkmMO8BifbEdasLrLruto8RVE qgHzbXHiZnxGvbk7D9SEY/75voglNa5e0xQ3Ax3I6iQor7rm+3C/eN2JgBd8lUzBTGId AJ5cVtgWuyWw/RPrPZDoLFfe9ftrt+cOpUmBjxOnqbHhsV4WMf8xmFJ2Vt/AU94YAObY gpYw== X-Received: by 10.112.198.73 with SMTP id ja9mr33239430lbc.19.1413888193142; Tue, 21 Oct 2014 03:43:13 -0700 (PDT) Received: from brick.home (adcz235.neoplus.adsl.tpnet.pl. [79.184.51.235]) by mx.google.com with ESMTPSA id n4sm4383533lah.2.2014.10.21.03.43.11 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Oct 2014 03:43:12 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Tue, 21 Oct 2014 12:43:08 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Harald Schmalzbauer Subject: Re: ctld(8), multiple 'portal-group' on same socket (individual 'discovery-auth-group' restrictions) Message-ID: <20141021104308.GA5990@brick.home> Mail-Followup-To: Harald Schmalzbauer , FreeBSD Stable References: <5444C94C.4050705@omnilan.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5444C94C.4050705@omnilan.de> User-Agent: Mutt/1.5.23 (2014-03-12) 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: Tue, 21 Oct 2014 10:43:16 -0000 On 1020T1035, Harald Schmalzbauer wrote: > Hello, > > I'm trying to move from istgt(1) to ctld(8), but it seems my setup isn't > possible with ctld. > Besides missing support for virtual-DVDs ('UnitType DVD' in istgt) and > real ODD-devices ('UnitType pass' in istgt), Yup, we don't implement virtual DVDs and passthrough. Especially the latter would be a nice feature to have. > I guess it's impossible to > define multiple "portal-group"s, listening on the same socket, but with > different "discovery-auth-group". > The idea is, to present initiators only targets at discovery, which they > are allowed to connect to. > Am I missing something which could provide such selective discovery with > ctld(8)? I thought about it, but I don't like the way istgt does it. By allowing multiple portal groups to bind to a single address (portal), we would introduce ambiguity as for which portal-group and associated discovery-auth-group is being used. On the other hand, a simplistic approach of only showing targets with auth-group being the same as discovery-auth-group for the portal probably wouldn't be very useful in real-world cases. From owner-freebsd-stable@FreeBSD.ORG Tue Oct 21 11:31:28 2014 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 67825721 for ; Tue, 21 Oct 2014 11:31:28 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E3861D25 for ; Tue, 21 Oct 2014 11:31:27 +0000 (UTC) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s9LBVOcJ053427 for ; Tue, 21 Oct 2014 13:31:24 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id D80C2341F; Tue, 21 Oct 2014 13:31:23 +0200 (CEST) Message-ID: <54464405.4090207@omnilan.de> Date: Tue, 21 Oct 2014 13:31:17 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: FreeBSD Stable Subject: Re: ctld(8), multiple 'portal-group' on same socket (individual 'discovery-auth-group' restrictions) References: <5444C94C.4050705@omnilan.de> <20141021104308.GA5990@brick.home> In-Reply-To: <20141021104308.GA5990@brick.home> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig42D225F1D00A3CAB209D0385" X-Greylist: ACL 119 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Tue, 21 Oct 2014 13:31:24 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) 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, 21 Oct 2014 11:31:28 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig42D225F1D00A3CAB209D0385 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bez=C3=BCglich Edward Tomasz Napiera=C5=82a's Nachricht vom 21.10.2014 1= 2:43 (localtime): > On 1020T1035, Harald Schmalzbauer wrote: >> Hello, >> >> I'm trying to move from istgt(1) to ctld(8), but it seems my setup isn= 't >> possible with ctld. >> Besides missing support for virtual-DVDs ('UnitType DVD' in istgt) and= >> real ODD-devices ('UnitType pass' in istgt), > Yup, we don't implement virtual DVDs and passthrough. Especially the > latter would be a nice feature to have. > >> I guess it's impossible to >> define multiple "portal-group"s, listening on the same socket, but wit= h >> different "discovery-auth-group". >> The idea is, to present initiators only targets at discovery, which th= ey >> are allowed to connect to. >> Am I missing something which could provide such selective discovery wi= th >> ctld(8)? > I thought about it, but I don't like the way istgt does it. By allowin= g > multiple portal groups to bind to a single address (portal), we would > introduce ambiguity as for which portal-group and associated > discovery-auth-group is being used. On the other hand, a simplistic > approach of only showing targets with auth-group being the same > as discovery-auth-group for the portal probably wouldn't be very useful= > in real-world cases. Thanks a lot for your attention and the highly appreciated work on ctl[d]= *! In my "real world" case, I dispense backup disks to win7 clients via iSCS= I. I liked the possibility to limit target-discovery-results, because curious people, garnated such extra resources, weren't able to see who else was granted this extra resource (by definition, there's no private data on the clients which use that backup-strategy, so no need for qualified identity checks or encryption needed). Even with any security mechanisms active, two consumers (some dozen in my case) of the same portal know about the other. That's one example where this feature was useful for me. Another one actually is (since not implemented in ctld, yet?) with virtual DVDs. If you provide 50 DVDs at one portal, it's confusing if any initiator needs to select from the complete list. I'd like to point to two options I'm missing: option RPM option FormFactor And another one I don't know/understand: option scsiname Missing resp. wrong reported option RPM leads to identification as SSD with ESXi initiators. I don't remember what defines a SSD vs. HDD, I think it was a threshold of something about 400? Or was it 0? I think I read the former=E2=80=A6 Don't have docs handy. The FormFactor was more cosmetic, but in bigger environments I guess it can be useful if you have multiple targets available, choosing the better fitting backend-pool e.g. If someone could point me to the meaning of option iscsiname? Thanks a lot, -Harry --------------enig42D225F1D00A3CAB209D0385 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlRGRAsACgkQLDqVQ9VXb8gzCQCfQNFezkkPkMaf5icVtm3VRWVg /xcAnA41TJ+dlGLCGkYivDWeGGhcTYSr =IYyz -----END PGP SIGNATURE----- --------------enig42D225F1D00A3CAB209D0385-- From owner-freebsd-stable@FreeBSD.ORG Tue Oct 21 12:59:30 2014 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 C28FBE2E for ; Tue, 21 Oct 2014 12:59:30 +0000 (UTC) Received: from lena.kiev.ua (lena.kiev.ua [82.146.51.205]) (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 87D41964 for ; Tue, 21 Oct 2014 12:59:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lena.kiev.ua; s=3; h=In-Reply-To:Content-Type:Mime-Version:References:Message-ID:Subject:To:From:Date; bh=ziDzxO15/ovyBdIagx7d3thzvnfXMWL1thMnz52RxHM=; b=QbZfEG7lbnii9rr1zdZVnpaQ8fvn2TQhChQMdgP4RgVT6KOMc36nXBpjJL2rw/BPaW5WVvcnjtMuJWmo9DfBtsEtvhKqi2pPd6VM8GC75pP1enJ7cJw/TYK9cDKMPFloWv/p+PZspW9VTf1NRUFLUxrQICJdwgKA6L38zGg3HLg=; Received: from ip-384c.rusanovka-net.kiev.ua ([94.244.56.76] helo=bedside.lena.kiev.ua) by lena.kiev.ua with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.83 (FreeBSD)) (envelope-from ) id 1XgZ28-000BZB-P1 for freebsd-stable@freebsd.org; Tue, 21 Oct 2014 15:59:29 +0300 Received: from bedside.lena.kiev.ua (localhost.lena.kiev.ua [127.0.0.1]) by bedside.lena.kiev.ua (8.14.9/8.14.9) with ESMTP id s9LCxMTd040346 for ; Tue, 21 Oct 2014 15:59:22 +0300 (EEST) (envelope-from Lena@lena.kiev.ua) X-Authentication-Warning: bedside.lena.kiev.ua: Host localhost.lena.kiev.ua [127.0.0.1] claimed to be bedside.lena.kiev.ua Received: (from lena@localhost) by bedside.lena.kiev.ua (8.14.9/8.14.9/Submit) id s9LCxMIF040345 for freebsd-stable@freebsd.org; Tue, 21 Oct 2014 15:59:22 +0300 (EEST) (envelope-from Lena@lena.kiev.ua) Date: Tue, 21 Oct 2014 15:59:22 +0300 From: Lena@lena.kiev.ua To: freebsd-stable@freebsd.org Subject: Re: vt(4) "newcons" and 80x25 vty? (tested: 10.1-BETA2) Message-ID: <20141021125922.GP815@lena.kiev> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54451F6D.9040600@dumbbell.fr> User-Agent: Mutt/1.4.2.3i 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, 21 Oct 2014 12:59:30 -0000 > From: Jean-S?bastien P?dron > > Please don't force people to change locale to Unicode > > in case of motherboard replacement to Intel video. > > What makes you prefer a non-Unicode locale? 1. I already have multiple files in non-Unicode locale in multiple directories in several machines (workstations and server), not easily distinguished from binary files. If I recode wrong files, they get corrupted. 2. The text editor I use (port editors/aee, wraps long lines on-screen instead of shifting the screen left-right) doesn't support Unicode. From owner-freebsd-stable@FreeBSD.ORG Tue Oct 21 13:45:24 2014 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 E9C7A7E4 for ; Tue, 21 Oct 2014 13:45:24 +0000 (UTC) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6CE8CE8F for ; Tue, 21 Oct 2014 13:45:24 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id z11so996438lbi.41 for ; Tue, 21 Oct 2014 06:45:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=xkkgjXzbIwnMug5gvsWEbyl3IuyOvnZqmRWkyJ6qpSA=; b=xA/ol/B5r0LOmNesgIY7bhdexvqBhc0ot8e7AB+92xoGk1dlMOObwQq+CJognAlRfz mUmE6lgo7fV3ctgISWO0hmBokSC2/kLniM/SSDOUetfEVt/qsKGRWpJKGRIYLXfIb7pI +uJajdniKV6+3vT6sHcyvIYSn+AXpiHomJOjJmEzuBjoC3TmMIyrtgaC+Q6buDRcSmhX rcx2e826awV/4cjUahF+xVmpHhNUqa+5nvygfMUIfidrbWlXSq0+1/qgnWyuvlQW9gSc 40fflzmJx8a9/RAZl0ZjSngODhkXpIcsdcaAFQN0Hux6TAyhb2cXwrIcAdHhozap891b VmBA== X-Received: by 10.152.204.76 with SMTP id kw12mr34150166lac.37.1413899121863; Tue, 21 Oct 2014 06:45:21 -0700 (PDT) Received: from brick.home ([79.184.115.52]) by mx.google.com with ESMTPSA id dq5sm4562948lbc.11.2014.10.21.06.45.20 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Oct 2014 06:45:20 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Tue, 21 Oct 2014 15:45:16 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Harald Schmalzbauer Subject: Re: ctld(8), multiple 'portal-group' on same socket (individual 'discovery-auth-group' restrictions) Message-ID: <20141021134516.GA89872@brick.home> Mail-Followup-To: Harald Schmalzbauer , FreeBSD Stable References: <5444C94C.4050705@omnilan.de> <20141021104308.GA5990@brick.home> <54464405.4090207@omnilan.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <54464405.4090207@omnilan.de> User-Agent: Mutt/1.5.23 (2014-03-12) 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: Tue, 21 Oct 2014 13:45:25 -0000 On 1021T1331, Harald Schmalzbauer wrote: > Bezüglich Edward Tomasz NapieraÅ‚a's Nachricht vom 21.10.2014 12:43 > (localtime): > > On 1020T1035, Harald Schmalzbauer wrote: > >> Hello, > >> > >> I'm trying to move from istgt(1) to ctld(8), but it seems my setup isn't > >> possible with ctld. > >> Besides missing support for virtual-DVDs ('UnitType DVD' in istgt) and > >> real ODD-devices ('UnitType pass' in istgt), > > Yup, we don't implement virtual DVDs and passthrough. Especially the > > latter would be a nice feature to have. > > > >> I guess it's impossible to > >> define multiple "portal-group"s, listening on the same socket, but with > >> different "discovery-auth-group". > >> The idea is, to present initiators only targets at discovery, which they > >> are allowed to connect to. > >> Am I missing something which could provide such selective discovery with > >> ctld(8)? > > I thought about it, but I don't like the way istgt does it. By allowing > > multiple portal groups to bind to a single address (portal), we would > > introduce ambiguity as for which portal-group and associated > > discovery-auth-group is being used. On the other hand, a simplistic > > approach of only showing targets with auth-group being the same > > as discovery-auth-group for the portal probably wouldn't be very useful > > in real-world cases. > > Thanks a lot for your attention and the highly appreciated work on ctl[d]*! Thanks :-) > In my "real world" case, I dispense backup disks to win7 clients via iSCSI. > I liked the possibility to limit target-discovery-results, because > curious people, garnated such extra resources, weren't able to see who > else was granted this extra resource (by definition, there's no private > data on the clients which use that backup-strategy, so no need for > qualified identity checks or encryption needed). Even with any security > mechanisms active, two consumers (some dozen in my case) of the same > portal know about the other. That's one example where this feature was > useful for me. So basically, each target has a different user/password pair, and during discovery the target only returns those targets that can actually be accessed using that user/password? > Another one actually is (since not implemented in ctld, yet?) with > virtual DVDs. If you provide 50 DVDs at one portal, it's confusing if > any initiator needs to select from the complete list. In this case do the returned targets depend on authentication, or something else, eg. a static list defined in config? > I'd like to point to two options I'm missing: > option RPM > option FormFactor > And another one I don't know/understand: > option scsiname > > Missing resp. wrong reported option RPM leads to identification as SSD > with ESXi initiators. I don't remember what defines a SSD vs. HDD, I > think it was a threshold of something about 400? Or was it 0? I think I > read the former… Don't have docs handy. > The FormFactor was more cosmetic, but in bigger environments I guess it > can be useful if you have multiple targets available, choosing the > better fitting backend-pool e.g. Hm, ok. > If someone could point me to the meaning of option iscsiname? That's an istgt option, right? From owner-freebsd-stable@FreeBSD.ORG Tue Oct 21 15:47:48 2014 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 2FE114F7 for ; Tue, 21 Oct 2014 15:47:48 +0000 (UTC) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (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 E6DAEE9E for ; Tue, 21 Oct 2014 15:47:47 +0000 (UTC) Received: from 2a02-8428-011b-e000-0290-f5ff-fe9d-b78c.rev.sfr.net ([2a02:8428:11b:e000:290:f5ff:fe9d:b78c] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1Xgbez-000ObO-St for freebsd-stable@freebsd.org; Tue, 21 Oct 2014 17:47:46 +0200 Message-ID: <5446801E.5000405@FreeBSD.org> Date: Tue, 21 Oct 2014 17:47:42 +0200 From: =?windows-1252?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: VT switch to console disabled once X starts References: <2553F6A9-0363-491B-9585-E12AD32CF0F6@alkumuna.eu> In-Reply-To: <2553F6A9-0363-491B-9585-E12AD32CF0F6@alkumuna.eu> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="t9ee6SS1WOVBcsXHHgPkibUHMn3EKuqsc" 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, 21 Oct 2014 15:47:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --t9ee6SS1WOVBcsXHHgPkibUHMn3EKuqsc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 14.10.2014 11:50, Matthieu Volat wrote: > Hello, Hi! > I've had this problem with a HP Z400 workstation which is currently=20 > running 10.1-RC2, but had it since I put FreeBSD 10 on it: using > either syscons or vt, I can see the console output when the system > boots. >=20 > But once the X server start (through xdm, using the nvidia driver),=20 > if I try to switch to another screen, I get only a black screen, but > I can get back to vt #9 and get my X session back. If I don't set xdm > in /etc/ttys, I can use the consoles... To be sure I understand, you have a non-working console if you start X with xdm from /etc/ttys. What about startx(1)? Do you have a working console in this case? And is this with vt(4) only? In other words, does it work as expected with syscons? --=20 Jean-S=E9bastien P=E9dron --t9ee6SS1WOVBcsXHHgPkibUHMn3EKuqsc 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 iQJ8BAEBCgBmBQJURoAhXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTMwb0P/iYpb+6Hlz6/RY2UVFORbDhs q7S1z02gEIi2P4ZcG1+8RihcwS6lGr7c6PpIMBcbfJq1Z0mlVRN+TMCNRyNMGglK k1R/bLEEnN25X7ov1l03QuOvgV4W9IRudSUX+YiIsKxdvW8FFUgGoIiyo05MCMjL DVyrYioFRIw7xarbwSPwJP/pBmAL3tIzvfYfcCEIuVpXiJpyHDz8gkL6ZnPXH8Iw DX2RBbgm3E8PxIxfLCkYFbBbC7rlerXrJqfi7yIAcIM4xWt913lnOPdU1FQB6jo2 F5X+D9q/nQ+HyGBhFL0/mC/vLxwMiwW6OP2zU92LWHDQgY5uk3DWcn7KXrvnvzT9 OQAHDVderuUdCeLJsy/pJVLgaW02gXDUDW4qV5uNTrZbMQw0B0IgkBhT4NI/of1X j06svDuL6zgvMreatON2lspRahhigpXHN2ezmp2ROFYMEk8H/ue00GQQPNCLZhj9 vyheqKsk6vXcYIJckfCqv+sPF/FE/OBK3VDns9WWPvVm5HzzovnI59aPRQyRj9pU exak7QhLSuy6cHLoh+D3LFFQkzrieTmuPsYvo4KffIIQeWqof54O0SiRzLgoLlj9 LxtvBYZcFqBLBDo9zFygfdmHhj6pEpRd3QLWeXFQ0Saqe1a/nBb9MTzyX7oiliqO ZJ3Uq+jR62nfl6lYXKhQ =qgi+ -----END PGP SIGNATURE----- --t9ee6SS1WOVBcsXHHgPkibUHMn3EKuqsc-- From owner-freebsd-stable@FreeBSD.ORG Tue Oct 21 16:29:38 2014 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 38921F8C for ; Tue, 21 Oct 2014 16:29:38 +0000 (UTC) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (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 EAEC6387 for ; Tue, 21 Oct 2014 16:29:37 +0000 (UTC) Received: from 2a02-8428-011b-e000-0290-f5ff-fe9d-b78c.rev.sfr.net ([2a02:8428:11b:e000:290:f5ff:fe9d:b78c] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XgcJT-000P6k-Tf for freebsd-stable@freebsd.org; Tue, 21 Oct 2014 18:29:36 +0200 Message-ID: <544689EB.3020303@dumbbell.fr> Date: Tue, 21 Oct 2014 18:29:31 +0200 From: =?windows-1252?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG) [NVIDIA vs. powerpc64 for vt console switching; Radeon X1950 not working for powerpc64 Xorg generally] References: <2C74DFEC-D943-4237-8988-B9657240EC21@dsl-only.net> <82C08920-CF4B-441F-8162-9F6D2625E927@dsl-only.net> <8BAFEFD4-2FC3-4566-9CCE-F039594BDE7F@dsl-only.net> <83AFBF78-CBE1-4651-B3D6-A83168956D93@dsl-only.net> In-Reply-To: <83AFBF78-CBE1-4651-B3D6-A83168956D93@dsl-only.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="JM9aDsxtNfsM9j9AkngF2naK50TtAavws" 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, 21 Oct 2014 16:29:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JM9aDsxtNfsM9j9AkngF2naK50TtAavws Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 05.10.2014 15:41, Mark Millard wrote: >> Please do this for both vt(4) and syscons. Then post both truss-vt.txt= >> and truss-sc.txt files to this list. This will help us to determine if= >> vt(4) lacks an ioctl, compared to syscons. >=20 > Each file is rather large. So here is an extraction that will=20 > hopefully have enough context around each ioctl but that is vastly=20 > smaller. (There are initial-replies to other request after this=20 > extraction from the two files.) Hi! Sorry for the long delay to answer. Thank to your log files, we can see that vt(4) is missing ioctls compared to syscons, but I don't know yet their purpose. This may explain the difference of behavior and is something I must study. >> Could you please post pictures of this screen with both -BETA2 and >> -BETA3? I'd like to understand this regression on your side. >=20 > For -BETA3 (and probably now -RC1?) I greatly doubt that I can get a=20 > useful screen picture for the vt with 2560x1440 on Radeon x1950 > issue. The -BETA3 2560x1440 boot-display seems to be text a couple of > pixels high/wide per character and fairly dark. (Presumes that the > pattern is from tiny text since it is too small to read.) The same > display pattern seems to repeat several times across the display. Hmmm, unfortunately, I don't know how to help on this, I don't know how PowerPC works and I don't have the hardware to test... I hope someone with the knowledge will shine in :) > Let me know if I should re-establish a -BETA2 No need, I understand what you describe. But as the issue is different, let's concentrate on the other problems first and see if this one comes back at some point. > Of the kms-drm-update-38 request... >=20 >> If you have some time, could you please test my "kms-drm-update-38", >> available on GitHut? >> https://github.com/dumbbell/freebsd/tree/kms-drm-update-38 >=20 > I probably will experiment with this at some point but it may take a=20 > while to get there. Cool, that would be nice! Thank you! --=20 Jean-S=E9bastien P=E9dron --JM9aDsxtNfsM9j9AkngF2naK50TtAavws 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 iQJ8BAEBCgBmBQJURonvXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTMbwcP/0STEh8y1B60oz4lQbTy4ZVw 7H82RhN9TgMKVd3CjI9LuR/c3weICYJnKdacKwu0pelGwdlAV+mY1mJvMQeErg8L IuDl4c/MP4kfyztk+TcjCjl8dx9bFxfr2Cx1nHSpSZ4VoPJB+7X5tRhFjAWBcAse V0Ukc+CSGDr/mIDDgCV4tixvlssNXXXvQzM4bYi2yS1bwFxHxpv+S4Goa3mpbU6a JhWblDigIQk/3oTMw+QMlEueHDemFlWPdv6tsVOsQOiHFSW0wLXW+T/BFMdApJD4 5a/CXpCx0SoY0lJAJVdyH09EthXQszQSSTPQXBr1vy3Nm+hcB6CmcXQPjVgmzMWA EdlKeCj81WOzDac2u3w6vekw1nFj45l85IaC7yznjMb5z1Lh4JTjVvy9vqOeYcat GsjPtUpl4EvBQgqT0x6Mo3Rx2WkaWCo55KkULRg7+Fmqyh8uirbxDt143wpkHjE1 bxTcgV33KOJ7BUT1BvypScIPLtWrkAqkwA4bwELgSBoiDNz6doxd0FOMlDzBk/8F svRh6thxk4w37ORQwY5ldyrZmqsv2faOEf++CQslWwrpNrTB0rEYCBNdMy99Klo5 0I+xMyFP7DaNN7Qzrab2UW9pyKhTxjA+wZ971D0n8b0K254gifeM9UbxnKxR6Cgr 7MtNQsXykELSxuJ2FN3h =nynB -----END PGP SIGNATURE----- --JM9aDsxtNfsM9j9AkngF2naK50TtAavws-- From owner-freebsd-stable@FreeBSD.ORG Tue Oct 21 17:32:14 2014 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 8B44A1F8 for ; Tue, 21 Oct 2014 17:32:14 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 162BBCBD for ; Tue, 21 Oct 2014 17:32:13 +0000 (UTC) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s9LHWBSA057616 for ; Tue, 21 Oct 2014 19:32:11 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 77A3034FC; Tue, 21 Oct 2014 19:32:10 +0200 (CEST) Message-ID: <5446988B.5020509@omnilan.de> Date: Tue, 21 Oct 2014 19:31:55 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: FreeBSD Stable Subject: Re: ctld(8), multiple 'portal-group' on same socket (individual 'discovery-auth-group' restrictions) References: <5444C94C.4050705@omnilan.de> <20141021104308.GA5990@brick.home> <54464405.4090207@omnilan.de> <20141021134516.GA89872@brick.home> In-Reply-To: <20141021134516.GA89872@brick.home> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig49C07E4D95F90B2884A93F58" X-Greylist: ACL 119 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Tue, 21 Oct 2014 19:32:11 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) 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, 21 Oct 2014 17:32:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig49C07E4D95F90B2884A93F58 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bez=C3=BCglich Edward Tomasz Napiera=C5=82a's Nachricht vom 21.10.2014 1= 5:45 (localtime): =E2=80=A6 >> In my "real world" case, I dispense backup disks to win7 clients via i= SCSI. >> I liked the possibility to limit target-discovery-results, because >> curious people, garnated such extra resources, weren't able to see who= >> else was granted this extra resource (by definition, there's no privat= e >> data on the clients which use that backup-strategy, so no need for >> qualified identity checks or encryption needed). Even with any securit= y >> mechanisms active, two consumers (some dozen in my case) of the same >> portal know about the other. That's one example where this feature was= >> useful for me. > So basically, each target has a different user/password pair, and > during discovery the target only returns those targets that can actuall= y > be accessed using that user/password? In general, yes, that's what I did with istgt. But I omitted chap authentication, intead I'm just checking initiator-name/adress. So speaking in ctl.conf, I would love to see an extension in the target Context, which influences discovering results, maybe like target iqn.2012-06.com.example:target0 { SendTarget on-discover | access-granted # access-granted only has effect on assigned portal-group(s), which have 'target-filter' enabled. =E2=80=A6 } I guess that would need quiet a lot of extra checks added to existing discovery-response functions, so maybe it would make sense to selectively enable/disbale this extra check at portal-group Context in the first place, maybe like portal-group lan0 { target-filter on | off =E2=80=A6 } I just had a look at rfc3721, to find a suitable name for the 'SendTarget' config option I suggested here (http://www.ietf.org/rfc/rfc3721.txt, Page 12, 3.b). Quote of the first sentence in chapter 3, describing the iSCSI discovery:= =C2=BBThe goal of iSCSI discovery is to allow an initiator to find th= e targets to which it has access, =E2=80=A6=C2=AB =E2=80=9C=E2=80=A6 to which it has access=E2=80=9D sounds to me like the = filtered SendTarget behaviuor should be default, but I haven't read the complete docuemtn nor am I native english speaker... >> Another one actually is (since not implemented in ctld, yet?) with >> virtual DVDs. If you provide 50 DVDs at one portal, it's confusing if >> any initiator needs to select from the complete list. > In this case do the returned targets depend on authentication, or somet= hing > else, eg. a static list defined in config? The returned targets are still access restricted, by authentication or any initiator-match rule (name, address, both). >> I'd like to point to two options I'm missing: >> option RPM >> option FormFactor >> And another one I don't know/understand: >> option scsiname >> >> Missing resp. wrong reported option RPM leads to identification as SSD= >> with ESXi initiators. I don't remember what defines a SSD vs. HDD, I >> think it was a threshold of something about 400? Or was it 0? I think = I >> read the former=E2=80=A6 Don't have docs handy. >> The FormFactor was more cosmetic, but in bigger environments I guess i= t >> can be useful if you have multiple targets available, choosing the >> better fitting backend-pool e.g. > Hm, ok. Thanks for your attention again! >> If someone could point me to the meaning of option iscsiname? > That's an istgt option, right? Sorry, haven't made clear: ctl.conf(5) references ctladm(8) for possible "name value" pairs for the "option" option in the target Context. In ctladm's OPTIONS section, I can find most options I ever used (and in my case mandatory options like "product") besides to above mentioned two (RPM and FormFactor), and also some additional I haven't used. There's "scsiname" listed. I don't even understand the meaning of that :-= ( Hope you don't mind if I add another question: In ctl.conf(5), section "portal-group Context", under the description for 'discovery-auth-group', one can read: =C2=BBBy default, portal groups that do not specify their own auth settings, using clauses such as chap or initiator-name, are assigned predefined auth-group "default",=E2=80=A6=C2=AB I tried to define 'initiator-name' under portal-group Context, but that didn't work. I think I got an error message and config-reload was rejecte= d. The reason I tried to not use a predefined auth-froup was, that I get a warning it I define a auth-group and don't assign it to any target, instead using it as 'discovery-auth-group' only. Not really a problem, prpbably not even worth a PR/bugzilla report, but wanted to mention it here :-) And, not enough yet, I'd like to suggest a extension to the examples section of ctl.conf(5): --- /tmp/ctl.conf.sample.orig 2014-10-21 19:11:46.000000000 +0200 +++ /tmp/ctl.conf.sample 2014-10-21 19:25:28.000000000 +0200 @@ -1,5 +1,16 @@ pidfile /var/run/ctld.pid =20 + # buitlin special + #auth-group default { auth-type deny } + #auth-group no-authentication { auth-type none} + + auth-group example1 { + auth-type none + initiator-name "iqn.2012-06.com.example:initiatorhost1" + initiator-name "iqn.2012-06.com.example:initiatorhost2" + initiator-portal 192.0.2.0/24 + } + auth-group example2 { chap-mutual "user" "secret" "mutualuser" "mutualsecret" chap-mutual "user2" "secret2" "mutualuser" "mutualsecret" @@ -41,3 +52,13 @@ option foo bar } } + + target iqn.2012-06.com.example:target1 { + auth-type none + initiator-name "iqn.2012-06.com.example:initiatorhostname0" + initiator-portal [2001:DB8::de:ef] + portal-group example2 + lun 0 { + path /dev/zvol/example_1 + } + } --------------enig49C07E4D95F90B2884A93F58 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlRGmJkACgkQLDqVQ9VXb8jlowCgxDzQMaKILKhLugk7pMX/QKgS Cw4AoIoUu1cy0L5hN0yrVDwh1FZZ+N03 =p5qN -----END PGP SIGNATURE----- --------------enig49C07E4D95F90B2884A93F58-- From owner-freebsd-stable@FreeBSD.ORG Tue Oct 21 17:55:45 2014 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 DDC50697; Tue, 21 Oct 2014 17:55:45 +0000 (UTC) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) (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 9B325F0A; Tue, 21 Oct 2014 17:55:45 +0000 (UTC) Received: from yggdrasil.alkumuna.eu (unknown [IPv6:2a01:e35:8a74:6e70:232:36ff:fe5c:3a87]) by smtp3-g21.free.fr (Postfix) with ESMTP id 9E4C4A6326; Tue, 21 Oct 2014 19:54:09 +0200 (CEST) Received: from freedom ([192.168.10.100]) (authenticated bits=0) by yggdrasil.alkumuna.eu (8.14.7/8.14.7) with ESMTP id s9LHtYHT012043 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 21 Oct 2014 19:55:34 +0200 (CEST) (envelope-from mazhe@alkumuna.eu) Date: Tue, 21 Oct 2014 19:55:28 +0200 From: Matthieu Volat To: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= Subject: Re: VT switch to console disabled once X starts Message-ID: <20141021195528.1a1eac62@freedom> In-Reply-To: <5446801E.5000405@FreeBSD.org> References: <2553F6A9-0363-491B-9585-E12AD32CF0F6@alkumuna.eu> <5446801E.5000405@FreeBSD.org> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/3rUwhkpb.vCd1WVcx2+kE1o"; protocol="application/pgp-signature" 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: Tue, 21 Oct 2014 17:55:46 -0000 --Sig_/3rUwhkpb.vCd1WVcx2+kE1o Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, 21 Oct 2014 17:47:42 +0200 Jean-S=C3=A9bastien P=C3=A9dron wrote: > On 14.10.2014 11:50, Matthieu Volat wrote: > > Hello, >=20 > Hi! >=20 > > I've had this problem with a HP Z400 workstation which is currently=20 > > running 10.1-RC2, but had it since I put FreeBSD 10 on it: using > > either syscons or vt, I can see the console output when the system > > boots. > >=20 > > But once the X server start (through xdm, using the nvidia driver),=20 > > if I try to switch to another screen, I get only a black screen, but > > I can get back to vt #9 and get my X session back. If I don't set xdm > > in /etc/ttys, I can use the consoles... >=20 > To be sure I understand, you have a non-working console if you start X > with xdm from /etc/ttys. >=20 > What about startx(1)? Do you have a working console in this case? Console seems to be "disabled" when X is started, either with xdm or startx= (to xfce): I just switch to a black screen after that.=20 But it seems keyboard input is working: if I type stuff then enter, I'll se= e a login attempt in /var/log/message After that, if I switch to tty9, I'll get back to X. >=20 > And is this with vt(4) only? In other words, does it work as expected > with syscons? I have the problem with both syscons and vt (vga). >=20 > --=20 > Jean-S=C3=A9bastien P=C3=A9dron >=20 --=20 Matthieu Volat tel: 06 84 54 39 43 www: --Sig_/3rUwhkpb.vCd1WVcx2+kE1o Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRGnhYACgkQ+ENDeYKZi366/wCgrKJaL2cg1bDfgxiIObX3hF36 DeUAoLPB5NAJeoCmpfjw1bTTBWOaYjNZ =EJII -----END PGP SIGNATURE----- --Sig_/3rUwhkpb.vCd1WVcx2+kE1o-- From owner-freebsd-stable@FreeBSD.ORG Tue Oct 21 18:12:26 2014 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 5C06A6CF for ; Tue, 21 Oct 2014 18:12:26 +0000 (UTC) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (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 1DCA21CD for ; Tue, 21 Oct 2014 18:12:26 +0000 (UTC) Received: from 2a02-8428-011b-e000-0290-f5ff-fe9d-b78c.rev.sfr.net ([2a02:8428:11b:e000:290:f5ff:fe9d:b78c] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1Xgduy-0000IQ-CO for freebsd-stable@freebsd.org; Tue, 21 Oct 2014 20:12:24 +0200 Message-ID: <5446A203.9000703@FreeBSD.org> Date: Tue, 21 Oct 2014 20:12:19 +0200 From: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: VT switch to console disabled once X starts References: <2553F6A9-0363-491B-9585-E12AD32CF0F6@alkumuna.eu> <5446801E.5000405@FreeBSD.org> <20141021195528.1a1eac62@freedom> In-Reply-To: <20141021195528.1a1eac62@freedom> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="k5sLdJo5hAEnUIGq5DBquNDCm228nCLiO" 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, 21 Oct 2014 18:12:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --k5sLdJo5hAEnUIGq5DBquNDCm228nCLiO Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 21.10.2014 19:55, Matthieu Volat wrote: >> And is this with vt(4) only? In other words, does it work as expected >> with syscons? >=20 > I have the problem with both syscons and vt (vga). Hmmm, the behavior you describe happens with Intel or Radeon GPUs when using syscons only. But it's unexpected with the NVIDIA driver, no matter the console driver you use... I have no NVIDIA hardware at hand. Was the dmesg you posted taken before or after X was started? Your Xorg.log shows no error either. --=20 Jean-S=C3=A9bastien P=C3=A9dron --k5sLdJo5hAEnUIGq5DBquNDCm228nCLiO 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 iQJ8BAEBCgBmBQJURqIIXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTMLq8QAIIdT6uzgwHiy8vjEu9+vxrU ZaOJ31XeMiV9E2JzUk5hc6nJ4X6SL65YtjSpNycoweU8V4nXMwdcvY1E75xHFkSD ByJlb4NySiUlpRlrC2ENMvh6bj/ez9Ylw4zj7IRxg/LNrLkBe+Bo0jSLstjQOym9 6zcJ76Ijq9wda6GMCcsesjPEh+UikfNr/rIEGkHS/PqeVfzWHFkGgVOcvz2itxT1 12tzIvBHhJM5QjnnjcefAEu2ZgpRHDll4ifu7qZghMmgCuCiT1qnSS4/3EoMu6fo LnNOiTcqm0Tepht9mOfCRRCtMVDIYree4BTg8vkRdQzcji+IvT6nNvOjfGfoUR9v 4/8iZv1+o4sobNTZk6TqXtwgqjW0ph98bc3TBLo7lb/zSZ58PIFyDE6e/YiURwc+ gHtktyF0T9Xb85m8xh2/SFR/2rrnx8ila+n8ijyfv9vRlzeFH1ojzMf1Hm8SWHJ9 dvXCj+L/xjqEOiUk+sRZsjsztfo1xXg9Rj++s2ZaIXBH8eTA678DLZo3dnCSFvm5 645dD+c+ndZjAdbFCxn35cGCiS1alvIW6IIkoZw7KbFM9DjhdI8jIT0saOpu3vND kD/QGLYUch/b0iIEoPoKchL47DlsUe29c58UEP6I08rkdgF97/1tVvbuAzmPkl5v wtcQp7guHYDqf+2nxlYK =byKY -----END PGP SIGNATURE----- --k5sLdJo5hAEnUIGq5DBquNDCm228nCLiO-- From owner-freebsd-stable@FreeBSD.ORG Tue Oct 21 18:52:53 2014 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 424DC255 for ; Tue, 21 Oct 2014 18:52:53 +0000 (UTC) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BA48E86D for ; Tue, 21 Oct 2014 18:52:52 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id hz20so1615395lab.39 for ; Tue, 21 Oct 2014 11:52:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=NsYTMTr80MYhLH7g10QOZyRcwuomXc8NUyjE853ErzA=; b=K5XebMyhTnEGjGDW3UIjnexO9V92WO+9TqnC+93MblbWNKD0rLGVeW/dKe0NKtsDVr MaxdnFfCUd3i1dyNaDl65r4h/k5NumZ9cW8bXWI+6Jvt1fw31zzTHv9dMAx9jz+0M2iB qRFgIveljHhHSteeUgehmUhUC1RjcjlDBFVWgfJA5aYc13ZJ32CNtFnRw4vdLRD7RmZg GCEJRe/6x+Fio/CW8SzipdS7ANHSXqodhKEMp/+8oIUTgisE8T1FeNfaoVwbCeMq277s Foqjd6a4HPTCU9oUSS+E8hvOA8BPgWxM8OMtaGtde7s4qOPcJYtSIXJ6IvVbZwLcBsYL gCLQ== X-Received: by 10.112.132.34 with SMTP id or2mr5058949lbb.75.1413917570671; Tue, 21 Oct 2014 11:52:50 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id r4sm2478302lar.3.2014.10.21.11.52.48 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Oct 2014 11:52:49 -0700 (PDT) Sender: Baptiste Daroussin Date: Tue, 21 Oct 2014 20:52:44 +0200 From: Baptiste Daroussin To: Alan Amesbury Subject: Re: Problem with libfetch, pkg, and proxying? Message-ID: <20141021185243.GA224@ivaldir.etoilebsd.net> References: <42CAA1B4-1DE8-4CA6-85A4-29773844B0E2@oitsec.umn.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NzB8fVQJ5HfG6fxh" Content-Disposition: inline In-Reply-To: <42CAA1B4-1DE8-4CA6-85A4-29773844B0E2@oitsec.umn.edu> 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: Tue, 21 Oct 2014 18:52:53 -0000 --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 20, 2014 at 03:20:06PM -0500, Alan Amesbury wrote: > Given FreeBSD-9.1-RELEASE, 'pkg' installed from ports, and a pkg.conf tha= t points to a proxy, it appears 'pkg' is ignoring the proxy setting for HTT= PS URLs. >=20 > The contents of /usr/local/etc/pkg.conf consists of: >=20 >=20 > pkg_env { > http_proxy: http://proxyhost.fqdn:3128/ > } >=20 libfetch does not support proxying https connections on 9.1 you will need to upgrade to a newer release of FreeBSD. regards, Bapt --NzB8fVQJ5HfG6fxh Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRGq3sACgkQ8kTtMUmk6Ex1xQCfaNlhSpNqJxsPSezZwvR9Ygaa QA4AoLzGKvw+dO67gwvlL8KOCvgG6gs5 =G0Ek -----END PGP SIGNATURE----- --NzB8fVQJ5HfG6fxh-- From owner-freebsd-stable@FreeBSD.ORG Tue Oct 21 19:40:52 2014 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 5FFB05CA; Tue, 21 Oct 2014 19:40:52 +0000 (UTC) Received: from mail.oitsec.umn.edu (mail.oitsec.umn.edu [128.101.238.120]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.oitsec.umn.edu", Issuer "InCommon Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C2501D04; Tue, 21 Oct 2014 19:40:51 +0000 (UTC) Received: from mail.oitsec.umn.edu (localhost [127.0.0.1]) by mail.oitsec.umn.edu (Postfix) with ESMTP id 92A2E5C810; Tue, 21 Oct 2014 14:40:39 -0500 (CDT) X-Virus-Scanned: amavisd-new at oitsec.umn.edu Received: from mail.oitsec.umn.edu ([127.0.0.1]) by mail.oitsec.umn.edu (mail.oitsec.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVWXDKjWP0So; Tue, 21 Oct 2014 14:40:39 -0500 (CDT) Received: from optimator.oitsec.umn.edu (optimator.oitsec.umn.edu [134.84.23.1]) (Authenticated sender: amesbury) by mail.oitsec.umn.edu (Postfix) with ESMTPSA id 3750C5C80A; Tue, 21 Oct 2014 14:40:39 -0500 (CDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: Problem with libfetch, pkg, and proxying? From: Alan Amesbury In-Reply-To: <20141021185243.GA224@ivaldir.etoilebsd.net> Date: Tue, 21 Oct 2014 14:40:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <096226D4-9E2D-4D3E-B2CD-007AC5B49329@oitsec.umn.edu> References: <42CAA1B4-1DE8-4CA6-85A4-29773844B0E2@oitsec.umn.edu> <20141021185243.GA224@ivaldir.etoilebsd.net> To: Baptiste Daroussin X-Mailer: Apple Mail (2.1990.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: Tue, 21 Oct 2014 19:40:52 -0000 On Oct 21, 2014, at 13:52 , Baptiste Daroussin wrote: > libfetch does not support proxying https connections on 9.1 you will = need to > upgrade to a newer release of FreeBSD. It's time to upgrade anyway. Thanks again! --=20 Alan Amesbury University Information Security From owner-freebsd-stable@FreeBSD.ORG Tue Oct 21 20:33:46 2014 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 D99986CA for ; Tue, 21 Oct 2014 20:33:46 +0000 (UTC) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (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 97AD63B5 for ; Tue, 21 Oct 2014 20:33:46 +0000 (UTC) Received: from 2a02-8428-011b-e000-0290-f5ff-fe9d-b78c.rev.sfr.net ([2a02:8428:11b:e000:290:f5ff:fe9d:b78c] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1Xgg7k-0001wr-H9 for freebsd-stable@freebsd.org; Tue, 21 Oct 2014 22:33:44 +0200 Message-ID: <5446C324.3010803@dumbbell.fr> Date: Tue, 21 Oct 2014 22:33:40 +0200 From: =?windows-1252?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG) [NVIDIA vs. powerpc64 for vt console switching; Radeon X1950 not working for powerpc64 Xorg generally] References: <2C74DFEC-D943-4237-8988-B9657240EC21@dsl-only.net> <82C08920-CF4B-441F-8162-9F6D2625E927@dsl-only.net> <8BAFEFD4-2FC3-4566-9CCE-F039594BDE7F@dsl-only.net> <83AFBF78-CBE1-4651-B3D6-A83168956D93@dsl-only.net> <19458DB3-FBDE-4BC5-867C-63E875E9261B@dsl-only.net> In-Reply-To: <19458DB3-FBDE-4BC5-867C-63E875E9261B@dsl-only.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="iOu80Q5W2IxFJuj8mREtb3NpjEw0xxMAQ" 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, 21 Oct 2014 20:33:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iOu80Q5W2IxFJuj8mREtb3NpjEw0xxMAQ Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 06.10.2014 10:27, Mark Millard wrote: > Radeon X1950 for 1920x1200: The boot text is fine. Xorg behavior is=20 > no different than with 10.1-RC1/BETA3/... The same Xorg.0.log > messages result and the same failures to find a screen to use > happens. (scfb too.) (Xorg -configure produced xorg.conf.new being a > match to my usual xorg.conf_radeon_pciex that I copy to > /etc/X11/xorg.conf when I switch the SSD to the X1950 based G5.) Could you please post the output of dmesg(8) *after* kldloading radeonkms= ? --=20 Jean-S=E9bastien P=E9dron --iOu80Q5W2IxFJuj8mREtb3NpjEw0xxMAQ 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 iQJ8BAEBCgBmBQJURsMoXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTMNn0P/RKUG9/lCj0nKfhGLXQYG7WY wG9cTHvax+mI2Pf5+36CKbdE03+BPRwL9WWQvJ14SZYyCkVKi1UNUnU5IdMe+eEX EE0zfr9a6M4s4+F3UWdD5w/eAIcoZUfJyzACCu0p6haA8woMOI7Or1esuqvMGTZ+ q8DioIUBfqLh88iTK4gwSFUYIgbIRcRFjbfsPkrb3Dw5FDxCADRTkxaUri8Yuq/U ldxDLrG9JVid/ZME/h80EcXUlqZH8uHoEl3hkd7nEeW+8VoOrtos3tMu05cNvdCR ndCn2BFq5Q5805FCrVd8bqwV8E+bWG8D0OeGKXkmkj1dDdMLiM/8YnS+qvIiW7x4 o7hdwNRv3v0wb4MKe511RXp4WI66OesTCDDVPqZcLLfNAa3wBiptr3paGFyA/+YY qZ4R2FZUpQrwQSNwB5esV6kvIK951wx0Eo7r3/RCNbSU9RBE3bfWeTwi3r4+CXNO HpN4OIaxNZaodOEC5lM5HYdZ6qWb1xwSI1zQ9GUcBJvFV/MZcMPUian7wL7UNU/B HSxqn3LwSYZTsKMqsKoid+wPK5qORW/SlqiwoLQzY0YrJKPwDsZ49L4c35Qc/J67 b5OBXdFGYMJp7IXNoeyH89xxc1VW3kbReAWrNLJwZvd5MywEq4mHYSSAiHY2fLFj d06KPcMQNbqx7ZPNF9X9 =QYYh -----END PGP SIGNATURE----- --iOu80Q5W2IxFJuj8mREtb3NpjEw0xxMAQ-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 22 06:25:19 2014 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 BB4ADBE4; Wed, 22 Oct 2014 06:25:19 +0000 (UTC) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6D7CCAF9; Wed, 22 Oct 2014 06:25:19 +0000 (UTC) Received: by mail-qg0-f44.google.com with SMTP id j5so2007691qga.31 for ; Tue, 21 Oct 2014 23:25:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=/KBf13oMp01ixZfTwwKR0goyEVltVIHM3vbap928Ejk=; b=G0QDFiZ4UkG2kOVJMKOpum7HyxAOclpQI7JPD9iSJmFl1OIjciYh1/wq8IUxEZWqAN 15PyiRPfYjybDkH1HGVaCDmJzmr34fGPehDwRhodUC76RPSoKlps9ODi+rh1as9kzXx+ RWdMmWH4qtcgRgPcvMqzDo/K7s6ENlXGHv1u5SqZzV0VnDJuM6OE62daKSmAc7V+QbaW Ftz1mny2tHUhml3hp3oVeCwZJIUhqys3bwsHo/Im3SiyOmu0V39uXktIaDfXOAFb/Oep 1aqKxtq7YHHkonSUmj9kP2flNyI9NjPADWUNa8fN81xQ4jOwSvr4aioz/3gphcA3W4+V Il3Q== MIME-Version: 1.0 X-Received: by 10.224.125.68 with SMTP id x4mr53041250qar.78.1413959118604; Tue, 21 Oct 2014 23:25:18 -0700 (PDT) Received: by 10.140.220.7 with HTTP; Tue, 21 Oct 2014 23:25:18 -0700 (PDT) In-Reply-To: <54451E2A.1020309@FreeBSD.org> References: <54451422.1070403@FreeBSD.org> <54451E2A.1020309@FreeBSD.org> Date: Wed, 22 Oct 2014 08:25:18 +0200 Message-ID: Subject: Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG) From: Zenny To: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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, 22 Oct 2014 06:25:19 -0000 Even with new xorg, two things didn't work with my Radeon 3 head cards: 1. console switching did not work 2. hdmi audio did not work. Tried also with PCBSD, the same results. I gave up and installed linux in the same machine, both worked fine in addition to: 1. booting time is very fast 2. thermal management is better (usually the cpu temps are 31-40 in linux default installation whereas the temp remains in the range of up to 49-63 with all the tweaks performed.) 3. Power consumption is lower in linux than freebsd (76watts compared to 126watts till the xorg started) These are some of the stuffs that needs to be addressed despite freebsd being overwhelmingly stable. On 10/20/14, Jean-S=C3=A9bastien P=C3=A9dron wrote: > On 20.10.2014 15:54, Jean-S=C3=A9bastien P=C3=A9dron wrote: >> On 20.10.2014 14:16, Pete French wrote: >>>> What version of FreeBSD do you use? >>> >>> 9.2 >> >> You're right, there seems to be something wrong. I'll discuss this with >> the graphics team. > > Koop Mast just committed a fix to the Ports tree. > > -- > Jean-S=C3=A9bastien P=C3=A9dron > > From owner-freebsd-stable@FreeBSD.ORG Wed Oct 22 07:03:47 2014 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 474A1150; Wed, 22 Oct 2014 07:03:47 +0000 (UTC) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) (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 E5131E7E; Wed, 22 Oct 2014 07:03:46 +0000 (UTC) Received: from yggdrasil.alkumuna.eu (unknown [IPv6:2a01:e35:8a74:6e70:232:36ff:fe5c:3a87]) by smtp3-g21.free.fr (Postfix) with ESMTP id 6D405A636A; Wed, 22 Oct 2014 09:02:14 +0200 (CEST) Received: from ist-159-28.ujf-grenoble.fr (ist-159-28.ujf-grenoble.fr [152.77.159.28]) (authenticated bits=0) by yggdrasil.alkumuna.eu (8.14.7/8.14.7) with ESMTP id s9M73d4v002542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Oct 2014 09:03:40 +0200 (CEST) (envelope-from mazhe@alkumuna.eu) Subject: Re: VT switch to console disabled once X starts Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Content-Type: text/plain; charset=utf-8 From: Matthieu Volat In-Reply-To: <5446A203.9000703@FreeBSD.org> Date: Wed, 22 Oct 2014 09:03:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6143A443-555A-472F-A9B7-CFF8356D4C4E@alkumuna.eu> References: <2553F6A9-0363-491B-9585-E12AD32CF0F6@alkumuna.eu> <5446801E.5000405@FreeBSD.org> <20141021195528.1a1eac62@freedom> <5446A203.9000703@FreeBSD.org> To: =?utf-8?Q?Jean-S=C3=A9bastien_P=C3=A9dron?= X-Mailer: Apple Mail (2.1990.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, 22 Oct 2014 07:03:47 -0000 > Le 21 oct. 2014 =C3=A0 20:12, Jean-S=C3=A9bastien P=C3=A9dron = a =C3=A9crit : >=20 > On 21.10.2014 19:55, Matthieu Volat wrote: >>> And is this with vt(4) only? In other words, does it work as = expected >>> with syscons? >>=20 >> I have the problem with both syscons and vt (vga). >=20 > Hmmm, the behavior you describe happens with Intel or Radeon GPUs when > using syscons only. But it's unexpected with the NVIDIA driver, no > matter the console driver you use... Yes, I am very puzzled by this... >=20 > I have no NVIDIA hardware at hand. Was the dmesg you posted taken = before > or after X was started? I should have been, but I'm not sure at which point dmesg.boot is = trunkated, here is the dmesg of a fresh reboot with xdm: Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.1-RC2-p1 #0: Tue Oct 21 06:36:05 UTC 2014 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 VT: running with driver "vga". CPU: Intel(R) Xeon(R) CPU W3520 @ 2.67GHz (2666.72-MHz = K8-class CPU) Origin =3D "GenuineIntel" Id =3D 0x106a5 Family =3D 0x6 Model =3D = 0x1a Stepping =3D 5 = Features=3D0xbfebfbff = Features2=3D0x9ce3bd AMD Features=3D0x28100800 AMD Features2=3D0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,VPID TSC: P-state invariant, performance statistics real memory =3D 8592031744 (8194 MB) avail memory =3D 8236482560 (7854 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 ioapic0: Changing APIC ID to 1 ioapic1: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard random: initialized module_register_init: MOD_LOAD (vesa, 0xffffffff80d92420, 0) error 19 kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) acpi0: reservation of fed40000, 12c1ffe (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, cff00000 (3) failed cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 hpet1: iomem 0xfed00000-0xfed003ff on acpi0 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xf808-0xf80b on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 device_attach: hpet0 attach returned 12 pcib0: on acpi0 pci63: on pcib0 pcib1: port 0xcf8-0xcff on acpi0 pci0: on pcib1 pcib2: at device 1.0 on pci0 pci3: on pcib2 pcib3: at device 3.0 on pci0 pci15: on pcib3 vgapci0: port 0xe000-0xe07f mem = 0xe2000000-0xe2ffffff,0xd0000000-0xdfffffff,0xe0000000-0xe1ffffff irq 24 = at device 0.0 on pci15 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io vgapci0: Boot video device pcib4: at device 7.0 on pci0 pci40: on pcib4 pci0: at device 16.0 (no driver = attached) pci0: at device 16.1 (no driver = attached) pci0: at device 17.0 (no driver = attached) pci0: at device 17.1 (no driver = attached) pci0: at device 20.0 (no driver = attached) pci0: at device 20.1 (no driver = attached) pci0: at device 20.2 (no driver = attached) uhci0: port 0xd000-0xd01f = irq 20 at device 26.0 on pci0 usbus0 on uhci0 uhci1: port 0xd020-0xd03f = irq 21 at device 26.1 on pci0 usbus1 on uhci1 uhci2: port 0xd040-0xd05f = irq 22 at device 26.2 on pci0 usbus2 on uhci2 ehci0: mem = 0xe3204800-0xe3204bff irq 22 at device 26.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 hdac0: mem 0xe3200000-0xe3203fff irq 21 = at device 27.0 on pci0 pcib5: at device 28.0 on pci0 pci28: on pcib5 pcib6: irq 21 at device 28.5 on pci0 pci1: on pcib6 bge0: mem 0xe3100000-0xe310ffff irq 17 at device 0.0 on pci1 bge0: CHIP ID 0x05784100; ASIC REV 0x5784; CHIP REV 0x57841; PCI-E miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, = 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: Ethernet address: f4:ce:46:2d:aa:a6 uhci3: port 0xd060-0xd07f = irq 20 at device 29.0 on pci0 usbus4 on uhci3 uhci4: port 0xd080-0xd09f = irq 21 at device 29.1 on pci0 usbus5 on uhci4 uhci5: port 0xd0a0-0xd0bf = irq 22 at device 29.2 on pci0 usbus6 on uhci5 ehci1: mem = 0xe3204c00-0xe3204fff irq 20 at device 29.7 on pci0 usbus7: EHCI version 1.0 usbus7 on ehci1 pcib7: at device 30.0 on pci0 pci55: on pcib7 pci55: at device 5.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port = 0xd100-0xd107,0xd110-0xd113,0xd108-0xd10f,0xd114-0xd117,0xd0c0-0xd0df = mem 0xe3204000-0xe32047ff irq 18 at device 31.2 on pci0 ahci0: AHCI v1.20 with 6 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on = acpi0 qpi0: on motherboard orm0: at iomem 0xe9000-0xeffff on isa0 ppc0: cannot reserve I/O port range est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 est2: on cpu2 p4tcc2: on cpu2 est3: on cpu3 p4tcc3: on cpu3 random: unblocking device. usbus0: 12Mbps Full Speed USB v1.0 fuse-freebsd: version 0.4.4, FUSE ABI 7.8 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 21 and 24,25,26 on hdaa0 pcm1: at nid 27 on hdaa0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 ugen1.1: at usbus1 uhub0: on usbus0 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 ugen3.1: at usbus3 ugen4.1: at usbus4 uhub3: on usbus3 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device=20 cd0: Serial Number R3786GBSB3631300 cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO = 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present = - tray closed SATA 2.x device ada0: Serial Number 9VM9ERCY ada0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #1 Launched! Timecounter "TSC-low" frequency 1333361188 Hz quality 1000 Root mount waiting for: usbus7 usbus3 Root mount waiting for: usbus7 usbus3 uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered Trying to mount root from zfs:zroot []... ugen6.2: at usbus6 ums0: on usbus6 ums0: 3 buttons and [XYZ] coordinates ID=3D0 And nothing more if I switch to ttyv0... Could it be related to the fact = this is a quadro nvidia card? vgapci0@pci0:15:0:0: class=3D0x030000 card=3D0x063a10de = chip=3D0x065910de rev=3D0xa1 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'G96 [Quadro FX 580]' class =3D display subclass =3D VGA >=20 > Your Xorg.log shows no error either. >=20 I also have a friend that happens to have a HP laptop using freebsd 9.3 = which has the same problem, coincidence? -- Matthieu Volat= From owner-freebsd-stable@FreeBSD.ORG Wed Oct 22 07:42:38 2014 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 95547B9A for ; Wed, 22 Oct 2014 07:42:38 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 55298312 for ; Wed, 22 Oct 2014 07:42:37 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1XgqYo-0007uB-P8 for freebsd-stable@freebsd.org; Wed, 22 Oct 2014 09:42:28 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: freebsd-stable@freebsd.org Subject: Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG) References: <54451422.1070403@FreeBSD.org> <54451E2A.1020309@FreeBSD.org> Date: Wed, 22 Oct 2014 09:42:21 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.17 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.3.1 X-Scan-Signature: 4b95630a2805109a2fafe329e7ec4fd6 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, 22 Oct 2014 07:42:38 -0000 On Wed, 22 Oct 2014 08:25:18 +0200, Zenny wrote: > Even with new xorg, two things didn't work with my Radeon 3 head cards= : > > 1. console switching did not work > 2. hdmi audio did not work. > > Tried also with PCBSD, the same results. I gave up and installed linux= > in the same machine, both worked fine in addition to: > > 1. booting time is very fast > 2. thermal management is better (usually the cpu temps are 31-40 in > linux default installation whereas the temp remains in the range of up= > to 49-63 with all the tweaks performed.) > 3. Power consumption is lower in linux than freebsd (76watts compared > to 126watts till the xorg started) > > These are some of the stuffs that needs to be addressed despite > freebsd being overwhelmingly stable. Can you help addressing all this? Ronald. > On 10/20/14, Jean-S=E9bastien P=E9dron wrote: >> On 20.10.2014 15:54, Jean-S=E9bastien P=E9dron wrote: >>> On 20.10.2014 14:16, Pete French wrote: >>>>> What version of FreeBSD do you use? >>>> >>>> 9.2 >>> >>> You're right, there seems to be something wrong. I'll discuss this w= ith >>> the graphics team. >> >> Koop Mast just committed a fix to the Ports tree. >> >> -- >> Jean-S=E9bastien P=E9dron >> >> > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.o= rg" From owner-freebsd-stable@FreeBSD.ORG Wed Oct 22 10:58:11 2014 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 14B777ED for ; Wed, 22 Oct 2014 10:58:11 +0000 (UTC) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 883A4EB0 for ; Wed, 22 Oct 2014 10:58:10 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id q1so2672345lam.32 for ; Wed, 22 Oct 2014 03:58:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=Wq/qhYgY7HXvJpZWgqdv+gc38IMZ1bU6aLsanwbA/hs=; b=h2IwImVDlH3RqMbzmIeVKs2VUJAeqTSZJcXMXWrkPfNbiNxcJBG0TvKuPjDoVwCvTi eTkXe59MbTkmGtDv5KTX1LsmRXW56GjsC5PC0n4DcX3N9KM+8qtv2j5DjKFzmw7zl+1l Dke0S80yTjyAwrXl7anjw8q1Rc3KCbFYD2WeRgdO7q2sv31ylVF1aFDhe1eKzyKgTHEn FleT2OzY64OfnvaJ4DeEaeLEZZNIeRPvAFlTymKlN1QcFl0kB/GnfvAb8jdwhiuUlrj4 m0C1xqx2tNDWXLQmDIu0FkHZ2RuJHmAx6Gf/jKKDFWfGo/T8+1vIY0ZfxNfkMK2JGxlc DA/g== X-Received: by 10.152.120.199 with SMTP id le7mr6971718lab.67.1413975488417; Wed, 22 Oct 2014 03:58:08 -0700 (PDT) Received: from brick.home (aeaa193.neoplus.adsl.tpnet.pl. [79.186.0.193]) by mx.google.com with ESMTPSA id ro7sm5654653lbb.14.2014.10.22.03.58.06 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Oct 2014 03:58:07 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Wed, 22 Oct 2014 12:58:04 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Harald Schmalzbauer Subject: Re: ctld(8), multiple 'portal-group' on same socket (individual 'discovery-auth-group' restrictions) Message-ID: <20141022105804.GB5415@brick.home> Mail-Followup-To: Harald Schmalzbauer , FreeBSD Stable References: <5444C94C.4050705@omnilan.de> <20141021104308.GA5990@brick.home> <54464405.4090207@omnilan.de> <20141021134516.GA89872@brick.home> <5446988B.5020509@omnilan.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5446988B.5020509@omnilan.de> User-Agent: Mutt/1.5.23 (2014-03-12) 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: Wed, 22 Oct 2014 10:58:11 -0000 On 1021T1931, Harald Schmalzbauer wrote: > Bezüglich Edward Tomasz NapieraÅ‚a's Nachricht vom 21.10.2014 15:45 > (localtime): > > … > >> In my "real world" case, I dispense backup disks to win7 clients via iSCSI. > >> I liked the possibility to limit target-discovery-results, because > >> curious people, garnated such extra resources, weren't able to see who > >> else was granted this extra resource (by definition, there's no private > >> data on the clients which use that backup-strategy, so no need for > >> qualified identity checks or encryption needed). Even with any security > >> mechanisms active, two consumers (some dozen in my case) of the same > >> portal know about the other. That's one example where this feature was > >> useful for me. > > So basically, each target has a different user/password pair, and > > during discovery the target only returns those targets that can actually > > be accessed using that user/password? > > In general, yes, that's what I did with istgt. But I omitted chap > authentication, intead I'm just checking initiator-name/adress. > So speaking in ctl.conf, I would love to see an extension in the target > Context, which influences discovering results, maybe like > > target iqn.2012-06.com.example:target0 { > SendTarget on-discover | access-granted # access-granted only has > effect on assigned portal-group(s), which have 'target-filter' enabled. > … } > > I guess that would need quiet a lot of extra checks added to existing > discovery-response functions, so maybe it would make sense to > selectively enable/disbale this extra check at portal-group Context in > the first place, maybe like > > portal-group lan0 { > target-filter on | off > … } I think I like the second one better. Except I'm not sure about "target-filter" name. "authorized-targets-only" perhaps? > I just had a look at rfc3721, to find a suitable name for the > 'SendTarget' config option I suggested here > (http://www.ietf.org/rfc/rfc3721.txt, Page 12, 3.b). > > Quote of the first sentence in chapter 3, describing the iSCSI discovery: > »The goal of iSCSI discovery is to allow an initiator to find the > targets to which it has access, …« > > “… to which it has access†sounds to me like the filtered SendTarget > behaviuor should be default, but I haven't read the complete docuemtn > nor am I native english speaker... Thought about this as default too. Question is, wouldn't it confuse users? On the other hand, _not_ doing it by default could be confusing too, just in another way. I kind of have a prototype for this. Could you test patches against 11-CURRENT, when I have them ready? > >> Another one actually is (since not implemented in ctld, yet?) with > >> virtual DVDs. If you provide 50 DVDs at one portal, it's confusing if > >> any initiator needs to select from the complete list. > > In this case do the returned targets depend on authentication, or something > > else, eg. a static list defined in config? > > The returned targets are still access restricted, by authentication or > any initiator-match rule (name, address, both). Ok. > >> I'd like to point to two options I'm missing: > >> option RPM > >> option FormFactor > >> And another one I don't know/understand: > >> option scsiname > >> > >> Missing resp. wrong reported option RPM leads to identification as SSD > >> with ESXi initiators. I don't remember what defines a SSD vs. HDD, I > >> think it was a threshold of something about 400? Or was it 0? I think I > >> read the former… Don't have docs handy. > >> The FormFactor was more cosmetic, but in bigger environments I guess it > >> can be useful if you have multiple targets available, choosing the > >> better fitting backend-pool e.g. > > Hm, ok. > > Thanks for your attention again! > > > >> If someone could point me to the meaning of option iscsiname? > > That's an istgt option, right? > > Sorry, haven't made clear: ctl.conf(5) references ctladm(8) for possible > "name value" pairs for the "option" option in the target Context. > In ctladm's OPTIONS section, I can find most options I ever used (and in > my case mandatory options like "product") besides to above mentioned two > (RPM and FormFactor), and also some additional I haven't used. > There's "scsiname" listed. I don't even understand the meaning of that :-( Ah. AFAIK it's just a "device name", at SCSI level. Basically, there are several kinds of identifiers a SCSI device (accessed over iSCSI or some other transport) can return when asked. There is NAA, EUI, and just text, which I believe is the "scsiname". > Hope you don't mind if I add another question: > > In ctl.conf(5), section "portal-group Context", under the description > for 'discovery-auth-group', one can read: > »By default, portal groups that do not specify their own auth > settings, using clauses such as chap or initiator-name, are assigned > predefined auth-group "default",…« > I tried to define 'initiator-name' under portal-group Context, but that > didn't work. I think I got an error message and config-reload was rejected. Hm, yeah, it's a documentation error. You can only use discovery-auth-group. > The reason I tried to not use a predefined auth-froup was, that I get a > warning it I define a auth-group and don't assign it to any target, > instead using it as 'discovery-auth-group' only. Not really a problem, > prpbably not even worth a PR/bugzilla report, but wanted to mention it > here :-) _Every_ problem is worth reporting. I've just fixed the spurious warning, btw. ;-) > And, not enough yet, I'd like to suggest a extension to the examples > section of ctl.conf(5): > > --- /tmp/ctl.conf.sample.orig 2014-10-21 19:11:46.000000000 +0200 > +++ /tmp/ctl.conf.sample 2014-10-21 19:25:28.000000000 +0200 > @@ -1,5 +1,16 @@ > pidfile /var/run/ctld.pid > > + # buitlin special > + #auth-group default { auth-type deny } > + #auth-group no-authentication { auth-type none} What is the above for? > + > + auth-group example1 { > + auth-type none > + initiator-name "iqn.2012-06.com.example:initiatorhost1" > + initiator-name "iqn.2012-06.com.example:initiatorhost2" > + initiator-portal 192.0.2.0/24 > + } This is to show ohw "auth-type none" should be used, right? I like it. > + > auth-group example2 { > chap-mutual "user" "secret" "mutualuser" "mutualsecret" > chap-mutual "user2" "secret2" "mutualuser" "mutualsecret" > @@ -41,3 +52,13 @@ > option foo bar > } > } > + > + target iqn.2012-06.com.example:target1 { > + auth-type none > + initiator-name "iqn.2012-06.com.example:initiatorhostname0" > + initiator-portal [2001:DB8::de:ef] > + portal-group example2 > + lun 0 { > + path /dev/zvol/example_1 > + } > + } This one, however, looks a little redundant. From owner-freebsd-stable@FreeBSD.ORG Wed Oct 22 12:30:32 2014 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 450843ED for ; Wed, 22 Oct 2014 12:30:32 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C2CFDD13 for ; Wed, 22 Oct 2014 12:30:31 +0000 (UTC) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s9MCURbf068353 for ; Wed, 22 Oct 2014 14:30:27 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id EE0E93773; Wed, 22 Oct 2014 14:30:26 +0200 (CEST) Message-ID: <5447A362.30605@omnilan.de> Date: Wed, 22 Oct 2014 14:30:26 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: FreeBSD Stable Subject: Re: ctld(8), multiple 'portal-group' on same socket (individual 'discovery-auth-group' restrictions) References: <5444C94C.4050705@omnilan.de> <20141021104308.GA5990@brick.home> <54464405.4090207@omnilan.de> <20141021134516.GA89872@brick.home> <5446988B.5020509@omnilan.de> <20141022105804.GB5415@brick.home> In-Reply-To: <20141022105804.GB5415@brick.home> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB720318A32A5BEBD0BE97B3E" X-Greylist: ACL 119 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Wed, 22 Oct 2014 14:30:27 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) 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, 22 Oct 2014 12:30:32 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB720318A32A5BEBD0BE97B3E Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bez=C3=BCglich Edward Tomasz Napiera=C5=82a's Nachricht vom 22.10.2014 1= 2:58 (localtime): > On 1021T1931, Harald Schmalzbauer wrote: >> Bez=C3=BCglich Edward Tomasz Napiera=C5=82a's Nachricht vom 21.10.201= 4 15:45 >> (localtime): >> >> =E2=80=A6 >>>> In my "real world" case, I dispense backup disks to win7 clients via= iSCSI. >>>> I liked the possibility to limit target-discovery-results, because >>>> curious people, garnated such extra resources, weren't able to see w= ho >>>> else was granted this extra resource (by definition, there's no priv= ate >>>> data on the clients which use that backup-strategy, so no need for >>>> qualified identity checks or encryption needed). Even with any secur= ity >>>> mechanisms active, two consumers (some dozen in my case) of the same= >>>> portal know about the other. That's one example where this feature w= as >>>> useful for me. >>> So basically, each target has a different user/password pair, and >>> during discovery the target only returns those targets that can actua= lly >>> be accessed using that user/password? >> In general, yes, that's what I did with istgt. But I omitted chap >> authentication, intead I'm just checking initiator-name/adress. >> So speaking in ctl.conf, I would love to see an extension in the targe= t >> Context, which influences discovering results, maybe like >> >> target iqn.2012-06.com.example:target0 { >> SendTarget on-discover | access-granted # access-granted only has >> effect on assigned portal-group(s), which have 'target-filter' enabled= =2E >> =E2=80=A6 } >> >> I guess that would need quiet a lot of extra checks added to existing >> discovery-response functions, so maybe it would make sense to >> selectively enable/disbale this extra check at portal-group Context in= >> the first place, maybe like >> >> portal-group lan0 { >> target-filter on | off >> =E2=80=A6 } > I think I like the second one better. Except I'm not sure about > "target-filter" name. "authorized-targets-only" perhaps? "authorized-targets-only" is much better! My idea was to have both options available. The option in the portal-group Context allowes to control if the option in the target Context should have effect at all (thus could save executions of unwanted checks). And the target option could override the meaning of "authorized-targets-only" when "SendTarget" set to "on-discover". But perhaps that's more confusing than useful=E2=80=A6 One imaginable use= case was if the target-portal admin want's to draw attention to a distinct offered taget, regardless if the intitiator's admin has access _yet_ (so even if the target-portal does filtering, that special target could be sent to the initiator, who probably wants to get that target). Basically I wanted to suggest something least radical as possible, so one could restore "old" behaviour as easy as possible. But I agree if you think that's too much overhead for such a special case= =2E >> I just had a look at rfc3721, to find a suitable name for the >> 'SendTarget' config option I suggested here >> (http://www.ietf.org/rfc/rfc3721.txt, Page 12, 3.b). >> >> Quote of the first sentence in chapter 3, describing the iSCSI discove= ry: >> =C2=BBThe goal of iSCSI discovery is to allow an initiator to find= the >> targets to which it has access, =E2=80=A6=C2=AB >> >> =E2=80=9C=E2=80=A6 to which it has access=E2=80=9D sounds to me like t= he filtered SendTarget >> behaviuor should be default, but I haven't read the complete docuemtn >> nor am I native english speaker... > Thought about this as default too. Question is, wouldn't it confuse > users? On the other hand, _not_ doing it by default could be confusing= > too, just in another way. Can't estimate what was more confusing. I think I remember having seen (enterprise) SAN devices from leading manufactureres, which also didn't filter. But if ESXi is used as initiator, the operator nevertheless wouldn't get confused, since she sees auto-attached targets in the first place, which "feels" like a filtered result. I don't know if ESXi admins commonly look at the real discovery-result-li= st. But that's what all windows operators get presented at first place=E2=80=A6= For me personally, I was very suprised when I first saw targets which I don't have access to and my first idea was to ask the admin of the SAN device, if he accidentally has switched off anything=E2=80=A6 > I kind of have a prototype for this. Could you test patches against > 11-CURRENT, when I have them ready? It's my pleasure to test anything! But I only have one workstation with 11-current available. So I'm limited to synthetic tests and won't be able to provide real world experience with 11. But if the changesets are also applicable to stable (with cosmetic changes, which I can do myself), I can do tests in my small (productive) office environment (consisting of only one ESXi and two Windows initiators), so at least little real world testing :-) >> And, not enough yet, I'd like to suggest a extension to the examples >> section of ctl.conf(5): >> >> --- /tmp/ctl.conf.sample.orig 2014-10-21 19:11:46.000000000 +0200 >> +++ /tmp/ctl.conf.sample 2014-10-21 19:25:28.000000000 +0200 >> @@ -1,5 +1,16 @@ >> pidfile /var/run/ctld.pid >> =20 >> + # buitlin special >> + #auth-group default { auth-type deny } >> + #auth-group no-authentication { auth-type none} > What is the above for? I thought it was useful for lazy people like me, to get the idea of "auth-group no-authentication" in the existing example, without reading := -) It should show that there are two built-in default auth-groups (or at least that the result is like if they were defined like that). And that there is 'auth-type' =20 >> + >> + target iqn.2012-06.com.example:target1 { >> + auth-type none >> + initiator-name "iqn.2012-06.com.example:initiatorhostname= 0" >> + initiator-portal [2001:DB8::de:ef] >> + portal-group example2 >> + lun 0 { >> + path /dev/zvol/example_1 >> + } >> + } > This one, however, looks a little redundant. Yes, it's mostly the other examples duplicated, but there's the very important 'auth-type' shown in action. Maybe there's a better way to show it, or maybe it's enough to show it in my other suggested auth-group example. Thanks, -Harry --------------enigB720318A32A5BEBD0BE97B3E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlRHo2IACgkQLDqVQ9VXb8iEEQCfZ2iLclg9Z2cOJpmLs0tVRbMr LHEAn2yjqen8+V2o5bSf2jElIBV7uB21 =8FXf -----END PGP SIGNATURE----- --------------enigB720318A32A5BEBD0BE97B3E-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 22 15:14:28 2014 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 97CA1F1B for ; Wed, 22 Oct 2014 15:14:28 +0000 (UTC) Received: from www81.your-server.de (www81.your-server.de [213.133.104.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 5534D7DE for ; Wed, 22 Oct 2014 15:14:27 +0000 (UTC) Received: from [77.23.103.58] (helo=michael-think.fritz.box) by www81.your-server.de with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1XgxDq-000683-Fm for freebsd-stable@freebsd.org; Wed, 22 Oct 2014 16:49:10 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes Subject: 10.1 sshd connections/processes don't die on physical disconnect ( sort-of repost ) To: "FreeBSD Stable Mailing List" Date: Wed, 22 Oct 2014 16:49:05 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Michael Ross" Message-ID: User-Agent: Opera Mail/1.0 (Win32) X-Authenticated-Sender: gmx@ross.cx X-Virus-Scanned: Clear (ClamAV 0.98.4/19525/Tue Oct 21 23:56:08 2014) 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, 22 Oct 2014 15:14:28 -0000 Hello, I dug a bit into the observation I posted here: http://lists.freebsd.org/pipermail/freebsd-stable/2014-September/079922.html Problem as follows: Host A running 10.1-RC1 r272736 Host B running 9.2-STABLE r261716 I connect to both hosts via ssh, and then I physically interrupt the connection -- pull the network cable or power down the router. ( simulate ISP forced disconnect ). Behaviour difference in sshd connections an processes, where the peer disconnected hard: 9.2-running Host B: connection and processes disappear after a while ( ~ 2 hours ? ) 10.1-running Host A: connection and processes linger around forever ( > 4 weeks ) Below a diff between the sshd_config files of the machines, Changing "PrivilegeSeparation" from "sandbox" back to "yes" does not help. Hints appreciated. Host A sockstat lists 41 sshd processes with connected sockets for the last 13 days, and I *know* that these are disconnected. Michael 1,2c1,2 < # $OpenBSD: sshd_config,v 1.93 2014/01/10 05:59:19 djm Exp $ < # $FreeBSD: stable/10/crypto/openssh/sshd_config 264692 2014-04-20 12:46:18Z des $ --- > # $OpenBSD: sshd_config,v 1.82 2010/09/06 17:10:19 naddy Exp $ > # $FreeBSD: release/9.1.0/crypto/openssh/sshd_config 224638 > 2011-08-03 19:14:22Z brooks $ 11c11 < # possible, but leave them commented. Uncommented options override the --- > # possible, but leave them commented. Uncommented options change a 17c17,19 < Port 22 --- > #VersionAddendum FreeBSD-20110503 > > #Port 22 19c21 < ListenAddress x.x.x.x --- > #ListenAddress 0.0.0.0 31d32 < #HostKey /etc/ssh/ssh_host_ed25519_key 37,39d37 < # Ciphers and keying < #RekeyLimit default none < 43c41 < #LogLevel INFO --- > LogLevel DEBUG 48c46 < PermitRootLogin no --- > PermitRootLogin yes 55,62c53 < < # The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2 < #AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2 < < #AuthorizedPrincipalsFile none < < #AuthorizedKeysCommand none < #AuthorizedKeysCommandUser nobody --- > #AuthorizedKeysFile .ssh/authorized_keys 92c83 < # and session processing. If this is enabled, PAM authentication will --- > # and session processing. If this is enabled, PAM authentication will 108d98 < #PermitTTY yes 113c103 < #UsePrivilegeSeparation sandbox --- > #UsePrivilegeSeparation yes 120c110 < #MaxStartups 10:30:100 --- > #MaxStartups 10 123d112 < #VersionAddendum FreeBSD-20140420 147d135 < # PermitTTY no From owner-freebsd-stable@FreeBSD.ORG Wed Oct 22 16:17:23 2014 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 F049C141 for ; Wed, 22 Oct 2014 16:17:23 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D7F18F00 for ; Wed, 22 Oct 2014 16:17:23 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9MGHN49045492 for ; Wed, 22 Oct 2014 16:17:23 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 194534] [freebsd-update] upgrade from FreeBSD-10-RELEASE to FreeBSD-10.1RC2 system fail to boot. Date: Wed, 22 Oct 2014 16:17:24 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 10.1-RC2 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sasamotikomi@gmail.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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, 22 Oct 2014 16:17:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194534 sasamotikomi@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |freebsd-stable@FreeBSD.org -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-stable@FreeBSD.ORG Wed Oct 22 16:40:46 2014 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 B9AF35BA for ; Wed, 22 Oct 2014 16:40:46 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A168817C for ; Wed, 22 Oct 2014 16:40:46 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9MGekXS096508 for ; Wed, 22 Oct 2014 16:40:46 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 194534] [freebsd-update] upgrade from FreeBSD-10-RELEASE to FreeBSD-10.1RC2 system fail to boot. Date: Wed, 22 Oct 2014 16:40:46 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 10.1-RC2 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: gjb@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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, 22 Oct 2014 16:40:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194534 --- Comment #1 from Glen Barber --- I am unable to reproduce this. Please provide more information about your machine configuration. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-stable@FreeBSD.ORG Wed Oct 22 17:56:58 2014 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 96FC1BD6 for ; Wed, 22 Oct 2014 17:56:58 +0000 (UTC) Received: from ozzie.tundraware.com (ozzie.tundraware.com [75.145.138.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ozzie.tundraware.com", Issuer "ozzie.tundraware.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 60A53BD0 for ; Wed, 22 Oct 2014 17:56:58 +0000 (UTC) Received: from [10.219.168.191] ([66.175.245.1]) (authenticated bits=0) by ozzie.tundraware.com (8.14.9/8.14.9) with ESMTP id s9MHud6J076815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 22 Oct 2014 12:56:40 -0500 (CDT) (envelope-from tundra@tundraware.com) Message-ID: <5447EFD2.9000609@tundraware.com> Date: Wed, 22 Oct 2014 12:56:34 -0500 From: Tim Daneliuk User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: FreeBSD Stable Subject: /usr/lib/pam_opie.so.5: Shared object "libopie.so.8" not found Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (ozzie.tundraware.com [75.145.138.73]); Wed, 22 Oct 2014 12:56:40 -0500 (CDT) X-TundraWare-MailScanner-Information: Please contact the ISP for more information X-TundraWare-MailScanner-ID: s9MHud6J076815 X-TundraWare-MailScanner: Found to be clean X-TundraWare-MailScanner-From: tundra@tundraware.com X-Spam-Status: No 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, 22 Oct 2014 17:56:58 -0000 I mentioned this yesterday and someone suggested a fix had been committed ... Well, not so much as of FreeBSD 10.1-PRERELEASE #2 r273434. This is still breaking cron and saslauthd, for example. The workaround is an appropriate entry in /usr/local/etc/libmap.d of the form: libopie.so.8 libopie.so.7 -- ---------------------------------------------------------------------------- Tim Daneliuk tundra@tundraware.com PGP Key: http://www.tundraware.com/PGP/ From owner-freebsd-stable@FreeBSD.ORG Wed Oct 22 18:16:43 2014 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 C1C412DD for ; Wed, 22 Oct 2014 18:16:43 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 83C31DF1 for ; Wed, 22 Oct 2014 18:16:42 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Xh0SY-0000jR-Cs; Wed, 22 Oct 2014 20:16:39 +0200 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: "FreeBSD Stable" , "Tim Daneliuk" Subject: Re: /usr/lib/pam_opie.so.5: Shared object "libopie.so.8" not found References: <5447EFD2.9000609@tundraware.com> Date: Wed, 22 Oct 2014 20:16:33 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <5447EFD2.9000609@tundraware.com> User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: -- X-Spam-Score: -2.9 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=disabled version=3.3.1 X-Scan-Signature: 739ba1b2be5fabc1cc6069058737919f 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, 22 Oct 2014 18:16:43 -0000 On Wed, 22 Oct 2014 19:56:34 +0200, Tim Daneliuk wrote: > I mentioned this yesterday and someone suggested a fix had been > committed ... Well, not so much as of FreeBSD 10.1-PRERELEASE #2 > r273434. > > This is still breaking cron and saslauthd, for example. > > The workaround is an appropriate entry in /usr/local/etc/libmap.d of the > form: > > libopie.so.8 libopie.so.7 > > Rebuild the port for saslauthd so it will pick up the right version of libopie again. Regards. Ronald. From owner-freebsd-stable@FreeBSD.ORG Wed Oct 22 18:22:14 2014 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 9CA564BE for ; Wed, 22 Oct 2014 18:22:14 +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 4D8E8ECA for ; Wed, 22 Oct 2014 18:22:13 +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 s9MIIpRg024778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 23 Oct 2014 05:18:58 +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 s9MIIjJg066007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 23 Oct 2014 05:18:45 +1100 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.9/8.14.9/Submit) id s9MIIjEc066006 for freebsd-stable@freebsd.org; Thu, 23 Oct 2014 05:18:45 +1100 (EST) (envelope-from peter) Date: Thu, 23 Oct 2014 05:18:45 +1100 From: Peter Jeremy To: freebsd-stable@freebsd.org Subject: Re: 10.1-RC1 tar(1) spurious directory traversal permission error Message-ID: <20141022181845.GB79285@server.rulingia.com> References: <20141020090424.GB1120@rwpc15.gfn.riverwillow.net.au> <20141020101306.GD1120@rwpc15.gfn.riverwillow.net.au> <20141020103617.GE1120@rwpc15.gfn.riverwillow.net.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="BOKacYhQ+x31HxR3" Content-Disposition: inline In-Reply-To: <20141020103617.GE1120@rwpc15.gfn.riverwillow.net.au> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp 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, 22 Oct 2014 18:22:14 -0000 --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2014-Oct-20 21:36:17 +1100, John Marshall wrote: >On Mon, 20 Oct 2014, 21:13 +1100, John Marshall wrote: >> On Mon, 20 Oct 2014, 11:22 +0200, Ronald Klop wrote: >> > Maybe the output of 'truss -o /tmp/truss.txt tar -czf dtt.tgz -C =20 >> > /data/tftp/thlan .' gives interesting information about what is exactl= y =20 >> > giving the permission denied. > >> $ truss -o /tmp/truss.txt tar -czf dtt.tgz -C /data/tftp/thlan . >> tar: .: Unable to continue traversing directory tree: Permission denied >> tar: Error exit delayed from previous errors. >> truss: can not get etype: No such process >> $=20 The directory traversal code in tar(1) in 10.x has changed to use openat(2) instead of chdir(2). Unfortunately, it appears there's an off-by-one error when popping back up the directory tree at the end and it winds up doing an openat(fd, "..", ...) at a point where fd references the directory specified in the '-C' option to tar. If that directory (the parent of the one passed to -C) is unreadable then it reports an error. To reproduce: server% cd /tmp server% chmod 755 t1 server% rm -r t1 server% mkdir -p t1/t2/{a,b} server% touch t1/t2/{a,b}/{f1,f2} server% tar -cvf /dev/null -C /tmp/t1/t2 . a . a ./b a ./a a ./a/f1 a ./a/f2 a ./b/f1 a ./b/f2 server% chmod 111 t1 =20 server% tar -cvf /dev/null -C /tmp/t1/t2 . a . a ./b a ./a a ./a/f1 a ./a/f2 a ./b/f1 a ./b/f2 tar: .: Unable to continue traversing directory tree: Permission denied tar: Error exit delayed from previous errors. server%=20 --=20 Peter Jeremy --BOKacYhQ+x31HxR3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUR/UFXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs0BB8P/i0c5N522U3LIG2u7ZFhrdOw uKEduPvhpvq51ODWEkE1+jcsdGg5R7mt2efPRyW3SWZmFqojvy+fHiJJ94MXafJU ayjF0JQU1qJB+/7qgYduTo1mjrZ/dLRsT++O5gEqPN7rljzqbBwsuF1UBlU5kvW/ ShgXrJLiAcbR17EPCyZ0y2fYkTFqUMYyApeUTVhu9ZLOHYrQNk4hZqARB5fZ1uZ/ V3lZQaFDxju+sAkva5DjNCOUOu7p6sexNSX9KMuCI8jCQHmxUS5iDWDyl1Z6oo5a 8iKQU8s5NXKxPwuhKubRfcSPuiR0x41E7XdefwQCUNjM3P4WZpsKWa/pfNyZNvAP 8m++fAuORwTT0cvlbbLXYKAWFJhpvLx4m1tndd7gqSzWoZIvqH/MWEz54t0yog/C XYa1+/8HQ7crRc2HlEUh4ZN57DkoTj+07YPYbRAW2JqhqQTWuQhDHv5DqSLyk5iC pHHPuxZ9d0it6lIgrOHON9DyyyDJXg9TDJ5R1Kmy0edl68ty8BfY25OVc+MM4Sct 8x6VhYW7UeRNzVKjcAePQyuR7bMEJqQ1qeeUSExE4xX7queHk6FzH6rj4UpRFTY/ nTVL4fcHXiWC5UVzyo7akW62/44VRSUpdSTo9xDk2izRziTzy6+0qZvdRazZDsxQ hllt4WgivXxCsvaqfUD5 =zXc8 -----END PGP SIGNATURE----- --BOKacYhQ+x31HxR3-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 22 18:31:48 2014 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 2A1BD71C for ; Wed, 22 Oct 2014 18:31:48 +0000 (UTC) Received: from ozzie.tundraware.com (ozzie.tundraware.com [75.145.138.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ozzie.tundraware.com", Issuer "ozzie.tundraware.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 25371FE3 for ; Wed, 22 Oct 2014 18:31:46 +0000 (UTC) Received: from [10.219.168.191] ([66.175.245.1]) (authenticated bits=0) by ozzie.tundraware.com (8.14.9/8.14.9) with ESMTP id s9MIVZNO094220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 22 Oct 2014 13:31:35 -0500 (CDT) (envelope-from tundra@tundraware.com) Message-ID: <5447F802.6010600@tundraware.com> Date: Wed, 22 Oct 2014 13:31:30 -0500 From: Tim Daneliuk User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ronald Klop , FreeBSD Stable Subject: Re: /usr/lib/pam_opie.so.5: Shared object "libopie.so.8" not found References: <5447EFD2.9000609@tundraware.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (ozzie.tundraware.com [75.145.138.73]); Wed, 22 Oct 2014 13:31:36 -0500 (CDT) X-TundraWare-MailScanner-Information: Please contact the ISP for more information X-TundraWare-MailScanner-ID: s9MIVZNO094220 X-TundraWare-MailScanner: Found to be clean X-TundraWare-MailScanner-From: tundra@tundraware.com X-Spam-Status: No 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, 22 Oct 2014 18:31:48 -0000 On 10/22/2014 01:16 PM, Ronald Klop wrote: > On Wed, 22 Oct 2014 19:56:34 +0200, Tim Daneliuk wrote: > >> I mentioned this yesterday and someone suggested a fix had been committed ... >> Well, not so much as of FreeBSD 10.1-PRERELEASE #2 r273434. >> >> This is still breaking cron and saslauthd, for example. >> >> The workaround is an appropriate entry in /usr/local/etc/libmap.d of the form: >> >> libopie.so.8 libopie.so.7 >> >> > > Rebuild the port for saslauthd so it will pick up the right version of libopie > again. The particular error I saw was from cron, so doing what you suggest will not fix all use cases. ---------------------------------------------------------------------------- Tim Daneliuk tundra@tundraware.com PGP Key: http://www.tundraware.com/PGP/ From owner-freebsd-stable@FreeBSD.ORG Wed Oct 22 19:46:05 2014 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 1ECAB6B8; Wed, 22 Oct 2014 19:46:05 +0000 (UTC) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 871119E2; Wed, 22 Oct 2014 19:46:04 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id bs8so2336443wib.5 for ; Wed, 22 Oct 2014 12:46: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:content-transfer-encoding; bh=66sIfBOrz7c+igkZdM06V0OTwRyiOCV4BggoqI8ZzDc=; b=VzddSjxTn8o/I8xY51fTFa6pp0S6grzxD57bpLxFm3SfdQTZjudKumzuSFsUEYjos6 DChiq/BeMGUM9BGuj71TVEI7OO8DfD2qnFh/9EyNISH3vd3+wQTePXfqppFNdVutKSDB ueEEg1Mo7+6DKXnw3yipu4OwFikZs+bJr0pmonxZa7QcdvpZaozB2TGtckc5VS0BBKMA oTaQk4oKy0AdBWHNcHNZsq7u6fApBSbJ2CmtmIqEKD+TVUg29XHDWt53iYyGQrwoENzJ OJMc+VWHub9hKPiZe9f8jjSrd1PYpvNR5jm6BIe8A/MHiz9sbl7QxIt7B74s3T/42/ij B57A== MIME-Version: 1.0 X-Received: by 10.180.74.4 with SMTP id p4mr8007347wiv.20.1414007162782; Wed, 22 Oct 2014 12:46:02 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Wed, 22 Oct 2014 12:46:02 -0700 (PDT) In-Reply-To: References: <54451422.1070403@FreeBSD.org> <54451E2A.1020309@FreeBSD.org> Date: Wed, 22 Oct 2014 12:46:02 -0700 X-Google-Sender-Auth: TjMfeRIjfofiMX0R30opA8ar4Cc Message-ID: Subject: Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG) From: Adrian Chadd To: Zenny Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Stable Mailing List , =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= 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, 22 Oct 2014 19:46:05 -0000 Hi! How are you measuring the CPU temperature and power consumption? Which version of PCBSD did you install? -a On 21 October 2014 23:25, Zenny wrote: > Even with new xorg, two things didn't work with my Radeon 3 head cards: > > 1. console switching did not work > 2. hdmi audio did not work. > > Tried also with PCBSD, the same results. I gave up and installed linux > in the same machine, both worked fine in addition to: > > 1. booting time is very fast > 2. thermal management is better (usually the cpu temps are 31-40 in > linux default installation whereas the temp remains in the range of up > to 49-63 with all the tweaks performed.) > 3. Power consumption is lower in linux than freebsd (76watts compared > to 126watts till the xorg started) > > These are some of the stuffs that needs to be addressed despite > freebsd being overwhelmingly stable. > > On 10/20/14, Jean-S=C3=A9bastien P=C3=A9dron wrote= : >> On 20.10.2014 15:54, Jean-S=C3=A9bastien P=C3=A9dron wrote: >>> On 20.10.2014 14:16, Pete French wrote: >>>>> What version of FreeBSD do you use? >>>> >>>> 9.2 >>> >>> You're right, there seems to be something wrong. I'll discuss this with >>> the graphics team. >> >> Koop Mast just committed a fix to the Ports tree. >> >> -- >> Jean-S=C3=A9bastien P=C3=A9dron >> >> > _______________________________________________ > 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" From owner-freebsd-stable@FreeBSD.ORG Wed Oct 22 23:39:42 2014 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 3A93C2D9 for ; Wed, 22 Oct 2014 23:39:42 +0000 (UTC) Received: from mta1.riverwillow.net.au (mta1.riverwillow.net.au [IPv6:2001:8000:1000:1801::36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mta1.riverwillow.net.au", Issuer "Riverwillow Root Certificate 2010-04-12" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 829C739F for ; Wed, 22 Oct 2014 23:39:41 +0000 (UTC) Received: from mail1.riverwillow.net.au (mail1.riverwillow.net.au [IPv6:2001:8000:1000:1801::46]) by mta1.riverwillow.net.au (8.14.9/8.14.9) with ESMTP id s9MNdXLS037713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 23 Oct 2014 10:39:33 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=mta1002; t=1414021173; bh=jHGPg/n9L7KH+2+GYhx9LenqSvgxifBKl4TIiU1jmQs=; h=Date:From:To:Subject:References:In-Reply-To; b=JG4eDKDMUvYJkEoep1BXdIdPU0nbu6CtHZilvWo8nH8F7lIlAqPYi23DdUX5zlzVG fHc3RwoIZKFMnLjprCiagFow4IBrNbhbESdN71H1vsiFxw1p25zmS+2Gvilo2hcUWt E/Cvcqm6bEksUygNo4i6mOLAouKoKK1PQHWYv+DQ= Received: from rwpc15.gfn.riverwillow.net.au (rwpc15.gfn.riverwillow.net.au [IPv6:2001:8000:1000:18e1:20c:76ff:fe0a:2117]) (authenticated bits=56) by mail1.riverwillow.net.au (8.14.9/8.14.9) with ESMTP id s9MNdRCI037710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 23 Oct 2014 10:39:28 +1100 (AEDT) Date: Thu, 23 Oct 2014 10:39:26 +1100 From: John Marshall To: freebsd-stable@freebsd.org Subject: Re: 10.1-RC1 tar(1) spurious directory traversal permission error Message-ID: <20141022233926.GC4814@rwpc15.gfn.riverwillow.net.au> Mail-Followup-To: freebsd-stable@freebsd.org References: <20141020090424.GB1120@rwpc15.gfn.riverwillow.net.au> <20141020101306.GD1120@rwpc15.gfn.riverwillow.net.au> <20141020103617.GE1120@rwpc15.gfn.riverwillow.net.au> <20141022181845.GB79285@server.rulingia.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KN5l+BnMqAQyZLvT" Content-Disposition: inline In-Reply-To: <20141022181845.GB79285@server.rulingia.com> OpenPGP: id=A29A84A2; url=http://pki.riverwillow.com.au/pgp/johnmarshall.asc 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, 22 Oct 2014 23:39:42 -0000 --KN5l+BnMqAQyZLvT Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 23 Oct 2014, 05:18 +1100, Peter Jeremy wrote: > The directory traversal code in tar(1) in 10.x has changed to use openat(= 2) > instead of chdir(2). Unfortunately, it appears there's an off-by-one err= or > when popping back up the directory tree at the end and it winds up doing = an > openat(fd, "..", ...) > at a point where fd references the directory specified in the '-C' option= to > tar. If that directory (the parent of the one passed to -C) is unreadable > then it reports an error. To reproduce: Thanks, Peter, for the independent confirmation. The scenario of traversal-only access to the parent directory is common in a situation where the directory contains per-user subdirectories, and each user has no business knowing about any subdirectory but his own. The archive generated is fine, the user has full permission to the directory being archived, but tar(1) exits with an error status. I regard this regression as a bug. I have updated Bug 194477. --=20 John Marshall --KN5l+BnMqAQyZLvT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRIQC4ACgkQw/tAaKKahKJ8pwCglyj3zS4Q9jO9NWBHvIbu6vIp kM0AnjbQ10pRH6L3KWeqAig1MNzS5wS8 =TJYO -----END PGP SIGNATURE----- --KN5l+BnMqAQyZLvT-- From owner-freebsd-stable@FreeBSD.ORG Thu Oct 23 02:50:23 2014 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 104ACAF0; Thu, 23 Oct 2014 02:50:23 +0000 (UTC) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::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 C277297B; Thu, 23 Oct 2014 02:50:22 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s9N2oKCL036069; Wed, 22 Oct 2014 22:50:20 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.7/8.14.4/Submit) id s9N2oKUB036066; Wed, 22 Oct 2014 22:50:20 -0400 (EDT) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21576.27884.76574.977691@hergotha.csail.mit.edu> Date: Wed, 22 Oct 2014 22:50:20 -0400 From: Garrett Wollman To: freebsd-stable@freebsd.org, freebsd-fs@freebsd.org Subject: Some 9.3 NFS testing X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Wed, 22 Oct 2014 22:50:20 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, HEADER_FROM_DIFFERENT_DOMAINS autolearn=disabled version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on hergotha.csail.mit.edu 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, 23 Oct 2014 02:50:23 -0000 Just thought I'd share this... I've been doing some acceptance testing on 9.3 prior to upgrading my production NFS servers. My most recent test is running bonnie++ on 192 Ubuntu VMs in parallel, to independent directories in the same server filesystem. It hasn't fallen over yet (will probably take another day or so to complete), and peaked at about 220k ops/s (but this was NFSv4 so there's no FHA and it takes at least two ops for every v3 RPC[1]). bonnie++ is running with -D (O_DIRECT), but I'm actually just using it as a load generator -- I don't care about the output. I have this system configured for a maximum of 64 nfsd threads, and the test load has had it pegged for the past eight hours. Right now all of the load generators are doing the "small file" part of bonnie++, so there's not a lot of activity but there are a lot of synchronous operations; it's been doing 60k ops/s for the past five hours. Load average maxed out at about 24 early on in the test, and has settled around 16-20 for this part of the test. Here's what nfsstat -se has to say (note: not reset for this round of testing): Server Info: Getattr Setattr Lookup Readlink Read Write Create Remove 1566655064 230074779 162549702 0 471311053 1466525587 149235773 115496945 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 125 0 0 245 116 2032193 27485368 223929240 Mknod Fsstat Fsinfo PathConf Commit LookupP SetClId SetClIdCf 0 53 268 131 15999631 0 386 386 Open OpenAttr OpenDwnGr OpenCfrm DelePurge DeleRet GetFH Lock 80924092 0 0 194 0 0 81110394 0 LockT LockU Close Verify NVerify PutFH PutPubFH PutRootFH 0 0 80578106 0 0 1203868156 0 193 Renew RestoreFH SaveFH Secinfo RelLckOwn V4Create 1271 0 14 384 0 570 Server: Retfailed Faults Clients 0 0 191 OpenOwner Opens LockOwner Locks Delegs 192 154 0 0 0 Server Cache Stats: Inprog Idem Non-idem Misses CacheSize TCPPeak 0 0 0 -167156883 1651 115531 I'd love to mix in some FreeBSD-generated loads but as discussed a week or so ago, our NFS client can't handle reading directories from which files are being deleted. FWIW, I just ran a quick "pmcstat -T" and noted the following: PMC: [unhalted-core-cycles] Samples: 775371 (100.0%) , 3264 unresolved Key: q => exiting... %SAMP IMAGE FUNCTION CALLERS 24.0 kernel _mtx_lock_sleep _vm_map_lock:22.4 ... 4.7 kernel Xinvlrng 4.7 kernel _mtx_lock_spin pmclog_reserve 4.2 kernel _sx_xlock_hard _sx_xlock 3.8 pmcstat _init 2.5 kernel bcopy vdev_queue_io_done 1.7 kernel _sx_xlock 1.6 zfs.ko lzjb_compress zio_compress_data 1.4 zfs.ko lzjb_decompress zio_decompress 1.2 kernel _sx_xunlock 1.2 kernel ipfw_chk ipfw_check_hook 1.1 libc.so.7 bsearch 1.0 zfs.ko fletcher_4_native zio_checksum_compute 1.0 kernel vm_page_splay vm_page_find_least 1.0 kernel cpu_idle_mwait sched_idletd 1.0 kernel free 0.9 kernel bzero 0.9 kernel cpu_search_lowest cpu_search_lowest 0.8 kernel vm_map_entry_splay vm_map_lookup_entry 0.8 kernel cpu_search_highest cpu_search_highest I doubt that this is news to anybody. Once I get the production servers upgraded to 9.3, I'll be ready to start testing 10.1 on this same setup. -GAWollman [1] I did previous testing, with smaller numbers of clients, using v3 as that is what we currently require our clients to use. I switched to v4 to try out the worst case -- after finding an OpenStack bug that was preventing me from starting more than 16 load generators at a time. From owner-freebsd-stable@FreeBSD.ORG Thu Oct 23 03:08:14 2014 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 6D349203 for ; Thu, 23 Oct 2014 03:08:14 +0000 (UTC) Received: from isis.morrow.me.uk (isis.morrow.me.uk [204.109.63.142]) by mx1.freebsd.org (Postfix) with ESMTP id 4583BC26 for ; Thu, 23 Oct 2014 03:08:13 +0000 (UTC) Received: from anubis.morrow.me.uk (unknown [93.89.81.46]) (Authenticated sender: mauzo) by isis.morrow.me.uk (Postfix) with ESMTPSA id 014DF4508A; Thu, 23 Oct 2014 03:08:05 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 isis.morrow.me.uk 014DF4508A DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morrow.me.uk; s=dkim201101; t=1414033686; bh=xG8JxNqwoCrTASQ00TrfLPi9lYrkLJTix+VrGoLyzVY=; h=Date:From:To:Subject:References:In-Reply-To; b=wrvn0cOoJRtYRR1WFZaljtaF/babEErmy5MXEjSMuaWsiz63v6FKbHPDDhh7zStOy bTseHQSmYVqyrQGPbmAskThaoT/icVlYKB6nQ/7i9OKhQY/K1ER9p+ZV9iK4v/eKza p6g8piL4RuTmpyzSc1GuhQttDKszaM8LtSKsevl4= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98.4 at isis.morrow.me.uk Received: by anubis.morrow.me.uk (Postfix, from userid 5001) id DA86315057; Thu, 23 Oct 2014 03:08:01 +0000 (UTC) Date: Thu, 23 Oct 2014 03:08:01 +0000 From: Ben Morrow To: jean-sebastien.pedron@dumbbell.fr, freebsd-stable@freebsd.org Subject: Re: 10.1 kernel device config for drm2 and kms drivers Message-ID: <20141023030801.GA2325@anubis.morrow.me.uk> Mail-Followup-To: jean-sebastien.pedron@dumbbell.fr, freebsd-stable@freebsd.org References: <20140911064731.GA15930@rwpc15.gfn.riverwillow.net.au> <54115D2A.5020802@FreeBSD.org> <20140911084624.GK2737@kib.kiev.ua> <20140911211428.GA6247@anubis.morrow.me.uk> <20140913204209.GA18072@anubis.morrow.me.uk> <20141021023235.GA77122@anubis.morrow.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141021023235.GA77122@anubis.morrow.me.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: Thu, 23 Oct 2014 03:08:14 -0000 Ben Morrow wrote: > Quoth =?windows-1252?Q?Jean-S=E9bastien_P=E9dron?= > : > > On 13.09.2014 22:42, Ben Morrow wrote: > > > Previously, with syscons, I could usually scroll back after boot had > > > finished and the login: prompt appeared and get all the way up to the > > > start of the kernel messages (the Copyright line). > > > > > > Now, with vt, and loading radeonkms from rc.conf rather than > > > loader.conf, if I switch to the console, I can: scroll up through 8 > > > screens of kernel and userland console messages > > > > The history scrolling was rewritten in r271871 (HEAD) and r271973 > > (10.1). I believe your problem is fixed by this change. > > > > Can you confirm if 10.1-RC* works for you in this regard? > > I'll check as soon as I can. I've just tested 10.1-RC3, and this indeed appears to have fixed the problem. Thank you. Ben From owner-freebsd-stable@FreeBSD.ORG Thu Oct 23 07:51:06 2014 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 BC9E1780; Thu, 23 Oct 2014 07:51:06 +0000 (UTC) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46FE49F2; Thu, 23 Oct 2014 07:51:06 +0000 (UTC) Received: by mail-qa0-f48.google.com with SMTP id x12so307553qac.21 for ; Thu, 23 Oct 2014 00:51:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ozwBqeMMpshvgDxVC2ksirRbT89YUWCnhdAXq59/4VM=; b=YLOu2TkXmrUeH08wwv1yoMCwYZulAHNlTVzRPFzNBQC0fopppelFLzCF3b7fi/159+ abroteUT5MMzpNRc1bAP0Ro82KrH91Xu0A1+DU4IYsGhqfuLLxN4g0igyd+pNNlfaiOC E2+Znut7J2FK61Gaa4BKl3NL3mOAJXbt/ty4oTIL549T+Z/N3dEPT2iKAMNWm8fnnlx7 m/L6rmMVo3yFQdP7jewNC3w/CI2MK8+C9kNaVRkanmwXxaMqLR5Ztbkt9MNiXpgAVjiC jKjrcms+Z6tdJWdqYpV55d+rZ2W6EXZUYfJUwOeHiiO8oxRyK55UlvnCvgn3FaATozA8 OA0A== MIME-Version: 1.0 X-Received: by 10.229.7.133 with SMTP id d5mr5077064qcd.24.1414050665145; Thu, 23 Oct 2014 00:51:05 -0700 (PDT) Received: by 10.140.220.7 with HTTP; Thu, 23 Oct 2014 00:51:05 -0700 (PDT) In-Reply-To: References: <54451422.1070403@FreeBSD.org> <54451E2A.1020309@FreeBSD.org> Date: Thu, 23 Oct 2014 09:51:05 +0200 Message-ID: Subject: Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG) From: Zenny To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Stable Mailing List , =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= 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, 23 Oct 2014 07:51:06 -0000 Hi Adrian: I use hardwares for both. For temperature, I use IR Thermogun like http://www.amazon.com/BAFX-Products-Infrared-Thermometer-Includes/dp/B00NI3= HNQK/ref=3Dsr_1_3?ie=3DUTF8&qid=3D1414050390&sr=3D8-3&keywords=3Dinfrared+t= hermometer For power monitor, I use a wattmeter like: http://www.amazon.com/P3-P4400-Electricity-Usage-Monitor/dp/B00009MDBU Hope this clarifies! On 10/22/14, Adrian Chadd wrote: > Hi! > > How are you measuring the CPU temperature and power consumption? > > Which version of PCBSD did you install? > > > > -a > > > On 21 October 2014 23:25, Zenny wrote: >> Even with new xorg, two things didn't work with my Radeon 3 head cards: >> >> 1. console switching did not work >> 2. hdmi audio did not work. >> >> Tried also with PCBSD, the same results. I gave up and installed linux >> in the same machine, both worked fine in addition to: >> >> 1. booting time is very fast >> 2. thermal management is better (usually the cpu temps are 31-40 in >> linux default installation whereas the temp remains in the range of up >> to 49-63 with all the tweaks performed.) >> 3. Power consumption is lower in linux than freebsd (76watts compared >> to 126watts till the xorg started) >> >> These are some of the stuffs that needs to be addressed despite >> freebsd being overwhelmingly stable. >> >> On 10/20/14, Jean-S=C3=A9bastien P=C3=A9dron wrot= e: >>> On 20.10.2014 15:54, Jean-S=C3=A9bastien P=C3=A9dron wrote: >>>> On 20.10.2014 14:16, Pete French wrote: >>>>>> What version of FreeBSD do you use? >>>>> >>>>> 9.2 >>>> >>>> You're right, there seems to be something wrong. I'll discuss this wit= h >>>> the graphics team. >>> >>> Koop Mast just committed a fix to the Ports tree. >>> >>> -- >>> Jean-S=C3=A9bastien P=C3=A9dron >>> >>> >> _______________________________________________ >> 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= " > From owner-freebsd-stable@FreeBSD.ORG Thu Oct 23 08:45:06 2014 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 C0321A26 for ; Thu, 23 Oct 2014 08:45:06 +0000 (UTC) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (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 80F17FAD for ; Thu, 23 Oct 2014 08:45:06 +0000 (UTC) Received: from 2a02-8428-011b-e000-0290-f5ff-fe9d-b78c.rev.sfr.net ([2a02:8428:11b:e000:290:f5ff:fe9d:b78c] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XhE12-000Amj-PB for freebsd-stable@freebsd.org; Thu, 23 Oct 2014 10:45:04 +0200 Message-ID: <5448C010.9090709@dumbbell.fr> Date: Thu, 23 Oct 2014 10:45:04 +0200 From: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG) References: <54451422.1070403@FreeBSD.org> <54451E2A.1020309@FreeBSD.org> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hpO9CnferEw7Ii4FO9HXtD8Mob1qsNdF0" 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, 23 Oct 2014 08:45:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hpO9CnferEw7Ii4FO9HXtD8Mob1qsNdF0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 22.10.2014 08:25, Zenny wrote: > Even with new xorg, two things didn't work with my Radeon 3 head cards:= >=20 > 1. console switching did not work Could you please describe your problem in more detail? For instance, do you use the new vt(4) console driver, which isn't enabled by default? > 2. hdmi audio did not work. HDMI audio isn't supported at all in our Radeon driver and won't be until we update it to match at least Linux 3.13 or something (I don't remember the exact number where HDMI audio was considered stable). Currently, we are at Linux 3.8. --=20 Jean-S=C3=A9bastien P=C3=A9dron --hpO9CnferEw7Ii4FO9HXtD8Mob1qsNdF0 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 iQJ8BAEBCgBmBQJUSMAQXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTMgF0P/1UT07tXX/OY7/ST3QfgWT2T PrED1KWZSKA/rJeP6j9tHI6IZdyxd/ZEEgw1xmiPXZbu0VhjFbmEQEpgn7ssmpiO rz2xSZLpI0KiE7mb9432IewMt/UCmTxJ7P0ovKvKN44wOC0KVxw3Rs690gEGP3bR VTKlipaDyTUUq9/RfyEHQ1CYtzNP9AQvfptoLOSiwZFn743KI/6L2/8j+d1RTxna RHNxQReXcnef6XALt6EUV8621ENnG69ZVM0x679kvr90cabd4wL2mvl5Vo7gdDE8 46VjK6ci81qm0w3Z1+5VhJbYP8ul54BPcNosoOCB5cB3+reJM7lgIz7M40Bh4kIg TpVAKpySU5zbO11ntsB/+EXv8lDRExmTnmBUFgJz21FV0fAHk3uFI7eh2dW57knB BFNROY7DKiyYhLVr7uz07OOFp2W7sT8mCjlxl4ax8e3hkBv8MeEmmJzGvBUKDyq4 c1bL5uCv+E1m/4LBufFroEP1TGpBgY6tFoT71iXho0m+8X1wKd/oP+ISoZ/9OUHA 2U6fVj96COfBcOYixrKn94I+CLQb/M3qMYjLIU1P82KfnemoHOu+LbFOTDvIZkq6 T9XbHVxI02bYrdsEaAtejpRFOZ1KXRRzttxkXdUkXPvsWeOfoR4LtMFGr5SrsQCg /kUWszZ1YxvZJsKlcDRZ =Hjh0 -----END PGP SIGNATURE----- --hpO9CnferEw7Ii4FO9HXtD8Mob1qsNdF0-- From owner-freebsd-stable@FreeBSD.ORG Thu Oct 23 08:57:08 2014 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 31F6DD86; Thu, 23 Oct 2014 08:57:08 +0000 (UTC) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (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 E578214E; Thu, 23 Oct 2014 08:57:07 +0000 (UTC) Received: from 2a02-8428-011b-e000-0290-f5ff-fe9d-b78c.rev.sfr.net ([2a02:8428:11b:e000:290:f5ff:fe9d:b78c] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XhECg-000Auf-1f; Thu, 23 Oct 2014 10:57:06 +0200 Message-ID: <5448C2DD.7040201@dumbbell.fr> Date: Thu, 23 Oct 2014 10:57:01 +0200 From: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org, Aleksandr Rybalko , Alexey Dokuchaev , Ed Maste Subject: Re: VT switch to console disabled once X starts References: <2553F6A9-0363-491B-9585-E12AD32CF0F6@alkumuna.eu> <5446801E.5000405@FreeBSD.org> <20141021195528.1a1eac62@freedom> <5446A203.9000703@FreeBSD.org> <6143A443-555A-472F-A9B7-CFF8356D4C4E@alkumuna.eu> In-Reply-To: <6143A443-555A-472F-A9B7-CFF8356D4C4E@alkumuna.eu> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TTt3Pl4cXI69Cs5S2CppUCtoBNO5hXSeU" 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, 23 Oct 2014 08:57:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TTt3Pl4cXI69Cs5S2CppUCtoBNO5hXSeU Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 22.10.2014 09:03, Matthieu Volat wrote: >> Le 21 oct. 2014 =C3=A0 20:12, Jean-S=C3=A9bastien P=C3=A9dron a =C3=A9crit : >> On 21.10.2014 19:55, Matthieu Volat wrote: >>>> And is this with vt(4) only? In other words, does it work as expecte= d >>>> with syscons? >>> >>> I have the problem with both syscons and vt (vga). >> >> Hmmm, the behavior you describe happens with Intel or Radeon GPUs when= >> using syscons only. But it's unexpected with the NVIDIA driver, no >> matter the console driver you use... >=20 > Yes, I am very puzzled by this... I CC Aleksandr and Ed, both developers of vt(4) and Alexey, the maintainer of the NVIDIA proprietary driver in the Ports tree. To sum up the thread: Matthieu is having trouble with vt-switching when using his NVIDIA Quadro card on FreeBSD 10.1-RC2. No matter if he uses syscons of vt(4), he always get a blank screen when switching to the console. Exactly, like syscons with a KMS driver: the console works (ie. responds to keyboard events) but nothing is displayed. A friend of his has a similar problem on 9.3. Have you guys already heard of Mathieu's problem? Did we already get success/failure reports from owners of Quadro cards? FYI, the start of the thread is here: https://lists.freebsd.org/pipermail/freebsd-stable/2014-October/080585.ht= ml >> I have no NVIDIA hardware at hand. Was the dmesg you posted taken befo= re >> or after X was started? >=20 > I should have been, but I'm not sure at which point dmesg.boot is=20 > trunkated, here is the dmesg of a fresh reboot with xdm: >=20 > (...) > vgapci0: port 0xe000-0xe07f mem 0xe2000000-0xe= 2ffffff,0xd0000000-0xdfffffff,0xe0000000-0xe1ffffff irq 24 at device 0.0 = on pci15 > nvidia0: on vgapci0 > vgapci0: child nvidia0 requested pci_enable_io > vgapci0: child nvidia0 requested pci_enable_io > vgapci0: Boot video device > (...) >=20 > And nothing more if I switch to ttyv0... Could it be related to the=20 > fact this is a quadro nvidia card? >=20 > vgapci0@pci0:15:0:0: class=3D0x030000 card=3D0x063a10de chip=3D0x065910= de rev=3D0xa1 hdr=3D0x00 > vendor =3D 'NVIDIA Corporation' > device =3D 'G96 [Quadro FX 580]' > class =3D display > subclass =3D VGA >=20 >> Your Xorg.log shows no error either. >=20 > I also have a friend that happens to have a HP laptop using freebsd=20 > 9.3 which has the same problem, coincidence? --=20 Jean-S=C3=A9bastien P=C3=A9dron --TTt3Pl4cXI69Cs5S2CppUCtoBNO5hXSeU 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 iQJ8BAEBCgBmBQJUSMLhXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTMJmgP/0Z4Yepven6SsUKQuFpt0xnf Y+fuzZHdEa7pKgarNBhEhu/8Az2YFVMWaLvwQ4xX4iPCnBeYHdpDzHJ1e0GTOMXy XgWGeYISlj/MDy3ypRbq3lDij+JzrkccFlx4ADrafN/38dgyGvKhS2Sodflzyomb qcHJGr9OcYRkUj12T+WIoy5K9OO1/WsO0C1smb3aur5Omc27ZeEF/f+90npMoPEj hCgOSPYvlNqFfgK+FoAdjqD88qdceqHhSU6/vS2O0X6jSC2CKx2FahCPkKG4AnZK rfLgicDlI340AoiE5kyiMqVG/wgs7LVripW6LqmRLeQGg+Yvoj4yA0TgzJF+R9DX gxNAvO4v0BemG07ykVtP3qZffqMiMpbGUtzaDKlUj2vOSGR0FrX8rH/JBYpOqc+k 900sullgXf0tmqmmJkOgjWSjgxQR7EmSMvxP2JuJ0sIizePIth3akOC9bFHDMcTx Ulg0egXI4qdO+pZzfg4bRa1Icv32kmaMJ1s+YFcGxyTJvfH5PyB20Dz0PlJGjnaz 832ooaXUtDgH4MIIoGCLETr0abU8T7QbSglahYP2ZrkeQSjpCNMsdIqMvFTTW2du a7J6b2vstFeD+9kjBH+Nea6FMVLx52O0gPQ4TrAOn2ItJcoRNjnoJQ3ZlP3K4MzO bY+iLknpb0dT2ipUF/XR =oGPZ -----END PGP SIGNATURE----- --TTt3Pl4cXI69Cs5S2CppUCtoBNO5hXSeU-- From owner-freebsd-stable@FreeBSD.ORG Thu Oct 23 09:05:22 2014 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 2153F1A3 for ; Thu, 23 Oct 2014 09:05:22 +0000 (UTC) Received: from mail.prolet.org (mail.prolet.org [195.24.42.5]) (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 CE4E4265 for ; Thu, 23 Oct 2014 09:05:21 +0000 (UTC) Received: from amorphis.prolet.org (localhost [127.0.0.1]) by mail.prolet.org (Postfix) with ESMTP id 21F3F3380C4F for ; Thu, 23 Oct 2014 11:59:15 +0300 (EEST) X-Virus-Scanned: amavisd-new at mail.prolet.org Received: from mail.prolet.org ([127.0.0.1]) by amorphis.prolet.org (amorphis.prolet.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmFL1dtpWeFg for ; Thu, 23 Oct 2014 11:59:10 +0300 (EEST) Received: from [10.140.54.79] (unknown [213.91.150.2]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.prolet.org (Postfix) with ESMTPSA id 016313380C4C for ; Thu, 23 Oct 2014 11:59:09 +0300 (EEST) Message-ID: <5448C35C.5080600@paladin.bulgarpress.com> Date: Thu, 23 Oct 2014 11:59:08 +0300 From: Mailing lists User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: stable@freebsd.org Subject: FreeBSD 9.1 + Supermicro IPMI + reboot = kernel crash 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, 23 Oct 2014 09:05:22 -0000 Hi people, I've three machines - FreeBSD 9.1 (i386+amd64) - at reboot usually the kernel dump and therefore gmirror rebuilds, etc. After reboot - kldload show the module is inserted but /dev/ipmi* is not populated, kldunload + kldload of the module fixes the access + /dev/ipmi* population. Any ideas (except upgrade which I plan to 9.3 soon)? +Waiting (max 60 seconds) for system process `vnlru' to stop...done +Waiting (max 60 seconds) for system process `bufdaemon' to stop...done + +Waiting (max 60 seconds) for system process `syncer' to stop...Syncing disks, vnodes remaining...9 Sleeping thread (tid 100093, pid 16) owns a non-sleepable lock +KDB: stack backtrace of thread 100093: +#0 0xffffffff808f3196 at mi_switch+0x186 +#1 0xffffffff8092bfa2 at sleepq_wait+0x42 +#2 0xffffffff808f3926 at _sleep+0x376 +#3 0xffffffff81551227 at ipmi_submit_driver_request+0x97 +#4 0xffffffff815519df at ipmi_set_watchdog+0xaf +#5 0xffffffff81551c8f at ipmi_wd_event+0x8f +#6 0xffffffff807bbdef at kern_do_pat+0x9f +#7 0xffffffff80984187 at sched_sync+0x1e7 +#8 0xffffffff808bbe3f at fork_exit+0x11f +#9 0xffffffff80bc3d9e at fork_trampoline+0xe +panic: sleeping thread +cpuid = 0 +KDB: stack backtrace: +#0 0xffffffff80920cf6 at kdb_backtrace+0x66 +#1 0xffffffff808ead0e at panic+0x1ce +#2 0xffffffff8092f172 at propagate_priority+0x1d2 +#3 0xffffffff8092fe9e at turnstile_wait+0x1be +#4 0xffffffff808d9198 at _mtx_lock_sleep+0xd8 +#5 0xffffffff8097d9b3 at vn_syncer_add_to_worklist+0x143 +#6 0xffffffff80981ac4 at reassignbuf+0xe4 +#8 0xffffffff8096a232 at bdwrite+0x52 +#7 0xffffffff809661c2 at bdirty+0x42 +#9 0xffffffff80af4ba9 at ffs_freefile+0x269 +#10 0xffffffff80b09711 at handle_workitem_freefile+0x101 +#11 0xffffffff80b09ba7 at process_worklist_item+0x377 +#12 0xffffffff80b0d8d6 at softdep_process_worklist+0x96 +#13 0xffffffff80b0fee7 at softdep_flush+0x197 +#14 0xffffffff808bbe3f at fork_exit+0x11f From owner-freebsd-stable@FreeBSD.ORG Thu Oct 23 13:39:50 2014 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 A1C14D87 for ; Thu, 23 Oct 2014 13:39:50 +0000 (UTC) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 61B21806 for ; Thu, 23 Oct 2014 13:39:50 +0000 (UTC) Received: by mail-qa0-f42.google.com with SMTP id cs9so673665qab.15 for ; Thu, 23 Oct 2014 06:39:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=k1BW7QkmGvY/dL2cEuOkbTBQJTY6vAb75ir39GiJGyU=; b=jtJwYHfVShX9lSjEkSElmagr2QnQoSBPYIwxfUDral+3OOWMGtQRcODNZ5qbdOGhMq JLPoNLBvknBl5EFtJNyruFeNJ4nRZ7wDecLxr+bJG28wzuedDOgOS01/iKV2GGtxH/5L BKYtqWuQRzGACfnBHuVYYC7lNN/L6qOb9LWAHp9szSL0mN0ULoyixlr2UrwZkF1/YRRU WYGSSQYP8YdQipZg6fU18kV7ZOmwX5PFaNJgEm7gqV0FL1PLShSQ8eXs00McjI0PjSoQ mhjpVHQwMhsRbaAH+PxquZX+Z7Mul1fCkbgXqGEppEU/RPN7fWQ1G7JY353NjATUQXZZ 687g== MIME-Version: 1.0 X-Received: by 10.140.108.244 with SMTP id j107mr7291266qgf.27.1414071589307; Thu, 23 Oct 2014 06:39:49 -0700 (PDT) Received: by 10.140.220.7 with HTTP; Thu, 23 Oct 2014 06:39:49 -0700 (PDT) In-Reply-To: <5448C010.9090709@dumbbell.fr> References: <54451422.1070403@FreeBSD.org> <54451E2A.1020309@FreeBSD.org> <5448C010.9090709@dumbbell.fr> Date: Thu, 23 Oct 2014 15:39:49 +0200 Message-ID: Subject: Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG) From: Zenny To: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Thu, 23 Oct 2014 13:39:50 -0000 On 10/23/14, Jean-S=C3=A9bastien P=C3=A9dron wrote: > On 22.10.2014 08:25, Zenny wrote: >> Even with new xorg, two things didn't work with my Radeon 3 head cards: >> >> 1. console switching did not work > > Could you please describe your problem in more detail? You may find this reported in some of the previous threads to this list. > > For instance, do you use the new vt(4) console driver, which isn't > enabled by default? Yep, I did enable it. Maybe I posted somewhere about this earlier to this mailing list and tried to make it work for some three months, failed and absorbed to gnu/linux again. > >> 2. hdmi audio did not work. > > HDMI audio isn't supported at all in our Radeon driver and won't be > until we update it to match at least Linux 3.13 or something (I don't > remember the exact number where HDMI audio was considered stable). > Currently, we are at Linux 3.8. Thanks for useful update. > > -- > Jean-S=C3=A9bastien P=C3=A9dron > > From owner-freebsd-stable@FreeBSD.ORG Thu Oct 23 13:47:36 2014 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 398BB2A1; Thu, 23 Oct 2014 13:47:36 +0000 (UTC) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 88296943; Thu, 23 Oct 2014 13:47:35 +0000 (UTC) Received: by mail-lb0-f180.google.com with SMTP id n15so839243lbi.25 for ; Thu, 23 Oct 2014 06:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=ilwixD3gP6SaqfLI1GFrqrssIsbaCIT/6E5H1M8PcYM=; b=hNKHXrSYH+ETMriAvWNZdcPyUGh4gELHWRITEEIWqnxQIufQMVn2H9mjq8fKoAxzWe 5tQhsx7/NvUugNXTJ2iLCvL6XlbgbCzNYMMwIoFPZvG/3BKTCseNEhHMRSqYNPJ1TXF5 +vgNNcmNQ5g13v3I5+WRtRA0fCr6tctVUzOUWAuqAluqSPtwJ0gVQfzrWTCpjMYtzM2E zm5QfVtViEJyUEBLNrtQyB25yq95fOc5JzwvI9LcWdgEaPwrc7D6gH53JhHj5TKPUaO0 P1RAdwmqdPnnHknWXVi5cD/KtDpLAXsKrEfIhyzRdDnVvuO17CsBB75V2KHaWYbuYwLg JGvQ== X-Received: by 10.112.132.34 with SMTP id or2mr5183733lbb.75.1414072053454; Thu, 23 Oct 2014 06:47:33 -0700 (PDT) MIME-Version: 1.0 Sender: royce.williams@gmail.com Received: by 10.112.171.73 with HTTP; Thu, 23 Oct 2014 06:47:13 -0700 (PDT) In-Reply-To: References: <20140610195025.af77561acbb2224539762600@mimar.rs> <20140610175315.GR2341@home.opsec.eu> <20140610180515.GA2380@bewilderbeast.blackhelicopters.org> From: Royce Williams Date: Thu, 23 Oct 2014 05:47:13 -0800 X-Google-Sender-Auth: EPCKcIO443Do4Z_I5ZrktrRLvDo Message-ID: Subject: Re: freebsd-update to 9.2-RELEASE-p8 loop To: freebsd-stable , secteam@freebsd.org Content-Type: text/plain; charset=UTF-8 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, 23 Oct 2014 13:47:36 -0000 On Tue, Jun 10, 2014 at 11:17 AM, Royce Williams wrote: > On Tue, Jun 10, 2014 at 11:08 AM, Royce Williams wrote: >> On Tue, Jun 10, 2014 at 10:43 AM, Royce Williams wrote: >>> On Tue, Jun 10, 2014 at 10:05 AM, Michael W. Lucas >>> wrote: >>>> On Tue, Jun 10, 2014 at 07:53:15PM +0200, Kurt Jaeger wrote: >>>>> Hi! >>>>> >>>>> > I used freebsd-update to update from 9.2-RELEASE-p7 to 9.2-RELEASE-p8 >>>>> > and rebooted. >>>>> > >>>>> > After reboot, uname -a shows 9.2-RELEASE-p7, but I've seen this before >>>>> > and consider it normal. >>>>> >>>>> p8 did not touch the kernel, therefore there is no update in the uname output. >>>>> >>>>> Why it again and again updates linker.hints, I don't know. >>>> >>>> linker.hints should be added to /etc/freebsd-update.conf IgnoreFiles, i.e.: >>>> >>>> IgnorePaths /boot/kernel/linker.hints >>>> >>>> linker.hints is dynamically generated, and freebsd-update shouldn't >>>> touch it. Yes, it's a bug. >>> >>> More background in this forums thread: >>> >>> https://forums.freebsd.org/viewtopic.php?&t=1362 >>> >>> Also, I've found that just adding the IgnorePaths line may be >>> necessary, but is not sufficient. I have added that line, but >>> freebsd-update continues to detect linker.hints as a needed update: >>> >>> $ grep linker /etc/freebsd-update.conf >>> IgnorePaths /boot/kernel/linker.hints >>> >>> $ sudo freebsd-update fetch >>> Looking up update.FreeBSD.org mirrors... 5 mirrors found. >>> Fetching metadata signature for 8.4-RELEASE from update4.freebsd.org... done. >>> Fetching metadata index... done. >>> Inspecting system... done. >>> Preparing to download files... done. >>> >>> The following files will be updated as part of updating to 8.4-RELEASE-p12: >>> /boot/kernel/linker.hints >> >> Better reference on freebsd-questions, but it raises more questions >> than it answers: >> >> http://lists.freebsd.org/pipermail/freebsd-questions/2014-May/257950.html >> >> Specifically, multiple users appear to still be experiencing this, >> even after applying the fix for this erratum: >> >> http://www.freebsd.org/security/advisories/FreeBSD-EN-14:04.kldxref.asc > > ... and there an open PR here, with folks still unable to ignore > linker.hints, even after applying EN-14:04.kldxref. > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189249 > > ... and another thread from May 27 that went quiet after someone still > had the problem after applying the erratum fix: > > https://www.mail-archive.com/freebsd-security@freebsd.org/msg05027.html After this tzdata erratum: https://www.freebsd.org/security/advisories/FreeBSD-EN-14:10.tzdata.asc ... the list of files that is repeatedly updated but still subject to freebsd-update now includes: $ sudo freebsd-update fetch Looking up update.FreeBSD.org mirrors... 5 mirrors found. Fetching metadata signature for 8.4-RELEASE from update5.freebsd.org... done. Fetching metadata index... done. Inspecting system... done. Preparing to download files... done. The following files will be added as part of updating to 8.4-RELEASE-p18: /usr/src/share/zoneinfo/leap-seconds.list /usr/src/share/zoneinfo/zone1970.tab The following files will be updated as part of updating to 8.4-RELEASE-p18: /boot/kernel/linker.hints /usr/share/zoneinfo/Africa/Bamako /usr/share/zoneinfo/Africa/Banjul /usr/share/zoneinfo/Africa/Conakry /usr/share/zoneinfo/Africa/Dakar /usr/share/zoneinfo/Africa/Freetown /usr/share/zoneinfo/Africa/Lome /usr/share/zoneinfo/Africa/Nouakchott /usr/share/zoneinfo/Africa/Ouagadougou /usr/share/zoneinfo/Africa/Sao_Tome /usr/share/zoneinfo/Atlantic/St_Helena /usr/share/zoneinfo/Pacific/Johnston I have updated the Bugzilla PR with this information. The last PR update said that it involves is an errata notice candidate, and transferred the PR over to secteam; cc:ed. Note that the PR says that the fix is: "Please backport kldxref.c patch in PR 182098 to 8.4-RELEASE, 9.2-RELEASE & 10.0-RELEASE" Royce From owner-freebsd-stable@FreeBSD.ORG Thu Oct 23 13:57:36 2014 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 472086FD for ; Thu, 23 Oct 2014 13:57:36 +0000 (UTC) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (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 06B9DA7D for ; Thu, 23 Oct 2014 13:57:35 +0000 (UTC) Received: from 2a02-8428-011b-e000-0290-f5ff-fe9d-b78c.rev.sfr.net ([2a02:8428:11b:e000:290:f5ff:fe9d:b78c] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XhItS-000EDf-69 for freebsd-stable@freebsd.org; Thu, 23 Oct 2014 15:57:34 +0200 Message-ID: <5449094D.5010704@dumbbell.fr> Date: Thu, 23 Oct 2014 15:57:33 +0200 From: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG) References: <54451422.1070403@FreeBSD.org> <54451E2A.1020309@FreeBSD.org> <5448C010.9090709@dumbbell.fr> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rFHHLkpXQ55pO95OFQFNDcvE8U1TlNM1n" 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, 23 Oct 2014 13:57:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rFHHLkpXQ55pO95OFQFNDcvE8U1TlNM1n Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 23.10.2014 15:39, Zenny wrote: >>> 1. console switching did not work >> >> Could you please describe your problem in more detail? >=20 > You may find this reported in some of the previous threads to this list= =2E >=20 >> For instance, do you use the new vt(4) console driver, which isn't >> enabled by default? >=20 > Yep, I did enable it. Maybe I posted somewhere about this earlier to > this mailing list and tried to make it work for some three months, > failed and absorbed to gnu/linux again. Yes, probably another thread because I can't find the information in this one. Many bugs were fixed in vt(4) in the past two months. If you're willing to try FreeBSD again, please get back to us to tell if it's working for you or not. --=20 Jean-S=C3=A9bastien P=C3=A9dron --rFHHLkpXQ55pO95OFQFNDcvE8U1TlNM1n 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 iQJ8BAEBCgBmBQJUSQlNXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTMbyQP/jNSeuJ5bErT6Mj9rdxvLeJh rZSEEJJrz9TBzQ/QKKT4APipUnwWvhyT5YrzCn4Xp9cyAykvzaFV8XcskfMaHbht 1D2iVdMcVB+RNZOiP+Zyco552AEad6xFXqJ//t3r27JKZFLwpanFnDOkcg6kMjJv L73TCAlH5/uyd3XkHF8qx/cTZ2+BnZIcssb6Op0vQZwctTbci7nPQSmHEo1H3+0z BFR7NCE8UyyuVxe8INUpjYU0NtM7VJe94qmHHq+lvSbSv/EY1pIL1LeNEg7kvNP8 D/QpRHxRRAIic++XBJXSXafX2C5O3lXzaF/oShIEWsf0dEFOJIx6R4BdEFJtKI2O tF0q8YnDSvJyEFq8Sh66TujNiV6N0da5WjZQb5PBvGbDeXbHVWWgjroiRgQrhy2U FNh2pTmpE2vd7tGyIm9qo73tH593LzXxcK1ALXA5a5mdo7HptPlD+V15Ng59w0HP pwZp+DGM8zfgjwFst35aHeVLKW1yXkiv2GEMdDcAs+uZ1LHpTaodRWlTZUpnNbR6 wkg8xWqGPn3mbq/8aB1RjVzzSu1nRBGYHOFjCWlJR/PLeabEzLuXXofJLS4fMKaq tgBCOaoqSHxqhBcBKbWHrmlESawYuaiEcH2S3Sb2BwBr1+04RqFFxfSWRluXYOIX Q4CGzxKTH3DnbqsDkfhs =5ndL -----END PGP SIGNATURE----- --rFHHLkpXQ55pO95OFQFNDcvE8U1TlNM1n-- From owner-freebsd-stable@FreeBSD.ORG Thu Oct 23 16:03:48 2014 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 79361CAD for ; Thu, 23 Oct 2014 16:03:48 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 153F6B2F for ; Thu, 23 Oct 2014 16:03:47 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id q5so1113982wiv.4 for ; Thu, 23 Oct 2014 09:03:46 -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=Ddpa/Lo7uQfps86hGQwlyiBACL0oeuVWcd9owtZdfrI=; b=ZvjqBq7klcdHtzYGfM67NysrS6zITG5wG8PhMtSY4OObjw2NMBDdsJr65gOA55SXbZ ktfP6mVGhEZTLKGoNNpkaPOhILzzr5KpCB6s2vfYl0k5X7ILEZZ2RkZg9a2xxyG/wFEO 098n0KZLumBytYEIDrtD//1+b1PfknA9g8WFk8a/hvsupH2PcxUNLZ3arkmMrX1LIJDq TIO6Ad4gZVsB3utFSS8TdkU7cGr8vx/n2oMPa8pOQ4rhQQ2UOwmcMjydVFqyJ6MF8IUe kIX5Piq8Jh+xz5WB0Kvf58d/I7TmHOkGlPKIDu27jHoom7DfONXstF7zdfw4ApG3gXyv V3Yg== MIME-Version: 1.0 X-Received: by 10.180.212.48 with SMTP id nh16mr14310663wic.50.1414080226306; Thu, 23 Oct 2014 09:03:46 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.194.220.227 with HTTP; Thu, 23 Oct 2014 09:03:46 -0700 (PDT) In-Reply-To: <5448C35C.5080600@paladin.bulgarpress.com> References: <5448C35C.5080600@paladin.bulgarpress.com> Date: Thu, 23 Oct 2014 10:03:46 -0600 X-Google-Sender-Auth: 3qKiC6I6FgJEU0JL8QNVqh4j1Ik Message-ID: Subject: Re: FreeBSD 9.1 + Supermicro IPMI + reboot = kernel crash From: Alan Somers To: Mailing lists Content-Type: text/plain; charset=UTF-8 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: Thu, 23 Oct 2014 16:03:48 -0000 On Thu, Oct 23, 2014 at 2:59 AM, Mailing lists wrote: > Hi people, > I've three machines - FreeBSD 9.1 (i386+amd64) - at reboot usually the > kernel dump and therefore gmirror rebuilds, etc. > > After reboot - kldload show the module is inserted but /dev/ipmi* is not > populated, kldunload + kldload of the module fixes the access + > /dev/ipmi* population. > > Any ideas (except upgrade which I plan to 9.3 soon)? > > +Waiting (max 60 seconds) for system process `vnlru' to stop...done > +Waiting (max 60 seconds) for system process `bufdaemon' to stop...done > + > +Waiting (max 60 seconds) for system process `syncer' to stop...Syncing > disks, vnodes remaining...9 Sleeping thread (tid 100093, pid 16) owns a > non-sleepable lock > +KDB: stack backtrace of thread 100093: > +#0 0xffffffff808f3196 at mi_switch+0x186 > +#1 0xffffffff8092bfa2 at sleepq_wait+0x42 > +#2 0xffffffff808f3926 at _sleep+0x376 > +#3 0xffffffff81551227 at ipmi_submit_driver_request+0x97 > +#4 0xffffffff815519df at ipmi_set_watchdog+0xaf > +#5 0xffffffff81551c8f at ipmi_wd_event+0x8f > +#6 0xffffffff807bbdef at kern_do_pat+0x9f > +#7 0xffffffff80984187 at sched_sync+0x1e7 > +#8 0xffffffff808bbe3f at fork_exit+0x11f > +#9 0xffffffff80bc3d9e at fork_trampoline+0xe > +panic: sleeping thread > +cpuid = 0 > +KDB: stack backtrace: > +#0 0xffffffff80920cf6 at kdb_backtrace+0x66 > +#1 0xffffffff808ead0e at panic+0x1ce > +#2 0xffffffff8092f172 at propagate_priority+0x1d2 > +#3 0xffffffff8092fe9e at turnstile_wait+0x1be > +#4 0xffffffff808d9198 at _mtx_lock_sleep+0xd8 > +#5 0xffffffff8097d9b3 at vn_syncer_add_to_worklist+0x143 > +#6 0xffffffff80981ac4 at reassignbuf+0xe4 > +#8 0xffffffff8096a232 at bdwrite+0x52 > +#7 0xffffffff809661c2 at bdirty+0x42 > +#9 0xffffffff80af4ba9 at ffs_freefile+0x269 > +#10 0xffffffff80b09711 at handle_workitem_freefile+0x101 > +#11 0xffffffff80b09ba7 at process_worklist_item+0x377 > +#12 0xffffffff80b0d8d6 at softdep_process_worklist+0x96 > +#13 0xffffffff80b0fee7 at softdep_flush+0x197 > +#14 0xffffffff808bbe3f at fork_exit+0x11f You want to pull in r272366 from head and rebuild your kernel. That change hasn't yet been MFCd to stable/9, but I don't think you'll have any trouble merging it. https://svnweb.freebsd.org/base?view=revision&revision=272366 -Alan From owner-freebsd-stable@FreeBSD.ORG Thu Oct 23 16:31:32 2014 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 D4848FB; Thu, 23 Oct 2014 16:31:32 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 397CFE25; Thu, 23 Oct 2014 16:31:32 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id bs8so2504445wib.3 for ; Thu, 23 Oct 2014 09:31:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=aniHAgiKG1EgBP+3SoreWDuYP2jvGyhhZC5UxK2Ey40=; b=zP8yFX5P2q9a9w0LKru1HfZj/3ldswBSEQoAEzVYES8E7n22er7jHdDrXc4xfsozXi 1U1IoHOodAdEBBpPkOmweJsvSAZFlVpgC6n7DlsSOyvssaZ6ucgTXMMfBNXjTY27x9RM Vt1NggY9ybO66LlRfUBwYKMb4Z71G+PNhnfcAxK0u1thHf1u8/euTdwCdW/ueuRNs+oq iZhe1x/Tb9Xdwf63h1MkgwqB5CDo5lRPanlLPmyAROzSVz5oJwXUBdMPgQG8A9W4m3qG pjKGvI6VohTzBc6nidFVHhSYlWPUpZmTxUlnYmWf9NEj6hwdOd7rsT/atg0XyBwD3xZX 1jJw== MIME-Version: 1.0 X-Received: by 10.194.61.51 with SMTP id m19mr6675394wjr.15.1414081890411; Thu, 23 Oct 2014 09:31:30 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Thu, 23 Oct 2014 09:31:30 -0700 (PDT) In-Reply-To: References: <54451422.1070403@FreeBSD.org> <54451E2A.1020309@FreeBSD.org> Date: Thu, 23 Oct 2014 09:31:30 -0700 X-Google-Sender-Auth: dgwo2YqR7-rolDfY74ZWiW6dDKA Message-ID: Subject: Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG) From: Adrian Chadd To: Zenny Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Stable Mailing List , =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= 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, 23 Oct 2014 16:31:33 -0000 Ok! Which version of PCBSD is it? I flipped the default power save state in freebsd-head to be the lowest supported by the CPU and all the more recent CPUs will idle at a much lower power level. You could try putting these into /etc/rc.conf if they aren't already there: performance_cx_lowest=3D"Cmax" economy_cx_lowest=3D"Cmax" .. and disable powerd. Would you be willing to conduct the power test without the GPUs installed? There may be something missing in FreeBSD and they may not be clocking down when idle. -a On 23 October 2014 00:51, Zenny wrote: > Hi Adrian: > > I use hardwares for both. > > For temperature, I use IR Thermogun like > http://www.amazon.com/BAFX-Products-Infrared-Thermometer-Includes/dp/B00N= I3HNQK/ref=3Dsr_1_3?ie=3DUTF8&qid=3D1414050390&sr=3D8-3&keywords=3Dinfrared= +thermometer > > For power monitor, I use a wattmeter like: > http://www.amazon.com/P3-P4400-Electricity-Usage-Monitor/dp/B00009MDBU > > Hope this clarifies! > > > > > > On 10/22/14, Adrian Chadd wrote: >> Hi! >> >> How are you measuring the CPU temperature and power consumption? >> >> Which version of PCBSD did you install? >> >> >> >> -a >> >> >> On 21 October 2014 23:25, Zenny wrote: >>> Even with new xorg, two things didn't work with my Radeon 3 head cards: >>> >>> 1. console switching did not work >>> 2. hdmi audio did not work. >>> >>> Tried also with PCBSD, the same results. I gave up and installed linux >>> in the same machine, both worked fine in addition to: >>> >>> 1. booting time is very fast >>> 2. thermal management is better (usually the cpu temps are 31-40 in >>> linux default installation whereas the temp remains in the range of up >>> to 49-63 with all the tweaks performed.) >>> 3. Power consumption is lower in linux than freebsd (76watts compared >>> to 126watts till the xorg started) >>> >>> These are some of the stuffs that needs to be addressed despite >>> freebsd being overwhelmingly stable. >>> >>> On 10/20/14, Jean-S=C3=A9bastien P=C3=A9dron wro= te: >>>> On 20.10.2014 15:54, Jean-S=C3=A9bastien P=C3=A9dron wrote: >>>>> On 20.10.2014 14:16, Pete French wrote: >>>>>>> What version of FreeBSD do you use? >>>>>> >>>>>> 9.2 >>>>> >>>>> You're right, there seems to be something wrong. I'll discuss this wi= th >>>>> the graphics team. >>>> >>>> Koop Mast just committed a fix to the Ports tree. >>>> >>>> -- >>>> Jean-S=C3=A9bastien P=C3=A9dron >>>> >>>> >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.or= g" >> From owner-freebsd-stable@FreeBSD.ORG Thu Oct 23 17:42:52 2014 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 03C04B96 for ; Thu, 23 Oct 2014 17:42:52 +0000 (UTC) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (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 B62DB7B1 for ; Thu, 23 Oct 2014 17:42:51 +0000 (UTC) Received: from 2a02-8428-011b-e000-0290-f5ff-fe9d-b78c.rev.sfr.net ([2a02:8428:11b:e000:290:f5ff:fe9d:b78c] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XhMPR-000Gjr-ON for freebsd-stable@freebsd.org; Thu, 23 Oct 2014 19:42:49 +0200 Message-ID: <54493E14.6000500@dumbbell.fr> Date: Thu, 23 Oct 2014 19:42:44 +0200 From: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG) References: <54451422.1070403@FreeBSD.org> <54451E2A.1020309@FreeBSD.org> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qIS3r0OjUKJHKuSrVR7PXBmHf8p2d8iuB" 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, 23 Oct 2014 17:42:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qIS3r0OjUKJHKuSrVR7PXBmHf8p2d8iuB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 23.10.2014 18:31, Adrian Chadd wrote: > Would you be willing to conduct the power test without the GPUs > installed? There may be something missing in FreeBSD and they may not > be clocking down when idle. Our Radeon kernel driver doesn't support power management. This feature was first added to Linux 3.11 (we're at 3.8) and was considered stable 3 or 4 releases later. This means that, currently, the card's clock and voltage are the factory boot-time defaults. For most cards, they are low and the card has poor performance, compared to Windows/Linux. For a few exceptions, the card is running at its maximum, leading to high temperatures and fans spinning fast. --=20 Jean-S=C3=A9bastien P=C3=A9dron --qIS3r0OjUKJHKuSrVR7PXBmHf8p2d8iuB 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 iQJ8BAEBCgBmBQJUST4ZXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTMEXEP/3aLjfEivTUOsdfH17pCYtF6 wYFaSMTj2iDUq+GUEDKsYuA5OvZ4ic+7YZkCjy9/AXavJRlSNPbFggf148jocyJr v3Akf9JFxcKBKD1WOIoYc7IskCZqZqoWWjn1SNWdvksEEF728U+NyGM8WuwqCmlJ ZVSG3rqyGs8McNTEwgloxVZFlzppERcCcmakkmYUyLKif/CvQa4GKgs2dDc8oXco jW+81bHwBJLNrh9pBmdnOUWzLOr71IGkWVY5RGHWkC4pmnOJqDC010y7fbgD3nWK H5RWodgSRwQnFnj+Wgi3rv01uLEs8mWgId2bNaW1VPTOqIdIso3u90ShKAa9+mFT MrH29R1qSDGg01u73n8qY7foYi3T8tcqvec1UKaHqUtVCMoaSiJoi6PB60eaKDg3 IfknSVd6kXJosGtevdRw9+nrjmIy2Ox+LzozbRHq7OD4CueDAUmlVXGWi2vPHLYA yHsXJr1hXaKQInKI2g/kZQlRPTTf1AhKgxXTGF5Ny/XGe8zRQfDFDyzl0SVzytuX I59RmAkNXCmxRqGT7+4hQFptDJ9Bzz5Zwk69IJc1R2poU8VhSH8WHSUGwdaX00+3 FhMdacLUpHqW8Zn5g0dXoXgUAo9/cET7T0LWu1uQTmq4p95T9z3/nmWZCHV8o80y B3z7kcyttUD7ARrwAeYY =tIqo -----END PGP SIGNATURE----- --qIS3r0OjUKJHKuSrVR7PXBmHf8p2d8iuB-- From owner-freebsd-stable@FreeBSD.ORG Thu Oct 23 17:56:56 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6C649F44; Thu, 23 Oct 2014 17:56:55 +0000 (UTC) Date: Thu, 23 Oct 2014 17:56:51 +0000 From: Glen Barber To: freebsd-stable@FreeBSD.org Subject: FreeBSD 10.1-RC3 Now Available Message-ID: <20141023175651.GA8074@hub.FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD Release Engineering Team 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, 23 Oct 2014 17:56:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The third RC build of the 10.1-RELEASE release cycle is now available on the FTP servers for the amd64, armv6, i386, ia64, powerpc, powerpc64 and sparc64 architectures. The image checksums follow at the end of this email. Installer images and memory stick images are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.1/ If you notice problems you can report them through the Bugzilla PR system or on the -stable mailing list. If you would like to use SVN to do a source based update of an existing system, use the "releng/10.1" branch. A list of changes since 10.0-RELEASE are available here: https://www.freebsd.org/releases/10.1R/relnotes.html Important note to those upgrading from previous -RC or -BETA builds: An API incompatibility was discovered between 10.0-RELEASE and 10.1-RC2 which was reverted prior to 10.1-RC3 builds, and the libopie.so shared library version was changed from '8' back to '7' in the releng/10.1 branch. Please be sure to rebuild any third party software that depends on this shared library before removing the incorrect version with freebsd-update(8) or source-based upgrades with 'make delete-old-libs'. Important note to ZFS users on the i386 architecture: A regression has been discovered that affects multi-disk (mirror, raidz-1, raidz-2, etc.) installations that may cause a kernel panic on boot. If using a multi-disk ZFS setup, adding 'options KSTACK_PAGES=4' to the kernel configuration is observed to resolve the problem. Please *do* *not* upgrade your system with freebsd-update(8) if using a multi-disk ZFS setup, since this will override the kernel configuration with the GENERIC kernel. Some of the changes between 10.1-RC2 and 10.1-RC3 include: o Several fixes to the UDPLite protocol implementation. o The vt(4) driver has been updated to save and restore keyboard mode and LED states when switching windows. o Several fixes to the SCTP protocol implementation. o A potential race condition in obtaining a file pointer has been corrected. o Fix ZFS ZVOL deadlock and rename issues. o Restore libopie.so ABI compatibility with 10.0-RELEASE. o Removed the last vestige of MD5 password hashes. o Several rc(8) script updates and fixes. o bsdinstall(8) has been updated to allow selecting local_unbound in the default services to enable at first boot. o Prevent ZFS leaking pool free space. o Fix rtsold(8) remote buffer overflow vulnerability. [SA-14:20] o Fix routed(8) remote denial of service vulnerability. [SA-14:21] o Fix memory leak in sandboxed namei lookup. [SA-14:22] o OpenSSL has been updated to version 1.0.1j. [SA-14:23] o Fix an issue where a FreeBSD virtual machine provisioned in the Microsoft Azure service does not recognize the second attached disk on the system. Pre-installed virtual machine images for 10.1-RC2 are also available for amd64 and i386 architectures. The images are located here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/VM-IMAGES/10.1-RC3/ The disk images are available in QCOW2, VHD, VMDK, and raw disk image formats. The image download size is approximately 135 MB, which decompress to a 20GB sparse image. The partition layout is: . 512k - freebsd-boot GPT partition type (bootfs GPT label) . 1GB - freebsd-swap GPT partition type (swapfs GPT label) . ~17GB - freebsd-ufs GPT partition type (rootfs GPT label) Note to consumers of the dvd1.iso image: The packages included on the dvd will not be recognized by bsdconfig(8), and the cause is being investigated. The packages, however, can be installed manually. To install packages from the dvd1.iso installer, create and mount the /dist directory: # mkdir -p /dist # mount -t cd9660 /dev/cd0 /dist Next, install pkg(8) from the DVD: # env REPOS_DIR=/dist/packages/repos \ pkg bootstrap At this point, pkg-install(8) can be used to install additional packages from the DVD. Please note, the REPOS_DIR environment variable should be used each time using the DVD as the package repository, otherwise conflicts with packages from the upstream mirrors may occur when they are fetched. For example, to install Gnome and Xorg, run: # env REPOS_DIR=/dist/packages/repos \ pkg install xorg-server xorg gnome2 [...] The freebsd-update(8) utility supports binary upgrades of amd64 and i386 systems running earlier FreeBSD releases. Systems running earlier FreeBSD releases can upgrade as follows: # freebsd-update upgrade -r 10.1-RC3 During this process, freebsd-update(8) may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install It is recommended to rebuild and install all applications if possible, especially if upgrading from an earlier FreeBSD release, for example, FreeBSD 8.x. Alternatively, the user can install misc/compat9x and other compatibility libraries, afterwards the system must be rebooted into the new userland: # shutdown -r now Finally, after rebooting, freebsd-update needs to be run again to remove stale files: # freebsd-update install == ISO CHECKSUMS == o 10.1-RC3 amd64 GENERIC: SHA256 (FreeBSD-10.1-RC3-amd64-bootonly.iso) = b3d9062c354f9f993839a2abd6308e4bd7a8e0311e5dc63bf1609266e94b65d5 SHA256 (FreeBSD-10.1-RC3-amd64-bootonly.iso.xz) = 3cbadbd51c7c9ef22882c2ad58463909c1838002422eb89f24b5b225a39d8eac SHA256 (FreeBSD-10.1-RC3-amd64-disc1.iso) = 19bf2d44437f16a34a85ec6f12c9e041204520f958326efb2d6047ae79fde3bb SHA256 (FreeBSD-10.1-RC3-amd64-disc1.iso.xz) = 48f18cb7b8b3a4930f0a172d8ca59708f6200a1b5073a8e3343198e0cb8fc95b SHA256 (FreeBSD-10.1-RC3-amd64-dvd1.iso) = fe658c7d6ab58eb409c901260d862ba50d32564f6442ae53a71e56ece1d0139b SHA256 (FreeBSD-10.1-RC3-amd64-dvd1.iso.xz) = 704923caf8587edd92d920759f8c1d222f8d12a11ae5579a6f25c473a1f8798a SHA256 (FreeBSD-10.1-RC3-amd64-memstick.img) = 24b8d36a1931f9f0fa49d0747375e5ba139a5525086c4380e662acc84a1d7780 SHA256 (FreeBSD-10.1-RC3-amd64-memstick.img.xz) = 19fdf5fb6b2fb25fe5672c08b9989dabfc3624602c991b1ffde5aa9ca652bac5 SHA256 (FreeBSD-10.1-RC3-amd64-mini-memstick.img) = 2028e27b0dc4297852deb9e9ac549e568ff695099e431bcd9fdb21174f9931a7 SHA256 (FreeBSD-10.1-RC3-amd64-mini-memstick.img.xz) = b57228e2961a23c73b3278f4d70588f9c24d0267a11d1b97d42db72e9b01e791 SHA256 (FreeBSD-10.1-RC3-amd64-uefi-bootonly.iso) = 3d20cce00696a4e587851ca08fd56c1e253e8a7ea4b497740fb0da70d1794dd7 SHA256 (FreeBSD-10.1-RC3-amd64-uefi-bootonly.iso.xz) = 2297dc064e877c380598897bb3f4506c33ad36024b967ebb326d10ed6874f987 SHA256 (FreeBSD-10.1-RC3-amd64-uefi-disc1.iso) = bcedf15bd6a2a494a183c4c49a012557842d5819fb9a6fe456ff6e22151cd87a SHA256 (FreeBSD-10.1-RC3-amd64-uefi-disc1.iso.xz) = bd82e6be3f8dac6ae752a12bc6a38e6154f3e8586664eadf62aaa63368e4da63 SHA256 (FreeBSD-10.1-RC3-amd64-uefi-dvd1.iso) = f3930ee575d322c61d00a4a1c2c192cc848bf8b60cc8f9740ace1ae04f3650e4 SHA256 (FreeBSD-10.1-RC3-amd64-uefi-dvd1.iso.xz) = c8662a99cdc2920ae2296466234561f3ba1557722ff7a7b16c34ec767de9816d SHA256 (FreeBSD-10.1-RC3-amd64-uefi-memstick.img) = 664af393ad14e647d8f1487eff3be2c7f1dbed21a0f47ca0b2bf01166be0e8c8 SHA256 (FreeBSD-10.1-RC3-amd64-uefi-memstick.img.xz) = 5d42bcab1399981b03a4504114074feaf458fa4b1f49853f3c5424e407a60cd5 SHA256 (FreeBSD-10.1-RC3-amd64-uefi-mini-memstick.img) = 22ab77e908d6a863b3da10c4d006bb6f4bd5a675841ed809703bc93f95e4aac2 SHA256 (FreeBSD-10.1-RC3-amd64-uefi-mini-memstick.img.xz) = 6bf1f42e9af9b99fba996175a634ce11fb196f947e70b7381e672b2507303a61 MD5 (FreeBSD-10.1-RC3-amd64-bootonly.iso) = 0d2bd2f1c4575ccb031de61596e7c2f1 MD5 (FreeBSD-10.1-RC3-amd64-bootonly.iso.xz) = e02ec035a4b91a9c7f80e672999405b9 MD5 (FreeBSD-10.1-RC3-amd64-disc1.iso) = 95e7e7b72467249d80e0a50cb2a90ef8 MD5 (FreeBSD-10.1-RC3-amd64-disc1.iso.xz) = 63c183ee3130c3bb981a36ed622ded36 MD5 (FreeBSD-10.1-RC3-amd64-dvd1.iso) = 88914f55f35193bd9b68b451edd1570f MD5 (FreeBSD-10.1-RC3-amd64-dvd1.iso.xz) = 82e40000c4d395cf83d1553ee38418d4 MD5 (FreeBSD-10.1-RC3-amd64-memstick.img) = e3d5ed7938616829ad7d328d33912b85 MD5 (FreeBSD-10.1-RC3-amd64-memstick.img.xz) = 74362707fb92b926c1fc76bde86eb17d MD5 (FreeBSD-10.1-RC3-amd64-mini-memstick.img) = 57c9b6bee4271fb542bd5e6867544ea4 MD5 (FreeBSD-10.1-RC3-amd64-mini-memstick.img.xz) = 8897d290260e10b4ce159cf35c5a7600 MD5 (FreeBSD-10.1-RC3-amd64-uefi-bootonly.iso) = 9bf92ddf7208a3a4221179a0b625d088 MD5 (FreeBSD-10.1-RC3-amd64-uefi-bootonly.iso.xz) = 2e16ab7c97461878c398440e206f48b4 MD5 (FreeBSD-10.1-RC3-amd64-uefi-disc1.iso) = 186d7934fab75f558be44943f8f8f863 MD5 (FreeBSD-10.1-RC3-amd64-uefi-disc1.iso.xz) = 8ad15ed8d9b3e5578d55e7691b766ec6 MD5 (FreeBSD-10.1-RC3-amd64-uefi-dvd1.iso) = 0101fe8d0b5409c39d23485b75d9590d MD5 (FreeBSD-10.1-RC3-amd64-uefi-dvd1.iso.xz) = 338d3b8c297528f2945ef247eddf8e5f MD5 (FreeBSD-10.1-RC3-amd64-uefi-memstick.img) = 003d3f690c8150a53140677bea39a6b2 MD5 (FreeBSD-10.1-RC3-amd64-uefi-memstick.img.xz) = 1f67e441a8947eaafe2e3596cc14bedc MD5 (FreeBSD-10.1-RC3-amd64-uefi-mini-memstick.img) = 4df7c9197355499ac3fd6b53c23f536f MD5 (FreeBSD-10.1-RC3-amd64-uefi-mini-memstick.img.xz) = 3d0e28575996965116865d23c7e54026 o 10.1-RC3 i386 GENERIC: SHA256 (FreeBSD-10.1-RC3-i386-bootonly.iso) = 7243b2617cd4cb36903442aa233cee76baabd9677543b31934a82f6cd79adcaf SHA256 (FreeBSD-10.1-RC3-i386-bootonly.iso.xz) = 5936e73e8cf21482f683fa275577fd2f4f6c1a2d4f76b7e6066833ffd9ca2132 SHA256 (FreeBSD-10.1-RC3-i386-disc1.iso) = f43aeddede90f5e059ce45b59ae37ad1536aaab856e045d45215b549fcfc7619 SHA256 (FreeBSD-10.1-RC3-i386-disc1.iso.xz) = c7b2dce10db19a5f6e944b02688f1d1a92bff08b7605b59218fede1306a57032 SHA256 (FreeBSD-10.1-RC3-i386-dvd1.iso) = 2938994818040935a9f43990caf01172f6377257f0039e94d27982e010daf279 SHA256 (FreeBSD-10.1-RC3-i386-dvd1.iso.xz) = 4f670fdaba03bb1e9174c03fbd7b952d257f47ea5b04434fb289f0665031cdee SHA256 (FreeBSD-10.1-RC3-i386-memstick.img) = c1ef4e3ce005223cc89581d37735f7a0f73e6d956edcfded14d680598503f98d SHA256 (FreeBSD-10.1-RC3-i386-memstick.img.xz) = 2fc7bdaf7c78c11be08625edf2c07e3c1f0d35488541dca356d69e8ed5241ea4 SHA256 (FreeBSD-10.1-RC3-i386-mini-memstick.img) = 5bd38de7870edba05f4fb66c03282615d5532dd690c31be0c9b48e2333506e00 SHA256 (FreeBSD-10.1-RC3-i386-mini-memstick.img.xz) = 84646fd14b48aaec42c33dc4917a507042cc3e4e9ef63bc179e653651aea4c04 MD5 (FreeBSD-10.1-RC3-i386-bootonly.iso) = de3537c2da1b73b28ae53c9501f48ee3 MD5 (FreeBSD-10.1-RC3-i386-bootonly.iso.xz) = 2e845b0f128cdf3132dace90c9526489 MD5 (FreeBSD-10.1-RC3-i386-disc1.iso) = 54db997ee6e45a3eb4fc98a79c0f2b31 MD5 (FreeBSD-10.1-RC3-i386-disc1.iso.xz) = dc0beca6af06f1c53bf5a89d4e5bc4be MD5 (FreeBSD-10.1-RC3-i386-dvd1.iso) = 2976f1772de60e98c629b44f16c36a90 MD5 (FreeBSD-10.1-RC3-i386-dvd1.iso.xz) = 264e33935ba7056e3122619c46d13b99 MD5 (FreeBSD-10.1-RC3-i386-memstick.img) = c67b208d7b21add13cc5402076bd0560 MD5 (FreeBSD-10.1-RC3-i386-memstick.img.xz) = 1305d5473a6dabcb6a40910274e4020b MD5 (FreeBSD-10.1-RC3-i386-mini-memstick.img) = 39917b2b66da7a05a95923a5ec2b6a0d MD5 (FreeBSD-10.1-RC3-i386-mini-memstick.img.xz) = dc2cfd45096a6de4fefdd310f6e34fa4 o 10.1-RC3 ia64 GENERIC: SHA256 (FreeBSD-10.1-RC3-ia64-bootonly.iso) = 5197c09d8d36efb2a3fbd70a847a94caa889e4466e5070fb67c21d2d8d9fa084 SHA256 (FreeBSD-10.1-RC3-ia64-bootonly.iso.xz) = 9abd909d7f94cfdbea52611dd4a8c6e3dc4a5e59bc2c36ea6390692a2a8c8202 SHA256 (FreeBSD-10.1-RC3-ia64-disc1.iso) = 75df3d37a31939035e6f66c26e04f389d4debd392b9732338834acdd6e6a8f19 SHA256 (FreeBSD-10.1-RC3-ia64-disc1.iso.xz) = 8fdc4bf92179db9908b9695e2c9ff34673d07520af4ead3c961a4e3769cd4efe SHA256 (FreeBSD-10.1-RC3-ia64-memstick.img) = 775a34cab4b96d597fd1e605ff1f43e059634e4982279cd71d9069d66093a490 SHA256 (FreeBSD-10.1-RC3-ia64-memstick.img.xz) = d7e3325935a5b175fd5950680d21f03ed48eea2fc6e68f36b0acfcd31c48a581 SHA256 (FreeBSD-10.1-RC3-ia64-mini-memstick.img) = 35f7be2e95405ac9f14076e9376a2e1d4b57376f4ab15b2caf7949f968d9ba60 SHA256 (FreeBSD-10.1-RC3-ia64-mini-memstick.img.xz) = 7e877f2283edb8139c6465eece874d78384ea2a8d682891bcb3b8d4b08b2e771 MD5 (FreeBSD-10.1-RC3-ia64-bootonly.iso) = 94674b28335fdc505505565be335e681 MD5 (FreeBSD-10.1-RC3-ia64-bootonly.iso.xz) = 372c98d8f356b6da9fc59b41c0420569 MD5 (FreeBSD-10.1-RC3-ia64-disc1.iso) = 655c466815347d225f364ff8a443631a MD5 (FreeBSD-10.1-RC3-ia64-disc1.iso.xz) = c8ec18785dc4e0c6ca25f4da29041d6f MD5 (FreeBSD-10.1-RC3-ia64-memstick.img) = 42b027ab402456f336d654c1b7a24891 MD5 (FreeBSD-10.1-RC3-ia64-memstick.img.xz) = eb5c8f325d0cf58d4a4f3ff592cbd1f8 MD5 (FreeBSD-10.1-RC3-ia64-mini-memstick.img) = 5e624fb1ab1483c5ad4ed1e2f397e055 MD5 (FreeBSD-10.1-RC3-ia64-mini-memstick.img.xz) = 6a20b117dd66c59a99433d174295ccf6 o 10.1-RC3 powerpc GENERIC: SHA256 (FreeBSD-10.1-RC3-powerpc-bootonly.iso) = bc3da306da33e0f98d107e89121d792078485a5e12565067c66d61240a33f670 SHA256 (FreeBSD-10.1-RC3-powerpc-bootonly.iso.xz) = 200c07a3ab08d5a830403d8a5c64f60db1910e0379b9f1862ac02cf82f34c1b0 SHA256 (FreeBSD-10.1-RC3-powerpc-disc1.iso) = 0571162ca14ebd5b36363bd0d9d1810126349d49f8c69d2a9162710b6a603519 SHA256 (FreeBSD-10.1-RC3-powerpc-disc1.iso.xz) = cf71f2d4cf5aaca51f55d2b9af89be8f0acebf396fbe3eeecd75fffc650c497a SHA256 (FreeBSD-10.1-RC3-powerpc-memstick.img) = 7e9e093735938790bf3c1c31a02b2a5d1f7d0f414848714362e1f5f55a2475d0 SHA256 (FreeBSD-10.1-RC3-powerpc-memstick.img.xz) = 94e293f699151e5d9265df113c443e477a8113d6af8f2b54fadbf5c259f645f4 SHA256 (FreeBSD-10.1-RC3-powerpc-mini-memstick.img) = 19325046dd76261fc78229c467ad6121d381d79bcb2b15067ea2b100f56052ed SHA256 (FreeBSD-10.1-RC3-powerpc-mini-memstick.img.xz) = d917be1f10a3356dc6dbabb8ef791ef8a16ddf951bb019f1f08783367545910a MD5 (FreeBSD-10.1-RC3-powerpc-bootonly.iso) = e555857e89257ede11f2ebf13a641f37 MD5 (FreeBSD-10.1-RC3-powerpc-bootonly.iso.xz) = d9c8c595c5fb128f68013469d2512ba1 MD5 (FreeBSD-10.1-RC3-powerpc-disc1.iso) = 4bfaec08bddb23e7f9d4bf5cd1698ee4 MD5 (FreeBSD-10.1-RC3-powerpc-disc1.iso.xz) = af73eb65fc9d3b9774745794e42c637d MD5 (FreeBSD-10.1-RC3-powerpc-memstick.img) = d29394c38b6a86455c8e0460eefd0a4a MD5 (FreeBSD-10.1-RC3-powerpc-memstick.img.xz) = a25260b97c49886960729344c949b849 MD5 (FreeBSD-10.1-RC3-powerpc-mini-memstick.img) = 2095eaace3cd7f2a901239210b3e0fac MD5 (FreeBSD-10.1-RC3-powerpc-mini-memstick.img.xz) = c6a36ba73b48fd1f74cdb12506ecb214 o 10.1-RC3 powerpc64 GENERIC64: SHA256 (FreeBSD-10.1-RC3-powerpc-powerpc64-bootonly.iso) = a8c87bd4b185c1c5f3fd884d666ee5c8d74fb7b906136b3e3fc25f77c4c343cd SHA256 (FreeBSD-10.1-RC3-powerpc-powerpc64-bootonly.iso.xz) = 9eb4f51cee928ecde9ce1e460461f12c53c4d9895ff776f276711e2807bf87e2 SHA256 (FreeBSD-10.1-RC3-powerpc-powerpc64-disc1.iso) = 9c703dd5563175ff406849978b03d75842845befa2147c54933cfcc26acbc669 SHA256 (FreeBSD-10.1-RC3-powerpc-powerpc64-disc1.iso.xz) = f215fd8e0028e1a9cbb9de1ec1e4ba6db159130ebfe8fd815f77545606492f36 SHA256 (FreeBSD-10.1-RC3-powerpc-powerpc64-memstick.img) = 1a24def2cb6754d8dc0d0261ade75bec931cc8ce77ec9bed7e889c63664a71b9 SHA256 (FreeBSD-10.1-RC3-powerpc-powerpc64-memstick.img.xz) = 643f9d625901d6ec8f59a0abd203ef4f4ee9fe85edeee1c7a495f2f448cddeb8 SHA256 (FreeBSD-10.1-RC3-powerpc-powerpc64-mini-memstick.img) = 00ab3b65b0d1fbcfa49d7c8d581e5c52e5c5b5ebeae3d10472667252f4612702 SHA256 (FreeBSD-10.1-RC3-powerpc-powerpc64-mini-memstick.img.xz) = df9db724556266792797b69b49f9dc79b099bc636327a79ae49e5763a1b09360 MD5 (FreeBSD-10.1-RC3-powerpc-powerpc64-bootonly.iso) = 742eb41e90818879273f38b86c1176b1 MD5 (FreeBSD-10.1-RC3-powerpc-powerpc64-bootonly.iso.xz) = c6e42bdf3bd9b3e5feb428f227d3f756 MD5 (FreeBSD-10.1-RC3-powerpc-powerpc64-disc1.iso) = 5ef4e51215e4a7b64da2533e5a47548f MD5 (FreeBSD-10.1-RC3-powerpc-powerpc64-disc1.iso.xz) = 558e38f20b80b451411d92daa14b6773 MD5 (FreeBSD-10.1-RC3-powerpc-powerpc64-memstick.img) = e878e6f92472c2ab720ed09da666b112 MD5 (FreeBSD-10.1-RC3-powerpc-powerpc64-memstick.img.xz) = bdff57d1dfa97298f999c2a8e06ef02a MD5 (FreeBSD-10.1-RC3-powerpc-powerpc64-mini-memstick.img) = 3e6068f5a38020e6458aaf5e18ebb08a MD5 (FreeBSD-10.1-RC3-powerpc-powerpc64-mini-memstick.img.xz) = e53504e152d017d05084ea64bec4bbb5 o 10.1-RC3 sparc64 GENERIC: SHA256 (FreeBSD-10.1-RC3-sparc64-bootonly.iso) = fd75126e0eda97a15104933dd424813a38e823d572a0ce78423790730c5881d3 SHA256 (FreeBSD-10.1-RC3-sparc64-bootonly.iso.xz) = 9032228a4fc1448b5ddcc106f34dc52fe98628f552925a33e584a49439d466f4 SHA256 (FreeBSD-10.1-RC3-sparc64-disc1.iso) = 0bb0d7af2a4fae28cc6d8600ec4024bbf60e2fe90dc2d98faf7c08d3d0cfd696 SHA256 (FreeBSD-10.1-RC3-sparc64-disc1.iso.xz) = ddfdf0855d4bde84037ed9cfb9aa547189fdcaff7216fb67f36a309858184deb MD5 (FreeBSD-10.1-RC3-sparc64-bootonly.iso) = c8a66bf2be1a6f1103af58c4d768be28 MD5 (FreeBSD-10.1-RC3-sparc64-bootonly.iso.xz) = 235a45494d91ab8c58af87975550894a MD5 (FreeBSD-10.1-RC3-sparc64-disc1.iso) = e76c0c097fcf103668b6ed6567861ade MD5 (FreeBSD-10.1-RC3-sparc64-disc1.iso.xz) = 4c41d7411d7d29a58e304b7848f9591f o 10.1-RC3 armv6 BEAGLEBONE: SHA256 (FreeBSD-10.1-RC3-arm-armv6-BEAGLEBONE.img.bz2) = 25c8c8236164c4569cbdbd7c493eecbd90ef482959aac9e4e4a140cca9bf073c MD5 (FreeBSD-10.1-RC3-arm-armv6-BEAGLEBONE.img.bz2) = be73ab1a4cdec79e3ca78f5a90054704 o 10.1-RC3 armv6 RPI-B: SHA256 (FreeBSD-10.1-RC3-arm-armv6-RPI-B.img.bz2) = 04c51a1b1e824a28cb0c407d06e0176cf25ee98db473492e5744b6736a16ba10 MD5 (FreeBSD-10.1-RC3-arm-armv6-RPI-B.img.bz2) = f8f9ab5434a8fa3285218441e4a6e5e1 o 10.1-RC3 armv6 PANDABOARD: SHA256 (FreeBSD-10.1-RC3-arm-armv6-PANDABOARD.img.bz2) = 7d3433dc9468d2eb1e949d4e7f114693cb42670fa78c0cc48452783915a3ce31 MD5 (FreeBSD-10.1-RC3-arm-armv6-PANDABOARD.img.bz2) = 5b9496c01ffe7cc6c0d6443497cbaaa4 o 10.1-RC3 armv6 ZEDBOARD: SHA256 (FreeBSD-10.1-RC3-arm-armv6-ZEDBOARD.img.bz2) = a25e20a682029c05cb08b21ba6ed45afdaab50e157cca30a9005b730238801be MD5 (FreeBSD-10.1-RC3-arm-armv6-ZEDBOARD.img.bz2) = 5a2a6b8700f4de25294bffb0c72180b0 == VM IMAGE CHECKSUMS == o 10.1-RC3 amd64: SHA256 (FreeBSD-10.1-RC3-amd64.qcow2.xz) = d54f8d8046f6c0f3a1931936b20f89261081cbed188ccf19ecaee7945675e566 SHA256 (FreeBSD-10.1-RC3-amd64.raw.xz) = ff789c9e9699d79aedc83a94c3ac8731a1d9aaddbc87b6577718d0caa355f7fd SHA256 (FreeBSD-10.1-RC3-amd64.vhd.xz) = 50c17ef72a17c7effed03cd8fb3177b8d678f25b0b42692dec23a4b53c1d969f SHA256 (FreeBSD-10.1-RC3-amd64.vmdk.xz) = e68987bc91c691f73d85d495a6237be29ab05d46f43b9bbc6dbe7da765e3bd17 MD5 (FreeBSD-10.1-RC3-amd64.qcow2.xz) = 2b5f312d41f412a4355be09cc65b5c87 MD5 (FreeBSD-10.1-RC3-amd64.raw.xz) = c2627f8b1e8dd3910d8cba1d0899f6f2 MD5 (FreeBSD-10.1-RC3-amd64.vhd.xz) = 8feee79f0c2ff92f53d0928864c7d54b MD5 (FreeBSD-10.1-RC3-amd64.vmdk.xz) = e7a4bf097addb73482ac6a83580c13eb o 10.1-RC3 i386: SHA256 (FreeBSD-10.1-RC3-i386.qcow2.xz) = a919f0e74487df9e437fc117c7a634247a688c6fc610d0690b2f6bb506d38aac SHA256 (FreeBSD-10.1-RC3-i386.raw.xz) = 73822dcb4bb734c3c3dbef4457f861e7859d85bb3f010bcdf3ceb3a9a83bbfc0 SHA256 (FreeBSD-10.1-RC3-i386.vhd.xz) = 81663437f4e06875e1887a43010942d620e6d663007ddd28fcfebc740cddc498 SHA256 (FreeBSD-10.1-RC3-i386.vmdk.xz) = 6571484e6e7c65345582e009d0a9d5b47ade83543c9272aa4ec4bb7039ba9c39 MD5 (FreeBSD-10.1-RC3-i386.qcow2.xz) = 6c6b740f9f10a7b27f8c3e50c5ce1842 MD5 (FreeBSD-10.1-RC3-i386.raw.xz) = f0dd77f28d258afaa4e3a44d033b1765 MD5 (FreeBSD-10.1-RC3-i386.vhd.xz) = 02291015fad4f75ef613f4677727147b MD5 (FreeBSD-10.1-RC3-i386.vmdk.xz) = 34ad33ac37f6271e4e533fcdd985a4f5 Glen Love FreeBSD? Support this and future releases with a donation to the FreeBSD Foundation! https://www.freebsdfoundation.org/donate/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUSUFjAAoJEAMUWKVHj+KToJMP/Az6GeRiChefNkWZxH2Kpzpq 1jsIY12gy78UYc/XO55HURJ/9LMo4ZrsSg69DSoSMv6dO/aIWmmfnboylA3A/N2U RpJmPIcOr8gTi2cnX0TCDi0sK6r5uX6FWS2vphoasnb+2iZScs1rCAkGMWyIBR5l a1T45+lSgsmbHkxE1hZ1d60ymHveijtPN5+wVuX9BdF0TGdVJqPqdV7Z4lq4I+se EWzbVK8JS4srDUxHhdVHfVLnYkVawxYMNCSZofqwY4PAFScakH0egEuLarEJcefV oVef7zagaZIdrgaodeSri+PiLBcwcJ+W36lCPvlSfH087RbDg2JTkbD8wW7W4G8Y nwHKfTaiVALOyp50f4IrjTon3ZwMy4xjZfDSM8XSTPBYKyK3MHGX03mCS29FNVqY wZMWEhBumXMS/Xgl+Mc88BRbsoI9vTXdzRbpUW7mp8WA3mQji+vioItpFJEjvkpi WxvoUu6fhGRwKPPEWIF9mwTsJEjDddBTWO7HNJ4g8Zv0E1b0qfuktsAsD0V3bxYo HeTHemwfGyAyxyFJr+yEYBRvUj6199rWotoy3sX4Xys/41BoyoX+vLx5DFdCOpFo l+Ywzm8NDk63sj6zN35nMDcvvhFv3boCxd+ZkJRQiswumWlG9LZHdBV/7XYZly7k nQPdMMtF37i6RssEHfF8 =hsl2 -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Thu Oct 23 18:53:17 2014 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 CA3527A0 for ; Thu, 23 Oct 2014 18:53:17 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5150DF38 for ; Thu, 23 Oct 2014 18:53:16 +0000 (UTC) Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s9NIrDZj085144 for ; Thu, 23 Oct 2014 20:53:13 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id B9C343AE0; Thu, 23 Oct 2014 20:53:12 +0200 (CEST) Message-ID: <54494E92.5010007@omnilan.de> Date: Thu, 23 Oct 2014 20:53:06 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: FreeBSD Stable Subject: sa(4) 9.2->10.1, nsa0.0: request ptr 0x803135040 is not on a page boundary; cannot split request X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2D651D67AA87269C43222F2C" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Thu, 23 Oct 2014 20:53:13 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) 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, 23 Oct 2014 18:53:18 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2D651D67AA87269C43222F2C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, I read about the changes in sa(4) regarding large-block-split changes and the transitional 'kern.cam.sa.allow_io_split' workarround. I'm using bacula (7.0.5) and my previous neccessarry multi-blocking adjustmets like "Minimum block size =3D 2097152" obviously didn't work with FreebSD 10.1 anymore. Good news is, they are not needed any more! With the default of 126 blocks (64512) I get 60-140MB/s with btape(8)'s speed test on my LTO4 (HH) drive and another quick test showed that using mbuffer(1) for zfs(8) 'send' isn't needed anymore (| dd of=3D/dev/nsa0 bs=3D64512 seems to max out LTO4 speed). [with FreeBSD 9 t= he transfer rates were some magnitudes lower with these block size settings!= ] Not so good news is, that bacula can't read the tape's label. 'Labeling a tape (with 'label' at bconsole(8) or btape(8)) is successful, and btape(8)'s 'readlabel' partially displays the correct label, but not the very beginning of the label: Volume Label: Id : **error**VerNo =E2=80=A6rest OK While it should read: Volume Label: Id : Bacula 1.0 immortal VerNo : 11 =E2=80=A6 When btape(8) starts to read the label, the _subject's error is reported_= : *nsa0.0: request ptr 0x803135040 is not on a page boundary; cannot split request* The same error show up if I configure bacula to use a fixed block size of kern.cam.sa.0.maxio (131072). Like expected, allowing split (with kern.cam.sa.allow_io_split in loader.conf) works arround that problem. But I'd like to understand why I cannot set kern.cam.sa.0.maxio resp. why btape(8) doesn't work 100% correct although blocksize < sa.0.maxio I don't have enough understanding to check the code myself, if it's a cam/sa(4) issue in FreeBSD or a problem in btape(8) (and also bacula itself, most likely the tool shares the code with bacula's storage deamon= ). Any hints highly appreciated! Thanks, -Harry --------------enig2D651D67AA87269C43222F2C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlRJTpgACgkQLDqVQ9VXb8hS2gCbBzaY5pEUAV0KeZNsS35E0csp 9ioAnjm5xMdwI9zfy4+6irsBPvL2tGmT =3X8L -----END PGP SIGNATURE----- --------------enig2D651D67AA87269C43222F2C-- From owner-freebsd-stable@FreeBSD.ORG Thu Oct 23 19:30:26 2014 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 31F3C719; Thu, 23 Oct 2014 19:30:26 +0000 (UTC) Received: from mail.prolet.org (mail.prolet.org [195.24.42.5]) (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 DD937392; Thu, 23 Oct 2014 19:30:25 +0000 (UTC) Received: from amorphis.prolet.org (localhost [127.0.0.1]) by mail.prolet.org (Postfix) with ESMTP id 7B4D23380C80; Thu, 23 Oct 2014 22:30:22 +0300 (EEST) X-Virus-Scanned: amavisd-new at mail.prolet.org Received: from mail.prolet.org ([127.0.0.1]) by amorphis.prolet.org (amorphis.prolet.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxV7OoF64jMV; Thu, 23 Oct 2014 22:30:17 +0300 (EEST) Received: from [192.168.10.16] (unknown [77.70.57.248]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.prolet.org (Postfix) with ESMTPSA id 23BA63380C78; Thu, 23 Oct 2014 22:30:17 +0300 (EEST) Message-ID: <54495748.7090604@paladin.bulgarpress.com> Date: Thu, 23 Oct 2014 22:30:16 +0300 From: Mailing lists User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Alan Somers Subject: Re: FreeBSD 9.1 + Supermicro IPMI + reboot = kernel crash References: <5448C35C.5080600@paladin.bulgarpress.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: Thu, 23 Oct 2014 19:30:26 -0000 Hi Alan, appreciated! Todor On 10/23/2014 07:03 PM, Alan Somers wrote: > On Thu, Oct 23, 2014 at 2:59 AM, Mailing lists > wrote: >> Hi people, >> I've three machines - FreeBSD 9.1 (i386+amd64) - at reboot usually the >> kernel dump and therefore gmirror rebuilds, etc. >> >> After reboot - kldload show the module is inserted but /dev/ipmi* is not >> populated, kldunload + kldload of the module fixes the access + >> /dev/ipmi* population. >> >> Any ideas (except upgrade which I plan to 9.3 soon)? >> >> +Waiting (max 60 seconds) for system process `vnlru' to stop...done >> +Waiting (max 60 seconds) for system process `bufdaemon' to stop...done >> + >> +Waiting (max 60 seconds) for system process `syncer' to stop...Syncing >> disks, vnodes remaining...9 Sleeping thread (tid 100093, pid 16) owns a >> non-sleepable lock >> +KDB: stack backtrace of thread 100093: >> +#0 0xffffffff808f3196 at mi_switch+0x186 >> +#1 0xffffffff8092bfa2 at sleepq_wait+0x42 >> +#2 0xffffffff808f3926 at _sleep+0x376 >> +#3 0xffffffff81551227 at ipmi_submit_driver_request+0x97 >> +#4 0xffffffff815519df at ipmi_set_watchdog+0xaf >> +#5 0xffffffff81551c8f at ipmi_wd_event+0x8f >> +#6 0xffffffff807bbdef at kern_do_pat+0x9f >> +#7 0xffffffff80984187 at sched_sync+0x1e7 >> +#8 0xffffffff808bbe3f at fork_exit+0x11f >> +#9 0xffffffff80bc3d9e at fork_trampoline+0xe >> +panic: sleeping thread >> +cpuid = 0 >> +KDB: stack backtrace: >> +#0 0xffffffff80920cf6 at kdb_backtrace+0x66 >> +#1 0xffffffff808ead0e at panic+0x1ce >> +#2 0xffffffff8092f172 at propagate_priority+0x1d2 >> +#3 0xffffffff8092fe9e at turnstile_wait+0x1be >> +#4 0xffffffff808d9198 at _mtx_lock_sleep+0xd8 >> +#5 0xffffffff8097d9b3 at vn_syncer_add_to_worklist+0x143 >> +#6 0xffffffff80981ac4 at reassignbuf+0xe4 >> +#8 0xffffffff8096a232 at bdwrite+0x52 >> +#7 0xffffffff809661c2 at bdirty+0x42 >> +#9 0xffffffff80af4ba9 at ffs_freefile+0x269 >> +#10 0xffffffff80b09711 at handle_workitem_freefile+0x101 >> +#11 0xffffffff80b09ba7 at process_worklist_item+0x377 >> +#12 0xffffffff80b0d8d6 at softdep_process_worklist+0x96 >> +#13 0xffffffff80b0fee7 at softdep_flush+0x197 >> +#14 0xffffffff808bbe3f at fork_exit+0x11f > You want to pull in r272366 from head and rebuild your kernel. That > change hasn't yet been MFCd to stable/9, but I don't think you'll have > any trouble merging it. > > https://svnweb.freebsd.org/base?view=revision&revision=272366 > > -Alan > _______________________________________________ > 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" From owner-freebsd-stable@FreeBSD.ORG Thu Oct 23 22:30:14 2014 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 AADBD400; Thu, 23 Oct 2014 22:30:14 +0000 (UTC) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BA0EAB50; Thu, 23 Oct 2014 22:30:13 +0000 (UTC) Received: by mail-la0-f46.google.com with SMTP id gi9so1704324lab.33 for ; Thu, 23 Oct 2014 15:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=/5fqvNvE/qdXl+isJp4pGo9u4qWhv3pR10hD+WYUvRE=; b=bNc8/R4fGAYwoTexq4fMoSUj1U/wgQ5WY3kuf4WXaC8t3F5jwPuv+Vx3i7liDMqJr+ DUksZTXY8/Arf3lmuqQEvAwl8FlkQiRMN0RSPfCoeiCptoQndikPuvr39NDHtrs9A5xe jtGnqBa+kJZwAVf8WgKDiNtfttlu6XG+Ob7GQVvxybL9NFwZ1gjT2IXjZ2vu/p6srDM4 6PjiyhblmqUwqbyv2156oJLC+C+n8wE2XL4VPE9psR+ZzdsKK/Q8Ghy/6nAHl2lflbuh Jzjd24oPpLFfagvlQDv5ElIFRXDaoCa0K9+kCfKKfdARlrdE7YJ7csC2XJvoxWumwebq H4Rg== MIME-Version: 1.0 X-Received: by 10.152.42.172 with SMTP id p12mr438220lal.11.1414103411024; Thu, 23 Oct 2014 15:30:11 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.84.197 with HTTP; Thu, 23 Oct 2014 15:30:10 -0700 (PDT) In-Reply-To: References: Date: Thu, 23 Oct 2014 15:30:10 -0700 X-Google-Sender-Auth: Vjq-Kaj1UQORJRV-k9cUp2U4-Mw Message-ID: Subject: Re: Automatically running /usr/tests on stable/10 branch under Jenkins From: Craig Rodrigues To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-testing@freebsd.org" , FreeBSD stable , "freebsd-virtualization@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, 23 Oct 2014 22:30:14 -0000 Garrett Cooper wrote: > > Hi Craig! > As much as everyone would like to take i386 out to pasture, > there's a large degree of value in running i386 tests on 11-CURRENT and > 10-STABLE (I've caught some interesting build bugs and test bugs by running > on my i386/CURRENT VM). Are there any plans to have i386 executors running > tests anytime soon (does bhyve support i386?)? > We (jenkins-admin@freebsd.org) have been busy the 5 months since BSDCan 2014 as you can see by our status report, which lists what we have done, and what our future plans are: https://www.freebsd.org/news/status/report-2014-07-2014-09.html#Jenkins-Continuous-Integration-for-FreeBSD Integrating Jenkins with Kyua on amd64 was a major milestone which was achieved, and was even mentioned on the Jenkins web site: http://jenkins-ci.org/content/freebsd-project-use-jenkins-os-testing Now, where to take this further (such as i386) is an interesting question. Personally, I would like to see: -> integration of automated kyua testing with the FreeBSD release engineering process -> more involvement from FreeBSD developers, and even companies such as EMC/Isilon, who can: -> write tests -> suggest and implement new tests (network, storage, VM, etc.) -> help with devops maintenance of the existing jenkins.freebsd.org cluster -> improve bhyve support in libvirt -> set up their own Jenkins build environments outside of FreeBSD, and help test things in their own private environments I've had requests for; -> running tests in bhyve VM's with very small memory footprints (Adrian Chadd) -> running tests in MIPS environment (Adrian Chadd) -> running Java JDK tests (Kip Macy) -> i386 builds (Garrett Cooper) There are a lot of different directions to take this, but without more people (and companies) pitching in and helping out, progress is limited by bodies working on the stuff. I will be at the MeetBSD Vendor summit (not the conference) Nov. 3-4, so hopefully anyone interested in pushing this stuff forward can talk to me there. -- Craig From owner-freebsd-stable@FreeBSD.ORG Fri Oct 24 03:31:28 2014 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 7423A981; Fri, 24 Oct 2014 03:31:28 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 32A77C42; Fri, 24 Oct 2014 03:31:27 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 0731E63E88; Fri, 24 Oct 2014 03:31:25 +0000 (UTC) Message-ID: <5449C81B.8080008@freebsd.org> Date: Thu, 23 Oct 2014 23:31:39 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-virtualization@freebsd.org, freebsd-testing@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Automatically running /usr/tests on stable/10 branch under Jenkins References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EO7bdR25mcpewkJ1lSwKXBRl5VclR2krx" 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, 24 Oct 2014 03:31:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EO7bdR25mcpewkJ1lSwKXBRl5VclR2krx Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2014-10-23 18:30, Craig Rodrigues wrote: > Garrett Cooper wrote: >=20 >> >> Hi Craig! >> As much as everyone would like to take i386 out to pasture, >> there's a large degree of value in running i386 tests on 11-CURRENT an= d >> 10-STABLE (I've caught some interesting build bugs and test bugs by ru= nning >> on my i386/CURRENT VM). Are there any plans to have i386 executors run= ning >> tests anytime soon (does bhyve support i386?)? >> >=20 >=20 > We (jenkins-admin@freebsd.org) have been busy the 5 months since BSDCan= > 2014 as > you can see by our status report, which lists what we have done, and wh= at > our future plans are: >=20 > https://www.freebsd.org/news/status/report-2014-07-2014-09.html#Jenkins= -Continuous-Integration-for-FreeBSD >=20 > Integrating Jenkins with Kyua on amd64 was a major milestone which was > achieved, and > was even mentioned on the Jenkins web site: >=20 > http://jenkins-ci.org/content/freebsd-project-use-jenkins-os-testing >=20 > Now, where to take this further (such as i386) is an interesting questi= on. >=20 > Personally, I would like to see: > -> integration of automated kyua testing with the FreeBSD release > engineering process > -> more involvement from FreeBSD developers, and even companies such= as > EMC/Isilon, > who can: > -> write tests > -> suggest and implement new tests (network, storage, VM, et= c.) > -> help with devops maintenance of the existing > jenkins.freebsd.org cluster > -> improve bhyve support in libvirt > -> set up their own Jenkins build environments outside of > FreeBSD, and help test things in their own private environments >=20 > I've had requests for; > -> running tests in bhyve VM's with very small memory footprints > (Adrian Chadd) > -> running tests in MIPS environment (Adrian Chadd) > -> running Java JDK tests (Kip Macy) > -> i386 builds (Garrett Cooper) >=20 > There are a lot of different directions to take this, but without more > people (and companies) pitching in and helping out, > progress is limited by bodies working on the stuff. >=20 > I will be at the MeetBSD Vendor summit (not the conference) Nov. 3-4, s= o > hopefully > anyone interested in pushing this stuff forward can talk to me there. >=20 > -- > Craig > _______________________________________________ > freebsd-virtualization@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to "freebsd-virtualization-unsubscribe@fr= eebsd.org" >=20 At the Cambridge Dev Summit, Xinuous specifically mentioned helping with testing and writing tests. Might be good people to reach out to --=20 Allan Jude --EO7bdR25mcpewkJ1lSwKXBRl5VclR2krx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJUScgeAAoJEJrBFpNRJZKfOSoP/RjL9wJCyl04M0OHCmXb5n0f sUbbElAF+Us4URbVNPVG5mVZooKT5Dl5WFm5uEjXHkzXXRbK24IPere4Tn46H3uw BB4AW9gmOcOxSOEYtghATIzLhBI+UkEZxLJrhKyQIMZFVg9P7hm2TC9wjUc6S/d3 Z6x+bd/ukh0ojRfAXaZ3oLVV2N/uAIgIOGAkDk34WApF8EjFwEO33dt035qO7/n4 OmgP3J2JvprEM2HKvYfgnDUpvYHz/DgJAoRaW0vTD2OK6yDuCF8ROIiBOI7gvl9M NKFUP4Wa8zIUF4u+WtqJ7x1yyDnvRhe/8Z63aSdcbITQ19nSX8YvQ0wCbpXScOgf 5lCkolSBolSNDsNeILVu3f4JV5/N8QwCV/9B1XuzGN98+cZiLLoqvXwkkz3HscZR QXwYlqVTP0VlJ9Z4yZMKjVEKwzYpzTwNR30shpIMhhLyzJVeAOAutaEhkTVuPEci 2H5jcCssQlCGBs24gSsl8yh5sN/pz2RmSa2t8OOFMtYCKpmYtZxs5XEObeNqI+qo Vseu8+zqAMFh59sRBdynp9BYzIY0vlHhJgklSDT8PBGECBvR7X0w8S9Pg4efjGaq YHs+4yoDMMQklap3dLJoqzeHsbrDfKy+30YTbx8UfB+ffrA8er1uLMJnlOzfqGR0 IMSS1NRGiP++uUgKIbFO =U9+b -----END PGP SIGNATURE----- --EO7bdR25mcpewkJ1lSwKXBRl5VclR2krx-- From owner-freebsd-stable@FreeBSD.ORG Fri Oct 24 04:20:11 2014 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 4EF5457F; Fri, 24 Oct 2014 04:20:11 +0000 (UTC) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 457A9FD6; Fri, 24 Oct 2014 04:20:10 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id 10so1931539lbg.28 for ; Thu, 23 Oct 2014 21:20:08 -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=a4h/yTVcb77Uzncemt6arDYRCSWVMJfN6seay5CYQZY=; b=VbmeUbQHCEuXpBDenR4ge+Lw69ZZKtTspwJV0Z28I/sVoI4mqAejvxNA/f9MtErN3R aOVX//GGg/bTzArUSC9bTtgdl76jnW6WIlkArpmCW0f60/GnwOVGdLssIEcRUFqjgkaU 2uw/Wcr8LBp9RXsVL7/proGlHIAUPcqUt02WfCfHkrB1+aEja2Ly1f9OxOtX9evhWIEU drYgSWVGChpwGzQP/MCYlBCTsDX/2hsAM3CH6veQc6OQSoO6fv6Y5ybAZc0gTmURVB/1 nWMijJM9fWG1nVqK7fg/EGx3qDMP1BoVnZpN136+KIZBXRWHG56zeyAJv1GvFv0H7Z6Z mSGA== MIME-Version: 1.0 X-Received: by 10.152.27.38 with SMTP id q6mr90580lag.92.1414124408058; Thu, 23 Oct 2014 21:20:08 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.84.197 with HTTP; Thu, 23 Oct 2014 21:20:07 -0700 (PDT) In-Reply-To: <5449C81B.8080008@freebsd.org> References: <5449C81B.8080008@freebsd.org> Date: Thu, 23 Oct 2014 21:20:07 -0700 X-Google-Sender-Auth: nnY3939Gop-kkXhmr88BME7waH4 Message-ID: Subject: Re: Automatically running /usr/tests on stable/10 branch under Jenkins From: Craig Rodrigues To: Allan Jude Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-testing@freebsd.org" , FreeBSD stable , "freebsd-virtualization@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, 24 Oct 2014 04:20:11 -0000 On Thu, Oct 23, 2014 at 8:31 PM, Allan Jude wrote: > > At the Cambridge Dev Summit, Xinuous specifically mentioned helping with > testing and writing tests. Might be good people to reach out to > Are you referring to Eric Le Blan from Xinuous who was interviewed on BSDNow ( http://www.bsdnow.tv/episodes/2014_08_20-engineering_nginx , starting at 0:16:38 )? -- Craig From owner-freebsd-stable@FreeBSD.ORG Fri Oct 24 05:36:43 2014 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 564D6DCC; Fri, 24 Oct 2014 05:36:43 +0000 (UTC) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 70D01932; Fri, 24 Oct 2014 05:36:42 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id n3so332698wiv.1 for ; Thu, 23 Oct 2014 22:36:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=7+pxbGFZibruIx59JPm4doCZlK817jtqLwwip/wT9QM=; b=tcMuKDzTsWFWq8GbT08dE3SKrXwylP37kShX6LyB9CrHeMXbQ/6y6oA3cW2gv81SSu Kr131k/7p5qxekmI9fofwbDdpJtKEiva/fvVAUppqLVf3CDfWYigNvXgph0VTw+ur3mB b3souRl9t78ke8NVcIa/UpCtrBfm7IcALsvP6dlcQPID9pIgKlrd63vulsSTtF+oyAIC O0ZsYsnO/O9RAeP0t0yNhAdXSm87O7XLZw4rvIJnmeeHPQ2jRdCBVXZqSGzJFYD1dSjY gwGxvDF3o0LuFJytvalSVxRJtk5bCoaKZvNwsr07GsyhIAtN70Y3qE3zH5DJQGF3K103 dX8g== X-Received: by 10.180.205.162 with SMTP id lh2mr1688937wic.14.1414129000784; Thu, 23 Oct 2014 22:36:40 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id hg14sm735728wib.24.2014.10.23.22.36.39 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 23 Oct 2014 22:36:39 -0700 (PDT) Date: Fri, 24 Oct 2014 07:36:36 +0200 From: Mateusz Guzik To: Craig Rodrigues Subject: Re: Automatically running /usr/tests on stable/10 branch under Jenkins Message-ID: <20141024053636.GH11222@dft-labs.eu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-testing@freebsd.org" , FreeBSD stable , "freebsd-virtualization@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, 24 Oct 2014 05:36:43 -0000 On Sun, Oct 12, 2014 at 11:14:45PM -0700, Craig Rodrigues wrote: > Hi, > > I have created this Jenkins job, which you can see a graphical > representation of: > > https://jenkins.freebsd.org/jenkins/view/FreeBSD_src_stable/job/FreeBSD_stable_10/848/BuildGraph/ > It is noted below stuff is being done this for current as well and in that light: > (1) does a buildworld/buildkernel on amd64 when someone checks new > code into the stable/10 branch Is not this excessive? I would suggest every N commits or M hours if there were not enough commits to reach given threshold. Of course no work in there were no commits whatsoever, but then do the work after the first which gets in. > (2) Creates a bootable UFS image with makefs any chance zfs will be used as well? > (3) Boots the image under bhyve > (4) Runs these commands inside the bhyve VM: > > cd /usr/tests > kyua test > kyua report-junit --output=test-output.xml would be nice to run some kind of stress testing. buildworld with a high -j is an example of a general purpose test. This could be done with different frequency than regular tests. > > (5) Shuts down the bhyve VM Do you have crashdumps configured in case stuff goes wrong? > (6) imports test-output.xml into Jenkins. > > You can see a full test report here: > > https://jenkins.freebsd.org/jenkins/job/FreeBSD_stable_10-tests/4/testReport/ > > We already do the same thing for CURRENT. > > Hopefully by running the tests regularly, we can help improve the quality > of FreeBSD. > > > -- > Craig > _______________________________________________ > freebsd-virtualization@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to "freebsd-virtualization-unsubscribe@freebsd.org" -- Mateusz Guzik From owner-freebsd-stable@FreeBSD.ORG Fri Oct 24 06:06:32 2014 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 476A76B7; Fri, 24 Oct 2014 06:06:32 +0000 (UTC) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D239DBF6; Fri, 24 Oct 2014 06:06:31 +0000 (UTC) Received: by mail-yh0-f53.google.com with SMTP id z6so2969534yhz.12 for ; Thu, 23 Oct 2014 23:06:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=/fyOPRnYYCIbhxYMFn8WZMuaLqU4ZjEzzlTJRglH0go=; b=wGMvK3AYzPLenHX6lV4ZTx8TgweK0+XZ/vLRSfQWCUiZlEEMB1CaHYYQV00F5md5iQ 2I9buxIeXEqZYBmYmfIEH4fOJDWXX7aCSk2sbezLEt59Pb1DNR5ImFtiJQgCKS/CZtkY iIr6R0xUOES3DUchUH1HdQLZ3+YkfzuJsSlQC8xxRrDhioyfXHEvw0ykELrTW6lJutoj Ez2cGkUUhqn2Hvn+Cc36SVmMzNVG9AFiM7Tyb1mhHHhGatbjdclZvyTUrF57kubHKs3h dMRoRw9KDjR33XV4hrNWqSU8j8yf8pKgq6wat1PPg4F19X5FKpQiwKw+QJhOtS0a0web ic0A== MIME-Version: 1.0 X-Received: by 10.170.74.85 with SMTP id q82mr3009680ykq.119.1414130790985; Thu, 23 Oct 2014 23:06:30 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.170.82.197 with HTTP; Thu, 23 Oct 2014 23:06:30 -0700 (PDT) In-Reply-To: <20141024053636.GH11222@dft-labs.eu> References: <20141024053636.GH11222@dft-labs.eu> Date: Thu, 23 Oct 2014 23:06:30 -0700 X-Google-Sender-Auth: oQccbWzenSL947pHPPmkGKERUgE Message-ID: Subject: Re: Automatically running /usr/tests on stable/10 branch under Jenkins From: "K. Macy" To: Mateusz Guzik Content-Type: text/plain; charset=UTF-8 Cc: Craig Rodrigues , "freebsd-testing@freebsd.org" , FreeBSD stable , "freebsd-virtualization@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, 24 Oct 2014 06:06:32 -0000 >> (2) Creates a bootable UFS image with makefs > > any chance zfs will be used as well? > Seconded. There are residual locking issues issues in ZFS. Particularly in the less exercised areas. >> (5) Shuts down the bhyve VM > > Do you have crashdumps configured in case stuff goes wrong? Along those same lines, do you have any sort of watchdog in case it deadlocks? -K From owner-freebsd-stable@FreeBSD.ORG Fri Oct 24 08:57:08 2014 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 325A89AE for ; Fri, 24 Oct 2014 08:57:08 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E94A5DD6 for ; Fri, 24 Oct 2014 08:57:07 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Xhag1-0006Y0-36; Fri, 24 Oct 2014 10:56:59 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "FreeBSD Stable" , "Tim Daneliuk" Subject: Re: /usr/lib/pam_opie.so.5: Shared object "libopie.so.8" not found References: <5447EFD2.9000609@tundraware.com> <5447F802.6010600@tundraware.com> Date: Fri, 24 Oct 2014 10:56:51 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <5447F802.6010600@tundraware.com> User-Agent: Opera Mail/12.17 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: -- X-Spam-Score: -2.9 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=disabled version=3.3.2 X-Scan-Signature: 448baf4759cd3283a5930955cc61e1db 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, 24 Oct 2014 08:57:08 -0000 On Wed, 22 Oct 2014 20:31:30 +0200, Tim Daneliuk wrote: > On 10/22/2014 01:16 PM, Ronald Klop wrote: >> On Wed, 22 Oct 2014 19:56:34 +0200, Tim Daneliuk >> wrote: >> >>> I mentioned this yesterday and someone suggested a fix had been >>> committed ... >>> Well, not so much as of FreeBSD 10.1-PRERELEASE #2 r273434. >>> >>> This is still breaking cron and saslauthd, for example. >>> >>> The workaround is an appropriate entry in /usr/local/etc/libmap.d of >>> the form: >>> >>> libopie.so.8 libopie.so.7 >>> >>> >> >> Rebuild the port for saslauthd so it will pick up the right version of >> libopie >> again. > > > The particular error I saw was from cron, so doing what you suggest will > not > fix all use cases. /usr/sbin/cron is not directly linked to libopie. $ ldd -a /usr/sbin/cron /usr/sbin/cron: libpam.so.5 => /usr/lib/libpam.so.5 (0x20043000) libutil.so.9 => /lib/libutil.so.9 (0x20057000) libc.so.7 => /lib/libc.so.7 (0x20071000) /usr/lib/libpam.so.5: libc.so.7 => /lib/libc.so.7 (0x20071000) /lib/libutil.so.9: libc.so.7 => /lib/libc.so.7 (0x20071000) But depending on your pam configuration some dependency might be dynamically loaded. Like this: $ ldd -a /usr/lib/pam_opie.so.5 /usr/lib/pam_opie.so.5: libopie.so.7 => /usr/lib/libopie.so.7 (0x801602000) libpam.so.5 => /usr/lib/libpam.so.5 (0x80180b000) libc.so.7 => /lib/libc.so.7 (0x80081f000) /usr/lib/libopie.so.7: libmd.so.6 => /lib/libmd.so.6 (0x801a17000) libc.so.7 => /lib/libc.so.7 (0x80081f000) /usr/lib/libpam.so.5: libc.so.7 => /lib/libc.so.7 (0x80081f000) /lib/libmd.so.6: libc.so.7 => /lib/libc.so.7 (0x80081f000) So rebuild those and things should be resolved again. Ronald. From owner-freebsd-stable@FreeBSD.ORG Fri Oct 24 09:46:14 2014 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 8C26D4B4; Fri, 24 Oct 2014 09:46:14 +0000 (UTC) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2FB84368; Fri, 24 Oct 2014 09:46:14 +0000 (UTC) Received: by mail-yh0-f53.google.com with SMTP id z6so9578yhz.40 for ; Fri, 24 Oct 2014 02:46:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=0NVyIy+0TkFwshd4VesyLvcmFIDsNiKKEon5CJmoXZE=; b=aPtXVr9FVrBbhAG40aWOVfAnsoEv1RhOFBeWkOm3kFnTFKdHk4Kf/WWmV0dMiNexqh tk6rJB0mO3w+9Fu7j4zHUrQCtgxrBBEYBglhu6jA+odGAkAkqDy5w5+5McFeX/QEIZK2 iUPpBj1byfFGDwooMDzrUg9xG4B/wfB2YKdSmtRRXubvjh20Hujpxt2cbV5FZi+A5v3v KepMHasCDhFMwk6jbIdkeb0J0Vd3BwTuLB2ttHWyrfeME50I8s2wcqZ5hxDT/tD23r50 5imrWTZasgbKsdUYjVDzi3VEJ8cdkX62hd+rn1T8lVyFmiyiQUDh917eIP1LI2lor1xk P1mA== MIME-Version: 1.0 X-Received: by 10.170.162.86 with SMTP id e83mr997172ykd.113.1414143973211; Fri, 24 Oct 2014 02:46:13 -0700 (PDT) Received: by 10.140.220.7 with HTTP; Fri, 24 Oct 2014 02:46:13 -0700 (PDT) In-Reply-To: References: <54451422.1070403@FreeBSD.org> <54451E2A.1020309@FreeBSD.org> Date: Fri, 24 Oct 2014 11:46:13 +0200 Message-ID: Subject: Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG) From: Zenny To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Stable Mailing List , =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= 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, 24 Oct 2014 09:46:14 -0000 On 10/23/14, Adrian Chadd wrote: > Ok! > > Which version of PCBSD is it? > > I flipped the default power save state in freebsd-head to be the > lowest supported by the CPU and all the more recent CPUs will idle at > a much lower power level. > > You could try putting these into /etc/rc.conf if they aren't already ther= e: > > performance_cx_lowest=3D"Cmax" > economy_cx_lowest=3D"Cmax" > > .. and disable powerd. This has been tested and tried without any improvements, fyi. Every tweak under the sky has been done, but no go. :-( > > Would you be willing to conduct the power test without the GPUs > installed? There may be something missing in FreeBSD and they may not > be clocking down when idle. > > > -a > > > On 23 October 2014 00:51, Zenny wrote: >> Hi Adrian: >> >> I use hardwares for both. >> >> For temperature, I use IR Thermogun like >> http://www.amazon.com/BAFX-Products-Infrared-Thermometer-Includes/dp/B00= NI3HNQK/ref=3Dsr_1_3?ie=3DUTF8&qid=3D1414050390&sr=3D8-3&keywords=3Dinfrare= d+thermometer >> >> For power monitor, I use a wattmeter like: >> http://www.amazon.com/P3-P4400-Electricity-Usage-Monitor/dp/B00009MDBU >> >> Hope this clarifies! >> >> >> >> >> >> On 10/22/14, Adrian Chadd wrote: >>> Hi! >>> >>> How are you measuring the CPU temperature and power consumption? >>> >>> Which version of PCBSD did you install? >>> >>> >>> >>> -a >>> >>> >>> On 21 October 2014 23:25, Zenny wrote: >>>> Even with new xorg, two things didn't work with my Radeon 3 head cards= : >>>> >>>> 1. console switching did not work >>>> 2. hdmi audio did not work. >>>> >>>> Tried also with PCBSD, the same results. I gave up and installed linux >>>> in the same machine, both worked fine in addition to: >>>> >>>> 1. booting time is very fast >>>> 2. thermal management is better (usually the cpu temps are 31-40 in >>>> linux default installation whereas the temp remains in the range of up >>>> to 49-63 with all the tweaks performed.) >>>> 3. Power consumption is lower in linux than freebsd (76watts compared >>>> to 126watts till the xorg started) >>>> >>>> These are some of the stuffs that needs to be addressed despite >>>> freebsd being overwhelmingly stable. >>>> >>>> On 10/20/14, Jean-S=C3=A9bastien P=C3=A9dron wr= ote: >>>>> On 20.10.2014 15:54, Jean-S=C3=A9bastien P=C3=A9dron wrote: >>>>>> On 20.10.2014 14:16, Pete French wrote: >>>>>>>> What version of FreeBSD do you use? >>>>>>> >>>>>>> 9.2 >>>>>> >>>>>> You're right, there seems to be something wrong. I'll discuss this >>>>>> with >>>>>> the graphics team. >>>>> >>>>> Koop Mast just committed a fix to the Ports tree. >>>>> >>>>> -- >>>>> Jean-S=C3=A9bastien P=C3=A9dron >>>>> >>>>> >>>> _______________________________________________ >>>> 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" >>> > From owner-freebsd-stable@FreeBSD.ORG Fri Oct 24 09:46:53 2014 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 5B3855A7 for ; Fri, 24 Oct 2014 09:46:53 +0000 (UTC) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1932F37C for ; Fri, 24 Oct 2014 09:46:53 +0000 (UTC) Received: by mail-qg0-f49.google.com with SMTP id e89so641840qgf.22 for ; Fri, 24 Oct 2014 02:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=9vVuGvb11vSrJCb83owLtClgr9T4yRjuCYvQDsRYVdo=; b=nd9G8G0DtnmPiFhR+M7msfsXS88eloLGPIizAYPzxrqi/zWWVnpLQbhokH5N8EcQpT ZFK2hXiUjnq7UWDOT+8mMeW112G8fTNzvHyE19/w4aQdu0samQTk+Ec4+bJe45TZ0T6A zgLTEH/Pnk4eEuGuEeHZUnnZbwX0h832PZ4hLSKL7s8G08Lta7mZXp7/8HipEdO4eXx3 DdeTeKdMlrRY3htTp3i2+ljxyFBTTsC3DI8Vzui1Y+z+t64BtRkB+EA8Jb/dr6mlXLa6 I7FgoznFP+4FFMp5/ML6qrEy391v5+56aJqvbf25aLvaO71ky9yeIS/Mtqud1NJmasW9 m1Jw== MIME-Version: 1.0 X-Received: by 10.170.199.138 with SMTP id q132mr4962516yke.17.1414144012223; Fri, 24 Oct 2014 02:46:52 -0700 (PDT) Received: by 10.140.220.7 with HTTP; Fri, 24 Oct 2014 02:46:52 -0700 (PDT) In-Reply-To: <54493E14.6000500@dumbbell.fr> References: <54451422.1070403@FreeBSD.org> <54451E2A.1020309@FreeBSD.org> <54493E14.6000500@dumbbell.fr> Date: Fri, 24 Oct 2014 11:46:52 +0200 Message-ID: Subject: Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG) From: Zenny To: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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, 24 Oct 2014 09:46:53 -0000 On 10/23/14, Jean-S=C3=A9bastien P=C3=A9dron wrote: > On 23.10.2014 18:31, Adrian Chadd wrote: >> Would you be willing to conduct the power test without the GPUs >> installed? There may be something missing in FreeBSD and they may not >> be clocking down when idle. > > Our Radeon kernel driver doesn't support power management. This feature > was first added to Linux 3.11 (we're at 3.8) and was considered stable 3 > or 4 releases later. > > This means that, currently, the card's clock and voltage are the factory > boot-time defaults. For most cards, they are low and the card has poor > performance, compared to Windows/Linux. For a few exceptions, the card > is running at its maximum, leading to high temperatures and fans > spinning fast. Yep, this sounds to be the reason of the problem, I guess. > > -- > Jean-S=C3=A9bastien P=C3=A9dron > > From owner-freebsd-stable@FreeBSD.ORG Fri Oct 24 11:14:32 2014 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 5FBF5B2E for ; Fri, 24 Oct 2014 11:14:32 +0000 (UTC) Received: from m2j4.x.rootbsd.net (pirzyk.org [IPv6:2607:fc50:1:5900:216:3eff:fe10:3498]) (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 2F43418D for ; Fri, 24 Oct 2014 11:14:32 +0000 (UTC) Received: from [192.168.1.126] (c-50-165-9-144.hsd1.il.comcast.net [50.165.9.144]) (authenticated bits=0) by m2j4.x.rootbsd.net (8.14.7/8.14.7) with ESMTP id s9OBEQmB070268 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 24 Oct 2014 06:14:28 -0500 (CDT) (envelope-from pirzyk@freeBSD.org) From: Jim Pirzyk Content-Type: multipart/signed; boundary="Apple-Mail=_6C668A53-ADFE-48D4-A336-3F2E0CC379E6"; protocol="application/pgp-signature"; micalg=pgp-sha256 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-14:11.crypt Date: Fri, 24 Oct 2014 06:14:20 -0500 References: <201410222107.s9ML7nLC010739@freefall.freebsd.org> To: freebsd-stable@freebsd.org In-Reply-To: <201410222107.s9ML7nLC010739@freefall.freebsd.org> X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.4 at pirzyk.org X-Virus-Status: Clean X-Spam-Status: No, score=-0.9 required=8.0 tests=ALL_TRUSTED,TW_SV autolearn=unavailable autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pirzyk.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, 24 Oct 2014 11:14:32 -0000 --Apple-Mail=_6C668A53-ADFE-48D4-A336-3F2E0CC379E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I was wondering if there is more information about this change? FreeBSD = changed the default away from DES to MD5 back in the 1.1.5 -> 2.0 = transition. It seems to me a downgrade and rewarding bad programming to = be changing back to DES now. Also the proper course of action is to = correct programs that make the wrong assumption about what crypt() = changes. Thanks - JimP On Oct 22, 2014, at 4:07 PM, FreeBSD Errata Notices = wrote: > Signed PGP part > = =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 > FreeBSD-EN-14:11.crypt Errata = Notice > The FreeBSD = Project >=20 > Topic: crypt(3) default hashing algorithm >=20 > Category: core > Module: libcrypt > Announced: 2014-10-22 > Affects: FreeBSD 9.3 and FreeBSD 10.0-STABLE after 2014-05-11 = and > before 2014-10-16. > Corrected: 2014-10-13 15:56:47 UTC (stable/10, 10.1-PRERELEASE) > 2014-10-16 21:39:04 UTC (releng/10.1, 10.1-RC3) > 2014-10-16 21:39:04 UTC (releng/10.1, 10.1-RC2-p2) > 2014-10-16 21:39:04 UTC (releng/10.1, 10.1-RC1-p2) > 2014-10-16 21:39:04 UTC (releng/10.1, 10.1-BETA3-p2) > 2014-10-21 21:09:54 UTC (stable/9, 9.3-STABLE) > 2014-10-21 23:50:46 UTC (releng/9.3, 9.3-RELEASE-p4) >=20 > For general information regarding FreeBSD Errata Notices and Security > Advisories, including descriptions of the fields above, security > branches, and the following sections, please visit > . >=20 > I. Background >=20 > The crypt(3) function performs password hashing. Different algorithms > of varying strength are available, with older, weaker algorithms being > retained for compatibility. >=20 > The crypt(3) function was originally based on the DES encryption > algorithm and generated a 13-character hash from an eight-character > password (longer passwords were truncated) and a two-character salt. >=20 > II. Problem Description >=20 > In recent FreeBSD releases, the default algorithm for crypt(3) was > changed to SHA-512, which generates a much longer hash than the > traditional DES-based algorithm. >=20 > III. Impact >=20 > Many applications assume that crypt(3) always returns a traditional = DES > hash, and blindly copy it into a short buffer without bounds checks. = This > may lead to a variety of undesirable results including, at worst, = crashing > the application. >=20 > IV. Workaround >=20 > No workaround is available. >=20 > V. Solution >=20 > Perform one of the following: >=20 > 1) Upgrade your system to a supported FreeBSD stable or release / = security > branch (releng) dated after the correction date. >=20 > 2) To update your present system via a source code patch: >=20 > The following patches have been verified to apply to the applicable > FreeBSD release branches. >=20 > a) Download the relevant patch from the location below, and verify the > detached PGP signature using your PGP utility. >=20 > # fetch http://security.FreeBSD.org/patches/EN-14:11/crypt.patch > # fetch http://security.FreeBSD.org/patches/EN-14:11/crypt.patch.asc > # gpg --verify crypt.patch.asc >=20 > b) Apply the patch. Execute the following commands as root: >=20 > # cd /usr/src > # patch < /path/to/patch >=20 > c) Recompile the operating system using buildworld and installworld as > described in . >=20 > Restart all deamons using the library, or reboot the system. >=20 > 3) To update your system via a binary patch: >=20 > Systems running a RELEASE version of FreeBSD on the i386 or amd64 > platforms can be updated via the freebsd-update(8) utility: >=20 > # freebsd-update fetch > # freebsd-update install >=20 > VI. Correction details >=20 > The following list contains the revision numbers of each file that was > corrected in FreeBSD. >=20 > Branch/path = Revision > = ------------------------------------------------------------------------- > stable/9/ = r273425 > releng/9.3/ = r273438 > stable/10/ = r273043 > releng/10.1/ = r273187 > = ------------------------------------------------------------------------- >=20 > To see which files were modified by a particular revision, run the > following command, replacing NNNNNN with the revision number, on a > machine with Subversion installed: >=20 > # svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base >=20 > Or visit the following URL, replacing NNNNNN with the revision number: >=20 > >=20 > VII. References >=20 > The latest revision of this Errata Notice is available at > http://security.FreeBSD.org/advisories/FreeBSD-EN-14:11.crypt.asc >=20 > _______________________________________________ > freebsd-announce@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-announce > To unsubscribe, send any mail to = "freebsd-announce-unsubscribe@freebsd.org" --- @(#) $Id: dot.signature,v 1.15 2007/12/27 15:06:13 pirzyk Exp $ __o jim@pirzyk.org = -------------------------------------------------- _'\<,_ (*)/ (*) I'd rather be out biking. --Apple-Mail=_6C668A53-ADFE-48D4-A336-3F2E0CC379E6 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 - http://gpgtools.org iFcDBQFUSjSS+2AFq07nokoRCHQtAP4nBn/msYhnsMGA/MZnyI+fjDIco8jwXGZl qim0cNo0gQD/ZcEqf87MEnyfzvHbXMdd94rpsOs6mA5xt45kVbzvnmo= =kfPf -----END PGP SIGNATURE----- --Apple-Mail=_6C668A53-ADFE-48D4-A336-3F2E0CC379E6-- From owner-freebsd-stable@FreeBSD.ORG Fri Oct 24 11:47:37 2014 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 AB36F530; Fri, 24 Oct 2014 11:47:37 +0000 (UTC) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C5DEF7AF; Fri, 24 Oct 2014 11:47:36 +0000 (UTC) Received: by mail-la0-f50.google.com with SMTP id s18so2497127lam.37 for ; Fri, 24 Oct 2014 04:47:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=sykNOvpM5+mZLnFfIrj340EFktUQ/g0P7iElpYoRH5Q=; b=ZX9Mm4jvMeYjuc0Csakx7ROX73lc1VMK8d/T0J/Vyi/YNSLxAlOnwPmHL/w3Z4yzgn UrDxhstSJI9JusAiIct1PsyxyO/JiZ7+WngMKidc+JfrtX6J8tq1cvIbsMtJ5CxdX0Vj ArJiDYFDMUBKMXyeBQRikXvRiaR1yCpDv/pqarkz2zZdAUjtmNxJu7SVs3Tu9Q60dpvq shs33cyKexJ2/ezZOZEzHTtjhwwLe8FDObFJ00GXDg8UMbKrDl22FIs1FlAHuUeSxHGF YQrCloDEN7EwYfVrfBUfn2uBAEYo4ljqSXP+eWmx8kz1ilqxz2mtrr/p1dB5r3dKys1L qDaQ== X-Received: by 10.152.21.39 with SMTP id s7mr4031370lae.0.1414151254683; Fri, 24 Oct 2014 04:47:34 -0700 (PDT) Received: from brick.home (aefx165.neoplus.adsl.tpnet.pl. [79.186.153.165]) by mx.google.com with ESMTPSA id f6sm1789319lbh.10.2014.10.24.04.47.33 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Oct 2014 04:47:33 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Fri, 24 Oct 2014 13:47:30 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Adrian Chadd Subject: Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG) Message-ID: <20141024114730.GC3413@brick.home> Mail-Followup-To: Adrian Chadd , Zenny , FreeBSD Stable Mailing List , =?iso-8859-1?Q?Jean-S=E9bastien_P=E9dron?= References: <54451422.1070403@FreeBSD.org> <54451E2A.1020309@FreeBSD.org> 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) Cc: Zenny , FreeBSD Stable Mailing List , =?iso-8859-1?Q?Jean-S=E9bastien_P=E9dron?= 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, 24 Oct 2014 11:47:37 -0000 On 1023T0931, Adrian Chadd wrote: > Ok! > > Which version of PCBSD is it? > > I flipped the default power save state in freebsd-head to be the > lowest supported by the CPU and all the more recent CPUs will idle at > a much lower power level. > > You could try putting these into /etc/rc.conf if they aren't already there: > > performance_cx_lowest="Cmax" > economy_cx_lowest="Cmax" > > .. and disable powerd. Could you explain this little more? Should modern systems just not use powerd(8) anymore? From owner-freebsd-stable@FreeBSD.ORG Fri Oct 24 12:22:56 2014 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 9DD70D1D for ; Fri, 24 Oct 2014 12:22:56 +0000 (UTC) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1F136B93 for ; Fri, 24 Oct 2014 12:22:55 +0000 (UTC) Received: by mail-lb0-f176.google.com with SMTP id p9so2436742lbv.21 for ; Fri, 24 Oct 2014 05:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=unUjxKCa7oEraPYEwuOt83XLo6BMZcDHV5i7c6pey48=; b=PStqVaFGggiHZiTVMUzMsA6KRXvv98P/O+opn+3MUQ11WLsYbXlevw2gNcTHdEcZkl pHd86hE/u47KGBHKDylOUqoFWJxDJInNH+JZFEjje8kY9U3qGK/IARpiLBzIv5g+8jX5 uwRbwHRTvgWjIY4N3/vm8hyDpxLZV620q205j3/6hQRA2rUlvBMJqUvilx4sP1aCKlmh ijs+0Sfg0VggApObTneKlmgvs3yn4hTtMpwu5/tUosidTSXrwvxfhSml6qjGx1LTsIWK oyHxd7xBy5+MiDvPbvzalxm40+FaIChuiZCz4tpAmuRMZ+SvXnWo9gJ+8wZiX7AYfQ92 BpVQ== X-Received: by 10.112.57.227 with SMTP id l3mr4153809lbq.68.1414153373735; Fri, 24 Oct 2014 05:22:53 -0700 (PDT) Received: from brick.home (aefx165.neoplus.adsl.tpnet.pl. [79.186.153.165]) by mx.google.com with ESMTPSA id i6sm1804822laf.47.2014.10.24.05.22.52 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Oct 2014 05:22:52 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Fri, 24 Oct 2014 14:22:50 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Harald Schmalzbauer Subject: Re: ctld(8), multiple 'portal-group' on same socket (individual 'discovery-auth-group' restrictions) Message-ID: <20141024122250.GA3992@brick.home> Mail-Followup-To: Harald Schmalzbauer , FreeBSD Stable References: <5444C94C.4050705@omnilan.de> <20141021104308.GA5990@brick.home> <54464405.4090207@omnilan.de> <20141021134516.GA89872@brick.home> <5446988B.5020509@omnilan.de> <20141022105804.GB5415@brick.home> <5447A362.30605@omnilan.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5447A362.30605@omnilan.de> User-Agent: Mutt/1.5.23 (2014-03-12) 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, 24 Oct 2014 12:22:56 -0000 Hi. Could you grab the file below, untar, "make all install", add "send authorized" (even shorter than 'authorized-portals-only yes" ;-) to portal-group in your ctl.conf, and see how it works for you? Thanks! http://people.freebsd.org/~trasz/ctld-send-authorized.tar.gz From owner-freebsd-stable@FreeBSD.ORG Fri Oct 24 13:12:07 2014 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 2F4907F7; Fri, 24 Oct 2014 13:12:07 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E49F9113; Fri, 24 Oct 2014 13:12:06 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Xheer-0003cZ-9i; Fri, 24 Oct 2014 15:12:03 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: freebsd-stable@freebsd.org, "Jim Pirzyk" Subject: Re: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-14:11.crypt References: <201410222107.s9ML7nLC010739@freefall.freebsd.org> Date: Fri, 24 Oct 2014 15:11:56 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.17 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.3.2 X-Scan-Signature: 72be745e4a817e3b6c39dafddcade14f 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, 24 Oct 2014 13:12:07 -0000 See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192277 Regards, Ronald. On Fri, 24 Oct 2014 13:14:20 +0200, Jim Pirzyk wrote: > Hi, > > I was wondering if there is more information about this change? FreeBSD > changed the default away from DES to MD5 back in the 1.1.5 -> 2.0 > transition. It seems to me a downgrade and rewarding bad programming to > be changing back to DES now. Also the proper course of action is to > correct programs that make the wrong assumption about what crypt() > changes. > > Thanks > > - JimP > > On Oct 22, 2014, at 4:07 PM, FreeBSD Errata Notices > wrote: > >> Signed PGP part >> ============================================================================= >> FreeBSD-EN-14:11.crypt Errata >> Notice >> The FreeBSD >> Project >> >> Topic: crypt(3) default hashing algorithm >> >> Category: core >> Module: libcrypt >> Announced: 2014-10-22 >> Affects: FreeBSD 9.3 and FreeBSD 10.0-STABLE after 2014-05-11 and >> before 2014-10-16. >> Corrected: 2014-10-13 15:56:47 UTC (stable/10, 10.1-PRERELEASE) >> 2014-10-16 21:39:04 UTC (releng/10.1, 10.1-RC3) >> 2014-10-16 21:39:04 UTC (releng/10.1, 10.1-RC2-p2) >> 2014-10-16 21:39:04 UTC (releng/10.1, 10.1-RC1-p2) >> 2014-10-16 21:39:04 UTC (releng/10.1, 10.1-BETA3-p2) >> 2014-10-21 21:09:54 UTC (stable/9, 9.3-STABLE) >> 2014-10-21 23:50:46 UTC (releng/9.3, 9.3-RELEASE-p4) >> >> For general information regarding FreeBSD Errata Notices and Security >> Advisories, including descriptions of the fields above, security >> branches, and the following sections, please visit >> . >> >> I. Background >> >> The crypt(3) function performs password hashing. Different algorithms >> of varying strength are available, with older, weaker algorithms being >> retained for compatibility. >> >> The crypt(3) function was originally based on the DES encryption >> algorithm and generated a 13-character hash from an eight-character >> password (longer passwords were truncated) and a two-character salt. >> >> II. Problem Description >> >> In recent FreeBSD releases, the default algorithm for crypt(3) was >> changed to SHA-512, which generates a much longer hash than the >> traditional DES-based algorithm. >> >> III. Impact >> >> Many applications assume that crypt(3) always returns a traditional DES >> hash, and blindly copy it into a short buffer without bounds checks. >> This >> may lead to a variety of undesirable results including, at worst, >> crashing >> the application. >> >> IV. Workaround >> >> No workaround is available. >> >> V. Solution >> >> Perform one of the following: >> >> 1) Upgrade your system to a supported FreeBSD stable or release / >> security >> branch (releng) dated after the correction date. >> >> 2) To update your present system via a source code patch: >> >> The following patches have been verified to apply to the applicable >> FreeBSD release branches. >> >> a) Download the relevant patch from the location below, and verify the >> detached PGP signature using your PGP utility. >> >> # fetch http://security.FreeBSD.org/patches/EN-14:11/crypt.patch >> # fetch http://security.FreeBSD.org/patches/EN-14:11/crypt.patch.asc >> # gpg --verify crypt.patch.asc >> >> b) Apply the patch. Execute the following commands as root: >> >> # cd /usr/src >> # patch < /path/to/patch >> >> c) Recompile the operating system using buildworld and installworld as >> described in . >> >> Restart all deamons using the library, or reboot the system. >> >> 3) To update your system via a binary patch: >> >> Systems running a RELEASE version of FreeBSD on the i386 or amd64 >> platforms can be updated via the freebsd-update(8) utility: >> >> # freebsd-update fetch >> # freebsd-update install >> >> VI. Correction details >> >> The following list contains the revision numbers of each file that was >> corrected in FreeBSD. >> >> Branch/path >> Revision >> ------------------------------------------------------------------------- >> stable/9/ >> r273425 >> releng/9.3/ >> r273438 >> stable/10/ >> r273043 >> releng/10.1/ >> r273187 >> ------------------------------------------------------------------------- >> >> To see which files were modified by a particular revision, run the >> following command, replacing NNNNNN with the revision number, on a >> machine with Subversion installed: >> >> # svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base >> >> Or visit the following URL, replacing NNNNNN with the revision number: >> >> >> >> VII. References >> >> The latest revision of this Errata Notice is available at >> http://security.FreeBSD.org/advisories/FreeBSD-EN-14:11.crypt.asc >> >> _______________________________________________ >> freebsd-announce@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-announce >> To unsubscribe, send any mail to >> "freebsd-announce-unsubscribe@freebsd.org" > > --- @(#) $Id: dot.signature,v 1.15 2007/12/27 15:06:13 pirzyk Exp $ > __o jim@pirzyk.org > -------------------------------------------------- > _'\<,_ > (*)/ (*) I'd rather be out biking. From owner-freebsd-stable@FreeBSD.ORG Fri Oct 24 13:22:00 2014 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 07BDAC51 for ; Fri, 24 Oct 2014 13:22:00 +0000 (UTC) Received: from m2j4.x.rootbsd.net (pirzyk.org [IPv6:2607:fc50:1:5900:216:3eff:fe10:3498]) (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 B09FC21F for ; Fri, 24 Oct 2014 13:21:59 +0000 (UTC) Received: from [192.168.1.126] (c-50-165-9-144.hsd1.il.comcast.net [50.165.9.144]) (authenticated bits=0) by m2j4.x.rootbsd.net (8.14.7/8.14.7) with ESMTP id s9ODLtCK072424 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 Oct 2014 08:21:56 -0500 (CDT) (envelope-from pirzyk@freeBSD.org) Content-Type: multipart/signed; boundary="Apple-Mail=_CEBCD18B-BCF1-49C2-9ACD-76BFAEEE8BBF"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-14:11.crypt From: Jim Pirzyk In-Reply-To: Date: Fri, 24 Oct 2014 08:21:48 -0500 Message-Id: References: <201410222107.s9ML7nLC010739@freefall.freebsd.org> To: Ronald Klop X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.4 at pirzyk.org X-Virus-Status: Clean X-Spam-Status: No, score=-0.9 required=8.0 tests=ALL_TRUSTED,TW_SV autolearn=unavailable autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pirzyk.org 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, 24 Oct 2014 13:22:00 -0000 --Apple-Mail=_CEBCD18B-BCF1-49C2-9ACD-76BFAEEE8BBF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think this should be reopened and reverted. This is the wrong answer = and has not taken into account the history of crypt() on FreeBSD. I = point you to the svn log: http://svnweb.freebsd.org/base?view=3Drevision&revision=3D4246 and http://www.freebsd.org/releases/2.0/notes.html If password security for FreeBSD is all you need, and you have no requirement for copying encrypted passwords from different hosts (Suns, DEC machines, etc) into FreeBSD password entries, then FreeBSD's MD5 based security may be all you require! We feel that our default = security model is more than a match for DES, and without any messy export issues to deal with. If you're outside (or even inside) the U.S., give it a = try! We are reversing 20+ years of FreeBSD progress. - JimP On Oct 24, 2014, at 8:11 AM, Ronald Klop wrote: > See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D192277 >=20 > Regards, > Ronald. >=20 > On Fri, 24 Oct 2014 13:14:20 +0200, Jim Pirzyk = wrote: >=20 >> Hi, >>=20 >> I was wondering if there is more information about this change? = FreeBSD changed the default away from DES to MD5 back in the 1.1.5 -> = 2.0 transition. It seems to me a downgrade and rewarding bad = programming to be changing back to DES now. Also the proper course of = action is to correct programs that make the wrong assumption about what = crypt() changes. >>=20 >> Thanks >>=20 >> - JimP >>=20 >> On Oct 22, 2014, at 4:07 PM, FreeBSD Errata Notices = wrote: >>=20 >>> Signed PGP part >>> = =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 >>> FreeBSD-EN-14:11.crypt = Errata Notice >>> The FreeBSD = Project >>>=20 >>> Topic: crypt(3) default hashing algorithm >>>=20 >>> Category: core >>> Module: libcrypt >>> Announced: 2014-10-22 >>> Affects: FreeBSD 9.3 and FreeBSD 10.0-STABLE after 2014-05-11 = and >>> before 2014-10-16. >>> Corrected: 2014-10-13 15:56:47 UTC (stable/10, 10.1-PRERELEASE) >>> 2014-10-16 21:39:04 UTC (releng/10.1, 10.1-RC3) >>> 2014-10-16 21:39:04 UTC (releng/10.1, 10.1-RC2-p2) >>> 2014-10-16 21:39:04 UTC (releng/10.1, 10.1-RC1-p2) >>> 2014-10-16 21:39:04 UTC (releng/10.1, 10.1-BETA3-p2) >>> 2014-10-21 21:09:54 UTC (stable/9, 9.3-STABLE) >>> 2014-10-21 23:50:46 UTC (releng/9.3, 9.3-RELEASE-p4) >>>=20 >>> For general information regarding FreeBSD Errata Notices and = Security >>> Advisories, including descriptions of the fields above, security >>> branches, and the following sections, please visit >>> . >>>=20 >>> I. Background >>>=20 >>> The crypt(3) function performs password hashing. Different = algorithms >>> of varying strength are available, with older, weaker algorithms = being >>> retained for compatibility. >>>=20 >>> The crypt(3) function was originally based on the DES encryption >>> algorithm and generated a 13-character hash from an eight-character >>> password (longer passwords were truncated) and a two-character salt. >>>=20 >>> II. Problem Description >>>=20 >>> In recent FreeBSD releases, the default algorithm for crypt(3) was >>> changed to SHA-512, which generates a much longer hash than the >>> traditional DES-based algorithm. >>>=20 >>> III. Impact >>>=20 >>> Many applications assume that crypt(3) always returns a traditional = DES >>> hash, and blindly copy it into a short buffer without bounds checks. = This >>> may lead to a variety of undesirable results including, at worst, = crashing >>> the application. >>>=20 >>> IV. Workaround >>>=20 >>> No workaround is available. >>>=20 >>> V. Solution >>>=20 >>> Perform one of the following: >>>=20 >>> 1) Upgrade your system to a supported FreeBSD stable or release / = security >>> branch (releng) dated after the correction date. >>>=20 >>> 2) To update your present system via a source code patch: >>>=20 >>> The following patches have been verified to apply to the applicable >>> FreeBSD release branches. >>>=20 >>> a) Download the relevant patch from the location below, and verify = the >>> detached PGP signature using your PGP utility. >>>=20 >>> # fetch http://security.FreeBSD.org/patches/EN-14:11/crypt.patch >>> # fetch http://security.FreeBSD.org/patches/EN-14:11/crypt.patch.asc >>> # gpg --verify crypt.patch.asc >>>=20 >>> b) Apply the patch. Execute the following commands as root: >>>=20 >>> # cd /usr/src >>> # patch < /path/to/patch >>>=20 >>> c) Recompile the operating system using buildworld and installworld = as >>> described in . >>>=20 >>> Restart all deamons using the library, or reboot the system. >>>=20 >>> 3) To update your system via a binary patch: >>>=20 >>> Systems running a RELEASE version of FreeBSD on the i386 or amd64 >>> platforms can be updated via the freebsd-update(8) utility: >>>=20 >>> # freebsd-update fetch >>> # freebsd-update install >>>=20 >>> VI. Correction details >>>=20 >>> The following list contains the revision numbers of each file that = was >>> corrected in FreeBSD. >>>=20 >>> Branch/path = Revision >>> = ------------------------------------------------------------------------- >>> stable/9/ = r273425 >>> releng/9.3/ = r273438 >>> stable/10/ = r273043 >>> releng/10.1/ = r273187 >>> = ------------------------------------------------------------------------- >>>=20 >>> To see which files were modified by a particular revision, run the >>> following command, replacing NNNNNN with the revision number, on a >>> machine with Subversion installed: >>>=20 >>> # svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base >>>=20 >>> Or visit the following URL, replacing NNNNNN with the revision = number: >>>=20 >>> = >>>=20 >>> VII. References >>>=20 >>> The latest revision of this Errata Notice is available at >>> http://security.FreeBSD.org/advisories/FreeBSD-EN-14:11.crypt.asc >>>=20 >>> _______________________________________________ >>> freebsd-announce@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-announce >>> To unsubscribe, send any mail to = "freebsd-announce-unsubscribe@freebsd.org" >>=20 >> --- @(#) $Id: dot.signature,v 1.15 2007/12/27 15:06:13 pirzyk Exp $ >> __o jim@pirzyk.org = -------------------------------------------------- >> _'\<,_ >> (*)/ (*) I'd rather be out biking. --- @(#) $Id: dot.signature,v 1.15 2007/12/27 15:06:13 pirzyk Exp $ __o jim@pirzyk.org = -------------------------------------------------- _'\<,_ (*)/ (*) I'd rather be out biking. --Apple-Mail=_CEBCD18B-BCF1-49C2-9ACD-76BFAEEE8BBF 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 - http://gpgtools.org iFcDBQFUSlJy+2AFq07nokoRCEd5AQCpt20/x+KYLRoGnzT4AX6LZ0FbnDF9xsEn 77+9/cEdZgD/T0nJM3xYTPSiC2of0xXwRLwHoqd1AeRJCT3EyfpXh4c= =sIP1 -----END PGP SIGNATURE----- --Apple-Mail=_CEBCD18B-BCF1-49C2-9ACD-76BFAEEE8BBF-- From owner-freebsd-stable@FreeBSD.ORG Fri Oct 24 13:49:08 2014 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 C615C83B; Fri, 24 Oct 2014 13:49:08 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 85724776; Fri, 24 Oct 2014 13:49:08 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1XhfEi-0000tZ-IK; Fri, 24 Oct 2014 15:49:06 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Jim Pirzyk" Subject: Re: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-14:11.crypt References: <201410222107.s9ML7nLC010739@freefall.freebsd.org> Date: Fri, 24 Oct 2014 15:48:59 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.17 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.3.1 X-Scan-Signature: 1629bd954af37e9bd463cbe85bf61e19 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, 24 Oct 2014 13:49:08 -0000 Hi, I have nothing to do with the actual coding, but please reread comment 7 from the bug report: 'This doesn't have anything common with system default password encryption, this is realized using /etc/login.conf and applications like passwd, etc.' Regards, Ronald. On Fri, 24 Oct 2014 15:21:48 +0200, Jim Pirzyk wrote: > I think this should be reopened and reverted. This is the wrong answer > and has not taken into account the history of crypt() on FreeBSD. I > point you to the svn log: > > http://svnweb.freebsd.org/base?view=revision&revision=4246 > > and > > http://www.freebsd.org/releases/2.0/notes.html > > If password security for FreeBSD is all you need, and you have no > requirement for copying encrypted passwords from different hosts (Suns, > DEC machines, etc) into FreeBSD password entries, then FreeBSD's MD5 > based security may be all you require! We feel that our default security > model is more than a match for DES, and without any messy export issues > to deal with. If you're outside (or even inside) the U.S., give it a > try! > > We are reversing 20+ years of FreeBSD progress. > > - JimP > > On Oct 24, 2014, at 8:11 AM, Ronald Klop wrote: > >> See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192277 >> >> Regards, >> Ronald. >> >> On Fri, 24 Oct 2014 13:14:20 +0200, Jim Pirzyk >> wrote: >> >>> Hi, >>> >>> I was wondering if there is more information about this change? >>> FreeBSD changed the default away from DES to MD5 back in the 1.1.5 -> >>> 2.0 transition. It seems to me a downgrade and rewarding bad >>> programming to be changing back to DES now. Also the proper course of >>> action is to correct programs that make the wrong assumption about >>> what crypt() changes. >>> >>> Thanks >>> >>> - JimP >>> >>> On Oct 22, 2014, at 4:07 PM, FreeBSD Errata Notices >>> wrote: >>> >>>> Signed PGP part >>>> ============================================================================= >>>> FreeBSD-EN-14:11.crypt >>>> Errata Notice >>>> The FreeBSD >>>> Project >>>> >>>> Topic: crypt(3) default hashing algorithm >>>> >>>> Category: core >>>> Module: libcrypt >>>> Announced: 2014-10-22 >>>> Affects: FreeBSD 9.3 and FreeBSD 10.0-STABLE after 2014-05-11 >>>> and >>>> before 2014-10-16. >>>> Corrected: 2014-10-13 15:56:47 UTC (stable/10, 10.1-PRERELEASE) >>>> 2014-10-16 21:39:04 UTC (releng/10.1, 10.1-RC3) >>>> 2014-10-16 21:39:04 UTC (releng/10.1, 10.1-RC2-p2) >>>> 2014-10-16 21:39:04 UTC (releng/10.1, 10.1-RC1-p2) >>>> 2014-10-16 21:39:04 UTC (releng/10.1, 10.1-BETA3-p2) >>>> 2014-10-21 21:09:54 UTC (stable/9, 9.3-STABLE) >>>> 2014-10-21 23:50:46 UTC (releng/9.3, 9.3-RELEASE-p4) >>>> >>>> For general information regarding FreeBSD Errata Notices and Security >>>> Advisories, including descriptions of the fields above, security >>>> branches, and the following sections, please visit >>>> . >>>> >>>> I. Background >>>> >>>> The crypt(3) function performs password hashing. Different algorithms >>>> of varying strength are available, with older, weaker algorithms being >>>> retained for compatibility. >>>> >>>> The crypt(3) function was originally based on the DES encryption >>>> algorithm and generated a 13-character hash from an eight-character >>>> password (longer passwords were truncated) and a two-character salt. >>>> >>>> II. Problem Description >>>> >>>> In recent FreeBSD releases, the default algorithm for crypt(3) was >>>> changed to SHA-512, which generates a much longer hash than the >>>> traditional DES-based algorithm. >>>> >>>> III. Impact >>>> >>>> Many applications assume that crypt(3) always returns a traditional >>>> DES >>>> hash, and blindly copy it into a short buffer without bounds checks. >>>> This >>>> may lead to a variety of undesirable results including, at worst, >>>> crashing >>>> the application. >>>> >>>> IV. Workaround >>>> >>>> No workaround is available. >>>> >>>> V. Solution >>>> >>>> Perform one of the following: >>>> >>>> 1) Upgrade your system to a supported FreeBSD stable or release / >>>> security >>>> branch (releng) dated after the correction date. >>>> >>>> 2) To update your present system via a source code patch: >>>> >>>> The following patches have been verified to apply to the applicable >>>> FreeBSD release branches. >>>> >>>> a) Download the relevant patch from the location below, and verify the >>>> detached PGP signature using your PGP utility. >>>> >>>> # fetch http://security.FreeBSD.org/patches/EN-14:11/crypt.patch >>>> # fetch http://security.FreeBSD.org/patches/EN-14:11/crypt.patch.asc >>>> # gpg --verify crypt.patch.asc >>>> >>>> b) Apply the patch. Execute the following commands as root: >>>> >>>> # cd /usr/src >>>> # patch < /path/to/patch >>>> >>>> c) Recompile the operating system using buildworld and installworld as >>>> described in . >>>> >>>> Restart all deamons using the library, or reboot the system. >>>> >>>> 3) To update your system via a binary patch: >>>> >>>> Systems running a RELEASE version of FreeBSD on the i386 or amd64 >>>> platforms can be updated via the freebsd-update(8) utility: >>>> >>>> # freebsd-update fetch >>>> # freebsd-update install >>>> >>>> VI. Correction details >>>> >>>> The following list contains the revision numbers of each file that was >>>> corrected in FreeBSD. >>>> >>>> Branch/path >>>> Revision >>>> ------------------------------------------------------------------------- >>>> stable/9/ >>>> r273425 >>>> releng/9.3/ >>>> r273438 >>>> stable/10/ >>>> r273043 >>>> releng/10.1/ >>>> r273187 >>>> ------------------------------------------------------------------------- >>>> >>>> To see which files were modified by a particular revision, run the >>>> following command, replacing NNNNNN with the revision number, on a >>>> machine with Subversion installed: >>>> >>>> # svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base >>>> >>>> Or visit the following URL, replacing NNNNNN with the revision number: >>>> >>>> >>>> >>>> VII. References >>>> >>>> The latest revision of this Errata Notice is available at >>>> http://security.FreeBSD.org/advisories/FreeBSD-EN-14:11.crypt.asc >>>> >>>> _______________________________________________ >>>> freebsd-announce@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-announce >>>> To unsubscribe, send any mail to >>>> "freebsd-announce-unsubscribe@freebsd.org" >>> >>> --- @(#) $Id: dot.signature,v 1.15 2007/12/27 15:06:13 pirzyk Exp $ >>> __o jim@pirzyk.org >>> -------------------------------------------------- >>> _'\<,_ >>> (*)/ (*) I'd rather be out biking. > > --- @(#) $Id: dot.signature,v 1.15 2007/12/27 15:06:13 pirzyk Exp $ > __o jim@pirzyk.org > -------------------------------------------------- > _'\<,_ > (*)/ (*) I'd rather be out biking. From owner-freebsd-stable@FreeBSD.ORG Fri Oct 24 16:10:24 2014 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 69289365 for ; Fri, 24 Oct 2014 16:10:24 +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 2876F926 for ; Fri, 24 Oct 2014 16:10:23 +0000 (UTC) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3jPVlP4dBMzb37 for ; Fri, 24 Oct 2014 18:10:09 +0200 (CEST) Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10024) with ESMTP id fUzlWvftRzoM for ; Fri, 24 Oct 2014 18:09:59 +0200 (CEST) Received: from marvin.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA for ; Fri, 24 Oct 2014 18:09:54 +0200 (CEST) Message-ID: <544A79D1.3090909@FreeBSD.org> Date: Fri, 24 Oct 2014 18:09:53 +0200 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: panic: detach with active requests on 10.1-RC3 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, 24 Oct 2014 16:10:24 -0000 Hi, I already sent this to freebsd-fs@. I'm making some experiments with 10.1-RC3 on alix boards as hardware using NanoBSD. By mounting and umounting UFS filesystems I have seen umount constantly hanging hard in a deadlock. I have tested on two boards with two distinct compactflash disks with same results. This was not happening with 10.0-RELEASE. I have build a 10.1-RC3 kernel with full debugging and caused the problem to happen, I got this: root@qtest:~ [0]# umount /cfg panic: detach with active requests KDB: stack backtrace: db_trace_self_wrapper(c0968053,c08ea7f0,c2d48800,c23d6bc8,c0536a16,...) at db_trace_self_wrapper+0x2d/frame 0xc23d6b98 kdb_backtrace(c09639e1,c09fa7e8,c095761d,c23d6c54,c095761d,...) at kdb_backtrace+0x30/frame 0xc23d6c00 vpanic(c09fa682,100,c095761d,c23d6c54,c23d6c54,...) at vpanic+0x80/frame 0xc23d6c24 kassert_panic(c095761d,c09575b3,c2d7acc0,4c7,c2d7acc0,...) at kassert_panic+0xe9/frame 0xc23d6c48 g_detach(c2d7acc0,4,c095725c,1c2,c09c8d5c,...) at g_detach+0x1d3/frame 0xc23d6c64 g_wither_washer(c09f7df4,0,c0956544,124,0,...) at g_wither_washer+0x109/frame 0xc23d6c90 g_run_events(0,c23d6d08,c095d42a,3dc,0,...) at g_run_events+0x40/frame 0xc23d6ccc fork_exit(c05c4e60,0,c23d6d08) at fork_exit+0x7f/frame 0xc23d6cf4 fork_trampoline() at fork_trampoline+0x8/frame 0xc23d6cf4 --- trap 0, eip = 0, esp = 0xc23d6d40, ebp = 0 --- KDB: enter: panic [ thread pid 12 tid 100006 ] Stopped at kdb_enter+0x3d: movl $0,kdb_why db> The machine is sitting there, I am connected with serial console, anyone willing to help me debug this further? I really know very little about kernel debugging. If necessary I can also make myself available via IRC or Jabber. It looks like this has some similarities with what was reported here: https://lists.freebsd.org/pipermail/freebsd-fs/2014-September/020035.html I also tested with head (including r272130) and it does deadlock the same. Maybe the slower media is exposing some problem which does not show up with faster disks? Thanks in advance! -- Guido Falsi From owner-freebsd-stable@FreeBSD.ORG Fri Oct 24 16:18:59 2014 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 48B6CA23 for ; Fri, 24 Oct 2014 16:18:59 +0000 (UTC) Received: from m2j4.x.rootbsd.net (pirzyk.org [IPv6:2607:fc50:1:5900:216:3eff:fe10:3498]) (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 03F4BA5D for ; Fri, 24 Oct 2014 16:18:58 +0000 (UTC) Received: from [192.168.1.126] (c-50-165-9-144.hsd1.il.comcast.net [50.165.9.144]) (authenticated bits=0) by m2j4.x.rootbsd.net (8.14.7/8.14.7) with ESMTP id s9OGInSh075330 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 Oct 2014 11:18:51 -0500 (CDT) (envelope-from pirzyk@freeBSD.org) Content-Type: multipart/signed; boundary="Apple-Mail=_33CE962D-51CE-43C8-BBCE-B40CAFA70727"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-14:11.crypt From: Jim Pirzyk In-Reply-To: Date: Fri, 24 Oct 2014 11:18:42 -0500 Message-Id: <23061782-21F6-4509-9362-2DAEED692F72@freeBSD.org> References: <201410222107.s9ML7nLC010739@freefall.freebsd.org> To: Ronald Klop X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.4 at pirzyk.org X-Virus-Status: Clean X-Spam-Status: No, score=-0.9 required=8.0 tests=ALL_TRUSTED,TW_SV autolearn=unavailable autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pirzyk.org 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, 24 Oct 2014 16:18:59 -0000 --Apple-Mail=_33CE962D-51CE-43C8-BBCE-B40CAFA70727 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 That statement is really irrelevant because this is the submitter, what = was the crypt() behavior back in the 2.0 days? Did anyone in FreeBSD = verify this statement? Why was that behavior not restored, as opposed = to chaining the default encryption algorithm. If login.conf was lost, = mangled, etc in the old days, you would still get md5/sha1/=85/etc = encryption, now you just get DES. I think the security implications of this change should have required a = bigger review, like at least sign off from security-officer@freebsd.org If this was a POSIX compatibility issue, that should have been evaluated = and reviewed properly. It feels there were not enough eyes on this = change and if as you say this is not affected the default passwd = algorithm, that should have also been noted in the Errata note. - JimP On Oct 24, 2014, at 8:48 AM, Ronald Klop wrote: > Hi, >=20 > I have nothing to do with the actual coding, but please reread comment = 7 from the bug report: > 'This doesn't have anything common with system default password = encryption, this is realized using /etc/login.conf and applications like = passwd, etc.' >=20 > Regards, > Ronald. >=20 > On Fri, 24 Oct 2014 15:21:48 +0200, Jim Pirzyk = wrote: >=20 >> I think this should be reopened and reverted. This is the wrong = answer and has not taken into account the history of crypt() on FreeBSD. = I point you to the svn log: >>=20 >> http://svnweb.freebsd.org/base?view=3Drevision&revision=3D4246 >>=20 >> and >>=20 >> http://www.freebsd.org/releases/2.0/notes.html >>=20 >> If password security for FreeBSD is all you need, and you have no >> requirement for copying encrypted passwords from different hosts = (Suns, >> DEC machines, etc) into FreeBSD password entries, then FreeBSD's MD5 >> based security may be all you require! We feel that our default = security >> model is more than a match for DES, and without any messy export = issues >> to deal with. If you're outside (or even inside) the U.S., give it a = try! >>=20 >> We are reversing 20+ years of FreeBSD progress. >>=20 >> - JimP >>=20 >> On Oct 24, 2014, at 8:11 AM, Ronald Klop = wrote: >>=20 >>> See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D192277 >>>=20 >>> Regards, >>> Ronald. >>>=20 >>> On Fri, 24 Oct 2014 13:14:20 +0200, Jim Pirzyk = wrote: >>>=20 >>>> Hi, >>>>=20 >>>> I was wondering if there is more information about this change? = FreeBSD changed the default away from DES to MD5 back in the 1.1.5 -> = 2.0 transition. It seems to me a downgrade and rewarding bad = programming to be changing back to DES now. Also the proper course of = action is to correct programs that make the wrong assumption about what = crypt() changes. >>>>=20 >>>> Thanks >>>>=20 >>>> - JimP >>>>=20 >>>> On Oct 22, 2014, at 4:07 PM, FreeBSD Errata Notices = wrote: >>>>=20 >>>>> Signed PGP part >>>>> = =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 >>>>> FreeBSD-EN-14:11.crypt = Errata Notice >>>>> The = FreeBSD Project >>>>>=20 >>>>> Topic: crypt(3) default hashing algorithm >>>>>=20 >>>>> Category: core >>>>> Module: libcrypt >>>>> Announced: 2014-10-22 >>>>> Affects: FreeBSD 9.3 and FreeBSD 10.0-STABLE after = 2014-05-11 and >>>>> before 2014-10-16. >>>>> Corrected: 2014-10-13 15:56:47 UTC (stable/10, = 10.1-PRERELEASE) >>>>> 2014-10-16 21:39:04 UTC (releng/10.1, 10.1-RC3) >>>>> 2014-10-16 21:39:04 UTC (releng/10.1, 10.1-RC2-p2) >>>>> 2014-10-16 21:39:04 UTC (releng/10.1, 10.1-RC1-p2) >>>>> 2014-10-16 21:39:04 UTC (releng/10.1, 10.1-BETA3-p2) >>>>> 2014-10-21 21:09:54 UTC (stable/9, 9.3-STABLE) >>>>> 2014-10-21 23:50:46 UTC (releng/9.3, 9.3-RELEASE-p4) >>>>>=20 >>>>> For general information regarding FreeBSD Errata Notices and = Security >>>>> Advisories, including descriptions of the fields above, security >>>>> branches, and the following sections, please visit >>>>> . >>>>>=20 >>>>> I. Background >>>>>=20 >>>>> The crypt(3) function performs password hashing. Different = algorithms >>>>> of varying strength are available, with older, weaker algorithms = being >>>>> retained for compatibility. >>>>>=20 >>>>> The crypt(3) function was originally based on the DES encryption >>>>> algorithm and generated a 13-character hash from an = eight-character >>>>> password (longer passwords were truncated) and a two-character = salt. >>>>>=20 >>>>> II. Problem Description >>>>>=20 >>>>> In recent FreeBSD releases, the default algorithm for crypt(3) was >>>>> changed to SHA-512, which generates a much longer hash than the >>>>> traditional DES-based algorithm. >>>>>=20 >>>>> III. Impact >>>>>=20 >>>>> Many applications assume that crypt(3) always returns a = traditional DES >>>>> hash, and blindly copy it into a short buffer without bounds = checks. This >>>>> may lead to a variety of undesirable results including, at worst, = crashing >>>>> the application. >>>>>=20 >>>>> IV. Workaround >>>>>=20 >>>>> No workaround is available. >>>>>=20 >>>>> V. Solution >>>>>=20 >>>>> Perform one of the following: >>>>>=20 >>>>> 1) Upgrade your system to a supported FreeBSD stable or release / = security >>>>> branch (releng) dated after the correction date. >>>>>=20 >>>>> 2) To update your present system via a source code patch: >>>>>=20 >>>>> The following patches have been verified to apply to the = applicable >>>>> FreeBSD release branches. >>>>>=20 >>>>> a) Download the relevant patch from the location below, and verify = the >>>>> detached PGP signature using your PGP utility. >>>>>=20 >>>>> # fetch http://security.FreeBSD.org/patches/EN-14:11/crypt.patch >>>>> # fetch = http://security.FreeBSD.org/patches/EN-14:11/crypt.patch.asc >>>>> # gpg --verify crypt.patch.asc >>>>>=20 >>>>> b) Apply the patch. Execute the following commands as root: >>>>>=20 >>>>> # cd /usr/src >>>>> # patch < /path/to/patch >>>>>=20 >>>>> c) Recompile the operating system using buildworld and = installworld as >>>>> described in . >>>>>=20 >>>>> Restart all deamons using the library, or reboot the system. >>>>>=20 >>>>> 3) To update your system via a binary patch: >>>>>=20 >>>>> Systems running a RELEASE version of FreeBSD on the i386 or amd64 >>>>> platforms can be updated via the freebsd-update(8) utility: >>>>>=20 >>>>> # freebsd-update fetch >>>>> # freebsd-update install >>>>>=20 >>>>> VI. Correction details >>>>>=20 >>>>> The following list contains the revision numbers of each file that = was >>>>> corrected in FreeBSD. >>>>>=20 >>>>> Branch/path = Revision >>>>> = ------------------------------------------------------------------------- >>>>> stable/9/ = r273425 >>>>> releng/9.3/ = r273438 >>>>> stable/10/ = r273043 >>>>> releng/10.1/ = r273187 >>>>> = ------------------------------------------------------------------------- >>>>>=20 >>>>> To see which files were modified by a particular revision, run the >>>>> following command, replacing NNNNNN with the revision number, on a >>>>> machine with Subversion installed: >>>>>=20 >>>>> # svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base >>>>>=20 >>>>> Or visit the following URL, replacing NNNNNN with the revision = number: >>>>>=20 >>>>> >>>>>=20 >>>>> VII. References >>>>>=20 >>>>> The latest revision of this Errata Notice is available at >>>>> http://security.FreeBSD.org/advisories/FreeBSD-EN-14:11.crypt.asc >>>>>=20 >>>>> _______________________________________________ >>>>> freebsd-announce@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-announce >>>>> To unsubscribe, send any mail to = "freebsd-announce-unsubscribe@freebsd.org" >>>>=20 >>>> --- @(#) $Id: dot.signature,v 1.15 2007/12/27 15:06:13 pirzyk Exp $ >>>> __o jim@pirzyk.org = -------------------------------------------------- >>>> _'\<,_ >>>> (*)/ (*) I'd rather be out biking. >>=20 >> --- @(#) $Id: dot.signature,v 1.15 2007/12/27 15:06:13 pirzyk Exp $ >> __o jim@pirzyk.org = -------------------------------------------------- >> _'\<,_ >> (*)/ (*) I'd rather be out biking. --- @(#) $Id: dot.signature,v 1.15 2007/12/27 15:06:13 pirzyk Exp $ __o jim@pirzyk.org = -------------------------------------------------- _'\<,_ (*)/ (*) I'd rather be out biking. --Apple-Mail=_33CE962D-51CE-43C8-BBCE-B40CAFA70727 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 - http://gpgtools.org iFcDBQFUSnvp+2AFq07nokoRCKVjAQCrJnCdSrLlL9QRfVjejAUcpwYnf34XGTre F+YMp1DVJwEA6rKcd7HONwYUbQ/fRfdYrfIAqDmqy1yE5n6uvuHWKls= =e/mR -----END PGP SIGNATURE----- --Apple-Mail=_33CE962D-51CE-43C8-BBCE-B40CAFA70727-- From owner-freebsd-stable@FreeBSD.ORG Fri Oct 24 17:43:58 2014 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 5896ECDE; Fri, 24 Oct 2014 17:43:58 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B67625EF; Fri, 24 Oct 2014 17:43:57 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id bs8so1884410wib.9 for ; Fri, 24 Oct 2014 10:43:56 -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=hEiAQWPeoQWOlNXEq+r0Rxu6zACXtGR09ScDYrc+bP4=; b=l5/+v7gbeHvomlPBEKFyitW8dF5xWYXIXfXH0fi0Khbxvu8MEkuUuBdb6vRrd3Wocr lzL+QijNPcjLvTgu5Z2ReB8r3tFDBNE8PxdgVP7fipYkBIZ7qEl2jlLkjCOI22AgleNx v7FwWbCh/I24Rlz3ODmhg99EtFq+kJm3lZzsQEYXlYmBdzK8g0U58gHDq/lB4ltviX/A G7HcpjhNSDjbDrqapCFRNYtEvsKurQIQzJWriEq8tufABPtqZJ8hUQMAiHK/cn8mmLhc wXyC0rbOJ3PYxaz6ykO7Sj9T/6ErrD73yqAoPNtGUkH0J8eyDUNhMsprX6/pVp/iCRJs UrjA== MIME-Version: 1.0 X-Received: by 10.180.79.228 with SMTP id m4mr5603473wix.26.1414172635931; Fri, 24 Oct 2014 10:43:55 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Fri, 24 Oct 2014 10:43:55 -0700 (PDT) In-Reply-To: <23061782-21F6-4509-9362-2DAEED692F72@freeBSD.org> References: <201410222107.s9ML7nLC010739@freefall.freebsd.org> <23061782-21F6-4509-9362-2DAEED692F72@freeBSD.org> Date: Fri, 24 Oct 2014 10:43:55 -0700 X-Google-Sender-Auth: 1IclwLKP1rlNiJh8jhqg3CP7xnY Message-ID: Subject: Re: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-14:11.crypt From: Adrian Chadd To: Jim Pirzyk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Stable Mailing List , Ronald Klop 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, 24 Oct 2014 17:43:58 -0000 You mean like des@ ? -adrian On 24 October 2014 09:18, Jim Pirzyk wrote: > That statement is really irrelevant because this is the submitter, what w= as the crypt() behavior back in the 2.0 days? Did anyone in FreeBSD verify= this statement? Why was that behavior not restored, as opposed to chainin= g the default encryption algorithm. If login.conf was lost, mangled, etc i= n the old days, you would still get md5/sha1/=E2=80=A6/etc encryption, now = you just get DES. > > I think the security implications of this change should have required a b= igger review, like at least sign off from security-officer@freebsd.org > > If this was a POSIX compatibility issue, that should have been evaluated = and reviewed properly. It feels there were not enough eyes on this change = and if as you say this is not affected the default passwd algorithm, that s= hould have also been noted in the Errata note. > > - JimP > > On Oct 24, 2014, at 8:48 AM, Ronald Klop wrote: > >> Hi, >> >> I have nothing to do with the actual coding, but please reread comment 7= from the bug report: >> 'This doesn't have anything common with system default password encrypti= on, this is realized using /etc/login.conf and applications like passwd, et= c.' >> >> Regards, >> Ronald. >> >> On Fri, 24 Oct 2014 15:21:48 +0200, Jim Pirzyk wrot= e: >> >>> I think this should be reopened and reverted. This is the wrong answer= and has not taken into account the history of crypt() on FreeBSD. I point= you to the svn log: >>> >>> http://svnweb.freebsd.org/base?view=3Drevision&revision=3D4246 >>> >>> and >>> >>> http://www.freebsd.org/releases/2.0/notes.html >>> >>> If password security for FreeBSD is all you need, and you have no >>> requirement for copying encrypted passwords from different hosts (Suns, >>> DEC machines, etc) into FreeBSD password entries, then FreeBSD's MD5 >>> based security may be all you require! We feel that our default securi= ty >>> model is more than a match for DES, and without any messy export issues >>> to deal with. If you're outside (or even inside) the U.S., give it a t= ry! >>> >>> We are reversing 20+ years of FreeBSD progress. >>> >>> - JimP >>> >>> On Oct 24, 2014, at 8:11 AM, Ronald Klop wrote: >>> >>>> See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D192277 >>>> >>>> Regards, >>>> Ronald. >>>> >>>> On Fri, 24 Oct 2014 13:14:20 +0200, Jim Pirzyk wr= ote: >>>> >>>>> Hi, >>>>> >>>>> I was wondering if there is more information about this change? Free= BSD changed the default away from DES to MD5 back in the 1.1.5 -> 2.0 trans= ition. It seems to me a downgrade and rewarding bad programming to be chan= ging back to DES now. Also the proper course of action is to correct progr= ams that make the wrong assumption about what crypt() changes. >>>>> >>>>> Thanks >>>>> >>>>> - JimP >>>>> >>>>> On Oct 22, 2014, at 4:07 PM, FreeBSD Errata Notices wrote: >>>>> >>>>>> Signed PGP part >>>>>> =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 >>>>>> FreeBSD-EN-14:11.crypt Erra= ta Notice >>>>>> The FreeBSD = Project >>>>>> >>>>>> Topic: crypt(3) default hashing algorithm >>>>>> >>>>>> Category: core >>>>>> Module: libcrypt >>>>>> Announced: 2014-10-22 >>>>>> Affects: FreeBSD 9.3 and FreeBSD 10.0-STABLE after 2014-05-11= and >>>>>> before 2014-10-16. >>>>>> Corrected: 2014-10-13 15:56:47 UTC (stable/10, 10.1-PRERELEASE) >>>>>> 2014-10-16 21:39:04 UTC (releng/10.1, 10.1-RC3) >>>>>> 2014-10-16 21:39:04 UTC (releng/10.1, 10.1-RC2-p2) >>>>>> 2014-10-16 21:39:04 UTC (releng/10.1, 10.1-RC1-p2) >>>>>> 2014-10-16 21:39:04 UTC (releng/10.1, 10.1-BETA3-p2) >>>>>> 2014-10-21 21:09:54 UTC (stable/9, 9.3-STABLE) >>>>>> 2014-10-21 23:50:46 UTC (releng/9.3, 9.3-RELEASE-p4) >>>>>> >>>>>> For general information regarding FreeBSD Errata Notices and Securit= y >>>>>> Advisories, including descriptions of the fields above, security >>>>>> branches, and the following sections, please visit >>>>>> . >>>>>> >>>>>> I. Background >>>>>> >>>>>> The crypt(3) function performs password hashing. Different algorith= ms >>>>>> of varying strength are available, with older, weaker algorithms bei= ng >>>>>> retained for compatibility. >>>>>> >>>>>> The crypt(3) function was originally based on the DES encryption >>>>>> algorithm and generated a 13-character hash from an eight-character >>>>>> password (longer passwords were truncated) and a two-character salt. >>>>>> >>>>>> II. Problem Description >>>>>> >>>>>> In recent FreeBSD releases, the default algorithm for crypt(3) was >>>>>> changed to SHA-512, which generates a much longer hash than the >>>>>> traditional DES-based algorithm. >>>>>> >>>>>> III. Impact >>>>>> >>>>>> Many applications assume that crypt(3) always returns a traditional = DES >>>>>> hash, and blindly copy it into a short buffer without bounds checks.= This >>>>>> may lead to a variety of undesirable results including, at worst, cr= ashing >>>>>> the application. >>>>>> >>>>>> IV. Workaround >>>>>> >>>>>> No workaround is available. >>>>>> >>>>>> V. Solution >>>>>> >>>>>> Perform one of the following: >>>>>> >>>>>> 1) Upgrade your system to a supported FreeBSD stable or release / se= curity >>>>>> branch (releng) dated after the correction date. >>>>>> >>>>>> 2) To update your present system via a source code patch: >>>>>> >>>>>> The following patches have been verified to apply to the applicable >>>>>> FreeBSD release branches. >>>>>> >>>>>> a) Download the relevant patch from the location below, and verify t= he >>>>>> detached PGP signature using your PGP utility. >>>>>> >>>>>> # fetch http://security.FreeBSD.org/patches/EN-14:11/crypt.patch >>>>>> # fetch http://security.FreeBSD.org/patches/EN-14:11/crypt.patch.asc >>>>>> # gpg --verify crypt.patch.asc >>>>>> >>>>>> b) Apply the patch. Execute the following commands as root: >>>>>> >>>>>> # cd /usr/src >>>>>> # patch < /path/to/patch >>>>>> >>>>>> c) Recompile the operating system using buildworld and installworld = as >>>>>> described in . >>>>>> >>>>>> Restart all deamons using the library, or reboot the system. >>>>>> >>>>>> 3) To update your system via a binary patch: >>>>>> >>>>>> Systems running a RELEASE version of FreeBSD on the i386 or amd64 >>>>>> platforms can be updated via the freebsd-update(8) utility: >>>>>> >>>>>> # freebsd-update fetch >>>>>> # freebsd-update install >>>>>> >>>>>> VI. Correction details >>>>>> >>>>>> The following list contains the revision numbers of each file that w= as >>>>>> corrected in FreeBSD. >>>>>> >>>>>> Branch/path Rev= ision >>>>>> --------------------------------------------------------------------= ----- >>>>>> stable/9/ r2= 73425 >>>>>> releng/9.3/ r2= 73438 >>>>>> stable/10/ r2= 73043 >>>>>> releng/10.1/ r2= 73187 >>>>>> --------------------------------------------------------------------= ----- >>>>>> >>>>>> To see which files were modified by a particular revision, run the >>>>>> following command, replacing NNNNNN with the revision number, on a >>>>>> machine with Subversion installed: >>>>>> >>>>>> # svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base >>>>>> >>>>>> Or visit the following URL, replacing NNNNNN with the revision numbe= r: >>>>>> >>>>>> >>>>>> >>>>>> VII. References >>>>>> >>>>>> The latest revision of this Errata Notice is available at >>>>>> http://security.FreeBSD.org/advisories/FreeBSD-EN-14:11.crypt.asc >>>>>> >>>>>> _______________________________________________ >>>>>> freebsd-announce@freebsd.org mailing list >>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-announce >>>>>> To unsubscribe, send any mail to "freebsd-announce-unsubscribe@freeb= sd.org" >>>>> >>>>> --- @(#) $Id: dot.signature,v 1.15 2007/12/27 15:06:13 pirzyk Exp $ >>>>> __o jim@pirzyk.org -----------------------------------------------= --- >>>>> _'\<,_ >>>>> (*)/ (*) I'd rather be out biking. >>> >>> --- @(#) $Id: dot.signature,v 1.15 2007/12/27 15:06:13 pirzyk Exp $ >>> __o jim@pirzyk.org ------------------------------------------------= -- >>> _'\<,_ >>> (*)/ (*) I'd rather be out biking. > > --- @(#) $Id: dot.signature,v 1.15 2007/12/27 15:06:13 pirzyk Exp $ > __o jim@pirzyk.org -------------------------------------------------= - > _'\<,_ > (*)/ (*) I'd rather be out biking. > From owner-freebsd-stable@FreeBSD.ORG Fri Oct 24 19:37:20 2014 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 B9A52E5E; Fri, 24 Oct 2014 19:37:20 +0000 (UTC) Received: from m2j4.x.rootbsd.net (pirzyk.org [IPv6:2607:fc50:1:5900:216:3eff:fe10:3498]) (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 84F99238; Fri, 24 Oct 2014 19:37:20 +0000 (UTC) Received: from [192.168.1.126] (c-50-165-9-144.hsd1.il.comcast.net [50.165.9.144]) (authenticated bits=0) by m2j4.x.rootbsd.net (8.14.7/8.14.7) with ESMTP id s9OJbDG7078385 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 Oct 2014 14:37:14 -0500 (CDT) (envelope-from pirzyk@freeBSD.org) Content-Type: multipart/signed; boundary="Apple-Mail=_6EB7C021-CF36-4694-87F1-9AF483B62067"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-14:11.crypt From: Jim Pirzyk In-Reply-To: Date: Fri, 24 Oct 2014 14:37:07 -0500 Message-Id: <2FDC7048-E9A3-443B-BC38-CDE776CA1212@freeBSD.org> References: <201410222107.s9ML7nLC010739@freefall.freebsd.org> <23061782-21F6-4509-9362-2DAEED692F72@freeBSD.org> To: Adrian Chadd X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.4 at pirzyk.org X-Virus-Status: Clean X-Spam-Status: No, score=-0.9 required=8.0 tests=ALL_TRUSTED,TW_SV autolearn=unavailable autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pirzyk.org Cc: FreeBSD Stable Mailing List , des@freebsd.org, Ronald Klop 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, 24 Oct 2014 19:37:20 -0000 --Apple-Mail=_6EB7C021-CF36-4694-87F1-9AF483B62067 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Is he the current security officer? If so it would have been nice to = see these issues addressed in the Errata announcement. I still don=92t understand the reasons for backing out a change after 20 = years. - JimP On Oct 24, 2014, at 12:43 PM, Adrian Chadd wrote: > You mean like des@ ? >=20 >=20 >=20 > -adrian >=20 > On 24 October 2014 09:18, Jim Pirzyk wrote: >> That statement is really irrelevant because this is the submitter, = what was the crypt() behavior back in the 2.0 days? Did anyone in = FreeBSD verify this statement? Why was that behavior not restored, as = opposed to chaining the default encryption algorithm. If login.conf was = lost, mangled, etc in the old days, you would still get md5/sha1/=85/etc = encryption, now you just get DES. >>=20 >> I think the security implications of this change should have required = a bigger review, like at least sign off from = security-officer@freebsd.org >>=20 >> If this was a POSIX compatibility issue, that should have been = evaluated and reviewed properly. It feels there were not enough eyes on = this change and if as you say this is not affected the default passwd = algorithm, that should have also been noted in the Errata note. >>=20 >> - JimP >>=20 >> On Oct 24, 2014, at 8:48 AM, Ronald Klop = wrote: >>=20 >>> Hi, >>>=20 >>> I have nothing to do with the actual coding, but please reread = comment 7 from the bug report: >>> 'This doesn't have anything common with system default password = encryption, this is realized using /etc/login.conf and applications like = passwd, etc.' >>>=20 >>> Regards, >>> Ronald. >>>=20 >>> On Fri, 24 Oct 2014 15:21:48 +0200, Jim Pirzyk = wrote: >>>=20 >>>> I think this should be reopened and reverted. This is the wrong = answer and has not taken into account the history of crypt() on FreeBSD. = I point you to the svn log: >>>>=20 >>>> http://svnweb.freebsd.org/base?view=3Drevision&revision=3D4246 >>>>=20 >>>> and >>>>=20 >>>> http://www.freebsd.org/releases/2.0/notes.html >>>>=20 >>>> If password security for FreeBSD is all you need, and you have no >>>> requirement for copying encrypted passwords from different hosts = (Suns, >>>> DEC machines, etc) into FreeBSD password entries, then FreeBSD's = MD5 >>>> based security may be all you require! We feel that our default = security >>>> model is more than a match for DES, and without any messy export = issues >>>> to deal with. If you're outside (or even inside) the U.S., give it = a try! >>>>=20 >>>> We are reversing 20+ years of FreeBSD progress. >>>>=20 >>>> - JimP >>>>=20 >>>> On Oct 24, 2014, at 8:11 AM, Ronald Klop = wrote: >>>>=20 >>>>> See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D192277 >>>>>=20 >>>>> Regards, >>>>> Ronald. >>>>>=20 >>>>> On Fri, 24 Oct 2014 13:14:20 +0200, Jim Pirzyk = wrote: >>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> I was wondering if there is more information about this change? = FreeBSD changed the default away from DES to MD5 back in the 1.1.5 -> = 2.0 transition. It seems to me a downgrade and rewarding bad = programming to be changing back to DES now. Also the proper course of = action is to correct programs that make the wrong assumption about what = crypt() changes. >>>>>>=20 >>>>>> Thanks >>>>>>=20 >>>>>> - JimP >>>>>>=20 >>>>>> On Oct 22, 2014, at 4:07 PM, FreeBSD Errata Notices = wrote: >>>>>>=20 >>>>>>> Signed PGP part >>>>>>> = =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 >>>>>>> FreeBSD-EN-14:11.crypt = Errata Notice >>>>>>> The = FreeBSD Project >>>>>>>=20 >>>>>>> Topic: crypt(3) default hashing algorithm >>>>>>>=20 >>>>>>> Category: core >>>>>>> Module: libcrypt >>>>>>> Announced: 2014-10-22 >>>>>>> Affects: FreeBSD 9.3 and FreeBSD 10.0-STABLE after = 2014-05-11 and >>>>>>> before 2014-10-16. >>>>>>> Corrected: 2014-10-13 15:56:47 UTC (stable/10, = 10.1-PRERELEASE) >>>>>>> 2014-10-16 21:39:04 UTC (releng/10.1, 10.1-RC3) >>>>>>> 2014-10-16 21:39:04 UTC (releng/10.1, 10.1-RC2-p2) >>>>>>> 2014-10-16 21:39:04 UTC (releng/10.1, 10.1-RC1-p2) >>>>>>> 2014-10-16 21:39:04 UTC (releng/10.1, = 10.1-BETA3-p2) >>>>>>> 2014-10-21 21:09:54 UTC (stable/9, 9.3-STABLE) >>>>>>> 2014-10-21 23:50:46 UTC (releng/9.3, = 9.3-RELEASE-p4) >>>>>>>=20 >>>>>>> For general information regarding FreeBSD Errata Notices and = Security >>>>>>> Advisories, including descriptions of the fields above, security >>>>>>> branches, and the following sections, please visit >>>>>>> . >>>>>>>=20 >>>>>>> I. Background >>>>>>>=20 >>>>>>> The crypt(3) function performs password hashing. Different = algorithms >>>>>>> of varying strength are available, with older, weaker algorithms = being >>>>>>> retained for compatibility. >>>>>>>=20 >>>>>>> The crypt(3) function was originally based on the DES encryption >>>>>>> algorithm and generated a 13-character hash from an = eight-character >>>>>>> password (longer passwords were truncated) and a two-character = salt. >>>>>>>=20 >>>>>>> II. Problem Description >>>>>>>=20 >>>>>>> In recent FreeBSD releases, the default algorithm for crypt(3) = was >>>>>>> changed to SHA-512, which generates a much longer hash than the >>>>>>> traditional DES-based algorithm. >>>>>>>=20 >>>>>>> III. Impact >>>>>>>=20 >>>>>>> Many applications assume that crypt(3) always returns a = traditional DES >>>>>>> hash, and blindly copy it into a short buffer without bounds = checks. This >>>>>>> may lead to a variety of undesirable results including, at = worst, crashing >>>>>>> the application. >>>>>>>=20 >>>>>>> IV. Workaround >>>>>>>=20 >>>>>>> No workaround is available. >>>>>>>=20 >>>>>>> V. Solution >>>>>>>=20 >>>>>>> Perform one of the following: >>>>>>>=20 >>>>>>> 1) Upgrade your system to a supported FreeBSD stable or release = / security >>>>>>> branch (releng) dated after the correction date. >>>>>>>=20 >>>>>>> 2) To update your present system via a source code patch: >>>>>>>=20 >>>>>>> The following patches have been verified to apply to the = applicable >>>>>>> FreeBSD release branches. >>>>>>>=20 >>>>>>> a) Download the relevant patch from the location below, and = verify the >>>>>>> detached PGP signature using your PGP utility. >>>>>>>=20 >>>>>>> # fetch http://security.FreeBSD.org/patches/EN-14:11/crypt.patch >>>>>>> # fetch = http://security.FreeBSD.org/patches/EN-14:11/crypt.patch.asc >>>>>>> # gpg --verify crypt.patch.asc >>>>>>>=20 >>>>>>> b) Apply the patch. Execute the following commands as root: >>>>>>>=20 >>>>>>> # cd /usr/src >>>>>>> # patch < /path/to/patch >>>>>>>=20 >>>>>>> c) Recompile the operating system using buildworld and = installworld as >>>>>>> described in = . >>>>>>>=20 >>>>>>> Restart all deamons using the library, or reboot the system. >>>>>>>=20 >>>>>>> 3) To update your system via a binary patch: >>>>>>>=20 >>>>>>> Systems running a RELEASE version of FreeBSD on the i386 or = amd64 >>>>>>> platforms can be updated via the freebsd-update(8) utility: >>>>>>>=20 >>>>>>> # freebsd-update fetch >>>>>>> # freebsd-update install >>>>>>>=20 >>>>>>> VI. Correction details >>>>>>>=20 >>>>>>> The following list contains the revision numbers of each file = that was >>>>>>> corrected in FreeBSD. >>>>>>>=20 >>>>>>> Branch/path = Revision >>>>>>> = ------------------------------------------------------------------------- >>>>>>> stable/9/ = r273425 >>>>>>> releng/9.3/ = r273438 >>>>>>> stable/10/ = r273043 >>>>>>> releng/10.1/ = r273187 >>>>>>> = ------------------------------------------------------------------------- >>>>>>>=20 >>>>>>> To see which files were modified by a particular revision, run = the >>>>>>> following command, replacing NNNNNN with the revision number, on = a >>>>>>> machine with Subversion installed: >>>>>>>=20 >>>>>>> # svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base >>>>>>>=20 >>>>>>> Or visit the following URL, replacing NNNNNN with the revision = number: >>>>>>>=20 >>>>>>> = >>>>>>>=20 >>>>>>> VII. References >>>>>>>=20 >>>>>>> The latest revision of this Errata Notice is available at >>>>>>> = http://security.FreeBSD.org/advisories/FreeBSD-EN-14:11.crypt.asc >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> freebsd-announce@freebsd.org mailing list >>>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-announce >>>>>>> To unsubscribe, send any mail to = "freebsd-announce-unsubscribe@freebsd.org" >>>>>>=20 >>>>>> --- @(#) $Id: dot.signature,v 1.15 2007/12/27 15:06:13 pirzyk Exp = $ >>>>>> __o jim@pirzyk.org = -------------------------------------------------- >>>>>> _'\<,_ >>>>>> (*)/ (*) I'd rather be out biking. >>>>=20 >>>> --- @(#) $Id: dot.signature,v 1.15 2007/12/27 15:06:13 pirzyk Exp $ >>>> __o jim@pirzyk.org = -------------------------------------------------- >>>> _'\<,_ >>>> (*)/ (*) I'd rather be out biking. >>=20 >> --- @(#) $Id: dot.signature,v 1.15 2007/12/27 15:06:13 pirzyk Exp $ >> __o jim@pirzyk.org = -------------------------------------------------- >> _'\<,_ >> (*)/ (*) I'd rather be out biking. >>=20 --- @(#) $Id: dot.signature,v 1.15 2007/12/27 15:06:13 pirzyk Exp $ __o jim@pirzyk.org = -------------------------------------------------- _'\<,_ (*)/ (*) I'd rather be out biking. --Apple-Mail=_6EB7C021-CF36-4694-87F1-9AF483B62067 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 - http://gpgtools.org iFcDBQFUSqpo+2AFq07nokoRCHJzAP9Fm5WrOvcWHFLsyujigDl6fpprkmMDTZe8 tu+GKvrmIQD8Dsn3aiQZr5b8+CrcIxYWVEnh49ChSfnxjBRexpsPxoo= =Fzvv -----END PGP SIGNATURE----- --Apple-Mail=_6EB7C021-CF36-4694-87F1-9AF483B62067-- From owner-freebsd-stable@FreeBSD.ORG Fri Oct 24 20:03:59 2014 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 BA1F9C77; Fri, 24 Oct 2014 20:03:59 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (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 9BAAB780; Fri, 24 Oct 2014 20:03:59 +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 31AE11486A; Fri, 24 Oct 2014 13:03:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1414181033; x=1414195433; bh=/4ttxBbS2jaVH8dwqKAo+U6krue2gkatyFrOMNdlVGw=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=owdBPPYaAbfkHf7Cy/MUUD0WEyiCUAZ4a2YNRiDUE48npPIEMih9HI2SGcDySoDCL 0GYYkU1hwhc4YBPc7ISBUf1pW1uKpin5OYm0j5SWIxIQo6MxgKjeuMBsZrh11SynKI 8vbIblxVGb7X2TlBrXmglMK6thP6azCQ0YST7yBo= Message-ID: <544AB0A9.8030808@delphij.net> Date: Fri, 24 Oct 2014 13:03:53 -0700 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: Jim Pirzyk , Ronald Klop Subject: Re: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-14:11.crypt References: <201410222107.s9ML7nLC010739@freefall.freebsd.org> <23061782-21F6-4509-9362-2DAEED692F72@freeBSD.org> In-Reply-To: <23061782-21F6-4509-9362-2DAEED692F72@freeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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, 24 Oct 2014 20:03:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 10/24/14 09:18, Jim Pirzyk wrote: > That statement is really irrelevant because this is the submitter, > what was the crypt() behavior back in the 2.0 days? Did anyone in FreeBSD's crypt(3) returns DES hash since FreeBSD 4.4. I don't think the previous behavior really matter here, especially with Peter's reasoning in r70421 on 2000/12/28: === Hindsight is wonderful, but I got cold feet over the crypt(3) default so I am backing it out for now. The problem is that some random program calling crypt() could be passing a DES salt and the crypt(3) library would encrypt it in md5 mode and there would be a password mismatch as a result. I wrote a validater function for the DES code to verify that a salt is valid for DES, but I realized there were too many strange things to go wrong. passwd(1), pw(8) etc still generate md5 passwords by default for /etc/master.passwd, so this is almost academic. It is a big deal for things that have their own crypt(3)-ed password strings (.htaccess, etc etc). Those are the things I do not want to break. My DES salt recognizer basically checked if the salt was either 2 or 13 characters long, or began with '_' (_PASSWORD_EFMT1). I think it would have worked but I have seen way too much crypt() mishandling in the past. === > FreeBSD verify this statement? Why was that behavior not > restored, as opposed to chaining the default encryption algorithm. > If login.conf was lost, mangled, etc in the old days, you would > still get md5/sha1/…/etc encryption, now you just get DES. If your login.conf was lost, mangled, etc., and you are still running a FreeBSD release that is older than FreeBSD 4.4-RELEASE, it's an owned system already. > I think the security implications of this change should have > required a bigger review, like at least sign off from > security-officer@freebsd.org All security advisories and errata notices are signed off by the Security Officer. Both Dag-Erling and I have considered the change for quite some time before it was made. > If this was a POSIX compatibility issue, that should have been > evaluated and reviewed properly. It feels there were not enough > eyes on this change and if as you say this is not affected the > default passwd algorithm, that should have also been noted in the > Errata note. It's not a POSIX compliance issue, at least not what I am aware of, as POSIX did not mandate the use of any algorithm by default, or what algorithms should be supported. It is, however, the default behavior of everyone else. Linux's glibc defaults to DES, OpenBSD's libc defaults to DES, so does Illumos, and all recent FreeBSD releases except 9.3-RELEASE. Given the fact that the change of crypt(3) default hash algorithm *does* *NOT* change the system default of password hashing algorithm (SHA512 currently, and tweakable via login.conf(5)), we do not believe it would hurt or weaken your safety, and therefore doesn't worth it to cause the subtle ABI breakage that breaks application in real world. Cheers, > > - JimP > > On Oct 24, 2014, at 8:48 AM, Ronald Klop > wrote: > >> Hi, >> >> I have nothing to do with the actual coding, but please reread >> comment 7 from the bug report: 'This doesn't have anything >> common with system default password encryption, this is realized >> using /etc/login.conf and applications like passwd, etc.' >> >> Regards, Ronald. >> >> On Fri, 24 Oct 2014 15:21:48 +0200, Jim Pirzyk >> wrote: >> >>> I think this should be reopened and reverted. This is the >>> wrong answer and has not taken into account the history of >>> crypt() on FreeBSD. I point you to the svn log: >>> >>> http://svnweb.freebsd.org/base?view=revision&revision=4246 >>> >>> and >>> >>> http://www.freebsd.org/releases/2.0/notes.html >>> >>> If password security for FreeBSD is all you need, and you have >>> no requirement for copying encrypted passwords from different >>> hosts (Suns, DEC machines, etc) into FreeBSD password entries, >>> then FreeBSD's MD5 based security may be all you require! We >>> feel that our default security model is more than a match for >>> DES, and without any messy export issues to deal with. If >>> you're outside (or even inside) the U.S., give it a try! >>> >>> We are reversing 20+ years of FreeBSD progress. >>> >>> - JimP >>> >>> On Oct 24, 2014, at 8:11 AM, Ronald Klop >>> wrote: >>> >>>> See: >>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192277 >>>> >>>> Regards, Ronald. >>>> >>>> On Fri, 24 Oct 2014 13:14:20 +0200, Jim Pirzyk >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> I was wondering if there is more information about this >>>>> change? FreeBSD changed the default away from DES to MD5 >>>>> back in the 1.1.5 -> 2.0 transition. It seems to me a >>>>> downgrade and rewarding bad programming to be changing >>>>> back to DES now. Also the proper course of action is to >>>>> correct programs that make the wrong assumption about what >>>>> crypt() changes. >>>>> >>>>> Thanks >>>>> >>>>> - JimP >>>>> >>>>> On Oct 22, 2014, at 4:07 PM, FreeBSD Errata Notices >>>>> wrote: >>>>> >>>>>> Signed PGP part >>>>>> ============================================================================= >>>>>> >>>>>> >>>>>> FreeBSD-EN-14:11.crypt Errata Notice >>>>>> The FreeBSD Project >>>>>> >>>>>> Topic: crypt(3) default hashing algorithm >>>>>> >>>>>> Category: core Module: libcrypt Announced: >>>>>> 2014-10-22 Affects: FreeBSD 9.3 and FreeBSD >>>>>> 10.0-STABLE after 2014-05-11 and before 2014-10-16. >>>>>> Corrected: 2014-10-13 15:56:47 UTC (stable/10, >>>>>> 10.1-PRERELEASE) 2014-10-16 21:39:04 UTC (releng/10.1, >>>>>> 10.1-RC3) 2014-10-16 21:39:04 UTC (releng/10.1, >>>>>> 10.1-RC2-p2) 2014-10-16 21:39:04 UTC (releng/10.1, >>>>>> 10.1-RC1-p2) 2014-10-16 21:39:04 UTC (releng/10.1, >>>>>> 10.1-BETA3-p2) 2014-10-21 21:09:54 UTC (stable/9, >>>>>> 9.3-STABLE) 2014-10-21 23:50:46 UTC (releng/9.3, >>>>>> 9.3-RELEASE-p4) >>>>>> >>>>>> For general information regarding FreeBSD Errata Notices >>>>>> and Security Advisories, including descriptions of the >>>>>> fields above, security branches, and the following >>>>>> sections, please visit >>>>>> . >>>>>> >>>>>> I. Background >>>>>> >>>>>> The crypt(3) function performs password hashing. >>>>>> Different algorithms of varying strength are available, >>>>>> with older, weaker algorithms being retained for >>>>>> compatibility. >>>>>> >>>>>> The crypt(3) function was originally based on the DES >>>>>> encryption algorithm and generated a 13-character hash >>>>>> from an eight-character password (longer passwords were >>>>>> truncated) and a two-character salt. >>>>>> >>>>>> II. Problem Description >>>>>> >>>>>> In recent FreeBSD releases, the default algorithm for >>>>>> crypt(3) was changed to SHA-512, which generates a much >>>>>> longer hash than the traditional DES-based algorithm. >>>>>> >>>>>> III. Impact >>>>>> >>>>>> Many applications assume that crypt(3) always returns a >>>>>> traditional DES hash, and blindly copy it into a short >>>>>> buffer without bounds checks. This may lead to a variety >>>>>> of undesirable results including, at worst, crashing the >>>>>> application. >>>>>> >>>>>> IV. Workaround >>>>>> >>>>>> No workaround is available. >>>>>> >>>>>> V. Solution >>>>>> >>>>>> Perform one of the following: >>>>>> >>>>>> 1) Upgrade your system to a supported FreeBSD stable or >>>>>> release / security branch (releng) dated after the >>>>>> correction date. >>>>>> >>>>>> 2) To update your present system via a source code >>>>>> patch: >>>>>> >>>>>> The following patches have been verified to apply to the >>>>>> applicable FreeBSD release branches. >>>>>> >>>>>> a) Download the relevant patch from the location below, >>>>>> and verify the detached PGP signature using your PGP >>>>>> utility. >>>>>> >>>>>> # fetch >>>>>> http://security.FreeBSD.org/patches/EN-14:11/crypt.patch >>>>>> # fetch >>>>>> http://security.FreeBSD.org/patches/EN-14:11/crypt.patch.asc >>>>>> >>>>>> >>>>>> # gpg --verify crypt.patch.asc >>>>>> >>>>>> b) Apply the patch. Execute the following commands as >>>>>> root: >>>>>> >>>>>> # cd /usr/src # patch < /path/to/patch >>>>>> >>>>>> c) Recompile the operating system using buildworld and >>>>>> installworld as described in >>>>>> . >>>>>> >>>>>> Restart all deamons using the library, or reboot the >>>>>> system. >>>>>> >>>>>> 3) To update your system via a binary patch: >>>>>> >>>>>> Systems running a RELEASE version of FreeBSD on the i386 >>>>>> or amd64 platforms can be updated via the >>>>>> freebsd-update(8) utility: >>>>>> >>>>>> # freebsd-update fetch # freebsd-update install >>>>>> >>>>>> VI. Correction details >>>>>> >>>>>> The following list contains the revision numbers of each >>>>>> file that was corrected in FreeBSD. >>>>>> >>>>>> Branch/path Revision >>>>>> ------------------------------------------------------------------------- >>>>>> >>>>>> >>>>>> stable/9/ r273425 >>>>>> releng/9.3/ r273438 stable/10/ r273043 releng/10.1/ >>>>>> r273187 >>>>>> ------------------------------------------------------------------------- >>>>>> >>>>>> >>>>>> >>>>>> To see which files were modified by a particular revision, run the >>>>>> following command, replacing NNNNNN with the revision >>>>>> number, on a machine with Subversion installed: >>>>>> >>>>>> # svn diff -cNNNNNN --summarize >>>>>> svn://svn.freebsd.org/base >>>>>> >>>>>> Or visit the following URL, replacing NNNNNN with the >>>>>> revision number: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> VII. References >>>>>> >>>>>> The latest revision of this Errata Notice is available at >>>>>> >>>>>> http://security.FreeBSD.org/advisories/FreeBSD-EN-14:11.crypt.asc >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> freebsd-announce@freebsd.org mailing list >>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-announce >>>>>> To unsubscribe, send any mail to >>>>>> "freebsd-announce-unsubscribe@freebsd.org" >>>>> >>>>> --- @(#) $Id: dot.signature,v 1.15 2007/12/27 15:06:13 >>>>> pirzyk Exp $ __o jim@pirzyk.org >>>>> -------------------------------------------------- _'\<,_ >>>>> (*)/ (*) I'd rather be out biking. >>> >>> --- @(#) $Id: dot.signature,v 1.15 2007/12/27 15:06:13 pirzyk >>> Exp $ __o jim@pirzyk.org >>> -------------------------------------------------- _'\<,_ (*)/ >>> (*) I'd rather be out biking. > > --- @(#) $Id: dot.signature,v 1.15 2007/12/27 15:06:13 pirzyk Exp $ > __o jim@pirzyk.org > -------------------------------------------------- _'\<,_ (*)/ (*) > I'd rather be out biking. > - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0 iQIcBAEBCgAGBQJUSrCoAAoJEJW2GBstM+nsjLIP/j03SQaje0RAAsAbt29M5jEq 5dRdqn9Dk8eL/rLxt41/M5+CTTgdErkrlUq+M9SKTT8qBYiS2MKHHjfdt7fbUw6d SnxWEcXTE0CHaY2fm/2dTDYKtYYdcHaEIIFB0x/Acx15xrxBhn7zNhpMyZzygynS VzLN9uwZi5y6Wq6v5k7D2dPKzsjlKCdRrLPX9Ad2qdw4YzptzQWfvr45ueiaVq12 fEBRsZqxdodHBbsftGlUNMpbHxejmhT5az2N0Kvytk30v6nBumN+T4Uyd0YU2+8Z Ea7RSQY4Q50hoTytaeQFfYyEIMYtaXMA9M1i2Z8tRvTodve8dMr9QJkdrezOQ359 lOcFpgZ36KGVlwzRL6PuaVyLIOtndFEfNOHUkmAmaz8t8kKVkkiBT1h60tz8NaXP SOQeXNbPrXlXd/KCSvSz4Wgb1cuL7DR9DE6Q6Ghyxd6bCJFnu919WS2lftUDm9f2 UvgA5XhdsHJbmUfAPB865SDUVi+gascDSDJdTI2XZOa37KAvPTtTw0gHRoLCx0Cs 52fp+9XsAHw7WiH1URhAxLbt484D2V0eq6IvK+if7FKoKecOxBkMGwRVVSfYXliu XG8HYlPQFnHGczaSVDYC0So7f1UqkUC6tVHo7FfxxS4B5cXKLmBN5OLGO1maI7sv TfiyjGJqk/sTzUN4Opu/ =0bFd -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Fri Oct 24 20:08:23 2014 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 6894ADAD; Fri, 24 Oct 2014 20:08:23 +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 479C47B5; Fri, 24 Oct 2014 20:08:23 +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 ECF2E1490E; Fri, 24 Oct 2014 13:08:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1414181303; x=1414195703; bh=5JmaQmIs/xjXd4p51mXWd1FTHxAPDZDxeyoAE1TpzZk=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=cPxdkKoT72tQlMwAYTTPRqTRayCAQEwnmHLZfdTbnW8CU/5qqPy0XpXu3bpaa5xIX s9Dpm5dOVPR7U5ArWP83n0h/W1LVk1NGFSnO+1O99NtyUzCnQLgeRJvOFNShGcnGXY w/uY2h/C7v9OBLz5oe80lT+vDaKzQpAEChvOB/Wo= Message-ID: <544AB1B6.2050302@delphij.net> Date: Fri, 24 Oct 2014 13:08:22 -0700 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: Jim Pirzyk , Adrian Chadd Subject: Re: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-14:11.crypt References: <201410222107.s9ML7nLC010739@freefall.freebsd.org> <23061782-21F6-4509-9362-2DAEED692F72@freeBSD.org> <2FDC7048-E9A3-443B-BC38-CDE776CA1212@freeBSD.org> In-Reply-To: <2FDC7048-E9A3-443B-BC38-CDE776CA1212@freeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: FreeBSD Stable Mailing List , Ronald Klop , des@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, 24 Oct 2014 20:08:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 10/24/14 12:37, Jim Pirzyk wrote: > Is he the current security officer? If so it would have been nice > to see these issues addressed in the Errata announcement. He is. All Errata notifications are signed by Security Officer by the way. > I still don’t understand the reasons for backing out a change after > 20 years. No, it's a change about 8 months ago, not 20 years, and that change happened 8 months ago changed the default that was there for 13 years, which is also what everybody else do right now, and is known to break poorly written applications. > - JimP > > On Oct 24, 2014, at 12:43 PM, Adrian Chadd > wrote: > >> You mean like des@ ? >> >> >> >> -adrian >> >> On 24 October 2014 09:18, Jim Pirzyk wrote: >>> That statement is really irrelevant because this is the >>> submitter, what was the crypt() behavior back in the 2.0 days? >>> Did anyone in FreeBSD verify this statement? Why was that >>> behavior not restored, as opposed to chaining the default >>> encryption algorithm. If login.conf was lost, mangled, etc in >>> the old days, you would still get md5/sha1/…/etc encryption, >>> now you just get DES. >>> >>> I think the security implications of this change should have >>> required a bigger review, like at least sign off from >>> security-officer@freebsd.org >>> >>> If this was a POSIX compatibility issue, that should have been >>> evaluated and reviewed properly. It feels there were not >>> enough eyes on this change and if as you say this is not >>> affected the default passwd algorithm, that should have also >>> been noted in the Errata note. >>> >>> - JimP >>> >>> On Oct 24, 2014, at 8:48 AM, Ronald Klop >>> wrote: >>> >>>> Hi, >>>> >>>> I have nothing to do with the actual coding, but please >>>> reread comment 7 from the bug report: 'This doesn't have >>>> anything common with system default password encryption, this >>>> is realized using /etc/login.conf and applications like >>>> passwd, etc.' >>>> >>>> Regards, Ronald. >>>> >>>> On Fri, 24 Oct 2014 15:21:48 +0200, Jim Pirzyk >>>> wrote: >>>> >>>>> I think this should be reopened and reverted. This is the >>>>> wrong answer and has not taken into account the history of >>>>> crypt() on FreeBSD. I point you to the svn log: >>>>> >>>>> http://svnweb.freebsd.org/base?view=revision&revision=4246 >>>>> >>>>> and >>>>> >>>>> http://www.freebsd.org/releases/2.0/notes.html >>>>> >>>>> If password security for FreeBSD is all you need, and you >>>>> have no requirement for copying encrypted passwords from >>>>> different hosts (Suns, DEC machines, etc) into FreeBSD >>>>> password entries, then FreeBSD's MD5 based security may be >>>>> all you require! We feel that our default security model >>>>> is more than a match for DES, and without any messy export >>>>> issues to deal with. If you're outside (or even inside) >>>>> the U.S., give it a try! >>>>> >>>>> We are reversing 20+ years of FreeBSD progress. >>>>> >>>>> - JimP >>>>> >>>>> On Oct 24, 2014, at 8:11 AM, Ronald Klop >>>>> wrote: >>>>> >>>>>> See: >>>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192277 >>>>>> >>>>>> Regards, Ronald. >>>>>> >>>>>> On Fri, 24 Oct 2014 13:14:20 +0200, Jim Pirzyk >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I was wondering if there is more information about this >>>>>>> change? FreeBSD changed the default away from DES to >>>>>>> MD5 back in the 1.1.5 -> 2.0 transition. It seems to >>>>>>> me a downgrade and rewarding bad programming to be >>>>>>> changing back to DES now. Also the proper course of >>>>>>> action is to correct programs that make the wrong >>>>>>> assumption about what crypt() changes. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> - JimP >>>>>>> >>>>>>> On Oct 22, 2014, at 4:07 PM, FreeBSD Errata Notices >>>>>>> wrote: >>>>>>> >>>>>>>> Signed PGP part >>>>>>>> ============================================================================= >>>>>>>> >>>>>>>> FreeBSD-EN-14:11.crypt Errata Notice >>>>>>>> The FreeBSD Project >>>>>>>> >>>>>>>> Topic: crypt(3) default hashing algorithm >>>>>>>> >>>>>>>> Category: core Module: libcrypt >>>>>>>> Announced: 2014-10-22 Affects: FreeBSD >>>>>>>> 9.3 and FreeBSD 10.0-STABLE after 2014-05-11 and >>>>>>>> before 2014-10-16. Corrected: 2014-10-13 >>>>>>>> 15:56:47 UTC (stable/10, 10.1-PRERELEASE) 2014-10-16 >>>>>>>> 21:39:04 UTC (releng/10.1, 10.1-RC3) 2014-10-16 >>>>>>>> 21:39:04 UTC (releng/10.1, 10.1-RC2-p2) 2014-10-16 >>>>>>>> 21:39:04 UTC (releng/10.1, 10.1-RC1-p2) 2014-10-16 >>>>>>>> 21:39:04 UTC (releng/10.1, 10.1-BETA3-p2) 2014-10-21 >>>>>>>> 21:09:54 UTC (stable/9, 9.3-STABLE) 2014-10-21 >>>>>>>> 23:50:46 UTC (releng/9.3, 9.3-RELEASE-p4) >>>>>>>> >>>>>>>> For general information regarding FreeBSD Errata >>>>>>>> Notices and Security Advisories, including >>>>>>>> descriptions of the fields above, security branches, >>>>>>>> and the following sections, please visit >>>>>>>> . >>>>>>>> >>>>>>>> I. Background >>>>>>>> >>>>>>>> The crypt(3) function performs password hashing. >>>>>>>> Different algorithms of varying strength are >>>>>>>> available, with older, weaker algorithms being >>>>>>>> retained for compatibility. >>>>>>>> >>>>>>>> The crypt(3) function was originally based on the DES >>>>>>>> encryption algorithm and generated a 13-character >>>>>>>> hash from an eight-character password (longer >>>>>>>> passwords were truncated) and a two-character salt. >>>>>>>> >>>>>>>> II. Problem Description >>>>>>>> >>>>>>>> In recent FreeBSD releases, the default algorithm for >>>>>>>> crypt(3) was changed to SHA-512, which generates a >>>>>>>> much longer hash than the traditional DES-based >>>>>>>> algorithm. >>>>>>>> >>>>>>>> III. Impact >>>>>>>> >>>>>>>> Many applications assume that crypt(3) always returns >>>>>>>> a traditional DES hash, and blindly copy it into a >>>>>>>> short buffer without bounds checks. This may lead to >>>>>>>> a variety of undesirable results including, at worst, >>>>>>>> crashing the application. >>>>>>>> >>>>>>>> IV. Workaround >>>>>>>> >>>>>>>> No workaround is available. >>>>>>>> >>>>>>>> V. Solution >>>>>>>> >>>>>>>> Perform one of the following: >>>>>>>> >>>>>>>> 1) Upgrade your system to a supported FreeBSD stable >>>>>>>> or release / security branch (releng) dated after the >>>>>>>> correction date. >>>>>>>> >>>>>>>> 2) To update your present system via a source code >>>>>>>> patch: >>>>>>>> >>>>>>>> The following patches have been verified to apply to >>>>>>>> the applicable FreeBSD release branches. >>>>>>>> >>>>>>>> a) Download the relevant patch from the location >>>>>>>> below, and verify the detached PGP signature using >>>>>>>> your PGP utility. >>>>>>>> >>>>>>>> # fetch >>>>>>>> http://security.FreeBSD.org/patches/EN-14:11/crypt.patch >>>>>>>> >>>>>>>> # fetch http://security.FreeBSD.org/patches/EN-14:11/crypt.patch.asc >>>>>>>> # gpg --verify crypt.patch.asc >>>>>>>> >>>>>>>> b) Apply the patch. Execute the following commands >>>>>>>> as root: >>>>>>>> >>>>>>>> # cd /usr/src # patch < /path/to/patch >>>>>>>> >>>>>>>> c) Recompile the operating system using buildworld >>>>>>>> and installworld as described in >>>>>>>> . >>>>>>>> >>>>>>>> >>>>>>>> Restart all deamons using the library, or reboot the system. >>>>>>>> >>>>>>>> 3) To update your system via a binary patch: >>>>>>>> >>>>>>>> Systems running a RELEASE version of FreeBSD on the >>>>>>>> i386 or amd64 platforms can be updated via the >>>>>>>> freebsd-update(8) utility: >>>>>>>> >>>>>>>> # freebsd-update fetch # freebsd-update install >>>>>>>> >>>>>>>> VI. Correction details >>>>>>>> >>>>>>>> The following list contains the revision numbers of >>>>>>>> each file that was corrected in FreeBSD. >>>>>>>> >>>>>>>> Branch/path >>>>>>>> Revision >>>>>>>> ------------------------------------------------------------------------- >>>>>>>> >>>>>>>> stable/9/ r273425 >>>>>>>> releng/9.3/ >>>>>>>> r273438 stable/10/ >>>>>>>> r273043 releng/10.1/ >>>>>>>> r273187 >>>>>>>> ------------------------------------------------------------------------- >>>>>>>> >>>>>>>> >>>>>>>> To see which files were modified by a particular revision, run the >>>>>>>> following command, replacing NNNNNN with the revision >>>>>>>> number, on a machine with Subversion installed: >>>>>>>> >>>>>>>> # svn diff -cNNNNNN --summarize >>>>>>>> svn://svn.freebsd.org/base >>>>>>>> >>>>>>>> Or visit the following URL, replacing NNNNNN with the >>>>>>>> revision number: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> VII. References >>>>>>>> >>>>>>>> The latest revision of this Errata Notice is >>>>>>>> available at >>>>>>>> http://security.FreeBSD.org/advisories/FreeBSD-EN-14:11.crypt.asc >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> freebsd-announce@freebsd.org mailing list >>>>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-announce >>>>>>>> >>>>>>>> To unsubscribe, send any mail to "freebsd-announce-unsubscribe@freebsd.org" >>>>>>> >>>>>>> --- @(#) $Id: dot.signature,v 1.15 2007/12/27 15:06:13 >>>>>>> pirzyk Exp $ __o jim@pirzyk.org >>>>>>> -------------------------------------------------- >>>>>>> _'\<,_ (*)/ (*) I'd rather be out biking. >>>>> >>>>> --- @(#) $Id: dot.signature,v 1.15 2007/12/27 15:06:13 >>>>> pirzyk Exp $ __o jim@pirzyk.org >>>>> -------------------------------------------------- _'\<,_ >>>>> (*)/ (*) I'd rather be out biking. >>> >>> --- @(#) $Id: dot.signature,v 1.15 2007/12/27 15:06:13 pirzyk >>> Exp $ __o jim@pirzyk.org >>> -------------------------------------------------- _'\<,_ (*)/ >>> (*) I'd rather be out biking. >>> > > --- @(#) $Id: dot.signature,v 1.15 2007/12/27 15:06:13 pirzyk Exp > $ __o jim@pirzyk.org > -------------------------------------------------- _'\<,_ (*)/ (*) > I'd rather be out biking. > - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0 iQIcBAEBCgAGBQJUSrG2AAoJEJW2GBstM+nsL7wP/Rxu+1ZCXTbGerqNXwbOMOgq 4sxqYb1qzbu5VUS07D8eJ85+IoLtzPM+2kXWerfE38tDRBl7rTTXzcgNV73VhJnX 01mV7J2KHJYZhW0hK3xCTkMn2Z9Ib/wT+u1I7OrcqrQNOA3ROkKUB39KLMP2tISB ae1kvooO59yywi4+YTHXN0fY8BSSCvTYfRGL32/qhFU4j1X7ZWQ1CipBESbMg5C2 7o1cgPGNjdLO4jMlkANM6YyvX2ZfbTURMHlWrX+NdXjJdxs0EUtEyVTMRG5XkCGw FrXYRurpNq8U6wF/8RPhDO/qARDI7566sdQv2EnZmFdAudRcwLlk8Hc9xrhgjwWA 4r5CsmSNJsji6Xwymb+zUXGmNgXo/6HOClEDv+hmbzVILJtTUwEp0hrAPhL2szjQ QtTb3E4ulkyZ8ma4tdjfg+Jm+CClVpnV+PJCoFY9q1gKdyb9V9LPlhUALiBPilhI r3kQJaYgy01LRy2ydwV1+Zai4LPQrpfKeXiqr6C+WXtaOX9ea2CYzrRgVb1jnP0y MLr1E+CP7OqCLLgpnC5MXzeZtDueZGE5+6hrorKl04nuyMb7lDlnArF+adSztJS3 xduboTNpHXBwi6gcEW8oYMKY8x6c8fl1dYUYrgsClOMNpycPE/R2mmZd2LVX73kd buDBmofRCYTGJgbtzf51 =ljm9 -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Fri Oct 24 23:07:30 2014 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 0C1F06EF for ; Fri, 24 Oct 2014 23:07:30 +0000 (UTC) Received: from mithlond.kdm.org (mithlond.kdm.org [70.56.43.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "A1-33714", Issuer "A1-33714" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B3C72BAC for ; Fri, 24 Oct 2014 23:07:29 +0000 (UTC) Received: from mithlond.kdm.org (localhost [127.0.0.1]) by mithlond.kdm.org (8.14.9/8.14.9) with ESMTP id s9ON7QXD052313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 24 Oct 2014 17:07:26 -0600 (MDT) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.14.9/8.14.9/Submit) id s9ON7Qgm052312; Fri, 24 Oct 2014 17:07:26 -0600 (MDT) (envelope-from ken) Date: Fri, 24 Oct 2014 17:07:26 -0600 From: "Kenneth D. Merry" To: Harald Schmalzbauer Subject: Re: sa(4) 9.2->10.1, nsa0.0: request ptr 0x803135040 is not on a page boundary; cannot split request Message-ID: <20141024230725.GA50845@mithlond.kdm.org> References: <54494E92.5010007@omnilan.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54494E92.5010007@omnilan.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [127.0.0.1]); Fri, 24 Oct 2014 17:07:26 -0600 (MDT) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mithlond.kdm.org 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, 24 Oct 2014 23:07:30 -0000 On Thu, Oct 23, 2014 at 20:53:06 +0200, Harald Schmalzbauer wrote: > Hello, > > I read about the changes in sa(4) regarding large-block-split changes > and the transitional 'kern.cam.sa.allow_io_split' workarround. > > I'm using bacula (7.0.5) and my previous neccessarry multi-blocking > adjustmets like "Minimum block size = 2097152" obviously didn't work > with FreebSD 10.1 anymore. > Good news is, they are not needed any more! > With the default of 126 blocks (64512) I get 60-140MB/s with btape(8)'s > speed test on my LTO4 (HH) drive and another quick test showed that > using mbuffer(1) for zfs(8) 'send' isn't needed anymore (| dd > of=/dev/nsa0 bs=64512 seems to max out LTO4 speed). [with FreeBSD 9 the > transfer rates were some magnitudes lower with these block size settings!] > > Not so good news is, that bacula can't read the tape's label. > 'Labeling a tape (with 'label' at bconsole(8) or btape(8)) is > successful, and btape(8)'s 'readlabel' partially displays the correct > label, but not the very beginning of the label: > Volume Label: > Id : **error**VerNo > ?rest OK > > While it should read: > Volume Label: > Id : Bacula 1.0 immortal > VerNo : 11 > ? > > When btape(8) starts to read the label, the _subject's error is reported_: > *nsa0.0: request ptr 0x803135040 is not on a page boundary; cannot split > request* What blocksize are you using with btape(8)? What kind of controller are you using? The reason you get that error message is that the sa(4) driver goes through physio(9) to get buffers from userland into the kernel. physio(9) relies on the vmapbuf()/vunmapbuf() routines to map buffers in and out of the kernel. vmapbuf() operates with a page granularity. The address to be mapped has to start on a page boundary. It also uses kernel virtual address segments that are MAXPHYS in size. On x86 boxes at least, MAXPHYS is 128KB. So if you use a blocksize of 128KB, but pass in a pointer that doesn't start on a page boundary, vmapbuf() will have to map 33 pages instead of 32. In your case, it will have to start at page address 0x803135000, and will need 33 4KB pages, which is greater than 128KB. This behavior obviously isn't very user friendly. If you want to avoid the problem, try setting your blocksize in Bacula to 4K less than what is reported in kern.cam.sa.0.maxio. If it's 131072, then set the blocksize to 126976. Another way to avoid the problem is to increase MAXPHYS. Increasing it beyond kern.cam.sa.0.cpi_maxio won't help anything. If you increase it too much, you can run into other problems. That said, though, you can probably bump it to 512K without much worry. Put this in your kernel config file and recompile/reinstall your kernel: options MAXPHYS="(512*1024)" options DFLTPHYS="(512*1024)" The same thing applies, though -- you'll want to set your blocksize to 1 page less than kern.cam.sa.0.maxio, since Bacula isn't using page-aligned buffers. > The same error show up if I configure bacula to use a fixed block size > of kern.cam.sa.0.maxio (131072). At that (i.e. the physio(9)) level, variable vs. fixed block mode won't matter. > Like expected, allowing split (with kern.cam.sa.allow_io_split in > loader.conf) works arround that problem. > But I'd like to understand why I cannot set kern.cam.sa.0.maxio resp. > why btape(8) doesn't work 100% correct although blocksize < sa.0.maxio See above. The unfortunate thing is that with the above setup, I think you'll wind up with a bigger block and then a smaller block going onto the tape in variable block mode at least. This is an example of why I/O splitting is bad -- you don't have good visibility from userland into exactly how things are getting put on tape. The application writes out what it wants, but it doesn't know what size blocks are hitting the tape. > I don't have enough understanding to check the code myself, if it's a > cam/sa(4) issue in FreeBSD or a problem in btape(8) (and also bacula > itself, most likely the tool shares the code with bacula's storage deamon). > > Any hints highly appreciated! I have considered implementing a custom read/write routine in the sa(4) driver to get around some of these issues, but it will require more than just sa(4) driver modifications for everything to work optimally. With a custom read/write routine, if we copied data into the kernel, we could essentially allow any I/O size that the controller and tape drive support without altering MAXPHYS. And alignment issues wouldn't matter, either. The drawback is that we wouldn't be able to do unmapped I/O for drivers that support it. (Unless the user happened to give us a single buffer that we could send down as an unmapped I/O.) The unmapped I/O code doesn't currently handle scatter/gather lists of unmapped buffers. Another drawback to copying is the increased overhead of versus unmapped I/O. Although on modern hardware, copying is usually more efficient than mapping user memory into the kernel's virtual address space, because of the TLB shootdowns that happen with the mapping operation. For tape users with just one tape drive, the overhead wouldn't be a big deal. If you have lots of tape drives attached to one machine, though, it could have a noticable effect. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-stable@FreeBSD.ORG Sat Oct 25 00:11:37 2014 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 5E75C580 for ; Sat, 25 Oct 2014 00:11:37 +0000 (UTC) Received: from mail.akips.com (mail.akips.com [65.19.130.19]) by mx1.freebsd.org (Postfix) with ESMTP id 4B3FB144 for ; Sat, 25 Oct 2014 00:11:36 +0000 (UTC) Received: from akips.com (CPE-120-146-191-2.static.qld.bigpond.net.au [120.146.191.2]) by mail.akips.com (Postfix) with ESMTPSA id 2AB9212 for ; Sat, 25 Oct 2014 10:04:21 +1000 (EST) Date: Sat, 25 Oct 2014 10:04:07 +1000 From: Paul Koch To: FreeBSD Stable Subject: 10.1 RC3 mmap NO_SYNC regression looks good Message-ID: <20141025100407.730e53b3@akips.com> Organization: AKIPS X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY, URIBL_BLOCKED autolearn=disabled version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on host1.akips.com 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, 25 Oct 2014 00:11:37 -0000 I must have missed any mention this being fixed in RC3, but see vm_fault.c was recently updated. The previous behaviour in the beta's and RC1/2 was fairly tragic for us because we have largish mmap'ed files using NO_SYNC. I updated one of our test boxes (5:30pm yesterday) from 10.0p9 to 10.1RC3 and looks good now. When we tried the BETAs, disk activity sky rocketed and performance dropped off a cliff. http://www.akips.com/gz/downloads/system-graphs-10.1-rc3-24h.html http://www.akips.com/gz/downloads/system-graphs-10.1-rc3-48h.html Not sure why there was a drop in memory usage though, so we'll investigate that. Paul. -- Paul Koch | Founder, CEO AKIPS Network Monitor http://www.akips.com Brisbane, Australia From owner-freebsd-stable@FreeBSD.ORG Sat Oct 25 01:59:06 2014 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 3B0DCD48 for ; Sat, 25 Oct 2014 01:59:06 +0000 (UTC) Received: from mail15.tpgi.com.au (smtp-out15.tpgi.com.au [220.244.226.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.tpg.com.au", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BDCF2C85 for ; Sat, 25 Oct 2014 01:59:04 +0000 (UTC) X-TPG-Junk-Status: Message not scanned X-TPG-Antivirus: Passed X-TPG-Abuse: host=[202.161.115.54]; ip=202.161.115.54; date=Sat, 25 Oct 2014 12:42:02 +1100 Received: from fish.ish.com.au (202-161-115-54.static.tpgi.com.au [202.161.115.54] (may be forged)) by mail15.tpgi.com.au (envelope-from ari@ish.com.au) (8.14.3/8.14.3) with ESMTP id s9P1g0qx018029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 25 Oct 2014 12:42:02 +1100 Received: from ip-211.ish.com.au ([203.29.62.211]:55169 helo=ish.com.au) by fish.ish.com.au with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XhC6u-0002iy-2Q for freebsd-stable@freebsd.org; Thu, 23 Oct 2014 17:43:01 +1100 Received: from [203.29.62.136] (HELO ip-136.ish.com.au) by ish.com.au (CommuniGate Pro SMTP 6.0.9) with ESMTPS id 17775516 for freebsd-stable@freebsd.org; Thu, 23 Oct 2014 17:43:00 +1100 Message-ID: <5448A373.1070707@ish.com.au> Date: Thu, 23 Oct 2014 17:42:59 +1100 From: Aristedes Maniatis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 To: freebsd-stable Subject: pkgng upgrade -> force upgrade of dependencies 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: Sat, 25 Oct 2014 01:59:06 -0000 I've scoured the documentation, but I cannot for the life of me figure how to do this. Let's say I want to upgrade a package "apache22" without upgrading everything on the system. Now I want to ensure I get enough of the dependencies into the upgrade that apache will actually work. So I try this: # pkg upgrade apache22-worker-mpm Installed packages to be UPGRADED: apache22-worker-mpm: 2.2.27_6 -> 2.2.29_2 Hmmm, that doesn't seem right. # pkg upgrade | grep openssl openssl: 1.0.1_15 -> 1.0.1_16 # pkg info -d apache22-worker-mpm apache22-worker-mpm-2.2.27_6: expat-2.1.0_1 openssl-1.0.1_15 perl5-5.16.3_11 pcre-8.34_2 apr-1.5.1.1.5.3_4 libiconv-1.14_3 So, a new version of openssl is needed and is linked to the new binary. But it will not be installed when I upgrade apache. Before I moved to pkgng/poudriere I used to use portmaster. That would more thoroughly examine the dependencies and make sure everything that was inter-related (both as parent and child dependencies) was upgraded together. But it did not force me to upgrade Java when I just wanted to get the new version of bash installed. Am I missing something? # pkg -v 1.3.8 Thanks Ari -- --------------------------> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From owner-freebsd-stable@FreeBSD.ORG Sat Oct 25 04:09:51 2014 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 A74F06A7; Sat, 25 Oct 2014 04:09:51 +0000 (UTC) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CAED0AAC; Sat, 25 Oct 2014 04:09:50 +0000 (UTC) Received: by mail-la0-f48.google.com with SMTP id gi9so3625537lab.35 for ; Fri, 24 Oct 2014 21:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qr/rXrJooVx762BNCGeZLQJlZqU3HKlQPWZ7sfLtm3c=; b=WzXiAEUVBlMrMqT/7YZNZen8mlrPCHCXS9274zlbszRKQdM3fXfRlmOEMp9ul61pge ApDZann6s3YTVVx78AyM4v0v5ezokZ/p8ajDDsaovQOXTwz1x9SPKm4yHK6x8298GsRF Y5XtdV86om+h+185/fVDgyjD9WAkM7r8Tjw2LHGWtFg0k4Yco641NOvsCDHSMg4L/1S/ Cj1ELosJxuXHoDysWwAblW1252aCVRbXxwO1Ub/DCjNnhTH8w92241nY7FzxjniplePY /xti57eDYguRh5icA9QANm50eIn/f5pHhI2amsZJZfLi3GDMb6S2K0KPFp3I3BiDFjGv 6B3A== MIME-Version: 1.0 X-Received: by 10.152.198.166 with SMTP id jd6mr7354418lac.81.1414210188680; Fri, 24 Oct 2014 21:09:48 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.84.197 with HTTP; Fri, 24 Oct 2014 21:09:48 -0700 (PDT) In-Reply-To: <20141024053636.GH11222@dft-labs.eu> References: <20141024053636.GH11222@dft-labs.eu> Date: Fri, 24 Oct 2014 21:09:48 -0700 X-Google-Sender-Auth: yE4uALWkHkllRY-YNfQm8cqtUco Message-ID: Subject: Re: Automatically running /usr/tests on stable/10 branch under Jenkins From: Craig Rodrigues To: Mateusz Guzik Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-testing@freebsd.org" , FreeBSD stable , "freebsd-virtualization@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: Sat, 25 Oct 2014 04:09:51 -0000 On Thu, Oct 23, 2014 at 10:36 PM, Mateusz Guzik wrote: > > (1) does a buildworld/buildkernel on amd64 when someone checks new > > code into the stable/10 branch > > Is not this excessive? It has not been a problem. For example, when a build occurs on the HEAD in svn, if further commits come in on HEAD, we have Jenkins configured so that it will not trigger another build on HEAD until the build in progress is done. It has been working fine. If no commits > > (2) Creates a bootable UFS image with makefs > > any chance zfs will be used as well? > Sure, we can look at that as well, but as I said earlier, there need to be more bodies working on setting up builds and configurations for this to happen. > > would be nice to run some kind of stress testing. buildworld with a high > -j is an example of a general purpose test. This could be done with > different frequency than regular tests. > > Are you volunteering to write the scripts that incorporate any stress testing that you think should be done? We would welcome any contributions. > Do you have crashdumps configured in case stuff goes wrong? > > No. You can look at our scripts used to build and boot the various VM's: https://wiki.freebsd.org/Jenkins#Repositories It's all on github, so if you think you have new scripts to add, or fixes to existing scripts, you can feel free to do a github pull request to contribute. -- Craig From owner-freebsd-stable@FreeBSD.ORG Sat Oct 25 04:20:22 2014 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 91E15B78; Sat, 25 Oct 2014 04:20:22 +0000 (UTC) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 88044C7A; Sat, 25 Oct 2014 04:20:21 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id f15so2308328lbj.13 for ; Fri, 24 Oct 2014 21:20:19 -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=eMt+sDIlpJGnS5JxkXDSZT1TZb/JCTw7KbaGM6giSrs=; b=UeQM8xvCXsqRKV6SmVW5SbTXzz2XCs6ubWveIwV6nz0icQD2gVI4rkXsjecJKFD67i zpnGcQsakvW2BoUc1jfDM+TALGNRpCHbG8Kb3Hx3TtOzIa6vRqYYwn2yWZmq+iaePXZd AyxK7IhTVb3TNeqI0fPouQv8cTmzCD+oSBQK4IflUyosMwV5wBmIKacJhOvuX+MVT+qp kA6NI9sxAUcxZMruv/6hLcH5UeC/fU9XnAf7Nn0IDUarZt+X2VwgMKE3xRrAg/hDq6cO giT1zrdxlqJFEL1+/QSsBaBTzR9RUM+haRfxDBAQQzcEOMt8ZpFgwhBXpvJyqCunzER0 gQsA== MIME-Version: 1.0 X-Received: by 10.152.22.135 with SMTP id d7mr8544867laf.46.1414210819435; Fri, 24 Oct 2014 21:20:19 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.84.197 with HTTP; Fri, 24 Oct 2014 21:20:19 -0700 (PDT) In-Reply-To: References: <20141024053636.GH11222@dft-labs.eu> Date: Fri, 24 Oct 2014 21:20:19 -0700 X-Google-Sender-Auth: T2JiUvJPzpUzUjMpVLkU7vfsiW0 Message-ID: Subject: Re: Automatically running /usr/tests on stable/10 branch under Jenkins From: Craig Rodrigues To: "K. Macy" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-testing@freebsd.org" , FreeBSD stable , "freebsd-virtualization@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: Sat, 25 Oct 2014 04:20:22 -0000 On Thu, Oct 23, 2014 at 11:06 PM, K. Macy wrote: > >> (2) Creates a bootable UFS image with makefs > > > > any chance zfs will be used as well? > > > > Seconded. There are residual locking issues issues in ZFS. > Particularly in the less exercised areas. > I think what would be an interesting exercise is to set up a Jenkins job to build and boot a bhyve VM with ZFS, and then run the ZFS Test Suite, ported by Alan Somers to FreeBSD: https://lists.freebsd.org/pipermail/freebsd-testing/2014-August/000503.html Are there any volunteers who would like to help set that up and get it running under Jenkins? > > Along those same lines, do you have any sort of watchdog in case it > deadlocks? > No. You can look at our scripts used to build and boot the various VM's: https://wiki.freebsd.org/Jenkins#Repositories It's all on github, so if you think you have new scripts to add, or fixes to existing scripts, you can feel free to do a github pull request to contribute. -- Craig From owner-freebsd-stable@FreeBSD.ORG Sat Oct 25 04:45:24 2014 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 988EF1FD; Sat, 25 Oct 2014 04:45:24 +0000 (UTC) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4F233ED4; Sat, 25 Oct 2014 04:45:24 +0000 (UTC) Received: by mail-pd0-f173.google.com with SMTP id v10so2550832pde.18 for ; Fri, 24 Oct 2014 21:45:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=sakTeGSANXio1+THlQlVOipJbwfFO0ckzcxpaeBzyjs=; b=j37WmbuziOXpvv4R8d4Rc9dgyMs3m0ee61g6tF64kqx+EhRAvzw4F35j9ZSZ+jWgsg UjEovt54uSSu+F5mDnmZZVNtBCnmrvWl9K0n2NTyS34W0T0NTR3FyZlFVf70NXSEXr+z OFs6NTLGCkdoUiNN0O5vLobRrmKmo2O2X2Y3vwkpRwAJ0vLSbPiifxCZihG+ClYXeWHC JUKT/C4DXNaXElnXVrQKrGO0NmNL1tLNeJkHixEqKrPRynz0uCUzSvtz3ACOLV3jutnx NOD35Ax+V5IWzoJ7Dp+pxO8zZmfSh4J0OysunnpNHeN6ttf8V8Y5DC/Fg0Hf+oxZYcaA HTpg== X-Received: by 10.70.11.2 with SMTP id m2mr8980923pdb.31.1414212323759; Fri, 24 Oct 2014 21:45:23 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:4d3d:33a4:5ddc:37e2? ([2601:8:ab80:7d6:4d3d:33a4:5ddc:37e2]) by mx.google.com with ESMTPSA id uj7sm5210916pac.4.2014.10.24.21.45.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 Oct 2014 21:45:23 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_2A11CEE8-A629-491F-891F-17FC136ECA72"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Automatically running /usr/tests on stable/10 branch under Jenkins From: Garrett Cooper In-Reply-To: Date: Fri, 24 Oct 2014 21:45:21 -0700 Message-Id: <81030948-E60F-4AAD-AAF1-16349607917D@gmail.com> References: <20141024053636.GH11222@dft-labs.eu> To: Craig Rodrigues X-Mailer: Apple Mail (2.1878.6) Cc: "freebsd-testing@freebsd.org" , FreeBSD stable , "K. Macy" , "freebsd-virtualization@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: Sat, 25 Oct 2014 04:45:24 -0000 --Apple-Mail=_2A11CEE8-A629-491F-891F-17FC136ECA72 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 24, 2014, at 21:20, Craig Rodrigues wrote: > On Thu, Oct 23, 2014 at 11:06 PM, K. Macy wrote: >=20 >>>> (2) Creates a bootable UFS image with makefs >>>=20 >>> any chance zfs will be used as well? >>>=20 >>=20 >> Seconded. There are residual locking issues issues in ZFS. >> Particularly in the less exercised areas. >>=20 >=20 > I think what would be an interesting exercise is to set up a Jenkins = job to > build > and boot a bhyve VM with ZFS, and then run > the ZFS Test Suite, ported by Alan Somers to FreeBSD: >=20 > = https://lists.freebsd.org/pipermail/freebsd-testing/2014-August/000503.htm= l >=20 >=20 > Are there any volunteers who would like to help set that up and get it > running > under Jenkins? I think getting tools/regression/zfs working first would be a better = idea (which means that ZFS developers will need to go debug/fix the = issue noted in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D191574 = ). I=92ll go ahead and commit my fixes to head from my github fork so it = runs. Alan also suggested against integrating the test suite as-is, because as = he said, "Remember, don't run these tests on a production system. They = WILL cause panics and deadlocks, and they may cause data loss too.=94 Cheers, -Garrett --Apple-Mail=_2A11CEE8-A629-491F-891F-17FC136ECA72 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 iQEcBAEBCgAGBQJUSyrhAAoJEMZr5QU6S73eQq0H/i1iKoeG+vYhyEgN5rLuis5b T7p5Vv5CLpCt0hiWcaAnKw6pRXLHS+NZpp2iaMg6El7C4E9XOAMYPrD6Lf5FSSyO 6jlBZ7NpNuTG7oo8SDe8uC3aHvEf8pw+XMNroAkLliRKrjGGkY7wsoD8IdlMTebT 6jAvMcszrEo6o8q2zi1kNZfT0y64US49htX7mVqxRVsDgvNSJMMsBlTzDigo4aGj rqlkL6WYaWus8XJr0rLXgLzFFNkb/6RsEDA258bA7lR+upordi375fhYCOJ0R6Rh C8l+EQOb18dcsh3d3WQRNF7Blt0O0lht+TL0AcnH4MZtslJLBsl/9fDzW1fLZKM= =psgR -----END PGP SIGNATURE----- --Apple-Mail=_2A11CEE8-A629-491F-891F-17FC136ECA72-- From owner-freebsd-stable@FreeBSD.ORG Sat Oct 25 05:11:15 2014 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 E3B15608; Sat, 25 Oct 2014 05:11:14 +0000 (UTC) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9A2C711F; Sat, 25 Oct 2014 05:11:14 +0000 (UTC) Received: by mail-pd0-f174.google.com with SMTP id p10so2570141pdj.33 for ; Fri, 24 Oct 2014 22:11:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=HQGvuTqDSbBI1h/rjkmmVCseB8iLUxwQ9KzKGEcIAJI=; b=Oayd24Qyh407XMyqb0JfzKScBq7WHCOp/zLZ7rWhSVXedqIWXpW6KqKPGVty/jpPU3 /iGsrICiHGEwI5AM8QawUIZPOfuhUR32bNY3XGNq/GqYFKjb17tLjZ6pxnn0/7BeR90v EN5sp+6fP/KzAvLR00Yxk6JGzFUbzsOEukf9UFrZTUsfD6YyVk5LdM45MWsL/AUb2wgL 2Aod0mSCEjHphPMPY/p70KBhCRBrvyQg/L1LJErYzklkEjACkRWKjJyh2T5bpBJIPeB3 jVny7B/WsN01LgLrd2zKHTcxDdhGWeY7T350BCvoit2KtQwJuFxygeYRV1XKYTlN0wEb HioQ== X-Received: by 10.68.246.229 with SMTP id xz5mr25945pbc.131.1414213874088; Fri, 24 Oct 2014 22:11:14 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:4d3d:33a4:5ddc:37e2? ([2601:8:ab80:7d6:4d3d:33a4:5ddc:37e2]) by mx.google.com with ESMTPSA id g2sm5218951pdk.46.2014.10.24.22.11.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 Oct 2014 22:11:13 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_51EBB7D1-6870-4412-A765-22F9D16DF84A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Automatically running /usr/tests on stable/10 branch under Jenkins From: Garrett Cooper In-Reply-To: <81030948-E60F-4AAD-AAF1-16349607917D@gmail.com> Date: Fri, 24 Oct 2014 22:11:11 -0700 Message-Id: <2D7ED585-8A72-462F-9F3E-1C67C620AC72@gmail.com> References: <20141024053636.GH11222@dft-labs.eu> <81030948-E60F-4AAD-AAF1-16349607917D@gmail.com> To: Craig Rodrigues X-Mailer: Apple Mail (2.1878.6) Cc: "freebsd-testing@freebsd.org" , FreeBSD stable , "K. Macy" , "freebsd-virtualization@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: Sat, 25 Oct 2014 05:11:15 -0000 --Apple-Mail=_51EBB7D1-6870-4412-A765-22F9D16DF84A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 24, 2014, at 21:45, Garrett Cooper wrote: > On Oct 24, 2014, at 21:20, Craig Rodrigues = wrote: >=20 >> On Thu, Oct 23, 2014 at 11:06 PM, K. Macy wrote: >>=20 >>>>> (2) Creates a bootable UFS image with makefs >>>>=20 >>>> any chance zfs will be used as well? >>>>=20 >>>=20 >>> Seconded. There are residual locking issues issues in ZFS. >>> Particularly in the less exercised areas. >>>=20 >>=20 >> I think what would be an interesting exercise is to set up a Jenkins = job to >> build >> and boot a bhyve VM with ZFS, and then run >> the ZFS Test Suite, ported by Alan Somers to FreeBSD: >>=20 >> = https://lists.freebsd.org/pipermail/freebsd-testing/2014-August/000503.htm= l >>=20 >>=20 >> Are there any volunteers who would like to help set that up and get = it >> running >> under Jenkins? >=20 > I think getting tools/regression/zfs working first would be a better = idea (which means that ZFS developers will need to go debug/fix the = issue noted inhttps://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D191574 = ). I=92ll go ahead and commit my fixes to head from my github fork so it = runs. Might have helped if I had referenced the appropriate bug: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D191573 (I=92m = basically fixing = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D191574 right now). Cheers! --Apple-Mail=_51EBB7D1-6870-4412-A765-22F9D16DF84A 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 iQEcBAEBCgAGBQJUSzDvAAoJEMZr5QU6S73eARAH/1P3uHc6LPrjW0rvbl4aTn4D e54PyOxQ/XEoy5MhauP8Wj3rg7HJn6/jcqtPldVQ2w8l0qzIbhiQOzL/Y93zknW8 yzKUAhkvd+5h2KmwxFK/u+fLAvK2UPurYTiJ1RC+UTiaA+8E+RlUH6iUjwl93JFo qp2SVDTxW7xbMq6Tmni8YKl4ZTcVlyPynRoKiVf7JJoy67oQPhOCWeTf8piaXI+x SYhgfetOvPl7ny8EnP3tHHqkg96ewpEqSs4ne0YQ4BejaBJwyQh/+H1rw2Nt6Af0 LTPv35Thnfr0tj2RBkcMaVsvNvkecKcws5SxPCatkNMRoRgFmbwJLhAMsTHi+10= =0kRo -----END PGP SIGNATURE----- --Apple-Mail=_51EBB7D1-6870-4412-A765-22F9D16DF84A-- From owner-freebsd-stable@FreeBSD.ORG Sat Oct 25 06:44:10 2014 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 C95F77D2; Sat, 25 Oct 2014 06:44:10 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id B01CCB08; Sat, 25 Oct 2014 06:44:10 +0000 (UTC) Received: from u10-2-32-011.office.norse-data.com (unknown [50.204.88.51]) by elvis.mu.org (Postfix) with ESMTPSA id 9D56F341F86A; Fri, 24 Oct 2014 23:44:10 -0700 (PDT) Message-ID: <544B46BA.4000008@freebsd.org> Date: Fri, 24 Oct 2014 23:44:10 -0700 From: Alfred Perlstein Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Garrett Cooper , Craig Rodrigues Subject: Re: Automatically running /usr/tests on stable/10 branch under Jenkins References: <20141024053636.GH11222@dft-labs.eu> <81030948-E60F-4AAD-AAF1-16349607917D@gmail.com> In-Reply-To: <81030948-E60F-4AAD-AAF1-16349607917D@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "freebsd-testing@freebsd.org" , FreeBSD stable , "freebsd-virtualization@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: Sat, 25 Oct 2014 06:44:10 -0000 On 10/24/14 9:45 PM, Garrett Cooper wrote: > On Oct 24, 2014, at 21:20, Craig Rodrigues wrote: > >> On Thu, Oct 23, 2014 at 11:06 PM, K. Macy wrote: >> >>>>> (2) Creates a bootable UFS image with makefs >>>> any chance zfs will be used as well? >>>> >>> Seconded. There are residual locking issues issues in ZFS. >>> Particularly in the less exercised areas. >>> >> I think what would be an interesting exercise is to set up a Jenkins job to >> build >> and boot a bhyve VM with ZFS, and then run >> the ZFS Test Suite, ported by Alan Somers to FreeBSD: >> >> https://lists.freebsd.org/pipermail/freebsd-testing/2014-August/000503.html >> >> >> Are there any volunteers who would like to help set that up and get it >> running >> under Jenkins? > I think getting tools/regression/zfs working first would be a better idea (which means that ZFS developers will need to go debug/fix the issue noted in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191574 ). I’ll go ahead and commit my fixes to head from my github fork so it runs. > > Alan also suggested against integrating the test suite as-is, because as he said, "Remember, don't run these tests on a production system. They WILL cause panics and deadlocks, and they may cause data loss too.” > > Cheers, > -Garrett Wait, we want to sweep those bugs under the rug? What exactly is wrong with making a test harness that can very easily reproduce a known problem? The chances are that anyone will dive into it once the bug is easily reproducible. -Alfred From owner-freebsd-stable@FreeBSD.ORG Sat Oct 25 06:48:04 2014 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 D6465A25; Sat, 25 Oct 2014 06:48:04 +0000 (UTC) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8B496B2F; Sat, 25 Oct 2014 06:48:04 +0000 (UTC) Received: by mail-pd0-f171.google.com with SMTP id r10so2660083pdi.30 for ; Fri, 24 Oct 2014 23:48:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=0W9DkqfiAld4WGNwRxVReCOvtZ/9P41LPKGt4Nci47w=; b=epVQvQOiEMDjjCGFLuY7SL5ke0xemxc8uTqDhVvyNveauSg6B9i8NJi8DnCp3U7vlU zbzCv0QK1I/jKkB70joNDOpMDkBSnR9JVznMLxbYUsqJvOXhWYVDMpN2TzgKFd5GLsK5 dhvnvmP0yXtj0Oi1ees9sCOvSyBtJNWDdXEVgO7dLKmWf8MzDFl4yqYM9PXu4KZ9AMXS 3kG+E40gcOtaHKcNgVCYUkh6+q5IifYCAkj0f6joAo6Lpr7WLo5wbHnn9lD4r/BS55Hf w7UdNjs4a+6tf8gJSeq6EcV20eBBdxKg8rKfrlN/xDsexhnnRZa/otfm/CPLDh4INnzZ FOCw== X-Received: by 10.68.213.101 with SMTP id nr5mr9344918pbc.81.1414219684005; Fri, 24 Oct 2014 23:48:04 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:4d3d:33a4:5ddc:37e2? ([2601:8:ab80:7d6:4d3d:33a4:5ddc:37e2]) by mx.google.com with ESMTPSA id nq2sm5418288pdb.74.2014.10.24.23.48.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 Oct 2014 23:48:03 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_FDB23D5C-BB5E-410D-95B3-35CE9ACBE165"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Automatically running /usr/tests on stable/10 branch under Jenkins From: Garrett Cooper In-Reply-To: <544B46BA.4000008@freebsd.org> Date: Fri, 24 Oct 2014 23:48:01 -0700 Message-Id: References: <20141024053636.GH11222@dft-labs.eu> <81030948-E60F-4AAD-AAF1-16349607917D@gmail.com> <544B46BA.4000008@freebsd.org> To: Alfred Perlstein X-Mailer: Apple Mail (2.1878.6) Cc: Craig Rodrigues , "freebsd-testing@freebsd.org" , FreeBSD stable , "freebsd-virtualization@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: Sat, 25 Oct 2014 06:48:05 -0000 --Apple-Mail=_FDB23D5C-BB5E-410D-95B3-35CE9ACBE165 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 24, 2014, at 23:44, Alfred Perlstein wrote: > On 10/24/14 9:45 PM, Garrett Cooper wrote: >> On Oct 24, 2014, at 21:20, Craig Rodrigues = wrote: >>=20 >>> On Thu, Oct 23, 2014 at 11:06 PM, K. Macy wrote: >>>=20 >>>>>> (2) Creates a bootable UFS image with makefs >>>>> any chance zfs will be used as well? >>>>>=20 >>>> Seconded. There are residual locking issues issues in ZFS. >>>> Particularly in the less exercised areas. >>>>=20 >>> I think what would be an interesting exercise is to set up a Jenkins = job to >>> build >>> and boot a bhyve VM with ZFS, and then run >>> the ZFS Test Suite, ported by Alan Somers to FreeBSD: >>>=20 >>> = https://lists.freebsd.org/pipermail/freebsd-testing/2014-August/000503.htm= l >>>=20 >>>=20 >>> Are there any volunteers who would like to help set that up and get = it >>> running >>> under Jenkins? >> I think getting tools/regression/zfs working first would be a better = idea (which means that ZFS developers will need to go debug/fix the = issue noted in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D191574 = ). I=92ll go ahead and commit my fixes to head from my github fork so it = runs. >>=20 >> Alan also suggested against integrating the test suite as-is, because = as he said, "Remember, don't run these tests on a production system. = They WILL cause panics and deadlocks, and they may cause data loss too.=94= >>=20 >> Cheers, >> -Garrett >=20 > Wait, we want to sweep those bugs under the rug? What exactly is = wrong with making a test harness that can very easily reproduce a known = problem? The chances are that anyone will dive into it once the bug is = easily reproducible. Sweeping bugs under the rug is not what I plan on doing; I=92m = marking these as expected failures, as opposed to having them = continually panic a machine. Once a ZFS dev takes a look at the issue = and resolves them, then the ZFS dev can remove the =93bail=94 calls I=92m = adding to the testcases. Cheers, -Garrett PS FWIW the panics are recent. As I stated in the first bug, it didn=92t = occur on 10.0-RELEASE. --Apple-Mail=_FDB23D5C-BB5E-410D-95B3-35CE9ACBE165 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 iQEcBAEBCgAGBQJUS0eiAAoJEMZr5QU6S73ejxcIALZRkCzcpT6cfWtwDIgts2rz 5zUOJHgmExFkkijOtd7m9HEFnQQcEDQ8JJ0P/s6Fvol2/gKfRCtjd51+ip2Dj8ya g67V81qOxTFomCWo9VxWMWaBtPsowP8wwG/ZL0QkKCYQlLQITNNVu8/FsKODpIbm IKja9Bk97du9oI7+1T6L0FvkRvvk7m7MJxkzI373HKTb6+hmmt7YK9jRQ7fh5efG Qy7Ce4UUAffr6V/PHqhVvxZLiZkSa69hnY9MaAKXkVRPvIgUFTFhdYTCKqw7L8Ua vJx+zflZEzCnA2a9NC0Llcf0roNsnPV/E11F5vBzhhIY1ICx2dx2Gj99298zHPE= =pm2N -----END PGP SIGNATURE----- --Apple-Mail=_FDB23D5C-BB5E-410D-95B3-35CE9ACBE165-- From owner-freebsd-stable@FreeBSD.ORG Sat Oct 25 09:38:42 2014 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 79D0D7B0; Sat, 25 Oct 2014 09:38:42 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 04C6EC5D; Sat, 25 Oct 2014 09:38:41 +0000 (UTC) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s9P9ccgg013571; Sat, 25 Oct 2014 11:38:38 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 35E993066; Sat, 25 Oct 2014 11:38:38 +0200 (CEST) Message-ID: <544B6F97.7010808@omnilan.de> Date: Sat, 25 Oct 2014 11:38:31 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Kenneth D. Merry" Subject: Re: sa(4) 9.2->10.1, nsa0.0: request ptr 0x803135040 is not on a page boundary; cannot split request References: <54494E92.5010007@omnilan.de> <20141024230725.GA50845@mithlond.kdm.org> In-Reply-To: <20141024230725.GA50845@mithlond.kdm.org> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig17D5E8A7EF21E5FDEBEBF205" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Sat, 25 Oct 2014 11:38:38 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) 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: Sat, 25 Oct 2014 09:38:42 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig17D5E8A7EF21E5FDEBEBF205 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Bez=FCglich Kenneth D. Merry's Nachricht vom 25.10.2014 01:07 (localtime= ): =85 >> When btape(8) starts to read the label, the _subject's error is report= ed_: >> *nsa0.0: request ptr 0x803135040 is not on a page boundary; cannot spl= it >> request* > What blocksize are you using with btape(8)? > > What kind of controller are you using? Hello and thanks a lot for your very avaluable explanations! had no block size set in the bacula(-sd) configuration. Btape(8) consults the same config file, so I thought it's probably bacula's default of 64512, but if I correctly understood your explanation later, it's more likely it's starting with kern.cam.sa.0.maxio, which doesn't work because of the non-page-aligned address!?! My LTO4 is connected via a mps(4), LSISAS2008. > The reason you get that error message is that the sa(4) driver goes thr= ough > physio(9) to get buffers from userland into the kernel. physio(9) reli= es > on the vmapbuf()/vunmapbuf() routines to map buffers in and out of the > kernel. > > vmapbuf() operates with a page granularity. The address to be mapped h= as > to start on a page boundary. It also uses kernel virtual address segme= nts > that are MAXPHYS in size. On x86 boxes at least, MAXPHYS is 128KB. So is it correct that kern.cam.sa.0.maxio =3D MAXPHYS? > So if you use a blocksize of 128KB, but pass in a pointer that doesn't > start on a page boundary, vmapbuf() will have to map 33 pages instead o= f > 32. In your case, it will have to start at page address 0x803135000, a= nd > will need 33 4KB pages, which is greater than 128KB. > > This behavior obviously isn't very user friendly.=20 > > If you want to avoid the problem, try setting your blocksize in Bacula = to > 4K less than what is reported in kern.cam.sa.0.maxio. If it's 131072, = then > set the blocksize to 126976. > > Another way to avoid the problem is to increase MAXPHYS. Increasing it= > beyond kern.cam.sa.0.cpi_maxio won't help anything. If you increase > it too much, you can run into other problems. > > That said, though, you can probably bump it to 512K without much worry.= > Put this in your kernel config file and recompile/reinstall your kernel= : > > options MAXPHYS=3D"(512*1024)" > options DFLTPHYS=3D"(512*1024)" > > The same thing applies, though -- you'll want to set your blocksize to = 1 > page less than kern.cam.sa.0.maxio, since Bacula isn't using page-align= ed > buffers. Ah, ok =96 =93unaligned buffers=94. I think I understood the reason for t= he message. That's enough for me for now; probably btape(8) attempts acessing the tape with kern.cam.sa.0.maxio, not bacula's default of 64512. What I haven't understood entirely is DFLTPHYS and the whole physio(9) chain down to the magnetic tape :-( But at least now I have an idea and your advise to increase DFLTPHYS, so I did that and will do some tests. I knew of that options before, but I didn't want to tune anything I can't estimate it's impact=85 Thanks a lot, -Harry --------------enig17D5E8A7EF21E5FDEBEBF205 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlRLb50ACgkQLDqVQ9VXb8inQwCgi8KogN2qPCZFLG1p/8ZxVmxE 33IAnibzVjZ0AQ/t/AXdl07tXIClikYs =xN/T -----END PGP SIGNATURE----- --------------enig17D5E8A7EF21E5FDEBEBF205-- From owner-freebsd-stable@FreeBSD.ORG Sat Oct 25 11:26:48 2014 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 92BFB989 for ; Sat, 25 Oct 2014 11:26:48 +0000 (UTC) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2D627902 for ; Sat, 25 Oct 2014 11:26:48 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id bs8so2996449wib.17 for ; Sat, 25 Oct 2014 04:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=GC9nugQBBTvo30tA4PO5Z5aKN2kw81On/xSHPuBGbBY=; b=vovVVZCe0AgtLmeJpIOeSm3Uz1swxDhJXw2LYts2AnPyngETYXuZYhi24B1VxL0Nyk H8s/7cJ5/tyri5DWTOeV+JUXkeTZSnmdbNeMbHPAREsl/2S1QOIE2ZriTTJ/P6Esz3cN WHK8+NyF4kmLRq1A/KQhNx61nuJUR8rD9dQEMrVclYQOm9b30+VRw6aj4Rlor2RpFMVD 7jdBWUoJs/KoTMvAn9GWEe90JAhD/NbYUu0YD7JqZt1ce49rbptkzGwxauCnovXNu6WA qG0uw9MWAg+9U7GBKrqQ0KUQAItDjN9JAPJvk/jFewTBkr2Byjp+wx03k94n9utvocaq j4gQ== X-Received: by 10.180.39.237 with SMTP id s13mr919184wik.52.1414236406496; Sat, 25 Oct 2014 04:26:46 -0700 (PDT) Received: from hollewijn.internal (8d690a59.ftth.concepts.nl. [141.105.10.89]) by mx.google.com with ESMTPSA id cw6sm8518313wjb.18.2014.10.25.04.26.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 25 Oct 2014 04:26:45 -0700 (PDT) From: Alban Hertroys Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Dump time issues Message-Id: <6978A7BF-3CB7-4088-904D-5A60D755A04C@gmail.com> Date: Sat, 25 Oct 2014 13:26:43 +0200 To: freebsd-stable Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) 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, 25 Oct 2014 11:26:48 -0000 I=92m seeing something odd in my dump output that I didn=92t notice = before: Dumping /root... DUMP: WARNING: should use -L when dumping live read-write filesystems! DUMP: Date of this level 6 dump: Sat Oct 25 12:43:08 2014 DUMP: Date of last level 0 dump: Sun Feb 23 01:38:22 2014 DUMP: Dumping /dev/mirror/root (/) to standard output DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 178184276 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: 2.43% done, finished in 3:20 at Sat Oct 25 16:09:41 2014 DUMP: 5.35% done, finished in 2:57 at Sat Oct 25 15:51:18 2014 DUMP: 6.98% done, finished in 3:19 at Sat Oct 25 16:19:11 2014 DUMP: 9.14% done, finished in 3:18 at Sat Oct 25 16:22:57 2014 DUMP: 11.98% done, finished in 3:03 at Sat Oct 25 16:12:54 2014 DUMP: 14.35% done, finished in 2:59 at Sat Oct 25 16:13:20 2014 Note that the time is jumping back and forth and that these times are = several hours into the future: $> date Sat Oct 25 13:16:05 CEST 2014 It=92s probably harmless, but I thought I=92d ask. A quick search on = Google didn=92t turn up anything useful. System is: $> uname -a FreeBSD solfertje 9.3-STABLE FreeBSD 9.3-STABLE #12 r269624: Wed Aug 6 = 14:51:47 CEST 2014 foo@bar:/usr/obj/usr/src/sys/ANTELOPE amd64 P.S. Not using dump -L because that=92s a journaled UFS file system that = doesn=92t support snapshots. Cheers, Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll find there is no forest. From owner-freebsd-stable@FreeBSD.ORG Sat Oct 25 11:29:13 2014 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 58433A97 for ; Sat, 25 Oct 2014 11:29:13 +0000 (UTC) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E5642922 for ; Sat, 25 Oct 2014 11:29:12 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id h11so1025294wiw.8 for ; Sat, 25 Oct 2014 04:29:11 -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 :content-transfer-encoding:message-id:references:to; bh=KOnb4JqipF2wdIEfgw5eqV9e6DZCvv+yPBctWqIcpB8=; b=Ii7SdaAoG9cjHs0BNrLYvGj4+NZbAHeN0FDcgNliJ1XB+HJN6eY2u8shzh0zPUy73A JScGqUAhyHGnsiWP9d3B1NSOHZfWWs2HGPPQApBYdwwmtkCTe+Prj7vu/oeFqAEoURxr VfnTx2tdFghu0M3rhH/mdIxx5KMTI5FzqrIo2o9ZQb+SK1/00iuG+PhM9yf7bcwA72Xq hEyrvbjf12yg3FFDvQ5ae1ipBzet8UGTLaAPYYpnZ6BoBZU8H44SWWoY9k+mCfSqzVSl p5+Yljo+wWolJAWbWu3mABbH4g8DjrpogRpx4YIlXl7Fqf3D70RUxcr1xWsAbg8DIfHU js2g== X-Received: by 10.180.99.105 with SMTP id ep9mr1990467wib.82.1414236551050; Sat, 25 Oct 2014 04:29:11 -0700 (PDT) Received: from hollewijn.internal (8d690a59.ftth.concepts.nl. [141.105.10.89]) by mx.google.com with ESMTPSA id hu3sm8524721wjb.17.2014.10.25.04.29.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 25 Oct 2014 04:29:10 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Dump time issues (never mind) From: Alban Hertroys In-Reply-To: <6978A7BF-3CB7-4088-904D-5A60D755A04C@gmail.com> Date: Sat, 25 Oct 2014 13:29:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <951288DF-EEB8-4582-B289-C8A4394D71E7@gmail.com> References: <6978A7BF-3CB7-4088-904D-5A60D755A04C@gmail.com> To: freebsd-stable X-Mailer: Apple Mail (2.1878.6) 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, 25 Oct 2014 11:29:13 -0000 On 25 Oct 2014, at 13:26, Alban Hertroys wrote: > DUMP: 2.43% done, finished in 3:20 at Sat Oct 25 16:09:41 2014 > DUMP: 5.35% done, finished in 2:57 at Sat Oct 25 15:51:18 2014 > DUMP: 6.98% done, finished in 3:19 at Sat Oct 25 16:19:11 2014 > DUMP: 9.14% done, finished in 3:18 at Sat Oct 25 16:22:57 2014 > DUMP: 11.98% done, finished in 3:03 at Sat Oct 25 16:12:54 2014 > DUMP: 14.35% done, finished in 2:59 at Sat Oct 25 16:13:20 2014 >=20 > Note that the time is jumping back and forth and that these times are = several hours into the future: Doh, never mind! It=92s talking about the time it will be finished, = isn=92t it? I read it as current progress related to the percentage = done. Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll find there is no forest. From owner-freebsd-stable@FreeBSD.ORG Sat Oct 25 11:38:48 2014 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 BF209D59 for ; Sat, 25 Oct 2014 11:38:48 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7D36F9ED for ; Sat, 25 Oct 2014 11:38:47 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id s9PBckKK048912; Sat, 25 Oct 2014 04:38:46 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id s9PBcki6048911; Sat, 25 Oct 2014 04:38:46 -0700 (PDT) (envelope-from david) Date: Sat, 25 Oct 2014 04:38:46 -0700 From: David Wolfskill To: Alban Hertroys Subject: Re: Dump time issues Message-ID: <20141025113846.GY1235@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Alban Hertroys , freebsd-stable References: <6978A7BF-3CB7-4088-904D-5A60D755A04C@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="CmyYfwfsVa1xvDOW" Content-Disposition: inline In-Reply-To: <6978A7BF-3CB7-4088-904D-5A60D755A04C@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) 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: Sat, 25 Oct 2014 11:38:48 -0000 --CmyYfwfsVa1xvDOW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 25, 2014 at 01:26:43PM +0200, Alban Hertroys wrote: > I?m seeing something odd in my dump output that I didn?t notice before: >=20 > Dumping /root... > DUMP: WARNING: should use -L when dumping live read-write filesystems! (That, by the way, is pretty good advice in my experience.) > ... > DUMP: dumping (Pass IV) [regular files] > DUMP: 2.43% done, finished in 3:20 at Sat Oct 25 16:09:41 2014 > DUMP: 5.35% done, finished in 2:57 at Sat Oct 25 15:51:18 2014 > DUMP: 6.98% done, finished in 3:19 at Sat Oct 25 16:19:11 2014 > DUMP: 9.14% done, finished in 3:18 at Sat Oct 25 16:22:57 2014 > DUMP: 11.98% done, finished in 3:03 at Sat Oct 25 16:12:54 2014 > DUMP: 14.35% done, finished in 2:59 at Sat Oct 25 16:13:20 2014 >=20 > Note that the time is jumping back and forth and that these times are sev= eral hours into the future: >=20 > $> date > Sat Oct 25 13:16:05 CEST 2014 > .... Sure; they are estimates. They are issued every 5 minutes or so; the first is an estimate that the dump will take 3.33 hrs. (3:20) more time, and thus complete at 16:09:41. The second (5 minutes later) estimates that it will only take 2:57 more, and thus complete at 15:51:18; this pattern continues. dump(8) tends to require varying amounts of time to process a file system, depending on the population of files where it is working -- e.g., lots of tiny files, vs. a smaller number of large files; file where all the data blocks are "near" each other, vs. those where blocks are scattered all over the file system. It is thus normal for the estimates -- especially the earlier ones -- to vary considerably. Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --CmyYfwfsVa1xvDOW Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUS4vFXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7uhAQAITdK5M65+vWnCNn9jkjX17C D5BlfcK1YRP3kYioPbz25RNj9jPgHzz/KhVHBzeGNF5hPD38hrlIK5u7Z1WO/0Zt 8nOOForkwJLHpNZRBwnU86+WvCFoLJllwUnCPuqaAgnP7D0ivm4Qz2PSmCs8tWv8 KFwqrO5isW5qgyQd5wjrurnFGSr3MYfUmEnoug0eVcpv3DzDjDiqzE21l2gGj1UD OHGVvxLrFsEbDrCISZpUHDM98aoIo21HnbwF9bzgmA/iTZDEQoe2y1DByaNByobe k/PCX+EQgb32Lbnc1RRGbJW5ZHj3pQnh2/x49noEcJ0ZJ0VomZd2uGvpbTg3r49z 64Tqfk9hFDoHytYEozKjfXo9rMvc3MPpuqTxndn/MSAxBnsumXf1IXPCTYXBLVK9 az+wPHPAID2Nbh26wfb8sSbYRJRBAoMA6eaWAzXziba79hty10rusL2Q88rACTwP N2iawkpAy1uaHDjQthjTT6d5ZrnVwEhZ+EhDMCo7aPHoSATc/297QytuVrgEAEly n8fwheFTT9iZ6FmuUBAQMOtJZ6TJ4qtw18mUE4kZZjpVB5I7fpR1YQOCCuIr7wXL pxLMnSlR+mgOcO+Tp5ustD+mTW5h7NbTYMu6zRZ1Rd7qaEhB1Z4Ey4Gxtjv7PxXZ 5h6+Hu2Oone0cRKKcCta =3W2h -----END PGP SIGNATURE----- --CmyYfwfsVa1xvDOW-- From owner-freebsd-stable@FreeBSD.ORG Sat Oct 25 14:57:49 2014 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 753BC158 for ; Sat, 25 Oct 2014 14:57:49 +0000 (UTC) Received: from webmail2.jnielsen.net (webmail2.jnielsen.net [50.114.224.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "webmail2.jnielsen.net", Issuer "freebsdsolutions.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 53559FAB for ; Sat, 25 Oct 2014 14:57:48 +0000 (UTC) Received: from [192.168.2.123] (c-50-160-123-105.hsd1.ut.comcast.net [50.160.123.105]) (authenticated bits=0) by webmail2.jnielsen.net (8.14.9/8.14.9) with ESMTP id s9PEvdqZ043284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Oct 2014 08:57:44 -0600 (MDT) (envelope-from lists@jnielsen.net) X-Authentication-Warning: webmail2.jnielsen.net: Host c-50-160-123-105.hsd1.ut.comcast.net [50.160.123.105] claimed to be [192.168.2.123] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: pkgng upgrade -> force upgrade of dependencies From: John Nielsen X-Mailer: iPhone Mail (12B411) In-Reply-To: <5448A373.1070707@ish.com.au> Date: Sat, 25 Oct 2014 08:57:38 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <97F5BECA-C7D0-49EE-AC91-7B87A990307D@jnielsen.net> References: <5448A373.1070707@ish.com.au> To: Aristedes Maniatis 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: Sat, 25 Oct 2014 14:57:49 -0000 > On Oct 23, 2014, at 12:42 AM, Aristedes Maniatis wrote: >=20 > I've scoured the documentation, but I cannot for the life of me figure how= to do this. Let's say I want to upgrade a package "apache22" without upgrad= ing everything on the system. Now I want to ensure I get enough of the depen= dencies into the upgrade that apache will actually work. So I try this: >=20 > # pkg upgrade apache22-worker-mpm > Installed packages to be UPGRADED: > apache22-worker-mpm: 2.2.27_6 -> 2.2.29_2 >=20 > Hmmm, that doesn't seem right. >=20 > # pkg upgrade | grep openssl > openssl: 1.0.1_15 -> 1.0.1_16 >=20 > # pkg info -d apache22-worker-mpm > apache22-worker-mpm-2.2.27_6: > expat-2.1.0_1 > openssl-1.0.1_15 > perl5-5.16.3_11 > pcre-8.34_2 > apr-1.5.1.1.5.3_4 > libiconv-1.14_3 >=20 > So, a new version of openssl is needed and is linked to the new binary. Bu= t it will not be installed when I upgrade apache. >=20 >=20 > Before I moved to pkgng/poudriere I used to use portmaster. That would mor= e thoroughly examine the dependencies and make sure everything that was inte= r-related (both as parent and child dependencies) was upgraded together. But= it did not force me to upgrade Java when I just wanted to get the new versi= on of bash installed. I'm not certain that it handles dependencies (it ought to), but the document= ed way to upgrade selectively is via "pkg install pkgname ..." From owner-freebsd-stable@FreeBSD.ORG Sat Oct 25 15:02:53 2014 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 93FD12CB; Sat, 25 Oct 2014 15:02:53 +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 39C47F3; Sat, 25 Oct 2014 15:02:52 +0000 (UTC) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3jQ5Bw4hRSzb3H; Sat, 25 Oct 2014 17:02:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :references:subject:subject:mime-version:user-agent:from:from :date:date:message-id:received:received; s=mail; t=1414249350; x=1416063751; bh=jOdZQts3DDqVZVbV67r+Q6l7Fu5JyaGlJTvk93/BPow=; b= ZLiJ06sHMeE3nSEbWoUcQ88PDpVX7/I150LBmedPGyAkh0Rfje3qPR1XblGbG9mn ubeRY92hwF0G1E6fB3ODR5GUMSH4yfD6Ex1O8+54a4L9tMg0EDI7voKs7qor/cN0 EU9SEoKGWdi2qJf3Mcaxby87A/opshHyfYKO1Ul65+A= 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 vHBL_i1R6wKW; Sat, 25 Oct 2014 17:02:30 +0200 (CEST) Received: from tommy.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA; Sat, 25 Oct 2014 17:02:30 +0200 (CEST) Message-ID: <544BBB85.2020909@madpilot.net> Date: Sat, 25 Oct 2014 17:02:29 +0200 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: FreeBSD FS Subject: Re: panic: detach with active requests on 10.1-RC3 References: <544A538F.6060202@FreeBSD.org> In-Reply-To: <544A538F.6060202@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Glen Barber , 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: Sat, 25 Oct 2014 15:02:53 -0000 On 10/24/14 15:26, Guido Falsi wrote: > Hi, > > I'm making some experiments with 10.1-RC3 on alix boards as hardware > using NanoBSD. > > By mounting and umounting UFS filesystems I have seen umount constantly > hanging hard in a deadlock. I have tested on two boards with two > distinct compactflash disks with same results. This was not happening > with 10.0-RELEASE. > > I have build a 10.1-RC3 kernel with full debugging and caused the > problem to happen, I got this: > > root@qtest:~ [0]# umount /cfg > panic: detach with active requests > KDB: stack backtrace: > db_trace_self_wrapper(c0968053,c08ea7f0,c2d48800,c23d6bc8,c0536a16,...) > at db_trace_self_wrapper+0x2d/frame 0xc23d6b98 > kdb_backtrace(c09639e1,c09fa7e8,c095761d,c23d6c54,c095761d,...) at > kdb_backtrace+0x30/frame 0xc23d6c00 > vpanic(c09fa682,100,c095761d,c23d6c54,c23d6c54,...) at vpanic+0x80/frame > 0xc23d6c24 > kassert_panic(c095761d,c09575b3,c2d7acc0,4c7,c2d7acc0,...) at > kassert_panic+0xe9/frame 0xc23d6c48 > g_detach(c2d7acc0,4,c095725c,1c2,c09c8d5c,...) at g_detach+0x1d3/frame > 0xc23d6c64 > g_wither_washer(c09f7df4,0,c0956544,124,0,...) at > g_wither_washer+0x109/frame 0xc23d6c90 > g_run_events(0,c23d6d08,c095d42a,3dc,0,...) at g_run_events+0x40/frame > 0xc23d6ccc > fork_exit(c05c4e60,0,c23d6d08) at fork_exit+0x7f/frame 0xc23d6cf4 > fork_trampoline() at fork_trampoline+0x8/frame 0xc23d6cf4 > --- trap 0, eip = 0, esp = 0xc23d6d40, ebp = 0 --- > KDB: enter: panic > [ thread pid 12 tid 100006 ] > Stopped at kdb_enter+0x3d: movl $0,kdb_why > db> > I tried to investigate some more by myself. Maybe what I found is obvious to anyone with decent VFS knowledge, anyway: After some fumbling around I did: db> show geom 0xc2e98b40 consumer: 0xc2e98b40 class: VFS (0xc09c8d5c) geom: ffs.ada0s3 (0xc3293600) provider: ada0s3 (0xc2e7e200) access: r0w0e0 flags: 0x0030 nstart: 19 nend: 18 Which shows nstart != nend, while g_detach asserts them to be the same. Going up the chain of providers I find also it's providers have nstart - nend == 1: db> show geom 0xc2e9b7c0 consumer: 0xc2e9b7c0 class: PART (0xc09c96b0) geom: ada0 (0xc2e7e780) provider: ada0 (0xc2e7e500) access: r2w0e0 flags: 0x0030 nstart: 1430 nend: 1429 db> show geom 0xc2e7e500 provider: ada0 (0xc2e7e500) class: DISK (0xc09c8890) geom: ada0 (0xc2e7e580) mediasize: 4017807360 sectorsize: 512 stripesize: 0 stripeoffset: 0 access: r2w0e0 flags: (0x0030) error: 0 nstart: 2085 nend: 2084 consumer: 0xc2e9a700 (ada0), access=r0w0e0, flags=0x0030 consumer: 0xc2e9b480 (ada0), access=r0w0e0, flags=0x0030 consumer: 0xc2e9b7c0 (ada0), access=r2w0e0, flags=0x0030 Looking at the code these values are touched only in g_io_request() and g_io_deliver() respectively. So this one now looks like a geom problem. In fact the only commit which touched those functions between 10.0 and 10.1 branches is r260385, which merged quite a few things. I've tried reverting it to test without that, but "svn merge -c -260385 ." generated a few conflicts I'm unable to resolve. So I need some guidance even to perform this simple test. > > The machine is sitting there, I am connected with serial console, anyone > willing to help me debug this further? I really know very little about > kernel debugging. If necessary I can also make myself available via IRC > or Jabber. > > It looks like this has some similarities with what was reported here: > > https://lists.freebsd.org/pipermail/freebsd-fs/2014-September/020035.html > > I also tested with head (including r272130) and it does deadlock the same. > After the analysis above I think that there really is no similitude with the probllem reported by bdrewery. -- Guido Falsi From owner-freebsd-stable@FreeBSD.ORG Sat Oct 25 15:57:25 2014 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 BAF3515E for ; Sat, 25 Oct 2014 15:57:25 +0000 (UTC) Received: from mail.server1.bsdforen.de (bsdforen.de [82.193.243.81]) by mx1.freebsd.org (Postfix) with ESMTP id 7D8DC83A for ; Sat, 25 Oct 2014 15:57:25 +0000 (UTC) Received: from AprilRyan.norad (HSI-KBW-46-223-128-94.hsi.kabel-badenwuerttemberg.de [46.223.128.94]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.server1.bsdforen.de (Postfix) with ESMTPSA id 777B186201 for ; Sat, 25 Oct 2014 17:57:24 +0200 (CEST) Message-ID: <544BC863.2040607@bsdforen.de> Date: Sat, 25 Oct 2014 17:57:23 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: File system issues 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: Sat, 25 Oct 2014 15:57:25 -0000 Two or 3 days ago, after an update to stable/10 my UFS file system started acting weird. I have freezes and files disappearing from the system. The first time that happened SU+J failed me. I.e. I went into single user mode and on the second fsck run it would still find errors that weren't successfully corrected due to the journal. That was the first time with the Samsung 840 PRO SSD. I rebuilt kernel/world, turned off journaling and rebooted, but the problems persisted. Yesterday I updated again: FreeBSD AprilRyan.norad 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #0 r273588: Fri Oct 24 17:18:14 CEST 2014 root@AprilRyan.norad:/usr/obj/S403/amd64/usr/src/sys/S403 amd64 Today I suddenly couldn't use sysctl any more. It turned out /sbin was suddenly empty. A couple of minutes later the system froze. After the hard reset it came up like this (shortened to relevant bits): http://pastebin.com/kXLtg3JR As you can see I'm using geli for everything but /boot. After a hard reset I usually go into single user mode and run fsck twice (ever since I had some really bad experiences). It doesn't come up clean, but what turns up in lost+found are just files from the browser cache and /sbin is back. What terrifies me (apart from disappearing files) is what happens after the system goes through a suspend and resume cycle, starting at line 258 in the pastebin. The harddisk comes back up with new errors! I cannot pin down which version was the one last working for me, but it's uname already said something about 10.1-PRERELEASE. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-stable@FreeBSD.ORG Sat Oct 25 16:02:38 2014 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 CCCC4397; Sat, 25 Oct 2014 16:02:38 +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 57E868F8; Sat, 25 Oct 2014 16:02:38 +0000 (UTC) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3jQ6X23q2czb3G; Sat, 25 Oct 2014 18:02:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :references:subject:subject:mime-version:user-agent:from:from :date:date:message-id:received:received; s=mail; t=1414252944; x=1416067345; bh=+i1X43VeKO7bXtQEVE9+Ku3mMcwriLVb+P2MoHp/1no=; b= CYzE/rcEydjxWcDIACQpcjFglrIRxIwoyLMYAAVl6pCvPTw9A3covUNc6UXMIKaG SKJQ9HKW4mh6MOadMsrhc/U7Df7dc2o07XbuoZMb1a8u/z6FG+o6wK1/BoIUogw5 ow8T6W77IsR93vpbO2shLGDfd41hXkFdVns0tfheoaI= 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 GritJvivHpbs; Sat, 25 Oct 2014 18:02:24 +0200 (CEST) Received: from tommy.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA; Sat, 25 Oct 2014 18:02:24 +0200 (CEST) Message-ID: <544BC990.4030700@madpilot.net> Date: Sat, 25 Oct 2014 18:02:24 +0200 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: FreeBSD FS Subject: Re: panic: detach with active requests on 10.1-RC3 References: <544A538F.6060202@FreeBSD.org> <544BBB85.2020909@madpilot.net> In-Reply-To: <544BBB85.2020909@madpilot.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Glen Barber , 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: Sat, 25 Oct 2014 16:02:38 -0000 On 10/25/14 17:02, Guido Falsi wrote: > On 10/24/14 15:26, Guido Falsi wrote: >> Hi, >> >> I'm making some experiments with 10.1-RC3 on alix boards as hardware >> using NanoBSD. >> >> By mounting and umounting UFS filesystems I have seen umount constantly >> hanging hard in a deadlock. I have tested on two boards with two >> distinct compactflash disks with same results. This was not happening >> with 10.0-RELEASE. >> >> I have build a 10.1-RC3 kernel with full debugging and caused the >> problem to happen, I got this: >> >> root@qtest:~ [0]# umount /cfg >> panic: detach with active requests >> KDB: stack backtrace: >> db_trace_self_wrapper(c0968053,c08ea7f0,c2d48800,c23d6bc8,c0536a16,...) >> at db_trace_self_wrapper+0x2d/frame 0xc23d6b98 >> kdb_backtrace(c09639e1,c09fa7e8,c095761d,c23d6c54,c095761d,...) at >> kdb_backtrace+0x30/frame 0xc23d6c00 >> vpanic(c09fa682,100,c095761d,c23d6c54,c23d6c54,...) at vpanic+0x80/frame >> 0xc23d6c24 >> kassert_panic(c095761d,c09575b3,c2d7acc0,4c7,c2d7acc0,...) at >> kassert_panic+0xe9/frame 0xc23d6c48 >> g_detach(c2d7acc0,4,c095725c,1c2,c09c8d5c,...) at g_detach+0x1d3/frame >> 0xc23d6c64 >> g_wither_washer(c09f7df4,0,c0956544,124,0,...) at >> g_wither_washer+0x109/frame 0xc23d6c90 >> g_run_events(0,c23d6d08,c095d42a,3dc,0,...) at g_run_events+0x40/frame >> 0xc23d6ccc >> fork_exit(c05c4e60,0,c23d6d08) at fork_exit+0x7f/frame 0xc23d6cf4 >> fork_trampoline() at fork_trampoline+0x8/frame 0xc23d6cf4 >> --- trap 0, eip = 0, esp = 0xc23d6d40, ebp = 0 --- >> KDB: enter: panic >> [ thread pid 12 tid 100006 ] >> Stopped at kdb_enter+0x3d: movl $0,kdb_why >> db> >> > > I tried to investigate some more by myself. Maybe what I found is > obvious to anyone with decent VFS knowledge, anyway: > > After some fumbling around I did: > > db> show geom 0xc2e98b40 > consumer: 0xc2e98b40 > class: VFS (0xc09c8d5c) > geom: ffs.ada0s3 (0xc3293600) > provider: ada0s3 (0xc2e7e200) > access: r0w0e0 > flags: 0x0030 > nstart: 19 > nend: 18 > > Which shows nstart != nend, while g_detach asserts them to be the same. > > Going up the chain of providers I find also it's providers have nstart - > nend == 1: > > db> show geom 0xc2e9b7c0 > consumer: 0xc2e9b7c0 > class: PART (0xc09c96b0) > geom: ada0 (0xc2e7e780) > provider: ada0 (0xc2e7e500) > access: r2w0e0 > flags: 0x0030 > nstart: 1430 > nend: 1429 > db> show geom 0xc2e7e500 > provider: ada0 (0xc2e7e500) > class: DISK (0xc09c8890) > geom: ada0 (0xc2e7e580) > mediasize: 4017807360 > sectorsize: 512 > stripesize: 0 > stripeoffset: 0 > access: r2w0e0 > flags: (0x0030) > error: 0 > nstart: 2085 > nend: 2084 > consumer: 0xc2e9a700 (ada0), access=r0w0e0, flags=0x0030 > consumer: 0xc2e9b480 (ada0), access=r0w0e0, flags=0x0030 > consumer: 0xc2e9b7c0 (ada0), access=r2w0e0, flags=0x0030 > > Looking at the code these values are touched only in g_io_request() and > g_io_deliver() respectively. > > So this one now looks like a geom problem. > > In fact the only commit which touched those functions between 10.0 and > 10.1 branches is r260385, which merged quite a few things. > > I've tried reverting it to test without that, but "svn merge -c -260385 > ." generated a few conflicts I'm unable to resolve. So I need some > guidance even to perform this simple test. > I finally succeeded in merging it good enough to compile and boot, and got the same panic, so Even this commit looks unrelated. I must admit I am out of ideas. -- Guido Falsi From owner-freebsd-stable@FreeBSD.ORG Sat Oct 25 16:49:50 2014 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 30F1BC36; Sat, 25 Oct 2014 16:49:50 +0000 (UTC) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1F886CA9; Sat, 25 Oct 2014 16:49:48 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id pn19so4268604lab.0 for ; Sat, 25 Oct 2014 09:49:46 -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=cgm9lfEHWfB6qAKCJlmjuQQ3hPSKCH27q8M4kK3lgUg=; b=t/zm/tpixCC8iLm0cepTwA62bBcKH00ujOBaTZjgFYl0Bo3gLBEwSzKg/CrjCEIWGS GiogtLPx0yMwoo2c6DZct0U0cUATsYJRJfO57owSpHlO3UMj8kJP3GZl9qXgyxRfCamL UjorKSEMtacmJRLL2upi0sTRhku8LSGxeMws02Ke0b7ZHxjat8ujAHmPaPX6lSypOII0 R1cK0S1ssTesQBpX78IwggzDqUkfjAknXFHUTfjM8wXoUnQXXAQUNiLAgulq/n9hN7dA 3sVj+i/FHxqB9SPwJhRlQC2IQcG4ZNYW6RtBZjNIGzx3Rx7RO+kvUSPNCnNPe3yRNatW OsLg== MIME-Version: 1.0 X-Received: by 10.112.57.227 with SMTP id l3mr11901372lbq.68.1414255786825; Sat, 25 Oct 2014 09:49:46 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.84.197 with HTTP; Sat, 25 Oct 2014 09:49:46 -0700 (PDT) In-Reply-To: <544B46BA.4000008@freebsd.org> References: <20141024053636.GH11222@dft-labs.eu> <81030948-E60F-4AAD-AAF1-16349607917D@gmail.com> <544B46BA.4000008@freebsd.org> Date: Sat, 25 Oct 2014 09:49:46 -0700 X-Google-Sender-Auth: GIlVT8zHlo5sp3t_C8L_ce6W7_A Message-ID: Subject: Re: Automatically running /usr/tests on stable/10 branch under Jenkins From: Craig Rodrigues To: Alfred Perlstein Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-testing@freebsd.org" , FreeBSD stable , "freebsd-virtualization@freebsd.org" , Garrett Cooper 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, 25 Oct 2014 16:49:50 -0000 On Fri, Oct 24, 2014 at 11:44 PM, Alfred Perlstein wrote: > > On 10/24/14 9:45 PM, Garrett Cooper wrote: > >> I think getting tools/regression/zfs working first would be a better idea >> (which means that ZFS developers will need to go debug/fix the issue noted >> in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191574 ). I'll go >> ahead and commit my fixes to head from my github fork so it runs. >> > If tools/regression/zfs has Kyuafiles that makes it easier to run under the kyua tool, that would greatly facilitate running under Jenkins automation, and would be useful. I notice some of the fixes you are applying to the regression/zfs tests is to make certain tests not run on FreeBSD because they cause known kernel panics such as this: https://lists.freebsd.org/pipermail/svn-src-all/2014-October/093671.html I'm not entirely convinced that this is a good way to "fix" a test. If a test causes a panic, then that's what it does, it it should not be swept under the rug, as Alfred has pointed out. Printing out a warning with a pointer to the PR just before running this type of test is OK, though. > >> Alan also suggested against integrating the test suite as-is, because as >> he said, "Remember, don't run these tests on a production system. They >> WILL cause panics and deadlocks, and they may cause data loss too." >> >> Cheers, >> -Garrett >> > > Wait, we want to sweep those bugs under the rug? What exactly is wrong > with making a test harness that can very easily reproduce a known problem? > The chances are that anyone will dive into it once the bug is easily > reproducible. > I agree with Alfred on this. Even though Alan's test suite may kernel panic or cause problems, there is still value in running it and making the results visible on jenkins.freebsd.org. Running these tests inside a VM which is generated during the build will allow these types of test to run, but still keep the test machine usable, even if the VM gets corrupted while running the tests. If we have test suites for ZFS, but no one runs them, then no one will bother to investigate and fix the bugs. Running the test suites under automation that is visible on jenkins.freebsd.org is going to force developers to see problems much sooner than they do now. Just having the tests in the tree and hoping that people run them and care to look into the problems is not enough. -- Craig From owner-freebsd-stable@FreeBSD.ORG Sat Oct 25 17:53:57 2014 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 EC66898F; Sat, 25 Oct 2014 17:53:56 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 69B7D324; Sat, 25 Oct 2014 17:53:56 +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 s9PHro3o049417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Oct 2014 20:53:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s9PHro3o049417 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s9PHro6w049416; Sat, 25 Oct 2014 20:53:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 25 Oct 2014 20:53:50 +0300 From: Konstantin Belousov To: "Kenneth D. Merry" Subject: Re: sa(4) 9.2->10.1, nsa0.0: request ptr 0x803135040 is not on a page boundary; cannot split request Message-ID: <20141025175350.GK1877@kib.kiev.ua> References: <54494E92.5010007@omnilan.de> <20141024230725.GA50845@mithlond.kdm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141024230725.GA50845@mithlond.kdm.org> 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: Harald Schmalzbauer , royger@freebsd.org, 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: Sat, 25 Oct 2014 17:53:57 -0000 On Fri, Oct 24, 2014 at 05:07:26PM -0600, Kenneth D. Merry wrote: > On Thu, Oct 23, 2014 at 20:53:06 +0200, Harald Schmalzbauer wrote: > > Hello, > > > > I read about the changes in sa(4) regarding large-block-split changes > > and the transitional 'kern.cam.sa.allow_io_split' workarround. > > > > I'm using bacula (7.0.5) and my previous neccessarry multi-blocking > > adjustmets like "Minimum block size = 2097152" obviously didn't work > > with FreebSD 10.1 anymore. > > Good news is, they are not needed any more! > > With the default of 126 blocks (64512) I get 60-140MB/s with btape(8)'s > > speed test on my LTO4 (HH) drive and another quick test showed that > > using mbuffer(1) for zfs(8) 'send' isn't needed anymore (| dd > > of=/dev/nsa0 bs=64512 seems to max out LTO4 speed). [with FreeBSD 9 the > > transfer rates were some magnitudes lower with these block size settings!] > > > > Not so good news is, that bacula can't read the tape's label. > > 'Labeling a tape (with 'label' at bconsole(8) or btape(8)) is > > successful, and btape(8)'s 'readlabel' partially displays the correct > > label, but not the very beginning of the label: > > Volume Label: > > Id : **error**VerNo > > ?rest OK > > > > While it should read: > > Volume Label: > > Id : Bacula 1.0 immortal > > VerNo : 11 > > ? > > > > When btape(8) starts to read the label, the _subject's error is reported_: > > *nsa0.0: request ptr 0x803135040 is not on a page boundary; cannot split > > request* > > What blocksize are you using with btape(8)? > > What kind of controller are you using? > > The reason you get that error message is that the sa(4) driver goes through > physio(9) to get buffers from userland into the kernel. physio(9) relies > on the vmapbuf()/vunmapbuf() routines to map buffers in and out of the > kernel. > > vmapbuf() operates with a page granularity. The address to be mapped has > to start on a page boundary. It also uses kernel virtual address segments > that are MAXPHYS in size. On x86 boxes at least, MAXPHYS is 128KB. > > So if you use a blocksize of 128KB, but pass in a pointer that doesn't > start on a page boundary, vmapbuf() will have to map 33 pages instead of > 32. In your case, it will have to start at page address 0x803135000, and > will need 33 4KB pages, which is greater than 128KB. I want to disable unaligned physio at all. See https://reviews.freebsd.org/D888 for yet another case where this beats. Obvious thing which stops us from doing this is binary compatibility. I need some form of wide support to make this change. > > This behavior obviously isn't very user friendly. > > If you want to avoid the problem, try setting your blocksize in Bacula to > 4K less than what is reported in kern.cam.sa.0.maxio. If it's 131072, then > set the blocksize to 126976. > > Another way to avoid the problem is to increase MAXPHYS. Increasing it > beyond kern.cam.sa.0.cpi_maxio won't help anything. If you increase > it too much, you can run into other problems. > > That said, though, you can probably bump it to 512K without much worry. > Put this in your kernel config file and recompile/reinstall your kernel: > > options MAXPHYS="(512*1024)" > options DFLTPHYS="(512*1024)" > > The same thing applies, though -- you'll want to set your blocksize to 1 > page less than kern.cam.sa.0.maxio, since Bacula isn't using page-aligned > buffers. > > > The same error show up if I configure bacula to use a fixed block size > > of kern.cam.sa.0.maxio (131072). > > At that (i.e. the physio(9)) level, variable vs. fixed block mode won't > matter. > > > Like expected, allowing split (with kern.cam.sa.allow_io_split in > > loader.conf) works arround that problem. > > But I'd like to understand why I cannot set kern.cam.sa.0.maxio resp. > > why btape(8) doesn't work 100% correct although blocksize < sa.0.maxio > > See above. The unfortunate thing is that with the above setup, I think > you'll wind up with a bigger block and then a smaller block going onto the > tape in variable block mode at least. > > This is an example of why I/O splitting is bad -- you don't have good > visibility from userland into exactly how things are getting put on tape. > The application writes out what it wants, but it doesn't know what size > blocks are hitting the tape. > > > I don't have enough understanding to check the code myself, if it's a > > cam/sa(4) issue in FreeBSD or a problem in btape(8) (and also bacula > > itself, most likely the tool shares the code with bacula's storage deamon). > > > > Any hints highly appreciated! > > I have considered implementing a custom read/write routine in the sa(4) > driver to get around some of these issues, but it will require more than > just sa(4) driver modifications for everything to work optimally. > > With a custom read/write routine, if we copied data into the kernel, we > could essentially allow any I/O size that the controller and tape drive > support without altering MAXPHYS. And alignment issues wouldn't matter, > either. > > The drawback is that we wouldn't be able to do unmapped I/O for drivers > that support it. (Unless the user happened to give us a single buffer that > we could send down as an unmapped I/O.) The unmapped I/O code doesn't > currently handle scatter/gather lists of unmapped buffers. > > Another drawback to copying is the increased overhead of versus unmapped > I/O. Although on modern hardware, copying is usually more efficient than > mapping user memory into the kernel's virtual address space, because of the > TLB shootdowns that happen with the mapping operation. > > For tape users with just one tape drive, the overhead wouldn't be a big > deal. If you have lots of tape drives attached to one machine, though, it > could have a noticable effect. > > Ken > -- > Kenneth Merry > ken@FreeBSD.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" From owner-freebsd-stable@FreeBSD.ORG Sat Oct 25 18:27:00 2014 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 288EEF2F for ; Sat, 25 Oct 2014 18:27:00 +0000 (UTC) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E0F7E833 for ; Sat, 25 Oct 2014 18:26:59 +0000 (UTC) Received: by mail-ig0-f182.google.com with SMTP id hn18so2553593igb.9 for ; Sat, 25 Oct 2014 11:26:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=dMEGC+A3PXBnczbmjVwhUoctQVqsmCziVytLQfQDaio=; b=Dk+vCPQfsPqzqWXd7Pk5SUQOMUAxCfyO8Z7yvptF2P0YglWAxC5n2GQETD4aYogpXt sB7JGYjsShj3gtGVi+n8VKsRtqgZnuEtqkPRTPHUYcgqTJeSUdZl34qc9S8ZUAu/Aj8y I2Gj72xM07t5g6cFy31kym9d7A5yg5jLj6besIKAggC6S8KwmYRdnWYBGIHEXOLF1ycu aH1eP4wctISMVliXESUetIe1Him4xQHkYULbNX1+b036h4CYjeZR4/yijVGOLFevZmcX FYDRRfZDQkfioGKHE2napz6FJIDU+Se21pX6jizdS99484bOvVHsp4SiejDVH1HrMmYa lrNw== MIME-Version: 1.0 X-Received: by 10.107.156.17 with SMTP id f17mr5851321ioe.15.1414261604820; Sat, 25 Oct 2014 11:26:44 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.107.11.141 with HTTP; Sat, 25 Oct 2014 11:26:44 -0700 (PDT) In-Reply-To: <20141025113846.GY1235@albert.catwhisker.org> References: <6978A7BF-3CB7-4088-904D-5A60D755A04C@gmail.com> <20141025113846.GY1235@albert.catwhisker.org> Date: Sat, 25 Oct 2014 11:26:44 -0700 X-Google-Sender-Auth: wCD-z2gb_CjGtfU01xroY4ffGa0 Message-ID: Subject: Re: Dump time issues From: Kevin Oberman To: David Wolfskill , Alban Hertroys , freebsd-stable 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: Sat, 25 Oct 2014 18:27:00 -0000 On Sat, Oct 25, 2014 at 4:38 AM, David Wolfskill wrote: > On Sat, Oct 25, 2014 at 01:26:43PM +0200, Alban Hertroys wrote: > > I?m seeing something odd in my dump output that I didn?t notice before: > > > > Dumping /root... > > DUMP: WARNING: should use -L when dumping live read-write filesystems! > > (That, by the way, is pretty good advice in my experience.) > As long as the volume is not SU+J. Then, in my experience, it's very bad advice. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-stable@FreeBSD.ORG Sat Oct 25 18:36:01 2014 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 75AFD210 for ; Sat, 25 Oct 2014 18:36:01 +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 3947A936 for ; Sat, 25 Oct 2014 18:36:01 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Xi6C0-000P7T-CH; Sat, 25 Oct 2014 20:36:00 +0200 Date: Sat, 25 Oct 2014 20:36:00 +0200 From: Kurt Jaeger To: Dominic Fandrey Subject: Re: File system issues Message-ID: <20141025183600.GG66862@home.opsec.eu> References: <544BC863.2040607@bsdforen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <544BC863.2040607@bsdforen.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: Sat, 25 Oct 2014 18:36:01 -0000 Hi! > Two or 3 days ago, after an update to stable/10 my UFS file system > started acting weird. I have freezes and files disappearing from the > system. > > The first time that happened SU+J failed me. I always disable journaling, because I had many failures with that in the past: tunefs -j disable -- pi@opsec.eu +49 171 3101372 6 years to go ! From owner-freebsd-stable@FreeBSD.ORG Sat Oct 25 19:11:20 2014 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 5CD84B55 for ; Sat, 25 Oct 2014 19:11:20 +0000 (UTC) Received: from orthanc.ca (orthanc.ca [IPv6:2607:f2f8:abf8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "orthanc.ca", Issuer "orthanc.ca CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 24ABCC21 for ; Sat, 25 Oct 2014 19:11:20 +0000 (UTC) Received: from [192.168.42.6] (d66-183-211-183.bchsia.telus.net [66.183.211.183]) (authenticated bits=0) by orthanc.ca (8.14.7/8.14.7) with ESMTP id s9PJBGUI061403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 25 Oct 2014 12:11:18 -0700 (PDT) (envelope-from lyndon@orthanc.ca) From: Lyndon Nerenberg Content-Type: multipart/signed; boundary="Apple-Mail=_CFBA05EF-37FA-49C5-B600-855545C6676E"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <50056B15-83F4-4524-995E-6486959C027C@orthanc.ca> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: File system issues Date: Sat, 25 Oct 2014 12:11:16 -0700 References: <544BC863.2040607@bsdforen.de> <20141025183600.GG66862@home.opsec.eu> To: freebsd-stable@FreeBSD.org In-Reply-To: <20141025183600.GG66862@home.opsec.eu> X-Mailer: Apple Mail (2.1878.6) X-Spam-Status: No, score=0.4 required=5.0 tests=RDNS_DYNAMIC autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on orthanc.ca 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, 25 Oct 2014 19:11:20 -0000 --Apple-Mail=_CFBA05EF-37FA-49C5-B600-855545C6676E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 25, 2014, at 11:36 AM, Kurt Jaeger wrote: > I always disable journaling, because I had many failures with that > in the past: >=20 > tunefs -j disable I turn it off because you cannot snapshot a journaled filesystem, which = breaks live dumps. It would be helpful if there was a way in the installer to toggle the = default setting for 'journaled' before carving out the filesystems. = It's moderately annoying to have to go through the option settings for = all the filesystems to turn this off. --lyndon --Apple-Mail=_CFBA05EF-37FA-49C5-B600-855545C6676E 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----- iQIcBAEBAgAGBQJUS/XUAAoJEG8PnXiV/JnUT/MQAK6JwZ7UYVVe+A+aPb4f0Reu U9PPq89aymOQJ+TWRQnomB/iSmtAqBmfzWnZbhFAhaBlTcQi49ZJGUtHrJKs8pJ9 iHwoGXxNuBoZmTZ3NZnSvnHXk4OKWMkhAD1rsCpYC0FngzCH5hiXozZan9x81TqH iTDh23WW4rPwNfHUmFCmMbC8YPhrnneb9KrBNO2K+nCMc34ePdo2D7ixeE8FC+hD tyoS2x3cCqWpltl9YenLUjuzLmkhv4iijLnolv939Ha9vp7E+DA61XYlla6M5i5E wxcTseeos4VwL2qeLtDNc6ReRTIpOxRkzCA1GBAhG4BB6KoSZbq8IBHNu8ko9mBc 8agz7uSbjvhnh1EhZfd9KLyQ/NFFlSKEOs/vSh5GaBtX4meQ202jS9Zom9MDoqlr gsJwgctXvMuahn+cnQHfeoGAbraebYvETUUMulIaDF30BVS21SUpW/Dk6FUKQaay fUnJprN4fA8cWEJ8cd3bT47qzLm0qivBQOWcaozKS6QO4RRNXf/NUcPgujHi4zOj bNvvCPr5b/GOUCq0OEhu/QJh/FzZwiB18GR+eZR4cS8Bk7eDPlqSwTPU7K7ATg9/ CJWXqlAzdqtkU2WyfO8mXHhRXbV3yRrdtzs5ASsLkQ3eEsOtjblu3Odp+qSJzK1w OsChXamgVBaXVW1co7ae =6lBp -----END PGP SIGNATURE----- --Apple-Mail=_CFBA05EF-37FA-49C5-B600-855545C6676E-- From owner-freebsd-stable@FreeBSD.ORG Sat Oct 25 20:20:07 2014 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 7E16FD6B; Sat, 25 Oct 2014 20:20:07 +0000 (UTC) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 104C3366; Sat, 25 Oct 2014 20:20:07 +0000 (UTC) Received: by mail-yh0-f54.google.com with SMTP id 29so3165889yhl.13 for ; Sat, 25 Oct 2014 13:20: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:content-transfer-encoding; bh=tynCnMKKC0eHZKShqxl5XFhNw74YLNxljWlRLqIOxA4=; b=Pub3QTq2WHLOKa8SdiQLMVF4SbTO2qnYUbR4XG+2yQllUwJPdQbUCWpRbuFy8nd9s8 r8pwHdCwy4EzGeMTtXHkwS7L9TqxbdbXcRNskwWWpPzDxCgil7raUIrZvitMCPnBJphI Y1aY/Zi3+hdvH1rNCXGNYqff8v+MHVALWchY3YxImcLw/VjXavNp1PD56P1vXrpdIR/Z fNNMe+v+M9AwqgBmfgQ9X1246rzuf5eDr+tEAGC/wTNiDB3kXn+PYKvfnmE6ht4LgoqI R6UiXjiXhNkLA2IPvRR1Lih9V4YEYtUgdDH/EuOz9rXOeEbbIGkRh4Xq4xXKIVvCB19C ksfw== MIME-Version: 1.0 X-Received: by 10.170.113.214 with SMTP id f205mr15326025ykb.10.1414268405509; Sat, 25 Oct 2014 13:20:05 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.170.82.197 with HTTP; Sat, 25 Oct 2014 13:20:05 -0700 (PDT) In-Reply-To: References: <20141024053636.GH11222@dft-labs.eu> <81030948-E60F-4AAD-AAF1-16349607917D@gmail.com> <544B46BA.4000008@freebsd.org> Date: Sat, 25 Oct 2014 13:20:05 -0700 X-Google-Sender-Auth: Tz1pjYcN82aDbop02VCfh_GmGLU Message-ID: Subject: Re: Automatically running /usr/tests on stable/10 branch under Jenkins From: "K. Macy" To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-testing@freebsd.org" , Alfred Perlstein , FreeBSD stable , "freebsd-virtualization@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: Sat, 25 Oct 2014 20:20:07 -0000 >>> Alan also suggested against integrating the test suite as-is, because a= s he said, "Remember, don't run these tests on a production system. They W= ILL cause panics and deadlocks, and they may cause data loss too.=E2=80=9D >>> >>> Cheers, >>> -Garrett >> >> Wait, we want to sweep those bugs under the rug? What exactly is wrong = with making a test harness that can very easily reproduce a known problem? = The chances are that anyone will dive into it once the bug is easily repro= ducible. > > Sweeping bugs under the rug is not what I plan on doing; I=E2=80= =99m marking these as expected failures, as opposed to having them continua= lly panic a machine. Once a ZFS dev takes a look at the issue and resolves = them, then the ZFS dev can remove the =E2=80=9Cbail=E2=80=9D calls I=E2=80= =99m adding to the testcases. > Cheers, > -Garrett Yes, disabling tests that fail leads to an ineffectual test suite. A test suite that never has any failures is not very useful. However, there are two factors to take in to account in this context: a) frequent failures can lead users to stop running a test suite leading to further regressions b) long-term repeated failures can desensitize users leading them to ignore *new* failures facilitating further regressions Thus it's really a question of what context you're talking about running the test suite in. For purposes of Jenkins we want full visibility in to what is passing and what is failing and how long this has been going on for. Cheers. -K From owner-freebsd-stable@FreeBSD.ORG Sat Oct 25 20:46:08 2014 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 256C38D1; Sat, 25 Oct 2014 20:46:08 +0000 (UTC) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1AE708A5; Sat, 25 Oct 2014 20:46:06 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id y10so3165082wgg.15 for ; Sat, 25 Oct 2014 13:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=t//pXgEd3Q3UH0iDU41IKFjnnABq5Sm5aPP3WwoOZYY=; b=SVH1blnEsqAYqr3PugLeWMACKsu9FoSXunMO38A0GhtfKZv0/sOTh3ATCkCS9jCQlD DAtFkj8tZBZefRlYGdMmO8HEeASGKxmgLOICXsaUtSVHbLYTBFdei7R3gKKoeKDHu6nt Ml6Jk9Nu7ZACfRC+Pe9L7Rbgb6wIDxIAk0fn91G//Plugu5QCeTEQldd3dXidRp6wOzd 4FQuRRsjKOgvCGhHeLqBnOJ6HQTRSOwbWRaxPWQ2YjRSVIYZ+EJ7FUlLQk5xooiMVr0V 8a0eM26oTPzJVM/gFgFcJPOJvV/GizrxUBE5Q6qiPdBpFQ/ErX4JxJQJREl+y+8+Tygp 2gOw== MIME-Version: 1.0 X-Received: by 10.194.91.176 with SMTP id cf16mr13105133wjb.60.1414269965374; Sat, 25 Oct 2014 13:46:05 -0700 (PDT) Reply-To: matt@ixsystems.com Sender: mattjeet@gmail.com Received: by 10.194.14.40 with HTTP; Sat, 25 Oct 2014 13:46:05 -0700 (PDT) In-Reply-To: References: <20141024053636.GH11222@dft-labs.eu> <81030948-E60F-4AAD-AAF1-16349607917D@gmail.com> <544B46BA.4000008@freebsd.org> Date: Sat, 25 Oct 2014 13:46:05 -0700 X-Google-Sender-Auth: d4LEDwRd3jOMoF28Wxp0hRpOoQk Message-ID: Subject: Re: Automatically running /usr/tests on stable/10 branch under Jenkins From: Matt Olander To: "K. Macy" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-testing@freebsd.org" , Alfred Perlstein , FreeBSD stable , "freebsd-virtualization@freebsd.org" , Garrett Cooper 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, 25 Oct 2014 20:46:08 -0000 On Sat, Oct 25, 2014 at 1:20 PM, K. Macy wrote: >>>> Alan also suggested against integrating the test suite as-is, because = as he said, "Remember, don't run these tests on a production system. They = WILL cause panics and deadlocks, and they may cause data loss too.=E2=80=9D >>>> >>>> Cheers, >>>> -Garrett >>> >>> Wait, we want to sweep those bugs under the rug? What exactly is wrong= with making a test harness that can very easily reproduce a known problem?= The chances are that anyone will dive into it once the bug is easily repr= oducible. >> >> Sweeping bugs under the rug is not what I plan on doing; I=E2=80= =99m marking these as expected failures, as opposed to having them continua= lly panic a machine. Once a ZFS dev takes a look at the issue and resolves = them, then the ZFS dev can remove the =E2=80=9Cbail=E2=80=9D calls I=E2=80= =99m adding to the testcases. >> Cheers, >> -Garrett > > Yes, disabling tests that fail leads to an ineffectual test suite. A > test suite that never has any failures is not very useful. However, > there are two factors to take in to account in this context: > a) frequent failures can lead users to stop running a test suite > leading to further regressions > b) long-term repeated failures can desensitize users leading them to > ignore *new* failures facilitating further regressions > > Thus it's really a question of what context you're talking about > running the test suite in. For purposes of Jenkins we want full > visibility in to what is passing and what is failing and how long this > has been going on for. Agreed. We're talking about doing an OpenZFS bug-tracker and maybe we could have tests post there automatically, once the bug is opened. I am going to put this on the board at MeetBSD Ca. next week, so we can have a discussion about it in real-time with some of the people present. Cheers, -matt From owner-freebsd-stable@FreeBSD.ORG Sat Oct 25 20:53:01 2014 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 501C6B25 for ; Sat, 25 Oct 2014 20:53:01 +0000 (UTC) Received: from mail.server1.bsdforen.de (bsdforen.de [82.193.243.81]) by mx1.freebsd.org (Postfix) with ESMTP id 12717979 for ; Sat, 25 Oct 2014 20:53:00 +0000 (UTC) Received: from AprilRyan.norad (HSI-KBW-46-223-128-94.hsi.kabel-badenwuerttemberg.de [46.223.128.94]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.server1.bsdforen.de (Postfix) with ESMTPSA id 4D89286126; Sat, 25 Oct 2014 22:52:52 +0200 (CEST) Message-ID: <544C0DA3.1060201@bsdforen.de> Date: Sat, 25 Oct 2014 22:52:51 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Kurt Jaeger Subject: Re: File system issues References: <544BC863.2040607@bsdforen.de> <20141025183600.GG66862@home.opsec.eu> In-Reply-To: <20141025183600.GG66862@home.opsec.eu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: Sat, 25 Oct 2014 20:53:01 -0000 On 25/10/2014 20:36, Kurt Jaeger wrote: > Hi! > >> Two or 3 days ago, after an update to stable/10 my UFS file system >> started acting weird. I have freezes and files disappearing from the >> system. >> >> The first time that happened SU+J failed me. > > I always disable journaling I think that's just a symptom here. The issue is stuff mysteriously disappearing from my file system on a running system. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-stable@FreeBSD.ORG Sat Oct 25 21:46:48 2014 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 62229484; Sat, 25 Oct 2014 21:46:48 +0000 (UTC) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1629EDD4; Sat, 25 Oct 2014 21:46:48 +0000 (UTC) Received: by mail-pa0-f43.google.com with SMTP id eu11so3107879pac.30 for ; Sat, 25 Oct 2014 14:46:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ROBklQZYzRnOWEg4u6+mXXSEkyoA39Nb6IiVCDo1Xxw=; b=TxhmpWmG3d4QN+IylTmBpQ4iKoZbx8OXhNghtQONHkI+RGzBN2aOzpdlTaPeIua/zr rCd1a80riRlgYFrpHlJ5FuvMCZbPrL6oWUmajDRwVFMUWEILl01baRhHrwaFj6KljQmQ iq5i6PImVvu/vaOv7JJo5bgxDUqKGipAU9HAC/poO7y0DL5yt4Bbs1wvk7gkvLm1Hm0J S/4c5derxn850sFBlqrbnTE42zGlBGDkmbDmZEP43OBvkVdoHFNHBAb219BzbA7TaMP4 ofxFP139tjrcShC8epy6Vrn43rKU1K8lw66K+m9wp9uxbK7ePFV2Wfxd/4UmqlvwTYvW sZtw== X-Received: by 10.70.19.101 with SMTP id d5mr13514906pde.79.1414273607611; Sat, 25 Oct 2014 14:46:47 -0700 (PDT) Received: from [192.168.20.5] (c-98-247-240-204.hsd1.wa.comcast.net. [98.247.240.204]) by mx.google.com with ESMTPSA id jq5sm6960728pbc.32.2014.10.25.14.46.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 25 Oct 2014 14:46:46 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_B288C26C-0C84-4CCF-A5EC-92AEB18549DC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Automatically running /usr/tests on stable/10 branch under Jenkins From: Garrett Cooper In-Reply-To: Date: Sat, 25 Oct 2014 14:46:46 -0700 Message-Id: <74FE3F75-43D2-4CFC-8B0F-56EF886F4748@gmail.com> References: <20141024053636.GH11222@dft-labs.eu> <81030948-E60F-4AAD-AAF1-16349607917D@gmail.com> <544B46BA.4000008@freebsd.org> To: "K. Macy" X-Mailer: Apple Mail (2.1878.6) Cc: "freebsd-testing@freebsd.org" , Alfred Perlstein , FreeBSD stable , "freebsd-virtualization@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: Sat, 25 Oct 2014 21:46:48 -0000 --Apple-Mail=_B288C26C-0C84-4CCF-A5EC-92AEB18549DC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 25, 2014, at 13:20, K. Macy wrote: >>>> Alan also suggested against integrating the test suite as-is, = because as he said, "Remember, don't run these tests on a production = system. They WILL cause panics and deadlocks, and they may cause data = loss too.=94 >>>>=20 >>>> Cheers, >>>> -Garrett >>>=20 >>> Wait, we want to sweep those bugs under the rug? What exactly is = wrong with making a test harness that can very easily reproduce a known = problem? The chances are that anyone will dive into it once the bug is = easily reproducible. >>=20 >> Sweeping bugs under the rug is not what I plan on doing; I=92m = marking these as expected failures, as opposed to having them = continually panic a machine. Once a ZFS dev takes a look at the issue = and resolves them, then the ZFS dev can remove the =93bail=94 calls I=92m = adding to the testcases. >=20 > Yes, disabling tests that fail leads to an ineffectual test suite. A > test suite that never has any failures is not very useful. However, > there are two factors to take in to account in this context: > a) frequent failures can lead users to stop running a test suite > leading to further regressions > b) long-term repeated failures can desensitize users leading them to > ignore *new* failures facilitating further regressions >=20 > Thus it's really a question of what context you're talking about > running the test suite in. For purposes of Jenkins we want full > visibility in to what is passing and what is failing and how long this > has been going on for. (seeing as how my other post isn=92t in the -testing archives yet..) Panicking a node (what the tests are doing before last night) = and exiting with a non-zero exit code (what I=92m making them do with = the bail outs in tools/regression/zfs) are both considered test = failures. The difference being that I can safely run all of the tests on = a production or a test machine without having to panic/reboot the box = and I get greater coverage in one fell swoop. If a developer wants they = can always delete the lines that bail out of the tests to get the = desired panic. Cheers, -Garrett --Apple-Mail=_B288C26C-0C84-4CCF-A5EC-92AEB18549DC 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 iQEcBAEBCgAGBQJUTBpGAAoJEMZr5QU6S73eroQH/0EUjiiTQEnkaDgG29GxsSP4 pmerYl9PXlSJiN1t0ApDz7HxxWh0qTsV8+5OIdrWOU4gvmK3DEaq+HOMqVboVtS5 WLFy+/bljFhnEbF5b3UqPUyNFNaCKV7Rdr96oLnA9NVJRvEo6aNHF0+rZKyTDeMd Qb7YDscluRqyqFCugb3rcatFWVHLycQKZdiUSx5Mdc7PnXiJ4nK9nK9nq6gU3lAA u9F3wKFZLHuzI9Ko2MEUp9jqwoK8kL2wx3Q5YBvyCUUI7OmoIf2GNhhxOZwa4Tga lfrTGH4gOcRLzjGmOGCOqXLAG3j1JpPetzJywdYjfZIVu+iEp+FmX4vH6WjF8nw= =a/Nc -----END PGP SIGNATURE----- --Apple-Mail=_B288C26C-0C84-4CCF-A5EC-92AEB18549DC-- From owner-freebsd-stable@FreeBSD.ORG Sat Oct 25 21:55:30 2014 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 49A4D678; Sat, 25 Oct 2014 21:55:30 +0000 (UTC) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CC162EB6; Sat, 25 Oct 2014 21:55:29 +0000 (UTC) Received: by mail-yh0-f49.google.com with SMTP id a41so2850484yho.22 for ; Sat, 25 Oct 2014 14:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=kKt6BmrW6I+rLbcDwNkEKwLjVTlpuwf/2Jn9S9xWo14=; b=gvhr0GrDcrOeHTC5nx8pgldKNvSbME/5jkI0kLJkw+pgl/cRnB0k84cK9wV+q56YbJ VG+woGlm/AS5K7No/+0DJPXINLGMUjgDc/4gJ6LaELUcskKepR5yvzetI1yGFu0F4+uO 3jezqTfumx1vwcoS0N/zhpI4fGNsHoBkXXMXigKHe1ZIb2TPyABVzf2nOlpUmMn5Zckn Kj/JRjkXKj182CHGbei9aYR3665sQdve/f4MPMbf5/E2REb+efnTPrGA3+D73rIUZImO RIjCnr39Dex8uCuCmWLyxTR3p30aBEmWJ18u4dlGZQXtp9rIrwShqqj2n3RMEP5uf50j gvfQ== MIME-Version: 1.0 X-Received: by 10.236.209.101 with SMTP id r65mr3468882yho.140.1414274129002; Sat, 25 Oct 2014 14:55:29 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.170.82.197 with HTTP; Sat, 25 Oct 2014 14:55:28 -0700 (PDT) In-Reply-To: <74FE3F75-43D2-4CFC-8B0F-56EF886F4748@gmail.com> References: <20141024053636.GH11222@dft-labs.eu> <81030948-E60F-4AAD-AAF1-16349607917D@gmail.com> <544B46BA.4000008@freebsd.org> <74FE3F75-43D2-4CFC-8B0F-56EF886F4748@gmail.com> Date: Sat, 25 Oct 2014 14:55:28 -0700 X-Google-Sender-Auth: t0VcMeHAoagDRAA2pnmRsZr5KUA Message-ID: Subject: Re: Automatically running /usr/tests on stable/10 branch under Jenkins From: "K. Macy" To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-testing@freebsd.org" , Alfred Perlstein , FreeBSD stable , "freebsd-virtualization@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: Sat, 25 Oct 2014 21:55:30 -0000 On Sat, Oct 25, 2014 at 2:46 PM, Garrett Cooper wro= te: > On Oct 25, 2014, at 13:20, K. Macy wrote: > >>>>> Alan also suggested against integrating the test suite as-is, because= as he said, "Remember, don't run these tests on a production system. They= WILL cause panics and deadlocks, and they may cause data loss too.=E2=80= =9D >>>>> >>>>> Cheers, >>>>> -Garrett >>>> >>>> Wait, we want to sweep those bugs under the rug? What exactly is wron= g with making a test harness that can very easily reproduce a known problem= ? The chances are that anyone will dive into it once the bug is easily rep= roducible. >>> >>> Sweeping bugs under the rug is not what I plan on doing; I=E2=80= =99m marking these as expected failures, as opposed to having them continua= lly panic a machine. Once a ZFS dev takes a look at the issue and resolves = them, then the ZFS dev can remove the =E2=80=9Cbail=E2=80=9D calls I=E2=80= =99m adding to the testcases. >> >> Yes, disabling tests that fail leads to an ineffectual test suite. A >> test suite that never has any failures is not very useful. However, >> there are two factors to take in to account in this context: >> a) frequent failures can lead users to stop running a test suite >> leading to further regressions >> b) long-term repeated failures can desensitize users leading them to >> ignore *new* failures facilitating further regressions >> >> Thus it's really a question of what context you're talking about >> running the test suite in. For purposes of Jenkins we want full >> visibility in to what is passing and what is failing and how long this >> has been going on for. > > (seeing as how my other post isn=E2=80=99t in the -testing archives yet..= ) > Panicking a node (what the tests are doing before last night) and= exiting with a non-zero exit code (what I=E2=80=99m making them do with th= e bail outs in tools/regression/zfs) are both considered test failures. The= difference being that I can safely run all of the tests on a production or= a test machine without having to panic/reboot the box and I get greater co= verage in one fell swoop. If a developer wants they can always delete the l= ines that bail out of the tests to get the desired panic. I don't think there is a RIGHT answer. I just ask that it be noisy about the choice that's being made. In other words, it should be very explicit that it's running a "safe" subset of the tests because FreeBSD's ZFS can't actually pass all of them, and that there be a flag to enable those of us who want to see the failure to see it without modifying any scripts or config files. A test framework that requires me to muck with settings to run failing tests isn't living up to its full potential. -K