From owner-freebsd-current@FreeBSD.ORG Sun Dec 30 11:38:36 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BEDC221D; Sun, 30 Dec 2012 11:38:36 +0000 (UTC) (envelope-from uqs@FreeBSD.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 38D4B8FC12; Sun, 30 Dec 2012 11:38:36 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.5/8.14.5) with ESMTP id qBUBcYIR042292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 30 Dec 2012 12:38:34 +0100 (CET) (envelope-from uqs@FreeBSD.org) Date: Sun, 30 Dec 2012 12:38:34 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: developers@FreeBSD.org, current@FreeBSD.org, hackers@FreeBSD.org Subject: Re: HEADS UP: FreeBSD git mirrors demoted to beta status, need your help Message-ID: <20121230113834.GG69724@acme.spoerlein.net> Mail-Followup-To: developers@FreeBSD.org, current@FreeBSD.org, hackers@FreeBSD.org References: <20121215132246.GH69724@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3MMMIZFJzhAsRj/+" Content-Disposition: inline In-Reply-To: <20121215132246.GH69724@acme.spoerlein.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: current@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Dec 2012 11:38:36 -0000 --3MMMIZFJzhAsRj/+ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Just a reminder that this re-roll will happen in almost two weeks. Thanks to a couple of volunteers, I now have independent confirmation that the process is deterministic and repeatable and the switch can progress as planned. Regards, Uli On Sat, 2012-12-15 at 14:22:46 +0100, Ulrich Sp=C3=B6rlein wrote: > Bad news everyone, >=20 > tl;dr The git mirror of the source repository needs to be re-rolled to > make the conversion deterministically repeatable, this will change > pretty much all git commit hashes. >=20 > The re-roll will be done January 15, 2013. >=20 > Not affected are the ports and doc repositories, nor is the svn_head > (for use with git-svn) affected. >=20 >=20 > Background >=20 > The converter (svn2git) was handing commits and objects to git's > fast-import in arbitrary order, this makes merge commits have an > arbitrary order of their parent commits and thus these merge commits > have changing commit hashes for each converter run. >=20 > This has been fixed, but requires us to move all the branches over to > this deterministic scheme, which will change all their commit hashes. > None of the contents of these commits change, so rebasing/remerging your > work into these branches is possible without running into any merge > conflicts. >=20 >=20 > We need your help >=20 > A goal of these conversions is to have them repeatable by you (yes, > you!), so the correctness of the conversion can be verified. There are > also no backups of the conversion runs, as they should be repeatable > anyway. >=20 > We need 2-3 volunteers to run these conversions themselves and verify > that the produced commit hashes match the published ones. The necessary > steps to do this are documented on the Wiki under >=20 > http://wiki.freebsd.org/GitWorkflow#History >=20 > Please send me your output of git show-ref in a private mail, thanks. >=20 > Cheers, > Uli >=20 > PS: This re-roll has nothing to do with the recent security incident. --3MMMIZFJzhAsRj/+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQEcBAEBAgAGBQJQ4Ce6AAoJEKOmmGRKr4LO78cH/RgCV96g7UAsI++NN6yKEHIA iinKYlwTiMOY981NJ79mc12YU5mffbdE8anjDK5K+MbOAqeoUl+AoG8KbafDqUEk yLL+nU3D2/iH/+FrenrGteJCOP+89NGfjuxTMi0yecoAnhQFOUt9t2PZOfvsTGFB VEG+ZynGD4b00odW7jwv8YBNbhWxI661ZIzU8GR9aUzVg4Iyk5ac7tWwXvgRQNTI TbtwHp+bh5MbTKXOsIAApcXy2liI1u1l94dxOkaSzEazeM7EBM/6d6NvLXk9PEMY uxzhc6E7z58+EY4VvzkBDTwr1jct1VISXjWIJqvohEHwN+Pf7b2SBSNAAY9F/cY= =yB0O -----END PGP SIGNATURE----- --3MMMIZFJzhAsRj/+-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 30 19:41:38 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 12A537DA for ; Sun, 30 Dec 2012 19:41:38 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id BB5EA8FC0C for ; Sun, 30 Dec 2012 19:41:37 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id qBUJfa3w003312; Sun, 30 Dec 2012 11:41:36 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id qBUJfaNd003311; Sun, 30 Dec 2012 11:41:36 -0800 (PST) (envelope-from david) Date: Sun, 30 Dec 2012 11:41:36 -0800 From: David Wolfskill To: Cy Schubert Subject: Re: Amd(8) Hangs at Boot Message-ID: <20121230194136.GK1787@albert.catwhisker.org> References: <201212291738.qBTHcgDZ006852@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uuKVzAmB+c+zQlhu" Content-Disposition: inline In-Reply-To: <201212291738.qBTHcgDZ006852@slippy.cwsent.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Dec 2012 19:41:38 -0000 --uuKVzAmB+c+zQlhu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 29, 2012 at 09:38:42AM -0800, Cy Schubert wrote: > Just udated to the latest current and amd hangs at boot. Ideas? > .... I don't see a problem @r244855. On my build machine, /usr/ports is a symlink to a "ports" working copy that resides on a ReadyNAS: freebeast(10.0-C)[2] ls -F /usr/ports /usr/ports@ freebeast(10.0-C)[3] ls -F /usr/ports/ CHANGES accessibility/ emulators/ misc/ sysutils/ COPYRIGHT arabic/ finance/ multimedia/ textproc/ GIDs archivers/ french/ net/ ukrainian/ INDEX-8 astro/ ftp/ net-im/ vietnamese/ INDEX-8.bz2 audio/ games/ net-mgmt/ www/ INDEX-9 benchmarks/ german/ net-p2p/ x11/ INDEX-9.bz2 biology/ graphics/ news/ x11-clocks/ KNOBS cad/ head/ packages/ x11-drivers/ LEGAL chinese/ hebrew/ palm/ x11-fm/ MOVED comms/ hungarian/ polish/ x11-fonts/ Makefile converters/ irc/ ports-mgmt/ x11-servers/ Mk/ databases/ japanese/ portuguese/ x11-themes/ README deskutils/ java/ print/ x11-toolkit= s/ Templates/ devel/ korean/ russian/ x11-wm/ Tools/ distfiles/ lang/ science/ UIDs dns/ mail/ security/ UPDATING editors/ math/ shells/ freebeast(10.0-C)[4] uname -a FreeBSD freebeast.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #1029 r2= 44855M/244856: Sun Dec 30 10:48:45 PST 2012 root@freebeast.catwhisker.o= rg:/usr/obj/usr/src/sys/GENERIC i386 freebeast(10.0-C)[5] ps axwwl | grep -w amd 0 764 1 0 20 0 10024 10052 select Ss - 0:00.07 /usr/sbin= /amd -p -c 1800 -k i386 -l syslog /net /etc/amd.map 1001 1878 964 0 23 0 10104 9916 - R+ 1 0:00.01 grep -w a= md freebeast(10.0-C)[6]=20 Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --uuKVzAmB+c+zQlhu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEUEARECAAYFAlDgmNYACgkQmprOCmdXAD3dbQCYrCuATqlEkOCABY5WsOfG+IiT oQCfRpGXzo/wC/v6YQN5v5v7BcoIYq8= =HYVp -----END PGP SIGNATURE----- --uuKVzAmB+c+zQlhu-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 30 20:30:53 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4DF9D3F0 for ; Sun, 30 Dec 2012 20:30:53 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id F25548FC12 for ; Sun, 30 Dec 2012 20:30:52 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1TpPWz-002Zgy-3z>; Sun, 30 Dec 2012 21:30:49 +0100 Received: from e178019190.adsl.alicedsl.de ([85.178.19.190] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1TpPWz-003CbX-00>; Sun, 30 Dec 2012 21:30:49 +0100 Message-ID: <50E0A477.3040606@zedat.fu-berlin.de> Date: Sun, 30 Dec 2012 21:30:47 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: David Wolfskill Subject: Re: Amd(8) Hangs at Boot References: <201212291738.qBTHcgDZ006852@slippy.cwsent.com> <20121230194136.GK1787@albert.catwhisker.org> In-Reply-To: <20121230194136.GK1787@albert.catwhisker.org> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAED3DD25DDCA87C3E33861BD" X-Originating-IP: 85.178.19.190 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Dec 2012 20:30:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAED3DD25DDCA87C3E33861BD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 12/30/12 20:41, schrieb David Wolfskill: > On Sat, Dec 29, 2012 at 09:38:42AM -0800, Cy Schubert wrote: >> Just udated to the latest current and amd hangs at boot. Ideas? >> .... >=20 > I don't see a problem @r244855. On my build machine, /usr/ports is a > symlink to a "ports" working copy that resides on a ReadyNAS: >=20 > freebeast(10.0-C)[2] ls -F /usr/ports > /usr/ports@ > freebeast(10.0-C)[3] ls -F /usr/ports/ > CHANGES accessibility/ emulators/ misc/ sysutil= s/ > COPYRIGHT arabic/ finance/ multimedia/ textpro= c/ > GIDs archivers/ french/ net/ ukraini= an/ > INDEX-8 astro/ ftp/ net-im/ vietnam= ese/ > INDEX-8.bz2 audio/ games/ net-mgmt/ www/ > INDEX-9 benchmarks/ german/ net-p2p/ x11/ > INDEX-9.bz2 biology/ graphics/ news/ x11-clo= cks/ > KNOBS cad/ head/ packages/ x11-dri= vers/ > LEGAL chinese/ hebrew/ palm/ x11-fm/= > MOVED comms/ hungarian/ polish/ x11-fon= ts/ > Makefile converters/ irc/ ports-mgmt/ x11-ser= vers/ > Mk/ databases/ japanese/ portuguese/ x11-the= mes/ > README deskutils/ java/ print/ x11-too= lkits/ > Templates/ devel/ korean/ russian/ x11-wm/= > Tools/ distfiles/ lang/ science/ > UIDs dns/ mail/ security/ > UPDATING editors/ math/ shells/ > freebeast(10.0-C)[4] uname -a > FreeBSD freebeast.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #102= 9 r244855M/244856: Sun Dec 30 10:48:45 PST 2012 root@freebeast.catwhi= sker.org:/usr/obj/usr/src/sys/GENERIC i386 > freebeast(10.0-C)[5] ps axwwl | grep -w amd > 0 764 1 0 20 0 10024 10052 select Ss - 0:00.07 /usr/= sbin/amd -p -c 1800 -k i386 -l syslog /net /etc/amd.map > 1001 1878 964 0 23 0 10104 9916 - R+ 1 0:00.01 grep = -w amd > freebeast(10.0-C)[6]=20 >=20 > Peace, > david >=20 I see a similar picture here and this AMD crap brought down my whole serv= er. I'm not able to install new buildworld, since I got stuck when mtree accesses / and then the amd automounter mountpoint directory /extern is reported newnfs server pid767@telesto:/extern: not responding I have no remote filesystems containing the sources for the OS, so I do not understand whats going on. This is definitely a bug in the recent system. --------------enigAED3DD25DDCA87C3E33861BD 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.19 (FreeBSD) iQEcBAEBAgAGBQJQ4KR4AAoJEOgBcD7A/5N8S3sIAJ1BlQn33pwb0Z60GgVDhbXh qTZzxlQPfNGUYGBI9Q1NEby0PluC4mJ7xr9eDvA9m+m9NuRiSc3eC8FdC19+wZW6 rADXm3hEHydsdW7ZZVe0NgsF6q96D4HXQPlJGmX7w+zBa/0fQqfJ3T1RvIkIzjVe xTsdVBcbogwJwkd9czWbqLhHU5ogybkJfVrLK3neO57RP18pXcVpSk230zvechWo e7Iwtcsez64cuG1wXfW6l0ZhxqvDio0oh8xtZslKdwGkHVqZGc9iKIrly+uuSbHe qEDh+MiCPmxf9NiR5Fq5xsofuS/ZSLY3V0n1gBKCjPw40DaVfaZdMN+cZlP62GY= =szGS -----END PGP SIGNATURE----- --------------enigAED3DD25DDCA87C3E33861BD-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 30 22:17:17 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B0D20C3C; Sun, 30 Dec 2012 22:17:17 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6CE4D8FC08; Sun, 30 Dec 2012 22:17:17 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:5d75:c766:7646:e7f3] (unknown [IPv6:2001:7b8:3a7:0:5d75:c766:7646:e7f3]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id EF0755C5A; Sun, 30 Dec 2012 23:17:15 +0100 (CET) Message-ID: <50E0BD66.4070609@FreeBSD.org> Date: Sun, 30 Dec 2012 23:17:10 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: Nathan Whitehorn Subject: Re: clang 3.2 RC2 miscompiles libgcc? References: <20121227150724.GA1431@mole.fafoe.narf.at> <50DC65F5.6060004@freebsd.org> In-Reply-To: <50DC65F5.6060004@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Dec 2012 22:17:17 -0000 On 2012-12-27 16:15, Nathan Whitehorn wrote: > On 12/27/12 09:07, Stefan Farfeleder wrote: >> I noticed that most of my C++ applications in recent versions of FreeBSD >> head suddenly crash without me recompiling them. I tracked it down to >> r243830 which imported a new clang version. The new clang seems to >> compile libgcc in a wrong or at least incompatible way with what gcc >> expects. In fact, the breakage only occurs with libgcc compiled by a >> post-r243830 clang and an application compiled with g++ -O2. For me, the >> crash happens with boost::program_options, but I'm not sure if that is >> necessary for the crash. > > I've seen what I think is the same thing due to a miscompilation of > unwind-dw2.c that caused crashes related to cross-shared-object > exception handling. It seems to have been fixed with the 3.2 release but > I haven't tested it too thoroughly yet. I have been playing with Stefan's testcase for a while now, and while I can reproduce the crashes, I am still at a loss about the cause. It does seem to have something to do with throwing exceptions, but I am still not sure whether I am looking at a bug in boost, gcc, clang, or libgcc... Do you happen to have a smaller testcase, by any chance? From owner-freebsd-current@FreeBSD.ORG Sun Dec 30 23:02:11 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6B1B9522 for ; Sun, 30 Dec 2012 23:02:11 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 22CF88FC0A for ; Sun, 30 Dec 2012 23:02:10 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAD/G4FCDaFvO/2dsb2JhbABFhjq3OnOCSIELAg0ZAokFlymOUZBYgSKLQIEPghaBEwOIYo0qiU2Ge4MSgVM1 X-IronPort-AV: E=Sophos;i="4.84,382,1355115600"; d="scan'208";a="6929956" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 30 Dec 2012 18:02:03 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id A48ADB3F1C for ; Sun, 30 Dec 2012 18:02:03 -0500 (EST) Date: Sun, 30 Dec 2012 18:02:03 -0500 (EST) From: Rick Macklem To: freebsd-current@freebsd.org Message-ID: <1466136079.1602238.1356908523623.JavaMail.root@erie.cs.uoguelph.ca> Subject: r244604 breaks build WITHOUT_KERBEROS + WITH_GSSAPI for gssd.c MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Dec 2012 23:02:11 -0000 Hi, Maybe someone familiar with the build environment can help with this. Someone reported via email that gssd.c no longer builds for the combination of WITHOUT_KERBEROS and WITH_GSSAPI. Now, the gssd is completely useless without kerberos, but I need a way to fix the build for this case? Can it just be set to not build the gssd daemon when WITHOUT_KERBEROS is specified? Alternately, if WITHOUT_KERBEROS is defined for the compile, I can #ifdef the code so that it builds, although the resultant binary is useless. Thanks in advance for any help with this, rick From owner-freebsd-current@FreeBSD.ORG Sun Dec 30 23:13:58 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2FD5D9D9; Sun, 30 Dec 2012 23:13:58 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 3C1C58FC0A; Sun, 30 Dec 2012 23:13:57 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBUNDuIG079079; Sun, 30 Dec 2012 16:13:56 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBUNDhtn084905; Sun, 30 Dec 2012 16:13:43 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: [RFC/RFT] calloutng From: Ian Lepore To: Alexander Motin In-Reply-To: <50DB4EFE.2020600@FreeBSD.org> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> Content-Type: multipart/mixed; boundary="=-0QeMdI0U6ePkF5/otAWO" Date: Sun, 30 Dec 2012 16:13:43 -0700 Message-ID: <1356909223.54953.74.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: Davide Italiano , freebsd-arch@freebsd.org, FreeBSD Current , Marius Strobl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Dec 2012 23:13:58 -0000 --=-0QeMdI0U6ePkF5/otAWO Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Wed, 2012-12-26 at 21:24 +0200, Alexander Motin wrote: > On 26.12.2012 01:21, Marius Strobl wrote: > > On Tue, Dec 18, 2012 at 11:03:47AM +0200, Alexander Motin wrote: > >> Experiments with dummynet shown ineffective support for very short > >> tick-based callouts. New version fixes that, allowing to get as many > >> tick-based callout events as hz value permits, while still be able to > >> aggregate events and generating minimum of interrupts. > >> > >> Also this version modifies system load average calculation to fix some > >> cases existing in HEAD and 9 branches, that could be fixed with new > >> direct callout functionality. > >> > >> http://people.freebsd.org/~mav/calloutng_12_17.patch > >> > >> With several important changes made last time I am going to delay commit > >> to HEAD for another week to do more testing. Comments and new test cases > >> are welcome. Thanks for staying tuned and commenting. > > > > FYI, I gave both calloutng_12_15_1.patch and calloutng_12_17.patch a > > try on sparc64 and it at least survives a buildworld there. However, > > with the patched kernels, buildworld times seem to increase slightly but > > reproducible by 1-2% (I only did four runs but typically buildworld > > times are rather stable and don't vary more than a minute for the > > same kernel and source here). Is this an expected trade-off (system > > time as such doesn't seem to increase)? > > I don't think build process uses significant number of callouts to > affect results directly. I think this additional time could be result of > the deeper next event look up, done by the new code, that is practically > useless for sparc64, which effectively has no cpu_idle() routine. It > wouldn't affect system time and wouldn't show up in any statistics > (except PMC or something alike) because it is executed inside timer > hardware interrupt handler. If my guess is right, that is a part that > probably still could be optimized. I'll look on it. Thanks. > > > Is there anything specific to test? > > Since the most of code is MI, for sparc64 I would mostly look on related > MD parts (eventtimers and timecounters) to make sure they are working > reliably in more stressful conditions. I still have some worries about > possible deadlock on hardware where IPIs are used to fetch present time > from other CPU. > > Here is small tool we are using for test correctness and performance of > different user-level APIs: http://people.freebsd.org/~mav/testsleep.c > I grabbed testsleep.c to test an arm event timer implementation, and had to fix a couple nits... kqueueto was missing from the names[] array, and I had to add a "* 1000" to a couple places where usec was stuffed into a timespec's tv_nsec. I also tested the calloutng_12_17 patches and the kqueue stuff behaved very strangely. Then I noticed you had a 12_26 patchset so I tested that (after crudely fixing a couple uninitialized var warnings), and it all looks good on this arm (Raspberry Pi). I'll attach the results. It's so sweet to be able to do precision sleeps. -- Ian --=-0QeMdI0U6ePkF5/otAWO Content-Disposition: inline; filename="calloutng_test.txt" Content-Type: text/plain; name="calloutng_test.txt"; charset="us-ascii" Content-Transfer-Encoding: 7bit for t in 1 300 3000 30000 300000 ; do for m in select poll usleep nanosleep kqueue kqueueto syscall ; do ./testsleep $t $m done done With calloutng_12_26.patch... HZ=100 HZ=250 HZ=1000 ---------- ---------------- ---------------- ---------------- select 1 55.79 1 50.96 1 61.32 poll 1 1109.46 1 1107.86 1 1114.38 usleep 1 56.33 1 72.90 1 62.78 nanosleep 1 52.66 1 55.23 1 64.23 kqueue 1 1114.23 1 1113.81 1 1121.21 kqueueto 1 65.44 1 71.00 1 75.01 syscall 1 4.70 1 4.45 1 4.55 select 300 355.79 300 357.76 300 362.35 poll 300 1107.85 300 1122.55 300 1115.62 usleep 300 355.28 300 357.28 300 360.79 nanosleep 300 354.49 300 355.82 300 360.62 kqueue 300 1112.57 300 1118.13 300 1117.16 kqueueto 300 375.98 300 378.62 300 395.61 syscall 300 4.41 300 4.45 300 4.54 select 3000 3246.75 3000 3246.74 3000 3252.72 poll 3000 3238.10 3000 3229.12 3000 3250.10 usleep 3000 3242.47 3000 3237.06 3000 3249.61 nanosleep 3000 3238.79 3000 3231.55 3000 3248.11 kqueue 3000 3240.01 3000 3236.07 3000 3247.60 kqueueto 3000 3265.36 3000 3267.22 3000 3274.96 syscall 3000 4.69 3000 4.44 3000 4.50 select 30000 31714.60 30000 31941.17 30000 32467.69 poll 30000 31522.76 30000 31983.00 30000 32497.81 usleep 30000 31459.67 30000 31980.76 30000 32458.71 nanosleep 30000 31431.02 30000 31982.22 30000 32525.20 kqueue 30000 31466.75 30000 31873.90 30000 31973.54 kqueueto 30000 31564.67 30000 32522.35 30000 32475.59 syscall 30000 4.70 30000 4.73 30000 4.89 select 300000 319133.02 300000 311562.33 300000 309918.62 poll 300000 319604.27 300000 311422.94 300000 310000.76 usleep 300000 319314.60 300000 311269.69 300000 309996.34 nanosleep 300000 319497.58 300000 311425.40 300000 309997.13 kqueue 300000 309995.55 300000 303980.27 300000 309908.82 kqueueto 300000 319505.88 300000 311424.97 300000 309996.16 syscall 300000 4.41 300000 4.45 300000 4.89 With no patches... HZ=100 HZ=250 HZ=1000 ---------- ---------------- ---------------- ---------------- select 1 19941.70 1 7989.10 1 1999.16 poll 1 19904.61 1 7987.32 1 1999.78 usleep 1 19904.95 1 7993.30 1 1999.96 nanosleep 1 19905.64 1 7993.71 1 1999.72 kqueue 1 10001.61 1 4004.00 1 1000.27 kqueueto 1 19904.00 1 7993.03 1 1999.54 syscall 1 4.04 1 4.05 1 4.75 select 300 19904.66 300 7998.39 300 2000.27 poll 300 19904.35 300 7993.47 300 1999.86 usleep 300 19903.96 300 7994.11 300 1999.81 nanosleep 300 19904.48 300 7993.77 300 1999.80 kqueue 300 10001.68 300 4004.18 300 1000.31 kqueueto 300 19997.86 300 7993.37 300 1999.59 syscall 300 4.01 300 4.00 300 4.32 select 3000 19904.80 3000 7998.85 3000 3998.43 poll 3000 19904.92 3000 8005.93 3000 3999.39 usleep 3000 19904.50 3000 7992.88 3000 3999.44 nanosleep 3000 19904.84 3000 7993.34 3000 3999.36 kqueue 3000 10001.58 3000 4003.97 3000 3000.72 kqueueto 3000 19903.56 3000 7993.24 3000 3999.34 syscall 3000 4.02 3000 4.37 3000 4.29 select 30000 39905.02 30000 35991.79 30000 31051.77 poll 30000 39905.49 30000 35980.35 30000 30995.64 usleep 30000 39903.78 30000 35979.48 30000 30995.23 nanosleep 30000 39904.55 30000 35981.61 30000 30995.87 kqueue 30000 30002.73 30000 32019.54 30000 30004.83 kqueueto 30000 39903.59 30000 35979.64 30000 30996.05 syscall 30000 4.44 30000 4.04 30000 4.31 select 300000 310001.23 300000 303995.86 300000 300994.30 poll 300000 309902.73 300000 303981.58 300000 300996.17 usleep 300000 309903.64 300000 303980.17 300000 300997.42 nanosleep 300000 309903.32 300000 303980.36 300000 300993.64 kqueue 300000 300002.77 300000 300019.46 300000 300006.90 kqueueto 300000 309903.31 300000 303978.10 300000 300996.84 syscall 300000 4.01 300000 4.04 300000 4.29 --=-0QeMdI0U6ePkF5/otAWO-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 30 23:46:11 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B3F5820D for ; Sun, 30 Dec 2012 23:46:11 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU [18.7.68.34]) by mx1.freebsd.org (Postfix) with ESMTP id 492C78FC08 for ; Sun, 30 Dec 2012 23:46:10 +0000 (UTC) X-AuditID: 12074422-b7f616d000000e7c-25-50e0d23c45c6 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 14.3D.03708.C32D0E05; Sun, 30 Dec 2012 18:46:04 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id qBUNk4Bg004676; Sun, 30 Dec 2012 18:46:04 -0500 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.6/8.12.4) with ESMTP id qBUNk2jb004405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 30 Dec 2012 18:46:03 -0500 (EST) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id qBUNk1a7020362; Sun, 30 Dec 2012 18:46:01 -0500 (EST) Date: Sun, 30 Dec 2012 18:46:01 -0500 (EST) From: Benjamin Kaduk To: Rick Macklem Subject: Re: r244604 breaks build WITHOUT_KERBEROS + WITH_GSSAPI for gssd.c In-Reply-To: <1466136079.1602238.1356908523623.JavaMail.root@erie.cs.uoguelph.ca> Message-ID: References: <1466136079.1602238.1356908523623.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrWtz6UGAwandEhZz3nxgsni47BqT A5PHjE/zWTx+b97LFMAUxWWTkpqTWZZapG+XwJUxuW0Xa8FDtoo5TyYyNjCuZe1i5OCQEDCR 2PIns4uRE8gUk7hwbz1bFyMXh5DAPkaJmeuOMEE4GxgljjV/ZYRwTjBJ7N79lQXCaWCUaDh+ mwWkn0VAW2L//R4wm01ARWLmm41sILaIgLrE5tX9zCA2s4C8xP8rl5lAbGEBb4mlB26zg9ic AoESvUf3sIOcxCvgKPHosxNIWEggQGL/jkeMILaogI7E6v1TwMbzCghKnJz5hAVipKXEuT/X 2SYwCs5CkpqFJLWAkWkVo2xKbpVubmJmTnFqsm5xcmJeXmqRrqlebmaJXmpK6SZGUKCyuyjt YPx5UOkQowAHoxIPb0D9/QAh1sSy4srcQ4ySHExKorxPLjwIEOJLyk+pzEgszogvKs1JLT7E KMHBrCTCe3QeUI43JbGyKrUoHyYlzcGiJM57LeWmv5BAemJJanZqakFqEUxWhoNDSYJX6yJQ o2BRanpqRVpmTglCmomDE2Q4D9DwdpDFvMUFibnFmekQ+VOMilLivHLngRICIImM0jy4Xlgi ecUoDvSKMC8PyAoeYBKC634FNJgJaLAWA9jgkkSElFQDY3L8/mNcLfJdPW1aG3y005itS1/z NUo2rFbJT5Besr5zsnuUn2hJwN17Nvwezile5/tuNSnL7Fr/5H1QlS53TNTkj0F/1PYlHJ2Q 3X7YtMRq36eX1bvvmueLL745Wd/aIupipdPkx3K/ZOVdnzw3anY/d/3Yl7y931M/6Dal7miP KuN+y8OmxFKckWioxVxUnAgAiceaxv8CAAA= Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Dec 2012 23:46:11 -0000 On Sun, 30 Dec 2012, Rick Macklem wrote: > Hi, > > Maybe someone familiar with the build environment can help > with this. > > Someone reported via email that gssd.c no longer builds for > the combination of WITHOUT_KERBEROS and WITH_GSSAPI. > > Now, the gssd is completely useless without kerberos, but > I need a way to fix the build for this case? > > Can it just be set to not build the gssd daemon when > WITHOUT_KERBEROS is specified? > Alternately, if WITHOUT_KERBEROS is defined for the compile, > I can #ifdef the code so that it builds, although the resultant > binary is useless. With my kerberos hat on, I would expect that WITHOUT_KERBEROS and WITH_GSSAPI would build a GSS-API application that does not use the krb5 GSS mechanism, that is, your "#ifdef [...] builds, although the resultant binary is useless" case. -Ben From owner-freebsd-current@FreeBSD.ORG Sun Dec 30 23:46:45 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0DD0B31C for ; Sun, 30 Dec 2012 23:46:45 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id B1B3C8FC0A for ; Sun, 30 Dec 2012 23:46:44 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAFzR4FCDaFvO/2dsb2JhbABFFoYktzpzgh4BAQUjBFIbGAICDRkCWQYTCRGHeQylbJBYgSKLNQsQCIMNgRMDiGKNKoEcjyyDEoFTNQ X-IronPort-AV: E=Sophos;i="4.84,383,1355115600"; d="scan'208";a="7966778" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 30 Dec 2012 18:45:35 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id B238EB3F14; Sun, 30 Dec 2012 18:45:35 -0500 (EST) Date: Sun, 30 Dec 2012 18:45:35 -0500 (EST) From: Rick Macklem To: David Wolfskill Message-ID: <1400518506.1602411.1356911135683.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20121230194136.GK1787@albert.catwhisker.org> Subject: Re: Amd(8) Hangs at Boot MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Dec 2012 23:46:45 -0000 David Wolfskill wrote: > On Sat, Dec 29, 2012 at 09:38:42AM -0800, Cy Schubert wrote: > > Just udated to the latest current and amd hangs at boot. Ideas? > > .... > > I don't see a problem @r244855. On my build machine, /usr/ports is a > symlink to a "ports" working copy that resides on a ReadyNAS: > > freebeast(10.0-C)[2] ls -F /usr/ports > /usr/ports@ > freebeast(10.0-C)[3] ls -F /usr/ports/ > CHANGES accessibility/ emulators/ misc/ sysutils/ > COPYRIGHT arabic/ finance/ multimedia/ textproc/ > GIDs archivers/ french/ net/ ukrainian/ > INDEX-8 astro/ ftp/ net-im/ vietnamese/ > INDEX-8.bz2 audio/ games/ net-mgmt/ www/ > INDEX-9 benchmarks/ german/ net-p2p/ x11/ > INDEX-9.bz2 biology/ graphics/ news/ x11-clocks/ > KNOBS cad/ head/ packages/ x11-drivers/ > LEGAL chinese/ hebrew/ palm/ x11-fm/ > MOVED comms/ hungarian/ polish/ x11-fonts/ > Makefile converters/ irc/ ports-mgmt/ x11-servers/ > Mk/ databases/ japanese/ portuguese/ x11-themes/ > README deskutils/ java/ print/ x11-toolkits/ > Templates/ devel/ korean/ russian/ x11-wm/ > Tools/ distfiles/ lang/ science/ > UIDs dns/ mail/ security/ > UPDATING editors/ math/ shells/ > freebeast(10.0-C)[4] uname -a > FreeBSD freebeast.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT > #1029 r244855M/244856: Sun Dec 30 10:48:45 PST 2012 > root@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386 > freebeast(10.0-C)[5] ps axwwl | grep -w amd > 0 764 1 0 20 0 10024 10052 select Ss - 0:00.07 /usr/sbin/amd -p -c > 1800 -k i386 -l syslog /net /etc/amd.map > 1001 1878 964 0 23 0 10104 9916 - R+ 1 0:00.01 grep -w amd > freebeast(10.0-C)[6] > > Peace, > david > -- > David H. Wolfskill david@catwhisker.org > Taliban: Evil men with guns afraid of truth from a 14-year old girl. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. This message is basically for Cy and not David... Since David doesn't see the problem with r244855, I'd suggest trying a new kernel and seeing if the problem still exists. If you still see the problem, I'd be suspicious of any recent commit done to the network device driver for whatever network interface you are using. Beyond that, Kostik recently pointed me at this: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html which covers the commands you can use under DB to try and figure out why it is stuck in udp_bind(). You can also do the following to figure out what source line# it is stuck at: - go to wherever the kernel binaries are # nm kernel | grep udp_bind - add the offset to the address for udp_bind # addr2line -e kernel.symbols - type in the hex value for address + offset --> it should give you a source line# It never hurts to capture packets between the client and NFS server and see if there what network traffic is occurring. If there is any traffic, wireshark does a good job of decoding it. Finally, there was an email w.r.t. loopback being broken, posted on Dec. 27, but I haven't seen any followup email about this being fixed. (I don't know if amd uses 127.0.0.1 or not?) Good luck with it and please let us know when you have more information, rick From owner-freebsd-current@FreeBSD.ORG Mon Dec 31 00:49:30 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1BA90993 for ; Mon, 31 Dec 2012 00:49:30 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id BBA5B8FC08 for ; Mon, 31 Dec 2012 00:49:29 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EALHg4FCDaFvO/2dsb2JhbABFhjq3O3OCHgEBBSNWGxQEERkCBFWILAylZpBWjFcLgyWBEwOIYoYmhwSBHI8sgxKBUzU X-IronPort-AV: E=Sophos;i="4.84,383,1355115600"; d="scan'208";a="7976953" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 30 Dec 2012 19:49:27 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 9B828B3F0D; Sun, 30 Dec 2012 19:49:27 -0500 (EST) Date: Sun, 30 Dec 2012 19:49:27 -0500 (EST) From: Rick Macklem To: bf1783@gmail.com Message-ID: <87170730.1602744.1356914967581.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: Subject: Re: svn commit: r244604 - head/usr.sbin/gssd MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1602743_344864969.1356914967578" X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 31 Dec 2012 00:49:30 -0000 ------=_Part_1602743_344864969.1356914967578 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit bf1783 wrote: > >Author: rmacklem > >Date: Sat Dec 22 23:21:17 2012 > >New Revision: 244604 > >URL: http://svnweb.freebsd.org/changeset/base/244604 > > > >Log: > > It was reported via email that some sshds create kerberos > > credential cache files with names other than /tmp/krb5cc_. > > The gssd daemon does not know how to find these credential caches. > > This patch implements a new option "-s" that does a search for > > credential cache files, using roughly the same algorithm as the > > gssd daemon for Linux uses. The gssd behaviour is only changed > > if the new "-s" option is specified. It also implements two other > > new options related to the "-s" option. > > > > Reported by: Piete.Brooks at cl.cam.ac.uk, Herbert Poeckl > > Tested by: Herbert Poeckl (admin at ist.tugraz.at), Illias A. > > Marinos > > MFC after: 2 weeks > > ... > > >+#include > > Rick: > > This breaks world built WITHOUT_KERBEROS and WITH_GSSAPI. > > Regards, > b. Could you please test the attached patch. Also, if someone who is familiar with the build/Makefile side of things could review this, it would be appreciated. Thanks, rick ------=_Part_1602743_344864969.1356914967578 Content-Type: text/x-patch; name=gssd-build.patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=gssd-build.patch LS0tIHVzci5zYmluL2dzc2QvZ3NzZC5jLnNhdjAJMjAxMi0xMi0zMCAxOTowNDoxOS4wMDAwMDAw MDAgLTA1MDAKKysrIHVzci5zYmluL2dzc2QvZ3NzZC5jCTIwMTItMTItMzAgMTk6MzU6MDYuNjQ4 NjAzMDAwIC0wNTAwCkBAIC0zNyw3ICszNyw5IEBAIF9fRkJTRElEKCIkRnJlZUJTRDogaGVhZC91 c3Iuc2Jpbi9nc3NkL2cKICNpbmNsdWRlIDxjdHlwZS5oPgogI2luY2x1ZGUgPGRpcmVudC5oPgog I2luY2x1ZGUgPGVyci5oPgorI2lmbmRlZiBXSVRIT1VUX0tFUkJFUk9TCiAjaW5jbHVkZSA8a3Ji NS5oPgorI2VuZGlmCiAjaW5jbHVkZSA8cHdkLmg+CiAjaW5jbHVkZSA8c3RkaW8uaD4KICNpbmNs dWRlIDxzdGRsaWIuaD4KQEAgLTEwMiwxMiArMTA0LDE4IEBAIG1haW4oaW50IGFyZ2MsIGNoYXIg Kiphcmd2KQogCQkJZGVidWdfbGV2ZWwrKzsKIAkJCWJyZWFrOwogCQljYXNlICdzJzoKKyNpZm5k ZWYgV0lUSE9VVF9LRVJCRVJPUwogCQkJLyoKIAkJCSAqIFNldCB0aGUgZGlyZWN0b3J5IHNlYXJj aCBsaXN0LiBUaGlzIGVuYWJsZXMgdXNlIG9mCiAJCQkgKiBmaW5kX2NjYWNoZV9maWxlKCkgdG8g c2VhcmNoIHRoZSBkaXJlY3RvcmllcyBmb3IgYQogCQkJICogc3VpdGFibGUgY3JlZGVudGlhbHMg Y2FjaGUgZmlsZS4KIAkJCSAqLwogCQkJc3RybGNweShjY2ZpbGVfZGlybGlzdCwgb3B0YXJnLCBz aXplb2YoY2NmaWxlX2Rpcmxpc3QpKTsKKyNlbHNlCisJCQlmcHJpbnRmKHN0ZGVyciwgIlRoaXMg b3B0aW9uIG5vdCBhdmFpbGFibGUgd2hlbiBidWlsdCIKKwkJCSAgICAiIHdpdGhvdXQgTUtfS0VS QkVST1NcbiIpOworCQkJZXhpdCgxKTsKKyNlbmRpZgogCQkJYnJlYWs7CiAJCWNhc2UgJ2MnOgog CQkJLyoKQEAgLTgxNCw2ICs4MjIsNyBAQCBzdGF0aWMgaW50CiBpc19hX3ZhbGlkX3RndF9jYWNo ZShjb25zdCBjaGFyICpmaWxlcGF0aCwgdWlkX3QgdWlkLCBpbnQgKnJldHJhdGluZywKICAgICB0 aW1lX3QgKnJldGV4cHRpbWUpCiB7CisjaWZuZGVmIFdJVEhPVVRfS0VSQkVST1MKIAlrcmI1X2Nv bnRleHQgY29udGV4dDsKIAlrcmI1X3ByaW5jaXBhbCBwcmluYzsKIAlrcmI1X2NjYWNoZSBjY2Fj aGU7CkBAIC05MTMsNSArOTIyLDggQEAgaXNfYV92YWxpZF90Z3RfY2FjaGUoY29uc3QgY2hhciAq ZmlsZXBhdAogCQkqcmV0ZXhwdGltZSA9IGV4cHRpbWU7CiAJfQogCXJldHVybiAocmV0KTsKKyNl bHNlIC8qIFdJVEhPVVRfS0VSQkVST1MgKi8KKwlyZXR1cm4gKDApOworI2VuZGlmIC8qICFXSVRI T1VUX0tFUkJFUk9TICovCiB9CiAKLS0tIHVzci5zYmluL2dzc2QvTWFrZWZpbGUuc2F2MAkyMDEy LTEyLTMwIDE5OjE4OjAwLjAwMDAwMDAwMCAtMDUwMAorKysgdXNyLnNiaW4vZ3NzZC9NYWtlZmls ZQkyMDEyLTEyLTMwIDE5OjM1OjAyLjAwMDAwMDAwMCAtMDUwMApAQCAtMSw1ICsxLDcgQEAKICMg JEZyZWVCU0Q6IGhlYWQvdXNyLnNiaW4vZ3NzZC9NYWtlZmlsZSAyNDQ2MzggMjAxMi0xMi0yMyAy MDoxMjo1N1ogcm1hY2tsZW0gJAogCisuaW5jbHVkZSA8YnNkLm93bi5taz4KKwogUFJPRz0JZ3Nz ZAogTUFOPQlnc3NkLjgKIFNSQ1M9CWdzc2QuYyBnc3NkLmggZ3NzZF9zdmMuYyBnc3NkX3hkci5j IGdzc2RfcHJvdC5jCkBAIC03LDggKzksMTQgQEAgU1JDUz0JZ3NzZC5jIGdzc2QuaCBnc3NkX3N2 Yy5jIGdzc2RfeGRyLgogQ0ZMQUdTKz0gLUkuCiBXQVJOUz89IDEKIAorLmlmICR7TUtfS0VSQkVS T1N9ICE9ICJubyIKIERQQUREPQkke0xJQkdTU0FQSX0gJHtMSUJLUkI1fSAke0xJQkhYNTA5fSAk e0xJQkFTTjF9ICR7TElCUk9LRU59ICR7TElCQ09NX0VSUn0gJHtMSUJDUllQVH0gJHtMSUJDUllQ VE99CiBMREFERD0JLWxnc3NhcGkgLWxrcmI1IC1saHg1MDkgLWxhc24xIC1scm9rZW4gLWxjb21f ZXJyIC1sY3J5cHQgLWxjcnlwdG8KKy5lbHNlCitDRkxBR1MrPSAtRFdJVEhPVVRfS0VSQkVST1MK K0RQQUREPQkke0xJQkdTU0FQSX0KK0xEQUREPQktbGdzc2FwaQorLmVuZGlmCiAKIENMRUFORklM RVM9IGdzc2Rfc3ZjLmMgZ3NzZC5oCiAK ------=_Part_1602743_344864969.1356914967578-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 31 02:54:43 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6F0BACE7; Mon, 31 Dec 2012 02:54:43 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by mx1.freebsd.org (Postfix) with ESMTP id 59F928FC13; Mon, 31 Dec 2012 02:54:41 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id dq11so5460440wgb.26 for ; Sun, 30 Dec 2012 18:54:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=E2ybxjALRIBmMhkONBfFD0J/Z3j4fDWSljGsLKZ6qRE=; b=LTe/Dntlff+7aQ0p1ZFO9Scvn3TYyF9UWajOtOs1X1q2mAPOOkz1OQtPuvZMpDsJ08 ypEE81l6Fd2Y6CxuIsj+91tKb7ERhnrhQrkM+vcfLDv/uda0V3fT1sxozF+cpNcK59sD xbhjLFhHnmw9vHtFbNnsCt+tLsIU/pL7o5e6ZRDVIW5otJiNnIbsTqE6tESiPAkrkJaK j/jwpSwuVzU+aMGflp3J08GDKiGmukRFiGalg4vDeXkCQEs+35keHd1FuWMjBNxvvCFb yn6/rKUG9JM9XYBQZ7h+2ztAnQhCRkccKWuK/YV3f+nHkFhaxEObXZUQO3rexffFR/0n xm1w== MIME-Version: 1.0 Received: by 10.180.109.201 with SMTP id hu9mr10698114wib.32.1356922475274; Sun, 30 Dec 2012 18:54:35 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Sun, 30 Dec 2012 18:54:35 -0800 (PST) In-Reply-To: <201212301628.qBUGS6tE037193@svn.freebsd.org> References: <201212301628.qBUGS6tE037193@svn.freebsd.org> Date: Sun, 30 Dec 2012 18:54:35 -0800 X-Google-Sender-Auth: RQjwDM7trmn4JXYVEvOTXIZh_04 Message-ID: Subject: Re: svn commit: r244865 - in head: . lib lib/libdisk share/mk From: Adrian Chadd To: Nathan Whitehorn , freebsd-current Content-Type: text/plain; charset=ISO-8859-1 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 31 Dec 2012 02:54:43 -0000 .. not that I mind old things being retired, but we really should announce things like this. Also - you disconnected libftpio too; is that intentional? Just because libdisk/libftpio isn't used by anything in the base -HEAD doesn't mean that: * it's not used by third party programs in ports; * it's not used by any external, non open source utilities that people have read. So I'd suggest creating a port for them both and begin the process of deprecating the kernel side interfaces that are unique to this API. Thanks, Adrian On 30 December 2012 08:28, Nathan Whitehorn wrote: > Author: nwhitehorn > Date: Sun Dec 30 16:28:06 2012 > New Revision: 244865 > URL: http://svnweb.freebsd.org/changeset/base/244865 > > Log: > With the old sade removed, libdisk is no longer used by anything in HEAD > and uses a number of problematic pre-gpart interfaces. Since it has been > entirely obsoleted by interfaces in geom, remove it. > > Deleted: > head/lib/libdisk/ > Modified: > head/ObsoleteFiles.inc > head/lib/Makefile > head/share/mk/bsd.libnames.mk > > Modified: head/ObsoleteFiles.inc > ============================================================================== > --- head/ObsoleteFiles.inc Sun Dec 30 15:38:06 2012 (r244864) > +++ head/ObsoleteFiles.inc Sun Dec 30 16:28:06 2012 (r244865) > @@ -38,6 +38,9 @@ > # xargs -n1 | sort | uniq -d; > # done > > +# 20121230: libdisk removed > +OLD_FILES+=usr/share/man/man3/libdisk.3.gz usr/include/libdisk.h > +OLD_FILES+=usr/lib/libdisk.a usr/lib32/libdisk.a > # 20121230: remove wrongly created directories for auditdistd > OLD_DIRS+=var/dist > OLD_DIRS+=var/remote > > Modified: head/lib/Makefile > ============================================================================== > --- head/lib/Makefile Sun Dec 30 15:38:06 2012 (r244864) > +++ head/lib/Makefile Sun Dec 30 16:28:06 2012 (r244865) > @@ -69,7 +69,6 @@ SUBDIR= ${SUBDIR_ORDERED} \ > libcompat \ > libdevinfo \ > libdevstat \ > - libdisk \ > libdwarf \ > libedit \ > ${_libefi} \ > > Modified: head/share/mk/bsd.libnames.mk > ============================================================================== > --- head/share/mk/bsd.libnames.mk Sun Dec 30 15:38:06 2012 (r244864) > +++ head/share/mk/bsd.libnames.mk Sun Dec 30 16:28:06 2012 (r244865) > @@ -45,7 +45,6 @@ LIBCURSES?= ${DESTDIR}${LIBDIR}/libcurse > LIBDEVINFO?= ${DESTDIR}${LIBDIR}/libdevinfo.a > LIBDEVSTAT?= ${DESTDIR}${LIBDIR}/libdevstat.a > LIBDIALOG?= ${DESTDIR}${LIBDIR}/libdialog.a > -LIBDISK?= ${DESTDIR}${LIBDIR}/libdisk.a > LIBDNS?= ${DESTDIR}${LIBDIR}/libdns.a > LIBDTRACE?= ${DESTDIR}${LIBDIR}/libdtrace.a > LIBDWARF?= ${DESTDIR}${LIBDIR}/libdwarf.a > @@ -54,7 +53,6 @@ LIBELF?= ${DESTDIR}${LIBDIR}/libelf.a > LIBFETCH?= ${DESTDIR}${LIBDIR}/libfetch.a > LIBFL?= "don't use LIBFL, use LIBL" > LIBFORM?= ${DESTDIR}${LIBDIR}/libform.a > -LIBFTPIO?= ${DESTDIR}${LIBDIR}/libftpio.a > LIBG2C?= ${DESTDIR}${LIBDIR}/libg2c.a > LIBGCC?= ${DESTDIR}${LIBDIR}/libgcc.a > LIBGCC_PIC?= ${DESTDIR}${LIBDIR}/libgcc_pic.a From owner-freebsd-current@FreeBSD.ORG Mon Dec 31 02:57:47 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4F6F7F66; Mon, 31 Dec 2012 02:57:47 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) by mx1.freebsd.org (Postfix) with ESMTP id B272C8FC08; Mon, 31 Dec 2012 02:57:46 +0000 (UTC) Received: by mail-ob0-f171.google.com with SMTP id dn14so11173707obc.16 for ; Sun, 30 Dec 2012 18:57:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Mg0DZsPzAODgqsg5fM3XJPSmVakiZNdbWoLVl6vLm9E=; b=FtONUvTOi8VK+MTpltMTF3GNPKW5hiS1lhmadsWdWTL7ngMlRJf/B5Wvk2t8F1I5CL DIzuepWU2dgthGH0zxhfSjyDZZqWCQEJeW0/CpuIx07ZUqLWvwxPXjvnX4AwLkpbbsAL Ij5M6GPUGrgBeOKFDcsbidzVolAaFSCaMLCaDap/1fIw8iN83o5LT69VXUjnek40jvnU 7xafw5R/llSlu3scMfb+U6tz8/bqd7SEl6xYX99nBd4sU35twRIrWuFx+zIdSehb6sw0 nQ3Zb6/VV/y06Aon32fx1YCDvyiwRsHRQvbyxn9C/y+qQGEQxwVy2jnV7HtvSqzKCQFC Qveg== MIME-Version: 1.0 Received: by 10.182.95.205 with SMTP id dm13mr33508079obb.9.1356922665763; Sun, 30 Dec 2012 18:57:45 -0800 (PST) Received: by 10.76.143.33 with HTTP; Sun, 30 Dec 2012 18:57:45 -0800 (PST) In-Reply-To: References: <201212301628.qBUGS6tE037193@svn.freebsd.org> Date: Sun, 30 Dec 2012 18:57:45 -0800 Message-ID: Subject: Re: svn commit: r244865 - in head: . lib lib/libdisk share/mk From: Garrett Cooper To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, freebsd-current , src-committers@freebsd.org, Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 31 Dec 2012 02:57:47 -0000 On Sun, Dec 30, 2012 at 6:54 PM, Adrian Chadd wrote: > .. not that I mind old things being retired, but we really should > announce things like this. > > Also - you disconnected libftpio too; is that intentional? > > Just because libdisk/libftpio isn't used by anything in the base -HEAD > doesn't mean that: > > * it's not used by third party programs in ports; > * it's not used by any external, non open source utilities that people > have read. > > So I'd suggest creating a port for them both and begin the process of > deprecating the kernel side interfaces that are unique to this API. +1 This is what exp- runs are for (portmgr can help with this). HTH, -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Dec 31 03:03:57 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B14353D7 for ; Mon, 31 Dec 2012 03:03:57 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by mx1.freebsd.org (Postfix) with ESMTP id 6C4698FC14 for ; Mon, 31 Dec 2012 03:03:57 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id l10so11189310oag.8 for ; Sun, 30 Dec 2012 19:03:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tf2d572StxaJR/FGurAdK2uPGbZArpfhnSEVchs047E=; b=qQXAQC9/l4pVsGOy9FKM0DX4nmYbhH26Q/2dQ0YvMcwGsVP3AIGq3ZohC8By4S/2Z/ uOn6gF3S7P6+61+8GFlBwY4WFnDWE+YoxpSYx5p9bV/eCBj8MxvcUkIxz6za15sTfKnm 1JPSPjfXsW0KqxhMmH04QU/Xwm/JomaKkgWpra5pWesdsr4oB5y/WgB+VVjXES60/D2E Ob9DMrFRoc/v0UmdX8mwVogU5NVQ505rFWT3rwGzzHOgagzK5DbyMMhxmaSsSVQ+aFJJ w+YygVRWF7x+RVtxrCyJF1PF66hif7Ip3uBUZWuO/BvSItgXlzCTqNZx5+N1cVDefpnP O5RQ== MIME-Version: 1.0 Received: by 10.182.95.205 with SMTP id dm13mr33515759obb.9.1356923029967; Sun, 30 Dec 2012 19:03:49 -0800 (PST) Received: by 10.76.143.33 with HTTP; Sun, 30 Dec 2012 19:03:49 -0800 (PST) In-Reply-To: <87170730.1602744.1356914967581.JavaMail.root@erie.cs.uoguelph.ca> References: <87170730.1602744.1356914967581.JavaMail.root@erie.cs.uoguelph.ca> Date: Sun, 30 Dec 2012 19:03:49 -0800 Message-ID: Subject: Re: svn commit: r244604 - head/usr.sbin/gssd From: Garrett Cooper To: Rick Macklem Content-Type: text/plain; charset=ISO-8859-1 Cc: bf1783@gmail.com, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 31 Dec 2012 03:03:57 -0000 On Sun, Dec 30, 2012 at 4:49 PM, Rick Macklem wrote: > bf1783 wrote: >> >Author: rmacklem >> >Date: Sat Dec 22 23:21:17 2012 >> >New Revision: 244604 >> >URL: http://svnweb.freebsd.org/changeset/base/244604 >> > >> >Log: >> > It was reported via email that some sshds create kerberos >> > credential cache files with names other than /tmp/krb5cc_. >> > The gssd daemon does not know how to find these credential caches. >> > This patch implements a new option "-s" that does a search for >> > credential cache files, using roughly the same algorithm as the >> > gssd daemon for Linux uses. The gssd behaviour is only changed >> > if the new "-s" option is specified. It also implements two other >> > new options related to the "-s" option. >> > >> > Reported by: Piete.Brooks at cl.cam.ac.uk, Herbert Poeckl >> > Tested by: Herbert Poeckl (admin at ist.tugraz.at), Illias A. >> > Marinos >> > MFC after: 2 weeks >> >> ... >> >> >+#include >> >> Rick: >> >> This breaks world built WITHOUT_KERBEROS and WITH_GSSAPI. >> >> Regards, >> b. > Could you please test the attached patch. > > Also, if someone who is familiar with the build/Makefile side > of things could review this, it would be appreciated. 1. I would name WITHOUT_KERBEROS to KERBEROS_SUPPORT in the sourcefile and CFLAGS to avoid potential confusion/noise with build logic. 2. This code should be revised per style(9): +#else + fprintf(stderr, "This option not available when built" + " without MK_KERBEROS\n"); + exit(1); In particular: errx(1, "This option requires Kerberos support"); Seems more succinct and addresses the actual item at hand. 3. This could be simplified as well potentially: +.if ${MK_KERBEROS} != "no" DPADD= ${LIBGSSAPI} ${LIBKRB5} ${LIBHX509} ${LIBASN1} ${LIBROKEN} ${LIBCOM_ERR} ${LIBCRYPT} ${LIBCRYPTO} LDADD= -lgssapi -lkrb5 -lhx509 -lasn1 -lroken -lcom_err -lcrypt -lcrypto +.else +CFLAGS+= -DWITHOUT_KERBEROS +DPADD= ${LIBGSSAPI} +LDADD= -lgssapi +.endif to this: DPADD= ${LIBGSSAPI} LDADD= -lgssapi .if ${MK_KERBEROS} != "no" CFLAGS+= -DKERBEROS_SUPPORT DPADD+= ${LIBKRB5} ${LIBHX509} ${LIBASN1} ${LIBROKEN} ${LIBCOM_ERR} ${LIBCRYPT} ${LIBCRYPTO} LDADD+= -lkrb5 -lhx509 -lasn1 -lroken -lcom_err -lcrypt -lcrypto .endif Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Dec 31 05:25:34 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 109CDFDB for ; Mon, 31 Dec 2012 05:25:34 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-gg0-f175.google.com (mail-gg0-f175.google.com [209.85.161.175]) by mx1.freebsd.org (Postfix) with ESMTP id B49E68FC0A for ; Mon, 31 Dec 2012 05:25:32 +0000 (UTC) Received: by mail-gg0-f175.google.com with SMTP id y1so1944919ggc.20 for ; Sun, 30 Dec 2012 21:25:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :x-gm-message-state; bh=OiJKmgKBKLpgO5FlpDMiSdvA2liUNIRnjMqMfF8d4Ek=; b=bMMS3oYiJkT5YO4xxAcV91cbilQTtQQOT7SVIjLnmAZ7wv5jwjH0xLHQq1Qja3Zi/T U5dFDgMXZRFQVmiX3mCcTo+ygDvcBtwI/icCssSBDM1WWNFaKVfEtlFuFAypE6lDUpyx pT+FgZbimpemWfOlJ0P12dr0B/GSV5ep1kL1gcdF7W6m9bHHBsTi7YLbbkkI1FSpV7ko 9uSq1ewIOVXrzEgxQBALfyluZPLyzwuNAgFrd97GHXtIOPu8lcyGcTsuoKPMglgn0hGg ZWnWLeG9q9YwwM9GWVGNFEOul8kSj6De5eHqWw5nkzdteBmQ0657eBdCy/dnGaiZptnM FHEQ== Received: by 10.236.154.165 with SMTP id h25mr36924331yhk.38.1356931150979; Sun, 30 Dec 2012 21:19:10 -0800 (PST) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.147.119.38 with HTTP; Sun, 30 Dec 2012 21:18:50 -0800 (PST) In-Reply-To: References: <201212301628.qBUGS6tE037193@svn.freebsd.org> From: Juli Mallett Date: Sun, 30 Dec 2012 21:18:50 -0800 X-Google-Sender-Auth: FCOkDL9foF8aXTLlXB-Xy2s3WP0 Message-ID: Subject: Re: svn commit: r244865 - in head: . lib lib/libdisk share/mk To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmjsuJU4xJrKuRm2EQD1hejcxep+EPt5AmS2Hwk32/kTUcTDXolqYZ4wQvuEPXGHDmBi5S+ Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, freebsd-current , src-committers@freebsd.org, Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 31 Dec 2012 05:25:34 -0000 On Sun, Dec 30, 2012 at 6:54 PM, Adrian Chadd wrote: > .. not that I mind old things being retired, but we really should > announce things like this. > > Also - you disconnected libftpio too; is that intentional? I would assume so, given that this only removed the static library name, which nothing else could be using still, seeing as how the library was disconnected and removed in r225952. > Just because libdisk/libftpio isn't used by anything in the base -HEAD > doesn't mean that: > > * it's not used by third party programs in ports; > * it's not used by any external, non open source utilities that people > have read. > > So I'd suggest creating a port for them both and begin the process of > deprecating the kernel side interfaces that are unique to this API. Pretty sure the addition of and widespread use of GEOM things initiated the deprecation of the really lousy and properly-disliked kernel interfaces involved. > On 30 December 2012 08:28, Nathan Whitehorn wrote: >> Author: nwhitehorn >> Date: Sun Dec 30 16:28:06 2012 >> New Revision: 244865 >> URL: http://svnweb.freebsd.org/changeset/base/244865 >> >> Log: >> With the old sade removed, libdisk is no longer used by anything in HEAD >> and uses a number of problematic pre-gpart interfaces. Since it has been >> entirely obsoleted by interfaces in geom, remove it. >> >> Deleted: >> head/lib/libdisk/ >> Modified: >> head/ObsoleteFiles.inc >> head/lib/Makefile >> head/share/mk/bsd.libnames.mk >> >> Modified: head/ObsoleteFiles.inc >> ============================================================================== >> --- head/ObsoleteFiles.inc Sun Dec 30 15:38:06 2012 (r244864) >> +++ head/ObsoleteFiles.inc Sun Dec 30 16:28:06 2012 (r244865) >> @@ -38,6 +38,9 @@ >> # xargs -n1 | sort | uniq -d; >> # done >> >> +# 20121230: libdisk removed >> +OLD_FILES+=usr/share/man/man3/libdisk.3.gz usr/include/libdisk.h >> +OLD_FILES+=usr/lib/libdisk.a usr/lib32/libdisk.a >> # 20121230: remove wrongly created directories for auditdistd >> OLD_DIRS+=var/dist >> OLD_DIRS+=var/remote >> >> Modified: head/lib/Makefile >> ============================================================================== >> --- head/lib/Makefile Sun Dec 30 15:38:06 2012 (r244864) >> +++ head/lib/Makefile Sun Dec 30 16:28:06 2012 (r244865) >> @@ -69,7 +69,6 @@ SUBDIR= ${SUBDIR_ORDERED} \ >> libcompat \ >> libdevinfo \ >> libdevstat \ >> - libdisk \ >> libdwarf \ >> libedit \ >> ${_libefi} \ >> >> Modified: head/share/mk/bsd.libnames.mk >> ============================================================================== >> --- head/share/mk/bsd.libnames.mk Sun Dec 30 15:38:06 2012 (r244864) >> +++ head/share/mk/bsd.libnames.mk Sun Dec 30 16:28:06 2012 (r244865) >> @@ -45,7 +45,6 @@ LIBCURSES?= ${DESTDIR}${LIBDIR}/libcurse >> LIBDEVINFO?= ${DESTDIR}${LIBDIR}/libdevinfo.a >> LIBDEVSTAT?= ${DESTDIR}${LIBDIR}/libdevstat.a >> LIBDIALOG?= ${DESTDIR}${LIBDIR}/libdialog.a >> -LIBDISK?= ${DESTDIR}${LIBDIR}/libdisk.a >> LIBDNS?= ${DESTDIR}${LIBDIR}/libdns.a >> LIBDTRACE?= ${DESTDIR}${LIBDIR}/libdtrace.a >> LIBDWARF?= ${DESTDIR}${LIBDIR}/libdwarf.a >> @@ -54,7 +53,6 @@ LIBELF?= ${DESTDIR}${LIBDIR}/libelf.a >> LIBFETCH?= ${DESTDIR}${LIBDIR}/libfetch.a >> LIBFL?= "don't use LIBFL, use LIBL" >> LIBFORM?= ${DESTDIR}${LIBDIR}/libform.a >> -LIBFTPIO?= ${DESTDIR}${LIBDIR}/libftpio.a >> LIBG2C?= ${DESTDIR}${LIBDIR}/libg2c.a >> LIBGCC?= ${DESTDIR}${LIBDIR}/libgcc.a >> LIBGCC_PIC?= ${DESTDIR}${LIBDIR}/libgcc_pic.a From owner-freebsd-current@FreeBSD.ORG Mon Dec 31 06:18:44 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D496F382; Mon, 31 Dec 2012 06:18:44 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 37D5F8FC08; Mon, 31 Dec 2012 06:18:43 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 025DD7300A; Mon, 31 Dec 2012 07:17:36 +0100 (CET) Date: Mon, 31 Dec 2012 07:17:35 +0100 From: Luigi Rizzo To: Ian Lepore Subject: Re: [RFC/RFT] calloutng Message-ID: <20121231061735.GA5866@onelab2.iet.unipi.it> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <1356909223.54953.74.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1356909223.54953.74.camel@revolution.hippie.lan> User-Agent: Mutt/1.4.2.3i Cc: Davide Italiano , Marius Strobl , Alexander Motin , FreeBSD Current , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 31 Dec 2012 06:18:44 -0000 On Sun, Dec 30, 2012 at 04:13:43PM -0700, Ian Lepore wrote: ... > I grabbed testsleep.c to test an arm event timer implementation, and had > to fix a couple nits... kqueueto was missing from the names[] array, and > I had to add a "* 1000" to a couple places where usec was stuffed into a > timespec's tv_nsec. > > I also tested the calloutng_12_17 patches and the kqueue stuff behaved > very strangely. Then I noticed you had a 12_26 patchset so I tested > that (after crudely fixing a couple uninitialized var warnings), and it > all looks good on this arm (Raspberry Pi). I'll attach the results. > > It's so sweet to be able to do precision sleeps. interesting numbers, but there seems to be some problem in computing the exact interval; delays are much larger than expected. In this test, the original timer code used to round to the next multiple of 1 tick and then add another tick (except for the kqueue case), which is exactly what you see in the second set of measurements. The calloutng code however seems to do something odd: in addition to fixed overhead (some 50us, which you can see in the tests for 1us and 300us), all delay seem to be ~10% larger than what is requested, upper bounded to 10ms (note, the numbers are averages so i cannot tell whether all samples are the same or there is some distribution of values). I am not sure if this error is peculiar of the ARM version or also appears on x86/amd64 but I believe it should be fixed. If you look at the results below: 1us possily ok: for very short intervals i would expect some kind of 'reschedule' without actually firing a timer; maybe 50us are what it takes to do a round through the scheduler ? 300us probably ok i guess the extra 50-90us are what it takes to do a round through the scheduler 1000us borderline (this is the case for poll and kqueue, which are rounded to 1ms) here intervals seem to be increased by 10%, and i cannot see a good reason for this (more below). 3000us and above: wrong here again, the intervals seem to be 10% larger than what is requested, perhaps limiting the error to 10-20ms. Maybe the 10% extension results from creating a default 'precision' for legacy calls, but i do not think this is done correctly. First of all, if users do not specify a precision themselves, the automatically generated value should never exceed one tick. Second, the only point of a 'precision' parameter is to merge requests that may be close in time, so if there is already a timer scheduled within [Treq, Treq+precision] i will get it; but if there no pending timer, then one should schedule it for the requested interval. Davide/Alexander, any ideas ? cheers luigi > for t in 1 300 3000 30000 300000 ; do > for m in select poll usleep nanosleep kqueue kqueueto syscall ; do > ./testsleep $t $m > done > done > > > With calloutng_12_26.patch... > > HZ=100 HZ=250 HZ=1000 > ---------- ---------------- ---------------- ---------------- > select 1 55.79 1 50.96 1 61.32 > poll 1 1109.46 1 1107.86 1 1114.38 > usleep 1 56.33 1 72.90 1 62.78 > nanosleep 1 52.66 1 55.23 1 64.23 > kqueue 1 1114.23 1 1113.81 1 1121.21 > kqueueto 1 65.44 1 71.00 1 75.01 > syscall 1 4.70 1 4.45 1 4.55 > select 300 355.79 300 357.76 300 362.35 > poll 300 1107.85 300 1122.55 300 1115.62 > usleep 300 355.28 300 357.28 300 360.79 > nanosleep 300 354.49 300 355.82 300 360.62 > kqueue 300 1112.57 300 1118.13 300 1117.16 > kqueueto 300 375.98 300 378.62 300 395.61 > syscall 300 4.41 300 4.45 300 4.54 > select 3000 3246.75 3000 3246.74 3000 3252.72 > poll 3000 3238.10 3000 3229.12 3000 3250.10 > usleep 3000 3242.47 3000 3237.06 3000 3249.61 > nanosleep 3000 3238.79 3000 3231.55 3000 3248.11 > kqueue 3000 3240.01 3000 3236.07 3000 3247.60 > kqueueto 3000 3265.36 3000 3267.22 3000 3274.96 > syscall 3000 4.69 3000 4.44 3000 4.50 > select 30000 31714.60 30000 31941.17 30000 32467.69 > poll 30000 31522.76 30000 31983.00 30000 32497.81 > usleep 30000 31459.67 30000 31980.76 30000 32458.71 > nanosleep 30000 31431.02 30000 31982.22 30000 32525.20 > kqueue 30000 31466.75 30000 31873.90 30000 31973.54 > kqueueto 30000 31564.67 30000 32522.35 30000 32475.59 > syscall 30000 4.70 30000 4.73 30000 4.89 > select 300000 319133.02 300000 311562.33 300000 309918.62 > poll 300000 319604.27 300000 311422.94 300000 310000.76 > usleep 300000 319314.60 300000 311269.69 300000 309996.34 > nanosleep 300000 319497.58 300000 311425.40 300000 309997.13 > kqueue 300000 309995.55 300000 303980.27 300000 309908.82 > kqueueto 300000 319505.88 300000 311424.97 300000 309996.16 > syscall 300000 4.41 300000 4.45 300000 4.89 > > > With no patches... > > HZ=100 HZ=250 HZ=1000 > ---------- ---------------- ---------------- ---------------- > select 1 19941.70 1 7989.10 1 1999.16 > poll 1 19904.61 1 7987.32 1 1999.78 > usleep 1 19904.95 1 7993.30 1 1999.96 > nanosleep 1 19905.64 1 7993.71 1 1999.72 > kqueue 1 10001.61 1 4004.00 1 1000.27 > kqueueto 1 19904.00 1 7993.03 1 1999.54 > syscall 1 4.04 1 4.05 1 4.75 > select 300 19904.66 300 7998.39 300 2000.27 > poll 300 19904.35 300 7993.47 300 1999.86 > usleep 300 19903.96 300 7994.11 300 1999.81 > nanosleep 300 19904.48 300 7993.77 300 1999.80 > kqueue 300 10001.68 300 4004.18 300 1000.31 > kqueueto 300 19997.86 300 7993.37 300 1999.59 > syscall 300 4.01 300 4.00 300 4.32 > select 3000 19904.80 3000 7998.85 3000 3998.43 > poll 3000 19904.92 3000 8005.93 3000 3999.39 > usleep 3000 19904.50 3000 7992.88 3000 3999.44 > nanosleep 3000 19904.84 3000 7993.34 3000 3999.36 > kqueue 3000 10001.58 3000 4003.97 3000 3000.72 > kqueueto 3000 19903.56 3000 7993.24 3000 3999.34 > syscall 3000 4.02 3000 4.37 3000 4.29 > select 30000 39905.02 30000 35991.79 30000 31051.77 > poll 30000 39905.49 30000 35980.35 30000 30995.64 > usleep 30000 39903.78 30000 35979.48 30000 30995.23 > nanosleep 30000 39904.55 30000 35981.61 30000 30995.87 > kqueue 30000 30002.73 30000 32019.54 30000 30004.83 > kqueueto 30000 39903.59 30000 35979.64 30000 30996.05 > syscall 30000 4.44 30000 4.04 30000 4.31 > select 300000 310001.23 300000 303995.86 300000 300994.30 > poll 300000 309902.73 300000 303981.58 300000 300996.17 > usleep 300000 309903.64 300000 303980.17 300000 300997.42 > nanosleep 300000 309903.32 300000 303980.36 300000 300993.64 > kqueue 300000 300002.77 300000 300019.46 300000 300006.90 > kqueueto 300000 309903.31 300000 303978.10 300000 300996.84 > syscall 300000 4.01 300000 4.04 300000 4.29 From owner-freebsd-current@FreeBSD.ORG Mon Dec 31 07:11:23 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 72FCE2E7; Mon, 31 Dec 2012 07:11:23 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id 46ECB8FC15; Mon, 31 Dec 2012 07:11:21 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 2F17C56078; Mon, 31 Dec 2012 01:11:21 -0600 (CST) Date: Mon, 31 Dec 2012 01:11:21 -0600 From: Mark Linimon To: Garrett Cooper Subject: Re: svn commit: r244865 - in head: . lib lib/libdisk share/mk Message-ID: <20121231071121.GA11697@lonesome.com> References: <201212301628.qBUGS6tE037193@svn.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Adrian Chadd , src-committers@freebsd.org, svn-src-all@freebsd.org, freebsd-current , Nathan Whitehorn , svn-src-head@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 31 Dec 2012 07:11:23 -0000 On Sun, Dec 30, 2012 at 06:57:45PM -0800, Garrett Cooper wrote: > This is what exp- runs are for (portmgr can help with this). OTOH -exp runs are currently off the air. mcl From owner-freebsd-current@FreeBSD.ORG Mon Dec 31 08:00:29 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6AC51140; Mon, 31 Dec 2012 08:00:29 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) by mx1.freebsd.org (Postfix) with ESMTP id D7BC88FC08; Mon, 31 Dec 2012 08:00:28 +0000 (UTC) Received: by mail-vc0-f176.google.com with SMTP id fo13so12569151vcb.35 for ; Mon, 31 Dec 2012 00:00:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=SPs38VQcmnu+caTyQwu/Z/8HaDdk5iZEn2W1EkN9GTY=; b=NmodQung/gEwb88SxllsH2ZvEVxRoSOfm0S0ecCqtwIPYzltchxjyEPlprnzL3S12k rtr2tTcSSneJl1pHbHOp6eQncY5piw9F1gNp/SCfFHBvjHwcgY78LTzNZQKx5vcdr3Hh w6arJyGm8YDd7E0BG0rdMHavwEvX+NWSg5l2P1IXjorAIcdrGMb3B4gaKnWLCsDMPU9L IfgY0BZ+Sq+RUaJ2jgZwXcBb2dIyqOfxGJVq51W/t8LwcUxW3A/o6pJPhsGLhgy1c720 yj54Q31umHsmJRO9wHiVa6TEmMpiJQvY289ZuoHsHyVpmCp4RqfnXe1XczQuwsdcelvb WWhQ== MIME-Version: 1.0 Received: by 10.58.222.40 with SMTP id qj8mr64611180vec.36.1356940822078; Mon, 31 Dec 2012 00:00:22 -0800 (PST) Sender: davide.italiano@gmail.com Received: by 10.58.229.136 with HTTP; Mon, 31 Dec 2012 00:00:21 -0800 (PST) In-Reply-To: <20121231061735.GA5866@onelab2.iet.unipi.it> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <1356909223.54953.74.camel@revolution.hippie.lan> <20121231061735.GA5866@onelab2.iet.unipi.it> Date: Mon, 31 Dec 2012 00:00:21 -0800 X-Google-Sender-Auth: u3rbG-o2zq2jDv9iiGJpHWs8HMg Message-ID: Subject: Re: [RFC/RFT] calloutng From: Davide Italiano To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Cc: Ian Lepore , Alexander Motin , FreeBSD Current , Marius Strobl , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 31 Dec 2012 08:00:29 -0000 On Sun, Dec 30, 2012 at 10:17 PM, Luigi Rizzo wrote: > On Sun, Dec 30, 2012 at 04:13:43PM -0700, Ian Lepore wrote: > ... >> I grabbed testsleep.c to test an arm event timer implementation, and had >> to fix a couple nits... kqueueto was missing from the names[] array, and >> I had to add a "* 1000" to a couple places where usec was stuffed into a >> timespec's tv_nsec. >> >> I also tested the calloutng_12_17 patches and the kqueue stuff behaved >> very strangely. Then I noticed you had a 12_26 patchset so I tested >> that (after crudely fixing a couple uninitialized var warnings), and it >> all looks good on this arm (Raspberry Pi). I'll attach the results. >> >> It's so sweet to be able to do precision sleeps. > > interesting numbers, but there seems to be some problem in computing > the exact interval; delays are much larger than expected. > > In this test, the original timer code used to round to the next multiple > of 1 tick and then add another tick (except for the kqueue case), > which is exactly what you see in the second set of measurements. > > The calloutng code however seems to do something odd: > in addition to fixed overhead (some 50us, which you can see in > the tests for 1us and 300us), all delay seem to be ~10% larger > than what is requested, upper bounded to 10ms (note, the > numbers are averages so i cannot tell whether all samples are > the same or there is some distribution of values). > > I am not sure if this error is peculiar of the ARM version or also > appears on x86/amd64 but I believe it should be fixed. > > If you look at the results below: > > 1us possily ok: > for very short intervals i would expect some kind > of 'reschedule' without actually firing a timer; maybe > 50us are what it takes to do a round through the scheduler ? > > 300us probably ok > i guess the extra 50-90us are what it takes to do a round > through the scheduler > > 1000us borderline (this is the case for poll and kqueue, which are > rounded to 1ms) > here intervals seem to be increased by 10%, and i cannot see > a good reason for this (more below). > > 3000us and above: wrong > here again, the intervals seem to be 10% larger than what is > requested, perhaps limiting the error to 10-20ms. > > > Maybe the 10% extension results from creating a default 'precision' > for legacy calls, but i do not think this is done correctly. > > First of all, if users do not specify a precision themselves, the > automatically generated value should never exceed one tick. > > Second, the only point of a 'precision' parameter is to merge > requests that may be close in time, so if there is already a > timer scheduled within [Treq, Treq+precision] i will get it; > but if there no pending timer, then one should schedule it > for the requested interval. > > Davide/Alexander, any ideas ? > The first question is what couple timecounter/eventtimer is used. Some hardware is slower than other, and this may affect numbers. Thanks for testing, BTW. Davide > cheers > luigi > >> for t in 1 300 3000 30000 300000 ; do >> for m in select poll usleep nanosleep kqueue kqueueto syscall ; do >> ./testsleep $t $m >> done >> done >> >> >> With calloutng_12_26.patch... >> >> HZ=100 HZ=250 HZ=1000 >> ---------- ---------------- ---------------- ---------------- >> select 1 55.79 1 50.96 1 61.32 >> poll 1 1109.46 1 1107.86 1 1114.38 >> usleep 1 56.33 1 72.90 1 62.78 >> nanosleep 1 52.66 1 55.23 1 64.23 >> kqueue 1 1114.23 1 1113.81 1 1121.21 >> kqueueto 1 65.44 1 71.00 1 75.01 >> syscall 1 4.70 1 4.45 1 4.55 >> select 300 355.79 300 357.76 300 362.35 >> poll 300 1107.85 300 1122.55 300 1115.62 >> usleep 300 355.28 300 357.28 300 360.79 >> nanosleep 300 354.49 300 355.82 300 360.62 >> kqueue 300 1112.57 300 1118.13 300 1117.16 >> kqueueto 300 375.98 300 378.62 300 395.61 >> syscall 300 4.41 300 4.45 300 4.54 >> select 3000 3246.75 3000 3246.74 3000 3252.72 >> poll 3000 3238.10 3000 3229.12 3000 3250.10 >> usleep 3000 3242.47 3000 3237.06 3000 3249.61 >> nanosleep 3000 3238.79 3000 3231.55 3000 3248.11 >> kqueue 3000 3240.01 3000 3236.07 3000 3247.60 >> kqueueto 3000 3265.36 3000 3267.22 3000 3274.96 >> syscall 3000 4.69 3000 4.44 3000 4.50 >> select 30000 31714.60 30000 31941.17 30000 32467.69 >> poll 30000 31522.76 30000 31983.00 30000 32497.81 >> usleep 30000 31459.67 30000 31980.76 30000 32458.71 >> nanosleep 30000 31431.02 30000 31982.22 30000 32525.20 >> kqueue 30000 31466.75 30000 31873.90 30000 31973.54 >> kqueueto 30000 31564.67 30000 32522.35 30000 32475.59 >> syscall 30000 4.70 30000 4.73 30000 4.89 >> select 300000 319133.02 300000 311562.33 300000 309918.62 >> poll 300000 319604.27 300000 311422.94 300000 310000.76 >> usleep 300000 319314.60 300000 311269.69 300000 309996.34 >> nanosleep 300000 319497.58 300000 311425.40 300000 309997.13 >> kqueue 300000 309995.55 300000 303980.27 300000 309908.82 >> kqueueto 300000 319505.88 300000 311424.97 300000 309996.16 >> syscall 300000 4.41 300000 4.45 300000 4.89 >> >> >> With no patches... >> >> HZ=100 HZ=250 HZ=1000 >> ---------- ---------------- ---------------- ---------------- >> select 1 19941.70 1 7989.10 1 1999.16 >> poll 1 19904.61 1 7987.32 1 1999.78 >> usleep 1 19904.95 1 7993.30 1 1999.96 >> nanosleep 1 19905.64 1 7993.71 1 1999.72 >> kqueue 1 10001.61 1 4004.00 1 1000.27 >> kqueueto 1 19904.00 1 7993.03 1 1999.54 >> syscall 1 4.04 1 4.05 1 4.75 >> select 300 19904.66 300 7998.39 300 2000.27 >> poll 300 19904.35 300 7993.47 300 1999.86 >> usleep 300 19903.96 300 7994.11 300 1999.81 >> nanosleep 300 19904.48 300 7993.77 300 1999.80 >> kqueue 300 10001.68 300 4004.18 300 1000.31 >> kqueueto 300 19997.86 300 7993.37 300 1999.59 >> syscall 300 4.01 300 4.00 300 4.32 >> select 3000 19904.80 3000 7998.85 3000 3998.43 >> poll 3000 19904.92 3000 8005.93 3000 3999.39 >> usleep 3000 19904.50 3000 7992.88 3000 3999.44 >> nanosleep 3000 19904.84 3000 7993.34 3000 3999.36 >> kqueue 3000 10001.58 3000 4003.97 3000 3000.72 >> kqueueto 3000 19903.56 3000 7993.24 3000 3999.34 >> syscall 3000 4.02 3000 4.37 3000 4.29 >> select 30000 39905.02 30000 35991.79 30000 31051.77 >> poll 30000 39905.49 30000 35980.35 30000 30995.64 >> usleep 30000 39903.78 30000 35979.48 30000 30995.23 >> nanosleep 30000 39904.55 30000 35981.61 30000 30995.87 >> kqueue 30000 30002.73 30000 32019.54 30000 30004.83 >> kqueueto 30000 39903.59 30000 35979.64 30000 30996.05 >> syscall 30000 4.44 30000 4.04 30000 4.31 >> select 300000 310001.23 300000 303995.86 300000 300994.30 >> poll 300000 309902.73 300000 303981.58 300000 300996.17 >> usleep 300000 309903.64 300000 303980.17 300000 300997.42 >> nanosleep 300000 309903.32 300000 303980.36 300000 300993.64 >> kqueue 300000 300002.77 300000 300019.46 300000 300006.90 >> kqueueto 300000 309903.31 300000 303978.10 300000 300996.84 >> syscall 300000 4.01 300000 4.04 300000 4.29 From owner-freebsd-current@FreeBSD.ORG Mon Dec 31 10:17:40 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DC49B2A0; Mon, 31 Dec 2012 10:17:40 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by mx1.freebsd.org (Postfix) with ESMTP id 0AD238FC12; Mon, 31 Dec 2012 10:17:39 +0000 (UTC) Received: by mail-ee0-f41.google.com with SMTP id d41so6247476eek.28 for ; Mon, 31 Dec 2012 02:17:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=FSL5cERnn0KcJG32xw3ftGzxZpAT3VlCzYXtzysnkNQ=; b=tmu98rReHUMAyUT/PEKZbqH9Rjw2jrzosdtFs53O/nrOy6+l9OzQx6ki32nTazeqDC 67rrzw3wqPEhmPcW9BWgwequQn0CPNY2fknpBstnaLCiqVcCXDLYb7v+b+jEALCoB6Ri ob27Gyo2KNGa82b8sHChTuhgFqA2iq5kjpHloM8Rr/HQLKkRnSlTCrmrvL+dLbyxfliQ qu6T7eoXiou3lf+nirBjVNSzJGn+3W0xz5MJj36M6se4zHUNLBsINs1bi6TVuvZgFumx Hhyns86l45Jj7wb7LKhN5EMLzMU4MJ/AlhCNzCf0MLe/B7Q+gwqOB/tsBQygtwiNegBz P1/Q== X-Received: by 10.14.194.195 with SMTP id m43mr110059168een.44.1356949052812; Mon, 31 Dec 2012 02:17:32 -0800 (PST) Received: from mavbook.mavhome.dp.ua ([91.198.175.1]) by mx.google.com with ESMTPS id 6sm84105691eea.3.2012.12.31.02.17.30 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 31 Dec 2012 02:17:31 -0800 (PST) Sender: Alexander Motin Message-ID: <50E16637.9070501@FreeBSD.org> Date: Mon, 31 Dec 2012 12:17:27 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: [RFC/RFT] calloutng References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <1356909223.54953.74.camel@revolution.hippie.lan> <20121231061735.GA5866@onelab2.iet.unipi.it> In-Reply-To: <20121231061735.GA5866@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Davide Italiano , Ian Lepore , FreeBSD Current , Marius Strobl , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 31 Dec 2012 10:17:40 -0000 On 31.12.2012 08:17, Luigi Rizzo wrote: > On Sun, Dec 30, 2012 at 04:13:43PM -0700, Ian Lepore wrote: > ... >> I grabbed testsleep.c to test an arm event timer implementation, and had >> to fix a couple nits... kqueueto was missing from the names[] array, and >> I had to add a "* 1000" to a couple places where usec was stuffed into a >> timespec's tv_nsec. >> >> I also tested the calloutng_12_17 patches and the kqueue stuff behaved >> very strangely. I've rewritten kqueue timeouts at the calloutng_12_26.patch. >> Then I noticed you had a 12_26 patchset so I tested >> that (after crudely fixing a couple uninitialized var warnings), and it >> all looks good on this arm (Raspberry Pi). I'll attach the results. >> >> It's so sweet to be able to do precision sleeps. Thank you for testing, Ian. > interesting numbers, but there seems to be some problem in computing > the exact interval; delays are much larger than expected. > > In this test, the original timer code used to round to the next multiple > of 1 tick and then add another tick (except for the kqueue case), > which is exactly what you see in the second set of measurements. > > The calloutng code however seems to do something odd: > in addition to fixed overhead (some 50us, which you can see in > the tests for 1us and 300us), all delay seem to be ~10% larger > than what is requested, upper bounded to 10ms (note, the > numbers are averages so i cannot tell whether all samples are > the same or there is some distribution of values). > > I am not sure if this error is peculiar of the ARM version or also > appears on x86/amd64 but I believe it should be fixed. > > If you look at the results below: > > 1us possily ok: > for very short intervals i would expect some kind > of 'reschedule' without actually firing a timer; maybe > 50us are what it takes to do a round through the scheduler ? > > 300us probably ok > i guess the extra 50-90us are what it takes to do a round > through the scheduler > > 1000us borderline (this is the case for poll and kqueue, which are > rounded to 1ms) > here intervals seem to be increased by 10%, and i cannot see > a good reason for this (more below). > > 3000us and above: wrong > here again, the intervals seem to be 10% larger than what is > requested, perhaps limiting the error to 10-20ms. > > > Maybe the 10% extension results from creating a default 'precision' > for legacy calls, but i do not think this is done correctly. > > First of all, if users do not specify a precision themselves, the > automatically generated value should never exceed one tick. > > Second, the only point of a 'precision' parameter is to merge > requests that may be close in time, so if there is already a > timer scheduled within [Treq, Treq+precision] i will get it; > but if there no pending timer, then one should schedule it > for the requested interval. > > Davide/Alexander, any ideas ? All mentioned effects could be explained with implemented logic. 50us at 1us is probably sum of minimal latency of the hardware eventtimer on the specific platform and some software processing overhead (syscall, callout, timecouters, scheduler, etc). At later points system starts to noticeably use precision specified by kern.timecounter.alloweddeviation sysctl. It affects results from two sides: 1) extending intervals for specified percent of time to allow event aggregation, and 2) choosing time base between fast getbinuptime() and precise binuptime(). Extending interval is needed to aggregate not only callouts with each other, but also callouts with other system events, which are impossible to schedule in advance. It gives specified relative error, but no more then one CPU wakeup period in absolute: for busy CPU (not skipping hardclock() ticks) it is 1/hz, for completely idle one it can be up to 0.5s. Second point allows to reduce processing overhead by the cost of error up to 1/hz for long periods (>(100/allowed)*(1/hz)), when it is used. To get best possible precision kern.timecounter.alloweddeviation sysctl can be set to smaller value. Setting it to 0 will effectively disable all optimizations, but should give 50us precision in all cases. >> for t in 1 300 3000 30000 300000 ; do >> for m in select poll usleep nanosleep kqueue kqueueto syscall ; do >> ./testsleep $t $m >> done >> done >> >> >> With calloutng_12_26.patch... >> >> HZ=100 HZ=250 HZ=1000 >> ---------- ---------------- ---------------- ---------------- >> select 1 55.79 1 50.96 1 61.32 >> poll 1 1109.46 1 1107.86 1 1114.38 >> usleep 1 56.33 1 72.90 1 62.78 >> nanosleep 1 52.66 1 55.23 1 64.23 >> kqueue 1 1114.23 1 1113.81 1 1121.21 >> kqueueto 1 65.44 1 71.00 1 75.01 >> syscall 1 4.70 1 4.45 1 4.55 >> select 300 355.79 300 357.76 300 362.35 >> poll 300 1107.85 300 1122.55 300 1115.62 >> usleep 300 355.28 300 357.28 300 360.79 >> nanosleep 300 354.49 300 355.82 300 360.62 >> kqueue 300 1112.57 300 1118.13 300 1117.16 >> kqueueto 300 375.98 300 378.62 300 395.61 >> syscall 300 4.41 300 4.45 300 4.54 >> select 3000 3246.75 3000 3246.74 3000 3252.72 >> poll 3000 3238.10 3000 3229.12 3000 3250.10 >> usleep 3000 3242.47 3000 3237.06 3000 3249.61 >> nanosleep 3000 3238.79 3000 3231.55 3000 3248.11 >> kqueue 3000 3240.01 3000 3236.07 3000 3247.60 >> kqueueto 3000 3265.36 3000 3267.22 3000 3274.96 >> syscall 3000 4.69 3000 4.44 3000 4.50 >> select 30000 31714.60 30000 31941.17 30000 32467.69 >> poll 30000 31522.76 30000 31983.00 30000 32497.81 >> usleep 30000 31459.67 30000 31980.76 30000 32458.71 >> nanosleep 30000 31431.02 30000 31982.22 30000 32525.20 >> kqueue 30000 31466.75 30000 31873.90 30000 31973.54 >> kqueueto 30000 31564.67 30000 32522.35 30000 32475.59 >> syscall 30000 4.70 30000 4.73 30000 4.89 >> select 300000 319133.02 300000 311562.33 300000 309918.62 >> poll 300000 319604.27 300000 311422.94 300000 310000.76 >> usleep 300000 319314.60 300000 311269.69 300000 309996.34 >> nanosleep 300000 319497.58 300000 311425.40 300000 309997.13 >> kqueue 300000 309995.55 300000 303980.27 300000 309908.82 >> kqueueto 300000 319505.88 300000 311424.97 300000 309996.16 >> syscall 300000 4.41 300000 4.45 300000 4.89 >> >> >> With no patches... >> >> HZ=100 HZ=250 HZ=1000 >> ---------- ---------------- ---------------- ---------------- >> select 1 19941.70 1 7989.10 1 1999.16 >> poll 1 19904.61 1 7987.32 1 1999.78 >> usleep 1 19904.95 1 7993.30 1 1999.96 >> nanosleep 1 19905.64 1 7993.71 1 1999.72 >> kqueue 1 10001.61 1 4004.00 1 1000.27 >> kqueueto 1 19904.00 1 7993.03 1 1999.54 >> syscall 1 4.04 1 4.05 1 4.75 >> select 300 19904.66 300 7998.39 300 2000.27 >> poll 300 19904.35 300 7993.47 300 1999.86 >> usleep 300 19903.96 300 7994.11 300 1999.81 >> nanosleep 300 19904.48 300 7993.77 300 1999.80 >> kqueue 300 10001.68 300 4004.18 300 1000.31 >> kqueueto 300 19997.86 300 7993.37 300 1999.59 >> syscall 300 4.01 300 4.00 300 4.32 >> select 3000 19904.80 3000 7998.85 3000 3998.43 >> poll 3000 19904.92 3000 8005.93 3000 3999.39 >> usleep 3000 19904.50 3000 7992.88 3000 3999.44 >> nanosleep 3000 19904.84 3000 7993.34 3000 3999.36 >> kqueue 3000 10001.58 3000 4003.97 3000 3000.72 >> kqueueto 3000 19903.56 3000 7993.24 3000 3999.34 >> syscall 3000 4.02 3000 4.37 3000 4.29 >> select 30000 39905.02 30000 35991.79 30000 31051.77 >> poll 30000 39905.49 30000 35980.35 30000 30995.64 >> usleep 30000 39903.78 30000 35979.48 30000 30995.23 >> nanosleep 30000 39904.55 30000 35981.61 30000 30995.87 >> kqueue 30000 30002.73 30000 32019.54 30000 30004.83 >> kqueueto 30000 39903.59 30000 35979.64 30000 30996.05 >> syscall 30000 4.44 30000 4.04 30000 4.31 >> select 300000 310001.23 300000 303995.86 300000 300994.30 >> poll 300000 309902.73 300000 303981.58 300000 300996.17 >> usleep 300000 309903.64 300000 303980.17 300000 300997.42 >> nanosleep 300000 309903.32 300000 303980.36 300000 300993.64 >> kqueue 300000 300002.77 300000 300019.46 300000 300006.90 >> kqueueto 300000 309903.31 300000 303978.10 300000 300996.84 >> syscall 300000 4.01 300000 4.04 300000 4.29 -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Dec 31 11:55:32 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A99086EA for ; Mon, 31 Dec 2012 11:55:32 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 5B0218FC0A for ; Mon, 31 Dec 2012 11:55:31 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAIZ84VCDaFvO/2dsb2JhbABFhjq3O3OCHgEBAQMBAQEBICsgCwUWDgYEAgINGQIpAQkmBggHBAEcBIdsBgymGpBjgSKLNQsQgxWBEwOIYop8gi6BHI8sgxKBUzU X-IronPort-AV: E=Sophos;i="4.84,385,1355115600"; d="scan'208";a="6965606" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 31 Dec 2012 06:55:30 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id F10E7B4037; Mon, 31 Dec 2012 06:55:29 -0500 (EST) Date: Mon, 31 Dec 2012 06:55:29 -0500 (EST) From: Rick Macklem To: Garrett Cooper Message-ID: <1905046872.1604317.1356954929867.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: Subject: Re: svn commit: r244604 - head/usr.sbin/gssd MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: bf1783@gmail.com, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 31 Dec 2012 11:55:32 -0000 Garrett Cooper wrote: > On Sun, Dec 30, 2012 at 4:49 PM, Rick Macklem > wrote: > > bf1783 wrote: > >> >Author: rmacklem > >> >Date: Sat Dec 22 23:21:17 2012 > >> >New Revision: 244604 > >> >URL: http://svnweb.freebsd.org/changeset/base/244604 > >> > > >> >Log: > >> > It was reported via email that some sshds create kerberos > >> > credential cache files with names other than /tmp/krb5cc_. > >> > The gssd daemon does not know how to find these credential > >> > caches. > >> > This patch implements a new option "-s" that does a search for > >> > credential cache files, using roughly the same algorithm as the > >> > gssd daemon for Linux uses. The gssd behaviour is only changed > >> > if the new "-s" option is specified. It also implements two > >> > other > >> > new options related to the "-s" option. > >> > > >> > Reported by: Piete.Brooks at cl.cam.ac.uk, Herbert Poeckl > >> > Tested by: Herbert Poeckl (admin at ist.tugraz.at), Illias A. > >> > Marinos > >> > MFC after: 2 weeks > >> > >> ... > >> > >> >+#include > >> > >> Rick: > >> > >> This breaks world built WITHOUT_KERBEROS and WITH_GSSAPI. > >> > >> Regards, > >> b. > > Could you please test the attached patch. > > > > Also, if someone who is familiar with the build/Makefile side > > of things could review this, it would be appreciated. > > 1. I would name WITHOUT_KERBEROS to KERBEROS_SUPPORT in the sourcefile > and CFLAGS to avoid potential confusion/noise with build logic. > WITHOUT_KERBEROS is used other places, like telnetd. Were you aware of that? (I just thought it would keep it consistent, but if you think it is better to use a different name, I don't care.) > 2. This code should be revised per style(9): > > +#else > + fprintf(stderr, "This option not available when built" > + " without MK_KERBEROS\n"); > + exit(1); > > In particular: > > errx(1, "This option requires Kerberos support"); > > Seems more succinct and addresses the actual item at hand. > Yea, I'll switch it to errx(). I just cribbed the code further down, that used fprintf(). > 3. This could be simplified as well potentially: > > +.if ${MK_KERBEROS} != "no" > DPADD= ${LIBGSSAPI} ${LIBKRB5} ${LIBHX509} ${LIBASN1} ${LIBROKEN} > ${LIBCOM_ERR} ${LIBCRYPT} ${LIBCRYPTO} > LDADD= -lgssapi -lkrb5 -lhx509 -lasn1 -lroken -lcom_err -lcrypt > -lcrypto > +.else > +CFLAGS+= -DWITHOUT_KERBEROS > +DPADD= ${LIBGSSAPI} > +LDADD= -lgssapi > +.endif > > to this: > > DPADD= ${LIBGSSAPI} > LDADD= -lgssapi > .if ${MK_KERBEROS} != "no" > CFLAGS+= -DKERBEROS_SUPPORT > DPADD+= ${LIBKRB5} ${LIBHX509} ${LIBASN1} ${LIBROKEN} ${LIBCOM_ERR} > ${LIBCRYPT} ${LIBCRYPTO} > LDADD+= -lkrb5 -lhx509 -lasn1 -lroken -lcom_err -lcrypt -lcrypto > .endif > Yea, I can do this change too. I think the latter is more readable. Thanks, rick > Thanks! > -Garrett > _______________________________________________ > 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 Dec 31 12:18:15 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BF4EB60A for ; Mon, 31 Dec 2012 12:18:15 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 6F01F8FC08 for ; Mon, 31 Dec 2012 12:18:15 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAP5/4VCDaFvO/2dsb2JhbABFhjq3O3OCHgEBAQMBAQEBICsgCxsOBgQCAg0ZAikBCSYGCAcEARwEh2wGDKYYkGKBIos1CxCDFYETA4hiinyCLoEcjyyDEoFTNQ X-IronPort-AV: E=Sophos;i="4.84,385,1355115600"; d="scan'208";a="6968304" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 31 Dec 2012 07:18:14 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 86A47B3F1A; Mon, 31 Dec 2012 07:18:14 -0500 (EST) Date: Mon, 31 Dec 2012 07:18:14 -0500 (EST) From: Rick Macklem To: Garrett Cooper Message-ID: <44353525.1604353.1356956294487.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <1905046872.1604317.1356954929867.JavaMail.root@erie.cs.uoguelph.ca> Subject: Re: svn commit: r244604 - head/usr.sbin/gssd MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: bf1783@gmail.com, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 31 Dec 2012 12:18:15 -0000 Rick Macklem wrote: > Garrett Cooper wrote: > > On Sun, Dec 30, 2012 at 4:49 PM, Rick Macklem > > wrote: > > > bf1783 wrote: > > >> >Author: rmacklem > > >> >Date: Sat Dec 22 23:21:17 2012 > > >> >New Revision: 244604 > > >> >URL: http://svnweb.freebsd.org/changeset/base/244604 > > >> > > > >> >Log: > > >> > It was reported via email that some sshds create kerberos > > >> > credential cache files with names other than > > >> > /tmp/krb5cc_. > > >> > The gssd daemon does not know how to find these credential > > >> > caches. > > >> > This patch implements a new option "-s" that does a search for > > >> > credential cache files, using roughly the same algorithm as > > >> > the > > >> > gssd daemon for Linux uses. The gssd behaviour is only changed > > >> > if the new "-s" option is specified. It also implements two > > >> > other > > >> > new options related to the "-s" option. > > >> > > > >> > Reported by: Piete.Brooks at cl.cam.ac.uk, Herbert Poeckl > > >> > Tested by: Herbert Poeckl (admin at ist.tugraz.at), Illias A. > > >> > Marinos > > >> > MFC after: 2 weeks > > >> > > >> ... > > >> > > >> >+#include > > >> > > >> Rick: > > >> > > >> This breaks world built WITHOUT_KERBEROS and WITH_GSSAPI. > > >> > > >> Regards, > > >> b. > > > Could you please test the attached patch. > > > > > > Also, if someone who is familiar with the build/Makefile side > > > of things could review this, it would be appreciated. > > > > 1. I would name WITHOUT_KERBEROS to KERBEROS_SUPPORT in the > > sourcefile > > and CFLAGS to avoid potential confusion/noise with build logic. > > > WITHOUT_KERBEROS is used other places, like telnetd. Were you aware of > that? > (I just thought it would keep it consistent, but if you think it is > better > to use a different name, I don't care.) > Oh, I see you were suggesting that the polarity be reversed. Well, although the #ifndef is a bit ugly, the utility is useless without Kerberos, so I think I'd rather stick with "enabled by default". Also, there is KPROGS in head/kerberos5/Makefile, which is a list of programs that depend on kerberos. gssd isn't in the list, but maybe it should be? (And that list is used to "dekerberise" them by setting -DWITHOUT_KERBEROS.) So, unless others feel strongly about it, I think I'd rather stick with using WITHOUT_KEREBEROS. rick > > 2. This code should be revised per style(9): > > > > +#else > > + fprintf(stderr, "This option not available when built" > > + " without MK_KERBEROS\n"); > > + exit(1); > > > > In particular: > > > > errx(1, "This option requires Kerberos support"); > > > > Seems more succinct and addresses the actual item at hand. > > > Yea, I'll switch it to errx(). I just cribbed the code further > down, that used fprintf(). > > > 3. This could be simplified as well potentially: > > > > +.if ${MK_KERBEROS} != "no" > > DPADD= ${LIBGSSAPI} ${LIBKRB5} ${LIBHX509} ${LIBASN1} ${LIBROKEN} > > ${LIBCOM_ERR} ${LIBCRYPT} ${LIBCRYPTO} > > LDADD= -lgssapi -lkrb5 -lhx509 -lasn1 -lroken -lcom_err -lcrypt > > -lcrypto > > +.else > > +CFLAGS+= -DWITHOUT_KERBEROS > > +DPADD= ${LIBGSSAPI} > > +LDADD= -lgssapi > > +.endif > > > > to this: > > > > DPADD= ${LIBGSSAPI} > > LDADD= -lgssapi > > .if ${MK_KERBEROS} != "no" > > CFLAGS+= -DKERBEROS_SUPPORT > > DPADD+= ${LIBKRB5} ${LIBHX509} ${LIBASN1} ${LIBROKEN} ${LIBCOM_ERR} > > ${LIBCRYPT} ${LIBCRYPTO} > > LDADD+= -lkrb5 -lhx509 -lasn1 -lroken -lcom_err -lcrypt -lcrypto > > .endif > > > Yea, I can do this change too. I think the latter is more readable. > > Thanks, rick > > > Thanks! > > -Garrett > > _______________________________________________ > > 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" > _______________________________________________ > 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 Dec 31 12:20:20 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F234B726 for ; Mon, 31 Dec 2012 12:20:19 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 9A6FB8FC14 for ; Mon, 31 Dec 2012 12:20:19 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAJyC4VCDaFvO/2dsb2JhbABFhjq3O3OCHgEBAQMBAQEBICsgCwUWDgYEERkCBCUBCSYGCAcEARwEh2wGDKYakGGMVwsQgxWBEwOIYoYmhFaCLoEcjyyDEoFTNQ X-IronPort-AV: E=Sophos;i="4.84,385,1355115600"; d="scan'208";a="8080835" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 31 Dec 2012 07:20:17 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id F079BB4033; Mon, 31 Dec 2012 07:20:17 -0500 (EST) Date: Mon, 31 Dec 2012 07:20:17 -0500 (EST) From: Rick Macklem To: Garrett Cooper Message-ID: <419702074.1604361.1356956417866.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <44353525.1604353.1356956294487.JavaMail.root@erie.cs.uoguelph.ca> Subject: Re: svn commit: r244604 - head/usr.sbin/gssd MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1604360_1467627588.1356956417863" X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: bf1783@gmail.com, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 31 Dec 2012 12:20:20 -0000 ------=_Part_1604360_1467627588.1356956417863 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Rick Macklem wrote: > Rick Macklem wrote: > > Garrett Cooper wrote: > > > On Sun, Dec 30, 2012 at 4:49 PM, Rick Macklem > > > > > > wrote: > > > > bf1783 wrote: > > > >> >Author: rmacklem > > > >> >Date: Sat Dec 22 23:21:17 2012 > > > >> >New Revision: 244604 > > > >> >URL: http://svnweb.freebsd.org/changeset/base/244604 > > > >> > > > > >> >Log: > > > >> > It was reported via email that some sshds create kerberos > > > >> > credential cache files with names other than > > > >> > /tmp/krb5cc_. > > > >> > The gssd daemon does not know how to find these credential > > > >> > caches. > > > >> > This patch implements a new option "-s" that does a search > > > >> > for > > > >> > credential cache files, using roughly the same algorithm as > > > >> > the > > > >> > gssd daemon for Linux uses. The gssd behaviour is only > > > >> > changed > > > >> > if the new "-s" option is specified. It also implements two > > > >> > other > > > >> > new options related to the "-s" option. > > > >> > > > > >> > Reported by: Piete.Brooks at cl.cam.ac.uk, Herbert Poeckl > > > >> > Tested by: Herbert Poeckl (admin at ist.tugraz.at), Illias > > > >> > A. > > > >> > Marinos > > > >> > MFC after: 2 weeks > > > >> > > > >> ... > > > >> > > > >> >+#include > > > >> > > > >> Rick: > > > >> > > > >> This breaks world built WITHOUT_KERBEROS and WITH_GSSAPI. > > > >> > > > >> Regards, > > > >> b. > > > > Could you please test the attached patch. > > > > > > > > Also, if someone who is familiar with the build/Makefile side > > > > of things could review this, it would be appreciated. > > > > > > 1. I would name WITHOUT_KERBEROS to KERBEROS_SUPPORT in the > > > sourcefile > > > and CFLAGS to avoid potential confusion/noise with build logic. > > > > > WITHOUT_KERBEROS is used other places, like telnetd. Were you aware > > of > > that? > > (I just thought it would keep it consistent, but if you think it is > > better > > to use a different name, I don't care.) > > > Oh, I see you were suggesting that the polarity be reversed. Well, > although the #ifndef is a bit ugly, the utility is useless without > Kerberos, so I think I'd rather stick with "enabled by default". > > Also, there is KPROGS in head/kerberos5/Makefile, which is a list > of programs that depend on kerberos. gssd isn't in the list, but > maybe it should be? (And that list is used to "dekerberise" them > by setting -DWITHOUT_KERBEROS.) > > So, unless others feel strongly about it, I think I'd rather stick > with using WITHOUT_KEREBEROS. > Oh, and I've attached the updated patch, rick > rick > > > > 2. This code should be revised per style(9): > > > > > > +#else > > > + fprintf(stderr, "This option not available when built" > > > + " without MK_KERBEROS\n"); > > > + exit(1); > > > > > > In particular: > > > > > > errx(1, "This option requires Kerberos support"); > > > > > > Seems more succinct and addresses the actual item at hand. > > > > > Yea, I'll switch it to errx(). I just cribbed the code further > > down, that used fprintf(). > > > > > 3. This could be simplified as well potentially: > > > > > > +.if ${MK_KERBEROS} != "no" > > > DPADD= ${LIBGSSAPI} ${LIBKRB5} ${LIBHX509} ${LIBASN1} ${LIBROKEN} > > > ${LIBCOM_ERR} ${LIBCRYPT} ${LIBCRYPTO} > > > LDADD= -lgssapi -lkrb5 -lhx509 -lasn1 -lroken -lcom_err -lcrypt > > > -lcrypto > > > +.else > > > +CFLAGS+= -DWITHOUT_KERBEROS > > > +DPADD= ${LIBGSSAPI} > > > +LDADD= -lgssapi > > > +.endif > > > > > > to this: > > > > > > DPADD= ${LIBGSSAPI} > > > LDADD= -lgssapi > > > .if ${MK_KERBEROS} != "no" > > > CFLAGS+= -DKERBEROS_SUPPORT > > > DPADD+= ${LIBKRB5} ${LIBHX509} ${LIBASN1} ${LIBROKEN} > > > ${LIBCOM_ERR} > > > ${LIBCRYPT} ${LIBCRYPTO} > > > LDADD+= -lkrb5 -lhx509 -lasn1 -lroken -lcom_err -lcrypt -lcrypto > > > .endif > > > > > Yea, I can do this change too. I think the latter is more readable. > > > > Thanks, rick > > > > > Thanks! > > > -Garrett > > > _______________________________________________ > > > 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" > > _______________________________________________ > > 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" > _______________________________________________ > 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" ------=_Part_1604360_1467627588.1356956417863 Content-Type: text/x-patch; name=gssd-build.patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=gssd-build.patch LS0tIHVzci5zYmluL2dzc2QvZ3NzZC5jLnNhdjAJMjAxMi0xMi0zMCAxOTowNDoxOS4wMDAwMDAw MDAgLTA1MDAKKysrIHVzci5zYmluL2dzc2QvZ3NzZC5jCTIwMTItMTItMzEgMDc6MDM6MzMuNjE0 NTE2MDAwIC0wNTAwCkBAIC0zNyw3ICszNyw5IEBAIF9fRkJTRElEKCIkRnJlZUJTRDogaGVhZC91 c3Iuc2Jpbi9nc3NkL2cKICNpbmNsdWRlIDxjdHlwZS5oPgogI2luY2x1ZGUgPGRpcmVudC5oPgog I2luY2x1ZGUgPGVyci5oPgorI2lmbmRlZiBXSVRIT1VUX0tFUkJFUk9TCiAjaW5jbHVkZSA8a3Ji NS5oPgorI2VuZGlmCiAjaW5jbHVkZSA8cHdkLmg+CiAjaW5jbHVkZSA8c3RkaW8uaD4KICNpbmNs dWRlIDxzdGRsaWIuaD4KQEAgLTEwMiwxMiArMTA0LDE3IEBAIG1haW4oaW50IGFyZ2MsIGNoYXIg Kiphcmd2KQogCQkJZGVidWdfbGV2ZWwrKzsKIAkJCWJyZWFrOwogCQljYXNlICdzJzoKKyNpZm5k ZWYgV0lUSE9VVF9LRVJCRVJPUwogCQkJLyoKIAkJCSAqIFNldCB0aGUgZGlyZWN0b3J5IHNlYXJj aCBsaXN0LiBUaGlzIGVuYWJsZXMgdXNlIG9mCiAJCQkgKiBmaW5kX2NjYWNoZV9maWxlKCkgdG8g c2VhcmNoIHRoZSBkaXJlY3RvcmllcyBmb3IgYQogCQkJICogc3VpdGFibGUgY3JlZGVudGlhbHMg Y2FjaGUgZmlsZS4KIAkJCSAqLwogCQkJc3RybGNweShjY2ZpbGVfZGlybGlzdCwgb3B0YXJnLCBz aXplb2YoY2NmaWxlX2Rpcmxpc3QpKTsKKyNlbHNlCisJCQllcnJ4KDEsICJUaGlzIG9wdGlvbiBu b3QgYXZhaWxhYmxlIHdoZW4gYnVpbHQiCisJCQkgICAgIiB3aXRob3V0IE1LX0tFUkJFUk9TXG4i KTsKKyNlbmRpZgogCQkJYnJlYWs7CiAJCWNhc2UgJ2MnOgogCQkJLyoKQEAgLTgxNCw2ICs4MjEs NyBAQCBzdGF0aWMgaW50CiBpc19hX3ZhbGlkX3RndF9jYWNoZShjb25zdCBjaGFyICpmaWxlcGF0 aCwgdWlkX3QgdWlkLCBpbnQgKnJldHJhdGluZywKICAgICB0aW1lX3QgKnJldGV4cHRpbWUpCiB7 CisjaWZuZGVmIFdJVEhPVVRfS0VSQkVST1MKIAlrcmI1X2NvbnRleHQgY29udGV4dDsKIAlrcmI1 X3ByaW5jaXBhbCBwcmluYzsKIAlrcmI1X2NjYWNoZSBjY2FjaGU7CkBAIC05MTMsNSArOTIxLDgg QEAgaXNfYV92YWxpZF90Z3RfY2FjaGUoY29uc3QgY2hhciAqZmlsZXBhdAogCQkqcmV0ZXhwdGlt ZSA9IGV4cHRpbWU7CiAJfQogCXJldHVybiAocmV0KTsKKyNlbHNlIC8qIFdJVEhPVVRfS0VSQkVS T1MgKi8KKwlyZXR1cm4gKDApOworI2VuZGlmIC8qICFXSVRIT1VUX0tFUkJFUk9TICovCiB9CiAK LS0tIHVzci5zYmluL2dzc2QvTWFrZWZpbGUuc2F2MAkyMDEyLTEyLTMwIDE5OjE4OjAwLjAwMDAw MDAwMCAtMDUwMAorKysgdXNyLnNiaW4vZ3NzZC9NYWtlZmlsZQkyMDEyLTEyLTMxIDA3OjAyOjQ1 LjAwMDAwMDAwMCAtMDUwMApAQCAtMSw1ICsxLDcgQEAKICMgJEZyZWVCU0Q6IGhlYWQvdXNyLnNi aW4vZ3NzZC9NYWtlZmlsZSAyNDQ2MzggMjAxMi0xMi0yMyAyMDoxMjo1N1ogcm1hY2tsZW0gJAog CisuaW5jbHVkZSA8YnNkLm93bi5taz4KKwogUFJPRz0JZ3NzZAogTUFOPQlnc3NkLjgKIFNSQ1M9 CWdzc2QuYyBnc3NkLmggZ3NzZF9zdmMuYyBnc3NkX3hkci5jIGdzc2RfcHJvdC5jCkBAIC03LDgg KzksMTQgQEAgU1JDUz0JZ3NzZC5jIGdzc2QuaCBnc3NkX3N2Yy5jIGdzc2RfeGRyLgogQ0ZMQUdT Kz0gLUkuCiBXQVJOUz89IDEKIAotRFBBREQ9CSR7TElCR1NTQVBJfSAke0xJQktSQjV9ICR7TElC SFg1MDl9ICR7TElCQVNOMX0gJHtMSUJST0tFTn0gJHtMSUJDT01fRVJSfSAke0xJQkNSWVBUfSAk e0xJQkNSWVBUT30KLUxEQUREPQktbGdzc2FwaSAtbGtyYjUgLWxoeDUwOSAtbGFzbjEgLWxyb2tl biAtbGNvbV9lcnIgLWxjcnlwdCAtbGNyeXB0bworRFBBREQ9CSR7TElCR1NTQVBJfQorTERBREQ9 CS1sZ3NzYXBpCisuaWYgJHtNS19LRVJCRVJPU30gIT0gIm5vIgorRFBBREQrPQkke0xJQktSQjV9 ICR7TElCSFg1MDl9ICR7TElCQVNOMX0gJHtMSUJST0tFTn0gJHtMSUJDT01fRVJSfSAke0xJQkNS WVBUfSAke0xJQkNSWVBUT30KK0xEQUREKz0JLWxrcmI1IC1saHg1MDkgLWxhc24xIC1scm9rZW4g LWxjb21fZXJyIC1sY3J5cHQgLWxjcnlwdG8KKy5lbHNlCitDRkxBR1MrPSAtRFdJVEhPVVRfS0VS QkVST1MKKy5lbmRpZgogCiBDTEVBTkZJTEVTPSBnc3NkX3N2Yy5jIGdzc2QuaAogCg== ------=_Part_1604360_1467627588.1356956417863-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 31 14:33:03 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 03EAB791; Mon, 31 Dec 2012 14:33:03 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id BDBD68FC0C; Mon, 31 Dec 2012 14:33:02 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0MFW00F00GF2QA00@smtpauth1.wiscmail.wisc.edu>; Mon, 31 Dec 2012 08:33:02 -0600 (CST) Received: from wanderer.tachypleus.net (pool-72-66-126-15.washdc.fios.verizon.net [72.66.126.15]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0MFW008FCGEZ2A20@smtpauth1.wiscmail.wisc.edu>; Mon, 31 Dec 2012 08:33:01 -0600 (CST) Date: Mon, 31 Dec 2012 09:32:59 -0500 From: Nathan Whitehorn Subject: Re: svn commit: r244865 - in head: . lib lib/libdisk share/mk In-reply-to: Sender: whitehorn@wisc.edu To: Juli Mallett Message-id: <50E1A21B.5060008@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=72.66.126.15 X-Spam-PmxInfo: Server=avs-16, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.12.31.142119, SenderIP=72.66.126.15 References: <201212301628.qBUGS6tE037193@svn.freebsd.org> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 Cc: svn-src-head@freebsd.org, Adrian Chadd , freebsd-current , src-committers@freebsd.org, svn-src-all@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 31 Dec 2012 14:33:03 -0000 On 12/31/12 00:18, Juli Mallett wrote: > On Sun, Dec 30, 2012 at 6:54 PM, Adrian Chadd wrote: >> .. not that I mind old things being retired, but we really should >> announce things like this. >> >> Also - you disconnected libftpio too; is that intentional? > I would assume so, given that this only removed the static library > name, which nothing else could be using still, seeing as how the > library was disconnected and removed in r225952. > >> Just because libdisk/libftpio isn't used by anything in the base -HEAD >> doesn't mean that: >> >> * it's not used by third party programs in ports; >> * it's not used by any external, non open source utilities that people >> have read. >> >> So I'd suggest creating a port for them both and begin the process of >> deprecating the kernel side interfaces that are unique to this API. > Pretty sure the addition of and widespread use of GEOM things > initiated the deprecation of the really lousy and properly-disliked > kernel interfaces involved. > On a similar note, I am extremely doubtful that any external code used libdisk. It was basically an internal detail of sysinstall with an interface that hadn't worked properly for a lot of applications in a very long time. The only evidence I can find that anyone used it for anything in the last decade is bug reports related to how it makes sysinstall crash in even slightly unusual circumstances. That said, I'm perfectly happy to add it back or make a port or something, but I'd prefer some evidence that it was ever used outside of sysinstall before doing that. I think some of the kernel interfaces (kern.geom.conftxt, for instance) have ended up being used in various shell scripts and so should probably stay. -Nathan -Nathan From owner-freebsd-current@FreeBSD.ORG Mon Dec 31 14:58:24 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7119B288 for ; Mon, 31 Dec 2012 14:58:24 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com [209.85.214.178]) by mx1.freebsd.org (Postfix) with ESMTP id 2D6A88FC0C for ; Mon, 31 Dec 2012 14:58:23 +0000 (UTC) Received: by mail-ob0-f178.google.com with SMTP id eh20so11369269obb.23 for ; Mon, 31 Dec 2012 06:58:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WIlBJnyYsstq/KdsiLcLwWXZMoN+5qwk8lfIqDIr3Ns=; b=tDkXLl6PmBHT2IeaLncQ4O/eoVbE6xnnH34Uw6QNqMlVCGYomoFNPs/rLwLpyq/OYh jjuBk0s1D1x2n2suMxNYlhIutD7wm+sCd5osoGsVbB1jghIa5s5zjkVad8wsUmBSJn8/ kdLVbXz8F0IGRddj+crBkVWLj0XmgYYyT7KAWBloss33FamKNpTFeMYyIQw77BFg+xS6 ZV7xo6mPVb7/H1EWB0mNa+xOo2YnT2X5yCthBp3YCVafn41l6XBURg0FiSZ6WIZmTpm7 zkjoUQRi9J26c/oYOfaHUdYbVAlg7bFYItatOQ5U5Jkkq/OtXKnMJyesSJ3g4vj6mZWl ZkCg== MIME-Version: 1.0 Received: by 10.60.172.164 with SMTP id bd4mr22234475oec.51.1356965896977; Mon, 31 Dec 2012 06:58:16 -0800 (PST) Received: by 10.76.143.33 with HTTP; Mon, 31 Dec 2012 06:58:16 -0800 (PST) In-Reply-To: <1905046872.1604317.1356954929867.JavaMail.root@erie.cs.uoguelph.ca> References: <1905046872.1604317.1356954929867.JavaMail.root@erie.cs.uoguelph.ca> Date: Mon, 31 Dec 2012 06:58:16 -0800 Message-ID: Subject: Re: svn commit: r244604 - head/usr.sbin/gssd From: Garrett Cooper To: Rick Macklem Content-Type: text/plain; charset=ISO-8859-1 Cc: bf1783@gmail.com, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 31 Dec 2012 14:58:24 -0000 On Mon, Dec 31, 2012 at 3:55 AM, Rick Macklem wrote: ... > WITHOUT_KERBEROS is used other places, like telnetd. Were you aware of that? > (I just thought it would keep it consistent, but if you think it is better > to use a different name, I don't care.) Ah, no. I wasn't aware of that :). Given that something else has been standardized around the tree, I agree that your approach of using WITHOUT_KERBEROS is ok. I wasn't keen on the name just because it could have simplified the code using a positive instead of a negative predicate in the #ifdef. I looked at the updated patch and it looks good to me :). Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Dec 31 15:02:56 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2890F3B5; Mon, 31 Dec 2012 15:02:56 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 63D648FC0A; Mon, 31 Dec 2012 15:02:50 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBVF2nlH089212; Mon, 31 Dec 2012 08:02:49 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBVF2iQ3085747; Mon, 31 Dec 2012 08:02:44 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: [RFC/RFT] calloutng From: Ian Lepore To: Alexander Motin In-Reply-To: <50E16637.9070501@FreeBSD.org> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <1356909223.54953.74.camel@revolution.hippie.lan> <20121231061735.GA5866@onelab2.iet.unipi.it> <50E16637.9070501@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" Date: Mon, 31 Dec 2012 08:02:44 -0700 Message-ID: <1356966164.54953.121.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Davide Italiano , freebsd-arch@freebsd.org, FreeBSD Current , Luigi Rizzo , Marius Strobl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 31 Dec 2012 15:02:56 -0000 On Mon, 2012-12-31 at 12:17 +0200, Alexander Motin wrote: > On 31.12.2012 08:17, Luigi Rizzo wrote: > > On Sun, Dec 30, 2012 at 04:13:43PM -0700, Ian Lepore wrote: > > ... > >> I grabbed testsleep.c to test an arm event timer implementation, and had > >> to fix a couple nits... kqueueto was missing from the names[] array, and > >> I had to add a "* 1000" to a couple places where usec was stuffed into a > >> timespec's tv_nsec. > >> > >> I also tested the calloutng_12_17 patches and the kqueue stuff behaved > >> very strangely. > > I've rewritten kqueue timeouts at the calloutng_12_26.patch. > > >> Then I noticed you had a 12_26 patchset so I tested > >> that (after crudely fixing a couple uninitialized var warnings), and it > >> all looks good on this arm (Raspberry Pi). I'll attach the results. > >> > >> It's so sweet to be able to do precision sleeps. > > Thank you for testing, Ian. > > > interesting numbers, but there seems to be some problem in computing > > the exact interval; delays are much larger than expected. > > > > In this test, the original timer code used to round to the next multiple > > of 1 tick and then add another tick (except for the kqueue case), > > which is exactly what you see in the second set of measurements. > > > > The calloutng code however seems to do something odd: > > in addition to fixed overhead (some 50us, which you can see in > > the tests for 1us and 300us), all delay seem to be ~10% larger > > than what is requested, upper bounded to 10ms (note, the > > numbers are averages so i cannot tell whether all samples are > > the same or there is some distribution of values). > > > > I am not sure if this error is peculiar of the ARM version or also > > appears on x86/amd64 but I believe it should be fixed. > > > > If you look at the results below: > > > > 1us possily ok: > > for very short intervals i would expect some kind > > of 'reschedule' without actually firing a timer; maybe > > 50us are what it takes to do a round through the scheduler ? > > > > 300us probably ok > > i guess the extra 50-90us are what it takes to do a round > > through the scheduler > > > > 1000us borderline (this is the case for poll and kqueue, which are > > rounded to 1ms) > > here intervals seem to be increased by 10%, and i cannot see > > a good reason for this (more below). > > > > 3000us and above: wrong > > here again, the intervals seem to be 10% larger than what is > > requested, perhaps limiting the error to 10-20ms. > > > > > > Maybe the 10% extension results from creating a default 'precision' > > for legacy calls, but i do not think this is done correctly. > > > > First of all, if users do not specify a precision themselves, the > > automatically generated value should never exceed one tick. > > > > Second, the only point of a 'precision' parameter is to merge > > requests that may be close in time, so if there is already a > > timer scheduled within [Treq, Treq+precision] i will get it; > > but if there no pending timer, then one should schedule it > > for the requested interval. > > > > Davide/Alexander, any ideas ? > > All mentioned effects could be explained with implemented logic. 50us at > 1us is probably sum of minimal latency of the hardware eventtimer on the > specific platform and some software processing overhead (syscall, > callout, timecouters, scheduler, etc). At later points system starts to > noticeably use precision specified by kern.timecounter.alloweddeviation > sysctl. It affects results from two sides: 1) extending intervals for > specified percent of time to allow event aggregation, and 2) choosing > time base between fast getbinuptime() and precise binuptime(). Extending > interval is needed to aggregate not only callouts with each other, but > also callouts with other system events, which are impossible to schedule > in advance. It gives specified relative error, but no more then one CPU > wakeup period in absolute: for busy CPU (not skipping hardclock() ticks) > it is 1/hz, for completely idle one it can be up to 0.5s. Second point > allows to reduce processing overhead by the cost of error up to 1/hz for > long periods (>(100/allowed)*(1/hz)), when it is used. > > To get best possible precision kern.timecounter.alloweddeviation sysctl > can be set to smaller value. Setting it to 0 will effectively disable > all optimizations, but should give 50us precision in all cases. > > >> for t in 1 300 3000 30000 300000 ; do > >> for m in select poll usleep nanosleep kqueue kqueueto syscall ; do > >> ./testsleep $t $m > >> done > >> done > >> > >> [test results snipped] > I should have posted some information about the test platform... It's a single-processor 700mhz arm chip. There was essentially nothing else running during the tests other than mostly-idle daemons (sshd, ntpd, the usual suspects). Kernel debugging options off (INVARIANTS[_SUPPORT], DIAGNOSTIC, and WITNESS). Some sysctl values of interest... rpi# sysctl kern.timecounter kern.timecounter.fast_gettime: 1 kern.timecounter.tick: 1 kern.timecounter.choice: BCM2835 Timecounter(1000) dummy(-1000000) kern.timecounter.hardware: BCM2835 Timecounter kern.timecounter.alloweddeviation: 5 kern.timecounter.stepwarnings: 1 kern.timecounter.tc.BCM2835 Timecounter.mask: 4294967295 kern.timecounter.tc.BCM2835 Timecounter.counter: 734706756 kern.timecounter.tc.BCM2835 Timecounter.frequency: 1000000 kern.timecounter.tc.BCM2835 Timecounter.quality: 1000 rpi# sysctl kern.eventtimer kern.eventtimer.choice: BCM2835 Event Timer 3(1000) kern.eventtimer.et.BCM2835 Event Timer 3.flags: 2 kern.eventtimer.et.BCM2835 Event Timer 3.frequency: 1000000 kern.eventtimer.et.BCM2835 Event Timer 3.quality: 1000 kern.eventtimer.periodic: 0 kern.eventtimer.timer: BCM2835 Event Timer 3 kern.eventtimer.activetick: 1 kern.eventtimer.idletick: 0 kern.eventtimer.singlemul: 4 BTW, is there any advantage to implementing periodic mode for an eventtimer? It would be easy enough to do for this hardware, but it looks like all this new event timer code is pretty much a stake through the heart of periodic timer ticks. -- Ian From owner-freebsd-current@FreeBSD.ORG Mon Dec 31 15:41:55 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3FEDBBC; Mon, 31 Dec 2012 15:41:55 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ea0-f180.google.com (mail-ea0-f180.google.com [209.85.215.180]) by mx1.freebsd.org (Postfix) with ESMTP id BC9F58FC0A; Mon, 31 Dec 2012 15:41:54 +0000 (UTC) Received: by mail-ea0-f180.google.com with SMTP id f13so4898631eai.25 for ; Mon, 31 Dec 2012 07:41:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ytQzY76ftkiIspE7Hu+QwblRBnbzQQJtZbgSK0k+nSI=; b=iDk2W4a1kJQjwisGyA8v+RYJ18RWJl/ww+eWkSCRMY0ZszbUIgKpiQ3MJSVE3yUPm9 2PjnYgr2q4oKBd4prkUxxRPGUOvwfMpEpcGpFKeu5QIcxgAjafk1uXNkXotiBUl4IKxW eWmeDsq+lSwv1TcUJwBrB0LTI4fxqQKlPtar3V7mtmDCy2Q+LlUzQEB/hIKbKcmK89qU xazJuPNR0TBBf/DXVjriCYOZrwmrp2I+UW6W5dHb6bZ+sh4NIESCEjSVZOHhcNoqRl6l dDjOLBV494WfVNZ+6qOq6Ld0ebNqy1M3AgZHUnygD//B3hDbanAcdDhn9OknRuGpertr XkIg== X-Received: by 10.14.173.65 with SMTP id u41mr110983401eel.13.1356968513616; Mon, 31 Dec 2012 07:41:53 -0800 (PST) Received: from mavbook.mavhome.dp.ua ([91.198.175.1]) by mx.google.com with ESMTPS id f49sm85749799eep.12.2012.12.31.07.41.51 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 31 Dec 2012 07:41:52 -0800 (PST) Sender: Alexander Motin Message-ID: <50E1B23C.6060804@FreeBSD.org> Date: Mon, 31 Dec 2012 17:41:48 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Ian Lepore Subject: Re: [RFC/RFT] calloutng References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <1356909223.54953.74.camel@revolution.hippie.lan> <20121231061735.GA5866@onelab2.iet.unipi.it> <50E16637.9070501@FreeBSD.org> <1356966164.54953.121.camel@revolution.hippie.lan> In-Reply-To: <1356966164.54953.121.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Davide Italiano , freebsd-arch@freebsd.org, FreeBSD Current , Luigi Rizzo , Marius Strobl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 31 Dec 2012 15:41:55 -0000 On 31.12.2012 17:02, Ian Lepore wrote: > On Mon, 2012-12-31 at 12:17 +0200, Alexander Motin wrote: >> On 31.12.2012 08:17, Luigi Rizzo wrote: >>> On Sun, Dec 30, 2012 at 04:13:43PM -0700, Ian Lepore wrote: >>> ... >>>> I grabbed testsleep.c to test an arm event timer implementation, and had >>>> to fix a couple nits... kqueueto was missing from the names[] array, and >>>> I had to add a "* 1000" to a couple places where usec was stuffed into a >>>> timespec's tv_nsec. >>>> >>>> I also tested the calloutng_12_17 patches and the kqueue stuff behaved >>>> very strangely. >> >> I've rewritten kqueue timeouts at the calloutng_12_26.patch. >> >>>> Then I noticed you had a 12_26 patchset so I tested >>>> that (after crudely fixing a couple uninitialized var warnings), and it >>>> all looks good on this arm (Raspberry Pi). I'll attach the results. >>>> >>>> It's so sweet to be able to do precision sleeps. >> >> Thank you for testing, Ian. >> >>> interesting numbers, but there seems to be some problem in computing >>> the exact interval; delays are much larger than expected. >>> >>> In this test, the original timer code used to round to the next multiple >>> of 1 tick and then add another tick (except for the kqueue case), >>> which is exactly what you see in the second set of measurements. >>> >>> The calloutng code however seems to do something odd: >>> in addition to fixed overhead (some 50us, which you can see in >>> the tests for 1us and 300us), all delay seem to be ~10% larger >>> than what is requested, upper bounded to 10ms (note, the >>> numbers are averages so i cannot tell whether all samples are >>> the same or there is some distribution of values). >>> >>> I am not sure if this error is peculiar of the ARM version or also >>> appears on x86/amd64 but I believe it should be fixed. >>> >>> If you look at the results below: >>> >>> 1us possily ok: >>> for very short intervals i would expect some kind >>> of 'reschedule' without actually firing a timer; maybe >>> 50us are what it takes to do a round through the scheduler ? >>> >>> 300us probably ok >>> i guess the extra 50-90us are what it takes to do a round >>> through the scheduler >>> >>> 1000us borderline (this is the case for poll and kqueue, which are >>> rounded to 1ms) >>> here intervals seem to be increased by 10%, and i cannot see >>> a good reason for this (more below). >>> >>> 3000us and above: wrong >>> here again, the intervals seem to be 10% larger than what is >>> requested, perhaps limiting the error to 10-20ms. >>> >>> >>> Maybe the 10% extension results from creating a default 'precision' >>> for legacy calls, but i do not think this is done correctly. >>> >>> First of all, if users do not specify a precision themselves, the >>> automatically generated value should never exceed one tick. >>> >>> Second, the only point of a 'precision' parameter is to merge >>> requests that may be close in time, so if there is already a >>> timer scheduled within [Treq, Treq+precision] i will get it; >>> but if there no pending timer, then one should schedule it >>> for the requested interval. >>> >>> Davide/Alexander, any ideas ? >> >> All mentioned effects could be explained with implemented logic. 50us at >> 1us is probably sum of minimal latency of the hardware eventtimer on the >> specific platform and some software processing overhead (syscall, >> callout, timecouters, scheduler, etc). At later points system starts to >> noticeably use precision specified by kern.timecounter.alloweddeviation >> sysctl. It affects results from two sides: 1) extending intervals for >> specified percent of time to allow event aggregation, and 2) choosing >> time base between fast getbinuptime() and precise binuptime(). Extending >> interval is needed to aggregate not only callouts with each other, but >> also callouts with other system events, which are impossible to schedule >> in advance. It gives specified relative error, but no more then one CPU >> wakeup period in absolute: for busy CPU (not skipping hardclock() ticks) >> it is 1/hz, for completely idle one it can be up to 0.5s. Second point >> allows to reduce processing overhead by the cost of error up to 1/hz for >> long periods (>(100/allowed)*(1/hz)), when it is used. >> >> To get best possible precision kern.timecounter.alloweddeviation sysctl >> can be set to smaller value. Setting it to 0 will effectively disable >> all optimizations, but should give 50us precision in all cases. >> >>>> for t in 1 300 3000 30000 300000 ; do >>>> for m in select poll usleep nanosleep kqueue kqueueto syscall ; do >>>> ./testsleep $t $m >>>> done >>>> done >>>> >>>> [test results snipped] >> > > I should have posted some information about the test platform... It's a > single-processor 700mhz arm chip. There was essentially nothing else > running during the tests other than mostly-idle daemons (sshd, ntpd, the > usual suspects). Kernel debugging options off (INVARIANTS[_SUPPORT], > DIAGNOSTIC, and WITNESS). > > Some sysctl values of interest... > > rpi# sysctl kern.timecounter > kern.timecounter.fast_gettime: 1 > kern.timecounter.tick: 1 > kern.timecounter.choice: BCM2835 Timecounter(1000) dummy(-1000000) > kern.timecounter.hardware: BCM2835 Timecounter > kern.timecounter.alloweddeviation: 5 > kern.timecounter.stepwarnings: 1 > kern.timecounter.tc.BCM2835 Timecounter.mask: 4294967295 > kern.timecounter.tc.BCM2835 Timecounter.counter: 734706756 > kern.timecounter.tc.BCM2835 Timecounter.frequency: 1000000 > kern.timecounter.tc.BCM2835 Timecounter.quality: 1000 > rpi# sysctl kern.eventtimer > kern.eventtimer.choice: BCM2835 Event Timer 3(1000) > kern.eventtimer.et.BCM2835 Event Timer 3.flags: 2 > kern.eventtimer.et.BCM2835 Event Timer 3.frequency: 1000000 > kern.eventtimer.et.BCM2835 Event Timer 3.quality: 1000 > kern.eventtimer.periodic: 0 > kern.eventtimer.timer: BCM2835 Event Timer 3 > kern.eventtimer.activetick: 1 > kern.eventtimer.idletick: 0 > kern.eventtimer.singlemul: 4 > > BTW, is there any advantage to implementing periodic mode for an > eventtimer? It would be easy enough to do for this hardware, but it > looks like all this new event timer code is pretty much a stake through > the heart of periodic timer ticks. Periodic-mode-only hardware is still supported, but present code takes almost no advantage from periodic mode if one-shot mode is supported. It can't use interrupts as time source to run events (as legacy code did) because of possible drift from system timecounter that makes impossible to specify absolute event time. The only benefit is that timer hardware is not reprogrammed each time, and I don't think that this economy worth result. But for all hardware supporting periodic mode I've implemented respective support at least for completeness and testing purposes. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Dec 31 21:29:56 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B95A55C; Mon, 31 Dec 2012 21:29:56 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 0E2F58FC0C; Mon, 31 Dec 2012 21:29:52 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qBVLTjla043052; Mon, 31 Dec 2012 16:29:45 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qBVLTjgD043035; Mon, 31 Dec 2012 21:29:45 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 31 Dec 2012 21:29:45 GMT Message-Id: <201212312129.qBVLTjgD043035@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips64/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 21:29:56 -0000 TB --- 2012-12-31 20:28:08 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2012-12-31 20:28:08 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-31 20:28:08 - starting HEAD tinderbox run for mips64/mips TB --- 2012-12-31 20:28:08 - cleaning the object tree TB --- 2012-12-31 20:28:08 - /usr/local/bin/svn stat /src TB --- 2012-12-31 20:28:11 - At svn revision 244906 TB --- 2012-12-31 20:28:12 - building world TB --- 2012-12-31 20:28:12 - CROSS_BUILD_TESTING=YES TB --- 2012-12-31 20:28:12 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-31 20:28:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-31 20:28:12 - SRCCONF=/dev/null TB --- 2012-12-31 20:28:12 - TARGET=mips TB --- 2012-12-31 20:28:12 - TARGET_ARCH=mips64 TB --- 2012-12-31 20:28:12 - TZ=UTC TB --- 2012-12-31 20:28:12 - __MAKE_CONF=/dev/null TB --- 2012-12-31 20:28:12 - cd /src TB --- 2012-12-31 20:28:12 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Dec 31 20:28:16 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Dec 31 21:29:27 UTC 2012 TB --- 2012-12-31 21:29:27 - cd /src/sys/mips/conf TB --- 2012-12-31 21:29:27 - /usr/sbin/config -m ADM5120 TB --- 2012-12-31 21:29:28 - skipping ADM5120 kernel TB --- 2012-12-31 21:29:28 - cd /src/sys/mips/conf TB --- 2012-12-31 21:29:28 - /usr/sbin/config -m ALCHEMY TB --- 2012-12-31 21:29:28 - skipping ALCHEMY kernel TB --- 2012-12-31 21:29:28 - cd /src/sys/mips/conf TB --- 2012-12-31 21:29:28 - /usr/sbin/config -m AP91 TB --- 2012-12-31 21:29:28 - skipping AP91 kernel TB --- 2012-12-31 21:29:28 - cd /src/sys/mips/conf TB --- 2012-12-31 21:29:28 - /usr/sbin/config -m AP93 TB --- 2012-12-31 21:29:28 - skipping AP93 kernel TB --- 2012-12-31 21:29:28 - cd /src/sys/mips/conf TB --- 2012-12-31 21:29:28 - /usr/sbin/config -m AP94 TB --- 2012-12-31 21:29:28 - skipping AP94 kernel TB --- 2012-12-31 21:29:28 - cd /src/sys/mips/conf TB --- 2012-12-31 21:29:28 - /usr/sbin/config -m AP96 TB --- 2012-12-31 21:29:28 - skipping AP96 kernel TB --- 2012-12-31 21:29:28 - cd /src/sys/mips/conf TB --- 2012-12-31 21:29:28 - /usr/sbin/config -m AR71XX_BASE TB --- 2012-12-31 21:29:28 - skipping AR71XX_BASE kernel TB --- 2012-12-31 21:29:28 - cd /src/sys/mips/conf TB --- 2012-12-31 21:29:28 - /usr/sbin/config -m AR724X_BASE TB --- 2012-12-31 21:29:28 - skipping AR724X_BASE kernel TB --- 2012-12-31 21:29:28 - cd /src/sys/mips/conf TB --- 2012-12-31 21:29:28 - /usr/sbin/config -m AR91XX_BASE TB --- 2012-12-31 21:29:28 - skipping AR91XX_BASE kernel TB --- 2012-12-31 21:29:28 - cd /src/sys/mips/conf TB --- 2012-12-31 21:29:28 - /usr/sbin/config -m BERI_DE4_MDROOT TB --- 2012-12-31 21:29:28 - building BERI_DE4_MDROOT kernel TB --- 2012-12-31 21:29:28 - CROSS_BUILD_TESTING=YES TB --- 2012-12-31 21:29:28 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-31 21:29:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-31 21:29:28 - SRCCONF=/dev/null TB --- 2012-12-31 21:29:28 - TARGET=mips TB --- 2012-12-31 21:29:28 - TARGET_ARCH=mips64 TB --- 2012-12-31 21:29:28 - TZ=UTC TB --- 2012-12-31 21:29:28 - __MAKE_CONF=/dev/null TB --- 2012-12-31 21:29:28 - cd /src TB --- 2012-12-31 21:29:28 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_MDROOT >>> Kernel build for BERI_DE4_MDROOT started on Mon Dec 31 21:29:28 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/kern/linker_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/kern/serdev_if.m -h rm -f .newdep /obj/src/make.amd64/make -V CFILES_NOZFS -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/cxgb -I/src/sys/dev/cxgbe -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=mips64 -mabi=64 -msoft-float -ffreestanding In file included from /src/sys/dev/fdt/fdt_common.h:37, from /src/sys/mips/beri/beri_machdep.c:58: /src/sys/dev/ofw/ofw_bus.h:36:24: error: ofw_bus_if.h: No such file or directory mkdep: compile failed *** [.depend] Error code 1 Stop in /obj/mips.mips64/src/sys/BERI_DE4_MDROOT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-31 21:29:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-31 21:29:45 - ERROR: failed to build BERI_DE4_MDROOT kernel TB --- 2012-12-31 21:29:45 - 2683.89 user 597.55 system 3696.86 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-mips64-mips.full From owner-freebsd-current@FreeBSD.ORG Mon Dec 31 23:25:20 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED9E9779; Mon, 31 Dec 2012 23:25:20 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id AAC658FC0A; Mon, 31 Dec 2012 23:25:20 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id qBVNPJ4V016683; Mon, 31 Dec 2012 23:25:19 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id w2fch3ceeq2n6n7t94dp8t2kqn; Mon, 31 Dec 2012 23:25:19 +0000 (UTC) (envelope-from kientzle@freebsd.org) From: Tim Kientzle Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: CFT: Overhauled CPSW driver for BeagleBone Date: Mon, 31 Dec 2012 15:25:15 -0800 Message-Id: <53026BDB-88DA-4869-99B3-B63D34667451@freebsd.org> To: freebsd-arm@freebsd.org, freebsd-current Current Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 31 Dec 2012 23:25:21 -0000 I've made some progress reworking the CPSW driver for BeagleBone and would appreciate any feedback: https://github.com/kientzle/cpsw I believe I've resolved the most pressing stability problems; the driver properly survives cables being unplugged and replugged, modules being loaded and unloaded while the network is busy, etc. The most obvious remaining issue: TX interrupts still just stop occasionally. But the watchdog now consistently detects and resets everything within a few seconds, so that's much less of a headache. I hope to commit this to FreeBSD-CURRENT within the week. Tim