From owner-freebsd-stable@FreeBSD.ORG Sun Nov 18 00:16:34 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4749816A46B; Sun, 18 Nov 2007 00:16:34 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id A14C113C459; Sun, 18 Nov 2007 00:16:33 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (dialup80.ach.sch.gr [81.186.70.80]) (authenticated bits=128) by igloo.linux.gr (8.14.1/8.14.1/Debian-9) with ESMTP id lAI00Y0Q019881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 18 Nov 2007 02:00:44 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.2/8.14.2) with ESMTP id lAHMAeQP004704; Sun, 18 Nov 2007 00:10:40 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.2/8.14.2/Submit) id lAHMAent004703; Sun, 18 Nov 2007 00:10:40 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Date: Sun, 18 Nov 2007 00:10:40 +0200 From: Giorgos Keramidas To: Ivan Voras Message-ID: <20071117221040.GA4665@kobe.laptop> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.94, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.46, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Regression in 7.0BETA2: unionfs and cd9660 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2007 00:16:34 -0000 On 2007-11-17 22:29, Ivan Voras wrote: > Hi, > > I'm reporting a regression in recent RELENG_7, it was present (and I've > reported it) on BETA2, and I sadly confirm that it's also present in > BETA3. The problem is that cd9660 doesn't want to be the underlying > layer for unionfs. > > How to repeat: > > Boot a system with root on cd9660 (e.g. "LiveCD"), then create a > UFS-based md/mfs, then try to mount it via unionfs over (e.g.) /etc: > > # <...make a ram-drive / memory file system on /tmp> > # mount_unionfs /tmp /etc > mount_unionfs: /etc: operation not supported by device > > This worked ok with BETA1 and even -CURRENT versions, and I've located > the breaking point somewhere between: > > #*default date=2007.11.07.00.00.00 > # > #*default date=2007.11.08.00.00.00 > > I don't know if the date is local or UTC, [...] FWIW, if these are dates used as -D 'arg' in cvs(1), then they are UTC. From owner-freebsd-stable@FreeBSD.ORG Sun Nov 18 01:26:28 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7208616A41A for ; Sun, 18 Nov 2007 01:26:28 +0000 (UTC) (envelope-from gepu@iogyte.ro) Received: from iogyte.ro (mail.iogyte.ro [62.231.111.163]) by mx1.freebsd.org (Postfix) with SMTP id B20FA13C44B for ; Sun, 18 Nov 2007 01:26:27 +0000 (UTC) (envelope-from gepu@iogyte.ro) Received: (qmail 45953 invoked by uid 1001); 18 Nov 2007 01:26:16 -0000 Date: Sun, 18 Nov 2007 03:26:16 +0200 From: Dan Epure To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Message-ID: <20071118012616.GF19354@iogyte.ro> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: pseudo terminals in 7.0 - pts implementation X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dan Epure List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2007 01:26:28 -0000 Hi, 7.0-BETA3 still has issues regarding the pts implementation . problems found: 1. - GNU screen: starting a screen, opening a few windows and quiting screen leaves the allocated pseudo terminal in use. 100 screen user, using each one opening 10 windows will deplete the default of 1000 pseudo terminals leaving the system unusable. 2. - 'ls /dev/ptmx' creates an additional entry in /dev/pty/. when the number of entries equals kern.pts.max the system became unusable. this feature is very important for an access server. Please help me find/solve the problem. Regards, Gepu From owner-freebsd-stable@FreeBSD.ORG Sun Nov 18 02:53:58 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56A1116A420 for ; Sun, 18 Nov 2007 02:53:58 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mx.egr.msu.edu (surfnturf.egr.msu.edu [35.9.37.164]) by mx1.freebsd.org (Postfix) with ESMTP id 2E76A13C458 for ; Sun, 18 Nov 2007 02:53:57 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from localhost (localhost.egr.msu.edu [127.0.0.1]) by mx.egr.msu.edu (Postfix) with ESMTP id C33BD2EB8EC; Sat, 17 Nov 2007 21:53:48 -0500 (EST) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mx.egr.msu.edu ([127.0.0.1]) by localhost (surfnturf.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YErj5j8-30Jc; Sat, 17 Nov 2007 21:53:48 -0500 (EST) Received: from localhost (daemon.egr.msu.edu [35.9.44.65]) by mx.egr.msu.edu (Postfix) with ESMTP id 8A1E12EB8B4; Sat, 17 Nov 2007 21:53:48 -0500 (EST) Received: by localhost (Postfix, from userid 21281) id 737C933C22; Sat, 17 Nov 2007 21:53:48 -0500 (EST) Date: Sat, 17 Nov 2007 21:53:48 -0500 From: Adam McDougall To: Ceri Davies Message-ID: <20071118025348.GB46369@egr.msu.edu> References: <20071117013104.GE46369@egr.msu.edu> <20071117194431.GE14309@submonkey.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071117194431.GE14309@submonkey.net> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: stable@freebsd.org Subject: Re: Hook up idmapd to build in 6-stable? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2007 02:53:58 -0000 On Sat, Nov 17, 2007 at 07:44:31PM +0000, Ceri Davies wrote: On Fri, Nov 16, 2007 at 08:31:04PM -0500, Adam McDougall wrote: > I am beginning to dabble with NFSv4 client functionality. I noticed > idmapd is not built in -stable but it has been in -current since src/sbin/Makefile > v. 1.163 (13 months ago). Should it be hooked up to the build? Thanks At the time I was looking at it in -current, idmapd worked fine but the client had serious issues (nothing on an NFSv4 mount could be executed, for instance) which I couldn't track down, so I stopped working with it. I think that hooking up idmapd could be a good thing to do in order to expose those problems, but I'm concerned that it may give the impression that our NFSv4 client is any use, which it appears not to be (at least 13 months ago; apologies if this is not longer the case). Ceri I hadn't realized until I read the manpage that the nfs4 client was considered incomplete, I suppose one of the first clues was idmap not being hooked up to the build :) and while I got a mount working and with idmap, it was discovered that ctimes appear to be broken: > ls -lc total 5 drwxr-xr-x 5 nobody nobody 4096 Dec 31 1969 Maildir -rw------- 1 nobody nobody 1029 Mar 3 1970 foo I doubt I will continue looking at the nfsv4 client in this state, and I don't really have a reason to use it at this point in time, but perhaps it would be better to state the apparent usefulness in a manpage to not give false impressions. Of course, that also takes work. From owner-freebsd-stable@FreeBSD.ORG Sun Nov 18 11:33:22 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C64FA16A417 for ; Sun, 18 Nov 2007 11:33:22 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 9EA5613C442 for ; Sun, 18 Nov 2007 11:33:22 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 05CF947791; Sun, 18 Nov 2007 06:08:31 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Sun, 18 Nov 2007 06:08:31 -0500 X-Sasl-enc: DS17NuCEXcZVF0dm9msZpA5qPtbsWTnTSzW58duPWz8s 1195384110 Received: from [192.168.1.235] (64-142-85-108.dsl.dynamic.sonic.net [64.142.85.108]) by mail.messagingengine.com (Postfix) with ESMTP id 961592A61D; Sun, 18 Nov 2007 06:08:30 -0500 (EST) Message-ID: <47401CA1.8000302@freebsd.org> Date: Sun, 18 Nov 2007 03:06:09 -0800 From: Darren Reed User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: RELENG_6 IPFilter MFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2007 11:33:22 -0000 I've just completed an MFC of IPFIilter in the FreeBSD 6 branch (RELENG_6) from HEAD. This brings the code used for IPFilter in FreeBSD into sync on each of HEAD, RELENG_6 and RELENG_7. Hopefully I can close one or two bug reports now ;) If you encounter any problems, please let me know. Cheers, Darren From owner-freebsd-stable@FreeBSD.ORG Sun Nov 18 14:45:47 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D511D16A46C; Sun, 18 Nov 2007 14:45:47 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9387013C48E; Sun, 18 Nov 2007 14:45:47 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id C2B35475AE; Sun, 18 Nov 2007 09:47:53 -0500 (EST) Date: Sun, 18 Nov 2007 14:45:28 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Dan Epure In-Reply-To: <20071118012616.GF19354@iogyte.ro> Message-ID: <20071118144243.B97497@fledge.watson.org> References: <20071118012616.GF19354@iogyte.ro> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, csjp@FreeBSD.org Subject: Re: pseudo terminals in 7.0 - pts implementation X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2007 14:45:47 -0000 On Sun, 18 Nov 2007, Dan Epure wrote: > 7.0-BETA3 still has issues regarding the pts implementation . > problems found: > 1. - GNU screen: starting a screen, opening a few windows and quiting screen leaves the allocated pseudo terminal in use. 100 screen user, using each one opening 10 windows will deplete the default of 1000 pseudo terminals leaving the system unusable. > 2. - 'ls /dev/ptmx' creates an additional entry in /dev/pty/. when the number of entries equals kern.pts.max the system became unusable. The first of these is likely a reference management bug of some sort -- I find that if I close a pty in screen by exiting the shell, the pts device is GC'd properly, but if I close it by killing the session with ctrl-k, then the pts device is not properly GC'd and processes hung off it not properly killed. I believe that closing the master device is not properly kicking the slave device and causing its consumers to exit, hence the pts device not being closd and released. Christian was taking a look at this a couple of days ago, and I've CC'd him. The second problem is more tricky, and has to do with the cloning model. Similar problems can exist with other variations on the ptmx implementation, and I need to give some thought to how to address this. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Sun Nov 18 16:10:34 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A283216A419; Sun, 18 Nov 2007 16:10:34 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 63D5113C465; Sun, 18 Nov 2007 16:10:34 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id lAIGAR2a000376; Sun, 18 Nov 2007 11:10:27 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy.sentex.ca (freebsd-legacy.sentex.ca [64.7.128.104]) by smtp1.sentex.ca (8.14.1/8.14.1) with ESMTP id lAIGAR3W087413; Sun, 18 Nov 2007 11:10:27 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-legacy.sentex.ca (Postfix, from userid 666) id D23C4241A2; Sun, 18 Nov 2007 11:10:26 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20071118161026.D23C4241A2@freebsd-legacy.sentex.ca> Date: Sun, 18 Nov 2007 11:10:26 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/4641/Tue Oct 30 15:59:09 2007 clamav-milter version 0.91.2 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [releng_6 tinderbox] failure on i386/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2007 16:10:34 -0000 TB --- 2007-11-18 15:34:45 - tinderbox 2.3 running on freebsd-legacy.sentex.ca TB --- 2007-11-18 15:34:45 - starting RELENG_6 tinderbox run for i386/i386 TB --- 2007-11-18 15:34:45 - cleaning the object tree TB --- 2007-11-18 15:35:30 - checking out the source tree TB --- 2007-11-18 15:35:30 - cd /tinderbox/RELENG_6/i386/i386 TB --- 2007-11-18 15:35:30 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_6 src TB --- 2007-11-18 15:45:10 - building world (CFLAGS=-O2 -pipe) TB --- 2007-11-18 15:45:10 - cd /src TB --- 2007-11-18 15:45:10 - /usr/bin/make -B buildworld >>> 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 [...] echo init: /obj/src/tmp/usr/lib/libc.a /obj/src/tmp/usr/lib/libutil.a /obj/src/tmp/usr/lib/libcrypt.a >> .depend ===> sbin/ip6fw (depend) rm -f .depend mkdep -f .depend -a /src/sbin/ip6fw/ip6fw.c echo ip6fw: /obj/src/tmp/usr/lib/libc.a >> .depend ===> sbin/ipf (depend) ===> sbin/ipf/libipf (depend) make: don't know how to make extras.c. Stop *** Error code 2 Stop in /src/sbin/ipf. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-11-18 16:10:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-11-18 16:10:26 - ERROR: failed to build world TB --- 2007-11-18 16:10:26 - tinderbox aborted TB --- 1193.43 user 183.23 system 2141.48 real http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Sun Nov 18 16:12:01 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F01FE16A419; Sun, 18 Nov 2007 16:12:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 8EE3E13C4E7; Sun, 18 Nov 2007 16:12:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id lAIGBt3H000448; Sun, 18 Nov 2007 11:11:55 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy.sentex.ca (freebsd-legacy.sentex.ca [64.7.128.104]) by smtp1.sentex.ca (8.14.1/8.14.1) with ESMTP id lAIGBtKl089368; Sun, 18 Nov 2007 11:11:55 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-legacy.sentex.ca (Postfix, from userid 666) id D947E241A2; Sun, 18 Nov 2007 11:11:54 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20071118161154.D947E241A2@freebsd-legacy.sentex.ca> Date: Sun, 18 Nov 2007 11:11:54 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/4641/Tue Oct 30 15:59:09 2007 clamav-milter version 0.91.2 on clamscanner5 X-Virus-Status: Clean Cc: Subject: [releng_6 tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2007 16:12:02 -0000 TB --- 2007-11-18 15:31:48 - tinderbox 2.3 running on freebsd-legacy.sentex.ca TB --- 2007-11-18 15:31:48 - starting RELENG_6 tinderbox run for amd64/amd64 TB --- 2007-11-18 15:31:48 - cleaning the object tree TB --- 2007-11-18 15:32:33 - checking out the source tree TB --- 2007-11-18 15:32:33 - cd /tinderbox/RELENG_6/amd64/amd64 TB --- 2007-11-18 15:32:33 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_6 src TB --- 2007-11-18 15:45:10 - building world (CFLAGS=-O2 -pipe) TB --- 2007-11-18 15:45:10 - cd /src TB --- 2007-11-18 15:45:10 - /usr/bin/make -B buildworld >>> 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 [...] echo init: /obj/amd64/src/tmp/usr/lib/libc.a /obj/amd64/src/tmp/usr/lib/libutil.a /obj/amd64/src/tmp/usr/lib/libcrypt.a >> .depend ===> sbin/ip6fw (depend) rm -f .depend mkdep -f .depend -a /src/sbin/ip6fw/ip6fw.c echo ip6fw: /obj/amd64/src/tmp/usr/lib/libc.a >> .depend ===> sbin/ipf (depend) ===> sbin/ipf/libipf (depend) make: don't know how to make extras.c. Stop *** Error code 2 Stop in /src/sbin/ipf. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-11-18 16:11:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-11-18 16:11:54 - ERROR: failed to build world TB --- 2007-11-18 16:11:54 - tinderbox aborted TB --- 1241.84 user 197.65 system 2406.12 real http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Sun Nov 18 16:48:42 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D8EB16A41A; Sun, 18 Nov 2007 16:48:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id E2B2813C459; Sun, 18 Nov 2007 16:48:41 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id lAIGmTcT002456; Sun, 18 Nov 2007 11:48:29 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy.sentex.ca (freebsd-legacy.sentex.ca [64.7.128.104]) by smtp1.sentex.ca (8.14.1/8.14.1) with ESMTP id lAIGmSkC040932; Sun, 18 Nov 2007 11:48:28 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-legacy.sentex.ca (Postfix, from userid 666) id D887B241A2; Sun, 18 Nov 2007 11:48:28 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20071118164828.D887B241A2@freebsd-legacy.sentex.ca> Date: Sun, 18 Nov 2007 11:48:28 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/4641/Tue Oct 30 15:59:09 2007 clamav-milter version 0.91.2 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [releng_6 tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2007 16:48:42 -0000 TB --- 2007-11-18 16:11:55 - tinderbox 2.3 running on freebsd-legacy.sentex.ca TB --- 2007-11-18 16:11:55 - starting RELENG_6 tinderbox run for sparc64/sparc64 TB --- 2007-11-18 16:11:55 - cleaning the object tree TB --- 2007-11-18 16:12:22 - checking out the source tree TB --- 2007-11-18 16:12:22 - cd /tinderbox/RELENG_6/sparc64/sparc64 TB --- 2007-11-18 16:12:22 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_6 src TB --- 2007-11-18 16:23:46 - building world (CFLAGS=-O2 -pipe) TB --- 2007-11-18 16:23:46 - cd /src TB --- 2007-11-18 16:23:46 - /usr/bin/make -B buildworld >>> 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 [...] echo init: /obj/sparc64/src/tmp/usr/lib/libc.a /obj/sparc64/src/tmp/usr/lib/libutil.a /obj/sparc64/src/tmp/usr/lib/libcrypt.a >> .depend ===> sbin/ip6fw (depend) rm -f .depend mkdep -f .depend -a /src/sbin/ip6fw/ip6fw.c echo ip6fw: /obj/sparc64/src/tmp/usr/lib/libc.a >> .depend ===> sbin/ipf (depend) ===> sbin/ipf/libipf (depend) make: don't know how to make extras.c. Stop *** Error code 2 Stop in /src/sbin/ipf. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-11-18 16:48:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-11-18 16:48:28 - ERROR: failed to build world TB --- 2007-11-18 16:48:28 - tinderbox aborted TB --- 1159.70 user 190.87 system 2193.68 real http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Sun Nov 18 16:49:21 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C69716A419; Sun, 18 Nov 2007 16:49:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 2649E13C502; Sun, 18 Nov 2007 16:49:20 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.14.1/8.13.8) with ESMTP id lAIGnDIa053069; Sun, 18 Nov 2007 11:49:13 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy.sentex.ca (freebsd-legacy.sentex.ca [64.7.128.104]) by smtp2.sentex.ca (8.14.1/8.14.1) with ESMTP id lAIGnDu6088427; Sun, 18 Nov 2007 11:49:13 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-legacy.sentex.ca (Postfix, from userid 666) id EF3AD241A2; Sun, 18 Nov 2007 11:49:12 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20071118164912.EF3AD241A2@freebsd-legacy.sentex.ca> Date: Sun, 18 Nov 2007 11:49:12 -0500 (EST) X-Virus-Scanned: ClamAV 0.90.2/3781/Fri Jul 27 07:24:10 2007 clamav-milter version 0.91.1 on news X-Virus-Status: Clean Cc: Subject: [releng_6 tinderbox] failure on i386/pc98 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2007 16:49:21 -0000 TB --- 2007-11-18 16:10:26 - tinderbox 2.3 running on freebsd-legacy.sentex.ca TB --- 2007-11-18 16:10:26 - starting RELENG_6 tinderbox run for i386/pc98 TB --- 2007-11-18 16:10:26 - cleaning the object tree TB --- 2007-11-18 16:10:59 - checking out the source tree TB --- 2007-11-18 16:10:59 - cd /tinderbox/RELENG_6/i386/pc98 TB --- 2007-11-18 16:10:59 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_6 src TB --- 2007-11-18 16:23:46 - building world (CFLAGS=-O2 -pipe) TB --- 2007-11-18 16:23:46 - cd /src TB --- 2007-11-18 16:23:46 - /usr/bin/make -B buildworld >>> 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 [...] echo init: /obj/pc98/src/tmp/usr/lib/libc.a /obj/pc98/src/tmp/usr/lib/libutil.a /obj/pc98/src/tmp/usr/lib/libcrypt.a >> .depend ===> sbin/ip6fw (depend) rm -f .depend mkdep -f .depend -a /src/sbin/ip6fw/ip6fw.c echo ip6fw: /obj/pc98/src/tmp/usr/lib/libc.a >> .depend ===> sbin/ipf (depend) ===> sbin/ipf/libipf (depend) make: don't know how to make extras.c. Stop *** Error code 2 Stop in /src/sbin/ipf. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-11-18 16:49:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-11-18 16:49:12 - ERROR: failed to build world TB --- 2007-11-18 16:49:12 - tinderbox aborted TB --- 1198.17 user 196.55 system 2326.12 real http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Sun Nov 18 18:41:11 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1DA916A469 for ; Sun, 18 Nov 2007 18:41:11 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.freebsd.org (Postfix) with ESMTP id 759F513C448 for ; Sun, 18 Nov 2007 18:41:11 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0JRP008H3T8G40C0@osl1smout1.broadpark.no> for freebsd-stable@freebsd.org; Sun, 18 Nov 2007 19:41:04 +0100 (CET) Received: from kg-work.kg4.no ([80.202.172.249]) by osl1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0JRP00D4AT8GX0X1@osl1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Sun, 18 Nov 2007 19:41:04 +0100 (CET) Date: Sun, 18 Nov 2007 19:41:04 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20071118194104.9f7273dc.torfinn.ingolfsen@broadpark.no> X-Mailer: Sylpheed 2.4.7 (GTK+ 2.12.1; i386-portbld-freebsd6.2) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: FreeBSD.org acting up again? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2007 18:41:11 -0000 Hello, Is the freebsd.org machine acting up again? I get connection resets when I try to do root@kg-work# fetch http://www.FreeBSD.org/ports/INDEX-6.bz2 fetch: http://www.FreeBSD.org/ports/INDEX-6.bz2: Connection reset by peer (or 'make fetchindex' or 'http://www.freebsd.org/') Or is this something else? -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Sun Nov 18 19:29:57 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E199216A469 for ; Sun, 18 Nov 2007 19:29:57 +0000 (UTC) (envelope-from dk@tetsuo.karasik.eu.org) Received: from tetsuo.karasik.eu.org (tetsuo.karasik.eu.org [129.142.67.14]) by mx1.freebsd.org (Postfix) with ESMTP id A7AFC13C4C4 for ; Sun, 18 Nov 2007 19:29:57 +0000 (UTC) (envelope-from dk@tetsuo.karasik.eu.org) Received: by tetsuo.karasik.eu.org (Postfix, from userid 1003) id F3E956169F5; Sun, 18 Nov 2007 20:01:59 +0100 (CET) Date: Sun, 18 Nov 2007 20:01:59 +0100 From: Dmitry Karasik To: freebsd-stable@freebsd.org Message-ID: <20071118190159.GA12962@tetsuo.karasik.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 6.2-STABLE Subject: No kernel messages displayed during boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2007 19:29:58 -0000 Hello, My 6.2-STABLE crashed today, and when I rebooted it, a very strange effect appeared: from the second the kernel took over, immediately after loading all .ko files, no text was printed in the console. The system booted though, and the next text was printed to the console was the login prompt. The screen didn't went blank, just all kernel messages and output of /etc/rc* wasn't there -- all was printed on the screen was FreeBSD boot menu, and login prompt. I've re-run 'make installworld' and 'make installkernel' (as I had leftovers from recent buildworld), - didn't help. I've tried to power down the machine (suspecied video card trouble), I've resetted BIOS, I've even disabled com port in BIOS (because the behavior looks like booting on serial console) -- nothing, absolutely nothing changes it. When I tried to boot in single-user mode, the prompt was never displayed at all, which fact indeed makes me think alogn the path of the wrong boot console. I've removed /boot/loader.conf, and double-checked that /boot.config isn't present - didn't help. My question is therefore, what cause of this effect might be? Or, if noone would be able to answer this, how I would print messages from kernel (I'd recompile it for that purpose) to identify which device it picked up for console IO -- and especially, how I print that either to a file, or directly to /dev/console? -- Sincerely, Dmitry Karasik From owner-freebsd-stable@FreeBSD.ORG Sun Nov 18 19:37:33 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBB7316A419 for ; Sun, 18 Nov 2007 19:37:33 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id BF04D13C4D9 for ; Sun, 18 Nov 2007 19:37:31 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id DA51D1CC07D; Sun, 18 Nov 2007 11:37:19 -0800 (PST) Date: Sun, 18 Nov 2007 11:37:19 -0800 From: Jeremy Chadwick To: Dmitry Karasik Message-ID: <20071118193719.GB11901@eos.sc1.parodius.com> References: <20071118190159.GA12962@tetsuo.karasik.eu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071118190159.GA12962@tetsuo.karasik.eu.org> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-stable@freebsd.org Subject: Re: No kernel messages displayed during boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2007 19:37:33 -0000 On Sun, Nov 18, 2007 at 08:01:59PM +0100, Dmitry Karasik wrote: > I've re-run 'make installworld' and 'make installkernel' (as I had leftovers > from recent buildworld), - didn't help. I've tried to power down the machine > (suspecied video card trouble), I've resetted BIOS, I've even disabled com port > in BIOS (because the behavior looks like booting on serial console) -- nothing, > absolutely nothing changes it. conscontrol(8) might help here ("conscontrol list"). Also worth looking at is sysctl kern.console. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Nov 18 19:40:48 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB6A216A418 for ; Sun, 18 Nov 2007 19:40:48 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id BEF5F13C447 for ; Sun, 18 Nov 2007 19:40:48 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id A9B281CC07B; Sun, 18 Nov 2007 11:34:19 -0800 (PST) Date: Sun, 18 Nov 2007 11:34:19 -0800 From: Jeremy Chadwick To: Torfinn Ingolfsen Message-ID: <20071118193419.GA11901@eos.sc1.parodius.com> References: <20071118194104.9f7273dc.torfinn.ingolfsen@broadpark.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071118194104.9f7273dc.torfinn.ingolfsen@broadpark.no> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD.org acting up again? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2007 19:40:48 -0000 On Sun, Nov 18, 2007 at 07:41:04PM +0100, Torfinn Ingolfsen wrote: > Is the freebsd.org machine acting up again? It was earlier for sure: # telnet www.freebsd.org 80 Trying 2001:4f8:fff6::21... Trying 69.147.83.33... Connected to www.freebsd.org. Escape character is '^]'. Connection closed by foreign host. At present it seems alright, though: # cd /usr/ports # make fetchindex /usr/ports/INDEX-6.bz2 100% of 1128 kB 10 MBps # -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Nov 18 19:42:44 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E846816A46D for ; Sun, 18 Nov 2007 19:42:43 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 3B22B13C45B for ; Sun, 18 Nov 2007 19:42:42 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id lAIJgIEO066083; Mon, 19 Nov 2007 02:42:18 +0700 (KRAT) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id lAIJgIfw066082; Mon, 19 Nov 2007 02:42:18 +0700 (KRAT) (envelope-from eugen) Date: Mon, 19 Nov 2007 02:42:17 +0700 From: Eugene Grosbein To: Torfinn Ingolfsen Message-ID: <20071118194217.GA65999@svzserv.kemerovo.su> References: <20071118194104.9f7273dc.torfinn.ingolfsen@broadpark.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071118194104.9f7273dc.torfinn.ingolfsen@broadpark.no> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD.org acting up again? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2007 19:42:45 -0000 On Sun, Nov 18, 2007 at 07:41:04PM +0100, Torfinn Ingolfsen wrote: > Is the freebsd.org machine acting up again? > I get connection resets when I try to do > root@kg-work# fetch http://www.FreeBSD.org/ports/INDEX-6.bz2 > fetch: http://www.FreeBSD.org/ports/INDEX-6.bz2: Connection reset by peer > > (or 'make fetchindex' or 'http://www.freebsd.org/') > Or is this something else? The same here: port 80 refuses connections. Eugene Grosbein From owner-freebsd-stable@FreeBSD.ORG Sun Nov 18 19:52:04 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6DBB16A417 for ; Sun, 18 Nov 2007 19:52:04 +0000 (UTC) (envelope-from angrywolf@flashmail.com) Received: from a.relay.invitel.net (a.relay.invitel.net [62.77.203.3]) by mx1.freebsd.org (Postfix) with ESMTP id 5755913C461 for ; Sun, 18 Nov 2007 19:52:03 +0000 (UTC) (envelope-from angrywolf@flashmail.com) Received: from mail.invitel.hu (mail.vnet.hu [213.163.59.4]) by a.relay.invitel.net (Invitel Core SMTP Transmitter) with ESMTP id DE75611106E for ; Sun, 18 Nov 2007 20:51:51 +0100 (CET) Received: from 555555.no-ip.org ([87.97.27.183]) by mail.invitel.hu (Invitel Messaging Server) with ESMTPA id <0JRP00JHIWI9GCO0@invitel.hu> for freebsd-stable@freebsd.org; Sun, 18 Nov 2007 20:51:51 +0100 (CET) Received: by 555555.no-ip.org (Postfix, from userid 8) id 49E668FCAE; Sun, 18 Nov 2007 20:51:13 +0100 (CET) Received: from gep7.555555.no-ip.org (gep7 [172.16.0.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by 555555.no-ip.org (Postfix) with ESMTP id 1F5E68FCAE for ; Sun, 18 Nov 2007 20:47:38 +0100 (CET) Date: Sun, 18 Nov 2007 20:47:16 +0100 From: AngryWolf In-reply-to: <20071118190159.GA12962@tetsuo.karasik.eu.org> To: freebsd-stable@freebsd.org Message-id: <200711182047.16811.angrywolf@flashmail.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline References: <20071118190159.GA12962@tetsuo.karasik.eu.org> User-Agent: KMail/1.9.7 Subject: Re: No kernel messages displayed during boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2007 19:52:04 -0000 Hi, I had the exact same problem after I upgraded to 7.0-BETA2, and the problem seemed to be that I forgot to `make delete-old' and `make delete-old-libs'. For details, see thread 'No boot messages after upgrading to 7.0-BETA2'. -- AngryWolf angrywolf@flashmail.com On Sunday 18 November 2007 20.01.59 Dmitry Karasik wrote: > Hello, > > My 6.2-STABLE crashed today, and when I rebooted it, a very strange effect > appeared: from the second the kernel took over, immediately after loading > all .ko files, no text was printed in the console. The system booted > though, and the next text was printed to the console was the login prompt. > The screen didn't went blank, just all kernel messages and output of > /etc/rc* wasn't there -- all was printed on the screen was FreeBSD boot > menu, and login prompt. > > I've re-run 'make installworld' and 'make installkernel' (as I had > leftovers from recent buildworld), - didn't help. I've tried to power down > the machine (suspecied video card trouble), I've resetted BIOS, I've even > disabled com port in BIOS (because the behavior looks like booting on > serial console) -- nothing, absolutely nothing changes it. > > When I tried to boot in single-user mode, the prompt was never displayed at > all, which fact indeed makes me think alogn the path of the wrong boot > console. I've removed /boot/loader.conf, and double-checked that > /boot.config isn't present - didn't help. > > My question is therefore, what cause of this effect might be? Or, if noone > would be able to answer this, how I would print messages from kernel (I'd > recompile it for that purpose) to identify which device it picked up for > console IO -- and especially, how I print that either to a file, or > directly to /dev/console? From owner-freebsd-stable@FreeBSD.ORG Sun Nov 18 19:58:51 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF7BA16A421 for ; Sun, 18 Nov 2007 19:58:51 +0000 (UTC) (envelope-from antik@bsd.ee) Received: from smtp-gw1.starman.ee (smtp-out3.starman.ee [85.253.0.5]) by mx1.freebsd.org (Postfix) with ESMTP id 8F82013C474 for ; Sun, 18 Nov 2007 19:58:51 +0000 (UTC) (envelope-from antik@bsd.ee) Received: from mx1.starman.ee (mx1.starman.ee [62.65.192.16]) by smtp-gw1.starman.ee (Postfix) with ESMTP id F0314A2166C for ; Sun, 18 Nov 2007 21:58:39 +0200 (EET) X-Virus-Scanned: by Amavisd-New at mx1.starman.ee Received: from [192.168.2.100] (pc131.host50.starman.ee [62.65.242.131]) by mx1.starman.ee (Postfix) with ESMTP id 363393F404E for ; Sun, 18 Nov 2007 21:58:39 +0200 (EET) From: Andrei Kolu To: freebsd-stable@freebsd.org Date: Sun, 18 Nov 2007 21:58:38 +0200 User-Agent: KMail/1.9.7 References: <20071118190159.GA12962@tetsuo.karasik.eu.org> In-Reply-To: <20071118190159.GA12962@tetsuo.karasik.eu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711182158.39392.antik@bsd.ee> Subject: Re: No kernel messages displayed during boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2007 19:58:51 -0000 Sunday 18 November 2007 21:01:59 kirjutas Dmitry Karasik: > Hello, > > My 6.2-STABLE crashed today, and when I rebooted it, a very strange effect > appeared: from the second the kernel took over, immediately after loading > all .ko files, no text was printed in the console. The system booted > though, and the next text was printed to the console was the login prompt. > The screen didn't went blank, just all kernel messages and output of > /etc/rc* wasn't there -- all was printed on the screen was FreeBSD boot > menu, and login prompt. > > I've re-run 'make installworld' and 'make installkernel' (as I had > leftovers from recent buildworld), - didn't help. I've tried to power down > the machine (suspecied video card trouble), I've resetted BIOS, I've even > disabled com port in BIOS (because the behavior looks like booting on > serial console) -- nothing, absolutely nothing changes it. > > When I tried to boot in single-user mode, the prompt was never displayed at > all, which fact indeed makes me think alogn the path of the wrong boot > console. I've removed /boot/loader.conf, and double-checked that > /boot.config isn't present - didn't help. > > My question is therefore, what cause of this effect might be? Or, if noone > would be able to answer this, how I would print messages from kernel (I'd > recompile it for that purpose) to identify which device it picked up for > console IO -- and especially, how I print that either to a file, or > directly to /dev/console? look at /boot/loader.conf #boot_mute="-m" # -m: Mute the console to suppress all console input and output during the boot. From owner-freebsd-stable@FreeBSD.ORG Sun Nov 18 21:26:22 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A85416A418 for ; Sun, 18 Nov 2007 21:26:22 +0000 (UTC) (envelope-from utisoft@googlemail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by mx1.freebsd.org (Postfix) with ESMTP id 0D14113C47E for ; Sun, 18 Nov 2007 21:26:21 +0000 (UTC) (envelope-from utisoft@googlemail.com) Received: by py-out-1112.google.com with SMTP id u77so5662390pyb for ; Sun, 18 Nov 2007 13:26:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=AtESGAThj7Gc9eS8JGDD29zNSenzC+crnBxTSdK4yfI=; b=dgw4pm/37amqhKDebZFC8eU2wTQgGFNQ2H8vgU68RM8uj+icfHDDojCmTHkhc+AFPjYqNlNAzKhPFuVBLcIKNQP+l/RGugyVido5XwcqWJDX/YbLylxymSJtLpse3zq4Vr/X1cQK0+BBKrY0vAOOvJLZjPK0gV5wy+PlWqnpjo4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=smXzbNx+u7rizl6UR4xbjkRUgyOHTEBBT2kQYZoUSJr2DNw4YAZUFrw9y3Lt8DBGUNhCX4Yr1YLluesAAMKyEGDcY/DIqDT9sh+k3ICurtwE3moY38Z0YPi6ctDcPbo5TiyGSwSvbnp6D/0GjBcYnpD7tXdYRStqGAKuasar4ng= Received: by 10.65.124.8 with SMTP id b8mr9655720qbn.1195419613214; Sun, 18 Nov 2007 13:00:13 -0800 (PST) Received: by 10.65.112.3 with HTTP; Sun, 18 Nov 2007 13:00:13 -0800 (PST) Message-ID: Date: Sun, 18 Nov 2007 21:00:13 +0000 From: "Chris Rees" To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: RELENG_6 IPFilter MFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: utisoft@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2007 21:26:22 -0000 > Subject: RELENG_6 IPFilter MFC > To: freebsd-stable@freebsd.org > Message-ID: <47401CA1.8000302@freebsd.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > I've just completed an MFC of IPFIilter in the FreeBSD 6 branch (RELENG_6) > from HEAD. This brings the code used for IPFilter in FreeBSD into sync on > each of HEAD, RELENG_6 and RELENG_7. Hopefully I can close one or > two bug reports now ;) > > If you encounter any problems, please let me know. > > Cheers, > Darren It broke make buildworld! csup'd to RELENG_6 make buildworld .... ===> sbin/ipf/libipf (depend) make: don't know how to make extras.c. Stop *** Error code 2 Stop in /src/sbin/ipf. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 -- One of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C Programs. (Robert Firth) R< $&h ! > $- ! $+ $@ $2 < @ $1 .UUCP. > (sendmail.cf) From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 03:46:11 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75E1516A41A for ; Mon, 19 Nov 2007 03:46:11 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id F378513C45B for ; Mon, 19 Nov 2007 03:46:10 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id lAJ3jtMT041238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Nov 2007 14:15:55 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: John Merryweather Cooper Date: Mon, 19 Nov 2007 14:15:51 +1030 User-Agent: KMail/1.9.7 References: <192440147.20071026152939@opanki.ru> <200711101035.33077.doconnor@gsoft.com.au> <4735304B.70201@yahoo.com> In-Reply-To: <4735304B.70201@yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2265737.fiZzlXGti7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200711191415.52302.doconnor@gsoft.com.au> X-Spam-Score: -3.977 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.58 on 203.31.81.10 Cc: Torfinn Ingolfsen , freebsd-stable@freebsd.org Subject: Re: loader on Dell INSPIRON 1501: BTX halted X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 03:46:11 -0000 --nextPart2265737.fiZzlXGti7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sat, 10 Nov 2007, John Merryweather Cooper wrote: > > I should be getting another system like it soon so I can test it > > again, hopefully I'll get time to add some 'go slow' routines to > > the stack trace so I can actually record it :) > > btx_crx.patch doesn't apply cleanly to btx.S in FreeBSD 7.0-BETA2 Hmm I think I applied it manually.. ISTR it wasn't too difficult. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart2265737.fiZzlXGti7 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHQQbw5ZPcIHs/zowRAvOXAKCFNqW6zpLO0pC1buBIY+ClxM1bNgCffJH0 EPxnOSjedwJpNAOIZJ2DBxM= =s30h -----END PGP SIGNATURE----- --nextPart2265737.fiZzlXGti7-- From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 07:51:26 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAE6F16A468 for ; Mon, 19 Nov 2007 07:51:26 +0000 (UTC) (envelope-from mse_software@charter.net) Received: from que02.charter.net (que02.charter.net [209.225.8.190]) by mx1.freebsd.org (Postfix) with ESMTP id 554CB13C46E for ; Mon, 19 Nov 2007 07:51:25 +0000 (UTC) (envelope-from mse_software@charter.net) Received: from aarprv04.charter.net ([10.20.200.74]) by mtai05.charter.net (InterMail vM.7.08.02.00 201-2186-121-20061213) with ESMTP id <20071119031303.UBYX12551.mtai05.charter.net@aarprv04.charter.net> for ; Sun, 18 Nov 2007 22:13:03 -0500 Received: from mselbep117p6dw ([71.83.252.214]) by aarprv04.charter.net with ESMTP id <20071119031302.SRVL17353.aarprv04.charter.net@mselbep117p6dw> for ; Sun, 18 Nov 2007 22:13:02 -0500 From: "Michael Eubanks" To: Date: Sun, 18 Nov 2007 19:12:26 -0800 Message-ID: <000001c82a5a$03828dd0$670aa8c0@mselbep117p6dw> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcgqWgMGu3KyHpt8R2mYSliKIEhXYg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Chzlrs: 0 Subject: problem compiling RELENG_6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 07:51:26 -0000 I've CVSup'd my RELENG_6 source and tried a make buildworld. Compilation breaks with the following error: ===> sbin/ipf/libipf (depend) make: don't know how to make extras.c. Stop *** Error code 2 I noticed there was another post with this same problem at http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2007-11/msg00203.htm l, although, I'm curious if there is a fix? Thank you, Michael Eubanks From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 08:10:02 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9599A16A46C for ; Mon, 19 Nov 2007 08:10:02 +0000 (UTC) (envelope-from ota@animenfo.com) Received: from smtp.unitz.ca (mx1.unitz.ca [69.60.224.6]) by mx1.freebsd.org (Postfix) with ESMTP id 67F2C13C458 for ; Mon, 19 Nov 2007 08:10:02 +0000 (UTC) (envelope-from ota@animenfo.com) Received: from localhost (localhost [127.0.0.1]) by smtp.unitz.ca (Postfix) with ESMTP id 5A4D86FAC29 for ; Mon, 19 Nov 2007 03:07:26 -0500 (EST) Received: from smtp.unitz.ca ([127.0.0.1]) by localhost (smtp.unitz.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrnRfseuBAkL for ; Mon, 19 Nov 2007 03:07:23 -0500 (EST) Received: from [192.168.0.10] (dsl-69-60-252-220.unitz.ca [69.60.252.220]) by smtp.unitz.ca (Postfix) with ESMTP id DE76E6FAC1D for ; Mon, 19 Nov 2007 03:07:22 -0500 (EST) Message-ID: <47414526.5090904@animenfo.com> Date: Mon, 19 Nov 2007 03:11:18 -0500 From: ota@animenfo.com User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: 6.2-RELEASE buildworld failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 08:10:02 -0000 Hi, I just csup'd the sources a few hours ago, and successfully compiled and installed a new kernel. However, when I go to do a buildworld, this comes up: -------------------------------------------------------------- >>> stage 2.3: build tools -------------------------------------------------------------- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/sbin:/bin:/usr/sbin:/usr/bin WORLDTMP=/usr/obj/usr/src/tmp MAKEFLAGS="-m /usr/src/tools/build/mk -m /usr/src/share/mk" make -f Makefile.inc1 TARGET=i386 TARGET_ARCH=i386 DESTDIR= BOOTSTRAPPING=602114 -DNO_LINT -DNO_CPU_CFLAGS -DNO_WARNS build-tools ===> bin/csh (obj,build-tools) grep 'ERR_' /usr/src/bin/csh/../../contrib/tcsh/sh.err.c | grep '^#define' >> sh.err.h cc -E -O2 -fno-strict-aliasing -pipe -I. -I/usr/src/bin/csh -I/usr/src/bin/csh/../../contrib/tcsh -D_PATH_TCSHELL='"/bin/csh"' -DHAVE_ICONV -I/usr/obj/usr/src/tmp/legacy/usr/include /usr/src/bin/csh/../../contrib/tcsh/tc.const.c /usr/src/bin/csh/../../contrib/tcsh/sh.char.h /usr/src/bin/csh/config.h /usr/src/bin/csh/../../contrib/tcsh/config_f.h /usr/src/bin/csh/../../contrib/tcsh/sh.types.h sh.err.h -D_h_tc_const | grep 'Char STR' | sed -e 's/Char \([a-zA-Z0-9_]*\)\(.*\)/extern Char \1[];/' | sort >> tc.const.h cc -o gethost -L/usr/obj/usr/src/tmp/legacy/usr/lib -O2 -fno-strict-aliasing -pipe -I. -I/usr/src/bin/csh -I/usr/src/bin/csh/../../contrib/tcsh -D_PATH_TCSHELL='"/bin/csh"' -DHAVE_ICONV -I/usr/obj/usr/src/tmp/legacy/usr/include /usr/src/bin/csh/../../contrib/tcsh/gethost.c /var/tmp//cck5eSfw.o(.text+0x25): In function `gettoken': : undefined reference to `__sbmaskrune' /var/tmp//cck5eSfw.o(.text+0x60): In function `gettoken': : undefined reference to `__sbmaskrune' *** Error code 1 Stop in /usr/src/bin/csh. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Any ideas? Russell Doucette From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 08:24:19 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA63216A41B for ; Mon, 19 Nov 2007 08:24:19 +0000 (UTC) (envelope-from dk@tetsuo.karasik.eu.org) Received: from tetsuo.karasik.eu.org (tetsuo.karasik.eu.org [129.142.67.14]) by mx1.freebsd.org (Postfix) with ESMTP id 7D6DB13C44B for ; Mon, 19 Nov 2007 08:24:19 +0000 (UTC) (envelope-from dk@tetsuo.karasik.eu.org) Received: by tetsuo.karasik.eu.org (Postfix, from userid 1003) id AA398616A60; Mon, 19 Nov 2007 09:24:01 +0100 (CET) Mime-version: 1.0 Content-type: text/plain; charset="koi8-r" Content-transfer-encoding: 8bit Keywords: 2001334874 X-Comment-To: Jeremy Chadwick Sender: dk@tetsuo.karasik.eu.org To: freebsd-stable@freebsd.org References: <20071118190159.GA12962@tetsuo.karasik.eu.org> <20071118193719.GB11901@eos.sc1.parodius.com> From: Dmitry Karasik In-Reply-To: Jeremy Chadwick's message of "Sun, 18 Nov 2007 11:37:19 -0800" Date: 19 Nov 2007 09:24:01 +0100 Message-ID: <84mytatzha.fsf@tetsuo.karasik.eu.org> Lines: 36 X-Mailer: Gnus v5.7/Emacs 20.7 Subject: Re: No kernel messages displayed during boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 08:24:19 -0000 Jeremy> On Sun, Nov 18, 2007 at 08:01:59PM +0100, Dmitry Karasik wrote: >> I've re-run 'make installworld' and 'make installkernel' (as I had >> leftovers from recent buildworld), - didn't help. I've tried to power >> down the machine (suspecied video card trouble), I've resetted BIOS, >> I've even disabled com port in BIOS (because the behavior looks like >> booting on serial console) -- nothing, absolutely nothing changes it. Jeremy> conscontrol(8) might help here ("conscontrol list"). Also worth Jeremy> looking at is sysctl kern.console. Hello Jeremy, Thanks, at least this is a hint. That shows on my system: $ conscontrol list Configured: Available: Muting: off and sysctl kern.console is / (not that I know what that means). Then I try this: $ conscontrol add /dev/console conscontrol: could not add console as a console: Device not configured $ conscontrol add /dev/consolectl conscontrol: could not add consolectl as a console: Device not configured Is that the expected behavior? What else I might try? -- Sincerely, Dmitry Karasik From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 08:26:03 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADDE616A417 for ; Mon, 19 Nov 2007 08:26:03 +0000 (UTC) (envelope-from dk@tetsuo.karasik.eu.org) Received: from tetsuo.karasik.eu.org (tetsuo.karasik.eu.org [129.142.67.14]) by mx1.freebsd.org (Postfix) with ESMTP id 6D6C513C4C4 for ; Mon, 19 Nov 2007 08:26:03 +0000 (UTC) (envelope-from dk@tetsuo.karasik.eu.org) Received: by tetsuo.karasik.eu.org (Postfix, from userid 1003) id C64CC616A60; Mon, 19 Nov 2007 09:25:56 +0100 (CET) Mime-version: 1.0 Content-type: text/plain; charset="koi8-r" Content-transfer-encoding: 8bit Keywords: 2001334874 X-Comment-To: AngryWolf Sender: dk@tetsuo.karasik.eu.org To: freebsd-stable@freebsd.org References: <20071118190159.GA12962@tetsuo.karasik.eu.org> <200711182047.16811.angrywolf@flashmail.com> From: Dmitry Karasik In-Reply-To: AngryWolf's message of "Sun, 18 Nov 2007 20:47:16 +0100" Date: 19 Nov 2007 09:25:56 +0100 Message-ID: <84ir3ytze3.fsf@tetsuo.karasik.eu.org> Lines: 16 X-Mailer: Gnus v5.7/Emacs 20.7 Subject: Re: No kernel messages displayed during boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 08:26:03 -0000 Hi AngryWolf! AngryWolf> Hi, I had the exact same problem after I upgraded to 7.0-BETA2, AngryWolf> and the problem seemed to be that I forgot to `make delete-old' AngryWolf> and `make delete-old-libs'. Thanks, I've run these, 'make delete-old' deleted some insignificant man pages and 'make delete-old-libs' deleted nothing. And the behavior didn't change . Did you notice, btw, what libs your 'make delete-old-libs' did remove? -- Sincerely, Dmitry Karasik From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 08:43:46 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86A7C16A469; Mon, 19 Nov 2007 08:43:46 +0000 (UTC) (envelope-from peo@intersonic.se) Received: from neonpark.inter-sonic.com (neonpark.inter-sonic.com [212.247.8.98]) by mx1.freebsd.org (Postfix) with ESMTP id 4963713C4AC; Mon, 19 Nov 2007 08:43:46 +0000 (UTC) (envelope-from peo@intersonic.se) X-Virus-Scanned: amavisd-new at inter-sonic.com Message-ID: <47414CB3.7060104@intersonic.se> Date: Mon, 19 Nov 2007 09:43:31 +0100 From: Per olof Ljungmark User-Agent: Thunderbird 2.0.0.6 (X11/20070827) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current Subject: panic: rtfree - any work done currently on this? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 08:43:46 -0000 Hi, I wonder if any work is done on http://www.freebsd.org/cgi/query-pr.cgi?pr=117913 if it is I'll be happy to test patches and/or suggestions or provide access to a box for debugging. Thanks, --per rtfree: 0xc5732d20 has 1 refs ssppiinn lloocckk 00xxcc5500ff22a20800 ((ttuurrnnssttiillee lloocckk)) hheelldd bbyy 00xxcc55111197868600 ((ttiidd 110000002154)) ttoooo lloonngg panic: spin lock held too long cpuid = 1 KDB: enter: panic [thread pid 16 tid 100014 ] Stopped at kdb_enter+0x32: leave db> wh Tracing pid 16 tid 100014 td 0xc5117660 kdb_enter(c0a9c7e0,1,c0a9b6b4,e3cb7b7c,1,...) at kdb_enter+0x32 panic(c0a9b6b4,c5119880,c0aa0958,c5119880,186b9,...) at panic+0x124 _mtx_lock_spin_failed(1,19,c0aa0984,cb,19,...) at _mtx_lock_spin_failed+0x51 _thread_lock_flags(c5119880,10,c0aa0984,cb,1,...) at _thread_lock_flags+0xc7 propagate_priority(c0bbd470,0,c0aa0984,2e2,c50f2c80,...) at propagate_priority+0xe0 turnstile_wait(c50f2c80,c55c4cc0,0,17a,c5867d08,...) at turnstile_wait+0x48c _mtx_lock_sleep(c5867d08,c5117660,0,c0ab2afe,1b6,...) at _mtx_lock_sleep+0x15a _mtx_lock_flags(c5867d08,0,c0ab2afe,1b6,3d2a1,...) at _mtx_lock_flags+0xef tcp_timer_rexmt(c58698ac,0,c0a9d9f9,ef,12,...) at tcp_timer_rexmt+0x96 softclock(0,0,c0a993e9,471,c515e364,...) at softclock+0x266 ithread_loop(c5113290,e3cb7d38,c0a9915d,2ea,c515f550,...) at ithread_loop+0x1b5 fork_exit(c0732ea0,c5113290,e3cb7d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe3cb7d70, ebp = 0 --- db> From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 09:36:53 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5403716A46E for ; Mon, 19 Nov 2007 09:36:53 +0000 (UTC) (envelope-from angrywolf@flashmail.com) Received: from b.relay.invitel.net (b.relay.invitel.net [62.77.203.4]) by mx1.freebsd.org (Postfix) with ESMTP id 108E913C468 for ; Mon, 19 Nov 2007 09:36:52 +0000 (UTC) (envelope-from angrywolf@flashmail.com) Received: from mail.invitel.hu (mail.vnet.hu [213.163.59.4]) by b.relay.invitel.net (Invitel Core SMTP Transmitter) with ESMTP id C0ED9388E3A for ; Mon, 19 Nov 2007 10:36:42 +0100 (CET) Received: from 555555.no-ip.org ([87.97.27.183]) by mail.invitel.hu (Invitel Messaging Server) with ESMTPA id <0JRQ00K8RYP520F0@invitel.hu> for freebsd-stable@freebsd.org; Mon, 19 Nov 2007 10:36:42 +0100 (CET) Received: by 555555.no-ip.org (Postfix, from userid 8) id 84C788FCAD; Mon, 19 Nov 2007 10:36:40 +0100 (CET) Received: from gep7.555555.no-ip.org (gep7 [172.16.0.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by 555555.no-ip.org (Postfix) with ESMTP id 7F7758FCAD for ; Mon, 19 Nov 2007 10:36:12 +0100 (CET) Date: Mon, 19 Nov 2007 10:36:04 +0100 From: AngryWolf In-reply-to: <84ir3ytze3.fsf@tetsuo.karasik.eu.org> To: freebsd-stable@freebsd.org Message-id: <200711191036.04673.angrywolf@flashmail.com> MIME-version: 1.0 Content-type: text/plain; charset=koi8-r Content-transfer-encoding: 7BIT Content-disposition: inline References: <20071118190159.GA12962@tetsuo.karasik.eu.org> <200711182047.16811.angrywolf@flashmail.com> <84ir3ytze3.fsf@tetsuo.karasik.eu.org> User-Agent: KMail/1.9.7 Subject: Re: No kernel messages displayed during boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 09:36:53 -0000 Hi Dmitry, Sorry then, probably my guess was wrong, but there's still a chance that it was actually rerunning 'mergemaster' that fixed my system. :) As I did a major upgrade, 'make delete-old-libs' did a lot of work for me (too much to memorize). -- AngryWolf angrywolf@flashmail.com On Monday 19 November 2007 09.25.56 Dmitry Karasik wrote: > Hi AngryWolf! > > AngryWolf> Hi, I had the exact same problem after I upgraded to 7.0-BETA2, > AngryWolf> and the problem seemed to be that I forgot to `make delete-old' > AngryWolf> and `make delete-old-libs'. > > Thanks, I've run these, 'make delete-old' deleted some insignificant man > pages and 'make delete-old-libs' deleted nothing. And the behavior didn't > change . > > Did you notice, btw, what libs your 'make delete-old-libs' did remove? From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 12:11:58 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 383EC16A417; Mon, 19 Nov 2007 12:11:58 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 8E5B913C46B; Mon, 19 Nov 2007 12:11:57 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: by blah.sun-fish.com (Postfix, from userid 1002) id 8521E1B10F0F; Mon, 19 Nov 2007 13:11:45 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on blah.cmotd.com X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 Received: from hater.haters.org (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id 8B8311B10F09; Mon, 19 Nov 2007 13:11:42 +0100 (CET) Message-ID: <47417D7E.5010603@moneybookers.com> Date: Mon, 19 Nov 2007 14:11:42 +0200 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.6 (X11/20071105) MIME-Version: 1.0 To: Ivan Voras References: <47414CB3.7060104@intersonic.se> In-Reply-To: Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4841/Mon Nov 19 05:25:36 2007 on blah.cmotd.com X-Virus-Status: Clean Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: panic: rtfree - any work done currently on this? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 12:11:58 -0000 Hi, Ivan Voras wrote: > Per olof Ljungmark wrote: > >> Hi, >> >> I wonder if any work is done on >> http://www.freebsd.org/cgi/query-pr.cgi?pr=117913 >> if it is I'll be happy to test patches and/or suggestions or provide >> access to a box for debugging. >> > > Last I've heard about it is that a fix was committed to 7-CURRENT. > This is different issue (or at least on different place) as the one that was discussed before 5-6 months. > _______________________________________________ > 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" > -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 12:56:23 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED26416A418; Mon, 19 Nov 2007 12:56:22 +0000 (UTC) (envelope-from peo@intersonic.se) Received: from neonpark.inter-sonic.com (neonpark.inter-sonic.com [212.247.8.98]) by mx1.freebsd.org (Postfix) with ESMTP id 940F113C48E; Mon, 19 Nov 2007 12:56:22 +0000 (UTC) (envelope-from peo@intersonic.se) X-Virus-Scanned: amavisd-new at inter-sonic.com Message-ID: <474187E5.6020203@intersonic.se> Date: Mon, 19 Nov 2007 13:56:05 +0100 From: Per olof Ljungmark User-Agent: Thunderbird 2.0.0.6 (X11/20070827) MIME-Version: 1.0 To: Ivan Voras References: <47414CB3.7060104@intersonic.se> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: panic: rtfree - any work done currently on this? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 12:56:23 -0000 Ivan Voras wrote: > Per olof Ljungmark wrote: >> Hi, >> >> I wonder if any work is done on >> http://www.freebsd.org/cgi/query-pr.cgi?pr=117913 >> if it is I'll be happy to test patches and/or suggestions or provide >> access to a box for debugging. > > Last I've heard about it is that a fix was committed to 7-CURRENT. Then I think something else was fixed - the issues we see still exists as of yesterday's sources. Thanks, From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 13:06:41 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F306716A419 for ; Mon, 19 Nov 2007 13:06:41 +0000 (UTC) (envelope-from toomas.aas@raad.tartu.ee) Received: from kuller.raad.tartu.ee (kuller.raad.tartu.ee [194.126.106.100]) by mx1.freebsd.org (Postfix) with ESMTP id B4B2F13C51D for ; Mon, 19 Nov 2007 13:06:41 +0000 (UTC) (envelope-from toomas.aas@raad.tartu.ee) Received: from localhost (localhost [127.0.0.1]) by kuller.raad.tartu.ee (Postfix) with ESMTP id 8BB10B814 for ; Mon, 19 Nov 2007 14:36:36 +0200 (EET) X-Virus-Scanned: amavisd-new at post.raad.tartu.ee Received: from kuller.raad.tartu.ee ([127.0.0.1]) by localhost (kuller.raad.tartu.ee [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuqWFBW31AN0 for ; Mon, 19 Nov 2007 14:36:34 +0200 (EET) Received: from raad.tartu.ee (lv.raad.tartu.ee [194.126.106.110]) by kuller.raad.tartu.ee (Postfix) with ESMTP id D1554BA3D for ; Mon, 19 Nov 2007 14:36:33 +0200 (EET) Received: from INFO/SpoolDir by raad.tartu.ee (Mercury 1.48); 19 Nov 07 14:36:33 +0200 Received: from SpoolDir by INFO (Mercury 1.48); 19 Nov 07 14:36:20 +0200 Received: from [172.26.1.6] (172.26.1.6) by raad.tartu.ee (Mercury 1.48) with ESMTP; 19 Nov 07 14:36:15 +0200 Message-ID: <474577B9.7090104@raad.tartu.ee> Date: Thu, 22 Nov 2007 14:36:09 +0200 From: Toomas Aas User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: garbled gjournal messages in dmesg with 7.0-BETA3 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 13:06:42 -0000 Hello! I have an IBM System x3400 machine with IBM ServeRAID 8k controller. There are three RAID1 volumes on the controller, which the OS sees as aacd0, aacd1 and aacd2. aacd1 contains three slices, aacd1s1 is simple UFS2, aacd1s2 and aacd1s3 are using UFS2 with gjournal. When I was using RELENG_7 from 20071112, there were following messages during booting regarding the gjournal: kernel: GEOM_JOURNAL: Journal 161627211: aacd1s2 contains data. kernel: GEOM_JOURNAL: Journal 161627211: aacd1s2 contains journal. kernel: GEOM_JOURNAL: Journal aacd1s2 clean. kernel: GEOM_JOURNAL: Journal 3372893522: aacd1s3 contains data. kernel: GEOM_JOURNAL: Journal 3372893522: aacd1s3 contains journal. kernel: GEOM_JOURNAL: Journal aacd1s3 clean. kernel: GEOM_JOURNAL: BIO_FLUSH not supported by aacd1s2. kernel: GEOM_JOURNAL: BIO_FLUSH not supported by aacd1s3. kernel: WARNING: Expected rawoffset 0, found 514080 kernel: WARNING: Expected rawoffset 0, found 42443730 Now I updated RELENG_7 today (20071119), and upon rebooting there are some garbled messages: kernel: GEOM_JOURNAL: Journal 161627211: aacd1s2 contains data. kernel: GEOM_JOURNAL: Journal 161627211: aacd1s2 contains journal. kernel: GEOM_JOURNAL: Journal aacd1s2 clean. kernel: GEOM_JOURNAL: Journal 3372893522: aacd1s3G EcOoMn_tJaOiUnRsN AdLa:t aB.IO kernel: _GFELOUMS_HJ OnUoRtN AsLu:p pJoorutrenda lb y 3a3a7c2d819s325.22 kernel: : aacd1s3 contains journal. kernel: GEOM_JOURNAL: Journal aacd1s3 clean. kernel: GEOM_JOURNAL: BIO_FLUSH not supported by aacd1s3. kernel: WARNING: Expected rawoffset 0, found 514080 kernel: WARNING: Expected rawoffset 0, found 42443730 The filesystem on aacd1s3.journal was mounted successfully and files seem to be intact, (but I haven't really verified all the files). This doesn't happen on every reboot, but it did happen on 2 tries out of 10. Before today's updating of RELENG_7 the machine had been rebooted 14 times and the problem had never happened. Has anyone else seen something like this? What more can I do to maybe get some useful information for developers? -- Toomas Aas From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 13:09:23 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7B1C16A473 for ; Mon, 19 Nov 2007 13:09:23 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.184]) by mx1.freebsd.org (Postfix) with ESMTP id 8061613C47E for ; Mon, 19 Nov 2007 13:09:22 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so1472838rvb for ; Mon, 19 Nov 2007 05:09:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=NS5rTUWJPVcVodzOLYhLOkep9kIBOdYIEpOGoYfhxII=; b=AO1lL+3TwaCiMQZTdgOUhQrywj1+a+5m0X+BQuGvSw0+MBqOuXOqhFWp2lbQowFbAEyk6Z/lytDagknvxWiDriEAciIiP51+7vZeNdiR2MkZ7JACDWvOOFIof70Zqj4uj8gIjsEXEuPRN6/Q0Xaeypl5g0VozrHxvMucCLT17+8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ONE8xM/x/rTWTgBX1ePecQ0zZOd2poqoZl+sJslOeEhz2dHlOfGoa/5pPqeMbYdAOX1ByL+C4jYShIt2CeU6zovS9eIAQ89LHoPvP5rS8PLnnx6XvTpv//58ce+3F+Lo5qznMx+QgERtp9kZvuuSwGWz4N+LSPPXuauqCDihxio= Received: by 10.140.82.2 with SMTP id f2mr1646891rvb.1195477753799; Mon, 19 Nov 2007 05:09:13 -0800 (PST) Received: by 10.141.211.5 with HTTP; Mon, 19 Nov 2007 05:09:13 -0800 (PST) Message-ID: <9bbcef730711190509h5b639472rfcc60213d9331cb5@mail.gmail.com> Date: Mon, 19 Nov 2007 14:09:13 +0100 From: "Ivan Voras" Sender: ivoras@gmail.com To: "Stefan Lambrev" In-Reply-To: <47417D7E.5010603@moneybookers.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47414CB3.7060104@intersonic.se> <47417D7E.5010603@moneybookers.com> X-Google-Sender-Auth: d4edd92d04f626d2 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: panic: rtfree - any work done currently on this? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 13:09:23 -0000 On 19/11/2007, Stefan Lambrev wrote: > Hi, > > Ivan Voras wrote: > > Per olof Ljungmark wrote: > > > >> Hi, > >> > >> I wonder if any work is done on > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=117913 > >> if it is I'll be happy to test patches and/or suggestions or provide > >> access to a box for debugging. > >> > > > > Last I've heard about it is that a fix was committed to 7-CURRENT. > > > This is different issue (or at least on different place) as the one that > was discussed before 5-6 months. You are correct, I was triggered too soon. From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 13:32:47 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 774DF16A41A for ; Mon, 19 Nov 2007 13:32:47 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from hermes.hw.ru (hermes.hw.ru [80.68.240.91]) by mx1.freebsd.org (Postfix) with ESMTP id 9C45D13C45A for ; Mon, 19 Nov 2007 13:32:45 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from [80.68.244.40] (account a_popov@rbc.ru [80.68.244.40] verified) by hermes.hw.ru (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 201255029 for freebsd-stable@freebsd.org; Mon, 19 Nov 2007 16:32:17 +0300 Message-ID: <4741905E.8050300@chistydom.ru> Date: Mon, 19 Nov 2007 16:32:14 +0300 From: Alexey Popov User-Agent: Thunderbird 2.0.0.6 (X11/20070924) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: multipart/mixed; boundary="------------060705080807060306020005" Subject: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 13:32:47 -0000 This is a multi-part message in MIME format. --------------060705080807060306020005 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Hi. I have a large pool of web backends (Apache + mod_php5) with 2 x Xeon 3.2GHz processors and 2 x Xeon 5120 dual-core processors. The workload is mostly CPU-bound. I'm using 6-STABLE-amd64 and also tried 7-STABLE. Now I'm trying to use new hardware with 2 x Xeon 5320 (quad-core), but it can not work under the same load as dual-core. It shows up to 80% system CPU load in top: last pid: 3850; load averages: 22.51, 19.75, 12.18 up 0+02:41:41 15:54:40 71 processes: 25 running, 46 sleeping CPU states: 9.5% user, 0.0% nice, 79.9% system, 1.2% interrupt, 9.5% idle Mem: 464M Active, 26M Inact, 75M Wired, 108K Cache, 51M Buf, 3323M Free Swap: 2048M Total, 2048M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 3729 www 1 118 0 99400K 50840K CPU4 1 1:55 23.24% httpd 3751 www 1 -4 0 96312K 46380K RUN 0 1:53 22.85% httpd 3732 www 1 118 0 96028K 47752K RUN 5 1:57 22.36% httpd 3744 www 1 -4 0 96036K 47756K RUN 7 1:54 22.27% httpd 3747 www 1 -4 0 96600K 48536K CPU5 1 1:53 22.07% httpd 3734 www 1 -4 0 96360K 46388K RUN 7 1:57 22.02% httpd 3758 www 1 -4 0 96004K 48208K CPU7 2 1:52 21.97% httpd 3763 www 1 -4 0 94824K 46800K RUN 1 1:55 21.88% httpd 3745 www 1 -4 0 97304K 47540K RUN 1 1:53 21.78% httpd 3750 www 1 -4 0 98672K 49920K RUN 0 1:54 21.73% httpd 3606 www 1 -4 0 96428K 48012K RUN 5 2:31 21.68% httpd 3762 www 1 -4 0 96008K 47332K CPU1 1 1:54 21.63% httpd 3757 www 1 -4 0 96368K 48020K RUN 0 1:53 21.48% httpd 3730 www 1 -4 0 96648K 48096K CPU7 5 1:57 21.44% httpd 3746 www 1 -4 0 96440K 48384K RUN 0 1:55 21.44% httpd 3756 www 1 -4 0 95972K 46984K RUN 1 1:55 21.44% httpd 3748 www 1 118 0 99756K 52056K select 6 1:55 21.39% httpd 3743 www 1 117 0 98432K 49984K select 6 1:52 21.34% httpd 3754 www 1 -4 0 98756K 50464K RUN 2 1:52 21.24% httpd 731 www 1 117 0 99232K 51028K select 4 2:37 21.14% httpd 3761 www 1 117 0 97384K 49136K RUN 0 1:53 21.14% httpd Here's the output from 2xdual-core backend running under the same load and with the same software: last pid: 52086; load averages: 3.84, 4.15, 4.11 up 42+01:14:01 16:06:10 45 processes: 8 running, 37 sleeping CPU states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0% idle Mem: 2264M Active, 704M Inact, 277M Wired, 181M Cache, 214M Buf, 384M Free Swap: 2048M Total, 1412K Used, 2046M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 52067 www 1 111 0 96476K 46868K CPU2 0 0:19 40.45% httpd 52069 www 1 110 0 99M 51464K CPU3 0 0:13 37.62% httpd 52064 www 1 4 0 97168K 47636K sbwait 2 0:18 35.27% httpd 52078 www 1 112 0 96348K 45752K RUN 1 0:04 34.13% httpd 52083 www 1 112 0 96892K 42384K RUN 0 0:02 32.37% httpd 52058 www 1 108 0 96156K 47228K CPU0 2 0:21 32.32% httpd 52071 www 1 108 0 99M 50528K RUN 0 0:09 31.80% httpd 52074 www 1 111 0 99M 51180K select 1 0:07 29.35% httpd 787 nobody 1 4 0 2079M 2077M kqread 1 20.7H 3.61% memcached 660 root 1 96 0 18120K 2108K select 0 25:17 0.00% snmpd 795 root 6 20 0 14652K 2992K kserel 0 13:28 0.00% bacula-fd I tried Linux and it works much better than old (2 x dual-core) backends. It handles 2 times more requests than FreeBSD on the old backends. So there's a real scalability problem in FreeBSD. The more processors it have the more CPU time it consumes. Also I faced the same problem moving heavily loaded MySQL-server to new hardware. That time I thought that the problem is in the mysql-server itself and I had to install Linux. See in attach: mutex statistics for quad-core system and dmesg and vmstat for dual- and quad-core systems. What can I do to make FreeBSD run faster on many-CPU systems??? With best regards, Alexey Popov --------------060705080807060306020005 Content-Type: text/plain; name="quad.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="quad.txt" Copyright (c) 1992-2007 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 6.3-PRERELEASE #0: Mon Nov 19 12:50:10 MSK 2007 llp@hydrogen.loadup.ru:/usr/obj/usr/src/sys/xxxSMP-amd64-HWPMC module_register: module accf_http already exists! Module accf_http failed to register: 17 module_register: module mfi_linux already exists! Module mfi_linux failed to register: 17 ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU E5320 @ 1.86GHz (1873.10-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6f7 Stepping = 7 Features=0xbfebfbff Features2=0x4e3bd AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 4 real memory = 5905580032 (5632 MB) avail memory = 4096229376 (3906 MB) FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs 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 lapic0: Forcing LINT1 to edge trigger kbd1 at kbdmux0 module_register_init: MOD_LOAD (accf_http, 0xffffffff8033a0e0, 0xffffffff807a9720) error 17 acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 cpu0: on acpi0 acpi_throttle0: on cpu0 cpu1: on acpi0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 cpu2: on acpi0 acpi_throttle2: on cpu2 acpi_throttle2: failed to attach P_CNT device_attach: acpi_throttle2 attach returned 6 cpu3: on acpi0 acpi_throttle3: on cpu3 acpi_throttle3: failed to attach P_CNT device_attach: acpi_throttle3 attach returned 6 cpu4: on acpi0 acpi_throttle4: on cpu4 acpi_throttle4: failed to attach P_CNT device_attach: acpi_throttle4 attach returned 6 cpu5: on acpi0 acpi_throttle5: on cpu5 acpi_throttle5: failed to attach P_CNT device_attach: acpi_throttle5 attach returned 6 cpu6: on acpi0 acpi_throttle6: on cpu6 acpi_throttle6: failed to attach P_CNT device_attach: acpi_throttle6 attach returned 6 cpu7: on acpi0 acpi_throttle7: on cpu7 acpi_throttle7: failed to attach P_CNT device_attach: acpi_throttle7 attach returned 6 acpi_button0: on acpi0 pcib0: port 0xca2,0xca3,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: irq 16 at device 1.0 on pci2 pci4: on pcib4 pcib5: irq 16 at device 2.0 on pci2 pci5: on pcib5 em0: port 0x2020-0x203f mem 0xb8820000-0xb883ffff,0xb8400000-0xb87fffff irq 18 at device 0.0 on pci5 em0: Ethernet address: 00:04:23:e1:30:ea em1: port 0x2000-0x201f mem 0xb8800000-0xb881ffff,0xb8000000-0xb83fffff irq 19 at device 0.1 on pci5 em1: Ethernet address: 00:04:23:e1:30:eb pcib6: at device 0.3 on pci1 pci6: on pcib6 pcib7: at device 3.0 on pci0 pci7: on pcib7 pcib8: at device 4.0 on pci0 pci8: on pcib8 pcib9: at device 5.0 on pci0 pci9: on pcib9 pcib10: at device 6.0 on pci0 pci10: on pcib10 pcib11: at device 0.0 on pci10 pci11: on pcib11 mfi0: mem 0xb8a00000-0xb8a0ffff,0xb8c00000-0xb8c1ffff irq 18 at device 14.0 on pci11 mfi0: Megaraid SAS driver Ver 2.00 mfi0: 280 (248793038s/0x0020/0) - Shutdown command received from host mfi0: 281 (4278190080s/0x0020/0) - PCI 0x041000 0x04411 0x041000 0x041004: Firmware initialization started (PCI ID 0411/1000/1004/1000) mfi0: 282 (4278190080s/0x0020/0) - Type 18: Firmware version 1.03.60-0255 mfi0: 283 (4278190118s/0x0008/0) - Battery temperature is normal mfi0: 284 (4278190118s/0x0008/0) - Battery Present mfi0: 285 (4278190156s/0x0002/0) - PD 08(e0/s8) event: Inserted: PD 08(e0/s8) mfi0: 286 (4278190156s/0x0002/0) - Type 29: Inserted: PD 08(e0/s8) Info: enclPd=ffff, scsiType=0, portMap=01, sasAddr=500000e016917972,0000000000000000 mfi0: 287 (4278190156s/0x0002/0) - PD 09(e0/s9) event: Inserted: PD 09(e0/s9) mfi0: 288 (4278190156s/0x0002/0) - Type 29: Inserted: PD 09(e0/s9) Info: enclPd=ffff, scsiType=0, portMap=02, sasAddr=500000e016916272,0000000000000000 mfi0: 289 (248793151s/0x0020/0) - Adapter ticks 248793151 elapsed 77s: Time established as 11/19/07 13:12:31; (77 seconds since power on) pcib12: at device 0.2 on pci10 pci12: on pcib12 pcib13: at device 7.0 on pci0 pci13: on pcib13 pci0: at device 8.0 (no driver attached) uhci0: port 0x3080-0x309f irq 23 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x3060-0x307f irq 22 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x3040-0x305f irq 23 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x3020-0x303f irq 22 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xb8d00400-0xb8d007ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered pcib14: at device 30.0 on pci0 pci14: on pcib14 pci14: at device 12.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30b0-0x30bf irq 20 at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 atapci1: port 0x30c8-0x30cf,0x30e4-0x30e7,0x30c0-0x30c7,0x30e0-0x30e3,0x30a0-0x30af mem 0xb8d00000-0xb8d003ff irq 20 at device 31.2 on pci0 ata2: on atapci1 ata3: on atapci1 pci0: at device 31.3 (no driver attached) sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] orm0: at iomem 0xc0000-0xc8fff,0xc9000-0xcdfff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec IP Filter: v4.1.28 initialized. Default = pass all, Logging = enabled ipfw2 initialized, divert enabled, rule-based forwarding disabled, default to accept, logging unlimited acd0: DVDR at ata0-slave UDMA33 mfid0: on mfi0 mfid0: 139236MB (285155328 sectors) RAID volume '' is optimal lapic2: Forcing LINT1 to edge trigger SMP: AP CPU #2 Launched! lapic1: Forcing LINT1 to edge trigger SMP: AP CPU #1 Launched! lapic3: Forcing LINT1 to edge trigger SMP: AP CPU #3 Launched! lapic4: Forcing LINT1 to edge trigger SMP: AP CPU #4 Launched! lapic7: Forcing LINT1 to edge trigger SMP: AP CPU #7 Launched! lapic5: Forcing LINT1 to edge trigger SMP: AP CPU #5 Launched! lapic6: Forcing LINT1 to edge trigger SMP: AP CPU #6 Launched! Trying to mount root from ufs:/dev/mfid0s1a em0: Hardware Initialization Failed em0: Unable to initialize the hardware em0: link state changed to UP 1 users Load 24.97 24.71 22.97 Nov 19 16:25 Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER Tot Share Tot Share Free in out in out Act 487264 19648 621692 33304 3400752 count All 535596 20936 5003244 37628 pages Proc: Interrupts r p d s w Csw Trp Sys Int Sof Flt cow 16839 total 27 1 39 137k 3390 33k 2490 313 2519 2519 zfod sio0 irq4 2519 ozfod ata0 irq14 78.0%Sys 1.1%Intr 13.1%User 0.0%Nice 7.8%Idle 100%ozfod 832 em0 mfi0 1 | | | | | | | | | | | daefr uhci0 uhci =======================================+>>>>>> prcfr 1999 cpu0: time 37 dtbuf 2979 totfr 2000 cpu2: time Namei Name-cache Dir-cache 100000 desvn react 2000 cpu1: time Calls hits % hits % 5491 numvn pdwak 2000 cpu3: time 51775 51775 100 3686 frevn pdpgs 2002 cpu4: time intrn 2002 cpu7: time Disks mfid0 80080 wire 2002 cpu5: time KB/t 0.00 472368 act 2002 cpu6: time tps 0 26720 inact MB/s 0.00 108 cache %busy 0 3400644 free 59296 buf debug.mutex.prof.stats: max total count avg cnt_hold cnt_lock name 14830 12696030 1840283 6 622811 981441 /usr/src/sys/kern/kern_lock.c:168 (lockbuilder mtxpool) 1152 67642 25424 2 0 0 /usr/src/sys/kern/kern_descrip.c:1962 (filedesc structure) 2343 1526816 557240 2 13043 481687 /usr/src/sys/kern/vfs_subr.c:1997 (vnode interlock) 1285 71570 25363 2 1 1 /usr/src/sys/kern/kern_descrip.c:1983 (sleep mtxpool) 328 7238962 2175947 3 6165708 7064072 /usr/src/sys/kern/kern_synch.c:220 (lockbuilder mtxpool) 1209 71686 25363 2 0 0 /usr/src/sys/kern/kern_descrip.c:1984 (filedesc structure) 1553 2069549 806581 2 555036 175103 /usr/src/sys/kern/kern_lock.c:532 (lockbuilder mtxpool) 14836 10286955 769265 13 36020 28870 /usr/src/sys/kern/vfs_subr.c:2119 (vnode interlock) 272 51743 23159 2 19 62 /usr/src/sys/kern/kern_conf.c:61 (cdev) 4189 8785941 350672 25 36714 13130 /usr/src/sys/kern/vfs_subr.c:2236 (vnode interlock) 11 100 28 3 0 2 /usr/src/sys/kern/tty.c:2093 (process lock) 3630 270809 103261 2 688 2045 /usr/src/sys/ufs/ufs/ufs_vnops.c:133 (vnode interlock) 243 22329 2023 11 48 9491 /usr/src/sys/kern/sys_generic.c:1147 (sellck) 2185 278665 102786 2 1002 450 /usr/src/sys/ufs/ufs/ufs_vnops.c:408 (vnode interlock) 200 2425 38 63 4 2750 /usr/src/sys/kern/kern_conf.c:329 (Giant) 353 326270 104708 3 3037 24148 /usr/src/sys/kern/vfs_mount.c:438 (struct mount mtx) 2529 228837 81898 2 0 3 /usr/src/sys/kern/kern_descrip.c:2112 (sleep mtxpool) 2307 1583215 257982 6 13461 23127 /usr/src/sys/kern/vfs_vnops.c:806 (vnode interlock) 24007 185216 346 535 161 23 /usr/src/sys/kern/kern_sysctl.c:1313 (Giant) 851 67462 24917 2 0 0 /usr/src/sys/kern/kern_descrip.c:1376 (filedesc structure) 1316 69326 24925 2 2 169 /usr/src/sys/kern/kern_descrip.c:1268 (process lock) 1420 77550 24917 3 0 0 /usr/src/sys/kern/kern_descrip.c:1391 (filedesc structure) 516 66280 24783 2 0 0 /usr/src/sys/kern/vfs_syscalls.c:1007 (filedesc structure) 11467 81199 24783 3 0 0 /usr/src/sys/kern/vfs_syscalls.c:1015 (filedesc structure) 5259 308813 107752 2 0 0 /usr/src/sys/kern/vfs_lookup.c:188 (filedesc structure) 599 2618267 455837 5 40555 177047 /usr/src/sys/kern/vfs_cache.c:356 (Name Cache) 1474 4246486 452087 9 9871 85861 /usr/src/sys/kern/vfs_cache.c:457 (vnode interlock) 2544 847434 317780 2 27777 152916 /usr/src/sys/kern/vfs_subr.c:2020 (vnode interlock) 1888 305492 107752 2 0 0 /usr/src/sys/kern/vfs_lookup.c:195 (filedesc structure) 437 277687 105799 2 11707 18106 /usr/src/sys/kern/vfs_subr.c:2060 (vnode interlock) 63 1325 150 8 14 3 /usr/src/sys/kern/kern_condvar.c:189 (sellck) 13 8322 2322 3 0 0 /usr/src/sys/kern/sys_generic.c:849 (filedesc structure) 451 9400 2670 3 26 39 /usr/src/sys/kern/sys_generic.c:1099 (sellck) 1146 41574 5704 7 62 169 /usr/src/sys/kern/uipc_socket.c:2049 (so_rcv) 1155 89277 5704 15 34 19 /usr/src/sys/kern/uipc_socket.c:2048 (so_snd) 5 27 8 3 0 0 /usr/src/sys/kern/kern_exit.c:139 (process lock) 11 31 8 3 0 0 /usr/src/sys/kern/kern_exit.c:212 (p_peers) 357 4300 493 8 0 46 /usr/src/sys/kern/sys_pipe.c:1345 (pipe mutex) 376 567533 104712 5 3856 3057 /usr/src/sys/kern/vfs_subr.c:343 (struct mount mtx) 8 103 16 6 0 0 /usr/src/sys/kern/subr_eventhandler.c:212 (eventhandler) 8 55 9 6 0 0 /usr/src/sys/kern/subr_eventhandler.c:215 (process_exit) 46 1333 121 11 5 9 /usr/src/sys/kern/kern_conf.c:341 (Giant) 4 23 8 2 0 0 /usr/src/sys/kern/sysv_sem.c:1268 (sem) 4 46 16 2 0 0 /usr/src/sys/kern/kern_exit.c:230 (process_exit) 216 8050 2322 3 0 0 /usr/src/sys/kern/sys_generic.c:872 (filedesc structure) 8 49 8 6 0 0 /usr/src/sys/fs/pseudofs/pseudofs_vncache.c:286 (pfs_vncache) 116 24710 2322 10 807 784 /usr/src/sys/kern/sys_generic.c:771 (sellck) 17 110 8 13 0 0 /usr/src/sys/fs/pseudofs/pseudofs_vncache.c:285 (Giant) 11973 107437 33819 3 0 0 /usr/src/sys/kern/kern_descrip.c:994 (filedesc structure) 2774 117520 37693 3 0 13 /usr/src/sys/kern/kern_sig.c:641 (process lock) 1819 3983950 104533 38 7818 38206 /usr/src/sys/kern/vfs_hash.c:71 (vfs hash) 2753 64202 22718 2 0 0 /usr/src/sys/kern/kern_descrip.c:1021 (filedesc structure) 5 25 8 3 0 0 /usr/src/sys/kern/kern_exit.c:238 (process lock) 5 24 8 3 0 0 /usr/src/sys/kern/kern_descrip.c:1639 (filedesc structure) 1035 4256701 104533 40 78201 60906 /usr/src/sys/kern/vfs_hash.c:79 (vnode interlock) 365 63008 22698 2 953 1293 /usr/src/sys/kern/vfs_mount.c:429 (struct mount mtx) 475 62166 22651 2 1384 496 /usr/src/sys/kern/vfs_vnops.c:902 (struct mount mtx) 5 22 8 2 0 0 /usr/src/sys/kern/kern_descrip.c:1653 (filedesc structure) 10 448 127 3 0 0 /usr/src/sys/kern/kern_event.c:1643 (tty) 833 60258 22565 2 1 8 /usr/src/sys/ufs/ufs/ufs_vnops.c:282 (vnode interlock) 912 1536 44 34 1 2 /usr/src/sys/kern/kern_conf.c:317 (Giant) 5 23 8 2 0 0 /usr/src/sys/kern/kern_descrip.c:1656 (fdesc) 5 23 8 2 0 0 /usr/src/sys/kern/kern_descrip.c:1673 (filedesc structure) 5 24 8 3 0 0 /usr/src/sys/kern/kern_descrip.c:1454 (fdesc) 371 58195 22651 2 875 1016 /usr/src/sys/kern/vfs_vnops.c:1045 (struct mount mtx) 192 7020 2283 3 0 0 /usr/src/sys/kern/sys_generic.c:698 (filedesc structure) 5 23 8 2 0 0 /usr/src/sys/kern/kern_exit.c:285 (p_peers) 502 20605 2283 9 1172 923 /usr/src/sys/kern/sys_generic.c:762 (sellck) 101 98352 10938 8 0 19 /usr/src/sys/dev/em/if_em.c:1464 (em0) 26 26048 7350 3 370 726 /usr/src/sys/net/if.c:2329 (ip_inq) 480 2053 9 228 0 0 /usr/src/sys/amd64/amd64/pmap.c:2748 (pmap) 94 44497 10927 4 148 658 /usr/src/sys/dev/em/if_em.c:1492 (em0) 488 2124 9 236 4 107126 /usr/src/sys/amd64/amd64/pmap.c:2747 (vm page queue mutex) 47 85817 7350 11 2 1 /usr/src/sys/dev/em/if_em.c:4546 (em0) 99 10733 828 12 0 5 /usr/src/sys/vm/vm_map.c:2297 (vm object) 25 41183 12051 3 282 384 /usr/src/sys/net/netisr.c:233 (ip_inq) 1138 57777 18145 3 0 0 /usr/src/sys/vm/vm_object.c:446 (vm object) 360 44497 13232 3 59 196 /usr/src/sys/net/pfil.c:63 (pfil_head_mtx) 297 42979 13232 3 33 154 /usr/src/sys/netinet/ip_fw2.c:156 (IPFW static rules) 1137 45016 13232 3 48 35 /usr/src/sys/netinet/ip_fw2.c:164 (IPFW static rules) 5 268 92 2 0 6 /usr/src/sys/vm/vm_object.c:572 (vm object) 122 730 135 5 2 3 /usr/src/sys/vm/vm_object.c:646 (vm page queue mutex) 183 42700 13228 3 0 0 /usr/src/sys/contrib/ipfilter/netinet/fil.c:2255 (ipf cache rwlock) 6 413 135 3 0 391 /usr/src/sys/vm/vm_object.c:669 (vm object_list) 173 23927 7835 3 0 0 /usr/src/sys/contrib/ipfilter/netinet/fil.c:2282 (ipf cache rwlock) 975 201344 13228 15 0 0 /usr/src/sys/contrib/ipfilter/netinet/fil.c:2562 (ipf filter rwlock) 982 307062 13228 23 639 954 /usr/src/sys/contrib/ipfilter/netinet/fil.c:2432 (ipf filter load/unload mutex) 62 7689 2507 3 0 37 /usr/src/sys/kern/uipc_socket.c:668 (so_snd) 36 42097 13232 3 43 60 /usr/src/sys/net/pfil.c:71 (pfil_head_mtx) 26 86698 27094 3 0 0 /usr/src/sys/netinet/ip_dummynet.c:743 (dummynet) 11 9540 3060 3 0 0 /usr/src/sys/kern/uipc_socket2.c:770 (so_snd) 94 6937 320 21 8 14 /usr/src/sys/vm/vm_object.c:1809 (vm page queue mutex) 760 41669 3060 13 38 1025 /usr/src/sys/netinet/tcp_usrreq.c:630 (tcp) 463 46791 13301 3 15 33 /usr/src/sys/netinet/tcp_output.c:253 (so_snd) 25 10126 2874 3 2 4 /usr/src/sys/netinet/tcp_input.c:2145 (so_snd) 1198 52186 7374 7 7 54 /usr/src/sys/net/route.c:147 (radix node head) 458 52801 7374 7 30 158 /usr/src/sys/net/route.c:197 (rtentry) 252 35852 2510 14 3 14 /usr/src/sys/netinet/tcp_input.c:2375 (so_rcv) 282 220788 6888 32 190 100 /usr/src/sys/netinet/tcp_input.c:625 (tcp) 545 453792 6888 65 701 672 /usr/src/sys/netinet/tcp_input.c:752 (inp) 96 39388 6315 6 35 30 /usr/src/sys/net/route.c:1265 (rtentry) 2461 49157 6315 7 1 4 /usr/src/sys/net/route.c:1281 (rtentry) 72 19734 6315 3 3 36 /usr/src/sys/net/if_ethersubr.c:409 (em0) 5 10 2 5 0 0 /usr/src/sys/kern/kern_proc.c:551 (process lock) 48 18573 6315 2 0 10 /usr/src/sys/dev/em/if_em.c:943 (em0) 19 46 4 11 0 0 /usr/src/sys/kern/kern_proc.c:473 (process group) 1896 73387 6618 11 586 454 /usr/src/sys/dev/em/if_em.c:974 (em0) 32 88 8 11 0 1 /usr/src/sys/kern/kern_exit.c:297 (Giant) 524 20223 6315 3 27 51 /usr/src/sys/netinet/ip_output.c:835 (rtentry) 2661 396213 3060 129 0 578 /usr/src/sys/netinet/tcp_usrreq.c:647 (inp) 5 23 8 2 0 0 /usr/src/sys/kern/kern_exit.c:365 (ktrace) 130 7625 2502 3 0 0 /usr/src/sys/kern/uipc_socket.c:864 (so_snd) 23 84 8 10 0 0 /usr/src/sys/kern/kern_exit.c:364 (process lock) 5 205 78 2 0 0 /usr/src/sys/kern/vfs_subr.c:2090 (vnode interlock) 5 177 60 2 1 0 /usr/src/sys/kern/vfs_vnops.c:1008 (struct mount mtx) 216 2641 374 7 0 3 /usr/src/sys/kern/vfs_bio.c:2387 (vnode interlock) 24 2411 373 6 4 1 /usr/src/sys/sys/buf.h:292 (lockbuilder mtxpool) 7 218 63 3 0 225 /usr/src/sys/ufs/ffs/ffs_softdep.c:4887 (Softdep Lock) 19 388 57 6 2 2 /usr/src/sys/kern/vfs_subr.c:1818 (vnode interlock) 6 497 162 3 0 3 /usr/src/sys/kern/vfs_bio.c:421 (buffer daemon lock) 10 583 183 3 2 6 /usr/src/sys/kern/vfs_bio.c:2259 (vm object) 8 535 145 3 2 3 /usr/src/sys/kern/vfs_bio.c:3403 (vm page queue mutex) 26 1546 145 10 0 0 /usr/src/sys/kern/vfs_bio.c:3402 (vm object) 476 1981 494 4 4 9 /usr/src/sys/kern/kern_lock.c:556 (lockbuilder mtxpool) 352 14144 3973 3 0 0 /usr/src/sys/kern/subr_sleepqueue.c:391 (sigacts) 50 3218 411 7 0 114 /usr/src/sys/kern/vfs_bio.c:1421 (buf queue lock) 450 68483 3973 17 5 10 /usr/src/sys/kern/subr_sleepqueue.c:389 (process lock) 5 182 60 3 0 0 /usr/src/sys/kern/vfs_vnops.c:1067 (struct mount mtx) 12 36 8 4 0 0 /usr/src/sys/kern/kern_exit.c:394 (process lock) 6 25 8 3 0 0 /usr/src/sys/kern/kern_resource.c:932 (sleep mtxpool) 5 30 8 3 0 0 /usr/src/sys/kern/kern_exit.c:468 (sigacts) 5 134 40 3 0 0 /usr/src/sys/kern/kern_sig.c:1719 (sigacts) 41 230 8 28 0 11 /usr/src/sys/kern/kern_exit.c:467 (process lock) 57 314 8 39 0 0 /usr/src/sys/kern/kern_exit.c:444 (process lock) 85 11508 2415 4 254 300 /usr/src/sys/netinet/tcp_input.c:1303 (so_rcv) 274 55363 22570 2 0 401 /usr/src/sys/vm/vnode_pager.c:131 (vm object) 211 60598 24777 2 0 0 /usr/src/sys/kern/vfs_syscalls.c:1017 (filedesc structure) 282 59815 24777 2 0 0 /usr/src/sys/kern/vfs_syscalls.c:1019 (filedesc structure) 250 55202 22576 2 1 23 /usr/src/sys/kern/vfs_syscalls.c:1062 (sleep mtxpool) 1323 189186 22576 8 0 0 /usr/src/sys/kern/vfs_syscalls.c:1061 (filedesc structure) 1451 61760 22836 2 0 10 /usr/src/sys/kern/kern_prot.c:92 (process lock) 1143 65390 23912 2 0 0 /usr/src/sys/kern/vfs_cache.c:720 (filedesc structure) 233 72388 23912 3 2150 3714 /usr/src/sys/kern/vfs_cache.c:801 (Name Cache) 1140 69010 23912 2 0 0 /usr/src/sys/kern/vfs_cache.c:723 (filedesc structure) 4278 609427 23912 25 755 595 /usr/src/sys/kern/vfs_cache.c:719 (Giant) 1016 34871 3676 9 1409 773 /usr/src/sys/kern/kern_condvar.c:301 (sellck) 705 18904 5013 3 0 0 /usr/src/sys/kern/sys_generic.c:1019 (filedesc structure) 1970 22990 5013 4 0 0 /usr/src/sys/kern/sys_generic.c:1043 (filedesc structure) 3820 68563 5013 13 67 93 /usr/src/sys/kern/sys_generic.c:951 (sellck) 17 255 31 8 0 0 /usr/src/sys/kern/subr_trap.c:268 (sigacts) 74 572 31 18 0 0 /usr/src/sys/kern/subr_trap.c:267 (process lock) 487 22678 6407 3 2 1 /usr/src/sys/kern/uipc_syscalls.c:128 (sleep mtxpool) 11 116 31 3 0 0 /usr/src/sys/amd64/amd64/machdep.c:335 (sigacts) 537 73109 6409 11 0 0 /usr/src/sys/kern/uipc_syscalls.c:120 (filedesc structure) 19 344 31 11 0 0 /usr/src/sys/amd64/amd64/machdep.c:334 (process lock) 309 16717 4650 3 107 77 /usr/src/sys/kern/uipc_socket.c:1018 (so_rcv) 119 6216 894 6 4 35 /usr/src/sys/kern/kern_exit.c:598 (process lock) 1318 26635 6040 4 77 139 /usr/src/sys/kern/uipc_socket.c:1265 (so_rcv) 2446 249683 8954 27 780 853 /usr/src/sys/netinet/tcp_usrreq.c:599 (tcp) 37 14088 4481 3 49 1 /usr/src/sys/kern/uipc_socket.c:1423 (so_rcv) 232 11614 3381 3 1 14 /usr/src/sys/kern/sys_generic.c:911 (process lock) 1469 31754 3381 9 19 26 /usr/src/sys/kern/sys_generic.c:942 (sellck) 11 46 8 5 0 0 /usr/src/sys/kern/kern_proc.c:423 (process lock) 17 110 8 13 0 0 /usr/src/sys/kern/kern_proc.c:422 (process group) 29 172 8 21 0 1 /usr/src/sys/kern/kern_proc.c:421 (Giant) 4 12 4 3 0 0 /usr/src/sys/kern/kern_proc.c:571 (session) 18 51 4 12 0 0 /usr/src/sys/kern/kern_proc.c:454 (process group) 29 88 4 22 0 0 /usr/src/sys/kern/kern_proc.c:453 (Giant) 5 25 8 3 0 0 /usr/src/sys/kern/kern_exit.c:680 (process lock) 5 25 8 3 0 0 /usr/src/sys/kern/kern_exit.c:683 (process lock) 5 32 14 2 0 41 /usr/src/sys/kern/kern_resource.c:1149 (sleep mtxpool) 12 64 17 3 0 0 /usr/src/sys/kern/kern_proc.c:1152 (struct pargs.ref) 12 121 31 3 0 0 /usr/src/sys/amd64/amd64/machdep.c:426 (process lock) 7 41 10 4 0 0 /usr/src/sys/kern/tty.c:850 (process lock) 5 15 4 3 0 0 /usr/src/sys/kern/kern_proc.c:260 (process group) 1173 1510 38 39 1 0 /usr/src/sys/kern/kern_conf.c:305 (Giant) 20 1260 388 3 0 0 /usr/src/sys/vm/uma_core.c:2349 (mbuf) 22 8389 2712 3 0 0 /usr/src/sys/nfsserver/nfs_srvsock.c:813 (nfsd_mtx) 24 8009 2712 2 13 41 /usr/src/sys/netinet/tcp_subr.c:1483 (tcp) 6 57 14 4 0 0 /usr/src/sys/kern/kern_time.c:581 (process lock) 64 1914 612 3 0 18 /usr/src/sys/vm/vm_unix.c:81 (process lock) 10 1028 343 2 0 6 /usr/src/sys/vm/vm_object.c:1874 (vm object) 11 549 199 2 0 0 /usr/src/sys/vm/vm_mmap.c:274 (process lock) 165 843 227 3 0 0 /usr/src/sys/vm/vm_mmap.c:1261 (process lock) 109 50814 16766 3 0 6 /usr/src/sys/amd64/amd64/trap.c:552 (process lock) 10 350 111 3 0 0 /usr/src/sys/vm/vm_object.c:229 (vm object_list) 140 50738 17036 2 269 295 /usr/src/sys/vm/vm_fault.c:854 (vm page queue mutex) 3163 202962 17181 11 0 3605 /usr/src/sys/vm/vm_fault.c:297 (vm object) 950 110673 17181 6 372 372 /usr/src/sys/amd64/amd64/pmap.c:2054 (vm page queue mutex) 957 122361 17181 7 0 0 /usr/src/sys/amd64/amd64/pmap.c:2055 (pmap) 1112 120548 39135 3 0 0 /usr/src/sys/amd64/amd64/pmap.c:2856 (pmap) 2069 90833 17789 5 0 0 /usr/src/sys/vm/vm_fault.c:989 (vm object) 793 53945 17181 3 215 211 /usr/src/sys/vm/vm_fault.c:912 (vm page queue mutex) 849 171876 17181 10 0 0 /usr/src/sys/vm/vm_fault.c:911 (vm object) 1439 55321 17181 3 1 2 /usr/src/sys/vm/vm_fault.c:934 (process lock) 1334 54611 16766 3 0 1 /usr/src/sys/amd64/amd64/trap.c:561 (process lock) 15 4925 830 5 2 14 /usr/src/sys/netinet/tcp_timer.c:139 (tcp) 256 103420 830 124 0 23 /usr/src/sys/netinet/tcp_timer.c:145 (inp) 91 11925 504 23 16 6 /usr/src/sys/amd64/amd64/pmap.c:1755 (vm page queue mutex) 92 12410 504 24 0 0 /usr/src/sys/amd64/amd64/pmap.c:1756 (pmap) 14 1353 370 3 0 4 /usr/src/sys/vm/uma_core.c:1888 (mbuf) 55 854 60 14 2 3 /usr/src/sys/netinet/tcp_input.c:373 (so_rcv) 105 13067 1649 7 41 43 /usr/src/sys/kern/kern_timeout.c:258 (Giant) 295 11605 3929 2 9 23 /usr/src/sys/kern/kern_resource.c:1075 (sleep mtxpool) 22 2541 873 2 0 17 /usr/src/sys/kern/vfs_subr.c:2941 (vnode_free_list) 91 2578 872 2 0 0 /usr/src/sys/kern/vfs_subr.c:2913 (vnode_free_list) 53 10898 3931 2 7 7 /usr/src/sys/kern/kern_resource.c:1101 (sleep mtxpool) 17 492 181 2 0 0 /usr/src/sys/kern/vfs_syscalls.c:787 (filedesc structure) 448 4343 894 4 0 0 /usr/src/sys/kern/kern_sig.c:297 (sigacts) 453 10221 894 11 0 0 /usr/src/sys/kern/kern_sig.c:295 (process lock) 245 7085 1081 6 29 2370 /usr/src/sys/geom/geom_io.c:67 (bio queue) 49 2184 56 39 0 0 /usr/src/sys/dev/random/yarrow.c:193 (random reseed) 13 1307 429 3 0 0 /usr/src/sys/vm/vm_object.c:357 (vm object) 8 202 60 3 0 0 /usr/src/sys/ufs/ffs/ffs_vnops.c:675 (process lock) 10 204 60 3 0 2 /usr/src/sys/vm/vnode_pager.c:382 (vm object) 62 912 120 7 0 0 /usr/src/sys/kern/kern_resource.c:855 (process lock) 5 171 63 2 0 0 /usr/src/sys/kern/uipc_socket2.c:324 (so_snd) 229 12029 128 93 2 1 /usr/src/sys/netinet/tcp_usrreq.c:580 (inp) 14 302 100 3 0 1 /usr/src/sys/kern/uipc_socket2.c:192 (so_rcv) 33 430 100 4 0 0 /usr/src/sys/kern/uipc_socket2.c:197 (so_snd) 5 119 41 2 0 0 /usr/src/sys/netinet/in_pcb.c:708 (so_rcv) 15 376 41 9 0 2 /usr/src/sys/netinet/in_pcb.c:707 (accept) 16 54 5 10 0 0 /usr/src/sys/kern/sys_socket.c:121 (process lock) 13 931 271 3 0 0 /usr/src/sys/geom/geom_event.c:185 (GEOM orphanage) 12 914 271 3 0 0 /usr/src/sys/geom/geom_event.c:199 (GEOM orphanage) 6 80 28 2 0 0 /usr/src/sys/net/if.c:1214 (ifnet) 11 154 55 2 0 0 /usr/src/sys/contrib/ipfilter/netinet/fil.c:6587 (ipf token rwlock) 12 153 55 2 0 0 /usr/src/sys/contrib/ipfilter/netinet/ip_frag.c:786 (ipf fragment rwlock) 5 158 55 2 0 0 /usr/src/sys/contrib/ipfilter/netinet/ip_frag.c:799 (ipf IP NAT-Frag rwlock) 6 245 55 4 0 0 /usr/src/sys/contrib/ipfilter/netinet/ip_state.c:3057 (ipf IP state rwlock) 6 217 55 3 0 0 /usr/src/sys/contrib/ipfilter/netinet/ip_nat.c:4464 (ipf IP NAT rwlock) 5 212 55 3 0 0 /usr/src/sys/contrib/ipfilter/netinet/ip_auth.c:563 (ipf IP User-Auth rwlock) 78 2626 55 47 0 1 /usr/src/sys/contrib/ipfilter/netinet/ip_frag.c:855 (ipf filter load/unload mutex) 61 471 142 3 0 0 /usr/src/sys/kern/kern_descrip.c:748 (sigio lock) 5 319 113 2 0 0 /usr/src/sys/kern/uipc_socket.c:488 (so_rcv) 61 1087 113 9 0 0 /usr/src/sys/kern/uipc_socket.c:487 (accept) 5 316 113 2 0 0 /usr/src/sys/kern/uipc_socket.c:400 (so_snd) 13 1656 610 2 2 0 /usr/src/sys/kern/kern_resource.c:1174 (sleep mtxpool) 89 1174 113 10 0 0 /usr/src/sys/kern/uipc_socket.c:409 (so_snd) 688 1042 123 8 0 0 /usr/src/sys/kern/uipc_socket.c:1477 (so_rcv) 13 369 123 3 0 0 /usr/src/sys/kern/uipc_socket.c:1486 (so_rcv) 21 1143 123 9 0 0 /usr/src/sys/kern/uipc_socket2.c:581 (so_rcv) 5 315 113 2 0 2 /usr/src/sys/kern/uipc_socket.c:253 (so_glabel) 10 324 113 2 0 0 /usr/src/sys/kern/uipc_socket.c:274 (so_glabel) 7 237 65 3 0 1 /usr/src/sys/kern/sys_pipe.c:591 (pipe mutex) 10 172 60 2 0 0 /usr/src/sys/kern/kern_descrip.c:2214 (sleep mtxpool) 20 1490 120 12 0 6 /usr/src/sys/kern/kern_descrip.c:2193 (Giant) 5 172 61 2 0 0 /usr/src/sys/kern/kern_descrip.c:2086 (so_rcv) 5 176 61 2 0 0 /usr/src/sys/kern/kern_descrip.c:2090 (filedesc structure) 11 179 61 2 0 0 /usr/src/sys/kern/uipc_syscalls.c:367 (so_rcv) 19 599 61 9 0 0 /usr/src/sys/kern/uipc_syscalls.c:334 (accept) 7 154 61 2 0 0 /usr/src/sys/kern/kern_descrip.c:951 (sigio lock) 5 160 61 2 0 0 /usr/src/sys/kern/uipc_syscalls.c:389 (sleep mtxpool) 11 762 277 2 0 0 /usr/src/sys/kern/sys_socket.c:144 (so_rcv) 11 777 279 2 0 0 /usr/src/sys/kern/sys_socket.c:170 (so_rcv) 6 777 279 2 0 0 /usr/src/sys/kern/sys_socket.c:173 (so_rcv) 46 841 279 3 0 0 /usr/src/sys/kern/sys_socket.c:176 (so_snd) 5 173 61 2 0 0 /usr/src/sys/kern/uipc_socket.c:524 (so_rcv) 13 350 61 5 1 2 /usr/src/sys/netinet/tcp_usrreq.c:466 (tcp) 15 384 61 6 0 0 /usr/src/sys/netinet/tcp_usrreq.c:472 (inp) 5 153 61 2 0 0 /usr/src/sys/kern/kern_descrip.c:2104 (so_rcv) 15 529 61 8 0 0 /usr/src/sys/kern/kern_descrip.c:2103 (accept) 12 162 60 2 0 0 /usr/src/sys/kern/kern_descrip.c:2200 (sleep mtxpool) 6 169 55 3 0 0 /usr/src/sys/netinet/ip_input.c:1215 (ipqlock) 106 2119 55 38 1 0 /usr/src/sys/netinet/tcp_timer.c:115 (tcp) 5 143 55 2 0 0 /usr/src/sys/netinet/igmp.c:443 (igmp_mtx) 16 171 28 6 0 1 /usr/src/sys/kern/vfs_subr.c:1641 (Syncer mtx) 11 82 28 2 0 0 /usr/src/sys/kern/vfs_subr.c:1717 (Syncer mtx) 28832 48031 94 510 31 2 /usr/src/sys/kern/kern_synch.c:218 (Giant) 6 372 131 2 0 0 /usr/src/sys/kern/uipc_socket2.c:346 (so_rcv) 24 640 187 3 0 0 /usr/src/sys/netinet/tcp_hostcache.c:291 (tcp_hc_entry) 5 184 66 2 0 0 /usr/src/sys/netinet/tcp_subr.c:1792 (so_rcv) 20 616 66 9 0 0 /usr/src/sys/netinet/tcp_subr.c:1791 (accept) 20 2261 368 6 4 360 /usr/src/sys/vm/vnode_pager.c:1199 (vm object) 286 4186 1274 3 21 25 /usr/src/sys/vm/vm_fault.c:346 (vm page queue mutex) 11 811 246 3 1 8 /usr/src/sys/vm/vm_fault.c:136 (vm page queue mutex) 308 7178 314 22 2 3 /usr/src/sys/vm/vm_fault.c:688 (vm object) 32 2582 246 10 0 0 /usr/src/sys/vm/vm_fault.c:792 (vm object) 32 1000 120 8 0 0 /usr/src/sys/vm/vm_fault.c:996 (vm object) 5 20 6 3 0 0 /usr/src/sys/vm/vm_pageout.c:1511 (vm page queue mutex) 24 238 81 2 0 0 /usr/src/sys/kern/kern_kthread.c:181 (process lock) 9 170 27 6 0 0 /usr/src/sys/kern/vfs_bio.c:2040 (buffer daemon lock) 15 195 27 7 0 0 /usr/src/sys/kern/vfs_subr.c:719 (vnode_free_list) 14 1138 264 4 0 0 /usr/src/sys/kern/vfs_subr.c:1977 (vnode interlock) 10 493 185 2 0 0 /usr/src/sys/vm/vnode_pager.c:229 (vm object) 10 498 195 2 0 0 /usr/src/sys/vm/vm_map.c:986 (vm object) 21 1236 192 6 0 0 /usr/src/sys/amd64/amd64/pmap.c:2233 (pmap) 34 2708 192 14 3 4 /usr/src/sys/vm/vm_map.c:1528 (vm page queue mutex) 41 3977 195 20 0 0 /usr/src/sys/vm/vm_map.c:1472 (vm object) 5 427 152 2 0 0 /usr/src/sys/netinet/tcp_subr.c:1649 (rtentry) 22 175 60 2 0 0 /usr/src/sys/kern/uipc_socket2.c:222 (accept) 7 280 108 2 0 0 /usr/src/sys/kern/uipc_socket.c:167 (so_glabel) 5 585 216 2 0 0 /usr/src/sys/kern/uipc_socket2.c:529 (process lock) 51 2961 108 27 0 0 /usr/src/sys/kern/uipc_socket2.c:468 (so_rcv) 60 3576 108 33 0 0 /usr/src/sys/kern/uipc_socket2.c:467 (so_snd) 31 505 102 4 0 0 /usr/src/sys/netinet/in_pcb.c:217 (inp) 5 155 60 2 0 0 /usr/src/sys/kern/uipc_socket2.c:262 (accept) 16 664 76 8 0 0 /usr/src/sys/netinet/tcp_input.c:2975 (so_snd) 17 647 76 8 0 0 /usr/src/sys/netinet/tcp_input.c:2992 (so_rcv) 112 3597 60 59 0 0 /usr/src/sys/netinet/tcp_syncache.c:564 (inp) 548 1815 161 11 0 0 /usr/src/sys/kern/uipc_socket2.c:127 (accept) 13 682 161 4 0 0 /usr/src/sys/kern/uipc_socket2.c:128 (so_rcv) 53 2072 60 34 0 0 /usr/src/sys/netinet/tcp_input.c:867 (inp) 4 149 59 2 0 0 /usr/src/sys/kern/uipc_socket2.c:142 (so_rcv) 653 6607 2202 3 0 0 /usr/src/sys/kern/kern_descrip.c:1761 (filedesc structure) 247 6505 2202 2 0 0 /usr/src/sys/kern/kern_descrip.c:1765 (filedesc structure) 5 95 27 3 0 0 /usr/src/sys/ufs/ffs/ffs_softdep.c:735 (Softdep Lock) 16 182 27 6 0 0 /usr/src/sys/ufs/ffs/ffs_softdep.c:754 (mountlist) 10 446 162 2 0 0 /usr/src/sys/ufs/ffs/ffs_softdep.c:847 (Softdep Lock) 42 2863 162 17 0 0 /usr/src/sys/ufs/ffs/ffs_softdep.c:767 (mountlist) 5 75 27 2 0 0 /usr/src/sys/ufs/ffs/ffs_softdep.c:774 (Softdep Lock) 3 24 8 3 10 5 /usr/src/sys/kern/kern_kse.c:965 (process lock) 5 31 9 3 7 4 /usr/src/sys/kern/kern_kse.c:422 (process lock) 513 7851 2242 3 0 0 /usr/src/sys/amd64/amd64/pmap.c:2255 (pmap) 2063 25059 2242 11 32 40 /usr/src/sys/vm/vm_fault.c:1011 (vm page queue mutex) 5 9 2 4 0 0 /usr/src/sys/vm/uma_core.c:988 (vm object) 5 81 30 2 0 0 /usr/src/sys/vm/uma_core.c:891 (PV ENTRY) 168 898 27 33 0 2 /usr/src/sys/kern/kern_time.c:627 (process lock) 5 147 52 2 0 0 /usr/src/sys/kern/uipc_socket2.c:172 (so_rcv) 5 148 52 2 0 0 /usr/src/sys/kern/uipc_socket2.c:177 (so_snd) 5 146 52 2 0 0 /usr/src/sys/kern/uipc_socket2.c:1081 (so_rcv) 215 3941 52 75 0 0 /usr/src/sys/netinet/tcp_usrreq.c:441 (inp) 45 742 26 28 0 0 /usr/src/sys/netinet/tcp_usrreq.c:165 (inp) 59 930 26 35 0 0 /usr/src/sys/netinet/tcp_usrreq.c:159 (tcp) 5 14 4 3 0 0 /usr/src/sys/kern/uipc_socket2.c:1153 (so_snd) 4 11 4 2 0 0 /usr/src/sys/netinet/tcp_input.c:1261 (so_snd) 11 456 153 2 0 0 /usr/src/sys/libkern/arc4random.c:137 (arc4_mtx) 68 222 6 37 0 0 /usr/src/sys/netinet/ip_fw2.c:4315 (IPFW dynamic rules) 62 224 46 4 1 0 /usr/src/sys/sys/buf.h:272 (lockbuilder mtxpool) 70 121 5 24 0 0 /usr/src/sys/kern/vfs_default.c:401 (vnode interlock) 9 151 35 4 3 3 /usr/src/sys/ufs/ffs/ffs_vfsops.c:1671 (vnode interlock) 11 162 38 4 0 16 /usr/src/sys/kern/vfs_bio.c:286 (needsbuffer lock) 5 163 43 3 0 3 /usr/src/sys/kern/vfs_bio.c:3745 (vnode interlock) 7 165 38 4 2 3 /usr/src/sys/kern/vfs_bio.c:3334 (vm page queue mutex) 27 504 38 13 3 1 /usr/src/sys/kern/vfs_bio.c:3332 (vm object) 16 339 31 10 0 1 /usr/src/sys/kern/vfs_default.c:433 (vnode interlock) 15 307 42 7 4 22 /usr/src/sys/dev/mfi/mfi_disk.c:258 (MFI I/O lock) 6 687 168 4 8 267 /usr/src/sys/kern/vfs_bio.c:2923 (bdone lock) 38 1053 42 25 0 0 /usr/src/sys/geom/geom_disk.c:198 (g_disk_done) 99 1933 40 48 10 4 /usr/src/sys/dev/mfi/mfi.c:912 (MFI I/O lock) 7 165 41 4 0 0 /usr/src/sys/kern/vfs_bio.c:332 (runningbufspace lock) 6 162 39 4 3 2 /usr/src/sys/kern/vfs_bio.c:3139 (vm page queue mutex) 27 521 39 13 2 4 /usr/src/sys/kern/vfs_bio.c:3120 (vm object) 11 785 265 2 4 3 /usr/src/sys/kern/vfs_bio.c:1437 (vnode interlock) 53 864 267 3 1 0 /usr/src/sys/kern/vfs_bio.c:355 (needsbuffer lock) 6 837 268 3 4 1 /usr/src/sys/kern/vfs_bio.c:313 (needsbuffer lock) 5 155 44 3 5 1 /usr/src/sys/kern/vfs_bio.c:3755 (vnode interlock) 12 45 10 4 0 0 /usr/src/sys/kern/vfs_subr.c:1846 (Syncer mtx) 13 96 16 6 0 0 /usr/src/sys/kern/vfs_subr.c:1596 (vnode interlock) 16 111 16 6 0 0 /usr/src/sys/kern/vfs_subr.c:1607 (Syncer mtx) 14 200 54 3 0 0 /usr/src/sys/netinet/ip_fw2.c:1327 (IPFW dynamic rules) 110 640 25 25 0 1 /usr/src/sys/netinet/udp_usrreq.c:510 (so_rcv) 116 830 25 33 0 0 /usr/src/sys/netinet/udp_usrreq.c:425 (inp) 123 996 25 39 0 6 /usr/src/sys/netinet/udp_usrreq.c:285 (udp) 5 689 248 2 0 0 /usr/src/sys/kern/vfs_vnops.c:499 (sleep mtxpool) 79 740 224 3 0 0 /usr/src/sys/ufs/ffs/ffs_vnops.c:597 (vnode interlock) 11 709 248 2 0 0 /usr/src/sys/kern/vfs_vnops.c:520 (sleep mtxpool) 5 701 414 1 0 0 /usr/src/sys/amd64/amd64/pmap.c:881 (pmap) 5 21 6 3 0 7 /usr/src/sys/vm/vm_glue.c:150 (system map) 905 2104 3 701 0 0 /usr/src/sys/vm/vm_meter.c:125 (vm object_list) 7 27136 17853 1 0 9629 /usr/src/sys/vm/vm_meter.c:198 (vm object) 132 337 3 112 0 0 /usr/src/sys/vm/vm_meter.c:212 (vm object_list) 5 36 8 4 0 0 /usr/src/sys/vm/swap_pager.c:2243 (swapdev) 5 112 41 2 0 0 /usr/src/sys/netinet/in_pcb.c:618 (rtentry) 44 115 3 38 0 0 /usr/src/sys/netinet/udp_usrreq.c:801 (udp) 8 97 23 4 0 0 /usr/src/sys/netinet/ip_fw2.c:1490 (IPFW dynamic rules) 269 3673 25 146 0 0 /usr/src/sys/netinet/udp_usrreq.c:805 (inp) 7 39 7 5 0 0 /usr/src/sys/netinet/tcp_timer.c:415 (tcp) 129 837 7 119 0 0 /usr/src/sys/netinet/tcp_timer.c:422 (inp) 33 33 1 33 0 0 /usr/src/sys/kern/uipc_socket2.c:292 (so_rcv) 67 337 43 7 0 0 /usr/src/sys/kern/uipc_socket2.c:159 (so_rcv) 97 257 43 5 0 0 /usr/src/sys/kern/uipc_socket2.c:160 (so_snd) 11 724 280 2 0 0 /usr/src/sys/kern/kern_descrip.c:383 (filedesc structure) 10 69 25 2 0 0 /usr/src/sys/kern/kern_descrip.c:423 (sleep mtxpool) 12 72 25 2 0 0 /usr/src/sys/kern/kern_descrip.c:426 (filedesc structure) 384 965 218 4 0 0 /usr/src/sys/kern/kern_descrip.c:431 (sleep mtxpool) 10 602 218 2 0 0 /usr/src/sys/kern/kern_descrip.c:436 (filedesc structure) 424 12200 218 55 11 6 /usr/src/sys/kern/kern_descrip.c:376 (Giant) 3 3 1 3 0 0 /usr/src/sys/kern/sys_pipe.c:385 (sleep mtxpool) 2 2 1 2 0 0 /usr/src/sys/kern/sys_pipe.c:400 (sleep mtxpool) 3 15 6 2 0 32 /usr/src/sys/kern/uipc_usrreq.c:920 (unp) 63 112 2 56 0 0 /usr/src/sys/kern/uipc_usrreq.c:399 (unp) 3 4 2 2 0 0 /usr/src/sys/kern/uipc_syscalls.c:628 (sleep mtxpool) 3 4 2 2 0 0 /usr/src/sys/kern/uipc_syscalls.c:633 (sleep mtxpool) 3 11 4 2 0 0 /usr/src/sys/kern/kern_fork.c:400 (process lock) 14 39 4 9 0 27 /usr/src/sys/kern/kern_fork.c:399 (process lock) 3 10 4 2 0 0 /usr/src/sys/kern/kern_descrip.c:1411 (filedesc structure) 5 12 4 3 0 0 /usr/src/sys/kern/kern_descrip.c:1421 (filedesc structure) 12 91 26 3 0 0 /usr/src/sys/kern/kern_descrip.c:1527 (sleep mtxpool) 76 208 4 52 0 0 /usr/src/sys/kern/kern_descrip.c:1511 (filedesc structure) 5 13 4 3 0 0 /usr/src/sys/kern/kern_descrip.c:1535 (filedesc structure) 5 13 4 3 0 0 /usr/src/sys/kern/kern_descrip.c:1539 (filedesc structure) 7 17 4 4 0 0 /usr/src/sys/kern/kern_descrip.c:1540 (filedesc structure) 7 28 7 4 0 0 /usr/src/sys/kern/kern_proc.c:1141 (struct pargs.ref) 5 16 4 4 0 0 /usr/src/sys/kern/kern_sig.c:2798 (sigacts) 5 10 4 2 0 0 /usr/src/sys/kern/kern_resource.c:921 (sleep mtxpool) 41 113 4 28 0 0 /usr/src/sys/kern/kern_fork.c:470 (process lock) 53 144 4 36 0 0 /usr/src/sys/kern/kern_fork.c:469 (process lock) 5 16 4 4 0 0 /usr/src/sys/kern/kern_fork.c:582 (session) 28 76 4 19 0 0 /usr/src/sys/kern/kern_fork.c:572 (process group) 5 15 4 3 0 0 /usr/src/sys/kern/kern_fork.c:600 (ktrace) 39 107 4 26 0 0 /usr/src/sys/kern/kern_fork.c:574 (process lock) 51 139 4 34 0 0 /usr/src/sys/kern/kern_fork.c:573 (process lock) 19 1419 144 9 0 0 /usr/src/sys/vm/vm_map.c:2508 (vm object) 111 2272 154 14 0 0 /usr/src/sys/amd64/amd64/pmap.c:2528 (vm page queue mutex) 95 958 76 12 0 0 /usr/src/sys/amd64/amd64/pmap.c:2531 (pmap) 104 1562 76 20 0 0 /usr/src/sys/amd64/amd64/pmap.c:2530 (pmap) 176 1262 82 15 0 0 /usr/src/sys/vm/vm_object.c:1627 (vm object) 15 609 95 6 0 0 /usr/src/sys/amd64/amd64/pmap.c:1933 (vm page queue mutex) 55 732 95 7 0 0 /usr/src/sys/amd64/amd64/pmap.c:1934 (pmap) 5 15 4 3 0 0 /usr/src/sys/kern/kern_fork.c:700 (process lock) 5 13 4 3 0 0 /usr/src/sys/kern/kern_fork.c:715 (process lock) 6 278 90 3 1 1 /usr/src/sys/vm/vm_object.c:1218 (vm object) 7 278 82 3 0 1 /usr/src/sys/vm/vm_object.c:1251 (vm object) 5 10 4 2 0 0 /usr/src/sys/kern/kern_fork.c:794 (process lock) 262 4189 329 12 0 240 /usr/src/sys/vm/vnode_pager.c:1211 (vnode interlock) 31 2903 329 8 0 0 /usr/src/sys/vm/vnode_pager.c:1229 (vm object) 60 88 4 22 0 0 /usr/src/sys/kern/uipc_usrreq.c:656 (so_rcv) 20 55 4 13 0 0 /usr/src/sys/kern/uipc_usrreq.c:680 (so_snd) 86 201 4 50 0 0 /usr/src/sys/kern/uipc_usrreq.c:564 (unp) 13 149 22 6 0 0 /usr/src/sys/fs/devfs/devfs_vnops.c:177 (devfs interlock) 31 288 22 13 0 0 /usr/src/sys/fs/devfs/devfs_vnops.c:180 (vnode interlock) 21 31061 11101 2 0 0 /usr/src/sys/kern/kern_descrip.c:998 (filedesc structure) 51 93 2 46 0 0 /usr/src/sys/kern/uipc_usrreq.c:433 (unp) 29 105 6 17 0 0 /usr/src/sys/kern/uipc_usrreq.c:417 (unp) 11 33 4 8 0 0 /usr/src/sys/dev/random/yarrow.c:280 (random reseed) 15 82 8 10 0 0 /usr/src/sys/fs/devfs/devfs_vnops.c:337 (vnode interlock) 3 6 4 1 0 0 /usr/src/sys/kern/vfs_subr.c:2192 (vnode interlock) 25 276 26 10 0 0 /usr/src/sys/vm/vm_fault.c:670 (vm object) 30 6812 2445 2 1 2 /usr/src/sys/kern/kern_proc.c:239 (process lock) 4 8 3 2 0 0 /usr/src/sys/kern/kern_proc.c:1209 (process lock) 1 1 1 1 0 0 /usr/src/sys/kern/kern_proc.c:302 (process lock) 1 1 1 1 0 0 /usr/src/sys/kern/kern_proc.c:305 (process group) 14 14 1 14 0 0 /usr/src/sys/kern/kern_proc.c:301 (Giant) 4 11 3 3 0 0 /usr/src/sys/kern/kern_proc.c:398 (process lock) 16 40 3 13 0 0 /usr/src/sys/kern/kern_proc.c:397 (process group) 25 64 3 21 0 0 /usr/src/sys/kern/kern_proc.c:396 (process group) 36 90 3 30 0 0 /usr/src/sys/kern/kern_proc.c:395 (Giant) 5 37 14 2 0 0 /usr/src/sys/kern/kern_descrip.c:625 (process lock) 5 44 14 3 0 0 /usr/src/sys/kern/kern_descrip.c:631 (filedesc structure) 11 48 14 3 0 0 /usr/src/sys/kern/kern_descrip.c:642 (sleep mtxpool) 10 21 5 4 0 0 /usr/src/sys/kern/kern_descrip.c:720 (filedesc structure) 5 25 9 2 0 0 /usr/src/sys/kern/kern_descrip.c:733 (filedesc structure) 5 24 7 3 0 0 /usr/src/sys/vm/vm_map.c:3105 (system map) 4 9 3 3 0 0 /usr/src/sys/kern/kern_exec.c:331 (process lock) 11 41 10 4 0 0 /usr/src/sys/vm/vm_page.c:1481 (vm page queue mutex) 5 15 5 3 0 0 /usr/src/sys/kern/kern_exec.c:876 (vm page queue mutex) 30 104 5 20 0 0 /usr/src/sys/kern/kern_exec.c:837 (vm object) 6 90 24 3 2 0 /usr/src/sys/vm/vm_object.c:1551 (vm page queue mutex) 5 334 106 3 12 6 /usr/src/sys/vm/vm_object.c:1570 (vm page queue mutex) 12 58 16 3 0 0 /usr/src/sys/vm/vm_object.c:1714 (vm object_list) 5 11 3 3 0 0 /usr/src/sys/vm/vm_map.c:2722 (process lock) 5 15 5 3 0 0 /usr/src/sys/vm/vm_glue.c:273 (vm page queue mutex) 26 93 5 18 0 0 /usr/src/sys/vm/vm_glue.c:256 (vm object) 3 11 5 2 0 0 /usr/src/sys/vm/vm_glue.c:309 (vm page queue mutex) 5 10 3 3 0 0 /usr/src/sys/kern/imgact_elf.c:762 (process lock) 5 13 5 2 0 0 /usr/src/sys/kern/kern_exec.c:898 (vm page queue mutex) 5 12 3 4 0 0 /usr/src/sys/kern/kern_descrip.c:1483 (filedesc structure) 15 108 13 8 0 2 /usr/src/sys/kern/kern_resource.c:1041 (uidinfo hash) 4 10 3 3 0 0 /usr/src/sys/kern/kern_descrip.c:1786 (filedesc structure) 1 5 3 1 0 0 /usr/src/sys/kern/kern_descrip.c:1811 (filedesc structure) 5 10 3 3 0 0 /usr/src/sys/kern/kern_sig.c:2808 (sigacts) 5 9 3 3 0 0 /usr/src/sys/kern/kern_sig.c:595 (sigacts) 26 63 3 21 0 0 /usr/src/sys/kern/kern_exec.c:518 (process lock) 5 27 10 2 0 0 /usr/src/sys/kern/kern_prot.c:1257 (process lock) 18 90 7 12 0 0 /usr/src/sys/kern/kern_prot.c:834 (process lock) 5 56 19 2 0 0 /usr/src/sys/kern/kern_prot.c:1988 (process lock) 2 2 1 2 0 0 /usr/src/sys/kern/kern_resource.c:689 (process lock) 3 9 4 2 0 0 /usr/src/sys/fs/devfs/devfs_vnops.c:611 (dev_clone) 4 11 4 2 0 0 /usr/src/sys/kern/uipc_usrreq.c:515 (so_rcv) 24 63 4 15 0 0 /usr/src/sys/kern/uipc_usrreq.c:499 (unp) 65 1180 26 45 0 0 /usr/src/sys/netinet/udp_usrreq.c:985 (udp) 5 118 44 2 0 0 /usr/src/sys/kern/uipc_syscalls.c:179 (filedesc structure) 26 441 26 16 0 0 /usr/src/sys/netinet/udp_usrreq.c:1070 (inp) 36 629 26 24 0 0 /usr/src/sys/netinet/udp_usrreq.c:1064 (udp) 17 85 14 6 0 0 /usr/src/sys/ufs/ffs/ffs_vnops.c:208 (vnode interlock) 3 5 2 2 0 0 /usr/src/sys/ufs/ffs/ffs_softdep.c:6021 (Softdep Lock) 29 54 3 18 0 0 /usr/src/sys/kern/vfs_bio.c:1600 (vnode interlock) 12 12 1 12 0 0 /usr/src/sys/kern/vfs_cluster.c:753 (vnode interlock) 1 1 1 1 0 0 /usr/src/sys/vm/vm_pager.c:324 (pbuf mutex) 5 9 2 4 0 0 /usr/src/sys/kern/vfs_cluster.c:895 (vm object) 6 6 1 6 0 0 /usr/src/sys/kern/vfs_cluster.c:835 (vnode interlock) 5 46 13 3 0 0 /usr/src/sys/ufs/ffs/ffs_softdep.c:3740 (process lock) 5 54 13 4 0 0 /usr/src/sys/ufs/ffs/ffs_softdep.c:3742 (Softdep Lock) 5 55 13 4 0 0 /usr/src/sys/ufs/ffs/ffs_softdep.c:3813 (process lock) 9 28 6 4 0 0 /usr/src/sys/ufs/ffs/ffs_vnops.c:283 (vnode interlock) 10 67 20 3 0 0 /usr/src/sys/kern/vfs_subr.c:1527 (Syncer mtx) 16 84 7 12 0 0 /usr/src/sys/kern/vfs_subr.c:3097 (vnode interlock) 13 50 7 7 0 0 /usr/src/sys/kern/vfs_subr.c:3105 (mountlist) 39 135 13 10 0 0 /usr/src/sys/ufs/ffs/ffs_softdep.c:4237 (Softdep Lock) 4 17 7 2 0 0 /usr/src/sys/kern/vfs_subr.c:3114 (struct mount mtx) 5 18 7 2 1 0 /usr/src/sys/kern/vfs_subr.c:2872 (struct mount mtx) 11 7193 4957 1 1 109 /usr/src/sys/kern/vfs_subr.c:2874 (vnode interlock) 14209 34629 12 2885 4 1 /usr/src/sys/kern/vfs_mount.c:1895 (struct mount mtx) 5 31 12 2 2 2 /usr/src/sys/kern/vfs_mount.c:1933 (struct mount mtx) 5 16 5 3 0 1 /usr/src/sys/ufs/ffs/ffs_vfsops.c:1139 (struct mount mtx) 4 17 5 3 0 0 /usr/src/sys/ufs/ffs/ffs_softdep.c:6242 (Softdep Lock) 3 13 5 2 0 0 /usr/src/sys/ufs/ffs/ffs_vfsops.c:1148 (struct mount mtx) 13 7658 4930 1 1 0 /usr/src/sys/ufs/ffs/ffs_vfsops.c:1157 (vnode interlock) 3 3 1 3 0 0 /usr/src/sys/vm/vm_pager.c:463 (vnode interlock) 5 5 1 5 0 0 /usr/src/sys/vm/vm_pager.c:401 (pbuf mutex) 5 13 5 2 0 67 /usr/src/sys/ufs/ffs/ffs_vfsops.c:1200 (vnode interlock) 5 22 7 3 0 0 /usr/src/sys/kern/vfs_subr.c:3120 (struct mount mtx) 5 97 37 2 0 0 /usr/src/sys/kern/kern_descrip.c:418 (filedesc structure) 4 4 1 4 0 0 /usr/src/sys/kern/kern_descrip.c:256 (process lock) 4 22 11 2 0 0 /usr/src/sys/kern/uipc_socket.c:1616 (so_rcv) 14 196 38 5 0 0 /usr/src/sys/netinet/tcp_usrreq.c:1023 (tcp) 15 239 38 6 0 0 /usr/src/sys/netinet/tcp_usrreq.c:1029 (inp) 1 6 4 1 0 0 /usr/src/sys/netinet/in_pcb.c:788 (inp) 10 27 4 6 0 0 /usr/src/sys/netinet/in_pcb.c:782 (tcp) 9 22 7 3 0 0 /usr/src/sys/netinet/in_pcb.c:761 (inp) 18 66 7 9 0 0 /usr/src/sys/netinet/in_pcb.c:755 (tcp) 112 1090 78 13 0 0 /usr/src/sys/amd64/amd64/pmap.c:2533 (pmap) 112 1142 78 14 0 0 /usr/src/sys/amd64/amd64/pmap.c:2534 (pmap) 7 12 2 6 0 0 /usr/src/sys/vm/vm_object.c:1333 (vm page queue mutex) 14 23 2 11 0 0 /usr/src/sys/vm/vm_object.c:1309 (vm object) 3 5 2 2 0 0 /usr/src/sys/vm/vm_object.c:1370 (vm page queue mutex) 23 44 2 22 0 5 /usr/src/sys/vm/vm_object.c:1308 (vm object) 2 3 2 1 0 0 /usr/src/sys/vm/vm_object.c:1378 (vm object) 3 5 2 2 0 0 /usr/src/sys/vm/vm_map.c:2644 (vm object) 3 3 1 3 0 0 /usr/src/sys/kern/vfs_syscalls.c:924 (filedesc structure) 4 4 1 4 0 0 /usr/src/sys/kern/vfs_syscalls.c:940 (filedesc structure) 15 15 1 15 0 0 /usr/src/sys/kern/kern_prot.c:1130 (process lock) 9 9 1 9 0 0 /usr/src/sys/kern/kern_resource.c:1046 (uidinfo hash) 52 52 1 52 0 0 /usr/src/sys/kern/kern_prot.c:1049 (process lock) 95 114 3 38 0 0 /usr/src/sys/kern/kern_prot.c:674 (process lock) 32 43 3 14 0 0 /usr/src/sys/kern/kern_prot.c:775 (process lock) 31 44 3 14 0 0 /usr/src/sys/kern/kern_prot.c:504 (process lock) 35 81 5 16 0 0 /usr/src/sys/kern/kern_prot.c:618 (process lock) 4 17 6 2 0 0 /usr/src/sys/kern/uipc_usrreq.c:382 (unp) 110 566 6 94 1 1 /usr/src/sys/kern/uipc_usrreq.c:1037 (Giant) 5 24 6 4 0 0 /usr/src/sys/kern/uipc_usrreq.c:1134 (unp) 1 3 2 1 0 0 /usr/src/sys/vm/vm_object.c:1689 (vm object) 26 50 7 7 0 1 /usr/src/sys/kern/sys_pipe.c:1479 (pipe mutex) 4 21 7 3 0 0 /usr/src/sys/kern/sys_pipe.c:1519 (pipe mutex) 3 6 2 3 0 0 /usr/src/sys/kern/kern_exit.c:350 (session) 2 2 1 2 0 0 /usr/src/sys/kern/kern_exit.c:426 (process lock) 9 9 1 9 0 0 /usr/src/sys/kern/kern_resource.c:1111 (uidinfo hash) 10 10 1 10 0 0 /usr/src/sys/kern/kern_resource.c:1112 (sleep mtxpool) 8 13 3 4 0 2 /usr/src/sys/kern/kern_exit.c:766 (process lock) 5 22 5 4 0 0 /usr/src/sys/kern/sys_pipe.c:993 (pipe mutex) 34 70 5 14 0 0 /usr/src/sys/kern/sys_pipe.c:1145 (pipe mutex) 4 14 5 2 0 0 /usr/src/sys/kern/sys_pipe.c:628 (pipe mutex) 5 5 1 5 0 0 /usr/src/sys/kern/kern_prot.c:135 (process lock) 5 7 2 3 0 0 /usr/src/sys/kern/kern_proc.c:319 (session) 6 9 2 4 0 0 /usr/src/sys/kern/kern_proc.c:322 (process group) 27 45 2 22 0 1 /usr/src/sys/kern/kern_proc.c:317 (Giant) 5 26 10 2 0 0 /usr/src/sys/kern/kern_descrip.c:1806 (filedesc structure) 4 31 10 3 0 0 /usr/src/sys/kern/kern_descrip.c:1808 (filedesc structure) 5 6 2 3 0 0 /usr/src/sys/kern/kern_sig.c:1164 (process lock) 11 6608 2464 2 0 0 /usr/src/sys/kern/kern_proc.c:638 (ktrace) 11 6671 2464 2 0 0 /usr/src/sys/kern/kern_proc.c:666 (sigacts) 10 6572 2464 2 0 0 /usr/src/sys/kern/kern_proc.c:717 (session) 361 62735 2464 25 3 24 /usr/src/sys/kern/kern_proc.c:1017 (process lock) 5 47 12 3 0 0 /usr/src/sys/vm/vm_glue.c:204 (process lock) 4 676 408 1 0 0 /usr/src/sys/amd64/amd64/pmap.c:2491 (pmap) 4 682 408 1 11 5 /usr/src/sys/vm/vm_fault.c:1093 (vm page queue mutex) 5 48 17 2 0 0 /usr/src/sys/ufs/ffs/ffs_alloc.c:1880 (FFS) 5 9 3 3 0 0 /usr/src/sys/ufs/ffs/ffs_softdep.c:2765 (FFS) 5 11 3 3 0 0 /usr/src/sys/ufs/ffs/ffs_softdep.c:2791 (Softdep Lock) 5 29 8 3 0 0 /usr/src/sys/ufs/ffs/ffs_softdep.c:986 (Softdep Lock) 11 19 3 6 0 0 /usr/src/sys/ufs/ffs/ffs_softdep.c:3669 (Softdep Lock) 4 11 3 3 0 0 /usr/src/sys/ufs/ffs/ffs_softdep.c:3675 (FFS) 5 9 3 3 0 0 /usr/src/sys/ufs/ffs/ffs_alloc.c:2072 (FFS) 4 10 3 3 0 0 /usr/src/sys/ufs/ffs/ffs_softdep.c:3681 (Softdep Lock) 3 11 5 2 0 0 /usr/src/sys/kern/subr_devstat.c:381 (devstat) 4 12 5 2 0 0 /usr/src/sys/kern/subr_devstat.c:394 (devstat) 5 60 22 2 0 0 /usr/src/sys/kern/kern_event.c:524 (filedesc structure) 5 62 22 2 0 0 /usr/src/sys/kern/kern_event.c:528 (sleep mtxpool) 596 1894 22 86 0 0 /usr/src/sys/netinet/udp_usrreq.c:1042 (inp) 602 2032 22 92 0 0 /usr/src/sys/netinet/udp_usrreq.c:1036 (udp) 5 69 22 3 0 0 /usr/src/sys/kern/uipc_syscalls.c:543 (so_rcv) 5 119 44 2 0 0 /usr/src/sys/kern/kern_event.c:980 (kqueue) 17 395 44 8 0 0 /usr/src/sys/kern/kern_event.c:972 (sleep mtxpool) 5 63 22 2 0 0 /usr/src/sys/kern/kern_event.c:723 (protect sysfilt_ops) 5 71 22 3 0 0 /usr/src/sys/kern/kern_event.c:779 (filedesc structure) 5 75 22 3 0 0 /usr/src/sys/kern/kern_event.c:788 (sleep mtxpool) 5 86 22 3 0 0 /usr/src/sys/kern/kern_event.c:1053 (kqueue) 11 76 22 3 0 0 /usr/src/sys/kern/kern_event.c:819 (filedesc structure) 15 86 22 3 0 0 /usr/src/sys/kern/kern_event.c:820 (kqueue) 5 71 22 3 0 0 /usr/src/sys/kern/kern_event.c:1577 (kqueue) 645 869 22 39 1 0 /usr/src/sys/kern/uipc_socket.c:2108 (so_rcv) 12 171 22 7 0 0 /usr/src/sys/kern/kern_event.c:926 (kqueue) 5 74 22 3 0 0 /usr/src/sys/kern/kern_event.c:1161 (kqueue) 96 243 21 11 0 0 /usr/src/sys/kern/kern_event.c:1547 (kqueue) 5 54 22 2 0 0 /usr/src/sys/kern/kern_event.c:1599 (kqueue) 21 211 22 9 0 0 /usr/src/sys/kern/uipc_socket.c:2120 (so_rcv) 12 80 22 3 0 0 /usr/src/sys/kern/kern_event.c:1847 (kqueue) 11 72 22 3 0 0 /usr/src/sys/kern/kern_event.c:739 (protect sysfilt_ops) 4 49 22 2 0 0 /usr/src/sys/kern/kern_event.c:1236 (kqueue) 4 50 22 2 0 0 /usr/src/sys/kern/kern_event.c:1000 (kqueue) 5 119 44 2 0 0 /usr/src/sys/kern/kern_event.c:1781 (kqueue) 5 74 22 3 0 0 /usr/src/sys/netinet/udp_usrreq.c:1087 (inp) 14 218 22 9 0 0 /usr/src/sys/netinet/udp_usrreq.c:1081 (udp) 5 74 22 3 0 0 /usr/src/sys/kern/kern_event.c:1421 (kqueue) 11 79 22 3 0 0 /usr/src/sys/kern/kern_event.c:1474 (filedesc structure) 84 799 16 49 0 0 /usr/src/sys/netinet/tcp_usrreq.c:121 (tcp) 4 41 16 2 0 0 /usr/src/sys/kern/uipc_socket2.c:115 (so_rcv) 1232 8691 32 271 0 0 /usr/src/sys/netinet/tcp_usrreq.c:368 (inp) 7 15 2 7 0 0 /usr/src/sys/kern/vfs_bio.c:1689 (buf queue lock) 7 7 1 7 0 0 /usr/src/sys/kern/vfs_bio.c:3545 (vm object) 3 3 1 3 0 0 /usr/src/sys/ufs/ffs/ffs_vfsops.c:1715 (vnode interlock) 2 2 1 2 0 0 /usr/src/sys/ufs/ffs/ffs_softdep.c:1003 (Softdep Lock) 5 5 1 5 0 0 /usr/src/sys/ufs/ffs/ffs_vfsops.c:1598 (vnode interlock) 8 20 4 5 0 0 /usr/src/sys/kern/vfs_bio.c:3596 (vm page queue mutex) 70 70 1 70 0 0 /usr/src/sys/kern/vfs_bio.c:3584 (vm object) 2 2 1 2 0 0 /usr/src/sys/kern/vfs_subr.c:1500 (vnode interlock) 3 5 2 2 0 0 /usr/src/sys/kern/vfs_bio.c:1321 (buf queue lock) 4 4 1 4 0 0 /usr/src/sys/ufs/ffs/ffs_vfsops.c:1620 (vnode interlock) 1102 2187 10 218 0 0 /usr/src/sys/ufs/ffs/ffs_vfsops.c:1181 (struct mount mtx) 5 6 2 3 0 0 /usr/src/sys/ufs/ffs/ffs_softdep.c:1826 (Softdep Lock) 10 15 2 7 0 0 /usr/src/sys/net/rtsock.c:1100 (ifnet) 5 17 4 4 0 0 /usr/src/sys/net/if.c:1235 (ifnet) 1579 3160 3 1053 0 0 /usr/src/sys/dev/em/if_em.c:1652 (em0) 23 797 246 3 0 217 /usr/src/sys/netinet/tcp_timer.c:252 (inp) 3 37 17 2 0 0 /usr/src/sys/vm/uma_core.c:2209 (UMA Slabs) 4 7 2 3 0 0 /usr/src/sys/ufs/ffs/ffs_balloc.c:654 (FFS) 2 3 2 1 0 0 /usr/src/sys/ufs/ffs/ffs_alloc.c:307 (FFS) 1 3 2 1 0 0 /usr/src/sys/ufs/ffs/ffs_alloc.c:1367 (FFS) 2 4 2 2 0 0 /usr/src/sys/ufs/ffs/ffs_softdep.c:1556 (Softdep Lock) 2 4 2 2 0 0 /usr/src/sys/ufs/ffs/ffs_softdep.c:1368 (Softdep Lock) 3 10 4 2 0 0 /usr/src/sys/ufs/ffs/ffs_softdep.c:653 (Softdep Lock) 3 3 1 3 0 0 /usr/src/sys/ufs/ffs/ffs_softdep.c:1591 (Softdep Lock) 26 33 3 11 0 0 /usr/src/sys/kern/vfs_bio.c:2793 (vm object) 5 10 2 5 0 0 /usr/src/sys/kern/vfs_bio.c:3483 (vm object) 6 9 2 4 0 0 /usr/src/sys/ufs/ffs/ffs_softdep.c:1659 (Softdep Lock) 2 2 1 2 0 0 /usr/src/sys/ufs/ffs/ffs_softdep.c:1291 (Softdep Lock) 4 22 8 2 0 0 /usr/src/sys/vm/uma_core.c:2408 (2048) 14 53 10 5 0 0 /usr/src/sys/netinet/ip_output.c:1240 (tcp) 15 80 10 8 0 0 /usr/src/sys/netinet/ip_output.c:1246 (inp) 4 5 2 2 0 0 /usr/src/sys/fs/fifofs/fifo_vnops.c:224 (fifo mutex) 1874 1922 2 961 2 0 /usr/src/sys/fs/fifofs/fifo_vnops.c:733 (Giant) 4 6 2 3 0 0 /usr/src/sys/ufs/ufs/ufs_vnops.c:2014 (vnode interlock) 9 18 2 9 0 0 /usr/src/sys/kern/uipc_usrreq.c:522 (so_snd) 58 109 2 54 0 0 /usr/src/sys/fs/fifofs/fifo_vnops.c:711 (Giant) 5 22 6 3 0 0 /usr/src/sys/kern/vfs_syscalls.c:3883 (filedesc structure) 5 23 6 3 0 0 /usr/src/sys/kern/vfs_syscalls.c:3891 (sleep mtxpool) 4 19 6 3 0 0 /usr/src/sys/kern/vfs_syscalls.c:3894 (filedesc structure) 5 10 2 5 0 0 /usr/src/sys/ufs/ffs/ffs_vfsops.c:1080 (FFS) 70 130 2 65 0 0 /usr/src/sys/kern/vfs_syscalls.c:334 (Giant) 5 5 1 5 0 0 /usr/src/sys/kern/sys_pipe.c:1270 (pipe mutex) 5 224 73 3 0 0 /usr/src/sys/vm/uma_core.c:416 (FFS2 dinode) 506 506 1 506 0 0 /usr/src/sys/vm/uma_core.c:1494 (UMA lock) 1 1 1 1 0 5 /usr/src/sys/vm/vnode_pager.c:157 (vm object) 1 1 1 1 0 0 /usr/src/sys/kern/vfs_bio.c:2535 (vnode interlock) 1 1 1 1 0 0 /usr/src/sys/kern/vfs_subr.c:2170 (vnode interlock) 1 1 1 1 0 0 /usr/src/sys/kern/vfs_bio.c:3704 (bdone lock) 3 3 1 3 0 0 /usr/src/sys/kern/vfs_bio.c:3694 (bdone lock) 2 2 1 2 0 0 /usr/src/sys/kern/vfs_bio.c:1248 (vm object) 2 2 1 2 0 0 /usr/src/sys/kern/vfs_cluster.c:133 (vnode interlock) 3 3 1 3 0 0 /usr/src/sys/dev/mfi/mfi.c:2497 (MFI I/O lock) --------------060705080807060306020005 Content-Type: text/plain; name="dual.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dual.txt" Copyright (c) 1992-2007 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 6.2-STABLE #1: Wed Oct 3 16:49:23 MSD 2007 llp@cover.xxx.ru:/usr/obj/usr/src/sys/xxxSMP-amd64 module_register: module accf_http already exists! Module accf_http failed to register: 17 module_register: module mfi_linux already exists! Module mfi_linux failed to register: 17 ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU 5120 @ 1.86GHz (1871.23-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Features=0xbfebfbff Features2=0x4e3bd AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 real memory = 5905580032 (5632 MB) avail memory = 4096319488 (3906 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard lapic0: Forcing LINT1 to edge trigger kbd1 at kbdmux0 module_register_init: MOD_LOAD (accf_http, 0xffffffff80340ea0, 0xffffffff807b4720) error 17 acpi0: on motherboard acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 2000 acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 cpu1: on acpi0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 cpu2: on acpi0 acpi_throttle2: on cpu2 acpi_throttle2: failed to attach P_CNT device_attach: acpi_throttle2 attach returned 6 cpu3: on acpi0 acpi_throttle3: on cpu3 acpi_throttle3: failed to attach P_CNT device_attach: acpi_throttle3 attach returned 6 acpi_button0: on acpi0 pcib0: port 0xca2,0xca3,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: irq 16 at device 1.0 on pci2 pci4: on pcib4 pcib5: irq 16 at device 2.0 on pci2 pci5: on pcib5 em0: port 0x2020-0x203f mem 0xb8820000-0xb883ffff,0xb8400000-0xb87fffff irq 18 at device 0.0 on pci5 em0: Ethernet address: 00:04:23:dd:5a:26 em1: port 0x2000-0x201f mem 0xb8800000-0xb881ffff,0xb8000000-0xb83fffff irq 19 at device 0.1 on pci5 em1: Ethernet address: 00:04:23:dd:5a:27 pcib6: at device 0.3 on pci1 pci6: on pcib6 pcib7: at device 3.0 on pci0 pci7: on pcib7 pcib8: at device 4.0 on pci0 pci8: on pcib8 pcib9: at device 5.0 on pci0 pci9: on pcib9 pcib10: at device 6.0 on pci0 pci10: on pcib10 pcib11: at device 0.0 on pci10 pci11: on pcib11 mfi0: mem 0xb8a00000-0xb8a0ffff,0xb8c00000-0xb8c1ffff irq 18 at device 14.0 on pci11 mfi0: Megaraid SAS driver Ver 2.00 mfi0: 593 (245173707s/0x0020/0) - Shutdown command received from host mfi0: 594 (4278190080s/0x0020/0) - PCI 0x041000 0x04411 0x041000 0x041004: Firmware initialization started (PCI ID 0411/1000/1004/1000) mfi0: 595 (4278190080s/0x0020/0) - Type 18: Firmware version 1.03.60-0255 mfi0: 596 (4278190080s/0x0020/0) - PCI 0x041000 0x04411 0x041000 0x041004: Firmware initialization started (PCI ID 0411/1000/1004/1000) mfi0: 597 (4278190080s/0x0020/0) - Type 18: Firmware version 1.03.60-0255 mfi0: 598 (4278190080s/0x0020/0) - PCI 0x041000 0x04411 0x041000 0x041004: Firmware initialization started (PCI ID 0411/1000/1004/1000) mfi0: 599 (4278190080s/0x0020/0) - Type 18: Firmware version 1.03.60-0255 mfi0: 600 (4278190080s/0x0020/0) - PCI 0x041000 0x04411 0x041000 0x041004: Firmware initialization started (PCI ID 0411/1000/1004/1000) mfi0: 601 (4278190080s/0x0020/0) - Type 18: Firmware version 1.03.60-0255 mfi0: 602 (4278190126s/0x0008/0) - Battery temperature is normal mfi0: 603 (4278190126s/0x0008/0) - Battery Present mfi0: 604 (4278190161s/0x0002/0) - PD 08(e0/s8) event: Inserted: PD 08(e0/s8) mfi0: 605 (4278190161s/0x0002/0) - Type 29: Inserted: PD 08(e0/s8) Info: enclPd=ffff, scsiType=0, portMap=01, sasAddr=500000e0158537c2,0000000000000000 mfi0: 606 (4278190161s/0x0002/0) - PD 09(e0/s9) event: Inserted: PD 09(e0/s9) mfi0: 607 (4278190161s/0x0002/0) - Type 29: Inserted: PD 09(e0/s9) Info: enclPd=ffff, scsiType=0, portMap=02, sasAddr=500000e0158539f2,0000000000000000 mfi0: 608 (245173902s/0x0020/0) - Adapter ticks 245173902 elapsed 82s: Time established as 10/08/07 15:51:42; (82 seconds since power on) pcib12: at device 0.2 on pci10 pci12: on pcib12 pcib13: at device 7.0 on pci0 pci13: on pcib13 pci0: at device 8.0 (no driver attached) uhci0: port 0x3080-0x309f irq 23 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x3060-0x307f irq 22 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x3040-0x305f irq 23 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x3020-0x303f irq 22 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xb8d00400-0xb8d007ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered pcib14: at device 30.0 on pci0 pci14: on pcib14 pci14: at device 12.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30b0-0x30bf irq 20 at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 atapci1: port 0x30c8-0x30cf,0x30e4-0x30e7,0x30c0-0x30c7,0x30e0-0x30e3,0x30a0-0x30af mem 0xb8d00000-0xb8d003ff irq 20 at device 31.2 on pci0 ata2: on atapci1 ata3: on atapci1 pci0: at device 31.3 (no driver attached) sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] orm0: at iomem 0xc0000-0xc8fff,0xc9000-0xcdfff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec IP Filter: v4.1.13 initialized. Default = pass all, Logging = enabled ipfw2 initialized, divert enabled, rule-based forwarding disabled, default to accept, logging unlimited acd0: DVDR at ata0-slave UDMA33 mfid0: on mfi0 mfid0: 139236MB (285155328 sectors) RAID volume '' is optimal lapic1: Forcing LINT1 to edge trigger SMP: AP CPU #1 Launched! lapic7: Forcing LINT1 to edge trigger SMP: AP CPU #3 Launched! lapic6: Forcing LINT1 to edge trigger SMP: AP CPU #2 Launched! Trying to mount root from ufs:/dev/mfid0s1a em0: link state changed to UP 1 users Load 5.27 7.25 6.15 Nov 19 16:22 Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER Tot Share Tot Share Free in out in out Act 2309932 13812 2385372 32628 880612 count All 2387968 14912 6766444 36300 pages Proc: Interrupts r p d s w Csw Trp Sys Int Sof Flt 1 cow 13149 total 38 4 30k 6327 117k 15k 233 3596 3525 zfod sio0 irq4 3523 ozfod ata0 irq14 17.9%Sys 3.5%Intr 41.5%User 0.0%Nice 37.1%Idle 99%ozfod 5148 em0 mfi0 1 | | | | | | | | | | | daefr uhci0 uhci =========++>>>>>>>>>>>>>>>>>>>> prcfr 1993 cpu0: time 36 dtbuf 3933 totfr 1993 cpu1: time Namei Name-cache Dir-cache 100000 desvn react 2007 cpu3: time Calls hits % hits % 27886 numvn pdwak 2008 cpu2: time 169660 169660 100 24717 frevn pdpgs intrn Disks mfid0 278668 wire KB/t 0.00 2318668 act tps 0 426152 inact MB/s 0.00 190808 cache %busy 0 689804 free --------------060705080807060306020005-- From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 13:46:34 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 872D716A417 for ; Mon, 19 Nov 2007 13:46:34 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4A71F13C448 for ; Mon, 19 Nov 2007 13:46:33 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Iu6wF-0006mu-Q3 for freebsd-stable@freebsd.org; Mon, 19 Nov 2007 13:45:23 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 19 Nov 2007 13:45:23 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 19 Nov 2007 13:45:23 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Mon, 19 Nov 2007 14:46:28 +0100 Lines: 35 Message-ID: References: <4741905E.8050300@chistydom.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.6 (X11/20070801) In-Reply-To: <4741905E.8050300@chistydom.ru> Sender: news Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 13:46:34 -0000 Alexey Popov wrote: > Hi. > > I have a large pool of web backends (Apache + mod_php5) with > 2 x Xeon 3.2GHz processors and 2 x Xeon 5120 dual-core processors. The > workload is mostly CPU-bound. I'm using 6-STABLE-amd64 and also tried > 7-STABLE. If you haven't tried mod_fcgid, give it a try - it can dramatically benefit PHP applications. And with mod_fcgid, you can use apache with a multi-threaded MPM (i.e. worker-mpm). > Now I'm trying to use new hardware with 2 x Xeon 5320 (quad-core), but > it can not work under the same load as dual-core. It shows up to 80% > system CPU load in top: On what version of FreeBSD is this? If it's 6-STABLE, this might be expected. > CPU states: 9.5% user, 0.0% nice, 79.9% system, 1.2% interrupt, 9.5% > idle Can you try hitting "S" to see if a kernel process is gobbling up CPU time? > Here's the output from 2xdual-core backend running under the same load > and with the same software: > CPU states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0% > idle This line is bogus - where is the load? > What can I do to make FreeBSD run faster on many-CPU systems??? Except for trying 7-STABLE, there's not much you can do. From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 13:47:10 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AD9116A418 for ; Mon, 19 Nov 2007 13:47:10 +0000 (UTC) (envelope-from toomas.aas@raad.tartu.ee) Received: from kuller.raad.tartu.ee (kuller.raad.tartu.ee [194.126.106.100]) by mx1.freebsd.org (Postfix) with ESMTP id CFA4D13C478 for ; Mon, 19 Nov 2007 13:47:09 +0000 (UTC) (envelope-from toomas.aas@raad.tartu.ee) Received: from localhost (localhost [127.0.0.1]) by kuller.raad.tartu.ee (Postfix) with ESMTP id 539AAB822 for ; Mon, 19 Nov 2007 15:46:47 +0200 (EET) X-Virus-Scanned: amavisd-new at post.raad.tartu.ee Received: from kuller.raad.tartu.ee ([127.0.0.1]) by localhost (kuller.raad.tartu.ee [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RocgdcWtMFPU for ; Mon, 19 Nov 2007 15:46:46 +0200 (EET) Received: from raad.tartu.ee (lv.raad.tartu.ee [194.126.106.110]) by kuller.raad.tartu.ee (Postfix) with ESMTP id 77F44B815 for ; Mon, 19 Nov 2007 15:46:46 +0200 (EET) Received: from INFO/SpoolDir by raad.tartu.ee (Mercury 1.48); 19 Nov 07 15:46:46 +0200 Received: from SpoolDir by INFO (Mercury 1.48); 19 Nov 07 15:46:34 +0200 Received: from [172.26.1.6] (172.26.1.6) by raad.tartu.ee (Mercury 1.48) with ESMTP; 19 Nov 07 15:46:28 +0200 Message-ID: <4745882E.4040405@raad.tartu.ee> Date: Thu, 22 Nov 2007 15:46:22 +0200 From: Toomas Aas User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <474577B9.7090104@raad.tartu.ee> In-Reply-To: <474577B9.7090104@raad.tartu.ee> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: garbled gjournal messages in dmesg with 7.0-BETA3 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 13:47:10 -0000 Forgot to mention, I'm running amd64. -- Toomas Aas From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 14:02:48 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7D8B16A468 for ; Mon, 19 Nov 2007 14:02:48 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8A8DF13C45A for ; Mon, 19 Nov 2007 14:02:48 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id D0ACA472AB; Mon, 19 Nov 2007 09:04:59 -0500 (EST) Date: Mon, 19 Nov 2007 14:02:25 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Alexey Popov In-Reply-To: <4741905E.8050300@chistydom.ru> Message-ID: <20071119140019.V80667@fledge.watson.org> References: <4741905E.8050300@chistydom.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 14:02:48 -0000 On Mon, 19 Nov 2007, Alexey Popov wrote: > I tried Linux and it works much better than old (2 x dual-core) backends. It > handles 2 times more requests than FreeBSD on the old backends. So there's a > real scalability problem in FreeBSD. The more processors it have the more > CPU time it consumes. > > Also I faced the same problem moving heavily loaded MySQL-server to new > hardware. That time I thought that the problem is in the mysql-server itself > and I had to install Linux. > > See in attach: mutex statistics for quad-core system and dmesg and vmstat > for dual- and quad-core systems. > > What can I do to make FreeBSD run faster on many-CPU systems??? Have you configured libmap.conf to force MySQL to use libthr instead of libpthread? libpthread is known to have serious performance bottlenecks for MySQL as compared to libthr. FreeBSD 7 contains significant optimization for increased numbers of cores, and is where a lot of the work optimizing MySQL has ended up. I see you're trying out a 6.3 beta, any chance you could try out a 7.0 beta instead? Also, consider switching to "options SCHED_ULE" in the 7.0 kernel rather than "options SCHED_4BSD". Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 14:16:46 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C5D716A41B for ; Mon, 19 Nov 2007 14:16:46 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from hermes.hw.ru (hermes.hw.ru [80.68.240.91]) by mx1.freebsd.org (Postfix) with ESMTP id DEE3113C44B for ; Mon, 19 Nov 2007 14:16:44 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from [80.68.244.40] (account a_popov@rbc.ru [80.68.244.40] verified) by hermes.hw.ru (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 201269577; Mon, 19 Nov 2007 17:16:21 +0300 Message-ID: <47419AB3.5030008@chistydom.ru> Date: Mon, 19 Nov 2007 17:16:19 +0300 From: Alexey Popov User-Agent: Thunderbird 2.0.0.6 (X11/20070924) MIME-Version: 1.0 To: Ivan Voras References: <4741905E.8050300@chistydom.ru> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 14:16:46 -0000 Hi. Ivan Voras wrote: >> I have a large pool of web backends (Apache + mod_php5) with >> 2 x Xeon 3.2GHz processors and 2 x Xeon 5120 dual-core processors. The >> workload is mostly CPU-bound. I'm using 6-STABLE-amd64 and also tried >> 7-STABLE. > If you haven't tried mod_fcgid, give it a try - it can dramatically > benefit PHP applications. And with mod_fcgid, you can use apache with a > multi-threaded MPM (i.e. worker-mpm). We tried to run php + nginx via fastcgi interface without apache at all, but improvement was too little (~10% more request per second) to abandon the advantages of apache. >> Now I'm trying to use new hardware with 2 x Xeon 5320 (quad-core), but >> it can not work under the same load as dual-core. It shows up to 80% >> system CPU load in top: > On what version of FreeBSD is this? If it's 6-STABLE, this might be > expected. I have almost identical results on 6-STABLE and 7-STABLE. Maybe 7-STABLE performs a little better. >> CPU states: 9.5% user, 0.0% nice, 79.9% system, 1.2% interrupt, 9.5% >> idle > Can you try hitting "S" to see if a kernel process is gobbling up CPU time? There's no such a process: last pid: 5266; load averages: 24.67, 22.65, 17.44 up 0+03:56:38 17:09:37 121 processes: 41 running, 62 sleeping, 18 waiting CPU states: 9.5% user, 0.0% nice, 82.0% system, 0.5% interrupt, 8.0% idle Mem: 439M Active, 27M Inact, 80M Wired, 108K Cache, 58M Buf, 3341M Free Swap: 2048M Total, 2048M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 5090 www -4 0 96572K 49464K RUN 5 2:59 23.39% httpd 3748 www -4 0 96172K 50060K RUN 4 14:21 23.19% httpd 5092 www -4 0 96412K 48060K RUN 4 2:57 23.19% httpd 5095 www -4 0 98148K 50688K RUN 5 2:57 22.75% httpd 5088 www -4 0 96664K 49120K RUN 4 3:02 22.56% httpd 5098 www -4 0 97404K 49864K RUN 3 2:57 22.56% httpd 5106 www 118 0 97908K 49972K CPU7 6 2:57 22.51% httpd 5084 www -4 0 96012K 48164K RUN 5 3:01 22.46% httpd 5081 www -4 0 96636K 49700K RUN 0 3:01 22.36% httpd 5109 www -4 0 96844K 49188K RUN 3 2:51 22.36% httpd 5108 www -4 0 95808K 47508K RUN 5 3:00 22.31% httpd 5085 www -4 0 98244K 49560K RUN 4 2:58 21.88% httpd 5104 www -4 0 96836K 48956K CPU5 5 2:55 21.88% httpd 5086 www 118 0 99140K 51264K CPU0 3 3:00 21.78% httpd 5111 www -4 0 96360K 48532K RUN 0 2:56 21.78% httpd 5105 www -4 0 96364K 47356K RUN 0 2:58 21.73% httpd 5099 www -4 0 94444K 47156K RUN 4 2:55 21.73% httpd 5096 www -4 0 96004K 48324K RUN 4 2:56 21.68% httpd 5083 www 117 0 97712K 50344K RUN 2 3:03 21.63% httpd 5094 www 118 0 97196K 49348K CPU3 6 2:56 21.58% httpd 5103 www -4 0 96040K 48808K RUN 4 2:58 21.48% httpd 5089 www 118 0 96084K 47808K CPU2 4 2:59 21.34% httpd 5082 www 117 0 96412K 48520K CPU6 5 3:00 21.29% httpd 5107 www -4 0 98172K 50332K RUN 4 2:55 21.29% httpd 5091 www -4 0 97460K 49504K RUN 0 2:56 20.95% httpd 5100 www -4 0 97188K 49400K RUN 4 2:56 20.65% httpd 5110 www -4 0 95168K 47436K RUN 5 2:59 20.56% httpd 5087 www 116 0 98432K 51172K CPU4 5 2:55 20.31% httpd 5097 www -4 0 96428K 49124K RUN 4 2:59 20.21% httpd 5102 www 117 0 96344K 48512K CPU3 4 3:01 19.82% httpd 5093 www -4 0 96512K 49948K RUN 4 2:55 19.82% httpd 5101 www -4 0 96012K 48968K RUN 3 3:01 19.48% httpd 10 root 171 52 0K 16K RUN 7 174:56 7.86% idle: cpu7 12 root 171 52 0K 16K RUN 5 174:44 7.86% idle: cpu5 14 root 171 52 0K 16K RUN 3 175:04 7.62% idle: cpu3 >> Here's the output from 2xdual-core backend running under the same load >> and with the same software: > >> CPU states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0% >> idle > > This line is bogus - where is the load? Sorry, probably it was my fault in copy&past. last pid: 54690; load averages: 3.47, 4.89, 5.18 up 42+02:07:51 17:00:00 47 processes: 3 running, 43 sleeping, 1 zombie CPU states: 56.0% user, 0.0% nice, 16.7% system, 1.6% interrupt, 25.7% idle Mem: 2268M Active, 416M Inact, 277M Wired, 186M Cache, 214M Buf, 664M Free Swap: 2048M Total, 1408K Used, 2047M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 54681 www 1 106 0 96916K 47792K CPU3 0 0:10 33.45% httpd 54652 www 1 20 0 97716K 48144K lockf 1 0:24 31.61% httpd 54680 www 1 106 0 96416K 46832K select 1 0:10 31.37% httpd 54686 www 1 20 0 97640K 45604K lockf 1 0:04 31.13% httpd 54651 www 1 104 0 96552K 46924K CPU1 1 0:25 29.50% httpd 54685 www 1 107 0 99124K 47300K select 3 0:03 25.93% httpd 54676 www 1 104 0 96492K 46368K select 1 0:09 25.14% httpd 54690 www 1 20 0 95816K 43584K lockf 1 0:01 23.81% httpd 54687 www 1 20 0 96360K 42892K lockf 1 0:02 22.48% httpd 54684 www 1 107 0 99120K 46152K select 3 0:02 13.18% httpd 787 nobody 1 4 0 2079M 2077M kqread 1 20.7H 4.00% memcached 660 root 1 96 0 18120K 2108K select 0 25:18 0.00% snmpd 795 root 6 20 0 14652K 2992K kserel 1 13:28 0.00% bacula-fd >> What can I do to make FreeBSD run faster on many-CPU systems??? > Except for trying 7-STABLE, there's not much you can do. I've already tried it, but no luck. With best regards, Alxey Popov From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 14:22:17 2007 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEDA416A419 for ; Mon, 19 Nov 2007 14:22:17 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2001:1b20:1:3::1]) by mx1.freebsd.org (Postfix) with ESMTP id 12A4213C43E for ; Mon, 19 Nov 2007 14:22:16 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id lAJEM92u091763; Mon, 19 Nov 2007 15:22:15 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id lAJEM9Xp091762; Mon, 19 Nov 2007 15:22:09 +0100 (CET) (envelope-from olli) Date: Mon, 19 Nov 2007 15:22:09 +0100 (CET) Message-Id: <200711191422.lAJEM9Xp091762@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, toomas.aas@raad.tartu.ee In-Reply-To: <474577B9.7090104@raad.tartu.ee> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Mon, 19 Nov 2007 15:22:15 +0100 (CET) Cc: Subject: Re: garbled gjournal messages in dmesg with 7.0-BETA3 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, toomas.aas@raad.tartu.ee List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 14:22:18 -0000 Toomas Aas wrote: > kernel: GEOM_JOURNAL: Journal 161627211: aacd1s2 contains data. > kernel: GEOM_JOURNAL: Journal 161627211: aacd1s2 contains journal. > kernel: GEOM_JOURNAL: Journal aacd1s2 clean. > kernel: GEOM_JOURNAL: Journal 3372893522: aacd1s3 contains data. > kernel: GEOM_JOURNAL: Journal 3372893522: aacd1s3 contains journal. > kernel: GEOM_JOURNAL: Journal aacd1s3 clean. > kernel: GEOM_JOURNAL: BIO_FLUSH not supported by aacd1s2. > kernel: GEOM_JOURNAL: BIO_FLUSH not supported by aacd1s3. > kernel: WARNING: Expected rawoffset 0, found 514080 > kernel: WARNING: Expected rawoffset 0, found 42443730 > > Now I updated RELENG_7 today (20071119), and upon rebooting there are some > garbled messages: > > kernel: GEOM_JOURNAL: Journal 161627211: aacd1s2 contains data. > kernel: GEOM_JOURNAL: Journal 161627211: aacd1s2 contains journal. > kernel: GEOM_JOURNAL: Journal aacd1s2 clean. > kernel: GEOM_JOURNAL: Journal 3372893522: aacd1s3G EcOoMn_tJaOiUnRsN AdLa:t > aB.IO > kernel: _GFELOUMS_HJ OnUoRtN AsLu:p pJoorutrenda lb y 3a3a7c2d819s325.22 > kernel: : aacd1s3 contains journal. > kernel: GEOM_JOURNAL: Journal aacd1s3 clean. > kernel: GEOM_JOURNAL: BIO_FLUSH not supported by aacd1s3. > kernel: WARNING: Expected rawoffset 0, found 514080 > kernel: WARNING: Expected rawoffset 0, found 42443730 Both sets of messages are exactly identical, except that in the second set, a few parts got interleaved. Try to copy the garbled parts and delete every second character, then you can recognize it. It's a known problem, but it's not trivial to solve in a generic and efficient way. > The filesystem on aacd1s3.journal was mounted successfully and files seem > to be intact, (but I haven't really verified all the files). Don't worry, your file systems are OK. It's just a display problem. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "To this day, many C programmers believe that 'strong typing' just means pounding extra hard on the keyboard." -- Peter van der Linden From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 14:24:15 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01B7916A420 for ; Mon, 19 Nov 2007 14:24:15 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from hermes.hw.ru (hermes.hw.ru [80.68.240.91]) by mx1.freebsd.org (Postfix) with ESMTP id 86DB613C4B8 for ; Mon, 19 Nov 2007 14:24:14 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from [80.68.244.40] (account a_popov@rbc.ru [80.68.244.40] verified) by hermes.hw.ru (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 201272467; Mon, 19 Nov 2007 17:23:45 +0300 Message-ID: <47419C6F.80903@chistydom.ru> Date: Mon, 19 Nov 2007 17:23:43 +0300 From: Alexey Popov User-Agent: Thunderbird 2.0.0.6 (X11/20070924) MIME-Version: 1.0 To: Robert Watson References: <4741905E.8050300@chistydom.ru> <20071119140019.V80667@fledge.watson.org> In-Reply-To: <20071119140019.V80667@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 14:24:15 -0000 Hi. Robert Watson wrote: >> Also I faced the same problem moving heavily loaded MySQL-server to >> new hardware. That time I thought that the problem is in the >> mysql-server itself and I had to install Linux. >> What can I do to make FreeBSD run faster on many-CPU systems??? > Have you configured libmap.conf to force MySQL to use libthr instead of > libpthread? libpthread is known to have serious performance bottlenecks > for MySQL as compared to libthr. I'm always using libthr with MySQL on 6-STABLE and it really helps. But that time with MySQL (and this time with Apache) the bottleneck was somewhere else. > FreeBSD 7 contains significant optimization for increased numbers of > cores, and is where a lot of the work optimizing MySQL has ended up. I > see you're trying out a 6.3 beta, any chance you could try out a 7.0 > beta instead? Also, consider switching to "options SCHED_ULE" in the 7.0 > kernel rather than "options SCHED_4BSD". I tried 7-BETA with SHED_4BSD and id did not help. Now I'll try SHED_ULE, thanks. With best regards, Alexey Popov From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 14:43:32 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A129A16A41A for ; Mon, 19 Nov 2007 14:43:32 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 63BDF13C44B for ; Mon, 19 Nov 2007 14:43:32 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Iu7qA-0003xR-5e for freebsd-stable@freebsd.org; Mon, 19 Nov 2007 14:43:10 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 19 Nov 2007 14:43:10 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 19 Nov 2007 14:43:10 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Mon, 19 Nov 2007 15:46:51 +0100 Lines: 35 Message-ID: References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.6 (X11/20070801) In-Reply-To: <47419AB3.5030008@chistydom.ru> Sender: news Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 14:43:32 -0000 Alexey Popov wrote: > last pid: 5266; load averages: 24.67, 22.65, 17.44 up 0+03:56:38 > 17:09:37 > 121 processes: 41 running, 62 sleeping, 18 waiting > CPU states: 9.5% user, 0.0% nice, 82.0% system, 0.5% interrupt, 8.0% > idle > Mem: 439M Active, 27M Inact, 80M Wired, 108K Cache, 58M Buf, 3341M Free > Swap: 2048M Total, 2048M Free > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 5090 www -4 0 96572K 49464K RUN 5 2:59 23.39% httpd > 3748 www -4 0 96172K 50060K RUN 4 14:21 23.19% httpd > 5092 www -4 0 96412K 48060K RUN 4 2:57 23.19% httpd > 5095 www -4 0 98148K 50688K RUN 5 2:57 22.75% httpd > 5088 www -4 0 96664K 49120K RUN 4 3:02 22.56% httpd This is really unusual - the number of processes is not that high, but if I'm reading the line from systat correctly, you have unusually many context switches: r p d s w Csw Trp Sys Int Sof Flt cow 16839 total 27 1 39 137k 3390 33k 2490 313 2519 2519 zfod sio0 irq4 nginx or similar asynchronous web servers should reduce inter-process contention context switches dramatically, but you say that it didn't work as such so the problem might be somewhere else. Try sending a 10-second or so output from vmstat to confirm this problem. If you can, attach a ktrace(1) to one of the httpd processes that consumes CPU, and send the processed kdump output. Also, did you try configuring and running pecl-APC for PHP? From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 14:47:53 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DBB916A418 for ; Mon, 19 Nov 2007 14:47:53 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 6235513C4B8 for ; Mon, 19 Nov 2007 14:47:53 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 251151CC07B; Mon, 19 Nov 2007 06:47:25 -0800 (PST) Date: Mon, 19 Nov 2007 06:47:25 -0800 From: Jeremy Chadwick To: Dmitry Karasik Message-ID: <20071119144725.GA38145@eos.sc1.parodius.com> References: <20071118190159.GA12962@tetsuo.karasik.eu.org> <20071118193719.GB11901@eos.sc1.parodius.com> <84mytatzha.fsf@tetsuo.karasik.eu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84mytatzha.fsf@tetsuo.karasik.eu.org> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-stable@freebsd.org Subject: Re: No kernel messages displayed during boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 14:47:53 -0000 On Mon, Nov 19, 2007 at 09:24:01AM +0100, Dmitry Karasik wrote: > Jeremy> On Sun, Nov 18, 2007 at 08:01:59PM +0100, Dmitry Karasik wrote: > >> I've re-run 'make installworld' and 'make installkernel' (as I had > >> leftovers from recent buildworld), - didn't help. I've tried to power > >> down the machine (suspecied video card trouble), I've resetted BIOS, > >> I've even disabled com port in BIOS (because the behavior looks like > >> booting on serial console) -- nothing, absolutely nothing changes it. > > Jeremy> conscontrol(8) might help here ("conscontrol list"). Also worth > Jeremy> looking at is sysctl kern.console. > > Hello Jeremy, > > Thanks, at least this is a hint. That shows on my system: > > $ conscontrol list > Configured: > Available: > Muting: off Hmm, it looks as if the system doesn't have any indication of what the local console is. I would expect to see a "consolectl" listed under the "Configured:" section. See below for some of the output from our systems... > and sysctl kern.console is / (not that I know what that means). I believe the sysctl is a comma-delimited list of what consoles are configured and available/unused. The "/" splits what's a configured console and what's available/unused. I bet conscontrol(8) just parses the sysctl output, but I'd have to look at the code. > $ conscontrol add /dev/console > conscontrol: could not add console as a console: Device not configured > $ conscontrol add /dev/consolectl > conscontrol: could not add consolectl as a console: Device not configured > > Is that the expected behavior? What else I might try? I'm betting that's not expected behaviour. :-) It seems to indicate the system has no knowledge of what the system console is. Here's some data for comparison: Our RELENG_6 systems which use serial console, and have a /boot.config of -S115200 -Dh on them show the following: eos# conscontrol list Configured: ttyd0,consolectl Available: ttyd0,consolectl Muting: off eos# sysctl kern.console kern.console: ttyd0,consolectl,/ttyd0,consolectl, And a RELENG_7 box with serial console (same /boot.config as above): northstar# conscontrol list Configured: ttyd0,consolectl,gdb Available: consolectl,gdb,ttyd0 Muting: off northstar# sysctl kern.console kern.console: ttyd0,consolectl,gdb,/consolectl,gdb,ttyd0, A RELENG_7 box with no serial console (no /boot.config): icarus# conscontrol list Configured: consolectl Available: consolectl,gdb,ttyd0 Muting: off icarus# sysctl kern.console kern.console: consolectl,/consolectl,gdb,ttyd0, -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 14:50:23 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8470E16A419 for ; Mon, 19 Nov 2007 14:50:23 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4808A13C44B for ; Mon, 19 Nov 2007 14:50:23 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1Iu7wo-0005WN-RO for freebsd-stable@freebsd.org; Mon, 19 Nov 2007 14:50:02 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 19 Nov 2007 14:50:02 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 19 Nov 2007 14:50:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Mon, 19 Nov 2007 15:49:13 +0100 Lines: 7 Message-ID: References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.6 (X11/20070801) In-Reply-To: <47419AB3.5030008@chistydom.ru> Sender: news Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 14:50:23 -0000 Alexey Popov wrote: > CPU states: 9.5% user, 0.0% nice, 82.0% system, 0.5% interrupt, 8.0% > idle A wild idea that might not help: try reducing kern.hz in loader.conf to something like 100 and see if something significant changes. From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 14:55:45 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0934516A469; Mon, 19 Nov 2007 14:55:45 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from hermes.hw.ru (hermes.hw.ru [80.68.240.91]) by mx1.freebsd.org (Postfix) with ESMTP id 58A8513C467; Mon, 19 Nov 2007 14:55:44 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from [80.68.244.40] (account a_popov@rbc.ru [80.68.244.40] verified) by hermes.hw.ru (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 201282264; Mon, 19 Nov 2007 17:54:34 +0300 Message-ID: <4741A3A8.4010803@chistydom.ru> Date: Mon, 19 Nov 2007 17:54:32 +0300 From: Alexey Popov User-Agent: Thunderbird 2.0.0.6 (X11/20070924) MIME-Version: 1.0 To: Robert Watson References: <4741905E.8050300@chistydom.ru> <20071119140019.V80667@fledge.watson.org> In-Reply-To: <20071119140019.V80667@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 14:55:45 -0000 Hi Robert Watson wrote: > FreeBSD 7 contains significant optimization for increased numbers of > cores, and is where a lot of the work optimizing MySQL has ended up. I > see you're trying out a 6.3 beta, any chance you could try out a 7.0 > beta instead? Also, consider switching to "options SCHED_ULE" in the 7.0 > kernel rather than "options SCHED_4BSD". I tried SCHED_ULE, but got no difference: last pid: 1063; load averages: 22.75, 13.76, 6.31 up 0+00:07:24 17:53:49 56 processes: 33 running, 23 sleeping CPU states: 26.5% user, 0.0% nice, 68.1% system, 0.3% interrupt, 5.1% idle Mem: 365M Active, 20M Inact, 102M Wired, 664K Cache, 46M Buf, 3419M Free Swap: 2048M Total, 2048M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 1019 www 1 101 0 101M 51244K RUN 6 0:37 26.86% httpd 1040 www 1 -4 0 92476K 42956K RUN 1 0:36 26.76% httpd 1004 www 1 -4 0 92476K 42864K RUN 4 0:38 25.98% httpd 1018 www 1 101 0 91452K 41736K CPU3 3 0:37 25.68% httpd 1000 www 1 101 0 92476K 42544K RUN 0 0:36 25.29% httpd 1026 www 1 101 0 93500K 39900K CPU0 0 0:35 25.20% httpd 1021 www 1 101 0 101M 49432K RUN 4 0:37 25.10% httpd 1024 www 1 101 0 93500K 44416K RUN 5 0:37 25.10% httpd 1020 www 1 101 0 94524K 43684K RUN 0 0:37 25.00% httpd 1030 www 1 101 0 96576K 46004K RUN 3 0:36 25.00% httpd 1031 www 1 101 0 101M 50956K RUN 3 0:37 24.66% httpd 1025 www 1 101 0 94524K 43880K RUN 5 0:36 24.56% httpd 1041 www 1 101 0 92476K 41792K RUN 2 0:36 24.56% httpd 1022 www 1 101 0 101M 48932K RUN 5 0:36 24.27% httpd With best regards, Alexey Popov From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 15:00:06 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDAA916A421 for ; Mon, 19 Nov 2007 15:00:06 +0000 (UTC) (envelope-from toomas.aas@raad.tartu.ee) Received: from kuller.raad.tartu.ee (kuller.raad.tartu.ee [194.126.106.100]) by mx1.freebsd.org (Postfix) with ESMTP id 7DC9913C447 for ; Mon, 19 Nov 2007 15:00:06 +0000 (UTC) (envelope-from toomas.aas@raad.tartu.ee) Received: from localhost (localhost [127.0.0.1]) by kuller.raad.tartu.ee (Postfix) with ESMTP id 27C5AB81A for ; Mon, 19 Nov 2007 17:00:00 +0200 (EET) X-Virus-Scanned: amavisd-new at post.raad.tartu.ee Received: from kuller.raad.tartu.ee ([127.0.0.1]) by localhost (kuller.raad.tartu.ee [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fd6JbgZQfPRp for ; Mon, 19 Nov 2007 16:59:58 +0200 (EET) Received: from raad.tartu.ee (lv.raad.tartu.ee [194.126.106.110]) by kuller.raad.tartu.ee (Postfix) with ESMTP id 0E3D5B817 for ; Mon, 19 Nov 2007 16:59:57 +0200 (EET) Received: from INFO/SpoolDir by raad.tartu.ee (Mercury 1.48); 19 Nov 07 16:59:58 +0200 Received: from SpoolDir by INFO (Mercury 1.48); 19 Nov 07 16:59:56 +0200 Received: from [172.26.1.6] (172.26.1.6) by raad.tartu.ee (Mercury 1.48) with ESMTP; 19 Nov 07 16:59:48 +0200 Message-ID: <4745995D.7020704@raad.tartu.ee> Date: Thu, 22 Nov 2007 16:59:41 +0200 From: Toomas Aas User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <474577B9.7090104@raad.tartu.ee> In-Reply-To: <474577B9.7090104@raad.tartu.ee> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: garbled gjournal messages in dmesg with 7.0-BETA3 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 15:00:06 -0000 Toomas Aas wrote: > kernel: GEOM_JOURNAL: Journal 3372893522: aacd1s3G EcOoMn_tJaOiUnRsN > AdLa:t aB.IO > kernel: _GFELOUMS_HJ OnUoRtN AsLu:p pJoorutrenda lb y 3a3a7c2d819s325.22 Looking more closely at this 'garbage' I just noticed that this is actually two messages 'mixed' together. If you read skipping one letter, the first line has: aacd1s3 contains data. GEOM_JOURNAL: BIO and the second line has: _FLUSH not supported by aacd1s2. GEOM_JOURNAL: Journal 3372893522 Interesting children's cryptography :) -- Toomas Aas From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 15:13:03 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A08316A468; Mon, 19 Nov 2007 15:13:03 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from hermes.hw.ru (hermes.hw.ru [80.68.240.91]) by mx1.freebsd.org (Postfix) with ESMTP id 3133013C43E; Mon, 19 Nov 2007 15:13:01 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from [80.68.244.40] (account a_popov@rbc.ru [80.68.244.40] verified) by hermes.hw.ru (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 201286763; Mon, 19 Nov 2007 18:12:28 +0300 Message-ID: <4741A7DA.2050706@chistydom.ru> Date: Mon, 19 Nov 2007 18:12:26 +0300 From: Alexey Popov User-Agent: Thunderbird 2.0.0.6 (X11/20070924) MIME-Version: 1.0 To: Ivan Voras References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> In-Reply-To: Content-Type: multipart/mixed; boundary="------------020408070004010709000809" Cc: freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 15:13:03 -0000 This is a multi-part message in MIME format. --------------020408070004010709000809 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi. Ivan Voras wrote: >> CPU states: 9.5% user, 0.0% nice, 82.0% system, 0.5% interrupt, 8.0% >> idle > A wild idea that might not help: try reducing kern.hz in loader.conf to > something like 100 and see if something significant changes. Now it runs with hz=100, number of context switches became ~ 2 times less, but still there's 90% system CPU load (see attach). With best regards, Alexey Popov --------------020408070004010709000809 Content-Type: text/plain; name="vmstat.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="vmstat.txt" ICAgIDEgdXNlcnMgICAgTG9hZCAxNi4zNiAxMi4yNCAgNi4xNCAgICAgICAgICAgICAgICAg IE5vdiAxOSAxODowOAoKTWVtOktCICAgIFJFQUwgICAgICAgICAgICBWSVJUVUFMICAgICAg ICAgICAgICAgICAgICAgICBWTiBQQUdFUiAgIFNXQVAgUEFHRVIKICAgICAgICBUb3QgICBT aGFyZSAgICAgIFRvdCAgICBTaGFyZSAgICBGcmVlICAgICAgICAgICBpbiAgIG91dCAgICAg aW4gICBvdXQKQWN0ICAzNjY5ODggICAxNjk1MiAgIDgzNDI4OCAgICAzNzI0OCAzNTE1NjI0 ICBjb3VudCAgICAgMQpBbGwgIDQyMzIyOCAgIDE4NDcyICA1MDg5NTY4ICAgIDQxMTQ0ICAg ICAgICAgIHBhZ2VzICAgICA0ClByb2M6ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSW50ZXJydXB0cwogIHIgICBwICAgZCAg IHMgICB3ICAgQ3N3ICBUcnAgIFN5cyAgSW50ICBTb2YgIEZsdCAgICAgIDEgY293ICAgIDM5 MTcgdG90YWwKIDMxICAgICAgICAgIDI0ICAgICAgIDk4ayAgMzVrICA5NWsgMjMxNSAgMTAw ICAyOWsgIDI5OTE5IHpmb2QgICAgICAgIHNpbzAgaXJxNAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgb3pmb2QgICAgICAgYXRh MCBpcnExNAo0OC42JVN5cyAgIDEuMCVJbnRyIDQ5LjUlVXNlciAgMC4wJU5pY2UgIDEuMCVJ ZGxlICAgICAgICAlb3pmb2QgICAgIDUgbWZpMCBpcnExOAp8ICAgIHwgICAgfCAgICB8ICAg IHwgICAgfCAgICB8ICAgIHwgICAgfCAgICB8ICAgIHwgICAgICAgZGFlZnIgICAgICAgdWhj aTAgdWhjaQo9PT09PT09PT09PT09PT09PT09PT09PT0rPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+PiAgIDE3MDkgcHJjZnIgICAyMDAgY3B1MDogdGltZQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDQgZHRidWYgICAgMjMxNDAgdG90ZnIgIDIzMTEgZW0w IGlycTI1NgpOYW1laSAgICAgTmFtZS1jYWNoZSAgIERpci1jYWNoZSAgICAxMDAwMDAgZGVz dm4gICAgICAgICAgcmVhY3QgICAyMDAgY3B1MjogdGltZQogICBDYWxscyAgICBoaXRzICAg JSAgICBoaXRzICAgJSAgICAgIDE0OTQgbnVtdm4gICAgICAgICAgcGR3YWsgICAyMDAgY3B1 MzogdGltZQogIDE0NzUxNyAgMTQ3NTE0IDEwMCAgICAgICAgICAgICAgICAgICAxNTggZnJl dm4gICAgICAgICAgcGRwZ3MgICAyMDAgY3B1MTogdGltZQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW50cm4gICAyMDAgY3B1 NDogdGltZQpEaXNrcyBtZmlkMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAxMDY4NDAgd2lyZSAgICAyMDAgY3B1NzogdGltZQpLQi90ICAyMC4yMCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAzNTU3MjAgYWN0ICAgICAyMDEgY3B1 NTogdGltZQp0cHMgICAgICAgNSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgMjEyNDggaW5hY3QgICAyMDAgY3B1NjogdGltZQpNQi9zICAgMC4xMCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDEyMjggY2FjaGUKJWJ1c3kgICAg IDEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAzNTE0NzkyIGZyZWUK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDY1 MDU2IGJ1ZgoKCgoKCg== --------------020408070004010709000809-- From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 15:14:59 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90D0516A46C for ; Mon, 19 Nov 2007 15:14:59 +0000 (UTC) (envelope-from dk@tetsuo.karasik.eu.org) Received: from tetsuo.karasik.eu.org (tetsuo.karasik.eu.org [129.142.67.14]) by mx1.freebsd.org (Postfix) with ESMTP id 5674F13C481 for ; Mon, 19 Nov 2007 15:14:58 +0000 (UTC) (envelope-from dk@tetsuo.karasik.eu.org) Received: by tetsuo.karasik.eu.org (Postfix, from userid 1003) id F2320616980; Mon, 19 Nov 2007 16:14:39 +0100 (CET) Mime-version: 1.0 Content-type: text/plain; charset="koi8-r" Content-transfer-encoding: 8bit Keywords: 2001334874 X-Comment-To: Jeremy Chadwick Sender: dk@tetsuo.karasik.eu.org To: freebsd-stable@freebsd.org References: <20071118190159.GA12962@tetsuo.karasik.eu.org> <20071118193719.GB11901@eos.sc1.parodius.com> <84mytatzha.fsf@tetsuo.karasik.eu.org> <20071119144725.GA38145@eos.sc1.parodius.com> From: Dmitry Karasik In-Reply-To: Jeremy Chadwick's message of "Mon, 19 Nov 2007 06:47:25 -0800" Date: 19 Nov 2007 16:14:39 +0100 Message-ID: <84zlxas1wg.fsf@tetsuo.karasik.eu.org> Lines: 48 X-Mailer: Gnus v5.7/Emacs 20.7 Subject: Re: No kernel messages displayed during boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 15:14:59 -0000 Jeremy> Hmm, it looks as if the system doesn't have any indication of what Jeremy> the local console is. I would expect to see a "consolectl" listed Jeremy> under the "Configured:" section. See below for some of the output Jeremy> from our systems... Hi Jeremy, Thanks for your advice, I've started to dig deeper and deeper until I found that it was boot0 loader's fault. Strange as it sounds, it is the only plausible explanation I can think of, because of the all strange effects I've encountered. First, the problem went away when I've replaced /boot/loader with a freshly compiled one. But the interesting part was, that the change to the new loader caused a prompt for the location of /boot/loader on the next reboot (note, no -a in loader.conf!). Next reboots went just fine. The interesting stuff began when I reverted the loader back, and it worked - but again, first time it prompted the input, and worked afterwards. This pattern with flipping old and new loaders back and forth actually was reproducible, and most fun of it all, also under qemu, which I used to save time and used the same /dev/ad4 my system lives on, but in read-only mode. The fact that that action chain actually presisted between reboots in qemu on a read-only device -- I don't know, I simply have no explanation to this. As a last resort, I've re-run boot0cfg -B , and voila, everything started worked fine, and the loader prompt effect disappeared. I'm thinking that something corrupted my MBR in such a nasty way that some boot0's memory, possibly boot flags word (-a, -D etc boot_ flags found in loader.conf) , thought of having been initialized to zero, was not. I tried to look at the source of boot0, but couldn't figure out first if that's an issue here at all, and second, if that behavior would be desirable (after all, the code must be 512 bytes max). Nevertheless, that effect was really spooky - imagine a stray bit in MBR turns off whole console logging! And at last - the machine crashed when I tried to write on msdosfs mounted on /dev/md0. Apparently it wrote something it shouldn't in the MBR. And I tried to write on msdosfs while trying to figure out if my old msdosfs kernel PR #47628 is still actual under 6.2. If anyone's willing to try that, (the PR has perl script attached, http://www.freebsd.org/cgi/query-pr.cgi?pr=47628), you're very welcome. Just back up your MBR first :) -- Sincerely, Dmitry Karasik From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 15:22:38 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2970216A417 for ; Mon, 19 Nov 2007 15:22:38 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smtp-out2.tiscali.nl (smtp-out2.tiscali.nl [195.241.79.177]) by mx1.freebsd.org (Postfix) with ESMTP id AA5DC13C4B8 for ; Mon, 19 Nov 2007 15:22:37 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from [195.241.149.28] (helo=guido.klop.ws) by smtp-out2.tiscali.nl with smtp (Tiscali http://www.tiscali.nl) id 1Iu89s-0003jG-Az for ; Mon, 19 Nov 2007 16:03:32 +0100 Received: (qmail 2663 invoked from network); 19 Nov 2007 15:03:29 -0000 Received: from localhost (HELO guido.klop.ws) (127.0.0.1) by localhost with SMTP; 19 Nov 2007 15:03:29 -0000 Date: Mon, 19 Nov 2007 16:03:27 +0100 To: freebsd-stable@freebsd.org From: "Ronald Klop" Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 References: <4741905E.8050300@chistydom.ru> <20071119140019.V80667@fledge.watson.org> <4741A3A8.4010803@chistydom.ru> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <4741A3A8.4010803@chistydom.ru> User-Agent: Opera Mail/9.24 (FreeBSD) Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 15:22:38 -0000 On Mon, 19 Nov 2007 15:54:32 +0100, Alexey Popov wrote: > Hi > > Robert Watson wrote: >> FreeBSD 7 contains significant optimization for increased numbers of >> cores, and is where a lot of the work optimizing MySQL has ended up. I >> see you're trying out a 6.3 beta, any chance you could try out a 7.0 >> beta instead? Also, consider switching to "options SCHED_ULE" in the >> 7.0 kernel rather than "options SCHED_4BSD". > I tried SCHED_ULE, but got no difference: > > last pid: 1063; load averages: 22.75, 13.76, 6.31 up 0+00:07:24 > 17:53:49 > 56 processes: 33 running, 23 sleeping > CPU states: 26.5% user, 0.0% nice, 68.1% system, 0.3% interrupt, 5.1% > idle > Mem: 365M Active, 20M Inact, 102M Wired, 664K Cache, 46M Buf, 3419M Free > Swap: 2048M Total, 2048M Free > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU > COMMAND > 1019 www 1 101 0 101M 51244K RUN 6 0:37 26.86% httpd > 1040 www 1 -4 0 92476K 42956K RUN 1 0:36 26.76% httpd > 1004 www 1 -4 0 92476K 42864K RUN 4 0:38 25.98% httpd > 1018 www 1 101 0 91452K 41736K CPU3 3 0:37 25.68% httpd > 1000 www 1 101 0 92476K 42544K RUN 0 0:36 25.29% httpd > 1026 www 1 101 0 93500K 39900K CPU0 0 0:35 25.20% httpd > 1021 www 1 101 0 101M 49432K RUN 4 0:37 25.10% httpd > 1024 www 1 101 0 93500K 44416K RUN 5 0:37 25.10% httpd > 1020 www 1 101 0 94524K 43684K RUN 0 0:37 25.00% httpd > 1030 www 1 101 0 96576K 46004K RUN 3 0:36 25.00% httpd > 1031 www 1 101 0 101M 50956K RUN 3 0:37 24.66% httpd > 1025 www 1 101 0 94524K 43880K RUN 5 0:36 24.56% httpd > 1041 www 1 101 0 92476K 41792K RUN 2 0:36 24.56% httpd > 1022 www 1 101 0 101M 48932K RUN 5 0:36 24.27% httpd You have a lot of free memory. Maybe you can wait a little to let it fill the cache or let it use more buf's. This could explain that the system is spending a lot if time in 'system'. Ronald. -- Ronald Klop Amsterdam, The Netherlands From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 15:24:20 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CA6B16A41B; Mon, 19 Nov 2007 15:24:20 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 674F613C467; Mon, 19 Nov 2007 15:24:20 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id B265247523; Mon, 19 Nov 2007 10:26:37 -0500 (EST) Date: Mon, 19 Nov 2007 15:24:02 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Alexey Popov , kris@FreeBSD.org In-Reply-To: <4741A3A8.4010803@chistydom.ru> Message-ID: <20071119152214.J80667@fledge.watson.org> References: <4741905E.8050300@chistydom.ru> <20071119140019.V80667@fledge.watson.org> <4741A3A8.4010803@chistydom.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 15:24:20 -0000 On Mon, 19 Nov 2007, Alexey Popov wrote: > Robert Watson wrote: >> FreeBSD 7 contains significant optimization for increased numbers of cores, >> and is where a lot of the work optimizing MySQL has ended up. I see you're >> trying out a 6.3 beta, any chance you could try out a 7.0 beta instead? >> Also, consider switching to "options SCHED_ULE" in the 7.0 kernel rather >> than "options SCHED_4BSD". > I tried SCHED_ULE, but got no difference: Did you see no change in throughput, or no change in reported CPU use? We should probably take this thread to performance@ and get Kris involved. He may be interested in trying to reproduce your workload in our testbed so we can perform measurements of our own, as well as getting you to provide profiling information. One of the things we'd most like to have are nice potted benchmarks for real-world workloads, as that allows us to easily replay them, perform measurements, optimize, etc. Thanks, Robert N M Watson Computer Laboratory University of Cambridge > > last pid: 1063; load averages: 22.75, 13.76, 6.31 up 0+00:07:24 > 17:53:49 > 56 processes: 33 running, 23 sleeping > CPU states: 26.5% user, 0.0% nice, 68.1% system, 0.3% interrupt, 5.1% idle > Mem: 365M Active, 20M Inact, 102M Wired, 664K Cache, 46M Buf, 3419M Free > Swap: 2048M Total, 2048M Free > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 1019 www 1 101 0 101M 51244K RUN 6 0:37 26.86% httpd > 1040 www 1 -4 0 92476K 42956K RUN 1 0:36 26.76% httpd > 1004 www 1 -4 0 92476K 42864K RUN 4 0:38 25.98% httpd > 1018 www 1 101 0 91452K 41736K CPU3 3 0:37 25.68% httpd > 1000 www 1 101 0 92476K 42544K RUN 0 0:36 25.29% httpd > 1026 www 1 101 0 93500K 39900K CPU0 0 0:35 25.20% httpd > 1021 www 1 101 0 101M 49432K RUN 4 0:37 25.10% httpd > 1024 www 1 101 0 93500K 44416K RUN 5 0:37 25.10% httpd > 1020 www 1 101 0 94524K 43684K RUN 0 0:37 25.00% httpd > 1030 www 1 101 0 96576K 46004K RUN 3 0:36 25.00% httpd > 1031 www 1 101 0 101M 50956K RUN 3 0:37 24.66% httpd > 1025 www 1 101 0 94524K 43880K RUN 5 0:36 24.56% httpd > 1041 www 1 101 0 92476K 41792K RUN 2 0:36 24.56% httpd > 1022 www 1 101 0 101M 48932K RUN 5 0:36 24.27% httpd > > With best regards, > Alexey Popov > From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 16:04:57 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECC6016A505; Mon, 19 Nov 2007 16:04:57 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from hermes.hw.ru (hermes.hw.ru [80.68.240.91]) by mx1.freebsd.org (Postfix) with ESMTP id 15A7413C457; Mon, 19 Nov 2007 16:04:56 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from [80.68.244.40] (account a_popov@rbc.ru [80.68.244.40] verified) by hermes.hw.ru (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 201299938; Mon, 19 Nov 2007 19:03:44 +0300 Message-ID: <4741B3DE.2000009@chistydom.ru> Date: Mon, 19 Nov 2007 19:03:42 +0300 From: Alexey Popov User-Agent: Thunderbird 2.0.0.6 (X11/20070924) MIME-Version: 1.0 To: Ivan Voras References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 16:04:58 -0000 Hi. Ivan Voras wrote: >> last pid: 5266; load averages: 24.67, 22.65, 17.44 up 0+03:56:38 >> 121 processes: 41 running, 62 sleeping, 18 waiting >> CPU states: 9.5% user, 0.0% nice, 82.0% system, 0.5% interrupt, 8.0% >> idle > This is really unusual - the number of processes is not that high, but > if I'm reading the line from systat correctly, you have unusually many > context switches: > r p d s w Csw Trp Sys Int Sof Flt cow 16839 total > 27 1 39 137k 3390 33k 2490 313 2519 2519 zfod > sio0 irq4 > nginx or similar asynchronous web servers should reduce inter-process > contention context switches dramatically, but you say that it didn't > work as such so the problem might be somewhere else. > Try sending a 10-second or so output from vmstat to confirm this problem. Yes, there's really many context switches: %vmstat 1 procs memory page disk faults cpu r b w avm fre flt re pi po fr sr mf0 in sy cs us sy id 23 1 0 615284 3581456 15980 0 0 0 15964 0 0 1414 58211 115230 25 60 15 24 0 0 631668 3564976 9940 0 0 0 5793 0 0 664 30036 158059 11 79 10 20 0 0 655220 3545516 22146 0 0 0 16731 0 0 1992 77638 116627 31 65 4 23 0 0 622452 3579700 18248 0 0 0 27451 0 0 1839 80646 115798 38 59 3 15 9 0 614260 3587484 4795 0 0 0 6765 0 0 352 23938 159993 6 83 11 21 0 0 625524 3567948 10154 0 0 0 5308 0 0 653 32718 159119 11 81 8 13 3 0 627572 3571924 15266 0 0 0 16278 0 0 1031 50321 142111 20 69 11 21 0 0 605044 3591860 9008 0 0 0 14021 0 0 873 42083 160441 13 79 8 19 1 0 611188 3593404 7498 0 0 0 7920 0 0 489 30012 158176 10 77 13 24 0 0 610164 3592360 5855 0 0 0 5602 0 0 666 26627 162937 8 81 11 20 3 0 622452 3587456 6372 0 0 0 5144 0 0 362 23705 161257 10 81 10 ^C % > If you can, attach a ktrace(1) to one of the httpd processes that > consumes CPU, and send the processed kdump output. Here is it: http://83.167.98.162/gprof/kdump.txt.gz > Also, did you try configuring and running pecl-APC for PHP?'s I'm using eAccelerator. Again, the same soft works good on less-CPU system and on Linux. With best regards, Alexey Popov From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 16:14:33 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5086216A419; Mon, 19 Nov 2007 16:14:33 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from phoebe.cse.buffalo.edu (phoebe.cse.buffalo.edu [128.205.32.89]) by mx1.freebsd.org (Postfix) with ESMTP id 0BF6A13C4AC; Mon, 19 Nov 2007 16:14:32 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) (authenticated bits=0) by phoebe.cse.buffalo.edu (8.14.1/8.13.7) with ESMTP id lAJGEGwS089806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Nov 2007 11:14:16 -0500 (EST) (envelope-from kensmith@cse.buffalo.edu) From: Ken Smith To: freebsd-stable , freebsd-current@freebsd.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-JpNoLuPrIL5CYiVLMgBI" Organization: U. Buffalo CSE Department Date: Mon, 19 Nov 2007 11:14:16 -0500 Message-Id: <1195488856.19739.42.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 FreeBSD GNOME Team Port X-DCC-Buffalo.EDU-Metrics: phoebe.cse.buffalo.edu 1335; Body=0 Fuz1=0 X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on phoebe.cse.buffalo.edu Cc: Subject: FreeBSD 7.0-BETA3 Available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 16:14:33 -0000 --=-JpNoLuPrIL5CYiVLMgBI Content-Type: text/plain Content-Transfer-Encoding: quoted-printable The 7.0-BETA3 builds are now available. If you would like to download an ISO image to install from they are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases//ISO-IMAGES/7.0/ (adjust to be your architecture, e.g. amd64, i386, etc.). If you would like to use cvsup to update an older machine the release tag is still RELENG_7. Checksums for the ISO files: MD5 (7.0-BETA3-amd64-bootonly.iso) =3D d3727590cdc07bc00ed4b8c70d882ffc MD5 (7.0-BETA3-amd64-disc1.iso) =3D f747c3e8c38f4b2486a28927120918b9 MD5 (7.0-BETA3-amd64-disc2.iso) =3D 8be4203cdb7c9c886fab9fe825586532 MD5 (7.0-BETA3-amd64-docs.iso) =3D 036c8529639f42667fb13b168bb62fd7 MD5 (7.0-BETA3-amd64-livefs.iso) =3D 4c132e37b3791d9c3667a26893ef164a MD5 (7.0-BETA3-i386-bootonly.iso) =3D 87d311072e75d83ec6f3fd757f23c5bb MD5 (7.0-BETA3-i386-disc1.iso) =3D e1f1fb8a233b4e48b9b57064e2287fb0 MD5 (7.0-BETA3-i386-disc2.iso) =3D 710482b33f37a4fecd247faaa0b0f76c MD5 (7.0-BETA3-i386-docs.iso) =3D 8e420fe99237d8c9d54f6afa079558b5 MD5 (7.0-BETA3-i386-livefs.iso) =3D 3ce12b63ed61d733b20c7432c00896e6 MD5 (7.0-BETA3-ia64-bootonly.iso) =3D 01d13c5ba7b8e939d717a08f43b160b0 MD5 (7.0-BETA3-ia64-disc1.iso) =3D 566ac5bc9bbe38be9df6eeed297444e8 MD5 (7.0-BETA3-ia64-disc2.iso) =3D 45f0045e057e5d76dc11598467a6745e MD5 (7.0-BETA3-ia64-docs.iso) =3D 3dd593b39c81c635b1404701fc042031 MD5 (7.0-BETA3-ia64-livefs.iso) =3D d62fee94d11be9bce1929f4e006d8865 MD5 (7.0-BETA3-pc98-bootonly.iso) =3D 4f03a75e3c5df7efc3868c300b48ba17 MD5 (7.0-BETA3-pc98-disc1.iso) =3D d94e1adff058e9b11160014d78444d2c MD5 (7.0-BETA3-pc98-livefs.iso) =3D 025bbc6400724ddfc49b5ce0860d2394 MD5 (7.0-BETA3-powerpc-bootonly.iso) =3D bfd4d07be776811e50d7706bbdc49518 MD5 (7.0-BETA3-powerpc-disc1.iso) =3D b44fcac04742856f9af5f54eddac46e9 MD5 (7.0-BETA3-powerpc-disc2.iso) =3D 1721b82f3ae2114b3c1e345c97e75f27 MD5 (7.0-BETA3-powerpc-docs.iso) =3D 7e8a460ea6bf432d8bdffe098f87bed7 MD5 (7.0-BETA3-sparc64-bootonly.iso) =3D 4bde71a072c042a9e5617d48188eace4 MD5 (7.0-BETA3-sparc64-disc1.iso) =3D f3ffc1caf127d81e72bdaa807b1c4de8 MD5 (7.0-BETA3-sparc64-disc2.iso) =3D 807c61cac4bda259c7f3513d3f9ae781 MD5 (7.0-BETA3-sparc64-docs.iso) =3D 92b55a7ed6f816530eb8f26422e3d0be SHA256 (7.0-BETA3-amd64-bootonly.iso) =3D 50a90064b6bddc14ec4c9fd40ae9d0713= 221a76b7fd7cd3355a3f09319487ede SHA256 (7.0-BETA3-amd64-disc1.iso) =3D 55c80f76039996406773e87b909b472693a8= d93c9cdc880fb4516b219236040e SHA256 (7.0-BETA3-amd64-disc2.iso) =3D 2f58909abf46b114ed49bf47d8e7d4d66c0c= 524c617f116f3ce5a12976d0285c SHA256 (7.0-BETA3-amd64-docs.iso) =3D ef4a6cad6399c94bca3fdb3bb5243f8e56555= 4955f4e94b0068e7214d3aa379b SHA256 (7.0-BETA3-amd64-livefs.iso) =3D 64d61b795bb3c358e38f61cc44ef70ea1ab= d6b3cdc710f79b9da3acf9485ad51 SHA256 (7.0-BETA3-i386-bootonly.iso) =3D e3895aa4d9570634465ba7132489b45dab= e19cf44638a97f14f577b6a465690b SHA256 (7.0-BETA3-i386-disc1.iso) =3D 082e00e6c8142e0c539f128311968fef443ac= 930702e567918a0dd758c09711f SHA256 (7.0-BETA3-i386-disc2.iso) =3D 70b66b100618ccab7a91c96c3312aa443f3ff= 904a7b290fecbc5bef3a35fc248 SHA256 (7.0-BETA3-i386-docs.iso) =3D 9bd6c09b8abd3f6e7243c3847168e74ad27e0e= 364b810ea19dedc10a1410af8c SHA256 (7.0-BETA3-i386-livefs.iso) =3D 177df8430a19b44f49b3dcc9be424bf0b74b= 270baf953f124633ba4ecab2d690 SHA256 (7.0-BETA3-ia64-bootonly.iso) =3D d25436d7be92b262253ce127b1e752c097= f9cc38561f78245f70e879b3af976e SHA256 (7.0-BETA3-ia64-disc1.iso) =3D 90c2b3611daf76000e7608672797235f234e1= 85f09fa36a1f13738361df0aeb8 SHA256 (7.0-BETA3-ia64-disc2.iso) =3D 6d5a3bbdd9808cf8efa9e3532ed386c604151= a6f071d85c751c260442f3fee52 SHA256 (7.0-BETA3-ia64-docs.iso) =3D 86d823f7f555635ccd4e91af31ec68e35d5dc8= 93fab04027e0f764911e73b5d8 SHA256 (7.0-BETA3-ia64-livefs.iso) =3D 2f8b156ffdc068eb09aa37742213e24d417d= f6387e903ed699ebac39ba61ba66 SHA256 (7.0-BETA3-pc98-bootonly.iso) =3D 4758018dca3ecebea0dc5d4b7c16ae4a4d= 2da668cb1ad0a5ab2363c890888f51 SHA256 (7.0-BETA3-pc98-disc1.iso) =3D d43a77a86c1294425e6f3504a5dd14d42f581= f800374ab2f1e0dca548db43abb SHA256 (7.0-BETA3-pc98-livefs.iso) =3D 33bf52a412c95983361307a6dc553f32d8e5= be7d0bc90199ef083b2e8caebb9c SHA256 (7.0-BETA3-powerpc-bootonly.iso) =3D 7d4b08c145c3c3b98ae603d6e2bb347= 88f8556c3027de041810a32b72b79dfe4 SHA256 (7.0-BETA3-powerpc-disc1.iso) =3D 8affc16a226d98166f9fa7b8b48965c537= b187a9fb13b84502a524746af4b9ac SHA256 (7.0-BETA3-powerpc-disc2.iso) =3D ca4ac30eb3a3241506a76cc3ad4ff9658f= 37b28e7bd0d6dc6f64e5938bef3be2 SHA256 (7.0-BETA3-powerpc-docs.iso) =3D 2603429f005d31623f59d47f2b198ef51fe= 6d300441dc6651be462d3359cc2db SHA256 (7.0-BETA3-sparc64-bootonly.iso) =3D 5db551ed17c9d075c65048128478580= e9feb95a83440bc9391da4eb514ba6783 SHA256 (7.0-BETA3-sparc64-disc1.iso) =3D 220cac1aa26537521f67333a4ece03ab2e= df87b443142276ca8d28b7da162c44 SHA256 (7.0-BETA3-sparc64-disc2.iso) =3D 15726eef5ecb1b4177644aa3717ee3736c= 13bb6dc372d7913fe1784496bb2371 SHA256 (7.0-BETA3-sparc64-docs.iso) =3D a32dda230c6fb654d906d48c8ad5c5ca5a4= 0ea176939f320b614b6b1df1957c3 --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-JpNoLuPrIL5CYiVLMgBI Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBHQbZY/G14VSmup/YRAkqiAJwMW8794ZuGEC+KG9Uw35fHitvC0wCfXPwn VcKutEabDxZ8/CpTXKb6DAU= =OHI2 -----END PGP SIGNATURE----- --=-JpNoLuPrIL5CYiVLMgBI-- From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 16:14:52 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EAF516A533; Mon, 19 Nov 2007 16:14:52 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from hermes.hw.ru (hermes.hw.ru [80.68.240.91]) by mx1.freebsd.org (Postfix) with ESMTP id B22EA13C4B8; Mon, 19 Nov 2007 16:14:51 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from [80.68.244.40] (account a_popov@rbc.ru [80.68.244.40] verified) by hermes.hw.ru (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 201302437; Mon, 19 Nov 2007 19:14:02 +0300 Message-ID: <4741B648.7090002@chistydom.ru> Date: Mon, 19 Nov 2007 19:14:00 +0300 From: Alexey Popov User-Agent: Thunderbird 2.0.0.6 (X11/20070924) MIME-Version: 1.0 To: Robert Watson References: <4741905E.8050300@chistydom.ru> <20071119140019.V80667@fledge.watson.org> <4741A3A8.4010803@chistydom.ru> <20071119152214.J80667@fledge.watson.org> In-Reply-To: <20071119152214.J80667@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kris@FreeBSD.org, freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 16:14:52 -0000 Hi. Robert Watson wrote: >> I tried SCHED_ULE, but got no difference: > Did you see no change in throughput, or no change in reported CPU use? No significant changes. > We should probably take this thread to performance@ and get Kris > involved. He may be interested in trying to reproduce your workload in > our testbed so we can perform measurements of our own, as well as > getting you to provide profiling information. One of the things we'd > most like to have are nice potted benchmarks for real-world workloads, > as that allows us to easily replay them, perform measurements, optimize, > etc. I can provide all profiling or configuration information you ask for. Except I can't provide PHP site source codes. Now I'm in situation that I can't install FreeBSD on all new servers because they are all based on 2xquad-core processors and I can't be sure it would work good. With best regards, Alexey Popov From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 16:27:26 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F41F16A419 for ; Mon, 19 Nov 2007 16:27:26 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id 03BB613C469 for ; Mon, 19 Nov 2007 16:27:25 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id 7073715C16; Mon, 19 Nov 2007 18:27:15 +0200 (EET) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28137-01; Mon, 19 Nov 2007 18:27:13 +0200 (EET) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id 8103415C11; Mon, 19 Nov 2007 18:27:13 +0200 (EET) Message-ID: <4741B95F.4020705@bulinfo.net> Date: Mon, 19 Nov 2007 18:27:11 +0200 From: Krassimir Slavchev User-Agent: Thunderbird 2.0.0.6 (X11/20070927) MIME-Version: 1.0 To: Alexey Popov References: <4741905E.8050300@chistydom.ru> In-Reply-To: <4741905E.8050300@chistydom.ru> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net Cc: freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 16:27:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All, What version of apache do you use and what are: StartServers MinSpareServers MaxSpareServers MaxClients KeepAliveTimeout settings in both configurations? Best Regards Alexey Popov wrote: > Hi. > > I have a large pool of web backends (Apache + mod_php5) with > 2 x Xeon 3.2GHz processors and 2 x Xeon 5120 dual-core processors. The > workload is mostly CPU-bound. I'm using 6-STABLE-amd64 and also tried > 7-STABLE. > > Now I'm trying to use new hardware with 2 x Xeon 5320 (quad-core), but > it can not work under the same load as dual-core. It shows up to 80% > system CPU load in top: > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHQblfxJBWvpalMpkRAgTQAJ4uy8qhmpCVWevAI0LSYXPrXiIUSQCeNE8y +dkavLoDzqrILkqVGZNZZDM= =xI6R -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 16:35:49 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4095816A473 for ; Mon, 19 Nov 2007 16:35:49 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from pd3mo2so.prod.shaw.ca (idcmail-mo1so.shaw.ca [24.71.223.10]) by mx1.freebsd.org (Postfix) with ESMTP id 2480213C4C4 for ; Mon, 19 Nov 2007 16:35:46 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from pd3mr1so.prod.shaw.ca (pd3mr1so-qfe3.prod.shaw.ca [10.0.141.177]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0JRR003YVI3AHC10@l-daemon> for freebsd-stable@freebsd.org; Mon, 19 Nov 2007 09:35:34 -0700 (MST) Received: from pn2ml8so.prod.shaw.ca ([10.0.121.152]) by pd3mr1so.prod.shaw.ca (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) with ESMTP id <0JRR0092GI38HD00@pd3mr1so.prod.shaw.ca> for freebsd-stable@freebsd.org; Mon, 19 Nov 2007 09:35:33 -0700 (MST) Received: from hexahedron.daemonology.net ([24.82.201.197]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with SMTP id <0JRR00LV3I37IY10@l-daemon> for freebsd-stable@freebsd.org; Mon, 19 Nov 2007 09:35:32 -0700 (MST) Received: (qmail 14263 invoked from network); Mon, 19 Nov 2007 16:35:17 +0000 Received: from unknown (HELO hexahedron.daemonology.net) (127.0.0.1) by localhost with SMTP; Mon, 19 Nov 2007 16:35:17 +0000 Date: Mon, 19 Nov 2007 08:35:16 -0800 From: Colin Percival In-reply-to: <1195488856.19739.42.camel@bauer.cse.buffalo.edu> To: freebsd-stable , freebsd-current@freebsd.org Message-id: <4741BB44.7010906@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Enigmail-Version: 0.95.5 References: <1195488856.19739.42.camel@bauer.cse.buffalo.edu> User-Agent: Thunderbird 2.0.0.9 (X11/20071117) Cc: Subject: Re: FreeBSD 7.0-BETA3 Available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 16:35:49 -0000 Ken Smith wrote: > The 7.0-BETA3 builds are now available. If you would like to download > an ISO image to install from they are available here: > > ftp://ftp.freebsd.org/pub/FreeBSD/releases//ISO-IMAGES/7.0/ > > (adjust to be your architecture, e.g. amd64, i386, etc.). If you > would like to use cvsup to update an older machine the release tag is > still RELENG_7. Due to a communications mix-up, it isn't yet possible to upgrade to 7.0-BETA3 using FreeBSD Update -- the bits are being assembled as I type this and binary upgrading to 7.0-BETA3 should work by the end of the day. For those of you who didn't read my earlier announcement and have no idea what I'm talking about, upgrading instructions are at http://www.daemonology.net/blog/2007-11-11-freebsd-major-version-upgrade.html for upgrading from 6.x to 7.0-BETA3, and at http://www.daemonology.net/blog/2007-11-10-freebsd-minor-version-upgrade.html for upgrading from 7.0-BETA1.5 or 7.0-BETA2 to 7.0-BETA3. Colin Percival FreeBSD Security Officer & FreeBSD Update wrangler From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 17:50:17 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CAC116A417 for ; Mon, 19 Nov 2007 17:50:17 +0000 (UTC) (envelope-from mistry.7@osu.edu) Received: from mail.united-ware.com (am-productions.biz [69.61.164.22]) by mx1.freebsd.org (Postfix) with ESMTP id CC8BD13C468 for ; Mon, 19 Nov 2007 17:50:15 +0000 (UTC) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.100] (adsl-68-252-59-152.dsl.wotnoh.ameritech.net [68.252.59.152]) (authenticated bits=0) by mail.united-ware.com (8.13.8/8.13.8) with ESMTP id lAJHtciq009554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Nov 2007 12:55:39 -0500 (EST) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: "[LoN]Kamikaze" Date: Mon, 19 Nov 2007 12:53:58 -0500 User-Agent: KMail/1.9.7 References: <200710171228.39123.mistry.7@osu.edu> <472ED12B.7040200@gmx.de> <200711070953.22154.mistry.7@osu.edu> In-Reply-To: <200711070953.22154.mistry.7@osu.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2125277.RqjLeX6XHG"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200711191254.08134.mistry.7@osu.edu> X-Virus-Scanned: ClamAV 0.91.2/4841/Sun Nov 18 23:25:36 2007 on mail.united-ware.com X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_7 jerky mouse and skipping sound (still a problem -BETA3) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 17:50:17 -0000 --nextPart2125277.RqjLeX6XHG Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 07 November 2007, Anish Mistry wrote: > On Monday 05 November 2007, [LoN]Kamikaze wrote: > > Marc Fonvieille wrote: > > > On Thu, Oct 18, 2007 at 05:53:47PM +0200, [LoN]Kamikaze wrote: > > >> Anish Mistry wrote: > > >>> On Thursday 18 October 2007, Marc Fonvieille wrote: > > >>>> On Wed, Oct 17, 2007 at 12:28:30PM -0400, Anish Mistry wrote: > > >>>>> I just updated to RELENG_7 from 6.2 and I'm running into > > >>>>> some really annoying issues with jerky mouse movement and > > >>>>> skipping sound. This seems to be similar to: > > >>>>> Re: SCHED_4BSD in RELENG_7 disturbs workflow > > >>>>> This happens both with 4BSD and ULE. > > >>>>> > > >>>>> I seems to happen when I'm compiling ports and a new > > >>>>> cc/bzip2/sh process fires off (I'm just watching top), I'll > > >>>>> get the skip/freezeup. > > >>>> > > >>>> [...] > > >>>> > > >>>> Using ULE and UP kernel (i.e. without SMP etc.) helped a bit > > >>>> the things but it's still very annoying to use firefox > > >>>> during ports build. I see this lag/freeze on all boxes I > > >>>> use with 7.0, but it's true that with a fast machine people > > >>>> can ignore the problem, it's less obvious than with a 1GHz > > >>>> box for example. > > >>> > > >>> Yeah, I'm still seeing this behavior. Does anyone have > > >>> suggestions on debugging? > > >>> > > >>> Thanks, > > >> > > >> I did post the solution in this thread. > > > > > > It has nothing to do with the mouse. > > > > Does the problem persist for you? It's gone for me, even with > > moused. > > Yes, the problem seems to have been fixed. I'm back to > kern.hz=3D1000 and removed FULL_PREEMPTION. No skipping. It looks like I spoke too soon. I've just tried to compile miro and=20 as it was compiling the boost-python dependency I noticed the problem=20 again. Switching kern.hz=3D"100" seems to fix the problem. Can any of=20 the developers in this area reproduce the issue? It's pretty easy to=20 reproduce on my 1.33Ghz Athlon. =2D-=20 Anish Mistry --nextPart2125277.RqjLeX6XHG Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHQc3AxqA5ziudZT0RAlM1AJ9m9VBkYtBeGui8xwKZ+HcvW0O30gCfWOCC wzKiIOzWkJECrRBdDQo5oTY= =vh7x -----END PGP SIGNATURE----- --nextPart2125277.RqjLeX6XHG-- From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 17:57:36 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB90716A4A0 for ; Mon, 19 Nov 2007 17:57:36 +0000 (UTC) (envelope-from lists@jmwebb.net) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by mx1.freebsd.org (Postfix) with ESMTP id AEAAC13C4D1 for ; Mon, 19 Nov 2007 17:57:36 +0000 (UTC) (envelope-from lists@jmwebb.net) Received: from [192.168.1.15] (CPE-75-87-124-136.kc.res.rr.com [75.87.124.136]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1IuAfC0B7x-0005z3; Mon, 19 Nov 2007 12:44:03 -0500 Message-ID: <4741CB60.2030901@jmwebb.net> Date: Mon, 19 Nov 2007 11:44:00 -0600 From: Josh Webb User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: freebsd-stable References: <1195488856.19739.42.camel@bauer.cse.buffalo.edu> In-Reply-To: <1195488856.19739.42.camel@bauer.cse.buffalo.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1/w1bt5hyXuDo0duZYJq9VALqV/tAYsRDlt1Ag AV21S2Zj0YgqOdOm/Hlujvmx9TYPXekI9WX9Og+umGsU4t7EMD hTpJoQxn/QiC9ratBT4MQ== Subject: Re: FreeBSD 7.0-BETA3 Available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 17:57:37 -0000 Ken Smith wrote: > The 7.0-BETA3 builds are now available. If you would like to download > an ISO image to install from they are available here: > > ftp://ftp.freebsd.org/pub/FreeBSD/releases//ISO-IMAGES/7.0/ > > (adjust to be your architecture, e.g. amd64, i386, etc.). If you > would like to use cvsup to update an older machine the release tag is > still RELENG_7. What's the best way for me to perform a binary upgrade from 7.0-BETA2? From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 17:58:03 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9323F16A417 for ; Mon, 19 Nov 2007 17:58:03 +0000 (UTC) (envelope-from lists@jmwebb.net) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) by mx1.freebsd.org (Postfix) with ESMTP id 5BAD313C47E for ; Mon, 19 Nov 2007 17:58:03 +0000 (UTC) (envelope-from lists@jmwebb.net) Received: from [192.168.1.15] (CPE-75-87-124-136.kc.res.rr.com [75.87.124.136]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1IuAnY1ae0-0008WE; Mon, 19 Nov 2007 12:52:41 -0500 Message-ID: <4741CD67.3040007@jmwebb.net> Date: Mon, 19 Nov 2007 11:52:39 -0600 From: Josh Webb User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: freebsd-stable References: <1195488856.19739.42.camel@bauer.cse.buffalo.edu> <4741CB60.2030901@jmwebb.net> In-Reply-To: <4741CB60.2030901@jmwebb.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX18SoOl3jkJpbaGyct75p9HO3GhpbHIFRauvY+V hlmsW6LaRpBaaNuM4BXj4uO/bCpOXv5ZsUF1XQIg7VWbRhDkkd VaCXHJYaeUoi1xYiEyJiQ== Subject: Re: FreeBSD 7.0-BETA3 Available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 17:58:03 -0000 >> The 7.0-BETA3 builds are now available. If you would like to download >> an ISO image to install from they are available here: >> >> ftp://ftp.freebsd.org/pub/FreeBSD/releases//ISO-IMAGES/7.0/ >> >> (adjust to be your architecture, e.g. amd64, i386, etc.). If you >> would like to use cvsup to update an older machine the release tag is >> still RELENG_7. > > What's the best way for me to perform a binary upgrade from 7.0-BETA2? > Oops, I should have hit "Get Mail" before asking. I would have seen that Colin already answered my question. From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 18:06:27 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F34616A41B for ; Mon, 19 Nov 2007 18:06:27 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.freebsd.org (Postfix) with ESMTP id 3AB6813C44B for ; Mon, 19 Nov 2007 18:06:27 +0000 (UTC) (envelope-from kometen@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so1267063uge for ; Mon, 19 Nov 2007 10:06:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=8p4VWacBQTAzwDLncic0TSuzHGYVdm9D9cMb940hg6c=; b=ugO22g5dAfpk40Y51vDRwXPLptGWPKazGfytwoJoQB8oC0LjSgUkbDEmFRscy5JD40YHdRHBPP/iXJ5IyCjYyMWeolHaT3ResyPMrLZF9Sb3se4XgUurLH8GIodD17TghoPFhmQbdNZPD3uYhB/B7Dx8+5NHrNqiob83qrlf51s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=c4gmmKFbSngou8a3dD1zcsOcWz+opm394r93U4F+7QR4JEoHBrGbrcs27i1jdBCIEc+lRt6nV10OpoF8ykvybhC/cl8Mydug4AgUZ0QkcbIik7/VJVHiqWInv/x6ro+8xdoFCkvPnedyG72hydsXojToDAU3uYJkNv+uwLMsmD8= Received: by 10.78.162.4 with SMTP id k4mr5548498hue.1195495578720; Mon, 19 Nov 2007 10:06:18 -0800 (PST) Received: by 10.78.161.3 with HTTP; Mon, 19 Nov 2007 10:06:18 -0800 (PST) Message-ID: Date: Mon, 19 Nov 2007 19:06:18 +0100 From: "Claus Guttesen" To: "Alexey Popov" In-Reply-To: <4741905E.8050300@chistydom.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4741905E.8050300@chistydom.ru> Cc: freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 18:06:27 -0000 On Nov 19, 2007 2:32 PM, Alexey Popov wrote: > Hi. > > I have a large pool of web backends (Apache + mod_php5) with > 2 x Xeon 3.2GHz processors and 2 x Xeon 5120 dual-core processors. The > workload is mostly CPU-bound. I'm using 6-STABLE-amd64 and also tried > 7-STABLE. > > Now I'm trying to use new hardware with 2 x Xeon 5320 (quad-core), but > it can not work under the same load as dual-core. It shows up to 80% > system CPU load in top: > > last pid: 3850; load averages: 22.51, 19.75, 12.18 Very high load. Could it be the raid-controller? I had a db-server with horibble performance due to a cheap raid-controller. Moving to a ciss-controller (DL380 G5) solved all my issues. My load decreased 100 fold. -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 18:22:39 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA95E16A46D for ; Mon, 19 Nov 2007 18:22:39 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by mx1.freebsd.org (Postfix) with ESMTP id CA27B13C474 for ; Mon, 19 Nov 2007 18:22:39 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so2189190waf for ; Mon, 19 Nov 2007 10:22:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=aajbCEAigfcBDhlYiMQGPtDtkfb+YLEXBgCEKvKy7Y8=; b=V8XIKjyzzHBZH9bD46PicFcQ2GYNOLClT88wl5uksuAxhSQxiW0k1tOXe4VoPYyW8hJkWmFusYlG7/J4SevdhKGqYtXiAAXvIj1NJryI9ibW3oPhbtA8UZbYiCmsvZv4HX/rW7mSIvLFB/KceTdnA03L4tXyco2RLQSK3/b+DVg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=B7Sf7bKPajQTn3t4Mpxzq6usDHp2Utx7zXH7hFO4sIwkOBxPEtbfgFotXfT6urQz2g1s1pEJMmKvohNIcLALn/wm4JxB0luAjj8KKidBqje3GB2em/TeIxRNR3kWpS4eEhzkPrSjHRnNL0UTi+huwBv6X23CvQJfNkqvxVsBaiY= Received: by 10.115.90.1 with SMTP id s1mr344606wal.1195496553068; Mon, 19 Nov 2007 10:22:33 -0800 (PST) Received: by 10.114.13.15 with HTTP; Mon, 19 Nov 2007 10:22:33 -0800 (PST) Message-ID: Date: Mon, 19 Nov 2007 10:22:33 -0800 From: "Kip Macy" To: "Anish Mistry" In-Reply-To: <200711191254.08134.mistry.7@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200710171228.39123.mistry.7@osu.edu> <472ED12B.7040200@gmx.de> <200711070953.22154.mistry.7@osu.edu> <200711191254.08134.mistry.7@osu.edu> Cc: "\[LoN\]Kamikaze" , freebsd-stable@freebsd.org Subject: Re: RELENG_7 jerky mouse and skipping sound (still a problem -BETA3) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 18:22:40 -0000 On Nov 19, 2007 9:53 AM, Anish Mistry wrote: > On Wednesday 07 November 2007, Anish Mistry wrote: > > On Monday 05 November 2007, [LoN]Kamikaze wrote: > > > Marc Fonvieille wrote: > > > > On Thu, Oct 18, 2007 at 05:53:47PM +0200, [LoN]Kamikaze wrote: > > > >> Anish Mistry wrote: > > > >>> On Thursday 18 October 2007, Marc Fonvieille wrote: > > > >>>> On Wed, Oct 17, 2007 at 12:28:30PM -0400, Anish Mistry wrote: > > > >>>>> I just updated to RELENG_7 from 6.2 and I'm running into > > > >>>>> some really annoying issues with jerky mouse movement and > > > >>>>> skipping sound. This seems to be similar to: > > > >>>>> Re: SCHED_4BSD in RELENG_7 disturbs workflow > > > >>>>> This happens both with 4BSD and ULE. > > > >>>>> > > > >>>>> I seems to happen when I'm compiling ports and a new > > > >>>>> cc/bzip2/sh process fires off (I'm just watching top), I'll > > > >>>>> get the skip/freezeup. > > > >>>> > > > >>>> [...] > > > >>>> > > > >>>> Using ULE and UP kernel (i.e. without SMP etc.) helped a bit > > > >>>> the things but it's still very annoying to use firefox > > > >>>> during ports build. I see this lag/freeze on all boxes I > > > >>>> use with 7.0, but it's true that with a fast machine people > > > >>>> can ignore the problem, it's less obvious than with a 1GHz > > > >>>> box for example. > > > >>> > > > >>> Yeah, I'm still seeing this behavior. Does anyone have > > > >>> suggestions on debugging? > > > >>> > > > >>> Thanks, > > > >> > > > >> I did post the solution in this thread. > > > > > > > > It has nothing to do with the mouse. > > > > > > Does the problem persist for you? It's gone for me, even with > > > moused. > > > > Yes, the problem seems to have been fixed. I'm back to > > kern.hz=1000 and removed FULL_PREEMPTION. No skipping. > It looks like I spoke too soon. I've just tried to compile miro and > as it was compiling the boost-python dependency I noticed the problem > again. Switching kern.hz="100" seems to fix the problem. Can any of > the developers in this area reproduce the issue? It's pretty easy to > reproduce on my 1.33Ghz Athlon. > There is an ithread priority inversion bug that might be causing this. The fix for that should be going in shortly. -Kip From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 18:24:14 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EEC616A46E; Mon, 19 Nov 2007 18:24:14 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4923113C461; Mon, 19 Nov 2007 18:24:13 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <4741D4D2.4090902@FreeBSD.org> Date: Mon, 19 Nov 2007 19:24:18 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Alexey Popov References: <4741905E.8050300@chistydom.ru> <20071119140019.V80667@fledge.watson.org> <4741A3A8.4010803@chistydom.ru> <20071119152214.J80667@fledge.watson.org> <4741B648.7090002@chistydom.ru> In-Reply-To: <4741B648.7090002@chistydom.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Robert Watson Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 18:24:14 -0000 Alexey Popov wrote: > Hi. > > Robert Watson wrote: >>> I tried SCHED_ULE, but got no difference: >> Did you see no change in throughput, or no change in reported CPU use? > No significant changes. > >> We should probably take this thread to performance@ and get Kris >> involved. He may be interested in trying to reproduce your workload >> in our testbed so we can perform measurements of our own, as well as >> getting you to provide profiling information. One of the things we'd >> most like to have are nice potted benchmarks for real-world workloads, >> as that allows us to easily replay them, perform measurements, >> optimize, etc. > I can provide all profiling or configuration information you ask for. > Except I can't provide PHP site source codes. > > Now I'm in situation that I can't install FreeBSD on all new servers > because they are all based on 2xquad-core processors and I can't be sure > it would work good. Running mutex profiling for e.g. 1 minute of representative load would be a useful starting point, as well as hwpmc profiling for the same duration. My guess is that you're hitting contention in the TCP send path, but I missed the start of this conversation so I don't know what problems you are seeing. Kris From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 18:35:33 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83E4116A417 for ; Mon, 19 Nov 2007 18:35:33 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 1263513C455 for ; Mon, 19 Nov 2007 18:35:32 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IuBSt-0002sy-Nd for freebsd-stable@freebsd.org; Mon, 19 Nov 2007 18:35:23 +0000 Received: from 78-1-101-166.adsl.net.t-com.hr ([78.1.101.166]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 19 Nov 2007 18:35:23 +0000 Received: from ivoras by 78-1-101-166.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 19 Nov 2007 18:35:23 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Mon, 19 Nov 2007 19:35:09 +0100 Lines: 64 Message-ID: References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> <4741B3DE.2000009@chistydom.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig08E7856D1BCDB2833F74CA53" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-101-166.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) In-Reply-To: <4741B3DE.2000009@chistydom.ru> X-Enigmail-Version: 0.95.5 Sender: news Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 18:35:33 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig08E7856D1BCDB2833F74CA53 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Alexey Popov wrote: > Here is it: http://83.167.98.162/gprof/kdump.txt.gz I don't see anything unusual there. Some more ideas: How is your disk load (iostat, systat -vm, diskinfo -t) during the load? You don't use NFS for the web directories, do you? Can you run bonnie++ while the machine is idle (i.e. apache is stopped) just to verify it isn't a stupid problem with the disks or the driver? >> Also, did you try configuring and running pecl-APC for PHP?'s > I'm using eAccelerator. Again, the same soft works good on less-CPU > system and on Linux. So, you pick the CPU out of the motherboard and plug in another one? If not, you can't be sure that some other thing isn't wrong. I know you tried it on Linux, but it might use slightly different commands in the driver that don't trigger the error. I'm very surprised that both 6.x and 7.x behave almost the same on your load: since they are very different in how they support multiple CPU-s, I'd expect a big difference in this case (in favour of 7.x), not a small one. This might point that the problem is not in the OS itself, but maybe in the hardware or in some driver. Many people (including me) have run FreeBSD on machines like yours without such problems, so let's dig further. You don't have WITNESS, INVARIANTS, DIAGNOSTICS or something similar enabled? Can you try a generic SMP kernel (called "SMP" in 6.x; the "GENERIC" in 7.x has SMP by default) and see how it works? Can you disable SMP and try with only one CPU (on the 2xquad machine)? You can do it in loader.conf by setting kern.smp.disabled=3D1, or perhaps= in BIOS. If there's a problem in some hardware or a driver, you'd still get a big load on sys time. You might also want to halt certain logical CPUs in the OS itself (see smp(4) man page) and see if there's a certain relationship between how many CPUs are running and what the sys load is. --------------enig08E7856D1BCDB2833F74CA53 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHQdddldnAQVacBcgRAkvXAKCtE5R0FjpyYEcs8prZhjSZrwh0UACgr91n 9dRDH+/KSBklM7l4vfiwF7s= =o/Ix -----END PGP SIGNATURE----- --------------enig08E7856D1BCDB2833F74CA53-- From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 18:44:29 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B58D516A41B for ; Mon, 19 Nov 2007 18:44:29 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id AAA0413C4C6 for ; Mon, 19 Nov 2007 18:44:29 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 0C72F1CC079; Mon, 19 Nov 2007 10:44:22 -0800 (PST) Date: Mon, 19 Nov 2007 10:44:22 -0800 From: Jeremy Chadwick To: Ivan Voras Message-ID: <20071119184422.GA43312@eos.sc1.parodius.com> References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> <4741B3DE.2000009@chistydom.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 18:44:29 -0000 On Mon, Nov 19, 2007 at 07:35:09PM +0100, Ivan Voras wrote: > Some more ideas: How is your disk load (iostat, systat -vm, diskinfo -t) > during the load? You don't use NFS for the web directories, do you? Don't forget about gstat(8), which (if the issue is an I/O bottleneck) may help pinpoint what particular disk device is being utilised too heavily. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 18:45:19 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F66D16A41A for ; Mon, 19 Nov 2007 18:45:19 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 209ED13C457 for ; Mon, 19 Nov 2007 18:45:19 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IuBbz-0004nz-PJ for freebsd-stable@freebsd.org; Mon, 19 Nov 2007 18:44:47 +0000 Received: from 78-1-101-166.adsl.net.t-com.hr ([78.1.101.166]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 19 Nov 2007 18:44:47 +0000 Received: from ivoras by 78-1-101-166.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 19 Nov 2007 18:44:47 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Mon, 19 Nov 2007 19:42:42 +0100 Lines: 39 Message-ID: References: <4741905E.8050300@chistydom.ru> <20071119140019.V80667@fledge.watson.org> <4741A3A8.4010803@chistydom.ru> <20071119152214.J80667@fledge.watson.org> <4741B648.7090002@chistydom.ru> <4741D4D2.4090902@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC829F72C5E4C261B65F814B0" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-101-166.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) In-Reply-To: <4741D4D2.4090902@FreeBSD.org> X-Enigmail-Version: 0.95.5 Sender: news Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 18:45:19 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC829F72C5E4C261B65F814B0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Kris Kennaway wrote: > My guess is that you're hitting contention in the TCP send path, but I > missed the start of this conversation so I don't know what problems you= > are seeing. Here it is: http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/038371.ht= ml there's some mutex profiling there. Offtopic: How to you read output from debug.mutex.prof.stats? Is cnt_lock the number of times a lock has been attempted to be acquired but it wasn't available? --------------enigC829F72C5E4C261B65F814B0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHQdkildnAQVacBcgRAvodAJ9rvdXydk/jz0zPwthzteAx1wwyWQCgvyQo ETAEi8nuGbc4Nb3To/biPXk= =3GdJ -----END PGP SIGNATURE----- --------------enigC829F72C5E4C261B65F814B0-- From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 18:46:41 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0222116A46E; Mon, 19 Nov 2007 18:46:41 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 24AC813C4E3; Mon, 19 Nov 2007 18:46:39 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <4741DA15.9000308@FreeBSD.org> Date: Mon, 19 Nov 2007 19:46:45 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Alexey Popov References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> <4741A7DA.2050706@chistydom.ru> In-Reply-To: <4741A7DA.2050706@chistydom.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Ivan Voras Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 18:46:41 -0000 Alexey Popov wrote: > Hi. > > Ivan Voras wrote: >>> CPU states: 9.5% user, 0.0% nice, 82.0% system, 0.5% interrupt, 8.0% >>> idle >> A wild idea that might not help: try reducing kern.hz in loader.conf to >> something like 100 and see if something significant changes. > Now it runs with hz=100, number of context switches became ~ 2 times > less, but still there's 90% system CPU load (see attach). System CPU usage doesn't tell you anything by itself, you need to look at how much work the system is actually doing (pages served/second, or whatever). For example, when your kernel is getting more work done, system CPU usage will also be higher. Kris From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 18:57:01 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8A3D16A41B; Mon, 19 Nov 2007 18:57:01 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 40BF113C4DD; Mon, 19 Nov 2007 18:57:01 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <4741DC82.1090809@FreeBSD.org> Date: Mon, 19 Nov 2007 19:57:06 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Ivan Voras References: <4741905E.8050300@chistydom.ru> <20071119140019.V80667@fledge.watson.org> <4741A3A8.4010803@chistydom.ru> <20071119152214.J80667@fledge.watson.org> <4741B648.7090002@chistydom.ru> <4741D4D2.4090902@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 18:57:02 -0000 Ivan Voras wrote: > Kris Kennaway wrote: > >> My guess is that you're hitting contention in the TCP send path, but I >> missed the start of this conversation so I don't know what problems you >> are seeing. > > Here it is: > http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/038371.html > > there's some mutex profiling there. OK, but that is on 6.x and only (I guess) on the 8 core machine. What is needed is at least a comparison of the two machines under identical conditions, and preferably on 7.0. It looks like the most serious issue might be due to lockmgr contention, but on 6.x lockmgr usage is not profiled directly (it only shows up via secondary mutexes). Comparing two 7.0 traces should help to shed more light on the subject. > Offtopic: How to you read output from debug.mutex.prof.stats? Is > cnt_lock the number of times a lock has been attempted to be acquired > but it wasn't available? It's explained in the MUTEX_PROFILING(9) manpage (LOCK_PROFILING(9) on 7.0) cnt_hold The number of times the lock was held and another thread attempted to acquire the lock. cnt_lock The number of times the lock was already held when this point was reached. Kris From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 19:04:44 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA8BC16A49C for ; Mon, 19 Nov 2007 19:04:44 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5408C13C45B for ; Mon, 19 Nov 2007 19:04:43 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IuBuX-0000rf-OF for freebsd-stable@freebsd.org; Mon, 19 Nov 2007 19:03:57 +0000 Received: from 78-1-101-166.adsl.net.t-com.hr ([78.1.101.166]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 19 Nov 2007 19:03:57 +0000 Received: from ivoras by 78-1-101-166.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 19 Nov 2007 19:03:57 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Mon, 19 Nov 2007 20:03:13 +0100 Lines: 45 Message-ID: References: <4741905E.8050300@chistydom.ru> <20071119140019.V80667@fledge.watson.org> <4741A3A8.4010803@chistydom.ru> <20071119152214.J80667@fledge.watson.org> <4741B648.7090002@chistydom.ru> <4741D4D2.4090902@FreeBSD.org> <4741DC82.1090809@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0C5FB2C2AC11270631CE4EB8" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-101-166.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) In-Reply-To: <4741DC82.1090809@FreeBSD.org> X-Enigmail-Version: 0.95.5 Sender: news Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 19:04:44 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0C5FB2C2AC11270631CE4EB8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Kris Kennaway wrote: > It's explained in the MUTEX_PROFILING(9) manpage (LOCK_PROFILING(9) on = 7.0) >=20 > cnt_hold The number of times the lock was held and anothe= r > thread attempted to acquire the lock. >=20 > cnt_lock The number of times the lock was already held > when this > point was reached. Interesting... why is the page named in UPPERCASE? :) finstall:~> locate lock_profiling finstall:~> locate LOCK_PROFILING /buildcd/livecd/usr/share/man/man9/LOCK_PROFILING.9.gz /usr/obj/usr/src/share/man/man9/LOCK_PROFILING.9.gz /usr/share/man/man9/LOCK_PROFILING.9.gz /usr/src/share/man/man9/LOCK_PROFILING.9 --------------enig0C5FB2C2AC11270631CE4EB8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHQd3yldnAQVacBcgRAlAJAJ93pQyDlQZx5WcfJNkhmu1z2z5cFQCgsYg1 W77MWljm2hklQ6qk99inlqU= =Nwaj -----END PGP SIGNATURE----- --------------enig0C5FB2C2AC11270631CE4EB8-- From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 19:19:11 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2722016A418; Mon, 19 Nov 2007 19:19:11 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7BF9113C467; Mon, 19 Nov 2007 19:19:10 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <4741E1B4.7000107@FreeBSD.org> Date: Mon, 19 Nov 2007 20:19:16 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Ivan Voras References: <4741905E.8050300@chistydom.ru> <20071119140019.V80667@fledge.watson.org> <4741A3A8.4010803@chistydom.ru> <20071119152214.J80667@fledge.watson.org> <4741B648.7090002@chistydom.ru> <4741D4D2.4090902@FreeBSD.org> <4741DC82.1090809@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 19:19:11 -0000 Ivan Voras wrote: > Kris Kennaway wrote: > >> It's explained in the MUTEX_PROFILING(9) manpage (LOCK_PROFILING(9) on 7.0) >> >> cnt_hold The number of times the lock was held and another >> thread attempted to acquire the lock. >> >> cnt_lock The number of times the lock was already held >> when this >> point was reached. > > Interesting... why is the page named in UPPERCASE? :) > > finstall:~> locate lock_profiling > finstall:~> locate LOCK_PROFILING > /buildcd/livecd/usr/share/man/man9/LOCK_PROFILING.9.gz > /usr/obj/usr/src/share/man/man9/LOCK_PROFILING.9.gz > /usr/share/man/man9/LOCK_PROFILING.9.gz > /usr/src/share/man/man9/LOCK_PROFILING.9 Matching the option name I guess. Not sure this is the right thing :) Kris From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 20:11:33 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C75E216A419 for ; Mon, 19 Nov 2007 20:11:33 +0000 (UTC) (envelope-from root@mail.telemarket.fr) Received: from mail.telemarket.fr (125-98.206-83.static-ip.oleane.fr [83.206.98.125]) by mx1.freebsd.org (Postfix) with ESMTP id 84B8613C48A for ; Mon, 19 Nov 2007 20:11:33 +0000 (UTC) (envelope-from root@mail.telemarket.fr) Received: from mail.telemarket.fr (localhost.localdomain [127.0.0.1]) by localhost.telemarket.fr (Postfix) with ESMTP id 840D18FC56 for ; Mon, 19 Nov 2007 20:44:53 +0100 (CET) Received: from mail.telemarket.fr (localhost.localdomain [127.0.0.1]) by mail.telemarket.fr (Postfix) with ESMTP id 5D6518FC85 for ; Mon, 19 Nov 2007 20:44:52 +0100 (CET) Received: (from root@localhost) by mail.telemarket.fr (8.12.10/8.12.10/Submit) id lAJJipl5011558 for stable@freebsd.org; Mon, 19 Nov 2007 20:44:51 +0100 Date: Mon, 19 Nov 2007 20:44:51 +0100 To: stable@freebsd.org Message-ID: <1195501491.15761.qmail@regions.net> From: "Regions Bank" MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: You have 1 new ALERT message X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 20:11:33 -0000 You have 1 new ALERT message Please login to your RegionsNet Online Banking and visit the Message Center section in order to read the message. To Login, please click the link below: [1]Go To RegionsNet Online © 2007 Regions Bank. All rights reserved References 1. http://www.informad.cl/EBanking/logon/ From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 20:14:18 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82FA616A41B; Mon, 19 Nov 2007 20:14:18 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1626E13C481; Mon, 19 Nov 2007 20:14:16 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <4741EE9E.9050406@FreeBSD.org> Date: Mon, 19 Nov 2007 21:14:22 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Alexey Popov References: <47137D36.1020305@chistydom.ru> <47149E6E.9000500@chistydom.ru> <4715035D.2090802@FreeBSD.org> <4715C297.1020905@chistydom.ru> <4715C5D7.7060806@FreeBSD.org> <471EE4D9.5080307@chistydom.ru> <4723BF87.20302@FreeBSD.org> <47344E47.9050908@chistydom.ru> <47349A17.3080806@FreeBSD.org> <47373B43.9060406@chistydom.ru> <4739557A.6090209@chistydom.ru> In-Reply-To: <4739557A.6090209@chistydom.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Panagiotis Christias , freebsd-stable@freebsd.org Subject: Re: amrd disk performance drop after running under high load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 20:14:18 -0000 Alexey Popov wrote: > Hi. > > Panagiotis Christias wrote: >>>>>> In the "good" case you are getting a much higher interrupt rate but >>>>>> with the data you provided I can't tell where from. You need to run >>>>>> vmstat -i at regular intervals (e.g. every 10 seconds for a minute) >>>>>> during the "good" and "bad" times, since it only provides counters >>>>>> and an average rate over the uptime of the system. >>>>> Now I'm running 10-process lighttpd and the problem became no so big. >>>>> >>>>> I collected interrupt stats and it shows no relation beetween >>>>> ionterrupts and slowdowns. Here is it: >>>>> http://83.167.98.162/gprof/intr-graph/ >>>>> >>>>> Also I have similiar statistics on mutex profiling and it shows >>>>> there's no problem in mutexes. >>>>> http://83.167.98.162/gprof/mtx-graph/mtxgifnew/ >>>>> >>>>> I have no idea what else to check. >>>> I don't know what this graph is showing me :) When precisely is the >>>> system behaving poorly? >> what is your RAID controller configuration (read ahead/cache/write >> policy)? I have seen weird/bogus numbers (~100% busy) reported by >> systat -v when read ahead was enabled on LSI/amr controllers. > > > ********************************************************************** > Existing Logical Drive Information > By LSI Logic Corp.,USA > > ********************************************************************** > [Note: For SATA-2, 4 and 6 channel controllers, please specify > Ch=0 Id=0..15 for specifying physical drive(Ch=channel, > Id=Target)] > > > Logical Drive : 0( Adapter: 0 ): Status: OPTIMAL > --------------------------------------------------- > SpanDepth :01 RaidLevel: 5 RdAhead : Adaptive Cache: DirectIo > StripSz :064KB Stripes : 6 WrPolicy: WriteBack > > Logical Drive 0 : SpanLevel_0 Disks > Chnl Target StartBlock Blocks Physical Target Status > ---- ------ ---------- ------ ---------------------- > 0 00 0x00000000 0x22ec0000 ONLINE > 0 01 0x00000000 0x22ec0000 ONLINE > 0 02 0x00000000 0x22ec0000 ONLINE > 0 03 0x00000000 0x22ec0000 ONLINE > 0 04 0x00000000 0x22ec0000 ONLINE > 0 05 0x00000000 0x22ec0000 ONLINE > > I tried to run with disabled Read-ahead, but it didn't help. I just ran into this myself, and apparently it can be caused by "Patrol Reads" where the adapter periodically scans the disks to look for media errors. You can turn this off using -stopPR with the megarc port. Kris From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 20:15:12 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D815A16A417; Mon, 19 Nov 2007 20:15:12 +0000 (UTC) (envelope-from root@kash.tomsk.ru) Received: from mx.kash.tomsk.ru (ns2.kash.tomsk.ru [88.204.35.2]) by mx1.freebsd.org (Postfix) with ESMTP id 04B8F13C4AC; Mon, 19 Nov 2007 20:15:11 +0000 (UTC) (envelope-from root@kash.tomsk.ru) Received: by mx.kash.tomsk.ru (Postfix, from userid 0) id E0DBDDAD45; Tue, 20 Nov 2007 02:15:03 +0600 (NOVT) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mx.kash.tomsk.ru (Postfix) with ESMTP id 13339DAD40 for ; Tue, 20 Nov 2007 02:15:02 +0600 (NOVT) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 74D511704BF; Mon, 19 Nov 2007 20:14:24 +0000 (UTC) (envelope-from owner-freebsd-hackers@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id B775C16A503; Mon, 19 Nov 2007 20:14:23 +0000 (UTC) (envelope-from owner-freebsd-hackers@freebsd.org) Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82FA616A41B; Mon, 19 Nov 2007 20:14:18 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1626E13C481; Mon, 19 Nov 2007 20:14:16 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <4741EE9E.9050406@FreeBSD.org> Date: Mon, 19 Nov 2007 21:14:22 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Alexey Popov References: <47137D36.1020305@chistydom.ru> <47149E6E.9000500@chistydom.ru> <4715035D.2090802@FreeBSD.org> <4715C297.1020905@chistydom.ru> <4715C5D7.7060806@FreeBSD.org> <471EE4D9.5080307@chistydom.ru> <4723BF87.20302@FreeBSD.org> <47344E47.9050908@chistydom.ru> <47349A17.3080806@FreeBSD.org> <47373B43.9060406@chistydom.ru> <4739557A.6090209@chistydom.ru> In-Reply-To: <4739557A.6090209@chistydom.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-hackers@freebsd.org Errors-To: owner-freebsd-hackers@freebsd.org X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue Nov 20 02:15:03 2007 X-DSPAM-Confidence: 0.9989 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4741eec7191327296633619 X-DSPAM-Factors: 27, Alexey, 0.00047, List-Post*, freebsd-stable@freebsd.org Subject: Re: amrd disk performance drop after running under high load X-BeenThere: freebsd-stable@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 20:15:13 -0000 Alexey Popov wrote: > Hi. > > Panagiotis Christias wrote: >>>>>> In the "good" case you are getting a much higher interrupt rate but >>>>>> with the data you provided I can't tell where from. You need to run >>>>>> vmstat -i at regular intervals (e.g. every 10 seconds for a minute) >>>>>> during the "good" and "bad" times, since it only provides counters >>>>>> and an average rate over the uptime of the system. >>>>> Now I'm running 10-process lighttpd and the problem became no so big. >>>>> >>>>> I collected interrupt stats and it shows no relation beetween >>>>> ionterrupts and slowdowns. Here is it: >>>>> http://83.167.98.162/gprof/intr-graph/ >>>>> >>>>> Also I have similiar statistics on mutex profiling and it shows >>>>> there's no problem in mutexes. >>>>> http://83.167.98.162/gprof/mtx-graph/mtxgifnew/ >>>>> >>>>> I have no idea what else to check. >>>> I don't know what this graph is showing me :) When precisely is the >>>> system behaving poorly? >> what is your RAID controller configuration (read ahead/cache/write >> policy)? I have seen weird/bogus numbers (~100% busy) reported by >> systat -v when read ahead was enabled on LSI/amr controllers. > > > ********************************************************************** > Existing Logical Drive Information > By LSI Logic Corp.,USA > > ********************************************************************** > [Note: For SATA-2, 4 and 6 channel controllers, please specify > Ch=0 Id=0..15 for specifying physical drive(Ch=channel, > Id=Target)] > > > Logical Drive : 0( Adapter: 0 ): Status: OPTIMAL > --------------------------------------------------- > SpanDepth :01 RaidLevel: 5 RdAhead : Adaptive Cache: DirectIo > StripSz :064KB Stripes : 6 WrPolicy: WriteBack > > Logical Drive 0 : SpanLevel_0 Disks > Chnl Target StartBlock Blocks Physical Target Status > ---- ------ ---------- ------ ---------------------- > 0 00 0x00000000 0x22ec0000 ONLINE > 0 01 0x00000000 0x22ec0000 ONLINE > 0 02 0x00000000 0x22ec0000 ONLINE > 0 03 0x00000000 0x22ec0000 ONLINE > 0 04 0x00000000 0x22ec0000 ONLINE > 0 05 0x00000000 0x22ec0000 ONLINE > > I tried to run with disabled Read-ahead, but it didn't help. I just ran into this myself, and apparently it can be caused by "Patrol Reads" where the adapter periodically scans the disks to look for media errors. You can turn this off using -stopPR with the megarc port. Kris _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 20:37:14 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A20C116A420; Mon, 19 Nov 2007 20:37:14 +0000 (UTC) (envelope-from w@wrzask.pl) Received: from mx.oak.pl (mx.oak.pl [217.96.108.251]) by mx1.freebsd.org (Postfix) with ESMTP id 6223613C46A; Mon, 19 Nov 2007 20:37:14 +0000 (UTC) (envelope-from w@wrzask.pl) Received: by oak.pl (Postfix, from userid 1002) id 9299D1CD15; Mon, 19 Nov 2007 21:21:42 +0100 (CET) Date: Mon, 19 Nov 2007 21:21:42 +0100 From: Jan Srzednicki To: freebsd-stable@freebsd.org, freebsd-pf@freebsd.org Message-ID: <20071119202142.GI2045@oak.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: pf(4) using inapropriate timeout values, 6.2-R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 20:37:14 -0000 Hello, I'm running pf(4) on a 6.2-RELEASE system. The problem occurs when on a TCP connection, one side sends a FIN (by issuing shutdown(SHUT_WR) on the socket), which is then ACK-ed properly. According to pf.conf(5), the connection should then be subject to tcp.closing timeout: tcp.closing The state after the first FIN has been sent. But, after testing, I have discovered that the connection is timeouted after tcp.finwait value: tcp.finwait The state after both FINs have been exchanged and the connec- tion is closed. Some hosts (notably web servers on Solaris) send TCP packets even after closing the connection. Increas- ing tcp.finwait (and possibly tcp.closing) can prevent block- ing of such packets. I'm positively sure it's precisely this value that timeouts this conection (which later on get state mismatches). Default tcp.closing value is quite big (15 minutes), while tcp.finwait ain't, and I have tuned tcp.finwait to a small value due to excesive number of short-lived connections I have running. This happens both with "keep state" and "modulate state". Is it some kind of a known issue? Is there any fix avalaible? I didn't test it on any other system than 6.2-R. -- Jan Srzednicki :: http://wrzask.pl/ "Remember, remember, the fifth of November" -- V for Vendetta From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 21:21:36 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 440BC16A474 for ; Mon, 19 Nov 2007 21:21:36 +0000 (UTC) (envelope-from bh@izb.knu.ac.kr) Received: from pinus.izb.knu.ac.kr (pinus.izb.knu.ac.kr [IPv6:2001:470:1f05:d8:3::1]) by mx1.freebsd.org (Postfix) with ESMTP id ECCED13C455 for ; Mon, 19 Nov 2007 21:21:35 +0000 (UTC) (envelope-from bh@izb.knu.ac.kr) Received: by pinus.izb.knu.ac.kr (Postfix, from userid 59) id AFF4A3EDC; Tue, 20 Nov 2007 06:21:34 +0900 (KST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on pinus.izb.knu.ac.kr X-Spam-Level: X-Spam-Status: No, score=-18.4 required=15.1 tests=DKIM_SIGNED,DKIM_VERIFIED autolearn=disabled version=3.2.3 X-Spam-Comment: DKIM? See http://www.google.com/search?btnI&q=RFC+4871 Received: from pinus.izb.knu.ac.kr (localhost.izb.knu.ac.kr [127.0.0.1]) by pinus.izb.knu.ac.kr (Postfix) with ESMTP id 5A3C33EDB; Tue, 20 Nov 2007 06:21:32 +0900 (KST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=izb.knu.ac.kr; h= subject:from:reply-to:to:cc:in-reply-to:references:content-type: date:message-id:mime-version:content-transfer-encoding; q= dns/txt; s=s1024; bh=Hw8Or7sSFTkrwEUv5F0s3+1A02rKZv2GS6iV3qqgSFo =; b=gbEDngcwWD3a0x7naVNvfUfiAh58gFg31FKPa4iDeX2J0aOyVIidNpK74UQ pqiiD/5dU7IADTOsEMBdnmusYX1Koy2wU4jjjZY4D1aJ2NGDaDq4SPALE7EwgA/E 77GM2dUYVjkKv3VzNXWcwMTo2X1tT7wEaL6C2xdPveybz2vU= Received: from chrys.izb.knu.ac.kr (chrys.izb.knu.ac.kr [IPv6:2001:470:1f05:cf:3::1]) by pinus.izb.knu.ac.kr (Postfix) with ESMTP id D683C3EDA; Tue, 20 Nov 2007 06:21:31 +0900 (KST) Received: from jihad.izb.knu.ac.kr (jihad.izb.knu.ac.kr [IPv6:2001:470:1f05:d8:3::2]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bh.rfc4871@chrys.izb.knu.ac.kr) by chrys.izb.knu.ac.kr (Postfix) with ESMTP id CCD0B1CCEE; Tue, 20 Nov 2007 06:21:17 +0900 (KST) Received: from [IPv6:::1] (localhost.izb.knu.ac.kr [IPv6:::1]) by jihad.izb.knu.ac.kr (Postfix) with ESMTP id 12E3B5E0E; Tue, 20 Nov 2007 06:21:25 +0900 (KST) From: Byung-Hee HWANG To: Ken Smith In-Reply-To: <1195488856.19739.42.camel@bauer.cse.buffalo.edu> References: <1195488856.19739.42.camel@bauer.cse.buffalo.edu> Content-Type: text/plain Organization: InZealBomb Date: Tue, 20 Nov 2007 06:21:20 +0900 Message-Id: <1195507281.986.3.camel@jihad.izb.knu.ac.kr> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-stable Subject: Re: FreeBSD 7.0-BETA3 Available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bh@izb.knu.ac.kr List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 21:21:36 -0000 On Mon, 2007-11-19 at 11:14 -0500, Ken Smith wrote: > The 7.0-BETA3 builds are now available. If you would like to download > an ISO image to install from they are available here: > > ftp://ftp.freebsd.org/pub/FreeBSD/releases//ISO-IMAGES/7.0/ > > (adjust to be your architecture, e.g. amd64, i386, etc.). If you > would like to use cvsup to update an older machine the release tag is > still RELENG_7. It works fine, THANKS! bh@jihad:~> uname -a FreeBSD jihad.izb.knu.ac.kr 7.0-BETA3 FreeBSD 7.0-BETA3 #2: Tue Nov 20 05:06:49 KST 2007 root@jihad.izb.knu.ac.kr:/usr/obj/usr/src/sys/GENERIC i386 bh@jihad:~> respect, bh -- "It's supposed to be so terrible that even my father won't talk about it." -- Michael Corleone, "Chapter 1", page 24 From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 21:30:01 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94BB316A41B for ; Mon, 19 Nov 2007 21:30:01 +0000 (UTC) (envelope-from fbsd@opal.com) Received: from smtp.vzavenue.net (smtp.vzavenue.net [66.171.59.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4DAAA13C447 for ; Mon, 19 Nov 2007 21:30:01 +0000 (UTC) (envelope-from fbsd@opal.com) Received: from 98.79.171.66.subscriber.vzavenue.net (HELO homobox.opal.com) ([66.171.79.98]) by smtp.vzavenue.net with ESMTP; 19 Nov 2007 16:29:45 -0500 X-REPUTATION: None X-REMOTE-IP: 66.171.79.98 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0KABiOQUdCq09i/2dsb2JhbACBW4gahm0 X-IronPort-AV: i="4.21,438,1188792000"; d="asc'?scan'208"; a="170827605:sNHT23538951" Received: from vougeot.opal.com (localhost [127.0.0.1]) (authenticated bits=0) by homobox.opal.com (8.13.8/8.13.8) with ESMTP id lAJLTidd089331 for ; Mon, 19 Nov 2007 16:29:44 -0500 (EST) (envelope-from fbsd@opal.com) Received: from vougeot.opal.com ([141.157.200.27] helo=vougeot.opal.com) by ASSP-nospam; 19 Nov 2007 16:29:43 -0500 Date: Mon, 19 Nov 2007 16:29:38 -0500 From: "J.R. Oldroyd" To: freebsd-stable@freebsd.org Message-ID: <20071119162938.24696649@vougeot.opal.com> X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.1; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/a8uNzKxbsDwan2vwj6SBqe4"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Subject: psm GlidePoint problems on 7.0b3 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 21:30:01 -0000 --Sig_/a8uNzKxbsDwan2vwj6SBqe4 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Just installed 7.0b3 on a Sony VAIO laptop which has an ALPS GlidePoint touchpad. System ran 6.2 and earlier FreeBSD versions without problems. On 7.0b3, there are several touchpad problems. Things work fine after the initial boot, both on the console and in xorg. I am running moused: /usr/sbin/moused -3 -m 1=3D4 -p /dev/psm0 -t auto and have the following in xorg.conf: Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" EndSection Those settings have been there for years, over several earlier FreeBSD versions, without problems. But now, on 7.0b3, after an APCI suspend and resume: 1. the touchpad's tap feature no longer works =3D> adding hint.psm.0.flags=3D"0x6000" to set HOOKRESUME and INITAFTERSUSPEND seems to cure this, despite this not being needed under previous FreeBSD versions. 2. after every resume it's as if a middle-click has been done: the last selected text is pasted back again. This could have possibly serious consequences depending on what text is present and what application the mouse is over when the unwanted paste occurs. 3. occasionally when moving the cursor using the touchpad, the coordinates suddenly jump unexpectedly to a new place on the screen, as in several hundred pixels away. These jumps seem to be of varying x and y offsets and direction. I am also seeing occasional menu pop-ups as if left-clic= ks or keyboard input (such as Alt-F) has been done - but all I am doing is moving the mouse using the touchpad! dmesg is: atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: flags 0x6000 irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model GlidePoint, device ID 0 Other than the 0x6000 flags hint, I have not changed any of the mouse settings during the freebsd-7.0 upgrade. Are some other changes needed? Or is this indicative of a possible bug in the mouse driver? Thanks, -jr --Sig_/a8uNzKxbsDwan2vwj6SBqe4 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iQDVAwUBR0IAQ0kkqUax7f6FAQLDvAYAoKHe/IV2fYsfR7hIdyJIQkvvug7RlTxM EsOeSWeR91JQSz/2IQ/O+j2c4/r0x3+GE412ZIMTHkLQnvyi3eofwR2oEOvGmf+e rTskFRqt+KcEU+aF1FvXPf2MrEmnDATNXGneyOlJUMoz4BJ0QPIlh+23M1vCeoAw aqSy8vh5+SG/U/NNTE+rvsv26jY9kW8o2EhVaK7ob9VWIUyIGnnnCo+V1CVIY/o3 9cLslvHI5WdibSSU8pALBzAu3325KKZ6 =XauG -----END PGP SIGNATURE----- --Sig_/a8uNzKxbsDwan2vwj6SBqe4-- From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 21:41:19 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 643E116A417 for ; Mon, 19 Nov 2007 21:41:19 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by mx1.freebsd.org (Postfix) with ESMTP id D2D3413C45A for ; Mon, 19 Nov 2007 21:41:17 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so6400371pyb for ; Mon, 19 Nov 2007 13:41:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=z6yfAjZTwLpRqD1GhuEEdAlB7n5PAE0c9wxVyRlnvlM=; b=kWn3+pURYtHw8VlLUsroyBFDdLAXl5LCo1sNYwFFk4d1NpcNFhLUL0Kq9EPcPMerUGnO85IbYVWMAyxhs7aVGtmS1ix3v9M15pdkBJrPUToCtWafXXHPyjQ8APiBIh2hFcNKoBbJUuOXRY2ltRH1GjvSbEB+PBBZ1BE3CyhUbFQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Hfdg5kqPwl9RUPdMH6+e6NiY4ZYz/IbWTyLNbhj/B9bVWuP2AH3t1CWbsOdzlEP2UftEU6r3dxwNrkclziyl7SmsI4LEm74XzGvW1tR7RhYs/TTmnhND0i6MeV6MKz0SHzb0tk3ervgrhRwRSILiHugKJZxz8ogO29XgMN8K8/w= Received: by 10.35.116.12 with SMTP id t12mr6685394pym.1195508469932; Mon, 19 Nov 2007 13:41:09 -0800 (PST) Received: by 10.35.58.11 with HTTP; Mon, 19 Nov 2007 13:41:09 -0800 (PST) Message-ID: Date: Mon, 19 Nov 2007 13:41:09 -0800 From: "Matt Reimer" To: "Alexey Popov" In-Reply-To: <4741B3DE.2000009@chistydom.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> <4741B3DE.2000009@chistydom.ru> Cc: freebsd-stable@freebsd.org, Ivan Voras Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 21:41:19 -0000 On Nov 19, 2007 8:03 AM, Alexey Popov wrote: > > Ivan Voras wrote: > > > > Also, did you try configuring and running pecl-APC for PHP?'s > I'm using eAccelerator. Again, the same soft works good on less-CPU > system and on Linux. FWIW, when playing with eaccelerator on RELENG_7 recently, I noticed that it seems to chew a lot of extra system time (as seen in top) when used with Apache+mod_fastcgi, but not when used with nginx. I didn't investigate. Matt From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 06:53:38 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3F8816A417; Tue, 20 Nov 2007 06:53:37 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [IPv6:2001:6f8:1098::2]) by mx1.freebsd.org (Postfix) with ESMTP id 798E013C46A; Tue, 20 Nov 2007 06:53:36 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id lAK6rYYU032279 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 20 Nov 2007 07:53:34 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id lAK6rY4N003488; Tue, 20 Nov 2007 07:53:34 +0100 (MET) Date: Tue, 20 Nov 2007 07:53:34 +0100 From: Daniel Hartmeier To: Jan Srzednicki Message-ID: <20071120065334.GJ29432@insomnia.benzedrine.cx> References: <20071119202142.GI2045@oak.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071119202142.GI2045@oak.pl> User-Agent: Mutt/1.5.12-2006-07-14 Cc: freebsd-stable@freebsd.org, freebsd-pf@freebsd.org Subject: Re: pf(4) using inapropriate timeout values, 6.2-R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 06:53:38 -0000 On Mon, Nov 19, 2007 at 09:21:42PM +0100, Jan Srzednicki wrote: > I'm positively sure it's precisely this value that timeouts this > conection (which later on get state mismatches). What does pfctl -vvss show for such a state entry, in particular the right-most part of the first line ("ESTABLISHED:ESTABLISHED" while the connection is still fully established, etc.)? Does it matter which side of the connection (the client or the server) half-closes the connection? It's possible that there's a bug in mapping the timeout, I'll check. Daniel From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 08:36:42 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E25516A417; Tue, 20 Nov 2007 08:36:42 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from hermes.hw.ru (hermes.hw.ru [80.68.240.91]) by mx1.freebsd.org (Postfix) with ESMTP id C0B4A13C442; Tue, 20 Nov 2007 08:36:39 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from [80.68.244.40] (account a_popov@rbc.ru [80.68.244.40] verified) by hermes.hw.ru (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 201459468; Tue, 20 Nov 2007 11:36:03 +0300 Message-ID: <47429C6A.8060701@chistydom.ru> Date: Tue, 20 Nov 2007 11:35:54 +0300 From: Alexey Popov User-Agent: Thunderbird 2.0.0.6 (X11/20070924) MIME-Version: 1.0 To: Kris Kennaway References: <4741905E.8050300@chistydom.ru> <20071119140019.V80667@fledge.watson.org> <4741A3A8.4010803@chistydom.ru> <20071119152214.J80667@fledge.watson.org> <4741B648.7090002@chistydom.ru> <4741D4D2.4090902@FreeBSD.org> <4741DC82.1090809@FreeBSD.org> In-Reply-To: <4741DC82.1090809@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------070007040800000700060905" Cc: freebsd-stable@freebsd.org, Ivan Voras Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 08:36:42 -0000 This is a multi-part message in MIME format. --------------070007040800000700060905 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi. Kris Kennaway wrote: > OK, but that is on 6.x and only (I guess) on the 8 core machine. What > is needed is at least a comparison of the two machines under identical > conditions, and preferably on 7.0. Right, that was 8-core on 6-STABLE. > It looks like the most serious issue might be due to lockmgr contention, > but on 6.x lockmgr usage is not profiled directly (it only shows up via > secondary mutexes). Comparing two 7.0 traces should help to shed more > light on the subject. At this moment I have no 4-core servers running FreeBSD 7. Take a look at lock profiling of 8-core server on 7-STABLE in attach. If there's no evidence of the problem I'll try 7-STABLE on the production 4-core server. Also could you explain what to look for in the lock profiling results? Does large "wait_total" values indicate problem or other columns??? With best regards, Alexey Popov --------------070007040800000700060905 Content-Type: text/plain; name="7-lockprof-quad.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="7-lockprof-quad.txt" ZGVidWcubG9jay5wcm9mLnN0YXRzOiAKICAgbWF4ICAgICAgICB0b3RhbCAgIHdhaXRfdG90 YWwgICAgICAgY291bnQgICBhdmcgd2FpdF9hdmcgICAgIGNudF9ob2xkICAgICBjbnRfbG9j ayBuYW1lCiAgICAxMCAgICAgICAgICAgNTYgICAgICAgICAgICAwICAgICAgICAgICA3ICAg ICA4ICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4v dWlwY191c3JyZXEuYzo1MTIgKHJ3OnVucF9nbG9iYWxfcndsb2NrKQogICAgMTggICAgICAg ICAgMTY1ICAgICAgICAgICAgMCAgICAgICAgICAxNyAgICAgOSAgICAgMCAgICAgICAgICAg IDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9uZXRpbmV0L3VkcF91c3JyZXEuYzoxMDk5 IChzbGVlcCBtdXRleDp1ZHApCiAgICA3MyAgICAgICAgICA1NzkgICAgICAgICAgICAwICAg ICAgICAgIDE2ICAgIDM2ICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9z cmMvc3lzL2dlb20vZ2VvbV9kaXNrLmM6MTk4IChzbGVlcCBtdXRleDpnX2Rpc2tfZG9uZSkK ICAgIDc5ICAgICAgICAgIDEzMyAgICAgICAgICAgIDAgICAgICAgICAgIDIgICAgNjYgICAg IDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi91aXBjX3Vz cnJlcS5jOjUzMCAocnc6dW5wX2dsb2JhbF9yd2xvY2spCiAgICAyOSAgICAgICAgICAxMDAg ICAgICAgICAgICAwICAgICAgICAgICA1ICAgIDIwICAgICAwICAgICAgICAgICAgMCAgICAg ICAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3ZtX29iamVjdC5jOjEyOTggKHNsZWVwIG11dGV4 OnZtIG9iamVjdCkKICAgIDI1ICAgICAgICAgICA3MiAgICAgICAgICAgIDAgICAgICAgICAg IDUgICAgMTQgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMv dm0vdm1fb2JqZWN0LmM6MTI5OSAoc2xlZXAgbXV0ZXg6dm0gb2JqZWN0KQogICAgMjcgICAg ICAgIDEyMDEzICAgICAgICAgICAgMCAgICAgICAgNDI1MSAgICAgMiAgICAgMCAgICAgICAg ICAgIDMgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9uZXQvaWZfZXRoZXJzdWJyLmM6NDA1 IChzbGVlcCBtdXRleDplbTApCiAgICAyNSAgICAgICAgICAyNTMgICAgICAgICAgICAwICAg ICAgICAgIDE2ICAgIDE1ICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9z cmMvc3lzL25ldGluZXQvdWRwX3VzcnJlcS5jOjExMTMgKHNsZWVwIG11dGV4OnVkcCkKICAz MjE1ICAgICAgIDI1MDYzNSAgICAgICAgICAgIDAgICAgICAgICA5MzMgICAyNjggICAgIDAg ICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdm1fbWFwLmM6MjI5 MyAoc2xlZXAgbXV0ZXg6dm0gb2JqZWN0KQogICAgIDIgICAgICAgICAgICA1ICAgICAgICAg ICAgMCAgICAgICAgICAgMyAgICAgMSAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAw IC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQxNCAoc2xlZXAgbXV0ZXg6MjA0OCkKICAg ICA4ICAgICAgICAgICA0MyAgICAgICAgICAgIDAgICAgICAgICAgIDcgICAgIDYgICAgIDAg ICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi91aXBjX3VzcnJl cS5jOjU1NyAocnc6dW5wX2dsb2JhbF9yd2xvY2spCiAgIDExNyAgICAgICAgICA0MTUgICAg ICAgICAgICAwICAgICAgICAgIDEwICAgIDQxICAgICAwICAgICAgICAgICAgMCAgICAgICAg ICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9leGl0LmM6NDI4IChzeDpwcm9jdHJlZSkK ICAgODEzICAgICAgICAyMTk1MyAgICAgICAgICAgIDAgICAgICAgIDE1NTEgICAgMTQgICAg IDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3Ns ZWVwcXVldWUuYzozOTAgKHNsZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAgIDEyICAgICAg ICAgICAyMSAgICAgICAgICAgIDAgICAgICAgICAgIDIgICAgMTAgICAgIDAgICAgICAgICAg ICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfYmlvLmM6MTczOCAoc2xl ZXAgbXV0ZXg6YnVmIHF1ZXVlIGxvY2spCiAgICAgNSAgICAgICAgICAgMTMgICAgICAgICAg ICAwICAgICAgICAgICAzICAgICA0ICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAg L3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6NDE0IChzbGVlcCBtdXRleDpNQVAgRU5UUlkp CiAgIDE0MCAgICAgICAgICAxNDAgICAgICAgICAgICAwICAgICAgICAgICAxICAgMTQwICAg ICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3ZtX2tlcm4u YzoyOTYgKHNsZWVwIG11dGV4OnN5c3RlbSBtYXApCiAgICAgNCAgICAgICAgICAgMTQgICAg ICAgICAgICAwICAgICAgICAgICA1ICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAg ICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3ZtX29iamVjdC5jOjEzNzggKHNsZWVwIG11dGV4OnZt IG9iamVjdCkKICAgIDQ0ICAgICAgICAgIDExMiAgICAgICAgICAgIDAgICAgICAgICAgIDMg ICAgMzcgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vy bi91aXBjX3VzcnJlcS5jOjYyMiAocnc6dW5wX2dsb2JhbF9yd2xvY2spCiAgIDU2MCAgICAg ICAgICA3MzAgICAgICAgICAgICAwICAgICAgICAgIDIxICAgIDM0ICAgICAwICAgICAgICAg ICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9kZXNjcmlwLmM6NjY1 IChzeDpmaWxlZGVzYyBzdHJ1Y3R1cmUpCiAgICAgNCAgICAgICAgICAgMzQgICAgICAgICAg ICAwICAgICAgICAgIDE0ICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAg L3Vzci9zcmMvc3lzL2tlcm4va2Vybl9leGVjLmM6ODU0IChzbGVlcCBtdXRleDp2bSBwYWdl IHF1ZXVlIG11dGV4KQogICAgMTggICAgICAgICAzNDc3ICAgICAgICAgICAgMCAgICAgICAg MTI0MiAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5 cy9rZXJuL3VpcGNfc29ja2V0LmM6MTEzNiAoc2xlZXAgbXV0ZXg6c29fc25kKQogICAgMTEg ICAgICAgICAgNDE5ICAgICAgICAgICAgMCAgICAgICAgICA2MCAgICAgNiAgICAgMCAgICAg ICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19iaW8uYzoyMTA3 IChzbGVlcCBtdXRleDpidWZmZXIgZGFlbW9uIGxvY2spCiAgICAgNSAgICAgICAgICAgMzkg ICAgICAgICAgICAwICAgICAgICAgIDE0ICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAg ICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9leGVjLmM6ODc2IChzbGVlcCBtdXRl eDp2bSBwYWdlIHF1ZXVlIG11dGV4KQogICAgIDcgICAgICAgICAgMTA4ICAgICAgICAgICAg MCAgICAgICAgICAyMyAgICAgNCAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91 c3Ivc3JjL3N5cy92bS92bV9mYXVsdC5jOjY0OSAoc2xlZXAgbXV0ZXg6dm0gb2JqZWN0KQog ICAgIDUgICAgICAgICAgMTA1ICAgICAgICAgICAgMCAgICAgICAgICAzNiAgICAgMiAgICAg MCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3VpcGNfc29j a2J1Zi5jOjgyNyAoc2xlZXAgbXV0ZXg6c29fcmN2KQogICAgIDEgICAgICAgICAgICAxICAg ICAgICAgICAgMCAgICAgICAgICAgMSAgICAgMSAgICAgMCAgICAgICAgICAgIDAgICAgICAg ICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjg4OSAoc2xlZXAgbXV0ZXg6MTI4 IEJ1Y2tldCkKICAgMTE4ICAgICAgICAgODAxMSAgICAgICAgICAgIDAgICAgICAgICA0MjMg ICAgMTggICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdm0v dm1fZmF1bHQuYzo2NjcgKHNsZWVwIG11dGV4OnZtIG9iamVjdCkKICAgICAzICAgICAgICAg ICAgOCAgICAgICAgICAgIDAgICAgICAgICAgIDMgICAgIDIgICAgIDAgICAgICAgICAgICAw ICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0MTQgKHNsZWVwIG11 dGV4Om1idWZfanVtYm9fcGFnZXNpemUpCiAgICAgMyAgICAgICAgICAgIDcgICAgICAgICAg ICAwICAgICAgICAgICAzICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAg L3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6NDE0IChzbGVlcCBtdXRleDpVUENBTEwpCiAg ICA1NiAgICAgICAgICAgNTYgICAgICAgICAgICAwICAgICAgICAgICAxICAgIDU2ICAgICAw ICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2ZzL2ZpZm9mcy9maWZv X3Zub3BzLmM6NzE2IChzbGVlcCBtdXRleDpHaWFudCkKICAgIDU1ICAgICAgICAgIDM0MyAg ICAgICAgICAgIDAgICAgICAgICAgIDggICAgNDIgICAgIDAgICAgICAgICAgICAwICAgICAg ICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2V4ZWMuYzo0OTQgKGxvY2ttZ3I6dWZz KQogICAgIDUgICAgICAgICAgIDcyICAgICAgICAgICAgMCAgICAgICAgICAyNyAgICAgMiAg ICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9uZXRpbmV0L2lw X2lucHV0LmM6MTIxOCAoc2xlZXAgbXV0ZXg6cnRlbnRyeSkKICAgMTI3ICAgICAgICAgMTQ2 NyAgICAgICAgICAgIDAgICAgICAgICAgMTYgICAgOTEgICAgIDAgICAgICAgICAgICAwICAg ICAgICAgICAgMCAvdXNyL3NyYy9zeXMvbmV0aW5ldC91ZHBfdXNycmVxLmM6ODQzIChzbGVl cCBtdXRleDppbnApCiAgICA4MSAgICAgICAgICAgODEgICAgICAgICAgICAwICAgICAgICAg ICAxICAgIDgxICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lz L2ZzL2ZpZm9mcy9maWZvX3Zub3BzLmM6NzM4IChzbGVlcCBtdXRleDpHaWFudCkKICAgICA1 ICAgICAgICAgICAyMiAgICAgICAgICAgIDAgICAgICAgICAgIDcgICAgIDMgICAgIDAgICAg ICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi91aXBjX3NvY2tldC5j OjIyMzAgKHNsZWVwIG11dGV4OnNvX3JjdikKICAgIDExICAgICAgICAgMTI4MyAgICAgICAg ICAgIDAgICAgICAgICA0ODUgICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAg MCAvdXNyL3NyYy9zeXMvdm0vdm1fbW1hcC5jOjEzMTggKHNsZWVwIG11dGV4OnByb2Nlc3Mg bG9jaykKICAgIDE1ICAgICAgICAgIDEyMyAgICAgICAgICAgIDAgICAgICAgICAgMTIgICAg MTAgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92 ZnNfYmlvLmM6MzQyNiAoc2xlZXAgbXV0ZXg6dm0gb2JqZWN0KQogICAgIDMgICAgICAgICAg IDEwICAgICAgICAgICAgMCAgICAgICAgICAgMyAgICAgMyAgICAgMCAgICAgICAgICAgIDAg ICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQxNCAoc2xlZXAgbXV0 ZXg6QUNMIFVNQSB6b25lKQogICAgMTcgICAgICAgICAxODM4ICAgICAgICAgICAgMCAgICAg ICAgIDI2MCAgICAgNyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3Jj L3N5cy92bS92bV9tYXAuYzoyNDk5IChzbGVlcCBtdXRleDp2bSBvYmplY3QpCiAgICAgNSAg ICAgICAgICAgMTAgICAgICAgICAgICAwICAgICAgICAgICAzICAgICAzICAgICAwICAgICAg ICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6NDE0IChz bGVlcCBtdXRleDpMIFZGUyBDYWNoZSkKICAgICAzICAgICAgICAgICAgNCAgICAgICAgICAg IDAgICAgICAgICAgIDIgICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAv dXNyL3NyYy9zeXMva2Vybi9rZXJuX2Rlc2NyaXAuYzoyNjAgKHNsZWVwIG11dGV4OnByb2Nl c3MgbG9jaykKICAgIDExICAgICAgICAgMTA2OCAgICAgICAgICAgIDAgICAgICAgICAzNzkg ICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdm0v dm1fZmF1bHQuYzo3NzAgKHNsZWVwIG11dGV4OnZtIG9iamVjdCkKICAgIDI2ICAgICAgICA0 OTI2OSAgICAgICAgNTIxMjMgICAgICAgMTQwMjkgICAgIDMgICAgIDMgICAgICAgICA1NDA0 ICAgICAgICAgNjY0NiAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2ludHIuYzo3MDYgKHNwaW4g bXV0ZXg6c2NoZWQgbG9jaykKICAgIDI1ICAgICAgICAgIDQxNyAgICAgICAgICAgIDAgICAg ICAgICAgMzggICAgMTAgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3Ny Yy9zeXMva2Vybi92ZnNfYmlvLmM6MzQ5OCAoc2xlZXAgbXV0ZXg6dm0gb2JqZWN0KQogICAg IDUgICAgICAgICAgIDU4ICAgICAgICAgICAgMCAgICAgICAgICAxOCAgICAgMyAgICAgMCAg ICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fdW10eC5j OjI3MDMgKHNwaW4gbXV0ZXg6dW10eCBsb2NrKQogICAgIDMgICAgICAgICAgICA2ICAgICAg ICAgICAgMCAgICAgICAgICAgMiAgICAgMyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAg ICAwIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19jbHVzdGVyLmM6OTEwIChzbGVlcCBtdXRleDp2 bSBvYmplY3QpCiAgICAgNSAgICAgICAgICAgNTAgICAgICAgICAgICAwICAgICAgICAgIDE3 ICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL3Zt L3VtYV9jb3JlLmM6MTg3NCAoc2xlZXAgbXV0ZXg6dGNwY2IpCiAgICAgNSAgICAgICAgICAg NDggICAgICAgICAgICAwICAgICAgICAgIDE2ICAgICAzICAgICAwICAgICAgICAgICAgMCAg ICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9ldmVudC5jOjc1OCAoc2xlZXAg bXV0ZXg6cHJvdGVjdCBzeXNmaWx0X29wcykKICAgICA1ICAgICAgICAgICAxMCAgICAgICAg ICAgIDAgICAgICAgICAgIDMgICAgIDMgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAg MCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0MTQgKHNsZWVwIG11dGV4OlVNQSBLZWdz KQogICAgMjAgICAgICAgICAgMTI0ICAgICAgICAgICAgMCAgICAgICAgICAxMSAgICAxMSAg ICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9uZXRpbmV0L3Rj cF91c3JyZXEuYzoxNDIxIChzbGVlcCBtdXRleDp0Y3ApCiAgIDM4OSAgICAgICAgMTY5NDEg ICAgICAgICAgMTI4ICAgICAgICAgIDgwICAgMjExICAgICAxICAgICAgICAgICAgMSAgICAg ICAgICAgIDEgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9leGl0LmM6Njg0IChzeDpwcm9jdHJl ZSkKICAgIDEwICAgICAgICAgICA0MyAgICAgICAgICAgIDAgICAgICAgICAgMTYgICAgIDIg ICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJu X2V2ZW50LmM6Nzc0IChzbGVlcCBtdXRleDpwcm90ZWN0IHN5c2ZpbHRfb3BzKQogICAgIDUg ICAgICAgICAgNDcwICAgICAgICAgICAgMCAgICAgICAgIDE5MyAgICAgMiAgICAgMCAgICAg ICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc192bm9wcy5jOjUw OCAoc2xlZXAgbXV0ZXg6c2xlZXAgbXR4cG9vbCkKICAgICAzICAgICAgICAgICAgOCAgICAg ICAgICAgIDAgICAgICAgICAgIDMgICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAg ICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0MTQgKHNsZWVwIG11dGV4OlBST0Mp CiAgICAgMyAgICAgICAgICAgIDggICAgICAgICAgICAwICAgICAgICAgICA0ICAgICAyICAg ICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdHR5LmM6 ODUwIChzbGVlcCBtdXRleDpwcm9jZXNzIGxvY2spCiAgMTAyNCAgICAgIDE0ODQxOTcgICAg ICAgIDkyMTczICAgICAgMjc5MTIyICAgICA1ICAgICAwICAgICAgICAgMzY4OSAgICAgICAg IDU0NzggL3Vzci9zcmMvc3lzL2tlcm4vdmZzX2NhY2hlLmM6MzI3IChzbGVlcCBtdXRleDpO YW1lIENhY2hlKQogICAgIDYgICAgICAgICAgNTEzICAgICAgICAgICAgMCAgICAgICAgIDE5 MyAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9r ZXJuL3Zmc192bm9wcy5jOjUyOSAoc2xlZXAgbXV0ZXg6c2xlZXAgbXR4cG9vbCkKICAzMDcy ICAgICAgICAgODA5MyAgICAgICAgICAgIDAgICAgICAgICAxMzcgICAgNTkgICAgIDAgICAg ICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdm1fb2JqZWN0LmM6MTYy NyAoc2xlZXAgbXV0ZXg6dm0gb2JqZWN0KQogICAgMTIgICAgICAgICA4OTM4ICAgICAgICAg IDE2MiAgICAgICAgMzYxOCAgICAgMiAgICAgMCAgICAgICAgICAgIDEgICAgICAgICAgICAy IC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19zdWJyLmM6Mjk0NiAoc2xlZXAgbXV0ZXg6dm5vZGUg aW50ZXJsb2NrKQogICAgIDMgICAgICAgICAgIDIwICAgICAgICAgICAgMCAgICAgICAgICAg OCAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9r ZXJuL2ltZ2FjdF9lbGYuYzo3NjMgKHNsZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAgICA1 ICAgICAgICAgIDExMCAgICAgICAgICAgIDAgICAgICAgICAgNDcgICAgIDIgICAgIDAgICAg ICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX211dGV4LmM6 MTQxIChzbGVlcCBtdXRleDpzb19yY3YpCiAgICAgNSAgICAgICAgICAgIDUgICAgICAgICAg ICAwICAgICAgICAgICAxICAgICA1ICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAg L3Vzci9zcmMvc3lzL2tlcm4va2Vybl9kZXNjcmlwLmM6Mzg1IChzbGVlcCBtdXRleDpwcm9j ZXNzIGxvY2spCiAgMTUzNyAgICAgICA0MjE1MjIgICAgICAgICAgIDgwICAgICAgIDQ3MTky ICAgICA4ICAgICAwICAgICAgICAgICAgMiAgICAgICAgICAgIDMgL3Vzci9zcmMvc3lzL3Zt L3ZtX2ZhdWx0LmM6ODg2IChzbGVlcCBtdXRleDp2bSBvYmplY3QpCiAgICAgMiAgICAgICAg ICAgIDQgICAgICAgICAgICAwICAgICAgICAgICAyICAgICAyICAgICAwICAgICAgICAgICAg MCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3ZtX21hcC5jOjI2MzEgKHNsZWVwIG11 dGV4OnZtIG9iamVjdCkKICAgICA0ICAgICAgICAgICAxMyAgICAgICAgICAgIDAgICAgICAg ICAgIDQgICAgIDMgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9z eXMvYW1kNjQvYW1kNjQvcG1hcC5jOjkwMiAoc2xlZXAgbXV0ZXg6cG1hcCkKICAgICAzICAg ICAgICAgICAgNyAgICAgICAgICAgIDAgICAgICAgICAgIDMgICAgIDIgICAgIDAgICAgICAg ICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdWZzL2Zmcy9mZnNfc29mdGRlcC5j OjYwMjMgKHNsZWVwIG11dGV4OlNvZnRkZXAgTG9jaykKICAgIDMxICAgICAgICAgIDIwNyAg ICAgICAgICAgIDAgICAgICAgICAgMTAgICAgMjAgICAgIDAgICAgICAgICAgICAwICAgICAg ICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2V4aXQuYzo1MTkgKHNwaW4gbXV0ZXg6 cHJvY2VzcyBzbG9jaykKICAxMTI1ICAgICAgICAgMTMwNCAgICAgICAgICAgIDAgICAgICAg ICAgIDYgICAyMTcgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9z eXMvdWZzL2Zmcy9mZnNfdm5vcHMuYzoyMTQgKHNsZWVwIG11dGV4OnZub2RlIGludGVybG9j aykKICAgIDQxICAgICAgICAgIDI2NyAgICAgICAgICAgIDAgICAgICAgICAgMTAgICAgMjYg ICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJu X2V4aXQuYzo1MjIgKHNwaW4gbXV0ZXg6cHJvY2VzcyBzbG9jaykKICAgICA1ICAgICAgICAg ICA0NiAgICAgICAgICAgIDAgICAgICAgICAgMTcgICAgIDIgICAgIDAgICAgICAgICAgICAw ICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvbmV0aW5ldC91ZHBfdXNycmVxLmM6MTA1MyAo c2xlZXAgbXV0ZXg6aW5wKQogICAgIDIgICAgICAgICAgICA3ICAgICAgICAgICAgMCAgICAg ICAgICAgMyAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3Jj L3N5cy92bS91bWFfY29yZS5jOjQxNCAoc2xlZXAgbXV0ZXg6VFVSTlNUSUxFKQogICAgIDUg ICAgICAgICAgIDExICAgICAgICAgICAgMCAgICAgICAgICAgMyAgICAgMyAgICAgMCAgICAg ICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3VpcGNfdXNycmVxLmM6 NzIyIChzbGVlcCBtdXRleDpzb19yY3YpCiAgICAgMiAgICAgICAgICAgIDIgICAgICAgICAg ICAwICAgICAgICAgICAxICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAg L3Vzci9zcmMvc3lzL3ZtL3ZtX3BhZ2VyLmM6MzM2IChzbGVlcCBtdXRleDpwYnVmIG11dGV4 KQogICAgIDIgICAgICAgICAgICA1ICAgICAgICAgICAgMCAgICAgICAgICAgMyAgICAgMSAg ICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29y ZS5jOjQxNCAoc2xlZXAgbXV0ZXg6cGlwZSkKICAgIDgyICAgICAgICAgIDk4NSAgICAgICAg ICAgIDAgICAgICAgICAgMTYgICAgNjEgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAg MCAvdXNyL3NyYy9zeXMvbmV0aW5ldC91ZHBfdXNycmVxLmM6MTA3MyAoc2xlZXAgbXV0ZXg6 aW5wKQogICAgIDIgICAgICAgICAgICA3ICAgICAgICAgICAgMCAgICAgICAgICAgNCAgICAg MSAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy92bS92bV9v YmplY3QuYzoxNjk1IChzbGVlcCBtdXRleDp2bSBvYmplY3QpCiAgICAgNyAgICAgICAgICAg IDcgICAgICAgICAgICAwICAgICAgICAgICAxICAgICA3ICAgICAwICAgICAgICAgICAgMCAg ICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL3Vmcy9mZnMvZmZzX3Zub3BzLmM6MjQwIChzbGVl cCBtdXRleDp2bm9kZSBpbnRlcmxvY2spCiAgICAzMSAgICAgICAgICAgNTMgICAgICAgICAg ICAwICAgICAgICAgICAyICAgIDI2ICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAg L3Vzci9zcmMvc3lzL2tlcm4vdmZzX2Jpby5jOjM2NDEgKHNsZWVwIG11dGV4OnZtIG9iamVj dCkKICAgIDMxICAgICAgICAgIDE0MiAgICAgICAgICAgIDAgICAgICAgICAgIDggICAgMTcg ICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJu X2V4ZWMuYzo3NDkgKGxvY2ttZ3I6dWZzKQogICAgIDMgICAgICAgICAgICA4ICAgICAgICAg ICAgMCAgICAgICAgICAgMyAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAw IC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQxNCAoc2xlZXAgbXV0ZXg6dW10eCBwaSkK ICAgODkwICAgICAgICAxNjAwMCAgICAgICAgICAyNTcgICAgICAgIDI3NzggICAgIDUgICAg IDAgICAgICAgICAgIDE2ICAgICAgICAgICAxOSAvdXNyL3NyYy9zeXMva2Vybi91aXBjX3Nv Y2tldC5jOjI0NjkgKHNsZWVwIG11dGV4OnNvX3JjdikKICAgICAzICAgICAgICAgICAzNiAg ICAgICAgICAgIDAgICAgICAgICAgMTYgICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAg ICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2V2ZW50LmM6MTQ5NSAoc3g6ZmlsZWRl c2Mgc3RydWN0dXJlKQogICAgIDUgICAgICAgICAgICA5ICAgICAgICAgICAgMCAgICAgICAg ICAgMyAgICAgMyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5 cy92bS91bWFfY29yZS5jOjQxNCAoc2xlZXAgbXV0ZXg6bXRfem9uZSkKICAgIDEyICAgICAg ICAgODg0MCAgICAgICAgICAyODEgICAgICAgIDM2MTggICAgIDIgICAgIDAgICAgICAgICAg ICAxICAgICAgICAgICAgMiAvdXNyL3NyYy9zeXMvdWZzL2Zmcy9mZnNfdmZzb3BzLmM6MTIy NiAoc2xlZXAgbXV0ZXg6dm5vZGUgaW50ZXJsb2NrKQogICAgMTggICAgICAgICAgIDE4ICAg ICAgICAgICAgMCAgICAgICAgICAgMSAgICAxOCAgICAgMCAgICAgICAgICAgIDAgICAgICAg ICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fcmVzb3VyY2UuYzoxODYgKHNsZWVwIG11 dGV4OnByb2Nlc3MgbG9jaykKICAgIDE0ICAgICAgICAgICA3MSAgICAgICAgICAgIDAgICAg ICAgICAgMTcgICAgIDQgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3Ny Yy9zeXMvbmV0aW5ldC91ZHBfdXNycmVxLmM6MTEwMCAoc2xlZXAgbXV0ZXg6aW5wKQogIDcz MzcgICAgICAgIDQ2MTg3ICAgICAgICAgIDI5MyAgICAgICAgIDEyNSAgIDM2OSAgICAgMiAg ICAgICAgICAgMTUgICAgICAgICAgIDExIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fc3luY2gu YzoyMzUgKHNsZWVwIG11dGV4OkdpYW50KQogICAgIDUgICAgICAgICAgIDkxICAgICAgICAg ICAgMCAgICAgICAgICAzMCAgICAgMyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAw IC91c3Ivc3JjL3N5cy9rZXJuL3VpcGNfc29ja2J1Zi5jOjk2IChzbGVlcCBtdXRleDpzb19z bmQpCiAgIDc4OCAgICAgICAxNTcyNzcgICAgICAgICAgMzc0ICAgICAgIDQ4MjkyICAgICAz ICAgICAwICAgICAgICAgICAxNSAgICAgICAgICAgMTcgL3Vzci9zcmMvc3lzL3ZtL3ZtX2Zh dWx0LmM6OTU5IChzbGVlcCBtdXRleDp2bSBvYmplY3QpCiAgICAyMCAgICAgICAgICAxNjUg ICAgICAgICAgICAwICAgICAgICAgIDE2ICAgIDEwICAgICAwICAgICAgICAgICAgMCAgICAg ICAgICAgIDAgL3Vzci9zcmMvc3lzL25ldGluZXQvdWRwX3VzcnJlcS5jOjExMTQgKHNsZWVw IG11dGV4OmlucCkKICAgIDE3ICAgICAgICAgMTA3MyAgICAgICAgICAgIDAgICAgICAgICAx NzIgICAgIDYgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMv dm0vdm1fZmF1bHQuYzo5NjYgKHNsZWVwIG11dGV4OnZtIG9iamVjdCkKICAgMTk5ICAgICAg ICAgIDM4MiAgICAgICAgICAgIDAgICAgICAgICAgIDIgICAxOTEgICAgIDAgICAgICAgICAg ICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfYmlvLmM6MzY4MCAoc2xl ZXAgbXV0ZXg6dm0gb2JqZWN0KQogICAgMTEgICAgICAgICAgIDQ0ICAgICAgICAgICAgMCAg ICAgICAgICAxMCAgICAgNCAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Iv c3JjL3N5cy9rZXJuL2tlcm5fc2lnLmM6MzI4OSAoc2xlZXAgbXV0ZXg6c2lnYWN0cykKICAg IDE2ICAgICAgICAgICAzMiAgICAgICAgICAgIDAgICAgICAgICAgIDcgICAgIDQgICAgIDAg ICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdWZzL2Zmcy9mZnNfdm5v cHMuYzoyODkgKHNsZWVwIG11dGV4OnZub2RlIGludGVybG9jaykKICAgIDM2ICAgICAgICAg MjAzNCAgICAgICAgICAgIDAgICAgICAgICA1NDUgICAgIDMgICAgIDAgICAgICAgICAgICAw ICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3RpbWVvdXQuYzoyNDEgKHNs ZWVwIG11dGV4OnRjcF9zY19oZWFkKQogICAgIDMgICAgICAgICAgIDE4ICAgICAgICAgICAg MCAgICAgICAgICAgOCAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91 c3Ivc3JjL3N5cy9rZXJuL2tlcm5fc2lnLmM6MzI5OSAoc2xlZXAgbXV0ZXg6c2lnYWN0cykK ICAgICA1ICAgICAgICAgICAgNSAgICAgICAgICAgIDAgICAgICAgICAgIDEgICAgIDUgICAg IDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdm1fcGFnZXIu Yzo0MTMgKHNsZWVwIG11dGV4OnBidWYgbXV0ZXgpCiAgMTc3MCAgICAgICAgNjc3MjIgICAg ICAgICAgICAwICAgICAgIDI1MDM3ICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAg ICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9kZXNjcmlwLmM6MTAyNSAoc3g6ZmlsZWRl c2Mgc3RydWN0dXJlKQogICAgIDQgICAgICAgICAgIDM1ICAgICAgICAgICAgMCAgICAgICAg ICAxMiAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5 cy91ZnMvZmZzL2Zmc192ZnNvcHMuYzoxMjY5IChzbGVlcCBtdXRleDp2bm9kZSBpbnRlcmxv Y2spCiAgICAxOCAgICAgICAgICAxNDMgICAgICAgICAgICAwICAgICAgICAgIDE2ICAgICA4 ICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdWlw Y19zb2NrZXQuYzoyNTI4IChzbGVlcCBtdXRleDpzb19yY3YpCiAgICAzMSAgICAgICAgICAg MzEgICAgICAgICAgICAwICAgICAgICAgICAxICAgIDMxICAgICAwICAgICAgICAgICAgMCAg ICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdWlwY191c3JyZXEuYzo4MTAgKHNsZWVw IG11dGV4OnNvX3JjdikKICAgIDExICAgICAgICAgICA3NiAgICAgICAgICAgNTkgICAgICAg ICAgMTAgICAgIDcgICAgIDUgICAgICAgICAgICA1ICAgICAgICAgICAgOCAvdXNyL3NyYy9z eXMva2Vybi9rZXJuX3RocmVhZC5jOjQ2NyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrKQogICAg IDUgICAgICAgICAgIDU5ICAgICAgICAgICAgMCAgICAgICAgICAxOSAgICAgMyAgICAgMCAg ICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fcHJvdC5j OjE4NzQgKHNsZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAgIDE3ICAgICAgICAgIDY5OCAg ICAgICAgICAgNDAgICAgICAgICAyMTUgICAgIDMgICAgIDAgICAgICAgICAgICAyICAgICAg ICAgICAgNSAvdXNyL3NyYy9zeXMva2Vybi92ZnNfY2FjaGUuYzo1MDAgKHNsZWVwIG11dGV4 Ok5hbWUgQ2FjaGUpCiAgMTkzMyAgICAgICA4OTgxMDYgICAgICAgICA5MjkyICAgICAgMTU3 MTAzICAgICA1ICAgICAwICAgICAgICAgIDc2NyAgICAgICAgICAyNzMgL3Vzci9zcmMvc3lz L2tlcm4vdmZzX3Zub3BzLmM6ODA3IChzbGVlcCBtdXRleDp2bm9kZSBpbnRlcmxvY2spCiAg ICAgMSAgICAgICAgICAgIDEgICAgICAgICAgICAwICAgICAgICAgICAxICAgICAxICAgICAw ICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9wcm90 LmM6MTkzMyAoc2xlZXAgbXV0ZXg6c2Vzc2lvbikKICAgIDc4ICAgICAgICAgNDc5NiAgICAg ICAgICAgIDAgICAgICAgIDE1ODUgICAgIDMgICAgIDAgICAgICAgICAgICAwICAgICAgICAg ICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zeXNfZ2VuZXJpYy5jOjg5MyAoc2xlZXAgbXV0ZXg6 cHJvY2VzcyBsb2NrKQogICAgIDMgICAgICAgICAgIDIxICAgICAgICAgICAzNSAgICAgICAg ICAxMCAgICAgMiAgICAgMyAgICAgICAgICAgIDQgICAgICAgICAgICA1IC91c3Ivc3JjL3N5 cy9rZXJuL2tlcm5fdGhyZWFkLmM6NTAxIChzcGluIG11dGV4OnNjaGVkIGxvY2spCiAgICAy MiAgICAgICAgMTc0MzIgICAgICAgICAgICAwICAgICAgICA2MzkzICAgICAyICAgICAwICAg ICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2NvbnRyaWIvaXBmaWx0ZXIv bmV0aW5ldC9maWwuYzoyMjgyIChydzppcGYgY2FjaGUgcndsb2NrKQogICAgIDUgICAgICAg ICAgIDE3ICAgICAgICAgICAgMCAgICAgICAgICAgNiAgICAgMiAgICAgMCAgICAgICAgICAg IDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9uZXRpbmV0L2luX3BjYi5jOjc4OSAoc2xl ZXAgbXV0ZXg6aW5wKQogICAxMzggICAgICAgIDEwMjk1ICAgICAgICAgMjAwMiAgICAgICAg MTcxOCAgICAgNSAgICAgMSAgICAgICAgICAgNDMgICAgICAgICAgIDg3IC91c3Ivc3JjL3N5 cy9uZXRpbmV0L3RjcF9pbnB1dC5jOjExOTEgKHNsZWVwIG11dGV4OnNvX3JjdikKICAgICAz ICAgICAgICAgICAgNyAgICAgICAgICAgIDAgICAgICAgICAgIDMgICAgIDIgICAgIDAgICAg ICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0MTQg KHNsZWVwIG11dGV4OnNvY2tldCkKICAgICAzICAgICAgICAgICAgOCAgICAgICAgICAgIDAg ICAgICAgICAgIDMgICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNy L3NyYy9zeXMva2Vybi92ZnNfc3lzY2FsbHMuYzozOTUxIChzbGVlcCBtdXRleDpzbGVlcCBt dHhwb29sKQogICAgMzcgICAgICAgICAgIDQ0ICAgICAgICAgICAgMCAgICAgICAgICAgMyAg ICAxNCAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJu L3VpcGNfdXNycmVxLmM6ODczIChzbGVlcCBtdXRleDpzb19yY3YpCiAgICAgNCAgICAgICAg ICAgMTUgICAgICAgICAgICAwICAgICAgICAgICA0ICAgICAzICAgICAwICAgICAgICAgICAg MCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL25ldGluZXQvaW5fcGNiLmM6ODA4IChzbGVl cCBtdXRleDppbnApCiAgICAgNiAgICAgICAgICAgIDYgICAgICAgICAgICAwICAgICAgICAg ICAxICAgICA2ICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lz L2tlcm4va2Vybl9wcm90LmM6MTkzMiAoc2xlZXAgbXV0ZXg6cHJvY2VzcyBsb2NrKQogICAg IDUgICAgICAgICAgIDEzICAgICAgICAgICAgMCAgICAgICAgICAgNCAgICAgMyAgICAgMCAg ICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjg4 OSAoc2xlZXAgbXV0ZXg6TUFQIEVOVFJZKQogICAgMTMgICAgICAgICAgMTAyICAgICAgICAg ICAgMCAgICAgICAgICAxMiAgICAgOCAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAw IC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19zdWJyLmM6MzE2MiAoc2xlZXAgbXV0ZXg6dm5vZGUg aW50ZXJsb2NrKQogICAgMTEgICAgICAgICAgMzU3ICAgICAgICAgICAgMCAgICAgICAgIDEy MCAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9j b250cmliL2lwZmlsdGVyL25ldGluZXQvaXBfZnJhZy5jOjc5OSAocnc6aXBmIElQIE5BVC1G cmFnIHJ3bG9jaykKICAgIDIzICAgICAgICAgMzgwMCAgICAgICAgICAgIDAgICAgICAgIDE0 NDggICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMv a2Vybi9rZXJuX2V4aXQuYzo3MTIgKHNwaW4gbXV0ZXg6cHJvY2VzcyBzbG9jaykKICAgMTA2 ICAgICAgICAxNTg3OSAgICAgICAgICAgIDAgICAgICAgICA1MzAgICAgMjkgICAgIDAgICAg ICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi91aXBjX3NvY2tidWYu YzoyMzEgKHNsZWVwIG11dGV4OnNvX3NuZCkKICAgICA5ICAgICAgICAgIDEzNiAgICAgICAg IDExOTAgICAgICAgICAgMjQgICAgIDUgICAgNDkgICAgICAgICAgICAwICAgICAgICAgICAg MiAvdXNyL3NyYy9zeXMvc3lzL2J1Zi5oOjI3NiAoc2xlZXAgbXV0ZXg6bG9ja2J1aWxkZXIg bXR4cG9vbCkKICAgICAzICAgICAgICAgICAxNyAgICAgICAgICAgIDAgICAgICAgICAgIDcg ICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdWZz L2Zmcy9mZnNfc29mdGRlcC5jOjM3NDIgKHNsZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAg IDEwICAgICAgICAgIDIxMSAgICAgICAgICAgIDAgICAgICAgICAgMzggICAgIDUgICAgIDAg ICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX2V2ZW50 aGFuZGxlci5jOjIxMiAoc2xlZXAgbXV0ZXg6ZXZlbnRoYW5kbGVyKQogICAgIDUgICAgICAg ICAgIDM0ICAgICAgICAgICAgMCAgICAgICAgICAxMiAgICAgMiAgICAgMCAgICAgICAgICAg IDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy91ZnMvZmZzL2Zmc19zb2Z0ZGVwLmM6NjI0 NCAoc2xlZXAgbXV0ZXg6U29mdGRlcCBMb2NrKQogICAgMzYgICAgICAgICAyMjIwICAgICAg ICAgICAgMCAgICAgICAgIDY5OSAgICAgMyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAg ICAwIC91c3Ivc3JjL3N5cy92bS92bV9vYmplY3QuYzoxODg0IChzbGVlcCBtdXRleDp2bSBv YmplY3QpCiAgMzI3NSAgICAgICAyOTQ0MDQgICAgICAgICAgICAwICAgICAgICAgNDE0ICAg NzExICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3Zt X21tYXAuYzo1NTcgKHN4OnVzZXIgbWFwKQogICAgMzggICAgICAgICAzNjQyICAgICAgICAg ICAxOCAgICAgICAgIDQ0OSAgICAgOCAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAx IC91c3Ivc3JjL3N5cy9zeXMvYnVmLmg6Mjk2IChzbGVlcCBtdXRleDpsb2NrYnVpbGRlciBt dHhwb29sKQogICAgMTEgICAgICAgICAgMzcwICAgICAgICAgICAgMCAgICAgICAgIDEzNCAg ICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJu L3N5c19zb2NrZXQuYzoxMjEgKHNsZWVwIG11dGV4OnNvX3JjdikKICAgIDExICAgICAgICAg IDM2NSAgICAgICAgICAgIDAgICAgICAgICAxMzUgICAgIDIgICAgIDAgICAgICAgICAgICAw ICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zeXNfc29ja2V0LmM6MTQ3IChzbGVl cCBtdXRleDpzb19yY3YpCiAgICAxMiAgICAgICAgIDI0NDcgICAgICAgICAgICAwICAgICAg ICAgNzIxICAgICAzICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMv c3lzL25ldGluZXQvdGNwX3RpbWV3YWl0LmM6NjQzIChzbGVlcCBtdXRleDppbnApCiAgICAx MSAgICAgICAgICAzNjIgICAgICAgICAgICAwICAgICAgICAgMTM1ICAgICAyICAgICAwICAg ICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3lzX3NvY2tldC5j OjE1MCAoc2xlZXAgbXV0ZXg6c29fcmN2KQogICAgMTAgICAgICAgICAgMTA2ICAgICAgICAg ICAgMCAgICAgICAgICAxNiAgICAgNiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAw IC91c3Ivc3JjL3N5cy9rZXJuL3VpcGNfc29ja2V0LmM6MjY4MCAoc2xlZXAgbXV0ZXg6c29f cmN2KQogICAgIDUgICAgICAgICAgMTQ5ICAgICAgICAgICAgMCAgICAgICAgICA0OSAgICAg MyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFf Y29yZS5jOjE4NzQgKHNsZWVwIG11dGV4Om1idWYpCiAgICAgMyAgICAgICAgICAgNDUgICAg ICAgICAgICAwICAgICAgICAgIDIxICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAg ICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9kZXNjcmlwLmM6NjU5IChzbGVlcCBtdXRl eDpwcm9jZXNzIGxvY2spCiAgICAgNSAgICAgICAgICAgMTEgICAgICAgICAgICAwICAgICAg ICAgICAzICAgICAzICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMv c3lzL3ZtL3VtYV9jb3JlLmM6NDE0IChzbGVlcCBtdXRleDoxNiBCdWNrZXQpCiAgICAgNCAg ICAgICAgICAgMjAgICAgICAgICAgICAwICAgICAgICAgICA3ICAgICAyICAgICAwICAgICAg ICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL3Vmcy9mZnMvZmZzX3NvZnRkZXAu YzozODE1IChzbGVlcCBtdXRleDpwcm9jZXNzIGxvY2spCiAgIDE2NiAgICAgICAgNjYyNTQg ICAgICAgICAgICAwICAgICAgICAgOTcyICAgIDY4ICAgICAwICAgICAgICAgICAgMCAgICAg ICAgICAgIDAgL3Vzci9zcmMvc3lzL25ldGluZXQvdGNwX3RpbWVyLmM6MTY5IChzbGVlcCBt dXRleDppbnApCiAgICA0MSAgICAgICAgICAgNDEgICAgICAgICAgICAwICAgICAgICAgICAx ICAgIDQxICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tl cm4vdWlwY191c3JyZXEuYzoxMTc4IChydzp1bnBfZ2xvYmFsX3J3bG9jaykKICAgIDExICAg ICAgICAgNjUwMyAgICAgICAgICAgMjkgICAgICAgIDI0NzIgICAgIDIgICAgIDAgICAgICAg ICAgICAwICAgICAgICAgICAgMiAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3Jlc291cmNlLmM6 MTI0MCAoc2xlZXAgbXV0ZXg6c2xlZXAgbXR4cG9vbCkKICAgIDIyICAgICAgICAgIDE1NSAg ICAgICAgICAgIDAgICAgICAgICAgMTEgICAgMTQgICAgIDAgICAgICAgICAgICAwICAgICAg ICAgICAgMCAvdXNyL3NyYy9zeXMvbmV0aW5ldC90Y3Bfc3Vici5jOjEzNzkgKHNsZWVwIG11 dGV4Omlzbl9tdHgpCiAgICAgNCAgICAgICAgICAgMTEgICAgICAgICAgICAwICAgICAgICAg ICAzICAgICAzICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lz L3ZtL3VtYV9jb3JlLmM6NDE0IChzbGVlcCBtdXRleDo2NCkKICAgICA0ICAgICAgICAgICAy NiAgICAgICAgICAgIDAgICAgICAgICAgMTAgICAgIDIgICAgIDAgICAgICAgICAgICAwICAg ICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2V4aXQuYzoyMTUgKHNsZWVwIG11 dGV4OnBfcGVlcnMpCiAgICAyNiAgICAgICAgNTQyMjUgICAgICAgIDg3OTQ0ICAgICAgIDEz MzQ5ICAgICA0ICAgICA2ICAgICAgICAgNzI2MiAgICAgICAgIDg1NjQgL3Vzci9zcmMvc3lz L2tlcm4va2Vybl9pbnRyLmM6MTEzMSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrKQogICAgMTIg ICAgICAgICA2MzY0ICAgICAgICAgICAxOSAgICAgICAgMjUyMiAgICAgMiAgICAgMCAgICAg ICAgICAgIDEgICAgICAgICAgICAxIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fcmVzb3VyY2Uu YzoxMjY2IChzbGVlcCBtdXRleDpzbGVlcCBtdHhwb29sKQogIDEwNTQgICAgICAgIDEzMDIx ICAgICAgICAgICAgMCAgICAgICAgICAyNCAgIDU0MiAgICAgMCAgICAgICAgICAgIDAgICAg ICAgICAgICAwIC91c3Ivc3JjL3N5cy9zeXMvYnVmLmg6MjgwIChsb2NrbWdyOmJ1ZndhaXQp CiAgICAgNiAgICAgICAgICAgIDYgICAgICAgICAgICAwICAgICAgICAgICAxICAgICA2ICAg ICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9y ZXNvdXJjZS5jOjEyNzcgKHNsZWVwIG11dGV4OnNsZWVwIG10eHBvb2wpCiAgICAxMiAgICAg ICAgICAxNTkgICAgICAgICAgICAwICAgICAgICAgIDYyICAgICAyICAgICAwICAgICAgICAg ICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9kZXNjcmlwLmM6MTU0 NCAoc2xlZXAgbXV0ZXg6c2xlZXAgbXR4cG9vbCkKICAgODY1ICAgICAgICAxODY0NCAgICAg ICAgICAgIDAgICAgICAgICA0NDkgICAgNDEgICAgIDAgICAgICAgICAgICAwICAgICAgICAg ICAgMCAvdXNyL3NyYy9zeXMvc3lzL2J1Zi5oOjMwMSAobG9ja21ncjpnZXRibGspCiAgICA0 MCAgICAgICAgNTA0NzcgICAgICAgICAgICAwICAgICAgICA2MDAxICAgICA4ICAgICAwICAg ICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL25ldGluZXQvdGNwX3N1YnIu YzoxNDI2IChzbGVlcCBtdXRleDppc25fbXR4KQogICAgIDQgICAgICAgICAgIDcyICAgICAg ICAgICAgMCAgICAgICAgICAyNCAgICAgMyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAg ICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZXhlYy5jOjkwMyAoc2xlZXAgbXV0ZXg6cHJv Y2Vzc19leGVjKQogICAgIDEgICAgICAgICAgICAyICAgICAgICAgICAgMCAgICAgICAgICAg MiAgICAgMSAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9r ZXJuL3Zmc19zeXNjYWxscy5jOjM4NjQgKHN4OmZpbGVkZXNjIHN0cnVjdHVyZSkKICAgICA0 ICAgICAgICAgICAgOSAgICAgICAgICAgIDAgICAgICAgICAgIDMgICAgIDMgICAgIDAgICAg ICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0MTQg KHNsZWVwIG11dGV4OktOT1RFKQogICAgIDQgICAgICAgICAgIDUzICAgICAgICAgICAgMCAg ICAgICAgICAyMiAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Iv c3JjL3N5cy9rZXJuL2tlcm5fcmVzb3VyY2UuYzoxMzE0IChzbGVlcCBtdXRleDpzbGVlcCBt dHhwb29sKQogICAgIDkgICAgICAgICAgIDM2ICAgICAgICAgICAgMCAgICAgICAgICAxMCAg ICAgMyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJu L3N5c3Zfc2VtLmM6MTI4OCAoc2xlZXAgbXV0ZXg6c2VtKQogICAgIDUgICAgICAgICAgIDMw ICAgICAgICAgICAgMCAgICAgICAgICAxMCAgICAgMyAgICAgMCAgICAgICAgICAgIDAgICAg ICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZXhpdC5jOjI4NCAoc2xlZXAgbXV0 ZXg6cF9wZWVycykKICAgIDEyICAgICAgICAgICA2MyAgICAgICAgICAgIDAgICAgICAgICAg IDcgICAgIDkgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMv a2Vybi91aXBjX3VzcnJlcS5jOjEyNjggKHJ3OnVucF9nbG9iYWxfcndsb2NrKQogICAgIDQg ICAgICAgICAgIDEwICAgICAgICAgICAgMCAgICAgICAgICAgMyAgICAgMyAgICAgMCAgICAg ICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQxNCAo c2xlZXAgbXV0ZXg6NTEyKQogICAgMzMgICAgICAgICA0MDM1ICAgICAgICAgICAxNiAgICAg ICAgMTUxNiAgICAgMiAgICAgMCAgICAgICAgICAgIDMgICAgICAgICAgICAxIC91c3Ivc3Jj L3N5cy9uZXRpbmV0L3RjcF9zdWJyLmM6MTYwNiAoc2xlZXAgbXV0ZXg6cnRlbnRyeSkKICAg IDc4ICAgICAgICAgNzU1MSAgICAgICAgICAgIDAgICAgICAgIDI3OTQgICAgIDIgICAgIDAg ICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3Jlc291 cmNlLmM6MTMzOSAoc2xlZXAgbXV0ZXg6c2xlZXAgbXR4cG9vbCkKICAgICA1ICAgICAgICAg ICAgNSAgICAgICAgICAgIDAgICAgICAgICAgIDEgICAgIDUgICAgIDAgICAgICAgICAgICAw ICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzoyMTk1IChzbGVlcCBt dXRleDpVTUEgU2xhYnMpCiAgICAxOCAgICAgICAgICAgMjUgICAgICAgICAgICAwICAgICAg ICAgICAzICAgICA4ICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMv c3lzL3ZtL3VtYV9jb3JlLmM6NDE0IChzbGVlcCBtdXRleDpOQU1FSSkKICAgICA0ICAgICAg ICAgICAzMCAgICAgICAgICAgIDAgICAgICAgICAgMTEgICAgIDIgICAgIDAgICAgICAgICAg ICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi91aXBjX3NvY2tldC5jOjI4MjAg KHNsZWVwIG11dGV4OnNvX3JjdikKICAgNDUyICAgICAgICAzOTkzOCAgICAgICAgIDk0MzAg ICAgICAgMTQ1MjQgICAgIDIgICAgIDAgICAgICAgICAgMTI0ICAgICAgICAgIDQyNCAvdXNy L3NyYy9zeXMva2Vybi92ZnNfY2FjaGUuYzo3NzQgKHNsZWVwIG11dGV4Ok5hbWUgQ2FjaGUp CiAgICAyMCAgICAgICAgIDQyMDQgICAgICAgICAgICAwICAgICAgICAxMDIxICAgICA0ICAg ICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdWlwY19z b2NrZXQuYzoyODMyIChzbGVlcCBtdXRleDpzb19yY3YpCiAgMTMzOSAgICAgICAgNTAyMTYg ICAgICAgICAgMTI5ICAgICAgICA4NTI3ICAgICA1ICAgICAwICAgICAgICAgICAgNiAgICAg ICAgICAgIDYgL3Vzci9zcmMvc3lzL25ldC9yb3V0ZS5jOjE0NyAoc2xlZXAgbXV0ZXg6cmFk aXggbm9kZSBoZWFkKQogICAgNjEgICAgICAgICAxNDAzICAgICAgICAgICAgMCAgICAgICAg IDQ5NCAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5 cy9rZXJuL3VpcGNfc29ja2V0LmM6Mjg0NiAoc2xlZXAgbXV0ZXg6c29fcmN2KQogICAgIDQg ICAgICAgICAgICA5ICAgICAgICAgICAgMCAgICAgICAgICAgMyAgICAgMyAgICAgMCAgICAg ICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQxNCAo c2xlZXAgbXV0ZXg6S01BUCBFTlRSWSkKICAgICA1ICAgICAgICAgIDMyMyAgICAgICAgICAg IDAgICAgICAgICAxMjAgICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAv dXNyL3NyYy9zeXMvbmV0aW5ldC9pZ21wLmM6NDQ2IChzbGVlcCBtdXRleDppZ21wX210eCkK ICAgIDMwICAgICAgICAgIDE5NCAgICAgICAgICAgIDAgICAgICAgICAgMzMgICAgIDUgICAg IDAgICAgICAgICAgICAxICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi91aXBjX3Nv Y2tldC5jOjI4NjMgKHNsZWVwIG11dGV4OnNvX3JjdikKICAgNDE2ICAgICA1NTIyOTczNyAg ICAgMTMyNDU4NjYgICAgIDExMDg4MjUgICAgNDkgICAgMTEgICAgICAgOTU3NDMzICAgICAg IDk5MTQ0NyAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3NsZWVwcXVldWUuYzoyMzIgKHNwaW4g bXV0ZXg6c2xlZXBxIGNoYWluKQogICAgIDUgICAgICAgICAgMTA4ICAgICAgICAgICAgMCAg ICAgICAgICAzNiAgICAgMyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Iv c3JjL3N5cy9rZXJuL3VpcGNfc29ja2V0LmM6Mjg3NSAoc2xlZXAgbXV0ZXg6c29fcmN2KQog ICAgNzcgICAgICAgICAgMjk0ICAgICAgICAgICAgMCAgICAgICAgICAgNSAgICA1OCAgICAg MCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19sb29r dXAuYzo0MTEgKGxvY2ttZ3I6ZGV2ZnMpCiAgICAgNSAgICAgICAgICAxMDMgICAgICAgICAg ICAwICAgICAgICAgIDM4ICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAg L3Vzci9zcmMvc3lzL25ldGluZXQvdGNwX3VzcnJlcS5jOjk3MiAoc2xlZXAgbXV0ZXg6c29f cmN2KQogICA5MTAgICAgICAgMTY4MzM3ICAgICAgICAgICAgMCAgICAgICAxNTIwNyAgICAx MSAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tl cm5fZGVzY3JpcC5jOjEzOTQgKHN4OmZpbGVkZXNjIHN0cnVjdHVyZSkKICAgIDEyICAgICAg ICAgIDE3NiAgICAgICAgICAgIDUgICAgICAgICAgNTkgICAgIDIgICAgIDAgICAgICAgICAg ICAxICAgICAgICAgICAgMiAvdXNyL3NyYy9zeXMva2Vybi91aXBjX3NvY2tldC5jOjI4OTQg KHNsZWVwIG11dGV4OnNvX3JjdikKICAgICA1ICAgICAgICAgICAgNSAgICAgICAgICAgIDAg ICAgICAgICAgIDEgICAgIDUgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNy L3NyYy9zeXMva2Vybi92ZnNfY2x1c3Rlci5jOjc1MyAoc2xlZXAgbXV0ZXg6dm5vZGUgaW50 ZXJsb2NrKQogICAgIDMgICAgICAgICAgIDIwICAgICAgICAgICAgMCAgICAgICAgICAxMCAg ICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJu L2tlcm5fZXhpdC5jOjQ3MCAoc2xlZXAgbXV0ZXg6c2lnYWN0cykKICAgICA0ICAgICAgICAg ICAgOSAgICAgICAgICAgIDAgICAgICAgICAgIDMgICAgIDMgICAgIDAgICAgICAgICAgICAw ICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0MTQgKHNsZWVwIG11 dGV4OlVNQSBab25lcykKICAgICAxICAgICAgICAgICAgMyAgICAgICAgICAgIDAgICAgICAg ICAgIDIgICAgIDEgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9z eXMvdWZzL2Zmcy9mZnNfdmZzb3BzLmM6MTY1NiAoc2xlZXAgbXV0ZXg6dm5vZGUgaW50ZXJs b2NrKQogICAxNTcgICAgICAgIDMzNTc3ICAgICAgICAgICAgMCAgICAgICAxMzgxNSAgICAg MiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy92bS92bm9k ZV9wYWdlci5jOjExMCAoc2xlZXAgbXV0ZXg6dm0gb2JqZWN0KQogICAgIDQgICAgICAgICAg IDE5ICAgICAgICAgICAgMCAgICAgICAgICAgNyAgICAgMiAgICAgMCAgICAgICAgICAgIDAg ICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3VpcGNfdXNycmVxLmM6NTEzIChzbGVl cCBtdXRleDp1bnBfbXR4KQogICAgMTcgICAgICAgICAgMTU3ICAgICAgICAgICAgMCAgICAg ICAgICAxOCAgICAgOCAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3Jj L3N5cy9rZXJuL2tlcm5fcmVzb3VyY2UuYzoxMjA2IChzbGVlcCBtdXRleDp1aWRpbmZvIGhh c2gpCiAgICAyOSAgICAgICAgNDE4NzYgICAgICAgIDI5ODI2ICAgICAgIDExMjQyICAgICAz ICAgICAyICAgICAgICAgMzg5OCAgICAgICAgIDM2NTMgL3Vzci9zcmMvc3lzL2tlcm4va2Vy bl9zd2l0Y2guYzoxODIgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jaykKICAgICA3ICAgICAgICAg ICAgNyAgICAgICAgICAgIDAgICAgICAgICAgIDEgICAgIDcgICAgIDAgICAgICAgICAgICAw ICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3Jlc291cmNlLmM6MTIxMSAo c2xlZXAgbXV0ZXg6dWlkaW5mbyBoYXNoKQogICAgMzggICAgICAgIDIzMTgxICAgICAgICAg ICA0OSAgICAgICAgNjAyNyAgICAgMyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAy IC91c3Ivc3JjL3N5cy9kZXYvZW0vaWZfZW0uYzo0MzA1IChzbGVlcCBtdXRleDplbTApCiAg ICAxOSAgICAgICAgICAxMzIgICAgICAgICAgICAwICAgICAgICAgIDEwICAgIDEzICAgICAw ICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9kZXNj cmlwLmM6MTQyOSAoc3g6ZmlsZWRlc2Mgc3RydWN0dXJlKQogICAgMjIgICAgICAgICA5NDg5 ICAgICAgICAxNDM5MCAgICAgICAgMzQwNCAgICAgMiAgICAgNCAgICAgICAgICAgMTEgICAg ICAgICAgMzA1IC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkXzRic2QuYzozODUgKHNwaW4gbXV0 ZXg6c2xlZXBxIGNoYWluKQogICA1NzYgICAgICAgICA0MTc3ICAgICAgICAgICAgMCAgICAg ICAgMTIzNiAgICAgMyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3Jj L3N5cy9rZXJuL3VpcGNfc29ja2J1Zi5jOjUzMSAoc2xlZXAgbXV0ZXg6c29fc25kKQogICAg IDMgICAgICAgICAgICA1ICAgICAgICAgICAgMCAgICAgICAgICAgMiAgICAgMiAgICAgMCAg ICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy91ZnMvZmZzL2Zmc192ZnNv cHMuYzoxNjc4IChzbGVlcCBtdXRleDp2bm9kZSBpbnRlcmxvY2spCiAgICA3NCAgICAgICAg ICAxMjIgICAgICAgICAgICAwICAgICAgICAgICAyICAgIDYxICAgICAwICAgICAgICAgICAg MCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdWlwY191c3JyZXEuYzo1MzMgKHNs ZWVwIG11dGV4OnVucF9tdHgpCiAgICA2OCAgICAgICAgICAxMTEgICAgICAgICAgICAwICAg ICAgICAgICAyICAgIDU1ICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9z cmMvc3lzL2tlcm4vdWlwY191c3JyZXEuYzo1MzYgKHNsZWVwIG11dGV4OnVucF9tdHgpCiAg ICAgNCAgICAgICAgICAgMTAgICAgICAgICAgICAwICAgICAgICAgICAzICAgICAzICAgICAw ICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6 NDE0IChzbGVlcCBtdXRleDpTV0FQTUVUQSkKICAgICA4ICAgICAgICAgIDIwOCAgICAgICAg ICAgIDYgICAgICAgICAgNjQgICAgIDMgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAg MiAvdXNyL3NyYy9zeXMva2Vybi92ZnNfYmlvLmM6MzAwMiAoc2xlZXAgbXV0ZXg6YmRvbmUg bG9jaykKICAgICA1ICAgICAgICAgICAxMCAgICAgICAgICAgIDAgICAgICAgICAgIDMgICAg IDMgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1h X2NvcmUuYzo0MTQgKHNsZWVwIG11dGV4OjMyIEJ1Y2tldCkKICAgICA2ICAgICAgICAgIDQy MiAgICAgICAgICAgIDAgICAgICAgICAxMjAgICAgIDMgICAgIDAgICAgICAgICAgICAwICAg ICAgICAgICAgMCAvdXNyL3NyYy9zeXMvY29udHJpYi9pcGZpbHRlci9uZXRpbmV0L2lwX2F1 dGguYzo1NjMgKHJ3OmlwZiBJUCBVc2VyLUF1dGggcndsb2NrKQogICAgIDQgICAgICAgICAg ICA5ICAgICAgICAgICAgMCAgICAgICAgICAgMyAgICAgMyAgICAgMCAgICAgICAgICAgIDAg ICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQxNCAoc2xlZXAgbXV0 ZXg6RElSSEFTSCkKICAgMTE4ICAgICAgICAgIDI2NSAgICAgICAgICAgIDAgICAgICAgICAg IDUgICAgNTMgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMv bmV0aW5ldC90Y3BfdGltZXIuYzo0MzggKHNsZWVwIG11dGV4OmlucCkKICAgIDExICAgICAg ICAgICAzMyAgICAgICAgICAgIDAgICAgICAgICAgMTEgICAgIDMgICAgIDAgICAgICAgICAg ICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3Jlc291cmNlLmM6Njc3 IChzbGVlcCBtdXRleDpwcm9jZXNzIGxvY2spCiAgICAgNCAgICAgICAgICAgMjMgICAgICAg ICAgICAwICAgICAgICAgICA5ICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAg IDAgL3Vzci9zcmMvc3lzL3Vmcy9mZnMvZmZzX3Zmc29wcy5jOjE3MjkgKHNsZWVwIG11dGV4 OnZub2RlIGludGVybG9jaykKICAgICA4ICAgICAgICAgICAgOCAgICAgICAgICAgIDAgICAg ICAgICAgIDEgICAgIDggICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3Ny Yy9zeXMva2Vybi92ZnNfY2x1c3Rlci5jOjg0MSAoc2xlZXAgbXV0ZXg6dm5vZGUgaW50ZXJs b2NrKQogICAgIDQgICAgICAgICAgICA0ICAgICAgICAgICAgMCAgICAgICAgICAgMSAgICAg NCAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tl cm5fcmVzb3VyY2UuYzoxMjc2IChzbGVlcCBtdXRleDp1aWRpbmZvIGhhc2gpCiAgICAgMiAg ICAgICAgICAgIDkgICAgICAgICAgICAwICAgICAgICAgICA0ICAgICAyICAgICAwICAgICAg ICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX2Jpby5jOjEzMjAg KHNsZWVwIG11dGV4OnZtIHBhZ2UgcXVldWUgbXV0ZXgpCiAgICAgMyAgICAgICAgICAgMjAg ICAgICAgICAgICAwICAgICAgICAgICA4ICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAg ICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9kZXNjcmlwLmM6MTUwMiAoc3g6Zmls ZWRlc2Mgc3RydWN0dXJlKQogICAgMjIgICAgICAgICAgMzgxICAgICAgICAgICAgMCAgICAg ICAgICA2NiAgICAgNSAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3Jj L3N5cy9rZXJuL2tlcm5fc3lzY3RsLmM6MTM5NiAoc3g6c3lzY3RsIGxvY2spCiAgICAyMCAg ICAgICAgICAgODcgICAgICAgICAgICAwICAgICAgICAgICA4ICAgIDEwICAgICAwICAgICAg ICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl90aW1lLmM6NjEx IChzbGVlcCBtdXRleDpwcm9jZXNzIGxvY2spCiAgICAxMCAgICAgICAgICAzOTkgICAgICAg ICAgICAwICAgICAgICAgMTU4ICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAg IDAgL3Vzci9zcmMvc3lzL3ZtL3Zub2RlX3BhZ2VyLmM6MjA4IChzbGVlcCBtdXRleDp2bSBv YmplY3QpCiAgICAyMiAgICAgICAgMTk4MTcgICAgICAgICA4ODQ0ICAgICAgICA3MzExICAg ICAyICAgICAxICAgICAgICAgMTQ0NCAgICAgICAgICA3ODMgL3Vzci9zcmMvc3lzL2tlcm4v a2Vybl9zd2l0Y2guYzoyNzIgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jaykKICAzNTMzICAgICAg ICAzNDUyMCAgICAgICAgICAgIDAgICAgICAgICAgMjQgIDE0MzggICAgIDAgICAgICAgICAg IDEwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfbW91bnQuYzoyMDI5IChz bGVlcCBtdXRleDpzdHJ1Y3QgbW91bnQgbXR4KQogICAgMTMgICAgICAgICA1MjM1ICAgICAg ICAgODMyMSAgICAgICAgMTg3MiAgICAgMiAgICAgNCAgICAgICAgICA0MjUgICAgICAgICAg OTAxIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfdHVybnN0aWxlLmM6MjAzIChzcGluIG11dGV4 OnNjaGVkIGxvY2spCiAgICAyMSAgICAgICAgIDE0MzUgICAgICAgICAgICAwICAgICAgICAg NTMwICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lz L2tlcm4vdWlwY19zb2NrZXQuYzoyODAgKHNsZWVwIG11dGV4OnNvX2dsYWJlbCkKICAgIDQw ICAgICAgICAgICA5NSAgICAgICAgICAgIDAgICAgICAgICAgIDMgICAgMzEgICAgIDAgICAg ICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi91aXBjX3VzcnJlcS5j OjYyMyAoc2xlZXAgbXV0ZXg6dW5wX210eCkKICAgIDM1ICAgICAgICAgICA3OSAgICAgICAg ICAgIDAgICAgICAgICAgIDMgICAgMjYgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAg MCAvdXNyL3NyYy9zeXMva2Vybi91aXBjX3VzcnJlcS5jOjYyNiAoc2xlZXAgbXV0ZXg6dW5w X210eCkKICAgICA1ICAgICAgICAgICAgNyAgICAgICAgICAgIDAgICAgICAgICAgIDIgICAg IDMgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdWZzL2Zm cy9mZnNfdmZzb3BzLmM6MTc3MyAoc2xlZXAgbXV0ZXg6dm5vZGUgaW50ZXJsb2NrKQogICAg IDUgICAgICAgICAxMDA4ICAgICAgICAgICAgMCAgICAgICAgIDM1MiAgICAgMiAgICAgMCAg ICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3VpcGNfc29ja2V0 LmM6Mjk5IChzbGVlcCBtdXRleDpzb19nbGFiZWwpCiAgICAgNCAgICAgICAgICAgMjcgICAg ICAgICAgICAwICAgICAgICAgIDEwICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAg ICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9leGl0LmM6NDA5IChzeDphbGxwcm9jKQog ICAxMDggICAgICAgIDM4ODg0ICAgICAgICAgIDcxNCAgICAgICAgMTU1MSAgICAyNSAgICAg MCAgICAgICAgICAgNTkgICAgICAgICAgIDI2IC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfc2xl ZXBxdWV1ZS5jOjQwOSAoc3BpbiBtdXRleDpzbGVlcHEgY2hhaW4pCiAgICAgNiAgICAgICAg ICAgMzEgICAgICAgICAgICAwICAgICAgICAgIDEwICAgICAzICAgICAwICAgICAgICAgICAg MCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9kZXNjcmlwLmM6MTU1MiAo c3g6ZmlsZWRlc2Mgc3RydWN0dXJlKQogICAgMTcgICAgICAgICAgIDgwICAgICAgICAgICA0 OCAgICAgICAgICAyNCAgICAgMyAgICAgMiAgICAgICAgICAgIDEgICAgICAgICAgICA0IC91 c3Ivc3JjL3N5cy9rZXJuL3Zmc19tb3VudC5jOjIwNjcgKHNsZWVwIG11dGV4OnN0cnVjdCBt b3VudCBtdHgpCiAgICA3NCAgICAgICAgIDMwMjkgICAgICAgICAgICAwICAgICAgICAgIDYz ICAgIDQ4ICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tl cm4va2Vybl90aW1lLmM6NjU3IChzbGVlcCBtdXRleDpwcm9jZXNzIGxvY2spCiAgICAgMSAg ICAgICAgICAgIDEgICAgICAgICAgICAwICAgICAgICAgICAxICAgICAxICAgICAwICAgICAg ICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MjQzNiAo c2xlZXAgbXV0ZXg6VU1BIFNsYWJzKQogICAgIDMgICAgICAgICAgICAzICAgICAgICAgICAg MCAgICAgICAgICAgMSAgICAgMyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91 c3Ivc3JjL3N5cy9rZXJuL3VpcGNfdXNycmVxLmM6MTMzMiAoc2xlZXAgbXV0ZXg6c29fcmN2 KQogICAgIDQgICAgICAgICAgICA4ICAgICAgICAgICAgMCAgICAgICAgICAgMyAgICAgMiAg ICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29y ZS5jOjQxNCAoc2xlZXAgbXV0ZXg6VU1BIFJDbnRTbGFicykKICAgIDE3ICAgICAgICAgMTg5 MiAgICAgICAgICAgIDAgICAgICAgICA3MzkgICAgIDIgICAgIDAgICAgICAgICAgICAwICAg ICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfc3Vici5jOjI5ODUgKHNsZWVwIG11 dGV4OnZub2RlX2ZyZWVfbGlzdCkKICAgICA0ICAgICAgICAgICAxMiAgICAgICAgICAgIDAg ICAgICAgICAgIDMgICAgIDQgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNy L3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0MTQgKHNsZWVwIG11dGV4OmF0YV9jb21wb3NpdGUp CiAgICAgNCAgICAgICAgICAgIDggICAgICAgICAgICAwICAgICAgICAgICAzICAgICAyICAg ICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3Jl LmM6NDE0IChzbGVlcCBtdXRleDpGaWxlcykKICAgIDEyICAgICAgICAgMTkxMSAgICAgICAg ICAgIDAgICAgICAgICA3MzkgICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAg MCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfc3Vici5jOjMwMTMgKHNsZWVwIG11dGV4OnZub2Rl X2ZyZWVfbGlzdCkKICAgICA1ICAgICAgICAgICAyNiAgICAgICAgICAgIDAgICAgICAgICAg MTIgICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMv a2Vybi9rZXJuX3Jlc291cmNlLmM6Nzk2IChzbGVlcCBtdXRleDpwcm9jZXNzIGxvY2spCiAg ICAgNSAgICAgICAgICAgMjIgICAgICAgICAgICAwICAgICAgICAgICA3ICAgICAzICAgICAw ICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6 MTg3NCAoc2xlZXAgbXV0ZXg6aW5wY2IpCiAgICAgMiAgICAgICAgICAgIDcgICAgICAgICAg ICAwICAgICAgICAgICAzICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAg L3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6NDE0IChzbGVlcCBtdXRleDpWTVNQQUNFKQog ICAgMjIgICAgICAgICAyODU5ICAgICAgICAgICAgMCAgICAgICAgMTA3MSAgICAgMiAgICAg MCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3VpcGNfc29j a2J1Zi5jOjI5MSAoc2xlZXAgbXV0ZXg6cHJvY2VzcyBsb2NrKQogICAgMTYgICAgICAgICAg IDIwICAgICAgICAgICAgMCAgICAgICAgICAgMyAgICAgNiAgICAgMCAgICAgICAgICAgIDAg ICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3VpcGNfdXNycmVxLmM6NzI2IChzbGVl cCBtdXRleDp1bnBfbXR4KQogICAgNjcgICAgICAgICAgOTY3ICAgICAgICAgICAgMCAgICAg ICAgICAzNSAgICAyNyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3Jj L3N5cy9rZXJuL2ltZ2FjdF9lbGYuYzozMjIgKHN4OnVzZXIgbWFwKQogICAgIDUgICAgICAg ICAgICA5ICAgICAgICAgICAgMCAgICAgICAgICAgMyAgICAgMyAgICAgMCAgICAgICAgICAg IDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQxNCAoc2xlZXAg bXV0ZXg6MTYpCiAgICAgNyAgICAgICAgICAxNDUgICAgICAgICAgICAwICAgICAgICAgIDQ1 ICAgICAzICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL3Zt L3VtYV9jb3JlLmM6MjMzNSAoc2xlZXAgbXV0ZXg6bWJ1ZikKICAgICA0ICAgICAgICAgICAy OSAgICAgICAgICAgIDAgICAgICAgICAgMTAgICAgIDIgICAgIDAgICAgICAgICAgICAwICAg ICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2Rlc2NyaXAuYzoxNjU2IChzeDpm aWxlZGVzYyBzdHJ1Y3R1cmUpCiAgICAgNiAgICAgICAgICAxMDggICAgICAgICAgICAwICAg ICAgICAgIDM1ICAgICAzICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9z cmMvc3lzL3ZtL3Zub2RlX3BhZ2VyLmM6MzYxIChzbGVlcCBtdXRleDp2bSBvYmplY3QpCiAg ICAxNCAgICAgICAgICAgOTMgICAgICAgICAgICAwICAgICAgICAgIDEwICAgICA5ICAgICAw ICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9kZXNj cmlwLmM6MTY3MCAoc3g6ZmlsZWRlc2Mgc3RydWN0dXJlKQogICAgIDUgICAgICAgICAgIDEw ICAgICAgICAgICAgMCAgICAgICAgICAgMyAgICAgMyAgICAgMCAgICAgICAgICAgIDAgICAg ICAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQxNCAoc2xlZXAgbXV0ZXg6 VU1BIEhhc2gpCiAgICAyNSAgICAgICAgICAgMjUgICAgICAgICAgICAwICAgICAgICAgICAx ICAgIDI1ICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tl cm4vdmZzX2Jpby5jOjE1MzEgKHNsZWVwIG11dGV4OnZtIHBhZ2UgcXVldWUgbXV0ZXgpCiAg ICAzNiAgICAgICAgICAgMzYgICAgICAgICAgICAwICAgICAgICAgICAxICAgIDM2ICAgICAw ICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdWlwY191c3Jy ZXEuYzo4MDQgKHNsZWVwIG11dGV4OnVucF9tdHgpCiAgICAgNSAgICAgICAgICAgMTAgICAg ICAgICAgICAwICAgICAgICAgICAzICAgICAzICAgICAwICAgICAgICAgICAgMCAgICAgICAg ICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6NDE0IChzbGVlcCBtdXRleDp0Y3B0 dykKICAxMjEwICAgICAgICA0MDQ3OCAgICAgICAgICAgMjQgICAgICAgMTUzMjIgICAgIDIg ICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMiAvdXNyL3NyYy9zeXMva2Vybi9rZXJu X2Rlc2NyaXAuYzoyMDA3IChzbGVlcCBtdXRleDpzbGVlcCBtdHhwb29sKQogICAgIDQgICAg ICAgICAgIDM5ICAgICAgICAgICAgMCAgICAgICAgICAxNSAgICAgMiAgICAgMCAgICAgICAg ICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19iaW8uYzoyOTQgKHNs ZWVwIG11dGV4Om5lZWRzYnVmZmVyIGxvY2spCiAgICAxMSAgICAgICAgICAgNzUgICAgICAg ICAgICAwICAgICAgICAgIDEyICAgICA2ICAgICAwICAgICAgICAgICAgMSAgICAgICAgICAg IDAgL3Vzci9zcmMvc3lzL3ZtL3ZtX3BhZ2VvdXQuYzoxNDQ2IChzbGVlcCBtdXRleDp2bSBw YWdlIHF1ZXVlIGZyZWUgbXV0ZXgpCiAgICAgMyAgICAgICAgICAgIDUgICAgICAgICAgICAw ICAgICAgICAgICAyICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vz ci9zcmMvc3lzL2Rldi9tZmkvbWZpLmM6MjQ5NyAoc2xlZXAgbXV0ZXg6TUZJIEkvTyBsb2Nr KQogICAgMTAgICAgICAgICAxMTI0ICAgICAgICAgICAgMCAgICAgICAgIDQzMCAgICAgMiAg ICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19i aW8uYzozMjEgKHNsZWVwIG11dGV4Om5lZWRzYnVmZmVyIGxvY2spCiAgICA0MyAgICAgICAg ICA1NDYgICAgICAgICAgICAwICAgICAgICAgIDE2ICAgIDM0ICAgICAwICAgICAgICAgICAg MCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL25ldGluZXQvdWRwX3VzcnJlcS5jOjI0MSAo c2xlZXAgbXV0ZXg6c29fcmN2KQogICAgNDggICAgICAgICAgODM3ICAgICAgICAgICAgMCAg ICAgICAgICA3MCAgICAxMSAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Iv c3JjL3N5cy9rZXJuL2tlcm5fcmVzb3VyY2UuYzo5NTggKHNsZWVwIG11dGV4OnByb2Nlc3Mg bG9jaykKICAgIDU3ICAgICAgICAgICA5NiAgICAgICAgICAgIDAgICAgICAgICAgIDMgICAg MzIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi91 aXBjX3VzcnJlcS5jOjg3MiAoc2xlZXAgbXV0ZXg6dW5wX210eCkKICAgIDIyICAgICAgICAg IDY0MCAgICAgICAgICAgIDAgICAgICAgICAgNjcgICAgIDkgICAgIDAgICAgICAgICAgICAw ICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3NpZy5jOjIyODkgKHNwaW4g bXV0ZXg6c2xlZXBxIGNoYWluKQogICAgMjIgICAgICAgICAzNDUxICAgICAgICAgICAgMCAg ICAgICAgMTI5NSAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Iv c3JjL3N5cy9rZXJuL2tlcm5fZGVzY3JpcC5jOjE3ODUgKHN4OmZpbGVkZXNjIHN0cnVjdHVy ZSkKICAgICA3ICAgICAgICAgIDk5MyAgICAgICAgICAgIDAgICAgICAgICAzOTQgICAgIDIg ICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNf YmlvLmM6MzYzIChzbGVlcCBtdXRleDpuZWVkc2J1ZmZlciBsb2NrKQogIDIxNDMgICAgICAg IDE2Nzc2ICAgICAgICAgIDExMyAgICAgICAgIDEyMCAgIDEzOSAgICAgMCAgICAgICAgICAg IDEgICAgICAgICAgICAzIC91c3Ivc3JjL3N5cy9uZXRpbmV0L3RjcF90aW1lci5jOjEyOCAo c2xlZXAgbXV0ZXg6dGNwKQogICAgIDMgICAgICAgICAgICA4ICAgICAgICAgICAgMCAgICAg ICAgICAgMyAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3Jj L3N5cy92bS91bWFfY29yZS5jOjQxNCAoc2xlZXAgbXV0ZXg6aXRpbWVyKQogICAgIDUgICAg ICAgICAgIDIzICAgICAgICAgICAgMCAgICAgICAgICAgOCAgICAgMiAgICAgMCAgICAgICAg ICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZGVzY3JpcC5jOjE4 MDkgKHN4OmZpbGVkZXNjIHN0cnVjdHVyZSkKICAyNjk4ICAgICAgMjcyODk4OSAgICAgICAg MjYxNzAgICAgICAyNzY3NTIgICAgIDkgICAgIDAgICAgICAgICAgMzk1ICAgICAgICAgIDk0 NSAvdXNyL3NyYy9zeXMva2Vybi92ZnNfY2FjaGUuYzo0NDAgKHNsZWVwIG11dGV4OnZub2Rl IGludGVybG9jaykKICAgMTc0ICAgICAgICAgNzY4MiAgICAgICAgIDM0OTkgICAgICAgICA2 MDUgICAgMTIgICAgIDUgICAgICAgICAgIDY0ICAgICAgICAgICA2MSAvdXNyL3NyYy9zeXMv a2Vybi9zeXNfZ2VuZXJpYy5jOjc1MCAoc2xlZXAgbXV0ZXg6c2VsbGNrKQogICA2MzIgICAg ICAgIDM3NzY0ICAgICAgICAgICAgMCAgICAgICAxNTIxNiAgICAgMiAgICAgMCAgICAgICAg ICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZGVzY3JpcC5jOjEy ODcgKHNsZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAgIDI5ICAgICAgICAgNTM0NyAgICAg ICAgICAxOTggICAgICAgICA5NzIgICAgIDUgICAgIDAgICAgICAgICAgICAxICAgICAgICAg ICAgMyAvdXNyL3NyYy9zeXMvbmV0aW5ldC90Y3BfdGltZXIuYzoxNTUgKHNsZWVwIG11dGV4 OnRjcCkKICAgMTIzICAgICAgICAxOTQ5MiAgICAgICAgIDM3MzUgICAgICAgICA2MDkgICAg MzIgICAgIDYgICAgICAgICAgIDYzICAgICAgICAgICA2MiAvdXNyL3NyYy9zeXMva2Vybi9z eXNfZ2VuZXJpYy5jOjc1OSAoc2xlZXAgbXV0ZXg6c2VsbGNrKQogICAgIDUgICAgICAgICAg IDM2ICAgICAgICAgICAgMCAgICAgICAgICAxNCAgICAgMiAgICAgMCAgICAgICAgICAgIDAg ICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZGVzY3JpcC5jOjE4MzQgKHN4 OmZpbGVkZXNjIHN0cnVjdHVyZSkKICAgICA1ICAgICAgICAgICAgNSAgICAgICAgICAgIDAg ICAgICAgICAgIDEgICAgIDUgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNy L3NyYy9zeXMvdm0vdm1fcGFnZXIuYzo0NzUgKHNsZWVwIG11dGV4OnZub2RlIGludGVybG9j aykKICAgNzkwICAgICAgIDEyMDQ1MyAgICAgICAgICAgIDUgICAgICAgNDkwMTYgICAgIDIg ICAgIDAgICAgICAgICAgICAxICAgICAgICAgICAgMSAvdXNyL3NyYy9zeXMva2Vybi9rZXJu X2Rlc2NyaXAuYzoyMTM5IChzbGVlcCBtdXRleDpzbGVlcCBtdHhwb29sKQogICAgMTcgICAg ICAgICAgMTE3ICAgICAgICAgICAgMCAgICAgICAgICAxMCAgICAxMSAgICAgMCAgICAgICAg ICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZXhpdC5jOjI5NiAo c2xlZXAgbXV0ZXg6R2lhbnQpCiAgICAgNSAgICAgICAgICAgMzMgICAgICAgICAgICAwICAg ICAgICAgIDEyICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9z cmMvc3lzL3ZtL3ZtX3BhZ2VvdXQuYzoxNDc4IChzbGVlcCBtdXRleDp2bSBwYWdlIHF1ZXVl IG11dGV4KQogIDcyOTcgICAgICAgIDQxMTY1ICAgICAgICAgICAgMCAgICAgICAgICAxMiAg MzQzMCAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJu L3Zmc19zdWJyLmM6MTYzOCAobG9ja21ncjpzeW5jZXIpCiAgICAxMCAgICAgICAgICAgMzAg ICAgICAgICAgICAwICAgICAgICAgIDEwICAgICAzICAgICAwICAgICAgICAgICAgMCAgICAg ICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9leGl0LmM6NzQ3IChzeDphbGxwcm9j KQogICAgMTUgICAgICAgICAgMTIwICAgICAgICAgICAgMCAgICAgICAgICAxNCAgICAgOCAg ICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5f ZXhlYy5jOjgyMCAoc2xlZXAgbXV0ZXg6dm0gb2JqZWN0KQogICAxNzAgICAgICAgIDI3MzYy ICAgICAgICAgICAgMCAgICAgICAgIDQ5NSAgICA1NSAgICAgMCAgICAgICAgICAgIDAgICAg ICAgICAgICAwIC91c3Ivc3JjL3N5cy9uZXRpbmV0L3RjcF9zeW5jYWNoZS5jOjY0OCAoc2xl ZXAgbXV0ZXg6aW5wKQogICAgMzAgICAgICAgICAgIDMwICAgICAgICAgICAgMCAgICAgICAg ICAgMSAgICAzMCAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5 cy9rZXJuL3N1YnJfc2xlZXBxdWV1ZS5jOjc1NCAoc3BpbiBtdXRleDpzbGVlcHEgY2hhaW4p CiAgMTM2NyAgICAgICAgODU5MzIgICAgICAgICA3OTA4ICAgICAgIDE1MjA3ICAgICA1ICAg ICAwICAgICAgICAgICAxMyAgICAgICAgICAgMTEgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9k ZXNjcmlwLmM6MTM2NiAoc3g6ZmlsZWxpc3QgbG9jaykKICAgICA1ICAgICAgICAgICA0MyAg ICAgICAgICAgIDAgICAgICAgICAgMTggICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAg ICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfYmlvLmM6Mzg0MSAoc2xlZXAgbXV0ZXg6 dm5vZGUgaW50ZXJsb2NrKQogICAgIDUgICAgICAgICAgIDYxICAgICAgICAgICAgMCAgICAg ICAgICAyMCAgICAgMyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3Jj L3N5cy9rZXJuL3Zmc19iaW8uYzozODUxIChzbGVlcCBtdXRleDp2bm9kZSBpbnRlcmxvY2sp CiAgICAxMiAgICAgICAgICAgMjIgICAgICAgICAgICAwICAgICAgICAgICAyICAgIDExICAg ICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9w cm9jLmM6MzA0IChzbGVlcCBtdXRleDpHaWFudCkKICAgIDEyICAgICAgICAgICA4MiAgICAg ICAgICAgIDAgICAgICAgICAgMTAgICAgIDggICAgIDAgICAgICAgICAgICAwICAgICAgICAg ICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2V4aXQuYzoxMzggKHNsZWVwIG11dGV4OnBy b2Nlc3MgbG9jaykKICAgIDc5ICAgICAgICAzNDMwOSAgICAgICAgICAgNTUgICAgICAgIDMy MTYgICAgMTAgICAgIDAgICAgICAgICAgIDkwICAgICAgICAgICAgMiAvdXNyL3NyYy9zeXMv a2Vybi9zdWJyX3NsZWVwcXVldWUuYzo3ODEgKHNwaW4gbXV0ZXg6c2xlZXBxIGNoYWluKQog ICAgMTIgICAgICAgICAgNDM2ICAgICAgICAgICAgMCAgICAgICAgIDEyMCAgICAgMyAgICAg MCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9jb250cmliL2lwZmls dGVyL25ldGluZXQvaXBfbmF0LmM6NDQ0NiAocnc6aXBmIElQIE5BVCByd2xvY2spCiAgICAx NyAgICAgICAgICAgMjggICAgICAgICAgICAwICAgICAgICAgICAyICAgIDE0ICAgICAwICAg ICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9wcm9jLmM6 MzIwIChzbGVlcCBtdXRleDpHaWFudCkKICAgICA1ICAgICAgICAgICAyNiAgICAgICAgICAg IDAgICAgICAgICAgMTAgICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAv dXNyL3NyYy9zeXMva2Vybi9rZXJuX2V4aXQuYzo3OTkgKHN4OmFsbHByb2MpCiAgICAgNSAg ICAgICAgICAgOTggICAgICAgICAgICAwICAgICAgICAgIDM1ICAgICAyICAgICAwICAgICAg ICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9kZXNjcmlwLmM6 MjIyNSAoc2xlZXAgbXV0ZXg6c2xlZXAgbXR4cG9vbCkKICAgICA1ICAgICAgICAgICA5MyAg ICAgICAgICAgIDAgICAgICAgICAgMzUgICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAg ICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2Rlc2NyaXAuYzoyMjM5IChzbGVlcCBt dXRleDpzbGVlcCBtdHhwb29sKQogICAgIDUgICAgICAgICAgIDEwICAgICAgICAgICAgMCAg ICAgICAgICAgMyAgICAgMyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Iv c3JjL3N5cy92bS91bWFfY29yZS5jOjQxNCAoc2xlZXAgbXV0ZXg6dW5wY2IpCiAgICAgNCAg ICAgICAgICAgMTAgICAgICAgICAgICAwICAgICAgICAgICAzICAgICAzICAgICAwICAgICAg ICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MjMzNSAo c2xlZXAgbXV0ZXg6MzIpCiAgICAxMyAgICAgICAgICAgNTcgICAgICAgICAgICAwICAgICAg ICAgIDE1ICAgICAzICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMv c3lzL3ZtL3ZtX2tlcm4uYzo0NDAgKHN4OnVzZXIgbWFwKQogICAgIDUgICAgICAgICAgMjE1 ICAgICAgICAgICAgMCAgICAgICAgICA2MCAgICAgMyAgICAgMCAgICAgICAgICAgIDAgICAg ICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fbXV0ZXguYzoxNDEgKHNsZWVwIG11 dGV4OmJ1ZmZlciBkYWVtb24gbG9jaykKICAgIDQ1ICAgICAgICAgICA3NyAgICAgICAgICAg IDAgICAgICAgICAgIDIgICAgMzggICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAv dXNyL3NyYy9zeXMva2Vybi9rZXJuX3Byb3QuYzozMjUgKHN4OnByb2N0cmVlKQogICAxMzMg ICAgICAgIDE2NDIwICAgICAgICAgICAgNSAgICAgICAgIDQ4MiAgICAzNCAgICAgMCAgICAg ICAgICAgIDAgICAgICAgICAgICAxIC91c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC9wbWFwLmM6 MTk1OSAoc2xlZXAgbXV0ZXg6cG1hcCkKICAgICA5ICAgICAgICAgICAgOSAgICAgICAgICAg IDAgICAgICAgICAgIDEgICAgIDkgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAv dXNyL3NyYy9zeXMva2Vybi91aXBjX3VzcnJlcS5jOjczMyAoc2xlZXAgbXV0ZXg6c29fc25k KQogIDExMjMgICAgICAgIDI0ODAyICAgICAgICAgIDQzMSAgICAgICAgMTU4NSAgICAxNSAg ICAgMCAgICAgICAgICAgIDMgICAgICAgICAgICA5IC91c3Ivc3JjL3N5cy9rZXJuL3N5c19n ZW5lcmljLmM6OTI0IChzbGVlcCBtdXRleDpzZWxsY2spCiAgIDE2MSAgICAgICAgIDE3ODQg ICAgICAgICAgICAwICAgICAgICAgIDE1ICAgMTE4ICAgICAwICAgICAgICAgICAgMCAgICAg ICAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3ZtX2tlcm4uYzo0NjkgKHN4OnVzZXIgbWFwKQog ICAgMTIgICAgICAgICAgMjI5ICAgICAgICAgICAgMCAgICAgICAgICA3MCAgICAgMyAgICAg MCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fbG9j a2YuYzoxOTIgKHNsZWVwIG11dGV4OnZub2RlIGludGVybG9jaykKICAxMjI4ICAgICAgICAz Mjc4NyAgICAgICAgICAgODggICAgICAgIDI3NzggICAgMTEgICAgIDAgICAgICAgICAgIDI0 ICAgICAgICAgICAxMSAvdXNyL3NyYy9zeXMva2Vybi91aXBjX3NvY2tldC5jOjI0NjggKHNs ZWVwIG11dGV4OnNvX3NuZCkKICAgIDMxICAgICAgICAgICA4NSAgICAgICAgICAgIDAgICAg ICAgICAgIDQgICAgMjEgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3Ny Yy9zeXMva2Vybi9rZXJuX3Byb2MuYzozOTggKHNsZWVwIG11dGV4OkdpYW50KQogIDEwNzUg ICAgICAgIDUyODkyICAgICAgICAgIDM3MiAgICAgICAgMjQ0NiAgICAyMSAgICAgMCAgICAg ICAgICAgMzQgICAgICAgICAgIDExIC91c3Ivc3JjL3N5cy9rZXJuL3N5c19nZW5lcmljLmM6 OTMzIChzbGVlcCBtdXRleDpzZWxsY2spCiAgICAgNCAgICAgICAgICAgIDYgICAgICAgICAg ICAwICAgICAgICAgICAyICAgICAzICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAg L3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MjE5NSAoc2xlZXAgbXV0ZXg6MTI4IEJ1Y2tl dCkKICAgIDExICAgICAgICAgICAzMyAgICAgICAgICAgIDAgICAgICAgICAgMTAgICAgIDMg ICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJu X2V4aXQuYzoyMzkgKHNsZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAgIDE4ICAgICAgICAg IDEzMiAgICAgICAgICAgIDAgICAgICAgICAgMTAgICAgMTMgICAgIDAgICAgICAgICAgICAw ICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3Byb2MuYzo0MjQgKHNsZWVw IG11dGV4OkdpYW50KQogICAgIDIgICAgICAgICAgIDEzICAgICAgICAgICAgMCAgICAgICAg ICAgNyAgICAgMSAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5 cy9rZXJuL3VpcGNfdXNycmVxLmM6MTEzNSAoc2xlZXAgbXV0ZXg6dW5wX210eCkKICAgIDIx ICAgICAgICAgNDgyMCAgICAgICAgIDk1MTYgICAgICAgIDE5MTQgICAgIDIgICAgIDQgICAg ICAgICAgNTYyICAgICAgICAgIDk3OCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3R1cm5zdGls ZS5jOjcyOCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrKQogICAgNjYgICAgICAgICAgMTIwICAg ICAgICAgICAgMCAgICAgICAgICAgMiAgICA2MCAgICAgMCAgICAgICAgICAgIDAgICAgICAg ICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fcHJvdC5jOjM4NCAoc3g6cHJvY3RyZWUp CiAgIDIxMCAgICAgMjAwNDk4MTggICAgMjU4MjM3Mjg0ICAgICAxMDE3NTU5ICAgIDE5ICAg MjUzICAgICAgICA4MjI5MyAgICAgIDEwMTEyMzMgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9t dXRleC5jOjE0MSAoc2xlZXAgbXV0ZXg6bG9ja2J1aWxkZXIgbXR4cG9vbCkKICAgIDE5ICAg ICAgICAgIDQ3MyAgICAgICAgICAgIDAgICAgICAgICAxMjcgICAgIDMgICAgIDAgICAgICAg ICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3NpZy5jOjc2MSAo c3BpbiBtdXRleDpwcm9jZXNzIHNsb2NrKQogICAgMTQgICAgICAgICAgIDUwICAgICAgICAg ICAgMCAgICAgICAgICAgNCAgICAxMiAgICAgMCAgICAgICAgICAgIDEgICAgICAgICAgICAw IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fcHJvYy5jOjQ1NiAoc2xlZXAgbXV0ZXg6R2lhbnQp CiAgICAgNCAgICAgICAgICAgMTIgICAgICAgICAgICAwICAgICAgICAgICA0ICAgICAzICAg ICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9w cm9jLmM6MjQyIChzbGVlcCBtdXRleDpwcm9jZXNzIGxvY2spCiAgICAyNCAgICAgICAxMTI3 ODggICAgICAgICAgICAwICAgICAgIDQzNDYwICAgICAyICAgICAwICAgICAgICAgICAgMCAg ICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9jbG9jay5jOjIxOSAoc3BpbiBt dXRleDpwcm9jZXNzIHNsb2NrKQogICAgIDUgICAgICAgICAgIDQ5ICAgICAgICAgICAgMCAg ICAgICAgICAxMyAgICAgMyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Iv c3JjL3N5cy92bS91bWFfY29yZS5jOjIzMzUgKHNsZWVwIG11dGV4OmlucGNiKQogICAgMjkg ICAgICAgMTIxNzY1ICAgICAgIDE2MzU4NyAgICAgICA0ODAxNSAgICAgMiAgICAgMyAgICAg ICAgMTU0NDkgICAgICAgIDIxMjg4IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fY2xvY2suYzoy MjQgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jaykKICAgIDIzICAgICAgICAxNTcxNSAgICAgICAg ICAgMzYgICAgICAgIDYwMDEgICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAx MCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3RpbWVvdXQuYzoxOTEgKHNwaW4gbXV0ZXg6Y2Fs bG91dCkKICAgICA1ICAgICAgICAgICA0OCAgICAgICAgICAgIDAgICAgICAgICAgMTYgICAg IDMgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9r ZXJuX2V2ZW50LmM6ODQxIChzbGVlcCBtdXRleDprcXVldWUpCiAgICAgMyAgICAgICAgICAg IDUgICAgICAgICAgICAwICAgICAgICAgICAyICAgICAyICAgICAwICAgICAgICAgICAgMCAg ICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9leGl0LmM6MzQ5IChzbGVlcCBt dXRleDpzZXNzaW9uKQogICAgMTAgICAgICAgICAgIDQxICAgICAgICAgICAgMCAgICAgICAg ICAgNSAgICAgOCAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5 cy9uZXRpbmV0L3RjcF90aW1lci5jOjQyMyAoc2xlZXAgbXV0ZXg6dGNwKQogICAgIDMgICAg ICAgICAgICA2ICAgICAgICAgICAgMCAgICAgICAgICAgMiAgICAgMyAgICAgMCAgICAgICAg ICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjE4NzQgKHNs ZWVwIG11dGV4Ok1BUCBFTlRSWSkKICAgICA0ICAgICAgICAgICAgNiAgICAgICAgICAgIDAg ICAgICAgICAgIDIgICAgIDMgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNy L3NyYy9zeXMva2Vybi9rZXJuX3Byb2MuYzozMjIgKHNsZWVwIG11dGV4OnNlc3Npb24pCiAg ICAgNCAgICAgICAgICAgMTUgICAgICAgICAgICAwICAgICAgICAgICA1ICAgICAzICAgICAw ICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdHR5LmM6MjA4 MSAoc2xlZXAgbXV0ZXg6cHJvY2VzcyBsb2NrKQogICAgNzIgICAgICAgIDEyMDkyICAgICAg ICAgIDE2OCAgICAgICAgNDI1MSAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAg IDEwIC91c3Ivc3JjL3N5cy9kZXYvZW0vaWZfZW0uYzo5MDcgKHNsZWVwIG11dGV4OmVtMCkK ICAgNTYwICAgICAgICAgMTE2OCAgICAgICAgICAgIDAgICAgICAgICAgIDMgICAzODkgICAg IDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfc3Vi ci5jOjE2MzggKGxvY2ttZ3I6dWZzKQogICAgIDEgICAgICAgICAgICAzICAgICAgICAgICAg MCAgICAgICAgICAgMiAgICAgMSAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91 c3Ivc3JjL3N5cy9rZXJuL2tlcm5fcHJvYy5jOjMwNSAoc2xlZXAgbXV0ZXg6cHJvY2VzcyBs b2NrKQogICAxNjUgICAgICAgIDI5MDE0ICAgICAgICAgICAgMCAgICAgICAgMTYxNiAgICAx NyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9uZXRpbmV0 L3RjcF9pbnB1dC5jOjIyNDggKHNsZWVwIG11dGV4OnNvX3JjdikKICAgIDEwICAgICAgICAg ICAyNyAgICAgICAgICAgIDAgICAgICAgICAgIDMgICAgIDkgICAgIDAgICAgICAgICAgICAw ICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi91aXBjX3VzcnJlcS5jOjg5NSAoc2xl ZXAgbXV0ZXg6c29fc25kKQogICAgMTkgICAgICAgICAzMjY4ICAgICAgICAgIDE2MCAgICAg ICAgMTIwMSAgICAgMiAgICAgMCAgICAgICAgICAgIDQgICAgICAgICAgICA2IC91c3Ivc3Jj L3N5cy9rZXJuL3N5c19nZW5lcmljLmM6MTA3OSAoc2xlZXAgbXV0ZXg6c2VsbGNrKQogICAg MzMgICAgICAgICAgIDMzICAgICAgICAgICAgMCAgICAgICAgICAgMSAgICAzMyAgICAgMCAg ICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3VpcGNfdXNycmVx LmM6MTI1MCAoc2xlZXAgbXV0ZXg6dW5wX210eCkKICAgIDI1ICAgICAgICAgICAyNSAgICAg ICAgICAgIDAgICAgICAgICAgIDEgICAgMjUgICAgIDAgICAgICAgICAgICAwICAgICAgICAg ICAgMCAvdXNyL3NyYy9zeXMva2Vybi91aXBjX3VzcnJlcS5jOjEyNTEgKHNsZWVwIG11dGV4 OnVucF9tdHgpCiAgICA3OSAgICAgICAgNDAwODIgICAgICAgICAgNzc4ICAgICAgICA0MjUx ICAgICA5ICAgICAwICAgICAgICAgICA0MSAgICAgICAgICAgMzggL3Vzci9zcmMvc3lzL2Rl di9lbS9pZl9lbS5jOjkzOCAoc2xlZXAgbXV0ZXg6ZW0wKQogICAyMjQgICAgICAgIDE3NDUy ICAgICAgICAgICA5MCAgICAgICAgMTQxNCAgICAxMiAgICAgMCAgICAgICAgICAgIDQgICAg ICAgICAgICA2IC91c3Ivc3JjL3N5cy9nZW9tL2dlb21faW8uYzo2OCAoc2xlZXAgbXV0ZXg6 YmlvIHF1ZXVlKQogICAgIDkgICAgICAgICAgMTg2ICAgICAgICAgICAgMCAgICAgICAgICA0 NiAgICAgNCAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9r ZXJuL3N5c19waXBlLmM6NTcyIChzbGVlcCBtdXRleDpwaXBlIG11dGV4KQogICAgODQgICAg ICAgICAxNzU1ICAgICAgICAgICAgMCAgICAgICAgIDE3OCAgICAgOSAgICAgMCAgICAgICAg ICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC9wbWFwLmM6MjE0 MCAoc2xlZXAgbXV0ZXg6cG1hcCkKICAgICA0ICAgICAgICAgICAyMCAgICAgICAgICAgIDAg ICAgICAgICAgIDcgICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNy L3NyYy9zeXMvdm0vdW1hX2NvcmUuYzoxODc0IChzbGVlcCBtdXRleDptYnVmX2p1bWJvX3Bh Z2VzaXplKQogICAgIDUgICAgICAgICAgIDIxICAgICAgICAgICAgMCAgICAgICAgICAgNyAg ICAgMyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJu L3VpcGNfdXNycmVxLmM6MTI2OSAoc2xlZXAgbXV0ZXg6dW5wX210eCkKICAgICA0ICAgICAg ICAgICAyNyAgICAgICAgICAgIDAgICAgICAgICAgMTAgICAgIDIgICAgIDAgICAgICAgICAg ICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2V4aXQuYzozOTkgKHNs ZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAgICAzICAgICAgICAgICAxMyAgICAgICAgICAg IDAgICAgICAgICAgIDYgICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAv dXNyL3NyYy9zeXMvdWZzL3Vmcy91ZnNfdm5vcHMuYzoxNzUgKHNsZWVwIG11dGV4OnZub2Rl IGludGVybG9jaykKICAgIDgyICAgICAgICA0OTgwMyAgICAgICAgICA2NTAgICAgICAgIDM2 MDAgICAgMTMgICAgIDAgICAgICAgICAgIDE0ICAgICAgICAgICAyMSAvdXNyL3NyYy9zeXMv a2Vybi9rZXJuX3RpbWVvdXQuYzoyNDEgKHNsZWVwIG11dGV4OkdpYW50KQogICAgMjQgICAg ICAgIDc4MzM0ICAgICAgICAgNTM3MCAgICAgICAyODExMiAgICAgMiAgICAgMCAgICAgICAg ICA0NzUgICAgICAgICAxMTM0IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fdGltZW91dC5jOjI5 NiAoc3BpbiBtdXRleDpjYWxsb3V0KQogICAgMTAgICAgICAgICAgIDkwICAgICAgICAgICAg MCAgICAgICAgICAxNiAgICAgNSAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91 c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZXZlbnQuYzo5NDcgKHNsZWVwIG11dGV4OmtxdWV1ZSkK ICAgICA3ICAgICAgICAgICAyNCAgICAgICAgICAgIDAgICAgICAgICAgIDUgICAgIDQgICAg IDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zeXNfcGlw ZS5jOjYwOSAoc2xlZXAgbXV0ZXg6cGlwZSBtdXRleCkKICAgMTA4ICAgICAgICAyMzgyOCAg ICAgICAgICA4NDkgICAgICAgIDE0MzAgICAgMTYgICAgIDAgICAgICAgICAgICA4ICAgICAg ICAgICAyMyAvdXNyL3NyYy9zeXMva2Vybi9zeXNfZ2VuZXJpYy5jOjExMjcgKHNsZWVwIG11 dGV4OnNlbGxjaykKICAgIDEzICAgICAgICAgNDI2MSAgICAgICAgICAxMDAgICAgICAgIDE1 NjggICAgIDIgICAgIDAgICAgICAgICAgIDE5ICAgICAgICAgICAyMyAvdXNyL3NyYy9zeXMv a2Vybi9zdWJyX3R1cm5zdGlsZS5jOjcxMCAoc3BpbiBtdXRleDp0ZF9jb250ZXN0ZWQpCiAg ICA0MiAgICAgICAgMTMzMzAgICAgICAgICA1NDgzICAgICAgICAxNTY4ICAgICA4ICAgICAz ICAgICAgICAgIDQzMyAgICAgICAgICA3MTAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90dXJu c3RpbGUuYzo4OTQgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jaykKICAgICA2ICAgICAgICAgIDg3 NyAgICAgICAgICAgIDAgICAgICAgICAzNDYgICAgIDIgICAgIDAgICAgICAgICAgICAwICAg ICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3R1cm5zdGlsZS5jOjcxOCAoc3Bp biBtdXRleDp0ZF9jb250ZXN0ZWQpCiAgICAgOSAgICAgICAgICAgIDkgICAgICAgICAgICAw ICAgICAgICAgICAxICAgICA5ICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vz ci9zcmMvc3lzL2tlcm4va2Vybl9leGl0LmM6NDM0IChzbGVlcCBtdXRleDpwcm9jZXNzIGxv Y2spCiAgICAxMyAgICAgICAgICAzODYgICAgICAgICAgICAwICAgICAgICAgMTM1ICAgICAy ICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3lz X3NvY2tldC5jOjE1MyAoc2xlZXAgbXV0ZXg6c29fc25kKQogICAgIDMgICAgICAgICAgICA3 ICAgICAgICAgICAgMCAgICAgICAgICAgMyAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAg ICAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQxNCAoc2xlZXAgbXV0ZXg6 TW91bnRwb2ludHMpCiAgICAgMyAgICAgICAgICAgMTEgICAgICAgICAgICAwICAgICAgICAg ICA0ICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lz L2tlcm4va2Vybl9wcm9jLmM6NDAxIChzbGVlcCBtdXRleDpwcm9jZXNzIGxvY2spCiAgIDE0 NCAgICAgICAgICA4NzcgICAgICAgICAgICAwICAgICAgICAgIDEwICAgIDg3ICAgICAwICAg ICAgICAgICAgMSAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9leGl0LmM6 NDQ5IChzbGVlcCBtdXRleDpwcm9jZXNzIGxvY2spCiAgICA0MyAgICAgICAgIDY5ODcgICAg ICAgICAgICAwICAgICAgICAxMDIxICAgICA2ICAgICAwICAgICAgICAgICAgMCAgICAgICAg ICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdWlwY19zb2NrZXQuYzoyODMxIChzbGVlcCBtdXRl eDphY2NlcHQpCiAgICAgMyAgICAgICAgICAgMTMgICAgICAgICAgICAwICAgICAgICAgICA2 ICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tl cm4va2Vybl9zd2l0Y2guYzoyNzIgKHNwaW4gbXV0ZXg6dHVybnN0aWxlIGxvY2spCiAgICAg MiAgICAgICAgICAgIDIgICAgICAgICAgICAwICAgICAgICAgICAxICAgICAyICAgICAwICAg ICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL3Vmcy9mZnMvZmZzX3Zmc29w cy5jOjExNDkgKHNsZWVwIG11dGV4OkZGUykKICAgIDIzICAgICAgICAgNjI3NyAgICAgICAg ICAgMzYgICAgICAgIDIyODAgICAgIDIgICAgIDAgICAgICAgICAgICA0ICAgICAgICAgICAg OCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3RpbWVvdXQuYzozNDYgKHNwaW4gbXV0ZXg6Y2Fs bG91dCkKICAgIDM2ICAgICAgICAgIDM1NCAgICAgICAgICAzOTcgICAgICAgICAgNjcgICAg IDUgICAgIDUgICAgICAgICAgIDEwICAgICAgICAgICA0NCAvdXNyL3NyYy9zeXMva2Vybi9z dWJyX3R1cm5zdGlsZS5jOjIwMyAoc3BpbiBtdXRleDp0dXJuc3RpbGUgbG9jaykKICAgIDEx ICAgICAgICAgMjI3NCAgICAgICAgICAxOTYgICAgICAgICA4NDcgICAgIDIgICAgIDAgICAg ICAgICAgICAwICAgICAgICAgICAgOCAvdXNyL3NyYy9zeXMva2Vybi9zeXNfZ2VuZXJpYy5j OjExNDAgKHNwaW4gbXV0ZXg6c2xlZXBxIGNoYWluKQogICAxMjggICAgICAgICAgNzM2ICAg ICAgICAgICAgMCAgICAgICAgICAxMCAgICA3MyAgICAgMCAgICAgICAgICAgIDEgICAgICAg ICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZXhpdC5jOjQ2OSAoc2xlZXAgbXV0ZXg6 cHJvY2VzcyBsb2NrKQogICAgMTAgICAgICAgICAgMTAxICAgICAgICAgICAgMCAgICAgICAg ICAzNiAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5 cy9rZXJuL2tlcm5fZXZlbnQuYzoxMDAxIChzbGVlcCBtdXRleDprcXVldWUpCiAgICAgNSAg ICAgICAgICAgMjUgICAgICAgICAgICAwICAgICAgICAgIDEwICAgICAyICAgICAwICAgICAg ICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9wcm9jLmM6NDI2 IChzbGVlcCBtdXRleDpwcm9jZXNzIGxvY2spCiAgICAgNCAgICAgICAgICAgMTIgICAgICAg ICAgICAwICAgICAgICAgICA1ICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAg IDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9zaWcuYzo5NTkgKHNwaW4gbXV0ZXg6cHJvY2Vz cyBzbG9jaykKICAgICA1ICAgICAgICAgICA1MCAgICAgICAgICAgIDAgICAgICAgICAgMjAg ICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vy bi9rZXJuX2V2ZW50LmM6MTAyMSAoc2xlZXAgbXV0ZXg6a3F1ZXVlKQogICAgMjMgICAgICAg IDE2OTM1ICAgICAgICAxNTA2NSAgICAgICAgNjI0MiAgICAgMiAgICAgMiAgICAgICAgIDE2 NzIgICAgICAgICAxNzgyIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fY2xvY2suYzo0MTIgKHNw aW4gbXV0ZXg6c2NoZWQgbG9jaykKICAgIDExICAgICAgICAgIDMwMyAgICAgICAgICAgIDAg ICAgICAgICAxMDMgICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNy L3NyYy9zeXMva2Vybi9rZXJuX2Rlc2NyaXAuYzo3ODIgKHNsZWVwIG11dGV4OnNpZ2lvIGxv Y2spCiAgICAgNCAgICAgICAgICAgMjEgICAgICAgICAgICAwICAgICAgICAgIDEwICAgICAy ICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vy bl9rc2UuYzo5MSAoc3BpbiBtdXRleDprc2UgbG9jaykKICAgMTU3ICAgICAgICAgMjk2NSAg ICAgICAgICAgIDAgICAgICAgICAgNDQgICAgNjcgICAgIDAgICAgICAgICAgICAwICAgICAg ICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdm1fbWFwLmM6MTE3MyAoc3g6dXNlciBtYXApCiAg MTEyOSAgICAgICAyNjU3NjYgICAgICAgICAgICAwICAgICAgIDQ3MTk2ICAgICA1ICAgICAw ICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0L3Bt YXAuYzoyMjYxIChzbGVlcCBtdXRleDpwbWFwKQogIDE0NTEgICAgICAgIDM0NzIyICAgICAg ICAgICAgMCAgICAgICAxMzc5OSAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAg ICAwIC91c3Ivc3JjL3N5cy91ZnMvdWZzL3Vmc192bm9wcy5jOjI5MyAoc2xlZXAgbXV0ZXg6 dm5vZGUgaW50ZXJsb2NrKQogICAgODMgICAgICAgIDM0Njk3ICAgICAgICAgICAgMSAgICAg ICAxMzgwOSAgICAgMiAgICAgMCAgICAgICAgICAgIDEgICAgICAgICAgICAxIC91c3Ivc3Jj L3N5cy9rZXJuL3Zmc19zeXNjYWxscy5jOjEwNzAgKHNsZWVwIG11dGV4OnNsZWVwIG10eHBv b2wpCiAgICAgNCAgICAgICAgICAgIDggICAgICAgICAgICAwICAgICAgICAgICAzICAgICAy ICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9j b3JlLmM6NDE0IChzbGVlcCBtdXRleDpzYWNraG9sZSkKICAgICA5ICAgICAgICAgIDEyOCAg ICAgICAgICAgIDAgICAgICAgICAgMjIgICAgIDUgICAgIDAgICAgICAgICAgICAwICAgICAg ICAgICAgMCAvdXNyL3NyYy9zeXMvdWZzL3Vmcy91ZnNfZGlyaGFzaC5jOjM1MCAoc2xlZXAg bXV0ZXg6ZGlyaGFzaCkKICAgOTc3ICAgICAgICAgNzk2MSAgICAgICAgICAgIDAgICAgICAg ICA0NDkgICAgMTcgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9z eXMvdm0vdm1fbWFwLmM6MTIwMiAoc3g6dXNlciBtYXApCiAgICAyNCAgICAgICAgOTUwNzMg ICAgICAgICA4MTc0ICAgICAgIDM0Mjg0ICAgICAyICAgICAwICAgICAgICAgMTIxMiAgICAg ICAgIDE2NDQgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl90aW1lb3V0LmM6NDE5IChzcGluIG11 dGV4OmNhbGxvdXQpCiAgICAgNSAgICAgICAgICAgNTMgICAgICAgICAgICAwICAgICAgICAg IDE2ICAgICAzICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lz L2tlcm4va2Vybl9ldmVudC5jOjEwNzQgKHNsZWVwIG11dGV4OmtxdWV1ZSkKICAgICAzICAg ICAgICAgICAgMyAgICAgICAgICAgIDAgICAgICAgICAgIDEgICAgIDMgICAgIDAgICAgICAg ICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2V2ZW50LmM6MTY2 NCAoc2xlZXAgbXV0ZXg6dHR5KQogICAgMTIgICAgICAgICAzNDcwICAgICAgICAgICAgMCAg ICAgICAgMTU2OCAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Iv c3JjL3N5cy9rZXJuL3N1YnJfdHVybnN0aWxlLmM6ODM0IChzcGluIG11dGV4OnRkX2NvbnRl c3RlZCkKICAgIDIyICAgICAgICAxNTcxNyAgICAgICAgICAgIDAgICAgICAgIDYwMDEgICAg IDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvbmZzc2Vy dmVyL25mc19zcnZzb2NrLmM6Nzk2IChzbGVlcCBtdXRleDpuZnNkX210eCkKICAgICA1ICAg ICAgICAgICA1NCAgICAgICAgICAgIDAgICAgICAgICAgMjEgICAgIDIgICAgIDAgICAgICAg ICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdWZzL3Vmcy91ZnNfZGlyaGFzaC5j OjM2OCAoc2xlZXAgbXV0ZXg6ZGlyaGFzaCkKICAgICA1ICAgICAgICAgIDI1NSAgICAgICAg ICAgIDAgICAgICAgICAxMDcgICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAg MCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfc3lzY2FsbHMuYzo4MTMgKHN4OmZpbGVkZXNjIHN0 cnVjdHVyZSkKICAgIDExICAgICAgICAgIDExNyAgICAgICAgICAgIDAgICAgICAgICAgMzUg ICAgIDMgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdWZz L2Zmcy9mZnNfdm5vcHMuYzo2ODMgKHNsZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAgMjY3 ICAgICAgICAgIDI2NyAgICAgICAgICAgIDAgICAgICAgICAgIDEgICAyNjcgICAgIDAgICAg ICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdm1fbWFwLmM6MjQxMiAo c2xlZXAgbXV0ZXg6c3lzdGVtIG1hcCkKICAgICA5ICAgICAgICAgICA1MSAgICAgICAgICAg IDAgICAgICAgICAgIDggICAgIDYgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAv dXNyL3NyYy9zeXMva2Vybi9zdWJyX2V2ZW50aGFuZGxlci5jOjIxNSAoc2xlZXAgbXV0ZXg6 cHJvY2Vzc19leGVjKQogICAgIDIgICAgICAgICAgICA4ICAgICAgICAgICAgMCAgICAgICAg ICAgNCAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5 cy9rZXJuL2tlcm5fcHJvYy5jOjU3NCAoc2xlZXAgbXV0ZXg6c2Vzc2lvbikKICAgIDEyICAg ICAgICAgMTI2NiAgICAgICAgICAgIDAgICAgICAgICA0ODAgICAgIDIgICAgIDAgICAgICAg ICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3Jlc291cmNlLmM6 NjMzIChzcGluIG11dGV4OnNsZWVwcSBjaGFpbikKICAxMzM1ICAgICAgICA1MTE2NiAgICAg ICAgICAxNTQgICAgICAgIDg1MjcgICAgIDYgICAgIDAgICAgICAgICAgICA0ICAgICAgICAg ICAgOSAvdXNyL3NyYy9zeXMvbmV0L3JvdXRlLmM6MTk3IChzbGVlcCBtdXRleDpydGVudHJ5 KQogICAgIDUgICAgICAgICAgMzIwICAgICAgICAgICAgMCAgICAgICAgIDEyMCAgICAgMiAg ICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9jb250cmliL2lw ZmlsdGVyL25ldGluZXQvaXBfZnJhZy5jOjc4NiAocnc6aXBmIGZyYWdtZW50IHJ3bG9jaykK ICAgIDExICAgICAgICAgMjgzOSAgICAgICAgIDM0NTUgICAgICAgIDExMTcgICAgIDIgICAg IDMgICAgICAgICAgMjc4ICAgICAgICAgIDM3OCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3Ry YXAuYzoxODIgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jaykKICAgIDEwICAgICAgICAgICA3NyAg ICAgICAgICAgIDAgICAgICAgICAgMTIgICAgIDYgICAgIDAgICAgICAgICAgICAwICAgICAg ICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfc3Vici5jOjMxNzAgKHNsZWVwIG11dGV4 Om1vdW50bGlzdCkKICAxMjU1ICAgICAgIDEyOTUzMiAgICAgICAgICAgMjcgICAgICAgNDcx NTkgICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMSAvdXNyL3NyYy9zeXMv YW1kNjQvYW1kNjQvdHJhcC5jOjU4NiAoc2xlZXAgbXV0ZXg6cHJvY2VzcyBsb2NrKQogICAg IDMgICAgICAgICAgIDIwICAgICAgICAgICAyOSAgICAgICAgICAxMSAgICAgMSAgICAgMiAg ICAgICAgICAgIDAgICAgICAgICAgICAxIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fbXV0ZXgu YzoxNDEgKHNsZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAgICAxICAgICAgICAgICAgMyAg ICAgICAgICAgIDAgICAgICAgICAgIDIgICAgIDEgICAgIDAgICAgICAgICAgICAwICAgICAg ICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3Byb2MuYzo1NTQgKHNsZWVwIG11dGV4 OnByb2Nlc3MgbG9jaykKICAzMzA2ICAgICAgIDEzOTI1NiAgICAgICAgICAgIDAgICAgICAg IDEyNDEgICAxMTIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9z eXMva2Vybi91aXBjX3NvY2tidWYuYzoxNDUgKHN4OnNvX3NuZF9zeCkKICAyMDE0ICAgICAg IDEyNjIyMyAgICAgICAgICAgIDAgICAgICAgNDcxNTkgICAgIDIgICAgIDAgICAgICAgICAg ICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvYW1kNjQvYW1kNjQvdHJhcC5jOjU5NSAo c2xlZXAgbXV0ZXg6cHJvY2VzcyBsb2NrKQogICAgMTEgICAgICAgICAzNjc0ICAgICAgICAg ICAxMyAgICAgICAgMTU2OCAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAy IC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfdHVybnN0aWxlLmM6ODk1IChzcGluIG11dGV4OnRk X2NvbnRlc3RlZCkKICAxMzMyICAgICAgIDE2MjQ5OSAgICAgICA0MjYwMzIgICAgICAgNjI1 MDkgICAgIDIgICAgIDYgICAgICAgICAgIDMxICAgICAgICAgMjQxNCAvdXNyL3NyYy9zeXMv dWZzL3Vmcy91ZnNfdm5vcHMuYzozODggKHNsZWVwIG11dGV4OnZub2RlIGludGVybG9jaykK ICAgIDIxICAgICAgICAxMTU4MCAgICAgICAgICAzMTggICAgICAgIDQyMTEgICAgIDIgICAg IDAgICAgICAgICAgIDQ1ICAgICAgICAgICA2MiAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3Rp bWVvdXQuYzo1MDAgKHNwaW4gbXV0ZXg6Y2FsbG91dCkKICAgIDM3ICAgICAgICAgIDI1MCAg ICAgICAgICAgIDAgICAgICAgICAgMzMgICAgIDcgICAgIDAgICAgICAgICAgICAwICAgICAg ICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi91aXBjX3NvY2tldC5jOjI4NjQgKHNsZWVwIG11 dGV4OnNvX3NuZCkKICAgIDQwICAgICAgICAgOTE3MSAgICAgICAgICAgIDAgICAgICAgICA0 ODAgICAgMTkgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMv a2Vybi9rZXJuX3RpbWVvdXQuYzoyNDEgKHNsZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAg IDExICAgICAgICAgIDEzNiAgICAgICAgICAgIDAgICAgICAgICAgMzYgICAgIDMgICAgIDAg ICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi91aXBjX3NvY2tl dC5jOjI4ODAgKHNsZWVwIG11dGV4OnNvX3NuZCkKICAgICA1ICAgICAgICAgICA4NiAgICAg ICAgICAgMjUgICAgICAgICAgMzAgICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAg ICAgMSAvdXNyL3NyYy9zeXMvbmV0aW5ldC90Y3BfdGltZXdhaXQuYzoyNTMgKHNsZWVwIG11 dGV4OnNvX3JjdikKICAgICAyICAgICAgICAgICAgMiAgICAgICAgICAgIDAgICAgICAgICAg IDEgICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMv dm0vdW1hX2NvcmUuYzoyMzM1IChzbGVlcCBtdXRleDoxMDI0KQogICAgIDMgICAgICAgICAg IDQzICAgICAgICAgICAgMCAgICAgICAgICAyMCAgICAgMiAgICAgMCAgICAgICAgICAgIDAg ICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy91ZnMvdWZzL3Vmc19kaXJoYXNoLmM6NDU3IChz bGVlcCBtdXRleDpkaXJoYXNoKQogICAgMjYgICAgICAgICA1MjQ4ICAgICAgICAgMTc0OSAg ICAgICAgMTA1MCAgICAgNCAgICAgMSAgICAgICAgICAzMzUgICAgICAgICAgMTgyIC91c3Iv c3JjL3N5cy9rZXJuL3N1YnJfdHJhcC5jOjIzNiAoc3BpbiBtdXRleDpzY2hlZCBsb2NrKQog ICA2MDkgICAgICAgICAzMDE0ICAgICAgICAgICAgMCAgICAgICAgICAgOCAgIDM3NiAgICAg MCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2ltZ2FjdF9l bGYuYzo2NzIgKGxvY2ttZ3I6dWZzKQogICAgMTAgICAgICAgICAgMTA1ICAgICAgICAgICAg MCAgICAgICAgICAyMCAgICAgNSAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91 c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZXZlbnQuYzoxMTgyIChzbGVlcCBtdXRleDprcXVldWUp CiAgICA0MSAgICAgICAgICAyNTUgICAgICAgICAgIDI1ICAgICAgICAgIDU5ICAgICA0ICAg ICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDEgL3Vzci9zcmMvc3lzL2tlcm4vdWlwY19z b2NrZXQuYzoyODk5IChzbGVlcCBtdXRleDpzb19zbmQpCiAgICAgNCAgICAgICAgICAgMjcg ICAgICAgICAgICAwICAgICAgICAgIDEwICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAg ICAgICAgIDAgL3Vzci9zcmMvc3lzL25ldGluZXQvdGNwX3RpbWV3YWl0LmM6MjcyIChzbGVl cCBtdXRleDpzb19yY3YpCiAgICAzNyAgICAgICAgMTIxMzkgICAgICAgICAgIDM4ICAgICAg ICAxNDQ4ICAgICA4ICAgICAwICAgICAgICAgICAgMSAgICAgICAgICAgIDIgL3Vzci9zcmMv c3lzL2tlcm4va2Vybl9leGl0LmM6Njg2IChzbGVlcCBtdXRleDpwcm9jZXNzIGxvY2spCiAg ICAzOCAgICAgICAgIDExMDEgICAgICAgICAgICAwICAgICAgICAgMTc1ICAgICA2ICAgICAw ICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0L3Bt YXAuYzoyNDQxIChzbGVlcCBtdXRleDpwbWFwKQogICAgIDcgICAgICAgICAgICA3ICAgICAg ICAgICAgMCAgICAgICAgICAgMSAgICAgNyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAg ICAwIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19zeXNjYWxscy5jOjk1MSAoc3g6ZmlsZWRlc2Mg c3RydWN0dXJlKQogICAgIDUgICAgICAgICAgIDg2ICAgICAgICAgICAgMCAgICAgICAgICAz NiAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9r ZXJuL2tlcm5fZGVzY3JpcC5jOjk4NSAoc2xlZXAgbXV0ZXg6c2lnaW8gbG9jaykKICAgIDMy ICAgICAgICAgMjUzMCAgICAgICAgICAgIDAgICAgICAgICA1NjcgICAgIDQgICAgIDAgICAg ICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3NpZy5jOjY2 MyAoc2xlZXAgbXV0ZXg6c2lnYWN0cykKICAgIDEzICAgICAgICAgNjgxNSAgICAgICAgICAg IDAgICAgICAgIDI1OTAgICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAv dXNyL3NyYy9zeXMvYW1kNjQvYW1kNjQvcG1hcC5jOjI0NjMgKHNsZWVwIG11dGV4OnBtYXAp CiAgICAyMyAgICAgICAgIDIyNjYgICAgICAgICAgICAwICAgICAgICAgNDgxICAgICA0ICAg ICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3Zub2RlX3Bh Z2VyLmM6MTE5MiAoc2xlZXAgbXV0ZXg6dm0gb2JqZWN0KQogICAgIDMgICAgICAgICAgIDIy ICAgICAgICAgICAgMCAgICAgICAgICAxMCAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAg ICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZXhpdC5jOjcyMiAoc2xlZXAgbXV0 ZXg6cHJvY2VzcyBsb2NrKQogICAgIDUgICAgICAgICAgIDM4ICAgICAgICAgICAgMCAgICAg ICAgICAxNiAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3Jj L3N5cy9rZXJuL2tlcm5fZXZlbnQuYzoxMjU3IChzbGVlcCBtdXRleDprcXVldWUpCiAgICA4 NiAgICAgICAgIDE5OTcgICAgICAgICAgICAwICAgICAgICAgIDQ2ICAgIDQzICAgICAwICAg ICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2Rldi9yYW5kb20veWFycm93 LmM6MTkxIChzbGVlcCBtdXRleDpyYW5kb20gcmVzZWVkKQogICAgMTAgICAgICAgICAgIDI4 ICAgICAgICAgICAgMCAgICAgICAgICAgMyAgICAgOSAgICAgMCAgICAgICAgICAgIDAgICAg ICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZXZlbnQuYzoxMjY2IChzbGVlcCBt dXRleDprcXVldWUpCiAgICAgNCAgICAgICAgICAgMTEgICAgICAgICAgICAwICAgICAgICAg ICAzICAgICAzICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lz L2tlcm4va2Vybl9ldmVudC5jOjEyNzUgKHNsZWVwIG11dGV4OmtxdWV1ZSkKNjA0NTA0NjYg ICAxMDYwODI5MDA3ICAgMTMxNjcxNDIyMiAgICAgIDM0MDM1NSAgMzExNiAgMzg2OCAgICAg ICAgNjIwNzIgICAgICAgIDYxMjY0IC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19zdWJyLmM6MjAz NSAobG9ja21ncjp1ZnMpCiAgICAyMiAgICAgICAgICAxMzUgICAgICAgICAgICAwICAgICAg ICAgIDEwICAgIDEzICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMv c3lzL2tlcm4va2Vybl9mb3JrLmM6NTQ2IChzbGVlcCBtdXRleDpwcm9jZXNzIGdyb3VwKQog ICAgNTUgICAgICAgICA0NTgwICAgICAgICAgICAgMCAgICAgICAgIDQ2NyAgICAgOSAgICAg MCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy92bS92bm9kZV9wYWdl ci5jOjEyMjIgKHNsZWVwIG11dGV4OnZtIG9iamVjdCkKICAgICA2ICAgICAgICAgICAxMyAg ICAgICAgICAgIDAgICAgICAgICAgIDMgICAgIDQgICAgIDAgICAgICAgICAgICAwICAgICAg ICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0MTQgKHNsZWVwIG11dGV4Omhv c3RjYWNoZSkKICAgICA1ICAgICAgICAgICAyMiAgICAgICAgICAgIDAgICAgICAgICAgMTAg ICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vy bi9rZXJuX2V4aXQuYzo3NTkgKHNsZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAgICA4ICAg ICAgICAgIDQ2OCAgICAgICAgICAgIDAgICAgICAgICAxMjAgICAgIDMgICAgIDAgICAgICAg ICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvY29udHJpYi9pcGZpbHRlci9uZXRp bmV0L2lwX3N0YXRlLmM6MzA1MiAocnc6aXBmIElQIHN0YXRlIHJ3bG9jaykKICAgIDExICAg ICAgICAgIDIwMyAgICAgICAgICAgIDAgICAgICAgICAgNjcgICAgIDMgICAgIDAgICAgICAg ICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvYW1kNjQvYW1kNjQvbWFjaGRlcC5j OjMzOSAoc2xlZXAgbXV0ZXg6c2lnYWN0cykKICAgICA0ICAgICAgICAgICAyNSAgICAgICAg ICAgIDAgICAgICAgICAgMTAgICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAg MCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2V4aXQuYzo3NjIgKHNsZWVwIG11dGV4OnByb2Nl c3MgbG9jaykKICAgICA2ICAgICAgICAgICAzMCAgICAgICAgICAgIDAgICAgICAgICAgIDkg ICAgIDMgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdm0v dW1hX2NvcmUuYzoxODc0IChzbGVlcCBtdXRleDpzb2NrZXQpCiAgICAxNSAgICAgICAgICA0 NDggICAgICAgICAgICAwICAgICAgICAgIDYwICAgICA3ICAgICAwICAgICAgICAgICAgMCAg ICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL3Vmcy9mZnMvZmZzX3NvZnRkZXAuYzo3NTAgKHNs ZWVwIG11dGV4Om1vdW50bGlzdCkKICAyMzI2ICAgICAxNjQ1NzE2NSAgICAgMjA2NjMwMDQg ICAgIDExMjM4NzEgICAgMTQgICAgMTggICAgICAgMjc0MjAxICAgICAgICA3NTE3MyAvdXNy L3NyYy9zeXMva2Vybi9rZXJuX2xvY2suYzoyMDAgKHNsZWVwIG11dGV4OmxvY2tidWlsZGVy IG10eHBvb2wpCiAgIDIwNyAgICAgICAgICA3MjQgICAgICAgICAgICAwICAgICAgICAgICA0 ICAgMTgxICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tl cm4vaW1nYWN0X2VsZi5jOjgwNSAobG9ja21ncjp1ZnMpCiAgICAgMyAgICAgICAgICAgMTcg ICAgICAgICAgICAwICAgICAgICAgICA4ICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAg ICAgICAgIDAgL3Vzci9zcmMvc3lzL25ldGluZXQvdGNwX3N1YnIuYzo3ODIgKHNsZWVwIG11 dGV4OnNvX3JjdikKICAgICA1ICAgICAgICAgICAxNiAgICAgICAgICAgIDAgICAgICAgICAg IDUgICAgIDMgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMv a2Vybi9zeXNfcGlwZS5jOjk3NCAoc2xlZXAgbXV0ZXg6cGlwZSBtdXRleCkKICAgMTE0ICAg ICAgICAgNTY1MCAgICAgICAgICAgIDAgICAgICAgICAzMDAgICAgMTggICAgIDAgICAgICAg ICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdWZzL2Zmcy9mZnNfc29mdGRlcC5j Ojc2MyAoc2xlZXAgbXV0ZXg6bW91bnRsaXN0KQogICAxMTMgICAgICAgIDE3Njk0ICAgICAg ICAxMTk5NSAgICAgICAgMzAyNCAgICAgNSAgICAgMyAgICAgICAgICAyMTMgICAgICAgICAx MDM2IC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfdHVybnN0aWxlLmM6NTQ5IChzcGluIG11dGV4 OnR1cm5zdGlsZSBsb2NrKQogICAyMDIgICAgICA5NTkxMjgyICAgICAgICAgICAgMCAgICAg NDk2NjM5NyAgICAgMSAgICAgMCAgICAgICAgICA5MzIgICAgICAgICAgICAwIC91c3Ivc3Jj L3N5cy9rZXJuL3N1YnJfdHVybnN0aWxlLmM6NTU1IChzcGluIG11dGV4OnR1cm5zdGlsZSBs b2NrKQogICAgMTMgICAgICAgICAgIDM2ICAgICAgICAgICAgMCAgICAgICAgICAgNSAgICAg NyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9kZXYvcmFu ZG9tL3lhcnJvdy5jOjI3OCAoc2xlZXAgbXV0ZXg6cmFuZG9tIHJlc2VlZCkKICAgIDc0ICAg ICAgICAgMTQ3OSAgICAgICAgICAgIDAgICAgICAgICAgNDcgICAgMzEgICAgIDAgICAgICAg ICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvYW1kNjQvYW1kNjQvbXBfbWFjaGRl cC5jOjg0NSAoc3BpbiBtdXRleDpzbXAgcmVuZGV6dm91cykKICAgIDEwICAgICAgICAgMjMx OSAgICAgICAgICAgIDAgICAgICAgICA5MDAgICAgIDIgICAgIDAgICAgICAgICAgICAwICAg ICAgICAgICAgMCAvdXNyL3NyYy9zeXMvbGlia2Vybi9hcmM0cmFuZG9tLmM6MTM3IChzbGVl cCBtdXRleDphcmM0X210eCkKICAgIDEzICAgICAgICAgICAxMyAgICAgICAgICAgIDAgICAg ICAgICAgIDEgICAgMTMgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3Ny Yy9zeXMva2Vybi9zeXNfc29ja2V0LmM6MTA1IChzbGVlcCBtdXRleDpwcm9jZXNzIGxvY2sp CiAgIDExOSAgICAgICAgMzQ5MjYgICAgICAgICAgOTg5ICAgICAgICA4MDA2ICAgICA0ICAg ICAwICAgICAgICAgICAzNCAgICAgICAgICAgNTYgL3Vzci9zcmMvc3lzL2Rldi9lbS9pZl9l bS5jOjEzOTYgKHNsZWVwIG11dGV4OmVtMCkKICAgIDMxICAgICAgICAgIDY1OSAgICAgICAg ICAgIDAgICAgICAgICAgNDEgICAgMTYgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAg MCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfc3Vici5jOjIxMzAgKGxvY2ttZ3I6dWZzKQogICAg IDMgICAgICAgICAgICA3ICAgICAgICAgICAgMCAgICAgICAgICAgMyAgICAgMiAgICAgMCAg ICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQx NCAoc2xlZXAgbXV0ZXg6ZGl2Y2IpCiAgICAzNCAgICAgICAgICAgNzcgICAgICAgICAgICAw ICAgICAgICAgICA2ICAgIDEyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vz ci9zcmMvc3lzL2tlcm4va2Vybl9leGl0LmM6ODQ4IChzbGVlcCBtdXRleDpwcm9jZXNzIGxv Y2spCiAgIDE0MyAgICAgICAgNTIxNDMgICAgICAgICAxODU4ICAgICAgICAxNTY4ICAgIDMz ICAgICAxICAgICAgICAgICAgOCAgICAgICAgICAgODcgL3Vzci9zcmMvc3lzL2tlcm4vc3Vi cl90dXJuc3RpbGUuYzo1OTMgKHNwaW4gbXV0ZXg6dHVybnN0aWxlIGxvY2spCiAgICAgMyAg ICAgICAgICAgMjIgICAgICAgICAgICAwICAgICAgICAgICA4ICAgICAyICAgICAwICAgICAg ICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MjMzNSAo c2xlZXAgbXV0ZXg6bWJ1Zl9qdW1ib19wYWdlc2l6ZSkKICAgICA1ICAgICAgICAgICA0NiAg ICAgICAgICAgIDAgICAgICAgICAgMTYgICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAg ICAgICAgMCAvdXNyL3NyYy9zeXMvbmV0aW5ldC91ZHBfdXNycmVxLmM6MTEyMyAoc2xlZXAg bXV0ZXg6c29fcmN2KQogICAgNjAgICAgICAgICAyMjc2ICAgICAgICAgICAgMCAgICAgICAg IDI5MCAgICAgNyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5 cy9hbWQ2NC9hbWQ2NC9tcF9tYWNoZGVwLmM6ODgyIChzcGluIG11dGV4OnNtcCByZW5kZXp2 b3VzKQogICAgIDcgICAgICAgICAxMzY3ICAgICAgICAgICAgMCAgICAgICAgIDQ5MCAgICAg MiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy92bS92bV91 bml4LmM6ODEgKHNsZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAgICA2ICAgICAgICAgIDg1 NSAgICAgICAgICAgIDAgICAgICAgICAzMDEgICAgIDIgICAgIDAgICAgICAgICAgICAwICAg ICAgICAgICAgMCAvdXNyL3NyYy9zeXMvbmV0aW5ldC90Y3BfdGltZXdhaXQuYzo0OTEgKHNs ZWVwIG11dGV4OnNvX3JjdikKICAgICAyICAgICAgICAgICAgMiAgICAgICAgICAgIDAgICAg ICAgICAgIDEgICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3Ny Yy9zeXMva2Vybi9rZXJuX2V4aXQuYzo4NzQgKHNsZWVwIG11dGV4OnByb2Nlc3MgbG9jaykK ICAgICA0ICAgICAgICAgICAxNyAgICAgICAgICAgIDAgICAgICAgICAgIDggICAgIDIgICAg IDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdm1fbWFwLmM6 MjcwOSAoc2xlZXAgbXV0ZXg6cHJvY2VzcyBsb2NrKQogICAgMTIgICAgICAgICAgIDQzICAg ICAgICAgICAgMCAgICAgICAgICAgNCAgICAxMCAgICAgMCAgICAgICAgICAgIDAgICAgICAg ICAgICAwIC91c3Ivc3JjL3N5cy92bS92bV9tYXAuYzoxNTI0IChzbGVlcCBtdXRleDp2bSBw YWdlIHF1ZXVlIG11dGV4KQogICAgODAgICAgICAgICAyNTYyICAgICAgICAgICAgMCAgICAg ICAgICA3NCAgICAzNCAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3Jj L3N5cy92bS92bV9tYXAuYzoxNTYwIChzeDp1c2VyIG1hcCkKICAgICA5ICAgICAgICAgIDEx MCAgICAgICAgICAgIDAgICAgICAgICAgMjIgICAgIDUgICAgIDAgICAgICAgICAgICAwICAg ICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdWZzL3Vmcy91ZnNfZGlyaGFzaC5jOjM0OSAoc2xl ZXAgbXV0ZXg6ZGlyaGFzaCBsaXN0KQogICAgNDcgICAgICAgICAyMDM0ICAgICAgICAgIDk3 OCAgICAgICAgIDE3MSAgICAxMSAgICAgNSAgICAgICAgICAgIDQgICAgICAgICAgICAzIC91 c3Ivc3JjL3N5cy92bS92bV9tYXAuYzoxNTM0IChzbGVlcCBtdXRleDp2bSBwYWdlIHF1ZXVl IG11dGV4KQogICAgIDIgICAgICAgICAgIDIwICAgICAgICAgICAgMCAgICAgICAgICAxMCAg ICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJu L2tlcm5fZm9yay5jOjc2NyAoc2xlZXAgbXV0ZXg6c2NoZWR0YWlsKQogICAgMTQgICAgICAg ICAgIDU5ICAgICAgICAgICAgMCAgICAgICAgICAxMCAgICAgNSAgICAgMCAgICAgICAgICAg IDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfZXZlbnRoYW5kbGVyLmM6 MjE1IChzbGVlcCBtdXRleDpwcm9jZXNzX2V4aXQpCiAgICAxNSAgICAgICAgICAgNzIgICAg ICAgICAgICAwICAgICAgICAgIDE2ICAgICA0ICAgICAwICAgICAgICAgICAgMCAgICAgICAg ICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9ldmVudC5jOjE0NDIgKHNsZWVwIG11dGV4 OmtxdWV1ZSkKICAgICA2ICAgICAgICAgIDEwMyAgICAgICAgICAgIDAgICAgICAgICAgMzIg ICAgIDMgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vy bi92ZnNfc3Vici5jOjE1NzMgKHNsZWVwIG11dGV4OlN5bmNlciBtdHgpCiAgICAyMyAgICAg ICAgICAxMzkgICAgICAgICAgICAwICAgICAgICAgIDM1ICAgICAzICAgICAwICAgICAgICAg ICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX2Jpby5jOjEyODAgKHNs ZWVwIG11dGV4OnZtIG9iamVjdCkKICAgIDY4ICAgICAgICAzODYzMSAgICAgICAgMTI1ODgg ICAgICAgMTUyMDUgICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAxNSAvdXNy L3NyYy9zeXMva2Vybi9rZXJuX2Rlc2NyaXAuYzoyMTc5IChzeDpmaWxlbGlzdCBsb2NrKQog ICAgMTkgICAgICAgICAgIDgwICAgICAgICAgICAgMCAgICAgICAgICAgNSAgICAxNiAgICAg MCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N5c19waXBl LmM6MTEyNyAoc2xlZXAgbXV0ZXg6cGlwZSBtdXRleCkKICAgIDM1ICAgICAgICAgIDQwMCAg ICAgICAgICAgIDAgICAgICAgICAgMTIgICAgMzMgICAgIDAgICAgICAgICAgICAwICAgICAg ICAgICAgMCAvdXNyL3NyYy9zeXMvbmV0aW5ldC9pcF9mdzIuYzo0ODc3IChzbGVlcCBtdXRl eDpJUEZXIGR5bmFtaWMgcnVsZXMpCiAgICAgMyAgICAgICAgICAgMTEgICAgICAgICAgICAw ICAgICAgICAgICA0ICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vz ci9zcmMvc3lzL2FtZDY0L2FtZDY0L3BtYXAuYzoyNjk1IChzbGVlcCBtdXRleDpwbWFwKQog ICAxMDUgICAgICAgICAzODM1ICAgICAgICAgICAgMCAgICAgICAgICA2MCAgICA2MyAgICAg MCAgICAgICAgICAgIDIgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fdGlt ZW91dC5jOjI0MSAoc2xlZXAgbXV0ZXg6ZW0wKQogICAgNDYgICAgICAgIDEzNDE2ICAgICAg ICAgICAgMCAgICAgICAgIDYwMSAgICAyMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAg ICAwIC91c3Ivc3JjL3N5cy9nZW9tL2dlb21fZXZlbnQuYzoxODUgKHN4OkdFT00gdG9wb2xv Z3kpCiAgICAgNSAgICAgICAgICAgMTAgICAgICAgICAgICAwICAgICAgICAgICAzICAgICAz ICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9j b3JlLmM6NDE0IChzbGVlcCBtdXRleDpGRlMxIGRpbm9kZSkKICAgIDIzICAgICAgICAgNDA2 NiAgICAgICAgICAgIDAgICAgICAgIDE1MDAgICAgIDIgICAgIDAgICAgICAgICAgICAwICAg ICAgICAgICAgMCAvdXNyL3NyYy9zeXMvZGV2L3N5c2NvbnMvc3lzY29ucy5jOjE4MDAgKHNw aW4gbXV0ZXg6c3lzY29ucyB2aWRlbyBsb2NrKQogICAgMTMgICAgICAgICAgIDMxICAgICAg ICAgICAgMCAgICAgICAgICAgNyAgICAgNCAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAg ICAwIC91c3Ivc3JjL3N5cy91ZnMvZmZzL2Zmc19zb2Z0ZGVwLmM6Mzc0NCAoc2xlZXAgbXV0 ZXg6U29mdGRlcCBMb2NrKQogICAgIDQgICAgICAgICAgIDEwICAgICAgICAgICAgMCAgICAg ICAgICAgMyAgICAgMyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3Jj L3N5cy92bS91bWFfY29yZS5jOjQxNCAoc2xlZXAgbXV0ZXg6Z19iaW8pCiAgICAxOCAgICAg ICAgICAgODQgICAgICAgICAgICAwICAgICAgICAgIDEwICAgICA4ICAgICAwICAgICAgICAg ICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9jb25mLmM6MzQ4IChz bGVlcCBtdXRleDpHaWFudCkKICAgICAyICAgICAgICAgICAgNiAgICAgICAgICAgIDAgICAg ICAgICAgIDMgICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3Ny Yy9zeXMvdm0vdW1hX2NvcmUuYzo0MTQgKHNsZWVwIG11dGV4OmtzaWdpbmZvKQogICAgNDEg ICAgICAgICAgMjcyICAgICAgICAgICAgMCAgICAgICAgICAxMCAgICAyNyAgICAgMCAgICAg ICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZm9yay5jOjU0 NSAoc3g6cHJvY3RyZWUpCiAgICAgNCAgICAgICAgICAgMzUgICAgICAgICAgICAwICAgICAg ICAgIDEyICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMv c3lzL2tlcm4vdmZzX3N1YnIuYzoyOTQ0IChzbGVlcCBtdXRleDpzdHJ1Y3QgbW91bnQgbXR4 KQogIDIzNjEgICAgICAgIDI2MDI0ICAgICAgICAgIDI4NCAgICAgICAgIDIwNCAgIDEyNyAg ICAgMSAgICAgICAgICAgMjQgICAgICAgICAgIDEyIC91c3Ivc3JjL3N5cy92bS92bV9vYmpl Y3QuYzo2NDEgKHNsZWVwIG11dGV4OnZtIHBhZ2UgcXVldWUgbXV0ZXgpCiAgICAgNSAgICAg ICAgICAgIDkgICAgICAgICAgICAwICAgICAgICAgICAzICAgICAzICAgICAwICAgICAgICAg ICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6NDE0IChzbGVl cCBtdXRleDpyaXBjYikKICAgMTI0ICAgICAgICAgMjY1OSAgICAgICAgICAgIDAgICAgICAg ICAxNTEgICAgMTcgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9z eXMvYW1kNjQvYW1kNjQvcG1hcC5jOjI3MzQgKHNsZWVwIG11dGV4OnBtYXApCiAgIDEyMCAg ICAgICAgIDE4NTggICAgICAgICAgICAwICAgICAgICAgMTUxICAgIDEyICAgICAwICAgICAg ICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0L3BtYXAuYzoy NzM1IChzbGVlcCBtdXRleDpwbWFwKQogICAgMjAgICAgICAgICAgIDIwICAgICAgICAgICAg MCAgICAgICAgICAgMSAgICAyMCAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91 c3Ivc3JjL3N5cy9rZXJuL2tlcm5fY29uZi5jOjM2MCAoc2xlZXAgbXV0ZXg6R2lhbnQpCiAg ICAzNiAgICAgICAgIDQyMzMgICAgICAgICAgICAwICAgICAgICAgNTA2ICAgICA4ICAgICAw ICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL25ldGluZXQvdGNwX2lu cHV0LmM6Mjg2NyAoc2xlZXAgbXV0ZXg6c29fcmN2KQogICAgNTkgICAgICAgICAxNTM0ICAg ICAgICAgICAgMCAgICAgICAgIDEyMyAgICAxMiAgICAgMCAgICAgICAgICAgIDAgICAgICAg ICAgICAwIC91c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC9wbWFwLmM6MjczNyAoc2xlZXAgbXV0 ZXg6cG1hcCkKICAgIDU2ICAgICAgICAgMTU1MSAgICAgICAgICAgIDAgICAgICAgICAxMjMg ICAgMTIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvYW1k NjQvYW1kNjQvcG1hcC5jOjI3MzggKHNsZWVwIG11dGV4OnBtYXApCiAgICAxMiAgICAgICAg ICAgNDYgICAgICAgICAgICAwICAgICAgICAgICA4ICAgICA1ICAgICAwICAgICAgICAgICAg MCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9zaWcuYzo5NTIgKHNsZWVw IG11dGV4OnNpZ2FjdHMpCiAgICAgNSAgICAgICAgICAgMzcgICAgICAgICAgICAwICAgICAg ICAgIDEwICAgICAzICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMv c3lzL2tlcm4vc3Vicl9ldmVudGhhbmRsZXIuYzoyMTUgKHNsZWVwIG11dGV4OnNjaGVkdGFp bCkKICAgIDIwICAgICAgICAgIDIwMSAgICAgICAgICAgIDAgICAgICAgICAgMTkgICAgMTAg ICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNf c3Vici5jOjE2NTMgKHNsZWVwIG11dGV4OlN5bmNlciBtdHgpCiAgICA0NiAgICAgICAgICAx MzEgICAgICAgICAgICAwICAgICAgICAgICA1ICAgIDI2ICAgICAwICAgICAgICAgICAgMCAg ICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9jb25mLmM6MzcyIChzbGVlcCBt dXRleDpHaWFudCkKICAxNzI4ICAgICAgIDEyODM0MiAgICAgICAgMTMwOTcgICAgICAgMTQ1 MjQgICAgIDggICAgIDAgICAgICAgICAgIDMyICAgICAgICAgICA0NiAvdXNyL3NyYy9zeXMv a2Vybi92ZnNfY2FjaGUuYzo2OTIgKHNsZWVwIG11dGV4OkdpYW50KQogICAgIDUgICAgICAg ICAgIDM2ICAgICAgICAgICAgMCAgICAgICAgICAxMCAgICAgMyAgICAgMCAgICAgICAgICAg IDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjE4NzQgKHNsZWVw IG11dGV4Ok5BTUVJKQogICAgMTMgICAgICAgICAgIDU5ICAgICAgICAgICAxOSAgICAgICAg ICAgNyAgICAgOCAgICAgMiAgICAgICAgICAgIDAgICAgICAgICAgICAxIC91c3Ivc3JjL3N5 cy9rZXJuL2tlcm5fY29uZi5jOjM4NCAoc2xlZXAgbXV0ZXg6R2lhbnQpCiAgICAyMiAgICAg ICAgIDIwMjAgICAgICAgICAgICAwICAgICAgICAgNjAxICAgICAzICAgICAwICAgICAgICAg ICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2dlb20vZ2VvbV9ldmVudC5jOjIzMyAo c3g6R0VPTSB0b3BvbG9neSkKICAgICA1ICAgICAgICAgICAxMCAgICAgICAgICAgIDAgICAg ICAgICAgIDMgICAgIDMgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3Ny Yy9zeXMvdm0vdW1hX2NvcmUuYzo0MTQgKHNsZWVwIG11dGV4OlZOT0RFUE9MTCkKICAgICA0 ICAgICAgICAgICAxMiAgICAgICAgICAgIDAgICAgICAgICAgIDMgICAgIDQgICAgIDAgICAg ICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0MTQg KHNsZWVwIG11dGV4OlZOT0RFKQogICAgIDIgICAgICAgICAgICAyICAgICAgICAgICAgMCAg ICAgICAgICAgMSAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Iv c3JjL3N5cy91ZnMvZmZzL2Zmc19zb2Z0ZGVwLmM6Mzc4NSAoc2xlZXAgbXV0ZXg6U29mdGRl cCBMb2NrKQogICAgMjUgICAgICAgICAgIDI1ICAgICAgICAgICAgMCAgICAgICAgICAgMSAg ICAyNSAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy91ZnMv ZmZzL2Zmc19zb2Z0ZGVwLmM6Mzc5NCAoc2xlZXAgbXV0ZXg6U29mdGRlcCBMb2NrKQogICAg MTEgICAgICAgICAgMjI1ICAgICAgICAgICAgMCAgICAgICAgICA3MiAgICAgMyAgICAgMCAg ICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy92bS92bV9nbHVlLmM6MTgz IChzeDp1c2VyIG1hcCkKICAgIDI2ICAgICAgICAgIDM4NiAgICAgICAgICAgIDAgICAgICAg ICAgMjEgICAgMTggICAgIDAgICAgICAgICAgICAxICAgICAgICAgICAgMCAvdXNyL3NyYy9z eXMva2Vybi9rZXJuX2V2ZW50LmM6MTU2OCAoc2xlZXAgbXV0ZXg6a3F1ZXVlKQogICAgIDQg ICAgICAgICAgIDMyICAgICAgICAgICA1NCAgICAgICAgICAxMiAgICAgMiAgICAgNCAgICAg ICAgICAgIDAgICAgICAgICAgICAxIC91c3Ivc3JjL3N5cy91ZnMvZmZzL2Zmc192ZnNvcHMu YzoxMjA4IChzbGVlcCBtdXRleDpzdHJ1Y3QgbW91bnQgbXR4KQogICAgIDUgICAgICAgICAg IDM0ICAgICAgICAgICAgMCAgICAgICAgICAxMiAgICAgMiAgICAgMCAgICAgICAgICAgIDAg ICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy91ZnMvZmZzL2Zmc192ZnNvcHMuYzoxMjE3IChz bGVlcCBtdXRleDpzdHJ1Y3QgbW91bnQgbXR4KQogICAgIDQgICAgICAgICAgIDQxICAgICAg ICAgICAgMCAgICAgICAgICAxNiAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAg ICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZXZlbnQuYzoxNTk4IChzbGVlcCBtdXRleDpr cXVldWUpCiAgICAgNyAgICAgICAgICAxNjYgICAgICAgICAgICAwICAgICAgICAgIDYwICAg ICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL25ldC9p Zi5jOjE0NzMgKHNsZWVwIG11dGV4OmlmbmV0KQogICAzNDAgICAgICAgMjk1MjgxICAgICAg ICAxMDU0MyAgICAgICAgNDYxOCAgICA2MyAgICAgMiAgICAgICAgICAyMDcgICAgICAgICAg MTc5IC91c3Ivc3JjL3N5cy9uZXRpbmV0L3RjcF9pbnB1dC5jOjQ3OSAoc2xlZXAgbXV0ZXg6 aW5wKQogICAgIDUgICAgICAgICAgIDI1ICAgICAgICAgICAxOSAgICAgICAgICAxMCAgICAg MiAgICAgMSAgICAgICAgICAgIDUgICAgICAgICAgICA1IC91c3Ivc3JjL3N5cy9rZXJuL2tl cm5fZm9yay5jOjM4MyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrKQogICAgMTAgICAgICAgICAg IDkwICAgICAgICAgICAgMCAgICAgICAgICAxOSAgICAgNCAgICAgMCAgICAgICAgICAgIDAg ICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9mcy9kZXZmcy9kZXZmc192bm9wcy5jOjE5NCAo c2xlZXAgbXV0ZXg6ZGV2ZnMgaW50ZXJsb2NrKQogIDIzOTAgICAgICAgICAyNjMzICAgICAg ICAgICAgMCAgICAgICAgICAgMyAgIDg3NyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAg ICAwIC91c3Ivc3JjL3N5cy91ZnMvZmZzL2Zmc192ZnNvcHMuYzoxMjUwIChzbGVlcCBtdXRl eDpzdHJ1Y3QgbW91bnQgbXR4KQogICAgIDMgICAgICAgICAgIDM0ICAgICAgICAgICAgMCAg ICAgICAgICAxNiAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Iv c3JjL3N5cy9rZXJuL2tlcm5fZXZlbnQuYzoxNjIwIChzbGVlcCBtdXRleDprcXVldWUpCiAg ICAxMiAgICAgICAgICAgMTUgICAgICAgICAgICAwICAgICAgICAgICAzICAgICA1ICAgICAw ICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6 NDE0IChzbGVlcCBtdXRleDppcHEpCiAgICAgNSAgICAgICAgICAyNTAgICAgICAgICAgICAw ICAgICAgICAgIDk2ICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vz ci9zcmMvc3lzL3ZtL3ZtX21hcC5jOjE4MDAgKHN4OnVzZXIgbWFwKQogICAgMTAgICAgICAg ICAgIDM0ICAgICAgICAgICAgMCAgICAgICAgICAgNSAgICAgNiAgICAgMCAgICAgICAgICAg IDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N5c19waXBlLmM6MTMyNyAoc2xl ZXAgbXV0ZXg6cGlwZSBtdXRleCkKICAgICA1ICAgICAgICAgICAzMSAgICAgICAgICAgIDAg ICAgICAgICAgMTIgICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNy L3NyYy9zeXMvdm0vdm1fZ2x1ZS5jOjI3NCAoc2xlZXAgbXV0ZXg6dm0gcGFnZSBxdWV1ZSBt dXRleCkKICAxNTk0ICAgICAgMTUzNTUwNiAgICAgMzUxMzgyMjUgICAgICA1NTgwMjEgICAg IDIgICAgNjIgICAgICAgICAxMTgxICAgICAgIDExNzU4MyAvdXNyL3NyYy9zeXMva2Vybi9r ZXJuX2xvY2suYzo1ODMgKHNsZWVwIG11dGV4OmxvY2tidWlsZGVyIG10eHBvb2wpCiAgICAx NiAgICAgICAgICA0NzkgICAgICAgICAgICAwICAgICAgICAgIDY3ICAgICA3ICAgICAwICAg ICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90cmFwLmM6 MjQ4IChzbGVlcCBtdXRleDpzaWdhY3RzKQogICAgMjQgICAgICAgICA1MzUyICAgICAgICAg IDEzMiAgICAgICAgMTg2NCAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICA1 IC91c3Ivc3JjL3N5cy9uZXRpbmV0L3RjcF9pbnB1dC5jOjIwMjUgKHNsZWVwIG11dGV4OnNv X3NuZCkKICAgIDMxICAgICAgICAgICAzMSAgICAgICAgICAgIDAgICAgICAgICAgIDEgICAg MzEgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92 ZnNfYmlvLmM6MTUzMCAoc2xlZXAgbXV0ZXg6dm0gb2JqZWN0KQogICAgIDYgICAgICAgICAx MjkyICAgICAgICAgIDMzNSAgICAgICAgIDQ5NiAgICAgMiAgICAgMCAgICAgICAgICAgIDEg ICAgICAgICAgICA0IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fbG9jay5jOjYwNyAoc2xlZXAg bXV0ZXg6bG9ja2J1aWxkZXIgbXR4cG9vbCkKICAgMTA3ICAgICAgIDE4NjYwMiAgICAgICAg ICAgIDAgICAgICAgMTIwMDIgICAgMTUgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAg MCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3Rhc2txdWV1ZS5jOjcxIChzcGluIG11dGV4OmZh c3RfdGFza3F1ZXVlKQogICAgIDUgICAgICAgICAgIDMxICAgICAgICAgICAgMCAgICAgICAg ICAxMiAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5 cy92bS92bV9nbHVlLmM6MzEwIChzbGVlcCBtdXRleDp2bSBwYWdlIHF1ZXVlIG11dGV4KQog ICA0MTkgICAgICAgICAzMjM0ICAgICAgICAgICAgMCAgICAgICAgICAxNSAgIDIxNSAgICAg MCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC9w bWFwLmM6Mjk1MCAoc2xlZXAgbXV0ZXg6cG1hcCkKICAgICA0ICAgICAgICAgICAxMCAgICAg ICAgICAgIDAgICAgICAgICAgIDMgICAgIDMgICAgIDAgICAgICAgICAgICAwICAgICAgICAg ICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0MTQgKHNsZWVwIG11dGV4OlNMRUVQ UVVFVUUpCiAgICAgNSAgICAgICAgICAgIDkgICAgICAgICAgICAwICAgICAgICAgICAzICAg ICAzICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3Vt YV9jb3JlLmM6NDE0IChzbGVlcCBtdXRleDpEUCBmYWtlcGcpCiAgICAgNCAgICAgICAgICAg MzIgICAgICAgICAgICAwICAgICAgICAgIDEyICAgICAyICAgICAwICAgICAgICAgICAgMCAg ICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX3N1YnIuYzozMTc5IChzbGVlcCBt dXRleDpzdHJ1Y3QgbW91bnQgbXR4KQogICAgMTIgICAgICAgICAgNTk3ICAgICAgICAgICAg MCAgICAgICAgIDIzNSAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91 c3Ivc3JjL3N5cy92bS92bV9vYmplY3QuYzoyMjUgKHNsZWVwIG11dGV4OnZtIG9iamVjdF9s aXN0KQogICAgIDUgICAgICAgICAgIDQxICAgICAgICAgICAgMCAgICAgICAgICAxMiAgICAg MyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3Zm c19zdWJyLmM6MzE4NSAoc2xlZXAgbXV0ZXg6c3RydWN0IG1vdW50IG10eCkKICAgIDk3ICAg ICAgICAyMDA2MCAgICAgICAgICAgIDAgICAgICAgICA0OTUgICAgNDAgICAgIDAgICAgICAg ICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvbmV0aW5ldC90Y3BfaW5wdXQuYzo2 MzYgKHNsZWVwIG11dGV4OmlucCkKICAgICA1ICAgICAgICAgICAyOSAgICAgICAgICAgIDAg ICAgICAgICAgIDkgICAgIDMgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNy L3NyYy9zeXMva2Vybi92ZnNfc3Vici5jOjE4ODggKHNsZWVwIG11dGV4OlN5bmNlciBtdHgp CiAgICAgMyAgICAgICAgICAgMjEgICAgICAgICAgICAwICAgICAgICAgICA3ICAgICAzICAg ICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3Jl LmM6MjMzNSAoc2xlZXAgbXV0ZXg6c29ja2V0KQogIDEwMjIgICAgICAgIDM1NjI0ICAgICAg ICAgIDE4MCAgICAgICAxMzg2MSAgICAgMiAgICAgMCAgICAgICAgICAxMDkgICAgICAgICAg ICA3IC91c3Ivc3JjL3N5cy9rZXJuL3Zmc192bm9wcy5jOjkwMyAoc2xlZXAgbXV0ZXg6c3Ry dWN0IG1vdW50IG10eCkKICAgICA0ICAgICAgICAgICA4MyAgICAgICAgICAgIDAgICAgICAg ICAgMzMgICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9z eXMvdm0vdm1fbWFwLmM6MzA5MiAoc2xlZXAgbXV0ZXg6c3lzdGVtIG1hcCkKICAgIDEyICAg ICAgICAgMTA1NyAgICAgICAgICAgMzMgICAgICAgICAzNzkgICAgIDIgICAgIDAgICAgICAg ICAgICAyICAgICAgICAgICAgMyAvdXNyL3NyYy9zeXMvdm0vdm1fZmF1bHQuYzoxMzcgKHNs ZWVwIG11dGV4OnZtIHBhZ2UgcXVldWUgbXV0ZXgpCiAgICAyMiAgICAgICAgIDIwOTggICAg ICAgICAgICAwICAgICAgICAgNjAwICAgICAzICAgICAwICAgICAgICAgICAgMCAgICAgICAg ICAgIDAgL3Vzci9zcmMvc3lzL2Rldi9yYW5kb20vcmFuZG9tZGV2X3NvZnQuYzoyNDkgKHNw aW4gbXV0ZXg6ZW50cm9weSBoYXJ2ZXN0IG11dGV4KQozNTE1NDE5ICAgICAgMzc1NTE2MCAg ICAgICAgICAgIDAgICAgICAgIDIxMDkgIDE3ODAgICAgIDAgICAgICAgICAgICAwICAgICAg ICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi91aXBjX3NvY2tidWYuYzoxNDUgKHN4OnNvX3Jj dl9zeCkKICAgICAzICAgICAgICAgICAgOCAgICAgICAgICAgIDAgICAgICAgICAgIDQgICAg IDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9r ZXJuX3Byb2MuYzoxMjA2IChzbGVlcCBtdXRleDpwcm9jZXNzIGxvY2spCiAgICAgMyAgICAg ICAgICAgMzYgICAgICAgICAgICAwICAgICAgICAgIDE1ICAgICAyICAgICAwICAgICAgICAg ICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9leGVjLmM6MzE4IChz bGVlcCBtdXRleDpwcm9jZXNzIGxvY2spCiAgICAgMyAgICAgICAgICAgIDggICAgICAgICAg ICAwICAgICAgICAgICAzICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAg L3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6NDE0IChzbGVlcCBtdXRleDpGRlMyIGRpbm9k ZSkKICAgICA1ICAgICAgICAgICAxOCAgICAgICAgICAgIDAgICAgICAgICAgIDcgICAgIDIg ICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvZnMvZGV2ZnMv ZGV2ZnNfdm5vcHMuYzozMjUgKHN4OnByb2N0cmVlKQogICAgIDIgICAgICAgICAgICAzICAg ICAgICAgICAgMCAgICAgICAgICAgMiAgICAgMSAgICAgMCAgICAgICAgICAgIDAgICAgICAg ICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjE4NzQgKHNsZWVwIG11dGV4OkZp bGVzKQogICAgMTMgICAgICAgICAxOTkxICAgICAgICAgICAgMiAgICAgICAgIDU5NCAgICAg MyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAxIC91c3Ivc3JjL3N5cy9kZXYvcmFu ZG9tL3JhbmRvbWRldl9zb2Z0LmM6MjY5IChzcGluIG11dGV4OmVudHJvcHkgaGFydmVzdCBt dXRleCkKICAgICA1ICAgICAgICAgICA4OCAgICAgICAgICAgMTIgICAgICAgICAgMzQgICAg IDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMSAvdXNyL3NyYy9zeXMva2Vybi9r ZXJuX2V2ZW50LmM6MTgwMiAoc2xlZXAgbXV0ZXg6a3F1ZXVlKQogICAgMzkgICAgICAgICAg MTg4ICAgICAgICAgICAgMCAgICAgICAgICAxNiAgICAxMSAgICAgMCAgICAgICAgICAgIDAg ICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N5c19waXBlLmM6MTQ2MSAoc2xlZXAg bXV0ZXg6cGlwZSBtdXRleCkKICAgICA0ICAgICAgICAgICAxMCAgICAgICAgICAgIDAgICAg ICAgICAgIDMgICAgIDMgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3Ny Yy9zeXMvdm0vdW1hX2NvcmUuYzo0MTQgKHNsZWVwIG11dGV4OmF0YV9yZXF1ZXN0KQogICA0 NjkgICAgICAgICAxMTQxICAgICAgICAgICAgMCAgICAgICAgICAgNCAgIDI4NSAgICAgMCAg ICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19zdWJyLmM6 MTYzOCAobG9ja21ncjpkZXZmcykKICAxNDc1ICAgICAgIDM1NzkxOCAgICAgICAgICA4Mjkg ICAgICAgMTM3MDkgICAgMjYgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMiAvdXNy L3NyYy9zeXMva2Vybi92ZnNfdm5vcHMuYzoyODggKGxvY2ttZ3I6dWZzKQogICAgMjMgICAg ICAgICAgIDIzICAgICAgICAgICAgMCAgICAgICAgICAgMSAgICAyMyAgICAgMCAgICAgICAg ICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3VpcGNfc29ja2V0LmM6NDgx IChzbGVlcCBtdXRleDpzb19yY3YpCiAgICAyMyAgICAgICAgMTY3MTIgICAgICAgICAgICAw ICAgICAgICA2MDI3ICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vz ci9zcmMvc3lzL2Rldi9yYW5kb20vcmFuZG9tZGV2X3NvZnQuYzozMDggKHNwaW4gbXV0ZXg6 ZW50cm9weSBoYXJ2ZXN0IG11dGV4KQogICAgIDUgICAgICAgICAgIDQ3ICAgICAgICAgICAg MCAgICAgICAgICAxNiAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91 c3Ivc3JjL3N5cy9rZXJuL3N5c19waXBlLmM6MTUwMSAoc2xlZXAgbXV0ZXg6cGlwZSBtdXRl eCkKICAgICA2ICAgICAgICAgIDE0NCAgICAgICAgICAgIDAgICAgICAgICAgNDYgICAgIDMg ICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNf YmlvLmM6NDI5IChzbGVlcCBtdXRleDpidWZmZXIgZGFlbW9uIGxvY2spCiAgIDk2MCAgICAg ICAyNjUzOTEgICAgICAgICAgICAwICAgICAgMTAxMDg3ICAgICAyICAgICAwICAgICAgICAg ICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0L3BtYXAuYzozMDc0 IChzbGVlcCBtdXRleDpwbWFwKQogICAgIDUgICAgICAgICAgIDQxICAgICAgICAgICAgMCAg ICAgICAgICAxNiAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Iv c3JjL3N5cy9rZXJuL2tlcm5fZXZlbnQuYzoxODY4IChzbGVlcCBtdXRleDprcXVldWUpCiAg ICAgNiAgICAgICAgICAgMjkgICAgICAgICAgICAwICAgICAgICAgIDEwICAgICAyICAgICAw ICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9mb3Jr LmM6NjU4IChzcGluIG11dGV4OnByb2Nlc3Mgc2xvY2spCiAgICAyNiAgICAgICAgICAxMzkg ICAgICAgICAgIDU3ICAgICAgICAgIDE2ICAgICA4ICAgICAzICAgICAgICAgICAgMCAgICAg ICAgICAgIDEgL3Vzci9zcmMvc3lzL2Rldi9tZmkvbWZpX2Rpc2suYzoyNTggKHNsZWVwIG11 dGV4Ok1GSSBJL08gbG9jaykKICAgIDQzICAgICAgICAgIDE0NCAgICAgICAgICAgIDAgICAg ICAgICAgIDUgICAgMjggICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3Ny Yy9zeXMvZnMvZGV2ZnMvZGV2ZnNfdm5vcHMuYzozNzUgKGxvY2ttZ3I6ZGV2ZnMpCiAgICAy MyAgICAgICAgIDMwMzcgICAgICAgICAzMDU2ICAgICAgICAgNjAwICAgICA1ICAgICA1ICAg ICAgICAgIDMyMiAgICAgICAgICAzNzcgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfNGJzZC5j OjI3MSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrKQogICAgIDUgICAgICAgICAgIDMxICAgICAg ICAgICA0MyAgICAgICAgICAxMCAgICAgMyAgICAgNCAgICAgICAgICAgIDMgICAgICAgICAg ICA1IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZm9yay5jOjY2NyAoc3BpbiBtdXRleDpzY2hl ZCBsb2NrKQogICAgMzggICAgICAgICAgIDM4ICAgICAgICAgICAgMCAgICAgICAgICAgMSAg ICAzOCAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy92bS92 bV9rZXJuLmM6MzM0IChzbGVlcCBtdXRleDp2bSBvYmplY3QpCiAgICA1NyAgICAgICAgIDE1 NTYgICAgICAgICAgICAwICAgICAgICAgMzI4ICAgICA0ICAgICAwICAgICAgICAgICAgMCAg ICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL25ldGluZXQvdGNwX3VzcnJlcS5jOjI1NSAoc2xl ZXAgbXV0ZXg6aW5wKQogICAgMjAgICAgICAgIDMzNjgwICAgICAgICAgNDE5NSAgICAgICAx Mzg2MSAgICAgMiAgICAgMCAgICAgICAgICAgNTAgICAgICAgICAgMTE2IC91c3Ivc3JjL3N5 cy9rZXJuL3Zmc192bm9wcy5jOjEwNDYgKHNsZWVwIG11dGV4OnN0cnVjdCBtb3VudCBtdHgp CiAgICAgNCAgICAgICAgICAgMTEgICAgICAgICAgICAwICAgICAgICAgICAzICAgICAzICAg ICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3Jl LmM6NDE0IChzbGVlcCBtdXRleDpWTSBPQkpFQ1QpCiAgICAgMyAgICAgICAgICAgMTcgICAg ICAgICAgICAwICAgICAgICAgICA4ICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAg ICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3lzX3BpcGUuYzozNjYgKHNsZWVwIG11dGV4OnNs ZWVwIG10eHBvb2wpCiAgICAgNiAgICAgICAgICAgNDkgICAgICAgICAgICAwICAgICAgICAg IDE5ICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lz L2ZzL2RldmZzL2RldmZzX3Zub3BzLmM6MjAxIChzeDpkZXZmc21vdW50KQogICAgIDQgICAg ICAgICAgIDE5ICAgICAgICAgICAgMCAgICAgICAgICAgOCAgICAgMiAgICAgMCAgICAgICAg ICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N5c19waXBlLmM6MzgxIChz bGVlcCBtdXRleDpzbGVlcCBtdHhwb29sKQogICAgMTIgICAgICAgIDEzOTU3ICAgICAgICAg ICA1MCAgICAgICAgNjAwMSAgICAgMiAgICAgMCAgICAgICAgICAgIDIgICAgICAgICAgIDEx IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fY2xvY2suYzoyNjQgKHNwaW4gbXV0ZXg6Y2FsbG91 dCkKICAgIDYzICAgICAgICAgICA2MyAgICAgICAgICAgIDAgICAgICAgICAgIDEgICAgNjMg ICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdm1fa2Vy bi5jOjQwMyAoc2xlZXAgbXV0ZXg6dm0gb2JqZWN0KQogICAgMzMgICAgICAgICAgMTcxICAg ICAgICAgICAgMCAgICAgICAgICAgOCAgICAyMSAgICAgMCAgICAgICAgICAgIDAgICAgICAg ICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZXhlYy5jOjUwNSAoc2xlZXAgbXV0ZXg6 cHJvY2VzcyBsb2NrKQogICAgMjMgICAgICAgICAzMDUzICAgICAgICAgIDI3OCAgICAgICAg MTExMiAgICAgMiAgICAgMCAgICAgICAgICAgIDMgICAgICAgICAgICA4IC91c3Ivc3JjL3N5 cy92bS92bV9mYXVsdC5jOjM0MCAoc2xlZXAgbXV0ZXg6dm0gcGFnZSBxdWV1ZSBtdXRleCkK ICAgNDcxICAgICAgICA4NDAyNiAgICAgICAgICAgIDAgICAgICAgIDYyMDYgICAgMTMgICAg IDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF80 YnNkLmM6MzgyIChzcGluIG11dGV4OnByb2Nlc3Mgc2xvY2spCiAgICAzMCAgICAgICAgIDQ1 NTkgICAgICAgICAgICAwICAgICAgICAgNDY3ICAgICA5ICAgICAwICAgICAgICAgICAgMCAg ICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3Zub2RlX3BhZ2VyLmM6MTIwNCAoc2xlZXAg bXV0ZXg6dm5vZGUgaW50ZXJsb2NrKQogICAgIDUgICAgICAgICAgMTc0ICAgICAgICAgICAg MCAgICAgICAgICA1NSAgICAgMyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91 c3Ivc3JjL3N5cy9uZXRpbmV0L2lwX2Z3Mi5jOjEzMDMgKHNsZWVwIG11dGV4OklQRlcgZHlu YW1pYyBydWxlcykKICAgNDI4ICAgICAgICAyNDA2NyAgICAgICAgICA2MDIgICAgICAgIDcy MjYgICAgIDMgICAgIDAgICAgICAgICAgICAzICAgICAgICAgICAyMCAvdXNyL3NyYy9zeXMv bmV0aW5ldC90Y3Bfb3V0cHV0LmM6MjcwIChzbGVlcCBtdXRleDpzb19zbmQpCiAgICAxMCAg ICAgICAgIDgyMTAgICAgICAgIDE3NDg0ICAgICAgICAyODAwICAgICAyICAgICA2ICAgICAg ICAgMTAzOSAgICAgICAgIDE0NDYgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfNGJzZC5jOjM4 NSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrKQogICAyOTYgICAgICAgICAgMzYxICAgICAgICAg ICAgMCAgICAgICAgICAgNiAgICA2MCAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAw IC91c3Ivc3JjL3N5cy91ZnMvZmZzL2Zmc19zb2Z0ZGVwLmM6NDIzOSAoc2xlZXAgbXV0ZXg6 U29mdGRlcCBMb2NrKQogICAgIDUgICAgICAgICAgIDI4ICAgICAgICAgICAgMCAgICAgICAg ICAxMCAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5 cy92bS91bWFfY29yZS5jOjIzMzUgKHNsZWVwIG11dGV4Ok5BTUVJKQogICAgODQgICAgICAg ICA0MzExICAgICAgICAgICAgMCAgICAgICAgIDQ5OSAgICAgOCAgICAgMCAgICAgICAgICAg IDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9uZXRpbmV0L3RjcF9zeW5jYWNoZS5jOjMx NiAoc2xlZXAgbXV0ZXg6dGNwX3NjX2hlYWQpCiAgICAxMSAgICAgICAgICAyMTYgICAgICAg ICAgICAwICAgICAgICAgIDczICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAg IDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9zaWcuYzoxOTYxIChzcGluIG11dGV4OnByb2Nl c3Mgc2xvY2spCiAgIDEzMiAgICAgICAgMTY4NjUgICAgICAgICA1MTc4ICAgICAgICAxNDYx ICAgIDExICAgICAzICAgICAgICAgICA5MiAgICAgICAgICAxMDAgL3Vzci9zcmMvc3lzL2tl cm4va2Vybl9tdXRleC5jOjE0MSAoc2xlZXAgbXV0ZXg6c2VsbGNrKQogICAgIDUgICAgICAg ICAgIDEwICAgICAgICAgICAgMCAgICAgICAgICAgMyAgICAgMyAgICAgMCAgICAgICAgICAg IDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQxNCAoc2xlZXAg bXV0ZXg6c3luY2FjaGUpCiAgICAyNSAgICAgIDI3MjMzMDkgICAgICAgMjM2MTAwICAgICAx MDI3ODk4ICAgICAyICAgICAwICAgICAgICAxODc0MiAgICAgICAgMzM5ODcgL3Vzci9zcmMv c3lzL2tlcm4vc3Vicl9zbGVlcHF1ZXVlLmM6MzMxIChzcGluIG11dGV4OnNjaGVkIGxvY2sp CiAgICAgNSAgICAgICAgICAgMzIgICAgICAgICAgICAwICAgICAgICAgIDEwICAgICAzICAg ICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9k ZXNjcmlwLmM6MTQ3MiAoc2xlZXAgbXV0ZXg6ZmRlc2MpCiAgICAgNiAgICAgICAgICAyMDkg ICAgICAgICAgICAwICAgICAgICAgIDcxICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAg ICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdWlwY19zb2NrZXQuYzo2ODYgKHNsZWVwIG11 dGV4OnNvX3JjdikKICAgIDQ3ICAgICAgICAxMTg3NSAgICAgICAgICAxMzUgICAgICAgIDQy NTEgICAgIDIgICAgIDAgICAgICAgICAgICAxICAgICAgICAgICAgNiAvdXNyL3NyYy9zeXMv bmV0aW5ldC9pcF9vdXRwdXQuYzo1OTQgKHNsZWVwIG11dGV4OnJ0ZW50cnkpCjY5NTMyNjcg ICAgICA3NzEzMTU3ICAgICAgICAgICAgMCAgICAgICAgICA5MiA4MzgzOCAgICAgMCAgICAg ICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc192bm9wcy5jOjUx NSAobG9ja21ncjp1ZnMpCiAgICAzOSAgICAgICAgIDU1NzQgICAgICAgICAgICAwICAgICAg ICAgNTY3ICAgICA5ICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMv c3lzL2tlcm4va2Vybl9zaWcuYzo2NjEgKHNsZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAg ICA1ICAgICAgICAgICAgOSAgICAgICAgICAgIDAgICAgICAgICAgIDMgICAgIDMgICAgIDAg ICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0 MTQgKHNsZWVwIG11dGV4OnJ0ZW50cnkpCiAgICAxMyAgICAgICAgICAgODkgICAgICAgICAg ICAwICAgICAgICAgIDEwICAgICA4ICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAg L3Vzci9zcmMvc3lzL25ldGluZXQvdGNwX3RpbWV3YWl0LmM6MjcxIChzbGVlcCBtdXRleDph Y2NlcHQpCiAgICAgNiAgICAgICAgICAgOTcgICAgICAgICAgICAwICAgICAgICAgIDM2ICAg ICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4v dWlwY19zb2NrZXQuYzo3MzUgKHNsZWVwIG11dGV4OnNvX3JjdikKICAgICAzICAgICAgICAg ICAgOCAgICAgICAgICAgIDAgICAgICAgICAgIDMgICAgIDIgICAgIDAgICAgICAgICAgICAw ICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0MTQgKHNsZWVwIG11 dGV4OlRIUkVBRCkKICAgIDc3ICAgICAgICAgICA4OSAgICAgICAgICAgIDAgICAgICAgICAg IDIgICAgNDQgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMv a2Vybi92ZnNfc3lzY2FsbHMuYzozNzg0IChsb2NrbWdyOnVmcykKICAgICAyICAgICAgICAg ICAgNyAgICAgICAgICAgIDAgICAgICAgICAgIDMgICAgIDIgICAgIDAgICAgICAgICAgICAw ICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0MTQgKHNsZWVwIG11 dGV4Om1idWZfZXh0X3JlZmNudCkKICAgIDIwICAgICAgICAzNDA1OCAgICAgICAgICAgIDAg ICAgICAgMTM5MzYgICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNy L3NyYy9zeXMva2Vybi9rZXJuX3Byb3QuYzo5MSAoc2xlZXAgbXV0ZXg6cHJvY2VzcyBsb2Nr KQogICAyNjEgICAgICAgICAxOTE2ICAgICAgICAgICAgMCAgICAgICAgICAxMSAgIDE3NCAg ICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9uZXRpbmV0L3Rj cF91c3JyZXEuYzo0NzAgKHNsZWVwIG11dGV4OmlucCkKICAgMzMwICAgICAgICAgNTUwNiAg ICAgICAgICAgIDAgICAgICAgICAgMzUgICAxNTcgICAgIDAgICAgICAgICAgICAwICAgICAg ICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfdm5vcHMuYzo1NzggKGxvY2ttZ3I6dWZz KQogICAgMzAgICAgICAgICA0MjM2ICAgICAgICAgOTE5OCAgICAgICAgMTU1MSAgICAgMiAg ICAgNSAgICAgICAgICA3MjQgICAgICAgICAxMDU1IC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJf c2xlZXBxdWV1ZS5jOjQxMSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrKQogICAgMTEgICAgICAg ICAgNDY2ICAgICAgICAgICAgMCAgICAgICAgIDE4MiAgICAgMiAgICAgMCAgICAgICAgICAg IDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy92bS92bV9tYXAuYzo5ODAgKHNsZWVwIG11 dGV4OnZtIG9iamVjdCkKICAgICAzICAgICAgICAgICAgNSAgICAgICAgICAgIDAgICAgICAg ICAgIDIgICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9z eXMva2Vybi9rZXJuX3Byb3QuYzoxMDkgKHNsZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAg IDE4ICAgICAgICAgIDYwNyAgICAgICAgICAgIDAgICAgICAgICAgNjcgICAgIDkgICAgIDAg ICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvYW1kNjQvYW1kNjQvbWFj aGRlcC5jOjMzOCAoc2xlZXAgbXV0ZXg6cHJvY2VzcyBsb2NrKQogICAgIDIgICAgICAgICAg ICA1ICAgICAgICAgICAgMCAgICAgICAgICAgMiAgICAgMiAgICAgMCAgICAgICAgICAgIDAg ICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fcHJvdC5jOjEyOCAoc2xlZXAg bXV0ZXg6cHJvY2VzcyBsb2NrKQogIDEzNDIgICAgICAgMTg5MjU4ICAgICAgICAgICAgMCAg ICAgICAxMzg4NCAgICAxMyAgICAgMCAgICAgICAgICAgIDEgICAgICAgICAgICAwIC91c3Iv c3JjL3N5cy9rZXJuL3Zmc192bm9wcy5jOjYxMyAobG9ja21ncjp1ZnMpCiAgIDM3MSAgICAg ICAyMDM1NDggICAgICAgICAgIDYwICAgICAgICA0NjE4ICAgIDQ0ICAgICAwICAgICAgICAg ICAxMCAgICAgICAgICAgIDMgL3Vzci9zcmMvc3lzL25ldGluZXQvdGNwX2lucHV0LmM6NDAw IChzbGVlcCBtdXRleDp0Y3ApCiAgIDEyNSAgICAgICAgMTkzOTQgICAgICAgICAgICAwICAg ICAgICAxMDA2ICAgIDE5ICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9z cmMvc3lzL25ldGluZXQvdGNwX3N5bmNhY2hlLmM6NDY0IChzbGVlcCBtdXRleDp0Y3Bfc2Nf aGVhZCkKICAgIDQxICAgICAgICAgIDk4MSAgICAgICAgICAgIDAgICAgICAgICAgNjAgICAg MTYgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92 ZnNfc3Vici5jOjczMCAoc2xlZXAgbXV0ZXg6dm5vZGVfZnJlZV9saXN0KQogICAgIDQgICAg ICAgICAgICA5ICAgICAgICAgICAgMCAgICAgICAgICAgMyAgICAgMyAgICAgMCAgICAgICAg ICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQxNCAoc2xl ZXAgbXV0ZXg6TkZTTU9VTlQpCiAgICAgNSAgICAgICAgICAgNjAgICAgICAgICAgICAwICAg ICAgICAgIDE2ICAgICAzICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9z cmMvc3lzL25ldGluZXQvaXBfZncyLmM6MTQ2NiAoc2xlZXAgbXV0ZXg6SVBGVyBkeW5hbWlj IHJ1bGVzKQogICAgIDYgICAgICAgICAgNjAzICAgICAgICAgICAgMCAgICAgICAgIDIwNCAg ICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy92bS92 bV9vYmplY3QuYzo2NjcgKHNsZWVwIG11dGV4OnZtIG9iamVjdF9saXN0KQogICAgMzggICAg ICAgICAgMjA5ICAgICAgICAgICAgMCAgICAgICAgICAxMCAgICAyMCAgICAgMCAgICAgICAg ICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZm9yay5jOjI2NyAo c3g6YWxscHJvYykKICAgICAzICAgICAgICAgICAgNyAgICAgICAgICAgIDAgICAgICAgICAg IDMgICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMv dm0vdW1hX2NvcmUuYzo0MTQgKHNsZWVwIG11dGV4OklQRlcgZHluYW1pYyBydWxlKQogICAg MTQgICAgICAgICAgIDM5ICAgICAgICAgICAgMCAgICAgICAgICAgNSAgICAgNyAgICAgMCAg ICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy92bS92bV9vYmplY3QuYzox MzMxIChzbGVlcCBtdXRleDp2bSBwYWdlIHF1ZXVlIG11dGV4KQogICAxMjYgICAgICAgICAx MjQ5ICAgICAgICAgICAgMCAgICAgICAgICAxOSAgICA2NSAgICAgMCAgICAgICAgICAgIDAg ICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19zdWJyLmM6MjAzNSAobG9ja21n cjpkZXZmcykKICAzMTk5ICAgICAgICAyNzY1NyAgICAgICAgICAxMzkgICAgICAgIDQyNTEg ICAgIDYgICAgIDAgICAgICAgICAgIDEwICAgICAgICAgICAgOSAvdXNyL3NyYy9zeXMvbmV0 L3JvdXRlLmM6MTI4NyAoc2xlZXAgbXV0ZXg6cnRlbnRyeSkKICAgICA1ICAgICAgICAgIDE4 MiAgICAgICAgICAgIDAgICAgICAgICAgNjcgICAgIDIgICAgIDAgICAgICAgICAgICAwICAg ICAgICAgICAgMCAvdXNyL3NyYy9zeXMvYW1kNjQvYW1kNjQvbWFjaGRlcC5jOjQxNCAoc2xl ZXAgbXV0ZXg6cHJvY2VzcyBsb2NrKQogICAgMTAgICAgICAgICAgIDU4ICAgICAgICAgICAg MCAgICAgICAgICAgOCAgICAgNyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91 c3Ivc3JjL3N5cy9uZXRpbmV0L3RjcF9zdWJyLmM6NzgxIChzbGVlcCBtdXRleDphY2NlcHQp CiAgIDEzNiAgICAgICAgIDEyMTkgICAgICAgICAgICAwICAgICAgICAgIDE4ICAgIDY3ICAg ICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL25ldGluZXQvdGNw X3VzcnJlcS5jOjU3MSAoc2xlZXAgbXV0ZXg6aW5wKQogICAgNDYgICAgICAgIDI1NTA5ICAg ICAgICAgICAgMCAgICAgICAgNDI1MSAgICAgNiAgICAgMCAgICAgICAgICAgIDEgICAgICAg ICAgICAwIC91c3Ivc3JjL3N5cy9uZXQvcm91dGUuYzoxMzAzIChzbGVlcCBtdXRleDpydGVu dHJ5KQogICAgIDUgICAgICAgICAgIDQwICAgICAgICAgICAgMCAgICAgICAgICAxMiAgICAg MyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tl cm5fbXV0ZXguYzoxNDEgKHNsZWVwIG11dGV4OnZtIHBhZ2UgcXVldWUgZnJlZSBtdXRleCkK ICAgICAzICAgICAgICAgICAgOCAgICAgICAgICAgIDAgICAgICAgICAgIDMgICAgIDIgICAg IDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUu Yzo0MTQgKHNsZWVwIG11dGV4OnRjcGNiKQogICAgMzYgICAgICAgICAxMjA3ICAgICAgICAg ICAgMCAgICAgICAgICA2NyAgICAxOCAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAw IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fc2lnLmM6MjE3NyAoc3BpbiBtdXRleDpwcm9jZXNz IHNsb2NrKQogICAgMTggICAgICAgIDMzMzc4ICAgICAgICAgICAzNyAgICAgICAxMzkyNiAg ICAgMiAgICAgMCAgICAgICAgICAgIDIgICAgICAgICAgICAzIC91c3Ivc3JjL3N5cy9rZXJu L2tlcm5fY29uZi5jOjY5IChzbGVlcCBtdXRleDpjZGV2KQogICAgIDUgICAgICAgICAgIDMw ICAgICAgICAgICAgMCAgICAgICAgICAxMCAgICAgMyAgICAgMCAgICAgICAgICAgIDAgICAg ICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZGVzY3JpcC5jOjE2NzMgKHNsZWVw IG11dGV4OmZkZXNjKQogICAgIDUgICAgICAgICAgIDkzICAgICAgICAgICAxMyAgICAgICAg ICAzNiAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAxIC91c3Ivc3JjL3N5 cy9rZXJuL3VpcGNfc3lzY2FsbHMuYzo0MDQgKHNsZWVwIG11dGV4OnNvX3JjdikKICAgICAx ICAgICAgICAgICAgMSAgICAgICAgICAgIDAgICAgICAgICAgIDEgICAgIDEgICAgIDAgICAg ICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzoyMzM1 IChzbGVlcCBtdXRleDpGaWxlcykKICAgIDI2ICAgICAgMjE5OTE4NyAgICAgICAgNDU1NDMg ICAgIDEwMjM2NDcgICAgIDIgICAgIDAgICAgICAgIDE2OTA3ICAgICAgICAgNTc0MyAvdXNy L3NyYy9zeXMva2Vybi9zdWJyX3NsZWVwcXVldWUuYzo1NDEgKHNwaW4gbXV0ZXg6c2NoZWQg bG9jaykKICAgICAyICAgICAgICAgICAxMyAgICAgICAgICAgIDAgICAgICAgICAgIDcgICAg IDEgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9r ZXJuX2V4ZWMuYzo3ODQgKHNsZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAgIDExICAgICAg ICAgIDEwNSAgICAgICAgICAgIDAgICAgICAgICAgMzYgICAgIDIgICAgIDAgICAgICAgICAg ICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvbmV0aW5ldC90Y3BfdXNycmVxLmM6NjA2 IChzbGVlcCBtdXRleDppbnApCiAgICAxNCAgICAgICAgICAgNjQgICAgICAgICAgICAwICAg ICAgICAgICA3ICAgICA5ICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9z cmMvc3lzL2ZzL2RldmZzL2RldmZzX3Zmc29wcy5jOjE1NyAoc3g6ZGV2ZnNtb3VudCkKICAg ICA1ICAgICAgICAgICAzMCAgICAgICAgICAgNjAgICAgICAgICAgMTAgICAgIDMgICAgIDYg ICAgICAgICAgICA0ICAgICAgICAgICAgNiAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF80YnNk LmM6NjUwIChzcGluIG11dGV4OnNjaGVkIGxvY2spCiAgICAgNSAgICAgICAgICAgMjQgICAg ICAgICAgICAwICAgICAgICAgIDEwICAgICAyICAgICAwICAgICAgICAgICAgMSAgICAgICAg ICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfNGJzZC5jOjY1MyAoc3BpbiBtdXRleDpz Y2hlZCBsb2NrKQogICAxMzYgICAgICAgIDE1OTQ5ICAgICAgICAgIDk2OSAgICAgICAgIDQ4 MiAgICAzMyAgICAgMiAgICAgICAgICAgNjAgICAgICAgICAgIDE0IC91c3Ivc3JjL3N5cy9h bWQ2NC9hbWQ2NC9wbWFwLmM6MTk1OCAoc2xlZXAgbXV0ZXg6dm0gcGFnZSBxdWV1ZSBtdXRl eCkKICA0MzA1ICAgICAgICAyODMwMSAgICAgICAgICAgIDAgICAgICAgICAgMjMgIDEyMzAg ICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdm1fbWFw LmM6MjQxMiAoc3g6dXNlciBtYXApCiAgICAyMiAgICAgICAgIDg2ODAgICAgICAgIDIwMTQ2 ICAgICAgICAyNzAwICAgICAzICAgICA3ICAgICAgICAgMTM1OCAgICAgICAgIDIxNDYgL3Vz ci9zcmMvc3lzL2tlcm4vc3Vicl9zbGVlcHF1ZXVlLmM6NTc2IChzcGluIG11dGV4OnNjaGVk IGxvY2spCiAgICAgMyAgICAgICAgICAgIDMgICAgICAgICAgICAxICAgICAgICAgICAxICAg ICAzICAgICAxICAgICAgICAgICAgMCAgICAgICAgICAgIDEgL3Vzci9zcmMvc3lzL2tlcm4v c2NoZWRfNGJzZC5jOjY4MiAoc3BpbiBtdXRleDpzY2hlZCBsb2NrKQogICAgMzEgICAgICAg ICAgMTYwICAgICAgICAgICAgMCAgICAgICAgICAgNyAgICAyMiAgICAgMCAgICAgICAgICAg IDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9mcy9kZXZmcy9kZXZmc192bm9wcy5jOjc4 OSAobG9ja21ncjpkZXZmcykKICAgIDE5ICAgICAgICAgMjY1NSAgICAgICAgICAgIDAgICAg ICAgICAzMDEgICAgIDggICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3Ny Yy9zeXMvbmV0aW5ldC90Y3BfdGltZXdhaXQuYzo0OTAgKHNsZWVwIG11dGV4OmFjY2VwdCkK ICAxNzY5ICAgICAgIDEzNDE0MiAgICAgICAgIDY1MDUgICAgICAgNDY4OTEgICAgIDIgICAg IDAgICAgICAgICAgMTIxICAgICAgICAgIDIzNiAvdXNyL3NyYy9zeXMvdm0vdm1fcGFnZS5j OjEwMzAgKHNsZWVwIG11dGV4OnZtIHBhZ2UgcXVldWUgZnJlZSBtdXRleCkKICAgMTI0ICAg ICAgICAgMTU5OCAgICAgICAgICAgIDAgICAgICAgICAgMzcgICAgNDMgICAgIDAgICAgICAg ICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvbmV0aW5ldC90Y3BfdXNycmVxLmM6 Njk3IChzbGVlcCBtdXRleDppbnApCiAgICAyOSAgICAgICAgICAyNjUgICAgICAgICAgICAw ICAgICAgICAgIDE5ICAgIDEzICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vz ci9zcmMvc3lzL2ZzL2RldmZzL2RldmZzX3Zub3BzLmM6MTk3IChzbGVlcCBtdXRleDp2bm9k ZSBpbnRlcmxvY2spCiAgICAgMyAgICAgICAgICAgMTAgICAgICAgICAgICAwICAgICAgICAg ICAzICAgICAzICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lz L2tlcm4vdmZzX3N1YnIuYzoxNTQ1IChzbGVlcCBtdXRleDp2bm9kZSBpbnRlcmxvY2spCiAg ICAgNSAgICAgICAgICAgNTggICAgICAgICAgICAwICAgICAgICAgIDE5ICAgICAzICAgICAw ICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9tdXRl eC5jOjE0MSAoc2xlZXAgbXV0ZXg6a3F1ZXVlKQogICAgIDYgICAgICAgICAgNTc4ICAgICAg ICAgICAgMCAgICAgICAgIDE4MCAgICAgMyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAg ICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fa3RocmVhZC5jOjE5NCAoc2xlZXAgbXV0ZXg6 cHJvY2VzcyBsb2NrKQogICAgIDUgICAgICAgICAgIDQ0ICAgICAgICAgICAgMCAgICAgICAg ICAxMiAgICAgMyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5 cy9rZXJuL3Zmc19iaW8uYzozNDM3IChzbGVlcCBtdXRleDp2bSBwYWdlIHF1ZXVlIG11dGV4 KQogICAxNDUgICAgICAgIDM2ODAyICAgICAgICAgOTY2OCAgICAgICAgMjAxNyAgICAxOCAg ICAgNCAgICAgICAgICAxNzggICAgICAgICAgMjA4IC91c3Ivc3JjL3N5cy9uZXRpbmV0L3Rj cF91c3JyZXEuYzo3MjkgKHNsZWVwIG11dGV4OmlucCkKICAgICA1ICAgICAgICAgICAgOSAg ICAgICAgICAgIDAgICAgICAgICAgIDMgICAgIDMgICAgIDAgICAgICAgICAgICAwICAgICAg ICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0MTQgKHNsZWVwIG11dGV4OlVN QSBTbGFicykKICAgICAzICAgICAgICAgICAyMSAgICAgICAgICAgIDAgICAgICAgICAgIDgg ICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdm0v dW1hX2NvcmUuYzoyMzM1IChzbGVlcCBtdXRleDp0Y3B0dykKICAgIDEyICAgICAgICAgIDQ5 MSAgICAgICAgICAgMzEgICAgICAgICAxNzkgICAgIDIgICAgIDAgICAgICAgICAgICAwICAg ICAgICAgICAgMiAvdXNyL3NyYy9zeXMva2Vybi92ZnNfYmlvLmM6MTQ4NyAoc2xlZXAgbXV0 ZXg6dm5vZGUgaW50ZXJsb2NrKQogICAgMjMgICAgICAgIDUyMzE5ICAgICAgICAgICAgMCAg ICAgICAxOTI3NCAgICAgMiAgICAgMCAgICAgICAgICAgIDEgICAgICAgICAgICAwIC91c3Iv c3JjL3N5cy9rZXJuL2tlcm5fc2lnLmM6OTk2IChzbGVlcCBtdXRleDpwcm9jZXNzIGxvY2sp CiAgIDQxOSAgICAgICAgICA0NjcgICAgICAgICAgICAwICAgICAgICAgIDE4ICAgIDI1ICAg ICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdWlwY19z eXNjYWxscy5jOjU2NSAoc2xlZXAgbXV0ZXg6c29fcmN2KQogICAgMTggICAgICAgICAgMTIz ICAgICAgICAgICAgMCAgICAgICAgICAxMiAgICAxMCAgICAgMCAgICAgICAgICAgIDAgICAg ICAgICAgICAwIC91c3Ivc3JjL3N5cy9mcy9kZXZmcy9kZXZmc192bm9wcy5jOjY5MSAoc3g6 ZGV2ZnNtb3VudCkKICAzMjkzICAgICAgIDEyMTY2MSAgICAgICAgICAgIDAgICAgICAgIDEy MzYgICAgOTggICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMv bmV0aW5ldC90Y3BfdXNycmVxLmM6Nzc5IChzbGVlcCBtdXRleDppbnApCiAgICAxOCAgICAg ICAgICAzNzMgICAgICAgICAgIDM2ICAgICAgICAgIDQyICAgICA4ICAgICAwICAgICAgICAg ICAgMyAgICAgICAgICAgIDIgL3Vzci9zcmMvc3lzL3ZtL3ZtX29iamVjdC5jOjE1NTEgKHNs ZWVwIG11dGV4OnZtIHBhZ2UgcXVldWUgbXV0ZXgpCiAgICAxMiAgICAgICAgICAxNjQgICAg ICAgICAgICAwICAgICAgICAgIDM4ICAgICA0ICAgICAwICAgICAgICAgICAgMCAgICAgICAg ICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX2Jpby5jOjM0OTkgKHNsZWVwIG11dGV4OnZt IHBhZ2UgcXVldWUgbXV0ZXgpCiAgICAxMSAgICAgICAgIDE2MTggICAgICAgICAyOTM5ICAg ICAgICAgNjA5ICAgICAyICAgICA0ICAgICAgICAgIDI3NCAgICAgICAgICAzMjIgL3Vzci9z cmMvc3lzL2tlcm4vc3lzX2dlbmVyaWMuYzo3NTMgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jaykK ICAgICA4ICAgICAgICAgICA4OSAgICAgICAgICAgIDAgICAgICAgICAgMTkgICAgIDQgICAg IDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfc3Vi ci5jOjE2MjIgKHNsZWVwIG11dGV4OnZub2RlIGludGVybG9jaykKICAgIDQ4ICAgICAgICAg IDE0NyAgICAgICAgICAgIDAgICAgICAgICAgIDUgICAgMjkgICAgIDAgICAgICAgICAgICAw ICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvbmV0aW5ldC90Y3BfcmVhc3MuYzoyNjcgKHNs ZWVwIG11dGV4OnNvX3JjdikKICAgIDExICAgICAgICAgMjkzMyAgICAgICAgICA5ODMgICAg ICAgIDEwNzEgICAgIDIgICAgIDAgICAgICAgICAgIDIzICAgICAgICAgICAyNSAvdXNyL3Ny Yy9zeXMvdm0vdm1fb2JqZWN0LmM6MTU3MCAoc2xlZXAgbXV0ZXg6dm0gcGFnZSBxdWV1ZSBt dXRleCkKICAzMzEwICAgICAgICAxMTIzOCAgICAgICAgICAgIDAgICAgICAgICAgIDcgIDE2 MDUgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdm1f bWFwLmM6MjU4NCAoc3g6dXNlciBtYXApCiAgICAgMSAgICAgICAgICAgIDMgICAgICAgICAg ICAwICAgICAgICAgICAyICAgICAxICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAg L3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MjM5NCAoc2xlZXAgbXV0ZXg6dGNwdHcpCiAg ICAxMyAgICAgICAgICAxNDAgICAgICAgICAgICAwICAgICAgICAgIDE5ICAgICA3ICAgICAw ICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX3N1YnIu YzoxNjQyIChzbGVlcCBtdXRleDp2bm9kZSBpbnRlcmxvY2spCiAgICA4NSAgICAgICAgIDE3 NDIgICAgICAgICAgICAwICAgICAgICAgMTc4ICAgICA5ICAgICAwICAgICAgICAgICAgMCAg ICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0L3BtYXAuYzoyMTM5IChzbGVl cCBtdXRleDp2bSBwYWdlIHF1ZXVlIG11dGV4KQogICAgMTEgICAgICAgICAxNTkzICAgICAg ICAgMzIyOSAgICAgICAgIDYwMiAgICAgMiAgICAgNSAgICAgICAgICAyNTMgICAgICAgICAg Mzc5IC91c3Ivc3JjL3N5cy9rZXJuL3N5c19nZW5lcmljLmM6Nzc4IChzcGluIG11dGV4OnNj aGVkIGxvY2spCiAgICAzMyAgICAgIDY5MjI1MzQgICAgICAgMjg2MTE0ICAgICAxMDI5ODA0 ICAgICA2ICAgICAwICAgICAgICAzNTg5NyAgICAgICAgMzcxOTUgL3Vzci9zcmMvc3lzL2tl cm4vc2NoZWRfNGJzZC5jOjg0NyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrKQogICAgIDUgICAg ICAgICAgICA5ICAgICAgICAgICAgMCAgICAgICAgICAgMyAgICAgMyAgICAgMCAgICAgICAg ICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQxNCAoc2xl ZXAgbXV0ZXg6dGNwcmVhc3MpCiAgMTE5MiAgICAgMTkxMjgzMTkgICAgICA2MTU3MDgzICAg ICAgIDYzNDEyICAgMzAxICAgIDk3ICAgICAgICA0MjEzMiAgICAgICAgMjM1MTEgL3Vzci9z cmMvc3lzL2tlcm4vdmZzX2hhc2guYzo3OSAoc2xlZXAgbXV0ZXg6dm5vZGUgaW50ZXJsb2Nr KQogICAgIDQgICAgICAgICAgICA2ICAgICAgICAgICAxMCAgICAgICAgICAgMiAgICAgMyAg ICAgNSAgICAgICAgICAgIDEgICAgICAgICAgICAyIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJf c2xlZXBxdWV1ZS5jOjc1NCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrKQogICAgMTIgICAgICAg ICAxNjE3ICAgICAgICAgMjk1OCAgICAgICAgIDYwNCAgICAgMiAgICAgNCAgICAgICAgICAx OTEgICAgICAgICAgMjQzIC91c3Ivc3JjL3N5cy9rZXJuL3N5c19nZW5lcmljLmM6Nzk1IChz cGluIG11dGV4OnNjaGVkIGxvY2spCiAgICAzMSAgICAgICAgIDEzMDIgICAgICAgICAgICAw ICAgICAgICAgNDU1ICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vz ci9zcmMvc3lzL3ZtL3ZtX29iamVjdC5jOjM1MiAoc2xlZXAgbXV0ZXg6dm0gb2JqZWN0KQog ICAgMTIgICAgICAgICAgIDYzICAgICAgICAgICAgMCAgICAgICAgICAgNyAgICAgOSAgICAg MCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9mcy9kZXZmcy9kZXZm c192bm9wcy5jOjM1MSAoc2xlZXAgbXV0ZXg6dm5vZGUgaW50ZXJsb2NrKQogICAgIDUgICAg ICAgICAgMTA4ICAgICAgICAgICAgMCAgICAgICAgICAzOCAgICAgMiAgICAgMCAgICAgICAg ICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19iaW8uYzoyMzI2IChz bGVlcCBtdXRleDp2bSBvYmplY3QpCiAgICAyMyAgICAgICAgICAgMzkgICAgICAgICAgICAw ICAgICAgICAgICAzICAgIDEzICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vz ci9zcmMvc3lzL2tlcm4va2Vybl9wcm90LmM6NDgxIChzbGVlcCBtdXRleDpwcm9jZXNzIGxv Y2spCiAgICAgNyAgICAgICAgICAgMjIgICAgICAgICAgICAwICAgICAgICAgICA0ICAgICA1 ICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vy bl9ldmVudC5jOjE2NjQgKHNsZWVwIG11dGV4OnBpcGUgbXV0ZXgpCiAgICA2OCAgICAgICAg ICA0NDMgICAgICAgICAgICAwICAgICAgICAgICA5ICAgIDQ5ICAgICAwICAgICAgICAgICAg MCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL25ldGluZXQvdGNwX3VzcnJlcS5jOjI1NCAo c2xlZXAgbXV0ZXg6dGNwKQogIDE0MzYgICAgICAgMTMwMDIxICAgICAgICA0MDM4NiAgICAg ICA0NzE5MiAgICAgMiAgICAgMCAgICAgICAgICAxMDEgICAgICAgICAgNDI4IC91c3Ivc3Jj L3N5cy92bS92bV9mYXVsdC5jOjg4NyAoc2xlZXAgbXV0ZXg6dm0gcGFnZSBxdWV1ZSBtdXRl eCkKICAgIDI5ICAgICAgICAgNDEyNSAgICAgICAgICAgIDAgICAgICAgICA1MDYgICAgIDgg ICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvbmV0aW5ldC90 Y3BfaW5wdXQuYzoyODUwIChzbGVlcCBtdXRleDpzb19zbmQpCiAgICAgMSAgICAgICAgICAg IDEgICAgICAgICAgICAwICAgICAgICAgICAxICAgICAxICAgICAwICAgICAgICAgICAgMCAg ICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2ZzL2ZpZm9mcy9maWZvX3Zub3BzLmM6Mjk3IChz bGVlcCBtdXRleDpzbGVlcCBtdHhwb29sKQogICAgMTkgICAgICAgICAgODI5ICAgICAgICAg ICAgMCAgICAgICAgICA2NyAgICAxMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAw IC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfdHJhcC5jOjI0NyAoc2xlZXAgbXV0ZXg6cHJvY2Vz cyBsb2NrKQogICAgNDMgICAgICAgICAgMTEwICAgICAgICAgICAgMCAgICAgICAgICAgNSAg ICAyMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJu L3Zmc19iaW8uYzoxNjQ5IChzbGVlcCBtdXRleDp2bm9kZSBpbnRlcmxvY2spCiAgICAxMyAg ICAgICAgICAgMTMgICAgICAgICAgICAwICAgICAgICAgICAxICAgIDEzICAgICAwICAgICAg ICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9yZXNvdXJjZS5j OjI2NiAoc3BpbiBtdXRleDpwcm9jZXNzIHNsb2NrKQogIDIzNjggICAgICAgMTU4Nzc3ICAg ICAgICAgICAyMiAgICAgICA0ODI5OCAgICAgMyAgICAgMCAgICAgICAgICAgIDEgICAgICAg ICAgICAxIC91c3Ivc3JjL3N5cy92bS92bV9vYmplY3QuYzo0NDEgKHNsZWVwIG11dGV4OnZt IG9iamVjdCkKICAgICA0ICAgICAgICAgICAyMSAgICAgICAgICAgMTEgICAgICAgICAgIDYg ICAgIDMgICAgIDEgICAgICAgICAgICAyICAgICAgICAgICAgMSAvdXNyL3NyYy9zeXMva2Vy bi9zdWJyX3NsZWVwcXVldWUuYzo4NTIgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jaykKICAgIDE5 ICAgICAgICAgMzY3OCAgICAgICAgICAgIDAgICAgICAgICA0OTAgICAgIDcgICAgIDAgICAg ICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdm1fdW5peC5jOjg4IChz eDp1c2VyIG1hcCkKICAgICAxICAgICAgICAgICAgMSAgICAgICAgICAgIDAgICAgICAgICAg IDEgICAgIDEgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMv ZnMvZmlmb2ZzL2ZpZm9fdm5vcHMuYzoyMjQgKHNsZWVwIG11dGV4OmZpZm8gbXV0ZXgpCiAg ICAxMCAgICAgICAgIDExNDcgICAgICAgICAgICAwICAgICAgICAgNDQxICAgICAyICAgICAw ICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3ZtX21tYXAuYzoy ODQgKHNsZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAxMTI5ICAgICAgIDI1ODg2NCAgICAg ICAgNDk0NjUgICAgICAgNDcxOTYgICAgIDUgICAgIDEgICAgICAgICAgMjUwICAgICAgICAg IDQ0MyAvdXNyL3NyYy9zeXMvYW1kNjQvYW1kNjQvcG1hcC5jOjIyNjAgKHNsZWVwIG11dGV4 OnZtIHBhZ2UgcXVldWUgbXV0ZXgpCiAgICAgNSAgICAgICAgICAgMjEgICAgICAgICAgICAw ICAgICAgICAgICA4ICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vz ci9zcmMvc3lzL3ZtL3ZtX21hcC5jOjI3MTMgKHN4OnVzZXIgbWFwKQogICAgIDUgICAgICAg ICAgIDEwICAgICAgICAgICAgMCAgICAgICAgICAgMyAgICAgMyAgICAgMCAgICAgICAgICAg IDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQxNCAoc2xlZXAg bXV0ZXg6bWJ1Zl9jbHVzdGVyKQogICAgIDUgICAgICAgICAgIDUwICAgICAgICAgICAgMCAg ICAgICAgICAxNiAgICAgMyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Iv c3JjL3N5cy9rZXJuL2tlcm5fZXZlbnQuYzo1MzQgKHNsZWVwIG11dGV4OnNsZWVwIG10eHBv b2wpCiAgICAgMyAgICAgICAgICAgMTYgICAgICAgICAgICAwICAgICAgICAgICA2ICAgICAy ICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9j b3JlLmM6NDE0IChzbGVlcCBtdXRleDptYnVmKQogICAgIDYgICAgICAgICAgMTk3ICAgICAg ICAgICAgMCAgICAgICAgICA2MCAgICAgMyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAg ICAwIC91c3Ivc3JjL3N5cy91ZnMvZmZzL2Zmc19zb2Z0ZGVwLmM6NzMzIChzbGVlcCBtdXRl eDpTb2Z0ZGVwIExvY2spCiAgICA2MiAgICAgICAgICA5NTUgICAgICAgICAgICAwICAgICAg ICAgIDQ3ICAgIDIwICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMv c3lzL25ldGluZXQvdGNwX3VzcnJlcS5jOjk1NiAoc2xlZXAgbXV0ZXg6aW5wKQogIDEwMDgg ICAgICAgMTMwNTg1ICAgICAgICAgIDg5MCAgICAgICA0ODA3NCAgICAgMiAgICAgMCAgICAg ICAgICAgNDUgICAgICAgICAgIDQ3IC91c3Ivc3JjL3N5cy92bS92bV9wYWdlLmM6MTMxNSAo c2xlZXAgbXV0ZXg6dm0gcGFnZSBxdWV1ZSBmcmVlIG11dGV4KQogICAgMjIgICAgICAgICA2 NDY1ICAgICAgICAxMjc0MyAgICAgICAgMjQ0NiAgICAgMiAgICAgNSAgICAgICAgICA5MDkg ICAgICAgICAxMTY2IC91c3Ivc3JjL3N5cy9rZXJuL3N5c19nZW5lcmljLmM6OTI3IChzcGlu IG11dGV4OnNjaGVkIGxvY2spCiAgIDEzNSAgICAgICAgIDQ0ODMgICAgICAgICAgICAwICAg ICAgICAxNTUxICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9z cmMvc3lzL2tlcm4vc3Vicl9zbGVlcHF1ZXVlLmM6MzkyIChzbGVlcCBtdXRleDpzaWdhY3Rz KQogICA5NjEgICAgICAgICA0MTYwICAgICAgICAgICAgMCAgICAgICAgIDE4MSAgICAyMiAg ICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy92bS92bV9tYXAu YzoxNDY3IChzbGVlcCBtdXRleDp2bSBvYmplY3QpCiAgICAzNyAgICAgICAgICAgOTIgICAg ICAgICAgICAwICAgICAgICAgICA1ICAgIDE4ICAgICAwICAgICAgICAgICAgMCAgICAgICAg ICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9wcm90LmM6NTkzIChzbGVlcCBtdXRleDpw cm9jZXNzIGxvY2spCiAgMzA4OSAgICAgICAgIDgyMjEgICAgICAgICAgICAwICAgICAgICAg IDI4ICAgMjkzICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lz L3ZtL3ZtX29iamVjdC5jOjQ5NyAoc2xlZXAgbXV0ZXg6dm0gb2JqZWN0KQogICAgMjIgICAg ICAgICA4NjQ3ICAgICAgICAgICAgMCAgICAgICAgMzA5OCAgICAgMiAgICAgMCAgICAgICAg ICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3VpcGNfc3lzY2FsbHMuYzox MzUgKHNsZWVwIG11dGV4OnNsZWVwIG10eHBvb2wpCiAgICAxMyAgICAgICAgICAgNzkgICAg ICAgICAgICAwICAgICAgICAgICA4ICAgICA5ICAgICAwICAgICAgICAgICAgMCAgICAgICAg ICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX2Jpby5jOjM2OTIgKHNsZWVwIG11dGV4OnZt IHBhZ2UgcXVldWUgbXV0ZXgpCiAgICAzMSAgICAgICAgMjAwMjYgICAgICAgICAgMTI2ICAg ICAgICAyNTkwICAgICA3ICAgICAwICAgICAgICAgICAgOCAgICAgICAgICAgMTAgL3Vzci9z cmMvc3lzL3ZtL3ZtX2ZhdWx0LmM6OTgxIChzbGVlcCBtdXRleDp2bSBwYWdlIHF1ZXVlIG11 dGV4KQogICAgMzYgICAgICAgICAgMzU0ICAgICAgICAgICAgMCAgICAgICAgICA2MCAgICAg NSAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy91ZnMvZmZz L2Zmc19zb2Z0ZGVwLmM6NzcwIChzbGVlcCBtdXRleDpTb2Z0ZGVwIExvY2spCiAgICAyMSAg ICAgICAgIDIzMzAgICAgICAgICA2MTMwICAgICAgICAgODYyICAgICAyICAgICA3ICAgICAg ICAgIDM4NiAgICAgICAgICA1MTIgL3Vzci9zcmMvc3lzL2tlcm4vc3lzX2dlbmVyaWMuYzo5 NTAgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jaykKICAgICAzICAgICAgICAgICAxMCAgICAgICAg ICAgIDAgICAgICAgICAgIDMgICAgIDMgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAg MCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0MTQgKHNsZWVwIG11dGV4OjI1NikKICAg ICAyICAgICAgICAgICAgNiAgICAgICAgICAgIDAgICAgICAgICAgIDMgICAgIDIgICAgIDAg ICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0 MTQgKHNsZWVwIG11dGV4Om1idWZfanVtYm9fMTZrKQogICAgMTEgICAgICAgICA0MzQzICAg ICAgICAgNzY3NCAgICAgICAgMTU4NCAgICAgMiAgICAgNCAgICAgICAgICA2OTMgICAgICAg ICAgODQ1IC91c3Ivc3JjL3N5cy9rZXJuL3N5c19nZW5lcmljLmM6OTY3IChzcGluIG11dGV4 OnNjaGVkIGxvY2spCiAgICAgNCAgICAgICAgICAgIDggICAgICAgICAgICAwICAgICAgICAg ICAzICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lz L3Vmcy9mZnMvZmZzX3NvZnRkZXAuYzo0ODg5IChzbGVlcCBtdXRleDpTb2Z0ZGVwIExvY2sp CiAgICAyMyAgICAgICAgIDE0MTIgICAgICAgICAgICAwICAgICAgICAgNTAzICAgICAyICAg ICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdWlwY19z b2NrZXQuYzo0MDkgKHNsZWVwIG11dGV4OmFjY2VwdCkKICAgIDE4ICAgICAgICAgIDE4OSAg ICAgICAgICAgIDAgICAgICAgICAgMjUgICAgIDcgICAgIDAgICAgICAgICAgICAwICAgICAg ICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfc3Vici5jOjE4NjAgKHNsZWVwIG11dGV4 OnZub2RlIGludGVybG9jaykKICAgICA1ICAgICAgICAgICA4MiAgICAgICAgICAgIDAgICAg ICAgICAgMzEgICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3Ny Yy9zeXMva2Vybi91aXBjX3N5c2NhbGxzLmM6MTgzIChzbGVlcCBtdXRleDpzbGVlcCBtdHhw b29sKQogICAgMTUgICAgICAgICAgIDMyICAgICAgICAgICAgMCAgICAgICAgICAgMyAgICAx MCAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tl cm5fcHJvdC5jOjY0NiAoc2xlZXAgbXV0ZXg6cHJvY2VzcyBsb2NrKQogICAgMzQgICAgICAg ICAgMjUxICAgICAgICAgICAgMCAgICAgICAgICA3NCAgICAgMyAgICAgMCAgICAgICAgICAg IDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fc2lnLmM6MjEwMiAoc2xl ZXAgbXV0ZXg6c2lnYWN0cykKICAgIDI3ICAgICAgIDEyNzgxOSAgICAgICAgIDM5MDkgICAg ICAgNjIwODkgICAgIDIgICAgIDAgICAgICAgICAxMTkyICAgICAgICAgIDQxNCAvdXNyL3Ny Yy9zeXMva2Vybi9rZXJuX3N5bmNoLmM6MjE2IChzcGluIG11dGV4OnNjaGVkIGxvY2spCiAg ICAgNiAgICAgICAgICAzNzggICAgICAgICAgICAwICAgICAgICAgMTI5ICAgICAyICAgICAw ICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3ZtX29iamVjdC5j OjU2NyAoc2xlZXAgbXV0ZXg6dm0gb2JqZWN0KQogIDMyMDggICAgICAgMjQ2NTk5ICAgICAg ICAgIDIxOCAgICAgICAgIDM0NiAgIDcxMiAgICAgMCAgICAgICAgICAgNjMgICAgICAgICAg IDEzIC91c3Ivc3JjL3N5cy92bS92bV9vYmplY3QuYzoxODE2IChzbGVlcCBtdXRleDp2bSBw YWdlIHF1ZXVlIG11dGV4KQogICAgMTMgICAgICAgICAgOTgxICAgICAgICAgICAgMCAgICAg ICAgIDMwMCAgICAgMyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3Jj L3N5cy91ZnMvZmZzL2Zmc19zb2Z0ZGVwLmM6ODQzIChzbGVlcCBtdXRleDpTb2Z0ZGVwIExv Y2spCiAgICA2MiAgICAgICAgICA3NzAgICAgICAgICAgICAwICAgICAgICAgIDI4ICAgIDI3 ICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL25ldGluZXQv dWRwX3VzcnJlcS5jOjM4NSAoc2xlZXAgbXV0ZXg6dWRwKQogICAgNDEgICAgICAgICAxMjI0 ICAgICAgICAgICAgMCAgICAgICAgICA2NiAgICAxOCAgICAgMCAgICAgICAgICAgIDIgICAg ICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fc3lzY3RsLmM6MTMzNCAoc2xlZXAg bXV0ZXg6R2lhbnQpCiAgICAgNCAgICAgICAgICAgNDUgICAgICAgICAgICAwICAgICAgICAg IDIxICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lz L3ZtL3VtYV9jb3JlLmM6ODg5IChzbGVlcCBtdXRleDp0Y3BjYikKICAgICA1ICAgICAgICAg ICAxNSAgICAgICAgICAgIDAgICAgICAgICAgIDQgICAgIDMgICAgIDAgICAgICAgICAgICAw ICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdm1fZmF1bHQuYzoxMDYxIChzbGVlcCBt dXRleDp2bSBwYWdlIHF1ZXVlIG11dGV4KQogICAgMjIgICAgICAgICAxMzMwICAgICAgICAg ICAgMCAgICAgICAgIDQ5NSAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAw IC91c3Ivc3JjL3N5cy9rZXJuL3VpcGNfc29ja2V0LmM6NDUxIChzbGVlcCBtdXRleDphY2Nl cHQpCiAgICAgNiAgICAgICAgIDE3NTkgICAgICAgICAgICAwICAgICAgICAgNjAxICAgICAy ICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2dlb20vZ2Vv bV9ldmVudC5jOjE4NyAoc2xlZXAgbXV0ZXg6R0VPTSBvcnBoYW5hZ2UpCiAgICA0MiAgICAg IDIwMzQ1NTIgICAgICAzMDY1MzMyICAgICAxMDI5ODA0ICAgICAxICAgICAyICAgICAgICA0 MDU1NyAgICAgICAyNzQ2NzEgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfNGJzZC5jOjExMDIg KHNwaW4gbXV0ZXg6c2NoZWQgbG9jaykKICAgICAzICAgICAgICAgICAgNSAgICAgICAgICAg MzggICAgICAgICAgIDIgICAgIDIgICAgMTkgICAgICAgICAgICAwICAgICAgICAgICAgMSAv dXNyL3NyYy9zeXMva2Vybi9zY2hlZF80YnNkLmM6Mzg1IChzcGluIG11dGV4OnR1cm5zdGls ZSBsb2NrKQogICAgMTkgICAgICAgICA1NjcyICAgICAgICAgICAgMCAgICAgICAgIDYwMSAg ICAgOSAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9nZW9t L2dlb21fZXZlbnQuYzoyMDEgKHNsZWVwIG11dGV4OkdFT00gb3JwaGFuYWdlKQogICAgMjIg ICAgICAgICA0MTM1ICAgICAgICAgICAgMCAgICAgICAgMTUzMCAgICAgMiAgICAgMCAgICAg ICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9uZXRpbmV0L3RjcF9ob3N0Y2Fj aGUuYzoyOTEgKHNsZWVwIG11dGV4OnRjcF9oY19lbnRyeSkKICAgNjA0ICAgICAgICAgMTUy NCAgICAgICAgICAgIDAgICAgICAgICAgIDMgICA1MDggICAgIDAgICAgICAgICAgICAwICAg ICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzoxNDkyIChzbGVlcCBtdXRl eDpVTUEgbG9jaykKICAgICA1ICAgICAgICAgIDIwNyAgICAgICAgICAgIDAgICAgICAgICAg NjAgICAgIDMgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMv a2Vybi9rZXJuX211dGV4LmM6MTQxIChzbGVlcCBtdXRleDpTb2Z0ZGVwIExvY2spCiAgIDI3 MyAgICAgICAgIDE5OTEgICAgICAgICAgICAwICAgICAgICAgIDExICAgMTgxICAgICAwICAg ICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL25ldGluZXQvdGNwX3VzcnJl cS5jOjQ2NyAoc2xlZXAgbXV0ZXg6dGNwKQogICAgNTcgICAgICAgICAgMjYwICAgICAgICAg ICAgMCAgICAgICAgICAgNyAgICAzNyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAw IC91c3Ivc3JjL3N5cy9rZXJuL3Zmc192bm9wcy5jOjI4OCAobG9ja21ncjpkZXZmcykKICAg IDIwICAgICAgICAgICA0OSAgICAgICAgICAgIDAgICAgICAgICAgIDQgICAgMTIgICAgIDAg ICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3Byb3Qu Yzo3NDUgKHNsZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAgIDE5ICAgICAgICAzMzk3OCAg ICAgICAgIDU0OTYgICAgICAgMTM4NTAgICAgIDIgICAgIDAgICAgICAgICAgIDU3ICAgICAg ICAgIDE1MiAvdXNyL3NyYy9zeXMva2Vybi92ZnNfbW91bnQuYzo0MzIgKHNsZWVwIG11dGV4 OnN0cnVjdCBtb3VudCBtdHgpCiAgICA5NCAgICAgICAyMTM0ODcgICAgICAgIDI4ODExICAg ICAgIDYzNzM1ICAgICAzICAgICAwICAgICAgICAgIDI5OCAgICAgICAgICA4NTIgL3Vzci9z cmMvc3lzL2tlcm4vdmZzX21vdW50LmM6NDQxIChzbGVlcCBtdXRleDpzdHJ1Y3QgbW91bnQg bXR4KQogICAgNzIgICAgICAgICA2NjU0ICAgICAgICAgIDM5MSAgICAgICAgMjE1MiAgICAg MyAgICAgMCAgICAgICAgICAgMTcgICAgICAgICAgIDI1IC91c3Ivc3JjL3N5cy9rZXJuL3Vp cGNfc29ja2V0LmM6MTQyNCAoc2xlZXAgbXV0ZXg6c29fcmN2KQogICAgMTEgICAgICAgICAg IDExICAgICAgICAgICAgMCAgICAgICAgICAgMSAgICAxMSAgICAgMCAgICAgICAgICAgIDAg ICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19zeXNjYWxscy5jOjM2NyAobG9j a21ncjp1ZnMpCiAgICAgMyAgICAgICAgICAgIDggICAgICAgICAgICAwICAgICAgICAgICAz ICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL3Zt L3VtYV9jb3JlLmM6NDE0IChzbGVlcCBtdXRleDpNQVApCiAgICAgMyAgICAgICAgICAgIDMg ICAgICAgICAgICAwICAgICAgICAgICAxICAgICAzICAgICAwICAgICAgICAgICAgMCAgICAg ICAgICAgIDAgL3Vzci9zcmMvc3lzL3Vmcy91ZnMvdWZzX3Zub3BzLmM6MjAzOCAoc2xlZXAg bXV0ZXg6dm5vZGUgaW50ZXJsb2NrKQogICAgIDUgICAgICAgICAgIDYyICAgICAgICAgIDE3 NiAgICAgICAgICAyMSAgICAgMiAgICAgOCAgICAgICAgICAgMTIgICAgICAgICAgIDE2IC91 c3Ivc3JjL3N5cy9rZXJuL3N5c19nZW5lcmljLmM6MTE0MCAoc3BpbiBtdXRleDpzY2hlZCBs b2NrKQogICAgMTAgICAgICAgICAxMTI4ICAgICAgICAgICAgMCAgICAgICAgIDI5NyAgICAg MyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3Zm c19zdWJyLmM6MjAxOSAoc2xlZXAgbXV0ZXg6dm5vZGUgaW50ZXJsb2NrKQogICAgMjIgICAg ICAgICAgIDg2ICAgICAgICAgICAgMCAgICAgICAgICAgNiAgICAxNCAgICAgMCAgICAgICAg ICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fcHJvdC5jOjgwNyAo c2xlZXAgbXV0ZXg6cHJvY2VzcyBsb2NrKQogICAgMjQgICAgICAgIDE3MDQ3ICAgICAgICAg ICAgMCAgICAgICAgNjAwMSAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAw IC91c3Ivc3JjL3N5cy9uZXRpbmV0L2lwX2R1bW15bmV0LmM6NzM5IChzbGVlcCBtdXRleDpk dW1teW5ldCkKICAgICA3ICAgICAgICAgMTE1OCAgICAgICAgICAgIDAgICAgICAgICA0MjQg ICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vy bi91aXBjX3NvY2tidWYuYzoxMTYgKHNsZWVwIG11dGV4OnNvX3JjdikKICAgMTQ1ICAgICAg ICAgMTMzMiAgICAgICAgICAgIDAgICAgICAgICAgMTggICAgNzQgICAgIDAgICAgICAgICAg ICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvbmV0aW5ldC90Y3BfdXNycmVxLmM6NTY4 IChzbGVlcCBtdXRleDp0Y3ApCiAgMjM3OCAgICAgICA5MDIwMDEgICAgICAgODA1MDcxICAg ICAgMzQwOTUzICAgICAyICAgICAyICAgICAgICAgIDIxMyAgICAgICAgIDU4OTUgL3Vzci9z cmMvc3lzL2tlcm4vdmZzX3N1YnIuYzoyMDM5IChzbGVlcCBtdXRleDp2bm9kZSBpbnRlcmxv Y2spCiAgICAgNSAgICAgICAgICAgIDUgICAgICAgICAgICAwICAgICAgICAgICAxICAgICA1 ICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL3Vmcy9mZnMv ZmZzX3NvZnRkZXAuYzo5OTkgKHNsZWVwIG11dGV4OlNvZnRkZXAgTG9jaykKICAgIDEyICAg ICAgICAgICA1NSAgICAgICAgICAgIDAgICAgICAgICAgMTYgICAgIDMgICAgIDAgICAgICAg ICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2V2ZW50LmM6NTMw IChzeDpmaWxlZGVzYyBzdHJ1Y3R1cmUpCiAgICAgNSAgICAgICAgICAxMTcgICAgICAgICAg ICAwICAgICAgICAgIDQwICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAg L3Vzci9zcmMvc3lzL2tlcm4va2Vybl9leGl0LmM6MjMzIChzbGVlcCBtdXRleDpwcm9jZXNz X2V4aXQpCiAgMjQ0OSAgICAgICA0OTMyMDkgICAgICAgMTA3OTg1ICAgICAgMTkzNDI1ICAg ICAyICAgICAwICAgICAgICAgMTIyOSAgICAgICAgIDM2MjQgL3Vzci9zcmMvc3lzL2tlcm4v dmZzX3N1YnIuYzoyMDYyIChzbGVlcCBtdXRleDp2bm9kZSBpbnRlcmxvY2spCiAgICAyMiAg ICAgICAgMTY3NDAgICAgICAgICAgIDEwICAgICAgICA2MDAxICAgICAyICAgICAwICAgICAg ICAgICAgMCAgICAgICAgICAgIDMgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9zeW5jaC5jOjMy MCAoc3BpbiBtdXRleDpmYXN0X3Rhc2txdWV1ZSkKICAgICA1ICAgICAgICAgICAgOSAgICAg ICAgICAgIDAgICAgICAgICAgIDIgICAgIDQgICAgIDAgICAgICAgICAgICAwICAgICAgICAg ICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3NpZy5jOjE0NjggKHNsZWVwIG11dGV4OnBy b2Nlc3MgbG9jaykKICAgIDIzICAgICAgIDE1NTk0MCAgICAgICAxMjQzODQgICAgICAgNjIx NTQgICAgIDIgICAgIDIgICAgICAgIDEyMjYyICAgICAgICAxODMxNCAvdXNyL3NyYy9zeXMv a2Vybi9zY2hlZF80YnNkLmM6MTI4MSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrKQogICAgIDUg ICAgICAgICAgIDEwICAgICAgICAgICAgMCAgICAgICAgICAgMyAgICAgMyAgICAgMCAgICAg ICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQxNCAo c2xlZXAgbXV0ZXg6MzIpCiAgICAgNCAgICAgICAgICAgNDEgICAgICAgICAgICAwICAgICAg ICAgIDE2ICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMv c3lzL25ldGluZXQvdGNwX3VzcnJlcS5jOjEyNTMgKHNsZWVwIG11dGV4OmlucCkKICAgIDEx ICAgICAgICAgICAzOCAgICAgICAgICAgIDAgICAgICAgICAgIDQgICAgIDkgICAgIDAgICAg ICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfZGVmYXVsdC5j OjQxMCAoc2xlZXAgbXV0ZXg6dm5vZGUgaW50ZXJsb2NrKQogICAgIDQgICAgICAgICAgIDEx ICAgICAgICAgICAgMCAgICAgICAgICAgMyAgICAgMyAgICAgMCAgICAgICAgICAgIDAgICAg ICAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQxNCAoc2xlZXAgbXV0ZXg6 NjQgQnVja2V0KQogICA3NzEgICAgICAgMTY1NTQ1ICAgICAgICAgIDM0NSAgICAgICA2NDU5 NiAgICAgMiAgICAgMCAgICAgICAgIDExOTggICAgICAgICAgIDE3IC91c3Ivc3JjL3N5cy9r ZXJuL3Zmc19zdWJyLmM6MjEwMSAoc2xlZXAgbXV0ZXg6dm5vZGUgaW50ZXJsb2NrKQogICAg IDUgICAgICAgICAgIDkxICAgICAgICAgICAgMCAgICAgICAgICAzNiAgICAgMiAgICAgMCAg ICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3VpcGNfc3lzY2Fs bHMuYzo0MjYgKHNsZWVwIG11dGV4OnNsZWVwIG10eHBvb2wpCiAgICAxNSAgICAgICAgICAg OTggICAgICAgICAgICAwICAgICAgICAgIDEyICAgICA4ICAgICAwICAgICAgICAgICAgMCAg ICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3ZtX2dsdWUuYzoyNTcgKHNsZWVwIG11dGV4 OnZtIG9iamVjdCkKICAgIDI1ICAgICAgICAgMzk1OSAgICAgICAgICAgIDAgICAgICAgICA0 ODAgICAgIDggICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMv a2Vybi9rZXJuX3Jlc291cmNlLmM6NjMxIChzcGluIG11dGV4OnByb2Nlc3Mgc2xvY2spCiAg ICAgNSAgICAgICAgICAxODIgICAgICAgICAgICAwICAgICAgICAgIDY3ICAgICAyICAgICAw ICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9zaWcu Yzo1OTEgKHNwaW4gbXV0ZXg6c2xlZXBxIGNoYWluKQogICAgMTEgICAgICAgICAgIDQzICAg ICAgICAgICAgMCAgICAgICAgICAgNyAgICAgNiAgICAgMCAgICAgICAgICAgIDAgICAgICAg ICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19kZWZhdWx0LmM6NDQyIChzbGVlcCBtdXRl eDp2bm9kZSBpbnRlcmxvY2spCiAgICAgNiAgICAgICAgICAxNTAgICAgICAgICAgICAwICAg ICAgICAgIDUyICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9z cmMvc3lzL2tlcm4vdmZzX3N1YnIuYzoyMTMxIChzbGVlcCBtdXRleDp2bm9kZSBpbnRlcmxv Y2spCiAgICAxOCAgICAgICAgICA2NzMgICAgICAgICAgICAwICAgICAgICAgIDcxICAgICA5 ICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdWlw Y19zb2NrZXQuYzo2ODUgKHNsZWVwIG11dGV4OmFjY2VwdCkKICAgMTAyICAgICAgICAxMjk0 MiAgICAgICAgICAgIDAgICAgICAgICA1MzAgICAgMjQgICAgIDAgICAgICAgICAgICAwICAg ICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi91aXBjX3NvY2tidWYuYzoyMzIgKHNsZWVw IG11dGV4OnNvX3JjdikKICAzMjE1ICAgICAgMzAwMTQwNSAgICAgICAgICAgIDAgICAgICAg NDcxOTIgICAgNjMgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9z eXMvdm0vdm1fbWFwLmM6MzA5MiAoc3g6dXNlciBtYXApCiAgICAgNCAgICAgICAgICAgIDgg ICAgICAgICAgICAwICAgICAgICAgICAzICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAg ICAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6NDE0IChzbGVlcCBtdXRleDpO RlNOT0RFKQogICAgMTcgICAgICAgICAgMTAyICAgICAgICAgICAgMCAgICAgICAgICAxMCAg ICAxMCAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJu L2tlcm5fZm9yay5jOjM5MCAoc2xlZXAgbXV0ZXg6cHJvY2VzcyBsb2NrKQogICAgIDkgICAg ICAgICAgIDUwICAgICAgICAgICAgMCAgICAgICAgICAxMCAgICAgNSAgICAgMCAgICAgICAg ICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZm9yay5jOjM5MSAo c2xlZXAgbXV0ZXg6cHJvY2VzcyBsb2NrKQogICAgMTAgICAgICAgICAgMzM2ICAgICAgICAg ICAgMCAgICAgICAgIDEyMCAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAw IC91c3Ivc3JjL3N5cy9jb250cmliL2lwZmlsdGVyL25ldGluZXQvZmlsLmM6NjU4NyAocnc6 aXBmIHRva2VuIHJ3bG9jaykKICAzMDU0ICAgICAxNjA3Nzc3NCAgICAgIDM1MTYzMTMgICAg ICA0Njk3ODMgICAgMzQgICAgIDcgICAgICAgIDE0ODI1ICAgICAgICAxNjU0MiAvdXNyL3Ny Yy9zeXMva2Vybi92ZnNfc3Vici5jOjIxNTkgKHNsZWVwIG11dGV4OnZub2RlIGludGVybG9j aykKICAgMTM1ICAgICAgICAgMTgyMCAgICAgICAgICAxMTcgICAgICAgICAgMzcgICAgNDkg ICAgIDMgICAgICAgICAgICAyICAgICAgICAgICAgMSAvdXNyL3NyYy9zeXMvbmV0aW5ldC90 Y3BfdXNycmVxLmM6Njk0IChzbGVlcCBtdXRleDp0Y3ApCiAgICAgNCAgICAgICAgICAgIDQg ICAgICAgICAgICAwICAgICAgICAgICAxICAgICA0ICAgICAwICAgICAgICAgICAgMCAgICAg ICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9yZXNvdXJjZS5jOjY5OCAoc3BpbiBt dXRleDpwcm9jZXNzIHNsb2NrKQogICAgIDYgICAgICAgICAgIDQxICAgICAgICAgICAgMCAg ICAgICAgICAxNyAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Iv c3JjL3N5cy9rZXJuL2tlcm5fZGVzY3JpcC5jOjQyOCAoc2xlZXAgbXV0ZXg6c2xlZXAgbXR4 cG9vbCkKICAgIDM0ICAgICAgMTM3MDMyMyAgICAgIDg4NzA3MTYgICAgICA0MTE5OTYgICAg IDMgICAgMjEgICAgICAgNDgxMzkzICAgICAgIDQxMDU1NSAvdXNyL3NyYy9zeXMva2Vybi9z Y2hlZF80YnNkLmM6MTM4MSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrKQogIDExODIgICAgICAg MzMwMDM5ICAgICAgICAxODQzNiAgICAgICA2MzczMCAgICAgNSAgICAgMCAgICAgICAgICA3 MTEgICAgICAgICAgNDc4IC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19zdWJyLmM6MzM3IChzbGVl cCBtdXRleDpzdHJ1Y3QgbW91bnQgbXR4KQogICAgOTAgICAgICAgICAgODI1ICAgICAgICAg ICAgMCAgICAgICAgICAxNiAgICA1MSAgICAgMCAgICAgICAgICAgIDEgICAgICAgICAgICAw IC91c3Ivc3JjL3N5cy9kZXYvbWZpL21maS5jOjkxMiAoc2xlZXAgbXV0ZXg6TUZJIEkvTyBs b2NrKQogICAgIDQgICAgICAgICAgICA5ICAgICAgICAgICAgMCAgICAgICAgICAgMyAgICAg MyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFf Y29yZS5jOjQxNCAoc2xlZXAgbXV0ZXg6aW5wY2IpCiAgICAgOSAgICAgICAgICAyNzIgICAg ICAgICAgICAwICAgICAgICAgIDk5ICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAg ICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9kZXNjcmlwLmM6NDQxIChzbGVlcCBtdXRl eDpzbGVlcCBtdHhwb29sKQogICAgIDUgICAgICAgICAgIDU0ICAgICAgICAgICAgMCAgICAg ICAgICAxNiAgICAgMyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3Jj L3N5cy9hbWQ2NC9hbWQ2NC9pb19hcGljLmM6MjEyIChzcGluIG11dGV4OmljdSkKICAgICA1 ICAgICAgICAgICAxMSAgICAgICAgICAgIDAgICAgICAgICAgIDMgICAgIDMgICAgIDAgICAg ICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0MTQg KHNsZWVwIG11dGV4OlMgVkZTIENhY2hlKQogICAgIDQgICAgICAgICAgICA2ICAgICAgICAg ICAgMCAgICAgICAgICAgMiAgICAgMyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAw IC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19zdWJyLmM6MjIxMCAoc2xlZXAgbXV0ZXg6dm5vZGUg aW50ZXJsb2NrKQogICAgIDUgICAgICAgICAgMTgxICAgICAgICAgICAgMCAgICAgICAgICA3 MCAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9r ZXJuL2tlcm5fdGltZS5jOjYzMCAoc3BpbiBtdXRleDpwcm9jZXNzIHNsb2NrKQogICAgMzkg ICAgICAgIDEwMzg5ICAgICAgICAgIDM4MyAgICAgICAgMjkxNiAgICAgMyAgICAgMCAgICAg ICAgICAgMzMgICAgICAgICAgIDI1IC91c3Ivc3JjL3N5cy9rZXJuL3VpcGNfc29ja2V0LmM6 MTY3MCAoc2xlZXAgbXV0ZXg6c29fcmN2KQogICAgNjggICAgICAgICAgIDY4ICAgICAgICAg ICAgMCAgICAgICAgICAgMSAgICA2OCAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAw IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fcHJvdC5jOjEwMDggKHNsZWVwIG11dGV4OnByb2Nl c3MgbG9jaykKICAgIDI1ICAgICAgICAgIDE2NSAgICAgICAgICAgIDAgICAgICAgICAgMTAg ICAgMTYgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vy bi9rZXJuX2ZvcmsuYzo0NTcgKHNsZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAgIDE5ICAg ICAgICAgIDExMiAgICAgICAgICAgIDAgICAgICAgICAgMTAgICAgMTEgICAgIDAgICAgICAg ICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2ZvcmsuYzo0NTgg KHNsZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAgICA1ICAgICAgICAgICA2NyAgICAgICAg ICAgIDAgICAgICAgICAgMTYgICAgIDQgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAg MCAvdXNyL3NyYy9zeXMvYW1kNjQvYW1kNjQvaW9fYXBpYy5jOjIyOSAoc3BpbiBtdXRleDpp Y3UpCiAgICAxOCAgICAgICAgICAzMjkgICAgICAgICAgICAwICAgICAgICAgIDM2ICAgICA5 ICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vy bl9ldmVudC5jOjk5MyAoc2xlZXAgbXV0ZXg6c2xlZXAgbXR4cG9vbCkKICAgIDEyICAgICAg ICAgICAyOCAgICAgICAgICAgIDAgICAgICAgICAgIDggICAgIDMgICAgIDAgICAgICAgICAg ICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfc3Vici5jOjIyMzIgKHNs ZWVwIG11dGV4OnZub2RlIGludGVybG9jaykKICAgMTIyICAgICAgICAgMzc3MCAgICAgICAg ICAgIDAgICAgICAgICAyNzQgICAgMTMgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAg MCAvdXNyL3NyYy9zeXMvYW1kNjQvYW1kNjQvcG1hcC5jOjI3MzIgKHNsZWVwIG11dGV4OnZt IHBhZ2UgcXVldWUgbXV0ZXgpCiAgICAgMyAgICAgICAgICAgMTUgICAgICAgICAgICAwICAg ICAgICAgICA3ICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9z cmMvc3lzL2ZzL2RldmZzL2RldmZzX3Zub3BzLmM6ODAzIChzbGVlcCBtdXRleDpzbGVlcCBt dHhwb29sKQogICAgMTggICAgICAgICAgIDQxICAgICAgICAgICAgMCAgICAgICAgICAgMyAg ICAxMyAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJu L3VpcGNfc29ja2J1Zi5jOjM0MyAoc2xlZXAgbXV0ZXg6c29fcmN2KQogICAgMTIgICAgICAg ICAgMjA1ICAgICAgICAgICAgMCAgICAgICAgICA1NCAgICAgMyAgICAgMCAgICAgICAgICAg IDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZXZlbnQuYzoxNjY0IChz bGVlcCBtdXRleDpzb19yY3YpCiAgICAgNSAgICAgICAgICAgMTIgICAgICAgICAgICAwICAg ICAgICAgICAzICAgICA0ICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9z cmMvc3lzL3ZtL3VtYV9jb3JlLmM6NDE0IChzbGVlcCBtdXRleDoxMjggQnVja2V0KQogICAg MTIgICAgICAgICAgIDEyICAgICAgICAgICAgMCAgICAgICAgICAgMSAgICAxMiAgICAgMCAg ICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc192bm9wcy5j OjYxMyAobG9ja21ncjpkZXZmcykKICAxNTY3ICAgICAxMjkzNjc3MCAgICAgIDI2NjE3MDkg ICAgICAyMTUzOTAgICAgNjAgICAgMTIgICAgICAgICA0MzgzICAgICAgICAxNDE0MCAvdXNy L3NyYy9zeXMva2Vybi92ZnNfc3Vici5jOjIyNzcgKHNsZWVwIG11dGV4OnZub2RlIGludGVy bG9jaykKICAgMTk1ICAgICAgMTk2MTU5OCAgICAgMjA4NzkxNTkgICAgIDExNDY3NDggICAg IDEgICAgMTggICAgICAgIDYzNjMxICAgICAgIDk4ODI0MiAvdXNyL3NyYy9zeXMva2Vybi9z dWJyX3R1cm5zdGlsZS5jOjUzNiAoc3BpbiBtdXRleDp0dXJuc3RpbGUgY2hhaW4pCiAgICAg MyAgICAgICAgICAgMjUgICAgICAgICAgICAwICAgICAgICAgIDEwICAgICAyICAgICAwICAg ICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9mb3JrLmM6 NTU2IChzbGVlcCBtdXRleDpzZXNzaW9uKQogICAxMjUgICAgIDMwODg4MzE2ICAgIDE0MzQ5 OTM2OSAgICAgNDk2OTQyMSAgICAgNiAgICAyOCAgICAgIDQ4MjQxOTYgICAgICA0NTU3NDQy IC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfdHVybnN0aWxlLmM6NTQ2IChzcGluIG11dGV4OnR1 cm5zdGlsZSBjaGFpbikKICAgIDEyICAgICAgICAgIDY4OCAgICAgICAgICAgIDAgICAgICAg ICAyNDggICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9z eXMva2Vybi92ZnNfYmlvLmM6MTM1MyAoc2xlZXAgbXV0ZXg6YnVmIHF1ZXVlIGxvY2spCiAg ICAgMyAgICAgICAgICAgIDkgICAgICAgICAgICAwICAgICAgICAgICA0ICAgICAyICAgICAw ICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9wcm9j LmM6MjYzIChzbGVlcCBtdXRleDpwcm9jZXNzIGdyb3VwKQogICAgMjEgICAgICAgICAgMzY0 ICAgICAgICAgICAgMCAgICAgICAgICAzNCAgICAxMCAgICAgMCAgICAgICAgICAgIDAgICAg ICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19jYWNoZS5jOjQ0NCAobG9ja21ncjp1 ZnMpCiAgICAyMSAgICAgICAgICAgMjEgICAgICAgICAgICAwICAgICAgICAgICAxICAgIDIx ICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vy bl9wcm90LmM6MTA4NSAoc2xlZXAgbXV0ZXg6cHJvY2VzcyBsb2NrKQogICAgMjIgICAgICAg ICAgMzIzICAgICAgICAgICAgMCAgICAgICAgICAzNiAgICAgOCAgICAgMCAgICAgICAgICAg IDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3VpcGNfc3lzY2FsbHMuYzozNzEg KHNsZWVwIG11dGV4OmFjY2VwdCkKICAgIDM2ICAgICAgICAgIDI1MyAgICAgICAgICAgIDAg ICAgICAgICAgMTAgICAgMjUgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNy L3NyYy9zeXMva2Vybi9rZXJuX2ZvcmsuYzo1NDcgKHNsZWVwIG11dGV4OnByb2Nlc3MgbG9j aykKICAgIDIyICAgICAgICAgIDE2MiAgICAgICAgICAgIDAgICAgICAgICAgMTAgICAgMTYg ICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJu X2ZvcmsuYzo1NDggKHNsZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAgICAyICAgICAgICAg ICAgNSAgICAgICAgICAgIDAgICAgICAgICAgIDIgICAgIDIgICAgIDAgICAgICAgICAgICAw ICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi91aXBjX3N5c2NhbGxzLmM6NjQzIChz bGVlcCBtdXRleDpzbGVlcCBtdHhwb29sKQogICAgIDIgICAgICAgICAgICA0ICAgICAgICAg ICAgMCAgICAgICAgICAgMiAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAw IC91c3Ivc3JjL3N5cy9rZXJuL3VpcGNfc3lzY2FsbHMuYzo2NDggKHNsZWVwIG11dGV4OnNs ZWVwIG10eHBvb2wpCiAgICAgMSAgICAgICAgICAgIDMgICAgICAgICAgICAwICAgICAgICAg ICAyICAgICAxICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lz L2tlcm4va2Vybl9wcm9jLmM6MzA4IChzbGVlcCBtdXRleDpwcm9jZXNzIGdyb3VwKQogICAg IDQgICAgICAgICAgIDI0ICAgICAgICAgICAgMCAgICAgICAgICAxMCAgICAgMiAgICAgMCAg ICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZm9yay5j OjU3NCAoc2xlZXAgbXV0ZXg6a3RyYWNlKQogICAgIDMgICAgICAgICAgICA4ICAgICAgICAg ICAgMCAgICAgICAgICAgMyAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAw IC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQxNCAoc2xlZXAgbXV0ZXg6RkZTIGlub2Rl KQogICAgIDggICAgICAgICAgIDQ2ICAgICAgICAgICAgMCAgICAgICAgICAxNiAgICAgMiAg ICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19i aW8uYzozNDAgKHNsZWVwIG11dGV4OnJ1bm5pbmdidWZzcGFjZSBsb2NrKQogICAgIDMgICAg ICAgICAgICA2ICAgICAgICAgICAgMCAgICAgICAgICAgMiAgICAgMyAgICAgMCAgICAgICAg ICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fcHJvYy5jOjMyNSAo c2xlZXAgbXV0ZXg6cHJvY2VzcyBncm91cCkKICAgICAyICAgICAgICAgICAgNSAgICAgICAg ICAgIDAgICAgICAgICAgIDMgICAgIDEgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAg MCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0MTQgKHNsZWVwIG11dGV4Om1idWZfanVt Ym9fOWspCiAgICAxNSAgICAgICAgIDU2MzggICAgICAgICAgICAwICAgICAgICAyMDIwICAg ICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4v dWlwY19zb2NrZXQuYzoxODI2IChzbGVlcCBtdXRleDpzb19yY3YpCiAgMTgzNyAgICAgICA0 OTg5MjAgICAgICAgICAgIDU4ICAgICAgIDQ3MTkyICAgIDEwICAgICAwICAgICAgICAgICAg MyAgICAgICAgICAgIDIgL3Vzci9zcmMvc3lzL3ZtL3ZtX2ZhdWx0LmM6MjkzIChzbGVlcCBt dXRleDp2bSBvYmplY3QpCiAgICAgNSAgICAgICAgICAgMzEgICAgICAgICAgICAwICAgICAg ICAgICA5ICAgICAzICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMv c3lzL2tlcm4va2Vybl9tdXRleC5jOjE0MSAoc2xlZXAgbXV0ZXg6cGlwZSBtdXRleCkKICAz ODA1ICAgICAgNjUwMTY3MiAgICAgICAzNTQwMTQgICAgICAgNjM0MTEgICAxMDIgICAgIDUg ICAgICAgICAxMTI5ICAgICAgICAgMTE0NyAvdXNyL3NyYy9zeXMva2Vybi92ZnNfaGFzaC5j OjcxIChzbGVlcCBtdXRleDp2ZnMgaGFzaCkKICAgIDMxICAgICAgICAgMTY0MiAgICAgICAg ICAgIDAgICAgICAgICAyMTkgICAgIDcgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAg MCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfYmlvLmM6MTQ2OCAoc2xlZXAgbXV0ZXg6YnVmIHF1 ZXVlIGxvY2spCiAgICAgNCAgICAgICAgICAgIDkgICAgICAgICAgICAwICAgICAgICAgICAz ICAgICAzICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL3Zt L3VtYV9jb3JlLmM6NDE0IChzbGVlcCBtdXRleDp1ZHBjYikKICAgICA1ICAgICAgICAgICA0 MyAgICAgICAgICAgIDAgICAgICAgICAgMTggICAgIDIgICAgIDAgICAgICAgICAgICAwICAg ICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3Byb3QuYzoxMjAzIChzbGVlcCBt dXRleDpwcm9jZXNzIGxvY2spCiAgICA3MCAgICAgICAgIDEyNDIgICAgICAgICAgMTM4ICAg ICAgICAgIDQ3ICAgIDI2ICAgICAyICAgICAgICAgICAgMCAgICAgICAgICAgIDUgL3Vzci9z cmMvc3lzL25ldGluZXQvdGNwX3VzcnJlcS5jOjk1NSAoc2xlZXAgbXV0ZXg6dGNwKQogICAg MjIgICAgICAgICAgIDYyICAgICAgICAgICAgMCAgICAgICAgICAgNCAgICAxNSAgICAgMCAg ICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fcHJvYy5j OjM5OSAoc2xlZXAgbXV0ZXg6cHJvY2VzcyBncm91cCkKICAgIDEyICAgICAgICAgICAzNyAg ICAgICAgICAgIDAgICAgICAgICAgIDQgICAgIDkgICAgIDAgICAgICAgICAgICAwICAgICAg ICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3Byb2MuYzo0MDAgKHNsZWVwIG11dGV4 OnByb2Nlc3MgZ3JvdXApCiAgICAgMyAgICAgICAgICAgNDIgICAgICAgICAgICAwICAgICAg ICAgIDIxICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMv c3lzL2tlcm4va2Vybl9kZXNjcmlwLmM6Njc2IChzbGVlcCBtdXRleDpzbGVlcCBtdHhwb29s KQogICAgIDQgICAgICAgICAgICA5ICAgICAgICAgICAgMCAgICAgICAgICAgMyAgICAgMyAg ICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3VpcGNf c29ja2V0LmM6MTg4OCAoc2xlZXAgbXV0ZXg6c29fcmN2KQogICAgIDUgICAgICAgICAgIDY5 ICAgICAgICAgICAgMCAgICAgICAgICAyOCAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAg ICAgICAgICAwIC91c3Ivc3JjL3N5cy92bS92bV9vYmplY3QuYzoxNzIwIChzbGVlcCBtdXRl eDp2bSBvYmplY3RfbGlzdCkKICAgICA0ICAgICAgICAgICAyNSAgICAgICAgICAgIDAgICAg ICAgICAgMTAgICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3Ny Yy9zeXMva2Vybi9rZXJuX2ZvcmsuYzo2NzYgKHNsZWVwIG11dGV4OnByb2Nlc3MgbG9jaykK ICAgICA1ICAgICAgICAgICAxMCAgICAgICAgICAgIDAgICAgICAgICAgIDMgICAgIDMgICAg IDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi91aXBjX3Nv Y2tldC5jOjE4OTUgKHNsZWVwIG11dGV4OnNvX3JjdikKICAgICA1ICAgICAgICAgICAyMCAg ICAgICAgICAgIDAgICAgICAgICAgIDcgICAgIDIgICAgIDAgICAgICAgICAgICAwICAgICAg ICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi91aXBjX3VzcnJlcS5jOjM2NSAocnc6dW5wX2ds b2JhbF9yd2xvY2spCiAgICAgNSAgICAgICAgICAgNzcgICAgICAgICAgICAwICAgICAgICAg IDMzICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lz L2tlcm4va2Vybl9kZXNjcmlwLmM6NDA5IChzeDpmaWxlZGVzYyBzdHJ1Y3R1cmUpCiAgICAx MSAgICAgICAgICAgODEgICAgICAgICAgICAwICAgICAgICAgIDEwICAgICA4ICAgICAwICAg ICAgICAgICAgMCAgICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9wcm9jLmM6 NDI1IChzbGVlcCBtdXRleDpwcm9jZXNzIGdyb3VwKQogICA0MTggICAgICAgICAzMTk5ICAg ICAgICAgICA2MyAgICAgICAgICAxNSAgIDIxMyAgICAgNCAgICAgICAgICAgIDUgICAgICAg ICAgICAyIC91c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC9wbWFwLmM6Mjk0OSAoc2xlZXAgbXV0 ZXg6dm0gcGFnZSBxdWV1ZSBtdXRleCkKICAgICA5ICAgICAgICAgICAzMiAgICAgICAgICAg IDAgICAgICAgICAgMTAgICAgIDMgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAv dXNyL3NyYy9zeXMva2Vybi9rZXJuX2ZvcmsuYzo2OTEgKHNsZWVwIG11dGV4OnByb2Nlc3Mg bG9jaykKICAgIDUxICAgICAgICAgIDY0NCAgICAgICAgICAgIDAgICAgICAgICAgMTYgICAg NDAgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvbmV0aW5l dC91ZHBfdXNycmVxLmM6NTQ5IChzbGVlcCBtdXRleDppbnApCiAgICAgOSAgICAgICAgICAg MjkgICAgICAgICAgICAwICAgICAgICAgICA0ICAgICA3ICAgICAwICAgICAgICAgICAgMCAg ICAgICAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9wcm9jLmM6NDU3IChzbGVlcCBt dXRleDpwcm9jZXNzIGdyb3VwKQogIDIzODAgICAgICA0MDc5ODM5ICAgICAgMzc1NDk5NCAg ICAgICA2NTY1OCAgICA2MiAgICA1NyAgICAgICAgIDE5OTcgICAgICAgICAyNzg0IC91c3Iv c3JjL3N5cy9rZXJuL3Zmc19sb29rdXAuYzo0MTEgKGxvY2ttZ3I6dWZzKQogICAgIDUgICAg ICAgICAgIDE2ICAgICAgICAgICAgMCAgICAgICAgICAgNCAgICAgNCAgICAgMCAgICAgICAg ICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fcHJvYy5jOjQ3NiAo c2xlZXAgbXV0ZXg6cHJvY2VzcyBncm91cCkKICAgICA5ICAgICAgICAgICA1OCAgICAgICAg ICAgIDAgICAgICAgICAgMTAgICAgIDUgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAg MCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2V4aXQuYzoyOTcgKHN4OnByb2N0cmVlKQogICAg MTMgICAgICAgICAgMTEyICAgICAgICAgICAgMCAgICAgICAgICAxNyAgICAgNiAgICAgMCAg ICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9uZXRpbmV0L3VkcF91c3Jy ZXEuYzoxMDE0IChzbGVlcCBtdXRleDp1ZHApCiAgICAxMSAgICAgICAgICA0ODEgICAgICAg ICAgICAwICAgICAgICAgMTc5ICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAg IDAgL3Vzci9zcmMvc3lzL3ZtL3ZtX29iamVjdC5jOjEyMTQgKHNsZWVwIG11dGV4OnZtIG9i amVjdCkKICAgICAyICAgICAgICAgICAgNSAgICAgICAgICAgIDAgICAgICAgICAgIDMgICAg IDEgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1h X2NvcmUuYzo0MTQgKHNsZWVwIG11dGV4OjQwOTYpCiAgICAgNiAgICAgICAgICAgOTUgICAg ICAgICAgMTU2ICAgICAgICAgIDM1ICAgICAyICAgICA0ICAgICAgICAgICAxNSAgICAgICAg ICAgMTcgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9yZXNvdXJjZS5jOjEwNDEgKHNwaW4gbXV0 ZXg6c2NoZWQgbG9jaykKICAgICA1ICAgICAgICAgICA1MSAgICAgICAgICAgIDAgICAgICAg ICAgMTYgICAgIDMgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9z eXMva2Vybi91aXBjX3NvY2tldC5jOjk2MSAoc2xlZXAgbXV0ZXg6c29fc25kKQogICAgIDQg ICAgICAgICAgIDExICAgICAgICAgICAgMCAgICAgICAgICAgMyAgICAgMyAgICAgMCAgICAg ICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQxNCAo c2xlZXAgbXV0ZXg6MTAyNCkKICAgIDM4ICAgICAgICAgIDUwMCAgICAgICAgICAgIDAgICAg ICAgICAgMzUgICAgMTQgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3Ny Yy9zeXMva2Vybi9rZXJuX3Jlc291cmNlLmM6MTA1OSAoc3BpbiBtdXRleDpwcm9jZXNzIHNs b2NrKQogICAgIDYgICAgICAgICAgMzU4ICAgICAgICAgICAgMCAgICAgICAgIDEyMCAgICAg MiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9uZXRpbmV0 L2lwX2lucHV0LmM6MTA4NiAoc2xlZXAgbXV0ZXg6aXBxbG9jaykKICAgMjI5ICAgICAgICAg MjEyNiAgICAgICAgICAgIDAgICAgICAgICA1MjMgICAgIDQgICAgIDAgICAgICAgICAgICAw ICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMvbmV0aW5ldC9pbl9wY2IuYzoyMTcgKHNsZWVw IG11dGV4OmlucCkKICAgIDI1ICAgICAgICAgMjU1NSAgICAgICAgICAgIDAgICAgICAgICA0 NDkgICAgIDUgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMv a2Vybi92ZnNfYmlvLmM6MjQ2MCAoc2xlZXAgbXV0ZXg6dm5vZGUgaW50ZXJsb2NrKQogICAg MTUgICAgICAgICAgMTUwICAgICAgICAgICAgMCAgICAgICAgICAxNyAgICAgOCAgICAgMCAg ICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9uZXRpbmV0L3VkcF91c3Jy ZXEuYzoxMDUyIChzbGVlcCBtdXRleDp1ZHApCiAgICAgOCAgICAgICAgICA0MjYgICAgICAg ICAgICAwICAgICAgICAgMTU3ICAgICAyICAgICAwICAgICAgICAgICAgMCAgICAgICAgICAg IDAgL3Vzci9zcmMvc3lzL3ZtL3ZtX29iamVjdC5jOjEyNDcgKHNsZWVwIG11dGV4OnZtIG9i amVjdCkKICAgIDMwICAgICAgICAgIDU0MCAgICAgICAgICAgIDAgICAgICAgICAgNjAgICAg IDkgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9r ZXJuX211dGV4LmM6MTQxIChzbGVlcCBtdXRleDpTeW5jZXIgbXR4KQogICAgIDUgICAgICAg ICAgIDEyICAgICAgICAgICAgMCAgICAgICAgICAgMyAgICAgNCAgICAgMCAgICAgICAgICAg IDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQxNCAoc2xlZXAg bXV0ZXg6MTI4KQogICAgIDUgICAgICAgICAgIDEwICAgICAgICAgICAgMCAgICAgICAgICAg NCAgICAgMiAgICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9r ZXJuL3VpcGNfc29ja2V0LmM6MjAxNiAoc2xlZXAgbXV0ZXg6c29fcmN2KQogICAgIDIgICAg ICAgICAgIDE1ICAgICAgICAgICAgMCAgICAgICAgICAgNyAgICAgMiAgICAgMCAgICAgICAg ICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3VpcGNfdXNycmVxLmM6NDk4 IChydzp1bnBfZ2xvYmFsX3J3bG9jaykKICAgIDg4ICAgICAgICAgMTA2OCAgICAgICAgICAg IDAgICAgICAgICAgMTYgICAgNjYgICAgIDAgICAgICAgICAgICAwICAgICAgICAgICAgMCAv dXNyL3NyYy9zeXMvbmV0aW5ldC91ZHBfdXNycmVxLmM6MTA3MiAoc2xlZXAgbXV0ZXg6dWRw KQogICAgIDYgICAgICAgICAgIDQ1ICAgICAgICAgICAgMCAgICAgICAgICAxMyAgICAgMyAg ICAgMCAgICAgICAgICAgIDAgICAgICAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19i aW8uYzozMjEzIChzbGVlcCBtdXRleDp2bSBvYmplY3QpCgo= --------------070007040800000700060905-- From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 08:41:58 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 200AE16A41A; Tue, 20 Nov 2007 08:41:58 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from hermes.hw.ru (hermes.hw.ru [80.68.240.91]) by mx1.freebsd.org (Postfix) with ESMTP id 2D92C13C465; Tue, 20 Nov 2007 08:41:56 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from [80.68.244.40] (account a_popov@rbc.ru [80.68.244.40] verified) by hermes.hw.ru (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 201460951; Tue, 20 Nov 2007 11:41:37 +0300 Message-ID: <47429DB8.7040504@chistydom.ru> Date: Tue, 20 Nov 2007 11:41:28 +0300 From: Alexey Popov User-Agent: Thunderbird 2.0.0.6 (X11/20070924) MIME-Version: 1.0 To: Kris Kennaway References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> <4741A7DA.2050706@chistydom.ru> <4741DA15.9000308@FreeBSD.org> In-Reply-To: <4741DA15.9000308@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Ivan Voras Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 08:41:58 -0000 Hi. Kris Kennaway wrote: >>>> CPU states: 9.5% user, 0.0% nice, 82.0% system, 0.5% interrupt, >>>> 8.0% idle >>> A wild idea that might not help: try reducing kern.hz in loader.conf to >>> something like 100 and see if something significant changes. >> Now it runs with hz=100, number of context switches became ~ 2 times >> less, but still there's 90% system CPU load (see attach). > > System CPU usage doesn't tell you anything by itself, you need to look > at how much work the system is actually doing (pages served/second, or > whatever). For example, when your kernel is getting more work done, > system CPU usage will also be higher. Usually on PHP backends slow PHP code eats most of the CPU time. I have %user much bigger than %system in CPU states. But now %system is much bigger than %user and I can conclude that on 8-core server FreeBSD consumes more CPU time than PHP. With best regards, Alexey Popov From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 09:09:39 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAEB016A419 for ; Tue, 20 Nov 2007 09:09:39 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 94A8913C448 for ; Tue, 20 Nov 2007 09:09:39 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: by blah.sun-fish.com (Postfix, from userid 1002) id 213751B10F09; Tue, 20 Nov 2007 10:09:38 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on blah.cmotd.com X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 Received: from hater.haters.org (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id 315F51B10F14 for ; Tue, 20 Nov 2007 10:09:34 +0100 (CET) Message-ID: <4742A44D.8080402@moneybookers.com> Date: Tue, 20 Nov 2007 11:09:33 +0200 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.6 (X11/20071105) MIME-Version: 1.0 To: FreeBSD Stable Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4853/Tue Nov 20 04:05:00 2007 on blah.cmotd.com X-Virus-Status: Clean Subject: Weird issue with DELL PE2850 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 09:09:39 -0000 Hi, I'm experiencing strange problem with PE2850 - CPU: Intel(R) Xeon(TM) CPU 3.20GHz (3192.23-MHz K8-class CPU) It's a dual processor (with HT) server and worked very well with freebsd 6.2, before few days I updated one of ours pe2850 to see how will 6.3 perform, and the first think that I notice is a freeze for few minutes during boot. Everything is ok till the following lines are displayed: SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! 2-5min freeze Trying to mount root from ufs:/dev/amrd0s1a ... I saw the same thing on other pe2850 with 7-BETA2, and I'm pretty sure that both servers didn't have such problems with earlier versions of 7-current and 6.2-stable. I'm running amd64 on both servers. on 6.3 hyperthreading is disabled and on 7b2 is enabled. I have CPUTYPE?=nocona in /etc/make.conf Any ideas where to dig and how to debug? Can someone else confirm this? I'm sure pe2850 is/was very popular server ;) -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 09:50:51 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7781C16A469; Tue, 20 Nov 2007 09:50:51 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id 7761613C4AC; Tue, 20 Nov 2007 09:50:50 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <4742ADFE.40902@FreeBSD.org> Date: Tue, 20 Nov 2007 10:50:54 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Alexey Popov References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> <4741A7DA.2050706@chistydom.ru> <4741DA15.9000308@FreeBSD.org> <47429DB8.7040504@chistydom.ru> In-Reply-To: <47429DB8.7040504@chistydom.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Ivan Voras Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 09:50:51 -0000 Alexey Popov wrote: > Hi. > > Kris Kennaway wrote: >>>>> CPU states: 9.5% user, 0.0% nice, 82.0% system, 0.5% interrupt, >>>>> 8.0% idle >>>> A wild idea that might not help: try reducing kern.hz in loader.conf to >>>> something like 100 and see if something significant changes. >>> Now it runs with hz=100, number of context switches became ~ 2 times >>> less, but still there's 90% system CPU load (see attach). >> >> System CPU usage doesn't tell you anything by itself, you need to look >> at how much work the system is actually doing (pages served/second, or >> whatever). For example, when your kernel is getting more work done, >> system CPU usage will also be higher. > Usually on PHP backends slow PHP code eats most of the CPU time. I have > %user much bigger than %system in CPU states. > > But now %system is much bigger than %user and I can conclude that on > 8-core server FreeBSD consumes more CPU time than PHP. That is one possibility, but you still need to look at the actual throughput on these machines before making conclusions about which is performing better. Can you please provide those numbers for 6.x, 7.x with ULE and 4BSD on the 4-core and 8-core systems? Kris From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 09:50:52 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05BB516A46C; Tue, 20 Nov 2007 09:50:52 +0000 (UTC) (envelope-from w@wrzask.pl) Received: from mx.oak.pl (mx.oak.pl [217.96.108.251]) by mx1.freebsd.org (Postfix) with ESMTP id B50C113C4BE; Tue, 20 Nov 2007 09:50:51 +0000 (UTC) (envelope-from w@wrzask.pl) Received: by oak.pl (Postfix, from userid 1002) id C1DAE1CCCC; Tue, 20 Nov 2007 10:50:41 +0100 (CET) Date: Tue, 20 Nov 2007 10:50:41 +0100 From: Jan Srzednicki To: Daniel Hartmeier Message-ID: <20071120095041.GJ2045@oak.pl> References: <20071119202142.GI2045@oak.pl> <20071120065334.GJ29432@insomnia.benzedrine.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071120065334.GJ29432@insomnia.benzedrine.cx> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-stable@freebsd.org, freebsd-pf@freebsd.org Subject: Re: pf(4) using inapropriate timeout values, 6.2-R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 09:50:52 -0000 On Tue, Nov 20, 2007 at 07:53:34AM +0100, Daniel Hartmeier wrote: > On Mon, Nov 19, 2007 at 09:21:42PM +0100, Jan Srzednicki wrote: > > > I'm positively sure it's precisely this value that timeouts this > > conection (which later on get state mismatches). > > What does pfctl -vvss show for such a state entry, in particular the > right-most part of the first line ("ESTABLISHED:ESTABLISHED" while the > connection is still fully established, etc.)? OK, here it comes. This is the connection before sending the one-side FIN: self tcp MY_IP_HERE:12525 <- MY_IP_HERE:64829 ESTABLISHED:ESTABLISHED [390096685 + 66608] wscale 1 [3173293905 + 65537] wscale 1 age 00:00:00, expires in 24:00:00, 2:1 pkts, 116:64 bytes, rule 30 id: 47207d980002e600 creatorid: 082298e6 self tcp MY_IP_HERE:64829 -> MY_IP_HERE:12525 ESTABLISHED:ESTABLISHED [3173293905 + 65537] wscale 1 [390096685 + 66608] wscale 1 age 00:00:00, expires in 24:00:00, 2:1 pkts, 116:64 bytes, rule 30 id: 47207d980002e5ff creatorid: 082298e6 (they're both on the same host) Now the client sends FIN: 10:39:30.008969 IP MY_IP_HERE.64829 > MY_IP_HERE.12525: F 222:222(0) ack 1 win 33304 10:39:30.009008 IP MY_IP_HERE.12525 > MY_IP_HERE.64829: . ack 223 win 33304 And the state becomes: self tcp MY_IP_HERE:12525 <- MY_IP_HERE:64829 ESTABLISHED:FIN_WAIT_2 [390096685 + 66608] wscale 1 [3173294128 + 66608] wscale 1 age 00:00:04, expires in 00:00:05, 4:3 pkts, 441:168 bytes, rule 30 id: 47207d980002e600 creatorid: 082298e6 self tcp MY_IP_HERE:64829 -> MY_IP_HERE:12525 FIN_WAIT_2:ESTABLISHED [3173294128 + 66608] wscale 1 [390096685 + 66608] wscale 1 age 00:00:04, expires in 00:00:05, 4:3 pkts, 441:168 bytes, rule 30 id: 47207d980002e5ff creatorid: 082298e6 Timeout values: # pfctl -s timeout No ALTQ support in kernel ALTQ related functions disabled tcp.first 120s tcp.opening 30s tcp.established 86400s tcp.closing 900s tcp.finwait 5s tcp.closed 10s tcp.tsdiff 30s udp.first 60s udp.single 30s udp.multiple 60s icmp.first 20s icmp.error 10s other.first 60s other.single 30s other.multiple 60s frag 30s interval 10s adaptive.start 0 states adaptive.end 0 states src.track 0s > Does it matter which side of the connection (the client or the server) > half-closes the connection? Nope, this happens on both sides. > It's possible that there's a bug in mapping the timeout, I'll check. Thx. -- Jan Srzednicki :: http://wrzask.pl/ "Remember, remember, the fifth of November" -- V for Vendetta From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 10:20:59 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C67116A418; Tue, 20 Nov 2007 10:20:59 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [IPv6:2001:6f8:1098::2]) by mx1.freebsd.org (Postfix) with ESMTP id D2E9413C455; Tue, 20 Nov 2007 10:20:57 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id lAKAKunG009271 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 20 Nov 2007 11:20:56 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id lAKAKuF6004999; Tue, 20 Nov 2007 11:20:56 +0100 (MET) Date: Tue, 20 Nov 2007 11:20:56 +0100 From: Daniel Hartmeier To: Jan Srzednicki Message-ID: <20071120102056.GK29432@insomnia.benzedrine.cx> References: <20071119202142.GI2045@oak.pl> <20071120065334.GJ29432@insomnia.benzedrine.cx> <20071120095041.GJ2045@oak.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071120095041.GJ2045@oak.pl> User-Agent: Mutt/1.5.12-2006-07-14 Cc: freebsd-stable@freebsd.org, freebsd-pf@freebsd.org Subject: Re: pf(4) using inapropriate timeout values, 6.2-R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 10:20:59 -0000 On Tue, Nov 20, 2007 at 10:50:41AM +0100, Jan Srzednicki wrote: > And the state becomes: > > self tcp MY_IP_HERE:12525 <- MY_IP_HERE:64829 ESTABLISHED:FIN_WAIT_2 > [390096685 + 66608] wscale 1 [3173294128 + 66608] wscale 1 > age 00:00:04, expires in 00:00:05, 4:3 pkts, 441:168 bytes, rule 30 > id: 47207d980002e600 creatorid: 082298e6 > self tcp MY_IP_HERE:64829 -> MY_IP_HERE:12525 FIN_WAIT_2:ESTABLISHED > [3173294128 + 66608] wscale 1 [390096685 + 66608] wscale 1 > age 00:00:04, expires in 00:00:05, 4:3 pkts, 441:168 bytes, rule 30 > id: 47207d980002e5ff creatorid: 082298e6 That's fine so far, ESTABLISHED:FIN_WAIT_2 is correct in this case. Look at your /usr/src/sys/contrib/pf/net/pf.c, in pf_test_state_tcp() there's a section like /* update expire time */ (*state)->expire = time_second; if (src->state >= TCPS_FIN_WAIT_2 && dst->state >= TCPS_FIN_WAIT_2) (*state)->timeout = PFTM_TCP_CLOSED; else if (src->state >= TCPS_CLOSING && dst->state >= TCPS_CLOSING) (*state)->timeout = PFTM_TCP_FIN_WAIT; else if (src->state < TCPS_ESTABLISHED || dst->state < TCPS_ESTABLISHED) (*state)->timeout = PFTM_TCP_OPENING; else if (src->state >= TCPS_CLOSING || dst->state >= TCPS_CLOSING) (*state)->timeout = PFTM_TCP_CLOSING; else (*state)->timeout = PFTM_TCP_ESTABLISHED; In 6.2-release this was, according to http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/contrib/pf/net/pf.c?rev=1.34.2.4;content-type=text%2Fplain /* update expire time */ (*state)->expire = time_second; if (src->state >= TCPS_FIN_WAIT_2 && dst->state >= TCPS_FIN_WAIT_2) (*state)->timeout = PFTM_TCP_CLOSED; else if (src->state >= TCPS_FIN_WAIT_2 || dst->state >= TCPS_FIN_WAIT_2) (*state)->timeout = PFTM_TCP_FIN_WAIT; else if (src->state < TCPS_ESTABLISHED || dst->state < TCPS_ESTABLISHED) (*state)->timeout = PFTM_TCP_OPENING; else if (src->state >= TCPS_CLOSING || dst->state >= TCPS_CLOSING) (*state)->timeout = PFTM_TCP_CLOSING; else (*state)->timeout = PFTM_TCP_ESTABLISHED; Note the slight difference, which explains your observations. It looks like this change was never backported/merged to RELENG_6. Try the newer (first) version, it should resolve your problem. Daniel From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 10:25:21 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CC7416A41A; Tue, 20 Nov 2007 10:25:21 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [IPv6:2001:6f8:1098::2]) by mx1.freebsd.org (Postfix) with ESMTP id A3CA813C4C4; Tue, 20 Nov 2007 10:25:20 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id lAKAPKF6027516 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 20 Nov 2007 11:25:20 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id lAKAPKAC006000; Tue, 20 Nov 2007 11:25:20 +0100 (MET) Date: Tue, 20 Nov 2007 11:25:20 +0100 From: Daniel Hartmeier To: Jan Srzednicki Message-ID: <20071120102520.GL29432@insomnia.benzedrine.cx> References: <20071119202142.GI2045@oak.pl> <20071120065334.GJ29432@insomnia.benzedrine.cx> <20071120095041.GJ2045@oak.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071120095041.GJ2045@oak.pl> User-Agent: Mutt/1.5.12-2006-07-14 Cc: freebsd-stable@freebsd.org, freebsd-pf@freebsd.org Subject: Re: pf(4) using inapropriate timeout values, 6.2-R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 10:25:21 -0000 The specific change in the OpenBSD tree was Revision 1.494 Mon Jul 4 08:28:04 2005 UTC (2 years, 4 months ago) by markus Branch: MAIN Changes since 1.493: +3 -3 lines restrict the tcp.finwait timeout (45s) to state combinations where we have seen a FIN from both sides (whether ACKed or not) and use tcp.closing (900s) for half closed connections. otherwise half closed connections will time out within 45s. ok dhartmei, henning. http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf.c.diff?r1=1.493&r2=1.494&f=h Index: pf.c =================================================================== RCS file: /cvs/src/sys/net/pf.c,v retrieving revision 1.493 retrieving revision 1.494 diff -u -r1.493 -r1.494 --- pf.c 13 Jun 2005 20:17:25 -0000 1.493 +++ pf.c 4 Jul 2005 08:28:04 -0000 1.494 @@ -4273,8 +4273,8 @@ if (src->state >= TCPS_FIN_WAIT_2 && dst->state >= TCPS_FIN_WAIT_2) (*state)->timeout = PFTM_TCP_CLOSED; - else if (src->state >= TCPS_FIN_WAIT_2 || - dst->state >= TCPS_FIN_WAIT_2) + else if (src->state >= TCPS_CLOSING && + dst->state >= TCPS_CLOSING) (*state)->timeout = PFTM_TCP_FIN_WAIT; else if (src->state < TCPS_ESTABLISHED || dst->state < TCPS_ESTABLISHED) Daniel From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 10:50:43 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02B5B16A468; Tue, 20 Nov 2007 10:50:43 +0000 (UTC) (envelope-from w@wrzask.pl) Received: from mx.oak.pl (mx.oak.pl [217.96.108.251]) by mx1.freebsd.org (Postfix) with ESMTP id 4461113C46A; Tue, 20 Nov 2007 10:50:41 +0000 (UTC) (envelope-from w@wrzask.pl) Received: by oak.pl (Postfix, from userid 1002) id 3BFDF1CD3A; Tue, 20 Nov 2007 11:50:32 +0100 (CET) Date: Tue, 20 Nov 2007 11:50:32 +0100 From: Jan Srzednicki To: Daniel Hartmeier Message-ID: <20071120105032.GK2045@oak.pl> References: <20071119202142.GI2045@oak.pl> <20071120065334.GJ29432@insomnia.benzedrine.cx> <20071120095041.GJ2045@oak.pl> <20071120102056.GK29432@insomnia.benzedrine.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071120102056.GK29432@insomnia.benzedrine.cx> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-stable@freebsd.org, freebsd-pf@freebsd.org Subject: Re: pf(4) using inapropriate timeout values, 6.2-R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 10:50:43 -0000 On Tue, Nov 20, 2007 at 11:20:56AM +0100, Daniel Hartmeier wrote: > On Tue, Nov 20, 2007 at 10:50:41AM +0100, Jan Srzednicki wrote: > > Note the slight difference, which explains your observations. > > It looks like this change was never backported/merged to RELENG_6. > > Try the newer (first) version, it should resolve your problem. Yeah, that solves the thing, thanks. Shoul I submit a PR to get that fix merged into RELENG_6? It seems worth fixing before 6.3-RELEASE is out. -- Jan Srzednicki :: http://wrzask.pl/ "Remember, remember, the fifth of November" -- V for Vendetta From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 10:59:50 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D565716A419 for ; Tue, 20 Nov 2007 10:59:50 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smtp-out0.tiscali.nl (smtp-out0.tiscali.nl [195.241.79.175]) by mx1.freebsd.org (Postfix) with ESMTP id 9F7F213C468 for ; Tue, 20 Nov 2007 10:59:50 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from [195.241.149.28] (helo=guido.klop.ws) by smtp-out0.tiscali.nl with smtp (Tiscali http://www.tiscali.nl) id 1IuQpN-0006mM-Iw for ; Tue, 20 Nov 2007 11:59:37 +0100 Received: (qmail 7187 invoked from network); 20 Nov 2007 10:59:34 -0000 Received: from localhost (HELO guido.klop.ws) (127.0.0.1) by localhost with SMTP; 20 Nov 2007 10:59:34 -0000 To: "FreeBSD Stable" From: "Ronald Klop" Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 References: <4742A44D.8080402@moneybookers.com> Content-Transfer-Encoding: Quoted-Printable Date: Tue, 20 Nov 2007 11:59:32 +0100 Message-ID: In-Reply-To: <4742A44D.8080402@moneybookers.com> User-Agent: Opera Mail/9.24 (FreeBSD) Subject: Re: Weird issue with DELL PE2850 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 10:59:50 -0000 On Tue, 20 Nov 2007 10:09:33 +0100, Stefan Lambrev = wrote: > Hi, > > I'm experiencing strange problem with PE2850 - CPU: Intel(R) Xeon(TM) = = > CPU 3.20GHz (3192.23-MHz K8-class CPU) > It's a dual processor (with HT) server and worked very well with freeb= sd = > 6.2, > before few days I updated one of ours pe2850 to see how will 6.3 = > perform, and the first think that I notice > is a freeze for few minutes during boot. > > Everything is ok till the following lines are displayed: > SMP: AP CPU #1 Launched! > SMP: AP CPU #2 Launched! > SMP: AP CPU #3 Launched! > 2-5min freeze > Trying to mount root from ufs:/dev/amrd0s1a > ... > I saw the same thing on other pe2850 with 7-BETA2, and I'm pretty sure= = > that both servers > didn't have such problems with earlier versions of 7-current and = > 6.2-stable. > > I'm running amd64 on both servers. > on 6.3 hyperthreading is disabled and on 7b2 is enabled. > I have CPUTYPE?=3Dnocona in /etc/make.conf > > Any ideas where to dig and how to debug? > Can someone else confirm this? > I'm sure pe2850 is/was very popular server ;) > Did you boot with verbose messages on? Ronald. -- = Ronald Klop Amsterdam, The Netherlands From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 11:27:20 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 672E216A417; Tue, 20 Nov 2007 11:27:20 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from hermes.hw.ru (hermes.hw.ru [80.68.240.91]) by mx1.freebsd.org (Postfix) with ESMTP id 391F613C459; Tue, 20 Nov 2007 11:27:18 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from [80.68.244.40] (account a_popov@rbc.ru [80.68.244.40] verified) by hermes.hw.ru (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 201504203; Tue, 20 Nov 2007 14:26:43 +0300 Message-ID: <4742C46A.1060701@chistydom.ru> Date: Tue, 20 Nov 2007 14:26:34 +0300 From: Alexey Popov User-Agent: Thunderbird 2.0.0.6 (X11/20070924) MIME-Version: 1.0 To: Kris Kennaway References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> <4741A7DA.2050706@chistydom.ru> <4741DA15.9000308@FreeBSD.org> <47429DB8.7040504@chistydom.ru> <4742ADFE.40902@FreeBSD.org> In-Reply-To: <4742ADFE.40902@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Ivan Voras Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 11:27:20 -0000 Hi Kris Kennaway wrote: >>>>>> CPU states: 9.5% user, 0.0% nice, 82.0% system, 0.5% >>>>>> interrupt, 8.0% idle >>>>> A wild idea that might not help: try reducing kern.hz in >>>>> loader.conf to >>>>> something like 100 and see if something significant changes. >> Usually on PHP backends slow PHP code eats most of the CPU time. I >> have %user much bigger than %system in CPU states. >> But now %system is much bigger than %user and I can conclude that on >> 8-core server FreeBSD consumes more CPU time than PHP. > That is one possibility, but you still need to look at the actual > throughput on these machines before making conclusions about which is > performing better. Can you please provide those numbers for 6.x, 7.x > with ULE and 4BSD on the 4-core and 8-core systems? Ok, here's results of practical research. The following is approximate maximum qps that backends can survive with my workload: 7-STABLE quad ULE 20 7-STABLE quad 4BSD 17 6-STABLE quad 14 6-STABLE dual 21 Linux CentOS 5 quad >50 With best regards, Alexey Popov From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 11:47:35 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A661016A419 for ; Tue, 20 Nov 2007 11:47:35 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 64F7E13C448 for ; Tue, 20 Nov 2007 11:47:35 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: by blah.sun-fish.com (Postfix, from userid 1002) id C24381B10F14; Tue, 20 Nov 2007 12:47:27 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on blah.cmotd.com X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 Received: from hater.haters.org (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id 090AD1B10F0B for ; Tue, 20 Nov 2007 12:47:23 +0100 (CET) Message-ID: <4742C94B.90309@moneybookers.com> Date: Tue, 20 Nov 2007 13:47:23 +0200 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.9 (X11/20071120) MIME-Version: 1.0 To: FreeBSD Stable References: <4742A44D.8080402@moneybookers.com> In-Reply-To: Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4855/Tue Nov 20 10:49:20 2007 on blah.cmotd.com X-Virus-Status: Clean Subject: Re: Weird issue with DELL PE2850 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 11:47:35 -0000 Hi, Ronald Klop wrote: > On Tue, 20 Nov 2007 10:09:33 +0100, Stefan Lambrev > wrote: > >> Hi, >> >> I'm experiencing strange problem with PE2850 - CPU: Intel(R) Xeon(TM) >> CPU 3.20GHz (3192.23-MHz K8-class CPU) >> It's a dual processor (with HT) server and worked very well with >> freebsd 6.2, >> before few days I updated one of ours pe2850 to see how will 6.3 >> perform, and the first think that I notice >> is a freeze for few minutes during boot. >> >> Everything is ok till the following lines are displayed: >> SMP: AP CPU #1 Launched! >> SMP: AP CPU #2 Launched! >> SMP: AP CPU #3 Launched! >> 2-5min freeze >> Trying to mount root from ufs:/dev/amrd0s1a >> ... >> I saw the same thing on other pe2850 with 7-BETA2, and I'm pretty >> sure that both servers >> didn't have such problems with earlier versions of 7-current and >> 6.2-stable. >> >> I'm running amd64 on both servers. >> on 6.3 hyperthreading is disabled and on 7b2 is enabled. >> I have CPUTYPE?=nocona in /etc/make.conf >> >> Any ideas where to dig and how to debug? >> Can someone else confirm this? >> I'm sure pe2850 is/was very popular server ;) >> > > Did you boot with verbose messages on? > > Ronald. > SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x07000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x06000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 4 to local APIC 0 ioapic0: Assigning ISA IRQ 9 to local APIC 0 ioapic0: Assigning ISA IRQ 14 to local APIC 0 ioapic0: Assigning ISA IRQ 15 to local APIC 0 ioapic0: Assigning PCI IRQ 16 to local APIC 0 ioapic0: Assigning PCI IRQ 18 to local APIC 0 ioapic0: Assigning PCI IRQ 19 to local APIC 0 ioapic0: Assigning PCI IRQ 21 to local APIC 0 ioapic0: Assigning PCI IRQ 23 to local APIC 0 ioapic1: Assigning PCI IRQ 46 to local APIC 0 ioapic2: Assigning PCI IRQ 64 to local APIC 0 ioapic2: Assigning PCI IRQ 65 to local APIC 0 ioapic3: Assigning PCI IRQ 106 to local APIC 0 ioapic3: Assigning PCI IRQ 107 to local APIC 0 ~2min freeze Trying to mount root from ufs:/dev/amrd0s1a Do not think this is more helpful :( -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 11:57:04 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50EB616A417; Tue, 20 Nov 2007 11:57:04 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from hermes.hw.ru (hermes.hw.ru [80.68.240.91]) by mx1.freebsd.org (Postfix) with ESMTP id 3AB7813C448; Tue, 20 Nov 2007 11:57:02 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from [80.68.244.40] (account a_popov@rbc.ru [80.68.244.40] verified) by hermes.hw.ru (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 201513087; Tue, 20 Nov 2007 14:56:44 +0300 Message-ID: <4742CB72.1060305@chistydom.ru> Date: Tue, 20 Nov 2007 14:56:34 +0300 From: Alexey Popov User-Agent: Thunderbird 2.0.0.6 (X11/20070924) MIME-Version: 1.0 To: Ivan Voras References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> <4741B3DE.2000009@chistydom.ru> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 11:57:04 -0000 Hi. Ivan Voras wrote: > Some more ideas: How is your disk load (iostat, systat -vm, diskinfo -t) > during the load? You don't use NFS for the web directories, do you? > Can you run bonnie++ while the machine is idle (i.e. apache is stopped) > just to verify it isn't a stupid problem with the disks or the driver? There's almost no disk load except writing ~15 strings per second to logs. All PHP code fits in memory and there's no need to read disk. atime turned off. NFS is not used. > So, you pick the CPU out of the motherboard and plug in another one? If > not, you can't be sure that some other thing isn't wrong. I know you > tried it on Linux, but it might use slightly different commands in the > driver that don't trigger the error. I'm very surprised that both 6.x > and 7.x behave almost the same on your load: since they are very > different in how they support multiple CPU-s, I'd expect a big > difference in this case (in favour of 7.x), not a small one. This might > point that the problem is not in the OS itself, but maybe in the > hardware or in some driver. I did'nt change CPU myself, but I think this 4-core and 8-core servers (Intel SR1500 platform) are different only in CPUs. You can see it in dmesg in the root of this thread. > You don't have WITNESS, INVARIANTS, DIAGNOSTICS or something similar > enabled? Can you try a generic SMP kernel (called "SMP" in 6.x; the > "GENERIC" in 7.x has SMP by default) and see how it works? > Can you disable SMP and try with only one CPU (on the 2xquad machine)? > You can do it in loader.conf by setting kern.smp.disabled=1, or perhaps > in BIOS. If there's a problem in some hardware or a driver, you'd still > get a big load on sys time. You might also want to halt certain logical > CPUs in the OS itself (see smp(4) man page) and see if there's a certain > relationship between how many CPUs are running and what the sys load is. Thank you. I need some time to try all this. I'll report if find something. With best regards, Alexey Popov From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 12:01:58 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C31116A473 for ; Tue, 20 Nov 2007 12:01:58 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 265E813C4B8 for ; Tue, 20 Nov 2007 12:01:58 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: by blah.sun-fish.com (Postfix, from userid 1002) id AF0561B10F15; Tue, 20 Nov 2007 13:01:50 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on blah.cmotd.com X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 Received: from hater.haters.org (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id 25B931B10F14; Tue, 20 Nov 2007 13:01:48 +0100 (CET) Message-ID: <4742CCAC.1060706@moneybookers.com> Date: Tue, 20 Nov 2007 14:01:48 +0200 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.9 (X11/20071120) MIME-Version: 1.0 To: Alexey Popov References: <4741905E.8050300@chistydom.ru> In-Reply-To: <4741905E.8050300@chistydom.ru> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4855/Tue Nov 20 10:49:20 2007 on blah.cmotd.com X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 12:01:58 -0000 Hi Alexey, Can you please send and dmesg from FreeBSD 7 on this server? As I'm little puzzled what you mean by 7-stable :) Alexey Popov wrote: > Hi. > > I have a large pool of web backends (Apache + mod_php5) with > 2 x Xeon 3.2GHz processors and 2 x Xeon 5120 dual-core processors. The > workload is mostly CPU-bound. I'm using 6-STABLE-amd64 and also tried > 7-STABLE. > > Now I'm trying to use new hardware with 2 x Xeon 5320 (quad-core), but > it can not work under the same load as dual-core. It shows up to 80% > system CPU load in top: > > ------------------------------------------------------------------------ > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 11:54:45 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72F3716A468 for ; Tue, 20 Nov 2007 11:54:45 +0000 (UTC) (envelope-from meubanks@mse.homeunix.net) Received: from solen.mse.homeunix.net (66-189-178-93.dhcp.wnch.wa.charter.com [66.189.178.93]) by mx1.freebsd.org (Postfix) with ESMTP id 3F87513C4C6 for ; Tue, 20 Nov 2007 11:54:44 +0000 (UTC) (envelope-from meubanks@mse.homeunix.net) Received: from mselbep117p6dw (koro.mse.homeunix.net [192.168.10.103]) by solen.mse.homeunix.net (8.14.1/8.14.1) with ESMTP id lAILxxPX026198 for ; Sun, 18 Nov 2007 13:59:59 -0800 (PST) (envelope-from meubanks@mse.homeunix.net) From: "Michael Eubanks" To: Date: Sun, 18 Nov 2007 13:59:48 -0800 Message-ID: <000901c82a2e$59d9d750$8102fea9@mselbep117p6dw> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcgqLlaNNICBoo2GSd2lLo+gAEBHWw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailman-Approved-At: Tue, 20 Nov 2007 12:34:41 +0000 Subject: problem compiling RELENG_6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 11:54:45 -0000 I've CVSup'd my RELENG_6 source and tried a make buildworld. Compilation breaks with the following error: ===> sbin/ipf/libipf (depend) make: don't know how to make extras.c. Stop *** Error code 2 I noticed there was another post with this same problem at http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2007-11/msg00203.htm l, although, I'm curious if there is a fix? Thank you, -Michael Eubanks meubanks@wsu.edu From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 12:48:26 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAA7816A46E for ; Tue, 20 Nov 2007 12:48:26 +0000 (UTC) (envelope-from k.joch@kmjeuro.com) Received: from sv07e.atm-tzs.kmjeuro.com (sv07e.atm-tzs.kmjeuro.com [193.81.94.207]) by mx1.freebsd.org (Postfix) with ESMTP id 6281F13C478 for ; Tue, 20 Nov 2007 12:48:25 +0000 (UTC) (envelope-from k.joch@kmjeuro.com) Received: from sv03 (adsl.sbg.kmjeuro.com [62.99.198.46]) (authenticated bits=0) by sv07e.atm-tzs.kmjeuro.com (8.12.10/8.12.10) with ESMTP id lAKCG1nG048849 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 20 Nov 2007 13:16:02 +0100 (CET) (envelope-from k.joch@kmjeuro.com) From: "Karl M. Joch" To: Date: Tue, 20 Nov 2007 13:15:56 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Thread-Index: Acgrbxm1qnv1dwoRQaKVeAUf5t/iiQ== In-Reply-To: <4742CCAC.1060706@moneybookers.com> X-CTS-SV07-Mailserver-Information: please visit www.ctseuro.com for further instructions. Protected by www.ctseuro.com X-CTS-SV07-Mailserver: Found to be clean X-CTS-SV07-Mailserver-From: k.joch@kmjeuro.com Subject: Software for distribution of configuration files and changes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 12:48:26 -0000 Hello, i have searched alot for a software to: - distribut configuration files from one master to different systems - maintain configuration files on one machine for all systemes and then send it out - push the files, not download them like cvsup - maintaining files for all systems and files only affecting one system any ideas and hints would be greatly appreziatet. Many thanks, best regards, Karl From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 12:58:18 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C02416A420 for ; Tue, 20 Nov 2007 12:58:18 +0000 (UTC) (envelope-from richard@unixguru.nl) Received: from mx1.unixguru.nl (mx1.unixguru.nl [77.37.12.119]) by mx1.freebsd.org (Postfix) with ESMTP id E321E13C46E for ; Tue, 20 Nov 2007 12:58:17 +0000 (UTC) (envelope-from richard@unixguru.nl) Received: from localhost (mx1.unixguru.nl [77.37.12.119]) by mx1.unixguru.nl (Postfix) with ESMTP id 986E51F823; Tue, 20 Nov 2007 13:59:18 +0100 (CET) Received: from mx1.unixguru.nl ([77.37.12.119]) by localhost (vs8916.vserver4free.de [77.37.12.119]) (amavisd-new, port 10024) with ESMTP id 3nM91I6DqzPz; Tue, 20 Nov 2007 13:59:18 +0100 (CET) Received: from mail.unixguru.nl (www.unixguru.nl [217.122.53.58]) by mx1.unixguru.nl (Postfix) with ESMTP id 154EF1F77E; Tue, 20 Nov 2007 13:59:18 +0100 (CET) Received: from localhost (shell.unixguru.nl [192.168.10.20]) by mail.unixguru.nl (Postfix) with ESMTP id 2238D11426; Tue, 20 Nov 2007 13:58:11 +0100 (CET) Date: Tue, 20 Nov 2007 13:58:10 +0100 From: Richard Arends To: "Karl M. Joch" Message-ID: <20071120125810.GC793@shell.unixguru.nl> References: <4742CCAC.1060706@moneybookers.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: Software for distribution of configuration files and changes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 12:58:18 -0000 On Tue, Nov 20, 2007 at 01:15:56PM +0100, Karl M. Joch wrote: Karl, > i have searched alot for a software to: > > - distribut configuration files from one master to different systems > - maintain configuration files on one machine for all systemes and then send > it out > - push the files, not download them like cvsup > - maintaining files for all systems and files only affecting one system > > any ideas and hints would be greatly appreziatet. http://en.wikipedia.org/wiki/Comparison_of_open_source_configuration_management_software -- Regards, Richard. /* Homo Sapiens non urinat in ventum */ From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 14:08:28 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FB0316A417 for ; Tue, 20 Nov 2007 14:08:28 +0000 (UTC) (envelope-from klintrup@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.freebsd.org (Postfix) with ESMTP id F099513C46B for ; Tue, 20 Nov 2007 14:08:27 +0000 (UTC) (envelope-from klintrup@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so1766224nfb for ; Tue, 20 Nov 2007 06:08:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; bh=kPolsRCyr7F+Z09h3UMNPxJBbAr/vO7gNeOAdZ5dDPQ=; b=rR4ypGmbPGYihcSf/N8NH3D8e28ZlDwSDkKR/AEeIBG4ntvEq9zdZbITAvZLHP7shkALZIXDy1wJJrk+ggZA+mNXpXvSd11c7ATJ12w6aEgRNGb3bEkdElL8jrRtNUGAfPLlwCs7RAvNXRHJOTY4wHkCyA63UfpRdsZwpx2G82M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=RSHO9Xjl6lvCyfJmjs03Ons9rD3VzFy0etmaiu4JC/z5CViD9B9W+w2yNSebxSAI/27al+7JHKJQqd+tz2axOfGr7ChodHkwbGdEXyQ+cwM6ZOt28vyK03d/sBkPXUQu/mkybkWLHjSIDpS+YwXbZEhsTQbgqwai9RDkhFBQ27Q= Received: by 10.82.112.3 with SMTP id k3mr17383623buc.1195565940918; Tue, 20 Nov 2007 05:39:00 -0800 (PST) Received: from ?192.168.45.149? ( [217.116.254.180]) by mx.google.com with ESMTPS id y37sm8267725iky.2007.11.20.05.38.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 20 Nov 2007 05:38:59 -0800 (PST) Message-ID: <4742E372.6060802@klintrup.dk> Date: Tue, 20 Nov 2007 14:38:58 +0100 From: =?ISO-8859-1?Q?S=F8ren_Klintrup?= User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Karl M. Joch" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: =?ISO-8859-1?Q?S=F8ren=20Klintrup?= Cc: freebsd-stable@freebsd.org Subject: Re: Software for distribution of configuration files and changes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 14:08:28 -0000 Karl M. Joch wrote: > Hello, > > i have searched alot for a software to: > > - distribut configuration files from one master to different systems > - maintain configuration files on one machine for all systemes and then send > it out > - push the files, not download them like cvsup > - maintaining files for all systems and files only affecting one system > > any ideas and hints would be greatly appreziatet. I've used cfengine for the past 4-5 years and can definately recommend it, more info on http://www.cfengine.net Cfengine maintains files and changes for a single system without problems, however it is primarily made for generic changes across a large number of systems, so if most of the changes are unique to each host, you probably want to look at something else. regards, Søren From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 15:13:00 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F04C216A41B for ; Tue, 20 Nov 2007 15:13:00 +0000 (UTC) (envelope-from dmw@unete.cl) Received: from mail02.ifxnetworks.com (mail02.ifxnetworks.com [190.61.128.32]) by mx1.freebsd.org (Postfix) with ESMTP id 9849313C47E for ; Tue, 20 Nov 2007 15:13:00 +0000 (UTC) (envelope-from dmw@unete.cl) Received: (qmail 13117 invoked from network); 20 Nov 2007 14:46:19 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on mail02.ifxnetworks.com X-Spam-Level: X-Spam-Status: No, score=0.1 required=7.0 tests=RDNS_NONE autolearn=disabled version=3.2.3 Received: from unknown (HELO [10.3.9.12]) (dmw@unete.cl@[200.73.52.251]) (envelope-sender ) by mail02.ifxnetworks.com (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 20 Nov 2007 14:46:18 -0000 Message-ID: <4742F331.1020607@unete.cl> Date: Tue, 20 Nov 2007 11:46:09 -0300 From: Daniel Molina Wegener Organization: DMW User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Michael Eubanks References: <000901c82a2e$59d9d750$8102fea9@mselbep117p6dw> In-Reply-To: <000901c82a2e$59d9d750$8102fea9@mselbep117p6dw> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: Re: problem compiling RELENG_6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dmw@unete.cl List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 15:13:01 -0000 Michael Eubanks escribió: > I've CVSup'd my RELENG_6 source and tried a make buildworld. Compilation > breaks with the following error: > > ===> sbin/ipf/libipf (depend) > make: don't know how to make extras.c. Stop > *** Error code 2 > > I noticed there was another post with this same problem at > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2007-11/msg00203.htm > l, although, I'm curious if there is a fix? It's fixed. I've CVSup'd again on sunday and I've compiled the source. Now I have 6.3-PRERELEASE and waiting for 6.3-STABLE. xD > > > Thank you, > -Michael Eubanks > meubanks@wsu.edu > > [SNI] Regards, -- .O. | Daniel Molina Wegener | C/C++ Developer ..O | dmw [at] unete [dot] cl | FOSS Coding Addict OOO | FreeBSD & Linux User | Standards Rocks! From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 15:32:26 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D59616A420 for ; Tue, 20 Nov 2007 15:32:26 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by mx1.freebsd.org (Postfix) with ESMTP id 6EF9713C48A for ; Tue, 20 Nov 2007 15:32:24 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so2544040waf for ; Tue, 20 Nov 2007 07:32:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=96zkQ9RLJJtT3fLXH2MPSJwyOaIQrfSVxw3q04/sNQM=; b=sYFyP8m4LvkX0O0nPgpywed8NuWBqZ56cU9z/2BW2lrbVthjYB/9DTUGecFj93sqYw7hQyKF9WcQ1M/hnq31bARRfwHidaqyrNnjsnPilt/5zNsg9ggP7TJ+JbgmSX/SZLSeS92CFfHdieEZWsUAlaeeTfYN+85WwyCpGg+Ltvo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=C3dx53m5uAotRvFG8UJeGpHgscVWVmPQhVtMymlqMHmR68yhG4/qtvN0AOCJ9g36lAnyGFKrg2aGVWvk2d4Z+XD3MXVdeI4UJHpKYglPOCR44thPs/qzQ3XHEa7WnXnL1heTa4Fb4Et+k6rnuW/RUICiYO7lE07I9UQaYJNXPvM= Received: by 10.114.209.1 with SMTP id h1mr138872wag.1195571179414; Tue, 20 Nov 2007 07:06:19 -0800 (PST) Received: by 10.115.109.10 with HTTP; Tue, 20 Nov 2007 07:06:19 -0800 (PST) Message-ID: Date: Tue, 20 Nov 2007 10:06:19 -0500 From: "Scott Ullrich" To: "Michael Eubanks" In-Reply-To: <000901c82a2e$59d9d750$8102fea9@mselbep117p6dw> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <000901c82a2e$59d9d750$8102fea9@mselbep117p6dw> Cc: freebsd-stable@freebsd.org Subject: Re: problem compiling RELENG_6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 15:32:26 -0000 On Nov 18, 2007 4:59 PM, Michael Eubanks wrote: > I've CVSup'd my RELENG_6 source and tried a make buildworld. Compilation > breaks with the following error: > > ===> sbin/ipf/libipf (depend) > make: don't know how to make extras.c. Stop > *** Error code 2 > > I noticed there was another post with this same problem at > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2007-11/msg00203.htm > l, although, I'm curious if there is a fix? You most likely cvsupped in the middle of Darren Reeds forgotten Makefile commit. It should be commited now if you want to try cvsupping and building again. Scott From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 16:27:55 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC17116A41B; Tue, 20 Nov 2007 16:27:55 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from hermes.hw.ru (hermes.hw.ru [80.68.240.91]) by mx1.freebsd.org (Postfix) with ESMTP id D75BD13C45D; Tue, 20 Nov 2007 16:27:54 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from [80.68.244.40] (account a_popov@rbc.ru [80.68.244.40] verified) by hermes.hw.ru (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 201584434; Tue, 20 Nov 2007 19:27:28 +0300 Message-ID: <47430AE8.7050408@chistydom.ru> Date: Tue, 20 Nov 2007 19:27:20 +0300 From: Alexey Popov User-Agent: Thunderbird 2.0.0.6 (X11/20070924) MIME-Version: 1.0 To: Ivan Voras References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> <4741B3DE.2000009@chistydom.ru> In-Reply-To: Content-Type: multipart/mixed; boundary="------------090001010301070405070406" Cc: freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 16:27:55 -0000 This is a multi-part message in MIME format. --------------090001010301070405070406 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi. Ivan Voras wrote: > Many people (including me) have run FreeBSD on machines like yours > without such problems, so let's dig further. > > You don't have WITNESS, INVARIANTS, DIAGNOSTICS or something similar > enabled? Can you try a generic SMP kernel (called "SMP" in 6.x; the > "GENERIC" in 7.x has SMP by default) and see how it works? > > Can you disable SMP and try with only one CPU (on the 2xquad machine)? > You can do it in loader.conf by setting kern.smp.disabled=1, or perhaps > in BIOS. If there's a problem in some hardware or a driver, you'd still > get a big load on sys time. You might also want to halt certain logical > CPUs in the OS itself (see smp(4) man page) and see if there's a certain > relationship between how many CPUs are running and what the sys load is. Now I'm running yesterday's FreeBSD 7.0-BETA3 amd64 with GENERIC kernel. I rebuilt kernel and world with clean make.conf. Also I rebuilt Apache, PHP and eAccelerator from scratch. I tried APC as well. No success. I tried 7-STABLE with UP kernel (GENERIC built without SMP config option). It works fine and can handle around 5-10 requests per second. It consumes %sys time is much less than %user time (see top output in attach). I.e. it seems to work good as a simple server with not so powerfull CPU. After that I rebuilt with SMP GENERIC kernel and put on that server 2 times more requests that UP could handle. For the first time it worked good. Then I increased load to 2.5 times more than UP. Immediately Apache child count increased to MaxClients (24), most of them in RUN state, and %sys became greater than %user (see attach). I think after some threshold of load FreeBSD is paying more CPU time to the management of running processes than to run them. Also I tried to halt CPUs by machdep.hlt_cpus sysctl, but in that case %sys in top was still much greater than %user. With best regards, Alexey Popov --------------090001010301070405070406 Content-Type: text/plain; name="top-SMP.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="top-SMP.txt" bGFzdCBwaWQ6ICAxMTAwOyAgbG9hZCBhdmVyYWdlczogIDguNTUsICA1LjIwLCAgMi4zNSAg ICAgICAgICAgICAgICAgICAgdXAgMCswMDowNTozOSAgMTg6NTk6NTIKNDggcHJvY2Vzc2Vz OiAgMjIgcnVubmluZywgMjYgc2xlZXBpbmcKQ1BVIHN0YXRlczogIDUuOSUgdXNlciwgIDAu MCUgbmljZSwgODEuMyUgc3lzdGVtLCAgMC4wJSBpbnRlcnJ1cHQsIDEyLjglIGlkbGUKTWVt OiAyNDVNIEFjdGl2ZSwgMTRNIEluYWN0LCAxMDJNIFdpcmVkLCAxMDhLIENhY2hlLCA0OE0g QnVmLCAzNTQzTSBGcmVlClN3YXA6IDIwNDhNIFRvdGFsLCAyMDQ4TSBGcmVlCgogIFBJRCBV U0VSTkFNRSAgIFRIUiBQUkkgTklDRSAgIFNJWkUgICAgUkVTIFNUQVRFICBDICAgVElNRSAg IFdDUFUgQ09NTUFORAogMTA5MyB3d3cgICAgICAgICAgMSAxMDUgICAgMCA5NDUyNEsgMzk3 MTZLIENQVTEgICA3ICAgMDowOSAzNC40MSUgaHR0cGQKIDEwOTQgd3d3ICAgICAgICAgIDEg MTA1ICAgIDAgOTE0NTJLIDM5NzMySyBzZWxlY3QgNCAgIDA6MDkgMzQuMDElIGh0dHBkCiAx MDk3IHd3dyAgICAgICAgICAxICAtNCAgICAwICAgIDk4TSA0ODM5MksgUlVOICAgIDcgICAw OjEwIDMzLjQxJSBodHRwZAogMTA5OCB3d3cgICAgICAgICAgMSAxMDUgICAgMCA5MjQ3Nksg NDMxNzZLIENQVTQgICA3ICAgMDowOSAzMy4yNyUgaHR0cGQKIDEwOTkgd3d3ICAgICAgICAg IDEgIC00ICAgIDAgOTI0NzZLIDQwNzg0SyBSVU4gICAgNyAgIDA6MDkgMzMuMjElIGh0dHBk CiAxMTAwIHd3dyAgICAgICAgICAxICAtNCAgICAwIDkyNDc2SyA0MTA4MEsgUlVOICAgIDQg ICAwOjA5IDMyLjg3JSBodHRwZAogMTA5NSB3d3cgICAgICAgICAgMSAgLTQgICAgMCA5MjQ3 NksgNDA4MjRLIFJVTiAgICA2ICAgMDowOSAzMi43NCUgaHR0cGQKIDEwOTAgd3d3ICAgICAg ICAgIDEgIC00ICAgIDAgOTY1NzJLIDQyNzAwSyBSVU4gICAgNSAgIDA6MDkgMzIuNTQlIGh0 dHBkCiAxMDg5IHd3dyAgICAgICAgICAxICAtNCAgICAwIDkzNTA0SyA0MjAzMksgUlVOICAg IDcgICAwOjA5IDMyLjQxJSBodHRwZAogMTA5MSB3d3cgICAgICAgICAgMSAgLTQgICAgMCA5 NTU0OEsgNDQ5MDBLIFJVTiAgICA0ICAgMDowOSAzMS45NSUgaHR0cGQKIDEwOTYgd3d3ICAg ICAgICAgIDEgIC00ICAgIDAgOTg2MjBLIDQ3MTYwSyBSVU4gICAgNiAgIDA6MDkgMzEuODYl IGh0dHBkCiAxMDg2IHd3dyAgICAgICAgICAxICAtNCAgICAwIDk2NTcySyA0NTc1MksgUlVO ICAgIDYgICAwOjEwIDMwLjkyJSBodHRwZAogMTA4NyB3d3cgICAgICAgICAgMSAxMDQgICAg MCA5MjQ3NksgNDEwMTZLIENQVTcgICA2ICAgMDowOSAzMC43MCUgaHR0cGQKIDEwODggd3d3 ICAgICAgICAgIDEgMTA0ICAgIDAgOTI0NzZLIDM4MzMySyBDUFUyICAgNiAgIDA6MTAgMzAu NTElIGh0dHBkCiAxMDg1IHd3dyAgICAgICAgICAxIDEwNSAgICAwIDk3NTk2SyA0NDQxNksg Q1BVNSAgIDUgICAwOjA5IDMwLjIzJSBodHRwZAogMTA5MiB3d3cgICAgICAgICAgMSAgLTQg ICAgMCA5MjQ3NksgNDAxNzJLIFJVTiAgICA2ICAgMDowOCAyOS40NSUgaHR0cGQKCg== --------------090001010301070405070406 Content-Type: text/plain; name="top-UP.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="top-UP.txt" bGFzdCBwaWQ6ICAyMjAzOyAgbG9hZCBhdmVyYWdlczogIDkuNzEsIDEwLjA4LCAgNy4zOCAg ICAgICAgICAgICAgICAgICAgdXAgMCswMDoxNzo0OCAgMTg6NTA6MzkKMzUgcHJvY2Vzc2Vz OiAgNSBydW5uaW5nLCAzMCBzbGVlcGluZwpDUFUgc3RhdGVzOiA4Mi4yJSB1c2VyLCAgMC4w JSBuaWNlLCAxMy44JSBzeXN0ZW0sICAwLjAlIGludGVycnVwdCwgIDQuMCUgaWRsZQpNZW06 IDEyOE0gQWN0aXZlLCAxNU0gSW5hY3QsIDEwOU0gV2lyZWQsIDEzMksgQ2FjaGUsIDg4TSBC dWYsIDM2NTdNIEZyZWUKU3dhcDogMjA0OE0gVG90YWwsIDIwNDhNIEZyZWUKCiAgUElEIFVT RVJOQU1FICAgVEhSIFBSSSBOSUNFICAgU0laRSAgICBSRVMgU1RBVEUgICAgVElNRSAgIFdD UFUgQ09NTUFORAogMjIwMSB3d3cgICAgICAgICAgMSAxMTcgICAgMCA5MjQ3NksgNDAzNTJL IFJVTiAgICAgIDA6MDIgMTAuNDglIGh0dHBkCiAyMjAzIHd3dyAgICAgICAgICAxIDExNiAg ICAwIDk2NTcySyA0MDkxMksgUlVOICAgICAgMDowMiAxMC4wNSUgaHR0cGQKIDIxOTUgd3d3 ICAgICAgICAgIDEgMTE3ICAgIDAgOTM1MDBLIDQzMDEySyBzZWxlY3QgICAwOjAyICA5LjYx JSBodHRwZAogMjIwMiB3d3cgICAgICAgICAgMSAgMjAgICAgMCA5MTQ1MksgNDEwNTZLIGxv Y2tmICAgIDA6MDIgIDguOTUlIGh0dHBkCiAyMTk0IHd3dyAgICAgICAgICAxIDExNyAgICAw ICAgMTAyTSA0OTQ0MEsgUlVOICAgICAgMDowMyAgOC4xMCUgaHR0cGQKIDIxOTIgd3d3ICAg ICAgICAgIDEgMTE0ICAgIDAgOTk2NDhLIDQ2MTY4SyBzZWxlY3QgICAwOjAzICA2Ljc2JSBo dHRwZAogMjE3OSB3d3cgICAgICAgICAgMSAgMjAgICAgMCA5MjQ3NksgNDE2NzJLIGxvY2tm ICAgIDA6MDQgIDYuNjklIGh0dHBkCiAyMTczIHd3dyAgICAgICAgICAxIDExOCAgICAwICAg MTAwTSA0ODkyMEsgUlVOICAgICAgMDowNCAgNS45MiUgaHR0cGQKIDIxNzQgd3d3ICAgICAg ICAgIDEgIDIwICAgIDAgOTI0NzZLIDQyOTY0SyBsb2NrZiAgICAwOjA0ICA1LjY3JSBodHRw ZAogIDg3OCBsbHAgICAgICAgICAgMSAgOTYgICAgMCAzMjkyOEsgIDQ1NzZLIHNlbGVjdCAg IDA6MDAgIDAuMDAlIHNzaGQKICA4OTEgcm9vdCAgICAgICAgIDEgIDIwICAgIDAgIDk2MTZL ICAyOTI0SyBwYXVzZSAgICAwOjAwICAwLjAwJSBjc2gKICA2OTEgcm9vdCAgICAgICAgIDEg IDk2ICAgIDAgIDg5NTJLICAyNTI4SyBzZWxlY3QgICAwOjAwICAwLjAwJSBudHBkCiAyMTYx IHJvb3QgICAgICAgICAxIDEzMSAgICAwIDg2MzMySyAxMzA4MEsgc2VsZWN0ICAgMDowMCAg MC4wMCUgaHR0cGQKIDIxNzggcm9vdCAgICAgICAgIDEgIDk2ICAgIDAgIDc2NTZLICAyMTY4 SyBSVU4gICAgICAwOjAwICAwLjAwJSB0b3AKICA4NzUgcm9vdCAgICAgICAgIDEgICA0ICAg IDAgMzI5MjhLICA0NTEySyBzYndhaXQgICAwOjAwICAwLjAwJSBzc2hkCiAgNzc0IHJvb3Qg ICAgICAgICAxICAgNCAgICAwICA0ODUySyAgMTY1Mksga3FyZWFkICAgMDowMCAgMC4wMCUg bWFzdGVyCgo= --------------090001010301070405070406-- From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 16:47:07 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7174E16A49E for ; Tue, 20 Nov 2007 16:47:07 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.freebsd.org (Postfix) with ESMTP id 0E72813C4C6 for ; Tue, 20 Nov 2007 16:47:06 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: by nf-out-0910.google.com with SMTP id b2so1824549nfb for ; Tue, 20 Nov 2007 08:47:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=beta; h=domainkey-signature:received:received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer; bh=W1MbGB6/uuHrD1Hhymk2V+TqrhuftTqbX1VzIClx+hs=; b=iHCOCgHPEPkAav7NbjznFmbO/pebK0bpRLBZuRU674dmL1Cu9wc/Ao7ee0fxp1YXuuf3kpBrDndK4jyLSezTLU6XV4zQrQSWyeZ9a205cFnw7hhHZuU9XT6SGB6Zr4YbmtK//9wiG5sNcv9whDuoEl2SEI96eNShE8PpB7NdTpQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer; b=CW/lzO8vpRMCNj8wpW0PNR9sNWPBLAyO4ssejlgtgN1dLbn13uE+jKaD76W5gXO0oK5x2eZUxmrPUeYPxBPdUMILgOAAYlpUWoFmXxY7rzvuRt4NbTrmbJPIheYlJs0qeA+d4qgOLp3IT3AKDzMeYnyCqgPV0AxByEk7CoJyFs4= Received: by 10.82.114.3 with SMTP id m3mr17884251buc.1195577224754; Tue, 20 Nov 2007 08:47:04 -0800 (PST) Received: from ?127.0.0.1? ( [217.206.187.79]) by mx.google.com with ESMTPS id m5sm3389592gve.2007.11.20.08.47.02 (version=SSLv3 cipher=RC4-MD5); Tue, 20 Nov 2007 08:47:03 -0800 (PST) From: Tom Evans To: Alexey Popov In-Reply-To: <47430AE8.7050408@chistydom.ru> References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> <4741B3DE.2000009@chistydom.ru> <47430AE8.7050408@chistydom.ru> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-3EIiZa0Krddtsz1adeD/" Date: Tue, 20 Nov 2007 16:47:02 +0000 Message-Id: <1195577222.82763.20.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.2 FreeBSD GNOME Team Port Cc: freebsd-stable@freebsd.org, Ivan Voras Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 16:47:07 -0000 --=-3EIiZa0Krddtsz1adeD/ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2007-11-20 at 19:27 +0300, Alexey Popov wrote: > Hi. > > After that I rebuilt with SMP GENERIC kernel and put on that server 2=20 > times more requests that UP could handle. For the first time it worked=20 > good. Then I increased load to 2.5 times more than UP. Immediately=20 > Apache child count increased to MaxClients (24), most of them in RUN=20 > state, and %sys became greater than %user (see attach). I think after=20 > some threshold of load FreeBSD is paying more CPU time to the management=20 > of running processes than to run them. >=20 > Also I tried to halt CPUs by machdep.hlt_cpus sysctl, but in that case=20 > %sys in top was still much greater than %user. MaxClients of 24 seems very low for a 8 cpu box, running prefork MPM. On our quad CPU boxes, running custom apache modules, we use=20 MaxClients 70 MinSpareServers 5 MaxSpareServers 15 StartServers 20 Perhaps you are seeing high system load because the system is having to maintain a lot of queued connections. Certainly, our load remains in-between comfortable margins, except when heavily stressed. Tom --=-3EIiZa0Krddtsz1adeD/ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBHQw+AlcRvFfyds/cRAk0PAKDCzGQHCCNT29eueBa8/xZeq+1XaQCgqmi8 eb9xKET6MT0hxDCA2IIvG0k= =ozz2 -----END PGP SIGNATURE----- --=-3EIiZa0Krddtsz1adeD/-- From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 17:15:18 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFFC816A469 for ; Tue, 20 Nov 2007 17:15:18 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.191]) by mx1.freebsd.org (Postfix) with ESMTP id B1E6613C448 for ; Tue, 20 Nov 2007 17:15:18 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so1843709rvb for ; Tue, 20 Nov 2007 09:15:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=IaTvqpKFfx0FgnEibmvU9La8y4ksl2O4QasVKzzs79Y=; b=Ivo+Kk0pM8xUMSAJpGiJEhIjOwJa/+EthydEPL7M2gfTlPKLC4zkMMxqtqF6Sg2TIrawbqehIxffrJSPk2ffxOvYvDXcW/dKtaJkA18Z70aYn76hVCqLIeozeGLxTugp0VyvGmZF4ud1bSK4uH1vfLHD6L8HvwROOvZaclgaAWk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=eeflIgb15/pv7MmF6dVaivGRe96r6knTmNOF64qVO6eSrmEBhV5IndoZe47yWsCDQpcbw1b93RBlRrY4wT0ro9tJFT9odgDED4G92sqTw2AhW777eClkpby7XCJHAShVREH6Mc27/ld2wqvTJzGuHk7Q/SvmtrM9PraDlfUg3QQ= Received: by 10.140.142.4 with SMTP id p4mr2472435rvd.1195578917833; Tue, 20 Nov 2007 09:15:17 -0800 (PST) Received: by 10.141.211.5 with HTTP; Tue, 20 Nov 2007 09:15:17 -0800 (PST) Message-ID: <9bbcef730711200915n12e37efcs67cf260641b9baab@mail.gmail.com> Date: Tue, 20 Nov 2007 18:15:17 +0100 From: "Ivan Voras" Sender: ivoras@gmail.com To: "Alexey Popov" In-Reply-To: <47430AE8.7050408@chistydom.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> <4741B3DE.2000009@chistydom.ru> <47430AE8.7050408@chistydom.ru> X-Google-Sender-Auth: 969eb154c0d67094 Cc: freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 17:15:18 -0000 On 20/11/2007, Alexey Popov wrote: > CPU states: 5.9% user, 0.0% nice, 81.3% system, 0.0% interrupt, 12.8% idle > CPU states: 82.2% user, 0.0% nice, 13.8% system, 0.0% interrupt, 4.0% idle Interesting coincidence: 1 CPU generates almost 8x less "sys time" then 8 CPUs. But it seems that you have found something real. Inspired by your problem I've done a simple measurement ("ab") on a 4-CPU (2x2 core Opterons 2216 HE, PAE) machine I maintain, under these circumstances: - a "heavy" PHP application - FastCGI - in this case, load of 4 clients - on 6-STABLE and I'm reporting similar findings: last pid: 2254; load averages: 1.43, 0.92, 0.69 up 71+08:23:06 18:00:31 153 processes: 8 running, 144 sleeping, 1 zombie CPU states: 38.8% user, 0.0% nice, 48.4% system, 3.2% interrupt, 9.6% idle Mem: 2321M Active, 1135M Inact, 313M Wired, 139M Cache, 112M Buf, 93M Free Swap: 4500M Total, 336K Used, 4500M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 2208 www 1 99 0 115M 19808K RUN 1 0:06 36.83% php-cgi 2207 www 1 100 0 114M 19348K RUN 3 0:05 32.66% php-cgi 1715 www 1 99 0 115M 23672K CPU0 0 0:24 27.83% php-cgi 1710 www 1 101 0 114M 23460K RUN 1 0:31 22.17% php-cgi 1882 www 1 99 0 115M 23392K CPU2 3 0:18 21.34% php-cgi 1718 www 1 4 0 114M 22556K sbwait 0 0:21 19.14% php-cgi 2677 pgsql 1 4 0 977M 55768K sbwait 0 0:00 28.00% postgres We are not so performance bound as you so I didn't do measurements earlier. I cannot "play" with settings on this machine as it is in production, but ~~50% sys time (the measurement changes around 45% +/- 10%) seems too much. On another 4-CPU machine (2x2 Xeons 5110, AMD64) with the same application and benchmark setup, but RELENG_7, which is not yet in production, the results are slightly different: last pid: 66564; load averages: 1.87, 0.48, 0.18 up 15+05:27:03 17:09:09 113 processes: 9 running, 104 sleeping CPU states: 49.0% user, 0.0% nice, 28.8% system, 0.0% interrupt, 22.1% idle Mem: 555M Active, 295M Inact, 884M Wired, 98M Cache, 213M Buf, 135M Free Swap: 2047M Total, 2047M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 66557 www 1 109 0 105M 25340K RUN 3 0:14 64.99% php-cgi 66559 www 1 109 0 105M 25308K RUN 2 0:14 62.99% php-cgi 66561 www 1 98 0 105M 22196K RUN 0 0:01 12.99% php-cgi 66562 www 1 98 0 105M 22196K RUN 1 0:01 11.96% php-cgi 59043 nobody 1 47 0 7012K 3744K select 2 0:27 5.96% sqlcached 774 pgsql 1 44 0 437M 112M select 2 3:55 0.00% postgres From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 17:38:34 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FFF616A420 for ; Tue, 20 Nov 2007 17:38:34 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from comtv.ru (comtv.ru [217.10.32.17]) by mx1.freebsd.org (Postfix) with ESMTP id EA50B13C442 for ; Tue, 20 Nov 2007 17:38:33 +0000 (UTC) (envelope-from lol@chistydom.ru) X-UCL: actv Received: from yoda.org.ru ([83.167.98.162] verified) by comtv.ru (CommuniGate Pro SMTP 4.1.8) with ESMTP id 20951764; Tue, 20 Nov 2007 20:38:29 +0300 Received: from [192.168.102.10] (unknown [192.168.102.10]) (Authenticated sender: llp@soekris.ru) by yoda.org.ru (Postfix) with ESMTP id 5F88E28B5F; Tue, 20 Nov 2007 20:38:46 +0300 (MSK) Message-ID: <47431B75.4040601@chistydom.ru> Date: Tue, 20 Nov 2007 20:37:57 +0300 From: Alexey Popov User-Agent: Thunderbird 2.0.0.6 (X11/20070924) MIME-Version: 1.0 To: Ivan Voras References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> <4741B3DE.2000009@chistydom.ru> <47430AE8.7050408@chistydom.ru> <9bbcef730711200915n12e37efcs67cf260641b9baab@mail.gmail.com> In-Reply-To: <9bbcef730711200915n12e37efcs67cf260641b9baab@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 17:38:34 -0000 Hi. Ivan Voras wrote: >> CPU states: 5.9% user, 0.0% nice, 81.3% system, 0.0% interrupt, 12.8% idle >> CPU states: 82.2% user, 0.0% nice, 13.8% system, 0.0% interrupt, 4.0% idle > Interesting coincidence: 1 CPU generates almost 8x less "sys time" then 8 CPUs. > But it seems that you have found something real. Inspired by your > problem I've done a simple measurement ("ab") on a 4-CPU (2x2 core > Opterons 2216 HE, PAE) machine I maintain, under these circumstances: > > - a "heavy" PHP application > - FastCGI > - in this case, load of 4 clients > - on 6-STABLE > > and I'm reporting similar findings: > CPU states: 38.8% user, 0.0% nice, 48.4% system, 3.2% interrupt, 9.6% idle > We are not so performance bound as you so I didn't do measurements > earlier. I cannot "play" with settings on this machine as it is in > production, but ~~50% sys time (the measurement changes around 45% +/- > 10%) seems too much. Thank you for your research. I think you can get more %sys with 4-core processors. For me 2xquad-core systems are now completely unusable as PHP backends. Anyway I'm happy that I'm not alone with this problem. But what can we do about it? With best regards, Alexey Popov From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 17:42:47 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 764B316A419; Tue, 20 Nov 2007 17:42:47 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from angel.ticketswitch.com (angel.ticketswitch.com [IPv6:2002:57e0:1d4e::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4618513C458; Tue, 20 Nov 2007 17:42:47 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from smaug.rattatosk ([10.50.50.2]) by angel.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IuX7W-0009gb-5X; Tue, 20 Nov 2007 17:42:46 +0000 Received: from dilbert.rattatosk ([10.50.50.6] helo=dilbert.ticketswitch.com) by smaug.rattatosk with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IuX7W-000OBA-3H; Tue, 20 Nov 2007 17:42:46 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IuX7W-0002Mw-3Z; Tue, 20 Nov 2007 17:42:46 +0000 To: ivoras@freebsd.org, lol@chistydom.ru In-Reply-To: <47431B75.4040601@chistydom.ru> Message-Id: From: Pete French Date: Tue, 20 Nov 2007 17:42:46 +0000 Cc: freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 17:42:47 -0000 > Thank you for your research. I think you can get more %sys with 4-core > processors. For me 2xquad-core systems are now completely unusable as > PHP backends. I am getting very alarmed by this discussion as we just took delivery of ten 2x quad core systems to be deployes as heavy webservers in order to replace the dual core ones. probably under 7.0 as 6.3 wont boot PAE and they have 16 gigs of memory. > Anyway I'm happy that I'm not alone with this problem. But what can we > do about it? when I get a webserver up and running I will also do some benchmarking and see if I get the same results. I am simply running straight forward Obj-C code on mine. -pete. From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 17:45:34 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 224D616A41A for ; Tue, 20 Nov 2007 17:45:34 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from comtv.ru (comtv.ru [217.10.32.17]) by mx1.freebsd.org (Postfix) with ESMTP id 7CE6113C459 for ; Tue, 20 Nov 2007 17:45:33 +0000 (UTC) (envelope-from lol@chistydom.ru) X-UCL: actv Received: from yoda.org.ru ([83.167.98.162] verified) by comtv.ru (CommuniGate Pro SMTP 4.1.8) with ESMTP id 20952719; Tue, 20 Nov 2007 20:45:31 +0300 Received: from [192.168.102.10] (unknown [192.168.102.10]) (Authenticated sender: llp@soekris.ru) by yoda.org.ru (Postfix) with ESMTP id EA6D728CF5; Tue, 20 Nov 2007 20:45:49 +0300 (MSK) Message-ID: <47431D21.4050804@chistydom.ru> Date: Tue, 20 Nov 2007 20:45:05 +0300 From: Alexey Popov User-Agent: Thunderbird 2.0.0.6 (X11/20070924) MIME-Version: 1.0 To: Tom Evans References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> <4741B3DE.2000009@chistydom.ru> <47430AE8.7050408@chistydom.ru> <1195577222.82763.20.camel@localhost> In-Reply-To: <1195577222.82763.20.camel@localhost> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Ivan Voras Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 17:45:34 -0000 Hi. Tom Evans wrote: >> After that I rebuilt with SMP GENERIC kernel and put on that server 2 >> times more requests that UP could handle. For the first time it worked >> good. Then I increased load to 2.5 times more than UP. Immediately >> Apache child count increased to MaxClients (24), most of them in RUN >> state, and %sys became greater than %user (see attach). I think after >> some threshold of load FreeBSD is paying more CPU time to the management >> of running processes than to run them. > MaxClients of 24 seems very low for a 8 cpu box, running prefork MPM. On > our quad CPU boxes, running custom apache modules, we use > MaxClients 70 > MinSpareServers 5 > MaxSpareServers 15 > StartServers 20 > Perhaps you are seeing high system load because the system is having to > maintain a lot of queued connections. Certainly, our load remains > in-between comfortable margins, except when heavily stressed. I believe 8-core FreeBSD server is able to maintain 1024 waiting TCP connections without measurable CPU load. As of this problem: increasing MaxClients leads to growing %sys part of CPU load. Generally large MaxClients value is useful when most Apache children are waiting for I/O or something else but CPU. With best regards, Alexey Popov From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 18:01:30 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F91F16A41A for ; Tue, 20 Nov 2007 18:01:30 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by mx1.freebsd.org (Postfix) with ESMTP id 3699013C447 for ; Tue, 20 Nov 2007 18:01:29 +0000 (UTC) (envelope-from kometen@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so1852923nfb for ; Tue, 20 Nov 2007 10:01:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=0roBnQwJrgFEmbHqNm0i16UtDyZNXXViRI8K1S5DFtc=; b=hNLI3O8Zci9aXuzEmeNI8bxcMP+z/ytXOVen55Bh8mEv+W4+uwKGDxqNGB22ccIDqRL566sAEaYf2Iikd/XwBKoeNpeQIr2g5injpBZo2BmKoqRPesqNXvVUiCiEE98ZojflUkyhACiMMIv46uixweoSVrL/OAOStlo/51Y2fdg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hIZsBNINzvvVSyl5D1NxkC6Mjd126fsJEj0643S/Pc8DzpCqNsCN4d+gWg0MFWpm059/Os9U4m/7rU5Ut4v87yKQFZf1Nje1QQfmmtD0pxGi68z7FUrVfvPv4mlVyhqFyMfnajfkzpQd6j3gW2sSJusWkuOBwgK1b/l7z97Zswk= Received: by 10.78.204.7 with SMTP id b7mr7044146hug.1195581686067; Tue, 20 Nov 2007 10:01:26 -0800 (PST) Received: by 10.78.161.3 with HTTP; Tue, 20 Nov 2007 10:01:25 -0800 (PST) Message-ID: Date: Tue, 20 Nov 2007 19:01:25 +0100 From: "Claus Guttesen" To: "Pete French" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47431B75.4040601@chistydom.ru> Cc: freebsd-stable@freebsd.org, ivoras@freebsd.org, lol@chistydom.ru Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 18:01:30 -0000 > > Thank you for your research. I think you can get more %sys with 4-core > > processors. For me 2xquad-core systems are now completely unusable as > > PHP backends. > > I am getting very alarmed by this discussion as we just took delivery > of ten 2x quad core systems to be deployes as heavy webservers in order to > replace the dual core ones. probably under 7.0 as 6.3 wont boot PAE and > they have 16 gigs of memory. I'm running two DL360 G5 webservers each with two quad-core cpu's. Each have 8 GB of ram, one is 2 Ghz and the other is 2.33 Ghz. They run just fine. These two webservers have twice the weight of three opterons with two dual-core cpu's on our coyote load-balancer. The servers are so fast I had to adjust the read- and write-size in fstab for the nfs-mounts. Using 8kb I got the 'nfs server not responding - alive again' during peak on the new servers. Using a 2kb size instead solved my problem. They handle twice as much traffic as the 4-way-opterons. The quad-cores run 7.0 beta2 with ule, php, apache. -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 18:21:28 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E736C16A418 for ; Tue, 20 Nov 2007 18:21:28 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by mx1.freebsd.org (Postfix) with ESMTP id A8EC713C46B for ; Tue, 20 Nov 2007 18:21:28 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so7042891pyb for ; Tue, 20 Nov 2007 10:21:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=17mCxRIeWYmxQUuCZFx1VXrmKMnUmCQ9qrjLogaddqM=; b=tNDr5AVlG3OJqxEOg7DC4fkY5wIvd5NJDFdX5jti3BX38j62RksJOV9c/Hpq3NL9knPfwP5wNDcBzikppHfPTY6s8YABZHHAITogS2jAecV4jADM8qH14WJfMOZrmf80DGBkw9xNEpFFWfo7XUR90Nb+PYUgdgC8/8pRv7BsSg4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=Kuq+My8h10TEdULSVMVn36QtHTP6yF4FT/GJ2fhobfDlFY46N+E/iU73TEVl5uX/ABE48Coo+W1hnnfAsNiJAkQe+urg1lImH57PkJGTorAK/SlvoLzVJFAqv/DRwfPNAUlIHG7SiG0mZY83a9f/ph+fuk+PnLbAXu0HhNnocxU= Received: by 10.64.53.20 with SMTP id b20mr14772270qba.1195582885843; Tue, 20 Nov 2007 10:21:25 -0800 (PST) Received: from ?192.168.2.2? ( [67.85.89.184]) by mx.google.com with ESMTPS id 1sm4957543qbh.2007.11.20.10.21.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 20 Nov 2007 10:21:25 -0800 (PST) Message-ID: <474325A0.7060802@gmail.com> Date: Tue, 20 Nov 2007 13:21:20 -0500 From: "Aryeh M. Friedman" User-Agent: Thunderbird 2.0.0.6 (X11/20071111) MIME-Version: 1.0 To: "Karl M. Joch" References: In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Software for distribution of configuration files and changes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 18:21:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Karl M. Joch wrote: > Hello, > > i have searched alot for a software to: > > - distribut configuration files from one master to different > systems - maintain configuration files on one machine for all > systemes and then send it out - push the files, not download them > like cvsup - maintaining files for all systems and files only > affecting one system > > any ideas and hints would be greatly appreziatet. > Have you looked at aegis (aegis.sf.net)? - -- Aryeh M. Friedman Developer, not business, friendly http://www.flosoft-systems.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHQyWgJ9+1V27SttsRAvd0AJ0XkDvAUPZhvoONYp+yEbSUxxWpxQCfdrnk fz7gOeOmsHPkDxtf6bQo480= =0z9l -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 18:25:29 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F2B216A47A for ; Tue, 20 Nov 2007 18:25:29 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 47A6A13C465 for ; Tue, 20 Nov 2007 18:25:29 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IuXme-0003Ka-Qc for freebsd-stable@freebsd.org; Tue, 20 Nov 2007 18:25:16 +0000 Received: from 89-172-50-42.adsl.net.t-com.hr ([89.172.50.42]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Nov 2007 18:25:16 +0000 Received: from ivoras by 89-172-50-42.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Nov 2007 18:25:16 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Tue, 20 Nov 2007 19:24:52 +0100 Lines: 37 Message-ID: References: <47431B75.4040601@chistydom.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF8A26390AAAE1C1552558ADD" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-50-42.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) In-Reply-To: X-Enigmail-Version: 0.95.5 Sender: news Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 18:25:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF8A26390AAAE1C1552558ADD Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Claus Guttesen wrote: > I'm running two DL360 G5 webservers each with two quad-core cpu's. > Each have 8 GB of ram, one is 2 Ghz and the other is 2.33 Ghz. They > run just fine. These two webservers have twice the weight of three > opterons with two dual-core cpu's on our coyote load-balancer. The issue in this thread is not if they are fast, but could they be made faster by shortening sys time :) (btw. what is your sys time under stress?) The systems I reported about are "fast enough" for me, but they are not for the person who started the thread, and I agree that it looks like there could be a problem. --------------enigF8A26390AAAE1C1552558ADD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHQyZ6ldnAQVacBcgRAo5tAKDcnXhvltAil6H8I9PCyKe5c/j9PgCg19/d o81kBf6YWGHlhbloFaYBxe4= =znFb -----END PGP SIGNATURE----- --------------enigF8A26390AAAE1C1552558ADD-- From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 19:03:14 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADB0116A41A; Tue, 20 Nov 2007 19:03:14 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id DD3FD13C469; Tue, 20 Nov 2007 19:03:13 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47432F77.3030606@FreeBSD.org> Date: Tue, 20 Nov 2007 20:03:19 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Alexey Popov References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> <4741A7DA.2050706@chistydom.ru> <4741DA15.9000308@FreeBSD.org> <47429DB8.7040504@chistydom.ru> <4742ADFE.40902@FreeBSD.org> <4742C46A.1060701@chistydom.ru> In-Reply-To: <4742C46A.1060701@chistydom.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Attilio Rao , freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 19:03:14 -0000 Alexey Popov wrote: > Hi > > Kris Kennaway wrote: >>>>>>> CPU states: 9.5% user, 0.0% nice, 82.0% system, 0.5% >>>>>>> interrupt, 8.0% idle >>>>>> A wild idea that might not help: try reducing kern.hz in >>>>>> loader.conf to >>>>>> something like 100 and see if something significant changes. >>> Usually on PHP backends slow PHP code eats most of the CPU time. I >>> have %user much bigger than %system in CPU states. >>> But now %system is much bigger than %user and I can conclude that on >>> 8-core server FreeBSD consumes more CPU time than PHP. >> That is one possibility, but you still need to look at the actual >> throughput on these machines before making conclusions about which is >> performing better. Can you please provide those numbers for 6.x, 7.x >> with ULE and 4BSD on the 4-core and 8-core systems? > Ok, here's results of practical research. The following is approximate > maximum qps that backends can survive with my workload: > > 7-STABLE quad ULE 20 > 7-STABLE quad 4BSD 17 > 6-STABLE quad 14 > 6-STABLE dual 21 > Linux CentOS 5 quad >50 OK, so 7.x is an improvement compared to 6.x on the 8 core machine, and ULE is an improvement over 4BSD. This much is in line with expectations. Neither shows an improvement vs 4 cores. It is hard to say for certain without a direct profile comparison of the workload, but it is probably due to lockmgr contention. lockmgr is used for various locking operations to do with VFS data structures. It is known to have poor performance and scale very badly. It is interesting that you are running into this on a real workload though, so far I have only encountered it as a limiting factor in synthetic microbenchmarks. There was some work done over the summer on replacing lockmgr with something reasonable, but unfortunately it is not yet ready for testing. I am CC'ing the developer who was working on that (Attilio Rao). Depending on his availability it will probably be at least a couple of months before it is ready though. In the meantime there is unfortunately not a lot that can be done, AFAICT. There is one hack that I will send you later but it is not likely to help much. I will also think about how to track down the cause of the contention further (the profiling trace only shows that it comes mostly from vget/vput but doesn't show where these are called from). Kris > > With best regards, > Alexey Popov > > From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 19:47:50 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88A8316A419; Tue, 20 Nov 2007 19:47:50 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id B0A8313C43E; Tue, 20 Nov 2007 19:47:48 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <474339E9.4080301@FreeBSD.org> Date: Tue, 20 Nov 2007 20:47:53 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Kris Kennaway References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> <4741A7DA.2050706@chistydom.ru> <4741DA15.9000308@FreeBSD.org> <47429DB8.7040504@chistydom.ru> <4742ADFE.40902@FreeBSD.org> <4742C46A.1060701@chistydom.ru> <47432F77.3030606@FreeBSD.org> In-Reply-To: <47432F77.3030606@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------030803050501020800060905" Cc: Attilio Rao , freebsd-stable@freebsd.org, Alexey Popov Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 19:47:50 -0000 This is a multi-part message in MIME format. --------------030803050501020800060905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Kris Kennaway wrote: > In the meantime there is unfortunately not a lot that can be done, > AFAICT. There is one hack that I will send you later but it is not > likely to help much. I will also think about how to track down the > cause of the contention further (the profiling trace only shows that it > comes mostly from vget/vput but doesn't show where these are called from). Actually this patch might help. It doesn't replace lockmgr but it does fix a silly thundering herd behaviour. It probably needs some adjustment to get it to apply cleanly (it is about 7 months old), and I apparently stopped using it because I ran into deadlocks. It might be stable enough to at least see how much it helps. Set the vfs.lookup_shared=1 sysctl to enable the other half of the patch. Kris --------------030803050501020800060905 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="lockmgr.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="lockmgr.diff" Change 117289 by kris@kris_xor on 2007/04/03 18:43:03 Rewrite of lockmgr to avoid the silly multiple wakeups. On a microbenchmark designed for high lockmgr contention (80 processes doing 1000 stat() calls of the same file on an 8-core amd64), this reduces system time by 95% and real time by 82%. This was ported from 6.x so support for LOCK_PROFILING is currently removed. Also add a hack to fake up shared lookups on UFS: acquire the lock in shared mode and then upgrade it to exclusive mode. This has a small benefit on my tests, and it is claimed there is a very large benefit in some workloads. Submitted by: ups Affected files ... ... //depot/user/kris/contention/sys/conf/options#10 edit ... //depot/user/kris/contention/sys/kern/kern_lock.c#7 edit ... //depot/user/kris/contention/sys/kern/subr_lock.c#6 edit ... //depot/user/kris/contention/sys/kern/vfs_default.c#4 edit ... //depot/user/kris/contention/sys/sys/lockmgr.h#5 edit ... //depot/user/kris/contention/sys/ufs/ffs/ffs_vfsops.c#6 edit ... //depot/user/kris/contention/sys/ufs/ffs/ffs_vnops.c#6 edit ... //depot/user/kris/contention/sys/ufs/ufs/ufs_lookup.c#4 edit Differences ... ==== //depot/user/kris/contention/sys/conf/options#10 (text+ko) ==== @@ -248,6 +248,9 @@ # Enable gjournal-based UFS journal. UFS_GJOURNAL opt_ufs.h +# Disable shared lookups for UFS +NO_UFS_LOOKUP_SHARED opt_ufs.h + # The below sentence is not in English, and neither is this one. # We plan to remove the static dependences above, with a # _ROOT option to control if it usable as root. This list ==== //depot/user/kris/contention/sys/kern/kern_lock.c#7 (text+ko) ==== @@ -41,10 +41,9 @@ */ #include -__FBSDID("$FreeBSD: src/sys/kern/kern_lock.c,v 1.109 2007/03/30 18:07:24 jhb Exp $"); +__FBSDID("$FreeBSD: src/sys/kern/kern_lock.c,v 1.89.2.5 2006/10/09 20:04:45 tegge Exp $"); #include "opt_ddb.h" -#include "opt_global.h" #include #include @@ -55,52 +54,21 @@ #include #include #include -#include #ifdef DEBUG_LOCKS #include #endif #ifdef DDB #include -static void db_show_lockmgr(struct lock_object *lock); -#endif -static void lock_lockmgr(struct lock_object *lock, int how); -static int unlock_lockmgr(struct lock_object *lock); - -struct lock_class lock_class_lockmgr = { - .lc_name = "lockmgr", - .lc_flags = LC_SLEEPLOCK | LC_SLEEPABLE | LC_RECURSABLE | LC_UPGRADABLE, -#ifdef DDB - .lc_ddb_show = db_show_lockmgr, #endif - .lc_lock = lock_lockmgr, - .lc_unlock = unlock_lockmgr, -}; /* * Locking primitives implementation. * Locks provide shared/exclusive sychronization. */ -void -lock_lockmgr(struct lock_object *lock, int how) -{ - - panic("lockmgr locks do not support sleep interlocking"); -} - -int -unlock_lockmgr(struct lock_object *lock) -{ - - panic("lockmgr locks do not support sleep interlocking"); -} - #define COUNT(td, x) if ((td)) (td)->td_locks += (x) -#define LK_ALL (LK_HAVE_EXCL | LK_WANT_EXCL | LK_WANT_UPGRADE | \ - LK_SHARE_NONZERO | LK_WAIT_NONZERO) -static int acquire(struct lock **lkpp, int extflags, int wanted, int *contested, uint64_t *waittime); static int acquiredrain(struct lock *lkp, int extflags) ; static __inline void @@ -117,60 +85,16 @@ COUNT(td, -decr); if (lkp->lk_sharecount == decr) { - lkp->lk_flags &= ~LK_SHARE_NONZERO; - if (lkp->lk_flags & (LK_WANT_UPGRADE | LK_WANT_EXCL)) { - wakeup(lkp); - } + if (lkp->lk_exclusivewait != 0) + wakeup_one(&lkp->lk_exclusivewait); lkp->lk_sharecount = 0; } else { lkp->lk_sharecount -= decr; + if (lkp->lk_sharecount == 1 && lkp->lk_flags & LK_WANT_UPGRADE) + wakeup(&lkp->lk_flags); } } -static int -acquire(struct lock **lkpp, int extflags, int wanted, int *contested, uint64_t *waittime) -{ - struct lock *lkp = *lkpp; - int error; - CTR3(KTR_LOCK, - "acquire(): lkp == %p, extflags == 0x%x, wanted == 0x%x", - lkp, extflags, wanted); - - if ((extflags & LK_NOWAIT) && (lkp->lk_flags & wanted)) - return EBUSY; - error = 0; - if ((lkp->lk_flags & wanted) != 0) - lock_profile_obtain_lock_failed(&lkp->lk_object, contested, waittime); - - while ((lkp->lk_flags & wanted) != 0) { - CTR2(KTR_LOCK, - "acquire(): lkp == %p, lk_flags == 0x%x sleeping", - lkp, lkp->lk_flags); - lkp->lk_flags |= LK_WAIT_NONZERO; - lkp->lk_waitcount++; - error = msleep(lkp, lkp->lk_interlock, lkp->lk_prio, - lkp->lk_wmesg, - ((extflags & LK_TIMELOCK) ? lkp->lk_timo : 0)); - lkp->lk_waitcount--; - if (lkp->lk_waitcount == 0) - lkp->lk_flags &= ~LK_WAIT_NONZERO; - if (error) - break; - if (extflags & LK_SLEEPFAIL) { - error = ENOLCK; - break; - } - if (lkp->lk_newlock != NULL) { - mtx_lock(lkp->lk_newlock->lk_interlock); - mtx_unlock(lkp->lk_interlock); - if (lkp->lk_waitcount == 0) - wakeup((void *)(&lkp->lk_newlock)); - *lkpp = lkp = lkp->lk_newlock; - } - } - mtx_assert(lkp->lk_interlock, MA_OWNED); - return (error); -} /* * Set, change, or release a lock. @@ -180,16 +104,16 @@ * accepted shared locks and shared-to-exclusive upgrades to go away. */ int -_lockmgr(struct lock *lkp, u_int flags, struct mtx *interlkp, - struct thread *td, char *file, int line) - +lockmgr(lkp, flags, interlkp, td) + struct lock *lkp; + u_int flags; + struct mtx *interlkp; + struct thread *td; { int error; struct thread *thr; - int extflags, lockflags; - int contested = 0; - uint64_t waitstart = 0; - + int extflags; + error = 0; if (td == NULL) thr = LK_KERNPROC; @@ -217,7 +141,7 @@ if ((flags & (LK_NOWAIT|LK_RELEASE)) == 0) WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, - &lkp->lk_interlock->lock_object, + &lkp->lk_interlock->mtx_object, "Acquiring lockmgr lock \"%s\"", lkp->lk_wmesg); if (panicstr != NULL) { @@ -244,16 +168,30 @@ * lock itself ). */ if (lkp->lk_lockholder != thr) { - lockflags = LK_HAVE_EXCL; - if (td != NULL && !(td->td_pflags & TDP_DEADLKTREAT)) - lockflags |= LK_WANT_EXCL | LK_WANT_UPGRADE; - error = acquire(&lkp, extflags, lockflags, &contested, &waitstart); - if (error) + + while (lkp->lk_exclusivecount != 0 /* || + (!(td->td_pflags & TDP_DEADLKTREAT) && + (lkp->lk_flags & LK_WANT_UPGRADE)) */) { + lkp->lk_sharewait++; + error = msleep(&lkp->lk_sharewait, lkp->lk_interlock, + lkp->lk_prio,lkp->lk_wmesg, + ((extflags & LK_TIMELOCK) ? lkp->lk_timo : 0)); + + if (error) + break; + if (extflags & LK_SLEEPFAIL) { + error = ENOLCK; + break; + } + + lkp->lk_sharewait--; + } + + if (error != 0) { + shareunlock(td,lkp,0); break; + } sharelock(td, lkp, 1); - if (lkp->lk_sharecount == 1) - lock_profile_obtain_lock_success(&lkp->lk_object, contested, waitstart, file, line); - #if defined(DEBUG_LOCKS) stack_save(&lkp->lk_stack); #endif @@ -264,8 +202,6 @@ * An alternative would be to fail with EDEADLK. */ sharelock(td, lkp, 1); - if (lkp->lk_sharecount == 1) - lock_profile_obtain_lock_success(&lkp->lk_object, contested, waitstart, file, line); /* FALLTHROUGH downgrade */ case LK_DOWNGRADE: @@ -276,10 +212,9 @@ sharelock(td, lkp, lkp->lk_exclusivecount); COUNT(td, -lkp->lk_exclusivecount); lkp->lk_exclusivecount = 0; - lkp->lk_flags &= ~LK_HAVE_EXCL; lkp->lk_lockholder = LK_NOPROC; - if (lkp->lk_waitcount) - wakeup((void *)lkp); + if (lkp->lk_sharewait) + wakeup((void *)&lkp->lk_sharewait); break; case LK_EXCLUPGRADE: @@ -308,15 +243,13 @@ panic("lockmgr: upgrade exclusive lock"); if (lkp->lk_sharecount <= 0) panic("lockmgr: upgrade without shared"); - shareunlock(td, lkp, 1); - if (lkp->lk_sharecount == 0) - lock_profile_release_lock(&lkp->lk_object); /* * If we are just polling, check to see if we will block. */ if ((extflags & LK_NOWAIT) && ((lkp->lk_flags & LK_WANT_UPGRADE) || lkp->lk_sharecount > 1)) { + shareunlock(td, lkp, 1); error = EBUSY; break; } @@ -327,34 +260,43 @@ * drop to zero, then take exclusive lock. */ lkp->lk_flags |= LK_WANT_UPGRADE; - error = acquire(&lkp, extflags, LK_SHARE_NONZERO, &contested, &waitstart); + + while(lkp->lk_sharecount != 1) { + + error = msleep(&lkp->lk_flags, lkp->lk_interlock, + lkp->lk_prio,lkp->lk_wmesg, + ((extflags & LK_TIMELOCK) ? lkp->lk_timo : 0)); + + if (error) + break; + if (extflags & LK_SLEEPFAIL) { + error = ENOLCK; + break; + } + } + lkp->lk_flags &= ~LK_WANT_UPGRADE; if (error) { - if ((lkp->lk_flags & ( LK_WANT_EXCL | LK_WAIT_NONZERO)) == (LK_WANT_EXCL | LK_WAIT_NONZERO)) - wakeup((void *)lkp); + shareunlock(td, lkp, 1); + if (lkp->lk_sharewait) + wakeup(&lkp->lk_sharewait); break; } + if (lkp->lk_exclusivecount != 0) panic("lockmgr: non-zero exclusive count"); - lkp->lk_flags |= LK_HAVE_EXCL; lkp->lk_lockholder = thr; lkp->lk_exclusivecount = 1; + lkp->lk_sharecount = 0; COUNT(td, 1); - lock_profile_obtain_lock_success(&lkp->lk_object, contested, waitstart, file, line); #if defined(DEBUG_LOCKS) stack_save(&lkp->lk_stack); #endif break; } - /* - * Someone else has requested upgrade. Release our shared - * lock, awaken upgrade requestor if we are the last shared - * lock, then request an exclusive lock. - */ - if ( (lkp->lk_flags & (LK_SHARE_NONZERO|LK_WAIT_NONZERO)) == - LK_WAIT_NONZERO) - wakeup((void *)lkp); + + shareunlock(td, lkp, 1); /* FALLTHROUGH exclusive request */ case LK_EXCLUSIVE: @@ -370,38 +312,52 @@ break; } } - /* - * If we are just polling, check to see if we will sleep. - */ - if ((extflags & LK_NOWAIT) && - (lkp->lk_flags & (LK_HAVE_EXCL | LK_WANT_EXCL | LK_WANT_UPGRADE | LK_SHARE_NONZERO))) { - error = EBUSY; - break; + + + if (lkp->lk_exclusivecount != 0 || lkp->lk_sharecount != 0) { + + + /* + * If we are just polling, check to see if we will sleep. + */ + if (extflags & LK_NOWAIT) { + error = EBUSY; + break; + } + + lkp->lk_exclusivewait++; + + while(lkp->lk_exclusivecount != 0 || lkp->lk_sharecount != 0) { + error = msleep(&lkp->lk_exclusivewait, lkp->lk_interlock, + lkp->lk_prio,lkp->lk_wmesg, + ((extflags & LK_TIMELOCK) ? lkp->lk_timo : 0)); + + if (error) + break; + if (extflags & LK_SLEEPFAIL) { + error = ENOLCK; + break; + } + + } + lkp->lk_exclusivewait--; + + if(error) { + if (lkp->lk_exclusivewait != 0) + wakeup(&lkp->lk_exclusivewait); + else if (lkp->lk_sharewait != 0) + wakeup(&lkp->lk_sharewait); + + break; + } } - /* - * Try to acquire the want_exclusive flag. - */ - error = acquire(&lkp, extflags, (LK_HAVE_EXCL | LK_WANT_EXCL), &contested, &waitstart); - if (error) - break; - lkp->lk_flags |= LK_WANT_EXCL; - /* - * Wait for shared locks and upgrades to finish. - */ - error = acquire(&lkp, extflags, LK_HAVE_EXCL | LK_WANT_UPGRADE | LK_SHARE_NONZERO, &contested, &waitstart); - lkp->lk_flags &= ~LK_WANT_EXCL; - if (error) { - if (lkp->lk_flags & LK_WAIT_NONZERO) - wakeup((void *)lkp); - break; - } - lkp->lk_flags |= LK_HAVE_EXCL; + + lkp->lk_lockholder = thr; if (lkp->lk_exclusivecount != 0) panic("lockmgr: non-zero exclusive count"); lkp->lk_exclusivecount = 1; COUNT(td, 1); - lock_profile_obtain_lock_success(&lkp->lk_object, contested, waitstart, file, line); #if defined(DEBUG_LOCKS) stack_save(&lkp->lk_stack); #endif @@ -418,23 +374,21 @@ if (lkp->lk_lockholder != LK_KERNPROC) COUNT(td, -1); if (lkp->lk_exclusivecount == 1) { - lkp->lk_flags &= ~LK_HAVE_EXCL; lkp->lk_lockholder = LK_NOPROC; lkp->lk_exclusivecount = 0; - lock_profile_release_lock(&lkp->lk_object); + if (lkp->lk_sharewait) + wakeup(&lkp->lk_sharewait); + else if (lkp->lk_exclusivewait) + wakeup_one(&lkp->lk_exclusivewait); } else { lkp->lk_exclusivecount--; } - } else if (lkp->lk_flags & LK_SHARE_NONZERO) + } else if (lkp->lk_sharecount != 0) shareunlock(td, lkp, 1); - else { - printf("lockmgr: thread %p unlocking unheld lock\n", - thr); - kdb_backtrace(); - } - - if (lkp->lk_flags & LK_WAIT_NONZERO) - wakeup((void *)lkp); + else + panic("lockmgr: thread %p, not holding a lock", + thr); + break; case LK_DRAIN: @@ -450,7 +404,7 @@ error = acquiredrain(lkp, extflags); if (error) break; - lkp->lk_flags |= LK_DRAINING | LK_HAVE_EXCL; + lkp->lk_flags |= LK_DRAINING; lkp->lk_lockholder = thr; lkp->lk_exclusivecount = 1; COUNT(td, 1); @@ -466,8 +420,10 @@ /* NOTREACHED */ } if ((lkp->lk_flags & LK_WAITDRAIN) && - (lkp->lk_flags & (LK_HAVE_EXCL | LK_WANT_EXCL | LK_WANT_UPGRADE | - LK_SHARE_NONZERO | LK_WAIT_NONZERO)) == 0) { + (lkp->lk_sharewait == 0) && + (lkp->lk_exclusivewait == 0) && + (lkp->lk_sharecount== 0) && + (lkp->lk_exclusivecount== 0)) { lkp->lk_flags &= ~LK_WAITDRAIN; wakeup((void *)&lkp->lk_flags); } @@ -479,10 +435,14 @@ acquiredrain(struct lock *lkp, int extflags) { int error; - if ((extflags & LK_NOWAIT) && (lkp->lk_flags & LK_ALL)) { - return EBUSY; - } - while (lkp->lk_flags & LK_ALL) { + + while ((lkp->lk_sharecount != 0) || + (lkp->lk_sharewait != 0) || + (lkp->lk_exclusivecount != 0) || + (lkp->lk_exclusivewait != 0)) { + + if (extflags & LK_NOWAIT) return EBUSY; + lkp->lk_flags |= LK_WAITDRAIN; error = msleep(&lkp->lk_flags, lkp->lk_interlock, lkp->lk_prio, lkp->lk_wmesg, @@ -496,34 +456,7 @@ return 0; } -/* - * Transfer any waiting processes from one lock to another. - */ -void -transferlockers(from, to) - struct lock *from; - struct lock *to; -{ - - KASSERT(from != to, ("lock transfer to self")); - KASSERT((from->lk_flags&LK_WAITDRAIN) == 0, ("transfer draining lock")); - mtx_lock(from->lk_interlock); - if (from->lk_waitcount == 0) { - mtx_unlock(from->lk_interlock); - return; - } - from->lk_newlock = to; - wakeup((void *)from); - msleep(&from->lk_newlock, from->lk_interlock, from->lk_prio, - "lkxfer", 0); - from->lk_newlock = NULL; - from->lk_flags &= ~(LK_WANT_EXCL | LK_WANT_UPGRADE); - KASSERT(from->lk_waitcount == 0, ("active lock")); - mtx_unlock(from->lk_interlock); -} - - /* * Initialize a lock; required before use. */ @@ -541,18 +474,16 @@ lkp->lk_interlock = mtx_pool_alloc(mtxpool_lockbuilder); lkp->lk_flags = (flags & LK_EXTFLG_MASK); lkp->lk_sharecount = 0; - lkp->lk_waitcount = 0; + lkp->lk_sharewait = 0; lkp->lk_exclusivecount = 0; + lkp->lk_exclusivewait = 0; lkp->lk_prio = prio; + lkp->lk_wmesg = wmesg; lkp->lk_timo = timo; lkp->lk_lockholder = LK_NOPROC; - lkp->lk_newlock = NULL; #ifdef DEBUG_LOCKS stack_zero(&lkp->lk_stack); #endif - lock_profile_object_init(&lkp->lk_object, &lock_class_lockmgr, wmesg); - lock_init(&lkp->lk_object, &lock_class_lockmgr, wmesg, NULL, - LO_RECURSABLE | LO_SLEEPABLE | LO_UPGRADABLE); } /* @@ -564,8 +495,6 @@ { CTR2(KTR_LOCK, "lockdestroy(): lkp == %p (lk_wmesg == \"%s\")", lkp, lkp->lk_wmesg); - lock_profile_object_destroy(&lkp->lk_object); - lock_destroy(&lkp->lk_object); } /* @@ -606,7 +535,8 @@ int count; mtx_lock(lkp->lk_interlock); - count = lkp->lk_exclusivecount + lkp->lk_sharecount; + count = lkp->lk_exclusivecount + + lkp->lk_sharecount; mtx_unlock(lkp->lk_interlock); return (count); } @@ -621,7 +551,9 @@ int count; mtx_lock(lkp->lk_interlock); - count = lkp->lk_waitcount; + count = lkp->lk_exclusivewait + + lkp->lk_sharewait + + (lkp->lk_flags & LK_WANT_UPGRADE) ? 1 : 0; mtx_unlock(lkp->lk_interlock); return (count); } @@ -638,12 +570,14 @@ if (lkp->lk_sharecount) printf(" lock type %s: SHARED (count %d)", lkp->lk_wmesg, lkp->lk_sharecount); - else if (lkp->lk_flags & LK_HAVE_EXCL) + else if (lkp->lk_exclusivecount) printf(" lock type %s: EXCL (count %d) by thread %p (pid %d)", lkp->lk_wmesg, lkp->lk_exclusivecount, lkp->lk_lockholder, lkp->lk_lockholder->td_proc->p_pid); - if (lkp->lk_waitcount > 0) - printf(" with %d pending", lkp->lk_waitcount); + if (lkp->lk_sharewait > 0) + printf(" with %d pending readers", lkp->lk_sharewait); + if (lkp->lk_exclusivewait > 0) + printf(" with %d pending writers", lkp->lk_exclusivewait); #ifdef DEBUG_LOCKS stack_print(&lkp->lk_stack); #endif @@ -663,24 +597,9 @@ lkp = td->td_wchan; /* Simple test to see if wchan points to a lockmgr lock. */ - if (LOCK_CLASS(&lkp->lk_object) == &lock_class_lockmgr && - lkp->lk_wmesg == td->td_wmesg) - goto ok; - - /* - * If this thread is doing a DRAIN, then it would be asleep on - * &lkp->lk_flags rather than lkp. - */ - lkp = (struct lock *)((char *)td->td_wchan - - offsetof(struct lock, lk_flags)); - if (LOCK_CLASS(&lkp->lk_object) == &lock_class_lockmgr && - lkp->lk_wmesg == td->td_wmesg && (lkp->lk_flags & LK_WAITDRAIN)) - goto ok; + if (lkp->lk_wmesg != td->td_wmesg) + return (0); - /* Doen't seem to be a lockmgr lock. */ - return (0); - -ok: /* Ok, we think we have a lockmgr lock, so output some details. */ db_printf("blocked on lk \"%s\" ", lkp->lk_wmesg); if (lkp->lk_sharecount) { @@ -693,26 +612,29 @@ return (1); } -void -db_show_lockmgr(struct lock_object *lock) +DB_SHOW_COMMAND(lockmgr, db_show_lockmgr) { struct thread *td; struct lock *lkp; - lkp = (struct lock *)lock; + if (!have_addr) + return; + lkp = (struct lock *)addr; - db_printf(" lock type: %s\n", lkp->lk_wmesg); - db_printf(" state: "); + db_printf("lock type: %s\n", lkp->lk_wmesg); + db_printf("state: "); if (lkp->lk_sharecount) db_printf("SHARED (count %d)\n", lkp->lk_sharecount); - else if (lkp->lk_flags & LK_HAVE_EXCL) { + else if (lkp->lk_exclusivecount != 0) { td = lkp->lk_lockholder; db_printf("EXCL (count %d) %p ", lkp->lk_exclusivecount, td); db_printf("(tid %d, pid %d, \"%s\")\n", td->td_tid, td->td_proc->p_pid, td->td_proc->p_comm); } else db_printf("UNLOCKED\n"); - if (lkp->lk_waitcount > 0) - db_printf(" waiters: %d\n", lkp->lk_waitcount); + if (lkp->lk_sharewait > 0) + db_printf("waiters shared: %d\n", lkp->lk_sharewait); + if (lkp->lk_exclusivewait > 0) + db_printf("waiters exclusive: %d\n", lkp->lk_exclusivewait); } #endif ==== //depot/user/kris/contention/sys/kern/subr_lock.c#6 (text+ko) ==== @@ -58,7 +58,6 @@ &lock_class_mtx_sleep, &lock_class_sx, &lock_class_rw, - &lock_class_lockmgr, }; #ifdef LOCK_PROFILING ==== //depot/user/kris/contention/sys/kern/vfs_default.c#4 (text+ko) ==== @@ -263,7 +263,7 @@ { struct vnode *vp = ap->a_vp; - return (_lockmgr(vp->v_vnlock, ap->a_flags, VI_MTX(vp), ap->a_td, ap->a_file, ap->a_line)); + return (lockmgr(vp->v_vnlock, ap->a_flags, VI_MTX(vp), ap->a_td)); } /* See above. */ ==== //depot/user/kris/contention/sys/sys/lockmgr.h#5 (text+ko) ==== @@ -31,7 +31,7 @@ * SUCH DAMAGE. * * @(#)lock.h 8.12 (Berkeley) 5/19/95 - * $FreeBSD: src/sys/sys/lockmgr.h,v 1.53 2007/03/30 18:07:24 jhb Exp $ + * $FreeBSD: src/sys/sys/lockmgr.h,v 1.47.2.3 2006/10/09 20:04:46 tegge Exp $ */ #ifndef _SYS_LOCKMGR_H_ @@ -40,8 +40,6 @@ #ifdef DEBUG_LOCKS #include /* XXX */ #endif -#include -#include struct mtx; @@ -51,23 +49,22 @@ * can be gained. */ struct lock { - struct lock_object lk_object; /* common lock properties */ struct mtx *lk_interlock; /* lock on remaining fields */ u_int lk_flags; /* see below */ int lk_sharecount; /* # of accepted shared locks */ - int lk_waitcount; /* # of processes sleeping for lock */ - short lk_exclusivecount; /* # of recursive exclusive locks */ + int lk_sharewait; /* # waiting for shared locks */ + int lk_exclusivecount; /* # of recursive exclusive locks */ + int lk_exclusivewait; /* # of recursive exclusive locks */ + short lk_prio; /* priority at which to sleep */ + const char *lk_wmesg; /* resource sleeping (for tsleep) */ int lk_timo; /* maximum sleep time (for tsleep) */ struct thread *lk_lockholder; /* thread of exclusive lock holder */ - struct lock *lk_newlock; /* lock taking over this lock */ - + #ifdef DEBUG_LOCKS struct stack lk_stack; #endif }; - -#define lk_wmesg lk_object.lo_name /* * Lock request types: * LK_SHARED - get one of many possible shared locks. If a process @@ -202,15 +199,13 @@ int timo, int flags); void lockdestroy(struct lock *); -int _lockmgr(struct lock *, u_int flags, - struct mtx *, struct thread *p, char *file, int line); +int lockmgr(struct lock *, u_int flags, + struct mtx *, struct thread *p); void transferlockers(struct lock *, struct lock *); void lockmgr_printinfo(struct lock *); int lockstatus(struct lock *, struct thread *); int lockcount(struct lock *); int lockwaiters(struct lock *); - -#define lockmgr(lock, flags, mtx, td) _lockmgr((lock), (flags), (mtx), (td), __FILE__, __LINE__) #ifdef DDB int lockmgr_chain(struct thread *td, struct thread **ownerp); #endif ==== //depot/user/kris/contention/sys/ufs/ffs/ffs_vfsops.c#6 (text+ko) ==== @@ -881,6 +881,9 @@ #endif /* !UFS_EXTATTR_AUTOSTART */ #endif /* !UFS_EXTATTR */ MNT_ILOCK(mp); +#ifndef NO_UFS_LOOKUP_SHARED + mp->mnt_kern_flag |= MNTK_LOOKUP_SHARED; +#endif mp->mnt_kern_flag |= MNTK_MPSAFE; MNT_IUNLOCK(mp); return (0); ==== //depot/user/kris/contention/sys/ufs/ffs/ffs_vnops.c#6 (text+ko) ==== @@ -370,7 +370,7 @@ flags |= LK_INTERLOCK; } lkp = vp->v_vnlock; - result = _lockmgr(lkp, flags, VI_MTX(vp), ap->a_td, ap->a_file, ap->a_line); + result = lockmgr(lkp, flags, VI_MTX(vp), ap->a_td); if (lkp == vp->v_vnlock || result != 0) break; /* @@ -381,7 +381,7 @@ * right lock. Release it, and try to get the * new lock. */ - (void) _lockmgr(lkp, LK_RELEASE, VI_MTX(vp), ap->a_td, ap->a_file, ap->a_line); + (void) lockmgr(lkp, LK_RELEASE, VI_MTX(vp), ap->a_td); if ((flags & LK_TYPE_MASK) == LK_UPGRADE) flags = (flags & ~LK_TYPE_MASK) | LK_EXCLUSIVE; flags &= ~LK_INTERLOCK; ==== //depot/user/kris/contention/sys/ufs/ufs/ufs_lookup.c#4 (text+ko) ==== @@ -166,6 +166,14 @@ vdp = ap->a_dvp; dp = VTOI(vdp); + +#ifndef NO_UFS_LOOKUP_SHARED + if ((vdp->v_mount->mnt_kern_flag & MNTK_LOOKUP_SHARED) && + (VOP_ISLOCKED(vdp, td) != LK_EXCLUSIVE)) { + /* Upgrade to exclusive lock, this might block */ + VOP_LOCK(vdp, LK_UPGRADE, td); + } +#endif /* * We now have a segment name to search for, and a directory to search. * --------------030803050501020800060905-- From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 20:47:21 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCE8316A417 for ; Tue, 20 Nov 2007 20:47:21 +0000 (UTC) (envelope-from andpet@telia.com) Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by mx1.freebsd.org (Postfix) with ESMTP id A74B013C457 for ; Tue, 20 Nov 2007 20:47:21 +0000 (UTC) (envelope-from andpet@telia.com) Received: from [192.168.1.20] (81.233.14.209) by pne-smtpout2-sn2.hy.skanova.net (7.3.129) (authenticated as u30405151) id 471A89B9008EFB11 for freebsd-stable@freebsd.org; Tue, 20 Nov 2007 20:37:23 +0100 Message-ID: <4743377F.4070402@telia.com> Date: Tue, 20 Nov 2007 20:37:35 +0100 From: Andreas Pettersson User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Lots of tcp in alias.log X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 20:47:21 -0000 Hi all. I have a problem with natd, I think. I'm using FreeBSD 6.2 as a router/proxy at home. Sometimes (weeks apart) I've noticed that it's quite impossible to surf. Connections timeout. A continuous ping from the router to an outside address reveals a packet loss of more than 50%. After some time it starts working again. When it happened again this weekend I took a peek into /var/log/alias.log: icmp=2, udp=169, tcp=26806, pptp=0, proto=0, frag_id=0 frag_ptr=0 / tot=26979 (sock=0) When I restarted natd the tcp value went back at "normal" (cruising around 150-200) and surfing worked fine. Right now I have a value of 24171 but everything seems to work fine so far. A tcpdump on the external interface reveals no unusual traffic and everything low volume. # netstat | grep -c tcp4 14 1. Does anyone know what might make the tcp value climb through the roof? I only have 2 machines on my internal network. 2. If there are some kind of tcp connection flood initiating from an inside machine, shouldn't the tcp aliases get purged after some time? Since there aren't any timestamps in alias.log it is difficult to search for clues. I had a quick look at alias_db.c but I'm no C programmer.. A more detailed log of created aliases (src ip, port etc) would be helpful. Thanks for any help. -- Andreas From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 21:09:59 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A487416A41A for ; Tue, 20 Nov 2007 21:09:59 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from gidgate.gid.co.uk (gid.co.uk [194.32.164.225]) by mx1.freebsd.org (Postfix) with ESMTP id 49FC413C468 for ; Tue, 20 Nov 2007 21:09:58 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from [194.32.164.30] (host-83-146-60-88.bulldogdsl.com [83.146.60.88]) by gidgate.gid.co.uk (8.13.8/8.13.8) with ESMTP id lAKL9tPI057407; Tue, 20 Nov 2007 21:09:56 GMT (envelope-from rb@gid.co.uk) In-Reply-To: <47432F77.3030606@FreeBSD.org> References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> <4741A7DA.2050706@chistydom.ru> <4741DA15.9000308@FreeBSD.org> <47429DB8.7040504@chistydom.ru> <4742ADFE.40902@FreeBSD.org> <4742C46A.1060701@chistydom.ru> <47432F77.3030606@FreeBSD.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <97FEA818-B54F-4981-A0A4-440D1DF5AB7A@gid.co.uk> Content-Transfer-Encoding: 7bit From: Bob Bishop Date: Tue, 20 Nov 2007 21:09:53 +0000 To: Kris Kennaway X-Mailer: Apple Mail (2.752.3) Cc: Attilio Rao , freebsd-stable@freebsd.org, Alexey Popov Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 21:09:59 -0000 Hi, FWIW, we are seeing 2 x quad-core 2.66GHz outperform (per core) 2 x dual-core 3GHz on the same type of m/b, apparently because of better bandwidth to memory. However, this is on a compute-intensive workload running 1 job per core so would be pretty insensitive to scheduler/ locking issues. -- Bob Bishop +44 (0)118 940 1243 rb@gid.co.uk fax +44 (0)118 940 1295 From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 21:13:32 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EC7A16A420; Tue, 20 Nov 2007 21:13:32 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id 1B4FD13C447; Tue, 20 Nov 2007 21:13:30 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47434E01.8020004@FreeBSD.org> Date: Tue, 20 Nov 2007 22:13:37 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Bob Bishop References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> <4741A7DA.2050706@chistydom.ru> <4741DA15.9000308@FreeBSD.org> <47429DB8.7040504@chistydom.ru> <4742ADFE.40902@FreeBSD.org> <4742C46A.1060701@chistydom.ru> <47432F77.3030606@FreeBSD.org> <97FEA818-B54F-4981-A0A4-440D1DF5AB7A@gid.co.uk> In-Reply-To: <97FEA818-B54F-4981-A0A4-440D1DF5AB7A@gid.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Attilio Rao , freebsd-stable@freebsd.org, Alexey Popov Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 21:13:32 -0000 Bob Bishop wrote: > Hi, > > FWIW, we are seeing 2 x quad-core 2.66GHz outperform (per core) 2 x > dual-core 3GHz on the same type of m/b, apparently because of better > bandwidth to memory. However, this is on a compute-intensive workload > running 1 job per core so would be pretty insensitive to > scheduler/locking issues. Alexey's problem is pretty specific to filesystem performance. Good to hear though :) Kris From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 21:22:44 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1581C16A419 for ; Tue, 20 Nov 2007 21:22:44 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.freebsd.org (Postfix) with ESMTP id A7CE713C459 for ; Tue, 20 Nov 2007 21:22:43 +0000 (UTC) (envelope-from kometen@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so1919981nfb for ; Tue, 20 Nov 2007 13:22:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=4atVC6C60BmzTQ0twrLwVKTw+DRFg/+HiF7wFu+peGI=; b=KS1j/+FHXjjilwGYbN2UNTXwvZv8CwgZOow7xXbhTskwRRo0acNpOxZPZ+dVk5wNd/rW/yehFLzsNmskrHyn8BFW6DA3fx/TI6b7UTfHT7WPGCEq13c5ue5lS6q0M7WjT8gB/AANwWGMxUC7pYN14/OMkgsZM3RuaYS6MLbum9k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=n+HYFHcxaSj1YXlf6C6rw9wzWv8/Td0MlGHl4+rMnF7PDJ904jZCs1Ge8RE6rI6uWrCL0OgSepWwYjWkhKlDT+lYrBdCyybEzs6P4siZry2aDKFKJr/wIIsl0syPyRlgLFwGlM8bChS8U+EubRjEyalw+H4Qt5GoyH0KRsCP3oY= Received: by 10.78.118.5 with SMTP id q5mr7391205huc.1195593762070; Tue, 20 Nov 2007 13:22:42 -0800 (PST) Received: by 10.78.161.3 with HTTP; Tue, 20 Nov 2007 13:22:41 -0800 (PST) Message-ID: Date: Tue, 20 Nov 2007 22:22:41 +0100 From: "Claus Guttesen" To: "Kris Kennaway" In-Reply-To: <47434E01.8020004@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4741905E.8050300@chistydom.ru> <4741A7DA.2050706@chistydom.ru> <4741DA15.9000308@FreeBSD.org> <47429DB8.7040504@chistydom.ru> <4742ADFE.40902@FreeBSD.org> <4742C46A.1060701@chistydom.ru> <47432F77.3030606@FreeBSD.org> <97FEA818-B54F-4981-A0A4-440D1DF5AB7A@gid.co.uk> <47434E01.8020004@FreeBSD.org> Cc: Attilio Rao , freebsd-stable@freebsd.org, Alexey Popov Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 21:22:44 -0000 > > FWIW, we are seeing 2 x quad-core 2.66GHz outperform (per core) 2 x > > dual-core 3GHz on the same type of m/b, apparently because of better > > bandwidth to memory. However, this is on a compute-intensive workload > > running 1 job per core so would be pretty insensitive to > > scheduler/locking issues. > > Alexey's problem is pretty specific to filesystem performance. Good to > hear though :) If that is the conclusion, wouldn't it make sense trying a different disk-controller then? -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 21:33:32 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B4DF16A468; Tue, 20 Nov 2007 21:33:32 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id 35A9A13C448; Tue, 20 Nov 2007 21:33:31 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <474352B1.2010108@FreeBSD.org> Date: Tue, 20 Nov 2007 22:33:37 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Claus Guttesen References: <4741905E.8050300@chistydom.ru> <4741A7DA.2050706@chistydom.ru> <4741DA15.9000308@FreeBSD.org> <47429DB8.7040504@chistydom.ru> <4742ADFE.40902@FreeBSD.org> <4742C46A.1060701@chistydom.ru> <47432F77.3030606@FreeBSD.org> <97FEA818-B54F-4981-A0A4-440D1DF5AB7A@gid.co.uk> <47434E01.8020004@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Attilio Rao , freebsd-stable@freebsd.org, Alexey Popov Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 21:33:32 -0000 Claus Guttesen wrote: >>> FWIW, we are seeing 2 x quad-core 2.66GHz outperform (per core) 2 x >>> dual-core 3GHz on the same type of m/b, apparently because of better >>> bandwidth to memory. However, this is on a compute-intensive workload >>> running 1 job per core so would be pretty insensitive to >>> scheduler/locking issues. >> Alexey's problem is pretty specific to filesystem performance. Good to >> hear though :) > > If that is the conclusion, wouldn't it make sense trying a different > disk-controller then? Filesystem, not disk. See my earlier email for more detailed discussion. Kris From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 21:35:07 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D32D316A46D for ; Tue, 20 Nov 2007 21:35:07 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.235]) by mx1.freebsd.org (Postfix) with ESMTP id 9CCB313C47E for ; Tue, 20 Nov 2007 21:35:06 +0000 (UTC) (envelope-from kometen@gmail.com) Received: by wr-out-0506.google.com with SMTP id 68so998167wra for ; Tue, 20 Nov 2007 13:35:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=D2PCQXkmrdW2tIHJJKeMqyRqQEosCoaIsD7KH6rFuqo=; b=tlK+Alv3YpmANUfffQyR+azyjoG9aupz8xVeUwrY/p/cmnwlPRd00p4t/wh0tMl2C5NJq1Y24XMfFiyqe8EVj4yRJ2TLipmItwFNfNRBPsos0w4KMmCNbW2oHfn6SNatnIZNyrZNt19QUTKxuspmcD9g/hbzpnaQELLp5IvPYBw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=eeSDVSrigitLvYxGOe9RUY/su+Qv1xyEmQqC4RIsiu6wfbA1KlyB6oXX7uJD25yLYmVmyGglJnxF7VyOSLb7YcL003PL7zIHnbMozCuDylAdHgs3ePB1au9tPPUY4a0fKEeoA65RT7gFP2V8HLdwuGoSCozDSXxVi2GpWFFU5+Y= Received: by 10.78.168.1 with SMTP id q1mr7350118hue.1195594505004; Tue, 20 Nov 2007 13:35:05 -0800 (PST) Received: by 10.78.161.3 with HTTP; Tue, 20 Nov 2007 13:35:04 -0800 (PST) Message-ID: Date: Tue, 20 Nov 2007 22:35:04 +0100 From: "Claus Guttesen" To: "Ivan Voras" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47431B75.4040601@chistydom.ru> Cc: freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 21:35:07 -0000 > The issue in this thread is not if they are fast, but could they be made > faster by shortening sys time :) Yes, I'm aware of that. :-) The comment was related to the former mail where some uncertainty came along when he read this thread. > (btw. what is your sys time under stress?) I'll take a look on sunday. That is our busiest day (evening). -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 22:41:26 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C72416A420; Tue, 20 Nov 2007 22:41:26 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id 4644D13C45D; Tue, 20 Nov 2007 22:41:25 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <4743629B.9090408@FreeBSD.org> Date: Tue, 20 Nov 2007 23:41:31 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Kris Kennaway References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> <4741A7DA.2050706@chistydom.ru> <4741DA15.9000308@FreeBSD.org> <47429DB8.7040504@chistydom.ru> <4742ADFE.40902@FreeBSD.org> <4742C46A.1060701@chistydom.ru> <47432F77.3030606@FreeBSD.org> <474339E9.4080301@FreeBSD.org> In-Reply-To: <474339E9.4080301@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------090206040000020400040605" Cc: Attilio Rao , freebsd-stable@freebsd.org, Alexey Popov Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 22:41:26 -0000 This is a multi-part message in MIME format. --------------090206040000020400040605 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Kris Kennaway wrote: > Kris Kennaway wrote: >> In the meantime there is unfortunately not a lot that can be done, >> AFAICT. There is one hack that I will send you later but it is not >> likely to help much. I will also think about how to track down the >> cause of the contention further (the profiling trace only shows that >> it comes mostly from vget/vput but doesn't show where these are called >> from). > > Actually this patch might help. It doesn't replace lockmgr but it does > fix a silly thundering herd behaviour. It probably needs some > adjustment to get it to apply cleanly (it is about 7 months old), and I > apparently stopped using it because I ran into deadlocks. It might be > stable enough to at least see how much it helps. > > Set the vfs.lookup_shared=1 sysctl to enable the other half of the patch. > > Kris > Try this one instead, it applies to HEAD. You'll need to manually enter the paths though because of how p4 mangles diffs. Kris --------------090206040000020400040605 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="lockmgr.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="lockmgr.diff" ==== //depot/user/kris/contention/sys/kern/kern_lock.c#10 - /zoo/kris/contention/kern/kern_lock.c ==== @@ -109,7 +109,6 @@ #define LK_ALL (LK_HAVE_EXCL | LK_WANT_EXCL | LK_WANT_UPGRADE | \ LK_SHARE_NONZERO | LK_WAIT_NONZERO) -static int acquire(struct lock **lkpp, int extflags, int wanted, int *contested, uint64_t *waittime); static int acquiredrain(struct lock *lkp, int extflags) ; static __inline void @@ -126,61 +125,17 @@ COUNT(td, -decr); if (lkp->lk_sharecount == decr) { - lkp->lk_flags &= ~LK_SHARE_NONZERO; - if (lkp->lk_flags & (LK_WANT_UPGRADE | LK_WANT_EXCL)) { - wakeup(lkp); - } + if (lkp->lk_exclusivewait != 0) + wakeup_one(&lkp->lk_exclusivewait); lkp->lk_sharecount = 0; } else { lkp->lk_sharecount -= decr; + if (lkp->lk_sharecount == 1 && lkp->lk_flags & LK_WANT_UPGRADE) + wakeup(&lkp->lk_flags); } } -static int -acquire(struct lock **lkpp, int extflags, int wanted, int *contested, uint64_t *waittime) -{ - struct lock *lkp = *lkpp; - int error; - CTR3(KTR_LOCK, - "acquire(): lkp == %p, extflags == 0x%x, wanted == 0x%x", - lkp, extflags, wanted); - if ((extflags & LK_NOWAIT) && (lkp->lk_flags & wanted)) - return EBUSY; - error = 0; - if ((lkp->lk_flags & wanted) != 0) - lock_profile_obtain_lock_failed(&lkp->lk_object, contested, waittime); - - while ((lkp->lk_flags & wanted) != 0) { - CTR2(KTR_LOCK, - "acquire(): lkp == %p, lk_flags == 0x%x sleeping", - lkp, lkp->lk_flags); - lkp->lk_flags |= LK_WAIT_NONZERO; - lkp->lk_waitcount++; - error = msleep(lkp, lkp->lk_interlock, lkp->lk_prio, - lkp->lk_wmesg, - ((extflags & LK_TIMELOCK) ? lkp->lk_timo : 0)); - lkp->lk_waitcount--; - if (lkp->lk_waitcount == 0) - lkp->lk_flags &= ~LK_WAIT_NONZERO; - if (error) - break; - if (extflags & LK_SLEEPFAIL) { - error = ENOLCK; - break; - } - if (lkp->lk_newlock != NULL) { - mtx_lock(lkp->lk_newlock->lk_interlock); - mtx_unlock(lkp->lk_interlock); - if (lkp->lk_waitcount == 0) - wakeup((void *)(&lkp->lk_newlock)); - *lkpp = lkp = lkp->lk_newlock; - } - } - mtx_assert(lkp->lk_interlock, MA_OWNED); - return (error); -} - /* * Set, change, or release a lock. * @@ -189,16 +144,16 @@ * accepted shared locks and shared-to-exclusive upgrades to go away. */ int -_lockmgr(struct lock *lkp, u_int flags, struct mtx *interlkp, - struct thread *td, char *file, int line) - +lockmgr(lkp, flags, interlkp, td) + struct lock *lkp; + u_int flags; + struct mtx *interlkp; + struct thread *td; { int error; struct thread *thr; - int extflags, lockflags; - int contested = 0; - uint64_t waitstart = 0; - + int extflags; + error = 0; if (td == NULL) thr = LK_KERNPROC; @@ -226,7 +181,7 @@ if ((flags & (LK_NOWAIT|LK_RELEASE)) == 0) WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, - &lkp->lk_interlock->lock_object, + &lkp->lk_interlock->mtx_object, "Acquiring lockmgr lock \"%s\"", lkp->lk_wmesg); if (panicstr != NULL) { @@ -253,16 +208,30 @@ * lock itself ). */ if (lkp->lk_lockholder != thr) { - lockflags = LK_HAVE_EXCL; - if (td != NULL && !(td->td_pflags & TDP_DEADLKTREAT)) - lockflags |= LK_WANT_EXCL | LK_WANT_UPGRADE; - error = acquire(&lkp, extflags, lockflags, &contested, &waitstart); - if (error) + + while (lkp->lk_exclusivecount != 0 /* || + (!(td->td_pflags & TDP_DEADLKTREAT) && + (lkp->lk_flags & LK_WANT_UPGRADE)) */) { + lkp->lk_sharewait++; + error = msleep(&lkp->lk_sharewait, lkp->lk_interlock, + lkp->lk_prio,lkp->lk_wmesg, + ((extflags & LK_TIMELOCK) ? lkp->lk_timo : 0)); + + if (error) + break; + if (extflags & LK_SLEEPFAIL) { + error = ENOLCK; + break; + } + + lkp->lk_sharewait--; + } + + if (error != 0) { + shareunlock(td,lkp,0); break; + } sharelock(td, lkp, 1); - if (lkp->lk_sharecount == 1) - lock_profile_obtain_lock_success(&lkp->lk_object, contested, waitstart, file, line); - #if defined(DEBUG_LOCKS) stack_save(&lkp->lk_stack); #endif @@ -273,8 +242,6 @@ * An alternative would be to fail with EDEADLK. */ sharelock(td, lkp, 1); - if (lkp->lk_sharecount == 1) - lock_profile_obtain_lock_success(&lkp->lk_object, contested, waitstart, file, line); /* FALLTHROUGH downgrade */ case LK_DOWNGRADE: @@ -285,10 +252,9 @@ sharelock(td, lkp, lkp->lk_exclusivecount); COUNT(td, -lkp->lk_exclusivecount); lkp->lk_exclusivecount = 0; - lkp->lk_flags &= ~LK_HAVE_EXCL; lkp->lk_lockholder = LK_NOPROC; - if (lkp->lk_waitcount) - wakeup((void *)lkp); + if (lkp->lk_sharewait) + wakeup((void *)&lkp->lk_sharewait); break; case LK_EXCLUPGRADE: @@ -317,15 +283,13 @@ panic("lockmgr: upgrade exclusive lock"); if (lkp->lk_sharecount <= 0) panic("lockmgr: upgrade without shared"); - shareunlock(td, lkp, 1); - if (lkp->lk_sharecount == 0) - lock_profile_release_lock(&lkp->lk_object); /* * If we are just polling, check to see if we will block. */ if ((extflags & LK_NOWAIT) && ((lkp->lk_flags & LK_WANT_UPGRADE) || lkp->lk_sharecount > 1)) { + shareunlock(td, lkp, 1); error = EBUSY; break; } @@ -336,34 +300,43 @@ * drop to zero, then take exclusive lock. */ lkp->lk_flags |= LK_WANT_UPGRADE; - error = acquire(&lkp, extflags, LK_SHARE_NONZERO, &contested, &waitstart); + + while(lkp->lk_sharecount != 1) { + + error = msleep(&lkp->lk_flags, lkp->lk_interlock, + lkp->lk_prio,lkp->lk_wmesg, + ((extflags & LK_TIMELOCK) ? lkp->lk_timo : 0)); + + if (error) + break; + if (extflags & LK_SLEEPFAIL) { + error = ENOLCK; + break; + } + } + lkp->lk_flags &= ~LK_WANT_UPGRADE; if (error) { - if ((lkp->lk_flags & ( LK_WANT_EXCL | LK_WAIT_NONZERO)) == (LK_WANT_EXCL | LK_WAIT_NONZERO)) - wakeup((void *)lkp); + shareunlock(td, lkp, 1); + if (lkp->lk_sharewait) + wakeup(&lkp->lk_sharewait); break; } + if (lkp->lk_exclusivecount != 0) panic("lockmgr: non-zero exclusive count"); - lkp->lk_flags |= LK_HAVE_EXCL; lkp->lk_lockholder = thr; lkp->lk_exclusivecount = 1; + lkp->lk_sharecount = 0; COUNT(td, 1); - lock_profile_obtain_lock_success(&lkp->lk_object, contested, waitstart, file, line); #if defined(DEBUG_LOCKS) stack_save(&lkp->lk_stack); #endif break; } - /* - * Someone else has requested upgrade. Release our shared - * lock, awaken upgrade requestor if we are the last shared - * lock, then request an exclusive lock. - */ - if ( (lkp->lk_flags & (LK_SHARE_NONZERO|LK_WAIT_NONZERO)) == - LK_WAIT_NONZERO) - wakeup((void *)lkp); + + shareunlock(td, lkp, 1); /* FALLTHROUGH exclusive request */ case LK_EXCLUSIVE: @@ -379,38 +352,52 @@ break; } } - /* - * If we are just polling, check to see if we will sleep. - */ - if ((extflags & LK_NOWAIT) && - (lkp->lk_flags & (LK_HAVE_EXCL | LK_WANT_EXCL | LK_WANT_UPGRADE | LK_SHARE_NONZERO))) { - error = EBUSY; - break; + + + if (lkp->lk_exclusivecount != 0 || lkp->lk_sharecount != 0) { + + + /* + * If we are just polling, check to see if we will sleep. + */ + if (extflags & LK_NOWAIT) { + error = EBUSY; + break; + } + + lkp->lk_exclusivewait++; + + while(lkp->lk_exclusivecount != 0 || lkp->lk_sharecount != 0) { + error = msleep(&lkp->lk_exclusivewait, lkp->lk_interlock, + lkp->lk_prio,lkp->lk_wmesg, + ((extflags & LK_TIMELOCK) ? lkp->lk_timo : 0)); + + if (error) + break; + if (extflags & LK_SLEEPFAIL) { + error = ENOLCK; + break; + } + + } + lkp->lk_exclusivewait--; + + if(error) { + if (lkp->lk_exclusivewait != 0) + wakeup(&lkp->lk_exclusivewait); + else if (lkp->lk_sharewait != 0) + wakeup(&lkp->lk_sharewait); + + break; + } } - /* - * Try to acquire the want_exclusive flag. - */ - error = acquire(&lkp, extflags, (LK_HAVE_EXCL | LK_WANT_EXCL), &contested, &waitstart); - if (error) - break; - lkp->lk_flags |= LK_WANT_EXCL; - /* - * Wait for shared locks and upgrades to finish. - */ - error = acquire(&lkp, extflags, LK_HAVE_EXCL | LK_WANT_UPGRADE | LK_SHARE_NONZERO, &contested, &waitstart); - lkp->lk_flags &= ~LK_WANT_EXCL; - if (error) { - if (lkp->lk_flags & LK_WAIT_NONZERO) - wakeup((void *)lkp); - break; - } - lkp->lk_flags |= LK_HAVE_EXCL; + + lkp->lk_lockholder = thr; if (lkp->lk_exclusivecount != 0) panic("lockmgr: non-zero exclusive count"); lkp->lk_exclusivecount = 1; COUNT(td, 1); - lock_profile_obtain_lock_success(&lkp->lk_object, contested, waitstart, file, line); #if defined(DEBUG_LOCKS) stack_save(&lkp->lk_stack); #endif @@ -427,23 +414,21 @@ if (lkp->lk_lockholder != LK_KERNPROC) COUNT(td, -1); if (lkp->lk_exclusivecount == 1) { - lkp->lk_flags &= ~LK_HAVE_EXCL; lkp->lk_lockholder = LK_NOPROC; lkp->lk_exclusivecount = 0; - lock_profile_release_lock(&lkp->lk_object); + if (lkp->lk_sharewait) + wakeup(&lkp->lk_sharewait); + else if (lkp->lk_exclusivewait) + wakeup_one(&lkp->lk_exclusivewait); } else { lkp->lk_exclusivecount--; } - } else if (lkp->lk_flags & LK_SHARE_NONZERO) + } else if (lkp->lk_sharecount != 0) shareunlock(td, lkp, 1); - else { - printf("lockmgr: thread %p unlocking unheld lock\n", - thr); - kdb_backtrace(); - } - - if (lkp->lk_flags & LK_WAIT_NONZERO) - wakeup((void *)lkp); + else + panic("lockmgr: thread %p, not holding a lock", + thr); + break; case LK_DRAIN: @@ -459,7 +444,7 @@ error = acquiredrain(lkp, extflags); if (error) break; - lkp->lk_flags |= LK_DRAINING | LK_HAVE_EXCL; + lkp->lk_flags |= LK_DRAINING; lkp->lk_lockholder = thr; lkp->lk_exclusivecount = 1; COUNT(td, 1); @@ -475,8 +460,10 @@ /* NOTREACHED */ } if ((lkp->lk_flags & LK_WAITDRAIN) && - (lkp->lk_flags & (LK_HAVE_EXCL | LK_WANT_EXCL | LK_WANT_UPGRADE | - LK_SHARE_NONZERO | LK_WAIT_NONZERO)) == 0) { + (lkp->lk_sharewait == 0) && + (lkp->lk_exclusivewait == 0) && + (lkp->lk_sharecount== 0) && + (lkp->lk_exclusivecount== 0)) { lkp->lk_flags &= ~LK_WAITDRAIN; wakeup((void *)&lkp->lk_flags); } @@ -488,10 +475,14 @@ acquiredrain(struct lock *lkp, int extflags) { int error; - if ((extflags & LK_NOWAIT) && (lkp->lk_flags & LK_ALL)) { - return EBUSY; - } - while (lkp->lk_flags & LK_ALL) { + + while ((lkp->lk_sharecount != 0) || + (lkp->lk_sharewait != 0) || + (lkp->lk_exclusivecount != 0) || + (lkp->lk_exclusivewait != 0)) { + + if (extflags & LK_NOWAIT) return EBUSY; + lkp->lk_flags |= LK_WAITDRAIN; error = msleep(&lkp->lk_flags, lkp->lk_interlock, lkp->lk_prio, lkp->lk_wmesg, @@ -505,34 +496,7 @@ return 0; } -/* - * Transfer any waiting processes from one lock to another. - */ -void -transferlockers(from, to) - struct lock *from; - struct lock *to; -{ - KASSERT(from != to, ("lock transfer to self")); - KASSERT((from->lk_flags&LK_WAITDRAIN) == 0, ("transfer draining lock")); - - mtx_lock(from->lk_interlock); - if (from->lk_waitcount == 0) { - mtx_unlock(from->lk_interlock); - return; - } - from->lk_newlock = to; - wakeup((void *)from); - msleep(&from->lk_newlock, from->lk_interlock, from->lk_prio, - "lkxfer", 0); - from->lk_newlock = NULL; - from->lk_flags &= ~(LK_WANT_EXCL | LK_WANT_UPGRADE); - KASSERT(from->lk_waitcount == 0, ("active lock")); - mtx_unlock(from->lk_interlock); -} - - /* * Initialize a lock; required before use. */ @@ -550,12 +514,13 @@ lkp->lk_interlock = mtx_pool_alloc(mtxpool_lockbuilder); lkp->lk_flags = (flags & LK_EXTFLG_MASK); lkp->lk_sharecount = 0; - lkp->lk_waitcount = 0; + lkp->lk_sharewait = 0; lkp->lk_exclusivecount = 0; + lkp->lk_exclusivewait = 0; lkp->lk_prio = prio; lkp->lk_timo = timo; + lkp->lk_wmesg = wmesg; lkp->lk_lockholder = LK_NOPROC; - lkp->lk_newlock = NULL; #ifdef DEBUG_LOCKS stack_zero(&lkp->lk_stack); #endif @@ -614,7 +579,8 @@ int count; mtx_lock(lkp->lk_interlock); - count = lkp->lk_exclusivecount + lkp->lk_sharecount; + count = lkp->lk_exclusivecount + + lkp->lk_sharecount; mtx_unlock(lkp->lk_interlock); return (count); } @@ -629,7 +595,9 @@ int count; mtx_lock(lkp->lk_interlock); - count = lkp->lk_waitcount; + count = lkp->lk_exclusivewait + + lkp->lk_sharewait + + (lkp->lk_flags & LK_WANT_UPGRADE) ? 1 : 0; mtx_unlock(lkp->lk_interlock); return (count); } @@ -646,12 +614,14 @@ if (lkp->lk_sharecount) printf(" lock type %s: SHARED (count %d)", lkp->lk_wmesg, lkp->lk_sharecount); - else if (lkp->lk_flags & LK_HAVE_EXCL) + else if (lkp->lk_exclusivecount) printf(" lock type %s: EXCL (count %d) by thread %p (pid %d)", lkp->lk_wmesg, lkp->lk_exclusivecount, lkp->lk_lockholder, lkp->lk_lockholder->td_proc->p_pid); - if (lkp->lk_waitcount > 0) - printf(" with %d pending", lkp->lk_waitcount); + if (lkp->lk_sharewait > 0) + printf(" with %d pending readers", lkp->lk_sharewait); + if (lkp->lk_exclusivewait > 0) + printf(" with %d pending writers", lkp->lk_exclusivewait); #ifdef DEBUG_LOCKS stack_print(&lkp->lk_stack); #endif @@ -671,24 +641,9 @@ lkp = td->td_wchan; /* Simple test to see if wchan points to a lockmgr lock. */ - if (LOCK_CLASS(&lkp->lk_object) == &lock_class_lockmgr && - lkp->lk_wmesg == td->td_wmesg) - goto ok; + if (lkp->lk_wmesg != td->td_wmesg) + return (0); - /* - * If this thread is doing a DRAIN, then it would be asleep on - * &lkp->lk_flags rather than lkp. - */ - lkp = (struct lock *)((char *)td->td_wchan - - offsetof(struct lock, lk_flags)); - if (LOCK_CLASS(&lkp->lk_object) == &lock_class_lockmgr && - lkp->lk_wmesg == td->td_wmesg && (lkp->lk_flags & LK_WAITDRAIN)) - goto ok; - - /* Doen't seem to be a lockmgr lock. */ - return (0); - -ok: /* Ok, we think we have a lockmgr lock, so output some details. */ db_printf("blocked on lk \"%s\" ", lkp->lk_wmesg); if (lkp->lk_sharecount) { @@ -701,7 +656,7 @@ return (1); } -void +static void db_show_lockmgr(struct lock_object *lock) { struct thread *td; @@ -709,18 +664,20 @@ lkp = (struct lock *)lock; - db_printf(" lock type: %s\n", lkp->lk_wmesg); - db_printf(" state: "); + db_printf("lock type: %s\n", lkp->lk_wmesg); + db_printf("state: "); if (lkp->lk_sharecount) db_printf("SHARED (count %d)\n", lkp->lk_sharecount); - else if (lkp->lk_flags & LK_HAVE_EXCL) { + else if (lkp->lk_exclusivecount != 0) { td = lkp->lk_lockholder; db_printf("EXCL (count %d) %p ", lkp->lk_exclusivecount, td); db_printf("(tid %d, pid %d, \"%s\")\n", td->td_tid, td->td_proc->p_pid, td->td_proc->p_comm); } else db_printf("UNLOCKED\n"); - if (lkp->lk_waitcount > 0) - db_printf(" waiters: %d\n", lkp->lk_waitcount); + if (lkp->lk_sharewait > 0) + db_printf("waiters shared: %d\n", lkp->lk_sharewait); + if (lkp->lk_exclusivewait > 0) + db_printf("waiters exclusive: %d\n", lkp->lk_exclusivewait); } #endif ==== //depot/user/kris/contention/sys/kern/subr_lock.c#14 - /zoo/kris/contention/kern/subr_lock.c ==== @@ -59,7 +59,6 @@ &lock_class_sx, &lock_class_rm, &lock_class_rw, - &lock_class_lockmgr, }; #ifdef LOCK_PROFILING ==== //depot/user/kris/contention/sys/kern/vfs_default.c#6 - /zoo/kris/contention/kern/vfs_default.c ==== @@ -263,7 +263,7 @@ { struct vnode *vp = ap->a_vp; - return (_lockmgr(vp->v_vnlock, ap->a_flags, VI_MTX(vp), ap->a_td, ap->a_file, ap->a_line)); + return (lockmgr(vp->v_vnlock, ap->a_flags, VI_MTX(vp), ap->a_td)); } /* See above. */ ==== //depot/user/kris/contention/sys/sys/lockmgr.h#6 - /zoo/kris/contention/sys/lockmgr.h ==== @@ -51,23 +51,23 @@ * can be gained. */ struct lock { - struct lock_object lk_object; /* common lock properties */ + struct lock_object lk_object; /* common lock properties */ struct mtx *lk_interlock; /* lock on remaining fields */ u_int lk_flags; /* see below */ int lk_sharecount; /* # of accepted shared locks */ - int lk_waitcount; /* # of processes sleeping for lock */ - short lk_exclusivecount; /* # of recursive exclusive locks */ + int lk_sharewait; /* # waiting for shared locks */ + int lk_exclusivecount; /* # of recursive exclusive locks */ + int lk_exclusivewait; /* # of recursive exclusive locks */ + short lk_prio; /* priority at which to sleep */ + const char *lk_wmesg; /* resource sleeping (for tsleep) */ int lk_timo; /* maximum sleep time (for tsleep) */ struct thread *lk_lockholder; /* thread of exclusive lock holder */ - struct lock *lk_newlock; /* lock taking over this lock */ - + #ifdef DEBUG_LOCKS struct stack lk_stack; #endif }; - -#define lk_wmesg lk_object.lo_name /* * Lock request types: * LK_SHARED - get one of many possible shared locks. If a process @@ -202,15 +202,13 @@ int timo, int flags); void lockdestroy(struct lock *); -int _lockmgr(struct lock *, u_int flags, - struct mtx *, struct thread *p, char *file, int line); +int lockmgr(struct lock *, u_int flags, + struct mtx *, struct thread *p); void transferlockers(struct lock *, struct lock *); void lockmgr_printinfo(struct lock *); int lockstatus(struct lock *, struct thread *); int lockcount(struct lock *); int lockwaiters(struct lock *); - -#define lockmgr(lock, flags, mtx, td) _lockmgr((lock), (flags), (mtx), (td), __FILE__, __LINE__) #ifdef DDB int lockmgr_chain(struct thread *td, struct thread **ownerp); #endif ==== //depot/user/kris/contention/sys/ufs/ffs/ffs_vnops.c#13 - /zoo/kris/contention/ufs/ffs/ffs_vnops.c ==== @@ -371,7 +371,7 @@ flags |= LK_INTERLOCK; } lkp = vp->v_vnlock; - result = _lockmgr(lkp, flags, VI_MTX(vp), ap->a_td, ap->a_file, ap->a_line); + result = lockmgr(lkp, flags, VI_MTX(vp), ap->a_td); if (lkp == vp->v_vnlock || result != 0) break; /* @@ -382,7 +382,7 @@ * right lock. Release it, and try to get the * new lock. */ - (void) _lockmgr(lkp, LK_RELEASE, VI_MTX(vp), ap->a_td, ap->a_file, ap->a_line); + (void) lockmgr(lkp, LK_RELEASE, VI_MTX(vp), ap->a_td); if ((flags & LK_TYPE_MASK) == LK_UPGRADE) flags = (flags & ~LK_TYPE_MASK) | LK_EXCLUSIVE; flags &= ~LK_INTERLOCK; --------------090206040000020400040605-- From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 23:15:03 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F46416A46C; Tue, 20 Nov 2007 23:15:03 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [82.208.36.70]) by mx1.freebsd.org (Postfix) with ESMTP id F235F13C465; Tue, 20 Nov 2007 23:15:02 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id A1AF719E023; Wed, 21 Nov 2007 00:15:01 +0100 (CET) Received: from [192.168.1.2] (r3a200.net.upc.cz [213.220.192.200]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTP id 1185A19E019; Wed, 21 Nov 2007 00:14:59 +0100 (CET) Message-ID: <47436A80.30306@quip.cz> Date: Wed, 21 Nov 2007 00:15:12 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Colin Percival Subject: missing .cshrc and pf.conf after upgrade to 7.0-beta3 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 23:15:03 -0000 Hi, I am not 100% sure, maybe I overlook something in binary major version upgrade procedure, but after upgrade from 6.2 to 7.0-BETA3 my roots ~/.cshrc was "accidentally" replaced with dist version of .cshrc and /etc/pf.conf is missing. It was on testing machine, so no problem (restored from backup). I am writing this as note to somebody who can investigate if there are something wrong or not. Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 23:15:32 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B958216A419 for ; Tue, 20 Nov 2007 23:15:32 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 30D2613C45B for ; Tue, 20 Nov 2007 23:15:31 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from js.berklix.net (p549A4404.dip.t-dialin.net [84.154.68.4]) (authenticated bits=0) by tower.berklix.org (8.13.6/8.13.6) with ESMTP id lAKNFSfo061608; Tue, 20 Nov 2007 23:15:29 GMT (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by js.berklix.net (8.13.8/8.13.8) with ESMTP id lAKNFdAh043857; Wed, 21 Nov 2007 00:15:42 +0100 (CET) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (localhost.js.berklix.net [127.0.0.1]) by fire.js.berklix.net (8.13.8/8.13.8) with ESMTP id lAKNFa4R012904; Wed, 21 Nov 2007 00:15:36 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <200711202315.lAKNFa4R012904@fire.js.berklix.net> To: "Aryeh M. Friedman" In-reply-to: <474325A0.7060802@gmail.com> References: <474325A0.7060802@gmail.com> Comments: In-reply-to "Aryeh M. Friedman" message dated "Tue, 20 Nov 2007 13:21:20 -0500." Date: Wed, 21 Nov 2007 00:15:36 +0100 From: "Julian H. Stacey" Cc: freebsd-stable@freebsd.org Subject: Re: Software for distribution of configuration files and changes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 23:15:32 -0000 > Karl M. Joch wrote: > > Hello, > > > > i have searched alot for a software to: > > > > - distribut configuration files from one master to different > > systems - maintain configuration files on one machine for all > > systemes and then send it out - push the files, not download them > > like cvsup - maintaining files for all systems and files only > > affecting one system > > > > any ideas and hints would be greatly appreziatet. > > > > Have you looked at aegis (aegis.sf.net)? One way is to use eg: rlogin master_host ; su cd /site; rdist -M 20 -P /usr/bin/ssh mylabel & have various /etc & /usr/local/etc & httpd.conf etc files symbolic linked to a parallel tree in per host copies of /site Add PermitRootLogin yes to /etc/ssh/sshd_config To make rdist as root easier. Some people prefer rsync to rdist. rdist6 & rsync are in /usr/ports/net/ There's doubtless other solutions too. -- Julian Stacey. Munich Computer Consultant, BSD Unix C Linux. http://berklix.com Ihr Rauch = mein allergischer Kopfschmerz. Dump cigs 4 snuff. From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 23:50:15 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DCDC16A420 for ; Tue, 20 Nov 2007 23:50:15 +0000 (UTC) (envelope-from kurt.buff@gmail.com) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.224]) by mx1.freebsd.org (Postfix) with ESMTP id 06D4B13C442 for ; Tue, 20 Nov 2007 23:50:14 +0000 (UTC) (envelope-from kurt.buff@gmail.com) Received: by qb-out-0506.google.com with SMTP id a10so1403733qbd for ; Tue, 20 Nov 2007 15:50:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=aTbRmDYwhKenLcvANZbH00TjUamvFUw+2ARI1Dhbw+c=; b=RJwLcqEu+mnjmPBz4tj6AD0HEQnPvCUl4JCFkaQXQzkSjkD8MCyXFJ9Gq3G4knwBg0FYCEWP7avVn8l3wGBp+Ho/TFGd0wSJvlaC8XQDK9Z5pt/fZKMLlZAMiT8b63tD19t+fSg/mB69WOZxZpKBJG8TY6JpUoFcSqeMFL1tNMs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Xj7H0I2F9YT01RPvcHlne1/NX+bGEj0ODIWHxrH2Yk8bkgGLHp2whI/3c9uMOU/NHLrpModTXkcr85fsizxCTY5nVXmmnJAK4CUWZVhX3mBHwg5IqoLMFwBGB2/Ikrc5vOKJ0whZl7u/Zj2w9CLRmi3/0Nn9QqY/DaPLsV9LU5Y= Received: by 10.142.97.20 with SMTP id u20mr1817634wfb.1195601713168; Tue, 20 Nov 2007 15:35:13 -0800 (PST) Received: by 10.142.72.20 with HTTP; Tue, 20 Nov 2007 15:35:13 -0800 (PST) Message-ID: Date: Tue, 20 Nov 2007 15:35:13 -0800 From: "Kurt Buff" To: "Julian H. Stacey" In-Reply-To: <200711202315.lAKNFa4R012904@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <474325A0.7060802@gmail.com> <200711202315.lAKNFa4R012904@fire.js.berklix.net> Cc: freebsd-stable@freebsd.org, "Aryeh M. Friedman" Subject: Re: Software for distribution of configuration files and changes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 23:50:15 -0000 On Nov 20, 2007 3:15 PM, Julian H. Stacey wrote: > > Karl M. Joch wrote: > > > Hello, > > > > > > i have searched alot for a software to: > > > > > > - distribut configuration files from one master to different > > > systems - maintain configuration files on one machine for all > > > systemes and then send it out - push the files, not download them > > > like cvsup - maintaining files for all systems and files only > > > affecting one system > > > > > > any ideas and hints would be greatly appreziatet. > > > > > > > Have you looked at aegis (aegis.sf.net)? > > One way is to use eg: > rlogin master_host ; su > cd /site; rdist -M 20 -P /usr/bin/ssh mylabel > & have various /etc & /usr/local/etc & httpd.conf etc files symbolic linked to > a parallel tree in per host copies of /site > Add > PermitRootLogin yes > to > /etc/ssh/sshd_config > To make rdist as root easier. > > Some people prefer rsync to rdist. rdist6 & rsync are in /usr/ports/net/ > There's doubtless other solutions too. Whichever technique is used, don't allow remote root login, if you value the security of your network. Proper use of sudo is probably the easiest way to avoid root in batch files. Kurt From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 23:53:08 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 164C816A46E for ; Tue, 20 Nov 2007 23:53:08 +0000 (UTC) (envelope-from mikej@rogers.com) Received: from smtp106.rog.mail.re2.yahoo.com (smtp106.rog.mail.re2.yahoo.com [68.142.225.204]) by mx1.freebsd.org (Postfix) with SMTP id BAC8413C478 for ; Tue, 20 Nov 2007 23:53:06 +0000 (UTC) (envelope-from mikej@rogers.com) Received: (qmail 11136 invoked from network); 20 Nov 2007 23:26:25 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=c+nNK3e2I3wDADsKXj+sSfO5pKrxw7VtMH8bE63HbinMSIc22qDTE0/DUG9B/dpP/RsG5D9N0Y24cK8gZYcdR9DWyEwfu2X1ywnXribFeYKdVhtxH3E4OoDsX9TSozcbFZakc/gJT0P8zEqSe3YESM6xfgnmvSOwieiUagyS8dA= ; Received: from unknown (HELO ?172.16.0.165?) (mikej@rogers.com@99.227.98.203 with plain) by smtp106.rog.mail.re2.yahoo.com with SMTP; 20 Nov 2007 23:26:25 -0000 X-YMail-OSG: z7f1ljkVM1ma.aDW3_EKnPDX2MX56Ty9BYJlETy3AROdkU8uQSX6cr.qahj62TDMUg-- Message-ID: <47436D1E.3000005@rogers.com> Date: Tue, 20 Nov 2007 18:26:22 -0500 From: Mike Jakubik User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Schedule for 6.3R is a 404 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2007 23:53:08 -0000 Hello, Just an FYI, http://www.freebsd.org/releases/6.3R/schedule.html returns a 404. This is linked from http://www.freebsd.org/releases/. Thanks. From owner-freebsd-stable@FreeBSD.ORG Wed Nov 21 00:20:53 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F9EF16A419 for ; Wed, 21 Nov 2007 00:20:53 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 1731113C468 for ; Wed, 21 Nov 2007 00:20:52 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 8B3341CC079; Tue, 20 Nov 2007 16:20:43 -0800 (PST) Date: Tue, 20 Nov 2007 16:20:43 -0800 From: Jeremy Chadwick To: "Julian H. Stacey" Message-ID: <20071121002043.GA98340@eos.sc1.parodius.com> References: <474325A0.7060802@gmail.com> <200711202315.lAKNFa4R012904@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200711202315.lAKNFa4R012904@fire.js.berklix.net> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-stable@freebsd.org, "Aryeh M. Friedman" Subject: Re: Software for distribution of configuration files and changes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2007 00:20:53 -0000 On Wed, Nov 21, 2007 at 12:15:36AM +0100, Julian H. Stacey wrote: > Add > PermitRootLogin yes > to > /etc/ssh/sshd_config This should really be "PermitRootLogin without-password". Yes, the phrase "without-password" looks scary, but it isn't so much -- it allows root login via passwordless SSH keys only, while simultaneously continues disallowing root logins via keyboard/password authentication. sshd_config(5) has details. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Nov 21 00:44:59 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B00C916A468 for ; Wed, 21 Nov 2007 00:44:59 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by mx1.freebsd.org (Postfix) with ESMTP id 7C9D813C447 for ; Wed, 21 Nov 2007 00:44:59 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so467696anc for ; Tue, 20 Nov 2007 16:44:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=GB9O6BHqYN8/b/s+Db49RHTBOnbCPb3ITKsMZjM5bl0=; b=s8GiKJmYAgCNKr6l2mt/PnmnY6zzI8QrUxOrnpLZyeY6t05XkyUlU0Y02g51XEXK1qqx8tL/W6sfEyO4MVy3uJKz+7QKpOzG7IpjAy5yv7Ng5IaGtnP07MIxmA28vrh4Gickei+Gjzb3xD9LNN8LAE+lPTSSEckGKj+h9MA00Uw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EVJZFq3nn4wVNiuokL/7No4KBmJdw4RO4ZNlpw6K6yTKaw05zqq/BsKpG/wEK+77RsOLw6YM/KaM0G9jP7qocY7lOq3+wySHaSZCtXoqo9Tqin8IU3zIeZXyzW3a575VhHDXMJseAkjDG2I8sOHQqwllZ3/ViQYvXV2xCxwH/xU= Received: by 10.78.118.5 with SMTP id q5mr7619685huc.1195605498864; Tue, 20 Nov 2007 16:38:18 -0800 (PST) Received: by 10.78.39.6 with HTTP; Tue, 20 Nov 2007 16:38:18 -0800 (PST) Message-ID: Date: Wed, 21 Nov 2007 03:38:18 +0300 From: pluknet To: "Miroslav Lachman" <000.fbsd@quip.cz> In-Reply-To: <47436A80.30306@quip.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47436A80.30306@quip.cz> Cc: freebsd-stable@freebsd.org, Colin Percival Subject: Re: missing .cshrc and pf.conf after upgrade to 7.0-beta3 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2007 00:44:59 -0000 Hello. On 21/11/2007, Miroslav Lachman <000.fbsd@quip.cz> wrote: > Hi, > > I am not 100% sure, maybe I overlook something in binary major version > upgrade procedure, but after upgrade from 6.2 to 7.0-BETA3 my roots > ~/.cshrc was "accidentally" replaced with dist version of .cshrc and It could happen if the 'UpdateIfUnmodified' directive in your freebsd-update.conf does not include /root/ path (/etc/ /var/ by default). > /etc/pf.conf is missing. It was moved to examples just before 7.0-BETA3. > Miroslav Lachman wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Wed Nov 21 06:12:18 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07FAC16A418 for ; Wed, 21 Nov 2007 06:12:18 +0000 (UTC) (envelope-from jackqq@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.190]) by mx1.freebsd.org (Postfix) with ESMTP id D834513C45A for ; Wed, 21 Nov 2007 06:12:17 +0000 (UTC) (envelope-from jackqq@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so2010880rvb for ; Tue, 20 Nov 2007 22:12:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=TxyA1G6uiYu5uBWgIqO9aAMSvnXrCxM7zdaFomBlong=; b=lVVfHWh4R4G5uJCaUGU1k+Q25VOOJBYOeDOe8L2lxLxQbx9O1dT6JTQHQFTV5nKi09MX2sOU+avYjX7/BRzIz8AAXdV5mfVR+FTiZFotA3lh3ltTFEg/uI/kafh4NenIbNqSI2cuDz0TyerVTuwuJhrSaxXS6IYHYhsqwYFSF98= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TzbuM1l0WTy4vI2if+jB8kYBAnVIwj2hcoMQ7ODh0rP1ktkGni0cfdMgKWQIJ3ovEKz8G46mzXonCfAFLtTq6jypWmNmmAeuOri0cWnM+1GFQz0WS9t3QhiUNqggAiU74//ZJ3do662fvCaBKh4zddDktfd8QJ+oDkSNz29EcnE= Received: by 10.142.154.20 with SMTP id b20mr1851114wfe.1195623947064; Tue, 20 Nov 2007 21:45:47 -0800 (PST) Received: by 10.142.109.20 with HTTP; Tue, 20 Nov 2007 21:45:47 -0800 (PST) Message-ID: <53a565700711202145q3c1a8db5k8c0d41d7ad890405@mail.gmail.com> Date: Wed, 21 Nov 2007 13:45:47 +0800 From: "Quan Qiu" To: freebsd-stable@freebsd.org In-Reply-To: <20071121002043.GA98340@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <474325A0.7060802@gmail.com> <200711202315.lAKNFa4R012904@fire.js.berklix.net> <20071121002043.GA98340@eos.sc1.parodius.com> Subject: Re: Software for distribution of configuration files and changes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2007 06:12:18 -0000 T24gTm92IDIxLCAyMDA3IDg6MjAgQU0sIEplcmVteSBDaGFkd2ljayA8a29pdHN1QGZyZWVic2Qu b3JnPiB3cm90ZToKPiBPbiBXZWQsIE5vdiAyMSwgMjAwNyBhdCAxMjoxNTozNkFNICswMTAwLCBK dWxpYW4gSC4gU3RhY2V5IHdyb3RlOgo+ID4gQWRkCj4gPiAgICAgICBQZXJtaXRSb290TG9naW4g eWVzCj4gPiB0bwo+ID4gICAgICAgL2V0Yy9zc2gvc3NoZF9jb25maWcKPgo+IFRoaXMgc2hvdWxk IHJlYWxseSBiZSAiUGVybWl0Um9vdExvZ2luIHdpdGhvdXQtcGFzc3dvcmQiLiAgWWVzLCB0aGUK PiBwaHJhc2UgIndpdGhvdXQtcGFzc3dvcmQiIGxvb2tzIHNjYXJ5LCBidXQgaXQgaXNuJ3Qgc28g bXVjaCAtLSBpdCBhbGxvd3MKPiByb290IGxvZ2luIHZpYSBwYXNzd29yZGxlc3MgU1NIIGtleXMg b25seSwgd2hpbGUgc2ltdWx0YW5lb3VzbHkKPiBjb250aW51ZXMgZGlzYWxsb3dpbmcgcm9vdCBs b2dpbnMgdmlhIGtleWJvYXJkL3Bhc3N3b3JkIGF1dGhlbnRpY2F0aW9uLgo+IHNzaGRfY29uZmln KDUpIGhhcyBkZXRhaWxzLgo+CgoKIkNoYWxsZW5nZVJlc3BvbnNlQXV0aGVudGljYXRpb24gbm8i IGlzIGFsc28gcmVxdWlyZWQgdG8gYXZvaWQgc3NoZAphY2NlcHRpbmcga2V5Ym9hcmQtaW50ZXJh Y3RpdmUvcGFtLgoKCi0tIAr0w4HnIChRSVUgUXVhbikgPGphY2txcUBnbWFpbC5jb20+Cg== From owner-freebsd-stable@FreeBSD.ORG Wed Nov 21 10:39:02 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 401F716A46D for ; Wed, 21 Nov 2007 10:39:02 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id EE48D13C44B for ; Wed, 21 Nov 2007 10:39:01 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IumxN-0007yp-0e for freebsd-stable@freebsd.org; Wed, 21 Nov 2007 10:37:21 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Nov 2007 10:37:21 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Nov 2007 10:37:21 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Wed, 21 Nov 2007 11:38:58 +0100 Lines: 7 Message-ID: References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> <4741A7DA.2050706@chistydom.ru> <4741DA15.9000308@FreeBSD.org> <47429DB8.7040504@chistydom.ru> <4742ADFE.40902@FreeBSD.org> <4742C46A.1060701@chistydom.ru> <47432F77.3030606@FreeBSD.org> <474339E9.4080301@FreeBSD.org> <4743629B.9090408@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.6 (X11/20070801) In-Reply-To: <4743629B.9090408@FreeBSD.org> Sender: news Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2007 10:39:02 -0000 Kris Kennaway wrote: > Try this one instead, it applies to HEAD. You'll need to manually enter > the paths though because of how p4 mangles diffs. It doesn't help, at least in my case (only 4 clients) - the sys time is still around 30% on a 4-CPU machine. From owner-freebsd-stable@FreeBSD.ORG Wed Nov 21 10:44:26 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9E5516A41B; Wed, 21 Nov 2007 10:44:26 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id 2487613C447; Wed, 21 Nov 2007 10:44:25 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47440C10.5060608@FreeBSD.org> Date: Wed, 21 Nov 2007 11:44:32 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Ivan Voras References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> <4741A7DA.2050706@chistydom.ru> <4741DA15.9000308@FreeBSD.org> <47429DB8.7040504@chistydom.ru> <4742ADFE.40902@FreeBSD.org> <4742C46A.1060701@chistydom.ru> <47432F77.3030606@FreeBSD.org> <474339E9.4080301@FreeBSD.org> <4743629B.9090408@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2007 10:44:26 -0000 Ivan Voras wrote: > Kris Kennaway wrote: > >> Try this one instead, it applies to HEAD. You'll need to manually enter >> the paths though because of how p4 mangles diffs. > > It doesn't help, at least in my case (only 4 clients) - the sys time is > still around 30% on a 4-CPU machine. I've already explained why that is meaningless. Kris From owner-freebsd-stable@FreeBSD.ORG Wed Nov 21 10:48:37 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33BAD16A417 for ; Wed, 21 Nov 2007 10:48:37 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id E03D913C46A for ; Wed, 21 Nov 2007 10:48:36 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Iun85-0001ml-Jc for freebsd-stable@freebsd.org; Wed, 21 Nov 2007 10:48:25 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Nov 2007 10:48:25 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Nov 2007 10:48:25 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Wed, 21 Nov 2007 11:52:26 +0100 Lines: 13 Message-ID: References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> <4741A7DA.2050706@chistydom.ru> <4741DA15.9000308@FreeBSD.org> <47429DB8.7040504@chistydom.ru> <4742ADFE.40902@FreeBSD.org> <4742C46A.1060701@chistydom.ru> <47432F77.3030606@FreeBSD.org> <474339E9.4080301@FreeBSD.org> <4743629B.9090408@FreeBSD.org> <47440C10.5060608@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.6 (X11/20070801) In-Reply-To: <47440C10.5060608@FreeBSD.org> Sender: news Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2007 10:48:37 -0000 Kris Kennaway wrote: > Ivan Voras wrote: >> Kris Kennaway wrote: >> >>> Try this one instead, it applies to HEAD. You'll need to manually enter >>> the paths though because of how p4 mangles diffs. >> >> It doesn't help, at least in my case (only 4 clients) - the sys time is >> still around 30% on a 4-CPU machine. > > I've already explained why that is meaningless. Yes, but I had to verify it anyway :) From owner-freebsd-stable@FreeBSD.ORG Wed Nov 21 10:54:07 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE0F616A421; Wed, 21 Nov 2007 10:54:07 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id 0D98613C469; Wed, 21 Nov 2007 10:54:06 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47440E55.3060909@FreeBSD.org> Date: Wed, 21 Nov 2007 11:54:13 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Ivan Voras References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> <4741A7DA.2050706@chistydom.ru> <4741DA15.9000308@FreeBSD.org> <47429DB8.7040504@chistydom.ru> <4742ADFE.40902@FreeBSD.org> <4742C46A.1060701@chistydom.ru> <47432F77.3030606@FreeBSD.org> <474339E9.4080301@FreeBSD.org> <4743629B.9090408@FreeBSD.org> <47440C10.5060608@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2007 10:54:07 -0000 Ivan Voras wrote: > Kris Kennaway wrote: >> Ivan Voras wrote: >>> Kris Kennaway wrote: >>> >>>> Try this one instead, it applies to HEAD. You'll need to manually enter >>>> the paths though because of how p4 mangles diffs. >>> It doesn't help, at least in my case (only 4 clients) - the sys time is >>> still around 30% on a 4-CPU machine. >> I've already explained why that is meaningless. > > Yes, but I had to verify it anyway :) You haven't verified anything until you look at how much work the system is doing, before and after. Kris From owner-freebsd-stable@FreeBSD.ORG Wed Nov 21 10:55:32 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4632716A418; Wed, 21 Nov 2007 10:55:32 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [82.208.36.70]) by mx1.freebsd.org (Postfix) with ESMTP id ECD6413C48A; Wed, 21 Nov 2007 10:55:31 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 4283C19E019; Wed, 21 Nov 2007 11:55:31 +0100 (CET) Received: from [192.168.1.2] (r3a200.net.upc.cz [213.220.192.200]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTP id AE44819E02D; Wed, 21 Nov 2007 11:55:28 +0100 (CET) Message-ID: <47440EAE.7000701@quip.cz> Date: Wed, 21 Nov 2007 11:55:42 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: pluknet References: <47436A80.30306@quip.cz> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Colin Percival Subject: Re: missing .cshrc and pf.conf after upgrade to 7.0-beta3 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2007 10:55:32 -0000 pluknet wrote: > Hello. > > On 21/11/2007, Miroslav Lachman <000.fbsd@quip.cz> wrote: >>I am not 100% sure, maybe I overlook something in binary major version >>upgrade procedure, but after upgrade from 6.2 to 7.0-BETA3 my roots >>~/.cshrc was "accidentally" replaced with dist version of .cshrc and > > It could happen if the 'UpdateIfUnmodified' directive in your > freebsd-update.conf does not include /root/ path (/etc/ /var/ by > default). Hmmm it seems a little bit dangerous to me. OK, it is my fault. >>/etc/pf.conf is missing. > > It was moved to examples just before 7.0-BETA3. I had my pf.conf modified, but after upgrade and reboot, my machine booted without firewall, because pf.conf is missing. Now I am looking in to /var/db/freebsd-update/install.MvUwSa/INDEX-OLD and /var/db/freebsd-update/install.MvUwSa/INDEX-NEW - /etc/pf.conf is only in INDEX-OLD, /root/.cshrc is in both - but I do not know if it means something, I do not know freebsd-update principles in conjunction with INDEX-*. Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Wed Nov 21 10:57:15 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E858C16A419 for ; Wed, 21 Nov 2007 10:57:15 +0000 (UTC) (envelope-from marcolz@serv1-mk3.ilse.net) Received: from serv1-mk3.ilse.net (serv1-mk3.ilse.net [62.69.160.41]) by mx1.freebsd.org (Postfix) with ESMTP id 533DF13C447 for ; Wed, 21 Nov 2007 10:57:14 +0000 (UTC) (envelope-from marcolz@serv1-mk3.ilse.net) Received: (from marcolz@localhost) by serv1-mk3.ilse.net (8.13.4/8.12.11) id lALAuxsL052017; Wed, 21 Nov 2007 11:56:59 +0100 (CET) (envelope-from marcolz) Date: Wed, 21 Nov 2007 11:56:59 +0100 From: Marc Olzheim To: freebsd-stable@freebsd.org Message-ID: <20071121105659.GA37877@ilse.net> References: <20071117111446.GA24272@ilse.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline In-Reply-To: <20071117111446.GA24272@ilse.net> X-Operating-System: FreeBSD serv1-mk3.ilse.net 4.11-STABLE FreeBSD 4.11-STABLE X-URL: http://ilse.nl/ User-Agent: Mutt/1.5.11 Cc: Marc Olzheim Subject: Re: FreeBSD 7.0-BETA2 /usr/src/sys/conf/kern.mk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2007 10:57:16 -0000 --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 17, 2007 at 12:14:46PM +0100, Marc Olzheim wrote: > For the MACHINE_ARCH =3D=3D "amd64" & ${CC} !=3D "icc" case, > the -mno-sse3 flag that *is* set for MACHINE_ARCH =3D=3D "i386", is not s= et. >=20 > I don't think the current gcc actually uses sse3 anywhere in the kernel > compile, as my kernels are working as normal, but for the sake of > completeness, I suggest the attached patch. (For CURRENT as well as > RELENG_7) It's /usr/src/sys/conf/kern.mk:1.46 that misses the fact that it can be set for amd64 as well, not just for i386. Should I file a PR to get this fixed before 7-RELEASE ? --- /usr/src/sys/conf/kern.mk.orig 2007-05-24 21:53:42.000000000 +0000 +++ /usr/src/sys/conf/kern.mk 2007-11-17 12:10:28.000000000 +0000 @@ -70,7 +70,7 @@ # .if ${MACHINE_ARCH} =3D=3D "amd64" CFLAGS+=3D -mcmodel=3Dkernel -mno-red-zone \ - -mfpmath=3D387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow \ + -mfpmath=3D387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow \ -msoft-float -fno-asynchronous-unwind-tables INLINE_LIMIT?=3D 8000 .endif --tThc/1wpZn/ma/RB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFHRA77ezjnobFOgrERAi8rAJ9qi+8IzIcCk2tQhO1rCiA5uXsPXACgoBuz La9mhBhSOcLDsasXO/kUg2E= =hKV6 -----END PGP SIGNATURE----- --tThc/1wpZn/ma/RB-- From owner-freebsd-stable@FreeBSD.ORG Wed Nov 21 11:00:23 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0453716A420 for ; Wed, 21 Nov 2007 11:00:23 +0000 (UTC) (envelope-from marcolz@serv1-mk3.ilse.net) Received: from serv1-mk3.ilse.net (serv1-mk3.ilse.net [62.69.160.41]) by mx1.freebsd.org (Postfix) with ESMTP id 8171A13C459 for ; Wed, 21 Nov 2007 11:00:22 +0000 (UTC) (envelope-from marcolz@serv1-mk3.ilse.net) Received: (from marcolz@localhost) by serv1-mk3.ilse.net (8.13.4/8.12.11) id lALB08vF052498; Wed, 21 Nov 2007 12:00:08 +0100 (CET) (envelope-from marcolz) Date: Wed, 21 Nov 2007 12:00:08 +0100 From: Marc Olzheim To: freebsd-stable@freebsd.org Message-ID: <20071121110008.GB37877@ilse.net> References: <20071117111446.GA24272@ilse.net> <20071121105659.GA37877@ilse.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CUfgB8w4ZwR/yMy5" Content-Disposition: inline In-Reply-To: <20071121105659.GA37877@ilse.net> User-Agent: Mutt/1.5.11 Cc: Marc Olzheim Subject: Re: FreeBSD 7.0-BETA2 /usr/src/sys/conf/kern.mk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2007 11:00:23 -0000 --CUfgB8w4ZwR/yMy5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 17, 2007 at 12:14:46PM +0100, Marc Olzheim wrote: > For the MACHINE_ARCH =3D=3D "amd64" & ${CC} !=3D "icc" case, > the -mno-sse3 flag that *is* set for MACHINE_ARCH =3D=3D "i386", is not s= et. >=20 > I don't think the current gcc actually uses sse3 anywhere in the kernel > compile, as my kernels are working as normal, but for the sake of > completeness, I suggest the attached patch. (For CURRENT as well as > RELENG_7) It's /usr/src/sys/conf/kern.mk:1.46 that misses the fact that it can be set for amd64 as well, not just for i386. Should I file a PR to get this fixed before 7-RELEASE ? --- /usr/src/sys/conf/kern.mk.orig 2007-05-24 21:53:42.000000000 +0000 +++ /usr/src/sys/conf/kern.mk 2007-11-17 12:10:28.000000000 +0000 @@ -70,7 +70,7 @@ # .if ${MACHINE_ARCH} =3D=3D "amd64" CFLAGS+=3D -mcmodel=3Dkernel -mno-red-zone \ - -mfpmath=3D387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow \ + -mfpmath=3D387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow \ -msoft-float -fno-asynchronous-unwind-tables INLINE_LIMIT?=3D 8000 .endif --CUfgB8w4ZwR/yMy5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFHRA+4ezjnobFOgrERAmSBAJ4q2M84FszJdoKrGFWqrtUIahpLeACeOylT vt0p3UWMR+8yw+YzbBeEVYE= =kop4 -----END PGP SIGNATURE----- --CUfgB8w4ZwR/yMy5-- From owner-freebsd-stable@FreeBSD.ORG Wed Nov 21 11:03:10 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9310E16A41A for ; Wed, 21 Nov 2007 11:03:10 +0000 (UTC) (envelope-from marcolz@serv1-mk3.ilse.net) Received: from serv1-mk3.ilse.net (serv1-mk3.ilse.net [62.69.160.41]) by mx1.freebsd.org (Postfix) with ESMTP id 18C0713C465 for ; Wed, 21 Nov 2007 11:03:09 +0000 (UTC) (envelope-from marcolz@serv1-mk3.ilse.net) Received: (from marcolz@localhost) by serv1-mk3.ilse.net (8.13.4/8.12.11) id lALB2riU052788 for freebsd-stable@freebsd.org; Wed, 21 Nov 2007 12:02:53 +0100 (CET) (envelope-from marcolz) Date: Wed, 21 Nov 2007 12:02:53 +0100 From: Marc Olzheim To: freebsd-stable@freebsd.org Message-ID: <20071121110253.GC37877@ilse.net> References: <4731D93E.2020600@ibctech.ca> <20071108160934.GA24041@SDF.LONESTAR.ORG> <20071111145424.GA32274@ilse.net> <20071114140820.GA37310@ilse.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6zdv2QT/q3FMhpsV" Content-Disposition: inline In-Reply-To: <20071114140820.GA37310@ilse.net> X-Operating-System: FreeBSD serv1-mk3.ilse.net 4.11-STABLE FreeBSD 4.11-STABLE X-URL: http://ilse.nl/ User-Agent: Mutt/1.5.11 Subject: Re: Boot-time pass for geli on 7.0-BETA2, -BETA3 and RELENG_7 not working for me. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2007 11:03:10 -0000 --6zdv2QT/q3FMhpsV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 14, 2007 at 03:08:20PM +0100, Marc Olzheim wrote: > > > today I updated from 6.2-RELEASE-p8 to 7.0-BETA2 as well. > > > I've ran into the same problem with the password input to GELI on boo= t time. > > > Chars are showing up after several keypresses. > > >=20 > > > After removing the new dcons driver from my KERNEL config, recompilin= g and rebooting, it does work normally like under 6.2R > >=20 > > Thanks, I tried it, but alas, to no avail... Still the same symptoms. := -/ >=20 > Using an uniprocessor kernel doesn't change anything either. -BETA3 doesn't change anything for me. Should I file a PR for this? Marc --6zdv2QT/q3FMhpsV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFHRBBdezjnobFOgrERAhaNAKCtNxOD6iL/n80obVG3Z30W4YNMSACg1QlI lya7tKRH7qym8SnCf7bnldM= =Nk1P -----END PGP SIGNATURE----- --6zdv2QT/q3FMhpsV-- From owner-freebsd-stable@FreeBSD.ORG Wed Nov 21 11:14:10 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E47316A418; Wed, 21 Nov 2007 11:14:10 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from comtv.ru (comtv.ru [217.10.32.17]) by mx1.freebsd.org (Postfix) with ESMTP id 543F013C467; Wed, 21 Nov 2007 11:14:08 +0000 (UTC) (envelope-from lol@chistydom.ru) X-UCL: actv Received: from yoda.org.ru ([83.167.98.162] verified) by comtv.ru (CommuniGate Pro SMTP 4.1.8) with ESMTP id 21325914; Wed, 21 Nov 2007 14:13:49 +0300 Received: from [80.68.244.40] (adm40.relax.ru [80.68.244.40]) (Authenticated sender: llp@soekris.ru) by yoda.org.ru (Postfix) with ESMTP id A95F828D6F; Wed, 21 Nov 2007 14:14:04 +0300 (MSK) Message-ID: <474412CF.5050200@chistydom.ru> Date: Wed, 21 Nov 2007 14:13:19 +0300 From: Alexey Popov User-Agent: Thunderbird 2.0.0.6 (X11/20070924) MIME-Version: 1.0 To: Kris Kennaway References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> <4741A7DA.2050706@chistydom.ru> <4741DA15.9000308@FreeBSD.org> <47429DB8.7040504@chistydom.ru> <4742ADFE.40902@FreeBSD.org> <4742C46A.1060701@chistydom.ru> <47432F77.3030606@FreeBSD.org> <474339E9.4080301@FreeBSD.org> In-Reply-To: <474339E9.4080301@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Attilio Rao , freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2007 11:14:10 -0000 Hi. Kris Kennaway wrote: >> In the meantime there is unfortunately not a lot that can be done, >> AFAICT. There is one hack that I will send you later but it is not >> likely to help much. I will also think about how to track down the >> cause of the contention further (the profiling trace only shows that >> it comes mostly from vget/vput but doesn't show where these are called >> from). > Actually this patch might help. It doesn't replace lockmgr but it does > fix a silly thundering herd behaviour. It probably needs some > adjustment to get it to apply cleanly (it is about 7 months old), and I > apparently stopped using it because I ran into deadlocks. It might be > stable enough to at least see how much it helps. Sorry, I didn't try you patch yet but I have other news. As mentioned in the description of your patch there is probably a scalability problem with stat() syscall on FreeBSD. The PHP code of our site consists of large amount of modules. I think this is true for many other large PHP sites. I reached out that PHP calls lstat() for every path element of each file it opens including modules. Truss output shows that PHP makes more than 2000 lstat's for one /index.php request. After investigation I found out that lstats() are called from realpath() libc function. It turned out that PHP has "realpath cache", but it's size by default is 16K which is not enough for my files. I set realpath_cache_size to 256K and now there is no that much lstat calls. Performance of 8-core machine growed in ~ 50% for me on 7-STABLE. Now it can handle 30 and more requests per seconds. I have the similiar results with 6-STABLE. Now I have not that big %sys values as it was before (see attached top output). Nevertheless, Linux with its >50 rps is still far away from FreeBSD. Linux makes that 2000+ lstat's without problem. There's still stat(), open(), gettimeofday(), close() syscalls for each include file in PHP that i can not switch off. And also it is unclear for me what to do with MySQL which happened to have the same problems for me. With best regards, Alexey Popov From owner-freebsd-stable@FreeBSD.ORG Wed Nov 21 11:15:13 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A69D16A468; Wed, 21 Nov 2007 11:15:13 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id 4FF7113C457; Wed, 21 Nov 2007 11:15:12 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47441346.90907@FreeBSD.org> Date: Wed, 21 Nov 2007 12:15:18 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Alexey Popov References: <4741905E.8050300@chistydom.ru> <20071119140019.V80667@fledge.watson.org> <4741A3A8.4010803@chistydom.ru> <20071119152214.J80667@fledge.watson.org> <4741B648.7090002@chistydom.ru> <4741D4D2.4090902@FreeBSD.org> <4741DC82.1090809@FreeBSD.org> <47429C6A.8060701@chistydom.ru> In-Reply-To: <47429C6A.8060701@chistydom.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Ivan Voras Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2007 11:15:13 -0000 Alexey Popov wrote: > Also could you explain what to look for in the lock profiling results? > Does large "wait_total" values indicate problem or other columns??? All of the columns (well, maybe except for the "lock name" ;-) can indicate potential problems of various kinds, so you have to look at them all to identify possible abnormalities. For example, if you are acquiring a mutex many times you might look for ways to reduce the frequency of acquisitions. If it is being held for long periods of time this can increase contention for other consumers. If there is high lock contention then processes will block waiting for it. If processes are spending a lot of time waiting for the lock then they are not getting work done. Kris From owner-freebsd-stable@FreeBSD.ORG Wed Nov 21 11:20:56 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D30E116A418 for ; Wed, 21 Nov 2007 11:20:56 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by mx1.freebsd.org (Postfix) with ESMTP id 8F77E13C45D for ; Wed, 21 Nov 2007 11:20:56 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so2898641waf for ; Wed, 21 Nov 2007 03:20:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=wdiJf/pul1wzzch9p56eXs+Ew+4BCOTQ21x0GVWPKKQ=; b=RUQHqIA+JILNTOMBQDVxYIJH9/h077B7H/Yi4s9NC9Si05S/2UlYzzfTQfKwz4LBtdRLwmG1Mx63Yd2BuHDFFWCTtim/f2tGlfI2m3s11txLhOUvFy7wJQ2SwevfQz+eCSw2B3fCrROZzVXmai5IfdhFibzDRWkVDGvNrh3M0ak= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=XKAMf/9FwjIdCPvqA/vQBR8pOoyD5wHvHLtvh0BBZM6OpWdfLvnSDCvWp6KbLdKk5KCAWUh9AlR/rdz3Ss8zhU0FTBJmSUn+PSSkWGaHLnRmlLyV5qTmsKC0hrg1oDYHHAJOgrvJn6CUhD7ZqLr+HlB53Hhr5T2qdKHWnUTn0m0= Received: by 10.140.147.18 with SMTP id u18mr150936rvd.1195644056271; Wed, 21 Nov 2007 03:20:56 -0800 (PST) Received: by 10.141.211.5 with HTTP; Wed, 21 Nov 2007 03:20:56 -0800 (PST) Message-ID: <9bbcef730711210320s73c0625bh25ba2561b270f237@mail.gmail.com> Date: Wed, 21 Nov 2007 12:20:56 +0100 From: "Ivan Voras" Sender: ivoras@gmail.com To: "Kris Kennaway" In-Reply-To: <47440E55.3060909@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4741905E.8050300@chistydom.ru> <4742ADFE.40902@FreeBSD.org> <4742C46A.1060701@chistydom.ru> <47432F77.3030606@FreeBSD.org> <474339E9.4080301@FreeBSD.org> <4743629B.9090408@FreeBSD.org> <47440C10.5060608@FreeBSD.org> <47440E55.3060909@FreeBSD.org> X-Google-Sender-Auth: b1a3c5916184d90c Cc: freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2007 11:20:56 -0000 On 21/11/2007, Kris Kennaway wrote: > Ivan Voras wrote: > > Yes, but I had to verify it anyway :) > > You haven't verified anything until you look at how much work the system > is doing, before and after. I have, and it's roughly the same (50 +/- 2 queries/s). (meaning that I'm not interested in exact statistics here, but in order-of-magnitude changes, which didn't happen). From owner-freebsd-stable@FreeBSD.ORG Wed Nov 21 13:07:15 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA5E416A417; Wed, 21 Nov 2007 13:07:15 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.freebsd.org (Postfix) with ESMTP id 7893C13C44B; Wed, 21 Nov 2007 13:07:14 +0000 (UTC) (envelope-from max@love2party.net) Received: from amd64.laiers.local (dslb-088-066-051-232.pools.arcor-ip.net [88.66.51.232]) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis) id 0ML2xA-1IupIN3cCh-0007qS; Wed, 21 Nov 2007 14:07:13 +0100 From: Max Laier Organization: FreeBSD To: freebsd-stable@freebsd.org Date: Wed, 21 Nov 2007 14:06:59 +0100 User-Agent: KMail/1.9.7 References: <47436A80.30306@quip.cz> <47440EAE.7000701@quip.cz> In-Reply-To: <47440EAE.7000701@quip.cz> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1850219.QIOQ7dab1r"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200711211407.08789.max@love2party.net> X-Provags-ID: V01U2FsdGVkX18HRmqp0NEPyWPxxNUaNXni8syV6dn/tlpr4rC qvgjSjfmw/SVO9BYMOQ8l5Y3yPDOK5pQfJm5k9dAZSZC5W+r9V 2wTOEOvug5nFsJ8lN09a27GV4OGHYmguz2cW7O+B1E= Cc: pluknet , Miroslav Lachman <000.fbsd@quip.cz>, Colin Percival Subject: Re: missing .cshrc and pf.conf after upgrade to 7.0-beta3 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2007 13:07:16 -0000 --nextPart1850219.QIOQ7dab1r Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 21 November 2007, Miroslav Lachman wrote: > pluknet wrote: > > Hello. > > > > On 21/11/2007, Miroslav Lachman <000.fbsd@quip.cz> wrote: > >>I am not 100% sure, maybe I overlook something in binary major > >> version upgrade procedure, but after upgrade from 6.2 to 7.0-BETA3 > >> my roots ~/.cshrc was "accidentally" replaced with dist version of > >> .cshrc and > > > > It could happen if the 'UpdateIfUnmodified' directive in your > > freebsd-update.conf does not include /root/ path (/etc/ /var/ by > > default). > > Hmmm it seems a little bit dangerous to me. OK, it is my fault. > > >>/etc/pf.conf is missing. > > > > It was moved to examples just before 7.0-BETA3. > > I had my pf.conf modified, but after upgrade and reboot, my machine > booted without firewall, because pf.conf is missing. > > Now I am looking in to /var/db/freebsd-update/install.MvUwSa/INDEX-OLD > and /var/db/freebsd-update/install.MvUwSa/INDEX-NEW - /etc/pf.conf is > only in INDEX-OLD, /root/.cshrc is in both - but I do not know if it > means something, I do not know freebsd-update principles in conjunction > with INDEX-*. It looks like freebsd-update will delete all files in INDEX-OLD but not in= =20 INDEX-NEW by default. Is there a way to make a certain file stick=20 around? It was obviously a mistake to install /etc/pf.conf as an example=20 file in the first place, but what can be done about it after the fact? =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1850219.QIOQ7dab1r Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHRC18XyyEoT62BG0RAtEpAJ954ih+o49r3yNW7ef56QsL+XrEEgCfZDfH VYavCn/Rp29E++9KXnyj7V0= =fh5/ -----END PGP SIGNATURE----- --nextPart1850219.QIOQ7dab1r-- From owner-freebsd-stable@FreeBSD.ORG Wed Nov 21 13:23:21 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D69516A41B; Wed, 21 Nov 2007 13:23:21 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from hermes.hw.ru (hermes.hw.ru [80.68.240.91]) by mx1.freebsd.org (Postfix) with ESMTP id 3D47913C50C; Wed, 21 Nov 2007 13:23:19 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from [80.68.244.40] (account a_popov@rbc.ru [80.68.244.40] verified) by hermes.hw.ru (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 201867035; Wed, 21 Nov 2007 16:22:58 +0300 Message-ID: <4744312A.2010508@chistydom.ru> Date: Wed, 21 Nov 2007 16:22:50 +0300 From: Alexey Popov User-Agent: Thunderbird 2.0.0.6 (X11/20070924) MIME-Version: 1.0 To: Kris Kennaway References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> <4741A7DA.2050706@chistydom.ru> <4741DA15.9000308@FreeBSD.org> <47429DB8.7040504@chistydom.ru> <4742ADFE.40902@FreeBSD.org> <4742C46A.1060701@chistydom.ru> <47432F77.3030606@FreeBSD.org> <474339E9.4080301@FreeBSD.org> <474412CF.5050200@chistydom.ru> In-Reply-To: <474412CF.5050200@chistydom.ru> Content-Type: multipart/mixed; boundary="------------040209030901040504080702" Cc: Attilio Rao , freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2007 13:23:21 -0000 This is a multi-part message in MIME format. --------------040209030901040504080702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all. Sorry, forgot to attach top & vmstat oputput on 8-core 7-stable with optimized PHP realpath_cache_size. With best regards, Alexey Popov --------------040209030901040504080702 Content-Type: text/plain; name="top-new.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="top-new.txt" last pid: 91239; load averages: 4.64, 4.72, 7.82 up 0+19:13:37 14:07:50 53 processes: 7 running, 46 sleeping CPU states: 78.0% user, 0.0% nice, 21.5% system, 0.0% interrupt, 0.4% idle Mem: 341M Active, 181M Inact, 225M Wired, 272K Cache, 186M Buf, 3158M Free Swap: 2048M Total, 2048M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 91238 www 1 4 0 99644K 48752K sbwait 4 0:03 64.04% httpd 91233 www 1 100 0 98M 46124K select 3 0:03 55.79% httpd 91236 www 1 100 0 92476K 41000K select 3 0:03 54.69% httpd 91234 www 1 100 0 99644K 47212K select 7 0:03 54.02% httpd 91235 www 1 100 0 93500K 42508K CPU1 0 0:03 52.26% httpd 91232 www 1 100 0 92476K 41980K select 4 0:03 45.17% httpd 91231 www 1 100 0 97596K 43656K CPU7 1 0:03 41.22% httpd 91226 www 1 100 0 99644K 49524K select 6 0:05 37.63% httpd 91228 www 1 100 0 98620K 46516K select 5 0:05 37.02% httpd 91237 www 1 98 0 99644K 43588K select 1 0:01 32.83% httpd 91223 www 1 101 0 96572K 47312K select 5 0:07 31.85% httpd 91229 www 1 99 0 99644K 46632K select 4 0:03 30.42% httpd 91135 www 1 101 0 98M 51528K select 7 0:33 29.86% httpd 91227 www 1 100 0 99M 47212K select 2 0:03 28.02% httpd 91225 www 1 100 0 98M 47068K CPU5 5 0:06 27.56% httpd 91180 www 1 100 0 113M 62152K CPU2 3 0:21 26.41% httpd 91224 www 1 100 0 99M 50260K select 5 0:06 24.21% httpd 91214 www 1 99 0 99644K 49576K select 5 0:11 23.49% httpd 91212 www 1 100 0 99M 51548K select 2 0:10 22.89% httpd 91230 www 1 98 0 98M 46200K select 7 0:02 21.31% httpd 91077 www 1 99 0 99M 51940K CPU6 4 0:50 20.41% httpd 91209 www 1 99 0 97596K 46316K CPU3 3 0:10 20.08% httpd 91196 www 1 98 0 99648K 50412K select 7 0:13 18.59% httpd 91239 www 1 96 0 99644K 45728K select 1 0:01 11.57% httpd 18052 llp 1 96 0 32928K 4544K select 5 0:25 0.00% sshd 698 root 1 96 0 8952K 2516K select 0 0:02 0.00% ntpd 779 root 1 96 0 20952K 3740K select 0 0:01 0.00% sshd 89816 root 1 100 0 86332K 13340K select 6 0:01 0.00% httpd 18074 root 1 20 0 9616K 3208K pause 0 0:01 0.00% csh 786 root 1 8 0 5736K 1388K nanslp 2 0:01 0.00% cron 765 root 1 4 0 4852K 1640K kqread 5 0:00 0.00% master 2 users Load 7.14 7.38 6.83 Nov 21 16:20 Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER Tot Share Tot Share Free in out in out Act 337476 33184 630700 37128 3249600 count All 397780 35216 4900464 48580 pages Proc: Interrupts r p d s w Csw Trp Sys Int Sof Flt 331 cow 20208 total 4 2 43 2 28k 33k 112k 4228 989 31k 31162 zfod sio0 irq4 ozfod ata0 irq14 8.2%Sys 0.1%Intr 48.3%User 0.0%Nice 43.5%Idle %ozfod mfi0 irq18 | | | | | | | | | | | daefr uhci0 uhci ====>>>>>>>>>>>>>>>>>>>>>>>> 3413 prcfr 1972 cpu0: time 9 dtbuf 26138 totfr 4228 em0 irq256 Namei Name-cache Dir-cache 100000 desvn react 2021 cpu2: time Calls hits % hits % 10544 numvn pdwak 2021 cpu3: time 88017 88017 100 283 frevn pdpgs 1983 cpu6: time intrn 1983 cpu7: time Disks mfid0 241756 wire 1972 cpu1: time KB/t 0.00 313748 act 2014 cpu4: time tps 0 196500 inact 2014 cpu5: time MB/s 0.00 256 cache %busy 0 3247264 free 206320 buf --------------040209030901040504080702-- From owner-freebsd-stable@FreeBSD.ORG Wed Nov 21 14:50:57 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F17E816A417 for ; Wed, 21 Nov 2007 14:50:56 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) by mx1.freebsd.org (Postfix) with ESMTP id AA35813C45B for ; Wed, 21 Nov 2007 14:50:56 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from localhost (marvin-mail [192.168.0.2]) by marvin.harmless.hu (Postfix) with ESMTP id 227EB7C175D for ; Wed, 21 Nov 2007 15:24:09 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.4.2 (20060627) (Debian) at harmless.hu Received: from marvin.harmless.hu ([192.168.0.2]) by localhost (marvin.harmless.hu [192.168.0.2]) (amavisd-new, port 10024) with ESMTP id b1zpOeB54BAQ for ; Wed, 21 Nov 2007 15:24:08 +0100 (CET) Received: from marvin.harmless.hu (localhost [127.0.0.1]) by marvin.harmless.hu (Postfix) with ESMTP id 46D457BFF3A for ; Wed, 21 Nov 2007 15:24:04 +0100 (CET) Date: Wed, 21 Nov 2007 15:24:04 +0100 From: Gergely CZUCZY To: freebsd-stable@freebsd.org Message-ID: <20071121142404.GA7511@harmless.hu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline User-Agent: mutt-ng/devel-r804 (FreeBSD) Subject: mmap max size (qemu VM memsize limit) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2007 14:50:57 -0000 --/04w6evG8XlLl3ft Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, I'm trying to set up a qemu with 4G memory to the host system on a 7-BETA2, and I've hit some kind of limit in freebsd. When i give more then ~2000MB of memory to qemu, it returns an after trying to mmap() it, saying "Could not map physical memory". At the end of mmap(2) there's a note saying: " The len argument is limited to the maximum file size or available use= r- land address space. Files may not be able to be made more than 1TB la= rge on 32 bit systems due to file systems restrictions and bugs, but addre= ss space is far more restrictive. Larger files may be possible on 64 bit systems." I guess I've found this limit. I've tried to check a few sysctls but I wasn= 't able to find the one effecting this limit. Could someone point me into the right direction in increasing the maximum mmap-able size? Sincerely, Gergely Czuczy mailto: gergely.czuczy@harmless.hu --=20 Weenies test. Geniuses solve problems that arise. --/04w6evG8XlLl3ft Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) owFNVD1rHFcUVSyneeBCnStzo0YW2VnvriSvvGZRLNmWBQ4psmBISODtzJ2Zh97H 6H1IHhVJocYYY4xbIwyq3IQEkjK/wZ2LkMKNq5A2RbrcN7O7zhYDe9+95553zpl5 cWV56dLK219++/bzZy9fffLTZTldV8F7XSSK22Ohk36v10+GW/1+spFsDYf59gb2 N7J+f5qm+3d3zvaM9qh9MqkrHIHHx/5GJbnQtyEtuXXox8HnyTab990VrjJOeGH0 CISWQuPibGK5djna5J5OTSZ0MYKjYDxmSWWF9nwqkbEHKKXpMHawpsDbmrrAG6BF ECrgcIQqwInwJWzug0JlbB3PfYlQGufB1c6jYkZT7zDZvTe5M+gA1xkcrB1Ti6AO oxAOBZVMDlIoKgkNuUWcuqzL2KMSNQgoBPUTPEZsDT8Mer3el7tx5uPWSKYDBGDR B6sd47Q292j/x1wpXl1fp6YOON4UV/dMkBlo44HOoCprJ1IuZ7irROGOby6ELccG YbAeSxbXHF2MRnGGNmKrEH8T6pfEk9siKBIbhGsvh9lcH8UfCxUU5ELStDhFMBb4 MRcyKg/B4ZjZhDVwMkrGs8yic+AqnmIX4D4NOoKpG+5ThGaO0KcRPFvIRSr0J7uE QXgFtoBkyMYApmLukIMsNLMtm1mN1nkr0pge17g2DYXr0NO3ZMbMuRav4RQvmXPb 7l3MHkeuD0kI8iFfUCaOFEwnImUic3Mzkplhtdu7q5Q6KEK8cpOW3ASi4Mu5lN22 TFtaUdMS00OyI8eTiJF66RqqB3DCnR6zNc/mCuWiQYqrydc8R+IZ8/ERm7E2FjGe saky9EpQJiicM/+sKEoPmbDYCBRTK3RqkbsWauEwi4lJmtXR5h3GvqZGCo+s6cXa R1JG1rB3GtLTminy35sRFG25mzblL+jlViSd65aBsSQZD3rsEaIWpKYnobuwT38o MpQOI0mUyhraRxaS/WSWFQ677MnO8qdL8Ssy/wCtXLqVLr3+6uzvztNv3v9885/7 m+dXf4etP8/+WDq/9mz7Tfju33fDler5Z79+f/HXhx8v/gM= =g9yW -----END PGP SIGNATURE----- --/04w6evG8XlLl3ft-- From owner-freebsd-stable@FreeBSD.ORG Wed Nov 21 15:03:47 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1949416A41B for ; Wed, 21 Nov 2007 15:03:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id EE06F13C506 for ; Wed, 21 Nov 2007 15:03:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by elvis.mu.org (Postfix) with ESMTP id 2D32E1A4D7C; Wed, 21 Nov 2007 07:03:46 -0800 (PST) From: John Baldwin To: freebsd-stable@freebsd.org, lev@freebsd.org Date: Wed, 21 Nov 2007 09:39:32 -0500 User-Agent: KMail/1.9.7 References: <44941699.20071115221850@serebryakov.spb.ru> In-Reply-To: <44941699.20071115221850@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711210939.32454.jhb@freebsd.org> Cc: Subject: Re: 6.3-PRERELEASE: interrupt storm detected on "irq11:"; throttling interrupt source, (irq11 is em0) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2007 15:03:47 -0000 On Thursday 15 November 2007 02:18:50 pm Lev Serebryakov wrote: > Hello, freebsd-stable. > > Upgrading my netwrok from 100Mbit to 1Gbit. > > I've replaced one of two fxp's with em (desktop varinat), and rebuild system. > Right after booting TONS of messages about interrupt storm (without > device name). irq11 is occuped by em0. > > uname -a > FreeBSD xxx.xxx.xxx 6.3-PRERELEASE FreeBSD 6.3-PRERELEASE #0: Thu Nov > 15 19:19:26 MSK 2007 lev@xxx.xxx.xxx:/usr/obj/usr/src/sys/GATEWAY i386 > > Here is dmesg.boot: > > Copyright (c) 1992-2007 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 6.3-PRERELEASE #0: Thu Nov 15 19:19:26 MSK 2007 > lev@xxx.xxx.xxx:/usr/obj/usr/src/sys/GATEWAY > Copyright (c) 1992-2007 The FreeBSD Project.Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Pentium III/Pentium III Xeon/Celeron (551.25-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x673 Stepping = 3 > Features=0x387f9ff > real memory = 671072256 (639 MB) > avail memory = 647380992 (617 MB) > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) > acpi0: on motherboard > acpi0: Power Button (fixed) > Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 > cpu0: on acpi0 > acpi_throttle0: on cpu0 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > agp0: mem 0xe7000000-0xe7ffffff at device 0.0 on pci0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > pci1: at device 0.0 (no driver attached) > isab0: at device 4.0 on pci0 > isa0: on isab0 > atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xb800-0xb80f at device 4.1 on pci0 > ata0: on atapci0 > ata1: on atapci0 > pci0: at device 4.2 (no driver attached) > intpm0: port 0xe800-0xe80f irq 9 at device 4.3 on pci0 > intpm0: I/O mapped e800 > intpm0: intr IRQ 9 enabled revision 0 > intpm0: [GIANT-LOCKED] > intsmb0: on intpm0 > smbus1: on intsmb0 > smb0: on smbus1 > intpm0: PM I/O mapped e400 > ath0: mem 0xe3800000-0xe380ffff irq 12 at device 10.0 on pci0 > ath0: Ethernet address: 00:15:e9:40:61:59 > ath0: mac 7.9 phy 4.5 radio 5.6 > fxp0: port 0xb000-0xb01f mem 0xe5000000-0xe5000fff,0xe3000000-0xe30fffff irq 10 at device 11.0 on pci0 > miibus0: on fxp0 > inphy0: on miibus0 > inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > fxp0: Ethernet address: 00:50:8b:5d:ac:cb > em0: port 0xa800-0xa83f mem 0xe2800000-0xe281ffff,0xe2000000-0xe201ffff irq 11 at device 12.0 on pci0 > em0: Ethernet address: 00:07:e9:09:ed:f3 > pci0: at device 13.0 (no driver attached) > ppc0: port 0x378-0x37f,0x778-0x77b 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 > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > sio0: type 16550A > sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 > sio1: type 16550A > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > pmtimer0 on isa0 > orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc87ff,0xcc000-0xccfff on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sio2 at port 0x3e8-0x3ef irq 5 on isa0 > sio2: type 16550A > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > Timecounter "TSC" frequency 551253671 Hz quality 800 > Timecounters tick every 1.000 msec > interrupt storm detected on "irq11:"; throttling interrupt source > ad0: 76351MB at ata0-master UDMA33 > acd0: CDROM at ata1-master PIO4 > Trying to mount root from ufs:/dev/ad0s1a > interrupt storm detected on "irq11:"; throttling interrupt source > interrupt storm detected on "irq11:"; throttling interrupt source > interrupt storm detected on "irq11:"; throttling interrupt source > interrupt storm detected on "irq11:"; throttling interrupt source > interrupt storm detected on "irq11:"; throttling interrupt source > ipfw2 initialized, divert loadable, rule-based forwarding disabled, default to deny, logging disabled > interrupt storm detected on "irq11:"; throttling interrupt source > interrupt storm detected on "irq11:"; throttling interrupt source > interrupt storm detected on "irq11:"; throttling interrupt source Probably you have a misrouted interrupt and some other device is interrupting on IRQ 11 but has its handler listening on another IRQ. You can try disabling invididual devices to see which one is causing the storm and then investigate further from there. em0 and any other devices on IRQ 11 are probably "innocent victims" of the other device whose IRQ is wrong. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Nov 21 16:16:40 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 889F716A46B for ; Wed, 21 Nov 2007 16:16:40 +0000 (UTC) (envelope-from test@ns1.gakki.ne.jp) Received: from ns1.gakki.ne.jp (ns1.gakki.ne.jp [211.18.219.66]) by mx1.freebsd.org (Postfix) with ESMTP id 2F97713C4C6 for ; Wed, 21 Nov 2007 16:16:40 +0000 (UTC) (envelope-from test@ns1.gakki.ne.jp) Received: from ns1.gakki.ne.jp (ns1.gakki.ne.jp [127.0.0.1]) by ns1.gakki.ne.jp (Postfix) with ESMTP id 3B42528608 for ; Thu, 22 Nov 2007 01:07:44 +0900 (JST) Received: (from test@localhost) by ns1.gakki.ne.jp (8.13.4/8.13.4/Submit) id lALG7ivc028837; Thu, 22 Nov 2007 01:07:44 +0900 Date: Thu, 22 Nov 2007 01:07:44 +0900 Message-Id: <200711211607.lALG7ivc028837@ns1.gakki.ne.jp> To: freebsd-stable@freebsd.org From: TotalMP3Converter.Offerts@ns1.gakki.ne.jp MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: New OFFERT X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2007 16:16:40 -0000 TOTAL MP3 CONVERTER... THIS WEEK FOR FREE!!! The best just got better. Now you can appreciate our new product at its true value! MP3 Converter is a high quality product. Those who ever tried any other tool from Softplicity know that. Program features and advantages in comparison with similar programs: * Source formats are MP3, RA, APL, MPC, MP+, M4A, MP4, TTA, OFR, SPX, WAV, OGG, WMA, FLAC, CDA, AAC, APE, MPP, WV, XM, IT, S3M, MOD, MTM, UMX. This one could help me feel like normal user, not a fool!!! The only drawback is that its a trial version. But i think its definitely worth the money , This Program makes the best TOP QUALITY. Mp3's from wav's better than highly publicized. It just works :) Copyright © 1998-2007 [1]Total MP3 Converter. All rights reserved. [all-to-mp3.png] [2]FREE Download References 1. mailto:support@TotalConverter.com 2. http://h1.ripway.com/totaldownloads/TotalMP3Converter.exe From owner-freebsd-stable@FreeBSD.ORG Wed Nov 21 17:01:20 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD24416A419 for ; Wed, 21 Nov 2007 17:01:20 +0000 (UTC) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (thingy.kcilink.com [74.92.149.59]) by mx1.freebsd.org (Postfix) with ESMTP id 7A66C13C4D1 for ; Wed, 21 Nov 2007 17:01:19 +0000 (UTC) (envelope-from vivek@khera.org) Received: from host-121.int.kcilink.com (host-121.int.kcilink.com [192.168.7.121]) by yertle.kcilink.com (Postfix) with ESMTP id D69AEC943A for ; Wed, 21 Nov 2007 12:01:18 -0500 (EST) Message-Id: From: Vivek Khera To: FreeBSD Stable List In-Reply-To: <53a565700711202145q3c1a8db5k8c0d41d7ad890405@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Wed, 21 Nov 2007 12:01:18 -0500 References: <474325A0.7060802@gmail.com> <200711202315.lAKNFa4R012904@fire.js.berklix.net> <20071121002043.GA98340@eos.sc1.parodius.com> <53a565700711202145q3c1a8db5k8c0d41d7ad890405@mail.gmail.com> X-Mailer: Apple Mail (2.915) Subject: Re: Software for distribution of configuration files and changes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2007 17:01:20 -0000 On Nov 21, 2007, at 12:45 AM, Quan Qiu wrote: > > "ChallengeResponseAuthentication no" is also required to avoid sshd > accepting keyboard-interactive/pam. > > I don't think this setting matters for PermitRootLogin without- password. At least the default on FreeBSD 6 works as expected when setting the root login limit. From owner-freebsd-stable@FreeBSD.ORG Wed Nov 21 17:12:39 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A83716A41B for ; Wed, 21 Nov 2007 17:12:39 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 107AF13C442 for ; Wed, 21 Nov 2007 17:12:38 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1Iut5P-0005j3-54 for freebsd-stable@freebsd.org; Wed, 21 Nov 2007 17:10:03 +0000 Received: from cairn.ints.net ([194.44.58.121]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Nov 2007 17:10:03 +0000 Received: from c.kworr by cairn.ints.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Nov 2007 17:10:03 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Volodymyr Kostyrko Date: Wed, 21 Nov 2007 18:15:28 +0200 Lines: 25 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: cairn.ints.net User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.8.1.9) Gecko/20071107 SeaMonkey/1.1.6 Sender: news Subject: CPUTYPE:=athlon problem on RELENG_7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2007 17:12:39 -0000 When I moved to RELENG_7 on my machine i have experienced some SIGILL's on graphic applications. Looking into the cause I found this in gcc docs: _athlon, athlon-tbird_ AMD Athlon CPU with MMX, 3dNOW!, enhanced 3dNOW! and SSE prefetch instructions support. But my processor lack any SSE support: CPU: AMD Athlon(tm) Processor (1343.06-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x644 Stepping = 4 Features=0x183f9ff AMD Features=0xc0440800,MMX+,3DNow!+,3DNow!> I have tried to enable CPU_ATHLON_SSE_HACK in kernel, but with no luck. I have also verified that I'm running the last available BIOS for my motherboard. Now when I have moved to k6-2 my system is working and stable as hell... Am I missing something weird? -- Sphinx of blackb quartz judge my vow. From owner-freebsd-stable@FreeBSD.ORG Wed Nov 21 17:16:17 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DA8616A417 for ; Wed, 21 Nov 2007 17:16:17 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from outgoing02.lava.net (outgoing02.lava.net [64.65.64.125]) by mx1.freebsd.org (Postfix) with ESMTP id 2849513C46B for ; Wed, 21 Nov 2007 17:16:16 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing02.lava.net (Postfix) with ESMTP id 50052B88EB for ; Wed, 21 Nov 2007 07:16:16 -1000 (HST) Received: by malasada.lava.net (Postfix, from userid 102) id B5D38153882; Wed, 21 Nov 2007 07:16:15 -1000 (HST) Date: Wed, 21 Nov 2007 07:16:15 -1000 From: Clifton Royston To: FreeBSD Stable List Message-ID: <20071121171614.GA4191@lava.net> Mail-Followup-To: FreeBSD Stable List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Subject: Debugging symbols for servers installed from CD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2007 17:16:17 -0000 All three SMP servers I recently installed with 6.2p8 from a custom build CD rebooted within the space of 24 hours about a day ago. (One of them is still not up; it sounds like it's requiring me to get to the console to fix the root fs.) Unfortunately I'd forgotten to set dumpdev in rc.conf on them, so I have nothing to analyze as yet. I've done "dumpon" and set dumpdev for the next boot, but making the assumption that I get a good crash dump if this recurs, should I be able to find the unstripped kernel somewhere on the build system? If it makes a difference, I'm no longer using custom kernel options, just sticking with GENERIC or SMP. I'm just wanting to be able to provide some useful info if this happens again. (It's a bit disappointing in that at the point I'd upgraded them, they'd run for over 350 days since last restart in 4.8x, and they didn't make it to one month in 6.2.) -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From owner-freebsd-stable@FreeBSD.ORG Wed Nov 21 17:46:56 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3001916A41B for ; Wed, 21 Nov 2007 17:46:56 +0000 (UTC) (envelope-from chrcoluk@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.freebsd.org (Postfix) with ESMTP id B24E313C447 for ; Wed, 21 Nov 2007 17:46:55 +0000 (UTC) (envelope-from chrcoluk@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so185411uge for ; Wed, 21 Nov 2007 09:46:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=ZPbOI9L+NIfIrBSZmB9kLJqOQHJI/fzogKdyEX8V93U=; b=d6MKvUiYh4JaUOIfMsuh7eoL6tvelJpwHXPxUwXB8FPK0fB/y/qjE3sGekI+foHH67pckqcktvmczym3oWEwhsQFMDGXPH7r2u9DpaX9Xbiy/QUuQRxnAPNqsrwBPj7bAkVPqJRi98nteKVwquOhQHqZE/v1850C1dTZQ+Gba20= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=wwzx2nBiKrx1Ch7y5R0wApjTQf+EDvQgQ5dkwSvDUUYcplSFHqnhnSANnOtVxA0NmD/MkaefaxFS1AVQcFI3A1NFyTPwPLBFtisvTJuKQlPCTRt6PcM7HAsVd22mr/wnpjC/UGJlSBP30Q1AkH3U+SMUT1B64vFOZu9MxAKgG+8= Received: by 10.66.248.5 with SMTP id v5mr146111ugh.1195665700209; Wed, 21 Nov 2007 09:21:40 -0800 (PST) Received: by 10.66.250.6 with HTTP; Wed, 21 Nov 2007 09:21:40 -0800 (PST) Message-ID: <3aaaa3a0711210921t470b44f8l33af77cdcc9067cd@mail.gmail.com> Date: Wed, 21 Nov 2007 17:21:40 +0000 From: Chris To: S.N.Grigoriev In-Reply-To: <18741195233013@webmail27.yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <18741195233013@webmail27.yandex.ru> Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 6.3 or FreeBSD 7.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2007 17:46:56 -0000 On 16/11/2007, S.N.Grigoriev wrote: > > Thu, 15 Nov 2007 22:31:19 +0000 (GMT) > Robert Watson wrote: > > > I feel that the 7.0 kernel will prove to be one of our most stable, > > not to mention most performant, .0 releases to date. > > Unfortunately, that's not true. For example, parallel printing > crashes my amd64 system since the beginning of May. I've posted > PR (kern/116669) which is still open. Some other people have > reported about similar problems. > > To my mind it's a stopper defect for 7.0 because parallel > printing is one of the basic computer tasks. FreeBSD was one > of the best print servers for years. But at present it cannot > be used in such a role (at least on amd64). > > Regards, > Serguey. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > Without a doubt I have to say the old saying applies dont try to fix what isnt broke, so goto 6.3 and by the time that is EOL then 7.x should be matured and a 7.1 release will exist which I have no doubt will have fixed bugs that we dont know about now. 6.0 was the same story we were all urged to upgrade our servers to it and for many people was fine but of course there was unforseen problems that had to be fixed in 6.1 and 6.2 it is a catch 22 it needs wider scale usage for problems to be found but people wont necessarily move their servers over willingly as the risk of things breaking is too high. I have a hobby server on 7.0 beta 3 but all my web servers are staying on 6.x for the forseeable future unless I have a good reason to move to 7 even taking into account the work that has gone into improving mysql performance. Chris From owner-freebsd-stable@FreeBSD.ORG Wed Nov 21 18:19:15 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D06CE16A421 for ; Wed, 21 Nov 2007 18:19:15 +0000 (UTC) (envelope-from chrcoluk@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.freebsd.org (Postfix) with ESMTP id 4E35013C478 for ; Wed, 21 Nov 2007 18:19:15 +0000 (UTC) (envelope-from chrcoluk@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so194523uge for ; Wed, 21 Nov 2007 10:19:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=45Iz3GY5azAyqA8YrOoWVFbTQA8nSvSB0EojD3fxbKs=; b=vDIqGZREm8RDMViZ/F6KV1SQdkTray8bMnZi56NV0c0KlYOHgF/lWTDv/6CeM9iOQbn0HzJXpE2l22Wi3FXu/5EnKlUq6iaQEuAUvnQTZCLA9yVTbF/AaP0hYiqX+djzxipvHvPpTzzLi5sDILnZYykN1RYOoOeZPJHalH+Q5Z4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Y9xI75upnXT9C4a3+pXDVUpUFRZSyJrwa47+wrnbY4UaNy39BPGIEeXQaZiBowb0LW2yhsj22ARuFylf47WSyoZTQkbjxdBpcRnBaUqrAJlqQZgXXNFbMfqxdYfmNFPBAHCGpzHL0jw/VnHZIxJDoT1zbqALlWNlNETnnZw16y8= Received: by 10.67.29.20 with SMTP id g20mr626359ugj.1195669154023; Wed, 21 Nov 2007 10:19:14 -0800 (PST) Received: by 10.66.250.6 with HTTP; Wed, 21 Nov 2007 10:19:13 -0800 (PST) Message-ID: <3aaaa3a0711211019h5cb8da70te146c3a7e3a556ca@mail.gmail.com> Date: Wed, 21 Nov 2007 18:19:13 +0000 From: Chris To: pyunyh@gmail.com In-Reply-To: <20071107130019.GH70832@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47203EC3.4010203@gmail.com> <20071027030921.GC25452@cdnetworks.co.kr> <4726EE79.6050401@lomaka.org.ua> <20071030085831.GG38663@cdnetworks.co.kr> <47273920.8090003@gmail.com> <20071031033638.GC42371@cdnetworks.co.kr> <47299584.8080701@gmail.com> <20071101090811.GE47075@cdnetworks.co.kr> <4731AF50.5040403@gmail.com> <20071107130019.GH70832@cdnetworks.co.kr> Cc: Oleg Lomaka , freebsd-stable@freebsd.org Subject: Re: any hope for nfe/msk? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2007 18:19:15 -0000 On 07/11/2007, Pyun YongHyeon wrote: > On Wed, Nov 07, 2007 at 02:28:00PM +0200, Oleg Lomaka wrote: > > Hello, > > > > Pyun YongHyeon wrote: > > >On Thu, Nov 01, 2007 at 10:59:48AM +0200, Oleg Lomaka wrote: > > > > Hello, > > > > > > > > Pyun YongHyeon wrote: > > > > >On Tue, Oct 30, 2007 at 04:01:04PM +0200, Oleg Lomaka wrote: > > > > > > > > > >[...] > > > > > > > > > > > I had RxFIFO overrun again :( > > > > > > from dmest: > > > > > > msk0: Rx FIFO overrun! > > > > > > > > > >[...] > > > > > > > > > >Please try attached patch again. Sorry for the trouble. > > > > >After applying the patch show me verbosed dmesg output related with > > > > >msk(4)/PHY driver. > > > > > > > > > >Thanks for testing. > > > > > > > > > pcib1: irq 16 at device 28.0 on pci0 > > > > pcib1: domain 0 > > > > pcib1: secondary bus 2 > > > > pcib1: subordinate bus 2 > > > > pcib1: I/O decode 0x2000-0x2fff > > > > pcib1: memory decode 0xd0100000-0xd01fffff > > > > pcib1: no prefetched decode > > > > pci2: on pcib1 > > > > pci2: domain=0, physical bus=2 > > > > found-> vendor=0x11ab, dev=0x4352, revid=0x14 > > > > domain=0, bus=2, slot=0, func=0 > > > > class=02-00-00, hdrtype=0x00, mfdev=0 > > > > cmdreg=0x0007, statreg=0x4010, cachelnsz=16 (dwords) > > > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > > > intpin=a, irq=11 > > > > powerspec 2 supports D0 D1 D2 D3 current D0 > > > > MSI supports 2 messages, 64 bit > > > > map[10]: type Memory, range 64, base 0xd0100000, size 14, enabled > > > > pcib1: requested memory range 0xd0100000-0xd0103fff: good > > > > map[18]: type I/O Port, range 32, base 0x2000, size 8, enabled > > > > pcib1: requested I/O range 0x2000-0x20ff: in range > > > > pcib1: slot 0 INTA routed to irq 16 > > > > mskc0: port 0x2000-0x20ff mem > > > > 0xd0100000-0xd0103fff irq 16 at device 0.0 on pci2 > > > > mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xd0100000 > > > > mskc0: MSI count : 2 > > > > mskc0: RAM buffer size : 4KB > > > > mskc0: Port 0 : Rx Queue 2KB(0x00000000:0x000007ff) > > > > mskc0: Port 0 : Tx Queue 2KB(0x00000800:0x00000fff) > > > > msk0: on mskc0 > > > > msk0: bpf attached > > > > msk0: Ethernet address: 00:1b:24:0e:bc:26 > > > > miibus0: on msk0 > > > > e1000phy0: PHY 0 on miibus0 > > > > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > > > ioapic0: routing intpin 16 (PCI IRQ 16) to vector 49 > > > > mskc0: [MPSAFE] > > > > mskc0: [FILTER] > > > > > > > > > >So far all looks good to me. If you encounter watchdog timeouts > > >or Rx FIFO overruns let me know. > > > > > > > > > > Got it again: > > msk0: Rx FIFO overrun! > > I believe this is happening under heavy CPU usage. Now i have firefox > > compiling and watched pictures on remote windows box using rdesktop. And > > after few minutes got network freeze. > > If it only happens under heavy system loads it's probably normal. If > system is too busy to serve other jobs the msk(4) may not recevie > more packets because its receive buffer was full. Probably msk(4) > should just count the overrun errors without printing the message > such that it would save more CPU cycles. > Btw, did you also see watchdog timeout errors? > > > But it looks i didn't get any packet lost :). Take a look at ping > > statistics... funny... > > I guess something is wrong here. Latency is unacceptable. However > I have no idea why ICMP echo reponse takes so long time. Are you > using any power saving mechanism(powerd, cpufreq etc)? > > > tdevil% ping 10.1.1.254 > > PING 10.1.1.254 (10.1.1.254): 56 data bytes > > 64 bytes from 10.1.1.254: icmp_seq=0 ttl=64 time=35926.404 ms > > 64 bytes from 10.1.1.254: icmp_seq=1 ttl=64 time=34925.694 ms > > 64 bytes from 10.1.1.254: icmp_seq=2 ttl=64 time=33924.729 ms > > 64 bytes from 10.1.1.254: icmp_seq=3 ttl=64 time=32923.814 ms > > 64 bytes from 10.1.1.254: icmp_seq=4 ttl=64 time=31922.833 ms > > 64 bytes from 10.1.1.254: icmp_seq=5 ttl=64 time=30921.878 ms > > 64 bytes from 10.1.1.254: icmp_seq=6 ttl=64 time=29920.923 ms > > 64 bytes from 10.1.1.254: icmp_seq=7 ttl=64 time=28919.960 ms > > 64 bytes from 10.1.1.254: icmp_seq=8 ttl=64 time=27919.009 ms > > 64 bytes from 10.1.1.254: icmp_seq=9 ttl=64 time=26918.042 ms > > 64 bytes from 10.1.1.254: icmp_seq=10 ttl=64 time=25917.078 ms > > 64 bytes from 10.1.1.254: icmp_seq=11 ttl=64 time=24916.115 ms > > 64 bytes from 10.1.1.254: icmp_seq=12 ttl=64 time=23915.144 ms > > 64 bytes from 10.1.1.254: icmp_seq=13 ttl=64 time=22914.192 ms > > 64 bytes from 10.1.1.254: icmp_seq=14 ttl=64 time=21913.214 ms > > 64 bytes from 10.1.1.254: icmp_seq=15 ttl=64 time=20912.278 ms > > 64 bytes from 10.1.1.254: icmp_seq=16 ttl=64 time=19911.330 ms > > 64 bytes from 10.1.1.254: icmp_seq=17 ttl=64 time=18910.375 ms > > 64 bytes from 10.1.1.254: icmp_seq=18 ttl=64 time=17909.419 ms > > 64 bytes from 10.1.1.254: icmp_seq=19 ttl=64 time=16853.821 ms > > 64 bytes from 10.1.1.254: icmp_seq=20 ttl=64 time=15854.710 ms > > 64 bytes from 10.1.1.254: icmp_seq=21 ttl=64 time=14701.312 ms > > 64 bytes from 10.1.1.254: icmp_seq=22 ttl=64 time=13701.003 ms > > 64 bytes from 10.1.1.254: icmp_seq=23 ttl=64 time=12700.052 ms > > 64 bytes from 10.1.1.254: icmp_seq=24 ttl=64 time=11699.098 ms > > 64 bytes from 10.1.1.254: icmp_seq=25 ttl=64 time=10698.148 ms > > 64 bytes from 10.1.1.254: icmp_seq=36 ttl=64 time=0.463 ms > > 64 bytes from 10.1.1.254: icmp_seq=37 ttl=64 time=0.379 ms > > > > -- > Regards, > Pyun YongHyeon > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > I started having problems on nfe driver now I was using on 6.2 stable and I had polling enabled, the entire system was lagging and even when idle. I have no upgraded the box in question to 7.0 beta 3 and keeping the nfe driver on. irq22: nfe0 ehci0 1652548 20 It hasnt had heavy load since the upgrade yet. ehci0: I have no local access so cannot disable usb in the bios, if I do a new kernel disabling ehci in the kernel config will this stop the interrupt sharing and allow me to use nfe reasonably without polling as I think polling itself has been causing me problems (i use nfs). Is nfe still getting development as these are existing problems that are known but there has been no update to the below page for a while now so I am curious if its dead in the water now. http://www.f.csce.kyushu-u.ac.jp/~shigeaki/software/freebsd-nfe.html Chris From owner-freebsd-stable@FreeBSD.ORG Wed Nov 21 18:43:15 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A2E116A4E0 for ; Wed, 21 Nov 2007 18:43:14 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.freebsd.org (Postfix) with ESMTP id 2D19F13C44B for ; Wed, 21 Nov 2007 18:43:13 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lALIh6gO008705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Nov 2007 05:43:08 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.1/8.14.1) with ESMTP id lALIh6hg045093; Thu, 22 Nov 2007 05:43:06 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.1/8.14.1/Submit) id lALIh5xL045086; Thu, 22 Nov 2007 05:43:05 +1100 (EST) (envelope-from peter) Date: Thu, 22 Nov 2007 05:43:05 +1100 From: Peter Jeremy To: Alexey Popov Message-ID: <20071121184304.GM50167@server.vk2pj.dyndns.org> References: <47419AB3.5030008@chistydom.ru> <4741A7DA.2050706@chistydom.ru> <4741DA15.9000308@FreeBSD.org> <47429DB8.7040504@chistydom.ru> <4742ADFE.40902@FreeBSD.org> <4742C46A.1060701@chistydom.ru> <47432F77.3030606@FreeBSD.org> <474339E9.4080301@FreeBSD.org> <474412CF.5050200@chistydom.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eHhjakXzOLJAF9wJ" Content-Disposition: inline In-Reply-To: <474412CF.5050200@chistydom.ru> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Attilio Rao , Kris Kennaway , freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2007 18:43:15 -0000 --eHhjakXzOLJAF9wJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 21, 2007 at 02:13:19PM +0300, Alexey Popov wrote: >As mentioned in the description of your patch there is probably a=20 >scalability problem with stat() syscall on FreeBSD. I wrote a quick tool to lstat() path elements on an otherwise idle dual-core system (1.6GHz Turion64x2, FreeBSD6.3/amd64). One instance: ~62k lstat/sec. 99% sys Two instances, same path: ~43k lstat/sec/instance. 97%sys Two instances, different path, same fs: ~50k lstat/sec/instance. 97%sys Two instances, different fs: ~53k lstat/sec/instance. 98%sys The slowdowns, especially the same path instance, are worse than I would have hoped. >makes that 2000+ lstat's without problem. There's still stat(), open(),=20 >gettimeofday(), close() syscalls for each include file in PHP that i can= =20 >not switch off. Note that gettimeofday() is known to be much slower (and more accurate) on FreeBSD than on Linux. Robert Watson (if I recall correctly) has done some work on building a framework to allow a choice between slow-and-accurate and fast-and-less-precise timestamps. I don't have the reference to hand but a check of the archives should turn it up. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --eHhjakXzOLJAF9wJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHRHw4/opHv/APuIcRAls+AJoDknCu/JnJVl/CtjaTYWKryACtcgCfUplM /UKNQu8TRyqhoMCCtczz9Fs= =kM/3 -----END PGP SIGNATURE----- --eHhjakXzOLJAF9wJ-- From owner-freebsd-stable@FreeBSD.ORG Wed Nov 21 18:57:05 2007 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 347DE16A420 for ; Wed, 21 Nov 2007 18:57:05 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (adsl-75-1-14-242.dsl.scrm01.sbcglobal.net [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id CDDEB13C45D for ; Wed, 21 Nov 2007 18:57:03 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id lALIb8gB065394; Wed, 21 Nov 2007 10:37:12 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200711211837.lALIb8gB065394@gw.catspoiler.org> Date: Wed, 21 Nov 2007 10:37:08 -0800 (PST) From: Don Lewis To: chrcoluk@gmail.com In-Reply-To: <3aaaa3a0711211019h5cb8da70te146c3a7e3a556ca@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: pyunyh@gmail.com, oleg.lomaka@gmail.com, freebsd-stable@FreeBSD.org Subject: Re: any hope for nfe/msk? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2007 18:57:05 -0000 On 21 Nov, Chris wrote: > On 07/11/2007, Pyun YongHyeon wrote: >> On Wed, Nov 07, 2007 at 02:28:00PM +0200, Oleg Lomaka wrote: >> > Hello, >> > >> > Pyun YongHyeon wrote: >> > >On Thu, Nov 01, 2007 at 10:59:48AM +0200, Oleg Lomaka wrote: >> > > > Hello, >> > > > >> > > > Pyun YongHyeon wrote: >> > > > >On Tue, Oct 30, 2007 at 04:01:04PM +0200, Oleg Lomaka wrote: >> > > > > >> > > > >[...] >> > > > > >> > > > > > I had RxFIFO overrun again :( >> > > > > > from dmest: >> > > > > > msk0: Rx FIFO overrun! >> > > > > >> > > > >[...] >> > > > > >> > > > >Please try attached patch again. Sorry for the trouble. >> > > > >After applying the patch show me verbosed dmesg output related with >> > > > >msk(4)/PHY driver. >> > > > > >> > > > >Thanks for testing. >> > > > > >> > > > pcib1: irq 16 at device 28.0 on pci0 >> > > > pcib1: domain 0 >> > > > pcib1: secondary bus 2 >> > > > pcib1: subordinate bus 2 >> > > > pcib1: I/O decode 0x2000-0x2fff >> > > > pcib1: memory decode 0xd0100000-0xd01fffff >> > > > pcib1: no prefetched decode >> > > > pci2: on pcib1 >> > > > pci2: domain=0, physical bus=2 >> > > > found-> vendor=0x11ab, dev=0x4352, revid=0x14 >> > > > domain=0, bus=2, slot=0, func=0 >> > > > class=02-00-00, hdrtype=0x00, mfdev=0 >> > > > cmdreg=0x0007, statreg=0x4010, cachelnsz=16 (dwords) >> > > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> > > > intpin=a, irq=11 >> > > > powerspec 2 supports D0 D1 D2 D3 current D0 >> > > > MSI supports 2 messages, 64 bit >> > > > map[10]: type Memory, range 64, base 0xd0100000, size 14, enabled >> > > > pcib1: requested memory range 0xd0100000-0xd0103fff: good >> > > > map[18]: type I/O Port, range 32, base 0x2000, size 8, enabled >> > > > pcib1: requested I/O range 0x2000-0x20ff: in range >> > > > pcib1: slot 0 INTA routed to irq 16 >> > > > mskc0: port 0x2000-0x20ff mem >> > > > 0xd0100000-0xd0103fff irq 16 at device 0.0 on pci2 >> > > > mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xd0100000 >> > > > mskc0: MSI count : 2 >> > > > mskc0: RAM buffer size : 4KB >> > > > mskc0: Port 0 : Rx Queue 2KB(0x00000000:0x000007ff) >> > > > mskc0: Port 0 : Tx Queue 2KB(0x00000800:0x00000fff) >> > > > msk0: on mskc0 >> > > > msk0: bpf attached >> > > > msk0: Ethernet address: 00:1b:24:0e:bc:26 >> > > > miibus0: on msk0 >> > > > e1000phy0: PHY 0 on miibus0 >> > > > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >> > > > ioapic0: routing intpin 16 (PCI IRQ 16) to vector 49 >> > > > mskc0: [MPSAFE] >> > > > mskc0: [FILTER] >> > > > >> > > >> > >So far all looks good to me. If you encounter watchdog timeouts >> > >or Rx FIFO overruns let me know. >> > > >> > > >> > >> > Got it again: >> > msk0: Rx FIFO overrun! >> > I believe this is happening under heavy CPU usage. Now i have firefox >> > compiling and watched pictures on remote windows box using rdesktop. And >> > after few minutes got network freeze. >> >> If it only happens under heavy system loads it's probably normal. If >> system is too busy to serve other jobs the msk(4) may not recevie >> more packets because its receive buffer was full. Probably msk(4) >> should just count the overrun errors without printing the message >> such that it would save more CPU cycles. >> Btw, did you also see watchdog timeout errors? >> >> > But it looks i didn't get any packet lost :). Take a look at ping >> > statistics... funny... >> >> I guess something is wrong here. Latency is unacceptable. However >> I have no idea why ICMP echo reponse takes so long time. Are you >> using any power saving mechanism(powerd, cpufreq etc)? >> >> > tdevil% ping 10.1.1.254 >> > PING 10.1.1.254 (10.1.1.254): 56 data bytes >> > 64 bytes from 10.1.1.254: icmp_seq=0 ttl=64 time=35926.404 ms >> > 64 bytes from 10.1.1.254: icmp_seq=1 ttl=64 time=34925.694 ms >> > 64 bytes from 10.1.1.254: icmp_seq=2 ttl=64 time=33924.729 ms >> > 64 bytes from 10.1.1.254: icmp_seq=3 ttl=64 time=32923.814 ms >> > 64 bytes from 10.1.1.254: icmp_seq=4 ttl=64 time=31922.833 ms >> > 64 bytes from 10.1.1.254: icmp_seq=5 ttl=64 time=30921.878 ms >> > 64 bytes from 10.1.1.254: icmp_seq=6 ttl=64 time=29920.923 ms >> > 64 bytes from 10.1.1.254: icmp_seq=7 ttl=64 time=28919.960 ms >> > 64 bytes from 10.1.1.254: icmp_seq=8 ttl=64 time=27919.009 ms >> > 64 bytes from 10.1.1.254: icmp_seq=9 ttl=64 time=26918.042 ms >> > 64 bytes from 10.1.1.254: icmp_seq=10 ttl=64 time=25917.078 ms >> > 64 bytes from 10.1.1.254: icmp_seq=11 ttl=64 time=24916.115 ms >> > 64 bytes from 10.1.1.254: icmp_seq=12 ttl=64 time=23915.144 ms >> > 64 bytes from 10.1.1.254: icmp_seq=13 ttl=64 time=22914.192 ms >> > 64 bytes from 10.1.1.254: icmp_seq=14 ttl=64 time=21913.214 ms >> > 64 bytes from 10.1.1.254: icmp_seq=15 ttl=64 time=20912.278 ms >> > 64 bytes from 10.1.1.254: icmp_seq=16 ttl=64 time=19911.330 ms >> > 64 bytes from 10.1.1.254: icmp_seq=17 ttl=64 time=18910.375 ms >> > 64 bytes from 10.1.1.254: icmp_seq=18 ttl=64 time=17909.419 ms >> > 64 bytes from 10.1.1.254: icmp_seq=19 ttl=64 time=16853.821 ms >> > 64 bytes from 10.1.1.254: icmp_seq=20 ttl=64 time=15854.710 ms >> > 64 bytes from 10.1.1.254: icmp_seq=21 ttl=64 time=14701.312 ms >> > 64 bytes from 10.1.1.254: icmp_seq=22 ttl=64 time=13701.003 ms >> > 64 bytes from 10.1.1.254: icmp_seq=23 ttl=64 time=12700.052 ms >> > 64 bytes from 10.1.1.254: icmp_seq=24 ttl=64 time=11699.098 ms >> > 64 bytes from 10.1.1.254: icmp_seq=25 ttl=64 time=10698.148 ms >> > 64 bytes from 10.1.1.254: icmp_seq=36 ttl=64 time=0.463 ms >> > 64 bytes from 10.1.1.254: icmp_seq=37 ttl=64 time=0.379 ms >> > >> >> -- >> Regards, >> Pyun YongHyeon >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> > > I started having problems on nfe driver now I was using on 6.2 stable > and I had polling enabled, the entire system was lagging and even when > idle. I have no upgraded the box in question to 7.0 beta 3 and > keeping the nfe driver on. > > irq22: nfe0 ehci0 1652548 20 > > It hasnt had heavy load since the upgrade yet. > > ehci0: > > I have no local access so cannot disable usb in the bios, if I do a > new kernel disabling ehci in the kernel config will this stop the > interrupt sharing and allow me to use nfe reasonably without polling > as I think polling itself has been causing me problems (i use nfs). > > Is nfe still getting development as these are existing problems that > are known but there has been no update to the below page for a while > now so I am curious if its dead in the water now. > > http://www.f.csce.kyushu-u.ac.jp/~shigeaki/software/freebsd-nfe.html > > Chris I've also seen wierd problems on a machine that shares an interrupt between nfe and ehci. I'm hoping that this recent commit to -CURRENT fixes the problem. I'm planning on trying it on my 7.0-BETA machine in the next day or so. scottl 2007-11-21 04:03:51 UTC FreeBSD src repository Modified files: sys/amd64/amd64 intr_machdep.c sys/i386/i386 intr_machdep.c sys/ia64/ia64 interrupt.c sys/powerpc/powerpc intr_machdep.c sys/sparc64/sparc64 intr_machdep.c Log: Extend critical section coverage in the low-level interrupt handlers to include the ithread scheduling step. Without this, a preemption might occur in between the interrupt getting masked and the ithread getting scheduled. Since the interrupt handler runs in the context of curthread, the scheudler might see it as having a such a low priority on a busy system that it doesn't get to run for a _long_ time, leaving the interrupt stranded in a disabled state. The only way that the preemption can happen is by a fast/filter handler triggering a schduling event earlier in the handler, so this problem can only happen for cases where an interrupt is being shared by both a fast/filter handler and an ithread handler. Unfortunately, it seems to be common for this sharing to happen with network and USB devices, for example. This fixes many of the mysterious TCP session timeouts and NIC watchdogs that were being reported. Many thanks to Sam Lefler for getting to the bottom of this problem. Reviewed by: jhb, jeff, silby Revision Changes Path 1.35 +1 -1 src/sys/amd64/amd64/intr_machdep.c 1.30 +1 -1 src/sys/i386/i386/intr_machdep.c 1.62 +1 -1 src/sys/ia64/ia64/interrupt.c 1.14 +1 -1 src/sys/powerpc/powerpc/intr_machdep.c 1.28 +1 -1 src/sys/sparc64/sparc64/intr_machdep.c From owner-freebsd-stable@FreeBSD.ORG Wed Nov 21 19:39:17 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8C9216A46D for ; Wed, 21 Nov 2007 19:39:17 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 34AF913C457 for ; Wed, 21 Nov 2007 19:39:15 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id lALJdERL064472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Nov 2007 11:39:15 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <47448963.9070500@errno.com> Date: Wed, 21 Nov 2007 11:39:15 -0800 From: Sam Leffler User-Agent: Thunderbird 2.0.0.6 (X11/20070814) MIME-Version: 1.0 To: Don Lewis References: <200711211837.lALIb8gB065394@gw.catspoiler.org> In-Reply-To: <200711211837.lALIb8gB065394@gw.catspoiler.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-Rhyolite-Metrics: o.com; whitelist Cc: chrcoluk@gmail.com, pyunyh@gmail.com, oleg.lomaka@gmail.com, freebsd-stable@freebsd.org Subject: Re: any hope for nfe/msk? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2007 19:39:18 -0000 Don Lewis wrote: > On 21 Nov, Chris wrote: > >> On 07/11/2007, Pyun YongHyeon wrote: >> >>> On Wed, Nov 07, 2007 at 02:28:00PM +0200, Oleg Lomaka wrote: >>> > Hello, >>> > >>> > Pyun YongHyeon wrote: >>> > >On Thu, Nov 01, 2007 at 10:59:48AM +0200, Oleg Lomaka wrote: >>> > > > Hello, >>> > > > >>> > > > Pyun YongHyeon wrote: >>> > > > >On Tue, Oct 30, 2007 at 04:01:04PM +0200, Oleg Lomaka wrote: >>> > > > > >>> > > > >[...] >>> > > > > >>> > > > > > I had RxFIFO overrun again :( >>> > > > > > from dmest: >>> > > > > > msk0: Rx FIFO overrun! >>> > > > > >>> > > > >[...] >>> > > > > >>> > > > >Please try attached patch again. Sorry for the trouble. >>> > > > >After applying the patch show me verbosed dmesg output related with >>> > > > >msk(4)/PHY driver. >>> > > > > >>> > > > >Thanks for testing. >>> > > > > >>> > > > pcib1: irq 16 at device 28.0 on pci0 >>> > > > pcib1: domain 0 >>> > > > pcib1: secondary bus 2 >>> > > > pcib1: subordinate bus 2 >>> > > > pcib1: I/O decode 0x2000-0x2fff >>> > > > pcib1: memory decode 0xd0100000-0xd01fffff >>> > > > pcib1: no prefetched decode >>> > > > pci2: on pcib1 >>> > > > pci2: domain=0, physical bus=2 >>> > > > found-> vendor=0x11ab, dev=0x4352, revid=0x14 >>> > > > domain=0, bus=2, slot=0, func=0 >>> > > > class=02-00-00, hdrtype=0x00, mfdev=0 >>> > > > cmdreg=0x0007, statreg=0x4010, cachelnsz=16 (dwords) >>> > > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>> > > > intpin=a, irq=11 >>> > > > powerspec 2 supports D0 D1 D2 D3 current D0 >>> > > > MSI supports 2 messages, 64 bit >>> > > > map[10]: type Memory, range 64, base 0xd0100000, size 14, enabled >>> > > > pcib1: requested memory range 0xd0100000-0xd0103fff: good >>> > > > map[18]: type I/O Port, range 32, base 0x2000, size 8, enabled >>> > > > pcib1: requested I/O range 0x2000-0x20ff: in range >>> > > > pcib1: slot 0 INTA routed to irq 16 >>> > > > mskc0: port 0x2000-0x20ff mem >>> > > > 0xd0100000-0xd0103fff irq 16 at device 0.0 on pci2 >>> > > > mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xd0100000 >>> > > > mskc0: MSI count : 2 >>> > > > mskc0: RAM buffer size : 4KB >>> > > > mskc0: Port 0 : Rx Queue 2KB(0x00000000:0x000007ff) >>> > > > mskc0: Port 0 : Tx Queue 2KB(0x00000800:0x00000fff) >>> > > > msk0: on mskc0 >>> > > > msk0: bpf attached >>> > > > msk0: Ethernet address: 00:1b:24:0e:bc:26 >>> > > > miibus0: on msk0 >>> > > > e1000phy0: PHY 0 on miibus0 >>> > > > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >>> > > > ioapic0: routing intpin 16 (PCI IRQ 16) to vector 49 >>> > > > mskc0: [MPSAFE] >>> > > > mskc0: [FILTER] >>> > > > >>> > > >>> > >So far all looks good to me. If you encounter watchdog timeouts >>> > >or Rx FIFO overruns let me know. >>> > > >>> > > >>> > >>> > Got it again: >>> > msk0: Rx FIFO overrun! >>> > I believe this is happening under heavy CPU usage. Now i have firefox >>> > compiling and watched pictures on remote windows box using rdesktop. And >>> > after few minutes got network freeze. >>> >>> If it only happens under heavy system loads it's probably normal. If >>> system is too busy to serve other jobs the msk(4) may not recevie >>> more packets because its receive buffer was full. Probably msk(4) >>> should just count the overrun errors without printing the message >>> such that it would save more CPU cycles. >>> Btw, did you also see watchdog timeout errors? >>> >>> > But it looks i didn't get any packet lost :). Take a look at ping >>> > statistics... funny... >>> >>> I guess something is wrong here. Latency is unacceptable. However >>> I have no idea why ICMP echo reponse takes so long time. Are you >>> using any power saving mechanism(powerd, cpufreq etc)? >>> >>> > tdevil% ping 10.1.1.254 >>> > PING 10.1.1.254 (10.1.1.254): 56 data bytes >>> > 64 bytes from 10.1.1.254: icmp_seq=0 ttl=64 time=35926.404 ms >>> > 64 bytes from 10.1.1.254: icmp_seq=1 ttl=64 time=34925.694 ms >>> > 64 bytes from 10.1.1.254: icmp_seq=2 ttl=64 time=33924.729 ms >>> > 64 bytes from 10.1.1.254: icmp_seq=3 ttl=64 time=32923.814 ms >>> > 64 bytes from 10.1.1.254: icmp_seq=4 ttl=64 time=31922.833 ms >>> > 64 bytes from 10.1.1.254: icmp_seq=5 ttl=64 time=30921.878 ms >>> > 64 bytes from 10.1.1.254: icmp_seq=6 ttl=64 time=29920.923 ms >>> > 64 bytes from 10.1.1.254: icmp_seq=7 ttl=64 time=28919.960 ms >>> > 64 bytes from 10.1.1.254: icmp_seq=8 ttl=64 time=27919.009 ms >>> > 64 bytes from 10.1.1.254: icmp_seq=9 ttl=64 time=26918.042 ms >>> > 64 bytes from 10.1.1.254: icmp_seq=10 ttl=64 time=25917.078 ms >>> > 64 bytes from 10.1.1.254: icmp_seq=11 ttl=64 time=24916.115 ms >>> > 64 bytes from 10.1.1.254: icmp_seq=12 ttl=64 time=23915.144 ms >>> > 64 bytes from 10.1.1.254: icmp_seq=13 ttl=64 time=22914.192 ms >>> > 64 bytes from 10.1.1.254: icmp_seq=14 ttl=64 time=21913.214 ms >>> > 64 bytes from 10.1.1.254: icmp_seq=15 ttl=64 time=20912.278 ms >>> > 64 bytes from 10.1.1.254: icmp_seq=16 ttl=64 time=19911.330 ms >>> > 64 bytes from 10.1.1.254: icmp_seq=17 ttl=64 time=18910.375 ms >>> > 64 bytes from 10.1.1.254: icmp_seq=18 ttl=64 time=17909.419 ms >>> > 64 bytes from 10.1.1.254: icmp_seq=19 ttl=64 time=16853.821 ms >>> > 64 bytes from 10.1.1.254: icmp_seq=20 ttl=64 time=15854.710 ms >>> > 64 bytes from 10.1.1.254: icmp_seq=21 ttl=64 time=14701.312 ms >>> > 64 bytes from 10.1.1.254: icmp_seq=22 ttl=64 time=13701.003 ms >>> > 64 bytes from 10.1.1.254: icmp_seq=23 ttl=64 time=12700.052 ms >>> > 64 bytes from 10.1.1.254: icmp_seq=24 ttl=64 time=11699.098 ms >>> > 64 bytes from 10.1.1.254: icmp_seq=25 ttl=64 time=10698.148 ms >>> > 64 bytes from 10.1.1.254: icmp_seq=36 ttl=64 time=0.463 ms >>> > 64 bytes from 10.1.1.254: icmp_seq=37 ttl=64 time=0.379 ms >>> > >>> >>> -- >>> Regards, >>> Pyun YongHyeon >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >>> >>> >> I started having problems on nfe driver now I was using on 6.2 stable >> and I had polling enabled, the entire system was lagging and even when >> idle. I have no upgraded the box in question to 7.0 beta 3 and >> keeping the nfe driver on. >> >> irq22: nfe0 ehci0 1652548 20 >> >> It hasnt had heavy load since the upgrade yet. >> >> ehci0: >> >> I have no local access so cannot disable usb in the bios, if I do a >> new kernel disabling ehci in the kernel config will this stop the >> interrupt sharing and allow me to use nfe reasonably without polling >> as I think polling itself has been causing me problems (i use nfs). >> >> Is nfe still getting development as these are existing problems that >> are known but there has been no update to the below page for a while >> now so I am curious if its dead in the water now. >> >> http://www.f.csce.kyushu-u.ac.jp/~shigeaki/software/freebsd-nfe.html >> >> Chris >> > > I've also seen wierd problems on a machine that shares an interrupt > between nfe and ehci. I'm hoping that this recent commit to -CURRENT > fixes the problem. I'm planning on trying it on my 7.0-BETA machine in > the next day or so. > > scottl 2007-11-21 04:03:51 UTC > > FreeBSD src repository > > Modified files: > sys/amd64/amd64 intr_machdep.c > sys/i386/i386 intr_machdep.c > sys/ia64/ia64 interrupt.c > sys/powerpc/powerpc intr_machdep.c > sys/sparc64/sparc64 intr_machdep.c > Log: > Extend critical section coverage in the low-level interrupt handlers to > include the ithread scheduling step. Without this, a preemption might > occur in between the interrupt getting masked and the ithread getting > scheduled. Since the interrupt handler runs in the context of curthread, > the scheudler might see it as having a such a low priority on a busy system > that it doesn't get to run for a _long_ time, leaving the interrupt stranded > in a disabled state. The only way that the preemption can happen is by > a fast/filter handler triggering a schduling event earlier in the handler, > so this problem can only happen for cases where an interrupt is being > shared by both a fast/filter handler and an ithread handler. Unfortunately, > it seems to be common for this sharing to happen with network and USB > devices, for example. This fixes many of the mysterious TCP session > timeouts and NIC watchdogs that were being reported. Many thanks to Sam > Lefler for getting to the bottom of this problem. > > nfe+ohci was the combo I had that prompted me to fix this. Sam From owner-freebsd-stable@FreeBSD.ORG Wed Nov 21 19:49:39 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB38B16A420; Wed, 21 Nov 2007 19:49:39 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id C0EB713C478; Wed, 21 Nov 2007 19:49:38 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47448BD8.60500@FreeBSD.org> Date: Wed, 21 Nov 2007 20:49:44 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Alexey Popov References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> <4741A7DA.2050706@chistydom.ru> <4741DA15.9000308@FreeBSD.org> <47429DB8.7040504@chistydom.ru> <4742ADFE.40902@FreeBSD.org> <4742C46A.1060701@chistydom.ru> <47432F77.3030606@FreeBSD.org> <474339E9.4080301@FreeBSD.org> <474412CF.5050200@chistydom.ru> In-Reply-To: <474412CF.5050200@chistydom.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Attilio Rao , freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2007 19:49:39 -0000 Alexey Popov wrote: > Hi. > > Kris Kennaway wrote: >>> In the meantime there is unfortunately not a lot that can be done, >>> AFAICT. There is one hack that I will send you later but it is not >>> likely to help much. I will also think about how to track down the >>> cause of the contention further (the profiling trace only shows that >>> it comes mostly from vget/vput but doesn't show where these are >>> called from). >> Actually this patch might help. It doesn't replace lockmgr but it >> does fix a silly thundering herd behaviour. It probably needs some >> adjustment to get it to apply cleanly (it is about 7 months old), and >> I apparently stopped using it because I ran into deadlocks. It might >> be stable enough to at least see how much it helps. > Sorry, I didn't try you patch yet but I have other news. > > As mentioned in the description of your patch there is probably a > scalability problem with stat() syscall on FreeBSD. Not as such, that was just a random example I chose to illustrate the lockmgr problems I described earlier. Try the patch I posted, it should help. Kris From owner-freebsd-stable@FreeBSD.ORG Wed Nov 21 19:53:33 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D7E216A420; Wed, 21 Nov 2007 19:53:33 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id 82C9613C467; Wed, 21 Nov 2007 19:53:32 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47448CC2.7030100@FreeBSD.org> Date: Wed, 21 Nov 2007 20:53:38 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Ivan Voras References: <4741905E.8050300@chistydom.ru> <4742ADFE.40902@FreeBSD.org> <4742C46A.1060701@chistydom.ru> <47432F77.3030606@FreeBSD.org> <474339E9.4080301@FreeBSD.org> <4743629B.9090408@FreeBSD.org> <47440C10.5060608@FreeBSD.org> <47440E55.3060909@FreeBSD.org> <9bbcef730711210320s73c0625bh25ba2561b270f237@mail.gmail.com> In-Reply-To: <9bbcef730711210320s73c0625bh25ba2561b270f237@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2007 19:53:33 -0000 Ivan Voras wrote: > On 21/11/2007, Kris Kennaway wrote: >> Ivan Voras wrote: > >>> Yes, but I had to verify it anyway :) >> You haven't verified anything until you look at how much work the system >> is doing, before and after. > > I have, and it's roughly the same (50 +/- 2 queries/s). > > (meaning that I'm not interested in exact statistics here, but in > order-of-magnitude changes, which didn't happen). OK, let's take a step back here. Did you obtain the lock profiling trace and verify that you're seeing the same problem as Alexey? Can I see the trace? Kris From owner-freebsd-stable@FreeBSD.ORG Wed Nov 21 20:18:51 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD1DE16A421; Wed, 21 Nov 2007 20:18:51 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id 316E913C455; Wed, 21 Nov 2007 20:18:50 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <474492B0.1010108@FreeBSD.org> Date: Wed, 21 Nov 2007 21:18:56 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Kris Kennaway References: <47137D36.1020305@chistydom.ru> <47149E6E.9000500@chistydom.ru> <4715035D.2090802@FreeBSD.org> <4715C297.1020905@chistydom.ru> <4715C5D7.7060806@FreeBSD.org> <471EE4D9.5080307@chistydom.ru> <4723BF87.20302@FreeBSD.org> <47344E47.9050908@chistydom.ru> <47349A17.3080806@FreeBSD.org> <47373B43.9060406@chistydom.ru> <4739557A.6090209@chistydom.ru> <4741EE9E.9050406@FreeBSD.org> In-Reply-To: <4741EE9E.9050406@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Panagiotis Christias , freebsd-stable@freebsd.org, Alexey Popov Subject: Re: amrd disk performance drop after running under high load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2007 20:18:51 -0000 Kris Kennaway wrote: > Alexey Popov wrote: >> Hi. >> >> Panagiotis Christias wrote: >>>>>>> In the "good" case you are getting a much higher interrupt rate but >>>>>>> with the data you provided I can't tell where from. You need to run >>>>>>> vmstat -i at regular intervals (e.g. every 10 seconds for a minute) >>>>>>> during the "good" and "bad" times, since it only provides counters >>>>>>> and an average rate over the uptime of the system. >>>>>> Now I'm running 10-process lighttpd and the problem became no so big. >>>>>> >>>>>> I collected interrupt stats and it shows no relation beetween >>>>>> ionterrupts and slowdowns. Here is it: >>>>>> http://83.167.98.162/gprof/intr-graph/ >>>>>> >>>>>> Also I have similiar statistics on mutex profiling and it shows >>>>>> there's no problem in mutexes. >>>>>> http://83.167.98.162/gprof/mtx-graph/mtxgifnew/ >>>>>> >>>>>> I have no idea what else to check. >>>>> I don't know what this graph is showing me :) When precisely is the >>>>> system behaving poorly? >>> what is your RAID controller configuration (read ahead/cache/write >>> policy)? I have seen weird/bogus numbers (~100% busy) reported by >>> systat -v when read ahead was enabled on LSI/amr controllers. >> >> >> ********************************************************************** >> Existing Logical Drive Information >> By LSI Logic Corp.,USA >> >> ********************************************************************** >> [Note: For SATA-2, 4 and 6 channel controllers, please specify >> Ch=0 Id=0..15 for specifying physical drive(Ch=channel, >> Id=Target)] >> >> >> Logical Drive : 0( Adapter: 0 ): Status: OPTIMAL >> --------------------------------------------------- >> SpanDepth :01 RaidLevel: 5 RdAhead : Adaptive Cache: >> DirectIo >> StripSz :064KB Stripes : 6 WrPolicy: WriteBack >> >> Logical Drive 0 : SpanLevel_0 Disks >> Chnl Target StartBlock Blocks Physical Target Status >> ---- ------ ---------- ------ ---------------------- >> 0 00 0x00000000 0x22ec0000 ONLINE >> 0 01 0x00000000 0x22ec0000 ONLINE >> 0 02 0x00000000 0x22ec0000 ONLINE >> 0 03 0x00000000 0x22ec0000 ONLINE >> 0 04 0x00000000 0x22ec0000 ONLINE >> 0 05 0x00000000 0x22ec0000 ONLINE >> >> I tried to run with disabled Read-ahead, but it didn't help. > > I just ran into this myself, and apparently it can be caused by "Patrol > Reads" where the adapter periodically scans the disks to look for media > errors. You can turn this off using -stopPR with the megarc port. > > Kris > Oops, -disPR is the correct command to disable, -stopPR just halts a PR event in progress. Kris From owner-freebsd-stable@FreeBSD.ORG Thu Nov 22 07:39:03 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8893016A417; Thu, 22 Nov 2007 07:39:03 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from hermes.hw.ru (hermes.hw.ru [80.68.240.91]) by mx1.freebsd.org (Postfix) with ESMTP id A7AD613C457; Thu, 22 Nov 2007 07:39:02 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from [80.68.244.40] (account a_popov@rbc.ru [80.68.244.40] verified) by hermes.hw.ru (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 202078850; Thu, 22 Nov 2007 10:38:26 +0300 Message-ID: <474531E8.6020006@chistydom.ru> Date: Thu, 22 Nov 2007 10:38:16 +0300 From: Alexey Popov User-Agent: Thunderbird 2.0.0.6 (X11/20070924) MIME-Version: 1.0 To: Max Laier References: <4741905E.8050300@chistydom.ru> <474339E9.4080301@FreeBSD.org> <4743629B.9090408@FreeBSD.org> <200711220050.51408.max@love2party.net> In-Reply-To: <200711220050.51408.max@love2party.net> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Attilio Rao , peterjeremy@optushome.com.au, Kris Kennaway , freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2007 07:39:03 -0000 Hi. Max Laier wrote: > I rolled a tiny, simple, possibly braindamaged benchmark (but then again > php code tends to be braindamaged): test.php includes 1000 different, > essential empty files and is strated over and over from a shell script > which counts the runs completed within 60seconds. 1-8,128 scripts are > started in parallel. > On a 2x dual Opteron running amd64 I get: This problem is almost invisible for me on 4-core servers. Could you try your benchmark on server with 8 or more cores??? With best regards, Alexey Popov From owner-freebsd-stable@FreeBSD.ORG Thu Nov 22 08:00:49 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C07316A419 for ; Thu, 22 Nov 2007 08:00:49 +0000 (UTC) (envelope-from gepu@iogyte.ro) Received: from iogyte.ro (mail.iogyte.ro [62.231.111.163]) by mx1.freebsd.org (Postfix) with SMTP id CBB7513C4D5 for ; Thu, 22 Nov 2007 08:00:05 +0000 (UTC) (envelope-from gepu@iogyte.ro) Received: (qmail 73636 invoked by uid 1001); 22 Nov 2007 06:59:56 -0000 Date: Thu, 22 Nov 2007 08:59:56 +0200 From: Dan Epure To: Robert Watson Message-ID: <20071122065956.GH19354@iogyte.ro> References: <20071118012616.GF19354@iogyte.ro> <20071118144243.B97497@fledge.watson.org> <20071121215807.F60495@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071121215807.F60495@fledge.watson.org> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, csjp@FreeBSD.org Subject: Re: pseudo terminals in 7.0 - pts implementation X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dan Epure List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2007 08:00:49 -0000 Hi Robert, Thank you for your answer. In this case the first problem (gnu screen) does not deserve any attention because it is related to the ptmx clonig. My goal is to find a way to increase the number os pseudo terminal. the traditional 256 pty is not sufficient for my needs. Is there any way to do this on freebsd other than using ptmx cloning ? On Wed, Nov 21, 2007 at 10:00:02PM +0000, Robert Watson wrote: > > On Sun, 18 Nov 2007, Robert Watson wrote: > >> On Sun, 18 Nov 2007, Dan Epure wrote: >> >>> 7.0-BETA3 still has issues regarding the pts implementation . problems >>> found: 1. - GNU screen: starting a screen, opening a few windows and >>> quiting screen leaves the allocated pseudo terminal in use. 100 screen >>> user, using each one opening 10 windows will deplete the default of 1000 >>> pseudo terminals leaving the system unusable. 2. - 'ls /dev/ptmx' creates >>> an additional entry in /dev/pty/. when the number of entries equals >>> kern.pts.max the system became unusable. >> >> The first of these is likely a reference management bug of some sort -- I >> find that if I close a pty in screen by exiting the shell, the pts device >> is GC'd properly, but if I close it by killing the session with ctrl-k, >> then the pts device is not properly GC'd and processes hung off it not >> properly killed. I believe that closing the master device is not properly >> kicking the slave device and causing its consumers to exit, hence the pts >> device not being closd and released. Christian was taking a look at this >> a couple of days ago, and I've CC'd him. >> >> The second problem is more tricky, and has to do with the cloning model. >> Similar problems can exist with other variations on the ptmx >> implementation, and I need to give some thought to how to address this. > > Dan, > > So, thinking a bit more about the second problem, I think it is inherrent > to the way we've designed the /dev/ptmx cloning model, which is > unfortunate. My current leaning is to disable the ptmx mechanism in 7.0 > and put together a revised one for 7.1. The reason to do this is to avoid > encoding the user<->kernel interface for allocating pty's via ptmx along > the current lines, which we'd then need to continue supporting in future > releases. I'm going to spend a bit of time over the next day or two > looking at revising the interface to fix these problems. > > Robert N M Watson > Computer Laboratory > University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Thu Nov 22 08:13:57 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0400016A474; Thu, 22 Nov 2007 08:13:57 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.freebsd.org (Postfix) with ESMTP id 8933513C457; Thu, 22 Nov 2007 08:13:56 +0000 (UTC) (envelope-from max@love2party.net) Received: from amd64.laiers.local (dslb-088-066-042-157.pools.arcor-ip.net [88.66.42.157]) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis) id 0ML31I-1IuzKP2JYF-0004cD; Thu, 22 Nov 2007 00:49:58 +0100 From: Max Laier Organization: FreeBSD To: freebsd-stable@freebsd.org Date: Thu, 22 Nov 2007 00:50:42 +0100 User-Agent: KMail/1.9.7 References: <4741905E.8050300@chistydom.ru> <474339E9.4080301@FreeBSD.org> <4743629B.9090408@FreeBSD.org> In-Reply-To: <4743629B.9090408@FreeBSD.org> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1663567.M1vWNXAkZY"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200711220050.51408.max@love2party.net> X-Provags-ID: V01U2FsdGVkX19K5eQDj+vmLeCvx26CRNaYpzdNyI9QFEkbL5b ic8hrqTSd3fhbxh35iE1zEM9WHeRvs4+23v5+9tud/u20MFjC9 /J4fd23mcQSPMklP4PWgN7HnnYh0ahU3aoc+i8e68Y= Cc: Attilio Rao , Kris Kennaway , Alexey Popov Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2007 08:13:57 -0000 --nextPart1663567.M1vWNXAkZY Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 20 November 2007, Kris Kennaway wrote: > Kris Kennaway wrote: > > Kris Kennaway wrote: > >> In the meantime there is unfortunately not a lot that can be done, > >> AFAICT. There is one hack that I will send you later but it is not > >> likely to help much. I will also think about how to track down the > >> cause of the contention further (the profiling trace only shows that > >> it comes mostly from vget/vput but doesn't show where these are > >> called from). > > > > Actually this patch might help. It doesn't replace lockmgr but it > > does fix a silly thundering herd behaviour. It probably needs some > > adjustment to get it to apply cleanly (it is about 7 months old), and > > I apparently stopped using it because I ran into deadlocks. It might > > be stable enough to at least see how much it helps. > > > > Set the vfs.lookup_shared=3D1 sysctl to enable the other half of the > > patch. > > > > Kris > > Try this one instead, it applies to HEAD. You'll need to manually > enter the paths though because of how p4 mangles diffs. I rolled a tiny, simple, possibly braindamaged benchmark (but then again=20 php code tends to be braindamaged): test.php includes 1000 different,=20 essential empty files and is strated over and over from a shell script=20 which counts the runs completed within 60seconds. 1-8,128 scripts are=20 started in parallel. On a 2x dual Opteron running amd64 I get: stock RELENG_7 w/o patch ULE: jobs sum runs gain 1 617 1 2 784 1.27 3 939 1.52 4 1015 1.65 5 658 1.07 6 642 1.04 7 666 1.08 8 696 1.13 128 726 1.18 RELENG_7 patched ULE vfs.lookup_shared=3D1: jobs sum runs gain 1 637 1 2 784 1.23 3 973 1.53 4 1104 1.73 5 708 1.11 6 733 1.15 7 776 1.22 8 840 1.32 128 936 1.47 So there is still a lot of room for improvement here. I'll rebuild with=20 lock profiling tomorrow and see what I can gather. Anything you'd like=20 to see in particular? =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1663567.M1vWNXAkZY Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHRMRbXyyEoT62BG0RAnQOAJ9a3antCCJXeVi0kWWOR3nsrru2+ACfaz3T 0eED8jBN1DCMR2OqjtBOqzs= =y37s -----END PGP SIGNATURE----- --nextPart1663567.M1vWNXAkZY-- From owner-freebsd-stable@FreeBSD.ORG Thu Nov 22 08:16:30 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA68916A47A; Thu, 22 Nov 2007 08:16:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5266313C4E8; Thu, 22 Nov 2007 08:16:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 3945E46E7C; Wed, 21 Nov 2007 17:02:59 -0500 (EST) Date: Wed, 21 Nov 2007 22:00:02 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Dan Epure In-Reply-To: <20071118144243.B97497@fledge.watson.org> Message-ID: <20071121215807.F60495@fledge.watson.org> References: <20071118012616.GF19354@iogyte.ro> <20071118144243.B97497@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, csjp@FreeBSD.org Subject: Re: pseudo terminals in 7.0 - pts implementation X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2007 08:16:30 -0000 On Sun, 18 Nov 2007, Robert Watson wrote: > On Sun, 18 Nov 2007, Dan Epure wrote: > >> 7.0-BETA3 still has issues regarding the pts implementation . problems >> found: 1. - GNU screen: starting a screen, opening a few windows and >> quiting screen leaves the allocated pseudo terminal in use. 100 screen >> user, using each one opening 10 windows will deplete the default of 1000 >> pseudo terminals leaving the system unusable. 2. - 'ls /dev/ptmx' creates >> an additional entry in /dev/pty/. when the number of entries equals >> kern.pts.max the system became unusable. > > The first of these is likely a reference management bug of some sort -- I > find that if I close a pty in screen by exiting the shell, the pts device is > GC'd properly, but if I close it by killing the session with ctrl-k, then > the pts device is not properly GC'd and processes hung off it not properly > killed. I believe that closing the master device is not properly kicking > the slave device and causing its consumers to exit, hence the pts device not > being closd and released. Christian was taking a look at this a couple of > days ago, and I've CC'd him. > > The second problem is more tricky, and has to do with the cloning model. > Similar problems can exist with other variations on the ptmx implementation, > and I need to give some thought to how to address this. Dan, So, thinking a bit more about the second problem, I think it is inherrent to the way we've designed the /dev/ptmx cloning model, which is unfortunate. My current leaning is to disable the ptmx mechanism in 7.0 and put together a revised one for 7.1. The reason to do this is to avoid encoding the user<->kernel interface for allocating pty's via ptmx along the current lines, which we'd then need to continue supporting in future releases. I'm going to spend a bit of time over the next day or two looking at revising the interface to fix these problems. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Thu Nov 22 08:51:14 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7349116A419; Thu, 22 Nov 2007 08:51:14 +0000 (UTC) (envelope-from root@kash.tomsk.ru) Received: from mx.kash.tomsk.ru (ns2.kash.tomsk.ru [88.204.35.2]) by mx1.freebsd.org (Postfix) with ESMTP id AA97C13C469; Thu, 22 Nov 2007 08:51:13 +0000 (UTC) (envelope-from root@kash.tomsk.ru) Received: by mx.kash.tomsk.ru (Postfix, from userid 0) id 01B97DAE37; Thu, 22 Nov 2007 02:29:57 +0600 (NOVT) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mx.kash.tomsk.ru (Postfix) with ESMTP id 1AE2ADACCD for ; Thu, 22 Nov 2007 02:29:56 +0600 (NOVT) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id A911D184FD; Wed, 21 Nov 2007 20:29:24 +0000 (UTC) (envelope-from owner-freebsd-hackers@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 6F6D516A475; Wed, 21 Nov 2007 20:29:23 +0000 (UTC) (envelope-from owner-freebsd-hackers@freebsd.org) Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD1DE16A421; Wed, 21 Nov 2007 20:18:51 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id 316E913C455; Wed, 21 Nov 2007 20:18:50 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <474492B0.1010108@FreeBSD.org> Date: Wed, 21 Nov 2007 21:18:56 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Kris Kennaway References: <47137D36.1020305@chistydom.ru> <47149E6E.9000500@chistydom.ru> <4715035D.2090802@FreeBSD.org> <4715C297.1020905@chistydom.ru> <4715C5D7.7060806@FreeBSD.org> <471EE4D9.5080307@chistydom.ru> <4723BF87.20302@FreeBSD.org> <47344E47.9050908@chistydom.ru> <47349A17.3080806@FreeBSD.org> <47373B43.9060406@chistydom.ru> <4739557A.6090209@chistydom.ru> <4741EE9E.9050406@FreeBSD.org> In-Reply-To: <4741EE9E.9050406@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-hackers@freebsd.org Errors-To: owner-freebsd-hackers@freebsd.org X-DSPAM-Result: Innocent X-DSPAM-Processed: Thu Nov 22 02:29:57 2007 X-DSPAM-Confidence: 0.9990 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 47449545191321860720487 X-DSPAM-Factors: 27, >+Alexey, 0.00028, Alexey, 0.00043, Sender*owner+freebsd, 0.00053, Sender*freebsd, 0.00053, List-Post*freebsd, 0.00053, List-Post*, Alexey Popov , freebsd-stable@freebsd.org Subject: Re: amrd disk performance drop after running under high load X-BeenThere: freebsd-stable@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2007 08:51:14 -0000 Kris Kennaway wrote: > Alexey Popov wrote: >> Hi. >> >> Panagiotis Christias wrote: >>>>>>> In the "good" case you are getting a much higher interrupt rate but >>>>>>> with the data you provided I can't tell where from. You need to run >>>>>>> vmstat -i at regular intervals (e.g. every 10 seconds for a minute) >>>>>>> during the "good" and "bad" times, since it only provides counters >>>>>>> and an average rate over the uptime of the system. >>>>>> Now I'm running 10-process lighttpd and the problem became no so big. >>>>>> >>>>>> I collected interrupt stats and it shows no relation beetween >>>>>> ionterrupts and slowdowns. Here is it: >>>>>> http://83.167.98.162/gprof/intr-graph/ >>>>>> >>>>>> Also I have similiar statistics on mutex profiling and it shows >>>>>> there's no problem in mutexes. >>>>>> http://83.167.98.162/gprof/mtx-graph/mtxgifnew/ >>>>>> >>>>>> I have no idea what else to check. >>>>> I don't know what this graph is showing me :) When precisely is the >>>>> system behaving poorly? >>> what is your RAID controller configuration (read ahead/cache/write >>> policy)? I have seen weird/bogus numbers (~100% busy) reported by >>> systat -v when read ahead was enabled on LSI/amr controllers. >> >> >> ********************************************************************** >> Existing Logical Drive Information >> By LSI Logic Corp.,USA >> >> ********************************************************************** >> [Note: For SATA-2, 4 and 6 channel controllers, please specify >> Ch=0 Id=0..15 for specifying physical drive(Ch=channel, >> Id=Target)] >> >> >> Logical Drive : 0( Adapter: 0 ): Status: OPTIMAL >> --------------------------------------------------- >> SpanDepth :01 RaidLevel: 5 RdAhead : Adaptive Cache: >> DirectIo >> StripSz :064KB Stripes : 6 WrPolicy: WriteBack >> >> Logical Drive 0 : SpanLevel_0 Disks >> Chnl Target StartBlock Blocks Physical Target Status >> ---- ------ ---------- ------ ---------------------- >> 0 00 0x00000000 0x22ec0000 ONLINE >> 0 01 0x00000000 0x22ec0000 ONLINE >> 0 02 0x00000000 0x22ec0000 ONLINE >> 0 03 0x00000000 0x22ec0000 ONLINE >> 0 04 0x00000000 0x22ec0000 ONLINE >> 0 05 0x00000000 0x22ec0000 ONLINE >> >> I tried to run with disabled Read-ahead, but it didn't help. > > I just ran into this myself, and apparently it can be caused by "Patrol > Reads" where the adapter periodically scans the disks to look for media > errors. You can turn this off using -stopPR with the megarc port. > > Kris > Oops, -disPR is the correct command to disable, -stopPR just halts a PR event in progress. Kris _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Thu Nov 22 09:01:16 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19DAB16A46C; Thu, 22 Nov 2007 09:01:16 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id E3BBC13C45A; Thu, 22 Nov 2007 09:01:15 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 3EF7947370; Thu, 22 Nov 2007 03:56:37 -0500 (EST) Date: Thu, 22 Nov 2007 08:53:36 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Dan Epure In-Reply-To: <20071122065956.GH19354@iogyte.ro> Message-ID: <20071122085228.M60495@fledge.watson.org> References: <20071118012616.GF19354@iogyte.ro> <20071118144243.B97497@fledge.watson.org> <20071121215807.F60495@fledge.watson.org> <20071122065956.GH19354@iogyte.ro> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, csjp@FreeBSD.org, jhb@FreeBSD.org Subject: Re: pseudo terminals in 7.0 - pts implementation X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2007 09:01:16 -0000 On Thu, 22 Nov 2007, Dan Epure wrote: > Thank you for your answer. In this case the first problem (gnu screen) does > not deserve any attention because it is related to the ptmx clonig. My goal > is to find a way to increase the number os pseudo terminal. the traditional > 256 pty is not sufficient for my needs. Is there any way to do this on > freebsd other than using ptmx cloning ? John Baldwin has just merged support for up to 1024 ptys using the traditional pty driver, I believe, to HEAD, and plans (or perhaps has already) merged it to 7.0. I see no reason not to further merge it to 6.x. I've stuck him on the CC list also. Robert N M Watson Computer Laboratory University of Cambridge > > > On Wed, Nov 21, 2007 at 10:00:02PM +0000, Robert Watson wrote: >> >> On Sun, 18 Nov 2007, Robert Watson wrote: >> >>> On Sun, 18 Nov 2007, Dan Epure wrote: >>> >>>> 7.0-BETA3 still has issues regarding the pts implementation . problems >>>> found: 1. - GNU screen: starting a screen, opening a few windows and >>>> quiting screen leaves the allocated pseudo terminal in use. 100 screen >>>> user, using each one opening 10 windows will deplete the default of 1000 >>>> pseudo terminals leaving the system unusable. 2. - 'ls /dev/ptmx' creates >>>> an additional entry in /dev/pty/. when the number of entries equals >>>> kern.pts.max the system became unusable. >>> >>> The first of these is likely a reference management bug of some sort -- I >>> find that if I close a pty in screen by exiting the shell, the pts device >>> is GC'd properly, but if I close it by killing the session with ctrl-k, >>> then the pts device is not properly GC'd and processes hung off it not >>> properly killed. I believe that closing the master device is not properly >>> kicking the slave device and causing its consumers to exit, hence the pts >>> device not being closd and released. Christian was taking a look at this >>> a couple of days ago, and I've CC'd him. >>> >>> The second problem is more tricky, and has to do with the cloning model. >>> Similar problems can exist with other variations on the ptmx >>> implementation, and I need to give some thought to how to address this. >> >> Dan, >> >> So, thinking a bit more about the second problem, I think it is inherrent >> to the way we've designed the /dev/ptmx cloning model, which is >> unfortunate. My current leaning is to disable the ptmx mechanism in 7.0 >> and put together a revised one for 7.1. The reason to do this is to avoid >> encoding the user<->kernel interface for allocating pty's via ptmx along >> the current lines, which we'd then need to continue supporting in future >> releases. I'm going to spend a bit of time over the next day or two >> looking at revising the interface to fix these problems. >> >> Robert N M Watson >> Computer Laboratory >> University of Cambridge > From owner-freebsd-stable@FreeBSD.ORG Thu Nov 22 11:44:21 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BB8016A468; Thu, 22 Nov 2007 11:44:21 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from hermes.hw.ru (hermes.hw.ru [80.68.240.91]) by mx1.freebsd.org (Postfix) with ESMTP id 9AEFC13C4EC; Thu, 22 Nov 2007 11:44:20 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from [80.68.244.40] (account a_popov@rbc.ru [80.68.244.40] verified) by hermes.hw.ru (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 202153338; Thu, 22 Nov 2007 14:43:54 +0300 Message-ID: <47456B71.5040205@chistydom.ru> Date: Thu, 22 Nov 2007 14:43:45 +0300 From: Alexey Popov User-Agent: Thunderbird 2.0.0.6 (X11/20070924) MIME-Version: 1.0 To: Kris Kennaway References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> <4741A7DA.2050706@chistydom.ru> <4741DA15.9000308@FreeBSD.org> <47429DB8.7040504@chistydom.ru> <4742ADFE.40902@FreeBSD.org> <4742C46A.1060701@chistydom.ru> <47432F77.3030606@FreeBSD.org> <474339E9.4080301@FreeBSD.org> <4743629B.9090408@FreeBSD.org> In-Reply-To: <4743629B.9090408@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Attilio Rao , freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2007 11:44:21 -0000 Hi. Kris Kennaway wrote: >>> In the meantime there is unfortunately not a lot that can be done, >>> AFAICT. There is one hack that I will send you later but it is not >>> likely to help much. I will also think about how to track down the >>> cause of the contention further (the profiling trace only shows that >>> it comes mostly from vget/vput but doesn't show where these are >>> called from). >> >> Actually this patch might help. It doesn't replace lockmgr but it >> does fix a silly thundering herd behaviour. It probably needs some >> adjustment to get it to apply cleanly (it is about 7 months old), and >> I apparently stopped using it because I ran into deadlocks. It might >> be stable enough to at least see how much it helps. > Try this one instead, it applies to HEAD. You'll need to manually enter > the paths though because of how p4 mangles diffs. Finally I tried your patch and it seems to help a little. Now FreeBSD 7-STABLE ULE 8-core server without optimized PHP realpath_cache_size (producing 2000+ lstats per request) can handle up to ~24 rps as opposed to max. 17 rps without your patch. %sys never grows over %user with your patch. On the server with optimized realpath_cache_size there's no visible influence of your patch. However Linux is still 2 times faster for my workload and there should also be another ways for optimization. With best regards, Alexey Popov From owner-freebsd-stable@FreeBSD.ORG Thu Nov 22 12:16:16 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09AEF16A41B for ; Thu, 22 Nov 2007 12:16:16 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from outgoing01.lava.net (outgoing01.lava.net [64.65.64.68]) by mx1.freebsd.org (Postfix) with ESMTP id D367813C46A for ; Thu, 22 Nov 2007 12:16:15 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing01.lava.net (Postfix) with ESMTP id D9F3E8695 for ; Wed, 21 Nov 2007 14:15:21 -1000 (HST) Received: by malasada.lava.net (Postfix, from userid 102) id A914D153882; Wed, 21 Nov 2007 14:15:21 -1000 (HST) Date: Wed, 21 Nov 2007 14:15:21 -1000 From: Clifton Royston To: FreeBSD Stable List Message-ID: <20071122001521.GF17359@lava.net> Mail-Followup-To: FreeBSD Stable List References: <20071121171614.GA4191@lava.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071121171614.GA4191@lava.net> User-Agent: Mutt/1.4.2.2i Subject: Re: Debugging symbols for servers installed from CD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2007 12:16:16 -0000 On Wed, Nov 21, 2007 at 07:16:15AM -1000, Clifton Royston wrote: > All three SMP servers I recently installed with 6.2p8 from a custom > build CD rebooted within the space of 24 hours about a day ago. (One > of them is still not up; it sounds like it's requiring me to get to the > console to fix the root fs.) Unfortunately I'd forgotten to set dumpdev > in rc.conf on them, so I have nothing to analyze as yet. Arrgh. One of the servers just crashed again a couple hours ago, but instead of dumping to /dev/ad0s1b, as configured, it hung. So no core to look at. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From owner-freebsd-stable@FreeBSD.ORG Thu Nov 22 13:22:11 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BFFE16A419 for ; Thu, 22 Nov 2007 13:22:11 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.229]) by mx1.freebsd.org (Postfix) with ESMTP id 5240013C46B for ; Thu, 22 Nov 2007 13:22:11 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so2203435nzf for ; Thu, 22 Nov 2007 05:22:03 -0800 (PST) Received: by 10.142.242.8 with SMTP id p8mr2275111wfh.1195699882407; Wed, 21 Nov 2007 18:51:22 -0800 (PST) Received: by 10.143.15.5 with HTTP; Wed, 21 Nov 2007 18:51:22 -0800 (PST) Message-ID: <84dead720711211851n406c1c79mc5d56cb9a74cdd7@mail.gmail.com> Date: Thu, 22 Nov 2007 08:21:22 +0530 From: "Joseph Koshy" To: "Karl M. Joch" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4742CCAC.1060706@moneybookers.com> Cc: freebsd-stable@freebsd.org Subject: Re: Software for distribution of configuration files and changes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2007 13:22:11 -0000 > i have searched alot for a software to: > > - distribut configuration files from one master to different systems > - maintain configuration files on one machine for all systemes and then send > it out > - push the files, not download them like cvsup > - maintaining files for all systems and files only affecting one system > > any ideas and hints would be greatly appreziatet. You could take a look at ISCONF: http://trac.t7a.org/isconf/ http://www.infrastructures.org/bootstrap/isconf.shtml -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-stable@FreeBSD.ORG Thu Nov 22 14:24:17 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B8B816A473 for ; Thu, 22 Nov 2007 14:24:17 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id A069E13C455 for ; Thu, 22 Nov 2007 14:24:16 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IvCyB-0004ds-Ko for freebsd-stable@freebsd.org; Thu, 22 Nov 2007 14:23:55 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 Nov 2007 14:23:55 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 Nov 2007 14:23:55 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Thu, 22 Nov 2007 15:27:54 +0100 Lines: 38 Message-ID: References: <4741905E.8050300@chistydom.ru> <4742ADFE.40902@FreeBSD.org> <4742C46A.1060701@chistydom.ru> <47432F77.3030606@FreeBSD.org> <474339E9.4080301@FreeBSD.org> <4743629B.9090408@FreeBSD.org> <47440C10.5060608@FreeBSD.org> <47440E55.3060909@FreeBSD.org> <9bbcef730711210320s73c0625bh25ba2561b270f237@mail.gmail.com> <47448CC2.7030100@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.6 (X11/20070801) In-Reply-To: <47448CC2.7030100@FreeBSD.org> Sender: news Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2007 14:24:17 -0000 Kris Kennaway wrote: > Ivan Voras wrote: >> On 21/11/2007, Kris Kennaway wrote: >>> Ivan Voras wrote: >> >>>> Yes, but I had to verify it anyway :) >>> You haven't verified anything until you look at how much work the system >>> is doing, before and after. >> >> I have, and it's roughly the same (50 +/- 2 queries/s). >> >> (meaning that I'm not interested in exact statistics here, but in >> order-of-magnitude changes, which didn't happen). > > OK, let's take a step back here. Did you obtain the lock profiling > trace and verify that you're seeing the same problem as Alexey? Can I > see the trace? Here it is: http://ivoras.sharanet.org/stuff/lock_profile.txt This is without your patch. There's a lot of ZFS locks in there, but it seems lockmgr:ufs and lockmgr:zfs have the largest records: 299117621 1474776121 148663 1042821 1414 0 513 440 /usr/src/sys/kern/vfs_subr.c:2035 (lockmgr:ufs) 117958368 847566147 182093 2676 316728 68 948 374 /usr/src/sys/kern/vfs_vnops.c:515 (lockmgr:zfs) Which is surprising since all the working-set file systems are on ZFS, only the root and /tmp are on UFS. /tmp also holds sockets for the databases. Your reading of the lock profile will be appreciated. From owner-freebsd-stable@FreeBSD.ORG Thu Nov 22 14:38:32 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8018716A41A for ; Thu, 22 Nov 2007 14:38:32 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.191]) by mx1.freebsd.org (Postfix) with ESMTP id F342D13C45B for ; Thu, 22 Nov 2007 14:38:31 +0000 (UTC) (envelope-from grafan@gmail.com) Received: by mu-out-0910.google.com with SMTP id i10so3433278mue for ; Thu, 22 Nov 2007 06:38:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; bh=sLnpaAv23Mvun/RSnFeR0hdq7TXRMBVEP6TI8L5JvUI=; b=oX1QufAowWnFUiqFi8xbo4H69K5byudnKNGoc/+eu7GxkxS6LGmg1dSv9lxvlt58plj3iCuL3a7a/vRwjGgc9tujP9HhEwxtgEKI1zXV1Hp2TVNof2VNsZMt5FM3dbMnM54AdNuBlvgeR028QlC2kocZD3nheQ7r/uOQmti/Na4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=tXtBjji7kQ4I+QZxHtSnCkYJ60Kyey76ozsO8LNIso0XPADfUT93HV9zhtNFlpHWv4fsEgtdygCBre1CCC98jaI5YayVQ4wy7Mv+01BZAu1GU6sbMrepWavTZ7SdMuWt796FTKHle7NUlXw/cW33Xu9MZLFIX5dYDE16PppPVEA= Received: by 10.82.140.20 with SMTP id n20mr23493695bud.1195742310029; Thu, 22 Nov 2007 06:38:30 -0800 (PST) Received: by 10.82.115.11 with HTTP; Thu, 22 Nov 2007 06:38:29 -0800 (PST) Message-ID: <6eb82e0711220638l7c5fba64k23c730b2af9c6a79@mail.gmail.com> Date: Thu, 22 Nov 2007 22:38:29 +0800 From: "Rong-en Fan" To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-ports@freebsd.org Subject: if you see undefined symbol '__mb_sb_limit' on 6.x X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2007 14:38:32 -0000 The ctype fix for UTF-8 locale unfortunately introduced some new symbols to libc. Therefore, binaries built on system with that fix can not be used on older system. For that sake, the fix is back-out for 6-STABLE. If you see undefined symbols '__mb_sb_limit', please rebuild the affected binary. Everything will be fine then. Binaries built between 20071025 and 20071030 will be affected by this. Sorry for the inconvenience. Regards, Rong-En Fan From owner-freebsd-stable@FreeBSD.ORG Thu Nov 22 15:47:47 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EB4616A41A for ; Thu, 22 Nov 2007 15:47:47 +0000 (UTC) (envelope-from gepu@iogyte.ro) Received: from iogyte.ro (mail.iogyte.ro [62.231.111.163]) by mx1.freebsd.org (Postfix) with SMTP id 871A913C461 for ; Thu, 22 Nov 2007 15:47:44 +0000 (UTC) (envelope-from gepu@iogyte.ro) Received: (qmail 97342 invoked by uid 1001); 22 Nov 2007 15:47:41 -0000 Date: Thu, 22 Nov 2007 17:47:41 +0200 From: Dan Epure To: Robert Watson Message-ID: <20071122154741.GA73724@iogyte.ro> References: <20071118012616.GF19354@iogyte.ro> <20071118144243.B97497@fledge.watson.org> <20071121215807.F60495@fledge.watson.org> <20071122065956.GH19354@iogyte.ro> <20071122085228.M60495@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071122085228.M60495@fledge.watson.org> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, csjp@FreeBSD.org, jhb@FreeBSD.org Subject: Re: pseudo terminals in 7.0 - pts implementation X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dan Epure List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2007 15:47:47 -0000 Hi, For the moment this feature is only available in HEAD. I think the limit is "only" 512 master/slave pairs. Should be enough for this year. Is it going to be merged in 6.3 ? Thanks again. On Thu, Nov 22, 2007 at 08:53:36AM +0000, Robert Watson wrote: > > On Thu, 22 Nov 2007, Dan Epure wrote: > >> Thank you for your answer. In this case the first problem (gnu screen) >> does not deserve any attention because it is related to the ptmx clonig. >> My goal is to find a way to increase the number os pseudo terminal. the >> traditional 256 pty is not sufficient for my needs. Is there any way to do >> this on freebsd other than using ptmx cloning ? > > John Baldwin has just merged support for up to 1024 ptys using the > traditional pty driver, I believe, to HEAD, and plans (or perhaps has > already) merged it to 7.0. I see no reason not to further merge it to 6.x. > I've stuck him on the CC list also. > > Robert N M Watson > Computer Laboratory > University of Cambridge > >> >> >> On Wed, Nov 21, 2007 at 10:00:02PM +0000, Robert Watson wrote: >>> >>> On Sun, 18 Nov 2007, Robert Watson wrote: >>> >>>> On Sun, 18 Nov 2007, Dan Epure wrote: >>>> >>>>> 7.0-BETA3 still has issues regarding the pts implementation . problems >>>>> found: 1. - GNU screen: starting a screen, opening a few windows and >>>>> quiting screen leaves the allocated pseudo terminal in use. 100 screen >>>>> user, using each one opening 10 windows will deplete the default of >>>>> 1000 >>>>> pseudo terminals leaving the system unusable. 2. - 'ls /dev/ptmx' >>>>> creates >>>>> an additional entry in /dev/pty/. when the number of entries equals >>>>> kern.pts.max the system became unusable. >>>> >>>> The first of these is likely a reference management bug of some sort -- >>>> I >>>> find that if I close a pty in screen by exiting the shell, the pts >>>> device >>>> is GC'd properly, but if I close it by killing the session with ctrl-k, >>>> then the pts device is not properly GC'd and processes hung off it not >>>> properly killed. I believe that closing the master device is not >>>> properly >>>> kicking the slave device and causing its consumers to exit, hence the >>>> pts >>>> device not being closd and released. Christian was taking a look at >>>> this >>>> a couple of days ago, and I've CC'd him. >>>> >>>> The second problem is more tricky, and has to do with the cloning model. >>>> Similar problems can exist with other variations on the ptmx >>>> implementation, and I need to give some thought to how to address this. >>> >>> Dan, >>> >>> So, thinking a bit more about the second problem, I think it is inherrent >>> to the way we've designed the /dev/ptmx cloning model, which is >>> unfortunate. My current leaning is to disable the ptmx mechanism in 7.0 >>> and put together a revised one for 7.1. The reason to do this is to >>> avoid >>> encoding the user<->kernel interface for allocating pty's via ptmx along >>> the current lines, which we'd then need to continue supporting in future >>> releases. I'm going to spend a bit of time over the next day or two >>> looking at revising the interface to fix these problems. >>> >>> Robert N M Watson >>> Computer Laboratory >>> University of Cambridge >> > _______________________________________________ > 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-stable@FreeBSD.ORG Thu Nov 22 20:25:17 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF02A16A46C; Thu, 22 Nov 2007 20:25:17 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id B36A013C442; Thu, 22 Nov 2007 20:25:16 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <4745E5B3.6060200@FreeBSD.org> Date: Thu, 22 Nov 2007 21:25:23 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Alexey Popov References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> <4741A7DA.2050706@chistydom.ru> <4741DA15.9000308@FreeBSD.org> <47429DB8.7040504@chistydom.ru> <4742ADFE.40902@FreeBSD.org> <4742C46A.1060701@chistydom.ru> <47432F77.3030606@FreeBSD.org> <474339E9.4080301@FreeBSD.org> <4743629B.9090408@FreeBSD.org> <47456B71.5040205@chistydom.ru> In-Reply-To: <47456B71.5040205@chistydom.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Attilio Rao , freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2007 20:25:18 -0000 Alexey Popov wrote: > Hi. > > Kris Kennaway wrote: >>>> In the meantime there is unfortunately not a lot that can be done, >>>> AFAICT. There is one hack that I will send you later but it is not >>>> likely to help much. I will also think about how to track down the >>>> cause of the contention further (the profiling trace only shows that >>>> it comes mostly from vget/vput but doesn't show where these are >>>> called from). >>> >>> Actually this patch might help. It doesn't replace lockmgr but it >>> does fix a silly thundering herd behaviour. It probably needs some >>> adjustment to get it to apply cleanly (it is about 7 months old), and >>> I apparently stopped using it because I ran into deadlocks. It might >>> be stable enough to at least see how much it helps. >> Try this one instead, it applies to HEAD. You'll need to manually >> enter the paths though because of how p4 mangles diffs. > Finally I tried your patch and it seems to help a little. > > Now FreeBSD 7-STABLE ULE 8-core server without optimized PHP > realpath_cache_size (producing 2000+ lstats per request) can handle up > to ~24 rps as opposed to max. 17 rps without your patch. %sys never > grows over %user with your patch. On the server with optimized > realpath_cache_size there's no visible influence of your patch. You said "20" before for this configuration, so I'm a bit suspicious about how seriously to treat your measurements :) Anyway, please obtain another lock profiling trace using the same conditions as the previous one (same workload & duration, etc), so we can compare what changed. Kris From owner-freebsd-stable@FreeBSD.ORG Thu Nov 22 20:32:01 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CF0A16A46C for ; Thu, 22 Nov 2007 20:32:01 +0000 (UTC) (envelope-from allbery@ece.cmu.edu) Received: from bache.ece.cmu.edu (BACHE.ECE.CMU.EDU [128.2.129.23]) by mx1.freebsd.org (Postfix) with ESMTP id 2442713C461 for ; Thu, 22 Nov 2007 20:32:01 +0000 (UTC) (envelope-from allbery@ece.cmu.edu) Received: from [10.9.204.128] (dsl093-061-215.pit1.dsl.speakeasy.net [66.93.61.215]) by bache.ece.cmu.edu (Postfix) with ESMTP id 05FB2CB; Thu, 22 Nov 2007 15:09:17 -0500 (EST) In-Reply-To: <84dead720711211851n406c1c79mc5d56cb9a74cdd7@mail.gmail.com> References: <4742CCAC.1060706@moneybookers.com> <84dead720711211851n406c1c79mc5d56cb9a74cdd7@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7C45143B-D486-40F4-8A34-D901E2D53F13@ece.cmu.edu> Content-Transfer-Encoding: 7bit From: "Brandon S. Allbery KF8NH" Date: Thu, 22 Nov 2007 15:09:15 -0500 To: "Karl M. Joch" X-Mailer: Apple Mail (2.752.2) Cc: FreeBSD Stable Subject: Re: Software for distribution of configuration files and changes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2007 20:32:01 -0000 On Nov 21, 2007, at 21:51 , Joseph Koshy wrote: >> i have searched alot for a software to: >> >> - distribut configuration files from one master to different systems >> - maintain configuration files on one machine for all systemes and >> then send >> it out >> - push the files, not download them like cvsup >> - maintaining files for all systems and files only affecting one >> system >> >> any ideas and hints would be greatly appreziatet. > > You could take a look at ISCONF: > > http://trac.t7a.org/isconf/ > http://www.infrastructures.org/bootstrap/isconf.shtml isconf, cfengine, puppet, lcfg, bcfg2, radmind... http:// www.infrastructures.org is in general a good resource for such things. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From owner-freebsd-stable@FreeBSD.ORG Thu Nov 22 20:38:40 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CE1F16A418 for ; Thu, 22 Nov 2007 20:38:40 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 5173213C44B for ; Thu, 22 Nov 2007 20:38:40 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id C14076924; Fri, 23 Nov 2007 09:24:37 +1300 (NZDT) Date: Fri, 23 Nov 2007 09:24:37 +1300 From: Andrew Thompson To: Colin Percival Message-ID: <20071122202437.GA77577@heff.fud.org.nz> References: <1195488856.19739.42.camel@bauer.cse.buffalo.edu> <4741BB44.7010906@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4741BB44.7010906@freebsd.org> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current@freebsd.org, freebsd-stable Subject: Re: FreeBSD 7.0-BETA3 Available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2007 20:38:40 -0000 On Mon, Nov 19, 2007 at 08:35:16AM -0800, Colin Percival wrote: > Ken Smith wrote: > > The 7.0-BETA3 builds are now available. If you would like to download > > an ISO image to install from they are available here: > > > > ftp://ftp.freebsd.org/pub/FreeBSD/releases//ISO-IMAGES/7.0/ > > > > (adjust to be your architecture, e.g. amd64, i386, etc.). If you > > would like to use cvsup to update an older machine the release tag is > > still RELENG_7. > > Due to a communications mix-up, it isn't yet possible to upgrade to 7.0-BETA3 > using FreeBSD Update -- the bits are being assembled as I type this and binary > upgrading to 7.0-BETA3 should work by the end of the day. I thought i'd have a go at updating from 7.0-BETA2 to BETA3 but hit a snag, I am using ZFS on root which doesn't support file flags so it borked in install_unschg(), chflags noschg ${BASEDIR}/${F} || return 1 Is there any way to test the underlying filesystem supports flags first? cheers, Andrew From owner-freebsd-stable@FreeBSD.ORG Thu Nov 22 20:57:05 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E82516A421; Thu, 22 Nov 2007 20:57:05 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id 79EB913C442; Thu, 22 Nov 2007 20:57:04 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <4745ED27.6060401@FreeBSD.org> Date: Thu, 22 Nov 2007 21:57:11 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Ivan Voras References: <4741905E.8050300@chistydom.ru> <4742ADFE.40902@FreeBSD.org> <4742C46A.1060701@chistydom.ru> <47432F77.3030606@FreeBSD.org> <474339E9.4080301@FreeBSD.org> <4743629B.9090408@FreeBSD.org> <47440C10.5060608@FreeBSD.org> <47440E55.3060909@FreeBSD.org> <9bbcef730711210320s73c0625bh25ba2561b270f237@mail.gmail.com> <47448CC2.7030100@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2007 20:57:05 -0000 Ivan Voras wrote: > Kris Kennaway wrote: >> Ivan Voras wrote: >>> On 21/11/2007, Kris Kennaway wrote: >>>> Ivan Voras wrote: >>>>> Yes, but I had to verify it anyway :) >>>> You haven't verified anything until you look at how much work the system >>>> is doing, before and after. >>> I have, and it's roughly the same (50 +/- 2 queries/s). >>> >>> (meaning that I'm not interested in exact statistics here, but in >>> order-of-magnitude changes, which didn't happen). >> OK, let's take a step back here. Did you obtain the lock profiling >> trace and verify that you're seeing the same problem as Alexey? Can I >> see the trace? > > Here it is: > > http://ivoras.sharanet.org/stuff/lock_profile.txt > > This is without your patch. > > There's a lot of ZFS locks in there, but it seems lockmgr:ufs and > lockmgr:zfs have the largest records: > > 299117621 1474776121 148663 1042821 1414 0 513 > 440 /usr/src/sys/kern/vfs_subr.c:2035 (lockmgr:ufs) > > 117958368 847566147 182093 2676 316728 68 > 948 374 /usr/src/sys/kern/vfs_vnops.c:515 (lockmgr:zfs) > > Which is surprising since all the working-set file systems are on ZFS, > only the root and /tmp are on UFS. /tmp also holds sockets for the > databases. > > Your reading of the lock profile will be appreciated. OK, how about with? Kris From owner-freebsd-stable@FreeBSD.ORG Thu Nov 22 21:31:49 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6AB316A419 for ; Thu, 22 Nov 2007 21:31:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 930C513C45A for ; Thu, 22 Nov 2007 21:31:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IvJe3-000KUQ-3f; Thu, 22 Nov 2007 23:31:37 +0200 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id lAMLVUPq033039; Thu, 22 Nov 2007 23:31:30 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id lAMLVUKB033038; Thu, 22 Nov 2007 23:31:30 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 22 Nov 2007 23:31:30 +0200 From: Kostik Belousov To: Rong-en Fan Message-ID: <20071122213130.GU78396@deviant.kiev.zoral.com.ua> References: <6eb82e0711220638l7c5fba64k23c730b2af9c6a79@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xFAlB6MquX7/xpZD" Content-Disposition: inline In-Reply-To: <6eb82e0711220638l7c5fba64k23c730b2af9c6a79@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: 3140350ce96b4815fe22a3a842dc7b15 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1823 [Nov 22 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: freebsd-stable@freebsd.org, freebsd-ports@freebsd.org Subject: Re: if you see undefined symbol '__mb_sb_limit' on 6.x X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2007 21:31:49 -0000 --xFAlB6MquX7/xpZD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Nov 22, 2007 at 10:38:29PM +0800, Rong-en Fan wrote: > The ctype fix for UTF-8 locale unfortunately introduced some > new symbols to libc. Therefore, binaries built on system with > that fix can not be used on older system. For that sake, the > fix is back-out for 6-STABLE. If you see undefined symbols > '__mb_sb_limit', please rebuild the affected binary. Everything > will be fine then. Binaries built between 20071025 and 20071030 > will be affected by this. Can this symbol be actually leaved in the libc ? If not used by the ctype.h, it would provide binary compatibility with all RELENG_6 systems in existence, not only the ones before 20071025 ? --xFAlB6MquX7/xpZD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHRfUxC3+MBN1Mb4gRAkBxAJ9dxeEj0l4Y+r1FgxcicEwnSaMjlwCdGrLW R2tf54cFRId9Iez4+46BV1o= =YZqr -----END PGP SIGNATURE----- --xFAlB6MquX7/xpZD-- From owner-freebsd-stable@FreeBSD.ORG Thu Nov 22 21:42:23 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B943B16A468 for ; Thu, 22 Nov 2007 21:42:23 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.185]) by mx1.freebsd.org (Postfix) with ESMTP id ACA3E13C4CC for ; Thu, 22 Nov 2007 21:42:23 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so2519997rvb for ; Thu, 22 Nov 2007 13:42:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=THZQ/d5YG3dJD5k2RisaDhOdwUJj0/6gECy4fKucYmw=; b=IYirXR6F0olXQATQphy5fjcBxnoFQ4RODn1V9XOeLjEg5A6Mk/+f3lgsgZkcBYoKvrFm1PKdGonn3UzxmILqUfmqJRaV5QHWWB9WWZJIZDxtRQxiakZ1Ooe/Od0b3uvC+SeSsMMxRYwlb74vxi2XDntKw0N7LyXEjpfb6r3fI24= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=aFuEoPe3Bi6lt2xXHcfwg4mN4RSXb0kjcerbcgCuwVEiMQDwYzJtwcwxmE5t3M3xWoizO8rnq/0Sd7sKSH4mdqXiKl8AeXu+RVsCJgIq1IKo/yjaFeGJD6oDEFmv8RFBd4IgxDHErG3YO/kKgXLW1KbmH+XKCsovp9ySPbZvRGI= Received: by 10.140.251.1 with SMTP id y1mr4167988rvh.1195767743095; Thu, 22 Nov 2007 13:42:23 -0800 (PST) Received: by 10.141.211.5 with HTTP; Thu, 22 Nov 2007 13:42:23 -0800 (PST) Message-ID: <9bbcef730711221342y5223f0cfuca1826c8f203e9b8@mail.gmail.com> Date: Thu, 22 Nov 2007 22:42:23 +0100 From: "Ivan Voras" Sender: ivoras@gmail.com To: "Kris Kennaway" In-Reply-To: <4745ED27.6060401@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4741905E.8050300@chistydom.ru> <4743629B.9090408@FreeBSD.org> <47440C10.5060608@FreeBSD.org> <47440E55.3060909@FreeBSD.org> <9bbcef730711210320s73c0625bh25ba2561b270f237@mail.gmail.com> <47448CC2.7030100@FreeBSD.org> <4745ED27.6060401@FreeBSD.org> X-Google-Sender-Auth: b489d03a38377c51 Cc: freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2007 21:42:23 -0000 On 22/11/2007, Kris Kennaway wrote: > Ivan Voras wrote: > > Kris Kennaway wrote: > >> OK, let's take a step back here. Did you obtain the lock profiling > >> trace and verify that you're seeing the same problem as Alexey? Can I > >> see the trace? > > > > Here it is: > > > > http://ivoras.sharanet.org/stuff/lock_profile.txt > > > > This is without your patch. > > > > Your reading of the lock profile will be appreciated. > > OK, how about with? The machine is going into production and I can't do such interventions on it any more. Based on the lock trace, do you think It's the same problem as Alexeys? From owner-freebsd-stable@FreeBSD.ORG Thu Nov 22 21:51:16 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E24CD16A419; Thu, 22 Nov 2007 21:51:16 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id 5E5F813C44B; Thu, 22 Nov 2007 21:51:16 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <4745F9DB.7040701@FreeBSD.org> Date: Thu, 22 Nov 2007 22:51:23 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Ivan Voras References: <4741905E.8050300@chistydom.ru> <4743629B.9090408@FreeBSD.org> <47440C10.5060608@FreeBSD.org> <47440E55.3060909@FreeBSD.org> <9bbcef730711210320s73c0625bh25ba2561b270f237@mail.gmail.com> <47448CC2.7030100@FreeBSD.org> <4745ED27.6060401@FreeBSD.org> <9bbcef730711221342y5223f0cfuca1826c8f203e9b8@mail.gmail.com> In-Reply-To: <9bbcef730711221342y5223f0cfuca1826c8f203e9b8@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2007 21:51:17 -0000 Ivan Voras wrote: > On 22/11/2007, Kris Kennaway wrote: >> Ivan Voras wrote: >>> Kris Kennaway wrote: > >>>> OK, let's take a step back here. Did you obtain the lock profiling >>>> trace and verify that you're seeing the same problem as Alexey? Can I >>>> see the trace? >>> Here it is: >>> >>> http://ivoras.sharanet.org/stuff/lock_profile.txt >>> >>> This is without your patch. >>> > >>> Your reading of the lock profile will be appreciated. >> OK, how about with? > > The machine is going into production and I can't do such interventions > on it any more. Based on the lock trace, do you think It's the same > problem as Alexeys? It looks like lockmgr, and the patch should definitely have helped. Maybe you forgot to enable vfs.lookup_shared? Kris From owner-freebsd-stable@FreeBSD.ORG Thu Nov 22 22:20:51 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A14DB16A41B; Thu, 22 Nov 2007 22:20:51 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id 7004013C4CC; Thu, 22 Nov 2007 22:20:51 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 02ACFEB66D0; Fri, 23 Nov 2007 06:20:54 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id EtU8soZ+cmCT; Fri, 23 Nov 2007 06:20:49 +0800 (CST) Received: from LI-Xins-MacBook.local (c-67-161-39-180.hsd1.ca.comcast.net [67.161.39.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 442C8EB09C5; Fri, 23 Nov 2007 06:20:46 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=cOY2/YkZ/qXoWRF6ztUCICVYuIYrfFZxTqcLgQEyaFYoQm9vWF2FoH+heT7bebYMp 6rBfGBnM6W5e507GdPg4g== Message-ID: <474600B8.2060900@delphij.net> Date: Thu, 22 Nov 2007 14:20:40 -0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Dan Epure References: <20071118012616.GF19354@iogyte.ro> <20071118144243.B97497@fledge.watson.org> <20071121215807.F60495@fledge.watson.org> <20071122065956.GH19354@iogyte.ro> <20071122085228.M60495@fledge.watson.org> <20071122154741.GA73724@iogyte.ro> In-Reply-To: <20071122154741.GA73724@iogyte.ro> X-Enigmail-Version: 0.95.5 OpenPGP: url=http://www.delphij.net/delphij.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigA84B8B705235EFE4E8F87AC2" Cc: freebsd-stable@freebsd.org, freebsd-current@freebsd.org, Robert Watson , csjp@FreeBSD.org, jhb@FreeBSD.org Subject: Re: pseudo terminals in 7.0 - pts implementation X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2007 22:20:51 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA84B8B705235EFE4E8F87AC2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dan Epure wrote: > Hi, >=20 > For the moment this feature is only available in HEAD. I think the limi= t is "only" 512 master/slave pairs. > Should be enough for this year. Is it going to be merged in 6.3 ?=20 > Thanks again. I don't think so. Currently the FreeBSD pts implementation has some serious issues that must be resolved before we can "officially" expose it to users, and merging it to 6.3 does not seem to be reasonable at this moment. Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enigA84B8B705235EFE4E8F87AC2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHRgC4OfuToMruuMARCoRaAJ94wFmG1hrS4V9rSlvC1cbkcWCAngCfYivG x52yWzf98722PDKzBufhBnE= =OxQH -----END PGP SIGNATURE----- --------------enigA84B8B705235EFE4E8F87AC2-- From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 01:21:29 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FFC316A418 for ; Fri, 23 Nov 2007 01:21:29 +0000 (UTC) (envelope-from jackqq@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.230]) by mx1.freebsd.org (Postfix) with ESMTP id BCB5113C442 for ; Fri, 23 Nov 2007 01:21:28 +0000 (UTC) (envelope-from jackqq@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so2336080nzf for ; Thu, 22 Nov 2007 17:21:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=xbN1bmtaApWKPs4/Um/DCG+iXaxB6m/P9SVtw+9kBlc=; b=YHnHv8/lmYY2v+8sD8Mco7siFaUuib2p0TkdpOPGJnXKIuvFd47f9J/wAsaKevzgC1j4GQan/pojR3zDfa2Bb+m1AYHmB0nGMzm3yQ1Q69ZrBjwSNVEkr7WUCjCbaBgJvl5KNP7WfxbbL+VwGfzPACM44do09wmYYW7BQosnT9U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=H4yGF6JhVA33oG/2aN8eLeqyTD5su2osNJas5gqePuGusnycTVRP03ZEsEblPZv1X2eBqpfCit4NmETzVpYFutvMXci5eQMC210NsV0Gd5sp8Bzn8Eg0zI1Vvj+0B3npXe2XP2BKu378PgF8c7Q8Pr40TZeOv+J8VNp2elHRQP0= Received: by 10.142.242.8 with SMTP id p8mr2506159wfh.1195780884191; Thu, 22 Nov 2007 17:21:24 -0800 (PST) Received: by 10.142.109.20 with HTTP; Thu, 22 Nov 2007 17:21:24 -0800 (PST) Message-ID: <53a565700711221721v1eb695bcy507780fc3fc30eaa@mail.gmail.com> Date: Fri, 23 Nov 2007 09:21:24 +0800 From: "Quan Qiu" To: freebsd-stable@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <474325A0.7060802@gmail.com> <200711202315.lAKNFa4R012904@fire.js.berklix.net> <20071121002043.GA98340@eos.sc1.parodius.com> <53a565700711202145q3c1a8db5k8c0d41d7ad890405@mail.gmail.com> Subject: Re: Software for distribution of configuration files and changes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 01:21:29 -0000 T24gTm92IDIyLCAyMDA3IDE6MDEgQU0sIFZpdmVrIEtoZXJhIDx2aXZla0BraGVyYS5vcmc+IHdy b3RlOgo+Cj4gT24gTm92IDIxLCAyMDA3LCBhdCAxMjo0NSBBTSwgUXVhbiBRaXUgd3JvdGU6Cj4K PiA+Cj4gPiAiQ2hhbGxlbmdlUmVzcG9uc2VBdXRoZW50aWNhdGlvbiBubyIgaXMgYWxzbyByZXF1 aXJlZCB0byBhdm9pZCBzc2hkCj4gPiBhY2NlcHRpbmcga2V5Ym9hcmQtaW50ZXJhY3RpdmUvcGFt Lgo+ID4KPiA+Cj4KPiBJIGRvbid0IHRoaW5rIHRoaXMgc2V0dGluZyBtYXR0ZXJzIGZvciBQZXJt aXRSb290TG9naW4gd2l0aG91dC0KPiBwYXNzd29yZC4gIEF0IGxlYXN0IHRoZSBkZWZhdWx0IG9u IEZyZWVCU0QgNiB3b3JrcyBhcyBleHBlY3RlZCB3aGVuCj4gc2V0dGluZyB0aGUgcm9vdCBsb2dp biBsaW1pdC4KPgoKClNvcnJ5IGZvciBub3QgbWVudGlvbmluZyBJJ20gb24gNS41LVNUQUJMRS4K ClVzaW5nIHRoZSBmb2xsb3dpbmcgc2V0dGluZ3MgaW4gc3NoZF9jb25maWc6CgpQZXJtaXRSb290 TG9naW4gd2l0aG91dC1wYXNzd29yZApQYXNzd29yZEF1dGhlbnRpY2F0aW9uIG5vClVzZUROUyBu bwpTdWJzeXN0ZW0gICAgICAgc2Z0cCAgICAvdXNyL2xpYmV4ZWMvc2Z0cC1zZXJ2ZXIKCgpQdVRU WSdpbmcgdG8gdGhlIGJveCBwcm9kdWNlczoKClVzaW5nIHVzZXJuYW1lICJyb290Ii4KVXNpbmcg a2V5Ym9hcmQtaW50ZXJhY3RpdmUgYXV0aGVudGljYXRpb24uClBhc3N3b3JkOgoKCi0tIAr0w4Hn IChRSVUgUXVhbikgPGphY2txcUBnbWFpbC5jb20+Cg== From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 01:29:58 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8554816A417 for ; Fri, 23 Nov 2007 01:29:58 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.185]) by mx1.freebsd.org (Postfix) with ESMTP id 66A4013C442 for ; Fri, 23 Nov 2007 01:29:58 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so2559320rvb for ; Thu, 22 Nov 2007 17:29:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=/074cIeMB+SEgzsWzRbRYi/yAXqlIeehKizABCjrh8E=; b=eZIQcdh4Q97CbNP8cinXVF2vv/JZ/SAi78mVwvoAsRpUQ7gV40RvcbDNOzIV4M5sAk/+fPTkvtDAUT3pyHJTAYX7pTN6NSmOCiG6eKx0Ombnxkp1ko9i0CI/IkcLoYlkDCCYBHJfpKtaJ//tdwyYhCLWPD8bKOAVucs2WSTPRVw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=qPkCZXSe/Jq64baM1YSdwO69UyzUvv9+x9xCrz3FiVwkK0HX8mF5wn90Z0NWnPNQCpIKruK0GQmfHdoPK+G77YI7WbxeM+dR3AAgWFuKcl71pJWeeGsyJLyP7zvK5aaCFyQ4n/eJEng91fINBDayE4jy4wz4+HHENHNfrosxuhY= Received: by 10.141.19.16 with SMTP id w16mr1309045rvi.1195781397982; Thu, 22 Nov 2007 17:29:57 -0800 (PST) Received: by 10.141.211.5 with HTTP; Thu, 22 Nov 2007 17:29:57 -0800 (PST) Message-ID: <9bbcef730711221729h4c76c183s155186129e2ff0e1@mail.gmail.com> Date: Fri, 23 Nov 2007 02:29:57 +0100 From: "Ivan Voras" Sender: ivoras@gmail.com To: "Kris Kennaway" In-Reply-To: <4745F9DB.7040701@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4741905E.8050300@chistydom.ru> <47440C10.5060608@FreeBSD.org> <47440E55.3060909@FreeBSD.org> <9bbcef730711210320s73c0625bh25ba2561b270f237@mail.gmail.com> <47448CC2.7030100@FreeBSD.org> <4745ED27.6060401@FreeBSD.org> <9bbcef730711221342y5223f0cfuca1826c8f203e9b8@mail.gmail.com> <4745F9DB.7040701@FreeBSD.org> X-Google-Sender-Auth: d4a5c7b57c4e1910 Cc: freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 01:29:58 -0000 On 22/11/2007, Kris Kennaway wrote: > It looks like lockmgr, and the patch should definitely have helped. > Maybe you forgot to enable vfs.lookup_shared? No, I haven't. But the machine I tested it on is only 4-core; maybe it would help on 8-core machines. From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 05:21:55 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A63F516A41A for ; Fri, 23 Nov 2007 05:21:55 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id ACF9A13C459 for ; Fri, 23 Nov 2007 05:21:55 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 69C601CC079; Thu, 22 Nov 2007 21:21:55 -0800 (PST) Date: Thu, 22 Nov 2007 21:21:55 -0800 From: Jeremy Chadwick To: Quan Qiu Message-ID: <20071123052155.GA721@eos.sc1.parodius.com> References: <474325A0.7060802@gmail.com> <200711202315.lAKNFa4R012904@fire.js.berklix.net> <20071121002043.GA98340@eos.sc1.parodius.com> <53a565700711202145q3c1a8db5k8c0d41d7ad890405@mail.gmail.com> <53a565700711221721v1eb695bcy507780fc3fc30eaa@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53a565700711221721v1eb695bcy507780fc3fc30eaa@mail.gmail.com> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-stable@freebsd.org Subject: Re: Software for distribution of configuration files and changes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 05:21:55 -0000 On Fri, Nov 23, 2007 at 09:21:24AM +0800, Quan Qiu wrote: > On Nov 22, 2007 1:01 AM, Vivek Khera wrote: > > > > On Nov 21, 2007, at 12:45 AM, Quan Qiu wrote: > > > > > > > > "ChallengeResponseAuthentication no" is also required to avoid sshd > > > accepting keyboard-interactive/pam. This affects all users, and not just root. This is probably not what you want. > Using the following settings in sshd_config: > > PermitRootLogin without-password > PasswordAuthentication no > UseDNS no > Subsystem sftp /usr/libexec/sftp-server > > PuTTY'ing to the box produces: > > Using username "root". > Using keyboard-interactive authentication. > Password: And have you tried actually attempting to log in with root's password that way? I'm betting it doesn't work. Here's proof from our RELENG_6 box, where I'm attempting to log in as root on it: eos$ whoami jdc eos$ ssh root@anubis.sc1.private.lan The authenticity of host 'anubis.sc1.private.lan (10.72.0.125)' can't be established. DSA key fingerprint is ... Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'anubis.sc1.private.lan' (DSA) to the list of known hosts. Password: Password: Password: And the sshd_config from anubis is all defaults values, except for "PermitRootLogin without-password". -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 06:14:16 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE49B16A46E for ; Fri, 23 Nov 2007 06:14:16 +0000 (UTC) (envelope-from jackqq@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.189]) by mx1.freebsd.org (Postfix) with ESMTP id C892913C478 for ; Fri, 23 Nov 2007 06:14:16 +0000 (UTC) (envelope-from jackqq@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so2608836rvb for ; Thu, 22 Nov 2007 22:14:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=wg1nUYVJwqf9tlKlqDrKK1hDunaVDbJ8LlNOhneRvUw=; b=ZTckw/g8Gw1TodGGEM8arGZ6FJ35B7UL0grxX9wQVfHTkvnTjZVOm1FzWCXuqsi39kWlyaPeuih2QpUmUwafgBqRGRwZWnrO+9TYQB+tQ32fbQfg1JWGLWEV2dYLTRQfNHNug/hCSEpMt+8/3HrZSaFR3zC67lzJyics4uF7ntc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=C3dY1IV1Nf+lzkaHQQgaupHrnx2EWjA14rrbL/yQOlDBc5MNRtowO5h4UqKrU+0iqKDrzyaTJdHBfBOC3YxBO/I1l+DrVkODnGfQsz1XneFjrwRPfEnw2CZAEpr5PqwzLSwU5pTquCi8iRnJIg5mZYiHXGIiCzcOG88tDEwV7II= Received: by 10.142.241.10 with SMTP id o10mr2530918wfh.1195798454191; Thu, 22 Nov 2007 22:14:14 -0800 (PST) Received: by 10.142.109.20 with HTTP; Thu, 22 Nov 2007 22:14:14 -0800 (PST) Message-ID: <53a565700711222214t7cc160bcq25769f9393d75081@mail.gmail.com> Date: Fri, 23 Nov 2007 14:14:14 +0800 From: "Quan Qiu" To: freebsd-stable@freebsd.org In-Reply-To: <20071123052155.GA721@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <474325A0.7060802@gmail.com> <200711202315.lAKNFa4R012904@fire.js.berklix.net> <20071121002043.GA98340@eos.sc1.parodius.com> <53a565700711202145q3c1a8db5k8c0d41d7ad890405@mail.gmail.com> <53a565700711221721v1eb695bcy507780fc3fc30eaa@mail.gmail.com> <20071123052155.GA721@eos.sc1.parodius.com> Subject: Re: Software for distribution of configuration files and changes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 06:14:17 -0000 T24gTm92IDIzLCAyMDA3IDE6MjEgUE0sIEplcmVteSBDaGFkd2ljayA8a29pdHN1QGZyZWVic2Qu b3JnPiB3cm90ZToKPiA+ID4gPiAiQ2hhbGxlbmdlUmVzcG9uc2VBdXRoZW50aWNhdGlvbiBubyIg aXMgYWxzbyByZXF1aXJlZCB0byBhdm9pZCBzc2hkCj4gPiA+ID4gYWNjZXB0aW5nIGtleWJvYXJk LWludGVyYWN0aXZlL3BhbS4KPgo+IFRoaXMgYWZmZWN0cyBhbGwgdXNlcnMsIGFuZCBub3QganVz dCByb290LiAgVGhpcyBpcyBwcm9iYWJseSBub3QKPiB3aGF0IHlvdSB3YW50LgoKWWVzLiBCdXQg d2l0aG91dCBQQU0sIHNzaGQganVzdCBwcm9tcHRzIGZvciBwYXNzd29yZCBpbiBhIGxpdHRsZSBk aWZmZXJlbnQgd2F5LgpQdVRUWSBvdXRwdXQ6CgpQQU06CgpVc2luZyB1c2VybmFtZSAicm9vdCIu ClVzaW5nIGtleWJvYXJkLWludGVyYWN0aXZlIGF1dGhlbnRpY2F0aW9uLgpQYXNzd29yZDoKCgpz c2hkOgoKVXNpbmcgdXNlcm5hbWUgInJvb3QiLgpyb290QGJsYWhibGFoLmJsYWgncyBwYXNzd29y ZDoKCgpBbmQsIHdoYXQncyB3b3JzZSwgaWYgdGhlIHN5c3RlbSBpcyBnb2luZyBkb3duIChpbiA1 IG1pbnV0ZXMpLAogIHBhbV9ub2xvZ2luLnNvIGluIC9ldGMvcGFtLmQvc3NoZAp3aWxsIGtpY2sg eW91IChub24tcm9vdCkgb3V0IGV2ZW4gaWYgeW91IGhhdmUKICBpZ25vcmVub2xvZ2luCmluIHlv dXIgbG9naW4gY2xhc3MuIFdoaWxlIHJlbW92aW5nIHRoYXQgbGluZSBpbiBQQU0gd2lsbApyZW5k ZXIgdGhlIG5vbG9naW4gZmVhdHVyZSB1c2VsZXNzIGZvciBhbGwgdXNlcnMuCgpJbiBvdGhlciB3 b3JkcywgaWYgYSBzeXN0ZW0gdXNlcyBQQU0gYW5kIGZvcmJpZHMgcm9vdCBsb2dpbgp1c2luZyBw YXNzd29yZCwgYWRtaW5pc3RyYXRvcnMgKHN0YWZmIG9yIHdoZWVsKSBoYXZlIG5vIHdheQp0byBs b2dpbiBhZ2FpbiB0byBzdG9wIHRoZSBwZW5kaW5nIHNodXRkb3duIGlmIHRoZXkgZG9uJ3QgaGF2 ZQp0aGUgcm9vdCBrZXkgYXQgaGFuZCBpbiBhIHRpbWVseSBtYW5uZXIuCgoKCj4gQW5kIGhhdmUg eW91IHRyaWVkIGFjdHVhbGx5IGF0dGVtcHRpbmcgdG8gbG9nIGluIHdpdGggcm9vdCdzIHBhc3N3 b3JkCj4gdGhhdCB3YXk/ICBJJ20gYmV0dGluZyBpdCBkb2Vzbid0IHdvcmsuCgpUaGF0IHJlYWxs eSB3b3JrZWQgZm9yIG1lLiBJJ20gcnVubmluZyBSRUxFTkdfNS4gVGhlIGN2c2lkIGZvcgovZXRj L3BhbS5kL3NzaGQgaXMKIyAkRnJlZUJTRDogc3JjL2V0Yy9wYW0uZC9zc2hkLHYgMS4xNSAyMDAz LzA0LzMwIDIxOjU3OjU0IG1hcmttIEV4cCAkCnNzaGQgdmVyc2lvbjoKT3BlblNTSF8zLjguMXAx IEZyZWVCU0QtMjAwNjA5MzAsIE9wZW5TU0wgMC45LjdlLXAxIDI1IE9jdCAyMDA0CgoKTXkgcHJv b2Y6CgpVc2luZyB1c2VybmFtZSAicm9vdCIuClVzaW5nIGtleWJvYXJkLWludGVyYWN0aXZlIGF1 dGhlbnRpY2F0aW9uLgpQYXNzd29yZDoKTGFzdCBsb2dpbjogRnJpIE5vdiAyMyAwOToxNDoyNyAy MDA3IGZyb20gNjEuMTM2LjE5LjIzNgpDb3B5cmlnaHQgKGMpIDE5ODAsIDE5ODMsIDE5ODYsIDE5 ODgsIDE5OTAsIDE5OTEsIDE5OTMsIDE5OTQKICAgICAgICBUaGUgUmVnZW50cyBvZiB0aGUgVW5p dmVyc2l0eSBvZiBDYWxpZm9ybmlhLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KCkZyZWVCU0QgNS41 LVNUQUJMRSAoSkFDS1FRTkFUKSAjNjogTW9uIE5vdiAxOSAyMTozMzozMCBDU1QgMjAwNwoKcm9v dEBzZXJ2aWNlcyBbfl0gMTM6NTEgRnJpIE5vdiAyMwojY2F0IC9ldGMvcGFtLmQvc3NoZAojCiMg JEZyZWVCU0Q6IHNyYy9ldGMvcGFtLmQvc3NoZCx2IDEuMTUgMjAwMy8wNC8zMCAyMTo1Nzo1NCBt YXJrbSBFeHAgJAouLi4KCgpXaXRob3V0IFBBTToKClVzaW5nIHVzZXJuYW1lICJyb290Ii4Kcm9v dEBibGFoYmxhaC5ibGFoJ3MgcGFzc3dvcmQ6CkFjY2VzcyBkZW5pZWQKcm9vdEBibGFoYmxhaC5i bGFoJ3MgcGFzc3dvcmQ6CgoKLS0gCvTDgecgKFFJVSBRdWFuKSA8amFja3FxQGdtYWlsLmNvbT4K From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 07:12:33 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC33C16A418; Fri, 23 Nov 2007 07:12:33 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from hermes.hw.ru (hermes.hw.ru [80.68.240.91]) by mx1.freebsd.org (Postfix) with ESMTP id EBD5A13C44B; Fri, 23 Nov 2007 07:12:32 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from [80.68.244.40] (account a_popov@rbc.ru [80.68.244.40] verified) by hermes.hw.ru (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 202397293; Fri, 23 Nov 2007 10:12:10 +0300 Message-ID: <47467D3F.7020002@chistydom.ru> Date: Fri, 23 Nov 2007 10:11:59 +0300 From: Alexey Popov User-Agent: Thunderbird 2.0.0.6 (X11/20070924) MIME-Version: 1.0 To: Kris Kennaway References: <47137D36.1020305@chistydom.ru> <47149E6E.9000500@chistydom.ru> <4715035D.2090802@FreeBSD.org> <4715C297.1020905@chistydom.ru> <4715C5D7.7060806@FreeBSD.org> <471EE4D9.5080307@chistydom.ru> <4723BF87.20302@FreeBSD.org> <47344E47.9050908@chistydom.ru> <47349A17.3080806@FreeBSD.org> <47373B43.9060406@chistydom.ru> <4739557A.6090209@chistydom.ru> <4741EE9E.9050406@FreeBSD.org> <474492B0.1010108@FreeBSD.org> In-Reply-To: <474492B0.1010108@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Panagiotis Christias , freebsd-stable@freebsd.org Subject: Re: amrd disk performance drop after running under high load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 07:12:34 -0000 Kris Kennaway wrote: >>>> what is your RAID controller configuration (read ahead/cache/write >>>> policy)? I have seen weird/bogus numbers (~100% busy) reported by >>>> systat -v when read ahead was enabled on LSI/amr controllers. >>> I tried to run with disabled Read-ahead, but it didn't help. >> I just ran into this myself, and apparently it can be caused by >> "Patrol Reads" where the adapter periodically scans the disks to look >> for media errors. You can turn this off using -stopPR with the megarc gg >> port. > Oops, -disPR is the correct command to disable, -stopPR just halts a PR > event in progress. Wow! Really disabling Patrol Reads solves the problem. Thank you! I have many amrd's and all of them appear to have Patrol Reads enabled by default. But the problem happenes only on three of them. Is this a hardware problem? With best regards, Alexey Popov From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 07:35:36 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8C9A16A421; Fri, 23 Nov 2007 07:35:36 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from hermes.hw.ru (hermes.hw.ru [80.68.240.91]) by mx1.freebsd.org (Postfix) with ESMTP id DF9F813C465; Fri, 23 Nov 2007 07:35:35 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from [80.68.244.40] (account a_popov@rbc.ru [80.68.244.40] verified) by hermes.hw.ru (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 202400514; Fri, 23 Nov 2007 10:29:52 +0300 Message-ID: <47468165.5010906@chistydom.ru> Date: Fri, 23 Nov 2007 10:29:41 +0300 From: Alexey Popov User-Agent: Thunderbird 2.0.0.6 (X11/20070924) MIME-Version: 1.0 To: Kris Kennaway References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> <4741A7DA.2050706@chistydom.ru> <4741DA15.9000308@FreeBSD.org> <47429DB8.7040504@chistydom.ru> <4742ADFE.40902@FreeBSD.org> <4742C46A.1060701@chistydom.ru> <47432F77.3030606@FreeBSD.org> <474339E9.4080301@FreeBSD.org> <4743629B.9090408@FreeBSD.org> <47456B71.5040205@chistydom.ru> <4745E5B3.6060200@FreeBSD.org> In-Reply-To: <4745E5B3.6060200@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Attilio Rao , freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 07:35:37 -0000 Hi. Kris Kennaway wrote: >> Now FreeBSD 7-STABLE ULE 8-core server without optimized PHP >> realpath_cache_size (producing 2000+ lstats per request) can handle up >> to ~24 rps as opposed to max. 17 rps without your patch. %sys never >> grows over %user with your patch. On the server with optimized >> realpath_cache_size there's no visible influence of your patch. > > You said "20" before for this configuration, so I'm a bit suspicious > about how seriously to treat your measurements :) Sorry, my mistake. s/ULE/4BSD. > Anyway, please obtain another lock profiling trace using the same > conditions as the previous one (same workload & duration, etc), so we > can compare what changed. OK, I'll make it a little bit later. Also I tried to find what else is slow in FreeBSD, I tried hwpmc as module and in kernel, but it fails with error: pmc: Unknown Intel CPU. module_register_init: MOD_LOAD (hwpmc, 0xffffffff804833e0, 0xffffffff809338a0) error 78 This is related to http://www.freebsd.org/cgi/query-pr.cgi?pr=amd64%2F111994&cat= and it is impossible to use hwpmc with modern CPUs. Is kgmon profiling usable on FreeBSD 7? With best regards, Alexey Popov From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 07:51:06 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32D9316A496 for ; Fri, 23 Nov 2007 07:51:06 +0000 (UTC) (envelope-from pmurray@nevada.net.nz) Received: from bellagio.open2view.net (bellagio.open2view.net [210.48.79.75]) by mx1.freebsd.org (Postfix) with ESMTP id E6E5313C45D for ; Fri, 23 Nov 2007 07:51:05 +0000 (UTC) (envelope-from pmurray@nevada.net.nz) Received: from mandalay.lan (125-239-150-247.jetstream.xtra.co.nz [125.239.150.247]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bellagio.open2view.net (Postfix) with ESMTP id 7CAD26A3EDC for ; Fri, 23 Nov 2007 20:24:25 +1300 (NZDT) Message-Id: From: Philip Murray To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v912) Date: Fri, 23 Nov 2007 20:24:21 +1300 X-Mailer: Apple Mail (2.912) Subject: Critical section expansion X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 07:51:06 -0000 Hi, I've been running this (http://lists.freebsd.org/pipermail/cvs-src/2007-November/084049.html ) change on RELENG_7 in production since it was committed and it's fixed a whole host of problems (NIC timeouts, TCP sessions dying under heavy disk load etc.) for me. So far it hasn't created any new ones... Just wondering if it's going to get MFC'd before the 7.0 release? Cheers Phil From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 09:15:02 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A07716A46C for ; Fri, 23 Nov 2007 09:15:02 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 039AD13C4CC for ; Fri, 23 Nov 2007 09:15:01 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 33E3D1CC079; Fri, 23 Nov 2007 01:14:56 -0800 (PST) Date: Fri, 23 Nov 2007 01:14:56 -0800 From: Jeremy Chadwick To: Quan Qiu Message-ID: <20071123091456.GA9582@eos.sc1.parodius.com> References: <474325A0.7060802@gmail.com> <200711202315.lAKNFa4R012904@fire.js.berklix.net> <20071121002043.GA98340@eos.sc1.parodius.com> <53a565700711202145q3c1a8db5k8c0d41d7ad890405@mail.gmail.com> <53a565700711221721v1eb695bcy507780fc3fc30eaa@mail.gmail.com> <20071123052155.GA721@eos.sc1.parodius.com> <53a565700711222214t7cc160bcq25769f9393d75081@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53a565700711222214t7cc160bcq25769f9393d75081@mail.gmail.com> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-stable@freebsd.org Subject: Re: Software for distribution of configuration files and changes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 09:15:02 -0000 On Fri, Nov 23, 2007 at 02:14:14PM +0800, Quan Qiu wrote: > > And have you tried actually attempting to log in with root's password > > that way? I'm betting it doesn't work. > > That really worked for me. I'm running RELENG_5. The cvsid for > /etc/pam.d/sshd is > # $FreeBSD: src/etc/pam.d/sshd,v 1.15 2003/04/30 21:57:54 markm Exp $ > sshd version: > OpenSSH_3.8.1p1 FreeBSD-20060930, OpenSSL 0.9.7e-p1 25 Oct 2004 > > My proof: > > Using username "root". > Using keyboard-interactive authentication. > Password: > Last login: Fri Nov 23 09:14:27 2007 from 61.136.19.236 > Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 > The Regents of the University of California. All rights reserved. > > FreeBSD 5.5-STABLE (JACKQQNAT) #6: Mon Nov 19 21:33:30 CST 2007 > > root@services [~] 13:51 Fri Nov 23 > #cat /etc/pam.d/sshd > # > # $FreeBSD: src/etc/pam.d/sshd,v 1.15 2003/04/30 21:57:54 markm Exp $ > ... > > > Without PAM: > > Using username "root". > root@blahblah.blah's password: > Access denied > root@blahblah.blah's password: Okay, so then the difference between what you're seeing and what I'm seeing is likely attributed to either OpenSSH changes (less likely) or PAM configuration changes between RELENG_5 and RELENG_6 (more likely). http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/pam.d/sshd -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 09:36:09 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B91A816A419 for ; Fri, 23 Nov 2007 09:36:09 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id 27E5B13C469 for ; Fri, 23 Nov 2007 09:36:09 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id C217262635; Fri, 23 Nov 2007 11:35:55 +0200 (EET) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44014-02; Fri, 23 Nov 2007 11:35:54 +0200 (EET) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id 9486862636; Fri, 23 Nov 2007 11:35:54 +0200 (EET) Message-ID: <47469EF9.70409@bulinfo.net> Date: Fri, 23 Nov 2007 11:35:53 +0200 From: Krassimir Slavchev User-Agent: Thunderbird 2.0.0.9 (X11/20071122) MIME-Version: 1.0 To: Ivan Voras References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> <4741B3DE.2000009@chistydom.ru> <47430AE8.7050408@chistydom.ru> <9bbcef730711200915n12e37efcs67cf260641b9baab@mail.gmail.com> In-Reply-To: <9bbcef730711200915n12e37efcs67cf260641b9baab@mail.gmail.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net Cc: freebsd-stable@freebsd.org, Alexey Popov Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 09:36:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ivan Voras wrote: > On 20/11/2007, Alexey Popov wrote: > >> CPU states: 5.9% user, 0.0% nice, 81.3% system, 0.0% interrupt, 12.8% idle >> CPU states: 82.2% user, 0.0% nice, 13.8% system, 0.0% interrupt, 4.0% idle > > Interesting coincidence: 1 CPU generates almost 8x less "sys time" then 8 CPUs. > > But it seems that you have found something real. Inspired by your > problem I've done a simple measurement ("ab") on a 4-CPU (2x2 core > Opterons 2216 HE, PAE) machine I maintain, under these circumstances: Would someone define what exact tests to be performed. Ok, using "ab" is fine but with what parameters it is used and against what, script or static html? It will be good to have written some perl, php ... scripts or C programs which simulates some kind of 'real world' work. There are lot of people who thinking 'it is good for me' (including me) but what can be done with such hardware? Best Regards > > - a "heavy" PHP application > - FastCGI > - in this case, load of 4 clients > - on 6-STABLE > > and I'm reporting similar findings: > > last pid: 2254; load averages: 1.43, 0.92, 0.69 up 71+08:23:06 18:00:31 > 153 processes: 8 running, 144 sleeping, 1 zombie > CPU states: 38.8% user, 0.0% nice, 48.4% system, 3.2% interrupt, 9.6% idle > Mem: 2321M Active, 1135M Inact, 313M Wired, 139M Cache, 112M Buf, 93M Free > Swap: 4500M Total, 336K Used, 4500M Free > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 2208 www 1 99 0 115M 19808K RUN 1 0:06 36.83% php-cgi > 2207 www 1 100 0 114M 19348K RUN 3 0:05 32.66% php-cgi > 1715 www 1 99 0 115M 23672K CPU0 0 0:24 27.83% php-cgi > 1710 www 1 101 0 114M 23460K RUN 1 0:31 22.17% php-cgi > 1882 www 1 99 0 115M 23392K CPU2 3 0:18 21.34% php-cgi > 1718 www 1 4 0 114M 22556K sbwait 0 0:21 19.14% php-cgi > 2677 pgsql 1 4 0 977M 55768K sbwait 0 0:00 28.00% postgres > > We are not so performance bound as you so I didn't do measurements > earlier. I cannot "play" with settings on this machine as it is in > production, but ~~50% sys time (the measurement changes around 45% +/- > 10%) seems too much. > > On another 4-CPU machine (2x2 Xeons 5110, AMD64) with the same > application and benchmark setup, but RELENG_7, which is not yet in > production, the results are slightly different: > > last pid: 66564; load averages: 1.87, 0.48, 0.18 up 15+05:27:03 17:09:09 > 113 processes: 9 running, 104 sleeping > CPU states: 49.0% user, 0.0% nice, 28.8% system, 0.0% interrupt, 22.1% idle > Mem: 555M Active, 295M Inact, 884M Wired, 98M Cache, 213M Buf, 135M Free > Swap: 2047M Total, 2047M Free > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 66557 www 1 109 0 105M 25340K RUN 3 0:14 64.99% php-cgi > 66559 www 1 109 0 105M 25308K RUN 2 0:14 62.99% php-cgi > 66561 www 1 98 0 105M 22196K RUN 0 0:01 12.99% php-cgi > 66562 www 1 98 0 105M 22196K RUN 1 0:01 11.96% php-cgi > 59043 nobody 1 47 0 7012K 3744K select 2 0:27 5.96% sqlcached > 774 pgsql 1 44 0 437M 112M select 2 3:55 0.00% postgres > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHRp75xJBWvpalMpkRAhbVAKClBhCif9G/bYPq6hHaNxAyT9NuLwCfb8+a Aqmf9RT+LBNYqKOE6crBs9g= =LL1v -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 10:16:46 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5657E16A417 for ; Fri, 23 Nov 2007 10:16:46 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.186]) by mx1.freebsd.org (Postfix) with ESMTP id C6F1E13C4CE for ; Fri, 23 Nov 2007 10:16:45 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so2653633rvb for ; Fri, 23 Nov 2007 02:16:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=elG5ix0J43kK4WmkobCW5acFRZdguztniXyrbPjgjcE=; b=GSPIhhXiO5ezXlcUVgk8doVuYJu+E/6rdNg3mpS+CGHCZO92U2Yo4bcnMGXnPTF486OeoDqPQYBVTZjzHsQ6riDKmGttNA8TPW0bBkHBFc+YFoDtPhs44H7QKlwSOJyXJvcV7zzmt3wP6MY/NoMw1YiBXHnwTslatSc4ZYlJrnI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ry7bxbwvfOc72vnSOxYtkXjA5QTlQLWkLPuEFpJEvgTl7p/qC6zIjye+DIV/F8MbrAUEJu+jb55uauZF85xGUMKzZORm8J+bFIPXi2rYl7CEydmwiAwTaJJTa/d4XC2nqjirzxu+fqktjrpVenhT7jViNV/dyUAFPnhTp+rh1Oc= Received: by 10.141.153.16 with SMTP id f16mr4385583rvo.1195812999336; Fri, 23 Nov 2007 02:16:39 -0800 (PST) Received: by 10.141.63.14 with HTTP; Fri, 23 Nov 2007 02:16:39 -0800 (PST) Message-ID: <9bbcef730711230216l74c30a08ja04a558742789b17@mail.gmail.com> Date: Fri, 23 Nov 2007 11:16:39 +0100 From: "Ivan Voras" Sender: ivoras@gmail.com To: "Krassimir Slavchev" In-Reply-To: <47469EF9.70409@bulinfo.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> <4741B3DE.2000009@chistydom.ru> <47430AE8.7050408@chistydom.ru> <9bbcef730711200915n12e37efcs67cf260641b9baab@mail.gmail.com> <47469EF9.70409@bulinfo.net> X-Google-Sender-Auth: 43004d686d60b561 Cc: freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 10:16:46 -0000 On 23/11/2007, Krassimir Slavchev wrote: > Would someone define what exact tests to be performed. > Ok, using "ab" is fine but with what parameters it is used and against > what, script or static html? It will be good to have written some perl, In this thread, it's always PHP code, with database backends. > php ... scripts or C programs which simulates some kind of 'real world' > work. The problem is that a realistic applications does a lot of things that are not easily simulated: - usually has a lot of code, lots of include files, libraries, etc. (so it stresses file systems, as was shown with fstat() in the thread - the code is most likely checking for changes in PHP libraries) - uses a database, which is populated with real-world data (so it has a lot of IPC of very varied sizes) - uses some kind of caching, both of compiled PHP code (eAccelerator, pecl-APC) and of data (eAccelerator, memcached) (which uses SysV SHM and IPC). Reducing all that to a C file that does all of it is very nontrivial. For "classic" setups with mod_php, it's not uncommon that httpd processes grow to 100 MB or more each, with all the heavy stuff brought in. From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 10:53:55 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71C3F16A418; Fri, 23 Nov 2007 10:53:55 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id A2A6513C468; Fri, 23 Nov 2007 10:53:53 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <4746B148.6000209@FreeBSD.org> Date: Fri, 23 Nov 2007 11:54:00 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Alexey Popov References: <47137D36.1020305@chistydom.ru> <47149E6E.9000500@chistydom.ru> <4715035D.2090802@FreeBSD.org> <4715C297.1020905@chistydom.ru> <4715C5D7.7060806@FreeBSD.org> <471EE4D9.5080307@chistydom.ru> <4723BF87.20302@FreeBSD.org> <47344E47.9050908@chistydom.ru> <47349A17.3080806@FreeBSD.org> <47373B43.9060406@chistydom.ru> <4739557A.6090209@chistydom.ru> <4741EE9E.9050406@FreeBSD.org> <474492B0.1010108@FreeBSD.org> <47467D3F.7020002@chistydom.ru> In-Reply-To: <47467D3F.7020002@chistydom.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Panagiotis Christias , freebsd-stable@freebsd.org Subject: Re: amrd disk performance drop after running under high load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 10:53:55 -0000 Alexey Popov wrote: > Kris Kennaway wrote: > >>>>> what is your RAID controller configuration (read ahead/cache/write >>>>> policy)? I have seen weird/bogus numbers (~100% busy) reported by >>>>> systat -v when read ahead was enabled on LSI/amr controllers. >>>> I tried to run with disabled Read-ahead, but it didn't help. >>> I just ran into this myself, and apparently it can be caused by >>> "Patrol Reads" where the adapter periodically scans the disks to look >>> for media errors. You can turn this off using -stopPR with the >>> megarc gg port. >> Oops, -disPR is the correct command to disable, -stopPR just halts a >> PR event in progress. > Wow! Really disabling Patrol Reads solves the problem. Thank you! > > I have many amrd's and all of them appear to have Patrol Reads enabled > by default. But the problem happenes only on three of them. Is this a > hardware problem? I am not sure, maybe for some reason the patrol reads are not interfering with other disk I/O so much (e.g. the hardware prioritises them differently or something). Anyway, glad to hear it was resolved. Kris From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 10:55:57 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0181B16A421; Fri, 23 Nov 2007 10:55:57 +0000 (UTC) (envelope-from root@kash.tomsk.ru) Received: from mx.kash.tomsk.ru (ns2.kash.tomsk.ru [88.204.35.2]) by mx1.freebsd.org (Postfix) with ESMTP id 1F75613C467; Fri, 23 Nov 2007 10:55:56 +0000 (UTC) (envelope-from root@kash.tomsk.ru) Received: by mx.kash.tomsk.ru (Postfix, from userid 0) id A93E1DAE72; Fri, 23 Nov 2007 16:55:38 +0600 (NOVT) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mx.kash.tomsk.ru (Postfix) with ESMTP id 4C99DDAE68 for ; Fri, 23 Nov 2007 16:55:37 +0600 (NOVT) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 32AF3B9A09; Fri, 23 Nov 2007 10:54:08 +0000 (UTC) (envelope-from owner-freebsd-hackers@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 80F4716A49C; Fri, 23 Nov 2007 10:54:07 +0000 (UTC) (envelope-from owner-freebsd-hackers@freebsd.org) Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71C3F16A418; Fri, 23 Nov 2007 10:53:55 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id A2A6513C468; Fri, 23 Nov 2007 10:53:53 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <4746B148.6000209@FreeBSD.org> Date: Fri, 23 Nov 2007 11:54:00 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Alexey Popov References: <47137D36.1020305@chistydom.ru> <47149E6E.9000500@chistydom.ru> <4715035D.2090802@FreeBSD.org> <4715C297.1020905@chistydom.ru> <4715C5D7.7060806@FreeBSD.org> <471EE4D9.5080307@chistydom.ru> <4723BF87.20302@FreeBSD.org> <47344E47.9050908@chistydom.ru> <47349A17.3080806@FreeBSD.org> <47373B43.9060406@chistydom.ru> <4739557A.6090209@chistydom.ru> <4741EE9E.9050406@FreeBSD.org> <474492B0.1010108@FreeBSD.org> <47467D3F.7020002@chistydom.ru> In-Reply-To: <47467D3F.7020002@chistydom.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-hackers@freebsd.org Errors-To: owner-freebsd-hackers@freebsd.org X-DSPAM-Result: Innocent X-DSPAM-Processed: Fri Nov 23 16:55:38 2007 X-DSPAM-Confidence: 0.9991 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4746b1aa191321013621364 X-DSPAM-Factors: 27, Alexey, 0.00041, List-Post*, freebsd-stable@freebsd.org Subject: Re: amrd disk performance drop after running under high load X-BeenThere: freebsd-stable@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 10:55:57 -0000 Alexey Popov wrote: > Kris Kennaway wrote: > >>>>> what is your RAID controller configuration (read ahead/cache/write >>>>> policy)? I have seen weird/bogus numbers (~100% busy) reported by >>>>> systat -v when read ahead was enabled on LSI/amr controllers. >>>> I tried to run with disabled Read-ahead, but it didn't help. >>> I just ran into this myself, and apparently it can be caused by >>> "Patrol Reads" where the adapter periodically scans the disks to look >>> for media errors. You can turn this off using -stopPR with the >>> megarc gg port. >> Oops, -disPR is the correct command to disable, -stopPR just halts a >> PR event in progress. > Wow! Really disabling Patrol Reads solves the problem. Thank you! > > I have many amrd's and all of them appear to have Patrol Reads enabled > by default. But the problem happenes only on three of them. Is this a > hardware problem? I am not sure, maybe for some reason the patrol reads are not interfering with other disk I/O so much (e.g. the hardware prioritises them differently or something). Anyway, glad to hear it was resolved. Kris _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 10:57:30 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AF4416A468; Fri, 23 Nov 2007 10:57:30 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id 5E16613C457; Fri, 23 Nov 2007 10:57:28 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <4746B21F.7050906@FreeBSD.org> Date: Fri, 23 Nov 2007 11:57:35 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Alexey Popov References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> <4741A7DA.2050706@chistydom.ru> <4741DA15.9000308@FreeBSD.org> <47429DB8.7040504@chistydom.ru> <4742ADFE.40902@FreeBSD.org> <4742C46A.1060701@chistydom.ru> <47432F77.3030606@FreeBSD.org> <474339E9.4080301@FreeBSD.org> <4743629B.9090408@FreeBSD.org> <47456B71.5040205@chistydom.ru> <4745E5B3.6060200@FreeBSD.org> <47468165.5010906@chistydom.ru> In-Reply-To: <47468165.5010906@chistydom.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Attilio Rao , freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 10:57:30 -0000 Alexey Popov wrote: > Hi. > > Kris Kennaway wrote: > >>> Now FreeBSD 7-STABLE ULE 8-core server without optimized PHP >>> realpath_cache_size (producing 2000+ lstats per request) can handle >>> up to ~24 rps as opposed to max. 17 rps without your patch. %sys >>> never grows over %user with your patch. On the server with optimized >>> realpath_cache_size there's no visible influence of your patch. >> >> You said "20" before for this configuration, so I'm a bit suspicious >> about how seriously to treat your measurements :) > Sorry, my mistake. s/ULE/4BSD. OK, please compare ULE to ULE with and without my patch (and remembering to enable the sysctl), and obtain lock profiling traces in both cases under identical workloads & durations. That is what I need to proceed with this issue. >> Anyway, please obtain another lock profiling trace using the same >> conditions as the previous one (same workload & duration, etc), so we >> can compare what changed. > OK, I'll make it a little bit later. > > Also I tried to find what else is slow in FreeBSD, I tried hwpmc as > module and in kernel, but it fails with error: > pmc: Unknown Intel CPU. > module_register_init: MOD_LOAD (hwpmc, 0xffffffff804833e0, > 0xffffffff809338a0) error 78 There are patches you need to enable it on woodcrest. They are in my p4 branch (kris-contention) but I don't have time right now to extract them. > This is related to > http://www.freebsd.org/cgi/query-pr.cgi?pr=amd64%2F111994&cat= > and it is impossible to use hwpmc with modern CPUs. Sounds like it. > Is kgmon profiling usable on FreeBSD 7? I've never bothered, it is likely to be quite slow, so it can totally change the workload you are trying to profile. Kris From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 10:58:50 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64B5716A41B for ; Fri, 23 Nov 2007 10:58:50 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id AC95C13C459; Fri, 23 Nov 2007 10:58:49 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <4746B270.3070902@FreeBSD.org> Date: Fri, 23 Nov 2007 11:58:56 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Philip Murray References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Critical section expansion X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 10:58:50 -0000 Philip Murray wrote: > Hi, > > I've been running this > (http://lists.freebsd.org/pipermail/cvs-src/2007-November/084049.html) > change on RELENG_7 in production since it was committed and it's fixed a > whole host of problems (NIC timeouts, TCP sessions dying under heavy > disk load etc.) for me. So far it hasn't created any new ones... > > Just wondering if it's going to get MFC'd before the 7.0 release? Absolutely. Kris From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 11:06:47 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0477516A418; Fri, 23 Nov 2007 11:06:47 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id 9DAA913C45D; Fri, 23 Nov 2007 11:06:46 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id 1F98265FF6; Fri, 23 Nov 2007 13:06:26 +0200 (EET) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53150-05; Fri, 23 Nov 2007 13:06:24 +0200 (EET) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id 027B465FF4; Fri, 23 Nov 2007 13:06:23 +0200 (EET) Message-ID: <4746B42E.4040709@bulinfo.net> Date: Fri, 23 Nov 2007 13:06:22 +0200 From: Krassimir Slavchev User-Agent: Thunderbird 2.0.0.9 (X11/20071122) MIME-Version: 1.0 To: Ivan Voras References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> <4741B3DE.2000009@chistydom.ru> <47430AE8.7050408@chistydom.ru> <9bbcef730711200915n12e37efcs67cf260641b9baab@mail.gmail.com> <47469EF9.70409@bulinfo.net> <9bbcef730711230216l74c30a08ja04a558742789b17@mail.gmail.com> In-Reply-To: <9bbcef730711230216l74c30a08ja04a558742789b17@mail.gmail.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net Cc: freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 11:06:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ivan Voras wrote: > On 23/11/2007, Krassimir Slavchev wrote: > >> Would someone define what exact tests to be performed. >> Ok, using "ab" is fine but with what parameters it is used and against >> what, script or static html? It will be good to have written some perl, > > In this thread, it's always PHP code, with database backends. > >> php ... scripts or C programs which simulates some kind of 'real world' >> work. > > The problem is that a realistic applications does a lot of things that > are not easily simulated: That's true but if the tests are same then they can be compared. > > - usually has a lot of code, lots of include files, libraries, etc. > (so it stresses file systems, as was shown with fstat() in the thread > - the code is most likely checking for changes in PHP libraries) This is not recommended for production systems. > - uses a database, which is populated with real-world data (so it has > a lot of IPC of very varied sizes) > - uses some kind of caching, both of compiled PHP code (eAccelerator, > pecl-APC) and of data (eAccelerator, memcached) (which uses SysV SHM > and IPC). > > Reducing all that to a C file that does all of it is very nontrivial. Yes, may be it is easier to write perl/php scripts. > For "classic" setups with mod_php, it's not uncommon that httpd > processes grow to 100 MB or more each, with all the heavy stuff > brought in. > Yes, that is true for mod_perl too. However, it is hard to simulate real workload. I will have 2 2xQuad Core(X5450) with 8G RAM systems (DL380G5) soon and will have about a month to play with them before put in production. If someone wish I can run specific test on them. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHRrQuxJBWvpalMpkRAvL9AJ9tBgeZPxg6zYWqJUgVimIJgaxl1ACeK2kS POeyNbZBGuiQB0OKHIEtoSk= =pjb2 -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 11:47:12 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 093E916A41B; Fri, 23 Nov 2007 11:47:12 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from hermes.hw.ru (hermes.hw.ru [80.68.240.91]) by mx1.freebsd.org (Postfix) with ESMTP id BC9D513C467; Fri, 23 Nov 2007 11:47:10 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from [80.68.244.40] (account a_popov@rbc.ru [80.68.244.40] verified) by hermes.hw.ru (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 202480478; Fri, 23 Nov 2007 14:46:36 +0300 Message-ID: <4746BD92.6000204@chistydom.ru> Date: Fri, 23 Nov 2007 14:46:26 +0300 From: Alexey Popov User-Agent: Thunderbird 2.0.0.6 (X11/20070924) MIME-Version: 1.0 To: Kris Kennaway References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> <4741A7DA.2050706@chistydom.ru> <4741DA15.9000308@FreeBSD.org> <47429DB8.7040504@chistydom.ru> <4742ADFE.40902@FreeBSD.org> <4742C46A.1060701@chistydom.ru> <47432F77.3030606@FreeBSD.org> <474339E9.4080301@FreeBSD.org> <4743629B.9090408@FreeBSD.org> <47456B71.5040205@chistydom.ru> <4745E5B3.6060200@FreeBSD.org> <47468165.5010906@chistydom.ru> <4746B21F.7050906@FreeBSD.org> In-Reply-To: <4746B21F.7050906@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Attilio Rao , freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 11:47:12 -0000 Hi Kris Kennaway wrote: >>>> Now FreeBSD 7-STABLE ULE 8-core server without optimized PHP >>>> realpath_cache_size (producing 2000+ lstats per request) can handle >>>> up to ~24 rps as opposed to max. 17 rps without your patch. %sys >>>> never grows over %user with your patch. On the server with optimized >>>> realpath_cache_size there's no visible influence of your patch. >>> You said "20" before for this configuration, so I'm a bit suspicious >>> about how seriously to treat your measurements :) >> Sorry, my mistake. s/ULE/4BSD. > OK, please compare ULE to ULE with and without my patch (and remembering > to enable the sysctl), and obtain lock profiling traces in both cases > under identical workloads & durations. That is what I need to proceed > with this issue. I didn't measured the exact values of requests per second on ULE with patch and without patch, but at first glance the benefits of the patch are similiar to 4BSD. If you need this values, I'll obtain them. Here you can find lock profiling results for 7-BETA3 GENERIC kernel with SCHED_ULE running optimized PHP and unoptimized, with your patch and without it: http://83.167.98.162/gprof/lockmgr/ This data was collected by th following script: (sysctl debug.lock.prof.reset=1 sysctl debug.lock.prof.enable=1 sleep 60 sysctl debug.lock.prof.enable=0 sysctl debug.lock.prof.stats top -d 2 -b | tail -25) AFAIU there's still high contention on "lockbuilder mtxpool" with patch applied. But hopefully "lockmgr:ufs" contention which i believe produced 80%sysCPU load is gone with your patch. >> Also I tried to find what else is slow in FreeBSD, I tried hwpmc as >> module and in kernel, but it fails with error: >> pmc: Unknown Intel CPU. > There are patches you need to enable it on woodcrest. They are in my p4 > branch (kris-contention) but I don't have time right now to extract them. I think it would be very useful because I can't see any other ways to profile FreeBSD on the modern many-cores machines. With best regards, Alexey Popov From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 12:09:47 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA33316A46E for ; Fri, 23 Nov 2007 12:09:47 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.184]) by mx1.freebsd.org (Postfix) with ESMTP id A585713C448 for ; Fri, 23 Nov 2007 12:09:47 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so2674888rvb for ; Fri, 23 Nov 2007 04:09:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=ni2rDDZPO8jjpfr3T4jGOTbYq/m+8Us21u6ER+23vkI=; b=V/NJxxGSK703b4WkiMOoEwNo0k+1xurKoTjv7LhryWy171lWgVlSlqGjAiJc25qwqYHIs8XsZ+UKSQ+ng5+NTXoeXOjal32eUR3XqIg8rgcI6WP3ZCXDNW6moCKnazSyT7x6njYK7Uj+IEsoI+z54s7A90owBk/Aeh3m2C5UmcM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RoY+CDawN4MBcHHlZy00NyunjCocNCs7uLtN/oJlAq27S6eFlkJxDf37R7N4In1Cd+6RUp8nDZ0+eLyicksLp3afWz+DzVjy/lF9A3QKPvPFtQ9TsMFC34lnwJa9Kdl9xIkx15kFduXqn7AgJXJFaY5RRC4+4Xqs+Y6vHL8/sWg= Received: by 10.141.164.10 with SMTP id r10mr3907907rvo.1195819784672; Fri, 23 Nov 2007 04:09:44 -0800 (PST) Received: by 10.141.206.11 with HTTP; Fri, 23 Nov 2007 04:09:44 -0800 (PST) Message-ID: <84dead720711230409u112b0a01k97e58d0ff0c61f8b@mail.gmail.com> Date: Fri, 23 Nov 2007 12:09:44 +0000 From: "Joseph Koshy" To: "Kris Kennaway" In-Reply-To: <4746B21F.7050906@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4741905E.8050300@chistydom.ru> <4742ADFE.40902@FreeBSD.org> <4742C46A.1060701@chistydom.ru> <47432F77.3030606@FreeBSD.org> <474339E9.4080301@FreeBSD.org> <4743629B.9090408@FreeBSD.org> <47456B71.5040205@chistydom.ru> <4745E5B3.6060200@FreeBSD.org> <47468165.5010906@chistydom.ru> <4746B21F.7050906@FreeBSD.org> Cc: Attilio Rao , freebsd-stable@freebsd.org, Alexey Popov Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 12:09:48 -0000 > > Also I tried to find what else is slow in FreeBSD, I tried hwpmc as > > module and in kernel, but it fails with error: > > pmc: Unknown Intel CPU. > > module_register_init: MOD_LOAD (hwpmc, 0xffffffff804833e0, > > 0xffffffff809338a0) error 78 > There are patches you need to enable it on woodcrest. They are in my p4 > branch (kris-contention) but I don't have time right now to extract them. These patches make hwpmc treat these CPUs are possessing Pentium-Pro class PMCs. Unfortunately, this is easy to do, but incorrect: - There are differences in the legal bit values that may be loaded into PMC registers for many hardware events. - hwpmc needs to be taught to support measurements on CPUs with multiple cores per package. And then there is additional work to support these CPUS at the same level as the current set: - The hardware events supported are named differently; documentation, libpmc's event selector parsing code need to be changed to suit. - The hardware supports a new class of "fixed function" PMCs that hwpmc needs to support. -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 12:33:51 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E08416A417 for ; Fri, 23 Nov 2007 12:33:51 +0000 (UTC) (envelope-from toomas.aas@raad.tartu.ee) Received: from kuller.raad.tartu.ee (kuller.raad.tartu.ee [194.126.106.100]) by mx1.freebsd.org (Postfix) with ESMTP id D079113C46B for ; Fri, 23 Nov 2007 12:33:50 +0000 (UTC) (envelope-from toomas.aas@raad.tartu.ee) Received: from localhost (localhost [127.0.0.1]) by kuller.raad.tartu.ee (Postfix) with ESMTP id 1F042BAF7 for ; Fri, 23 Nov 2007 14:33:33 +0200 (EET) X-Virus-Scanned: amavisd-new at post.raad.tartu.ee Received: from kuller.raad.tartu.ee ([127.0.0.1]) by localhost (kuller.raad.tartu.ee [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEdMTLGHb7mP for ; Fri, 23 Nov 2007 14:33:31 +0200 (EET) Received: from raad.tartu.ee (lv.raad.tartu.ee [194.126.106.110]) by kuller.raad.tartu.ee (Postfix) with ESMTP id EB6ACB819 for ; Fri, 23 Nov 2007 14:33:30 +0200 (EET) Received: from INFO/SpoolDir by raad.tartu.ee (Mercury 1.48); 23 Nov 07 14:33:30 +0200 Received: from SpoolDir by INFO (Mercury 1.48); 23 Nov 07 14:33:26 +0200 Received: from [172.26.1.6] (172.26.1.6) by raad.tartu.ee (Mercury 1.48) with ESMTP; 23 Nov 07 14:33:24 +0200 Message-ID: <4746C893.1090305@raad.tartu.ee> Date: Fri, 23 Nov 2007 14:33:23 +0200 From: Toomas Aas User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: "conatainer" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 12:33:51 -0000 With RELENG_7 source cvsupped 3 days ago, I noticed several occurrences of word "conatainer" in sys/dev/aac/aac_debug.c case AifJobCtrZero: /* Container clear operation */ device_printf(sc->aac_dev, "(ConatainerZero) container %d\n", aif->data.PR[0].jd.client.container.src); break; case AifJobCtrCopy: /* Container copy operation */ device_printf(sc->aac_dev, "(ConatainerCopy) container %d to %d\n", aif->data.PR[0].jd.client.container.src, aif->data.PR[0].jd.client.container.dst); ...and so on. A lot of aac debug messages talk about "Conatainer" something or other. Shouldn't it be "Container"? English is not my native language, so I didn't want to file a PR in case there actually is a word "conatainer" in English language. -- Toomas Aas From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 12:50:07 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7622716A420; Fri, 23 Nov 2007 12:50:07 +0000 (UTC) (envelope-from root@kash.tomsk.ru) Received: from mx.kash.tomsk.ru (ns2.kash.tomsk.ru [88.204.35.2]) by mx1.freebsd.org (Postfix) with ESMTP id 671A013C4D3; Fri, 23 Nov 2007 12:50:06 +0000 (UTC) (envelope-from root@kash.tomsk.ru) Received: by mx.kash.tomsk.ru (Postfix, from userid 0) id CC563DAE85; Fri, 23 Nov 2007 18:49:59 +0600 (NOVT) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mx.kash.tomsk.ru (Postfix) with ESMTP id 61365DAE81 for ; Fri, 23 Nov 2007 18:49:55 +0600 (NOVT) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id C35715D6B7; Fri, 23 Nov 2007 12:49:17 +0000 (UTC) (envelope-from owner-freebsd-hackers@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id D555316A4A9; Fri, 23 Nov 2007 12:49:13 +0000 (UTC) (envelope-from owner-freebsd-hackers@freebsd.org) Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC33C16A418; Fri, 23 Nov 2007 07:12:33 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from hermes.hw.ru (hermes.hw.ru [80.68.240.91]) by mx1.freebsd.org (Postfix) with ESMTP id EBD5A13C44B; Fri, 23 Nov 2007 07:12:32 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from [80.68.244.40] (account a_popov@rbc.ru [80.68.244.40] verified) by hermes.hw.ru (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 202397293; Fri, 23 Nov 2007 10:12:10 +0300 Message-ID: <47467D3F.7020002@chistydom.ru> Date: Fri, 23 Nov 2007 10:11:59 +0300 From: Alexey Popov User-Agent: Thunderbird 2.0.0.6 (X11/20070924) MIME-Version: 1.0 To: Kris Kennaway References: <47137D36.1020305@chistydom.ru> <47149E6E.9000500@chistydom.ru> <4715035D.2090802@FreeBSD.org> <4715C297.1020905@chistydom.ru> <4715C5D7.7060806@FreeBSD.org> <471EE4D9.5080307@chistydom.ru> <4723BF87.20302@FreeBSD.org> <47344E47.9050908@chistydom.ru> <47349A17.3080806@FreeBSD.org> <47373B43.9060406@chistydom.ru> <4739557A.6090209@chistydom.ru> <4741EE9E.9050406@FreeBSD.org> <474492B0.1010108@FreeBSD.org> In-Reply-To: <474492B0.1010108@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 23 Nov 2007 12:49:09 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-hackers@freebsd.org Errors-To: owner-freebsd-hackers@freebsd.org X-DSPAM-Result: Innocent X-DSPAM-Processed: Fri Nov 23 18:49:59 2007 X-DSPAM-Confidence: 0.9993 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4746cc77191327536814152 X-DSPAM-Factors: 27, Received*ESMTPA+id, 0.00010, Received*(account, 0.00016, From*Alexey, 0.00024, With+best, 0.00024, best+regards, 0.00024, regards+Alexey, 0.00024, Received*ESMTPA, 0.00025, Received*with+ESMTPA, 0.00025, Alexey, 0.00041, Sender*owner+freebsd, 0.00047, Sender*freebsd, 0.00047, List-Post*freebsd, 0.00047, List-Post*, freebsd-stable@freebsd.org Subject: Re: amrd disk performance drop after running under high load X-BeenThere: freebsd-stable@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 12:50:07 -0000 Kris Kennaway wrote: >>>> what is your RAID controller configuration (read ahead/cache/write >>>> policy)? I have seen weird/bogus numbers (~100% busy) reported by >>>> systat -v when read ahead was enabled on LSI/amr controllers. >>> I tried to run with disabled Read-ahead, but it didn't help. >> I just ran into this myself, and apparently it can be caused by >> "Patrol Reads" where the adapter periodically scans the disks to look >> for media errors. You can turn this off using -stopPR with the megarc gg >> port. > Oops, -disPR is the correct command to disable, -stopPR just halts a PR > event in progress. Wow! Really disabling Patrol Reads solves the problem. Thank you! I have many amrd's and all of them appear to have Patrol Reads enabled by default. But the problem happenes only on three of them. Is this a hardware problem? With best regards, Alexey Popov _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 12:50:31 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30D0F16A4A1 for ; Fri, 23 Nov 2007 12:50:31 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 0B84113C45D for ; Fri, 23 Nov 2007 12:50:30 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 4218A1CC079; Fri, 23 Nov 2007 04:50:24 -0800 (PST) Date: Fri, 23 Nov 2007 04:50:24 -0800 From: Jeremy Chadwick To: Toomas Aas Message-ID: <20071123125024.GA16527@eos.sc1.parodius.com> References: <4746C893.1090305@raad.tartu.ee> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4746C893.1090305@raad.tartu.ee> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-stable@freebsd.org Subject: Re: "conatainer" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 12:50:31 -0000 On Fri, Nov 23, 2007 at 02:33:23PM +0200, Toomas Aas wrote: > With RELENG_7 source cvsupped 3 days ago, I noticed several occurrences of > word "conatainer" in sys/dev/aac/aac_debug.c > > ... Shouldn't it be "Container"? English is not my native language, > so I didn't want to file a PR in case there actually is a word "conatainer" > in English language. You're correct -- it should be container; someone was typing fast. :-) Another fun one to grep for is " teh" or "teh ". -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 13:17:40 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44A2C16A417 for ; Fri, 23 Nov 2007 13:17:40 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id D47A413C46A for ; Fri, 23 Nov 2007 13:17:39 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IvYPJ-0007r2-Mc for freebsd-stable@freebsd.org; Fri, 23 Nov 2007 13:17:21 +0000 Received: from 89-172-38-231.adsl.net.t-com.hr ([89.172.38.231]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 23 Nov 2007 13:17:21 +0000 Received: from ivoras by 89-172-38-231.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 23 Nov 2007 13:17:21 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Fri, 23 Nov 2007 14:16:57 +0100 Lines: 38 Message-ID: References: <4741905E.8050300@chistydom.ru> <47419AB3.5030008@chistydom.ru> <4741B3DE.2000009@chistydom.ru> <47430AE8.7050408@chistydom.ru> <9bbcef730711200915n12e37efcs67cf260641b9baab@mail.gmail.com> <47469EF9.70409@bulinfo.net> <9bbcef730711230216l74c30a08ja04a558742789b17@mail.gmail.com> <4746B42E.4040709@bulinfo.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig876A1DE41C3943F1B27F9DA5" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-38-231.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) In-Reply-To: <4746B42E.4040709@bulinfo.net> X-Enigmail-Version: 0.95.5 Sender: news Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 13:17:40 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig876A1DE41C3943F1B27F9DA5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Krassimir Slavchev wrote: > That's true but if the tests are same then they can be compared. >=20 >> - the code is most likely checking for changes in PHP libraries) >=20 > This is not recommended for production systems. PHP code accelerators / caches do that all the time. require_once() also does it. > Yes, may be it is easier to write perl/php scripts. I'm glad you're volunteering :) --------------enig876A1DE41C3943F1B27F9DA5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHRtLJldnAQVacBcgRApYfAJ9NyMEaUFS0pv9EHHagu3kJSG9NmQCeJwvM c17nCFhZXs8Oe6NM8F7YpIM= =d30v -----END PGP SIGNATURE----- --------------enig876A1DE41C3943F1B27F9DA5-- From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 13:29:58 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6535C16A417 for ; Fri, 23 Nov 2007 13:29:58 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2A54913C461 for ; Fri, 23 Nov 2007 13:29:58 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 58067470C6; Fri, 23 Nov 2007 08:33:02 -0500 (EST) Date: Fri, 23 Nov 2007 13:29:50 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Philip Murray In-Reply-To: Message-ID: <20071123132915.F98338@fledge.watson.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: Critical section expansion X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 13:29:58 -0000 On Fri, 23 Nov 2007, Philip Murray wrote: > I've been running this > (http://lists.freebsd.org/pipermail/cvs-src/2007-November/084049.html) > change on RELENG_7 in production since it was committed and it's fixed a > whole host of problems (NIC timeouts, TCP sessions dying under heavy disk > load etc.) for me. So far it hasn't created any new ones... > > Just wondering if it's going to get MFC'd before the 7.0 release? I asked Scott about this also -- turns out he doesn't use the automated MFC after reminder system, so doesn't tag commits with "MFC after". He does intend to MFC this before the release. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 14:31:23 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3944116A417; Fri, 23 Nov 2007 14:31:23 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 9A16013C4F2; Fri, 23 Nov 2007 14:31:21 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from js.berklix.net (p549A70DA.dip.t-dialin.net [84.154.112.218]) (authenticated bits=0) by tower.berklix.org (8.13.6/8.13.6) with ESMTP id lANDrZgQ004919; Fri, 23 Nov 2007 13:53:36 GMT (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by js.berklix.net (8.13.8/8.13.8) with ESMTP id lANDsAQF067866; Fri, 23 Nov 2007 14:54:10 +0100 (CET) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (localhost.js.berklix.net [127.0.0.1]) by fire.js.berklix.net (8.13.8/8.13.8) with ESMTP id lANDsAvo082948; Fri, 23 Nov 2007 14:54:10 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <200711231354.lANDsAvo082948@fire.js.berklix.net> To: Mike Jakubik In-reply-to: <47436D1E.3000005@rogers.com> References: <47436D1E.3000005@rogers.com> Comments: In-reply-to Mike Jakubik message dated "Tue, 20 Nov 2007 18:26:22 -0500." Date: Fri, 23 Nov 2007 14:54:10 +0100 From: "Julian H. Stacey" Cc: webmaster@freebsd.org, stable@freebsd.org Subject: Re: Schedule for 6.3R is a 404 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 14:31:23 -0000 Mike Jakubik wrote Tue, 20 Nov 2007 18:26:22 -0500 (Wed 00:26 CET): > Just an FYI, http://www.freebsd.org/releases/6.3R/schedule.html returns > a 404. This is linked from http://www.freebsd.org/releases/. Still so at Fri Nov 23 14:52:46 CET 2007 Ive cc'd webmaster@freebsd.org -- Julian Stacey. Munich Computer Consultant, BSD Unix C Linux. http://berklix.com Ihr Rauch = mein allergischer Kopfschmerz. Dump cigs 4 snuff. From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 18:55:46 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7854616A418 for ; Fri, 23 Nov 2007 18:55:46 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from angel.ticketswitch.com (angel.ticketswitch.com [IPv6:2002:57e0:1d4e::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2D7B313C448 for ; Fri, 23 Nov 2007 18:55:46 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from smaug.rattatosk ([10.50.50.2]) by angel.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Ivdgm-000909-L2 for stable@freebsd.org; Fri, 23 Nov 2007 18:55:44 +0000 Received: from dilbert.rattatosk ([10.50.50.6] helo=dilbert.ticketswitch.com) by smaug.rattatosk with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Ivdgm-0009Ac-In for stable@freebsd.org; Fri, 23 Nov 2007 18:55:44 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ivdgm-000Oq2-II for stable@freebsd.org; Fri, 23 Nov 2007 18:55:44 +0000 To: stable@freebsd.org Message-Id: From: Pete French Date: Fri, 23 Nov 2007 18:55:44 +0000 Cc: Subject: Is it O.K. to use the 7.0 ports tree on 6.3 ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 18:55:46 -0000 I have a set of machines running 7.0 and a set running 6.3 which I would like to use the same ports on. I was under the impression that there was only one ports tree, so is it safe to simply untar the ports.tgz file from 7.0 on the 6.3 machines, rename INDEX-7 to INDEX-6 and install away, or are there more subtle differences to tran the unwary ? cheers, -pcf. From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 19:31:50 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70D8516A418 for ; Fri, 23 Nov 2007 19:31:50 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from cauchy.math.missouri.edu (cauchy.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id 3D33D13C459 for ; Fri, 23 Nov 2007 19:31:49 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from laptop2.gateway.2wire.net (cauchy.math.missouri.edu [128.206.184.213]) by cauchy.math.missouri.edu (8.14.2/8.14.1) with ESMTP id lANIxuWq007831; Fri, 23 Nov 2007 12:59:57 -0600 (CST) (envelope-from stephen@math.missouri.edu) Message-ID: <47472331.4020809@math.missouri.edu> Date: Fri, 23 Nov 2007 13:00:01 -0600 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.9) Gecko/20071118 SeaMonkey/1.1.6 MIME-Version: 1.0 To: Pete French References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: Is it O.K. to use the 7.0 ports tree on 6.3 ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 19:31:50 -0000 Pete French wrote: > I have a set of machines running 7.0 and a set running 6.3 which I > would like to use the same ports on. I was under the impression that > there was only one ports tree, so is it safe to simply untar the > ports.tgz file from 7.0 on the 6.3 machines, rename INDEX-7 to INDEX-6 > and install away, or are there more subtle differences to tran the unwary ? > > cheers, > > -pcf. I think that they are the same, except INDEX-6 and INDEX-7 differ. So do your tar-untaring, and then do make fetchindex on the 6.3 machine(s). From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 19:50:51 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3712916A417; Fri, 23 Nov 2007 19:50:51 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from mail.soaustin.net (lefty.soaustin.net [66.135.55.46]) by mx1.freebsd.org (Postfix) with ESMTP id 1203813C4F3; Fri, 23 Nov 2007 19:50:51 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from bighuge.lonesome.com (cpe-66-68-146-180.austin.res.rr.com [66.68.146.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.soaustin.net (Postfix) with ESMTP id 82F608C0C2; Fri, 23 Nov 2007 13:17:27 -0600 (CST) From: Mark Linimon Organization: FreeBSD.org To: freebsd-stable@freebsd.org Date: Fri, 23 Nov 2007 07:17:45 -0600 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711230717.46555.linimon@FreeBSD.org> Cc: stable@freebsd.org, Pete French Subject: Re: Is it O.K. to use the 7.0 ports tree on 6.3 ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 19:50:51 -0000 On Friday 23 November 2007, Pete French wrote: > is it safe to simply untar the ports.tgz file from 7.0 on the 6.3 > machines, rename INDEX-7 to INDEX-6 and install away, or are there > more subtle differences to tran the unwary ? The dependencies can vary depending on OS release, so it's not guaranteed to work. Use 'make fetchindex' after you install to get the latest snapshot for 6-STABLE. mcl From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 19:50:51 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3712916A417; Fri, 23 Nov 2007 19:50:51 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from mail.soaustin.net (lefty.soaustin.net [66.135.55.46]) by mx1.freebsd.org (Postfix) with ESMTP id 1203813C4F3; Fri, 23 Nov 2007 19:50:51 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from bighuge.lonesome.com (cpe-66-68-146-180.austin.res.rr.com [66.68.146.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.soaustin.net (Postfix) with ESMTP id 82F608C0C2; Fri, 23 Nov 2007 13:17:27 -0600 (CST) From: Mark Linimon Organization: FreeBSD.org To: freebsd-stable@freebsd.org Date: Fri, 23 Nov 2007 07:17:45 -0600 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711230717.46555.linimon@FreeBSD.org> Cc: stable@freebsd.org, Pete French Subject: Re: Is it O.K. to use the 7.0 ports tree on 6.3 ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 19:50:51 -0000 On Friday 23 November 2007, Pete French wrote: > is it safe to simply untar the ports.tgz file from 7.0 on the 6.3 > machines, rename INDEX-7 to INDEX-6 and install away, or are there > more subtle differences to tran the unwary ? The dependencies can vary depending on OS release, so it's not guaranteed to work. Use 'make fetchindex' after you install to get the latest snapshot for 6-STABLE. mcl From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 19:57:53 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C83916A420; Fri, 23 Nov 2007 19:57:53 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from angel.ticketswitch.com (angel.ticketswitch.com [IPv6:2002:57e0:1d4e::1]) by mx1.freebsd.org (Postfix) with ESMTP id D017E13C45B; Fri, 23 Nov 2007 19:57:52 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from smaug.rattatosk ([10.50.50.2]) by angel.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Iveeq-0009Xp-7i; Fri, 23 Nov 2007 19:57:48 +0000 Received: from dilbert.rattatosk ([10.50.50.6] helo=dilbert.ticketswitch.com) by smaug.rattatosk with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Iveeq-0009gL-5U; Fri, 23 Nov 2007 19:57:48 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iveeq-000PPa-4y; Fri, 23 Nov 2007 19:57:48 +0000 To: freebsd-stable@freebsd.org, linimon@FreeBSD.org In-Reply-To: <200711230717.46555.linimon@FreeBSD.org> Message-Id: From: Pete French Date: Fri, 23 Nov 2007 19:57:48 +0000 Cc: stable@freebsd.org Subject: Re: Is it O.K. to use the 7.0 ports tree on 6.3 ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 19:57:53 -0000 > The dependencies can vary depending on OS release, so it's not > guaranteed to work. Use 'make fetchindex' after you install to > get the latest snapshot for 6-STABLE. Thanks, that was the bit I had forgotten! cheers, -pcf. From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 19:57:53 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C83916A420; Fri, 23 Nov 2007 19:57:53 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from angel.ticketswitch.com (angel.ticketswitch.com [IPv6:2002:57e0:1d4e::1]) by mx1.freebsd.org (Postfix) with ESMTP id D017E13C45B; Fri, 23 Nov 2007 19:57:52 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from smaug.rattatosk ([10.50.50.2]) by angel.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Iveeq-0009Xp-7i; Fri, 23 Nov 2007 19:57:48 +0000 Received: from dilbert.rattatosk ([10.50.50.6] helo=dilbert.ticketswitch.com) by smaug.rattatosk with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Iveeq-0009gL-5U; Fri, 23 Nov 2007 19:57:48 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iveeq-000PPa-4y; Fri, 23 Nov 2007 19:57:48 +0000 To: freebsd-stable@freebsd.org, linimon@FreeBSD.org In-Reply-To: <200711230717.46555.linimon@FreeBSD.org> Message-Id: From: Pete French Date: Fri, 23 Nov 2007 19:57:48 +0000 Cc: stable@freebsd.org Subject: Re: Is it O.K. to use the 7.0 ports tree on 6.3 ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 19:57:53 -0000 > The dependencies can vary depending on OS release, so it's not > guaranteed to work. Use 'make fetchindex' after you install to > get the latest snapshot for 6-STABLE. Thanks, that was the bit I had forgotten! cheers, -pcf. From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 20:49:06 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4415016A417; Fri, 23 Nov 2007 20:49:06 +0000 (UTC) (envelope-from sat@cenkes.org) Received: from heka.cenkes.org (heka.cenkes.org [208.79.80.110]) by mx1.freebsd.org (Postfix) with ESMTP id 2070913C468; Fri, 23 Nov 2007 20:49:06 +0000 (UTC) (envelope-from sat@cenkes.org) Received: from amilo.cenkes.org (ppp85-141-135-156.pppoe.mtu-net.ru [85.141.135.156]) (Authenticated sender: sat) by heka.cenkes.org (Postfix) with ESMTP id E89BA242F82A; Fri, 23 Nov 2007 23:31:51 +0300 (MSK) Date: Fri, 23 Nov 2007 23:31:50 +0300 From: Andrew Pantyukhin To: Jeremy Chadwick Message-ID: <20071123203149.GT66812@amilo.cenkes.org> References: <4746C893.1090305@raad.tartu.ee> <20071123125024.GA16527@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071123125024.GA16527@eos.sc1.parodius.com> X-OS: FreeBSD 8.0-CURRENT amd64 User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Toomas Aas , freebsd-stable@freebsd.org Subject: Re: "conatainer" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: infofarmer@FreeBSD.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 20:49:06 -0000 On Fri, Nov 23, 2007 at 04:50:24AM -0800, Jeremy Chadwick wrote: > Another fun one to grep for is " teh" or "teh ". grep -w teh :) From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 21:43:58 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 194B416A421; Fri, 23 Nov 2007 21:43:58 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id C57BA13C478; Fri, 23 Nov 2007 21:43:56 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <474749A4.7010806@FreeBSD.org> Date: Fri, 23 Nov 2007 22:44:04 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Joseph Koshy References: <4741905E.8050300@chistydom.ru> <4742ADFE.40902@FreeBSD.org> <4742C46A.1060701@chistydom.ru> <47432F77.3030606@FreeBSD.org> <474339E9.4080301@FreeBSD.org> <4743629B.9090408@FreeBSD.org> <47456B71.5040205@chistydom.ru> <4745E5B3.6060200@FreeBSD.org> <47468165.5010906@chistydom.ru> <4746B21F.7050906@FreeBSD.org> <84dead720711230409u112b0a01k97e58d0ff0c61f8b@mail.gmail.com> In-Reply-To: <84dead720711230409u112b0a01k97e58d0ff0c61f8b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Attilio Rao , freebsd-stable@freebsd.org, Alexey Popov Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 21:43:58 -0000 Joseph Koshy wrote: >>> Also I tried to find what else is slow in FreeBSD, I tried hwpmc as >>> module and in kernel, but it fails with error: >>> pmc: Unknown Intel CPU. >>> module_register_init: MOD_LOAD (hwpmc, 0xffffffff804833e0, >>> 0xffffffff809338a0) error 78 > >> There are patches you need to enable it on woodcrest. They are in my p4 >> branch (kris-contention) but I don't have time right now to extract them. > > These patches make hwpmc treat these CPUs are possessing Pentium-Pro class > PMCs. > > Unfortunately, this is easy to do, but incorrect: > - There are differences in the legal bit values that may be loaded into > PMC registers for many hardware events. > - hwpmc needs to be taught to support measurements on CPUs with > multiple cores per package. > > And then there is additional work to support these CPUS > at the same level as the current set: > - The hardware events supported are named differently; documentation, > libpmc's event selector parsing code need to be changed to suit. > - The hardware supports a new class of "fixed function" PMCs that > hwpmc needs to support. > Well, this is all true, but overlooks the point that it does minimally work, which is of critical importance to people with one of these CPUs who want to actually use your tool ;) Kris From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 22:14:20 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FFFB16A420 for ; Fri, 23 Nov 2007 22:14:20 +0000 (UTC) (envelope-from askbill@conducive.net) Received: from conducive.net (lindfield.ch [203.194.153.81]) by mx1.freebsd.org (Postfix) with ESMTP id 264A013C4D5 for ; Fri, 23 Nov 2007 22:14:20 +0000 (UTC) (envelope-from askbill@conducive.net) Received: from cm218-253-81-177.hkcable.com.hk ([218.253.81.177]:62893 helo=pb.local) by conducive.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1IvghN-0004Yu-7r for freebsd-stable@freebsd.org; Fri, 23 Nov 2007 22:08:33 +0000 Message-ID: <47474F60.4080804@conducive.net> Date: Fri, 23 Nov 2007 22:08:32 +0000 From: =?UTF-8?B?6Z+T5a625qiZIEJpbGwgSGFja2Vy?= User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.2) Gecko/20070221 SeaMonkey/1.1.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Buildworld failures -6.3-PRE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 22:14:20 -0000 Many such, Wearing out my csup welcome for 'RELENG_6'. Same or similar error when attempting to regress to 'RELENG_6_2' Details: ================================================================= -------------------------------------------------------------- >>> stage 2.3: build tools -------------------------------------------------------------- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/sbin:/bin:/usr/sbin:/usr/bin WORLDTMP=/usr/obj/usr/src/tmp MAKEFLAGS="-m /usr/src/tools/build/mk -j 9 -m /usr/src/share/mk" /usr/obj/usr/src/make.amd64/make -f Makefile.inc1 TARGET=amd64 TARGET_ARCH=amd64 DESTDIR= BOOTSTRAPPING=602113 -DNO_LINT -DNO_CPU_CFLAGS -DNO_WARNS build-tools ===> bin/csh (obj,build-tools) grep 'ERR_' /usr/src/bin/csh/../../contrib/tcsh/sh.err.c | grep '^#define' >> sh.err.h cc -E -O2 -fno-strict-aliasing -pipe -I. -I/usr/src/bin/csh -I/usr/src/bin/csh/../../contrib/tcsh -D_PATH_TCSHELL='"/bin/csh"' -DHAVE_ICONV -I/usr/obj/usr/src/tmp/legacy/usr/include /usr/src/bin/csh/../../contrib/tcsh/tc.const.c /usr/src/bin/csh/../../contrib/tcsh/sh.char.h /usr/src/bin/csh/config.h /usr/src/bin/csh/../../contrib/tcsh/config_f.h /usr/src/bin/csh/../../contrib/tcsh/sh.types.h sh.err.h -D_h_tc_const | grep 'Char STR' | sed -e 's/Char \([a-zA-Z0-9_]*\)\(.*\)/extern Char \1[];/' | sort >> tc.const.h cc -o gethost -L/usr/obj/usr/src/tmp/legacy/usr/lib -O2 -fno-strict-aliasing -pipe -I. -I/usr/src/bin/csh -I/usr/src/bin/csh/../../contrib/tcsh -D_PATH_TCSHELL='"/bin/csh"' -DHAVE_ICONV -I/usr/obj/usr/src/tmp/legacy/usr/include /usr/src/bin/csh/../../contrib/tcsh/gethost.c /var/tmp//ccMRLXC4.o(.text+0x9): In function `gettoken': : undefined reference to `__mb_sb_limit' /var/tmp//ccMRLXC4.o(.text+0x8d): In function `gettoken': : undefined reference to `__mb_sb_limit' *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error ===================================== I thought this had been fixed? Bill Hacker From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 22:31:43 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B4A316A420 for ; Fri, 23 Nov 2007 22:31:43 +0000 (UTC) (envelope-from askbill@conducive.net) Received: from conducive.net (conducive.org [203.194.153.81]) by mx1.freebsd.org (Postfix) with ESMTP id 282C313C46B for ; Fri, 23 Nov 2007 22:31:43 +0000 (UTC) (envelope-from askbill@conducive.net) Received: from cm218-253-81-177.hkcable.com.hk ([218.253.81.177]:62953 helo=pb.local) by conducive.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Ivh3k-0004h3-Ps for freebsd-stable@freebsd.org; Fri, 23 Nov 2007 22:31:41 +0000 Message-ID: <474754CC.2070807@conducive.net> Date: Fri, 23 Nov 2007 22:31:40 +0000 From: =?UTF-8?B?6Z+T5a625qiZIEJpbGwgSGFja2Vy?= User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.2) Gecko/20070221 SeaMonkey/1.1.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Buildworld failures - 6.3-PRE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 22:31:43 -0000 Confirming localized failure: cd'ed to /usr/src/contrib/tcsh ========================================== triligon# ./configure checking build system type... amd64-unknown-freebsd6.3 checking host system type... amd64-unknown-freebsd6.3 checking cached host tuple... ok Tcsh will use configuration file `bsd4.4'. checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking how to run the C preprocessor... gcc -E checking for egrep... grep -E checking whether gcc needs -traditional... no checking for library containing crypt... -lcrypt checking for library containing getspnam... no checking for library containing tgetent... -ltermlib checking for library containing gethostbyname... none required checking for library containing connect... none required checking for library containing iconv... no checking for ANSI C header files... no checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking auth.h usability... no checking auth.h presence... no checking for auth.h... no checking for inttypes.h... (cached) yes checking shadow.h usability... no checking shadow.h presence... no checking for shadow.h... no checking for stdint.h... (cached) yes checking utmpx.h usability... no checking utmpx.h presence... no checking for utmpx.h... no checking utmp.h usability... yes checking utmp.h presence... yes checking for utmp.h... yes checking wchar.h usability... yes checking wchar.h presence... yes checking for wchar.h... yes checking for wchar_t... yes checking size of wchar_t... 4 checking wctype.h usability... yes checking wctype.h presence... yes checking for wctype.h... yes checking for dirent.h that defines DIR... yes checking for library containing opendir... none required checking whether stat file-mode macros are broken... no checking for ANSI C header files... (cached) no checking for long long... yes checking for uid_t in sys/types.h... yes checking type of array argument to getgroups... gid_t checking for mode_t... yes checking return type of signal handlers... void checking for size_t... yes checking for uid_t in sys/types.h... (cached) yes checking for socklen_t... yes checking for struct dirent.d_ino... yes checking for struct utmp.ut_host... no checking for struct utmp.ut_user... no checking for struct utmp.ut_tv... no checking for struct utmp.ut_xtime... no checking for struct sockaddr_storage.ss_family... yes checking for an ANSI C-conforming const... yes checking for function prototypes... yes checking for working volatile... yes checking whether gethostname is declared... yes checking for dup2... yes checking for getcwd... yes checking for gethostname... yes checking for getpwent... yes checking for getutent... no checking for memmove... yes checking for memset... yes checking for nice... yes checking for nl_langinfo... yes checking for sbrk... yes checking for setpgid... yes checking for setpriority... yes checking for strerror... yes checking for strstr... yes checking for sysconf... yes checking for wcwidth... yes checking whether getpgrp requires zero arguments... yes checking whether setpgrp takes no argument... no configure: creating ./config.status config.status: creating Makefile config.status: creating config.h =================== triligon# make grep 'ERR_' ./sh.err.c | grep '^#define' >> sh.err.h gcc -E -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' -D_h_tc_const ./tc.const.c | sed -n -e 's/^\(Char STR[a-zA-Z0-9_]*\) *\[ *\].*/extern \1[];/p' | sort >> tc.const.h gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.dir.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.dol.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.err.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.exec.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.char.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.exp.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.file.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.func.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.glob.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.hist.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.init.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.lex.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.misc.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.parse.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.print.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.proc.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.sem.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.set.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.time.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' glob.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' mi.termios.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' ma.setp.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' vms.termcap.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' tw.help.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' tw.init.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' tw.parse.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' tw.spell.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' tw.comp.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' tw.color.c grep '[FV]_' ./ed.defns.c | grep '^#define' >> ed.defns.h gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' ed.chared.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' ed.refresh.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' ed.screen.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' ed.init.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' ed.inputl.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' ed.defns.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' ed.xmap.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' ed.term.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' tc.alloc.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' tc.bind.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' tc.const.c rm -f gethost gcc -o gethost -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' ./gethost.c -ltermlib -lcrypt /var/tmp//ccSrQDLG.o(.text+0x9): In function `gettoken': ./gethost.c:126: undefined reference to `__mb_sb_limit' /var/tmp//ccSrQDLG.o(.text+0x8d):./gethost.c:139: undefined reference to `__mb_sb_limit' *** Error code 1 Stop in /usr/src/contrib/tcsh. From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 22:34:31 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAE1816A419 for ; Fri, 23 Nov 2007 22:34:31 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by mx1.freebsd.org (Postfix) with ESMTP id B692013C4E7 for ; Fri, 23 Nov 2007 22:34:31 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so9351907pyb for ; Fri, 23 Nov 2007 14:34:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=JhxCF+1sNenyiSnuBPNxIr/gWl8RajCNKx7bhtjKO58=; b=ECMhC0SFOH0Z6gPwtxfTq3xFt5/z9KYma1nhz34n/zxzcU1toHLN7cSOBySRpmouPyMdyF2/E0oantin7U7ckaZwKkOjGOyDsWnvtx9aO8jGj/OlyGz2GIw0Vzl/xwiMdw7Aj+B+n2egMUtwFP4Ef85ojMrxfwQQlso7yLqHY+I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=S5g6rWx/4K6KmpDWHI2pjZfEOwaZeWKYjMgaUld2ZNM2MY82kdQhx/B8n33wJSeq4F3PkjMdYwmS+K6dEwPTEdWFTa50A+LlVAJq+irBiOpG+9ltW6BlDg2hMBWc/CPYevsWwvMfYeuDzM4qUmkc/HTtBRrD6h699PfJCx7HFHM= Received: by 10.64.76.15 with SMTP id y15mr23127663qba.1195857270509; Fri, 23 Nov 2007 14:34:30 -0800 (PST) Received: by 10.65.105.5 with HTTP; Fri, 23 Nov 2007 14:34:30 -0800 (PST) Message-ID: Date: Fri, 23 Nov 2007 22:34:30 +0000 From: "Aryeh Friedman" To: "=?ISO-8859-1?Q?=B6_Bill_Hacker?=" In-Reply-To: <47474F60.4080804@conducive.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <47474F60.4080804@conducive.net> Cc: freebsd-stable@freebsd.org Subject: Re: Buildworld failures -6.3-PRE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 22:34:32 -0000 On 11/23/07, =B6 Bill Hacker wrote: > Many such, > > Wearing out my csup welcome for 'RELENG_6'. > > Same or similar error when attempting to regress to 'RELENG_6_2' > > Details: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > -------------------------------------------------------------- > >>> stage 2.3: build tools > -------------------------------------------------------------- > cd /usr/src; MAKEOBJDIRPREFIX=3D/usr/obj INSTALL=3D"sh > /usr/src/tools/install.sh" > PATH=3D/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/u= sr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/sbin:/bin:/usr/sbin:/usr/bin > WORLDTMP=3D/usr/obj/usr/src/tmp MAKEFLAGS=3D"-m /usr/src/tools/build/m= k -j 9 > -m > /usr/src/share/mk" /usr/obj/usr/src/make.amd64/make -f Makefile.inc1 > TARGET=3Damd64 TARGET_ARCH=3Damd64 DESTDIR=3D BOOTSTRAPPING=3D602113 -D= NO_LINT > -DNO_CPU_CFLAGS -DNO_WARNS build-tools > =3D=3D=3D> bin/csh (obj,build-tools) > grep 'ERR_' /usr/src/bin/csh/../../contrib/tcsh/sh.err.c | grep '^#define= ' > >> > sh.err.h > cc -E -O2 -fno-strict-aliasing -pipe -I. -I/usr/src/bin/csh > -I/usr/src/bin/csh/../../contrib/tcsh -D_PATH_TCSHELL=3D'"/bin/csh"' > -DHAVE_ICONV > -I/usr/obj/usr/src/tmp/legacy/usr/include > /usr/src/bin/csh/../../contrib/tcsh/tc.const.c > /usr/src/bin/csh/../../contrib/tcsh/sh.char.h /usr/src/bin/csh/config.h > /usr/src/bin/csh/../../contrib/tcsh/config_f.h > /usr/src/bin/csh/../../contrib/tcsh/sh.types.h sh.err.h -D_h_tc_const | g= rep > 'Char STR' | sed -e 's/Char \([a-zA-Z0-9_]*\)\(.*\)/extern Char \1[];/' = | > sort > >> tc.const.h > cc -o gethost -L/usr/obj/usr/src/tmp/legacy/usr/lib -O2 > -fno-strict-aliasing > -pipe -I. -I/usr/src/bin/csh -I/usr/src/bin/csh/../../contrib/tcsh > -D_PATH_TCSHELL=3D'"/bin/csh"' -DHAVE_ICONV > -I/usr/obj/usr/src/tmp/legacy/usr/include > /usr/src/bin/csh/../../contrib/tcsh/gethost.c > /var/tmp//ccMRLXC4.o(.text+0x9): In function `gettoken': > : undefined reference to `__mb_sb_limit' > /var/tmp//ccMRLXC4.o(.text+0x8d): In function `gettoken': > : undefined reference to `__mb_sb_limit' > *** Error code 1 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > I thought this had been fixed? Same error under -current.... also note to those who are courious about my mergemaster patch Doug was right skipping make altogether is the wrong solution... will look into it deeeper From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 22:36:06 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B3EA16A41A for ; Fri, 23 Nov 2007 22:36:06 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by mx1.freebsd.org (Postfix) with ESMTP id DB6CD13C4CC for ; Fri, 23 Nov 2007 22:36:05 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so9352705pyb for ; Fri, 23 Nov 2007 14:36:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=XfleOrXPrhXVRyp3OoMbsvncqys4sHOD9eZLTm1e9sU=; b=N8HQXFgAZfsMfF+B7jQp1cb0TfWCEeVXrHQUbTfh8bhiRyicsPUHCAwEqsMeE8Nl85NYB5TVCKY+RUkRYsvVgizwseUOnVf6vn1BLtw5cFTJcttiA9zKtOzVCQSFJVY0zyjhXDx6Wy1Dl34qAKKRX3BXumpr6VKEWv/xShYfr58= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nznpLMJ9P7cDlrW5CzdujjBigGToOcK2WygFMuWK7Q1QUQdYfLafFSsqdZ9rXaMCyoHT9BHR+o6wM+ll49bjHy+E2XVBps0/WjEfOf/4eCVQrSLe+TxtZf177FBlYw6yKzP2vvTsiEDShRcAbumU/N4Jyzs+AiX1LGVsljXPz3Y= Received: by 10.65.122.13 with SMTP id z13mr23070659qbm.1195857364828; Fri, 23 Nov 2007 14:36:04 -0800 (PST) Received: by 10.65.105.5 with HTTP; Fri, 23 Nov 2007 14:36:04 -0800 (PST) Message-ID: Date: Fri, 23 Nov 2007 22:36:04 +0000 From: "Aryeh Friedman" To: "=?BIG5?B?wfquYbzQIEJpbGwgSGFja2Vy?=" In-Reply-To: <474754CC.2070807@conducive.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <474754CC.2070807@conducive.net> Cc: freebsd-stable@freebsd.org Subject: Re: Buildworld failures - 6.3-PRE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 22:36:06 -0000 So your saying until fixed NO_TCSH should be in make.conf? On 11/23/07, $B4Z2HI8(B Bill Hacker wrote: > Confirming localized failure: > > cd'ed to /usr/src/contrib/tcsh > > ========================================== > > triligon# ./configure > checking build system type... amd64-unknown-freebsd6.3 > checking host system type... amd64-unknown-freebsd6.3 > checking cached host tuple... ok > Tcsh will use configuration file `bsd4.4'. > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking how to run the C preprocessor... gcc -E > checking for egrep... grep -E > checking whether gcc needs -traditional... no > checking for library containing crypt... -lcrypt > checking for library containing getspnam... no > checking for library containing tgetent... -ltermlib > checking for library containing gethostbyname... none required > checking for library containing connect... none required > checking for library containing iconv... no > checking for ANSI C header files... no > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking auth.h usability... no > checking auth.h presence... no > checking for auth.h... no > checking for inttypes.h... (cached) yes > checking shadow.h usability... no > checking shadow.h presence... no > checking for shadow.h... no > checking for stdint.h... (cached) yes > checking utmpx.h usability... no > checking utmpx.h presence... no > checking for utmpx.h... no > checking utmp.h usability... yes > checking utmp.h presence... yes > checking for utmp.h... yes > checking wchar.h usability... yes > checking wchar.h presence... yes > checking for wchar.h... yes > checking for wchar_t... yes > checking size of wchar_t... 4 > checking wctype.h usability... yes > checking wctype.h presence... yes > checking for wctype.h... yes > checking for dirent.h that defines DIR... yes > checking for library containing opendir... none required > checking whether stat file-mode macros are broken... no > checking for ANSI C header files... (cached) no > checking for long long... yes > checking for uid_t in sys/types.h... yes > checking type of array argument to getgroups... gid_t > checking for mode_t... yes > checking return type of signal handlers... void > checking for size_t... yes > checking for uid_t in sys/types.h... (cached) yes > checking for socklen_t... yes > checking for struct dirent.d_ino... yes > checking for struct utmp.ut_host... no > checking for struct utmp.ut_user... no > checking for struct utmp.ut_tv... no > checking for struct utmp.ut_xtime... no > checking for struct sockaddr_storage.ss_family... yes > checking for an ANSI C-conforming const... yes > checking for function prototypes... yes > checking for working volatile... yes > checking whether gethostname is declared... yes > checking for dup2... yes > checking for getcwd... yes > checking for gethostname... yes > checking for getpwent... yes > checking for getutent... no > checking for memmove... yes > checking for memset... yes > checking for nice... yes > checking for nl_langinfo... yes > checking for sbrk... yes > checking for setpgid... yes > checking for setpriority... yes > checking for strerror... yes > checking for strstr... yes > checking for sysconf... yes > checking for wcwidth... yes > checking whether getpgrp requires zero arguments... yes > checking whether setpgrp takes no argument... no > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > > =================== > > triligon# make > grep 'ERR_' ./sh.err.c | grep '^#define' >> sh.err.h > gcc -E -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' -D_h_tc_const > ./tc.const.c | sed -n -e 's/^\(Char STR[a-zA-Z0-9_]*\) *\[ *\].*/extern > \1[];/p' | sort >> tc.const.h > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.dir.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.dol.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.err.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.exec.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.char.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.exp.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.file.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.func.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.glob.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.hist.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.init.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.lex.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.misc.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.parse.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.print.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.proc.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.sem.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.set.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.time.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' glob.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' mi.termios.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' ma.setp.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' vms.termcap.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' tw.help.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' tw.init.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' tw.parse.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' tw.spell.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' tw.comp.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' tw.color.c > grep '[FV]_' ./ed.defns.c | grep '^#define' >> ed.defns.h > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' ed.chared.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' ed.refresh.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' ed.screen.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' ed.init.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' ed.inputl.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' ed.defns.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' ed.xmap.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' ed.term.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' tc.alloc.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' tc.bind.c > gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' tc.const.c > rm -f gethost > gcc -o gethost -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' > ./gethost.c -ltermlib -lcrypt > /var/tmp//ccSrQDLG.o(.text+0x9): In function `gettoken': > ./gethost.c:126: undefined reference to `__mb_sb_limit' > /var/tmp//ccSrQDLG.o(.text+0x8d):./gethost.c:139: undefined reference to > `__mb_sb_limit' > *** Error code 1 > > Stop in /usr/src/contrib/tcsh. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 23:03:19 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F8BD16A41A for ; Fri, 23 Nov 2007 23:03:19 +0000 (UTC) (envelope-from askbill@conducive.net) Received: from conducive.net (conducive.org [203.194.153.81]) by mx1.freebsd.org (Postfix) with ESMTP id 0699C13C459 for ; Fri, 23 Nov 2007 23:03:18 +0000 (UTC) (envelope-from askbill@conducive.net) Received: from cm218-253-81-177.hkcable.com.hk ([218.253.81.177]:63179 helo=pb.local) by conducive.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1IvhYL-0004nd-S2 for freebsd-stable@freebsd.org; Fri, 23 Nov 2007 23:03:17 +0000 Message-ID: <47475C35.4030503@conducive.net> Date: Fri, 23 Nov 2007 23:03:17 +0000 From: =?UTF-8?B?6Z+T5a625qiZIEJpbGwgSGFja2Vy?= User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.2) Gecko/20070221 SeaMonkey/1.1.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <474754CC.2070807@conducive.net> <47475829.4040706@conducive.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: Buildworld failures - 6.3-PRE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 23:03:19 -0000 Aryeh Friedman wrote: > On 11/23/07, � Bill Hacker wrote: >> Aryeh Friedman wrote: >>> So your saying until fixed NO_TCSH should be in make.conf? >> Wouldn't break *my* heart, I prefer bash. >> >> But AFAIK it breaks a lot of other stuff that depends on tcsh or >> tcsh-as-csh. >> >> (already tried nuking that whole tree. No Joy). >> >> Bill > > I am about to embark on an other buildworld/mergemaster/etc and am > willing to look into this in detail so I will send you a patch if I > find one What I posted was 6-STABLE relevant. I'm just now updating an R&D box to HEAD - may not have the problem. As to patch - don't send it to *me*. I don't use patches , OR drink blended whisky. I use rm -Rf and go back to the last thing that JFW'ed. If you can't get it right the first time .... Still running several 4.11-STABLE 1U's for that reason. Hardware and code that JFW (VIA CPU's). Bill > >>>> Confirming localized failure: >>>> >>>> cd'ed to /usr/src/contrib/tcsh >>>> >>>> ========================================== >>>> >>>> triligon# ./configure >>>> checking build system type... amd64-unknown-freebsd6.3 >>>> checking host system type... amd64-unknown-freebsd6.3 >>>> checking cached host tuple... ok >>>> Tcsh will use configuration file `bsd4.4'. >>>> checking for gcc... gcc >>>> checking for C compiler default output file name... a.out >>>> checking whether the C compiler works... yes >>>> checking whether we are cross compiling... no >>>> checking for suffix of executables... >>>> checking for suffix of object files... o >>>> checking whether we are using the GNU C compiler... yes >>>> checking whether gcc accepts -g... yes >>>> checking for gcc option to accept ANSI C... none needed >>>> checking how to run the C preprocessor... gcc -E >>>> checking for egrep... grep -E >>>> checking whether gcc needs -traditional... no >>>> checking for library containing crypt... -lcrypt >>>> checking for library containing getspnam... no >>>> checking for library containing tgetent... -ltermlib >>>> checking for library containing gethostbyname... none required >>>> checking for library containing connect... none required >>>> checking for library containing iconv... no >>>> checking for ANSI C header files... no >>>> checking for sys/types.h... yes >>>> checking for sys/stat.h... yes >>>> checking for stdlib.h... yes >>>> checking for string.h... yes >>>> checking for memory.h... yes >>>> checking for strings.h... yes >>>> checking for inttypes.h... yes >>>> checking for stdint.h... yes >>>> checking for unistd.h... yes >>>> checking auth.h usability... no >>>> checking auth.h presence... no >>>> checking for auth.h... no >>>> checking for inttypes.h... (cached) yes >>>> checking shadow.h usability... no >>>> checking shadow.h presence... no >>>> checking for shadow.h... no >>>> checking for stdint.h... (cached) yes >>>> checking utmpx.h usability... no >>>> checking utmpx.h presence... no >>>> checking for utmpx.h... no >>>> checking utmp.h usability... yes >>>> checking utmp.h presence... yes >>>> checking for utmp.h... yes >>>> checking wchar.h usability... yes >>>> checking wchar.h presence... yes >>>> checking for wchar.h... yes >>>> checking for wchar_t... yes >>>> checking size of wchar_t... 4 >>>> checking wctype.h usability... yes >>>> checking wctype.h presence... yes >>>> checking for wctype.h... yes >>>> checking for dirent.h that defines DIR... yes >>>> checking for library containing opendir... none required >>>> checking whether stat file-mode macros are broken... no >>>> checking for ANSI C header files... (cached) no >>>> checking for long long... yes >>>> checking for uid_t in sys/types.h... yes >>>> checking type of array argument to getgroups... gid_t >>>> checking for mode_t... yes >>>> checking return type of signal handlers... void >>>> checking for size_t... yes >>>> checking for uid_t in sys/types.h... (cached) yes >>>> checking for socklen_t... yes >>>> checking for struct dirent.d_ino... yes >>>> checking for struct utmp.ut_host... no >>>> checking for struct utmp.ut_user... no >>>> checking for struct utmp.ut_tv... no >>>> checking for struct utmp.ut_xtime... no >>>> checking for struct sockaddr_storage.ss_family... yes >>>> checking for an ANSI C-conforming const... yes >>>> checking for function prototypes... yes >>>> checking for working volatile... yes >>>> checking whether gethostname is declared... yes >>>> checking for dup2... yes >>>> checking for getcwd... yes >>>> checking for gethostname... yes >>>> checking for getpwent... yes >>>> checking for getutent... no >>>> checking for memmove... yes >>>> checking for memset... yes >>>> checking for nice... yes >>>> checking for nl_langinfo... yes >>>> checking for sbrk... yes >>>> checking for setpgid... yes >>>> checking for setpriority... yes >>>> checking for strerror... yes >>>> checking for strstr... yes >>>> checking for sysconf... yes >>>> checking for wcwidth... yes >>>> checking whether getpgrp requires zero arguments... yes >>>> checking whether setpgrp takes no argument... no >>>> configure: creating ./config.status >>>> config.status: creating Makefile >>>> config.status: creating config.h >>>> >>>> =================== >>>> >>>> triligon# make >>>> grep 'ERR_' ./sh.err.c | grep '^#define' >> sh.err.h >>>> gcc -E -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' -D_h_tc_const >>>> ./tc.const.c | sed -n -e 's/^\(Char STR[a-zA-Z0-9_]*\) *\[ *\].*/extern >>>> \1[];/p' | sort >> tc.const.h >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.dir.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.dol.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.err.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.exec.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.char.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.exp.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.file.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.func.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.glob.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.hist.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.init.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.lex.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.misc.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.parse.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.print.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.proc.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.sem.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.set.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.time.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' glob.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> mi.termios.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' ma.setp.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> vms.termcap.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' tw.help.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' tw.init.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' tw.parse.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' tw.spell.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' tw.comp.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' tw.color.c >>>> grep '[FV]_' ./ed.defns.c | grep '^#define' >> ed.defns.h >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> ed.chared.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> ed.refresh.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> ed.screen.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' ed.init.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> ed.inputl.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' ed.defns.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' ed.xmap.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' ed.term.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' tc.alloc.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' tc.bind.c >>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' tc.const.c >>>> rm -f gethost >>>> gcc -o gethost -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >>>> ./gethost.c -ltermlib -lcrypt >>>> /var/tmp//ccSrQDLG.o(.text+0x9): In function `gettoken': >>>> ./gethost.c:126: undefined reference to `__mb_sb_limit' >>>> /var/tmp//ccSrQDLG.o(.text+0x8d):./gethost.c:139: undefined reference to >>>> `__mb_sb_limit' >>>> *** Error code 1 >>>> >>>> Stop in /usr/src/contrib/tcsh. >>>> _______________________________________________ >>>> freebsd-stable@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >>>> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 23:09:25 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8E3416A419 for ; Fri, 23 Nov 2007 23:09:25 +0000 (UTC) (envelope-from askbill@conducive.net) Received: from conducive.net (conducive.org [203.194.153.81]) by mx1.freebsd.org (Postfix) with ESMTP id 8791E13C469 for ; Fri, 23 Nov 2007 23:09:25 +0000 (UTC) (envelope-from askbill@conducive.net) Received: from cm218-253-81-177.hkcable.com.hk ([218.253.81.177]:63181 helo=pb.local) by conducive.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1IvheG-0004tw-Hz for freebsd-stable@freebsd.org; Fri, 23 Nov 2007 23:09:24 +0000 Message-ID: <47475DA4.8010108@conducive.net> Date: Fri, 23 Nov 2007 23:09:24 +0000 From: =?UTF-8?B?6Z+T5a625qiZIEJpbGwgSGFja2Vy?= User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.2) Gecko/20070221 SeaMonkey/1.1.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <474754CC.2070807@conducive.net> <47475829.4040706@conducive.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: Buildworld failures - 6.3-PRE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 23:09:25 -0000 Aryeh Friedman wrote: > btw I am starting with 6.2-RELEASE because of the cd issues I have > mentioned should I go straight to current or should I go to 6.3 then > upto current? > At the current state of at least the .jp and .dk mirrors, I had breakage from RELENG_6_0, _6_1, 6_1, 6_2 and RELENG_6 All AMD-64, and attempting to build with 6.3-PRERELEASE and world last built 27 October. YMMV, and this is on of of the Tomcats, Core-D 2-core, not a GA G33-DS3R Quad Core where I'm working up HEAD as soon as the csup completes. Bill > On 11/23/07, Aryeh Friedman wrote: >> On 11/23/07, � Bill Hacker wrote: >>> Aryeh Friedman wrote: >>>> So your saying until fixed NO_TCSH should be in make.conf? >>> Wouldn't break *my* heart, I prefer bash. >>> >>> But AFAIK it breaks a lot of other stuff that depends on tcsh or >>> tcsh-as-csh. >>> >>> (already tried nuking that whole tree. No Joy). >>> >>> Bill >> I am about to embark on an other buildworld/mergemaster/etc and am >> willing to look into this in detail so I will send you a patch if I >> find one >> >>>>> Confirming localized failure: >>>>> >>>>> cd'ed to /usr/src/contrib/tcsh >>>>> >>>>> ========================================== >>>>> >>>>> triligon# ./configure >>>>> checking build system type... amd64-unknown-freebsd6.3 >>>>> checking host system type... amd64-unknown-freebsd6.3 >>>>> checking cached host tuple... ok >>>>> Tcsh will use configuration file `bsd4.4'. >>>>> checking for gcc... gcc >>>>> checking for C compiler default output file name... a.out >>>>> checking whether the C compiler works... yes >>>>> checking whether we are cross compiling... no >>>>> checking for suffix of executables... >>>>> checking for suffix of object files... o >>>>> checking whether we are using the GNU C compiler... yes >>>>> checking whether gcc accepts -g... yes >>>>> checking for gcc option to accept ANSI C... none needed >>>>> checking how to run the C preprocessor... gcc -E >>>>> checking for egrep... grep -E >>>>> checking whether gcc needs -traditional... no >>>>> checking for library containing crypt... -lcrypt >>>>> checking for library containing getspnam... no >>>>> checking for library containing tgetent... -ltermlib >>>>> checking for library containing gethostbyname... none required >>>>> checking for library containing connect... none required >>>>> checking for library containing iconv... no >>>>> checking for ANSI C header files... no >>>>> checking for sys/types.h... yes >>>>> checking for sys/stat.h... yes >>>>> checking for stdlib.h... yes >>>>> checking for string.h... yes >>>>> checking for memory.h... yes >>>>> checking for strings.h... yes >>>>> checking for inttypes.h... yes >>>>> checking for stdint.h... yes >>>>> checking for unistd.h... yes >>>>> checking auth.h usability... no >>>>> checking auth.h presence... no >>>>> checking for auth.h... no >>>>> checking for inttypes.h... (cached) yes >>>>> checking shadow.h usability... no >>>>> checking shadow.h presence... no >>>>> checking for shadow.h... no >>>>> checking for stdint.h... (cached) yes >>>>> checking utmpx.h usability... no >>>>> checking utmpx.h presence... no >>>>> checking for utmpx.h... no >>>>> checking utmp.h usability... yes >>>>> checking utmp.h presence... yes >>>>> checking for utmp.h... yes >>>>> checking wchar.h usability... yes >>>>> checking wchar.h presence... yes >>>>> checking for wchar.h... yes >>>>> checking for wchar_t... yes >>>>> checking size of wchar_t... 4 >>>>> checking wctype.h usability... yes >>>>> checking wctype.h presence... yes >>>>> checking for wctype.h... yes >>>>> checking for dirent.h that defines DIR... yes >>>>> checking for library containing opendir... none required >>>>> checking whether stat file-mode macros are broken... no >>>>> checking for ANSI C header files... (cached) no >>>>> checking for long long... yes >>>>> checking for uid_t in sys/types.h... yes >>>>> checking type of array argument to getgroups... gid_t >>>>> checking for mode_t... yes >>>>> checking return type of signal handlers... void >>>>> checking for size_t... yes >>>>> checking for uid_t in sys/types.h... (cached) yes >>>>> checking for socklen_t... yes >>>>> checking for struct dirent.d_ino... yes >>>>> checking for struct utmp.ut_host... no >>>>> checking for struct utmp.ut_user... no >>>>> checking for struct utmp.ut_tv... no >>>>> checking for struct utmp.ut_xtime... no >>>>> checking for struct sockaddr_storage.ss_family... yes >>>>> checking for an ANSI C-conforming const... yes >>>>> checking for function prototypes... yes >>>>> checking for working volatile... yes >>>>> checking whether gethostname is declared... yes >>>>> checking for dup2... yes >>>>> checking for getcwd... yes >>>>> checking for gethostname... yes >>>>> checking for getpwent... yes >>>>> checking for getutent... no >>>>> checking for memmove... yes >>>>> checking for memset... yes >>>>> checking for nice... yes >>>>> checking for nl_langinfo... yes >>>>> checking for sbrk... yes >>>>> checking for setpgid... yes >>>>> checking for setpriority... yes >>>>> checking for strerror... yes >>>>> checking for strstr... yes >>>>> checking for sysconf... yes >>>>> checking for wcwidth... yes >>>>> checking whether getpgrp requires zero arguments... yes >>>>> checking whether setpgrp takes no argument... no >>>>> configure: creating ./config.status >>>>> config.status: creating Makefile >>>>> config.status: creating config.h >>>>> >>>>> =================== >>>>> >>>>> triligon# make >>>>> grep 'ERR_' ./sh.err.c | grep '^#define' >> sh.err.h >>>>> gcc -E -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' -D_h_tc_const >>>>> ./tc.const.c | sed -n -e 's/^\(Char STR[a-zA-Z0-9_]*\) *\[ >> *\].*/extern >>>>> \1[];/p' | sort >> tc.const.h >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' sh.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> sh.dir.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> sh.dol.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> sh.err.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> sh.exec.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> sh.char.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> sh.exp.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> sh.file.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> sh.func.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> sh.glob.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> sh.hist.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> sh.init.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> sh.lex.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> sh.misc.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> sh.parse.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> sh.print.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> sh.proc.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> sh.sem.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> sh.set.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> sh.time.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' glob.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >>> mi.termios.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> ma.setp.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >>> vms.termcap.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> tw.help.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> tw.init.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> tw.parse.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> tw.spell.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> tw.comp.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> tw.color.c >>>>> grep '[FV]_' ./ed.defns.c | grep '^#define' >> ed.defns.h >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >>> ed.chared.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >>> ed.refresh.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >>> ed.screen.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> ed.init.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >>> ed.inputl.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> ed.defns.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> ed.xmap.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> ed.term.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> tc.alloc.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> tc.bind.c >>>>> gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >> tc.const.c >>>>> rm -f gethost >>>>> gcc -o gethost -g -O2 -I. -I. -D_PATH_TCSHELL='"/usr/local/bin/tcsh"' >>>>> ./gethost.c -ltermlib -lcrypt >>>>> /var/tmp//ccSrQDLG.o(.text+0x9): In function `gettoken': >>>>> ./gethost.c:126: undefined reference to `__mb_sb_limit' >>>>> /var/tmp//ccSrQDLG.o(.text+0x8d):./gethost.c:139: undefined reference >> to >>>>> `__mb_sb_limit' >>>>> *** Error code 1 >>>>> >>>>> Stop in /usr/src/contrib/tcsh. >>>>> _______________________________________________ >>>>> freebsd-stable@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>>>> To unsubscribe, send any mail to >> "freebsd-stable-unsubscribe@freebsd.org" >>> _______________________________________________ >>> freebsd-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-stable@FreeBSD.ORG Fri Nov 23 23:22:53 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C87AC16A418 for ; Fri, 23 Nov 2007 23:22:53 +0000 (UTC) (envelope-from askbill@conducive.net) Received: from conducive.net (conducive.org [203.194.153.81]) by mx1.freebsd.org (Postfix) with ESMTP id A0E1613C45D for ; Fri, 23 Nov 2007 23:22:53 +0000 (UTC) (envelope-from askbill@conducive.net) Received: from cm218-253-81-177.hkcable.com.hk ([218.253.81.177]:63175 helo=pb.local) by conducive.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1IvhrI-0004vo-Td for freebsd-stable@freebsd.org; Fri, 23 Nov 2007 23:22:52 +0000 Message-ID: <474760CC.5070102@conducive.net> Date: Fri, 23 Nov 2007 23:22:52 +0000 From: =?UTF-8?B?6Z+T5a625qiZIEJpbGwgSGFja2Vy?= User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.2) Gecko/20070221 SeaMonkey/1.1.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <474754CC.2070807@conducive.net> <47475829.4040706@conducive.net> <47475DA4.8010108@conducive.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Buildworld failures - 6.3-PRE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 23:22:53 -0000 Aryeh Friedman wrote: > Here is a nasty idea... ftp the src dist files from 7.0-BETA3 do a > buildworld on them then upgrade from there That's a non-starter for the Tyan's Twin BGE NIC's and IHC7 CMFM SATA controller. Bill From owner-freebsd-stable@FreeBSD.ORG Sat Nov 24 00:41:08 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6E7D16A41A for ; Sat, 24 Nov 2007 00:41:08 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by mx1.freebsd.org (Postfix) with ESMTP id 41D4913C468 for ; Sat, 24 Nov 2007 00:41:07 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so9407692pyb for ; Fri, 23 Nov 2007 16:41:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=+BGdSt5O3mmS69ydlUC+hxsBlLDSft2C72gNsaka1ZM=; b=HEnuO3ZNxBZB/jkZzau2SWk6Gx9QR+XpXm0f8bEHBPJ+S64dcuEpuztTIqVhj4uqe0ncCvHr9yYxM03JZ3JQWV/aOnAGAFn3Fip7XwTBjQjPsMOHmzE2q4s9m1KB3QwkEN56bpldLN1lTUEv2L7oCsHV1uusjdt8tXvfmjjFBlY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QglcQcbwH4jUEIBETGN7t0DnIlKInz92o5QPLpiZ+O3zh2XFqEpCZFn/+pfa2Jtrby+pcklLJkpuSDH/gJN54CppqHcjtDSlwCohp/DschYSK5RKME0X0koS53rQ5x02Dv9/U35UMgrhWilK6logPTJ2RkFMgODMcydsmMq3zAA= Received: by 10.65.124.8 with SMTP id b8mr23264411qbn.1195864865817; Fri, 23 Nov 2007 16:41:05 -0800 (PST) Received: by 10.65.105.5 with HTTP; Fri, 23 Nov 2007 16:41:05 -0800 (PST) Message-ID: Date: Sat, 24 Nov 2007 00:41:05 +0000 From: "Aryeh Friedman" To: "=?ISO-8859-1?Q?=B6_Bill_Hacker?=" In-Reply-To: <474760CC.5070102@conducive.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <474754CC.2070807@conducive.net> <47475829.4040706@conducive.net> <47475DA4.8010108@conducive.net> <474760CC.5070102@conducive.net> Cc: freebsd-stable@freebsd.org Subject: Re: Buildworld failures - 6.3-PRE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2007 00:41:09 -0000 On 11/23/07, =B6 Bill Hacker wrote: > Aryeh Friedman wrote: > > Here is a nasty idea... ftp the src dist files from 7.0-BETA3 do a > > buildworld on them then upgrade from there > > That's a non-starter for the Tyan's > > Twin BGE NIC's and IHC7 CMFM SATA controller. Besides it turns out the sources for 7 are not in a dist file format yet anyways... btw I got a intresting clue on the re(4) stuff if it slows down on 6.2-release (yes I know thats not what I reported) do the following and it will clear up: ifconfig re0 192.168.2.2 -txcsum -rxcsum ifconfig lo0 127.0.0.1 route add default 192.168.2.1 From owner-freebsd-stable@FreeBSD.ORG Sat Nov 24 02:34:17 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A177C16A418 for ; Sat, 24 Nov 2007 02:34:17 +0000 (UTC) (envelope-from gmiller@classic-games.com) Received: from fmailhost03.isp.att.net (fmailhost03.isp.att.net [204.127.217.103]) by mx1.freebsd.org (Postfix) with ESMTP id AE2A613C448 for ; Sat, 24 Nov 2007 02:34:17 +0000 (UTC) (envelope-from gmiller@classic-games.com) Received: from [65.7.36.164] (host-65-7-36-164.mem.bellsouth.net?[65.7.36.164]) by bellsouth.net (frfwmhc03) with ESMTP id <20071124022133H0300lkjjse>; Sat, 24 Nov 2007 02:21:34 +0000 X-Originating-IP: [65.7.36.164] Message-ID: <47478A58.2000906@classic-games.com> Date: Fri, 23 Nov 2007 20:20:08 -0600 From: Greg Miller User-Agent: Thunderbird 2.0.0.6 (X11/20071105) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Maestro 2E on 6.3-PRERELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2007 02:34:17 -0000 I have a Maestro 2E sound card that works perfectly on 6.2-RELEASE-p8, but not on 6.3-PRERELEASE. Here's the dmesg: > Copyright (c) 1992-2007 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 6.3-PRERELEASE #13: Thu Nov 22 06:25:22 CST 2007 > greg@localhost:/usr/obj/usr/src/sys/CUSTOM > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Pentium(R) D CPU 3.00GHz (3606.95-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf62 Stepping = 2 > Features=0xbfebfbff > Features2=0xe43d > AMD Features=0x20000000 > AMD Features2=0x1 > Cores per package: 2 > real memory = 1073217536 (1023 MB) > avail memory = 1036808192 (988 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > acpi0: on motherboard > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > cpu0: on acpi0 > acpi_throttle0: on cpu0 > cpu1: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: irq 16 at device 1.0 on pci0 > pci3: on pcib1 > nvidia0: port 0xe800-0xe87f mem 0xdf000000-0xdfffffff,0xe0000000-0xefffffff,0xde000000-0xdeffffff irq 16 at device 0.0 on pci3 > nvidia0: [GIANT-LOCKED] > pcm0: mem 0xdddf8000-0xdddfbfff irq 19 at device 27.0 on pci0 > pcib2: irq 16 at device 28.0 on pci0 > pci2: on pcib2 > uhci0: port 0x7000-0x701f irq 20 at device 29.0 on pci0 > uhci0: [GIANT-LOCKED] > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub0: 2 ports with 2 removable, self powered > uhci1: port 0x7400-0x741f irq 17 at device 29.1 on pci0 > uhci1: [GIANT-LOCKED] > usb1: on uhci1 > usb1: USB revision 1.0 > uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub1: 2 ports with 2 removable, self powered > uhci2: port 0x7800-0x781f irq 18 at device 29.2 on pci0 > uhci2: [GIANT-LOCKED] > usb2: on uhci2 > usb2: USB revision 1.0 > uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub2: 2 ports with 2 removable, self powered > uhci3: port 0x8000-0x801f irq 19 at device 29.3 on pci0 > uhci3: [GIANT-LOCKED] > usb3: on uhci3 > usb3: USB revision 1.0 > uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub3: 2 ports with 2 removable, self powered > ehci0: mem 0xdddff800-0xdddffbff irq 20 at device 29.7 on pci0 > ehci0: [GIANT-LOCKED] > usb4: EHCI version 1.0 > usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 > usb4: on ehci0 > usb4: USB revision 2.0 > uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 > uhub4: 8 ports with 8 removable, self powered > pcib3: at device 30.0 on pci0 > pci1: on pcib3 > sio0: configured irq 21 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0: <3COM PCI FaxModem> port 0xa400-0xa407 irq 21 at device 0.0 on pci1 > sio0: moving to sio4 > sio4: type 16550A > puc0: port 0xa800-0xa81f irq 22 at device 1.0 on pci1 > sio5: on puc0 > sio5: type 16550A > sio6: on puc0 > sio6: type 16550A > pcm1: port 0xb000-0xb0ff irq 23 at device 2.0 on pci1 > pcm1: agg_rdcodec() RW_DONE timed out. > pcm1: will perform cold reset. > pcm1: agg_rdcodec() RW_DONE timed out. > pcm1: agg_rdcodec() RW_DONE timed out. > pcm1: agg_rdcodec() RW_DONE timed out. > pcm1: agg_rdcodec() RW_DONE timed out. > pcm1: agg_rdcodec() RW_DONE timed out. > pcm1: ac97 codec invalid or not present (id == ffffffff) > pcm1: mixer initialization failed! > device_attach: pcm1 attach returned 6 > atapci0: port 0xc800-0xc807,0xc400-0xc403,0xc000-0xc007,0xb800-0xb803,0xb400-0xb40f irq 19 at device 4.0 on pci1 > ata2: on atapci0 > ata3: on atapci0 > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 > ata0: on atapci1 > ata1: on atapci1 > atapci2: port 0x9800-0x9807,0x9400-0x9403,0x9000-0x9007,0x8800-0x8803,0x8400-0x840f mem 0xdddffc00-0xdddfffff irq 23 at device 31.2 on pci0 > ata4: on atapci2 > ata5: on atapci2 > pci0: at device 31.3 (no driver attached) > acpi_button0: on acpi0 > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 > fdc0: [FAST] > 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 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > can't re-use a leaf (%desc)! > can't re-use a leaf (%driver)! > can't re-use a leaf (%location)! > can't re-use a leaf (%pnpinfo)! > can't re-use a leaf (%parent)! > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > sio0: type 16550A > pmtimer0 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 > Timecounters tick every 1.000 msec > acd0: CDRW at ata0-master PIO4 > afd0: (no media) at ata0-slave PIO0 > ad4: 114473MB at ata2-master UDMA100 > pcm0: > pcm0: > SMP: AP CPU #1 Launched! > acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 > afd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 > cd0 at ata0 bus 0 target 0 lun 0 > cd0: Removable CD-ROM SCSI-0 device > cd0: 16.000MB/s transfers > cd0: cd present [452 x 2048 byte records] > da0 at ata0 bus 0 target 1 lun 0 > da0: Removable Direct Access SCSI-0 device > da0: 3.300MB/s transfers > da0: Attempt to query device size failed: NOT READY, Medium not present > Trying to mount root from ufs:/dev/ad4s2a -- http://www.velocityvector.com/ | http://www.classic-games.com/ I'd rather hunt with Dick Cheney than ride with Ted Kennedy. From owner-freebsd-stable@FreeBSD.ORG Sat Nov 24 04:20:39 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFBF016A419 for ; Sat, 24 Nov 2007 04:20:39 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with SMTP id 78FA813C457 for ; Sat, 24 Nov 2007 04:20:38 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 9225 invoked by uid 399); 24 Nov 2007 03:53:58 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTP; 24 Nov 2007 03:53:58 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <4747A054.5040308@FreeBSD.org> Date: Fri, 23 Nov 2007 19:53:56 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.9 (X11/20071119) MIME-Version: 1.0 To: =?UTF-8?B?6Z+T5a625qiZIEJpbGwgSGFja2Vy?= References: <47474F60.4080804@conducive.net> In-Reply-To: <47474F60.4080804@conducive.net> X-Enigmail-Version: 0.95.5 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: Re: Buildworld failures -6.3-PRE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2007 04:20:39 -0000 韓家標 Bill Hacker wrote: > Many such, > > Wearing out my csup welcome for 'RELENG_6'. > > Same or similar error when attempting to regress to 'RELENG_6_2' > : undefined reference to `__mb_sb_limit' > *** Error code 1 Have you cleaned out /usr/obj/ ? That's always the first place to start when you see problems of this type, especially in a -stable branch. You might also want to do 'cd /usr/src && make cleandir ; make cleandir' (yes, I meant to type it twice). hth, Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Sat Nov 24 04:23:47 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E389D16A417 for ; Sat, 24 Nov 2007 04:23:47 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with SMTP id A402E13C4CC for ; Sat, 24 Nov 2007 04:23:47 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 12288 invoked by uid 399); 24 Nov 2007 03:57:06 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTP; 24 Nov 2007 03:57:06 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <4747A110.9090805@FreeBSD.org> Date: Fri, 23 Nov 2007 19:57:04 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.9 (X11/20071119) MIME-Version: 1.0 To: Pete French References: In-Reply-To: X-Enigmail-Version: 0.95.5 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: Is it O.K. to use the 7.0 ports tree on 6.3 ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2007 04:23:48 -0000 Pete French wrote: > I have a set of machines running 7.0 and a set running 6.3 which I > would like to use the same ports on. I was under the impression that > there was only one ports tree, so is it safe to simply untar the > ports.tgz file from 7.0 on the 6.3 machines, rename INDEX-7 to INDEX-6 > and install away, or are there more subtle differences to tran the unwary ? You've already received the right advice about not renaming the INDEX, but I think it's also worth mentioning that untar'ing a static picture of the ports tree is of little practical value unless you never plan to update the base, and you never plan to update any ports on that machine. You're much better off starting with downloading the tree with csup, that way you can maintain it more easily down the road. Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Sat Nov 24 04:24:38 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17E0516A41B for ; Sat, 24 Nov 2007 04:24:38 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by mx1.freebsd.org (Postfix) with ESMTP id E924D13C468 for ; Sat, 24 Nov 2007 04:24:37 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so50495pyb for ; Fri, 23 Nov 2007 20:24:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=fHcm/S9bI7IxXKReLzLFYLLZTQBM2LwXtYV07ceIPaI=; b=si0OGQgHMITLXxDsgDLkIwYJPr3B5eHLJA3ABuidUVoXycqsJcEC6krPRrky0KZL6bpXe5U/ah291jY5ZAdPame1vKE0QFpVBEDIuZALgHnAOWxf2VL04DhbEB3wkejDIG7DhU159YJR1Z+bBCP1Zvv+sMMTVdPvqsivuklsp7s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Ly0HwQusUvgFU3OdFhM2rbjTWNGNcDJdv+HMCrNVkWedSw8sDt7lZl+1//1odiuKJSu3QTO7GRa+Q5prJzYIyNSen24IwYOZRu+23/e3PiYXJTIS3Haoil9ak/z0Y1S0O5kWOuPOSCUu7idbPDCP0ROB0EbQY7B1F8QeV7vy+vw= Received: by 10.65.54.9 with SMTP id g9mr190179qbk.1195878276840; Fri, 23 Nov 2007 20:24:36 -0800 (PST) Received: by 10.65.105.5 with HTTP; Fri, 23 Nov 2007 20:24:36 -0800 (PST) Message-ID: Date: Sat, 24 Nov 2007 04:24:36 +0000 From: "Aryeh Friedman" To: "Doug Barton" In-Reply-To: <4747A054.5040308@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <47474F60.4080804@conducive.net> <4747A054.5040308@FreeBSD.org> Cc: =?ISO-8859-1?Q?=E9U9FU93=E5=AE=B6=E6=A8U99_Bill_Hacker?= , freebsd-stable@freebsd.org Subject: Re: Buildworld failures -6.3-PRE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2007 04:24:38 -0000 On 11/24/07, Doug Barton wrote: > =B6 Bill Hacker wrote: > > Many such, > > > > Wearing out my csup welcome for 'RELENG_6'. > > > > Same or similar error when attempting to regress to 'RELENG_6_2' > > > : undefined reference to `__mb_sb_limit' > > *** Error code 1 > > Have you cleaned out /usr/obj/ ? That's always the first place to > start when you see problems of this type, especially in a -stable > branch. You might also want to do > 'cd /usr/src && make cleandir ; make cleandir' > (yes, I meant to type it twice). What wrong with rm -rf /usr/obj? From owner-freebsd-stable@FreeBSD.ORG Sat Nov 24 05:35:18 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B925F16A419; Sat, 24 Nov 2007 05:35:18 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id 3322E13C459; Sat, 24 Nov 2007 05:35:16 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id QAA07459; Sat, 24 Nov 2007 16:11:55 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 24 Nov 2007 16:11:54 +1100 (EST) From: Ian Smith To: Doug Barton In-Reply-To: <4747A110.9090805@FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: stable@freebsd.org, Pete French Subject: Re: Is it O.K. to use the 7.0 ports tree on 6.3 ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2007 05:35:18 -0000 On Fri, 23 Nov 2007, Doug Barton wrote: > Pete French wrote: > > I have a set of machines running 7.0 and a set running 6.3 which I > > would like to use the same ports on. I was under the impression that > > there was only one ports tree, so is it safe to simply untar the > > ports.tgz file from 7.0 on the 6.3 machines, rename INDEX-7 to INDEX-6 > > and install away, or are there more subtle differences to tran the unwary ? > > You've already received the right advice about not renaming the INDEX, > but I think it's also worth mentioning that untar'ing a static picture > of the ports tree is of little practical value unless you never plan > to update the base, and you never plan to update any ports on that > machine. > > You're much better off starting with downloading the tree with csup, > that way you can maintain it more easily down the road. Or you can just use 'portsnap fetch extract' and then for updates use 'portsnap fetch update'. This maintains the INDEX files according to your base system also; you don't need to use make fetchindex. Cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Sat Nov 24 06:27:59 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08C8E16A417 for ; Sat, 24 Nov 2007 06:27:59 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by mx1.freebsd.org (Postfix) with ESMTP id A1B9A13C44B for ; Sat, 24 Nov 2007 06:27:58 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail17.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lAO6Rjap014152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Nov 2007 17:27:56 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.1/8.14.1) with ESMTP id lAO6RjCn001122; Sat, 24 Nov 2007 17:27:45 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.1/8.14.1/Submit) id lAO6RjG2001121; Sat, 24 Nov 2007 17:27:45 +1100 (EST) (envelope-from peter) Date: Sat, 24 Nov 2007 17:27:44 +1100 From: Peter Jeremy To: Aryeh Friedman Message-ID: <20071124062744.GU50167@server.vk2pj.dyndns.org> References: <47474F60.4080804@conducive.net> <4747A054.5040308@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-stable@freebsd.org Subject: Re: Buildworld failures -6.3-PRE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2007 06:27:59 -0000 On Sat, Nov 24, 2007 at 04:24:36AM +0000, Aryeh Friedman wrote: >On 11/24/07, Doug Barton wrote: >> 'cd /usr/src && make cleandir ; make cleandir' >> (yes, I meant to type it twice). > >What wrong with rm -rf /usr/obj? That's similar to a single 'make cleandir', though it will also delete the kernel build count (the #nn in "uname -a"). Note that the second 'make cleandir' is still necessary in case any cruft has been created inside /usr/src. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. From owner-freebsd-stable@FreeBSD.ORG Sat Nov 24 12:25:33 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCFC916A418; Sat, 24 Nov 2007 12:25:33 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from angel.ticketswitch.com (angel.ticketswitch.com [IPv6:2002:57e0:1d4e::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9A43D13C458; Sat, 24 Nov 2007 12:25:33 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from smaug.rattatosk ([10.50.50.2]) by angel.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Ivu4i-000F51-Ga; Sat, 24 Nov 2007 12:25:32 +0000 Received: from dilbert.rattatosk ([10.50.50.6] helo=dilbert.ticketswitch.com) by smaug.rattatosk with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Ivu4i-000Gqe-Do; Sat, 24 Nov 2007 12:25:32 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ivu4i-0008Ur-DW; Sat, 24 Nov 2007 12:25:32 +0000 To: dougb@FreeBSD.org In-Reply-To: <4747A110.9090805@FreeBSD.org> Message-Id: From: Pete French Date: Sat, 24 Nov 2007 12:25:32 +0000 Cc: stable@freebsd.org Subject: Re: Is it O.K. to use the 7.0 ports tree on 6.3 ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2007 12:25:33 -0000 > You've already received the right advice about not renaming the INDEX, > but I think it's also worth mentioning that untar'ing a static picture > of the ports tree is of little practical value unless you never plan > to update the base, and you never plan to update any ports on that > machine. Sorrty, but I do not understand this at all. Surely untarring the ports file is exactly what the installer does when you install BSD onto a machine? Why is doing it by hand any different ? > You're much better off starting with downloading the tree with csup, > that way you can maintain it more easily down the road. Won't running csup on the tree I just untarred work ? I use csup (and have used cvsup in the past) to update ports trees on machines I installed from CD, and it works fine. Unless the installer is doing something other than simply untarring that file I can't see why it isn't just going to work in the same way. In this case the point is moot as I am not going to update the ports tree on these machines at all - this is a temporary measure until I wipe them and upgrade them to 7.0 when it is released. Have upgraded one to 7.0 already to tryit out (works really nicely) but I just wanted the rest of the machines in the fram to be running the same versions in the interim few weeks until I upgrade them all. Thanks for the advice though, if it really doesnt work then thats definitely worth knowing! Might to some experiments to verity that though - sorry for being scepticle, but I am sure I have done this in the past and it worked fine. cheers, -pete. From owner-freebsd-stable@FreeBSD.ORG Sat Nov 24 12:58:53 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 759E416A46D; Sat, 24 Nov 2007 12:58:53 +0000 (UTC) (envelope-from rsmith@xs4all.nl) Received: from smtp-vbr10.xs4all.nl (smtp-vbr10.xs4all.nl [194.109.24.30]) by mx1.freebsd.org (Postfix) with ESMTP id 2178B13C4EA; Sat, 24 Nov 2007 12:58:52 +0000 (UTC) (envelope-from rsmith@xs4all.nl) Received: from slackbox.xs4all.nl (slackbox.xs4all.nl [213.84.242.160]) by smtp-vbr10.xs4all.nl (8.13.8/8.13.8) with ESMTP id lAOCfPCg046228; Sat, 24 Nov 2007 13:41:25 +0100 (CET) (envelope-from rsmith@xs4all.nl) Received: by slackbox.xs4all.nl (Postfix, from userid 1001) id E8A7EB8F8; Sat, 24 Nov 2007 13:41:24 +0100 (CET) Date: Sat, 24 Nov 2007 13:41:24 +0100 From: Roland Smith To: Pete French Message-ID: <20071124124124.GB37199@slackbox.xs4all.nl> References: <4747A110.9090805@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Y7xTucakfITjPcLV" Content-Disposition: inline In-Reply-To: X-GPG-Fingerprint: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 X-GPG-Key: http://www.xs4all.nl/~rsmith/pubkey.txt X-GPG-Notice: If this message is not signed, don't assume I sent it! User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: by XS4ALL Virus Scanner Cc: stable@freebsd.org, dougb@freebsd.org Subject: Re: Is it O.K. to use the 7.0 ports tree on 6.3 ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2007 12:58:53 -0000 --Y7xTucakfITjPcLV Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 24, 2007 at 12:25:32PM +0000, Pete French wrote: > > You've already received the right advice about not renaming the INDEX, > > but I think it's also worth mentioning that untar'ing a static picture > > of the ports tree is of little practical value unless you never plan > > to update the base, and you never plan to update any ports on that > > machine. >=20 > Sorrty, but I do not understand this at all. Surely untarring the ports > file is exactly what the installer does when you install BSD onto a machi= ne? > Why is doing it by hand any different ? Not much. Some packages and a tarball of the ports tree are on the installation CD for convenience. If you have a fast internet connection, then don't bother installing stuff from the CD, because it's dated by the time you install it. Install the ports tree with portsnap, and then build the ports you want (or get the latest packages if you don't fancy compiling stuff). That way you'll get the latest ports. > > You're much better off starting with downloading the tree with csup, > > that way you can maintain it more easily down the road. >=20 > Won't running csup on the tree I just untarred work ? I use csup > (and have used cvsup in the past) to update ports trees on machines > I installed from CD, and it works fine. Unless the installer is doing > something other than simply untarring that file I can't see why it isn't > just going to work in the same way. For keeping the ports tree up-to-date, portsnap is generally faster. See =A74.5 of the Handbook on how to use it. Roland --=20 R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) --Y7xTucakfITjPcLV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHSBv0EnfvsMMhpyURAq0KAJ0aBhOdDGPnz4NOJjdHW+w8PyhibACdGql+ VH85UNs7IIVyPiudaWzyhds= =uVUh -----END PGP SIGNATURE----- --Y7xTucakfITjPcLV-- From owner-freebsd-stable@FreeBSD.ORG Sat Nov 24 13:17:50 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77C6616A41A; Sat, 24 Nov 2007 13:17:50 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id A812F13C442; Sat, 24 Nov 2007 13:17:49 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47482485.7030906@FreeBSD.org> Date: Sat, 24 Nov 2007 14:17:57 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Pete French References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, dougb@FreeBSD.org Subject: Re: Is it O.K. to use the 7.0 ports tree on 6.3 ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2007 13:17:50 -0000 Pete French wrote: >> You've already received the right advice about not renaming the INDEX, >> but I think it's also worth mentioning that untar'ing a static picture >> of the ports tree is of little practical value unless you never plan >> to update the base, and you never plan to update any ports on that >> machine. > > Sorrty, but I do not understand this at all. Surely untarring the ports > file is exactly what the installer does when you install BSD onto a machine? > Why is doing it by hand any different ? > >> You're much better off starting with downloading the tree with csup, >> that way you can maintain it more easily down the road. > > Won't running csup on the tree I just untarred work ? I use csup > (and have used cvsup in the past) to update ports trees on machines > I installed from CD, and it works fine. Unless the installer is doing > something other than simply untarring that file I can't see why it isn't > just going to work in the same way. Yes, it definitely will not work. When files are deleted from the ports tree after your initial tarball extraction, c[v]sup will not notice that they are missing (since it does not have a baseline), and will not remove them. Thus, you will encounter ports with "stale" patches that no longer apply, or apply but break the compilation, etc. There is a FAQ about this on the cvsup webpage on www.polstra.com that explains in detail. Kris From owner-freebsd-stable@FreeBSD.ORG Sat Nov 24 13:43:57 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from misaki (localhost [IPv6:::1]) by hub.freebsd.org (Postfix) with SMTP id 05F2B16A469; Sat, 24 Nov 2007 13:43:55 +0000 (UTC) (envelope-from ariff@FreeBSD.org) Date: Sat, 24 Nov 2007 21:43:13 +0800 From: Ariff Abdullah To: Greg Miller Message-Id: <20071124214313.73ef157b.ariff@FreeBSD.org> In-Reply-To: <47478A58.2000906@classic-games.com> References: <47478A58.2000906@classic-games.com> Organization: FreeBSD X-Mailer: /usr/local/lib/ruby/1.8/net/smtp.rb Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Sat__24_Nov_2007_21_43_13_+0800_y8MZ7n3nzV056Ouo" Cc: freebsd-stable@freebsd.org Subject: Re: Maestro 2E on 6.3-PRERELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2007 13:43:57 -0000 --Signature=_Sat__24_Nov_2007_21_43_13_+0800_y8MZ7n3nzV056Ouo Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 23 Nov 2007 20:20:08 -0600 Greg Miller wrote: >=20 > I have a Maestro 2E sound card that works perfectly on > 6.2-RELEASE-p8, but not on 6.3-PRERELEASE. Here's the dmesg: >=20 Could be something else (acpi? bus changes? etc). The sound driver stuffs virtually unchanged. [...] > > pcm1: port 0xb000-0xb0ff irq 23 at > > device 2.0 on pci1 pcm1: agg_rdcodec() RW_DONE timed out. > > pcm1: will perform cold reset. > > pcm1: agg_rdcodec() RW_DONE timed out. > > pcm1: agg_rdcodec() RW_DONE timed out. > > pcm1: agg_rdcodec() RW_DONE timed out. > > pcm1: agg_rdcodec() RW_DONE timed out. > > pcm1: agg_rdcodec() RW_DONE timed out. > > pcm1: ac97 codec invalid or not present (id =3D=3D ffffffff) > > pcm1: mixer initialization failed! > > device_attach: pcm1 attach returned 6 [...] > > pcm0: > > pcm0: Why not using this one? [...] > > SMP: AP CPU #1 Launched! > > acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=3D0x24 ascq=3D0x00=20 > > afd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=3D0x24 ascq=3D0x00=20 > > cd0 at ata0 bus 0 target 0 lun 0 > > cd0: Removable CD-ROM SCSI-0 > > device cd0: 16.000MB/s transfers > > cd0: cd present [452 x 2048 byte records] > > da0 at ata0 bus 0 target 1 lun 0 > > da0: Removable Direct Access SCSI-0 device=20 > > da0: 3.300MB/s transfers > > da0: Attempt to query device size failed: NOT READY, Medium not > > present Trying to mount root from ufs:/dev/ad4s2a >=20 >=20 -- Ariff Abdullah FreeBSD ... Recording in stereo is obviously too advanced and confusing for us idiot ***** users :P ........ --Signature=_Sat__24_Nov_2007_21_43_13_+0800_y8MZ7n3nzV056Ouo Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHSCpxlr+deMUwTNoRAiarAKC34Muw1oDQ6Bd5u/joHl+oGq+fnACgmIga 4o93jh4cQkqVqVenXIfZ8gU= =0zP4 -----END PGP SIGNATURE----- --Signature=_Sat__24_Nov_2007_21_43_13_+0800_y8MZ7n3nzV056Ouo-- From owner-freebsd-stable@FreeBSD.ORG Sat Nov 24 16:40:40 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D622E16A421; Sat, 24 Nov 2007 16:40:40 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from angel.ticketswitch.com (angel.ticketswitch.com [IPv6:2002:57e0:1d4e::1]) by mx1.freebsd.org (Postfix) with ESMTP id AD27A13C45B; Sat, 24 Nov 2007 16:40:40 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from smaug.rattatosk ([10.50.50.2]) by angel.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Ivy3c-000GSC-03; Sat, 24 Nov 2007 16:40:40 +0000 Received: from dilbert.rattatosk ([10.50.50.6] helo=dilbert.ticketswitch.com) by smaug.rattatosk with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Ivy3b-000Ie5-UC; Sat, 24 Nov 2007 16:40:39 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ivy3b-000Acq-Tn; Sat, 24 Nov 2007 16:40:39 +0000 To: kris@FreeBSD.org In-Reply-To: <47482485.7030906@FreeBSD.org> Message-Id: From: Pete French Date: Sat, 24 Nov 2007 16:40:39 +0000 Cc: stable@freebsd.org, dougb@FreeBSD.org Subject: Re: Is it O.K. to use the 7.0 ports tree on 6.3 ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2007 16:40:40 -0000 > Yes, it definitely will not work. When files are deleted from the ports > tree after your initial tarball extraction, c[v]sup will not notice that > they are missing (since it does not have a baseline), and will not > remove them. Thus, you will encounter ports with "stale" patches that > no longer apply, or apply but break the compilation, etc. Ahhh, right. So preseuably an install off the CD does something to give csup a baseline which I am missing (or is csupping the ports on a tree installed as part of the install process a bad idea too?). > There is a FAQ about this on the cvsup webpage on www.polstra.com that > explains in detail. Thanks, will take a look. Learn something new every day I guess! :) -pete. From owner-freebsd-stable@FreeBSD.ORG Sat Nov 24 16:48:13 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4ED1A16A41A; Sat, 24 Nov 2007 16:48:13 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id C4C1D13C458; Sat, 24 Nov 2007 16:48:11 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <474855D3.8080709@FreeBSD.org> Date: Sat, 24 Nov 2007 17:48:19 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Pete French References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, dougb@FreeBSD.org Subject: Re: Is it O.K. to use the 7.0 ports tree on 6.3 ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2007 16:48:13 -0000 Pete French wrote: >> Yes, it definitely will not work. When files are deleted from the ports >> tree after your initial tarball extraction, c[v]sup will not notice that >> they are missing (since it does not have a baseline), and will not >> remove them. Thus, you will encounter ports with "stale" patches that >> no longer apply, or apply but break the compilation, etc. > > Ahhh, right. So preseuably an install off the CD does something to > give csup a baseline which I am missing (or is csupping the ports on > a tree installed as part of the install process a bad idea too?). The latter. It would be a nice idea to try and improve this. Kris >> There is a FAQ about this on the cvsup webpage on www.polstra.com that >> explains in detail. > > Thanks, will take a look. Learn something new every day I guess! :) > > -pete. > >