From owner-freebsd-current@FreeBSD.ORG Sun Aug 4 00:10:46 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EEE97275; Sun, 4 Aug 2013 00:10:46 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B35DE2311; Sun, 4 Aug 2013 00:10:46 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.6/8.14.6) with ESMTP id r740Aj95001524; Sat, 3 Aug 2013 17:10:45 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.6/8.14.6/Submit) id r740AjPg001523; Sat, 3 Aug 2013 17:10:45 -0700 (PDT) (envelope-from sgk) Date: Sat, 3 Aug 2013 17:10:45 -0700 From: Steve Kargl To: Glen Barber Subject: Re: svn error during 'make buildkernel'? Message-ID: <20130804001045.GA1500@troutmask.apl.washington.edu> References: <20130803210348.GA715@troutmask.apl.washington.edu> <20130803210858.GJ78299@glenbarber.us> <20130803213023.GA812@troutmask.apl.washington.edu> <20130803214313.GL78299@glenbarber.us> <20130803221702.GA979@troutmask.apl.washington.edu> <20130803222047.GN78299@glenbarber.us> <20130803224608.GA1150@troutmask.apl.washington.edu> <20130803224719.GP78299@glenbarber.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130803224719.GP78299@glenbarber.us> 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, 04 Aug 2013 00:10:47 -0000 On Sat, Aug 03, 2013 at 06:47:19PM -0400, Glen Barber wrote: > On Sat, Aug 03, 2013 at 03:46:08PM -0700, Steve Kargl wrote: > > On Sat, Aug 03, 2013 at 06:20:47PM -0400, Glen Barber wrote: > > > On Sat, Aug 03, 2013 at 03:17:02PM -0700, Steve Kargl wrote: > > > > > > > > BTW, you should upgrade devel/subversion anyway, since there are > > > > > security vulnerabilities. > > > > > > > > 1.7.9 works/worked fine for updating my /usr/src and my personal > > > > svn repository. The change to use svnlite in newvers.sh should > > > > have an entry in UPDATING to alert users that have a too old > > > > svn port that they need to upgrade. I go as far to suggest that > > > > that the script should look for svn in the path before it looks > > > > for svnlite. > > > > > > I cannot differentiate what version of svn is used to check out the > > > tree. When in doubt, software in base wins, IMHO. > > > > You don't need to differentiate anything. devel/subversion > > installs svnversion. svnversion simply needs to be in $PATH. > > If newvers.sh can't find svnversion in $PATH, then it can fall > > back to /usr/bin/svnliteversion. The install svnversion from > > devel/subversion will in all likelihood be consistent with the > > svn used to checkout/update /usr/src. > > > > No, because you can set WITH_SVN=1 in src.conf, and svnlite will install > as svn. If someone set WITH_SVN=1, then more than likely she has already checked out/upgraded a /usr/src with the newly anointed 1.8.0 and she has de-installed devel/subversion. So, newsver.sh looks for svnversion in $PATH. It will find svnversion from the WITH_SVN=1 setting, the svnversion from devel/subversion in $PATH, or no svnversion. If it can't find a svnversion at all, the script falls back to looking for a svnliteversion. If the script can't find svnversion or svnliteversion, then it issues an error. -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Aug 4 00:53:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A5E15729; Sun, 4 Aug 2013 00:53:38 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [IPv6:2607:fc50:1:2300:1001:1001:1001:face]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 77BDB2450; Sun, 4 Aug 2013 00:53:38 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 113F98270; Sun, 4 Aug 2013 00:53:36 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 113F98270 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Sat, 3 Aug 2013 20:53:35 -0400 From: Glen Barber To: Steve Kargl Subject: Re: svn error during 'make buildkernel'? Message-ID: <20130804005335.GQ78299@glenbarber.us> References: <20130803210348.GA715@troutmask.apl.washington.edu> <20130803210858.GJ78299@glenbarber.us> <20130803213023.GA812@troutmask.apl.washington.edu> <20130803214313.GL78299@glenbarber.us> <20130803221702.GA979@troutmask.apl.washington.edu> <20130803222047.GN78299@glenbarber.us> <20130803224608.GA1150@troutmask.apl.washington.edu> <20130803224719.GP78299@glenbarber.us> <20130804001045.GA1500@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="v+Mbu5iuT/5Blw/K" Content-Disposition: inline In-Reply-To: <20130804001045.GA1500@troutmask.apl.washington.edu> X-Operating-System: FreeBSD 10.0-CURRENT amd64 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, 04 Aug 2013 00:53:38 -0000 --v+Mbu5iuT/5Blw/K Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 03, 2013 at 05:10:45PM -0700, Steve Kargl wrote: > If the script can't find svnversion or svnliteversion, > then it issues an error. >=20 *sigh* No. It is *not* a fatal error. Glen --v+Mbu5iuT/5Blw/K Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBCAAGBQJR/aYPAAoJEFJPDDeguUajDZwIAJN9uxhgbzWBkMAge1/U5Wjb VM1RkcsjlBV/8w3C/H2uKZ+NCKFib8V4D+tibCwF/nOn2NggWSUBVBxxKW1JjM4/ FBfsuf8v3hw5Wl7tqJD+/WybMuiqRVaAGgekhgBWipphVViafma8cWRR2MbSrghs ge+BoY8/6VXV+e/5u3mt5wlcW1iATEddQ4TIlHmJjYMAwTIv8ox/R3Ab/wwxxNbM ym0w6m0bmkzFQ1El98arMyd41QuAfK4RX7kb33/2YHyOs3qIiU9YWpLVxrlw/718 MWNB9nIXTzxUv1YSUSzb8XaJh1oUP8+izu26AQ0xSu54iA1ULb/qQ+0In9rObGU= =IPJb -----END PGP SIGNATURE----- --v+Mbu5iuT/5Blw/K-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 4 02:05:00 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 35DADEC8; Sun, 4 Aug 2013 02:05:00 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0A6A1269E; Sun, 4 Aug 2013 02:04:59 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 225768910; Sun, 4 Aug 2013 02:04:58 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 225768910 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Sat, 3 Aug 2013 22:04:56 -0400 From: Glen Barber To: Erich Dollansky Subject: Re: svn error during 'make buildkernel'? Message-ID: <20130804020456.GS78299@glenbarber.us> References: <20130803210348.GA715@troutmask.apl.washington.edu> <20130803210858.GJ78299@glenbarber.us> <20130803213023.GA812@troutmask.apl.washington.edu> <20130803214313.GL78299@glenbarber.us> <20130803221702.GA979@troutmask.apl.washington.edu> <20130804081009.257c5801@X220.ovitrap.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2/Dpz40iF3jpiHxF" Content-Disposition: inline In-Reply-To: <20130804081009.257c5801@X220.ovitrap.com> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, Steve Kargl 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, 04 Aug 2013 02:05:00 -0000 --2/Dpz40iF3jpiHxF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Aug 04, 2013 at 08:10:09AM +0800, Erich Dollansky wrote: > doesn't this show again that svn came a bit early? No, it shows that people do not keep their third-party software up to date. Glen --2/Dpz40iF3jpiHxF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBCAAGBQJR/bbIAAoJEFJPDDeguUajbHUH/iWNX2CnIVu5QEM4bh1U7fh+ IshYKTF86JU3VSwZW3tdqc5PX82SyrjZiqzoG6ESd3wEtsOiRB0SaOAPSLhMwX9B 227UOxzkWIJQMfkKE5NyL8xnxce4bS969r/XHmCfEOMKbTtxVirrG2tGc71Hh+sA J3kaKWXb9krQOHg3YYK0J3notg56QKxxxk1QbB/DWnni4Xn8xdOV+8OOyIWi41UU CkKqEfhgPYef+xsUtVuR7jJ7of3TgEyML5dHNJkhE0OXICvHxitNBojeJxL6wwsi ChFEltgvoK+ojWKISoqoEfJTJKZEowTwzSLF0YD1IvXQvJl0jT8ZKOwnUqNsZZY= =wEvH -----END PGP SIGNATURE----- --2/Dpz40iF3jpiHxF-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 4 04:17:39 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 74A08F15; Sun, 4 Aug 2013 04:17:39 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qe0-x22a.google.com (mail-qe0-x22a.google.com [IPv6:2607:f8b0:400d:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 195F82AE2; Sun, 4 Aug 2013 04:17:39 +0000 (UTC) Received: by mail-qe0-f42.google.com with SMTP id s14so1138157qeb.1 for ; Sat, 03 Aug 2013 21:17:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=6aBHD11gnhYcvGCTTJpWe0i2EkeCn17FQTeGF/iUJ48=; b=iE3F1mTU5u1mbgKIBierrvLZNNlg/90PVlw1+s8qpVDavlfUHnamvZ4aVJFk1HtzWz WTPbduEhGia4njYcHZkSgd25CG0pCxgcw5BFKjeDxK37Tvl0tIoU/2ljRPT++Qk/UdH4 m7YgnlgNojbN1O45snLKS3/OSqotDphmuNJp0vfGn/r/eHbEBg5q90uDBYe9AkrrO7xZ eM8znBbLHHIqKg4rAOPEy7j8on6Y2EhPC6yISwRsA1TRxHnGTe1ydeTptiRmBybnIibg 0v+Ek38KQa6JhwJ03GIvRoKORo890iIhajCPO1dKhnb5GcsKb1QsMZfxNEvBLBsNyBD6 Na/Q== X-Received: by 10.224.45.138 with SMTP id e10mr21231074qaf.47.1375589857869; Sat, 03 Aug 2013 21:17:37 -0700 (PDT) Received: from raichu (24-212-218-13.cable.teksavvy.com. [24.212.218.13]) by mx.google.com with ESMTPSA id w2sm3968351qec.8.2013.08.03.21.17.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 03 Aug 2013 21:17:37 -0700 (PDT) Sender: Mark Johnston Date: Sun, 4 Aug 2013 00:17:34 -0400 From: Mark Johnston To: Konstantin Belousov Subject: Re: ldd runs linux programs Message-ID: <20130804041734.GB3259@raichu> References: <20130728193110.GB17514@gpr.nnz-home.ru> <20130728204958.GA32322@dft-labs.eu> <51F5D491.1080803@freebsd.org> <20130729081254.GB32322@dft-labs.eu> <20130729155625.GA2544@charmander> <20130729205449.GA6007@dft-labs.eu> <20130801021231.GA58998@raichu> <20130801133935.GT4972@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130801133935.GT4972@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Gennady Proskurin , Mateusz Guzik , 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, 04 Aug 2013 04:17:39 -0000 On Thu, Aug 01, 2013 at 04:39:35PM +0300, Konstantin Belousov wrote: > On Wed, Jul 31, 2013 at 10:12:31PM -0400, Mark Johnston wrote: > > On Mon, Jul 29, 2013 at 10:54:49PM +0200, Mateusz Guzik wrote: > > > On Mon, Jul 29, 2013 at 11:56:25AM -0400, Mark Johnston wrote: > > > > > 127276 suggests running the binary as is (which I don't like) and > > > > > achieves this with a hacky way. So if we really want to do this, the > > > > > patch should be reworked to detect Linux binaries properly. > > > > > > > > > > In general we should gain linux_ldd (like linux_kdump) and our ldd > > > > > should work only on FreeBSD binaries. The last part is achieved with my > > > > > patch. > > > > > > > > > > markj, are you working on this? > > > > > > > > Not really; my original fix for this problem was essentially the same as > > > > yours. That is, just change ldd(1) to bail if the OS ABI byte isn't > > > > equal to ELFOSABI_FREEBSD. That's the change I have committed in my > > > > local tree right now. > > > > > > > > Then I thought I'd try to get ldd to work properly with Linux binaries > > > > as well, but wasn't sure what the right approach should be. As the above > > > > PR suggests, the easy thing to do is to just pass > > > > LD_TRACE_LOADED_OBJECTS and not LD_32_TRACE_LOADED_OBJECTS for 32-bit > > > > ELF objects if the OS isn't FreeBSD. This feels somewhat hacky to me, > > > > but I didn't really see another approach. > > > > > > > > That said, I think your patch should be committed since it's clearly an > > > > improvement over the current behaviour. I'm willing to test and commit > > > > it, and clean up the open PRs. If you could expand on the right way to > > > > handle Linux binaries, I'd be willing to implement and commit that too. > > > > I don't quite understand your reference to linux_kdump though - I have > > > > no such program on my laptop running CURRENT, and ktrace+kdump seem to > > > > work fine with the Linux binaries under /compat/linux. > > > > > > > > > > Well, there was linux_kdump in ports but it apparently got obsolete as > > > necessary support for included in our regular kdump. > > > > > > So it may make sense to teach our ldd how to deal with Linux binaries > > > for consistency, but its unclear for me if this is better than providing > > > linux_ldd. Also there is the problem of (not) appending /compat/linux to > > > printed paths (for Linux binaries the kernel performs file lookups against > > > /compat/linux first). I'm not that interested in this problem though. :P > > > > What do you think of the patch below, which just sets both variables in > > the compat case? It's somewhat less intrusive than the patch in the PR. > > If that's no good then I'll just commit your original patch; I really > > just want to fix the fact that the example pipeline in the ldd(1) man > > page starts a GTK program (some Adobe Flash thingy to be specific) when > > run in /usr/local/bin on my desktop machine. :) > > > > [snip] > > I do not understand this COMPAT_32BIT business in ldd(1). Its only > application seems to preventing ldd 32bit binary from amd64 host to > work on i386 ? > > IMO, both LD_TRACE and LD_32_TRACE should be passed unconditionally > always. I do not see any harm of doing this. I spent some time trying to figure out if there was any reason for this and didn't come up with anything. Does the patch below look ok? It just adds a couple of macros to set both the native and 32-bit compat variable. It works properly for me for 32-bit, native, and (32-bit) Linux executables and shared libs on an amd64 machine. diff --git a/usr.bin/ldd/ldd.c b/usr.bin/ldd/ldd.c index 00c8797..39f38e8 100644 --- a/usr.bin/ldd/ldd.c +++ b/usr.bin/ldd/ldd.c @@ -49,12 +49,6 @@ __FBSDID("$FreeBSD$"); #include "extern.h" -#ifdef COMPAT_32BIT -#define LD_ "LD_32_" -#else -#define LD_ "LD_" -#endif - /* * 32-bit ELF data structures can only be used if the system header[s] declare * them. There is no official macro for determining whether they are declared, @@ -76,13 +70,23 @@ static void usage(void); #define _PATH_LDD32 "/usr/bin/ldd32" +#define LDD_SETENV(name, value, overwrite) do { \ + setenv("LD_" name, value, overwrite); \ + setenv("LD_32_" name, value, overwrite); \ +} while (0) + +#define LDD_UNSETENV(name) do { \ + unsetenv("LD_" name); \ + unsetenv("LD_32_" name); \ +} while (0) + static int execldd32(char *file, char *fmt1, char *fmt2, int aflag, int vflag) { char *argv[8]; int i, rval, status; - unsetenv(LD_ "TRACE_LOADED_OBJECTS"); + LDD_UNSETENV("TRACE_LOADED_OBJECTS"); rval = 0; i = 0; argv[i++] = strdup(_PATH_LDD32); @@ -121,7 +125,7 @@ execldd32(char *file, char *fmt1, char *fmt2, int aflag, int vflag) } while (i--) free(argv[i]); - setenv(LD_ "TRACE_LOADED_OBJECTS", "yes", 1); + LDD_SETENV("TRACE_LOADED_OBJECTS", "yes", 1); return (rval); } #endif @@ -210,15 +214,15 @@ main(int argc, char *argv[]) } /* ld.so magic */ - setenv(LD_ "TRACE_LOADED_OBJECTS", "yes", 1); + LDD_SETENV("TRACE_LOADED_OBJECTS", "yes", 1); if (fmt1 != NULL) - setenv(LD_ "TRACE_LOADED_OBJECTS_FMT1", fmt1, 1); + LDD_SETENV("TRACE_LOADED_OBJECTS_FMT1", fmt1, 1); if (fmt2 != NULL) - setenv(LD_ "TRACE_LOADED_OBJECTS_FMT2", fmt2, 1); + LDD_SETENV("TRACE_LOADED_OBJECTS_FMT2", fmt2, 1); - setenv(LD_ "TRACE_LOADED_OBJECTS_PROGNAME", *argv, 1); + LDD_SETENV("TRACE_LOADED_OBJECTS_PROGNAME", *argv, 1); if (aflag) - setenv(LD_ "TRACE_LOADED_OBJECTS_ALL", "1", 1); + LDD_SETENV("TRACE_LOADED_OBJECTS_ALL", "1", 1); else if (fmt1 == NULL && fmt2 == NULL) /* Default formats */ printf("%s:\n", *argv); From owner-freebsd-current@FreeBSD.ORG Sun Aug 4 04:19:45 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9DBDA101; Sun, 4 Aug 2013 04:19:45 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 61C632B08; Sun, 4 Aug 2013 04:19:45 +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 r744Ji4q053749; Sun, 4 Aug 2013 00:19:44 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r744Ji2n053715; Sun, 4 Aug 2013 04:19:44 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 4 Aug 2013 04:19:44 GMT Message-Id: <201308040419.r744Ji2n053715@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 powerpc/powerpc 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: Sun, 04 Aug 2013 04:19:45 -0000 TB --- 2013-08-04 03:16:22 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-04 03:16:22 - 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 --- 2013-08-04 03:16:22 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-08-04 03:16:22 - cleaning the object tree TB --- 2013-08-04 03:17:38 - /usr/local/bin/svn stat /src TB --- 2013-08-04 03:17:42 - At svn revision 253918 TB --- 2013-08-04 03:17:43 - building world TB --- 2013-08-04 03:17:43 - CROSS_BUILD_TESTING=YES TB --- 2013-08-04 03:17:43 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-04 03:17:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-04 03:17:43 - SRCCONF=/dev/null TB --- 2013-08-04 03:17:43 - TARGET=powerpc TB --- 2013-08-04 03:17:43 - TARGET_ARCH=powerpc TB --- 2013-08-04 03:17:43 - TZ=UTC TB --- 2013-08-04 03:17:43 - __MAKE_CONF=/dev/null TB --- 2013-08-04 03:17:43 - cd /src TB --- 2013-08-04 03:17:43 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Aug 4 03:17:50 UTC 2013 >>> 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 [...] c++ -O2 -pipe -I/src/lib/clang/libclangfrontend/../../../contrib/llvm/include -I/src/lib/clang/libclangfrontend/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangfrontend/../../../contrib/llvm/tools/clang/lib/Frontend -I. -I/src/lib/clang/libclangfrontend/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc-unknown-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"powerpc-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangfrontend/../../../contrib/llvm/tools/clang/lib/Frontend/ChainedDiagnosticConsumer.cpp -o ChainedDiagnosticConsumer.o c++ -O2 -pipe -I/src/lib/clang/libclangfrontend/../../../contrib/llvm/include -I/src/lib/clang/libclangfrontend/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangfrontend/../../../contrib/llvm/tools/clang/lib/Frontend -I. -I/src/lib/clang/libclangfrontend/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc-unknown-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"powerpc-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangfrontend/../../../contrib/llvm/tools/clang/lib/Frontend/ChainedIncludesSource.cpp -o ChainedIncludesSource.o c++ -O2 -pipe -I/src/lib/clang/libclangfrontend/../../../contrib/llvm/include -I/src/lib/clang/libclangfrontend/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangfrontend/../../../contrib/llvm/tools/clang/lib/Frontend -I. -I/src/lib/clang/libclangfrontend/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc-unknown-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"powerpc-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangfrontend/../../../contrib/llvm/tools/clang/lib/Frontend/CompilerInstance.cpp -o CompilerInstance.o /src/lib/clang/libclangfrontend/../../../contrib/llvm/tools/clang/lib/Frontend/CompilerInstance.cpp: In member function 'virtual clang::ModuleLoadResult clang::CompilerInstance::loadModule(clang::SourceLocation, clang::ModuleIdPath, clang::Module::NameVisibilityKind, bool)': /src/lib/clang/libclangfrontend/../../../contrib/llvm/tools/clang/lib/Frontend/CompilerInstance.cpp:1088: internal compiler error: in var_ann, at tree-flow-inline.h:128 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop. bmake[5]: stopped in /src/lib/clang/libclangfrontend *** Error code 1 Stop. bmake[4]: stopped in /src/lib/clang *** Error code 1 Stop. bmake[3]: stopped in /src/lib *** Error code 1 Stop. bmake[2]: stopped in /src *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-04 04:19:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-04 04:19:43 - ERROR: failed to build world TB --- 2013-08-04 04:19:43 - 3029.30 user 460.42 system 3801.76 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Aug 4 01:36:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 76FF7D3B; Sun, 4 Aug 2013 01:36:21 +0000 (UTC) (envelope-from erich@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4F03525D9; Sun, 4 Aug 2013 01:36:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=FSi+mjGBY1ib1O/3sDXh4FkrSCxgtY/Gfsvlo4LxHRI=; b=KH3arsNcMklnHo0ulW2FoP8Tb8bX14JGXMp54Zf2V2uKtUEgsm3ZLWM0VdH/Eb6GTkXtMS4MLdkbytClO4RkB22Z8UqvLvnJL0RMy2DZE9e7jti4MALdQhsV0vrpc89/e2Vi7Rq1ydAwnmcFqgTL7ODRL/8m+ncafTFhmkInaCU=; Received: from [182.9.115.162] (port=25085 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1V5ltp-0028Xi-Rp; Sat, 03 Aug 2013 18:10:18 -0600 Date: Sun, 4 Aug 2013 08:10:09 +0800 From: Erich Dollansky To: Steve Kargl Subject: Re: svn error during 'make buildkernel'? Message-ID: <20130804081009.257c5801@X220.ovitrap.com> In-Reply-To: <20130803221702.GA979@troutmask.apl.washington.edu> References: <20130803210348.GA715@troutmask.apl.washington.edu> <20130803210858.GJ78299@glenbarber.us> <20130803213023.GA812@troutmask.apl.washington.edu> <20130803214313.GL78299@glenbarber.us> <20130803221702.GA979@troutmask.apl.washington.edu> Organization: ALO Green Technologies X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erich@alogt.com X-Source: X-Source-Args: X-Source-Dir: X-Mailman-Approved-At: Sun, 04 Aug 2013 04:21:29 +0000 Cc: Glen Barber , 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, 04 Aug 2013 01:36:21 -0000 Hi, On Sat, 3 Aug 2013 15:17:02 -0700 Steve Kargl wrote: > On Sat, Aug 03, 2013 at 05:43:13PM -0400, Glen Barber wrote: > > On Sat, Aug 03, 2013 at 02:30:23PM -0700, Steve Kargl wrote: > > > On Sat, Aug 03, 2013 at 05:08:58PM -0400, Glen Barber wrote: > > > > On Sat, Aug 03, 2013 at 02:03:49PM -0700, Steve Kargl wrote: > > > > > I updated my /usr/src with subversion from ports: > > > > > > > > > > % pkg info | grep subver > > > > > subversion-1.7.9_1 Version control system > > > > > > > > > > 'make buildworld' completed as expected. 'make buildkernel' > > > > > seems to complete, but I'm seeing > > > > > > > > > > :> hack.c > > > > > cc -shared -nostdlib hack.c -o hack.So > > > > > rm -f hack.c > > > > > MAKE=make sh /usr/src/sys/conf/newvers.sh MOBILE > > > > > svn: E155036: The working copy at '/usr/src' > > > > > is too old (format 29) to work with client version '1.8.0 > > > > > (r1490375)' (expects format 31). You need to upgrade the > > > > > working copy first. > > > > > > > > > > > > > > Why is svn being run during 'make buildkernel'? More > > > > > importantly, why is the freshly built svn in /usr/obj being > > > > > invoked when it has not previously been installed and > > > > > so /usr/src may indeed be in a older, yet valid, format? > > > > > > > > > > > > > src/sys/conf/newvers.sh sets the svn revision, which is printed > > > > by uname(1). > > > > > > > > devel/subversion is at version 1.8.x, so you should upgrade your > > > > installed port. Or you can use /usr/bin/svnlite directly, and > > > > run: > > > > > > > > # /usr/bin/svnlite upgrade /usr/src > > > > > > > > > > Thanks. > > > > > > Looks like an entry in /usr/src/UPDATING is missing if > > > /usr/bin/svn* is forcing an obsolscence of a functioning > > > installed port. > > > > > > > The port was at 1.8.x before I added the additional lookup of > > svnlite to the script. > > My installed port was at 1.7.9. I can't find anywhere that > states that one must immediately upgrade to a new version > when a port's maintainer updates it. I've banged my head > against the ports collection dependency idiocy too often > to chase after every update. > > > There really is no need for UPDATING entry, since 1.7.9 is > > deprecated, and the behavior you have seen is not a fatal > > error with the buildkernel process. > > Installing a freshly built kernel when an ERROR message appears > within the last 10 lines of 'make buildkernel' seems like a > rather dumb thing do. > > > BTW, you should upgrade devel/subversion anyway, since there are > > security vulnerabilities. > > 1.7.9 works/worked fine for updating my /usr/src and my personal > svn repository. The change to use svnlite in newvers.sh should > have an entry in UPDATING to alert users that have a too old > svn port that they need to upgrade. I go as far to suggest that > that the script should look for svn in the path before it looks > for svnlite. > doesn't this show again that svn came a bit early? I wait only for the day, when two versions are needed. One for the ports, one for FreeBSD itself. Let us hope that this is all ironed out until 10 is released. I see the need to integrate svn into the base system. But this should not force to keep also the ports current. At least it should not confuse users when they keep the ports a bit older. I am aware of that we are talking of current here and I am aware of solutions for this problem. Erich From owner-freebsd-current@FreeBSD.ORG Sun Aug 4 04:56:51 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5972A5B7; Sun, 4 Aug 2013 04:56:51 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1E32C2C52; Sun, 4 Aug 2013 04:56:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=vPFDfuMk+s2E/wOaJaqoxqTHNeYlPeEklAb+jeoEYbQ=; b=vvsnqjaqdFOaLnSPokO7nLdy/qRs4rXSFPi1dr1y7eDMjgm39SrBg7t5jmOSep3eeq5mAFHc+htAzahT+SJCkdpgXLboqo3agwEQEjKrksHoSEE5/DMQOE4lV6FZSyFSwkJWjdld0zWoCJQz7ew3ks3NEl5ZTSCXUXU32Xv0KBA=; Received: from [182.7.63.110] (port=17875 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1V5qN6-000hJu-F6; Sat, 03 Aug 2013 22:56:50 -0600 Date: Sun, 4 Aug 2013 12:56:40 +0800 From: Erich Dollansky To: Glen Barber Subject: Re: svn error during 'make buildkernel'? Message-ID: <20130804125640.2a1822fe@X220.ovitrap.com> In-Reply-To: <20130804020456.GS78299@glenbarber.us> References: <20130803210348.GA715@troutmask.apl.washington.edu> <20130803210858.GJ78299@glenbarber.us> <20130803213023.GA812@troutmask.apl.washington.edu> <20130803214313.GL78299@glenbarber.us> <20130803221702.GA979@troutmask.apl.washington.edu> <20130804081009.257c5801@X220.ovitrap.com> <20130804020456.GS78299@glenbarber.us> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-current@freebsd.org, Steve Kargl 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, 04 Aug 2013 04:56:51 -0000 Hi, On Sat, 3 Aug 2013 22:04:56 -0400 Glen Barber wrote: > On Sun, Aug 04, 2013 at 08:10:09AM +0800, Erich Dollansky wrote: > > doesn't this show again that svn came a bit early? > > No, it shows that people do not keep their third-party software up to > date. you want to say, that it is true what Windows people say is true, that Linus/Unix people do not work with their machines but are busy compiling their kernel? I want to work with my computer. I also want to be able to do updates of the kernel alone when I read here of a fix in the kernel that bugs me just as it was possible with cvs. I hope We all can soon do this again. Erich > > Glen > From owner-freebsd-current@FreeBSD.ORG Sun Aug 4 05:34:17 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4DE1FB2A; Sun, 4 Aug 2013 05:34:17 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2AA1A2DB6; Sun, 4 Aug 2013 05:34:17 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.6/8.14.6) with ESMTP id r745YGQJ002331; Sat, 3 Aug 2013 22:34:16 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.6/8.14.6/Submit) id r745YGqV002330; Sat, 3 Aug 2013 22:34:16 -0700 (PDT) (envelope-from sgk) Date: Sat, 3 Aug 2013 22:34:16 -0700 From: Steve Kargl To: Glen Barber Subject: Re: svn error during 'make buildkernel'? Message-ID: <20130804053416.GA2299@troutmask.apl.washington.edu> References: <20130803210348.GA715@troutmask.apl.washington.edu> <20130803210858.GJ78299@glenbarber.us> <20130803213023.GA812@troutmask.apl.washington.edu> <20130803214313.GL78299@glenbarber.us> <20130803221702.GA979@troutmask.apl.washington.edu> <20130803222047.GN78299@glenbarber.us> <20130803224608.GA1150@troutmask.apl.washington.edu> <20130803224719.GP78299@glenbarber.us> <20130804001045.GA1500@troutmask.apl.washington.edu> <20130804005335.GQ78299@glenbarber.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130804005335.GQ78299@glenbarber.us> 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, 04 Aug 2013 05:34:17 -0000 On Sat, Aug 03, 2013 at 08:53:35PM -0400, Glen Barber wrote: > On Sat, Aug 03, 2013 at 05:10:45PM -0700, Steve Kargl wrote: > > If the script can't find svnversion or svnliteversion, > > then it issues an error. > > > > *sigh* > > No. It is *not* a fatal error. > I didn't say anything about a fatal error. *sigh* In a bygone time, FreeBSD committers actually cared about the quality of software. -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Aug 4 06:51:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 89D3FABB; Sun, 4 Aug 2013 06:51:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0CA9620BD; Sun, 4 Aug 2013 06:51:23 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r746pE78091419; Sun, 4 Aug 2013 09:51:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r746pE78091419 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r746pEdX091418; Sun, 4 Aug 2013 09:51:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 4 Aug 2013 09:51:14 +0300 From: Konstantin Belousov To: Mark Johnston Subject: Re: ldd runs linux programs Message-ID: <20130804065114.GI4972@kib.kiev.ua> References: <20130728193110.GB17514@gpr.nnz-home.ru> <20130728204958.GA32322@dft-labs.eu> <51F5D491.1080803@freebsd.org> <20130729081254.GB32322@dft-labs.eu> <20130729155625.GA2544@charmander> <20130729205449.GA6007@dft-labs.eu> <20130801021231.GA58998@raichu> <20130801133935.GT4972@kib.kiev.ua> <20130804041734.GB3259@raichu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ShzNbizneSsKYyOp" Content-Disposition: inline In-Reply-To: <20130804041734.GB3259@raichu> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Gennady Proskurin , Mateusz Guzik , 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, 04 Aug 2013 06:51:24 -0000 --ShzNbizneSsKYyOp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 04, 2013 at 12:17:34AM -0400, Mark Johnston wrote: > I spent some time trying to figure out if there was any reason for this > and didn't come up with anything. Does the patch below look ok? It just > adds a couple of macros to set both the native and 32-bit compat > variable. It works properly for me for 32-bit, native, and (32-bit) > Linux executables and shared libs on an amd64 machine. >=20 > diff --git a/usr.bin/ldd/ldd.c b/usr.bin/ldd/ldd.c > index 00c8797..39f38e8 100644 > --- a/usr.bin/ldd/ldd.c > +++ b/usr.bin/ldd/ldd.c > @@ -49,12 +49,6 @@ __FBSDID("$FreeBSD$"); > =20 > #include "extern.h" > =20 > -#ifdef COMPAT_32BIT > -#define LD_ "LD_32_" > -#else > -#define LD_ "LD_" > -#endif > - > /* > * 32-bit ELF data structures can only be used if the system header[s] d= eclare > * them. There is no official macro for determining whether they are de= clared, > @@ -76,13 +70,23 @@ static void usage(void); > =20 > #define _PATH_LDD32 "/usr/bin/ldd32" > =20 > +#define LDD_SETENV(name, value, overwrite) do { \ > + setenv("LD_" name, value, overwrite); \ > + setenv("LD_32_" name, value, overwrite); \ > +} while (0) > + > +#define LDD_UNSETENV(name) do { \ > + unsetenv("LD_" name); \ > + unsetenv("LD_32_" name); \ > +} while (0) > + > static int > execldd32(char *file, char *fmt1, char *fmt2, int aflag, int vflag) > { > char *argv[8]; > int i, rval, status; > =20 > - unsetenv(LD_ "TRACE_LOADED_OBJECTS"); > + LDD_UNSETENV("TRACE_LOADED_OBJECTS"); > rval =3D 0; > i =3D 0; > argv[i++] =3D strdup(_PATH_LDD32); > @@ -121,7 +125,7 @@ execldd32(char *file, char *fmt1, char *fmt2, int afl= ag, int vflag) > } > while (i--) > free(argv[i]); > - setenv(LD_ "TRACE_LOADED_OBJECTS", "yes", 1); > + LDD_SETENV("TRACE_LOADED_OBJECTS", "yes", 1); > return (rval); > } > #endif > @@ -210,15 +214,15 @@ main(int argc, char *argv[]) > } > =20 > /* ld.so magic */ > - setenv(LD_ "TRACE_LOADED_OBJECTS", "yes", 1); > + LDD_SETENV("TRACE_LOADED_OBJECTS", "yes", 1); > if (fmt1 !=3D NULL) > - setenv(LD_ "TRACE_LOADED_OBJECTS_FMT1", fmt1, 1); > + LDD_SETENV("TRACE_LOADED_OBJECTS_FMT1", fmt1, 1); > if (fmt2 !=3D NULL) > - setenv(LD_ "TRACE_LOADED_OBJECTS_FMT2", fmt2, 1); > + LDD_SETENV("TRACE_LOADED_OBJECTS_FMT2", fmt2, 1); > =20 > - setenv(LD_ "TRACE_LOADED_OBJECTS_PROGNAME", *argv, 1); > + LDD_SETENV("TRACE_LOADED_OBJECTS_PROGNAME", *argv, 1); > if (aflag) > - setenv(LD_ "TRACE_LOADED_OBJECTS_ALL", "1", 1); > + LDD_SETENV("TRACE_LOADED_OBJECTS_ALL", "1", 1); > else if (fmt1 =3D=3D NULL && fmt2 =3D=3D NULL) > /* Default formats */ > printf("%s:\n", *argv); This looks fine to me. --ShzNbizneSsKYyOp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR/fniAAoJEJDCuSvBvK1B9swQAILL7cNpR7dw2xNneHCcTAso jYZuzh9y/QE9SPQzWA4lLd/mzuahy5gFCYpkB1upHzW0VQc4+0/TqhjrFeeWsgT1 SweK6kjsyic2k96+ltSbOvulBVAK9sOdV+AyF5QncsrawXxyTriQCYyAOioI/1df NUlGaaU3Mqn36TCm12skYeSf33JmI3KApTeD48tRIv2v1JTaaTPJU9Bxtkdm/ycZ tvM88KRGiccI5end3OI4D3FkoYal3Lodm16utd9ZKE6o/YRLeH/RjW33Zdxx7SgW yT4UNPjghi15tbGkILXGiB7cAmMEylBsabgsPsCYAtSjWLPoGJzs69QyhUr7c26Y m5UU/B14WULaFkLUQoDuJxw+B66mTwbd6m/g3tSgiZk1SumeEOpSh/pf6EZ9hCdF nyapcCiZD0UUFx09TmuEDmK6cMI9pVRluzyhmwtIkRkP9+E4N4WdeYPs1rokZlhx kV1KhvDHs3Ye9UI0Zv2a6z6ruN0jrRz087qTD9SDgBzDFUpu6Eir/+5QXglcFoiY ggQPv+q7+y3mOVyqWGsz6uJ6ZXm95T6LAziReH7v0l04azCe5W1KRoSk+M8SksDW aw5490TF2IDGRcfEmuH1wDa7ZoTj2HSOQuYiXdgDBtLqUS/Dhk3j1ibAIaYzea+1 wsC+TqtdR5tj1ZLx/kNG =FBmT -----END PGP SIGNATURE----- --ShzNbizneSsKYyOp-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 4 07:15:57 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 41F9AE74; Sun, 4 Aug 2013 07:15:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0780E2127; Sun, 4 Aug 2013 07:15:56 +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 r747FtfM067442; Sun, 4 Aug 2013 03:15:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r747FtwH067441; Sun, 4 Aug 2013 07:15:55 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 4 Aug 2013 07:15:55 GMT Message-Id: <201308040715.r747FtwH067441@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 powerpc64/powerpc 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: Sun, 04 Aug 2013 07:15:57 -0000 TB --- 2013-08-04 03:58:30 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-04 03:58:30 - 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 --- 2013-08-04 03:58:30 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2013-08-04 03:58:30 - cleaning the object tree TB --- 2013-08-04 04:00:35 - /usr/local/bin/svn stat /src TB --- 2013-08-04 04:00:40 - At svn revision 253918 TB --- 2013-08-04 04:00:41 - building world TB --- 2013-08-04 04:00:41 - CROSS_BUILD_TESTING=YES TB --- 2013-08-04 04:00:41 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-04 04:00:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-04 04:00:41 - SRCCONF=/dev/null TB --- 2013-08-04 04:00:41 - TARGET=powerpc TB --- 2013-08-04 04:00:41 - TARGET_ARCH=powerpc64 TB --- 2013-08-04 04:00:41 - TZ=UTC TB --- 2013-08-04 04:00:41 - __MAKE_CONF=/dev/null TB --- 2013-08-04 04:00:41 - cd /src TB --- 2013-08-04 04:00:41 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Aug 4 04:00:48 UTC 2013 >>> 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sun Aug 4 07:01:05 UTC 2013 TB --- 2013-08-04 07:01:05 - generating LINT kernel config TB --- 2013-08-04 07:01:05 - cd /src/sys/powerpc/conf TB --- 2013-08-04 07:01:05 - /usr/bin/make -B LINT TB --- 2013-08-04 07:01:05 - cd /src/sys/powerpc/conf TB --- 2013-08-04 07:01:05 - /usr/sbin/config -m LINT TB --- 2013-08-04 07:01:05 - skipping LINT kernel TB --- 2013-08-04 07:01:05 - cd /src/sys/powerpc/conf TB --- 2013-08-04 07:01:05 - /usr/sbin/config -m GENERIC TB --- 2013-08-04 07:01:05 - skipping GENERIC kernel TB --- 2013-08-04 07:01:05 - cd /src/sys/powerpc/conf TB --- 2013-08-04 07:01:05 - /usr/sbin/config -m GENERIC64 TB --- 2013-08-04 07:01:05 - building GENERIC64 kernel TB --- 2013-08-04 07:01:05 - CROSS_BUILD_TESTING=YES TB --- 2013-08-04 07:01:05 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-04 07:01:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-04 07:01:05 - SRCCONF=/dev/null TB --- 2013-08-04 07:01:05 - TARGET=powerpc TB --- 2013-08-04 07:01:05 - TARGET_ARCH=powerpc64 TB --- 2013-08-04 07:01:05 - TZ=UTC TB --- 2013-08-04 07:01:05 - __MAKE_CONF=/dev/null TB --- 2013-08-04 07:01:05 - cd /src TB --- 2013-08-04 07:01:05 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64 >>> Kernel build for GENERIC64 started on Sun Aug 4 07:01:05 UTC 2013 >>> 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 >>> stage 3.2: building everything [...] ===> scc (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /src/sys/modules/scc/../../dev/scc/scc_bfe_macio.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /src/sys/modules/scc/../../dev/scc/scc_bfe_quicc.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /src/sys/modules/scc/../../dev/scc/scc_dev_quicc.c cc1: warnings being treated as errors /src/sys/modules/scc/../../dev/scc/scc_dev_quicc.c: In function 'quicc_bfe_iclear': /src/sys/modules/scc/../../dev/scc/scc_dev_quicc.c:110: warning: implicit declaration of function 'quicc_read4' /src/sys/modules/scc/../../dev/scc/scc_dev_quicc.c:110: warning: nested extern declaration of 'quicc_read4' [-Wnested-externs] *** Error code 1 Stop. bmake[3]: stopped in /src/sys/modules/scc *** Error code 1 Stop. bmake[2]: stopped in /src/sys/modules *** Error code 1 Stop. bmake[1]: stopped in /obj/powerpc.powerpc64/src/sys/GENERIC64 *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-04 07:15:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-04 07:15:55 - ERROR: failed to build GENERIC64 kernel TB --- 2013-08-04 07:15:55 - 10354.00 user 1264.52 system 11845.16 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Aug 4 11:09:41 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8F299B3 for ; Sun, 4 Aug 2013 11:09:41 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 625AE2541 for ; Sun, 4 Aug 2013 11:09:41 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id r74B9ZDt019624 for ; Sun, 4 Aug 2013 04:09:35 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <51FE366F.4010804@rawbw.com> Date: Sun, 04 Aug 2013 04:09:35 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130628 Thunderbird/17.0.7 MIME-Version: 1.0 To: current@freebsd.org Subject: Please check in this patch: kern/181012: Implemented linux system call fstatfs64 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 04 Aug 2013 11:09:41 -0000 http://www.freebsd.org/cgi/query-pr.cgi?pr=181012 Thank you, Yuri From owner-freebsd-current@FreeBSD.ORG Sun Aug 4 19:10:01 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4E6AEE6A; Sun, 4 Aug 2013 19:10:01 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2085124AA; Sun, 4 Aug 2013 19:10:00 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Michael Butler", Issuer "Protected Networks Certificate Authority" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 559E5613B; Sun, 4 Aug 2013 15:09:59 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=Mr5ZXkKDxzVO9EVQgoXWuHuw/JE4sLtscPmmKwBCBF8wdf7ydqji3/e5YJSEkN41h 9iYIyMZ++kjHfjyr0PWl3hvnjhozTY6u7SxJ732DxoE1djoXbHYMxBDQHonzH0z Message-ID: <51FEA705.4020407@protected-networks.net> Date: Sun, 04 Aug 2013 15:09:57 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130802 Thunderbird/17.0.7 MIME-Version: 1.0 To: az@freebsd.org, FreeBSD Current Subject: namespace confusion between GCC 4.2 and GCC 4.6? X-Enigmail-Version: 1.5.1 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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, 04 Aug 2013 19:10:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 With the (-current) base system compiled with (the native) GCC and attempting to compile editor/libreoffice (with gcc-4.6), I get .. [build LNK] Library/libstore.so [build srs] /usr/ports/editors/libreoffice/work/libreoffice-4.0.4.2/dbaccess/source/ui/dlg/AutoControls_tmpl.hrc [build srs] /usr/ports/editors/libreoffice/work/libreoffice-4.0.4.2/dbaccess/source/ui/inc/toolbox_tmpl.hrc [build LNK] Executable/HelpIndexer [build LNK] Executable/HelpLinker /usr/local/lib/libclucene-core.so: undefined reference to `logl@GLIBCXX_3.4' /usr/local/lib/libclucene-shared.so: undefined reference to `log10l@GLIBCXX_3.4' collect2: ld returned 1 exit status gmake[4]: *** [/usr/ports/editors/libreoffice/work/workdir/unxfbsdi.pro/LinkTarget/Executable/HelpIndexer] Error 1 gmake[4]: *** Waiting for unfinished jobs.... Recompiling textproc/clucene with gcc-4.6 solves the linkage problem but causes (many) other packages to fail (e.g. KDE components with clucene dependencies). What is the recommended solution? imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (FreeBSD) iEYEARECAAYFAlH+pwUACgkQQv9rrgRC1JKGMQCfd4RDciiYb0yx3Kki6+T4plCR eYEAn2HmEgjTinUW9yMaXQSemrp9Cgmf =ZejK -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Aug 4 19:33:51 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 139E3B24 for ; Sun, 4 Aug 2013 19:33:51 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-vb0-x22f.google.com (mail-vb0-x22f.google.com [IPv6:2607:f8b0:400c:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A5B2C2620 for ; Sun, 4 Aug 2013 19:33:50 +0000 (UTC) Received: by mail-vb0-f47.google.com with SMTP id h10so2171881vbh.34 for ; Sun, 04 Aug 2013 12:33:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Zg08kLzceYdeMJ5tOBPQV6ZrhyQCBsIR2epYjOUjVyc=; b=bOYekEJ+WoPijGtyvfsWlSWgruTYdWebBmLh9BJBEA1LhBG6IrAF+49DbbuLJjhIAF aVv6z6o5+JoscyHJt4kPCaCkwThaSecZoHdI4xJALZVjwq/ub2IfuOnT55Fjlwb/hoN0 y6QN9onbvlR7g3a+GdZWSvxMlVYPshqBc8PxSJL7vfFFY8v+UnHd0qkE3sB4vhaZ+Ec0 9LrN6iZJO/Fo0LwIdNUym7D+dwPwZUPqVAXm+qU7fexP6ewULAZi5ZgdOcrmnSTo4n6H MPWGWwzeM9hUXGGWxGXq9CY8YFWrrQWRc6tRT+Pp15uRTm5XOKuHNzIkCWU9V/Ti/qPv QPeg== MIME-Version: 1.0 X-Received: by 10.58.100.234 with SMTP id fb10mr4968883veb.5.1375644829775; Sun, 04 Aug 2013 12:33:49 -0700 (PDT) Received: by 10.220.96.78 with HTTP; Sun, 4 Aug 2013 12:33:49 -0700 (PDT) Date: Sun, 4 Aug 2013 15:33:49 -0400 Message-ID: Subject: Kernel Panic on FreeBSD 10.0-CURRENT #1 r253918 From: "Sam Fourman Jr." To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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, 04 Aug 2013 19:33:51 -0000 hello list, could someone help me figure out why this machine kernel paniced? I have a full crashdump file if needed, this machine is configured as a Firewall and wifi hostap running pf in a small office here is a mailing list post to someone that had a similar problem a few years back http://lists.freebsd.org/pipermail/freebsd-bugs/2011-April/043985.html a backtrace, full dmesg, and kernel config are below kgdb /boot/kernel/kernel /var/crash/vmcore.0 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 10 fault virtual address = 0x10 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff809937a8 stack pointer = 0x28:0xffffff8000278870 frame pointer = 0x28:0xffffff80002788c0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (swi4: clock) trap number = 12 panic: page fault cpuid = 0 Uptime: 23h57m13s Dumping 2452 out of 8070 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Reading symbols from /boot/kernel/zfs.ko.symbols...done. Loaded symbols for /boot/kernel/zfs.ko.symbols Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. Loaded symbols for /boot/kernel/opensolaris.ko.symbols Reading symbols from /boot/kernel/uhid.ko.symbols...done. Loaded symbols for /boot/kernel/uhid.ko.symbols Reading symbols from /boot/kernel/wlan_xauth.ko.symbols...done. Loaded symbols for /boot/kernel/wlan_xauth.ko.symbols #0 doadump (textdump=1) at pcpu.h:236 236 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump (textdump=1) at pcpu.h:236 #1 0xffffffff8083eb21 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0xffffffff8083ee84 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:754 #3 0xffffffff80bd5dea in trap_fatal (frame=, eva=) at /usr/src/sys/amd64/amd64/trap.c:873 #4 0xffffffff80bd6027 in trap_pfault (frame=0x0, usermode=) at /usr/src/sys/amd64/amd64/trap.c:699 #5 0xffffffff80bd5876 in trap (frame=0xffffff80002787c0) at /usr/src/sys/amd64/amd64/trap.c:463 #6 0xffffffff80bc06b2 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 #7 0xffffffff809937a8 in in6_tmpaddrtimer (arg=0xfffffe00170fc0b6) at /usr/src/sys/netinet6/in6_ifattach.c:935 #8 0xffffffff8085140a in softclock_call_cc (c=0xffffffff81325210, cc=0xffffffff8131c700, direct=0) at /usr/src/sys/kern/kern_timeout.c:674 #9 0xffffffff80851704 in softclock (arg=) at /usr/src/sys/kern/kern_timeout.c:802 #10 0xffffffff80815dc3 in intr_event_execute_handlers (p=, ie=0xfffffe0014ab3400) at /usr/src/sys/kern/kern_intr.c:1263 #11 0xffffffff80816716 in ithread_loop (arg=0xfffffe0014a896e0) at /usr/src/sys/kern/kern_intr.c:1276 #12 0xffffffff80813b31 in fork_exit (callout=0xffffffff80816680 , arg=0xfffffe0014a896e0, frame=0xffffff8000278a40) at /usr/src/sys/kern/kern_fork.c:991 #13 0xffffffff80bc0bee in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:606 #14 0x0000000000000000 in ?? () Current language: auto; currently minimal (kgdb) if you need a dmesg it is below Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #1 r253918: Sat Aug 3 18:32:13 UTC 2013 root@Border:/usr/obj/usr/src/sys/BORDER amd64 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 CPU: AMD FX(tm)-4100 Quad-Core Processor (3600.29-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x600f12 Family = 0x15 Model = 0x1 Stepping = 2 Features=0x178bfbff Features2=0x1e98220b AMD Features=0x2e500800 AMD Features2=0x1c9bfff,> TSC: P-state invariant, performance statistics real memory = 8589934592 (8192 MB) avail memory = 7868518400 (7504 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 16 cpu1 (AP): APIC ID: 17 cpu2 (AP): APIC ID: 18 cpu3 (AP): APIC ID: 19 ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has zero address or length: 0x0000000000000000/0x1 (20130725/tbfadt-630) ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-55 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 450 Event timer "HPET2" frequency 14318180 Hz quality 450 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.2 (no driver attached) pcib1: irq 52 at device 2.0 on pci0 pci1: on pcib1 vgapci0: mem 0xfd000000-0xfdffffff,0xc0000000-0xcfffffff,0xfc000000-0xfcffffff irq 24 at device 0.0 on pci1 pcib2: irq 52 at device 4.0 on pci0 pci2: on pcib2 re0: port 0xe000-0xe0ff mem 0xd0004000-0xd0004fff,0xd0000000-0xd0003fff irq 44 at device 0.0 on pci2 re0: Using 1 MSI-X message re0: Chip rev. 0x48000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 60:a4:4c:57:02:c4 pcib3: irq 52 at device 5.0 on pci0 pci3: on pcib3 xhci0: mem 0xfe400000-0xfe407fff irq 46 at device 0.0 on pci3 xhci0: 32 byte context size. usbus0 on xhci0 pcib4: irq 53 at device 7.0 on pci0 pci4: on pcib4 xhci1: mem 0xfe300000-0xfe307fff irq 50 at device 0.0 on pci4 xhci1: 32 byte context size. usbus1 on xhci1 pcib5: irq 53 at device 9.0 on pci0 pci5: on pcib5 ath0: mem 0xfe200000-0xfe21ffff irq 48 at device 0.0 on pci5 ar9300_set_stub_functions: setting stub functions ar9300_set_stub_functions: setting stub functions ar9300_attach: calling ar9300_hw_attach ar9300_hw_attach: calling ar9300_eeprom_attach ar9300_flash_map: unimplemented for now Restoring Cal data from DRAM Restoring Cal data from EEPROM ar9300_hw_attach: ar9300_eeprom_attach returned 0 ath0: RX status length: 48 ath0: RX buffer size: 4096 ath0: TX descriptor length: 128 ath0: TX status length: 36 ath0: TX buffers per descriptor: 4 ar9300_freebsd_setup_x_tx_desc: called, 0x0/0, 0x0/0, 0x0/0 ath0: ath_edma_setup_rxfifo: type=0, FIFO depth = 16 entries ath0: ath_edma_setup_rxfifo: type=1, FIFO depth = 128 entries ath0: [HT] enabling HT modes ath0: [HT] enabling short-GI in 20MHz mode ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 stream STBC transmit enabled ath0: [HT] 3 RX streams; 3 TX streams ath0: AR9380 mac 448.3 RF5110 phy 0.0 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000 ahci0: port 0xf040-0xf047,0xf030-0xf033,0xf020-0xf027,0xf010-0xf013,0xf000-0xf00f mem 0xfe50b000-0xfe50b3ff irq 19 at device 17.0 on pci0 ahci0: AHCI v1.20 with 3 6Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich2: at channel 2 on ahci0 ahcich5: at channel 5 on ahci0 ohci0: mem 0xfe50a000-0xfe50afff irq 18 at device 18.0 on pci0 usbus2 on ohci0 ehci0: mem 0xfe509000-0xfe5090ff irq 17 at device 18.2 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 ohci1: mem 0xfe508000-0xfe508fff irq 20 at device 19.0 on pci0 usbus4 on ohci1 ehci1: mem 0xfe507000-0xfe5070ff irq 21 at device 19.2 on pci0 usbus5: EHCI version 1.0 usbus5 on ehci1 pci0: at device 20.0 (no driver attached) pci0: at device 20.2 (no driver attached) isab0: at device 20.3 on pci0 isa0: on isab0 pcib6: at device 20.4 on pci0 pci6: on pcib6 re1: port 0xd100-0xd1ff mem 0xfe141000-0xfe1410ff irq 20 at device 5.0 on pci6 re1: Chip rev. 0x10000000 re1: MAC rev. 0x00000000 miibus1: on re1 rgephy1: PHY 1 on miibus1 rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re1: Ethernet address: 00:14:d1:25:d8:23 re2: port 0xd000-0xd0ff mem 0xfe140000-0xfe1400ff irq 21 at device 6.0 on pci6 re2: Chip rev. 0x10000000 re2: MAC rev. 0x00000000 miibus2: on re2 rgephy2: PHY 1 on miibus2 rgephy2: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re2: Ethernet address: 00:14:d1:25:d8:44 ohci2: mem 0xfe506000-0xfe506fff irq 18 at device 20.5 on pci0 usbus6 on ohci2 ohci3: mem 0xfe505000-0xfe505fff irq 22 at device 22.0 on pci0 usbus7 on ohci3 ehci2: mem 0xfe504000-0xfe5040ff irq 23 at device 22.2 on pci0 usbus8: EHCI version 1.0 usbus8 on ehci2 acpi_button0: on acpi0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] ppc0: cannot reserve I/O port range acpi_throttle0: on cpu0 hwpstate0: on cpu0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 acpi_throttle2: on cpu2 acpi_throttle2: failed to attach P_CNT device_attach: acpi_throttle2 attach returned 6 acpi_throttle3: on cpu3 acpi_throttle3: failed to attach P_CNT device_attach: acpi_throttle3 attach returned 6 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec usbus0: 5.0Gbps Super Speed USB v3.0 usbus1: 5.0Gbps Super Speed USB v3.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 480Mbps High Speed USB v2.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 12Mbps Full Speed USB v1.0 usbus8: 480Mbps High Speed USB v2.0 ugen0.1: <0x1b21> at usbus0 uhub0: <0x1b21 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 ugen3.1: at usbus3 uhub1: on usbus3 ugen2.1: at usbus2 uhub2: on usbus2 ugen1.1: <0x1b21> at usbus1 uhub3: <0x1b21 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus1 ugen6.1: at usbus6 uhub4: on usbus6 ugen5.1: at usbus5 uhub5: on usbus5 ugen4.1: at usbus4 uhub6: on usbus4 ugen8.1: at usbus8 uhub7: on usbus8 ugen7.1: at usbus7 uhub8: on usbus7 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-7 SATA 1.x device ada0: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) ada0: 38166MB (78165360 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 ada1 at ahcich2 bus 0 scbus1 target 0 lun 0 ada1: ATA-7 SATA 1.x device ada1: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 38166MB (78165360 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad6 ada2 at ahcich5 bus 0 scbus2 target 0 lun 0 ada2: ATA-7 SATA 1.x device ada2: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) ada2: 38166MB (78165360 512 byte sectors: 16H 63S/T 16383C) ada2: Previously was known as ad8 SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! Timecounter "TSC-low" frequency 1800146890 Hz quality 1000 uhub4: 2 ports with 2 removable, self powered uhub8: 4 ports with 4 removable, self powered uhub2: 5 ports with 5 removable, self powered uhub6: 5 ports with 5 removable, self powered uhub3: 4 ports with 4 removable, self powered uhub0: 4 ports with 4 removable, self powered GEOM: ada2: the secondary GPT table is corrupt or invalid. GEOM: ada2: using the primary only -- recovery suggested. GEOM: diskid/DISK-MDT-MCANKK515312: the secondary GPT table is corrupt or invalid. GEOM: diskid/DISK-MDT-MCANKK515312: using the primary only -- recovery suggested. Root mount waiting for: usbus8 usbus5 usbus3 Root mount waiting for: usbus8 usbus5 usbus3 uhub7: 4 ports with 4 removable, self powered uhub1: 5 ports with 5 removable, self powered uhub5: 5 ports with 5 removable, self powered Trying to mount root from zfs:Puffy []... ugen4.2: at usbus4 ukbd0: on usbus4 kbd2 at ukbd0 <118>Setting hostuuid: becbf4de-e6e7-53eb-eafa-1c0fc0145223. <118>Setting hostid: 0xfbb7c83e. <118>Starting ddb. <118>Entropy harvesting: interrupts ethernet point_to_point ar9300_Stub_GetCTSTimeout: called ar9300_Stub_GetCTSTimeout: called ar9300_Stub_GetAntennaSwitch: called ar9300_Stub_GetAntennaSwitch: called <118> kickstart. <118>Starting file system checks: <118>Mounting local file systems:. <118>/etc/rc: WARNING: $swapfile is obsolete. Ignored. <118>Writing entropy file:. <118>Setting hostname: Border. wlan0: Ethernet address: 7c:c3:a1:b3:fc:af <118>ifconfig: ioctl(SIOCGIFINFO_IN6): Protocol family not supported <118>Starting Network: lo0 re0 ath0 re1 re2 pflog0. <118>lo0: flags=8049 metric 0 mtu 16384 <118> options=600003 <118> inet6 ::1 prefixlen 128 <118> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6 <118> inet 127.0.0.1 netmask 0xff000000 <118> nd6 options=21 <118>re0: flags=8843 metric 0 mtu 1500 <118> options=8209b <118> ether 60:a4:4c:57:02:c4 <118> inet 75.133.75.194 netmask 0xfffffff8 broadcast 75.133.75.199 <118> inet6 fe80::62a4:4cff:fe57:2c4%re0 prefixlen 64 scopeid 0x1 <118> nd6 options=29 <118> media: Ethernet autoselect (none) <118> status: no carrier <118>ath0: flags=8843 metric 0 mtu 2290 <118> ether 7c:c3:a1:b3:fc:af <118> nd6 options=29 <118> media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng <118> status: running <118>re1: flags=8843 metric 0 mtu 1500 <118> options=8209b <118> ether 00:14:d1:25:d8:23 <118> inet 192.168.12.1 netmask 0xffffff00 broadcast 192.168.12.255 <118> inet6 fe80::214:d1ff:fe25:d823%re1 prefixlen 64 scopeid 0x3 <118> nd6 options=29 <118> media: Ethernet autoselect (none) <118> status: no carrier <118>re2: flags=8802 metric 0 mtu 1500 <118> options=8209b <118> ether 00:14:d1:25:d8:44 <118> nd6 options=29 <118> media: Ethernet autoselect (10baseT/UTP ) <118> status: active <118>pflog0: flags=0<> metric 0 mtu 33152 <118>Starting devd. <118>Starting Network: re2. <118>re2: flags=8802 metric 0 mtu 1500 <118> options=8209b <118> ether 00:14:d1:25:d8:44 <118> nd6 options=29 <118> media: Ethernet autoselect (10baseT/UTP ) <118> status: active <118>Additional inet routing options: gateway=YES. <118>ifconfig: ioctl(SIOCGIFINFO_IN6): Protocol family not supported <118>Starting Network: pflog0. <118>pflog0: flags=0<> metric 0 mtu 33152 <118>Additional inet routing options: gateway=YES. uhid0: on usbus4 uhid1: on usbus4 <118>Starting pflog. <118>Aug 3 19:14:54 pflogd[1589]: [priv]: msg PRIV_OPEN_LOG received <118>Enabling pf. <118>add net default: gateway 75.133.75.193 fib 0 <118>add net 192.168.1.0: gateway re0 fib 0 <118>Additional inet routing options: gateway=YES. <118>add net fe80::: gateway ::1 fib 0,1,2,3,4,5 <118>add net ff02::: gateway ::1 fib 0,1,2,3,4,5 <118>add net ::ffff:0.0.0.0: gateway ::1 fib 0,1,2,3,4,5 <118>add net ::0.0.0.0: gateway ::1 fib 0,1,2,3,4,5 <118>ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib <118>32-bit compatibility ldconfig path: /usr/lib32 <118>Creating and/or trimming log files. <118>Starting syslogd. <118>No core dumps found. <118>Setting date via ntp. <118> 3 Aug 19:14:57 ntpdate[1778]: step time server 64.246.132.14 offset -0.389482 sec <118>Clearing /tmp (X related). <118>Starting dhcpd. <118>Aug 3 19:14:58 Border dhcpd: WARNING: Host declarations are global. They are not limited to the scope you declared them in. <118>Starting local daemons:delete net default fib 0 <118>route: writing to routing socket: No such process <118>delete net default fib 1: not in table <118>add net default: gateway 75.133.75.193 fib 0 <118>. <118>Updating motd:. <118>Mounting late file systems:. <118>Starting ntpd. <118>Configuring syscons: blanktime. <118>Performing sanity check on sshd configuration. <118>Starting sshd. <118>Starting cron. <118>Starting hostapd. <118>Configuration file: /etc/hostapd.conf <118>Using interface wlan0 with hwaddr 7c:c3:a1:b3:fc:af and ssid "BlackBox" <118> <118>Sat Aug 3 19:14:59 UTC 2013 <118>Aug 3 20:24:48 Border dhcpd: uid lease 192.168.12.202 for client 60:a4:4c:60:d5:a7 is duplicate on WIRED <118>Aug 3 20:25:24 Border sshd[2029]: error: PAM: authentication error for illegal user sfourman from 192.168.12.32 <118>Aug 3 20:25:27 Border sshd[2029]: error: PAM: authentication error for illegal user sfourman from 192.168.12.32 ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) <118>Aug 3 20:39:51 Border dhcpd: uid lease 192.168.12.211 for client 60:a4:4c:60:d5:a7 is duplicate on WIRED <118>Aug 3 20:40:11 Border last message repeated 2 times <118>Aug 3 20:41:15 Border last message repeated 2 times ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) <118>Aug 3 23:01:11 Border dhcpd: uid lease 192.168.12.202 for client 60:a4:4c:60:d5:a7 is duplicate on WIRED ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) <118>Aug 4 00:52:41 Border dhcpd: uid lease 192.168.12.202 for client 60:a4:4c:60:d5:a7 is duplicate on WIRED ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) ath0: ath_tx_tid_drain_print: norm: node 0xffffff800a9e2000: bf=0xffffff8000cedcc0: addbaw=0, dobaw=0, seqno=164, retry=0 ath0: ath_tx_tid_drain_print: node 0xffffff800a9e2000: bf=0xffffff8000cedcc0: txq[1] axq_depth=0, axq_aggr_depth=0 ath0: ath_tx_tid_drain_print: node 0xffffff800a9e2000: bf=0xffffff8000cedcc0: tid txq_depth=2 hwq_depth=0, bar_wait=0, isfiltered=0 ath0: ath_tx_tid_drain_print: node 0xffffff800a9e2000: tid 0: sched=0, paused=1, incomp=0, baw_head=0, baw_tail=0 txa_start=0, ni_txseqs=166 FRDS 7c:c3:a1:b3:fc:af->78:d6:f0:86:1a:91(7c:c3:a1:b3:fc:af) data QoS [TID 0] 0M c802 0000 78d6 f086 1a91 7cc3 a1b3 fcaf 7cc3 a1b3 fcaf 400a 0000 841a <118>Aug 4 02:00:04 Border login: ROOT LOGIN (root) ON ttyv0 <118>Aug 4 02:02:09 Border dhcpd: uid lease 192.168.12.211 for client 60:a4:4c:60:d5:a7 is duplicate on WIRED <118>Aug 4 02:02:50 Border last message repeated 4 times <118>Aug 4 02:04:22 Border last message repeated 3 times ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) <118>Aug 4 02:26:02 Border dhcpd: uid lease 192.168.12.202 for client 60:a4:4c:60:d5:a7 is duplicate on WIRED ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) <118>Aug 4 03:02:06 Border sm-mta[8412]: r74326P0008412: SYSERR(root): hash map "Alias0": missing map file /etc/mail/aliases.db: No such file or directory <118>Aug 4 03:02:06 Border sm-mta[8414]: r74326P0008412: SYSERR(root): hash map "Alias0": missing map file /etc/mail/aliases.db: No such file or directory <118>Aug 4 03:02:07 Border sm-mta[8422]: r74327QB008422: SYSERR(root): hash map "Alias0": missing map file /etc/mail/aliases.db: No such file or directory <118>Aug 4 03:02:07 Border sm-mta[8423]: r74327QB008422: SYSERR(root): hash map "Alias0": missing map file /etc/mail/aliases.db: No such file or directory ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) ath0: ath_bar_response: huh? bar_tx=0, bar_wait=0 ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=176) ath0: device timeout ath0: device timeout ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) <118>Aug 4 10:37:43 Border dhcpd: uid lease 192.168.12.202 for client 60:a4:4c:60:d5:a7 is duplicate on WIRED ath0: ath_tx_should_swq_frame: 78:d6:f0:86:1a:91: Node is asleep; sending mgmt (type=0, subtype=192) <118>Aug 4 14:32:42 Border dhcpd: WARNING: Host declarations are global. They are not limited to the scope you declared them in. Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 10 fault virtual address = 0x10 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff809937a8 stack pointer = 0x28:0xffffff8000278870 frame pointer = 0x28:0xffffff80002788c0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (swi4: clock) trap number = 12 panic: page fault cpuid = 0 Uptime: 23h57m13s Dumping 2452 out of 8070 MB:^@^@^@^@^@^@^@^@^@^@^@^@^@^ -- Kernel config is as follows... root@Border:/var/crash # cat /usr/src/sys/amd64/conf/BORDER include GENERIC nocpu i486_CPU ident BORDER nooptions WITNESS nooptions INVARIANTS nodevice eisa nodevice fdc nooptions SCTP #Pretty console options SC_NORM_ATTR=(FG_GREEN|BG_BLACK) options SC_NORM_REV_ATTR=(FG_YELLOW|BG_GREEN) options SC_KERNEL_CONS_ATTR=(FG_LIGHTRED|BG_BLACK) options SC_KERNEL_CONS_REV_ATTR=(FG_BLACK|BG_RED) options SC_HISTORY_SIZE=8192 # Firewalling device pf device pflog options ROUTETABLES=6 options ALTQ options ALTQ_HFSC options ALTQ_NOPCC options IPSTEALTH # The nullFS to mount local directory options NULLFS # VIMAGE stuff #makeoptions NO_MODULES=yes #options VIMAGE options NETGRAPH options NETGRAPH_ETHER options NETGRAPH_BRIDGE options NETGRAPH_EIFACE options NETGRAPH_SOCKET device epair device if_bridge # Atheros Wireless NIC card options options AH_DEBUG options ATH_DEBUG options ATH_DIAGAPI nodevice bwn nodevice bwi # Delete Sound support nodevice sound # Generic sound driver (required) nodevice snd_cmi # CMedia CMI8338/CMI8738 nodevice snd_csa # Crystal Semiconductor CS461x/428x nodevice snd_emu10kx # Creative SoundBlaster Live! and Audigy nodevice snd_es137x # Ensoniq AudioPCI ES137x nodevice snd_hda # Intel High Definition Audio nodevice snd_ich # Intel, NVidia and other ICH AC'97 Audio nodevice snd_via8233 # VIA VT8233x Audio root@Border:/var/crash # Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Sun Aug 4 20:00:41 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4CF21CA9 for ; Sun, 4 Aug 2013 20:00:41 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5FA3B27B6 for ; Sun, 4 Aug 2013 20:00:40 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA11939; Sun, 04 Aug 2013 23:00:37 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1V64Tl-000Avj-Dt; Sun, 04 Aug 2013 23:00:37 +0300 Message-ID: <51FEB294.30807@FreeBSD.org> Date: Sun, 04 Aug 2013 22:59:16 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: Garrett Cooper Subject: Re: Build break in dtrace modules at r253772 with gcc References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 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, 04 Aug 2013 20:00:41 -0000 on 02/08/2013 23:29 Garrett Cooper said the following: > r253772 breaks dtrace compiled as a module on amd64 like so when using gcc: I am aware of the problem with dtrace/dtrace module and apologize for it. The easiest way to work around it is to add CWARNFLAGS+= -Wno-cast-qual to the respective Makefile. There is a patch to fix the problem in the C code. > cc1: warnings being treated as errors > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:1184: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:1184: > warning: cast discards qualifiers from pointer target type > --- g_label_iso9660.o --- > --- modules-all --- > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:1265: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:1265: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:1441: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:1441: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:1448: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:1494: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:1498: > warning: cast discards qualifiers from pointer target type > --- g_label_ext2fs.o --- > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=core2 > -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/usr/src/sys -I/usr/src/sys/contrib/altq > -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > -include opt_global.h -fno-common -finline-limit=8000 --param > inline-unit-growth=100 --param large-function-growth=1000 > -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel > -mno-red-zone -mno-mmx -mno-sse -msoft-float > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector > -Werror /usr/src/sys/geom/label/g_label_ext2fs.c > --- modules-all --- > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:1502: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:1891: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:1891: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:1891: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:1891: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:1911: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:1911: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:1916: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:1916: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:1916: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:1916: > warning: cast discards qualifiers from pointer target type > --- g_label_msdosfs.o --- > --- modules-all --- > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:1933: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:1933: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:1935: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:1935: > warning: cast discards qualifiers from pointer target type > --- g_label_msdosfs.o --- > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=core2 > -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/usr/src/sys -I/usr/src/sys/contrib/altq > -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > -include opt_global.h -fno-common -finline-limit=8000 --param > inline-unit-growth=100 --param large-function-growth=1000 > -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel > -mno-red-zone -mno-mmx -mno-sse -msoft-float > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector > -Werror /usr/src/sys/geom/label/g_label_msdosfs.c > --- g_label_ntfs.o --- > --- modules-all --- > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c: > In function 'dtrace_disx86': > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:2606: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:2650: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:2695: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:2699: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:2703: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:2707: > warning: cast discards qualifiers from pointer target type > --- g_label_reiserfs.o --- > --- modules-all --- > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:2752: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:2756: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:2760: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:2769: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:2778: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:2785: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:2827: > warning: cast discards qualifiers from pointer target type > --- g_label_ntfs.o --- > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=core2 > -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/usr/src/sys -I/usr/src/sys/contrib/altq > -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > -include opt_global.h -fno-common -finline-limit=8000 --param > inline-unit-growth=100 --param large-function-growth=1000 > -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel > -mno-red-zone -mno-mmx -mno-sse -msoft-float > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector > -Werror /usr/src/sys/geom/label/g_label_ntfs.c > --- modules-all --- > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:2846: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:2848: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:2856: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:2887: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:2894: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:2895: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:2940: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:2960: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:2962: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:2964: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:2966: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:2969: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:2972: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:2984: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:3045: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:3047: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:3050: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:3076: > warning: cast discards qualifiers from pointer target type > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64/dis_tables.c:3096: > warning: cast discards qualifiers from pointer target type > --- g_label_reiserfs.o --- > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=core2 > -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/usr/src/sys -I/usr/src/sys/contrib/altq > -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > -include opt_global.h -fno-common -finline-limit=8000 --param > inline-unit-growth=100 --param large-function-growth=1000 > -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel > -mno-red-zone -mno-mmx -mno-sse -msoft-float > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector > -Werror /usr/src/sys/geom/label/g_label_reiserfs.c > --- g_label_ufs.o --- > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=core2 > -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/usr/src/sys -I/usr/src/sys/contrib/altq > -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > -include opt_global.h -fno-common -finline-limit=8000 --param > inline-unit-growth=100 --param large-function-growth=1000 > -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel > -mno-red-zone -mno-mmx -mno-sse -msoft-float > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector > -Werror /usr/src/sys/geom/label/g_label_ufs.c > --- g_label_gpt.o --- > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=core2 > -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/usr/src/sys -I/usr/src/sys/contrib/altq > -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > -include opt_global.h -fno-common -finline-limit=8000 --param > inline-unit-growth=100 --param large-function-growth=1000 > -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel > -mno-red-zone -mno-mmx -mno-sse -msoft-float > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector > -Werror /usr/src/sys/geom/label/g_label_gpt.c > --- modules-all --- > *** [dis_tables.o] Error code 1 > > make: stopped in /usr/src/sys/modules/dtrace/dtrace > > > $ uname -a > FreeBSD gran-tourismo.west.isilon.com 10.0-CURRENT FreeBSD > 10.0-CURRENT #2 r+4fbed0e: Sat Jun 22 16:53:12 PDT 2013 > gcooper@gran-tourismo.west.isilon.com:/usr/obj/usr/src/sys/GRAN-TOURISMO > amd64 > > My KERNCONFs, make.conf, and src.conf are provided for reference. > > Thanks, > -Garrett > -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Aug 4 22:52:11 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2F49E1F6 for ; Sun, 4 Aug 2013 22:52:11 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8DE442CEC for ; Sun, 4 Aug 2013 22:52:10 +0000 (UTC) Received: by mail-la0-f43.google.com with SMTP id ep20so1581527lab.2 for ; Sun, 04 Aug 2013 15:52:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=qcCf0OJnHmbE7KJGocHBy8n2UFqWnLA97jCXRJJeZI0=; b=NMSyZxR6O741MnWGkUHHvdyl6JNlhYRVsJh0ij6Te/aFDJkBDui/2kXsPH0/XYF28i rgXvT2yHIb2KNzMMhuNTJRAOEL8lVWyeNNavidMD4UfRiLFm6bv59qJAsuwNCWTNaNfK rnziHF++poHrWqJrYaxEuBItPg8xt5eCXDkWQG0d3kUECWBxzoyPmqFxhi6Sk4CrE3dl rDmU1E8tteKjMwEE4T74OK90upvs+cUVUh8/lmZRpURPcnI+W38/jat4pe4pXk/Kq0O/ fl7qk+Y2hnsCkHUyY+gYU70WRWNSKjTVo06OeMH8OY1P2uAuwvAr6wsIC6FacVrsGqAX s4JQ== MIME-Version: 1.0 X-Received: by 10.112.20.137 with SMTP id n9mr7746455lbe.20.1375656728340; Sun, 04 Aug 2013 15:52:08 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.22.100 with HTTP; Sun, 4 Aug 2013 15:52:08 -0700 (PDT) In-Reply-To: References: Date: Sun, 4 Aug 2013 15:52:08 -0700 X-Google-Sender-Auth: 9JF1fC-ZJlpNVpUcoG7fNZyokiU Message-ID: Subject: Re: Kernel Panic on FreeBSD 10.0-CURRENT #1 r253918 From: Craig Rodrigues To: "Sam Fourman Jr." Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current 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, 04 Aug 2013 22:52:11 -0000 On Sun, Aug 4, 2013 at 12:33 PM, Sam Fourman Jr. wrote: > hello list, > > could someone help me figure out why this machine kernel paniced? > I have a full crashdump file if needed, > this machine is configured as a Firewall and wifi hostap running pf in a > small office > > > here is a mailing list post to someone that had a similar problem a few > years back > http://lists.freebsd.org/pipermail/freebsd-bugs/2011-April/043985.html > > a backtrace, full dmesg, and kernel config are below > > > kgdb /boot/kernel/kernel /var/crash/vmcore.0 > #4 0xffffffff80bd6027 in trap_pfault (frame=0x0, usermode= out>) at /usr/src/sys/amd64/amd64/trap.c:699 > #5 0xffffffff80bd5876 in trap (frame=0xffffff80002787c0) at > /usr/src/sys/amd64/amd64/trap.c:463 > #6 0xffffffff80bc06b2 in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:232 > #7 0xffffffff809937a8 in in6_tmpaddrtimer (arg=0xfffffe00170fc0b6) at > /usr/src/sys/netinet6/in6_ifattach.c:935 > #8 0xffffffff8085140a in softclock_call_cc (c=0xffffffff81325210, > cc=0xffffffff8131c700, direct=0) at /usr/src/sys/kern/kern_timeout.c:674 > #9 0xffffffff80851704 in softclock (arg=) at > /usr/src/sys/kern/kern_timeout.c:802 > #10 0xffffffff80815dc3 in intr_event_execute_handlers (p= out>, ie=0xfffffe0014ab3400) at /usr/src/sys/kern/kern_intr.c:1263 > #11 0xffffffff80816716 in ithread_loop (arg=0xfffffe0014a896e0) at > /usr/src/sys/kern/kern_intr.c:1276 > #12 0xffffffff80813b31 in fork_exit (callout=0xffffffff80816680 > , arg=0xfffffe0014a896e0, frame=0xffffff8000278a40) at > /usr/src/sys/kern/kern_fork.c:991 > #13 0xffffffff80bc0bee in fork_trampoline () at > /usr/src/sys/amd64/amd64/exception.S:606 > #14 0x0000000000000000 in ?? () > Current language: auto; currently minimal > (kgdb) > > > You have VIMAGE enabled in your kernel config. I have debugged a few of these VIMAGE problems before. Can you do the following for me: (1) Download John's gdb scripts from: http://people.freebsd.org/~jhb/gdb/ . Put them in a directory such as $HOME/gdb/ (2) Go to the kernel source directory. You must be in this directory for the gdb macros to work: cd /usr/src (3) Start kgdb: kgdb /usr/obj/sys/conf/GENERIC/kernel.debug /var/crash/vmcore [ tune that line to where your kernel.debug is ] (4) Load the gdb scripts: source /home/mydir/gdb/gdb6 (5) Go to the frame where the problem occurred. For you it is in frame 7 in6_tmpaddrtimer.c (kgdb) frame 7 (6) Find the thread id of the active thread using this: (kgdb) i thr There will be an asterisk besides the active thread such as: * 301 Thread 100515 (PID=551: at-spi-bus-launcher) 0xffffffff8094fdc6 in sched_switch (td=0xfffffe0009f43000, newtd=, (7) Using the thread id obtain in step 6, look up the value of curthread, and assign it to the $td variable, for example: (kgdb) lookup_thread 301 $td 0 (8) Print out the value of $td and derference it just like any other gdb variable (kgdb) p $td (9) Print out the value of td->td_vnet (kgdb) p $td->td_vnet I suspect td_vnet is NULL, but please confirm. -- Craig From owner-freebsd-current@FreeBSD.ORG Sun Aug 4 22:59:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F268C433; Sun, 4 Aug 2013 22:59:57 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-vb0-x22e.google.com (mail-vb0-x22e.google.com [IPv6:2607:f8b0:400c:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9E61A2D47; Sun, 4 Aug 2013 22:59:57 +0000 (UTC) Received: by mail-vb0-f46.google.com with SMTP id p13so2194757vbe.5 for ; Sun, 04 Aug 2013 15:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=grhjmaP2yzCtM6Kdp4NZ3y8IBBD3mYr6E8Zasd/RInw=; b=gKn5F2T9zXOhzkwZ2tvnJI32+F/TJRBaM7xuAErpmtaEIMW9RC4E6Zpi1nDxDLfHvw pff6j25FfRZ8Mi4liMA0llaiEGifScC8N97MLjWgV/qHlfewcZk81TcJpOPg4XQdDJDg 4VXn0/IQhQwQPdBPSXekuQeFtsV0CTcJVPcemPLqJ/KRafVLRPdd5u3TsgB6iwmvPOA1 YUeJDu8d1vV07HoIUm/ICk/pTpZvskzOQgANBBeNkofs6GLjwvvkpIMMcF1Vn4WxjfcK uhWnuJq+16QYPknEqeiBE98c3Ftcthv/5kTt0gzbN36R33N1XDENjQUL1yetz/pAH9cc d4cg== MIME-Version: 1.0 X-Received: by 10.52.165.239 with SMTP id zb15mr4133269vdb.44.1375657196649; Sun, 04 Aug 2013 15:59:56 -0700 (PDT) Received: by 10.220.96.78 with HTTP; Sun, 4 Aug 2013 15:59:56 -0700 (PDT) In-Reply-To: References: Date: Sun, 4 Aug 2013 18:59:56 -0400 Message-ID: Subject: Re: Kernel Panic on FreeBSD 10.0-CURRENT #1 r253918 From: "Sam Fourman Jr." To: Craig Rodrigues Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current 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, 04 Aug 2013 22:59:58 -0000 On Sun, Aug 4, 2013 at 6:52 PM, Craig Rodrigues wrote: > On Sun, Aug 4, 2013 at 12:33 PM, Sam Fourman Jr. wrote: > >> hello list, >> >> could someone help me figure out why this machine kernel paniced? >> I have a full crashdump file if needed, >> this machine is configured as a Firewall and wifi hostap running pf in a >> small office >> >> >> here is a mailing list post to someone that had a similar problem a few >> years back >> http://lists.freebsd.org/pipermail/freebsd-bugs/2011-April/043985.html >> >> a backtrace, full dmesg, and kernel config are below >> >> >> kgdb /boot/kernel/kernel /var/crash/vmcore.0 >> #4 0xffffffff80bd6027 in trap_pfault (frame=0x0, usermode=> optimized >> out>) at /usr/src/sys/amd64/amd64/trap.c:699 >> #5 0xffffffff80bd5876 in trap (frame=0xffffff80002787c0) at >> /usr/src/sys/amd64/amd64/trap.c:463 >> #6 0xffffffff80bc06b2 in calltrap () at >> /usr/src/sys/amd64/amd64/exception.S:232 >> #7 0xffffffff809937a8 in in6_tmpaddrtimer (arg=0xfffffe00170fc0b6) at >> /usr/src/sys/netinet6/in6_ifattach.c:935 >> #8 0xffffffff8085140a in softclock_call_cc (c=0xffffffff81325210, >> cc=0xffffffff8131c700, direct=0) at /usr/src/sys/kern/kern_timeout.c:674 >> #9 0xffffffff80851704 in softclock (arg=) at >> /usr/src/sys/kern/kern_timeout.c:802 >> #10 0xffffffff80815dc3 in intr_event_execute_handlers (p=> out>, ie=0xfffffe0014ab3400) at /usr/src/sys/kern/kern_intr.c:1263 >> #11 0xffffffff80816716 in ithread_loop (arg=0xfffffe0014a896e0) at >> /usr/src/sys/kern/kern_intr.c:1276 >> #12 0xffffffff80813b31 in fork_exit (callout=0xffffffff80816680 >> , arg=0xfffffe0014a896e0, frame=0xffffff8000278a40) at >> /usr/src/sys/kern/kern_fork.c:991 >> #13 0xffffffff80bc0bee in fork_trampoline () at >> /usr/src/sys/amd64/amd64/exception.S:606 >> #14 0x0000000000000000 in ?? () >> Current language: auto; currently minimal >> (kgdb) >> >> >> > > You have VIMAGE enabled in your kernel config. I have debugged a few of > these VIMAGE problems > before. > > Can you do the following for me: > > Craig, Thank you for getting back to me, I will get to work on this right away and get you what you need. but are we CERTAIN this panic could be from VIMAGE? I totally thought I had a # infront of that line when I built this kernel... if you notice I did post the kernel config at the bottom of that email, and VIMAGE is NOT included... but maybe I did something wrong and somehow built VIMAGE in anyway.. is there some sort of command I can run to ask the system if it does indeed have VIMAGE? -- Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Sun Aug 4 23:24:04 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7FDBA924; Sun, 4 Aug 2013 23:24:04 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5EE612E2C; Sun, 4 Aug 2013 23:24:04 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.6/8.14.6) with ESMTP id r74NNwKr006103; Sun, 4 Aug 2013 16:23:58 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.6/8.14.6/Submit) id r74NNwnD006102; Sun, 4 Aug 2013 16:23:58 -0700 (PDT) (envelope-from sgk) Date: Sun, 4 Aug 2013 16:23:58 -0700 From: Steve Kargl To: Glen Barber Subject: Re: svn error during 'make buildkernel'? Message-ID: <20130804232358.GA6068@troutmask.apl.washington.edu> References: <20130803210348.GA715@troutmask.apl.washington.edu> <20130803210858.GJ78299@glenbarber.us> <20130803213023.GA812@troutmask.apl.washington.edu> <20130803214313.GL78299@glenbarber.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130803214313.GL78299@glenbarber.us> 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, 04 Aug 2013 23:24:04 -0000 On Sat, Aug 03, 2013 at 05:43:13PM -0400, Glen Barber wrote: > On Sat, Aug 03, 2013 at 02:30:23PM -0700, Steve Kargl wrote: > > > > Thanks. > > > > Looks like an entry in /usr/src/UPDATING is missing if > > /usr/bin/svn* is forcing an obsolscence of a functioning > > installed port. > > > > The port was at 1.8.x before I added the additional lookup of > svnlite to the script. There really is no need for UPDATING entry, > since 1.7.9 is deprecated, and the behavior you have seen is not a fatal > error with the buildkernel process. > > BTW, you should upgrade devel/subversion anyway, since there are > security vulnerabilities. > Here's a perfect example why chasing the bleeding edge ports is a stupid idea. After upgrading devel/subversion as you suggested, I see cd /usr/ports % svn upgrade % svn update Updating '.': svn: E170000: Unrecognized URL scheme for 'http://svn.freebsd.org/ports/head' % svn --version | grep version svn, version 1.8.1 (r1503906) % which svn /usr/local/bin/svn %which svnlite /usr/bin/svnlite % svnlite --version | grep version svn, version 1.8.1 (r1503906) Subversion is open source software, see http://subversion.apache.org/ % svnlite % svnlite update Updating '.': U www/squid33/distinfo U www/squid33/files/squid.in U www/squid33/Makefile U cad/gmsh/Makefile U cad/gmsh/distinfo U cad/gmsh/pkg-plist U lang/gcc47/Makefile U lang/gcc47/distinfo U lang/gdc/Makefile U x11-clocks/xdaliclock/Makefile U x11-clocks/xdaliclock/distinfo U net-mgmt/virt-viewer/Makefile U net-mgmt/virt-viewer/distinfo U net-mgmt/virt-viewer/pkg-plist U x11/xfwp/Makefile U x11/xfwp/distinfo Updated to revision 324253. So, how do I fix svn, now? -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Aug 4 23:27:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E6ED4B2B for ; Sun, 4 Aug 2013 23:27:58 +0000 (UTC) (envelope-from dieterich.joh@gmail.com) Received: from mail-gh0-x229.google.com (mail-gh0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A84992E4A for ; Sun, 4 Aug 2013 23:27:58 +0000 (UTC) Received: by mail-gh0-f169.google.com with SMTP id r1so1037246ghr.28 for ; Sun, 04 Aug 2013 16:27:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=dXL0C+lBV4qSTAzgBum/W5wcX/Er9NT8xKxzRJDbLlA=; b=HFvwtMkCAf+pgzkczcivFYuPtepuCKSETBdzEDKbA7Z6vGzxH9Y5wzA89DcZbnbnvJ 6RwYQbiIv22xCSNmN1dcbIR46I2/etZl+goXHIv8yRWAfK0H3ZD77kVoMozlbC7PpXTX tsN/LxVKQ46JFMqiE+x3+dsdSXG831AcrLLt35/C8Z7VNWOwwOu4K8aChkKCrHEqcIGg t3A3v9WJgqWs9YdYrXsUwJ9RkU4B+9+vXzWXY/a5OUKBJMWDotqWxwefA/08wSe6eIxC pC/jHfgpw0GB5TAk6v27grEhG7j39gEgy8NOyGa21/P3+o8hNM1zb2yp0umGquP7kecJ l8Fg== X-Received: by 10.236.163.138 with SMTP id a10mr3993795yhl.111.1375658877806; Sun, 04 Aug 2013 16:27:57 -0700 (PDT) Received: from bresson.poelloepaeae.de (jd-t430s.Princeton.EDU. [128.112.34.82]) by mx.google.com with ESMTPSA id f67sm32170960yhh.9.2013.08.04.16.27.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 04 Aug 2013 16:27:57 -0700 (PDT) Message-ID: <51FEE37B.9090205@gmail.com> Date: Sun, 04 Aug 2013 19:27:55 -0400 From: Johannes Dieterich User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130731 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-current@freebsd.org, Steve Kargl Subject: Re: svn error during 'make buildkernel'? References: <20130803210348.GA715@troutmask.apl.washington.edu> <20130803210858.GJ78299@glenbarber.us> <20130803213023.GA812@troutmask.apl.washington.edu> <20130803214313.GL78299@glenbarber.us> <20130804232358.GA6068@troutmask.apl.washington.edu> In-Reply-To: <20130804232358.GA6068@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 04 Aug 2013 23:27:59 -0000 Hi, On 08/04/13 19:23, Steve Kargl wrote: > On Sat, Aug 03, 2013 at 05:43:13PM -0400, Glen Barber wrote: >> On Sat, Aug 03, 2013 at 02:30:23PM -0700, Steve Kargl wrote: >>> >>> Thanks. >>> >>> Looks like an entry in /usr/src/UPDATING is missing if >>> /usr/bin/svn* is forcing an obsolscence of a functioning >>> installed port. >>> >> >> The port was at 1.8.x before I added the additional lookup of >> svnlite to the script. There really is no need for UPDATING entry, >> since 1.7.9 is deprecated, and the behavior you have seen is not a fatal >> error with the buildkernel process. >> >> BTW, you should upgrade devel/subversion anyway, since there are >> security vulnerabilities. >> > > Here's a perfect example why chasing the bleeding edge ports > is a stupid idea. After upgrading devel/subversion as you > suggested, I see > > cd /usr/ports > % svn upgrade > % svn update > Updating '.': > svn: E170000: Unrecognized URL scheme for 'http://svn.freebsd.org/ports/head' > % svn --version | grep version > svn, version 1.8.1 (r1503906) > % which svn > /usr/local/bin/svn > %which svnlite > /usr/bin/svnlite > % svnlite --version | grep version > svn, version 1.8.1 (r1503906) > Subversion is open source software, see http://subversion.apache.org/ > % svnlite > % svnlite update > Updating '.': > U www/squid33/distinfo > U www/squid33/files/squid.in > U www/squid33/Makefile > U cad/gmsh/Makefile > U cad/gmsh/distinfo > U cad/gmsh/pkg-plist > U lang/gcc47/Makefile > U lang/gcc47/distinfo > U lang/gdc/Makefile > U x11-clocks/xdaliclock/Makefile > U x11-clocks/xdaliclock/distinfo > U net-mgmt/virt-viewer/Makefile > U net-mgmt/virt-viewer/distinfo > U net-mgmt/virt-viewer/pkg-plist > U x11/xfwp/Makefile > U x11/xfwp/distinfo > Updated to revision 324253. > > So, how do I fix svn, now? You need to enable the SERF option for the port and rebuild, it is now required to be able to access http/https-type repositories. Hope this helps Johannes From owner-freebsd-current@FreeBSD.ORG Sun Aug 4 23:28:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 571EBC2C; Sun, 4 Aug 2013 23:28:03 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [IPv6:2607:fc50:1:2300:1001:1001:1001:face]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2C6102E4E; Sun, 4 Aug 2013 23:28:03 +0000 (UTC) Received: from glenbarber.us (c-71-224-221-174.hsd1.nj.comcast.net [71.224.221.174]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 0B328889A; Sun, 4 Aug 2013 23:28:02 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 0B328889A Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Sun, 4 Aug 2013 19:28:00 -0400 From: Glen Barber To: Steve Kargl Subject: Re: svn error during 'make buildkernel'? Message-ID: <20130804232800.GJ2352@glenbarber.us> References: <20130803210348.GA715@troutmask.apl.washington.edu> <20130803210858.GJ78299@glenbarber.us> <20130803213023.GA812@troutmask.apl.washington.edu> <20130803214313.GL78299@glenbarber.us> <20130804232358.GA6068@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ofZMSlrAVk9bLeVm" Content-Disposition: inline In-Reply-To: <20130804232358.GA6068@troutmask.apl.washington.edu> X-Operating-System: FreeBSD 10.0-CURRENT amd64 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, 04 Aug 2013 23:28:03 -0000 --ofZMSlrAVk9bLeVm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 04, 2013 at 04:23:58PM -0700, Steve Kargl wrote: > Here's a perfect example why chasing the bleeding edge ports > is a stupid idea. After upgrading devel/subversion as you > suggested, I see >=20 They are not "bleeding edge ports", they are updates to ported software. > cd /usr/ports > % svn upgrade > % svn update > Updating '.': > svn: E170000: Unrecognized URL scheme for 'http://svn.freebsd.org/ports/h= ead' Did you enable the SERF option? If not, then clearly adding an UPDATING entry is pointless anyway, since you did not read the ports/UPDATING entry 20130619. Glen --ofZMSlrAVk9bLeVm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBCAAGBQJR/uOAAAoJEFJPDDeguUaj+7wH/2SdridbMweqNkgUz2/2MGMB anyZYHNs3KKFwqEvRAxg3nwCZIbM1UYHCZGYVmirqU+2L6poHD3OazO3HZFx/Hsj cfGGtem5spAuyp2z4YXHJMV48ScVoxJTqIOw4nMyU/hCVwo+ITsCJgbiupOBrUs5 CMbyXBXsftMFgQp5wGaXVS9rJOhUdKR0soqqCEt9RPbhmpNoT9034Ia8cNrTIjUi jkyPTvIItRZcyA5wd2+TySQOD05S/3AxZaNM2hp3Kpf13oT/2K5+l5xUr5cP6DCI Pi6xoD36pY/zHBy7Jy+cR6ZcZksdQnNmV13BhhdbOxlMgX8ERvBGiCCOEYokSgI= =Mp3y -----END PGP SIGNATURE----- --ofZMSlrAVk9bLeVm-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 4 23:51:10 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 22F8D14C for ; Sun, 4 Aug 2013 23:51:10 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D1D9C2EDE for ; Sun, 4 Aug 2013 23:51:09 +0000 (UTC) Received: by mail-ve0-f173.google.com with SMTP id cy12so2453388veb.32 for ; Sun, 04 Aug 2013 16:51:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=T5OU8oHeqbjGtPFg3r2yQYSpJTaw9J2kr1V045cjirI=; b=SfAZCtY9WebuH/61Zm0lRO+VxtgjZ6zQl1pg6eojBWJdq1xC70x9BtUVQOwDTaauMw Xv2HIXTmxJQxnITYj++Qj5QNl72UMv2nRKQ9l3zz/sbQh2tEJbj2W9r5yODzh44gFOMF wHUsdGDidpvsE7Hlxh9L856CZjvxZI0/r5U6w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=T5OU8oHeqbjGtPFg3r2yQYSpJTaw9J2kr1V045cjirI=; b=CF4VV81Gq7wQ3a2A5Qk9RdntMYEi3D9h7ykkuD2u2pi+OkYKvqQDk0SsA5gwE23r07 8dTu9+bGwlBRinai82MCEMCxmMQKsjAPsb9u3aa7thDiKRmOd7XaM/QkPttgJGSYlSqv 4vq4AECApk+1nflTgzLY47UlLliRxToaLFXvHmXDXLSAUTP7XAoygtzEIcmj1OsHSKj6 6wZruHvKLn09U64ZQXxQmDDb4wmKvyNvIrhKhLkq+bAxWtyeOF7BXsBH4mYYCsXNWGMq jVoJli91SO8VZea7tacfWYzKJ90YJvwNFlu7BCxs/YoH3grJzHfTWLpK/o6P0TghgvYd mDZw== MIME-Version: 1.0 X-Received: by 10.59.2.167 with SMTP id bp7mr4869596ved.67.1375660268852; Sun, 04 Aug 2013 16:51:08 -0700 (PDT) Received: by 10.220.167.74 with HTTP; Sun, 4 Aug 2013 16:51:08 -0700 (PDT) In-Reply-To: <20130804232358.GA6068@troutmask.apl.washington.edu> References: <20130803210348.GA715@troutmask.apl.washington.edu> <20130803210858.GJ78299@glenbarber.us> <20130803213023.GA812@troutmask.apl.washington.edu> <20130803214313.GL78299@glenbarber.us> <20130804232358.GA6068@troutmask.apl.washington.edu> Date: Sun, 4 Aug 2013 16:51:08 -0700 Message-ID: Subject: Re: svn error during 'make buildkernel'? From: Peter Wemm To: Steve Kargl Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnuRHTaYXE4KUouVmUgA4y6DTEew+OrEyIVn+K3339jfyX2Ib1d7bdmfiSn5rdc61jtX4ic 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, 04 Aug 2013 23:51:10 -0000 On Sun, Aug 4, 2013 at 4:23 PM, Steve Kargl wrote: > On Sat, Aug 03, 2013 at 05:43:13PM -0400, Glen Barber wrote: >> On Sat, Aug 03, 2013 at 02:30:23PM -0700, Steve Kargl wrote: >> > >> > Thanks. >> > >> > Looks like an entry in /usr/src/UPDATING is missing if >> > /usr/bin/svn* is forcing an obsolscence of a functioning >> > installed port. >> > >> >> The port was at 1.8.x before I added the additional lookup of >> svnlite to the script. There really is no need for UPDATING entry, >> since 1.7.9 is deprecated, and the behavior you have seen is not a fatal >> error with the buildkernel process. >> >> BTW, you should upgrade devel/subversion anyway, since there are >> security vulnerabilities. >> > > Here's a perfect example why chasing the bleeding edge ports > is a stupid idea. After upgrading devel/subversion as you > suggested, I see > > cd /usr/ports > % svn upgrade > % svn update > Updating '.': > svn: E170000: Unrecognized URL scheme for 'http://svn.freebsd.org/ports/head' > % svn --version | grep version > svn, version 1.8.1 (r1503906) > % which svn > /usr/local/bin/svn > %which svnlite > /usr/bin/svnlite > % svnlite --version | grep version > svn, version 1.8.1 (r1503906) > Subversion is open source software, see http://subversion.apache.org/ > % svnlite > % svnlite update > Updating '.': > U www/squid33/distinfo > U www/squid33/files/squid.in > U www/squid33/Makefile > U cad/gmsh/Makefile > U cad/gmsh/distinfo > U cad/gmsh/pkg-plist > U lang/gcc47/Makefile > U lang/gcc47/distinfo > U lang/gdc/Makefile > U x11-clocks/xdaliclock/Makefile > U x11-clocks/xdaliclock/distinfo > U net-mgmt/virt-viewer/Makefile > U net-mgmt/virt-viewer/distinfo > U net-mgmt/virt-viewer/pkg-plist > U x11/xfwp/Makefile > U x11/xfwp/distinfo > Updated to revision 324253. > > So, how do I fix svn, now? ports/UPDATING: 20130619: AFFECTS: users of devel/subversion AUTHOR: ohauer@FreeBSD.org devel/subversion has been upgraded from 1.7.10 to 1.8.0 If you want to upgrade, and use http/https access to repositories, please check, that SERF option is enabled, as NEON support ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ is gone. Also, mod_dontdothat and svnauthz_validate are now eanbled with one option TOOLS, among other new tools and SVNMUCC is enabled always. subversion-1.7.x is available as devel/subversion17 -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV UTF-8: So you can \342\200\231 .. for when a ' just won't do ZFS must be the bacon of file systems. "everything's better with ZFS" From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 00:12:34 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 33F56405 for ; Mon, 5 Aug 2013 00:12:34 +0000 (UTC) (envelope-from bryanv@daemoninthecloset.org) Received: from torment.daemoninthecloset.org (torment.daemoninthecloset.org [94.242.209.234]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EAF372F71 for ; Mon, 5 Aug 2013 00:12:33 +0000 (UTC) Received: from sage.daemoninthecloset.org (unknown [70.114.209.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sage.daemoninthecloset.org", Issuer "daemoninthecloset.org" (verified OK)) by torment.daemoninthecloset.org (Postfix) with ESMTPS id DC1FE42C08C4 for ; Mon, 5 Aug 2013 02:16:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at daemoninthecloset.org X-Virus-Scanned: amavisd-new at daemoninthecloset.org Date: Sun, 4 Aug 2013 19:12:17 -0500 (CDT) From: Bryan Venteicher To: current@freebsd.org Message-ID: <601099152.721.1375661537866.JavaMail.root@daemoninthecloset.org> In-Reply-To: <1050637258.686.1375660230986.JavaMail.root@daemoninthecloset.org> Subject: [CFT] VMware vmxnet3 ethernet driver MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [192.168.10.20] X-Mailer: Zimbra 8.0.2_GA_5569 (ZimbraWebClient - GC20 ([unknown])/8.0.2_GA_5569) Thread-Topic: VMware vmxnet3 ethernet driver Thread-Index: 53UDZogjsC0f1OuMIle9ebXg7GUjTw== 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, 05 Aug 2013 00:12:34 -0000 Hi, I've ported the OpenBSD vmxnet3 ethernet driver to FreeBSD. I did a lot of cleanup, bug fixes, new features, etc (+2000 new lines) along the way so there is not much of a resemblance left. The driver is in good enough shape I'd like additional testers. A patch against -CURRENT is at [1]. Alternatively, the driver and a Makefile is at [2]; this should compile at least as far back as 9.1. I can look at 8-STABLE if there is interest. Obviously, besides reports of 'it works', I'm interested performance vs the emulated e1000, and (for those using it) the VMware tools vmxnet3 driver. Hopefully it is no worse :) The drivers supports most VMXNET3 features - IPv4/IPv6 checksum offload, TSO, LRO, VLAN tag offload. AFAIK, the only notable missing feature is multiqueue; 3/4 of the code needed is already in the driver, but I don't have time to do final bit of work. Most of the development was done on QEMU 1.5, but also tested on VMware Fusion and VMware ESXi. [1] - http://people.freebsd.org/~bryanv/vmware/if_vmx.patch [2] - http://people.freebsd.org/~bryanv/vmware/files/ From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 00:44:34 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1CA9E989 for ; Mon, 5 Aug 2013 00:44:34 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F38FC2056 for ; Mon, 5 Aug 2013 00:44:33 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.6/8.14.6) with ESMTP id r750iXRu006413; Sun, 4 Aug 2013 17:44:33 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.6/8.14.6/Submit) id r750iXWT006412; Sun, 4 Aug 2013 17:44:33 -0700 (PDT) (envelope-from sgk) Date: Sun, 4 Aug 2013 17:44:33 -0700 From: Steve Kargl To: Peter Wemm Subject: Re: svn error during 'make buildkernel'? Message-ID: <20130805004433.GA6355@troutmask.apl.washington.edu> References: <20130803210348.GA715@troutmask.apl.washington.edu> <20130803210858.GJ78299@glenbarber.us> <20130803213023.GA812@troutmask.apl.washington.edu> <20130803214313.GL78299@glenbarber.us> <20130804232358.GA6068@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Mon, 05 Aug 2013 00:44:34 -0000 On Sun, Aug 04, 2013 at 04:51:08PM -0700, Peter Wemm wrote: > On Sun, Aug 4, 2013 at 4:23 PM, Steve Kargl > wrote: > > On Sat, Aug 03, 2013 at 05:43:13PM -0400, Glen Barber wrote: > >> On Sat, Aug 03, 2013 at 02:30:23PM -0700, Steve Kargl wrote: > >> > > >> > Thanks. > >> > > >> > Looks like an entry in /usr/src/UPDATING is missing if > >> > /usr/bin/svn* is forcing an obsolscence of a functioning > >> > installed port. > >> > > >> > >> The port was at 1.8.x before I added the additional lookup of > >> svnlite to the script. There really is no need for UPDATING entry, > >> since 1.7.9 is deprecated, and the behavior you have seen is not a fatal > >> error with the buildkernel process. > >> > >> BTW, you should upgrade devel/subversion anyway, since there are > >> security vulnerabilities. > > > > Here's a perfect example why chasing the bleeding edge ports > > is a stupid idea. After upgrading devel/subversion as you > > suggested, I see > > > > cd /usr/ports > > % svn upgrade > > % svn update > > Updating '.': > > svn: E170000: Unrecognized URL scheme for 'http://svn.freebsd.org/ports/head' > > % svn --version | grep version > > svn, version 1.8.1 (r1503906) > > % which svn > > /usr/local/bin/svn > > %which svnlite > > /usr/bin/svnlite > > % svnlite --version | grep version > > svn, version 1.8.1 (r1503906) > > Subversion is open source software, see http://subversion.apache.org/ > > % svnlite > > % svnlite update > > Updating '.': > > U www/squid33/distinfo > > U www/squid33/files/squid.in > > U www/squid33/Makefile > > U cad/gmsh/Makefile > > U cad/gmsh/distinfo > > U cad/gmsh/pkg-plist > > U lang/gcc47/Makefile > > U lang/gcc47/distinfo > > U lang/gdc/Makefile > > U x11-clocks/xdaliclock/Makefile > > U x11-clocks/xdaliclock/distinfo > > U net-mgmt/virt-viewer/Makefile > > U net-mgmt/virt-viewer/distinfo > > U net-mgmt/virt-viewer/pkg-plist > > U x11/xfwp/Makefile > > U x11/xfwp/distinfo > > Updated to revision 324253. > > > > So, how do I fix svn, now? > > ports/UPDATING: > > 20130619: > AFFECTS: users of devel/subversion > AUTHOR: ohauer@FreeBSD.org > > devel/subversion has been upgraded from 1.7.10 to 1.8.0 > > If you want to upgrade, and use http/https access to repositories, > please check, that SERF option is enabled, as NEON support > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I did not want to upgrade. It was suggested/forced on me by revisio 252505 of newvers.sh that looks for svnliteversion instead of the installed svnversion. 1.7.9 was working fine. -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 00:50:29 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6113CAC7; Mon, 5 Aug 2013 00:50:29 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 271332077; Mon, 5 Aug 2013 00:50:29 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.6/8.14.6) with ESMTP id r750oSf9006436; Sun, 4 Aug 2013 17:50:28 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.6/8.14.6/Submit) id r750oSRk006435; Sun, 4 Aug 2013 17:50:28 -0700 (PDT) (envelope-from sgk) Date: Sun, 4 Aug 2013 17:50:28 -0700 From: Steve Kargl To: Glen Barber Subject: Re: svn error during 'make buildkernel'? Message-ID: <20130805005028.GB6355@troutmask.apl.washington.edu> References: <20130803210348.GA715@troutmask.apl.washington.edu> <20130803210858.GJ78299@glenbarber.us> <20130803213023.GA812@troutmask.apl.washington.edu> <20130803214313.GL78299@glenbarber.us> <20130804232358.GA6068@troutmask.apl.washington.edu> <20130804232800.GJ2352@glenbarber.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130804232800.GJ2352@glenbarber.us> 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: Mon, 05 Aug 2013 00:50:29 -0000 On Sun, Aug 04, 2013 at 07:28:00PM -0400, Glen Barber wrote: > On Sun, Aug 04, 2013 at 04:23:58PM -0700, Steve Kargl wrote: > > Here's a perfect example why chasing the bleeding edge ports > > is a stupid idea. After upgrading devel/subversion as you > > suggested, I see > > > > They are not "bleeding edge ports", they are updates to ported software. > > > cd /usr/ports > > % svn upgrade > > % svn update > > Updating '.': > > svn: E170000: Unrecognized URL scheme for 'http://svn.freebsd.org/ports/head' > > Did you enable the SERF option? > > If not, then clearly adding an UPDATING entry is pointless anyway, since > you did not read the ports/UPDATING entry 20130619. > Given that you failed to add info to src/UPDATING about the need for subversion 1.8.0 (or newer) if svnlite is also installed, why would you expect one to think that a change to devel/subversion would be documented in ports/UPDATING. Please fix your commit. See my first email in this thread for the problem. If you are disinclined to fix your commit, then consider this an official request to back out revision 252505. -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 00:55:34 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 21B55C16; Mon, 5 Aug 2013 00:55:34 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E835D20A5; Mon, 5 Aug 2013 00:55:33 +0000 (UTC) Received: from glenbarber.us (c-71-224-221-174.hsd1.nj.comcast.net [71.224.221.174]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 0AF23805F; Mon, 5 Aug 2013 00:55:31 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 0AF23805F Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Sun, 4 Aug 2013 20:55:30 -0400 From: Glen Barber To: Steve Kargl Subject: Re: svn error during 'make buildkernel'? Message-ID: <20130805005530.GL2352@glenbarber.us> References: <20130803210348.GA715@troutmask.apl.washington.edu> <20130803210858.GJ78299@glenbarber.us> <20130803213023.GA812@troutmask.apl.washington.edu> <20130803214313.GL78299@glenbarber.us> <20130804232358.GA6068@troutmask.apl.washington.edu> <20130805004433.GA6355@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zHDeOHGDnzKksZSU" Content-Disposition: inline In-Reply-To: <20130805004433.GA6355@troutmask.apl.washington.edu> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, Peter Wemm 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, 05 Aug 2013 00:55:34 -0000 --zHDeOHGDnzKksZSU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 04, 2013 at 05:44:33PM -0700, Steve Kargl wrote: > > If you want to upgrade, and use http/https access to repositories, > > please check, that SERF option is enabled, as NEON support > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >=20 > I did not want to upgrade. It was suggested/forced on me > by revisio 252505 of newvers.sh that looks for svnliteversion instead > of the installed svnversion. 1.7.9 was working fine. >=20 You were not forced to do anything. If svn 1.7.9 works, great. Use it. The error generated is non-fatal, and once I receive response on a proposed patch, will be suppressed if the svn version used to check out the tree is not compatible with that used to check the version of the tree with the kernel build. But seriously, this is -CURRENT. Things change. Glen --zHDeOHGDnzKksZSU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBCAAGBQJR/vgCAAoJEFJPDDeguUajYLkH/3bsvN/Poe8nkyXNHQgEUfLC UA9KoX4PPRKvcxN2EEn2ZtylzXHfuKNxSA/XtvjJ7/2fhqCE7FLtFWlWud8PigKv q7hDJGATUlaZihu9skyY6Z2CNG2tlCDiKu7CXl4dTprbyRGuZmmV6OrLCQmSg/K8 rjn481aaaVhTJR4AGOzq3GeIT185ZJfm0JLvCPtJF4QrqX4Mv1R8WSElFGgsZJhB vjr027bSSgZl83CpbElglkw9rASJIGZbMgCLTvoJXUZ2kWmYiK+61pGh4sp5Sot7 IhPM8y2MgOZWqgwDt110kUAc7qWQoN+ihyPvZrEkX2C+sU7VBd8IKrouHHEm/sQ= =fYD5 -----END PGP SIGNATURE----- --zHDeOHGDnzKksZSU-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 00:57:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6A627D2B; Mon, 5 Aug 2013 00:57:07 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3D38020B3; Mon, 5 Aug 2013 00:57:06 +0000 (UTC) Received: from glenbarber.us (c-71-224-221-174.hsd1.nj.comcast.net [71.224.221.174]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id B482080B2; Mon, 5 Aug 2013 00:57:05 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us B482080B2 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Sun, 4 Aug 2013 20:57:04 -0400 From: Glen Barber To: Steve Kargl Subject: Re: svn error during 'make buildkernel'? Message-ID: <20130805005704.GM2352@glenbarber.us> References: <20130803210348.GA715@troutmask.apl.washington.edu> <20130803210858.GJ78299@glenbarber.us> <20130803213023.GA812@troutmask.apl.washington.edu> <20130803214313.GL78299@glenbarber.us> <20130804232358.GA6068@troutmask.apl.washington.edu> <20130804232800.GJ2352@glenbarber.us> <20130805005028.GB6355@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Ll0BBk1HBk/f94B0" Content-Disposition: inline In-Reply-To: <20130805005028.GB6355@troutmask.apl.washington.edu> X-Operating-System: FreeBSD 10.0-CURRENT amd64 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: Mon, 05 Aug 2013 00:57:07 -0000 --Ll0BBk1HBk/f94B0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 04, 2013 at 05:50:28PM -0700, Steve Kargl wrote: > If you are disinclined to fix your commit, then consider this > an official request to back out revision 252505. >=20 You are the first and only one to complain after this change was in effect for 2 months. I am sorry that you do not keep your ports up to date. But this is -CURRENT, not -RELEASE. Change is expected, roads may be bumpy, etc. Glen --Ll0BBk1HBk/f94B0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBCAAGBQJR/vhgAAoJEFJPDDeguUajCIwH/RA6DzJELMxGQaom/V6aTGsc 9RM6L/Cm12BMAcpMji3Aiy+m8k7kRBi619/tTmrnItoXzoDw5I5Wd8S4xvaE7Bcf 8WWBGqyzJq38PsddYd8ehmU9/mx5BT/TxUicusWPsfrFzJReYt4ipYHIc9ujfpCR PFf8A0M8Xm7eeAnopFix6fJ27/AJ2u3c6c/BwmmPLTZpThMz6bxM0KwsHfbmusHK e+q4zctnlU4+/nCspwDBNuW8vbZNq6lGbBwfze2Wd8JZR8PDHrK0/N0tqjSUyo5M uHUh5ybwf0huRPMpWublu49j7Y/qfra7QFE28EUksLSi10JRRbZ9T7J01iSjDlc= =GI5Q -----END PGP SIGNATURE----- --Ll0BBk1HBk/f94B0-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 01:15:19 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9279EEFE; Mon, 5 Aug 2013 01:15:19 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6F4AE2118; Mon, 5 Aug 2013 01:15:19 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.6/8.14.6) with ESMTP id r751FJqL006577; Sun, 4 Aug 2013 18:15:19 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.6/8.14.6/Submit) id r751FIur006576; Sun, 4 Aug 2013 18:15:18 -0700 (PDT) (envelope-from sgk) Date: Sun, 4 Aug 2013 18:15:18 -0700 From: Steve Kargl To: Glen Barber Subject: Re: svn error during 'make buildkernel'? Message-ID: <20130805011518.GA6544@troutmask.apl.washington.edu> References: <20130803210348.GA715@troutmask.apl.washington.edu> <20130803210858.GJ78299@glenbarber.us> <20130803213023.GA812@troutmask.apl.washington.edu> <20130803214313.GL78299@glenbarber.us> <20130804232358.GA6068@troutmask.apl.washington.edu> <20130805004433.GA6355@troutmask.apl.washington.edu> <20130805005530.GL2352@glenbarber.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130805005530.GL2352@glenbarber.us> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, Peter Wemm 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, 05 Aug 2013 01:15:19 -0000 On Sun, Aug 04, 2013 at 08:55:30PM -0400, Glen Barber wrote: > On Sun, Aug 04, 2013 at 05:44:33PM -0700, Steve Kargl wrote: > > > If you want to upgrade, and use http/https access to repositories, > > > please check, that SERF option is enabled, as NEON support > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > I did not want to upgrade. It was suggested/forced on me > > by revisio 252505 of newvers.sh that looks for svnliteversion instead > > of the installed svnversion. 1.7.9 was working fine. > > > > You were not forced to do anything. > > If svn 1.7.9 works, great. Use it. > > The error generated is non-fatal, and once I receive response on > a proposed patch, will be suppressed if the svn version used to check > out the tree is not compatible with that used to check the version of > the tree with the kernel build. I don't care if it was nonfatal or not. An prominent ERROR message during 'make buldkernel' should set off an alarm in anyone's head. > > But seriously, this is -CURRENT. Things change. > Yeah, I've been running -current since it was called 386bsd+patchkit some 20 years ago. In the old days, committers cared about the quality of their commits. When informed of an issue, they looked into the problem instead of blaming the users. -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 01:16:28 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6764B77 for ; Mon, 5 Aug 2013 01:16:28 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DE85F2126 for ; Mon, 5 Aug 2013 01:16:27 +0000 (UTC) Received: from alph.d.allbsd.org (p2049-ipbf1102funabasi.chiba.ocn.ne.jp [122.26.101.49]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id r751G8L1026264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Aug 2013 10:16:18 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.5/8.14.5) with ESMTP id r751G8MC006062; Mon, 5 Aug 2013 10:16:08 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Mon, 05 Aug 2013 10:15:49 +0900 (JST) Message-Id: <20130805.101549.530648979044553714.hrs@allbsd.org> To: sfourman@gmail.com Subject: Re: Kernel Panic on FreeBSD 10.0-CURRENT #1 r253918 From: Hiroki Sato In-Reply-To: References: X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Mon_Aug__5_10_15_49_2013_686)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Mon, 05 Aug 2013 10:16:18 +0900 (JST) X-Spam-Status: No, score=-90.5 required=13.0 tests=CONTENT_TYPE_PRESENT, DIRECTOCNDYN,DYN_PBL,RCVD_IN_PBL,SPF_SOFTFAIL,USER_IN_WHITELIST, X_CHINESE_RELAY autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org 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, 05 Aug 2013 01:16:28 -0000 ----Security_Multipart(Mon_Aug__5_10_15_49_2013_686)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Sam Fourman Jr." wrote in : sf> could someone help me figure out why this machine kernel paniced? sf> I have a full crashdump file if needed, sf> this machine is configured as a Firewall and wifi hostap running pf in a sf> small office ... sf> #7 0xffffffff809937a8 in in6_tmpaddrtimer (arg=0xfffffe00170fc0b6) at sf> /usr/src/sys/netinet6/in6_ifattach.c:935 sf> #8 0xffffffff8085140a in softclock_call_cc (c=0xffffffff81325210, sf> cc=0xffffffff8131c700, direct=0) at /usr/src/sys/kern/kern_timeout.c:674 Can you try to update the kernel to r253950 or later? This is probably because one of my recent commits broke IPv6 temporary address timer on non-IPv6 interfaces. -- Hiroki ----Security_Multipart(Mon_Aug__5_10_15_49_2013_686)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEABECAAYFAlH+/MUACgkQTyzT2CeTzy2CsgCgrJzBpsXp4FxsMZyUbxpSxFdK jDUAoLqRixXIr5fm2RRp69hHr5qtmru/ =7kyn -----END PGP SIGNATURE----- ----Security_Multipart(Mon_Aug__5_10_15_49_2013_686)---- From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 01:18:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 520721C9; Mon, 5 Aug 2013 01:18:59 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2EA64213F; Mon, 5 Aug 2013 01:18:59 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.6/8.14.6) with ESMTP id r751IwGx006599; Sun, 4 Aug 2013 18:18:58 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.6/8.14.6/Submit) id r751IwCm006598; Sun, 4 Aug 2013 18:18:58 -0700 (PDT) (envelope-from sgk) Date: Sun, 4 Aug 2013 18:18:58 -0700 From: Steve Kargl To: Glen Barber Subject: Re: svn error during 'make buildkernel'? Message-ID: <20130805011858.GB6544@troutmask.apl.washington.edu> References: <20130803210348.GA715@troutmask.apl.washington.edu> <20130803210858.GJ78299@glenbarber.us> <20130803213023.GA812@troutmask.apl.washington.edu> <20130803214313.GL78299@glenbarber.us> <20130804232358.GA6068@troutmask.apl.washington.edu> <20130804232800.GJ2352@glenbarber.us> <20130805005028.GB6355@troutmask.apl.washington.edu> <20130805005704.GM2352@glenbarber.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130805005704.GM2352@glenbarber.us> 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: Mon, 05 Aug 2013 01:18:59 -0000 On Sun, Aug 04, 2013 at 08:57:04PM -0400, Glen Barber wrote: > On Sun, Aug 04, 2013 at 05:50:28PM -0700, Steve Kargl wrote: > > If you are disinclined to fix your commit, then consider this > > an official request to back out revision 252505. > > > > You are the first and only one to complain after this change was in > effect for 2 months. Perhaps, I'm "the first and only one to complain" because others already recognize that you will turn a deaf ear to their complaints. -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 01:23:49 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 40876309; Mon, 5 Aug 2013 01:23:49 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 13B3A2156; Mon, 5 Aug 2013 01:23:48 +0000 (UTC) Received: from glenbarber.us (c-71-224-221-174.hsd1.nj.comcast.net [71.224.221.174]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 9D5FD83A3; Mon, 5 Aug 2013 01:23:47 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 9D5FD83A3 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Sun, 4 Aug 2013 21:23:45 -0400 From: Glen Barber To: Steve Kargl Subject: Re: svn error during 'make buildkernel'? Message-ID: <20130805012345.GB63528@glenbarber.us> References: <20130803210348.GA715@troutmask.apl.washington.edu> <20130803210858.GJ78299@glenbarber.us> <20130803213023.GA812@troutmask.apl.washington.edu> <20130803214313.GL78299@glenbarber.us> <20130804232358.GA6068@troutmask.apl.washington.edu> <20130804232800.GJ2352@glenbarber.us> <20130805005028.GB6355@troutmask.apl.washington.edu> <20130805005704.GM2352@glenbarber.us> <20130805011858.GB6544@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="98e8jtXdkpgskNou" Content-Disposition: inline In-Reply-To: <20130805011858.GB6544@troutmask.apl.washington.edu> X-Operating-System: FreeBSD 10.0-CURRENT amd64 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: Mon, 05 Aug 2013 01:23:49 -0000 --98e8jtXdkpgskNou Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 04, 2013 at 06:18:58PM -0700, Steve Kargl wrote: > > You are the first and only one to complain after this change was in > > effect for 2 months. >=20 > Perhaps, I'm "the first and only one to complain" because others already > recognize that you will turn a deaf ear to their complaints. I know you are not "new" here. So, I really do find it offensive that you would even consider sending an email with such an accusation. Glen --98e8jtXdkpgskNou Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBCAAGBQJR/v6hAAoJEFJPDDeguUajaH0H/RuQaHCeh8J7o3mMuw08TOiP PpkNJiClZP+WaDgQn5tV+GpjYugvfi1rS9gFsFO/rLUXRt1advq3QbhGPM+Ulvvf fhTXK/GJ30vkBKdPQrPM46iy6cAcvRYwrgzeUWQf4Def+abuX8VKbIW38z6zzXCU SQ/ENhefbd3hvW5RlQWGQVKPIBYCqRv/IALG8r0m4D8ytdayVR9+yX+sdOiwddA0 8PDjyBBzNFt72A/z337A4JvGNIveUysFEqZhjhHauJ8oqOE8kNhhkAurJuzfMUc1 XO0nQ4sJzSZ/dvjari2FNqBWX1YcFLIk+jaRJMsPELeWVFfbS9sAJezZw0mJ5E4= =m99N -----END PGP SIGNATURE----- --98e8jtXdkpgskNou-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 03:01:50 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CB2272F6; Mon, 5 Aug 2013 03:01:50 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) by mx1.freebsd.org (Postfix) with ESMTP id 5B22E2461; Mon, 5 Aug 2013 03:01:49 +0000 (UTC) X-AuditID: 12074423-b7f168e00000095a-a0-51ff159703e0 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id C6.85.02394.7951FF15; Sun, 4 Aug 2013 23:01:43 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id r7531gX0031002; Sun, 4 Aug 2013 23:01:42 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r7531dAF029672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 4 Aug 2013 23:01:40 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r7531cZ0016497; Sun, 4 Aug 2013 23:01:39 -0400 (EDT) Date: Sun, 4 Aug 2013 23:01:38 -0400 (EDT) From: Benjamin Kaduk To: Steve Kargl , Glen Barber Subject: Re: svn error during 'make buildkernel'? In-Reply-To: <20130805012345.GB63528@glenbarber.us> Message-ID: References: <20130803210348.GA715@troutmask.apl.washington.edu> <20130803210858.GJ78299@glenbarber.us> <20130803213023.GA812@troutmask.apl.washington.edu> <20130803214313.GL78299@glenbarber.us> <20130804232358.GA6068@troutmask.apl.washington.edu> <20130804232800.GJ2352@glenbarber.us> <20130805005028.GB6355@troutmask.apl.washington.edu> <20130805005704.GM2352@glenbarber.us> <20130805011858.GB6544@troutmask.apl.washington.edu> <20130805012345.GB63528@glenbarber.us> 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+NgFvrMIsWRmVeSWpSXmKPExsUixG6nojtd9H+gwZKTbBZz3nxgstjffIDN 4tbd58wOzB4zPs1n8ejdPY85gCmKyyYlNSezLLVI3y6BK6NrXjNLwWG2ir5tUxkbGDtYuxg5 OSQETCS+n7jADGGLSVy4t56ti5GLQ0hgH6PE23tt7BDOBkaJ/zfOQTkHmSRevznPBtIiJFAv 8e3CDTCbRUBLYuns2UwgNpuAisTMNxvB4iICURKT9z1lAbGZBeQl/l+5DFYjLGAo8aTlL1ic U8BYYs3qO4wgNq+Ao0Rj02dmiGVXmSU2LGoFKxIV0JFYvX8KC0SRoMTJmU+ghlpKnPtznW0C o+AsJKlZSFILGJlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Zrp5WaW6KWmlG5iBIeti/IOxj8H lQ4xCnAwKvHwKrD/DxRiTSwrrsw9xCjJwaQkylvJAhTiS8pPqcxILM6ILyrNSS0+xCjBwawk wsve/zdQiDclsbIqtSgfJiXNwaIkzvvs6dlAIYH0xJLU7NTUgtQimKwMB4eSBG+pCNBQwaLU 9NSKtMycEoQ0EwcnyHAeoOH+IDW8xQWJucWZ6RD5U4yKUuK8riAJAZBERmkeXC8srbxiFAd6 RZg3FaSKB5iS4LpfAQ1mAhps8hPk6uKSRISUVANjYW7wxezMv8rvDu26/TrFoE39+SyTy384 anfbX691Lb45Na2QYVJL9DXLnOZfl+4stV26oCr+6q44brZj8hGW22UFphZenCK3epXAxTsh 74X/TzPZ6vA6cLKXsIZx7L5GrgT3G+fUFi+30xKfzdYmw+mn/+Gze9Px/661r1Pfr5rDVJD4 dm+AEktxRqKhFnNRcSIAMhF1ZQYDAAA= 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, 05 Aug 2013 03:01:50 -0000 On Sun, 4 Aug 2013, Glen Barber wrote: > On Sun, Aug 04, 2013 at 06:18:58PM -0700, Steve Kargl wrote: >>> You are the first and only one to complain after this change was in >>> effect for 2 months. >> >> Perhaps, I'm "the first and only one to complain" because others already >> recognize that you will turn a deaf ear to their complaints. > > I know you are not "new" here. So, I really do find it offensive that > you would even consider sending an email with such an accusation. I am saddened by the tone of discourse in this thread, since I know all parties to be quite intelligent, and have every reason to believe they are acting in good faith. It sounds like Glen is in fact working on the issue, and Steve should ignore the (now known to be) spurious error message and go on with his work. -Ben From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 04:48:28 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 75D8C346; Mon, 5 Aug 2013 04:48:28 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3A7CA27C0; Mon, 5 Aug 2013 04:48:28 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.6/8.14.6) with ESMTP id r754mRul007265; Sun, 4 Aug 2013 21:48:27 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.6/8.14.6/Submit) id r754mR0t007264; Sun, 4 Aug 2013 21:48:27 -0700 (PDT) (envelope-from sgk) Date: Sun, 4 Aug 2013 21:48:27 -0700 From: Steve Kargl To: Glen Barber Subject: Re: svn error during 'make buildkernel'? Message-ID: <20130805044827.GA7214@troutmask.apl.washington.edu> References: <20130803210348.GA715@troutmask.apl.washington.edu> <20130803210858.GJ78299@glenbarber.us> <20130803213023.GA812@troutmask.apl.washington.edu> <20130803214313.GL78299@glenbarber.us> <20130804232358.GA6068@troutmask.apl.washington.edu> <20130804232800.GJ2352@glenbarber.us> <20130805005028.GB6355@troutmask.apl.washington.edu> <20130805005704.GM2352@glenbarber.us> <20130805011858.GB6544@troutmask.apl.washington.edu> <20130805012345.GB63528@glenbarber.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130805012345.GB63528@glenbarber.us> 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: Mon, 05 Aug 2013 04:48:28 -0000 On Sun, Aug 04, 2013 at 09:23:45PM -0400, Glen Barber wrote: > On Sun, Aug 04, 2013 at 06:18:58PM -0700, Steve Kargl wrote: > > > You are the first and only one to complain after this change was in > > > effect for 2 months. > > > > Perhaps, I'm "the first and only one to complain" because others already > > recognize that you will turn a deaf ear to their complaints. > > I know you are not "new" here. So, I really do find it offensive that > you would even consider sending an email with such an accusation. > Sorry, but I've become frustrated with your own glib responses. Don't worry. This is my final response in this thread. I'll refrain from replying to any other email or commit message from you. -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 06:43:50 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AC2134D0 for ; Mon, 5 Aug 2013 06:43:50 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 783C22B7E for ; Mon, 5 Aug 2013 06:43:50 +0000 (UTC) Received: by mail-ob0-f181.google.com with SMTP id dn14so4781527obc.40 for ; Sun, 04 Aug 2013 23:43:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=4NQfNr+PgK0r6k1uWsu4aPE8+oYuwjgey0TJdUdNgRM=; b=flfzNgLJAUKyf4DCWUj6tKCOchncxjA0tu0H3iPevMvF3L8qYEytRkV4zBWUcTWpqw +IwJcrnFBw4BkxlrKQjqBZpogEbwjJtgGs0i/c03BSOt/3q6aYoCE6ipEG+O3pPUzwVJ 3/iiFVDJKyZMvTUV59nwvQ4gKUTr/B96x+vYEJv2MEgn7gKtn4McvG4ayvN+pEF1K3dM L1JNmTD5PAUh79AN3DaCV6XgyMWDlBJ37KPNJA6b9dWa8I0/yugrELIhOh7Hzsk5Lw4S FjuxRgFV//w+Cf02Dg5QfMH2bAZ+yhQ7Nj4NPnu0tIP2rma06etxTC4lloEkYSMlRS/D FO+A== X-Received: by 10.42.25.12 with SMTP id y12mr1512015icb.64.1375685029092; Sun, 04 Aug 2013 23:43:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.158.74 with HTTP; Sun, 4 Aug 2013 23:43:34 -0700 (PDT) From: "Lundberg, Johannes" Date: Mon, 5 Aug 2013 15:43:34 +0900 Message-ID: Subject: FreeBSD on MacBook Air 2013 To: FreeBSD Current X-Gm-Message-State: ALoCoQmvRAqni4oIWlpHmR4LIq6ccaQMMGaAsbVfVPJDxF7s7BueoNvukEBbk59oYrHYpLdXf5X/ Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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, 05 Aug 2013 06:43:50 -0000 Hi Has anyone managed to install FreeBSD on the latest MacBook Air? Be happy to hear any tips or pointers... Johannes Lundberg BRILLIANTSERVICE CO., LTD. From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 08:24:38 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 02D0543F; Mon, 5 Aug 2013 08:24:38 +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 BBD2A2E8B; Mon, 5 Aug 2013 08:24:37 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id CF5727300A; Mon, 5 Aug 2013 10:23:07 +0200 (CEST) Date: Mon, 5 Aug 2013 10:23:07 +0200 From: Luigi Rizzo To: net@freebsd.org Subject: [net] protecting interfaces from races between control and data ? Message-ID: <20130805082307.GA35162@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: 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, 05 Aug 2013 08:24:38 -0000 i am slightly unclear of what mechanisms we use to prevent races between interface being reconfigured (up/down/multicast setting, etc, all causing reinitialization of the rx and tx rings) and i) packets from the host stack being sent out; ii) interrupts from the network card being processed. I think in the old times IFF_DRV_RUNNING was used for this purpose, but now it is not enough. Acquiring the "core lock" in the NIC does not seem enough, either, because newer drivers, especially multiqueue ones, have per-queue rx and tx locks. Does anyone know if there is a generic mechanism, or each driver reimplements its own way ? thanks luigi From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 09:05:05 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 605CD2C3; Mon, 5 Aug 2013 09:05:05 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-ee0-x236.google.com (mail-ee0-x236.google.com [IPv6:2a00:1450:4013:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BE432207C; Mon, 5 Aug 2013 09:05:04 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id e53so1483511eek.27 for ; Mon, 05 Aug 2013 02:05:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=buspEsQWGFSX5bIUE2wZcgddm8oPvaIk/LhEadbcHT0=; b=K5WUTlSn85O06OqB1jnoMp+m74YvHwnToJrv5LcfpOI1KRHiZya5rFrDKKJZ1OAHt+ p506F/5+bViXsWWnCPFBhoKPNY8I8YX1f8XNQAaKw0r0U9R7hAlBX7CWHjb/O+39Y5bo Q4hxty7D6tGH8Rn9rx6GrKpl0EouC0pvl1ZbI87ZibX4A1VSHl69vtJ0Yu2z8Qt3FGIp LW5iJahwMCVZx+ncfm9PqVOXfIhVdMTsdge8ZxULg7enffF4R5QIywmG0dogyz1PQ9rC h303oGql+4+SPZmZs0yxDa+57XMGYyVf0Ns2Lxf3GRZB2g37H6NJ78UC9oHil85PezUz K2VQ== X-Received: by 10.14.111.198 with SMTP id w46mr4823291eeg.66.1375693503148; Mon, 05 Aug 2013 02:05:03 -0700 (PDT) Received: from laptop.minsk.domain (m-s.agava.net. [195.222.84.203]) by mx.google.com with ESMTPSA id k3sm31750151een.16.2013.08.05.02.05.01 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Mon, 05 Aug 2013 02:05:02 -0700 (PDT) Date: Mon, 5 Aug 2013 12:04:59 +0300 From: "Sergey V. Dyatko" To: Glen Barber Subject: Re: svn error during 'make buildkernel'? Message-ID: <20130805120459.6a47fde8@laptop.minsk.domain> In-Reply-To: <20130804020456.GS78299@glenbarber.us> References: <20130803210348.GA715@troutmask.apl.washington.edu> <20130803210858.GJ78299@glenbarber.us> <20130803213023.GA812@troutmask.apl.washington.edu> <20130803214313.GL78299@glenbarber.us> <20130803221702.GA979@troutmask.apl.washington.edu> <20130804081009.257c5801@X220.ovitrap.com> <20130804020456.GS78299@glenbarber.us> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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: Mon, 05 Aug 2013 09:05:05 -0000 On Sat, 3 Aug 2013 22:04:56 -0400 Glen Barber wrote: > On Sun, Aug 04, 2013 at 08:10:09AM +0800, Erich Dollansky wrote: > > doesn't this show again that svn came a bit early? > > No, it shows that people do not keep their third-party software up to > date. > > Glen > what about devel/subversion17? ;-) Why I _must_ update my svn client to 1.8.x ? I can do svn checkout/update/etc with 1.7 installed, BUT I also want to see svn revision when I run uname -a. We are talking about that some time ago on efnet. newvers.sh should check exit code. [tiger@laptop]:~/vcs/sysadm%svnversion svn: E155036: The working copy at '/usr/home/tiger/vcs/sysadm' is too old (format 29) to work with client version '1.8.1 (r1503906)' (expects format 31). You need to upgrade the working copy first. [tiger@laptop]:~/vcs/sysadm%echo $? 1 [tiger@laptop]:~/vcs/sysadm%svn upgrade Upgraded '.' [tiger@laptop]:~/vcs/sysadm%svnversion 13 [tiger@laptop]:~/vcs/sysadm%echo $? 0 -- wbr, tiger From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 09:08:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DE73B4FB for ; Mon, 5 Aug 2013 09:08:36 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-ea0-x22a.google.com (mail-ea0-x22a.google.com [IPv6:2a00:1450:4013:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6FE0F20AF for ; Mon, 5 Aug 2013 09:08:36 +0000 (UTC) Received: by mail-ea0-f170.google.com with SMTP id h14so1470113eak.15 for ; Mon, 05 Aug 2013 02:08:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=AW2HLQW+xtUi0qaEAGWrFtVxW5XoCOwT6pqF6xNXib4=; b=kCnF96mHyZYrMerrUBhp7A0DZdwk7zVvSKj2613lnzg+f3RdVuJ18nGyh2jLZn1/en QtJ09GqCqcPJennuQpskBGV7znn8bIViz+gBXBMV48QfZ/k3DKU8tnJ9BY3oXFsJD1t6 82Te0L6y/91tQpwEQbF1dpWAX5HOkjQjIfDJvkugAZNSWtVRWnJGwtYkK3p4aG0PMCZX XUFJip+DjCVOfYii2GNiu7mVB3klTycknF/jsO9/9lB27Cl5Gt63y+NQXxvq5Ll0gSRa 2vAEzIGXUBBlZvlgJhWYCpA8r3glVqgxKzx88TqrYO90iE6PwH2Zckz7OZ0HymbAvJyM D/mQ== X-Received: by 10.15.98.3 with SMTP id bi3mr15750235eeb.124.1375693714733; Mon, 05 Aug 2013 02:08:34 -0700 (PDT) Received: from laptop.minsk.domain (m-s.agava.net. [195.222.84.203]) by mx.google.com with ESMTPSA id a4sm31818959eez.0.2013.08.05.02.08.33 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Mon, 05 Aug 2013 02:08:34 -0700 (PDT) Date: Mon, 5 Aug 2013 12:08:32 +0300 From: "Sergey V. Dyatko" To: freebsd-current@freebsd.org Subject: Re: svn error during 'make buildkernel'? Message-ID: <20130805120832.277c4761@laptop.minsk.domain> In-Reply-To: <20130805005704.GM2352@glenbarber.us> References: <20130803210348.GA715@troutmask.apl.washington.edu> <20130803210858.GJ78299@glenbarber.us> <20130803213023.GA812@troutmask.apl.washington.edu> <20130803214313.GL78299@glenbarber.us> <20130804232358.GA6068@troutmask.apl.washington.edu> <20130804232800.GJ2352@glenbarber.us> <20130805005028.GB6355@troutmask.apl.washington.edu> <20130805005704.GM2352@glenbarber.us> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 05 Aug 2013 09:08:36 -0000 On Sun, 4 Aug 2013 20:57:04 -0400 Glen Barber wrote: > On Sun, Aug 04, 2013 at 05:50:28PM -0700, Steve Kargl wrote: > > If you are disinclined to fix your commit, then consider this > > an official request to back out revision 252505. > > > > You are the first and only one to complain after this change was in > effect for 2 months. > that is not true. _same_ ML: Jul,14 'lost my r2xxxxx subversion id in uname & kern.version' > I am sorry that you do not keep your ports up to date. But this is > -CURRENT, not -RELEASE. Change is expected, roads may be bumpy, etc. > > Glen > -- wbr, tiger From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 09:17:16 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BC2116C1; Mon, 5 Aug 2013 09:17:16 +0000 (UTC) (envelope-from willy@Offermans.Rompen.nl) Received: from cpsmtpb-ews08.kpnxchange.com (cpsmtpb-ews08.kpnxchange.com [213.75.39.13]) by mx1.freebsd.org (Postfix) with ESMTP id 2C0392110; Mon, 5 Aug 2013 09:17:15 +0000 (UTC) Received: from cpsps-ews22.kpnxchange.com ([10.94.84.188]) by cpsmtpb-ews08.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Mon, 5 Aug 2013 11:16:05 +0200 Received: from CPSMTPM-CMT103.kpnxchange.com ([195.121.3.19]) by cpsps-ews22.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Mon, 5 Aug 2013 11:16:05 +0200 Received: from sun.offermans.rompen.nl ([77.170.60.162]) by CPSMTPM-CMT103.kpnxchange.com with Microsoft SMTPSVC(7.0.6002.18264); Mon, 5 Aug 2013 11:16:04 +0200 Received: from squid (squid.vpn.offrom.nl [10.168.0.72]) by sun.offermans.rompen.nl (8.14.5/8.14.4) with ESMTP id r759G4F9070525; Mon, 5 Aug 2013 11:16:04 +0200 (CEST) (envelope-from willy@vpn.offrom.nl) Received: from willy by squid with local (Exim 4.72) (envelope-from ) id 1V6GtX-0005zC-I3; Mon, 05 Aug 2013 11:16:03 +0200 Date: Mon, 5 Aug 2013 11:16:03 +0200 From: Willy Offermans To: Brooks Davis Subject: Re: control of order of inet devices Message-ID: <20130805091603.GB4557@vpn.offrom.nl> References: <20130416135621.GE3286@vpn.offrom.nl> <20130416154423.GD98205@lor.one-eyed-alien.net> <20130417091408.GG3480@vpn.offrom.nl> <516E6B10.2080000@gmail.com> <20130417200127.GB30583@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130417200127.GB30583@lor.one-eyed-alien.net> User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 05 Aug 2013 09:16:05.0116 (UTC) FILETIME=[698EABC0:01CE91BC] X-RcptDomain: freebsd.org Cc: Joshua Isom , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Willy@Offermans.Rompen.nl List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 09:17:16 -0000 Hello Brooks, On Wed, Apr 17, 2013 at 03:01:27PM -0500, Brooks Davis wrote: > On Wed, Apr 17, 2013 at 04:27:44AM -0500, Joshua Isom wrote: > > On 4/17/2013 4:14 AM, Willy Offermans wrote: > > > This is what I read in some of the articles or handbook as well. Can I > > > reorder this linked list? Can I control the order by creating the kernel > > > and reordering the inclusion of the device drivers? > > > > > > I am aware that the request sounds silly, but I have a third party program > > > which checks its licence against the first inet device. Since I have added > > > a new inet controller, the sequence has changed. Of course I ask for a new > > > licence, but they want to charge me for that and I do not see any reason > > > for that. > > > > Load old inet devices like normal, in loader.conf. Then load the new > > device driver before networking, after rc's started. If it'd because of > > probe order, then you might just have to control the probe order the > > hard way. If the program's calling ifconfig itself, you could write a > > wrapper to resort the output. And call a lawyer, getting a new ethernet > > card shouldn't void a license. > > It wouldn't be particularly hard to influence the sorting of the list if > you're willing to modify the if_attach_internal() function and always > insert devices with that name at the beginning. It just doesn't seem > very general purpose so I'd have a hard time considering including it. > > -- Brooks I see und subscribe to your point. However it is not clear to me how the order is established. Maybe if I know that, I can influence the order. Can you comment on that? Where can I find the code for the if_attach_internal() function? Digging into the code might also elucidate a lot of things, so I need to ask less :). Maybe I will change the code a bit to suite my wishes. If that is the case, I will inform the list and show the code. Maybe it is useful. -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Wiel ************************************* W.K. Offermans Home: +31 45 544 49 44 Mobile: +31 681 15 87 68 e-mail: Willy@Offermans.Rompen.nl From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 09:36:17 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DFEBCAFB; Mon, 5 Aug 2013 09:36:17 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id B2D4721E0; Mon, 5 Aug 2013 09:36:17 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id r759aHjC077642; Mon, 5 Aug 2013 02:36:17 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <51FF7211.6020909@rawbw.com> Date: Mon, 05 Aug 2013 02:36:17 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130628 Thunderbird/17.0.7 MIME-Version: 1.0 To: current@freebsd.org Subject: Linux epoll(7) patch Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Roman Divacky 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, 05 Aug 2013 09:36:17 -0000 There is the patch, suggested by Roman Divacky, implementing Linux epoll(7) functionality: http://rys.vlakno.cz/~rdivacky/patches/linux_epoll.patch This patch was suggested 5 years ago and was discussed on emulation@: http://lists.freebsd.org/pipermail/freebsd-emulation/2008-March/004409.html http://lists.freebsd.org/pipermail/freebsd-emulation/2008-March/004428.html Discussion stalled back then, and epoll is still unimplemented. Anybody can identify any issues with this patch? Are there any alternatives? Yuri From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 10:36:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 56DDD5DE for ; Mon, 5 Aug 2013 10:36:32 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-qe0-x22a.google.com (mail-qe0-x22a.google.com [IPv6:2607:f8b0:400d:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A49372406 for ; Mon, 5 Aug 2013 10:36:30 +0000 (UTC) Received: by mail-qe0-f42.google.com with SMTP id s14so1624284qeb.15 for ; Mon, 05 Aug 2013 03:36:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6inDUNBMsQeaOkFmzBi5y9GmP6GswxAuLBu+N4Awb8w=; b=dm+qsguv+rkVyKFYljMkwNC88Kio4IeR4OQNEZeWu5LE1vDHaglE11yqntSgJKAzQw 1BmxOQ1dwzx8WuKK0Ysk01uGXmlw0h07MCyPH7KZN+a0XkLjty62m8lVM1hq3Apa7J8w v4rvw4NwWA4UxgASOYXLV/LtGIk0LhvBrRWzbfPda+TEln80PUYEFP6TChREUEv4sg4x N0QYFRXKX26Eocch6bNr6oe2w2jMBo7Ke25AY0eS9tMP8WzmBmRP46gy1YVEnaNhd978 uMiDef5yiTYOivKqGSxPDEGbMZg2CX3iSBJO1CoBvUsRQvswfxBDmIA1bSLqhP0Z2pxO 2ahQ== MIME-Version: 1.0 X-Received: by 10.49.2.195 with SMTP id 3mr25238147qew.15.1375698989846; Mon, 05 Aug 2013 03:36:29 -0700 (PDT) Received: by 10.224.78.194 with HTTP; Mon, 5 Aug 2013 03:36:29 -0700 (PDT) In-Reply-To: <20130805120832.277c4761@laptop.minsk.domain> References: <20130803210348.GA715@troutmask.apl.washington.edu> <20130803210858.GJ78299@glenbarber.us> <20130803213023.GA812@troutmask.apl.washington.edu> <20130803214313.GL78299@glenbarber.us> <20130804232358.GA6068@troutmask.apl.washington.edu> <20130804232800.GJ2352@glenbarber.us> <20130805005028.GB6355@troutmask.apl.washington.edu> <20130805005704.GM2352@glenbarber.us> <20130805120832.277c4761@laptop.minsk.domain> Date: Mon, 5 Aug 2013 13:36:29 +0300 Message-ID: Subject: Re: svn error during 'make buildkernel'? From: Kimmo Paasiala To: "Sergey V. Dyatko" Content-Type: text/plain; charset=UTF-8 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, 05 Aug 2013 10:36:32 -0000 On Mon, Aug 5, 2013 at 12:08 PM, Sergey V. Dyatko wrote: > On Sun, 4 Aug 2013 20:57:04 -0400 > Glen Barber wrote: > >> On Sun, Aug 04, 2013 at 05:50:28PM -0700, Steve Kargl wrote: >> > If you are disinclined to fix your commit, then consider this >> > an official request to back out revision 252505. >> > >> >> You are the first and only one to complain after this change was in >> effect for 2 months. >> > > that is not true. _same_ ML: > Jul,14 > 'lost my r2xxxxx subversion id in uname & > kern.version' > > Your problem is that don't really the UPDATING instructions. There are clear instructions on how you can stay with the 1.7 version of subversion. Nothing forces you to update to 1.8., that has been already established in this discussion. -Kimmo From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 11:02:43 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BEC84C61 for ; Mon, 5 Aug 2013 11:02:43 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-ee0-x22d.google.com (mail-ee0-x22d.google.com [IPv6:2a00:1450:4013:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4EE5F24F6 for ; Mon, 5 Aug 2013 11:02:43 +0000 (UTC) Received: by mail-ee0-f45.google.com with SMTP id c50so1543361eek.32 for ; Mon, 05 Aug 2013 04:02:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=DQjee1OYtbTGk5mnOq3ecgxpoDJfG0K2R8JKCnNNSJQ=; b=Yx8kMjfpJunIaEaPibZ/1YoOacdJLw0yVZ/i7nJhaNq9LQg+3Ira6xGdzHXRcZxO8z J94f9rqQRF9Alf1B8W9UuQ3a0pit8Ycp94lOXPp978wOn+Qi67DDzB3/n+6jNl83bxiq 2ukEt3cfzh/9JwTk5yEec+nc7je/xhwSlcWS/SasWLjjlPyafaOPXApNVI4RrtSHHgAg KvmvBTNeMekkHQOPla3Hq0PTE9mhQU+Yb2cl78D4tgFRbfaay6qZJ1akHcbypTSF52LG iMaFTKORw+itlsZbKF7cR1pQhg33OrMu+HgsCZLymM/UV5l0MuVTHHp7LDixj3df5177 x3KQ== X-Received: by 10.15.52.5 with SMTP id o5mr16680629eew.58.1375700561660; Mon, 05 Aug 2013 04:02:41 -0700 (PDT) Received: from laptop.minsk.domain (m-s.agava.net. [195.222.84.203]) by mx.google.com with ESMTPSA id bb14sm32460513eeb.17.2013.08.05.04.02.40 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Mon, 05 Aug 2013 04:02:41 -0700 (PDT) Date: Mon, 5 Aug 2013 14:02:39 +0300 From: "Sergey V. Dyatko" To: freebsd-current@freebsd.org Subject: Re: svn error during 'make buildkernel'? Message-ID: <20130805140239.78658eb8@laptop.minsk.domain> In-Reply-To: References: <20130803210348.GA715@troutmask.apl.washington.edu> <20130803210858.GJ78299@glenbarber.us> <20130803213023.GA812@troutmask.apl.washington.edu> <20130803214313.GL78299@glenbarber.us> <20130804232358.GA6068@troutmask.apl.washington.edu> <20130804232800.GJ2352@glenbarber.us> <20130805005028.GB6355@troutmask.apl.washington.edu> <20130805005704.GM2352@glenbarber.us> <20130805120832.277c4761@laptop.minsk.domain> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 05 Aug 2013 11:02:43 -0000 On Mon, 5 Aug 2013 13:36:29 +0300 Kimmo Paasiala wrote: > On Mon, Aug 5, 2013 at 12:08 PM, Sergey V. Dyatko > wrote: > > On Sun, 4 Aug 2013 20:57:04 -0400 > > Glen Barber wrote: > > > >> On Sun, Aug 04, 2013 at 05:50:28PM -0700, Steve Kargl wrote: > >> > If you are disinclined to fix your commit, then consider this > >> > an official request to back out revision 252505. > >> > > >> > >> You are the first and only one to complain after this change was in > >> effect for 2 months. > >> > > > > that is not true. _same_ ML: > > Jul,14 > > 'lost my r2xxxxx subversion id in uname & > > kern.version' > > > > > > Your problem is that don't really the UPDATING instructions. There are > clear instructions on how you can stay with the 1.7 version of I'm using fresh version of devel/subversion (1.8) and I forced to do svn upgrade for all my old checkouts. Now we are talking about another things > subversion. Nothing forces you to update to 1.8., that has been > already established in this discussion. > wrong. newvers.sh use 1.8.x client from base. Yes, that is NOT fatal error, sure. Revision will not be listed in the `uname -a` output, that is not right! Steve have subversion 1.7 installed AND 1.7 checkout. `svnversion /usr/src/` output is correct for him, but NOT `svnliteversion /usr/src/` ;-) > -Kimmo -- wbr, tiger From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 11:27:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D6140EA1; Mon, 5 Aug 2013 11:27:03 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-vb0-x233.google.com (mail-vb0-x233.google.com [IPv6:2607:f8b0:400c:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8109F283C; Mon, 5 Aug 2013 11:27:03 +0000 (UTC) Received: by mail-vb0-f51.google.com with SMTP id x16so2667886vbf.10 for ; Mon, 05 Aug 2013 04:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vh/A6/BKBT0f5FHCFZMkxrNJv2HMeWwnNXmYyHjkkuM=; b=HRwaCDfU7GCJeTtt1zOeyn4vEJUMDnl3KZoLRqETepqvWoRojmZenHMYxbPDUjw4Bl MAIIg+uFOmlxdrc5lg0/n/SOccVmJEyU/RO0+0LjuQ3fzVXy0pIYhcwiKrRneUaCioh1 OAqD0t/Mn5qwxmjpsErM+O+vmVqpTBh+04pN/GXbOizVgyXVzTDQ2ulMkCvX97HSaWPF BUgJkCjl6bqtszhM74PoSt3tRP4oYPcstoTyfpL0YPG7+gcVqFZe21Bh53zXzp7HyGgY clY4qzKdWLAms0vFrGIsHaGtY6DDrWE5v7+JJ6M4hGPMt1dNuxRWuJJJcvRo4WOlX723 UHRw== MIME-Version: 1.0 X-Received: by 10.58.34.178 with SMTP id a18mr5550282vej.86.1375702022644; Mon, 05 Aug 2013 04:27:02 -0700 (PDT) Received: by 10.220.96.78 with HTTP; Mon, 5 Aug 2013 04:27:02 -0700 (PDT) In-Reply-To: <20130805.101549.530648979044553714.hrs@allbsd.org> References: <20130805.101549.530648979044553714.hrs@allbsd.org> Date: Mon, 5 Aug 2013 07:27:02 -0400 Message-ID: Subject: Re: Kernel Panic on FreeBSD 10.0-CURRENT #1 r253918 From: "Sam Fourman Jr." To: Hiroki Sato Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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, 05 Aug 2013 11:27:03 -0000 > Can you try to update the kernel to r253950 or later? This is > probably because one of my recent commits broke IPv6 temporary > address timer on non-IPv6 interfaces. > > -- Hiroki > I just built a kernel based on r253950, I will keep the list updated if the panic happens again -- Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 08:57:13 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A6E00CC5 for ; Mon, 5 Aug 2013 08:57:13 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm43-vm10.bullet.mail.bf1.yahoo.com (nm43-vm10.bullet.mail.bf1.yahoo.com [216.109.114.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 10F572FD1 for ; Mon, 5 Aug 2013 08:57:12 +0000 (UTC) Received: from [98.139.215.140] by nm43.bullet.mail.bf1.yahoo.com with NNFMP; 05 Aug 2013 08:57:06 -0000 Received: from [68.142.230.76] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 05 Aug 2013 08:57:06 -0000 Received: from [127.0.0.1] by smtp233.mail.bf1.yahoo.com with NNFMP; 05 Aug 2013 08:57:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1375693026; bh=g6MvKxMXufr38DVZ9QRpodvH8ZmW/f1OMpHnkowr2k4=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=gxNqdyBz7JXtFiVhtRTQtwlMJedchz/fzQ2nKd9QiylodjiJJYMW7NGGsOWcr9SwcXyrsB9DiQOytwrSWXWz0qaqqTI86tRLzvglbyOeylnS/AkrbZhMEbiiOLhqEWOwFBCR2YARG3LnpLNs119+VhpjTdxD5fGEFedvww+nOAo= X-Yahoo-Newman-Id: 186511.61154.bm@smtp233.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 2diJR4IVM1kXMFVXVWX7nonHpAFk90cHXkMTV.HVJZFXG1w llGVwNsKZkA_dNp9tT8IaIS4Rwgzk5TeqL.s6JXjitWlgoDlxhKHmuAD.6ng 5NzmGIuyP.atDetYsoBtg3tzW6H8xbYO2OQ8oafqcNI40hNuJ8FTj_QWF2J8 JAnZxH86Xg1sFVvl..Qr8ZrzUVjVtXYkC6TspXHtQJBS.PHoOe2p0F50oW7X _9eM8lnu5qexXTUjeHGReqSrkHy9Zkubjugbf.MJEg.wF7Ltg93Jk0EDQ8sE jbVu7P0MlNDBvCvk9rQ.HdSQc9LMFnRz7h6QeiYlNGEmlU7nSm9b4V0bFKyM JlOf.WeEE9S2bOWZ211_E6_K2z2tRMs7UKPtynZFeVtjkAAzK1cxXiA75Pe1 2gXdGUdrTJC52aJ3uzbYiUvlpieEFBZ8axKt.ABbjGKEawVd9Sv0bm9mP6_x J55hyCbfw_6mcYbqclk3YE2z5AWjh5dUqho3yZpXf8g8nRCLtT8XcJpAKXve gQhLOhlDq3IGkvf9BadwPLaWfOw6xDBO45ToDifPVoJVlyL33VEE_hRwHYg- - X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- X-Rocket-Received: from [192.168.254.206] (scott4long@168.103.85.57 with ) by smtp233.mail.bf1.yahoo.com with SMTP; 05 Aug 2013 08:57:06 +0000 UTC Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: [net] protecting interfaces from races between control and data ? From: Scott Long In-Reply-To: <20130805082307.GA35162@onelab2.iet.unipi.it> Date: Mon, 5 Aug 2013 02:57:04 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <179713DC-926B-4E8A-9BE4-EC4337B8736E@yahoo.com> References: <20130805082307.GA35162@onelab2.iet.unipi.it> To: Luigi Rizzo X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Mon, 05 Aug 2013 12:01:24 +0000 Cc: current@freebsd.org, net@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, 05 Aug 2013 08:57:13 -0000 On Aug 5, 2013, at 2:23 AM, Luigi Rizzo wrote: > i am slightly unclear of what mechanisms we use to prevent races > between interface being reconfigured (up/down/multicast setting, etc, > all causing reinitialization of the rx and tx rings) and >=20 > i) packets from the host stack being sent out; > ii) interrupts from the network card being processed. >=20 > I think in the old times IFF_DRV_RUNNING was used for this purpose, > but now it is not enough. > Acquiring the "core lock" in the NIC does not seem enough, either, > because newer drivers, especially multiqueue ones, have per-queue > rx and tx locks. >=20 > Does anyone know if there is a generic mechanism, or each driver > reimplements its own way ? >=20 I'll speak to the RX side of the question. Several years ago I modified = the if_em driver to use a fast interrupt handler that would signal actual = processing in a taskqueue thread. The result was a system with no more latency = than the classic ithread model, but with the ability to allow RX processing = to be halted, drained, and restarted via an explicit API. This in turn was = extended to cause the RX processing to be safely paused during the control events that you described above. The system worked well on many fronts, but unfortunately I was unable to actively maintain it, and it was slowly garbage collected over time. I = think that it could have been extended without much effort to cover = TX-complete processing. TX dispatch is a different matter, but I don't think that = it would be hard to have the if_transmit/if_start path respond to control = synchronization events. Scott From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 14:59:44 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2C02C6D9; Mon, 5 Aug 2013 14:59:44 +0000 (UTC) (envelope-from bryanv@daemoninthecloset.org) Received: from torment.daemoninthecloset.org (torment.daemoninthecloset.org [94.242.209.234]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E113E2175; Mon, 5 Aug 2013 14:59:43 +0000 (UTC) Received: from sage.daemoninthecloset.org (unknown [70.114.209.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sage.daemoninthecloset.org", Issuer "daemoninthecloset.org" (verified OK)) by torment.daemoninthecloset.org (Postfix) with ESMTPS id C5F5542C082F; Mon, 5 Aug 2013 17:03:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at daemoninthecloset.org X-Virus-Scanned: amavisd-new at daemoninthecloset.org Date: Mon, 5 Aug 2013 09:59:32 -0500 (CDT) From: Bryan Venteicher To: Luigi Rizzo Message-ID: <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> In-Reply-To: <20130805082307.GA35162@onelab2.iet.unipi.it> References: <20130805082307.GA35162@onelab2.iet.unipi.it> Subject: Re: [net] protecting interfaces from races between control and data ? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.51.1.6] X-Mailer: Zimbra 8.0.2_GA_5569 (ZimbraWebClient - GC28 (Mac)/8.0.2_GA_5569) Thread-Topic: protecting interfaces from races between control and data ? Thread-Index: XB5cQkjSbdk+U+3uKm786A9OXRt2+g== Cc: current@freebsd.org, net@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, 05 Aug 2013 14:59:44 -0000 ----- Original Message ----- > i am slightly unclear of what mechanisms we use to prevent races > between interface being reconfigured (up/down/multicast setting, etc, > all causing reinitialization of the rx and tx rings) and > > i) packets from the host stack being sent out; > ii) interrupts from the network card being processed. > > I think in the old times IFF_DRV_RUNNING was used for this purpose, > but now it is not enough. > Acquiring the "core lock" in the NIC does not seem enough, either, > because newer drivers, especially multiqueue ones, have per-queue > rx and tx locks. > What I've done in my drivers is: * Lock the core mutex * Clear IFF_DRV_RUNNING * Lock/unlock each queue's lock The various Rx/Tx queue functions check for IFF_DRV_RUNNING after (re)acquiring their queue lock. See at vtnet_stop_rendezvous() at [1] for an example. > Does anyone know if there is a generic mechanism, or each driver > reimplements its own way ? > We desperately need a saner ifnet/driver interface. I think andre@ had some previous work in this area (and additional plans as well?). IMO, there's a lot to like on what DragonflyBSD has done in this area. [1] - http://svnweb.freebsd.org/base/user/bryanv/vtnetmq/sys/dev/virtio/network/if_vtnet.c?revision=252451&view=markup > thanks > luigi > _______________________________________________ > 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 Aug 5 15:22:06 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 79B08E34; Mon, 5 Aug 2013 15:22:06 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 67D6B22B3; Mon, 5 Aug 2013 15:22:06 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 19AE81A3C39; Mon, 5 Aug 2013 08:22:06 -0700 (PDT) Message-ID: <51FFC31D.3080304@mu.org> Date: Mon, 05 Aug 2013 08:22:05 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yuri Subject: Re: Linux epoll(7) patch References: <51FF7211.6020909@rawbw.com> In-Reply-To: <51FF7211.6020909@rawbw.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Roman Divacky , 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, 05 Aug 2013 15:22:06 -0000 On 8/5/13 2:36 AM, Yuri wrote: > There is the patch, suggested by Roman Divacky, implementing Linux > epoll(7) functionality: > http://rys.vlakno.cz/~rdivacky/patches/linux_epoll.patch > > This patch was suggested 5 years ago and was discussed on emulation@: > http://lists.freebsd.org/pipermail/freebsd-emulation/2008-March/004409.html > > http://lists.freebsd.org/pipermail/freebsd-emulation/2008-March/004428.html > > > Discussion stalled back then, and epoll is still unimplemented. > > Anybody can identify any issues with this patch? > Are there any alternatives? > > Yuri The patch is small. I too am wondering why it's not committed, was there any push back? -- Alfred Perlstein From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 15:30:41 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 03035319 for ; Mon, 5 Aug 2013 15:30:41 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CCA48233F for ; Mon, 5 Aug 2013 15:30:40 +0000 (UTC) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id DBE43207C7 for ; Mon, 5 Aug 2013 11:30:38 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute3.internal (MEProxy); Mon, 05 Aug 2013 11:30:38 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=g/lnHRR7yTzsKDUPUVyn9egZdlw=; b=eMb ZAWBeUNqdkzZZRhWPHvipsQ4cXKGiqGNHjNaUsGhymBD/6+wlAkXH3TrRLSFJoJO PIJpXjj2ROEGBVp51TtbrsS7ZcAXDdH0WneYJF4c6Ha3wzwn+twcbq3vCvm+2GXw L1IFgxVTyVlym5nuknQ6lBQFfmcJfElRJBiMdWe0= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id C2416B02158; Mon, 5 Aug 2013 11:30:38 -0400 (EDT) Message-Id: <1375716638.21499.6061603.4C417842@webmail.messagingengine.com> X-Sasl-Enc: zQFpMIWUn7fNDSFomT4NMxYtr8APpswTWJRGRQ3WOzyM 1375716638 From: Mark Felder To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-2d520484 In-Reply-To: <51FFC31D.3080304@mu.org> References: <51FF7211.6020909@rawbw.com> <51FFC31D.3080304@mu.org> Subject: Re: Linux epoll(7) patch Date: Mon, 05 Aug 2013 10:30:38 -0500 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, 05 Aug 2013 15:30:41 -0000 On Mon, Aug 5, 2013, at 10:22, Alfred Perlstein wrote: > The patch is small. I too am wondering why it's not committed, was > there any push back? > The glory days of the Linuxulator were around FreeBSD 6 when basically everything ran and often it ran much faster. We could really use a revival of this with the FreeBSD 10 release... From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 15:33:56 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4BA73484 for ; Mon, 5 Aug 2013 15:33:56 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) by mx1.freebsd.org (Postfix) with ESMTP id BE7AB2372 for ; Mon, 5 Aug 2013 15:33:55 +0000 (UTC) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.1 cv=ANp1G3FL c=1 sm=0 tr=0 a=nVny9ETX7T5uMhI2oTVyRA==:117 a=AaUjGI9IrlcA:10 a=kj9zAlcOel0A:10 a=OA2lqS22AAAA:8 a=sIt-5M63AAAA:8 a=S2kPtTsVP8EA:10 a=6I5d2MoRAAAA:8 a=Ugakn1e14OIgSr2CHUEA:9 a=CjuIK1q_8ugA:10 a=ZZAfTtC2Ym4A:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp02.rcn.cmh.synacor.com header.from=roberthuff@rcn.com; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.mail=roberthuff@rcn.com; spf=neutral; sender-id=neutral Received-SPF: neutral (smtp02.rcn.cmh.synacor.com: 209.6.193.164 is neither permitted nor denied by domain of rcn.com) Received: from [209.6.193.164] ([209.6.193.164:22695] helo=jerusalem.litteratus.org.litteratus.org) by smtp.rcn.com (envelope-from ) (ecelerity 2.2.3.49 r(42060/42061)) with ESMTP id 25/56-14489-0E5CFF15; Mon, 05 Aug 2013 11:33:54 -0400 From: Robert Huff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: base64 Message-ID: <20991.50656.38794.827648@jerusalem.litteratus.org> Date: Mon, 5 Aug 2013 11:33:52 -0400 To: Craig Rodrigues Subject: Re: "make buildworld" fails In-Reply-To: References: X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid Cc: Robert Huff , 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, 05 Aug 2013 15:33:56 -0000 DQoNCkNyYWlnIFJvZHJpZ3VlcyB3cml0ZXM6DQoNCj4gIE9uIFNhdCwgSnVuIDEsIDIwMTMg YXQgMTA6NDcgQU0sIFJvYmVydCBIdWZmIDxyb2JlcnRodWZmQHJjbi5jb20+IHdyb3RlOg0K DQo+PiAgY2MgLU8gLXBpcGUgLWcgLUROT19QV0RfT1ZFUlJJREUgLUkvdXNyL3NyYy91c3Iu YmluL2JtYWtlDQo+PiAgLURVU0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdf SCAtREhBVkVfQ09ORklHX0gNCj4+ICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZF X0NPTkZJR19IDQo+PiAgLURfUEFUSF9ERUZTWVNQQVRIPVwiLi4uL3NoYXJlL21rOi91c3Iv c2hhcmUvbWtcIg0KPj4gIC1JLiAtSS91c3Ivc3JjL2NvbnRyaWIvYm1ha2UgLURNQUtFX05B VElWRSAtc3RkPWdudTk5DQo+PiAgLVF1bnVzZWQtYXJndW1lbnRzIC1mc3RhY2stcHJvdGVj dG9yIC1Xc3lzdGVtLWhlYWRlcnMgLVdhbGwNCj4+ICAtV25vLWZvcm1hdC15MmsgLVcgLVdu by11bnVzZWQtcGFyYW1ldGVyIC1Xc3RyaWN0LXByb3RvdHlwZXMNCj4+ICAtV21pc3Npbmct cHJvdG90eXBlcyAtV3BvaW50ZXItYXJpdGggLVduby11bmluaXRpYWxpemVkDQo+PiAgLVdu by1wb2ludGVyLXNpZ24gLVduby1lbXB0eS1ib2R5IC1Xbm8tc3RyaW5nLXBsdXMtaW50DQo+ PiAgLVduby10YXV0b2xvZ2ljYWwtY29tcGFyZSAtV25vLXVudXNlZC12YWx1ZQ0KPj4gIC1X bm8tcGFyZW50aGVzZXMtZXF1YWxpdHkgLVduby11bnVzZWQtZnVuY3Rpb24gLVduby1jb252 ZXJzaW9uDQo+PiAgLXN0YXRpYyAtbyBtYWtlIGFyY2gubyBidWYubyBjb21wYXQubyBjb25k Lm8gZGlyLm8gZm9yLm8gaGFzaC5vDQo+PiAgam9iLm8gbWFpbi5vIG1ha2UubyBtYWtlX21h bGxvYy5vIG1ldGEubyBwYXJzZS5vIHN0ci5vIHN0cmxpc3Qubw0KPj4gIHN1ZmYubyB0YXJn Lm8gdHJhY2UubyB1dGlsLm8gdmFyLm8gbHN0QXBwZW5kLm8gbHN0QXRFbmQubw0KPj4gIGxz dEF0RnJvbnQubyBsc3RDbG9zZS5vIGxzdENvbmNhdC5vIGxzdERhdHVtLm8gbHN0RGVRdWV1 ZS5vDQo+PiAgbHN0RGVzdHJveS5vIGxzdER1cGwubyBsc3RFblF1ZXVlLm8gbHN0RmluZC5v IGxzdEZpbmRGcm9tLm8NCj4+ICBsc3RGaXJzdC5vIGxzdEZvckVhY2gubyBsc3RGb3JFYWNo RnJvbS5vIGxzdEluaXQubyBsc3RJbnNlcnQubw0KPj4gIGxzdElzQXRFbmQubyBsc3RJc0Vt cHR5Lm8gbHN0TGFzdC5vIGxzdE1lbWJlci5vIGxzdE5leHQubw0KPj4gIGxzdE9wZW4ubyBs c3RQcmV2Lm8gbHN0UmVtb3ZlLm8gbHN0UmVwbGFjZS5vIGxzdFN1Y2MubyBzdHJlc2VwLm8N Cj4+c2ggL3Vzci9zcmMvdG9vbHMvaW5zdGFsbC5zaCAtbyByb290IC1nIHdoZWVsIC1tIDU1 NSBtYWtlIFwNCj4+CS91c3Ivb2JqL3Vzci9zcmMvbWFrZS5hbWQ2NC9tYWtlDQo+PnVzYWdl OiBtYWtlIFstQmVpa05ucXJzdFdYXSANCj4+ICAgICAgICAgICAgWy1DIGRpcmVjdG9yeV0g Wy1EIHZhcmlhYmxlXSBbLWQgZmxhZ3NdIFstZiBtYWtlZmlsZV0NCj4+ICAgICAgICAgICAg Wy1JIGRpcmVjdG9yeV0gWy1KIHByaXZhdGVdIFstaiBtYXhfam9ic10gWy1tIGRpcmVjdG9y eV0gWy1UIGZpbGVdDQo+PiAgICAgICAgICAgIFstViB2YXJpYWJsZV0gW3ZhcmlhYmxlPXZh bHVlXSBbdGFyZ2V0IC4uLl0NCj4+KioqIFtidWlsZHdvcmxkXSBFcnJvciBjb2RlIDINCj4+ DQo+PlN0b3AgaW4gL3Vzci9zcmMuDQoNCj4gID4gPiAgV2l0aG91dCB0b3VjaGluZyBhbnl0 aGluZyBpbiB5b3VyIHRyZWUsIGNhbiB5b3UgcHJvdmlkZSBzb21lIG1vcmUNCj4gID4gPiAg aW5mb3JtYXRpb246DQo+ICA+ID4NCj4gID4gPiAgKDEpICBXaGF0IGlzIHRoZSBvdXRwdXQg b2YgL3Vzci9iaW4vbWFrZSAtViBNQUtFX1ZFUlNJT04NCj4gID4NCj4gID4gMTAyMDEyMDUz MDANCj4gID4NCj4gID4gPiAgKDIpICBXaGF0IGlzIHRoZSBvdXRwdXQgb2YgIC91c3Ivb2Jq L3Vzci9zcmMvbWFrZS5hbWQ2NC9tYWtlIC1WDQo+ICA+IE1BS0VfVkVSU0lPTg0KPiAgPg0K PiAgPiAyMDEzMDUyMA0KPiAgPg0KPiAgPiA+ICAoNCkgIFdoYXQgaXMgdGhlIEdSTiB2ZXJz aW9uIG9mIHlvdXIgdHJlZT8gIElmIHlvdSB1cGRhdGVkIHdpdGggc3ZuDQo+ICA+ID4gIGRp cmVjdGx5LA0KPiAgPiA+ICAgICAgICAgeW91IGNhbiBmaW5kIG91dCB3aXRoICJzdm4gaW5m byAvdXNyL3NyYyINCj4gID4NCj4gID4gV29ya2luZyBDb3B5IFJvb3QgUGF0aDogL3Vzci9z cmMNCj4gID4gVVJMOiBzdm46Ly9zdm4wLnVzLWVhc3QuZnJlZWJzZC5vcmcvYmFzZS9oZWFk DQo+ICA+IFJlcG9zaXRvcnkgUm9vdDogc3ZuOi8vc3ZuMC51cy1lYXN0LmZyZWVic2Qub3Jn L2Jhc2UNCj4gID4gUmVwb3NpdG9yeSBVVUlEOiBjY2Y5Zjg3Mi1hYTJlLWRkMTEtOWZjOC0w MDFjMjNkMGJjMWYNCj4gID4gUmV2aXNpb246IDI1MTIxMw0KPiAgPiBOb2RlIEtpbmQ6IGRp cmVjdG9yeQ0KPiAgPiBTY2hlZHVsZTogbm9ybWFsDQo+ICA+IExhc3QgQ2hhbmdlZCBBdXRo b3I6IG5wDQo+ICA+IExhc3QgQ2hhbmdlZCBSZXY6IDI1MTIxMw0KPiAgPiBMYXN0IENoYW5n ZWQgRGF0ZTogMjAxMy0wNS0zMSAyMjowNzozNyAtMDQwMCAoRnJpLCAzMSBNYXkgMjAxMykN Cj4gID4NCj4gIA0KPiAgDQo+ICBUaGFua3MgZm9yIHByb3ZpZGluZyB0aGUgaW5mb3JtYXRp b24uDQo+ICBUaGlzIGxvb2tzIHJlbGF0ZWQgdG8gdGhlIGxhdGVzdCBjaGFuZ2UgdG8gc3dp dGNoIHRvIGJtYWtlLg0KPiAgSSBkb24ndCB1bmRlcnN0YW5kIGhvdyBhbGwgdGhlIHBpZWNl cyBvZiB0aGUgcHV6emxlIGZpdCB0b2dldGhlciB0bw0KPiAgMTAwJSBkaWFnbm9zZSB0aGUg cHJvYmxlbSwgYnV0IGFuIHlvdSB0cnkgdGhlIGZvbGxvd2luZzoNCj4gIA0KPiAgKDEpICBD b21wbGV0ZWx5IGJsb3cgYXdheSB0aGUgb2JqIHRyZWUgd2l0aDoNCj4gIA0KPiAgcm0gLWZy IC91c3Ivb2JqDQo+ICANCj4gICgyKSAgVXBkYXRlIHRoZSBzb3VyY2UgdHJlZSB1bmRlciAv dXNyL3NyYyB0byB0aGUgbGF0ZXN0IHJldmlzaW9uIHdpdGggInN2bg0KPiAgdXBkYXRlIg0K PiAgDQo+ICAoMykgIFRyeSBhZ2FpbjoNCj4gICAgICAgICAgbWFrZSAtZCBsIGJ1aWxkd29y bGQNCg0KCURvbmU7IHRoZSByZXN1bHRzIGFyZSBhcHBlbmRlZC4NCglTVk4gaW5mbzoNCg0K V29ya2luZyBDb3B5IFJvb3QgUGF0aDogL3Vzci9zcmMNClVSTDogc3ZuOi8vc3ZuMC51cy1l YXN0LmZyZWVic2Qub3JnL2Jhc2UvaGVhZA0KUmVsYXRpdmUgVVJMOiBeL2hlYWQNClJlcG9z aXRvcnkgUm9vdDogc3ZuOi8vc3ZuMC51cy1lYXN0LmZyZWVic2Qub3JnL2Jhc2UNClJlcG9z aXRvcnkgVVVJRDogY2NmOWY4NzItYWEyZS1kZDExLTlmYzgtMDAxYzIzZDBiYzFmDQpSZXZp c2lvbjogMjUzOTY0DQpOb2RlIEtpbmQ6IGRpcmVjdG9yeQ0KU2NoZWR1bGU6IG5vcm1hbA0K TGFzdCBDaGFuZ2VkIEF1dGhvcjogbWF2DQpMYXN0IENoYW5nZWQgUmV2OiAyNTM5NjANCkxh c3QgQ2hhbmdlZCBEYXRlOiAyMDEzLTA4LTA1IDA4OjE1OjUzIC0wNDAwIChNb24sIDA1IEF1 ZyAyMDEzKQ0KDQoJU29ycnkgZm9yIHRoZSBkZWxheS4NCg0KDQoJCQkJCVJvYmVydCBIdWZm DQoNCgwNCihjZCAvdXNyL3NyYyAmJiBtYWtlIGJtYWtlKQ0KZWNobw0KDQplY2hvICItLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSINCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQplY2hvICI+Pj4gQnVpbGRpbmcgYW4gdXAtdG8tZGF0ZSBtYWtl KDEpIg0KPj4+IEJ1aWxkaW5nIGFuIHVwLXRvLWRhdGUgbWFrZSgxKQ0KZWNobyAiLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0iDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KY2QgL3Vzci9zcmMvdXNyLmJpbi9ibWFrZTsgIE1BS0VPQkpESVJQ UkVGSVg9L3Vzci9vYmovdXNyL3NyYy9tYWtlLmFtZDY0ICBERVNURElSPSAgSU5TVEFMTD0i c2ggL3Vzci9zcmMvdG9vbHMvaW5zdGFsbC5zaCIgbWFrZSAgLURfVVBHUkFESU5HICAtRE5P TUFOIC1ETk9fTUFOIC1ETk9TSEFSRUQgLUROT19TSEFSRUQgIC1ETk9fQ1BVX0NGTEFHUyAt RE5PX1dFUlJPUiBvYmogJiYgIE1BS0VPQkpESVJQUkVGSVg9L3Vzci9vYmovdXNyL3NyYy9t YWtlLmFtZDY0ICBERVNURElSPSAgSU5TVEFMTD0ic2ggL3Vzci9zcmMvdG9vbHMvaW5zdGFs bC5zaCIgbWFrZSAgLURfVVBHUkFESU5HICAtRE5PTUFOIC1ETk9fTUFOIC1ETk9TSEFSRUQg LUROT19TSEFSRUQgIC1ETk9fQ1BVX0NGTEFHUyAtRE5PX1dFUlJPUiBkZXBlbmQgJiYgIE1B S0VPQkpESVJQUkVGSVg9L3Vzci9vYmovdXNyL3NyYy9tYWtlLmFtZDY0ICBERVNURElSPSAg SU5TVEFMTD0ic2ggL3Vzci9zcmMvdG9vbHMvaW5zdGFsbC5zaCIgbWFrZSAgLURfVVBHUkFE SU5HICAtRE5PTUFOIC1ETk9fTUFOIC1ETk9TSEFSRUQgLUROT19TSEFSRUQgIC1ETk9fQ1BV X0NGTEFHUyAtRE5PX1dFUlJPUiBhbGwgJiYgIE1BS0VPQkpESVJQUkVGSVg9L3Vzci9vYmov dXNyL3NyYy9tYWtlLmFtZDY0ICBERVNURElSPSAgSU5TVEFMTD0ic2ggL3Vzci9zcmMvdG9v bHMvaW5zdGFsbC5zaCIgbWFrZSAgLURfVVBHUkFESU5HICAtRE5PTUFOIC1ETk9fTUFOIC1E Tk9TSEFSRUQgLUROT19TSEFSRUQgIC1ETk9fQ1BVX0NGTEFHUyAtRE5PX1dFUlJPUiBpbnN0 YWxsIERFU1RESVI9L3Vzci9vYmovdXNyL3NyYy9tYWtlLmFtZDY0IEJJTkRJUj0gUFJPR05B TUU9Ym1ha2UNCmlmICEgdGVzdCAtZCAvdXNyL29iai91c3Ivc3JjL21ha2UuYW1kNjQvdXNy L3NyYy91c3IuYmluL2JtYWtlLzsgdGhlbiAgbWtkaXIgLXAgL3Vzci9vYmovdXNyL3NyYy9t YWtlLmFtZDY0L3Vzci9zcmMvdXNyLmJpbi9ibWFrZTsgIGlmICEgdGVzdCAtZCAvdXNyL29i ai91c3Ivc3JjL21ha2UuYW1kNjQvdXNyL3NyYy91c3IuYmluL2JtYWtlLzsgdGhlbiAgZWNo byAiVW5hYmxlIHRvIGNyZWF0ZSAvdXNyL29iai91c3Ivc3JjL21ha2UuYW1kNjQvdXNyL3Ny Yy91c3IuYmluL2JtYWtlLiI7ICBleGl0IDE7ICBmaTsgIGVjaG8gIi91c3Ivb2JqL3Vzci9z cmMvbWFrZS5hbWQ2NC91c3Ivc3JjL3Vzci5iaW4vYm1ha2UgY3JlYXRlZCBmb3IgL3Vzci9z cmMvdXNyLmJpbi9ibWFrZSI7ICBmaQ0KL3Vzci9vYmovdXNyL3NyYy9tYWtlLmFtZDY0L3Vz ci9zcmMvdXNyLmJpbi9ibWFrZSBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL2JtYWtl DQpzZXQgLWU7IGZvciBlbnRyeSBpbiB1bml0LXRlc3RzOyBkbyAgaWYgdGVzdCAtZCAvdXNy L3NyYy91c3IuYmluL2JtYWtlLyR7ZW50cnl9LmFtZDY0OyB0aGVuICBlY2hvICI9PT0+ICR7 ZW50cnl9LmFtZDY0IChvYmopIjsgIGVkaXI9JHtlbnRyeX0uYW1kNjQ7ICBjZCAvdXNyL3Ny Yy91c3IuYmluL2JtYWtlLyR7ZWRpcn07ICBlbHNlICBlY2hvICI9PT0+ICRlbnRyeSAob2Jq KSI7ICBlZGlyPSR7ZW50cnl9OyAgY2QgL3Vzci9zcmMvdXNyLmJpbi9ibWFrZS8ke2VkaXJ9 OyAgZmk7ICBtYWtlIG9iaiAgRElSUFJGWD0kZWRpci87ICBkb25lDQo9PT0+IHVuaXQtdGVz dHMgKG9iaikNCmlmICEgdGVzdCAtZCAvdXNyL29iai91c3Ivc3JjL21ha2UuYW1kNjQvdXNy L3NyYy91c3IuYmluL2JtYWtlL3VuaXQtdGVzdHMvOyB0aGVuICBta2RpciAtcCAvdXNyL29i ai91c3Ivc3JjL21ha2UuYW1kNjQvdXNyL3NyYy91c3IuYmluL2JtYWtlL3VuaXQtdGVzdHM7 ICBpZiAhIHRlc3QgLWQgL3Vzci9vYmovdXNyL3NyYy9tYWtlLmFtZDY0L3Vzci9zcmMvdXNy LmJpbi9ibWFrZS91bml0LXRlc3RzLzsgdGhlbiAgZWNobyAiVW5hYmxlIHRvIGNyZWF0ZSAv dXNyL29iai91c3Ivc3JjL21ha2UuYW1kNjQvdXNyL3NyYy91c3IuYmluL2JtYWtlL3VuaXQt dGVzdHMuIjsgIGV4aXQgMTsgIGZpOyAgZWNobyAiL3Vzci9vYmovdXNyL3NyYy9tYWtlLmFt ZDY0L3Vzci9zcmMvdXNyLmJpbi9ibWFrZS91bml0LXRlc3RzIGNyZWF0ZWQgZm9yIC91c3Iv c3JjL3Vzci5iaW4vYm1ha2UvdW5pdC10ZXN0cyI7ICBmaQ0KL3Vzci9vYmovdXNyL3NyYy9t YWtlLmFtZDY0L3Vzci9zcmMvdXNyLmJpbi9ibWFrZS91bml0LXRlc3RzIGNyZWF0ZWQgZm9y IC91c3Ivc3JjL3Vzci5iaW4vYm1ha2UvdW5pdC10ZXN0cw0Kcm0gLWYgLmRlcGVuZA0KbWtk ZXAgLWYgLmRlcGVuZCAtYSAgICAtRE5PX1BXRF9PVkVSUklERSAtSS91c3Ivc3JjL3Vzci5i aW4vYm1ha2UgLURVU0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtREhB VkVfQ09ORklHX0ggLURVU0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAt RF9QQVRIX0RFRlNZU1BBVEg9XCIuLi4vc2hhcmUvbWs6L3Vzci9zaGFyZS9ta1wiIC1JLiAt SS91c3Ivc3JjL2NvbnRyaWIvYm1ha2UgLURNQUtFX05BVElWRSAtc3RkPWdudTk5ICAgL3Vz ci9zcmMvY29udHJpYi9ibWFrZS9hcmNoLmMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9idWYu YyAvdXNyL3NyYy9jb250cmliL2JtYWtlL2NvbXBhdC5jIC91c3Ivc3JjL2NvbnRyaWIvYm1h a2UvY29uZC5jIC91c3Ivc3JjL2NvbnRyaWIvYm1ha2UvZGlyLmMgL3Vzci9zcmMvY29udHJp Yi9ibWFrZS9mb3IuYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL2hhc2guYyAvdXNyL3NyYy9j b250cmliL2JtYWtlL2pvYi5jIC91c3Ivc3JjL2NvbnRyaWIvYm1ha2UvbWFpbi5jIC91c3Iv c3JjL2NvbnRyaWIvYm1ha2UvbWFrZS5jIC91c3Ivc3JjL2NvbnRyaWIvYm1ha2UvbWFrZV9t YWxsb2MuYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL21ldGEuYyAvdXNyL3NyYy9jb250cmli L2JtYWtlL3BhcnNlLmMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9zdHIuYyAvdXNyL3NyYy9j b250cmliL2JtYWtlL3N0cmxpc3QuYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL3N1ZmYuYyAv dXNyL3NyYy9jb250cmliL2JtYWtlL3RhcmcuYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL3Ry YWNlLmMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS91dGlsLmMgL3Vzci9zcmMvY29udHJpYi9i bWFrZS92YXIuYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL2xzdC5saWIvbHN0QXBwZW5kLmMg L3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdEF0RW5kLmMgL3Vzci9zcmMvY29u dHJpYi9ibWFrZS9sc3QubGliL2xzdEF0RnJvbnQuYyAvdXNyL3NyYy9jb250cmliL2JtYWtl L2xzdC5saWIvbHN0Q2xvc2UuYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL2xzdC5saWIvbHN0 Q29uY2F0LmMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdERhdHVtLmMgL3Vz ci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdERlUXVldWUuYyAvdXNyL3NyYy9jb250 cmliL2JtYWtlL2xzdC5saWIvbHN0RGVzdHJveS5jIC91c3Ivc3JjL2NvbnRyaWIvYm1ha2Uv bHN0LmxpYi9sc3REdXBsLmMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdEVu UXVldWUuYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL2xzdC5saWIvbHN0RmluZC5jIC91c3Iv c3JjL2NvbnRyaWIvYm1ha2UvbHN0LmxpYi9sc3RGaW5kRnJvbS5jIC91c3Ivc3JjL2NvbnRy aWIvYm1ha2UvbHN0LmxpYi9sc3RGaXJzdC5jIC91c3Ivc3JjL2NvbnRyaWIvYm1ha2UvbHN0 LmxpYi9sc3RGb3JFYWNoLmMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdEZv ckVhY2hGcm9tLmMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdEluaXQuYyAv dXNyL3NyYy9jb250cmliL2JtYWtlL2xzdC5saWIvbHN0SW5zZXJ0LmMgL3Vzci9zcmMvY29u dHJpYi9ibWFrZS9sc3QubGliL2xzdElzQXRFbmQuYyAvdXNyL3NyYy9jb250cmliL2JtYWtl L2xzdC5saWIvbHN0SXNFbXB0eS5jIC91c3Ivc3JjL2NvbnRyaWIvYm1ha2UvbHN0LmxpYi9s c3RMYXN0LmMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdE1lbWJlci5jIC91 c3Ivc3JjL2NvbnRyaWIvYm1ha2UvbHN0LmxpYi9sc3ROZXh0LmMgL3Vzci9zcmMvY29udHJp Yi9ibWFrZS9sc3QubGliL2xzdE9wZW4uYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL2xzdC5s aWIvbHN0UHJldi5jIC91c3Ivc3JjL2NvbnRyaWIvYm1ha2UvbHN0LmxpYi9sc3RSZW1vdmUu YyAvdXNyL3NyYy9jb250cmliL2JtYWtlL2xzdC5saWIvbHN0UmVwbGFjZS5jIC91c3Ivc3Jj L2NvbnRyaWIvYm1ha2UvbHN0LmxpYi9sc3RTdWNjLmMgL3Vzci9zcmMvY29udHJpYi9ibWFr ZS9zdHJlc2VwLmMNCmVjaG8gbWFrZTogL3Vzci9saWIvbGliYy5hICA+PiAuZGVwZW5kDQpj YyAtTyAtcGlwZSAtZyAtRE5PX1BXRF9PVkVSUklERSAtSS91c3Ivc3JjL3Vzci5iaW4vYm1h a2UgIC1EVVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURIQVZFX0NP TkZJR19IICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1EX1BB VEhfREVGU1lTUEFUSD1cIi4uLi9zaGFyZS9tazovdXNyL3NoYXJlL21rXCIgLUkuIC1JL3Vz ci9zcmMvY29udHJpYi9ibWFrZSAgLURNQUtFX05BVElWRSAgLXN0ZD1nbnU5OSAtUXVudXNl ZC1hcmd1bWVudHMgLWZzdGFjay1wcm90ZWN0b3IgLVdzeXN0ZW0taGVhZGVycyAtV2FsbCAt V25vLWZvcm1hdC15MmsgLVcgLVduby11bnVzZWQtcGFyYW1ldGVyIC1Xc3RyaWN0LXByb3Rv dHlwZXMgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdwb2ludGVyLWFyaXRoIC1Xbm8tdW5pbml0 aWFsaXplZCAtV25vLXBvaW50ZXItc2lnbiAtV25vLWVtcHR5LWJvZHkgLVduby1zdHJpbmct cGx1cy1pbnQgLVduby10YXV0b2xvZ2ljYWwtY29tcGFyZSAtV25vLXVudXNlZC12YWx1ZSAt V25vLXBhcmVudGhlc2VzLWVxdWFsaXR5IC1Xbm8tdW51c2VkLWZ1bmN0aW9uIC1Xbm8tY29u dmVyc2lvbiAgLWMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9hcmNoLmMNCmNjIC1PIC1waXBl IC1nIC1ETk9fUFdEX09WRVJSSURFIC1JL3Vzci9zcmMvdXNyLmJpbi9ibWFrZSAgLURVU0Vf TUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtREhBVkVfQ09ORklHX0ggIC1E VVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURfUEFUSF9ERUZTWVNQ QVRIPVwiLi4uL3NoYXJlL21rOi91c3Ivc2hhcmUvbWtcIiAtSS4gLUkvdXNyL3NyYy9jb250 cmliL2JtYWtlICAtRE1BS0VfTkFUSVZFICAtc3RkPWdudTk5IC1RdW51c2VkLWFyZ3VtZW50 cyAtZnN0YWNrLXByb3RlY3RvciAtV3N5c3RlbS1oZWFkZXJzIC1XYWxsIC1Xbm8tZm9ybWF0 LXkyayAtVyAtV25vLXVudXNlZC1wYXJhbWV0ZXIgLVdzdHJpY3QtcHJvdG90eXBlcyAtV21p c3NpbmctcHJvdG90eXBlcyAtV3BvaW50ZXItYXJpdGggLVduby11bmluaXRpYWxpemVkIC1X bm8tcG9pbnRlci1zaWduIC1Xbm8tZW1wdHktYm9keSAtV25vLXN0cmluZy1wbHVzLWludCAt V25vLXRhdXRvbG9naWNhbC1jb21wYXJlIC1Xbm8tdW51c2VkLXZhbHVlIC1Xbm8tcGFyZW50 aGVzZXMtZXF1YWxpdHkgLVduby11bnVzZWQtZnVuY3Rpb24gLVduby1jb252ZXJzaW9uICAt YyAvdXNyL3NyYy9jb250cmliL2JtYWtlL2J1Zi5jDQpjYyAtTyAtcGlwZSAtZyAtRE5PX1BX RF9PVkVSUklERSAtSS91c3Ivc3JjL3Vzci5iaW4vYm1ha2UgIC1EVVNFX01FVEEgLURNQUtF X05BVElWRSAtREhBVkVfQ09ORklHX0ggLURIQVZFX0NPTkZJR19IICAtRFVTRV9NRVRBIC1E TUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1EX1BBVEhfREVGU1lTUEFUSD1cIi4uLi9z aGFyZS9tazovdXNyL3NoYXJlL21rXCIgLUkuIC1JL3Vzci9zcmMvY29udHJpYi9ibWFrZSAg LURNQUtFX05BVElWRSAgLXN0ZD1nbnU5OSAtUXVudXNlZC1hcmd1bWVudHMgLWZzdGFjay1w cm90ZWN0b3IgLVdzeXN0ZW0taGVhZGVycyAtV2FsbCAtV25vLWZvcm1hdC15MmsgLVcgLVdu by11bnVzZWQtcGFyYW1ldGVyIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdtaXNzaW5nLXByb3Rv dHlwZXMgLVdwb2ludGVyLWFyaXRoIC1Xbm8tdW5pbml0aWFsaXplZCAtV25vLXBvaW50ZXIt c2lnbiAtV25vLWVtcHR5LWJvZHkgLVduby1zdHJpbmctcGx1cy1pbnQgLVduby10YXV0b2xv Z2ljYWwtY29tcGFyZSAtV25vLXVudXNlZC12YWx1ZSAtV25vLXBhcmVudGhlc2VzLWVxdWFs aXR5IC1Xbm8tdW51c2VkLWZ1bmN0aW9uIC1Xbm8tY29udmVyc2lvbiAgLWMgL3Vzci9zcmMv Y29udHJpYi9ibWFrZS9jb21wYXQuYw0KY2MgLU8gLXBpcGUgLWcgLUROT19QV0RfT1ZFUlJJ REUgLUkvdXNyL3NyYy91c3IuYmluL2JtYWtlICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUg LURIQVZFX0NPTkZJR19IIC1ESEFWRV9DT05GSUdfSCAgLURVU0VfTUVUQSAtRE1BS0VfTkFU SVZFIC1ESEFWRV9DT05GSUdfSCAtRF9QQVRIX0RFRlNZU1BBVEg9XCIuLi4vc2hhcmUvbWs6 L3Vzci9zaGFyZS9ta1wiIC1JLiAtSS91c3Ivc3JjL2NvbnRyaWIvYm1ha2UgIC1ETUFLRV9O QVRJVkUgIC1zdGQ9Z251OTkgLVF1bnVzZWQtYXJndW1lbnRzIC1mc3RhY2stcHJvdGVjdG9y IC1Xc3lzdGVtLWhlYWRlcnMgLVdhbGwgLVduby1mb3JtYXQteTJrIC1XIC1Xbm8tdW51c2Vk LXBhcmFtZXRlciAtV3N0cmljdC1wcm90b3R5cGVzIC1XbWlzc2luZy1wcm90b3R5cGVzIC1X cG9pbnRlci1hcml0aCAtV25vLXVuaW5pdGlhbGl6ZWQgLVduby1wb2ludGVyLXNpZ24gLVdu by1lbXB0eS1ib2R5IC1Xbm8tc3RyaW5nLXBsdXMtaW50IC1Xbm8tdGF1dG9sb2dpY2FsLWNv bXBhcmUgLVduby11bnVzZWQtdmFsdWUgLVduby1wYXJlbnRoZXNlcy1lcXVhbGl0eSAtV25v LXVudXNlZC1mdW5jdGlvbiAtV25vLWNvbnZlcnNpb24gIC1jIC91c3Ivc3JjL2NvbnRyaWIv Ym1ha2UvY29uZC5jDQpjYyAtTyAtcGlwZSAtZyAtRE5PX1BXRF9PVkVSUklERSAtSS91c3Iv c3JjL3Vzci5iaW4vYm1ha2UgIC1EVVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09O RklHX0ggLURIQVZFX0NPTkZJR19IICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZF X0NPTkZJR19IIC1EX1BBVEhfREVGU1lTUEFUSD1cIi4uLi9zaGFyZS9tazovdXNyL3NoYXJl L21rXCIgLUkuIC1JL3Vzci9zcmMvY29udHJpYi9ibWFrZSAgLURNQUtFX05BVElWRSAgLXN0 ZD1nbnU5OSAtUXVudXNlZC1hcmd1bWVudHMgLWZzdGFjay1wcm90ZWN0b3IgLVdzeXN0ZW0t aGVhZGVycyAtV2FsbCAtV25vLWZvcm1hdC15MmsgLVcgLVduby11bnVzZWQtcGFyYW1ldGVy IC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdwb2ludGVyLWFy aXRoIC1Xbm8tdW5pbml0aWFsaXplZCAtV25vLXBvaW50ZXItc2lnbiAtV25vLWVtcHR5LWJv ZHkgLVduby1zdHJpbmctcGx1cy1pbnQgLVduby10YXV0b2xvZ2ljYWwtY29tcGFyZSAtV25v LXVudXNlZC12YWx1ZSAtV25vLXBhcmVudGhlc2VzLWVxdWFsaXR5IC1Xbm8tdW51c2VkLWZ1 bmN0aW9uIC1Xbm8tY29udmVyc2lvbiAgLWMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9kaXIu Yw0KY2MgLU8gLXBpcGUgLWcgLUROT19QV0RfT1ZFUlJJREUgLUkvdXNyL3NyYy91c3IuYmlu L2JtYWtlICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1ESEFW RV9DT05GSUdfSCAgLURVU0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAt RF9QQVRIX0RFRlNZU1BBVEg9XCIuLi4vc2hhcmUvbWs6L3Vzci9zaGFyZS9ta1wiIC1JLiAt SS91c3Ivc3JjL2NvbnRyaWIvYm1ha2UgIC1ETUFLRV9OQVRJVkUgIC1zdGQ9Z251OTkgLVF1 bnVzZWQtYXJndW1lbnRzIC1mc3RhY2stcHJvdGVjdG9yIC1Xc3lzdGVtLWhlYWRlcnMgLVdh bGwgLVduby1mb3JtYXQteTJrIC1XIC1Xbm8tdW51c2VkLXBhcmFtZXRlciAtV3N0cmljdC1w cm90b3R5cGVzIC1XbWlzc2luZy1wcm90b3R5cGVzIC1XcG9pbnRlci1hcml0aCAtV25vLXVu aW5pdGlhbGl6ZWQgLVduby1wb2ludGVyLXNpZ24gLVduby1lbXB0eS1ib2R5IC1Xbm8tc3Ry aW5nLXBsdXMtaW50IC1Xbm8tdGF1dG9sb2dpY2FsLWNvbXBhcmUgLVduby11bnVzZWQtdmFs dWUgLVduby1wYXJlbnRoZXNlcy1lcXVhbGl0eSAtV25vLXVudXNlZC1mdW5jdGlvbiAtV25v LWNvbnZlcnNpb24gIC1jIC91c3Ivc3JjL2NvbnRyaWIvYm1ha2UvZm9yLmMNCmNjIC1PIC1w aXBlIC1nIC1ETk9fUFdEX09WRVJSSURFIC1JL3Vzci9zcmMvdXNyLmJpbi9ibWFrZSAgLURV U0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtREhBVkVfQ09ORklHX0gg IC1EVVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURfUEFUSF9ERUZT WVNQQVRIPVwiLi4uL3NoYXJlL21rOi91c3Ivc2hhcmUvbWtcIiAtSS4gLUkvdXNyL3NyYy9j b250cmliL2JtYWtlICAtRE1BS0VfTkFUSVZFICAtc3RkPWdudTk5IC1RdW51c2VkLWFyZ3Vt ZW50cyAtZnN0YWNrLXByb3RlY3RvciAtV3N5c3RlbS1oZWFkZXJzIC1XYWxsIC1Xbm8tZm9y bWF0LXkyayAtVyAtV25vLXVudXNlZC1wYXJhbWV0ZXIgLVdzdHJpY3QtcHJvdG90eXBlcyAt V21pc3NpbmctcHJvdG90eXBlcyAtV3BvaW50ZXItYXJpdGggLVduby11bmluaXRpYWxpemVk IC1Xbm8tcG9pbnRlci1zaWduIC1Xbm8tZW1wdHktYm9keSAtV25vLXN0cmluZy1wbHVzLWlu dCAtV25vLXRhdXRvbG9naWNhbC1jb21wYXJlIC1Xbm8tdW51c2VkLXZhbHVlIC1Xbm8tcGFy ZW50aGVzZXMtZXF1YWxpdHkgLVduby11bnVzZWQtZnVuY3Rpb24gLVduby1jb252ZXJzaW9u ICAtYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL2hhc2guYw0KY2MgLU8gLXBpcGUgLWcgLURO T19QV0RfT1ZFUlJJREUgLUkvdXNyL3NyYy91c3IuYmluL2JtYWtlICAtRFVTRV9NRVRBIC1E TUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1ESEFWRV9DT05GSUdfSCAgLURVU0VfTUVU QSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtRF9QQVRIX0RFRlNZU1BBVEg9XCIu Li4vc2hhcmUvbWs6L3Vzci9zaGFyZS9ta1wiIC1JLiAtSS91c3Ivc3JjL2NvbnRyaWIvYm1h a2UgIC1ETUFLRV9OQVRJVkUgLVduby1mb3JtYXQtbm9ubGl0ZXJhbCAtc3RkPWdudTk5IC1R dW51c2VkLWFyZ3VtZW50cyAtZnN0YWNrLXByb3RlY3RvciAtV3N5c3RlbS1oZWFkZXJzIC1X YWxsIC1Xbm8tZm9ybWF0LXkyayAtVyAtV25vLXVudXNlZC1wYXJhbWV0ZXIgLVdzdHJpY3Qt cHJvdG90eXBlcyAtV21pc3NpbmctcHJvdG90eXBlcyAtV3BvaW50ZXItYXJpdGggLVduby11 bmluaXRpYWxpemVkIC1Xbm8tcG9pbnRlci1zaWduIC1Xbm8tZW1wdHktYm9keSAtV25vLXN0 cmluZy1wbHVzLWludCAtV25vLXRhdXRvbG9naWNhbC1jb21wYXJlIC1Xbm8tdW51c2VkLXZh bHVlIC1Xbm8tcGFyZW50aGVzZXMtZXF1YWxpdHkgLVduby11bnVzZWQtZnVuY3Rpb24gLVdu by1jb252ZXJzaW9uIC1Xbm8tZm9ybWF0LW5vbmxpdGVyYWwgLWMgL3Vzci9zcmMvY29udHJp Yi9ibWFrZS9qb2IuYw0KY2MgLU8gLXBpcGUgLWcgLUROT19QV0RfT1ZFUlJJREUgLUkvdXNy L3NyYy91c3IuYmluL2JtYWtlICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NP TkZJR19IIC1ESEFWRV9DT05GSUdfSCAgLURVU0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFW RV9DT05GSUdfSCAtRF9QQVRIX0RFRlNZU1BBVEg9XCIuLi4vc2hhcmUvbWs6L3Vzci9zaGFy ZS9ta1wiIC1JLiAtSS91c3Ivc3JjL2NvbnRyaWIvYm1ha2UgIC1ETUFLRV9OQVRJVkUgIC1z dGQ9Z251OTkgLVF1bnVzZWQtYXJndW1lbnRzIC1mc3RhY2stcHJvdGVjdG9yIC1Xc3lzdGVt LWhlYWRlcnMgLVdhbGwgLVduby1mb3JtYXQteTJrIC1XIC1Xbm8tdW51c2VkLXBhcmFtZXRl ciAtV3N0cmljdC1wcm90b3R5cGVzIC1XbWlzc2luZy1wcm90b3R5cGVzIC1XcG9pbnRlci1h cml0aCAtV25vLXVuaW5pdGlhbGl6ZWQgLVduby1wb2ludGVyLXNpZ24gLVduby1lbXB0eS1i b2R5IC1Xbm8tc3RyaW5nLXBsdXMtaW50IC1Xbm8tdGF1dG9sb2dpY2FsLWNvbXBhcmUgLVdu by11bnVzZWQtdmFsdWUgLVduby1wYXJlbnRoZXNlcy1lcXVhbGl0eSAtV25vLXVudXNlZC1m dW5jdGlvbiAtV25vLWNvbnZlcnNpb24gIi1ETUFLRV9WRVJTSU9OPVwiMjAxMzA3MzBcIiIg LWMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9tYWluLmMNCmNjIC1PIC1waXBlIC1nIC1ETk9f UFdEX09WRVJSSURFIC1JL3Vzci9zcmMvdXNyLmJpbi9ibWFrZSAgLURVU0VfTUVUQSAtRE1B S0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtREhBVkVfQ09ORklHX0ggIC1EVVNFX01FVEEg LURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURfUEFUSF9ERUZTWVNQQVRIPVwiLi4u L3NoYXJlL21rOi91c3Ivc2hhcmUvbWtcIiAtSS4gLUkvdXNyL3NyYy9jb250cmliL2JtYWtl ICAtRE1BS0VfTkFUSVZFICAtc3RkPWdudTk5IC1RdW51c2VkLWFyZ3VtZW50cyAtZnN0YWNr LXByb3RlY3RvciAtV3N5c3RlbS1oZWFkZXJzIC1XYWxsIC1Xbm8tZm9ybWF0LXkyayAtVyAt V25vLXVudXNlZC1wYXJhbWV0ZXIgLVdzdHJpY3QtcHJvdG90eXBlcyAtV21pc3NpbmctcHJv dG90eXBlcyAtV3BvaW50ZXItYXJpdGggLVduby11bmluaXRpYWxpemVkIC1Xbm8tcG9pbnRl ci1zaWduIC1Xbm8tZW1wdHktYm9keSAtV25vLXN0cmluZy1wbHVzLWludCAtV25vLXRhdXRv bG9naWNhbC1jb21wYXJlIC1Xbm8tdW51c2VkLXZhbHVlIC1Xbm8tcGFyZW50aGVzZXMtZXF1 YWxpdHkgLVduby11bnVzZWQtZnVuY3Rpb24gLVduby1jb252ZXJzaW9uICAtYyAvdXNyL3Ny Yy9jb250cmliL2JtYWtlL21ha2UuYw0KY2MgLU8gLXBpcGUgLWcgLUROT19QV0RfT1ZFUlJJ REUgLUkvdXNyL3NyYy91c3IuYmluL2JtYWtlICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUg LURIQVZFX0NPTkZJR19IIC1ESEFWRV9DT05GSUdfSCAgLURVU0VfTUVUQSAtRE1BS0VfTkFU SVZFIC1ESEFWRV9DT05GSUdfSCAtRF9QQVRIX0RFRlNZU1BBVEg9XCIuLi4vc2hhcmUvbWs6 L3Vzci9zaGFyZS9ta1wiIC1JLiAtSS91c3Ivc3JjL2NvbnRyaWIvYm1ha2UgIC1ETUFLRV9O QVRJVkUgIC1zdGQ9Z251OTkgLVF1bnVzZWQtYXJndW1lbnRzIC1mc3RhY2stcHJvdGVjdG9y IC1Xc3lzdGVtLWhlYWRlcnMgLVdhbGwgLVduby1mb3JtYXQteTJrIC1XIC1Xbm8tdW51c2Vk LXBhcmFtZXRlciAtV3N0cmljdC1wcm90b3R5cGVzIC1XbWlzc2luZy1wcm90b3R5cGVzIC1X cG9pbnRlci1hcml0aCAtV25vLXVuaW5pdGlhbGl6ZWQgLVduby1wb2ludGVyLXNpZ24gLVdu by1lbXB0eS1ib2R5IC1Xbm8tc3RyaW5nLXBsdXMtaW50IC1Xbm8tdGF1dG9sb2dpY2FsLWNv bXBhcmUgLVduby11bnVzZWQtdmFsdWUgLVduby1wYXJlbnRoZXNlcy1lcXVhbGl0eSAtV25v LXVudXNlZC1mdW5jdGlvbiAtV25vLWNvbnZlcnNpb24gIC1jIC91c3Ivc3JjL2NvbnRyaWIv Ym1ha2UvbWFrZV9tYWxsb2MuYw0KY2MgLU8gLXBpcGUgLWcgLUROT19QV0RfT1ZFUlJJREUg LUkvdXNyL3NyYy91c3IuYmluL2JtYWtlICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURI QVZFX0NPTkZJR19IIC1ESEFWRV9DT05GSUdfSCAgLURVU0VfTUVUQSAtRE1BS0VfTkFUSVZF IC1ESEFWRV9DT05GSUdfSCAtRF9QQVRIX0RFRlNZU1BBVEg9XCIuLi4vc2hhcmUvbWs6L3Vz ci9zaGFyZS9ta1wiIC1JLiAtSS91c3Ivc3JjL2NvbnRyaWIvYm1ha2UgIC1ETUFLRV9OQVRJ VkUgLURIQVZFX0ZJTEVNT05fSCAtSS91c3IvaW5jbHVkZS9kZXYvZmlsZW1vbiAtc3RkPWdu dTk5IC1RdW51c2VkLWFyZ3VtZW50cyAtZnN0YWNrLXByb3RlY3RvciAtV3N5c3RlbS1oZWFk ZXJzIC1XYWxsIC1Xbm8tZm9ybWF0LXkyayAtVyAtV25vLXVudXNlZC1wYXJhbWV0ZXIgLVdz dHJpY3QtcHJvdG90eXBlcyAtV21pc3NpbmctcHJvdG90eXBlcyAtV3BvaW50ZXItYXJpdGgg LVduby11bmluaXRpYWxpemVkIC1Xbm8tcG9pbnRlci1zaWduIC1Xbm8tZW1wdHktYm9keSAt V25vLXN0cmluZy1wbHVzLWludCAtV25vLXRhdXRvbG9naWNhbC1jb21wYXJlIC1Xbm8tdW51 c2VkLXZhbHVlIC1Xbm8tcGFyZW50aGVzZXMtZXF1YWxpdHkgLVduby11bnVzZWQtZnVuY3Rp b24gLVduby1jb252ZXJzaW9uIC1ESEFWRV9GSUxFTU9OX0ggLUkvdXNyL2luY2x1ZGUvZGV2 L2ZpbGVtb24gLWMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9tZXRhLmMNCmNjIC1PIC1waXBl IC1nIC1ETk9fUFdEX09WRVJSSURFIC1JL3Vzci9zcmMvdXNyLmJpbi9ibWFrZSAgLURVU0Vf TUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtREhBVkVfQ09ORklHX0ggIC1E VVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURfUEFUSF9ERUZTWVNQ QVRIPVwiLi4uL3NoYXJlL21rOi91c3Ivc2hhcmUvbWtcIiAtSS4gLUkvdXNyL3NyYy9jb250 cmliL2JtYWtlICAtRE1BS0VfTkFUSVZFIC1Xbm8tZm9ybWF0LW5vbmxpdGVyYWwgLXN0ZD1n bnU5OSAtUXVudXNlZC1hcmd1bWVudHMgLWZzdGFjay1wcm90ZWN0b3IgLVdzeXN0ZW0taGVh ZGVycyAtV2FsbCAtV25vLWZvcm1hdC15MmsgLVcgLVduby11bnVzZWQtcGFyYW1ldGVyIC1X c3RyaWN0LXByb3RvdHlwZXMgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdwb2ludGVyLWFyaXRo IC1Xbm8tdW5pbml0aWFsaXplZCAtV25vLXBvaW50ZXItc2lnbiAtV25vLWVtcHR5LWJvZHkg LVduby1zdHJpbmctcGx1cy1pbnQgLVduby10YXV0b2xvZ2ljYWwtY29tcGFyZSAtV25vLXVu dXNlZC12YWx1ZSAtV25vLXBhcmVudGhlc2VzLWVxdWFsaXR5IC1Xbm8tdW51c2VkLWZ1bmN0 aW9uIC1Xbm8tY29udmVyc2lvbiAtV25vLWZvcm1hdC1ub25saXRlcmFsIC1jIC91c3Ivc3Jj L2NvbnRyaWIvYm1ha2UvcGFyc2UuYw0KY2MgLU8gLXBpcGUgLWcgLUROT19QV0RfT1ZFUlJJ REUgLUkvdXNyL3NyYy91c3IuYmluL2JtYWtlICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUg LURIQVZFX0NPTkZJR19IIC1ESEFWRV9DT05GSUdfSCAgLURVU0VfTUVUQSAtRE1BS0VfTkFU SVZFIC1ESEFWRV9DT05GSUdfSCAtRF9QQVRIX0RFRlNZU1BBVEg9XCIuLi4vc2hhcmUvbWs6 L3Vzci9zaGFyZS9ta1wiIC1JLiAtSS91c3Ivc3JjL2NvbnRyaWIvYm1ha2UgIC1ETUFLRV9O QVRJVkUgIC1zdGQ9Z251OTkgLVF1bnVzZWQtYXJndW1lbnRzIC1mc3RhY2stcHJvdGVjdG9y IC1Xc3lzdGVtLWhlYWRlcnMgLVdhbGwgLVduby1mb3JtYXQteTJrIC1XIC1Xbm8tdW51c2Vk LXBhcmFtZXRlciAtV3N0cmljdC1wcm90b3R5cGVzIC1XbWlzc2luZy1wcm90b3R5cGVzIC1X cG9pbnRlci1hcml0aCAtV25vLXVuaW5pdGlhbGl6ZWQgLVduby1wb2ludGVyLXNpZ24gLVdu by1lbXB0eS1ib2R5IC1Xbm8tc3RyaW5nLXBsdXMtaW50IC1Xbm8tdGF1dG9sb2dpY2FsLWNv bXBhcmUgLVduby11bnVzZWQtdmFsdWUgLVduby1wYXJlbnRoZXNlcy1lcXVhbGl0eSAtV25v LXVudXNlZC1mdW5jdGlvbiAtV25vLWNvbnZlcnNpb24gIC1jIC91c3Ivc3JjL2NvbnRyaWIv Ym1ha2Uvc3RyLmMNCmNjIC1PIC1waXBlIC1nIC1ETk9fUFdEX09WRVJSSURFIC1JL3Vzci9z cmMvdXNyLmJpbi9ibWFrZSAgLURVU0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05G SUdfSCAtREhBVkVfQ09ORklHX0ggIC1EVVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVf Q09ORklHX0ggLURfUEFUSF9ERUZTWVNQQVRIPVwiLi4uL3NoYXJlL21rOi91c3Ivc2hhcmUv bWtcIiAtSS4gLUkvdXNyL3NyYy9jb250cmliL2JtYWtlICAtRE1BS0VfTkFUSVZFICAtc3Rk PWdudTk5IC1RdW51c2VkLWFyZ3VtZW50cyAtZnN0YWNrLXByb3RlY3RvciAtV3N5c3RlbS1o ZWFkZXJzIC1XYWxsIC1Xbm8tZm9ybWF0LXkyayAtVyAtV25vLXVudXNlZC1wYXJhbWV0ZXIg LVdzdHJpY3QtcHJvdG90eXBlcyAtV21pc3NpbmctcHJvdG90eXBlcyAtV3BvaW50ZXItYXJp dGggLVduby11bmluaXRpYWxpemVkIC1Xbm8tcG9pbnRlci1zaWduIC1Xbm8tZW1wdHktYm9k eSAtV25vLXN0cmluZy1wbHVzLWludCAtV25vLXRhdXRvbG9naWNhbC1jb21wYXJlIC1Xbm8t dW51c2VkLXZhbHVlIC1Xbm8tcGFyZW50aGVzZXMtZXF1YWxpdHkgLVduby11bnVzZWQtZnVu Y3Rpb24gLVduby1jb252ZXJzaW9uICAtYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL3N0cmxp c3QuYw0KY2MgLU8gLXBpcGUgLWcgLUROT19QV0RfT1ZFUlJJREUgLUkvdXNyL3NyYy91c3Iu YmluL2JtYWtlICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1E SEFWRV9DT05GSUdfSCAgLURVU0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdf SCAtRF9QQVRIX0RFRlNZU1BBVEg9XCIuLi4vc2hhcmUvbWs6L3Vzci9zaGFyZS9ta1wiIC1J LiAtSS91c3Ivc3JjL2NvbnRyaWIvYm1ha2UgIC1ETUFLRV9OQVRJVkUgIC1zdGQ9Z251OTkg LVF1bnVzZWQtYXJndW1lbnRzIC1mc3RhY2stcHJvdGVjdG9yIC1Xc3lzdGVtLWhlYWRlcnMg LVdhbGwgLVduby1mb3JtYXQteTJrIC1XIC1Xbm8tdW51c2VkLXBhcmFtZXRlciAtV3N0cmlj dC1wcm90b3R5cGVzIC1XbWlzc2luZy1wcm90b3R5cGVzIC1XcG9pbnRlci1hcml0aCAtV25v LXVuaW5pdGlhbGl6ZWQgLVduby1wb2ludGVyLXNpZ24gLVduby1lbXB0eS1ib2R5IC1Xbm8t c3RyaW5nLXBsdXMtaW50IC1Xbm8tdGF1dG9sb2dpY2FsLWNvbXBhcmUgLVduby11bnVzZWQt dmFsdWUgLVduby1wYXJlbnRoZXNlcy1lcXVhbGl0eSAtV25vLXVudXNlZC1mdW5jdGlvbiAt V25vLWNvbnZlcnNpb24gIC1jIC91c3Ivc3JjL2NvbnRyaWIvYm1ha2Uvc3VmZi5jDQpjYyAt TyAtcGlwZSAtZyAtRE5PX1BXRF9PVkVSUklERSAtSS91c3Ivc3JjL3Vzci5iaW4vYm1ha2Ug IC1EVVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURIQVZFX0NPTkZJ R19IICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1EX1BBVEhf REVGU1lTUEFUSD1cIi4uLi9zaGFyZS9tazovdXNyL3NoYXJlL21rXCIgLUkuIC1JL3Vzci9z cmMvY29udHJpYi9ibWFrZSAgLURNQUtFX05BVElWRSAgLXN0ZD1nbnU5OSAtUXVudXNlZC1h cmd1bWVudHMgLWZzdGFjay1wcm90ZWN0b3IgLVdzeXN0ZW0taGVhZGVycyAtV2FsbCAtV25v LWZvcm1hdC15MmsgLVcgLVduby11bnVzZWQtcGFyYW1ldGVyIC1Xc3RyaWN0LXByb3RvdHlw ZXMgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdwb2ludGVyLWFyaXRoIC1Xbm8tdW5pbml0aWFs aXplZCAtV25vLXBvaW50ZXItc2lnbiAtV25vLWVtcHR5LWJvZHkgLVduby1zdHJpbmctcGx1 cy1pbnQgLVduby10YXV0b2xvZ2ljYWwtY29tcGFyZSAtV25vLXVudXNlZC12YWx1ZSAtV25v LXBhcmVudGhlc2VzLWVxdWFsaXR5IC1Xbm8tdW51c2VkLWZ1bmN0aW9uIC1Xbm8tY29udmVy c2lvbiAgLWMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS90YXJnLmMNCmNjIC1PIC1waXBlIC1n IC1ETk9fUFdEX09WRVJSSURFIC1JL3Vzci9zcmMvdXNyLmJpbi9ibWFrZSAgLURVU0VfTUVU QSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtREhBVkVfQ09ORklHX0ggIC1EVVNF X01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURfUEFUSF9ERUZTWVNQQVRI PVwiLi4uL3NoYXJlL21rOi91c3Ivc2hhcmUvbWtcIiAtSS4gLUkvdXNyL3NyYy9jb250cmli L2JtYWtlICAtRE1BS0VfTkFUSVZFICAtc3RkPWdudTk5IC1RdW51c2VkLWFyZ3VtZW50cyAt ZnN0YWNrLXByb3RlY3RvciAtV3N5c3RlbS1oZWFkZXJzIC1XYWxsIC1Xbm8tZm9ybWF0LXky ayAtVyAtV25vLXVudXNlZC1wYXJhbWV0ZXIgLVdzdHJpY3QtcHJvdG90eXBlcyAtV21pc3Np bmctcHJvdG90eXBlcyAtV3BvaW50ZXItYXJpdGggLVduby11bmluaXRpYWxpemVkIC1Xbm8t cG9pbnRlci1zaWduIC1Xbm8tZW1wdHktYm9keSAtV25vLXN0cmluZy1wbHVzLWludCAtV25v LXRhdXRvbG9naWNhbC1jb21wYXJlIC1Xbm8tdW51c2VkLXZhbHVlIC1Xbm8tcGFyZW50aGVz ZXMtZXF1YWxpdHkgLVduby11bnVzZWQtZnVuY3Rpb24gLVduby1jb252ZXJzaW9uICAtYyAv dXNyL3NyYy9jb250cmliL2JtYWtlL3RyYWNlLmMNCmNjIC1PIC1waXBlIC1nIC1ETk9fUFdE X09WRVJSSURFIC1JL3Vzci9zcmMvdXNyLmJpbi9ibWFrZSAgLURVU0VfTUVUQSAtRE1BS0Vf TkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtREhBVkVfQ09ORklHX0ggIC1EVVNFX01FVEEgLURN QUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURfUEFUSF9ERUZTWVNQQVRIPVwiLi4uL3No YXJlL21rOi91c3Ivc2hhcmUvbWtcIiAtSS4gLUkvdXNyL3NyYy9jb250cmliL2JtYWtlICAt RE1BS0VfTkFUSVZFICAtc3RkPWdudTk5IC1RdW51c2VkLWFyZ3VtZW50cyAtZnN0YWNrLXBy b3RlY3RvciAtV3N5c3RlbS1oZWFkZXJzIC1XYWxsIC1Xbm8tZm9ybWF0LXkyayAtVyAtV25v LXVudXNlZC1wYXJhbWV0ZXIgLVdzdHJpY3QtcHJvdG90eXBlcyAtV21pc3NpbmctcHJvdG90 eXBlcyAtV3BvaW50ZXItYXJpdGggLVduby11bmluaXRpYWxpemVkIC1Xbm8tcG9pbnRlci1z aWduIC1Xbm8tZW1wdHktYm9keSAtV25vLXN0cmluZy1wbHVzLWludCAtV25vLXRhdXRvbG9n aWNhbC1jb21wYXJlIC1Xbm8tdW51c2VkLXZhbHVlIC1Xbm8tcGFyZW50aGVzZXMtZXF1YWxp dHkgLVduby11bnVzZWQtZnVuY3Rpb24gLVduby1jb252ZXJzaW9uICAtYyAvdXNyL3NyYy9j b250cmliL2JtYWtlL3V0aWwuYw0KY2MgLU8gLXBpcGUgLWcgLUROT19QV0RfT1ZFUlJJREUg LUkvdXNyL3NyYy91c3IuYmluL2JtYWtlICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURI QVZFX0NPTkZJR19IIC1ESEFWRV9DT05GSUdfSCAgLURVU0VfTUVUQSAtRE1BS0VfTkFUSVZF IC1ESEFWRV9DT05GSUdfSCAtRF9QQVRIX0RFRlNZU1BBVEg9XCIuLi4vc2hhcmUvbWs6L3Vz ci9zaGFyZS9ta1wiIC1JLiAtSS91c3Ivc3JjL2NvbnRyaWIvYm1ha2UgIC1ETUFLRV9OQVRJ VkUgLVduby1jYXN0LXF1YWwgLVduby1mb3JtYXQtbm9ubGl0ZXJhbCAtc3RkPWdudTk5IC1R dW51c2VkLWFyZ3VtZW50cyAtZnN0YWNrLXByb3RlY3RvciAtV3N5c3RlbS1oZWFkZXJzIC1X YWxsIC1Xbm8tZm9ybWF0LXkyayAtVyAtV25vLXVudXNlZC1wYXJhbWV0ZXIgLVdzdHJpY3Qt cHJvdG90eXBlcyAtV21pc3NpbmctcHJvdG90eXBlcyAtV3BvaW50ZXItYXJpdGggLVduby11 bmluaXRpYWxpemVkIC1Xbm8tcG9pbnRlci1zaWduIC1Xbm8tZW1wdHktYm9keSAtV25vLXN0 cmluZy1wbHVzLWludCAtV25vLXRhdXRvbG9naWNhbC1jb21wYXJlIC1Xbm8tdW51c2VkLXZh bHVlIC1Xbm8tcGFyZW50aGVzZXMtZXF1YWxpdHkgLVduby11bnVzZWQtZnVuY3Rpb24gLVdu by1jb252ZXJzaW9uIC1Xbm8tY2FzdC1xdWFsIC1Xbm8tZm9ybWF0LW5vbmxpdGVyYWwgLWMg L3Vzci9zcmMvY29udHJpYi9ibWFrZS92YXIuYw0KY2MgLU8gLXBpcGUgLWcgLUROT19QV0Rf T1ZFUlJJREUgLUkvdXNyL3NyYy91c3IuYmluL2JtYWtlICAtRFVTRV9NRVRBIC1ETUFLRV9O QVRJVkUgLURIQVZFX0NPTkZJR19IIC1ESEFWRV9DT05GSUdfSCAgLURVU0VfTUVUQSAtRE1B S0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtRF9QQVRIX0RFRlNZU1BBVEg9XCIuLi4vc2hh cmUvbWs6L3Vzci9zaGFyZS9ta1wiIC1JLiAtSS91c3Ivc3JjL2NvbnRyaWIvYm1ha2UgIC1E TUFLRV9OQVRJVkUgIC1zdGQ9Z251OTkgLVF1bnVzZWQtYXJndW1lbnRzIC1mc3RhY2stcHJv dGVjdG9yIC1Xc3lzdGVtLWhlYWRlcnMgLVdhbGwgLVduby1mb3JtYXQteTJrIC1XIC1Xbm8t dW51c2VkLXBhcmFtZXRlciAtV3N0cmljdC1wcm90b3R5cGVzIC1XbWlzc2luZy1wcm90b3R5 cGVzIC1XcG9pbnRlci1hcml0aCAtV25vLXVuaW5pdGlhbGl6ZWQgLVduby1wb2ludGVyLXNp Z24gLVduby1lbXB0eS1ib2R5IC1Xbm8tc3RyaW5nLXBsdXMtaW50IC1Xbm8tdGF1dG9sb2dp Y2FsLWNvbXBhcmUgLVduby11bnVzZWQtdmFsdWUgLVduby1wYXJlbnRoZXNlcy1lcXVhbGl0 eSAtV25vLXVudXNlZC1mdW5jdGlvbiAtV25vLWNvbnZlcnNpb24gIC1jIC91c3Ivc3JjL2Nv bnRyaWIvYm1ha2UvbHN0LmxpYi9sc3RBcHBlbmQuYw0KY2MgLU8gLXBpcGUgLWcgLUROT19Q V0RfT1ZFUlJJREUgLUkvdXNyL3NyYy91c3IuYmluL2JtYWtlICAtRFVTRV9NRVRBIC1ETUFL RV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1ESEFWRV9DT05GSUdfSCAgLURVU0VfTUVUQSAt RE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtRF9QQVRIX0RFRlNZU1BBVEg9XCIuLi4v c2hhcmUvbWs6L3Vzci9zaGFyZS9ta1wiIC1JLiAtSS91c3Ivc3JjL2NvbnRyaWIvYm1ha2Ug IC1ETUFLRV9OQVRJVkUgIC1zdGQ9Z251OTkgLVF1bnVzZWQtYXJndW1lbnRzIC1mc3RhY2st cHJvdGVjdG9yIC1Xc3lzdGVtLWhlYWRlcnMgLVdhbGwgLVduby1mb3JtYXQteTJrIC1XIC1X bm8tdW51c2VkLXBhcmFtZXRlciAtV3N0cmljdC1wcm90b3R5cGVzIC1XbWlzc2luZy1wcm90 b3R5cGVzIC1XcG9pbnRlci1hcml0aCAtV25vLXVuaW5pdGlhbGl6ZWQgLVduby1wb2ludGVy LXNpZ24gLVduby1lbXB0eS1ib2R5IC1Xbm8tc3RyaW5nLXBsdXMtaW50IC1Xbm8tdGF1dG9s b2dpY2FsLWNvbXBhcmUgLVduby11bnVzZWQtdmFsdWUgLVduby1wYXJlbnRoZXNlcy1lcXVh bGl0eSAtV25vLXVudXNlZC1mdW5jdGlvbiAtV25vLWNvbnZlcnNpb24gIC1jIC91c3Ivc3Jj L2NvbnRyaWIvYm1ha2UvbHN0LmxpYi9sc3RBdEVuZC5jDQpjYyAtTyAtcGlwZSAtZyAtRE5P X1BXRF9PVkVSUklERSAtSS91c3Ivc3JjL3Vzci5iaW4vYm1ha2UgIC1EVVNFX01FVEEgLURN QUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURIQVZFX0NPTkZJR19IICAtRFVTRV9NRVRB IC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1EX1BBVEhfREVGU1lTUEFUSD1cIi4u Li9zaGFyZS9tazovdXNyL3NoYXJlL21rXCIgLUkuIC1JL3Vzci9zcmMvY29udHJpYi9ibWFr ZSAgLURNQUtFX05BVElWRSAgLXN0ZD1nbnU5OSAtUXVudXNlZC1hcmd1bWVudHMgLWZzdGFj ay1wcm90ZWN0b3IgLVdzeXN0ZW0taGVhZGVycyAtV2FsbCAtV25vLWZvcm1hdC15MmsgLVcg LVduby11bnVzZWQtcGFyYW1ldGVyIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdtaXNzaW5nLXBy b3RvdHlwZXMgLVdwb2ludGVyLWFyaXRoIC1Xbm8tdW5pbml0aWFsaXplZCAtV25vLXBvaW50 ZXItc2lnbiAtV25vLWVtcHR5LWJvZHkgLVduby1zdHJpbmctcGx1cy1pbnQgLVduby10YXV0 b2xvZ2ljYWwtY29tcGFyZSAtV25vLXVudXNlZC12YWx1ZSAtV25vLXBhcmVudGhlc2VzLWVx dWFsaXR5IC1Xbm8tdW51c2VkLWZ1bmN0aW9uIC1Xbm8tY29udmVyc2lvbiAgLWMgL3Vzci9z cmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdEF0RnJvbnQuYw0KY2MgLU8gLXBpcGUgLWcg LUROT19QV0RfT1ZFUlJJREUgLUkvdXNyL3NyYy91c3IuYmluL2JtYWtlICAtRFVTRV9NRVRB IC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1ESEFWRV9DT05GSUdfSCAgLURVU0Vf TUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtRF9QQVRIX0RFRlNZU1BBVEg9 XCIuLi4vc2hhcmUvbWs6L3Vzci9zaGFyZS9ta1wiIC1JLiAtSS91c3Ivc3JjL2NvbnRyaWIv Ym1ha2UgIC1ETUFLRV9OQVRJVkUgIC1zdGQ9Z251OTkgLVF1bnVzZWQtYXJndW1lbnRzIC1m c3RhY2stcHJvdGVjdG9yIC1Xc3lzdGVtLWhlYWRlcnMgLVdhbGwgLVduby1mb3JtYXQteTJr IC1XIC1Xbm8tdW51c2VkLXBhcmFtZXRlciAtV3N0cmljdC1wcm90b3R5cGVzIC1XbWlzc2lu Zy1wcm90b3R5cGVzIC1XcG9pbnRlci1hcml0aCAtV25vLXVuaW5pdGlhbGl6ZWQgLVduby1w b2ludGVyLXNpZ24gLVduby1lbXB0eS1ib2R5IC1Xbm8tc3RyaW5nLXBsdXMtaW50IC1Xbm8t dGF1dG9sb2dpY2FsLWNvbXBhcmUgLVduby11bnVzZWQtdmFsdWUgLVduby1wYXJlbnRoZXNl cy1lcXVhbGl0eSAtV25vLXVudXNlZC1mdW5jdGlvbiAtV25vLWNvbnZlcnNpb24gIC1jIC91 c3Ivc3JjL2NvbnRyaWIvYm1ha2UvbHN0LmxpYi9sc3RDbG9zZS5jDQpjYyAtTyAtcGlwZSAt ZyAtRE5PX1BXRF9PVkVSUklERSAtSS91c3Ivc3JjL3Vzci5iaW4vYm1ha2UgIC1EVVNFX01F VEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURIQVZFX0NPTkZJR19IICAtRFVT RV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1EX1BBVEhfREVGU1lTUEFU SD1cIi4uLi9zaGFyZS9tazovdXNyL3NoYXJlL21rXCIgLUkuIC1JL3Vzci9zcmMvY29udHJp Yi9ibWFrZSAgLURNQUtFX05BVElWRSAgLXN0ZD1nbnU5OSAtUXVudXNlZC1hcmd1bWVudHMg LWZzdGFjay1wcm90ZWN0b3IgLVdzeXN0ZW0taGVhZGVycyAtV2FsbCAtV25vLWZvcm1hdC15 MmsgLVcgLVduby11bnVzZWQtcGFyYW1ldGVyIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdtaXNz aW5nLXByb3RvdHlwZXMgLVdwb2ludGVyLWFyaXRoIC1Xbm8tdW5pbml0aWFsaXplZCAtV25v LXBvaW50ZXItc2lnbiAtV25vLWVtcHR5LWJvZHkgLVduby1zdHJpbmctcGx1cy1pbnQgLVdu by10YXV0b2xvZ2ljYWwtY29tcGFyZSAtV25vLXVudXNlZC12YWx1ZSAtV25vLXBhcmVudGhl c2VzLWVxdWFsaXR5IC1Xbm8tdW51c2VkLWZ1bmN0aW9uIC1Xbm8tY29udmVyc2lvbiAgLWMg L3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdENvbmNhdC5jDQpjYyAtTyAtcGlw ZSAtZyAtRE5PX1BXRF9PVkVSUklERSAtSS91c3Ivc3JjL3Vzci5iaW4vYm1ha2UgIC1EVVNF X01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURIQVZFX0NPTkZJR19IICAt RFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1EX1BBVEhfREVGU1lT UEFUSD1cIi4uLi9zaGFyZS9tazovdXNyL3NoYXJlL21rXCIgLUkuIC1JL3Vzci9zcmMvY29u dHJpYi9ibWFrZSAgLURNQUtFX05BVElWRSAgLXN0ZD1nbnU5OSAtUXVudXNlZC1hcmd1bWVu dHMgLWZzdGFjay1wcm90ZWN0b3IgLVdzeXN0ZW0taGVhZGVycyAtV2FsbCAtV25vLWZvcm1h dC15MmsgLVcgLVduby11bnVzZWQtcGFyYW1ldGVyIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdt aXNzaW5nLXByb3RvdHlwZXMgLVdwb2ludGVyLWFyaXRoIC1Xbm8tdW5pbml0aWFsaXplZCAt V25vLXBvaW50ZXItc2lnbiAtV25vLWVtcHR5LWJvZHkgLVduby1zdHJpbmctcGx1cy1pbnQg LVduby10YXV0b2xvZ2ljYWwtY29tcGFyZSAtV25vLXVudXNlZC12YWx1ZSAtV25vLXBhcmVu dGhlc2VzLWVxdWFsaXR5IC1Xbm8tdW51c2VkLWZ1bmN0aW9uIC1Xbm8tY29udmVyc2lvbiAg LWMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdERhdHVtLmMNCmNjIC1PIC1w aXBlIC1nIC1ETk9fUFdEX09WRVJSSURFIC1JL3Vzci9zcmMvdXNyLmJpbi9ibWFrZSAgLURV U0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtREhBVkVfQ09ORklHX0gg IC1EVVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURfUEFUSF9ERUZT WVNQQVRIPVwiLi4uL3NoYXJlL21rOi91c3Ivc2hhcmUvbWtcIiAtSS4gLUkvdXNyL3NyYy9j b250cmliL2JtYWtlICAtRE1BS0VfTkFUSVZFICAtc3RkPWdudTk5IC1RdW51c2VkLWFyZ3Vt ZW50cyAtZnN0YWNrLXByb3RlY3RvciAtV3N5c3RlbS1oZWFkZXJzIC1XYWxsIC1Xbm8tZm9y bWF0LXkyayAtVyAtV25vLXVudXNlZC1wYXJhbWV0ZXIgLVdzdHJpY3QtcHJvdG90eXBlcyAt V21pc3NpbmctcHJvdG90eXBlcyAtV3BvaW50ZXItYXJpdGggLVduby11bmluaXRpYWxpemVk IC1Xbm8tcG9pbnRlci1zaWduIC1Xbm8tZW1wdHktYm9keSAtV25vLXN0cmluZy1wbHVzLWlu dCAtV25vLXRhdXRvbG9naWNhbC1jb21wYXJlIC1Xbm8tdW51c2VkLXZhbHVlIC1Xbm8tcGFy ZW50aGVzZXMtZXF1YWxpdHkgLVduby11bnVzZWQtZnVuY3Rpb24gLVduby1jb252ZXJzaW9u ICAtYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL2xzdC5saWIvbHN0RGVRdWV1ZS5jDQpjYyAt TyAtcGlwZSAtZyAtRE5PX1BXRF9PVkVSUklERSAtSS91c3Ivc3JjL3Vzci5iaW4vYm1ha2Ug IC1EVVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURIQVZFX0NPTkZJ R19IICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1EX1BBVEhf REVGU1lTUEFUSD1cIi4uLi9zaGFyZS9tazovdXNyL3NoYXJlL21rXCIgLUkuIC1JL3Vzci9z cmMvY29udHJpYi9ibWFrZSAgLURNQUtFX05BVElWRSAgLXN0ZD1nbnU5OSAtUXVudXNlZC1h cmd1bWVudHMgLWZzdGFjay1wcm90ZWN0b3IgLVdzeXN0ZW0taGVhZGVycyAtV2FsbCAtV25v LWZvcm1hdC15MmsgLVcgLVduby11bnVzZWQtcGFyYW1ldGVyIC1Xc3RyaWN0LXByb3RvdHlw ZXMgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdwb2ludGVyLWFyaXRoIC1Xbm8tdW5pbml0aWFs aXplZCAtV25vLXBvaW50ZXItc2lnbiAtV25vLWVtcHR5LWJvZHkgLVduby1zdHJpbmctcGx1 cy1pbnQgLVduby10YXV0b2xvZ2ljYWwtY29tcGFyZSAtV25vLXVudXNlZC12YWx1ZSAtV25v LXBhcmVudGhlc2VzLWVxdWFsaXR5IC1Xbm8tdW51c2VkLWZ1bmN0aW9uIC1Xbm8tY29udmVy c2lvbiAgLWMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdERlc3Ryb3kuYw0K Y2MgLU8gLXBpcGUgLWcgLUROT19QV0RfT1ZFUlJJREUgLUkvdXNyL3NyYy91c3IuYmluL2Jt YWtlICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1ESEFWRV9D T05GSUdfSCAgLURVU0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtRF9Q QVRIX0RFRlNZU1BBVEg9XCIuLi4vc2hhcmUvbWs6L3Vzci9zaGFyZS9ta1wiIC1JLiAtSS91 c3Ivc3JjL2NvbnRyaWIvYm1ha2UgIC1ETUFLRV9OQVRJVkUgIC1zdGQ9Z251OTkgLVF1bnVz ZWQtYXJndW1lbnRzIC1mc3RhY2stcHJvdGVjdG9yIC1Xc3lzdGVtLWhlYWRlcnMgLVdhbGwg LVduby1mb3JtYXQteTJrIC1XIC1Xbm8tdW51c2VkLXBhcmFtZXRlciAtV3N0cmljdC1wcm90 b3R5cGVzIC1XbWlzc2luZy1wcm90b3R5cGVzIC1XcG9pbnRlci1hcml0aCAtV25vLXVuaW5p dGlhbGl6ZWQgLVduby1wb2ludGVyLXNpZ24gLVduby1lbXB0eS1ib2R5IC1Xbm8tc3RyaW5n LXBsdXMtaW50IC1Xbm8tdGF1dG9sb2dpY2FsLWNvbXBhcmUgLVduby11bnVzZWQtdmFsdWUg LVduby1wYXJlbnRoZXNlcy1lcXVhbGl0eSAtV25vLXVudXNlZC1mdW5jdGlvbiAtV25vLWNv bnZlcnNpb24gIC1jIC91c3Ivc3JjL2NvbnRyaWIvYm1ha2UvbHN0LmxpYi9sc3REdXBsLmMN CmNjIC1PIC1waXBlIC1nIC1ETk9fUFdEX09WRVJSSURFIC1JL3Vzci9zcmMvdXNyLmJpbi9i bWFrZSAgLURVU0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtREhBVkVf Q09ORklHX0ggIC1EVVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURf UEFUSF9ERUZTWVNQQVRIPVwiLi4uL3NoYXJlL21rOi91c3Ivc2hhcmUvbWtcIiAtSS4gLUkv dXNyL3NyYy9jb250cmliL2JtYWtlICAtRE1BS0VfTkFUSVZFICAtc3RkPWdudTk5IC1RdW51 c2VkLWFyZ3VtZW50cyAtZnN0YWNrLXByb3RlY3RvciAtV3N5c3RlbS1oZWFkZXJzIC1XYWxs IC1Xbm8tZm9ybWF0LXkyayAtVyAtV25vLXVudXNlZC1wYXJhbWV0ZXIgLVdzdHJpY3QtcHJv dG90eXBlcyAtV21pc3NpbmctcHJvdG90eXBlcyAtV3BvaW50ZXItYXJpdGggLVduby11bmlu aXRpYWxpemVkIC1Xbm8tcG9pbnRlci1zaWduIC1Xbm8tZW1wdHktYm9keSAtV25vLXN0cmlu Zy1wbHVzLWludCAtV25vLXRhdXRvbG9naWNhbC1jb21wYXJlIC1Xbm8tdW51c2VkLXZhbHVl IC1Xbm8tcGFyZW50aGVzZXMtZXF1YWxpdHkgLVduby11bnVzZWQtZnVuY3Rpb24gLVduby1j b252ZXJzaW9uICAtYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL2xzdC5saWIvbHN0RW5RdWV1 ZS5jDQpjYyAtTyAtcGlwZSAtZyAtRE5PX1BXRF9PVkVSUklERSAtSS91c3Ivc3JjL3Vzci5i aW4vYm1ha2UgIC1EVVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURI QVZFX0NPTkZJR19IICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19I IC1EX1BBVEhfREVGU1lTUEFUSD1cIi4uLi9zaGFyZS9tazovdXNyL3NoYXJlL21rXCIgLUku IC1JL3Vzci9zcmMvY29udHJpYi9ibWFrZSAgLURNQUtFX05BVElWRSAgLXN0ZD1nbnU5OSAt UXVudXNlZC1hcmd1bWVudHMgLWZzdGFjay1wcm90ZWN0b3IgLVdzeXN0ZW0taGVhZGVycyAt V2FsbCAtV25vLWZvcm1hdC15MmsgLVcgLVduby11bnVzZWQtcGFyYW1ldGVyIC1Xc3RyaWN0 LXByb3RvdHlwZXMgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdwb2ludGVyLWFyaXRoIC1Xbm8t dW5pbml0aWFsaXplZCAtV25vLXBvaW50ZXItc2lnbiAtV25vLWVtcHR5LWJvZHkgLVduby1z dHJpbmctcGx1cy1pbnQgLVduby10YXV0b2xvZ2ljYWwtY29tcGFyZSAtV25vLXVudXNlZC12 YWx1ZSAtV25vLXBhcmVudGhlc2VzLWVxdWFsaXR5IC1Xbm8tdW51c2VkLWZ1bmN0aW9uIC1X bm8tY29udmVyc2lvbiAgLWMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdEZp bmQuYw0KY2MgLU8gLXBpcGUgLWcgLUROT19QV0RfT1ZFUlJJREUgLUkvdXNyL3NyYy91c3Iu YmluL2JtYWtlICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1E SEFWRV9DT05GSUdfSCAgLURVU0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdf SCAtRF9QQVRIX0RFRlNZU1BBVEg9XCIuLi4vc2hhcmUvbWs6L3Vzci9zaGFyZS9ta1wiIC1J LiAtSS91c3Ivc3JjL2NvbnRyaWIvYm1ha2UgIC1ETUFLRV9OQVRJVkUgIC1zdGQ9Z251OTkg LVF1bnVzZWQtYXJndW1lbnRzIC1mc3RhY2stcHJvdGVjdG9yIC1Xc3lzdGVtLWhlYWRlcnMg LVdhbGwgLVduby1mb3JtYXQteTJrIC1XIC1Xbm8tdW51c2VkLXBhcmFtZXRlciAtV3N0cmlj dC1wcm90b3R5cGVzIC1XbWlzc2luZy1wcm90b3R5cGVzIC1XcG9pbnRlci1hcml0aCAtV25v LXVuaW5pdGlhbGl6ZWQgLVduby1wb2ludGVyLXNpZ24gLVduby1lbXB0eS1ib2R5IC1Xbm8t c3RyaW5nLXBsdXMtaW50IC1Xbm8tdGF1dG9sb2dpY2FsLWNvbXBhcmUgLVduby11bnVzZWQt dmFsdWUgLVduby1wYXJlbnRoZXNlcy1lcXVhbGl0eSAtV25vLXVudXNlZC1mdW5jdGlvbiAt V25vLWNvbnZlcnNpb24gIC1jIC91c3Ivc3JjL2NvbnRyaWIvYm1ha2UvbHN0LmxpYi9sc3RG aW5kRnJvbS5jDQpjYyAtTyAtcGlwZSAtZyAtRE5PX1BXRF9PVkVSUklERSAtSS91c3Ivc3Jj L3Vzci5iaW4vYm1ha2UgIC1EVVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklH X0ggLURIQVZFX0NPTkZJR19IICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NP TkZJR19IIC1EX1BBVEhfREVGU1lTUEFUSD1cIi4uLi9zaGFyZS9tazovdXNyL3NoYXJlL21r XCIgLUkuIC1JL3Vzci9zcmMvY29udHJpYi9ibWFrZSAgLURNQUtFX05BVElWRSAgLXN0ZD1n bnU5OSAtUXVudXNlZC1hcmd1bWVudHMgLWZzdGFjay1wcm90ZWN0b3IgLVdzeXN0ZW0taGVh ZGVycyAtV2FsbCAtV25vLWZvcm1hdC15MmsgLVcgLVduby11bnVzZWQtcGFyYW1ldGVyIC1X c3RyaWN0LXByb3RvdHlwZXMgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdwb2ludGVyLWFyaXRo IC1Xbm8tdW5pbml0aWFsaXplZCAtV25vLXBvaW50ZXItc2lnbiAtV25vLWVtcHR5LWJvZHkg LVduby1zdHJpbmctcGx1cy1pbnQgLVduby10YXV0b2xvZ2ljYWwtY29tcGFyZSAtV25vLXVu dXNlZC12YWx1ZSAtV25vLXBhcmVudGhlc2VzLWVxdWFsaXR5IC1Xbm8tdW51c2VkLWZ1bmN0 aW9uIC1Xbm8tY29udmVyc2lvbiAgLWMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGli L2xzdEZpcnN0LmMNCmNjIC1PIC1waXBlIC1nIC1ETk9fUFdEX09WRVJSSURFIC1JL3Vzci9z cmMvdXNyLmJpbi9ibWFrZSAgLURVU0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05G SUdfSCAtREhBVkVfQ09ORklHX0ggIC1EVVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVf Q09ORklHX0ggLURfUEFUSF9ERUZTWVNQQVRIPVwiLi4uL3NoYXJlL21rOi91c3Ivc2hhcmUv bWtcIiAtSS4gLUkvdXNyL3NyYy9jb250cmliL2JtYWtlICAtRE1BS0VfTkFUSVZFICAtc3Rk PWdudTk5IC1RdW51c2VkLWFyZ3VtZW50cyAtZnN0YWNrLXByb3RlY3RvciAtV3N5c3RlbS1o ZWFkZXJzIC1XYWxsIC1Xbm8tZm9ybWF0LXkyayAtVyAtV25vLXVudXNlZC1wYXJhbWV0ZXIg LVdzdHJpY3QtcHJvdG90eXBlcyAtV21pc3NpbmctcHJvdG90eXBlcyAtV3BvaW50ZXItYXJp dGggLVduby11bmluaXRpYWxpemVkIC1Xbm8tcG9pbnRlci1zaWduIC1Xbm8tZW1wdHktYm9k eSAtV25vLXN0cmluZy1wbHVzLWludCAtV25vLXRhdXRvbG9naWNhbC1jb21wYXJlIC1Xbm8t dW51c2VkLXZhbHVlIC1Xbm8tcGFyZW50aGVzZXMtZXF1YWxpdHkgLVduby11bnVzZWQtZnVu Y3Rpb24gLVduby1jb252ZXJzaW9uICAtYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL2xzdC5s aWIvbHN0Rm9yRWFjaC5jDQpjYyAtTyAtcGlwZSAtZyAtRE5PX1BXRF9PVkVSUklERSAtSS91 c3Ivc3JjL3Vzci5iaW4vYm1ha2UgIC1EVVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVf Q09ORklHX0ggLURIQVZFX0NPTkZJR19IICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURI QVZFX0NPTkZJR19IIC1EX1BBVEhfREVGU1lTUEFUSD1cIi4uLi9zaGFyZS9tazovdXNyL3No YXJlL21rXCIgLUkuIC1JL3Vzci9zcmMvY29udHJpYi9ibWFrZSAgLURNQUtFX05BVElWRSAg LXN0ZD1nbnU5OSAtUXVudXNlZC1hcmd1bWVudHMgLWZzdGFjay1wcm90ZWN0b3IgLVdzeXN0 ZW0taGVhZGVycyAtV2FsbCAtV25vLWZvcm1hdC15MmsgLVcgLVduby11bnVzZWQtcGFyYW1l dGVyIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdwb2ludGVy LWFyaXRoIC1Xbm8tdW5pbml0aWFsaXplZCAtV25vLXBvaW50ZXItc2lnbiAtV25vLWVtcHR5 LWJvZHkgLVduby1zdHJpbmctcGx1cy1pbnQgLVduby10YXV0b2xvZ2ljYWwtY29tcGFyZSAt V25vLXVudXNlZC12YWx1ZSAtV25vLXBhcmVudGhlc2VzLWVxdWFsaXR5IC1Xbm8tdW51c2Vk LWZ1bmN0aW9uIC1Xbm8tY29udmVyc2lvbiAgLWMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9s c3QubGliL2xzdEZvckVhY2hGcm9tLmMNCmNjIC1PIC1waXBlIC1nIC1ETk9fUFdEX09WRVJS SURFIC1JL3Vzci9zcmMvdXNyLmJpbi9ibWFrZSAgLURVU0VfTUVUQSAtRE1BS0VfTkFUSVZF IC1ESEFWRV9DT05GSUdfSCAtREhBVkVfQ09ORklHX0ggIC1EVVNFX01FVEEgLURNQUtFX05B VElWRSAtREhBVkVfQ09ORklHX0ggLURfUEFUSF9ERUZTWVNQQVRIPVwiLi4uL3NoYXJlL21r Oi91c3Ivc2hhcmUvbWtcIiAtSS4gLUkvdXNyL3NyYy9jb250cmliL2JtYWtlICAtRE1BS0Vf TkFUSVZFICAtc3RkPWdudTk5IC1RdW51c2VkLWFyZ3VtZW50cyAtZnN0YWNrLXByb3RlY3Rv ciAtV3N5c3RlbS1oZWFkZXJzIC1XYWxsIC1Xbm8tZm9ybWF0LXkyayAtVyAtV25vLXVudXNl ZC1wYXJhbWV0ZXIgLVdzdHJpY3QtcHJvdG90eXBlcyAtV21pc3NpbmctcHJvdG90eXBlcyAt V3BvaW50ZXItYXJpdGggLVduby11bmluaXRpYWxpemVkIC1Xbm8tcG9pbnRlci1zaWduIC1X bm8tZW1wdHktYm9keSAtV25vLXN0cmluZy1wbHVzLWludCAtV25vLXRhdXRvbG9naWNhbC1j b21wYXJlIC1Xbm8tdW51c2VkLXZhbHVlIC1Xbm8tcGFyZW50aGVzZXMtZXF1YWxpdHkgLVdu by11bnVzZWQtZnVuY3Rpb24gLVduby1jb252ZXJzaW9uICAtYyAvdXNyL3NyYy9jb250cmli L2JtYWtlL2xzdC5saWIvbHN0SW5pdC5jDQpjYyAtTyAtcGlwZSAtZyAtRE5PX1BXRF9PVkVS UklERSAtSS91c3Ivc3JjL3Vzci5iaW4vYm1ha2UgIC1EVVNFX01FVEEgLURNQUtFX05BVElW RSAtREhBVkVfQ09ORklHX0ggLURIQVZFX0NPTkZJR19IICAtRFVTRV9NRVRBIC1ETUFLRV9O QVRJVkUgLURIQVZFX0NPTkZJR19IIC1EX1BBVEhfREVGU1lTUEFUSD1cIi4uLi9zaGFyZS9t azovdXNyL3NoYXJlL21rXCIgLUkuIC1JL3Vzci9zcmMvY29udHJpYi9ibWFrZSAgLURNQUtF X05BVElWRSAgLXN0ZD1nbnU5OSAtUXVudXNlZC1hcmd1bWVudHMgLWZzdGFjay1wcm90ZWN0 b3IgLVdzeXN0ZW0taGVhZGVycyAtV2FsbCAtV25vLWZvcm1hdC15MmsgLVcgLVduby11bnVz ZWQtcGFyYW1ldGVyIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdtaXNzaW5nLXByb3RvdHlwZXMg LVdwb2ludGVyLWFyaXRoIC1Xbm8tdW5pbml0aWFsaXplZCAtV25vLXBvaW50ZXItc2lnbiAt V25vLWVtcHR5LWJvZHkgLVduby1zdHJpbmctcGx1cy1pbnQgLVduby10YXV0b2xvZ2ljYWwt Y29tcGFyZSAtV25vLXVudXNlZC12YWx1ZSAtV25vLXBhcmVudGhlc2VzLWVxdWFsaXR5IC1X bm8tdW51c2VkLWZ1bmN0aW9uIC1Xbm8tY29udmVyc2lvbiAgLWMgL3Vzci9zcmMvY29udHJp Yi9ibWFrZS9sc3QubGliL2xzdEluc2VydC5jDQpjYyAtTyAtcGlwZSAtZyAtRE5PX1BXRF9P VkVSUklERSAtSS91c3Ivc3JjL3Vzci5iaW4vYm1ha2UgIC1EVVNFX01FVEEgLURNQUtFX05B VElWRSAtREhBVkVfQ09ORklHX0ggLURIQVZFX0NPTkZJR19IICAtRFVTRV9NRVRBIC1ETUFL RV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1EX1BBVEhfREVGU1lTUEFUSD1cIi4uLi9zaGFy ZS9tazovdXNyL3NoYXJlL21rXCIgLUkuIC1JL3Vzci9zcmMvY29udHJpYi9ibWFrZSAgLURN QUtFX05BVElWRSAgLXN0ZD1nbnU5OSAtUXVudXNlZC1hcmd1bWVudHMgLWZzdGFjay1wcm90 ZWN0b3IgLVdzeXN0ZW0taGVhZGVycyAtV2FsbCAtV25vLWZvcm1hdC15MmsgLVcgLVduby11 bnVzZWQtcGFyYW1ldGVyIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdtaXNzaW5nLXByb3RvdHlw ZXMgLVdwb2ludGVyLWFyaXRoIC1Xbm8tdW5pbml0aWFsaXplZCAtV25vLXBvaW50ZXItc2ln biAtV25vLWVtcHR5LWJvZHkgLVduby1zdHJpbmctcGx1cy1pbnQgLVduby10YXV0b2xvZ2lj YWwtY29tcGFyZSAtV25vLXVudXNlZC12YWx1ZSAtV25vLXBhcmVudGhlc2VzLWVxdWFsaXR5 IC1Xbm8tdW51c2VkLWZ1bmN0aW9uIC1Xbm8tY29udmVyc2lvbiAgLWMgL3Vzci9zcmMvY29u dHJpYi9ibWFrZS9sc3QubGliL2xzdElzQXRFbmQuYw0KY2MgLU8gLXBpcGUgLWcgLUROT19Q V0RfT1ZFUlJJREUgLUkvdXNyL3NyYy91c3IuYmluL2JtYWtlICAtRFVTRV9NRVRBIC1ETUFL RV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1ESEFWRV9DT05GSUdfSCAgLURVU0VfTUVUQSAt RE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtRF9QQVRIX0RFRlNZU1BBVEg9XCIuLi4v c2hhcmUvbWs6L3Vzci9zaGFyZS9ta1wiIC1JLiAtSS91c3Ivc3JjL2NvbnRyaWIvYm1ha2Ug IC1ETUFLRV9OQVRJVkUgIC1zdGQ9Z251OTkgLVF1bnVzZWQtYXJndW1lbnRzIC1mc3RhY2st cHJvdGVjdG9yIC1Xc3lzdGVtLWhlYWRlcnMgLVdhbGwgLVduby1mb3JtYXQteTJrIC1XIC1X bm8tdW51c2VkLXBhcmFtZXRlciAtV3N0cmljdC1wcm90b3R5cGVzIC1XbWlzc2luZy1wcm90 b3R5cGVzIC1XcG9pbnRlci1hcml0aCAtV25vLXVuaW5pdGlhbGl6ZWQgLVduby1wb2ludGVy LXNpZ24gLVduby1lbXB0eS1ib2R5IC1Xbm8tc3RyaW5nLXBsdXMtaW50IC1Xbm8tdGF1dG9s b2dpY2FsLWNvbXBhcmUgLVduby11bnVzZWQtdmFsdWUgLVduby1wYXJlbnRoZXNlcy1lcXVh bGl0eSAtV25vLXVudXNlZC1mdW5jdGlvbiAtV25vLWNvbnZlcnNpb24gIC1jIC91c3Ivc3Jj L2NvbnRyaWIvYm1ha2UvbHN0LmxpYi9sc3RJc0VtcHR5LmMNCmNjIC1PIC1waXBlIC1nIC1E Tk9fUFdEX09WRVJSSURFIC1JL3Vzci9zcmMvdXNyLmJpbi9ibWFrZSAgLURVU0VfTUVUQSAt RE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtREhBVkVfQ09ORklHX0ggIC1EVVNFX01F VEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURfUEFUSF9ERUZTWVNQQVRIPVwi Li4uL3NoYXJlL21rOi91c3Ivc2hhcmUvbWtcIiAtSS4gLUkvdXNyL3NyYy9jb250cmliL2Jt YWtlICAtRE1BS0VfTkFUSVZFICAtc3RkPWdudTk5IC1RdW51c2VkLWFyZ3VtZW50cyAtZnN0 YWNrLXByb3RlY3RvciAtV3N5c3RlbS1oZWFkZXJzIC1XYWxsIC1Xbm8tZm9ybWF0LXkyayAt VyAtV25vLXVudXNlZC1wYXJhbWV0ZXIgLVdzdHJpY3QtcHJvdG90eXBlcyAtV21pc3Npbmct cHJvdG90eXBlcyAtV3BvaW50ZXItYXJpdGggLVduby11bmluaXRpYWxpemVkIC1Xbm8tcG9p bnRlci1zaWduIC1Xbm8tZW1wdHktYm9keSAtV25vLXN0cmluZy1wbHVzLWludCAtV25vLXRh dXRvbG9naWNhbC1jb21wYXJlIC1Xbm8tdW51c2VkLXZhbHVlIC1Xbm8tcGFyZW50aGVzZXMt ZXF1YWxpdHkgLVduby11bnVzZWQtZnVuY3Rpb24gLVduby1jb252ZXJzaW9uICAtYyAvdXNy L3NyYy9jb250cmliL2JtYWtlL2xzdC5saWIvbHN0TGFzdC5jDQpjYyAtTyAtcGlwZSAtZyAt RE5PX1BXRF9PVkVSUklERSAtSS91c3Ivc3JjL3Vzci5iaW4vYm1ha2UgIC1EVVNFX01FVEEg LURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURIQVZFX0NPTkZJR19IICAtRFVTRV9N RVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1EX1BBVEhfREVGU1lTUEFUSD1c Ii4uLi9zaGFyZS9tazovdXNyL3NoYXJlL21rXCIgLUkuIC1JL3Vzci9zcmMvY29udHJpYi9i bWFrZSAgLURNQUtFX05BVElWRSAgLXN0ZD1nbnU5OSAtUXVudXNlZC1hcmd1bWVudHMgLWZz dGFjay1wcm90ZWN0b3IgLVdzeXN0ZW0taGVhZGVycyAtV2FsbCAtV25vLWZvcm1hdC15Mmsg LVcgLVduby11bnVzZWQtcGFyYW1ldGVyIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdtaXNzaW5n LXByb3RvdHlwZXMgLVdwb2ludGVyLWFyaXRoIC1Xbm8tdW5pbml0aWFsaXplZCAtV25vLXBv aW50ZXItc2lnbiAtV25vLWVtcHR5LWJvZHkgLVduby1zdHJpbmctcGx1cy1pbnQgLVduby10 YXV0b2xvZ2ljYWwtY29tcGFyZSAtV25vLXVudXNlZC12YWx1ZSAtV25vLXBhcmVudGhlc2Vz LWVxdWFsaXR5IC1Xbm8tdW51c2VkLWZ1bmN0aW9uIC1Xbm8tY29udmVyc2lvbiAgLWMgL3Vz ci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdE1lbWJlci5jDQpjYyAtTyAtcGlwZSAt ZyAtRE5PX1BXRF9PVkVSUklERSAtSS91c3Ivc3JjL3Vzci5iaW4vYm1ha2UgIC1EVVNFX01F VEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURIQVZFX0NPTkZJR19IICAtRFVT RV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1EX1BBVEhfREVGU1lTUEFU SD1cIi4uLi9zaGFyZS9tazovdXNyL3NoYXJlL21rXCIgLUkuIC1JL3Vzci9zcmMvY29udHJp Yi9ibWFrZSAgLURNQUtFX05BVElWRSAgLXN0ZD1nbnU5OSAtUXVudXNlZC1hcmd1bWVudHMg LWZzdGFjay1wcm90ZWN0b3IgLVdzeXN0ZW0taGVhZGVycyAtV2FsbCAtV25vLWZvcm1hdC15 MmsgLVcgLVduby11bnVzZWQtcGFyYW1ldGVyIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdtaXNz aW5nLXByb3RvdHlwZXMgLVdwb2ludGVyLWFyaXRoIC1Xbm8tdW5pbml0aWFsaXplZCAtV25v LXBvaW50ZXItc2lnbiAtV25vLWVtcHR5LWJvZHkgLVduby1zdHJpbmctcGx1cy1pbnQgLVdu by10YXV0b2xvZ2ljYWwtY29tcGFyZSAtV25vLXVudXNlZC12YWx1ZSAtV25vLXBhcmVudGhl c2VzLWVxdWFsaXR5IC1Xbm8tdW51c2VkLWZ1bmN0aW9uIC1Xbm8tY29udmVyc2lvbiAgLWMg L3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdE5leHQuYw0KY2MgLU8gLXBpcGUg LWcgLUROT19QV0RfT1ZFUlJJREUgLUkvdXNyL3NyYy91c3IuYmluL2JtYWtlICAtRFVTRV9N RVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1ESEFWRV9DT05GSUdfSCAgLURV U0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtRF9QQVRIX0RFRlNZU1BB VEg9XCIuLi4vc2hhcmUvbWs6L3Vzci9zaGFyZS9ta1wiIC1JLiAtSS91c3Ivc3JjL2NvbnRy aWIvYm1ha2UgIC1ETUFLRV9OQVRJVkUgIC1zdGQ9Z251OTkgLVF1bnVzZWQtYXJndW1lbnRz IC1mc3RhY2stcHJvdGVjdG9yIC1Xc3lzdGVtLWhlYWRlcnMgLVdhbGwgLVduby1mb3JtYXQt eTJrIC1XIC1Xbm8tdW51c2VkLXBhcmFtZXRlciAtV3N0cmljdC1wcm90b3R5cGVzIC1XbWlz c2luZy1wcm90b3R5cGVzIC1XcG9pbnRlci1hcml0aCAtV25vLXVuaW5pdGlhbGl6ZWQgLVdu by1wb2ludGVyLXNpZ24gLVduby1lbXB0eS1ib2R5IC1Xbm8tc3RyaW5nLXBsdXMtaW50IC1X bm8tdGF1dG9sb2dpY2FsLWNvbXBhcmUgLVduby11bnVzZWQtdmFsdWUgLVduby1wYXJlbnRo ZXNlcy1lcXVhbGl0eSAtV25vLXVudXNlZC1mdW5jdGlvbiAtV25vLWNvbnZlcnNpb24gIC1j IC91c3Ivc3JjL2NvbnRyaWIvYm1ha2UvbHN0LmxpYi9sc3RPcGVuLmMNCmNjIC1PIC1waXBl IC1nIC1ETk9fUFdEX09WRVJSSURFIC1JL3Vzci9zcmMvdXNyLmJpbi9ibWFrZSAgLURVU0Vf TUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtREhBVkVfQ09ORklHX0ggIC1E VVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURfUEFUSF9ERUZTWVNQ QVRIPVwiLi4uL3NoYXJlL21rOi91c3Ivc2hhcmUvbWtcIiAtSS4gLUkvdXNyL3NyYy9jb250 cmliL2JtYWtlICAtRE1BS0VfTkFUSVZFICAtc3RkPWdudTk5IC1RdW51c2VkLWFyZ3VtZW50 cyAtZnN0YWNrLXByb3RlY3RvciAtV3N5c3RlbS1oZWFkZXJzIC1XYWxsIC1Xbm8tZm9ybWF0 LXkyayAtVyAtV25vLXVudXNlZC1wYXJhbWV0ZXIgLVdzdHJpY3QtcHJvdG90eXBlcyAtV21p c3NpbmctcHJvdG90eXBlcyAtV3BvaW50ZXItYXJpdGggLVduby11bmluaXRpYWxpemVkIC1X bm8tcG9pbnRlci1zaWduIC1Xbm8tZW1wdHktYm9keSAtV25vLXN0cmluZy1wbHVzLWludCAt V25vLXRhdXRvbG9naWNhbC1jb21wYXJlIC1Xbm8tdW51c2VkLXZhbHVlIC1Xbm8tcGFyZW50 aGVzZXMtZXF1YWxpdHkgLVduby11bnVzZWQtZnVuY3Rpb24gLVduby1jb252ZXJzaW9uICAt YyAvdXNyL3NyYy9jb250cmliL2JtYWtlL2xzdC5saWIvbHN0UHJldi5jDQpjYyAtTyAtcGlw ZSAtZyAtRE5PX1BXRF9PVkVSUklERSAtSS91c3Ivc3JjL3Vzci5iaW4vYm1ha2UgIC1EVVNF X01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURIQVZFX0NPTkZJR19IICAt RFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1EX1BBVEhfREVGU1lT UEFUSD1cIi4uLi9zaGFyZS9tazovdXNyL3NoYXJlL21rXCIgLUkuIC1JL3Vzci9zcmMvY29u dHJpYi9ibWFrZSAgLURNQUtFX05BVElWRSAgLXN0ZD1nbnU5OSAtUXVudXNlZC1hcmd1bWVu dHMgLWZzdGFjay1wcm90ZWN0b3IgLVdzeXN0ZW0taGVhZGVycyAtV2FsbCAtV25vLWZvcm1h dC15MmsgLVcgLVduby11bnVzZWQtcGFyYW1ldGVyIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdt aXNzaW5nLXByb3RvdHlwZXMgLVdwb2ludGVyLWFyaXRoIC1Xbm8tdW5pbml0aWFsaXplZCAt V25vLXBvaW50ZXItc2lnbiAtV25vLWVtcHR5LWJvZHkgLVduby1zdHJpbmctcGx1cy1pbnQg LVduby10YXV0b2xvZ2ljYWwtY29tcGFyZSAtV25vLXVudXNlZC12YWx1ZSAtV25vLXBhcmVu dGhlc2VzLWVxdWFsaXR5IC1Xbm8tdW51c2VkLWZ1bmN0aW9uIC1Xbm8tY29udmVyc2lvbiAg LWMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdFJlbW92ZS5jDQpjYyAtTyAt cGlwZSAtZyAtRE5PX1BXRF9PVkVSUklERSAtSS91c3Ivc3JjL3Vzci5iaW4vYm1ha2UgIC1E VVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURIQVZFX0NPTkZJR19I ICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1EX1BBVEhfREVG U1lTUEFUSD1cIi4uLi9zaGFyZS9tazovdXNyL3NoYXJlL21rXCIgLUkuIC1JL3Vzci9zcmMv Y29udHJpYi9ibWFrZSAgLURNQUtFX05BVElWRSAgLXN0ZD1nbnU5OSAtUXVudXNlZC1hcmd1 bWVudHMgLWZzdGFjay1wcm90ZWN0b3IgLVdzeXN0ZW0taGVhZGVycyAtV2FsbCAtV25vLWZv cm1hdC15MmsgLVcgLVduby11bnVzZWQtcGFyYW1ldGVyIC1Xc3RyaWN0LXByb3RvdHlwZXMg LVdtaXNzaW5nLXByb3RvdHlwZXMgLVdwb2ludGVyLWFyaXRoIC1Xbm8tdW5pbml0aWFsaXpl ZCAtV25vLXBvaW50ZXItc2lnbiAtV25vLWVtcHR5LWJvZHkgLVduby1zdHJpbmctcGx1cy1p bnQgLVduby10YXV0b2xvZ2ljYWwtY29tcGFyZSAtV25vLXVudXNlZC12YWx1ZSAtV25vLXBh cmVudGhlc2VzLWVxdWFsaXR5IC1Xbm8tdW51c2VkLWZ1bmN0aW9uIC1Xbm8tY29udmVyc2lv biAgLWMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdFJlcGxhY2UuYw0KY2Mg LU8gLXBpcGUgLWcgLUROT19QV0RfT1ZFUlJJREUgLUkvdXNyL3NyYy91c3IuYmluL2JtYWtl ICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1ESEFWRV9DT05G SUdfSCAgLURVU0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtRF9QQVRI X0RFRlNZU1BBVEg9XCIuLi4vc2hhcmUvbWs6L3Vzci9zaGFyZS9ta1wiIC1JLiAtSS91c3Iv c3JjL2NvbnRyaWIvYm1ha2UgIC1ETUFLRV9OQVRJVkUgIC1zdGQ9Z251OTkgLVF1bnVzZWQt YXJndW1lbnRzIC1mc3RhY2stcHJvdGVjdG9yIC1Xc3lzdGVtLWhlYWRlcnMgLVdhbGwgLVdu by1mb3JtYXQteTJrIC1XIC1Xbm8tdW51c2VkLXBhcmFtZXRlciAtV3N0cmljdC1wcm90b3R5 cGVzIC1XbWlzc2luZy1wcm90b3R5cGVzIC1XcG9pbnRlci1hcml0aCAtV25vLXVuaW5pdGlh bGl6ZWQgLVduby1wb2ludGVyLXNpZ24gLVduby1lbXB0eS1ib2R5IC1Xbm8tc3RyaW5nLXBs dXMtaW50IC1Xbm8tdGF1dG9sb2dpY2FsLWNvbXBhcmUgLVduby11bnVzZWQtdmFsdWUgLVdu by1wYXJlbnRoZXNlcy1lcXVhbGl0eSAtV25vLXVudXNlZC1mdW5jdGlvbiAtV25vLWNvbnZl cnNpb24gIC1jIC91c3Ivc3JjL2NvbnRyaWIvYm1ha2UvbHN0LmxpYi9sc3RTdWNjLmMNCmNj IC1PIC1waXBlIC1nIC1ETk9fUFdEX09WRVJSSURFIC1JL3Vzci9zcmMvdXNyLmJpbi9ibWFr ZSAgLURVU0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtREhBVkVfQ09O RklHX0ggIC1EVVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURfUEFU SF9ERUZTWVNQQVRIPVwiLi4uL3NoYXJlL21rOi91c3Ivc2hhcmUvbWtcIiAtSS4gLUkvdXNy L3NyYy9jb250cmliL2JtYWtlICAtRE1BS0VfTkFUSVZFICAtc3RkPWdudTk5IC1RdW51c2Vk LWFyZ3VtZW50cyAtZnN0YWNrLXByb3RlY3RvciAtV3N5c3RlbS1oZWFkZXJzIC1XYWxsIC1X bm8tZm9ybWF0LXkyayAtVyAtV25vLXVudXNlZC1wYXJhbWV0ZXIgLVdzdHJpY3QtcHJvdG90 eXBlcyAtV21pc3NpbmctcHJvdG90eXBlcyAtV3BvaW50ZXItYXJpdGggLVduby11bmluaXRp YWxpemVkIC1Xbm8tcG9pbnRlci1zaWduIC1Xbm8tZW1wdHktYm9keSAtV25vLXN0cmluZy1w bHVzLWludCAtV25vLXRhdXRvbG9naWNhbC1jb21wYXJlIC1Xbm8tdW51c2VkLXZhbHVlIC1X bm8tcGFyZW50aGVzZXMtZXF1YWxpdHkgLVduby11bnVzZWQtZnVuY3Rpb24gLVduby1jb252 ZXJzaW9uICAtYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL3N0cmVzZXAuYw0KY2MgLU8gLXBp cGUgLWcgLUROT19QV0RfT1ZFUlJJREUgLUkvdXNyL3NyYy91c3IuYmluL2JtYWtlICAtRFVT RV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1ESEFWRV9DT05GSUdfSCAg LURVU0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtRF9QQVRIX0RFRlNZ U1BBVEg9XCIuLi4vc2hhcmUvbWs6L3Vzci9zaGFyZS9ta1wiIC1JLiAtSS91c3Ivc3JjL2Nv bnRyaWIvYm1ha2UgIC1ETUFLRV9OQVRJVkUgIC1zdGQ9Z251OTkgLVF1bnVzZWQtYXJndW1l bnRzIC1mc3RhY2stcHJvdGVjdG9yIC1Xc3lzdGVtLWhlYWRlcnMgLVdhbGwgLVduby1mb3Jt YXQteTJrIC1XIC1Xbm8tdW51c2VkLXBhcmFtZXRlciAtV3N0cmljdC1wcm90b3R5cGVzIC1X bWlzc2luZy1wcm90b3R5cGVzIC1XcG9pbnRlci1hcml0aCAtV25vLXVuaW5pdGlhbGl6ZWQg LVduby1wb2ludGVyLXNpZ24gLVduby1lbXB0eS1ib2R5IC1Xbm8tc3RyaW5nLXBsdXMtaW50 IC1Xbm8tdGF1dG9sb2dpY2FsLWNvbXBhcmUgLVduby11bnVzZWQtdmFsdWUgLVduby1wYXJl bnRoZXNlcy1lcXVhbGl0eSAtV25vLXVudXNlZC1mdW5jdGlvbiAtV25vLWNvbnZlcnNpb24g ICAtc3RhdGljIC1vIG1ha2UgYXJjaC5vIGJ1Zi5vIGNvbXBhdC5vIGNvbmQubyBkaXIubyBm b3IubyBoYXNoLm8gam9iLm8gbWFpbi5vIG1ha2UubyBtYWtlX21hbGxvYy5vIG1ldGEubyBw YXJzZS5vIHN0ci5vIHN0cmxpc3QubyBzdWZmLm8gdGFyZy5vIHRyYWNlLm8gdXRpbC5vIHZh ci5vIGxzdEFwcGVuZC5vIGxzdEF0RW5kLm8gbHN0QXRGcm9udC5vIGxzdENsb3NlLm8gbHN0 Q29uY2F0Lm8gbHN0RGF0dW0ubyBsc3REZVF1ZXVlLm8gbHN0RGVzdHJveS5vIGxzdER1cGwu byBsc3RFblF1ZXVlLm8gbHN0RmluZC5vIGxzdEZpbmRGcm9tLm8gbHN0Rmlyc3QubyBsc3RG b3JFYWNoLm8gbHN0Rm9yRWFjaEZyb20ubyBsc3RJbml0Lm8gbHN0SW5zZXJ0Lm8gbHN0SXNB dEVuZC5vIGxzdElzRW1wdHkubyBsc3RMYXN0Lm8gbHN0TWVtYmVyLm8gbHN0TmV4dC5vIGxz dE9wZW4ubyBsc3RQcmV2Lm8gbHN0UmVtb3ZlLm8gbHN0UmVwbGFjZS5vIGxzdFN1Y2MubyBz dHJlc2VwLm8gDQpzaCAvdXNyL3NyYy90b29scy9pbnN0YWxsLnNoICAtbyByb290IC1nIHdo ZWVsIC1tIDU1NSAgIG1ha2UgL3Vzci9vYmovdXNyL3NyYy9tYWtlLmFtZDY0L2JtYWtlDQpj ZCAvdXNyL3NyYzsgUEFUSD0vc2JpbjovYmluOi91c3Ivc2JpbjovdXNyL2JpbiBgdGVzdCAt eCAvdXNyL29iai91c3Ivc3JjL21ha2UuYW1kNjQvYm1ha2UgJiYgZWNobyAvdXNyL29iai91 c3Ivc3JjL21ha2UuYW1kNjQvYm1ha2UgfHwgZWNobyBtYWtlYCAgLW0gL3Vzci9zcmMvc2hh cmUvbWsgLWYgTWFrZWZpbGUuaW5jMSBUQVJHRVQ9YW1kNjQgVEFSR0VUX0FSQ0g9YW1kNjQg YnVpbGR3b3JsZA0KdXNhZ2U6IGJtYWtlIFstQmVpa05ucXJzdFd3WF0gDQogICAgICAgICAg ICBbLUMgZGlyZWN0b3J5XSBbLUQgdmFyaWFibGVdIFstZCBmbGFnc10gWy1mIG1ha2VmaWxl XQ0KICAgICAgICAgICAgWy1JIGRpcmVjdG9yeV0gWy1KIHByaXZhdGVdIFstaiBtYXhfam9i c10gWy1tIGRpcmVjdG9yeV0gWy1UIGZpbGVdDQogICAgICAgICAgICBbLVYgdmFyaWFibGVd IFt2YXJpYWJsZT12YWx1ZV0gW3RhcmdldCAuLi5dDQoqKiogW2J1aWxkd29ybGRdIEVycm9y IGNvZGUgMg0KDQpTdG9wIGluIC91c3Ivc3JjLg== From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 15:35:46 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 989945A6 for ; Mon, 5 Aug 2013 15:35:46 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (mail.vlakno.cz [178.238.39.38]) by mx1.freebsd.org (Postfix) with ESMTP id 5EB5E2385 for ; Mon, 5 Aug 2013 15:35:46 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id 2799B1CC5653; Mon, 5 Aug 2013 17:25:56 +0200 (CEST) Date: Mon, 5 Aug 2013 17:25:56 +0200 From: Roman Divacky To: Alfred Perlstein Subject: Re: Linux epoll(7) patch Message-ID: <20130805152556.GA37810@freebsd.org> References: <51FF7211.6020909@rawbw.com> <51FFC31D.3080304@mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51FFC31D.3080304@mu.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Yuri , 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, 05 Aug 2013 15:35:46 -0000 On Mon, Aug 05, 2013 at 08:22:05AM -0700, Alfred Perlstein wrote: > On 8/5/13 2:36 AM, Yuri wrote: > > There is the patch, suggested by Roman Divacky, implementing Linux > > epoll(7) functionality: > > http://rys.vlakno.cz/~rdivacky/patches/linux_epoll.patch > > > > This patch was suggested 5 years ago and was discussed on emulation@: > > http://lists.freebsd.org/pipermail/freebsd-emulation/2008-March/004409.html > > > > http://lists.freebsd.org/pipermail/freebsd-emulation/2008-March/004428.html > > > > > > Discussion stalled back then, and epoll is still unimplemented. > > > > Anybody can identify any issues with this patch? > > Are there any alternatives? > > > > Yuri > The patch is small. I too am wondering why it's not committed, was > there any push back? iirc the main problem with the patch is that it doesnt work over fork, I never got to implement that feature. Nevertheless it looks like the patch is useful even without that feature so maybe it should just be commited? Roman From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 15:36:17 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0A93F6C2; Mon, 5 Aug 2013 15:36:17 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-vb0-x229.google.com (mail-vb0-x229.google.com [IPv6:2607:f8b0:400c:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ACCA42398; Mon, 5 Aug 2013 15:36:16 +0000 (UTC) Received: by mail-vb0-f41.google.com with SMTP id g17so2991652vbg.28 for ; Mon, 05 Aug 2013 08:36:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Pu9lXwdbMSUW5/41SaRQ9bIWbwl9SYWDfUlRx+cvXjQ=; b=m5QiGaAkcZkidpdl7pu2aYIu+Bhde8ymz1+MhStKoHKw1bnMjzdChBImKDlDZX3oIU JaZX2TcSd1ZoApkjOWR9gPuScveFfsxbtHrCE6IVk4Ypwo1OuHJB+BkRVsJWx8swBxMV mwTGHbcR8tzy9aQePKR0PIIW9UaDz3UJQaeej0avFValCPWKHfplnNry7UtZhZ3J3p3Y 2e3H3TyQzjhxVnIN3IZvEJL3QZp0g04Mmpp8oMrn4b9fgex8Ygmgbl2hG4Bba4ay+bjg f+numS0IypzgZys95UfWwJ4m21pX/7r4NpwnCntzONtDMLuE3ArvwzYi1yWVEA9Q2fjM E2YQ== MIME-Version: 1.0 X-Received: by 10.52.65.147 with SMTP id x19mr4999656vds.103.1375716975784; Mon, 05 Aug 2013 08:36:15 -0700 (PDT) Received: by 10.220.96.78 with HTTP; Mon, 5 Aug 2013 08:36:15 -0700 (PDT) In-Reply-To: <1375716638.21499.6061603.4C417842@webmail.messagingengine.com> References: <51FF7211.6020909@rawbw.com> <51FFC31D.3080304@mu.org> <1375716638.21499.6061603.4C417842@webmail.messagingengine.com> Date: Mon, 5 Aug 2013 11:36:15 -0400 Message-ID: Subject: Re: Linux epoll(7) patch From: "Sam Fourman Jr." To: Mark Felder Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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, 05 Aug 2013 15:36:17 -0000 > The glory days of the Linuxulator were around FreeBSD 6 when basically > everything ran and often it ran much faster. We could really use a > revival of this with the FreeBSD 10 release... > _______________________________________________ > 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" > epoll is needed to get the linux version of plex media server working in FreeNAS, however in the last month or so it looks as if a FreeBSD native app has been released also I believe Yuri is working on a Linuxulator refresh up to at least Fedora 19 -- Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 15:39:55 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 498C78C3; Mon, 5 Aug 2013 15:39:55 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AA3E223CC; Mon, 5 Aug 2013 15:39:54 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id m46so2616280wev.36 for ; Mon, 05 Aug 2013 08:39:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=kPQHJyY1zBpzSc5B5/welaPohIM2GZ98sKK++lyvDW4=; b=Pw0hkiKfo5PAxwjytDZKGCpbNMBi66piKXeUjn/nHP7glfxYscy74Ym04YDak1aEAp QbNe4/kIU5eas8oYhv2OipZ5/40vrm6XYPIs9naTmJ2ZzC8SI4zBIQt7L7zck1UKbO5b zNby7Y+vUSWlJpoKhp28aSzEFYauhJWfXBGX+AcPZ+KeK8rKaSTuE4j01Ms7Sq+1uOng gQZJ5eiYDQCeqjhEO5F5SPgA2sR/Omh6Tzm8yPoQ5fmOCH6T+Tg32SphebR9uj7wHqc2 wjLR3JmtWkClCRc85tU5oepC4bnk94ms8Q0VgoNWn/HFi1YrbGy6+9Ab2BEiZwXOZBWk 676A== X-Received: by 10.194.110.39 with SMTP id hx7mr13581146wjb.4.1375717192906; Mon, 05 Aug 2013 08:39:52 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id z2sm22254726wiv.11.2013.08.05.08.39.50 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 05 Aug 2013 08:39:51 -0700 (PDT) Date: Mon, 5 Aug 2013 17:39:46 +0200 From: Mateusz Guzik To: Roman Divacky Subject: Re: Linux epoll(7) patch Message-ID: <20130805153946.GA29300@dft-labs.eu> References: <51FF7211.6020909@rawbw.com> <51FFC31D.3080304@mu.org> <20130805152556.GA37810@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20130805152556.GA37810@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Yuri , Alfred Perlstein , 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, 05 Aug 2013 15:39:55 -0000 On Mon, Aug 05, 2013 at 05:25:56PM +0200, Roman Divacky wrote: > On Mon, Aug 05, 2013 at 08:22:05AM -0700, Alfred Perlstein wrote: > > On 8/5/13 2:36 AM, Yuri wrote: > > > There is the patch, suggested by Roman Divacky, implementing Linux > > > epoll(7) functionality: > > > http://rys.vlakno.cz/~rdivacky/patches/linux_epoll.patch > > > > > > This patch was suggested 5 years ago and was discussed on emulation@: > > > http://lists.freebsd.org/pipermail/freebsd-emulation/2008-March/004409.html > > > > > > http://lists.freebsd.org/pipermail/freebsd-emulation/2008-March/004428.html > > > > > > > > > Discussion stalled back then, and epoll is still unimplemented. > > > > > > Anybody can identify any issues with this patch? > > > Are there any alternatives? > > > > > > Yuri > > The patch is small. I too am wondering why it's not committed, was > > there any push back? > > iirc the main problem with the patch is that it doesnt work over fork, I never > got to implement that feature. > > Nevertheless it looks like the patch is useful even without that feature so > maybe it should just be commited? > What happens to fd after the fork? Is it closed or simply remains non-functional? If the former, I suggest the patch is altered to leave fd with badfdops in place so that epoll users get less surprised. -- Mateusz Guzik From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 15:46:07 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9FFCFAAA; Mon, 5 Aug 2013 15:46:07 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0ED8F240B; Mon, 5 Aug 2013 15:46:06 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id hr7so1688988wib.12 for ; Mon, 05 Aug 2013 08:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=wcEuz7SwM5lnp1ELEuS15xUD9fl379Cc+SC2aQRyM78=; b=tcOyfMPS041odEFpBwOXKVh3RL9uDtZGC5KYflLdbx/bEezHlUCNgeKvTJzAi6h/yy h1z44vSNFYQWO8N0LdNqaehfXX53/vS9Hf1Iy6c0PjQ7jgqLkv4I3g/f7VNbB1URoux+ EYL9yvIUL4baqHjIsHNW1JMToKPjz3wSZ6ybdL9DKKvYZczxCgzxmnS/7YYr+qirCXM+ wmxgPaEwr6VZMfBEOA5JcQXIygAi9rO7F+fdlsNiorXDQcykENFZ95xsZLZmM9NBNUFF Gez1mdGngJ8Mo83Jlxgbpy1TwAekc+enhL1c5seJVSsAMclieiARV09noAa1rGB4Drds p4CQ== MIME-Version: 1.0 X-Received: by 10.180.160.165 with SMTP id xl5mr7139867wib.46.1375717565346; Mon, 05 Aug 2013 08:46:05 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.116.136 with HTTP; Mon, 5 Aug 2013 08:46:05 -0700 (PDT) In-Reply-To: <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> Date: Mon, 5 Aug 2013 08:46:05 -0700 X-Google-Sender-Auth: LktrRb4KALl0kOzD1nz2ankEW3E Message-ID: Subject: Re: [net] protecting interfaces from races between control and data ? From: Adrian Chadd To: Bryan Venteicher Content-Type: text/plain; charset=ISO-8859-1 Cc: Luigi Rizzo , current@freebsd.org, net@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, 05 Aug 2013 15:46:07 -0000 On 5 August 2013 07:59, Bryan Venteicher wrote: > What I've done in my drivers is: > * Lock the core mutex > * Clear IFF_DRV_RUNNING > * Lock/unlock each queue's lock .. and I think that's the only sane way of doing it. I'm going to (soon) propose something similar for cxgbe/ixgbe as we use these NICs at work, then feed this experiment back into the network stack so we can have a unified way of doing this. You may also want to synchronize against the driver TX/RX/core locks and state when doing things like, say, halting DMA in preparation for multicast reprogramming on some hardware; or even doing a chip reset. I had to hand-roll this for ath(4) to make it completely correct - any kind of overlapping reset, reset during TX, reset during RX etc would cause all kinds of instability and random-crap-scribbled-everywhere issues. So yes, this is a larger scale issue that needs to be solved. -adrian From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 16:06:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B1E431A0 for ; Mon, 5 Aug 2013 16:06:07 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 85C5E2529 for ; Mon, 5 Aug 2013 16:06:07 +0000 (UTC) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 5B09321488; Mon, 5 Aug 2013 12:06:01 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute3.internal (MEProxy); Mon, 05 Aug 2013 12:06:02 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:cc:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=X8W2eV2+BFLNk0pTlaxPsn0R+l0=; b=oCr SpgbbfKYgrn5ts8X6AsTqUNr8ru+APt9vA1JYhzhXnZzbxyI/Hp2AADiXLoXGbnT Msq6Z5dMf8uUiMBzdBLbtDmSxc4gs6cKSgPEz5nNCUViHK9CvFZidBXsJfjWJ4dg H+0vo7Y2YJPLxkWuf0/0nNYcWjM2PXkL+a0pQpo4= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id B0309B02158; Mon, 5 Aug 2013 12:06:01 -0400 (EDT) Message-Id: <1375718761.4529.6100347.21E3CCBF@webmail.messagingengine.com> X-Sasl-Enc: X0vd3APpGuV1qF0xdpNG/UhBqekuR/CcIgqfChz9GAEL 1375718761 From: Mark Felder To: "Sam Fourman Jr." MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-2d520484 In-Reply-To: References: <51FF7211.6020909@rawbw.com> <51FFC31D.3080304@mu.org> <1375716638.21499.6061603.4C417842@webmail.messagingengine.com> Subject: Re: Linux epoll(7) patch Date: Mon, 05 Aug 2013 11:06:01 -0500 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, 05 Aug 2013 16:06:07 -0000 On Mon, Aug 5, 2013, at 10:36, Sam Fourman Jr. wrote: > > epoll is needed to get the linux version of plex media server working in > FreeNAS, > however in the last month or so it looks as if a FreeBSD native app has > been released > I'm working closely with Elan (head of Plex) and expect to be committing a port to the tree soon. You can test the port here: https://github.com/felderado/plexmediaserver_port/ I believe the FreeBSD version at this time lacks the ability to auto-detect filesystem changes so manual scanning or notification from your download software will be required. Sickbeard and Couch Potato can do this, for example. From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 16:15:03 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5B4354AF; Mon, 5 Aug 2013 16:15:03 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7591525C2; Mon, 5 Aug 2013 16:15:02 +0000 (UTC) Received: by mail-la0-f42.google.com with SMTP id mf11so2250829lab.15 for ; Mon, 05 Aug 2013 09:15:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=IJksw33/x2N791vbphuUxZFdCSsyAGGfakfCm7Zm1ZM=; b=G5yyLzkkK27DPQds8L9nO+pLwGpJ2CvPfINDIwkoazj8QaoUeeO6ji2TZII5VyxGPO 00O3NKADwIAexY7Q1nhCLiDm3fRycEbDF1UznUVCF6JV9PQA79GiHFglQ3UiDA7jeS1H xD9EoaA/B+iCEK4HXm8QwGNUPJKfDkCasjEgaxQQmRrq8lnvDNmQCwGjSAW7+xJFIRAF kle3tiPyIV2EKjdWIbwVit6uy/x3vaoO3lv12VcCj0ERW5yA0KHN3SaB0UeAnq3A+vk/ J7XCZmkyGNfVpfCNVuXm1WoSU951o9OaG7Qe/LvRxK00EVFkHSupg5KpRTh+NtYMszCM otyg== MIME-Version: 1.0 X-Received: by 10.152.87.42 with SMTP id u10mr1630303laz.43.1375719300456; Mon, 05 Aug 2013 09:15:00 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.200.165 with HTTP; Mon, 5 Aug 2013 09:15:00 -0700 (PDT) In-Reply-To: References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> Date: Mon, 5 Aug 2013 18:15:00 +0200 X-Google-Sender-Auth: k8hbls4GhIGp5BnB4loRnZejBkY Message-ID: Subject: Re: [net] protecting interfaces from races between control and data ? From: Luigi Rizzo To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Giuseppe Lettieri , Bryan Venteicher , current@freebsd.org, net@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, 05 Aug 2013 16:15:03 -0000 On Mon, Aug 5, 2013 at 5:46 PM, Adrian Chadd wrote: > On 5 August 2013 07:59, Bryan Venteicher > wrote: > > > What I've done in my drivers is: > > * Lock the core mutex > > * Clear IFF_DRV_RUNNING > > * Lock/unlock each queue's lock > > .. and I think that's the only sane way of doing it. > yeah, this was also the solution we had in mind, i was surprised not find this pattern in the drivers i have looked at. Also there are drivers (chelsio ?) which do not seem to have locks on the receive interrupt handlers ? Does anyone know how linux copes with the same problem ? They seem to have an rtnl_lock() which is a global lock for all configuration of netdevices (would replace our per-interface 'core lock' above), but i am totally unclear on how individual tx threads and interrupt handlers acknowledge that they have read the change in status. cheers luigi From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 16:26:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0D83893B for ; Mon, 5 Aug 2013 16:26:06 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward5l.mail.yandex.net (forward5l.mail.yandex.net [IPv6:2a02:6b8:0:1819::5]) by mx1.freebsd.org (Postfix) with ESMTP id C42AC2672 for ; Mon, 5 Aug 2013 16:26:05 +0000 (UTC) Received: from smtp13.mail.yandex.net (smtp13.mail.yandex.net [95.108.130.68]) by forward5l.mail.yandex.net (Yandex) with ESMTP id C596BC407C4 for ; Mon, 5 Aug 2013 20:26:03 +0400 (MSK) Received: from smtp13.mail.yandex.net (localhost [127.0.0.1]) by smtp13.mail.yandex.net (Yandex) with ESMTP id 2F022E40556 for ; Mon, 5 Aug 2013 20:26:03 +0400 (MSK) Received: from 87.249.28.58.tel.ru (87.249.28.58.tel.ru [87.249.28.58]) by smtp13.mail.yandex.net (nwsmtp/Yandex) with ESMTP id Z3gThrPA3D-Q2EqUUpN; Mon, 5 Aug 2013 20:26:02 +0400 Message-ID: <51FFD21A.3050602@passap.ru> Date: Mon, 05 Aug 2013 20:26:02 +0400 From: Boris Samorodov User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130707 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: "make buildworld" fails References: <20991.50656.38794.827648@jerusalem.litteratus.org> In-Reply-To: <20991.50656.38794.827648@jerusalem.litteratus.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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, 05 Aug 2013 16:26:06 -0000 05.08.2013 19:33, Robert Huff пишет: > cd /usr/src; PATH=/sbin:/bin:/usr/sbin:/usr/bin `test -x /usr/obj/usr/src/make.amd64/bmake && echo /usr/obj/usr/src/make.amd64/bmake || echo make` -m /usr/src/share/mk -f Makefile.inc1 TARGET=amd64 TARGET_ARCH=amd64 buildworld > usage: bmake [-BeikNnqrstWwX] > [-C directory] [-D variable] [-d flags] [-f makefile] > [-I directory] [-J private] [-j max_jobs] [-m directory] [-T file] > [-V variable] [variable=value] [target ...] > *** [buildworld] Error code 2 This note from /usr/src/UPDATING may be relevant: ----- 20130613: Some people report the following error after the switch to bmake: make: illegal option -- J usage: make [-BPSXeiknpqrstv] [-C directory] [-D variable] ... *** [buildworld] Error code 2 this likely due to an old instance of make in ${MAKEPATH} (${MAKEOBJDIRPREFIX}${.CURDIR}/make.${MACHINE}) which src/Makefile will use that blindly, if it exists, so if you see the above error: rm -rf `make -V MAKEPATH` should resolve it. ----- -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 16:45:42 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E9271E2E; Mon, 5 Aug 2013 16:45:42 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-bk0-x234.google.com (mail-bk0-x234.google.com [IPv6:2a00:1450:4008:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4B98D275B; Mon, 5 Aug 2013 16:45:42 +0000 (UTC) Received: by mail-bk0-f52.google.com with SMTP id e11so1046440bkh.39 for ; Mon, 05 Aug 2013 09:45:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; bh=76zv+e1Dv2GI/7SduBrzsX8Xmr6QHbaR3iBuoL7UjxA=; b=jiEcTeFGN6I5lOZulty95x3pSRJtS6dF5rd2v9mi6d7EM9tCJttdNTc8/n+ufJFJoW xFxtzwrv7CESPoTw/+NDwum4FoG6oY2TPPK7DDRD2eRzzJ8nnwQznK80+joswLTANj2b iEH5EnexsId15iyjygfrSornqREzGjy6Y+c8keOrHvW2k4PnqtkROUnM+10L/0+8QxS0 z3rRQxqaB6egC3vpVUSNJ15YQ8GyVKxFQg0v9ELiAfCJW1+/q+9e6eCTV/Ul/JQi8Ado WB/0frIfiqJoFnrpHyau+cUKc1u9uS63IkWyjG9i9723O4XJo4Si9AsoX/uYP424wBno WXSw== X-Received: by 10.205.47.73 with SMTP id ur9mr1095210bkb.156.1375721139617; Mon, 05 Aug 2013 09:45:39 -0700 (PDT) Received: from ernst.home (p4FCA7969.dip0.t-ipconnect.de. [79.202.121.105]) by mx.google.com with ESMTPSA id if11sm5172301bkc.15.2013.08.05.09.45.37 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 05 Aug 2013 09:45:38 -0700 (PDT) Date: Mon, 5 Aug 2013 18:45:36 +0200 From: Gary Jennejohn To: "Sam Fourman Jr." Subject: Re: Kernel Panic on FreeBSD 10.0-CURRENT #1 r253918 Message-ID: <20130805184536.33236d7b@ernst.home> In-Reply-To: References: X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.17; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Craig Rodrigues , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 16:45:43 -0000 On Sun, 4 Aug 2013 18:59:56 -0400 "Sam Fourman Jr." wrote: > On Sun, Aug 4, 2013 at 6:52 PM, Craig Rodrigues wrote: > > > On Sun, Aug 4, 2013 at 12:33 PM, Sam Fourman Jr. wrote: > > > >> hello list, > >> > >> could someone help me figure out why this machine kernel paniced? > >> I have a full crashdump file if needed, > >> this machine is configured as a Firewall and wifi hostap running pf in a > >> small office > >> > >> > >> here is a mailing list post to someone that had a similar problem a few > >> years back > >> http://lists.freebsd.org/pipermail/freebsd-bugs/2011-April/043985.html > >> > >> a backtrace, full dmesg, and kernel config are below > >> > >> > >> kgdb /boot/kernel/kernel /var/crash/vmcore.0 > >> #4 0xffffffff80bd6027 in trap_pfault (frame=0x0, usermode= >> optimized > >> out>) at /usr/src/sys/amd64/amd64/trap.c:699 > >> #5 0xffffffff80bd5876 in trap (frame=0xffffff80002787c0) at > >> /usr/src/sys/amd64/amd64/trap.c:463 > >> #6 0xffffffff80bc06b2 in calltrap () at > >> /usr/src/sys/amd64/amd64/exception.S:232 > >> #7 0xffffffff809937a8 in in6_tmpaddrtimer (arg=0xfffffe00170fc0b6) at > >> /usr/src/sys/netinet6/in6_ifattach.c:935 > >> #8 0xffffffff8085140a in softclock_call_cc (c=0xffffffff81325210, > >> cc=0xffffffff8131c700, direct=0) at /usr/src/sys/kern/kern_timeout.c:674 > >> #9 0xffffffff80851704 in softclock (arg=) at > >> /usr/src/sys/kern/kern_timeout.c:802 > >> #10 0xffffffff80815dc3 in intr_event_execute_handlers (p= >> out>, ie=0xfffffe0014ab3400) at /usr/src/sys/kern/kern_intr.c:1263 > >> #11 0xffffffff80816716 in ithread_loop (arg=0xfffffe0014a896e0) at > >> /usr/src/sys/kern/kern_intr.c:1276 > >> #12 0xffffffff80813b31 in fork_exit (callout=0xffffffff80816680 > >> , arg=0xfffffe0014a896e0, frame=0xffffff8000278a40) at > >> /usr/src/sys/kern/kern_fork.c:991 > >> #13 0xffffffff80bc0bee in fork_trampoline () at > >> /usr/src/sys/amd64/amd64/exception.S:606 > >> #14 0x0000000000000000 in ?? () > >> Current language: auto; currently minimal > >> (kgdb) > >> > >> > >> > > > > You have VIMAGE enabled in your kernel config. I have debugged a few of > > these VIMAGE problems > > before. > > > > Can you do the following for me: > > > > > Craig, > > Thank you for getting back to me, I will get to work on this right away and > get you what you need. > but are we CERTAIN this panic could be from VIMAGE? I totally thought I had > a # infront of that line when I built this kernel... > > if you notice I did post the kernel config at the bottom of that email, and > VIMAGE is NOT included... > but maybe I did something wrong and somehow built VIMAGE in anyway.. > > is there some sort of command I can run to ask the system if it does indeed > have VIMAGE? > kldstat -v maybe? Seems to list every module in the kernel. I don't have VIMAGE enabled so can't say whether it will really appear. -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 17:13:06 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3EC73660; Mon, 5 Aug 2013 17:13:06 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0419B28FB; Mon, 5 Aug 2013 17:13:05 +0000 (UTC) Received: by mail-pd0-f173.google.com with SMTP id p11so3487338pdj.32 for ; Mon, 05 Aug 2013 10:13:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=A6dgrK6zlFFan2PwgEg8Zx3im9qX+MeYm0qKZqwqixM=; b=l+uJEts6N3ktFpMtF3evI3UU3SelqeTx70qqu2lEXYF6JS6JeSKycuiSQ1D1JVK2SE QWGYv/n2uVjEas3BSdJ6wQ+fGJCAM/E+Z5ZOkXo+0gc4u+A1JMHgzYA0o2lG4P+T/2cJ vl8owDLacwtCu5Y8eh9Iz7AkYpwji7bUGFm+GGI7GJv7iPzsrZLJvW6FS7Z2Xo6E1yPx IDFU3/DJJsVcCm1s9nnh3fkfg6IRtTbm3vjJPLN1T6QGtzdA0M//NoSdU+2f5LeDRjvU zH3yyIJ4Yod+8HTibQ7a3idjvxClzp6njBiZ+nMwXuyTWhboHCSSypvxCZDcYywgs7Wu 4bYg== X-Received: by 10.68.169.97 with SMTP id ad1mr23138366pbc.84.1375722785646; Mon, 05 Aug 2013 10:13:05 -0700 (PDT) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPSA id qc5sm99574pbc.31.2013.08.05.10.13.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 Aug 2013 10:13:04 -0700 (PDT) Sender: Navdeep Parhar Message-ID: <51FFDD1E.1000206@FreeBSD.org> Date: Mon, 05 Aug 2013 10:13:02 -0700 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130731 Thunderbird/17.0.7 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: [net] protecting interfaces from races between control and data ? References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , net@freebsd.org, Bryan Venteicher , Giuseppe Lettieri , 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, 05 Aug 2013 17:13:06 -0000 On 08/05/13 09:15, Luigi Rizzo wrote: > On Mon, Aug 5, 2013 at 5:46 PM, Adrian Chadd wrote: > >> On 5 August 2013 07:59, Bryan Venteicher >> wrote: >> >>> What I've done in my drivers is: >>> * Lock the core mutex >>> * Clear IFF_DRV_RUNNING >>> * Lock/unlock each queue's lock >> >> .. and I think that's the only sane way of doing it. >> > > yeah, this was also the solution we had in mind, i was surprised > not find this pattern in the drivers i have looked at. > > Also there are drivers (chelsio ?) which do not seem to have locks on the > receive interrupt handlers ? This is correct. cxgbe(4) does not have any locks on rx, just a "state" for each rx queue that's maintained with atomic ops. Regards, Navdeep > > Does anyone know how linux copes with the same problem ? > > They seem to have an rtnl_lock() which is a global lock for all > configuration > of netdevices (would replace our per-interface 'core lock' above), > but i am totally unclear on how individual tx threads and interrupt handlers > acknowledge that they have read the change in status. > > cheers > luigi > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 17:17:30 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 48085886; Mon, 5 Aug 2013 17:17:30 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 81BD7295A; Mon, 5 Aug 2013 17:17:29 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id p58so2687490wes.40 for ; Mon, 05 Aug 2013 10:17:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=53AuICVCdcZlIghBYscnVB5whDr/1xVLfYIPIe4O16U=; b=h/gmYHTWNFnwUvRBYGPA6SDt4GD2n/jo+fzv4NUxKgnwpxKInBTDfuSRWJ/dfZfj10 2l/nySiD+H1tqhMll727a2vf9LChWGUzma5UVnEBmWCqdsxKqPWR8TFL1aNWHmJQ/TlH CiHBER8erGa1RRj97541I6dHet1Ohfai0+0Yi51Qr6kbQdN0iIs9DGKDKXcjrDHGo/O3 8RmnABsBelJw8lgnU8n+y2SBNcziTuzwnnVqDwDIF/FTxUEht+ylabFsLKVY2UbSLbHs 4AG7njqS8+4BXPzvqvwVKoey9fN4YSG42NBJ2/mx6DHyaDKcS60l30HnndMGtAors8S1 hjMw== MIME-Version: 1.0 X-Received: by 10.180.185.148 with SMTP id fc20mr7612847wic.0.1375723047877; Mon, 05 Aug 2013 10:17:27 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.116.136 with HTTP; Mon, 5 Aug 2013 10:17:27 -0700 (PDT) In-Reply-To: <51FFDD1E.1000206@FreeBSD.org> References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> Date: Mon, 5 Aug 2013 10:17:27 -0700 X-Google-Sender-Auth: xvHHdnO8uRlzvUdaJTkNkn7V8Fo Message-ID: Subject: Re: [net] protecting interfaces from races between control and data ? From: Adrian Chadd To: Navdeep Parhar Content-Type: text/plain; charset=ISO-8859-1 Cc: Bryan Venteicher , Giuseppe Lettieri , Luigi Rizzo , current@freebsd.org, net@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, 05 Aug 2013 17:17:30 -0000 I'm travelling back to San Jose today; poke me tomorrow and I'll brain dump what I did in ath(4) and the lessons learnt. The TL;DR version - you don't want to grab an extra lock in the read/write paths as that slows things down. Reuse the same per-queue TX/RX lock and have: * a reset flag that is set when something is resetting; that says to the queue "don't bother processing anything, just dive out"; * 'i am doing Tx / Rx' flags per queue that is set at the start of TX/RX servicing and finishes at the end; that way the reset code knows if there's something pending; * have the reset path grab each lock, set the 'reset' flag on each, then walk each queue again and make sure they're all marked as 'not doing TX/RX'. At that point the reset can occur, then the flag cna be cleared, then TX/RX can resume. -adrian On 5 August 2013 10:13, Navdeep Parhar wrote: > On 08/05/13 09:15, Luigi Rizzo wrote: >> On Mon, Aug 5, 2013 at 5:46 PM, Adrian Chadd wrote: >> >>> On 5 August 2013 07:59, Bryan Venteicher >>> wrote: >>> >>>> What I've done in my drivers is: >>>> * Lock the core mutex >>>> * Clear IFF_DRV_RUNNING >>>> * Lock/unlock each queue's lock >>> >>> .. and I think that's the only sane way of doing it. >>> >> >> yeah, this was also the solution we had in mind, i was surprised >> not find this pattern in the drivers i have looked at. >> >> Also there are drivers (chelsio ?) which do not seem to have locks on the >> receive interrupt handlers ? > > This is correct. cxgbe(4) does not have any locks on rx, just a "state" > for each rx queue that's maintained with atomic ops. > > Regards, > Navdeep > > >> >> Does anyone know how linux copes with the same problem ? >> >> They seem to have an rtnl_lock() which is a global lock for all >> configuration >> of netdevices (would replace our per-interface 'core lock' above), >> but i am totally unclear on how individual tx threads and interrupt handlers >> acknowledge that they have read the change in status. >> >> cheers >> luigi >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 17:20:15 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6D08DA6B; Mon, 5 Aug 2013 17:20:15 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A607C2997; Mon, 5 Aug 2013 17:20:14 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id j17so1795681wiw.17 for ; Mon, 05 Aug 2013 10:20:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Z0qqlvZSbYYLwmIdMg8zl/qe3mxUzG93G0K4/kOzScY=; b=ckD4n2U9qLwrdUtA9Ciz+MfDiedcLFccJcofzCt8GGnwvw/aTSitKmig59gXpJGGUu WxJYNDsI1vcXuQOq58YoRc1uls+mh8fIMsfb6xy7fbFN0Ok+fyDXlEnirrNIzmOEQdYc 24VZ8WaChaHPp+3q3lLaGNP5d64s18wOFlkcjf7AyUsc+3uda9V/pJSwgnB/0vR/2kSy PQc9YRpdJMG74phBDqk+5BT2v1F+OOQeadVg08+bGfHH1jwefqGmobiHvOQZg65IoE3/ 8GWRIkXbhOtl94uPNFJz0/KmQHb6ljoKTsUMJ5qmu2zZOfIN/jqtm+4op11Wluddb99s RRew== MIME-Version: 1.0 X-Received: by 10.194.201.202 with SMTP id kc10mr14057689wjc.1.1375723212843; Mon, 05 Aug 2013 10:20:12 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.116.136 with HTTP; Mon, 5 Aug 2013 10:20:12 -0700 (PDT) In-Reply-To: References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> Date: Mon, 5 Aug 2013 10:20:12 -0700 X-Google-Sender-Auth: 2-qcTBCZjB_LRkVkLpTgqOsD12Q Message-ID: Subject: Re: [net] protecting interfaces from races between control and data ? From: Adrian Chadd To: Navdeep Parhar Content-Type: text/plain; charset=ISO-8859-1 Cc: Bryan Venteicher , Giuseppe Lettieri , Luigi Rizzo , current@freebsd.org, net@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, 05 Aug 2013 17:20:15 -0000 .. and I bet it's not a design pattern, and this is total conjecture on my part: * the original drivers weren't SMP safe; * noone really sat down and figured out how to correctly synchronise all of this stuff; * people did the minimum amount of work to keep the driver from immediately crashing, but didn't really think things through at a larger scale. Almost every driver is this way Luigi. :-) -adrian From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 17:29:25 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DA3C5DAD for ; Mon, 5 Aug 2013 17:29:25 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5C5112A2C for ; Mon, 5 Aug 2013 17:29:25 +0000 (UTC) Received: by mail-la0-f51.google.com with SMTP id fp13so2243912lab.24 for ; Mon, 05 Aug 2013 10:29:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=xHhwbsK+9Y/i2l1e93JfA3pmsqc+hc0RPhRTPjHm110=; b=L57sT/u0b+XpJWBfz5wp/FZNj0fzfs2bqKCMK3KiY+vgqaqzEfUSP+OeFBTUfj8/li AQ4xp7FF92PL1tkJIsNAkE278b6w0TrwH/6O1aWkE7Nz33Wgn5AB0lcvyGqlLFX6p/Gj BoqttomWYWOxp0XpBQabHAoH0q1Iz/rdZeaMMjuJQTMDrwqhpEc7YGsXkKUriiW4tktB WuuvCWWGq2RfuluKouakCSqco8xeti0ygH8LPUYBYcSmBEfzZIk4FhxPEpX3v8otgARH LTBV2G/n0U7fJLQteJQdWJtwvYKMlkHAgDnY2/3EJFjzjEb5pcZUQfIccas5TwuF/cV8 M9ig== MIME-Version: 1.0 X-Received: by 10.112.156.133 with SMTP id we5mr2565398lbb.81.1375723763192; Mon, 05 Aug 2013 10:29:23 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.22.100 with HTTP; Mon, 5 Aug 2013 10:29:23 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 Aug 2013 10:29:23 -0700 X-Google-Sender-Auth: upDLD_oWmZEgRaJCk36z0MG59zg Message-ID: Subject: Re: Kernel Panic on FreeBSD 10.0-CURRENT #1 r253918 From: Craig Rodrigues To: "Sam Fourman Jr." Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current 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, 05 Aug 2013 17:29:26 -0000 On Sun, Aug 4, 2013 at 3:59 PM, Sam Fourman Jr. wrote: > > > > Craig, > > Thank you for getting back to me, I will get to work on this right away > and get you what you need. > but are we CERTAIN this panic could be from VIMAGE? I totally thought I > had a # infront of that line when I built this kernel... > > if you notice I did post the kernel config at the bottom of that email, > and VIMAGE is NOT included... > but maybe I did something wrong and somehow built VIMAGE in anyway.. > > is there some sort of command I can run to ask the system if it does > indeed have VIMAGE? > On the booted an running system, if you type: sysctl kern.conftxt that will display the actual kernel config options used to build the running kernel. This is handy because once or twice when doing development, I edited a kernel config file and forgot to rebuild the kernel before installing it. It would still be useful if you could run through those steps which I gave you and provide the debugging output, just to double check. -- Craig From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 17:36:25 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5F3944B1; Mon, 5 Aug 2013 17:36:25 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 45D9E2AB1; Mon, 5 Aug 2013 17:36:24 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id ec20so2311991lab.28 for ; Mon, 05 Aug 2013 10:36:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=2rzT9Cecv/nAAHnMXSQ2bQxtOaPUdNq7iwzZrH2pVpQ=; b=l76mt1SMaPw/l3wWNi95/3Lt+IP+/kK07ID/9fhMJhC1ldi+EyzS2B7daf3tpDff+b q8zU8u957hmw/ryINMzjhXDB9men0kpa+vZSVDsCv7S4PdUPXg0ek6XcnzEykiFCcQB9 RQ8sr2tGfNJR65BgjPfQ0qWGUmNrp2J/vwESarQkhmLlAdgeS/rJhdeEhKqR00ykODEL pmp8moaoUct4+zFpmHe24hHOPwZakmxkSgEx4f+g51B1IqjKHdHNOSoEikB9MZCp0bHl VcyOhl75aAp+3DUaMbGfILQRb1imbvn5uOzJk64RK0WY6C2D4nMX2fWbNvzfap0ak/Mn yXcw== MIME-Version: 1.0 X-Received: by 10.112.11.20 with SMTP id m20mr1297788lbb.56.1375724182270; Mon, 05 Aug 2013 10:36:22 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.200.165 with HTTP; Mon, 5 Aug 2013 10:36:22 -0700 (PDT) In-Reply-To: References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> Date: Mon, 5 Aug 2013 19:36:22 +0200 X-Google-Sender-Auth: bRXHtflqCqaEThiVs5xN7NeSKLw Message-ID: Subject: Re: [net] protecting interfaces from races between control and data ? From: Luigi Rizzo To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Giuseppe Lettieri , net@freebsd.org, Bryan Venteicher , Navdeep Parhar , 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, 05 Aug 2013 17:36:25 -0000 On Mon, Aug 5, 2013 at 7:17 PM, Adrian Chadd wrote: > I'm travelling back to San Jose today; poke me tomorrow and I'll brain > dump what I did in ath(4) and the lessons learnt. > > The TL;DR version - you don't want to grab an extra lock in the > read/write paths as that slows things down. Reuse the same per-queue > TX/RX lock and have: > > * a reset flag that is set when something is resetting; that says to > the queue "don't bother processing anything, just dive out"; > * 'i am doing Tx / Rx' flags per queue that is set at the start of > TX/RX servicing and finishes at the end; that way the reset code knows > if there's something pending; > * have the reset path grab each lock, set the 'reset' flag on each, > then walk each queue again and make sure they're all marked as 'not > doing TX/RX'. At that point the reset can occur, then the flag cna be > cleared, then TX/RX can resume. > so this is slightly different from what Bryan suggested (and you endorsed) before, as in that case there was a single 'reset' flag IFF_DRV_RUNNING protected by the 'core' lock, then a nested round on all tx and rx locks to make sure that all customers have seen it. In both cases the tx and rx paths only need the per-queue lock. As i see it, having a per-queue reset flag removes the need for nesting core + queue locks, but since this is only in the control path perhaps it is not a big deal (and is better to have a single place to look at to tell whether or not we should bail out). cheers luigi From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 17:32:12 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 35332251 for ; Mon, 5 Aug 2013 17:32:12 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm13.bullet.mail.ne1.yahoo.com (nm13.bullet.mail.ne1.yahoo.com [98.138.90.76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D9AA62A84 for ; Mon, 5 Aug 2013 17:32:11 +0000 (UTC) Received: from [98.138.90.56] by nm13.bullet.mail.ne1.yahoo.com with NNFMP; 05 Aug 2013 17:32:04 -0000 Received: from [98.138.226.127] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 05 Aug 2013 17:32:04 -0000 Received: from [127.0.0.1] by smtp206.mail.ne1.yahoo.com with NNFMP; 05 Aug 2013 17:32:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1375723924; bh=YiS4NvFfaKQ8oewMV8XxgvkG12NOLehq+k67gYJZaok=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=bszIC1LJKRZMcjmLLa4+S54WpbnnkBNUQgSZuR5vRjBm+09N4HA8e2LDABIsUvDGTlqSIjWOMdT+9TDKzfe3kV1oS1LzoM8Piy3iMmmeU1I0GjHGd+XGp6D15yyneKn1AzCP9W79zwFj6N4GJw15gXUxKO9rjgKLW9qMq1NBvkM= X-Yahoo-Newman-Id: 697595.10846.bm@smtp206.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: qJrqZAkVM1n1eOIWn9ZHv7Bd1ajC776U11nuLqzRMtf.vl0 trVo7Gmmdr_AtuZsuYUYtGO69JamoOQkDHdXKUzccGSeotnZzCQrIxarpj3z jVm8NU0bHmCgTeKSEgv3uUFFH5.JYuuncnwWjTpDuBblyroyTnBwapUa8v_b q5GYrd6eYcMNKt1ZdWkTkOlYslg7olzBsUl1AOJJ7_igPT.wf33mILokhhDh S2nc.jmTYF0ug3rR9Tzmd0MEVH5PM8Yi9hqGzQkTp9gpTjxwvqqKxCzYt0LZ UPWlGCLFyVC33JJsA5_xIJ0rPgUCbaEx2owVV7uS6hNbDbYcINMeMllIhA4m y4yP9joYI5yjoxNE5omceTcUHDlmC4CYQJoBf.ZQEbkvtOc3wH7KRnY.K0Wp ko.15VteDiPGq.kiSmrdrswrVeJzLhJHUU2NpS1RlPfePFtxRlkK7T1KFEZO 4I.gcYBqa5BOlMSC0J30xF4Rah93NgiBAxza_ZxFkjz0byrvNfC8TRHUnzze dqpHcDL3bk0Y5O28ihS7m4z05jZTE6Qoswzzas3K0BIxE5..DyWsdnr9MfA- - X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- X-Rocket-Received: from lgmc-adee.corp.netflix.com (scott4long@69.53.237.126 with ) by smtp206.mail.ne1.yahoo.com with SMTP; 05 Aug 2013 10:32:04 -0700 PDT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: [net] protecting interfaces from races between control and data ? From: Scott Long In-Reply-To: Date: Mon, 5 Aug 2013 11:32:02 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <195AEBBF-4297-4570-9D38-954FEC8D08DB@yahoo.com> References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> To: Adrian Chadd X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Mon, 05 Aug 2013 17:46:39 +0000 Cc: current@freebsd.org, Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri , Luigi Rizzo 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, 05 Aug 2013 17:32:12 -0000 On Aug 5, 2013, at 11:20 AM, Adrian Chadd wrote: > .. and I bet it's not a design pattern, and this is total conjecture = on my part: >=20 > * the original drivers weren't SMP safe; > * noone really sat down and figured out how to correctly synchronise > all of this stuff; > * people did the minimum amount of work to keep the driver from > immediately crashing, but didn't really think things through at a > larger scale. >=20 > Almost every driver is this way Luigi. :-) >=20 >=20 Yes, but let me expand. The original work to make NIC drivers SMP = focused around just putting everything under 1 lock. The lock was acquired in if_start and held through the transmission of the packet, it was held in if_ioctl all the way through whatever action was taken, and it was held = in the interrupt handler over all of the RX and TX-complete processing. = This worked fine up until the RX path called if_input() with the netisr path = set for direct dispatch. In this mode, the code could flow up the stack and then immediately back down into the if_start handler for the driver, where it would try to acquire the same lock again. Also, it meant that forwarding packets between to interfaces would have the lock from the RX context of one interface held into the TX context of the other = interface. Obviously, this was a big mess, so the "solution" was to just drop the lock around the call to if_input(). No consideration was made for = driver state that might change during the lock release, nor was any = consideration made for the performance impact of dropping the lock on every packet and then having to contend with top-half TX threads to pick it back up. But this became the quick-fix pattern. As for the original question of why the RX path can operate unlocked, = it's fairly easy. The RX machinery of most NICs is fairly separate from the = TX machinery, so little synchronization is needed. When there's a state = change in the driver, in terms of an interface going down, a queue size = changing, or the driver being unloaded, it's up to the driver to pause and drain = the RX processing prior to this state change. It worked well when I did it = in if_em, and it appears to work well with cxgbe. Scott From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 17:49:16 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6C19BC05; Mon, 5 Aug 2013 17:49:16 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DEC7B2B89; Mon, 5 Aug 2013 17:49:15 +0000 (UTC) Received: by mail-ve0-f172.google.com with SMTP id oz10so3461306veb.17 for ; Mon, 05 Aug 2013 10:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=D2+WuzNylDlrVMC06bwGlyCSnDekeP0XfKz+Pa93Yl4=; b=nIFFGrcckToaxZY3qQFYcX4tffziKnp2PPzwie3r+uzqDQFlQ44uuXcxFoqe9txZsg thCq0HR83GikytJ596Q1wK8GHvHTZ9ON2M+X06z3XDs//PcyMB+lBNcBoGuzngZP/6QL GWrYotUgeuCoP3nYrNMAZqDvWez+hP6Hr/Pphb85Hpl5GEvK7u8q5NtfD1s9/eoiSTiR M09l/k5XYV1Zkl0uuqrguhhtGBUIaqUISYGJDBkmLdggX17oIHqCgdQYLWTCobA4L7Uy WfJYcyXvHALgqERdUaw4ocO7TFvawJ8kEr4HuiTzAlEaYsMPaoq4XVCfU5iXYTIFW+kT 2DMg== MIME-Version: 1.0 X-Received: by 10.52.117.174 with SMTP id kf14mr5128392vdb.26.1375724955058; Mon, 05 Aug 2013 10:49:15 -0700 (PDT) Received: by 10.220.159.141 with HTTP; Mon, 5 Aug 2013 10:49:14 -0700 (PDT) In-Reply-To: References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> Date: Mon, 5 Aug 2013 10:49:14 -0700 Message-ID: Subject: Re: [net] protecting interfaces from races between control and data ? From: Jack Vogel To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Adrian Chadd , FreeBSD current mailing list , Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri 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, 05 Aug 2013 17:49:16 -0000 Sigh, this ends up being ugly I'm afraid. I need some time to look at code and think about it. Jack On Mon, Aug 5, 2013 at 10:36 AM, Luigi Rizzo wrote: > On Mon, Aug 5, 2013 at 7:17 PM, Adrian Chadd wrote: > > > I'm travelling back to San Jose today; poke me tomorrow and I'll brain > > dump what I did in ath(4) and the lessons learnt. > > > > The TL;DR version - you don't want to grab an extra lock in the > > read/write paths as that slows things down. Reuse the same per-queue > > TX/RX lock and have: > > > > * a reset flag that is set when something is resetting; that says to > > the queue "don't bother processing anything, just dive out"; > > * 'i am doing Tx / Rx' flags per queue that is set at the start of > > TX/RX servicing and finishes at the end; that way the reset code knows > > if there's something pending; > > * have the reset path grab each lock, set the 'reset' flag on each, > > then walk each queue again and make sure they're all marked as 'not > > doing TX/RX'. At that point the reset can occur, then the flag cna be > > cleared, then TX/RX can resume. > > > > so this is slightly different from what Bryan suggested (and you endorsed) > before, as in that case there was a single 'reset' flag IFF_DRV_RUNNING > protected by the 'core' lock, then a nested round on all tx and rx locks > to make sure that all customers have seen it. > In both cases the tx and rx paths only need the per-queue lock. > > As i see it, having a per-queue reset flag removes the need for nesting > core + queue locks, but since this is only in the control path perhaps > it is not a big deal (and is better to have a single place to look at to > tell whether or not we should bail out). > > cheers > luigi > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 17:58:59 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C27597D; Mon, 5 Aug 2013 17:58:59 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 92C162C17; Mon, 5 Aug 2013 17:58:58 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id ec20so2316316lab.0 for ; Mon, 05 Aug 2013 10:58:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=6ZtvieGuGGhAoaS120XU/yBY9J5erKykOaKC1g2RHZM=; b=UDqfQxf4mqMb/UO47n6zUdZVEG+2QScx44XHXDKrGBij62yi6VgwfstSwP/4mRjeuP C3i1p87rUezNa7tErAFgfUfxtWM0zMzWIF4HLrgAZDYfYzvMxQ/1y3rwFKsabmX94ICk kdEOYdrztO04jq/AsqhYvRB4X2RlpLRvc629P/97Eh3gCL9o6vIRU7XqY+ObccFghCuh Ybgbw+wlWKU66CxpjwycKgZDFDF2gE+J+yMa6Uf8lUBcRZ1OTAp/J6CpfdDBfW4Gw1xr lk5eNM12nASMeUTxeAk0bbnUclap+UbbBppZnQPM7pRf0MA/YcO+auRNOOXIZ2rSKBv5 S9Xw== MIME-Version: 1.0 X-Received: by 10.152.36.198 with SMTP id s6mr5661194laj.67.1375725536550; Mon, 05 Aug 2013 10:58:56 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.200.165 with HTTP; Mon, 5 Aug 2013 10:58:56 -0700 (PDT) In-Reply-To: References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> Date: Mon, 5 Aug 2013 19:58:56 +0200 X-Google-Sender-Auth: -7AMBJyuIckaxEZBCuXlzZJHyq0 Message-ID: Subject: Re: [net] protecting interfaces from races between control and data ? From: Luigi Rizzo To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Adrian Chadd , FreeBSD current mailing list , Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri 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, 05 Aug 2013 17:58:59 -0000 On Mon, Aug 5, 2013 at 7:49 PM, Jack Vogel wrote: > Sigh, this ends up being ugly I'm afraid. I need some time to look at code > and think about it. > > actually the intel drivers seem in decent shape, especially if we reuse IFF_DRV_RUNNING as the reset flag and the core+queue lock in the control path. cheers luigi > Jack > > > > On Mon, Aug 5, 2013 at 10:36 AM, Luigi Rizzo wrote: > >> On Mon, Aug 5, 2013 at 7:17 PM, Adrian Chadd wrote: >> >> > I'm travelling back to San Jose today; poke me tomorrow and I'll brain >> > dump what I did in ath(4) and the lessons learnt. >> > >> > The TL;DR version - you don't want to grab an extra lock in the >> > read/write paths as that slows things down. Reuse the same per-queue >> > TX/RX lock and have: >> > >> > * a reset flag that is set when something is resetting; that says to >> > the queue "don't bother processing anything, just dive out"; >> > * 'i am doing Tx / Rx' flags per queue that is set at the start of >> > TX/RX servicing and finishes at the end; that way the reset code knows >> > if there's something pending; >> > * have the reset path grab each lock, set the 'reset' flag on each, >> > then walk each queue again and make sure they're all marked as 'not >> > doing TX/RX'. At that point the reset can occur, then the flag cna be >> > cleared, then TX/RX can resume. >> > >> >> so this is slightly different from what Bryan suggested (and you endorsed) >> before, as in that case there was a single 'reset' flag IFF_DRV_RUNNING >> protected by the 'core' lock, then a nested round on all tx and rx locks >> to make sure that all customers have seen it. >> In both cases the tx and rx paths only need the per-queue lock. >> >> As i see it, having a per-queue reset flag removes the need for nesting >> core + queue locks, but since this is only in the control path perhaps >> it is not a big deal (and is better to have a single place to look at to >> tell whether or not we should bail out). >> >> cheers >> luigi >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 18:19:06 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A99616D; Mon, 5 Aug 2013 18:19:06 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E01B52E0B; Mon, 5 Aug 2013 18:19:05 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id y10so2694972wgg.4 for ; Mon, 05 Aug 2013 11:19:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=tMzw5Vr38AmxBMmKKa5qf7JQp1ahPyDqUdmn+Y8bX9o=; b=kLNFSK2UD4LQN0lR0UjIMtPl24ZHTSkSmrc1tygIjL6YVaugIqgTKANlwt/lF3/JAX 9Y/P+YmAVyfiAiK0GPX7jXrbCltQSur1i6DbzDTOe7F9Nl4HH9h9i83A9b6ZHrgy+ANY gmqPNqVJ9PmaGtF5Rg4xv/koCVMQRs24rJlDiZmXgYOHaWtfQZh+PDT5ecczOddArxAX qL5y0AMjHdku6E2ADwWLY22DdRxWOUGhvYBUJWcJvMc92Pmu6uVBXEslpM+ZQpMiJrQ1 bW5zb5IXVKRIHx8CvcgVIw+xvA/vcYsXADII5UPeZV0rkgVd7QE2nKlyHBvwmyXQqi23 yyxg== MIME-Version: 1.0 X-Received: by 10.194.201.202 with SMTP id kc10mr14215519wjc.1.1375726744177; Mon, 05 Aug 2013 11:19:04 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.116.136 with HTTP; Mon, 5 Aug 2013 11:19:04 -0700 (PDT) In-Reply-To: References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> Date: Mon, 5 Aug 2013 11:19:04 -0700 X-Google-Sender-Auth: Ym1h1UimcX5x_7BkjBd_OP4xP4g Message-ID: Subject: Re: [net] protecting interfaces from races between control and data ? From: Adrian Chadd To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD current mailing list , Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri , Jack Vogel 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, 05 Aug 2013 18:19:06 -0000 No, brian said two things: * the flag, protected by the core lock * per-queue flags -adrian From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 18:46:12 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0DE467CC; Mon, 5 Aug 2013 18:46:12 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vb0-x231.google.com (mail-vb0-x231.google.com [IPv6:2607:f8b0:400c:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7F02A2FCA; Mon, 5 Aug 2013 18:46:11 +0000 (UTC) Received: by mail-vb0-f49.google.com with SMTP id w16so3144326vbb.8 for ; Mon, 05 Aug 2013 11:46:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6afeiJM6qdEqDg7Hhhu2/MbjauYgbQs3h+wtDMDualo=; b=HBU0qqgT82Lik9DbrYsPUPL+n1NQSAjUOy6B6ep2Nil1LdKMn94bXEfQAsqotv6bhR 7TWcrJePREOODMfQu8dULYCTb1dIOQ9oUfL0ryqc8xfaiY7d0Hxdy38bi6gRZ7tvRw9V kALV1ZG9MPpuib3rB0C89fxSkzsA6SEfDJNsBbUnMwoc1qBKUSlx8EX4x49JDduMRk3a VKceRQMC7T7uheZUdPqvjEJpoKYr8646y5IRvI2a3Yk1F7myOO01jnHLymdSaTowIeRK bS2XKrQNbS0EVPTenbylxvuQRXDBVbdJxzhbklxVtvAg5lmHxP+uogrqWvSds8QH9Mwh p41w== MIME-Version: 1.0 X-Received: by 10.58.97.238 with SMTP id ed14mr6154605veb.34.1375728370638; Mon, 05 Aug 2013 11:46:10 -0700 (PDT) Received: by 10.220.159.141 with HTTP; Mon, 5 Aug 2013 11:46:10 -0700 (PDT) In-Reply-To: References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> Date: Mon, 5 Aug 2013 11:46:10 -0700 Message-ID: Subject: Re: [net] protecting interfaces from races between control and data ? From: Jack Vogel To: Luigi Rizzo Content-Type: multipart/mixed; boundary=089e013a1666d6e88d04e337b81a X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Adrian Chadd , FreeBSD current mailing list , Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri 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, 05 Aug 2013 18:46:12 -0000 --089e013a1666d6e88d04e337b81a Content-Type: text/plain; charset=ISO-8859-1 What do you think about this change? Cheers, Jack On Mon, Aug 5, 2013 at 10:58 AM, Luigi Rizzo wrote: > On Mon, Aug 5, 2013 at 7:49 PM, Jack Vogel wrote: > >> Sigh, this ends up being ugly I'm afraid. I need some time to look at >> code and think about it. >> >> > actually the intel drivers seem in decent shape, > especially if we reuse IFF_DRV_RUNNING as the reset flag > and the core+queue lock in the control path. > > cheers > luigi > > > >> Jack >> >> >> >> On Mon, Aug 5, 2013 at 10:36 AM, Luigi Rizzo wrote: >> >>> On Mon, Aug 5, 2013 at 7:17 PM, Adrian Chadd wrote: >>> >>> > I'm travelling back to San Jose today; poke me tomorrow and I'll brain >>> > dump what I did in ath(4) and the lessons learnt. >>> > >>> > The TL;DR version - you don't want to grab an extra lock in the >>> > read/write paths as that slows things down. Reuse the same per-queue >>> > TX/RX lock and have: >>> > >>> > * a reset flag that is set when something is resetting; that says to >>> > the queue "don't bother processing anything, just dive out"; >>> > * 'i am doing Tx / Rx' flags per queue that is set at the start of >>> > TX/RX servicing and finishes at the end; that way the reset code knows >>> > if there's something pending; >>> > * have the reset path grab each lock, set the 'reset' flag on each, >>> > then walk each queue again and make sure they're all marked as 'not >>> > doing TX/RX'. At that point the reset can occur, then the flag cna be >>> > cleared, then TX/RX can resume. >>> > >>> >>> so this is slightly different from what Bryan suggested (and you >>> endorsed) >>> before, as in that case there was a single 'reset' flag IFF_DRV_RUNNING >>> protected by the 'core' lock, then a nested round on all tx and rx locks >>> to make sure that all customers have seen it. >>> In both cases the tx and rx paths only need the per-queue lock. >>> >>> As i see it, having a per-queue reset flag removes the need for nesting >>> core + queue locks, but since this is only in the control path perhaps >>> it is not a big deal (and is better to have a single place to look at to >>> tell whether or not we should bail out). >>> >>> cheers >>> luigi >>> >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >> >> > > > -- > -----------------------------------------+------------------------------- > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL +39-050-2211611 . via Diotisalvi 2 > Mobile +39-338-6809875 . 56122 PISA (Italy) > -----------------------------------------+------------------------------- > --089e013a1666d6e88d04e337b81a Content-Type: application/octet-stream; name="quiesce.diff" Content-Disposition: attachment; filename="quiesce.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hk012dni0 UHJveHlDaGFpbnMtMy4xIChodHRwOi8vcHJveHljaGFpbnMuc2YubmV0KQpJbmRleDogaXhnYmUu Ywo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09Ci0tLSBpeGdiZS5jCShyZXZpc2lvbiAyNTM5NjUpCisrKyBpeGdiZS5jCSh3 b3JraW5nIGNvcHkpCkBAIC0xMDczLDYgKzEwNzMsNyBAQAogCiAJbXR4X2Fzc2VydCgmYWRhcHRl ci0+Y29yZV9tdHgsIE1BX09XTkVEKTsKIAlJTklUX0RFQlVHT1VUKCJpeGdiZV9pbml0X2xvY2tl ZDogYmVnaW4iKTsKKwlpeGdiZV9xdWllc2NlX3F1ZXVlcyhhZGFwdGVyKTsKIAlody0+YWRhcHRl cl9zdG9wcGVkID0gRkFMU0U7CiAJaXhnYmVfc3RvcF9hZGFwdGVyKGh3KTsKICAgICAgICAgY2Fs bG91dF9zdG9wKCZhZGFwdGVyLT50aW1lcik7CkBAIC0xMzM2LDcgKzEzMzcsMjYgQEAKIAlyZXR1 cm47CiB9CiAKKy8qCisqKiBNYWtlIHN1cmUgYWxsIHF1ZXVlcyBoYXZlIHNlZW4gSUZGX0RSVl9S VU5OSU5HCisqKiBpcyBjbGVhcmVkIGFuZCBzdG9wIHByb2Nlc3NpbmcuCisqLworc3RhdGljIGlu bGluZSB2b2lkCitpeGdiZV9xdWllc2NlX3F1ZXVlcyhzdHJ1Y3QgYWRhcHRlciAqYWRhcHRlcikK K3sKKwlzdHJ1Y3QgaWZuZXQgICAqaWZwID0gYWRhcHRlci0+aWZwOworCXN0cnVjdCB0eF9yaW5n CSp0eHIgPSBhZGFwdGVyLT50eF9yaW5nczsKKwlzdHJ1Y3QgcnhfcmluZyAqcnhyID0gYWRhcHRl ci0+cnhfcmluZ3M7CiAKKwlpZnAtPmlmX2Rydl9mbGFncyAmPSB+SUZGX0RSVl9SVU5OSU5HOwor CWZvciAoaW50IGkgPSAwOyBpIDwgYWRhcHRlci0+bnVtX3F1ZXVlczsgaSsrLCByeHIrKywgdHhy KyspIHsKKwkJSVhHQkVfVFhfTE9DSyh0eHIpOworCQlJWEdCRV9UWF9VTkxPQ0sodHhyKTsKKwkJ SVhHQkVfUlhfTE9DSyhyeHIpOworCQlJWEdCRV9SWF9VTkxPQ0socnhyKTsKKwl9Cit9CisKIC8q CiAqKgogKiogTVNJWCBJbnRlcnJ1cHQgSGFuZGxlcnMgYW5kIFRhc2tsZXRzCg== --089e013a1666d6e88d04e337b81a-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 19:24:11 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4DD7253F; Mon, 5 Aug 2013 19:24:11 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 34B6A220A; Mon, 5 Aug 2013 19:24:11 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id r75JO505015827; Mon, 5 Aug 2013 12:24:05 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <51FFFBD4.7070705@rawbw.com> Date: Mon, 05 Aug 2013 12:24:04 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130628 Thunderbird/17.0.7 MIME-Version: 1.0 To: Mateusz Guzik Subject: Re: Linux epoll(7) patch References: <51FF7211.6020909@rawbw.com> <51FFC31D.3080304@mu.org> <20130805152556.GA37810@freebsd.org> <20130805153946.GA29300@dft-labs.eu> In-Reply-To: <20130805153946.GA29300@dft-labs.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Roman Divacky , Alfred Perlstein , 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, 05 Aug 2013 19:24:11 -0000 On 08/05/2013 08:39, Mateusz Guzik wrote: > What happens to fd after the fork? Is it closed or simply remains > non-functional? > > If the former, I suggest the patch is altered to leave fd with badfdops > in place so that epoll users get less surprised. I will try to alter it this way. However, there is no easy way of testing such case, apart from compiling specially crafted linux program. Also forking after poll is a marginal case. Doubt it ever matters in practice. I found two more problems with the patch: epoll_wait treats timeout as if it was in microseconds, when it is in milliseconds. Also epoll_wait doesn't check for the special case of timeout=-1. I corrected both issues. Will do additional testing, and will submit PR with an updated patch when done. Yuri From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 20:16:24 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0B48EBA8; Mon, 5 Aug 2013 20:16:24 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D13162589; Mon, 5 Aug 2013 20:16:22 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id ev20so2399907lab.36 for ; Mon, 05 Aug 2013 13:16:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=lSm+JfLcdP0pOg5ejSKOsqZcLRzLlSGySgP/NNuIpuE=; b=LT7tsatXzIytu83j92dOevJul3W8LoCbrxwomiOTfHyiifc9Fcye/gUp7SnLXNlvRm HasXXXzQtc3RuBdBn/q80iAC/s2HExE93MaaRJ9DjGeN2Km3Oq8d4siF9rXrorM+Y7AG wXPFyPcLHUuPFl48uXsg3+s5hZ1CBjlCsATKAd0HIVFor6S3y1dBNQPofQhM0kVbCf3W RRfkt3ld2yQOFEyAJBPsWrTmA18MroqimkEY/V+jZzYaxcf0fY6+LzKp7vaUW0Els0l1 UO1JJrgFDRD0XdLJ0vATQKwRtbVUV3/oOJdabeTSlWiYuwXaP0u3sWVTvj8Ce1hHB5CO fIgQ== MIME-Version: 1.0 X-Received: by 10.152.27.227 with SMTP id w3mr8381624lag.84.1375733780601; Mon, 05 Aug 2013 13:16:20 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.200.165 with HTTP; Mon, 5 Aug 2013 13:16:20 -0700 (PDT) In-Reply-To: References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> Date: Mon, 5 Aug 2013 22:16:20 +0200 X-Google-Sender-Auth: LS8qWBypBbsSgv83bL3eP3IuKrY Message-ID: Subject: Re: [net] protecting interfaces from races between control and data ? From: Luigi Rizzo To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD current mailing list , Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri , Jack Vogel 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, 05 Aug 2013 20:16:24 -0000 On Mon, Aug 5, 2013 at 8:19 PM, Adrian Chadd wrote: > No, brian said two things: > > * the flag, protected by the core lock > * per-queue flags > i see no mentions on per-queue flags on his email. This is the relevant part ------------ What I've done in my drivers is: * Lock the core mutex * Clear IFF_DRV_RUNNING * Lock/unlock each queue's lock The various Rx/Tx queue functions check for IFF_DRV_RUNNING after (re)acquiring their queue lock. See at vtnet_stop_rendezvous() at [1] for an example. [1] http://svnweb.freebsd.org/base/user/bryanv/vtnetmq/sys/dev/virtio/network/if_vtnet.c?revision=252451&view=markup ----------------- > > > > -adrian > -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 20:18:26 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AAE85D7B for ; Mon, 5 Aug 2013 20:18:26 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 01D5025BE for ; Mon, 5 Aug 2013 20:18:25 +0000 (UTC) Received: (qmail 46652 invoked from network); 5 Aug 2013 20:57:41 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 5 Aug 2013 20:57:41 -0000 Message-ID: <520006FB.4010202@freebsd.org> Date: Mon, 05 Aug 2013 22:11:39 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Bryan Venteicher Subject: Re: [net] protecting interfaces from races between control and data ? References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> In-Reply-To: <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Luigi Rizzo , current@freebsd.org, net@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, 05 Aug 2013 20:18:26 -0000 On 05.08.2013 16:59, Bryan Venteicher wrote: > > > ----- Original Message ----- >> i am slightly unclear of what mechanisms we use to prevent races >> between interface being reconfigured (up/down/multicast setting, etc, >> all causing reinitialization of the rx and tx rings) and >> >> i) packets from the host stack being sent out; >> ii) interrupts from the network card being processed. >> >> I think in the old times IFF_DRV_RUNNING was used for this purpose, >> but now it is not enough. >> Acquiring the "core lock" in the NIC does not seem enough, either, >> because newer drivers, especially multiqueue ones, have per-queue >> rx and tx locks. >> > > What I've done in my drivers is: > * Lock the core mutex > * Clear IFF_DRV_RUNNING > * Lock/unlock each queue's lock > > The various Rx/Tx queue functions check for IFF_DRV_RUNNING after > (re)acquiring their queue lock. See at vtnet_stop_rendezvous() at > [1] for an example. > >> Does anyone know if there is a generic mechanism, or each driver >> reimplements its own way ? >> > > We desperately need a saner ifnet/driver interface. I think andre@ > had some previous work in this area (and additional plans as well?). Yes. I have received a grant from the FF to look at this in depth, evaluate different approaches and to propose an implementation for the whole stack. -- Andre > IMO, there's a lot to like on what DragonflyBSD has done in this area. > > [1] - http://svnweb.freebsd.org/base/user/bryanv/vtnetmq/sys/dev/virtio/network/if_vtnet.c?revision=252451&view=markup > >> thanks >> luigi >> _______________________________________________ >> 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-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 20:20:52 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 27087AD for ; Mon, 5 Aug 2013 20:20:52 +0000 (UTC) (envelope-from joel@freebsd.org) Received: from mail.vnode.se (mail.vnode.se [212.247.52.13]) by mx1.freebsd.org (Postfix) with ESMTP id D76BB25FA for ; Mon, 5 Aug 2013 20:20:51 +0000 (UTC) Received: from mail.vnode.se (localhost [127.0.0.1]) by mail.vnode.se (Postfix) with ESMTP id 58E7BE3F07A; Mon, 5 Aug 2013 22:20:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at vnode.se Received: from mail.vnode.se ([127.0.0.1]) by mail.vnode.se (mail.vnode.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cr8BjbrGr8oz; Mon, 5 Aug 2013 22:20:42 +0200 (CEST) Received: from devbox.vnode.local (unknown [83.223.1.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.vnode.se (Postfix) with ESMTPSA id 0F1E9E3F079; Mon, 5 Aug 2013 22:20:41 +0200 (CEST) Date: Mon, 5 Aug 2013 22:20:40 +0200 From: Joel Dahl To: Bryan Venteicher Subject: Re: [CFT] VMware vmxnet3 ethernet driver Message-ID: <20130805202039.GA18861@devbox.vnode.local> References: <1050637258.686.1375660230986.JavaMail.root@daemoninthecloset.org> <601099152.721.1375661537866.JavaMail.root@daemoninthecloset.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <601099152.721.1375661537866.JavaMail.root@daemoninthecloset.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 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, 05 Aug 2013 20:20:52 -0000 On Sun, Aug 04, 2013 at 07:12:17PM -0500, Bryan Venteicher wrote: > Hi, > > I've ported the OpenBSD vmxnet3 ethernet driver to FreeBSD. I did a > lot of cleanup, bug fixes, new features, etc (+2000 new lines) along > the way so there is not much of a resemblance left. > > The driver is in good enough shape I'd like additional testers. A patch > against -CURRENT is at [1]. Alternatively, the driver and a Makefile is > at [2]; this should compile at least as far back as 9.1. I can look at > 8-STABLE if there is interest. > > Obviously, besides reports of 'it works', I'm interested performance vs > the emulated e1000, and (for those using it) the VMware tools vmxnet3 > driver. Hopefully it is no worse :) I have ~100 FreeBSD 8/9 VMs in my vSphere 5.1 environment, all using the VMware tools package from VMware. Everything has been running great for years. (we skipped vSphere 5.0). Why should I use this vmxnet driver instead of the VMware tools driver or the emulated e1000? -- Joel From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 20:23:05 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4C0C8301; Mon, 5 Aug 2013 20:23:05 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 313AF2630; Mon, 5 Aug 2013 20:23:04 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id fq13so2423046lab.39 for ; Mon, 05 Aug 2013 13:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=HYYcpMGp/JYLBrFL02NsZk+b146MTXEg1cQPplrFqPI=; b=tooPMRzea4HMOktJekdye0HM9KRKrxFRIN968Dtk5xkvdnjAZHxnp+GmjU7ZBYGyPr BLWzD/hcFZdnPXgHFUSTDK39MOfu6ULZwerI6aJQt41WEhM/Sw1LWJx0Bck74Z1+CM3y nhQ3A4j6BYI8VQg2UA0Cc+XIgV6E2/3gR6EAdWBtKijVvPByvNUngj7r2RsoynI7DBZ6 ERfDBvjvoLMkDBMFdGODG1UaUQnltSkNUsfwbtjvk+8JnTLfg2vRvkpvlufAyIy5Njh0 SgQULvXK1/8olwd1NDxSAUd0GT27FOfFTrn9WnI0KVk1go2vrCYBYkb/OU68gjanH4oU pBjg== MIME-Version: 1.0 X-Received: by 10.112.5.199 with SMTP id u7mr9634813lbu.67.1375734182140; Mon, 05 Aug 2013 13:23:02 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.200.165 with HTTP; Mon, 5 Aug 2013 13:23:02 -0700 (PDT) In-Reply-To: References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> Date: Mon, 5 Aug 2013 22:23:02 +0200 X-Google-Sender-Auth: R1Vl7ShBkSaL0gyIsijJhuAdlC0 Message-ID: Subject: Re: [net] protecting interfaces from races between control and data ? From: Luigi Rizzo To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Adrian Chadd , FreeBSD current mailing list , Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri 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, 05 Aug 2013 20:23:05 -0000 On Mon, Aug 5, 2013 at 8:46 PM, Jack Vogel wrote: > What do you think about this change? > > looks good to me. but there is no need to rush, especially it will be nice if all interested parties agree on an approach and possibly even naming. I do not have any specific test case but the problem came up when an interface is in netmap mode and dispatches to the in-kernel VALE switch, and userland tries to move the interface back to regular mode. cheers luigi From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 20:32:06 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 73DC2854 for ; Mon, 5 Aug 2013 20:32:06 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 92EA626AF for ; Mon, 5 Aug 2013 20:32:03 +0000 (UTC) Received: from alph.d.allbsd.org (p2049-ipbf1102funabasi.chiba.ocn.ne.jp [122.26.101.49]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id r75KVhoX048155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Aug 2013 05:31:53 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.5/8.14.5) with ESMTP id r75KVfsd017228 for ; Tue, 6 Aug 2013 05:31:42 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Tue, 06 Aug 2013 05:30:57 +0900 (JST) Message-Id: <20130806.053057.1087108059090705794.hrs@allbsd.org> To: current@FreeBSD.org Subject: HEADS UP: s/time_second/time_uptime/ in sys/netinet6 From: Hiroki Sato X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart0(Tue_Aug__6_05_30_57_2013_775)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Tue, 06 Aug 2013 05:31:53 +0900 (JST) X-Spam-Status: No, score=-89.9 required=13.0 tests=CONTENT_TYPE_PRESENT, DIRECTOCNDYN,DYN_PBL,FAKEDWORD_ZERO,QENCPTR1,RCVD_IN_PBL,SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 05 Aug 2013 20:32:06 -0000 ----Security_Multipart0(Tue_Aug__6_05_30_57_2013_775)-- Content-Type: Multipart/Mixed; boundary="--Next_Part(Tue_Aug__6_05_30_57_2013_464)--" Content-Transfer-Encoding: 7bit ----Next_Part(Tue_Aug__6_05_30_57_2013_464)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I just wanted to let you know that data structures in sys/netinet6 now uses time_uptime instead of time_second. This should not be user-visible, but if you notice there is something wrong with IPv6 after r253970, please let me know. Please do not forget to update rtsold(8), rtadvd(8), and ndp(8) together when you compile a new kernel. -- Hiroki ----Next_Part(Tue_Aug__6_05_30_57_2013_464)-- Content-Type: Message/Rfc822 Content-Transfer-Encoding: 7bit Return-Path: Received: from 133.31.130.32 ([unix socket]) by alph.allbsd.org (Cyrus v2.4.17) with LMTPA; Tue, 06 Aug 2013 05:13:38 +0900 X-Sieve: CMU Sieve 2.4 Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id r75KDFpN046110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 6 Aug 2013 05:13:26 +0900 (JST) (envelope-from owner-src-committers@FreeBSD.org) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.freebsd.org (Postfix) with ESMTPS id 94CE12BDE for ; Mon, 5 Aug 2013 20:13:14 +0000 (UTC) Received: by hub.freebsd.org (Postfix) id BE2A56B7; Mon, 5 Aug 2013 20:13:13 +0000 (UTC) Delivered-To: hrs@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 538) id 967CD676; Mon, 5 Aug 2013 20:13:13 +0000 (UTC) Delivered-To: src-committers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5B148674; Mon, 5 Aug 2013 20:13:06 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 46256255E; Mon, 5 Aug 2013 20:13:06 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.7/8.14.7) with ESMTP id r75KD6w6015170; Mon, 5 Aug 2013 20:13:06 GMT (envelope-from hrs@svn.freebsd.org) Received: (from hrs@localhost) by svn.freebsd.org (8.14.7/8.14.5/Submit) id r75KD36I015147; Mon, 5 Aug 2013 20:13:03 GMT (envelope-from hrs@svn.freebsd.org) Message-Id: <201308052013.r75KD36I015147@svn.freebsd.org> From: Hiroki Sato Date: Mon, 5 Aug 2013 20:13:03 +0000 (UTC) To: src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org Subject: svn commit: r253970 - in head: sys/netinet6 sys/sys usr.sbin/ndp usr.sbin/rtadvctl usr.sbin/rtadvd usr.sbin/rtsold X-SVN-Group: head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: owner-src-committers@FreeBSD.org Precedence: bulk X-Loop: FreeBSD.ORG X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Tue, 06 Aug 2013 05:13:27 +0900 (JST) X-Spam-Status: No, score=-99.3 required=13.0 tests=CONTENT_TYPE_PRESENT, FAKEDWORD_ZERO,REVDNSUNKNOWN,SPF_PASS,T_RP_MATCHES_RCVD,USER_IN_WHITELIST, X_CHINESE_RELAY autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Author: hrs Date: Mon Aug 5 20:13:02 2013 New Revision: 253970 URL: http://svnweb.freebsd.org/changeset/base/253970 Log: - Use time_uptime instead of time_second in data structures for PF_INET6 in kernel. This fixes various malfunction when the wall time clock is changed. Bump __FreeBSD_version to 1000041. - Use clock_gettime(CLOCK_MONOTONIC_FAST) in userland utilities. MFC after: 1 month Modified: head/sys/netinet6/icmp6.c head/sys/netinet6/in6.c head/sys/netinet6/in6.h head/sys/netinet6/ip6_forward.c head/sys/netinet6/ip6_id.c head/sys/netinet6/ip6_mroute.c head/sys/netinet6/nd6.c head/sys/netinet6/nd6_rtr.c head/sys/sys/param.h head/usr.sbin/ndp/ndp.c head/usr.sbin/rtadvctl/rtadvctl.c head/usr.sbin/rtadvd/config.c head/usr.sbin/rtadvd/rrenum.c head/usr.sbin/rtadvd/rtadvd.c head/usr.sbin/rtadvd/rtadvd.h head/usr.sbin/rtadvd/timer.c head/usr.sbin/rtadvd/timer.h head/usr.sbin/rtadvd/timer_subr.c head/usr.sbin/rtadvd/timer_subr.h head/usr.sbin/rtsold/dump.c head/usr.sbin/rtsold/rtsol.c head/usr.sbin/rtsold/rtsold.c head/usr.sbin/rtsold/rtsold.h Modified: head/sys/netinet6/icmp6.c ============================================================================== --- head/sys/netinet6/icmp6.c Mon Aug 5 19:42:03 2013 (r253969) +++ head/sys/netinet6/icmp6.c Mon Aug 5 20:13:02 2013 (r253970) @@ -1931,8 +1931,8 @@ ni6_store_addrs(struct icmp6_nodeinfo *n ltime = ND6_INFINITE_LIFETIME; else { if (ifa6->ia6_lifetime.ia6t_expire > - time_second) - ltime = htonl(ifa6->ia6_lifetime.ia6t_expire - time_second); + time_uptime) + ltime = htonl(ifa6->ia6_lifetime.ia6t_expire - time_uptime); else ltime = 0; } Modified: head/sys/netinet6/in6.c ============================================================================== --- head/sys/netinet6/in6.c Mon Aug 5 19:42:03 2013 (r253969) +++ head/sys/netinet6/in6.c Mon Aug 5 20:13:02 2013 (r253970) @@ -523,12 +523,12 @@ in6_control(struct socket *so, u_long cm /* sanity for overflow - beware unsigned */ lt = &ifr->ifr_ifru.ifru_lifetime; if (lt->ia6t_vltime != ND6_INFINITE_LIFETIME && - lt->ia6t_vltime + time_second < time_second) { + lt->ia6t_vltime + time_uptime < time_uptime) { error = EINVAL; goto out; } if (lt->ia6t_pltime != ND6_INFINITE_LIFETIME && - lt->ia6t_pltime + time_second < time_second) { + lt->ia6t_pltime + time_uptime < time_uptime) { error = EINVAL; goto out; } @@ -632,12 +632,12 @@ in6_control(struct socket *so, u_long cm /* for sanity */ if (ia->ia6_lifetime.ia6t_vltime != ND6_INFINITE_LIFETIME) { ia->ia6_lifetime.ia6t_expire = - time_second + ia->ia6_lifetime.ia6t_vltime; + time_uptime + ia->ia6_lifetime.ia6t_vltime; } else ia->ia6_lifetime.ia6t_expire = 0; if (ia->ia6_lifetime.ia6t_pltime != ND6_INFINITE_LIFETIME) { ia->ia6_lifetime.ia6t_preferred = - time_second + ia->ia6_lifetime.ia6t_pltime; + time_uptime + ia->ia6_lifetime.ia6t_pltime; } else ia->ia6_lifetime.ia6t_preferred = 0; break; @@ -1140,7 +1140,7 @@ in6_update_ifa(struct ifnet *ifp, struct ia->ia_ifa.ifa_addr = (struct sockaddr *)&ia->ia_addr; ia->ia_addr.sin6_family = AF_INET6; ia->ia_addr.sin6_len = sizeof(ia->ia_addr); - ia->ia6_createtime = time_second; + ia->ia6_createtime = time_uptime; if ((ifp->if_flags & (IFF_POINTOPOINT | IFF_LOOPBACK)) != 0) { /* * XXX: some functions expect that ifa_dstaddr is not @@ -1167,7 +1167,7 @@ in6_update_ifa(struct ifnet *ifp, struct } /* update timestamp */ - ia->ia6_updatetime = time_second; + ia->ia6_updatetime = time_uptime; /* set prefix mask */ if (ifra->ifra_prefixmask.sin6_len) { @@ -1217,12 +1217,12 @@ in6_update_ifa(struct ifnet *ifp, struct ia->ia6_lifetime = ifra->ifra_lifetime; if (ia->ia6_lifetime.ia6t_vltime != ND6_INFINITE_LIFETIME) { ia->ia6_lifetime.ia6t_expire = - time_second + ia->ia6_lifetime.ia6t_vltime; + time_uptime + ia->ia6_lifetime.ia6t_vltime; } else ia->ia6_lifetime.ia6t_expire = 0; if (ia->ia6_lifetime.ia6t_pltime != ND6_INFINITE_LIFETIME) { ia->ia6_lifetime.ia6t_preferred = - time_second + ia->ia6_lifetime.ia6t_pltime; + time_uptime + ia->ia6_lifetime.ia6t_pltime; } else ia->ia6_lifetime.ia6t_preferred = 0; @@ -1240,7 +1240,7 @@ in6_update_ifa(struct ifnet *ifp, struct */ if ((ifra->ifra_flags & IN6_IFF_DEPRECATED) != 0) { ia->ia6_lifetime.ia6t_pltime = 0; - ia->ia6_lifetime.ia6t_preferred = time_second; + ia->ia6_lifetime.ia6t_preferred = time_uptime; } /* * Make the address tentative before joining multicast addresses, Modified: head/sys/netinet6/in6.h ============================================================================== --- head/sys/netinet6/in6.h Mon Aug 5 19:42:03 2013 (r253969) +++ head/sys/netinet6/in6.h Mon Aug 5 20:13:02 2013 (r253970) @@ -361,11 +361,11 @@ extern const struct in6_addr in6addr_lin #define IFA6_IS_DEPRECATED(a) \ ((a)->ia6_lifetime.ia6t_pltime != ND6_INFINITE_LIFETIME && \ - (u_int32_t)((time_second - (a)->ia6_updatetime)) > \ + (u_int32_t)((time_uptime - (a)->ia6_updatetime)) > \ (a)->ia6_lifetime.ia6t_pltime) #define IFA6_IS_INVALID(a) \ ((a)->ia6_lifetime.ia6t_vltime != ND6_INFINITE_LIFETIME && \ - (u_int32_t)((time_second - (a)->ia6_updatetime)) > \ + (u_int32_t)((time_uptime - (a)->ia6_updatetime)) > \ (a)->ia6_lifetime.ia6t_vltime) #endif /* _KERNEL */ Modified: head/sys/netinet6/ip6_forward.c ============================================================================== --- head/sys/netinet6/ip6_forward.c Mon Aug 5 19:42:03 2013 (r253969) +++ head/sys/netinet6/ip6_forward.c Mon Aug 5 20:13:02 2013 (r253970) @@ -137,8 +137,8 @@ ip6_forward(struct mbuf *m, int srcrt) IN6_IS_ADDR_UNSPECIFIED(&ip6->ip6_src)) { IP6STAT_INC(ip6s_cantforward); /* XXX in6_ifstat_inc(rt->rt_ifp, ifs6_in_discard) */ - if (V_ip6_log_time + V_ip6_log_interval < time_second) { - V_ip6_log_time = time_second; + if (V_ip6_log_time + V_ip6_log_interval < time_uptime) { + V_ip6_log_time = time_uptime; log(LOG_DEBUG, "cannot forward " "from %s to %s nxt %d received on %s\n", @@ -405,8 +405,8 @@ skip_routing: IP6STAT_INC(ip6s_badscope); in6_ifstat_inc(rt->rt_ifp, ifs6_in_discard); - if (V_ip6_log_time + V_ip6_log_interval < time_second) { - V_ip6_log_time = time_second; + if (V_ip6_log_time + V_ip6_log_interval < time_uptime) { + V_ip6_log_time = time_uptime; log(LOG_DEBUG, "cannot forward " "src %s, dst %s, nxt %d, rcvif %s, outif %s\n", Modified: head/sys/netinet6/ip6_id.c ============================================================================== --- head/sys/netinet6/ip6_id.c Mon Aug 5 19:42:03 2013 (r253969) +++ head/sys/netinet6/ip6_id.c Mon Aug 5 20:13:02 2013 (r253970) @@ -221,7 +221,7 @@ initid(struct randomtab *p) p->ru_g = pmod(p->ru_gen, j, p->ru_n); p->ru_counter = 0; - p->ru_reseed = time_second + p->ru_out; + p->ru_reseed = time_uptime + p->ru_out; p->ru_msb = p->ru_msb ? 0 : (1U << (p->ru_bits - 1)); } @@ -231,7 +231,7 @@ randomid(struct randomtab *p) int i, n; u_int32_t tmp; - if (p->ru_counter >= p->ru_max || time_second > p->ru_reseed) + if (p->ru_counter >= p->ru_max || time_uptime > p->ru_reseed) initid(p); tmp = arc4random(); Modified: head/sys/netinet6/ip6_mroute.c ============================================================================== --- head/sys/netinet6/ip6_mroute.c Mon Aug 5 19:42:03 2013 (r253969) +++ head/sys/netinet6/ip6_mroute.c Mon Aug 5 20:13:02 2013 (r253970) @@ -1103,8 +1103,8 @@ X_ip6_mforward(struct ip6_hdr *ip6, stru */ if (IN6_IS_ADDR_UNSPECIFIED(&ip6->ip6_src)) { IP6STAT_INC(ip6s_cantforward); - if (V_ip6_log_time + V_ip6_log_interval < time_second) { - V_ip6_log_time = time_second; + if (V_ip6_log_time + V_ip6_log_interval < time_uptime) { + V_ip6_log_time = time_uptime; log(LOG_DEBUG, "cannot forward " "from %s to %s nxt %d received on %s\n", Modified: head/sys/netinet6/nd6.c ============================================================================== --- head/sys/netinet6/nd6.c Mon Aug 5 19:42:03 2013 (r253969) +++ head/sys/netinet6/nd6.c Mon Aug 5 20:13:02 2013 (r253970) @@ -428,7 +428,7 @@ nd6_llinfo_settimer_locked(struct llentr ln->ln_ntick = 0; canceled = callout_stop(&ln->ln_timer_ch); } else { - ln->la_expire = time_second + tick / hz; + ln->la_expire = time_uptime + tick / hz; LLE_ADDREF(ln); if (tick > INT_MAX) { ln->ln_ntick = tick - INT_MAX; @@ -591,7 +591,7 @@ nd6_timer(void *arg) /* expire default router list */ TAILQ_FOREACH_SAFE(dr, &V_nd_defrouter, dr_entry, ndr) { - if (dr->expire && dr->expire < time_second) + if (dr->expire && dr->expire < time_uptime) defrtrlist_del(dr); } @@ -675,7 +675,7 @@ nd6_timer(void *arg) * prefix is not necessary. */ if (pr->ndpr_vltime != ND6_INFINITE_LIFETIME && - time_second - pr->ndpr_lastupdate > pr->ndpr_vltime) { + time_uptime - pr->ndpr_lastupdate > pr->ndpr_vltime) { /* * address expiration and prefix expiration are @@ -1033,9 +1033,9 @@ nd6_free(struct llentry *ln, int gc) * XXX: the check for ln_state would be redundant, * but we intentionally keep it just in case. */ - if (dr->expire > time_second) + if (dr->expire > time_uptime) nd6_llinfo_settimer_locked(ln, - (dr->expire - time_second) * hz); + (dr->expire - time_uptime) * hz); else nd6_llinfo_settimer_locked(ln, (long)V_nd6_gctimer * hz); Modified: head/sys/netinet6/nd6_rtr.c ============================================================================== --- head/sys/netinet6/nd6_rtr.c Mon Aug 5 19:42:03 2013 (r253969) +++ head/sys/netinet6/nd6_rtr.c Mon Aug 5 20:13:02 2013 (r253970) @@ -282,7 +282,7 @@ nd6_ra_input(struct mbuf *m, int off, in dr0.rtlifetime = 0; else dr0.rtlifetime = ntohs(nd_ra->nd_ra_router_lifetime); - dr0.expire = time_second + dr0.rtlifetime; + dr0.expire = time_uptime + dr0.rtlifetime; dr0.ifp = ifp; /* unspecified or not? (RFC 2461 6.3.4) */ if (advreachable) { @@ -874,7 +874,7 @@ nd6_prelist_add(struct nd_prefixctl *pr, free(new, M_IP6NDP); return(error); } - new->ndpr_lastupdate = time_second; + new->ndpr_lastupdate = time_uptime; if (newp != NULL) *newp = new; @@ -998,7 +998,7 @@ prelist_update(struct nd_prefixctl *new, pr->ndpr_vltime = new->ndpr_vltime; pr->ndpr_pltime = new->ndpr_pltime; (void)in6_init_prefix_ltimes(pr); /* XXX error case? */ - pr->ndpr_lastupdate = time_second; + pr->ndpr_lastupdate = time_uptime; } if (new->ndpr_raf_onlink && @@ -1136,7 +1136,7 @@ prelist_update(struct nd_prefixctl *new, if (lt6_tmp.ia6t_vltime == ND6_INFINITE_LIFETIME) remaininglifetime = ND6_INFINITE_LIFETIME; - else if (time_second - ifa6->ia6_updatetime > + else if (time_uptime - ifa6->ia6_updatetime > lt6_tmp.ia6t_vltime) { /* * The case of "invalid" address. We should usually @@ -1145,7 +1145,7 @@ prelist_update(struct nd_prefixctl *new, remaininglifetime = 0; } else remaininglifetime = lt6_tmp.ia6t_vltime - - (time_second - ifa6->ia6_updatetime); + (time_uptime - ifa6->ia6_updatetime); /* when not updating, keep the current stored lifetime. */ lt6_tmp.ia6t_vltime = remaininglifetime; @@ -1181,18 +1181,18 @@ prelist_update(struct nd_prefixctl *new, u_int32_t maxvltime, maxpltime; if (V_ip6_temp_valid_lifetime > - (u_int32_t)((time_second - ifa6->ia6_createtime) + + (u_int32_t)((time_uptime - ifa6->ia6_createtime) + V_ip6_desync_factor)) { maxvltime = V_ip6_temp_valid_lifetime - - (time_second - ifa6->ia6_createtime) - + (time_uptime - ifa6->ia6_createtime) - V_ip6_desync_factor; } else maxvltime = 0; if (V_ip6_temp_preferred_lifetime > - (u_int32_t)((time_second - ifa6->ia6_createtime) + + (u_int32_t)((time_uptime - ifa6->ia6_createtime) + V_ip6_desync_factor)) { maxpltime = V_ip6_temp_preferred_lifetime - - (time_second - ifa6->ia6_createtime) - + (time_uptime - ifa6->ia6_createtime) - V_ip6_desync_factor; } else maxpltime = 0; @@ -1207,7 +1207,7 @@ prelist_update(struct nd_prefixctl *new, } } ifa6->ia6_lifetime = lt6_tmp; - ifa6->ia6_updatetime = time_second; + ifa6->ia6_updatetime = time_uptime; } IF_ADDR_RUNLOCK(ifp); if (ia6_match == NULL && new->ndpr_vltime) { @@ -1988,7 +1988,7 @@ in6_tmpifadd(const struct in6_ifaddr *ia if (ia0->ia6_lifetime.ia6t_vltime != ND6_INFINITE_LIFETIME) { vltime0 = IFA6_IS_INVALID(ia0) ? 0 : (ia0->ia6_lifetime.ia6t_vltime - - (time_second - ia0->ia6_updatetime)); + (time_uptime - ia0->ia6_updatetime)); if (vltime0 > V_ip6_temp_valid_lifetime) vltime0 = V_ip6_temp_valid_lifetime; } else @@ -1996,7 +1996,7 @@ in6_tmpifadd(const struct in6_ifaddr *ia if (ia0->ia6_lifetime.ia6t_pltime != ND6_INFINITE_LIFETIME) { pltime0 = IFA6_IS_DEPRECATED(ia0) ? 0 : (ia0->ia6_lifetime.ia6t_pltime - - (time_second - ia0->ia6_updatetime)); + (time_uptime - ia0->ia6_updatetime)); if (pltime0 > V_ip6_temp_preferred_lifetime - V_ip6_desync_factor){ pltime0 = V_ip6_temp_preferred_lifetime - V_ip6_desync_factor; @@ -2054,11 +2054,11 @@ in6_init_prefix_ltimes(struct nd_prefix if (ndpr->ndpr_pltime == ND6_INFINITE_LIFETIME) ndpr->ndpr_preferred = 0; else - ndpr->ndpr_preferred = time_second + ndpr->ndpr_pltime; + ndpr->ndpr_preferred = time_uptime + ndpr->ndpr_pltime; if (ndpr->ndpr_vltime == ND6_INFINITE_LIFETIME) ndpr->ndpr_expire = 0; else - ndpr->ndpr_expire = time_second + ndpr->ndpr_vltime; + ndpr->ndpr_expire = time_uptime + ndpr->ndpr_vltime; return 0; } @@ -2070,7 +2070,7 @@ in6_init_address_ltimes(struct nd_prefix if (lt6->ia6t_vltime == ND6_INFINITE_LIFETIME) lt6->ia6t_expire = 0; else { - lt6->ia6t_expire = time_second; + lt6->ia6t_expire = time_uptime; lt6->ia6t_expire += lt6->ia6t_vltime; } @@ -2078,7 +2078,7 @@ in6_init_address_ltimes(struct nd_prefix if (lt6->ia6t_pltime == ND6_INFINITE_LIFETIME) lt6->ia6t_preferred = 0; else { - lt6->ia6t_preferred = time_second; + lt6->ia6t_preferred = time_uptime; lt6->ia6t_preferred += lt6->ia6t_pltime; } } Modified: head/sys/sys/param.h ============================================================================== --- head/sys/sys/param.h Mon Aug 5 19:42:03 2013 (r253969) +++ head/sys/sys/param.h Mon Aug 5 20:13:02 2013 (r253970) @@ -58,7 +58,7 @@ * in the range 5 to 9. */ #undef __FreeBSD_version -#define __FreeBSD_version 1000040 /* Master, propagated to newvers */ +#define __FreeBSD_version 1000041 /* Master, propagated to newvers */ /* * __FreeBSD_kernel__ indicates that this system uses the kernel of FreeBSD, Modified: head/usr.sbin/ndp/ndp.c ============================================================================== --- head/usr.sbin/ndp/ndp.c Mon Aug 5 19:42:03 2013 (r253969) +++ head/usr.sbin/ndp/ndp.c Mon Aug 5 20:13:02 2013 (r253970) @@ -79,7 +79,6 @@ #include #include #include -#include #include #include @@ -105,6 +104,7 @@ #include #include #include +#include #include #include #include "gmt2local.h" @@ -125,6 +125,7 @@ static int tflag; static int32_t thiszone; /* time difference with gmt */ static int s = -1; static int repeat = 0; +static struct timespec ts, ts0; char ntop_buf[INET6_ADDRSTRLEN]; /* inet_ntop() */ char host_buf[NI_MAXHOST]; /* getnameinfo() */ @@ -153,7 +154,7 @@ static void getdefif(void); static void setdefif(char *); #endif static char *sec2str(time_t); -static void ts_print(const struct timeval *); +static void ts_print(const struct timespec *); #ifdef ICMPV6CTL_ND6_DRLIST static char *rtpref_str[] = { @@ -164,6 +165,16 @@ static char *rtpref_str[] = { }; #endif +#define TS_SUB(tsp, usp, vsp) \ + do { \ + (vsp)->tv_sec = (tsp)->tv_sec - (usp)->tv_sec; \ + (vsp)->tv_nsec = (tsp)->tv_nsec - (usp)->tv_nsec; \ + if ((vsp)->tv_nsec < 0) { \ + (vsp)->tv_sec--; \ + (vsp)->tv_nsec += 1000000000L; \ + } \ + } while (0) + int mode = 0; char *arg = NULL; @@ -172,10 +183,14 @@ main(argc, argv) int argc; char **argv; { + struct timespec now; int ch; pid = getpid(); thiszone = gmt2local(0); + clock_gettime(CLOCK_REALTIME_FAST, &now); + clock_gettime(CLOCK_MONOTONIC_FAST, &ts); + TS_SUB(&now, &ts, &ts0); while ((ch = getopt(argc, argv, "acd:f:Ii:nprstA:HPR")) != -1) switch (ch) { case 'a': @@ -367,7 +382,8 @@ getsocket() struct sockaddr_in6 so_mask = {sizeof(so_mask), AF_INET6 }; struct sockaddr_in6 blank_sin = {sizeof(blank_sin), AF_INET6 }, sin_m; struct sockaddr_dl blank_sdl = {sizeof(blank_sdl), AF_LINK }, sdl_m; -int expire_time, flags, found_entry; +static time_t expire_time; +static int flags, found_entry; struct { struct rt_msghdr m_rtm; char m_space[512]; @@ -412,10 +428,10 @@ set(argc, argv) flags = expire_time = 0; while (argc-- > 0) { if (strncmp(argv[0], "temp", 4) == 0) { - struct timeval time; + struct timespec now; - gettimeofday(&time, 0); - expire_time = time.tv_sec + 20 * 60; + clock_gettime(CLOCK_MONOTONIC_FAST, &now); + expire_time = now.tv_sec + 20 * 60; } else if (strncmp(argv[0], "proxy", 5) == 0) flags |= RTF_ANNOUNCE; argv++; @@ -566,7 +582,7 @@ dump(addr, cflag) struct sockaddr_dl *sdl; extern int h_errno; struct in6_nbrinfo *nbi; - struct timeval time; + struct timespec now; int addrwidth; int llwidth; int ifwidth; @@ -653,9 +669,9 @@ again:; #endif continue; } - gettimeofday(&time, 0); + clock_gettime(CLOCK_MONOTONIC_FAST, &now); if (tflag) - ts_print(&time); + ts_print(&now); addrwidth = strlen(host_buf); if (addrwidth < W_ADDR) @@ -676,9 +692,9 @@ again:; /* Print neighbor discovery specific informations */ nbi = getnbrinfo(&sin->sin6_addr, sdl->sdl_index, 1); if (nbi) { - if (nbi->expire > time.tv_sec) { + if (nbi->expire > now.tv_sec) { printf(" %-9.9s", - sec2str(nbi->expire - time.tv_sec)); + sec2str(nbi->expire - now.tv_sec)); } else if (nbi->expire == 0) printf(" %-9.9s", "permanent"); else @@ -1075,7 +1091,7 @@ rtrlist() char *buf; struct in6_defrouter *p, *ep; size_t l; - struct timeval time; + struct timespec now; if (sysctl(mib, sizeof(mib) / sizeof(mib[0]), NULL, &l, NULL, 0) < 0) { err(1, "sysctl(ICMPV6CTL_ND6_DRLIST)"); @@ -1110,18 +1126,18 @@ rtrlist() rtpref = ((p->flags & ND_RA_FLAG_RTPREF_MASK) >> 3) & 0xff; printf(", pref=%s", rtpref_str[rtpref]); - gettimeofday(&time, 0); + clock_gettime(CLOCK_MONOTONIC_FAST, &now); if (p->expire == 0) printf(", expire=Never\n"); else printf(", expire=%s\n", - sec2str(p->expire - time.tv_sec)); + sec2str(p->expire - now.tv_sec)); } free(buf); #else struct in6_drlist dr; int s, i; - struct timeval time; + struct timespec now; if ((s = socket(AF_INET6, SOCK_DGRAM, 0)) < 0) { err(1, "socket"); @@ -1150,12 +1166,12 @@ rtrlist() printf(", flags=%s%s", DR.flags & ND_RA_FLAG_MANAGED ? "M" : "", DR.flags & ND_RA_FLAG_OTHER ? "O" : ""); - gettimeofday(&time, 0); + clock_gettime(CLOCK_MONOTONIC_FAST, &now); if (DR.expire == 0) printf(", expire=Never\n"); else printf(", expire=%s\n", - sec2str(DR.expire - time.tv_sec)); + sec2str(DR.expire - now.tv_sec)); } #undef DR close(s); @@ -1171,7 +1187,7 @@ plist() struct in6_prefix *p, *ep, *n; struct sockaddr_in6 *advrtr; size_t l; - struct timeval time; + struct timespec now; const int niflags = NI_NUMERICHOST; int ninflags = nflag ? NI_NUMERICHOST : 0; char namebuf[NI_MAXHOST]; @@ -1202,7 +1218,7 @@ plist() printf("%s/%d if=%s\n", namebuf, p->prefixlen, if_indextoname(p->if_index, ifix_buf)); - gettimeofday(&time, 0); + clock_gettime(CLOCK_MONOTONIC_FAST, &now); /* * meaning of fields, especially flags, is very different * by origin. notify the difference to the users. @@ -1228,9 +1244,9 @@ plist() printf(", pltime=%lu", (unsigned long)p->pltime); if (p->expire == 0) printf(", expire=Never"); - else if (p->expire >= time.tv_sec) + else if (p->expire >= now.tv_sec) printf(", expire=%s", - sec2str(p->expire - time.tv_sec)); + sec2str(p->expire - now.tv_sec)); else printf(", expired"); printf(", ref=%d", p->refcnt); @@ -1278,9 +1294,9 @@ plist() #else struct in6_prlist pr; int s, i; - struct timeval time; + struct timespec now; - gettimeofday(&time, 0); + clock_gettime(CLOCK_MONOTONIC_FAST, &now); if ((s = socket(AF_INET6, SOCK_DGRAM, 0)) < 0) { err(1, "socket"); @@ -1316,7 +1332,7 @@ plist() printf("%s/%d if=%s\n", namebuf, PR.prefixlen, if_indextoname(PR.if_index, ifix_buf)); - gettimeofday(&time, 0); + clock_gettime(CLOCK_MONOTONIC_FAST, &now); /* * meaning of fields, especially flags, is very different * by origin. notify the difference to the users. @@ -1352,9 +1368,9 @@ plist() printf(", pltime=%lu", PR.pltime); if (PR.expire == 0) printf(", expire=Never"); - else if (PR.expire >= time.tv_sec) + else if (PR.expire >= now.tv_sec) printf(", expire=%s", - sec2str(PR.expire - time.tv_sec)); + sec2str(PR.expire - now.tv_sec)); else printf(", expired"); #ifdef NDPRF_ONLINK @@ -1577,15 +1593,15 @@ sec2str(total) * from tcpdump/util.c */ static void -ts_print(tvp) - const struct timeval *tvp; +ts_print(tsp) + const struct timespec *tsp; { int s; /* Default */ - s = (tvp->tv_sec + thiszone) % 86400; + s = (tsp->tv_sec + thiszone + ts0.tv_sec) % 86400; (void)printf("%02d:%02d:%02d.%06u ", - s / 3600, (s % 3600) / 60, s % 60, (u_int32_t)tvp->tv_usec); + s / 3600, (s % 3600) / 60, s % 60, (u_int32_t)tsp->tv_nsec / 1000); } #undef NEXTADDR Modified: head/usr.sbin/rtadvctl/rtadvctl.c ============================================================================== --- head/usr.sbin/rtadvctl/rtadvctl.c Mon Aug 5 19:42:03 2013 (r253969) +++ head/usr.sbin/rtadvctl/rtadvctl.c Mon Aug 5 20:13:02 2013 (r253970) @@ -55,6 +55,7 @@ #include #include #include +#include #include #include "pathnames.h" @@ -416,6 +417,7 @@ action_show(int argc, char **argv) char argv_dnssl[IFNAMSIZ + sizeof(":dnssl=")]; char ssbuf[SSBUFLEN]; + struct timespec now, ts0, ts; struct ctrl_msg_pl cp; struct ifinfo *ifi; TAILQ_HEAD(, ifinfo) ifl = TAILQ_HEAD_INITIALIZER(ifl); @@ -464,6 +466,10 @@ action_show(int argc, char **argv) } } + clock_gettime(CLOCK_REALTIME_FAST, &now); + clock_gettime(CLOCK_MONOTONIC_FAST, &ts); + TS_SUB(&now, &ts, &ts0); + TAILQ_FOREACH(ifi, &ifl, ifi_next) { struct ifinfo *ifi_s; struct rtadvd_timer *rat; @@ -615,12 +621,20 @@ action_show(int argc, char **argv) rat = (struct rtadvd_timer *)cp.cp_val; } - printf("\tNext RA send: %s", - (rat == NULL) ? "never\n" : - ctime((time_t *)&rat->rat_tm.tv_sec)); - printf("\tLast RA sent: %s", - (ifi_s->ifi_ra_lastsent.tv_sec == 0) ? "never\n" : - ctime((time_t *)&ifi_s->ifi_ra_lastsent.tv_sec)); + printf("\tNext RA send: "); + if (rat == NULL) + printf("never\n"); + else { + ts.tv_sec = rat->rat_tm.tv_sec + ts0.tv_sec; + printf("%s", ctime(&ts.tv_sec)); + } + printf("\tLast RA send: "); + if (ifi_s->ifi_ra_lastsent.tv_sec == 0) + printf("never\n"); + else { + ts.tv_sec = ifi_s->ifi_ra_lastsent.tv_sec + ts0.tv_sec; + printf("%s", ctime(&ts.tv_sec)); + } if (rai->rai_clockskew) printf("\tClock skew: %" PRIu16 "sec\n", rai->rai_clockskew); @@ -747,9 +761,9 @@ action_show_prefix(struct prefix *pfx) { char ntopbuf[INET6_ADDRSTRLEN]; char ssbuf[SSBUFLEN]; - struct timeval now; + struct timespec now; - gettimeofday(&now, NULL); + clock_gettime(CLOCK_MONOTONIC_FAST, &now); printf("\t %s/%d", inet_ntop(AF_INET6, &pfx->pfx_prefix, ntopbuf, sizeof(ntopbuf)), pfx->pfx_prefixlen); @@ -800,7 +814,7 @@ action_show_prefix(struct prefix *pfx) printf(""); if (pfx->pfx_timer) { - struct timeval *rest; + struct timespec *rest; rest = rtadvd_timer_rest(pfx->pfx_timer); if (rest) { /* XXX: what if not? */ Modified: head/usr.sbin/rtadvd/config.c ============================================================================== --- head/usr.sbin/rtadvd/config.c Mon Aug 5 19:42:03 2013 (r253969) +++ head/usr.sbin/rtadvd/config.c Mon Aug 5 20:13:02 2013 (r253970) @@ -34,7 +34,6 @@ #include #include #include -#include #include #include @@ -58,6 +57,7 @@ #include #include #include +#include #include #include @@ -563,8 +563,9 @@ getconfig(struct ifinfo *ifi) makeentry(entbuf, sizeof(entbuf), i, "vltimedecr"); if (agetflag(entbuf)) { - struct timeval now; - gettimeofday(&now, 0); + struct timespec now; + + clock_gettime(CLOCK_MONOTONIC_FAST, &now); pfx->pfx_vltimeexpire = now.tv_sec + pfx->pfx_validlifetime; } @@ -583,8 +584,9 @@ getconfig(struct ifinfo *ifi) makeentry(entbuf, sizeof(entbuf), i, "pltimedecr"); if (agetflag(entbuf)) { - struct timeval now; - gettimeofday(&now, 0); + struct timespec now; + + clock_gettime(CLOCK_MONOTONIC_FAST, &now); pfx->pfx_pltimeexpire = now.tv_sec + pfx->pfx_preflifetime; } @@ -1164,7 +1166,7 @@ delete_prefix(struct prefix *pfx) void invalidate_prefix(struct prefix *pfx) { - struct timeval timo; + struct timespec timo; struct rainfo *rai; struct ifinfo *ifi; char ntopbuf[INET6_ADDRSTRLEN]; @@ -1191,7 +1193,7 @@ invalidate_prefix(struct prefix *pfx) delete_prefix(pfx); } timo.tv_sec = prefix_timo; - timo.tv_usec = 0; + timo.tv_nsec = 0; rtadvd_set_timer(&timo, pfx->pfx_timer); } @@ -1415,7 +1417,7 @@ make_packet(struct rainfo *rai) TAILQ_FOREACH(pfx, &rai->rai_prefix, pfx_next) { uint32_t vltime, pltime; - struct timeval now; + struct timespec now; ndopt_pi = (struct nd_opt_prefix_info *)buf; ndopt_pi->nd_opt_pi_type = ND_OPT_PREFIX_INFORMATION; @@ -1432,7 +1434,7 @@ make_packet(struct rainfo *rai) vltime = 0; else { if (pfx->pfx_vltimeexpire || pfx->pfx_pltimeexpire) - gettimeofday(&now, NULL); + clock_gettime(CLOCK_MONOTONIC_FAST, &now); if (pfx->pfx_vltimeexpire == 0) vltime = pfx->pfx_validlifetime; else Modified: head/usr.sbin/rtadvd/rrenum.c ============================================================================== --- head/usr.sbin/rtadvd/rrenum.c Mon Aug 5 19:42:03 2013 (r253969) +++ head/usr.sbin/rtadvd/rrenum.c Mon Aug 5 20:13:02 2013 (r253970) @@ -49,6 +49,7 @@ #include #include #include +#include #include #include "rtadvd.h" #include "rrenum.h" @@ -215,7 +216,7 @@ do_use_prefix(int len, struct rr_pco_mat rai = ifi->ifi_rainfo; TAILQ_FOREACH(pfx, &rai->rai_prefix, pfx_next) { - struct timeval now; + struct timespec now; if (prefix_match(&pfx->pfx_prefix, pfx->pfx_prefixlen, &rpm->rpm_prefix, @@ -226,14 +227,16 @@ do_use_prefix(int len, struct rr_pco_mat pfx->pfx_preflifetime = ntohl(rpu->rpu_pltime); if (irr->irr_rrf_decrvalid) { - gettimeofday(&now, 0); + clock_gettime(CLOCK_MONOTONIC_FAST, + &now); pfx->pfx_vltimeexpire = now.tv_sec + pfx->pfx_validlifetime; } else pfx->pfx_vltimeexpire = 0; if (irr->irr_rrf_decrprefd) { - gettimeofday(&now, 0); + clock_gettime(CLOCK_MONOTONIC_FAST, + &now); pfx->pfx_pltimeexpire = now.tv_sec + pfx->pfx_preflifetime; Modified: head/usr.sbin/rtadvd/rtadvd.c ============================================================================== --- head/usr.sbin/rtadvd/rtadvd.c Mon Aug 5 19:42:03 2013 (r253969) +++ head/usr.sbin/rtadvd/rtadvd.c Mon Aug 5 20:13:02 2013 (r253970) @@ -35,7 +35,6 @@ #include #include #include -#include #include #include #include @@ -179,7 +178,7 @@ int main(int argc, char *argv[]) { struct pollfd set[PFD_MAX]; - struct timeval *timeout; + struct timespec *timeout; int i, ch; int fflag = 0, logopt; int error; @@ -331,7 +330,7 @@ main(int argc, char *argv[]) "<%s> set timer to %ld:%ld. waiting for " "inputs or timeout", __func__, (long int)timeout->tv_sec, - (long int)timeout->tv_usec); + (long int)timeout->tv_nsec / 1000); } else { syslog(LOG_DEBUG, "<%s> there's no timer. waiting for inputs", @@ -339,7 +338,7 @@ main(int argc, char *argv[]) } if ((i = poll(set, sizeof(set)/sizeof(set[0]), timeout ? (timeout->tv_sec * 1000 + - timeout->tv_usec / 1000) : INFTIM)) < 0) { + timeout->tv_nsec / 1000 / 1000) : INFTIM)) < 0) { /* EINTR would occur if a signal was delivered */ if (errno != EINTR) @@ -432,7 +431,7 @@ rtadvd_shutdown(void) if (ifi->ifi_ra_timer == NULL) continue; if (ifi->ifi_ra_lastsent.tv_sec == 0 && - ifi->ifi_ra_lastsent.tv_usec == 0 && + ifi->ifi_ra_lastsent.tv_nsec == 0 && ifi->ifi_ra_timer != NULL) { /* * When RA configured but never sent, @@ -1006,7 +1005,7 @@ static void set_short_delay(struct ifinfo *ifi) { long delay; /* must not be greater than 1000000 */ - struct timeval interval, now, min_delay, tm_tmp, *rest; + struct timespec interval, now, min_delay, tm_tmp, *rest; if (ifi->ifi_ra_timer == NULL) return; @@ -1023,9 +1022,9 @@ set_short_delay(struct ifinfo *ifi) delay = random() % MAX_RA_DELAY_TIME; #endif interval.tv_sec = 0; - interval.tv_usec = delay; + interval.tv_nsec = delay * 1000; rest = rtadvd_timer_rest(ifi->ifi_ra_timer); - if (TIMEVAL_LT(rest, &interval)) { + if (TS_CMP(rest, &interval, <)) { syslog(LOG_DEBUG, "<%s> random delay is larger than " "the rest of the current timer", __func__); interval = *rest; @@ -1038,13 +1037,13 @@ set_short_delay(struct ifinfo *ifi) * MIN_DELAY_BETWEEN_RAS plus the random value after the * previous advertisement was sent. */ - gettimeofday(&now, NULL); - TIMEVAL_SUB(&now, &ifi->ifi_ra_lastsent, &tm_tmp); + clock_gettime(CLOCK_MONOTONIC_FAST, &now); + TS_SUB(&now, &ifi->ifi_ra_lastsent, &tm_tmp); min_delay.tv_sec = MIN_DELAY_BETWEEN_RAS; - min_delay.tv_usec = 0; - if (TIMEVAL_LT(&tm_tmp, &min_delay)) { - TIMEVAL_SUB(&min_delay, &tm_tmp, &min_delay); - TIMEVAL_ADD(&min_delay, &interval, &interval); + min_delay.tv_nsec = 0; + if (TS_CMP(&tm_tmp, &min_delay, <)) { + TS_SUB(&min_delay, &tm_tmp, &min_delay); + TS_ADD(&min_delay, &interval, &interval); } rtadvd_set_timer(&interval, ifi->ifi_ra_timer); } @@ -1242,7 +1241,7 @@ prefix_check(struct nd_opt_prefix_info * int inconsistent = 0; char ntopbuf[INET6_ADDRSTRLEN]; char prefixbuf[INET6_ADDRSTRLEN]; - struct timeval now; + struct timespec now; #if 0 /* impossible */ if (pinfo->nd_opt_pi_type != ND_OPT_PREFIX_INFORMATION) @@ -1285,7 +1284,7 @@ prefix_check(struct nd_opt_prefix_info * * XXX: can we really expect that all routers on the link * have synchronized clocks? */ - gettimeofday(&now, NULL); + clock_gettime(CLOCK_MONOTONIC_FAST, &now); preferred_time += now.tv_sec; if (!pfx->pfx_timer && rai->rai_clockskew && @@ -1318,7 +1317,7 @@ prefix_check(struct nd_opt_prefix_info * valid_time = ntohl(pinfo->nd_opt_pi_valid_time); if (pfx->pfx_vltimeexpire) { - gettimeofday(&now, NULL); + clock_gettime(CLOCK_MONOTONIC_FAST, &now); valid_time += now.tv_sec; if (!pfx->pfx_timer && rai->rai_clockskew && @@ -1784,7 +1783,7 @@ ra_output(struct ifinfo *ifi) } /* update timestamp */ - gettimeofday(&ifi->ifi_ra_lastsent, NULL); + clock_gettime(CLOCK_MONOTONIC_FAST, &ifi->ifi_ra_lastsent); /* update counter */ ifi->ifi_rs_waitcount = 0; @@ -1866,7 +1865,7 @@ ra_timeout(void *arg) /* update RA timer */ void -ra_timer_update(void *arg, struct timeval *tm) +ra_timer_update(void *arg, struct timespec *tm) { uint16_t interval; struct rainfo *rai; @@ -1916,12 +1915,12 @@ ra_timer_update(void *arg, struct timeva } tm->tv_sec = interval; - tm->tv_usec = 0; + tm->tv_nsec = 0; syslog(LOG_DEBUG, "<%s> RA timer on %s is set to %ld:%ld", __func__, ifi->ifi_ifname, - (long int)tm->tv_sec, (long int)tm->tv_usec); + (long int)tm->tv_sec, (long int)tm->tv_nsec / 1000); return; } Modified: head/usr.sbin/rtadvd/rtadvd.h ============================================================================== --- head/usr.sbin/rtadvd/rtadvd.h Mon Aug 5 19:42:03 2013 (r253969) +++ head/usr.sbin/rtadvd/rtadvd.h Mon Aug 5 20:13:02 2013 (r253970) @@ -270,7 +270,7 @@ struct ifinfo { uint32_t ifi_burstinterval; struct rtadvd_timer *ifi_ra_timer; /* timestamp when the latest RA was sent */ - struct timeval ifi_ra_lastsent; + struct timespec ifi_ra_lastsent; uint16_t ifi_rs_waitcount; /* statistics */ @@ -286,7 +286,7 @@ extern TAILQ_HEAD(ifilist_head_t, ifinfo extern char *mcastif; struct rtadvd_timer *ra_timeout(void *); -void ra_timer_update(void *, struct timeval *); +void ra_timer_update(void *, struct timespec *); void ra_output(struct ifinfo *); int prefix_match(struct in6_addr *, int, Modified: head/usr.sbin/rtadvd/timer.c ============================================================================== --- head/usr.sbin/rtadvd/timer.c Mon Aug 5 19:42:03 2013 (r253969) +++ head/usr.sbin/rtadvd/timer.c Mon Aug 5 20:13:02 2013 (r253970) @@ -31,7 +31,6 @@ * SUCH DAMAGE. */ -#include #include #include @@ -44,6 +43,7 @@ #include #include #include +#include #include #include "rtadvd.h" @@ -52,12 +52,17 @@ struct rtadvd_timer_head_t ra_timer = TAILQ_HEAD_INITIALIZER(ra_timer); -static struct timeval tm_limit = {0x7fffffff, 0x7fffffff}; -static struct timeval tm_max; +static struct timespec tm_limit; +static struct timespec tm_max; void rtadvd_timer_init(void) { + /* Generate maximum time in timespec. */ + memset(&tm_limit.tv_sec, 0xff, sizeof(tm_limit.tv_sec)); + memset(&tm_limit.tv_nsec, 0xff, sizeof(tm_limit.tv_nsec)); + tm_limit.tv_sec &= ~(1UL << (sizeof(tm_limit.tv_sec) * 8 - 1)); + tm_limit.tv_nsec &= ~(1UL << (sizeof(tm_limit.tv_nsec) * 8 - 1)); tm_max = tm_limit; TAILQ_INIT(&ra_timer); @@ -102,7 +107,7 @@ rtadvd_update_timeout_handler(void) struct rtadvd_timer * rtadvd_add_timer(struct rtadvd_timer *(*timeout)(void *), - void (*update)(void *, struct timeval *), + void (*update)(void *, struct timespec *), void *timeodata, void *updatedata) { *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** ----Next_Part(Tue_Aug__6_05_30_57_2013_464)---- ----Security_Multipart0(Tue_Aug__6_05_30_57_2013_775)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEABECAAYFAlIAC4EACgkQTyzT2CeTzy3uHACfYYyQmnLxw+JonVpRfITE8dcY UjQAoMrMyRD8Aq/TVi7YkQjJpSB72y89 =ePPX -----END PGP SIGNATURE----- ----Security_Multipart0(Tue_Aug__6_05_30_57_2013_775)---- From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 21:01:54 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4676238C; Mon, 5 Aug 2013 21:01:54 +0000 (UTC) (envelope-from bryanv@daemoninthecloset.org) Received: from torment.daemoninthecloset.org (torment.daemoninthecloset.org [94.242.209.234]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F13EA27F2; Mon, 5 Aug 2013 21:01:53 +0000 (UTC) Received: from sage.daemoninthecloset.org (unknown [70.114.209.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sage.daemoninthecloset.org", Issuer "daemoninthecloset.org" (verified OK)) by torment.daemoninthecloset.org (Postfix) with ESMTPS id 5C61442C082F; Mon, 5 Aug 2013 23:06:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at daemoninthecloset.org X-Virus-Scanned: amavisd-new at daemoninthecloset.org Date: Mon, 5 Aug 2013 16:01:43 -0500 (CDT) From: Bryan Venteicher To: Luigi Rizzo Message-ID: <235239368.957.1375736503264.JavaMail.root@daemoninthecloset.org> In-Reply-To: References: <20130805082307.GA35162@onelab2.iet.unipi.it> <51FFDD1E.1000206@FreeBSD.org> Subject: Re: [net] protecting interfaces from races between control and data ? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.51.1.6] X-Mailer: Zimbra 8.0.2_GA_5569 (ZimbraWebClient - GC28 (Mac)/8.0.2_GA_5569) Thread-Topic: protecting interfaces from races between control and data ? Thread-Index: zrOts6xhU4hMZifeaT65P3z9acX4Vg== Cc: Adrian Chadd , FreeBSD current mailing list , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri , Jack Vogel 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, 05 Aug 2013 21:01:54 -0000 ----- Original Message ----- > On Mon, Aug 5, 2013 at 8:19 PM, Adrian Chadd wrote: > > > No, brian said two things: > > > > * the flag, protected by the core lock > > * per-queue flags > > > > i see no mentions on per-queue flags on his email. > This is the relevant part > Right, I just use the IFF_DRV_RUNNING flag. I think Adrian meant 'per-queue locks' here? > ------------ > > What I've done in my drivers is: > * Lock the core mutex > * Clear IFF_DRV_RUNNING > * Lock/unlock each queue's lock > > The various Rx/Tx queue functions check for IFF_DRV_RUNNING after > (re)acquiring their queue lock. See at vtnet_stop_rendezvous() at > [1] for an example. > > [1] > http://svnweb.freebsd.org/base/user/bryanv/vtnetmq/sys/dev/virtio/network/if_vtnet.c?revision=252451&view=markup > > ----------------- > > > > > > > > > > -adrian > > > > > > -- > -----------------------------------------+------------------------------- > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL +39-050-2211611 . via Diotisalvi 2 > Mobile +39-338-6809875 . 56122 PISA (Italy) > -----------------------------------------+------------------------------- > From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 21:04:56 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 087BF562 for ; Mon, 5 Aug 2013 21:04:56 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 38DCB2825 for ; Mon, 5 Aug 2013 21:04:54 +0000 (UTC) Received: (qmail 46896 invoked from network); 5 Aug 2013 21:50:50 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 5 Aug 2013 21:50:50 -0000 Message-ID: <5200136C.8000201@freebsd.org> Date: Mon, 05 Aug 2013 23:04:44 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: [net] protecting interfaces from races between control and data ? References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , current@freebsd.org, Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri 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, 05 Aug 2013 21:04:56 -0000 On 05.08.2013 19:36, Luigi Rizzo wrote: > On Mon, Aug 5, 2013 at 7:17 PM, Adrian Chadd wrote: > >> I'm travelling back to San Jose today; poke me tomorrow and I'll brain >> dump what I did in ath(4) and the lessons learnt. >> >> The TL;DR version - you don't want to grab an extra lock in the >> read/write paths as that slows things down. Reuse the same per-queue >> TX/RX lock and have: >> >> * a reset flag that is set when something is resetting; that says to >> the queue "don't bother processing anything, just dive out"; >> * 'i am doing Tx / Rx' flags per queue that is set at the start of >> TX/RX servicing and finishes at the end; that way the reset code knows >> if there's something pending; >> * have the reset path grab each lock, set the 'reset' flag on each, >> then walk each queue again and make sure they're all marked as 'not >> doing TX/RX'. At that point the reset can occur, then the flag cna be >> cleared, then TX/RX can resume. >> [picking a post at random to reply in this thread] > so this is slightly different from what Bryan suggested (and you endorsed) > before, as in that case there was a single 'reset' flag IFF_DRV_RUNNING > protected by the 'core' lock, then a nested round on all tx and rx locks > to make sure that all customers have seen it. > In both cases the tx and rx paths only need the per-queue lock. > > As i see it, having a per-queue reset flag removes the need for nesting > core + queue locks, but since this is only in the control path perhaps > it is not a big deal (and is better to have a single place to look at to > tell whether or not we should bail out). Ideally we don't want to have any locks in the RX and TX path at all. For the TX path this is not easy to achieve but for RX it isn't difficult at all provided the correct model is used. My upcoming stack/driver proposal is along these lines: RX with MSI-X: Every queue has its own separate RX interrupt vector which is serviced by a single dedicated ithread (or taskqueue) which does while(1) for work on the RX ring only going to sleep when it reaches the end of work on the ring. It is then woken up by an interrupt to resume work. To prevent a live-lock on the CPU it would periodically yield to allow other kernel and user-space threads to run in between. Each queue's ithread (taskqueue) can be pinned to a particular core or float with a certain stickiness. To reconfigure the card (when the RX ring is affected) the ithread (taskqueue) is terminated and after the changes restarted again. This is done by the control path and allows us to run RX completely lock free because there is only ever one ithread accessing the RX queue doing away with the need for further locking synchronization. RX with MSI or legacy interrupts: Here multi-queue is impeded because of some synchronization issues. Depending on the hardware synchronization model the ithreads again do while(1) but have to be made runnable by the interrupt handler when new work has been indicated. TX in general: This is a bit more tricky as we have the hard requirement of packet ordering for individual sessions (tcp and others). That means we must use the same queue for all packets of the same session. This makes running TX non-locked a bit tricky because when we pin a TX queue to a core we must switch to that core first before adding anything to the queue. If the packet was generated on that core there is no overhead, OTOH if not there is the scheduler over- head and some cache losses. Ensuring that a the entire TX path, possibly including user-space (write et al) happens on the same core is difficult and may have its own inefficiencies. The number of TX queue vs. number of cores is another point of contention. To make the 1:1 scheme work well, one must have as many queues as cores. A more scalable and generic approach doesn't bind TX queues to any particular core and is covers each by its own lock to protect the TX ring enqueue. To prevent false lock cache line sharing each TX structure should be on its own cache line. As each session has an affinity hash they become distributed across the TX queues significantly reducing contention. The TX complete handling freeing the mbuf(s) is done the same way as for the RX ring with a dedicated ithread (taskqueue) for each. Also bpf should hook in here (the packet has been sent) instead of at the TX enqueue time. The whole concept of IFF_DRV_RUNNING will go away along with the IFQ macros. Each driver then provides a direct TX function pointer which is put into a decoupled ifnet TX field for use by the stack. Under normal operation all interface TX goes directly into TX DMA ring. The particular multi-queue and locking model is decided by the driver. The kernel provides a couple of common optimized abstractions for use by all drivers that want/need it to avoid code and functionality duplication. When things like ALTQ are activated on an interface the ifnet TX function pointer is replaced with the appropriate intermediate function pointer which eventually will call the drivers TX function. The intermediate TX packet handler (ALTQ) can do its own additional locking on top of the drivers TX locking. Control path: The control path is separate from the high speed TX and RX data paths. It has its own overall lock. Multiple locks typically don't make sense here. If it needs to modify, reconfigure, or newly set up the TX or RX rings then it has to stop the RX ithreads (taskqueues) and to lock the TX queue locks before it can do that. After the changes are made and stable packet processing can continue. I've adjusted / heavily modified fxp, bge and igb drivers in my tcp_workqueue branch to test these concepts. Not all of it is committed or fully up to date. -- Andre From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 21:48:57 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 79E5D7C7; Mon, 5 Aug 2013 21:48:57 +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 C321A2A2A; Mon, 5 Aug 2013 21:48:56 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id E2FC47300A; Mon, 5 Aug 2013 23:53:19 +0200 (CEST) Date: Mon, 5 Aug 2013 23:53:19 +0200 From: Luigi Rizzo To: Andre Oppermann Subject: Re: [net] protecting interfaces from races between control and data ? Message-ID: <20130805215319.GA43271@onelab2.iet.unipi.it> References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> <5200136C.8000201@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5200136C.8000201@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Adrian Chadd , current@freebsd.org, Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri 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, 05 Aug 2013 21:48:57 -0000 On Mon, Aug 05, 2013 at 11:04:44PM +0200, Andre Oppermann wrote: > On 05.08.2013 19:36, Luigi Rizzo wrote: ... > > [picking a post at random to reply in this thread] > > tell whether or not we should bail out). > > Ideally we don't want to have any locks in the RX and TX path at all. Ok i have read your proposal below but there are a few things I do not completely understand, below -- essentially I do not understand whether the removal of IFF_DRV_RUNNING (or equivalent) forces you to replace the ifp->new_tx_function() with something else when you want to do an "ifconfig down" Specifically, here are my doubts: - Considering that the rxq lock is rarely contended (only when the control path is active, which in your approach below requires killing and restarting the ithread), and is acquired/released only once per interrupt/batch, i am under the impression that the per-queue RX lock is not a performance problem and makes it easier to reason on the code (and does not require different approach for MSI-x and other cases). - in the tx datapath, do you want to acquire the txq lock before or after calling ifp->new_tx_function() ? (btw how it compares to ifp->if_start or ifp->if_transmit ?) If you do it within the tx handler then you lose the ability of replacing the handler when you do a reconfiguration, because grabbing the tx lock in the control path does not tell you whether anyone is in the handler. If you do it outside, then the driver should also expose the locks, or some locking function. Overall, it seems to me that keeping the IFF_DRV_RUNNING flag is a lot more practical, not to mention fewer modifications to the code. [description of Andre's proposal below, for reference] cheers luigi > Every queue has its own separate RX interrupt vector which is serviced by > a single dedicated ithread (or taskqueue) which does while(1) for work on > the RX ring only going to sleep when it reaches the end of work on the ring. > It is then woken up by an interrupt to resume work. To prevent a live-lock > on the CPU it would periodically yield to allow other kernel and user-space > threads to run in between. Each queue's ithread (taskqueue) can be pinned > to a particular core or float with a certain stickiness. To reconfigure the > card (when the RX ring is affected) the ithread (taskqueue) is terminated > and after the changes restarted again. This is done by the control path > and allows us to run RX completely lock free because there is only ever one > ithread accessing the RX queue doing away with the need for further locking > synchronization. ok I admit i did not think of killing and restarting the ithread, but i wonder how > RX with MSI or legacy interrupts: > > Here multi-queue is impeded because of some synchronization issues. Depending > on the hardware synchronization model the ithreads again do while(1) but have > to be made runnable by the interrupt handler when new work has been indicated. > > TX in general: > > This is a bit more tricky as we have the hard requirement of packet ordering > for individual sessions (tcp and others). That means we must use the same > queue for all packets of the same session. This makes running TX non-locked > a bit tricky because when we pin a TX queue to a core we must switch to that > core first before adding anything to the queue. If the packet was generated > on that core there is no overhead, OTOH if not there is the scheduler over- > head and some cache losses. Ensuring that a the entire TX path, possibly > including user-space (write et al) happens on the same core is difficult and > may have its own inefficiencies. The number of TX queue vs. number of cores > is another point of contention. To make the 1:1 scheme work well, one must > have as many queues as cores. > > A more scalable and generic approach doesn't bind TX queues to any particular > core and is covers each by its own lock to protect the TX ring enqueue. To > prevent false lock cache line sharing each TX structure should be on its own > cache line. As each session has an affinity hash they become distributed > across the TX queues significantly reducing contention. > > The TX complete handling freeing the mbuf(s) is done the same way as for the > RX ring with a dedicated ithread (taskqueue) for each. Also bpf should hook > in here (the packet has been sent) instead of at the TX enqueue time. > > The whole concept of IFF_DRV_RUNNING will go away along with the IFQ macros. > Each driver then provides a direct TX function pointer which is put into a > decoupled ifnet TX field for use by the stack. Under normal operation all > interface TX goes directly into TX DMA ring. The particular multi-queue > and locking model is decided by the driver. The kernel provides a couple > of common optimized abstractions for use by all drivers that want/need it > to avoid code and functionality duplication. When things like ALTQ are > activated on an interface the ifnet TX function pointer is replaced with > the appropriate intermediate function pointer which eventually will call > the drivers TX function. The intermediate TX packet handler (ALTQ) can > do its own additional locking on top of the drivers TX locking. > > Control path: > > The control path is separate from the high speed TX and RX data paths. > It has its own overall lock. Multiple locks typically don't make sense > here. If it needs to modify, reconfigure, or newly set up the TX or RX > rings then it has to stop the RX ithreads (taskqueues) and to lock the > TX queue locks before it can do that. After the changes are made and > stable packet processing can continue. > > I've adjusted / heavily modified fxp, bge and igb drivers in my tcp_workqueue > branch to test these concepts. Not all of it is committed or fully up to date. > > -- > Andre > From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 22:52:12 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id ED03B6B3; Mon, 5 Aug 2013 22:52:12 +0000 (UTC) (envelope-from bryanv@daemoninthecloset.org) Received: from torment.daemoninthecloset.org (torment.daemoninthecloset.org [94.242.209.234]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AE6532C60; Mon, 5 Aug 2013 22:52:12 +0000 (UTC) Received: from sage.daemoninthecloset.org (unknown [70.114.209.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sage.daemoninthecloset.org", Issuer "daemoninthecloset.org" (verified OK)) by torment.daemoninthecloset.org (Postfix) with ESMTPS id 5CA1742C082F; Tue, 6 Aug 2013 00:56:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at daemoninthecloset.org X-Virus-Scanned: amavisd-new at daemoninthecloset.org Date: Mon, 5 Aug 2013 17:52:01 -0500 (CDT) From: Bryan Venteicher To: Joel Dahl Message-ID: <1174186801.993.1375743121722.JavaMail.root@daemoninthecloset.org> In-Reply-To: <20130805202039.GA18861@devbox.vnode.local> References: <1050637258.686.1375660230986.JavaMail.root@daemoninthecloset.org> <601099152.721.1375661537866.JavaMail.root@daemoninthecloset.org> <20130805202039.GA18861@devbox.vnode.local> Subject: Re: [CFT] VMware vmxnet3 ethernet driver MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.51.1.6] X-Mailer: Zimbra 8.0.2_GA_5569 (ZimbraWebClient - GC28 (Mac)/8.0.2_GA_5569) Thread-Topic: VMware vmxnet3 ethernet driver Thread-Index: XglhsYXvJ+VZ70khzgi9CYN8S8Swgg== Cc: 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, 05 Aug 2013 22:52:13 -0000 ----- Original Message ----- > I have ~100 FreeBSD 8/9 VMs in my vSphere 5.1 environment, all using the > VMware tools package from VMware. Everything has been running great for > years. > (we skipped vSphere 5.0). Why should I use this vmxnet driver instead of the > VMware tools driver or the emulated e1000? > They are out of tree and subject to rotting. I had to use the patches at [1] to even get them to compile on 9.1 and -current. I don't think VMware puts much engineering resources behind it; there was a compiler warning of a silly bug like: if (foo) ; do_something(); vmxnet3 has modern features LRO, IPv6 checksum offloading, etc that the emulated e1000 lacks. In my test setup, e1000 tops out at 30MB/sec but vmxnet3 goes to 50MB/sec. I'd like to hear other's experiences. [1] - http://ogris.de/vmware/ > -- > Joel > From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 22:57:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id ECEEF8AF for ; Mon, 5 Aug 2013 22:57:24 +0000 (UTC) (envelope-from mack@macktronics.com) Received: from borg.macktronics.com (borg.macktronics.com [209.181.253.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C48872C91 for ; Mon, 5 Aug 2013 22:57:24 +0000 (UTC) Received: from olive.macktronics.com (olive.macktronics.com [209.181.253.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by borg.macktronics.com (Postfix) with ESMTPS id 9E6792FB for ; Mon, 5 Aug 2013 17:49:03 -0500 (CDT) Date: Mon, 5 Aug 2013 17:49:01 -0500 (CDT) From: Dan Mack To: freebsd-current@freebsd.org Subject: LOR on head ... Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII 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, 05 Aug 2013 22:57:25 -0000 Not sure if this is a known issue since I don't usually use UFS. Yesterday I put current on an acer laptop with an i3 processor/4GB RAM with UFS file system on a OCZ vertex 2 SSD and trim enabled via tunefs. Below is the dmesg along with the LOR message at the bottom. I can provide more information if it is helpful. Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #0: Sun Aug 4 16:54:51 UTC 2013 root@beam.macktronics.com:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Core(TM) i3-2370M CPU @ 2.40GHz (2394.61-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x206a7 Family = 0x6 Model = 0x2a Stepping = 7 Features=0xbfebfbff Features2=0x1dbae3bf AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 3785801728 (3610 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x2000-0x203f mem 0xc0000000-0xc03fffff,0xb0000000-0xbfffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: aperture size is 256M, detected 131068k stolen memory pci0: at device 22.0 (no driver attached) ehci0: mem 0xc0609000-0xc06093ff irq 16 at device 26.0 on pci0 usbus0: EHCI version 1.0 usbus0 on ehci0 hdac0: mem 0xc0600000-0xc0603fff irq 22 at device 27.0 on pci0 pcib1: irq 17 at device 28.0 on pci0 pci2: on pcib1 bge0: mem 0xc0430000-0xc043ffff,0xc0440000-0xc044ffff irq 16 at device 0.0 on pci2 bge0: CHIP ID 0x57785100; ASIC REV 0x57785; CHIP REV 0x577851; PCI-E miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: Ethernet address: dc:0e:a1:b1:e8:d4 sdhci_pci0: mem 0xc0400000-0xc040ffff irq 17 at device 0.1 on pci2 sdhci_pci0: 1 slot(s) allocated pci2: at device 0.2 (no driver attached) pci2: at device 0.3 (no driver attached) pcib2: irq 16 at device 28.1 on pci0 pci3: on pcib2 ath0: mem 0xc0500000-0xc057ffff irq 17 at device 0.0 on pci3 ar9300_set_stub_functions: setting stub functions ar9300_set_stub_functions: setting stub functions ar9300_attach: calling ar9300_hw_attach ar9300_hw_attach: calling ar9300_eeprom_attach ar9300_flash_map: unimplemented for now Restoring Cal data from DRAM Restoring Cal data from EEPROM Restoring Cal data from Flash Restoring Cal data from Flash Restoring Cal data from OTP ar9300_hw_attach: ar9300_eeprom_attach returned 0 ath0: RX status length: 48 ath0: RX buffer size: 4096 ath0: TX descriptor length: 128 ath0: TX status length: 36 ath0: TX buffers per descriptor: 4 ar9300_freebsd_setup_x_tx_desc: called, 0x0/0, 0x0/0, 0x0/0 ath0: ath_edma_setup_rxfifo: type=0, FIFO depth = 16 entries ath0: ath_edma_setup_rxfifo: type=1, FIFO depth = 128 entries ath0: [HT] enabling HT modes ath0: [HT] enabling short-GI in 20MHz mode ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 RX streams; 1 TX streams ath0: AR9485 mac 576.1 RF5110 phy 829.5 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000 ehci1: mem 0xc0608000-0xc06083ff irq 23 at device 29.0 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci1 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0x2088-0x208f,0x2094-0x2097,0x2080-0x2087,0x2090-0x2093,0x2060-0x207f mem 0xc0607000-0xc06077ff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich2: at channel 2 on ahci0 ahciem0: on ahci0 pci0: at device 31.3 (no driver attached) atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 battery0: on acpi0 acpi_acad0: on acpi0 acpi_button0: on acpi0 acpi_lid0: on acpi0 acpi_button1: on acpi0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 est2: on cpu2 p4tcc2: on cpu2 est3: on cpu3 p4tcc3: on cpu3 Timecounters tick every 1.000 msec hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 20,33 and 27 on hdaa0 pcm1: at nid 24 on hdaa0 hdacc1: at cad 3 on hdac0 hdaa1: at nid 1 on hdacc1 pcm2: at nid 5 on hdaa1 usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 76319MB (156301488 512 byte sectors: 16H 63S/T 16383C) ada0: quirks=0x1<4K> ada0: Previously was known as ad4 ses0 at ahciem0 bus 0 scbus2 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device cd0 at ahcich2 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! Timecounter "TSC-low" frequency 1197304466 Hz quality 1000 WARNING: WITNESS option enabled, expect reduced performance. Root mount waiting for: usbus1 usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered Root mount waiting for: usbus1 usbus0 ugen0.2: at usbus0 uhub2: on usbus0 ugen1.2: at usbus1 uhub3: on usbus1 Root mount waiting for: usbus1 usbus0 uhub2: 6 ports with 6 removable, self powered uhub3: 8 ports with 8 removable, self powered ugen0.3: at usbus0 Trying to mount root from ufs:/dev/gpt/acer1 [rw]... ar9300_Stub_GetCTSTimeout: called ar9300_Stub_GetCTSTimeout: called ar9300_Stub_GetAntennaSwitch: called ar9300_Stub_GetAntennaSwitch: called wlan0: Ethernet address: 44:6d:57:91:61:3d lock order reversal: 1st 0xffffff80ec5844e0 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3061 2nd 0xfffffe0046273200 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff81166ca2d0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff81166ca380 witness_checkorder() at witness_checkorder+0xd4f/frame 0xffffff81166ca410 _sx_xlock() at _sx_xlock+0x75/frame 0xffffff81166ca450 ufsdirhash_add() at ufsdirhash_add+0x3b/frame 0xffffff81166ca490 ufs_direnter() at ufs_direnter+0x688/frame 0xffffff81166ca550 ufs_rename() at ufs_rename+0xedb/frame 0xffffff81166ca760 VOP_RENAME_APV() at VOP_RENAME_APV+0xf5/frame 0xffffff81166ca790 kern_renameat() at kern_renameat+0x3df/frame 0xffffff81166ca9a0 amd64_syscall() at amd64_syscall+0x265/frame 0xffffff81166caab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xffffff81166caab0 --- syscall (128, FreeBSD ELF64, sys_rename), rip = 0x801c509ca, rsp = 0x7fffffffccb8, rbp = 0x7fffffffccc0 --- dan -- Dan Mack From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 23:24:27 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 60F6BBD1 for ; Mon, 5 Aug 2013 23:24:27 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 106062D70 for ; Mon, 5 Aug 2013 23:24:26 +0000 (UTC) Received: by mail-ve0-f180.google.com with SMTP id pb11so3767464veb.39 for ; Mon, 05 Aug 2013 16:24:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7kzahkxaioUH58spF2j/WYc1OULuksUrUe9qEtPWdg0=; b=MONgd8YZMZtq7yb3SRlu1LuUsC+y7ho0zHtBoG0JyyIDXOzh382q8rnc5E90s6jEb/ hOp2Evxk4/YPsEd+uLRjRkPPgBAVu/V0nRCtsoQAo5y8Rbu9ZC69LjoDFOF42ozLGCF4 g6uL7gKLJ2SaIncm5GMLO9SidVXOWrQlZ95ZMhsCFY7+sjflI71vns+mN/mo4qoPDnyE hJvAvJKJ6eq1RX42935+tjySADMCritGB3U9VRtRY6NWyusgBroETg/UI/37no3BVHGD yTRtOYMTmqpXRb9vkeDqSGcubQEyTRAsQA/L7u8hrEwWkuOvcTJeQDCNa+bL1nekEUvV qO3g== MIME-Version: 1.0 X-Received: by 10.58.135.167 with SMTP id pt7mr6457352veb.75.1375745066115; Mon, 05 Aug 2013 16:24:26 -0700 (PDT) Received: by 10.220.96.78 with HTTP; Mon, 5 Aug 2013 16:24:26 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 Aug 2013 19:24:26 -0400 Message-ID: Subject: Re: LOR on head ... From: "Sam Fourman Jr." To: Dan Mack Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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, 05 Aug 2013 23:24:27 -0000 I am going to respond to this before I forget.... I had the SAME exact LOR's with ath 9300 and I reported them, however I have since switched out motherboards and the LOR's have strangely diapered here is a full dmesg for a perfectly working system FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 CPU: AMD FX(tm)-4100 Quad-Core Processor (3600.30-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x600f12 Family = 0x15 Model = 0x1 Stepping = 2 Features=0x178bfbff Features2=0x1e98220b AMD Features=0x2e500800 AMD Features2=0x1c9bfff,> TSC: P-state invariant, performance statistics real memory = 8589934592 (8192 MB) avail memory = 7868518400 (7504 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 16 cpu1 (AP): APIC ID: 17 cpu2 (AP): APIC ID: 18 cpu3 (AP): APIC ID: 19 ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has zero address or length: 0x0000000000000000/0x1 (20130725/tbfadt-630) ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-55 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 450 Event timer "HPET2" frequency 14318180 Hz quality 450 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.2 (no driver attached) pcib1: irq 52 at device 2.0 on pci0 pci1: on pcib1 vgapci0: mem 0xfd000000-0xfdffffff,0xc0000000-0xcfffffff,0xfc000000-0xfcffffff irq 24 at device 0.0 on pci1 pcib2: irq 52 at device 4.0 on pci0 pci2: on pcib2 re0: port 0xe000-0xe0ff mem 0xd0004000-0xd0004fff,0xd0000000-0xd0003fff irq 44 at device 0.0 on pci2 re0: Using 1 MSI-X message re0: Chip rev. 0x48000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 60:a4:4c:57:02:c4 pcib3: irq 52 at device 5.0 on pci0 pci3: on pcib3 xhci0: mem 0xfe400000-0xfe407fff irq 46 at device 0.0 on pci3 xhci0: 32 byte context size. usbus0 on xhci0 pcib4: irq 53 at device 7.0 on pci0 pci4: on pcib4 xhci1: mem 0xfe300000-0xfe307fff irq 50 at device 0.0 on pci4 xhci1: 32 byte context size. usbus1 on xhci1 pcib5: irq 53 at device 9.0 on pci0 pci5: on pcib5 ath0: mem 0xfe200000-0xfe21ffff irq 48 at device 0.0 on pci5 ar9300_set_stub_functions: setting stub functions ar9300_set_stub_functions: setting stub functions ar9300_attach: calling ar9300_hw_attach ar9300_hw_attach: calling ar9300_eeprom_attach ar9300_flash_map: unimplemented for now Restoring Cal data from DRAM Restoring Cal data from EEPROM ar9300_hw_attach: ar9300_eeprom_attach returned 0 ath0: RX status length: 48 ath0: RX buffer size: 4096 ath0: TX descriptor length: 128 ath0: TX status length: 36 ath0: TX buffers per descriptor: 4 ar9300_freebsd_setup_x_tx_desc: called, 0x0/0, 0x0/0, 0x0/0 ath0: ath_edma_setup_rxfifo: type=0, FIFO depth = 16 entries ath0: ath_edma_setup_rxfifo: type=1, FIFO depth = 128 entries ath0: [HT] enabling HT modes ath0: [HT] enabling short-GI in 20MHz mode ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 stream STBC transmit enabled ath0: [HT] 3 RX streams; 3 TX streams ath0: AR9380 mac 448.3 RF5110 phy 0.0 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000 ahci0: port 0xf040-0xf047,0xf030-0xf033,0xf020-0xf027,0xf010-0xf013,0xf000-0xf00f mem 0xfe50b000-0xfe50b3ff irq 19 at device 17.0 on pci0 ahci0: AHCI v1.20 with 3 6Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich2: at channel 2 on ahci0 ahcich5: at channel 5 on ahci0 ohci0: mem 0xfe50a000-0xfe50afff irq 18 at device 18.0 on pci0 usbus2 on ohci0 ehci0: mem 0xfe509000-0xfe5090ff irq 17 at device 18.2 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 ohci1: mem 0xfe508000-0xfe508fff irq 20 at device 19.0 on pci0 usbus4 on ohci1 ehci1: mem 0xfe507000-0xfe5070ff irq 21 at device 19.2 on pci0 usbus5: EHCI version 1.0 usbus5 on ehci1 pci0: at device 20.0 (no driver attached) pci0: at device 20.2 (no driver attached) isab0: at device 20.3 on pci0 isa0: on isab0 pcib6: at device 20.4 on pci0 pci6: on pcib6 re1: port 0xd100-0xd1ff mem 0xfe141000-0xfe1410ff irq 20 at device 5.0 on pci6 re1: Chip rev. 0x10000000 re1: MAC rev. 0x00000000 miibus1: on re1 rgephy1: PHY 1 on miibus1 rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re1: Ethernet address: 00:14:d1:25:d8:23 re2: port 0xd000-0xd0ff mem 0xfe140000-0xfe1400ff irq 21 at device 6.0 on pci6 re2: Chip rev. 0x10000000 re2: MAC rev. 0x00000000 miibus2: on re2 rgephy2: PHY 1 on miibus2 rgephy2: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re2: Ethernet address: 00:14:d1:25:d8:44 ohci2: mem 0xfe506000-0xfe506fff irq 18 at device 20.5 on pci0 usbus6 on ohci2 ohci3: mem 0xfe505000-0xfe505fff irq 22 at device 22.0 on pci0 usbus7 on ohci3 ehci2: mem 0xfe504000-0xfe5040ff irq 23 at device 22.2 on pci0 usbus8: EHCI version 1.0 usbus8 on ehci2 acpi_button0: on acpi0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] ppc0: cannot reserve I/O port range acpi_throttle0: on cpu0 hwpstate0: on cpu0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 acpi_throttle2: on cpu2 acpi_throttle2: failed to attach P_CNT device_attach: acpi_throttle2 attach returned 6 acpi_throttle3: on cpu3 acpi_throttle3: failed to attach P_CNT device_attach: acpi_throttle3 attach returned 6 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec usbus0: 5.0Gbps Super Speed USB v3.0 usbus1: 5.0Gbps Super Speed USB v3.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 480Mbps High Speed USB v2.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 12Mbps Full Speed USB v1.0 usbus8: 480Mbps High Speed USB v2.0 ugen0.1: <0x1b21> at usbus0 uhub0: <0x1b21 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 ugen3.1: at usbus3 uhub1: on usbus3 ugen2.1: at usbus2 uhub2: on usbus2 ugen1.1: <0x1b21> at usbus1 uhub3: <0x1b21 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus1 ugen6.1: at usbus6 uhub4: on usbus6 ugen5.1: at usbus5 uhub5: on usbus5 ugen4.1: at usbus4 uhub6: on usbus4 ugen8.1: at usbus8 uhub7: on usbus8 ugen7.1: at usbus7 uhub8: on usbus7 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-7 SATA 1.x device ada0: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) ada0: 38166MB (78165360 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 ada1 at ahcich2 bus 0 scbus1 target 0 lun 0 ada1: ATA-7 SATA 1.x device ada1: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 38166MB (78165360 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad6 ada2 at ahcich5 bus 0 scbus2 target 0 lun 0 ada2: ATA-7 SATA 1.x device ada2: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) ada2: 38166MB (78165360 512 byte sectors: 16H 63S/T 16383C) ada2: Previously was known as ad8 SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! Timecounter "TSC-low" frequency 1800148234 Hz quality 1000 uhub4: 2 ports with 2 removable, self powered uhub8: 4 ports with 4 removable, self powered uhub6: 5 ports with 5 removable, self powered uhub2: 5 ports with 5 removable, self powered uhub0: 4 ports with 4 removable, self powered uhub3: 4 ports with 4 removable, self powered GEOM: ada2: the secondary GPT table is corrupt or invalid. GEOM: ada2: using the primary only -- recovery suggested. GEOM: diskid/DISK-MDT-MCANKK515312: the secondary GPT table is corrupt or invalid. GEOM: diskid/DISK-MDT-MCANKK515312: using the primary only -- recovery suggested. Root mount waiting for: usbus8 usbus5 usbus3 Root mount waiting for: usbus8 usbus5 usbus3 uhub7: 4 ports with 4 removable, self powered uhub5: 5 ports with 5 removable, self powered uhub1: 5 ports with 5 removable, self powered Trying to mount root from zfs:Puffy []... ugen4.2: at usbus4 ukbd0: on usbus4 kbd2 at ukbd0 ar9300_Stub_GetCTSTimeout: called ar9300_Stub_GetCTSTimeout: called ar9300_Stub_GetAntennaSwitch: called ar9300_Stub_GetAntennaSwitch: called wlan0: Ethernet address: 7c:c3:a1:b3:fc:af uhid0: on usbus4 uhid1: on usbus4 root@Border:~ # uptime 11:20PM up 15:06, 1 user, load averages: 0.34, 0.33, 0.25 -- Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 23:32:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 468C6D5F for ; Mon, 5 Aug 2013 23:32:12 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vb0-x22c.google.com (mail-vb0-x22c.google.com [IPv6:2607:f8b0:400c:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0663C2DBA for ; Mon, 5 Aug 2013 23:32:11 +0000 (UTC) Received: by mail-vb0-f44.google.com with SMTP id e13so3501875vbg.3 for ; Mon, 05 Aug 2013 16:32:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=G8cGB7NgqLefTNmedUNBEbcVezJXq1ljh2dMlJGJZG0=; b=cb4taKRjDz8nuhXgXa08FQ2H7bQvn2X5GIId8K5vfZ4dfT6SnHZC6ZrQllfdkADn+l 3AqjYKGaSo1wSCLJ9IzuDCKzNFhr9f9VCX6jPp9CMORdObbyfpOq2j55Fz0GncQigUPb y50l3hjFZrJnmRuJ/I3FGri+NJDYzLCkvaZUd3WAiLG8tT1KYhHbC72UeKEHoRgOIq6b uojX0IW+CsQ+WCLjq3Q6TlLPwkrxNi538PXbwm6TiIJn7QEGTbGPwlKL+rt6vfBmGLkp 1j6ZSSILVVluh32o7S6Zo6hiiUBKw/71TMWdpHKhAhYCXrML2DDTI+7122lYMox9qOA9 WUUg== MIME-Version: 1.0 X-Received: by 10.220.182.193 with SMTP id cd1mr6630420vcb.32.1375745530275; Mon, 05 Aug 2013 16:32:10 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.220.21.140 with HTTP; Mon, 5 Aug 2013 16:32:09 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 Aug 2013 16:32:09 -0700 X-Google-Sender-Auth: -yIiXe6EbQWwrxyJGXz_d19dKas Message-ID: Subject: Re: LOR on head ... From: Davide Italiano To: "Sam Fourman Jr." Content-Type: text/plain; charset=ISO-8859-1 Cc: Dan Mack , 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, 05 Aug 2013 23:32:12 -0000 On Mon, Aug 5, 2013 at 4:24 PM, Sam Fourman Jr. wrote: > I am going to respond to this before I forget.... > > I had the SAME exact LOR's with ath 9300 and I reported them, > however I have since switched out motherboards and the LOR's have strangely > diapered > > > here is a full dmesg for a perfectly working system > > FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 > CPU: AMD FX(tm)-4100 Quad-Core Processor (3600.30-MHz K8-class > CPU) > Origin = "AuthenticAMD" Id = 0x600f12 Family = 0x15 Model = 0x1 > Stepping = 2 > > Features=0x178bfbff > > Features2=0x1e98220b > AMD Features=0x2e500800 > AMD > Features2=0x1c9bfff,> > TSC: P-state invariant, performance statistics > real memory = 8589934592 (8192 MB) > avail memory = 7868518400 (7504 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > FreeBSD/SMP: 1 package(s) x 4 core(s) > cpu0 (BSP): APIC ID: 16 > cpu1 (AP): APIC ID: 17 > cpu2 (AP): APIC ID: 18 > cpu3 (AP): APIC ID: 19 > ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has zero > address or length: 0x0000000000000000/0x1 (20130725/tbfadt-630) > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-55 on motherboard > kbd1 at kbdmux0 > acpi0: on motherboard > acpi0: Power Button (fixed) > cpu0: on acpi0 > cpu1: on acpi0 > cpu2: on acpi0 > cpu3: on acpi0 > attimer0: port 0x40-0x43 irq 0 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > atrtc0: port 0x70-0x71 irq 8 on acpi0 > Event timer "RTC" frequency 32768 Hz quality 0 > hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 950 > Event timer "HPET" frequency 14318180 Hz quality 450 > Event timer "HPET1" frequency 14318180 Hz quality 450 > Event timer "HPET2" frequency 14318180 Hz quality 450 > Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > acpi_ec0: port 0x62,0x66 on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: at device 0.2 (no driver attached) > pcib1: irq 52 at device 2.0 on pci0 > pci1: on pcib1 > vgapci0: mem > 0xfd000000-0xfdffffff,0xc0000000-0xcfffffff,0xfc000000-0xfcffffff irq 24 at > device 0.0 on pci1 > pcib2: irq 52 at device 4.0 on pci0 > pci2: on pcib2 > re0: port > 0xe000-0xe0ff mem 0xd0004000-0xd0004fff,0xd0000000-0xd0003fff irq 44 at > device 0.0 on pci2 > re0: Using 1 MSI-X message > re0: Chip rev. 0x48000000 > re0: MAC rev. 0x00000000 > miibus0: on re0 > rgephy0: PHY 1 on miibus0 > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, > 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, > 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow > re0: Ethernet address: 60:a4:4c:57:02:c4 > pcib3: irq 52 at device 5.0 on pci0 > pci3: on pcib3 > xhci0: mem 0xfe400000-0xfe407fff irq > 46 at device 0.0 on pci3 > xhci0: 32 byte context size. > usbus0 on xhci0 > pcib4: irq 53 at device 7.0 on pci0 > pci4: on pcib4 > xhci1: mem 0xfe300000-0xfe307fff irq > 50 at device 0.0 on pci4 > xhci1: 32 byte context size. > usbus1 on xhci1 > pcib5: irq 53 at device 9.0 on pci0 > pci5: on pcib5 > ath0: mem 0xfe200000-0xfe21ffff irq 48 at device 0.0 on > pci5 > ar9300_set_stub_functions: setting stub functions > ar9300_set_stub_functions: setting stub functions > ar9300_attach: calling ar9300_hw_attach > ar9300_hw_attach: calling ar9300_eeprom_attach > ar9300_flash_map: unimplemented for now > Restoring Cal data from DRAM > Restoring Cal data from EEPROM > ar9300_hw_attach: ar9300_eeprom_attach returned 0 > ath0: RX status length: 48 > ath0: RX buffer size: 4096 > ath0: TX descriptor length: 128 > ath0: TX status length: 36 > ath0: TX buffers per descriptor: 4 > ar9300_freebsd_setup_x_tx_desc: called, 0x0/0, 0x0/0, 0x0/0 > ath0: ath_edma_setup_rxfifo: type=0, FIFO depth = 16 entries > ath0: ath_edma_setup_rxfifo: type=1, FIFO depth = 128 entries > ath0: [HT] enabling HT modes > ath0: [HT] enabling short-GI in 20MHz mode > ath0: [HT] 1 stream STBC receive enabled > ath0: [HT] 1 stream STBC transmit enabled > ath0: [HT] 3 RX streams; 3 TX streams > ath0: AR9380 mac 448.3 RF5110 phy 0.0 > ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000 > ahci0: port > 0xf040-0xf047,0xf030-0xf033,0xf020-0xf027,0xf010-0xf013,0xf000-0xf00f mem > 0xfe50b000-0xfe50b3ff irq 19 at device 17.0 on pci0 > ahci0: AHCI v1.20 with 3 6Gbps ports, Port Multiplier supported > ahcich0: at channel 0 on ahci0 > ahcich2: at channel 2 on ahci0 > ahcich5: at channel 5 on ahci0 > ohci0: mem 0xfe50a000-0xfe50afff irq > 18 at device 18.0 on pci0 > usbus2 on ohci0 > ehci0: mem 0xfe509000-0xfe5090ff > irq 17 at device 18.2 on pci0 > usbus3: EHCI version 1.0 > usbus3 on ehci0 > ohci1: mem 0xfe508000-0xfe508fff irq > 20 at device 19.0 on pci0 > usbus4 on ohci1 > ehci1: mem 0xfe507000-0xfe5070ff > irq 21 at device 19.2 on pci0 > usbus5: EHCI version 1.0 > usbus5 on ehci1 > pci0: at device 20.0 (no driver attached) > pci0: at device 20.2 (no driver attached) > isab0: at device 20.3 on pci0 > isa0: on isab0 > pcib6: at device 20.4 on pci0 > pci6: on pcib6 > re1: port > 0xd100-0xd1ff mem 0xfe141000-0xfe1410ff irq 20 at device 5.0 on pci6 > re1: Chip rev. 0x10000000 > re1: MAC rev. 0x00000000 > miibus1: on re1 > rgephy1: PHY 1 on miibus1 > rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, > 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, > 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, > 1000baseT-FDX-flow-master, auto, auto-flow > re1: Ethernet address: 00:14:d1:25:d8:23 > re2: port > 0xd000-0xd0ff mem 0xfe140000-0xfe1400ff irq 21 at device 6.0 on pci6 > re2: Chip rev. 0x10000000 > re2: MAC rev. 0x00000000 > miibus2: on re2 > rgephy2: PHY 1 on miibus2 > rgephy2: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, > 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, > 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, > 1000baseT-FDX-flow-master, auto, auto-flow > re2: Ethernet address: 00:14:d1:25:d8:44 > ohci2: mem 0xfe506000-0xfe506fff irq > 18 at device 20.5 on pci0 > usbus6 on ohci2 > ohci3: mem 0xfe505000-0xfe505fff irq > 22 at device 22.0 on pci0 > usbus7 on ohci3 > ehci2: mem 0xfe504000-0xfe5040ff > irq 23 at device 22.2 on pci0 > usbus8: EHCI version 1.0 > usbus8 on ehci2 > acpi_button0: on acpi0 > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > ppc0: cannot reserve I/O port range > acpi_throttle0: on cpu0 > hwpstate0: on cpu0 > acpi_throttle1: on cpu1 > acpi_throttle1: failed to attach P_CNT > device_attach: acpi_throttle1 attach returned 6 > acpi_throttle2: on cpu2 > acpi_throttle2: failed to attach P_CNT > device_attach: acpi_throttle2 attach returned 6 > acpi_throttle3: on cpu3 > acpi_throttle3: failed to attach P_CNT > device_attach: acpi_throttle3 attach returned 6 > ZFS filesystem version: 5 > ZFS storage pool version: features support (5000) > Timecounters tick every 1.000 msec > usbus0: 5.0Gbps Super Speed USB v3.0 > usbus1: 5.0Gbps Super Speed USB v3.0 > usbus2: 12Mbps Full Speed USB v1.0 > usbus3: 480Mbps High Speed USB v2.0 > usbus4: 12Mbps Full Speed USB v1.0 > usbus5: 480Mbps High Speed USB v2.0 > usbus6: 12Mbps Full Speed USB v1.0 > usbus7: 12Mbps Full Speed USB v1.0 > usbus8: 480Mbps High Speed USB v2.0 > ugen0.1: <0x1b21> at usbus0 > uhub0: <0x1b21 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 > ugen3.1: at usbus3 > uhub1: on usbus3 > ugen2.1: at usbus2 > uhub2: on usbus2 > ugen1.1: <0x1b21> at usbus1 > uhub3: <0x1b21 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus1 > ugen6.1: at usbus6 > uhub4: on usbus6 > ugen5.1: at usbus5 > uhub5: on usbus5 > ugen4.1: at usbus4 > uhub6: on usbus4 > ugen8.1: at usbus8 > uhub7: on usbus8 > ugen7.1: at usbus7 > uhub8: on usbus7 > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ATA-7 SATA 1.x device > ada0: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) > ada0: 38166MB (78165360 512 byte sectors: 16H 63S/T 16383C) > ada0: Previously was known as ad4 > ada1 at ahcich2 bus 0 scbus1 target 0 lun 0 > ada1: ATA-7 SATA 1.x device > ada1: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) > ada1: Command Queueing enabled > ada1: 38166MB (78165360 512 byte sectors: 16H 63S/T 16383C) > ada1: Previously was known as ad6 > ada2 at ahcich5 bus 0 scbus2 target 0 lun 0 > ada2: ATA-7 SATA 1.x device > ada2: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) > ada2: 38166MB (78165360 512 byte sectors: 16H 63S/T 16383C) > ada2: Previously was known as ad8 > SMP: AP CPU #1 Launched! > SMP: AP CPU #2 Launched! > SMP: AP CPU #3 Launched! > Timecounter "TSC-low" frequency 1800148234 Hz quality 1000 > uhub4: 2 ports with 2 removable, self powered > uhub8: 4 ports with 4 removable, self powered > uhub6: 5 ports with 5 removable, self powered > uhub2: 5 ports with 5 removable, self powered > uhub0: 4 ports with 4 removable, self powered > uhub3: 4 ports with 4 removable, self powered > GEOM: ada2: the secondary GPT table is corrupt or invalid. > GEOM: ada2: using the primary only -- recovery suggested. > GEOM: diskid/DISK-MDT-MCANKK515312: the secondary GPT table is corrupt or > invalid. > GEOM: diskid/DISK-MDT-MCANKK515312: using the primary only -- recovery > suggested. > Root mount waiting for: usbus8 usbus5 usbus3 > Root mount waiting for: usbus8 usbus5 usbus3 > uhub7: 4 ports with 4 removable, self powered > uhub5: 5 ports with 5 removable, self powered > uhub1: 5 ports with 5 removable, self powered > Trying to mount root from zfs:Puffy []... > ugen4.2: at usbus4 > ukbd0: on usbus4 > kbd2 at ukbd0 > ar9300_Stub_GetCTSTimeout: called > ar9300_Stub_GetCTSTimeout: called > ar9300_Stub_GetAntennaSwitch: called > ar9300_Stub_GetAntennaSwitch: called > wlan0: Ethernet address: 7c:c3:a1:b3:fc:af > uhid0: on usbus4 > uhid1: on usbus4 > root@Border:~ # uptime > 11:20PM up 15:06, 1 user, load averages: 0.34, 0.33, 0.25 > > > > -- > > Sam Fourman Jr. > _______________________________________________ > 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" The LOR is a false positive. See the comment in sys/ufs/ufs/ufs_dirhash.c Also, switching motherboards is not related to this in any way. You'll eventually hit that LOR report, unless you disabled WITNESS. Thanks, -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 23:45:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F166429C for ; Mon, 5 Aug 2013 23:45:32 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) by mx1.freebsd.org (Postfix) with ESMTP id 9D4C72E37 for ; Mon, 5 Aug 2013 23:45:32 +0000 (UTC) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.1 cv=ANp1G3FL c=1 sm=0 tr=0 a=nVny9ETX7T5uMhI2oTVyRA==:117 a=AaUjGI9IrlcA:10 a=kj9zAlcOel0A:10 a=OA2lqS22AAAA:8 a=sIt-5M63AAAA:8 a=S2kPtTsVP8EA:10 a=5qxXKLoQqx1W0KXEjMQA:9 a=CjuIK1q_8ugA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp02.rcn.cmh.synacor.com header.from=roberthuff@rcn.com; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.mail=roberthuff@rcn.com; spf=neutral; sender-id=neutral Received-SPF: neutral (smtp02.rcn.cmh.synacor.com: 209.6.193.164 is neither permitted nor denied by domain of rcn.com) Received: from [209.6.193.164] ([209.6.193.164:22380] helo=jerusalem.litteratus.org.litteratus.org) by smtp.rcn.com (envelope-from ) (ecelerity 2.2.3.49 r(42060/42061)) with ESMTP id 38/9E-14489-A1930025; Mon, 05 Aug 2013 19:45:31 -0400 From: Robert Huff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: base64 Message-ID: <20992.14618.332769.261961@jerusalem.litteratus.org> Date: Mon, 5 Aug 2013 19:45:30 -0400 To: Boris Samorodov Subject: Re: "make buildworld" fails In-Reply-To: <51FFD21A.3050602@passap.ru> References: <51FFD21A.3050602@passap.ru> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid 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, 05 Aug 2013 23:45:33 -0000 DQpCb3JpcyBTYW1vcm9kb3Ygd3JpdGVzOg0KDQo+ICBUaGlzIG5vdGUgZnJvbSAvdXNyL3Ny Yy9VUERBVElORyBtYXkgYmUgcmVsZXZhbnQ6DQo+ICAtLS0tLQ0KPiAgMjAxMzA2MTM6DQo+ ICAgICAgICAgIFNvbWUgcGVvcGxlIHJlcG9ydCB0aGUgZm9sbG93aW5nIGVycm9yIGFmdGVy IHRoZSBzd2l0Y2ggdG8gYm1ha2U6DQo+ICANCj4gICAgICAgICAgICAgICAgICBtYWtlOiBp bGxlZ2FsIG9wdGlvbiAtLSBKDQo+ICAgICAgICAgICAgICAgICAgdXNhZ2U6IG1ha2UgWy1C UFNYZWlrbnBxcnN0dl0gWy1DIGRpcmVjdG9yeV0gWy1EIHZhcmlhYmxlXQ0KPiAgICAgICAg ICAgICAgICAgICAgICAgICAgLi4uDQo+ICAgICAgICAgICAgICAgICAgKioqIFtidWlsZHdv cmxkXSBFcnJvciBjb2RlIDINCj4gIA0KPiAgICAgICAgICB0aGlzIGxpa2VseSBkdWUgdG8g YW4gb2xkIGluc3RhbmNlIG9mIG1ha2UgaW4NCj4gICAgICAgICAgJHtNQUtFUEFUSH0gKCR7 TUFLRU9CSkRJUlBSRUZJWH0key5DVVJESVJ9L21ha2UuJHtNQUNISU5FfSkNCj4gICAgICAg ICAgd2hpY2ggc3JjL01ha2VmaWxlIHdpbGwgdXNlIHRoYXQgYmxpbmRseSwgaWYgaXQgZXhp c3RzLCBzbyBpZg0KPiAgICAgICAgICB5b3Ugc2VlIHRoZSBhYm92ZSBlcnJvcjoNCj4gIA0K PiAgICAgICAgICAgICAgICAgIHJtIC1yZiBgbWFrZSAtViBNQUtFUEFUSGANCj4gIA0KPiAg ICAgICAgICBzaG91bGQgcmVzb2x2ZSBpdC4NCg0KCVdvdWxkIHRoYXQgaXQgd2VyZSBzby4g IDotKA0KCTEpIA0KDQpodWZmQD4+IG1ha2UgLVYgTUFLRVBBVEgNCg0KaHVmZkA+Pg0KDQoJ MikgQWZ0ZXIgcnVubmluZyB0aGUgYWJvdmUsIGJ1aWxkd29ybGQgc3RvcHMgYXQgdGhlIHNh bWUgcGxhY2U6DQoNCihjZCAvdXNyL3NyYyAmJiBtYWtlIGJtYWtlKQ0KZWNobw0KDQplY2hv ICItLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSINCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQplY2hvICI+Pj4gQnVpbGRpbmcgYW4gdXAtdG8tZGF0 ZSBtYWtlKDEpIg0KPj4+IEJ1aWxkaW5nIGFuIHVwLXRvLWRhdGUgbWFrZSgxKQ0KZWNobyAi LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0iDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KY2QgL3Vzci9zcmMvdXNyLmJpbi9ibWFrZTsgIE1BS0VP QkpESVJQUkVGSVg9L3Vzci9vYmovdXNyL3NyYy9tYWtlLmFtZDY0ICBERVNURElSPSAgSU5T VEFMTD0ic2ggL3Vzci9zcmMvdG9vbHMvaW5zdGFsbC5zaCIgbWFrZSAgLURfVVBHUkFESU5H ICAtRE5PTUFOIC1ETk9fTUFOIC1ETk9TSEFSRUQgLUROT19TSEFSRUQgIC1ETk9fQ1BVX0NG TEFHUyAtRE5PX1dFUlJPUiBvYmogJiYgIE1BS0VPQkpESVJQUkVGSVg9L3Vzci9vYmovdXNy L3NyYy9tYWtlLmFtZDY0ICBERVNURElSPSAgSU5TVEFMTD0ic2ggL3Vzci9zcmMvdG9vbHMv aW5zdGFsbC5zaCIgbWFrZSAgLURfVVBHUkFESU5HICAtRE5PTUFOIC1ETk9fTUFOIC1ETk9T SEFSRUQgLUROT19TSEFSRUQgIC1ETk9fQ1BVX0NGTEFHUyAtRE5PX1dFUlJPUiBkZXBlbmQg JiYgIE1BS0VPQkpESVJQUkVGSVg9L3Vzci9vYmovdXNyL3NyYy9tYWtlLmFtZDY0ICBERVNU RElSPSAgSU5TVEFMTD0ic2ggL3Vzci9zcmMvdG9vbHMvaW5zdGFsbC5zaCIgbWFrZSAgLURf VVBHUkFESU5HICAtRE5PTUFOIC1ETk9fTUFOIC1ETk9TSEFSRUQgLUROT19TSEFSRUQgIC1E Tk9fQ1BVX0NGTEFHUyAtRE5PX1dFUlJPUiBhbGwgJiYgIE1BS0VPQkpESVJQUkVGSVg9L3Vz ci9vYmovdXNyL3NyYy9tYWtlLmFtZDY0ICBERVNURElSPSAgSU5TVEFMTD0ic2ggL3Vzci9z cmMvdG9vbHMvaW5zdGFsbC5zaCIgbWFrZSAgLURfVVBHUkFESU5HICAtRE5PTUFOIC1ETk9f TUFOIC1ETk9TSEFSRUQgLUROT19TSEFSRUQgIC1ETk9fQ1BVX0NGTEFHUyAtRE5PX1dFUlJP UiBpbnN0YWxsIERFU1RESVI9L3Vzci9vYmovdXNyL3NyYy9tYWtlLmFtZDY0IEJJTkRJUj0g UFJPR05BTUU9Ym1ha2UNCmlmICEgdGVzdCAtZCAvdXNyL29iai91c3Ivc3JjL21ha2UuYW1k NjQvdXNyL3NyYy91c3IuYmluL2JtYWtlLzsgdGhlbiAgbWtkaXIgLXAgL3Vzci9vYmovdXNy L3NyYy9tYWtlLmFtZDY0L3Vzci9zcmMvdXNyLmJpbi9ibWFrZTsgIGlmICEgdGVzdCAtZCAv dXNyL29iai91c3Ivc3JjL21ha2UuYW1kNjQvdXNyL3NyYy91c3IuYmluL2JtYWtlLzsgdGhl biAgZWNobyAiVW5hYmxlIHRvIGNyZWF0ZSAvdXNyL29iai91c3Ivc3JjL21ha2UuYW1kNjQv dXNyL3NyYy91c3IuYmluL2JtYWtlLiI7ICBleGl0IDE7ICBmaTsgIGVjaG8gIi91c3Ivb2Jq L3Vzci9zcmMvbWFrZS5hbWQ2NC91c3Ivc3JjL3Vzci5iaW4vYm1ha2UgY3JlYXRlZCBmb3Ig L3Vzci9zcmMvdXNyLmJpbi9ibWFrZSI7ICBmaQ0KL3Vzci9vYmovdXNyL3NyYy9tYWtlLmFt ZDY0L3Vzci9zcmMvdXNyLmJpbi9ibWFrZSBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmlu L2JtYWtlDQpzZXQgLWU7IGZvciBlbnRyeSBpbiB1bml0LXRlc3RzOyBkbyAgaWYgdGVzdCAt ZCAvdXNyL3NyYy91c3IuYmluL2JtYWtlLyR7ZW50cnl9LmFtZDY0OyB0aGVuICBlY2hvICI9 PT0+ICR7ZW50cnl9LmFtZDY0IChvYmopIjsgIGVkaXI9JHtlbnRyeX0uYW1kNjQ7ICBjZCAv dXNyL3NyYy91c3IuYmluL2JtYWtlLyR7ZWRpcn07ICBlbHNlICBlY2hvICI9PT0+ICRlbnRy eSAob2JqKSI7ICBlZGlyPSR7ZW50cnl9OyAgY2QgL3Vzci9zcmMvdXNyLmJpbi9ibWFrZS8k e2VkaXJ9OyAgZmk7ICBtYWtlIG9iaiAgRElSUFJGWD0kZWRpci87ICBkb25lDQo9PT0+IHVu aXQtdGVzdHMgKG9iaikNCmlmICEgdGVzdCAtZCAvdXNyL29iai91c3Ivc3JjL21ha2UuYW1k NjQvdXNyL3NyYy91c3IuYmluL2JtYWtlL3VuaXQtdGVzdHMvOyB0aGVuICBta2RpciAtcCAv dXNyL29iai91c3Ivc3JjL21ha2UuYW1kNjQvdXNyL3NyYy91c3IuYmluL2JtYWtlL3VuaXQt dGVzdHM7ICBpZiAhIHRlc3QgLWQgL3Vzci9vYmovdXNyL3NyYy9tYWtlLmFtZDY0L3Vzci9z cmMvdXNyLmJpbi9ibWFrZS91bml0LXRlc3RzLzsgdGhlbiAgZWNobyAiVW5hYmxlIHRvIGNy ZWF0ZSAvdXNyL29iai91c3Ivc3JjL21ha2UuYW1kNjQvdXNyL3NyYy91c3IuYmluL2JtYWtl L3VuaXQtdGVzdHMuIjsgIGV4aXQgMTsgIGZpOyAgZWNobyAiL3Vzci9vYmovdXNyL3NyYy9t YWtlLmFtZDY0L3Vzci9zcmMvdXNyLmJpbi9ibWFrZS91bml0LXRlc3RzIGNyZWF0ZWQgZm9y IC91c3Ivc3JjL3Vzci5iaW4vYm1ha2UvdW5pdC10ZXN0cyI7ICBmaQ0KL3Vzci9vYmovdXNy L3NyYy9tYWtlLmFtZDY0L3Vzci9zcmMvdXNyLmJpbi9ibWFrZS91bml0LXRlc3RzIGNyZWF0 ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vYm1ha2UvdW5pdC10ZXN0cw0Kcm0gLWYgLmRlcGVu ZA0KbWtkZXAgLWYgLmRlcGVuZCAtYSAgICAtRE5PX1BXRF9PVkVSUklERSAtSS91c3Ivc3Jj L3Vzci5iaW4vYm1ha2UgLURVU0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdf SCAtREhBVkVfQ09ORklHX0ggLURVU0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05G SUdfSCAtRF9QQVRIX0RFRlNZU1BBVEg9XCIuLi4vc2hhcmUvbWs6L3Vzci9zaGFyZS9ta1wi IC1JLiAtSS91c3Ivc3JjL2NvbnRyaWIvYm1ha2UgLURNQUtFX05BVElWRSAtc3RkPWdudTk5 ICAgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9hcmNoLmMgL3Vzci9zcmMvY29udHJpYi9ibWFr ZS9idWYuYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL2NvbXBhdC5jIC91c3Ivc3JjL2NvbnRy aWIvYm1ha2UvY29uZC5jIC91c3Ivc3JjL2NvbnRyaWIvYm1ha2UvZGlyLmMgL3Vzci9zcmMv Y29udHJpYi9ibWFrZS9mb3IuYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL2hhc2guYyAvdXNy L3NyYy9jb250cmliL2JtYWtlL2pvYi5jIC91c3Ivc3JjL2NvbnRyaWIvYm1ha2UvbWFpbi5j IC91c3Ivc3JjL2NvbnRyaWIvYm1ha2UvbWFrZS5jIC91c3Ivc3JjL2NvbnRyaWIvYm1ha2Uv bWFrZV9tYWxsb2MuYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL21ldGEuYyAvdXNyL3NyYy9j b250cmliL2JtYWtlL3BhcnNlLmMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9zdHIuYyAvdXNy L3NyYy9jb250cmliL2JtYWtlL3N0cmxpc3QuYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL3N1 ZmYuYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL3RhcmcuYyAvdXNyL3NyYy9jb250cmliL2Jt YWtlL3RyYWNlLmMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS91dGlsLmMgL3Vzci9zcmMvY29u dHJpYi9ibWFrZS92YXIuYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL2xzdC5saWIvbHN0QXBw ZW5kLmMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdEF0RW5kLmMgL3Vzci9z cmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdEF0RnJvbnQuYyAvdXNyL3NyYy9jb250cmli L2JtYWtlL2xzdC5saWIvbHN0Q2xvc2UuYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL2xzdC5s aWIvbHN0Q29uY2F0LmMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdERhdHVt LmMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdERlUXVldWUuYyAvdXNyL3Ny Yy9jb250cmliL2JtYWtlL2xzdC5saWIvbHN0RGVzdHJveS5jIC91c3Ivc3JjL2NvbnRyaWIv Ym1ha2UvbHN0LmxpYi9sc3REdXBsLmMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGli L2xzdEVuUXVldWUuYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL2xzdC5saWIvbHN0RmluZC5j IC91c3Ivc3JjL2NvbnRyaWIvYm1ha2UvbHN0LmxpYi9sc3RGaW5kRnJvbS5jIC91c3Ivc3Jj L2NvbnRyaWIvYm1ha2UvbHN0LmxpYi9sc3RGaXJzdC5jIC91c3Ivc3JjL2NvbnRyaWIvYm1h a2UvbHN0LmxpYi9sc3RGb3JFYWNoLmMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGli L2xzdEZvckVhY2hGcm9tLmMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdElu aXQuYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL2xzdC5saWIvbHN0SW5zZXJ0LmMgL3Vzci9z cmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdElzQXRFbmQuYyAvdXNyL3NyYy9jb250cmli L2JtYWtlL2xzdC5saWIvbHN0SXNFbXB0eS5jIC91c3Ivc3JjL2NvbnRyaWIvYm1ha2UvbHN0 LmxpYi9sc3RMYXN0LmMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdE1lbWJl ci5jIC91c3Ivc3JjL2NvbnRyaWIvYm1ha2UvbHN0LmxpYi9sc3ROZXh0LmMgL3Vzci9zcmMv Y29udHJpYi9ibWFrZS9sc3QubGliL2xzdE9wZW4uYyAvdXNyL3NyYy9jb250cmliL2JtYWtl L2xzdC5saWIvbHN0UHJldi5jIC91c3Ivc3JjL2NvbnRyaWIvYm1ha2UvbHN0LmxpYi9sc3RS ZW1vdmUuYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL2xzdC5saWIvbHN0UmVwbGFjZS5jIC91 c3Ivc3JjL2NvbnRyaWIvYm1ha2UvbHN0LmxpYi9sc3RTdWNjLmMgL3Vzci9zcmMvY29udHJp Yi9ibWFrZS9zdHJlc2VwLmMNCmVjaG8gbWFrZTogL3Vzci9saWIvbGliYy5hICA+PiAuZGVw ZW5kDQpjYyAtTyAtcGlwZSAtZyAtRE5PX1BXRF9PVkVSUklERSAtSS91c3Ivc3JjL3Vzci5i aW4vYm1ha2UgIC1EVVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURI QVZFX0NPTkZJR19IICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19I IC1EX1BBVEhfREVGU1lTUEFUSD1cIi4uLi9zaGFyZS9tazovdXNyL3NoYXJlL21rXCIgLUku IC1JL3Vzci9zcmMvY29udHJpYi9ibWFrZSAgLURNQUtFX05BVElWRSAgLXN0ZD1nbnU5OSAt UXVudXNlZC1hcmd1bWVudHMgLWZzdGFjay1wcm90ZWN0b3IgLVdzeXN0ZW0taGVhZGVycyAt V2FsbCAtV25vLWZvcm1hdC15MmsgLVcgLVduby11bnVzZWQtcGFyYW1ldGVyIC1Xc3RyaWN0 LXByb3RvdHlwZXMgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdwb2ludGVyLWFyaXRoIC1Xbm8t dW5pbml0aWFsaXplZCAtV25vLXBvaW50ZXItc2lnbiAtV25vLWVtcHR5LWJvZHkgLVduby1z dHJpbmctcGx1cy1pbnQgLVduby10YXV0b2xvZ2ljYWwtY29tcGFyZSAtV25vLXVudXNlZC12 YWx1ZSAtV25vLXBhcmVudGhlc2VzLWVxdWFsaXR5IC1Xbm8tdW51c2VkLWZ1bmN0aW9uIC1X bm8tY29udmVyc2lvbiAgLWMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9hcmNoLmMNCmNjIC1P IC1waXBlIC1nIC1ETk9fUFdEX09WRVJSSURFIC1JL3Vzci9zcmMvdXNyLmJpbi9ibWFrZSAg LURVU0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtREhBVkVfQ09ORklH X0ggIC1EVVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURfUEFUSF9E RUZTWVNQQVRIPVwiLi4uL3NoYXJlL21rOi91c3Ivc2hhcmUvbWtcIiAtSS4gLUkvdXNyL3Ny Yy9jb250cmliL2JtYWtlICAtRE1BS0VfTkFUSVZFICAtc3RkPWdudTk5IC1RdW51c2VkLWFy Z3VtZW50cyAtZnN0YWNrLXByb3RlY3RvciAtV3N5c3RlbS1oZWFkZXJzIC1XYWxsIC1Xbm8t Zm9ybWF0LXkyayAtVyAtV25vLXVudXNlZC1wYXJhbWV0ZXIgLVdzdHJpY3QtcHJvdG90eXBl cyAtV21pc3NpbmctcHJvdG90eXBlcyAtV3BvaW50ZXItYXJpdGggLVduby11bmluaXRpYWxp emVkIC1Xbm8tcG9pbnRlci1zaWduIC1Xbm8tZW1wdHktYm9keSAtV25vLXN0cmluZy1wbHVz LWludCAtV25vLXRhdXRvbG9naWNhbC1jb21wYXJlIC1Xbm8tdW51c2VkLXZhbHVlIC1Xbm8t cGFyZW50aGVzZXMtZXF1YWxpdHkgLVduby11bnVzZWQtZnVuY3Rpb24gLVduby1jb252ZXJz aW9uICAtYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL2J1Zi5jDQpjYyAtTyAtcGlwZSAtZyAt RE5PX1BXRF9PVkVSUklERSAtSS91c3Ivc3JjL3Vzci5iaW4vYm1ha2UgIC1EVVNFX01FVEEg LURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURIQVZFX0NPTkZJR19IICAtRFVTRV9N RVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1EX1BBVEhfREVGU1lTUEFUSD1c Ii4uLi9zaGFyZS9tazovdXNyL3NoYXJlL21rXCIgLUkuIC1JL3Vzci9zcmMvY29udHJpYi9i bWFrZSAgLURNQUtFX05BVElWRSAgLXN0ZD1nbnU5OSAtUXVudXNlZC1hcmd1bWVudHMgLWZz dGFjay1wcm90ZWN0b3IgLVdzeXN0ZW0taGVhZGVycyAtV2FsbCAtV25vLWZvcm1hdC15Mmsg LVcgLVduby11bnVzZWQtcGFyYW1ldGVyIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdtaXNzaW5n LXByb3RvdHlwZXMgLVdwb2ludGVyLWFyaXRoIC1Xbm8tdW5pbml0aWFsaXplZCAtV25vLXBv aW50ZXItc2lnbiAtV25vLWVtcHR5LWJvZHkgLVduby1zdHJpbmctcGx1cy1pbnQgLVduby10 YXV0b2xvZ2ljYWwtY29tcGFyZSAtV25vLXVudXNlZC12YWx1ZSAtV25vLXBhcmVudGhlc2Vz LWVxdWFsaXR5IC1Xbm8tdW51c2VkLWZ1bmN0aW9uIC1Xbm8tY29udmVyc2lvbiAgLWMgL3Vz ci9zcmMvY29udHJpYi9ibWFrZS9jb21wYXQuYw0KDQoJLg0KCS4NCgkuDQoNCmNjIC1PIC1w aXBlIC1nIC1ETk9fUFdEX09WRVJSSURFIC1JL3Vzci9zcmMvdXNyLmJpbi9ibWFrZSAgLURV U0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtREhBVkVfQ09ORklHX0gg IC1EVVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURfUEFUSF9ERUZT WVNQQVRIPVwiLi4uL3NoYXJlL21rOi91c3Ivc2hhcmUvbWtcIiAtSS4gLUkvdXNyL3NyYy9j b250cmliL2JtYWtlICAtRE1BS0VfTkFUSVZFICAtc3RkPWdudTk5IC1RdW51c2VkLWFyZ3Vt ZW50cyAtZnN0YWNrLXByb3RlY3RvciAtV3N5c3RlbS1oZWFkZXJzIC1XYWxsIC1Xbm8tZm9y bWF0LXkyayAtVyAtV25vLXVudXNlZC1wYXJhbWV0ZXIgLVdzdHJpY3QtcHJvdG90eXBlcyAt V21pc3NpbmctcHJvdG90eXBlcyAtV3BvaW50ZXItYXJpdGggLVduby11bmluaXRpYWxpemVk IC1Xbm8tcG9pbnRlci1zaWduIC1Xbm8tZW1wdHktYm9keSAtV25vLXN0cmluZy1wbHVzLWlu dCAtV25vLXRhdXRvbG9naWNhbC1jb21wYXJlIC1Xbm8tdW51c2VkLXZhbHVlIC1Xbm8tcGFy ZW50aGVzZXMtZXF1YWxpdHkgLVduby11bnVzZWQtZnVuY3Rpb24gLVduby1jb252ZXJzaW9u ICAgLXN0YXRpYyAtbyBtYWtlIGFyY2gubyBidWYubyBjb21wYXQubyBjb25kLm8gZGlyLm8g Zm9yLm8gaGFzaC5vIGpvYi5vIG1haW4ubyBtYWtlLm8gbWFrZV9tYWxsb2MubyBtZXRhLm8g cGFyc2UubyBzdHIubyBzdHJsaXN0Lm8gc3VmZi5vIHRhcmcubyB0cmFjZS5vIHV0aWwubyB2 YXIubyBsc3RBcHBlbmQubyBsc3RBdEVuZC5vIGxzdEF0RnJvbnQubyBsc3RDbG9zZS5vIGxz dENvbmNhdC5vIGxzdERhdHVtLm8gbHN0RGVRdWV1ZS5vIGxzdERlc3Ryb3kubyBsc3REdXBs Lm8gbHN0RW5RdWV1ZS5vIGxzdEZpbmQubyBsc3RGaW5kRnJvbS5vIGxzdEZpcnN0Lm8gbHN0 Rm9yRWFjaC5vIGxzdEZvckVhY2hGcm9tLm8gbHN0SW5pdC5vIGxzdEluc2VydC5vIGxzdElz QXRFbmQubyBsc3RJc0VtcHR5Lm8gbHN0TGFzdC5vIGxzdE1lbWJlci5vIGxzdE5leHQubyBs c3RPcGVuLm8gbHN0UHJldi5vIGxzdFJlbW92ZS5vIGxzdFJlcGxhY2UubyBsc3RTdWNjLm8g c3RyZXNlcC5vIA0Kc2ggL3Vzci9zcmMvdG9vbHMvaW5zdGFsbC5zaCAgLW8gcm9vdCAtZyB3 aGVlbCAtbSA1NTUgICBtYWtlIC91c3Ivb2JqL3Vzci9zcmMvbWFrZS5hbWQ2NC9ibWFrZQ0K Y2QgL3Vzci9zcmM7IFBBVEg9L3NiaW46L2JpbjovdXNyL3NiaW46L3Vzci9iaW4gYHRlc3Qg LXggL3Vzci9vYmovdXNyL3NyYy9tYWtlLmFtZDY0L2JtYWtlICYmIGVjaG8gL3Vzci9vYmov dXNyL3NyYy9tYWtlLmFtZDY0L2JtYWtlIHx8IGVjaG8gbWFrZWAgIC1tIC91c3Ivc3JjL3No YXJlL21rIC1mIE1ha2VmaWxlLmluYzEgVEFSR0VUPWFtZDY0IFRBUkdFVF9BUkNIPWFtZDY0 IGJ1aWxkd29ybGQNCnVzYWdlOiBibWFrZSBbLUJlaWtObnFyc3RXd1hdIA0KICAgICAgICAg ICAgWy1DIGRpcmVjdG9yeV0gWy1EIHZhcmlhYmxlXSBbLWQgZmxhZ3NdIFstZiBtYWtlZmls ZV0NCiAgICAgICAgICAgIFstSSBkaXJlY3RvcnldIFstSiBwcml2YXRlXSBbLWogbWF4X2pv YnNdIFstbSBkaXJlY3RvcnldIFstVCBmaWxlXQ0KICAgICAgICAgICAgWy1WIHZhcmlhYmxl XSBbdmFyaWFibGU9dmFsdWVdIFt0YXJnZXQgLi4uXQ0KKioqIFtidWlsZHdvcmxkXSBFcnJv ciBjb2RlIDINCg0KU3RvcCBpbiAvdXNyL3NyYy4NCg0KDQoJUmVzcGVjdGZ1bGx5LA0KDQoN CgkJCQkJUm9iZXJ0IEh1ZmY= From owner-freebsd-current@FreeBSD.ORG Tue Aug 6 00:36:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 28411C15; Tue, 6 Aug 2013 00:36:55 +0000 (UTC) (envelope-from mack@macktronics.com) Received: from borg.macktronics.com (borg.macktronics.com [209.181.253.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F31DB2FC9; Tue, 6 Aug 2013 00:36:54 +0000 (UTC) Received: from olive.macktronics.com (olive.macktronics.com [209.181.253.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by borg.macktronics.com (Postfix) with ESMTPS id 91663323; Mon, 5 Aug 2013 19:36:53 -0500 (CDT) Date: Mon, 5 Aug 2013 19:36:52 -0500 (CDT) From: Dan Mack To: Davide Italiano Subject: Re: LOR on head ... In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "Sam Fourman Jr." , 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: Tue, 06 Aug 2013 00:36:55 -0000 On Mon, 5 Aug 2013, Davide Italiano wrote: > The LOR is a false positive. > See the comment in sys/ufs/ufs/ufs_dirhash.c > Also, switching motherboards is not related to this in any way. You'll > eventually hit that LOR report, unless you disabled WITNESS. Ah, thank you Davide; sorry for the noise ... I've been using only ZFS for so long that I haven't run across this yet. I'm also getting these too which appear to be the same sort of thing, no? lock order reversal: 1st 0xfffffe010157d418 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2099 2nd 0xffffff80ec37fa78 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:262 3rd 0xfffffe010157b9a0 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2099 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff81166cecb0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff81166ced60 witness_checkorder() at witness_checkorder+0xd4f/frame 0xffffff81166cedf0 __lockmgr_args() at __lockmgr_args+0x6f2/frame 0xffffff81166cef20 ffs_lock() at ffs_lock+0x84/frame 0xffffff81166cef70 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xffffff81166cefa0 _vn_lock() at _vn_lock+0xab/frame 0xffffff81166cf010 vget() at vget+0x70/frame 0xffffff81166cf060 vfs_hash_get() at vfs_hash_get+0xf5/frame 0xffffff81166cf0b0 ffs_vgetf() at ffs_vgetf+0x41/frame 0xffffff81166cf140 softdep_sync_buf() at softdep_sync_buf+0x8fa/frame 0xffffff81166cf1f0 ffs_syncvnode() at ffs_syncvnode+0x258/frame 0xffffff81166cf270 ffs_truncate() at ffs_truncate+0x5ca/frame 0xffffff81166cf450 ufs_direnter() at ufs_direnter+0x891/frame 0xffffff81166cf510 ufs_makeinode() at ufs_makeinode+0x573/frame 0xffffff81166cf6d0 VOP_CREATE_APV() at VOP_CREATE_APV+0xea/frame 0xffffff81166cf700 vn_open_cred() at vn_open_cred+0x300/frame 0xffffff81166cf850 kern_openat() at kern_openat+0x1f5/frame 0xffffff81166cf9a0 amd64_syscall() at amd64_syscall+0x265/frame 0xffffff81166cfab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xffffff81166cfab0 --- syscall (5, FreeBSD ELF64, sys_open), rip = 0x80093d3ea, rsp = 0x7fffffffd758, rbp = 0x7fffffffd7b0 --- dan -- Dan Mack From owner-freebsd-current@FreeBSD.ORG Tue Aug 6 05:04:02 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 94B9628E for ; Tue, 6 Aug 2013 05:04:02 +0000 (UTC) (envelope-from joel@freebsd.org) Received: from mail.vnode.se (mail.vnode.se [212.247.52.13]) by mx1.freebsd.org (Postfix) with ESMTP id 547C62797 for ; Tue, 6 Aug 2013 05:04:02 +0000 (UTC) Received: from mail.vnode.se (localhost [127.0.0.1]) by mail.vnode.se (Postfix) with ESMTP id 3BD65E3F07A; Tue, 6 Aug 2013 07:04:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at vnode.se Received: from mail.vnode.se ([127.0.0.1]) by mail.vnode.se (mail.vnode.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2Js5VfyWuWK; Tue, 6 Aug 2013 07:03:58 +0200 (CEST) Received: from devbox.vnode.local (unknown [83.223.1.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.vnode.se (Postfix) with ESMTPSA id E6F31E3F079; Tue, 6 Aug 2013 07:03:57 +0200 (CEST) Date: Tue, 6 Aug 2013 07:03:54 +0200 From: Joel Dahl To: Bryan Venteicher Subject: Re: [CFT] VMware vmxnet3 ethernet driver Message-ID: <20130806050354.GB18861@devbox.vnode.local> References: <1050637258.686.1375660230986.JavaMail.root@daemoninthecloset.org> <601099152.721.1375661537866.JavaMail.root@daemoninthecloset.org> <20130805202039.GA18861@devbox.vnode.local> <1174186801.993.1375743121722.JavaMail.root@daemoninthecloset.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1174186801.993.1375743121722.JavaMail.root@daemoninthecloset.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 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: Tue, 06 Aug 2013 05:04:02 -0000 On Mon, Aug 05, 2013 at 05:52:01PM -0500, Bryan Venteicher wrote: > > > ----- Original Message ----- > > I have ~100 FreeBSD 8/9 VMs in my vSphere 5.1 environment, all using the > > VMware tools package from VMware. Everything has been running great for > > years. > > (we skipped vSphere 5.0). Why should I use this vmxnet driver instead of the > > VMware tools driver or the emulated e1000? > > > > They are out of tree and subject to rotting. I had to use the patches > at [1] to even get them to compile on 9.1 and -current. I don't think > VMware puts much engineering resources behind it; Perhaps not, but they do support FreeBSD. I've started several support cases with FreeBSD-specific problems and they've fixed all so far. Are you aiming at completely replacing VMware tools, or just the device drivers? -- Joel From owner-freebsd-current@FreeBSD.ORG Tue Aug 6 05:53:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6E69088E; Tue, 6 Aug 2013 05:53:56 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-bk0-x22a.google.com (mail-bk0-x22a.google.com [IPv6:2a00:1450:4008:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C46FB292B; Tue, 6 Aug 2013 05:53:55 +0000 (UTC) Received: by mail-bk0-f42.google.com with SMTP id jk14so1277694bkc.15 for ; Mon, 05 Aug 2013 22:53:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; bh=pNUTzaZa0XFUgPDetEcTMr/B/Wc3pbcz2Fbwq7QsgYg=; b=vadfhJnqJI1pcI3ixpb7dGHNGveF9DlopzZGvd7NwTE1mGsJ/y2QONbdlqymAg35Ax a0OhavejMntYE2Ytj2g18cksVAFEahNk1TG/UoHEnEl+VWtJL4KL5elokvO/gobxQb2q 1ShkZPm0olx+bKYDLk4Di5P/XDzTtoXKPoP0hB8gFMNVq4NF7/SIQiTKLKyhQBF+tj7r k/BgSC4FjjAc83s+K2mQ62qyvsnpzZKlEpHWid04wCnIJueVpqyeocTAq1HXtZ2lHJWE 7kPi5iXqpdFUamq658elZnJcaQOEnlnVxWgE6XSO3Hbk48ckCPJM3OgiidiveEzehRRd tJGA== X-Received: by 10.204.55.13 with SMTP id s13mr3264932bkg.170.1375768433886; Mon, 05 Aug 2013 22:53:53 -0700 (PDT) Received: from ernst.home (p4FCA7DE8.dip0.t-ipconnect.de. [79.202.125.232]) by mx.google.com with ESMTPSA id h5sm410701bkg.8.2013.08.05.22.53.52 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 05 Aug 2013 22:53:53 -0700 (PDT) Date: Tue, 6 Aug 2013 07:53:50 +0200 From: Gary Jennejohn To: Craig Rodrigues Subject: Re: Kernel Panic on FreeBSD 10.0-CURRENT #1 r253918 Message-ID: <20130806075350.497414fd@ernst.home> In-Reply-To: References: X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.17; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "Sam Fourman Jr." , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 05:53:56 -0000 On Mon, 5 Aug 2013 10:29:23 -0700 Craig Rodrigues wrote: > On Sun, Aug 4, 2013 at 3:59 PM, Sam Fourman Jr. wrote: > > > > > > > > > Craig, > > > > Thank you for getting back to me, I will get to work on this right away > > and get you what you need. > > but are we CERTAIN this panic could be from VIMAGE? I totally thought I > > had a # infront of that line when I built this kernel... > > > > if you notice I did post the kernel config at the bottom of that email, > > and VIMAGE is NOT included... > > but maybe I did something wrong and somehow built VIMAGE in anyway.. > > > > is there some sort of command I can run to ask the system if it does > > indeed have VIMAGE? > > > > On the booted an running system, if you type: > > sysctl kern.conftxt > > that will display the actual kernel config options used to build the > running kernel. > Not necessarily sysctl kern.conftxt sysctl: unknown oid 'kern.conftxt': No such file or directory -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Tue Aug 6 06:05:37 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5DAD3CDF; Tue, 6 Aug 2013 06:05:37 +0000 (UTC) (envelope-from bryanv@daemoninthecloset.org) Received: from torment.daemoninthecloset.org (torment.daemoninthecloset.org [94.242.209.234]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1DFC029F3; Tue, 6 Aug 2013 06:05:37 +0000 (UTC) Received: from sage.daemoninthecloset.org (unknown [70.114.209.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sage.daemoninthecloset.org", Issuer "daemoninthecloset.org" (verified OK)) by torment.daemoninthecloset.org (Postfix) with ESMTPS id 6385742C10D7; Tue, 6 Aug 2013 08:09:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at daemoninthecloset.org X-Virus-Scanned: amavisd-new at daemoninthecloset.org Date: Tue, 6 Aug 2013 01:05:20 -0500 (CDT) From: Bryan Venteicher To: Joel Dahl Message-ID: <671854288.1036.1375769120756.JavaMail.root@daemoninthecloset.org> In-Reply-To: <20130806050354.GB18861@devbox.vnode.local> References: <1050637258.686.1375660230986.JavaMail.root@daemoninthecloset.org> <601099152.721.1375661537866.JavaMail.root@daemoninthecloset.org> <20130805202039.GA18861@devbox.vnode.local> <1174186801.993.1375743121722.JavaMail.root@daemoninthecloset.org> <20130806050354.GB18861@devbox.vnode.local> Subject: Re: [CFT] VMware vmxnet3 ethernet driver MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [192.168.10.20] X-Mailer: Zimbra 8.0.2_GA_5569 (ZimbraWebClient - GC20 ([unknown])/8.0.2_GA_5569) Thread-Topic: VMware vmxnet3 ethernet driver Thread-Index: ViA/8l8/aWIeb/QKzBW05zNOPE614Q== Cc: 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: Tue, 06 Aug 2013 06:05:37 -0000 ----- Original Message ----- > Perhaps not, but they do support FreeBSD. I've started several support cases > with FreeBSD-specific problems and they've fixed all so far. > Yes, it is not a blackhole of support. At $JOB, we got caught by the FreeBSD specific issue of the busted timer that was fixed. But they've less helpful in other regards, and have more or less said FreeBSD isn't high in their priority because it isn't Linux. > Are you aiming at completely replacing VMware tools, or just the device > drivers? > I'd like as much as possible to work out of the box. vmxnet3 is as far as my current interests go. OpenBSD has a vmt device that apparently does (at least the important bits of) what vmtoolsd does; I'll look at that closer at some point. I have no intention of preventing people from using VMware's tools if they desire, nor breaking existing users. > -- > Joel > From owner-freebsd-current@FreeBSD.ORG Tue Aug 6 07:32:20 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 512DADF0 for ; Tue, 6 Aug 2013 07:32:20 +0000 (UTC) (envelope-from joel@vnode.se) Received: from mail.vnode.se (mail.vnode.se [212.247.52.13]) by mx1.freebsd.org (Postfix) with ESMTP id 0D9FE2CD4 for ; Tue, 6 Aug 2013 07:32:19 +0000 (UTC) Received: from mail.vnode.se (localhost [127.0.0.1]) by mail.vnode.se (Postfix) with ESMTP id 2678DE3F07A; Tue, 6 Aug 2013 09:32:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at vnode.se Received: from mail.vnode.se ([127.0.0.1]) by mail.vnode.se (mail.vnode.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id coM7Ro+bjOoj; Tue, 6 Aug 2013 09:32:17 +0200 (CEST) Received: from [10.101.106.159] (edsfw.benders.se [212.247.52.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.vnode.se (Postfix) with ESMTPSA id 153B5E3F079; Tue, 6 Aug 2013 09:32:17 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: [CFT] VMware vmxnet3 ethernet driver From: Joel Dahl In-Reply-To: <671854288.1036.1375769120756.JavaMail.root@daemoninthecloset.org> Date: Tue, 6 Aug 2013 09:32:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1050637258.686.1375660230986.JavaMail.root@daemoninthecloset.org> <601099152.721.1375661537866.JavaMail.root@daemoninthecloset.org> <20130805202039.GA18861@devbox.vnode.local> <1174186801.993.1375743121722.JavaMail.root@daemoninthecloset.org> <20130806050354.GB18861@devbox.vnode.local> <671854288.1036.1375769120756.JavaMail.root@daemoninthecloset.org> To: Bryan Venteicher X-Mailer: Apple Mail (2.1508) Cc: 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: Tue, 06 Aug 2013 07:32:20 -0000 6 aug 2013 kl. 08:05 skrev Bryan Venteicher = : >=20 >=20 > ----- Original Message ----- >> Perhaps not, but they do support FreeBSD. I've started several = support cases >> with FreeBSD-specific problems and they've fixed all so far. >>=20 >=20 > Yes, it is not a blackhole of support. At $JOB, we got caught by the = FreeBSD > specific issue of the busted timer that was fixed. But they've less = helpful > in other regards, and have more or less said FreeBSD isn't high in = their > priority because it isn't Linux. >=20 >> Are you aiming at completely replacing VMware tools, or just the = device >> drivers? >>=20 >=20 > I'd like as much as possible to work out of the box. vmxnet3 is as far = as > my current interests go. OpenBSD has a vmt device that apparently does = (at > least the important bits of) what vmtoolsd does; I'll look at that = closer > at some point. Cool. I didn't know about vmt. I read the CVS log in the OpenBSD tree = and it actually seems to do most of what I need. Having all this working out of the box = (without VMware Tools installed) would be most welcome. =85but I guess VMware would consider this an unsupported configuration = or something like that, which sucks if/when I need to contact their support. -- Joel= From owner-freebsd-current@FreeBSD.ORG Tue Aug 6 09:00:43 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4534627E for ; Tue, 6 Aug 2013 09:00:43 +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]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 02D3A211F for ; Tue, 6 Aug 2013 09:00:42 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1V6d8D-002m8L-HE>; Tue, 06 Aug 2013 11:00:41 +0200 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198] helo=telesto) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1V6d8D-003BsT-Ey>; Tue, 06 Aug 2013 11:00:41 +0200 Date: Tue, 6 Aug 2013 11:00:33 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: CURRENT (r253984) buildworld fails: contrib/bind9/bin/dig/dighost.c:4340:27: error: passing 'const char *' to parameter of type 'void *' discards qualifiers Message-ID: <20130806110033.3a600a7b@telesto> Organization: FU Berlin X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/T9gw.apOmlxxzAH._oFrq9l"; protocol="application/pgp-signature" X-Originating-IP: 130.133.86.198 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: Tue, 06 Aug 2013 09:00:43 -0000 --Sig_/T9gw.apOmlxxzAH._oFrq9l Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Buildword on r253984 fails ins BIND9: cc -O2 -pipe -O3 -march=3Dnative -I/usr/src/usr.sbin/pkg_install/create/../lib -pipe -O3 -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wformat=3D2 -Wno-format-extra-args -Wno-format-nonliteral -Werror -c /usr/src/usr.sbin/pkg_install/create/perform.c --- usr.bin.all__D --- /usr/src/usr.bin/dig/../../contrib/bind9/bin/dig/dighost.c:4340:27: error: passing 'const char *' to parameter of type 'void *' discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers] isc_buffer_init(&buffer, str, len); [...] --Sig_/T9gw.apOmlxxzAH._oFrq9l Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBAgAGBQJSALs5AAoJEOgBcD7A/5N8IAQH/0/va1t5x3JJ7AKCMoxtenIc sZaFHELQdxDObs2jllrCM3dq5azyKYbPDBgASZBD3EOVoFHn0lljGvbi6tucf94E uq8lpFqhCg6VrZkkibdq+XpdJ51YqIQgWJfI0ZZNsAW6egTYGYBhHtHc61yTDVlx 9plAWjOo5pVv2hc9Tc/quorUmjysQ3ZBV0ayHteUsjUq7ZPjw2iN92KI/tlFBSII 3c2dTa4Z5ezqZP5qPeoOOfy6lOWR61mlaWo1wVicw5ydhZPxKl03tyY/JmXt7pIX 2u9a5VJYASvNQroQ955DVPJEnmyxXLjbA7dp+4iz5Tn/iugb1mqH0m2xGEWJBIQ= =GZ1f -----END PGP SIGNATURE----- --Sig_/T9gw.apOmlxxzAH._oFrq9l-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 6 09:06:55 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2AAC74BD; Tue, 6 Aug 2013 09:06:55 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F190E217E; Tue, 6 Aug 2013 09:06:54 +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 r7696mNk057338; Tue, 6 Aug 2013 05:06:48 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r7696lIE057335; Tue, 6 Aug 2013 09:06:47 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 6 Aug 2013 09:06:47 GMT Message-Id: <201308060906.r7696lIE057335@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 arm/arm 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: Tue, 06 Aug 2013 09:06:55 -0000 TB --- 2013-08-06 06:20:28 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-06 06:20:28 - 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 --- 2013-08-06 06:20:28 - starting HEAD tinderbox run for arm/arm TB --- 2013-08-06 06:20:28 - cleaning the object tree TB --- 2013-08-06 06:20:28 - /usr/local/bin/svn stat /src TB --- 2013-08-06 06:20:33 - At svn revision 253982 TB --- 2013-08-06 06:20:34 - building world TB --- 2013-08-06 06:20:34 - CROSS_BUILD_TESTING=YES TB --- 2013-08-06 06:20:34 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-06 06:20:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-06 06:20:34 - SRCCONF=/dev/null TB --- 2013-08-06 06:20:34 - TARGET=arm TB --- 2013-08-06 06:20:34 - TARGET_ARCH=arm TB --- 2013-08-06 06:20:34 - TZ=UTC TB --- 2013-08-06 06:20:34 - __MAKE_CONF=/dev/null TB --- 2013-08-06 06:20:34 - cd /src TB --- 2013-08-06 06:20:34 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Aug 6 06:20:41 UTC 2013 >>> 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 [...] rm -f .depend CC='cc ' mkdep -f .depend -a -DHAVE_ARC4RANDOM -DHAVE_POLL_H -DSMALL -DRESCUE -std=gnu99 /src/sbin/rtsol/../../usr.sbin/rtsold/rtsold.c /src/sbin/rtsol/../../usr.sbin/rtsold/rtsol.c /src/sbin/rtsol/../../usr.sbin/rtsold/if.c /src/sbin/rtsol/../../usr.sbin/rtsold/probe.c /src/sbin/rtsol/../../usr.sbin/rtsold/dump.c /src/sbin/rtsol/../../usr.sbin/rtsold/rtsock.c echo rtsol: /obj/arm.arm/src/tmp/usr/lib/libc.a >> .depend cc -O -pipe -DHAVE_ARC4RANDOM -DHAVE_POLL_H -DSMALL -DRESCUE -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -c /src/sbin/rtsol/../../usr.sbin/rtsold/rtsold.c /src/sbin/rtsol/../../usr.sbin/rtsold/rtsold.c:193:25: error: shift count >= width of type [-Werror,-Wshift-count-overflow] tm_max.tv_sec &= ~(1UL << (sizeof(tm_max.tv_sec) * 8 - 1)); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. *** Error code 1 Stop. bmake[5]: stopped in /src/sbin/rtsol *** Error code 1 Stop. bmake[4]: stopped in /obj/arm.arm/src/rescue/rescue *** Error code 1 Stop. bmake[3]: stopped in /src/rescue/rescue *** Error code 1 Stop. bmake[2]: stopped in /src/rescue *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-06 09:06:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-06 09:06:47 - ERROR: failed to build world TB --- 2013-08-06 09:06:47 - 8011.84 user 1315.45 system 9979.10 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Tue Aug 6 09:06:58 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 076574C0; Tue, 6 Aug 2013 09:06:58 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CF2142180; Tue, 6 Aug 2013 09:06:54 +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 r7696moj057366; Tue, 6 Aug 2013 05:06:48 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r7696mMM057365; Tue, 6 Aug 2013 09:06:48 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 6 Aug 2013 09:06:48 GMT Message-Id: <201308060906.r7696mMM057365@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 armv6/arm 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: Tue, 06 Aug 2013 09:06:58 -0000 TB --- 2013-08-06 06:20:28 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-06 06:20:28 - 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 --- 2013-08-06 06:20:28 - starting HEAD tinderbox run for armv6/arm TB --- 2013-08-06 06:20:28 - cleaning the object tree TB --- 2013-08-06 06:20:28 - /usr/local/bin/svn stat /src TB --- 2013-08-06 06:20:33 - At svn revision 253982 TB --- 2013-08-06 06:20:34 - building world TB --- 2013-08-06 06:20:34 - CROSS_BUILD_TESTING=YES TB --- 2013-08-06 06:20:34 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-06 06:20:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-06 06:20:34 - SRCCONF=/dev/null TB --- 2013-08-06 06:20:34 - TARGET=arm TB --- 2013-08-06 06:20:34 - TARGET_ARCH=armv6 TB --- 2013-08-06 06:20:34 - TZ=UTC TB --- 2013-08-06 06:20:34 - __MAKE_CONF=/dev/null TB --- 2013-08-06 06:20:34 - cd /src TB --- 2013-08-06 06:20:34 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Aug 6 06:20:41 UTC 2013 >>> 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 [...] rm -f .depend CC='cc ' mkdep -f .depend -a -DHAVE_ARC4RANDOM -DHAVE_POLL_H -DSMALL -DRESCUE -std=gnu99 /src/sbin/rtsol/../../usr.sbin/rtsold/rtsold.c /src/sbin/rtsol/../../usr.sbin/rtsold/rtsol.c /src/sbin/rtsol/../../usr.sbin/rtsold/if.c /src/sbin/rtsol/../../usr.sbin/rtsold/probe.c /src/sbin/rtsol/../../usr.sbin/rtsold/dump.c /src/sbin/rtsol/../../usr.sbin/rtsold/rtsock.c echo rtsol: /obj/arm.armv6/src/tmp/usr/lib/libc.a >> .depend cc -O -pipe -DHAVE_ARC4RANDOM -DHAVE_POLL_H -DSMALL -DRESCUE -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -c /src/sbin/rtsol/../../usr.sbin/rtsold/rtsold.c /src/sbin/rtsol/../../usr.sbin/rtsold/rtsold.c:193:25: error: shift count >= width of type [-Werror,-Wshift-count-overflow] tm_max.tv_sec &= ~(1UL << (sizeof(tm_max.tv_sec) * 8 - 1)); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. *** Error code 1 Stop. bmake[5]: stopped in /src/sbin/rtsol *** Error code 1 Stop. bmake[4]: stopped in /obj/arm.armv6/src/rescue/rescue *** Error code 1 Stop. bmake[3]: stopped in /src/rescue/rescue *** Error code 1 Stop. bmake[2]: stopped in /src/rescue *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-06 09:06:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-06 09:06:48 - ERROR: failed to build world TB --- 2013-08-06 09:06:48 - 8027.37 user 1315.12 system 9979.64 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-armv6-arm.full From owner-freebsd-current@FreeBSD.ORG Tue Aug 6 10:42:00 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 38172BA5; Tue, 6 Aug 2013 10:42:00 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E73C02647; Tue, 6 Aug 2013 10:41:59 +0000 (UTC) Received: by mail-ob0-f176.google.com with SMTP id uz19so99128obc.35 for ; Tue, 06 Aug 2013 03:41:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Z2f65XjncTiLsTfjiR6laMOKPkFNMWYWAHZi5F29vfs=; b=yDHk0wZAXgl5QpiDQLwPrp/zf0L9+qQiorK9uxmPGl5Bvl708uSv5Wh/BYTYQ/xakw jyd82ahQvEGQDNvRceJ5Kar13k979UEzGGFNRQkA2Psj8qHD8pHtJ52UiszPx0jyAkDB K+kdTWlonUTIC2Qx9JlY508eXuIv1gvLbUrYjBcIqNsbk74Ywf5mQAloipj9jxBnZw2M a0R5pU03kI+gZeC4yxyWh+z7uzntcl5Zm7T/joL8txHxwND7Pufl8Oxs0oQD8qam54Yr HVdrBY8q2ubMm7yz+fu1fKlRvw7iDsFmyIFcnIcRRGGYuoBTRtg3KSS1jhaiDJvyo3OL hHkg== X-Received: by 10.60.79.131 with SMTP id j3mr418815oex.96.1375785719259; Tue, 06 Aug 2013 03:41:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.131.111 with HTTP; Tue, 6 Aug 2013 03:41:29 -0700 (PDT) In-Reply-To: References: <51EEAA36.6030206@bitfrost.no> <51EEABA3.7060909@FreeBSD.org> <51EEE15C.6020900@FreeBSD.org> From: Jia-Shiun Li Date: Tue, 6 Aug 2013 18:41:29 +0800 Message-ID: Subject: Re: Panic at USB drive plugging in To: Alexander Motin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Hans Petter Selasky , 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: Tue, 06 Aug 2013 10:42:00 -0000 2013/7/24 =E4=B8=8B=E5=8D=8810:26 =E6=96=BC "Jia-Shiun Li" =E5=AF=AB=E9=81=93=EF=BC=9A > On Wed, Jul 24, 2013 at 4:02 AM, Alexander Motin wrote: > > cam.k kernel module includes all existing periph drivers in one bundle. > > Loading cam.ko you are probably getting sg driver also, that triggers > > reported issue. You may try to rip out sg with single line hack to > module's > > Makefile. The real fix require looking closer on sg, which I never used= . > > > > Indeed. Test result did confirm that if sg is not included in cam.ko > USB drives will not cause kernel to panic. > > Hi all, turns out, it may be conflicts between assumed and actual sg usage. The sg driver specifically assumes a write-read sequence. If a read comes first it will cause sg to panic at msleep() in sgread. In my case the process is hald-probe-storage tasting new devices. But it can be as simple as "dd if=3D/dev/sgX". I am wondering that, is sg necessary on FreeBSD? Since most applications seem to live happily without it in GENERIC kernel. Maybe we can isolate it from cam.ko to make cam usable as module, and make the standalone sg module depending on cam module before sg got more resistant to misuse? Regards, Jia-Shiun. From owner-freebsd-current@FreeBSD.ORG Tue Aug 6 12:29:36 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C86FD770; Tue, 6 Aug 2013 12:29:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 99A102BDE; Tue, 6 Aug 2013 12:29:36 +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 r76CTZN3024594; Tue, 6 Aug 2013 08:29:35 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r76CTUko024380; Tue, 6 Aug 2013 12:29:30 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 6 Aug 2013 12:29:30 GMT Message-Id: <201308061229.r76CTUko024380@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 mips/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: Tue, 06 Aug 2013 12:29:37 -0000 TB --- 2013-08-06 11:41:02 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-06 11:41:02 - 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 --- 2013-08-06 11:41:02 - starting HEAD tinderbox run for mips/mips TB --- 2013-08-06 11:41:02 - cleaning the object tree TB --- 2013-08-06 11:41:02 - /usr/local/bin/svn stat /src TB --- 2013-08-06 11:41:11 - At svn revision 253982 TB --- 2013-08-06 11:41:12 - building world TB --- 2013-08-06 11:41:12 - CROSS_BUILD_TESTING=YES TB --- 2013-08-06 11:41:12 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-06 11:41:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-06 11:41:12 - SRCCONF=/dev/null TB --- 2013-08-06 11:41:12 - TARGET=mips TB --- 2013-08-06 11:41:12 - TARGET_ARCH=mips TB --- 2013-08-06 11:41:12 - TZ=UTC TB --- 2013-08-06 11:41:12 - __MAKE_CONF=/dev/null TB --- 2013-08-06 11:41:12 - cd /src TB --- 2013-08-06 11:41:12 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Aug 6 11:41:19 UTC 2013 >>> 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 [...] (cd /src/rescue/rescue/../../sbin/rtsol && /obj/src/make.amd64/bmake -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/rtsol/ depend && /obj/src/make.amd64/bmake -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/rtsol/ rtsold.o rtsol.o if.o probe.o dump.o rtsock.o) rm -f .depend CC='cc ' mkdep -f .depend -a -DHAVE_ARC4RANDOM -DHAVE_POLL_H -DSMALL -DRESCUE -std=gnu99 /src/sbin/rtsol/../../usr.sbin/rtsold/rtsold.c /src/sbin/rtsol/../../usr.sbin/rtsold/rtsol.c /src/sbin/rtsol/../../usr.sbin/rtsold/if.c /src/sbin/rtsol/../../usr.sbin/rtsold/probe.c /src/sbin/rtsol/../../usr.sbin/rtsold/dump.c /src/sbin/rtsol/../../usr.sbin/rtsold/rtsock.c echo rtsol: /obj/mips.mips/src/tmp/usr/lib/libc.a >> .depend cc -O -pipe -G0 -DHAVE_ARC4RANDOM -DHAVE_POLL_H -DSMALL -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/rtsol/../../usr.sbin/rtsold/rtsold.c cc1: warnings being treated as errors /src/sbin/rtsol/../../usr.sbin/rtsold/rtsold.c: In function 'main': /src/sbin/rtsol/../../usr.sbin/rtsold/rtsold.c:193: warning: left shift count >= width of type *** Error code 1 Stop. bmake[5]: stopped in /src/sbin/rtsol *** Error code 1 Stop. bmake[4]: stopped in /obj/mips.mips/src/rescue/rescue *** Error code 1 Stop. bmake[3]: stopped in /src/rescue/rescue *** Error code 1 Stop. bmake[2]: stopped in /src/rescue *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-06 12:29:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-06 12:29:30 - ERROR: failed to build world TB --- 2013-08-06 12:29:30 - 2095.24 user 562.53 system 2908.23 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Tue Aug 6 14:26:48 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3DFBAC51 for ; Tue, 6 Aug 2013 14:26:48 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 810862155 for ; Tue, 6 Aug 2013 14:26:47 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA08821 for ; Tue, 06 Aug 2013 17:26:40 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1V6iDf-000KAg-SP for freebsd-current@FreeBSD.org; Tue, 06 Aug 2013 17:26:40 +0300 Message-ID: <52010768.6090902@FreeBSD.org> Date: Tue, 06 Aug 2013 17:25:44 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: FreeBSD Current Subject: weird patch(1) behavior X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit 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: Tue, 06 Aug 2013 14:26:48 -0000 ... Patching file xxxx using Plan A... Hunk #1 succeeded at 53 with fuzz 1 (offset -2 lines). patch: **** misordered hunks! output would be garbled But what I see is that patching actually fails. So: "Hunk #1 succeeded" is a lie, it did not succeed - target file was not changed at all. "**** misordered hunks!" is a lie, because the whole patch consisted of exactly one hunk. This was quite confusing. $ patch --version Patch version 2.1 gpatch worked as expected: patching file xxxx Hunk #1 FAILED at 55. 1 out of 1 hunk FAILED -- saving rejects to file xxxx.rej -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Aug 6 16:02:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 383B7BF8 for ; Tue, 6 Aug 2013 16:02:26 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AEBAD25B7 for ; Tue, 6 Aug 2013 16:02:25 +0000 (UTC) Received: by mail-lb0-f175.google.com with SMTP id 13so632761lba.20 for ; Tue, 06 Aug 2013 09:02:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=/rmrgif7vSU5G6vuhFi1mZFgD0mby1yD4s8s23Ob8Nk=; b=w/49W5/pWn1TM5hdGHrkfXZYa+P264n9zlTSfsYIBr/lVAfd2TkPewWQEU7ButXRdQ /h1lXgufaQejSjuybry0grGdXAeguEcTvrNyDY5/kuP0/v4PhbFJC3rV3zqIEjzdtIsw 172gZeta0X0UyjIxoLVBUv5C6CzFnmGg2zdlS81aM1P07h/Slba4lLpclnSwb6EtyKEj liAa03F2DcHAg/69TJSwjXG6GX/QlUQGgKYi3pbbN1UIq3uxv0g+v0CMhVbXPz2iaRC1 QMxkbdilcIArwBkw4q4hA2+Y+ZcK2QQnRttiMP4KnKaQStupoXizqPG2wpGq1HeE2TsD js7A== MIME-Version: 1.0 X-Received: by 10.112.55.207 with SMTP id u15mr1529289lbp.58.1375804943525; Tue, 06 Aug 2013 09:02:23 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.22.100 with HTTP; Tue, 6 Aug 2013 09:02:23 -0700 (PDT) In-Reply-To: <20130806075350.497414fd@ernst.home> References: <20130806075350.497414fd@ernst.home> Date: Tue, 6 Aug 2013 09:02:23 -0700 X-Google-Sender-Auth: 9tvAW_-5vMmHFd1lVHpACeSvhIY Message-ID: Subject: Re: Kernel Panic on FreeBSD 10.0-CURRENT #1 r253918 From: Craig Rodrigues To: gljennjohn@googlemail.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "Sam Fourman Jr." , FreeBSD Current 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: Tue, 06 Aug 2013 16:02:26 -0000 On Mon, Aug 5, 2013 at 10:53 PM, Gary Jennejohn wrote: > On Mon, 5 Aug 2013 10:29:23 -0700 > Craig Rodrigues wrote: > > > > > On the booted an running system, if you type: > > > > sysctl kern.conftxt > > > > that will display the actual kernel config options used to build the > > running kernel. > > > > Not necessarily > > sysctl kern.conftxt > sysctl: unknown oid 'kern.conftxt': No such file or directory > I forgot to mention, sysctl kern.conftxt will only display something if you have this in your kernel config: options INCLUDE_CONFIG_FILE # Include this file in kernel It's always handy to have that in your kernel config. -- Craig From owner-freebsd-current@FreeBSD.ORG Tue Aug 6 16:36:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C54DD7FD; Tue, 6 Aug 2013 16:36:53 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7042527CF; Tue, 6 Aug 2013 16:36:53 +0000 (UTC) Received: by mail-ve0-f173.google.com with SMTP id cy12so655345veb.18 for ; Tue, 06 Aug 2013 09:36:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ulvq9zFS2gCXmgFLAwpqZbAKigMgLezpmt6idDMDMAc=; b=p4lteXVrpwE2m55eOYrCf4S5eDfYFSZ8QrGVcEXR086xGyxH9gjftw7bpWGi7FlESs OuXwiBZcH1HeoRSioRiMGww203nJV0BEHBNevONr6PRQjQdT0PVHf+xg1seZXlEplHdL JXTaCSkQgDnM15DyPN4pCPUvtp8rqBOtRN5tZ4YGtx4MkbUSmImztBfxuOqTh25x43P8 BvIDcm8Sjx76rplYCc87xS7zGoc8frordGmEmKeFKPadsjqagk7DimEfZ8Km8ma7p3tA Al5zYqNeGBfSc/1QkTGFOA8ShLSOqOAlKExztkxz/nI2MIRB+7oqMBeoO/H2n4/mo1gp 2xTA== MIME-Version: 1.0 X-Received: by 10.58.34.178 with SMTP id a18mr606026vej.86.1375807012282; Tue, 06 Aug 2013 09:36:52 -0700 (PDT) Received: by 10.220.96.78 with HTTP; Tue, 6 Aug 2013 09:36:52 -0700 (PDT) In-Reply-To: References: <20130806075350.497414fd@ernst.home> Date: Tue, 6 Aug 2013 12:36:52 -0400 Message-ID: Subject: Re: Kernel Panic on FreeBSD 10.0-CURRENT #1 r253918 From: "Sam Fourman Jr." To: Craig Rodrigues Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current 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: Tue, 06 Aug 2013 16:36:53 -0000 I forgot to mention, sysctl kern.conftxt > will only display something if you have this in your kernel config: > > options INCLUDE_CONFIG_FILE # Include this file in kernel > > It's always handy to have that in your kernel config. > > -- > Craig > No wonder why, it wasn't working for me and I didn't know why -- Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Tue Aug 6 16:43:58 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 150A8BA7 for ; Tue, 6 Aug 2013 16:43:58 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 462A62853 for ; Tue, 6 Aug 2013 16:43:57 +0000 (UTC) Received: (qmail 49916 invoked from network); 6 Aug 2013 17:29:43 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 6 Aug 2013 17:29:43 -0000 Message-ID: <520127C3.3020101@freebsd.org> Date: Tue, 06 Aug 2013 18:43:47 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: [net] protecting interfaces from races between control and data ? References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> <5200136C.8000201@freebsd.org> <20130805215319.GA43271@onelab2.iet.unipi.it> In-Reply-To: <20130805215319.GA43271@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , current@freebsd.org, Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri 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: Tue, 06 Aug 2013 16:43:58 -0000 On 05.08.2013 23:53, Luigi Rizzo wrote: > On Mon, Aug 05, 2013 at 11:04:44PM +0200, Andre Oppermann wrote: >> On 05.08.2013 19:36, Luigi Rizzo wrote: > ... >> >> [picking a post at random to reply in this thread] >>> tell whether or not we should bail out). >> >> Ideally we don't want to have any locks in the RX and TX path at all. > > Ok i have read your proposal below but there are a few things > I do not completely understand, below -- essentially I do not > understand whether the removal of IFF_DRV_RUNNING (or equivalent) > forces you to replace the ifp->new_tx_function() with something > else when you want to do an "ifconfig down" Sorry, it's IFF_DRV_OACTIVE that'll go away, not IFF_DRV_RUNNING. It's of no use with multi-queue anyways. Though we may get more differentiated states for interface availability. > Specifically, here are my doubts: > > - Considering that the rxq lock is rarely contended > (only when the control path is active, which in your approach > below requires killing and restarting the ithread), > and is acquired/released only once per interrupt/batch, > i am under the impression that the per-queue RX lock is > not a performance problem and makes it easier to reason > on the code (and does not require different approach > for MSI-x and other cases). There are two important things here: 1) there must only be one (i)thread per RX queue to prevent lock contention; 2) even with a non-contended lock there are effects felt by the other cores or CPUs like bus lock cycles which are considerable. Stopping and restarting the ithread/taskqueue in those cases that require more involved (hardware) reconfiguration isn't much of an overhead compared to per-packet or per-packet-batch locking in the hot path. > - in the tx datapath, do you want to acquire the txq lock > before or after calling ifp->new_tx_function() ? > (btw how it compares to ifp->if_start or ifp->if_transmit ?) Struct ifnet is going to be split into two parts, the stack owned part and the driver owned part. The stack will never fumble the driver owned parts and the driver must only change the stack owned parts through accessor functions. (This split has also been proposed by Juniper quite some time ago but for different reasons). The driver supplies a TX frame transmit function (mostly like if_transmit today) which does all locking and multi-queue handling internally (driver owned. This gives driver writers the freedom to better adjust to different hardware communication methods as they become available, like we witnessed a couple of times in the past. If the driver is multi-queue capable it takes the rss-hash from the packet header to select an appropriate queue which may have its own dedicated lock. If there is only one queue then it will obtain that lock which may see some contention when multiple cores try to send at the same time. The driver may do more extensive locking, however that likely comes at the expense of performance. Typically on modern NICs the TX function will be a thin locked wrapper around the DMA enqueue function. For or older or other kinds of interfaces it may implement full internal soft queuing (as the IFQ did). An efficient generic implementation of those will be provided for driver to make use of. > If you do it within the tx handler then you lose the ability > of replacing the handler when you do a reconfiguration, > because grabbing the tx lock in the control path does not tell > you whether anyone is in the handler. > If you do it outside, then the driver should also expose the locks, > or some locking function. The stack calls the transmit function without any driver-specific locks held. It'll make sure though that the stack-ifnet doesn't go away in between probably by using cheap rmlocks. The drivers control path gets a function to ensure that the stack has drained all writers and it is safe to reconfigure (as in callout_drain()). Not all hardware and control path changes necessarily require a reinitialization. The stack-ifnet shadows some information, like interface state, and may do its own independent SMP optimizations to avoid contention. > Overall, it seems to me that keeping the IFF_DRV_RUNNING > flag is a lot more practical, not to mention fewer modifications > to the code. Generally we want to optimize for the fast packet path, reduce any friction we can, and take a hit on reconfig being more "expensive" as it is much less frequent. Mind you not all of this is worked out in detail yet and may be subject to further changes and refinements as more benchmarking of different approaches is performed. -- Andre [PS: I'm currently on summer vacation and write this while having access] > [description of Andre's proposal below, for reference] > > cheers > luigi > >> Every queue has its own separate RX interrupt vector which is serviced by >> a single dedicated ithread (or taskqueue) which does while(1) for work on >> the RX ring only going to sleep when it reaches the end of work on the ring. >> It is then woken up by an interrupt to resume work. To prevent a live-lock >> on the CPU it would periodically yield to allow other kernel and user-space >> threads to run in between. Each queue's ithread (taskqueue) can be pinned >> to a particular core or float with a certain stickiness. To reconfigure the >> card (when the RX ring is affected) the ithread (taskqueue) is terminated >> and after the changes restarted again. This is done by the control path >> and allows us to run RX completely lock free because there is only ever one >> ithread accessing the RX queue doing away with the need for further locking >> synchronization. > > ok I admit i did not think of killing and restarting the ithread, > but i wonder how >> RX with MSI or legacy interrupts: >> >> Here multi-queue is impeded because of some synchronization issues. Depending >> on the hardware synchronization model the ithreads again do while(1) but have >> to be made runnable by the interrupt handler when new work has been indicated. >> >> TX in general: >> >> This is a bit more tricky as we have the hard requirement of packet ordering >> for individual sessions (tcp and others). That means we must use the same >> queue for all packets of the same session. This makes running TX non-locked >> a bit tricky because when we pin a TX queue to a core we must switch to that >> core first before adding anything to the queue. If the packet was generated >> on that core there is no overhead, OTOH if not there is the scheduler over- >> head and some cache losses. Ensuring that a the entire TX path, possibly >> including user-space (write et al) happens on the same core is difficult and >> may have its own inefficiencies. The number of TX queue vs. number of cores >> is another point of contention. To make the 1:1 scheme work well, one must >> have as many queues as cores. >> >> A more scalable and generic approach doesn't bind TX queues to any particular >> core and is covers each by its own lock to protect the TX ring enqueue. To >> prevent false lock cache line sharing each TX structure should be on its own >> cache line. As each session has an affinity hash they become distributed >> across the TX queues significantly reducing contention. >> >> The TX complete handling freeing the mbuf(s) is done the same way as for the >> RX ring with a dedicated ithread (taskqueue) for each. Also bpf should hook >> in here (the packet has been sent) instead of at the TX enqueue time. >> >> The whole concept of IFF_DRV_RUNNING will go away along with the IFQ macros. >> Each driver then provides a direct TX function pointer which is put into a >> decoupled ifnet TX field for use by the stack. Under normal operation all >> interface TX goes directly into TX DMA ring. The particular multi-queue >> and locking model is decided by the driver. The kernel provides a couple >> of common optimized abstractions for use by all drivers that want/need it >> to avoid code and functionality duplication. When things like ALTQ are >> activated on an interface the ifnet TX function pointer is replaced with >> the appropriate intermediate function pointer which eventually will call >> the drivers TX function. The intermediate TX packet handler (ALTQ) can >> do its own additional locking on top of the drivers TX locking. >> >> Control path: >> >> The control path is separate from the high speed TX and RX data paths. >> It has its own overall lock. Multiple locks typically don't make sense >> here. If it needs to modify, reconfigure, or newly set up the TX or RX >> rings then it has to stop the RX ithreads (taskqueues) and to lock the >> TX queue locks before it can do that. After the changes are made and >> stable packet processing can continue. >> >> I've adjusted / heavily modified fxp, bge and igb drivers in my tcp_workqueue >> branch to test these concepts. Not all of it is committed or fully up to date. >> >> -- >> Andre >> > > From owner-freebsd-current@FreeBSD.ORG Tue Aug 6 18:20:42 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 870E7C30; Tue, 6 Aug 2013 18:20:42 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5B02F2E1A; Tue, 6 Aug 2013 18:20:41 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id E811937B5BB; Tue, 6 Aug 2013 13:11:07 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3c8kRv1zjQzSqN; Tue, 6 Aug 2013 13:11:07 -0500 (CDT) Date: Tue, 6 Aug 2013 13:11:07 -0500 From: "Matthew D. Fuller" To: Glen Barber Subject: Re: svn error during 'make buildkernel'? Message-ID: <20130806181107.GR34979@over-yonder.net> References: <20130803210348.GA715@troutmask.apl.washington.edu> <20130803210858.GJ78299@glenbarber.us> <20130803213023.GA812@troutmask.apl.washington.edu> <20130803214313.GL78299@glenbarber.us> <20130804232358.GA6068@troutmask.apl.washington.edu> <20130805004433.GA6355@troutmask.apl.washington.edu> <20130805005530.GL2352@glenbarber.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130805005530.GL2352@glenbarber.us> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.21-fullermd.4 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.8 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: freebsd-current@freebsd.org, Peter Wemm , Steve Kargl 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: Tue, 06 Aug 2013 18:20:42 -0000 On Sun, Aug 04, 2013 at 08:55:30PM -0400 I heard the voice of Glen Barber, and lo! it spake thus: > > The error generated is non-fatal, and once I receive response on a > proposed patch, will be suppressed if the svn version used to check > out the tree is not compatible with that used to check the version > of the tree with the kernel build. But not try the ports svn as well? I mean, as breakage goes, it's not even in the top 100; I'd _much_ rather have a kernel that I have to guess the revision of but boots, than one properly recorded that doesn't. But it's still unpleasant, and is one of those things you probably won't notice missing until suddenly you need it. And this isn't just a presentism. Sure, right _now_ devel/subversion and base svnlite get along, but what happens when ports moves to 1.9 which changes the WT format? Even if -CURRENT src gets upgraded simultaneously[0], the same surely can't be said of every back branch. I realize this is all still a WIP, and please don't read any anger into my words. But this _has_ been something I've found a little worrisome since the original import/newvers change. Heck, newvers can show me version info if I'm getting my source tree from git or p4, but can't handle ports svn? By the time this works its way into a stable branch, I really think it should either handle svnversion from ports as well, or come with a big bright flashing warning that using svn from anything but base svnlite for /usr/src is a degraded experience. [0] Which still wouldn't really fix things, since /usr/bin/svnliteversion is arbitrarily old, not up to date with the source tree. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-current@FreeBSD.ORG Tue Aug 6 18:31:04 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 456F5ED6; Tue, 6 Aug 2013 18:31:04 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F06FA2E9A; Tue, 6 Aug 2013 18:31:03 +0000 (UTC) Received: from glenbarber.us (unknown [IPv6:2001:470:8:120e:1:1:c57c:729]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id D20CFA733; Tue, 6 Aug 2013 18:30:55 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us D20CFA733 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Tue, 6 Aug 2013 14:30:54 -0400 From: Glen Barber To: "Matthew D. Fuller" Subject: Re: svn error during 'make buildkernel'? Message-ID: <20130806183054.GB2190@glenbarber.us> References: <20130803210348.GA715@troutmask.apl.washington.edu> <20130803210858.GJ78299@glenbarber.us> <20130803213023.GA812@troutmask.apl.washington.edu> <20130803214313.GL78299@glenbarber.us> <20130804232358.GA6068@troutmask.apl.washington.edu> <20130805004433.GA6355@troutmask.apl.washington.edu> <20130805005530.GL2352@glenbarber.us> <20130806181107.GR34979@over-yonder.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="QTprm0S8XgL7H0Dt" Content-Disposition: inline In-Reply-To: <20130806181107.GR34979@over-yonder.net> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, Peter Wemm , Steve Kargl 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: Tue, 06 Aug 2013 18:31:04 -0000 --QTprm0S8XgL7H0Dt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 06, 2013 at 01:11:07PM -0500, Matthew D. Fuller wrote: > On Sun, Aug 04, 2013 at 08:55:30PM -0400 I heard the voice of > Glen Barber, and lo! it spake thus: > >=20 > > The error generated is non-fatal, and once I receive response on a > > proposed patch, will be suppressed if the svn version used to check > > out the tree is not compatible with that used to check the version > > of the tree with the kernel build. >=20 > But not try the ports svn as well? I mean, as breakage goes, it's not > even in the top 100; I'd _much_ rather have a kernel that I have to > guess the revision of but boots, than one properly recorded that > doesn't. But it's still unpleasant, and is one of those things you > probably won't notice missing until suddenly you need it. >=20 > And this isn't just a presentism. Sure, right _now_ devel/subversion > and base svnlite get along, but what happens when ports moves to 1.9 > which changes the WT format? Even if -CURRENT src gets upgraded > simultaneously[0], the same surely can't be said of every back branch. >=20 > I realize this is all still a WIP, and please don't read any anger > into my words. But this _has_ been something I've found a little > worrisome since the original import/newvers change. Heck, newvers can > show me version info if I'm getting my source tree from git or p4, but > can't handle ports svn? By the time this works its way into a stable > branch, I really think it should either handle svnversion from ports > as well, or come with a big bright flashing warning that using svn > from anything but base svnlite for /usr/src is a degraded experience. >=20 >=20 > [0] Which still wouldn't really fix things, since > /usr/bin/svnliteversion is arbitrarily old, not up to date with > the source tree. >=20 I have this on my todo list, but right now I have bigger things to deal with. As soon as I can, I will fix the logic. Right now, it is not "as easy as checking which svn works", because the more I look at the logic for newvers.sh, the more I dislike how it all works. Glen --QTprm0S8XgL7H0Dt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBCAAGBQJSAUDeAAoJEFJPDDeguUaj2xIH/11KAffErE4gjYwBxuPe43h+ CNCtuQjxMm6iqowJNap6MnShYHKiTmllqHdIgo+qk9MIKJjw6EDq3ox+7kAaht69 eMEaYGkVQkKBK7i0+gyR/xApLHWx2WSlpUt4xhWKL67ScISOToYv2MWMO7IahRV7 GtzHfiP+DxEfYZ7xYp4h68T/M2TNnOQdDclP6n82ii3tJbPKX6jYJzxP52fWPFpK Zu/9kRbKdAzfuOkk2z068Vrp8KCSvE25+/d/BjziTPNIs9MTZW1HVSBtjuUn1moq JgBfeEVJrO1Dhs7+FgBtDh0AZmcUtzL0HV2wfyCBWdwm1NABXJ8jMHIOn6uS6tc= =suAp -----END PGP SIGNATURE----- --QTprm0S8XgL7H0Dt-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 6 22:55:43 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 90825B9F; Tue, 6 Aug 2013 22:55:43 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 002AE2957; Tue, 6 Aug 2013 22:55:41 +0000 (UTC) Received: by mail-la0-f46.google.com with SMTP id eh20so742602lab.19 for ; Tue, 06 Aug 2013 15:55:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qS39UwrZbO6GBzSgTi/tEiqoEzpCy/+oszbaWnu6jlM=; b=D0G/WC1+bKvlGwGryXpLFFoX7FSVEaSimjckU1TV0zjA4GPaIiWQHOlFZf/aRjDzqq vyM+ayqJzGFg2Qoks4a5it3K+sAJajJqiQzToUuGC2Ax3xYdTF+8Qzd/ALkp2Ntmqh3w 6Nkp7NIWOPAIIDL7ZKoiZ6yTAEUxp0ro9Kvyr6PRq+2ei4xmZOdzV/uFHSs2QbBOwzbL FG7j7eoT63n9nBm2Qlf3UwKIBGE/y8XUcwf8oVPMRt7+K2UXWDblR3bA8HN3PxWHYAkh ipknG4ApY6io8XXHIaujZI1dUrL0971lw4DUyxQeJaVuTx0TBz9IxA8Wt8cXO+HO/mOn PZ2w== MIME-Version: 1.0 X-Received: by 10.112.134.202 with SMTP id pm10mr423807lbb.79.1375829739818; Tue, 06 Aug 2013 15:55:39 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.200.165 with HTTP; Tue, 6 Aug 2013 15:55:39 -0700 (PDT) In-Reply-To: <520127C3.3020101@freebsd.org> References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> <5200136C.8000201@freebsd.org> <20130805215319.GA43271@onelab2.iet.unipi.it> <520127C3.3020101@freebsd.org> Date: Wed, 7 Aug 2013 00:55:39 +0200 X-Google-Sender-Auth: jbbZQ-QJDDC23Bo6q3t8fnY-dD0 Message-ID: Subject: Re: [net] protecting interfaces from races between control and data ? From: Luigi Rizzo To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Adrian Chadd , current@freebsd.org, Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri 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: Tue, 06 Aug 2013 22:55:43 -0000 thanks for the explanations and for experimenting with the various alternatives. I started this thread just to understand whether something was already in place, and to make sure that what I do with netmap is not worse than the situation we have now. I guess that while the best solution comes out, a quick and non intrusive workaround is at least follow the approach that Bryan suggested. cheers luigi On Tue, Aug 6, 2013 at 6:43 PM, Andre Oppermann wrote: > On 05.08.2013 23:53, Luigi Rizzo wrote: > >> On Mon, Aug 05, 2013 at 11:04:44PM +0200, Andre Oppermann wrote: >> >>> On 05.08.2013 19:36, Luigi Rizzo wrote: >>> >> ... >> >>> >>> [picking a post at random to reply in this thread] >>> >>>> tell whether or not we should bail out). >>>> >>> >>> Ideally we don't want to have any locks in the RX and TX path at all. >>> >> >> Ok i have read your proposal below but there are a few things >> I do not completely understand, below -- essentially I do not >> understand whether the removal of IFF_DRV_RUNNING (or equivalent) >> forces you to replace the ifp->new_tx_function() with something >> else when you want to do an "ifconfig down" >> > > Sorry, it's IFF_DRV_OACTIVE that'll go away, not IFF_DRV_RUNNING. > It's of no use with multi-queue anyways. Though we may get more > differentiated states for interface availability. > > > Specifically, here are my doubts: >> >> - Considering that the rxq lock is rarely contended >> (only when the control path is active, which in your approach >> below requires killing and restarting the ithread), >> and is acquired/released only once per interrupt/batch, >> i am under the impression that the per-queue RX lock is >> not a performance problem and makes it easier to reason >> on the code (and does not require different approach >> for MSI-x and other cases). >> > > There are two important things here: 1) there must only be one > (i)thread per RX queue to prevent lock contention; 2) even with > a non-contended lock there are effects felt by the other cores > or CPUs like bus lock cycles which are considerable. Stopping > and restarting the ithread/taskqueue in those cases that require > more involved (hardware) reconfiguration isn't much of an overhead > compared to per-packet or per-packet-batch locking in the hot path. > > > - in the tx datapath, do you want to acquire the txq lock >> before or after calling ifp->new_tx_function() ? >> (btw how it compares to ifp->if_start or ifp->if_transmit ?) >> > > Struct ifnet is going to be split into two parts, the stack owned > part and the driver owned part. The stack will never fumble the > driver owned parts and the driver must only change the stack owned > parts through accessor functions. (This split has also been proposed > by Juniper quite some time ago but for different reasons). > > The driver supplies a TX frame transmit function (mostly like if_transmit > today) which does all locking and multi-queue handling internally (driver > owned. This gives driver writers the freedom to better adjust to different > hardware communication methods as they become available, like we witnessed > a couple of times in the past. > > If the driver is multi-queue capable it takes the rss-hash from the packet > header > to select an appropriate queue which may have its own dedicated lock. If > there > is only one queue then it will obtain that lock which may see some > contention > when multiple cores try to send at the same time. The driver may do more > extensive locking, however that likely comes at the expense of performance. > > Typically on modern NICs the TX function will be a thin locked wrapper > around > the DMA enqueue function. For or older or other kinds of interfaces it may > implement full internal soft queuing (as the IFQ did). An efficient > generic > implementation of those will be provided for driver to make use of. > > > > If you do it within the tx handler then you lose the ability > > of replacing the handler when you do a reconfiguration, > > because grabbing the tx lock in the control path does not tell > > you whether anyone is in the handler. > > If you do it outside, then the driver should also expose the locks, > > or some locking function. > > The stack calls the transmit function without any driver-specific locks > held. > It'll make sure though that the stack-ifnet doesn't go away in between > probably > by using cheap rmlocks. > > The drivers control path gets a function to ensure that the stack has > drained > all writers and it is safe to reconfigure (as in callout_drain()). Not all > hardware and control path changes necessarily require a reinitialization. > > The stack-ifnet shadows some information, like interface state, and may do > its > own independent SMP optimizations to avoid contention. > > > Overall, it seems to me that keeping the IFF_DRV_RUNNING >> flag is a lot more practical, not to mention fewer modifications >> to the code. >> > > Generally we want to optimize for the fast packet path, reduce any > friction we > can, and take a hit on reconfig being more "expensive" as it is much less > frequent. > > Mind you not all of this is worked out in detail yet and may be subject to > further changes and refinements as more benchmarking of different > approaches > is performed. > > -- > Andre > > [PS: I'm currently on summer vacation and write this while having access] > > > [description of Andre's proposal below, for reference] >> >> cheers >> luigi >> >> Every queue has its own separate RX interrupt vector which is serviced by >>> a single dedicated ithread (or taskqueue) which does while(1) for work on >>> the RX ring only going to sleep when it reaches the end of work on the >>> ring. >>> It is then woken up by an interrupt to resume work. To prevent a >>> live-lock >>> on the CPU it would periodically yield to allow other kernel and >>> user-space >>> threads to run in between. Each queue's ithread (taskqueue) can be >>> pinned >>> to a particular core or float with a certain stickiness. To reconfigure >>> the >>> card (when the RX ring is affected) the ithread (taskqueue) is terminated >>> and after the changes restarted again. This is done by the control path >>> and allows us to run RX completely lock free because there is only ever >>> one >>> ithread accessing the RX queue doing away with the need for further >>> locking >>> synchronization. >>> >> >> ok I admit i did not think of killing and restarting the ithread, >> but i wonder how >> >>> RX with MSI or legacy interrupts: >>> >>> Here multi-queue is impeded because of some synchronization issues. >>> Depending >>> on the hardware synchronization model the ithreads again do while(1) but >>> have >>> to be made runnable by the interrupt handler when new work has been >>> indicated. >>> >>> TX in general: >>> >>> This is a bit more tricky as we have the hard requirement of packet >>> ordering >>> for individual sessions (tcp and others). That means we must use the >>> same >>> queue for all packets of the same session. This makes running TX >>> non-locked >>> a bit tricky because when we pin a TX queue to a core we must switch to >>> that >>> core first before adding anything to the queue. If the packet was >>> generated >>> on that core there is no overhead, OTOH if not there is the scheduler >>> over- >>> head and some cache losses. Ensuring that a the entire TX path, possibly >>> including user-space (write et al) happens on the same core is difficult >>> and >>> may have its own inefficiencies. The number of TX queue vs. number of >>> cores >>> is another point of contention. To make the 1:1 scheme work well, one >>> must >>> have as many queues as cores. >>> >>> A more scalable and generic approach doesn't bind TX queues to any >>> particular >>> core and is covers each by its own lock to protect the TX ring enqueue. >>> To >>> prevent false lock cache line sharing each TX structure should be on its >>> own >>> cache line. As each session has an affinity hash they become distributed >>> across the TX queues significantly reducing contention. >>> >>> The TX complete handling freeing the mbuf(s) is done the same way as for >>> the >>> RX ring with a dedicated ithread (taskqueue) for each. Also bpf should >>> hook >>> in here (the packet has been sent) instead of at the TX enqueue time. >>> >>> The whole concept of IFF_DRV_RUNNING will go away along with the IFQ >>> macros. >>> Each driver then provides a direct TX function pointer which is put into >>> a >>> decoupled ifnet TX field for use by the stack. Under normal operation >>> all >>> interface TX goes directly into TX DMA ring. The particular multi-queue >>> and locking model is decided by the driver. The kernel provides a couple >>> of common optimized abstractions for use by all drivers that want/need it >>> to avoid code and functionality duplication. When things like ALTQ are >>> activated on an interface the ifnet TX function pointer is replaced with >>> the appropriate intermediate function pointer which eventually will call >>> the drivers TX function. The intermediate TX packet handler (ALTQ) can >>> do its own additional locking on top of the drivers TX locking. >>> >>> Control path: >>> >>> The control path is separate from the high speed TX and RX data paths. >>> It has its own overall lock. Multiple locks typically don't make sense >>> here. If it needs to modify, reconfigure, or newly set up the TX or RX >>> rings then it has to stop the RX ithreads (taskqueues) and to lock the >>> TX queue locks before it can do that. After the changes are made and >>> stable packet processing can continue. >>> >>> I've adjusted / heavily modified fxp, bge and igb drivers in my >>> tcp_workqueue >>> branch to test these concepts. Not all of it is committed or fully up >>> to date. >>> >>> -- >>> Andre >>> >>> >> >> > -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-current@FreeBSD.ORG Wed Aug 7 06:13:39 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 704ACD41 for ; Wed, 7 Aug 2013 06:13:39 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.21.123]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E86402954 for ; Wed, 7 Aug 2013 06:13:38 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [193.68.6.1]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.6/8.14.6) with ESMTP id r776DSJY087201 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 7 Aug 2013 09:13:29 +0300 (EEST) (envelope-from daniel@digsys.bg) Message-ID: <5201E588.5040604@digsys.bg> Date: Wed, 07 Aug 2013 09:13:28 +0300 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130731 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: svn error during 'make buildkernel'? References: <20130803210348.GA715@troutmask.apl.washington.edu> <20130803210858.GJ78299@glenbarber.us> <20130803213023.GA812@troutmask.apl.washington.edu> <20130803214313.GL78299@glenbarber.us> <20130804232358.GA6068@troutmask.apl.washington.edu> <20130805004433.GA6355@troutmask.apl.washington.edu> <20130805005530.GL2352@glenbarber.us> <20130806181107.GR34979@over-yonder.net> In-Reply-To: <20130806181107.GR34979@over-yonder.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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: Wed, 07 Aug 2013 06:13:39 -0000 On 06.08.13 21:11, Matthew D. Fuller wrote: > Sure, right _now_ devel/subversion and base svnlite get along, but > what happens when ports moves to 1.9 which changes the WT format? This is just one of the quirks that subversion has, in that it's database can't be easily parsed with other tools. Perhaps a "fix" might be caching the last revision number in a text file so you don't need svnversion in order to extract it from the source tree? A fix/patch to subversion, that is. Daniel From owner-freebsd-current@FreeBSD.ORG Wed Aug 7 06:43:50 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 44E4BAA8; Wed, 7 Aug 2013 06:43:50 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 166A82AA6; Wed, 7 Aug 2013 06:43:49 +0000 (UTC) Received: from jre-mbp.elischer.org (etroy.elischer.org [121.45.226.51]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.6) with ESMTP id r776hDhI083962 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 6 Aug 2013 23:43:22 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5201EC7C.4010209@freebsd.org> Date: Wed, 07 Aug 2013 14:43:08 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Bryan Venteicher Subject: Re: [CFT] VMware vmxnet3 ethernet driver References: <1050637258.686.1375660230986.JavaMail.root@daemoninthecloset.org> <601099152.721.1375661537866.JavaMail.root@daemoninthecloset.org> <20130805202039.GA18861@devbox.vnode.local> <1174186801.993.1375743121722.JavaMail.root@daemoninthecloset.org> In-Reply-To: <1174186801.993.1375743121722.JavaMail.root@daemoninthecloset.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, Joel Dahl 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: Wed, 07 Aug 2013 06:43:50 -0000 On 8/6/13 6:52 AM, Bryan Venteicher wrote: > > ----- Original Message ----- >> I have ~100 FreeBSD 8/9 VMs in my vSphere 5.1 environment, all using the >> VMware tools package from VMware. Everything has been running great for >> years. >> (we skipped vSphere 5.0). Why should I use this vmxnet driver instead of the >> VMware tools driver or the emulated e1000? >> > They are out of tree and subject to rotting. I had to use the patches > at [1] to even get them to compile on 9.1 and -current. I don't think > VMware puts much engineering resources behind it; there was a compiler > warning of a silly bug like: > if (foo) ; > do_something(); > > vmxnet3 has modern features LRO, IPv6 checksum offloading, etc that > the emulated e1000 lacks. In my test setup, e1000 tops out at 30MB/sec > but vmxnet3 goes to 50MB/sec. I'd like to hear other's experiences. it'd be nice if we could get vmware to just support the drivers in tree.. by which I mean, just submit patches.. why do they need to have it out of tree? > > [1] - http://ogris.de/vmware/ > >> -- >> Joel >> > _______________________________________________ > 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 Wed Aug 7 07:18:03 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B089A427; Wed, 7 Aug 2013 07:18:03 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 520FC2C56; Wed, 7 Aug 2013 07:18:02 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id u10so1255543lbi.28 for ; Wed, 07 Aug 2013 00:18:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=0KxcqGC3WvWiRDlyeUqaPPUJNeQU620FtJBwCg/XN4c=; b=jOAWpdA8Cq+lwF5MdP33CeExc4xFk6p8i3RX3LRbwdgDZrnEeVhrAcO52oaRyFwnHr nZcOCyxtsjpifhxu8uHP6qOBWdnJyVdSrM8DiZFL0c8aNFuGqixiYeHd7ffakPCoSSI5 8P+WMo3JjgkYNt4ePl5tQkwfYbWvKgnjPGcwjruag4WWmXCt+B+wUrbufMG5jHGY4oOx iiQGkbZhzcsIjV8sq++GAS2cIXfYhKki4Z6OmMqtSfUpoGVwORkXatmMwSYIsD2xHB+j SBR7592Zybgygn3aoGOflCsyuWDDvaeZcMERGM/EGUGyWT8mezSSHob2ByQudeQtwdX1 uMTA== MIME-Version: 1.0 X-Received: by 10.152.19.97 with SMTP id d1mr795779lae.34.1375859880203; Wed, 07 Aug 2013 00:18:00 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.200.165 with HTTP; Wed, 7 Aug 2013 00:17:59 -0700 (PDT) In-Reply-To: <201308070326.r773QCLD035541@mail.karels.net> References: <20130805215319.GA43271@onelab2.iet.unipi.it> <201308070326.r773QCLD035541@mail.karels.net> Date: Wed, 7 Aug 2013 09:18:00 +0200 X-Google-Sender-Auth: a7yRlQjeUh-lwQ89EstnIQoZ08w Message-ID: Subject: Re: [net] protecting interfaces from races between control and data ? From: Luigi Rizzo To: mike@karels.net Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Adrian Chadd , Andre Oppermann , current@freebsd.org, Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri 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: Wed, 07 Aug 2013 07:18:03 -0000 On Wed, Aug 7, 2013 at 5:26 AM, Mike Karels wrote: > I'm replying to one of the last messages of this thread, but in part going > back to the beginning; then I'm following up on Andre's proposal. > > Luigi wrote: > > i am slightly unclear of what mechanisms we use to prevent races > > between interface being reconfigured (up/down/multicast setting, etc, > > all causing reinitialization of the rx and tx rings) and > > > i) packets from the host stack being sent out; > > ii) interrupts from the network card being processed. > > > I think in the old times IFF_DRV_RUNNING was used for this purpose, > > but now it is not enough. > > Acquiring the "core lock" in the NIC does not seem enough, either, > > because newer drivers, especially multiqueue ones, have per-queue > > rx and tx locks. > > > Does anyone know if there is a generic mechanism, or each driver > > reimplements its own way ? > > I'm not sure I understand the question, or its motivation. What problem(s) > are we trying to solve here? It seems to me that this is mostly internal > to drivers, and I don't see the issue with races. In particular, the only > external guarantees that I see are that control operations will affect the > packet stream "soon" but at some undefined place. Not all of the cited > operations (e.g. multicast changes) need to cause the rings to be > reinitialized; if they do, that's a chip or driver flaw. Clearing the UP > flag should cause packets to stop arriving "soon", but presumably > processing > those already in memory; packets to stop being sent "soon", probably > including > some already accepted for transmission; and new attempts to transmit > receiving > an error "soon". And, of course, the driver should not crash or misbehave. > Other than that, I don't see what external guarantees need to be met. > i only want 'driver should not crash or misbehave', which is something that (I believe) many current drivers do not guarantee because of the races mentioned in the thread (control path reinitializes rings without waiting for the datapath to drain). My specific problem was achieving this safe behaviour when moving between netmap mode and regular mode; i hoped i could replicate whatever scheme was implemented by the drivers in 'normal' mode, and this is when i realized that there was no such protection in place. Jumping to (near) the end of the thread, I like most of Andre's proposal. > Running with minimal locks at this layer is an admirable goal, and I agree > with most of what was said. I have a few observations on the general > changes, > or related issues: > > There was mention of taskqueues. I think that with MSI-X, taskqueues > should not be needed or used. More specifically, having separate ithreads > and taskqueues, with ithreads deferring to taskqueues after some limit, > makes > sense only for MSI and legacy interrupts. With MSI-X, an interrupt thread > should be able to process packets indefinitely with sufficient CPU > resources, > and there is no reason to context switch to a different thread > periodically. > A periodic "yield" might be reasonable, but if it is necessary, small > packet > performance will suffer. However, most of this is internal to the driver. > i am not completely clear on what is the difference between ithreads and taskqueues. Also, Andre's proposal requires to force-kill the ithread, but i am unclear on how to do it safely (i.e. without leaving the data structures in some inconsistent state), unless ithread periodically yields the CPU when it is in a safe state. While this is internal to the driver, we should probably provide some template code to avoid that each driver implements its own way to shutdown the ithread. cheers luigi From owner-freebsd-current@FreeBSD.ORG Wed Aug 7 10:31:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B0186DAD for ; Wed, 7 Aug 2013 10:31:58 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward9l.mail.yandex.net (forward9l.mail.yandex.net [IPv6:2a02:6b8:0:1819::9]) by mx1.freebsd.org (Postfix) with ESMTP id 567A62F07 for ; Wed, 7 Aug 2013 10:31:58 +0000 (UTC) Received: from smtp12.mail.yandex.net (smtp12.mail.yandex.net [95.108.131.191]) by forward9l.mail.yandex.net (Yandex) with ESMTP id 79E4AE614E2; Wed, 7 Aug 2013 14:31:53 +0400 (MSK) Received: from smtp12.mail.yandex.net (localhost [127.0.0.1]) by smtp12.mail.yandex.net (Yandex) with ESMTP id 23A1716A0783; Wed, 7 Aug 2013 14:31:53 +0400 (MSK) Received: from 93.91.10.81.tel.ru (93.91.10.81.tel.ru [93.91.10.81]) by smtp12.mail.yandex.net (nwsmtp/Yandex) with ESMTP id W37e433bHN-Vo5OXCOd; Wed, 7 Aug 2013 14:31:51 +0400 Message-ID: <52022214.7080200@passap.ru> Date: Wed, 07 Aug 2013 14:31:48 +0400 From: Boris Samorodov Organization: =?UTF-8?B?0JfQkNCeICLQktCQ0KDQoiI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130806 Thunderbird/17.0.7 MIME-Version: 1.0 To: Robert Huff Subject: Re: "make buildworld" fails References: <51FFD21A.3050602@passap.ru> <20992.14618.332769.261961@jerusalem.litteratus.org> In-Reply-To: <20992.14618.332769.261961@jerusalem.litteratus.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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: Wed, 07 Aug 2013 10:31:58 -0000 06.08.2013 03:45, Robert Huff пишет: > > Boris Samorodov writes: > >> This note from /usr/src/UPDATING may be relevant: >> ----- >> 20130613: >> Some people report the following error after the switch to bmake: >> >> make: illegal option -- J >> usage: make [-BPSXeiknpqrstv] [-C directory] [-D variable] >> ... >> *** [buildworld] Error code 2 >> >> this likely due to an old instance of make in >> ${MAKEPATH} (${MAKEOBJDIRPREFIX}${.CURDIR}/make.${MACHINE}) >> which src/Makefile will use that blindly, if it exists, so if >> you see the above error: >> >> rm -rf `make -V MAKEPATH` >> >> should resolve it. > > Would that it were so. :-( > 1) > > huff@>> make -V MAKEPATH > > huff@>> > > 2) After running the above, buildworld stops at the same place: > > (cd /usr/src && make bmake) > echo > > echo "--------------------------------------------------------------" > -------------------------------------------------------------- > echo ">>> Building an up-to-date make(1)" >>>> Building an up-to-date make(1) > echo "--------------------------------------------------------------" > -------------------------------------------------------------- > cd /usr/src/usr.bin/bmake; MAKEOBJDIRPREFIX=/usr/obj/usr/src/make.amd64 DESTDIR= INSTALL="sh /usr/src/tools/install.sh" make -D_UPGRADING -DNOMAN -DNO_MAN -DNOSHARED -DNO_SHARED -DNO_CPU_CFLAGS -DNO_WERROR obj && MAKEOBJDIRPREFIX=/usr/obj/usr/src/make.amd64 DESTDIR= INSTALL="sh /usr/src/tools/install.sh" make -D_UPGRADING -DNOMAN -DNO_MAN -DNOSHARED -DNO_SHARED -DNO_CPU_CFLAGS -DNO_WERROR depend && MAKEOBJDIRPREFIX=/usr/obj/usr/src/make.amd64 DESTDIR= INSTALL="sh /usr/src/tools/install.sh" make -D_UPGRADING -DNOMAN -DNO_MAN -DNOSHARED -DNO_SHARED -DNO_CPU_CFLAGS -DNO_WERROR all && MAKEOBJDIRPREFIX=/usr/obj/usr/src/make.amd64 DESTDIR= INSTALL="sh /usr/src/tools/install.sh" make -D_UPGRADING -DNOMAN -DNO_MAN -DNOSHARED -DNO_SHARED -DNO_CPU_CFLAGS -DNO_WERROR install DESTDIR=/usr/obj/usr/src/make.amd64 BINDIR= PROGNAME=bmake > if ! test -d /usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake/; then mkdir -p /usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake; if ! test -d /usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake/; then echo "Unable to create /usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake."; exit 1; fi; echo "/usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake created for /usr/src/usr.bin/bmake"; fi > /usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake created for /usr/src/usr.bin/bmake > set -e; for entry in unit-tests; do if test -d /usr/src/usr.bin/bmake/${entry}.amd64; then echo "===> ${entry}.amd64 (obj)"; edir=${entry}.amd64; cd /usr/src/usr.bin/bmake/${edir}; else echo "===> $entry (obj)"; edir=${entry}; cd /usr/src/usr.bin/bmake/${edir}; fi; make obj DIRPRFX=$edir/; done > ===> unit-tests (obj) > if ! test -d /usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake/unit-tests/; then mkdir -p /usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake/unit-tests; if ! test -d /usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake/unit-tests/; then echo "Unable to create /usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake/unit-tests."; exit 1; fi; echo "/usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake/unit-tests created for /usr/src/usr.bin/bmake/unit-tests"; fi > /usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake/unit-tests created for /usr/src/usr.bin/bmake/unit-tests > rm -f .depend > mkdep -f .depend -a -DNO_PWD_OVERRIDE -I/usr/src/usr.bin/bmake -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/usr/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 /usr/src/contrib/bmake/arch.c /usr/src/contrib/bmake/buf.c /usr/src/contrib/bmake/compat.c /usr/src/contrib/bmake/cond.c /usr/src/contrib/bmake/dir.c /usr/src/contrib/bmake/for.c /usr/src/contrib/bmake/hash.c /usr/src/contrib/bmake/job.c /usr/src/contrib/bmake/main.c /usr/src/contrib/bmake/make.c /usr/src/contrib/bmake/make_malloc.c /usr/src/contrib/bmake/meta.c /usr/src/contrib/bmake/parse.c /usr/src/contrib/bmake/str.c /usr/src/contrib/bmake/strlist.c /usr/src/contrib/bmake/suff.c /usr/src/contrib/bmake/targ.c /usr/src/contrib/bmake/trace.c /usr/src/contrib/bmake/util.c /usr/src/contrib/bmake/var.c /usr/src/contrib/bmake/lst.lib/lstAppend.c /usr/src/contrib/bmake/lst.lib/lstAtEnd.c /usr/src/contrib/bmake/ls t.lib/lst AtFront.c /usr/src/contrib/bmake/lst.lib/lstClose.c /usr/src/contrib/bmake/lst.lib/lstConcat.c /usr/src/contrib/bmake/lst.lib/lstDatum.c /usr/src/contrib/bmake/lst.lib/lstDeQueue.c /usr/src/contrib/bmake/lst.lib/lstDestroy.c /usr/src/contrib/bmake/lst.lib/lstDupl.c /usr/src/contrib/bmake/lst.lib/lstEnQueue.c /usr/src/contrib/bmake/lst.lib/lstFind.c /usr/src/contrib/bmake/lst.lib/lstFindFrom.c /usr/src/contrib/bmake/lst.lib/lstFirst.c /usr/src/contrib/bmake/lst.lib/lstForEach.c /usr/src/contrib/bmake/lst.lib/lstForEachFrom.c /usr/src/contrib/bmake/lst.lib/lstInit.c /usr/src/contrib/bmake/lst.lib/lstInsert.c /usr/src/contrib/bmake/lst.lib/lstIsAtEnd.c /usr/src/contrib/bmake/lst.lib/lstIsEmpty.c /usr/src/contrib/bmake/lst.lib/lstLast.c /usr/src/contrib/bmake/lst.lib/lstMember.c /usr/src/contrib/bmake/lst.lib/lstNext.c /usr/src/contrib/bmake/lst.lib/lstOpen.c /usr/src/contrib/bmake/lst.lib/lstPrev.c /usr/src/contrib/bmake/lst.lib/lstRemove.c /usr/src/contrib/bmake/lst.lib/lstRepl ace.c /us r/src/contrib/bmake/lst.lib/lstSucc.c /usr/src/contrib/bmake/stresep.c > echo make: /usr/lib/libc.a >> .depend > cc -O -pipe -g -DNO_PWD_OVERRIDE -I/usr/src/usr.bin/bmake -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/usr/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -c /usr/src/contrib/bmake/arch.c > cc -O -pipe -g -DNO_PWD_OVERRIDE -I/usr/src/usr.bin/bmake -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/usr/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -c /usr/src/contrib/bmake/buf.c > cc -O -pipe -g -DNO_PWD_OVERRIDE -I/usr/src/usr.bin/bmake -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/usr/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -c /usr/src/contrib/bmake/compat.c > > . > . > . > > cc -O -pipe -g -DNO_PWD_OVERRIDE -I/usr/src/usr.bin/bmake -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/usr/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -static -o make arch.o buf.o compat.o cond.o dir.o for.o hash.o job.o main.o make.o make_malloc.o meta.o parse.o str.o strlist.o suff.o targ.o trace.o util.o var.o lstAppend.o lstAtEnd.o lstAtFront.o lstClose.o lstConcat.o lstDatum.o lstDeQueue.o lstDestroy.o lstDupl.o lstEnQueue.o lstFind.o lstFindFrom.o lstFirst.o lstForEach.o lstForEachFrom.o lstInit.o lstInsert.o lstIsAtEnd.o lstIsEmpt y.o lstLast.o lstMember.o lstNext.o lstOpen.o lstPrev.o lstRemove.o lstReplace.o lstSucc.o stresep.o > sh /usr/src/tools/install.sh -o root -g wheel -m 555 make /usr/obj/usr/src/make.amd64/bmake > cd /usr/src; PATH=/sbin:/bin:/usr/sbin:/usr/bin `test -x /usr/obj/usr/src/make.amd64/bmake && echo /usr/obj/usr/src/make.amd64/bmake || echo make` -m /usr/src/share/mk -f Makefile.inc1 TARGET=amd64 TARGET_ARCH=amd64 buildworld > usage: bmake [-BeikNnqrstWwX] > [-C directory] [-D variable] [-d flags] [-f makefile] > [-I directory] [-J private] [-j max_jobs] [-m directory] [-T file] > [-V variable] [variable=value] [target ...] > *** [buildworld] Error code 2 > > Stop in /usr/src. OK, the note may be written not user-friendly. Well, I've had something like you get: http://lists.freebsd.org/pipermail/freebsd-current/2013-May/041976.html The culprit was /usr/obj/usr/src/make.amd64/make. Seems to be your case as well. BTW, total removing of /usr/src should help also. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Wed Aug 7 11:14:43 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1A2B44AE for ; Wed, 7 Aug 2013 11:14:43 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D1D212275 for ; Wed, 7 Aug 2013 11:14:42 +0000 (UTC) Received: from coleburn.avinity.tv (host-229-161-243.77.avinity.tv [77.243.161.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 64D9E5C5A; Wed, 7 Aug 2013 13:14:33 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: "make buildworld" fails From: Dimitry Andric In-Reply-To: <52022214.7080200@passap.ru> Date: Wed, 7 Aug 2013 13:14:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8C019F08-0432-42E2-9A43-88D1D13C8014@andric.com> References: <51FFD21A.3050602@passap.ru> <20992.14618.332769.261961@jerusalem.litteratus.org> <52022214.7080200@passap.ru> To: Boris Samorodov X-Mailer: Apple Mail (2.1508) Cc: Robert Huff , 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: Wed, 07 Aug 2013 11:14:43 -0000 On Aug 7, 2013, at 12:31, Boris Samorodov wrote: > 06.08.2013 03:45, Robert Huff =D0=BF=D0=B8=D1=88=D0=B5=D1=82: ... >> cd /usr/src; PATH=3D/sbin:/bin:/usr/sbin:/usr/bin `test -x = /usr/obj/usr/src/make.amd64/bmake && echo = /usr/obj/usr/src/make.amd64/bmake || echo make` -m /usr/src/share/mk -f = Makefile.inc1 TARGET=3Damd64 TARGET_ARCH=3Damd64 buildworld >> usage: bmake [-BeikNnqrstWwX]=20 >> [-C directory] [-D variable] [-d flags] [-f makefile] >> [-I directory] [-J private] [-j max_jobs] [-m directory] = [-T file] >> [-V variable] [variable=3Dvalue] [target ...] >> *** [buildworld] Error code 2 >>=20 >> Stop in /usr/src. >=20 > OK, the note may be written not user-friendly. >=20 > Well, I've had something like you get: > = http://lists.freebsd.org/pipermail/freebsd-current/2013-May/041976.html >=20 > The culprit was /usr/obj/usr/src/make.amd64/make. Seems to be your = case > as well. >=20 > BTW, total removing of /usr/src should help also. I assume you meant /usr/obj here? :-) -Dimitry From owner-freebsd-current@FreeBSD.ORG Wed Aug 7 12:13:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5E56DE94 for ; Wed, 7 Aug 2013 12:13:21 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward2l.mail.yandex.net (forward2l.mail.yandex.net [IPv6:2a02:6b8:0:1819::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1D73826F1 for ; Wed, 7 Aug 2013 12:13:21 +0000 (UTC) Received: from smtp12.mail.yandex.net (smtp12.mail.yandex.net [95.108.131.191]) by forward2l.mail.yandex.net (Yandex) with ESMTP id EE4321AC148A; Wed, 7 Aug 2013 16:13:18 +0400 (MSK) Received: from smtp12.mail.yandex.net (localhost [127.0.0.1]) by smtp12.mail.yandex.net (Yandex) with ESMTP id 787E116A04F3; Wed, 7 Aug 2013 16:13:18 +0400 (MSK) Received: from 93.91.10.81.tel.ru (93.91.10.81.tel.ru [93.91.10.81]) by smtp12.mail.yandex.net (nwsmtp/Yandex) with ESMTP id ICyuTnJesb-DI5arDas; Wed, 7 Aug 2013 16:13:18 +0400 Message-ID: <520239DD.5090106@passap.ru> Date: Wed, 07 Aug 2013 16:13:17 +0400 From: Boris Samorodov Organization: =?UTF-8?B?0JfQkNCeICLQktCQ0KDQoiI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130806 Thunderbird/17.0.7 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: "make buildworld" fails References: <51FFD21A.3050602@passap.ru> <20992.14618.332769.261961@jerusalem.litteratus.org> <52022214.7080200@passap.ru> <8C019F08-0432-42E2-9A43-88D1D13C8014@andric.com> In-Reply-To: <8C019F08-0432-42E2-9A43-88D1D13C8014@andric.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Robert Huff , 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: Wed, 07 Aug 2013 12:13:21 -0000 07.08.2013 15:14, Dimitry Andric пишет: > On Aug 7, 2013, at 12:31, Boris Samorodov wrote: >> 06.08.2013 03:45, Robert Huff пишет: > ... >>> cd /usr/src; PATH=/sbin:/bin:/usr/sbin:/usr/bin `test -x /usr/obj/usr/src/make.amd64/bmake && echo /usr/obj/usr/src/make.amd64/bmake || echo make` -m /usr/src/share/mk -f Makefile.inc1 TARGET=amd64 TARGET_ARCH=amd64 buildworld >>> usage: bmake [-BeikNnqrstWwX] >>> [-C directory] [-D variable] [-d flags] [-f makefile] >>> [-I directory] [-J private] [-j max_jobs] [-m directory] [-T file] >>> [-V variable] [variable=value] [target ...] >>> *** [buildworld] Error code 2 >>> >>> Stop in /usr/src. >> >> OK, the note may be written not user-friendly. >> >> Well, I've had something like you get: >> http://lists.freebsd.org/pipermail/freebsd-current/2013-May/041976.html >> >> The culprit was /usr/obj/usr/src/make.amd64/make. Seems to be your case >> as well. >> >> BTW, total removing of /usr/src should help also. > > I assume you meant /usr/obj here? :-) :-) Aha! Sorry. Sure it's /usr/obj! Thanks for correction. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Wed Aug 7 12:15:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 39331FD8 for ; Wed, 7 Aug 2013 12:15:06 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) by mx1.freebsd.org (Postfix) with ESMTP id E03A52714 for ; Wed, 7 Aug 2013 12:15:05 +0000 (UTC) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.1 cv=ANp1G3FL c=1 sm=0 tr=0 a=nVny9ETX7T5uMhI2oTVyRA==:117 a=AaUjGI9IrlcA:10 a=kj9zAlcOel0A:10 a=OA2lqS22AAAA:8 a=sIt-5M63AAAA:8 a=S2kPtTsVP8EA:10 a=6I5d2MoRAAAA:8 a=am_TcQbSZq2l_yFDeO0A:9 a=CjuIK1q_8ugA:10 a=EeD7E4ZpW3AA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.mail=roberthuff@rcn.com; spf=neutral; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com header.from=roberthuff@rcn.com; sender-id=neutral Received-SPF: neutral (smtp02.rcn.cmh.synacor.com: 209.6.193.164 is neither permitted nor denied by domain of rcn.com) Received: from [209.6.193.164] ([209.6.193.164:25071] helo=jerusalem.litteratus.org.litteratus.org) by smtp.rcn.com (envelope-from ) (ecelerity 2.2.3.49 r(42060/42061)) with ESMTP id AF/C8-14489-24A32025; Wed, 07 Aug 2013 08:14:59 -0400 From: Robert Huff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20994.14913.985491.417317@jerusalem.litteratus.org> Date: Wed, 7 Aug 2013 08:14:57 -0400 To: Boris Samorodov Subject: Re: "make buildworld" fails In-Reply-To: <52022214.7080200@passap.ru> References: <51FFD21A.3050602@passap.ru> <20992.14618.332769.261961@jerusalem.litteratus.org> <52022214.7080200@passap.ru> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid Cc: Robert Huff , 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: Wed, 07 Aug 2013 12:15:06 -0000 Boris Samorodov writes: > > sh /usr/src/tools/install.sh -o root -g wheel -m 555 make /usr/obj/usr/src/make.amd64/bmake > > cd /usr/src; PATH=/sbin:/bin:/usr/sbin:/usr/bin `test -x /usr/obj/usr/src/make.amd64/bmake && echo /usr/obj/usr/src/make.amd64/bmake || echo make` -m /usr/src/share/mk -f Makefile.inc1 TARGET=amd64 TARGET_ARCH=amd64 buildworld > > usage: bmake [-BeikNnqrstWwX] > > [-C directory] [-D variable] [-d flags] [-f makefile] > > [-I directory] [-J private] [-j max_jobs] [-m directory] [-T file] > > [-V variable] [variable=value] [target ...] > > *** [buildworld] Error code 2 > > > > Stop in /usr/src. > > OK, the note may be written not user-friendly. > > Well, I've had something like you get: > http://lists.freebsd.org/pipermail/freebsd-current/2013-May/041976.html Looks like the same thing. > The culprit was /usr/obj/usr/src/make.amd64/make. Seems to be your case > as well. huff@>> dir /usr/obj/usr/src/make.amd64 total 2284 drwxr-xr-x 3 root wheel 512 Aug 7 07:39 . drwxr-xr-x 3 root wheel 512 Aug 7 07:39 .. -rwxr-xr-x 1 root wheel 2291577 Aug 7 07:39 bmake drwxr-xr-x 3 root wheel 512 Aug 7 07:39 usr > BTW, total removing of /usr/src should help also. The 'make buildworld' is part of: #! /bin/csh cd /usr/src rm buildworld.log rm -rf /usr/obj make -v cleandir date > ./buildworld.time make -v -d l buildworld >& ./buildworld.log tail -n 50 /usr/src/buildworld.log | sendmail huff Robert Huff From owner-freebsd-current@FreeBSD.ORG Wed Aug 7 12:49:30 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8E4DE7C8 for ; Wed, 7 Aug 2013 12:49:30 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward2h.mail.yandex.net (forward2h.mail.yandex.net [IPv6:2a02:6b8:0:f05::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4295E294C for ; Wed, 7 Aug 2013 12:49:30 +0000 (UTC) Received: from smtp4h.mail.yandex.net (smtp4h.mail.yandex.net [84.201.186.21]) by forward2h.mail.yandex.net (Yandex) with ESMTP id DD7C77010F9; Wed, 7 Aug 2013 16:49:26 +0400 (MSK) Received: from smtp4h.mail.yandex.net (localhost [127.0.0.1]) by smtp4h.mail.yandex.net (Yandex) with ESMTP id 81EF92C151B; Wed, 7 Aug 2013 16:49:26 +0400 (MSK) Received: from 93.91.10.81.tel.ru (93.91.10.81.tel.ru [93.91.10.81]) by smtp4h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id kkRMmYUU1Z-nPZ8sVLd; Wed, 7 Aug 2013 16:49:25 +0400 Message-ID: <52024255.7090907@passap.ru> Date: Wed, 07 Aug 2013 16:49:25 +0400 From: Boris Samorodov Organization: =?UTF-8?B?0JfQkNCeICLQktCQ0KDQoiI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130806 Thunderbird/17.0.7 MIME-Version: 1.0 To: Robert Huff Subject: Re: "make buildworld" fails References: <51FFD21A.3050602@passap.ru> <20992.14618.332769.261961@jerusalem.litteratus.org> <52022214.7080200@passap.ru> <20994.14913.985491.417317@jerusalem.litteratus.org> In-Reply-To: <20994.14913.985491.417317@jerusalem.litteratus.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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: Wed, 07 Aug 2013 12:49:30 -0000 07.08.2013 16:14, Robert Huff пишет: > > Boris Samorodov writes: > >> > sh /usr/src/tools/install.sh -o root -g wheel -m 555 make /usr/obj/usr/src/make.amd64/bmake >> > cd /usr/src; PATH=/sbin:/bin:/usr/sbin:/usr/bin `test -x /usr/obj/usr/src/make.amd64/bmake && echo /usr/obj/usr/src/make.amd64/bmake || echo make` -m /usr/src/share/mk -f Makefile.inc1 TARGET=amd64 TARGET_ARCH=amd64 buildworld >> > usage: bmake [-BeikNnqrstWwX] >> > [-C directory] [-D variable] [-d flags] [-f makefile] >> > [-I directory] [-J private] [-j max_jobs] [-m directory] [-T file] >> > [-V variable] [variable=value] [target ...] >> > *** [buildworld] Error code 2 >> > >> > Stop in /usr/src. >> >> OK, the note may be written not user-friendly. >> >> Well, I've had something like you get: >> http://lists.freebsd.org/pipermail/freebsd-current/2013-May/041976.html > > Looks like the same thing. Not quite -- for me that was old and stale file from some previous buildworld. >> The culprit was /usr/obj/usr/src/make.amd64/make. Seems to be your case >> as well. > > huff@>> dir /usr/obj/usr/src/make.amd64 > total 2284 > drwxr-xr-x 3 root wheel 512 Aug 7 07:39 . > drwxr-xr-x 3 root wheel 512 Aug 7 07:39 .. > -rwxr-xr-x 1 root wheel 2291577 Aug 7 07:39 bmake > drwxr-xr-x 3 root wheel 512 Aug 7 07:39 usr Hm, I do not have such directory now: ----- % ls -l /usr/obj/usr/src/make\* ls: /usr/obj/usr/src/make*: No such file or directory ----- >> BTW, total removing of /usr/src should help also. > > The 'make buildworld' is part of: > > #! /bin/csh > > cd /usr/src > rm buildworld.log > rm -rf /usr/obj > make -v cleandir > date > ./buildworld.time > make -v -d l buildworld >& ./buildworld.log > tail -n 50 /usr/src/buildworld.log | sendmail huff One more thing. I do not have a file named "bmake" at /usr/obj, but have just "make" (at this host I build world for i386 as well): ----- % find /usr/obj -type f -name bmake % find /usr/obj -type f -name make /usr/obj/usr/src/usr.bin/bmake/make /usr/obj/i386.i386/usr/src/usr.bin/bmake/make ----- While at the first e-mail last log line was: >> sh /usr/src/tools/install.sh -o root -g wheel -m 555 make \ >> /usr/obj/usr/src/make.amd64/make Are there some non-default configure/environment values? -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Wed Aug 7 13:40:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 50C009A2 for ; Wed, 7 Aug 2013 13:40:55 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) by mx1.freebsd.org (Postfix) with ESMTP id 087D02C8E for ; Wed, 7 Aug 2013 13:40:54 +0000 (UTC) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.1 cv=IO07VGfG c=1 sm=0 tr=0 a=nVny9ETX7T5uMhI2oTVyRA==:117 a=nVny9ETX7T5uMhI2oTVyRA==:17 a=K-v-2zaBAAAA:8 a=AaUjGI9IrlcA:10 a=kj9zAlcOel0A:10 a=OA2lqS22AAAA:8 a=sIt-5M63AAAA:8 a=S2kPtTsVP8EA:10 a=LjTOzC1lAAAA:8 a=g3k24fdcAAAA:8 a=L9qgJDJ1iCtfaKdao-wA:9 a=CjuIK1q_8ugA:10 a=KmloqkfaIt8A:10 a=6k4BJ-aj_1UA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp01.rcn.cmh.synacor.com header.from=roberthuff@rcn.com; sender-id=neutral Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.mail=roberthuff@rcn.com; spf=neutral; sender-id=neutral Received-SPF: neutral (smtp01.rcn.cmh.synacor.com: 209.6.193.164 is neither permitted nor denied by domain of rcn.com) Received: from [209.6.193.164] ([209.6.193.164:48026] helo=jerusalem.litteratus.org.litteratus.org) by smtp.rcn.com (envelope-from ) (ecelerity 2.2.3.49 r(42060/42061)) with ESMTP id 43/41-04066-56E42025; Wed, 07 Aug 2013 09:40:54 -0400 From: Robert Huff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20994.20068.695921.759096@jerusalem.litteratus.org> Date: Wed, 7 Aug 2013 09:40:52 -0400 To: Boris Samorodov Subject: Re: "make buildworld" fails In-Reply-To: <52024255.7090907@passap.ru> References: <51FFD21A.3050602@passap.ru> <20992.14618.332769.261961@jerusalem.litteratus.org> <52022214.7080200@passap.ru> <20994.14913.985491.417317@jerusalem.litteratus.org> <52024255.7090907@passap.ru> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid Cc: Robert Huff , 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: Wed, 07 Aug 2013 13:40:55 -0000 Boris Samorodov writes: > While at the first e-mail last log line was: > >> sh /usr/src/tools/install.sh -o root -g wheel -m 555 make \ > >> /usr/obj/usr/src/make.amd64/make > > Are there some non-default configure/environment values? Not as far as I know. There is no src.conf; make.conf is appended. Robert Huff CFLAGS= -O -pipe -g STRIP= SYMVER_ENABLED= yes X_WINDOW_SYSTEM= xorg HAVE_MOTIF= yes KERNCONF=JERUSALEM # To avoid building various parts of the base system: # (copied from /usr/share/examples/etc/make.conf NO_BIND_ETC= true # Do not install files to /etc/namedb NO_BLUETOOTH= true # do not build Bluetooth related stuff NO_PROFILE= true # Avoid compiling profiled libraries # to get automatic SASL in sendmail SENDMAIL_CFLAGS+= -I/usr/local/include/ -DSASL=2 SENDMAIL_LDFLAGS+= -L/usr/local/lib SENDMAIL_LDADD+= -lsasl2 # # to make CUPS magically keep working # See: http://www.csua.berkeley.edu/~ranga/notes/freebsd_cups.html # CUPS_OVERWRITE_BASE= yes NO_LPR= true # added per /usr/ports/UPDATING entry 20090401 OVERRIDE_LINUX_BASE_PORT=f10 OVERRIDE_LINUX_NONBASE_PORTS=f10 # WITH_MOZILLA= libxul WITH_GECKO= libxul # # added 2007/03/04 per advice of # in re science/gramps # WITH_BERKELEYDB=db43 WITH_BDB_VER=43 WANT_OPENLDAP_VER=24 WANT_OPENLDAP_SASL=true # # as required by ports/UPDATING of 20121012 # SAMBA_ENABLE=YES # # PORTS: use clang unless gcc is explicitly required # # # default to using clang for all port builds, with the following # exceptions # ports which will only build with the base system GNU compiler (4.2) # # the "make index" target also seems to need this, for some reason .if target(index) | \ ${.CURDIR:M*/devel/antlr*} | \ ${.CURDIR:M*/devel/google-perftools* } | \ ${.CURDIR:M*/graphics/ImageMagick* } | \ ${.CURDIR:M*/graphics/opencv*} | \ ${.CURDIR:M*/x11/kdelibs4*} | \ USE_GCC?=4.2 .endif # ports which need *some* version of the GNU compiler (won't build with # clang or have runtime issues if built with clang) # use the highest version of gcc we have installed from ports (4.6) .if ${.CURDIR:M*/accessibility/jovie*} | \ ${.CURDIR:M*/accessibility/kdeaccessibility4*} | \ ${.CURDIR:M*/audio/grip*} | \ ${.CURDIR:M*/audio/mpg123*} | \ ${.CURDIR:M*/audio/rosegarden*} | \ ${.CURDIR:M*/databases/virtuoso*} | \ ${.CURDIR:M*/deskutils/kdepimlibs4*} | \ ${.CURDIR:M*/devel/apache-ant*} | \ ${.CURDIR:M*/devel/icu*} | \ ${.CURDIR:M*/devel/kdevelop-kde4*} | \ ${.CURDIR:M*/devel/kdevplatform*} | \ ${.CURDIR:M*/devel/log4j*} | \ ${.CURDIR:M*/games/kdegames4*} | \ ${.CURDIR:M*/graphics/tonicpoint-viewer*} | \ ${.CURDIR:M*/java/* } | \ ${.CURDIR:M*/lang/gcc* } | \ ${.CURDIR:M*/math/fftw3*} | \ ${.CURDIR:M*/multimedia/avidemux2*} | \ ${.CURDIR:M*/multimedia/kdemultimedia4*} | \ ${.CURDIR:M*/multimedia/vlc*} | \ ${.CURDIR:M*/multimedia/xbmc*} | \ ${.CURDIR:M*/net/kdenetwork4*} | \ ${.CURDIR:M*/net/mpich2*} | \ ${.CURDIR:M*/net/opal3*} | \ ${.CURDIR:M*/net-p2p/ktorrent*} | \ ${.CURDIR:M*/net-p2p/vuze*} | \ ${.CURDIR:M*/sysutils/lsof*} | \ ${.CURDIR:M*/textproc/docbook-xsl*} | \ ${.CURDIR:M*/textproc/fop*} | \ ${.CURDIR:M*/www/libxul*} | \ ${.CURDIR:M*/x11/kde4-baseapps*} | \ ${.CURDIR:M*/x11/kde4-workspace*} | \ ${.CURDIR:M*/x11/lxpanel*} | \ USE_GCC?=4.6+ .endif .if ${.CURDIR:M*/usr/ports/*} .if !defined(USE_GCC) .if !defined(CC) || ${CC} == "cc" CC=clang .endif .if !defined(CXX) || ${CXX} == "c++" CXX=clang++ .endif .if !defined(CPP) || ${CPP} == "cpp" CPP=clang-cpp .endif .endif .endif WITH_NEW_XORG=yes WITH_BSD_SORT= WITH_PKGNG=yes # added by use.perl 2013-06-13 09:50:52 PERL_VERSION=5.16.3 From owner-freebsd-current@FreeBSD.ORG Wed Aug 7 13:41:01 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0D3499A6; Wed, 7 Aug 2013 13:41:01 +0000 (UTC) (envelope-from bryanv@daemoninthecloset.org) Received: from torment.daemoninthecloset.org (torment.daemoninthecloset.org [94.242.209.234]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C1BAC2C8F; Wed, 7 Aug 2013 13:41:00 +0000 (UTC) Received: from sage.daemoninthecloset.org (unknown [70.114.209.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sage.daemoninthecloset.org", Issuer "daemoninthecloset.org" (verified OK)) by torment.daemoninthecloset.org (Postfix) with ESMTPS id A9BF942C0853; Wed, 7 Aug 2013 15:45:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at daemoninthecloset.org X-Virus-Scanned: amavisd-new at daemoninthecloset.org Date: Wed, 7 Aug 2013 08:40:43 -0500 (CDT) From: Bryan Venteicher To: Julian Elischer Message-ID: <1782675758.14654.1375882843424.JavaMail.root@daemoninthecloset.org> In-Reply-To: <5201EC7C.4010209@freebsd.org> References: <1050637258.686.1375660230986.JavaMail.root@daemoninthecloset.org> <601099152.721.1375661537866.JavaMail.root@daemoninthecloset.org> <20130805202039.GA18861@devbox.vnode.local> <1174186801.993.1375743121722.JavaMail.root@daemoninthecloset.org> <5201EC7C.4010209@freebsd.org> Subject: Re: [CFT] VMware vmxnet3 ethernet driver MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [192.168.10.24] X-Mailer: Zimbra 8.0.2_GA_5569 (ZimbraWebClient - GC28 (Mac)/8.0.2_GA_5569) Thread-Topic: VMware vmxnet3 ethernet driver Thread-Index: jbaETGtuRdqytXPHmZHRM9M/ayOtkA== Cc: current@freebsd.org, Joel Dahl 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: Wed, 07 Aug 2013 13:41:01 -0000 ----- Original Message ----- > it'd be nice if we could get vmware to just support the drivers in tree.. > by which I mean, just submit patches.. why do they need to have it out > of tree? > I agree. But they are all unfriendly licensed. The FF had a discussion to get them relicensed to something more suitable, but that went no where over the past year. It is unfortunate this vendor supplied, out of tree driver, issue is still around. Linux should have taught companies how foolish this is. From owner-freebsd-current@FreeBSD.ORG Wed Aug 7 13:54:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2651611C; Wed, 7 Aug 2013 13:54:45 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) Received: from mail.made4.biz (unknown [IPv6:2001:41d0:1:7018::1:3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DA0462D81; Wed, 7 Aug 2013 13:54:44 +0000 (UTC) Received: from [2001:1b48:10b:cafe:225:64ff:febe:589f] (helo=viking.yzserv.com) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1V74CI-000KzV-RH; Wed, 07 Aug 2013 15:54:43 +0200 Message-ID: <520251A2.6060502@FreeBSD.org> Date: Wed, 07 Aug 2013 15:54:42 +0200 From: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130801 Thunderbird/17.0.7 MIME-Version: 1.0 To: Rui Paulo , Pyun YongHyeon , freebsd-current@freebsd.org Subject: Re: svn commit: r254021 - head/contrib/wpa/src/drivers References: <201308070403.r7743VIP004811@svn.freebsd.org> <52025016.8040708@FreeBSD.org> In-Reply-To: <52025016.8040708@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2AJXMJXWONFSHSGNJRTRV" 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: Wed, 07 Aug 2013 13:54:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2AJXMJXWONFSHSGNJRTRV Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 07.08.2013 15:48, Jean-S=C3=A9bastien P=C3=A9dron wrote: > On 07.08.2013 06:03, Rui Paulo wrote: >> - *status =3D ifmr.ifm_status & IFM_ACTIVE; >> + *status =3D ifmr.ifm_status & (IFM_ACTIVE|IFM_AVALID); >=20 > The timing problem is back with this change. I guess because IFM_AVALID= > is set but not IFM_ACTIVE. Maybe they must be both set? (sorry, typo in mailing-list address...) --=20 Jean-S=C3=A9bastien P=C3=A9dron ------enig2AJXMJXWONFSHSGNJRTRV 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.20 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlICUaIACgkQa+xGJsFYOlOmAgCglK/KuZ1HfeQnMvrujIA1EtLn FmAAnRcz3LVEMGYpI9oRQ/YD1uglgDXw =6k1i -----END PGP SIGNATURE----- ------enig2AJXMJXWONFSHSGNJRTRV-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 7 14:29:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E689FBB5 for ; Wed, 7 Aug 2013 14:29:24 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A87DE2F87 for ; Wed, 7 Aug 2013 14:29:24 +0000 (UTC) Received: from coleburn.avinity.tv (host-229-161-243.77.avinity.tv [77.243.161.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id B6FAD5C5A; Wed, 7 Aug 2013 16:29:21 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: "make buildworld" fails From: Dimitry Andric In-Reply-To: <20994.20068.695921.759096@jerusalem.litteratus.org> Date: Wed, 7 Aug 2013 16:29:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <69ACD03B-11D3-44AC-96B6-86241DF42EEC@FreeBSD.org> References: <51FFD21A.3050602@passap.ru> <20992.14618.332769.261961@jerusalem.litteratus.org> <52022214.7080200@passap.ru> <20994.14913.985491.417317@jerusalem.litteratus.org> <52024255.7090907@passap.ru> <20994.20068.695921.759096@jerusalem.litteratus.org> To: Robert Huff X-Mailer: Apple Mail (2.1508) Cc: freebsd-current@freebsd.org, Boris Samorodov 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: Wed, 07 Aug 2013 14:29:25 -0000 On Aug 7, 2013, at 15:40, Robert Huff wrote: > Boris Samorodov writes: ... >> Are there some non-default configure/environment values? >=20 > Not as far as I know. There is no src.conf; make.conf is = appended. >=20 >=20 > Robert Huff >=20 >=20 >=20 > CFLAGS=3D -O -pipe -g=20 Just a note: don't set CFLAGS with =3D, always use +=3D, e.g.: CFLAGS+=3D -O -pipe -g Also, you might want to set -g in DEBUG_FLAGS instead, not directly in = CFLAGS. -Dimitry From owner-freebsd-current@FreeBSD.ORG Wed Aug 7 17:28:54 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C028C97A; Wed, 7 Aug 2013 17:28:54 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5AEB42AB5; Wed, 7 Aug 2013 17:28:53 +0000 (UTC) Received: from p5dc3ee31.dip0.t-ipconnect.de ([93.195.238.49] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1V77XR-000601-Fr; Wed, 07 Aug 2013 19:28:45 +0200 Message-ID: <520283C9.8030806@gwdg.de> Date: Wed, 07 Aug 2013 19:28:41 +0200 From: Rainer Hurling User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130802 Thunderbird/17.0.7 MIME-Version: 1.0 To: current@freebsd.org Subject: Port problems after r253839 on HEAD Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: bapt@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: Wed, 07 Aug 2013 17:28:54 -0000 After introducing r253839 on HEAD (/head/contrib/binutils/ld/ldmain.c), I recognized some wired behaviour in the ports system on my CURRENT boxes. Some of the ports do not build anymore. They print almost similar messages about an ld problem (invalid DSO for symbol 'xxx' definition), followed by the lib, which symbols are not found. With a recent 10.0-CURRENT (at least r253839) you can try this for example with the following two ports: -------------------- (1) editors/nano cc -O2 -pipe -fno-strict-aliasing -L/usr/local/lib -o nano browser.o chars.o color.o cut.o files.o global.o help.o move.o nano.o prompt.o rcfile.o search.o text.o utils.o winio.o /usr/local/lib/libintl.so /usr/local/lib/libiconv.so -Wl,-rpath -Wl,/usr/local/lib -lncursesw /usr/bin/ld: .: invalid DSO for symbol `keypad' definition /usr/local/lib/libtinfow.so.5.9: could not read symbols: Bad value cc: error: linker command failed with exit code 1 (use -v to see invocation) (2) www/evolution-webcal cc -O2 -pipe -fno-strict-aliasing -L/usr/local/lib -o evolution-webcal evolution-webcal-main.o evolution-webcal-notify.o -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage -lXfixes -lX11 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lpangoft2-1.0 -lpango-1.0 -lfreetype -lfontconfig -lecal-1.2 -lical -licalss -licalvcal -pthread -ledataserver-1.2 -lxml2 -lgconf-2 -lsoup-2.4 -lgio-2.0 -lgobject-2.0 -L/usr/local/lib -lglib-2.0 -lintl /usr/bin/ld: R: invalid DSO for symbol `g_thread_init' definition /usr/local/lib/libgthread-2.0.so.0: could not read symbols: Bad value cc: error: linker command failed with exit code 1 (use -v to see invocation) -------------------- This errors disappear when I revert /usr/bin/ld to a revision before 253839. Furthermore I observed some wired behaviour for SAGA GIS (math/saga; I am the maintainer of it). This port should build and install a SAGA GIS module as /usr/local/lib/saga/libopencv.so (for this it has graphics/opencv as a dependency). With /usr/bin/ld rev. 253839 installed, the autotools configure process from math/saga is not able to find /usr/local/lib/libopencv_legacy.so and so it does not build the module. Unfortunately it gives no clarifying hint about the problem). Reverting the version of /usr/bin/ld before r253839 solves this problem ... I hope my description is of some use and does not point in the wrong direction. Rainer Hurling From owner-freebsd-current@FreeBSD.ORG Wed Aug 7 17:43:39 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 30F4FDEB for ; Wed, 7 Aug 2013 17:43:39 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B79232BE0 for ; Wed, 7 Aug 2013 17:43:38 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id l18so1777614wgh.35 for ; Wed, 07 Aug 2013 10:43:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=H5d7nufjheZsOmk8fLiN34eM4lieliwKQ9xqxd+Z0Ew=; b=rtz4cqq8xS8fdbKhNbI/hcPcOu9K6ROFt6J+HMHQFFfIHWoPOO2pSin2iOg29eNcjO gvQF1alKBf7NsVl0tLHOPyyHahG6kjtx7CzSSO0zXvIbNNiSFYMBisGlmTLWLYcT/Rn+ 49YEYPeHib21DG1YPbNv/ftDvMD/lbng214SCruhhgwVXfwqzIrFMwfExrJFUEO/quui etNvDcJbDi1yaLKCxgDaFczmhZ66rdWGIUFHzhLqOTZqMnMb+9RjljB1hU/sPpdA6IRU zn19ak+gB+h1O6qvfCSj/D/VHvs8PDIL0hK74EzGb2HJY9xEVmxwjJqtTmBxpOhYwWJ/ CPeA== X-Received: by 10.194.22.41 with SMTP id a9mr1130117wjf.16.1375897417116; Wed, 07 Aug 2013 10:43:37 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id mb7sm10388397wic.10.2013.08.07.10.43.35 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 07 Aug 2013 10:43:35 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 7 Aug 2013 19:43:33 +0200 From: Baptiste Daroussin To: Rainer Hurling Subject: Re: Port problems after r253839 on HEAD Message-ID: <20130807174333.GK40254@ithaqua.etoilebsd.net> References: <520283C9.8030806@gwdg.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0FM4RQAc0jwHekq5" Content-Disposition: inline In-Reply-To: <520283C9.8030806@gwdg.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 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: Wed, 07 Aug 2013 17:43:39 -0000 --0FM4RQAc0jwHekq5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 07, 2013 at 07:28:41PM +0200, Rainer Hurling wrote: > After introducing r253839 on HEAD (/head/contrib/binutils/ld/ldmain.c), > I recognized some wired behaviour in the ports system on my CURRENT boxes. >=20 > Some of the ports do not build anymore. They print almost similar > messages about an ld problem (invalid DSO for symbol 'xxx' definition), > followed by the lib, which symbols are not found. >=20 > With a recent 10.0-CURRENT (at least r253839) you can try this for > example with the following two ports: >=20 normally I had tracked down all those ports, except if you are building them with nom default options, What that means is basically the said ports are missing some -lbla in ldfla= gs, The missing ones are those listed in the line following the DSO bla in nano for example the first failure means -liconv is missing. I afk until 24th so I can't commit any fix to the said ports. There were properly building in my exp-run for the said change, meaning eit= her you build with non default options im that case the port requires a fix or perhaps your ports tree is not uptodate, in particular lots of those failur= es are fixed by the recent glib update. regards, Bapt --0FM4RQAc0jwHekq5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlICh0UACgkQ8kTtMUmk6ExG+wCfYtF24PkJc0JJ0gyd9ZE0O9uH TocAoMJo8ds2QNGJG0ik+x5p51/VSxg/ =Jck6 -----END PGP SIGNATURE----- --0FM4RQAc0jwHekq5-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 7 18:04:47 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CED3D623; Wed, 7 Aug 2013 18:04:47 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from s1.omnilan.de (s1.omnilan.de [217.91.127.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3B8342D59; Wed, 7 Aug 2013 18:04:45 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by s1.omnilan.de (8.13.8/8.13.8) with ESMTP id r77I4grt080836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Aug 2013 20:04:43 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <52028C31.6060908@omnilan.de> Date: Wed, 07 Aug 2013 20:04:33 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: attilio@freebsd.org Subject: Re: MPSAFE VFS -- List of upcoming actions References: <20120829060158.GA38721@x2.osted.lan> <20120831052003.GA91340@x2.osted.lan> <20120905201531.GA54452@x2.osted.lan> <20120917140055.GA9037@x2.osted.lan> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0CA859C26DF2E57AF9889AAA" Cc: FreeBSD FS , FreeBSD current 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: Wed, 07 Aug 2013 18:04:48 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0CA859C26DF2E57AF9889AAA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bez=FCglich Attilio Rao's Nachricht vom 14.10.2012 02:27 (localtime): > On Fri, Sep 21, 2012 at 1:22 AM, Attilio Rao wrot= e: >> On Wed, Sep 19, 2012 at 3:48 AM, Attilio Rao wro= te: >>> On Fri, Jul 13, 2012 at 12:18 AM, Attilio Rao w= rote: >>>> 2012/7/4 Attilio Rao : >>>>> 2012/6/29 Attilio Rao : >>>>>> As already published several times, according to the following pla= n: >>>>>> http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS >>>>>> >>>>> I still haven't heard from Vivien or Edward, anyway as NTFS is >>>>> basically only used RO these days (also the mount_ntfs code just >>>>> permits RO mounting) I stripped all the uncomplete/bogus write supp= ort >>>>> with the following patch: >>>>> http://www.freebsd.org/~attilio/ntfs_remove_write.patch >>>>> >>>>> This is an attempt to make the code smaller and possibly just focus= on =2E.. > I've committed the FUSE support into base as r241519. Thank you for your great work! I had used http://www.freebsd.org/~attilio/fuse_import/fuse_stable9_241030.patch with releng/9.1. Some improovements were made in the meantime in head. I'm not familiar with svn. Was it possible to generate a new patchset against releng/9.2? I'd have to concat manually downloadad revisions via svnweb... :-( Thanks a lot, -Harry --------------enig0CA859C26DF2E57AF9889AAA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlICjDoACgkQLDqVQ9VXb8iQuwCfSxH85V+gfuN5AyQpiYb6a6pO QCgAoNECBYHrZ2dUVHjX87YoDK6XyK80 =DDAF -----END PGP SIGNATURE----- --------------enig0CA859C26DF2E57AF9889AAA-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 7 19:01:11 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 01054FD0; Wed, 7 Aug 2013 19:01:11 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 24947211F; Wed, 7 Aug 2013 19:01:10 +0000 (UTC) Received: from p5dc3ee31.dip0.t-ipconnect.de ([93.195.238.49] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1V78yp-0006UB-TV; Wed, 07 Aug 2013 21:01:08 +0200 Message-ID: <52029973.5070607@gwdg.de> Date: Wed, 07 Aug 2013 21:01:07 +0200 From: Rainer Hurling User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130802 Thunderbird/17.0.7 MIME-Version: 1.0 To: Baptiste Daroussin Subject: Re: Port problems after r253839 on HEAD References: <520283C9.8030806@gwdg.de> <20130807174333.GK40254@ithaqua.etoilebsd.net> In-Reply-To: <20130807174333.GK40254@ithaqua.etoilebsd.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: 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: Wed, 07 Aug 2013 19:01:11 -0000 Thanks, Bapt, for answering. Am 07.08.2013 19:43, schrieb Baptiste Daroussin: > On Wed, Aug 07, 2013 at 07:28:41PM +0200, Rainer Hurling wrote: >> After introducing r253839 on HEAD (/head/contrib/binutils/ld/ldmain.c), >> I recognized some wired behaviour in the ports system on my CURRENT boxes. >> >> Some of the ports do not build anymore. They print almost similar >> messages about an ld problem (invalid DSO for symbol 'xxx' definition), >> followed by the lib, which symbols are not found. >> >> With a recent 10.0-CURRENT (at least r253839) you can try this for >> example with the following two ports: >> > normally I had tracked down all those ports, except if you are building them > with nom default options, #cd /usr/ports/www/evolution-webcal #make config ===> No options to configure #cd /usr/ports/editors/nano #make config ===> No options to configure > What that means is basically the said ports are missing some -lbla in ldflags, > > The missing ones are those listed in the line following the DSO bla > in nano for example the first failure means -liconv is missing. Yupp, thanks, the following two patches seem to work: --- Makefile.orig 2013-07-17 16:59:50.000000000 +0200 +++ Makefile 2013-08-07 20:42:11.000000000 +0200 @@ -15,11 +15,13 @@ CONFLICTS= nano-devel-2* +LIB_DEPENDS= tinfow:${PORTSDIR}/devel/ncurses + GNU_CONFIGURE= yes CONFIGURE_ARGS= --docdir=${DOCSDIR} CPPFLAGS+= -I${LOCALBASE}/include -LDFLAGS+= -L${LOCALBASE}/lib +LDFLAGS+= -L${LOCALBASE}/lib -ltinfow .include --- Makefile.orig 2013-06-20 17:40:13.000000000 +0200 +++ Makefile 2013-08-07 20:47:21.000000000 +0200 @@ -23,7 +23,7 @@ USE_GNOME= gnomeprefix gnomehack intlhack evolutiondataserver libgnomeui GNU_CONFIGURE= yes CPPFLAGS+= -I${LOCALBASE}/include -LDFLAGS+= -L${LOCALBASE}/lib +LDFLAGS+= -L${LOCALBASE}/lib -lgthread-2.0 GCONF_SCHEMAS= evolution-webcal.schemas > > I afk until 24th so I can't commit any fix to the said ports. > There were properly building in my exp-run for the said change, meaning either > you build with non default options im that case the port requires a fix or > perhaps your ports tree is not uptodate, in particular lots of those failures > are fixed by the recent glib update. Hmm. As far as I can say my ports tree is uptodate and I did the complete glib update (/usr/ports/UPDATING entry 20130731). So I have no clue, why editors/nano does complain about devel/ncurses. In particular I am wondering about the misbehaviour of my port math/saga. As I wrote before, the autotools process does not find libopencv.so, only and only if HEAD is using /usr/bin/ld r253839. Probably there is a hidden problem, not seen before without the ld patch? Any hint would be very appreciated. Many thanks for your fast help and greetings from Göttingen in Germany, Rainer > > regards, > Bapt > From owner-freebsd-current@FreeBSD.ORG Wed Aug 7 20:00:26 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4F59177B for ; Wed, 7 Aug 2013 20:00:26 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B1A0A2522 for ; Wed, 7 Aug 2013 20:00:25 +0000 (UTC) Received: (qmail 55691 invoked from network); 7 Aug 2013 20:46:00 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 7 Aug 2013 20:46:00 -0000 Message-ID: <5202A74E.4060602@freebsd.org> Date: Wed, 07 Aug 2013 22:00:14 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: [net] protecting interfaces from races between control and data ? References: <20130805215319.GA43271@onelab2.iet.unipi.it> <201308070326.r773QCLD035541@mail.karels.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , current@freebsd.org, mike@karels.net, Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri 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: Wed, 07 Aug 2013 20:00:26 -0000 On 07.08.2013 09:18, Luigi Rizzo wrote: > On Wed, Aug 7, 2013 at 5:26 AM, Mike Karels > wrote: > Jumping to (near) the end of the thread, I like most of Andre's proposal. > Running with minimal locks at this layer is an admirable goal, and I agree > with most of what was said. I have a few observations on the general changes, > or related issues: > > There was mention of taskqueues. I think that with MSI-X, taskqueues > should not be needed or used. More specifically, having separate ithreads > and taskqueues, with ithreads deferring to taskqueues after some limit, makes > sense only for MSI and legacy interrupts. With MSI-X, an interrupt thread > should be able to process packets indefinitely with sufficient CPU resources, > and there is no reason to context switch to a different thread periodically. > A periodic "yield" might be reasonable, but if it is necessary, small packet > performance will suffer. However, most of this is internal to the driver. > > > i am not completely clear on what is the difference between ithreads and taskqueues. The difference between ithreads and taskqueues is actually very small and mostly in name and how they're set up and kicked off when work is to be done. Both are real kernel threads. Most of the confusion, also in Mikes response, seems to come from the name ithreads for interrupt-threads. However an ithread is not running in interrupt context, only the interrupt handler (called filter) does. Scheduling a taskqueue from an ithread is a bit round-about but commonly done. The bus_setup_intr(9) man page isn't helping to clear up the confusion. The idea is that a (legacy) interrupt is handled in two stages: 1) a small function reading the hardware interrupt status register to determine if this hardware actually raised an interrupt, and acknowledge it (to prevent additional interrupts from firing while this one is handled). If it wasn't this card, it hands off to the handler if this interrupt line is shared; 2) the actual function/thread handling the data that was indicated by the interrupt. Only step 1 runs in interrupt context and thus must be very small and avoid any form of blocking. Step 2 is a normal kernel thread set up as an ithread running at an elevated priority compared to user-space processes/threads. MSI and MSI-X always are exclusive and non-shared interrupts. Thus a handler running in interrupt context isn't necessary for non-legacy interrupt sources. The ithread can be scheduled right away to do its work. > Also, Andre's proposal requires to force-kill the ithread, but i am unclear on how to do it > safely (i.e. without leaving the data structures in some inconsistent state), unless ithread > periodically yields the CPU when it is in a safe state. While this is internal to the driver, > we should probably provide some template code to avoid that each driver implements > its own way to shutdown the ithread. Yes, when done a well-tested, stable and performant template will be provided. -- Andre From owner-freebsd-current@FreeBSD.ORG Wed Aug 7 23:11:00 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EF01A69C; Wed, 7 Aug 2013 23:11:00 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B4FA22137; Wed, 7 Aug 2013 23:11:00 +0000 (UTC) Received: by mail-pa0-f48.google.com with SMTP id kp13so2690153pab.35 for ; Wed, 07 Aug 2013 16:11:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=jEEKILxGJCiC5GjRqevQ4KZ9ci1i3W1Stv24fC1zEMk=; b=v5VhDtcD0Y+kznltF5OTakDZVLAhsl9S1X+v8GrFR/IsLKCD2CwdFvUC3bSt7F0Pjx BQF0MsnP+srIAIWdm4pDkg1rGIkpDiSALOk61j4YsM5ZS7h9HQAhcAka9llAf9cQ4RG2 epZD5ulafR215BblNSlrgifrQVNfUyo0b3+v4Unvbb2nIz3C+THL1wS65VfJOfYMDVfi cBMzD5OeeKpKiDXS8PLDhIpTbm7Urk+UeI0Z+exUIVVx4yVN3moWot2MWVniD98dVJOR kJR0LMjjm0/TMzS4/WPRnCgILmXUD4R0dfKn/fDGuMYKq8BV7VBx03j/NwOiRfN+RjEw l0uA== MIME-Version: 1.0 X-Received: by 10.68.251.234 with SMTP id zn10mr2823951pbc.188.1375917060313; Wed, 07 Aug 2013 16:11:00 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.67.14.66 with HTTP; Wed, 7 Aug 2013 16:11:00 -0700 (PDT) In-Reply-To: <52028C31.6060908@omnilan.de> References: <20120829060158.GA38721@x2.osted.lan> <20120831052003.GA91340@x2.osted.lan> <20120905201531.GA54452@x2.osted.lan> <20120917140055.GA9037@x2.osted.lan> <52028C31.6060908@omnilan.de> Date: Wed, 7 Aug 2013 16:11:00 -0700 X-Google-Sender-Auth: A-okjY7GCK_xLR5LvQA8bkRpAiU Message-ID: Subject: Re: MPSAFE VFS -- List of upcoming actions From: Kevin Oberman To: Harald Schmalzbauer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Attilio Rao , FreeBSD FS , FreeBSD current 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: Wed, 07 Aug 2013 23:11:01 -0000 On Wed, Aug 7, 2013 at 11:04 AM, Harald Schmalzbauer < h.schmalzbauer@omnilan.de> wrote: > Bez=C3=BCglich Attilio Rao's Nachricht vom 14.10.2012 02:27 (localtime): > > On Fri, Sep 21, 2012 at 1:22 AM, Attilio Rao > wrote: > >> On Wed, Sep 19, 2012 at 3:48 AM, Attilio Rao > wrote: > >>> On Fri, Jul 13, 2012 at 12:18 AM, Attilio Rao > wrote: > >>>> 2012/7/4 Attilio Rao : > >>>>> 2012/6/29 Attilio Rao : > >>>>>> As already published several times, according to the following pla= n: > >>>>>> http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS > >>>>>> > >>>>> I still haven't heard from Vivien or Edward, anyway as NTFS is > >>>>> basically only used RO these days (also the mount_ntfs code just > >>>>> permits RO mounting) I stripped all the uncomplete/bogus write > support > >>>>> with the following patch: > >>>>> http://www.freebsd.org/~attilio/ntfs_remove_write.patch > >>>>> > >>>>> This is an attempt to make the code smaller and possibly just focus > on > > ... > > > I've committed the FUSE support into base as r241519. > > Thank you for your great work! > I had used > http://www.freebsd.org/~attilio/fuse_import/fuse_stable9_241030.patch > with releng/9.1. > Some improovements were made in the meantime in head. > I'm not familiar with svn. > Was it possible to generate a new patchset against releng/9.2? I'd have > to concat manually downloadad revisions via svnweb... :-( > > Thanks a lot, > > -Harry > > Already done. All of the changes in head have been back-ported to 9.2-PRERELEASE with the exception of a locking enhancement not available outside of current. You can find it at: https://docs.google.com/file/d/0B9QNUQlebx5UdlhPUTB4TXF6enc/edit?usp=3Dshar= ing The changes were minor, mostly updating line numbers. There was a major update to the new fuse release, but it was rolled back because it would not work with fusefs-libs. Both will need to be updated at the same time. I don't know what the state of any effort to do this might be or how difficult it will be. --=20 R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Thu Aug 8 03:40:23 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EA3DC837; Thu, 8 Aug 2013 03:40:23 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BF836204E; Thu, 8 Aug 2013 03:40:23 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r783eEgM080406; Thu, 8 Aug 2013 03:40:14 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id jib69syhahekvvuirrqjuubqke; Thu, 08 Aug 2013 03:40:14 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: [net] protecting interfaces from races between control and data ? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <520127C3.3020101@freebsd.org> Date: Wed, 7 Aug 2013 20:40:14 -0700 Content-Transfer-Encoding: 7bit Message-Id: <696F42E9-B1E6-4198-BD55-F7595932E320@kientzle.com> References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> <5200136C.8000201@freebsd.org> <20130805215319.GA43271@onelab2.iet.unipi.it> <520127C3.3020101@freebsd.org> To: Andre Oppermann X-Mailer: Apple Mail (2.1283) Cc: Adrian Chadd , current@FreeBSD.org, Bryan Venteicher , Navdeep Parhar , net@FreeBSD.org, Giuseppe Lettieri , Luigi Rizzo 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: Thu, 08 Aug 2013 03:40:24 -0000 On Aug 6, 2013, at 9:43 AM, Andre Oppermann wrote: > The driver supplies a TX frame transmit function (mostly like if_transmit > today) which does all locking and multi-queue handling internally (driver > owned. This gives driver writers the freedom to better adjust to different > hardware communication methods as they become available, like we witnessed > a couple of times in the past. How would you handle TX dequeue? I'm curious because I got a nice speedup with cpsw by not using the TX interrupt at all: I just dequeued completed packets at the end of the TX transmit function. I suppose this would still work with your scheme. Tim From owner-freebsd-current@FreeBSD.ORG Thu Aug 8 03:40:24 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0732E83B; Thu, 8 Aug 2013 03:40:24 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D13D3204F; Thu, 8 Aug 2013 03:40:20 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r783e84H080403; Thu, 8 Aug 2013 03:40:08 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id u9zpp422c7ztvadbitukha32a2; Thu, 08 Aug 2013 03:40:08 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: [net] protecting interfaces from races between control and data ? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <520127C3.3020101@freebsd.org> Date: Wed, 7 Aug 2013 20:37:36 -0700 Content-Transfer-Encoding: 7bit Message-Id: <170757A0-2A8A-4F48-B5A0-20EC725B963B@kientzle.com> References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> <5200136C.8000201@freebsd.org> <20130805215319.GA43271@onelab2.iet.unipi.it> <520127C3.3020101@freebsd.org> To: Andre Oppermann X-Mailer: Apple Mail (2.1283) Cc: Adrian Chadd , current@FreeBSD.org, Bryan Venteicher , Navdeep Parhar , net@FreeBSD.org, Giuseppe Lettieri , Luigi Rizzo 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: Thu, 08 Aug 2013 03:40:24 -0000 On Aug 6, 2013, at 9:43 AM, Andre Oppermann wrote: > The driver supplies a TX frame transmit function (mostly like if_transmit > today) which does all locking and multi-queue handling internally (driver > owned. This gives driver writers the freedom to better adjust to different > hardware communication methods as they become available, like we witnessed > a couple of times in the past. How would you handle TX dequeue? I'm curious because I got a nice speedup with cpsw by not using the TX interrupt at all: I just dequeued completed packets at the end of the TX transmit function. I suppose this would still work with your scheme. Tim From owner-freebsd-current@FreeBSD.ORG Thu Aug 8 05:24:00 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 96EA0126 for ; Thu, 8 Aug 2013 05:24:00 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 60BCF25D7 for ; Thu, 8 Aug 2013 05:24:00 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id k5so1152397iea.32 for ; Wed, 07 Aug 2013 22:23:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=A6d5m82Sa/9n59wqACzPWp2Y7d3RMd9JFkFh0a1SBHM=; b=Ae3Cx3G+eNbjrpGW0kOTf7yJrTgOQbuCxWI9offPSd/vjEGgHfzSt1XECwCYkgRmqL tBSWxtNniW7Gc8LaZCUTZby45HiqMsuv660AyEeBx89D4DeuyxWBxNUHUXCVQ6Nl1+0v ZQeE+QlTUZU8aKqqN9fN+/R0MTZeFKuovjzfBJ3b0AiRGD2CSSux6iranr6JtiNeC6Hp RQj7Otvwac2bbDYM4quBnN45hsam9bBxbBSrz9qRcdl20YbLkZ+uRzwzAzhWcMlKTCmR 9CuF0cU9b8uCO8cUVqr/pRp8TXr3FQMC4nuvJ9xoKnoHCFJUHCy2cqJmAFkgZy70Z0Ps KSCg== X-Gm-Message-State: ALoCoQk8nK1iET8dzw6+9yVTEFCsAdtXVIjRN5mJ0f9SnLf/pCiiX4qyokRn9X2xv6stkwaUIhrJ X-Received: by 10.42.83.201 with SMTP id i9mr1296037icl.110.1375938998922; Wed, 07 Aug 2013 22:16:38 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id io8sm5063623igb.7.2013.08.07.22.16.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 Aug 2013 22:16:38 -0700 (PDT) Sender: Warner Losh Subject: Re: [net] protecting interfaces from races between control and data ? Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Wed, 7 Aug 2013 23:16:36 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> To: Adrian Chadd X-Mailer: Apple Mail (2.1085) Cc: current@freebsd.org, Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri , Luigi Rizzo 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: Thu, 08 Aug 2013 05:24:00 -0000 On Aug 5, 2013, at 11:20 AM, Adrian Chadd wrote: > .. and I bet it's not a design pattern, and this is total conjecture = on my part: >=20 > * the original drivers weren't SMP safe; > * noone really sat down and figured out how to correctly synchronise > all of this stuff; > * people did the minimum amount of work to keep the driver from > immediately crashing, but didn't really think things through at a > larger scale. >=20 > Almost every driver is this way Luigi. :-) Most of the drivers in the three don't support hardware that performs = well enough for this to be a problem. :) Any driver that's still around = from the pre-locking days can easily saturate the lines (or the = hardware) on today's (and even yesterday's hardware). All the rest have come up with different ways to cope... Warner From owner-freebsd-current@FreeBSD.ORG Thu Aug 8 06:53:34 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B63814F9 for ; Thu, 8 Aug 2013 06:53:34 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 99E2129F5 for ; Thu, 8 Aug 2013 06:53:34 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.89,837,1367996400"; d="asc'?scan'208";a="272234742" Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx1-out.netapp.com with ESMTP; 07 Aug 2013 23:53:33 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.240]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Wed, 7 Aug 2013 23:53:32 -0700 From: "Eggert, Lars" To: freebsd-current Subject: nfsd server cache flooded, try to increase nfsrc_floodlevel Thread-Topic: nfsd server cache flooded, try to increase nfsrc_floodlevel Thread-Index: AQHOlAP+ylZAPzFePkW/vcJEBx2JqQ== Date: Thu, 8 Aug 2013 06:53:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_DCCAA671-D7B1-479D-A9B7-A4D0585935DB"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: Rick Macklem 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: Thu, 08 Aug 2013 06:53:34 -0000 --Apple-Mail=_DCCAA671-D7B1-479D-A9B7-A4D0585935DB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, every few days or so, my -STABLE NFS server (v3 and v4) gets wedged with = a ton of messages about "nfsd server cache flooded, try to increase = nfsrc_floodlevel" in the log, and nfsstat shows TCPPeak at 16385. It = requires a reboot to unwedge, restarting the server does not help. The clients are (mostly) six -CURRENT nfsv4 boxes that netboot from the = server and mount all drives from there. I googled around and saw that others have hit this issue, but I haven't = seen any resolution posted. I guess I can increase NFSRVCACHE_FLOODLEVEL = in the source, but I wonder if I wouldn't simply hit the increase value = after a little while longer... Lars --Apple-Mail=_DCCAA671-D7B1-479D-A9B7-A4D0585935DB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQCVAwUBUgNAbNZcnpRveo1xAQJnxAP/SjcdE0q+Bu3/0rcPVHH4Wnkm4fFgsVlh K79ESGjdx1w85fT+WwYZeEVN3ff2wh/vx5lSrSAED0cp/KtMIF2t2sD6OrX8MExv 3EOFKOy0BJ/3g1LFxjG6Cy11l7NkeE7rwsjUa5mvuVPHY7bjv3KXwVKIBY8grMIC aZevQzu2Re0= =ARd/ -----END PGP SIGNATURE----- --Apple-Mail=_DCCAA671-D7B1-479D-A9B7-A4D0585935DB-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 8 08:31:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 60CC7830; Thu, 8 Aug 2013 08:31:22 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from s1.omnilan.de (s1.omnilan.de [217.91.127.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ECD5E2ED5; Thu, 8 Aug 2013 08:31:21 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by s1.omnilan.de (8.13.8/8.13.8) with ESMTP id r788VFMI094776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Aug 2013 10:31:15 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <52035753.1080006@omnilan.de> Date: Thu, 08 Aug 2013 10:31:15 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Kevin Oberman Subject: Re: MPSAFE VFS -- List of upcoming actions References: <20120829060158.GA38721@x2.osted.lan> <20120831052003.GA91340@x2.osted.lan> <20120905201531.GA54452@x2.osted.lan> <20120917140055.GA9037@x2.osted.lan> <52028C31.6060908@omnilan.de> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBADF1F97E6A532456356F403" Cc: Attilio Rao , FreeBSD FS , FreeBSD current 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: Thu, 08 Aug 2013 08:31:22 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBADF1F97E6A532456356F403 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bez=C3=BCglich Kevin Oberman's Nachricht vom 08.08.2013 01:11 (localtime= ): > On Wed, Aug 7, 2013 at 11:04 AM, Harald Schmalzbauer < > h.schmalzbauer@omnilan.de> wrote: > >> Bez=C3=BCglich Attilio Rao's Nachricht vom 14.10.2012 02:27 (localtim= e): >>> On Fri, Sep 21, 2012 at 1:22 AM, Attilio Rao >> wrote: >>>> On Wed, Sep 19, 2012 at 3:48 AM, Attilio Rao >> wrote: >>>>> On Fri, Jul 13, 2012 at 12:18 AM, Attilio Rao = >> wrote: >>>>>> 2012/7/4 Attilio Rao : >>>>>>> 2012/6/29 Attilio Rao : >>>>>>>> As already published several times, according to the following p= lan: >>>>>>>> http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS >>>>>>>> >>>>>>> I still haven't heard from Vivien or Edward, anyway as NTFS is >>>>>>> basically only used RO these days (also the mount_ntfs code just >>>>>>> permits RO mounting) I stripped all the uncomplete/bogus write >> support >>>>>>> with the following patch: >>>>>>> http://www.freebsd.org/~attilio/ntfs_remove_write.patch >>>>>>> >>>>>>> This is an attempt to make the code smaller and possibly just foc= us >> on >> >> ... >> >>> I've committed the FUSE support into base as r241519. >> Thank you for your great work! >> I had used >> http://www.freebsd.org/~attilio/fuse_import/fuse_stable9_241030.patch >> with releng/9.1. >> Some improovements were made in the meantime in head. >> I'm not familiar with svn. >> Was it possible to generate a new patchset against releng/9.2? I'd hav= e >> to concat manually downloadad revisions via svnweb... :-( >> >> Thanks a lot, >> >> -Harry >> >> Already done. All of the changes in head have been back-ported to > 9.2-PRERELEASE with the exception of a locking enhancement not availabl= e > outside of current. You can find it at: > https://docs.google.com/file/d/0B9QNUQlebx5UdlhPUTB4TXF6enc/edit?usp=3D= sharing Great, I found accidentally the download-arrow for fuse_stable9_253631.patch after enabling java script - not used to google interfaces... (for those who want to get the patch with fetch/wget/...:=20 ftp://ftp.omnilan.de/pub/FreeBSD/OmniLAN/deploy-tools/local-patches/RELEN= G_9_2/no_autoapply/fuse_stable9_253631.patch.orig ) There's still only GENERIC for amd64 altered to include fuse by default. Any reason why not i386? I'd not include it in any GENERIC kernel, I'd prefer keeping it loadable... Just for interest, is there a one-liner to get such a patchset out of svn? Looks like the above was done with local sourcetree, not svn internally? Best regards, -Harry --------------enigBADF1F97E6A532456356F403 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlIDV1MACgkQLDqVQ9VXb8gK1QCgnPmClsA2n5SLya5XgNClLYMJ NJcAn0WvKgg2vngB9UFz8KOwYB4fI//h =uKE3 -----END PGP SIGNATURE----- --------------enigBADF1F97E6A532456356F403-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 8 09:42:10 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 752E0E98; Thu, 8 Aug 2013 09:42:10 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7E1A823B6; Thu, 8 Aug 2013 09:42:09 +0000 (UTC) Received: from gate.nw-fva.de ([134.76.242.1] helo=pc028.nfv) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1V7MjP-0005KL-AY; Thu, 08 Aug 2013 11:42:07 +0200 Message-ID: <520367EB.2060204@gwdg.de> Date: Thu, 08 Aug 2013 11:42:03 +0200 From: Rainer Hurling User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130802 Thunderbird/17.0.7 MIME-Version: 1.0 To: Baptiste Daroussin Subject: Re: Port problems after r253839 on HEAD References: <520283C9.8030806@gwdg.de> <20130807174333.GK40254@ithaqua.etoilebsd.net> <52029973.5070607@gwdg.de> In-Reply-To: <52029973.5070607@gwdg.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: 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: Thu, 08 Aug 2013 09:42:10 -0000 Am 07.08.2013 21:01 (UTC+1) schrieb Rainer Hurling: > Thanks, Bapt, for answering. > > Am 07.08.2013 19:43, schrieb Baptiste Daroussin: >> On Wed, Aug 07, 2013 at 07:28:41PM +0200, Rainer Hurling wrote: >>> After introducing r253839 on HEAD (/head/contrib/binutils/ld/ldmain.c), >>> I recognized some wired behaviour in the ports system on my CURRENT boxes. >>> >>> Some of the ports do not build anymore. They print almost similar >>> messages about an ld problem (invalid DSO for symbol 'xxx' definition), >>> followed by the lib, which symbols are not found. >>> >>> With a recent 10.0-CURRENT (at least r253839) you can try this for >>> example with the following two ports: >>> >> normally I had tracked down all those ports, except if you are building them >> with nom default options, > > #cd /usr/ports/www/evolution-webcal > #make config > ===> No options to configure > > #cd /usr/ports/editors/nano > #make config > ===> No options to configure > >> What that means is basically the said ports are missing some -lbla in ldflags, >> >> The missing ones are those listed in the line following the DSO bla >> in nano for example the first failure means -liconv is missing. > > Yupp, thanks, the following two patches seem to work: > > --- Makefile.orig 2013-07-17 16:59:50.000000000 +0200 > +++ Makefile 2013-08-07 20:42:11.000000000 +0200 > @@ -15,11 +15,13 @@ > > CONFLICTS= nano-devel-2* > > +LIB_DEPENDS= tinfow:${PORTSDIR}/devel/ncurses > + > GNU_CONFIGURE= yes > > CONFIGURE_ARGS= --docdir=${DOCSDIR} > CPPFLAGS+= -I${LOCALBASE}/include > -LDFLAGS+= -L${LOCALBASE}/lib > +LDFLAGS+= -L${LOCALBASE}/lib -ltinfow > > .include > > > > --- Makefile.orig 2013-06-20 17:40:13.000000000 +0200 > +++ Makefile 2013-08-07 20:47:21.000000000 +0200 > @@ -23,7 +23,7 @@ > USE_GNOME= gnomeprefix gnomehack intlhack evolutiondataserver libgnomeui > GNU_CONFIGURE= yes > CPPFLAGS+= -I${LOCALBASE}/include > -LDFLAGS+= -L${LOCALBASE}/lib > +LDFLAGS+= -L${LOCALBASE}/lib -lgthread-2.0 > > GCONF_SCHEMAS= evolution-webcal.schemas > > >> >> I afk until 24th so I can't commit any fix to the said ports. > > >> There were properly building in my exp-run for the said change, meaning either >> you build with non default options im that case the port requires a fix or >> perhaps your ports tree is not uptodate, in particular lots of those failures >> are fixed by the recent glib update. > > Hmm. As far as I can say my ports tree is uptodate and I did the > complete glib update (/usr/ports/UPDATING entry 20130731). So I have no > clue, why editors/nano does complain about devel/ncurses. > > In particular I am wondering about the misbehaviour of my port > math/saga. As I wrote before, the autotools process does not find > libopencv.so, only and only if HEAD is using /usr/bin/ld r253839. > Probably there is a hidden problem, not seen before without the ld > patch? Any hint would be very appreciated. Ok, after getting your hint about missing LDFLAGS I narrowed it down for SAGA GIS 2.1.0. As complained in the config.log, conftest for autotools is also missing one library. The following in math/saga should do the trick (I will open a PR for it): --- Makefile.orig 2013-07-31 18:09:58.000000000 +0200 +++ Makefile 2013-08-08 11:11:15.000000000 +0200 @@ -47,7 +47,7 @@ .include -LDFLAGS+= -L${LOCALBASE}/lib +LDFLAGS+= -L${LOCALBASE}/lib -lopencv_core CONFIGURE_ARGS+= CFLAGS="${CFLAGS}" LDFLAGS="${LDFLAGS}" .if ${PORT_OPTIONS:MPYTHON} So no problems left for me with new /usr/bin/ld :) Thanks again for any help. Greetings, Rainer > > Many thanks for your fast help and greetings from Göttingen in Germany, > Rainer >> >> regards, >> Bapt >> From owner-freebsd-current@FreeBSD.ORG Thu Aug 8 12:20:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C32B95FB for ; Thu, 8 Aug 2013 12:20:59 +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 8AB692DF5 for ; Thu, 8 Aug 2013 12:20:59 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAIeMA1KDaFve/2dsb2JhbABbFoMlUIMUuzWBMHSCJAEBBSNWGxgCAg0ZAlkGiCMMpx+RMYEojTiBBzQHgmeBJwOZC4h5hyyDNCCBLUE X-IronPort-AV: E=Sophos;i="4.89,838,1367985600"; d="scan'208";a="44060615" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 08 Aug 2013 08:20:58 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id B1761B3EEF; Thu, 8 Aug 2013 08:20:58 -0400 (EDT) Date: Thu, 8 Aug 2013 08:20:58 -0400 (EDT) From: Rick Macklem To: Lars Eggert Message-ID: <1578548312.7148700.1375964458716.JavaMail.root@uoguelph.ca> In-Reply-To: Subject: Re: nfsd server cache flooded, try to increase nfsrc_floodlevel 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 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: freebsd-current 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: Thu, 08 Aug 2013 12:20:59 -0000 Lars Eggert wrote: > Hi, > > every few days or so, my -STABLE NFS server (v3 and v4) gets wedged > with a ton of messages about "nfsd server cache flooded, try to > increase nfsrc_floodlevel" in the log, and nfsstat shows TCPPeak at > 16385. It requires a reboot to unwedge, restarting the server does > not help. > > The clients are (mostly) six -CURRENT nfsv4 boxes that netboot from > the server and mount all drives from there. > > I googled around and saw that others have hit this issue, but I > haven't seen any resolution posted. I guess I can increase > NFSRVCACHE_FLOODLEVEL in the source, but I wonder if I wouldn't > simply hit the increase value after a little while longer... > > Lars > You can either try this patch (which dynamically adjusts nfsrc_floodlevel along with handling a variety of overhead issues for the DRC under heavy load): http://people.freebsd.org/~rmacklem/drc4.patch or just bump it up a bunch. The default value was safe for a server with 256Mbytes of ram and a default mbuf cluster limit. The only thing you might have to do along with bumping NFSRC_FLOODLEVEL up is increasing kern.ipc.mbclusters. The variant of the above patch will make it into head someday, once I merge in changes from ivoras@'s similar patch and confer with him about it. rick From owner-freebsd-current@FreeBSD.ORG Thu Aug 8 15:14:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DBDD431D; Thu, 8 Aug 2013 15:14:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AD70D2A2F; Thu, 8 Aug 2013 15:14:24 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9E90BB939; Thu, 8 Aug 2013 11:14:23 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: svn error during 'make buildkernel'? Date: Thu, 8 Aug 2013 11:14:05 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: <20130803210348.GA715@troutmask.apl.washington.edu> <20130806181107.GR34979@over-yonder.net> <20130806183054.GB2190@glenbarber.us> In-Reply-To: <20130806183054.GB2190@glenbarber.us> MIME-Version: 1.0 Message-Id: <201308081114.05978.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 08 Aug 2013 11:14:23 -0400 (EDT) Cc: Glen Barber , Steve Kargl , Peter Wemm , "Matthew D. Fuller" 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: Thu, 08 Aug 2013 15:14:24 -0000 On Tuesday, August 06, 2013 2:30:54 pm Glen Barber wrote: > On Tue, Aug 06, 2013 at 01:11:07PM -0500, Matthew D. Fuller wrote: > > On Sun, Aug 04, 2013 at 08:55:30PM -0400 I heard the voice of > > Glen Barber, and lo! it spake thus: > > > > > > The error generated is non-fatal, and once I receive response on a > > > proposed patch, will be suppressed if the svn version used to check > > > out the tree is not compatible with that used to check the version > > > of the tree with the kernel build. > > > > But not try the ports svn as well? I mean, as breakage goes, it's not > > even in the top 100; I'd _much_ rather have a kernel that I have to > > guess the revision of but boots, than one properly recorded that > > doesn't. But it's still unpleasant, and is one of those things you > > probably won't notice missing until suddenly you need it. > > > > And this isn't just a presentism. Sure, right _now_ devel/subversion > > and base svnlite get along, but what happens when ports moves to 1.9 > > which changes the WT format? Even if -CURRENT src gets upgraded > > simultaneously[0], the same surely can't be said of every back branch. > > > > I realize this is all still a WIP, and please don't read any anger > > into my words. But this _has_ been something I've found a little > > worrisome since the original import/newvers change. Heck, newvers can > > show me version info if I'm getting my source tree from git or p4, but > > can't handle ports svn? By the time this works its way into a stable > > branch, I really think it should either handle svnversion from ports > > as well, or come with a big bright flashing warning that using svn > > from anything but base svnlite for /usr/src is a degraded experience. > > > > > > [0] Which still wouldn't really fix things, since > > /usr/bin/svnliteversion is arbitrarily old, not up to date with > > the source tree. > > > > I have this on my todo list, but right now I have bigger things to deal > with. As soon as I can, I will fix the logic. Right now, it is not "as > easy as checking which svn works", because the more I look at the logic > for newvers.sh, the more I dislike how it all works. BTW, I was totally surprised by this recent error on my laptop which still has 1.7 installed. I don't rebuild ports all the time because it's a PITA. I think the fact that svnliteversion is used in preference to svnversion is a huge POLA violation and completely agree with Steve on this one. It shouldn't be that hard to just check $? and fallback to svnliteversion if svnversion fails. I have much more complex hacks in place at work where we have active 1.6, 1.7, and 1.8 clients. :( -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Aug 8 15:59:29 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DCF54E0F; Thu, 8 Aug 2013 15:59:28 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 96C0E2E9B; Thu, 8 Aug 2013 15:59:28 +0000 (UTC) Received: from glenbarber.us (unknown [IPv6:2001:470:8:120e:1:1:c57c:729]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 48D00A7DD; Thu, 8 Aug 2013 15:59:26 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 48D00A7DD Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Thu, 8 Aug 2013 11:59:24 -0400 From: Glen Barber To: John Baldwin Subject: Re: svn error during 'make buildkernel'? Message-ID: <20130808155924.GA29016@glenbarber.us> References: <20130803210348.GA715@troutmask.apl.washington.edu> <20130806181107.GR34979@over-yonder.net> <20130806183054.GB2190@glenbarber.us> <201308081114.05978.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LQksG6bCIzRHxTLp" Content-Disposition: inline In-Reply-To: <201308081114.05978.jhb@freebsd.org> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, Steve Kargl , Peter Wemm , "Matthew D. Fuller" 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: Thu, 08 Aug 2013 15:59:29 -0000 --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 08, 2013 at 11:14:05AM -0400, John Baldwin wrote: > On Tuesday, August 06, 2013 2:30:54 pm Glen Barber wrote: > > On Tue, Aug 06, 2013 at 01:11:07PM -0500, Matthew D. Fuller wrote: > > > On Sun, Aug 04, 2013 at 08:55:30PM -0400 I heard the voice of > > > Glen Barber, and lo! it spake thus: > > > >=20 > > > > The error generated is non-fatal, and once I receive response on a > > > > proposed patch, will be suppressed if the svn version used to check > > > > out the tree is not compatible with that used to check the version > > > > of the tree with the kernel build. > > >=20 > > > But not try the ports svn as well? I mean, as breakage goes, it's not > > > even in the top 100; I'd _much_ rather have a kernel that I have to > > > guess the revision of but boots, than one properly recorded that > > > doesn't. But it's still unpleasant, and is one of those things you > > > probably won't notice missing until suddenly you need it. > > >=20 > > > And this isn't just a presentism. Sure, right _now_ devel/subversion > > > and base svnlite get along, but what happens when ports moves to 1.9 > > > which changes the WT format? Even if -CURRENT src gets upgraded > > > simultaneously[0], the same surely can't be said of every back branch. > > >=20 > > > I realize this is all still a WIP, and please don't read any anger > > > into my words. But this _has_ been something I've found a little > > > worrisome since the original import/newvers change. Heck, newvers can > > > show me version info if I'm getting my source tree from git or p4, but > > > can't handle ports svn? By the time this works its way into a stable > > > branch, I really think it should either handle svnversion from ports > > > as well, or come with a big bright flashing warning that using svn > > > from anything but base svnlite for /usr/src is a degraded experience. > > >=20 > > >=20 > > > [0] Which still wouldn't really fix things, since > > > /usr/bin/svnliteversion is arbitrarily old, not up to date with > > > the source tree. > > >=20 > >=20 > > I have this on my todo list, but right now I have bigger things to deal > > with. As soon as I can, I will fix the logic. Right now, it is not "as > > easy as checking which svn works", because the more I look at the logic > > for newvers.sh, the more I dislike how it all works. >=20 > BTW, I was totally surprised by this recent error on my laptop which still > has 1.7 installed. I don't rebuild ports all the time because it's a PIT= A. > I think the fact that svnliteversion is used in preference to svnversion > is a huge POLA violation and completely agree with Steve on this one. > It shouldn't be that hard to just check $? and fallback to svnliteversion > if svnversion fails. I have much more complex hacks in place at work whe= re > we have active 1.6, 1.7, and 1.8 clients. :( >=20 Fixed in r254094. Glen --LQksG6bCIzRHxTLp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBCAAGBQJSA8BcAAoJEFJPDDeguUajOVoH/iQwaIVhk5nqRe5Ogve5gUgy PuxACYXBzo7yEiTSE60yI0UGYeOHM3MgvP7GReMc3/O9QVsy6snq+OOsI/8RWuz3 TTfZ+dt5865oYw7+ZcT+g5J/lVJFd1hXlvbSiX92br1zXqcFdL4dhRdp+vljAXi4 WoL19bpzhbtBb4uWRtPG2c5qM3eSrnUuf8CFl9Z78l+g7tmdi3OkcVWaJQ1/EUtg 6PzBCJ4UG5ow/hsU2kOIyVbvr2bEgT/ydvqoqsdwiCN9xV7L8z9VGRw2AA6Fq44M oDgrbpBqmjW28pvLRqm9NUVUvHErYZQG32IY2GwQWukCpK8sK2pHHSNtEJYonLQ= =FdTZ -----END PGP SIGNATURE----- --LQksG6bCIzRHxTLp-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 8 18:06:23 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 924794BB for ; Thu, 8 Aug 2013 18:06:23 +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]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4EBA228A3 for ; Thu, 8 Aug 2013 18:06:23 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1V7UbN-0044II-MA>; Thu, 08 Aug 2013 20:06:21 +0200 Received: from e179190106.adsl.alicedsl.de ([85.179.190.106] helo=munin.geoinf.fu-berlin.de) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1V7UbN-002dcH-Io>; Thu, 08 Aug 2013 20:06:21 +0200 Date: Thu, 8 Aug 2013 20:10:18 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present Message-ID: <20130808201018.1215f733@munin.geoinf.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd9.2) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/OcDuIse3+pvhsy2ZuiWDaCL"; protocol="application/pgp-signature" X-Originating-IP: 85.179.190.106 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: Thu, 08 Aug 2013 18:06:23 -0000 --Sig_/OcDuIse3+pvhsy2ZuiWDaCL Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable The most recent CURRENT doesn't work with the x11/nvidia-driver (which is at 319.25 in the ports and 325.15 from nVidia). After build- and installworld AND successfully rebuilding port x11/nvidia-driver, the system crashes immediately after a reboot as soon the kernel module nvidia.ko seems to get loaded (in my case, I load nvidia.ko via /etc/rc.conf.local since the nVidia BLOB doesn't load cleanly everytime when loaded from /boot/loader.conf). The crash occurs on systems with default compilation options set while building world and with settings like -O3 -march=3Dnative. It doesn't matter.=20 FreeBSD and the port x11/nvidia-driver has been compiled with CLANG. Most recent FreeBSD revision still crashing is r254097. When vmcore is saved, I always see something like savecore: reboot after panic: vm_radix_insert: key 23c078 is already present=20 Does anyone has any idea what's going on? Thanks for helping in advance, Oliver --Sig_/OcDuIse3+pvhsy2ZuiWDaCL Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBAgAGBQJSA98KAAoJEOgBcD7A/5N8SIYH/RG1DWY4IzYL+hUPXI2jPPeJ Ks+MoWdWcs1TbfJyhDxFMjyrZYwD2yHZ5iZq2JKJ5+R6NqfznaINAjWmMPdS8nE2 i0zcklfPZ3BJRfq2OtAO3Wk9GBmTtvJWZR0mHNiZdLFVhXNdhEsRqzOG07QEbtek 1AR03IvZKXrjkHWsZPEQSEOEI8cuMFGwWjVFA5ATw4TywHpWKkSMBDDI6H92V7Ck ePCNSm9wMt0gPb9rjjtKYcPqWcWJDGj4N/da1VIh5GZzdd+YXAPJuIxVC0vJhTYj 7goMczjtDpLbkzsv2gT6zX3Z4DlLBwntwnC2yS1o2UXLMy4rphOG3C5fb6BO6UA= =4Rm0 -----END PGP SIGNATURE----- --Sig_/OcDuIse3+pvhsy2ZuiWDaCL-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 8 18:15:02 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 10D8F857 for ; Thu, 8 Aug 2013 18:15:02 +0000 (UTC) (envelope-from lifanov@mail.lifanov.com) Received: from mail.lifanov.com (mail.lifanov.com [206.125.175.12]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EE6D22938 for ; Thu, 8 Aug 2013 18:15:01 +0000 (UTC) Received: from [10.1.3.5] (cnet520-windstream.mcclatchyinteractive.com [166.108.16.2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.lifanov.com (Postfix) with ESMTPSA id CE9711A02F7; Thu, 8 Aug 2013 18:14:54 +0000 (UTC) Message-ID: <5203E01D.6010007@mail.lifanov.com> Date: Thu, 08 Aug 2013 14:14:53 -0400 From: Nikolai Lifanov User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130801 Thunderbird/17.0.7 MIME-Version: 1.0 To: "O. Hartmann" Subject: Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present References: <20130808201018.1215f733@munin.geoinf.fu-berlin.de> In-Reply-To: <20130808201018.1215f733@munin.geoinf.fu-berlin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD CURRENT 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: Thu, 08 Aug 2013 18:15:02 -0000 On 08/08/13 14:10, O. Hartmann wrote: > The most recent CURRENT doesn't work with the x11/nvidia-driver (which > is at 319.25 in the ports and 325.15 from nVidia). > > After build- and installworld AND successfully rebuilding port > x11/nvidia-driver, the system crashes immediately after a reboot as > soon the kernel module nvidia.ko seems to get loaded (in my case, I > load nvidia.ko via /etc/rc.conf.local since the nVidia BLOB doesn't > load cleanly everytime when loaded from /boot/loader.conf). > > The crash occurs on systems with default compilation options set while > building world and with settings like -O3 -march=native. It doesn't > matter. > > FreeBSD and the port x11/nvidia-driver has been compiled with CLANG. > > Most recent FreeBSD revision still crashing is r254097. > > When vmcore is saved, I always see something like > > savecore: reboot after panic: vm_radix_insert: key 23c078 is already > present > > > Does anyone has any idea what's going on? > > Thanks for helping in advance, > > Oliver > I don't know what might be going on, but another piece of data: I can say that it works on r254097 with -O2 -march=corei7-avx - Nikolai Lifanov From owner-freebsd-current@FreeBSD.ORG Thu Aug 8 18:30:25 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E90E91E0 for ; Thu, 8 Aug 2013 18:30:25 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 80F702AAC for ; Thu, 8 Aug 2013 18:30:25 +0000 (UTC) Received: by mail-we0-f169.google.com with SMTP id n5so2868052wev.28 for ; Thu, 08 Aug 2013 11:30:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=RQ20p2d69yx/zRqqgD+92v2kTim9QwhC5ItihxcrzXk=; b=nI3O/5y5oxzuG1lqzMqaVqwq9e5rjwIWUOe55pGj1zRxUifbDoNFyRL0DRd7rVkAGp 0nayTGccSaVIvx6mLtniNjGeqN4corWFAuvwRKwXE6W4EHhx4rRTfHreM0T947ePyjUK 6cHeIMmvDBP8hZjHBTP2HuISyWCRmJeemZD6EXf6BBAsG134fgvDKguNMiLw1QWCjQCW cj5SatF14FNW07mUVnw0CfK2en3tVbgwSuVsy6+PmIUWnhKWS9QeBHwyS0g+5UNQCdXN sNQ4Iunuu5SiYyGXGo7+bxncykyT6s/CPNCjOPRFBDAYjC65SEXeWSIHsRZI886cTsps SEzw== MIME-Version: 1.0 X-Received: by 10.180.160.165 with SMTP id xl5mr114343wib.46.1375986623805; Thu, 08 Aug 2013 11:30:23 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.116.136 with HTTP; Thu, 8 Aug 2013 11:30:23 -0700 (PDT) In-Reply-To: <20130808201018.1215f733@munin.geoinf.fu-berlin.de> References: <20130808201018.1215f733@munin.geoinf.fu-berlin.de> Date: Thu, 8 Aug 2013 11:30:23 -0700 X-Google-Sender-Auth: i6d6RCiP_q49ycLqswV-V4K7OSE Message-ID: Subject: Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present From: Adrian Chadd To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD CURRENT 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: Thu, 08 Aug 2013 18:30:26 -0000 Can you go over some previous versions in -HEAD and see when it was introduced? -adrian On 8 August 2013 11:10, O. Hartmann wrote: > The most recent CURRENT doesn't work with the x11/nvidia-driver (which > is at 319.25 in the ports and 325.15 from nVidia). > > After build- and installworld AND successfully rebuilding port > x11/nvidia-driver, the system crashes immediately after a reboot as > soon the kernel module nvidia.ko seems to get loaded (in my case, I > load nvidia.ko via /etc/rc.conf.local since the nVidia BLOB doesn't > load cleanly everytime when loaded from /boot/loader.conf). > > The crash occurs on systems with default compilation options set while > building world and with settings like -O3 -march=native. It doesn't > matter. > > FreeBSD and the port x11/nvidia-driver has been compiled with CLANG. > > Most recent FreeBSD revision still crashing is r254097. > > When vmcore is saved, I always see something like > > savecore: reboot after panic: vm_radix_insert: key 23c078 is already > present > > > Does anyone has any idea what's going on? > > Thanks for helping in advance, > > Oliver From owner-freebsd-current@FreeBSD.ORG Thu Aug 8 17:29:01 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D9E8BC25 for ; Thu, 8 Aug 2013 17:29:01 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm49-vm4.bullet.mail.gq1.yahoo.com (nm49-vm4.bullet.mail.gq1.yahoo.com [67.195.87.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A6AB226B5 for ; Thu, 8 Aug 2013 17:29:01 +0000 (UTC) Received: from [216.39.60.181] by nm49.bullet.mail.gq1.yahoo.com with NNFMP; 08 Aug 2013 17:23:21 -0000 Received: from [98.136.164.77] by tm17.bullet.mail.gq1.yahoo.com with NNFMP; 08 Aug 2013 17:23:21 -0000 Received: from [127.0.0.1] by smtp239.mail.gq1.yahoo.com with NNFMP; 08 Aug 2013 17:23:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1375982601; bh=HHyIreysPKOMyVa85kxfnCcsv9XcN3hRbm0UAG49ri0=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=R5MySjQhs9Ba95g/0Ofay/MYPmB89ldB85S09S4F87AbrE7f9BsMRxSKW3UltBTsPlFqtSPG1k6tZG2+OpMKckVfiydRjyhjKH8BStu6vrFL2FZ03+hPU0dnHDvrqdRr/Q+e+MUQcUEOUgAHdm7ujwFy1YDX2K/xR+KsVyf6eIg= X-Yahoo-Newman-Id: 124328.76621.bm@smtp239.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: icbtmfQVM1mMOJGwJdkQUTE60iZh8Je.6qTqkqCu1WxdEU. z8Wtun6FiHsxHJJ.VaTGXgLxFASl7Y3WoRNjql4J1W9tkn4oSMTZlEpvcBhh eDtdEY6CObvHdQ6EAnNI6Kqq62k9bdz80jLB3PrWYWGbmPFyDDGjJURWdUGt t8jEAJSOmOQOYh9YJfjHWPiQAetWIWMOg6IbyMtpD5Y1jz6BxxsECLAre1Ig 7Vru5b0Lg5cPCucicZCA4q8bCnXIxCy2jB7S63u.WsuhdQtv8laxhwf9iCBC N5pIzdt50YOHu8RmsQUGLHVdqjJKt83ArkBd_egL4itdnrEYxC2hMmkOt9MM TDXaezsQEaWvYZkZT3dKJetJe7WGCF25y8HIqqgaqVg1AzSu4a4Vr.E65cPj 0KkTdnkZXrZ9bHy5BUxQ8.eoCpxSnAKA3e_Tq7KW_EsNlaUL9PONStjq4Udp ploME_ZEwCycv5UPmGRmWy7FJDa.41D5wHq2R841U64gKECYeEfRJvH_SgSh FM35hpLpYXkjrUcEK6mn69aqFo_UnXvm4FD8GHKhrWlYZyI.f8WHruBEdbfK j X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- X-Rocket-Received: from phobos.corp.netflix.com (scott4long@69.53.237.66 with ) by smtp239.mail.gq1.yahoo.com with SMTP; 08 Aug 2013 17:23:20 +0000 UTC Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: [net] protecting interfaces from races between control and data ? From: Scott Long In-Reply-To: Date: Thu, 8 Aug 2013 10:23:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3BFB5B13-78C5-47E0-81B8-29A03A0136DF@yahoo.com> References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> To: Warner Losh X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Thu, 08 Aug 2013 18:58:24 +0000 Cc: Adrian Chadd , current@freebsd.org, Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri , Luigi Rizzo 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: Thu, 08 Aug 2013 17:29:02 -0000 On Aug 7, 2013, at 10:16 PM, Warner Losh wrote: >=20 > On Aug 5, 2013, at 11:20 AM, Adrian Chadd wrote: >=20 >> .. and I bet it's not a design pattern, and this is total conjecture = on my part: >>=20 >> * the original drivers weren't SMP safe; >> * noone really sat down and figured out how to correctly synchronise >> all of this stuff; >> * people did the minimum amount of work to keep the driver from >> immediately crashing, but didn't really think things through at a >> larger scale. >>=20 >> Almost every driver is this way Luigi. :-) >=20 > Most of the drivers in the three don't support hardware that performs = well enough for this to be a problem. :) Any driver that's still around = from the pre-locking days can easily saturate the lines (or the = hardware) on today's (and even yesterday's hardware). >=20 > All the rest have come up with different ways to cope=85 >=20 Not really. So the typical pattern is: foo_rxeof() { =85. FOO_UNLOCK(sc); ifp->if_input(ifp, m); FOO_LOCK(sc); =85. } Grepping for an approximation of this pattern: [nflx1] ~/svn/head/sys/dev% grep -r -B 5 if_input * | grep -i UNLOCK | = cut -d '/' -f 1 ae age alc ale an an bce bfe bge bm cadence cas cas dc de e1000 e1000 e1000 ed ep et ex fe fxp gem gxemul hme ie ixgb ixgbe ixgbe jme le le lge mge msk msk my nfe nfe nge nve pcn pdq re sbni sf sge sis sk sk sn snc ste stge ti tl tsec tx txp usb usb vge virtio vr vte vx wb wl xe xl Sure a lot of these are very legacy. But there's a lot in here's that = are not. bge, bce, e1000, ixgbe, virtio, etc, probably more that I'm = not catching in this quick pass. Scott From owner-freebsd-current@FreeBSD.ORG Thu Aug 8 20:02:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 299D8631; Thu, 8 Aug 2013 20:02:15 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E26072F93; Thu, 8 Aug 2013 20:02:14 +0000 (UTC) Received: by mail-pa0-f48.google.com with SMTP id kp13so3953085pab.35 for ; Thu, 08 Aug 2013 13:02:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ZBXuRRbTKp753l88MLYIQlKsrU7YMQ7dr0J3nwjf8xE=; b=zGsUh6PgnKnJO7BP0dnED/1jaDvv7wj8X1TcautD5rtrx8uks2pPnOG7OQ013LS5Wv MOJrNwvenhId35A+tAdL20XQHoplFPd3n5uEAia6ztcbdsMoerRjv/sTBd4p2cBx2K9z M32R9k+SX4E0dGTT1bzxGJcIXodbKCjN/GS1oGN4ghLtMtiA99ee8YNfDC2iLf13EnT0 QvWAk+QjWffXTbCxsU48gkaANvlTqMi5kiSelJFhBku944bSpzn+siGAVD00Q4gz0Dph 84YFod7PKLX5GhINtCoC3XSA7Dnp2hYlOJ0j4l91kAaCnK727LXwzS52bq05d+Kje7uF bLnA== MIME-Version: 1.0 X-Received: by 10.66.102.70 with SMTP id fm6mr7989102pab.57.1375992134500; Thu, 08 Aug 2013 13:02:14 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.67.14.66 with HTTP; Thu, 8 Aug 2013 13:02:14 -0700 (PDT) In-Reply-To: <52035753.1080006@omnilan.de> References: <20120829060158.GA38721@x2.osted.lan> <20120831052003.GA91340@x2.osted.lan> <20120905201531.GA54452@x2.osted.lan> <20120917140055.GA9037@x2.osted.lan> <52028C31.6060908@omnilan.de> <52035753.1080006@omnilan.de> Date: Thu, 8 Aug 2013 13:02:14 -0700 X-Google-Sender-Auth: ip_vBuaaUcHPGXGegchzaQX-vAk Message-ID: Subject: Re: MPSAFE VFS -- List of upcoming actions From: Kevin Oberman To: Harald Schmalzbauer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Attilio Rao , FreeBSD FS , FreeBSD current 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: Thu, 08 Aug 2013 20:02:15 -0000 On Thu, Aug 8, 2013 at 1:31 AM, Harald Schmalzbauer < h.schmalzbauer@omnilan.de> wrote: > Bez=C3=BCglich Kevin Oberman's Nachricht vom 08.08.2013 01:11 (localtime= ): > > On Wed, Aug 7, 2013 at 11:04 AM, Harald Schmalzbauer < > > h.schmalzbauer@omnilan.de> wrote: > > > >> Bez=C3=BCglich Attilio Rao's Nachricht vom 14.10.2012 02:27 (localtim= e): > >>> On Fri, Sep 21, 2012 at 1:22 AM, Attilio Rao > >> wrote: > >>>> On Wed, Sep 19, 2012 at 3:48 AM, Attilio Rao > >> wrote: > >>>>> On Fri, Jul 13, 2012 at 12:18 AM, Attilio Rao > >> wrote: > >>>>>> 2012/7/4 Attilio Rao : > >>>>>>> 2012/6/29 Attilio Rao : > >>>>>>>> As already published several times, according to the following > plan: > >>>>>>>> http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS > >>>>>>>> > >>>>>>> I still haven't heard from Vivien or Edward, anyway as NTFS is > >>>>>>> basically only used RO these days (also the mount_ntfs code just > >>>>>>> permits RO mounting) I stripped all the uncomplete/bogus write > >> support > >>>>>>> with the following patch: > >>>>>>> http://www.freebsd.org/~attilio/ntfs_remove_write.patch > >>>>>>> > >>>>>>> This is an attempt to make the code smaller and possibly just foc= us > >> on > >> > >> ... > >> > >>> I've committed the FUSE support into base as r241519. > >> Thank you for your great work! > >> I had used > >> http://www.freebsd.org/~attilio/fuse_import/fuse_stable9_241030.patch > >> with releng/9.1. > >> Some improovements were made in the meantime in head. > >> I'm not familiar with svn. > >> Was it possible to generate a new patchset against releng/9.2? I'd hav= e > >> to concat manually downloadad revisions via svnweb... :-( > >> > >> Thanks a lot, > >> > >> -Harry > >> > >> Already done. All of the changes in head have been back-ported to > > 9.2-PRERELEASE with the exception of a locking enhancement not availabl= e > > outside of current. You can find it at: > > > https://docs.google.com/file/d/0B9QNUQlebx5UdlhPUTB4TXF6enc/edit?usp=3Dsh= aring > > Great, I found accidentally the download-arrow for > fuse_stable9_253631.patch after enabling java script - not used to > google interfaces... (for those who want to get the patch with > fetch/wget/...: > > ftp://ftp.omnilan.de/pub/FreeBSD/OmniLAN/deploy-tools/local-patches/RELEN= G_9_2/no_autoapply/fuse_stable9_253631.patch.orig > ) > > There's still only GENERIC for amd64 altered to include fuse by default. > Any reason why not i386? I'd not include it in any GENERIC kernel, I'd > prefer keeping it loadable... > > Just for interest, is there a one-liner to get such a patchset out of > svn? Looks like the above was done with local sourcetree, not svn > internally? > > Best regards, > > -Harry > I only updated the patches Attilio provided several months ago for 9-STABLE, and his patch-set only added the option for amd64. I see no reason that it should not be in i386, as well, but had not noticed since I run amd64 these days. You can certainly try adding the option to GENERIC on an i386 system and see what happens. I suspect it will work fine. If so (and unless I hear a reason not to from Attilio) I'll update the patch-set to do it. Kevin --=20 R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Thu Aug 8 21:39:25 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D1B73B16 for ; Thu, 8 Aug 2013 21:39:25 +0000 (UTC) (envelope-from sean_bruno@yahoo.com) Received: from nm6.bullet.mail.bf1.yahoo.com (nm6.bullet.mail.bf1.yahoo.com [98.139.212.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5721924EC for ; Thu, 8 Aug 2013 21:39:25 +0000 (UTC) Received: from [66.196.81.171] by nm6.bullet.mail.bf1.yahoo.com with NNFMP; 08 Aug 2013 21:39:23 -0000 Received: from [98.139.211.205] by tm17.bullet.mail.bf1.yahoo.com with NNFMP; 08 Aug 2013 21:39:23 -0000 Received: from [127.0.0.1] by smtp214.mail.bf1.yahoo.com with NNFMP; 08 Aug 2013 21:39:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1375997963; bh=/MJSCVaf6GLk5hf5TTmj3SFaXmX7zOYKmCOSarUQ0jY=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:Cc:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-Mailer; b=cd/Kh0MF8y0sIKtQuPDSBOTOa8qm5TZInImktbF1SnMD4VyBnrF4CWofpmPIZYGK21CGzVfW4hFic4I7RaTaq6W2Vb9/B5lA+AvuK1yuNJ2uawf8eJfuYoqXOQq3aLaVoNz7zI0NMMCxS/nJBJqYGOaDOyKxBCwt0fEzu2Omu/k= X-Yahoo-Newman-Id: 114802.1388.bm@smtp214.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: dKsfU6cVM1msASyPfIkrXsHeuZgVd.uDkUJDUgE.PN5M0b3 Cz2avl2nNBktCfPvf5X9nLGyy.FhHNFTq8EspukR6YSBu7J1q3Dj0BRv9yZx P4_xSaErBcOoyNLj2EHSUZWA8wYkQkEGXH.vxWruXS4EMhBv1vUOf4ab4aYa qaSaL7r4x_Ey3Y.DFUo9nW79T5IozrJKQmuLuLD50h8jCViXS2.iuOhR5d6T QyuV.9WSMK1BzTQxrKFOFal3bHXncJV5xXwncMdnSWDBxyezDivtVZLZ9v1y LuvtSX7pitnmo3YKLN_E7x.4_EqWLw_DzLLaiszVXGybLFUAcM5W52yTFKVr A13WfTHEHKps3DpiwS8z5pWxvJ29SJbNdp0cHG2eDzp4dJ8yWMBjiH3ZaiHg GtpNCkkvXjh2PM.IFhRYJVl2QuXL65I648crJiomRmBNFEBD0UHcjlwkMwO1 K7j6V_eJsPbB_5..1fCTWKwgWNqo0KG1egykdamOT78fGW40PK5eAzvHxTP0 hn3tSJ1TWXRoixf2cl5j7xV0Qke3iTNDVkW_h1KlVHzrMcGgOnLqIRlrSgW0 eyGtytQ-- X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4- X-Rocket-Received: from [10.73.160.242] (sean_bruno@209.131.62.116 with ) by smtp214.mail.bf1.yahoo.com with SMTP; 08 Aug 2013 14:39:23 -0700 PDT Subject: Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present From: Sean Bruno To: Adrian Chadd In-Reply-To: References: <20130808201018.1215f733@munin.geoinf.fu-berlin.de> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-SdVNa+GHKeosDG0Yjvs9" Date: Thu, 08 Aug 2013 14:39:21 -0700 Message-ID: <1375997961.1451.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: FreeBSD CURRENT , "O. Hartmann" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@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: Thu, 08 Aug 2013 21:39:26 -0000 --=-SdVNa+GHKeosDG0Yjvs9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Thu, 2013-08-08 at 11:30 -0700, Adrian Chadd wrote: > Can you go over some previous versions in -HEAD and see when it was intro= duced? >=20 >=20 >=20 > -adrian >=20 > On 8 August 2013 11:10, O. Hartmann wrote: > > The most recent CURRENT doesn't work with the x11/nvidia-driver (which > > is at 319.25 in the ports and 325.15 from nVidia). > > > > After build- and installworld AND successfully rebuilding port > > x11/nvidia-driver, the system crashes immediately after a reboot as > > soon the kernel module nvidia.ko seems to get loaded (in my case, I > > load nvidia.ko via /etc/rc.conf.local since the nVidia BLOB doesn't > > load cleanly everytime when loaded from /boot/loader.conf). > > > > The crash occurs on systems with default compilation options set while > > building world and with settings like -O3 -march=3Dnative. It doesn't > > matter. > > > > FreeBSD and the port x11/nvidia-driver has been compiled with CLANG. > > > > Most recent FreeBSD revision still crashing is r254097. > > > > When vmcore is saved, I always see something like > > > > savecore: reboot after panic: vm_radix_insert: key 23c078 is already > > present > > > > > > Does anyone has any idea what's going on? > > > > Thanks for helping in advance, > > > > Oliver I'm seeing a complete deadlock on my T520 with today's current and latest portsnap'd versions of ports for the nvidia-driver updates. A little bisection and help from others seems to point the finger at Jeff's r254025 I'm getting a complete deadlock on X starting, but loading the module seems to have no ill effects. Sean --=-SdVNa+GHKeosDG0Yjvs9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (FreeBSD) iQEcBAABAgAGBQJSBBACAAoJEBkJRdwI6BaHwegIAIsSPE5oC5/rCiWpoTcIwzXD 2tuXYUeercRV4wz4YCl5SXLAGCZ+xVI7lJqmlrzWdqUZbdl0/PIw05w8r1vDWsvN TQpK7cpN+qbJpR/rsSxQoOFFmBYzXOWI/UfXnyVjivfZi0gKFp1kLaKxtG4eXVja Nav9KrSyt90FDsKUuTt9X0EZFV0l83Nku1r8b7dPSEJ1q3u81DfYIUErj3a7UGyP kvzuwSqeHhhdHOL+/WXilkcj+dL5arzqu4LMn+Ed4JVhN1t8xcgZr9em49z27cwL xCs+O5VgQDpLRdAXY+3ktWXGpVOxR7jiBIWcxnVHSlFcNSCELLxLtaQiUKpLM/w= =eW6b -----END PGP SIGNATURE----- --=-SdVNa+GHKeosDG0Yjvs9-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 8 22:09:16 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E92BA93E for ; Thu, 8 Aug 2013 22:09:15 +0000 (UTC) (envelope-from jlh@FreeBSD.org) Received: from caravan.chchile.org (caravan.chchile.org [178.32.125.136]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7E44226D2 for ; Thu, 8 Aug 2013 22:09:15 +0000 (UTC) Received: by caravan.chchile.org (Postfix, from userid 1000) id 3CC83B7357; Thu, 8 Aug 2013 22:09:08 +0000 (UTC) Date: Fri, 9 Aug 2013 00:09:08 +0200 From: Jeremie Le Hen To: freebsd-current@FreeBSD.org Subject: panic: excl->share in zfs Message-ID: <20130808220908.GA76693@caravan.chchile.org> Mail-Followup-To: freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) 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: Thu, 08 Aug 2013 22:09:16 -0000 Hi guys, I've just got a panic with: FreeBSD obiwan 10.0-CURRENT FreeBSD 10.0-CURRENT #21: Sun Jul 21 21:37:10 CEST 2013 root@obiwan:/usr/obj/usr/src/sys/OBIWAN amd64 I have a core around if needed. obiwan:/usr/src# svn info Path: . Working Copy Root Path: /usr/src URL: http://svn0.us-west.freebsd.org/base/head Repository Root: http://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 253515 Node Kind: directory Schedule: normal Last Changed Author: des Last Changed Rev: 253515 Last Changed Date: 2013-07-21 09:24:25 +0200 (Sun, 21 Jul 2013) ddb capture buffer db:0:kdb.enter.panic> run lockinfo db:1:lockinfo> show locks exclusive lockmgr zfs (zfs) r = 0 (0xfffffe0046ac4d50) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1806 db:1:locks> show alllocks Process 29451 (git) thread 0xfffffe008bbc4000 (101227) exclusive lockmgr zfs (zfs) r = 0 (0xfffffe0046ac4d50) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1806 Process 11062 (sshd) thread 0xfffffe008c59a490 (101159) exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xfffffe008c268e40) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 db:1:alllocks> show lockedvnods Locked vnodes db:0:kdb.enter.panic> show pcpu cpuid = 1 dynamic pcpu = 0xffffff807f417080 curthread = 0xfffffe008bbc4000: pid 29451 "git" curpcb = 0xffffff80e61d8cc0 fpcurthread = none idlethread = 0xfffffe0009693490: tid 100004 "idle: cpu1" curpmap = 0xfffffe000969a138 tssp = 0xffffffff8108e2f8 commontssp = 0xffffffff8108e2f8 rsp0 = 0xffffff80e61d8cc0 gs32p = 0xffffffff8108fd50 ldt = 0xffffffff8108fd90 tss = 0xffffffff8108fd80 spin locks held: db:0:kdb.enter.panic> bt Tracing pid 29451 tid 101227 td 0xfffffe008bbc4000 kdb_enter() at kdb_enter+0x3e/frame 0xffffff80e61d7d10 vpanic() at vpanic+0x146/frame 0xffffff80e61d7d50 kassert_panic() at kassert_panic+0x136/frame 0xffffff80e61d7dc0 witness_checkorder() at witness_checkorder+0x327/frame 0xffffff80e61d7e50 __lockmgr_args() at __lockmgr_args+0x456/frame 0xffffff80e61d7f80 vop_stdlock() at vop_stdlock+0x3c/frame 0xffffff80e61d7fa0 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xffffff80e61d7fd0 _vn_lock() at _vn_lock+0xab/frame 0xffffff80e61d8040 zfs_lookup() at zfs_lookup+0x395/frame 0xffffff80e61d80d0 zfs_freebsd_lookup() at zfs_freebsd_lookup+0x6d/frame 0xffffff80e61d8210 VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xea/frame 0xffffff80e61d8240 vfs_cache_lookup() at vfs_cache_lookup+0xcf/frame 0xffffff80e61d8290 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xea/frame 0xffffff80e61d82c0 null_lookup() at null_lookup+0x8b/frame 0xffffff80e61d8330 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xea/frame 0xffffff80e61d8360 lookup() at lookup+0x590/frame 0xffffff80e61d83f0 namei() at namei+0x464/frame 0xffffff80e61d84a0 vn_open_cred() at vn_open_cred+0x28f/frame 0xffffff80e61d85f0 vop_stdvptocnp() at vop_stdvptocnp+0x1a4/frame 0xffffff80e61d8920 null_vptocnp() at null_vptocnp+0x2b/frame 0xffffff80e61d8980 VOP_VPTOCNP_APV() at VOP_VPTOCNP_APV+0xf0/frame 0xffffff80e61d89b0 vn_vptocnp_locked() at vn_vptocnp_locked+0x118/frame 0xffffff80e61d8a20 vn_fullpath1() at vn_fullpath1+0x1ca/frame 0xffffff80e61d8a80 kern___getcwd() at kern___getcwd+0xd6/frame 0xffffff80e61d8ae0 amd64_syscall() at amd64_syscall+0x265/frame 0xffffff80e61d8bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xffffff80e61d8bf0 --- syscall (326, FreeBSD ELF64, sys___getcwd), rip = 0x8016ad99c, rsp = 0x7fffffffd848, rbp = 0x76cd20 --- -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. From owner-freebsd-current@FreeBSD.ORG Thu Aug 8 22:37:43 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8EB363B4; Thu, 8 Aug 2013 22:37:43 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F201E285B; Thu, 8 Aug 2013 22:37:42 +0000 (UTC) Received: by mail-wg0-f54.google.com with SMTP id e12so3040761wgh.33 for ; Thu, 08 Aug 2013 15:37:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=oZWwo/8DLMcW32F0jDj+v/mk1Jc5BrLNNLpY+s/dPdA=; b=qSjNU1sG9zCFu26eOMJxTS16w7rv7W4dE0vrl8GG1UKHSK8kt1Xe72S02z46XbXQTe 5UOJvbO9OtVXisfI+hzQ+PUXcDIVoOilF8eT0U+ZoRcCbFNJlUrmT9c05K/uyL0SZLP2 U+kUSoWFp/VeOvKOy93mWzhk9BNSaszMz7ojU/r0wsmN2b9TF6VaI5kyswfE8X/xdWuD VcbqATViwpKhZDNp1eE2Cczu4E86N3iD+buKjTIhbEgZ60jawWxA68/dY7cj8Vf1wLej 1CDPGx+MATgt3zuahvDgUWUBfGcXYExCywHSRjbcr8R2RIXeUNRd5koqa5NrSKfx3iaJ luQg== MIME-Version: 1.0 X-Received: by 10.180.8.42 with SMTP id o10mr694443wia.0.1376001461223; Thu, 08 Aug 2013 15:37:41 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.116.136 with HTTP; Thu, 8 Aug 2013 15:37:40 -0700 (PDT) In-Reply-To: <1375997961.1451.3.camel@localhost> References: <20130808201018.1215f733@munin.geoinf.fu-berlin.de> <1375997961.1451.3.camel@localhost> Date: Thu, 8 Aug 2013 15:37:40 -0700 X-Google-Sender-Auth: IaDLbjvcTP6XYfGxhjwgnbH9NZk Message-ID: Subject: Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present From: Adrian Chadd To: sbruno@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD CURRENT , "O. Hartmann" 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: Thu, 08 Aug 2013 22:37:43 -0000 Woo! Tell Jeff! File a PR! Set everything on fire! -adrian On 8 August 2013 14:39, Sean Bruno wrote: > On Thu, 2013-08-08 at 11:30 -0700, Adrian Chadd wrote: >> Can you go over some previous versions in -HEAD and see when it was introduced? >> >> >> >> -adrian >> >> On 8 August 2013 11:10, O. Hartmann wrote: >> > The most recent CURRENT doesn't work with the x11/nvidia-driver (which >> > is at 319.25 in the ports and 325.15 from nVidia). >> > >> > After build- and installworld AND successfully rebuilding port >> > x11/nvidia-driver, the system crashes immediately after a reboot as >> > soon the kernel module nvidia.ko seems to get loaded (in my case, I >> > load nvidia.ko via /etc/rc.conf.local since the nVidia BLOB doesn't >> > load cleanly everytime when loaded from /boot/loader.conf). >> > >> > The crash occurs on systems with default compilation options set while >> > building world and with settings like -O3 -march=native. It doesn't >> > matter. >> > >> > FreeBSD and the port x11/nvidia-driver has been compiled with CLANG. >> > >> > Most recent FreeBSD revision still crashing is r254097. >> > >> > When vmcore is saved, I always see something like >> > >> > savecore: reboot after panic: vm_radix_insert: key 23c078 is already >> > present >> > >> > >> > Does anyone has any idea what's going on? >> > >> > Thanks for helping in advance, >> > >> > Oliver > > I'm seeing a complete deadlock on my T520 with today's current and > latest portsnap'd versions of ports for the nvidia-driver updates. > > A little bisection and help from others seems to point the finger at > Jeff's r254025 > > I'm getting a complete deadlock on X starting, but loading the module > seems to have no ill effects. > > Sean From owner-freebsd-current@FreeBSD.ORG Fri Aug 9 00:18:05 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 042A5523; Fri, 9 Aug 2013 00:18:05 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3B0922D8E; Fri, 9 Aug 2013 00:18:04 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id f14so1156256wiw.9 for ; Thu, 08 Aug 2013 17:18:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ryT471CEcueqAct/PHx4mW01uzOKrrCQHiEFTpaBDS4=; b=HDjHBg6Q/yR76LCIZibAKP+dua5gRdpz229xpPRlYsXNPhX4rzeOumvgg8KEaN/Kb3 7xlNxCFbcejThOrflmubwj6DTfFcr/faEfWuojzZRH5oGE3Iu8gS2I7TrwIxMpv5MwbY Z6FpDY4K0IhgHE8Cd447Gvx4GWcKhZaiNPYCPD4zT9zz4UhqGAUwRgFPh4iljjgKaej7 JFaDJDprSl9Z4URfJ5L3F8Tl0dmpS88qbOm/HWnqs4q4OhDrmEoJb/lWPdqrqs6GSaog nBu5dtF1revVZCWW5aRT3OdXfdHa0KS9JrC8Qg9vVONSssK943I2GWhH5ysgwNRx3hL6 CoMg== MIME-Version: 1.0 X-Received: by 10.180.20.116 with SMTP id m20mr725711wie.46.1376007482502; Thu, 08 Aug 2013 17:18:02 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.116.136 with HTTP; Thu, 8 Aug 2013 17:18:02 -0700 (PDT) In-Reply-To: <3BFB5B13-78C5-47E0-81B8-29A03A0136DF@yahoo.com> References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> <3BFB5B13-78C5-47E0-81B8-29A03A0136DF@yahoo.com> Date: Thu, 8 Aug 2013 17:18:02 -0700 X-Google-Sender-Auth: qiNC1bW8Lrz-_F72T2yYp9CMzzQ Message-ID: Subject: Re: [net] protecting interfaces from races between control and data ? From: Adrian Chadd To: Scott Long Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org, Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri , Luigi Rizzo , Warner Losh 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: Fri, 09 Aug 2013 00:18:05 -0000 .. and it's not just about "saturate the port" with traffic. It's also about "what happens if I shut down the MAC whilst I'm in the process of programming in new RX/TX descriptors?" The ath(4) driver had a spectacular behaviour where if you mess things up the wrong way it will quite happily DMA crap all over the memory of your running system, leading to quite hilarious bugs. -adrian From owner-freebsd-current@FreeBSD.ORG Fri Aug 9 00:27:06 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 10D11802 for ; Fri, 9 Aug 2013 00:27:06 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm30-vm6.bullet.mail.gq1.yahoo.com (nm30-vm6.bullet.mail.gq1.yahoo.com [98.136.216.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BDF2C2E39 for ; Fri, 9 Aug 2013 00:27:05 +0000 (UTC) Received: from [98.137.12.61] by nm30.bullet.mail.gq1.yahoo.com with NNFMP; 09 Aug 2013 00:20:14 -0000 Received: from [98.136.164.73] by tm6.bullet.mail.gq1.yahoo.com with NNFMP; 09 Aug 2013 00:20:14 -0000 Received: from [127.0.0.1] by smtp235.mail.gq1.yahoo.com with NNFMP; 09 Aug 2013 00:20:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1376007614; bh=zHiSK3cA2cIM0tWIXhDDYOiqAkerWT5Y2BByeVW57Rw=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=5r/hxZTQmPPt9qsgOAKNzTTkRiepNR/zNKY70/0olVC7ZK4zeVZvVJ5IJUILxpscbXR7oU2PmMUEtVfLPO16EC+lc34VjMO3rOq8I/3kehYNF4stUU95etrhfgbw9zzZL9Ec2y7CI7zPAM7JDVDRhsAjny6RjECK/5gtuy7XRbY= X-Yahoo-Newman-Id: 99189.72728.bm@smtp235.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: JAxQ.LcVM1m_YU5BLf2rywnEtJMnNWaYwjT6PEB5QfhPM.D PA.pSf56VX0g_vdYk8flQpJuVVAKPVQcGoBnWMSDAUvWLGUAtrdnkt_ld95N lraeWfUvS7hs_hr5nHw3mdWGiAp.KaDlhwwznEdoR5hcDIpCzCG1mdYQdxjt 2ybae_Vky.NxoXF.7zm50bLTe2NcLi_wdQX_aSxYqMwj8PFpJsk8RfG97Ev0 1ZVo0NWjPg.22G0O6eesLwBCPBbdMzxxge0pQ5UK6zKciL64khfMM5hN9duu wJJylcGNEpSk37sZOksMxE_oWp.4P1SZFgz7cTTJmUdZGpsmLSc0hg17jg42 sdN8QOeiMqxnuVMUBvmzW_qn_URWK_RNZCkVJ9bkTDscYgkSQu0DJmLnxkDS cA_ANpy.fKK3Vg9R7rdMqqyKlbGsO55yrLcqZKkdCeldAIAsf5teNFEpcB8U UT4HTOXB3YaQQvjHeK9vIr4fhG5BekY8qcye3PIqoGvzzRGGe5jlTeHq1doH Uno_Ncd1IHv_Rv7Y9sUWUUisiLMbm1m9OGJzZOV4Kczo03ql8H8gWTdxv X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- X-Rocket-Received: from phobos.corp.netflix.com (scott4long@69.53.237.66 with ) by smtp235.mail.gq1.yahoo.com with SMTP; 09 Aug 2013 00:20:13 +0000 UTC Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: [net] protecting interfaces from races between control and data ? From: Scott Long In-Reply-To: Date: Thu, 8 Aug 2013 17:20:13 -0700 Content-Transfer-Encoding: 7bit Message-Id: <0068D32B-C900-47EB-8E82-C50506AB1F6D@yahoo.com> References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> <3BFB5B13-78C5-47E0-81B8-29A03A0136DF@yahoo.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Fri, 09 Aug 2013 00:53:36 +0000 Cc: current@freebsd.org, Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri , Luigi Rizzo , Warner Losh 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: Fri, 09 Aug 2013 00:27:06 -0000 Yup, it's an incredibly unsafe pattern. It also leads to the pattern where auxiliary processing is handed off to a taskqueue, which then interleaves the lock ownership with the ithread and produces out-of-order packet reception. Scott On Aug 8, 2013, at 5:18 PM, Adrian Chadd wrote: > .. and it's not just about "saturate the port" with traffic. > > It's also about "what happens if I shut down the MAC whilst I'm in the > process of programming in new RX/TX descriptors?" > > The ath(4) driver had a spectacular behaviour where if you mess things > up the wrong way it will quite happily DMA crap all over the memory of > your running system, leading to quite hilarious bugs. > > > > -adrian From owner-freebsd-current@FreeBSD.ORG Fri Aug 9 05:24:27 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id ED848E4E; Fri, 9 Aug 2013 05:24:26 +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]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A99222DD1; Fri, 9 Aug 2013 05:24:26 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) with esmtp (envelope-from ) id <1V7fBY-0007wN-Mb>; Fri, 09 Aug 2013 07:24:24 +0200 Received: from g229117132.adsl.alicedsl.de ([92.229.117.132] helo=munin.geoinf.fu-berlin.de) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) with esmtpsa (envelope-from ) id <1V7fBY-003BPF-Hw>; Fri, 09 Aug 2013 07:24:24 +0200 Date: Fri, 9 Aug 2013 07:28:16 +0200 From: "O. Hartmann" To: Adrian Chadd Subject: Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present Message-ID: <20130809072816.08828aa2@munin.geoinf.fu-berlin.de> In-Reply-To: References: <20130808201018.1215f733@munin.geoinf.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd9.2) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/X6VJvt_8TaWNiuQ/2iicGgD"; protocol="application/pgp-signature" X-Originating-IP: 92.229.117.132 Cc: FreeBSD CURRENT 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: Fri, 09 Aug 2013 05:24:27 -0000 --Sig_/X6VJvt_8TaWNiuQ/2iicGgD Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 8 Aug 2013 11:30:23 -0700 Adrian Chadd wrote: > Can you go over some previous versions in -HEAD and see when it was > introduced? Not that easy. I tried simply rebuilding the kernel with older sources, but then the compiler fails compiling the nvidia port. I think I have to keep kernel and world in sync. But compiling them both takes 2 hours on my older box, I haven't access to the faster i7 system until monday. >=20 >=20 >=20 > -adrian >=20 > On 8 August 2013 11:10, O. Hartmann > wrote: > > The most recent CURRENT doesn't work with the x11/nvidia-driver > > (which is at 319.25 in the ports and 325.15 from nVidia). > > > > After build- and installworld AND successfully rebuilding port > > x11/nvidia-driver, the system crashes immediately after a reboot as > > soon the kernel module nvidia.ko seems to get loaded (in my case, I > > load nvidia.ko via /etc/rc.conf.local since the nVidia BLOB doesn't > > load cleanly everytime when loaded from /boot/loader.conf). > > > > The crash occurs on systems with default compilation options set > > while building world and with settings like -O3 -march=3Dnative. It > > doesn't matter. > > > > FreeBSD and the port x11/nvidia-driver has been compiled with CLANG. > > > > Most recent FreeBSD revision still crashing is r254097. > > > > When vmcore is saved, I always see something like > > > > savecore: reboot after panic: vm_radix_insert: key 23c078 is already > > present > > > > > > Does anyone has any idea what's going on? > > > > Thanks for helping in advance, > > > > Oliver --Sig_/X6VJvt_8TaWNiuQ/2iicGgD Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBAgAGBQJSBH32AAoJEOgBcD7A/5N8iWIIAJOLqHn7zkiM/+sPxbii3qCF 6f//Ni2bcdAE0NEJ4xEcBpLT/NNw++OJ23CO4vTzlyjQcY/50cS1iIrQLsN1wQ0K ewFr0sqiReDNhC5uXiJhDlz1VhxM4jWQFYEuHtt9jUN8ceNisTaDsS+PfaisBASC mz3RS1S4m+QJlWvIzVJQHbnQlaDzAAXg859NYBI4+2bpL49xSM5bfzcVCMtaEP3A qYcaIcbkagmgOWwADomW5Q9g4nOMYX7d3xdwx12r54mkCxU8+JNFqFgn7dBAvcVj PJnmW4XtG8mEv21fEmVm4AYwcT4/3nnrfEgnYRAA4gMbgiIUGJ1l/h6hPPTlltA= =Onlw -----END PGP SIGNATURE----- --Sig_/X6VJvt_8TaWNiuQ/2iicGgD-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 9 05:28:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E82631DB; Fri, 9 Aug 2013 05:28:55 +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]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A37202E02; Fri, 9 Aug 2013 05:28:55 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) with esmtp (envelope-from ) id <1V7fFu-0009BC-6T>; Fri, 09 Aug 2013 07:28:54 +0200 Received: from g229117132.adsl.alicedsl.de ([92.229.117.132] helo=munin.geoinf.fu-berlin.de) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) with esmtpsa (envelope-from ) id <1V7fFu-003Bbv-1i>; Fri, 09 Aug 2013 07:28:54 +0200 Date: Fri, 9 Aug 2013 07:32:51 +0200 From: "O. Hartmann" To: sbruno@freebsd.org Subject: Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present Message-ID: <20130809073251.376c9206@munin.geoinf.fu-berlin.de> In-Reply-To: <1375997961.1451.3.camel@localhost> References: <20130808201018.1215f733@munin.geoinf.fu-berlin.de> <1375997961.1451.3.camel@localhost> Organization: FU Berlin X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd9.2) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/U+MU8EjEWES0WcpPo2vAGRr"; protocol="application/pgp-signature" X-Originating-IP: 92.229.117.132 Cc: sean_bruno@yahoo.com, Adrian Chadd , FreeBSD CURRENT 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: Fri, 09 Aug 2013 05:28:56 -0000 --Sig_/U+MU8EjEWES0WcpPo2vAGRr Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 08 Aug 2013 14:39:21 -0700 Sean Bruno wrote: > On Thu, 2013-08-08 at 11:30 -0700, Adrian Chadd wrote: > > Can you go over some previous versions in -HEAD and see when it was > > introduced? > >=20 > >=20 > >=20 > > -adrian > >=20 > > On 8 August 2013 11:10, O. Hartmann > > wrote: > > > The most recent CURRENT doesn't work with the x11/nvidia-driver > > > (which is at 319.25 in the ports and 325.15 from nVidia). > > > > > > After build- and installworld AND successfully rebuilding port > > > x11/nvidia-driver, the system crashes immediately after a reboot > > > as soon the kernel module nvidia.ko seems to get loaded (in my > > > case, I load nvidia.ko via /etc/rc.conf.local since the nVidia > > > BLOB doesn't load cleanly everytime when loaded > > > from /boot/loader.conf). > > > > > > The crash occurs on systems with default compilation options set > > > while building world and with settings like -O3 -march=3Dnative. It > > > doesn't matter. > > > > > > FreeBSD and the port x11/nvidia-driver has been compiled with > > > CLANG. > > > > > > Most recent FreeBSD revision still crashing is r254097. > > > > > > When vmcore is saved, I always see something like > > > > > > savecore: reboot after panic: vm_radix_insert: key 23c078 is > > > already present > > > > > > > > > Does anyone has any idea what's going on? > > > > > > Thanks for helping in advance, > > > > > > Oliver >=20 > I'm seeing a complete deadlock on my T520 with today's current and > latest portsnap'd versions of ports for the nvidia-driver updates. >=20 > A little bisection and help from others seems to point the finger at > Jeff's r254025 >=20 > I'm getting a complete deadlock on X starting, but loading the module > seems to have no ill effects. >=20 > Sean Rigth, I loaded the module also via /boot/loader.conf and it loads cleanly. I start xdm and then the deadlock occurs. I tried recompiling the whole xorg suite via "portmaster -f xorg xdm", it took a while, but no effect, still dying. Oliver --Sig_/U+MU8EjEWES0WcpPo2vAGRr Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBAgAGBQJSBH8DAAoJEOgBcD7A/5N8RhYH/As5jnit6GHoqxWZxVkkv6SC VDV6d5MJMikkPTHClrN4/lmAQL1pblr0jbC+OPRb6n+Raa6fNjKUBSP/7ni/wN3o 1WjUANGObQUuBSSniKic71H984TwbS/qN58ZwocgxOXCSVirhA93qr8AAaQG7dPB 3uuCRTV1oYVxUk4b+BjDruJHLPGekazuveHGMtXMeKvKwZ82cl7ZgsLDwwDFFUES 5hrSiOJ5O0z0b9t0O5GnayXghWmgBOYv2jjcOEqqliOZnhlwHlItyecFcMblniqy S8eVmS1oOSLOGwrkOYYKH7g8sn+1vnGcV/KV4pxdKhxL0lx4XLs5Zqxkd12dq4Q= =qo60 -----END PGP SIGNATURE----- --Sig_/U+MU8EjEWES0WcpPo2vAGRr-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 9 07:17:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4F84F951 for ; Fri, 9 Aug 2013 07:17:35 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: from nm1-vm8.bt.bullet.mail.ir2.yahoo.com (nm1-vm8.bt.bullet.mail.ir2.yahoo.com [212.82.99.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 59D0922F3 for ; Fri, 9 Aug 2013 07:17:33 +0000 (UTC) Received: from [212.82.98.46] by nm1.bt.bullet.mail.ir2.yahoo.com with NNFMP; 09 Aug 2013 07:10:30 -0000 Received: from [46.228.39.181] by tm7.bt.bullet.mail.ir2.yahoo.com with NNFMP; 09 Aug 2013 07:10:30 -0000 Received: from [127.0.0.1] by smtp122.bt.mail.ir2.yahoo.com with NNFMP; 09 Aug 2013 07:10:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=s1024; t=1376032230; bh=18qLUT994jcZZ4RMjUiZ+NOU0QVsnRfTRXqa9ke9TPg=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language; b=noVzgDD+2Y/w7BzxU+5RcvnalpGkhgcS98oi3NqXKLfQKh1T1d2OLXbXfwCdHfNOjyOu2ITdcWuo48I3IM5lYndZRnMUIWJHbVL1Yy0H2zqW4K4WHEQfUHlhtjcaYRluxbxiQJd4DQbsOpza+tEzLjru9DgvaiZ1N0w/J5AOEvo= X-Yahoo-Newman-Id: 406434.42888.bm@smtp122.bt.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: gN8jgAEVM1mDOtloTkyp7NeJfA4vv2vjh70jVCpsiNFHbKW q1SnwitEu5wJZfDj21lx1U09W3HaN59mztk3xq.L7gDEkWLfpdqtyfhILUp_ 8GdttLxeIGLus1BbdfwAgysgRh9DPHl.9ZxfMOCX5oBc_6QHMooGWK3_Jans 4B3aQPgTzyPToJxqKmUhuMe5eD3SHL4mg3SWVNMXb7i5JG_gtjYV0qggzvPB .FZIwNO7y7.bk5pU55AZp.PbV0D22DMFXpkOmGsGewuPdDkNL3Y0Iq2P9CqY XLJrGsmoMkB10DnjPnF1cUjTatVMJmAkTJ5J0Z7M_wKOwaqOz3fTopxO_H8o lOaMUAfQdbKt9UrDh.TbJm9R.8qoNsgO_nYtHLt_VsA66bFNHbyXa9jUvw0d 1LrB2PtMcuth7trEScKNRM5KrsEne.2rAYQp3foBfrgbIHQOeWjuTMQig2dw rPK1B8CS3KpVPVwB5Uqk2nYF5ZQNjLgVbIPtFkNtb6qboJx9dO2LU1IlyuK6 ._pxl42KVOEGdnKgmfNeOVJuvtZ8zGTrS4IeFn9Ub6fPQa7OXUJE- X-Yahoo-SMTP: IZRlAYqswBDptUXTX.cYc1l2h3YNYE0xlrpi4wWl.OMHg4FYv7uDnfZx6kQf X-Rocket-Received: from ThomasPC (Thomas.Sparrevohn@86.158.107.17 with login) by smtp122.bt.mail.ir2.yahoo.com with SMTP; 09 Aug 2013 07:10:30 +0000 UTC From: "Thomas Sparrevohn" To: "'O. Hartmann'" , References: <20130808201018.1215f733@munin.geoinf.fu-berlin.de> <1375997961.1451.3.camel@localhost> <20130809073251.376c9206@munin.geoinf.fu-berlin.de> In-Reply-To: <20130809073251.376c9206@munin.geoinf.fu-berlin.de> Subject: RE: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present Date: Fri, 9 Aug 2013 08:10:30 +0100 Message-ID: <016c01ce94cf$886eb1a0$994c14e0$@btinternet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHBE77wJ3qZY3ZyXsKSg61yiSspyAL8PV+IAqscJO8Bjic89ZltyzJQ Content-Language: en-gb Cc: sean_bruno@yahoo.com, 'Adrian Chadd' , 'FreeBSD CURRENT' 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: Fri, 09 Aug 2013 07:17:35 -0000 I saw this problem with the update to latest NVidia-driver yesterday with the previous version I don't think there is a problem -----Original Message----- From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd-current@freebsd.org] On Behalf Of O. Hartmann Sent: 09 August 2013 06:33 To: sbruno@freebsd.org Cc: sean_bruno@yahoo.com; Adrian Chadd; FreeBSD CURRENT Subject: Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present On Thu, 08 Aug 2013 14:39:21 -0700 Sean Bruno wrote: > On Thu, 2013-08-08 at 11:30 -0700, Adrian Chadd wrote: > > Can you go over some previous versions in -HEAD and see when it was > > introduced? > > > > > > > > -adrian > > > > On 8 August 2013 11:10, O. Hartmann > > wrote: > > > The most recent CURRENT doesn't work with the x11/nvidia-driver > > > (which is at 319.25 in the ports and 325.15 from nVidia). > > > > > > After build- and installworld AND successfully rebuilding port > > > x11/nvidia-driver, the system crashes immediately after a reboot > > > as soon the kernel module nvidia.ko seems to get loaded (in my > > > case, I load nvidia.ko via /etc/rc.conf.local since the nVidia > > > BLOB doesn't load cleanly everytime when loaded from > > > /boot/loader.conf). > > > > > > The crash occurs on systems with default compilation options set > > > while building world and with settings like -O3 -march=native. It > > > doesn't matter. > > > > > > FreeBSD and the port x11/nvidia-driver has been compiled with > > > CLANG. > > > > > > Most recent FreeBSD revision still crashing is r254097. > > > > > > When vmcore is saved, I always see something like > > > > > > savecore: reboot after panic: vm_radix_insert: key 23c078 is > > > already present > > > > > > > > > Does anyone has any idea what's going on? > > > > > > Thanks for helping in advance, > > > > > > Oliver > > I'm seeing a complete deadlock on my T520 with today's current and > latest portsnap'd versions of ports for the nvidia-driver updates. > > A little bisection and help from others seems to point the finger at > Jeff's r254025 > > I'm getting a complete deadlock on X starting, but loading the module > seems to have no ill effects. > > Sean Rigth, I loaded the module also via /boot/loader.conf and it loads cleanly. I start xdm and then the deadlock occurs. I tried recompiling the whole xorg suite via "portmaster -f xorg xdm", it took a while, but no effect, still dying. Oliver From owner-freebsd-current@FreeBSD.ORG Fri Aug 9 08:37:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 24094574; Fri, 9 Aug 2013 08:37:53 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 607AD27AB; Fri, 9 Aug 2013 08:37:52 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id l18so1301295wgh.2 for ; Fri, 09 Aug 2013 01:37:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Erh3vT9OUFZW8ZxYGaGbY/UVN6XGCM6xwIMbUi7wqrc=; b=RbmjeLizlT6F9N1GuOMaAc/GB4TMCF+Vw2Bpvw81yG1LJ7eDwNIEdg5ckJDRV4tG9Z sRIucKw4d8PRXFFn5Kvt3B9xA+qIgyYLR9zDwfI14Xw9NGNIrGgcoZjBA1ONw+/wp9Jg UfcSkSX1FBoQnmcJkSRbhJv/ShunbTqGRHjuDBmzUVHlAzcuQGBiVtCey/Yn7+7EB7d7 uW7roA7L4U1MoFqfjm7rM5iYyQ2TAQmNJEHXAh2kSmjljuarH7+mk6OGspD2PfFWi0OD y0itLJ5yM2Puo6/3FqrO5E6mXaQlr6r9wayod1l7dQweVsmU/qU+TRTyJdiOAPNpQqLZ svaQ== MIME-Version: 1.0 X-Received: by 10.180.160.165 with SMTP id xl5mr1456662wib.46.1376037470653; Fri, 09 Aug 2013 01:37:50 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.116.136 with HTTP; Fri, 9 Aug 2013 01:37:50 -0700 (PDT) In-Reply-To: <51BBA07B.80403@gmail.com> References: <512A6FFF.2060603@gmail.com> <201302281209.45170.jhb@freebsd.org> <51394952.9030700@gmail.com> <201306141139.16728.jhb@freebsd.org> <51BBA07B.80403@gmail.com> Date: Fri, 9 Aug 2013 01:37:50 -0700 X-Google-Sender-Auth: 8yIkgXveAcabiO-bBQ6Cve3lljM Message-ID: Subject: Re: Fixing X220 Video The Right Way From: Adrian Chadd To: matt Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-acpi@freebsd.org, 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: Fri, 09 Aug 2013 08:37:53 -0000 Hi! Hm, resurrecting this thread, I'll try this on my X230 tomorrow and see if it makes the (non-xorg, console only) video work on resume. If it does, what will it take to automatically determine that this kind of work-around is needed? Thanks! -adrian On 14 June 2013 16:00, matt wrote: > On 06/14/13 08:39, John Baldwin wrote: > >> I got this to work by using 4 backslashes. At that point the patch >> worked. (I recently got access to an X220.) I get a local APIC >> error each time I adjust the brightness though (probably the BIOS >> is doing something wonky). >> > > > That's awesome! I've asked -CURRENT about the > > I tried single quotes, double quotes, double backslash, and I meant to > try ascii escapes next :) > > I'm glad you got this working, it makes the X220 (and probably other > laptops with similar issues) more usable on FreeBSD. > > I'll have to bring my X220 back up to current and start looking at > sleep issues next. > > Matt From owner-freebsd-current@FreeBSD.ORG Fri Aug 9 16:17:54 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AD33BF98 for ; Fri, 9 Aug 2013 16:17:54 +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]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6B8A02154 for ; Fri, 9 Aug 2013 16:17:54 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1V7pNw-000Gng-Gv>; Fri, 09 Aug 2013 18:17:52 +0200 Received: from f052020002.adsl.alicedsl.de ([78.52.20.2] helo=munin.geoinf.fu-berlin.de) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1V7pNw-003vrJ-Df>; Fri, 09 Aug 2013 18:17:52 +0200 Date: Fri, 9 Aug 2013 18:21:44 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: r254147: kernel build failure: vm_page.c:1206:20: error: use of undeclared identifier 'VPO_BUSY' Message-ID: <20130809182144.5ce79f4d@munin.geoinf.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd9.2) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/qHlL00_dl90ulzNI4hiFN7V"; protocol="application/pgp-signature" X-Originating-IP: 78.52.20.2 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: Fri, 09 Aug 2013 16:17:54 -0000 --Sig_/qHlL00_dl90ulzNI4hiFN7V Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Most recent sources fails in kernel build: [...] cc -c -pipe -O3 -fno-strict-aliasing -march=3Dnative -std=3Dc99 -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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror /usr/src/sys/vm/vm_page.c /usr/src/sys/vm/vm_page.c:1205:21: error: use of undeclared identifier 'VPO_BUSY' if (mold->oflags & VPO_BUSY) { ^ /usr/src/sys/vm/vm_page.c:1206:20: error: use of undeclared identifier 'VPO_BUSY' mold->oflags &=3D ~VPO_BUSY; ^ 2 errors generated. *** Error code 1 Regards, Oliver --Sig_/qHlL00_dl90ulzNI4hiFN7V Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBAgAGBQJSBRcdAAoJEOgBcD7A/5N8TqQH/RVfUPkqA9t97MUlgG6P30Q4 76IuIUTD+9EZLW3fTqXAo+n9ysqkju5sC9xVaWSCQt5kGng8Na9RnrFp0zSsQdOp BQpwxQ9lghSwP7yYOGKFwhQu2IEza8CZsHnsp88PCA7UQgwGzG58J2p3CgKmfsKw jqri5BahY3YIhAfx1VYgP4MCmHTkuoZWeWQNMtaRKnRXCpio9uWpdOeHthRM/sbz /xFXolkBuMSgZ2Vj2XM7e6+9n8Xfh3RXEO2sXOBwpeAE7ymFCKPW7ahIBO1K9dSH T4xUKxKGY9Vh7h9wH77cDyS9e/IuLxbWqWyU8648EMOc3itnUIGLOofopdsBu60= =ifH3 -----END PGP SIGNATURE----- --Sig_/qHlL00_dl90ulzNI4hiFN7V-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 9 16:37:02 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 73C0995F; Fri, 9 Aug 2013 16:37:02 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4C1BE22C9; Fri, 9 Aug 2013 16:37:02 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4315FB958; Fri, 9 Aug 2013 12:37:01 -0400 (EDT) From: John Baldwin To: Adrian Chadd Subject: Re: Fixing X220 Video The Right Way Date: Fri, 9 Aug 2013 11:57:19 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: <512A6FFF.2060603@gmail.com> <51BBA07B.80403@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201308091157.19765.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 09 Aug 2013 12:37:01 -0400 (EDT) Cc: matt , freebsd-acpi@freebsd.org, 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: Fri, 09 Aug 2013 16:37:02 -0000 On Friday, August 09, 2013 4:37:50 am Adrian Chadd wrote: > Hi! > > Hm, resurrecting this thread, I'll try this on my X230 tomorrow and > see if it makes the (non-xorg, console only) video work on resume. > > If it does, what will it take to automatically determine that this > kind of work-around is needed? This does not affect suspend/resume. It only fixes LCD brightness handling via acpi_video(4). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Aug 9 17:12:39 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D9C5936E for ; Fri, 9 Aug 2013 17:12:39 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8557D24BF for ; Fri, 9 Aug 2013 17:12:38 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.7/8.14.7) with ESMTP id r79HCbgi047082 for ; Fri, 9 Aug 2013 10:12:37 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.7/8.14.7/Submit) id r79HCbV6047081 for freebsd-current@freebsd.org; Fri, 9 Aug 2013 10:12:37 -0700 (PDT) (envelope-from david) Date: Fri, 9 Aug 2013 10:12:37 -0700 From: David Wolfskill To: FreeBSD CURRENT Subject: Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present Message-ID: <20130809171237.GN1746@albert.catwhisker.org> References: <20130808201018.1215f733@munin.geoinf.fu-berlin.de> <1375997961.1451.3.camel@localhost> <20130809073251.376c9206@munin.geoinf.fu-berlin.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YqkpBxMMfeZoT90/" Content-Disposition: inline In-Reply-To: <20130809073251.376c9206@munin.geoinf.fu-berlin.de> User-Agent: Mutt/1.5.21 (2010-09-15) 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: Fri, 09 Aug 2013 17:12:39 -0000 --YqkpBxMMfeZoT90/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 09, 2013 at 07:32:51AM +0200, O. Hartmann wrote: > ... > > > On 8 August 2013 11:10, O. Hartmann > > > wrote: > > > > The most recent CURRENT doesn't work with the x11/nvidia-driver > > > > (which is at 319.25 in the ports and 325.15 from nVidia). > > > > > > > > After build- and installworld AND successfully rebuilding port > > > > x11/nvidia-driver, the system crashes immediately after a reboot > > > > as soon the kernel module nvidia.ko seems to get loaded (in my > > > > case, I load nvidia.ko via /etc/rc.conf.local since the nVidia > > > > BLOB doesn't load cleanly everytime when loaded > > > > from /boot/loader.conf). > > > > > > > > The crash occurs on systems with default compilation options set > > > > while building world and with settings like -O3 -march=3Dnative. It > > > > doesn't matter. > > > > > > > > FreeBSD and the port x11/nvidia-driver has been compiled with > > > > CLANG. > > > > > > > > Most recent FreeBSD revision still crashing is r254097. > > > > > > > > When vmcore is saved, I always see something like > > > > > > > > savecore: reboot after panic: vm_radix_insert: key 23c078 is > > > > already present > > > > > > > > > > > > Does anyone has any idea what's going on? > > > > > > > > Thanks for helping in advance, > > > > > > > > Oliver > >=20 > > I'm seeing a complete deadlock on my T520 with today's current and > > latest portsnap'd versions of ports for the nvidia-driver updates. > >=20 > > A little bisection and help from others seems to point the finger at > > Jeff's r254025 > >=20 > > I'm getting a complete deadlock on X starting, but loading the module > > seems to have no ill effects. > >=20 > > Sean >=20 > Rigth, I loaded the module also via /boot/loader.conf and it loads > cleanly. I start xdm and then the deadlock occurs. >=20 > I tried recompiling the whole xorg suite via "portmaster -f xorg xdm", > it took a while, but no effect, still dying. > ..... Sorry to be rather late to the party; the Internet connection I'm using at the moment is a bit flaky. (I'm out of town.) I managed to get head/i386 @r254135 built and booting ... by removing the "options DEBUG_MEMGUARD" from my kernel. However, that merely prevented a (very!) early panic, and got me to the point where trying to start xdm with the x11/nvidia-driver as the display driver causes an immediate reboot (no crash dump, despite 'dumpdev=3D"AUTO"' in /etc/rc.conf). No drop to debugger, either. Booting & starting xdm with the nv driver works -- that's my present environment as I am typing this. However, the panic with DEBUG_MEMGUARD may offer a clue. Unfortunately, it's early enough that screen lock/scrolling doesn't work, and I only had the patience to write down partof the panic information. (This is on my laptop; no serial console, AFAICT -- and no device to capture the output if I did, since I'm not at home.) The top line of the screen (at the panic) reads: s/kern/subr_vmem.c:1050 The backtrace has the expected stuff near the top (about kbd, panic, and memguard stuff); just below that is: vmem_alloc(c1226100,6681000,2,c1820cc0,3b5,...) at 0xc0ac5673=3Dvmem_alloc+= 0x53/frame 0xc1820ca0 Caveat: that was hand-transcribed from the screen to papaer, then hand-transcribed from paper to this email message. And my highest grade in "Penmanship" was a D+. Be that as it may, here's the relevant section of subr_vmem.c with line numbers (cut/pasted, so tabs get munged): 1039 /* 1040 * vmem_alloc: allocate resource from the arena. 1041 */ 1042 int 1043 vmem_alloc(vmem_t *vm, vmem_size_t size, int flags, vmem_addr_t *ad= drp) 1044 { 1045 const int strat __unused =3D flags & VMEM_FITMASK; 1046 qcache_t *qc; 1047=20 1048 flags &=3D VMEM_FLAGS; 1049 MPASS(size > 0); 1050 MPASS(strat =3D=3D M_BESTFIT || strat =3D=3D M_FIRSTFIT); 1051 if ((flags & M_NOWAIT) =3D=3D 0) 1052 WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL, "vm= em_alloc"); 1053 1054 if (size <=3D vm->vm_qcache_max) { 1055 qc =3D &vm->vm_qcache[(size - 1) >> vm->vm_quantum_= shift]; 1056 *addrp =3D (vmem_addr_t)uma_zalloc(qc->qc_cache, fl= ags); 1057 if (*addrp =3D=3D 0) 1058 return (ENOMEM); 1059 return (0); 1060 } 1061 1062 return vmem_xalloc(vm, size, 0, 0, 0, VMEM_ADDR_MIN, VMEM_A= DDR_MAX, 1063 flags, addrp); 1064 } This is at r254025. 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. --YqkpBxMMfeZoT90/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlIFIwQACgkQmprOCmdXAD3MEQCfdjuWfilBjWJU8Rg1HszySQEz GWIAoIOqKm1d2Y/lwQtl6q/ZDStyYlwr =DTLV -----END PGP SIGNATURE----- --YqkpBxMMfeZoT90/-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 9 17:27:49 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0100D9B7; Fri, 9 Aug 2013 17:27:48 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D460D258D; Fri, 9 Aug 2013 17:27:48 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id r79HRlHP022818; Fri, 9 Aug 2013 10:27:47 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id r79HRlk2022817; Fri, 9 Aug 2013 10:27:47 -0700 (PDT) (envelope-from sgk) Date: Fri, 9 Aug 2013 10:27:47 -0700 From: Steve Kargl To: Baptiste Daroussin Subject: Re: Port problems after r253839 on HEAD Message-ID: <20130809172747.GA9649@troutmask.apl.washington.edu> References: <520283C9.8030806@gwdg.de> <20130807174333.GK40254@ithaqua.etoilebsd.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130807174333.GK40254@ithaqua.etoilebsd.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 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: Fri, 09 Aug 2013 17:27:49 -0000 On Wed, Aug 07, 2013 at 07:43:33PM +0200, Baptiste Daroussin wrote: > On Wed, Aug 07, 2013 at 07:28:41PM +0200, Rainer Hurling wrote: > > After introducing r253839 on HEAD (/head/contrib/binutils/ld/ldmain.c), > > I recognized some wired behaviour in the ports system on my CURRENT boxes. > > > > Some of the ports do not build anymore. They print almost similar > > messages about an ld problem (invalid DSO for symbol 'xxx' definition), > > followed by the lib, which symbols are not found. > > > > With a recent 10.0-CURRENT (at least r253839) you can try this for > > example with the following two ports: > > > normally I had tracked down all those ports, except if you are building them > with nom default options, > > What that means is basically the said ports are missing some -lbla in ldflags, > > The missing ones are those listed in the line following the DSO bla > in nano for example the first failure means -liconv is missing. > > I afk until 24th so I can't commit any fix to the said ports. > There were properly building in my exp-run for the said change, meaning either > you build with non default options im that case the port requires a fix or > perhaps your ports tree is not uptodate, in particular lots of those failures > are fixed by the recent glib update. On a freshly rebuilt freebsd-current where I've deleted all ports to do a fresh build of everything I use, I see % portmaster news/pan ... CXXLD pan /usr/bin/ld: ,: invalid DSO for symbol `libiconv_open' definition /usr/local/lib/libiconv.so.3: could not read symbols: Bad value c++: error: linker command failed with exit code 1 (use -v to see invocation) gmake[5]: *** [pan] Error 1 gmake[5]: Leaving directory `/usr/ports/news/pan/work/pan-0.139/pan/gui' gmake[4]: *** [all-recursive] Error 1 gmake[4]: Leaving directory `/usr/ports/news/pan/work/pan-0.139/pan' Please, fix. -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Aug 9 18:59:33 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9CBC7167; Fri, 9 Aug 2013 18:59:33 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D37CF2AB3; Fri, 9 Aug 2013 18:59:32 +0000 (UTC) Received: from p5dc3eee5.dip0.t-ipconnect.de ([93.195.238.229] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1V7ruE-0004jo-Nb; Fri, 09 Aug 2013 20:59:23 +0200 Message-ID: <52053C06.30706@gwdg.de> Date: Fri, 09 Aug 2013 20:59:18 +0200 From: Rainer Hurling User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130808 Thunderbird/17.0.8 MIME-Version: 1.0 To: Steve Kargl Subject: Re: Port problems after r253839 on HEAD References: <520283C9.8030806@gwdg.de> <20130807174333.GK40254@ithaqua.etoilebsd.net> <20130809172747.GA9649@troutmask.apl.washington.edu> In-Reply-To: <20130809172747.GA9649@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: Baptiste Daroussin , 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: Fri, 09 Aug 2013 18:59:33 -0000 Am 09.08.2013 19:27 UTC+2, schrieb Steve Kargl: > On Wed, Aug 07, 2013 at 07:43:33PM +0200, Baptiste Daroussin wrote: >> On Wed, Aug 07, 2013 at 07:28:41PM +0200, Rainer Hurling wrote: >>> After introducing r253839 on HEAD (/head/contrib/binutils/ld/ldmain.c), >>> I recognized some wired behaviour in the ports system on my CURRENT boxes. >>> >>> Some of the ports do not build anymore. They print almost similar >>> messages about an ld problem (invalid DSO for symbol 'xxx' definition), >>> followed by the lib, which symbols are not found. >>> >>> With a recent 10.0-CURRENT (at least r253839) you can try this for >>> example with the following two ports: >>> >> normally I had tracked down all those ports, except if you are building them >> with nom default options, >> >> What that means is basically the said ports are missing some -lbla in ldflags, >> >> The missing ones are those listed in the line following the DSO bla >> in nano for example the first failure means -liconv is missing. >> >> I afk until 24th so I can't commit any fix to the said ports. >> There were properly building in my exp-run for the said change, meaning either >> you build with non default options im that case the port requires a fix or >> perhaps your ports tree is not uptodate, in particular lots of those failures >> are fixed by the recent glib update. > > > On a freshly rebuilt freebsd-current where I've deleted all ports > to do a fresh build of everything I use, I see > > % portmaster news/pan > ... > CXXLD pan > /usr/bin/ld: ,: invalid DSO for symbol `libiconv_open' definition > /usr/local/lib/libiconv.so.3: could not read symbols: Bad value > c++: error: linker command failed with exit code 1 (use -v to see invocation) > gmake[5]: *** [pan] Error 1 > gmake[5]: Leaving directory `/usr/ports/news/pan/work/pan-0.139/pan/gui' > gmake[4]: *** [all-recursive] Error 1 > gmake[4]: Leaving directory `/usr/ports/news/pan/work/pan-0.139/pan' > > Please, fix. > If I understand bapt@ right, this should be all what is needed: --- Makefile.orig 2013-06-20 17:48:12.000000000 +0200 +++ Makefile 2013-08-09 20:56:36.000000000 +0200 @@ -15,7 +15,8 @@ LICENSE= GPLv2 LIB_DEPENDS= pcre:${PORTSDIR}/devel/pcre \ - gmime-2.6:${PORTSDIR}/mail/gmime26 + gmime-2.6:${PORTSDIR}/mail/gmime26 \ + iconv:${PORTSDIR}/converters/libiconv USE_BZIP2= yes USE_GMAKE= yes @@ -23,7 +24,7 @@ USE_GNOME= intlhack GNU_CONFIGURE= yes CPPFLAGS+= -I${LOCALBASE}/include -LDFLAGS+= -L${LOCALBASE}/lib -lgnuregex +LDFLAGS+= -L${LOCALBASE}/lib -lgnuregex -liconv OPTIONS_DEFINE= GTKSPELL GTK3 OPTIONS_DEFAULT=GTKSPELL HTH, Rainer From owner-freebsd-current@FreeBSD.ORG Fri Aug 9 19:06:49 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B13BB5D2; Fri, 9 Aug 2013 19:06:49 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 90CEA2B47; Fri, 9 Aug 2013 19:06:49 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id r79J6mRm017447; Fri, 9 Aug 2013 12:06:48 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id r79J6mMZ017446; Fri, 9 Aug 2013 12:06:48 -0700 (PDT) (envelope-from sgk) Date: Fri, 9 Aug 2013 12:06:48 -0700 From: Steve Kargl To: Rainer Hurling Subject: Re: Port problems after r253839 on HEAD Message-ID: <20130809190648.GA15013@troutmask.apl.washington.edu> References: <520283C9.8030806@gwdg.de> <20130807174333.GK40254@ithaqua.etoilebsd.net> <20130809172747.GA9649@troutmask.apl.washington.edu> <52053C06.30706@gwdg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52053C06.30706@gwdg.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Baptiste Daroussin , 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: Fri, 09 Aug 2013 19:06:49 -0000 On Fri, Aug 09, 2013 at 08:59:18PM +0200, Rainer Hurling wrote: > > If I understand bapt@ right, this should be all what is needed: > > --- Makefile.orig 2013-06-20 17:48:12.000000000 +0200 > +++ Makefile 2013-08-09 20:56:36.000000000 +0200 > @@ -15,7 +15,8 @@ > LICENSE= GPLv2 > > LIB_DEPENDS= pcre:${PORTSDIR}/devel/pcre \ > - gmime-2.6:${PORTSDIR}/mail/gmime26 > + gmime-2.6:${PORTSDIR}/mail/gmime26 \ > + iconv:${PORTSDIR}/converters/libiconv I did not add this to my fix as libiconv had previously been installed. But, I suspect it is needed. > -LDFLAGS+= -L${LOCALBASE}/lib -lgnuregex > +LDFLAGS+= -L${LOCALBASE}/lib -lgnuregex -liconv This fixed the build issue. -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Aug 9 19:24:20 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5529EF9B; Fri, 9 Aug 2013 19:24:20 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 183CD2C74; Fri, 9 Aug 2013 19:24:16 +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 r79JO8Bf085944; Fri, 9 Aug 2013 15:24:08 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r79JO8k2085939; Fri, 9 Aug 2013 19:24:08 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 9 Aug 2013 19:24:08 GMT Message-Id: <201308091924.r79JO8k2085939@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 armv6/arm 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: Fri, 09 Aug 2013 19:24:20 -0000 TB --- 2013-08-09 16:20:21 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-09 16:20:21 - 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 --- 2013-08-09 16:20:21 - starting HEAD tinderbox run for armv6/arm TB --- 2013-08-09 16:20:21 - cleaning the object tree TB --- 2013-08-09 16:20:21 - /usr/local/bin/svn stat /src TB --- 2013-08-09 16:20:26 - At svn revision 254147 TB --- 2013-08-09 16:20:27 - building world TB --- 2013-08-09 16:20:27 - CROSS_BUILD_TESTING=YES TB --- 2013-08-09 16:20:27 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-09 16:20:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-09 16:20:27 - SRCCONF=/dev/null TB --- 2013-08-09 16:20:27 - TARGET=arm TB --- 2013-08-09 16:20:27 - TARGET_ARCH=armv6 TB --- 2013-08-09 16:20:27 - TZ=UTC TB --- 2013-08-09 16:20:27 - __MAKE_CONF=/dev/null TB --- 2013-08-09 16:20:27 - cd /src TB --- 2013-08-09 16:20:27 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Aug 9 16:20:34 UTC 2013 >>> 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 Fri Aug 9 19:21:45 UTC 2013 TB --- 2013-08-09 19:21:45 - generating LINT kernel config TB --- 2013-08-09 19:21:45 - cd /src/sys/arm/conf TB --- 2013-08-09 19:21:45 - /usr/bin/make -B LINT TB --- 2013-08-09 19:21:45 - cd /src/sys/arm/conf TB --- 2013-08-09 19:21:45 - /usr/sbin/config -m LINT TB --- 2013-08-09 19:21:45 - skipping LINT kernel TB --- 2013-08-09 19:21:45 - cd /src/sys/arm/conf TB --- 2013-08-09 19:21:45 - /usr/sbin/config -m AC100 TB --- 2013-08-09 19:21:45 - building AC100 kernel TB --- 2013-08-09 19:21:45 - CROSS_BUILD_TESTING=YES TB --- 2013-08-09 19:21:45 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-09 19:21:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-09 19:21:45 - SRCCONF=/dev/null TB --- 2013-08-09 19:21:45 - TARGET=arm TB --- 2013-08-09 19:21:45 - TARGET_ARCH=armv6 TB --- 2013-08-09 19:21:45 - TZ=UTC TB --- 2013-08-09 19:21:45 - __MAKE_CONF=/dev/null TB --- 2013-08-09 19:21:45 - cd /src TB --- 2013-08-09 19:21:45 - /usr/bin/make -B buildkernel KERNCONF=AC100 >>> Kernel build for AC100 started on Fri Aug 9 19:21:45 UTC 2013 >>> 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 >>> stage 3.2: building everything [...] cc -c -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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/vm/vm_page.c /src/sys/vm/vm_page.c:1205:21: error: use of undeclared identifier 'VPO_BUSY' if (mold->oflags & VPO_BUSY) { ^ /src/sys/vm/vm_page.c:1206:20: error: use of undeclared identifier 'VPO_BUSY' mold->oflags &= ~VPO_BUSY; ^ 2 errors generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.armv6/src/sys/AC100 *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-09 19:24:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-09 19:24:08 - ERROR: failed to build AC100 kernel TB --- 2013-08-09 19:24:08 - 8898.34 user 1536.70 system 11026.77 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-armv6-arm.full From owner-freebsd-current@FreeBSD.ORG Fri Aug 9 19:34:22 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 948945F0; Fri, 9 Aug 2013 19:34:22 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5B8FA2D30; Fri, 9 Aug 2013 19:34:22 +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 r79JYL2L042114; Fri, 9 Aug 2013 15:34:21 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r79JYLI8042112; Fri, 9 Aug 2013 19:34:21 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 9 Aug 2013 19:34:21 GMT Message-Id: <201308091934.r79JYLI8042112@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 arm/arm 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: Fri, 09 Aug 2013 19:34:22 -0000 TB --- 2013-08-09 16:20:21 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-09 16:20:21 - 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 --- 2013-08-09 16:20:21 - starting HEAD tinderbox run for arm/arm TB --- 2013-08-09 16:20:21 - cleaning the object tree TB --- 2013-08-09 16:20:21 - /usr/local/bin/svn stat /src TB --- 2013-08-09 16:20:26 - At svn revision 254147 TB --- 2013-08-09 16:20:27 - building world TB --- 2013-08-09 16:20:27 - CROSS_BUILD_TESTING=YES TB --- 2013-08-09 16:20:27 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-09 16:20:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-09 16:20:27 - SRCCONF=/dev/null TB --- 2013-08-09 16:20:27 - TARGET=arm TB --- 2013-08-09 16:20:27 - TARGET_ARCH=arm TB --- 2013-08-09 16:20:27 - TZ=UTC TB --- 2013-08-09 16:20:27 - __MAKE_CONF=/dev/null TB --- 2013-08-09 16:20:27 - cd /src TB --- 2013-08-09 16:20:27 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Aug 9 16:20:34 UTC 2013 >>> 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 Fri Aug 9 19:19:42 UTC 2013 TB --- 2013-08-09 19:19:42 - generating LINT kernel config TB --- 2013-08-09 19:19:42 - cd /src/sys/arm/conf TB --- 2013-08-09 19:19:42 - /usr/bin/make -B LINT TB --- 2013-08-09 19:19:42 - cd /src/sys/arm/conf TB --- 2013-08-09 19:19:42 - /usr/sbin/config -m LINT TB --- 2013-08-09 19:19:42 - building LINT kernel TB --- 2013-08-09 19:19:42 - CROSS_BUILD_TESTING=YES TB --- 2013-08-09 19:19:42 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-09 19:19:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-09 19:19:42 - SRCCONF=/dev/null TB --- 2013-08-09 19:19:42 - TARGET=arm TB --- 2013-08-09 19:19:42 - TARGET_ARCH=arm TB --- 2013-08-09 19:19:42 - TZ=UTC TB --- 2013-08-09 19:19:42 - __MAKE_CONF=/dev/null TB --- 2013-08-09 19:19:42 - cd /src TB --- 2013-08-09 19:19:42 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Aug 9 19:19:42 UTC 2013 >>> 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 >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/vm/vm_page.c /src/sys/vm/vm_page.c:1205:21: error: use of undeclared identifier 'VPO_BUSY' if (mold->oflags & VPO_BUSY) { ^ /src/sys/vm/vm_page.c:1206:20: error: use of undeclared identifier 'VPO_BUSY' mold->oflags &= ~VPO_BUSY; ^ 2 errors generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-09 19:34:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-09 19:34:21 - ERROR: failed to build LINT kernel TB --- 2013-08-09 19:34:21 - 9310.36 user 1639.12 system 11639.62 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Fri Aug 9 19:50:33 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3F3ACD49; Fri, 9 Aug 2013 19:50:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 04DCC2E2E; Fri, 9 Aug 2013 19:50:32 +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 r79JoVUM022949; Fri, 9 Aug 2013 15:50:31 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r79JoVc2022944; Fri, 9 Aug 2013 19:50:31 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 9 Aug 2013 19:50:31 GMT Message-Id: <201308091950.r79JoVc2022944@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 i386/i386 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: Fri, 09 Aug 2013 19:50:33 -0000 TB --- 2013-08-09 16:20:21 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-09 16:20:21 - 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 --- 2013-08-09 16:20:21 - starting HEAD tinderbox run for i386/i386 TB --- 2013-08-09 16:20:21 - cleaning the object tree TB --- 2013-08-09 16:20:21 - /usr/local/bin/svn stat /src TB --- 2013-08-09 16:20:26 - At svn revision 254147 TB --- 2013-08-09 16:20:27 - building world TB --- 2013-08-09 16:20:27 - CROSS_BUILD_TESTING=YES TB --- 2013-08-09 16:20:27 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-09 16:20:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-09 16:20:27 - SRCCONF=/dev/null TB --- 2013-08-09 16:20:27 - TARGET=i386 TB --- 2013-08-09 16:20:27 - TARGET_ARCH=i386 TB --- 2013-08-09 16:20:27 - TZ=UTC TB --- 2013-08-09 16:20:27 - __MAKE_CONF=/dev/null TB --- 2013-08-09 16:20:27 - cd /src TB --- 2013-08-09 16:20:27 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Aug 9 16:20:34 UTC 2013 >>> 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 Fri Aug 9 19:32:08 UTC 2013 TB --- 2013-08-09 19:32:08 - generating LINT kernel config TB --- 2013-08-09 19:32:08 - cd /src/sys/i386/conf TB --- 2013-08-09 19:32:08 - /usr/bin/make -B LINT TB --- 2013-08-09 19:32:08 - cd /src/sys/i386/conf TB --- 2013-08-09 19:32:08 - /usr/sbin/config -m LINT TB --- 2013-08-09 19:32:08 - building LINT kernel TB --- 2013-08-09 19:32:08 - CROSS_BUILD_TESTING=YES TB --- 2013-08-09 19:32:08 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-09 19:32:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-09 19:32:08 - SRCCONF=/dev/null TB --- 2013-08-09 19:32:08 - TARGET=i386 TB --- 2013-08-09 19:32:08 - TARGET_ARCH=i386 TB --- 2013-08-09 19:32:08 - TZ=UTC TB --- 2013-08-09 19:32:08 - __MAKE_CONF=/dev/null TB --- 2013-08-09 19:32:08 - cd /src TB --- 2013-08-09 19:32:08 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Aug 9 19:32:08 UTC 2013 >>> 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 >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg /src/sys/vm/vm_page.c /src/sys/vm/vm_page.c:1205:21: error: use of undeclared identifier 'VPO_BUSY' if (mold->oflags & VPO_BUSY) { ^ /src/sys/vm/vm_page.c:1206:20: error: use of undeclared identifier 'VPO_BUSY' mold->oflags &= ~VPO_BUSY; ^ 2 errors generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/i386.i386/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-09 19:50:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-09 19:50:31 - ERROR: failed to build LINT kernel TB --- 2013-08-09 19:50:31 - 10226.02 user 1740.88 system 12609.96 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Fri Aug 9 20:03:35 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C3FF934D for ; Fri, 9 Aug 2013 20:03:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 609372EF1 for ; Fri, 9 Aug 2013 20:03:35 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5E860B95B for ; Fri, 9 Aug 2013 16:03:34 -0400 (EDT) From: John Baldwin To: current@freebsd.org Subject: HEAD in dubious state after 254141 Date: Fri, 9 Aug 2013 16:03:33 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_VsUBSGAELqL+1H/" Message-Id: <201308091603.33445.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 09 Aug 2013 16:03:34 -0400 (EDT) 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: Fri, 09 Aug 2013 20:03:35 -0000 --Boundary-00=_VsUBSGAELqL+1H/ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'm in the process of reverting 254150 and 254141. I think the changes in 254141 were from an old tree that wasn't updated for the changes in 254138 and I don't seen an obvious way to fix 254141, so until Attilio can redo 254141 I'm going to revert these. -- John Baldwin --Boundary-00=_VsUBSGAELqL+1H/ Content-Type: message/rfc822; name="forwarded message" Content-Transfer-Encoding: 7bit Content-Description: John Baldwin : Re: svn commit: r254150 - head/sys/vm Content-Disposition: inline Return-Path: Received: from bigwig.baldwin.cx ([unix socket]) by bigwig.baldwin.cx (Cyrus v2.3.16) with LMTPA; Fri, 09 Aug 2013 15:58:35 -0400 X-Sieve: CMU Sieve 2.3 Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) by bigwig.baldwin.cx (Postfix) with ESMTP id 40651B978 for ; Fri, 9 Aug 2013 15:58:34 -0400 (EDT) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.freebsd.org (Postfix) with ESMTPS id 9BE157BFF for ; Fri, 9 Aug 2013 19:58:33 +0000 (UTC) Received: by hub.freebsd.org (Postfix) id 7D524E0; Fri, 9 Aug 2013 19:58:33 +0000 (UTC) Delivered-To: jhb@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 538) id 5DDA06D; Fri, 9 Aug 2013 19:58:33 +0000 (UTC) Delivered-To: src-committers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C59B16B; Fri, 9 Aug 2013 19:58:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9ADEB2E88; Fri, 9 Aug 2013 19:58:27 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 62210B939; Fri, 9 Aug 2013 15:58:26 -0400 (EDT) From: John Baldwin To: "David E. O'Brien" Subject: Re: svn commit: r254150 - head/sys/vm Date: Fri, 9 Aug 2013 15:56:47 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org References: <201308091643.r79GhoWx023884@svn.freebsd.org> In-Reply-To: <201308091643.r79GhoWx023884@svn.freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201308091556.47535.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 09 Aug 2013 15:58:26 -0400 (EDT) Sender: owner-src-committers@FreeBSD.org Precedence: bulk X-Loop: FreeBSD.ORG X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 09 Aug 2013 15:58:34 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.97.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on bigwig.baldwin.cx X-Length: 3938 X-UID: 69454 On Friday, August 09, 2013 12:43:50 pm David E. O'Brien wrote: > Author: obrien > Date: Fri Aug 9 16:43:50 2013 > New Revision: 254150 > URL: http://svnweb.freebsd.org/changeset/base/254150 > > Log: > Add missing 'VPO_BUSY' from r254141 to fix kernel build break. > > Modified: > head/sys/vm/vm_page.h This can't possibly be correct as r254138 just removed this flag. If it isn't obvious how to fix the uses added back in r254141, then r254141 should be reverted instead. Hmm, looking at the relevant bits of r254141, it doesn't look obvious: + /* Detach the old page from the resident tailq. */ + TAILQ_REMOVE(&object->memq, mold, listq); + vm_page_lock(mold); + if (mold->oflags & VPO_BUSY) { + mold->oflags &= ~VPO_BUSY; + vm_page_flash(mold); + } Since nothing is setting this flag, this can't possibly work correctly currently. I wouldn't boot a top-of-tree kernel right now. :( -- John Baldwin --Boundary-00=_VsUBSGAELqL+1H/-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 9 20:24:32 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5C827821; Fri, 9 Aug 2013 20:24:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2427F3000; Fri, 9 Aug 2013 20:24:31 +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 r79KOUFW017289; Fri, 9 Aug 2013 16:24:30 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r79KOUeF017285; Fri, 9 Aug 2013 20:24:30 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 9 Aug 2013 20:24:30 GMT Message-Id: <201308092024.r79KOUeF017285@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 amd64/amd64 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: Fri, 09 Aug 2013 20:24:32 -0000 TB --- 2013-08-09 16:20:21 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-09 16:20:21 - 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 --- 2013-08-09 16:20:21 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-08-09 16:20:21 - cleaning the object tree TB --- 2013-08-09 16:20:21 - /usr/local/bin/svn stat /src TB --- 2013-08-09 16:20:26 - At svn revision 254147 TB --- 2013-08-09 16:20:27 - building world TB --- 2013-08-09 16:20:27 - CROSS_BUILD_TESTING=YES TB --- 2013-08-09 16:20:27 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-09 16:20:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-09 16:20:27 - SRCCONF=/dev/null TB --- 2013-08-09 16:20:27 - TARGET=amd64 TB --- 2013-08-09 16:20:27 - TARGET_ARCH=amd64 TB --- 2013-08-09 16:20:27 - TZ=UTC TB --- 2013-08-09 16:20:27 - __MAKE_CONF=/dev/null TB --- 2013-08-09 16:20:27 - cd /src TB --- 2013-08-09 16:20:27 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Aug 9 16:20:34 UTC 2013 >>> 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Fri Aug 9 20:07:06 UTC 2013 TB --- 2013-08-09 20:07:06 - generating LINT kernel config TB --- 2013-08-09 20:07:06 - cd /src/sys/amd64/conf TB --- 2013-08-09 20:07:06 - /usr/bin/make -B LINT TB --- 2013-08-09 20:07:06 - cd /src/sys/amd64/conf TB --- 2013-08-09 20:07:06 - /usr/sbin/config -m LINT TB --- 2013-08-09 20:07:06 - building LINT kernel TB --- 2013-08-09 20:07:06 - CROSS_BUILD_TESTING=YES TB --- 2013-08-09 20:07:06 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-09 20:07:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-09 20:07:06 - SRCCONF=/dev/null TB --- 2013-08-09 20:07:06 - TARGET=amd64 TB --- 2013-08-09 20:07:06 - TARGET_ARCH=amd64 TB --- 2013-08-09 20:07:06 - TZ=UTC TB --- 2013-08-09 20:07:06 - __MAKE_CONF=/dev/null TB --- 2013-08-09 20:07:06 - cd /src TB --- 2013-08-09 20:07:06 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Aug 9 20:07:06 UTC 2013 >>> 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 >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg /src/sys/vm/vm_page.c /src/sys/vm/vm_page.c:1205:21: error: use of undeclared identifier 'VPO_BUSY' if (mold->oflags & VPO_BUSY) { ^ /src/sys/vm/vm_page.c:1206:20: error: use of undeclared identifier 'VPO_BUSY' mold->oflags &= ~VPO_BUSY; ^ 2 errors generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/amd64.amd64/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-09 20:24:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-09 20:24:30 - ERROR: failed to build LINT kernel TB --- 2013-08-09 20:24:30 - 11661.92 user 2108.29 system 14648.91 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Fri Aug 9 20:26:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BE861984 for ; Fri, 9 Aug 2013 20:26:07 +0000 (UTC) (envelope-from dt71@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3E4F22041 for ; Fri, 9 Aug 2013 20:26:07 +0000 (UTC) Received: from [192.168.1.80] ([84.1.168.225]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Lugbo-1W7adD497g-00zlRq for ; Fri, 09 Aug 2013 22:26:00 +0200 Message-ID: <5205500F.3070100@gmx.com> Date: Fri, 09 Aug 2013 22:24:47 +0200 From: dt71@gmx.com User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:22.0) Gecko/20100101 Firefox/22.0 SeaMonkey/2.19 MIME-Version: 1.0 To: Glen Barber Subject: Re: svn error during 'make buildkernel'? References: <20130803210348.GA715@troutmask.apl.washington.edu> <20130803210858.GJ78299@glenbarber.us> <20130803213023.GA812@troutmask.apl.washington.edu> <20130803214313.GL78299@glenbarber.us> In-Reply-To: <20130803214313.GL78299@glenbarber.us> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:VnuSIYynXReJMujvgNH5sK9JxzD3SrYFlgFzErB/FV748tHDA6Y sfRHbjUAnPttjqmy4Kz9gE0HGB8TTKmHAYRC38r+W3LOmQ4t+PO8krh7Rh4Sa79drpSbLC+ LHxLx4S4dboGV0eoVkdQCFjg6ncaqbqfysr+XH2EIeEWyCYgsXFPNGvL15Ej6+kDIVv4oOG eFkQMm4efLFl0imOzRqUQ== 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: Fri, 09 Aug 2013 20:26:07 -0000 On 08/03/2013 23:43, Glen Barber wrote: > BTW, you should upgrade devel/subversion anyway, since there are > security vulnerabilities. BTW, you should remove GA, since it is a security vulnerability itself. From owner-freebsd-current@FreeBSD.ORG Fri Aug 9 20:31:42 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 40C0AB59; Fri, 9 Aug 2013 20:31:42 +0000 (UTC) (envelope-from hps@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id F100920AB; Fri, 9 Aug 2013 20:31:41 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta.bitpro.no (Postfix) with ESMTP id 060B77A37B; Fri, 9 Aug 2013 22:31:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 249998F2B8C; Fri, 9 Aug 2013 22:31:49 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpUcSOozNBD2; Fri, 9 Aug 2013 22:31:48 +0200 (CEST) Received: from laptop015.hselasky.homeunix.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) by mail.lockless.no (Postfix) with ESMTPSA id 9E7BC8F2B8B; Fri, 9 Aug 2013 22:31:48 +0200 (CEST) Message-ID: <52055201.7040506@bitfrost.no> Date: Fri, 09 Aug 2013 22:33:05 +0200 From: Hans Petter Selasky Organization: Bitfrost A/S User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130522 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-usb@FreeBSD.org, freebsd-current@freebsd.org Subject: FYI: Advanced USB compliance testing tool now in the tree (10-current only) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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: Fri, 09 Aug 2013 20:31:42 -0000 Hi, For those of you that want to make sure your USB mass storage device behaves correctly when using FreeBSD, typically for critical applications, I've just added an advanced USB testing tool to the FreeBSD source tree. It can be used to stress your USB mass storage device in ways that are beyond what "bonnie" will do. See tools/tools/usbtest or the following commit: http://svnweb.freebsd.org/changeset/base/254159 --HPS From owner-freebsd-current@FreeBSD.ORG Fri Aug 9 20:53:54 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 506719D0; Fri, 9 Aug 2013 20:53:54 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 16B532204; Fri, 9 Aug 2013 20:53:53 +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 r79Krr7C081748; Fri, 9 Aug 2013 16:53:53 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r79KrrbF081744; Fri, 9 Aug 2013 20:53:53 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 9 Aug 2013 20:53:53 GMT Message-Id: <201308092053.r79KrrbF081744@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 mips/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: Fri, 09 Aug 2013 20:53:54 -0000 TB --- 2013-08-09 19:50:32 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-09 19:50:32 - 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 --- 2013-08-09 19:50:32 - starting HEAD tinderbox run for mips/mips TB --- 2013-08-09 19:50:32 - cleaning the object tree TB --- 2013-08-09 19:50:32 - /usr/local/bin/svn stat /src TB --- 2013-08-09 19:50:35 - At svn revision 254147 TB --- 2013-08-09 19:50:36 - building world TB --- 2013-08-09 19:50:36 - CROSS_BUILD_TESTING=YES TB --- 2013-08-09 19:50:36 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-09 19:50:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-09 19:50:36 - SRCCONF=/dev/null TB --- 2013-08-09 19:50:36 - TARGET=mips TB --- 2013-08-09 19:50:36 - TARGET_ARCH=mips TB --- 2013-08-09 19:50:36 - TZ=UTC TB --- 2013-08-09 19:50:36 - __MAKE_CONF=/dev/null TB --- 2013-08-09 19:50:36 - cd /src TB --- 2013-08-09 19:50:36 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Aug 9 19:50:44 UTC 2013 >>> 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 Fri Aug 9 20:50:57 UTC 2013 TB --- 2013-08-09 20:50:57 - cd /src/sys/mips/conf TB --- 2013-08-09 20:50:57 - /usr/sbin/config -m ADM5120 TB --- 2013-08-09 20:50:57 - skipping ADM5120 kernel TB --- 2013-08-09 20:50:57 - cd /src/sys/mips/conf TB --- 2013-08-09 20:50:57 - /usr/sbin/config -m ALCHEMY TB --- 2013-08-09 20:50:57 - skipping ALCHEMY kernel TB --- 2013-08-09 20:50:57 - cd /src/sys/mips/conf TB --- 2013-08-09 20:50:57 - /usr/sbin/config -m AP121 TB --- 2013-08-09 20:50:57 - building AP121 kernel TB --- 2013-08-09 20:50:57 - CROSS_BUILD_TESTING=YES TB --- 2013-08-09 20:50:57 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-09 20:50:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-09 20:50:57 - SRCCONF=/dev/null TB --- 2013-08-09 20:50:57 - TARGET=mips TB --- 2013-08-09 20:50:57 - TARGET_ARCH=mips TB --- 2013-08-09 20:50:57 - TZ=UTC TB --- 2013-08-09 20:50:57 - __MAKE_CONF=/dev/null TB --- 2013-08-09 20:50:57 - cd /src TB --- 2013-08-09 20:50:57 - /usr/bin/make -B buildkernel KERNCONF=AP121 >>> Kernel build for AP121 started on Fri Aug 9 20:50:57 UTC 2013 >>> 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 >>> stage 3.2: building everything [...] cc -c -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/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=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/vm/vm_meter.c cc -c -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/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=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/vm/vm_mmap.c cc -c -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/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=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/vm/vm_object.c cc -c -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/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=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/vm/vm_page.c /src/sys/vm/vm_page.c: In function 'vm_page_replace': /src/sys/vm/vm_page.c:1205: error: 'VPO_BUSY' undeclared (first use in this function) /src/sys/vm/vm_page.c:1205: error: (Each undeclared identifier is reported only once /src/sys/vm/vm_page.c:1205: error: for each function it appears in.) *** Error code 1 Stop. bmake[1]: stopped in /obj/mips.mips/src/sys/AP121 *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-09 20:53:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-09 20:53:52 - ERROR: failed to build AP121 kernel TB --- 2013-08-09 20:53:52 - 2761.44 user 673.98 system 3800.88 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Fri Aug 9 21:27:17 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3360FB08; Fri, 9 Aug 2013 21:27:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EDCDC23E1; Fri, 9 Aug 2013 21:27:13 +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 r79LRCUf061561; Fri, 9 Aug 2013 17:27:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r79LRCYT061557; Fri, 9 Aug 2013 21:27:12 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 9 Aug 2013 21:27:12 GMT Message-Id: <201308092127.r79LRCYT061557@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: Fri, 09 Aug 2013 21:27:17 -0000 TB --- 2013-08-09 20:24:30 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-09 20:24:30 - 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 --- 2013-08-09 20:24:30 - starting HEAD tinderbox run for mips64/mips TB --- 2013-08-09 20:24:30 - cleaning the object tree TB --- 2013-08-09 20:24:30 - /usr/local/bin/svn stat /src TB --- 2013-08-09 20:24:34 - At svn revision 254147 TB --- 2013-08-09 20:24:35 - building world TB --- 2013-08-09 20:24:35 - CROSS_BUILD_TESTING=YES TB --- 2013-08-09 20:24:35 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-09 20:24:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-09 20:24:35 - SRCCONF=/dev/null TB --- 2013-08-09 20:24:35 - TARGET=mips TB --- 2013-08-09 20:24:35 - TARGET_ARCH=mips64 TB --- 2013-08-09 20:24:35 - TZ=UTC TB --- 2013-08-09 20:24:35 - __MAKE_CONF=/dev/null TB --- 2013-08-09 20:24:35 - cd /src TB --- 2013-08-09 20:24:35 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Aug 9 20:24:42 UTC 2013 >>> 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 Fri Aug 9 21:24:58 UTC 2013 TB --- 2013-08-09 21:24:58 - cd /src/sys/mips/conf TB --- 2013-08-09 21:24:58 - /usr/sbin/config -m ADM5120 TB --- 2013-08-09 21:24:58 - skipping ADM5120 kernel TB --- 2013-08-09 21:24:58 - cd /src/sys/mips/conf TB --- 2013-08-09 21:24:58 - /usr/sbin/config -m ALCHEMY TB --- 2013-08-09 21:24:58 - skipping ALCHEMY kernel TB --- 2013-08-09 21:24:58 - cd /src/sys/mips/conf TB --- 2013-08-09 21:24:58 - /usr/sbin/config -m AP121 TB --- 2013-08-09 21:24:58 - skipping AP121 kernel TB --- 2013-08-09 21:24:58 - cd /src/sys/mips/conf TB --- 2013-08-09 21:24:58 - /usr/sbin/config -m AP91 TB --- 2013-08-09 21:24:58 - skipping AP91 kernel TB --- 2013-08-09 21:24:58 - cd /src/sys/mips/conf TB --- 2013-08-09 21:24:58 - /usr/sbin/config -m AP93 TB --- 2013-08-09 21:24:58 - skipping AP93 kernel TB --- 2013-08-09 21:24:58 - cd /src/sys/mips/conf TB --- 2013-08-09 21:24:58 - /usr/sbin/config -m AP94 TB --- 2013-08-09 21:24:58 - skipping AP94 kernel TB --- 2013-08-09 21:24:58 - cd /src/sys/mips/conf TB --- 2013-08-09 21:24:58 - /usr/sbin/config -m AP96 TB --- 2013-08-09 21:24:58 - skipping AP96 kernel TB --- 2013-08-09 21:24:58 - cd /src/sys/mips/conf TB --- 2013-08-09 21:24:58 - /usr/sbin/config -m AR71XX_BASE TB --- 2013-08-09 21:24:58 - skipping AR71XX_BASE kernel TB --- 2013-08-09 21:24:58 - cd /src/sys/mips/conf TB --- 2013-08-09 21:24:58 - /usr/sbin/config -m AR724X_BASE TB --- 2013-08-09 21:24:58 - skipping AR724X_BASE kernel TB --- 2013-08-09 21:24:58 - cd /src/sys/mips/conf TB --- 2013-08-09 21:24:58 - /usr/sbin/config -m AR91XX_BASE TB --- 2013-08-09 21:24:58 - skipping AR91XX_BASE kernel TB --- 2013-08-09 21:24:58 - cd /src/sys/mips/conf TB --- 2013-08-09 21:24:58 - /usr/sbin/config -m AR933X_BASE TB --- 2013-08-09 21:24:58 - skipping AR933X_BASE kernel TB --- 2013-08-09 21:24:58 - cd /src/sys/mips/conf TB --- 2013-08-09 21:24:58 - /usr/sbin/config -m AR934X_BASE TB --- 2013-08-09 21:24:58 - skipping AR934X_BASE kernel TB --- 2013-08-09 21:24:58 - cd /src/sys/mips/conf TB --- 2013-08-09 21:24:58 - /usr/sbin/config -m BERI_DE4_MDROOT TB --- 2013-08-09 21:24:58 - building BERI_DE4_MDROOT kernel TB --- 2013-08-09 21:24:58 - CROSS_BUILD_TESTING=YES TB --- 2013-08-09 21:24:58 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-09 21:24:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-09 21:24:58 - SRCCONF=/dev/null TB --- 2013-08-09 21:24:58 - TARGET=mips TB --- 2013-08-09 21:24:58 - TARGET_ARCH=mips64 TB --- 2013-08-09 21:24:58 - TZ=UTC TB --- 2013-08-09 21:24:58 - __MAKE_CONF=/dev/null TB --- 2013-08-09 21:24:58 - cd /src TB --- 2013-08-09 21:24:58 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_MDROOT >>> Kernel build for BERI_DE4_MDROOT started on Fri Aug 9 21:24:58 UTC 2013 >>> 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 >>> stage 3.2: building everything [...] cc -c -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/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 -Werror /src/sys/vm/vm_meter.c cc -c -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/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 -Werror /src/sys/vm/vm_mmap.c cc -c -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/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 -Werror /src/sys/vm/vm_object.c cc -c -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/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 -Werror /src/sys/vm/vm_page.c /src/sys/vm/vm_page.c: In function 'vm_page_replace': /src/sys/vm/vm_page.c:1205: error: 'VPO_BUSY' undeclared (first use in this function) /src/sys/vm/vm_page.c:1205: error: (Each undeclared identifier is reported only once /src/sys/vm/vm_page.c:1205: error: for each function it appears in.) *** Error code 1 Stop. bmake[1]: stopped in /obj/mips.mips64/src/sys/BERI_DE4_MDROOT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-09 21:27:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-09 21:27:12 - ERROR: failed to build BERI_DE4_MDROOT kernel TB --- 2013-08-09 21:27:12 - 2753.55 user 635.95 system 3761.50 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips64-mips.full From owner-freebsd-current@FreeBSD.ORG Fri Aug 9 21:31:07 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id ADFFAE08; Fri, 9 Aug 2013 21:31:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7325A243A; Fri, 9 Aug 2013 21:31:07 +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 r79LV6Wu069143; Fri, 9 Aug 2013 17:31:06 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r79LV6oC069139; Fri, 9 Aug 2013 21:31:06 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 9 Aug 2013 21:31:06 GMT Message-Id: <201308092131.r79LV6oC069139@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 ia64/ia64 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: Fri, 09 Aug 2013 21:31:07 -0000 TB --- 2013-08-09 19:34:21 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-09 19:34:21 - 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 --- 2013-08-09 19:34:21 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-08-09 19:34:21 - cleaning the object tree TB --- 2013-08-09 19:34:21 - /usr/local/bin/svn stat /src TB --- 2013-08-09 19:34:25 - At svn revision 254147 TB --- 2013-08-09 19:34:26 - building world TB --- 2013-08-09 19:34:26 - CROSS_BUILD_TESTING=YES TB --- 2013-08-09 19:34:26 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-09 19:34:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-09 19:34:26 - SRCCONF=/dev/null TB --- 2013-08-09 19:34:26 - TARGET=ia64 TB --- 2013-08-09 19:34:26 - TARGET_ARCH=ia64 TB --- 2013-08-09 19:34:26 - TZ=UTC TB --- 2013-08-09 19:34:26 - __MAKE_CONF=/dev/null TB --- 2013-08-09 19:34:26 - cd /src TB --- 2013-08-09 19:34:26 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Aug 9 19:34:34 UTC 2013 >>> 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 Fri Aug 9 21:10:49 UTC 2013 TB --- 2013-08-09 21:10:49 - generating LINT kernel config TB --- 2013-08-09 21:10:49 - cd /src/sys/ia64/conf TB --- 2013-08-09 21:10:49 - /usr/bin/make -B LINT TB --- 2013-08-09 21:10:50 - cd /src/sys/ia64/conf TB --- 2013-08-09 21:10:50 - /usr/sbin/config -m LINT TB --- 2013-08-09 21:10:50 - building LINT kernel TB --- 2013-08-09 21:10:50 - CROSS_BUILD_TESTING=YES TB --- 2013-08-09 21:10:50 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-09 21:10:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-09 21:10:50 - SRCCONF=/dev/null TB --- 2013-08-09 21:10:50 - TARGET=ia64 TB --- 2013-08-09 21:10:50 - TARGET_ARCH=ia64 TB --- 2013-08-09 21:10:50 - TZ=UTC TB --- 2013-08-09 21:10:50 - __MAKE_CONF=/dev/null TB --- 2013-08-09 21:10:50 - cd /src TB --- 2013-08-09 21:10:50 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Aug 9 21:10:50 UTC 2013 >>> 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 >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/vm/vm_meter.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/vm/vm_mmap.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/vm/vm_object.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/vm/vm_page.c /src/sys/vm/vm_page.c: In function 'vm_page_replace': /src/sys/vm/vm_page.c:1205: error: 'VPO_BUSY' undeclared (first use in this function) /src/sys/vm/vm_page.c:1205: error: (Each undeclared identifier is reported only once /src/sys/vm/vm_page.c:1205: error: for each function it appears in.) *** Error code 1 Stop. bmake[1]: stopped in /obj/ia64.ia64/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-09 21:31:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-09 21:31:06 - ERROR: failed to build LINT kernel TB --- 2013-08-09 21:31:06 - 5623.41 user 964.94 system 7004.67 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Fri Aug 9 21:32:03 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 61150F3B; Fri, 9 Aug 2013 21:32:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3A779244B; Fri, 9 Aug 2013 21:32:03 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B75A1B939; Fri, 9 Aug 2013 17:31:59 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: HEAD in dubious state after 254141, update to 254163+ Date: Fri, 9 Aug 2013 17:16:05 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: <201308091603.33445.jhb@freebsd.org> In-Reply-To: <201308091603.33445.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201308091716.05948.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 09 Aug 2013 17:31:59 -0400 (EDT) Cc: 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: Fri, 09 Aug 2013 21:32:03 -0000 On Friday, August 09, 2013 4:03:33 pm John Baldwin wrote: > I'm in the process of reverting 254150 and 254141. I think the changes in > 254141 were from an old tree that wasn't updated for the changes in 254138 and > I don't seen an obvious way to fix 254141, so until Attilio can redo 254141 > I'm going to revert these. Alan submitted a fix for the 254141 and I've booted it successfully so I've commited that. However, please be sure to update to at least 254163. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Aug 9 22:56:02 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 66DAE273; Fri, 9 Aug 2013 22:56:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2C7DB27B9; Fri, 9 Aug 2013 22:56:01 +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 r79MttV6094877; Fri, 9 Aug 2013 18:55:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r79Mtt4J094874; Fri, 9 Aug 2013 22:55:55 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 9 Aug 2013 22:55:55 GMT Message-Id: <201308092255.r79Mtt4J094874@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 i386/pc98 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: Fri, 09 Aug 2013 22:56:02 -0000 TB --- 2013-08-09 19:24:09 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-09 19:24:09 - 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 --- 2013-08-09 19:24:09 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-08-09 19:24:09 - cleaning the object tree TB --- 2013-08-09 19:24:09 - /usr/local/bin/svn stat /src TB --- 2013-08-09 19:24:16 - At svn revision 254147 TB --- 2013-08-09 19:24:17 - building world TB --- 2013-08-09 19:24:17 - CROSS_BUILD_TESTING=YES TB --- 2013-08-09 19:24:17 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-09 19:24:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-09 19:24:17 - SRCCONF=/dev/null TB --- 2013-08-09 19:24:17 - TARGET=pc98 TB --- 2013-08-09 19:24:17 - TARGET_ARCH=i386 TB --- 2013-08-09 19:24:17 - TZ=UTC TB --- 2013-08-09 19:24:17 - __MAKE_CONF=/dev/null TB --- 2013-08-09 19:24:17 - cd /src TB --- 2013-08-09 19:24:17 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Aug 9 19:24:24 UTC 2013 >>> 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 Fri Aug 9 22:41:17 UTC 2013 TB --- 2013-08-09 22:41:17 - generating LINT kernel config TB --- 2013-08-09 22:41:17 - cd /src/sys/pc98/conf TB --- 2013-08-09 22:41:17 - /usr/bin/make -B LINT TB --- 2013-08-09 22:41:17 - cd /src/sys/pc98/conf TB --- 2013-08-09 22:41:17 - /usr/sbin/config -m LINT TB --- 2013-08-09 22:41:17 - building LINT kernel TB --- 2013-08-09 22:41:17 - CROSS_BUILD_TESTING=YES TB --- 2013-08-09 22:41:17 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-09 22:41:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-09 22:41:17 - SRCCONF=/dev/null TB --- 2013-08-09 22:41:17 - TARGET=pc98 TB --- 2013-08-09 22:41:17 - TARGET_ARCH=i386 TB --- 2013-08-09 22:41:17 - TZ=UTC TB --- 2013-08-09 22:41:17 - __MAKE_CONF=/dev/null TB --- 2013-08-09 22:41:17 - cd /src TB --- 2013-08-09 22:41:17 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Aug 9 22:41:17 UTC 2013 >>> 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 >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg /src/sys/vm/vm_page.c /src/sys/vm/vm_page.c:1205:21: error: use of undeclared identifier 'VPO_BUSY' if (mold->oflags & VPO_BUSY) { ^ /src/sys/vm/vm_page.c:1206:20: error: use of undeclared identifier 'VPO_BUSY' mold->oflags &= ~VPO_BUSY; ^ 2 errors generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/pc98.i386/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-09 22:55:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-09 22:55:55 - ERROR: failed to build LINT kernel TB --- 2013-08-09 22:55:55 - 10320.80 user 1492.72 system 12706.76 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Fri Aug 9 22:56:08 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6E9E5279; Fri, 9 Aug 2013 22:56:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 336A627BD; Fri, 9 Aug 2013 22:56:08 +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 r79Mu7jA095964; Fri, 9 Aug 2013 18:56:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r79Mu7Dl095962; Fri, 9 Aug 2013 22:56:07 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 9 Aug 2013 22:56:07 GMT Message-Id: <201308092256.r79Mu7Dl095962@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 sparc64/sparc64 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: Fri, 09 Aug 2013 22:56:08 -0000 TB --- 2013-08-09 21:31:06 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-09 21:31:06 - 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 --- 2013-08-09 21:31:06 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-08-09 21:31:06 - cleaning the object tree TB --- 2013-08-09 21:31:06 - /usr/local/bin/svn stat /src TB --- 2013-08-09 21:31:09 - At svn revision 254147 TB --- 2013-08-09 21:31:10 - building world TB --- 2013-08-09 21:31:10 - CROSS_BUILD_TESTING=YES TB --- 2013-08-09 21:31:10 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-09 21:31:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-09 21:31:10 - SRCCONF=/dev/null TB --- 2013-08-09 21:31:10 - TARGET=sparc64 TB --- 2013-08-09 21:31:10 - TARGET_ARCH=sparc64 TB --- 2013-08-09 21:31:10 - TZ=UTC TB --- 2013-08-09 21:31:10 - __MAKE_CONF=/dev/null TB --- 2013-08-09 21:31:10 - cd /src TB --- 2013-08-09 21:31:10 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Aug 9 21:31:17 UTC 2013 >>> 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 Fri Aug 9 22:40:53 UTC 2013 TB --- 2013-08-09 22:40:53 - generating LINT kernel config TB --- 2013-08-09 22:40:53 - cd /src/sys/sparc64/conf TB --- 2013-08-09 22:40:53 - /usr/bin/make -B LINT TB --- 2013-08-09 22:40:53 - cd /src/sys/sparc64/conf TB --- 2013-08-09 22:40:53 - /usr/sbin/config -m LINT TB --- 2013-08-09 22:40:53 - building LINT kernel TB --- 2013-08-09 22:40:53 - CROSS_BUILD_TESTING=YES TB --- 2013-08-09 22:40:53 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-09 22:40:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-09 22:40:53 - SRCCONF=/dev/null TB --- 2013-08-09 22:40:53 - TARGET=sparc64 TB --- 2013-08-09 22:40:53 - TARGET_ARCH=sparc64 TB --- 2013-08-09 22:40:53 - TZ=UTC TB --- 2013-08-09 22:40:53 - __MAKE_CONF=/dev/null TB --- 2013-08-09 22:40:53 - cd /src TB --- 2013-08-09 22:40:53 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Aug 9 22:40:53 UTC 2013 >>> 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 >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/vm/vm_meter.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/vm/vm_mmap.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/vm/vm_object.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/vm/vm_page.c /src/sys/vm/vm_page.c: In function 'vm_page_replace': /src/sys/vm/vm_page.c:1205: error: 'VPO_BUSY' undeclared (first use in this function) /src/sys/vm/vm_page.c:1205: error: (Each undeclared identifier is reported only once /src/sys/vm/vm_page.c:1205: error: for each function it appears in.) *** Error code 1 Stop. bmake[1]: stopped in /obj/sparc64.sparc64/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-09 22:56:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-09 22:56:07 - ERROR: failed to build LINT kernel TB --- 2013-08-09 22:56:07 - 3966.50 user 723.63 system 5100.75 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Fri Aug 9 23:39:50 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1A052F55; Fri, 9 Aug 2013 23:39:50 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D3CE42A03; Fri, 9 Aug 2013 23:39:49 +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 r79Ndmdw004514; Fri, 9 Aug 2013 19:39:48 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r79NdmnF004510; Fri, 9 Aug 2013 23:39:48 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 9 Aug 2013 23:39:48 GMT Message-Id: <201308092339.r79NdmnF004510@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 powerpc/powerpc 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: Fri, 09 Aug 2013 23:39:50 -0000 TB --- 2013-08-09 20:53:53 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-09 20:53:53 - 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 --- 2013-08-09 20:53:53 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-08-09 20:53:53 - cleaning the object tree TB --- 2013-08-09 20:53:53 - /usr/local/bin/svn stat /src TB --- 2013-08-09 20:53:57 - At svn revision 254147 TB --- 2013-08-09 20:53:58 - building world TB --- 2013-08-09 20:53:58 - CROSS_BUILD_TESTING=YES TB --- 2013-08-09 20:53:58 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-09 20:53:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-09 20:53:58 - SRCCONF=/dev/null TB --- 2013-08-09 20:53:58 - TARGET=powerpc TB --- 2013-08-09 20:53:58 - TARGET_ARCH=powerpc TB --- 2013-08-09 20:53:58 - TZ=UTC TB --- 2013-08-09 20:53:58 - __MAKE_CONF=/dev/null TB --- 2013-08-09 20:53:58 - cd /src TB --- 2013-08-09 20:53:58 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Aug 9 20:54:06 UTC 2013 >>> 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 Fri Aug 9 23:29:44 UTC 2013 TB --- 2013-08-09 23:29:44 - generating LINT kernel config TB --- 2013-08-09 23:29:44 - cd /src/sys/powerpc/conf TB --- 2013-08-09 23:29:44 - /usr/bin/make -B LINT TB --- 2013-08-09 23:29:44 - cd /src/sys/powerpc/conf TB --- 2013-08-09 23:29:44 - /usr/sbin/config -m LINT TB --- 2013-08-09 23:29:44 - building LINT kernel TB --- 2013-08-09 23:29:44 - CROSS_BUILD_TESTING=YES TB --- 2013-08-09 23:29:44 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-09 23:29:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-09 23:29:44 - SRCCONF=/dev/null TB --- 2013-08-09 23:29:44 - TARGET=powerpc TB --- 2013-08-09 23:29:44 - TARGET_ARCH=powerpc TB --- 2013-08-09 23:29:44 - TZ=UTC TB --- 2013-08-09 23:29:44 - __MAKE_CONF=/dev/null TB --- 2013-08-09 23:29:44 - cd /src TB --- 2013-08-09 23:29:44 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Aug 9 23:29:45 UTC 2013 >>> 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 >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/vm/vm_meter.c cc -c -O -pipe -std=c99 -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/vm/vm_mmap.c cc -c -O -pipe -std=c99 -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/vm/vm_object.c cc -c -O -pipe -std=c99 -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/vm/vm_page.c /src/sys/vm/vm_page.c: In function 'vm_page_replace': /src/sys/vm/vm_page.c:1205: error: 'VPO_BUSY' undeclared (first use in this function) /src/sys/vm/vm_page.c:1205: error: (Each undeclared identifier is reported only once /src/sys/vm/vm_page.c:1205: error: for each function it appears in.) *** Error code 1 Stop. bmake[1]: stopped in /obj/powerpc.powerpc/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-09 23:39:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-09 23:39:48 - ERROR: failed to build LINT kernel TB --- 2013-08-09 23:39:48 - 8549.71 user 1080.23 system 9955.52 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 00:36:18 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B1D44270; Sat, 10 Aug 2013 00:36:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 76F992CF0; Sat, 10 Aug 2013 00:36:18 +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 r7A0aH2f010491; Fri, 9 Aug 2013 20:36:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r7A0aHiC010490; Sat, 10 Aug 2013 00:36:17 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 10 Aug 2013 00:36:17 GMT Message-Id: <201308100036.r7A0aHiC010490@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 powerpc64/powerpc 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: Sat, 10 Aug 2013 00:36:18 -0000 TB --- 2013-08-09 21:27:12 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-09 21:27:12 - 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 --- 2013-08-09 21:27:12 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2013-08-09 21:27:13 - cleaning the object tree TB --- 2013-08-09 21:27:13 - /usr/local/bin/svn stat /src TB --- 2013-08-09 21:27:16 - At svn revision 254147 TB --- 2013-08-09 21:27:17 - building world TB --- 2013-08-09 21:27:17 - CROSS_BUILD_TESTING=YES TB --- 2013-08-09 21:27:17 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-09 21:27:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-09 21:27:17 - SRCCONF=/dev/null TB --- 2013-08-09 21:27:17 - TARGET=powerpc TB --- 2013-08-09 21:27:17 - TARGET_ARCH=powerpc64 TB --- 2013-08-09 21:27:17 - TZ=UTC TB --- 2013-08-09 21:27:17 - __MAKE_CONF=/dev/null TB --- 2013-08-09 21:27:17 - cd /src TB --- 2013-08-09 21:27:17 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Aug 9 21:27:24 UTC 2013 >>> 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Aug 10 00:30:54 UTC 2013 TB --- 2013-08-10 00:30:54 - generating LINT kernel config TB --- 2013-08-10 00:30:54 - cd /src/sys/powerpc/conf TB --- 2013-08-10 00:30:54 - /usr/bin/make -B LINT TB --- 2013-08-10 00:30:54 - cd /src/sys/powerpc/conf TB --- 2013-08-10 00:30:54 - /usr/sbin/config -m LINT TB --- 2013-08-10 00:30:54 - skipping LINT kernel TB --- 2013-08-10 00:30:54 - cd /src/sys/powerpc/conf TB --- 2013-08-10 00:30:54 - /usr/sbin/config -m GENERIC TB --- 2013-08-10 00:30:54 - skipping GENERIC kernel TB --- 2013-08-10 00:30:54 - cd /src/sys/powerpc/conf TB --- 2013-08-10 00:30:54 - /usr/sbin/config -m GENERIC64 TB --- 2013-08-10 00:30:54 - building GENERIC64 kernel TB --- 2013-08-10 00:30:54 - CROSS_BUILD_TESTING=YES TB --- 2013-08-10 00:30:54 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-10 00:30:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-10 00:30:54 - SRCCONF=/dev/null TB --- 2013-08-10 00:30:54 - TARGET=powerpc TB --- 2013-08-10 00:30:54 - TARGET_ARCH=powerpc64 TB --- 2013-08-10 00:30:54 - TZ=UTC TB --- 2013-08-10 00:30:54 - __MAKE_CONF=/dev/null TB --- 2013-08-10 00:30:54 - cd /src TB --- 2013-08-10 00:30:54 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64 >>> Kernel build for GENERIC64 started on Sat Aug 10 00:30:54 UTC 2013 >>> 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 >>> stage 3.2: building everything [...] cc -c -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/vm/vm_meter.c cc -c -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/vm/vm_mmap.c cc -c -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/vm/vm_object.c cc -c -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/vm/vm_page.c /src/sys/vm/vm_page.c: In function 'vm_page_replace': /src/sys/vm/vm_page.c:1205: error: 'VPO_BUSY' undeclared (first use in this function) /src/sys/vm/vm_page.c:1205: error: (Each undeclared identifier is reported only once /src/sys/vm/vm_page.c:1205: error: for each function it appears in.) *** Error code 1 Stop. bmake[1]: stopped in /obj/powerpc.powerpc64/src/sys/GENERIC64 *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-10 00:36:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-10 00:36:17 - ERROR: failed to build GENERIC64 kernel TB --- 2013-08-10 00:36:17 - 9902.01 user 1259.86 system 11344.23 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 03:11:19 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 993AD2FE; Sat, 10 Aug 2013 03:11:19 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5E68623BD; Sat, 10 Aug 2013 03:11:19 +0000 (UTC) Received: by mail-pd0-f181.google.com with SMTP id g10so1271785pdj.26 for ; Fri, 09 Aug 2013 20:11:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=1G2uR5Jm7t5Q076nxoI4QCniCQoDBoMYDkHK/W+T3sU=; b=c4dx4hoNkbukgRon4JJMyUbquR84HgKHraX3fhcwMpfWQ/nnN5jiD+lQQ8VMOeQ3VK QAPO4uASpjSdsNU+6e34OxAXDvjMJKss5R6mfBLlsTpJpM+Lm0ToC/+ikfR5v1XGxbQd gAQCdHtLVS13VsdutVDJu9TSwF6Xcz4jeMyObCPJg0e5Q96fyWwv2KJqk6S3Jq6KByuW yBSiPlthrAz4UCXgg6GVsjSPSBV+ugnECHcp0EGVHlJf5A0ppPDePdZ3g8tvr5lb9O+Y FWYt0W/z+k6xvtlW1j/vtRfkFa+/SeS1uiKQLmZOawbacvRl7MbFcKtSQ7caN1H4nnjp gTiQ== X-Received: by 10.66.229.106 with SMTP id sp10mr14495982pac.117.1376104278572; Fri, 09 Aug 2013 20:11:18 -0700 (PDT) Received: from flatline.sfrsys.com (c-67-161-25-189.hsd1.ca.comcast.net. [67.161.25.189]) by mx.google.com with ESMTPSA id fa5sm23159780pbb.3.2013.08.09.20.11.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 Aug 2013 20:11:17 -0700 (PDT) Message-ID: <5205AF0A.4090304@gmail.com> Date: Fri, 09 Aug 2013 20:10:02 -0700 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130806 Thunderbird/17.0.7 MIME-Version: 1.0 To: John Baldwin Subject: Re: Fixing X220 Video The Right Way References: <512A6FFF.2060603@gmail.com> <51BBA07B.80403@gmail.com> <201308091157.19765.jhb@freebsd.org> In-Reply-To: <201308091157.19765.jhb@freebsd.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , freebsd-current@freebsd.org, freebsd-acpi@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: Sat, 10 Aug 2013 03:11:19 -0000 hw.acpi.reset_video used to send this machine X220 into a reboot loop, with flashing thinklight. Interesting that it no longer causes this problem. I kind of paused since the trackpad sucks so much in X. I think since ssh still works, that just the display or graphics port is off. It may be worth trying to do some acpi_calls via ssh to try to hack the display back on... Matt On 08/09/13 08:57, John Baldwin wrote: > On Friday, August 09, 2013 4:37:50 am Adrian Chadd wrote: >> Hi! >> >> Hm, resurrecting this thread, I'll try this on my X230 tomorrow >> and see if it makes the (non-xorg, console only) video work on >> resume. >> >> If it does, what will it take to automatically determine that >> this kind of work-around is needed? > > > This does not affect suspend/resume. It only fixes LCD brightness > handling via acpi_video(4). > From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 04:04:23 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9338E7C1 for ; Sat, 10 Aug 2013 04:04:23 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 475A525B0 for ; Sat, 10 Aug 2013 04:04:22 +0000 (UTC) Received: from [127.0.0.1] (Scott4long@pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id r7A3umI3028753 for ; Fri, 9 Aug 2013 21:56:48 -0600 (MDT) (envelope-from scottl@samsco.org) From: Scott Long Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: CFT: PCI Command Register fixups Message-Id: <5E12B1A6-5B39-46FE-B8C7-239D23AEEE5E@samsco.org> Date: Fri, 9 Aug 2013 21:56:48 -0600 To: "current@freebsd.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) 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: Sat, 10 Aug 2013 04:04:23 -0000 All, Subversion rev 250418 affected approximately 63 drivers by making them = vulnerable to resource allocation failures on motherboards with buggy = BIOSes. The revision itself is good, but it needs to address these = drivers and bring them up to what is, in effect, a modified way for = drivers to manage their PCI resources. If you've been seeing something = like the following message since June 24/27, then you need this patch: mps0: port 0xd000-0xd0ff mem 0xfb79c000-0xfb79ffff irq 19 = at device 0.0 on pci4 mps0: PCI memory window not available device_attach: mps0 attach returned 6 The patch originated from John Baldwin, I merely fixed up a few nits and = am passing it around for review and testing. Please find it here: http://people.freebsd.org/~scottl/pci_command_fixes.patch Thanks, Scott From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 06:00:10 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2AC981EF; Sat, 10 Aug 2013 06:00:10 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 61A0A29AE; Sat, 10 Aug 2013 06:00:09 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id hr7so347068wib.16 for ; Fri, 09 Aug 2013 23:00:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=VbBJZaHJIis/uePBvSmuNm3Q1pgDiRs0gOtk8oAkueM=; b=Dj8vDjzsXHHcPqfVKw/iaeRbTtnT4iqI3Xt+Ou0fSstMv+LCYWA6PAKzglqXRgmW10 GNU+QvuBQsz/dRYvodNShOM3ISPalE6qNI8Men6trNlSljjKn4Hn1FJSIFTmQYB7epV+ UuTeFE7nTOgl93m6u+LELD/R8fKMRs8841tyWP+DylxkQrx1kbTO6uU5lSZPSgBDD8Up vR2ZaAuHp4UWWW1UcjBMEl8URnZT8uU9TjrQsv6W7RKoDPgH3ount8nFJSW9gjkfqwI6 1VSV+n3gpf6YDnjMqXHEqBt2CO+y56mvXnXGiaIdHh46g2erlIx66RLBUa5PyL7dypb9 ACvg== MIME-Version: 1.0 X-Received: by 10.194.203.73 with SMTP id ko9mr2140768wjc.79.1376114406690; Fri, 09 Aug 2013 23:00:06 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.116.136 with HTTP; Fri, 9 Aug 2013 23:00:06 -0700 (PDT) In-Reply-To: <5205AF0A.4090304@gmail.com> References: <512A6FFF.2060603@gmail.com> <51BBA07B.80403@gmail.com> <201308091157.19765.jhb@freebsd.org> <5205AF0A.4090304@gmail.com> Date: Fri, 9 Aug 2013 23:00:06 -0700 X-Google-Sender-Auth: KrHwq9kjYuqFYziakwiby-tm96M Message-ID: Subject: Re: Fixing X220 Video The Right Way From: Adrian Chadd To: matt Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-acpi@freebsd.org, 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: Sat, 10 Aug 2013 06:00:10 -0000 when did it start working? -adrian On 9 August 2013 20:10, matt wrote: > hw.acpi.reset_video used to send this machine X220 into a reboot loop, > with flashing thinklight. Interesting that it no longer causes this > problem. I kind of paused since the trackpad sucks so much in X. > > I think since ssh still works, that just the display or graphics port > is off. > > It may be worth trying to do some acpi_calls via ssh to try to hack > the display back on... > > Matt > > On 08/09/13 08:57, John Baldwin wrote: >> On Friday, August 09, 2013 4:37:50 am Adrian Chadd wrote: >>> Hi! >>> >>> Hm, resurrecting this thread, I'll try this on my X230 tomorrow >>> and see if it makes the (non-xorg, console only) video work on >>> resume. >>> >>> If it does, what will it take to automatically determine that >>> this kind of work-around is needed? >> >> >> This does not affect suspend/resume. It only fixes LCD brightness >> handling via acpi_video(4). >> > From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 06:11:58 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 105863AC for ; Sat, 10 Aug 2013 06:11:58 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9938C2A38 for ; Sat, 10 Aug 2013 06:11:57 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id l18so4042780wgh.11 for ; Fri, 09 Aug 2013 23:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=8cUZ/G1OTpadXK6l0V884TZwG27NQEIgqYT+WigbMPQ=; b=WssNi3lTcmqF9WDC5rU9e+3Pd4JrqyG8Eb3De69Wvfwm+il/MY50w+gTBkqXEUpra3 5xj658cWKA+JK8snYHqT4bYQQEKEmnsGwODrxhp3sWTK1SEoTcf6rGBfbsTmIVdyJMjQ V2h6aG9Fbbgj/0qZHEKbeCGX2vQDK3CCQndZsSNjkx0+BUv28/3PEppjNB0aUtIlQFIA xNL6WYsxuzdZ3oiN6POPa+PE5vcRpkMhTmoBfQjOeE+szs0RQhaWRtUvtvCaw3VlGvWz wX/ysvZcikth39BH3ev2PUK6O9I+XKOlJau/kNL2eUqY0lng+a08ElXfGAKD11J5Mj1E COmg== MIME-Version: 1.0 X-Received: by 10.180.211.206 with SMTP id ne14mr3793885wic.30.1376115115825; Fri, 09 Aug 2013 23:11:55 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.116.136 with HTTP; Fri, 9 Aug 2013 23:11:55 -0700 (PDT) In-Reply-To: <5E12B1A6-5B39-46FE-B8C7-239D23AEEE5E@samsco.org> References: <5E12B1A6-5B39-46FE-B8C7-239D23AEEE5E@samsco.org> Date: Fri, 9 Aug 2013 23:11:55 -0700 X-Google-Sender-Auth: dufR4yl4VO7bq4HFM51vZ661hTE Message-ID: Subject: Re: CFT: PCI Command Register fixups From: Adrian Chadd To: Scott Long Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "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: Sat, 10 Aug 2013 06:11:58 -0000 Hi, I'll test out the iwn patch, thanks! -adrian On 9 August 2013 20:56, Scott Long wrote: > All, > > Subversion rev 250418 affected approximately 63 drivers by making them vu= lnerable to resource allocation failures on motherboards with buggy BIOSes.= The revision itself is good, but it needs to address these drivers and br= ing them up to what is, in effect, a modified way for drivers to manage the= ir PCI resources. If you've been seeing something like the following messa= ge since June 24/27, then you need this patch: > > mps0: port 0xd000-0xd0ff mem 0xfb79c000-0xfb79ffff irq 19 a= t device 0.0 on pci4 > mps0: PCI memory window not available > device_attach: mps0 attach returned 6 > > The patch originated from John Baldwin, I merely fixed up a few nits and = am passing it around for review and testing. Please find it here: > > http://people.freebsd.org/~scottl/pci_command_fixes.patch > > Thanks, > Scott > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 08:37:11 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C762D685 for ; Sat, 10 Aug 2013 08:37:11 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-bk0-x22b.google.com (mail-bk0-x22b.google.com [IPv6:2a00:1450:4008:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3D9F12F16 for ; Sat, 10 Aug 2013 08:37:11 +0000 (UTC) Received: by mail-bk0-f43.google.com with SMTP id mz13so1321269bkb.2 for ; Sat, 10 Aug 2013 01:37:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-type:content-transfer-encoding; bh=ZUjXwOOr8JnrtSf26Jw4i9SAqNZVupz/dTuvweACKU8=; b=cqF/gzKa8wmXuhylWdZ3NIVMYghYjRdEnodZi+BUAuZGe/180UYhS78HM6/2xlQpYl alqT+1Kmb8tkqr10HXI5al+aECHd2gEDpW7U07mZV3FG9CvO8MWrDf1XaaYcTE5d3FYI EQNgrLAeqSSE2dcsYVkyQ9C/1VILIPQPU2BzUtGYbG3o4kxRdP78+yWr4JmyI7mNfixH 3+PXf981yn1BeCWJnliGABrahIqrD6pR+vBaflUHZ0+ZmSqTixv6GtOKVEjWh9FasRrG EOSwU20yv5+zrqCkE1zelGGh5XAyatv0DqbFRX8ysjtZE6lvYrO+PTdwBInLuNge5ntf rDMQ== X-Received: by 10.204.186.208 with SMTP id ct16mr2591954bkb.165.1376123828313; Sat, 10 Aug 2013 01:37:08 -0700 (PDT) Received: from ernst.home (p4FCA6A8C.dip0.t-ipconnect.de. [79.202.106.140]) by mx.google.com with ESMTPSA id 14sm2504929bkl.17.2013.08.10.01.37.06 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 10 Aug 2013 01:37:07 -0700 (PDT) Date: Sat, 10 Aug 2013 10:37:05 +0200 From: Gary Jennejohn To: David Wolfskill Subject: Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present Message-ID: <20130810103705.022ce7be@ernst.home> In-Reply-To: <20130809171237.GN1746@albert.catwhisker.org> References: <20130808201018.1215f733@munin.geoinf.fu-berlin.de> <1375997961.1451.3.camel@localhost> <20130809073251.376c9206@munin.geoinf.fu-berlin.de> <20130809171237.GN1746@albert.catwhisker.org> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.17; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 08:37:11 -0000 On Fri, 9 Aug 2013 10:12:37 -0700 David Wolfskill wrote: > On Fri, Aug 09, 2013 at 07:32:51AM +0200, O. Hartmann wrote: > > ... > > > > On 8 August 2013 11:10, O. Hartmann > > > > wrote: > > > > > The most recent CURRENT doesn't work with the x11/nvidia-driver > > > > > (which is at 319.25 in the ports and 325.15 from nVidia). > > > > > > > > > > After build- and installworld AND successfully rebuilding port > > > > > x11/nvidia-driver, the system crashes immediately after a reboot > > > > > as soon the kernel module nvidia.ko seems to get loaded (in my > > > > > case, I load nvidia.ko via /etc/rc.conf.local since the nVidia > > > > > BLOB doesn't load cleanly everytime when loaded > > > > > from /boot/loader.conf). > > > > > > > > > > The crash occurs on systems with default compilation options set > > > > > while building world and with settings like -O3 -march=native. It > > > > > doesn't matter. > > > > > > > > > > FreeBSD and the port x11/nvidia-driver has been compiled with > > > > > CLANG. > > > > > > > > > > Most recent FreeBSD revision still crashing is r254097. > > > > > > > > > > When vmcore is saved, I always see something like > > > > > > > > > > savecore: reboot after panic: vm_radix_insert: key 23c078 is > > > > > already present > > > > > > > > > > > > > > > Does anyone has any idea what's going on? > > > > > > > > > > Thanks for helping in advance, > > > > > > > > > > Oliver > > > > > > I'm seeing a complete deadlock on my T520 with today's current and > > > latest portsnap'd versions of ports for the nvidia-driver updates. > > > > > > A little bisection and help from others seems to point the finger at > > > Jeff's r254025 > > > > > > I'm getting a complete deadlock on X starting, but loading the module > > > seems to have no ill effects. > > > > > > Sean > > > > Rigth, I loaded the module also via /boot/loader.conf and it loads > > cleanly. I start xdm and then the deadlock occurs. > > > > I tried recompiling the whole xorg suite via "portmaster -f xorg xdm", > > it took a while, but no effect, still dying. > > ..... > > Sorry to be rather late to the party; the Internet connection I'm using > at the moment is a bit flaky. (I'm out of town.) > > I managed to get head/i386 @r254135 built and booting ... by removing > the "options DEBUG_MEMGUARD" from my kernel. > > However, that merely prevented a (very!) early panic, and got me to the > point where trying to start xdm with the x11/nvidia-driver as the > display driver causes an immediate reboot (no crash dump, despite > 'dumpdev="AUTO"' in /etc/rc.conf). No drop to debugger, either. > > Booting & starting xdm with the nv driver works -- that's my present > environment as I am typing this. > > However, the panic with DEBUG_MEMGUARD may offer a clue. Unfortunately, > it's early enough that screen lock/scrolling doesn't work, and I only > had the patience to write down partof the panic information. (This is > on my laptop; no serial console, AFAICT -- and no device to capture the > output if I did, since I'm not at home.) > > The top line of the screen (at the panic) reads: > > s/kern/subr_vmem.c:1050 > > The backtrace has the expected stuff near the top (about kbd, panic, and > memguard stuff); just below that is: > > vmem_alloc(c1226100,6681000,2,c1820cc0,3b5,...) at 0xc0ac5673=vmem_alloc+0x53/frame 0xc1820ca0 > > Caveat: that was hand-transcribed from the screen to papaer, then > hand-transcribed from paper to this email message. And my highest grade > in "Penmanship" was a D+. > > Be that as it may, here's the relevant section of subr_vmem.c with line > numbers (cut/pasted, so tabs get munged): > > 1039 /* > 1040 * vmem_alloc: allocate resource from the arena. > 1041 */ > 1042 int > 1043 vmem_alloc(vmem_t *vm, vmem_size_t size, int flags, vmem_addr_t *addrp) > 1044 { > 1045 const int strat __unused = flags & VMEM_FITMASK; > 1046 qcache_t *qc; > 1047 > 1048 flags &= VMEM_FLAGS; > 1049 MPASS(size > 0); > 1050 MPASS(strat == M_BESTFIT || strat == M_FIRSTFIT); > 1051 if ((flags & M_NOWAIT) == 0) > 1052 WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL, "vmem_alloc"); > 1053 > 1054 if (size <= vm->vm_qcache_max) { > 1055 qc = &vm->vm_qcache[(size - 1) >> vm->vm_quantum_shift]; > 1056 *addrp = (vmem_addr_t)uma_zalloc(qc->qc_cache, flags); > 1057 if (*addrp == 0) > 1058 return (ENOMEM); > 1059 return (0); > 1060 } > 1061 > 1062 return vmem_xalloc(vm, size, 0, 0, 0, VMEM_ADDR_MIN, VMEM_ADDR_MAX, > 1063 flags, addrp); > 1064 } > > > This is at r254025. > The REINPLACE_CMD at line 160 of nvidia-driver/Makefile is incorrect. How do I know that? Because I made a patch which results in a working nvidia-driver-319.32 with r254050. That's what I'm running right now. Here's the patch (loaded with :r in vi, so all spaces etc. are correct): --- src/nvidia_subr.c.orig 2013-08-09 11:32:26.000000000 +0200 +++ src/nvidia_subr.c 2013-08-09 11:33:23.000000000 +0200 @@ -945,7 +945,7 @@ return ENOMEM; } - address = kmem_alloc_contig(kernel_map, size, flags, 0, + address = kmem_alloc_contig(kmem_arena, size, flags, 0, sc->dma_mask, PAGE_SIZE, 0, attr); if (!address) { status = ENOMEM; @@ -994,7 +994,7 @@ os_flush_cpu_cache(); if (at->pte_array[0].virtual_address != NULL) { - kmem_free(kernel_map, + kmem_free(kmem_arena, at->pte_array[0].virtual_address, at->size); malloc_type_freed(M_NVIDIA, at->size); } @@ -1021,7 +1021,7 @@ if (at->attr != VM_MEMATTR_WRITE_BACK) os_flush_cpu_cache(); - kmem_free(kernel_map, at->pte_array[0].virtual_address, + kmem_free(kmem_arena, at->pte_array[0].virtual_address, at->size); malloc_type_freed(M_NVIDIA, at->size); @@ -1085,7 +1085,7 @@ } for (i = 0; i < count; i++) { - address = kmem_alloc_contig(kernel_map, PAGE_SIZE, flags, 0, + address = kmem_alloc_contig(kmem_arena, PAGE_SIZE, flags, 0, sc->dma_mask, PAGE_SIZE, 0, attr); if (!address) { status = ENOMEM; @@ -1139,7 +1139,7 @@ for (i = 0; i < count; i++) { if (at->pte_array[i].virtual_address == 0) break; - kmem_free(kernel_map, + kmem_free(kmem_arena, at->pte_array[i].virtual_address, PAGE_SIZE); malloc_type_freed(M_NVIDIA, PAGE_SIZE); } @@ -1169,7 +1169,7 @@ os_flush_cpu_cache(); for (i = 0; i < count; i++) { - kmem_free(kernel_map, + kmem_free(kmem_arena, at->pte_array[i].virtual_address, PAGE_SIZE); malloc_type_freed(M_NVIDIA, PAGE_SIZE); } The primary differences are 1) use kmem_arena instead of kernel_map everywhere. The REINPLACE_CMD uses kernel_arena 2) DO NOT use kva_free, but kmem_free as previously To use the patch Delete or comment out the 4 lines starting at 160 in Makefile Run ``make patch'' cd work/NVIDIA-FreeBSD-x86_64-319.32/src patch < [wherever the patch is] cd ../../.. make deinstall install clean kldunload the old nvidia.ko kldload the new nvidia.ko start X -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 09:12:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 877B1BF3 for ; Sat, 10 Aug 2013 09:12:53 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E9FDA20C2 for ; Sat, 10 Aug 2013 09:12:52 +0000 (UTC) Received: from p5dc3f042.dip0.t-ipconnect.de ([93.195.240.66] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1V85C4-0002S9-Ra; Sat, 10 Aug 2013 11:10:41 +0200 Message-ID: <52060390.1040505@gwdg.de> Date: Sat, 10 Aug 2013 11:10:40 +0200 From: Rainer Hurling User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130808 Thunderbird/17.0.8 MIME-Version: 1.0 To: gljennjohn@googlemail.com Subject: Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present References: <20130808201018.1215f733@munin.geoinf.fu-berlin.de> <1375997961.1451.3.camel@localhost> <20130809073251.376c9206@munin.geoinf.fu-berlin.de> <20130809171237.GN1746@albert.catwhisker.org> <20130810103705.022ce7be@ernst.home> In-Reply-To: <20130810103705.022ce7be@ernst.home> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: FreeBSD CURRENT 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: Sat, 10 Aug 2013 09:12:53 -0000 Am 10.08.2013 10:37, schrieb Gary Jennejohn: > On Fri, 9 Aug 2013 10:12:37 -0700 > David Wolfskill wrote: > >> On Fri, Aug 09, 2013 at 07:32:51AM +0200, O. Hartmann wrote: >>> ... >>>>> On 8 August 2013 11:10, O. Hartmann >>>>> wrote: >>>>>> The most recent CURRENT doesn't work with the x11/nvidia-driver >>>>>> (which is at 319.25 in the ports and 325.15 from nVidia). >>>>>> >>>>>> After build- and installworld AND successfully rebuilding port >>>>>> x11/nvidia-driver, the system crashes immediately after a reboot >>>>>> as soon the kernel module nvidia.ko seems to get loaded (in my >>>>>> case, I load nvidia.ko via /etc/rc.conf.local since the nVidia >>>>>> BLOB doesn't load cleanly everytime when loaded >>>>>> from /boot/loader.conf). >>>>>> >>>>>> The crash occurs on systems with default compilation options set >>>>>> while building world and with settings like -O3 -march=native. It >>>>>> doesn't matter. >>>>>> >>>>>> FreeBSD and the port x11/nvidia-driver has been compiled with >>>>>> CLANG. >>>>>> >>>>>> Most recent FreeBSD revision still crashing is r254097. >>>>>> >>>>>> When vmcore is saved, I always see something like >>>>>> >>>>>> savecore: reboot after panic: vm_radix_insert: key 23c078 is >>>>>> already present >>>>>> >>>>>> >>>>>> Does anyone has any idea what's going on? >>>>>> >>>>>> Thanks for helping in advance, >>>>>> >>>>>> Oliver >>>> >>>> I'm seeing a complete deadlock on my T520 with today's current and >>>> latest portsnap'd versions of ports for the nvidia-driver updates. >>>> >>>> A little bisection and help from others seems to point the finger at >>>> Jeff's r254025 >>>> >>>> I'm getting a complete deadlock on X starting, but loading the module >>>> seems to have no ill effects. >>>> >>>> Sean >>> >>> Rigth, I loaded the module also via /boot/loader.conf and it loads >>> cleanly. I start xdm and then the deadlock occurs. >>> >>> I tried recompiling the whole xorg suite via "portmaster -f xorg xdm", >>> it took a while, but no effect, still dying. >>> ..... >> >> Sorry to be rather late to the party; the Internet connection I'm using >> at the moment is a bit flaky. (I'm out of town.) >> >> I managed to get head/i386 @r254135 built and booting ... by removing >> the "options DEBUG_MEMGUARD" from my kernel. >> >> However, that merely prevented a (very!) early panic, and got me to the >> point where trying to start xdm with the x11/nvidia-driver as the >> display driver causes an immediate reboot (no crash dump, despite >> 'dumpdev="AUTO"' in /etc/rc.conf). No drop to debugger, either. >> >> Booting & starting xdm with the nv driver works -- that's my present >> environment as I am typing this. >> >> However, the panic with DEBUG_MEMGUARD may offer a clue. Unfortunately, >> it's early enough that screen lock/scrolling doesn't work, and I only >> had the patience to write down partof the panic information. (This is >> on my laptop; no serial console, AFAICT -- and no device to capture the >> output if I did, since I'm not at home.) >> >> The top line of the screen (at the panic) reads: >> >> s/kern/subr_vmem.c:1050 >> >> The backtrace has the expected stuff near the top (about kbd, panic, and >> memguard stuff); just below that is: >> >> vmem_alloc(c1226100,6681000,2,c1820cc0,3b5,...) at 0xc0ac5673=vmem_alloc+0x53/frame 0xc1820ca0 >> >> Caveat: that was hand-transcribed from the screen to papaer, then >> hand-transcribed from paper to this email message. And my highest grade >> in "Penmanship" was a D+. >> >> Be that as it may, here's the relevant section of subr_vmem.c with line >> numbers (cut/pasted, so tabs get munged): >> >> 1039 /* >> 1040 * vmem_alloc: allocate resource from the arena. >> 1041 */ >> 1042 int >> 1043 vmem_alloc(vmem_t *vm, vmem_size_t size, int flags, vmem_addr_t *addrp) >> 1044 { >> 1045 const int strat __unused = flags & VMEM_FITMASK; >> 1046 qcache_t *qc; >> 1047 >> 1048 flags &= VMEM_FLAGS; >> 1049 MPASS(size > 0); >> 1050 MPASS(strat == M_BESTFIT || strat == M_FIRSTFIT); >> 1051 if ((flags & M_NOWAIT) == 0) >> 1052 WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL, "vmem_alloc"); >> 1053 >> 1054 if (size <= vm->vm_qcache_max) { >> 1055 qc = &vm->vm_qcache[(size - 1) >> vm->vm_quantum_shift]; >> 1056 *addrp = (vmem_addr_t)uma_zalloc(qc->qc_cache, flags); >> 1057 if (*addrp == 0) >> 1058 return (ENOMEM); >> 1059 return (0); >> 1060 } >> 1061 >> 1062 return vmem_xalloc(vm, size, 0, 0, 0, VMEM_ADDR_MIN, VMEM_ADDR_MAX, >> 1063 flags, addrp); >> 1064 } >> >> >> This is at r254025. >> > > The REINPLACE_CMD at line 160 of nvidia-driver/Makefile is incorrect. > > How do I know that? Because I made a patch which results in a working > nvidia-driver-319.32 with r254050. That's what I'm running right now. > > Here's the patch (loaded with :r in vi, so all spaces etc. are correct): > > --- src/nvidia_subr.c.orig 2013-08-09 11:32:26.000000000 +0200 > +++ src/nvidia_subr.c 2013-08-09 11:33:23.000000000 +0200 > @@ -945,7 +945,7 @@ > return ENOMEM; > } > > - address = kmem_alloc_contig(kernel_map, size, flags, 0, > + address = kmem_alloc_contig(kmem_arena, size, flags, 0, > sc->dma_mask, PAGE_SIZE, 0, attr); > if (!address) { > status = ENOMEM; > @@ -994,7 +994,7 @@ > os_flush_cpu_cache(); > > if (at->pte_array[0].virtual_address != NULL) { > - kmem_free(kernel_map, > + kmem_free(kmem_arena, > at->pte_array[0].virtual_address, at->size); > malloc_type_freed(M_NVIDIA, at->size); > } > @@ -1021,7 +1021,7 @@ > if (at->attr != VM_MEMATTR_WRITE_BACK) > os_flush_cpu_cache(); > > - kmem_free(kernel_map, at->pte_array[0].virtual_address, > + kmem_free(kmem_arena, at->pte_array[0].virtual_address, > at->size); > malloc_type_freed(M_NVIDIA, at->size); > > @@ -1085,7 +1085,7 @@ > } > > for (i = 0; i < count; i++) { > - address = kmem_alloc_contig(kernel_map, PAGE_SIZE, flags, 0, > + address = kmem_alloc_contig(kmem_arena, PAGE_SIZE, flags, 0, > sc->dma_mask, PAGE_SIZE, 0, attr); > if (!address) { > status = ENOMEM; > @@ -1139,7 +1139,7 @@ > for (i = 0; i < count; i++) { > if (at->pte_array[i].virtual_address == 0) > break; > - kmem_free(kernel_map, > + kmem_free(kmem_arena, > at->pte_array[i].virtual_address, PAGE_SIZE); > malloc_type_freed(M_NVIDIA, PAGE_SIZE); > } > @@ -1169,7 +1169,7 @@ > os_flush_cpu_cache(); > > for (i = 0; i < count; i++) { > - kmem_free(kernel_map, > + kmem_free(kmem_arena, > at->pte_array[i].virtual_address, PAGE_SIZE); > malloc_type_freed(M_NVIDIA, PAGE_SIZE); > } > > The primary differences are > 1) use kmem_arena instead of kernel_map everywhere. The REINPLACE_CMD > uses kernel_arena > 2) DO NOT use kva_free, but kmem_free as previously > > To use the patch > Delete or comment out the 4 lines starting at 160 in Makefile > Run ``make patch'' > cd work/NVIDIA-FreeBSD-x86_64-319.32/src > patch < [wherever the patch is] > cd ../../.. > make deinstall install clean > kldunload the old nvidia.ko > kldload the new nvidia.ko > start X > Yes, I can confirm, that it builds, installs and runs fine for me. The patch should be placed as x11/nvidia-driver/files/patch-src__nvidia_subr.c, shoudn't it? Many thanks for this work. Regards and a nice weekend, Rainer Hurling From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 09:31:25 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CB39A15C for ; Sat, 10 Aug 2013 09:31:25 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-bk0-x234.google.com (mail-bk0-x234.google.com [IPv6:2a00:1450:4008:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5347521BF for ; Sat, 10 Aug 2013 09:31:25 +0000 (UTC) Received: by mail-bk0-f52.google.com with SMTP id e11so1651567bkh.11 for ; Sat, 10 Aug 2013 02:31:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-type:content-transfer-encoding; bh=4SaNYZn3zxdR2uJeqqBMFG5wQGG1QgtjA3MnIKpz9bo=; b=XsYYp1XfUPvAQQW8nzZ+sy7TnbLZYFx5Hs5ILg2Aa05G/Dz05WbublIbFLGtUo77sZ tdON+X17yQPIzS8ti05q8qzzWl9cpImJ2aqq7Lls4ASiBIXgHda3naepUdHNO8AJycdh NENJ/vEOJd1Nt5UPJdAAa4ZvMI6hSnlLcpYfItMZQwS/tEfXxiDfv2Rf4ygdqZAoepk2 7Gn+d3KkV23T5t3Js3mMyKgzXMShxGfjFS/B1d9x4xlKZS9E/b5DfjoG8vMSK7Q0FxDz iuR1pkUTUG6R0Z0k1f+FzL49JRwE9FrPQCR5ncBpM6UrmPCwfiqmjhGFE5NlhWJq8q6j OFeQ== X-Received: by 10.204.74.135 with SMTP id u7mr2692095bkj.54.1376127083351; Sat, 10 Aug 2013 02:31:23 -0700 (PDT) Received: from ernst.home (p4FCA6A8C.dip0.t-ipconnect.de. [79.202.106.140]) by mx.google.com with ESMTPSA id h5sm3912232bkg.8.2013.08.10.02.31.21 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 10 Aug 2013 02:31:22 -0700 (PDT) Date: Sat, 10 Aug 2013 11:31:19 +0200 From: Gary Jennejohn To: Rainer Hurling Subject: Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present Message-ID: <20130810113119.3f44ae32@ernst.home> In-Reply-To: <52060390.1040505@gwdg.de> References: <20130808201018.1215f733@munin.geoinf.fu-berlin.de> <1375997961.1451.3.camel@localhost> <20130809073251.376c9206@munin.geoinf.fu-berlin.de> <20130809171237.GN1746@albert.catwhisker.org> <20130810103705.022ce7be@ernst.home> <52060390.1040505@gwdg.de> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.17; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 09:31:25 -0000 On Sat, 10 Aug 2013 11:10:40 +0200 Rainer Hurling wrote: > Yes, I can confirm, that it builds, installs and runs fine for me. > > The patch should be placed as > x11/nvidia-driver/files/patch-src__nvidia_subr.c, shoudn't it? > > Many thanks for this work. > Thanks for testing. Yes, putting the patch into files/ with that name works also and is much simpler than the steps I outlined. -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 09:32:49 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B031E288; Sat, 10 Aug 2013 09:32:49 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7694D21D8; Sat, 10 Aug 2013 09:32:49 +0000 (UTC) Received: by mail-pb0-f49.google.com with SMTP id xb4so5245208pbc.8 for ; Sat, 10 Aug 2013 02:32:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8f7IGUyzHgFY+GBt1U2sxX1pPCwvYfFnBqQPtLNVhO4=; b=IDj6yeFu3bYeBxn8Gq3aT1db+W3vFMnnBBks0JCoFFqqSBGeLMFPqe8dEAga0blTFy sTipdlzcB15kUhaJB7wiHyB1J7gObxsixOfeVtRCcKSvKtmpegDpEdOfJ86+nruYuqKG R+dOpRTErhJEMahxnIOx60BAQeaFG8ww1DwT2JjSVo0FG8/rZZclz0MHahicCOUBaMQn XHe2bC07MW9zq4mqsp4Nnplqa0bigdb5Eo7BLA6GDRDZBTCTHdnpY+kCGF9sChtUu8pb eFdpWAhB4Pwpwapi/eoEu3Y+j7jpYBXYD3ObPL9qJDnc25WhVjdd/6tuAwnm0YUfDHGG oc7g== X-Received: by 10.69.15.33 with SMTP id fl1mr15371928pbd.189.1376127169041; Sat, 10 Aug 2013 02:32:49 -0700 (PDT) Received: from flatline.sfrsys.com (c-67-161-25-189.hsd1.ca.comcast.net. [67.161.25.189]) by mx.google.com with ESMTPSA id yk10sm27431232pac.16.2013.08.10.02.32.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 10 Aug 2013 02:32:48 -0700 (PDT) Message-ID: <52060881.8090607@gmail.com> Date: Sat, 10 Aug 2013 02:31:45 -0700 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130806 Thunderbird/17.0.7 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Fixing X220 Video The Right Way References: <512A6FFF.2060603@gmail.com> <51BBA07B.80403@gmail.com> <201308091157.19765.jhb@freebsd.org> <5205AF0A.4090304@gmail.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, 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: Sat, 10 Aug 2013 09:32:49 -0000 Not sure that it did :) I tried it once early on, and it concerned me enough I never tried again. It was clearly in a violently erroneous state! At one point, X *could* resume the display. This makes me think the problem is solved via the graphics "chip" state, but it could be an acpi thing. I can't remember if I ever tried to startx after the resume on the "blind" console. Matt On 08/09/13 23:00, Adrian Chadd wrote: > when did it start working? > > > -adrian > > On 9 August 2013 20:10, matt wrote: >> hw.acpi.reset_video used to send this machine X220 into a reboot >> loop, with flashing thinklight. Interesting that it no longer >> causes this problem. I kind of paused since the trackpad sucks so >> much in X. >> >> I think since ssh still works, that just the display or graphics >> port is off. >> >> It may be worth trying to do some acpi_calls via ssh to try to >> hack the display back on... >> >> Matt >> >> On 08/09/13 08:57, John Baldwin wrote: >>> On Friday, August 09, 2013 4:37:50 am Adrian Chadd wrote: >>>> Hi! >>>> >>>> Hm, resurrecting this thread, I'll try this on my X230 >>>> tomorrow and see if it makes the (non-xorg, console only) >>>> video work on resume. >>>> >>>> If it does, what will it take to automatically determine >>>> that this kind of work-around is needed? >>> >>> >>> This does not affect suspend/resume. It only fixes LCD >>> brightness handling via acpi_video(4). >>> >> > From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 11:02:06 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AF814239 for ; Sat, 10 Aug 2013 11:02:06 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 778B2259E for ; Sat, 10 Aug 2013 11:02:06 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:acd9:718:8db4:b823]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id BB2BE4AC1C for ; Sat, 10 Aug 2013 15:02:03 +0400 (MSK) Date: Sat, 10 Aug 2013 15:01:57 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1388219877.20130810150157@serebryakov.spb.ru> To: "current@freebsd.org" Subject: loader don't load loader.conf if device.hints has errors MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@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: Sat, 10 Aug 2013 11:02:06 -0000 Hello, Current. I've make simple mistake (DOS-style EOL) in /boot/device.hints and /boot/loader.conf was skipped too with strange (device.hints-related) message: FreeBSD/x86 bootstrap loader, Revision 1.1 (root@fbsd-c-64.vm.home.serebryakov.spb.ru, Sat Aug 10 14:02:41 MSK 2013) Loading /boot/defaults/loader.conf Warning: syntax error on file /boot/device.hints hint.uart.0.flags="0x00" ^ Warning: syntax error on file /boot/loader.conf hint.uart.0.flags="0x00" ^ /boot/kernel/kernel text=0x5dfed8 data=0x69078+0xd6b10 syms=[0x8+0x9cd50+0x8+0x930ab] Is it Ok? -- // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 11:09:04 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C5B73503; Sat, 10 Aug 2013 11:09:04 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 8685C25D7; Sat, 10 Aug 2013 11:09:04 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:acd9:718:8db4:b823]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 689064AC1C; Sat, 10 Aug 2013 15:08:56 +0400 (MSK) Date: Sat, 10 Aug 2013 15:08:49 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <383656436.20130810150849@serebryakov.spb.ru> To: freebsd-embedded@FreeBSD.org, freebsd-current@FreeBSD.org Subject: nanobsd-built system doesn't have SVN revision in "uname" (and it looks like regression) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@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: Sat, 10 Aug 2013 11:09:04 -0000 Hello, Freebsd-embedded. Latest revisions of -CURRENT built with "nanobsd" script haven't revision in "uname -a" output: FreeBSD gateway.home.serebryakov.spb.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Sat Aug 10 14:17:32 MSK 2013 root@fbsd-c-64.vm.home.serebryakov.spb.ru:/data/obj.nano/gateway.v2/data/src/sys/D2500CC amd64 System was built from "/data/src" directory, which IS subversion working copy and `svn' and `svnversion' PRESENTS in $PATH. It is r254177, really. I don't remeber exactly, but I have feeling, that earlier revisions didn't have this problem. -- // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 11:18:54 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BEC886AA; Sat, 10 Aug 2013 11:18:54 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 7C60D2632; Sat, 10 Aug 2013 11:18:54 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:acd9:718:8db4:b823]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id DA12F4AC1C; Sat, 10 Aug 2013 15:18:52 +0400 (MSK) Date: Sat, 10 Aug 2013 15:18:46 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <37152758.20130810151846@serebryakov.spb.ru> To: Lev Serebryakov Subject: Re: nanobsd-built system doesn't have SVN revision in "uname" (and it looks like regression) In-Reply-To: <383656436.20130810150849@serebryakov.spb.ru> References: <383656436.20130810150849@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@FreeBSD.org, freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@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: Sat, 10 Aug 2013 11:18:54 -0000 Hello, Lev. You wrote 10 =D0=B0=D0=B2=D0=B3=D1=83=D1=81=D1=82=D0=B0 2013 =D0=B3., 15:08= :49: LS> Latest revisions of -CURRENT built with "nanobsd" script haven't revis= ion LS> in "uname -a" output: LS> FreeBSD gateway.home.serebryakov.spb.ru 10.0-CURRENT FreeBSD LS> 10.0-CURRENT #0: Sat Aug 10 14:17:32 MSK 2013 =20 LS> root@fbsd-c-64.vm.home.serebryakov.spb.ru:/data/obj.nano/gateway.v2/dat= a/src/sys/D2500CC amd64 LS> System was built from "/data/src" directory, which IS subversion worki= ng LS> copy and `svn' and `svnversion' PRESENTS in $PATH. Ok, problem is, that "svnliteversion" presents too, but WC version is old one (for 1.7.x). I'm not sure, is this bug worth fixing. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 11:24:18 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DBA178EF for ; Sat, 10 Aug 2013 11:24:18 +0000 (UTC) (envelope-from joel@freebsd.org) Received: from mail.vnode.se (mail.vnode.se [212.247.52.13]) by mx1.freebsd.org (Postfix) with ESMTP id 9C0342695 for ; Sat, 10 Aug 2013 11:24:18 +0000 (UTC) Received: from mail.vnode.se (localhost [127.0.0.1]) by mail.vnode.se (Postfix) with ESMTP id B33E6E3F07A for ; Sat, 10 Aug 2013 13:24:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at vnode.se Received: from mail.vnode.se ([127.0.0.1]) by mail.vnode.se (mail.vnode.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQdnHbsPYuOY for ; Sat, 10 Aug 2013 13:24:15 +0200 (CEST) Received: from devbox.vnode.local (unknown [83.223.1.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.vnode.se (Postfix) with ESMTPSA id 7F659E3F079 for ; Sat, 10 Aug 2013 13:24:14 +0200 (CEST) Date: Sat, 10 Aug 2013 13:24:11 +0200 From: Joel Dahl To: current@freebsd.org Subject: panic on boot with fresh current Message-ID: <20130810112410.GA27286@devbox.vnode.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) 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: Sat, 10 Aug 2013 11:24:18 -0000 Hi, I just rebuilt a fresh current on my laptop. It panics on boot with: panic: witness_init: pending locks list is too small, increase WITNESS_PENDLIST I'm in a hurry right now so I can't gather much more info at the moment, but I thought I'd mention it. -- Joel From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 12:59:31 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F0278E13; Sat, 10 Aug 2013 12:59:30 +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]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A8A382A76; Sat, 10 Aug 2013 12:59:30 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) with esmtp (envelope-from ) id <1V88lU-002bPa-4D>; Sat, 10 Aug 2013 14:59:28 +0200 Received: from g225187188.adsl.alicedsl.de ([92.225.187.188] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) with esmtpsa (envelope-from ) id <1V88lT-000ojS-Uw>; Sat, 10 Aug 2013 14:59:28 +0200 Date: Sat, 10 Aug 2013 14:59:22 +0200 From: "O. Hartmann" To: gljennjohn@googlemail.com Subject: Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present Message-ID: <20130810145922.1bc18c5a@thor.walstatt.dyndns.org> In-Reply-To: <20130810113119.3f44ae32@ernst.home> References: <20130808201018.1215f733@munin.geoinf.fu-berlin.de> <1375997961.1451.3.camel@localhost> <20130809073251.376c9206@munin.geoinf.fu-berlin.de> <20130809171237.GN1746@albert.catwhisker.org> <20130810103705.022ce7be@ernst.home> <52060390.1040505@gwdg.de> <20130810113119.3f44ae32@ernst.home> Organization: FU Berlin X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/VMFiOyelyg1yJjVAXCioeNb"; protocol="application/pgp-signature" X-Originating-IP: 92.225.187.188 Cc: FreeBSD Ports , FreeBSD CURRENT 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: Sat, 10 Aug 2013 12:59:31 -0000 --Sig_/VMFiOyelyg1yJjVAXCioeNb Content-Type: multipart/mixed; boundary="MP_/p+JT9kiyBsVuns5obrQbw3L" --MP_/p+JT9kiyBsVuns5obrQbw3L Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sat, 10 Aug 2013 11:31:19 +0200 Gary Jennejohn wrote: > On Sat, 10 Aug 2013 11:10:40 +0200 > Rainer Hurling wrote: >=20 > > Yes, I can confirm, that it builds, installs and runs fine for me. > >=20 > > The patch should be placed as > > x11/nvidia-driver/files/patch-src__nvidia_subr.c, shoudn't it? > >=20 > > Many thanks for this work. > >=20 >=20 > Thanks for testing. >=20 > Yes, putting the patch into files/ with that name works also and > is much simpler than the steps I outlined. >=20 Placing the patch in files as recommended here doesn't play well with the obvious intention of the REINPLACE command: the patch only applies to 319.25. I use the cutting edge 325.15. The patch doesn't apply since some lines shifted - here comes the tricky REINPLACE part of the Makefile in place. I simply adapted your patches discussed and introduced here and "adapted" the REINPLACE statements/pattern around line 160 in the toplevel Makefile of port x11/nvidia-driver. Find the patch attached - I forgot to raise PORTREVISION=3D1. I'm now sending this email from the prior crashing box with the patch discussed applied via the Makefile to 325.15. Thanks a lot for the fast help. Regards, Oliver=20 --MP_/p+JT9kiyBsVuns5obrQbw3L Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename=nvidia-driver.patch.txt diff -Nur nvidia-driver.orig/Makefile nvidia-driver/Makefile --- nvidia-driver.orig/Makefile 2013-08-10 14:46:08.000000000 +0200 +++ nvidia-driver/Makefile 2013-08-10 14:41:52.000000000 +0200 @@ -158,8 +158,8 @@ .endif # Catch up with KVA space allocation API changes in recent -CURRENT .if ${OSVERSION} > 1000040 - ${REINPLACE_CMD} -e 's/kmem_free(kernel_map,/kva_free(/ ; \ - /kmem_alloc_contig/s/map/arena/' ${WRKSRC}/src/nvidia_subr.c + ${REINPLACE_CMD} -e 's/kmem_free(kernel_map,/kmem_free(kmem_arena,/ ; \ + /kmem_alloc_contig/s/kernel_map/kmem_arena/' ${WRKSRC}/src/nvidia_subr.c .endif # Process OPTIONS .if ${PORT_OPTIONS:MFREEBSD_AGP} --MP_/p+JT9kiyBsVuns5obrQbw3L-- --Sig_/VMFiOyelyg1yJjVAXCioeNb Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBAgAGBQJSBjkvAAoJEOgBcD7A/5N8HLYIALx4PtCwZ/VeVcSGFsNX7Iwj orGyh0RNxUlsgmxUY4QdSQ9PXt5bpz6dpxAnhh3ILz/8mGriWyNABeGrURh8v6gG HDBhcsRYQa54vvTHPmOXu6er33sBrz6rUv6I1RBk/4KJaYngax0AQxM0dcgKg6jD JFhac5HsfWIOamEbyV4bu/UOCeuq9xI9F4LEwkNyj/5nc95UUO2CadBGa+cUUuYj qkV17LRY7vsjDzgn4oCzdOQxYimDjsIhgiZtVr9LebHiXjViFQrTRpdswJ9pr2VJ WUBB03ickD+FGkEv8JMr2zJdZnWPKA/ZZoNNORT9a9TegwT44SvF/MIgXhMHUzs= =5Sek -----END PGP SIGNATURE----- --Sig_/VMFiOyelyg1yJjVAXCioeNb-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 13:22:42 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5B089B36; Sat, 10 Aug 2013 13:22:42 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E187F2BB6; Sat, 10 Aug 2013 13:22:41 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 64A6F6A6004; Sat, 10 Aug 2013 15:22:39 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id r7ADMdWn058559; Sat, 10 Aug 2013 15:22:39 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id r7ADMd92057441; Sat, 10 Aug 2013 15:22:39 +0200 (CEST) (envelope-from lars) Date: Sat, 10 Aug 2013 15:22:39 +0200 From: Lars Engels To: Hans Petter Selasky Subject: Re: Problems with usb bluetooth device Message-ID: <20130810132239.GR85426@e-new.0x20.net> References: <20090328095030.GD64269@e.0x20.net> <200903281100.33957.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Kg2J3k9IiiSZbiqb" Content-Disposition: inline In-Reply-To: <200903281100.33957.hselasky@c2i.net> X-Editor: VIM - Vi IMproved 7.3 X-Operation-System: FreeBSD 8.4-RELEASE User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, 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: Sat, 10 Aug 2013 13:22:42 -0000 --Kg2J3k9IiiSZbiqb Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 28, 2009 at 11:00:32AM +0100, Hans Petter Selasky wrote: > On Saturday 28 March 2009, Lars Engels wrote: > > Hi all, > > > > yesterday I bought a shiny new hama usb bluetooth dongle but I am having > > some problems using it: > > > > before loading ng_ubt: > > usb2_alloc_device:1480: set address 2 failed (ignored) > > usb2_alloc_device:1516: getting device descriptor at addr 2 failed! > > usb2_req_re_enumerate:1421: addr=3D2, set address failed! (ignored) > > usb2_req_re_enumerate:1434: getting device descriptor at addr 2 faile= d! > > usb2_req_re_enumerate:1421: addr=3D2, set address failed! (ignored) > > usb2_req_re_enumerate:1434: getting device descriptor at addr 2 faile= d! > > ugen0.2: <> at usbus0 (disconnected) > > after loading ng_ubt: > > uhub_reattach_port:413: could not allocate new device! > > ubt0: > 2.00/1.00, addr 2> on usbus2 ^^^^^^^^^^ > > internal bluetooth device > > WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() > > WARNING: attempt to net_add_domain(netgraph) after domainfinalize() > > ugen0.2: at usbus0 > > ubt1: > 2.00/48.39, addr 2> on usbus0 ubt1: ubt_bulk_read_callback:837: bulk-in > > transfer failed: USB_ERR_STALLED ubt1: ubt_intr_read_callback:741: > > interrupt transfer failed: USB_ERR_STALLED ubt1: at uhub0, port 1, addr= 2 > > (disconnected) > > ugen0.2: at usbus0 (disconnected) > > device re-inserted: > > usb2_alloc_device:1480: set address 2 failed (ignored) > > usb2_alloc_device:1516: getting device descriptor at addr 2 failed! > > usb2_req_re_enumerate:1421: addr=3D2, set address failed! (ignored) > > usb2_req_re_enumerate:1434: getting device descriptor at addr 2 faile= d! > > usb2_req_re_enumerate:1421: addr=3D2, set address failed! (ignored) > > usb2_req_re_enumerate:1434: getting device descriptor at addr 2 faile= d! > > ugen0.2: <> at usbus0 (disconnected) > > uhub_reattach_port:413: could not allocate new device! > > > > So the device is no longer recognized after I re-connect it. usbconfig = does > > not show it: ugen0.1: at usbus0, cfg=3D0 md=3DHOST > > spd=3DFULL (12Mbps) pwr=3DON ugen1.1: at usbus1, = cfg=3D0 > > md=3DHOST spd=3DFULL (12Mbps) pwr=3DON ugen2.1: a= t usbus2, > > cfg=3D0 md=3DHOST spd=3DFULL (12Mbps) pwr=3DON ugen3.1: at > > usbus3, cfg=3D0 md=3DHOST spd=3DFULL (12Mbps) pwr=3DON ugen4.1: > Intel> at usbus4, cfg=3D0 md=3DHOST spd=3DHIGH (480Mbps) pwr=3DON ugen2= =2E2: > Bluetooth 2.0 plus EDR Broadcom Corp> at usbus2, cfg=3D0 md=3DHOST spd= =3DFULL > > (12Mbps = =20 > > pwr=3DON > > > > It only lists the internal device... > > > > My CURRENT was compiled two days ago, so I should be up-to-date. >=20 > Does it work when you use an external USB HUB? >=20 > Does this device have some kind of autoinstall on it? >=20 > You could try enabling uhci/ehci debugging. > sysctl hw.usb2.uhci.debug =3D 15 >=20 > Then we would know the exact cause of the error. Just for your info: Aug 10 15:21:45 milhouse kernel: ubt1: on usbus3 Aug 10 15:21:45 milhouse devd: Executing '/etc/rc.d/bluetooth quietstart ub= t1' After 4 years, the device now works without an external hub. ;-)) Lars --Kg2J3k9IiiSZbiqb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlIGPp8ACgkQKc512sD3afhiigCgkPl+RABCQj3XQvrjFyFU/7Cp 0CIAoLPB+wkWQXd0/ImE+fGQpbT//SLH =6p8/ -----END PGP SIGNATURE----- --Kg2J3k9IiiSZbiqb-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 13:39:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 96FC230A; Sat, 10 Aug 2013 13:39:55 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 007932C58; Sat, 10 Aug 2013 13:39:54 +0000 (UTC) Received: by mail-bk0-f51.google.com with SMTP id mx10so1384280bkb.10 for ; Sat, 10 Aug 2013 06:39:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-type:content-transfer-encoding; bh=TN2ZKDDujANIpXljE/9/IxkkMcvyMHKi2gsQp4XaS90=; b=LjhvGdZK22a8t9HhJeDz6GWwrDxh5zDtD7lvVYwqUSLb74WimynLwWXqKDPvo+Kfiy 2cb+SgHCcvA9tA4X5hNTm0ykk3h9671V3No9rDRfxhiN5v4T3DP6V/g9P3CkzJ8GtmFh EjG3nUUi5jxOi3doxmsuWClArhnOYN4OGXe6kUwz5jgiVZBxLac3ZjsyfLDa7F/aFqoM VDidEQLhqf2910g7OfiPEmBq4RzX2/TtY2Wl62phPCd87sGh8x6DvX2rd28hCAtBRR4k odoFNaXKQpY0N9dUplRa53V3+hWBu4ENzlaRauDAgjH/JEn/Mm8PXKAGfHFZqfVCV8fs 1GFg== X-Received: by 10.204.229.208 with SMTP id jj16mr2630031bkb.65.1376141991914; Sat, 10 Aug 2013 06:39:51 -0700 (PDT) Received: from ernst.home (p4FCA6A8C.dip0.t-ipconnect.de. [79.202.106.140]) by mx.google.com with ESMTPSA id ct12sm4054488bkb.12.2013.08.10.06.39.50 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 10 Aug 2013 06:39:51 -0700 (PDT) Date: Sat, 10 Aug 2013 15:39:48 +0200 From: Gary Jennejohn To: "O. Hartmann" Subject: Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present Message-ID: <20130810153948.1c853981@ernst.home> In-Reply-To: <20130810145922.1bc18c5a@thor.walstatt.dyndns.org> References: <20130808201018.1215f733@munin.geoinf.fu-berlin.de> <1375997961.1451.3.camel@localhost> <20130809073251.376c9206@munin.geoinf.fu-berlin.de> <20130809171237.GN1746@albert.catwhisker.org> <20130810103705.022ce7be@ernst.home> <52060390.1040505@gwdg.de> <20130810113119.3f44ae32@ernst.home> <20130810145922.1bc18c5a@thor.walstatt.dyndns.org> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.17; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD Ports , FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 13:39:55 -0000 On Sat, 10 Aug 2013 14:59:22 +0200 "O. Hartmann" wrote: > On Sat, 10 Aug 2013 11:31:19 +0200 > Gary Jennejohn wrote: > > > On Sat, 10 Aug 2013 11:10:40 +0200 > > Rainer Hurling wrote: > > > > > Yes, I can confirm, that it builds, installs and runs fine for me. > > > > > > The patch should be placed as > > > x11/nvidia-driver/files/patch-src__nvidia_subr.c, shoudn't it? > > > > > > Many thanks for this work. > > > > > > > Thanks for testing. > > > > Yes, putting the patch into files/ with that name works also and > > is much simpler than the steps I outlined. > > > > > Placing the patch in files as recommended here doesn't play well with > the obvious intention of the REINPLACE command: > > the patch only applies to 319.25. > > I use the cutting edge 325.15. The patch doesn't apply since some lines > shifted - here comes the tricky REINPLACE part of the Makefile in place. > > I simply adapted your patches discussed and introduced here and > "adapted" the REINPLACE statements/pattern around line 160 in the > toplevel Makefile of port x11/nvidia-driver. > > Find the patch attached - I forgot to raise PORTREVISION=1. > > I'm now sending this email from the prior crashing box with the patch > discussed applied via the Makefile to 325.15. > > Thanks a lot for the fast help. > Yes, this is a better approach. I made my patch before realizing that the REINPLACE_CMD was the source of the errors. Any real advantage to using 325.15? You should submit a PR with this patch. -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 14:01:10 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 44D8ED47; Sat, 10 Aug 2013 14:01:10 +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]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F32462E02; Sat, 10 Aug 2013 14:01:09 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) with esmtp (envelope-from ) id <1V89jA-002v5r-LK>; Sat, 10 Aug 2013 16:01:08 +0200 Received: from g225187188.adsl.alicedsl.de ([92.225.187.188] helo=munin.geoinf.fu-berlin.de) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) with esmtpsa (envelope-from ) id <1V89jA-000tIq-GR>; Sat, 10 Aug 2013 16:01:08 +0200 Date: Sat, 10 Aug 2013 16:04:59 +0200 From: "O. Hartmann" To: gljennjohn@googlemail.com Subject: Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present Message-ID: <20130810160459.725cc4a9@munin.geoinf.fu-berlin.de> In-Reply-To: <20130810153948.1c853981@ernst.home> References: <20130808201018.1215f733@munin.geoinf.fu-berlin.de> <1375997961.1451.3.camel@localhost> <20130809073251.376c9206@munin.geoinf.fu-berlin.de> <20130809171237.GN1746@albert.catwhisker.org> <20130810103705.022ce7be@ernst.home> <52060390.1040505@gwdg.de> <20130810113119.3f44ae32@ernst.home> <20130810145922.1bc18c5a@thor.walstatt.dyndns.org> <20130810153948.1c853981@ernst.home> Organization: FU Berlin X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd9.2) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/YRSdXm/SuDovAH02XcdUQm0"; protocol="application/pgp-signature" X-Originating-IP: 92.225.187.188 Cc: FreeBSD CURRENT , FreeBSD Ports 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: Sat, 10 Aug 2013 14:01:10 -0000 --Sig_/YRSdXm/SuDovAH02XcdUQm0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 10 Aug 2013 15:39:48 +0200 Gary Jennejohn wrote: > On Sat, 10 Aug 2013 14:59:22 +0200 > "O. Hartmann" wrote: >=20 > > On Sat, 10 Aug 2013 11:31:19 +0200 > > Gary Jennejohn wrote: > >=20 > > > On Sat, 10 Aug 2013 11:10:40 +0200 > > > Rainer Hurling wrote: > > >=20 > > > > Yes, I can confirm, that it builds, installs and runs fine for > > > > me. > > > >=20 > > > > The patch should be placed as > > > > x11/nvidia-driver/files/patch-src__nvidia_subr.c, shoudn't it? > > > >=20 > > > > Many thanks for this work. > > > >=20 > > >=20 > > > Thanks for testing. > > >=20 > > > Yes, putting the patch into files/ with that name works also and > > > is much simpler than the steps I outlined. > > >=20 > >=20 > >=20 > > Placing the patch in files as recommended here doesn't play well > > with the obvious intention of the REINPLACE command: > >=20 > > the patch only applies to 319.25. > >=20 > > I use the cutting edge 325.15. The patch doesn't apply since some > > lines shifted - here comes the tricky REINPLACE part of the > > Makefile in place. > >=20 > > I simply adapted your patches discussed and introduced here and > > "adapted" the REINPLACE statements/pattern around line 160 in the > > toplevel Makefile of port x11/nvidia-driver. > >=20 > > Find the patch attached - I forgot to raise PORTREVISION=3D1. > >=20 > > I'm now sending this email from the prior crashing box with the > > patch discussed applied via the Makefile to 325.15. > >=20 > > Thanks a lot for the fast help. > >=20 >=20 > Yes, this is a better approach. I made my patch before realizing > that the REINPLACE_CMD was the source of the errors. >=20 > Any real advantage to using 325.15? Well, nvidia claims they have fixed bugs and it is the successor in line after 319.25. It is stable, it is the newest, it is so far nice :-) >=20 > You should submit a PR with this patch. >=20 Well, I do. I thought it isn't my honour since I simply made a profit from the labor of others here and I simply picked up crumps. Well, I added a followup to port/181144. Oliver --Sig_/YRSdXm/SuDovAH02XcdUQm0 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBAgAGBQJSBkiQAAoJEOgBcD7A/5N8IYwIAJ4qw8tpbLqLtBrIm8/CdEFI +8r3KODlwsmBfLXkW8Pk7OeR99dL43MrYATuZV2U30XwYHK4A/iHpJH5I23Npeog K6QmDRiLvyvBgVThaElRUdJrSELPOKUDv28XObGPZ09oPf62hdznitOq2jD2mAPW WTFizAPicZ9X2IPwOtp85SjsrKGcToQ2ku0GjCB7/apvmv1Aqvn4FeTbZnJ0/P4G mLF5jgb6+MjoceXh1vxeCeYCz72ZDikng7Ivw+yjYoXx3DpWtBf1Y+xabxTaxajM s8b/e54VOE+YcBs1+mALTztDe73+FXioCKzx3DIF5wGf+IaMHObN+xX9RrH5TZg= =1QvD -----END PGP SIGNATURE----- --Sig_/YRSdXm/SuDovAH02XcdUQm0-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 14:02:13 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1ED46FC9; Sat, 10 Aug 2013 14:02:13 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id D84152E1C; Sat, 10 Aug 2013 14:02:12 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:acd9:718:8db4:b823]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 771454AC1C; Sat, 10 Aug 2013 18:02:10 +0400 (MSK) Date: Sat, 10 Aug 2013 18:02:03 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <602958881.20130810180203@serebryakov.spb.ru> To: freebsd-current@FreeBSD.org, freebsd-embedded@FreeBSD.org Subject: Re: nanobsd-built system doesn't have SVN revision in "uname" (and it looks like regression) In-Reply-To: <37152758.20130810151846@serebryakov.spb.ru> References: <383656436.20130810150849@serebryakov.spb.ru> <37152758.20130810151846@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@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: Sat, 10 Aug 2013 14:02:13 -0000 Hello, Freebsd-current. You wrote 10 =D0=B0=D0=B2=D0=B3=D1=83=D1=81=D1=82=D0=B0 2013 =D0=B3., 15:18= :46: LS>> Latest revisions of -CURRENT built with "nanobsd" script haven't revi= sion LS>> in "uname -a" output: LS>> FreeBSD gateway.home.serebryakov.spb.ru 10.0-CURRENT FreeBSD LS>> 10.0-CURRENT #0: Sat Aug 10 14:17:32 MSK 2013 =20 LS>> root@fbsd-c-64.vm.home.serebryakov.spb.ru:/data/obj.nano/gateway.v2/da= ta/src/sys/D2500CC amd64 LS>> System was built from "/data/src" directory, which IS subversion work= ing LS>> copy and `svn' and `svnversion' PRESENTS in $PATH. LS> Ok, problem is, that "svnliteversion" presents too, but WC version is = old LS> one (for 1.7.x). I'm not sure, is this bug worth fixing. Nope, upgrading working copy doesn't help :((( --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 14:03:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2C76F1C0; Sat, 10 Aug 2013 14:03:32 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 746E12E3F; Sat, 10 Aug 2013 14:03:31 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id j13so499875wgh.3 for ; Sat, 10 Aug 2013 07:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=7jlMC7eZOchLVE1UaAJLG/V4pHa+nWytjY+fGgQvZS8=; b=bBiwY/JKNKJ5qacvSi7LgCbUxo+ZFOBajnuz7TZxxw4D+A5Ox2A7NuV6XqwgpUTYvl ahYHKShITxzvDbOL4n01ByUvbf/N8/xRmZW3dzYAlgl3wHYBk14MeXM/rCvtB0t77uGi LFCNiKvG9I3d745hm47dWoah/pTRwlL0TDalGHeeWmfpP5Z973ijaG3QnFT22cdxtgWm W+A/emeB7mF+Ud//7vA+8cvr0AqWIQq+fMvuVa612c1SLzcaKq/cbkfP1fH1uO3G/7QP ZH0f5T9Fm1X/UTINWrTsJsJ+w9dJk+oWzynq3WOpsdL3zgUYQgdJJiErIBqS32S9ZpH/ CVwQ== MIME-Version: 1.0 X-Received: by 10.180.211.206 with SMTP id ne14mr4401246wic.30.1376143409734; Sat, 10 Aug 2013 07:03:29 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.116.136 with HTTP; Sat, 10 Aug 2013 07:03:29 -0700 (PDT) In-Reply-To: <602958881.20130810180203@serebryakov.spb.ru> References: <383656436.20130810150849@serebryakov.spb.ru> <37152758.20130810151846@serebryakov.spb.ru> <602958881.20130810180203@serebryakov.spb.ru> Date: Sat, 10 Aug 2013 07:03:29 -0700 X-Google-Sender-Auth: Dh_BRK9fL87V4zkwUOQPZ0VX3Ws Message-ID: Subject: Re: nanobsd-built system doesn't have SVN revision in "uname" (and it looks like regression) From: Adrian Chadd To: lev@freebsd.org Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-embedded@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: Sat, 10 Aug 2013 14:03:32 -0000 Try running the svnlite version of svn upgrade. (svnlite upgrade) -adrian On 10 August 2013 07:02, Lev Serebryakov wrote: > Hello, Freebsd-current. > You wrote 10 =C1=D7=C7=D5=D3=D4=C1 2013 =C7., 15:18:46: > > LS>> Latest revisions of -CURRENT built with "nanobsd" script haven't re= vision > LS>> in "uname -a" output: > LS>> FreeBSD gateway.home.serebryakov.spb.ru 10.0-CURRENT FreeBSD > LS>> 10.0-CURRENT #0: Sat Aug 10 14:17:32 MSK 2013 > LS>> root@fbsd-c-64.vm.home.serebryakov.spb.ru:/data/obj.nano/gateway.v2/= data/src/sys/D2500CC amd64 > LS>> System was built from "/data/src" directory, which IS subversion wo= rking > LS>> copy and `svn' and `svnversion' PRESENTS in $PATH. > LS> Ok, problem is, that "svnliteversion" presents too, but WC version i= s old > LS> one (for 1.7.x). I'm not sure, is this bug worth fixing. > Nope, upgrading working copy doesn't help :((( > > -- > // Black Lion AKA Lev Serebryakov > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 14:13:27 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C4F64A81; Sat, 10 Aug 2013 14:13:27 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 971352EBD; Sat, 10 Aug 2013 14:13:27 +0000 (UTC) Received: from glenbarber.us (nucleus.glenbarber.us [IPv6:2001:470:8:1205:2:2:ff:29]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id D6C4EC935; Sat, 10 Aug 2013 14:13:25 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us D6C4EC935 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Sat, 10 Aug 2013 10:13:24 -0400 From: Glen Barber To: Adrian Chadd Subject: Re: nanobsd-built system doesn't have SVN revision in "uname" (and it looks like regression) Message-ID: <20130810141324.GD2432@glenbarber.us> References: <383656436.20130810150849@serebryakov.spb.ru> <37152758.20130810151846@serebryakov.spb.ru> <602958881.20130810180203@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TybLhxa8M7aNoW+V" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: lev@freebsd.org, freebsd-embedded@freebsd.org, 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: Sat, 10 Aug 2013 14:13:28 -0000 --TybLhxa8M7aNoW+V Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hmm. I suspect r254094 is to blame here, although I did extensive testing with different svn versions before the commit. :( I'll take another look at this, in case I missed an edge case. Glen On Sat, Aug 10, 2013 at 07:03:29AM -0700, Adrian Chadd wrote: > Try running the svnlite version of svn upgrade. >=20 > (svnlite upgrade) >=20 >=20 >=20 > -adrian >=20 > On 10 August 2013 07:02, Lev Serebryakov wrote: > > Hello, Freebsd-current. > > You wrote 10 =D0=B0=D0=B2=D0=B3=D1=83=D1=81=D1=82=D0=B0 2013 =D0=B3., 1= 5:18:46: > > > > LS>> Latest revisions of -CURRENT built with "nanobsd" script haven't = revision > > LS>> in "uname -a" output: > > LS>> FreeBSD gateway.home.serebryakov.spb.ru 10.0-CURRENT FreeBSD > > LS>> 10.0-CURRENT #0: Sat Aug 10 14:17:32 MSK 2013 > > LS>> root@fbsd-c-64.vm.home.serebryakov.spb.ru:/data/obj.nano/gateway.v= 2/data/src/sys/D2500CC amd64 > > LS>> System was built from "/data/src" directory, which IS subversion = working > > LS>> copy and `svn' and `svnversion' PRESENTS in $PATH. > > LS> Ok, problem is, that "svnliteversion" presents too, but WC version= is old > > LS> one (for 1.7.x). I'm not sure, is this bug worth fixing. > > Nope, upgrading working copy doesn't help :((( > > > > -- > > // Black Lion AKA Lev Serebryakov > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" > _______________________________________________ > 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" --TybLhxa8M7aNoW+V Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBCAAGBQJSBkqEAAoJEFJPDDeguUajnREH/0X+BJ5oAlTmT7L6A5pUEW/E Ce1Sr25UF9UzO0GxfZGniZ8vYZiiX+YMgsiQum0u/dVtk4CJ9x0JDOsZM8hxeCEw SWtacES6XYoLh/ya3Opt5d/kKLUdHeaTPG31UnkGRhbUYB0sJWEkRGo4Xl4eKauF VlJvOI6jT2YcpTxHjcG4ZIJ7aiDmGbvNEQHE62ZzJZ5E39E+eSuFh9FPHKku5yfm LuTSUgRd1BGnotg/LTyGb769gVTHtlFvJUoH2ReQJrNIPkBFPdEOZLV1SkMBYA6G aCM2Pl9JcCGLYqsqZD1VtglE8Z5hna94cm563S9j8m+wEGvTvZBBl7E8SAKe8v8= =5TVQ -----END PGP SIGNATURE----- --TybLhxa8M7aNoW+V-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 15:08:53 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 97193F9F for ; Sat, 10 Aug 2013 15:08:53 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5C0542134 for ; Sat, 10 Aug 2013 15:08:53 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:acd9:718:8db4:b823]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id EAFA54AC57 for ; Sat, 10 Aug 2013 19:08:51 +0400 (MSK) Date: Sat, 10 Aug 2013 19:08:45 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1494493349.20130810190845@serebryakov.spb.ru> To: "current@freebsd.org" Subject: Re: loader don't load loader.conf if device.hints has errors In-Reply-To: <1388219877.20130810150157@serebryakov.spb.ru> References: <1388219877.20130810150157@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@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: Sat, 10 Aug 2013 15:08:53 -0000 Hello, Lev. You wrote 10 =D0=B0=D0=B2=D0=B3=D1=83=D1=81=D1=82=D0=B0 2013 =D0=B3., 15:01= :57: LS> Hello, Current. LS> I've make simple mistake (DOS-style EOL) in /boot/device.hints and LS> /boot/loader.conf was skipped too with strange (device.hints-related) LS> message: LS> FreeBSD/x86 bootstrap loader, Revision 1.1 LS> (root@fbsd-c-64.vm.home.serebryakov.spb.ru, Sat Aug 10 14:02:41 MSK 201= 3) LS> Loading /boot/defaults/loader.conf LS> Warning: syntax error on file /boot/device.hints LS> hint.uart.0.flags=3D"0x00" LS> ^ LS> Warning: syntax error on file /boot/loader.conf LS> hint.uart.0.flags=3D"0x00" LS> ^ LS> /boot/kernel/kernel text=3D0x5dfed8 data=3D0x69078+0xd6b10 syms=3D[0x8+= 0x9cd50+0x8+0x930ab] Also, loader doesn't say anything about reading "/boot/device.hints" and "/boot/loader.conf", but it reads them for sure: FreeBSD/x86 bootstrap loader, Revision 1.1 (root@fbsd-c-64.vm.home.serebryakov.spb.ru, Sat Aug 10 18:35:18 MSK 2013) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=3D0x5e5fb0 data=3D0x69cf8+0xd6c10 syms=3D[0x8+0x9d= b48+0x8+0x93be1] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... GDB: no debug ports present --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 15:13:47 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9C7AD31D; Sat, 10 Aug 2013 15:13:47 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5EBB4218B; Sat, 10 Aug 2013 15:13:47 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:acd9:718:8db4:b823]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 1196E4AC1C; Sat, 10 Aug 2013 19:13:45 +0400 (MSK) Date: Sat, 10 Aug 2013 19:13:39 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <529930061.20130810191339@serebryakov.spb.ru> To: Glen Barber Subject: Re: nanobsd-built system doesn't have SVN revision in "uname" (and it looks like regression) In-Reply-To: <20130810141324.GD2432@glenbarber.us> References: <383656436.20130810150849@serebryakov.spb.ru> <37152758.20130810151846@serebryakov.spb.ru> <602958881.20130810180203@serebryakov.spb.ru> <20130810141324.GD2432@glenbarber.us> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@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: Sat, 10 Aug 2013 15:13:47 -0000 Hello, Glen. You wrote 10 =D0=B0=D0=B2=D0=B3=D1=83=D1=81=D1=82=D0=B0 2013 =D0=B3., 18:13= :24: GB> Hmm. I suspect r254094 is to blame here, although I did extensive GB> testing with different svn versions before the commit. :( GB> I'll take another look at this, in case I missed an edge case. It doesn't look like edge case... Sources in /data/src. It is SVN WC. # cd /data/src && svnversion 254178M # cd /data/src && svnliteversion 254178M # "host" system is -CURRENT too, already without revision in uname -a output (!), from Sat Jul 20. System is built with nanobsd script, but it looks like nanobsd.sh doesn't do any special here. It sets MAKEOBJDIRPREFIX to /data/obj.nano/gateway.v2 and call: env TARGET_ARCH=3Damd64 make -j4 __MAKE_CONF=3D/some/path/to/generated/make= .conf buildworld Generated make.conf looks like: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D XCC=3D/usr/bin/cc XCXX=3D/usr/bin/c++ XCPP=3D/usr/bin/cpp COMPILER_TYPE=3Dclang MALLOC_PRODUCTION=3Dyes BOOT_COMCONSOLE_SPEED=3D115200 BOOT_COMCONSOLE_PORT=3D0x2E8 WITHOUT_ACCT=3Dyes WITHOUT_ACPI=3Dyes WITHOUT_AMD=3Dyes WITHOUT_APM=3Dyes WITHOUT_ATM=3Dyes WITHOUT_AUDIT=3Dyes WITHOUT_AUTHPF=3Dyes WITHOUT_BIND_DNSSEC=3Dyes WITHOUT_CALENDAR=3Dyes WITHOUT_CDDL=3Dyes WITHOUT_CLANG=3Dyes WITHOUT_CROSS_COMPILER=3Dyes WITHOUT_CTM=3Dyes WITHOUT_DICT=3Dyes WITHOUT_EXAMPLES=3Dyes WITHOUT_FLOPPY=3Dyes WITHOUT_FREEBSD_UPDATE=3Dyes WITHOUT_GAMES=3Dyes WITHOUT_GCC=3Dyes WITHOUT_GCOV=3Dyes WITHOUT_GDB=3Dyes WITHOUT_GPIB=3Dyes WITHOUT_GPIO=3Dyes WITHOUT_GROFF=3Dyes WITHOUT_GSSAPI=3Dyes WITHOUT_HTML=3Dyes WITHOUT_INFO=3Dyes WITHOUT_IPFILTER=3Dyes WITHOUT_IPX=3Dyes WITHOUT_JAIL=3Dyes WITHOUT_LEGACY_CONSOLE=3Dyes WITHOUT_LIB32=3Dyes WITHOUT_LOCALES=3Dyes WITHOUT_LOCATE=3Dyes WITHOUT_LPR=3Dyes WITHOUT_KERBEROS=3Dyes WITHOUT_KERBEROS_SUPPORT=3Dyes WITHOUT_MAN=3Dyes WITHOUT_NCP=3Dyes WITHOUT_NDIS=3Dyes WITHOUT_NIS=3Dyes WITHOUT_NLS=3Dyes WITHOUT_NLS_CATALOGS=3Dyes WITHOUT_NS_CACHING=3Dyes WITHOUT_OBJC=3Dyes WITHOUT_PC_SYSINSTALL=3Dyes WITHOUT_PF=3Dyes WITHOUT_PORTSNAP=3Dyes WITHOUT_PROFILE=3Dyes WITHOUT_QUOTAS=3Dyes WITHOUT_RCMDS=3Dyes WITHOUT_RCS=3Dyes WITHOUT_ROUTED=3Dyes WITHOUT_SHAREDOCS=3Dyes WITHOUT_SVNLITE=3Dyes WITHOUT_SYSCONS=3Dyes WITHOUT_ZFS=3Dyes SRCCONF=3D/dev/null =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 16:51:11 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BBBB6E78 for ; Sat, 10 Aug 2013 16:51:11 +0000 (UTC) (envelope-from bryan-lists@shatow.net) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6E0A9256E for ; Sat, 10 Aug 2013 16:51:11 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sweb; b=w0LoY4 WxC1sET+gIhucqgQz8Vx6Gp7VlLRcfxzAOWf6k4zssKYZL9gOfufyUfbwjKCc7WF 6tGO64dEPi0HR9UlHz9L+Y9orr1AnmeCSmwwzXwpZ4wrM1RAzzEy6JqwJQ06n192 /dFndBh93jNd4momHNLUGWfql7dDUGMJnCYZ0= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sweb; bh=WrOpQbAVk9W3 ucmBTyrxDVWKWDwTJjF+uD91jP5B18s=; b=if+tSiyHYxmHa8je3JW/DKNl6csP h4z2JI8WzuIt/TRIIsgonF+mvwvSLEHv4x2PluU+Y3ssVxT3pLXmAoCZsjhB1BIC +JVT4nW0yxZdLCfuG2WYwlI2YNGLioH6MM4JMzdil/kZiRdX8Q1ioBA0tACBmu08 rtAS2rBLjRomV7A= Received: (qmail 12516 invoked from network); 10 Aug 2013 11:44:28 -0500 Received: from unknown (HELO ?10.10.0.24?) (bryan@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 10 Aug 2013 11:44:28 -0500 Message-ID: <52066DE0.2060305@shatow.net> Date: Sat, 10 Aug 2013 11:44:16 -0500 From: Bryan Drewery User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: current@freebsd.org Subject: Re: panic on boot with fresh current References: <20130810112410.GA27286@devbox.vnode.local> In-Reply-To: <20130810112410.GA27286@devbox.vnode.local> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Joel Dahl 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: Sat, 10 Aug 2013 16:51:11 -0000 On 8/10/2013 6:24 AM, Joel Dahl wrote: > Hi, > > I just rebuilt a fresh current on my laptop. It panics on boot with: > > panic: witness_init: pending locks list is too small, increase > WITNESS_PENDLIST > > I'm in a hurry right now so I can't gather much more info at the moment, but I > thought I'd mention it. > I also get this. The last stable revision for me was r254150 -- Regards, Bryan Drewery From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 17:15:48 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EF2B69EC for ; Sat, 10 Aug 2013 17:15:48 +0000 (UTC) (envelope-from bryan-lists@shatow.net) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A78A9266B for ; Sat, 10 Aug 2013 17:15:48 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sweb; b=RzJytC RFiGu6ATwHOKDDjUWgk1i6rzymAJZXdUG7NDm5SlvdvYfQ2nUYaP9kIbQFn/il32 9YHwq7fyJ2gTd+ZJ9rUfqtdB/HWYsPwYUW9N3rgBCXMTiTXQDdDoMpLntlojQEX6 bgoxP63XjnBxbgsSzMImZEtcEiefp0MF9xGiI= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sweb; bh=qEIFoJMER3jU w7+cIVUjJSdqzueGntRJN9ErFzY9/gw=; b=PqFtQCBm2CvyLyFCTBSrsRMafIrM TEq4Gj+5ZUffWF1M/T06FAKuJWVBjUJ3t+e1FOuYasblVJdUFIrMDqlWUO3esZyT oI3hbFfu8lUCKuBXVcX5nmAtGfC7c1UgoG1jp+bB0tSKTwd2/Met3vVan8GPCdIj tcI80C51gMLLTs0= Received: (qmail 58076 invoked from network); 10 Aug 2013 12:15:46 -0500 Received: from unknown (HELO ?10.10.0.24?) (bryan@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 10 Aug 2013 12:15:46 -0500 Message-ID: <52067537.2070309@shatow.net> Date: Sat, 10 Aug 2013 12:15:35 -0500 From: Bryan Drewery User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: panic on boot with fresh current References: <20130810112410.GA27286@devbox.vnode.local> <52066DE0.2060305@shatow.net> In-Reply-To: <52066DE0.2060305@shatow.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Sat, 10 Aug 2013 17:15:49 -0000 On 8/10/2013 11:44 AM, Bryan Drewery wrote: > On 8/10/2013 6:24 AM, Joel Dahl wrote: >> panic: witness_init: pending locks list is too small, increase >> WITNESS_PENDLIST > I also get this. The last stable revision for me was r254150 r254150 stable, r254171 panic. backtrace: https://dl.dropboxusercontent.com/u/8732004/r254171-panic.jpg -- Regards, Bryan Drewery From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 17:33:21 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C833DE27 for ; Sat, 10 Aug 2013 17:33:21 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vb0-x22c.google.com (mail-vb0-x22c.google.com [IPv6:2607:f8b0:400c:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 831CF2743 for ; Sat, 10 Aug 2013 17:33:21 +0000 (UTC) Received: by mail-vb0-f44.google.com with SMTP id e13so4810988vbg.31 for ; Sat, 10 Aug 2013 10:33:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=zRycCVRmLt8cHuab2RnqARV/bo8NvyzOFSRVuBr7Vsk=; b=NwSR+SWKbpUQZhooQruxrRwZX5rmoJcgYBU1cnjnngGGBOxy855C/LjkG7OiXh7cZT nynEKtYHoWR7a/SIgxhcLMCFfek4tTg31kzuCsJx4VL7/MF6csK9nSKyT2NxbqJ7YAYP w1+ta4WhGpuyMj7KIy5tpm3gtuZZWcwB8Z+H0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=zRycCVRmLt8cHuab2RnqARV/bo8NvyzOFSRVuBr7Vsk=; b=eF391Ts0/FvdLWEJ0KGsSLPOgyMAuXp2fIh2O888UU5cYlHKZsPLq0x0XSeQoWu5X4 bMmpzN7T528zGjsmfBqHSA3+MJCIefiDn/UmxOK+TZfjaDq2R3qkYQFLEUyznvT3GwWK hiwOcthtL+pI/z2uKzszvAl9jXOgH/y2uCBHLJ6ZNLnYrvjN50L8CnzpxG45m7m6JNU+ p1qWdImOmTaKl2fSnBFsKG2VRyoW+FlQvt7covBK2tXJFfg+0ZJ2RwmJF3mlXjcyAUuT UjXiwhHRX21LbZ6reI9rzHgh8zlGMyXI1zkmD7GQz2IHxJrZsxcIlIBHv8leU7kwLSAl r2IA== X-Gm-Message-State: ALoCoQlfgJ/3E/9qPCJwjtQpSznXvMI07AESNYmcJZ1WnSU9bWXrL6H4TBJuR/Q58r7g7+Y2HCX0 MIME-Version: 1.0 X-Received: by 10.59.2.167 with SMTP id bp7mr3034720ved.67.1376156000310; Sat, 10 Aug 2013 10:33:20 -0700 (PDT) Received: by 10.220.167.74 with HTTP; Sat, 10 Aug 2013 10:33:20 -0700 (PDT) Date: Sat, 10 Aug 2013 10:33:20 -0700 Message-ID: Subject: Fun with nvi From: Peter Wemm To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 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: Sat, 10 Aug 2013 17:33:21 -0000 I've been tinkering with the nvi refresh from the GSoC in 2011, aka nvi2. https://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/zy/1 https://github.com/lichray/nvi2 The goal was to update the multibyte handling in nvi-1.79 (the one we have in our tree) in such a way we could import it. Anyway.. an early WIP: http://people.freebsd.org/~peter/nvi2.tgz peter@overcee[ 9:37AM]~/head/contrib/nvi/catalog-1643> echo $LANG en_US.UTF-8 peter@overcee[ 9:38AM]~/head/contrib/nvi/catalog-1644> vi -c 'set fileencoding=GB2312' zh_CN.GB2312.base .. leads to fun things like: http://people.freebsd.org/~peter/nvi2-transcoding.png that's editing the file in GB2312 format, but converting to utf-8 on the fly for my terminal. This is with the WITH_ICONV=yes in make.conf. nvi2 will build without it but obviously won't be able to work with non-default encoding methods. In straight up UTF-8 mode: http://people.freebsd.org/~peter/nvi2-utf8-4.png How to use the tarball.. 1) rm -rf contrib/nvi usr.bin/vi 2) extract tarball into src tree 3) patch -p0 < nvi.diff (this adds a built-tool to world) Note that I haven't actually done a buildworld yet. I've just been building it directly from src/usr.bin/vi with make obj && make depend && make all && make install .. to save time. But you'll need to have WITH_ICONV=yes in make.conf to do the fancy stuff. Note that the ports tree is a long way from being WITH_ICONV=yes safe, so don't do this on an important machine. An example of the tweaks to make ports happier: http://people.freebsd.org/~peter/iconv.diff - that's not complete. Most of the ports tree was updated to use Mk/Uses/iconv.mk but there's still some oddballs scattered around in weird places. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV UTF-8: for when a ' just won\342\200\231t do. ZFS must be the bacon of file systems. "everything's better with ZFS" From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 17:44:13 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1B1DD480 for ; Sat, 10 Aug 2013 17:44:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 81E4A27A8 for ; Sat, 10 Aug 2013 17:44:12 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r7AHi7Ig065543; Sat, 10 Aug 2013 20:44:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r7AHi7Ig065543 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r7AHi7cW065542; Sat, 10 Aug 2013 20:44:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 10 Aug 2013 20:44:07 +0300 From: Konstantin Belousov To: Bryan Drewery Subject: Re: panic on boot with fresh current Message-ID: <20130810174407.GD4972@kib.kiev.ua> References: <20130810112410.GA27286@devbox.vnode.local> <52066DE0.2060305@shatow.net> <52067537.2070309@shatow.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Ql3x3BT2cR6kuqru" Content-Disposition: inline In-Reply-To: <52067537.2070309@shatow.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home 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: Sat, 10 Aug 2013 17:44:13 -0000 --Ql3x3BT2cR6kuqru Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 10, 2013 at 12:15:35PM -0500, Bryan Drewery wrote: > On 8/10/2013 11:44 AM, Bryan Drewery wrote: > > On 8/10/2013 6:24 AM, Joel Dahl wrote: > >> panic: witness_init: pending locks list is too small, increase > >> WITNESS_PENDLIST > > I also get this. The last stable revision for me was r254150 >=20 > r254150 stable, r254171 panic. >=20 > backtrace: https://dl.dropboxusercontent.com/u/8732004/r254171-panic.jpg So could you point to exact commit which causes panic ? --Ql3x3BT2cR6kuqru Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJSBnvmAAoJEJDCuSvBvK1B/iIP/jBPAKi46F5KVK9TnRNImpPh E5/1cynWWIOB5YwlwgDw7G5QhYVFbG/XB638+Opm7Ktnlp7BF4qy24A4PgDrXXKU HixqL62sdsvyJD95JLsLh0GI7EFoMtU3C+CEX/NMWxydNdRqui1LZMjP4SlI6Hop tyuz3LD1zmd/5spntCkd/7jTNyRig1v1C6deN04Zma20bWF+4+ErMiZbxlaJIwMt 9kBjUYmnFOZ2gZ0DyoXNzdbgNUViNxkfSAFNi9/Pw5dcpMmj4kJnd2UZr+hclgOB MPRJbw+/4my2QDe9ISs68d+UEYqoG/9vFKV0pb0eT72AC0B0h9JX3y1yUOutqOU7 RPYKnCUO1vYQQGez7D2c9VuPwzTczhYRh43wFyL5VKGpJjl3oFwkV7eLZgHbTtqu v+/Xt+bi8GtkRjzJPGaUa4SMyDN1+/osVCCy/hHm/rKIV56hg/VyWV2JYt4UIVIx 0xYMP+ZxZIaDe7d1yaXb+GYGyUZ7ummHpHrJ+BceUDIX1TW6UYRZp0+eECz44TR6 clICyJ/N3xp1R8kzi2KvKPmFe4Papd/5JclEtuTqWHuV1QEt/E6FGELM4BsmQTgF erby7+6c0Bs6YwED9haTBHCNPLPgVWEEeJG8Qlc1PjpBWcPWFKd22N3cer/UjE6z ooa8bVgeGk1hBNW/vKPR =JmJx -----END PGP SIGNATURE----- --Ql3x3BT2cR6kuqru-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 17:45:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B229B5A7 for ; Sat, 10 Aug 2013 17:45:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2363227C2 for ; Sat, 10 Aug 2013 17:45:51 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r7AHjlPc066499; Sat, 10 Aug 2013 20:45:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r7AHjlPc066499 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r7AHjlrJ066497; Sat, 10 Aug 2013 20:45:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 10 Aug 2013 20:45:47 +0300 From: Konstantin Belousov To: Bryan Drewery Subject: Re: panic on boot with fresh current Message-ID: <20130810174547.GE4972@kib.kiev.ua> References: <20130810112410.GA27286@devbox.vnode.local> <52066DE0.2060305@shatow.net> <52067537.2070309@shatow.net> <20130810174407.GD4972@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QvmQhSMkm7STXBho" Content-Disposition: inline In-Reply-To: <20130810174407.GD4972@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home 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: Sat, 10 Aug 2013 17:45:52 -0000 --QvmQhSMkm7STXBho Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 10, 2013 at 08:44:07PM +0300, Konstantin Belousov wrote: > On Sat, Aug 10, 2013 at 12:15:35PM -0500, Bryan Drewery wrote: > > On 8/10/2013 11:44 AM, Bryan Drewery wrote: > > > On 8/10/2013 6:24 AM, Joel Dahl wrote: > > >> panic: witness_init: pending locks list is too small, increase > > >> WITNESS_PENDLIST > > > I also get this. The last stable revision for me was r254150 > >=20 > > r254150 stable, r254171 panic. > >=20 > > backtrace: https://dl.dropboxusercontent.com/u/8732004/r254171-panic.jpg >=20 > So could you point to exact commit which causes panic ? It is r254167, right ? --QvmQhSMkm7STXBho Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJSBnxKAAoJEJDCuSvBvK1BwisP/0xXtaRmiv9WqbPgojNF1Rid 0bCMBBxBCll1lUJEpys0XOpgdxbREcMThbUgnQLJqIsl+Ml4SjfYoqa30niJ9Zoy v/EUXbAsJbtK5hSBDt9VG7BQTc8YC+kAiL5T4aCTgle3e7+hQd+TuephiMPDx+85 9oPLDrql5zAszt4r+CJWtTZITwW7RV13OpFYHXRH13Vp/YhbSujef1tSWzqJs1Dj NY7wJh6S/a+gi9Jr3EEBRYkE3Wl1qUeZ4ZUrY6JyEdbjhZ40wNYj7feW3rZ8Hl+0 Izs2z2GqS+au47TNrgAwuNcpqZcUDqwNaw7AUMP3cd4miXpgKQr/rbgw1nqGNdUb AkfNxJ0iFYd9EsYmz2Zk1C7jZW433Gw6j7PhMVobI9qhd0CQxme3WPaNWdX45ONY 1pikkH6W1k92cO0vtuj9282qNzufgSFAo+3LozzRP8VgoqYNpKGoOb9sqI2MeepV 3lF9pIDlQ0Q3Asr64bojadCF4SmK0JhJYo47g5Tc7ibRzalRXpFPhTjkzXwNqLwf Oe6bDzKolDLcqXGKZNZi93sCdhA1r4MKh/ujR42TNsnbcsVKZF3mx92vr8UlQ0/+ 1DgJDPzFhZAuBfdtZSGDZ/8BjHrfxqLxIxk1YoEiObnZap4vedK7w0wf0Yf+mjid VC6v7uy2qc3bzMZwsoJR =k5rB -----END PGP SIGNATURE----- --QvmQhSMkm7STXBho-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 17:46:54 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 11C54799; Sat, 10 Aug 2013 17:46:54 +0000 (UTC) (envelope-from mack@macktronics.com) Received: from borg.macktronics.com (borg.macktronics.com [209.181.253.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D715927D5; Sat, 10 Aug 2013 17:46:53 +0000 (UTC) Received: from olive.macktronics.com (olive.macktronics.com [209.181.253.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by borg.macktronics.com (Postfix) with ESMTPS id 32DA1A5A; Sat, 10 Aug 2013 12:46:47 -0500 (CDT) Date: Sat, 10 Aug 2013 12:46:45 -0500 (CDT) From: Dan Mack To: Lev Serebryakov Subject: Re: nanobsd-built system doesn't have SVN revision in "uname" (and it looks like regression) In-Reply-To: <529930061.20130810191339@serebryakov.spb.ru> Message-ID: References: <383656436.20130810150849@serebryakov.spb.ru> <37152758.20130810151846@serebryakov.spb.ru> <602958881.20130810180203@serebryakov.spb.ru> <20130810141324.GD2432@glenbarber.us> <529930061.20130810191339@serebryakov.spb.ru> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Glen Barber , freebsd-current@freebsd.org, freebsd-embedded@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: Sat, 10 Aug 2013 17:46:54 -0000 Same problems here ... sometime after 10.0-CURRENT r253918 ... Two other systems stopped working and they have a mixture of svn / svnlite version combinations: working system: #1: ports svn installed at newer version root@borg:/usr/src # svnversion ; svnversion --version | head -1 253918 svnversion, version 1.8.0 (r1490375) root@borg:/usr/src # svnliteversion ; svnliteversion --version | head -1 253918 svnversion, version 1.8.1 (r1503906) root@borg:/usr/src # uname -a FreeBSD borg.example.com 10.0-CURRENT FreeBSD 10.0-CURRENT #3 r253918: Sat Aug 3 15:16:58 CDT 2013 root@borg.example.com:/usr/obj/usr/src/sys/MACKGEN amd64 Systems not working: #2: no ports svn installed root@olive:/usr/src # uname -a FreeBSD olive.example.com 10.0-CURRENT FreeBSD 10.0-CURRENT #5: Sat Aug 10 08:30:25 CDT 2013 root@olive.example.com:/usr/obj/usr/src/sys/MACKGEN amd64 root@olive:/usr/src # svnversion ; svnversion --version | head -1 svnversion: Command not found. svnversion: Command not found. root@olive:/usr/src # svnliteversion ; svnliteversion --version | head -1 254178 svnversion, version 1.8.1 (r1503906) #3: ports version installed at newer version root@darkstor:/usr/src # uname -a FreeBSD darkstor.example.com 10.0-CURRENT FreeBSD 10.0-CURRENT #7: Sat Aug 10 08:35:47 CDT 2013 root@darkstor.example.com:/usr/obj/usr/src/sys/MACKGEN amd64 root@darkstor:/usr/src # svnversion ; svnversion --version | head -1 254178 svnversion, version 1.8.0 (r1490375) root@darkstor:/usr/src # svnliteversion ; svnliteversion --version | head -1 254178 svnversion, version 1.8.1 (r1503906) Dan On Sat, 10 Aug 2013, Lev Serebryakov wrote: > Hello, Glen. > You wrote 10 ??????? 2013 ?., 18:13:24: > > GB> Hmm. I suspect r254094 is to blame here, although I did extensive > GB> testing with different svn versions before the commit. :( > GB> I'll take another look at this, in case I missed an edge case. > It doesn't look like edge case... > > Sources in /data/src. It is SVN WC. > > # cd /data/src && svnversion > 254178M > # cd /data/src && svnliteversion > 254178M > # > > > "host" system is -CURRENT too, already without revision in uname -a output > (!), from Sat Jul 20. > > System is built with nanobsd script, but it looks like nanobsd.sh doesn't > do any special here. It sets MAKEOBJDIRPREFIX to /data/obj.nano/gateway.v2 > and call: > > env TARGET_ARCH=amd64 make -j4 __MAKE_CONF=/some/path/to/generated/make.conf buildworld > > Generated make.conf looks like: > ======================================================================= > XCC=/usr/bin/cc > XCXX=/usr/bin/c++ > XCPP=/usr/bin/cpp > COMPILER_TYPE=clang > MALLOC_PRODUCTION=yes > BOOT_COMCONSOLE_SPEED=115200 > BOOT_COMCONSOLE_PORT=0x2E8 > WITHOUT_ACCT=yes > WITHOUT_ACPI=yes > WITHOUT_AMD=yes > WITHOUT_APM=yes > WITHOUT_ATM=yes > WITHOUT_AUDIT=yes > WITHOUT_AUTHPF=yes > WITHOUT_BIND_DNSSEC=yes > WITHOUT_CALENDAR=yes > WITHOUT_CDDL=yes > WITHOUT_CLANG=yes > WITHOUT_CROSS_COMPILER=yes > WITHOUT_CTM=yes > WITHOUT_DICT=yes > WITHOUT_EXAMPLES=yes > WITHOUT_FLOPPY=yes > WITHOUT_FREEBSD_UPDATE=yes > WITHOUT_GAMES=yes > WITHOUT_GCC=yes > WITHOUT_GCOV=yes > WITHOUT_GDB=yes > WITHOUT_GPIB=yes > WITHOUT_GPIO=yes > WITHOUT_GROFF=yes > WITHOUT_GSSAPI=yes > WITHOUT_HTML=yes > WITHOUT_INFO=yes > WITHOUT_IPFILTER=yes > WITHOUT_IPX=yes > WITHOUT_JAIL=yes > WITHOUT_LEGACY_CONSOLE=yes > WITHOUT_LIB32=yes > WITHOUT_LOCALES=yes > WITHOUT_LOCATE=yes > WITHOUT_LPR=yes > WITHOUT_KERBEROS=yes > WITHOUT_KERBEROS_SUPPORT=yes > WITHOUT_MAN=yes > WITHOUT_NCP=yes > WITHOUT_NDIS=yes > WITHOUT_NIS=yes > WITHOUT_NLS=yes > WITHOUT_NLS_CATALOGS=yes > WITHOUT_NS_CACHING=yes > WITHOUT_OBJC=yes > WITHOUT_PC_SYSINSTALL=yes > WITHOUT_PF=yes > WITHOUT_PORTSNAP=yes > WITHOUT_PROFILE=yes > WITHOUT_QUOTAS=yes > WITHOUT_RCMDS=yes > WITHOUT_RCS=yes > WITHOUT_ROUTED=yes > WITHOUT_SHAREDOCS=yes > WITHOUT_SVNLITE=yes > WITHOUT_SYSCONS=yes > WITHOUT_ZFS=yes > SRCCONF=/dev/null > ======================================================================= > > -- > // Black Lion AKA Lev Serebryakov > > _______________________________________________ > 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" dan -- Dan Mack From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 18:09:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8AF13AAD; Sat, 10 Aug 2013 18:09:22 +0000 (UTC) (envelope-from mack@macktronics.com) Received: from borg.macktronics.com (borg.macktronics.com [209.181.253.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5BE9928AD; Sat, 10 Aug 2013 18:09:22 +0000 (UTC) Received: from olive.macktronics.com (olive.macktronics.com [209.181.253.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by borg.macktronics.com (Postfix) with ESMTPS id 7518DA5F; Sat, 10 Aug 2013 13:09:21 -0500 (CDT) Date: Sat, 10 Aug 2013 13:09:20 -0500 (CDT) From: Dan Mack To: Lev Serebryakov Subject: Re: nanobsd-built system doesn't have SVN revision in "uname" (and it looks like regression) In-Reply-To: Message-ID: References: <383656436.20130810150849@serebryakov.spb.ru> <37152758.20130810151846@serebryakov.spb.ru> <602958881.20130810180203@serebryakov.spb.ru> <20130810141324.GD2432@glenbarber.us> <529930061.20130810191339@serebryakov.spb.ru> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Glen Barber , freebsd-current@freebsd.org, freebsd-embedded@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: Sat, 10 Aug 2013 18:09:22 -0000 Here's the before and after looks like FWIW: ' + LC_ALL=C + export LC_ALL + [ ! -r version ] + echo 0 + touch version + cat version + pwd + hostname + date + v=0 u=root d=/usr/src/sys/conf h=borg.macktronics.com t='Sat Aug 10 12:59:21 CDT 2013' + make -V KERN_IDENT + i='' + make -V CC + grep version + cc -v + compiler_v='FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610' + [ -x /usr/bin/svnliteversion ] + svnversion=/usr/bin/svnliteversion + [ ! -z /usr/bin/svnliteversion ] + break + [ -x /usr/bin/p4 ] + [ -x /usr/local/bin/p4 ] + [ -d ./../../.git ] + [ -n /usr/bin/svnliteversion ] + cd ./.. + /usr/bin/svnliteversion + svn=253918 + svn=' r253918' + [ -n '' ] + [ -n '' ] + cat + echo 1 BAD: ' + LC_ALL=C + export LC_ALL + [ ! -r version ] + echo 0 + touch version + cat version + pwd + hostname + date + v=0 u=root d=/usr/src/sys/conf h=olive.macktronics.com t='Sat Aug 10 12:58:47 CDT 2013' + make -V KERN_IDENT + i='' + make -V CC + grep version + cc -v + compiler_v='FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610' + [ ! -z '' ] + [ -x /usr/bin/svnversion ] + [ ! -z '' ] + [ -x /usr/local/bin/svnversion ] + [ -z '' ] + [ -x /usr/bin/svnliteversion ] + basename newvers.sh + /usr/bin/svnversion newvers.sh + [ 127 -eq 0 ] + svnversion='' + [ -x /usr/bin/p4 ] + [ -x /usr/local/bin/p4 ] + [ -d ./../../.git ] + [ -n '' ] + [ -n '' ] + [ -n '' ] + cat + echo 1 It looks like you are doing the first [! -z '"${svnversion}"' ] before $svnversion is being set. In the old version, this was being set via: if [ -x /usr/bin/svnliteversion ] ; then svnversion=/usr/bin/svnliteversion fi But I'm not sure if that's intentional or not ... Dan On Sat, 10 Aug 2013, Dan Mack wrote: > Same problems here ... sometime after 10.0-CURRENT r253918 ... Two other > systems stopped working and they have a mixture of svn / svnlite version > combinations: > > working system: > > #1: ports svn installed at newer version > root@borg:/usr/src # svnversion ; svnversion --version | head -1 > 253918 > svnversion, version 1.8.0 (r1490375) > root@borg:/usr/src # svnliteversion ; svnliteversion --version | head -1 > 253918 > svnversion, version 1.8.1 (r1503906) > root@borg:/usr/src # uname -a > FreeBSD borg.example.com 10.0-CURRENT FreeBSD 10.0-CURRENT #3 r253918: Sat > Aug 3 15:16:58 CDT 2013 root@borg.example.com:/usr/obj/usr/src/sys/MACKGEN > amd64 > > Systems not working: > > #2: no ports svn installed > root@olive:/usr/src # uname -a > FreeBSD olive.example.com 10.0-CURRENT FreeBSD 10.0-CURRENT #5: Sat Aug 10 > 08:30:25 CDT 2013 root@olive.example.com:/usr/obj/usr/src/sys/MACKGEN amd64 > root@olive:/usr/src # svnversion ; svnversion --version | head -1 > svnversion: Command not found. > svnversion: Command not found. > root@olive:/usr/src # svnliteversion ; svnliteversion --version | head -1 > 254178 > svnversion, version 1.8.1 (r1503906) > > #3: ports version installed at newer version > root@darkstor:/usr/src # uname -a > FreeBSD darkstor.example.com 10.0-CURRENT FreeBSD 10.0-CURRENT #7: Sat Aug 10 > 08:35:47 CDT 2013 root@darkstor.example.com:/usr/obj/usr/src/sys/MACKGEN > amd64 > root@darkstor:/usr/src # svnversion ; svnversion --version | head -1 > 254178 > svnversion, version 1.8.0 (r1490375) > root@darkstor:/usr/src # svnliteversion ; svnliteversion --version | head -1 > 254178 > svnversion, version 1.8.1 (r1503906) > > Dan > > On Sat, 10 Aug 2013, Lev Serebryakov wrote: > >> Hello, Glen. >> You wrote 10 ??????? 2013 ?., 18:13:24: >> >> GB> Hmm. I suspect r254094 is to blame here, although I did extensive >> GB> testing with different svn versions before the commit. :( >> GB> I'll take another look at this, in case I missed an edge case. >> It doesn't look like edge case... >> >> Sources in /data/src. It is SVN WC. >> >> # cd /data/src && svnversion >> 254178M >> # cd /data/src && svnliteversion >> 254178M >> # >> >> >> "host" system is -CURRENT too, already without revision in uname -a output >> (!), from Sat Jul 20. >> >> System is built with nanobsd script, but it looks like nanobsd.sh doesn't >> do any special here. It sets MAKEOBJDIRPREFIX to /data/obj.nano/gateway.v2 >> and call: >> >> env TARGET_ARCH=amd64 make -j4 >> __MAKE_CONF=/some/path/to/generated/make.conf buildworld >> >> Generated make.conf looks like: >> ======================================================================= >> XCC=/usr/bin/cc >> XCXX=/usr/bin/c++ >> XCPP=/usr/bin/cpp >> COMPILER_TYPE=clang >> MALLOC_PRODUCTION=yes >> BOOT_COMCONSOLE_SPEED=115200 >> BOOT_COMCONSOLE_PORT=0x2E8 >> WITHOUT_ACCT=yes >> WITHOUT_ACPI=yes >> WITHOUT_AMD=yes >> WITHOUT_APM=yes >> WITHOUT_ATM=yes >> WITHOUT_AUDIT=yes >> WITHOUT_AUTHPF=yes >> WITHOUT_BIND_DNSSEC=yes >> WITHOUT_CALENDAR=yes >> WITHOUT_CDDL=yes >> WITHOUT_CLANG=yes >> WITHOUT_CROSS_COMPILER=yes >> WITHOUT_CTM=yes >> WITHOUT_DICT=yes >> WITHOUT_EXAMPLES=yes >> WITHOUT_FLOPPY=yes >> WITHOUT_FREEBSD_UPDATE=yes >> WITHOUT_GAMES=yes >> WITHOUT_GCC=yes >> WITHOUT_GCOV=yes >> WITHOUT_GDB=yes >> WITHOUT_GPIB=yes >> WITHOUT_GPIO=yes >> WITHOUT_GROFF=yes >> WITHOUT_GSSAPI=yes >> WITHOUT_HTML=yes >> WITHOUT_INFO=yes >> WITHOUT_IPFILTER=yes >> WITHOUT_IPX=yes >> WITHOUT_JAIL=yes >> WITHOUT_LEGACY_CONSOLE=yes >> WITHOUT_LIB32=yes >> WITHOUT_LOCALES=yes >> WITHOUT_LOCATE=yes >> WITHOUT_LPR=yes >> WITHOUT_KERBEROS=yes >> WITHOUT_KERBEROS_SUPPORT=yes >> WITHOUT_MAN=yes >> WITHOUT_NCP=yes >> WITHOUT_NDIS=yes >> WITHOUT_NIS=yes >> WITHOUT_NLS=yes >> WITHOUT_NLS_CATALOGS=yes >> WITHOUT_NS_CACHING=yes >> WITHOUT_OBJC=yes >> WITHOUT_PC_SYSINSTALL=yes >> WITHOUT_PF=yes >> WITHOUT_PORTSNAP=yes >> WITHOUT_PROFILE=yes >> WITHOUT_QUOTAS=yes >> WITHOUT_RCMDS=yes >> WITHOUT_RCS=yes >> WITHOUT_ROUTED=yes >> WITHOUT_SHAREDOCS=yes >> WITHOUT_SVNLITE=yes >> WITHOUT_SYSCONS=yes >> WITHOUT_ZFS=yes >> SRCCONF=/dev/null >> ======================================================================= >> >> -- >> // Black Lion AKA Lev Serebryakov >> >> _______________________________________________ >> 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" > > > dan > -- > Dan Mack > > _______________________________________________ > 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" > dan -- Dan Mack From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 18:11:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 158FFC53; Sat, 10 Aug 2013 18:11:56 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [IPv6:2607:fc50:1:2300:1001:1001:1001:face]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D95C228FF; Sat, 10 Aug 2013 18:11:55 +0000 (UTC) Received: from glenbarber.us (nucleus.glenbarber.us [IPv6:2001:470:8:1205:2:2:ff:29]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 9F6CFC11B; Sat, 10 Aug 2013 18:11:53 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 9F6CFC11B Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Sat, 10 Aug 2013 14:11:52 -0400 From: Glen Barber To: Dan Mack Subject: Re: nanobsd-built system doesn't have SVN revision in "uname" (and it looks like regression) Message-ID: <20130810181152.GE2432@glenbarber.us> References: <383656436.20130810150849@serebryakov.spb.ru> <37152758.20130810151846@serebryakov.spb.ru> <602958881.20130810180203@serebryakov.spb.ru> <20130810141324.GD2432@glenbarber.us> <529930061.20130810191339@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="idY8LE8SD6/8DnRI" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Lev Serebryakov , freebsd-embedded@freebsd.org, 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: Sat, 10 Aug 2013 18:11:56 -0000 --idY8LE8SD6/8DnRI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 10, 2013 at 01:09:20PM -0500, Dan Mack wrote: > It looks like you are doing the first [! -z '"${svnversion}"' ] > before $svnversion is being set. In the old version, this was > being set via: >=20 > if [ -x /usr/bin/svnliteversion ] ; then > svnversion=3D/usr/bin/svnliteversion > fi >=20 > But I'm not sure if that's intentional or not ... >=20 Ugh. No, this was not intentional. I'll have this fixed shortly. Thank you for the report and the investigation. Glen --idY8LE8SD6/8DnRI Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBCAAGBQJSBoJoAAoJEFJPDDeguUajaB0H/jA2wWE5b6i4T6sKSCcKvKkP k4dfwKOQ5xvjHpAiu2doLgYjXa30p/+9/d1qNhcqXqCQ1rrlwkg4c3QSH32SnPG1 XB1m3Z574gX+siryBtYcBH4UdRfrzcW/fEoQhjcGJJIqyZ1WsjjBRkpo/nbWGkGf GJNgAohBRi/E9ETs/6L52vUopx+uIve20QkJX19TejD+lfIuN/9+jOJSLho8In2x ZX6kbW3dyWg23gADh7lY6ZQFYz5qpHGoDDNJjSi5gsegGaVxsdaWwGxFGVDbxEpI waI0LNe1Zsau/ssKR13kekUNztKpagW06xYLdk8W+TbykfwoM1F2l/vXAMfyIys= =OybU -----END PGP SIGNATURE----- --idY8LE8SD6/8DnRI-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 18:21:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 85597F21 for ; Sat, 10 Aug 2013 18:21:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 231E92956 for ; Sat, 10 Aug 2013 18:21:14 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r7AIL9h2073998; Sat, 10 Aug 2013 21:21:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r7AIL9h2073998 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r7AIL9HV073997; Sat, 10 Aug 2013 21:21:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 10 Aug 2013 21:21:09 +0300 From: Konstantin Belousov To: Bryan Drewery Subject: Re: panic on boot with fresh current Message-ID: <20130810182109.GG4972@kib.kiev.ua> References: <20130810112410.GA27286@devbox.vnode.local> <52066DE0.2060305@shatow.net> <52067537.2070309@shatow.net> <20130810174407.GD4972@kib.kiev.ua> <20130810174547.GE4972@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vbZajQVEYxrkwA3V" Content-Disposition: inline In-Reply-To: <20130810174547.GE4972@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home 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: Sat, 10 Aug 2013 18:21:15 -0000 --vbZajQVEYxrkwA3V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 10, 2013 at 08:45:47PM +0300, Konstantin Belousov wrote: > On Sat, Aug 10, 2013 at 08:44:07PM +0300, Konstantin Belousov wrote: > > On Sat, Aug 10, 2013 at 12:15:35PM -0500, Bryan Drewery wrote: > > > On 8/10/2013 11:44 AM, Bryan Drewery wrote: > > > > On 8/10/2013 6:24 AM, Joel Dahl wrote: > > > >> panic: witness_init: pending locks list is too small, increase > > > >> WITNESS_PENDLIST > > > > I also get this. The last stable revision for me was r254150 > > >=20 > > > r254150 stable, r254171 panic. > > >=20 > > > backtrace: https://dl.dropboxusercontent.com/u/8732004/r254171-panic.= jpg > >=20 > > So could you point to exact commit which causes panic ? > It is r254167, right ? >=20 So I cannot reproduce it locally. The problem is that r254167 moved sleepq initialization before witness is operational, and witness has a backlog of locks initialized before witness init. The backlog overflown. The right fix looks to be just what the panic message told, please try this: diff --git a/sys/kern/subr_witness.c b/sys/kern/subr_witness.c index 3b4d7a2..37e8cf2 100644 --- a/sys/kern/subr_witness.c +++ b/sys/kern/subr_witness.c @@ -135,7 +135,7 @@ __FBSDID("$FreeBSD$"); #define WITNESS_COUNT 1024 #define WITNESS_CHILDCOUNT (WITNESS_COUNT * 4) #define WITNESS_HASH_SIZE 251 /* Prime, gives load factor < 2 */ -#define WITNESS_PENDLIST 768 +#define WITNESS_PENDLIST 1024 =20 /* Allocate 256 KB of stack data space */ #define WITNESS_LO_DATA_COUNT 2048 If this does not help, try to increse PENDLIST even more. But, sleepq uses 256 elements, which means that my increase should be enough. --vbZajQVEYxrkwA3V Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJSBoSUAAoJEJDCuSvBvK1BeSkQAKNnwWNIk8B0z6pM2ja8FeXQ 5hDHM0dtmb1QCenAY/33RG44cNO7Cqzs+ZQgqfxvvCLd+PH6LGZJfzwIzySS8Qsl eAZF8inKCbvNeSzuY/TWcDT9OtV6jvG5/7jP2uwHQtc3X7T0Z9Ob5fCilYQp2Da0 EJ54i4zqMaLNjLxcmfaSjHU22oGIRXl0ojbOPJ875a8bz8etBFoupt387SiUSA3K VlcPX9QfDNJ3TM3uq6JpC2D6UuIilsEQotBwZ17d5WLp4oPGzahczgFe99JWjEPF dDY9ZMZQkIFk3mTBV+C2/jtQBxN0fc12TMOC7WwjGyBQ8fq1jGfYv+4e5cfGZVzl tkCJ+DhxjApJq125oHBf/xGQmQevHIqMFWLpTW/N5R2O3h4VNgu+uzws545gxmxe KCgW5sLOggXS26+2B+Yb4l5tuJ8Zp0p727fXrnV1dZaPzsJ5T0U8cOYHf8cab8hr D7kMlzsn4+QH0af02bmTKeJTZVt7zA5zI7MV/2YrLSwOXiFmIB+R5oKWPLs30Ncm tdEkntre3EaorbiJvwz5n1jYsredCjcdK59RvRu5JtoeDnxEdB70yxDcnnd6KZTw ZYYWTOBXWl+gAEtUTQeHZ+KfTuNwooxm9H8n/jbatD2aepKLBzvLB3aDgI+WrOpS d5QuNcY+9vpSt9OSAWU5 =IHFc -----END PGP SIGNATURE----- --vbZajQVEYxrkwA3V-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 18:25:02 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 523C4352; Sat, 10 Aug 2013 18:25:02 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [IPv6:2607:fc50:1:2300:1001:1001:1001:face]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 211632980; Sat, 10 Aug 2013 18:25:02 +0000 (UTC) Received: from glenbarber.us (nucleus.glenbarber.us [IPv6:2001:470:8:1205:2:2:ff:29]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id E1C00C26C; Sat, 10 Aug 2013 18:25:00 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us E1C00C26C Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Sat, 10 Aug 2013 14:24:59 -0400 From: Glen Barber To: Dan Mack Subject: Re: nanobsd-built system doesn't have SVN revision in "uname" (and it looks like regression) Message-ID: <20130810182459.GF2432@glenbarber.us> References: <383656436.20130810150849@serebryakov.spb.ru> <37152758.20130810151846@serebryakov.spb.ru> <602958881.20130810180203@serebryakov.spb.ru> <20130810141324.GD2432@glenbarber.us> <529930061.20130810191339@serebryakov.spb.ru> <20130810181152.GE2432@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GV0iVqYguTV4Q9ER" Content-Disposition: inline In-Reply-To: <20130810181152.GE2432@glenbarber.us> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Lev Serebryakov , freebsd-embedded@freebsd.org, 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: Sat, 10 Aug 2013 18:25:02 -0000 --GV0iVqYguTV4Q9ER Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 10, 2013 at 02:11:52PM -0400, Glen Barber wrote: > On Sat, Aug 10, 2013 at 01:09:20PM -0500, Dan Mack wrote: > > It looks like you are doing the first [! -z '"${svnversion}"' ] > > before $svnversion is being set. In the old version, this was > > being set via: > >=20 > > if [ -x /usr/bin/svnliteversion ] ; then > > svnversion=3D/usr/bin/svnliteversion > > fi > >=20 > > But I'm not sure if that's intentional or not ... > >=20 >=20 > Ugh. No, this was not intentional. I'll have this fixed shortly. >=20 Fixed in r254184. The problem is that I was evaluating ${svnversion} being set before looking for /usr/bin/svnliteversion; however when _running_ /usr/bin/svnliteversion, it was being run as /usr/bin/svnversion by mistake. Thank you for the reports, and Dan, thank you for your help. Glen --GV0iVqYguTV4Q9ER Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBCAAGBQJSBoV7AAoJEFJPDDeguUajcdkIAK7KFqFppIpLq2+Ws1qcsPDI ddvJ8BaSGRFQKK3UHfxnJbbyIImKn4nsoQU9sFq+pgo91leIapWYuobLUAJCYs// A72A5yoEL5tuMiyIK/h0Sd0DHWYnRPn/HXEh/rXXOihuMp38+AF0Vb0+RyoPz6/N anvcQZosvNtziE7uybQUZoAyPw66+VW7SDNVxivYEEhcUbIKAFUShud4yU88HKpS FfNBBsPUA/k9UVBjJdlVC4LOuucmwnx9ToKhS5SoWQLxo6nud1lzPidPeIBt2t5R PmVGFs7ih6xa6+3P2PV+DcQvvBGgkDKbaW3QcqBNe6zrLilgfHS3Fk0pIsEF5gg= =m02a -----END PGP SIGNATURE----- --GV0iVqYguTV4Q9ER-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 19:06:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9B3CF9AC for ; Sat, 10 Aug 2013 19:06:24 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 15A322B19 for ; Sat, 10 Aug 2013 19:06:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:Message-ID:Subject:To:Sender:From:Date; bh=mlgFtCK6o6DeCwdeYvmjowfWvUVsTn8MnfCS0Cl3D0I=; b=OG9sGZ5gfQc3a+ij4qrs2GujIx/q+KvJH7uSFbHJE5X9fSZD6AMvDEs7+auQmjl7/f+IYsNgiwPcQOAxlGF/Y4bOrStEVFZTYeNZYgmcpdqryWW8xFV+8+Ak384azbAtF/PBVPzCLZsLtvG+xBD18oZlTflsQvIWPBsOOyE9bfA=; Received: from cpe-72-182-93-216.austin.res.rr.com ([72.182.93.216]:16339 helo=borg) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1V8EUP-0006py-Gb for freebsd-current@freebsd.org; Sat, 10 Aug 2013 14:06:23 -0500 Date: Sat, 10 Aug 2013 14:06:10 -0500 (CDT) From: Larry Rosenman Sender: ler@borg To: freebsd-current@freebsd.org Subject: crash with cpucontrol/microcode update : Today's -CURRENT Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Spam-Score: 2.6 (++) X-LERCTR-Spam-Score: 2.6 (++) X-Spam-Report: SpamScore (2.6/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, KAM_STOCKTIP=5.5 X-LERCTR-Spam-Report: SpamScore (2.6/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, KAM_STOCKTIP=5.5 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: Sat, 10 Aug 2013 19:06:24 -0000 I'm getting the following @R254183: when I try to run the microcode_update. Just started with yesterday's -CURRENT. I can supply the full vmcore and ssh access. borg.lerctr.org dumped core - see /var/crash/vmcore.7 Sat Aug 10 14:00:00 CDT 2013 FreeBSD borg.lerctr.org 10.0-CURRENT FreeBSD 10.0-CURRENT #16: Sat Aug 10 13:45:06 CDT 2013 root@borg.lerctr.org:/usr/obj/usr/src/sys/BORG-DTRACE amd64 panic: page fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1378 (cpucontrol) trap number = 12 panic: page fault cpuid = 0 Uptime: 1m48s Dumping 2337 out of 64479 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Reading symbols from /boot/kernel/zfs.ko.symbols...done. Loaded symbols for /boot/kernel/zfs.ko.symbols Reading symbols from /boot/kernel/acl_nfs4.ko.symbols...done. Loaded symbols for /boot/kernel/acl_nfs4.ko.symbols Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. Loaded symbols for /boot/kernel/opensolaris.ko.symbols Reading symbols from /boot/kernel/linux.ko.symbols...done. Loaded symbols for /boot/kernel/linux.ko.symbols Reading symbols from /boot/kernel/snd_envy24ht.ko.symbols...done. Loaded symbols for /boot/kernel/snd_envy24ht.ko.symbols Reading symbols from /boot/kernel/snd_spicds.ko.symbols...done. Loaded symbols for /boot/kernel/snd_spicds.ko.symbols Reading symbols from /boot/kernel/sound.ko.symbols...done. Loaded symbols for /boot/kernel/sound.ko.symbols Reading symbols from /boot/kernel/coretemp.ko.symbols...done. Loaded symbols for /boot/kernel/coretemp.ko.symbols Reading symbols from /boot/kernel/ichsmb.ko.symbols...done. Loaded symbols for /boot/kernel/ichsmb.ko.symbols Reading symbols from /boot/kernel/smbus.ko.symbols...done. Loaded symbols for /boot/kernel/smbus.ko.symbols Reading symbols from /boot/kernel/ichwd.ko.symbols...done. Loaded symbols for /boot/kernel/ichwd.ko.symbols Reading symbols from /boot/kernel/cpuctl.ko.symbols...done. Loaded symbols for /boot/kernel/cpuctl.ko.symbols Reading symbols from /boot/kernel/crypto.ko.symbols...done. Loaded symbols for /boot/kernel/crypto.ko.symbols Reading symbols from /boot/kernel/cryptodev.ko.symbols...done. Loaded symbols for /boot/kernel/cryptodev.ko.symbols Reading symbols from /boot/kernel/dtraceall.ko.symbols...done. Loaded symbols for /boot/kernel/dtraceall.ko.symbols Reading symbols from /boot/kernel/profile.ko.symbols...done. Loaded symbols for /boot/kernel/profile.ko.symbols Reading symbols from /boot/kernel/cyclic.ko.symbols...done. Loaded symbols for /boot/kernel/cyclic.ko.symbols Reading symbols from /boot/kernel/dtrace.ko.symbols...done. Loaded symbols for /boot/kernel/dtrace.ko.symbols Reading symbols from /boot/kernel/systrace_freebsd32.ko.symbols...done. Loaded symbols for /boot/kernel/systrace_freebsd32.ko.symbols Reading symbols from /boot/kernel/systrace.ko.symbols...done. Loaded symbols for /boot/kernel/systrace.ko.symbols Reading symbols from /boot/kernel/sdt.ko.symbols...done. Loaded symbols for /boot/kernel/sdt.ko.symbols Reading symbols from /boot/kernel/lockstat.ko.symbols...done. Loaded symbols for /boot/kernel/lockstat.ko.symbols Reading symbols from /boot/kernel/fasttrap.ko.symbols...done. Loaded symbols for /boot/kernel/fasttrap.ko.symbols Reading symbols from /boot/kernel/fbt.ko.symbols...done. Loaded symbols for /boot/kernel/fbt.ko.symbols Reading symbols from /boot/kernel/dtnfscl.ko.symbols...done. Loaded symbols for /boot/kernel/dtnfscl.ko.symbols Reading symbols from /boot/kernel/dtmalloc.ko.symbols...done. Loaded symbols for /boot/kernel/dtmalloc.ko.symbols Reading symbols from /boot/kernel/dtio.ko.symbols...done. Loaded symbols for /boot/kernel/dtio.ko.symbols Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. Loaded symbols for /boot/kernel/fdescfs.ko.symbols Reading symbols from /boot/kernel/uhid.ko.symbols...done. Loaded symbols for /boot/kernel/uhid.ko.symbols Reading symbols from /boot/kernel/ums.ko.symbols...done. Loaded symbols for /boot/kernel/ums.ko.symbols Reading symbols from /boot/modules/vboxnetflt.ko...done. Loaded symbols for /boot/modules/vboxnetflt.ko Reading symbols from /boot/kernel/netgraph.ko.symbols...done. Loaded symbols for /boot/kernel/netgraph.ko.symbols Reading symbols from /boot/kernel/ng_ether.ko.symbols...done. Loaded symbols for /boot/kernel/ng_ether.ko.symbols Reading symbols from /boot/modules/vboxnetadp.ko...done. Loaded symbols for /boot/modules/vboxnetadp.ko #0 doadump (textdump=) at pcpu.h:236 236 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=) at pcpu.h:236 #1 0xffffffff8051d6f0 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0xffffffff8051da77 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:754 #3 0xffffffff80780d9a in trap_fatal (frame=, eva=) at /usr/src/sys/amd64/amd64/trap.c:873 #4 0xffffffff80781199 in trap_pfault (frame=0x0, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:731 #5 0xffffffff80780792 in trap (frame=0xffffff900d55c7b0) at /usr/src/sys/amd64/amd64/trap.c:463 #6 0xffffffff8076ad02 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 #7 0xffffffff80709be9 in vm_page_unwire (m=0x0, activate=0) at /usr/src/sys/vm/vm_page.c:2356 #8 0xffffffff806fb4ed in kmem_unback (object=0xffffffff80c57550, addr=, size=4096) at /usr/src/sys/vm/vm_kern.c:404 #9 0xffffffff806fb5a4 in kmem_free (vmem=0xffffffff80bd7780, addr=18446741884987129872, size=4096) at /usr/src/sys/vm/vm_kern.c:421 #10 0xffffffff80506597 in contigfree (addr=0x0, size=4048, type=0xffffffff812d5ea0) at /usr/src/sys/kern/kern_malloc.c:435 #11 0xffffffff812d5a79 in cpuctl_ioctl (dev=, cmd=, data=0xfffffe000d2a2f80 "0?c", flags=, td=) at /usr/src/sys/modules/cpuctl/../../dev/cpuctl/cpuctl.c:480 #12 0xffffffff8041962f in devfs_ioctl_f (fp=0xfffffe001e68cbe0, com=3222299396, data=0xfffffe000d2a2f80, cred=, td=0xfffffe0252ebd490) at /usr/src/sys/fs/devfs/devfs_vnops.c:757 #13 0xffffffff8056b3be in kern_ioctl (td=0xfffffe0252ebd490, fd=, com=0) at file.h:306 #14 0xffffffff8056b13f in sys_ioctl (td=0xfffffe0252ebd490, uap=0xffffff900d55cb80) at /usr/src/sys/kern/sys_generic.c:693 #15 0xffffffff80781697 in amd64_syscall (td=0xfffffe0252ebd490, traced=0) at subr_syscall.c:134 #16 0xffffffff8076afeb in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 #17 0x000000080094b4ea in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) ------------------------------------------------------------------------ ps -axl UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 0 0 0 -8 0 0 0 - DLs - 0:02.61 [kernel] 0 1 0 0 52 0 9428 0 wait DLs - 0:00.26 [init] 0 2 0 0 -16 0 0 0 ftcl DL - 0:00.00 [ftcleanup] 0 3 0 0 -16 0 0 0 crypto_w DL - 0:00.00 [crypto] 0 4 0 0 -16 0 0 0 crypto_r DL - 0:00.00 [crypto returns 0 5 0 0 -16 0 0 0 - DL - 0:00.00 [fdc0] 0 6 0 0 -8 0 0 0 tx->tx_s DL - 0:00.09 [zfskern] 0 7 0 0 -16 0 0 0 waiting_ DL - 0:00.00 [sctp_iterator] 0 8 0 0 -16 0 0 0 ccb_scan DL - 0:00.00 [xpt_thrd] 0 9 0 0 -16 0 0 0 psleep DL - 0:00.00 [pagedaemon] 0 10 0 0 -16 0 0 0 audit_wo DL - 0:00.00 [audit] 0 11 0 0 155 0 0 0 - RL - 6:08.99 [idle] 0 12 0 0 -84 0 0 0 - WL - 0:00.43 [intr] 0 13 0 0 -8 0 0 0 - DL - 0:00.38 [geom] 0 14 0 0 -16 0 0 0 - DL - 0:00.01 [yarrow] 0 15 0 0 -68 0 0 0 - DL - 0:00.04 [usb] 0 16 0 0 -20 0 0 0 VBoxIS DL - 0:00.00 [TIMER] 0 17 0 0 -16 0 0 0 psleep DL - 0:00.00 [vmdaemon] 0 18 0 0 155 0 0 0 pgzero DL - 0:00.00 [pagezero] 0 19 0 0 -16 0 0 0 psleep DL - 0:00.00 [bufdaemon] 0 20 0 0 16 0 0 0 syncer DL - 0:00.00 [syncer] 0 21 0 0 -16 0 0 0 vlruwt DL - 0:00.00 [vnlru] 0 847 1 0 52 0 16584 0 select Ds - 0:00.00 [moused] 0 866 1 0 20 0 13208 0 select Ds - 0:00.00 [devd] 0 1004 1 0 20 0 14380 0 - Rs - 0:00.05 [syslogd] 0 1007 1 0 -52 0 6192 2104 nanslp Ds - 0:00.00 [watchdogd] 0 1021 1 0 20 0 16468 0 select Ds - 0:00.01 [rpcbind] 0 1056 1 0 52 0 38964 0 select Ds - 0:00.02 [mountd] 0 1062 1 0 52 0 36804 0 select Ds - 0:00.04 [nfsd] 0 1064 1062 0 52 0 12228 0 rpcsvc D - 0:00.00 [nfsd] 0 1072 1 0 52 0 32716 0 select Ds - 0:00.99 [apcupsd] 0 1103 1 0 20 0 25268 0 select Ds - 0:00.01 [ntpd] 0 1124 0 0 -16 0 0 0 sleep DL - 0:00.00 [ng_queue] 0 1136 1 0 20 0 34748 0 nanslp Ds - 0:00.01 [perl] 0 1140 1 0 52 0 30844 0 nanslp D - 0:00.43 [smartd] 70 1149 1 0 20 0 86688 0 select Ds - 0:00.23 [postgres] 70 1153 1149 0 20 0 86688 0 select Ds - 0:00.00 [postgres] 70 1154 1149 0 20 0 86688 0 select Ds - 0:00.00 [postgres] 70 1155 1149 0 20 0 86688 0 select Ds - 0:00.00 [postgres] 70 1156 1149 0 20 0 46392 0 select Ds - 0:00.00 [postgres] 26 1246 1 0 52 0 48804 0 select Ds - 0:00.00 [exim-4.80.1-2] 0 1255 1 0 20 0 103300 0 kqread Ds - 0:00.02 [cupsd] 1028 1261 1 0 155 0 46764 0 select Ds - 0:00.07 [boinc_client] 910 1265 1 0 20 0 65436 0 uwait Ds - 0:00.00 [bacula-sd] 0 1268 1 0 20 0 65260 0 uwait Ds - 0:00.00 [bacula-fd] 910 1271 1 0 20 0 78464 0 uwait Ds - 0:00.00 [bacula-dir] 0 1276 1 0 20 0 56324 0 select Ds - 0:00.00 [sshd] 0 1288 1 0 20 0 16472 0 nanslp Ds - 0:00.00 [cron] 0 1310 1 0 52 0 18592 0 select Ds - 0:00.00 [inetd] 0 1326 1 0 52 0 16944 0 wait D - 0:00.00 [sh] 0 1327 1 0 52 0 12220 0 piperd D - 0:00.00 [logger] 0 1328 1326 0 52 0 8120 0 nanslp D - 0:00.00 [sleep] 0 1330 1 0 52 0 14376 0 ttyin Ds+ - 0:00.01 [getty] 0 1331 1 0 52 0 14376 0 ttyin Ds+ - 0:00.01 [getty] 0 1332 1 0 52 0 14376 0 ttyin Ds+ - 0:00.01 [getty] 0 1333 1 0 52 0 14376 0 ttyin Ds+ - 0:00.01 [getty] 0 1334 1 0 52 0 14376 0 ttyin Ds+ - 0:00.01 [getty] 0 1335 1 0 52 0 14376 0 ttyin Ds+ - 0:00.01 [getty] 0 1336 1 0 52 0 14376 0 ttyin Ds+ - 0:00.00 [getty] 0 1337 1 0 52 0 14376 0 ttyin Ds+ - 0:00.01 [getty] 0 1339 1276 0 21 0 81592 0 select Ds - 0:00.00 [sshd] 1002 1341 1339 0 20 0 81592 0 select D - 0:00.00 [sshd] 1002 1342 1341 0 20 0 16944 0 wait Ds - 0:00.00 [sh] 0 1344 1342 0 20 0 51140 0 select D - 0:00.00 [sudo] 0 1345 1344 0 20 0 16944 0 wait D - 0:00.00 [sh] 1028 1346 1261 0 155 19 86380 0 - RN - 0:00.94 [wcgrid_faah_7. 1028 1347 1261 0 155 19 1892 0 - RN - 0:00.04 [wcgrid_cep2_6. 1028 1348 1261 0 155 19 68404 0 - RN - 0:01.31 [wcgrid_faah_7. 1028 1349 1261 0 155 19 68404 0 - RN - 0:00.74 [wcgrid_faah_7. 1028 1350 1261 0 155 19 90036 0 - RN - 0:00.90 [wcgrid_faah_7. 1028 1351 1261 0 155 19 68412 0 - RN - 0:00.73 [wcgrid_faah_7. 1028 1352 1261 0 155 19 67892 0 - RN - 0:00.88 [wcgrid_faah_7. 1028 1353 1347 0 155 19 1892 0 i DN - 0:00.00 [wcgrid_cep2_6. 1028 1354 1261 0 155 19 76092 0 - RN - 0:00.80 [wcgrid_faah_7. 1028 1355 1353 0 155 19 1892 0 i DN - 0:00.00 [wcgrid_cep2_6. 1028 1356 1261 0 155 19 68404 0 i DN - 0:00.00 [wcgrid_faah_7. 1028 1357 1261 0 155 19 68412 0 - RN - 0:00.00 [wcgrid_faah_7. 1028 1358 1261 0 155 19 86380 0 - RN - 0:00.00 [wcgrid_faah_7. 1028 1359 1261 0 155 19 68404 0 i DN - 0:00.00 [wcgrid_faah_7. 1028 1360 1261 0 155 19 67892 0 i DN - 0:00.00 [wcgrid_faah_7. 1028 1361 1261 0 155 19 76092 0 i DN - 0:00.00 [wcgrid_faah_7. 1028 1362 1261 0 155 19 90036 0 - RN - 0:00.00 [wcgrid_faah_7. 0 1372 1345 0 43 0 16944 0 wait D+ - 0:00.01 [sh] 0 1378 1372 0 30 0 12228 0 - R+ - 0:00.00 [cpucontrol] ------------------------------------------------------------------------ vmstat -s 319667 cpu context switches 33520 device interrupts 4096 software interrupts 633273 traps 5813583 system calls 22 kernel threads created 1128 fork() calls 219 vfork() calls 9 rfork() calls 0 swap pager pageins 0 swap pager pages paged in 0 swap pager pageouts 0 swap pager pages paged out 1154 vnode pager pageins 8819 vnode pager pages paged in 8 vnode pager pageouts 16 vnode pager pages paged out 0 page daemon wakeups 0 pages examined by the page daemon 11 pages reactivated 42644 copy-on-write faults 255 copy-on-write optimized faults 562815 zero fill pages zeroed 0 zero fill pages prezeroed 5 intransit blocking page faults 622067 total VM faults taken 1014 page faults requiring I/O 0 pages affected by kernel thread creation 42834 pages affected by fork() 8586 pages affected by vfork() 115675 pages affected by rfork() 0 pages cached 823364 pages freed 0 pages freed by daemon 0 pages freed by exiting processes 26936 pages active 8342 pages inactive 4 pages in VM cache 220798 pages wired down 15823471 pages free 4096 bytes per page 240707 total name lookups cache hits (90% pos + 4% neg) system 0% per-directory deletions 0%, falsehits 0%, toolong 0% ------------------------------------------------------------------------ vmstat -m Type InUse MemUse HighUse Requests Size(s) kdtrace 462 100K - 1922 64,256 kenv 84 11K - 112 16,32,64,128 kqueue 2 3K - 30 256,2048 proc-args 53 5K - 513 16,32,64,128,256 DEVFSP 3 1K - 38 64 hhook 2 1K - 2 256 ithread 122 22K - 122 32,128,256 KTRACE 100 13K - 100 128 linker 401 197K - 544 16,32,64,128,256,512,1024,2048,4096 lockf 53 6K - 89 64,128 loginclass 1 1K - 6 64 cache 1 1K - 1 32 devbuf 18685 36135K - 19791 16,32,64,128,256,512,1024,2048,4096 temp 57 35K - 6961 16,32,64,128,256,512,1024,2048,4096 ip6ndp 5 1K - 6 64,128 module 301 38K - 301 128 mtx_pool 2 16K - 2 osd 7 1K - 18 16,32,64,128 pmchooks 1 1K - 1 128 NFS fh 1 1K - 5 16 pgrp 40 5K - 62 128 session 37 5K - 48 128 proc 2 256K - 2 subproc 194 360K - 1489 512,4096 cred 108 17K - 8666 64,256 plimit 23 6K - 204 256 uidinfo 7 33K - 25 128 sysctl 0 0K - 526 16,32,64 sysctloid 6788 337K - 6940 16,32,64,128 sysctltmp 0 0K - 384 16,32,64,128,256,4096 tidhash 1 256K - 1 callout 9 3208K - 9 umtx 792 99K - 792 128 p1003.1b 1 1K - 1 16 SWAP 12 19681K - 12 64 bus 945 90K - 5370 16,32,64,128,256,512,1024 bus-sc 141 293K - 2331 16,32,64,128,256,512,1024,2048,4096 devstat 34 69K - 34 32,4096 eventhandler 90 8K - 90 64,128 kobj 180 720K - 902 4096 Per-cpu 1 1K - 1 32 rman 360 41K - 797 16,32,128 sbuf 0 0K - 3645 16,32,64,128,256,512,1024,2048,4096 sglist 3 1K - 3 32 stack 0 0K - 2 256 taskqueue 109 17K - 139 16,32,64,256,1024 Unitno 20 2K - 420 32,64 vmem 2 160K - 4 ioctlops 1 1K - 2920 16,32,64,128,256,512,1024,2048 select 35 5K - 35 128 iov 1 1K - 1252 16,64,128,256,512 msg 4 30K - 4 2048,4096 sem 4 106K - 4 2048,4096 shm 6 30K - 13 2048 tty 20 20K - 22 1024,2048 pts 1 1K - 1 256 mbuf_tag 0 0K - 59 32,128 shmfd 1 8K - 1 soname 7 1K - 22000 16,32,128 pcb 37 8341K - 77 16,32,128,1024,2048 newnfsmnt 1 1K - 1 1024 vfscache 1 16384K - 1 vfs_hash 1 8192K - 1 vnodes 1 1K - 1 256 pfs_nodes 21 6K - 21 256 pfs_vncache 86 6K - 88 64 mount 396 20K - 1854 16,32,64,128,256,512 GEOM 344 60K - 3318 16,32,64,128,256,512,1024,2048 vnodemarker 0 0K - 161 512 BPF 3 1K - 3 128 acpica 1830 187K - 52091 16,32,64,128,256,512,1024,2048 ifnet 4 7K - 4 128,2048 ifaddr 48 15K - 48 32,64,128,256,512,2048,4096 ether_multi 47 3K - 54 16,32,64 clone 6 1K - 6 128 arpcom 2 1K - 2 16 lltable 13 5K - 13 256,512 UART 6 5K - 6 16,1024 CAM CCB 13 26K - 101 2048 acpitask 1 8K - 1 acpisem 22 3K - 22 128 CAM path 22 1K - 68 32 acpidev 36 3K - 36 64 routetbl 35 5K - 228 32,64,128,256,512 igmp 3 1K - 3 256 in_multi 2 1K - 2 256 CAM periph 16 4K - 40 16,32,64,128,256 CAM queue 31 8K - 100 16,32,512 CAM dev queue 8 1K - 8 32 sctp_a_it 0 0K - 3 16 sctp_vrf 1 1K - 1 64 sctp_ifa 5 1K - 5 128 sctp_ifn 2 1K - 2 128 sctp_iter 0 0K - 3 256 hostcache 1 28K - 1 syncache 1 64K - 1 in6_mfilter 1 1K - 1 1024 in6_multi 27 4K - 27 32,256 ip6_moptions 2 1K - 2 32,256 raid_data 0 0K - 480 32,128,256 mld 3 1K - 3 128 CAM SIM 8 2K - 8 256 CAM XPT 58 4K - 342 16,32,64,128,256,1024 NFS FHA 1 2K - 1 2048 rpc 19 5K - 23 32,64,128,256,512,1024 audit_evclass 188 6K - 229 32 vm_pgdata 7 8193K - 7 128 UMAHash 3 5K - 6 512,1024,2048,4096 scsi_cd 0 0K - 11 16 USB 50 162K - 56 16,32,64,128,256,512,1024,4096 USBdev 76 26K - 112 32,64,128,512,2048,4096 pci_link 16 2K - 16 32,64,128 acpi_perf 8 1K - 8 64 memdesc 1 4K - 1 4096 atkbddev 2 1K - 2 64 md_nvidia_data 0 0K - 78 512 kbdmux 7 18K - 7 16,512,1024,2048 LED 4 1K - 4 16,128 md_sii_data 0 0K - 78 512 CAM DEV 15 30K - 24 2048 ata_pci 1 1K - 1 64 acpiintr 1 1K - 1 64 ppbusdev 2 1K - 2 256 apmdev 1 1K - 1 128 madt_table 0 0K - 1 4096 isadev 5 1K - 5 128 random_adaptors 1 1K - 1 32 entropy 1024 64K - 1024 64 DEVFS3 223 56K - 269 256 io_apic 2 4K - 2 2048 DEVFS1 194 97K - 236 512 MCA 8 1K - 8 128 cdev 8 2K - 8 256 msi 2 1K - 2 128 nexusdev 4 1K - 4 16 DEVFS 42 1K - 43 16,128 filedesc 86 267K - 1390 16,32,64,128,2048,4096 filedesc_to_leader 17 2K - 17 64 sigio 1 1K - 1 64 filecaps 0 0K - 2 64 linux 43 3K - 43 32,64 mixer 1 4K - 1 4096 feeder 16 2K - 18 32,128 kstat_data 5 1K - 5 64 solaris 64977 432023K - 918878 16,32,64,128,256,512,1024,2048,4096 spicds 7 1K - 7 128 envy24ht 15 195K - 15 64,2048 cpuctl 2 5K - 2 64,4096 crypto 1 1K - 1 512 xform 0 0K - 167 16,32 cyclic 32 3K - 32 16,64,128 fbt 1 256K - 1 iprtheap 23 56K - 23 32,64,128,256,2048 nvidia 179 862K - 182 16,32,64,128,256,512,1024,2048,4096 fdesc_mount 1 1K - 1 16 netgraph_node 4 1K - 4 128,256 netgraph 2 1K - 2 64 ------------------------------------------------------------------------ vmstat -z ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Kegs: 384, 0, 172, 8, 172, 0, 0 UMA Zones: 1664, 0, 188, 0, 188, 0, 0 UMA Slabs: 80, 0, 22943, 257, 39931, 0, 0 UMA RCntSlabs: 88, 0, 816, 39, 816, 0, 0 UMA Hash: 256, 0, 7, 8, 10, 0, 0 4 Bucket: 32, 0, 252, 748, 5062, 786, 0 8 Bucket: 64, 0, 134, 1230, 2869, 188, 0 16 Bucket: 128, 0, 121, 1150, 2651, 26, 0 32 Bucket: 256, 0, 169, 761, 4898, 92, 0 64 Bucket: 512, 0, 427, 253, 3989, 334, 0 128 Bucket: 1024, 0, 1577, 147, 6403, 23, 0 vmem btag: 56, 0, 15370, 605, 16546, 226, 0 VM OBJECT: 256, 0, 3138, 342, 18576, 0, 0 RADIX NODE: 144, 0, 13651, 1037, 93009, 39, 0 MAP: 240, 0, 3, 61, 3, 0, 0 KMAP ENTRY: 128, 0, 13, 514, 13, 2, 0 MAP ENTRY: 128, 0, 1705, 1178, 41317, 0, 0 VMSPACE: 408, 0, 53, 181, 1357, 0, 0 fakepg: 104, 0, 0, 0, 0, 0, 0 mt_zone: 4112, 0, 288, 0, 288, 0, 0 16: 16, 0, 5, 246, 5, 0, 0 16: 16, 0, 2467, 545, 2622, 0, 0 16: 16, 0, 2, 249, 2, 0, 0 16: 16, 0, 89, 915, 24074, 0, 0 16: 16, 0, 4, 1000, 254, 0, 0 16: 16, 0, 651, 855, 4300, 0, 0 16: 16, 0, 48, 454, 80, 0, 0 16: 16, 0, 3154, 862, 71341, 0, 0 32: 32, 0, 2, 123, 2, 0, 0 32: 32, 0, 2634, 491, 2720, 0, 0 32: 32, 0, 10, 240, 10, 0, 0 32: 32, 0, 109, 891, 4525, 0, 0 32: 32, 0, 250, 750, 649, 0, 0 32: 32, 0, 337, 1288, 2957, 0, 0 32: 32, 0, 79, 921, 480, 0, 0 32: 32, 0, 1963, 2412, 48008, 0, 0 64: 64, 0, 6, 428, 6, 0, 0 64: 64, 0, 330, 600, 340, 0, 0 64: 64, 0, 14, 296, 14, 0, 0 64: 64, 0, 781, 1017, 2205, 0, 0 64: 64, 0, 103, 951, 1404, 0, 0 64: 64, 0, 9185, 735, 16699, 0, 0 64: 64, 0, 1093, 829, 1093, 0, 0 64: 64, 0, 25104, 5524, 244655, 0, 0 128: 128, 0, 8, 519, 8, 0, 0 128: 128, 0, 2007, 1000, 2513, 0, 0 128: 128, 0, 45, 978, 67, 0, 0 128: 128, 0, 1239, 900, 22787, 0, 0 128: 128, 0, 1164, 603, 1245, 0, 0 128: 128, 0, 2042, 686, 25479, 0, 0 128: 128, 0, 3, 276, 3, 0, 0 128: 128, 0, 9616, 2288, 86497, 0, 0 256: 256, 0, 2, 73, 2, 0, 0 256: 256, 0, 34, 461, 241, 0, 0 256: 256, 0, 6, 129, 6, 0, 0 256: 256, 0, 242, 403, 902, 0, 0 256: 256, 0, 465, 300, 950, 0, 0 256: 256, 0, 397, 338, 5080, 0, 0 256: 256, 0, 1, 74, 1, 0, 0 256: 256, 0, 4397, 4423, 98046, 0, 0 512: 512, 0, 4, 84, 8, 0, 0 512: 512, 0, 39, 49, 195, 0, 0 512: 512, 0, 0, 232, 161, 0, 0 512: 512, 0, 235, 165, 1414, 0, 0 512: 512, 0, 18, 70, 18, 0, 0 512: 512, 0, 338, 126, 434, 0, 0 512: 512, 0, 0, 0, 0, 0, 0 512: 512, 0, 10447, 601, 209776, 0, 0 1024: 1024, 0, 1, 15, 1, 0, 0 1024: 1024, 0, 1, 67, 100, 0, 0 1024: 1024, 0, 5, 23, 5, 0, 0 1024: 1024, 0, 6, 62, 1720, 0, 0 1024: 1024, 0, 20, 20, 20, 0, 0 1024: 1024, 0, 26, 262, 3723, 0, 0 1024: 1024, 0, 1, 15, 1, 0, 0 1024: 1024, 0, 339, 93, 51688, 0, 0 2048: 2048, 0, 5, 31, 12, 0, 0 2048: 2048, 0, 32, 20, 129, 0, 0 2048: 2048, 0, 1, 5, 1, 0, 0 2048: 2048, 0, 15, 11, 227, 0, 0 2048: 2048, 0, 76, 32, 1373, 0, 0 2048: 2048, 0, 25, 33, 203, 0, 0 2048: 2048, 0, 5, 1, 5, 0, 0 2048: 2048, 0, 365, 45, 4185, 0, 0 4096: 4096, 0, 1, 0, 1, 0, 0 4096: 4096, 0, 2, 0, 2, 0, 0 4096: 4096, 0, 180, 1, 902, 0, 0 4096: 4096, 0, 12, 0, 14, 0, 0 4096: 4096, 0, 5, 2, 8, 0, 0 4096: 4096, 0, 132, 7, 4551, 0, 0 4096: 4096, 0, 0, 0, 0, 0, 0 4096: 4096, 0, 5874, 9408, 89410, 0, 0 uint64 pcpu: 8, 0, 1386, 150, 1386, 0, 0 SLEEPQUEUE: 80, 0, 397, 750, 397, 0, 0 Files: 80, 0, 207, 793, 14296, 0, 0 TURNSTILE: 136, 0, 397, 283, 397, 0, 0 rl_entry: 40, 0, 49, 951, 49, 0, 0 umtx pi: 96, 0, 0, 0, 0, 0, 0 MAC labels: 40, 0, 0, 0, 0, 0, 0 PROC: 1208, 0, 83, 34, 1378, 0, 0 THREAD: 1168, 0, 377, 19, 542, 0, 0 cpuset: 72, 0, 286, 759, 438, 0, 0 cyclic_id_cache: 64, 0, 0, 0, 0, 0, 0 audit_record: 1240, 0, 0, 0, 0, 0, 0 mbuf_packet: 256, 25727505, 1023, 607, 1407, 0, 0 mbuf: 256, 25727505, 2, 878, 1060, 0, 0 mbuf_cluster: 2048, 4019922, 1625, 1, 1625,1490, 0 mbuf_jumbo_page: 4096, 2009961, 0, 3, 7, 0, 0 mbuf_jumbo_9k: 9216, 1786632, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 1339972, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 dtrace_state_cache: 4096, 0, 0, 0, 0, 0, 0 ttyinq: 160, 0, 180, 320, 540, 0, 0 ttyoutq: 256, 0, 95, 400, 287, 0, 0 g_bio: 248, 0, 0, 736, 100826, 0, 0 ata_request: 336, 0, 0, 154, 70, 0, 0 vtnet_tx_hdr: 24, 0, 0, 0, 0, 0, 0 cryptop: 88, 0, 0, 0, 0, 0, 0 cryptodesc: 72, 0, 0, 0, 0, 0, 0 nv_stack_t: 12288, 0, 2, 2, 12, 0, 0 FPU_save_area: 512, 0, 0, 0, 0, 0, 0 taskq_zone: 48, 0, 0, 0, 0, 0, 0 taskq_zone: 48, 0, 0, 581, 81, 0, 0 VNODE: 472, 0, 9463, 113, 9663, 0, 0 VNODEPOLL: 112, 0, 0, 0, 0, 0, 0 BUF TRIE: 144, 0, 0, 105948, 0, 0, 0 NAMEI: 1024, 0, 0, 132, 57320, 0, 0 S VFS Cache: 108, 0, 9378, 527, 11372, 0, 0 STS VFS Cache: 148, 0, 0, 0, 0, 0, 0 L VFS Cache: 328, 0, 151, 173, 205, 0, 0 LTS VFS Cache: 368, 0, 0, 0, 0, 0, 0 NCLNODE: 528, 0, 1, 13, 1, 0, 0 space_seg_cache: 64, 0, 7959, 101099, 238144, 0, 0 zio_cache: 944, 0, 6, 13970, 295331, 0, 0 zio_link_cache: 48, 0, 0, 15770, 278175, 0, 0 sa_cache: 80, 0, 9242, 658, 9413, 0, 0 dnode_t: 856, 0, 10211, 49, 13930, 0, 0 dmu_buf_impl_t: 224, 0, 19047, 299, 24850, 0, 0 arc_buf_hdr_t: 216, 0, 11737, 467, 13936, 0, 0 arc_buf_t: 72, 0, 10586, 689, 16271, 0, 0 zil_lwb_cache: 192, 0, 5, 495, 54, 0, 0 zfs_znode_cache: 368, 0, 9242, 128, 9413, 0, 0 Mountpoints: 816, 0, 30, 35, 30, 0, 0 pipe: 744, 0, 9, 86, 814, 0, 0 ksiginfo: 112, 0, 131, 1374, 1687, 0, 0 itimer: 352, 0, 1, 32, 1, 0, 0 KNOTE: 128, 0, 6, 521, 40, 0, 0 socket: 680, 2063352, 61, 71, 4016, 0, 0 unpcb: 240, 2063360, 16, 480, 3676, 0, 0 ipq: 56, 125670, 0, 0, 0, 0, 0 udp_inpcb: 392, 2063360, 20, 220, 298, 0, 0 udpcb: 16, 2063471, 20, 984, 298, 0, 0 tcp_inpcb: 392, 2063360, 24, 216, 36, 0, 0 tcpcb: 1024, 2063352, 24, 80, 36, 0, 0 tcptw: 72, 27775, 0, 165, 2, 0, 0 syncache: 152, 15366, 0, 78, 1, 0, 0 hostcache: 136, 15370, 0, 0, 0, 0, 0 tcpreass: 40, 251300, 0, 0, 0, 0, 0 sackhole: 32, 0, 0, 0, 0, 0, 0 sctp_ep: 1408, 2063352, 0, 0, 0, 0, 0 sctp_asoc: 2344, 40000, 0, 0, 0, 0, 0 sctp_laddr: 48, 80012, 0, 332, 4, 0, 0 sctp_raddr: 728, 80000, 0, 0, 0, 0, 0 sctp_chunk: 136, 400026, 0, 0, 0, 0, 0 sctp_readq: 104, 400026, 0, 0, 0, 0, 0 sctp_stream_msg_out: 104, 400026, 0, 0, 0, 0, 0 sctp_asconf: 40, 400000, 0, 0, 0, 0, 0 sctp_asconf_ack: 48, 400060, 0, 0, 0, 0, 0 ripcb: 392, 2063360, 0, 0, 0, 0, 0 rtentry: 200, 0, 17, 243, 17, 0, 0 selfd: 56, 0, 76, 989, 4050, 0, 0 SWAPMETA: 288, 8039850, 0, 0, 0, 0, 0 NetGraph items: 72, 4123, 0, 0, 0, 0, 0 NetGraph data items: 72, 527, 0, 0, 0, 0, 0 ------------------------------------------------------------------------ vmstat -i interrupt total rate irq1: atkbd0 3 0 irq6: fdc0 22 0 irq14: ata0 117 0 irq17: uhci0 ehci0 1145 7 irq19: uhci1 ahci0+ 31666 206 cpu0:timer 7042 46 irq256: em0 567 3 cpu6:timer 5638 36 cpu1:timer 6302 41 cpu3:timer 7819 51 cpu2:timer 4971 32 cpu7:timer 6608 43 cpu4:timer 5406 35 cpu5:timer 6416 41 Total 83722 547 ------------------------------------------------------------------------ pstat -T 207/2063348 files 0M/147455M swap space ------------------------------------------------------------------------ pstat -s Device 512-blocks Used Avail Capacity /dev/gpt/swap0 50331392 0 50331392 0% /dev/gpt/swap1 50331392 0 50331392 0% /dev/gpt/swap2 50331392 0 50331392 0% /dev/gpt/swap3 50331392 0 50331392 0% /dev/gpt/swap4 50331392 0 50331392 0% /dev/gpt/swap5 50331392 0 50331392 0% Total 301988352 0 301988352 0% ------------------------------------------------------------------------ iostat iostat: kvm_read(_tk_nin): invalid address (0x0) iostat: disabling TTY statistics ada0 ada1 ada2 cpu KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 15.37 36 0.55 15.50 34 0.52 15.58 36 0.55 0 0 2 0 97 ------------------------------------------------------------------------ ipcs -a Message Queues: T ID KEY MODE OWNER GROUP CREATOR CGROUP CBYTES QNUM QBYTES LSPID LRPID STIME RTIME CTIME Shared Memory: T ID KEY MODE OWNER GROUP CREATOR CGROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIME m 65536 5432001 --rw------- pgsql pgsql pgsql pgsql 4 41263104 1149 1149 13:54:11 13:55:13 13:54:11 Semaphores: T ID KEY MODE OWNER GROUP CREATOR CGROUP NSEMS OTIME CTIME s 65536 5432001 --rw------- pgsql pgsql pgsql pgsql 17 13:54:11 13:54:11 s 65537 5432002 --rw------- pgsql pgsql pgsql pgsql 17 13:54:11 13:54:11 s 65538 5432003 --rw------- pgsql pgsql pgsql pgsql 17 13:54:11 13:54:11 s 65539 5432004 --rw------- pgsql pgsql pgsql pgsql 17 13:54:11 13:54:11 s 65540 5432005 --rw------- pgsql pgsql pgsql pgsql 17 13:54:11 13:54:11 s 65541 5432006 --rw------- pgsql pgsql pgsql pgsql 17 13:54:11 13:54:11 s 65542 5432007 --rw------- pgsql pgsql pgsql pgsql 17 13:54:19 13:54:11 ------------------------------------------------------------------------ ipcs -T msginfo: msgmax: 16384 (max characters in a message) msgmni: 40 (# of message queues) msgmnb: 2048 (max characters in a message queue) msgtql: 40 (max # of messages in system) msgssz: 8 (size of a message segment) msgseg: 2048 (# of message segments in system) shminfo: shmmax: 536870912 (max shared memory segment size) shmmin: 1 (min shared memory segment size) shmmni: 192 (max number of shared memory identifiers) shmseg: 128 (max shared memory segments per process) shmall: 131072 (max amount of shared memory in pages) seminfo: semmni: 50 (# of semaphore identifiers) semmns: 340 (# of semaphores in system) semmnu: 150 (# of undo structures in system) semmsl: 340 (max # of semaphores per id) semopm: 100 (max # of operations per semop call) semume: 50 (max # of undo entries per process) semusz: 632 (size in bytes of undo structure) semvmx: 32767 (semaphore maximum value) semaem: 16384 (adjust on exit max value) ------------------------------------------------------------------------ nfsstat Client Info: Rpc Counts: Getattr Setattr Lookup Readlink Read Write Create Remove 2 0 0 0 0 0 0 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 0 0 0 0 0 0 0 0 Mknod Fsstat Fsinfo PathConf Commit 0 1 1 0 0 Rpc Info: TimedOut Invalid X Replies Retries Requests 0 0 0 0 4 Cache Info: Attr Hits Misses Lkup Hits Misses BioR Hits Misses BioW Hits Misses 0 0 0 0 0 0 0 0 BioRLHits Misses BioD Hits Misses DirE Hits Misses Accs Hits Misses 0 0 0 0 0 0 0 0 Server Info: Getattr Setattr Lookup Readlink Read Write Create Remove 0 0 0 0 0 0 0 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 0 0 0 0 0 0 0 0 Mknod Fsstat Fsinfo PathConf Commit 0 0 0 0 0 Server Ret-Failed 0 Server Faults 0 Server Cache Stats: Inprog Idem Non-idem Misses 0 0 0 0 Server Write Gathering: WriteOps WriteRPC Opsaved 0 0 0 ------------------------------------------------------------------------ netstat -s tcp: 167 packets sent 138 data packets (12023 bytes) 0 data packets (0 bytes) retransmitted 0 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 21 ack-only packets (4 delayed) 0 URG only packets 0 window probe packets 0 window update packets 8 control packets 196 packets received 137 acks (for 11879 bytes) 1 duplicate ack 0 acks for unsent data 136 packets (16234 bytes) received in-sequence 0 completely duplicate packets (0 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 0 out-of-order packets (0 bytes) 0 packets (0 bytes) of data after window 0 window probes 0 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 5 connection requests 1 connection accept 0 bad connection attempts 0 listen queue overflows 0 ignored RSTs in the windows 6 connections established (including accepts) 12 connections closed (including 0 drops) 0 connections updated cached RTT on close 0 connections updated cached RTT variance on close 0 connections updated cached ssthresh on close 0 embryonic connections dropped 133 segments updated rtt (of 134 attempts) 0 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 3 correct ACK header predictions 57 correct data packet header predictions 1 syncache entry added 0 retransmitted 0 dupsyn 0 dropped 1 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 1 cookie sent 0 cookies received 0 hostcache entries added 0 bucket overflow 0 SACK recovery episodes 0 segment rexmits in SACK recovery episodes 0 byte rexmits in SACK recovery episodes 0 SACK options (SACK blocks) received 0 SACK options (SACK blocks) sent 0 SACK scoreboard overflow 0 packets with ECN CE bit set 0 packets with ECN ECT(0) bit set 0 packets with ECN ECT(1) bit set 0 successful ECN handshakes 0 times ECN reduced the congestion window udp: 118 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 0 with no checksum 0 dropped due to no socket 36 broadcast/multicast datagrams undelivered 0 dropped due to full socket buffers 0 not for hashed pcb 82 delivered 82 datagrams output 0 times multicast source filter matched ip: 267 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 264 packets for this host 3 packets for unknown/unsupported protocol 0 packets forwarded (0 packets fast forwarded) 0 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 199 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header icmp: 0 calls to icmp_error 0 errors not generated in response to an icmp message 0 messages with bad code fields 0 messages less than the minimum length 0 messages with bad checksum 0 messages with bad length 0 multicast echo requests ignored 0 multicast timestamp requests ignored 0 message responses generated 0 invalid return addresses 0 no return routes igmp: 3 messages received 0 messages received with too few bytes 0 messages received with wrong TTL 0 messages received with bad checksum 1 V1/V2 membership query received 0 V3 membership queries received 0 membership queries received with invalid field(s) 1 general query received 0 group queries received 0 group-source queries received 0 group-source queries dropped 1 membership report received 0 membership reports received with invalid field(s) 0 membership reports received for groups to which we belong 0 V3 reports received without Router Alert 0 membership reports sent arp: 3 ARP requests sent 3 ARP replies sent 26 ARP requests received 7 ARP replies received 33 ARP packets received 0 total packets dropped due to no ARP entry 0 ARP entrys timed out 0 Duplicate IPs seen ip6: 50 total packets received 0 with size smaller than minimum 0 with data size < data length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 fragments that exceeded limit 0 packets reassembled ok 50 packets for this host 0 packets forwarded 0 packets not forwardable 0 redirects sent 57 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 4 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 packets that violated scope rules 0 multicast packets which we don't join Input histogram: UDP: 50 Mbuf statistics: 26 one mbuf 24 one ext mbuf 0 two or more ext mbuf 0 packets whose headers are not contiguous 0 tunneling packets that can't find gif 0 packets discarded because of too many headers 0 failures of source address selection Source addresses selection rule applied: icmp6: 0 calls to icmp6_error 0 errors not generated in response to an icmp6 message 0 errors not generated because of rate limitation Output histogram: neighbor solicitation: 1 0 messages with bad code fields 0 messages < minimum length 0 bad checksums 0 messages with bad length Histogram of error messages to be generated: 0 no route 0 administratively prohibited 0 beyond scope 0 address unreachable 0 port unreachable 0 packet too big 0 time exceed transit 0 time exceed reassembly 0 erroneous header field 0 unrecognized next header 0 unrecognized option 0 redirect 0 unknown 0 message responses generated 0 messages with too many ND options 0 messages with bad ND options 0 bad neighbor solicitation messages 0 bad neighbor advertisement messages 0 bad router solicitation messages 0 bad router advertisement messages 0 bad redirect messages 0 path MTU changes rip6: 0 messages received 0 checksum calculations on inbound 0 messages with bad checksum 0 messages dropped due to no socket 0 multicast messages dropped due to no socket 0 messages dropped due to full socket buffers 0 delivered 0 datagrams output ------------------------------------------------------------------------ netstat -m 1025/1485/2510 mbufs in use (current/cache/total) 1018/608/1626/4019922 mbuf clusters in use (current/cache/total/max) 1023/607 mbuf+clusters out of packet secondary zone in use (current/cache) 0/3/3/2009961 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/1786632 9k jumbo clusters in use (current/cache/total/max) 0/0/0/1339972 16k jumbo clusters in use (current/cache/total/max) 2292K/1599K/3891K bytes allocated to network (current/cache/total) 0/1490/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile ------------------------------------------------------------------------ netstat -id Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop em0 1500 00:30:48:f2:29:9c 300 0 0 205 0 0 0 em0 1500 192.168.200.0 borg 245 - - 199 - - - em0 1500 fe80::230:48f fe80::230:48ff:fe 0 - - 3 - - - em1* 1500 00:30:48:f2:29:9d 0 0 0 0 0 0 0 lo0 16384 50 0 0 50 0 0 0 lo0 16384 localhost ::1 50 - - 50 - - - lo0 16384 fe80::1%lo0 fe80::1 0 - - 0 - - - lo0 16384 your-net localhost 0 - - 0 - - - ------------------------------------------------------------------------ netstat -anr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.200.11 UGS 0 39 em0 127.0.0.1 link#3 UH 0 0 lo0 192.168.200.0/24 link#1 U 0 160 em0 192.168.200.4 link#1 UHS 0 0 lo0 Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 ::1 link#3 UH lo0 ::ffff:0.0.0.0/96 ::1 UGRS lo0 fe80::/10 ::1 UGRS lo0 fe80::%em0/64 link#1 U em0 fe80::230:48ff:fef2:299c%em0 link#1 UHS lo0 fe80::%lo0/64 link#3 U lo0 fe80::1%lo0 link#3 UHS lo0 ff01::%em0/32 fe80::230:48ff:fef2:299c%em0 U em0 ff01::%lo0/32 ::1 U lo0 ff02::/16 ::1 UGRS lo0 ff02::%em0/32 fe80::230:48ff:fef2:299c%em0 U em0 ff02::%lo0/32 ::1 U lo0 ------------------------------------------------------------------------ netstat -anA Active Internet connections (including servers) Tcpcb Proto Recv-Q Send-Q Local Address Foreign Address (state) fffffe025f039c00 tcp4 0 0 192.168.200.4.3351 198.20.8.246.80 ESTABLISHED fffffe0206042400 tcp4 0 0 127.0.0.1.31416 *.* LISTEN fffffe001eff9400 tcp4 0 148 192.168.200.4.22 192.168.200.87.498 ESTABLISHED fffffe020602e400 tcp4 0 0 *.9101 *.* LISTEN fffffe020615e800 tcp4 0 0 *.22 *.* LISTEN fffffe020615ec00 tcp6 0 0 *.22 *.* LISTEN fffffe020602e800 tcp4 0 0 *.9102 *.* LISTEN fffffe023e226400 tcp4 0 0 *.9103 *.* LISTEN fffffe020615f000 tcp4 0 0 *.631 *.* LISTEN fffffe020615f400 tcp6 0 0 *.631 *.* LISTEN fffffe001eff9800 tcp4 0 0 127.0.0.1.587 *.* LISTEN fffffe001eff9c00 tcp4 0 0 127.0.0.1.25 *.* LISTEN fffffe001effa000 tcp4 0 0 192.168.200.4.587 *.* LISTEN fffffe001effa400 tcp4 0 0 192.168.200.4.25 *.* LISTEN fffffe001effa800 tcp4 0 0 127.0.0.1.5432 *.* LISTEN fffffe001effac00 tcp6 0 0 ::1.5432 *.* LISTEN fffffe02063a6000 tcp4 0 0 *.3551 *.* LISTEN fffffe020602ec00 tcp6 0 0 *.2049 *.* LISTEN fffffe020602f000 tcp4 0 0 *.2049 *.* LISTEN fffffe020615f800 tcp4 0 0 *.977 *.* LISTEN fffffe020615fc00 tcp6 0 0 *.977 *.* LISTEN fffffe001effb000 tcp4 0 0 *.111 *.* LISTEN fffffe020602f400 tcp6 0 0 *.111 *.* LISTEN fffffe0206042800 tcp4 0 0 192.168.200.4.755 192.168.200.23.204 ESTABLISHED fffffe001eb7f7a8 udp4 0 0 *.631 *.* fffffe001eba77a8 udp6 0 0 ::1.46935 ::1.46935 fffffe001eb7f930 udp4 0 0 127.0.0.1.123 *.* fffffe001eb7fab8 udp6 0 0 fe80:3::1.123 *.* fffffe001eb7fc40 udp6 0 0 ::1.123 *.* fffffe001eb7fdc8 udp6 0 0 fe80:1::230:48ff.1 *.* fffffe001eb04000 udp4 0 0 192.168.200.4.123 *.* fffffe001eb04188 udp6 0 0 *.123 *.* fffffe001eb04310 udp4 0 0 *.123 *.* fffffe001ee6e188 udp6 0 0 *.2049 *.* fffffe001ee6e310 udp4 0 0 *.2049 *.* fffffe001eb04498 udp4 0 0 *.977 *.* fffffe001eb04620 udp6 0 0 *.977 *.* fffffe001ee7c188 udp6 0 0 *.* *.* fffffe001eb047a8 udp4 0 0 *.868 *.* fffffe001eb04930 udp4 0 0 *.111 *.* fffffe001eb04ab8 udp6 0 0 *.1013 *.* fffffe001eb04c40 udp6 0 0 *.111 *.* fffffe001eb91620 udp4 0 0 *.514 *.* fffffe001eb917a8 udp6 0 0 *.514 *.* Active UNIX domain sockets Address Type Recv-Q Send-Q Inode Conn Refs Nextref Addr fffffe0206108780 stream 0 0 0 fffffe001ee823c0 0 0 fffffe001ee823c0 stream 0 0 0 fffffe0206108780 0 0 fffffe0206108960 stream 0 0 fffffe0206b91588 0 0 0 /var/run/cups.sock fffffe001ee5b000 stream 0 0 fffffe02068f0760 0 0 0 /tmp/.s.PGSQL.5432 fffffe0206109690 stream 0 0 fffffe020610d760 0 0 0 /var/run/rpcbind.sock fffffe001ee825a0 stream 0 0 fffffe001e71f938 0 0 0 /var/run/devd.pipe fffffe001ee822d0 dgram 0 0 0 0 0 0 fffffe001ee824b0 dgram 0 0 0 fffffe02060dd960 0 fffffe001ee89000 fffffe001ee89000 dgram 0 0 0 fffffe02060dd960 0 fffffe0206108870 fffffe0206108870 dgram 0 0 0 fffffe02060dd960 0 0 fffffe02060dd780 dgram 0 0 0 fffffe02060dd870 0 fffffe001ee5b870 fffffe001ee5b870 dgram 0 0 0 fffffe02060dd870 0 fffffe001eeb02d0 fffffe001eeb02d0 dgram 0 0 0 fffffe02060dd870 0 fffffe001ee61b40 fffffe001ee61b40 dgram 0 0 0 fffffe02060dd870 0 0 fffffe02060dd870 dgram 0 0 fffffe001e786938 0 fffffe02060dd780 0 /var/run/logpriv fffffe02060dd960 dgram 0 0 fffffe001e786b10 0 fffffe001ee824b0 0 /var/run/log ------------------------------------------------------------------------ netstat -aL Current listen queue sizes (qlen/incqlen/maxqlen) Proto Listen Local Address tcp4 0/0/128 localhost.31416 tcp4 0/0/50 *.bacula-dir tcp4 0/0/128 *.ssh tcp6 0/0/128 *.ssh tcp4 0/0/50 *.bacula-fd tcp4 0/0/50 *.bacula-sd tcp4 0/0/128 *.ipp tcp6 0/0/128 *.ipp tcp4 0/0/20 localhost.submission tcp4 0/0/20 localhost.smtp tcp4 0/0/20 borg.submission tcp4 0/0/20 borg.smtp tcp4 0/0/128 localhost.postgresql tcp6 0/0/128 localhost.postgresql tcp4 0/0/5 *.3551 tcp6 0/0/5 *.nfsd tcp4 0/0/5 *.nfsd tcp4 0/0/128 *.977 tcp6 0/0/128 *.977 tcp4 0/0/128 *.sunrpc tcp6 0/0/128 *.sunrpc unix 0/0/128 /var/run/cups.sock unix 0/0/128 /tmp/.s.PGSQL.5432 unix 0/0/128 /var/run/rpcbind.sock unix 0/0/4 /var/run/devd.pipe ------------------------------------------------------------------------ fstat fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read file 10 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read file 10 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read file 10 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read file 10 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read file 10 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read file 10 at 0xffff fstat: can't read file 13 at 0xfffffffffffffff fstat: can't read file 14 at 0x78 fstat: can't read file 16 at 0xffff fstat: can't read file 19 at 0xfffffffffffffff fstat: can't read file 20 at 0x78 fstat: can't read file 22 at 0xffff fstat: can't read file 23 at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read file 10 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read file 10 at 0xffff fstat: can't read file 13 at 0xfffffffffffffff fstat: can't read file 14 at 0x78 fstat: can't read file 16 at 0xffff fstat: can't read file 19 at 0xfffffffffffffff fstat: can't read file 20 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root cpucontrol 1378 root - - error - root cpucontrol 1378 wd - - error - root cpucontrol 1378 text - - error - root cpucontrol 1378 ctty /dev 169 crw--w---- pts/0 rw root cpucontrol 1378 0 /dev 169 crw--w---- pts/0 rw root sh 1372 root - - error - root sh 1372 wd - - error - root sh 1372 text - - error - root sh 1372 ctty /dev 169 crw--w---- pts/0 rw root sh 1372 0 /dev 169 crw--w---- pts/0 rw root sh 1372 6 /dev 169 crw--w---- pts/0 rw boinc wcgrid_faah_7.15_i 1362 root - - error - boinc wcgrid_faah_7.15_i 1362 wd - - error - boinc wcgrid_faah_7.15_i 1362 text - - error - boinc wcgrid_faah_7.15_i 1362 0 /dev 30 crw-rw-rw- null rw boinc wcgrid_faah_7.15_i 1362 6 /dev 30 crw-rw-rw- null rw boinc wcgrid_faah_7.15_i 1361 root - - error - boinc wcgrid_faah_7.15_i 1361 wd - - error - boinc wcgrid_faah_7.15_i 1361 text - - error - boinc wcgrid_faah_7.15_i 1361 0 /dev 30 crw-rw-rw- null rw boinc wcgrid_faah_7.15_i 1361 6 /dev 30 crw-rw-rw- null rw boinc wcgrid_faah_7.15_i 1360 root - - error - boinc wcgrid_faah_7.15_i 1360 wd - - error - boinc wcgrid_faah_7.15_i 1360 text - - error - boinc wcgrid_faah_7.15_i 1360 0 /dev 30 crw-rw-rw- null rw boinc wcgrid_faah_7.15_i 1360 6 /dev 30 crw-rw-rw- null rw boinc wcgrid_faah_7.15_i 1359 root - - error - boinc wcgrid_faah_7.15_i 1359 wd - - error - boinc wcgrid_faah_7.15_i 1359 text - - error - boinc wcgrid_faah_7.15_i 1359 0 /dev 30 crw-rw-rw- null rw boinc wcgrid_faah_7.15_i 1359 6 /dev 30 crw-rw-rw- null rw boinc wcgrid_faah_7.15_i 1358 root - - error - boinc wcgrid_faah_7.15_i 1358 wd - - error - boinc wcgrid_faah_7.15_i 1358 text - - error - boinc wcgrid_faah_7.15_i 1358 0 /dev 30 crw-rw-rw- null rw boinc wcgrid_faah_7.15_i 1358 6 /dev 30 crw-rw-rw- null rw boinc wcgrid_faah_7.15_i 1357 root - - error - boinc wcgrid_faah_7.15_i 1357 wd - - error - boinc wcgrid_faah_7.15_i 1357 text - - error - boinc wcgrid_faah_7.15_i 1357 0 /dev 30 crw-rw-rw- null rw boinc wcgrid_faah_7.15_i 1357 6 /dev 30 crw-rw-rw- null rw boinc wcgrid_faah_7.15_i 1356 root - - error - boinc wcgrid_faah_7.15_i 1356 wd - - error - boinc wcgrid_faah_7.15_i 1356 text - - error - boinc wcgrid_faah_7.15_i 1356 0 /dev 30 crw-rw-rw- null rw boinc wcgrid_faah_7.15_i 1356 6 /dev 30 crw-rw-rw- null rw boinc wcgrid_cep2_6.40_i 1355 root - - error - boinc wcgrid_cep2_6.40_i 1355 wd - - error - boinc wcgrid_cep2_6.40_i 1355 text - - error - boinc wcgrid_cep2_6.40_i 1355 0 /dev 30 crw-rw-rw- null rw boinc wcgrid_cep2_6.40_i 1355 6 - - error - boinc wcgrid_faah_7.15_i 1354 root - - error - boinc wcgrid_faah_7.15_i 1354 wd - - error - boinc wcgrid_faah_7.15_i 1354 text - - error - boinc wcgrid_faah_7.15_i 1354 0 /dev 30 crw-rw-rw- null rw boinc wcgrid_faah_7.15_i 1354 6 /dev 30 crw-rw-rw- null rw boinc wcgrid_cep2_6.40_i 1353 root - - error - boinc wcgrid_cep2_6.40_i 1353 wd - - error - boinc wcgrid_cep2_6.40_i 1353 text - - error - boinc wcgrid_cep2_6.40_i 1353 0 /dev 30 crw-rw-rw- null rw boinc wcgrid_cep2_6.40_i 1353 6 - - error - boinc wcgrid_faah_7.15_i 1352 root - - error - boinc wcgrid_faah_7.15_i 1352 wd - - error - boinc wcgrid_faah_7.15_i 1352 text - - error - boinc wcgrid_faah_7.15_i 1352 0 /dev 30 crw-rw-rw- null rw boinc wcgrid_faah_7.15_i 1352 6 /dev 30 crw-rw-rw- null rw boinc wcgrid_faah_7.15_i 1351 root - - error - boinc wcgrid_faah_7.15_i 1351 wd - - error - boinc wcgrid_faah_7.15_i 1351 text - - error - boinc wcgrid_faah_7.15_i 1351 0 /dev 30 crw-rw-rw- null rw boinc wcgrid_faah_7.15_i 1351 6 /dev 30 crw-rw-rw- null rw boinc wcgrid_faah_7.15_i 1350 root - - error - boinc wcgrid_faah_7.15_i 1350 wd - - error - boinc wcgrid_faah_7.15_i 1350 text - - error - boinc wcgrid_faah_7.15_i 1350 0 /dev 30 crw-rw-rw- null rw boinc wcgrid_faah_7.15_i 1350 6 /dev 30 crw-rw-rw- null rw boinc wcgrid_faah_7.15_i 1349 root - - error - boinc wcgrid_faah_7.15_i 1349 wd - - error - boinc wcgrid_faah_7.15_i 1349 text - - error - boinc wcgrid_faah_7.15_i 1349 0 /dev 30 crw-rw-rw- null rw boinc wcgrid_faah_7.15_i 1349 6 /dev 30 crw-rw-rw- null rw boinc wcgrid_faah_7.15_i 1348 root - - error - boinc wcgrid_faah_7.15_i 1348 wd - - error - boinc wcgrid_faah_7.15_i 1348 text - - error - boinc wcgrid_faah_7.15_i 1348 0 /dev 30 crw-rw-rw- null rw boinc wcgrid_faah_7.15_i 1348 6 /dev 30 crw-rw-rw- null rw boinc wcgrid_cep2_6.40_i 1347 root - - error - boinc wcgrid_cep2_6.40_i 1347 wd - - error - boinc wcgrid_cep2_6.40_i 1347 text - - error - boinc wcgrid_cep2_6.40_i 1347 0 /dev 30 crw-rw-rw- null rw boinc wcgrid_cep2_6.40_i 1347 6 - - error - boinc wcgrid_faah_7.15_i 1346 root - - error - boinc wcgrid_faah_7.15_i 1346 wd - - error - boinc wcgrid_faah_7.15_i 1346 text - - error - boinc wcgrid_faah_7.15_i 1346 0 /dev 30 crw-rw-rw- null rw boinc wcgrid_faah_7.15_i 1346 6 /dev 30 crw-rw-rw- null rw root sh 1345 root - - error - root sh 1345 wd - - error - root sh 1345 text - - error - root sh 1345 ctty /dev 169 crw--w---- pts/0 rw root sh 1345 0 /dev 169 crw--w---- pts/0 rw root sh 1345 6 /dev 169 crw--w---- pts/0 rw root sudo 1344 root - - error - root sudo 1344 wd - - error - root sudo 1344 text - - error - root sudo 1344 ctty /dev 169 crw--w---- pts/0 rw root sudo 1344 0 /dev 169 crw--w---- pts/0 rw ler sh 1342 root - - error - ler sh 1342 wd - - error - ler sh 1342 text - - error - ler sh 1342 ctty /dev 169 crw--w---- pts/0 rw ler sh 1342 0 /dev 169 crw--w---- pts/0 rw ler sh 1342 6 /dev 169 crw--w---- pts/0 rw ler sshd 1341 root - - error - ler sshd 1341 wd - - error - ler sshd 1341 text - - error - ler sshd 1341 0 /dev 30 crw-rw-rw- null rw ler sshd 1341 6 /dev 30 crw-rw-rw- null rw root sshd 1339 root - - error - root sshd 1339 wd - - error - root sshd 1339 text - - error - root sshd 1339 0 /dev 30 crw-rw-rw- null r root sshd 1339 6 /dev 30 crw-rw-rw- null rw root getty 1337 root - - error - root getty 1337 wd - - error - root getty 1337 text - - error - root getty 1337 ctty /dev 83 crw------- ttyv7 rw root getty 1337 0 /dev 83 crw------- ttyv7 rw root getty 1336 root - - error - root getty 1336 wd - - error - root getty 1336 text - - error - root getty 1336 ctty /dev 82 crw------- ttyv6 rw root getty 1336 0 /dev 82 crw------- ttyv6 rw root getty 1335 root - - error - root getty 1335 wd - - error - root getty 1335 text - - error - root getty 1335 ctty /dev 81 crw------- ttyv5 rw root getty 1335 0 /dev 81 crw------- ttyv5 rw root getty 1334 root - - error - root getty 1334 wd - - error - root getty 1334 text - - error - root getty 1334 ctty /dev 80 crw------- ttyv4 rw root getty 1334 0 /dev 80 crw------- ttyv4 rw root getty 1333 root - - error - root getty 1333 wd - - error - root getty 1333 text - - error - root getty 1333 ctty /dev 79 crw------- ttyv3 rw root getty 1333 0 /dev 79 crw------- ttyv3 rw root getty 1332 root - - error - root getty 1332 wd - - error - root getty 1332 text - - error - root getty 1332 ctty /dev 78 crw------- ttyv2 rw root getty 1332 0 /dev 78 crw------- ttyv2 rw root getty 1331 root - - error - root getty 1331 wd - - error - root getty 1331 text - - error - root getty 1331 ctty /dev 77 crw------- ttyv1 rw root getty 1331 0 /dev 77 crw------- ttyv1 rw root getty 1330 root - - error - root getty 1330 wd - - error - root getty 1330 text - - error - root getty 1330 ctty /dev 76 crw------- ttyv0 rw root getty 1330 0 /dev 76 crw------- ttyv0 rw root sleep 1328 root - - error - root sleep 1328 wd - - error - root sleep 1328 text - - error - root sleep 1328 0 /dev 30 crw-rw-rw- null r root logger 1327 root - - error - root logger 1327 wd - - error - root logger 1327 text - - error - root logger 1327 0* pipe fffffe001e7bfba0 <-> fffffe001e7bfd00 0 rw root sh 1326 root - - error - root sh 1326 wd - - error - root sh 1326 text - - error - root sh 1326 0 /dev 30 crw-rw-rw- null r root inetd 1310 root - - error - root inetd 1310 wd - - error - root inetd 1310 text - - error - root inetd 1310 0 /dev 30 crw-rw-rw- null rw root cron 1288 root - - error - root cron 1288 wd - - error - root cron 1288 text - - error - root cron 1288 0 /dev 30 crw-rw-rw- null rw root sshd 1276 root - - error - root sshd 1276 wd - - error - root sshd 1276 text - - error - root sshd 1276 0 /dev 30 crw-rw-rw- null rw bacula bacula-dir 1271 root - - error - bacula bacula-dir 1271 wd - - error - bacula bacula-dir 1271 text - - error - bacula bacula-dir 1271 0 /dev 30 crw-rw-rw- null r root bacula-fd 1268 root - - error - root bacula-fd 1268 wd - - error - root bacula-fd 1268 text - - error - root bacula-fd 1268 0 /dev 30 crw-rw-rw- null r bacula bacula-sd 1265 root - - error - bacula bacula-sd 1265 wd - - error - bacula bacula-sd 1265 text - - error - bacula bacula-sd 1265 0 /dev 30 crw-rw-rw- null r boinc boinc_client 1261 root - - error - boinc boinc_client 1261 wd - - error - boinc boinc_client 1261 text - - error - boinc boinc_client 1261 0 /dev 30 crw-rw-rw- null rw boinc boinc_client 1261 6 - - error - root cupsd 1255 root - - error - root cupsd 1255 wd - - error - root cupsd 1255 text - - error - root cupsd 1255 0 /dev 30 crw-rw-rw- null r root cupsd 1255 6 /dev 30 crw-rw-rw- null w root cupsd 1255 12 /dev 30 crw-rw-rw- null w mailnull exim-4.80.1-2 1246 root - - error - mailnull exim-4.80.1-2 1246 wd - - error - mailnull exim-4.80.1-2 1246 text - - error - mailnull exim-4.80.1-2 1246 0 /dev 30 crw-rw-rw- null rw mailnull exim-4.80.1-2 1246 6 /dev 30 crw-rw-rw- null rw pgsql postgres 1156 root - - error - pgsql postgres 1156 wd - - error - pgsql postgres 1156 text - - error - pgsql postgres 1156 0 /dev 30 crw-rw-rw- null r pgsql postgres 1156 6 - - error - pgsql postgres 1155 root - - error - pgsql postgres 1155 wd - - error - pgsql postgres 1155 text - - error - pgsql postgres 1155 0 /dev 30 crw-rw-rw- null r pgsql postgres 1155 6 - - error - pgsql postgres 1154 root - - error - pgsql postgres 1154 wd - - error - pgsql postgres 1154 text - - error - pgsql postgres 1154 0 /dev 30 crw-rw-rw- null r pgsql postgres 1154 6 - - error - pgsql postgres 1153 root - - error - pgsql postgres 1153 wd - - error - pgsql postgres 1153 text - - error - pgsql postgres 1153 0 /dev 30 crw-rw-rw- null r pgsql postgres 1153 6 - - error - pgsql postgres 1149 root - - error - pgsql postgres 1149 wd - - error - pgsql postgres 1149 text - - error - pgsql postgres 1149 0 /dev 30 crw-rw-rw- null r pgsql postgres 1149 6 - - error - root smartd 1140 root - - error - root smartd 1140 wd - - error - root smartd 1140 text - - error - root smartd 1140 0 /dev 30 crw-rw-rw- null rw root perl 1136 root - - error - root perl 1136 wd - - error - root perl 1136 text - - error - root perl 1136 0 - - error - root ng_queue 1124 root - - error - root ng_queue 1124 wd - - error - root ntpd 1103 root - - error - root ntpd 1103 wd - - error - root ntpd 1103 text - - error - root ntpd 1103 0 /dev 30 crw-rw-rw- null rw root ntpd 1103 6 /dev 30 crw-rw-rw- null rw root ntpd 1103 12 /dev 30 crw-rw-rw- null rw root ntpd 1103 18* local dgram fffffe001eeb02d0 <-> fffffe02060dd870 root apcupsd 1072 root - - error - root apcupsd 1072 wd - - error - root apcupsd 1072 text - - error - root apcupsd 1072 0 /dev 30 crw-rw-rw- null r root apcupsd 1072 6 /dev 30 crw-rw-rw- null r root nfsd 1064 root - - error - root nfsd 1064 wd - - error - root nfsd 1064 text - - error - root nfsd 1064 0 /dev 30 crw-rw-rw- null rw root nfsd 1062 root - - error - root nfsd 1062 wd - - error - root nfsd 1062 text - - error - root nfsd 1062 0 /dev 30 crw-rw-rw- null rw root nfsd 1062 6 /dev 30 crw-rw-rw- null rw root mountd 1056 root - - error - root mountd 1056 wd - - error - root mountd 1056 text - - error - root mountd 1056 0 /dev 30 crw-rw-rw- null rw root mountd 1056 6 /dev 30 crw-rw-rw- null rw root rpcbind 1021 root - - error - root rpcbind 1021 wd - - error - root rpcbind 1021 text - - error - root rpcbind 1021 0 /dev 30 crw-rw-rw- null rw root rpcbind 1021 6 /dev 30 crw-rw-rw- null rw root watchdogd 1007 root - - error - root watchdogd 1007 wd - - error - root watchdogd 1007 text - - error - root watchdogd 1007 0 /dev 30 crw-rw-rw- null rw root syslogd 1004 root - - error - root syslogd 1004 wd - - error - root syslogd 1004 text - - error - root syslogd 1004 0 /dev 30 crw-rw-rw- null rw root syslogd 1004 6 /dev 30 crw-rw-rw- null rw root syslogd 1004 12 /dev 30 crw-rw-rw- null rw root syslogd 1004 18 - - error - root devd 866 root - - error - root devd 866 wd - - error - root devd 866 text - - error - root devd 866 0 /dev 30 crw-rw-rw- null rw root devd 866 6 /dev 30 crw-rw-rw- null rw root moused 847 root - - error - root moused 847 wd - - error - root moused 847 text - - error - root moused 847 0 /dev 30 crw-rw-rw- null rw root init 1 root - - error - root init 1 wd - - error - root init 1 text - - error - root kernel 0 root - - error - root kernel 0 wd - - error - ------------------------------------------------------------------------ dmesg Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #16: Sat Aug 10 13:45:06 CDT 2013 root@borg.lerctr.org:/usr/obj/usr/src/sys/BORG-DTRACE amd64 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz (2327.55-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Family = 0x6 Model = 0x17 Stepping = 6 Features=0xbfebfbff Features2=0xce3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 68719476736 (65536 MB) avail memory = 65660014592 (62618 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 netmap: loaded module random: initialized cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) unknown: I/O range not supported cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 350 Event timer "HPET1" frequency 14318180 Hz quality 340 Event timer "HPET2" frequency 14318180 Hz quality 340 atrtc0: port 0x70-0x71 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 0.0 on pci1 pci2: on pcib2 pcib3: irq 16 at device 0.0 on pci2 pci3: on pcib3 pcib4: at device 0.0 on pci3 pci4: on pcib4 pcib5: at device 0.2 on pci3 pci5: on pcib5 pcib6: irq 18 at device 2.0 on pci2 pci6: on pcib6 em0: port 0x2000-0x201f mem 0xd9220000-0xd923ffff,0xd9200000-0xd921ffff irq 18 at device 0.0 on pci6 em0: Using an MSI interrupt em0: Ethernet address: 00:30:48:f2:29:9c 001.000009 netmap_attach [2244] success for em0 em1: port 0x2020-0x203f mem 0xd9260000-0xd927ffff,0xd9240000-0xd925ffff irq 19 at device 0.1 on pci6 em1: Using an MSI interrupt em1: Ethernet address: 00:30:48:f2:29:9d 001.000010 netmap_attach [2244] success for em1 pcib7: at device 0.3 on pci1 pci7: on pcib7 pcib8: at device 4.0 on pci0 pci8: on pcib8 vgapci0: port 0x3000-0x307f mem 0xd8000000-0xd8ffffff,0xc0000000-0xc7ffffff,0xc8000000-0xc9ffffff irq 16 at device 0.0 on pci8 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io pci8: at device 0.1 (no driver attached) pcib9: at device 6.0 on pci0 pci9: on pcib9 pci0: at device 8.0 (no driver attached) pcib10: irq 17 at device 28.0 on pci0 pci10: on pcib10 pcib11: irq 16 at device 0.0 on pci10 pci11: on pcib11 pcm0: port 0x4080-0x409f,0x4000-0x407f irq 16 at device 0.0 on pci11 pcm0: system configuration SubVendorID: 0x1412, SubDeviceID: 0x2403 XIN2 Clock Source: 24.576MHz(96kHz*256) MPU-401 UART(s) #: not implemented ADC #: 1 and SPDIF receiver connected DAC #: 4 Multi-track converter type: AC'97(SDATA_OUT:packed) S/PDIF(IN/OUT): 1/1 ID# 0x00 GPIO(mask/dir/state): 0xff/0xff/0xff uhci0: port 0x1800-0x181f irq 17 at device 29.0 on pci0 usbus0 on uhci0 uhci1: port 0x1820-0x183f irq 19 at device 29.1 on pci0 usbus1 on uhci1 uhci2: port 0x1840-0x185f irq 18 at device 29.2 on pci0 usbus2 on uhci2 ehci0: mem 0xd9600400-0xd96007ff irq 17 at device 29.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 pcib12: at device 30.0 on pci0 pci12: on pcib12 vgapci1: port 0x5000-0x50ff mem 0xd0000000-0xd7ffffff,0xd9300000-0xd930ffff irq 18 at device 1.0 on pci12 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0 ata0: at channel 0 on atapci0 ahci0: port 0x18a0-0x18a7,0x1874-0x1877,0x1878-0x187f,0x1870-0x1873,0x1880-0x189f mem 0xd9600800-0xd9600bff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.10 with 6 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 ichsmb0: port 0x1100-0x111f irq 19 at device 31.3 on pci0 smbus0: on ichsmb0 acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ichwd0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 coretemp2: on cpu2 est2: on cpu2 p4tcc2: on cpu2 coretemp3: on cpu3 est3: on cpu3 p4tcc3: on cpu3 coretemp4: on cpu4 est4: on cpu4 p4tcc4: on cpu4 coretemp5: on cpu5 est5: on cpu5 p4tcc5: on cpu5 coretemp6: on cpu6 est6: on cpu6 p4tcc6: on cpu6 coretemp7: on cpu7 est7: on cpu7 p4tcc7: on cpu7 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec vboxdrv: fAsync=0 offMin=0x395 offMax=0x50f usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ata0: DMA limited to UDMA33, controller found non-ATA66 cable ada0 at ahcich0 bus 0 scbus1 target 0 lun 0 ada0: ATA-8 SATA 3.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada0: quirks=0x1<4K> ada0: Previously was known as ad4 ada1 at ahcich1 bus 0 scbus2 target 0 lun 0 ada1: ATA-8 SATA 3.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada1: quirks=0x1<4K> ada1: Previously was known as ad6 ada2 at ahcich2 bus 0 scbus3 target 0 lun 0 ada2: ATA-8 SATA 3.x device ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada2: quirks=0x1<4K> ada2: Previously was known as ad8 ada3 at ahcich3 bus 0 scbus4 target 0 lun 0 ada3: ATA-8 SATA 3.x device ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada3: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada3: quirks=0x1<4K> ada3: Previously was known as ad10 ada4 at ahcich4 bus 0 scbus5 target 0 lun 0 ada4: ATA-8 SATA 3.x device ada4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada4: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada4: quirks=0x1<4K> ada4: Previously was known as ad12 ada5 at ahcich5 bus 0 scbus6 target 0 lun 0 ada5: ATA-8 SATA 3.x device ada5: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada5: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada5: quirks=0x1<4K> ada5: Previously was known as ad14 cd0 at ata0 bus 0 scbus0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present SMP: AP CPU #6 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #5 Launched! uhub1: 2 ports with 2 removable, self powered uhub0: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered Root mount waiting for: usbus3 uhub3: 6 ports with 6 removable, self powered Root mount waiting for: usbus3 Root mount waiting for: usbus3 ugen3.2: at usbus3 ukbd0: on usbus3 kbd2 at ukbd0 Trying to mount root from zfs:zroot/ROOT/default []... ugen0.2: at usbus0 ugen0.3: at usbus0 ffclock reset: HPET (14318180 Hz), time = 1376160821.500000000 Setting hostuuid: 53d19f64-d663-a017-8922-0030488e9ff3. Setting hostid: 0xf53a926e. Entropy harvesting: interrupts ethernet point_to_point kickstart. Starting file system checks: Mounting local file systems:. Writing entropy file:. Setting hostname: borg.lerctr.org. Starting Network: lo0 em0 em1. lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff000000 nd6 options=21 em0: flags=8843 metric 0 mtu 1500 options=4219b ether 00:30:48:f2:29:9c inet 192.168.200.4 netmask 0xffffff00 broadcast 192.168.200.255 inet6 fe80::230:48ff:fef2:299c%em0 prefixlen 64 scopeid 0x1 nd6 options=29 media: Ethernet autoselect status: no carrier em1: flags=8c02 metric 0 mtu 1500 options=4219b ether 00:30:48:f2:29:9d nd6 options=29 media: Ethernet autoselect status: no carrier Starting devd. Starting Network: em1. em1: flags=8c02 metric 0 mtu 1500 options=4219b ether 00:30:48:f2:29:9d nd6 options=29 media: Ethernet autoselect status: no carrier uhid0: on usbus3 ums0: on usbus0 ums0: 5 buttons and [XYZ] coordinates ID=0 Starting ums0 moused. add net default: gateway 192.168.200.11 add net fe80::: gateway ::1 add net ff02::: gateway ::1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 Mounting NFS file systems:. ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/kde4/lib /usr/local/lib/compat /usr/local/lib/dbmail /usr/local/lib/event2 /usr/local/lib/pth /usr/local/lib/qt4 /usr/local/lib/virtualbox 32-bit compatibility ldconfig path: /usr/lib32 /usr/local/lib32/compat Creating and/or trimming log files. Starting syslogd. Starting watchdogd. No core dumps found. Additional ABI support: linux. Starting rpcbind. NFS access cache time=60 Clearing /tmp (X related). Starting mountd. NFSv4 is disabled Starting nfsd. Starting apcupsd. Updating motd:. Mounting late file systems:. Starting ntpd. Starting sshblock. Starting smartd. Starting exim. Starting cupsd. Starting boinc_client. Starting bacula_sd. Starting bacula_fd. Starting bacula_dir. Performing sanity check on sshd configuration. Starting sshd. Configuring syscons: blanktime. Starting cron. mixer: WRITE_MIXER: Device not configured mixer: WRITE_MIXER: Device not configured mixer: WRITE_MIXER: Device not configured mixer: WRITE_MIXER: Device not configured mixer: WRITE_MIXER: Device not configured mixer: WRITE_MIXER: Device not configured Starting inetd. Starting background file system checks in 60 seconds. Sat Aug 10 13:54:18 CDT 2013 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x5e fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80709be9 stack pointer = 0x28:0xffffff900d55c860 frame pointer = 0x28:0xffffff900d55c870 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1378 (cpucontrol) trap number = 12 panic: page fault cpuid = 0 Uptime: 1m48s Dumping 2337 out of 64479 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% ------------------------------------------------------------------------ kernel config options CONFIG_AUTOGENERATED ident BORG-DTRACE machine amd64 cpu HAMMER makeoptions WITH_CTF=1 makeoptions DEBUG=-g options FFCLOCK options USB_DEBUG options RDRAND_RNG options PADLOCK_RNG options ATH_ENABLE_11N options AH_AR5416_INTERRUPT_MITIGATION options AH_SUPPORT_AR5416 options IEEE80211_SUPPORT_MESH options IEEE80211_AMPDU_AGE options IEEE80211_DEBUG options SC_PIXEL_MODE options VESA options AHD_REG_PRETTY_PRINT options AHC_REG_PRETTY_PRINT options ATA_STATIC_ID options SMP options MALLOC_DEBUG_MAXZONES=8 options KDB_TRACE options INCLUDE_CONFIG_FILE options DDB_CTF options KDTRACE_HOOKS options KDTRACE_FRAME options MAC options CAPABILITIES options CAPABILITY_MODE options AUDIT options HWPMC_HOOKS options KBD_INSTALL_CDEV options PRINTF_BUFR_SIZE=128 options _KPOSIX_PRIORITY_SCHEDULING options SYSVSEM options SYSVMSG options SYSVSHM options STACK options KTRACE options SCSI_DELAY=5000 options COMPAT_FREEBSD7 options COMPAT_FREEBSD6 options COMPAT_FREEBSD5 options COMPAT_FREEBSD4 options COMPAT_FREEBSD32 options GEOM_LABEL options GEOM_RAID options GEOM_PART_GPT options PSEUDOFS options PROCFS options CD9660 options MSDOSFS options NFS_ROOT options NFSLOCKD options NFSD options NFSCL options QUOTA options SCTP options TCP_OFFLOAD options INET6 options INET options PREEMPTION options SCHED_ULE options NEW_PCIB options GEOM_PART_MBR options GEOM_PART_EBR_COMPAT options GEOM_PART_EBR options GEOM_PART_BSD device isa device mem device io device uart_ns8250 device cpufreq device acpi device pci device fdc device ahci device ata device esp device isci device scbus device ch device da device sa device cd device pass device ses device hptnr device aacraid device atkbdc device atkbd device psm device kbdmux device vga device splash device sc device agp device uart device ppc device ppbus device lpt device ppi device em device miibus device cas device gem device hme device nfe device nge device loop device random device ether device vlan device tun device md device gif device faith device firmware device bpf device uhci device ohci device ehci device xhci device usb device ukbd device umass device virtio device virtio_pci device vtnet device virtio_blk device virtio_scsi device virtio_balloon device netmap ------------------------------------------------------------------------ ddb capture buffer ddb: ddb_capture: kvm_nlist -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 19:17:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 54480E3D for ; Sat, 10 Aug 2013 19:17:53 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C1F9D2BFC for ; Sat, 10 Aug 2013 19:17:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=Zn+mr75Sb4ycPV9cZePenzYFQxAdSDFNJhE9i8Adn0g=; b=fiU+1tHJqnYFjcyNxBYPiVxPImuA+UKfZbf5/1NKWS9ONzw01HkFKtzbNJY6Zare5sZVJN/tIdJzxbbsLILuMDRmpK4YZFDtHHXD4FUFDg2oU9yQqNXvJtL49QS9wAltZUMP32+O0KpTPZEiAIlTCAQygyltU+n169Cn/5KiLJc=; Received: from localhost.lerctr.org ([127.0.0.1]:38073 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpa (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1V8EfW-0006uj-3K for freebsd-current@freebsd.org; Sat, 10 Aug 2013 14:17:51 -0500 Received: from cpe-72-182-93-216.austin.res.rr.com ([72.182.93.216]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Sat, 10 Aug 2013 14:17:40 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 10 Aug 2013 14:17:40 -0500 From: Larry Rosenman To: freebsd-current@freebsd.org Subject: Re: crash with cpucontrol/microcode update : Today's -CURRENT In-Reply-To: References: Message-ID: X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/0.9.2 X-Spam-Score: 2.6 (++) X-LERCTR-Spam-Score: 2.6 (++) X-Spam-Report: SpamScore (2.6/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, KAM_STOCKTIP=5.5, RP_MATCHES_RCVD=-0.001 X-LERCTR-Spam-Report: SpamScore (2.6/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, KAM_STOCKTIP=5.5, RP_MATCHES_RCVD=-0.001 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: Sat, 10 Aug 2013 19:17:53 -0000 On 2013-08-10 14:06, Larry Rosenman wrote: > I'm getting the following @R254183: > when I try to run the microcode_update. > > Just started with yesterday's -CURRENT. > > I can supply the full vmcore and ssh access. > > > borg.lerctr.org dumped core - see /var/crash/vmcore.7 > > Sat Aug 10 14:00:00 CDT 2013 > > FreeBSD borg.lerctr.org 10.0-CURRENT FreeBSD 10.0-CURRENT #16: Sat Aug > 10 13:45:06 CDT 2013 > root@borg.lerctr.org:/usr/obj/usr/src/sys/BORG-DTRACE amd64 > > panic: page fault > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and > you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 1378 (cpucontrol) > trap number = 12 > panic: page fault > cpuid = 0 > Uptime: 1m48s > Dumping 2337 out of 64479 > MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% > > Reading symbols from /boot/kernel/zfs.ko.symbols...done. > Loaded symbols for /boot/kernel/zfs.ko.symbols > Reading symbols from /boot/kernel/acl_nfs4.ko.symbols...done. > Loaded symbols for /boot/kernel/acl_nfs4.ko.symbols > Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. > Loaded symbols for /boot/kernel/opensolaris.ko.symbols > Reading symbols from /boot/kernel/linux.ko.symbols...done. > Loaded symbols for /boot/kernel/linux.ko.symbols > Reading symbols from /boot/kernel/snd_envy24ht.ko.symbols...done. > Loaded symbols for /boot/kernel/snd_envy24ht.ko.symbols > Reading symbols from /boot/kernel/snd_spicds.ko.symbols...done. > Loaded symbols for /boot/kernel/snd_spicds.ko.symbols > Reading symbols from /boot/kernel/sound.ko.symbols...done. > Loaded symbols for /boot/kernel/sound.ko.symbols > Reading symbols from /boot/kernel/coretemp.ko.symbols...done. > Loaded symbols for /boot/kernel/coretemp.ko.symbols > Reading symbols from /boot/kernel/ichsmb.ko.symbols...done. > Loaded symbols for /boot/kernel/ichsmb.ko.symbols > Reading symbols from /boot/kernel/smbus.ko.symbols...done. > Loaded symbols for /boot/kernel/smbus.ko.symbols > Reading symbols from /boot/kernel/ichwd.ko.symbols...done. > Loaded symbols for /boot/kernel/ichwd.ko.symbols > Reading symbols from /boot/kernel/cpuctl.ko.symbols...done. > Loaded symbols for /boot/kernel/cpuctl.ko.symbols > Reading symbols from /boot/kernel/crypto.ko.symbols...done. > Loaded symbols for /boot/kernel/crypto.ko.symbols > Reading symbols from /boot/kernel/cryptodev.ko.symbols...done. > Loaded symbols for /boot/kernel/cryptodev.ko.symbols > Reading symbols from /boot/kernel/dtraceall.ko.symbols...done. > Loaded symbols for /boot/kernel/dtraceall.ko.symbols > Reading symbols from /boot/kernel/profile.ko.symbols...done. > Loaded symbols for /boot/kernel/profile.ko.symbols > Reading symbols from /boot/kernel/cyclic.ko.symbols...done. > Loaded symbols for /boot/kernel/cyclic.ko.symbols > Reading symbols from /boot/kernel/dtrace.ko.symbols...done. > Loaded symbols for /boot/kernel/dtrace.ko.symbols > Reading symbols from /boot/kernel/systrace_freebsd32.ko.symbols...done. > Loaded symbols for /boot/kernel/systrace_freebsd32.ko.symbols > Reading symbols from /boot/kernel/systrace.ko.symbols...done. > Loaded symbols for /boot/kernel/systrace.ko.symbols > Reading symbols from /boot/kernel/sdt.ko.symbols...done. > Loaded symbols for /boot/kernel/sdt.ko.symbols > Reading symbols from /boot/kernel/lockstat.ko.symbols...done. > Loaded symbols for /boot/kernel/lockstat.ko.symbols > Reading symbols from /boot/kernel/fasttrap.ko.symbols...done. > Loaded symbols for /boot/kernel/fasttrap.ko.symbols > Reading symbols from /boot/kernel/fbt.ko.symbols...done. > Loaded symbols for /boot/kernel/fbt.ko.symbols > Reading symbols from /boot/kernel/dtnfscl.ko.symbols...done. > Loaded symbols for /boot/kernel/dtnfscl.ko.symbols > Reading symbols from /boot/kernel/dtmalloc.ko.symbols...done. > Loaded symbols for /boot/kernel/dtmalloc.ko.symbols > Reading symbols from /boot/kernel/dtio.ko.symbols...done. > Loaded symbols for /boot/kernel/dtio.ko.symbols > Reading symbols from /boot/modules/vboxdrv.ko...done. > Loaded symbols for /boot/modules/vboxdrv.ko > Reading symbols from /boot/modules/nvidia.ko...done. > Loaded symbols for /boot/modules/nvidia.ko > Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. > Loaded symbols for /boot/kernel/fdescfs.ko.symbols > Reading symbols from /boot/kernel/uhid.ko.symbols...done. > Loaded symbols for /boot/kernel/uhid.ko.symbols > Reading symbols from /boot/kernel/ums.ko.symbols...done. > Loaded symbols for /boot/kernel/ums.ko.symbols > Reading symbols from /boot/modules/vboxnetflt.ko...done. > Loaded symbols for /boot/modules/vboxnetflt.ko > Reading symbols from /boot/kernel/netgraph.ko.symbols...done. > Loaded symbols for /boot/kernel/netgraph.ko.symbols > Reading symbols from /boot/kernel/ng_ether.ko.symbols...done. > Loaded symbols for /boot/kernel/ng_ether.ko.symbols > Reading symbols from /boot/modules/vboxnetadp.ko...done. > Loaded symbols for /boot/modules/vboxnetadp.ko > #0 doadump (textdump=) at pcpu.h:236 > 236 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=) at pcpu.h:236 > #1 0xffffffff8051d6f0 in kern_reboot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:447 > #2 0xffffffff8051da77 in panic (fmt=) > at /usr/src/sys/kern/kern_shutdown.c:754 > #3 0xffffffff80780d9a in trap_fatal (frame=, > eva=) at /usr/src/sys/amd64/amd64/trap.c:873 > #4 0xffffffff80781199 in trap_pfault (frame=0x0, usermode=0) > at /usr/src/sys/amd64/amd64/trap.c:731 > #5 0xffffffff80780792 in trap (frame=0xffffff900d55c7b0) > at /usr/src/sys/amd64/amd64/trap.c:463 > #6 0xffffffff8076ad02 in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:232 > #7 0xffffffff80709be9 in vm_page_unwire (m=0x0, activate=0) > at /usr/src/sys/vm/vm_page.c:2356 > #8 0xffffffff806fb4ed in kmem_unback (object=0xffffffff80c57550, > addr=, size=4096) at > /usr/src/sys/vm/vm_kern.c:404 > #9 0xffffffff806fb5a4 in kmem_free (vmem=0xffffffff80bd7780, > addr=18446741884987129872, size=4096) at > /usr/src/sys/vm/vm_kern.c:421 > #10 0xffffffff80506597 in contigfree (addr=0x0, size=4048, > type=0xffffffff812d5ea0) at /usr/src/sys/kern/kern_malloc.c:435 > #11 0xffffffff812d5a79 in cpuctl_ioctl (dev=, > cmd=, data=0xfffffe000d2a2f80 "0?c", > flags=, td=) > at /usr/src/sys/modules/cpuctl/../../dev/cpuctl/cpuctl.c:480 > #12 0xffffffff8041962f in devfs_ioctl_f (fp=0xfffffe001e68cbe0, > com=3222299396, data=0xfffffe000d2a2f80, cred= out>, > td=0xfffffe0252ebd490) at /usr/src/sys/fs/devfs/devfs_vnops.c:757 > #13 0xffffffff8056b3be in kern_ioctl (td=0xfffffe0252ebd490, > fd=, com=0) at file.h:306 > #14 0xffffffff8056b13f in sys_ioctl (td=0xfffffe0252ebd490, > uap=0xffffff900d55cb80) at /usr/src/sys/kern/sys_generic.c:693 > #15 0xffffffff80781697 in amd64_syscall (td=0xfffffe0252ebd490, > traced=0) > at subr_syscall.c:134 > #16 0xffffffff8076afeb in Xfast_syscall () > at /usr/src/sys/amd64/amd64/exception.S:391 > #17 0x000000080094b4ea in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > (kgdb) > > ------------------------------------------------------------------------ > ps -axl > > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND > 0 0 0 0 -8 0 0 0 - DLs - 0:02.61 > [kernel] > 0 1 0 0 52 0 9428 0 wait DLs - 0:00.26 [init] > 0 2 0 0 -16 0 0 0 ftcl DL - 0:00.00 > [ftcleanup] > 0 3 0 0 -16 0 0 0 crypto_w DL - 0:00.00 > [crypto] > 0 4 0 0 -16 0 0 0 crypto_r DL - 0:00.00 [crypto > returns > 0 5 0 0 -16 0 0 0 - DL - 0:00.00 [fdc0] > 0 6 0 0 -8 0 0 0 tx->tx_s DL - 0:00.09 > [zfskern] > 0 7 0 0 -16 0 0 0 waiting_ DL - 0:00.00 > [sctp_iterator] > 0 8 0 0 -16 0 0 0 ccb_scan DL - 0:00.00 > [xpt_thrd] > 0 9 0 0 -16 0 0 0 psleep DL - 0:00.00 > [pagedaemon] > 0 10 0 0 -16 0 0 0 audit_wo DL - 0:00.00 [audit] > 0 11 0 0 155 0 0 0 - RL - 6:08.99 [idle] > 0 12 0 0 -84 0 0 0 - WL - 0:00.43 [intr] > 0 13 0 0 -8 0 0 0 - DL - 0:00.38 [geom] > 0 14 0 0 -16 0 0 0 - DL - 0:00.01 > [yarrow] > 0 15 0 0 -68 0 0 0 - DL - 0:00.04 [usb] > 0 16 0 0 -20 0 0 0 VBoxIS DL - 0:00.00 [TIMER] > 0 17 0 0 -16 0 0 0 psleep DL - 0:00.00 > [vmdaemon] > 0 18 0 0 155 0 0 0 pgzero DL - 0:00.00 > [pagezero] > 0 19 0 0 -16 0 0 0 psleep DL - 0:00.00 > [bufdaemon] > 0 20 0 0 16 0 0 0 syncer DL - 0:00.00 > [syncer] > 0 21 0 0 -16 0 0 0 vlruwt DL - 0:00.00 [vnlru] > 0 847 1 0 52 0 16584 0 select Ds - 0:00.00 > [moused] > 0 866 1 0 20 0 13208 0 select Ds - 0:00.00 [devd] > 0 1004 1 0 20 0 14380 0 - Rs - 0:00.05 > [syslogd] > 0 1007 1 0 -52 0 6192 2104 nanslp Ds - 0:00.00 > [watchdogd] > 0 1021 1 0 20 0 16468 0 select Ds - 0:00.01 > [rpcbind] > 0 1056 1 0 52 0 38964 0 select Ds - 0:00.02 > [mountd] > 0 1062 1 0 52 0 36804 0 select Ds - 0:00.04 [nfsd] > 0 1064 1062 0 52 0 12228 0 rpcsvc D - 0:00.00 [nfsd] > 0 1072 1 0 52 0 32716 0 select Ds - 0:00.99 > [apcupsd] > 0 1103 1 0 20 0 25268 0 select Ds - 0:00.01 [ntpd] > 0 1124 0 0 -16 0 0 0 sleep DL - 0:00.00 > [ng_queue] > 0 1136 1 0 20 0 34748 0 nanslp Ds - 0:00.01 [perl] > 0 1140 1 0 52 0 30844 0 nanslp D - 0:00.43 > [smartd] > 70 1149 1 0 20 0 86688 0 select Ds - 0:00.23 > [postgres] > 70 1153 1149 0 20 0 86688 0 select Ds - 0:00.00 > [postgres] > 70 1154 1149 0 20 0 86688 0 select Ds - 0:00.00 > [postgres] > 70 1155 1149 0 20 0 86688 0 select Ds - 0:00.00 > [postgres] > 70 1156 1149 0 20 0 46392 0 select Ds - 0:00.00 > [postgres] > 26 1246 1 0 52 0 48804 0 select Ds - 0:00.00 > [exim-4.80.1-2] > 0 1255 1 0 20 0 103300 0 kqread Ds - 0:00.02 [cupsd] > 1028 1261 1 0 155 0 46764 0 select Ds - 0:00.07 > [boinc_client] > 910 1265 1 0 20 0 65436 0 uwait Ds - 0:00.00 > [bacula-sd] > 0 1268 1 0 20 0 65260 0 uwait Ds - 0:00.00 > [bacula-fd] > 910 1271 1 0 20 0 78464 0 uwait Ds - 0:00.00 > [bacula-dir] > 0 1276 1 0 20 0 56324 0 select Ds - 0:00.00 [sshd] > 0 1288 1 0 20 0 16472 0 nanslp Ds - 0:00.00 [cron] > 0 1310 1 0 52 0 18592 0 select Ds - 0:00.00 [inetd] > 0 1326 1 0 52 0 16944 0 wait D - 0:00.00 [sh] > 0 1327 1 0 52 0 12220 0 piperd D - 0:00.00 > [logger] > 0 1328 1326 0 52 0 8120 0 nanslp D - 0:00.00 [sleep] > 0 1330 1 0 52 0 14376 0 ttyin Ds+ - 0:00.01 [getty] > 0 1331 1 0 52 0 14376 0 ttyin Ds+ - 0:00.01 [getty] > 0 1332 1 0 52 0 14376 0 ttyin Ds+ - 0:00.01 [getty] > 0 1333 1 0 52 0 14376 0 ttyin Ds+ - 0:00.01 [getty] > 0 1334 1 0 52 0 14376 0 ttyin Ds+ - 0:00.01 [getty] > 0 1335 1 0 52 0 14376 0 ttyin Ds+ - 0:00.01 [getty] > 0 1336 1 0 52 0 14376 0 ttyin Ds+ - 0:00.00 [getty] > 0 1337 1 0 52 0 14376 0 ttyin Ds+ - 0:00.01 [getty] > 0 1339 1276 0 21 0 81592 0 select Ds - 0:00.00 [sshd] > 1002 1341 1339 0 20 0 81592 0 select D - 0:00.00 [sshd] > 1002 1342 1341 0 20 0 16944 0 wait Ds - 0:00.00 [sh] > 0 1344 1342 0 20 0 51140 0 select D - 0:00.00 [sudo] > 0 1345 1344 0 20 0 16944 0 wait D - 0:00.00 [sh] > 1028 1346 1261 0 155 19 86380 0 - RN - 0:00.94 > [wcgrid_faah_7. > 1028 1347 1261 0 155 19 1892 0 - RN - 0:00.04 > [wcgrid_cep2_6. > 1028 1348 1261 0 155 19 68404 0 - RN - 0:01.31 > [wcgrid_faah_7. > 1028 1349 1261 0 155 19 68404 0 - RN - 0:00.74 > [wcgrid_faah_7. > 1028 1350 1261 0 155 19 90036 0 - RN - 0:00.90 > [wcgrid_faah_7. > 1028 1351 1261 0 155 19 68412 0 - RN - 0:00.73 > [wcgrid_faah_7. > 1028 1352 1261 0 155 19 67892 0 - RN - 0:00.88 > [wcgrid_faah_7. > 1028 1353 1347 0 155 19 1892 0 i DN - 0:00.00 > [wcgrid_cep2_6. > 1028 1354 1261 0 155 19 76092 0 - RN - 0:00.80 > [wcgrid_faah_7. > 1028 1355 1353 0 155 19 1892 0 i DN - 0:00.00 > [wcgrid_cep2_6. > 1028 1356 1261 0 155 19 68404 0 i DN - 0:00.00 > [wcgrid_faah_7. > 1028 1357 1261 0 155 19 68412 0 - RN - 0:00.00 > [wcgrid_faah_7. > 1028 1358 1261 0 155 19 86380 0 - RN - 0:00.00 > [wcgrid_faah_7. > 1028 1359 1261 0 155 19 68404 0 i DN - 0:00.00 > [wcgrid_faah_7. > 1028 1360 1261 0 155 19 67892 0 i DN - 0:00.00 > [wcgrid_faah_7. > 1028 1361 1261 0 155 19 76092 0 i DN - 0:00.00 > [wcgrid_faah_7. > 1028 1362 1261 0 155 19 90036 0 - RN - 0:00.00 > [wcgrid_faah_7. > 0 1372 1345 0 43 0 16944 0 wait D+ - 0:00.01 [sh] > 0 1378 1372 0 30 0 12228 0 - R+ - 0:00.00 > [cpucontrol] > > ------------------------------------------------------------------------ > vmstat -s > > 319667 cpu context switches > 33520 device interrupts > 4096 software interrupts > 633273 traps > 5813583 system calls > 22 kernel threads created > 1128 fork() calls > 219 vfork() calls > 9 rfork() calls > 0 swap pager pageins > 0 swap pager pages paged in > 0 swap pager pageouts > 0 swap pager pages paged out > 1154 vnode pager pageins > 8819 vnode pager pages paged in > 8 vnode pager pageouts > 16 vnode pager pages paged out > 0 page daemon wakeups > 0 pages examined by the page daemon > 11 pages reactivated > 42644 copy-on-write faults > 255 copy-on-write optimized faults > 562815 zero fill pages zeroed > 0 zero fill pages prezeroed > 5 intransit blocking page faults > 622067 total VM faults taken > 1014 page faults requiring I/O > 0 pages affected by kernel thread creation > 42834 pages affected by fork() > 8586 pages affected by vfork() > 115675 pages affected by rfork() > 0 pages cached > 823364 pages freed > 0 pages freed by daemon > 0 pages freed by exiting processes > 26936 pages active > 8342 pages inactive > 4 pages in VM cache > 220798 pages wired down > 15823471 pages free > 4096 bytes per page > 240707 total name lookups > cache hits (90% pos + 4% neg) system 0% per-directory > deletions 0%, falsehits 0%, toolong 0% > > ------------------------------------------------------------------------ > vmstat -m > > Type InUse MemUse HighUse Requests Size(s) > kdtrace 462 100K - 1922 64,256 > kenv 84 11K - 112 16,32,64,128 > kqueue 2 3K - 30 256,2048 > proc-args 53 5K - 513 16,32,64,128,256 > DEVFSP 3 1K - 38 64 > hhook 2 1K - 2 256 > ithread 122 22K - 122 32,128,256 > KTRACE 100 13K - 100 128 > linker 401 197K - 544 > 16,32,64,128,256,512,1024,2048,4096 > lockf 53 6K - 89 64,128 > loginclass 1 1K - 6 64 > cache 1 1K - 1 32 > devbuf 18685 36135K - 19791 > 16,32,64,128,256,512,1024,2048,4096 > temp 57 35K - 6961 > 16,32,64,128,256,512,1024,2048,4096 > ip6ndp 5 1K - 6 64,128 > module 301 38K - 301 128 > mtx_pool 2 16K - 2 > osd 7 1K - 18 16,32,64,128 > pmchooks 1 1K - 1 128 > NFS fh 1 1K - 5 16 > pgrp 40 5K - 62 128 > session 37 5K - 48 128 > proc 2 256K - 2 > subproc 194 360K - 1489 512,4096 > cred 108 17K - 8666 64,256 > plimit 23 6K - 204 256 > uidinfo 7 33K - 25 128 > sysctl 0 0K - 526 16,32,64 > sysctloid 6788 337K - 6940 16,32,64,128 > sysctltmp 0 0K - 384 16,32,64,128,256,4096 > tidhash 1 256K - 1 > callout 9 3208K - 9 > umtx 792 99K - 792 128 > p1003.1b 1 1K - 1 16 > SWAP 12 19681K - 12 64 > bus 945 90K - 5370 16,32,64,128,256,512,1024 > bus-sc 141 293K - 2331 > 16,32,64,128,256,512,1024,2048,4096 > devstat 34 69K - 34 32,4096 > eventhandler 90 8K - 90 64,128 > kobj 180 720K - 902 4096 > Per-cpu 1 1K - 1 32 > rman 360 41K - 797 16,32,128 > sbuf 0 0K - 3645 > 16,32,64,128,256,512,1024,2048,4096 > sglist 3 1K - 3 32 > stack 0 0K - 2 256 > taskqueue 109 17K - 139 16,32,64,256,1024 > Unitno 20 2K - 420 32,64 > vmem 2 160K - 4 > ioctlops 1 1K - 2920 > 16,32,64,128,256,512,1024,2048 > select 35 5K - 35 128 > iov 1 1K - 1252 16,64,128,256,512 > msg 4 30K - 4 2048,4096 > sem 4 106K - 4 2048,4096 > shm 6 30K - 13 2048 > tty 20 20K - 22 1024,2048 > pts 1 1K - 1 256 > mbuf_tag 0 0K - 59 32,128 > shmfd 1 8K - 1 > soname 7 1K - 22000 16,32,128 > pcb 37 8341K - 77 16,32,128,1024,2048 > newnfsmnt 1 1K - 1 1024 > vfscache 1 16384K - 1 > vfs_hash 1 8192K - 1 > vnodes 1 1K - 1 256 > pfs_nodes 21 6K - 21 256 > pfs_vncache 86 6K - 88 64 > mount 396 20K - 1854 16,32,64,128,256,512 > GEOM 344 60K - 3318 > 16,32,64,128,256,512,1024,2048 > vnodemarker 0 0K - 161 512 > BPF 3 1K - 3 128 > acpica 1830 187K - 52091 > 16,32,64,128,256,512,1024,2048 > ifnet 4 7K - 4 128,2048 > ifaddr 48 15K - 48 > 32,64,128,256,512,2048,4096 > ether_multi 47 3K - 54 16,32,64 > clone 6 1K - 6 128 > arpcom 2 1K - 2 16 > lltable 13 5K - 13 256,512 > UART 6 5K - 6 16,1024 > CAM CCB 13 26K - 101 2048 > acpitask 1 8K - 1 > acpisem 22 3K - 22 128 > CAM path 22 1K - 68 32 > acpidev 36 3K - 36 64 > routetbl 35 5K - 228 32,64,128,256,512 > igmp 3 1K - 3 256 > in_multi 2 1K - 2 256 > CAM periph 16 4K - 40 16,32,64,128,256 > CAM queue 31 8K - 100 16,32,512 > CAM dev queue 8 1K - 8 32 > sctp_a_it 0 0K - 3 16 > sctp_vrf 1 1K - 1 64 > sctp_ifa 5 1K - 5 128 > sctp_ifn 2 1K - 2 128 > sctp_iter 0 0K - 3 256 > hostcache 1 28K - 1 > syncache 1 64K - 1 > in6_mfilter 1 1K - 1 1024 > in6_multi 27 4K - 27 32,256 > ip6_moptions 2 1K - 2 32,256 > raid_data 0 0K - 480 32,128,256 > mld 3 1K - 3 128 > CAM SIM 8 2K - 8 256 > CAM XPT 58 4K - 342 16,32,64,128,256,1024 > NFS FHA 1 2K - 1 2048 > rpc 19 5K - 23 32,64,128,256,512,1024 > audit_evclass 188 6K - 229 32 > vm_pgdata 7 8193K - 7 128 > UMAHash 3 5K - 6 512,1024,2048,4096 > scsi_cd 0 0K - 11 16 > USB 50 162K - 56 > 16,32,64,128,256,512,1024,4096 > USBdev 76 26K - 112 32,64,128,512,2048,4096 > pci_link 16 2K - 16 32,64,128 > acpi_perf 8 1K - 8 64 > memdesc 1 4K - 1 4096 > atkbddev 2 1K - 2 64 > md_nvidia_data 0 0K - 78 512 > kbdmux 7 18K - 7 16,512,1024,2048 > LED 4 1K - 4 16,128 > md_sii_data 0 0K - 78 512 > CAM DEV 15 30K - 24 2048 > ata_pci 1 1K - 1 64 > acpiintr 1 1K - 1 64 > ppbusdev 2 1K - 2 256 > apmdev 1 1K - 1 128 > madt_table 0 0K - 1 4096 > isadev 5 1K - 5 128 > random_adaptors 1 1K - 1 32 > entropy 1024 64K - 1024 64 > DEVFS3 223 56K - 269 256 > io_apic 2 4K - 2 2048 > DEVFS1 194 97K - 236 512 > MCA 8 1K - 8 128 > cdev 8 2K - 8 256 > msi 2 1K - 2 128 > nexusdev 4 1K - 4 16 > DEVFS 42 1K - 43 16,128 > filedesc 86 267K - 1390 16,32,64,128,2048,4096 > filedesc_to_leader 17 2K - 17 64 > sigio 1 1K - 1 64 > filecaps 0 0K - 2 64 > linux 43 3K - 43 32,64 > mixer 1 4K - 1 4096 > feeder 16 2K - 18 32,128 > kstat_data 5 1K - 5 64 > solaris 64977 432023K - 918878 > 16,32,64,128,256,512,1024,2048,4096 > spicds 7 1K - 7 128 > envy24ht 15 195K - 15 64,2048 > cpuctl 2 5K - 2 64,4096 > crypto 1 1K - 1 512 > xform 0 0K - 167 16,32 > cyclic 32 3K - 32 16,64,128 > fbt 1 256K - 1 > iprtheap 23 56K - 23 32,64,128,256,2048 > nvidia 179 862K - 182 > 16,32,64,128,256,512,1024,2048,4096 > fdesc_mount 1 1K - 1 16 > netgraph_node 4 1K - 4 128,256 > netgraph 2 1K - 2 64 > > ------------------------------------------------------------------------ > vmstat -z > > ITEM SIZE LIMIT USED FREE REQ FAIL > SLEEP > > UMA Kegs: 384, 0, 172, 8, 172, 0, > 0 > UMA Zones: 1664, 0, 188, 0, 188, 0, > 0 > UMA Slabs: 80, 0, 22943, 257, 39931, 0, > 0 > UMA RCntSlabs: 88, 0, 816, 39, 816, 0, > 0 > UMA Hash: 256, 0, 7, 8, 10, 0, > 0 > 4 Bucket: 32, 0, 252, 748, 5062, 786, > 0 > 8 Bucket: 64, 0, 134, 1230, 2869, 188, > 0 > 16 Bucket: 128, 0, 121, 1150, 2651, 26, > 0 > 32 Bucket: 256, 0, 169, 761, 4898, 92, > 0 > 64 Bucket: 512, 0, 427, 253, 3989, 334, > 0 > 128 Bucket: 1024, 0, 1577, 147, 6403, 23, > 0 > vmem btag: 56, 0, 15370, 605, 16546, 226, > 0 > VM OBJECT: 256, 0, 3138, 342, 18576, 0, > 0 > RADIX NODE: 144, 0, 13651, 1037, 93009, 39, > 0 > MAP: 240, 0, 3, 61, 3, 0, > 0 > KMAP ENTRY: 128, 0, 13, 514, 13, 2, > 0 > MAP ENTRY: 128, 0, 1705, 1178, 41317, 0, > 0 > VMSPACE: 408, 0, 53, 181, 1357, 0, > 0 > fakepg: 104, 0, 0, 0, 0, 0, > 0 > mt_zone: 4112, 0, 288, 0, 288, 0, > 0 > 16: 16, 0, 5, 246, 5, 0, > 0 > 16: 16, 0, 2467, 545, 2622, 0, > 0 > 16: 16, 0, 2, 249, 2, 0, > 0 > 16: 16, 0, 89, 915, 24074, 0, > 0 > 16: 16, 0, 4, 1000, 254, 0, > 0 > 16: 16, 0, 651, 855, 4300, 0, > 0 > 16: 16, 0, 48, 454, 80, 0, > 0 > 16: 16, 0, 3154, 862, 71341, 0, > 0 > 32: 32, 0, 2, 123, 2, 0, > 0 > 32: 32, 0, 2634, 491, 2720, 0, > 0 > 32: 32, 0, 10, 240, 10, 0, > 0 > 32: 32, 0, 109, 891, 4525, 0, > 0 > 32: 32, 0, 250, 750, 649, 0, > 0 > 32: 32, 0, 337, 1288, 2957, 0, > 0 > 32: 32, 0, 79, 921, 480, 0, > 0 > 32: 32, 0, 1963, 2412, 48008, 0, > 0 > 64: 64, 0, 6, 428, 6, 0, > 0 > 64: 64, 0, 330, 600, 340, 0, > 0 > 64: 64, 0, 14, 296, 14, 0, > 0 > 64: 64, 0, 781, 1017, 2205, 0, > 0 > 64: 64, 0, 103, 951, 1404, 0, > 0 > 64: 64, 0, 9185, 735, 16699, 0, > 0 > 64: 64, 0, 1093, 829, 1093, 0, > 0 > 64: 64, 0, 25104, 5524, 244655, 0, > 0 > 128: 128, 0, 8, 519, 8, 0, > 0 > 128: 128, 0, 2007, 1000, 2513, 0, > 0 > 128: 128, 0, 45, 978, 67, 0, > 0 > 128: 128, 0, 1239, 900, 22787, 0, > 0 > 128: 128, 0, 1164, 603, 1245, 0, > 0 > 128: 128, 0, 2042, 686, 25479, 0, > 0 > 128: 128, 0, 3, 276, 3, 0, > 0 > 128: 128, 0, 9616, 2288, 86497, 0, > 0 > 256: 256, 0, 2, 73, 2, 0, > 0 > 256: 256, 0, 34, 461, 241, 0, > 0 > 256: 256, 0, 6, 129, 6, 0, > 0 > 256: 256, 0, 242, 403, 902, 0, > 0 > 256: 256, 0, 465, 300, 950, 0, > 0 > 256: 256, 0, 397, 338, 5080, 0, > 0 > 256: 256, 0, 1, 74, 1, 0, > 0 > 256: 256, 0, 4397, 4423, 98046, 0, > 0 > 512: 512, 0, 4, 84, 8, 0, > 0 > 512: 512, 0, 39, 49, 195, 0, > 0 > 512: 512, 0, 0, 232, 161, 0, > 0 > 512: 512, 0, 235, 165, 1414, 0, > 0 > 512: 512, 0, 18, 70, 18, 0, > 0 > 512: 512, 0, 338, 126, 434, 0, > 0 > 512: 512, 0, 0, 0, 0, 0, > 0 > 512: 512, 0, 10447, 601, 209776, 0, > 0 > 1024: 1024, 0, 1, 15, 1, 0, > 0 > 1024: 1024, 0, 1, 67, 100, 0, > 0 > 1024: 1024, 0, 5, 23, 5, 0, > 0 > 1024: 1024, 0, 6, 62, 1720, 0, > 0 > 1024: 1024, 0, 20, 20, 20, 0, > 0 > 1024: 1024, 0, 26, 262, 3723, 0, > 0 > 1024: 1024, 0, 1, 15, 1, 0, > 0 > 1024: 1024, 0, 339, 93, 51688, 0, > 0 > 2048: 2048, 0, 5, 31, 12, 0, > 0 > 2048: 2048, 0, 32, 20, 129, 0, > 0 > 2048: 2048, 0, 1, 5, 1, 0, > 0 > 2048: 2048, 0, 15, 11, 227, 0, > 0 > 2048: 2048, 0, 76, 32, 1373, 0, > 0 > 2048: 2048, 0, 25, 33, 203, 0, > 0 > 2048: 2048, 0, 5, 1, 5, 0, > 0 > 2048: 2048, 0, 365, 45, 4185, 0, > 0 > 4096: 4096, 0, 1, 0, 1, 0, > 0 > 4096: 4096, 0, 2, 0, 2, 0, > 0 > 4096: 4096, 0, 180, 1, 902, 0, > 0 > 4096: 4096, 0, 12, 0, 14, 0, > 0 > 4096: 4096, 0, 5, 2, 8, 0, > 0 > 4096: 4096, 0, 132, 7, 4551, 0, > 0 > 4096: 4096, 0, 0, 0, 0, 0, > 0 > 4096: 4096, 0, 5874, 9408, 89410, 0, > 0 > uint64 pcpu: 8, 0, 1386, 150, 1386, 0, > 0 > SLEEPQUEUE: 80, 0, 397, 750, 397, 0, > 0 > Files: 80, 0, 207, 793, 14296, 0, > 0 > TURNSTILE: 136, 0, 397, 283, 397, 0, > 0 > rl_entry: 40, 0, 49, 951, 49, 0, > 0 > umtx pi: 96, 0, 0, 0, 0, 0, > 0 > MAC labels: 40, 0, 0, 0, 0, 0, > 0 > PROC: 1208, 0, 83, 34, 1378, 0, > 0 > THREAD: 1168, 0, 377, 19, 542, 0, > 0 > cpuset: 72, 0, 286, 759, 438, 0, > 0 > cyclic_id_cache: 64, 0, 0, 0, 0, 0, > 0 > audit_record: 1240, 0, 0, 0, 0, 0, > 0 > mbuf_packet: 256, 25727505, 1023, 607, 1407, 0, > 0 > mbuf: 256, 25727505, 2, 878, 1060, 0, > 0 > mbuf_cluster: 2048, 4019922, 1625, 1, 1625,1490, > 0 > mbuf_jumbo_page: 4096, 2009961, 0, 3, 7, 0, > 0 > mbuf_jumbo_9k: 9216, 1786632, 0, 0, 0, 0, > 0 > mbuf_jumbo_16k: 16384, 1339972, 0, 0, 0, 0, > 0 > mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, > 0 > dtrace_state_cache: 4096, 0, 0, 0, 0, 0, > 0 > ttyinq: 160, 0, 180, 320, 540, 0, > 0 > ttyoutq: 256, 0, 95, 400, 287, 0, > 0 > g_bio: 248, 0, 0, 736, 100826, 0, > 0 > ata_request: 336, 0, 0, 154, 70, 0, > 0 > vtnet_tx_hdr: 24, 0, 0, 0, 0, 0, > 0 > cryptop: 88, 0, 0, 0, 0, 0, > 0 > cryptodesc: 72, 0, 0, 0, 0, 0, > 0 > nv_stack_t: 12288, 0, 2, 2, 12, 0, > 0 > FPU_save_area: 512, 0, 0, 0, 0, 0, > 0 > taskq_zone: 48, 0, 0, 0, 0, 0, > 0 > taskq_zone: 48, 0, 0, 581, 81, 0, > 0 > VNODE: 472, 0, 9463, 113, 9663, 0, > 0 > VNODEPOLL: 112, 0, 0, 0, 0, 0, > 0 > BUF TRIE: 144, 0, 0, 105948, 0, 0, > 0 > NAMEI: 1024, 0, 0, 132, 57320, 0, > 0 > S VFS Cache: 108, 0, 9378, 527, 11372, 0, > 0 > STS VFS Cache: 148, 0, 0, 0, 0, 0, > 0 > L VFS Cache: 328, 0, 151, 173, 205, 0, > 0 > LTS VFS Cache: 368, 0, 0, 0, 0, 0, > 0 > NCLNODE: 528, 0, 1, 13, 1, 0, > 0 > space_seg_cache: 64, 0, 7959, 101099, 238144, 0, > 0 > zio_cache: 944, 0, 6, 13970, 295331, 0, > 0 > zio_link_cache: 48, 0, 0, 15770, 278175, 0, > 0 > sa_cache: 80, 0, 9242, 658, 9413, 0, > 0 > dnode_t: 856, 0, 10211, 49, 13930, 0, > 0 > dmu_buf_impl_t: 224, 0, 19047, 299, 24850, 0, > 0 > arc_buf_hdr_t: 216, 0, 11737, 467, 13936, 0, > 0 > arc_buf_t: 72, 0, 10586, 689, 16271, 0, > 0 > zil_lwb_cache: 192, 0, 5, 495, 54, 0, > 0 > zfs_znode_cache: 368, 0, 9242, 128, 9413, 0, > 0 > Mountpoints: 816, 0, 30, 35, 30, 0, > 0 > pipe: 744, 0, 9, 86, 814, 0, > 0 > ksiginfo: 112, 0, 131, 1374, 1687, 0, > 0 > itimer: 352, 0, 1, 32, 1, 0, > 0 > KNOTE: 128, 0, 6, 521, 40, 0, > 0 > socket: 680, 2063352, 61, 71, 4016, 0, > 0 > unpcb: 240, 2063360, 16, 480, 3676, 0, > 0 > ipq: 56, 125670, 0, 0, 0, 0, > 0 > udp_inpcb: 392, 2063360, 20, 220, 298, 0, > 0 > udpcb: 16, 2063471, 20, 984, 298, 0, > 0 > tcp_inpcb: 392, 2063360, 24, 216, 36, 0, > 0 > tcpcb: 1024, 2063352, 24, 80, 36, 0, > 0 > tcptw: 72, 27775, 0, 165, 2, 0, > 0 > syncache: 152, 15366, 0, 78, 1, 0, > 0 > hostcache: 136, 15370, 0, 0, 0, 0, > 0 > tcpreass: 40, 251300, 0, 0, 0, 0, > 0 > sackhole: 32, 0, 0, 0, 0, 0, > 0 > sctp_ep: 1408, 2063352, 0, 0, 0, 0, > 0 > sctp_asoc: 2344, 40000, 0, 0, 0, 0, > 0 > sctp_laddr: 48, 80012, 0, 332, 4, 0, > 0 > sctp_raddr: 728, 80000, 0, 0, 0, 0, > 0 > sctp_chunk: 136, 400026, 0, 0, 0, 0, > 0 > sctp_readq: 104, 400026, 0, 0, 0, 0, > 0 > sctp_stream_msg_out: 104, 400026, 0, 0, 0, 0, > 0 > sctp_asconf: 40, 400000, 0, 0, 0, 0, > 0 > sctp_asconf_ack: 48, 400060, 0, 0, 0, 0, > 0 > ripcb: 392, 2063360, 0, 0, 0, 0, > 0 > rtentry: 200, 0, 17, 243, 17, 0, > 0 > selfd: 56, 0, 76, 989, 4050, 0, > 0 > SWAPMETA: 288, 8039850, 0, 0, 0, 0, > 0 > NetGraph items: 72, 4123, 0, 0, 0, 0, > 0 > NetGraph data items: 72, 527, 0, 0, 0, 0, > 0 > > > ------------------------------------------------------------------------ > vmstat -i > > interrupt total rate > irq1: atkbd0 3 0 > irq6: fdc0 22 0 > irq14: ata0 117 0 > irq17: uhci0 ehci0 1145 7 > irq19: uhci1 ahci0+ 31666 206 > cpu0:timer 7042 46 > irq256: em0 567 3 > cpu6:timer 5638 36 > cpu1:timer 6302 41 > cpu3:timer 7819 51 > cpu2:timer 4971 32 > cpu7:timer 6608 43 > cpu4:timer 5406 35 > cpu5:timer 6416 41 > Total 83722 547 > > ------------------------------------------------------------------------ > pstat -T > > 207/2063348 files > 0M/147455M swap space > > ------------------------------------------------------------------------ > pstat -s > > Device 512-blocks Used Avail Capacity > /dev/gpt/swap0 50331392 0 50331392 0% > /dev/gpt/swap1 50331392 0 50331392 0% > /dev/gpt/swap2 50331392 0 50331392 0% > /dev/gpt/swap3 50331392 0 50331392 0% > /dev/gpt/swap4 50331392 0 50331392 0% > /dev/gpt/swap5 50331392 0 50331392 0% > Total 301988352 0 301988352 0% > > ------------------------------------------------------------------------ > iostat > > iostat: kvm_read(_tk_nin): invalid address (0x0) > iostat: disabling TTY statistics > ada0 ada1 ada2 cpu > KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id > 15.37 36 0.55 15.50 34 0.52 15.58 36 0.55 0 0 2 0 97 > > ------------------------------------------------------------------------ > ipcs -a > > Message Queues: > T ID KEY MODE OWNER GROUP CREATOR > CGROUP CBYTES QNUM > QBYTES LSPID LRPID STIME RTIME CTIME > > Shared Memory: > T ID KEY MODE OWNER GROUP CREATOR > CGROUP NATTCH SEGSZ CPID LPID ATIME > DTIME CTIME m 65536 5432001 --rw------- pgsql pgsql > pgsql pgsql 4 41263104 1149 > 1149 13:54:11 13:55:13 13:54:11 > > Semaphores: > T ID KEY MODE OWNER GROUP CREATOR > CGROUP NSEMS OTIME CTIME s 65536 5432001 > --rw------- pgsql pgsql pgsql pgsql 17 13:54:11 > 13:54:11 > s 65537 5432002 --rw------- pgsql pgsql pgsql > pgsql 17 13:54:11 13:54:11 > s 65538 5432003 --rw------- pgsql pgsql pgsql > pgsql 17 13:54:11 13:54:11 > s 65539 5432004 --rw------- pgsql pgsql pgsql > pgsql 17 13:54:11 13:54:11 > s 65540 5432005 --rw------- pgsql pgsql pgsql > pgsql 17 13:54:11 13:54:11 > s 65541 5432006 --rw------- pgsql pgsql pgsql > pgsql 17 13:54:11 13:54:11 > s 65542 5432007 --rw------- pgsql pgsql pgsql > pgsql 17 13:54:19 13:54:11 > > > ------------------------------------------------------------------------ > ipcs -T > > msginfo: > msgmax: 16384 (max characters in a message) > msgmni: 40 (# of message queues) > msgmnb: 2048 (max characters in a message queue) > msgtql: 40 (max # of messages in system) > msgssz: 8 (size of a message segment) > msgseg: 2048 (# of message segments in system) > > shminfo: > shmmax: 536870912 (max shared memory segment size) > shmmin: 1 (min shared memory segment size) > shmmni: 192 (max number of shared memory identifiers) > shmseg: 128 (max shared memory segments per process) > shmall: 131072 (max amount of shared memory in pages) > > seminfo: > semmni: 50 (# of semaphore identifiers) > semmns: 340 (# of semaphores in system) > semmnu: 150 (# of undo structures in system) > semmsl: 340 (max # of semaphores per id) > semopm: 100 (max # of operations per semop call) > semume: 50 (max # of undo entries per process) > semusz: 632 (size in bytes of undo structure) > semvmx: 32767 (semaphore maximum value) > semaem: 16384 (adjust on exit max value) > > > ------------------------------------------------------------------------ > nfsstat > > Client Info: > Rpc Counts: > Getattr Setattr Lookup Readlink Read Write Create > Remove > 2 0 0 0 0 0 0 > 0 > Rename Link Symlink Mkdir Rmdir Readdir RdirPlus > Access > 0 0 0 0 0 0 0 > 0 > Mknod Fsstat Fsinfo PathConf Commit > 0 1 1 0 0 > Rpc Info: > TimedOut Invalid X Replies Retries Requests > 0 0 0 0 4 > Cache Info: > Attr Hits Misses Lkup Hits Misses BioR Hits Misses BioW Hits > Misses > 0 0 0 0 0 0 0 > 0 > BioRLHits Misses BioD Hits Misses DirE Hits Misses Accs Hits > Misses > 0 0 0 0 0 0 0 > 0 > > Server Info: > Getattr Setattr Lookup Readlink Read Write Create > Remove > 0 0 0 0 0 0 0 > 0 > Rename Link Symlink Mkdir Rmdir Readdir RdirPlus > Access > 0 0 0 0 0 0 0 > 0 > Mknod Fsstat Fsinfo PathConf Commit > 0 0 0 0 0 > Server Ret-Failed > 0 > Server Faults > 0 > Server Cache Stats: > Inprog Idem Non-idem Misses > 0 0 0 0 > Server Write Gathering: > WriteOps WriteRPC Opsaved > 0 0 0 > > ------------------------------------------------------------------------ > netstat -s > > tcp: > 167 packets sent > 138 data packets (12023 bytes) > 0 data packets (0 bytes) retransmitted > 0 data packets unnecessarily retransmitted > 0 resends initiated by MTU discovery > 21 ack-only packets (4 delayed) > 0 URG only packets > 0 window probe packets > 0 window update packets > 8 control packets > 196 packets received > 137 acks (for 11879 bytes) > 1 duplicate ack > 0 acks for unsent data > 136 packets (16234 bytes) received in-sequence > 0 completely duplicate packets (0 bytes) > 0 old duplicate packets > 0 packets with some dup. data (0 bytes duped) > 0 out-of-order packets (0 bytes) > 0 packets (0 bytes) of data after window > 0 window probes > 0 window update packets > 0 packets received after close > 0 discarded for bad checksums > 0 discarded for bad header offset fields > 0 discarded because packet too short > 0 discarded due to memory problems > 5 connection requests > 1 connection accept > 0 bad connection attempts > 0 listen queue overflows > 0 ignored RSTs in the windows > 6 connections established (including accepts) > 12 connections closed (including 0 drops) > 0 connections updated cached RTT on close > 0 connections updated cached RTT variance on close > 0 connections updated cached ssthresh on close > 0 embryonic connections dropped > 133 segments updated rtt (of 134 attempts) > 0 retransmit timeouts > 0 connections dropped by rexmit timeout > 0 persist timeouts > 0 connections dropped by persist timeout > 0 Connections (fin_wait_2) dropped because of timeout > 0 keepalive timeouts > 0 keepalive probes sent > 0 connections dropped by keepalive > 3 correct ACK header predictions > 57 correct data packet header predictions > 1 syncache entry added > 0 retransmitted > 0 dupsyn > 0 dropped > 1 completed > 0 bucket overflow > 0 cache overflow > 0 reset > 0 stale > 0 aborted > 0 badack > 0 unreach > 0 zone failures > 1 cookie sent > 0 cookies received > 0 hostcache entries added > 0 bucket overflow > 0 SACK recovery episodes > 0 segment rexmits in SACK recovery episodes > 0 byte rexmits in SACK recovery episodes > 0 SACK options (SACK blocks) received > 0 SACK options (SACK blocks) sent > 0 SACK scoreboard overflow > 0 packets with ECN CE bit set > 0 packets with ECN ECT(0) bit set > 0 packets with ECN ECT(1) bit set > 0 successful ECN handshakes > 0 times ECN reduced the congestion window > udp: > 118 datagrams received > 0 with incomplete header > 0 with bad data length field > 0 with bad checksum > 0 with no checksum > 0 dropped due to no socket > 36 broadcast/multicast datagrams undelivered > 0 dropped due to full socket buffers > 0 not for hashed pcb > 82 delivered > 82 datagrams output > 0 times multicast source filter matched > ip: > 267 total packets received > 0 bad header checksums > 0 with size smaller than minimum > 0 with data size < data length > 0 with ip length > max ip packet size > 0 with header length < data size > 0 with data length < header length > 0 with bad options > 0 with incorrect version number > 0 fragments received > 0 fragments dropped (dup or out of space) > 0 fragments dropped after timeout > 0 packets reassembled ok > 264 packets for this host > 3 packets for unknown/unsupported protocol > 0 packets forwarded (0 packets fast forwarded) > 0 packets not forwardable > 0 packets received for unknown multicast group > 0 redirects sent > 199 packets sent from this host > 0 packets sent with fabricated ip header > 0 output packets dropped due to no bufs, etc. > 0 output packets discarded due to no route > 0 output datagrams fragmented > 0 fragments created > 0 datagrams that can't be fragmented > 0 tunneling packets that can't find gif > 0 datagrams with bad address in header > icmp: > 0 calls to icmp_error > 0 errors not generated in response to an icmp message > 0 messages with bad code fields > 0 messages less than the minimum length > 0 messages with bad checksum > 0 messages with bad length > 0 multicast echo requests ignored > 0 multicast timestamp requests ignored > 0 message responses generated > 0 invalid return addresses > 0 no return routes > igmp: > 3 messages received > 0 messages received with too few bytes > 0 messages received with wrong TTL > 0 messages received with bad checksum > 1 V1/V2 membership query received > 0 V3 membership queries received > 0 membership queries received with invalid field(s) > 1 general query received > 0 group queries received > 0 group-source queries received > 0 group-source queries dropped > 1 membership report received > 0 membership reports received with invalid field(s) > 0 membership reports received for groups to which we belong > 0 V3 reports received without Router Alert > 0 membership reports sent > arp: > 3 ARP requests sent > 3 ARP replies sent > 26 ARP requests received > 7 ARP replies received > 33 ARP packets received > 0 total packets dropped due to no ARP entry > 0 ARP entrys timed out > 0 Duplicate IPs seen > ip6: > 50 total packets received > 0 with size smaller than minimum > 0 with data size < data length > 0 with bad options > 0 with incorrect version number > 0 fragments received > 0 fragments dropped (dup or out of space) > 0 fragments dropped after timeout > 0 fragments that exceeded limit > 0 packets reassembled ok > 50 packets for this host > 0 packets forwarded > 0 packets not forwardable > 0 redirects sent > 57 packets sent from this host > 0 packets sent with fabricated ip header > 0 output packets dropped due to no bufs, etc. > 4 output packets discarded due to no route > 0 output datagrams fragmented > 0 fragments created > 0 datagrams that can't be fragmented > 0 packets that violated scope rules > 0 multicast packets which we don't join > Input histogram: > UDP: 50 > Mbuf statistics: > 26 one mbuf > 24 one ext mbuf > 0 two or more ext mbuf > 0 packets whose headers are not contiguous > 0 tunneling packets that can't find gif > 0 packets discarded because of too many headers > 0 failures of source address selection > Source addresses selection rule applied: > icmp6: > 0 calls to icmp6_error > 0 errors not generated in response to an icmp6 message > 0 errors not generated because of rate limitation > Output histogram: > neighbor solicitation: 1 > 0 messages with bad code fields > 0 messages < minimum length > 0 bad checksums > 0 messages with bad length > Histogram of error messages to be generated: > 0 no route > 0 administratively prohibited > 0 beyond scope > 0 address unreachable > 0 port unreachable > 0 packet too big > 0 time exceed transit > 0 time exceed reassembly > 0 erroneous header field > 0 unrecognized next header > 0 unrecognized option > 0 redirect > 0 unknown > 0 message responses generated > 0 messages with too many ND options > 0 messages with bad ND options > 0 bad neighbor solicitation messages > 0 bad neighbor advertisement messages > 0 bad router solicitation messages > 0 bad router advertisement messages > 0 bad redirect messages > 0 path MTU changes > rip6: > 0 messages received > 0 checksum calculations on inbound > 0 messages with bad checksum > 0 messages dropped due to no socket > 0 multicast messages dropped due to no socket > 0 messages dropped due to full socket buffers > 0 delivered > 0 datagrams output > > ------------------------------------------------------------------------ > netstat -m > > 1025/1485/2510 mbufs in use (current/cache/total) > 1018/608/1626/4019922 mbuf clusters in use (current/cache/total/max) > 1023/607 mbuf+clusters out of packet secondary zone in use > (current/cache) > 0/3/3/2009961 4k (page size) jumbo clusters in use > (current/cache/total/max) > 0/0/0/1786632 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/1339972 16k jumbo clusters in use (current/cache/total/max) > 2292K/1599K/3891K bytes allocated to network (current/cache/total) > 0/1490/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > > ------------------------------------------------------------------------ > netstat -id > > Name Mtu Network Address Ipkts Ierrs Idrop > Opkts Oerrs Coll Drop > em0 1500 00:30:48:f2:29:9c 300 0 0 > 205 0 0 0 em0 1500 192.168.200.0 borg > 245 - - 199 - - - em0 1500 fe80::230:48f > fe80::230:48ff:fe 0 - - 3 - - - em1* > 1500 00:30:48:f2:29:9d 0 0 0 0 > 0 0 0 lo0 16384 50 > 0 0 50 0 0 0 lo0 16384 localhost ::1 > 50 - - 50 - - - lo0 16384 > fe80::1%lo0 fe80::1 0 - - 0 - > - - lo0 16384 your-net localhost 0 - > - 0 - - - > > ------------------------------------------------------------------------ > netstat -anr > > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif > Expire > default 192.168.200.11 UGS 0 39 em0 > 127.0.0.1 link#3 UH 0 0 lo0 > 192.168.200.0/24 link#1 U 0 160 em0 > 192.168.200.4 link#1 UHS 0 0 lo0 > > Internet6: > Destination Gateway Flags > Netif Expire > ::/96 ::1 UGRS > lo0 > ::1 link#3 UH > lo0 > ::ffff:0.0.0.0/96 ::1 UGRS > lo0 > fe80::/10 ::1 UGRS > lo0 > fe80::%em0/64 link#1 U > em0 > fe80::230:48ff:fef2:299c%em0 link#1 UHS > lo0 > fe80::%lo0/64 link#3 U > lo0 > fe80::1%lo0 link#3 UHS > lo0 > ff01::%em0/32 fe80::230:48ff:fef2:299c%em0 U > em0 > ff01::%lo0/32 ::1 U > lo0 > ff02::/16 ::1 UGRS > lo0 > ff02::%em0/32 fe80::230:48ff:fef2:299c%em0 U > em0 > ff02::%lo0/32 ::1 U > lo0 > > ------------------------------------------------------------------------ > netstat -anA > > Active Internet connections (including servers) > Tcpcb Proto Recv-Q Send-Q Local Address Foreign > Address (state) > fffffe025f039c00 tcp4 0 0 192.168.200.4.3351 > 198.20.8.246.80 ESTABLISHED > fffffe0206042400 tcp4 0 0 127.0.0.1.31416 *.* > LISTEN > fffffe001eff9400 tcp4 0 148 192.168.200.4.22 > 192.168.200.87.498 ESTABLISHED > fffffe020602e400 tcp4 0 0 *.9101 *.* > LISTEN > fffffe020615e800 tcp4 0 0 *.22 *.* > LISTEN > fffffe020615ec00 tcp6 0 0 *.22 *.* > LISTEN > fffffe020602e800 tcp4 0 0 *.9102 *.* > LISTEN > fffffe023e226400 tcp4 0 0 *.9103 *.* > LISTEN > fffffe020615f000 tcp4 0 0 *.631 *.* > LISTEN > fffffe020615f400 tcp6 0 0 *.631 *.* > LISTEN > fffffe001eff9800 tcp4 0 0 127.0.0.1.587 *.* > LISTEN > fffffe001eff9c00 tcp4 0 0 127.0.0.1.25 *.* > LISTEN > fffffe001effa000 tcp4 0 0 192.168.200.4.587 *.* > LISTEN > fffffe001effa400 tcp4 0 0 192.168.200.4.25 *.* > LISTEN > fffffe001effa800 tcp4 0 0 127.0.0.1.5432 *.* > LISTEN > fffffe001effac00 tcp6 0 0 ::1.5432 *.* > LISTEN > fffffe02063a6000 tcp4 0 0 *.3551 *.* > LISTEN > fffffe020602ec00 tcp6 0 0 *.2049 *.* > LISTEN > fffffe020602f000 tcp4 0 0 *.2049 *.* > LISTEN > fffffe020615f800 tcp4 0 0 *.977 *.* > LISTEN > fffffe020615fc00 tcp6 0 0 *.977 *.* > LISTEN > fffffe001effb000 tcp4 0 0 *.111 *.* > LISTEN > fffffe020602f400 tcp6 0 0 *.111 *.* > LISTEN > fffffe0206042800 tcp4 0 0 192.168.200.4.755 > 192.168.200.23.204 ESTABLISHED > fffffe001eb7f7a8 udp4 0 0 *.631 *.* > fffffe001eba77a8 udp6 0 0 ::1.46935 ::1.46935 > fffffe001eb7f930 udp4 0 0 127.0.0.1.123 *.* > fffffe001eb7fab8 udp6 0 0 fe80:3::1.123 *.* > fffffe001eb7fc40 udp6 0 0 ::1.123 *.* > fffffe001eb7fdc8 udp6 0 0 fe80:1::230:48ff.1 *.* > fffffe001eb04000 udp4 0 0 192.168.200.4.123 *.* > fffffe001eb04188 udp6 0 0 *.123 *.* > fffffe001eb04310 udp4 0 0 *.123 *.* > fffffe001ee6e188 udp6 0 0 *.2049 *.* > fffffe001ee6e310 udp4 0 0 *.2049 *.* > fffffe001eb04498 udp4 0 0 *.977 *.* > fffffe001eb04620 udp6 0 0 *.977 *.* > fffffe001ee7c188 udp6 0 0 *.* *.* > fffffe001eb047a8 udp4 0 0 *.868 *.* > fffffe001eb04930 udp4 0 0 *.111 *.* > fffffe001eb04ab8 udp6 0 0 *.1013 *.* > fffffe001eb04c40 udp6 0 0 *.111 *.* > fffffe001eb91620 udp4 0 0 *.514 *.* > fffffe001eb917a8 udp6 0 0 *.514 *.* Active > UNIX domain sockets > Address Type Recv-Q Send-Q Inode Conn Refs Nextref Addr > fffffe0206108780 stream 0 0 0 fffffe001ee823c0 > 0 0 > fffffe001ee823c0 stream 0 0 0 fffffe0206108780 > 0 0 > fffffe0206108960 stream 0 0 fffffe0206b91588 0 > 0 0 /var/run/cups.sock > fffffe001ee5b000 stream 0 0 fffffe02068f0760 0 > 0 0 /tmp/.s.PGSQL.5432 > fffffe0206109690 stream 0 0 fffffe020610d760 0 > 0 0 /var/run/rpcbind.sock > fffffe001ee825a0 stream 0 0 fffffe001e71f938 0 > 0 0 /var/run/devd.pipe > fffffe001ee822d0 dgram 0 0 0 0 0 > 0 > fffffe001ee824b0 dgram 0 0 0 fffffe02060dd960 > 0 fffffe001ee89000 > fffffe001ee89000 dgram 0 0 0 fffffe02060dd960 > 0 fffffe0206108870 > fffffe0206108870 dgram 0 0 0 fffffe02060dd960 > 0 0 > fffffe02060dd780 dgram 0 0 0 fffffe02060dd870 > 0 fffffe001ee5b870 > fffffe001ee5b870 dgram 0 0 0 fffffe02060dd870 > 0 fffffe001eeb02d0 > fffffe001eeb02d0 dgram 0 0 0 fffffe02060dd870 > 0 fffffe001ee61b40 > fffffe001ee61b40 dgram 0 0 0 fffffe02060dd870 > 0 0 > fffffe02060dd870 dgram 0 0 fffffe001e786938 0 > fffffe02060dd780 0 /var/run/logpriv > fffffe02060dd960 dgram 0 0 fffffe001e786b10 0 > fffffe001ee824b0 0 /var/run/log > > ------------------------------------------------------------------------ > netstat -aL > > Current listen queue sizes (qlen/incqlen/maxqlen) > Proto Listen Local Address tcp4 0/0/128 > localhost.31416 tcp4 0/0/50 *.bacula-dir tcp4 0/0/128 > *.ssh tcp6 0/0/128 *.ssh tcp4 0/0/50 *.bacula-fd tcp4 > 0/0/50 *.bacula-sd tcp4 0/0/128 *.ipp tcp6 0/0/128 > *.ipp tcp4 0/0/20 localhost.submission tcp4 0/0/20 > localhost.smtp tcp4 0/0/20 borg.submission tcp4 0/0/20 > borg.smtp tcp4 0/0/128 localhost.postgresql tcp6 0/0/128 > localhost.postgresql tcp4 0/0/5 *.3551 tcp6 0/0/5 > *.nfsd tcp4 0/0/5 *.nfsd tcp4 0/0/128 *.977 > tcp6 0/0/128 *.977 tcp4 0/0/128 *.sunrpc tcp6 0/0/128 > *.sunrpc unix 0/0/128 /var/run/cups.sock > unix 0/0/128 /tmp/.s.PGSQL.5432 > unix 0/0/128 /var/run/rpcbind.sock > unix 0/0/4 /var/run/devd.pipe > > ------------------------------------------------------------------------ > fstat > > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read file 7 at 0xfffffffffffffff > fstat: can't read file 8 at 0x78 > fstat: can't read file 10 at 0xffff > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read file 7 at 0xfffffffffffffff > fstat: can't read file 8 at 0x78 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read file 7 at 0xfffffffffffffff > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read file 7 at 0xfffffffffffffff > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read file 7 at 0xfffffffffffffff > fstat: can't read file 8 at 0x78 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read file 7 at 0xfffffffffffffff > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read file 7 at 0xfffffffffffffff > fstat: can't read file 8 at 0x78 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read file 7 at 0xfffffffffffffff > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read file 7 at 0xfffffffffffffff > fstat: can't read file 8 at 0x78 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read file 7 at 0xfffffffffffffff > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read file 7 at 0xfffffffffffffff > fstat: can't read file 8 at 0x78 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read file 7 at 0xfffffffffffffff > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read file 7 at 0xfffffffffffffff > fstat: can't read file 8 at 0x78 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read file 7 at 0xfffffffffffffff > fstat: can't read file 8 at 0x78 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read file 7 at 0xfffffffffffffff > fstat: can't read file 8 at 0x78 > fstat: can't read file 10 at 0xffff > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read file 7 at 0xfffffffffffffff > fstat: can't read file 8 at 0x78 > fstat: can't read file 10 at 0xffff > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read file 7 at 0xfffffffffffffff > fstat: can't read file 8 at 0x78 > fstat: can't read file 10 at 0xffff > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read file 7 at 0xfffffffffffffff > fstat: can't read file 8 at 0x78 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read file 7 at 0xfffffffffffffff > fstat: can't read file 8 at 0x78 > fstat: can't read file 10 at 0xffff > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read file 7 at 0xfffffffffffffff > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read file 7 at 0xfffffffffffffff > fstat: can't read file 8 at 0x78 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read file 7 at 0xfffffffffffffff > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read file 7 at 0xfffffffffffffff > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read file 7 at 0xfffffffffffffff > fstat: can't read file 8 at 0x78 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read file 7 at 0xfffffffffffffff > fstat: can't read file 8 at 0x78 > fstat: can't read file 10 at 0xffff > fstat: can't read file 13 at 0xfffffffffffffff > fstat: can't read file 14 at 0x78 > fstat: can't read file 16 at 0xffff > fstat: can't read file 19 at 0xfffffffffffffff > fstat: can't read file 20 at 0x78 > fstat: can't read file 22 at 0xffff > fstat: can't read file 23 at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read file 7 at 0xfffffffffffffff > fstat: can't read file 8 at 0x78 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read file 7 at 0xfffffffffffffff > fstat: can't read file 8 at 0x78 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read file 7 at 0xfffffffffffffff > fstat: can't read file 8 at 0x78 > fstat: can't read file 10 at 0xffff > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read file 7 at 0xfffffffffffffff > fstat: can't read file 8 at 0x78 > fstat: can't read file 10 at 0xffff > fstat: can't read file 13 at 0xfffffffffffffff > fstat: can't read file 14 at 0x78 > fstat: can't read file 16 at 0xffff > fstat: can't read file 19 at 0xfffffffffffffff > fstat: can't read file 20 at 0x78 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read file 1 at 0xfffffffffffffff > fstat: can't read file 2 at 0x78 > fstat: can't read file 4 at 0xffff > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > fstat: can't read znode_phys at 0x1 > USER CMD PID FD MOUNT INUM MODE SZ|DV R/W > root cpucontrol 1378 root - - error - > root cpucontrol 1378 wd - - error - > root cpucontrol 1378 text - - error - > root cpucontrol 1378 ctty /dev 169 crw--w---- pts/0 rw > root cpucontrol 1378 0 /dev 169 crw--w---- pts/0 rw > root sh 1372 root - - error - > root sh 1372 wd - - error - > root sh 1372 text - - error - > root sh 1372 ctty /dev 169 crw--w---- pts/0 rw > root sh 1372 0 /dev 169 crw--w---- pts/0 rw > root sh 1372 6 /dev 169 crw--w---- pts/0 rw > boinc wcgrid_faah_7.15_i 1362 root - - error - > boinc wcgrid_faah_7.15_i 1362 wd - - error - > boinc wcgrid_faah_7.15_i 1362 text - - error - > boinc wcgrid_faah_7.15_i 1362 0 /dev 30 crw-rw-rw- > null rw > boinc wcgrid_faah_7.15_i 1362 6 /dev 30 crw-rw-rw- > null rw > boinc wcgrid_faah_7.15_i 1361 root - - error - > boinc wcgrid_faah_7.15_i 1361 wd - - error - > boinc wcgrid_faah_7.15_i 1361 text - - error - > boinc wcgrid_faah_7.15_i 1361 0 /dev 30 crw-rw-rw- > null rw > boinc wcgrid_faah_7.15_i 1361 6 /dev 30 crw-rw-rw- > null rw > boinc wcgrid_faah_7.15_i 1360 root - - error - > boinc wcgrid_faah_7.15_i 1360 wd - - error - > boinc wcgrid_faah_7.15_i 1360 text - - error - > boinc wcgrid_faah_7.15_i 1360 0 /dev 30 crw-rw-rw- > null rw > boinc wcgrid_faah_7.15_i 1360 6 /dev 30 crw-rw-rw- > null rw > boinc wcgrid_faah_7.15_i 1359 root - - error - > boinc wcgrid_faah_7.15_i 1359 wd - - error - > boinc wcgrid_faah_7.15_i 1359 text - - error - > boinc wcgrid_faah_7.15_i 1359 0 /dev 30 crw-rw-rw- > null rw > boinc wcgrid_faah_7.15_i 1359 6 /dev 30 crw-rw-rw- > null rw > boinc wcgrid_faah_7.15_i 1358 root - - error - > boinc wcgrid_faah_7.15_i 1358 wd - - error - > boinc wcgrid_faah_7.15_i 1358 text - - error - > boinc wcgrid_faah_7.15_i 1358 0 /dev 30 crw-rw-rw- > null rw > boinc wcgrid_faah_7.15_i 1358 6 /dev 30 crw-rw-rw- > null rw > boinc wcgrid_faah_7.15_i 1357 root - - error - > boinc wcgrid_faah_7.15_i 1357 wd - - error - > boinc wcgrid_faah_7.15_i 1357 text - - error - > boinc wcgrid_faah_7.15_i 1357 0 /dev 30 crw-rw-rw- > null rw > boinc wcgrid_faah_7.15_i 1357 6 /dev 30 crw-rw-rw- > null rw > boinc wcgrid_faah_7.15_i 1356 root - - error - > boinc wcgrid_faah_7.15_i 1356 wd - - error - > boinc wcgrid_faah_7.15_i 1356 text - - error - > boinc wcgrid_faah_7.15_i 1356 0 /dev 30 crw-rw-rw- > null rw > boinc wcgrid_faah_7.15_i 1356 6 /dev 30 crw-rw-rw- > null rw > boinc wcgrid_cep2_6.40_i 1355 root - - error - > boinc wcgrid_cep2_6.40_i 1355 wd - - error - > boinc wcgrid_cep2_6.40_i 1355 text - - error - > boinc wcgrid_cep2_6.40_i 1355 0 /dev 30 crw-rw-rw- > null rw > boinc wcgrid_cep2_6.40_i 1355 6 - - error - > boinc wcgrid_faah_7.15_i 1354 root - - error - > boinc wcgrid_faah_7.15_i 1354 wd - - error - > boinc wcgrid_faah_7.15_i 1354 text - - error - > boinc wcgrid_faah_7.15_i 1354 0 /dev 30 crw-rw-rw- > null rw > boinc wcgrid_faah_7.15_i 1354 6 /dev 30 crw-rw-rw- > null rw > boinc wcgrid_cep2_6.40_i 1353 root - - error - > boinc wcgrid_cep2_6.40_i 1353 wd - - error - > boinc wcgrid_cep2_6.40_i 1353 text - - error - > boinc wcgrid_cep2_6.40_i 1353 0 /dev 30 crw-rw-rw- > null rw > boinc wcgrid_cep2_6.40_i 1353 6 - - error - > boinc wcgrid_faah_7.15_i 1352 root - - error - > boinc wcgrid_faah_7.15_i 1352 wd - - error - > boinc wcgrid_faah_7.15_i 1352 text - - error - > boinc wcgrid_faah_7.15_i 1352 0 /dev 30 crw-rw-rw- > null rw > boinc wcgrid_faah_7.15_i 1352 6 /dev 30 crw-rw-rw- > null rw > boinc wcgrid_faah_7.15_i 1351 root - - error - > boinc wcgrid_faah_7.15_i 1351 wd - - error - > boinc wcgrid_faah_7.15_i 1351 text - - error - > boinc wcgrid_faah_7.15_i 1351 0 /dev 30 crw-rw-rw- > null rw > boinc wcgrid_faah_7.15_i 1351 6 /dev 30 crw-rw-rw- > null rw > boinc wcgrid_faah_7.15_i 1350 root - - error - > boinc wcgrid_faah_7.15_i 1350 wd - - error - > boinc wcgrid_faah_7.15_i 1350 text - - error - > boinc wcgrid_faah_7.15_i 1350 0 /dev 30 crw-rw-rw- > null rw > boinc wcgrid_faah_7.15_i 1350 6 /dev 30 crw-rw-rw- > null rw > boinc wcgrid_faah_7.15_i 1349 root - - error - > boinc wcgrid_faah_7.15_i 1349 wd - - error - > boinc wcgrid_faah_7.15_i 1349 text - - error - > boinc wcgrid_faah_7.15_i 1349 0 /dev 30 crw-rw-rw- > null rw > boinc wcgrid_faah_7.15_i 1349 6 /dev 30 crw-rw-rw- > null rw > boinc wcgrid_faah_7.15_i 1348 root - - error - > boinc wcgrid_faah_7.15_i 1348 wd - - error - > boinc wcgrid_faah_7.15_i 1348 text - - error - > boinc wcgrid_faah_7.15_i 1348 0 /dev 30 crw-rw-rw- > null rw > boinc wcgrid_faah_7.15_i 1348 6 /dev 30 crw-rw-rw- > null rw > boinc wcgrid_cep2_6.40_i 1347 root - - error - > boinc wcgrid_cep2_6.40_i 1347 wd - - error - > boinc wcgrid_cep2_6.40_i 1347 text - - error - > boinc wcgrid_cep2_6.40_i 1347 0 /dev 30 crw-rw-rw- > null rw > boinc wcgrid_cep2_6.40_i 1347 6 - - error - > boinc wcgrid_faah_7.15_i 1346 root - - error - > boinc wcgrid_faah_7.15_i 1346 wd - - error - > boinc wcgrid_faah_7.15_i 1346 text - - error - > boinc wcgrid_faah_7.15_i 1346 0 /dev 30 crw-rw-rw- > null rw > boinc wcgrid_faah_7.15_i 1346 6 /dev 30 crw-rw-rw- > null rw > root sh 1345 root - - error - > root sh 1345 wd - - error - > root sh 1345 text - - error - > root sh 1345 ctty /dev 169 crw--w---- pts/0 rw > root sh 1345 0 /dev 169 crw--w---- pts/0 rw > root sh 1345 6 /dev 169 crw--w---- pts/0 rw > root sudo 1344 root - - error - > root sudo 1344 wd - - error - > root sudo 1344 text - - error - > root sudo 1344 ctty /dev 169 crw--w---- pts/0 rw > root sudo 1344 0 /dev 169 crw--w---- pts/0 rw > ler sh 1342 root - - error - > ler sh 1342 wd - - error - > ler sh 1342 text - - error - > ler sh 1342 ctty /dev 169 crw--w---- pts/0 rw > ler sh 1342 0 /dev 169 crw--w---- pts/0 rw > ler sh 1342 6 /dev 169 crw--w---- pts/0 rw > ler sshd 1341 root - - error - > ler sshd 1341 wd - - error - > ler sshd 1341 text - - error - > ler sshd 1341 0 /dev 30 crw-rw-rw- null rw > ler sshd 1341 6 /dev 30 crw-rw-rw- null rw > root sshd 1339 root - - error - > root sshd 1339 wd - - error - > root sshd 1339 text - - error - > root sshd 1339 0 /dev 30 crw-rw-rw- null r > root sshd 1339 6 /dev 30 crw-rw-rw- null rw > root getty 1337 root - - error - > root getty 1337 wd - - error - > root getty 1337 text - - error - > root getty 1337 ctty /dev 83 crw------- ttyv7 rw > root getty 1337 0 /dev 83 crw------- ttyv7 rw > root getty 1336 root - - error - > root getty 1336 wd - - error - > root getty 1336 text - - error - > root getty 1336 ctty /dev 82 crw------- ttyv6 rw > root getty 1336 0 /dev 82 crw------- ttyv6 rw > root getty 1335 root - - error - > root getty 1335 wd - - error - > root getty 1335 text - - error - > root getty 1335 ctty /dev 81 crw------- ttyv5 rw > root getty 1335 0 /dev 81 crw------- ttyv5 rw > root getty 1334 root - - error - > root getty 1334 wd - - error - > root getty 1334 text - - error - > root getty 1334 ctty /dev 80 crw------- ttyv4 rw > root getty 1334 0 /dev 80 crw------- ttyv4 rw > root getty 1333 root - - error - > root getty 1333 wd - - error - > root getty 1333 text - - error - > root getty 1333 ctty /dev 79 crw------- ttyv3 rw > root getty 1333 0 /dev 79 crw------- ttyv3 rw > root getty 1332 root - - error - > root getty 1332 wd - - error - > root getty 1332 text - - error - > root getty 1332 ctty /dev 78 crw------- ttyv2 rw > root getty 1332 0 /dev 78 crw------- ttyv2 rw > root getty 1331 root - - error - > root getty 1331 wd - - error - > root getty 1331 text - - error - > root getty 1331 ctty /dev 77 crw------- ttyv1 rw > root getty 1331 0 /dev 77 crw------- ttyv1 rw > root getty 1330 root - - error - > root getty 1330 wd - - error - > root getty 1330 text - - error - > root getty 1330 ctty /dev 76 crw------- ttyv0 rw > root getty 1330 0 /dev 76 crw------- ttyv0 rw > root sleep 1328 root - - error - > root sleep 1328 wd - - error - > root sleep 1328 text - - error - > root sleep 1328 0 /dev 30 crw-rw-rw- null r > root logger 1327 root - - error - > root logger 1327 wd - - error - > root logger 1327 text - - error - > root logger 1327 0* pipe fffffe001e7bfba0 <-> > fffffe001e7bfd00 0 rw > root sh 1326 root - - error - > root sh 1326 wd - - error - > root sh 1326 text - - error - > root sh 1326 0 /dev 30 crw-rw-rw- null r > root inetd 1310 root - - error - > root inetd 1310 wd - - error - > root inetd 1310 text - - error - > root inetd 1310 0 /dev 30 crw-rw-rw- null rw > root cron 1288 root - - error - > root cron 1288 wd - - error - > root cron 1288 text - - error - > root cron 1288 0 /dev 30 crw-rw-rw- null rw > root sshd 1276 root - - error - > root sshd 1276 wd - - error - > root sshd 1276 text - - error - > root sshd 1276 0 /dev 30 crw-rw-rw- null rw > bacula bacula-dir 1271 root - - error - > bacula bacula-dir 1271 wd - - error - > bacula bacula-dir 1271 text - - error - > bacula bacula-dir 1271 0 /dev 30 crw-rw-rw- null r > root bacula-fd 1268 root - - error - > root bacula-fd 1268 wd - - error - > root bacula-fd 1268 text - - error - > root bacula-fd 1268 0 /dev 30 crw-rw-rw- null r > bacula bacula-sd 1265 root - - error - > bacula bacula-sd 1265 wd - - error - > bacula bacula-sd 1265 text - - error - > bacula bacula-sd 1265 0 /dev 30 crw-rw-rw- null r > boinc boinc_client 1261 root - - error - > boinc boinc_client 1261 wd - - error - > boinc boinc_client 1261 text - - error - > boinc boinc_client 1261 0 /dev 30 crw-rw-rw- null rw > boinc boinc_client 1261 6 - - error - > root cupsd 1255 root - - error - > root cupsd 1255 wd - - error - > root cupsd 1255 text - - error - > root cupsd 1255 0 /dev 30 crw-rw-rw- null r > root cupsd 1255 6 /dev 30 crw-rw-rw- null w > root cupsd 1255 12 /dev 30 crw-rw-rw- null w > mailnull exim-4.80.1-2 1246 root - - error - > mailnull exim-4.80.1-2 1246 wd - - error - > mailnull exim-4.80.1-2 1246 text - - error - > mailnull exim-4.80.1-2 1246 0 /dev 30 crw-rw-rw- null rw > mailnull exim-4.80.1-2 1246 6 /dev 30 crw-rw-rw- null rw > pgsql postgres 1156 root - - error - > pgsql postgres 1156 wd - - error - > pgsql postgres 1156 text - - error - > pgsql postgres 1156 0 /dev 30 crw-rw-rw- null r > pgsql postgres 1156 6 - - error - > pgsql postgres 1155 root - - error - > pgsql postgres 1155 wd - - error - > pgsql postgres 1155 text - - error - > pgsql postgres 1155 0 /dev 30 crw-rw-rw- null r > pgsql postgres 1155 6 - - error - > pgsql postgres 1154 root - - error - > pgsql postgres 1154 wd - - error - > pgsql postgres 1154 text - - error - > pgsql postgres 1154 0 /dev 30 crw-rw-rw- null r > pgsql postgres 1154 6 - - error - > pgsql postgres 1153 root - - error - > pgsql postgres 1153 wd - - error - > pgsql postgres 1153 text - - error - > pgsql postgres 1153 0 /dev 30 crw-rw-rw- null r > pgsql postgres 1153 6 - - error - > pgsql postgres 1149 root - - error - > pgsql postgres 1149 wd - - error - > pgsql postgres 1149 text - - error - > pgsql postgres 1149 0 /dev 30 crw-rw-rw- null r > pgsql postgres 1149 6 - - error - > root smartd 1140 root - - error - > root smartd 1140 wd - - error - > root smartd 1140 text - - error - > root smartd 1140 0 /dev 30 crw-rw-rw- null rw > root perl 1136 root - - error - > root perl 1136 wd - - error - > root perl 1136 text - - error - > root perl 1136 0 - - error - > root ng_queue 1124 root - - error - > root ng_queue 1124 wd - - error - > root ntpd 1103 root - - error - > root ntpd 1103 wd - - error - > root ntpd 1103 text - - error - > root ntpd 1103 0 /dev 30 crw-rw-rw- null rw > root ntpd 1103 6 /dev 30 crw-rw-rw- null rw > root ntpd 1103 12 /dev 30 crw-rw-rw- null rw > root ntpd 1103 18* local dgram fffffe001eeb02d0 <-> > fffffe02060dd870 > root apcupsd 1072 root - - error - > root apcupsd 1072 wd - - error - > root apcupsd 1072 text - - error - > root apcupsd 1072 0 /dev 30 crw-rw-rw- null r > root apcupsd 1072 6 /dev 30 crw-rw-rw- null r > root nfsd 1064 root - - error - > root nfsd 1064 wd - - error - > root nfsd 1064 text - - error - > root nfsd 1064 0 /dev 30 crw-rw-rw- null rw > root nfsd 1062 root - - error - > root nfsd 1062 wd - - error - > root nfsd 1062 text - - error - > root nfsd 1062 0 /dev 30 crw-rw-rw- null rw > root nfsd 1062 6 /dev 30 crw-rw-rw- null rw > root mountd 1056 root - - error - > root mountd 1056 wd - - error - > root mountd 1056 text - - error - > root mountd 1056 0 /dev 30 crw-rw-rw- null rw > root mountd 1056 6 /dev 30 crw-rw-rw- null rw > root rpcbind 1021 root - - error - > root rpcbind 1021 wd - - error - > root rpcbind 1021 text - - error - > root rpcbind 1021 0 /dev 30 crw-rw-rw- null rw > root rpcbind 1021 6 /dev 30 crw-rw-rw- null rw > root watchdogd 1007 root - - error - > root watchdogd 1007 wd - - error - > root watchdogd 1007 text - - error - > root watchdogd 1007 0 /dev 30 crw-rw-rw- null rw > root syslogd 1004 root - - error - > root syslogd 1004 wd - - error - > root syslogd 1004 text - - error - > root syslogd 1004 0 /dev 30 crw-rw-rw- null rw > root syslogd 1004 6 /dev 30 crw-rw-rw- null rw > root syslogd 1004 12 /dev 30 crw-rw-rw- null rw > root syslogd 1004 18 - - error - > root devd 866 root - - error - > root devd 866 wd - - error - > root devd 866 text - - error - > root devd 866 0 /dev 30 crw-rw-rw- null rw > root devd 866 6 /dev 30 crw-rw-rw- null rw > root moused 847 root - - error - > root moused 847 wd - - error - > root moused 847 text - - error - > root moused 847 0 /dev 30 crw-rw-rw- null rw > root init 1 root - - error - > root init 1 wd - - error - > root init 1 text - - error - > root kernel 0 root - - error - > root kernel 0 wd - - error - > > ------------------------------------------------------------------------ > dmesg > > Copyright (c) 1992-2013 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, > 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 10.0-CURRENT #16: Sat Aug 10 13:45:06 CDT 2013 > root@borg.lerctr.org:/usr/obj/usr/src/sys/BORG-DTRACE amd64 > FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 > CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz (2327.55-MHz > K8-class CPU) > Origin = "GenuineIntel" Id = 0x10676 Family = 0x6 Model = 0x17 > Stepping = 6 > > Features=0xbfebfbff > > Features2=0xce3bd > AMD Features=0x20100800 > AMD Features2=0x1 > TSC: P-state invariant, performance statistics > real memory = 68719476736 (65536 MB) > avail memory = 65660014592 (62618 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > FreeBSD/SMP: 2 package(s) x 4 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 2 > cpu3 (AP): APIC ID: 3 > cpu4 (AP): APIC ID: 4 > cpu5 (AP): APIC ID: 5 > cpu6 (AP): APIC ID: 6 > cpu7 (AP): APIC ID: 7 > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-47 on motherboard > kbd1 at kbdmux0 > netmap: loaded module > random: initialized > cryptosoft0: on motherboard > acpi0: on motherboard > acpi0: Power Button (fixed) > unknown: I/O range not supported > cpu0: on acpi0 > cpu1: on acpi0 > cpu2: on acpi0 > cpu3: on acpi0 > cpu4: on acpi0 > cpu5: on acpi0 > cpu6: on acpi0 > cpu7: on acpi0 > hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 > on acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 950 > Event timer "HPET" frequency 14318180 Hz quality 350 > Event timer "HPET1" frequency 14318180 Hz quality 340 > Event timer "HPET2" frequency 14318180 Hz quality 340 > atrtc0: port 0x70-0x71 on acpi0 > Event timer "RTC" frequency 32768 Hz quality 0 > attimer0: port 0x40-0x43,0x50-0x53 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: at device 2.0 on pci0 > pci1: on pcib1 > pcib2: irq 16 at device 0.0 on pci1 > pci2: on pcib2 > pcib3: irq 16 at device 0.0 on pci2 > pci3: on pcib3 > pcib4: at device 0.0 on pci3 > pci4: on pcib4 > pcib5: at device 0.2 on pci3 > pci5: on pcib5 > pcib6: irq 18 at device 2.0 on pci2 > pci6: on pcib6 > em0: port 0x2000-0x201f > mem 0xd9220000-0xd923ffff,0xd9200000-0xd921ffff irq 18 at device 0.0 > on pci6 > em0: Using an MSI interrupt > em0: Ethernet address: 00:30:48:f2:29:9c > 001.000009 netmap_attach [2244] success for em0 > em1: port 0x2020-0x203f > mem 0xd9260000-0xd927ffff,0xd9240000-0xd925ffff irq 19 at device 0.1 > on pci6 > em1: Using an MSI interrupt > em1: Ethernet address: 00:30:48:f2:29:9d > 001.000010 netmap_attach [2244] success for em1 > pcib7: at device 0.3 on pci1 > pci7: on pcib7 > pcib8: at device 4.0 on pci0 > pci8: on pcib8 > vgapci0: port 0x3000-0x307f mem > 0xd8000000-0xd8ffffff,0xc0000000-0xc7ffffff,0xc8000000-0xc9ffffff irq > 16 at device 0.0 on pci8 > nvidia0: on vgapci0 > vgapci0: child nvidia0 requested pci_enable_io > vgapci0: child nvidia0 requested pci_enable_io > pci8: at device 0.1 (no driver attached) > pcib9: at device 6.0 on pci0 > pci9: on pcib9 > pci0: at device 8.0 (no driver attached) > pcib10: irq 17 at device 28.0 on pci0 > pci10: on pcib10 > pcib11: irq 16 at device 0.0 on pci10 > pci11: on pcib11 > pcm0: port 0x4080-0x409f,0x4000-0x407f irq > 16 at device 0.0 on pci11 > pcm0: system configuration > SubVendorID: 0x1412, SubDeviceID: 0x2403 > XIN2 Clock Source: 24.576MHz(96kHz*256) > MPU-401 UART(s) #: not implemented > ADC #: 1 and SPDIF receiver connected > DAC #: 4 > Multi-track converter type: AC'97(SDATA_OUT:packed) > S/PDIF(IN/OUT): 1/1 ID# 0x00 > GPIO(mask/dir/state): 0xff/0xff/0xff > uhci0: port > 0x1800-0x181f irq 17 at device 29.0 on pci0 > usbus0 on uhci0 > uhci1: port > 0x1820-0x183f irq 19 at device 29.1 on pci0 > usbus1 on uhci1 > uhci2: port > 0x1840-0x185f irq 18 at device 29.2 on pci0 > usbus2 on uhci2 > ehci0: mem 0xd9600400-0xd96007ff > irq 17 at device 29.7 on pci0 > usbus3: EHCI version 1.0 > usbus3 on ehci0 > pcib12: at device 30.0 on pci0 > pci12: on pcib12 > vgapci1: port 0x5000-0x50ff mem > 0xd0000000-0xd7ffffff,0xd9300000-0xd930ffff irq 18 at device 1.0 on > pci12 > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on > pci0 > ata0: at channel 0 on atapci0 > ahci0: port > 0x18a0-0x18a7,0x1874-0x1877,0x1878-0x187f,0x1870-0x1873,0x1880-0x189f > mem 0xd9600800-0xd9600bff irq 19 at device 31.2 on pci0 > ahci0: AHCI v1.10 with 6 3Gbps ports, Port Multiplier supported > ahcich0: at channel 0 on ahci0 > ahcich1: at channel 1 on ahci0 > ahcich2: at channel 2 on ahci0 > ahcich3: at channel 3 on ahci0 > ahcich4: at channel 4 on ahci0 > ahcich5: at channel 5 on ahci0 > ichsmb0: port > 0x1100-0x111f irq 19 at device 31.3 on pci0 > smbus0: on ichsmb0 > acpi_button0: on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on > acpi0 > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 > ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode > ppc0: FIFO with 16/16/9 bytes threshold > ppbus0: on ppc0 > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > ichwd0 on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on > isa0 > coretemp0: on cpu0 > est0: on cpu0 > p4tcc0: on cpu0 > coretemp1: on cpu1 > est1: on cpu1 > p4tcc1: on cpu1 > coretemp2: on cpu2 > est2: on cpu2 > p4tcc2: on cpu2 > coretemp3: on cpu3 > est3: on cpu3 > p4tcc3: on cpu3 > coretemp4: on cpu4 > est4: on cpu4 > p4tcc4: on cpu4 > coretemp5: on cpu5 > est5: on cpu5 > p4tcc5: on cpu5 > coretemp6: on cpu6 > est6: on cpu6 > p4tcc6: on cpu6 > coretemp7: on cpu7 > est7: on cpu7 > p4tcc7: on cpu7 > ZFS filesystem version: 5 > ZFS storage pool version: features support (5000) > Timecounters tick every 1.000 msec > vboxdrv: fAsync=0 offMin=0x395 offMax=0x50f > usbus0: 12Mbps Full Speed USB v1.0 > usbus1: 12Mbps Full Speed USB v1.0 > usbus2: 12Mbps Full Speed USB v1.0 > usbus3: 480Mbps High Speed USB v2.0 > ugen0.1: at usbus0 > uhub0: on > usbus0 > ugen1.1: at usbus1 > uhub1: on > usbus1 > ugen2.1: at usbus2 > uhub2: on > usbus2 > ugen3.1: at usbus3 > uhub3: on > usbus3 > ata0: DMA limited to UDMA33, controller found non-ATA66 cable > ada0 at ahcich0 bus 0 scbus1 target 0 lun 0 > ada0: ATA-8 SATA 3.x device > ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) > ada0: quirks=0x1<4K> > ada0: Previously was known as ad4 > ada1 at ahcich1 bus 0 scbus2 target 0 lun 0 > ada1: ATA-8 SATA 3.x device > ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada1: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) > ada1: quirks=0x1<4K> > ada1: Previously was known as ad6 > ada2 at ahcich2 bus 0 scbus3 target 0 lun 0 > ada2: ATA-8 SATA 3.x device > ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada2: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) > ada2: quirks=0x1<4K> > ada2: Previously was known as ad8 > ada3 at ahcich3 bus 0 scbus4 target 0 lun 0 > ada3: ATA-8 SATA 3.x device > ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada3: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) > ada3: quirks=0x1<4K> > ada3: Previously was known as ad10 > ada4 at ahcich4 bus 0 scbus5 target 0 lun 0 > ada4: ATA-8 SATA 3.x device > ada4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada4: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) > ada4: quirks=0x1<4K> > ada4: Previously was known as ad12 > ada5 at ahcich5 bus 0 scbus6 target 0 lun 0 > ada5: ATA-8 SATA 3.x device > ada5: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada5: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) > ada5: quirks=0x1<4K> > ada5: Previously was known as ad14 > cd0 at ata0 bus 0 scbus0 target 0 lun 0 > cd0: Removable CD-ROM SCSI-0 device > cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) > cd0: Attempt to query device size failed: NOT READY, Medium not present > SMP: AP CPU #6 Launched! > SMP: AP CPU #1 Launched! > SMP: AP CPU #3 Launched! > SMP: AP CPU #2 Launched! > SMP: AP CPU #7 Launched! > SMP: AP CPU #4 Launched! > SMP: AP CPU #5 Launched! > uhub1: 2 ports with 2 removable, self powered > uhub0: 2 ports with 2 removable, self powered > uhub2: 2 ports with 2 removable, self powered > Root mount waiting for: usbus3 > uhub3: 6 ports with 6 removable, self powered > Root mount waiting for: usbus3 > Root mount waiting for: usbus3 > ugen3.2: at usbus3 > ukbd0: on > usbus3 > kbd2 at ukbd0 > Trying to mount root from zfs:zroot/ROOT/default []... > ugen0.2: at usbus0 > ugen0.3: at usbus0 > ffclock reset: HPET (14318180 Hz), time = 1376160821.500000000 > Setting hostuuid: 53d19f64-d663-a017-8922-0030488e9ff3. > Setting hostid: 0xf53a926e. > Entropy harvesting: interrupts ethernet point_to_point kickstart. > Starting file system checks: > Mounting local file systems:. > Writing entropy file:. > Setting hostname: borg.lerctr.org. > Starting Network: lo0 em0 em1. > lo0: flags=8049 metric 0 mtu 16384 > options=600003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > inet 127.0.0.1 netmask 0xff000000 > nd6 options=21 > em0: flags=8843 metric 0 mtu > 1500 > options=4219b > ether 00:30:48:f2:29:9c > inet 192.168.200.4 netmask 0xffffff00 broadcast 192.168.200.255 > inet6 fe80::230:48ff:fef2:299c%em0 prefixlen 64 scopeid 0x1 > nd6 options=29 > media: Ethernet autoselect > status: no carrier > em1: flags=8c02 metric 0 mtu 1500 > options=4219b > ether 00:30:48:f2:29:9d > nd6 options=29 > media: Ethernet autoselect > status: no carrier > Starting devd. > Starting Network: em1. > em1: flags=8c02 metric 0 mtu 1500 > options=4219b > ether 00:30:48:f2:29:9d > nd6 options=29 > media: Ethernet autoselect > status: no carrier > uhid0: on > usbus3 > ums0: 1.10/1.21, addr 2> on usbus0 > ums0: 5 buttons and [XYZ] coordinates ID=0 > Starting ums0 moused. > add net default: gateway 192.168.200.11 > add net fe80::: gateway ::1 > add net ff02::: gateway ::1 > add net ::ffff:0.0.0.0: gateway ::1 > add net ::0.0.0.0: gateway ::1 > Mounting NFS file systems:. > ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib > /usr/local/kde4/lib /usr/local/lib/compat /usr/local/lib/dbmail > /usr/local/lib/event2 /usr/local/lib/pth /usr/local/lib/qt4 > /usr/local/lib/virtualbox > 32-bit compatibility ldconfig path: /usr/lib32 /usr/local/lib32/compat > Creating and/or trimming log files. > Starting syslogd. > Starting watchdogd. > No core dumps found. > Additional ABI support: linux. > Starting rpcbind. > NFS access cache time=60 > Clearing /tmp (X related). > Starting mountd. > NFSv4 is disabled > Starting nfsd. > Starting apcupsd. > Updating motd:. > Mounting late file systems:. > Starting ntpd. > Starting sshblock. > Starting smartd. > Starting exim. > Starting cupsd. > Starting boinc_client. > Starting bacula_sd. > Starting bacula_fd. > Starting bacula_dir. > Performing sanity check on sshd configuration. > Starting sshd. > Configuring syscons: blanktime. > Starting cron. > mixer: WRITE_MIXER: Device not configured > mixer: WRITE_MIXER: Device not configured > mixer: WRITE_MIXER: Device not configured > mixer: WRITE_MIXER: Device not configured > mixer: WRITE_MIXER: Device not configured > mixer: WRITE_MIXER: Device not configured > Starting inetd. > Starting background file system checks in 60 seconds. > > Sat Aug 10 13:54:18 CDT 2013 > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x5e > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff80709be9 > stack pointer = 0x28:0xffffff900d55c860 > frame pointer = 0x28:0xffffff900d55c870 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 1378 (cpucontrol) > trap number = 12 > panic: page fault > cpuid = 0 > Uptime: 1m48s > Dumping 2337 out of 64479 > MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% > > ------------------------------------------------------------------------ > kernel config > > options CONFIG_AUTOGENERATED > ident BORG-DTRACE > machine amd64 > cpu HAMMER > makeoptions WITH_CTF=1 > makeoptions DEBUG=-g > options FFCLOCK > options USB_DEBUG > options RDRAND_RNG > options PADLOCK_RNG > options ATH_ENABLE_11N > options AH_AR5416_INTERRUPT_MITIGATION > options AH_SUPPORT_AR5416 > options IEEE80211_SUPPORT_MESH > options IEEE80211_AMPDU_AGE > options IEEE80211_DEBUG > options SC_PIXEL_MODE > options VESA > options AHD_REG_PRETTY_PRINT > options AHC_REG_PRETTY_PRINT > options ATA_STATIC_ID > options SMP > options MALLOC_DEBUG_MAXZONES=8 > options KDB_TRACE > options INCLUDE_CONFIG_FILE > options DDB_CTF > options KDTRACE_HOOKS > options KDTRACE_FRAME > options MAC > options CAPABILITIES > options CAPABILITY_MODE > options AUDIT > options HWPMC_HOOKS > options KBD_INSTALL_CDEV > options PRINTF_BUFR_SIZE=128 > options _KPOSIX_PRIORITY_SCHEDULING > options SYSVSEM > options SYSVMSG > options SYSVSHM > options STACK > options KTRACE > options SCSI_DELAY=5000 > options COMPAT_FREEBSD7 > options COMPAT_FREEBSD6 > options COMPAT_FREEBSD5 > options COMPAT_FREEBSD4 > options COMPAT_FREEBSD32 > options GEOM_LABEL > options GEOM_RAID > options GEOM_PART_GPT > options PSEUDOFS > options PROCFS > options CD9660 > options MSDOSFS > options NFS_ROOT > options NFSLOCKD > options NFSD > options NFSCL > options QUOTA > options SCTP > options TCP_OFFLOAD > options INET6 > options INET > options PREEMPTION > options SCHED_ULE > options NEW_PCIB > options GEOM_PART_MBR > options GEOM_PART_EBR_COMPAT > options GEOM_PART_EBR > options GEOM_PART_BSD > device isa > device mem > device io > device uart_ns8250 > device cpufreq > device acpi > device pci > device fdc > device ahci > device ata > device esp > device isci > device scbus > device ch > device da > device sa > device cd > device pass > device ses > device hptnr > device aacraid > device atkbdc > device atkbd > device psm > device kbdmux > device vga > device splash > device sc > device agp > device uart > device ppc > device ppbus > device lpt > device ppi > device em > device miibus > device cas > device gem > device hme > device nfe > device nge > device loop > device random > device ether > device vlan > device tun > device md > device gif > device faith > device firmware > device bpf > device uhci > device ohci > device ehci > device xhci > device usb > device ukbd > device umass > device virtio > device virtio_pci > device vtnet > device virtio_blk > device virtio_scsi > device virtio_balloon > device netmap > > ------------------------------------------------------------------------ > ddb capture buffer > > ddb: ddb_capture: kvm_nlist I also notice no SVN rev in this build nor r254185. :( -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 20:03:02 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D62BD6B9 for ; Sat, 10 Aug 2013 20:03:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5AE162DCB for ; Sat, 10 Aug 2013 20:03:02 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r7AK2udF099201; Sat, 10 Aug 2013 23:02:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r7AK2udF099201 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r7AK2u3l099200; Sat, 10 Aug 2013 23:02:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 10 Aug 2013 23:02:56 +0300 From: Konstantin Belousov To: Larry Rosenman Subject: Re: crash with cpucontrol/microcode update : Today's -CURRENT Message-ID: <20130810200256.GI4972@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="t7jLP6F5mUg+B1HH" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home 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: Sat, 10 Aug 2013 20:03:02 -0000 --t7jLP6F5mUg+B1HH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 10, 2013 at 02:06:10PM -0500, Larry Rosenman wrote: > I'm getting the following @R254183: > when I try to run the microcode_update. >=20 > Just started with yesterday's -CURRENT. > (kgdb) #0 doadump (textdump=3D) at pcpu.h:236 > #1 0xffffffff8051d6f0 in kern_reboot (howto=3D260) > at /usr/src/sys/kern/kern_shutdown.c:447 > #2 0xffffffff8051da77 in panic (fmt=3D) > at /usr/src/sys/kern/kern_shutdown.c:754 > #3 0xffffffff80780d9a in trap_fatal (frame=3D, > eva=3D) at /usr/src/sys/amd64/amd64/trap.c:873 > #4 0xffffffff80781199 in trap_pfault (frame=3D0x0, usermode=3D0) > at /usr/src/sys/amd64/amd64/trap.c:731 > #5 0xffffffff80780792 in trap (frame=3D0xffffff900d55c7b0) > at /usr/src/sys/amd64/amd64/trap.c:463 > #6 0xffffffff8076ad02 in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:232 > #7 0xffffffff80709be9 in vm_page_unwire (m=3D0x0, activate=3D0) > at /usr/src/sys/vm/vm_page.c:2356 > #8 0xffffffff806fb4ed in kmem_unback (object=3D0xffffffff80c57550, > addr=3D, size=3D4096) at /usr/src/sys/vm/vm_ker= n.c:404 > #9 0xffffffff806fb5a4 in kmem_free (vmem=3D0xffffffff80bd7780, > addr=3D18446741884987129872, size=3D4096) at /usr/src/sys/vm/vm_kern= =2Ec:421 > #10 0xffffffff80506597 in contigfree (addr=3D0x0, size=3D4048, > type=3D0xffffffff812d5ea0) at /usr/src/sys/kern/kern_malloc.c:435 > #11 0xffffffff812d5a79 in cpuctl_ioctl (dev=3D, > cmd=3D, data=3D0xfffffe000d2a2f80 "0?c", > flags=3D, td=3D) > at /usr/src/sys/modules/cpuctl/../../dev/cpuctl/cpuctl.c:480 > #12 0xffffffff8041962f in devfs_ioctl_f (fp=3D0xfffffe001e68cbe0, > com=3D3222299396, data=3D0xfffffe000d2a2f80, cred=3D, > td=3D0xfffffe0252ebd490) at /usr/src/sys/fs/devfs/devfs_vnops.c:757 > #13 0xffffffff8056b3be in kern_ioctl (td=3D0xfffffe0252ebd490, > fd=3D, com=3D0) at file.h:306 > #14 0xffffffff8056b13f in sys_ioctl (td=3D0xfffffe0252ebd490, > uap=3D0xffffff900d55cb80) at /usr/src/sys/kern/sys_generic.c:693 > #15 0xffffffff80781697 in amd64_syscall (td=3D0xfffffe0252ebd490, traced= =3D0) > at subr_syscall.c:134 > #16 0xffffffff8076afeb in Xfast_syscall () > at /usr/src/sys/amd64/amd64/exception.S:391 Try this. diff --git a/sys/dev/cpuctl/cpuctl.c b/sys/dev/cpuctl/cpuctl.c index 742ef0db..4e5abb2 100644 --- a/sys/dev/cpuctl/cpuctl.c +++ b/sys/dev/cpuctl/cpuctl.c @@ -346,8 +346,7 @@ update_intel(int cpu, cpuctl_update_args_t *args, struc= t thread *td) else ret =3D EEXIST; fail: - if (ptr !=3D NULL) - contigfree(ptr, args->size, M_CPUCTL); + free(ptr, M_CPUCTL); return (ret); } =20 @@ -476,8 +475,7 @@ update_via(int cpu, cpuctl_update_args_t *args, struct = thread *td) else ret =3D 0; fail: - if (ptr !=3D NULL) - contigfree(ptr, args->size, M_CPUCTL); + free(ptr, M_CPUCTL); return (ret); } =20 --t7jLP6F5mUg+B1HH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJSBpxvAAoJEJDCuSvBvK1B6AAP/0h9rkaGEBwupRftJ3JIGIY1 XB8cxGN47FTAyhtKb/e55oohQX6deLJtWfkS+Dh+njvscnl/2mm5crWeXARclItG dAOV+JIyDJS+owVVJhOz+0tVFdi1RJGj2o3KNClgPDcJlwTD3AqGNOwYBbSidY6g KC3FyWA6Xdptu7encyMhguKIkWRpTW8oxzl/RG0o0oqi7kvJwOjuZGGQ8aseWnI7 gz+v+INQaceF77tvFysiFwTuheZD+lOY5C6o4wKsdYp7L860BH/q+JT79fepm64w kqC+IZpsLqPu9uTPV9jOjx9yyy6cvaLagBLFXg8qnqh4yunDVl0+As8JomBiLLo0 n9mSrMnz8BPem3ZjH1CoqbRbE4mVRdjyjaVDDzzbFH3eTGVmNRls+Xqqs8OTdChZ NTORJcO5jteqXupXxhv49r8NHE6FLC4xNFVVwPQIAvaiXSk/ML1OVO0iGSr4DnQp Qpyz9GC/DDiN09gryYyqX232EIalgrxelWU9KHSQteL1LSxw1YbX6IlJPkGcbEsh Yu82gM7e4E2Iw5T17L/Dye+NDQgyIOrou71ruSf0XzHDbnfNhVVEiUoNuODxssRK mM5ojww/319+8E/c4vkHNff9rrnzJ0AyrJS9timQVhyjXRcWeRsN4rMn/sGaxhnB EQphhh+3rF3L58bhCTx3 =+5V8 -----END PGP SIGNATURE----- --t7jLP6F5mUg+B1HH-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 20:12:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 29F43964 for ; Sat, 10 Aug 2013 20:12:03 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E8B352E58 for ; Sat, 10 Aug 2013 20:12:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=lUvVFh4J0dtUaCu0MM2d7N1Or4Yb+FwRWAKfOAfMO3M=; b=T64imEWbelyRaYA6CycaC81tKVrGPbYNVPzO1R9u9ereHRfyAGRjv7o2sjhA0ID2dS7CSOPnWNVc7RJiXvmd2pMWVLWEj9KgKxQ++XMB5Dks9zWhZ4F5KRffvMcX1xdfvQGAmm7WrZIH6WtvF7jYHy0yFo+hR7QZ7/QTlk/MZ2w=; Received: from localhost.lerctr.org ([127.0.0.1]:14312 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpa (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1V8FW4-000NX2-Ep for freebsd-current@freebsd.org; Sat, 10 Aug 2013 15:12:01 -0500 Received: from cpe-72-182-93-216.austin.res.rr.com ([72.182.93.216]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Sat, 10 Aug 2013 15:11:59 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 10 Aug 2013 15:11:59 -0500 From: Larry Rosenman To: freebsd-current@freebsd.org Subject: Re: crash with cpucontrol/microcode update : Today's -CURRENT In-Reply-To: <20130810200256.GI4972@kib.kiev.ua> References: <20130810200256.GI4972@kib.kiev.ua> Message-ID: X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/0.9.2 X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 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: Sat, 10 Aug 2013 20:12:03 -0000 On 2013-08-10 15:02, Konstantin Belousov wrote: > Try this. > > diff --git a/sys/dev/cpuctl/cpuctl.c b/sys/dev/cpuctl/cpuctl.c > index 742ef0db..4e5abb2 100644 > --- a/sys/dev/cpuctl/cpuctl.c > +++ b/sys/dev/cpuctl/cpuctl.c > @@ -346,8 +346,7 @@ update_intel(int cpu, cpuctl_update_args_t *args, > struct thread *td) > else > ret = EEXIST; > fail: > - if (ptr != NULL) > - contigfree(ptr, args->size, M_CPUCTL); > + free(ptr, M_CPUCTL); > return (ret); > } > > @@ -476,8 +475,7 @@ update_via(int cpu, cpuctl_update_args_t *args, > struct thread *td) > else > ret = 0; > fail: > - if (ptr != NULL) > - contigfree(ptr, args->size, M_CPUCTL); > + free(ptr, M_CPUCTL); > return (ret); > } Fixed it. # service microcode_update onestart Updating cpucodes... /usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl0 from rev 0x60c to rev 0x60f... done. /usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl1 from rev 0x60c to rev 0x60f... done. /usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl2 from rev 0x60c to rev 0x60f... done. /usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl3 from rev 0x60c to rev 0x60f... done. /usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl4 from rev 0x60c to rev 0x60f... done. /usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl5 from rev 0x60c to rev 0x60f... done. /usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl6 from rev 0x60c to rev 0x60f... done. /usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl7 from rev 0x60c to rev 0x60f... done. Done. # ^D$ -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 20:25:28 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 106FFC91 for ; Sat, 10 Aug 2013 20:25:28 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C36F32ECD for ; Sat, 10 Aug 2013 20:25:27 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1V8Fj3-0003Y7-CS for freebsd-current@freebsd.org; Sat, 10 Aug 2013 22:25:25 +0200 Received: from a91-154-115-217.elisa-laajakaista.fi ([91.154.115.217]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 10 Aug 2013 22:25:25 +0200 Received: from rakuco by a91-154-115-217.elisa-laajakaista.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 10 Aug 2013 22:25:25 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Raphael Kubo da Costa Subject: Re: panic on boot with fresh current Date: Sat, 10 Aug 2013 23:25:13 +0300 Lines: 6 Message-ID: <864nax2t06.fsf@orwell.Elisa> References: <20130810112410.GA27286@devbox.vnode.local> <52066DE0.2060305@shatow.net> <52067537.2070309@shatow.net> <20130810174407.GD4972@kib.kiev.ua> <20130810174547.GE4972@kib.kiev.ua> <20130810182109.GG4972@kib.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: a91-154-115-217.elisa-laajakaista.fi User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (berkeley-unix) Cancel-Lock: sha1:FyZEHboDmJBXMfWIQ6yVdYr4sSg= 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: Sat, 10 Aug 2013 20:25:28 -0000 Konstantin Belousov writes: > The right fix looks to be just what the panic message told, please try > this: The patch managed to fix the crash here at least. From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 20:32:20 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 134BFE06 for ; Sat, 10 Aug 2013 20:32:20 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C65AB2F22 for ; Sat, 10 Aug 2013 20:32:19 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1V8Fpg-0008HR-2n for freebsd-current@freebsd.org; Sat, 10 Aug 2013 22:32:16 +0200 Received: from a91-154-115-217.elisa-laajakaista.fi ([91.154.115.217]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 10 Aug 2013 22:32:16 +0200 Received: from rakuco by a91-154-115-217.elisa-laajakaista.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 10 Aug 2013 22:32:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Raphael Kubo da Costa Subject: Entropy harvesting sysctl error messages as of r254181 Date: Sat, 10 Aug 2013 23:32:04 +0300 Lines: 10 Message-ID: <86zjsp1e4b.fsf@orwell.Elisa> Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: a91-154-115-217.elisa-laajakaista.fi User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (berkeley-unix) Cancel-Lock: sha1:w0r4+50TTBTJKR4dkhABYEqYHGY= 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: Sat, 10 Aug 2013 20:32:20 -0000 After updating -CURRENT from a one or two-month old checkout, I get the following messages when /etc/rc.d/initrandom is run: Entropy harvesting:sysctl: unknown oid 'kern.random.sys.harvest.interrupt': No such file or directory interruptssysctl: unknown oid 'kern.random.sys.harvest.ethernet': No such file or directory ethernetsysctl: unknown oid 'kern.random.sys.harvest.point_to_point': No such file or directory point_to_point kickstart Is there something fishy I should look for? kern.random.adaptors is set to "rdrandyarrow", and this is an IvyBridge laptop running amd64. From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 20:52:28 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6BAE8541 for ; Sat, 10 Aug 2013 20:52:28 +0000 (UTC) (envelope-from bryan-lists@shatow.net) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2132D2FF0 for ; Sat, 10 Aug 2013 20:52:27 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sweb; b=pN7gtB J/kf2/733EUFTxhRXwmkWlbknVDndkGr+stMnRmvJWtHBVX6TG7yyFes+UIn4rdq 3+KB0rSTmO94/pdCmBSXvzhxZaLf8BovTSmu0UE3fS5xfI1ZJStzmUA2SE6aPLBS giezQ3sfIrSom7/zjeSJCa7aDp90OngsX+YHg= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sweb; bh=cfTXYdbfKPin vnu4YCQ/G9EFLCcSg+RWuQ4L21wfy50=; b=amngjDZvUUBJ+oG7rt9K+TvFm3o4 vURqcqdUhogOD/4ynV0E031XvlM3hD8e+COhfSSjYpcyjw+ERCSqr6PaPUJDGZFq C6tq+6Ki/i9tsoJcKXfWEOULYk1nqb/5C9NKWhfqEKvVpXOWOGcvtPZxaLcjqHg1 Zb3rr1Tw9teuoPg= Received: (qmail 35778 invoked from network); 10 Aug 2013 15:52:26 -0500 Received: from unknown (HELO ?10.10.0.24?) (bryan@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 10 Aug 2013 15:52:26 -0500 Message-ID: <5206A7FD.3030708@shatow.net> Date: Sat, 10 Aug 2013 15:52:13 -0500 From: Bryan Drewery User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: panic on boot with fresh current References: <20130810112410.GA27286@devbox.vnode.local> <52066DE0.2060305@shatow.net> <52067537.2070309@shatow.net> <20130810174407.GD4972@kib.kiev.ua> <20130810174547.GE4972@kib.kiev.ua> In-Reply-To: <20130810174547.GE4972@kib.kiev.ua> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 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: Sat, 10 Aug 2013 20:52:28 -0000 On 8/10/2013 12:45 PM, Konstantin Belousov wrote: > On Sat, Aug 10, 2013 at 08:44:07PM +0300, Konstantin Belousov wrote: >> On Sat, Aug 10, 2013 at 12:15:35PM -0500, Bryan Drewery wrote: >>> On 8/10/2013 11:44 AM, Bryan Drewery wrote: >>>> On 8/10/2013 6:24 AM, Joel Dahl wrote: >>>>> panic: witness_init: pending locks list is too small, increase >>>>> WITNESS_PENDLIST >>>> I also get this. The last stable revision for me was r254150 >>> >>> r254150 stable, r254171 panic. >>> >>> backtrace: https://dl.dropboxusercontent.com/u/8732004/r254171-panic.jpg >> >> So could you point to exact commit which causes panic ? > It is r254167, right ? > That was my guess based on the stack trace. I will try your patch. -- Regards, Bryan Drewery bdrewery@freenode/EFNet From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 21:27:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 81973C6F for ; Sat, 10 Aug 2013 21:27:06 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 17B7E21CD for ; Sat, 10 Aug 2013 21:27:05 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id x12so4536585wgg.24 for ; Sat, 10 Aug 2013 14:27:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=RR1wnmHimcJU46ZjjXSLHSC2orcOpUh3XNRnsP6Yfc8=; b=TYXe2VUF422IYbAtCzaRYtK9dooQEvZ7Oq2vgXV2Iow9kHTcbljeECfKahAGELBl+Y mkxj54FjFm04thr+yAksGPEmNo8WdrZCSU2L+ZUbGGMMIUeIuwtADZ3Lx9me8GujSbfV JT0uGV2FElJji7SuMGhLxpBw47B9uwQ5RNgsj6vs1qXbDeGH+NbtlB8VWOSuam+MV5Ne 8dZS63su3vs295nyD1GDAdj04c9zETQ3JRMZf1gA7uiH1EqESD7VlA9BqqssH2RZaL24 X/Wj/EstNChrkHCVvBSHXRR8fxH2DfmQPqel+ytcVmMbfch6Oq7ZH7UpBb8eM67r6wvZ +2wg== MIME-Version: 1.0 X-Received: by 10.180.160.165 with SMTP id xl5mr3226691wib.46.1376170024020; Sat, 10 Aug 2013 14:27:04 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.116.136 with HTTP; Sat, 10 Aug 2013 14:27:03 -0700 (PDT) In-Reply-To: <20130810182109.GG4972@kib.kiev.ua> References: <20130810112410.GA27286@devbox.vnode.local> <52066DE0.2060305@shatow.net> <52067537.2070309@shatow.net> <20130810174407.GD4972@kib.kiev.ua> <20130810174547.GE4972@kib.kiev.ua> <20130810182109.GG4972@kib.kiev.ua> Date: Sat, 10 Aug 2013 14:27:03 -0700 X-Google-Sender-Auth: jTPQUFKltbfqlIkRMXzlGMS2a0Y Message-ID: Subject: Re: panic on boot with fresh current From: Adrian Chadd To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, Bryan Drewery 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: Sat, 10 Aug 2013 21:27:06 -0000 Hi, I can reproduce it locally, purely by booting an unchanged amd64 GENERIC. Are you testing it against an _unmodified_ GENERIC, on amd64? If it doesn't panic for you but it does panic for me (and I'll go and get the svn version once I reboot to the old kernel and test) then there may be a hidden problem here that needs solving as this could vary based upon the machine it's happening on. Thanks, -adrian From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 21:29:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 26FD9D93 for ; Sat, 10 Aug 2013 21:29:35 +0000 (UTC) (envelope-from bryan-lists@shatow.net) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B69AD21E9 for ; Sat, 10 Aug 2013 21:29:34 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sweb; b=FoIPG6 i2jt5EAuZEzZifuV3KoUx2NB6K6z2TCapPS9sNoexG4CSVHlJctiRvYeH5uiexqJ xtX1N+7xqOyGE/HChP+GM56xUYMH2cNzIgMUNXLxHVYG/tH5AngAoiXAkF6NEw8U ypYXG9A7xGo/BZWwJpzon/e+Llsfl3FOqnmpU= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sweb; bh=FhaqJR552LVf 7roTzAUnXO5YiT4keas8190X7t5PS3M=; b=ER3CZtK6l9cZ8OUhMHJbyDcSGQkq gCSitzkwQjvnsIWGqTj6kULdwVUpDD6v8tFAc+ybtPQ9fxwAaAmvEmq4G47z7t5T AhzUmX4xfMBxFnoz4pjOeRe/6JRlcTIxG2Jn5XMwSPhSgcFmQzcwHv46DtxhI7DX n2k5mu43FZZXkyw= Received: (qmail 30702 invoked from network); 10 Aug 2013 16:29:32 -0500 Received: from unknown (HELO ?10.10.0.24?) (bryan@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 10 Aug 2013 16:29:32 -0500 Message-ID: <5206B0B0.7030201@shatow.net> Date: Sat, 10 Aug 2013 16:29:20 -0500 From: Bryan Drewery User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: panic on boot with fresh current References: <20130810112410.GA27286@devbox.vnode.local> <52066DE0.2060305@shatow.net> <52067537.2070309@shatow.net> <20130810174407.GD4972@kib.kiev.ua> <20130810174547.GE4972@kib.kiev.ua> <20130810182109.GG4972@kib.kiev.ua> In-Reply-To: <20130810182109.GG4972@kib.kiev.ua> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 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: Sat, 10 Aug 2013 21:29:35 -0000 On 8/10/2013 1:21 PM, Konstantin Belousov wrote: > On Sat, Aug 10, 2013 at 08:45:47PM +0300, Konstantin Belousov wrote: >> On Sat, Aug 10, 2013 at 08:44:07PM +0300, Konstantin Belousov wrote: >>> On Sat, Aug 10, 2013 at 12:15:35PM -0500, Bryan Drewery wrote: >>>> On 8/10/2013 11:44 AM, Bryan Drewery wrote: >>>>> On 8/10/2013 6:24 AM, Joel Dahl wrote: >>>>>> panic: witness_init: pending locks list is too small, increase >>>>>> WITNESS_PENDLIST >>>>> I also get this. The last stable revision for me was r254150 >>>> >>>> r254150 stable, r254171 panic. >>>> >>>> backtrace: https://dl.dropboxusercontent.com/u/8732004/r254171-panic.jpg >>> >>> So could you point to exact commit which causes panic ? >> It is r254167, right ? >> > So I cannot reproduce it locally. The problem is that r254167 moved sleepq > initialization before witness is operational, and witness has a backlog > of locks initialized before witness init. The backlog overflown. > > The right fix looks to be just what the panic message told, please try > this: Yup this patch fixed it, as stated. Thank you for looking at this. -- Regards, Bryan Drewery From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 21:34:33 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C07BA6C; Sat, 10 Aug 2013 21:34:33 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 92F532236; Sat, 10 Aug 2013 21:34:33 +0000 (UTC) Received: by mail-pd0-f171.google.com with SMTP id g10so1890135pdj.16 for ; Sat, 10 Aug 2013 14:34:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=HAOGqi6ek7imOHuQlpIHHHFhxWSa2lO0nPdlpM+ZcSE=; b=KqgRmx1EOd9fQFTUx7/iQxzH4hyvZcXvdFf+mHQ5pIOlQJjZpaGDvYg9RDlzmwAX4M W8IQPdmJbRxEjIG/A8ryK9s2BPHgZUXz0+TQddMDDRsY1wwc5T3vgdGeRxjkGTZkOZlh TcFd4SUnBO5C8mJbPtDJVXmGjrO55O5m0rV+RyYJiyIjJsFfuTzBxFomKIQkB0ccnNzo n67k0Dixg+R6S7G1iUikzhQYqppaV0BGqBRn6H5Ho17kcNfY8zUcllzli+rrXJjhBkrL KmkHxVSBFPdglUlelLpOGpG1Rz+s2pB1ydbgvyjtb669XCl/EN9Xy2Pf+rC13+2M/2rj Z7Gg== MIME-Version: 1.0 X-Received: by 10.66.102.70 with SMTP id fm6mr6931734pab.57.1376170472077; Sat, 10 Aug 2013 14:34:32 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.67.14.66 with HTTP; Sat, 10 Aug 2013 14:34:32 -0700 (PDT) In-Reply-To: <52055201.7040506@bitfrost.no> References: <52055201.7040506@bitfrost.no> Date: Sat, 10 Aug 2013 14:34:32 -0700 X-Google-Sender-Auth: xwBWcp8-4gKOAcOBJ3ikv0Tx5LQ Message-ID: Subject: Re: FYI: Advanced USB compliance testing tool now in the tree (10-current only) From: Kevin Oberman To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current , freebsd-usb@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: Sat, 10 Aug 2013 21:34:33 -0000 On Fri, Aug 9, 2013 at 1:33 PM, Hans Petter Selasky wrote: > Hi, > > For those of you that want to make sure your USB mass storage device > behaves correctly when using FreeBSD, typically for critical applications, > I've just added an advanced USB testing tool to the FreeBSD source tree. It > can be used to stress your USB mass storage device in ways that are beyond > what "bonnie" will do. See tools/tools/usbtest or the following commit: > > http://svnweb.freebsd.org/**changeset/base/254159 > > --HPS Looks very nice. While it is now only in head, is there a reason it could not be built and used on a 9.2-BETA system? (I have not tried. Just wondering if I should.) -- R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 21:47:22 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 51865560 for ; Sat, 10 Aug 2013 21:47:22 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E15CD22D7 for ; Sat, 10 Aug 2013 21:47:21 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.7/8.14.7/ALCHEMY.FRANKEN.DE) with ESMTP id r7ALlKZL060731; Sat, 10 Aug 2013 23:47:20 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.7/8.14.7/Submit) id r7ALlJWX060730; Sat, 10 Aug 2013 23:47:19 +0200 (CEST) (envelope-from marius) Date: Sat, 10 Aug 2013 23:47:19 +0200 From: Marius Strobl To: Scott Long Subject: Re: CFT: PCI Command Register fixups Message-ID: <20130810214719.GA60616@alchemy.franken.de> References: <5E12B1A6-5B39-46FE-B8C7-239D23AEEE5E@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5E12B1A6-5B39-46FE-B8C7-239D23AEEE5E@samsco.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "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: Sat, 10 Aug 2013 21:47:22 -0000 On Fri, Aug 09, 2013 at 09:56:48PM -0600, Scott Long wrote: > All, > > Subversion rev 250418 affected approximately 63 drivers by making them vulnerable to resource allocation failures on motherboards with buggy BIOSes. The revision itself is good, but it needs to address these drivers and bring them up to what is, in effect, a modified way for drivers to manage their PCI resources. If you've been seeing something like the following message since June 24/27, then you need this patch: > > mps0: port 0xd000-0xd0ff mem 0xfb79c000-0xfb79ffff irq 19 at device 0.0 on pci4 > mps0: PCI memory window not available > device_attach: mps0 attach returned 6 > > The patch originated from John Baldwin, I merely fixed up a few nits and am passing it around for review and testing. Please find it here: > > http://people.freebsd.org/~scottl/pci_command_fixes.patch > In mpt_pci.c, there's a style nit/inconsistency regarding the other drivers touched by the above patch; if after these fixes, a driver still fiddles with PCIR_COMMAND, it should be just fine to also OR in PCIM_CMD_BUSMASTEREN as part of that and to not additionally call pci_enable_busmaster(). Apart from that, the patch looks good to me. Marius From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 23:07:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 49BE1B33 for ; Sat, 10 Aug 2013 23:07:35 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0B814257A for ; Sat, 10 Aug 2013 23:07:34 +0000 (UTC) Received: by mail-vc0-f181.google.com with SMTP id hz10so1911895vcb.40 for ; Sat, 10 Aug 2013 16:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=REfseamwFuB5KERx+ARP4Zs4vLit4oIGiFD9m1V56ts=; b=X4252rjhC6TypaPbtQyPqeeYudIT9JNnaf6aWAQ17crmJsSDdX8Mu0gAky28xgrvBm MVqqxn7XLLrnsx8qogVRc83Bnb7GIAZW1u9tMsBcquTRSpQoHRfxgeC0Ci49Y8IiXWBr 63t464nytDglu8XVLEbwK/sXUJoX9L0tKTeBPXwz5wjw9zUotnGQFoVNIguI8nzNheQS HTv1ALmRIXcaUX2xkItA/zdsrvvc2GFLEvWY15BXICOtJxLOkiJ7EQhUoF29BVTeYTND gnU0LecU95gUbqiCpgSN0YCH5+UqKbaWrgRN7qvZJyJ4BVZuAucYuurlHRdbZqBCbDh+ 1Prg== MIME-Version: 1.0 X-Received: by 10.58.135.167 with SMTP id pt7mr3404601veb.75.1376176053246; Sat, 10 Aug 2013 16:07:33 -0700 (PDT) Received: by 10.220.96.78 with HTTP; Sat, 10 Aug 2013 16:07:33 -0700 (PDT) In-Reply-To: References: Date: Sat, 10 Aug 2013 19:07:33 -0400 Message-ID: Subject: Re: Light humour From: "Sam Fourman Jr." To: Paul Webster Content-Type: text/plain; charset=ISO-8859-1 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: Sat, 10 Aug 2013 23:07:35 -0000 On Sat, Apr 27, 2013 at 6:31 PM, Paul Webster wrote: > Just got this link on IRC, (freenode/##freebsd) was so funny I thought > I would see if I could get any of you guys to spit out you're coffee > :) > > http://antibsd.wordpress.com/ > _______________________________________________ Sorry I am REALLY late to this party, but wow this site made me laugh :) I straight up choked on my soda.......... -- Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Sat Aug 10 23:09:11 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4CC5DC50 for ; Sat, 10 Aug 2013 23:09:11 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-vb0-x22d.google.com (mail-vb0-x22d.google.com [IPv6:2607:f8b0:400c:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0D40C258D for ; Sat, 10 Aug 2013 23:09:10 +0000 (UTC) Received: by mail-vb0-f45.google.com with SMTP id e15so4884982vbg.18 for ; Sat, 10 Aug 2013 16:09:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LyWwaMrJiK8jPTRJKAIHXHm95Wj+Atf77ItXieLEKBg=; b=zg8lIi4ymG/ggLCr0OGKPZwHy8C4zaHWJ7Ci/5ULGg6+ATi0k9mWSt9ghfsH6atutG nUrOmIfX+p5BGPcZYw1/GuwZQZfAwg6XRvS4VWgR47Aq6M6VLa5EJVkeNsK3RMh8IbO7 NnSRkXwnYa6wa9jW7DzR0+WHOkkZluZGzjEQ/n/TmdkSZnoJ3PvZlrB5uac3mwRCnN01 emtLG/EhXlC085gJ5SXnN6n7VF0T8Ujpk+wEcwmVsDofOEJ8J2gVz7+upe7OWS5TGfBE TaPed2S09E6K6fEfNnhaUbYRmQob0SltGntkn+y0dMGMjWk/ObCdXh6Akl8KhcjypjOs J0yQ== MIME-Version: 1.0 X-Received: by 10.52.176.106 with SMTP id ch10mr7446531vdc.41.1376176150204; Sat, 10 Aug 2013 16:09:10 -0700 (PDT) Received: by 10.220.96.78 with HTTP; Sat, 10 Aug 2013 16:09:10 -0700 (PDT) In-Reply-To: References: Date: Sat, 10 Aug 2013 19:09:10 -0400 Message-ID: Subject: Re: Light humour From: "Sam Fourman Jr." To: Paul Webster Content-Type: text/plain; charset=ISO-8859-1 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: Sat, 10 Aug 2013 23:09:11 -0000 On Sat, Aug 10, 2013 at 7:07 PM, Sam Fourman Jr. wrote: > On Sat, Apr 27, 2013 at 6:31 PM, Paul Webster > wrote: >> Just got this link on IRC, (freenode/##freebsd) was so funny I thought >> I would see if I could get any of you guys to spit out you're coffee >> :) >> >> http://antibsd.wordpress.com/ >> _______________________________________________ > > > Sorry I am REALLY late to this party, but wow this site made me laugh :) > I straight up choked on my soda.......... > -- > > Sam Fourman Jr. he changed the link... http://aboutthebsds.wordpress.com/ -- Sam Fourman Jr.