From owner-freebsd-stable@FreeBSD.ORG Sun Dec 14 17:23: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 48200204; Sun, 14 Dec 2014 17:23:17 +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 D83317C6; Sun, 14 Dec 2014 17:23:16 +0000 (UTC) Received: by mail-la0-f48.google.com with SMTP id gf13so8468532lab.35 for ; Sun, 14 Dec 2014 09:23:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=0GbBo7N+YHn2JXx/aR76dmTDf+bu4FmDojsHQVIpu+0=; b=k0Ni9Pe/TL0JhhQyxmLhVgvz0qvxblsYQlatCuDy+RupciYJhWSxEAEwpEYgS0ah++ 6Gv5c1P0SKm9AuO6ibETsZzt20OO/yRkRkLqASd/vYrXugUFGLG0e+ifQQBj+22fOubW fCLXZakr9al+B408tlF+/IUt8jsp0D6Ori+aeT5XXRQCe0nmNdIX++xJ0msxqaUD8UcZ /PS3g30dEFsxoN0bKassc3CCNTVexifZw4SbioGtYWkhupwjLusbXKwUblUK+hIBj9VV W67kffG+qpTrlU0350vv+r3MaZE8rinaGOFdy0Ws6pX0qcLsGz8UMQZxlXVZiHVoe8OJ lC1A== MIME-Version: 1.0 X-Received: by 10.152.205.74 with SMTP id le10mr25841995lac.96.1418577794855; Sun, 14 Dec 2014 09:23:14 -0800 (PST) Sender: thomas.e.zander@googlemail.com Received: by 10.25.77.17 with HTTP; Sun, 14 Dec 2014 09:23:14 -0800 (PST) In-Reply-To: References: <20141122171734.GA4600@marvin2011.fritz.box> <5470C695.3040204@yahoo.com.br> Date: Sun, 14 Dec 2014 18:23:14 +0100 X-Google-Sender-Auth: --jcUN80-0Wh6YTHFmSQ6GMvBts Message-ID: Subject: Re: ath(4) device timeout -> reboot necessary From: Thomas Zander To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: Danilo Egea Gondolfo , FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2014 17:23:17 -0000 On 23 November 2014 at 13:23, Thomas Zander wrote: > On 22 November 2014 at 19:11, Adrian Chadd wrote: > >> Try setting >> sysctl dev.ath.0.hal.force_full_reset=1 > > Thanks Adrian. I put this into sysctl.conf and observe the effects > over the next weeks. I made the following observations in the past two weeks regarding this sysctl: - Reboots are not strictly necessary after an ath0 device timeout to get wifi to reconnect, as you expected, - If a device timeout has happend once, it is a virtual certainty to get the next one within 2 hours. This continues until the next reboot. So *something* might not get reset fully Any ideas? Best regards Riggs From owner-freebsd-stable@FreeBSD.ORG Sun Dec 14 17:48: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 29B5DA10 for ; Sun, 14 Dec 2014 17:48:06 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (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 007B99AD for ; Sun, 14 Dec 2014 17:48:05 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Y0DGx-000Aon-6c for freebsd-stable@freebsd.org; Sun, 14 Dec 2014 17:47:59 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sBEHlwuR023094 for ; Sun, 14 Dec 2014 10:47:58 -0700 (MST) (envelope-from ian@freebsd.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/6r9xyLFqAnxuSikI8yeD9 Message-ID: <1418579278.2026.9.camel@freebsd.org> Subject: i386 PAE kernel works fine on 10-stable From: Ian Lepore To: FreeBSD Stable Date: Sun, 14 Dec 2014 10:47:58 -0700 Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.8 FreeBSD GNOME Team Port Mime-Version: 1.0 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, 14 Dec 2014 17:48:06 -0000 This is an out of the blue FYI post to let people know that despite all the misinformation you'll run across if you search for information on FreeBSD PAE support, it (still) works just fine. I've been using it (for reasons related to our build system and products at $work) since 2006, and I can say unequivocally that it works fine on 6.x, 8.x, and now 10.x (and presumably on the odd-numbered releases too but I've never tried those). In my most recent testing with 10-stable, I found it was compatible with drm2 and radeonkms drivers and I was able to run Xorg and gnome just fine. All my devices, and apps, and even the linuxulator worked just fine. One thing that changed somewhere between 8.4 and 10.1 is that I had to add a kernel tuning option to my kernel config: option KVA_PAGES=768 # Default is 512 I suspect that the most frequent use of PAE is on laptops that have 4gb and the default tuning is adequate for that. My desktop machine has 12gb and I needed to bump up that value to avoid errors related to being unable to create new kernel stacks. -- Ian From owner-freebsd-stable@FreeBSD.ORG Sun Dec 14 18:09:50 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 4FC24210; Sun, 14 Dec 2014 18:09:50 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 3EFA2B92; Sun, 14 Dec 2014 18:09:49 +0000 (UTC) Received: from [10.0.1.20] (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 2A954341F83D; Sun, 14 Dec 2014 10:09:43 -0800 (PST) Subject: Re: i386 PAE kernel works fine on 10-stable Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alfred Perlstein In-Reply-To: <1418579278.2026.9.camel@freebsd.org> Date: Sun, 14 Dec 2014 10:09:46 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1418579278.2026.9.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.1283) 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: Sun, 14 Dec 2014 18:09:50 -0000 On Dec 14, 2014, at 9:47 AM, Ian Lepore wrote: > This is an out of the blue FYI post to let people know that despite = all > the misinformation you'll run across if you search for information on > FreeBSD PAE support, it (still) works just fine. I've been using it > (for reasons related to our build system and products at $work) since > 2006, and I can say unequivocally that it works fine on 6.x, 8.x, and > now 10.x (and presumably on the odd-numbered releases too but I've = never > tried those). >=20 > In my most recent testing with 10-stable, I found it was compatible = with > drm2 and radeonkms drivers and I was able to run Xorg and gnome just > fine. All my devices, and apps, and even the linuxulator worked just > fine. >=20 > One thing that changed somewhere between 8.4 and 10.1 is that I had to > add a kernel tuning option to my kernel config: >=20 > option KVA_PAGES=3D768 # Default is 512 >=20 > I suspect that the most frequent use of PAE is on laptops that have = 4gb > and the default tuning is adequate for that. My desktop machine has > 12gb and I needed to bump up that value to avoid errors related to = being > unable to create new kernel stacks. >=20 There already is a #define that is bifurcated based on PAE in pmap.h: #ifndef KVA_PAGES #ifdef PAE #define KVA_PAGES 512 #else #define KVA_PAGES 256 #endif #endif Do you think it will harm things to apply your suggested default to this = file? -Alfred From owner-freebsd-stable@FreeBSD.ORG Sun Dec 14 18:12: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 105EA39C for ; Sun, 14 Dec 2014 18:12:41 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (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 D97F2C60 for ; Sun, 14 Dec 2014 18:12:40 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Y0Dep-0004UP-8g; Sun, 14 Dec 2014 18:12:39 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sBEICaUP023319; Sun, 14 Dec 2014 11:12:36 -0700 (MST) (envelope-from ian@freebsd.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+EXeRRU6Lgkileoy0iwRB8 Message-ID: <1418580756.2026.12.camel@freebsd.org> Subject: Re: i386 PAE kernel works fine on 10-stable From: Ian Lepore To: Alfred Perlstein Date: Sun, 14 Dec 2014 11:12:36 -0700 In-Reply-To: References: <1418579278.2026.9.camel@freebsd.org> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.8 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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: Sun, 14 Dec 2014 18:12:41 -0000 On Sun, 2014-12-14 at 10:09 -0800, Alfred Perlstein wrote: > On Dec 14, 2014, at 9:47 AM, Ian Lepore wrote: > > > This is an out of the blue FYI post to let people know that despite all > > the misinformation you'll run across if you search for information on > > FreeBSD PAE support, it (still) works just fine. I've been using it > > (for reasons related to our build system and products at $work) since > > 2006, and I can say unequivocally that it works fine on 6.x, 8.x, and > > now 10.x (and presumably on the odd-numbered releases too but I've never > > tried those). > > > > In my most recent testing with 10-stable, I found it was compatible with > > drm2 and radeonkms drivers and I was able to run Xorg and gnome just > > fine. All my devices, and apps, and even the linuxulator worked just > > fine. > > > > One thing that changed somewhere between 8.4 and 10.1 is that I had to > > add a kernel tuning option to my kernel config: > > > > option KVA_PAGES=768 # Default is 512 > > > > I suspect that the most frequent use of PAE is on laptops that have 4gb > > and the default tuning is adequate for that. My desktop machine has > > 12gb and I needed to bump up that value to avoid errors related to being > > unable to create new kernel stacks. > > > > There already is a #define that is bifurcated based on PAE in pmap.h: > > #ifndef KVA_PAGES > #ifdef PAE > #define KVA_PAGES 512 > #else > #define KVA_PAGES 256 > #endif > #endif > > Do you think it will harm things to apply your suggested default to this file? > I would have to defer to someone who actually understands just what that parm is tuning. It was purely speculation on my part that the current default is adequate for less memory than I have, and I don't know what that downside might be for setting it too high. -- Ian From owner-freebsd-stable@FreeBSD.ORG Sun Dec 14 18:37: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 401EED60 for ; Sun, 14 Dec 2014 18:37:41 +0000 (UTC) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 02005E4D for ; Sun, 14 Dec 2014 18:37:41 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 58E36B80B0; Sun, 14 Dec 2014 19:37:39 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 462EF28494; Sun, 14 Dec 2014 19:37:39 +0100 (CET) Date: Sun, 14 Dec 2014 19:37:39 +0100 From: Jilles Tjoelker To: Walter Hop Subject: Re: System hang on shutdown when running freebsd-update Message-ID: <20141214183739.GC84077@stack.nl> References: <548846F8.4080208@club-internet.fr> <20141210133658.GA12721@ozzmosis.com> <54885894.2060006@club-internet.fr> <7FE045BA-246F-460F-81F5-CFC312072A92@spam.lifeforms.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7FE045BA-246F-460F-81F5-CFC312072A92@spam.lifeforms.nl> User-Agent: Mutt/1.5.21 (2010-09-15) 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: Sun, 14 Dec 2014 18:37:41 -0000 On Wed, Dec 10, 2014 at 09:48:18PM +0100, Walter Hop wrote: > root@current:~ # chflags noschg /sbin/init > root@current:~ # cp -Rp /sbin/init /sbin/init2 > lock order reversal: > 1st 0xfffffe007b842fa0 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3093 > 2nd 0xfffff80002b9ea00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe000025c270 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe000025c320 > witness_checkorder() at witness_checkorder+0xdad/frame 0xfffffe000025c3b0 > _sx_xlock() at _sx_xlock+0x75/frame 0xfffffe000025c3f0 > ufsdirhash_add() at ufsdirhash_add+0x3a/frame 0xfffffe000025c430 > ufs_direnter() at ufs_direnter+0x6a0/frame 0xfffffe000025c4f0 > ufs_makeinode() at ufs_makeinode+0x560/frame 0xfffffe000025c6a0 > VOP_CREATE_APV() at VOP_CREATE_APV+0xf1/frame 0xfffffe000025c6d0 > vn_open_cred() at vn_open_cred+0x29d/frame 0xfffffe000025c820 > kern_openat() at kern_openat+0x26f/frame 0xfffffe000025c9a0 > amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe000025cab0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe000025cab0 > --- syscall (5, FreeBSD ELF64, sys_open), rip = 0x80094f01a, rsp = 0x7fffffffe958, rbp = 0x7fffffffe9c0 --- > Screenshot is here: http://lf.ms/current-r273635-hang-1.png > Finally, when rebooting, another lock order reversal appears and the > system hangs. I don’t have a text log of this, so I’ll copy the first > few lines: > Syncing disks, vnodes remaining…1 0 0 done > All buffers synced. > lock order reversal: > 1st 0xfffff80002e65d50 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1223 > 2nd 0xfffff80002e665f0 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2144 > Screenshot is here: http://lf.ms/current-r273635-hang-2.png > I don’t have kernel hacking experience, but these source files look > awfully related to the parts that we are having problems with. > I would really love some research into this and possibly an errata for > 10.1. What can we do to make this actionable? Both of these LORs are false positives. There is no mechanism in WITNESS to suppress them properly. I cannot reproduce the problem (VirtualBox, stable/10 amd64 and head i386), so apparently there is something special about some users' environments that causes this. -- Jilles Tjoelker From owner-freebsd-stable@FreeBSD.ORG Sun Dec 14 18:53:12 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 EF5C517A; Sun, 14 Dec 2014 18:53:12 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id DCE44FED; Sun, 14 Dec 2014 18:53:12 +0000 (UTC) Received: from [10.0.1.20] (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 4EE0E341F84F; Sun, 14 Dec 2014 10:53:12 -0800 (PST) Subject: Re: i386 PAE kernel works fine on 10-stable Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Alfred Perlstein In-Reply-To: <1418580756.2026.12.camel@freebsd.org> Date: Sun, 14 Dec 2014 10:53:14 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <847BD158-0867-4F5F-83A9-1651E77D29EF@mu.org> References: <1418579278.2026.9.camel@freebsd.org> <1418580756.2026.12.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.1283) 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: Sun, 14 Dec 2014 18:53:13 -0000 On Dec 14, 2014, at 10:12 AM, Ian Lepore wrote: > On Sun, 2014-12-14 at 10:09 -0800, Alfred Perlstein wrote: >> On Dec 14, 2014, at 9:47 AM, Ian Lepore wrote: >>=20 >>> This is an out of the blue FYI post to let people know that despite = all >>> the misinformation you'll run across if you search for information = on >>> FreeBSD PAE support, it (still) works just fine. I've been using it >>> (for reasons related to our build system and products at $work) = since >>> 2006, and I can say unequivocally that it works fine on 6.x, 8.x, = and >>> now 10.x (and presumably on the odd-numbered releases too but I've = never >>> tried those). >>>=20 >>> In my most recent testing with 10-stable, I found it was compatible = with >>> drm2 and radeonkms drivers and I was able to run Xorg and gnome just >>> fine. All my devices, and apps, and even the linuxulator worked = just >>> fine. >>>=20 >>> One thing that changed somewhere between 8.4 and 10.1 is that I had = to >>> add a kernel tuning option to my kernel config: >>>=20 >>> option KVA_PAGES=3D768 # Default is 512 >>>=20 >>> I suspect that the most frequent use of PAE is on laptops that have = 4gb >>> and the default tuning is adequate for that. My desktop machine has >>> 12gb and I needed to bump up that value to avoid errors related to = being >>> unable to create new kernel stacks. >>>=20 >>=20 >> There already is a #define that is bifurcated based on PAE in pmap.h: >>=20 >> #ifndef KVA_PAGES >> #ifdef PAE >> #define KVA_PAGES 512 >> #else >> #define KVA_PAGES 256 >> #endif >> #endif >>=20 >> Do you think it will harm things to apply your suggested default to = this file? >>=20 >=20 > I would have to defer to someone who actually understands just what = that > parm is tuning. It was purely speculation on my part that the current > default is adequate for less memory than I have, and I don't know what > that downside might be for setting it too high. >=20 KVA pages is the amount of pages reserved for kernel address space: * Size of Kernel address space. This is the number of page table pages * (4MB each) to use for the kernel. 256 pages =3D=3D 1 Gigabyte. * This **MUST** be a multiple of 4 (eg: 252, 256, 260, etc). * For PAE, the page table page unit size is 2MB. This means that 512 = pages * is 1 Gigabyte. Double everything. It must be a multiple of 8 for = PAE. It appears that our default for PAE leaves 1GB for kernel address to = play with? That's an interesting default. Wonder if it really makes = sense for PAE since the assumption is that you'll have >4GB ram in the = box, wiring down 1.5GB for kernel would seem to make sense=85 Probably = make sense to ask Peter or Alan on this. Also wondering how bad it would be to make these tunables, I see they = trickle down quite a bit into the system, hopefully not defining some = static arrays, but I haven't dived down that far. Ian, just to understand better, how much memory is in your machine? -Alfred From owner-freebsd-stable@FreeBSD.ORG Sun Dec 14 19:25:11 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 9812ABB3; Sun, 14 Dec 2014 19:25:11 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::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 430FB37C; Sun, 14 Dec 2014 19:25:11 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id B088E16A402; Sun, 14 Dec 2014 20:25:06 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXqmPe3u7Wkv; Sun, 14 Dec 2014 20:24:55 +0100 (CET) Received: from [IPv6:2001:4cb8:3:1:7c0e:cd5d:381f:40b2] (unknown [IPv6:2001:4cb8:3:1:7c0e:cd5d:381f:40b2]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 05E8E16A404; Sun, 14 Dec 2014 20:12:44 +0100 (CET) Message-ID: <548DE12A.7050208@digiware.nl> Date: Sun, 14 Dec 2014 20:12:42 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: missing /usr/lib/libc_nonshared.a References: <54837FAC.801@digiware.nl> <548AAC45.8080800@digiware.nl> <548B7941.4080303@digiware.nl> In-Reply-To: <548B7941.4080303@digiware.nl> Content-Type: text/plain; charset=ISO-8859-1 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: Sun, 14 Dec 2014 19:25:11 -0000 On 13-12-2014 0:24, Willem Jan Withagen wrote: > On 12-12-2014 16:12, Dimitry Andric wrote: >> On 12 Dec 2014, at 09:50, Willem Jan Withagen wrote: >>> >>> On 2014-12-06 23:14, Willem Jan Withagen wrote: >>>> Still trying to upgrade from 9.3 to 10.1, which seemed to get going. >>>> Completely started over again with cleaned out /etc/{make.src}.conf. >>>> Then build/installed 9.3 again which also included clang this time. >>>> >>>> but building the toolchain generates: >>>> -------------------------------------------------------------- >>>>>>> stage 2.3: build tools >>>> -------------------------------------------------------------- >> ... >>>> cc -o gethost -L/usr/obj/usr/src10/tmp/legacy/usr/lib -O2 -pipe -I. >>>> -I/usr/src10/bin/csh -I/usr/src10/bin/csh/../../contrib/tcsh >>>> -D_PATH_TCSHELL='"/bin/csh"' -std=gnu99 >>>> -I/usr/obj/usr/src10/tmp/legacy/usr/include >>>> /usr/src10/bin/csh/../../contrib/tcsh/gethost.c >>>> /usr/bin/ld: cannot find /usr/lib/libc_nonshared.a >>>> *** Error code 1 >>>> ----------------- >>>> >>>> Now I can fudge around this, by getting this lib from another 10.x >>>> system, but changes are that things are nog 100% compatible. >>>> >>>> So how do I get this lib first, before starting to build bin/csh. >> >> This part of buildworld uses the compiler, include files, linker and >> libraries from your existing system. E.g. it is normal for this part to >> use /usr/bin/ld, /usr/lib, and so on. >> >> On a 9.3 system, I would not expect ld to search for libc_nonshared.a, >> since that is a feature introduced in 10.0, where /usr/lib/libc.so was >> changed from a symlink to a linker script. >> >> Can you please check on your system, what /usr/lib/libc.so is? Is it a >> symlink or a plain text file? If it is the latter, your system is most >> likely polluted with 10.x installation left-overs. > > Right, then this is a consequence of something I'm trying to repair.... > I thought I build world+kernel. > So I installed kernel and rebooted, > Only to find out that instalworld did not make it very far. > > After that I started fidgeting, hoping to somehow get to 10.1. > > So my guess is that things get very upset if one is building on a system > with a 10.1 kernel, and a 9.3 world. > >>>> The other question is: >>>> why am I still using gcc for the toolchain even since I now have >>>> clang onboard? >> >> For the early stages of buildworld, e.g. bootstrap-tools, build-tools >> and cross-tools, it is normal that the system compiler is used, e.g. >> just /usr/bin/cc. >> >> On a 9.x system, that is usually gcc, but this does not say anything >> about the later stages of buildworld, which will be built with the >> toolchain produced in the cross-tools stage. For 10.x, that is usually >> clang. >> >> >>> Turn out that the only way I could cheat make in to going anywhere was to: >>> cd /usr/src/lib/libc_nonshared >>> make >>> make install >>> >>> And only then the build seems to progress. >> >> I think it is better to inspect your /usr/lib/libc.so, and find out if >> it is accidentally replaced by a linker script. > > /* $FreeBSD: stable/10/lib/libc/libc.ldscript 258398 2013-11-20 > 20:24:59Z peter $ */ > GROUP ( /lib/libc.so.7 /usr/lib/libc_nonshared.a > /usr/lib/libssp_nonshared.a ) > > So that seem to be the case > >>> This all even though the /usr/obj tree holds: >>> [~] wjw > locate libc_non >>> /usr/objs/amd64/usr/src10/lib/libc_nonshared >>> /usr/objs/amd64/usr/src10/lib/libc_nonshared/.depend >>> /usr/objs/amd64/usr/src10/lib/libc_nonshared/__iconv.o >>> /usr/objs/amd64/usr/src10/lib/libc_nonshared/__iconv_free_list.o >>> /usr/objs/amd64/usr/src10/lib/libc_nonshared/__iconv_get_list.o >>> /usr/objs/amd64/usr/src10/lib/libc_nonshared/__stub.o >>> /usr/objs/amd64/usr/src10/lib/libc_nonshared/iconv.o >>> /usr/objs/amd64/usr/src10/lib/libc_nonshared/iconv_canonicalize.o >>> /usr/objs/amd64/usr/src10/lib/libc_nonshared/iconv_close.o >>> /usr/objs/amd64/usr/src10/lib/libc_nonshared/iconv_open.o >>> /usr/objs/amd64/usr/src10/lib/libc_nonshared/iconv_open_into.o >>> /usr/objs/amd64/usr/src10/lib/libc_nonshared/iconv_set_relocation_prefix.o >>> /usr/objs/amd64/usr/src10/lib/libc_nonshared/iconvctl.o >>> /usr/objs/amd64/usr/src10/lib/libc_nonshared/iconvlist.o >>> /usr/objs/amd64/usr/src10/lib/libc_nonshared/libc_nonshared.a >>> /usr/objs/amd64/usr/src10/tmp/usr/lib/libc_nonshared.a >>> >>> And I would expect csh to be build against: >>> /usr/objs/amd64/usr/src10/tmp/usr/lib/libc_nonshared.a >>> >>> But for what happened, I conclude that it is linked against /usr/lib. >> >> During the early stages of buildworld, this is completely normal, and >> expected. > > I just manually went into /usr/src/lib/libc_nonshared and ran > make > make install > > And now I'm trying to build world on a 1.8GHz atom, so that is slow.... > Even just compiling clang is already a serious undertaking. Just a closing remark on the issue... Compilation went thru, and I was able to install 10.1 Running it right now. Thanx for the help, --WjW From owner-freebsd-stable@FreeBSD.ORG Sun Dec 14 19:26:58 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 0D642CA3; Sun, 14 Dec 2014 19:26:58 +0000 (UTC) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::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 9105C38F; Sun, 14 Dec 2014 19:26:57 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id n3so7094018wiv.1 for ; Sun, 14 Dec 2014 11:26:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=9J1VdjcdIXde7C3t76Qi6Le3gosSmEoUEXCP5u9LBQc=; b=hnmbClnmTSNLTwhWVYD8USFaN1J3VJqbUz0HNrqvTc4/kD+TnOmW5C9XocrgaHrr8j 7WOCszbKkDr7/HvvIDEyKSmK6jwAMFN0Khe5lAaR/SrJyaYKGB/ubw6d7WXoWXyw2Ewb CGB7YFQraGO71g+bycHjXCjsXs9NVuYpP+2do5YBs9apLHH4NDJAa1+szd6GUXJrX/Fx 0kWe2GXqBSRkKBH6fJiJQa4zW8nG7MEXZ5poglJALls4LhaaZx40cOjRl+6MEdTu4oHK iCd5yT5M5d3m0qJuee6KW9JN2Kae+lUnWh9q16xTjZgmIYndSRplpjp57B/zqx4hN+x6 4wNA== MIME-Version: 1.0 X-Received: by 10.194.24.103 with SMTP id t7mr46044349wjf.15.1418585214886; Sun, 14 Dec 2014 11:26:54 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.195 with HTTP; Sun, 14 Dec 2014 11:26:54 -0800 (PST) In-Reply-To: References: <20141122171734.GA4600@marvin2011.fritz.box> <5470C695.3040204@yahoo.com.br> Date: Sun, 14 Dec 2014 11:26:54 -0800 X-Google-Sender-Auth: 9M1p1nJbYAd5_ng5IuMFDHzmY4c Message-ID: Subject: Re: ath(4) device timeout -> reboot necessary From: Adrian Chadd To: Thomas Zander Content-Type: text/plain; charset=UTF-8 Cc: Danilo Egea Gondolfo , FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2014 19:26:58 -0000 Hi, Nope. In theory the full reset is doing just that.. a full chip cold stop and start. There's only a handful of state that needs a full reset line pulldown to achieve. So if that's fixing it then ok, maybe there's some issues i can patch aronud by doing a full chip reset. I wonder if there are also some bugs lurking in some of the calibration code that keeps state over time; or the ANI code that keeps state over time. -adrian On 14 December 2014 at 09:23, Thomas Zander wrote: > On 23 November 2014 at 13:23, Thomas Zander wrote: >> On 22 November 2014 at 19:11, Adrian Chadd wrote: >> >>> Try setting >>> sysctl dev.ath.0.hal.force_full_reset=1 >> >> Thanks Adrian. I put this into sysctl.conf and observe the effects >> over the next weeks. > > I made the following observations in the past two weeks regarding this sysctl: > - Reboots are not strictly necessary after an ath0 device timeout to > get wifi to reconnect, as you expected, > - If a device timeout has happend once, it is a virtual certainty to > get the next one within 2 hours. This continues until the next reboot. > So *something* might not get reset fully > > Any ideas? > > Best regards > Riggs From owner-freebsd-stable@FreeBSD.ORG Sun Dec 14 19: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 9DC7EF64 for ; Sun, 14 Dec 2014 19:39:50 +0000 (UTC) Received: from tau.lfms.nl (tau.lfms.nl [93.189.130.30]) (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 2D344686 for ; Sun, 14 Dec 2014 19:39:49 +0000 (UTC) Received: from sim.dt.lfms.nl (dt.lfms.nl [83.84.86.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by tau.lfms.nl (Postfix) with ESMTPS id 217E689E9E for ; Sun, 14 Dec 2014 20:39:40 +0100 (CET) Received: from [192.168.130.112] (borax.dt.lfms.nl [192.168.130.112]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sim.dt.lfms.nl (Postfix) with ESMTPS id CE3D69C090A2 for ; Sun, 14 Dec 2014 20:39:39 +0100 (CET) From: Walter Hop Message-Id: <97F0F0EE-D312-49F2-8B49-5FB959BCD1B2@spam.lifeforms.nl> Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: System hang on shutdown when running freebsd-update Date: Sun, 14 Dec 2014 20:39:39 +0100 References: <548846F8.4080208@club-internet.fr> <20141210133658.GA12721@ozzmosis.com> <54885894.2060006@club-internet.fr> <7FE045BA-246F-460F-81F5-CFC312072A92@spam.lifeforms.nl> <20141214183739.GC84077@stack.nl> To: freebsd-stable@freebsd.org In-Reply-To: <20141214183739.GC84077@stack.nl> X-Mailer: Apple Mail (2.1993) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Sun, 14 Dec 2014 19:39:50 -0000 Hi Jilles! > On 14 Dec 2014, at 19:37, Jilles Tjoelker wrote: >=20 > Both of these LORs are false positives. There is no mechanism in = WITNESS > to suppress them properly. Thanks for checking :) > I cannot reproduce the problem (VirtualBox, stable/10 amd64 and head > i386), so apparently there is something special about some users' > environments that causes this. Interesting! Was the root filesystem using UFS+SU? I tried installing = VirtualBox on OS X and did a clean 10.1 amd64 iso install within it, and = I *did* get the crash. Tried switching chipset emulation in Vbox but I = can=E2=80=99t seem to not get it... --=20 Walter Hop | PGP key: https://lifeforms.nl/pgp From owner-freebsd-stable@FreeBSD.ORG Sun Dec 14 19: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 AC2C1394 for ; Sun, 14 Dec 2014 19:59:30 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (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 7E5AE895 for ; Sun, 14 Dec 2014 19:59:30 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Y0FKC-000B9K-GF; Sun, 14 Dec 2014 19:59:28 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sBEJxPFk023629; Sun, 14 Dec 2014 12:59:26 -0700 (MST) (envelope-from ian@freebsd.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19D1hb63Nw3bxl2lSJIOmCX Message-ID: <1418587165.977.0.camel@freebsd.org> Subject: Re: i386 PAE kernel works fine on 10-stable From: Ian Lepore To: Alfred Perlstein Date: Sun, 14 Dec 2014 12:59:25 -0700 In-Reply-To: <847BD158-0867-4F5F-83A9-1651E77D29EF@mu.org> References: <1418579278.2026.9.camel@freebsd.org> <1418580756.2026.12.camel@freebsd.org> <847BD158-0867-4F5F-83A9-1651E77D29EF@mu.org> Content-Type: text/plain; charset="windows-1251" X-Mailer: Evolution 3.12.8 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id sBEJxPFk023629 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: Sun, 14 Dec 2014 19:59:30 -0000 On Sun, 2014-12-14 at 10:53 -0800, Alfred Perlstein wrote: > On Dec 14, 2014, at 10:12 AM, Ian Lepore wrote: >=20 > > On Sun, 2014-12-14 at 10:09 -0800, Alfred Perlstein wrote: > >> On Dec 14, 2014, at 9:47 AM, Ian Lepore wrote: > >>=20 > >>> This is an out of the blue FYI post to let people know that despite= all > >>> the misinformation you'll run across if you search for information = on > >>> FreeBSD PAE support, it (still) works just fine. I've been using i= t > >>> (for reasons related to our build system and products at $work) sin= ce > >>> 2006, and I can say unequivocally that it works fine on 6.x, 8.x, a= nd > >>> now 10.x (and presumably on the odd-numbered releases too but I've = never > >>> tried those). > >>>=20 > >>> In my most recent testing with 10-stable, I found it was compatible= with > >>> drm2 and radeonkms drivers and I was able to run Xorg and gnome jus= t > >>> fine. All my devices, and apps, and even the linuxulator worked ju= st > >>> fine. > >>>=20 > >>> One thing that changed somewhere between 8.4 and 10.1 is that I had= to > >>> add a kernel tuning option to my kernel config: > >>>=20 > >>> option KVA_PAGES=3D768 # Default is 512 > >>>=20 > >>> I suspect that the most frequent use of PAE is on laptops that have= 4gb > >>> and the default tuning is adequate for that. My desktop machine ha= s > >>> 12gb and I needed to bump up that value to avoid errors related to = being > >>> unable to create new kernel stacks. > >>>=20 > >>=20 > >> There already is a #define that is bifurcated based on PAE in pmap.h= : > >>=20 > >> #ifndef KVA_PAGES > >> #ifdef PAE > >> #define KVA_PAGES 512 > >> #else > >> #define KVA_PAGES 256 > >> #endif > >> #endif > >>=20 > >> Do you think it will harm things to apply your suggested default to = this file? > >>=20 > >=20 > > I would have to defer to someone who actually understands just what t= hat > > parm is tuning. It was purely speculation on my part that the curren= t > > default is adequate for less memory than I have, and I don't know wha= t > > that downside might be for setting it too high. > >=20 >=20 > KVA pages is the amount of pages reserved for kernel address space: >=20 > * Size of Kernel address space. This is the number of page table page= s > * (4MB each) to use for the kernel. 256 pages =3D=3D 1 Gigabyte. > * This **MUST** be a multiple of 4 (eg: 252, 256, 260, etc). > * For PAE, the page table page unit size is 2MB. This means that 512 = pages > * is 1 Gigabyte. Double everything. It must be a multiple of 8 for P= AE. >=20 > It appears that our default for PAE leaves 1GB for kernel address to pl= ay with? That's an interesting default. Wonder if it really makes sense= for PAE since the assumption is that you'll have >4GB ram in the box, wi= ring down 1.5GB for kernel would seem to make sense=85 Probably make sen= se to ask Peter or Alan on this. >=20 > Also wondering how bad it would be to make these tunables, I see they t= rickle down quite a bit into the system, hopefully not defining some stat= ic arrays, but I haven't dived down that far. >=20 > Ian, just to understand better, how much memory is in your machine? >=20 12GB. -- Ian From owner-freebsd-stable@FreeBSD.ORG Sun Dec 14 20:22: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 3F1C56BE; Sun, 14 Dec 2014 20:22:08 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 1FC4FAF0; Sun, 14 Dec 2014 20:22:07 +0000 (UTC) Received: from [10.0.1.20] (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 34F6B341F83D; Sun, 14 Dec 2014 12:22:06 -0800 (PST) Subject: Re: i386 PAE kernel works fine on 10-stable Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1251 From: Alfred Perlstein In-Reply-To: <1418587165.977.0.camel@freebsd.org> Date: Sun, 14 Dec 2014 12:22:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <705D7AEE-D0D6-477B-80F5-746E2B1104B2@mu.org> References: <1418579278.2026.9.camel@freebsd.org> <1418580756.2026.12.camel@freebsd.org> <847BD158-0867-4F5F-83A9-1651E77D29EF@mu.org> <1418587165.977.0.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.1283) 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: Sun, 14 Dec 2014 20:22:08 -0000 On Dec 14, 2014, at 11:59 AM, Ian Lepore wrote: > On Sun, 2014-12-14 at 10:53 -0800, Alfred Perlstein wrote: >> On Dec 14, 2014, at 10:12 AM, Ian Lepore wrote: >>=20 >>> On Sun, 2014-12-14 at 10:09 -0800, Alfred Perlstein wrote: >>>> On Dec 14, 2014, at 9:47 AM, Ian Lepore wrote: >>>>=20 >>>>> This is an out of the blue FYI post to let people know that = despite all >>>>> the misinformation you'll run across if you search for information = on >>>>> FreeBSD PAE support, it (still) works just fine. I've been using = it >>>>> (for reasons related to our build system and products at $work) = since >>>>> 2006, and I can say unequivocally that it works fine on 6.x, 8.x, = and >>>>> now 10.x (and presumably on the odd-numbered releases too but I've = never >>>>> tried those). >>>>>=20 >>>>> In my most recent testing with 10-stable, I found it was = compatible with >>>>> drm2 and radeonkms drivers and I was able to run Xorg and gnome = just >>>>> fine. All my devices, and apps, and even the linuxulator worked = just >>>>> fine. >>>>>=20 >>>>> One thing that changed somewhere between 8.4 and 10.1 is that I = had to >>>>> add a kernel tuning option to my kernel config: >>>>>=20 >>>>> option KVA_PAGES=3D768 # Default is 512 >>>>>=20 >>>>> I suspect that the most frequent use of PAE is on laptops that = have 4gb >>>>> and the default tuning is adequate for that. My desktop machine = has >>>>> 12gb and I needed to bump up that value to avoid errors related to = being >>>>> unable to create new kernel stacks. >>>>>=20 >>>>=20 >>>> There already is a #define that is bifurcated based on PAE in = pmap.h: >>>>=20 >>>> #ifndef KVA_PAGES >>>> #ifdef PAE >>>> #define KVA_PAGES 512 >>>> #else >>>> #define KVA_PAGES 256 >>>> #endif >>>> #endif >>>>=20 >>>> Do you think it will harm things to apply your suggested default to = this file? >>>>=20 >>>=20 >>> I would have to defer to someone who actually understands just what = that >>> parm is tuning. It was purely speculation on my part that the = current >>> default is adequate for less memory than I have, and I don't know = what >>> that downside might be for setting it too high. >>>=20 >>=20 >> KVA pages is the amount of pages reserved for kernel address space: >>=20 >> * Size of Kernel address space. This is the number of page table = pages >> * (4MB each) to use for the kernel. 256 pages =3D=3D 1 Gigabyte. >> * This **MUST** be a multiple of 4 (eg: 252, 256, 260, etc). >> * For PAE, the page table page unit size is 2MB. This means that 512 = pages >> * is 1 Gigabyte. Double everything. It must be a multiple of 8 for = PAE. >>=20 >> It appears that our default for PAE leaves 1GB for kernel address to = play with? That's an interesting default. Wonder if it really makes = sense for PAE since the assumption is that you'll have >4GB ram in the = box, wiring down 1.5GB for kernel would seem to make sense=85 Probably = make sense to ask Peter or Alan on this. >>=20 >> Also wondering how bad it would be to make these tunables, I see they = trickle down quite a bit into the system, hopefully not defining some = static arrays, but I haven't dived down that far. >>=20 >> Ian, just to understand better, how much memory is in your machine? >>=20 >=20 > 12GB. Another option to keep things simple it might make sense to add a kernel = conf for PAE-12GLARGER and just include the PAE kernel and set your = tunable. =20 That will keep people with "small PAE" (6G) from perhaps experiencing = changes while still allowing larger PAE customers to tune properly. Adding a note to the top of the PAE kernel stating "this works well for = machines with less than 12GB, but for larger systems you want = PAE-12GLARGER". -Alfred= From owner-freebsd-stable@FreeBSD.ORG Sun Dec 14 20:28: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 67083878; Sun, 14 Dec 2014 20:28:11 +0000 (UTC) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::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 205EBB62; Sun, 14 Dec 2014 20:28:11 +0000 (UTC) Received: by mail-yh0-f52.google.com with SMTP id z6so4628605yhz.11 for ; Sun, 14 Dec 2014 12:28:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U7YZ/7udGjiri+AFzR6j+JUPUGPXFO3lz0URErZANss=; b=zIMsBM8xEe5TAGAerVKfPGR0jf2k/tU1LpDwPQ8yCdXUIQPb+OuvabV6oicEvm2zuB JsT66I1Uvj8hArX+Mqjtt3VnacFWUdMPIdp+cWlIHPtyVrc9eGp9SoRbd2vGuNTz16Gv FOC714DIra69oO+E2LYUsuh1zhKjObyVAX/bwJbd51TITs6G3zk8MnqSYugGqayVYg4x YMMLxZd0/8DaAT1vON7BSZwAUXrLF/qUfjp+xKJ7c5dZfbcaNfA1/Q7M/Y3qGkw/UbWq hAiKYBvB8dZF9ssA3OzCQqTxeQ9qXRu5frBwgCbwEeVcBIraVbZQ+wrNMutgvQBCdtYJ nS2Q== MIME-Version: 1.0 X-Received: by 10.170.90.68 with SMTP id h65mr22347786yka.94.1418588890343; Sun, 14 Dec 2014 12:28:10 -0800 (PST) Received: by 10.170.90.131 with HTTP; Sun, 14 Dec 2014 12:28:10 -0800 (PST) In-Reply-To: <1418587165.977.0.camel@freebsd.org> References: <1418579278.2026.9.camel@freebsd.org> <1418580756.2026.12.camel@freebsd.org> <847BD158-0867-4F5F-83A9-1651E77D29EF@mu.org> <1418587165.977.0.camel@freebsd.org> Date: Sun, 14 Dec 2014 12:28:10 -0800 Message-ID: Subject: Re: i386 PAE kernel works fine on 10-stable From: Mehmet Erol Sanliturk To: Ian Lepore Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Alfred Perlstein , 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: Sun, 14 Dec 2014 20:28:11 -0000 In FreeBSD Handbook , " 2.2. Minimum Hardware Requirements i386 pae(4) for details " when pae(4) is clicked : https://www.freebsd.org/cgi/man.cgi?query=pae&sektion=4 https://www.freebsd.org/cgi/man.cgi?query=pae&apropos=0&sektion=0&manpath=FreeBSD+10.1-RELEASE&arch=default&format=html response is "Sorry, no data found for `pae'." Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-stable@FreeBSD.ORG Mon Dec 15 05:39: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 4EE39126; Mon, 15 Dec 2014 05:39:25 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E363B6A2; Mon, 15 Dec 2014 05:39:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id sBF5crNO039750; Mon, 15 Dec 2014 16:38:54 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 15 Dec 2014 16:38:53 +1100 (EST) From: Ian Smith To: Mehmet Erol Sanliturk Subject: Elusive manpage [was: i386 PAE kernel works fine on 10-stable] In-Reply-To: Message-ID: <20141215161550.M68123@sola.nimnet.asn.au> References: <1418579278.2026.9.camel@freebsd.org> <1418580756.2026.12.camel@freebsd.org> <847BD158-0867-4F5F-83A9-1651E77D29EF@mu.org> <1418587165.977.0.camel@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Alfred Perlstein , FreeBSD Stable , Ian Lepore 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, 15 Dec 2014 05:39:25 -0000 On Sun, 14 Dec 2014 12:28:10, Mehmet Erol Sanliturk wrote: > In FreeBSD Handbook , > > " > 2.2. Minimum Hardware Requirements > i386 > pae(4) for details > " > > when pae(4) is clicked : > > https://www.freebsd.org/cgi/man.cgi?query=pae&sektion=4 > https://www.freebsd.org/cgi/man.cgi?query=pae&apropos=0&sektion=0&manpath=FreeBSD+10.1-RELEASE&arch=default&format=html > > response is > > "Sorry, no data found for `pae'." Indeed. I was going to respond that manpages relating only to (eg) i386 - such as PAE and a network adapter (ep(4)) I recently hunted - don't show up if you've left the default setting of 'default' architecture, which is apparently amd64, but then I checked .. This one doesn't show up on 10.1-RELEASE, even once you've selected i386, but it does for 10.0-RELEASE, 10.0-stable .. and 10.1-stable! Also for 9.3-RELEASE and -stable, and earlier. Personally I think the 'default' arch selector should specifically say 'amd64' rather than 'default', or better still 'default' should mean the default for the manpage concerned, which in this case would be i386. IOW if a manpage exists for any arch, it should show up, at least as a hint that it exists on another arch than (the unspecified) 'default'. cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Mon Dec 15 07:27: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 78151CB6 for ; Mon, 15 Dec 2014 07:27:23 +0000 (UTC) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id B2B22E8 for ; Mon, 15 Dec 2014 07:27:22 +0000 (UTC) Received: (qmail 23480 invoked from network); 15 Dec 2014 07:20:39 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 15 Dec 2014 07:20:38 -0000 Date: Mon, 15 Dec 2014 08:20:38 +0100 (CET) Message-Id: <20141215.082038.41648681.sthaug@nethelp.no> To: freebsd-stable@freebsd.org Subject: Re: BIND chroot environment in 10-RELEASE...gone? From: sthaug@nethelp.no In-Reply-To: <20131203.223612.74719903.sthaug@nethelp.no> References: <20131203.223612.74719903.sthaug@nethelp.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 07:27:23 -0000 > > > It was a deliberate decision made by the maintainer. He said the chroot > > > code in the installation was too complicated and would be removed as a > > > part of the installation clean-up to get all BIND related files out of > > > /usr and /etc. I protested at the time as did someone else, but the > > > maintainer did not respond. I thnk this was a really, really bad > > > decision. > > > > > > I searched a bit for the thread on removing BIND leftovers, but have > > > failed to find it. > > > > > > > You're probably thinking about my November 17 posting: > > http://lists.freebsd.org/pipermail/freebsd-stable/2013-November/075895.html > > > > I'm glad to see others finally speaking up; I was beginning to think I was > > the only one who thought this was not a good idea. I'm a bit surprised > > that no one has responded yet. > > I agree with the protesters here. Removing chroot and symlinking logic > in the ports is a significant disservice to FreeBSD users, and will > make it harder to use BIND in a sensible way. A net disincentive to > use FreeBSD :-( I have now installed my first 10.1 based name server. I had to spend some hours to recreate the changeroot environment that I had so easily available in FreeBSD up to 9.x. Removing the changeroot environment and symlinking logic is a net disservice to the FreeBSD community, and disincentive to use FreeBSD. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-stable@FreeBSD.ORG Mon Dec 15 09:03:55 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 F17718A5 for ; Mon, 15 Dec 2014 09:03:55 +0000 (UTC) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::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 83A3BC7D for ; Mon, 15 Dec 2014 09:03:55 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id r20so8111552wiv.12 for ; Mon, 15 Dec 2014 01:03:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=w7tzSC4XZtm8MSia6z8lkIVjekNepcjyhuGNVeZFUFo=; b=nt3gCxCyzOHUrMN3FSsJta8t6L/Ka3f9YMSE0nvp2re+b3CG2QXo+PZVm75T/8EzN1 lVnycn8mhKUeL4WXrpHNYtJ4R6xwdO7pdAeMEYRcD15Kz21NQOT7h3QVhScr9obrl67G kw7BmkYL1hS0T8o909xXvTg45WKz00R3E3WF/QyybLwOSiseQpHZR0/6Mn2bdNuF/tP+ Mo5UaY5txlLVDxGogLxarmIASV3CmWY59MoDf9tTOJdNkKWpN5gl78YOHxYUOg/4lIxg Eq9nQjGLM9AQfebIPTrKLR36+CaLZ1CU23WhiZv15AP4BdubepDMBCMSBo61QUTHmA/I T/+Q== MIME-Version: 1.0 X-Received: by 10.194.78.3 with SMTP id x3mr48984271wjw.127.1418634233854; Mon, 15 Dec 2014 01:03:53 -0800 (PST) Received: by 10.27.48.13 with HTTP; Mon, 15 Dec 2014 01:03:53 -0800 (PST) In-Reply-To: <20141215.082038.41648681.sthaug@nethelp.no> References: <20131203.223612.74719903.sthaug@nethelp.no> <20141215.082038.41648681.sthaug@nethelp.no> Date: Mon, 15 Dec 2014 20:03:53 +1100 Message-ID: Subject: Re: BIND chroot environment in 10-RELEASE...gone? From: Chris Knight To: freebsd-stable@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: Mon, 15 Dec 2014 09:03:56 -0000 Howdy, On 15 December 2014 at 18:20, wrote: > [snip] > > Removing the changeroot environment and symlinking logic is a net > disservice to the FreeBSD community, and disincentive to use FreeBSD. > > +1 This, and the mess that is pkg, is making me reconsider FreeBSD as my Open Source OS of choice, after 20 years of use. The patchwork quilt of components that makes up a Linux distro doesn't need to be complemented by further FreeBSD releases :-( -- Regards, Chris Knight From owner-freebsd-stable@FreeBSD.ORG Mon Dec 15 09:48: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 5E82648D for ; Mon, 15 Dec 2014 09:48:13 +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 1DD6613E for ; Mon, 15 Dec 2014 09:48:12 +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 1Y0SFx-0006ZD-Ne for freebsd-stable@freebsd.org; Mon, 15 Dec 2014 10:48:03 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: freebsd-stable@freebsd.org Subject: Re: BIND chroot environment in 10-RELEASE...gone? References: <20131203.223612.74719903.sthaug@nethelp.no> <20141215.082038.41648681.sthaug@nethelp.no> Date: Mon, 15 Dec 2014 10:47:56 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <20141215.082038.41648681.sthaug@nethelp.no> 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: 729ef2e9e2cd27dd49f9ca04774c95e6 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, 15 Dec 2014 09:48:13 -0000 On Mon, 15 Dec 2014 08:20:38 +0100, wrote: >> > > It was a deliberate decision made by the maintainer. He said the >> chroot >> > > code in the installation was too complicated and would be removed >> as a >> > > part of the installation clean-up to get all BIND related files out >> of >> > > /usr and /etc. I protested at the time as did someone else, but the >> > > maintainer did not respond. I thnk this was a really, really bad >> > > decision. >> > > >> > > I searched a bit for the thread on removing BIND leftovers, but have >> > > failed to find it. >> > > >> > >> > You're probably thinking about my November 17 posting: >> > >> http://lists.freebsd.org/pipermail/freebsd-stable/2013-November/075895.html >> > >> > I'm glad to see others finally speaking up; I was beginning to think >> I was >> > the only one who thought this was not a good idea. I'm a bit >> surprised >> > that no one has responded yet. >> >> I agree with the protesters here. Removing chroot and symlinking logic >> in the ports is a significant disservice to FreeBSD users, and will >> make it harder to use BIND in a sensible way. A net disincentive to >> use FreeBSD :-( > > I have now installed my first 10.1 based name server. I had to spend > some hours to recreate the changeroot environment that I had so easily > available in FreeBSD up to 9.x. > > > Removing the changeroot environment and symlinking logic is a net > disservice to the FreeBSD community, and disincentive to use FreeBSD. > > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no Isn't this reasoning a bit flawed? Something hurt you so you state it is hurting a whole community. I, for one, am glad the security updates of the Bind software are now better maintainable across all FreeBSD version. NB: using a jail might give an easier to maintain secure environment for bind than a chroot. With more restrictions to the process also. Regards, Ronald. From owner-freebsd-stable@FreeBSD.ORG Mon Dec 15 10:03: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 28E70713 for ; Mon, 15 Dec 2014 10:03:32 +0000 (UTC) Received: from mail.xtaz.uk (tao.xtaz.uk [IPv6:2001:8b0:202::10]) (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 DCBBC343 for ; Mon, 15 Dec 2014 10:03:31 +0000 (UTC) Received: by mail.xtaz.uk (Postfix, from userid 1001) id 9FCAF209AF15; Mon, 15 Dec 2014 10:03:27 +0000 (GMT) Date: Mon, 15 Dec 2014 10:03:27 +0000 From: Matt Smith To: Ronald Klop Subject: Re: BIND chroot environment in 10-RELEASE...gone? Message-ID: <20141215100327.GE52267@xtaz.uk> Mail-Followup-To: Matt Smith , Ronald Klop , freebsd-stable@freebsd.org References: <20131203.223612.74719903.sthaug@nethelp.no> <20141215.082038.41648681.sthaug@nethelp.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 10:03:32 -0000 On Dec 15 10:47, Ronald Klop wrote: >On Mon, 15 Dec 2014 08:20:38 +0100, wrote: >> >>Removing the changeroot environment and symlinking logic is a net >>disservice to the FreeBSD community, and disincentive to use FreeBSD. >> >> >>Steinar Haug, Nethelp consulting, sthaug@nethelp.no > >Isn't this reasoning a bit flawed? Something hurt you so you state it >is hurting a whole community. > >I, for one, am glad the security updates of the Bind software are now >better maintainable across all FreeBSD version. >NB: using a jail might give an easier to maintain secure environment >for bind than a chroot. With more restrictions to the process also. I agree and in my case it improved things. I was using BIND from the base system as an internet authoratitive nameserver. It wasn't designed for this and I should have been using the ports version at least. The removal of BIND from the base made me look at its replacement, Unbound, and from that it led me to NSD. So now I'm using both Unbound and NSD, both in a chroot, and it's much more secure than BIND would have been in my old configuration. Sometimes being forced to make changes can bring improvements. -- Matt From owner-freebsd-stable@FreeBSD.ORG Mon Dec 15 10:41: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 C956FDFD for ; Mon, 15 Dec 2014 10:41:40 +0000 (UTC) Received: from hades.sorbs.net (hades.sorbs.net [67.231.146.201]) by mx1.freebsd.org (Postfix) with ESMTP id 3808399C for ; Mon, 15 Dec 2014 10:41:38 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from isux.com (firewall.isux.com [213.165.190.213]) by hades.sorbs.net (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPSA id <0NGM00LAPDWQKS00@hades.sorbs.net> for freebsd-stable@freebsd.org; Mon, 15 Dec 2014 02:46:03 -0800 (PST) Message-id: <548EBAD9.8050701@sorbs.net> Date: Mon, 15 Dec 2014 11:41:29 +0100 From: Michelle Sullivan User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.24) Gecko/20100301 SeaMonkey/1.1.19 To: Chris Knight Subject: Re: BIND chroot environment in 10-RELEASE...gone? References: <20131203.223612.74719903.sthaug@nethelp.no> <20141215.082038.41648681.sthaug@nethelp.no> In-reply-to: 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, 15 Dec 2014 10:41:41 -0000 Chris Knight wrote: > Howdy, > > On 15 December 2014 at 18:20, wrote: > >> [snip] >> >> Removing the changeroot environment and symlinking logic is a net >> disservice to the FreeBSD community, and disincentive to use FreeBSD. >> >> >> > +1 > This, and the mess that is pkg, is making me reconsider FreeBSD as my > Open Source OS of choice, after 20 years of use. > The patchwork quilt of components that makes up a Linux distro doesn't > need to be complemented by further FreeBSD releases :-( > > +1 Ronald Klop wrote: > > Isn't this reasoning a bit flawed? Something hurt you so you state it > is hurting a whole community. > Not really, the problem is you have production environments, people change something (sometimes announced in advance, sometimes not) a security issue comes out and you "upgrade"/"pactch" and suddenly your production environment is broken because the patch didn't just close a security hole, it rewrote the installation in a way that was incompatible with the running environment. > I, for one, am glad the security updates of the Bind software are now > better maintainable across all FreeBSD version. > NB: using a jail might give an easier to maintain secure environment > for bind than a chroot. With more restrictions to the process also. That it might be, but that doesn't justify changing everything on a whim. Happened to me with the Bapt 1st Sept port patches to force people to switch to pkg... I still don't have my production machines switched over, and despite Bapt doing his damnedest in breaking everything, I now have a working build server (with considerable hacking) using the old package system and a pkgng build system so I can build both and continue to migrate servers. However, I spend most of my time patching the Mk/* and Uses/* directories to keep it working.. which majority of the time is just copying new Uses/* files into the old build system and removing the relevant code from the old *.mk files.. Why haven't I switched to pkgng? Production systems that require regression testing dev env's and instead of doing that I'm building and patching systems to make the build process work... and why am I doing that? Because some patches I required in production (some to make it work, some security related) were not patched back to the quarterly where it all worked *despite asking for them to be* so I had to go down the path of making the old build system work again... Now consider this drive to make FreeBSD more like another Linux with a different kernel.... Why would people switch to FreeBSD now, they might just as well stay with Linux and all the packaging problems.. Consider the above to Solaris and a problem I had yesterday... I still have a few Solaris servers, and used to use 'sunfreeware' .. was always a pain to use for any thing that needed other options than those compiled... but it was good for getting a working compiler then could build my own software the hard way... So when 'sunfreeware' stopped being 'free' I switched to OpenCSW... 48 hours ago I had to update and upgrade 3 of the systems due to the latest BIND9 security issue.. found out, Solaris 8 is not supported anymore (they still have all the old working packages - EOL'd - *not broken* - just frozen in time, no new patches...) Solaris 9 had gone the same way... again *not broken*.. and my Solaris 10 box well they had build the packages against a patched LibC that was incompatible with older systems so with the upgrade I found my system had no working sudo, no working ssh, nor any other tools ... so much for 'pkgutil -U -u' (which is the equiv of 'pkg -f upgrade' in PKGNG) not breaking anything... Turns out it was my problem because of a missing base patch, which I applied and got it all back up and running again... however that was because I still had a root shell over ssh and was able to complete patching before losing my connection otherwise I wouldn't have been able to do anything without remote hands... Now my point? I went to the #OpenCSW IRC channel and managed to get a hold of one of the developers that were able to help with the issue, tell me which patch etc.. but it didn't stop there... I commented that it would be nice if my server wasn't so easily fucked because of a missing patch and it should at least be announced... (I was a little pissed off and tetchy) however, complete professionalism there, they helped with the patchid, indicated that the particular patch should have been applied in 2008.. which led me to find out that the 'automated patching' daemon that Sun made had actually failed to patch anything... they came to an agreement (took on board what I said immediately) and have decided to code a patch so that they pkgutil will check for required base packages and refuse to patch anything (including the catalog) to a version of the system that requires a missing patch. At the same time they updated the website immediately to indicate the issue as a warning to people that might be in the same situation as me... This patch they are working on will effectively create a 'rolling EOL' for a particular build set... ie everything will continue working except you can't patch to a level that requires a BaseOS pre-req... so if you need a patched piece of software and don't have a pre-req OS patch you can still download all the latest working tools so you can roll your own until you can BaseOS patch.... what a refreshing change... Developers that take on good ideas without forcing upgrades first or forcing their own agenda's. Harsh... yes maybe... and my apologies to those FreeBSD developers that I have had private email convos with to resolve issues and patches that have also been as helpful.. but theirs is (mostly) not the public voice of change in FreeBSD... Sorry for the rant. (and no I didn't proof-read before hitting send - spend enough time writing it!) -- Michelle Sullivan http://www.mhix.org/ From owner-freebsd-stable@FreeBSD.ORG Mon Dec 15 11:34:09 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 A7449BDB for ; Mon, 15 Dec 2014 11:34:09 +0000 (UTC) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id E4FF0E73 for ; Mon, 15 Dec 2014 11:34:08 +0000 (UTC) Received: (qmail 30650 invoked from network); 15 Dec 2014 11:34:05 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 15 Dec 2014 11:34:05 -0000 Date: Mon, 15 Dec 2014 12:34:05 +0100 (CET) Message-Id: <20141215.123405.74723741.sthaug@nethelp.no> To: ronald-lists@klop.ws Subject: Re: BIND chroot environment in 10-RELEASE...gone? From: sthaug@nethelp.no In-Reply-To: References: <20131203.223612.74719903.sthaug@nethelp.no> <20141215.082038.41648681.sthaug@nethelp.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 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: Mon, 15 Dec 2014 11:34:09 -0000 > > > > Removing the changeroot environment and symlinking logic is a net > > disservice to the FreeBSD community, and disincentive to use FreeBSD. > > > > > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > > Isn't this reasoning a bit flawed? Something hurt you so you state it is > hurting a whole community. > > I, for one, am glad the security updates of the Bind software are now > better maintainable across all FreeBSD version. I don't see the connection between removing BIND from the base system (I agree that this makes BIND updates better maintainable) and the complete removal of the changeroot/symlink functionality. > NB: using a jail might give an easier to maintain secure environment for > bind than a chroot. With more restrictions to the process also. Absolutely agree. However, that requires time to learn jails properly, which I don't have right now. Thus *for me*, it would have been much nicer if the BIND ports had kept the changeroot/symlink functionality that (as far as I know) Doug Barton put in. I don't claim to speak for anybody but myself :-) Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-stable@FreeBSD.ORG Mon Dec 15 13:01:02 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 85B56741 for ; Mon, 15 Dec 2014 13:01:02 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2F9BF9E4 for ; Mon, 15 Dec 2014 13:01:01 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id sBFD10fi071775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 15 Dec 2014 06:01:00 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id sBFD0xth071772; Mon, 15 Dec 2014 06:00:59 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Mon, 15 Dec 2014 06:00:59 -0700 (MST) From: Warren Block To: sthaug@nethelp.no Subject: Re: BIND chroot environment in 10-RELEASE...gone? In-Reply-To: <20141215.123405.74723741.sthaug@nethelp.no> Message-ID: References: <20131203.223612.74719903.sthaug@nethelp.no> <20141215.082038.41648681.sthaug@nethelp.no> <20141215.123405.74723741.sthaug@nethelp.no> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Mon, 15 Dec 2014 06:01:00 -0700 (MST) Cc: freebsd-stable@freebsd.org, ronald-lists@klop.ws 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, 15 Dec 2014 13:01:02 -0000 On Mon, 15 Dec 2014, sthaug@nethelp.no wrote: >>> >>> Removing the changeroot environment and symlinking logic is a net >>> disservice to the FreeBSD community, and disincentive to use FreeBSD. >>> >>> >>> Steinar Haug, Nethelp consulting, sthaug@nethelp.no >> >> Isn't this reasoning a bit flawed? Something hurt you so you state it is >> hurting a whole community. >> >> I, for one, am glad the security updates of the Bind software are now >> better maintainable across all FreeBSD version. > > I don't see the connection between removing BIND from the base system > (I agree that this makes BIND updates better maintainable) and the > complete removal of the changeroot/symlink functionality. > >> NB: using a jail might give an easier to maintain secure environment for >> bind than a chroot. With more restrictions to the process also. > > Absolutely agree. However, that requires time to learn jails properly, > which I don't have right now. Here is a start: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails-ezjail.html#jails-ezjail-example-bind From owner-freebsd-stable@FreeBSD.ORG Mon Dec 15 14:33:29 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 3ABA7833 for ; Mon, 15 Dec 2014 14:33:29 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 28E0E63E for ; Mon, 15 Dec 2014 14:33:29 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id DE63CDF9 for ; Mon, 15 Dec 2014 14:33:28 +0000 (UTC) Date: Mon, 15 Dec 2014 14:33:28 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-stable@freebsd.org Message-ID: <1572101424.31.1418654008013.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <657535456.30.1418647176076.JavaMail.jenkins@jenkins-9.freebsd.org> References: <657535456.30.1418647176076.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : Build-UFS-image #672 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: Build-UFS-image X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 14:33:29 -0000 See From owner-freebsd-stable@FreeBSD.ORG Mon Dec 15 15:34: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 C1C5CB50 for ; Mon, 15 Dec 2014 15:34:43 +0000 (UTC) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::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 86FEBD56 for ; Mon, 15 Dec 2014 15:34:43 +0000 (UTC) Received: by mail-oi0-f44.google.com with SMTP id e131so8284703oig.31 for ; Mon, 15 Dec 2014 07:34:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=L3b21r0GXg9uLQouvWBn8Jtm2rUjbzlyMpZd5tqz6ik=; b=anpCz6pVfFIdZk3jNxCFbqhBSeDnFEaJPgS8PKNq7DaLk5cJjOmZ/mc3DvebReXvyc DnAMvcdG7VK+4m3bO+HdXtTwsqK0PJd53OIseTZUkcnVHT7FcnP7ggaatPxc5Qtw+wDl nrfn9mtWVwswJbNw5BHrOK7EYy6EigO84aC8ggRVipfxPUTd5uQoK7XslOB4MO0PhQI9 wdiMKzTGwbX+tWXVakeKgX/+rYFQTHTWBFac8VnDCJK1guksao46q/9OpAOIrYXZSmk5 qi5snuk50LOxBHSV46om34k5UkOVC0jEmlASvCNXb4BGzs20gETlc6+deMNHMrYglE28 neBA== MIME-Version: 1.0 X-Received: by 10.60.150.194 with SMTP id uk2mr19359308oeb.37.1418657682713; Mon, 15 Dec 2014 07:34:42 -0800 (PST) Received: by 10.202.0.67 with HTTP; Mon, 15 Dec 2014 07:34:42 -0800 (PST) Date: Mon, 15 Dec 2014 12:34:42 -0300 Message-ID: Subject: Mounting swap partition From: Net Warrior To: FreeBSD Stable List Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 15:34:43 -0000 Hi there guys It's beeen a long time since I do not use FreeBSD, sice 9-RELEASE, now I back on the road and I found lots of cools stuff and thing which I'm trying to assimilate, now I have a simple problem which I cannot solve, cannot activate swap partition, can you lend me a hand with this? root@:~ # gpart show => 34 83886013 diskid/DISK-VB7030ac45-d4933b52 GPT (40G) 34 1024 1 freebsd-boot (512K) 1058 4194304 2 freebsd-swap (2.0G) 4195362 79690685 3 freebsd-zfs (38G) root@:~ # swapinfo Device 1K-blocks Used Avail Capacity root@:~ # swapon -a swapon: /dev/ada0p2: No such file or directory Best regards From owner-freebsd-stable@FreeBSD.ORG Mon Dec 15 16:08: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 5C3B3EF for ; Mon, 15 Dec 2014 16:08:56 +0000 (UTC) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (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 E4818AF for ; Mon, 15 Dec 2014 16:08:55 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id y19so14935454wgg.21 for ; Mon, 15 Dec 2014 08:08:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=L/L1IvTOoS2hu2UHAFIO2jXsF1DhZjmV+m7RpEfDXM0=; b=UpDafqkZ1RIl6MSP88paRts5Z1fa5gBHUd9bXiIyduoBPTFPg429AtgQIqqn8sU4mR i89ZZuFITFXn20HqyUtIWAJRTi/O8sCvcsQeDXKRKQWtWEtYoFb4ytUHJYOK66SlBQHv lmqBoRdcCjFSIXX+B2+9FSAJeGXvZwX/UND90K2jQfQY2d+BOz0J+m3apLbCZe7IodAr rrK/eJdmeqQ0aLJwCGgpELaVwHfdaixq5YJoJdVVkk1PLhMBwtuEI9q43Xt8EwfrBzws uIBNFByEN0szkxCP+T4jfJnlYM0Es0+ZYhfuNUJBNBY+q/JZsNgE/vKX5AiJQI3oqW6L C13A== X-Gm-Message-State: ALoCoQlOP9ng+arTAQtG3BjA7WirXVUhvmtwhlbML7r1tA5NKzf0ts4ynWDMR7JODZP8r+ATzMNI X-Received: by 10.180.107.198 with SMTP id he6mr33122981wib.44.1418659728053; Mon, 15 Dec 2014 08:08:48 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id l9sm13644801wic.21.2014.12.15.08.08.47 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Dec 2014 08:08:47 -0800 (PST) Message-ID: <548F071D.2000700@multiplay.co.uk> Date: Mon, 15 Dec 2014 16:06:53 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Mounting swap partition References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 16:08:56 -0000 Is your disk attached to ada0? You can check this with camcontrol e.g. camcontrol devlist camcontrol identify Personally I find diskid's more of a hindrance than a help so I disable them in /boot/loader.conf with: kern.geom.label.disk_ident.enable="0" For reference the same can be done for gpt and gptid, however gptid are more useful: kern.geom.label.gpt.enable="0" kern.geom.label.gptid.enable="0" If your using 9.x I would also recommend moving to 10.1, lots of good things in this. Regards Steve On 15/12/2014 15:34, Net Warrior wrote: > Hi there guys > It's beeen a long time since I do not use FreeBSD, sice 9-RELEASE, now I > back on the road and I found lots of cools stuff and thing which I'm trying > to assimilate, now I have a simple problem which I cannot solve, cannot > activate swap partition, can you lend me a hand with this? > > root@:~ # gpart show > => 34 83886013 diskid/DISK-VB7030ac45-d4933b52 GPT (40G) > 34 1024 1 freebsd-boot (512K) > 1058 4194304 2 freebsd-swap (2.0G) > 4195362 79690685 3 freebsd-zfs (38G) > > > root@:~ # swapinfo > Device 1K-blocks Used Avail Capacity > > root@:~ # swapon -a > swapon: /dev/ada0p2: No such file or directory > > Best regards > _______________________________________________ > 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 Mon Dec 15 16:17: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 B47B14F7 for ; Mon, 15 Dec 2014 16:17:14 +0000 (UTC) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::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 6F1A41B8 for ; Mon, 15 Dec 2014 16:17:14 +0000 (UTC) Received: by mail-qc0-f176.google.com with SMTP id i17so8975687qcy.35 for ; Mon, 15 Dec 2014 08:17:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ywYX1hBqzF48fWC/FC8Ybw0XqWIYXbm3Mt6dQUmzPwQ=; b=cpDx4ZadAcLTiNHx5nYM8Yd3lABGacQ7R1n1uUm9dDY2Udj4bJIW1+VhsKV0f5uIFm 7IUA0zHVYfx/2A6qWmDopRvibCmj51qY6/rdJwPrUeBC1kcodqu1T8j7rfJhMDmRrePO WIR+JWsUXvbqYturWkg5x1de5HWJpMpRsgAHUnYiy3udwK6YtwcRsVlnKK/Z5/4/Z+31 HZ/yns4TNUGCO70ILD4EbgdR3wKvi56Z0DG7nifoHzLQyUjyZJkat4LKFwnNz08LrQCv UTy0gYRD48Feu6ntLQdyIvCxvK7STwYyYKtWMWe9WY8P2ZXSrDyFmqecGPpBGF7mRXO+ 1gfQ== X-Received: by 10.224.137.131 with SMTP id w3mr5807298qat.95.1418660233484; Mon, 15 Dec 2014 08:17:13 -0800 (PST) Received: from [192.168.0.102] ([181.47.206.199]) by mx.google.com with ESMTPSA id s32sm10890407qge.23.2014.12.15.08.17.12 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Dec 2014 08:17:13 -0800 (PST) Message-ID: <548F0986.1070803@gmail.com> Date: Mon, 15 Dec 2014 13:17:10 -0300 From: Net Warrior User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Mounting swap partition References: <548F071D.2000700@multiplay.co.uk> In-Reply-To: <548F071D.2000700@multiplay.co.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 16:17:14 -0000 Hi Steve Sorry, I should have provide much more info, this is 10.1 REL on a Vbox VM this is the output FreeBSD 10.1-RELEASE FreeBSD 10.1-RELEASE #0 r274401: Tue Nov 11 21:02:49 UTC 2014 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 camcontrol devlist at scbus0 target 0 lun 0 (ada0,pass0) ass0: ATA-6 device pass0: 33.300MB/s transfers (UDMA2, PIO 65536bytes) protocol ATA/ATAPI-6 device model VBOX HARDDISK firmware revision 1.0 serial number VB7030ac45-d4933b52 cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 83886080 sectors LBA48 not supported PIO supported PIO4 w/o IORDY DMA supported WDMA2 UDMA6 Feature Support Enabled Value Vendor read ahead yes yes write cache yes yes flush cache yes yes overlap no Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) no NCQ Queue Management no NCQ Streaming no Receive & Send FPDMA Queued no SMART no no microcode download no no security no no power management yes yes advanced power management no no automatic acoustic management no no media status notification no no power-up in Standby no no write-read-verify no no unload no no general purpose logging no no free-fall no no Data Set Management (DSM/TRIM) no Host Protected Area (HPA) no Thanks for your time and support Regards On 12/15/2014 01:06 PM, Steven Hartland wrote: > Is your disk attached to ada0? > > You can check this with camcontrol e.g. > camcontrol devlist > camcontrol identify > > Personally I find diskid's more of a hindrance than a help so I > disable them in /boot/loader.conf with: > kern.geom.label.disk_ident.enable="0" > > For reference the same can be done for gpt and gptid, however gptid > are more useful: > kern.geom.label.gpt.enable="0" > kern.geom.label.gptid.enable="0" > > If your using 9.x I would also recommend moving to 10.1, lots of good > things in this. > > Regards > Steve > > On 15/12/2014 15:34, Net Warrior wrote: >> Hi there guys >> It's beeen a long time since I do not use FreeBSD, sice 9-RELEASE, now I >> back on the road and I found lots of cools stuff and thing which I'm >> trying >> to assimilate, now I have a simple problem which I cannot solve, cannot >> activate swap partition, can you lend me a hand with this? >> >> root@:~ # gpart show >> => 34 83886013 diskid/DISK-VB7030ac45-d4933b52 GPT (40G) >> 34 1024 1 freebsd-boot >> (512K) >> 1058 4194304 2 freebsd-swap >> (2.0G) >> 4195362 79690685 3 freebsd-zfs >> (38G) >> >> >> root@:~ # swapinfo >> Device 1K-blocks Used Avail Capacity >> >> root@:~ # swapon -a >> swapon: /dev/ada0p2: No such file or directory >> >> Best regards >> _______________________________________________ >> 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" > > _______________________________________________ > 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 Mon Dec 15 16:50:43 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 13A68AD5 for ; Mon, 15 Dec 2014 16:50:43 +0000 (UTC) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d: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 C605079C for ; Mon, 15 Dec 2014 16:50:42 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id j7so947033qaq.3 for ; Mon, 15 Dec 2014 08:50:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=L6wwWqfTdU8H5MBmHtx9SKsIHoXh+trr+qK+qBfGOkA=; b=F9WEb7zgTayaerfepJCGRsVFWCcaCVuZ0xvsrX/BBi0/YGMEAOnr8zqSsU4FpDHiS2 mI8UhLe5cQGMBtj+6U41iC6lh3EC6o+oCutXzEBTvXmpkeDWfHFsJAn6lZ9DMuuA9BCE fpnVCOYFgz20HXY1ect4ruXclm+ZcvrIO0YwX9d9+LN2vIQ65IOjAQpSKlpUkcot/Qbi Cmr2LKNeKHRM0T++neyZbNzPLewt6bhxdGk5aDNwVF2C6YeIt2bS3Xh1027AWte5D2dG Zp4if8zz+yjY3e1QbdXfg+ILAHR7BO23hGOZSt2N2TDnNhjTQNcXRFUsfAmudD9TYzbR 9Hbg== X-Received: by 10.224.54.203 with SMTP id r11mr57647002qag.62.1418662241772; Mon, 15 Dec 2014 08:50:41 -0800 (PST) Received: from [192.168.0.102] ([181.47.206.199]) by mx.google.com with ESMTPSA id l10sm10990631qas.25.2014.12.15.08.50.40 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Dec 2014 08:50:41 -0800 (PST) Message-ID: <548F115D.3080609@gmail.com> Date: Mon, 15 Dec 2014 13:50:37 -0300 From: Net Warrior User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Mounting swap partition References: <548F071D.2000700@multiplay.co.uk> In-Reply-To: <548F071D.2000700@multiplay.co.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 16:50:43 -0000 Hi Steve After disabling gpt and gptid at boot the swap is back root@:~ # swapinfo Device 1K-blocks Used Avail Capacity /dev/ada0p2 2097152 0 2097152 0% Thank you very much. On 12/15/2014 01:06 PM, Steven Hartland wrote: > Is your disk attached to ada0? > > You can check this with camcontrol e.g. > camcontrol devlist > camcontrol identify > > Personally I find diskid's more of a hindrance than a help so I > disable them in /boot/loader.conf with: > kern.geom.label.disk_ident.enable="0" > > For reference the same can be done for gpt and gptid, however gptid > are more useful: > kern.geom.label.gpt.enable="0" > kern.geom.label.gptid.enable="0" > > If your using 9.x I would also recommend moving to 10.1, lots of good > things in this. > > Regards > Steve > > On 15/12/2014 15:34, Net Warrior wrote: >> Hi there guys >> It's beeen a long time since I do not use FreeBSD, sice 9-RELEASE, now I >> back on the road and I found lots of cools stuff and thing which I'm >> trying >> to assimilate, now I have a simple problem which I cannot solve, cannot >> activate swap partition, can you lend me a hand with this? >> >> root@:~ # gpart show >> => 34 83886013 diskid/DISK-VB7030ac45-d4933b52 GPT (40G) >> 34 1024 1 freebsd-boot >> (512K) >> 1058 4194304 2 freebsd-swap >> (2.0G) >> 4195362 79690685 3 freebsd-zfs >> (38G) >> >> >> root@:~ # swapinfo >> Device 1K-blocks Used Avail Capacity >> >> root@:~ # swapon -a >> swapon: /dev/ada0p2: No such file or directory >> >> Best regards >> _______________________________________________ >> 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" > > _______________________________________________ > 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 Mon Dec 15 21:15:37 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 CC1EC7D9 for ; Mon, 15 Dec 2014 21:15:37 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::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 5E214B57 for ; Mon, 15 Dec 2014 21:15:37 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id B355316A405 for ; Mon, 15 Dec 2014 22:15:33 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwkUHlRI4qI0; Mon, 15 Dec 2014 22:15:14 +0100 (CET) Received: from [192.168.10.9] (vaio [192.168.10.9]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 3304516A402 for ; Mon, 15 Dec 2014 22:15:14 +0100 (CET) Message-ID: <548F4F62.4020308@digiware.nl> Date: Mon, 15 Dec 2014 22:15:14 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "ports@freebsd.org" Subject: I do not quite understand why a BIND upgrade needs to touch soo much. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 21:15:38 -0000 Hi, I'm trying get going in the new flow of pkg and poudriere. So I'm building my packages with poudriere and using pkg (1.4.0) to upgrade bind. With the sort of shocking result: ====================== Installed packages to be REMOVED: gettext-0.18.3.1_1 elm-2.5.8_2 libexif-0.6.21 neon29-0.29.6_4 rrdtool-1.4.8_4 glib~pkg-renamed~E6E1-2.36.3_4 LPRng-3.8.C_2,1 gnome-mime-data-2.18.0_4 libzvbi-0.2.34 vcdimager-0.7.24_1 flex-2.5.37_1 bison-2.7.1,1 gnutls-3.2.19_1 git-2.1.2 texi2html-5.0_1,1 p5-Locale-gettext-1.05_3 help2man-1.43.3_1 yasm-1.2.0 binutils-2.24_1 gmake-4.1 sudo-1.8.11.p1 New packages to be INSTALLED: gettext-runtime: 0.19.3 glib: 2.42.1 docbook: 1.5 pinentry: 0.9.0 npth: 1.1 Installed packages to be UPGRADED: bind99: 9.9.6 -> 9.9.6P1 gtk-update-icon-cache: 2.24.22 -> 2.24.25 gtk2: 2.24.22_4 -> 2.24.25_1 pango: 1.34.1_7 -> 1.36.8 python27: 2.7.8_5 -> 2.7.8_6 gobject-introspection: 1.36.0_3 -> 1.42.0 gdk-pixbuf2: 2.28.2_1 -> 2.31.2 gconf2: 2.32.0_6 -> 3.2.6_2 dconf: 0.14.1_1 -> 0.22.0 atk: 2.8.0_1 -> 2.14.0 gnupg: 2.0.26_1 -> 2.1.0_1 bash: 4.3.30 -> 4.3.30_1 getopt: 1.1.5 -> 1.1.6 Installed packages to be REINSTALLED: subversion-1.8.10_3 (options changed) gdbm-1.11_2 (options changed) popt-1.16_1 (direct dependency changed) gstreamer-plugins-0.10.36_4,3 (direct dependency changed) libIDL-0.8.14_2 (direct dependency changed) ORBit2-2.14.19_1 (direct dependency changed) polkit-0.105_3 (direct dependency changed) dbus-glib-0.100.2_1 (direct dependency changed) shared-mime-info-1.1_1 (direct dependency changed) libidn-1.29 (options changed) libgpg-error-1.17 (options changed) The operation will free 112 MB. 23 MB to be downloaded. ====================== I can "respect" the fact that some things need to be upgraded as a side-effect, eg. ue to lib upgrades. But why reinstall subversion which for me as user is an edge package (nothing depends on it), and not reinstall rrdtools, which has other dependancies (cacti). So just going 'yes' by default leaves me with broken packages. Or having to capture the list of removed packages and start adding that by hand. Which in the end sort of boils down into doing full-fledged 'pkg upgrade', and giving me all new packages, with lots of possibilities of broken services due to the upgrades. Requiring me to checkout all services and stuff that I have on this server. As an alternative portupgrade bind99 does the job with minimal invasive surgery. But then I'm back to maintaining every package on every server just by itself. --WjW From owner-freebsd-stable@FreeBSD.ORG Mon Dec 15 21:20:49 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 ABA95A2B for ; Mon, 15 Dec 2014 21:20:49 +0000 (UTC) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::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 3BE69BC1 for ; Mon, 15 Dec 2014 21:20:49 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id a1so15682894wgh.23 for ; Mon, 15 Dec 2014 13:20:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WZekCeOB8sYyMzNLN3o9i0kY6YM3SgoPloReYHswjpc=; b=W+aRdifGa+VEfsUNS1Wm6JwTNNP1cda1k5WqZ+c5BB397c/j5iQGLuh0bP0ynSPTB4 +56cughEtSrfyA05F1/3k6VeaBPCKlqiC9MKS+Pcrvu02yhMpsmovoX+Oy3qo3ZJlUyw vGlG01BFvvqNvzc4WtZCURlrEqd5YtMsam8ux2o0RQh2Zu6+4K7QC7iOl7RH036+8bV7 gIbvAlYZPSfm+9qyAjtGemH7vY2pA42Ya4ZYQEF7JzEx9REnYEi9LMKjj9+DT9UyB1uw CR785IZzo88gF/01sdffRqFBUnc9bpKeR9e/6IM3ZYJkMNhS68k2sJ5v6eWLo+S0YpoW Yc0Q== MIME-Version: 1.0 X-Received: by 10.194.193.2 with SMTP id hk2mr54137996wjc.40.1418678447624; Mon, 15 Dec 2014 13:20:47 -0800 (PST) Received: by 10.216.186.137 with HTTP; Mon, 15 Dec 2014 13:20:47 -0800 (PST) In-Reply-To: <548F4F62.4020308@digiware.nl> References: <548F4F62.4020308@digiware.nl> Date: Mon, 15 Dec 2014 16:20:47 -0500 Message-ID: Subject: Re: I do not quite understand why a BIND upgrade needs to touch soo much. From: Brandon Allbery To: Willem Jan Withagen Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "ports@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, 15 Dec 2014 21:20:49 -0000 On Mon, Dec 15, 2014 at 4:15 PM, Willem Jan Withagen wrote: > > So I'm building my packages with poudriere and using pkg (1.4.0) > to upgrade bind. With the sort of shocking result: > ====================== > Installed packages to be REMOVED: > gettext-0.18.3.1_1 > That first one is the key. Bind depends on gettext --- as does pretty much every other package in existence --- and gettext underwent a massive breaking change, which is kinda deranging everything else. The recent /usr/ports/UPDATING entry for gettext has the gory details. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net From owner-freebsd-stable@FreeBSD.ORG Mon Dec 15 21:26:28 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 1800FD4A for ; Mon, 15 Dec 2014 21:26:28 +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 9BED6CA8 for ; Mon, 15 Dec 2014 21:26:27 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id bs8so11838047wib.5 for ; Mon, 15 Dec 2014 13:26:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pzgggdO8OcXNuV2S24cPGACtyQkbNsi8661DxeL6bnA=; b=JN9SByWQnkF6zeZmnWnrU3Ug/75HMRf1Z5z3b0iPB0vz0qU7YDuppl9gxQaQeUgrR/ EhnFTUZM1aXfctIEggcYbUn42aoV8Rpw4ZPV68jVeUoxQhw0iVcnJDelJSw7cQ/2Xqqw cgnyhuVx39UBVdU+UFLR27IQbkkmmzq4PhR5VCDqjUTbEd8l8wFr97CpsXPTMlIrDOh5 KRwmYBd3Zq4/g9IgjftAGz9kJqVvkKoPtcqKyLThblIbIXdoHXsSGAmXmftWAWyQ4pox tJy6QCvS06O2Y4/uuD8LqgBGww+boZh+IEutKP3nvNB29XhRCov4LuAk7y+A/vcj2ZaA Go+g== MIME-Version: 1.0 X-Received: by 10.194.79.199 with SMTP id l7mr56469817wjx.136.1418678786043; Mon, 15 Dec 2014 13:26:26 -0800 (PST) Received: by 10.216.186.137 with HTTP; Mon, 15 Dec 2014 13:26:25 -0800 (PST) In-Reply-To: References: <548F4F62.4020308@digiware.nl> Date: Mon, 15 Dec 2014 16:26:25 -0500 Message-ID: Subject: Re: I do not quite understand why a BIND upgrade needs to touch soo much. From: Brandon Allbery To: Willem Jan Withagen Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "ports@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, 15 Dec 2014 21:26:28 -0000 On Mon, Dec 15, 2014 at 4:20 PM, Brandon Allbery wrote: > > On Mon, Dec 15, 2014 at 4:15 PM, Willem Jan Withagen > wrote: >> >> So I'm building my packages with poudriere and using pkg (1.4.0) >> to upgrade bind. With the sort of shocking result: >> ====================== >> Installed packages to be REMOVED: >> gettext-0.18.3.1_1 >> > > That first one is the key. Bind depends on gettext --- as does pretty much > every other package in existence --- and gettext underwent a massive > breaking change, which is kinda deranging everything else. The recent > /usr/ports/UPDATING entry for gettext has the gory details. > To explain a bit further: this time, your portupgrade would do a lot of extra work as well. bind is not self-contained; it has dependencies, some of which are shared by other packages. If you want your bind update to be self-contained then you'll need to make your own port and package from it containing its own gettext, so you can upgrade that one package without breaking every other package that depends on gettext. Otherwise, you just have to accept that a package other than bind, which bind and just about everything else depends on, *also* changed; and you can't just upgrade bind without upgrading gettext *and* either upgrading or removing the other packages that depend on the old gettext. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net From owner-freebsd-stable@FreeBSD.ORG Mon Dec 15 22:11:08 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 8C7FFA5D for ; Mon, 15 Dec 2014 22:11:08 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::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 43C4A156 for ; Mon, 15 Dec 2014 22:11:08 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 3F2E116A402; Mon, 15 Dec 2014 23:11:05 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTmm58agsyOg; Mon, 15 Dec 2014 23:10:55 +0100 (CET) Received: from [192.168.10.9] (vaio [192.168.10.9]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id C232816A407; Mon, 15 Dec 2014 23:10:55 +0100 (CET) Message-ID: <548F5C6F.7040309@digiware.nl> Date: Mon, 15 Dec 2014 23:10:55 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brandon Allbery Subject: Re: I do not quite understand why a BIND upgrade needs to touch soo much. References: <548F4F62.4020308@digiware.nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ports@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, 15 Dec 2014 22:11:08 -0000 On 15-12-2014 22:26, Brandon Allbery wrote: > On Mon, Dec 15, 2014 at 4:20 PM, Brandon Allbery > wrote: >> >> On Mon, Dec 15, 2014 at 4:15 PM, Willem Jan Withagen >> wrote: >>> >>> So I'm building my packages with poudriere and using pkg (1.4.0) >>> to upgrade bind. With the sort of shocking result: >>> ====================== >>> Installed packages to be REMOVED: >>> gettext-0.18.3.1_1 >>> >> >> That first one is the key. Bind depends on gettext --- as does pretty much >> every other package in existence --- and gettext underwent a massive >> breaking change, which is kinda deranging everything else. The recent >> /usr/ports/UPDATING entry for gettext has the gory details. >> > > To explain a bit further: this time, your portupgrade would do a lot of > extra work as well. bind is not self-contained; it has dependencies, some > of which are shared by other packages. If you want your bind update to be > self-contained then you'll need to make your own port and package from it > containing its own gettext, so you can upgrade that one package without > breaking every other package that depends on gettext. Otherwise, you just > have to accept that a package other than bind, which bind and just about > everything else depends on, *also* changed; and you can't just upgrade bind > without upgrading gettext *and* either upgrading or removing the other > packages that depend on the old gettext. Yup, more than true in the ultimate case. Although 'portupgrade bind99' in this case did not require any other packages to be upgraded too. I've been hesitant in upgrading other packages with less security pressure, because of the huge list with extra's. And you are right, this change in gettext is going to bite at some point. (besides from building things with static linked libs.) Still leaves the point that 'pkg upgrade bind99' removes packages without reinstalling those. The only alternatives are: - pkg upgrade, and everything is upgraded - capture the list of deletion, and manually re-add them after the upgrade Neither solution is something I look forward too. --WjW From owner-freebsd-stable@FreeBSD.ORG Mon Dec 15 22:11:54 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 A3689B5B for ; Mon, 15 Dec 2014 22:11:54 +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 684091F9 for ; Mon, 15 Dec 2014 22:11:54 +0000 (UTC) Received: by mail-ig0-f181.google.com with SMTP id l13so6390302iga.8 for ; Mon, 15 Dec 2014 14:11:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=VoKTG2S4NI2sf+5E9tx0ZP0Z0TmIt5fX0228bO0BSiE=; b=XSx593QYfU4K0Ee1SWWbehky6P3fKazcAddLiKqlKXy+2VL7sjnTST35Hdngj9m6bi qPc74t2IU1NzUhVGqoai3DOMso4lBAfpX9JSz7Ty/sqkGgJ573N66nZ88kpBMmSbpraz 9ANs07V1YCu6Owevr3n7pDO0RK1dd26xvj7IbY2l/Zngs1GKe/I1FqM8J388w12kHjgm Sb1kczq0JWIjTZsOz4nhjCKqRl1FbBWWvubyxO5QfNNpdJn5v3RsZ1LTAmFnbeslUnnW 0ChIIu8O+PlBF7s48PLDGIIvUKZEXpurz1GUCfxKKHoP60KrbaqvzS8cvLSouIp7R4hW 7Qwg== MIME-Version: 1.0 X-Received: by 10.50.30.202 with SMTP id u10mr20077540igh.35.1418681513870; Mon, 15 Dec 2014 14:11:53 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.107.52.19 with HTTP; Mon, 15 Dec 2014 14:11:53 -0800 (PST) In-Reply-To: <548F115D.3080609@gmail.com> References: <548F071D.2000700@multiplay.co.uk> <548F115D.3080609@gmail.com> Date: Mon, 15 Dec 2014 14:11:53 -0800 X-Google-Sender-Auth: 3_-IjlSRSNHms6kWFHKEDGvZ-4w Message-ID: Subject: Re: Mounting swap partition From: Kevin Oberman To: Net Warrior Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD-STABLE Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 22:11:54 -0000 On Mon, Dec 15, 2014 at 8:50 AM, Net Warrior wrote: > Hi Steve > After disabling gpt and gptid at boot the swap is back > > root@:~ # swapinfo > Device 1K-blocks Used Avail Capacity > /dev/ada0p2 2097152 0 2097152 0% > > Thank you very much. > While this works, I find it best to leave gpt in place and then use gpart to label all partitions (except swap which does not support it) and use glabel to label swap. Now everything is named and there should never be any confusion. You can see why I leave gpt labels enabled. Here is my fstab: # Device Mountpoint FStype Options Dump Pass# /dev/gpt/swap none swap sw 0 0 /dev/gpt/rootfs / ufs rw 1 1 /dev/gpt/tmp /tmp ufs rw 2 2 /dev/gpt/usr /usr ufs rw 2 2 /dev/gpt/var /var ufs rw 2 2 /dev/ntfs/Windows7_OS /media/Windows7_OS ntfs rw,failok,uid=9381,gid=15,norecover,noatime,windows_names,late,mountprog=/usr/local/bin/ntfs-3g 0 0 /dev/ntfs/Media /media/Media ntfs rw,failok,uid=9381,gid=15,norecover,noatime,windows_names,late,mountprog=/usr/local/bin/ntfs-3g 0 0 #/dev/acd0 /cdrom cd9660 ro,noauto 0 0 -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-stable@FreeBSD.ORG Mon Dec 15 22:18: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 D8AB6D34 for ; Mon, 15 Dec 2014 22:18:43 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 83F4E267 for ; Mon, 15 Dec 2014 22:18:43 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id sBFMIfDS008337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 15 Dec 2014 15:18:42 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id sBFMIf3j008334; Mon, 15 Dec 2014 15:18:41 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Mon, 15 Dec 2014 15:18:41 -0700 (MST) From: Warren Block To: Kevin Oberman Subject: Re: Mounting swap partition In-Reply-To: Message-ID: References: <548F071D.2000700@multiplay.co.uk> <548F115D.3080609@gmail.com> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Mon, 15 Dec 2014 15:18:42 -0700 (MST) Cc: FreeBSD-STABLE Mailing List , Net Warrior 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, 15 Dec 2014 22:18:43 -0000 On Mon, 15 Dec 2014, Kevin Oberman wrote: > On Mon, Dec 15, 2014 at 8:50 AM, Net Warrior > wrote: > >> Hi Steve >> After disabling gpt and gptid at boot the swap is back >> >> root@:~ # swapinfo >> Device 1K-blocks Used Avail Capacity >> /dev/ada0p2 2097152 0 2097152 0% >> >> Thank you very much. >> > > While this works, I find it best to leave gpt in place and then use gpart > to label all partitions (except swap which does not support it) Umm.... > and use glabel to label swap. GPT labels are stored in the metadata, so swap can have a GPT label just like all the other partitions. Maybe you are thinking of UFS filesystem labels? > Now everything is named and there should never be any confusion. You can > see why I leave gpt labels enabled. Here is my fstab: > # Device Mountpoint FStype Options Dump Pass# > /dev/gpt/swap none swap sw 0 0 ^^^^^^^^^^^^^^^ That is a GPT label right there. From owner-freebsd-stable@FreeBSD.ORG Mon Dec 15 22:26:20 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 9130147D for ; Mon, 15 Dec 2014 22:26:20 +0000 (UTC) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::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 205EC3A0 for ; Mon, 15 Dec 2014 22:26:20 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id n12so15764638wgh.8 for ; Mon, 15 Dec 2014 14:26:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TjIncL9TFLCTkCTq1cNV0KAT9I83mIYMfoUuX9l7YHo=; b=yIB6x1tLz/UJft20nPr5ioOTXzlDg2dSUsaY+7tChmoLSTOMUzcp5Kt6nmVtbLm4Nd 6ll0gQ6OlUM+Spvv36z2mI3gYIOlJ1pOIbQmsywRBTeC0hCx3O5Tiw+7ifHDqs1lIgwJ 2H0sdlXGGDoR9GcG9TdxgxKnHWZc1LRovSiuQGkX7gGcL0ED07OsKEWDzRSsMPzTPIac ZziZ7Bpo1zTiib3cRqTjaRVAN2yhR/rbqKKuj81AqV5pRQkmG7u88Jdx6+2VZGpnwhiC 216/KLB1QAuQD1adA4yMzJUz4J5pxUU5N8BtyuKX8Oa42P9lnkwrW/X2HTcXuSDkDTZm iUrA== MIME-Version: 1.0 X-Received: by 10.194.246.130 with SMTP id xw2mr53989745wjc.33.1418682378527; Mon, 15 Dec 2014 14:26:18 -0800 (PST) Received: by 10.216.186.137 with HTTP; Mon, 15 Dec 2014 14:26:18 -0800 (PST) In-Reply-To: <548F5C6F.7040309@digiware.nl> References: <548F4F62.4020308@digiware.nl> <548F5C6F.7040309@digiware.nl> Date: Mon, 15 Dec 2014 17:26:18 -0500 Message-ID: Subject: Re: I do not quite understand why a BIND upgrade needs to touch soo much. From: Brandon Allbery To: Willem Jan Withagen Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "ports@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, 15 Dec 2014 22:26:20 -0000 On Mon, Dec 15, 2014 at 5:10 PM, Willem Jan Withagen wrote: > > Yup, more than true in the ultimate case. > Although 'portupgrade bind99' in this case did not require any other > packages to be upgraded too. > Hm; I'd expect it to notice the new gettext and build that as well, since the new bind might depend on changes in it (it has no way of knowing that in this case it's safe). OTOH this explains some of the screw cases that portuprade used to get me into, which are why I use portmaster these days.... Still leaves the point that 'pkg upgrade bind99' removes packages > without reinstalling those. The only alternatives are: > - pkg upgrade, and everything is upgraded > - capture the list of deletion, and manually re-add them after > the upgrade > This comes of prebuilt packages. In theory, a poudriere setup could be managed so that you updated only the bind99 Makefile. If you're relying on the standard packages, or updating a poudriere ports tree without checking /usr/ports/UPDATING first, you have no way to limit the update and get a bind99 package built against the old gettext; you have little choice but to upgrade everything. Any other package manager would give you the same result. (Something like nix gives you the option of the "In theory..." above about poudriere. The *default* behavior won't differ.) -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net From owner-freebsd-stable@FreeBSD.ORG Mon Dec 15 22:57: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 A0DAABFB for ; Mon, 15 Dec 2014 22:57:38 +0000 (UTC) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5AE768DD for ; Mon, 15 Dec 2014 22:57:38 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 68CD928423 for ; Mon, 15 Dec 2014 23:49:47 +0100 (CET) Received: from illbsd.quip.test (ip-89-177-49-222.net.upcbroadband.cz [89.177.49.222]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id B081328422 for ; Mon, 15 Dec 2014 23:49:46 +0100 (CET) Message-ID: <548F658A.7030306@quip.cz> Date: Mon, 15 Dec 2014 23:49:46 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30 MIME-Version: 1.0 To: FreeBSD-STABLE Mailing List Subject: Re: Mounting swap partition References: <548F071D.2000700@multiplay.co.uk> <548F115D.3080609@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 22:57:38 -0000 Kevin Oberman wrote on 12/15/2014 23:11: > While this works, I find it best to leave gpt in place and then use gpart > to label all partitions (except swap which does not support it) and use > glabel to label swap. > Now everything is named and there should never be any confusion. Best ... and you can never attach another disk with the same labels (same naming scheme, probably your disk from another computer for recovery). Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Mon Dec 15 23:01: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 4953B288 for ; Mon, 15 Dec 2014 23:01:46 +0000 (UTC) Received: from mail-wg0-x244.google.com (mail-wg0-x244.google.com [IPv6:2a00:1450:400c:c00::244]) (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 BF1739BC for ; Mon, 15 Dec 2014 23:01:45 +0000 (UTC) Received: by mail-wg0-f68.google.com with SMTP id b13so3652416wgh.11 for ; Mon, 15 Dec 2014 15:01:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:subject:to:content-type:mime-version:reply-to :organization:date; bh=iwTVyBuwrI3MszvaH9bmTynH1nDGGa1KfpX9FPUt558=; b=Jhnpp/kD2mTHlTKlxe5vQpcEozgyNUWz5ZoOu9G6qKJiek3mpj3ttnh5VSjiE3wIn1 ckYpnWwgzw1bBzwSxF/Nneusf1NfB5l4K+obQOAHWWWEGKuLMAwSfzLL428TWCxxOwyv TS+7A5YCONmev8+Bp/EaJTJXC6cFAtz6NrynP868tqghFhjfOx8h4jHe/+PY8/Mapd+T u4qO7ca2l4+eRGI0C6+rGXLvDOZMHjAvZvnR955V5QYTKe1NwaHU83uk1Mo8Edwi+Bu+ 7YPmNnNfDhVW8VdQ48yzAoH4Sd9x65tBENHFx7pJohLkaXRggh1aNk47zIIxxHXpYzuG 7iew== X-Received: by 10.194.222.34 with SMTP id qj2mr57423092wjc.80.1418684504243; Mon, 15 Dec 2014 15:01:44 -0800 (PST) Received: from 87.68.226.188.adsl.012.net.il ([77.125.134.88]) by mx.google.com with ESMTPSA id ej10sm14908683wib.2.2014.12.15.15.01.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Dec 2014 15:01:41 -0800 (PST) Message-ID: <548f6855.aa62b40a.7c26.24d4@mx.google.com> From: "Rotem Hecht" Subject: Music composer for Tv commercials, films and video games To: "freebsd-stable" MIME-Version: 1.0 Reply-To: "info@rotemmusic.com" Organization: Rotem Hecht Date: Tue, 16 Dec 2014 01:01:42 +0200 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 23:01:46 -0000 Hello=20 =20 I hope you well =20 I am Rotem Hecht. I work as a professional music composer and sound d= esigner, I'm based in Israel and in Los Angeles, California and working with production companies all over the world. I compose original music for movies, TV commercials, video games, even= ts, corporate films and I am open to other media scenarios. My portfolio includes projects performed for Microsoft, Hershey's, Kre= -O, Hasbro, Mercedes, Audi, Nickelodeon, Hop! TV Channel and more =20 I=E2=80=99m capable of delivering high quality products at decent rate= s and in short period of time. I would like to offer you my services. Please check my portfolio on my= website www.rotemmusic.com =20 Thank You for your time. =20 All The Best , =20 Rotem Hecht Mob:+972-528-227726 rotemhecht@gmail.com Skype: rhecht1282=20 =20 Unsubscribe From owner-freebsd-stable@FreeBSD.ORG Mon Dec 15 23:05:31 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 986614F0 for ; Mon, 15 Dec 2014 23:05:31 +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 6840FA06 for ; Mon, 15 Dec 2014 23:05:31 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.9/8.14.9) with ESMTP id sBFN5SJU010941; Mon, 15 Dec 2014 18:05:28 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.9/8.14.4/Submit) id sBFN5SPp010940; Mon, 15 Dec 2014 18:05:28 -0500 (EST) (envelope-from wollman) Date: Mon, 15 Dec 2014 18:05:28 -0500 (EST) From: Garrett Wollman Message-Id: <201412152305.sBFN5SPp010940@hergotha.csail.mit.edu> To: allbery.b@gmail.com Subject: Re: I do not quite understand why a BIND upgrade needs to touch soo much. References: <548F4F62.4020308@digiware.nl> <548F5C6F.7040309@digiware.nl> Organization: none X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Mon, 15 Dec 2014 18:05:28 -0500 (EST) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on hergotha.csail.mit.edu 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: Mon, 15 Dec 2014 23:05:31 -0000 In article , allbery.b@gmail.com writes: >On Mon, Dec 15, 2014 at 5:10 PM, Willem Jan Withagen >wrote: >> >> Yup, more than true in the ultimate case. >> Although 'portupgrade bind99' in this case did not require any other >> packages to be upgraded too. >> > >Hm; I'd expect it to notice the new gettext and build that as well, since >the new bind might depend on changes in it (it has no way of knowing that >in this case it's safe). No, portupgrade has no concern over whether there's a new gettext unless you tell it to upgrade dependencies recursively -- it doesn't look at the gettext port at all otherwise. The dependencies in ports are on the files that are installed (usually shared libraries or pkgconf data files): if the required files already exist, the ports framework doesn't look at the dependency. (If the required files hadn't already existed, then in this case they'd probably fall afoul of CONFLICTS checking when attempting to install the dependency and the portupgrade would fail.) Most of the time this would work, but it would fail in interesting ways and leave you unsure as to whether your set of installed packages was actually self-consistent. >This comes of prebuilt packages. In theory, a poudriere setup could be >managed so that you updated only the bind99 Makefile. If you're relying on >the standard packages, or updating a poudriere ports tree without checking >/usr/ports/UPDATING first, you have no way to limit the update and get a >bind99 package built against the old gettext; you have little choice but to >upgrade everything. It's a trade-off, of course. Some other operating systems have armies of volunteers to manage old versions of packages, backporting security fixes and whatnot; in FreeBSD we have at best a brigade, not an army, and have historically chosen to always build self-consistent package sets and only support the versions supported the the upstream developers. This is sadly why a number of ISVs have gone on a "self-contained packaging" trip, so if you install commercial software, you may no longer know how many unpatched copies of the JRE (for example) (or Python or FreeType) you have sitting around buried in some application's directory tree. That said, I do think there's a bug in pkg 1.4's dependency solver. I upgraded my home workstation over the weekend, and it wanted to uninstall a number of packages[1] that did not have any plausible connection to the things that changed. After allowing the upgrade to complete, I reinstalled the uninstalled packages with no issues. -GAWollman [1] inkscape was one; I don't recall the others. From owner-freebsd-stable@FreeBSD.ORG Mon Dec 15 23:12:05 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 59AFD771 for ; Mon, 15 Dec 2014 23:12:05 +0000 (UTC) Received: from smtp.digiware.nl (smtp.digiware.nl [31.223.170.169]) (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 14943AF4 for ; Mon, 15 Dec 2014 23:12:04 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 3AEE616A402; Tue, 16 Dec 2014 00:11:56 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvK8r-Rt5Nvm; Tue, 16 Dec 2014 00:11:29 +0100 (CET) Received: from [192.168.10.9] (vaio [192.168.10.9]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 96C3C16A407; Tue, 16 Dec 2014 00:11:29 +0100 (CET) Message-ID: <548F6AA1.5000407@digiware.nl> Date: Tue, 16 Dec 2014 00:11:29 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brandon Allbery Subject: Re: I do not quite understand why a BIND upgrade needs to touch soo much. References: <548F4F62.4020308@digiware.nl> <548F5C6F.7040309@digiware.nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ports@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, 15 Dec 2014 23:12:05 -0000 On 15-12-2014 23:26, Brandon Allbery wrote: > On Mon, Dec 15, 2014 at 5:10 PM, Willem Jan Withagen > Hm; I'd expect it to notice the new gettext and build that as well, since > the new bind might depend on changes in it (it has no way of knowing that > in this case it's safe). OTOH this explains some of the screw cases that > portuprade used to get me into, which are why I use portmaster these > days.... augh, that is something to check. I've been using portinstall/upgrade for a serious time. Did have some awkward moments, but always consider them pilot-error... > Still leaves the point that 'pkg upgrade bind99' removes packages >> without reinstalling those. The only alternatives are: >> - pkg upgrade, and everything is upgraded >> - capture the list of deletion, and manually re-add them after >> the upgrade >> > > This comes of prebuilt packages. In theory, a poudriere setup could be > managed so that you updated only the bind99 Makefile. If you're relying on > the standard packages, or updating a poudriere ports tree without checking > /usr/ports/UPDATING first, you have no way to limit the update and get a > bind99 package built against the old gettext; you have little choice but to > upgrade everything. This calls for something in /etc/crontab like: ( diff -N /usr/src/UPDATING ~/tmp/UPDATING || cp /usr/src/UPDATING ~/tmp/UPDATING ) What I us to get alerted when /usr/src/UPDATING gets changed. But then still I'm afraid that just getting a poudriere package set for just only bind99 is perhaps a bit too much. > nix gives you the option of the "In theory..." above about poudriere. The > *default* behavior won't differ.) > --WjW From owner-freebsd-stable@FreeBSD.ORG Mon Dec 15 23:38: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 E040FD6E for ; Mon, 15 Dec 2014 23:38:50 +0000 (UTC) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001: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 A31C3D4C for ; Mon, 15 Dec 2014 23:38:50 +0000 (UTC) Received: by mail-ig0-f169.google.com with SMTP id hl2so6835095igb.2 for ; Mon, 15 Dec 2014 15:38:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=f9vlMp8e5v8oQvQkvB15U+A6Vm8//q3fkPjerIJNvkw=; b=T30SaheEyKo7WaBH4WAN7tXruB2TxsHO7QtFjR8TqLMRLlLcBjH993FM9ZSbgKtj65 mDf3HF23aovP3I1MRAuwHVuDCXNdGm/ApWUx80V9aTFfgqNrGkXpWpH4TQN2PeTwEd7J I+9w/+6maCuL7crltLs5sG0VnAuRXheuPMo3MwOeeUcNUI+f1/tNjfXdYCcE9X2zwlmb +iIK3QF55sFzdz9Ovfa96Ik814b3hHkWrwXg/aTuB9ypIuu5qD7BGDUKbAs4yfb11rzT YDxhDz0jofGHjsQXiL/b2NbSraL3FVLec5YpBzfdFGIl9P+ywrKVX0PgOm9V7a1IGobg AfmQ== MIME-Version: 1.0 X-Received: by 10.107.168.18 with SMTP id r18mr31554088ioe.76.1418686730089; Mon, 15 Dec 2014 15:38:50 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.107.52.19 with HTTP; Mon, 15 Dec 2014 15:38:50 -0800 (PST) In-Reply-To: <548F658A.7030306@quip.cz> References: <548F071D.2000700@multiplay.co.uk> <548F115D.3080609@gmail.com> <548F658A.7030306@quip.cz> Date: Mon, 15 Dec 2014 15:38:50 -0800 X-Google-Sender-Auth: stSCaqXG9mUB9W86SlHpSgzOMgU Message-ID: Subject: Re: Mounting swap partition From: Kevin Oberman To: Miroslav Lachman <000.fbsd@quip.cz> Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD-STABLE Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 23:38:51 -0000 On Mon, Dec 15, 2014 at 2:49 PM, Miroslav Lachman <000.fbsd@quip.cz> wrote: > Kevin Oberman wrote on 12/15/2014 23:11: > > While this works, I find it best to leave gpt in place and then use gpart >> to label all partitions (except swap which does not support it) and use >> glabel to label swap. >> Now everything is named and there should never be any confusion. >> > > Best ... and you can never attach another disk with the same labels (same > naming scheme, probably your disk from another computer for recovery). > > Miroslav Lachman > > True. I label my backup media with "bak" appended to the label. This does prevent confusing the original with the backup, but does not work with dd(1) for the entire disk. Since I don't do this for my backups, that is not an issue. And, thanks, Warren for catching my faux pas. I was remembering the old UFS labels. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-stable@FreeBSD.ORG Mon Dec 15 23:43: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 D2629C4; Mon, 15 Dec 2014 23:43:01 +0000 (UTC) Received: from smtp2.wemm.org (smtp2.wemm.org [IPv6:2001:470:67:39d::78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp2.wemm.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B484CE2D; Mon, 15 Dec 2014 23:43:01 +0000 (UTC) Received: from overcee.wemm.org (canning.wemm.org [192.203.228.65]) by smtp2.wemm.org (Postfix) with ESMTP id 4B0A0FD8; Mon, 15 Dec 2014 15:43:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=m20140428; t=1418686981; bh=XJxTKOjw6gvqgME5YBtL+JzBPVz4gNJg0XRzyoAyVtM=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=BGSBeS71VR8hjzNdmFs04YPHn7/5i4UDTfcMGk759okGk4imFu00THMi4dqGZF37r 5MyHKI5oC3FJrkJWoVVrhw7Obn/zwEY4yhnNGKTnj03yCaycipJp3voOYXeL//ydGW hx9/nZDt5TErz72bru85eXnf9JxE27Ar2CR+Vj1o= From: Peter Wemm To: freebsd-stable@freebsd.org Subject: Re: i386 PAE kernel works fine on 10-stable Date: Mon, 15 Dec 2014 15:42:56 -0800 Message-ID: <1641407.80FsgLC8bS@overcee.wemm.org> User-Agent: KMail/4.14.2 (FreeBSD/11.0-CURRENT; KDE/4.14.2; amd64; ; ) In-Reply-To: <847BD158-0867-4F5F-83A9-1651E77D29EF@mu.org> References: <1418579278.2026.9.camel@freebsd.org> <1418580756.2026.12.camel@freebsd.org> <847BD158-0867-4F5F-83A9-1651E77D29EF@mu.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5987328.3IsdAz3Yqb"; micalg="pgp-sha1"; protocol="application/pgp-signature" Cc: Alfred Perlstein , Ian Lepore 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, 15 Dec 2014 23:43:02 -0000 --nextPart5987328.3IsdAz3Yqb Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Sunday, December 14, 2014 10:53:14 AM Alfred Perlstein wrote: > On Dec 14, 2014, at 10:12 AM, Ian Lepore wrote: > > On Sun, 2014-12-14 at 10:09 -0800, Alfred Perlstein wrote: > >> On Dec 14, 2014, at 9:47 AM, Ian Lepore wrote: > >>> This is an out of the blue FYI post to let people know that despi= te all > >>> the misinformation you'll run across if you search for informatio= n on > >>> FreeBSD PAE support, it (still) works just fine. I've been using= it > >>> (for reasons related to our build system and products at $work) s= ince > >>> 2006, and I can say unequivocally that it works fine on 6.x, 8.x,= and > >>> now 10.x (and presumably on the odd-numbered releases too but I'v= e never > >>> tried those). > >>>=20 > >>> In my most recent testing with 10-stable, I found it was compatib= le with > >>> drm2 and radeonkms drivers and I was able to run Xorg and gnome j= ust > >>> fine. All my devices, and apps, and even the linuxulator worked = just > >>> fine. > >>>=20 > >>> One thing that changed somewhere between 8.4 and 10.1 is that I h= ad to > >>> add a kernel tuning option to my kernel config: > >>>=20 > >>> option KVA_PAGES=3D768=09 # Default is 512 > >>>=20 > >>> I suspect that the most frequent use of PAE is on laptops that ha= ve 4gb > >>> and the default tuning is adequate for that. My desktop machine = has > >>> 12gb and I needed to bump up that value to avoid errors related t= o being > >>> unable to create new kernel stacks. > >>=20 > >> There already is a #define that is bifurcated based on PAE in pmap= .h: > >>=20 > >> #ifndef KVA_PAGES > >> #ifdef PAE > >> #define KVA_PAGES 512 > >> #else > >> #define KVA_PAGES 256 > >> #endif > >> #endif > >>=20 > >> Do you think it will harm things to apply your suggested default t= o this > >> file?>=20 > > I would have to defer to someone who actually understands just what= that > > parm is tuning. It was purely speculation on my part that the curr= ent > > default is adequate for less memory than I have, and I don't know w= hat > > that downside might be for setting it too high. >=20 > KVA pages is the amount of pages reserved for kernel address space: >=20 > * Size of Kernel address space. This is the number of page table pa= ges > * (4MB each) to use for the kernel. 256 pages =3D=3D 1 Gigabyte. > * This **MUST** be a multiple of 4 (eg: 252, 256, 260, etc). > * For PAE, the page table page unit size is 2MB. This means that 51= 2 pages > * is 1 Gigabyte. Double everything. It must be a multiple of 8 for = PAE. >=20 > It appears that our default for PAE leaves 1GB for kernel address to = play > with? That's an interesting default. Wonder if it really makes sens= e for > PAE since the assumption is that you'll have >4GB ram in the box, wir= ing > down 1.5GB for kernel would seem to make sense=E2=80=A6 Probably mak= e sense to ask > Peter or Alan on this. It's always been a 1GB/3GB split. It was never a problem until certain= =20 scaling defaults were changed to scale solely based on physical ram wit= hout=20 regard for kva limits. With the current settings and layout of the userland address space betw= een the=20 zero-memory hole, the reservation for maxdsiz, followed by the ld-elf.s= o.1=20 space and shared libraries, there's just enough room to mmap a 2GB file= and=20 have a tiny bit of wiggle room left. With changing the kernel/user split to 1.5/2.5 then userland is more=20= restricted and is typically around the 1.8/1.9GB range. You can get a large memory PAE system to boot with default settings by=20= seriously scaling things down like kern.maxusers, mbufs limits, etc. However, we have run ref11-i386 and ref10-i386 in the cluster for 18+ m= onths=20 with a 1.5/2.5 split and even then we've run out of kva and we've hit a= few=20 pmap panics and things that appear to be fallout of bounce buffer probl= ems. While yes, you can make it work, I am personally not convinced that it = is=20 reliable. My last i386 PAE machine died earlier this year with a busted scsi back= plane=20 for the drives. It went to the great server crusher. > Also wondering how bad it would be to make these tunables, I see they= > trickle down quite a bit into the system, hopefully not defining some= > static arrays, but I haven't dived down that far. They cause extensive compile time macro expansion variations that are e= xported=20 to assembler code via genassym. KVA_PAGES is not a good candidate for = a=20 runtime tunable unless you like the pain of i386/locore.s and friends. =2D-=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI= 6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 --nextPart5987328.3IsdAz3Yqb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABAgAGBQJUj3IEAAoJEDXWlwnsgJ4EkgQIAIj+f+4YMStdhhJB3v3m9EDa 5AELMW3jIZDyiRrC4qdo7EGcc2JjVRPxROup5+8xXpfvSVZgx05nbe0jZ73letoS y0+DS2v5m1YC1f6j0t8aS3ZZmAkMpRX+ibKSiSCXEg9hGZHytBgefzDiXluOwS+3 wzLu0gSIUY10d0NzeyL7J8GjiyRFG2bkfYlkg5hhiTopXW/LKJ8qkUeBNbd8KmIG I4yLhdzGF+zvX8RX9LW44kEUAVRt48xtA9ANA4rklJQt/mU38fNfFCH8DC9obvSj pGEOCn7Y3T/hCFeOz4G40jtU4JNOJC30wV6y6RED3KYXbQvLUMzjlUa5qDVHKcA= =vGGT -----END PGP SIGNATURE----- --nextPart5987328.3IsdAz3Yqb-- From owner-freebsd-stable@FreeBSD.ORG Tue Dec 16 00:33:05 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 A9791C2D; Tue, 16 Dec 2014 00:33:05 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id 883CA3A5; Tue, 16 Dec 2014 00:33:05 +0000 (UTC) Received: from [100.121.71.237] (175.sub-70-197-5.myvzw.com [70.197.5.175]) by elvis.mu.org (Postfix) with ESMTPSA id 0ED57341F83D; Mon, 15 Dec 2014 16:33:05 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: i386 PAE kernel works fine on 10-stable From: Alfred Perlstein X-Mailer: iPhone Mail (12B440) In-Reply-To: <1641407.80FsgLC8bS@overcee.wemm.org> Date: Mon, 15 Dec 2014 16:33:04 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1418579278.2026.9.camel@freebsd.org> <1418580756.2026.12.camel@freebsd.org> <847BD158-0867-4F5F-83A9-1651E77D29EF@mu.org> <1641407.80FsgLC8bS@overcee.wemm.org> To: Peter Wemm Cc: "freebsd-stable@freebsd.org" , Ian Lepore 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, 16 Dec 2014 00:33:05 -0000 > On Dec 15, 2014, at 3:42 PM, Peter Wemm wrote: >=20 >> On Sunday, December 14, 2014 10:53:14 AM Alfred Perlstein wrote: >>> On Dec 14, 2014, at 10:12 AM, Ian Lepore wrote: >>>> On Sun, 2014-12-14 at 10:09 -0800, Alfred Perlstein wrote: >>>>> On Dec 14, 2014, at 9:47 AM, Ian Lepore wrote: >>>>> This is an out of the blue FYI post to let people know that despite al= l >>>>> the misinformation you'll run across if you search for information on >>>>> FreeBSD PAE support, it (still) works just fine. I've been using it >>>>> (for reasons related to our build system and products at $work) since >>>>> 2006, and I can say unequivocally that it works fine on 6.x, 8.x, and >>>>> now 10.x (and presumably on the odd-numbered releases too but I've nev= er >>>>> tried those). >>>>>=20 >>>>> In my most recent testing with 10-stable, I found it was compatible wi= th >>>>> drm2 and radeonkms drivers and I was able to run Xorg and gnome just >>>>> fine. All my devices, and apps, and even the linuxulator worked just >>>>> fine. >>>>>=20 >>>>> One thing that changed somewhere between 8.4 and 10.1 is that I had to= >>>>> add a kernel tuning option to my kernel config: >>>>>=20 >>>>> option KVA_PAGES=3D768 # Default is 512 >>>>>=20 >>>>> I suspect that the most frequent use of PAE is on laptops that have 4g= b >>>>> and the default tuning is adequate for that. My desktop machine has >>>>> 12gb and I needed to bump up that value to avoid errors related to bei= ng >>>>> unable to create new kernel stacks. >>>>=20 >>>> There already is a #define that is bifurcated based on PAE in pmap.h: >>>>=20 >>>> #ifndef KVA_PAGES >>>> #ifdef PAE >>>> #define KVA_PAGES 512 >>>> #else >>>> #define KVA_PAGES 256 >>>> #endif >>>> #endif >>>>=20 >>>> Do you think it will harm things to apply your suggested default to thi= s >>>> file?> >>> I would have to defer to someone who actually understands just what that= >>> parm is tuning. It was purely speculation on my part that the current >>> default is adequate for less memory than I have, and I don't know what >>> that downside might be for setting it too high. >>=20 >> KVA pages is the amount of pages reserved for kernel address space: >>=20 >> * Size of Kernel address space. This is the number of page table pages >> * (4MB each) to use for the kernel. 256 pages =3D=3D 1 Gigabyte. >> * This **MUST** be a multiple of 4 (eg: 252, 256, 260, etc). >> * For PAE, the page table page unit size is 2MB. This means that 512 pag= es >> * is 1 Gigabyte. Double everything. It must be a multiple of 8 for PAE.= >>=20 >> It appears that our default for PAE leaves 1GB for kernel address to play= >> with? That's an interesting default. Wonder if it really makes sense fo= r >> PAE since the assumption is that you'll have >4GB ram in the box, wiring >> down 1.5GB for kernel would seem to make sense=E2=80=A6 Probably make se= nse to ask >> Peter or Alan on this. >=20 > It's always been a 1GB/3GB split. It was never a problem until certain=20= > scaling defaults were changed to scale solely based on physical ram withou= t=20 > regard for kva limits. Hmm the original patch I gave for that only changed scaling for machines wit= h 64 bit pointers. Why was it that the 32 bit stuff was made to change? >=20 > With the current settings and layout of the userland address space between= the=20 > zero-memory hole, the reservation for maxdsiz, followed by the ld-elf.so.1= =20 > space and shared libraries, there's just enough room to mmap a 2GB file an= d=20 > have a tiny bit of wiggle room left. >=20 > With changing the kernel/user split to 1.5/2.5 then userland is more=20 > restricted and is typically around the 1.8/1.9GB range. >=20 > You can get a large memory PAE system to boot with default settings by=20 > seriously scaling things down like kern.maxusers, mbufs limits, etc. >=20 > However, we have run ref11-i386 and ref10-i386 in the cluster for 18+ mont= hs=20 > with a 1.5/2.5 split and even then we've run out of kva and we've hit a fe= w=20 > pmap panics and things that appear to be fallout of bounce buffer problems= . >=20 > While yes, you can make it work, I am personally not convinced that it is=20= > reliable. >=20 > My last i386 PAE machine died earlier this year with a busted scsi backpla= ne=20 > for the drives. It went to the great server crusher. Oh I made dumb assumption that pae was 4/4 basically not split. Ok thanks.=20= >=20 >> Also wondering how bad it would be to make these tunables, I see they >> trickle down quite a bit into the system, hopefully not defining some >> static arrays, but I haven't dived down that far. >=20 > They cause extensive compile time macro expansion variations that are expo= rted=20 > to assembler code via genassym. KVA_PAGES is not a good candidate for a=20= > runtime tunable unless you like the pain of i386/locore.s and friends. Ouch. Ok.=20 -Alfred.=20= From owner-freebsd-stable@FreeBSD.ORG Tue Dec 16 01:12:41 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 C8368273; Tue, 16 Dec 2014 01:12:41 +0000 (UTC) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::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 582DA9CB; Tue, 16 Dec 2014 01:12:41 +0000 (UTC) Received: by mail-wg0-f54.google.com with SMTP id l2so16164948wgh.41 for ; Mon, 15 Dec 2014 17:12:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=MDiCc1Ttz4v3WAsY8kL0n+vY5wRyfuuVItMy+1vvaF4=; b=evp5+et1ex8OTpu4lud1rI4E4oodTJZsDrnQ59t1U1uLhk0hSqSSYXbL2xhx3tTF8t xGHEyrOXYxa1kgzBB5EmHbV7M/5550Fxk3zK3H6C3bob0FYynBY+NAqfvWDznd+DvuRV sea1SMRcL2yBagpr3am3kMQkn93sO4VIqlHzgk7Kb9NPI9kEg2cBQfb6O7KUDW41xv/A IU7SqkNjwpLCvPcsoRrpS+hLOqCe4eOu4QtDk9+mDc77uVg65jhc+ALOI66XKGlbZfzX JCdGTsypHs0lx24mYzIT/seDGtBjq/VHUgCCKXoGf81PEThigjDLCXdUgwlxjrsfa7Yt zn/g== MIME-Version: 1.0 X-Received: by 10.180.80.133 with SMTP id r5mr255604wix.20.1418692359818; Mon, 15 Dec 2014 17:12:39 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.195 with HTTP; Mon, 15 Dec 2014 17:12:39 -0800 (PST) In-Reply-To: References: <1418579278.2026.9.camel@freebsd.org> <1418580756.2026.12.camel@freebsd.org> <847BD158-0867-4F5F-83A9-1651E77D29EF@mu.org> <1641407.80FsgLC8bS@overcee.wemm.org> Date: Mon, 15 Dec 2014 17:12:39 -0800 X-Google-Sender-Auth: 2pEo62JITqwpPFOAN-jEyq4r4Mk Message-ID: Subject: Re: i386 PAE kernel works fine on 10-stable From: Adrian Chadd To: Alfred Perlstein Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-stable@freebsd.org" , Ian Lepore , Peter Wemm 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, 16 Dec 2014 01:12:41 -0000 On 15 December 2014 at 16:33, Alfred Perlstein wrote: > >> On Dec 15, 2014, at 3:42 PM, Peter Wemm wrote: >> >> It's always been a 1GB/3GB split. It was never a problem until certain >> scaling defaults were changed to scale solely based on physical ram without >> regard for kva limits. > > Hmm the original patch I gave for that only changed scaling for machines with 64 bit pointers. Why was it that the 32 bit stuff was made to change? I recall this - I went digging; commit 7beb738c8a72cc197d3e898784afe3fba28f1834 removed that particular bit of autotuning based on the size of void *. Maybe this stuff is a little busted and we need to add some more config parameters? (Also, there's the vm space shift thing that also needed adjustment for memory-constrained systems. We've had do it on MIPS and low-memory (64mb, 128mb) RAM i386 systems.) -adrian From owner-freebsd-stable@FreeBSD.ORG Tue Dec 16 04:24:43 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 F00F086A for ; Tue, 16 Dec 2014 04:24:43 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BE5D0E83 for ; Tue, 16 Dec 2014 04:24:43 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sBG4OvVH073434; Mon, 15 Dec 2014 20:24:57 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: freebsd-stable@freebsd.org, In-Reply-To: <20141215.082038.41648681.sthaug@nethelp.no> References: <20131203.223612.74719903.sthaug@nethelp.no>, <20141215.082038.41648681.sthaug@nethelp.no> From: "Chris H" Subject: Re: BIND chroot environment in 10-RELEASE...gone? Date: Mon, 15 Dec 2014 20:24:58 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: 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: Tue, 16 Dec 2014 04:24:44 -0000 On Mon, 15 Dec 2014 08:20:38 +0100 (CET) sthaug@nethelp.no wrote > > > > It was a deliberate decision made by the maintainer. He said the chroot > > > > code in the installation was too complicated and would be removed as a > > > > part of the installation clean-up to get all BIND related files out of > > > > /usr and /etc. I protested at the time as did someone else, but the > > > > maintainer did not respond. I thnk this was a really, really bad > > > > decision. > > > > > > > > I searched a bit for the thread on removing BIND leftovers, but have > > > > failed to find it. > > > > > > > > > > You're probably thinking about my November 17 posting: > > > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2013-November/075895.html > > > > > > I'm glad to see others finally speaking up; I was beginning to think I > > > was the only one who thought this was not a good idea. I'm a bit > > > surprised that no one has responded yet. > > > > I agree with the protesters here. Removing chroot and symlinking logic > > in the ports is a significant disservice to FreeBSD users, and will > > make it harder to use BIND in a sensible way. A net disincentive to > > use FreeBSD :-( > > I have now installed my first 10.1 based name server. I had to spend > some hours to recreate the changeroot environment that I had so easily > available in FreeBSD up to 9.x. > > > Removing the changeroot environment and symlinking logic is a net > disservice to the FreeBSD community, and disincentive to use FreeBSD. > In all fairness (is there even such a thing?); "Convenience" is a two-way street. For each person that thinks the BIND chroot(8) mtree(8) symlink(2) was a great "service". There are at *least* as many whom feel differently. I chose to remove/disable the BIND, from BASE, some time ago. As it wasn't "convenient" to have to overcome/deal with the CVE/security issues. In the end, I was forced to re-examine some of the other resolvers, that ultimately, only proved to be better choice(s). Just sayin' --Chris > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > _______________________________________________ > 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 Tue Dec 16 06:04:18 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 88473304; Tue, 16 Dec 2014 06:04:18 +0000 (UTC) Received: from smtp2.wemm.org (smtp2.wemm.org [192.203.228.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp2.wemm.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 681ADA9B; Tue, 16 Dec 2014 06:04:18 +0000 (UTC) Received: from overcee.wemm.org (canning.wemm.org [192.203.228.65]) by smtp2.wemm.org (Postfix) with ESMTP id 3607B95; Mon, 15 Dec 2014 22:04:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=m20140428; t=1418709851; bh=NEC188nGzRgFx9eGafBT7agNqcIV0IUZgIhZ8pwY/qc=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=oLsyh1p4Q2FS08Y/wgm7eaiz23PTUb0IhnNkVa7wUDOD3OAnX9x1jJX+f3bUHMtGn dxPaIa7Z47xnjQSAv6vA89Vcx63eBiS+pYpVdII1pK1YoLfaNtR7aNwX5v8Zrmz2BA LRIK4DxhYYpLMpz3x/5QwkKTfXTb1Ktq6I20rG2E= From: Peter Wemm To: Adrian Chadd Subject: Re: i386 PAE kernel works fine on 10-stable Date: Mon, 15 Dec 2014 22:04:06 -0800 Message-ID: <2036758.o6RQzZpOtp@overcee.wemm.org> User-Agent: KMail/4.14.2 (FreeBSD/11.0-CURRENT; KDE/4.14.2; amd64; ; ) In-Reply-To: References: <1418579278.2026.9.camel@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4420963.u7c8slbCU8"; micalg="pgp-sha1"; protocol="application/pgp-signature" Cc: Alfred Perlstein , "freebsd-stable@freebsd.org" , Ian Lepore 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, 16 Dec 2014 06:04:18 -0000 --nextPart4420963.u7c8slbCU8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Monday, December 15, 2014 05:12:39 PM Adrian Chadd wrote: > On 15 December 2014 at 16:33, Alfred Perlstein wrote:= > >> On Dec 15, 2014, at 3:42 PM, Peter Wemm wrote: > >>=20 > >> It's always been a 1GB/3GB split. It was never a problem until ce= rtain > >> scaling defaults were changed to scale solely based on physical ra= m > >> without > >> regard for kva limits. > >=20 > > Hmm the original patch I gave for that only changed scaling for mac= hines > > with 64 bit pointers. Why was it that the 32 bit stuff was made to > > change? > I recall this - I went digging; commit >=20 > 7beb738c8a72cc197d3e898784afe3fba28f1834 >=20 > removed that particular bit of autotuning based on the size of void *= . >=20 > Maybe this stuff is a little busted and we need to add some more > config parameters? >=20 > (Also, there's the vm space shift thing that also needed adjustment > for memory-constrained systems. We've had do it on MIPS and low-memor= y > (64mb, 128mb) RAM i386 systems.) >=20 >=20 >=20 > -adrian There's more to it than just one commit. There's years of general tren= ds that=20 added scaling by physical ram without regard for kva consumption. The=20= starting point for Alfred's commits a few years ago already didn't work= =20 properly on large memory systems. Alfred worked on the scaling for the= 64-bit=20 / direct map systems and tried to leave the caps alone for kva-constrai= ned=20 systems. The caps were already too high. Except for i386, kva-limited systems generally are pretty small and are= =20 explicitly tuned for "small". The tuning considerations for a 32MB or = 64MB=20 mips/arm system is very different than a 16GB i386 PAE system. =2D-=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI= 6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 --nextPart4420963.u7c8slbCU8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABAgAGBQJUj8taAAoJEDXWlwnsgJ4EA/EIAItF3mNK02PQvolcgS4y9fJb kQkNUTKo7gzWTaclcTNQ90OmHmQExs9uOMD/i5EN2thTfil7YmcwlrF+cSrJPb/l 5jEBn4irS/31C59bG4LmwmEuq3QW2kQj9i6l6avZuC3mXcMpRNHYkz/8X2YdXkTn o+DFHQOzB+rGwIjl5aRoO2OZnMjdmxqtSI+OVlU7bOLMEu+TcdbcggsI/kqKHR2X iwFiSokL8Gz8fzBJjrdGCorU71xhhXbaycSK0NmJACiHvXCCXyHx2AglTGuojClg tgDQlG6GOkBK7ymhyCwTtpldWUPUnutD/D01Akjre3DY88YxakkHLQfb6EFOiMU= =iOt5 -----END PGP SIGNATURE----- --nextPart4420963.u7c8slbCU8-- From owner-freebsd-stable@FreeBSD.ORG Tue Dec 16 06:12: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 A186258A for ; Tue, 16 Dec 2014 06:12:46 +0000 (UTC) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::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 61CE1B8C for ; Tue, 16 Dec 2014 06:12:46 +0000 (UTC) Received: by mail-ig0-f180.google.com with SMTP id h15so6496879igd.1 for ; Mon, 15 Dec 2014 22:12:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=r/7cVAOXAbKhogh2ye7eTiMoekiXXYpHTym1Ouetp3M=; b=RNBNpqLD+8GiBHu3Y5GmjUoUA2OjCJBAsG/UdnUaGGQF5njH3xISkRTowONThE0gRZ dybcjnTuJvRXzbbj89H8gWif6tsOVKSR6+lNSHoVwxV7nRL1QAEMimKz0j0GQb8KEjdF ojITl6QV1T2xwSLKThB8G8v3tIL8mlDeuulH5w82cTZ/lkMm/6AsRrLDeOk2dclyBI+Y TPPagGfB/NyFwtJtG8ty9esPuxpRswTy6wedII7qcw+yUx+3PBkW0Z9YXXTZVi2xI1bU MSpBmtAZ8bjSFoy/ZqTOHJ/2vi+NXC5B7St2TpHjJRmqb3MmgjRWHLmakADpE6cMR7VY I+dw== MIME-Version: 1.0 X-Received: by 10.107.6.196 with SMTP id f65mr32460135ioi.54.1418710365848; Mon, 15 Dec 2014 22:12:45 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.107.52.19 with HTTP; Mon, 15 Dec 2014 22:12:45 -0800 (PST) In-Reply-To: References: <20131203.223612.74719903.sthaug@nethelp.no> <20141215.082038.41648681.sthaug@nethelp.no> Date: Mon, 15 Dec 2014 22:12:45 -0800 X-Google-Sender-Auth: fCpxxOW8ArUT9pjc6D1Qb1CEons Message-ID: Subject: Re: BIND chroot environment in 10-RELEASE...gone? From: Kevin Oberman To: Chris H Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD-STABLE Mailing List , "sthaug@nethelp.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: Tue, 16 Dec 2014 06:12:46 -0000 On Mon, Dec 15, 2014 at 8:24 PM, Chris H wrote: > On Mon, 15 Dec 2014 08:20:38 +0100 (CET) sthaug@nethelp.no wrote > > > > > > It was a deliberate decision made by the maintainer. He said the > chroot > > > > > code in the installation was too complicated and would be removed > as a > > > > > part of the installation clean-up to get all BIND related files > out of > > > > > /usr and /etc. I protested at the time as did someone else, but the > > > > > maintainer did not respond. I thnk this was a really, really bad > > > > > decision. > > > > > > > > > > I searched a bit for the thread on removing BIND leftovers, but > have > > > > > failed to find it. > > > > > > > > > > > > > You're probably thinking about my November 17 posting: > > > > > > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2013-November/075895.html > > > > > > > > I'm glad to see others finally speaking up; I was beginning to think > I > > > > was the only one who thought this was not a good idea. I'm a bit > > > > surprised that no one has responded yet. > > > > > > I agree with the protesters here. Removing chroot and symlinking logic > > > in the ports is a significant disservice to FreeBSD users, and will > > > make it harder to use BIND in a sensible way. A net disincentive to > > > use FreeBSD :-( > > > > I have now installed my first 10.1 based name server. I had to spend > > some hours to recreate the changeroot environment that I had so easily > > available in FreeBSD up to 9.x. > > > > > > Removing the changeroot environment and symlinking logic is a net > > disservice to the FreeBSD community, and disincentive to use FreeBSD. > > > In all fairness (is there even such a thing?); > "Convenience" is a two-way street. For each person that thinks > the BIND chroot(8) mtree(8) symlink(2) was a great "service". There > are at *least* as many whom feel differently. I chose to remove/disable > the BIND, from BASE, some time ago. As it wasn't "convenient" to have > to overcome/deal with the CVE/security issues. In the end, I was forced > to re-examine some of the other resolvers, that ultimately, only proved > to be better choice(s). > > Just sayin' > > --Chris > Please don't conflate issues. Moving BIND out of the base system is something long overdue. I know that the longtime BIND maintainer, Doug B, had long felt it should be removed. This has exactly NOTHING to do with removing the default chroot installation. The ports were, by default installed chrooted. Jailed would have been better, but it was not something that could be done in a port unless the jail had already been set up. chroot is still vastly superior to not chrooted and I was very distressed to see it go from the ports. Disclaimer, since I retired I am no longer running a DNS server, so this had no impact on me. I simply see it as an unfortunate regression. -- Kevin Oberman, Network Engineer, Retired From owner-freebsd-stable@FreeBSD.ORG Tue Dec 16 06:50:09 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 E73DBD62 for ; Tue, 16 Dec 2014 06:50:08 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B245CEA9 for ; Tue, 16 Dec 2014 06:50:08 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sBG6oOi7001116 for ; Mon, 15 Dec 2014 22:50:24 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: In-Reply-To: References: <20131203.223612.74719903.sthaug@nethelp.no> <20141215.082038.41648681.sthaug@nethelp.no> , From: "Chris H" Subject: Re: BIND chroot environment in 10-RELEASE...gone? Date: Mon, 15 Dec 2014 22:50:24 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <7b45af36d8b18292188ef78b427f6f52@ultimatedns.net> 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: Tue, 16 Dec 2014 06:50:09 -0000 On Mon, 15 Dec 2014 22:12:45 -0800 Kevin Oberman wrote > On Mon, Dec 15, 2014 at 8:24 PM, Chris H wrote: > > > On Mon, 15 Dec 2014 08:20:38 +0100 (CET) sthaug@nethelp.no wrote > > > > > > > > It was a deliberate decision made by the maintainer. He said the > > chroot > > > > > > code in the installation was too complicated and would be removed > > as a > > > > > > part of the installation clean-up to get all BIND related files > > out of > > > > > > /usr and /etc. I protested at the time as did someone else, but the > > > > > > maintainer did not respond. I thnk this was a really, really bad > > > > > > decision. > > > > > > > > > > > > I searched a bit for the thread on removing BIND leftovers, but > > have > > > > > > failed to find it. > > > > > > > > > > > > > > > > You're probably thinking about my November 17 posting: > > > > > > > > > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2013-November/075895.html > > > > > > > > > > I'm glad to see others finally speaking up; I was beginning to think > > I > > > > > was the only one who thought this was not a good idea. I'm a bit > > > > > surprised that no one has responded yet. > > > > > > > > I agree with the protesters here. Removing chroot and symlinking logic > > > > in the ports is a significant disservice to FreeBSD users, and will > > > > make it harder to use BIND in a sensible way. A net disincentive to > > > > use FreeBSD :-( > > > > > > I have now installed my first 10.1 based name server. I had to spend > > > some hours to recreate the changeroot environment that I had so easily > > > available in FreeBSD up to 9.x. > > > > > > > > > Removing the changeroot environment and symlinking logic is a net > > > disservice to the FreeBSD community, and disincentive to use FreeBSD. > > > > > In all fairness (is there even such a thing?); > > "Convenience" is a two-way street. For each person that thinks > > the BIND chroot(8) mtree(8) symlink(2) was a great "service". There > > are at *least* as many whom feel differently. I chose to remove/disable > > the BIND, from BASE, some time ago. As it wasn't "convenient" to have > > to overcome/deal with the CVE/security issues. In the end, I was forced > > to re-examine some of the other resolvers, that ultimately, only proved > > to be better choice(s). > > > > Just sayin' > > > > --Chris > > > > Please don't conflate issues. Moving BIND out of the base system is > something long overdue. I know that the longtime BIND maintainer, Doug B, > had long felt it should be removed. This has exactly NOTHING to do with > removing the default chroot installation. The ports were, by default > installed chrooted. Jailed would have been better, but it was not something > that could be done in a port unless the jail had already been set up. > chroot is still vastly superior to not chrooted Agreed. > and I was very distressed > to see it go from the ports. > > Disclaimer, since I retired I am no longer running a DNS server, so this > had no impact on me. I simply see it as an unfortunate regression. In the end I was forced to explore other avenues I probably wouldn't have taken the time to do (then). In the end, I was all the better for having done so. The same might also be said for chroot v. jail v {...} It wasn't my intention to "pick" on any app/policy, per se; --Chris > -- > Kevin Oberman, Network Engineer, Retired > _______________________________________________ > 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 Tue Dec 16 08:09: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 107B6643 for ; Tue, 16 Dec 2014 08:09:25 +0000 (UTC) Received: from mail.droso.net (koala.droso.dk [IPv6:2a01:4f8:a0:7163::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CC054888 for ; Tue, 16 Dec 2014 08:09:24 +0000 (UTC) Received: by mail.droso.net (Postfix, from userid 1001) id 72BD621409; Tue, 16 Dec 2014 09:09:19 +0100 (CET) Date: Tue, 16 Dec 2014 09:09:19 +0100 From: Erwin Lansing To: freebsd-stable@freebsd.org Subject: Re: I do not quite understand why a BIND upgrade needs to touch soo much. Message-ID: <20141216080919.GQ89148@droso.dk> Mail-Followup-To: freebsd-stable@freebsd.org References: <548F4F62.4020308@digiware.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <548F4F62.4020308@digiware.nl> X-Operating-System: FreeBSD/amd64 9.3-RELEASE-p5 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, 16 Dec 2014 08:09:25 -0000 Hoi Willem Jan, On Mon, Dec 15, 2014 at 10:15:14PM +0100, Willem Jan Withagen wrote: > Hi, > > I'm trying get going in the new flow of pkg and poudriere. > > So I'm building my packages with poudriere and using pkg (1.4.0) > to upgrade bind. With the sort of shocking result: > ====================== > Installed packages to be REMOVED: > gettext-0.18.3.1_1 [snip] > The operation will free 112 MB. > 23 MB to be downloaded. > ====================== > > I can "respect" the fact that some things need to be upgraded as a > side-effect, eg. ue to lib upgrades. > > But why reinstall subversion which for me as user is an edge package > (nothing depends on it), and not reinstall rrdtools, which has other > dependancies (cacti). > > So just going 'yes' by default leaves me with broken packages. > Or having to capture the list of removed packages and start adding that > by hand. Which in the end sort of boils down into doing full-fledged > 'pkg upgrade', and giving me all new packages, with lots of > possibilities of broken services due to the upgrades. Requiring me to > checkout all services and stuff that I have on this server. > > As an alternative > portupgrade bind99 > does the job with minimal invasive surgery. > But then I'm back to maintaining every package on every server just by > itself. > Maybe the quarterly branches are more for your type of servers? They only get security updates, like the bind one here, but not the newest developments, like the gettext changes. Of course, this still postpones the gettext update until the next quarter, but at least that change will have seen its teething pains ironed out. http://blogs.freebsdish.org/portmgr/2014/04/02/ports-2014q2-branched/ http://blogs.freebsdish.org/portmgr/2014/07/01/2014q3-branched/ Erwin -- Erwin Lansing http://droso.dk erwin@FreeBSD.org http:// www.FreeBSD.org From owner-freebsd-stable@FreeBSD.ORG Tue Dec 16 09:17: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 B28E74A4 for ; Tue, 16 Dec 2014 09:17:56 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 27EFEF84 for ; Tue, 16 Dec 2014 09:17:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id sBG9HLbu095103; Tue, 16 Dec 2014 20:17:22 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 16 Dec 2014 20:17:21 +1100 (EST) From: Ian Smith To: Kevin Oberman Subject: Re: BIND chroot environment in 10-RELEASE...gone? In-Reply-To: Message-ID: <20141216193514.K68123@sola.nimnet.asn.au> References: <20131203.223612.74719903.sthaug@nethelp.no> <20141215.082038.41648681.sthaug@nethelp.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Warren Block , FreeBSD-STABLE Mailing List , "sthaug@nethelp.no" , Chris H 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, 16 Dec 2014 09:17:56 -0000 On Mon, 15 Dec 2014 22:12:45 -0800, Kevin Oberman wrote: > On Mon, Dec 15, 2014 at 8:24 PM, Chris H wrote: > > > On Mon, 15 Dec 2014 08:20:38 +0100 (CET) sthaug@nethelp.no wrote [..] > > > > > > Removing the changeroot environment and symlinking logic is a net > > > disservice to the FreeBSD community, and disincentive to use FreeBSD. > > > > > In all fairness (is there even such a thing?); > > "Convenience" is a two-way street. For each person that thinks > > the BIND chroot(8) mtree(8) symlink(2) was a great "service". There > > are at *least* as many whom feel differently. I chose to remove/disable > > the BIND, from BASE, some time ago. As it wasn't "convenient" to have > > to overcome/deal with the CVE/security issues. In the end, I was forced > > to re-examine some of the other resolvers, that ultimately, only proved > > to be better choice(s). > > > > Just sayin' > Please don't conflate issues. Moving BIND out of the base system is > something long overdue. I know that the longtime BIND maintainer, Doug B, > had long felt it should be removed. This has exactly NOTHING to do with > removing the default chroot installation. The ports were, by default > installed chrooted. Jailed would have been better, but it was not something > that could be done in a port unless the jail had already been set up. > chroot is still vastly superior to not chrooted and I was very distressed > to see it go from the ports. > > Disclaimer, since I retired I am no longer running a DNS server, so this > had no impact on me. I simply see it as an unfortunate regression. Me too, which is why I was pleased to see Warren's excellent handbook example of setting up BIND in a jail as well catering to that need: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails-ezjail.html#jails-ezjail-example-bind That's for a caching-only local resolver, but it's hardly a long jump to extend that framework to an authoratative nameserver, BIND or otherwise. Good docs are gold, and can sometimes compensate for notsogood policy :) cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Tue Dec 16 09:23:04 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 C0F97704 for ; Tue, 16 Dec 2014 09:23:04 +0000 (UTC) Received: from mail.droso.net (koala.droso.dk [213.239.220.246]) (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 7F484A8 for ; Tue, 16 Dec 2014 09:23:03 +0000 (UTC) Received: by mail.droso.net (Postfix, from userid 1001) id DED3B22CAA; Tue, 16 Dec 2014 10:22:59 +0100 (CET) Date: Tue, 16 Dec 2014 10:22:59 +0100 From: Erwin Lansing To: freebsd-stable@freebsd.org Subject: Re: BIND chroot environment in 10-RELEASE...gone? Message-ID: <20141216092259.GF89148@droso.dk> Mail-Followup-To: freebsd-stable@freebsd.org References: <20131203.223612.74719903.sthaug@nethelp.no> <20141215.082038.41648681.sthaug@nethelp.no> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD/amd64 9.3-RELEASE-p5 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, 16 Dec 2014 09:23:04 -0000 On Mon, Dec 15, 2014 at 10:12:45PM -0800, Kevin Oberman wrote: > > Please don't conflate issues. Moving BIND out of the base system is > something long overdue. I know that the longtime BIND maintainer, Doug B, > had long felt it should be removed. This has exactly NOTHING to do with > removing the default chroot installation. The ports were, by default > installed chrooted. Jailed would have been better, but it was not something > that could be done in a port unless the jail had already been set up. > chroot is still vastly superior to not chrooted and I was very distressed > to see it go from the ports. > While I don't want to get dragged down into this discussion that can go on forever without any consensus, I just want to point out that there is a slight twist to the above description. Due to implementational details, the ports' chroot was actually inside the base system parts of BIND. Removing the one, removed the other. I did try my hand at a reimplentation self-contained in the port, but that proved less trivial than thought and I never reached a satisfactory solution. If anyone want to try their hands at it as well and convince the new port maintainer, please do so, but trust me when I say that. e.g. an ezjail solution, is much easier to set up and maintain than reverting to the old functionality. In they end, I'd rather see a more general solution that can chroot, or jail, an arbitrary daemon from ports rather than special treatment of a single port. If BIND, why not also NSD, unbound, or apache for arguments sake? Erwin -- Erwin Lansing http://droso.dk erwin@FreeBSD.org http:// www.FreeBSD.org From owner-freebsd-stable@FreeBSD.ORG Tue Dec 16 11:20:19 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 843FD49E for ; Tue, 16 Dec 2014 11:20:19 +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 426911101 for ; Tue, 16 Dec 2014 11:20:18 +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 1Y0pC6-0000QP-RN for freebsd-stable@freebsd.org; Tue, 16 Dec 2014 11:17:36 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: freebsd-stable@freebsd.org Subject: Re: I do not quite understand why a BIND upgrade needs to touch soo much. References: <548F4F62.4020308@digiware.nl> <548F5C6F.7040309@digiware.nl> <548F6AA1.5000407@digiware.nl> Date: Tue, 16 Dec 2014 11:17:29 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <548F6AA1.5000407@digiware.nl> 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: 1f72ff50073f138f9668c095d6f579a1 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, 16 Dec 2014 11:20:19 -0000 On Tue, 16 Dec 2014 00:11:29 +0100, Willem Jan Withagen wrote: > On 15-12-2014 23:26, Brandon Allbery wrote: >> On Mon, Dec 15, 2014 at 5:10 PM, Willem Jan Withagen > >> Hm; I'd expect it to notice the new gettext and build that as well, >> since >> the new bind might depend on changes in it (it has no way of knowing >> that >> in this case it's safe). OTOH this explains some of the screw cases that >> portuprade used to get me into, which are why I use portmaster these >> days.... > > augh, that is something to check. I've been using portinstall/upgrade > for a serious time. Did have some awkward moments, but always consider > them pilot-error... > >> Still leaves the point that 'pkg upgrade bind99' removes packages >>> without reinstalling those. The only alternatives are: >>> - pkg upgrade, and everything is upgraded >>> - capture the list of deletion, and manually re-add them after >>> the upgrade >>> >> >> This comes of prebuilt packages. In theory, a poudriere setup could be >> managed so that you updated only the bind99 Makefile. If you're relying >> on >> the standard packages, or updating a poudriere ports tree without >> checking >> /usr/ports/UPDATING first, you have no way to limit the update and get a >> bind99 package built against the old gettext; you have little choice >> but to >> upgrade everything. > > This calls for something in /etc/crontab like: > ( diff -N /usr/src/UPDATING ~/tmp/UPDATING || cp /usr/src/UPDATING > ~/tmp/UPDATING ) > What I us to get alerted when /usr/src/UPDATING gets changed. People can put this in their RSS reader for alerts of /usr/ports/UPDATING: http://updating.versia.com/atom/ports Or variations of http://updating.versia.com/atom/stable-10 for /usr/src/UPDATING. Regards, Ronald. From owner-freebsd-stable@FreeBSD.ORG Tue Dec 16 13:02:22 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 E634F801 for ; Tue, 16 Dec 2014 13:02:22 +0000 (UTC) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D6451DE1 for ; Tue, 16 Dec 2014 13:02:22 +0000 (UTC) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.14.9/8.14.9) with ESMTP id sBGD2BwE010222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 16 Dec 2014 14:02:11 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.14.9/8.14.9/Submit) with ESMTP id sBGD2Asu010219; Tue, 16 Dec 2014 14:02:10 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Tue, 16 Dec 2014 14:02:10 +0100 (CET) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: Willem Jan Withagen Subject: Re: I do not quite understand why a BIND upgrade needs to touch soo much. In-Reply-To: <548F5C6F.7040309@digiware.nl> Message-ID: References: <548F4F62.4020308@digiware.nl> <548F5C6F.7040309@digiware.nl> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.fig.ol.no Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "ports@freebsd.org" , Brandon Allbery 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, 16 Dec 2014 13:02:23 -0000 On Mon, 15 Dec 2014 23:10+0100, Willem Jan Withagen wrote: > On 15-12-2014 22:26, Brandon Allbery wrote: > > On Mon, Dec 15, 2014 at 4:20 PM, Brandon Allbery > > wrote: > >> > >> On Mon, Dec 15, 2014 at 4:15 PM, Willem Jan Withagen > >> wrote: > >>> > >>> So I'm building my packages with poudriere and using pkg (1.4.0) > >>> to upgrade bind. With the sort of shocking result: > >>> ====================== > >>> Installed packages to be REMOVED: > >>> gettext-0.18.3.1_1 > >>> > >> > >> That first one is the key. Bind depends on gettext --- as does pretty much > >> every other package in existence --- and gettext underwent a massive > >> breaking change, which is kinda deranging everything else. The recent > >> /usr/ports/UPDATING entry for gettext has the gory details. > >> > > > > To explain a bit further: this time, your portupgrade would do a lot of > > extra work as well. bind is not self-contained; it has dependencies, some > > of which are shared by other packages. If you want your bind update to be > > self-contained then you'll need to make your own port and package from it > > containing its own gettext, so you can upgrade that one package without > > breaking every other package that depends on gettext. Otherwise, you just > > have to accept that a package other than bind, which bind and just about > > everything else depends on, *also* changed; and you can't just upgrade bind > > without upgrading gettext *and* either upgrading or removing the other > > packages that depend on the old gettext. > > Yup, more than true in the ultimate case. > Although 'portupgrade bind99' in this case did not require any other > packages to be upgraded too. > > I've been hesitant in upgrading other packages with less security > pressure, because of the huge list with extra's. > And you are right, this change in gettext is going to bite at some > point. (besides from building things with static linked libs.) While YMMV, I use portupgrade and not pkg, and upgrading gettext was pretty much less painful than indicated by the UPDATING entry. Simply run: portupgrade -fpvo devel/gettext-runtime gettext cd /usr/ports/devel/gettext-tools && make && make install && make package && make clean cd /usr/ports/devel/gettext && make && make install && make package && make clean portupgrade -fprvx gettext -x gettext-runtime -x gettext-tools devel/gettext-runtime > Still leaves the point that 'pkg upgrade bind99' removes packages > without reinstalling those. The only alternatives are: > - pkg upgrade, and everything is upgraded > - capture the list of deletion, and manually re-add them after > the upgrade > > Neither solution is something I look forward too. > > --WjW -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-stable@FreeBSD.ORG Tue Dec 16 14:09: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 AAC0E612; Tue, 16 Dec 2014 14:09:52 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7A65578A; Tue, 16 Dec 2014 14:09:52 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sBGEA9KI090022; Tue, 16 Dec 2014 06:10:09 -0800 (PST) (envelope-from chrish@UltimateDNS.NET) To: freebsd-stable@freebsd.org, Erwin Lansing In-Reply-To: <20141216092259.GF89148@droso.dk> References: <20131203.223612.74719903.sthaug@nethelp.no> <20141215.082038.41648681.sthaug@nethelp.no> , <20141216092259.GF89148@droso.dk> From: "Chris H" Subject: Re: BIND chroot environment in 10-RELEASE...gone? Date: Tue, 16 Dec 2014 06:10:09 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <2172924ecb6a8bad66e48b4a7cc08e35@ultimatedns.net> 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: Tue, 16 Dec 2014 14:09:52 -0000 On Tue, 16 Dec 2014 10:22:59 +0100 Erwin Lansing wrote > On Mon, Dec 15, 2014 at 10:12:45PM -0800, Kevin Oberman wrote: > > > > Please don't conflate issues. Moving BIND out of the base system is > > something long overdue. I know that the longtime BIND maintainer, Doug B, > > had long felt it should be removed. This has exactly NOTHING to do with > > removing the default chroot installation. The ports were, by default > > installed chrooted. Jailed would have been better, but it was not something > > that could be done in a port unless the jail had already been set up. > > chroot is still vastly superior to not chrooted and I was very distressed > > to see it go from the ports. > > > > While I don't want to get dragged down into this discussion that can go > on forever without any consensus, I just want to point out that there is > a slight twist to the above description. Due to implementational > details, the ports' chroot was actually inside the base system parts of > BIND. Removing the one, removed the other. > > I did try my hand at a reimplentation self-contained in the port, but > that proved less trivial than thought and I never reached a satisfactory > solution. I found it to be surprisingly difficult, as well. > If anyone want to try their hands at it as well and convince > the new port maintainer, please do so, but trust me when I say that. > e.g. an ezjail solution, is much easier to set up and maintain than > reverting to the old functionality. In they end, I'd rather see a > more general solution that can chroot, or jail, an arbitrary daemon from > ports rather than special treatment of a single port. If BIND, why not > also NSD, unbound, or apache for arguments sake? Hmm. Maybe something along the lines of sysutils/ez-chroot? : Sounds like it could really be a popular port! :) --Chris > > Erwin > > -- > Erwin Lansing http://droso.dk > erwin@FreeBSD.org http:// www.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 Tue Dec 16 17:07:50 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 9E7013A3; Tue, 16 Dec 2014 17:07:50 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 58AF4D50; Tue, 16 Dec 2014 17:07:50 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4A6ADB953; Tue, 16 Dec 2014 12:07:49 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Subject: Re: Help debugging stable/10 Date: Tue, 16 Dec 2014 11:29:57 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <5488F58D.7060708@ShaneWare.Biz> In-Reply-To: <5488F58D.7060708@ShaneWare.Biz> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201412161129.57704.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 16 Dec 2014 12:07:49 -0500 (EST) Cc: Alexander Motin , hselasky@freebsd.org, mjg@freebsd.org, Shane Ambler 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, 16 Dec 2014 17:07:50 -0000 On Wednesday, December 10, 2014 8:38:21 pm Shane Ambler wrote: > Since upgrading to 10.1 (RC2) I have had trouble getting uptimes greater > than 1 day. I have little experience debugging the OS so could use some > help. > > # uname -a > FreeBSD leader.local 10.1-STABLE FreeBSD 10.1-STABLE #0 r275364: Tue Dec > 2 08:13:06 ACDT 2014 > root@leader.local:/usr/obj/usr/src-stable/sys/GENERIC amd64 > > This is on an ASUS P8H61-M LE/USB3 corei5 8GB with 3x 2TB Seagate drives > in raidz. > Full backtraces and dmesg at http://shaneware.biz/freebsddebugdata/ > > The thing that breaks which forces me to reset the machine is that I am > unable to start new processes. Existing processes continue to work I > just can't start new ones. Some simple commands do work but top ps > procstat usbconfig all fail to start. I have been able use script to > get some backtraces from kgdb before restarting. It looks like your processes are hanging on a global lock used by sysctl(3). That would explain hangs in top/ps/procstat as they all use sysctls. For example: Thread 709 (Thread 101172): #0 sched_switch (td=0xfffff8006cccd490, newtd=, flags=) at /usr/src-stable/sys/kern/sched_ule.c:1945 #1 0xffffffff80933801 in mi_switch (flags=260, newtd=0x0) at /usr/src-stable/sys/kern/kern_synch.c:493 #2 0xffffffff8097110a in sleepq_wait (wchan=0x0, pri=0) at /usr/src-stable/sys/kern/subr_sleepqueue.c:617 #3 0xffffffff8093284a in _sx_xlock_hard (sx=0xffffffff8157adc0, tid=18446735279441892496, opts=, file=0x0, line=0) at /usr/src-stable/sys/kern/kern_sx.c:681 #4 0xffffffff80936004 in userland_sysctl (td=, name=0xfffffe021e889930, namelen=3, old=, oldlenp=, inkernel=, new=, newlen=, retval=, flags=0) at sx.h:152 #5 0xffffffff80935e64 in sys___sysctl (td=0xfffff8006cccd490, uap=0xfffffe021e889a40) at /usr/src-stable/sys/kern/kern_sysctl.c:1536 #6 0xffffffff80d29c51 in amd64_syscall (td=0xfffff8006cccd490, traced=0) at subr_syscall.c:134 #7 0xffffffff80d0eceb in Xfast_syscall () at /usr/src-stable/sys/amd64/amd64/exception.S:391 #8 0x0000000800b6e64a in ?? () Previous frame inner to this frame (corrupt stack?) ---Type to continue, or q to quit--- To hang like this means that some sysctl handler is running for a long time. Looking in your traces, this appears to be the problematic sysctl: Thread 397 (Thread 100422): #0 sched_switch (td=0xfffff8001049f920, newtd=, flags=) at /usr/src-stable/sys/kern/sched_ule.c:1945 #1 0xffffffff80933801 in mi_switch (flags=260, newtd=0x0) at /usr/src-stable/sys/kern/kern_synch.c:493 #2 0xffffffff8097189a in sleepq_timedwait (wchan=0x0, pri=0) at /usr/src-stable/sys/kern/subr_sleepqueue.c:652 #3 0xffffffff8093320e in _sleep (ident=, lock=, priority=, wmesg=, sbt=, pr=, flags=) at /usr/src-stable/sys/kern/kern_synch.c:251 #4 0xffffffff80891ae3 in g_waitfor_event (func=, arg=, flag=) at /usr/src-stable/sys/geom/geom_event.c:427 #5 0xffffffff808933d9 in sysctl_kern_geom_conftxt (oidp=, arg1=, arg2=, req=0xfffffe021dc13868) at /usr/src-stable/sys/geom/geom_kern.c:169 #6 0xffffffff80935a9e in sysctl_root (arg1=, arg2=) at /usr/src-stable/sys/kern/kern_sysctl.c:1500 #7 0xffffffff80936078 in userland_sysctl (td=, name=0xfffffe021dc13930, namelen=, old=, oldlenp=, inkernel=, new=, newlen=, retval=, flags=0) at /usr/src-stable/sys/kern/kern_sysctl.c:1610 #8 0xffffffff80935e64 in sys___sysctl (td=0xfffff8001049f920, uap=0xfffffe021dc13a40) at /usr/src-stable/sys/kern/kern_sysctl.c:1536 #9 0xffffffff80d29c51 in amd64_syscall (td=0xfffff8001049f920, traced=0) at subr_syscall.c:134 #10 0xffffffff80d0eceb in Xfast_syscall () at /usr/src-stable/sys/amd64/amd64/exception.S:391 #11 0x00000008019c864a in ?? () Previous frame inner to this frame (corrupt stack?) (Note that HEAD has some changes by mjg@ (cc'd) to allow concurrent sysctls that would at least make this less painful.) The root issue is why is geom hanging. Hmm, that thread is also stuck on an sx lock: Thread 259 (Thread 100015): #0 sched_switch (td=0xfffff80005170000, newtd=, flags=) at /usr/src-stable/sys/kern/sched_ule.c:1945 #1 0xffffffff80933801 in mi_switch (flags=260, newtd=0x0) at /usr/src-stable/sys/kern/kern_synch.c:493 #2 0xffffffff8097110a in sleepq_wait (wchan=0x0, pri=0) at /usr/src-stable/sys/kern/subr_sleepqueue.c:617 #3 0xffffffff8093284a in _sx_xlock_hard (sx=0xffffffff816451e0, tid=18446735277701922816, opts=, file=0x0, line=0) at /usr/src-stable/sys/kern/kern_sx.c:681 #4 0xffffffff808912b2 in g_run_events () at sx.h:152 #5 0xffffffff808fad3a in fork_exit (callout=0xffffffff80893240 , arg=0x0, frame=0xfffffe01ef98aac0) at /usr/src-stable/sys/kern/kern_fork.c:996 #6 0xffffffff80d0ef3e in fork_trampoline () at /usr/src-stable/sys/amd64/amd64/exception.S:606 #7 0x0000000000000000 in ?? () That is probably g_topology_lock. If so, it is held by this thread (g_dev_open() grabs it around g_access()): Thread 673 (Thread 101936): #0 sched_switch (td=0xfffff80162200490, newtd=, flags=) at /usr/src-stable/sys/kern/sched_ule.c:1945 #1 0xffffffff80933801 in mi_switch (flags=260, newtd=0x0) at /usr/src-stable/sys/kern/kern_synch.c:493 #2 0xffffffff8097110a in sleepq_wait (wchan=0x0, pri=0) at /usr/src-stable/sys/kern/subr_sleepqueue.c:617 #3 0xffffffff80933227 in _sleep (ident=, lock=, priority=, wmesg=, sbt=, pr=, flags=) at /usr/src-stable/sys/kern/kern_synch.c:255 #4 0xffffffff8030b9b3 in daopen (dp=) at /usr/src-stable/sys/cam/scsi/scsi_da.c:1295 #5 0xffffffff8089013b in g_disk_access (pp=0xfffff800097f4c00, r=, w=, e=) at /usr/src-stable/sys/geom/geom_disk.c:136 #6 0xffffffff80894f3e in g_access (cp=0xfffff800097f2e00, dcr=1, dcw=0, dce=0) at /usr/src-stable/sys/geom/geom_subr.c:913 #7 0xffffffff8088df12 in g_dev_open (dev=, flags=, fmt=, td=) at /usr/src-stable/sys/geom/geom_dev.c:361 #8 0xffffffff808180f2 in devfs_open (ap=) at /usr/src-stable/sys/fs/devfs/devfs_vnops.c:1086 ---Type to continue, or q to quit--- #9 0xffffffff80e44fd1 in VOP_OPEN_APV (vop=, a=) at vnode_if.c:469 #10 0xffffffff809d9bb4 in vn_open_vnode (vp=0xfffff8017d14d000, fmode=1, cred=0xfffff8000c2e4b00, td=0xfffff80162200490, fp=0xfffff80081060230) at vnode_if.h:196 #11 0xffffffff809d97ac in vn_open_cred (ndp=0xfffffe021e97b880, flagp=0xfffffe021e97b95c, cmode=, vn_open_flags=, cred=0x0, fp=0xfffff80081060230) at /usr/src-stable/sys/kern/vfs_vnops.c:256 #12 0xffffffff809d2def in kern_openat (td=0xfffff80162200490, fd=-100, path=0x7fffffffe99e , pathseg=UIO_USERSPACE, flags=1, mode=) at /usr/src-stable/sys/kern/vfs_syscalls.c:1091 #13 0xffffffff80d29c51 in amd64_syscall (td=0xfffff80162200490, traced=0) at subr_syscall.c:134 #14 0xffffffff80d0eceb in Xfast_syscall () at /usr/src-stable/sys/amd64/amd64/exception.S:391 #15 0x0000000800f8dcea in ?? () Previous frame inner to this frame (corrupt stack?) Line 1295 of scsi_da.c in a stable/10 checkout of today is this: /* Wait for the disk size update. */ error = cam_periph_sleep(periph, &softc->disk->d_mediasize, PRIBIO, "dareprobe", 0); To be stuck here means that the request dareprobe() queued is stuck behind some other request on the device. Looking in your traces, there are several threads all waiting for an ioctl() to a passX device to complete: Thread 432 (Thread 100542): #0 sched_switch (td=0xfffff801acb8a920, newtd=, flags=) at /usr/src-stable/sys/kern/sched_ule.c:1945 #1 0xffffffff80933801 in mi_switch (flags=260, newtd=0x0) at /usr/src-stable/sys/kern/kern_synch.c:493 #2 0xffffffff8097110a in sleepq_wait (wchan=0x0, pri=0) at /usr/src-stable/sys/kern/subr_sleepqueue.c:617 #3 0xffffffff80933227 in _sleep (ident=, lock=, priority=, wmesg=, sbt=, pr=, flags=) at /usr/src-stable/sys/kern/kern_synch.c:255 ---Type to continue, or q to quit--- #4 0xffffffff802ddc0e in cam_periph_runccb (ccb=0xfffff80187888000, error_routine=0xffffffff8030d2a0 , camflags=CAM_RETRY_SELTO, sense_flags=18, ds=0xfffff8000984fa20) at /usr/src-stable/sys/cam/cam_periph.c:969 #5 0xffffffff8030d233 in passdoioctl (dev=, cmd=, addr=0xfffff800b50f4800 "", flag=, td=) at /usr/src-stable/sys/cam/scsi/scsi_pass.c:680 #6 0xffffffff8030cf32 in passioctl (dev=0xfffff80009835e00, cmd=3302496258, addr=0xfffff800b50f4800 "", flag=3, td=0xfffff801acb8a920) at /usr/src-stable/sys/cam/scsi/scsi_pass.c:533 #7 0xffffffff80819a99 in devfs_ioctl_f (fp=0xfffff800b5d6f320, com=3302496258, data=0xfffff800b50f4800, cred=, td=0xfffff801acb8a920) at /usr/src-stable/sys/fs/devfs/devfs_vnops.c:759 #8 0xffffffff8097d865 in kern_ioctl (td=0xfffff801acb8a920, fd=, com=0) at file.h:320 #9 0xffffffff8097d560 in sys_ioctl (td=0xfffff801acb8a920, uap=0xfffffe021de9aa40) at /usr/src-stable/sys/kern/sys_generic.c:718 #10 0xffffffff80d29c51 in amd64_syscall (td=0xfffff801acb8a920, traced=0) at subr_syscall.c:134 #11 0xffffffff80d0eceb in Xfast_syscall () at /usr/src-stable/sys/amd64/amd64/exception.S:391 #12 0x0000000800ff3f7a in ?? () Previous frame inner to this frame (corrupt stack?) I suspect the daopen() is hanging on the disk associated with the given passX device. Are you running smartd or anything else that accesses passX devices? Also, do you have a coredump from this or were you just running kgdb against the live system? If you have a coredump you can run ps against it (or use some kgdb macros I have) to see the command name of the process doing the passX ioctls. We could also see which passX devices were blocking to see if this is related to either AHCI or USB. Also, do you possibly have any errors in your dmesg from the disk devices? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Dec 16 17:08: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 5A4565BF; Tue, 16 Dec 2014 17:08:01 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 34478D55; Tue, 16 Dec 2014 17:08:01 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3006DB984; Tue, 16 Dec 2014 12:08:00 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Subject: Re: FreeBSD 10.1 qcow2 image panic on Linux VM hosts Date: Tue, 16 Dec 2014 12:05:41 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <546F2614.4020800@stenton.me.uk> In-Reply-To: <546F2614.4020800@stenton.me.uk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201412161205.41152.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 16 Dec 2014 12:08:00 -0500 (EST) Cc: Marcel Moolenaar 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, 16 Dec 2014 17:08:01 -0000 On Friday, November 21, 2014 6:46:28 am Chris Stenton wrote: > Hi, > > I am trying to run the vanilla FreeBSD 10.1 qcow2 image on a CENTOS 7 VM > Host. > > I can start it up ok but under a small load it kernel panics. > > The error is > > g_vfs_done():vtdb0: hard error gpt/rootfs[WRITE(offset=21890048, > length=8704)]cmd=write error = 534 panic:cannot reassign paging buffer > cpuid = 1 > > Dump failed so I am just copying the above from virt-manager console. > > All I am doing is pkg install emacs24 and it gets as far as "[7/96] > Installing perl5-5.16.3_11: 32%" > > I've tried the Image on a Ubuntu VM host as well and get the same > problem. I've tried varying the amount of memory up to 4GB but still > the same problem. Other OS's clients run fine. > > Any ideas? Marcel believes he fixed the root issue in r275721. Can you try rebuilding the image with the fixed mkimg to see if that fixes the problem? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Dec 16 21:07:00 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 EBA17359 for ; Tue, 16 Dec 2014 21:07:00 +0000 (UTC) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::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 AC286FC for ; Tue, 16 Dec 2014 21:07:00 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id x19so13678434ier.27 for ; Tue, 16 Dec 2014 13:07:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=i6XbZh5baiqNmkKjSz4v/DEEUR1ZIeDBhVMmdsq/FU4=; b=QMd04yPakXEsabHjeYnuWprXmiXhVnfbx0f9esHvTJRoJjlukc9Yv45l2CScK5Mga+ i1ocX/rS1pmlVW04BzVPX2jNI/BgNE0Y4o5ci20QoyaYHRnU7E8o0s/UzC5CeeEr0KwA XkBtDYMsQgXhjc0bPX82uGw65KBQtjWWHSTEIXmvkNauY/+3XymIElF9XrqfrI+5uABs ro+aCrSGPyeCyWb9KnIPDoZCEUvQYnqlffszlpKrsBE6/2cVI3NrNul4yVwoWpDnRyET SmeerwjmtFl3BfvaKhzFLxQy/3j3MXvoqvlQ9VAE8xzNey42DDU3KlfB0/jl6W6c6xZa 8fvQ== MIME-Version: 1.0 X-Received: by 10.42.4.201 with SMTP id 9mr34095395ict.23.1418764019953; Tue, 16 Dec 2014 13:06:59 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.107.52.19 with HTTP; Tue, 16 Dec 2014 13:06:59 -0800 (PST) In-Reply-To: <20141216092259.GF89148@droso.dk> References: <20131203.223612.74719903.sthaug@nethelp.no> <20141215.082038.41648681.sthaug@nethelp.no> <20141216092259.GF89148@droso.dk> Date: Tue, 16 Dec 2014 13:06:59 -0800 X-Google-Sender-Auth: 2P5zj8LvUZyUDNH2I-ik--1vo-E Message-ID: Subject: Re: BIND chroot environment in 10-RELEASE...gone? From: Kevin Oberman To: FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 21:07:01 -0000 On Tue, Dec 16, 2014 at 1:22 AM, Erwin Lansing wrote: > On Mon, Dec 15, 2014 at 10:12:45PM -0800, Kevin Oberman wrote: > > > > Please don't conflate issues. Moving BIND out of the base system is > > something long overdue. I know that the longtime BIND maintainer, Doug B, > > had long felt it should be removed. This has exactly NOTHING to do with > > removing the default chroot installation. The ports were, by default > > installed chrooted. Jailed would have been better, but it was not > something > > that could be done in a port unless the jail had already been set up. > > chroot is still vastly superior to not chrooted and I was very distressed > > to see it go from the ports. > > > > While I don't want to get dragged down into this discussion that can go > on forever without any consensus, I just want to point out that there is > a slight twist to the above description. Due to implementational > details, the ports' chroot was actually inside the base system parts of > BIND. Removing the one, removed the other. > > I did try my hand at a reimplentation self-contained in the port, but > that proved less trivial than thought and I never reached a satisfactory > solution. If anyone want to try their hands at it as well and convince > the new port maintainer, please do so, but trust me when I say that. > e.g. an ezjail solution, is much easier to set up and maintain than > reverting to the old functionality. In they end, I'd rather see a > more general solution that can chroot, or jail, an arbitrary daemon from > ports rather than special treatment of a single port. If BIND, why not > also NSD, unbound, or apache for arguments sake? > Erwin, Thanks for this explanation! In the prior discussion of this issue back when BIND was removed from the base, I never saw this and it explains a great deal.I hope that this will quiet some of the complaints. While it is still a regression, it's one worth making. Getting BIND out of the base system really was urgently required. Thanks for your efforts on this. Warren, Nice write-up on jailing BIND. The instructions are easy to follow, but they are still pretty complex and getting everything right without a tutorial like this was very tricky. For me it involved a fair amount of trial and error and before ez-jail it was really, really hard. (Not sure that I ever got it right.) -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-stable@FreeBSD.ORG Tue Dec 16 23:27:03 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 07E54695; Tue, 16 Dec 2014 23:27:03 +0000 (UTC) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by mx1.freebsd.org (Postfix) with ESMTP id 5D290226; Tue, 16 Dec 2014 23:27:00 +0000 (UTC) Received: from ppp14-2-30-215.lns21.adl2.internode.on.net (HELO leader.local) ([14.2.30.215]) by ipmail05.adl6.internode.on.net with ESMTP; 17 Dec 2014 09:55:11 +1030 Message-ID: <5490BF55.3020108@ShaneWare.Biz> Date: Wed, 17 Dec 2014 09:55:09 +1030 From: Shane Ambler User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: John Baldwin , freebsd-stable@freebsd.org Subject: Re: Help debugging stable/10 References: <5488F58D.7060708@ShaneWare.Biz> <201412161129.57704.jhb@freebsd.org> In-Reply-To: <201412161129.57704.jhb@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Motin , hselasky@freebsd.org, mjg@freebsd.org, Shane Ambler 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, 16 Dec 2014 23:27:03 -0000 On 17/12/2014 02:59, John Baldwin wrote: > On Wednesday, December 10, 2014 8:38:21 pm Shane Ambler wrote: >> Since upgrading to 10.1 (RC2) I have had trouble getting uptimes greater >> than 1 day. I have little experience debugging the OS so could use some >> help. >> >> # uname -a >> FreeBSD leader.local 10.1-STABLE FreeBSD 10.1-STABLE #0 r275364: Tue Dec >> 2 08:13:06 ACDT 2014 >> root@leader.local:/usr/obj/usr/src-stable/sys/GENERIC amd64 >> >> This is on an ASUS P8H61-M LE/USB3 corei5 8GB with 3x 2TB Seagate drives >> in raidz. >> Full backtraces and dmesg at http://shaneware.biz/freebsddebugdata/ >> >> The thing that breaks which forces me to reset the machine is that I am >> unable to start new processes. Existing processes continue to work I >> just can't start new ones. Some simple commands do work but top ps >> procstat usbconfig all fail to start. I have been able use script to >> get some backtraces from kgdb before restarting. > > It looks like your processes are hanging on a global lock used by sysctl(3). > That would explain hangs in top/ps/procstat as they all use sysctls. For > example: > > Thread 709 (Thread 101172): > #0 sched_switch (td=0xfffff8006cccd490, newtd=, flags=) > at /usr/src-stable/sys/kern/sched_ule.c:1945 > #1 0xffffffff80933801 in mi_switch (flags=260, newtd=0x0) at /usr/src-stable/sys/kern/kern_synch.c:493 > #2 0xffffffff8097110a in sleepq_wait (wchan=0x0, pri=0) at /usr/src-stable/sys/kern/subr_sleepqueue.c:617 > #3 0xffffffff8093284a in _sx_xlock_hard (sx=0xffffffff8157adc0, tid=18446735279441892496, > opts=, file=0x0, line=0) at /usr/src-stable/sys/kern/kern_sx.c:681 > #4 0xffffffff80936004 in userland_sysctl (td=, name=0xfffffe021e889930, namelen=3, > old=, oldlenp=, inkernel=, > new=, newlen=, retval=, flags=0) at sx.h:152 > #5 0xffffffff80935e64 in sys___sysctl (td=0xfffff8006cccd490, uap=0xfffffe021e889a40) > at /usr/src-stable/sys/kern/kern_sysctl.c:1536 > #6 0xffffffff80d29c51 in amd64_syscall (td=0xfffff8006cccd490, traced=0) at subr_syscall.c:134 > #7 0xffffffff80d0eceb in Xfast_syscall () at /usr/src-stable/sys/amd64/amd64/exception.S:391 > #8 0x0000000800b6e64a in ?? () > Previous frame inner to this frame (corrupt stack?) > ---Type to continue, or q to quit--- > > To hang like this means that some sysctl handler is running for a long time. > > Looking in your traces, this appears to be the problematic sysctl: > > Thread 397 (Thread 100422): > #0 sched_switch (td=0xfffff8001049f920, newtd=, flags=) > at /usr/src-stable/sys/kern/sched_ule.c:1945 > #1 0xffffffff80933801 in mi_switch (flags=260, newtd=0x0) at /usr/src-stable/sys/kern/kern_synch.c:493 > #2 0xffffffff8097189a in sleepq_timedwait (wchan=0x0, pri=0) at /usr/src-stable/sys/kern/subr_sleepqueue.c:652 > #3 0xffffffff8093320e in _sleep (ident=, lock=, > priority=, wmesg=, sbt=, pr=, > flags=) at /usr/src-stable/sys/kern/kern_synch.c:251 > #4 0xffffffff80891ae3 in g_waitfor_event (func=, arg=, > flag=) at /usr/src-stable/sys/geom/geom_event.c:427 > #5 0xffffffff808933d9 in sysctl_kern_geom_conftxt (oidp=, arg1=, > arg2=, req=0xfffffe021dc13868) at /usr/src-stable/sys/geom/geom_kern.c:169 > #6 0xffffffff80935a9e in sysctl_root (arg1=, arg2=) > at /usr/src-stable/sys/kern/kern_sysctl.c:1500 > #7 0xffffffff80936078 in userland_sysctl (td=, name=0xfffffe021dc13930, > namelen=, old=, oldlenp=, > inkernel=, new=, newlen=, > retval=, flags=0) at /usr/src-stable/sys/kern/kern_sysctl.c:1610 > #8 0xffffffff80935e64 in sys___sysctl (td=0xfffff8001049f920, uap=0xfffffe021dc13a40) > at /usr/src-stable/sys/kern/kern_sysctl.c:1536 > #9 0xffffffff80d29c51 in amd64_syscall (td=0xfffff8001049f920, traced=0) at subr_syscall.c:134 > #10 0xffffffff80d0eceb in Xfast_syscall () at /usr/src-stable/sys/amd64/amd64/exception.S:391 > #11 0x00000008019c864a in ?? () > Previous frame inner to this frame (corrupt stack?) > > (Note that HEAD has some changes by mjg@ (cc'd) to allow concurrent sysctls > that would at least make this less painful.) > > The root issue is why is geom hanging. Hmm, that thread is also stuck on an > sx lock: > > Thread 259 (Thread 100015): > #0 sched_switch (td=0xfffff80005170000, newtd=, flags=) > at /usr/src-stable/sys/kern/sched_ule.c:1945 > #1 0xffffffff80933801 in mi_switch (flags=260, newtd=0x0) at /usr/src-stable/sys/kern/kern_synch.c:493 > #2 0xffffffff8097110a in sleepq_wait (wchan=0x0, pri=0) at /usr/src-stable/sys/kern/subr_sleepqueue.c:617 > #3 0xffffffff8093284a in _sx_xlock_hard (sx=0xffffffff816451e0, tid=18446735277701922816, > opts=, file=0x0, line=0) at /usr/src-stable/sys/kern/kern_sx.c:681 > #4 0xffffffff808912b2 in g_run_events () at sx.h:152 > #5 0xffffffff808fad3a in fork_exit (callout=0xffffffff80893240 , arg=0x0, frame=0xfffffe01ef98aac0) > at /usr/src-stable/sys/kern/kern_fork.c:996 > #6 0xffffffff80d0ef3e in fork_trampoline () at /usr/src-stable/sys/amd64/amd64/exception.S:606 > #7 0x0000000000000000 in ?? () > > That is probably g_topology_lock. If so, it is held by this thread > (g_dev_open() grabs it around g_access()): > > Thread 673 (Thread 101936): > #0 sched_switch (td=0xfffff80162200490, newtd=, flags=) > at /usr/src-stable/sys/kern/sched_ule.c:1945 > #1 0xffffffff80933801 in mi_switch (flags=260, newtd=0x0) at /usr/src-stable/sys/kern/kern_synch.c:493 > #2 0xffffffff8097110a in sleepq_wait (wchan=0x0, pri=0) at /usr/src-stable/sys/kern/subr_sleepqueue.c:617 > #3 0xffffffff80933227 in _sleep (ident=, lock=, > priority=, wmesg=, sbt=, pr=, > flags=) at /usr/src-stable/sys/kern/kern_synch.c:255 > #4 0xffffffff8030b9b3 in daopen (dp=) at /usr/src-stable/sys/cam/scsi/scsi_da.c:1295 > #5 0xffffffff8089013b in g_disk_access (pp=0xfffff800097f4c00, r=, w=, > e=) at /usr/src-stable/sys/geom/geom_disk.c:136 > #6 0xffffffff80894f3e in g_access (cp=0xfffff800097f2e00, dcr=1, dcw=0, dce=0) > at /usr/src-stable/sys/geom/geom_subr.c:913 > #7 0xffffffff8088df12 in g_dev_open (dev=, flags=, > fmt=, td=) at /usr/src-stable/sys/geom/geom_dev.c:361 > #8 0xffffffff808180f2 in devfs_open (ap=) at /usr/src-stable/sys/fs/devfs/devfs_vnops.c:1086 > ---Type to continue, or q to quit--- > #9 0xffffffff80e44fd1 in VOP_OPEN_APV (vop=, a=) at vnode_if.c:469 > #10 0xffffffff809d9bb4 in vn_open_vnode (vp=0xfffff8017d14d000, fmode=1, cred=0xfffff8000c2e4b00, > td=0xfffff80162200490, fp=0xfffff80081060230) at vnode_if.h:196 > #11 0xffffffff809d97ac in vn_open_cred (ndp=0xfffffe021e97b880, flagp=0xfffffe021e97b95c, > cmode=, vn_open_flags=, cred=0x0, fp=0xfffff80081060230) > at /usr/src-stable/sys/kern/vfs_vnops.c:256 > #12 0xffffffff809d2def in kern_openat (td=0xfffff80162200490, fd=-100, > path=0x7fffffffe99e , pathseg=UIO_USERSPACE, flags=1, > mode=) at /usr/src-stable/sys/kern/vfs_syscalls.c:1091 > #13 0xffffffff80d29c51 in amd64_syscall (td=0xfffff80162200490, traced=0) at subr_syscall.c:134 > #14 0xffffffff80d0eceb in Xfast_syscall () at /usr/src-stable/sys/amd64/amd64/exception.S:391 > #15 0x0000000800f8dcea in ?? () > Previous frame inner to this frame (corrupt stack?) > > Line 1295 of scsi_da.c in a stable/10 checkout of today is this: > > /* Wait for the disk size update. */ > error = cam_periph_sleep(periph, &softc->disk->d_mediasize, PRIBIO, > "dareprobe", 0); > > To be stuck here means that the request dareprobe() queued is stuck behind > some other request on the device. Looking in your traces, there are several > threads all waiting for an ioctl() to a passX device to complete: > > Thread 432 (Thread 100542): > #0 sched_switch (td=0xfffff801acb8a920, newtd=, flags=) > at /usr/src-stable/sys/kern/sched_ule.c:1945 > #1 0xffffffff80933801 in mi_switch (flags=260, newtd=0x0) at /usr/src-stable/sys/kern/kern_synch.c:493 > #2 0xffffffff8097110a in sleepq_wait (wchan=0x0, pri=0) at /usr/src-stable/sys/kern/subr_sleepqueue.c:617 > #3 0xffffffff80933227 in _sleep (ident=, lock=, > priority=, wmesg=, sbt=, pr=, > flags=) at /usr/src-stable/sys/kern/kern_synch.c:255 > ---Type to continue, or q to quit--- > #4 0xffffffff802ddc0e in cam_periph_runccb (ccb=0xfffff80187888000, error_routine=0xffffffff8030d2a0 , > camflags=CAM_RETRY_SELTO, sense_flags=18, ds=0xfffff8000984fa20) at /usr/src-stable/sys/cam/cam_periph.c:969 > #5 0xffffffff8030d233 in passdoioctl (dev=, cmd=, > addr=0xfffff800b50f4800 "", flag=, td=) > at /usr/src-stable/sys/cam/scsi/scsi_pass.c:680 > #6 0xffffffff8030cf32 in passioctl (dev=0xfffff80009835e00, cmd=3302496258, addr=0xfffff800b50f4800 "", flag=3, > td=0xfffff801acb8a920) at /usr/src-stable/sys/cam/scsi/scsi_pass.c:533 > #7 0xffffffff80819a99 in devfs_ioctl_f (fp=0xfffff800b5d6f320, com=3302496258, data=0xfffff800b50f4800, > cred=, td=0xfffff801acb8a920) at /usr/src-stable/sys/fs/devfs/devfs_vnops.c:759 > #8 0xffffffff8097d865 in kern_ioctl (td=0xfffff801acb8a920, fd=, com=0) at file.h:320 > #9 0xffffffff8097d560 in sys_ioctl (td=0xfffff801acb8a920, uap=0xfffffe021de9aa40) > at /usr/src-stable/sys/kern/sys_generic.c:718 > #10 0xffffffff80d29c51 in amd64_syscall (td=0xfffff801acb8a920, traced=0) at subr_syscall.c:134 > #11 0xffffffff80d0eceb in Xfast_syscall () at /usr/src-stable/sys/amd64/amd64/exception.S:391 > #12 0x0000000800ff3f7a in ?? () > Previous frame inner to this frame (corrupt stack?) > > I suspect the daopen() is hanging on the disk associated with the given > passX device. > > Are you running smartd or anything else that accesses passX devices? > > Also, do you have a coredump from this or were you just running kgdb against > the live system? If you have a coredump you can run ps against it (or use > some kgdb macros I have) to see the command name of the process doing the > passX ioctls. We could also see which passX devices were blocking to see if > this is related to either AHCI or USB. Also, do you possibly have any errors > in your dmesg from the disk devices? > Thanks for looking at this. I updated a few days ago - FreeBSD leader.local 10.1-STABLE FreeBSD 10.1-STABLE #0 r275731: Sat Dec 13 08:36:29 ACDT 2014 root@leader.local:/usr/obj/usr/src/sys/GENERIC amd64 I haven't got any core dumps as I only get to the stage of no process creation (yesterday I had it freeze completely) leaving no choice but to reset. I leave a root terminal open so that I can run kgdb before resetting. I have sysutils/smartmontools installed but I'm not running smartd, I just have the smart status in daily logs. I'll vote for USB - I have two USB memsticks that I use almost daily - previously (since 10.1RC2) I have had trouble with them. Failure to get the dev entries created, followed with no console messages of device insert/remove. I had noticed this before being unable to create processes so wasn't sure which came first. usbconfig was sometimes the first process I noticed failure to run. I haven't seen this for a while, so not in stable, maybe in release but definitely in RC 2-4 I think it was in RC3 I got errors of - xptioctl: pass driver is not in the kernel xptioctl: put "device pass" in your kernel config file a couple of times with the USB memstick - again not recently. Before release I had an issue with constant zfs writes - I haven't been able to re-create a lockup since RC4 so don't know if that is related. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194654 I'm not seeing any device errors in dmesg, log/messages or log/console.log Someone had mentioned lockups with latest nvidia driver that going back to the previous had fixed, I am getting some x related crashes so was going to look at that. Dec 17 03:21:16 leader kernel: pid 62431 (xcmmtst_big), uid 0: exited on signal 10 (core dumped) Dec 17 03:22:11 leader kernel: pid 69694 (xprobe_gas_x8632), uid 0: exited on signal 11 (core dumped) Dec 17 03:22:11 leader kernel: pid 69779 (xprobe_3dnow), uid 0: exited on signal 4 (core dumped) Dec 17 03:22:42 leader kernel: pid 78410 (xprobe_gas_x8632), uid 0: exited on signal 11 (core dumped) Dec 17 03:22:43 leader kernel: pid 78554 (xprobe_3dnow), uid 0: exited on signal 4 (core dumped) Dec 17 03:46:21 leader kernel: pid 40770 (xdfc), uid 0: exited on signal 10 (core dumped) Dec 17 03:46:26 leader kernel: pid 41000 (xdmmtst), uid 0: exited on signal 10 (core dumped) Dec 17 03:50:55 leader kernel: pid 52533 (xdfc), uid 0: exited on signal 10 (core dumped) Dec 17 03:51:30 leader kernel: pid 54062 (xdfc), uid 0: exited on signal 11 (core dumped) I could run a build of kernel and world with debugging or (is it witness?) for a few days if that would help get more info. -- FreeBSD - the place to B...Software Developing Shane Ambler From owner-freebsd-stable@FreeBSD.ORG Wed Dec 17 02:54:44 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 EF2A4343 for ; Wed, 17 Dec 2014 02:54:44 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id DDEA5A1E for ; Wed, 17 Dec 2014 02:54:44 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 7AFD5187 for ; Wed, 17 Dec 2014 02:54:45 +0000 (UTC) Date: Wed, 17 Dec 2014 02:54:45 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-stable@freebsd.org Message-ID: <1022146096.36.1418784885442.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <336727638.35.1418779986253.JavaMail.jenkins@jenkins-9.freebsd.org> References: <336727638.35.1418779986253.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : Build-UFS-image #689 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: Build-UFS-image X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 02:54:45 -0000 See From owner-freebsd-stable@FreeBSD.ORG Wed Dec 17 11:23:33 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 D351A1F6A for ; Wed, 17 Dec 2014 11:23:33 +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 9AD129C0 for ; Wed, 17 Dec 2014 11:23:33 +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.84 (FreeBSD)) (envelope-from ) id 1Y1ChS-000Gxn-SC; Wed, 17 Dec 2014 11:23:26 +0000 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1Y1ChS-0000fc-OF; Wed, 17 Dec 2014 11:23:26 +0000 To: mikael@ikivesi.net, petefrench@ingresso.co.uk Subject: Re: Hard system lockups with 10.1, probably drm/newcons/radeonkms-related In-Reply-To: <86iohfv6y5.fsf@ikivesi.net> Message-Id: From: Pete French Date: Wed, 17 Dec 2014 11:23:26 +0000 Cc: rleigh@codelibre.net, 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, 17 Dec 2014 11:23:33 -0000 Just to follow this up - I said I would try 10.1 and mesa 10 this week to see if this fixes the issue, and (for me) it has gone aay completely. No lockups or odd graphics card resets. -pete. From owner-freebsd-stable@FreeBSD.ORG Wed Dec 17 11:29: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 97A072B8 for ; Wed, 17 Dec 2014 11:29:56 +0000 (UTC) Received: from smtpfb2-g21.free.fr (unknown [IPv6:2a01:e0c:1:1599::19]) by mx1.freebsd.org (Postfix) with ESMTP id 21844A67 for ; Wed, 17 Dec 2014 11:29:54 +0000 (UTC) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by smtpfb2-g21.free.fr (Postfix) with ESMTP id 52F75CDC265 for ; Wed, 17 Dec 2014 11:08:04 +0100 (CET) Received: from yggdrasil.alkumuna.eu (unknown [IPv6:2a01:e35:8a74:6e70:232:36ff:fe5c:3a87]) by smtp1-g21.free.fr (Postfix) with ESMTP id F1658940002 for ; Wed, 17 Dec 2014 11:04:42 +0100 (CET) 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.9/8.14.9) with ESMTP id sBHA5RxJ076752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 17 Dec 2014 11:05:28 +0100 (CET) (envelope-from mazhe@alkumuna.eu) From: Matthieu Volat Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: freebsd-update: deleting / ? Message-Id: <540146C8-028D-4A43-ADB0-CF78F6FBEB30@alkumuna.eu> Date: Wed, 17 Dec 2014 11:05:19 +0100 To: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) 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, 17 Dec 2014 11:29:56 -0000 Hi, I have a bad feeling with what today's freebsd-update run gives me : The following files will be removed as part of updating to 10.1-RELEASE-p2 / Isn't it a bit hard just for an unbound vulnerability? :) -- Matthieu Volat From owner-freebsd-stable@FreeBSD.ORG Wed Dec 17 12:00:23 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 99E55F61 for ; Wed, 17 Dec 2014 12:00:23 +0000 (UTC) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e: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 63C1AE55 for ; Wed, 17 Dec 2014 12:00:23 +0000 (UTC) Received: by mail-pa0-f52.google.com with SMTP id eu11so16116075pac.25 for ; Wed, 17 Dec 2014 04:00:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EjvRGPBeWrrRYuIZ6zGGYZQ5M+OpuLGsADElv2TGj9E=; b=FNRW2lPLpwFi6UenZsjqmxAB5m+IiB1bMzxieSp7pjyRjVCqIc4792RSdPFUsR10Dz iqojUIDGAh6ZzKQGu2PgGmWYjUXY18Gz9ozmo+Dwshqbso4icy3mQNS9b9RlVKBK3lyJ SWiUCVwZWHsVDneR8bzLnUbnwmRjSOA7ALKEusxlACofiQw1qRwkDg/bqRLRC435fXOX hj3TX7+X9KnAcIqfqK36YyIDR8QYPNZiIEbXld8e4pDD0m13fH3KzhAp7040ZDwgcp4A g4Kk38qXDuzCuUnLO7CTKcvxCG34z4xkeU2Gp4l32bcNK1vl9xwihDa2qgncCwtAVfg4 yl5Q== X-Received: by 10.70.47.195 with SMTP id f3mr68501234pdn.156.1418817622902; Wed, 17 Dec 2014 04:00:22 -0800 (PST) Received: from ?IPv6:2001:44b8:31ae:7b00:f839:c79a:d75:9254? (2001-44b8-31ae-7b00-f839-c79a-0d75-9254.static.ipv6.internode.on.net. [2001:44b8:31ae:7b00:f839:c79a:d75:9254]) by mx.google.com with ESMTPSA id bn13sm3822651pdb.4.2014.12.17.04.00.20 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Dec 2014 04:00:22 -0800 (PST) Sender: Kubilay Kocak Message-ID: <5491704E.7090407@FreeBSD.org> Date: Wed, 17 Dec 2014 23:00:14 +1100 From: Kubilay Kocak Reply-To: koobs@FreeBSD.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Thunderbird/34.0 MIME-Version: 1.0 To: Matthieu Volat , freebsd-stable@freebsd.org Subject: Re: freebsd-update: deleting / ? References: <540146C8-028D-4A43-ADB0-CF78F6FBEB30@alkumuna.eu> In-Reply-To: <540146C8-028D-4A43-ADB0-CF78F6FBEB30@alkumuna.eu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 12:00:23 -0000 On 17/12/2014 9:05 PM, Matthieu Volat wrote: > Hi, > > I have a bad feeling with what today's freebsd-update run gives me : > > The following files will be removed as part of updating to 10.1-RELEASE-p2 > / > > Isn't it a bit hard just for an unbound vulnerability? :) > > -- Matthieu Volat > _______________________________________________ > 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" > Issue has been reported and assigned, if you'd could add a comment on the issue that would be appreciated: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196055 I've also pinged a few other people on IRC in case assistance is required or Colin is afk. Koobs From owner-freebsd-stable@FreeBSD.ORG Wed Dec 17 14:58:54 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 B1CBC78D; Wed, 17 Dec 2014 14:58:54 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8A6BB97D; Wed, 17 Dec 2014 14:58:54 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 77074B984; Wed, 17 Dec 2014 09:58:53 -0500 (EST) From: John Baldwin To: Shane Ambler Subject: Re: Help debugging stable/10 Date: Wed, 17 Dec 2014 09:30:26 -0500 Message-ID: <2129928.1Q3VzLjDQL@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <5490BF55.3020108@ShaneWare.Biz> References: <5488F58D.7060708@ShaneWare.Biz> <201412161129.57704.jhb@freebsd.org> <5490BF55.3020108@ShaneWare.Biz> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 17 Dec 2014 09:58:53 -0500 (EST) Cc: Alexander Motin , freebsd-stable@freebsd.org, hselasky@freebsd.org, mjg@freebsd.org, Shane Ambler 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, 17 Dec 2014 14:58:54 -0000 On Wednesday, December 17, 2014 09:55:09 AM Shane Ambler wrote: > I think it was in RC3 I got errors of - > xptioctl: pass driver is not in the kernel > xptioctl: put "device pass" in your kernel config file > a couple of times with the USB memstick - again not recently. Interesting. Perhaps take 'pass' back out then as the cure seems worse than the disease. :) Can you figure out what processes are running when those errors are logged? Whatever is calling xptioctl() is triggering this I believe. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Dec 17 19:01:09 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 DAAAC23B; Wed, 17 Dec 2014 19:01:09 +0000 (UTC) Received: from apollo.teardrop.org (apollo.teardrop.org [173.228.105.28]) (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 C4DEFB9A; Wed, 17 Dec 2014 19:01:09 +0000 (UTC) Received: by apollo.teardrop.org (Postfix, from userid 30000) id C15F01C722; Wed, 17 Dec 2014 18:53:08 +0000 (UTC) Date: Wed, 17 Dec 2014 18:53:08 +0000 From: James Snow To: Kubilay Kocak Subject: Re: freebsd-update: deleting / ? Message-ID: <20141217185308.GH56018@teardrop.org> References: <540146C8-028D-4A43-ADB0-CF78F6FBEB30@alkumuna.eu> <5491704E.7090407@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5491704E.7090407@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-stable@freebsd.org, Matthieu Volat 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, 17 Dec 2014 19:01:09 -0000 On Wed, Dec 17, 2014 at 11:00:14PM +1100, Kubilay Kocak wrote: > On 17/12/2014 9:05 PM, Matthieu Volat wrote: > > Hi, > > > > I have a bad feeling with what today's freebsd-update run gives me : > > > > The following files will be removed as part of updating to 10.1-RELEASE-p2 > > / > > > > Isn't it a bit hard just for an unbound vulnerability? :) > > > > -- Matthieu Volat > > _______________________________________________ > > 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" > > > > Issue has been reported and assigned, if you'd could add a comment on > the issue that would be appreciated: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196055 > > I've also pinged a few other people on IRC in case assistance is > required or Colin is afk. Got curious and tried to repro: Installing updates...rmdir: ///: Is a directory At least the safety was on. ;) -Snow From owner-freebsd-stable@FreeBSD.ORG Thu Dec 18 01:59: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 0A33B2FC; Thu, 18 Dec 2014 01:59:46 +0000 (UTC) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by mx1.freebsd.org (Postfix) with ESMTP id DDD4F223; Thu, 18 Dec 2014 01:59:44 +0000 (UTC) Received: from ppp14-2-30-215.lns21.adl2.internode.on.net (HELO leader.local) ([14.2.30.215]) by ipmail05.adl6.internode.on.net with ESMTP; 18 Dec 2014 12:29:36 +1030 Message-ID: <54923507.5030908@ShaneWare.Biz> Date: Thu, 18 Dec 2014 12:29:35 +1030 From: Shane Ambler User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: John Baldwin Subject: Re: Help debugging stable/10 References: <5488F58D.7060708@ShaneWare.Biz> <201412161129.57704.jhb@freebsd.org> <5490BF55.3020108@ShaneWare.Biz> <2129928.1Q3VzLjDQL@ralph.baldwin.cx> In-Reply-To: <2129928.1Q3VzLjDQL@ralph.baldwin.cx> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Motin , freebsd-stable@freebsd.org, hselasky@freebsd.org, mjg@freebsd.org, Shane Ambler 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, 18 Dec 2014 01:59:46 -0000 On 18/12/2014 01:00, John Baldwin wrote: > On Wednesday, December 17, 2014 09:55:09 AM Shane Ambler wrote: >> I think it was in RC3 I got errors of - >> xptioctl: pass driver is not in the kernel >> xptioctl: put "device pass" in your kernel config file >> a couple of times with the USB memstick - again not recently. > > Interesting. Perhaps take 'pass' back out then as the cure seems worse than > the disease. :) Can you figure out what processes are running when those > errors are logged? Whatever is calling xptioctl() is triggering this I > believe. > I haven't altered the kernel config. That was an old error I got a few times when I had issues with the USB device insertion not registering. I think I saw it 3 times and it was a continuous repeat on the console. It only showed when things went bad so I wasn't convinced I needed to add it. Just mentioned as it appeared to be USB related and might hint to what triggers the USB system to falter. Could be a red herring too. -- FreeBSD - the place to B...Software Developing Shane Ambler From owner-freebsd-stable@FreeBSD.ORG Thu Dec 18 03:33:02 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 1A9771D7; Thu, 18 Dec 2014 03:33:02 +0000 (UTC) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001: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 D1363119B; Thu, 18 Dec 2014 03:33:01 +0000 (UTC) Received: by mail-ig0-f170.google.com with SMTP id r2so163587igi.3; Wed, 17 Dec 2014 19:33:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=K/QmUwERsPHDWw/8i6PESeaLu1pQ3qMLQnM8M4u09nk=; b=vTdudDLv1ce0kvzLyXz8vHavfl0ZYSZdWpEdikPy/GgKDGWTSXqXBbwIgmyHW/J9bV 7acJGQNF9fLpJz+yTzHGhOxoQQ8NHpwq3ruAUGZunutKO1nzb48mJ0rd2Av9FAqHp/YO nepSs02Fm+cs5Io8Jbkyy/FrxyAKOJFt8D2kzEFtOQZxnxY+IzrTr5h5vXc57RsqQ1mw 0BO/zOnp0eiSeeFxPKxQDs4NNBnGo+UYO9xqrjOph1KfjCuJk1hhkc+Tg/6ZR02so3jU SlLpO1373nZ62h9mypgHb5kmKlPDQ2xGYJrCQCddcknHSmABbBKhpzTtAeYuf1w15vLK NiIg== MIME-Version: 1.0 X-Received: by 10.51.17.11 with SMTP id ga11mr510174igd.0.1418873581237; Wed, 17 Dec 2014 19:33:01 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.107.52.19 with HTTP; Wed, 17 Dec 2014 19:33:01 -0800 (PST) In-Reply-To: <54923507.5030908@ShaneWare.Biz> References: <5488F58D.7060708@ShaneWare.Biz> <201412161129.57704.jhb@freebsd.org> <5490BF55.3020108@ShaneWare.Biz> <2129928.1Q3VzLjDQL@ralph.baldwin.cx> <54923507.5030908@ShaneWare.Biz> Date: Wed, 17 Dec 2014 19:33:01 -0800 X-Google-Sender-Auth: wdclv8TYMhmApNaCPSs8STqLNYk Message-ID: Subject: Re: Help debugging stable/10 From: Kevin Oberman To: Shane Ambler Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD-STABLE Mailing List , hselasky@freebsd.org, mjg@freebsd.org, Alexander Motin , Shane Ambler , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 03:33:02 -0000 On Wed, Dec 17, 2014 at 5:59 PM, Shane Ambler wrote: > On 18/12/2014 01:00, John Baldwin wrote: > >> On Wednesday, December 17, 2014 09:55:09 AM Shane Ambler wrote: >> >>> I think it was in RC3 I got errors of - >>> xptioctl: pass driver is not in the kernel >>> xptioctl: put "device pass" in your kernel config file >>> a couple of times with the USB memstick - again not recently. >>> >> >> Interesting. Perhaps take 'pass' back out then as the cure seems worse >> than >> the disease. :) Can you figure out what processes are running when those >> errors are logged? Whatever is calling xptioctl() is triggering this I >> believe. >> >> > I haven't altered the kernel config. That was an old error I got a few > times when I had issues with the USB device insertion not registering. > I think I saw it 3 times and it was a continuous repeat on the console. > It only showed when things went bad so I wasn't convinced I needed to add > it. Just mentioned as it appeared to be USB related and might hint > to what triggers the USB system to falter. > > Could be a red herring too. > Probably also a read herring, but could this be tied the the problems reported with shutdown never completing? It freezes right after the "All files synced" message, but the devices are not marked clean. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458 -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-stable@FreeBSD.ORG Thu Dec 18 04:34: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 6B03B82A; Thu, 18 Dec 2014 04:34:58 +0000 (UTC) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e: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 364A618D1; Thu, 18 Dec 2014 04:34:58 +0000 (UTC) Received: by mail-pa0-f41.google.com with SMTP id rd3so593669pab.0; Wed, 17 Dec 2014 20:34:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CbNmfSiaQmVYuamwh9/JGQINzmJ0YQuNQyavHnwWsDU=; b=W9PugLHiCTo/MYVJ6QX9HJDzCbZnNlUehwyKSm245PXmEV/1jO90nI2LNLdyxZKI/y yDvsvYFgFiyccz/NNocexSeqCHBw0+RChSvXSPx8uVStcKcpr6ZJoPVC5DH15EfXx/Km soDOk+j0NrhmJ7m5jJNvyKm+NCyOrKrlIaE1sM2e/KW5ITV2aLL6I/IUYD30jKl0924g kLKTez23miR8FVSnf2J3VSdJgUt3Sjiq86cf0aydwpzDD3zoTZ6K7//7EByH/2Dl2bnA ffvS9D2EUPCQZsHsTHEb5u00FUsrn7An3xHxXfW2/k205+epafwnZaGaM7E4xE390Anq 5+6A== MIME-Version: 1.0 X-Received: by 10.70.45.17 with SMTP id i17mr68294pdm.13.1418877297717; Wed, 17 Dec 2014 20:34:57 -0800 (PST) Received: by 10.70.94.167 with HTTP; Wed, 17 Dec 2014 20:34:57 -0800 (PST) In-Reply-To: <54923507.5030908@ShaneWare.Biz> References: <5488F58D.7060708@ShaneWare.Biz> <201412161129.57704.jhb@freebsd.org> <5490BF55.3020108@ShaneWare.Biz> <2129928.1Q3VzLjDQL@ralph.baldwin.cx> <54923507.5030908@ShaneWare.Biz> Date: Wed, 17 Dec 2014 22:34:57 -0600 Message-ID: Subject: Re: Help debugging stable/10 From: Adam Vande More To: Shane Ambler Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-stable@freebsd.org" , Hans Petter Selasky , mjg@freebsd.org, Alexander Motin , Shane Ambler , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 04:34:58 -0000 On Wed, Dec 17, 2014 at 7:59 PM, Shane Ambler wrote: > > On 18/12/2014 01:00, John Baldwin wrote: > >> On Wednesday, December 17, 2014 09:55:09 AM Shane Ambler wrote: >> >>> I think it was in RC3 I got errors of - >>> xptioctl: pass driver is not in the kernel >>> xptioctl: put "device pass" in your kernel config file >>> a couple of times with the USB memstick - again not recently. >>> >> >> Interesting. Perhaps take 'pass' back out then as the cure seems worse >> than >> the disease. :) Can you figure out what processes are running when those >> errors are logged? Whatever is calling xptioctl() is triggering this I >> believe. >> >> > I haven't altered the kernel config. That was an old error I got a few > times when I had issues with the USB device insertion not registering. > I think I saw it 3 times and it was a continuous repeat on the console. > It only showed when things went bad so I wasn't convinced I needed to add > it. Just mentioned as it appeared to be USB related and might hint > to what triggers the USB system to falter. > > Could be a red herring too. There are previous mentions of that error being tickled by hald. Disabling it or preventing it from attacking your device might be a workaround. -- Adam From owner-freebsd-stable@FreeBSD.ORG Thu Dec 18 17:12: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 10A1BC93 for ; Thu, 18 Dec 2014 17:12:36 +0000 (UTC) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "people.fsn.hu", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B23D51DE3 for ; Thu, 18 Dec 2014 17:12:34 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id DAEEC156AC05; Thu, 18 Dec 2014 18:04:18 +0100 (CET) X-Bogosity: Ham, tests=bogofilter, spamicity=0.125809, version=1.2.3 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 7.4558] X-CRM114-CacheID: sfid-20141218_18041_E311E54A X-CRM114-Status: Good ( pR: 7.4558 ) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Thu Dec 18 18:04:18 2014 X-DSPAM-Confidence: 0.7008 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 549309123191664152027 X-DSPAM-Factors: 27, From*"Nagy, Attila" , 0.00010, disks, 0.00335, zfs, 0.00386, queue, 0.00386, Received*(japan.t, 0.00418, Received*online.co.hu+[195.228.243.99]), 0.00456, Received*[195.228.243.99]), 0.00456, Received*online.co.hu, 0.00456, Received*(japan.t+online.co.hu, 0.00456, IO, 0.00501, the+queue, 0.00833, here?, 0.00997, Subject*zfs, 0.00997, zpool, 0.01000, zpool, 0.01000, Date*18+04, 0.99000, Date*04+13, 0.99000, From*Attila"+; Thu, 18 Dec 2014 18:04:14 +0100 (CET) Message-ID: <5493090D.2030406@fsn.hu> Date: Thu, 18 Dec 2014 18:04:13 +0100 From: "Nagy, Attila" 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: geom_multipath and zfs doesn't work Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 17:12:36 -0000 Hi, Running stable/10@r273159 on FC disks (through isp) I can't create a zfs pool. What I have is a simple device, accessible on /dev/multipath/sas0, backed by da0 and da4: # gmultipath status Name Status Components multipath/sas0 OPTIMAL da0 (ACTIVE) da4 (READ) When I issue a zpool create data /dev/multipath/sas0 command, zpool starts to eat 100% CPU: # procstat -k 3924 PID TID COMM TDNAME KSTACK 3924 100128 zpool - gstat shows that there is one uncompleted read IO on multipath/sas0 and the queue length constantly grows on da0: # gstat -b dT: 1.030s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 124402 146 0 0 0.0 0 0 0.0 100.5 da0 0 0 0 0 0.0 0 0 0.0 0.0 da1 0 0 0 0 0.0 0 0 0.0 0.0 da2 0 0 0 0 0.0 0 0 0.0 0.0 da3 1 0 0 0 0.0 0 0 0.0 0.0 multipath/sas0 0 0 0 0 0.0 0 0 0.0 0.0 da4 0 0 0 0 0.0 0 0 0.0 0.0 da5 0 0 0 0 0.0 0 0 0.0 0.0 da6 0 0 0 0 0.0 0 0 0.0 0.0 da7 0 0 0 0 0.0 0 0 0.0 0.0 da8 0 0 0 0 0.0 0 0 0.0 0.0 da9 0 0 0 0 0.0 0 0 0.0 0.0 multipath/sas1 0 0 0 0 0.0 0 0 0.0 0.0 multipath/sata0 0 0 0 0 0.0 0 0 0.0 0.0 multipath/sata1 0 0 0 0 0.0 0 0 0.0 0.0 md0 0 0 0 0 0.0 0 0 0.0 0.0 md1 I can use these devices finely with dd. What's going on here? From owner-freebsd-stable@FreeBSD.ORG Thu Dec 18 17:46:33 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 477204A9 for ; Thu, 18 Dec 2014 17:46:33 +0000 (UTC) Received: from mail.egr.msu.edu (gribble.egr.msu.edu [35.9.37.169]) by mx1.freebsd.org (Postfix) with ESMTP id 212EB2251 for ; Thu, 18 Dec 2014 17:46:32 +0000 (UTC) Received: from gribble (localhost [127.0.0.1]) by mail.egr.msu.edu (Postfix) with ESMTP id A74E045BB2 for ; Thu, 18 Dec 2014 12:46:30 -0500 (EST) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mail.egr.msu.edu ([127.0.0.1]) by gribble (gribble.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGyvAPEi2658 for ; Thu, 18 Dec 2014 12:46:30 -0500 (EST) Received: from EGR authenticated sender Message-ID: <549312F6.1070007@egr.msu.edu> Date: Thu, 18 Dec 2014 12:46:30 -0500 From: Adam McDougall User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: geom_multipath and zfs doesn't work References: <5493090D.2030406@fsn.hu> In-Reply-To: <5493090D.2030406@fsn.hu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 17:46:33 -0000 On 12/18/2014 12:04, Nagy, Attila wrote: > Hi, > > Running stable/10@r273159 on FC disks (through isp) I can't create a zfs > pool. > > What I have is a simple device, accessible on /dev/multipath/sas0, > backed by da0 and da4: > # gmultipath status > Name Status Components > multipath/sas0 OPTIMAL da0 (ACTIVE) > da4 (READ) > > When I issue a > zpool create data /dev/multipath/sas0 > command, zpool starts to eat 100% CPU: > # procstat -k 3924 > PID TID COMM TDNAME KSTACK > 3924 100128 zpool - > > gstat shows that there is one uncompleted read IO on multipath/sas0 and > the queue length constantly grows on da0: > # gstat -b > dT: 1.030s w: 1.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name > 124402 146 0 0 0.0 0 0 0.0 100.5 da0 > I can use these devices finely with dd. > > What's going on here? I have a hunch. Try sysctl vfs.zfs.vdev.trim_on_init=0 before zpool create? From owner-freebsd-stable@FreeBSD.ORG Thu Dec 18 18:44:34 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 AB8CDC59 for ; Thu, 18 Dec 2014 18:44:34 +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 3D8B22C57 for ; Thu, 18 Dec 2014 18:44:34 +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 sBIIiUpa021117 for ; Thu, 18 Dec 2014 19:44:30 +0100 (CET) (envelope-from freebsd@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 68C6B31E7; Thu, 18 Dec 2014 19:44:30 +0100 (CET) Message-ID: <5493208E.7040201@omnilan.de> Date: Thu, 18 Dec 2014 19:44:30 +0100 From: Harry 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 Mailing List Subject: pkg-1.4-0 signal-4-exit with core-avx-i; FreeBSD:10:i386 vs. FreeBSD:10:32? Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Thu, 18 Dec 2014 19:44:30 +0100 (CET) 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, 18 Dec 2014 18:44:34 -0000 Hello, surprisingly my deployment process fails with: pkg: file:///media/OAK_PKG_CD/packages/FreeBSD:10:i386/meta.txz: No such file or directory I never had any problems with my scripts with pkg-1.3.8. It looks that FreeBSD:10:32 was renamed to FreeBSD:10:i386, right? Now pkg-1.4.0 is mandatory. Not mentioned in UPDATING, no help how to define previous version … :-( pkg-1.4.0 core dumps when compiled with CPUTYPE=core-avx-i on an Ivy-Bridge host and run on a Haswell system (both ESXi-guest and both stable/10, r275903) :-( This is not very helpful, I know, sorry, but I don't have time to investigate – I was about to do some quick updates… I strongly vote for pkg integration into base with the usual maintenance quality. The current circular dependency caused too much problems since pkg_legacy was abandoned. A planned one-hour-task again takes me 10 hours because of fundamental changes I cannot easily revert or were announced/tested. Thanks, -Harry From owner-freebsd-stable@FreeBSD.ORG Thu Dec 18 19:30:52 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 F1F2DF64 for ; Thu, 18 Dec 2014 19:30:52 +0000 (UTC) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "people.fsn.hu", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9A6F1145A for ; Thu, 18 Dec 2014 19:30:51 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 05E4F156B2FF; Thu, 18 Dec 2014 20:30:47 +0100 (CET) X-Bogosity: Ham, tests=bogofilter, spamicity=0.074367, version=1.2.3 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 10.2453] X-CRM114-CacheID: sfid-20141218_20304_B8A09715 X-CRM114-Status: Good ( pR: 10.2453 ) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Thu Dec 18 20:30:47 2014 X-DSPAM-Confidence: 0.9957 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 54932b6784632623875237 X-DSPAM-Factors: 27, From*"Nagy, Attila" , 0.00010, >+On, 0.00043, wrote+>>, 0.00103, wrote+>, 0.00180, >>+I, 0.00264, Nagy+Attila, 0.00279, >+I, 0.00308, disks, 0.00335, zfs, 0.00386, zfs, 0.00386, queue, 0.00386, Received*(japan.t, 0.00418, Received*online.co.hu+[195.228.243.99]), 0.00456, Received*[195.228.243.99]), 0.00456, Received*online.co.hu, 0.00456, Received*(japan.t+online.co.hu, 0.00456, IO, 0.00501, >>+>>, 0.00516, >>+>>, 0.00516, sysctl, 0.00557, References*fsn.hu>, 0.00557, the+default, 0.00557, wrote, 0.00680, wrote, 0.00680, the+queue, 0.00833, here?, 0.00997, X-Spambayes-Classification: ham; 0.00 Received: from [IPv6:::1] (japan.t-online.co.hu [195.228.243.99]) by people.fsn.hu (Postfix) with ESMTPSA id 5C0EA156B2E8; Thu, 18 Dec 2014 20:30:44 +0100 (CET) Message-ID: <54932B63.5030207@fsn.hu> Date: Thu, 18 Dec 2014 20:30:43 +0100 From: "Nagy, Attila" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Adam McDougall , freebsd-stable@freebsd.org Subject: Re: geom_multipath and zfs doesn't work References: <5493090D.2030406@fsn.hu> <549312F6.1070007@egr.msu.edu> In-Reply-To: <549312F6.1070007@egr.msu.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 19:30:53 -0000 Hi, On 12/18/14 18:46, Adam McDougall wrote: > On 12/18/2014 12:04, Nagy, Attila wrote: >> Running stable/10@r273159 on FC disks (through isp) I can't create a zfs >> pool. >> >> gstat shows that there is one uncompleted read IO on multipath/sas0 and >> the queue length constantly grows on da0: >> # gstat -b >> dT: 1.030s w: 1.000s >> L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name >> 124402 146 0 0 0.0 0 0 0.0 100.5 da0 >> I can use these devices finely with dd. >> >> What's going on here? > I have a hunch. Try sysctl vfs.zfs.vdev.trim_on_init=0 before zpool create? > Bingo, that's it. If I disable this, zpool create returns immediately. BTW, zpool create took 1 hour and 11 minutes with the default value... Thank you very much for the quick response! From owner-freebsd-stable@FreeBSD.ORG Fri Dec 19 00:29: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 9687C333 for ; Fri, 19 Dec 2014 00:29:49 +0000 (UTC) Received: from mail.ultra-secure.de (mail.ultra-secure.de [88.198.178.88]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D9CC62538 for ; Fri, 19 Dec 2014 00:29:48 +0000 (UTC) Received: (qmail 52458 invoked by uid 89); 19 Dec 2014 00:27:30 -0000 Received: from unknown (HELO ?192.168.1.200?) (rainer@ultra-secure.de@217.71.83.52) by mail.ultra-secure.de with ESMTPA; 19 Dec 2014 00:27:30 -0000 From: Rainer Duffner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: FreeBSD 10.1-amd64 -> booting on a HP DL380 Gen9 results in panic Message-Id: Date: Fri, 19 Dec 2014 01:27:13 +0100 To: freebsd-stable Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) 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, 19 Dec 2014 00:29:49 -0000 Hi, we got one to test and it booted using the UEFI memory stick image. However, I get a panic after Event time =E2=80=9ELAPIC=E2=80=9C quality 600 ACPI APIC Table: panic: APIC: CPU with APIC ID 0 is not enabled cpuid =3D 0 and then a stack backtrace What does that mean? AFAIK, I have a single E5-2620V3 CPU and 16 GB RAM in there. It=E2=80=99s primarily intended as a test-system - but earlier or later = I will have to put one into production because we=E2=80=99ll likely stop = procuring Gen8 systems sometime next year (when they simply stop = becoming available). I haven=E2=80=99t tried a snapshot of current. Rainer= From owner-freebsd-stable@FreeBSD.ORG Fri Dec 19 02:04:55 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 8F2C8965 for ; Fri, 19 Dec 2014 02:04:55 +0000 (UTC) Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.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 4CBF5383 for ; Fri, 19 Dec 2014 02:04:54 +0000 (UTC) Received: by mail-qg0-f46.google.com with SMTP id q107so85175qgd.5 for ; Thu, 18 Dec 2014 18:04:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=l1IHaFJ8wT3VGG26PjrGiKsbrEKUhMmhjTYZ7HNnwAs=; b=hz9QbHSygETQTiz70MvJiPej448jUItOa8ePbjXxIKlzsudWtloMG0qATTDPRC/OQr cOp7G/fPx/Np8lyi/nFQ8eUtzu10bPSNNM1rbFbuXsVMLkPd6aJVo7ibgaC/HrqsSL5X o1FFdktvDq15NfbXw4Sj0XZAjhDsadXobxhn83pzCM7WRVvITCUy3nONkd3u671R5v4z 2RLZm/oGUbm8lnJKACdb4jCkc4f0TY2CdHzxbpIp2ZGUM0q7+i8gu7axT+7VidhAJKSS dPyP+D6MpLVRi5z/6O2p/esqy1WVS/hR9GMv4XT6FCmaNxH54Ggb1SJEePGMB3Dl8bey WCBg== X-Gm-Message-State: ALoCoQnYJwDtCnQeEl2PIWDXZsOS84GKfhepwUC0YqUo9vsFUDueplQ7qjzeKlnGyJiuZkfRH5qn X-Received: by 10.224.55.145 with SMTP id u17mr9795090qag.12.1418954693551; Thu, 18 Dec 2014 18:04:53 -0800 (PST) Received: from [192.168.2.20] (ool-182c6c57.dyn.optonline.net. [24.44.108.87]) by mx.google.com with ESMTPSA id k4sm8448812qaf.0.2014.12.18.18.04.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Dec 2014 18:04:52 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: FreeBSD 10.1-amd64 -> booting on a HP DL380 Gen9 results in panic From: Mark Saad X-Mailer: iPhone Mail (12B411) In-Reply-To: Date: Thu, 18 Dec 2014 21:04:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <506CBF31-C4AB-43F6-9FDF-B45209D9CC21@longcount.org> References: To: Rainer Duffner 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, 19 Dec 2014 02:04:55 -0000 > On Dec 18, 2014, at 7:27 PM, Rainer Duffner wrote= : >=20 > Hi, >=20 > we got one to test and it booted using the UEFI memory stick image. >=20 > However, I get a panic after > Event time =E2=80=9ELAPIC=E2=80=9C quality 600 > ACPI APIC Table: > panic: APIC: CPU with APIC ID 0 is not enabled > cpuid =3D 0 >=20 > and then a stack backtrace >=20 >=20 > What does that mean? >=20 > AFAIK, I have a single E5-2620V3 CPU and 16 GB RAM in there. >=20 >=20 > It=E2=80=99s primarily intended as a test-system - but earlier or later I w= ill have to put one into production because we=E2=80=99ll likely stop procur= ing Gen8 systems sometime next year (when they simply stop becoming availabl= e). >=20 > I haven=E2=80=99t tried a snapshot of current Did you try disabling uefi and using a standard boot image ? Also this could= be a hp firmware bug are you running the latest bios / spp ?=20 Mark=20 >=20 > Rainer > _______________________________________________ > 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 Dec 19 13:28: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 CD6E2706 for ; Fri, 19 Dec 2014 13:28:06 +0000 (UTC) Received: from mx1.informatik.uni-stuttgart.de (mailgw.informatik.uni-stuttgart.de [129.69.211.41]) by mx1.freebsd.org (Postfix) with ESMTP id 927091639 for ; Fri, 19 Dec 2014 13:28:06 +0000 (UTC) Received: from azu.informatik.uni-stuttgart.de (azu.informatik.uni-stuttgart.de [129.69.218.66]) by mx1.informatik.uni-stuttgart.de (Postfix) with ESMTP id 7D8E87011 for ; Fri, 19 Dec 2014 14:21:11 +0100 (CET) Received: by azu.informatik.uni-stuttgart.de (Postfix, from userid 19691) id 724202E85; Fri, 19 Dec 2014 14:21:02 +0100 (MET) Date: Fri, 19 Dec 2014 14:21:01 +0100 (MET) From: Christian Corti To: freebsd-stable@freebsd.org Subject: New bug with O_CREAT|O_EXCL and NFS? Message-ID: User-Agent: Alpine 2.02 (SUN 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII 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, 19 Dec 2014 13:28:06 -0000 I've had big headaches finding the problem why "ssh -X host" destroys the permissions of the .Xauthority file in my NFS home directory. 'host' is any of our FreeBSD 10.1-RELEASE servers (sparc64 and amd64) Permissions before login: 0600 Permissions after login: 0000 (ouch!) I've found out that the cause for this lies in the Xau library (AuLock.c) that creates a new file in XauLockAuth: [...] creat_fd = open (creat_name, O_WRONLY | O_CREAT | O_EXCL, 0600); [...] Wrote a small test program that makes just that open call, and the result is the same: the created file has permission 0000. This must be a regression, since I have a FreeBSD 9.0-RELEASE-p4 system (amd64) that does *not* have this problem. Is this a known problem? Any hints on solving that problem? For now, I must add a custom /etc/ssh/sshrc file with "chmod 600 ~/.Xauthority". Christian From owner-freebsd-stable@FreeBSD.ORG Fri Dec 19 15:44:23 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 DF9AF225 for ; Fri, 19 Dec 2014 15:44:23 +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 6F0952E80 for ; Fri, 19 Dec 2014 15:44:23 +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 sBJFiJlU031065 for ; Fri, 19 Dec 2014 16:44:19 +0100 (CET) (envelope-from freebsd@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 7B3F733FD; Fri, 19 Dec 2014 16:44:19 +0100 (CET) Message-ID: <549447D2.7080804@omnilan.de> Date: Fri, 19 Dec 2014 16:44:18 +0100 From: Harry 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 Mailing List Subject: New in pkg-1.4-0 pkg: unlinkat(usr/local/): Read-only file system [Was: pkg-1.4-0 signal-4-exit with core-avx-i; FreeBSD:10:i386 vs. FreeBSD:10:32?] References: <5493208E.7040201@omnilan.de> In-Reply-To: <5493208E.7040201@omnilan.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: ACL 119 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Fri, 19 Dec 2014 16:44:19 +0100 (CET) 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: Fri, 19 Dec 2014 15:44:24 -0000 Bezüglich Harry Schmalzbauer's Nachricht vom 18.12.2014 19:44 (localtime): > Hello, > > surprisingly my deployment process fails with: > pkg: file:///media/OAK_PKG_CD/packages/FreeBSD:10:i386/meta.txz: No such > file or directory > > I never had any problems with my scripts with pkg-1.3.8. It looks that > FreeBSD:10:32 was renamed to FreeBSD:10:i386, right? After adjusting my scripts to handle the new ABI, I now see the another pkg(8) surprise: 'pkg delete -f pkg' [1/1] Deinstalling pkg-1.4.0... [1/1] Deleting files for pkg-1.4.0: 100% pkg: unlinkat(usr/local/): Read-only file system pkg: unlinkat(usr/): Read-only file system pkg: unlinkat(usr/local/): Read-only file system pkg: unlinkat(usr/): Read-only file system … (repeted) It's true that "/" is read-only, but "/usr/local" is rw of course. pkg(8) mustn't touch anything on "/" for most packages, which is true for "pkg" itself. Can somebody explain the cause of these error messages with pkg-1.4.0? Thanks, -Harry From owner-freebsd-stable@FreeBSD.ORG Fri Dec 19 16:06:35 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 6A52C716 for ; Fri, 19 Dec 2014 16:06: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 F2EB71437 for ; Fri, 19 Dec 2014 16:06:34 +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 sBJG6Xve031244 for ; Fri, 19 Dec 2014 17:06:33 +0100 (CET) (envelope-from freebsd@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 E73233405; Fri, 19 Dec 2014 17:06:32 +0100 (CET) Message-ID: <54944D08.8000202@omnilan.de> Date: Fri, 19 Dec 2014 17:06:32 +0100 From: Harry 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 Mailing List Subject: CPUTYPEs includig avx are suspicious with clang in stable/10 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Fri, 19 Dec 2014 17:06:33 +0100 (CET) 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: Fri, 19 Dec 2014 16:06:35 -0000 I'm seeing sporadic problems (core dumps) with binaries compiled with CPUTYPE=core-i-avx. They run fine on IvyBridge, but fail on Haswells. Stripping avx from MACHINE_CPU (by defining CPUTYPE=corei7 instead of core-i-avx) solved all crashes on the haswell system. I have no idea if applications like pkg(8) make use of AVX, I'd bet they don't do. So I guess it's something wrong with clang. Unfortuantely I currently don't have a development installation on any haswell system to provide some useful backtraces, but perhaps somebody with compiler knowledge can have a look at this problem? Thanks, -Harry From owner-freebsd-stable@FreeBSD.ORG Fri Dec 19 18:27: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 B4A56A9B for ; Fri, 19 Dec 2014 18:27:10 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id A2EF52DBA for ; Fri, 19 Dec 2014 18:27:10 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 403706CE for ; Fri, 19 Dec 2014 18:27:10 +0000 (UTC) Date: Fri, 19 Dec 2014 18:27:07 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-stable@freebsd.org Message-ID: <1279332077.43.1419013627861.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <805885612.42.1419004003694.JavaMail.jenkins@jenkins-9.freebsd.org> References: <805885612.42.1419004003694.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : Build-UFS-image #716 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: Build-UFS-image X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 18:27:10 -0000 See From owner-freebsd-stable@FreeBSD.ORG Fri Dec 19 22:43: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 5C11D25B for ; Fri, 19 Dec 2014 22:43:25 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 20EB4203D for ; Fri, 19 Dec 2014 22:43:24 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4EAEuplFSDaFve/2dsb2JhbABag1hYBIMBwx4KhSdKAoEsAQEBAQF9hAwBAQEDAQEBASArIAsFFhgCAg0FARMCKQEJJgYIBwQBHASIAwgNum+WLwEBAQEBAQQBAQEBAQEBAQEZgSGOAAEBGzQHEgGCVYFBBYlFiAaDHhmDCjCCMoVzhC2DOSKEDCAxAQZ+BxcifgEBAQ X-IronPort-AV: E=Sophos;i="5.07,609,1413259200"; d="scan'208";a="178075497" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 19 Dec 2014 17:43:18 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 881B9B4040; Fri, 19 Dec 2014 17:43:18 -0500 (EST) Date: Fri, 19 Dec 2014 17:43:18 -0500 (EST) From: Rick Macklem To: Christian Corti Message-ID: <376853369.1281572.1419028998536.JavaMail.root@uoguelph.ca> In-Reply-To: Subject: Re: New bug with O_CREAT|O_EXCL and NFS? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.12] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) 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, 19 Dec 2014 22:43:25 -0000 Christian Corti wrote: > I've had big headaches finding the problem why "ssh -X host" destroys > the > permissions of the .Xauthority file in my NFS home directory. > 'host' is any of our FreeBSD 10.1-RELEASE servers (sparc64 and amd64) > Permissions before login: 0600 > Permissions after login: 0000 (ouch!) > > I've found out that the cause for this lies in the Xau library > (AuLock.c) > that creates a new file in XauLockAuth: > [...] > creat_fd = open (creat_name, O_WRONLY | O_CREAT | O_EXCL, 0600); > [...] > > Wrote a small test program that makes just that open call, and the > result > is the same: the created file has permission 0000. > > This must be a regression, since I have a FreeBSD 9.0-RELEASE-p4 > system > (amd64) that does *not* have this problem. > > Is this a known problem? Any hints on solving that problem? For now, > I > must add a custom /etc/ssh/sshrc file with "chmod 600 ~/.Xauthority". > If you are using a Solaris NFS server then, yes, it is a known bug in the Solaris NFS server. See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193128 If you are not using a Solaris server, then this needs to be investigated further, since I am only aware of the Solaris server case. As you'll see in the bug report, the Solaris server replies NFS_OK to the Setattr, but does not set the mode. If you change the client to specify "use server time" for the time setting, then the Solaris server does set the file mode. Until I add a mount option in the client to force "use server's time" workarounds are: - Use a non-Solaris NFS server. - Use NFSv2, which seems to work ok. ("nfsv2" or "vers=2" mount option) - Hack your kernel with the patch in the bug report. Please let us know if you are using a Solaris server? Thanks, rick > Christian > _______________________________________________ > 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" >