From owner-freebsd-current@FreeBSD.ORG Sun Oct 12 08:35:13 2014 Return-Path: Delivered-To: freebsd-current@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 2FD1C98D for ; Sun, 12 Oct 2014 08:35:13 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DD74A8EE for ; Sun, 12 Oct 2014 08:35:12 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XdEcK-0000wA-5f for freebsd-current@freebsd.org; Sun, 12 Oct 2014 10:35:04 +0200 Received: from ip5b42e0b8.dynamic.kabel-deutschland.de ([ip5b42e0b8.dynamic.kabel-deutschland.de]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 12 Oct 2014 10:35:04 +0200 Received: from holger by ip5b42e0b8.dynamic.kabel-deutschland.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 12 Oct 2014 10:35:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Holger Freyther Subject: Re: Buildworld Failure Date: Sun, 12 Oct 2014 07:58:35 +0000 (UTC) Lines: 18 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 91.66.224.184 (Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.120 Safari/537.36) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2014 08:35:13 -0000 Shawn Webb gmail.com> writes: Good Morning, > make[5]: make[5]: don't know how to make > /jenkins/usr/local/jenkins/workspace/HardenedBSD- Master/rescue/rescue//usr/local/jenkins/workspace/HardenedBSD- Master/bin/cat/cat.o. I am facing the same issue and it seems to be related to setting a custom MAKEOBJDIRPREFIX when building. Did you find a solution to your problem other than disabling building rescue? holger From owner-freebsd-current@FreeBSD.ORG Mon Oct 13 02:07:14 2014 Return-Path: Delivered-To: freebsd-current@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 17CC451A; Mon, 13 Oct 2014 02:07:14 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 06B938C8; Mon, 13 Oct 2014 02:07:14 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 6E721A60; Mon, 13 Oct 2014 02:07:14 +0000 (UTC) Date: Mon, 13 Oct 2014 02:07:12 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, yongari@FreeBSD.org, jch@FreeBSD.org, jhibbits@FreeBSD.org, ngie@FreeBSD.org, mav@FreeBSD.org, hrs@FreeBSD.org Message-ID: <2040945122.30.1413166034409.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #1617 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 02:07:14 -0000 See Changes: [ngie] Do initial port of contrib/netbsd-tests/lib/libc/locale t_io: - Expect failures potentially related to implementation-specific knowledge of the zh_TW.Big5 locale [*] t_mbrtowc: - Handle unknown locales more gracefully (do not test if the locale doesn't exist) - Expect failure with mbrtowc_internal dealing with Japanese locales (potentially related to implementation detail knowledge of the ja_* locales) [*]. t_mbstowcs, t_mbtowc, t_wctomb: - Handle unknown locales more gracefully (do not test if the locale doesn't exist) t_wcstod: - Treat FreeBSD like NetBSD and Linux in the XXX: FIXME section [*] More investigation is required to determine the root cause of the failures Submitted by: pho Sponsored by: EMC / Isilon Storage Division [yongari] Remove ALC_LOCK_ASSERT in alc_stop_queue(). This function is now called in device attach without holding a driver lock so it resulted in panic. Reported by: markj [ngie] Add #include for printf Sponsored by: EMC / Isilon Storage Division [jhibbits] Check error return from reading integer part of temperature. There's a very remote, but possible, chance that the integer part read will fail, but the fraction read succeeds, at which point the reported temperature is invalid. Reported by: Matthew Rezny MFC after: 3 weeks [ngie] Expect nice_err to fail on FreeBSD with unprivileged users PR: 189821 Sponsored by: EMC / Isilon Storage Division [jch] A connection in TIME_WAIT state before calling close() actually did not received any RST packet. Do not set error to ECONNRESET in this case. Differential Revision: https://reviews.freebsd.org/D879 Reviewed by: rpaulo, adrian Approved by: jhb (mentor) Sponsored by: Verisign, Inc. [hrs] s/-/_/ in name. [ngie] - Add libutil #include for fparseln - Change ATF_REQUIRE_EQ_MSG to ATF_CHECK_EQ_MSG to gather all failing results possible (currently 12 with leftassoc) - Mark leftassoc "atf_tc_expect_fail" on FreeBSD (PR coming soon after further analysis is done on the code) In collaboration with: pho Sponsored by: EMC / Isilon Storage Division [ngie] Fix compilation errors with missing wide-type headers and fix compilation warnings with -Wformat In collaboration with: pho Sponsored by: EMC / Isilon Storage Division [ngie] Implement 64MB memory limit for test to ensure that it fails reliably in 600 seconds; it would previously fail inconsistently when run in some virtual machine configurations This patch might need to be reverted or revisited later (see the attached PR for more details) PR: 169302 Submitted by: pho Sponsored by: EMC / Isilon Storage Division [jhibbits] Add an AC line monitor so power_profile can work Summary: Add a polling loop (1Hz) to monitor the battery and AC status, to notify devd like ACPI does for power monitoring. This allows /etc/rc.d/power_profile to work on PowerPC laptops Test Plan: Tested on a Titanium PowerBook, configuring economy_cpu_freq and performance_cpu_freq, disabling powerd. Reviewers: #powerpc, nwhitehorn Reviewed By: nwhitehorn Subscribers: rpaulo Differential Revision: https://reviews.freebsd.org/D937 [mav] Remove stale comments. ------------------------------------------ Started by user rodrigc Building remotely on jenkins-10.freebsd.org (FreeBSD-10) in workspace Updating svn://svn.freebsd.org/base/head at revision '2014-10-13T02:05:27.126 +0000' U contrib/netbsd-tests/lib/libc/locale/t_mbstowcs.c U contrib/netbsd-tests/lib/libc/locale/t_wcstod.c U contrib/netbsd-tests/lib/libc/locale/t_io.c U contrib/netbsd-tests/lib/libc/locale/t_mbtowc.c U contrib/netbsd-tests/lib/libc/locale/t_wctomb.c U contrib/netbsd-tests/lib/libc/locale/t_mbrtowc.c U contrib/netbsd-tests/lib/libc/gen/t_nice.c U contrib/netbsd-tests/lib/libc/regex/t_exhaust.c U contrib/netbsd-tests/lib/libc/regex/t_regex_att.c U contrib/netbsd-tests/lib/libc/regex/debug.c U etc/devd/apple.conf U etc/rc.d/bgfsck U sys/dev/alc/if_alc.c U sys/dev/iicbus/max6690.c U sys/powerpc/powermac/pmu.c U sys/cam/ctl/scsi_ctl.c U sys/netinet/tcp_usrreq.c At revision 273019 [FreeBSD_HEAD] $ /bin/sh -xe /tmp/hudson5455479227585742006.sh + cat + make -j 4 buildworld __MAKE_CONF= make: " line 1: Need an operator make: Fatal errors encountered -- cannot continue make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Mon Oct 13 02:09:47 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F759668; Mon, 13 Oct 2014 02:09:46 +0000 (UTC) Date: Mon, 13 Oct 2014 02:09:41 +0000 From: Glen Barber To: jenkins-admin@freebsd.org Subject: Re: Build failed in Jenkins: FreeBSD_HEAD #1617 Message-ID: <20141013020941.GW26035@hub.FreeBSD.org> References: <2040945122.30.1413166034409.JavaMail.jenkins@jenkins-9.freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AAkN98o3X3ouhQaz" Content-Disposition: inline In-Reply-To: <2040945122.30.1413166034409.JavaMail.jenkins@jenkins-9.freebsd.org> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 02:09:48 -0000 --AAkN98o3X3ouhQaz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 13, 2014 at 02:07:12AM +0000, jenkins-admin@freebsd.org wrote: > See >=20 > [...] > Started by user rodrigc > Building remotely on jenkins-10.freebsd.org (FreeBSD-10) in workspace > Updating svn://svn.freebsd.org/base/head at revision '2014-10-13T02:05:27= =2E126 +0000' > U contrib/netbsd-tests/lib/libc/locale/t_mbstowcs.c > U contrib/netbsd-tests/lib/libc/locale/t_wcstod.c > U contrib/netbsd-tests/lib/libc/locale/t_io.c > U contrib/netbsd-tests/lib/libc/locale/t_mbtowc.c > U contrib/netbsd-tests/lib/libc/locale/t_wctomb.c > U contrib/netbsd-tests/lib/libc/locale/t_mbrtowc.c > U contrib/netbsd-tests/lib/libc/gen/t_nice.c > U contrib/netbsd-tests/lib/libc/regex/t_exhaust.c > U contrib/netbsd-tests/lib/libc/regex/t_regex_att.c > U contrib/netbsd-tests/lib/libc/regex/debug.c > U etc/devd/apple.conf > U etc/rc.d/bgfsck > U sys/dev/alc/if_alc.c > U sys/dev/iicbus/max6690.c > U sys/powerpc/powermac/pmu.c > U sys/cam/ctl/scsi_ctl.c > U sys/netinet/tcp_usrreq.c > At revision 273019 > [FreeBSD_HEAD] $ /bin/sh -xe /tmp/hudson5455479227585742006.sh > + cat > + make -j 4 buildworld __MAKE_CONF=3D > make: "; Sun, 12 Oct 2014 19:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=OqCH5XbFUh4WQpAtI0g2k66QSHajkAHO6ie48ncp/qk=; b=sd5pC0M/yKgic7CRmBzNKNXiobnZK+u8d+cRi9iN0Ze32Yta5V5JxL0yT896TQH7SS SsAmxUqntge2sooXV9LYFFjKklK4j+UoEYlxMStAQzShhH54DksMST5I51RBgkpheRHB QvuSnmR9ZPdmuDx3eEDcDwvtyLeuCWITZ5MlDPA3dNmLbY8IGRwAPHxJW32HLlY/pjuY ndB+lfm7SwJns1GvBQFrf/qyj1Sk9G6UhlfoguItK/uCPECh/5sAtuczZHQRVME+OpUp keVCraGEUgDQbfc1zJ3BID8kyCMXjldPdYaChsK/b2zkgrncSY5nVBlIWPP+8u17PwSd XJuQ== X-Received: by 10.68.234.225 with SMTP id uh1mr4495122pbc.13.1413168005232; Sun, 12 Oct 2014 19:40:05 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:3158:a83c:dca7:c7bc? ([2601:8:ab80:7d6:3158:a83c:dca7:c7bc]) by mx.google.com with ESMTPSA id cn1sm9677584pdb.13.2014.10.12.19.40.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 12 Oct 2014 19:40:04 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_8FF0D9DA-6961-4723-8F75-E02224560270"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Build failed in Jenkins: FreeBSD_HEAD #1617 From: Garrett Cooper In-Reply-To: <20141013020941.GW26035@hub.FreeBSD.org> Date: Sun, 12 Oct 2014 19:40:03 -0700 Message-Id: References: <2040945122.30.1413166034409.JavaMail.jenkins@jenkins-9.freebsd.org> <20141013020941.GW26035@hub.FreeBSD.org> To: Glen Barber X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current@freebsd.org, jenkins-admin@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 02:40:06 -0000 --Apple-Mail=_8FF0D9DA-6961-4723-8F75-E02224560270 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 12, 2014, at 19:09, Glen Barber wrote: > On Mon, Oct 13, 2014 at 02:07:12AM +0000, jenkins-admin@freebsd.org = wrote: >> See = >>=20 >> [...] >=20 >> Started by user rodrigc >> Building remotely on jenkins-10.freebsd.org (FreeBSD-10) in workspace = >> Updating svn://svn.freebsd.org/base/head at revision = '2014-10-13T02:05:27.126 +0000' >> U contrib/netbsd-tests/lib/libc/locale/t_mbstowcs.c >> U contrib/netbsd-tests/lib/libc/locale/t_wcstod.c >> U contrib/netbsd-tests/lib/libc/locale/t_io.c >> U contrib/netbsd-tests/lib/libc/locale/t_mbtowc.c >> U contrib/netbsd-tests/lib/libc/locale/t_wctomb.c >> U contrib/netbsd-tests/lib/libc/locale/t_mbrtowc.c >> U contrib/netbsd-tests/lib/libc/gen/t_nice.c >> U contrib/netbsd-tests/lib/libc/regex/t_exhaust.c >> U contrib/netbsd-tests/lib/libc/regex/t_regex_att.c >> U contrib/netbsd-tests/lib/libc/regex/debug.c >> U etc/devd/apple.conf >> U etc/rc.d/bgfsck >> U sys/dev/alc/if_alc.c >> U sys/dev/iicbus/max6690.c >> U sys/powerpc/powermac/pmu.c >> U sys/cam/ctl/scsi_ctl.c >> U sys/netinet/tcp_usrreq.c >> At revision 273019 >> [FreeBSD_HEAD] $ /bin/sh -xe /tmp/hudson5455479227585742006.sh >> + cat >> + make -j 4 buildworld = __MAKE_CONF=3D >> make: = " = line 1: Need an operator >> make: Fatal errors encountered -- cannot continue >> make: stopped in = >> Build step 'Execute shell' marked build as failure >=20 > FWIW, output showing what the make.conf contains would be helpful. Is the command using the URL for make.conf as __MAKE_CONF? --Apple-Mail=_8FF0D9DA-6961-4723-8F75-E02224560270 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUOzuDAAoJEMZr5QU6S73ej0YIAI/mHz8HYVzksGOJT/4fBZ0p 0NQBRAmZqIuXs2jlhjJonbrquATkL9LXlFMA8u6x6ZW3+Hhk9jmrPjTIYarXbTlQ RjTbzPpx7TsByiAhvslEfrRteDg0DfGKhZDQkhJtb5gZJMJMTGwWodsn16WqOuNU 0ujX4T8LYO76eiUwQjkLC7MvG1bJPx8I2+Wzw+VFW5BVz/BiqYdmP/R5z3onbseE AlxgcieONCD6gLEKMaPZqYEJ5XVODY3FQbhVoSu/Ii+JUa4l/iIK3c+5yVhIjcGl ndJVUkDtNtdbNyUM72iXxNZAN44jI1tuVeOv8RH1lwzG3tr59lOG2TLYHj1BzQY= =Ml65 -----END PGP SIGNATURE----- --Apple-Mail=_8FF0D9DA-6961-4723-8F75-E02224560270-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 13 05:22:32 2014 Return-Path: Delivered-To: freebsd-current@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 ACD09A99; Mon, 13 Oct 2014 05:22:32 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 9968CD69; Mon, 13 Oct 2014 05:22:32 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id C7D66AD1; Mon, 13 Oct 2014 05:22:32 +0000 (UTC) Date: Mon, 13 Oct 2014 05:22:31 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, yongari@FreeBSD.org, jch@FreeBSD.org, jhibbits@FreeBSD.org, mav@FreeBSD.org, ngie@FreeBSD.org, hrs@FreeBSD.org Message-ID: <837593042.32.1413177752792.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <790255440.31.1413166573563.JavaMail.jenkins@jenkins-9.freebsd.org> References: <790255440.31.1413166573563.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD #1619 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 05:22:32 -0000 See From owner-freebsd-current@FreeBSD.ORG Mon Oct 13 11:29:54 2014 Return-Path: Delivered-To: current@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 D8DDD594 for ; Mon, 13 Oct 2014 11:29:54 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9406C640 for ; Mon, 13 Oct 2014 11:29:54 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id s9DBTnfY024882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 13 Oct 2014 04:29:52 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <543BB7A7.9080709@freebsd.org> Date: Mon, 13 Oct 2014 19:29:43 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: FreeBSD Current Subject: number of args in a syscall Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 11:29:54 -0000 I'm faced with porting some code that has patched the 8.0 kernel to accept up to 16 args in a syscall. It makes my skin crawl a bit but if I can't give a good reason to suggest that they do things differently in 10 (pass a pointer to a struct maybe) then I'll just take the easy path and s/8/16/ in the appropriate line in amd64/include/proc.h and get on with life. I initially thought it may confuse things like ktrace or truss but I haven't seen any problems.. allocating more space on the stack is another thing but you only ever do one syscall at a time. Julian From owner-freebsd-current@FreeBSD.ORG Mon Oct 13 14:14:27 2014 Return-Path: Delivered-To: current@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 C3474A9E; Mon, 13 Oct 2014 14:14:27 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2DD48A49; Mon, 13 Oct 2014 14:14:26 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s9DEELl5049029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2014 17:14:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s9DEELl5049029 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s9DEELWu049028; Mon, 13 Oct 2014 17:14:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 13 Oct 2014 17:14:21 +0300 From: Konstantin Belousov To: Julian Elischer Subject: Re: number of args in a syscall Message-ID: <20141013141420.GM2153@kib.kiev.ua> References: <543BB7A7.9080709@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <543BB7A7.9080709@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 14:14:27 -0000 On Mon, Oct 13, 2014 at 07:29:43PM +0800, Julian Elischer wrote: > I'm faced with porting some code that has patched the 8.0 kernel > to accept up to 16 args in a syscall. > It makes my skin crawl a bit but if I can't give a good reason to > suggest that they do things differently in 10 (pass a pointer to a > struct maybe) > then I'll just take the easy path and s/8/16/ in > the appropriate line in amd64/include/proc.h and get on with life. It should work; I assume this is for your local modifications. A fine point in the amd64 (syscall) calling sequence is that first 6 integer arguments are passed in registers, everything else and more overflows to memory. Syscall parameters passing conventions are very similar of the conventions for the regular functions, stubs do very little. The syscall arg fetch code does distinguish the registers/memory args and performs copyin for memory portion, see cpu_fetch_syscall_args(). > > I initially thought it may confuse things like ktrace or truss but I > haven't seen any problems.. > allocating more space on the stack is another thing but you only ever > do one syscall at a time. The difference in the stack usage for 8 vs.16 args would be around 100-200 bytes. From owner-freebsd-current@FreeBSD.ORG Mon Oct 13 15:38:00 2014 Return-Path: Delivered-To: freebsd-current@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 2C5AAAA6 for ; Mon, 13 Oct 2014 15:38:00 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 057AB322 for ; Mon, 13 Oct 2014 15:37:59 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 071F026BE9 for ; Mon, 13 Oct 2014 15:37:52 +0000 (UTC) Message-ID: <543BF1D4.5060403@freebsd.org> Date: Mon, 13 Oct 2014 11:37:56 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Proposal for adding "firewall_myservices_udp" in etc/rc.conf References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pJ2meS2w1JSmOi83bNcdHBbacQQsmKQ9O" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 15:38:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pJ2meS2w1JSmOi83bNcdHBbacQQsmKQ9O Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2014-10-10 16:38, Olivier Cochard-Labb=E9 wrote: > For a simple workstation, we can use this simple configuration in > /etc/rc.conf: > firewall_type=3D"workstation" > firewall_enable=3D"YES" > firewall_myservices=3D"22,80" > firewall_allowservices=3D"any" >=20 > But the firewall_myservices allows only TCP services. > It's not possible to declare UDP services (like a torrent client). >=20 > This patch propose to add UDP services by 2 changes: > 1. firewall_myservices became a deprecated alias, the new is > firewall_myservices_tcp > 2. A new firewall_myservices_udp variable is added. >=20 > Patch attached to PR194292: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D194292 >=20 > What do you think ? > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 I see this as quite reasonable. I'll add some notes about it to the handbook if the patch is accepted. --=20 Allan Jude --pJ2meS2w1JSmOi83bNcdHBbacQQsmKQ9O Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJUO/HXAAoJEJrBFpNRJZKfps0QAK+kVRQ2ZvNWKtbYvanV6J+y kbvnHPL9llVcrJIHC7NOmE0aZ+MdaZMmjtRubqtdlxaItwU6t17G/Qdr/Hjx879z 8BTmM1reHaS9oWPj/j+m25Pc0lJBNtk/Vp5g4Cvces85xF12/dEC+mqmHp6jhFFy iWL/HVkLSlD1KP0raLGB0wuQ58vUWlSIfhSqT2voIrxT2MjJ24r//Hpcm9QFUnqE cFR9kWQjQzKWwQ+eb5zLWnj/6o34NnswozPSjjJ8qh+0Jz3Yp+6s2fNritDjahxa 5VYgXho8MatHceKdY8zKuRxp4sYhQCBuIw9K9ggsMdkT51hfJJFz8PCH/RRDOYGr dfaVjNC/4IGs+HfVv/F8vXmgd+kP2r4ONXGBVaNWFpoqqPCX10Zfp/pSKOEuWXpe sCR+WcIh4od0jhvtKCUQG99kaCP/N34IDbtijoLZ8fxUuwpWmI23ExMyDbWD9g2b wNoelPBkJqXnMqZtcoY6CvW5dzymeKps+VOL6NeXvKueAF4BKCp8vEL0yg5y8U7g zUMKx+SzgZfF2jZm9Z+mY831GPV28H/2UL9YIfP6v8hwFwTI8y35mMvuMUsTU1ix rSm+b5H+llCPZ/ywFB2EA7pLr1EJIWAPLnSfMP01VpJNJVyTuu4CAd2VsYUdiigM ixqK3rdwKtgXPeO8N6sZ =Hlh4 -----END PGP SIGNATURE----- --pJ2meS2w1JSmOi83bNcdHBbacQQsmKQ9O-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 13 17:30:58 2014 Return-Path: Delivered-To: freebsd-current@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 53631BEF for ; Mon, 13 Oct 2014 17:30:58 +0000 (UTC) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D65586D3 for ; Mon, 13 Oct 2014 17:30:57 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id d1so8002770wiv.8 for ; Mon, 13 Oct 2014 10:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=gkLjtwj6BmtO5TVSLI11RflOexP9xc5BdYo2m1Lk+9U=; b=RjNrs5f7jJ1MQ9IYGQaNC9zUYoyTmxDXfhIuJKdDIIQVYzL6Ct8ibQm56Y50itEWH7 rDDW8dZBTsWsHwzfL5GTXdMUGn+exIo4eDZcHtzzu2heJYq1OtkNCqyL6eEO2Z13/czX L/d2lENP4Qn7+M2fuikOY+jgeeG+zEGmJfJMgu1Ak0Cw2UEIHD3WSXj/7PXCtEogYy1D ter88Z1knyOeOubqmqASHtr1y+FRPVDHKiWALISW0X1+LAb5hLHQHRwdKG/Rqrtc4i5r x6F7RdcFIyzvUrlK9+0cO0aLz15ST9TJY4weQ75VDXh0qZW8Sz6slb6Y8HeSO+fd/mAI Wf5w== MIME-Version: 1.0 X-Received: by 10.180.77.229 with SMTP id v5mr381142wiw.59.1413221456201; Mon, 13 Oct 2014 10:30:56 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Mon, 13 Oct 2014 10:30:56 -0700 (PDT) In-Reply-To: References: Date: Mon, 13 Oct 2014 10:30:56 -0700 X-Google-Sender-Auth: AQgLpjST6TkblIzkIKeeAZ6yXGo Message-ID: Subject: Re: Proposal for adding "firewall_myservices_udp" in etc/rc.conf From: Adrian Chadd To: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 17:30:58 -0000 Please add a myservices for IP protocols. I'd like to allow things like GRE so PPTP works. (This is great - now I can have tftp work through the rc.conf firewall!0 Thanks! -a On 10 October 2014 13:38, Olivier Cochard-Labb=C3=A9 w= rote: > For a simple workstation, we can use this simple configuration in > /etc/rc.conf: > firewall_type=3D"workstation" > firewall_enable=3D"YES" > firewall_myservices=3D"22,80" > firewall_allowservices=3D"any" > > But the firewall_myservices allows only TCP services. > It's not possible to declare UDP services (like a torrent client). > > This patch propose to add UDP services by 2 changes: > 1. firewall_myservices became a deprecated alias, the new is > firewall_myservices_tcp > 2. A new firewall_myservices_udp variable is added. > > Patch attached to PR194292: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D194292 > > What do you think ? > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-current@FreeBSD.ORG Mon Oct 13 18:27:57 2014 Return-Path: Delivered-To: freebsd-current@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 51B5DF49 for ; Mon, 13 Oct 2014 18:27:57 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 151F6C44 for ; Mon, 13 Oct 2014 18:27:57 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 4283F1FE022 for ; Mon, 13 Oct 2014 20:27:55 +0200 (CEST) Message-ID: <543C19AD.8070603@selasky.org> Date: Mon, 13 Oct 2014 20:27:57 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: FreeBSD Current Subject: Problem with perl and SVK Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 18:27:57 -0000 Hi, When updating the system to the latest perl and SVK version in ports, I am seeing this: > svk diff . autoused module List::Util has unique import() method at /usr/local/lib/perl5/site_perl/5.16/SVK/Util.pm line 91. BEGIN failed--compilation aborted at /usr/local/lib/perl5/site_perl/5.16/SVK/Util.pm line 91. Compilation failed in require at /usr/local/lib/perl5/5.16/autouse.pm line 53. System information: > pkg info | grep -E "svk|perl" p5-Log-Log4perl-1.42 Log4j implementation for Perl p5-Scalar-List-Utils-1.35,1 Perl subroutines that would be nice to have in the perl core p5-Storable-2.45 Persistency for perl data structures perl5-5.16.3_11 Practical Extraction and Report Language svk-2.2.3_3 Distributed Version Control System Any ideas how to fix? --HPS From owner-freebsd-current@FreeBSD.ORG Mon Oct 13 18:37:06 2014 Return-Path: Delivered-To: freebsd-current@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 11EA369B for ; Mon, 13 Oct 2014 18:37:06 +0000 (UTC) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C5F13D52 for ; Mon, 13 Oct 2014 18:37:05 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XdkUU-00022Z-8B; Mon, 13 Oct 2014 20:37:06 +0200 Date: Mon, 13 Oct 2014 20:37:06 +0200 From: Kurt Jaeger To: Hans Petter Selasky Subject: Re: Problem with perl and SVK Message-ID: <20141013183706.GO29437@home.opsec.eu> References: <543C19AD.8070603@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <543C19AD.8070603@selasky.org> Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 18:37:06 -0000 Hi! > When updating the system to the latest perl and SVK version in ports, I > am seeing this: [...] I'm seeing the same on 10.0p9 and perl 5.20. > Any ideas how to fix? This seems to bringt svk back in the game: cd /usr/local/lib/perl5/site_perl/5.20/SVK vi Util.pm replace use autouse 'List::Util' => qw( max(@) ); with use List::Util; but a short test shows: $ svk Use of uninitialized value $ARGV[0] in ucfirst at /usr/local/lib/perl5/site_perl/5.20/App/CLI/Command.pm line 116. SVK Documentation - Main index: [...] so the root cause is somewhere deeper. -- pi@opsec.eu +49 171 3101372 6 years to go ! From owner-freebsd-current@FreeBSD.ORG Mon Oct 13 18:55:12 2014 Return-Path: Delivered-To: freebsd-current@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 218E3D6 for ; Mon, 13 Oct 2014 18:55:12 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D51A2F44 for ; Mon, 13 Oct 2014 18:55:11 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 8CD1B1FE022; Mon, 13 Oct 2014 20:55:09 +0200 (CEST) Message-ID: <543C200F.90905@selasky.org> Date: Mon, 13 Oct 2014 20:55:11 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Kurt Jaeger Subject: Re: Problem with perl and SVK References: <543C19AD.8070603@selasky.org> <20141013183706.GO29437@home.opsec.eu> In-Reply-To: <20141013183706.GO29437@home.opsec.eu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 18:55:12 -0000 On 10/13/14 20:37, Kurt Jaeger wrote: > Hi! > >> When updating the system to the latest perl and SVK version in ports, I >> am seeing this: > [...] > > I'm seeing the same on 10.0p9 and perl 5.20. > >> Any ideas how to fix? > > This seems to bringt svk back in the game: > > cd /usr/local/lib/perl5/site_perl/5.20/SVK > vi Util.pm > > replace > > use autouse 'List::Util' => qw( max(@) ); > > with > > use List::Util; > > but a short test shows: > > $ svk > Use of uninitialized value $ARGV[0] in ucfirst at /usr/local/lib/perl5/site_perl/5.20/App/CLI/Command.pm line 116. > SVK Documentation - Main index: > [...] > > so the root cause is somewhere deeper. > Hi, Using "use List::Util;" instead of autouse fixes the "svk diff" at least over here. --HPS From owner-freebsd-current@FreeBSD.ORG Mon Oct 13 19:00:54 2014 Return-Path: Delivered-To: freebsd-current@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 670252F1 for ; Mon, 13 Oct 2014 19:00:54 +0000 (UTC) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::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 38391F92 for ; Mon, 13 Oct 2014 19:00:54 +0000 (UTC) Received: by mail-ig0-f176.google.com with SMTP id hn15so11598376igb.9 for ; Mon, 13 Oct 2014 12:00:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pn3TFgWJzX0Na7bvj9y+98wqPycT/aD2sOs0yMocQSk=; b=WCcxYH25Qqur3GduVcBIUNS9FxO5M1MVNzAgzn+sx0C/4ZyNwc2XTQxcTFbwGQCCD1 Y/yKr9bgCoL2XbQOtG8CTiSxRD79fp9kCJ56/6xxnUrO+cMxUmETtwBmhf2k0+YFZAUu /78113Rf7N5JEe9YPWLtEFWB0RK6W6a0aEIkLi1de3tuugkEbDoQ39jyjrw0SIWa0zyN ooJLGyei6IgQO2NoAt2XndnJvBQhHnPikVaZ+u0IHK43PLzPeabCRO/cNFMb8TZHMUEC m6XDSndM9BrsSeZnjOwMvIr4k+QpFDXbzzNaQ3qQLCYilPGp0x1ghBWlei4Q2TamYQYN bXog== MIME-Version: 1.0 X-Received: by 10.50.61.68 with SMTP id n4mr1421536igr.26.1413226853627; Mon, 13 Oct 2014 12:00:53 -0700 (PDT) Received: by 10.50.227.42 with HTTP; Mon, 13 Oct 2014 12:00:53 -0700 (PDT) In-Reply-To: <543C200F.90905@selasky.org> References: <543C19AD.8070603@selasky.org> <20141013183706.GO29437@home.opsec.eu> <543C200F.90905@selasky.org> Date: Mon, 13 Oct 2014 12:00:53 -0700 Message-ID: Subject: Re: Problem with perl and SVK From: NGie Cooper To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 Cc: Kurt Jaeger , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 19:00:54 -0000 On Mon, Oct 13, 2014 at 11:55 AM, Hans Petter Selasky wrote: ... Hi Hans! This sounds like a package dependency / compatibility issue -- please file a ports PR in Bugzilla. Thanks! From owner-freebsd-current@FreeBSD.ORG Mon Oct 13 19:08:06 2014 Return-Path: Delivered-To: freebsd-current@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 6341784F for ; Mon, 13 Oct 2014 19:08:06 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 224D110E for ; Mon, 13 Oct 2014 19:08:05 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id C2BD91FE022; Mon, 13 Oct 2014 21:08:03 +0200 (CEST) Message-ID: <543C2315.7040403@selasky.org> Date: Mon, 13 Oct 2014 21:08:05 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Kurt Jaeger Subject: Re: Problem with perl and SVK References: <543C19AD.8070603@selasky.org> <20141013183706.GO29437@home.opsec.eu> <543C200F.90905@selasky.org> In-Reply-To: <543C200F.90905@selasky.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 19:08:06 -0000 On 10/13/14 20:55, Hans Petter Selasky wrote: > On 10/13/14 20:37, Kurt Jaeger wrote: >> Hi! >> >>> When updating the system to the latest perl and SVK version in ports, I >>> am seeing this: >> [...] >> >> I'm seeing the same on 10.0p9 and perl 5.20. >> >>> Any ideas how to fix? >> >> This seems to bringt svk back in the game: >> >> cd /usr/local/lib/perl5/site_perl/5.20/SVK >> vi Util.pm >> >> replace >> >> use autouse 'List::Util' => qw( max(@) ); >> >> with >> >> use List::Util; >> >> but a short test shows: >> >> $ svk >> Use of uninitialized value $ARGV[0] in ucfirst at >> /usr/local/lib/perl5/site_perl/5.20/App/CLI/Command.pm line 116. >> SVK Documentation - Main index: >> [...] >> >> so the root cause is somewhere deeper. >> > > Hi, > > Using "use List::Util;" instead of autouse fixes the "svk diff" at least > over here. > > --HPS Hi, Seems to work: https://svnweb.freebsd.org/changeset/base/273059 The other perl warning has always been there. Will someone make a patch for the SVK port? --HPS From owner-freebsd-current@FreeBSD.ORG Mon Oct 13 19:10:45 2014 Return-Path: Delivered-To: freebsd-current@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 4FC9E9AC for ; Mon, 13 Oct 2014 19:10:45 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0D4551B8 for ; Mon, 13 Oct 2014 19:10:44 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id BCFD61FE022; Mon, 13 Oct 2014 21:10:42 +0200 (CEST) Message-ID: <543C23B4.3000602@selasky.org> Date: Mon, 13 Oct 2014 21:10:44 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: NGie Cooper Subject: Re: Problem with perl and SVK References: <543C19AD.8070603@selasky.org> <20141013183706.GO29437@home.opsec.eu> <543C200F.90905@selasky.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Kurt Jaeger , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 19:10:45 -0000 On 10/13/14 21:00, NGie Cooper wrote: > On Mon, Oct 13, 2014 at 11:55 AM, Hans Petter Selasky wrote: > > ... > > Hi Hans! > > This sounds like a package dependency / compatibility issue -- please > file a ports PR in Bugzilla. > Hi, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194337 --HPS From owner-freebsd-current@FreeBSD.ORG Tue Oct 14 08:19:49 2014 Return-Path: Delivered-To: freebsd-current@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 10B82DA0 for ; Tue, 14 Oct 2014 08:19:49 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E6C12935 for ; Tue, 14 Oct 2014 08:19:48 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1XdxKY-0004Dc-B3 for freebsd-current@freebsd.org; Tue, 14 Oct 2014 01:19:42 -0700 Date: Tue, 14 Oct 2014 01:19:42 -0700 (PDT) From: Beeblebrox To: freebsd-current@freebsd.org Message-ID: <1413274782325-5956648.post@n5.nabble.com> In-Reply-To: <20141005220221.1ed7df8d@rsbsd.rsb> References: <1412530903064-5954561.post@n5.nabble.com> <20141005183517.GA1073@unixarea.DDR.dd> <20141005220221.1ed7df8d@rsbsd.rsb> Subject: Re: printing text file with LPD - non-printable characters MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 08:19:49 -0000 Enscript does not support UTF-8 formatted text files, so it's not usable in this case. One solution, "is to use paps, instead of Enscript, for converting UTF-8 encoded text to PostScript." http://www.linuxfromscratch.org/blfs/view/svn/pst/enscript.html Another (which I prefer) solution is to send to printer like this (with "n" being the 8859 extension number): $ iconv -f UTF-8 -t ISO-8859-n file-UTF8.txt | enscript --encoding=8859n | lpr -P Thanks to Martin Paredes for this suggestion. Perhaps this information or the appropriate enscript conversion code for psif could be included in the Handbook (https://www.freebsd.org/doc/handbook/printing-lpd.html 10.5.3.4 / 10.5.3.5)? Regards. ----- FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/printing-text-file-with-LPD-non-printable-characters-tp5954561p5956648.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Tue Oct 14 09:15:23 2014 Return-Path: Delivered-To: freebsd-current@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 840018CB for ; Tue, 14 Oct 2014 09:15:23 +0000 (UTC) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3E872E25 for ; Tue, 14 Oct 2014 09:15:22 +0000 (UTC) Received: from [89.204.135.184] (helo=unixarea.DDR.dd) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1XdyCN-0002d3-Cq; Tue, 14 Oct 2014 11:15:19 +0200 Received: from unixarea.DDR.dd (localhost [127.0.0.1]) by unixarea.DDR.dd (8.14.9/8.14.3) with ESMTP id s9E9F9cV001537; Tue, 14 Oct 2014 11:15:10 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by unixarea.DDR.dd (8.14.9/8.14.3/Submit) id s9E9F52G001536; Tue, 14 Oct 2014 11:15:05 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: unixarea.DDR.dd: guru set sender to guru@unixarea.de using -f Date: Tue, 14 Oct 2014 11:15:03 +0200 From: Matthias Apitz To: Beeblebrox Subject: Re: printing text file with LPD - non-printable characters Message-ID: <20141014091503.GA1481@unixarea.DDR.dd> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , Beeblebrox , freebsd-current@freebsd.org References: <1412530903064-5954561.post@n5.nabble.com> <20141005183517.GA1073@unixarea.DDR.dd> <20141005220221.1ed7df8d@rsbsd.rsb> <1413274782325-5956648.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1413274782325-5956648.post@n5.nabble.com> X-Operating-System: FreeBSD 11.0-CURRENT r269739 (i386) User-Agent: Mutt/1.5.23 (2014-03-12) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.204.135.184 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 09:15:23 -0000 El dĂ­a Tuesday, October 14, 2014 a las 01:19:42AM -0700, Beeblebrox escribiĂł: > Enscript does not support UTF-8 formatted text files, so it's not usable in > this case. > > One solution, "is to use paps, instead of Enscript, for converting UTF-8 > encoded text to PostScript." > http://www.linuxfromscratch.org/blfs/view/svn/pst/enscript.html > > ... We are using in production environments CUPS in the version 1.4.3; this has a component 'texttops' which supports UTF-8 encoded text (only) and prints UTF-8 nicely on the fly. We have a special enhancement of the used fonts to support most EU languages. HIH matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: guru@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign From owner-freebsd-current@FreeBSD.ORG Tue Oct 14 09:26:38 2014 Return-Path: Delivered-To: freebsd-current@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 B7DF4B73 for ; Tue, 14 Oct 2014 09:26:38 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 957C1F10 for ; Tue, 14 Oct 2014 09:26:38 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1XdyNJ-000708-CP for freebsd-current@freebsd.org; Tue, 14 Oct 2014 02:26:37 -0700 Date: Tue, 14 Oct 2014 02:26:37 -0700 (PDT) From: Beeblebrox To: freebsd-current@freebsd.org Message-ID: <20141014122631.6c83732d@rsbsd.rsb> In-Reply-To: <20141014091503.GA1481@unixarea.DDR.dd> References: <1412530903064-5954561.post@n5.nabble.com> <20141005183517.GA1073@unixarea.DDR.dd> <20141005220221.1ed7df8d@rsbsd.rsb> <1413274782325-5956648.post@n5.nabble.com> <20141014091503.GA1481@unixarea.DDR.dd> Subject: Re: printing text file with LPD - non-printable characters MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 09:26:38 -0000 > We are using in production environments CUPS in the version 1.4.3; > this has a component 'texttops' which supports UTF-8 encoded text > (only) and prints UTF-8 nicely on the fly. Thanks for the input. Unfortunately, CUPS has been broken for me since May/14. (http://freebsd.1045724.n5.nabble.com/print-cups-base-web-interface-broken-amp-unable-to-print-td5918098.html#a5922974) Installed CUPS components: cups-base-1.7.3_1, cups-client-1.7.3_2, cups-image-1.7.3_1, cups-pdf-2.6.1_1, cups-pstoraster-8.15.4_8, gutenprint-cups-5.2.10 Regards. ----- FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/printing-text-file-with-LPD-non-printable-characters-tp5954561p5956658.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Tue Oct 14 09:30:09 2014 Return-Path: Delivered-To: freebsd-current@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 7FEB2D9A for ; Tue, 14 Oct 2014 09:30:09 +0000 (UTC) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 39908F39 for ; Tue, 14 Oct 2014 09:30:09 +0000 (UTC) Received: from [89.204.135.184] (helo=unixarea.DDR.dd) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1XdyQe-0003KG-Am for freebsd-current@freebsd.org; Tue, 14 Oct 2014 11:30:05 +0200 Received: from unixarea.DDR.dd (localhost [127.0.0.1]) by unixarea.DDR.dd (8.14.9/8.14.3) with ESMTP id s9E9TtH4001583 for ; Tue, 14 Oct 2014 11:29:56 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by unixarea.DDR.dd (8.14.9/8.14.3/Submit) id s9E9TqV4001582 for freebsd-current@freebsd.org; Tue, 14 Oct 2014 11:29:52 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: unixarea.DDR.dd: guru set sender to guru@unixarea.de using -f Date: Tue, 14 Oct 2014 11:29:50 +0200 From: Matthias Apitz To: freebsd-current@freebsd.org Subject: Re: printing text file with LPD - non-printable characters Message-ID: <20141014092950.GA1573@unixarea.DDR.dd> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , freebsd-current@freebsd.org References: <1412530903064-5954561.post@n5.nabble.com> <20141005183517.GA1073@unixarea.DDR.dd> <20141005220221.1ed7df8d@rsbsd.rsb> <1413274782325-5956648.post@n5.nabble.com> <20141014091503.GA1481@unixarea.DDR.dd> <20141014122631.6c83732d@rsbsd.rsb> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20141014122631.6c83732d@rsbsd.rsb> X-Operating-System: FreeBSD 11.0-CURRENT r269739 (i386) User-Agent: Mutt/1.5.23 (2014-03-12) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.204.135.184 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 09:30:09 -0000 El dĂ­a Tuesday, October 14, 2014 a las 02:26:37AM -0700, Beeblebrox escribiĂł: > > We are using in production environments CUPS in the version 1.4.3; > > this has a component 'texttops' which supports UTF-8 encoded text > > (only) and prints UTF-8 nicely on the fly. > > Thanks for the input. > Unfortunately, CUPS has been broken for me since May/14. > (http://freebsd.1045724.n5.nabble.com/print-cups-base-web-interface-broken-amp-unable-to-print-td5918098.html#a5922974) > > Installed CUPS components: > cups-base-1.7.3_1, cups-client-1.7.3_2, cups-image-1.7.3_1, cups-pdf-2.6.1_1, cups-pstoraster-8.15.4_8, gutenprint-cups-5.2.10 This is one of the reasons we stick with 1.4.3. matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: guru@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign From owner-freebsd-current@FreeBSD.ORG Tue Oct 14 10:07:11 2014 Return-Path: Delivered-To: freebsd-current@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 ADAA6849 for ; Tue, 14 Oct 2014 10:07:11 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8B8C83D7 for ; Tue, 14 Oct 2014 10:07:11 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1Xdz0Y-0000Qj-Ti for freebsd-current@freebsd.org; Tue, 14 Oct 2014 03:07:10 -0700 Date: Tue, 14 Oct 2014 03:07:10 -0700 (PDT) From: Beeblebrox To: freebsd-current@freebsd.org Message-ID: <20141014130654.0fb45a70@rsbsd.rsb> In-Reply-To: <20141014092950.GA1573@unixarea.DDR.dd> References: <1412530903064-5954561.post@n5.nabble.com> <20141005183517.GA1073@unixarea.DDR.dd> <20141005220221.1ed7df8d@rsbsd.rsb> <1413274782325-5956648.post@n5.nabble.com> <20141014091503.GA1481@unixarea.DDR.dd> <20141014122631.6c83732d@rsbsd.rsb> <20141014092950.GA1573@unixarea.DDR.dd> Subject: Re: printing text file with LPD - non-printable characters MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 10:07:11 -0000 @Matthias: > This is one of the reasons we stick with 1.4.3. How? Did you create a self-maintained port for it? How did you overcome the problem of CUPS-dependent ports pulling in 1.7.3 in poudriere? Regards. ----- FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/printing-text-file-with-LPD-non-printable-characters-tp5954561p5956672.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Tue Oct 14 10:43:05 2014 Return-Path: Delivered-To: freebsd-current@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 1E788BC for ; Tue, 14 Oct 2014 10:43:05 +0000 (UTC) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CBC6197F for ; Tue, 14 Oct 2014 10:43:04 +0000 (UTC) Received: from [89.204.135.184] (helo=unixarea.DDR.dd) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1XdzZE-0005u5-IP for freebsd-current@freebsd.org; Tue, 14 Oct 2014 12:43:00 +0200 Received: from unixarea.DDR.dd (localhost [127.0.0.1]) by unixarea.DDR.dd (8.14.9/8.14.3) with ESMTP id s9EAgqOS001777 for ; Tue, 14 Oct 2014 12:42:53 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by unixarea.DDR.dd (8.14.9/8.14.3/Submit) id s9EAgnSB001776 for freebsd-current@freebsd.org; Tue, 14 Oct 2014 12:42:49 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: unixarea.DDR.dd: guru set sender to guru@unixarea.de using -f Date: Tue, 14 Oct 2014 12:42:47 +0200 From: Matthias Apitz To: freebsd-current@freebsd.org Subject: Re: printing text file with LPD - non-printable characters Message-ID: <20141014104247.GA1760@unixarea.DDR.dd> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , freebsd-current@freebsd.org References: <1412530903064-5954561.post@n5.nabble.com> <20141005183517.GA1073@unixarea.DDR.dd> <20141005220221.1ed7df8d@rsbsd.rsb> <1413274782325-5956648.post@n5.nabble.com> <20141014091503.GA1481@unixarea.DDR.dd> <20141014122631.6c83732d@rsbsd.rsb> <20141014092950.GA1573@unixarea.DDR.dd> <20141014130654.0fb45a70@rsbsd.rsb> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20141014130654.0fb45a70@rsbsd.rsb> X-Operating-System: FreeBSD 11.0-CURRENT r269739 (i386) User-Agent: Mutt/1.5.23 (2014-03-12) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.204.135.184 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 10:43:05 -0000 El dĂ­a Tuesday, October 14, 2014 a las 03:07:10AM -0700, Beeblebrox escribiĂł: > @Matthias: I'm not '@Matthias', but Matthias, and I think, the @ sign is normaly used to express user@host or @domain; > > This is one of the reasons we stick with 1.4.3. > > How? Did you create a self-maintained port for it? > How did you overcome the problem of CUPS-dependent ports pulling in 1.7.3 in poudriere? I compile it directly from source, also on non-FreeBSD hosts (Linux and SPARC) and ship it to our customers. matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: guru@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign From owner-freebsd-current@FreeBSD.ORG Tue Oct 14 14:43:08 2014 Return-Path: Delivered-To: freebsd-current@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 831EE46A for ; Tue, 14 Oct 2014 14:43:08 +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 EBD0F7C4 for ; Tue, 14 Oct 2014 14:43:07 +0000 (UTC) Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s9EEh4Di058693 for ; Tue, 14 Oct 2014 16:43:04 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 3860A3394; Tue, 14 Oct 2014 16:43:04 +0200 (CEST) Message-ID: <543D3671.8040004@omnilan.de> Date: Tue, 14 Oct 2014 16:42:57 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: FreeBSD current Subject: installincludes, bsd.incs.mk and param.h X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC823973ECAEB3ADE3BF66AF3" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Tue, 14 Oct 2014 16:43:04 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 14:43:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC823973ECAEB3ADE3BF66AF3 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hello, since bsd.port.mk insinsts on param.h, I have inconveniences on my production systems which were installed with "WITHOUT_TOOLCHAIN=3Dtrue" i= n src.conf (resulting in MK_TOOLCHAIN=3Dno). My first attempt was the following patch: --- share/mk/bsd.incs.mk.orig 2014-10-14 16:35:53.000000000 +0200 +++ share/mk/bsd.incs.mk 2014-10-14 16:34:57.000000000 +0200 @@ -81,4 +81,9 @@ realinstall: installincludes .ORDER: beforeinstall installincludes =20 +.else +installincludes: + ${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m ${NOBINMODE} \ + ${SYSDIR}/sys/param.h ${DESTDIR}${INCLUDEDIR}/sys/sys + .endif # !defined(NO_INCS) && ${MK_TOOLCHAIN} !=3D "no" "$SYSDIR" makes the example above not working! Unfortunately I couldn't figure out when/how param.h gets installed. Also, I couldn't find out what stage uses include/Makefile, only that it's not used when MK_TOOLCHAIN=3Dno. Any help highly appreciated! Thanks, -Harry --------------enigC823973ECAEB3ADE3BF66AF3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlQ9NncACgkQLDqVQ9VXb8h/twCfYaJO635uQMY/BP2Eow5HfVw8 nVoAoITqOFD3OV7qXQIgcKKRTarLo/GC =CY47 -----END PGP SIGNATURE----- --------------enigC823973ECAEB3ADE3BF66AF3-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 14 14:52:55 2014 Return-Path: Delivered-To: freebsd-current@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 A7D84888 for ; Tue, 14 Oct 2014 14:52:55 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 660D08CA for ; Tue, 14 Oct 2014 14:52:54 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id s9EEqrmZ037126; Tue, 14 Oct 2014 07:52:53 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id s9EEqrZL037125; Tue, 14 Oct 2014 07:52:53 -0700 (PDT) (envelope-from david) Date: Tue, 14 Oct 2014 07:52:53 -0700 From: David Wolfskill To: Harald Schmalzbauer Subject: Re: installincludes, bsd.incs.mk and param.h Message-ID: <20141014145253.GD2078@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Harald Schmalzbauer , FreeBSD current References: <543D3671.8040004@omnilan.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="JAtnJwvplI04zgov" Content-Disposition: inline In-Reply-To: <543D3671.8040004@omnilan.de> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 14:52:55 -0000 --JAtnJwvplI04zgov Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 14, 2014 at 04:42:57PM +0200, Harald Schmalzbauer wrote: > Hello, >=20 > since bsd.port.mk insinsts on param.h, I have inconveniences on my > production systems which were installed with "WITHOUT_TOOLCHAIN=3Dtrue" in > src.conf (resulting in MK_TOOLCHAIN=3Dno). >=20 > My first attempt was the following patch: > ... > "$SYSDIR" makes the example above not working! > Unfortunately I couldn't figure out when/how param.h gets installed. > Also, I couldn't find out what stage uses include/Makefile, only that > it's not used when MK_TOOLCHAIN=3Dno. >=20 > Any help highly appreciated! > .... My production systems have their OS built on a "build machine"; at install time, the build machine exports its /usr/src and /usr/obj, and I "make installkernel installworld" (& mergemaster...) on the production systems. I'm still building ports using portmaster on the production systems (as I lack the infrastructure to create my own pkg repository, and I need some non-default options), so I export the build machine's /usr/src & /usr/obj to the production machines during the ports builds, as well. That said, I don't try to do anything with respect to MK_TOOLCHAIN -- in normal use, the production machines don't have /usr/src or /usr/obj at all anyway. In any case, this has generally been working for me for many years. Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --JAtnJwvplI04zgov Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUPTjEXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7QF0P/Ap40XwsFzTCQQ4uR3ULecLa N36VyoNK6M5RhtVvHP378o9bjpwP87xzwFcBYy8xsaFKSiaVuMLRGhUOs7y1MgXu xLrLlLGccHcKqxy84HRD+qrum5yvMdp2RA7BXxeePqFcafWF7jsMxNj0NQJ6Q3J8 r+Kvx+I/4Cs1y9RYC/uCV3INKdwoaA238mUJban93qwtPwe6AJ1DRwpCK3pNkvE9 I/n+XydlLST0HYjc1yAkfOuAvF32i/n8uGub4TtYQ0zauUAfOV+YGA+CbLlnQnQO SVjRRdStF66gx/r2AYPYo/l7BiuGLS5tTQUQ26GT6LXPvxmQII21oAn/4KY/vll6 ghyOhmDUwAOAU2vsGw5C+4JowoXbuD627Y9N6ncDoseClGVm638ugaIuJP8xMxq5 o20+IcuavqN2/7iChePZjEPSNW5bfmujq+UDk9OBBKEjYnupZUMKAVdZD1ZvxhPt qlDgU9pfOBtYcJzqeMjyyhPSdRbnwkkuIEG3S0Y2cqHPkFQvAps5fc+MRKnaQ+Qf NAAUykjsvxfHYVqrrsokSpKLD6sQRvxNksvQFd/haRPzcUfpt/v4pw00jgV3EZ0l dpyh1RyUMIvT9NmO2481P4MGxZ+f2GkRZVYvqbDOUe9ZC47Wvbye85qKX93XKQgp dLkwDctyocvqDmQ2iEKk =fK1a -----END PGP SIGNATURE----- --JAtnJwvplI04zgov-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 14 15:25:03 2014 Return-Path: Delivered-To: freebsd-current@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 05F7B248 for ; Tue, 14 Oct 2014 15:25:03 +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 A0731BD6 for ; Tue, 14 Oct 2014 15:25:02 +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 s9EFOtTd059142; Tue, 14 Oct 2014 17:24:55 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 1361933AF; Tue, 14 Oct 2014 17:24:55 +0200 (CEST) Message-ID: <543D4046.9030809@omnilan.de> Date: Tue, 14 Oct 2014 17:24:54 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: David Wolfskill , FreeBSD current Subject: Re: installincludes, bsd.incs.mk and param.h References: <543D3671.8040004@omnilan.de> <20141014145253.GD2078@albert.catwhisker.org> In-Reply-To: <20141014145253.GD2078@albert.catwhisker.org> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5AB91D253F1F05C8AA2319E7" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Tue, 14 Oct 2014 17:24:55 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 15:25:03 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5AB91D253F1F05C8AA2319E7 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Bez=FCglich David Wolfskill's Nachricht vom 14.10.2014 16:52 (localtime)= : > On Tue, Oct 14, 2014 at 04:42:57PM +0200, Harald Schmalzbauer wrote: >> Hello, >> >> since bsd.port.mk insinsts on param.h, I have inconveniences on my >> production systems which were installed with "WITHOUT_TOOLCHAIN=3Dtrue= " in >> src.conf (resulting in MK_TOOLCHAIN=3Dno). >> >> My first attempt was the following patch: >> ... >> "$SYSDIR" makes the example above not working! >> Unfortunately I couldn't figure out when/how param.h gets installed. >> Also, I couldn't find out what stage uses include/Makefile, only that >> it's not used when MK_TOOLCHAIN=3Dno. >> >> Any help highly appreciated! >> .... > My production systems have their OS built on a "build machine"; at > install time, the build machine exports its /usr/src and /usr/obj, and = I > "make installkernel installworld" (& mergemaster...) on the production > systems. > > I'm still building ports using portmaster on the production systems (as= > I lack the infrastructure to create my own pkg repository, and I need > some non-default options), so I export the build machine's /usr/src & > /usr/obj to the production machines during the ports builds, as well. > > That said, I don't try to do anything with respect to MK_TOOLCHAIN -- i= n > normal use, the production machines don't have /usr/src or /usr/obj at > all anyway. > > In any case, this has generally been working for me for many years. Sounds reasonable. For one (big) enivronment at least. I have different, completely unrelated environments which I maintain. Therefore I do have a complete project-oriented build- and rollout infrastruture, which also handles ports/packages (most times distributed as repository on CD, each CD a set of applications for one distinct machine). So on my production systems, I don't need to (and even can't) compile any sources, but on some of them, I often use the ports tree for update checks or various - destination machine unrelated - tasks, like 'make fetch' for having a convenient way looking into sources e.g. ... The ports tree has been a very valuable source for me in many aspects, not just for compiling anything. The param.h dependent OSVERSION check is relatively new, but bites me frequently. So I really need a possibility to make the ports tree usable again on machines which don't have any part of TOOLCHAIN installed. Preferably I'd like to "fix" the dependency as close as possible to the FreeBSD standard build environment, instead of botching post-installworld= =2E.. Thanks, -Harry =20 --------------enig5AB91D253F1F05C8AA2319E7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlQ9QEYACgkQLDqVQ9VXb8hOAACeOsv1BpHkm1SkMjeyHiOMUdtk yt4An1esaPu86822iSHqIIo4gTWhp6nv =S1S0 -----END PGP SIGNATURE----- --------------enig5AB91D253F1F05C8AA2319E7-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 14 15:37:53 2014 Return-Path: Delivered-To: freebsd-current@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 871D86ED for ; Tue, 14 Oct 2014 15:37:53 +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 5865FCEE for ; Tue, 14 Oct 2014 15:37:52 +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 1Xe4AU-0005Wm-7L; Tue, 14 Oct 2014 15:37:46 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s9EFbi5J046998; Tue, 14 Oct 2014 09:37:44 -0600 (MDT) (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+lPKIShb3HeQ5rnDBMPVP2 X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: installincludes, bsd.incs.mk and param.h From: Ian Lepore To: Harald Schmalzbauer In-Reply-To: <543D4046.9030809@omnilan.de> References: <543D3671.8040004@omnilan.de> <20141014145253.GD2078@albert.catwhisker.org> <543D4046.9030809@omnilan.de> Content-Type: text/plain; charset="ISO-8859-1" Date: Tue, 14 Oct 2014 09:37:43 -0600 Message-ID: <1413301063.12052.396.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id s9EFbi5J046998 Cc: FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 15:37:53 -0000 On Tue, 2014-10-14 at 17:24 +0200, Harald Schmalzbauer wrote: > Bez=FCglich David Wolfskill's Nachricht vom 14.10.2014 16:52 (localtime= ): > > On Tue, Oct 14, 2014 at 04:42:57PM +0200, Harald Schmalzbauer wrote: > >> Hello, > >> > >> since bsd.port.mk insinsts on param.h, I have inconveniences on my > >> production systems which were installed with "WITHOUT_TOOLCHAIN=3Dtr= ue" in > >> src.conf (resulting in MK_TOOLCHAIN=3Dno). > >> > >> My first attempt was the following patch: > >> ... > >> "$SYSDIR" makes the example above not working! > >> Unfortunately I couldn't figure out when/how param.h gets installed. > >> Also, I couldn't find out what stage uses include/Makefile, only tha= t > >> it's not used when MK_TOOLCHAIN=3Dno. > >> > >> Any help highly appreciated! > >> .... > > My production systems have their OS built on a "build machine"; at > > install time, the build machine exports its /usr/src and /usr/obj, an= d I > > "make installkernel installworld" (& mergemaster...) on the productio= n > > systems. > > > > I'm still building ports using portmaster on the production systems (= as > > I lack the infrastructure to create my own pkg repository, and I need > > some non-default options), so I export the build machine's /usr/src & > > /usr/obj to the production machines during the ports builds, as well. > > > > That said, I don't try to do anything with respect to MK_TOOLCHAIN --= in > > normal use, the production machines don't have /usr/src or /usr/obj a= t > > all anyway. > > > > In any case, this has generally been working for me for many years. >=20 > Sounds reasonable. For one (big) enivronment at least. > I have different, completely unrelated environments which I maintain. > Therefore I do have a complete project-oriented build- and rollout > infrastruture, which also handles ports/packages (most times distribute= d > as repository on CD, each CD a set of applications for one distinct > machine). >=20 > So on my production systems, I don't need to (and even can't) compile > any sources, but on some of them, I often use the ports tree for update > checks or various - destination machine unrelated - tasks, like 'make > fetch' for having a convenient way looking into sources e.g. ... > The ports tree has been a very valuable source for me in many aspects, > not just for compiling anything. >=20 > The param.h dependent OSVERSION check is relatively new, but bites me > frequently. So I really need a possibility to make the ports tree usabl= e > again on machines which don't have any part of TOOLCHAIN installed. > Preferably I'd like to "fix" the dependency as close as possible to the > FreeBSD standard build environment, instead of botching post-installwor= ld... >=20 > Thanks, >=20 > -Harry >=20 > =20 >=20 It appears that while bsd.ports.mk has lost the ability to use the version of the running system (sysctl kern.osreldate), it still has the logic to just use OSVERSION if it's already set on the make command line or in the environment. Can you leverage that to regain the behavior you're used to? -- Ian From owner-freebsd-current@FreeBSD.ORG Tue Oct 14 16:09:18 2014 Return-Path: Delivered-To: freebsd-current@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 7002DD26; Tue, 14 Oct 2014 16:09:18 +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 D561AFFE; Tue, 14 Oct 2014 16:09:17 +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 s9EG9FBw059497; Tue, 14 Oct 2014 18:09:15 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id A246B33BC; Tue, 14 Oct 2014 18:09:15 +0200 (CEST) Message-ID: <543D4AAA.6040204@omnilan.de> Date: Tue, 14 Oct 2014 18:09:14 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Ian Lepore Subject: Re: installincludes, bsd.incs.mk and param.h References: <543D3671.8040004@omnilan.de> <20141014145253.GD2078@albert.catwhisker.org> <543D4046.9030809@omnilan.de> <1413301063.12052.396.camel@revolution.hippie.lan> In-Reply-To: <1413301063.12052.396.camel@revolution.hippie.lan> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig289B8A80CAA8BCB5DB8D18ED" X-Greylist: ACL 119 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Tue, 14 Oct 2014 18:09:16 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) Cc: FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 16:09:18 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig289B8A80CAA8BCB5DB8D18ED Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bez=FCglich Ian Lepore's Nachricht vom 14.10.2014 17:37 (localtime): =2E.. > It appears that while bsd.ports.mk has lost the ability to use the > version of the running system (sysctl kern.osreldate), it still has the= > logic to just use OSVERSION if it's already set on the make command lin= e > or in the environment. Can you leverage that to regain the behavior > you're used to? In general yes, that's what I did since my last ports-svn-update, but only to avoid complete breakage. Problem is that I have absolutely not in mind what OSVERSION on what machine to set. So I'm supplying a "dummy" version. That shouldn't be a problem for my purposes, but it's simply wrong. This check was introduced to gather the =BBcorrect=AB OSVERSION ;-) And manually supplyi= ng the correct version doesn't work due to brain contraints ;-) I like the idea to ask a userland installed indicator. But I'm not familar enough with bsd.incs.mk and the related installworld stage. I'd just need the hint from where include/Makefile gets conditionally (MK_TOOLCCHAIN!=3Dno) included ... ?!? Somwhere it start's recursing the SUBDIRs, and I guess every binary calls installincludes: from it's directory (which works since bsd.lib.mk and bsd.prog.mk include bsd.incs.mk), but I can't find at what SUBDIR param.h is involved. Thanks, -Harry --------------enig289B8A80CAA8BCB5DB8D18ED Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlQ9SqsACgkQLDqVQ9VXb8g9HgCgr5k3KEN2DowsSzWObRr/TLVp bbIAoLk3SoWtRTWRWPZ32Tp9+EVqWMT/ =K9Um -----END PGP SIGNATURE----- --------------enig289B8A80CAA8BCB5DB8D18ED-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 14 16:49:17 2014 Return-Path: Delivered-To: freebsd-current@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 D4642987 for ; Tue, 14 Oct 2014 16:49:17 +0000 (UTC) Received: from gw.catspoiler.org (cl-1657.chi-02.us.sixxs.net [IPv6:2001:4978:f:678::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 8771A6A8 for ; Tue, 14 Oct 2014 16:49:17 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id s9EGn5qf034978; Tue, 14 Oct 2014 09:49:09 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201410141649.s9EGn5qf034978@gw.catspoiler.org> Date: Tue, 14 Oct 2014 09:49:05 -0700 (PDT) From: Don Lewis Subject: Re: printing text file with LPD - non-printable characters To: zaphod@berentweb.com In-Reply-To: <20141014122631.6c83732d@rsbsd.rsb> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 16:49:17 -0000 On 14 Oct, Beeblebrox wrote: >> We are using in production environments CUPS in the version 1.4.3; >> this has a component 'texttops' which supports UTF-8 encoded text >> (only) and prints UTF-8 nicely on the fly. > > Thanks for the input. > Unfortunately, CUPS has been broken for me since May/14. > (http://freebsd.1045724.n5.nabble.com/print-cups-base-web-interface-broken-amp-unable-to-print-td5918098.html#a5922974) > > Installed CUPS components: > cups-base-1.7.3_1, cups-client-1.7.3_2, cups-image-1.7.3_1, cups-pdf-2.6.1_1, cups-pstoraster-8.15.4_8, gutenprint-cups-5.2.10 I think it also broke for me around that timeframe until I found that I also needed cups-filters. cups-base-1.7.3_1 Common UNIX Printing System: Server cups-client-1.7.3_2 Common UNIX Printing System: Library cups cups-filters-1.0.58 Backends, filters and other software (was part of the core CUPS) cups-image-1.7.3_1 Common UNIX Printing System: Library cupsimage cups-pstoraster-8.15.4_8 Postscript interpreter for CUPS printing to non-PS printers gutenprint-cups-5.2.10 GutenPrint Printer Driver libgnomecups-0.2.3_6,1 Support library for gnome cups administration From owner-freebsd-current@FreeBSD.ORG Tue Oct 14 17:00:56 2014 Return-Path: Delivered-To: freebsd-current@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 AD0DDC7F for ; Tue, 14 Oct 2014 17:00:56 +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 7DCFE809 for ; Tue, 14 Oct 2014 17:00:56 +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 1Xe5Sw-000NVC-JK; Tue, 14 Oct 2014 17:00:54 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s9EH0rxe047321; Tue, 14 Oct 2014 11:00:53 -0600 (MDT) (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: U2FsdGVkX18hT35PPGJqtOPA30zuYpL5 X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: installincludes, bsd.incs.mk and param.h From: Ian Lepore To: Harald Schmalzbauer In-Reply-To: <543D4AAA.6040204@omnilan.de> References: <543D3671.8040004@omnilan.de> <20141014145253.GD2078@albert.catwhisker.org> <543D4046.9030809@omnilan.de> <1413301063.12052.396.camel@revolution.hippie.lan> <543D4AAA.6040204@omnilan.de> Content-Type: text/plain; charset="ISO-8859-1" Date: Tue, 14 Oct 2014 11:00:52 -0600 Message-ID: <1413306052.12052.399.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id s9EH0rxe047321 Cc: FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 17:00:56 -0000 On Tue, 2014-10-14 at 18:09 +0200, Harald Schmalzbauer wrote: > Bez=FCglich Ian Lepore's Nachricht vom 14.10.2014 17:37 (localtime): > ... > > It appears that while bsd.ports.mk has lost the ability to use the > > version of the running system (sysctl kern.osreldate), it still has t= he > > logic to just use OSVERSION if it's already set on the make command l= ine > > or in the environment. Can you leverage that to regain the behavior > > you're used to? >=20 > In general yes, that's what I did since my last ports-svn-update, but > only to avoid complete breakage. > Problem is that I have absolutely not in mind what OSVERSION on what > machine to set. So I'm supplying a "dummy" version. That shouldn't be a > problem for my purposes, but it's simply wrong. This check was > introduced to gather the =BBcorrect=AB OSVERSION ;-) And manually suppl= ying > the correct version doesn't work due to brain contraints ;-) > I like the idea to ask a userland installed indicator. But I'm not > familar enough with bsd.incs.mk and the related installworld stage. I'd > just need the hint from where include/Makefile gets conditionally > (MK_TOOLCCHAIN!=3Dno) included ... ?!? Somwhere it start's recursing th= e > SUBDIRs, and I guess every binary calls installincludes: from it's > directory (which works since bsd.lib.mk and bsd.prog.mk include > bsd.incs.mk), but I can't find at what SUBDIR param.h is involved. >=20 > Thanks, >=20 > -Harry >=20 The old code that used to work for you got the version via sysctl, so I was recommending that you keep doing that yourself, since it's no longer built in to bsd.ports.mk. =20 So just add "export OSVERSION=3D`sysctl kern.osreldate` to your script that kicks off this update process, something like that. -- Ian From owner-freebsd-current@FreeBSD.ORG Tue Oct 14 17:41:54 2014 Return-Path: Delivered-To: freebsd-current@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 36C8C76E for ; Tue, 14 Oct 2014 17:41:54 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 13CD3C2A for ; Tue, 14 Oct 2014 17:41:53 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1Xe66b-0006rB-17 for freebsd-current@freebsd.org; Tue, 14 Oct 2014 10:41:53 -0700 Date: Tue, 14 Oct 2014 10:41:53 -0700 (PDT) From: Beeblebrox To: freebsd-current@freebsd.org Message-ID: <20141014204110.0b924b30@rsbsd.rsb> In-Reply-To: <201410141649.s9EGn5qf034978@gw.catspoiler.org> References: <1412530903064-5954561.post@n5.nabble.com> <20141005183517.GA1073@unixarea.DDR.dd> <20141005220221.1ed7df8d@rsbsd.rsb> <1413274782325-5956648.post@n5.nabble.com> <20141014091503.GA1481@unixarea.DDR.dd> <20141014122631.6c83732d@rsbsd.rsb> <201410141649.s9EGn5qf034978@gw.catspoiler.org> Subject: Re: printing text file with LPD - non-printable characters MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 17:41:54 -0000 @Don: > I think it (cups) also broke for me around that timeframe until I > found that I also needed cups-filters. You sir, are a life saver! Thank you for the tip. [SOLVED] ----- FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/printing-text-file-with-LPD-non-printable-characters-tp5954561p5956782.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Tue Oct 14 21:59:11 2014 Return-Path: Delivered-To: freebsd-current@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 7C12CED0; Tue, 14 Oct 2014 21:59:11 +0000 (UTC) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 7F8BEC83; Tue, 14 Oct 2014 21:59:10 +0000 (UTC) X-AuditID: 1209190f-f79aa6d000005b45-77-543d9ca69b7d Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 60.B8.23365.6AC9D345; Tue, 14 Oct 2014 17:59:02 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s9ELx1EE026774; Tue, 14 Oct 2014 17:59:02 -0400 Received: from localhost (mass-toolpike.mit.edu [18.9.64.17]) (authenticated bits=0) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9ELx0Zp008940; Tue, 14 Oct 2014 17:59:01 -0400 Date: Tue, 14 Oct 2014 17:59:00 -0400 (EDT) From: Benjamin Kaduk X-X-Sender: kaduk@mass-toolpike.mit.edu To: freebsd-hackers@FreeBSD.org Subject: FreeBSD Quarterly Status Report - Third Quarter 2014 Message-ID: User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAKsWRmVeSWpSXmKPExsUixCmqrbtsjm2Iwc1NJha7rp1mt5jz5gOT xfbN/xgtDjcLObB4zPg0nyWAMYrLJiU1J7MstUjfLoEro3nHRLaC/1+YK+ZO+8bcwHi9i7mL kZNDQsBEounLF0YIW0ziwr31bF2MXBxCArOZJHb9usQC4WxklPi1ZyoThPOJUWLnze1sIC0s AtoSM3vfgo1iE1CTWL/iGtRYdYnP8xeCjRURkJfY1/SeHcRmFrCWaFn5grWLkYNDWMBW4t6F dJAwr4C7xMyWX2DlogK6Eof+/WGDiAtKnJz5hAWi1V/i+bzN7BMY+WchSc1CkoKwdSSmTFzB CGFrS9y/2ca2gJFlFaNsSm6Vbm5iZk5xarJucXJiXl5qka6JXm5miV5qSukmRnDQSvLvYPx2 UOkQowAHoxIPb0GkTYgQa2JZcWXuIUZJDiYlUd7ZfbYhQnxJ+SmVGYnFGfFFpTmpxYcYJTiY lUR47ZOBcrwpiZVVqUX5MClpDhYlcd5NP/hChATSE0tSs1NTC1KLYLIyHBxKErx5s4EaBYtS 01Mr0jJzShDSTBycIMN5gIbHg9TwFhck5hZnpkPkTzHacxzreNnLxNHzGUR++AUiH+z+M4FJ iCUvPy9VSpy3DKRNAKQtozQPbjIsIb1iFAd6VJjXDKSKB5jM4Ga/AlrLBLR2YijY2pJEhJRU A6PPtK43un9vl1n/3fzbvCp0YWa47geFXY1KLMJbl53Pk7lx6Z2D5mFrXoMP1z9HXwhrvMta d3j1klmm2osZnWx9THeGdU7f+uFYrn3GxrCj2i8vey2tWNgiIrdqFYP4fsU01j0VZ5++YfJ9 yBMRwhPLGGHT1Rw177saj5yq18zLC9+e82bRMFRiKc5INNRiLipOBAD90mepIwMAAA== Content-Type: TEXT/PLAIN; charset=ISO-8859-2 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 21:59:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 FreeBSD Project Quarterly Status Report: July - September 2014 This report covers FreeBSD-related projects between July and September 2014. This is the third of four reports planned for 2014. The third quarter of 2014 was another productive quarter for the FreeBSD project. A lot of work has been done on various ARM platforms, with the goal of bringing them to Tier 1 status in FreeBSD 11. The various ports teams have also worked hard to improve the state of FreeBSD as a desktop operating system. As usual, performance improvements feature in several places in this report and many of these can benefit from user benchmarking to validate our results. Thanks to all the reporters for the excellent work! The deadline for submissions covering the period from October to December 2014 is January 7th, 2015. __________________________________________________________________ FreeBSD Team Reports * FreeBSD Cluster Administration Team * FreeBSD Release Engineering Team * Ports Collection * The FreeBSD Core Team Projects * Address Space Layout Randomization (ASLR) * amd64 Xen Paravirtualization * bhyve * Chelsio iSCSI Offload Support * Debian GNU/kFreeBSD * FreeBSD Preseed Installation (PXE) * Jenkins Continuous Integration for FreeBSD * New Automounter * QEMU bsd-user-Enabled Ports Building * VMWare VAAI and Microsoft ODX Acceleration in CTL * ZFSguru Kernel * Intel GPU Driver Update * SDIO Driver * UEFI Boot * Updated vt(4) System Console * Updating OpenCrypto Architectures * FreeBSD on Newer ARM Boards * FreeBSD/arm64 Userland Programs * LLDB Debugger Port * LLVM Address Sanitizer (Asan) * SSE Variants of libc Routines for amd64 Ports * FreeBSD Python Ports * GNOME/FreeBSD * KDE on FreeBSD * The Graphics Stack on FreeBSD * Xfce Documentation * Handbook ezjail Section * Michael Lucas Books * ZFS Chapter of the Handbook Miscellaneous * The FreeBSD Foundation __________________________________________________________________ FreeBSD Cluster Administration Team Contact: FreeBSD Cluster Administration Team The FreeBSD Cluster Administration Team consists of the people responsible for administering the machines that the project relies on for its distributed work and communications to be synchronised. In this quarter, the team has worked on: * Implemented a central, FreeBSD cluster-specific package building node using ports-mgmt/poudriere-devel, providing a single consistent set of third-party binary packages throughout the FreeBSD cluster from a common, known-working configuration. * Converted all machines running in the FreeBSD cluster from individual (and sometimes different) userland and kernel configurations to a single configuration for the base system. This enabled the implementation of a FreeBSD.org-specific binary update mechanism currently deployed throughout the cluster. This project is sponsored by The FreeBSD Foundation . __________________________________________________________________ FreeBSD Release Engineering Team URL: http://www.freebsd.org/releases/10.1R/schedule.html URL: http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes and maintaining the respective branches, among other things. In mid-July, FreeBSD 9.3-RELEASE was released without delay in release cycle. In late August, the FreeBSD 10.1-RELEASE cycle began, and as of this writing, is expected to stay on schedule. Work to produce virtual machine images as part of the release cycle has continued, supporting various cloud services such as Microsoft Azure, Amazon EC2, and Google Compute Engine. This project is sponsored by The FreeBSD Foundation . __________________________________________________________________ Ports Collection URL: http://www.FreeBSD.org/ports/ URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-ports/ URL: http://portsmon.freebsd.org/index.html URL: http://portscout.freebsd.org/ URL: http://www.freebsd.org/portmgr/index.html URL: http://blogs.freebsdish.org/portmgr/ URL: http://www.twitter.com/freebsd_portmgr/ URL: http://www.facebook.com/portmgr URL: http://plus.google.com/communities/108335846196454338383 Contact: Frederic Culot Contact: Port Management Team As of the end of Q3, the ports tree holds a bit more than 24,000 ports, and the PR count is below 1,400. Despite the summer holidays the tree saw sustained activity with more than 9,000 commits and almost 2,000 ports PRs closed! In Q3, five new developers were granted a ports commit bit. None were taken in for safekeeping. On the management side, tabthorpe@ decided to step down from his portmgr duties in July. No other changes were made to the team during Q3. This quarter also saw the release of the third quarterly branch, namely 2014Q3. On the QA side, 34 exp-runs were performed to validate sensitive updates or cleanups. Last, the 20th anniversary of the ports tree was commemorated during Q3 and a video was published for this event. Open tasks: 1. Tremendous work was done on the PR front in Q3 and we would be very pleased to see committers dedicate themselves to closing as many as possible in Q4 as well. __________________________________________________________________ The FreeBSD Core Team Contact: FreeBSD Core Team The FreeBSD Core Team constitutes the project's "Board of Directors", responsible for deciding the project's overall goals and direction as well as managing specific areas of the FreeBSD project landscape. The third quarter of this year was a relatively quiet time in terms of Core Team activity. No major policy changes were decided, but the criterea for awarding commit bits were reviewed and the existing requirements were clarified and documented at http://www.freebsd.org/interna=B3proposing-committers.html. Other items dealt with by core during this period: * Confirmed with Microsoft that it is permissible to include DCTCP in FreeBSD. * Promoted git-beta.freebsd.org out of beta-test to an official service, consequently renaming it to git.freebsd.org. * Mediated between groups of contributors and committers adopting different positions on the on-going work to introduce ASLR and associated technologies. * Worked with the FreeBSD Foundation to obtain a license for XenForo, and with the forum administrators on plans to migrate the FreeBSD forums onto the FreeBSD cluster and to switch to XenForo. During this period, three commit bits were granted, and two commit bits were taken in for safe keeping. __________________________________________________________________ Address Space Layout Randomization (ASLR) URL: http://hardenedbsd.org/ URL: https://reviews.freebsd.org/D473 URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D193940 URL: https://wiki.freebsd.org/201409DevSummit/ASLR URL: https://wiki.freebsd.org/AddressSpaceLayoutRandomization Contact: Shawn Webb Contact: Oliver Pinter Address Space Layout Randomization (ASLR) is a computer security technique that aids in mitigating low-level vulnerabilities such as buffer overflows. ASLR randomizes the memory layout of running applications, to prevent an attacker from knowing where a given exploitable vulnerability lies in memory. A lot has happened in the last few months. Shawn Webb gave presentations at both BSDCan 2014 and EuroBSDCon 2014. The presentations were met with a lot of support and backing. At the end of EuroBSDCon Ilya Bakulin fixed the known bug with ASLR on ARM systems. Shawn Webb and Oliver Pinter have submitted our patch to the Phabricator code review system. Shawn Webb added an API for allowing a debugger to disable ASLR to support deterministic debugging. Oliver Pinter enhanced the performance of our ASLR implementation. A package building exp-run was ran and came out favorably in terms of performance. Shawn Webb bumped up the maximum number of bits allowed to be randomized to 20 and set the default to 14. Shawn Webb and Oliver Pinter founded The HardenedBSD project to serve as a staging area for their work on security-related projects for FreeBSD. This project is sponsored by SoldierX. Open tasks: 1. Get more people testing and reviewing our patch 2. Run more performance tests 3. Figure out why the two ports failed in the EXP-RUN. Involve the port maintainers. 4. Test on different architectures (we need help with this) __________________________________________________________________ amd64 Xen Paravirtualization URL: https://wiki.freebsd.org/FreeBSD/Xen Contact: Cherry Mathew This project aims to add support to the FreeBSD kernel for running in Xen Paravirtualised mode on amd64 systems. This project has finally reached a "Proof of Concept" stage on the branch projects/amd64_xen_pv. Testing and bug reports on various configurations is encouraged! The author is also seeking bounties to help complete the effort and assess potential interest. Please send email if interested. PV kernels are still supported by most cloud providers for a range of configurations, although they are expected to be phased out in the future. This project is sponsored by Spectralogic Corporation (2012-2013) . Open tasks: 1. Large page support 2. SMP support 3. Debug and cleanup 4. Security vetting 5. Performance tweaks __________________________________________________________________ bhyve URL: http://www.bhyve.org URL: http://www.youtube.com/watch?v=3DlTOiSyu0-MA Contact: Peter Grehan Contact: Neel Natu Contact: John Baldwin Contact: Tycho Nightingale Contact: Allan Jude bhyve is a hypervisor that runs on the FreeBSD/amd64 platform. At present, it runs FreeBSD (8.x or later), Linux i386/x64, OpenBSD i386/amd64, and NetBSD/amd64 guests. Current development is focused on enabling additional guest operating systems and implementing features found in other hypervisors. A significant amount of progress has been made since the last status report. Most importantly, all of this work has been MFCed to the 10-STABLE branch and will be included in the 10.1 release. Support for AMD processors is being developed in the bhyve_svm SVN project branch. The branch is almost at feature-parity with mainline Intel VT-x support, and will be committed into -CURRENT in the near future. New features added this quarter: * Guest support for recent Linux i386/x64, OpenBSD i386/amd64, and NetBSD amd64. * Force guest reset and poweroff with bhyvectl * Allow the SMBIOS UUID to be set from the command line * PCI MMIO extended config space access * Improved AHCI error handling, legacy interrupt mode * Additional instruction emulation required by a number of guests * Legacy x86 task switching to support double-faults in FreeBSD/i386 * Legacy PCI interrupts, operation without an APIC (OpenBSD install) * Guest memory not included by default in core dumps * Allow guest vCPUs to be pinned to individual host CPUs * Virtio RNG device emulation * Chapter about bhyve added to FreeBSD Handbook Open tasks: 1. Improve documentation 2. CSM BIOS boot support for non UEFI-aware guests 3. Add support for virtio-scsi 4. Improve virtio-net, add offload features, support multiple queues 5. Implement Intel 82580 and e1000 NIC emulation 6. Netmap support 7. Flexible networking backend: wanproxy, vhost-net 8. Move to a single process model, instead of bhyveload and bhyve 9. Support running bhyve as non-root 10. Add filters for popular VM file formats (VMDK, VHD, QCOW2) 11. Implement an abstraction layer for video (no X11 or SDL in base system) 12. Support for VNC as a video output 13. Suspend/resume support 14. Live Migration 15. Nested VT-x support (bhyve in bhyve) 16. Support for other architectures (ARM, MIPS, PPC) __________________________________________________________________ Chelsio iSCSI Offload Support Contact: Sreenivasa Honnur Contact: Edward Tomasz Napiera=B3a Building on the new in-kernel iSCSI target and initiator stack released in FreeBSD 10.0, Chelsio Communications has begun developing an offload interface to take advantage of the hardware offload capabilities of Chelsio T4 and T5 10 and 40 gigabit Ethernet adapters. The code implements hardware PDU offload for both target and initiator. The iSCSI stack has been modified to provide a hardware-independent offload API, allowing offload drivers to be loaded as kernel modules, and to provide mechanisms for the system administrator to configure this feature. The project is entering a testing phase. The code will be released under the BSD license and is expected to be completed later in the year and ship in FreeBSD 10.2-RELEASE. This project is sponsored by Chelsio Communications , and The FreeBSD Foundation . Open tasks: 1. Complete testing __________________________________________________________________ Debian GNU/kFreeBSD URL: https://wiki.debian.org/Debian_GNU/kFreeBSD URL: https://www.debian.org/ports/kfreebsd-gnu/ Contact: Debian GNU/kFreeBSD Maintainers Debian GNU/kFreeBSD is a software distribution produced by Debian, based on the kernel of FreeBSD (instead of Linux) and GNU libc. Around 90% of Debian's software archive has now been ported to it, for amd64 and i386 architectures. It was first released with Debian "squeeze" as a development preview in 2011, featured again in the "wheezy" release, and hopes to be part of the official Debian "jessie" release in early 2015. In 2003 there were several attempts to bootstrap a minimal Debian system upon FreeBSD or NetBSD kernels, some also trying to use the native BSD libc. The most successful and longest-lived of these was a "GNU/FreeBSD" chroot bootstrapped by Robert Millan with the GNU libc that most of Debian's core packages were designed to work with. The "k" was later added to the name to reflect that it takes just the kernel from FreeBSD, with most everything else from the Debian archive. We do also package some FreeBSD utilities as needed to boot it and take advantage of certain features. FreeBSD support within GNU libc is now mostly maintained by Petr Salinger, who recently converted it from an older threading implementation based on LinuxThreads to NPTL, which is much more compatible with the software we run. We have the GNU compiler toolchain as well as Clang 3.4; Perl, Python and Ruby; and OpenJDK 7, based the on work done in FreeBSD's own ports collection. We use linprocfs for /proc because much of Debian GNU software expects this. The Linuxulator is not needed at all, but could make for interesting future uses. Porting work mostly focuses now on individual packages' build systems, on preprocessor #ifdefs that do not clearly distinguish between kernel and libc, or fixing testsuites' presumptions of Linux-specific behaviour. In the course of this, we even found the odd FreeBSD kernel bug, including EN-14:06 / CVE-2014-3880. GNU/kFreeBSD has already seen production use, mostly on webservers, email servers and file servers; one such machine has 475 days' uptime receiving around 10,000 emails per day. It has become increasingly practical for desktop/laptop uses thanks largely to new features coming in from FreeBSD 10.1. KMS graphics mean that 3D gaming and high-definition video playback perform brilliantly. We have great support for Intel graphics chipsets, but only an older nvidia Xorg driver. For radeonkms, Robert Millan was able to add firmware-loading support so that non-free binary blobs can be packaged separately, outside of Debian's main archive. Proprietary drivers are not useful to us as they would need to be rebuilt from source to port them. vt(4) was necessary for KMS to not break VT switching. But it has also improved the console's handling of non-ASCII character sets and we do look forward to having console fonts for non-Latin scripts. We have supported ZFS for some time, even as a root/boot filesystem (using GRUB 2; Robert Millan added the ZFS support which now FreeBSD itself is able to benefit from). Enhancements coming from OpenZFS, especially LZ4 compression, in combination with better memory management and GEOM improvements, mean that "jessie" should see a noticeable performance boost. debian-installer already allows for pre-seeded, unattended installs and there are PXE-bootable install images available. virtio drivers are new to the "jessie" release, enabling support for some public clouds. We are now compiling Xen domU and PVHVM support into our standard kernel builds. We already have userland tools to configure the PF firewall. As an experiment, we are compiling in IPSEC support by default for the upcoming release, and would like to see it put to good use against present-day privacy and security threats. We try to support the use of Debian GNU/kFreeBSD inside a jail on a FreeBSD host system, and hopefully vice-versa. Some of the jail utilities are not yet packaged, but we have documentation on the Debian Wiki on how to set up jails on "wheezy", which are fully functional. The init system we currently use is a parallel System V-style init, although Debian GNU/Linux will be switching away from that to systemd. For the next release we may switch to OpenRC, which is mostly ported already. Not having systemd or udev means that we will be unable to support GNOME 3.14 in the upcoming release. We have very good support for XFCE, also have KDE, LXDE and the recently-packaged MATE desktop environment. The Debian software archive provides many alternative window managers for Xorg such as IceWM, dozens of terminal emulators, and so on. As we approach the freeze of the Debian "jessie" release, we would love for anyone to test GNU/kFreeBSD, try to use it for whatever would be useful to you, and let us know what issues you run into. Ask for help on our project mailing list or IRC channel, and let us know of any bugs you find. We still have time to fix problems before release, and we would be happy to improve our documentation at any time. __________________________________________________________________ FreeBSD Preseed Installation (PXE) URL: https://wiki.freebsd.org/SummerOfCode2014/FreeBSD_PXE_preseed Contact: Kamil Czekirda This is a Google Summer of code project to provide a noninteractive FreeBSD installation process from the network. In the first part, an implementation was added for scripted bsdinstall(8). It supports variables such as KEYMAP, HOSTNAME, MIRROR, RELEASE, TIMEZONE, DAEMONS, ROOTPWHASH, and USERS. Network configuration, ZFS options, and others are also included. The second part of the project is about booting the fai (Fully Automatic Installer) from the network by PXE. An installer distro was created based on mfsBSD. After boot, fai looks for the "bootfile-name" parameter from the DHCP server. This parameter tells fai where the bsdinstall script is located. fai supports MAC-based configuration, or a default if a MAC-based configuration file does not exist. This project is sponsored by Google Summer of Code 2014 . Open tasks: 1. Documentation, including a HOWTO and handbook 2. More tests in different configurations 3. Support for more than one network interface is planned __________________________________________________________________ Jenkins Continuous Integration for FreeBSD URL: https://jenkins.freebsd.org URL: https://wiki.freebsd.org/201405DevSummit/Jenkins URL: http://www.bsdcan.org/2014/schedule/events/445.en.html URL: http://clang-analyzer.llvm.org/scan-build.html URL: http://scan.freebsd.org URL: http://www.bsdnow.tv/episodes/2014_07_02-base_iso_100 URL: http://www.slideshare.net/CraigRodrigues1/libvirt-bhyve URL: https://github.com/jmmv/kyua URL: https://issues.jenkins-ci.org/browse/JENKINS-24521 URL: https://github.com/jenkinsci/jenkins/pul=B31387 URL: https://github.com/jenkinsci/jenkins/pul=B31410 URL: http://jenkins.mouf.net/job/pkg/ URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D193499 URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D193246 URL: https://github.com/rodrigc/kyua/wiki/Quickstart-Guide Contact: Craig Rodrigues Contact: Jenkins Administrators Contact: FreeBSD Testing In May, Craig Rodrigues led a working group Continuous Integration and Testing with Jenkins for FreeBSD at the FreeBSD Devsummit in Ottawa. Craig Rodrigues also gave a Jenkins presentation at BSDCan. At BSDCan, Craig Rodrigues had some discussions with Julio Merino about how to better integrate FreeBSD testing efforts with Jenkins and kyua. As a result of this discussion, Julio Merino enhanced the kyua testing framework with a kyua report-junit command. This command takes kyua test results and outputs a test report in JUnit XML format. Jenkins can directly import JUnit XML test results and display them nicely. In June, Craig Rodrigues was interviewed for episode 44 of BSD Now. The interview covered Jenkins and Continuous Integration in the FreeBSD project. In July, Craig Rodrigues gave a presentation to the Bay Area FreeBSD Users Group (BAFUG), Libvirt and bhyve, based on experience he had with those technologies when used with Jenkins. Li-Wen Hsu set up a Jenkins job to run the LLVM scan-build tool to perform static analysis of the FreeBSD code, and make the results availalble at scan.freebsd.org. Steve Wills modified the Jenkins job which builds pkg(8) to use the kyua report-junit command to integrate pkg(8) test results in Jenkins. Anthony Williams reported that the version of the Java Native Access (JNA) library bundled with Jenkins has problems on FreeBSD. This causes problems with Jenkins using libpam and other plugins that use JNA. Craig filed JENKINS-24521 against Jenkins. Craig submitted patches to Jenkins to update Jenkins to use JNA 4.1.0, which has fixes for FreeBSD. Craig Rodrigues worked on automatically running the tests in the FreeBSD /usr/tests directory under Jenkins using the kyua test framework. Craig Rodrigues provided feedback to Julio Merino about kyua and Julio Merino incorporated some of the feedback as bugfixes and feature enhancements to kyua. Craig Rodrigues committed some fixes to FreeBSD to eliminate some test failures. One of the tests still results in a crash in byacc. This is being tracked in PR 193499. Thomas E. Dickey (byacc maintainer) submitted a patch to fix the problem, and this has been committed to FreeBSD. Craig Rodrigues analyzed the cause of some startup errors in Jenkins when opening a multicast socket. He had some discussion with Bruce M. Simpson captured in PR 193246. The Java JDK depends on functionality in Solaris where it is possible to open an IPv4 multicast socket, but with an IPv4 multicast address mapped to an IPv6 address. On Linux, there are modifications to the JDK itself to work around this. Bruce M. Simpson said that the work to make the FreeBSD IPv6 stack behave like Solaris would require some work. Craig Rodrigues started writing a Kyua Quickstart Guide. This guide is meant to help new kyua users who want to write tests and run them under kyua. Craig Rodrigues is seeking feedback to help improve this guide. Open tasks: 1. Upstream more fixes to Jenkins for FreeBSD, such as JNA fixes. 2. Automate the build of /usr/tests. 3. Set up more builds based on examples from the existing FreeBSD Tinderbox. 4. Get feedback for improving the Kyua Quickstart Guide. 5. We need more people to join us on freebsd-testing@FreeBSD.org and help out. We especially need people with devops and scripting experience to help us set up more builds and tests. We would also like to integrate with other parts of the project, such as Phabricator. __________________________________________________________________ New Automounter URL: https://wiki.freebsd.org/Automounter URL: http://people.freebsd.org/~trasz/autofs.pdf Contact: Edward Tomasz Napiera=B3a Limitations of the current automounter, amd(8), are a recurring problem reported by many FreeBSD users. A new automounter is being developed to address these concerns. The automounter is a cleanroom implementation of functionality available in most other Unix systems, using proper kernel support implemented via an autofs filesystem. The automounter supports a standard map format, and will integrate with the Lightweight Directory Access Protocol (LDAP) service. The FreeBSD Foundation worked with enterprise and university users to test the new automounter in existing LDAP-based environments, including some with thousands of map entries. The code is now ready to use. It has been committed to 11-CURRENT and 10-STABLE, and will ship as part of 10.1-RELEASE. There is ongoing work on improving performance and fixing possible bugs. This project is sponsored by The FreeBSD Foundation . __________________________________________________________________ QEMU bsd-user-Enabled Ports Building URL: https://wiki.freebsd.org/QemuUserModeHowTo URL: http://chips.ysv.freebsd.org/packages URL: https://github.com/seanbruno/qemu-bsd-user Contact: Sean Bruno Contact: Juergen Lock Contact: Stacey Son FreeBSD packages for the Tier-1 i386 and amd64 CPU architectures are built by a single very high-performance machine. Other architectures lack equivalent hardware, and we began experimenting with QEMU's user-mode emulation to cross-build packages from an amd64 builder. We have moved from just being able to produce packages to providing a stable repo of packages for ARMv6. ports-mgmt/poudriere-devel is still the current method for building packages. See the previous status report for explanations and details on methods. __________________________________________________________________ VMWare VAAI and Microsoft ODX Acceleration in CTL Contact: Alexander Motin The CAM Target Layer (CTL), used as base for the kernel iSCSI server, got support for VMWare VAAI and Microsoft ODX storage acceleration. It permits avoiding network bottlenecks and improves storage efficiency on sets of large operations, such as virtual machine (or large file) creation, initialization to zeros, copy, delete, etc.. VMWare VAAI includes support for these primitives/SCSI commands: Atomic Test and Set (ATS) -- COMPARE AND WRITE command; Extended Copy (Clone) -- SPC-3 subset of XCOPY commands; Write Same (Zero) -- set of WRITE SAME commands; and Dead Space Reclamation (Delete) -- UNMAP command. Microsoft ODX includes support for these SCSI commands: POPULATE TOKEN/WRITE USING TOKEN (SPC-4 extensions of XCOPY), WRITE SAME and UNMAP. All XCOPY operations are currently limited to one storage host. ODX operations are currently limited only to iSCSI disks. Accelerated inter-host copying or copying to/from files on Samba shares is not implemented and is handled by initiators in the legacy way. The code is committed to FreeBSD head and stable/10 branches, and will be present in FreeBSD 10.1 and FreeNAS 9.2.1.8 / 9.3 releases. This project is sponsored by iXsystems, Inc. . Open tasks: 1. Full support for thin provisioning, including capacity usage reporting and threshold notifications. 2. Inter-host XCOPY operations. __________________________________________________________________ ZFSguru URL: http://zfsguru.com URL: http://zfsguru.com/news/stateoftheproject/2014 URL: http://zfsguru.com/forum/zfsgurudevelopment/876 Contact: Jason Edwards ZFSguru is a multifunctional server appliance with a strong emphasis on storage. ZFSguru began as simple web-interface frontend to ZFS, but has since grown into a FreeBSD derivative with its own infrastructure. The scope of the project has also grown with the inclusion of add-on packages that add functionality beyond the traditional NAS functionality found in similar product like FreeNAS and NAS4Free. ZFSguru aims to be a true multifunctional server appliance that is extremely easy to set up and can unite both novice and more experienced users in a single user interface. The modular nature of the project combats the danger of bloat, whilst still allowing extended functionality to be easily deployed. The development work in Q3 focused heavily on the new build infrastructure. This allows the ZFSguru project to release new system images together with addon services at much higher frequency and with much less manual intervention. This should free up a lot of development time to be spent on the core of the project: the web interface. Furthermore, a new website and forum is being worked on, replacing the old-fashioned website that offers only limited functionality. The new website will be linked to the server database, providing real-time updates about the project. In addition, a new platform for collaborated development is in the works. A service addon has been created for the GitLab project, which is a drop-in replacement of the popular GitHub website. The choice was made to host our own solution and not rely on GitHub itself. In retrospect this appears to have been a good decision. The recent development where GitHub removed projects after DCMA-takedowns being sent is incompatible with the philosophy of free-flow-of-information, of which the ZFSguru project is a strong proponent. By hosting our own solution, we have avoided any dependency on third party projects. The next task will be to introduce a new remote database structure, dubbed GuruDB. This will speed up the web-interface as well as introduce Service Bulletins which address important notifications to our users, as well as announce new releases. After GuruDB, the Migration Manager is one of the last remaining features still missing in the web-interface. This functionality provides an easy way to upgrade the current system by performing a new clean installation, but migrate all relevant configuration to the new installation. It also allows users to 'backup' all system configuration in a single file to be stored on a different machine should things go awry. A longer version of the 2014 development progress of the ZFSguru project and information specific to the newly-released 10.1-002 system image can be found in the Links section. __________________________________________________________________ Intel GPU Driver Update URL: https://lists.freebsd.org/pipermai=B3freebsd-current/2014-October/052532 .html Contact: Konstantin Belousov The project to update the Intel graphics chipset driver (i915kms) to a recent snapshot of the Linux upstream code continues. A patch with a large chunk of updates has been made available to test for regressions against current functionality, but is not yet expected to provide working new functions. The GEM I/O ioctl code path has been modified to more closely resemble the Linux code structure (easing future imports). This project is sponsored by FreeBSD Foundation . Open tasks: 1. Fix any bugs reported against the latest versions of the patch. 2. Make Haswell graphics work with Mesa. __________________________________________________________________ SDIO Driver URL: https://wiki.freebsd.org/SDIO URL: https://github.com/kibab/freebsd/tree/mmccam URL: https://reviews.freebsd.org/D862 Contact: Ilya Bakulin SDIO is an interface designed as an extension of the existing SD card standard, allowing the connection of different peripherals to a host with a standard SD controller. Peripherals currently sold in the general market include WLAN/BT modules, cameras, fingerprint readers, and barcode scanners. SDIO is also used to connect some peripherals in products like Chromebooks and Wandboard. The current main focus of the project is to reimplement the existing MMC/SD stack using the CAM framework. This will allow utilizing the well-tested CAM locking model and debug features. The first version of the code was uploaded on Phabricator for review. The new stack is able to attach to the SD card and bring it to an operational state. The only supported SD controller driver is ti_sdhci which is used by the BeagleBone Black. Modifying other SDHCI-compliant drivers should not be a hard task. Open tasks: 1. At this point, feedback from kernel developers is really needed. This may be done in the form of code review. If the chosen way of implementing the CAM-aware MMC stack is considered correct, then adding code for interacting with SD cards (for example, setting the optimal transfer rates) will be the next task. 2. Write a CAM peripheral driver that implements an interface to the FreeBSD disk(9). It will send MMC I/O commands using the MMC XPT layer. 3. Extending camcontrol(8) to make it possible to send MMC-specific commands directly to the MMC/SD card using pass(4) will greatly assist in developing new features for the stack. 4. Modify the sdhci(4) driver to work with the new stack. This is required to work on the new stack using PC hardware, not only the BeagleBone Black. __________________________________________________________________ UEFI Boot URL: https://wiki.freebsd.org/UEFI URL: http://www.freebsd.org/snapshots/ Contact: Ed Maste Contact: Nathan Whitehorn The Unified Extensible Firmware Interface, or UEFI, provides boot- and run-time services for x86 and other computers. For the x86 architecture it replaces the legacy BIOS. This project will adapt the FreeBSD loader and kernel boot process for compatibility with UEFI firmware, found on contemporary servers, desktops, and laptops. Over the last three months Ed and others refined the existing UEFI support and merged it to the stable/10 branch for the upcoming FreeBSD 10.1 release. To avoid the risk of a regression, the standard FreeBSD 10.1 install images continue to use the existing partitioning scheme and support only legacy BIOS boot. Separate UEFI-enabled installer images will be included with 10.1. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Document manual installation, including dual-boot configurations. 2. Implement boot1.efi for ZFS file systems. 3. Add support for UEFI variables stored in non-volatile memory (NVRAM). 4. Debug boot failures with certain UEFI firmware implementations. 5. Support secure boot. __________________________________________________________________ Updated vt(4) System Console URL: https://wiki.freebsd.org/Newcons Contact: Aleksandr Rybalko Contact: Ed Maste Contact: Ed Schouten Contact: Jean-S=E9bastien P=E9dron Contact: Warren Block The vt(4) (aka Newcons) project provides a replacement for the legacy syscons system console. It brings a number of improvements, including better integration with graphics modes and broader character set support. A large number of improvements were committed to vt(4) over the last three months. Jean-S=E9bastien P=E9dron fixed significant performance regressions observed with vt_vga, particularly noticeable on virtual machines. Stefan Esser converted and cleaned up all of the keyboard map files for use with vt(4). The EFI framebuffer driver and the ofwfb driver now work with the xf86-video-scfb X11 video driver, supporting native-resolution (albeit unaccelerated) X. The fixes and improvements have all been merged and will be available in the upcoming FreeBSD 10.1 release. Open tasks: 1. Implement the remaining features supported by vidcontrol(1). 2. Write manual pages for vt(4) drivers and kernel interfaces. 3. Support direct handling of keyboards by the kbd device (without kbdmux(4)). 4. CJK fonts. This is in progress. 5. Switch to vt(4) by default. 6. Implement compatibility mode to be able to use single-byte charsets/key-codes in vt(4). __________________________________________________________________ Updating OpenCrypto URL: https://p4db.freebsd.org/depotTreeBrowser.cgi?FSPC=3D//depot/projects/op= e ncrypto URL: http://freebsdfoundation.blogspot.com/2014/08/freebsd-foundation-announ ces-ipsec.html Contact: John-Mark Gurney The project adds support for the AES-GCM and AES-CTR cryptography modes to the OpenCrypto framework. Both software and AES-NI accelerated versions are now functional and working. Ermal Lu=E7i (eri@) is working on adding support for these additional modes to IPsec. This project is sponsored by The FreeBSD Foundation , and Netgate . Open tasks: 1. Create a test suite for the most common modes. __________________________________________________________________ FreeBSD on Newer ARM Boards URL: https://github.com/tsgan/qualcomm Contact: Ganbold Tsagaankhuu Work on initial support of the IFC6410 board, which was stopped due to a bricked bootloader, has been started again. This board has the Qualcomm Snapdragon S4 SoC, featuring the Krait CPU. This CPU is considered a "platform" for use in smartphones, tablets, and smartbook devices. Krait has many similarities with the ARM Cortex-A15 CPU and is also based on the ARMv7 instruction set. These peripherals are working: * Qualcomm High Speed UART driver for MSM 7000/8000 series chips (included in src tree) * Krait Timer Open tasks: 1. Get the MMC driver working. May need more help from experts. __________________________________________________________________ FreeBSD/arm64 URL: http://svnweb.freebsd.org/base/projects/arm64/ Contact: Andrew Turner Until recently, all ARM CPU designs were 32-bit only. With the introduction of the ARMv8 architecture, ARM has added a new 64-bit mode. This new mode has been named AArch64. Arm64 is the name of the in-progress port of FreeBSD to ARMv8 CPUs when in AArch64 mode. Since the last status report, FreeBSD has started to execute userland instructions. This includes implementing more of the needed kernel functions to handle creation of processes. Using clang to compile userland has found a few issues with the version in the base system. These issues are expected to be resolved when clang 3.5 is imported. Initial support for device drivers has been added. This includes the start of the bus_space functions and interrupt handling. This allowed the existing timer and interrupt controller drivers from armv6 to be used as these devices are similar. The FDT data is now being passed from the loader to the kernel using the standard mechanism. The pmap implementation has been changed to be based on the amd64 code. This fixes a number of issues with the old implementation. Open tasks: 1. Boot to multi-user mode 2. Get dynamic libraries working 3. Test on real hardware __________________________________________________________________ LLDB Debugger Port URL: https://wiki.FreeBSD.org/lldb Contact: Ed Maste LLDB is the debugger project associated with Clang/LLVM. It supports the Mac OS X, Linux, and FreeBSD platforms, with Windows support under development. It builds on existing components in the larger LLVM project, for example using Clang's expression parser and LLVM's disassembler. Work over the last three months consisted mainly of maintenance, ensuring that the upstream FreeBSD port continues to build and that testsuite failures are promptly addressed. I plan to import a new LLDB snapshot after the base system Clang is updated to 3.5. Some upstream improvements that will be in that import include: * Ability to specify a count to thread step-* operations. * Ongoing AArch64 development. * Significant progress on the lldb-gdbserver debug stub. * I/O handling improvements. * A much faster C++ name demangler for most symbols. A proof-of-concept implementation of kernel debugging support for amd64 was completed as part of Google Summer of Code. It is not ready to be committed, but will form the basis for upcoming kernel debugging support. This project is sponsored by DARP/AFRL, SRI International, and University of Cambridge. Open tasks: 1. Port remote debug stub (lldb-gdbserver) from Linux to FreeBSD. 2. Add support for local and core file kernel debugging. 3. Implement, fix or test support on all non-amd64 architectures. 4. Verify cross-debugging. 5. Investigate and fix test suite failures. 6. Package LLDB as a port. 7. Enable by default in the base system for working architectures. __________________________________________________________________ LLVM Address Sanitizer (Asan) URL: https://code.google.com/p/address-sanitizer/ URL: http://clang.llvm.org/docs/AddressSanitizer.html URL: http://lab.llvm.org:8011/builders/sanitizer_x86_64-freebsd URL: http://lists.freebsd.org/pipermai=B3svn-src-head/2014-July/060270.html URL: http://lists.freebsd.org/pipermai=B3svn-src-head/2014-July/060504.html Contact: Viktor Kuzutov The LLVM address sanitizer (Asan) is a fast memory error detector that can detect use-after-free errors and buffer overflows. It has been ported to FreeBSD. The mainline version of LLVM is known to pass all of the tests in the LLVM and Asan test suites without unexpected failures on FreeBSD 10.0. A buildbot running sanitizer tests under FreeBSD stable/10 has been established. See the Links section. To make it possible to run programs with sanitizer checks enabled on FreeBSD, a new sysctl named kern.proc_vmmap_skip_resident_count has been added. See the Links section. Running the address sanitizer checks on stable/10 requires this sysctl to be set to 1. A similar work is in progress to add FreeBSD support to the thread sanitizer (Tsan), which detects data races in parallel programs. __________________________________________________________________ SSE Variants of libc Routines for amd64 URL: http://trac.baldwin.cx:8080/freebsd/wiki/LibCSSE Contact: John Baldwin I have written SSE/AVX-optimized versions of a few libc routines for amd64. So far the list includes memcpy, memset, and strlen. For each routine I have written a simple regression test as well as performed some simple microbenchmarks on various AMD and Intel CPUs. The simplest routine is strlen which appears to be a general win in microbenchmarks. memcpy and memset have proven trickier as different variants can behave quite differently on different CPUs. At present, I do not yet have a patch relative to libc. Once I do, this will be suitable for more testing. I would like to see some real-world benchmarks that show measurable improvement before pushing any of this up into the tree. Open tasks: 1. Create a branch that holds a modified libc and is suitable for testing __________________________________________________________________ FreeBSD Python Ports URL: https://wiki.FreeBSD.org/Python URL: irc://freebsd-python@irc.freenode.net Contact: FreeBSD Python Team The FreeBSD Python team continued to improve the overall experience with Python-based software on FreeBSD. During the last quarter, the bsd.python.mk bits of the ports infrastructure were converted to the more modern USES format. Several options, such as support for easy_install, were deprecated or removed to make the infrastructure easier to maintain and less complex for port maintainers. The Python ports were refactored and simplified to improve maintainability and to get rid of long-standing issues due to the previously complex and error-prone build process. The Python 2 branch was updated to Python 2.7.8 and setuptools to 5.5.1. With the availability of pkg 1.3, installing Python packages and modules for different Python versions is now supported in the package management infrastructure. This allows us to remove the previously required port duplicates for Python 2 and Python 3. Open tasks: 1. Retire the Python 3 specific port duplicates 2. Convert ports to the new USES syntax 3. More tasks can be found on the team's wiki page (see Links). 4. To get involved, interested people can say hello on IRC and let us know their areas of interest! __________________________________________________________________ GNOME/FreeBSD URL: http://www.freebsd.org/gnome URL: https://wiki.gnome.org/Projects/Jhbuild/FreeBSD URL: http://marcuscom.com/downloads/marcusmerge Contact: FreeBSD GNOME Team GNOME is a desktop environment and graphical user interface that runs on top of a computer operating system. GNOME is part of the GNU Project and can be used with various Unix-like operating systems, including FreeBSD. MATE is a fork of GNOME 2. The MATE ports were updated to the 1.8 versions. Cairo, the vector graphics library used by GNOME, has been updated to 1.12. This allowed the merge of GNOME 3 to begin. We are currently doing test builds to find ports broken by the update and pruning ports that do not build any more because of incompatible updates. Gustau Perez started preliminary work on the next development version of GNOME in MC, to be ready for GNOME 3.15. We will skip 3.14 entirely. Open tasks: 1. Finish the GNOME 3.12 merge, and start tracking GNOME 3.15 (development series). __________________________________________________________________ KDE on FreeBSD URL: https://freebsd.kde.org/ URL: https://freebsd.kde.org/area51.php URL: https://wiki.freebsd.org/KDE URL: https://mail.kde.org/mailman/listinfo/kde-freebsd URL: http://portscout.freebsd.org/kde@freebsd.org.html Contact: KDE on FreeBSD team The KDE on FreeBSD team focuses on packaging and making sure the experience of KDE and Qt on FreeBSD is as good as possible. First of all, we are happy to announce that Alonso Schaich, longtime contributor to our experimental area51 repositories, has become a ports committer, mentored by KDE on FreeBSD members Raphael Kubo da Costa (rakuco@) and Max Brazhnikov (makc@). During this quarter, the team has kept most of the KDE and Qt ports up-to-date, working on the following releases: * CMake 3.0.1 and 3.0.2 * PyQt 4.11.1, SIP 4.16.2, QScintilla 2.8.3 * DigiKam 4.2.0 (in area51) * KDE 4.13.3, 4.14.0 and 4.14.1 (in area51) * KDE Telepathy 0.8.0 (in area51) Additionally, work on updating the Qt5 ports to the 5.3 series has begun, and we intend to commit the updated ports in our experimental area51 repository to the ports tree in Q4. Open tasks: 1. Updating out-of-date ports, see the Links Portscout entry for a list. 2. Committing all the updated ports we have been accumulating in our experimental repositories into the ports tree. __________________________________________________________________ The Graphics Stack on FreeBSD URL: https://wiki.freebsd.org/Graphics URL: http://trillian.chruetertee.ch/ports/browser/trunk URL: http://lists.freebsd.org/pipermai=B3freebsd-ports-announce/2014-October/ 000096.html URL: http://wiki.x.org/wiki/Events/XDC2014/ Contact: FreeBSD Graphics team The newest graphics stack (that is, the set of ports conditional on the WITH_NEW_XORG knob) was enabled on all architectures. The only regression is for users of Intel GPUs and FreeBSD 8.X or 9.0. Those releases lack the required kernel driver and therefore xf86-video-intel will not work (the last UMS-aware version does not work with xserver 1.12). Users can still use xf86-video-vesa if they cannot or do not want to update their FreeBSD workstation. Owners of Radeon GPUs can use xf86-video-ati-ums 6.14.6 with xserver 1.12 if the KMS driver is not available (that is, before FreeBSD 9.3). The old graphics stack will be removed with the next update to these ports. See the announcement in the Links section. Hardware context support was added to the i915 driver in both HEAD and 10.1-RELEASE. This will allow us to update libglapi, libGL, dri, libEGL and libglesv2 ports to a newer version of Mesa. The latest version is already available from our development ports tree (see the links section). Cairo was updated to 1.12. This will allow the FreeBSD GNOME team to upgrade pango and Gtk+ 3. Unfortunately, the update also revealed that xf86-video-intel 2.7.1 was in a much worse state than previously assumed. We will attend XDC 2014 (X.Org Developer's Conference) from October 8th through 10th in Bordeaux, France. The goal is to reconnect with graphics stack developers, who are mostly working with Linux these days. We will give a presentation on the current state of this stack on FreeBSD. See the XDC website in the Links section for the program and live streaming. Open tasks: 1. See the "Graphics" wiki page for up-to-date information. __________________________________________________________________ Xfce URL: https://wiki.freebsd.org/Xfce URL: http://www.redports.org/browser/olivierd/xfce4 URL: https://people.freebsd.org/~olivierd/xfce4-4.11-screencast.webm Contact: FreeBSD Xfce Team Xfce is a free software desktop environment for Unix and Unix-like platforms including FreeBSD. It aims to be fast and lightweight while still being visually appealing and easy to use. The Xfce team continues to keep each piece of the Xfce Desktop up to date. That is why we are working on the next stable release (no date scheduled). There were no major updates in the ports tree except for cosmetic changes this quarter. Major upcoming changes include: * Switch to the USES framework * Support both GTK2 and GTK3, with GTK2 being the default. * A GNOME-like default icons theme * Enhanced documentation (handbooks, FAQ) Below is a list of current ports in the devel repository (see link). * deskutils/xfce4-xkb-plugin 0.7.0 * deve=B3xfce4-dev-tools 4.11.0 * misc/xfce4-appfinder 4.11.0 * multimedia/xfce4-parole 0.6.1 and 0.7.0 * sysutils/garcon 0.3.0 * sysutils/xfce4-settings 4.11.3 * x11/libxfce4menu 4.11.1 * x11/libxfce4util 4.11.0 * x11-wm/xfce4-desktop 4.11.8 * x11-wm/xfce4-panel 4.11.1 * x11-wm/xfce4-session 4.11.0 There are also two new ports * deskutils/xfce4-volumed-pulse 0.2.0 * x11/xfce4-dashboard 0.2.3 and 0.3.2 For more details, please see our wiki page in the Links section. Open tasks: 1. Finish patching the ACPI helper (xfce4-power-manager). 2. Continue to work on documentation, especially the Porter's Handbook, and creata a FAQ). __________________________________________________________________ Handbook ezjail Section URL: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails-ezjail .html Contact: Warren Block ezjail is a very popular jails management utility, but was only mentioned in passing in the Handbook. This new section describes basic setup and usage. An in-depth example shows how to create and configure a jail. It also serves as an example of how to run a simple caching-only BIND in a jail. __________________________________________________________________ Michael Lucas Books URL: http://blather.michaelwlucas.com/archives/2088 URL: http://blather.michaelwlucas.com/archives/2119 URL: https://www.tiltedwindmillpress.com/?product=3Dfreebsd-mastery-storage-e= s sentials Contact: Michael Lucas Lucas is working on a series of small FreeBSD books. The first one, FreeBSD Mastery: Storage Essentials, is underway, and covers GEOM, gpart, MBR, UFS, GELI, GBDE, disk sector alignment, and more. You can pre-order the book at a discount from his web site, or wait for it to hit print and all major ebook retailers. Get status updates on his blog, or check @mwlauthor on Twitter. Open tasks: 1. Lucas needs to write faster. __________________________________________________________________ ZFS Chapter of the Handbook URL: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/zfs.html Contact: Allan Jude Contact: Benedict Reuschling Contact: Warren Block ZFS is one of the premier features of FreeBSD, and the quality of the documentation should match that of other important features. Much of the original documentation from Sun and Oracle has disappeared, moved, or is about the proprietary version of ZFS. The OpenZFS project does not provide much documentation and instead provides users with a few links, including the FreeBSD Handbook. New users have many questions about ZFS and yet there exists a great deal more bad advice about ZFS than proper documentation. After over a year of work, a new ZFS chapter has been added to the FreeBSD Handbook. Over 20,000 words describe the basics of creating, managing, and maintaining a ZFS pool. Advanced features like compression, deduplication, and delegation are covered. The chapter also contains a glossary of terms, explaining a number of the concepts unique to ZFS, and documents some of the many sysctl variables that can be used for tuning. The remaining work to be done is in the FAQ section, which aims to help users address the most common questions or problems they might face with ZFS. We would like to hear experiences, questions, misconceptions, gotchas, stumbling blocks and suggestions for the FAQ section from other users. A use cases section that highlights some of the cases where ZFS provides advantages over traditional file systems is also planned. Please send suggestions to the docs mailing list. This project is sponsored by ScaleEngine Inc.. Open tasks: 1. Technical review by Matt Ahrens (co-creator of ZFS) 2. Improve the delegation section 3. Improve the tuning section, and cover recently added sysctls 4. Add a section on jails and the jailed property 5. Add an FAQ section 6. Add a Use Cases section 7. General editing and review __________________________________________________________________ The FreeBSD Foundation URL: http://www.FreeBSDFoundation.org/ URL: http://freebsdjournal.com/ Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Most of the funding is used to support FreeBSD development projects, conferences, and developer summits, purchase equipment to grow and improve the FreeBSD infrastructure, and provide legal support for the Project. We published our fourth issue of the FreeBSD Journal. We have over 4500 subscriptions to date. Work continued on adding support for the Dynamic Edition which will be available soon. The fifth issue is also due out soon. Foundation staff member Konstantin Belousov wrapped up the PostgreSQL performance investigation project. Kostik reran the benchmarks as a configuration error may have affected earlier results. Improvements arising from the investigation are merged to the FreeBSD 10 development branch and will be in the 10.1 release. Kostik also committed a variety of virtual memory and file system bug fixes and improvements. Over the quarter, Foundation staff member Edward Napiera=B3a refined the new autofs-based automounter and incorporated feedback from testers in enterprise and university contexts. The automounter is available in the development branch of FreeBSD and will be included in FreeBSD 10.1. Edward also supported engineers at Chelsio in preparing iSCSI offload support for Chelsio's 10- and 40-gigabit per second Ethernet adapters. Ed Maste, our project manager, tested and integrated UEFI system boot and new vt(4) console work into the release branch for the upcoming FreeBSD 10.1 release. He committed a number of small toolchain and build infrastructure improvements. He also wrote an article on LLDB for the FreeBSD Journal and presented the LLDB work at EuroBSDCon. FreeBSD Foundation Systems Administrator and Release Engineer Glen Barber continued work on finalizing the 9.3-RELEASE process, followed by starting the 10.1-RELEASE process. Work has continued on producing regularly-updated FreeBSD development snapshot builds for the various supported architectures, which include amd64, i386, ia64, powerpc, powerpc64, sparc64, and arm. In addition, work has been committed to a project branch which allows FreeBSD virtual machine disk images to be produced by default as part of the release process. A plan has been put together for the upcoming Secure Boot work. More hardware has been purchased to support FreeBSD infrastructure at NYI and Sentex. We announced a collaboration between the Foundation and Cavium to deliver a FreeBSD ARMv8 based implementation. We signed a license agreement with Oracle to get access to the TCKs for Java 7 and 8. Robert Watson ran and organized the Cambridge Developer Summit. We provided a travel grant to a Google Summer of Code student to attend the summit. We provided a travel grant to a developer who organized and ran BSDDay in Argentina. We were a Gold Sponsor for EuroBSDCon 2014 and sponsored the Developer Summit. We provided 4 travel grants to assist FreeBSD contributors with their travel expenses to attend the conference. We also had 6 board/staff members attend the conference and some gave talks, tutorials, and chaired some sessions. We held our Fall Fundraising campaign there and raised over $2,000 in donations from attendees. We organized the Silicon Valley Vendor/Developer Summit that is happening November 3 and 4. Kirk McKusick, Robert Watson, and George Neville-Neil published the second edition of "The Design and Implementation of the FreeBSD Operating System." Kirk McKusick presented a 2-day tutorial on the FreeBSD kernel and gave a talk on the implementation of ZFS at EuroBSDCon. Dru Lavigne attended Fossetcon: September 11-13 (fossetcon.org). We created new recruiting fliers for upcoming events, including the Grace Hopper conference. We started sending out Foundation monthly update emails to keep the FreeBSD community informed on some of the activities we did the previous month to support FreeBSD. __________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGgBAEBCgAGBQJUPZwDAAoJECjZpvNk63USKbkMH0Q4dV1ZPR5PwkJXLW9HV8Ap wllhTQ9OG3kjq73nMkRpTI0xoGvldwAWbIXfAw1g0LfooewgImx4eLNBX858mYHA IQtafoDDrH2retKtUsDiobsoTAAbMjtRJDZJ0sd+sMWr9y59CkdvaLhnNLeQni7w jwIlDviZQYPyY0upTgXitb0sDN0K3W0ys1AmQoVYpClfn8N4qGKuCzWX95linj4R ykB3SSSeN1rI6dZhSR8H1Uc6aCv3D3gokP3sbwADYG6A321TAYCEtj7uQzTCO+V7 uZNn1LrhFQ8dT4Es8VU2FCbW4qdenFy2I5/86o/PF46kNoEnuOoCLxTcUa7UCtHj OtA4g/k9J3FKjOAiufMaAP44xy+fPvFPJWI88kwaSv/npX3VyhwNR3MN2RNUNEiJ HMm/ImuYIWCuFTqvVzAiWWZxxXxrzMAbdZCNiRmFhmv5KJznhnWkUvUI8CRqtMVF ZfANAYYgcZ8qqmeFpo2K/sDhsDbYu5IU9YY60MOJfOBcnQg=3D =3D3AH2 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Oct 16 03:34:18 2014 Return-Path: Delivered-To: freebsd-current@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 9673FC2B; Thu, 16 Oct 2014 03:34:18 +0000 (UTC) Received: from mx2.shrew.net (mx2.shrew.net [38.97.5.132]) (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 69842D42; Thu, 16 Oct 2014 03:34:18 +0000 (UTC) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx2.shrew.net (8.14.7/8.14.7) with ESMTP id s9G3XIvO048940; Wed, 15 Oct 2014 22:33:18 -0500 (CDT) (envelope-from mgrooms@shrew.net) Message-Id: <201410160333.s9G3XIvO048940@mx2.shrew.net> Received: from [IPv6:2607:fb90:b06:4225:fa9d:25d:af4c:dcc7] (unknown [172.56.14.182]) by mail.shrew.net (Postfix) with ESMTPSA id 115A518ADFE; Wed, 15 Oct 2014 22:33:07 -0500 (CDT) Date: Wed, 15 Oct 2014 22:30:44 -0500 Subject: Re: HEADS UP: Merging projects/bhyve_svm to HEAD From: Matthew Grooms To: Anish Gupta MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx2.shrew.net [10.24.10.11]); Wed, 15 Oct 2014 22:33:18 -0500 (CDT) Cc: freebsd-current@freebsd.org, Neel Natu , freebsd-virtualization@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 03:34:18 -0000 RmFudGFzdGljIG5ld3MhIEdyZWF0bHkgYXBwcmVjaWF0ZWQuCgotTWF0dGhldwoKT24gT2N0IDE1 LCAyMDE0IDEwOjAwIFBNLCBBbmlzaCBHdXB0YSA8YWtndXB0M0BnbWFpbC5jb20+IHdyb3RlOgo+ Cj4gSGkgYWxsLCAKPgo+IFRoZSBwcm9qZWN0cy9iaHl2ZV9zdm0gYnJhbmNoIGlzIHJlYWR5IHRv IGJlIG1lcmdlZCB0byBIRUFELiAKPgo+IFRoaXMgYnJhbmNoIGNvbnRhaW5zIHBhdGNoZXMgdG8g Ymh5dmUgdG8gZW5hYmxlIGl0IHRvIHdvcmsgb24gQU1EIAo+IHByb2Nlc3NvcnMgd2l0aCBTVk0v QU1ELVYgaGFyZHdhcmUgZXh0ZW5zaW9uc1sxXS4gUHJldHR5IG11Y2ggYW55IEFNRCAKPiBwcm9j ZXNzb3Igc2luY2UgMjAxMCB3aWxsIGhhdmUgdGhlIGZlYXR1cmVzIHJlcXVpcmVkIGJ5IGJoeXZl LiAKPgo+IGJoeXZlIG9uIEFNRCBzdXBwb3J0cyAoYWxtb3N0KSBhbGwgdGhlIGZlYXR1cmVzIGF2 YWlsYWJsZSB3aXRoIEludGVsIAo+IFsyXS4gQWxsIGd1ZXN0IE9TZXMgc3VwcG9ydGVkIG9uIElu dGVsIGFyZSBzdXBwb3J0ZWQgb24gQU1ELiBBbGwgdGhlIAo+IGJoeXZlLXJlbGF0ZWQgdXRpbGl0 aWVzIGZ1bmN0aW9uIHNpbWlsYXJseSBvbiBib3RoIEludGVsIGFuZCBBTUQgCj4gcGxhdGZvcm1z IFszXS4gCj4KPiBUaGUgcGF0Y2ggYWdhaW5zdCBIRUFEIHJldmlzaW9uIDI3MzA2NiBpcyBhdmFp bGFibGUgZm9yIHJldmlldyBhbmQgdGVzdGluZzogCj4gaHR0cHM6Ly9wZW9wbGUuZnJlZWJzZC5v cmcvfm5lZWwvYmh5dmUvYmh5dmVfc3ZtLmRpZmYgW05lZWzigJlzIHdlYiBkaXJlY3RvcnldIAo+ Cj4gWzFdOiBodHRwOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL1g4Nl92aXJ0dWFsaXphdGlvbiAK PiBbMl06IGJoeXZlIGRvZXNuJ3Qgc3VwcG9ydCBQQ0kgcGFzc3RocnUgb24gQU1EIGF0IHRoaXMg dGltZSAKPiBbM106IGJoeXZlY3RsIGhhcyBncm93biBzb21lIHByb2Nlc3Nvci1zcGVjaWZpYyBv cHRpb25zIAo+Cj4gVGhhbmtzIGFuZCByZWdhcmRzLCAKPiBQZXRlciwgTmVlbCAmIEFuaXNoW2Fr Z3VwdDNAZ21haWwuY29tXSAKPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXyAKPiBmcmVlYnNkLXZpcnR1YWxpemF0aW9uQGZyZWVic2Qub3JnIG1haWxpbmcg bGlzdCAKPiBodHRwOi8vbGlzdHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmVlYnNk LXZpcnR1YWxpemF0aW9uIAo+IFRvIHVuc3Vic2NyaWJlLCBzZW5kIGFueSBtYWlsIHRvICJmcmVl YnNkLXZpcnR1YWxpemF0aW9uLXVuc3Vic2NyaWJlQGZyZWVic2Qub3JnIiAK From owner-freebsd-current@FreeBSD.ORG Thu Oct 16 05:56:44 2014 Return-Path: Delivered-To: freebsd-current@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 F0AFF89F; Thu, 16 Oct 2014 05:56:43 +0000 (UTC) Received: from aslan.scsiguy.com (www.scsiguy.com [70.89.174.89]) (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 A781BBBF; Thu, 16 Oct 2014 05:56:43 +0000 (UTC) Received: from [192.168.0.61] (jt-mbp.home.scsiguy.org [192.168.0.61]) (authenticated bits=0) by aslan.scsiguy.com (8.14.9/8.14.9) with ESMTP id s9G5uXK8078988 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Oct 2014 23:56:35 -0600 (MDT) (envelope-from gibbs@FreeBSD.org) From: "Justin T. Gibbs" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: OOM killer and kernel cache reclamation rate limit in vm_pageout_scan() Date: Wed, 15 Oct 2014 23:56:33 -0600 Message-Id: To: freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Cc: alc@FreeBSD.org, Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 05:56:44 -0000 avg pointed out the rate limiting code in vm_pageout_scan() during = discussion about PR 187594. While it certainly can contribute to the = problems discussed in that PR, a bigger problem is that it can allow the = OOM killer to be triggered even though there is plenty of reclaimable = memory available in the system. Any load that can consume enough pages = within the polling interval to hit the v_free_min threshold (e.g. = multiple 'dd if=3D/dev/zero of=3D/file/on/zfs') can make this happen. The product I=92m working on does not have swap configured and treats = any OOM trigger as fatal, so it is very obvious when this happens. :-) I=92ve tried several things to mitigate the problem. The first was to = ignore rate limiting for pass 2. However, even though ZFS is guaranteed = to receive some feedback prior to OOM being declared, my testing showed = that a trivial load (a couple dd operations) could still consume enough = of the reclaimed space to leave the system below its target at the end = of pass 2. After removing the rate limiting entirely, I=92ve so far = been unable to kill the system via a ZFS induced load. I understand the motivation behind the rate limiting, but the current = implementation seems too simplistic to be safe. The documentation for = the Solaris slab allocator provides good motivation for their approach = of using a =93sliding average=94 to reign in temporary bursts of usage = without unduly harming efficient service for the recorded steady-state = memory demand. Regardless of the approach taken, I believe that the OOM = killer must be a last resort and shouldn=92t be called when there are = caches that can be culled. One other thing I=92ve noticed in my testing with ZFS is that it needs = feedback and a little time to react to memory pressure. Calling it=92s = lowmem handler just once isn=92t enough for it to limit in-flight writes = so it can avoid reuse of pages that it just freed up. But, it doesn=92t = take too long to react (> 1sec in the profiling I=92ve done). Is there = a way in vm_pageout_scan() that we can better record that progress is = being made (pages were freed in the pass, even if some/all of them were = consumed again) and allow more passes before the OOM killer is invoked = in this case? =97 Justin From owner-freebsd-current@FreeBSD.ORG Thu Oct 16 06:10:44 2014 Return-Path: Delivered-To: freebsd-current@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 481A3CC7; Thu, 16 Oct 2014 06:10:44 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id EDB84CBD; Thu, 16 Oct 2014 06:10:42 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA13000; Thu, 16 Oct 2014 09:10:40 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1XeeGm-000AnG-1f; Thu, 16 Oct 2014 09:10:40 +0300 Message-ID: <543F612A.9060805@FreeBSD.org> Date: Thu, 16 Oct 2014 09:09:46 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "Justin T. Gibbs" , freebsd-current@FreeBSD.org Subject: Re: OOM killer and kernel cache reclamation rate limit in vm_pageout_scan() References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: alc@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 06:10:44 -0000 On 16/10/2014 08:56, Justin T. Gibbs wrote: > avg pointed out the rate limiting code in vm_pageout_scan() during discussion > about PR 187594. While it certainly can contribute to the problems discussed > in that PR, a bigger problem is that it can allow the OOM killer to be > triggered even though there is plenty of reclaimable memory available in the > system. Any load that can consume enough pages within the polling interval > to hit the v_free_min threshold (e.g. multiple 'dd if=/dev/zero > of=/file/on/zfs') can make this happen. > > The product I’m working on does not have swap configured and treats any OOM > trigger as fatal, so it is very obvious when this happens. :-) > > I’ve tried several things to mitigate the problem. The first was to ignore > rate limiting for pass 2. However, even though ZFS is guaranteed to receive > some feedback prior to OOM being declared, my testing showed that a trivial > load (a couple dd operations) could still consume enough of the reclaimed > space to leave the system below its target at the end of pass 2. After > removing the rate limiting entirely, I’ve so far been unable to kill the > system via a ZFS induced load. > > I understand the motivation behind the rate limiting, but the current > implementation seems too simplistic to be safe. The documentation for the > Solaris slab allocator provides good motivation for their approach of using a > “sliding average” to reign in temporary bursts of usage without unduly > harming efficient service for the recorded steady-state memory demand. > Regardless of the approach taken, I believe that the OOM killer must be a > last resort and shouldn’t be called when there are caches that can be > culled. FWIW, I have this toy branch: https://github.com/avg-I/freebsd/compare/experiment/uma-cache-trimming Not all commits are relevant to the problem and some things are unfinished. Not sure if the changes would help your case either... > One other thing I’ve noticed in my testing with ZFS is that it needs feedback > and a little time to react to memory pressure. Calling it’s lowmem handler > just once isn’t enough for it to limit in-flight writes so it can avoid reuse > of pages that it just freed up. But, it doesn’t take too long to react (> I've been thinking about this and maybe we need to make arc_memory_throttle() more aggressive on FreeBSD. I can't say that I really follow the logic of that code, though. > 1sec in the profiling I’ve done). Is there a way in vm_pageout_scan() that > we can better record that progress is being made (pages were freed in the > pass, even if some/all of them were consumed again) and allow more passes > before the OOM killer is invoked in this case? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Oct 16 06:11:07 2014 Return-Path: Delivered-To: freebsd-current@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 A3A54DCF; Thu, 16 Oct 2014 06:11:07 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4D59ACC8; Thu, 16 Oct 2014 06:11:06 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA13005; Thu, 16 Oct 2014 09:11:04 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1XeeHA-000AnF-LX; Thu, 16 Oct 2014 09:11:04 +0300 Message-ID: <543F612A.3060304@FreeBSD.org> Date: Thu, 16 Oct 2014 09:09:46 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "Justin T. Gibbs" , freebsd-current@FreeBSD.org Subject: Re: OOM killer and kernel cache reclamation rate limit in vm_pageout_scan() References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: alc@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 06:11:07 -0000 On 16/10/2014 08:56, Justin T. Gibbs wrote: > avg pointed out the rate limiting code in vm_pageout_scan() during discussion > about PR 187594. While it certainly can contribute to the problems discussed > in that PR, a bigger problem is that it can allow the OOM killer to be > triggered even though there is plenty of reclaimable memory available in the > system. Any load that can consume enough pages within the polling interval > to hit the v_free_min threshold (e.g. multiple 'dd if=/dev/zero > of=/file/on/zfs') can make this happen. > > The product I’m working on does not have swap configured and treats any OOM > trigger as fatal, so it is very obvious when this happens. :-) > > I’ve tried several things to mitigate the problem. The first was to ignore > rate limiting for pass 2. However, even though ZFS is guaranteed to receive > some feedback prior to OOM being declared, my testing showed that a trivial > load (a couple dd operations) could still consume enough of the reclaimed > space to leave the system below its target at the end of pass 2. After > removing the rate limiting entirely, I’ve so far been unable to kill the > system via a ZFS induced load. > > I understand the motivation behind the rate limiting, but the current > implementation seems too simplistic to be safe. The documentation for the > Solaris slab allocator provides good motivation for their approach of using a > “sliding average” to reign in temporary bursts of usage without unduly > harming efficient service for the recorded steady-state memory demand. > Regardless of the approach taken, I believe that the OOM killer must be a > last resort and shouldn’t be called when there are caches that can be > culled. FWIW, I have this toy branch: https://github.com/avg-I/freebsd/compare/experiment/uma-cache-trimming Not all commits are relevant to the problem and some things are unfinished. Not sure if the changes would help your case either... > One other thing I’ve noticed in my testing with ZFS is that it needs feedback > and a little time to react to memory pressure. Calling it’s lowmem handler > just once isn’t enough for it to limit in-flight writes so it can avoid reuse > of pages that it just freed up. But, it doesn’t take too long to react (> I've been thinking about this and maybe we need to make arc_memory_throttle() more aggressive on FreeBSD. I can't say that I really follow the logic of that code, though. > 1sec in the profiling I’ve done). Is there a way in vm_pageout_scan() that > we can better record that progress is being made (pages were freed in the > pass, even if some/all of them were consumed again) and allow more passes > before the OOM killer is invoked in this case? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Oct 16 08:10:22 2014 Return-Path: Delivered-To: freebsd-current@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 773EA9DB for ; Thu, 16 Oct 2014 08:10:22 +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 F0115A56 for ; Thu, 16 Oct 2014 08:10:21 +0000 (UTC) Received: by mail-la0-f48.google.com with SMTP id gi9so2401083lab.21 for ; Thu, 16 Oct 2014 01:10:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=/H+gqCHU5wF+Xw2VV7Lvmo/nF27TSXHvmU2LIR4rftI=; b=IDkCCk1pTouCZc0+2mGvn+H4hTFR0lRd3XJdRtBpaR2xPm97kbCIbxFXq22E8uzTGs rVF0dALmcBYB0uKl+oCTYgR/VryCv6pazXzQqthlODeyZpzvMCP9eNykp18c5JxnnVCH oAzjLapsbJDVip6CQN9BBsp3l9e2EUISY6x/5EFmMVChwhCq4LsZcsZgnHeziH83NXVf Vfu++yAMMBmwBxoFY5JbH+ygUYTo48vYDlOANtwhU4PBYSR7L0KElel+ScvarY1kQwgq 4hS5OET47VVSDr9w5uadUmhNKvy/KcgoZ7MUpbqsSjU5YqILSRNmkVeZOyZ1GO2gOhQH stvw== X-Received: by 10.152.22.74 with SMTP id b10mr17750402laf.16.1413447019807; Thu, 16 Oct 2014 01:10:19 -0700 (PDT) Received: from brick.home (addo146.neoplus.adsl.tpnet.pl. [79.184.66.146]) by mx.google.com with ESMTPSA id h1sm6891940lam.5.2014.10.16.01.10.18 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Oct 2014 01:10:19 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Thu, 16 Oct 2014 10:10:16 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Matthew Grooms Subject: Re: Resizing a zpool as a VMware ESXi guest ... Message-ID: <20141016081016.GA4670@brick.home> Mail-Followup-To: Matthew Grooms , freebsd-current@freebsd.org References: <543841B8.4070007@shrew.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <543841B8.4070007@shrew.net> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 08:10:22 -0000 On 1010T1529, Matthew Grooms wrote: > All, > > I am a long time user and advocate of FreeBSD and manage a several > deployments of FreeBSD in a few data centers. Now that these > environments are almost always virtual, it would make sense that FreeBSD > support for basic features such as dynamic disk resizing. It looks like > most of the parts are intended to work. Kudos to the FreeBSD foundation > for seeing the need and sponsoring dynamic increase of online UFS > filesystems via growfs. Unfortunately, it would appear that there are > still problems in this area, such as ... > > a) cam/geom recognizing when a drive's size has increased > b) zpool recognizing when a gpt partition size has increased > > For example, if I do an install of FreeBSD 10 on VMware using ZFS, I see > the following ... > > root@zpool-test:~ # gpart show > => 34 16777149 da0 GPT (8.0G) > 34 1024 1 freebsd-boot (512K) > 1058 4194304 2 freebsd-swap (2.0G) > 4195362 12581821 3 freebsd-zfs (6.0G) > > If I increase the VM disk size using VMware to 16G and rescan using > camcontrol, this is what I see ... "camcontrol rescan" does not force fetching the updated disk size. AFAIK there is no way to do that. However, this should happen automatically, if the "other side" properly sends proper Unit Attention after resizing. No idea why this doesn't happen with VMWare. Reboot obviously clears things up. [..] > Now I want the claim the additional 14 gigs of space for my zpool ... > > root@zpool-test:~ # zpool status > pool: zroot > state: ONLINE > scan: none requested > config: > > NAME STATE READ > WRITE CKSUM > zroot ONLINE 0 0 0 > gptid/352086bd-50b5-11e4-95b8-0050569b2a04 ONLINE 0 0 0 > > root@zpool-test:~ # zpool set autoexpand=on zroot > root@zpool-test:~ # zpool online -e zroot > gptid/352086bd-50b5-11e4-95b8-0050569b2a04 > root@zpool-test:~ # zpool list > NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT > zroot 5.97G 876M 5.11G 14% 1.00x ONLINE - > > The zpool appears to still only have 5.11G free. Lets reboot and try > again ... Interesting. This used to work; actually either of those (autoexpand or online -e) should do the trick. > root@zpool-test:~ # zpool set autoexpand=on zroot > root@zpool-test:~ # zpool online -e zroot > gptid/352086bd-50b5-11e4-95b8-0050569b2a04 > root@zpool-test:~ # zpool list > NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT > zroot 14.0G 876M 13.1G 6% 1.00x ONLINE - > > Now I have 13.1G free. I can add this space to any of my zfs volumes and > it picks the change up immediately. So the question remains, why do I > need to reboot the OS twice to allocate new disk space to a volume? > FreeBSD is first and foremost a server operating system. Servers are > commonly deployed in data centers. Virtual environments are now > commonplace in data centers, not the exception to the rule. VMware still > has the vast majority of the private virutal environment market. I > assume that most would expect things like this to work out of the box. > Did I miss a required step or is this fixed in CURRENT? Looks like genuine bugs (or rather, one missing feature and one bug). Filling PRs for those might be a good idea. From owner-freebsd-current@FreeBSD.ORG Thu Oct 16 08:17:07 2014 Return-Path: Delivered-To: freebsd-current@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 63710CFC; Thu, 16 Oct 2014 08:17:07 +0000 (UTC) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::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 32EBCB98; Thu, 16 Oct 2014 08:17:07 +0000 (UTC) Received: by mail-pa0-f42.google.com with SMTP id bj1so2992912pad.15 for ; Thu, 16 Oct 2014 01:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=yVE6AKCJ0k6ANwFOp89B4DbGXopNq36yhuwytoh93eY=; b=LTbXPrzU+lHYssZ+E3PjF6ppMAxY3FsVar1tBpd/KS53FSypvF7GWzJ2pwv8UHSPZH K2Sw/qnWjQl5dNrJaY3Pa1Hljs5+9egqTRiGhvGQBhve5DkoEYPjv6K50j02u9VBzwE1 TjLyTApw8+MvEufsTcm1+CPUHJ1i3QNdLr8i6VryIQdZTQyJKiqN3akxEX1Got2DaZB1 mbf9vj0gJS65oQYXZkjTE9O8PtXaJhA/fYuCluzLfDnsYxi6wbbbG/8RWaMdSKg3w7B+ 9HQi7pbcwXdHkgZ1rHLIC/qgR5gIYmolkuZAN+BJ+cVreZAva6Xv2u44U6SSmHxOZns2 3XWw== X-Received: by 10.66.97.39 with SMTP id dx7mr18178354pab.65.1413447426752; Thu, 16 Oct 2014 01:17:06 -0700 (PDT) Received: from [10.90.168.70] (mobile-166-137-215-085.mycingular.net. [166.137.215.85]) by mx.google.com with ESMTPSA id c15sm19058857pbu.15.2014.10.16.01.17.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Oct 2014 01:17:06 -0700 (PDT) References: <543841B8.4070007@shrew.net> <20141016081016.GA4670@brick.home> Mime-Version: 1.0 (1.0) In-Reply-To: <20141016081016.GA4670@brick.home> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D257) From: Garrett Cooper Subject: Re: Resizing a zpool as a VMware ESXi guest ... Date: Thu, 16 Oct 2014 01:17:04 -0700 To: =?utf-8?Q?Edward_Tomasz_Napiera=C5=82a?= Cc: Matthew Grooms , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 08:17:07 -0000 > On Oct 16, 2014, at 1:10, Edward Tomasz Napiera=C5=82a = wrote: > "camcontrol rescan" does not force fetching the updated disk size. > AFAIK there is no way to do that. However, this should happen > automatically, if the "other side" properly sends proper Unit Attention > after resizing. No idea why this doesn't happen with VMWare. > Reboot obviously clears things up. >=20 > [..] Is open-vm-tools installed? I ask because if I don't have it installed and the kernel modules loaded, VM= ware doesn't notify the guest OS of disks being added/removed. Also, what disk controller are you using? Cheers.= From owner-freebsd-current@FreeBSD.ORG Thu Oct 16 09:08:57 2014 Return-Path: Delivered-To: freebsd-current@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 E00CB81B; Thu, 16 Oct 2014 09:08:56 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 7A8561FA; Thu, 16 Oct 2014 09:08:56 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id BE3E320E7088C; Thu, 16 Oct 2014 09:08:55 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.8 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,RDNS_DYNAMIC,STOX_REPLY_TYPE,TVD_FINGER_02 autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id 163F420E70885; Thu, 16 Oct 2014 09:08:54 +0000 (UTC) Message-ID: <94C0652FCB034AE195AECA2036D51D46@multiplay.co.uk> From: "Steven Hartland" To: "Justin T. Gibbs" , References: Subject: Re: OOM killer and kernel cache reclamation rate limit in vm_pageout_scan() Date: Thu, 16 Oct 2014 10:08:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: alc@FreeBSD.org, Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 09:08:57 -0000 Unfortunately ZFS doesn't prevent new inflight writes until it hits zfs_dirty_data_max, so while what your suggesting will help, if the writes come in quick enough I would expect it to still be able to out run the pageout. ----- Original Message ----- From: "Justin T. Gibbs" To: Cc: ; "Andriy Gapon" Sent: Thursday, October 16, 2014 6:56 AM Subject: OOM killer and kernel cache reclamation rate limit in vm_pageout_scan() avg pointed out the rate limiting code in vm_pageout_scan() during discussion about PR 187594. While it certainly can contribute to the problems discussed in that PR, a bigger problem is that it can allow the OOM killer to be triggered even though there is plenty of reclaimable memory available in the system. Any load that can consume enough pages within the polling interval to hit the v_free_min threshold (e.g. multiple 'dd if=/dev/zero of=/file/on/zfs') can make this happen. The product I’m working on does not have swap configured and treats any OOM trigger as fatal, so it is very obvious when this happens. :-) I’ve tried several things to mitigate the problem. The first was to ignore rate limiting for pass 2. However, even though ZFS is guaranteed to receive some feedback prior to OOM being declared, my testing showed that a trivial load (a couple dd operations) could still consume enough of the reclaimed space to leave the system below its target at the end of pass 2. After removing the rate limiting entirely, I’ve so far been unable to kill the system via a ZFS induced load. I understand the motivation behind the rate limiting, but the current implementation seems too simplistic to be safe. The documentation for the Solaris slab allocator provides good motivation for their approach of using a “sliding average” to reign in temporary bursts of usage without unduly harming efficient service for the recorded steady-state memory demand. Regardless of the approach taken, I believe that the OOM killer must be a last resort and shouldn’t be called when there are caches that can be culled. One other thing I’ve noticed in my testing with ZFS is that it needs feedback and a little time to react to memory pressure. Calling it’s lowmem handler just once isn’t enough for it to limit in-flight writes so it can avoid reuse of pages that it just freed up. But, it doesn’t take too long to react (> 1sec in the profiling I’ve done). Is there a way in vm_pageout_scan() that we can better record that progress is being made (pages were freed in the pass, even if some/all of them were consumed again) and allow more passes before the OOM killer is invoked in this case? — Justin _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Oct 16 10:53:45 2014 Return-Path: Delivered-To: freebsd-current@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 0C389CDF; Thu, 16 Oct 2014 10:53:45 +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 7197AFF7; Thu, 16 Oct 2014 10:53:44 +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 s9GArgBm083717; Thu, 16 Oct 2014 12:53:42 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 3987237C9; Thu, 16 Oct 2014 12:53:42 +0200 (CEST) Message-ID: <543FA3B5.5040807@omnilan.de> Date: Thu, 16 Oct 2014 12:53:41 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Ian Lepore Subject: Re: installincludes, bsd.incs.mk and param.h References: <543D3671.8040004@omnilan.de> <20141014145253.GD2078@albert.catwhisker.org> <543D4046.9030809@omnilan.de> <1413301063.12052.396.camel@revolution.hippie.lan> <543D4AAA.6040204@omnilan.de> <1413306052.12052.399.camel@revolution.hippie.lan> In-Reply-To: <1413306052.12052.399.camel@revolution.hippie.lan> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4116FC56734C11967F80E8EB" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Thu, 16 Oct 2014 12:53:42 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) Cc: FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 10:53:45 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4116FC56734C11967F80E8EB Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Bez=FCglich Ian Lepore's Nachricht vom 14.10.2014 19:00 (localtime): =85 > The old code that used to work for you got the version via sysctl, so I= > was recommending that you keep doing that yourself, since it's no longe= r > built in to bsd.ports.mk. =20 > > So just add "export OSVERSION=3D`sysctl kern.osreldate` to your script > that kicks off this update process, something like that. Thank you for your support! Like for many others, the former OSVERSION detection wasn't working very well for me with jail environments (python broke e.g.). Therefore I had worked arround it defferently, nonetheless I'm not happy with reverting to the old behaviour. Since /usr/include gets populated regardless if "WITHOUT_TOOLCHAIN=3Dtrue= " was set in src.conf, I think it's a good idea to have the one param.h also installed, regardless of the option. Please see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D194401 Thanks, -Harry --------------enig4116FC56734C11967F80E8EB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlQ/o7UACgkQLDqVQ9VXb8i98ACeJbOExMSPHue2SROtU5xUIo1a MhcAn3QbDUi2auRDd2wZ8w9FjJj+1lS4 =oaWI -----END PGP SIGNATURE----- --------------enig4116FC56734C11967F80E8EB-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 16 10:54:49 2014 Return-Path: Delivered-To: freebsd-current@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 A9599DFE; Thu, 16 Oct 2014 10:54:49 +0000 (UTC) Received: from mx2.paymentallianceintl.com (mx2.paymentallianceintl.com [216.26.158.171]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx2.paymentallianceintl.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6F08362; Thu, 16 Oct 2014 10:54:48 +0000 (UTC) Received: from firewall.mikej.com (162-230-214-65.lightspeed.lsvlky.sbcglobal.net [162.230.214.65]) by mx2.paymentallianceintl.com (8.14.5/8.13.8) with ESMTP id s9GAkcJi011381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Oct 2014 06:46:39 -0400 (EDT) (envelope-from mikej@mikej.com) Received: from mail.mikej.com ([192.168.6.63]) by firewall.mikej.com (8.14.9/8.14.9) with ESMTP id s9GAkBg2024035; Thu, 16 Oct 2014 06:46:33 -0400 (EDT) (envelope-from mikej@mikej.com) X-Authentication-Warning: firewall.mikej.com: Host [192.168.6.63] claimed to be mail.mikej.com MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 16 Oct 2014 06:46:11 -0400 From: Michael Jung To: Garrett Cooper Subject: Re: Resizing a zpool as a VMware ESXi guest ... In-Reply-To: References: <543841B8.4070007@shrew.net> <20141016081016.GA4670@brick.home> Message-ID: <5ca164a5bdd2d44d0b60a7fab5066fa2@mail.mikej.com> X-Sender: mikej@mikej.com User-Agent: Roundcube Webmail/1.0.2 Cc: owner-freebsd-current@freebsd.org, Matthew Grooms , =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 10:54:49 -0000 On 2014-10-16 04:17, Garrett Cooper wrote: >> On Oct 16, 2014, at 1:10, Edward Tomasz NapieraƂa >> wrote: > >> "camcontrol rescan" does not force fetching the updated disk size. >> AFAIK there is no way to do that. However, this should happen >> automatically, if the "other side" properly sends proper Unit >> Attention >> after resizing. No idea why this doesn't happen with VMWare. >> Reboot obviously clears things up. >> >> [..] > > Is open-vm-tools installed? > > I ask because if I don't have it installed and the kernel modules > loaded, VMware doesn't notify the guest OS of disks being > added/removed. > > Also, what disk controller are you using? > > Cheers. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" I duplicated this behavior. According to gpart The virtual disk does not grow until the freebsd guest is rebooted. FreeBSD freebsd10 10.0-RELEASE-p6 FreeBSD 10.0-RELEASE-p6 #0: Tue Jun 24 07:47:37 UTC 2014 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC pkg info -- amd64 open-vm-tools-nox11-1280544_8,1 Open VMware tools for FreeBSD VMware guests ESXi reported -- Running, version:2147483647 (3rd-party/Independent) ESXi-5.5-1331820(A00) Guest Hardware version 10 789 - S 0:00.54 /usr/local/bin/vmtoolsd -c /usr/local/share/vmware-tools/ Id Refs Address Size Name 1 12 0xffffffff80200000 15f03b0 kernel 2 1 0xffffffff81a12000 5209 fdescfs.ko 3 1 0xffffffff81a18000 2198 vmmemctl.ko 4 1 0xffffffff81a1b000 23d8 vmxnet.ko 5 1 0xffffffff81a1e000 2bf0 vmblock.ko 6 1 0xffffffff81a21000 81b4 vmhgfs.ko --mikej From owner-freebsd-current@FreeBSD.ORG Thu Oct 16 11:33:18 2014 Return-Path: Delivered-To: current@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 3264D833; Thu, 16 Oct 2014 11:33:18 +0000 (UTC) Received: from mail.jrv.org (adsl-70-243-84-11.dsl.austtx.swbell.net [70.243.84.11]) by mx1.freebsd.org (Postfix) with ESMTP id F109D682; Thu, 16 Oct 2014 11:33:17 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.jrv.org (Postfix) with ESMTP id B28D41A1D02; Thu, 16 Oct 2014 06:25:44 -0500 (CDT) Received: from mail.jrv.org ([127.0.0.1]) by localhost (zimbra64.housenet.jrv [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id QhW2_ibdt3fa; Thu, 16 Oct 2014 06:25:34 -0500 (CDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.jrv.org (Postfix) with ESMTP id D289A1A1CFA; Thu, 16 Oct 2014 06:25:34 -0500 (CDT) X-Virus-Scanned: amavisd-new at zimbra64.housenet.jrv Received: from mail.jrv.org ([127.0.0.1]) by localhost (zimbra64.housenet.jrv [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Mt5NHfUP045b; Thu, 16 Oct 2014 06:25:34 -0500 (CDT) Received: from [192.168.138.128] (BMX.housenet.jrv [192.168.3.140]) by mail.jrv.org (Postfix) with ESMTPSA id AB7B61A1CF7; Thu, 16 Oct 2014 06:25:34 -0500 (CDT) Message-ID: <543FAB3C.4090503@jrv.org> Date: Thu, 16 Oct 2014 06:25:48 -0500 From: "James R. Van Artsdalen" User-Agent: Mozilla/5.0 (Windows NT 5.0; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 Subject: Re: zfs recv hangs in kmem arena References: <54250AE9.6070609@jrv.org> In-Reply-To: <54250AE9.6070609@jrv.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 11:33:18 -0000 The zfs recv / kmem arena hang happens with -CURRENT as well as 10-STABLE, on two different systems, with 16GB or 32GB of RAM, from memstick or normal multi-user environments, Hangs usually seem to hapeen 1TB to 3TB in, but last night one run hung after only 4.35MB. On 9/26/2014 1:42 AM, James R. Van Artsdalen wrote: > FreeBSD BLACKIE.housenet.jrv 10.1-BETA2 FreeBSD 10.1-BETA2 #2 r272070M: > Wed Sep 24 17:36:56 CDT 2014 > james@BLACKIE.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64 > > With current STABLE10 I am unable to replicate a ZFS pool using zfs > send/recv without zfs hanging in state "kmem arena", within the first > 4TB or so (of a 23TB Pool). > > The most recent attempt used this command line > > SUPERTEX:/root# zfs send -R BIGTEX/UNIX@syssnap | ssh BLACKIE zfs recv > -duvF BIGTOX > > though local replications fail in kmem arena too. > > The two machines I've been attempting this on have 16BG and 32GB of RAM > each and are otherwise idle. > > Any suggestions on how to get around, or investigate, "kmem arena"? > > # top > last pid: 3272; load averages: 0.22, 0.22, 0.23 up > 0+08:25:02 01:32:07 > 34 processes: 1 running, 33 sleeping > CPU: 0.0% user, 0.0% nice, 0.1% system, 0.0% interrupt, 99.9% idle > Mem: 21M Active, 82M Inact, 15G Wired, 28M Cache, 450M Free > ARC: 12G Total, 24M MFU, 12G MRU, 23M Anon, 216M Header, 47M Other > Swap: 16G Total, 16G Free > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU > COMMAND > 1173 root 1 52 0 86476K 7780K select 0 124:33 0.00% sshd > 1176 root 1 46 0 87276K 47732K kmem a 3 48:36 0.00% zfs > 968 root 32 20 0 12344K 1888K rpcsvc 0 0:13 0.00% nfsd > 1009 root 1 20 0 25452K 2864K select 3 0:01 0.00% ntpd > ... From owner-freebsd-current@FreeBSD.ORG Thu Oct 16 11:39:19 2014 Return-Path: Delivered-To: freebsd-current@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 CC15CA0E; Thu, 16 Oct 2014 11:39:19 +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 6F1036C4; Thu, 16 Oct 2014 11:39:19 +0000 (UTC) Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s9GBdGw3084172; Thu, 16 Oct 2014 13:39:16 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id EDCD337D7; Thu, 16 Oct 2014 13:39:15 +0200 (CEST) Message-ID: <543FAE63.1040803@omnilan.de> Date: Thu, 16 Oct 2014 13:39:15 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: "O. Hartmann" Subject: Re: CURRENT: EFI boot failure References: <20140916020541.03c18d04.ohartman@zedat.fu-berlin.de> <54178607.1060305@freebsd.org> <541786BE.6010105@freebsd.org> <20140916075121.29989a53.ohartman@zedat.fu-berlin.de> <5417E20D.8070607@freebsd.org> <20140916230348.189e80cd.ohartman@zedat.fu-berlin.de> <5418B8C3.7040406@FreeBSD.org> <20140919152207.0473e213.ohartman@zedat.fu-berlin.de> <542183A6.7060802@omnilan.de> <542188DC.8000307@omnilan.de> <20141004084737.64b35fd8.ohartman@zedat.fu-berlin.de> In-Reply-To: <20141004084737.64b35fd8.ohartman@zedat.fu-berlin.de> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig283F5A5C256F93DB60D8471A" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Thu, 16 Oct 2014 13:39:17 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) Cc: Andriy Gapon , FreeBSD Current , Ed Maste , Nathan Whitehorn , Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 11:39:20 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig283F5A5C256F93DB60D8471A Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Bez=FCglich O. Hartmann's Nachricht vom 04.10.2014 08:47 (localtime): =85 >> Sorry, forget the suggestion, it doesn't work since it leads to CFLAG >> -march=3D"" and the same problem occurs. >> For my case this works: >> --- sys/boot/efi/Makefile.inc.orig 2014-09-23 16:22:46.000000000 = +0200 >> +++ sys/boot/efi/Makefile.inc 2014-09-23 16:46:30.000000000 +0200 >> @@ -2,6 +2,10 @@ >> =20 >> BINDIR?=3D /boot >> =20 >> +.if ${CPUTYPE} =3D=3D "core-avx2" >> +CPUTYPE=3D core-avx-i >> +.endif >> + >> .if ${MACHINE_CPUARCH} =3D=3D "i386" >> CFLAGS+=3D -march=3Di386 >> .endif >> >> JFI >> >> -Harry >> > Has this problem anyhow seriously been addressed? I run into this very = often on several > platforms with HAswell-based CPUs (other systems with IvyBridge or Sand= yBridge are still > to be migrated to UEFI boot, so I do not have any older architectures a= t hand to proof > whether this issue is still present or not on Non-AVX2 systems. > > If there is no progress so far, would it be well-advised to open a PR? Unofrtunately I don't really have qualified knwoledge about compiler optimazations nor any efi binary knwoledge. Opening a PR is really needed, this issue shouldn't be left unchecked. But I'd prefer if someone does it, who understands what Matt Fleming answered in http://lists.freebsd.org/pipermail/freebsd-current/2014-September/052354.= html Anyone? Thanks, -Harry --------------enig283F5A5C256F93DB60D8471A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlQ/rmMACgkQLDqVQ9VXb8gGlACffJxTTfQpFtt0vYavk+d46Ogo YbQAn0n5GZO+kNeEcXKzOkuWROb9GEBZ =cQxI -----END PGP SIGNATURE----- --------------enig283F5A5C256F93DB60D8471A-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 16 11:52:54 2014 Return-Path: Delivered-To: freebsd-current@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 01303CEB; Thu, 16 Oct 2014 11:52:53 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E70338E0; Thu, 16 Oct 2014 11:52:52 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA17343; Thu, 16 Oct 2014 14:52:44 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Xejbn-000B7s-PW; Thu, 16 Oct 2014 14:52:43 +0300 Message-ID: <543FB153.8000801@FreeBSD.org> Date: Thu, 16 Oct 2014 14:51:47 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Steven Hartland , "Justin T. Gibbs" , freebsd-current@FreeBSD.org Subject: Re: OOM killer and kernel cache reclamation rate limit in vm_pageout_scan() References: <94C0652FCB034AE195AECA2036D51D46@multiplay.co.uk> In-Reply-To: <94C0652FCB034AE195AECA2036D51D46@multiplay.co.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: alc@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 11:52:54 -0000 On 16/10/2014 12:08, Steven Hartland wrote: > Unfortunately ZFS doesn't prevent new inflight writes until it > hits zfs_dirty_data_max, so while what your suggesting will > help, if the writes come in quick enough I would expect it to > still be able to out run the pageout. As I've mentioned, arc_memory_throttle() also plays role in limiting the dirty data. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Oct 16 16:12:35 2014 Return-Path: Delivered-To: current@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 E39B2B71; Thu, 16 Oct 2014 16:12:34 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C20ABB92; Thu, 16 Oct 2014 16:12:34 +0000 (UTC) Received: from delphij-macbook.home.us.delphij.net (unknown [IPv6:2001:470:83bf:0:5da2:ad7b:ac1d:bf78]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id B7168238C9; Thu, 16 Oct 2014 09:12:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1413475954; x=1413490354; bh=wxT7FrlsPuEfeqYoRYbXS3edRIvGEGcpjiHDqajHzWQ=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=bSoLNYyLiClWytm3+wGgBMKRWqHtrTgLmihkZepw0OvmyOtdi7qOB7rPzIcO5Z17m MHWJHtD6Exguf+syOCRuyTJbFF+jAiy3Z66ekZ4QOb2SccRQ3y4MhRDIlXUESiAjIm IghvsDp5uIjdtDXTJuyP+eCjwIM+ieyzq7ggmHfE= Message-ID: <543FEE6F.5050007@delphij.net> Date: Thu, 16 Oct 2014 09:12:31 -0700 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: "James R. Van Artsdalen" Subject: Re: zfs recv hangs in kmem arena References: <54250AE9.6070609@jrv.org> <543FAB3C.4090503@jrv.org> In-Reply-To: <543FAB3C.4090503@jrv.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 16:12:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 10/16/14 4:25 AM, James R. Van Artsdalen wrote: > The zfs recv / kmem arena hang happens with -CURRENT as well as > 10-STABLE, on two different systems, with 16GB or 32GB of RAM, > from memstick or normal multi-user environments, > > Hangs usually seem to hapeen 1TB to 3TB in, but last night one run > hung after only 4.35MB. > > On 9/26/2014 1:42 AM, James R. Van Artsdalen wrote: >> FreeBSD BLACKIE.housenet.jrv 10.1-BETA2 FreeBSD 10.1-BETA2 #2 >> r272070M: Wed Sep 24 17:36:56 CDT 2014 >> james@BLACKIE.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64 >> >> With current STABLE10 I am unable to replicate a ZFS pool using >> zfs send/recv without zfs hanging in state "kmem arena", within >> the first 4TB or so (of a 23TB Pool). >> >> The most recent attempt used this command line >> >> SUPERTEX:/root# zfs send -R BIGTEX/UNIX@syssnap | ssh BLACKIE zfs >> recv -duvF BIGTOX >> >> though local replications fail in kmem arena too. >> >> The two machines I've been attempting this on have 16BG and 32GB >> of RAM each and are otherwise idle. >> >> Any suggestions on how to get around, or investigate, "kmem >> arena"? >> >> # top last pid: 3272; load averages: 0.22, 0.22, 0.23 >> up 0+08:25:02 01:32:07 34 processes: 1 running, 33 sleeping >> CPU: 0.0% user, 0.0% nice, 0.1% system, 0.0% interrupt, 99.9% >> idle Mem: 21M Active, 82M Inact, 15G Wired, 28M Cache, 450M Free >> ARC: 12G Total, 24M MFU, 12G MRU, 23M Anon, 216M Header, 47M >> Other Swap: 16G Total, 16G Free >> >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME >> WCPU COMMAND 1173 root 1 52 0 86476K 7780K select >> 0 124:33 0.00% sshd 1176 root 1 46 0 87276K 47732K >> kmem a 3 48:36 0.00% zfs 968 root 32 20 0 12344K >> 1888K rpcsvc 0 0:13 0.00% nfsd 1009 root 1 20 0 >> 25452K 2864K select 3 0:01 0.00% ntpd ... What does procstat -kk 1176 (or the PID of your 'zfs' process that stuck in that state) say? Cheers, -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUP+5vAAoJEJW2GBstM+ns0v4P/31s7geR2j22etrRnfReUxbb lbex0VkmLGm23TbTj2vpVce+ogBeA4zo6h4WzF/yYt2372MpWOfnEoVX2yOuuGku AFapewXS3UMXLzaRWrdTWng1KQlOyQykAHI2rvQLlYlQNTLA5AbUm6uzNXaKpD8s PbckREQ6wHnpZOiRcMN695QstjBNCal+XJHgvrwTfyp9vdFrPVD4UHnsN7MU6QSO XobxOqbuw4Tq95mgYJqrjk+xEYMgzUy2zkVp2QTCBXZn3T3yroI2RcgUZQWaw5SO xRegPa5jfJqcQJAdSxl8oVs9Sz8+5YDeksAnjCOxIQzLZBbNho+SOAzi+kjnT6W7 ijTc20z5eioQVPekdJ4MBweBsAeS1aGi8VWppuP+ZDLoirmxB0LaZyRv/W/HRQDD j4CoZswkndh+J+9Crsa9SUkfNGNvVVNjhJUGyIfTGFUsMbWTAWwa4SMj7Ad04aqW yhg+Ab4H3Yc14TahtX0jrhD3sTBer6ZoMFKE3tl8aStGXHVMyPkj0PHg5xjZEWL2 XGF86eoIgx03A9sIdbdHEZpyTMksfNatDXZk5XpPGF/sVd6txUoYP4Ch2wD8YRFM O5Ny2r6ash2rZYmlyjf19n4gvKebdGo8d8NbzOJ3oYue6OI/88cu0rv6xLV9hHSF fwgIbPo5uK4hIpEm0Dk4 =qY45 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Oct 17 03:08:38 2014 Return-Path: Delivered-To: freebsd-current@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 A19586E0; Fri, 17 Oct 2014 03:08:38 +0000 (UTC) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.allbsd.org", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7203B7D3; Fri, 17 Oct 2014 03:08:35 +0000 (UTC) Received: from alph.d.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=56) by mail.allbsd.org (8.14.9/8.14.8) with ESMTP id s9H386k8044951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 Oct 2014 12:08:16 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.8/8.14.8) with ESMTP id s9H3849q008984; Fri, 17 Oct 2014 12:08:05 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 17 Oct 2014 10:22:59 +0900 (JST) Message-Id: <20141017.102259.2303779237508789020.hrs@allbsd.org> To: freebsd-rc@freebsd.org, freebsd-current@freebsd.org, freebsd-ports@FreeBSD.org Reply-To: freebsd-rc@freebsd.org Subject: [CFT] multiple instance support in rc.d script From: Hiroki Sato X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.6 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart0(Fri_Oct_17_10_22_59_2014_900)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Fri, 17 Oct 2014 12:08:25 +0900 (JST) X-Spam-Status: No, score=-95.7 required=13.0 tests=CONTENT_TYPE_PRESENT, FAKEDWORD_BACKQUOTE,FAKEDWORD_EXCLAMATION,FAKEDWORD_ONE, FAKEDWORD_VERTICALLINE,QENCPTR2,RDNS_NONE,SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 03:08:38 -0000 ----Security_Multipart0(Fri_Oct_17_10_22_59_2014_900)-- Content-Type: Multipart/Mixed; boundary="--Next_Part(Fri_Oct_17_10_22_59_2014_318)--" Content-Transfer-Encoding: 7bit ----Next_Part(Fri_Oct_17_10_22_59_2014_318)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit [Please reply to freebsd-rc@] Hi, I would like your feedback and testers of the attached patch. This implements multiple instance support in rc.d scripts. You can try it by replacing /etc/rc.subr with the attached one. More details are as follow. Typically, an rc.d/foo script has the following structure and rc.conf variables: /etc/rc.d/foo: ---- name=foo rcvar=foo_enable ... load_rc_command $name run_rc_command $* ---- /etc/rc.conf: ---- foo_enable="YES" foo_flags="-f -l -a -g" ---- The above supports one instance for one script. After replacing rc.subr, you can specify additional instances in rc.conf: /etc/rc.conf: ---- foo_instances="one two" foo_one_enable="YES" foo_one_flags="-f -l -a -g" foo_two_enable="YES" foo_two_flags="-F -L -A -G" ---- $foo_instances defines instances by space-separated list of instance names, and rc.conf variables for them are something like ${name}_${instname}_enable. The following command # service foo start starts foo_one and foo_two with the specified flags. Instances can be specified in the following form: # service foo start:one or multiple instances in a particular order: # service foo start:two,one Basically, no change is required for the rc.d/foo script itself. However, there is a problem that default values of the instantiated variables are not defined. For example, if an rc.d/script uses $foo_mode, you need to define $foo_one_mode. The default value of $foo_mode is usually defined in etc/defaults/rc.conf for rc.d scripts in the base system and ": ${foo_mode:=value}" idiom in scripts from Ports Collection. So all of the variables should be defined for each instance, too. As you noticed, this is not easy without editing the script itself. To alleviate this, set_rcvar() can be used: /etc/rc.d/foo: ---- name=foo rcvar=foo_enable set_rcvar foo_enable YES "Enable $name" set_rcvar foo_program "/tmp/test" "Command for $name" ... load_rc_command $name run_rc_command $* ---- The three arguments are varname, default value, and description. If a variable is defined by set_rcvar(), default values instantiated variables will be set automatically---foo_one_program is set by foo_program if it is not defined. This approach still has another problem. set_rcvar() is not supported in all branches, so a script using it does not work in old supported branches. One solution which can be used for scripts in Ports Collection is adding both definitions before and after load_rc_command() until EoL of old branches like this: /etc/rc.d/foo: ---- name=foo rcvar=foo_enable if type set_rcvar >/dev/null 2>&1; then set_rcvar foo_enable YES "Enable $name" set_rcvar foo_program "/tmp/test" "Command for $name" fi ... load_rc_command $name # will be removed after all supported branches have set_rcvar(). if ! type set_rcvar >/dev/null 2>&1; then : ${foo_enable:="YES"} : ${foo_program:="/tmp/test"} for _i in $foo_instances; do for _j in enable program; do eval : \${foo_${_i}_enable:=\$foo_$_j} done done fi run_rc_command $* ---- This is a bit ugly but should work fine. I am using this patch to invoke multiple named (caching server/contents server) and syslogd (local only/listens INET/INET6 socket only) daemons. While $foo_instances is designed as a user-defined knob, this can be applied to software which need to invoke multiple/different daemons which depend on each other in a script, too. I am feeling this patch still needs more careful review from others. Any comments are welcome. Thank you. -- Hiroki ----Next_Part(Fri_Oct_17_10_22_59_2014_318)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rc.subr_multiinstance_20141017-1.diff" Index: etc/rc.subr =================================================================== --- etc/rc.subr (revision 272976) +++ etc/rc.subr (working copy) @@ -698,7 +698,10 @@ # "start stop restart rcvar status poll ${extra_commands}" # If there's a match, run ${argument}_cmd or the default method # (see below). +# _run_rc_command0() is the main routine and run_rc_command() is +# a wrapper to handle multiple instances. # +# # If argument has a given prefix, then change the operation as follows: # Prefix Operation # ------ --------- @@ -755,6 +758,9 @@ # # ${name}_nice n Nice level to run ${command} at. # +# ${name}_pidfile n This to be used in /etc/rc.conf to override +# ${pidfile}. +# # ${name}_user n User to run ${command} as, using su(1) if not # using ${name}_chroot. # Requires /usr to be mounted. @@ -863,6 +869,57 @@ # run_rc_command() { + local _act _instances _name _desc _rcvar + + _act=$1 + shift + eval _instances=\$${name}_instances + + # Check if instance is specified, e.g. "start:instance,...". + case ${_act%:*} in + $_act) ;; # no instance specified + *) + _instances=$(echo ${_act#*:} | tr "," " ") + _act=${_act%:*} + ;; + esac + + # Use reverse order for stop. + case $_act in + *stop) _instances=$(reverse_list $_instances) ;; + esac + + case $_instances in + "") + _name=$name + _inst= + _run_rc_command0 $_act "$@" + ;; + *) + _name=$name + _desc=$desc + _rcvar=$rcvar + for _inst in $_instances; do + # Use a subshell to preserve variables. + ( + name=${_name}_$_inst + eval desc=\"$_desc\${${name}_desc+:\ }\$${name}_desc\" + rcvar=${_rcvar%_enable}_${_inst}_enable + _run_rc_command0 $_act "$@" + ) + done + ;; + esac +} + +getnameparam() +{ + + eval echo \${$1_$_inst${_inst:+_}$2-\$$1_$2} +} + +_run_rc_command0() +{ _return=0 rc_arg=$1 if [ -z "$name" ]; then @@ -904,8 +961,12 @@ ;; esac - eval _override_command=\$${name}_program - command=${_override_command:-$command} + if [ -z "$command" ]; then + command=$(getnameparam $_name program) + fi + if [ -z "$pidfile" ]; then + pidfile=$(getnameparam $_name pidfile) + fi _keywords="start stop restart rcvar enabled $extra_commands" rc_pid= @@ -936,13 +997,16 @@ if [ -n "$flags" ]; then # allow override from environment rc_flags=$flags else - eval rc_flags=\$${name}_flags + rc_flags=$(getnameparam $_name flags) fi - eval _chdir=\$${name}_chdir _chroot=\$${name}_chroot \ - _nice=\$${name}_nice _user=\$${name}_user \ - _group=\$${name}_group _groups=\$${name}_groups \ - _fib=\$${name}_fib _env=\$${name}_env \ - _prepend=\$${name}_prepend + _chdir=$(getnameparam $_name chdir) + _chroot=$(getnameparam $_name chroot) + _nice=$(getnameparam $_name nice) + _user=$(getnameparam $_name user) + _group=$(getnameparam $_name group) + _groups=$(getnameparam $_name groups) + _env=$(getnameparam $_name env) + _prepend=$(getnameparam $_name prepend) if [ -n "$_user" ]; then # unset $_user if running as that user if [ "$_user" = "$(eval $IDCMD)" ]; then @@ -977,9 +1041,9 @@ # if there's a custom ${XXX_cmd}, # run that instead of the default # - eval _cmd=\$${rc_arg}_cmd \ - _precmd=\$${rc_arg}_precmd \ - _postcmd=\$${rc_arg}_postcmd + _cmd=$(getnameparam $rc_arg cmd) + _precmd=$(getnameparam $rc_arg precmd) + _postcmd=$(getnameparam $rc_arg postcmd) if [ -n "$_cmd" ]; then _run_rc_precmd || return 1 @@ -1134,16 +1198,10 @@ echo "" fi echo "#" - # Get unique vars in $rcvar $rcvars - for _v in $rcvar $rcvars; do - case $v in - $_v\ *|\ *$_v|*\ $_v\ *) ;; - *) v="${v# } $_v" ;; - esac - done # Display variables. - for _v in $v; do + for _v in $(getinstlist $_name "$_inst" $rcvar $rcvars); + do if [ -z "$_v" ]; then continue fi @@ -1150,24 +1208,20 @@ eval _desc=\$${_v}_desc eval _defval=\$${_v}_defval - _h="-" + eval _val=\$$_v - eval echo \"$_v=\\\"\$$_v\\\"\" - # decode multiple lines of _desc - while [ -n "$_desc" ]; do - case $_desc in - *^^*) - echo "# $_h ${_desc%%^^*}" - _desc=${_desc#*^^} - _h=" " - ;; - *) - echo "# $_h ${_desc}" - break - ;; - esac - done - echo "# (default: \"$_defval\")" + case $_defval in + $_val) + _e= + _m= + ;; + *) + _e=" # (default: \"$_defval\")" + _m="(*)" + ;; + esac + echo "# $_v$_m${_desc+: }$_desc" + eval echo \"$_v=\\\"\$$_v\\\"\" \$_e done echo "" ;; @@ -1308,11 +1362,104 @@ } # +# uniqlist var list +# Put a list into $var with duplicate words removed. +# +uniqlist() +{ + local _uv _v + + _uv= + for _v in "$@"; do + case $_uv in + $_v|$_v\ *|*\ $_v|*\ $_v\ *) ;; + *) _uv="${_uv# }${_uv:+ }$_v" ;; + esac + done + echo "$_uv" +} +# +# createinstlist() name inst list +# Generate a variable list with the instance name. +# +createinstlist() +{ + local _name _inst _v + + _name=$1 + _inst=$2 + shift 2 + for _v in $(uniqlist "$@"); do + echo "${_name}_${_inst}${_inst+_}${_v#${_name}_}" + done +} +# +# getinstlist() name inst list +# Get a variable list only with the instance name. +# +getinstlist() +{ + local _name _inst _v _l + + _name=$1 + _inst=$2 + shift 2 + _l= + for _v in $(uniqlist "$@"); do + case $_v in + ${_name}${_inst:+_}${_inst}_*) _l="${_l# }${_l:+ }$_v" ;; + esac + done + uniqlist $_l +} + +# # load_rc_config name # Source in the configuration file for a given name. +# load_rc_config0() is the main routine and load_rc_config() is +# a wrapper to handle multiple instances. # load_rc_config() { + local _instances _inst _name _rcvars _defval _desc _k _v _ul + + # XXX: normalization + ltr "$name" "-" "_" name + ltr "$1" "-" "_" _name + _load_rc_config0 $_name + + eval _instances=\$${_name}_instances + _rcvars=$rcvars + + for _inst in $_instances; do + # Set default values for ${_name}_$_inst. + + for _k in $(uniqlist $_rcvars); do + # _k includes _name + eval _defval=\${${_k}_defval} + eval _desc=\${${_k}_desc} + set_rcvar $(createinstlist $_name $_inst $_k) \ + "$_defval" "$_desc" + done + for _k in $_rc_namevarlist; do + if [ "$_k" = "instances" ]; then + continue + fi + _k=${_name}_$_k + # _k includes _name + eval _defval=\${${_k}_defval} + eval _desc=\${${_k}_desc} + if [ -n "$_defval" ]; then + set_rcvar $(createinstlist $_name $_inst $_k) \ + "$_defval" "$_desc" + fi + done + _load_rc_config0 ${_name}_$_inst + done +} + +_load_rc_config0() +{ local _name _rcvar_val _var _defval _v _msg _new _d _name=$1 if [ -z "$_name" ]; then ----Next_Part(Fri_Oct_17_10_22_59_2014_318)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rc.subr" # $NetBSD: rc.subr,v 1.67 2006/10/07 11:25:15 elad Exp $ # $FreeBSD: head/etc/rc.subr 272976 2014-10-12 02:42:36Z hrs $ # # Copyright (c) 1997-2004 The NetBSD Foundation, Inc. # All rights reserved. # # This code is derived from software contributed to The NetBSD Foundation # by Luke Mewburn. # # Redistribution and use in source and binary forms, with or without # modification, are permitted provided that the following conditions # are met: # 1. Redistributions of source code must retain the above copyright # notice, this list of conditions and the following disclaimer. # 2. Redistributions in binary form must reproduce the above copyright # notice, this list of conditions and the following disclaimer in the # documentation and/or other materials provided with the distribution. # # THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS # ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED # TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR # PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS # BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR # CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF # SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS # INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN # CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) # ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE # POSSIBILITY OF SUCH DAMAGE. # # rc.subr # functions used by various rc scripts # : ${RC_PID:=$$}; export RC_PID # # Operating System dependent/independent variables # if [ -z "${_rc_subr_loaded}" ]; then _rc_subr_loaded="YES" SYSCTL="/sbin/sysctl" SYSCTL_N="${SYSCTL} -n" SYSCTL_W="${SYSCTL}" ID="/usr/bin/id" IDCMD="if [ -x $ID ]; then $ID -un; fi" PS="/bin/ps -ww" JID=`$PS -p $$ -o jid=` # # functions # --------- # list_vars pattern # List vars matching pattern. # list_vars() { set | { while read LINE; do var="${LINE%%=*}" case "$var" in "$LINE"|*[!a-zA-Z0-9_]*) continue ;; $1) echo $var esac done; } } # set_rcvar [var] [defval] [desc] # # Echo or define a rc.conf(5) variable name. Global variable # $rcvars is used. # # If no argument is specified, echo "${name}_enable". # # If only a var is specified, echo "${var}_enable". # # If var and defval are specified, the ${var} is defined as # rc.conf(5) variable and the default value is ${defvar}. An # optional argument $desc can also be specified to add a # description for that. # set_rcvar() { local _var case $# in 0) echo ${name}_enable ;; 1) echo ${1}_enable ;; *) debug "set_rcvar: \$$1=$2 is added" \ " as a rc.conf(5) variable." _var=$1 rcvars="${rcvars# } $_var" eval ${_var}_defval=\"$2\" shift 2 eval ${_var}_desc=\"$*\" ;; esac } # set_rcvar_obsolete oldvar [newvar] [msg] # Define obsolete variable. # Global variable $rcvars_obsolete is used. # set_rcvar_obsolete() { local _var _var=$1 debug "set_rcvar_obsolete: \$$1(old) -> \$$2(new) is defined" rcvars_obsolete="${rcvars_obsolete# } $1" eval ${1}_newvar=\"$2\" shift 2 eval ${_var}_obsolete_msg=\"$*\" } # # force_depend script [rcvar] # Force a service to start. Intended for use by services # to resolve dependency issues. # $1 - filename of script, in /etc/rc.d, to run # $2 - name of the script's rcvar (minus the _enable) # force_depend() { local _depend _dep_rcvar _depend="$1" _dep_rcvar="${2:-$1}_enable" [ -n "$rc_fast" ] && ! checkyesno always_force_depends && checkyesno $_dep_rcvar && return 0 /etc/rc.d/${_depend} forcestatus >/dev/null 2>&1 && return 0 info "${name} depends on ${_depend}, which will be forced to start." if ! /etc/rc.d/${_depend} forcestart; then warn "Unable to force ${_depend}. It may already be running." return 1 fi } # # checkyesno var # Test $1 variable, and warn if not set to YES or NO. # Return 0 if it's "yes" (et al), nonzero otherwise. # checkyesno() { eval _value=\$${1} debug "checkyesno: $1 is set to $_value." case $_value in # "yes", "true", "on", or "1" [Yy][Ee][Ss]|[Tt][Rr][Uu][Ee]|[Oo][Nn]|1) return 0 ;; # "no", "false", "off", or "0" [Nn][Oo]|[Ff][Aa][Ll][Ss][Ee]|[Oo][Ff][Ff]|0) return 1 ;; *) warn "\$${1} is not set properly - see rc.conf(5)." return 1 ;; esac } # # reverse_list list # print the list in reverse order # reverse_list() { _revlist= for _revfile; do _revlist="$_revfile $_revlist" done echo $_revlist } # stop_boot always # If booting directly to multiuser or $always is enabled, # send SIGTERM to the parent (/etc/rc) to abort the boot. # Otherwise just exit. # stop_boot() { local always case $1 in # "yes", "true", "on", or "1" [Yy][Ee][Ss]|[Tt][Rr][Uu][Ee]|[Oo][Nn]|1) always=true ;; *) always=false ;; esac if [ "$autoboot" = yes -o "$always" = true ]; then echo "ERROR: ABORTING BOOT (sending SIGTERM to parent)!" kill -TERM ${RC_PID} fi exit 1 } # # mount_critical_filesystems type # Go through the list of critical filesystems as provided in # the rc.conf(5) variable $critical_filesystems_${type}, checking # each one to see if it is mounted, and if it is not, mounting it. # mount_critical_filesystems() { eval _fslist=\$critical_filesystems_${1} for _fs in $_fslist; do mount | ( _ismounted=false while read what _on on _type type; do if [ $on = $_fs ]; then _ismounted=true fi done if $_ismounted; then : else mount $_fs >/dev/null 2>&1 fi ) done } # # check_pidfile pidfile procname [interpreter] # Parses the first line of pidfile for a PID, and ensures # that the process is running and matches procname. # Prints the matching PID upon success, nothing otherwise. # interpreter is optional; see _find_processes() for details. # check_pidfile() { _pidfile=$1 _procname=$2 _interpreter=$3 if [ -z "$_pidfile" -o -z "$_procname" ]; then err 3 'USAGE: check_pidfile pidfile procname [interpreter]' fi if [ ! -f $_pidfile ]; then debug "pid file ($_pidfile): not readable." return fi read _pid _junk < $_pidfile if [ -z "$_pid" ]; then debug "pid file ($_pidfile): no pid in file." return fi _find_processes $_procname ${_interpreter:-.} '-p '"$_pid" } # # check_process procname [interpreter] # Ensures that a process (or processes) named procname is running. # Prints a list of matching PIDs. # interpreter is optional; see _find_processes() for details. # check_process() { _procname=$1 _interpreter=$2 if [ -z "$_procname" ]; then err 3 'USAGE: check_process procname [interpreter]' fi _find_processes $_procname ${_interpreter:-.} '-ax' } # # _find_processes procname interpreter psargs # Search for procname in the output of ps generated by psargs. # Prints the PIDs of any matching processes, space separated. # # If interpreter == ".", check the following variations of procname # against the first word of each command: # procname # `basename procname` # `basename procname` + ":" # "(" + `basename procname` + ")" # "[" + `basename procname` + "]" # # If interpreter != ".", read the first line of procname, remove the # leading #!, normalise whitespace, append procname, and attempt to # match that against each command, either as is, or with extra words # at the end. As an alternative, to deal with interpreted daemons # using perl, the basename of the interpreter plus a colon is also # tried as the prefix to procname. # _find_processes() { if [ $# -ne 3 ]; then err 3 'USAGE: _find_processes procname interpreter psargs' fi _procname=$1 _interpreter=$2 _psargs=$3 _pref= if [ $_interpreter != "." ]; then # an interpreted script _script="${_chroot}${_chroot:+/}$_procname" if [ -r "$_script" ]; then read _interp < $_script # read interpreter name case "$_interp" in \#!*) _interp=${_interp#\#!} # strip #! set -- $_interp case $1 in */bin/env) shift # drop env to get real name ;; esac if [ $_interpreter != $1 ]; then warn "\$command_interpreter $_interpreter != $1" fi ;; *) warn "no shebang line in $_script" set -- $_interpreter ;; esac else warn "cannot read shebang line from $_script" set -- $_interpreter fi _interp="$* $_procname" # cleanup spaces, add _procname _interpbn=${1##*/} _fp_args='_argv' _fp_match='case "$_argv" in ${_interp}|"${_interp} "*|"[${_interpbn}]"|"${_interpbn}: ${_procname}"*)' else # a normal daemon _procnamebn=${_procname##*/} _fp_args='_arg0 _argv' _fp_match='case "$_arg0" in $_procname|$_procnamebn|${_procnamebn}:|"(${_procnamebn})"|"[${_procnamebn}]")' fi _proccheck="\ $PS 2>/dev/null -o pid= -o jid= -o command= $_psargs"' | while read _npid _jid '"$_fp_args"'; do '"$_fp_match"' if [ "$JID" -eq "$_jid" ]; then echo -n "$_pref$_npid"; _pref=" "; fi ;; esac done' # debug "in _find_processes: proccheck is ($_proccheck)." eval $_proccheck } # sort_lite [-b] [-n] [-k POS] [-t SEP] # A lite version of sort(1) (supporting a few options) that can be used # before the real sort(1) is available (e.g., in scripts that run prior # to mountcritremote). Requires only shell built-in functionality. # sort_lite() { local funcname=sort_lite local sort_sep="$IFS" sort_ignore_leading_space= local sort_field=0 sort_strict_fields= sort_numeric= local nitems=0 skip_leading=0 trim= local OPTIND flag while getopts bnk:t: flag; do case "$flag" in b) sort_ignore_leading_space=1 ;; n) sort_numeric=1 sort_ignore_leading_space=1 ;; k) sort_field="${OPTARG%%,*}" ;; # only up to first comma # NB: Unlike sort(1) only one POS allowed t) sort_sep="$OPTARG" if [ ${#sort_sep} -gt 1 ]; then echo "$funcname: multi-character tab \`$sort_sep'" >&2 return 1 fi sort_strict_fields=1 ;; \?) return 1 ;; esac done shift $(( $OPTIND - 1 )) # Create transformation pattern to trim leading text if desired case "$sort_field" in ""|[!0-9]*|*[!0-9.]*) echo "$funcname: invalid sort field \`$sort_field'" >&2 return 1 ;; *.*) skip_leading=${sort_field#*.} sort_field=${sort_field%%.*} while [ ${skip_leading:-0} -gt 1 ] 2> /dev/null; do trim="$trim?" skip_leading=$(( $skip_leading - 1 )) done esac # Copy input to series of local numbered variables # NB: IFS of NULL preserves leading whitespace local LINE while IFS= read -r LINE || [ "$LINE" ]; do nitems=$(( $nitems + 1 )) local src_$nitems="$LINE" done # # Sort numbered locals using insertion sort # local curitem curitem_orig curitem_mod curitem_haskey local dest dest_orig dest_mod dest_haskey local d gt n local i=1 while [ $i -le $nitems ]; do curitem_haskey=1 # Assume sort field (-k POS) exists eval curitem=\"\$src_$i\" curitem_mod="$curitem" # for modified comparison curitem_orig="$curitem" # for original comparison # Trim leading whitespace if desired if [ "$sort_ignore_leading_space" ]; then while case "$curitem_orig" in [$IFS]*) : ;; *) false; esac do curitem_orig="${curitem_orig#?}" done curitem_mod="$curitem_orig" fi # Shift modified comparison value if sort field (-k POS) is > 1 n=$sort_field while [ $n -gt 1 ]; do case "$curitem_mod" in *[$sort_sep]*) # Cut text up-to (and incl.) first separator curitem_mod="${curitem_mod#*[$sort_sep]}" # Skip NULLs unless strict field splitting [ "$sort_strict_fields" ] || [ "${curitem_mod%%[$sort_sep]*}" ] || [ $n -eq 2 ] || continue ;; *) # Asked for a field that doesn't exist curitem_haskey= break esac n=$(( $n - 1 )) done # Trim trailing words if sort field >= 1 [ $sort_field -ge 1 -a "$sort_numeric" ] && curitem_mod="${curitem_mod%%[$sort_sep]*}" # Apply optional trim (-k POS.TRIM) to cut leading characters curitem_mod="${curitem_mod#$trim}" # Determine the type of modified comparison to use initially # NB: Prefer numerical if requested but fallback to standard case "$curitem_mod" in ""|[!0-9]*) # NULL or begins with non-number gt=">" [ "$sort_numeric" ] && curitem_mod=0 ;; *) if [ "$sort_numeric" ]; then gt="-gt" curitem_mod="${curitem_mod%%[!0-9]*}" # NB: trailing non-digits removed # otherwise numeric comparison fails else gt=">" fi esac # If first time through, short-circuit below position-search if [ $i -le 1 ]; then d=0 else d=1 fi # # Find appropriate element position # while [ $d -gt 0 ] do dest_haskey=$curitem_haskey eval dest=\"\$dest_$d\" dest_mod="$dest" # for modified comparison dest_orig="$dest" # for original comparison # Trim leading whitespace if desired if [ "$sort_ignore_leading_space" ]; then while case "$dest_orig" in [$IFS]*) : ;; *) false; esac do dest_orig="${dest_orig#?}" done dest_mod="$dest_orig" fi # Shift modified value if sort field (-k POS) is > 1 n=$sort_field while [ $n -gt 1 ]; do case "$dest_mod" in *[$sort_sep]*) # Cut text up-to (and incl.) 1st sep dest_mod="${dest_mod#*[$sort_sep]}" # Skip NULLs unless strict fields [ "$sort_strict_fields" ] || [ "${dest_mod%%[$sort_sep]*}" ] || [ $n -eq 2 ] || continue ;; *) # Asked for a field that doesn't exist dest_haskey= break esac n=$(( $n - 1 )) done # Trim trailing words if sort field >= 1 [ $sort_field -ge 1 -a "$sort_numeric" ] && dest_mod="${dest_mod%%[$sort_sep]*}" # Apply optional trim (-k POS.TRIM), cut leading chars dest_mod="${dest_mod#$trim}" # Determine type of modified comparison to use # NB: Prefer numerical if requested, fallback to std case "$dest_mod" in ""|[!0-9]*) # NULL or begins with non-number gt=">" [ "$sort_numeric" ] && dest_mod=0 ;; *) if [ "$sort_numeric" ]; then gt="-gt" dest_mod="${dest_mod%%[!0-9]*}" # NB: kill trailing non-digits # for numeric comparison safety else gt=">" fi esac # Break if we've found the proper element position if [ "$curitem_haskey" -a "$dest_haskey" ]; then if [ "$dest_mod" = "$curitem_mod" ]; then [ "$dest_orig" ">" "$curitem_orig" ] && break elif [ "$dest_mod" $gt "$curitem_mod" ] \ 2> /dev/null then break fi else [ "$dest_orig" ">" "$curitem_orig" ] && break fi # Break if we've hit the end [ $d -ge $i ] && break d=$(( $d + 1 )) done # Shift remaining positions forward, making room for new item n=$i while [ $n -ge $d ]; do # Shift destination item forward one placement eval dest_$(( $n + 1 ))=\"\$dest_$n\" n=$(( $n - 1 )) done # Place the element if [ $i -eq 1 ]; then local dest_1="$curitem" else local dest_$d="$curitem" fi i=$(( $i + 1 )) done # Print sorted results d=1 while [ $d -le $nitems ]; do eval echo \"\$dest_$d\" d=$(( $d + 1 )) done } # # wait_for_pids pid [pid ...] # spins until none of the pids exist # wait_for_pids() { local _list _prefix _nlist _j _list="$@" if [ -z "$_list" ]; then return fi _prefix= while true; do _nlist=""; for _j in $_list; do if kill -0 $_j 2>/dev/null; then _nlist="${_nlist}${_nlist:+ }$_j" [ -n "$_prefix" ] && sleep 1 fi done if [ -z "$_nlist" ]; then break fi _list=$_nlist echo -n ${_prefix:-"Waiting for PIDS: "}$_list _prefix=", " pwait $_list 2>/dev/null done if [ -n "$_prefix" ]; then echo "." fi } # # get_pidfile_from_conf string file # # Takes a string to search for in the specified file. # Ignores lines with traditional comment characters. # # Example: # # if get_pidfile_from_conf string file; then # pidfile="$_pidfile_from_conf" # else # pidfile='appropriate default' # fi # get_pidfile_from_conf() { if [ -z "$1" -o -z "$2" ]; then err 3 "USAGE: get_pidfile_from_conf string file ($name)" fi local string file line string="$1" ; file="$2" if [ ! -s "$file" ]; then err 3 "get_pidfile_from_conf: $file does not exist ($name)" fi while read line; do case "$line" in *[#\;]*${string}*) continue ;; *${string}*) break ;; esac done < $file if [ -n "$line" ]; then line=${line#*/} _pidfile_from_conf="/${line%%[\"\;]*}" else return 1 fi } # # check_startmsgs # If rc_quiet is set (usually as a result of using faststart at # boot time) check if rc_startmsgs is enabled. # check_startmsgs() { if [ -n "$rc_quiet" ]; then checkyesno rc_startmsgs else return 0 fi } # # run_rc_command argument # Search for argument in the list of supported commands, which is: # "start stop restart rcvar status poll ${extra_commands}" # If there's a match, run ${argument}_cmd or the default method # (see below). # _run_rc_command0() is the main routine and run_rc_command() is # a wrapper to handle multiple instances. # # # If argument has a given prefix, then change the operation as follows: # Prefix Operation # ------ --------- # fast Skip the pid check, and set rc_fast=yes, rc_quiet=yes # force Set ${rcvar} to YES, and set rc_force=yes # one Set ${rcvar} to YES # quiet Don't output some diagnostics, and set rc_quiet=yes # # The following globals are used: # # Name Needed Purpose # ---- ------ ------- # name y Name of script. # # command n Full path to command. # Not needed if ${rc_arg}_cmd is set for # each keyword. # # command_args n Optional args/shell directives for command. # # command_interpreter n If not empty, command is interpreted, so # call check_{pidfile,process}() appropriately. # # desc n Description of script. # # extra_commands n List of extra commands supported. # # pidfile n If set, use check_pidfile $pidfile $command, # otherwise use check_process $command. # In either case, only check if $command is set. # # procname n Process name to check for instead of $command. # # rcvar n This is checked with checkyesno to determine # if the action should be run. # # ${name}_program n Full path to command. # Meant to be used in /etc/rc.conf to override # ${command}. # # ${name}_chroot n Directory to chroot to before running ${command} # Requires /usr to be mounted. # # ${name}_chdir n Directory to cd to before running ${command} # (if not using ${name}_chroot). # # ${name}_flags n Arguments to call ${command} with. # NOTE: $flags from the parent environment # can be used to override this. # # ${name}_env n Environment variables to run ${command} with. # # ${name}_fib n Routing table number to run ${command} with. # # ${name}_nice n Nice level to run ${command} at. # # ${name}_pidfile n This to be used in /etc/rc.conf to override # ${pidfile}. # # ${name}_user n User to run ${command} as, using su(1) if not # using ${name}_chroot. # Requires /usr to be mounted. # # ${name}_group n Group to run chrooted ${command} as. # Requires /usr to be mounted. # # ${name}_groups n Comma separated list of supplementary groups # to run the chrooted ${command} with. # Requires /usr to be mounted. # # ${name}_prepend n Command added before ${command}. # # ${rc_arg}_cmd n If set, use this as the method when invoked; # Otherwise, use default command (see below) # # ${rc_arg}_precmd n If set, run just before performing the # ${rc_arg}_cmd method in the default # operation (i.e, after checking for required # bits and process (non)existence). # If this completes with a non-zero exit code, # don't run ${rc_arg}_cmd. # # ${rc_arg}_postcmd n If set, run just after performing the # ${rc_arg}_cmd method, if that method # returned a zero exit code. # # required_dirs n If set, check for the existence of the given # directories before running a (re)start command. # # required_files n If set, check for the readability of the given # files before running a (re)start command. # # required_modules n If set, ensure the given kernel modules are # loaded before running a (re)start command. # The check and possible loads are actually # done after start_precmd so that the modules # aren't loaded in vain, should the precmd # return a non-zero status to indicate a error. # If a word in the list looks like "foo:bar", # "foo" is the KLD file name and "bar" is the # module name. If a word looks like "foo~bar", # "foo" is the KLD file name and "bar" is a # egrep(1) pattern matching the module name. # Otherwise the module name is assumed to be # the same as the KLD file name, which is most # common. See load_kld(). # # required_vars n If set, perform checkyesno on each of the # listed variables before running the default # (re)start command. # # Default behaviour for a given argument, if no override method is # provided: # # Argument Default behaviour # -------- ----------------- # start if !running && checkyesno ${rcvar} # ${command} # # stop if ${pidfile} # rc_pid=$(check_pidfile $pidfile $command) # else # rc_pid=$(check_process $command) # kill $sig_stop $rc_pid # wait_for_pids $rc_pid # ($sig_stop defaults to TERM.) # # reload Similar to stop, except use $sig_reload instead, # and doesn't wait_for_pids. # $sig_reload defaults to HUP. # Note that `reload' isn't provided by default, # it should be enabled via $extra_commands. # # restart Run `stop' then `start'. # # status Show if ${command} is running, etc. # # poll Wait for ${command} to exit. # # rcvar Display what rc.conf variable is used (if any). # # enabled Return true if the service is enabled. # # Variables available to methods, and after run_rc_command() has # completed: # # Variable Purpose # -------- ------- # rc_arg Argument to command, after fast/force/one processing # performed # # rc_flags Flags to start the default command with. # Defaults to ${name}_flags, unless overridden # by $flags from the environment. # This variable may be changed by the precmd method. # # rc_pid PID of command (if appropriate) # # rc_fast Not empty if "fast" was provided (q.v.) # # rc_force Not empty if "force" was provided (q.v.) # # rc_quiet Not empty if "quiet" was provided # # run_rc_command() { local _act _instances _name _desc _rcvar _act=$1 shift eval _instances=\$${name}_instances # Check if instance is specified, e.g. "start:instance,...". case ${_act%:*} in $_act) ;; # no instance specified *) _instances=$(echo ${_act#*:} | tr "," " ") _act=${_act%:*} ;; esac # Use reverse order for stop. case $_act in *stop) _instances=$(reverse_list $_instances) ;; esac case $_instances in "") _name=$name _inst= _run_rc_command0 $_act "$@" ;; *) _name=$name _desc=$desc _rcvar=$rcvar for _inst in $_instances; do # Use a subshell to preserve variables. ( name=${_name}_$_inst eval desc=\"$_desc\${${name}_desc+:\ }\$${name}_desc\" rcvar=${_rcvar%_enable}_${_inst}_enable _run_rc_command0 $_act "$@" ) done ;; esac } getnameparam() { eval echo \${$1_$_inst${_inst:+_}$2-\$$1_$2} } _run_rc_command0() { _return=0 rc_arg=$1 if [ -z "$name" ]; then err 3 'run_rc_command: $name is not set.' fi # Don't repeat the first argument when passing additional command- # line arguments to the command subroutines. # shift 1 rc_extra_args="$*" _rc_prefix= case "$rc_arg" in fast*) # "fast" prefix; don't check pid rc_arg=${rc_arg#fast} rc_fast=yes rc_quiet=yes ;; force*) # "force" prefix; always run rc_force=yes _rc_prefix=force rc_arg=${rc_arg#${_rc_prefix}} if [ -n "${rcvar}" ]; then eval ${rcvar}=YES fi ;; one*) # "one" prefix; set ${rcvar}=yes _rc_prefix=one rc_arg=${rc_arg#${_rc_prefix}} if [ -n "${rcvar}" ]; then eval ${rcvar}=YES fi ;; quiet*) # "quiet" prefix; omit some messages _rc_prefix=quiet rc_arg=${rc_arg#${_rc_prefix}} rc_quiet=yes ;; esac if [ -z "$command" ]; then command=$(getnameparam $_name program) fi if [ -z "$pidfile" ]; then pidfile=$(getnameparam $_name pidfile) fi _keywords="start stop restart rcvar enabled $extra_commands" rc_pid= _pidcmd= _procname=${procname:-${command}} # setup pid check command if [ -n "$_procname" ]; then if [ -n "$pidfile" ]; then _pidcmd='rc_pid=$(check_pidfile '"$pidfile $_procname $command_interpreter"')' else _pidcmd='rc_pid=$(check_process '"$_procname $command_interpreter"')' fi if [ -n "$_pidcmd" ]; then _keywords="${_keywords} status poll" fi fi if [ -z "$rc_arg" ]; then rc_usage $_keywords fi if [ "$rc_arg" = "enabled" ] ; then checkyesno ${rcvar} return $? fi if [ -n "$flags" ]; then # allow override from environment rc_flags=$flags else rc_flags=$(getnameparam $_name flags) fi _chdir=$(getnameparam $_name chdir) _chroot=$(getnameparam $_name chroot) _nice=$(getnameparam $_name nice) _user=$(getnameparam $_name user) _group=$(getnameparam $_name group) _groups=$(getnameparam $_name groups) _env=$(getnameparam $_name env) _prepend=$(getnameparam $_name prepend) if [ -n "$_user" ]; then # unset $_user if running as that user if [ "$_user" = "$(eval $IDCMD)" ]; then unset _user fi fi [ -z "$autoboot" ] && eval $_pidcmd # determine the pid if necessary for _elem in $_keywords; do if [ "$_elem" != "$rc_arg" ]; then continue fi # if ${rcvar} is set, $1 is not "rcvar" # and ${rc_pid} is not set, then run # checkyesno ${rcvar} # and return if that failed # if [ -n "${rcvar}" -a "$rc_arg" != "rcvar" -a "$rc_arg" != "stop" ] || [ -n "${rcvar}" -a "$rc_arg" = "stop" -a -z "${rc_pid}" ]; then if ! checkyesno ${rcvar}; then if [ -n "${rc_quiet}" ]; then return 0 fi echo -n "Cannot '${rc_arg}' $name. Set ${rcvar} to " echo -n "YES in /etc/rc.conf or use 'one${rc_arg}' " echo "instead of '${rc_arg}'." return 0 fi fi # if there's a custom ${XXX_cmd}, # run that instead of the default # _cmd=$(getnameparam $rc_arg cmd) _precmd=$(getnameparam $rc_arg precmd) _postcmd=$(getnameparam $rc_arg postcmd) if [ -n "$_cmd" ]; then _run_rc_precmd || return 1 _run_rc_doit "$_cmd $rc_extra_args" || return 1 _run_rc_postcmd return $_return fi case "$rc_arg" in # default operations... status) _run_rc_precmd || return 1 if [ -n "$rc_pid" ]; then echo "${name} is running as pid $rc_pid." else echo "${name} is not running." return 1 fi _run_rc_postcmd ;; start) if [ -z "$rc_fast" -a -n "$rc_pid" ]; then if [ -z "$rc_quiet" ]; then echo 1>&2 "${name} already running? " \ "(pid=$rc_pid)." fi return 1 fi if [ ! -x "${_chroot}${_chroot:+/}${command}" ]; then warn "run_rc_command: cannot run $command" return 1 fi if ! _run_rc_precmd; then warn "failed precmd routine for ${name}" return 1 fi # setup the full command to run # check_startmsgs && echo "Starting ${name}." if [ -n "$_chroot" ]; then _doit="\ ${_nice:+nice -n $_nice }\ ${_fib:+setfib -F $_fib }\ ${_env:+env $_env }\ chroot ${_user:+-u $_user }${_group:+-g $_group }${_groups:+-G $_groups }\ $_chroot $command $rc_flags $command_args" else _doit="\ ${_chdir:+cd $_chdir && }\ ${_fib:+setfib -F $_fib }\ ${_env:+env $_env }\ $command $rc_flags $command_args" if [ -n "$_user" ]; then _doit="su -m $_user -c 'sh -c \"$_doit\"'" fi if [ -n "$_nice" ]; then if [ -z "$_user" ]; then _doit="sh -c \"$_doit\"" fi _doit="nice -n $_nice $_doit" fi if [ -n "$_prepend" ]; then _doit="$_prepend $_doit" fi fi # run the full command # if ! _run_rc_doit "$_doit"; then warn "failed to start ${name}" return 1 fi # finally, run postcmd # _run_rc_postcmd ;; stop) if [ -z "$rc_pid" ]; then [ -n "$rc_fast" ] && return 0 _run_rc_notrunning return 1 fi _run_rc_precmd || return 1 # send the signal to stop # echo "Stopping ${name}." _doit=$(_run_rc_killcmd "${sig_stop:-TERM}") _run_rc_doit "$_doit" || return 1 # wait for the command to exit, # and run postcmd. wait_for_pids $rc_pid _run_rc_postcmd ;; reload) if [ -z "$rc_pid" ]; then _run_rc_notrunning return 1 fi _run_rc_precmd || return 1 _doit=$(_run_rc_killcmd "${sig_reload:-HUP}") _run_rc_doit "$_doit" || return 1 _run_rc_postcmd ;; restart) # prevent restart being called more # than once by any given script # if ${_rc_restart_done:-false}; then return 0 fi _rc_restart_done=true _run_rc_precmd || return 1 # run those in a subshell to keep global variables ( run_rc_command ${_rc_prefix}stop $rc_extra_args ) ( run_rc_command ${_rc_prefix}start $rc_extra_args ) _return=$? [ $_return -ne 0 ] && [ -z "$rc_force" ] && return 1 _run_rc_postcmd ;; poll) _run_rc_precmd || return 1 if [ -n "$rc_pid" ]; then wait_for_pids $rc_pid fi _run_rc_postcmd ;; rcvar) echo -n "# $name" if [ -n "$desc" ]; then echo " : $desc" else echo "" fi echo "#" # Display variables. for _v in $(getinstlist $_name "$_inst" $rcvar $rcvars); do if [ -z "$_v" ]; then continue fi eval _desc=\$${_v}_desc eval _defval=\$${_v}_defval eval _val=\$$_v case $_defval in $_val) _e= _m= ;; *) _e=" # (default: \"$_defval\")" _m="(*)" ;; esac echo "# $_v$_m${_desc+: }$_desc" eval echo \"$_v=\\\"\$$_v\\\"\" \$_e done echo "" ;; *) rc_usage $_keywords ;; esac return $_return done echo 1>&2 "$0: unknown directive '$rc_arg'." rc_usage $_keywords # not reached } # # Helper functions for run_rc_command: common code. # They use such global variables besides the exported rc_* ones: # # name R/W # ------------------ # _precmd R # _postcmd R # _return W # _run_rc_precmd() { check_required_before "$rc_arg" || return 1 if [ -n "$_precmd" ]; then debug "run_rc_command: ${rc_arg}_precmd: $_precmd $rc_extra_args" eval "$_precmd $rc_extra_args" _return=$? # If precmd failed and force isn't set, request exit. if [ $_return -ne 0 ] && [ -z "$rc_force" ]; then return 1 fi fi check_required_after "$rc_arg" || return 1 return 0 } _run_rc_postcmd() { if [ -n "$_postcmd" ]; then debug "run_rc_command: ${rc_arg}_postcmd: $_postcmd $rc_extra_args" eval "$_postcmd $rc_extra_args" _return=$? fi return 0 } _run_rc_doit() { debug "run_rc_command: doit: $*" eval "$@" _return=$? # If command failed and force isn't set, request exit. if [ $_return -ne 0 ] && [ -z "$rc_force" ]; then return 1 fi return 0 } _run_rc_notrunning() { local _pidmsg if [ -n "$pidfile" ]; then _pidmsg=" (check $pidfile)." else _pidmsg= fi echo 1>&2 "${name} not running?${_pidmsg}" } _run_rc_killcmd() { local _cmd _cmd="kill -$1 $rc_pid" if [ -n "$_user" ]; then _cmd="su -m ${_user} -c 'sh -c \"${_cmd}\"'" fi echo "$_cmd" } # # run_rc_script file arg # Start the script `file' with `arg', and correctly handle the # return value from the script. # If `file' ends with `.sh', it's sourced into the current environment # when $rc_fast_and_loose is set, otherwise it is run as a child process. # If `file' appears to be a backup or scratch file, ignore it. # Otherwise if it is executable run as a child process. # run_rc_script() { _file=$1 _arg=$2 if [ -z "$_file" -o -z "$_arg" ]; then err 3 'USAGE: run_rc_script file arg' fi unset name command command_args command_interpreter \ extra_commands pidfile procname \ rcvar rcvars rcvars_obsolete required_dirs required_files \ required_vars eval unset ${_arg}_cmd ${_arg}_precmd ${_arg}_postcmd case "$_file" in /etc/rc.d/*.sh) # no longer allowed in the base warn "Ignoring old-style startup script $_file" ;; *[~#]|*.OLD|*.bak|*.orig|*,v) # scratch file; skip warn "Ignoring scratch file $_file" ;; *) # run in subshell if [ -x $_file ]; then if [ -n "$rc_fast_and_loose" ]; then set $_arg; . $_file else ( trap "echo Script $_file interrupted >&2 ; kill -QUIT $$" 3 trap "echo Script $_file interrupted >&2 ; exit 1" 2 trap "echo Script $_file running >&2" 29 set $_arg; . $_file ) fi fi ;; esac } # # uniqlist var list # Put a list into $var with duplicate words removed. # uniqlist() { local _uv _v _uv= for _v in "$@"; do case $_uv in $_v|$_v\ *|*\ $_v|*\ $_v\ *) ;; *) _uv="${_uv# }${_uv:+ }$_v" ;; esac done echo "$_uv" } # # createinstlist() name inst list # Generate a variable list with the instance name. # createinstlist() { local _name _inst _v _name=$1 _inst=$2 shift 2 for _v in $(uniqlist "$@"); do echo "${_name}_${_inst}${_inst+_}${_v#${_name}_}" done } # # getinstlist() name inst list # Get a variable list only with the instance name. # getinstlist() { local _name _inst _v _l _name=$1 _inst=$2 shift 2 _l= for _v in $(uniqlist "$@"); do case $_v in ${_name}${_inst:+_}${_inst}_*) _l="${_l# }${_l:+ }$_v" ;; esac done uniqlist $_l } # # load_rc_config name # Source in the configuration file for a given name. # load_rc_config0() is the main routine and load_rc_config() is # a wrapper to handle multiple instances. # load_rc_config() { local _instances _inst _name _rcvars _defval _desc _k _v _ul # XXX: normalization ltr "$name" "-" "_" name ltr "$1" "-" "_" _name _load_rc_config0 $_name eval _instances=\$${_name}_instances _rcvars=$rcvars for _inst in $_instances; do # Set default values for ${_name}_$_inst. for _k in $(uniqlist $_rcvars); do # _k includes _name eval _defval=\${${_k}_defval} eval _desc=\${${_k}_desc} set_rcvar $(createinstlist $_name $_inst $_k) \ "$_defval" "$_desc" done for _k in $_rc_namevarlist; do if [ "$_k" = "instances" ]; then continue fi _k=${_name}_$_k # _k includes _name eval _defval=\${${_k}_defval} eval _desc=\${${_k}_desc} if [ -n "$_defval" ]; then set_rcvar $(createinstlist $_name $_inst $_k) \ "$_defval" "$_desc" fi done _load_rc_config0 ${_name}_$_inst done } _load_rc_config0() { local _name _rcvar_val _var _defval _v _msg _new _d _name=$1 if [ -z "$_name" ]; then err 3 'USAGE: load_rc_config name' fi if ${_rc_conf_loaded:-false}; then : else if [ -r /etc/defaults/rc.conf ]; then debug "Sourcing /etc/defaults/rc.conf" . /etc/defaults/rc.conf source_rc_confs elif [ -r /etc/rc.conf ]; then debug "Sourcing /etc/rc.conf (/etc/defaults/rc.conf doesn't exist)." . /etc/rc.conf fi _rc_conf_loaded=true fi for _d in /etc ${local_startup%*/rc.d}; do if [ -f ${_d}/rc.conf.d/"$_name" ]; then debug "Sourcing ${_d}/rc.conf.d/$_name" . ${_d}/rc.conf.d/"$_name" elif [ -d ${_d}/rc.conf.d/"$_name" ] ; then local _rc for _rc in ${_d}/rc.conf.d/"$_name"/* ; do if [ -f "$_rc" ] ; then debug "Sourcing $_rc" . "$_rc" fi done fi done # Set defaults if defined. for _var in $rcvar $rcvars; do eval _defval=\$${_var}_defval if [ -n "$_defval" ]; then eval : \${$_var:=\$${_var}_defval} fi done # check obsolete rc.conf variables for _var in $rcvars_obsolete; do eval _v=\$$_var eval _msg=\$${_var}_obsolete_msg eval _new=\$${_var}_newvar case $_v in "") ;; *) if [ -z "$_new" ]; then _msg="Ignored." else eval $_new=\"\$$_var\" if [ -z "$_msg" ]; then _msg="Use \$$_new instead." fi fi warn "\$$_var is obsolete. $_msg" ;; esac done } # # load_rc_config_var name var # Read the rc.conf(5) var for name and set in the # current shell, using load_rc_config in a subshell to prevent # unwanted side effects from other variable assignments. # load_rc_config_var() { if [ $# -ne 2 ]; then err 3 'USAGE: load_rc_config_var name var' fi eval $(eval '( load_rc_config '$1' >/dev/null; if [ -n "${'$2'}" -o "${'$2'-UNSET}" != "UNSET" ]; then echo '$2'=\'\''${'$2'}\'\''; fi )' ) } # # rc_usage commands # Print a usage string for $0, with `commands' being a list of # valid commands. # rc_usage() { echo -n 1>&2 "Usage: $0 [fast|force|one|quiet](" _sep= for _elem; do echo -n 1>&2 "$_sep$_elem" _sep="|" done echo 1>&2 ")" exit 1 } # # err exitval message # Display message to stderr and log to the syslog, and exit with exitval. # err() { exitval=$1 shift if [ -x /usr/bin/logger ]; then logger "$0: ERROR: $*" fi echo 1>&2 "$0: ERROR: $*" exit $exitval } # # warn message # Display message to stderr and log to the syslog. # warn() { if [ -x /usr/bin/logger ]; then logger "$0: WARNING: $*" fi echo 1>&2 "$0: WARNING: $*" } # # info message # Display informational message to stdout and log to syslog. # info() { case ${rc_info} in [Yy][Ee][Ss]|[Tt][Rr][Uu][Ee]|[Oo][Nn]|1) if [ -x /usr/bin/logger ]; then logger "$0: INFO: $*" fi echo "$0: INFO: $*" ;; esac } # # debug message # If debugging is enabled in rc.conf output message to stderr. # BEWARE that you don't call any subroutine that itself calls this # function. # debug() { case ${rc_debug} in [Yy][Ee][Ss]|[Tt][Rr][Uu][Ee]|[Oo][Nn]|1) if [ -x /usr/bin/logger ]; then logger "$0: DEBUG: $*" fi echo 1>&2 "$0: DEBUG: $*" ;; esac } # # backup_file action file cur backup # Make a backup copy of `file' into `cur', and save the previous # version of `cur' as `backup' or use rcs for archiving. # # This routine checks the value of the backup_uses_rcs variable, # which can be either YES or NO. # # The `action' keyword can be one of the following: # # add `file' is now being backed up (and is possibly # being reentered into the backups system). `cur' # is created and RCS files, if necessary, are # created as well. # # update `file' has changed and needs to be backed up. # If `cur' exists, it is copied to to `back' or # checked into RCS (if the repository file is old), # and then `file' is copied to `cur'. Another RCS # check in done here if RCS is being used. # # remove `file' is no longer being tracked by the backups # system. If RCS is not being used, `cur' is moved # to `back', otherwise an empty file is checked in, # and then `cur' is removed. # # backup_file() { _action=$1 _file=$2 _cur=$3 _back=$4 if checkyesno backup_uses_rcs; then _msg0="backup archive" _msg1="update" # ensure that history file is not locked if [ -f $_cur,v ]; then rcs -q -u -U -M $_cur fi # ensure after switching to rcs that the # current backup is not lost if [ -f $_cur ]; then # no archive, or current newer than archive if [ ! -f $_cur,v -o $_cur -nt $_cur,v ]; then ci -q -f -u -t-"$_msg0" -m"$_msg1" $_cur rcs -q -kb -U $_cur co -q -f -u $_cur fi fi case $_action in add|update) cp -p $_file $_cur ci -q -f -u -t-"$_msg0" -m"$_msg1" $_cur rcs -q -kb -U $_cur co -q -f -u $_cur chown root:wheel $_cur $_cur,v ;; remove) cp /dev/null $_cur ci -q -f -u -t-"$_msg0" -m"$_msg1" $_cur rcs -q -kb -U $_cur chown root:wheel $_cur $_cur,v rm $_cur ;; esac else case $_action in add|update) if [ -f $_cur ]; then cp -p $_cur $_back fi cp -p $_file $_cur chown root:wheel $_cur ;; remove) mv -f $_cur $_back ;; esac fi } # make_symlink src link # Make a symbolic link 'link' to src from basedir. If the # directory in which link is to be created does not exist # a warning will be displayed and an error will be returned. # Returns 0 on success, 1 otherwise. # make_symlink() { local src link linkdir _me src="$1" link="$2" linkdir="`dirname $link`" _me="make_symlink()" if [ -z "$src" -o -z "$link" ]; then warn "$_me: requires two arguments." return 1 fi if [ ! -d "$linkdir" ]; then warn "$_me: the directory $linkdir does not exist." return 1 fi if ! ln -sf $src $link; then warn "$_me: unable to make a symbolic link from $link to $src" return 1 fi return 0 } # devfs_rulesets_from_file file # Reads a set of devfs commands from file, and creates # the specified rulesets with their rules. Returns non-zero # if there was an error. # devfs_rulesets_from_file() { local file _err _me _opts file="$1" _me="devfs_rulesets_from_file" _err=0 if [ -z "$file" ]; then warn "$_me: you must specify a file" return 1 fi if [ ! -e "$file" ]; then debug "$_me: no such file ($file)" return 0 fi # Disable globbing so that the rule patterns are not expanded # by accident with matching filesystem entries. _opts=$-; set -f debug "reading rulesets from file ($file)" { while read line do case $line in \#*) continue ;; \[*\]*) rulenum=`expr "$line" : "\[.*=\([0-9]*\)\]"` if [ -z "$rulenum" ]; then warn "$_me: cannot extract rule number ($line)" _err=1 break fi rulename=`expr "$line" : "\[\(.*\)=[0-9]*\]"` if [ -z "$rulename" ]; then warn "$_me: cannot extract rule name ($line)" _err=1 break; fi eval $rulename=\$rulenum debug "found ruleset: $rulename=$rulenum" if ! /sbin/devfs rule -s $rulenum delset; then _err=1 break fi ;; *) rulecmd="${line%%"\#*"}" # evaluate the command incase it includes # other rules if [ -n "$rulecmd" ]; then debug "adding rule ($rulecmd)" if ! eval /sbin/devfs rule -s $rulenum $rulecmd then _err=1 break fi fi ;; esac if [ $_err -ne 0 ]; then debug "error in $_me" break fi done } < $file case $_opts in *f*) ;; *) set +f ;; esac return $_err } # devfs_init_rulesets # Initializes rulesets from configuration files. Returns # non-zero if there was an error. # devfs_init_rulesets() { local file _me _me="devfs_init_rulesets" # Go through this only once if [ -n "$devfs_rulesets_init" ]; then debug "$_me: devfs rulesets already initialized" return fi for file in $devfs_rulesets; do if ! devfs_rulesets_from_file $file; then warn "$_me: could not read rules from $file" return 1 fi done devfs_rulesets_init=1 debug "$_me: devfs rulesets initialized" return 0 } # devfs_set_ruleset ruleset [dir] # Sets the default ruleset of dir to ruleset. The ruleset argument # must be a ruleset name as specified in devfs.rules(5) file. # Returns non-zero if it could not set it successfully. # devfs_set_ruleset() { local devdir rs _me [ -n "$1" ] && eval rs=\$$1 || rs= [ -n "$2" ] && devdir="-m "$2"" || devdir= _me="devfs_set_ruleset" if [ -z "$rs" ]; then warn "$_me: you must specify a ruleset number" return 1 fi debug "$_me: setting ruleset ($rs) on mount-point (${devdir#-m })" if ! /sbin/devfs $devdir ruleset $rs; then warn "$_me: unable to set ruleset $rs to ${devdir#-m }" return 1 fi return 0 } # devfs_apply_ruleset ruleset [dir] # Apply ruleset number $ruleset to the devfs mountpoint $dir. # The ruleset argument must be a ruleset name as specified # in a devfs.rules(5) file. Returns 0 on success or non-zero # if it could not apply the ruleset. # devfs_apply_ruleset() { local devdir rs _me [ -n "$1" ] && eval rs=\$$1 || rs= [ -n "$2" ] && devdir="-m "$2"" || devdir= _me="devfs_apply_ruleset" if [ -z "$rs" ]; then warn "$_me: you must specify a ruleset" return 1 fi debug "$_me: applying ruleset ($rs) to mount-point (${devdir#-m })" if ! /sbin/devfs $devdir rule -s $rs applyset; then warn "$_me: unable to apply ruleset $rs to ${devdir#-m }" return 1 fi return 0 } # devfs_domount dir [ruleset] # Mount devfs on dir. If ruleset is specified it is set # on the mount-point. It must also be a ruleset name as specified # in a devfs.rules(5) file. Returns 0 on success. # devfs_domount() { local devdir rs _me devdir="$1" [ -n "$2" ] && rs=$2 || rs= _me="devfs_domount()" if [ -z "$devdir" ]; then warn "$_me: you must specify a mount-point" return 1 fi debug "$_me: mount-point is ($devdir), ruleset is ($rs)" if ! mount -t devfs dev "$devdir"; then warn "$_me: Unable to mount devfs on $devdir" return 1 fi if [ -n "$rs" ]; then devfs_init_rulesets devfs_set_ruleset $rs $devdir devfs -m $devdir rule applyset fi return 0 } # Provide a function for normalizing the mounting of memory # filesystems. This should allow the rest of the code here to remain # as close as possible between 5-current and 4-stable. # $1 = size # $2 = mount point # $3 = (optional) extra mdmfs flags mount_md() { if [ -n "$3" ]; then flags="$3" fi /sbin/mdmfs $flags -s $1 md $2 } # Code common to scripts that need to load a kernel module # if it isn't in the kernel yet. Syntax: # load_kld [-e regex] [-m module] file # where -e or -m chooses the way to check if the module # is already loaded: # regex is egrep'd in the output from `kldstat -v', # module is passed to `kldstat -m'. # The default way is as though `-m file' were specified. load_kld() { local _loaded _mod _opt _re while getopts "e:m:" _opt; do case "$_opt" in e) _re="$OPTARG" ;; m) _mod="$OPTARG" ;; *) err 3 'USAGE: load_kld [-e regex] [-m module] file' ;; esac done shift $(($OPTIND - 1)) if [ $# -ne 1 ]; then err 3 'USAGE: load_kld [-e regex] [-m module] file' fi _mod=${_mod:-$1} _loaded=false if [ -n "$_re" ]; then if kldstat -v | egrep -q -e "$_re"; then _loaded=true fi else if kldstat -q -m "$_mod"; then _loaded=true fi fi if ! $_loaded; then if ! kldload "$1"; then warn "Unable to load kernel module $1" return 1 else info "$1 kernel module loaded." fi else debug "load_kld: $1 kernel module already loaded." fi return 0 } # ltr str src dst [var] # Change every $src in $str to $dst. # Useful when /usr is not yet mounted and we cannot use tr(1), sed(1) nor # awk(1). If var is non-NULL, set it to the result. ltr() { local _str _src _dst _out _com _var _str="$1" _src="$2" _dst="$3" _var="$4" _out="" local IFS="${_src}" for _com in ${_str}; do if [ -z "${_out}" ]; then _out="${_com}" else _out="${_out}${_dst}${_com}" fi done if [ -n "${_var}" ]; then setvar "${_var}" "${_out}" else echo "${_out}" fi } # Creates a list of providers for GELI encryption. geli_make_list() { local devices devices2 local provider mountpoint type options rest # Create list of GELI providers from fstab. while read provider mountpoint type options rest ; do case ":${options}" in :*noauto*) noauto=yes ;; *) noauto=no ;; esac case ":${provider}" in :#*) continue ;; *.eli) # Skip swap devices. if [ "${type}" = "swap" -o "${options}" = "sw" -o "${noauto}" = "yes" ]; then continue fi devices="${devices} ${provider}" ;; esac done < /etc/fstab # Append providers from geli_devices. devices="${devices} ${geli_devices}" for provider in ${devices}; do provider=${provider%.eli} provider=${provider#/dev/} devices2="${devices2} ${provider}" done echo ${devices2} } # Find scripts in local_startup directories that use the old syntax # find_local_scripts_old() { zlist='' slist='' for dir in ${local_startup}; do if [ -d "${dir}" ]; then for file in ${dir}/[0-9]*.sh; do grep '^# PROVIDE:' $file >/dev/null 2>&1 && continue zlist="$zlist $file" done for file in ${dir}/[!0-9]*.sh; do grep '^# PROVIDE:' $file >/dev/null 2>&1 && continue slist="$slist $file" done fi done } find_local_scripts_new() { local_rc='' for dir in ${local_startup}; do if [ -d "${dir}" ]; then for file in `grep -l '^# PROVIDE:' ${dir}/* 2>/dev/null`; do case "$file" in *.sample) ;; *) if [ -x "$file" ]; then local_rc="${local_rc} ${file}" fi ;; esac done fi done } # check_required_{before|after} command # Check for things required by the command before and after its precmd, # respectively. The two separate functions are needed because some # conditions should prevent precmd from being run while other things # depend on precmd having already been run. # check_required_before() { local _f case "$1" in start) for _f in $required_vars; do if ! checkyesno $_f; then warn "\$${_f} is not enabled." if [ -z "$rc_force" ]; then return 1 fi fi done for _f in $required_dirs; do if [ ! -d "${_f}/." ]; then warn "${_f} is not a directory." if [ -z "$rc_force" ]; then return 1 fi fi done for _f in $required_files; do if [ ! -r "${_f}" ]; then warn "${_f} is not readable." if [ -z "$rc_force" ]; then return 1 fi fi done ;; esac return 0 } check_required_after() { local _f _args case "$1" in start) for _f in $required_modules; do case "${_f}" in *~*) _args="-e ${_f#*~} ${_f%%~*}" ;; *:*) _args="-m ${_f#*:} ${_f%%:*}" ;; *) _args="${_f}" ;; esac if ! load_kld ${_args}; then if [ -z "$rc_force" ]; then return 1 fi fi done ;; esac return 0 } # check_jail mib # Return true if security.jail.$mib exists and set to 1. check_jail() { local _mib _v _mib=$1 if _v=$(${SYSCTL_N} "security.jail.$_mib" 2> /dev/null); then case $_v in 1) return 0;; esac fi return 1 } # check_kern_features mib # Return existence of kern.features.* sysctl MIB as true or # false. The result will be cached in $_rc_cache_kern_features_ # namespace. "0" means the kern.features.X exists. check_kern_features() { local _v [ -n "$1" ] || return 1; eval _v=\$_rc_cache_kern_features_$1 [ -n "$_v" ] && return "$_v"; if ${SYSCTL_N} kern.features.$1 > /dev/null 2>&1; then eval _rc_cache_kern_features_$1=0 return 0 else eval _rc_cache_kern_features_$1=1 return 1 fi } # check_namevarlist var # Return "0" if ${name}_var is reserved in rc.subr. _rc_namevarlist="program chroot chdir env flags fib nice user group groups prepend" check_namevarlist() { local _v for _v in $_rc_namevarlist; do case $1 in $_v) return 0 ;; esac done return 1 } # _echoonce var msg mode # mode=0: Echo $msg if ${$var} is empty. # After doing echo, a string is set to ${$var}. # # mode=1: Echo $msg if ${$var} is a string with non-zero length. # _echoonce() { local _var _msg _mode eval _var=\$$1 _msg=$2 _mode=$3 case $_mode in 1) [ -n "$_var" ] && echo "$_msg" ;; *) [ -z "$_var" ] && echo -n "$_msg" && eval "$1=finished" ;; esac } fi # [ -z "${_rc_subr_loaded}" ] _rc_subr_loaded=: ----Next_Part(Fri_Oct_17_10_22_59_2014_318)---- ----Security_Multipart0(Fri_Oct_17_10_22_59_2014_900)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlRAb3MACgkQTyzT2CeTzy3EuQCeP4RN0h3xdzYGX0KRN94739Yf d4UAoL5ub3g++5oEfENqbesRTS+/GQlH =Q0pT -----END PGP SIGNATURE----- ----Security_Multipart0(Fri_Oct_17_10_22_59_2014_900)---- From owner-freebsd-current@FreeBSD.ORG Fri Oct 17 03:41:39 2014 Return-Path: Delivered-To: freebsd-current@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 41A55BC0; Fri, 17 Oct 2014 03:41:39 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 1AE12AE8; Fri, 17 Oct 2014 03:41:38 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id B186160706; Fri, 17 Oct 2014 03:41:31 +0000 (UTC) Message-ID: <54408FF3.10902@freebsd.org> Date: Thu, 16 Oct 2014 23:41:39 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: [CFT] multiple instance support in rc.d script References: <20141017.102259.2303779237508789020.hrs@allbsd.org> In-Reply-To: <20141017.102259.2303779237508789020.hrs@allbsd.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KjqH1SK7gMFcjvNrbxSvMMsqEkCcmPP1J" Cc: "dte >> Devin Teske" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 03:41:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KjqH1SK7gMFcjvNrbxSvMMsqEkCcmPP1J Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2014-10-16 21:22, Hiroki Sato wrote: > [Please reply to freebsd-rc@] >=20 > Hi, >=20 > I would like your feedback and testers of the attached patch. This > implements multiple instance support in rc.d scripts. You can try it > by replacing /etc/rc.subr with the attached one. >=20 > More details are as follow. Typically, an rc.d/foo script has the > following structure and rc.conf variables: >=20 > /etc/rc.d/foo: > ---- > name=3Dfoo > rcvar=3Dfoo_enable > ... > load_rc_command $name > run_rc_command $* > ---- >=20 > /etc/rc.conf: > ---- > foo_enable=3D"YES" > foo_flags=3D"-f -l -a -g" > ---- >=20 > The above supports one instance for one script. After replacing > rc.subr, you can specify additional instances in rc.conf: >=20 > /etc/rc.conf: > ---- > foo_instances=3D"one two" >=20 > foo_one_enable=3D"YES" > foo_one_flags=3D"-f -l -a -g" >=20 > foo_two_enable=3D"YES" > foo_two_flags=3D"-F -L -A -G" > ---- >=20 > $foo_instances defines instances by space-separated list of instance > names, and rc.conf variables for them are something like > ${name}_${instname}_enable. The following command >=20 > # service foo start >=20 > starts foo_one and foo_two with the specified flags. Instances can > be specified in the following form: >=20 > # service foo start:one >=20 > or multiple instances in a particular order: >=20 > # service foo start:two,one >=20 > Basically, no change is required for the rc.d/foo script itself. > However, there is a problem that default values of the instantiated > variables are not defined. >=20 > For example, if an rc.d/script uses $foo_mode, you need to define > $foo_one_mode. The default value of $foo_mode is usually defined in > etc/defaults/rc.conf for rc.d scripts in the base system and ": > ${foo_mode:=3Dvalue}" idiom in scripts from Ports Collection. So all > of the variables should be defined for each instance, too. As you > noticed, this is not easy without editing the script itself. >=20 > To alleviate this, set_rcvar() can be used: >=20 > /etc/rc.d/foo: > ---- > name=3Dfoo > rcvar=3Dfoo_enable >=20 > set_rcvar foo_enable YES "Enable $name" > set_rcvar foo_program "/tmp/test" "Command for $name" > ... > load_rc_command $name > run_rc_command $* > ---- >=20 > The three arguments are varname, default value, and description. If > a variable is defined by set_rcvar(), default values instantiated > variables will be set automatically---foo_one_program is set by > foo_program if it is not defined. >=20 > This approach still has another problem. set_rcvar() is not > supported in all branches, so a script using it does not work in old > supported branches. One solution which can be used for scripts in > Ports Collection is adding both definitions before and after > load_rc_command() until EoL of old branches like this: >=20 > /etc/rc.d/foo: > ---- > name=3Dfoo > rcvar=3Dfoo_enable >=20 > if type set_rcvar >/dev/null 2>&1; then > set_rcvar foo_enable YES "Enable $name" > set_rcvar foo_program "/tmp/test" "Command for $name" > fi > ... > load_rc_command $name >=20 > # will be removed after all supported branches have set_rcvar(). > if ! type set_rcvar >/dev/null 2>&1; then > : ${foo_enable:=3D"YES"} > : ${foo_program:=3D"/tmp/test"} > for _i in $foo_instances; do > for _j in enable program; do > eval : \${foo_${_i}_enable:=3D\$foo_$_j} > done > done > fi >=20 > run_rc_command $* > ---- >=20 > This is a bit ugly but should work fine. >=20 > I am using this patch to invoke multiple named (caching > server/contents server) and syslogd (local only/listens INET/INET6 > socket only) daemons. While $foo_instances is designed as a > user-defined knob, this can be applied to software which need to > invoke multiple/different daemons which depend on each other in a > script, too. >=20 > I am feeling this patch still needs more careful review from others. > Any comments are welcome. Thank you. >=20 > -- Hiroki >=20 This feature is quite useful. I've used the built in version that the rc.d script in memcached and it is very helpful to be able to run multiple named instances. I wonder if sysrc could be improved to support an 'append', so you can ha= ve: foo_instances=3D"one two" and do: sysrc --append foo_instances=3Dthree to get: foo_instances=3D"one two three" instead of having to do: sysrc foo_instances=3D"`sysrc -n foo_instances` three" or something more convoluted --=20 Allan Jude --KjqH1SK7gMFcjvNrbxSvMMsqEkCcmPP1J Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJUQI/2AAoJEJrBFpNRJZKf82wP/1j1bAHgJqk4moMCI6fLgK4y yATrAPOY7NcX7TIqI719JvhLTrgxzUrdTVAY9O/TYuOtlVz0FabtvPbL2Pd8yS+f z94IKkiF3dNglXz0DeFNBoi3bIstAL6eP9Rxrbx5zFxDOCLQjqZBWTIhjElPSrUF JsiWcsHGcbtG8aD9YKI4zXlK8WrKtWISBGikZ3B2jEuT5yw+mIkCKspmHMac+DfY Y1/wdxECjuLkvhNHgJCvR6pZLDEyu3O8bzRxfKpI/68T131S/4SEDZeNUN69NFYG 927v5ZqOX0AYIFZPw05NpEmFjUUz9/f1GJTYnyHfpP7ZaXF5o8FbUFXS/zAzFFgs VH/I/ws45xfsrKNDH1JXfxPQJczAvFxnR6LIaqiOKAqm1lvM5HKDqplftWlA5uox /CzY6njDiugYGaOY2yJhx2Qj6g0PNUUECjDPeZqw6dCHQohltiYK81LaNG6vOLJK 12vizOcqYIb+eQm9UI8vBqY9wFwWuDJNu963YtkNiVDc74Z2k/1w2qhtHzrHkMvW SYO1BTo+OZApo2Nvh/U3qyd9huOmaBa3YL8aUCOHruE8zqbmkEzgWKj67gQM9Nk9 OowYx8y8+36jij7QkJiDqP2Rm5Y6nFsVWn2Y94PJGXMS3tZ2fckZp8f178+fwLQs TfDfGRs7IK65f3VfITbz =VlVl -----END PGP SIGNATURE----- --KjqH1SK7gMFcjvNrbxSvMMsqEkCcmPP1J-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 17 04:10:31 2014 Return-Path: Delivered-To: current@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 D05B423D; Fri, 17 Oct 2014 04:10:31 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B4AD6CCB; Fri, 17 Oct 2014 04:10:31 +0000 (UTC) Received: from delphij-macbook.home.us.delphij.net (unknown [IPv6:2001:470:83bf:0:14f4:f167:6c7a:fce4]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 091FE3A1F; Thu, 16 Oct 2014 21:10:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1413519031; x=1413533431; bh=SfnrGzueCF9MRC2ek5cax3DnRNglwirXPkkHvyqKmFY=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=NszhTEg2dcNN7Kps3S4ZLJqh6ipWEUh/pc2eMYI7rgE2B6V9buTHyhm35BBZ+mSo2 smdugX0FsdO0WuNJGK+M2FJObCI1yJgaUfdgF6JDSX1LzSxqI6+MqATsVcD9X/3H3g GzyWu/Vw7EmCINBjYAPZt8yPXGvv6V0gud3FrWKI= Message-ID: <544096B3.20306@delphij.net> Date: Thu, 16 Oct 2014 21:10:27 -0700 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: "James R. Van Artsdalen" , d@delphij.net Subject: Re: zfs recv hangs in kmem arena References: <54250AE9.6070609@jrv.org> <543FAB3C.4090503@jrv.org> <543FEE6F.5050007@delphij.net> <54409050.4070401@jrv.org> In-Reply-To: <54409050.4070401@jrv.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, "James R. Van Artsdalen" , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 04:10:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 10/16/14 8:43 PM, James R. Van Artsdalen wrote: > On 10/16/2014 11:12 AM, Xin Li wrote: >>> On 9/26/2014 1:42 AM, James R. Van Artsdalen wrote: >>>> FreeBSD BLACKIE.housenet.jrv 10.1-BETA2 FreeBSD 10.1-BETA2 >>>> #2 r272070M: Wed Sep 24 17:36:56 CDT 2014 >>>> james@BLACKIE.housenet.jrv:/usr/obj/usr/src/sys/GENERIC >>>> amd64 >>>> >>>> With current STABLE10 I am unable to replicate a ZFS pool >>>> using zfs send/recv without zfs hanging in state "kmem >>>> arena", within the first 4TB or so (of a 23TB Pool). > >> What does procstat -kk 1176 (or the PID of your 'zfs' process >> that stuck in that state) say? >> >> Cheers, >> > SUPERTEX:/root# ps -lp 866 UID PID PPID CPU PRI NI VSZ RSS > MWCHAN STAT TT TIME COMMAND 0 866 863 0 52 0 66800 > 29716 kmem are D+ 1 57:40.82 zfs recv -duvF BIGTOX > SUPERTEX:/root# procstat -kk 866 PID TID COMM TDNAME > KSTACK 866 101573 zfs - mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d vmem_xalloc+0x568 vmem_alloc+0x3d > kmem_malloc+0x33 keg_alloc_slab+0xcd keg_fetch_slab+0x151 > zone_fetch_slab+0x7e zone_import+0x40 uma_zalloc_arg+0x34e > arc_get_data_buf+0x31a arc_buf_alloc+0xaa dmu_buf_will_fill+0x169 > dmu_write+0xfc dmu_recv_stream+0xd40 zfs_ioc_recv+0x94e > zfsdev_ioctl+0x5ca Do you have any special tuning in your /boot/loader.conf? Cheers, -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUQJazAAoJEJW2GBstM+ns6dQQAK4NM6X40d7tS7pqoTQvZbrD U0u5kid703tWgAlSFzvORxeOEB94BxcHu/z1a68nGhUlL2kip8SirWV9A1rqBpes i4T6asHYTcFj4OvaPfSoA7lSVsZIaLK+RscraN1b7hehSG9UExeYF8D7cRIguhoa 1Gnlv5iZZkjJZGjR0R6DmxC8C1CyNxAZBXnj1L+ofpgUzqH0Rw2TCW1XVKqMcxvI 5lpt+V0uu7MPNgjzgVy/1z5ZD2SUBPco0eHuN/Npj0c6HkmHkoWqd53vxrBhlyCP eDbzLw7QTO7PaV5hAuC9y9/X1JGlmTVa0GP2irKuE5t1bAbVwUPQqpn+iiFs1Le8 34fL/jkCeSBY6voYYj100CBU1/1mZOh93wuY6FdMVWPJp/bsjbDUtKZUmosGU86j ZMikfVNl5Jc5dmH30JGFCDOWzfaFq+V34toSfYIihaBQPyFov0Mr7De5MvQ7VJ7D qiXDcfAXE99CXzAboYpruwrbxyxTqhUmXlWp2uCPqvmo0WhVUsROmhhXhWXkG3tS S7L0n4X8kgklveirZWq/oDsg4JXNTP2ernNdAYyhD7TbG/N4INdFaVuqZkDVDgny ibwY0HEzg2zskJOJBqr9a21fZx6c2dvJ1n+j5BaAq6ve2Hw2NyvUVWfMTknp4I8j t/JJtsDNs9xokH/veS3J =aBKI -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Oct 17 14:14:49 2014 Return-Path: Delivered-To: freebsd-current@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 BB0649A7; Fri, 17 Oct 2014 14:14:49 +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 2CF8CCB5; Fri, 17 Oct 2014 14:14:49 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id em10so1391026wid.1 for ; Fri, 17 Oct 2014 07:14:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:mime-version :content-type:content-disposition:user-agent; bh=OrlPgThDKp4yqUgxmtF4rmDACry4QLRbHcMzn2oHu5k=; b=cdSBkgqYMfBw24qly+HEsV6kUn0Kqkv/cl7KETYHlMFqaKaF/x9iRKOaVH4k8MTUiE igQ0hIjnKKeNLk+F65s6a/EHckk10yBINANYNL0g/P/GsyA9JtewCNXHUtN2IAjqXmeR Wwhb7t1KSrDgi1yGwXmp35q2RyHpb5t5XN6KkrCKhHRFB65jdhO/2+s31sJ0sbLIV7QO 9xcBryWhMogX2AqvAEPF1ANsmn1PeGP5p8skT5Qdzg/IJOBJKFFpOqNsYf41oiJrATf5 yL4AWWdlnHWUyMiTZK7QM8tOhdh2wm2eF+tF1ga7AFYRS2zDOvLkhXCzsrLUaUq8JSHG Bvaw== X-Received: by 10.180.76.41 with SMTP id h9mr14521907wiw.40.1413555287493; Fri, 17 Oct 2014 07:14:47 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id w10sm1855466wje.10.2014.10.17.07.14.46 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 17 Oct 2014 07:14:46 -0700 (PDT) Date: Fri, 17 Oct 2014 16:14:44 +0200 From: Mateusz Guzik To: freebsd-current@freebsd.org Subject: libmap.conf vs packages and whatnot Message-ID: <20141017141444.GA16591@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , freebsd-current@freebsd.org, bapt@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: bapt@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 14:14:49 -0000 Hello, turns out that we got some additional cost when executing binaries. I'm not declaring I'm going to do any work on this, but I'd like to state why I don't like current approach. It's just my $0,03. So we got libmap.conf + /usr/local/etc/libmap.d directory. This results in: lstat("/etc",{ mode=drwxr-xr-x ,inode=22,size=117,blksize=7680 }) = 0 (0x0) lstat("/etc/libmap.conf",{ mode=-rw-r--r-- ,inode=384351,size=47,blksize=4096 }) = 0 (0x0) open("/etc/libmap.conf",O_CLOEXEC,0146) = 3 (0x3) fstat(3,{ mode=-rw-r--r-- ,inode=384351,size=47,blksize=4096 }) = 0 (0x0) mmap(0x0,47,PROT_READ,MAP_PRIVATE,3,0x0) = 34366185472 (0x800626000) close(3) = 0 (0x0) lstat("/usr",{ mode=drwxr-xr-x ,inode=9,size=17,blksize=4096 }) = 0 (0x0) lstat("/usr/local",{ mode=drwxr-xr-x ,inode=563,size=17,blksize=4096 }) = 0 (0x0) lstat("/usr/local/etc",{ mode=drwxr-xr-x ,inode=16407,size=44,blksize=4096 }) = 0 (0x0) lstat("/usr/local/etc/libmap.d",{ mode=drwxr-xr-x ,inode=12994,size=2,blksize=4096 }) = 0 (0x0) open("/usr/local/etc/libmap.d",O_NONBLOCK|O_DIRECTORY|O_CLOEXEC,0165) = 3 (0x3) fstatfs(0x3,0x7fffffffcaa0,0x0,0x400,0x1000,0x8080808080808080) = 0 (0x0) getdirentries(0x3,0x800624000,0x1000,0x800623028,0x1000,0x8080808080808080) = 24 (0x18) getdirentries(0x3,0x800624000,0x1000,0x800623028,0x1000,0x8080808080808080) = 0 (0x0) close(3) = 0 (0x0) For each exec, even though in vast majority of cases there is no need for this. Also note the directory is empty, otherwise this is another round of lstats + open for each file. I'm told this will be needed for ports so that they can shuffle libraries for interested programs. I don't know problem area very well, so please correct me if this stuff cannot work. First off, if there is no way around needing to parse data, I would suggest generating a binary blob which can be mmapped and quickly traversed. 1st case: we want new lib for each program just replace a symlink (or better yet, a hardlink) to the old one. 2nd case: only selected programs should get new lib For each prog in need, one can create /usr/local/etc/libmap.d/${prog}. And there you go, one open and if it failed there is nothing to do. Path in question can be a symlink to a bigger file with a set of remmapped libraries, or possibly can 'include ${some_set}'. It is unclear to me whether ports tree guarantees unique names of binaries. If not, maybe there will be an easy way to guarantee lookups or unique stuff anyway (putting some crap in during compilation/linkage?). This way the cost for uninterested progs is greatly reduced. Interested progs also get this faster, as long as there are more than 3 files (as with current approach one would have to parse them all). -- Mateusz Guzik From owner-freebsd-current@FreeBSD.ORG Fri Oct 17 14:32:10 2014 Return-Path: Delivered-To: freebsd-current@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 0CC4CE86; Fri, 17 Oct 2014 14:32:10 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A414BEAA; Fri, 17 Oct 2014 14:32:09 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s9HEW4QS021180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Oct 2014 17:32:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s9HEW4QS021180 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s9HEW4iR021179; Fri, 17 Oct 2014 17:32:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 17 Oct 2014 17:32:04 +0300 From: Konstantin Belousov To: "Justin T. Gibbs" Subject: Re: OOM killer and kernel cache reclamation rate limit in vm_pageout_scan() Message-ID: <20141017143204.GH2153@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: alc@FreeBSD.org, freebsd-current@freebsd.org, Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 14:32:10 -0000 On Wed, Oct 15, 2014 at 11:56:33PM -0600, Justin T. Gibbs wrote: > avg pointed out the rate limiting code in vm_pageout_scan() during discussion about PR 187594. While it certainly can contribute to the problems discussed in that PR, a bigger problem is that it can allow the OOM killer to be triggered even though there is plenty of reclaimable memory available in the system. Any load that can consume enough pages within the polling interval to hit the v_free_min threshold (e.g. multiple 'dd if=/dev/zero of=/file/on/zfs') can make this happen. > > The product I?m working on does not have swap configured and treats any OOM trigger as fatal, so it is very obvious when this happens. :-) > > I?ve tried several things to mitigate the problem. The first was to ignore rate limiting for pass 2. However, even though ZFS is guaranteed to receive some feedback prior to OOM being declared, my testing showed that a trivial load (a couple dd operations) could still consume enough of the reclaimed space to leave the system below its target at the end of pass 2. After removing the rate limiting entirely, I?ve so far been unable to kill the system via a ZFS induced load. > > I understand the motivation behind the rate limiting, but the current implementation seems too simplistic to be safe. The documentation for the Solaris slab allocator provides good motivation for their approach of using a ?sliding average? to reign in temporary bursts of usage without unduly harming efficient service for the recorded steady-state memory demand. Regardless of the approach taken, I believe that the OOM killer must be a last resort and shouldn?t be called when there are caches that can be culled. > > One other thing I?ve noticed in my testing with ZFS is that it needs feedback and a little time to react to memory pressure. Calling it?s lowmem handler just once isn?t enough for it to limit in-flight writes so it can avoid reuse of pages that it just freed up. But, it doesn?t take too long to react (> 1sec in the profiling I?ve done). Is there a way in vm_pageout_scan() that we can better record that progress is being made (pages were freed in the pass, even if some/all of them were consumed again) and allow more passes before the OOM killer is invoked in this case? > > ? > Justin https://docs.freebsd.org/cgi/getmsg.cgi?fetch=103436+0+/usr/local/www/db/text/2014/freebsd-hackers/20141012.freebsd-hackers might have some relevance. From owner-freebsd-current@FreeBSD.ORG Fri Oct 17 21:12:36 2014 Return-Path: Delivered-To: freebsd-current@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 06A3EDB8 for ; Fri, 17 Oct 2014 21:12:36 +0000 (UTC) Received: from zhbdzmsp-smta17.bluewin.ch (zhbdzmsp-smta17.bluewin.ch [195.186.99.133]) by mx1.freebsd.org (Postfix) with ESMTP id 8EA41E6F for ; Fri, 17 Oct 2014 21:12:34 +0000 (UTC) Received: from [195.186.227.131] ([195.186.227.131:60629] helo=zhhdzmsp-smta14.bluewin.ch) by zhbdzmsp-smta17.bluewin.ch (envelope-from ) (ecelerity 3.5.7.40067 r(Platform:3.5.7.0)) with ESMTP id C7/95-26555-FF581445; Fri, 17 Oct 2014 21:11:27 +0000 Received: from noxon.firefly (176.127.15.207) by zhhdzmsp-smta14.bluewin.ch (8.5.142) (authenticated as tobias.berner) id 52330D9E1A2DF99B; Fri, 17 Oct 2014 21:11:27 +0000 From: "Tobias C. Berner" To: 'Current Current' Subject: kernel page fault with nfs Date: Fri, 17 Oct 2014 23:11:26 +0200 Message-ID: <3430961.Iq02vNgBU7@noxon.firefly> User-Agent: KMail/4.14.2 (FreeBSD/11.0-CURRENT; KDE/4.14.2; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Mailman-Approved-At: Fri, 17 Oct 2014 21:45:59 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 21:12:36 -0000 Hi For some days now I've had problems with my current (last test with r273178M). Sometimes when accessing a nfs-share there is a pagefault: ####################################################### Fatal trap 12: page fault while in kernel mode cpuid = 7; apic id = 07 fault virtual address = 0xfffffe07cfe60400 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80d4d4b6 stack pointer = 0x28:0xfffffe086088b380 frame pointer = 0x28:0xfffffe086088b3f0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 43868 (mplayer) #0 0xffffffff80926d29 in shutdown_nice (howto=1) at /usr/src/sys/kern/kern_shutdown.c:207 #1 0xffffffff80926a2d in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:444 #2 0xffffffff80926f80 in panic (fmt=0x104
) at /usr/src/sys/kern/kern_shutdown.c:698 #3 0xffffffff8035f147 in panic_cmd_del (arg=0x0) at /usr/src/sys/ddb/db_command.c:244 #4 0xffffffff8035ed5d in db_command (cmd_table=0x0) at /usr/src/sys/ddb/db_command.c:439 #5 0xffffffff8035ead4 in db_command_loop () at /usr/src/sys/ddb/db_command.c:488 #6 0xffffffff803615e0 in db_trap (type=, code=0) at /usr/src/sys/ddb/db_main.c:247 #7 0xffffffff80966db1 in kdb_trap (type=12, code=0, tf=0xfffffe086088b2d0) at /usr/src/sys/kern/subr_kdb.c:626 #8 0xffffffff80d4f92c in trap_fatal (frame=0xfffffe086088b2d0, eva=) at /usr/src/sys/amd64/amd64/trap.c:835 #9 0xffffffff80d4fcbc in trap_pfault (frame=0xfffffe086088b2d0, usermode=0) at atomic.h:161 #10 0xffffffff80d4f2de in trap (frame=0xfffffe086088b2d0) at /usr/src/sys/amd64/amd64/trap.c:594 #11 0xffffffff80d33822 in Xtss () at /usr/src/sys/amd64/amd64/exception.S:154 #12 0xffffffff80d4d4b6 in stack_save_td (st=, td=) at /usr/src/sys/amd64/amd64/stack_machdep.c:74 #13 0xffffffff809f30b2 in foffset_unlock (fp=, val=, flags=) at /usr/src/sys/kern/vfs_vnops.c:700 #14 0xffffffff8082faad in ncl_bioread (vp=0xfffff80201dd7490, uio=0xfffffe086088b7d8, ioflag=, cred=0xfffff8015816a600) at /usr/src/sys/fs/nfsclient/nfs_clbio.c:511 #15 0xffffffff80e64381 in VOP_MARKATIME_APV (vop=, a=0xfffffe086088b650) at vnode_if.c:856 #16 0xffffffff809f4dd5 in vn_read (fp=0xfffff80272490cd0, uio=0xfffffe086088b7d8, active_cred=0xfffff8015816a600, flags=128, td=0xfffff80000000000) at vnode_if.h:859 #17 0xffffffff809f5502 in get_advice (fp=0xfffffe086088b730, uio=0x400) at /usr/src/sys/kern/vfs_vnops.c:729 #18 0xffffffff809f2b80 in vn_io_fault1 () at /usr/src/sys/kern/vfs_vnops.c:1058 #19 0xffffffff809f0d3b in vn_io_fault (fp=0xfffff80272490cd0, uio=0xfffffe086088b970, active_cred=0x400, flags=128, td=0xfffff80000000000) at /usr/src/sys/kern/vfs_vnops.c:128 #20 0xffffffff80981d95 in freebsd6_pread (td=0xfffff802d93204a8, uap=0xfffff9fb094c00a8) at /usr/src/sys/kern/sys_generic.c:217 #21 0xffffffff80981ab8 in sys_cap_fcntls_get (td=, uap=0x800) at /usr/src/sys/kern/sys_capability.c:576 #22 0xffffffff80981a43 in sys_cap_fcntls_get (td=, uap=0x0) at sx.h:183 #23 0xffffffff80d503cb in amd64_syscall (td=0x45e400, traced=0) at subr_syscall.c:87 #24 0xffffffff80d33b0b in Xprot () at /usr/src/sys/amd64/amd64/exception.S:324 #25 0x0000000806a7fe6a in ?? () ################################################## Any hints would be appreciated. Please let me know if further information is required. Thanks in advance, Tobias From owner-freebsd-current@FreeBSD.ORG Fri Oct 17 23:08:17 2014 Return-Path: Delivered-To: freebsd-current@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 8E5043B7 for ; Fri, 17 Oct 2014 23:08:17 +0000 (UTC) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (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 13807AC6 for ; Fri, 17 Oct 2014 23:08:16 +0000 (UTC) Received: by mail-lb0-f179.google.com with SMTP id l4so1430813lbv.38 for ; Fri, 17 Oct 2014 16:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=lO0Ti8PLIAxqJZ3k4FtbfwjXsCjJREAAOitTCZj4++M=; b=HDYgzTYUdot0T6tJb2pvSYm+WpQb/OFv+NYdsg9SXG6/J45G8ksaNxonISS2J9o6qt LcIWDQJmMIqZSm0Sr2CxMTwNJ8MJ3vGT56/4w8I78uRB3YLTwjU0vVIJZzM9oTiie4S1 PMlGiJ/OgyJReGrVpZ7E1uH/1geSGNk0yqoPpI7DVbj6rN8dbY0wCEX2Xk/Q+EcTtROa heRyqzSebiOI+sE/TxCU6AtKZaKyFzPBNoAeMvw4L61IoaMDEbcjcIPA+BiDsO5OHJBU Kq+2CbebED0qD25rfByb8igAR/sWfIV0caY99nA02JBGQ9KZeE5L2GQWK4Lb+PXzeKcj 1hVA== MIME-Version: 1.0 X-Received: by 10.152.36.33 with SMTP id n1mr6118892laj.95.1413586992903; Fri, 17 Oct 2014 16:03:12 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.131.66 with HTTP; Fri, 17 Oct 2014 16:03:12 -0700 (PDT) In-Reply-To: References: <20140811221043.492110d4@arch> <20140813213718.4814f58c@arch> <53EC1214.9020505@pinyon.org> Date: Fri, 17 Oct 2014 16:03:12 -0700 X-Google-Sender-Auth: aGeTuDoMbuDZhe2RuzPjFYhX_e0 Message-ID: Subject: Re: HOWTO articles for migrating from Linux to FreeBSD, especially for pkg? From: Craig Rodrigues To: "Russell L. Carter" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 23:08:17 -0000 On Fri, Aug 15, 2014 at 12:01 PM, Craig Rodrigues wrote: > On Wed, Aug 13, 2014 at 6:34 PM, Russell L. Carter > wrote: > > One complaint I have about the FreeBSD project, is that the core > project contributors and developers rely too much on > e-mail for communication. This certainly works, and I use it too, but > new and casual users getting into FreeBSD > may get lost in the maze of FreeBSD mailing lists. It would be nice > if more of the core project contributors > used the web forums ( http://forums.freebsd.org ), since stuff like > that shows up nicely in web searches, and it is easier > for newcomers to find stuff, and jump in and contribute to threads, > versus mailing lists. > I just noticed this: https://forums.freebsd.org/threads/new-forums-software-online.48495/ The FreeBSD Forums Administration team just upgraded the forum software from phpBB to Xenforo. They migrated 260,000 messages......wow, this is a huge achievement! Xenforo is nice stuff, so hopefully more FreeBSD core developers can take advantage of the forums, in addition to the traditional mailing lists. -- Craig From owner-freebsd-current@FreeBSD.ORG Fri Oct 17 23:24:40 2014 Return-Path: Delivered-To: freebsd-current@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 1B9FC710 for ; Fri, 17 Oct 2014 23:24:40 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AD637CF2 for ; Fri, 17 Oct 2014 23:24:39 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id h11so5201176wiw.0 for ; Fri, 17 Oct 2014 16:24:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=8Ge9mdNID6RnySi0y8MIiK4A3+zdMY3S3TegLSzthNk=; b=THWG49bUDCHmyGOQbWvmWGtqtwLXkiXYzYeFHWSQfbMJJl3v5qDr+stmEyCkipKIve Nuj9LBmsryaPOG+wzB3elmMqT1NqgYR48Wk+fVyAyhJmCrA7bEUd+6T97qHJzxNEi15+ 9F+iFfgQpyKUSkB+7WpoSp/B5o4kL2+B9jwFrNeYzBD9S/FqZQMZ/bIfJlfLnc3X8uZY g0MeQx+fF4JvgcchGc0I4k0tQiUgtLTjMnJFJdP+L1DjeUf7USY7TxF8G8NCNmagpmbA TkEpBXS4qR51cJN8432sgDy1Sd2GHHnVTIVwU1MEHiuD5HYuIXMYlBxHYYW2WFcz1xfG KZ3A== MIME-Version: 1.0 X-Received: by 10.180.21.163 with SMTP id w3mr2154711wie.66.1413586768344; Fri, 17 Oct 2014 15:59:28 -0700 (PDT) Received: by 10.194.190.78 with HTTP; Fri, 17 Oct 2014 15:59:28 -0700 (PDT) Date: Sat, 18 Oct 2014 06:59:28 +0800 Message-ID: Subject: ssh None cipher From: Ben Woods To: freebsd-current@freebsd.org X-Mailman-Approved-At: Sat, 18 Oct 2014 02:01:25 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 23:24:40 -0000 Whilst trying to replicate data from my FreeNAS to my FreeBSD home theater PC on my local LAN, I came across this bug preventing use of the None cipher: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=163127 I think I could enable the None cipher by recompiling base with a flag in /etc/src.conf. Is there any harm in enabling this by default, but having the None cipher remain disabled in /etc/ssh/sshd_config? That way people wouldn't have it on my default, but wouldn't have to recompile to enable it. Thoughts? -- -- From: Benjamin Woods woodsb02@gmail.com From owner-freebsd-current@FreeBSD.ORG Sat Oct 18 02:43:51 2014 Return-Path: Delivered-To: freebsd-current@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 C5EC32D2 for ; Sat, 18 Oct 2014 02:43:51 +0000 (UTC) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 50429B3 for ; Sat, 18 Oct 2014 02:43:50 +0000 (UTC) X-AuditID: 1209190c-f795e6d000006c66-cd-5441d3dff4dc Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 09.01.27750.FD3D1445; Fri, 17 Oct 2014 22:43:43 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s9I2hg2Z005306; Fri, 17 Oct 2014 22:43:42 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9I2heD7004075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 Oct 2014 22:43:42 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s9I2heY4008525; Fri, 17 Oct 2014 22:43:40 -0400 (EDT) Date: Fri, 17 Oct 2014 22:43:39 -0400 (EDT) From: Benjamin Kaduk To: Ben Woods Subject: Re: ssh None cipher In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHIsWRmVeSWpSXmKPExsUixG6nonv/smOIwbTD/BZz3nxgspj6/iOr A5PHjE/zWTx2zrrLHsAUxWWTkpqTWZZapG+XwJWxbst8toJPrBW3jjxibmC8wtLFyMEhIWAi 8fB5ZRcjJ5ApJnHh3nq2LkYuDiGB2UwSE9ufs0A4Gxkl1u64COUcYpKY+u0gM0iLkEADo8Sv D/wgNouAtsS8W0fYQGw2ARWJmW82gtkiAkoSvRv/sYLYzALyEv+vXGYCsYUFZCTOTfnGDmJz CgRKtP27xghi8wo4ShzduYwJYn6AxNFpC8BqRAV0JFbvn8ICUSMocXLmExaImVoSy6dvY5nA KDgLSWoWktQCRqZVjLIpuVW6uYmZOcWpybrFyYl5ealFuoZ6uZkleqkppZsYQYHKKcmzg/HN QaVDjAIcjEo8vAtOOoYIsSaWFVfmHmKU5GBSEuXlOAsU4kvKT6nMSCzOiC8qzUktPsQowcGs JMI7dTJQjjclsbIqtSgfJiXNwaIkzrvpB1+IkEB6YklqdmpqQWoRTFaGg0NJgrfvElCjYFFq empFWmZOCUKaiYMTZDgP0PBFIDW8xQWJucWZ6RD5U4zGHC1Nb3uZOO6c/NDLJMSSl5+XKiXO WwVSKgBSmlGaBzcNlmxeMYoDPSfMewCkigeYqODmvQJaxQS0asVvB5BVJYkIKakGRocDUz3W LpoalZy0bedq+6Xzeqc/6933YqrIqU+dFd/kT049sHzG3+5GxovbOHevvPv6WIdky4Yramf/ J0sZvStsnfFthoHI7p8+Soc1dxQrNpVcOdU+4dpq8W9VJ6V2+kruf/bCbkGCdWHaRR6OHKa5 27feUBWbXta+/d2aJW3TmJ5Ef5iuWqepxFKckWioxVxUnAgA5ypZOREDAAA= Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 02:43:51 -0000 On Fri, 17 Oct 2014, Ben Woods wrote: > Whilst trying to replicate data from my FreeNAS to my FreeBSD home theater > PC on my local LAN, I came across this bug preventing use of the None > cipher: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=163127 > > I think I could enable the None cipher by recompiling base with a flag in > /etc/src.conf. I agree. > Is there any harm in enabling this by default, but having the None cipher > remain disabled in /etc/ssh/sshd_config? That way people wouldn't have it > on my default, but wouldn't have to recompile to enable it. I do not see any immediate and concrete harm that doing so would cause, yet that is insufficient for me to think that doing so would be a good idea. -Ben From owner-freebsd-current@FreeBSD.ORG Sat Oct 18 04:10:23 2014 Return-Path: Delivered-To: freebsd-current@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 A88DAA34 for ; Sat, 18 Oct 2014 04:10:23 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 818E6A2C for ; Sat, 18 Oct 2014 04:10:22 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 53B656199B for ; Sat, 18 Oct 2014 04:10:15 +0000 (UTC) Message-ID: <5441E834.2000906@freebsd.org> Date: Sat, 18 Oct 2014 00:10:28 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: ssh None cipher References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8orAXqGSb5FtwfURkCEjVSwKt5TWSr1Bo" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 04:10:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8orAXqGSb5FtwfURkCEjVSwKt5TWSr1Bo Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2014-10-17 22:43, Benjamin Kaduk wrote: > On Fri, 17 Oct 2014, Ben Woods wrote: >=20 >> Whilst trying to replicate data from my FreeNAS to my FreeBSD home the= ater >> PC on my local LAN, I came across this bug preventing use of the None >> cipher: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D163127 >> >> I think I could enable the None cipher by recompiling base with a flag= in >> /etc/src.conf. >=20 > I agree. >=20 >> Is there any harm in enabling this by default, but having the None cip= her >> remain disabled in /etc/ssh/sshd_config? That way people wouldn't have= it >> on my default, but wouldn't have to recompile to enable it. >=20 > I do not see any immediate and concrete harm that doing so would cause,= > yet that is insufficient for me to think that doing so would be a good > idea. >=20 > -Ben > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 I've been using openssh-portable from ports with the none cipher patch to get around this. IIRC, upstream openssh refuses to merge the none cipher patches "because you shouldn't do that". But I'd vote for having it compiled in and just disabled by default. It will refuse to let you have a shell without encryption, and prints a big fat hairy warning when encryption is disabled. --=20 Allan Jude --8orAXqGSb5FtwfURkCEjVSwKt5TWSr1Bo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJUQeg3AAoJEJrBFpNRJZKfiGcQAKoEo0vJ2YvTo6MX45A+L//y s1jWcMQaESoZ8oxkKcAVI2yic1xFKrNSru4g0/m9awO4KuGjrnx/guy0DK+x7Ge3 B/HqAGIKZFuYbsPnxQhxLF8jpjxudbMPM/RO1Qr1KcqQuGwInR6OHjt+c8Yif6r1 0pLayFB69m6eCdUfGEBmdznl43jlhZWhABk4pj7rTq6zO/IhbiEX6vaAHwqIsRj2 3jFr2PL4roH49VvyKfNO7k3bNJO1mekaJ0YPtWJJigxJeBVzWfay2/sJr2urwnhk MNbr8fQ5zqiN2oJaZYA1q8pkaUSCsrqhk5iBgLJRucYXTKo0L+3pEPTv7bN0ozZW 0hi/wry1JuYZrj3oEKWzHqfVytVwg7WIOcqVxMu/m0JaV9GHv0+fNxoBQ71LWhiH Pb0VgBK06Xzx9zrhgtHRPG4QP5zxcaZXijiiDsNEcpgZYR2Hv2Sra7Yd0MUrj+eI flyR9ycw8bCnKoG8cobHU2qDyfe7uKA4BFNlmobd5VkLcig5zHr0eXxEcBa/5uYM blHA3bRKyNNXmDmK65prvItWhtPdrH+MTwPbe86AfYe2xyzi3kiRp08bjEYwCaXC f/QAe63ugfblWJ+Czdx52hpN82BLK5ZFhf7r9hEcZ/mAGjesbx31YjWh4IaRj/nE bXf1K0tMZAbUmbA3ebiA =Dkz8 -----END PGP SIGNATURE----- --8orAXqGSb5FtwfURkCEjVSwKt5TWSr1Bo-- From owner-freebsd-current@FreeBSD.ORG Sat Oct 18 04:12:09 2014 Return-Path: Delivered-To: freebsd-current@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 E292BB37; Sat, 18 Oct 2014 04:12:09 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (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 B9799ACB; Sat, 18 Oct 2014 04:12:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=lOcaxKSaNEE4FvaUyYx8b296t8RgwX/Kxk3ZKMjFT0U=; b=I/q79uJrFtQ23qP93aHKJYVRTupcham+9oX/ikck8NIiYwXDBkSMTMgKhPxFOoUu5Sn0MqUXkoaIT2290TkbaFTIPgDgyJJ7I4uq8XwxgFOayAwtJfLdX1wS5qSnNbnMx47zpVZauDBn2unMWExTbsahYqHU6LY2+xJNR76bB6M=; Received: from [203.174.11.50] (port=46963 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (UNKNOWN:AES128-GCM-SHA256:128) (Exim 4.82) (envelope-from ) id 1XfLN3-004GFK-Og; Fri, 17 Oct 2014 22:12:02 -0600 Date: Sat, 18 Oct 2014 12:11:50 +0800 From: Erich Dollansky To: Craig Rodrigues Subject: Re: HOWTO articles for migrating from Linux to FreeBSD, especially for pkg? Message-ID: <20141018121150.5aae6682@X220.alogt.com> In-Reply-To: References: <20140811221043.492110d4@arch> <20140813213718.4814f58c@arch> <53EC1214.9020505@pinyon.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: "Russell L. Carter" , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 04:12:10 -0000 Hi, On Fri, 15 Aug 2014 12:01:30 -0700 Craig Rodrigues wrote: > On Wed, Aug 13, 2014 at 6:34 PM, Russell L. Carter > wrote: > > > One complaint I have about the FreeBSD project, is that the core > project contributors and developers rely too much on > e-mail for communication. This certainly works, and I use it too, but > new and casual users getting into FreeBSD > may get lost in the maze of FreeBSD mailing lists. It would be nice > if more of the core project contributors mailing lists have two advantages I would not like to miss. A) people can create their own archive and use it when they are offline B) Google & Co. offer good search tools to search the online archives > used the web forums ( http://forums.freebsd.org ), since stuff like I also noticed while travelling that some locations block the forum. Ok, it is rare. > that shows up nicely in web searches, and it is easier This is also true for the e-mails. Erich From owner-freebsd-current@FreeBSD.ORG Sat Oct 18 06:55:31 2014 Return-Path: Delivered-To: freebsd-current@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 334B1AB8 for ; Sat, 18 Oct 2014 06:55:31 +0000 (UTC) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E06FDA5B for ; Sat, 18 Oct 2014 06:55:30 +0000 (UTC) Received: from fortune.joker.local (180-198-225-68.nagoya1.commufa.jp [180.198.225.68]) (authenticated bits=0) by dec.sakura.ne.jp (8.14.3/8.14.2/[SAKURA-WEB]/20080708) with ESMTP id s9I5wwLD022246 for ; Sat, 18 Oct 2014 14:58:59 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sat, 18 Oct 2014 14:58:57 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Subject: Re: HOWTO articles for migrating from Linux to FreeBSD, especially for pkg? Message-Id: <20141018145857.c17931841923f39c79464033@dec.sakura.ne.jp> In-Reply-To: <20141018121150.5aae6682@X220.alogt.com> References: <20140811221043.492110d4@arch> <20140813213718.4814f58c@arch> <53EC1214.9020505@pinyon.org> <20141018121150.5aae6682@X220.alogt.com> Organization: Junchoon corps X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 06:55:31 -0000 On Sat, 18 Oct 2014 12:11:50 +0800 Erich Dollansky wrote: Hi. I think the advantages of the forum are... *Well moderated by moderators and anministrators. *Registering email address is needed, but not disclosed by default. These mean "no need to worry about increasing spams". In cases off-forum discussion is needed, private message can be used to exchange actual email address. > Hi, > > On Fri, 15 Aug 2014 12:01:30 -0700 > Craig Rodrigues wrote: > > > On Wed, Aug 13, 2014 at 6:34 PM, Russell L. Carter > > wrote: > > > > > One complaint I have about the FreeBSD project, is that the core > > project contributors and developers rely too much on > > e-mail for communication. This certainly works, and I use it too, but > > new and casual users getting into FreeBSD > > may get lost in the maze of FreeBSD mailing lists. It would be nice > > if more of the core project contributors > > mailing lists have two advantages I would not like to miss. > > A) people can create their own archive and use it when they are offline > B) Google & Co. offer good search tools to search the online archives > > > used the web forums ( http://forums.freebsd.org ), since stuff like > > I also noticed while travelling that some locations block the forum. > Ok, it is rare. > > > that shows up nicely in web searches, and it is easier > > This is also true for the e-mails. > > Erich > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- $B@DLZ(B $BCNL@(B [Tomoaki AOKI] junchoon@dec.sakura.ne.jp MXE02273@nifty.com From owner-freebsd-current@FreeBSD.ORG Sat Oct 18 10:54:47 2014 Return-Path: Delivered-To: freebsd-current@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 E8D703EC for ; Sat, 18 Oct 2014 10:54:46 +0000 (UTC) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id 9A088FB7 for ; Sat, 18 Oct 2014 10:54:46 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3jKh2D0bfgz17G for ; Sat, 18 Oct 2014 12:54:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= content-transfer-encoding:content-type:content-type:in-reply-to :references:subject:subject:mime-version:user-agent:organization :from:from:date:date:message-id:received:received:received; s= jakla4; t=1413629679; x=1416221680; bh=exVKDnnDuU3ttj8AN79NulqAG cet2Zw3dYRGQQlLqWs=; b=YRfu8x3Hf6j+hwO1PyXsIKn3KBdjv9VMnEMZl7Rln QIF6Akvwma5i8YHXiLgScpedFl+KiS9RADA1Y3DJOhgStB0MFiq/xQqeILf3lksE XGuhePffuF2cCEyJII7unCVslYqFAyZExDBLRhBWJgjBo1Wqc6fAmLngpsi2FMlM w4= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id fJ0wHwyDIO83 for ; Sat, 18 Oct 2014 12:54:39 +0200 (CEST) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP for ; Sat, 18 Oct 2014 12:54:39 +0200 (CEST) Received: from sleepy.ijs.si (sleepy.ijs.si [IPv6:2001:1470:ff80:e001::1:1]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mildred.ijs.si (Postfix) with ESMTPSA id 3jKh266wKxzsm for ; Sat, 18 Oct 2014 12:54:38 +0200 (CEST) Message-ID: <544246E8.1090001@ijs.si> Date: Sat, 18 Oct 2014 12:54:32 +0200 From: Mark Martinec Organization: J. Stefan Institute User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: ssh None cipher References: <5441E834.2000906@freebsd.org> In-Reply-To: <5441E834.2000906@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 10:54:47 -0000 If the purpose of having a none cipher is to have a fast file transfer, then one should be using sysutils/bbcp for that purposes. Uses ssd for authentication, and opens unencrypted channel(s) for the actual data transfer. It's also very fast, can use multiple TCP streams. Mark On 10/18/14 06:10, Allan Jude wrote: > On 2014-10-17 22:43, Benjamin Kaduk wrote: >> On Fri, 17 Oct 2014, Ben Woods wrote: >> >>> Whilst trying to replicate data from my FreeNAS to my FreeBSD home theater >>> PC on my local LAN, I came across this bug preventing use of the None >>> cipher: >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=163127 >>> >>> I think I could enable the None cipher by recompiling base with a flag in >>> /etc/src.conf. >> >> I agree. >> >>> Is there any harm in enabling this by default, but having the None cipher >>> remain disabled in /etc/ssh/sshd_config? That way people wouldn't have it >>> on my default, but wouldn't have to recompile to enable it. >> >> I do not see any immediate and concrete harm that doing so would cause, >> yet that is insufficient for me to think that doing so would be a good >> idea. >> >> -Ben >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > > I've been using openssh-portable from ports with the none cipher patch > to get around this. > > IIRC, upstream openssh refuses to merge the none cipher patches "because > you shouldn't do that". But I'd vote for having it compiled in and just > disabled by default. > > It will refuse to let you have a shell without encryption, and prints a > big fat hairy warning when encryption is disabled. > From owner-freebsd-current@FreeBSD.ORG Sat Oct 18 11:56:52 2014 Return-Path: Delivered-To: freebsd-current@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 758B9B2F for ; Sat, 18 Oct 2014 11:56:52 +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 4DE1B6C9 for ; Sat, 18 Oct 2014 11:56:52 +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 40F4DB9A3; Sat, 18 Oct 2014 07:56:51 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: kernel page fault with nfs Date: Sat, 18 Oct 2014 06:43:58 -0400 Message-ID: <1995323.F02irpmLMA@ralph.baldwin.cx> User-Agent: KMail/4.12.5 (FreeBSD/10.1-BETA2; KDE/4.12.5; amd64; ; ) In-Reply-To: <3430961.Iq02vNgBU7@noxon.firefly> References: <3430961.Iq02vNgBU7@noxon.firefly> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Sat, 18 Oct 2014 07:56:51 -0400 (EDT) Cc: "Tobias C. Berner" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 11:56:52 -0000 On Friday, October 17, 2014 11:11:26 PM Tobias C. Berner wrote: > Hi > > > For some days now I've had problems with my current (last test with > r273178M). > > Sometimes when accessing a nfs-share there is a pagefault: > > ####################################################### > Fatal trap 12: page fault while in kernel mode > cpuid = 7; apic id = 07 > fault virtual address = 0xfffffe07cfe60400 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff80d4d4b6 > stack pointer = 0x28:0xfffffe086088b380 > frame pointer = 0x28:0xfffffe086088b3f0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 43868 (mplayer) > > > #0 0xffffffff80926d29 in shutdown_nice (howto=1) at > /usr/src/sys/kern/kern_shutdown.c:207 > #1 0xffffffff80926a2d in kern_reboot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:444 > #2 0xffffffff80926f80 in panic (fmt=0x104
) at > /usr/src/sys/kern/kern_shutdown.c:698 > #3 0xffffffff8035f147 in panic_cmd_del (arg=0x0) at > /usr/src/sys/ddb/db_command.c:244 > #4 0xffffffff8035ed5d in db_command (cmd_table=0x0) at > /usr/src/sys/ddb/db_command.c:439 > #5 0xffffffff8035ead4 in db_command_loop () at > /usr/src/sys/ddb/db_command.c:488 #6 0xffffffff803615e0 in db_trap > (type=, code=0) at /usr/src/sys/ddb/db_main.c:247 > #7 0xffffffff80966db1 in kdb_trap (type=12, code=0, tf=0xfffffe086088b2d0) > at /usr/src/sys/kern/subr_kdb.c:626 > #8 0xffffffff80d4f92c in trap_fatal (frame=0xfffffe086088b2d0, eva= optimized out>) at /usr/src/sys/amd64/amd64/trap.c:835 > #9 0xffffffff80d4fcbc in trap_pfault (frame=0xfffffe086088b2d0, usermode=0) > at atomic.h:161 > #10 0xffffffff80d4f2de in trap (frame=0xfffffe086088b2d0) at > /usr/src/sys/amd64/amd64/trap.c:594 > #11 0xffffffff80d33822 in Xtss () at > /usr/src/sys/amd64/amd64/exception.S:154 #12 0xffffffff80d4d4b6 in > stack_save_td (st=, td=) at > /usr/src/sys/amd64/amd64/stack_machdep.c:74 > #13 0xffffffff809f30b2 in foffset_unlock (fp=, > val=, flags=) at > /usr/src/sys/kern/vfs_vnops.c:700 > #14 0xffffffff8082faad in ncl_bioread (vp=0xfffff80201dd7490, > uio=0xfffffe086088b7d8, ioflag=, > cred=0xfffff8015816a600) at > /usr/src/sys/fs/nfsclient/nfs_clbio.c:511 > #15 0xffffffff80e64381 in VOP_MARKATIME_APV (vop=, > a=0xfffffe086088b650) at vnode_if.c:856 > #16 0xffffffff809f4dd5 in vn_read (fp=0xfffff80272490cd0, > uio=0xfffffe086088b7d8, active_cred=0xfffff8015816a600, flags=128, > td=0xfffff80000000000) at vnode_if.h:859 #17 0xffffffff809f5502 in > get_advice (fp=0xfffffe086088b730, uio=0x400) at > /usr/src/sys/kern/vfs_vnops.c:729 > #18 0xffffffff809f2b80 in vn_io_fault1 () at > /usr/src/sys/kern/vfs_vnops.c:1058 #19 0xffffffff809f0d3b in vn_io_fault > (fp=0xfffff80272490cd0, uio=0xfffffe086088b970, active_cred=0x400, > flags=128, td=0xfffff80000000000) at > /usr/src/sys/kern/vfs_vnops.c:128 > #20 0xffffffff80981d95 in freebsd6_pread (td=0xfffff802d93204a8, > uap=0xfffff9fb094c00a8) at /usr/src/sys/kern/sys_generic.c:217 > #21 0xffffffff80981ab8 in sys_cap_fcntls_get (td=, > uap=0x800) at /usr/src/sys/kern/sys_capability.c:576 > #22 0xffffffff80981a43 in sys_cap_fcntls_get (td=, > uap=0x0) at sx.h:183 > #23 0xffffffff80d503cb in amd64_syscall (td=0x45e400, traced=0) at > subr_syscall.c:87 > #24 0xffffffff80d33b0b in Xprot () at > /usr/src/sys/amd64/amd64/exception.S:324 #25 0x0000000806a7fe6a in ?? () > ################################################## The functions in this stack trace don't make sense. It is as if you are running kgdb against the wrong kernel. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Sat Oct 18 12:43:15 2014 Return-Path: Delivered-To: freebsd-current@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 7DA16659; Sat, 18 Oct 2014 12:43:15 +0000 (UTC) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::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 DBC73B10; Sat, 18 Oct 2014 12:43:14 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id b13so2535369wgh.12 for ; Sat, 18 Oct 2014 05:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=0lewuKq1ZfXrjEMbcUTqWu/M7xO2ZT0sgk4sZHf/n4o=; b=1A4IBRuEXRjX6Stm8LTwci5ACk/hVq48mRkE5RNKAtaRooUb3jfBCW2pVPwRJlPSOc 38nFjkBuzeP/N2T4ZS3FZEb8wxvA/LJJFlYgfcyIhlOKCiD2FAdrVfCf1dERW/1QsO4X FZ9AlHqhc0MAnObQIULdPM2U1cZeCDnzJRH70Y0f5c2HkTrS9BfSmIZn0969gcyO7oO9 OxhkW6/FoRu4RUd/N5hMEjQoL4Bbh3egcZoPzlQhVEWWxzWn0lO0bfMMSoAF9l5aqJSW xHNnwB+sMQYJVfR7uWFPk2bgtEbpOT0v3GDL/fY9mBT64X/9GYmOTuFE5UU91t+QzFiN ryhg== MIME-Version: 1.0 X-Received: by 10.180.39.106 with SMTP id o10mr5977232wik.54.1413636193005; Sat, 18 Oct 2014 05:43:13 -0700 (PDT) Received: by 10.216.159.193 with HTTP; Sat, 18 Oct 2014 05:43:12 -0700 (PDT) Received: by 10.216.159.193 with HTTP; Sat, 18 Oct 2014 05:43:12 -0700 (PDT) Reply-To: araujo@FreeBSD.org In-Reply-To: <1995323.F02irpmLMA@ralph.baldwin.cx> References: <3430961.Iq02vNgBU7@noxon.firefly> <1995323.F02irpmLMA@ralph.baldwin.cx> Date: Sat, 18 Oct 2014 20:43:12 +0800 Message-ID: Subject: Re: kernel page fault with nfs From: Marcelo Araujo To: John Baldwin Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current , "Tobias C. Berner" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 12:43:15 -0000 When you rebuild your system, did you rebuild and install all kernel and world? Best Regards, On Oct 18, 2014 7:57 PM, "John Baldwin" wrote: > On Friday, October 17, 2014 11:11:26 PM Tobias C. Berner wrote: > > Hi > > > > > > For some days now I've had problems with my current (last test with > > r273178M). > > > > Sometimes when accessing a nfs-share there is a pagefault: > > > > ####################################################### > > Fatal trap 12: page fault while in kernel mode > > cpuid = 7; apic id = 07 > > fault virtual address = 0xfffffe07cfe60400 > > fault code = supervisor read data, page not present > > instruction pointer = 0x20:0xffffffff80d4d4b6 > > stack pointer = 0x28:0xfffffe086088b380 > > frame pointer = 0x28:0xfffffe086088b3f0 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 43868 (mplayer) > > > > > > #0 0xffffffff80926d29 in shutdown_nice (howto=1) at > > /usr/src/sys/kern/kern_shutdown.c:207 > > #1 0xffffffff80926a2d in kern_reboot (howto=260) at > > /usr/src/sys/kern/kern_shutdown.c:444 > > #2 0xffffffff80926f80 in panic (fmt=0x104
bounds>) at > > /usr/src/sys/kern/kern_shutdown.c:698 > > #3 0xffffffff8035f147 in panic_cmd_del (arg=0x0) at > > /usr/src/sys/ddb/db_command.c:244 > > #4 0xffffffff8035ed5d in db_command (cmd_table=0x0) at > > /usr/src/sys/ddb/db_command.c:439 > > #5 0xffffffff8035ead4 in db_command_loop () at > > /usr/src/sys/ddb/db_command.c:488 #6 0xffffffff803615e0 in db_trap > > (type=, code=0) at /usr/src/sys/ddb/db_main.c:247 > > #7 0xffffffff80966db1 in kdb_trap (type=12, code=0, > tf=0xfffffe086088b2d0) > > at /usr/src/sys/kern/subr_kdb.c:626 > > #8 0xffffffff80d4f92c in trap_fatal (frame=0xfffffe086088b2d0, > eva= > optimized out>) at /usr/src/sys/amd64/amd64/trap.c:835 > > #9 0xffffffff80d4fcbc in trap_pfault (frame=0xfffffe086088b2d0, > usermode=0) > > at atomic.h:161 > > #10 0xffffffff80d4f2de in trap (frame=0xfffffe086088b2d0) at > > /usr/src/sys/amd64/amd64/trap.c:594 > > #11 0xffffffff80d33822 in Xtss () at > > /usr/src/sys/amd64/amd64/exception.S:154 #12 0xffffffff80d4d4b6 in > > stack_save_td (st=, td=) at > > /usr/src/sys/amd64/amd64/stack_machdep.c:74 > > #13 0xffffffff809f30b2 in foffset_unlock (fp=, > > val=, flags=) at > > /usr/src/sys/kern/vfs_vnops.c:700 > > #14 0xffffffff8082faad in ncl_bioread (vp=0xfffff80201dd7490, > > uio=0xfffffe086088b7d8, ioflag=, > > cred=0xfffff8015816a600) at > > /usr/src/sys/fs/nfsclient/nfs_clbio.c:511 > > #15 0xffffffff80e64381 in VOP_MARKATIME_APV (vop=, > > a=0xfffffe086088b650) at vnode_if.c:856 > > #16 0xffffffff809f4dd5 in vn_read (fp=0xfffff80272490cd0, > > uio=0xfffffe086088b7d8, active_cred=0xfffff8015816a600, flags=128, > > td=0xfffff80000000000) at vnode_if.h:859 #17 0xffffffff809f5502 in > > get_advice (fp=0xfffffe086088b730, uio=0x400) at > > /usr/src/sys/kern/vfs_vnops.c:729 > > #18 0xffffffff809f2b80 in vn_io_fault1 () at > > /usr/src/sys/kern/vfs_vnops.c:1058 #19 0xffffffff809f0d3b in vn_io_fault > > (fp=0xfffff80272490cd0, uio=0xfffffe086088b970, active_cred=0x400, > > flags=128, td=0xfffff80000000000) at > > /usr/src/sys/kern/vfs_vnops.c:128 > > #20 0xffffffff80981d95 in freebsd6_pread (td=0xfffff802d93204a8, > > uap=0xfffff9fb094c00a8) at /usr/src/sys/kern/sys_generic.c:217 > > #21 0xffffffff80981ab8 in sys_cap_fcntls_get (td=, > > uap=0x800) at /usr/src/sys/kern/sys_capability.c:576 > > #22 0xffffffff80981a43 in sys_cap_fcntls_get (td=, > > uap=0x0) at sx.h:183 > > #23 0xffffffff80d503cb in amd64_syscall (td=0x45e400, traced=0) at > > subr_syscall.c:87 > > #24 0xffffffff80d33b0b in Xprot () at > > /usr/src/sys/amd64/amd64/exception.S:324 #25 0x0000000806a7fe6a in ?? () > > ################################################## > > The functions in this stack trace don't make sense. It is as if you are > running kgdb against the wrong kernel. > > -- > John Baldwin > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sat Oct 18 17:21:03 2014 Return-Path: Delivered-To: freebsd-current@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 BB97DB3B for ; Sat, 18 Oct 2014 17:21:03 +0000 (UTC) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::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 8500F69C for ; Sat, 18 Oct 2014 17:21:03 +0000 (UTC) Received: by mail-oi0-f52.google.com with SMTP id a3so1965930oib.11 for ; Sat, 18 Oct 2014 10:21:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LvXAq4wzwT1NlTCJXqwK/Tvyh7t6VruaBRhKFTHF7hY=; b=bs0jF8HhfRd0SWefbOiSJqLDoTR4vENwaryc+lxCODyrUE4PEOo79sZH63yWQ9RJMM BjoM0k1JTKSPIDoLqDkraKVCJNV1g+EsNBHr8KUqDRczZWETBGlwwNU06VXzGurWFAss gtHbwbbD8MA5ioZjgKOSLvJmlZGo1y2WHiJ/7fym2U8UhtKe9SAtRKRdE3mfQbv9Guxo ZyTrujKrUXlFgU5QY//NI/oBFodnGhhNxZtt8gsPTKNqWvRbuxOBj9V58zQLxmLYXdK9 3Z2Fny4j/PnQHbw06fqkIS5SA9EtxiElMgaZg5jpKut6n2hKjduFOB0FgRDjQePj1glG Hfmw== MIME-Version: 1.0 X-Received: by 10.182.73.196 with SMTP id n4mr2417280obv.51.1413652862731; Sat, 18 Oct 2014 10:21:02 -0700 (PDT) Received: by 10.202.104.195 with HTTP; Sat, 18 Oct 2014 10:21:02 -0700 (PDT) Received: by 10.202.104.195 with HTTP; Sat, 18 Oct 2014 10:21:02 -0700 (PDT) In-Reply-To: <544246E8.1090001@ijs.si> References: <5441E834.2000906@freebsd.org> <544246E8.1090001@ijs.si> Date: Sat, 18 Oct 2014 10:21:02 -0700 Message-ID: Subject: Re: ssh None cipher From: Freddie Cash To: Mark Martinec Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD-Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 17:21:03 -0000 On Oct 18, 2014 3:54 AM, "Mark Martinec" wrote: > > If the purpose of having a none cipher is to have a fast > file transfer, then one should be using sysutils/bbcp > for that purposes. Uses ssd for authentication, and > opens unencrypted channel(s) for the actual data transfer. > It's also very fast, can use multiple TCP streams. That's an interesting alternative to rsync, scp, and ftp, but doesn't help with zfs send/recv which is where the none cipher really shines. Without the none cipher, SSH becomes the bottleneck limiting transfers to around 400 Mbps on a gigabit LAN. With the none cipher, the network becomes the bottleneck limiting transfers to around 920 Mbps on the same gigabit LAN. This is between two 8-core AMD Opteron 6200 systems using igb(4) NICs. From owner-freebsd-current@FreeBSD.ORG Sat Oct 18 19:32:02 2014 Return-Path: Delivered-To: freebsd-current@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 26D80F45 for ; Sat, 18 Oct 2014 19:32:02 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id F2963218 for ; Sat, 18 Oct 2014 19:32:01 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id B514161F62 for ; Sat, 18 Oct 2014 19:32:00 +0000 (UTC) Message-ID: <5442C040.4090200@freebsd.org> Date: Sat, 18 Oct 2014 15:32:16 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: ssh None cipher References: <5441E834.2000906@freebsd.org> <544246E8.1090001@ijs.si> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4SXHcoudoKe1TEJoi7s5hoRtg6hReCwDJ" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 19:32:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4SXHcoudoKe1TEJoi7s5hoRtg6hReCwDJ Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2014-10-18 13:21, Freddie Cash wrote: > On Oct 18, 2014 3:54 AM, "Mark Martinec" = > wrote: >> >> If the purpose of having a none cipher is to have a fast >> file transfer, then one should be using sysutils/bbcp >> for that purposes. Uses ssd for authentication, and >> opens unencrypted channel(s) for the actual data transfer. >> It's also very fast, can use multiple TCP streams. >=20 > That's an interesting alternative to rsync, scp, and ftp, but doesn't h= elp > with zfs send/recv which is where the none cipher really shines. >=20 > Without the none cipher, SSH becomes the bottleneck limiting transfers = to > around 400 Mbps on a gigabit LAN. With the none cipher, the network bec= omes > the bottleneck limiting transfers to around 920 Mbps on the same gigabi= t > LAN. >=20 > This is between two 8-core AMD Opteron 6200 systems using igb(4) NICs. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 Actually, looking into it, the bbcp command can support a pipe at each end instead of files, so you can actually do a zfs send | zfs receive via bbcp, and use multiple concurrent connections, to get around TCP window stuff when going transatlantic I am going to be trying it out shortly. Note: the other big improvement in newer ssh is the HPN stuff, that is switched on since 9.2 I think. --=20 Allan Jude --4SXHcoudoKe1TEJoi7s5hoRtg6hReCwDJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJUQsBEAAoJEJrBFpNRJZKfPFMQAIuIyEbPJSZhWdCr41devM4D EzJQaVrYqSe7eKJJL3pALTfP9O2EqKZ1WqQSlW4fCe/4DdU6YJBRy1WOOf60F5xQ /QeAdBWU8+b+qUs98fcWMPSVfH1eCz1tLgqLBFTOiZJ7W5/ul/wVu0tKq1bGBrvM GZNbAFHD1wRKqiMAh189nhxAYb96e5B4Hxxln8ZTcDrwYE+AY7gqvdTnffxqmLec 9Lhhk7fZnMa/j6nPZthWcxotCMArj0PYOZ9Iq9DpUgH/EytHF4ve+uwuy/jTH/UZ qziZCvjMZeZfNPGimmG2RT69KlolyWc0xJMcQn94Z7ycblvdqDQijjCLqkeVW8Ni QnyhIzIiffdrratLBJ81TAxywnNo41LHySWCgZs4SCpmzzxfsqzRffS4HQHyqcVz iLUi1y4dJ5gwqful5S3AB44N25SSrCtCkZ/CbuIpqLbCC/N1HaCpHNStSJTCs7rO 0UsWPkQFPLKij/1WCNhpvIUg/f9o0tF7Lg9Qt6Oz3fV5jHFskS43tkneW4E1P5Ie WVurBM4cIP2LqGwGFqbGWUdKFNZwb7L5rV9g4RdtM+vyOcO+9Uly/WDjYN07UqpN vvA6KCOfz9OmEqNgz9vkLGFNPH5AUUR3LogXQc+SJeuFVFqBFVe73uEDMwqTN3WH p3wgG1t3YJmJ+7EaVcQ/ =MX3a -----END PGP SIGNATURE----- --4SXHcoudoKe1TEJoi7s5hoRtg6hReCwDJ-- From owner-freebsd-current@FreeBSD.ORG Sat Oct 18 20:58:07 2014 Return-Path: Delivered-To: freebsd-current@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 EC78181B for ; Sat, 18 Oct 2014 20:58:07 +0000 (UTC) Received: from mx2.shrew.net (mx2.shrew.net [38.97.5.132]) (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 BC60BAC2 for ; Sat, 18 Oct 2014 20:58:07 +0000 (UTC) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx2.shrew.net (8.14.7/8.14.7) with ESMTP id s9IKv6NX060364 for ; Sat, 18 Oct 2014 15:57:06 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.22.200.30] (cpe-72-177-96-36.austin.res.rr.com [72.177.96.36]) by mail.shrew.net (Postfix) with ESMTPSA id 87FFF18A7D7 for ; Sat, 18 Oct 2014 15:56:55 -0500 (CDT) Message-ID: <5442D459.3030108@shrew.net> Date: Sat, 18 Oct 2014 15:58:01 -0500 From: Matthew Grooms User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Resizing a zpool as a VMware ESXi guest ... References: <543841B8.4070007@shrew.net> <20141016081016.GA4670@brick.home> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx2.shrew.net [10.24.10.11]); Sat, 18 Oct 2014 15:57:06 -0500 (CDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 20:58:08 -0000 On 10/16/2014 3:17 AM, Garrett Cooper wrote: > >> On Oct 16, 2014, at 1:10, Edward Tomasz NapieraƂa >> wrote: > >> "camcontrol rescan" does not force fetching the updated disk size. >> AFAIK there is no way to do that. However, this should happen >> automatically, if the "other side" properly sends proper Unit >> Attention after resizing. No idea why this doesn't happen with >> VMWare. Reboot obviously clears things up. >> >> [..] > > Is open-vm-tools installed? > > I ask because if I don't have it installed and the kernel modules > loaded, VMware doesn't notify the guest OS of disks being > added/removed. > VMware tools were not installed at the time. I'll try that, but I doubt it will make a difference for resizing. > Also, what disk controller are you using? > The ESXi 5.5 default controller for FreeBSD, LSI Logic Parallel ... mpt0@pci0:0:16:0: class=0x010000 card=0x197615ad chip=0x00301000 rev=0x01 hdr=0x00 vendor = 'LSI Logic / Symbios Logic' device = '53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI' class = mass storage subclass = SCSI I'll try it with the LSI Logic SAS controller as well to see if that makes a difference. -Matthew From owner-freebsd-current@FreeBSD.ORG Sat Oct 18 22:11:04 2014 Return-Path: Delivered-To: freebsd-current@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 E4F95415; Sat, 18 Oct 2014 22:11:04 +0000 (UTC) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::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 B1FFA12A; Sat, 18 Oct 2014 22:11:04 +0000 (UTC) Received: by mail-pd0-f172.google.com with SMTP id ft15so2741587pdb.3 for ; Sat, 18 Oct 2014 15:11:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:cc:to:mime-version; bh=rH1igzWpluLVyU2BM82QjkkLFctoo5Q64rtff/mOjVo=; b=R5Jm3bo5c/oRLj92yEr+lphei6wEou505sBCpUSem3KZU3ilMHebHt/6/ZfpJwzcZ8 ZA10eeR7tAqnT5xcPmoUV+lt4AMScufFX2IDUG4jMPkN8dzJTElycea9aiXj5Wl3cSMW mW6n7SBDPvv87D/lUot2K4med8I9uWSfh3UUjT9/ibMTNOf9q/XfF87nykwisI9YtmVm KrGRTMAgqsTibVzt3jH3cPFqt9LrLjmMiZJ3vyDWPBUL+QTkB4qaorYJhL90C9DY63G0 XioHd5/oQ5DwSp/w4xWnXli8E5OwsBvKj3JKX0t1eit2Gk4qP4ek4B3N2cjkMiCshKZf MYJw== X-Received: by 10.68.68.173 with SMTP id x13mr17459737pbt.57.1413670264228; Sat, 18 Oct 2014 15:11:04 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:b45b:8d6f:7b1c:aff5? ([2601:8:ab80:7d6:b45b:8d6f:7b1c:aff5]) by mx.google.com with ESMTPSA id b3sm5002190pdm.65.2014.10.18.15.11.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 18 Oct 2014 15:11:03 -0700 (PDT) From: Garrett Cooper Content-Type: multipart/signed; boundary="Apple-Mail=_259B0AD2-DA98-4C04-889F-26A1ADFE9BE3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: panic: worklist_remove: 0xca327d00 allocdirect(0x20005) not on list Date: Sat, 18 Oct 2014 15:11:02 -0700 Message-Id: <83240205-6667-487B-9451-568C9D9B934F@gmail.com> To: freebsd-current Current Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Cc: Alexander Motin X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 22:11:05 -0000 --Apple-Mail=_259B0AD2-DA98-4C04-889F-26A1ADFE9BE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I ran into this panic when doing a crypto intensive workload = while running a buildworld in the background. I haven=E2=80=99t seen = this panic before. My world and kernel were build recently (in the past 3 days). Thanks! -Garrett # kgdb /boot/kernel/kernel vmcore.0=20 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you = are welcome to change it and/or distribute copies of it under certain = conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for = details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: panic: worklist_remove: 0xca327d00 allocdirect(0x20005) not on list cpuid =3D 2 KDB: enter: panic Reading symbols from = /usr/local/lib/vmware-tools/modules/drivers/vmmemctl.ko...done. Loaded symbols for = /usr/local/lib/vmware-tools/modules/drivers/vmmemctl.ko Reading symbols from = /usr/local/lib/vmware-tools/modules/drivers/vmxnet.ko...done. Loaded symbols for /usr/local/lib/vmware-tools/modules/drivers/vmxnet.ko Reading symbols from = /usr/local/lib/vmware-tools/modules/drivers/vmblock.ko...done. Loaded symbols for = /usr/local/lib/vmware-tools/modules/drivers/vmblock.ko Reading symbols from = /usr/local/lib/vmware-tools/modules/drivers/vmhgfs.ko...done. Loaded symbols for /usr/local/lib/vmware-tools/modules/drivers/vmhgfs.ko Reading symbols from /boot/kernel/aio.ko.symbols...done. Loaded symbols for /boot/kernel/aio.ko.symbols Reading symbols from /boot/kernel/mqueuefs.ko.symbols...done. Loaded symbols for /boot/kernel/mqueuefs.ko.symbols Reading symbols from /boot/kernel/if_vlan.ko...done. Loaded symbols for /boot/kernel/if_vlan.ko #0 doadump (textdump=3D0) at pcpu.h:233 233 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump (textdump=3D0) at pcpu.h:233 #1 0xc04c764d in db_fncall (dummy1=3D-1063112532, dummy2=3D0, = dummy3=3D-1068053257, dummy4=3D0xe271b11c "@?q?([??0??=C6=AC0??\001") at = /usr/src/sys/ddb/db_command.c:568 #2 0xc04c732b in db_command (cmd_table=3D) at = /usr/src/sys/ddb/db_command.c:440 #3 0xc04c7070 in db_command_loop () at = /usr/src/sys/ddb/db_command.c:493 #4 0xc04c9aa0 in db_trap (type=3D, code=3D) at /usr/src/sys/ddb/db_main.c:251 #5 0xc06d5b84 in kdb_trap (type=3D, code=3D, tf=3D) at = /usr/src/sys/kern/subr_kdb.c:654 #6 0xc0930657 in trap (frame=3D) at = /usr/src/sys/i386/i386/trap.c:693 #7 0xc091883c in calltrap () at /usr/src/sys/i386/i386/exception.s:169 #8 0xc06d540d in kdb_enter (why=3D0xc099dc65 "panic", msg=3D) at cpufunc.h:71 #9 0xc0690b7f in panic (fmt=3D) at = /usr/src/sys/kern/kern_shutdown.c:739 #10 0xc0874fca in softdep_disk_write_complete (bp=3D) at /usr/src/sys/ufs/ffs/ffs_softdep.c:1036 #11 0xc073b033 in bufdone_finish (bp=3D0xe25a24f0) at buf.h:420 #12 0xc073ae40 in bufdone (bp=3D) at = /usr/src/sys/kern/vfs_bio.c:3795 #13 0xc05dda61 in g_vfs_done (bip=3D) at = /usr/src/sys/geom/geom_vfs.c:157 #14 0xc05d82ff in g_io_deliver (bp=3D0xc6f6eab0, error=3D) at /usr/src/sys/geom/geom_io.c:669 #15 0xc05dc03e in g_std_done (bp=3D) at = /usr/src/sys/geom/geom_subr.c:1026 #16 0xc05d82ff in g_io_deliver (bp=3D0xc7096be0, error=3D) at /usr/src/sys/geom/geom_io.c:669 #17 0xc05d51a0 in g_disk_done_single (bp=3D0xc7096be0) at = /usr/src/sys/geom/geom_disk.c:254 #18 0xc048ea6d in dadone (periph=3D, = done_ccb=3D) at = /usr/src/sys/cam/scsi/scsi_da.c:3021 #19 0xc0466ee4 in xpt_done_process (ccb_h=3D0xcd2b9000) at = /usr/src/sys/cam/cam_xpt.c:5248 #20 0xc046bbf4 in xpt_done_td (arg=3D0xc0a1d480) at = /usr/src/sys/cam/cam_xpt.c:5275 #21 0xc06502e3 in fork_exit (callout=3D0xc046ba00 ) at = /usr/src/sys/kern/kern_fork.c:977 #22 0xc09188e4 in fork_trampoline () at = /usr/src/sys/i386/i386/exception.s:278 Current language: auto; currently minimal --Apple-Mail=_259B0AD2-DA98-4C04-889F-26A1ADFE9BE3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUQuV2AAoJEMZr5QU6S73ezz4IAKHFMlAfKgDsTDrekRtnVaSR 1zVPtv2/ATUJLkQxHySqgIQyqSWoF8FVKwoTNv3p4jctiJUyUQkdQYce3I/7oa/P hovNSU35wct1oNw4iMbEBJNzJK7g9kUE4XIBAWZFi17ed8KjrNMDQEAe177naw7J xKyPOmPokop+be/g4TQJs4X0pdb7uOPjv1gNw6aKmnl1xyG4C4X6bb1UxNE7akhO ipSiIMqhrUjl6W9t3wNiZmwLfbJQYAk3XrGUhL+ZfquD5DLPmk/GQodohK2NLuuz DT6LLxG/2U2/I1+IPw8y11vpJljfC3unz4uPML65INJM1XoNE5li9pif6s2mgjA= =f9A5 -----END PGP SIGNATURE----- --Apple-Mail=_259B0AD2-DA98-4C04-889F-26A1ADFE9BE3-- From owner-freebsd-current@FreeBSD.ORG Sat Oct 18 22:48:31 2014 Return-Path: Delivered-To: freebsd-current@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 B3A50F0A; Sat, 18 Oct 2014 22:48:31 +0000 (UTC) Received: from zhhdzmsp-smta18.bluewin.ch (zhhdzmsp-smta18.bluewin.ch [195.186.227.133]) by mx1.freebsd.org (Postfix) with ESMTP id B09D75E9; Sat, 18 Oct 2014 22:48:30 +0000 (UTC) Received: from [195.186.99.131] ([195.186.99.131:50213] helo=zhbdzmsp-smta13.bluewin.ch) by zhhdzmsp-smta18.bluewin.ch (envelope-from ) (ecelerity 3.5.7.40067 r(Platform:3.5.7.0)) with ESMTP id 70/24-02067-63EE2445; Sat, 18 Oct 2014 22:48:22 +0000 Received: from noxon.firefly (176.127.15.207) by zhbdzmsp-smta13.bluewin.ch (8.5.142) (authenticated as tobias.berner) id 51DDDBBD20C360B7; Sat, 18 Oct 2014 22:48:21 +0000 From: "Tobias C. Berner" To: araujo@freebsd.org Subject: Re: kernel page fault with nfs Date: Sun, 19 Oct 2014 00:48:21 +0200 Message-ID: <10171630.Vr2tvlANVU@noxon.firefly> User-Agent: KMail/4.14.2 (FreeBSD/11.0-CURRENT; KDE/4.14.2; amd64; ; ) In-Reply-To: References: <3430961.Iq02vNgBU7@noxon.firefly> <1995323.F02irpmLMA@ralph.baldwin.cx> MIME-Version: 1.0 X-Mailman-Approved-At: Sat, 18 Oct 2014 23:39:32 +0000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 22:48:31 -0000 Hi World ist from october 16, installed world and kernel then. Kernel was later rebuilt with debug-options. Is the following more sensible? ################################################## # kgdb NOXON/kernel.debug vmcore.1 Fatal trap 12: page fault while in kernel mode cpuid = 5; apic id = 05 fault virtual address = 0xfffffe07d1744000 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff80d4d58a stack pointer = 0x28:0xfffffe086057f240 frame pointer = 0x28:0xfffffe086057f2f0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 6524 (python2.7) (kgdb) bt #0 doadump (textdump=1) at pcpu.h:219 #1 0xffffffff80926b6d in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0xffffffff809270c0 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:746 #3 0xffffffff8035f167 in db_panic (addr=, have_addr=2, count=0, modif=0x0) at /usr/src/sys/ddb/db_command.c:473 #4 0xffffffff8035ed7d in db_command (cmd_table=0x0) at /usr/src/sys/ddb/db_command.c:440 #5 0xffffffff8035eaf4 in db_command_loop () at /usr/src/sys/ddb/db_command.c:493 #6 0xffffffff80361600 in db_trap (type=, code=0) at /usr/src/sys/ddb/db_main.c:251 #7 0xffffffff80966f01 in kdb_trap (type=12, code=0, tf=) at /usr/src/sys/kern/subr_kdb.c:654 #8 0xffffffff80d4fa7c in trap_fatal (frame=0xfffffe086057f190, eva=) at /usr/src/sys/amd64/amd64/trap.c:861 #9 0xffffffff80d4fe0c in trap_pfault (frame=0xfffffe086057f190, usermode=) at /usr/src/sys/amd64/amd64/trap.c:677 #10 0xffffffff80d4f42e in trap (frame=0xfffffe086057f190) at /usr/src/sys/amd64/amd64/trap.c:426 #11 0xffffffff80d33972 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #12 0xffffffff80d4d58a in bzero () at /usr/src/sys/amd64/amd64/support.S:53 #13 0xffffffff80830463 in ncl_doio (vp=0xfffff801e7f99938, bp=0xfffffe07c5a168e8, cr=, td=, called_from_strategy=) at /usr/src/sys/fs/nfsclient/nfs_clbio.c:1648 #14 0xffffffff80831acf in ncl_write (ap=) at /usr/src/sys/fs/nfsclient/nfs_clbio.c:1124 #15 0xffffffff80e646a5 in VOP_WRITE_APV (vop=, a=) at vnode_if.c:997 #16 0xffffffff809f52f9 in vn_write (fp=0xfffff80101c62780, uio=0xfffffe086057f970, active_cred=, flags=320, td=0x0) at vnode_if.h:413 #17 0xffffffff809f5602 in vn_io_fault_doio (args=, uio=0xa00, td=0x0) at /usr/src/sys/kern/vfs_vnops.c:991 #18 0xffffffff809f2aec in vn_io_fault1 () at /usr/src/sys/kern/vfs_vnops.c:1047 #19 0xffffffff809f0e3b in vn_io_fault (fp=0xfffff80101c62780, uio=0xfffffe086057f970, active_cred=, flags=0, td=0xfffff80171d79920) at /usr/src/sys/kern/vfs_vnops.c:1152 #20 0xffffffff80982357 in dofilewrite (td=0xfffff80171d79920, fd=19, fp=0xfffff80101c62780, auio=0xfffffe086057f970, offset=, flags=0) at file.h:306 #21 0xffffffff80982088 in kern_writev (td=0xfffff80171d79920, fd=19, auio=0xfffffe086057f970) at /usr/src/sys/kern/sys_generic.c:467 #22 0xffffffff80982013 in sys_write (td=, uap=) at /usr/src/sys/kern/sys_generic.c:382 #23 0xffffffff80d5051b in amd64_syscall (td=0xfffff80171d79920, traced=0) at subr_syscall.c:133 #24 0xffffffff80d33c5b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:390 #25 0x000000080137de4a in ?? () ################################################## Thanks in advance, Tobias Berner On Saturday 18 October 2014 20.43:12 Marcelo Araujo wrote: > When you rebuild your system, did you rebuild and install all kernel and > world? > > Best Regards, > > On Oct 18, 2014 7:57 PM, "John Baldwin" wrote: > > On Friday, October 17, 2014 11:11:26 PM Tobias C. Berner wrote: > > > Hi > > > > > > > > > For some days now I've had problems with my current (last test with > > > r273178M). > > > > > > Sometimes when accessing a nfs-share there is a pagefault: > > > > > > ################################################## ##### > > > Fatal trap 12: page fault while in kernel mode > > > cpuid = 7; apic id = 07 > > > fault virtual address = 0xfffffe07cfe60400 > > > fault code = supervisor read data, page not present > > > instruction pointer = 0x20:0xffffffff80d4d4b6 > > > stack pointer = 0x28:0xfffffe086088b380 > > > frame pointer = 0x28:0xfffffe086088b3f0 > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > > > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > > > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > current process = 43868 (mplayer) > > > > > > > > > #0 0xffffffff80926d29 in shutdown_nice (howto=1) at > > > /usr/src/sys/kern/kern_shutdown.c:207 > > > #1 0xffffffff80926a2d in kern_reboot (howto=260) at > > > /usr/src/sys/kern/kern_shutdown.c:444 > > > #2 0xffffffff80926f80 in panic (fmt=0x104
> > > bounds>) at > > > > > /usr/src/sys/kern/kern_shutdown.c:698 > > > #3 0xffffffff8035f147 in panic_cmd_del (arg=0x0) at > > > /usr/src/sys/ddb/db_command.c:244 > > > #4 0xffffffff8035ed5d in db_command (cmd_table=0x0) at > > > /usr/src/sys/ddb/db_command.c:439 > > > #5 0xffffffff8035ead4 in db_command_loop () at > > > /usr/src/sys/ddb/db_command.c:488 #6 0xffffffff803615e0 in db_trap > > > (type=, code=0) at /usr/src/sys/ddb/db_main.c:247 > > > #7 0xffffffff80966db1 in kdb_trap (type=12, code=0, > > > > tf=0xfffffe086088b2d0)