From owner-freebsd-stable@FreeBSD.ORG Sun Jan 31 01:06:27 2010 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 BB1A81065750; Sun, 31 Jan 2010 01:06:27 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail15.syd.optusnet.com.au (mail15.syd.optusnet.com.au [211.29.132.196]) by mx1.freebsd.org (Postfix) with ESMTP id BC6048FC19; Sun, 31 Jan 2010 01:06:26 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c122-106-232-148.belrs3.nsw.optusnet.com.au [122.106.232.148]) by mail15.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o0V16Jj8013115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 31 Jan 2010 12:06:20 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id o0V16IbU002112; Sun, 31 Jan 2010 12:06:18 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id o0V16IaS002111; Sun, 31 Jan 2010 12:06:18 +1100 (EST) (envelope-from peter) Date: Sun, 31 Jan 2010 12:06:18 +1100 From: Peter Jeremy To: Marius Strobl Message-ID: <20100131010618.GA1864@server.vk2pj.dyndns.org> References: <20100126073336.GA1955@server.vk2pj.dyndns.org> <201001260946.44977.jhb@freebsd.org> <20100126183756.GA40779@alchemy.franken.de> <201001261510.59667.jhb@freebsd.org> <20100127063649.GA1889@server.vk2pj.dyndns.org> <20100127115229.GD40779@alchemy.franken.de> 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: <20100127115229.GD40779@alchemy.franken.de> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: rmacklem@freebsd.org, dfr@freebsd.org, freebsd-stable@freebsd.org, John Baldwin Subject: Re: uma_zalloc_arg complaining about non-sleepable locks 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, 31 Jan 2010 01:06:27 -0000 --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Sorry for the delay, I was trying to avoid rebooting my server. I've setup a similar environment in VirtualBox to test it. On 2010-Jan-27 12:52:29 +0100, Marius Strobl wr= ote: >Ah, I forgot that using nfsm_aligned() causes nfs_realign() to >be a NOP on architectures without strict alignment requirements >for performance reasons. That's generally fine but unfortunately >that way you don't actually exercise the code which caused the >problem before (unfortunately I still don't manage to hit the >unaligned case myself). >Could you please test with #ifdef __NO_STRICT_ALIGNMENT replaced >with #if 0 in sys/nfs/nfs_common.h? The vfs.nfs.realign_count >counter should also increase then. I'm not sure what triggers the unaligned case either - I tried roughly "tar -cf - -C /mnt/usr src | tar -xf - -C /mnt/tmp" and that caused some unaligned accesses (but also completely wedged the VBox host). I also tried copying a pile of files off my NFS client (FreeBSD-8.x/i386) and that also triggered some unaligned accesses without any errors being reported. Currently, I have: vfs.nfs.realign_count: 12 vfs.nfs.realign_test: 188817 I'd say that your patch works. --=20 Peter Jeremy --tThc/1wpZn/ma/RB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAktk14oACgkQ/opHv/APuIeisgCePxY3sndE6CGY8tE4mczcl/h6 GhwAn2JbZL6GMfbgMmksUrCuASTaFbRW =1AQN -----END PGP SIGNATURE----- --tThc/1wpZn/ma/RB-- From owner-freebsd-stable@FreeBSD.ORG Sun Jan 31 02:05:40 2010 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 3DE84106566B; Sun, 31 Jan 2010 02:05:40 +0000 (UTC) (envelope-from freebsd@insightbb.com) Received: from mxsf14.insightbb.com (mxsf14.insightbb.com [74.128.0.96]) by mx1.freebsd.org (Postfix) with ESMTP id EA90B8FC13; Sun, 31 Jan 2010 02:05:39 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.49,376,1262581200"; d="scan'208";a="28345812" Received: from unknown (HELO asav01.insightbb.com) ([172.31.249.123]) by mxsf14.insightbb.com with ESMTP; 30 Jan 2010 21:05:37 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMEAOhzZEvQLicL/2dsb2JhbACBM9cQgkWCAAQ X-IronPort-AV: E=Sophos;i="4.49,376,1262581200"; d="scan'208";a="243416846" Received: from 208-46-39-11.dia.static.qwest.net (HELO laptop2.stevenfriedrich.org) ([208.46.39.11]) by asavout01.insightbb.com with ESMTP; 30 Jan 2010 21:05:37 -0500 From: Steven Friedrich To: freebsd-stable@freebsd.org Date: Sat, 30 Jan 2010 21:05:30 -0500 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; i386; ; ) References: <1264864993.00213457.1264853403@10.7.7.3> <4B64587F.7050701@FreeBSD.org> In-Reply-To: <4B64587F.7050701@FreeBSD.org> X-Face: i~b2iK'Z*tJ)pO9@6lJG=k7>N, V~YMq":Iwdl!m|A"g, N@)'|zb[{ Cc: Alexander Motin Subject: Re: loading module sdhci causes panic 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, 31 Jan 2010 02:05:40 -0000 On Saturday 30 January 2010 11:04:15 am Alexander Motin wrote: > Steven Friedrich wrote: > > I stopped the boot before the timer expired, after it had loaded modules > > specified in /boot/loader.conf > > > > I loaded mmc, mmcsd, and sdhci. > > > > I continued the boot, and it panic'ed right after apic. > > > > I rebooted everal times, to load each individually, to narrow it down to > > sdhci. > > > > Can anyone verify that sdhci is compatible with FreeBSD 8? > > > > I updated and built today. > > I am using it daily since written it and till present 9-CURRENT. Show > your verbose boot messages and crash information. > I updated source and built world and kernel today. My machine won't complete a dump and reboot. I'll work on that, but the below text is from a successful boot, and I show where the panic occurred. I don't build all modules, but I added mmc, mmcsd, and sdhci to the var in make.conf. When this all began, I had built the modules and loaded them by hand. There was no panic, so I added them to /boot/loader.conf and then it panic'ed. I've also made it panic by stopping the boot and hand-loading the three modules. I haven't built these into a kernel... Copyright (c) 1992-2010 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 8.0-STABLE #31: Sat Jan 30 16:19:51 EST 2010 admin@laptop2.StevenFriedrich.org:/usr/obj/usr/src/sys/LAPTOP i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2793.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 Features=0xbfebfbff Features2=0x641d AMD Features=0x20100000 TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 2094256128 (1997 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 1 core(s) x 2 HTT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 1 ioapic0 irqs 0-23 on motherboard Here, it reported a trap 12 page fault while in Kernel mode fault code supervisor read, page not present The next line would have been: video4bsd: /dev/video0..9, /dev/video_daemon0..9 Here's a snip from the original topic and a response: On Friday 29 January 2010 23:14:06 Steven Friedrich wrote: > I'd like to access the digital media slots on my laptop. > > Specifically, I want to read Sony Memory Sticks. > > pciconf -lv shows the devices: > > none2@pci0:11:0:3: class=0x018000 card=0x3082103c chip=0x8033104c rev=0x00 > hdr=0x00 > vendor = 'Texas Instruments (TI)' > device = 'PCIxx11/21 Integrated FlashMedia Controller' > class = mass storage > none3@pci0:11:0:4: class=0x080500 card=0x3082103c chip=0x8034104c rev=0x00 > hdr=0x00 > vendor = 'Texas Instruments (TI)' > device = 'SDA Standard Compliant SD Host Controller (10981734)' > class = base peripheral > subclass = SD host controller Probably supported by sdhci(4). I don't know which of the two controllers supports Sony Memory Sticks, but I figured I'd get the drivers installed and try it. From owner-freebsd-stable@FreeBSD.ORG Sun Jan 31 02:44:57 2010 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 0E5D41065672 for ; Sun, 31 Jan 2010 02:44:57 +0000 (UTC) (envelope-from kensmith@buffalo.edu) Received: from localmailA.acsu.buffalo.edu (localmailA.acsu.buffalo.edu [128.205.5.196]) by mx1.freebsd.org (Postfix) with ESMTP id D1BB48FC1B for ; Sun, 31 Jan 2010 02:44:56 +0000 (UTC) Received: from localmailA.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 115B9B064; Sat, 30 Jan 2010 21:44:56 -0500 (EST) Received: from localmailA.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailA.acsu.buffalo.edu (Postfix) with ESMTP id 7605EB068; Sat, 30 Jan 2010 21:44:54 -0500 (EST) Received: from mweb2.acsu.buffalo.edu (mweb2.acsu.buffalo.edu [128.205.5.239]) by localmailA.acsu.buffalo.edu (Prefixe) with ESMTP id 6FE9FB064; Sat, 30 Jan 2010 21:44:54 -0500 (EST) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) by mweb2.acsu.buffalo.edu (Postfix) with ESMTP id 4D8BE207B6; Sat, 30 Jan 2010 21:44:54 -0500 (EST) From: Ken Smith To: Ian Smith In-Reply-To: <20100130164546.K46992@sola.nimnet.asn.au> References: <1264828108.4948.18.camel@neo.cse.buffalo.edu> <20100130164546.K46992@sola.nimnet.asn.au> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-d3V5gKSIdttV26ZhEn4O" Date: Sat, 30 Jan 2010 21:44:53 -0500 Message-Id: <1264905893.19953.23.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-PM-EL-Spam-Prob: : 8% Cc: freebsd-stable Subject: Re: 7.3-BETA1 Available... [memstick.img?] 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, 31 Jan 2010 02:44:57 -0000 --=-d3V5gKSIdttV26ZhEn4O Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2010-01-30 at 17:17 +1100, Ian Smith wrote: > are there any plans afoot to release memstick.img/s for 7.3-R? >=20 > If so, where should I look for information on how it may be done? >=20 > If not, is there something about RELENG_7 precluding that? USB stack? No, no plans afoot for memsticks for the balance of the 7.X releases. The sysinstall support for installing from a USB based disk didn't get MFCed to stable/7. Even if it was we're already something of a heavyweight on images (both CDs-with-packages and DVD) so my plan all along had been to phase in the memstick image for stable/8 and at the same time drop CDs-with-packages. > My search for information on the particular recipe/s used to make the=20 > 8.0-R memstick images has proven fruitless so far, despite several=20 > useful suggestions on ways to make various other sorts of bootable USB=20 > stick images. So far they seem to have been made out-of-band, somehow? >=20 > My particular interest is in putting DVD release/s onto a 4GB(+) stick,=20 > hopefully on bootable slices rather than 'dangerously dedicated' form. I was more or less experimenting with the memsticks for 8.0 and never quite got around to packaging up what I do into a script. I'll try to get something along those lines into the tree some time soon. Release builds are done in two passes - the first pass creates all the directories needed but stops there giving me a chance to add stuff to those directories. That's where I put the packages into place if there are going to be any. After doing that the second pass runs which builds the ISO images. After the first pass I briefly put the packages directory that is supposed to be on disc1 (which is just the docs packages, sysinstall gets grumpy if those aren't present) into the dvd1 directory and do this: makefs foo.fs dvd1 dd if=3D/dev/zero of=3D8.0-RELEASE-amd64-memstick.img \ bs=3D10240 count=3D mdconfig -a -t vnode -f 8.0-RELEASE-amd64-memstick.img fdisk -BIq /dev/md0 bsdlabel -B -w /dev/md0 dd if=3Dfoo.fs of=3D/dev/md0a bs=3D10240 conv=3Dsync mdconfig -d -u 0 The number should be calculated to be two blocks larger than the size of foo.fs so you've got room for round-up error and enough space for the label. After doing that I put the packages directory I'd used where it's supposed to be (disc1), put the proper set of packages for the DVD into the dvd1 directory, and then run the second pass of the release build to generate the ISO images. --=20 Ken Smith - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-d3V5gKSIdttV26ZhEn4O Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAktk7qUACgkQ/G14VSmup/b3xgCgjdr2341EB1mQkoBD1JJEapXh 7kUAni/wvjuiiCJFN6bh/CYNCNrOvsV7 =qcSe -----END PGP SIGNATURE----- --=-d3V5gKSIdttV26ZhEn4O-- From owner-freebsd-stable@FreeBSD.ORG Sun Jan 31 03:49:27 2010 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 8306C1065670 for ; Sun, 31 Jan 2010 03:49:27 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gx0-f212.google.com (mail-gx0-f212.google.com [209.85.217.212]) by mx1.freebsd.org (Postfix) with ESMTP id 35F1D8FC1A for ; Sun, 31 Jan 2010 03:49:26 +0000 (UTC) Received: by gxk4 with SMTP id 4so2780055gxk.13 for ; Sat, 30 Jan 2010 19:49:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=b0AVvHgQQTUDVq20waZ5p/WHqlGCEV/ZUx7AUGBk/Zg=; b=HkUA3jp8yIuGsZgdDOzgg2UtBDx7GkXjH/ljAaUAZYFvOYXFByilhumSrekSlwyk+n 8cgArd1riO2jaKtXEfUQmur9O/sCggRdLF6cOMdqbEJfUNaTtN5auYkhFk81e13B3kRd TjROgL+JSCe8LFYiuaMWeABWHjFP/S9Agob2Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=YQA87WMxo5a7eGiBmtu25oFJDuhXZjHBgcEAKT17kxbHVdQfHxjQm3q5iBcaMDbRID VHjlD/9hM8V+nr1N1DoMZStlkBnSaFt7G1b0gdurLZl6onmfEn3eBmYKhA0ELD6/3IV4 v7F2rjNvA4KV2n8FmnP7GK7HJdKzzIDrvSPkc= Received: by 10.91.42.39 with SMTP id u39mr2565707agj.26.1264909764562; Sat, 30 Jan 2010 19:49:24 -0800 (PST) Received: from centel.dataix.local (ppp-21.129.dialinfree.com [209.172.21.129]) by mx.google.com with ESMTPS id 22sm1241436yxe.39.2010.01.30.19.49.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 30 Jan 2010 19:49:23 -0800 (PST) Sender: "J. Hellenthal" Date: Sat, 30 Jan 2010 22:49:19 -0500 From: jhell To: Antony Mawer In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: stable@freebsd.org Subject: Re: [patch] New splash_txt module - support for ASCII splash(4) boot screens 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, 31 Jan 2010 03:49:27 -0000 On Fri, 29 Jan 2010 10:37, lists@ wrote: > Hi all, > > I recently dusted off an old patch I put together years ago which adds > a new splash_txt decoder module for the splash(4) boot splash screen. > The module allows you to use a binary-format ASCII drawing (80x25) as > a boot splash screen rather than the graphical modes offered by > splash_bmp and splash_pcx. We have been and still are using it, but I > finally got around to adding the relevant changes to the splash(4) man > page and putting together some examples for wider testing. If it seems > of use to others it would be nice if someone would be interested in > committing it at some stage. > > In case the list eats the patch, you can grab a copy of it here: > > http://www.mawer.org/freebsd/splash_txt.patch > > To give you an idea of what it looks like, here is a screenshot of a > quick generic FreeBSD splash screen I put together: > > http://www.mawer.org/freebsd/splash_txt.png > > If you'd like to try it for yourself then the process to build it > should be something like this: > > 1. Download the attached patch > 2. Create the required folders before applying the patch -- cd > /usr/src && mkdir sys/modules/splash/txt > 3. Apply the patch -- patch < splash_txt.patch > 4. Build the module -- cd sys/modules/splash/txt && make && make install > > Once that's completed, you can configure it by adding the following to > loader.conf: > > splash_txt_load="YES" > bitmap_load="YES" > bitmap_name="/boot/freebsd.bin" > > I have uploaded a sample boot splash screen at > http://www.mawer.org/freebsd/freebsd.bin . The files can be produced > using TheDraw and saving in its Binary file format, which consists of > a sequence of 2 byte pairs. The first byte in a pair is the character > to draw on the screen, and the second is the colour/display attributes > to draw the character with. > > If anyone else would like to try this out and has any feedback, or if > someone thinks it may be of interest to integrate into the tree please > let me know ... > > -- Antony > If this was a vote I would have to vote YES! Very cool contribution! -- jhell From owner-freebsd-stable@FreeBSD.ORG Sun Jan 31 04:36:45 2010 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 1EAE5106566B for ; Sun, 31 Jan 2010 04:36:45 +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 91B988FC12 for ; Sun, 31 Jan 2010 04:36:44 +0000 (UTC) Received: from inchoate.gsoft.com.au (ppp121-45-156-252.lns6.adl6.internode.on.net [121.45.156.252]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id o0V4ab0S084267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 31 Jan 2010 15:06:37 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Sun, 31 Jan 2010 15:06:17 +1030 User-Agent: KMail/1.9.10 References: <1264828108.4948.18.camel@neo.cse.buffalo.edu> <20100130164546.K46992@sola.nimnet.asn.au> <1264905893.19953.23.camel@bauer.cse.buffalo.edu> In-Reply-To: <1264905893.19953.23.camel@bauer.cse.buffalo.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4635696.WB4jkQphGq"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201001311506.32184.doconnor@gsoft.com.au> X-Spam-Score: -1.707 () AWL,BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Ian Smith , Ken Smith Subject: Re: 7.3-BETA1 Available... [memstick.img?] 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, 31 Jan 2010 04:36:45 -0000 --nextPart4635696.WB4jkQphGq Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sun, 31 Jan 2010, Ken Smith wrote: > No, no plans afoot for memsticks for the balance of the 7.X releases. > The sysinstall support for installing from a USB based disk didn't > get MFCed to stable/7. =C2=A0Even if it was we're already something of a > heavyweight on images (both CDs-with-packages and DVD) so my plan all > along had been to phase in the memstick image for stable/8 and at the > same time drop CDs-with-packages. =46WIW the method I used works on 7.x because sysinstall understands how=20 to read the install off a DOS device :) =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 --nextPart4635696.WB4jkQphGq Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLZQjQ5ZPcIHs/zowRAmPMAKCnss4RvwoVR9eY7k+tmwZ5EFk5lACffd04 pnIegu1xp+uM68wns3LrPck= =Eht0 -----END PGP SIGNATURE----- --nextPart4635696.WB4jkQphGq-- From owner-freebsd-stable@FreeBSD.ORG Sun Jan 31 08:37:44 2010 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 DD54D106566B for ; Sun, 31 Jan 2010 08:37:44 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id 80D298FC12 for ; Sun, 31 Jan 2010 08:37:44 +0000 (UTC) Received: by pxi13 with SMTP id 13so1624002pxi.3 for ; Sun, 31 Jan 2010 00:37:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=aX2tDxWemNcEPWQLveTqI+llMwFhPExm2aOfdCJ6rfc=; b=EKhYQHLhGljyxLA3/F/dz0wdU3vZJqQTyMhg24+NxyqaTZaVTuHlyOTyu6uJT9U+fc d/UeRQa3MY/J/NpqGCPpeHVUjSEnkhnYDGoz5LH4eaLsl3q2Qq9mrrPNXapGVTFJRdGx JuMLdH7xrKn2ElSsEgINPG2LaAkFTFr6GLduc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=T+BSJs6W2SHeDHHnVh0w/5kD1yz/mUaI8hfaMVupKBW9vLugaivQpgHcUtCG+51Sb8 fW1TJgxxVBcKET2KU7P18F72eL9dCjPVVbMxLpSajzpLHcGYkDk3XhPrB7ElxDjdIADX pKUs1ADJJsgEpBrvXsho2qlq4Wlj8eFdXdIJQ= MIME-Version: 1.0 Received: by 10.142.9.27 with SMTP id 27mr2048191wfi.241.1264927063995; Sun, 31 Jan 2010 00:37:43 -0800 (PST) Date: Sun, 31 Jan 2010 00:37:43 -0800 Message-ID: <147432021001310037n1b67f01bx4b4e8781321cea8@mail.gmail.com> From: Nick Rogers To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: em(4) + ALTQ broken 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, 31 Jan 2010 08:37:44 -0000 I'm having problems getting PF + ALTQ to work on em(4) interfaces under 8.0-RELEASE. Kernel was rebuilt with the additional options necessary for ALTQ and what not. Same basic configuration works fine under 7.2-RELEASE. Basically, the queues create successfully but running a pfctl -vsq shows a zero packet/byte count for all queues, even the interface's root queues. This same problem is mentioned in PR kern/138392, and the following forum thread... http://forums.freebsd.org/showthread.php?t=6656 em(4)/e1000 driver from CURRENT does not fix the problem. Building an 8.0-RELEASE kernel with the em(4) driver from 7.2-RELEASE fixes the problem (i.e., replacing sys/dev/e1000 with that from 7.2). One of the machines im experiencing this on has the following intel chipset... [user@foo ~]$ sysctl dev.em.0 dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 6.9.6 dev.em.0.%driver: em dev.em.0.%location: slot=0 function=0 dev.em.0.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x15d9 subdevice=0x040d class=0x020000 dev.em.0.%parent: pci3 dev.em.0.debug: -1 dev.em.0.stats: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: 100 Is this issue receiving any attention? I ask because one of the em(4) driver contributors mentioned he had not heard of this problem in a recent thread regarding a different em(4) bug, and this is a pretty serious problem for me as I have many devices in production that need to be upgraded to 8.0, all running Intel interfaces and relying on ALTQ. I appreciate any updates or information and would be happy to test any patches and/or provide more information. Thanks. From owner-freebsd-stable@FreeBSD.ORG Sun Jan 31 13:42:19 2010 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 04A671065672 for ; Sun, 31 Jan 2010 13:42:19 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.freebsd.org (Postfix) with ESMTP id 8A1808FC28 for ; Sun, 31 Jan 2010 13:42:18 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KX4006JP62H5250@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Sun, 31 Jan 2010 14:42:17 +0100 (CET) Received: from kg-v2.kg4.no ([80.203.92.186]) by bgo1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KX400LWW62HGHF0@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Sun, 31 Jan 2010 14:42:17 +0100 (CET) Date: Sun, 31 Jan 2010 14:42:17 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20100131144217.ca08e965.torfinn.ingolfsen@broadpark.no> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.6; amd64-portbld-freebsd8.0) 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: panic - sleeping thread on FreeBSD 8.0-stable / amd64 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, 31 Jan 2010 13:42:19 -0000 Hi, One of my machines had a panic or something. The machine was pingable, but I couldn't ssh into it, and there was no response on the console. On the console was these lines: "Sleeping thread (tid 10014, pid 0) owns a non-sleepable lock" "panic: sleeping thread" "cpuid = 1" The only thing I did with the machine yesterday (before this happened) was to upgrade the machine froms zfs v13 to v14. But that went well, no problems. root@kg-f2# last | head -6 tingo pts/1 kg-v2.kg4.no Sun Jan 31 14:26 still logged in tingo pts/0 kg-v2.kg4.no Sun Jan 31 14:26 still logged in root ttyv0 Sun Jan 31 14:25 still logged in reboot ~ Sun Jan 31 14:25 reboot ~ Sat Jan 30 17:48 reboot ~ Sat Jan 30 17:31 The two reboots yesterday is from the zfs upgrade. Since I couldn't do anything useful with it, I just turned off the power and rebooted it. The machine runs FreeBSD 8,0 stable and zfs: root@kg-f2# uname -a FreeBSD kg-f2.kg4.no 8.0-STABLE FreeBSD 8.0-STABLE #1: Fri Jan 15 16:43:49 CET 2010 root@kg-f2.kg4.no:/usr/obj/usr/src/sys/GENERIC amd64 It will be a file server, nut is mostly idle now (I haven't started using it yet). Details on the hardware: http://sites.google.com/site/tingox/ga-ma74gm-s2h dmesgs and more on the FreeBSD page for this machine: http://sites.google.com/site/tingox/ga-ma74gm-s2h_freebsd HTH -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Sun Jan 31 16:28:58 2010 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 BC7461065694; Sun, 31 Jan 2010 16:28:58 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 2AF848FC14; Sun, 31 Jan 2010 16:28:57 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id o0VGSsBD009963; Sun, 31 Jan 2010 17:28:54 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id o0VGSsoE009962; Sun, 31 Jan 2010 17:28:54 +0100 (CET) (envelope-from marius) Date: Sun, 31 Jan 2010 17:28:54 +0100 From: Marius Strobl To: John Baldwin Message-ID: <20100131162854.GC77522@alchemy.franken.de> References: <20100126073336.GA1955@server.vk2pj.dyndns.org> <201001260946.44977.jhb@freebsd.org> <20100126183756.GA40779@alchemy.franken.de> <201001261510.59667.jhb@freebsd.org> <20100127063649.GA1889@server.vk2pj.dyndns.org> <20100127115229.GD40779@alchemy.franken.de> <20100131010618.GA1864@server.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100131010618.GA1864@server.vk2pj.dyndns.org> User-Agent: Mutt/1.4.2.3i Cc: rmacklem@freebsd.org, dfr@freebsd.org, freebsd-stable@freebsd.org, Peter Jeremy Subject: Re: uma_zalloc_arg complaining about non-sleepable locks 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, 31 Jan 2010 16:28:58 -0000 On Sun, Jan 31, 2010 at 12:06:18PM +1100, Peter Jeremy wrote: > Sorry for the delay, I was trying to avoid rebooting my server. > I've setup a similar environment in VirtualBox to test it. > > On 2010-Jan-27 12:52:29 +0100, Marius Strobl wrote: > >Ah, I forgot that using nfsm_aligned() causes nfs_realign() to > >be a NOP on architectures without strict alignment requirements > >for performance reasons. That's generally fine but unfortunately > >that way you don't actually exercise the code which caused the > >problem before (unfortunately I still don't manage to hit the > >unaligned case myself). > > >Could you please test with #ifdef __NO_STRICT_ALIGNMENT replaced > >with #if 0 in sys/nfs/nfs_common.h? The vfs.nfs.realign_count > >counter should also increase then. > > I'm not sure what triggers the unaligned case either - I tried > roughly "tar -cf - -C /mnt/usr src | tar -xf - -C /mnt/tmp" and > that caused some unaligned accesses (but also completely wedged > the VBox host). I also tried copying a pile of files off my > NFS client (FreeBSD-8.x/i386) and that also triggered some > unaligned accesses without any errors being reported. > > Currently, I have: > vfs.nfs.realign_count: 12 > vfs.nfs.realign_test: 188817 > > I'd say that your patch works. John, are you okay with that patch? http://people.freebsd.org/~marius/fha_extract_info_realign2.diff It's intention is to: - Move nfs_realign() from the NFS client to the shared NFS code and remove the NFS server version in order to reduce code duplication. The shared version now uses a second parameter how, which is passed on to m_get(9) and m_getcl(9) as the server used M_WAIT while the client requires M_DONTWAIT, and replaces the the previously unused parameter hsiz. - Change nfs_realign() to use nfsm_aligned() so as with other NFS code the alignment check isn't actually performed on platforms without strict alignment requirements for performance reasons because as the comment suggests only occasionally occurs with TCP. - Change fha_extract_info() to use nfs_realign() with M_NOWAIT rather than M_DONTWAIT because it's called with the RPC sp_lock held. The only downside of the shared nfs_realign() are the combined SYSCTL counters but the fact we incremented them non-atomically so far I think already indicates that their intention only is a rough indication rather than exact values for client and server. Marius From owner-freebsd-stable@FreeBSD.ORG Sun Jan 31 16:56:42 2010 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 553BA1065670 for ; Sun, 31 Jan 2010 16:56:42 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.freebsd.org (Postfix) with ESMTP id 1296E8FC19 for ; Sun, 31 Jan 2010 16:56:41 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KX400F0XF2F4IA0@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Sun, 31 Jan 2010 17:56:39 +0100 (CET) Received: from kg-v2.kg4.no ([80.203.92.186]) by bgo1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KX400CFZF2FI370@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Sun, 31 Jan 2010 17:56:39 +0100 (CET) Date: Sun, 31 Jan 2010 17:56:39 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20100131175639.86ba9aee.torfinn.ingolfsen@broadpark.no> In-reply-to: <20100131144217.ca08e965.torfinn.ingolfsen@broadpark.no> References: <20100131144217.ca08e965.torfinn.ingolfsen@broadpark.no> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.6; amd64-portbld-freebsd8.0) 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: Re: panic - sleeping thread on FreeBSD 8.0-stable / amd64 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, 31 Jan 2010 16:56:42 -0000 On Sun, 31 Jan 2010 14:42:17 +0100 Torfinn Ingolfsen wrote: > Hi, > > One of my machines had a panic or something. > The machine was pingable, but I couldn't ssh into it, and there was no response on the console. > And it did it again, only a few hours later. I'll try to update to latest -stable, and see if that helps. Same messgae as last time, unfortunately I didn't record tge details (tid and pid). Oh well. -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Sun Jan 31 17:01:16 2010 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 6C4601065676 for ; Sun, 31 Jan 2010 17:01:16 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id C1F6D8FC24 for ; Sun, 31 Jan 2010 17:01:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o0VGxs9G070246; Mon, 1 Feb 2010 03:59:54 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 1 Feb 2010 03:59:54 +1100 (EST) From: Ian Smith To: Ken Smith In-Reply-To: <1264905893.19953.23.camel@bauer.cse.buffalo.edu> Message-ID: <20100201022642.G46992@sola.nimnet.asn.au> References: <1264828108.4948.18.camel@neo.cse.buffalo.edu> <20100130164546.K46992@sola.nimnet.asn.au> <1264905893.19953.23.camel@bauer.cse.buffalo.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-stable Subject: Re: 7.3-BETA1 Available... [memstick.img?] 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, 31 Jan 2010 17:01:16 -0000 On Sat, 30 Jan 2010, Ken Smith wrote: > On Sat, 2010-01-30 at 17:17 +1100, Ian Smith wrote: > > > are there any plans afoot to release memstick.img/s for 7.3-R? > > > > If so, where should I look for information on how it may be done? > > > > If not, is there something about RELENG_7 precluding that? USB stack? > > No, no plans afoot for memsticks for the balance of the 7.X releases. > The sysinstall support for installing from a USB based disk didn't get > MFCed to stable/7. Even if it was we're already something of a > heavyweight on images (both CDs-with-packages and DVD) so my plan all > along had been to phase in the memstick image for stable/8 and at the > same time drop CDs-with-packages. Ah, fair enough. So maybe a DVD-sized memstick.img for 8.1? :) > > My search for information on the particular recipe/s used to make the > > 8.0-R memstick images has proven fruitless so far, despite several > > useful suggestions on ways to make various other sorts of bootable USB > > stick images. So far they seem to have been made out-of-band, somehow? > > > > My particular interest is in putting DVD release/s onto a 4GB(+) stick, > > hopefully on bootable slices rather than 'dangerously dedicated' form. > > I was more or less experimenting with the memsticks for 8.0 and never > quite got around to packaging up what I do into a script. I'll try to > get something along those lines into the tree some time soon. Release > builds are done in two passes - the first pass creates all the > directories needed but stops there giving me a chance to add stuff to > those directories. That's where I put the packages into place if there > are going to be any. After doing that the second pass runs which builds > the ISO images. After the first pass I briefly put the packages > directory that is supposed to be on disc1 (which is just the docs > packages, sysinstall gets grumpy if those aren't present) into the dvd1 > directory and do this: And /fixit too, I gather? Cool, I wondered how that mix was setup. > makefs foo.fs dvd1 > dd if=/dev/zero of=8.0-RELEASE-amd64-memstick.img \ > bs=10240 count= > mdconfig -a -t vnode -f 8.0-RELEASE-amd64-memstick.img > fdisk -BIq /dev/md0 > bsdlabel -B -w /dev/md0 > dd if=foo.fs of=/dev/md0a bs=10240 conv=sync > mdconfig -d -u 0 > > The number should be calculated to be two blocks larger than the > size of foo.fs so you've got room for round-up error and enough space > for the label. Thanks! Last night I manually worked through Luigi's make_freebsd_image() from http://info.iet.unipi.it/~luigi/FreeBSD/20081204-iso2flash on my 7.2-S of a few weeks ago, which is different: no fdisk, bsdlabel munging and later copying boot around it, seeming more complex than the above but seems to work, though its label has a: starting at sector 0, not 16(?) [As an aside, man.cgi says that there's no makefs(8) at 7.2-STABLE: http://www.freebsd.org/cgi/man.cgi?query=makefs&sektion=0&manpath=FreeBSD+7.2-stable&apropos=1&format=html which had me believing it until I checked, confirming the contrary] > After doing that I put the packages directory I'd used where it's > supposed to be (disc1), put the proper set of packages for the DVD into > the dvd1 directory, and then run the second pass of the release build to > generate the ISO images. Thanks again; making some sense of my poring over src/release scripts. cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Sun Jan 31 17:04:23 2010 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 F2E911065679 for ; Sun, 31 Jan 2010 17:04:23 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 708988FC0C for ; Sun, 31 Jan 2010 17:04:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o0VH4GkR070503; Mon, 1 Feb 2010 04:04:17 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 1 Feb 2010 04:04:16 +1100 (EST) From: Ian Smith To: "Daniel O'Connor" In-Reply-To: <201001311506.32184.doconnor@gsoft.com.au> Message-ID: <20100201040016.B46992@sola.nimnet.asn.au> References: <1264828108.4948.18.camel@neo.cse.buffalo.edu> <20100130164546.K46992@sola.nimnet.asn.au> <1264905893.19953.23.camel@bauer.cse.buffalo.edu> <201001311506.32184.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1539747065-1264957456=:46992" Cc: freebsd-stable@freebsd.org, Ken Smith Subject: Re: 7.3-BETA1 Available... [memstick.img?] 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, 31 Jan 2010 17:04:24 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1539747065-1264957456=:46992 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Sun, 31 Jan 2010, Daniel O'Connor wrote: > On Sun, 31 Jan 2010, Ken Smith wrote: > > No, no plans afoot for memsticks for the balance of the 7.X releases. > > The sysinstall support for installing from a USB based disk didn't > > get MFCed to stable/7.  Even if it was we're already something of a > > heavyweight on images (both CDs-with-packages and DVD) so my plan all > > along had been to phase in the memstick image for stable/8 and at the > > same time drop CDs-with-packages. > > FWIW the method I used works on 7.x because sysinstall understands how > to read the install off a DOS device :) Still to figure out how your method - using Luigi's syslinux boot off a FAT slice on a stick - works when 7's sysinstall can't see USB disks? cheers, Ian --0-1539747065-1264957456=:46992-- From owner-freebsd-stable@FreeBSD.ORG Sun Jan 31 18:36:35 2010 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 6D69F1065672; Sun, 31 Jan 2010 18:36:35 +0000 (UTC) (envelope-from erwin@mail.droso.net) Received: from mail.droso.net (koala.ipv6.droso.net [IPv6:2001:6c8:6:c:20d:56ff:fe6f:f935]) by mx1.freebsd.org (Postfix) with ESMTP id F294E8FC15; Sun, 31 Jan 2010 18:36:34 +0000 (UTC) Received: by mail.droso.net (Postfix, from userid 1001) id 40BA51CC39; Sun, 31 Jan 2010 19:36:33 +0100 (CET) Date: Sun, 31 Jan 2010 19:36:33 +0100 From: Erwin Lansing To: ports@FreeBSD.org, stable@FreeBSD.org Message-ID: <20100131183632.GC78399@droso.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZG5hGh9V5E9QzVHS" Content-Disposition: inline X-Operating-System: FreeBSD/i386 7.2-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) Cc: re@FreeBSD.org, portmgr@FreeBSD.org Subject: [HEADSUP]: ports feature freeze starts in one week 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, 31 Jan 2010 18:36:35 -0000 --ZG5hGh9V5E9QzVHS Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In preparation for 7.3-RELEASE, the ports tree will be in feature freeze after release candidate 1 (RC1 )is released, currently planned for February 8. If you have any commits with high impact planned, get them in the tree before then and if they require an experimental build, have a request for one in portmgr hands within the next few days. Note that this again will be a feature freeze and not a full freeze. Normal upgrade, new ports, and changes that only affect other branches will be allowed without prior approval but with the extra Feature safe: yes tag in the commit message. Any commit that is sweeping, i.e. touches a large number of ports, infrastructural changes, commts to ports with unusually high number of dependencies, and any other commit that requires the rebuilding of many packages will not be allowed without prior explicit approval from portmgr after that date. -erwin --=20 Erwin Lansing http://droso.org Prediction is very difficult especially about the future erwin@FreeBSD.org --ZG5hGh9V5E9QzVHS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iD8DBQFLZc2wefbgcXQUYpwRAqdhAJ97QDk7k6gMumK+W9wF2Bke2K9vYgCfQMqv ZGug0cW1KJs1Cs0o5BbTohg= =iqkG -----END PGP SIGNATURE----- --ZG5hGh9V5E9QzVHS-- From owner-freebsd-stable@FreeBSD.ORG Sun Jan 31 21:44:47 2010 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 CF8FB1065676 for ; Sun, 31 Jan 2010 21:44:47 +0000 (UTC) (envelope-from freebsd@insightbb.com) Received: from mxsf01.insightbb.com (mxsf01.insightbb.com [74.128.0.71]) by mx1.freebsd.org (Postfix) with ESMTP id 96E918FC18 for ; Sun, 31 Jan 2010 21:44:47 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.49,378,1262581200"; d="scan'208";a="806490798" Received: from unknown (HELO asav02.insightbb.com) ([172.31.249.123]) by mxsf01.insightbb.com with ESMTP; 31 Jan 2010 16:44:46 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As8EAHmIZUvQLicL/2dsb2JhbACBM4F/wyuOfoEtgRiBJloEhgE X-IronPort-AV: E=Sophos;i="4.49,378,1262581200"; d="scan'208";a="345817392" Received: from 208-46-39-11.dia.static.qwest.net (HELO laptop2.stevenfriedrich.org) ([208.46.39.11]) by asavout02.manage.insightbb.com with ESMTP; 31 Jan 2010 16:44:46 -0500 From: Steven Friedrich To: freebsd-stable@freebsd.org Date: Sun, 31 Jan 2010 16:44:39 -0500 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; i386; ; ) References: <201001300708.37683.freebsd@insightbb.com> <4B643A76.7040007@chillt.de> In-Reply-To: <4B643A76.7040007@chillt.de> X-Face: i~b2iK'Z*tJ)pO9@6lJG=k7>N, V~YMq":Iwdl!m|A"g, N@)'|zb[{ Cc: Bartosz Fabianowski Subject: Re: loading module sdhci causes panic 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, 31 Jan 2010 21:44:47 -0000 On Saturday 30 January 2010 08:56:06 am Bartosz Fabianowski wrote: > > Can anyone verify that sdhci is compatible with FreeBSD 8? > > I loaded mmc, mmcsd, and sdhci when I first installed FreeBSD 8.0 > without any problems. Since then, I have updated to -STABLE and put > these three devices in my kernel configuration file. No problems either. > It must be very recent breakage or some incompatibility with your > particular hardware. > > - Bartosz > _______________________________________________ > 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" > When I add the three drivers to my kernel, I don't get a panic, but when I insert an SD 1GB card, nothing happens. pciconf -lv reveals that the driver attached to my device: sdhci0@pci0:11:0:4: class=0x080500 card=0x3082103c chip=0x8034104c rev=0x00 hdr=0x00 vendor = 'Texas Instruments (TI)' device = 'SDA Standard Compliant SD Host Controller (10981734)' class = base peripheral subclass = SD host controller I verified that this SD card is recognized by Windows XP. When I plug in a card, should some message appear on the console? Will it auto-mount? From owner-freebsd-stable@FreeBSD.ORG Sun Jan 31 22:30:16 2010 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 88566106566C for ; Sun, 31 Jan 2010 22:30:16 +0000 (UTC) (envelope-from tobias@kilb.org) Received: from mail.gedankensindfrei.de (mail.gedankensindfrei.de [193.34.68.186]) by mx1.freebsd.org (Postfix) with SMTP id F060D8FC12 for ; Sun, 31 Jan 2010 22:30:15 +0000 (UTC) Received: from localhost ([84.58.139.92]) by mail.gedankensindfrei.de ; Sun, 31 Jan 2010 23:09:43 +0100 Date: Sun, 31 Jan 2010 23:10:02 +0100 From: Tobias Kilb To: freebsd-stable@freebsd.org Message-Id: <20100131231002.a0166fd5.tobias@kilb.org> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.5; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA256"; boundary="Signature=_Sun__31_Jan_2010_23_10_02_+0100_5=ul/w5rEwIalZdk" Subject: Firewire error. Cannot connect WD MyBook over Firewire 400. 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, 31 Jan 2010 22:30:16 -0000 --Signature=_Sun__31_Jan_2010_23_10_02_+0100_5=ul/w5rEwIalZdk Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Guys, I have a problem with my firewire connection to the Western Digital 1TB MyBook. The kernel reports this controller: Jan 30 11:34:23 tobias kernel: fwohci0: mem 0xd3100000-0= xd3100fff irq 23 at device 6.0 on pci4 Jan 30 11:34:23 tobias kernel: fwohci0: [ITHREAD] Jan 30 11:34:23 tobias kernel: fwohci0: OHCI version 1.0 (ROM=3D0) Jan 30 11:34:23 tobias kernel: fwohci0: No. of Isochronous channels is 8. Jan 30 11:34:23 tobias kernel: fwohci0: EUI64 00:90:27:00:02:55:8a:b9 Jan 30 11:34:23 tobias kernel: fwohci0: Phy 1394a available S400, 2 ports. Jan 30 11:34:23 tobias kernel: fwohci0: Link S400, max_rec 2048 bytes. Jan 30 11:34:23 tobias kernel: firewire0: on fwohc= i0 Jan 30 11:34:23 tobias kernel: dcons_crom0: on fi= rewire0 Jan 30 11:34:23 tobias kernel: dcons_crom0: bus_addr 0x1e2c000 Jan 30 11:34:23 tobias kernel: fwe0: on firewire0 Jan 30 11:34:23 tobias kernel: if_fwe0: Fake Ethernet address: 02:90:27:55:= 8a:b9 Jan 30 11:34:23 tobias kernel: fwe0: Ethernet address: 02:90:27:55:8a:b9 Jan 30 11:34:23 tobias kernel: fwip0: on firewire0 Jan 30 11:34:23 tobias kernel: fwip0: Firewire address: 00:90:27:00:02:55:8= a:b9 @ 0xfffe00000000, S400, maxrec 2048 Jan 30 11:34:23 tobias kernel: fwohci0: Initiate bus reset Jan 30 11:34:23 tobias kernel: fwohci0: fwohci_intr_core: BUS reset Jan 30 11:34:23 tobias kernel: fwohci0: fwohci_intr_core: node_id=3D0x00000= 000, SelfID Count=3D1, CYCLEMASTER mode When I plug in the WD MyBook Drive I get the following errors in=20 /var/log/messages: Jan 30 14:11:20 tobias kernel: fwohci0: fwohci_intr_core: BUS reset Jan 30 14:11:20 tobias kernel: fwohci0: fwohci_intr_core: node_id=3D0x00000= 001, SelfID Count=3D2, CYCLEMASTER mode Jan 30 14:11:20 tobias kernel: firewire0: 2 nodes, maxhop <=3D 1 cable IRM = irm(1) (me)=20 Jan 30 14:11:20 tobias kernel: firewire0: bus manager 1=20 Jan 30 14:11:44 tobias kernel: fwohci0: fwohci_intr_core: BUS reset Jan 30 14:11:44 tobias kernel: fwohci0: fwohci_intr_core: node_id=3D0x00000= 001, SelfID Count=3D3, CYCLEMASTER mode Jan 30 14:11:44 tobias kernel: firewire0: 2 nodes, maxhop <=3D 1 cable IRM = irm(1) (me)=20 Jan 30 14:11:44 tobias kernel: firewire0: bus manager 1=20 Jan 30 14:11:44 tobias kernel: fwohci0: fwohci_intr_core: BUS reset Jan 30 14:11:44 tobias kernel: fwohci0: fwohci_intr_core: node_id=3D0x00000= 001, SelfID Count=3D4, CYCLEMASTER mode Jan 30 14:11:44 tobias kernel: firewire0: 2 nodes, maxhop <=3D 1 cable IRM = irm(1) (me)=20 Jan 30 14:11:44 tobias kernel: firewire0: bus manager 1=20 Jan 30 14:11:45 tobias kernel: fwohci0: too many cycle lost, no cycle maste= r presents? And there exists no daX device in /dev. FreeBSD version is: FreeBSD tobias.universum.local 8.0-STABLE FreeBSD 8.0-STABLE #0: Tue Dec 29= 09:04:10 CET 2009 root@tobias.universum.local:/usr/obj/usr/src/sys/GEN= ERIC amd64 Does anybody knows this problem? Regards, tobias --=20 PGP Key ID: 0xFB7BE41D http://pgp.mit.edu:11371/pks/lookup?op=3Dvindex&search=3D0x304097BEFB7BE41D Fingerprint: 8FBE 6DA4 2EA0 5922 4E73 E7B4 3040 97BE FB7B E41D --Signature=_Sun__31_Jan_2010_23_10_02_+0100_5=ul/w5rEwIalZdk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iF4EAREIAAYFAktl/7sACgkQMECXvvt75B1zzwD/aRzXL186JdyF9ellBK6EWGi1 ZeucvUfisMB/DnwA9scBAIN+8Kar2vqafm93VG7c1fDT1Z3MmUT69bV+CFlyoMUL =H4lm -----END PGP SIGNATURE----- --Signature=_Sun__31_Jan_2010_23_10_02_+0100_5=ul/w5rEwIalZdk-- From owner-freebsd-stable@FreeBSD.ORG Sun Jan 31 22:41:57 2010 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 D1D201065679; Sun, 31 Jan 2010 22:41:57 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 65F3D8FC19; Sun, 31 Jan 2010 22:41:57 +0000 (UTC) Received: by vws11 with SMTP id 11so1365588vws.13 for ; Sun, 31 Jan 2010 14:41:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=U97vQe6h76e08l9yMAEUxMTYEnv6Zaf/YXLSL69QJ3U=; b=EDujsp0/V7gPlJwy2/moLsU9fNtxLnLGqStOiMPcxkieRLEOkzYI0aF+E1JKlNFBjk IoJnWirDw7FagNlh4PInCtqt0UFu+VUL44EC7GGnUJxoF25ACu5CMkdPRYdHJImwluLv 9so7Qbdj7eA8VR84/zcfoPiYTS7ANh0+JUaJM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=bxpPGSbz9qV/ppfTx7rfMAOVRTpHCbbwhQmbMOeDhykH8ICnL47D+LGrQpoK66yt5L QpF4BzXMnud/mH1oV/XGAqBkdHhBYYZcqpn5qIHdTpZeFpmICqEnK3GKJr6WGxOmsSIe Iw6CKQopCsnwdU1ceDahKe0TrrQN6fdszBWY8= Received: by 10.220.124.25 with SMTP id s25mr4477575vcr.68.1264977716290; Sun, 31 Jan 2010 14:41:56 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 42sm52552969vws.8.2010.01.31.14.41.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 31 Jan 2010 14:41:54 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sun, 31 Jan 2010 14:40:33 -0800 From: Pyun YongHyeon Date: Sun, 31 Jan 2010 14:40:33 -0800 To: Nick Rogers Message-ID: <20100131224033.GA1107@michelle.cdnetworks.com> References: <147432021001310037n1b67f01bx4b4e8781321cea8@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="5mCyUwZo2JvN/JJP" Content-Disposition: inline In-Reply-To: <147432021001310037n1b67f01bx4b4e8781321cea8@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: jfv@FreeBSD.org, stable@freebsd.org Subject: Re: em(4) + ALTQ broken X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@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, 31 Jan 2010 22:41:58 -0000 --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Jan 31, 2010 at 12:37:43AM -0800, Nick Rogers wrote: > I'm having problems getting PF + ALTQ to work on em(4) interfaces under > 8.0-RELEASE. Kernel was rebuilt with the additional options necessary for > ALTQ and what not. Same basic configuration works fine under 7.2-RELEASE. > Basically, the queues create successfully but running a pfctl -vsq shows a > zero packet/byte count for all queues, even the interface's root queues. > > This same problem is mentioned in PR kern/138392, and the following forum > thread... > http://forums.freebsd.org/showthread.php?t=6656 > > em(4)/e1000 driver from CURRENT does not fix the problem. Building an > 8.0-RELEASE kernel with the em(4) driver from 7.2-RELEASE fixes the problem > (i.e., replacing sys/dev/e1000 with that from 7.2). > > One of the machines im experiencing this on has the following intel > chipset... > > [user@foo ~]$ sysctl dev.em.0 > dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 6.9.6 > dev.em.0.%driver: em > dev.em.0.%location: slot=0 function=0 > dev.em.0.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x15d9 > subdevice=0x040d class=0x020000 > dev.em.0.%parent: pci3 > dev.em.0.debug: -1 > dev.em.0.stats: -1 > dev.em.0.rx_int_delay: 0 > dev.em.0.tx_int_delay: 66 > dev.em.0.rx_abs_int_delay: 66 > dev.em.0.tx_abs_int_delay: 66 > dev.em.0.rx_processing_limit: 100 > > Is this issue receiving any attention? I ask because one of the em(4) driver > contributors mentioned he had not heard of this problem in a recent thread > regarding a different em(4) bug, and this is a pretty serious problem for me > as I have many devices in production that need to be upgraded to 8.0, all > running Intel interfaces and relying on ALTQ. > > I appreciate any updates or information and would be happy to test any > patches and/or provide more information. Thanks. > _______________________________________________ I guess the problem comes from multi-queue support. The drbr interface is implemented with inline function so em(4)/igb(4) may have to define ALTQ to the header. I have not tested the patch(no time at this moment) but would you give it try? Thanks. --5mCyUwZo2JvN/JJP Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="em_igb_altq.patch" Index: sys/dev/e1000/if_igb.c =================================================================== --- sys/dev/e1000/if_igb.c (revision 203324) +++ sys/dev/e1000/if_igb.c (working copy) @@ -36,6 +36,7 @@ #ifdef HAVE_KERNEL_OPTION_HEADERS #include "opt_device_polling.h" #include "opt_inet.h" +#include "opt_altq.h" #endif #include Index: sys/dev/e1000/if_em.c =================================================================== --- sys/dev/e1000/if_em.c (revision 203324) +++ sys/dev/e1000/if_em.c (working copy) @@ -35,6 +35,7 @@ #ifdef HAVE_KERNEL_OPTION_HEADERS #include "opt_device_polling.h" #include "opt_inet.h" +#include "opt_altq.h" #endif #include --5mCyUwZo2JvN/JJP-- From owner-freebsd-stable@FreeBSD.ORG Sun Jan 31 22:57:15 2010 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 98B281065670 for ; Sun, 31 Jan 2010 22:57:15 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id 79B928FC16 for ; Sun, 31 Jan 2010 22:57:15 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta08.emeryville.ca.mail.comcast.net with comcast id cNgP1d0041smiN4A8NxFJe; Sun, 31 Jan 2010 22:57:15 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta20.emeryville.ca.mail.comcast.net with comcast id cNxF1d0053S48mS8gNxFGw; Sun, 31 Jan 2010 22:57:15 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 0D8091E3033; Sun, 31 Jan 2010 14:57:14 -0800 (PST) Date: Sun, 31 Jan 2010 14:57:14 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100131225714.GA20108@icarus.home.lan> References: <201001300708.37683.freebsd@insightbb.com> <4B643A76.7040007@chillt.de> <201001311644.39995.freebsd@insightbb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201001311644.39995.freebsd@insightbb.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: loading module sdhci causes panic 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, 31 Jan 2010 22:57:15 -0000 On Sun, Jan 31, 2010 at 04:44:39PM -0500, Steven Friedrich wrote: > On Saturday 30 January 2010 08:56:06 am Bartosz Fabianowski wrote: > > > Can anyone verify that sdhci is compatible with FreeBSD 8? > > > > I loaded mmc, mmcsd, and sdhci when I first installed FreeBSD 8.0 > > without any problems. Since then, I have updated to -STABLE and put > > these three devices in my kernel configuration file. No problems either. > > It must be very recent breakage or some incompatibility with your > > particular hardware. > > > > - Bartosz > > _______________________________________________ > > 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" > > > When I add the three drivers to my kernel, I don't get a panic, but when I > insert an SD 1GB card, nothing happens. > > pciconf -lv reveals that the driver attached to my device: > > sdhci0@pci0:11:0:4: class=0x080500 card=0x3082103c chip=0x8034104c > rev=0x00 hdr=0x00 > vendor = 'Texas Instruments (TI)' > device = 'SDA Standard Compliant SD Host Controller (10981734)' > class = base peripheral > subclass = SD host controller > > I verified that this SD card is recognized by Windows XP. > > When I plug in a card, should some message appear on the console? Will it > auto-mount? Can you please post your entire kernel configuration file (specifically the one which includes the above 3 drivers in it)? -- | Jeremy Chadwick jdc@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 Feb 1 00:33:29 2010 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 51C92106566B for ; Mon, 1 Feb 2010 00:33:29 +0000 (UTC) (envelope-from freebsd@insightbb.com) Received: from mxsf14.insightbb.com (mxsf14.insightbb.com [74.128.0.96]) by mx1.freebsd.org (Postfix) with ESMTP id 146A48FC19 for ; Mon, 1 Feb 2010 00:33:28 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.49,379,1262581200"; d="scan'208";a="28743719" Received: from unknown (HELO asav03.insightbb.com) ([172.31.249.123]) by mxsf14.insightbb.com with ESMTP; 31 Jan 2010 19:33:28 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroEAFGwZUvQLicL/2dsb2JhbACBM9Q9gkWCAAQ X-IronPort-AV: E=Sophos;i="4.49,379,1262581200"; d="scan'208";a="122833053" Received: from 208-46-39-11.dia.static.qwest.net (HELO laptop2.stevenfriedrich.org) ([208.46.39.11]) by asavout03.insightbb.com with ESMTP; 31 Jan 2010 19:33:26 -0500 From: Steven Friedrich To: freebsd-stable@freebsd.org Date: Sun, 31 Jan 2010 19:33:19 -0500 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; i386; ; ) References: <201001300708.37683.freebsd@insightbb.com> <201001311644.39995.freebsd@insightbb.com> <20100131225714.GA20108@icarus.home.lan> In-Reply-To: <20100131225714.GA20108@icarus.home.lan> X-Face: i~b2iK'Z*tJ)pO9@6lJG=k7>N, V~YMq":Iwdl!m|A"g, N@)'|zb[{ Cc: Jeremy Chadwick Subject: Re: loading module sdhci causes panic 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, 01 Feb 2010 00:33:29 -0000 On Sunday 31 January 2010 05:57:14 pm Jeremy Chadwick wrote: > On Sun, Jan 31, 2010 at 04:44:39PM -0500, Steven Friedrich wrote: > > On Saturday 30 January 2010 08:56:06 am Bartosz Fabianowski wrote: > > > > Can anyone verify that sdhci is compatible with FreeBSD 8? > > > > > > I loaded mmc, mmcsd, and sdhci when I first installed FreeBSD 8.0 > > > without any problems. Since then, I have updated to -STABLE and put > > > these three devices in my kernel configuration file. No problems > > > either. It must be very recent breakage or some incompatibility with > > > your particular hardware. > > > > > > - Bartosz > > > > When I add the three drivers to my kernel, I don't get a panic, but when > > I insert an SD 1GB card, nothing happens. > > > > pciconf -lv reveals that the driver attached to my device: > > > > sdhci0@pci0:11:0:4: class=0x080500 card=0x3082103c chip=0x8034104c > > rev=0x00 hdr=0x00 > > vendor = 'Texas Instruments (TI)' > > device = 'SDA Standard Compliant SD Host Controller (10981734)' > > class = base peripheral > > subclass = SD host controller > > > > I verified that this SD card is recognized by Windows XP. > > > > When I plug in a card, should some message appear on the console? Will > > it auto-mount? > > Can you please post your entire kernel configuration file (specifically > the one which includes the above 3 drivers in it)? > # # LAPTOP -- Laptop kernel configuration file for FreeBSD/i386 # ident LAPTOP machine i386 cpu I586_CPU cpu I686_CPU # To statically compile in device wiring instead of /boot/device.hints #hints "LAPTOP.hints" # Default places to look for devices. makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols # hopefully, cure the shutdown anomaly options PRINTF_BUFR_SIZE=128 options INCLUDE_CONFIG_FILE options SCHED_ULE # ULE scheduler #options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption # IPI_PREEMPTION instructs the kernel to preempt threads running on other # CPUS if needed. Relies on the PREEMPTION option options IPI_PREEMPTION options INET # InterNETworking options INET6 # IPv6 communications protocols options SCTP # Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling #options MD_ROOT # MD is a potential root device options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework #options GEOM_GPT # GUID Partition Tables. # The options COMPAT_43 kernel configuration option has been deemed unnecessary and # has been removed from GENERIC and related kernel configurations. This change may # result in a small performance increase for some workloads. #options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options P1003_1B_SEMAPHORES # POSIX-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev #options ADAPTIVE_GIANT # Giant mutex is adaptive. options SC_HISTORY_SIZE=1000 options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing options MAC # TrustedBSD MAC Framework options FLOWTABLE # per-cpu routing cache options KTRACE # ktrace(1) support options STACK # stack(9) support #options KDTRACE_HOOKS # Kernel DTrace hooks # PERFMON causes the driver for Pentium/Pentium Pro performance counters # to be compiled. See perfmon(4) for more information. # options PERFMON # To make an SMP kernel, the next line is needed options SMP # Symmetric MultiProcessor Kernel # The apic device enables the use of the I/O APIC for interrupt delivery. # The apic device can be used in both UP and SMP kernels, but is required # for SMP kernels. Thus, the apic device is not strictly an SMP option, # but it is a prerequisite for SMP. device apic # I/O APIC # ACPI extras driver for HP laptops device acpi_hp # CPU frequency control device cpufreq # # Temperature sensors: # # coretemp: on-die sensor on Intel Core and newer CPUs # device coretemp # Bus support. device pci # Floppy drives #device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives #device atausb # ATA USB support options ATA_STATIC_ID # Static device numbering # SCSI peripherals device scbus # SCSI bus (required for SCSI) device da # Direct Access (disks) #device cd # CD device pass # Passthrough device (direct SCSI access) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets device drm # DRM core module required by DRM drivers device radeondrm # ATI Radeon # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support device cbb # cardbus (yenta) bridge device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus # Serial (COM) ports #device sio # 8250, 16[45]50 based serial ports # Parallel port #device ppc #device ppbus # Parallel port bus (required) #device lpt # Printer #device plip # TCP/IP over parallel #device ppi # Parallel port interface device #device vpo # Requires scbus and da # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! #device miibus # MII bus support #device rl # RealTek 8129/8139 # Wireless NIC cards #device wlan # 802.11 support #device wlan_wep # 802.11 WEP support #device wlan_ccmp # 802.11 CCMP support #device wlan_tkip # 802.11 TKIP support #device wlan_amrr # AMRR transmit rate control algorithm # the scan code has been folded into the wlan module in FreeBSD8.0 #device wlan_scan_ap # 802.11 AP mode scanning #device wlan_scan_sta # 802.11 STA mode scanning #device wlan_xauth # #device an # Aironet 4500/4800 802.11 wireless NICs. #device awi # BayStack 660 and others #device ral # Ralink Technology RT2500 wireless NICs. #device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) #device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) # ugen is gone from 8.0, must have been folded-in #device ugen # Generic # umass will conflict with atausb # removed umass per advice from Predrag Punosevac device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse #device ulpt # printers #device ucom # why isn't this listed in NOTES? #device uplcom # IOgear (ATEN) usb serial adapter # USB Ethernet, requires miibus #device axe # ASIX Electronics USB Ethernet # FireWire support #device firewire # FireWire bus code device snd_ich device sound #device speaker # see man acpi #device acpi # acpi_video can conflict with device agp # ACPI Video Extensions (LCD backlight/brightness, video output, etc.) #device acpi_video options VESA # Enable NDIS binary driver support options NDISAPI #device ndis # Netgear WG111T supported as of 8.0, but load as module #device uath # Atheros AR5523 wireless NICs device dcons # Dumb console driver #device dcons_crom # Configuration ROM for dcons device smb device smbus device ichsmb # how about SD controller device mmc device mmcsd device sdhci From owner-freebsd-stable@FreeBSD.ORG Mon Feb 1 01:13:17 2010 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 96A27106568D for ; Mon, 1 Feb 2010 01:13:17 +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 EFB048FC13 for ; Mon, 1 Feb 2010 01:13:16 +0000 (UTC) Received: from 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 o111Cmkk032521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 1 Feb 2010 11:42:48 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Ian Smith Date: Mon, 1 Feb 2010 11:42:44 +1030 User-Agent: KMail/1.9.10 References: <1264828108.4948.18.camel@neo.cse.buffalo.edu> <201001311506.32184.doconnor@gsoft.com.au> <20100201040016.B46992@sola.nimnet.asn.au> In-Reply-To: <20100201040016.B46992@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1611814.25ULi7BySM"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201002011142.46490.doconnor@gsoft.com.au> X-Spam-Score: -3.638 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: freebsd-stable@freebsd.org, Ken Smith Subject: Re: 7.3-BETA1 Available... [memstick.img?] 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, 01 Feb 2010 01:13:17 -0000 --nextPart1611814.25ULi7BySM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Mon, 1 Feb 2010, Ian Smith wrote: > On Sun, 31 Jan 2010, Daniel O'Connor wrote: > > On Sun, 31 Jan 2010, Ken Smith wrote: > > > No, no plans afoot for memsticks for the balance of the 7.X > > > releases. The sysinstall support for installing from a USB based > > > disk didn't get MFCed to stable/7. =C2=A0Even if it was we're already > > > something of a heavyweight on images (both CDs-with-packages and > > > DVD) so my plan all along had been to phase in the memstick > > > image for stable/8 and at the same time drop CDs-with-packages. > > > > FWIW the method I used works on 7.x because sysinstall understands > > how to read the install off a DOS device :) > > Still to figure out how your method - using Luigi's syslinux boot off > a FAT slice on a stick - works when 7's sysinstall can't see USB > disks? 7 _can_ see USB disks just fine, it has nothing to do with the USB=20 stack. The problem was purely that sysinstall did not look at certain=20 candidates for source media due to some old assumptions in the code.=20 The patches in 8.x to allow it to install "from USB" just changed it=20 to look harder for UFS source media. IMO FAT32 is more flexible anyway since 99.9% of all USB sticks already=20 come formatted using it, and 99.9% of all computers with USB ports can=20 read and write it. =46WIW there is a tool that is shipped with some Linux distros which can=20 take a CD/DVD image and munge it onto a USB stick. Unfortunately it=20 doesn't work on FreeBSD because I can't get the loader to read from the=20 USB stick directly which means I need to make an MFS for sysinstall=20 which contains the loader, kernel and sysinstall MFS. If such an image=20 were shipped as part of the build then this tool could be used by end=20 users to convert the ISO image themselves. =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 --nextPart1611814.25ULi7BySM Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLZiqO5ZPcIHs/zowRAoSQAJ9wkzAPjOdafjZBJiX57uqwPuaYKQCeILiE VSggqKBpfE9WjO2m+0xJ/eI= =GlN/ -----END PGP SIGNATURE----- --nextPart1611814.25ULi7BySM-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 1 02:06:52 2010 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 09E76106568D for ; Mon, 1 Feb 2010 02:06:52 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-pz0-f194.google.com (mail-pz0-f194.google.com [209.85.222.194]) by mx1.freebsd.org (Postfix) with ESMTP id D00C68FC0C for ; Mon, 1 Feb 2010 02:06:51 +0000 (UTC) Received: by pzk32 with SMTP id 32so1248247pzk.27 for ; Sun, 31 Jan 2010 18:06:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PznhmLSlW6JZjZEu3v/emNqwAmggrb/ymK6RhhzSUZI=; b=harg6y4QTlX7BMfrid9CjY5yZUtemtMVHp3VMYAvcQNzmwuC5ZiowQSazPRmCbhz6t nNiL2spKXYvXG7Oiyy3bnC12ADAiCNAFIjvNRxr4l4TQAZAiUzcrJ5v8n3J98/JezD1T haV4ECEd0R3Dt5NVySdpDrCJtaej1QQ70VSg4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fXNLIeqUBQPoNzJS/3yaXWCtbbXSBkQwG+4O2kx1isLyW+9xQjOe2bbXHsSC/QhwnA hDeP3D/St5sxJUGh0y7HTa4XqPyxdRGWrTtcSNWDZfY2AcisIc3v8MI45NkisTU2fFU2 C/1TZVK8nVdgHMSTY7BL3/go3p9KgTxxZ4Dp4= MIME-Version: 1.0 Received: by 10.143.24.15 with SMTP id b15mr2666394wfj.41.1264989660116; Sun, 31 Jan 2010 18:01:00 -0800 (PST) In-Reply-To: <201002011142.46490.doconnor@gsoft.com.au> References: <1264828108.4948.18.camel@neo.cse.buffalo.edu> <201001311506.32184.doconnor@gsoft.com.au> <20100201040016.B46992@sola.nimnet.asn.au> <201002011142.46490.doconnor@gsoft.com.au> Date: Sun, 31 Jan 2010 18:01:00 -0800 Message-ID: <7d6fde3d1001311801i5d19ed65wb062d5b5f8130740@mail.gmail.com> From: Garrett Cooper To: "Daniel O'Connor" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, Ian Smith , Ken Smith Subject: Re: 7.3-BETA1 Available... [memstick.img?] 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, 01 Feb 2010 02:06:52 -0000 On Sun, Jan 31, 2010 at 5:12 PM, Daniel O'Connor wr= ote: > On Mon, 1 Feb 2010, Ian Smith wrote: >> On Sun, 31 Jan 2010, Daniel O'Connor wrote: >> =A0> On Sun, 31 Jan 2010, Ken Smith wrote: >> =A0> > No, no plans afoot for memsticks for the balance of the 7.X >> =A0> > releases. The sysinstall support for installing from a USB based >> =A0> > disk didn't get MFCed to stable/7. =A0Even if it was we're alread= y >> =A0> > something of a heavyweight on images (both CDs-with-packages and >> =A0> > DVD) so my plan all along had been to phase in the memstick >> =A0> > image for stable/8 and at the same time drop CDs-with-packages. >> =A0> >> =A0> FWIW the method I used works on 7.x because sysinstall understands >> =A0> how to read the install off a DOS device :) >> >> Still to figure out how your method - using Luigi's syslinux boot off >> a FAT slice on a stick - works when 7's sysinstall can't see USB >> disks? > > 7 _can_ see USB disks just fine, it has nothing to do with the USB > stack. > > The problem was purely that sysinstall did not look at certain > candidates for source media due to some old assumptions in the code. > The patches in 8.x =A0to allow it to install "from USB" just changed it > to look harder for UFS source media. > > IMO FAT32 is more flexible anyway since 99.9% of all USB sticks already > come formatted using it, and 99.9% of all computers with USB ports can > read and write it. > > FWIW there is a tool that is shipped with some Linux distros which can > take a CD/DVD image and munge it onto a USB stick. Unfortunately it > doesn't work on FreeBSD because I can't get the loader to read from the > USB stick directly which means I need to make an MFS for sysinstall > which contains the loader, kernel and sysinstall MFS. If such an image > were shipped as part of the build then this tool could be used by end > users to convert the ISO image themselves. Daniel, Could you please describe the process to me in more detail (i.e what tools are used, high-level process req'd, etc)? I am going to be doing something similar for work [at Ironport] and if I can do it in a better manner and it would be accepted into the tree, that would be the option I'd take for resolving this bootable media, for my work as well as for the community as a whole. Thanks, -Garrett From owner-freebsd-stable@FreeBSD.ORG Mon Feb 1 02:26:27 2010 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 1DD381065670 for ; Mon, 1 Feb 2010 02:26:27 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id E7A218FC14 for ; Mon, 1 Feb 2010 02:26:26 +0000 (UTC) Received: by pxi13 with SMTP id 13so2164885pxi.3 for ; Sun, 31 Jan 2010 18:26:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TM2sJtlO0DJEKODxR0A6Af1ONMOCWnYpcqZr1QlJmCU=; b=eKOuAgha6QOADWnq/4jge+c/y7RwREmqwVjIxF1H0V4bn5VhbYd/k0D3iMzwUES+NN oUq42fYf3BUOgIFOLSC1lZ0tlhiH42DHKrsR+v/7X9+qZk6DivQcTlJVnGd2n7vtukWo j6cOwfPq6WFeXk9kV8L5cdnpo4D8iqzkHiBBA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=PsOUcNOi5PqH+q54SBzy9somzbv4A2mmpwOxiJbrCzKEmZ3akkwTW9G9lG9gAtR9KH 6rUvbe1Z1y2UgN8F50K2qz/Ne4Ga7K+5H5nqLfKsYv2atWsCWH6vfG+KsBHwvcjqeuGI E3quI2L4V+Dohd8eqsrpGSEsBzy1thu0KUZ2E= MIME-Version: 1.0 Received: by 10.142.5.10 with SMTP id 10mr2602290wfe.334.1264989298427; Sun, 31 Jan 2010 17:54:58 -0800 (PST) In-Reply-To: <20100131231002.a0166fd5.tobias@kilb.org> References: <20100131231002.a0166fd5.tobias@kilb.org> Date: Sun, 31 Jan 2010 17:54:58 -0800 Message-ID: <7d6fde3d1001311754y393f052fndc4cb8c7a716678a@mail.gmail.com> From: Garrett Cooper To: Tobias Kilb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Firewire error. Cannot connect WD MyBook over Firewire 400. 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, 01 Feb 2010 02:26:27 -0000 On Sun, Jan 31, 2010 at 2:10 PM, Tobias Kilb wrote: > Hi Guys, > > I have a problem with my firewire connection to the Western Digital 1TB > MyBook. The kernel reports this controller: > > Jan 30 11:34:23 tobias kernel: fwohci0: mem 0xd3100000= -0xd3100fff irq 23 at device 6.0 on pci4 > Jan 30 11:34:23 tobias kernel: fwohci0: [ITHREAD] > Jan 30 11:34:23 tobias kernel: fwohci0: OHCI version 1.0 (ROM=3D0) > Jan 30 11:34:23 tobias kernel: fwohci0: No. of Isochronous channels is 8. > Jan 30 11:34:23 tobias kernel: fwohci0: EUI64 00:90:27:00:02:55:8a:b9 > Jan 30 11:34:23 tobias kernel: fwohci0: Phy 1394a available S400, 2 ports= . > Jan 30 11:34:23 tobias kernel: fwohci0: Link S400, max_rec 2048 bytes. > Jan 30 11:34:23 tobias kernel: firewire0: on fwo= hci0 > Jan 30 11:34:23 tobias kernel: dcons_crom0: on = firewire0 > Jan 30 11:34:23 tobias kernel: dcons_crom0: bus_addr 0x1e2c000 > Jan 30 11:34:23 tobias kernel: fwe0: on firewire= 0 > Jan 30 11:34:23 tobias kernel: if_fwe0: Fake Ethernet address: 02:90:27:5= 5:8a:b9 > Jan 30 11:34:23 tobias kernel: fwe0: Ethernet address: 02:90:27:55:8a:b9 > Jan 30 11:34:23 tobias kernel: fwip0: on firewire0 > Jan 30 11:34:23 tobias kernel: fwip0: Firewire address: 00:90:27:00:02:55= :8a:b9 @ 0xfffe00000000, S400, maxrec 2048 > Jan 30 11:34:23 tobias kernel: fwohci0: Initiate bus reset > Jan 30 11:34:23 tobias kernel: fwohci0: fwohci_intr_core: BUS reset > Jan 30 11:34:23 tobias kernel: fwohci0: fwohci_intr_core: node_id=3D0x000= 00000, SelfID Count=3D1, CYCLEMASTER mode > > When I plug in the WD MyBook Drive I get the following errors in > /var/log/messages: > > Jan 30 14:11:20 tobias kernel: fwohci0: fwohci_intr_core: BUS reset > Jan 30 14:11:20 tobias kernel: fwohci0: fwohci_intr_core: node_id=3D0x000= 00001, SelfID Count=3D2, CYCLEMASTER mode > Jan 30 14:11:20 tobias kernel: firewire0: 2 nodes, maxhop <=3D 1 cable IR= M irm(1) =A0(me) > Jan 30 14:11:20 tobias kernel: firewire0: bus manager 1 > Jan 30 14:11:44 tobias kernel: fwohci0: fwohci_intr_core: BUS reset > Jan 30 14:11:44 tobias kernel: fwohci0: fwohci_intr_core: node_id=3D0x000= 00001, SelfID Count=3D3, CYCLEMASTER mode > Jan 30 14:11:44 tobias kernel: firewire0: 2 nodes, maxhop <=3D 1 cable IR= M irm(1) =A0(me) > Jan 30 14:11:44 tobias kernel: firewire0: bus manager 1 > Jan 30 14:11:44 tobias kernel: fwohci0: fwohci_intr_core: BUS reset > Jan 30 14:11:44 tobias kernel: fwohci0: fwohci_intr_core: node_id=3D0x000= 00001, SelfID Count=3D4, CYCLEMASTER mode > Jan 30 14:11:44 tobias kernel: firewire0: 2 nodes, maxhop <=3D 1 cable IR= M irm(1) =A0(me) > Jan 30 14:11:44 tobias kernel: firewire0: bus manager 1 > Jan 30 14:11:45 tobias kernel: fwohci0: too many cycle lost, no cycle mas= ter presents? > > And there exists no daX device in /dev. > > FreeBSD version is: > > FreeBSD tobias.universum.local 8.0-STABLE FreeBSD 8.0-STABLE #0: Tue Dec = 29 09:04:10 CET 2009 =A0 =A0 root@tobias.universum.local:/usr/obj/usr/src/s= ys/GENERIC =A0amd64 > > Does anybody knows this problem? Is it one of the models that has encryption enabled on it? Thanks, -Garrett From owner-freebsd-stable@FreeBSD.ORG Mon Feb 1 02:56:42 2010 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 AEE41106566C for ; Mon, 1 Feb 2010 02:56:41 +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 124E08FC12 for ; Mon, 1 Feb 2010 02:56:40 +0000 (UTC) Received: from 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 o112uYIV035496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 1 Feb 2010 13:26:34 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Garrett Cooper Date: Mon, 1 Feb 2010 13:26:24 +1030 User-Agent: KMail/1.9.10 References: <1264828108.4948.18.camel@neo.cse.buffalo.edu> <201002011142.46490.doconnor@gsoft.com.au> <7d6fde3d1001311801i5d19ed65wb062d5b5f8130740@mail.gmail.com> In-Reply-To: <7d6fde3d1001311801i5d19ed65wb062d5b5f8130740@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1331191.mNPq3rDmfx"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201002011326.32384.doconnor@gsoft.com.au> X-Spam-Score: -3.637 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: freebsd-stable@freebsd.org, Ian Smith , Ken Smith Subject: Re: 7.3-BETA1 Available... [memstick.img?] 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, 01 Feb 2010 02:56:42 -0000 --nextPart1331191.mNPq3rDmfx Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Mon, 1 Feb 2010, Garrett Cooper wrote: > =A0 =A0 Could you please describe the process to me in more detail (i.e > what tools are used, high-level process req'd, etc)? I am going to be > doing something similar for work [at Ironport] and if I can do it in > a better manner and it would be accepted into the tree, that would be > the option I'd take for resolving this bootable media, for my work as > well as for the community as a whole. I do a make release then run this script on the resulting DVD=20 directory.. http://www.gsoft.com.au/~doconnor/makeusb.sh ie.. /tmp/makeusb.sh /tmp/${RELNAME}-release/R/cdrom/dvd1 /dev/da1 Then mount it onto /mnt and do cp -r /tmp/${RELNAME}-release/R/cdrom/dvd1/${BUILDNAME} /mnt It creates an MFS using makefs which syslinux can load and then the=20 loader runs, loads the kernel and the MFS (nested MFS - bleh) and then=20 boots as usual for an install. Once the kernel starts the USB stick is accessable as daX as a FAT=20 partition. I have tried getting syslinux to just run the loader from an MFS (which=20 works) but I can't get the loader to read the USB stick for some reason=20 even though AFAICS it should grok FAT32 disks. I didn't really know how=20 to debug it any further though so I went with the less elegant MFS in=20 MFS route. Also I imagine gpart could be used (in HEAD anyway) instead of the fdisk=20 voodoo I have. Note that while it references logo.lss it doesn't actually copy it over=20 (it's my company's logo, but anything would suffice and it's optional -=20 syslinux ignores the directive if the file doesn't exist) I hope you find it useful and it gets in the tree :) Thanks. =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 --nextPart1331191.mNPq3rDmfx Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLZkLg5ZPcIHs/zowRArzbAJ97sRH+1fpynMMaR+6aHyMkYaR+jACdFkH+ NIC/mGcsSPi/HIwKAgsCHek= =NFc0 -----END PGP SIGNATURE----- --nextPart1331191.mNPq3rDmfx-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 1 05:52:14 2010 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 D097D106566B for ; Mon, 1 Feb 2010 05:52:14 +0000 (UTC) (envelope-from tobias@kilb.org) Received: from mail.gedankensindfrei.de (mail.gedankensindfrei.de [193.34.68.186]) by mx1.freebsd.org (Postfix) with SMTP id 43B618FC0C for ; Mon, 1 Feb 2010 05:52:13 +0000 (UTC) Received: from localhost ([84.58.139.92]) by mail.gedankensindfrei.de ; Mon, 1 Feb 2010 06:52:12 +0100 Date: Mon, 1 Feb 2010 06:52:24 +0100 From: Tobias Kilb To: freebsd-stable@freebsd.org Message-Id: <20100201065224.50d4b1a3.tobias@kilb.org> In-Reply-To: <7d6fde3d1001311754y393f052fndc4cb8c7a716678a@mail.gmail.com> References: <20100131231002.a0166fd5.tobias@kilb.org> <7d6fde3d1001311754y393f052fndc4cb8c7a716678a@mail.gmail.com> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.5; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA256"; boundary="Signature=_Mon__1_Feb_2010_06_52_24_+0100_C6yZE4gbLGgYvS79" Subject: Re: Firewire error. Cannot connect WD MyBook over Firewire 400. 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, 01 Feb 2010 05:52:14 -0000 --Signature=_Mon__1_Feb_2010_06_52_24_+0100_C6yZE4gbLGgYvS79 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 31 Jan 2010 17:54:58 -0800 Garrett Cooper wrote: > On Sun, Jan 31, 2010 at 2:10 PM, Tobias Kilb wrote: > > Hi Guys, > > > > I have a problem with my firewire connection to the Western Digital 1TB > > MyBook. The kernel reports this controller: > > > > Jan 30 11:34:23 tobias kernel: fwohci0: mem 0xd31000= 00-0xd3100fff irq 23 at device 6.0 on pci4 > > Jan 30 11:34:23 tobias kernel: fwohci0: [ITHREAD] > > Jan 30 11:34:23 tobias kernel: fwohci0: OHCI version 1.0 (ROM=3D0) > > Jan 30 11:34:23 tobias kernel: fwohci0: No. of Isochronous channels is = 8. > > Jan 30 11:34:23 tobias kernel: fwohci0: EUI64 00:90:27:00:02:55:8a:b9 > > Jan 30 11:34:23 tobias kernel: fwohci0: Phy 1394a available S400, 2 por= ts. > > Jan 30 11:34:23 tobias kernel: fwohci0: Link S400, max_rec 2048 bytes. > > Jan 30 11:34:23 tobias kernel: firewire0: on f= wohci0 > > Jan 30 11:34:23 tobias kernel: dcons_crom0: o= n firewire0 > > Jan 30 11:34:23 tobias kernel: dcons_crom0: bus_addr 0x1e2c000 > > Jan 30 11:34:23 tobias kernel: fwe0: on firewi= re0 > > Jan 30 11:34:23 tobias kernel: if_fwe0: Fake Ethernet address: 02:90:27= :55:8a:b9 > > Jan 30 11:34:23 tobias kernel: fwe0: Ethernet address: 02:90:27:55:8a:b9 > > Jan 30 11:34:23 tobias kernel: fwip0: on firewire0 > > Jan 30 11:34:23 tobias kernel: fwip0: Firewire address: 00:90:27:00:02:= 55:8a:b9 @ 0xfffe00000000, S400, maxrec 2048 > > Jan 30 11:34:23 tobias kernel: fwohci0: Initiate bus reset > > Jan 30 11:34:23 tobias kernel: fwohci0: fwohci_intr_core: BUS reset > > Jan 30 11:34:23 tobias kernel: fwohci0: fwohci_intr_core: node_id=3D0x0= 0000000, SelfID Count=3D1, CYCLEMASTER mode > > > > When I plug in the WD MyBook Drive I get the following errors in > > /var/log/messages: > > > > Jan 30 14:11:20 tobias kernel: fwohci0: fwohci_intr_core: BUS reset > > Jan 30 14:11:20 tobias kernel: fwohci0: fwohci_intr_core: node_id=3D0x0= 0000001, SelfID Count=3D2, CYCLEMASTER mode > > Jan 30 14:11:20 tobias kernel: firewire0: 2 nodes, maxhop <=3D 1 cable = IRM irm(1) =A0(me) > > Jan 30 14:11:20 tobias kernel: firewire0: bus manager 1 > > Jan 30 14:11:44 tobias kernel: fwohci0: fwohci_intr_core: BUS reset > > Jan 30 14:11:44 tobias kernel: fwohci0: fwohci_intr_core: node_id=3D0x0= 0000001, SelfID Count=3D3, CYCLEMASTER mode > > Jan 30 14:11:44 tobias kernel: firewire0: 2 nodes, maxhop <=3D 1 cable = IRM irm(1) =A0(me) > > Jan 30 14:11:44 tobias kernel: firewire0: bus manager 1 > > Jan 30 14:11:44 tobias kernel: fwohci0: fwohci_intr_core: BUS reset > > Jan 30 14:11:44 tobias kernel: fwohci0: fwohci_intr_core: node_id=3D0x0= 0000001, SelfID Count=3D4, CYCLEMASTER mode > > Jan 30 14:11:44 tobias kernel: firewire0: 2 nodes, maxhop <=3D 1 cable = IRM irm(1) =A0(me) > > Jan 30 14:11:44 tobias kernel: firewire0: bus manager 1 > > Jan 30 14:11:45 tobias kernel: fwohci0: too many cycle lost, no cycle m= aster presents? > > > > And there exists no daX device in /dev. > > > > FreeBSD version is: > > > > FreeBSD tobias.universum.local 8.0-STABLE FreeBSD 8.0-STABLE #0: Tue De= c 29 09:04:10 CET 2009 =A0 =A0 root@tobias.universum.local:/usr/obj/usr/src= /sys/GENERIC =A0amd64 > > > > Does anybody knows this problem? >=20 > Is it one of the models that has encryption enabled on it? No this disk has no (pseudo)hardware encryption.=20 I have tried fwcontrol -r, but that helps nothing. > Thanks, > -Garrett >___________________________________ > 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" --=20 PGP Key ID: 0xFB7BE41D http://pgp.mit.edu:11371/pks/lookup?op=3Dvindex&search=3D0x304097BEFB7BE41D Fingerprint: 8FBE 6DA4 2EA0 5922 4E73 E7B4 3040 97BE FB7B E41D --Signature=_Mon__1_Feb_2010_06_52_24_+0100_C6yZE4gbLGgYvS79 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iF4EAREIAAYFAktmbCAACgkQMECXvvt75B2j4wD+PsbZRF+X98KM8Kj+ryR++Env Ik9uX1kY13h8m2sSquMBAJHtK8qkVkmh6Ctx8dIchBXSVbQ8n/vh+QEoL8rsTt6o =eobA -----END PGP SIGNATURE----- --Signature=_Mon__1_Feb_2010_06_52_24_+0100_C6yZE4gbLGgYvS79-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 1 06:53:43 2010 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 DDA66106566C for ; Mon, 1 Feb 2010 06:53:43 +0000 (UTC) (envelope-from bermejator@hotmail.com) Received: from snt0-omc2-s23.snt0.hotmail.com (snt0-omc2-s23.snt0.hotmail.com [65.55.90.98]) by mx1.freebsd.org (Postfix) with ESMTP id B33F38FC08 for ; Mon, 1 Feb 2010 06:53:43 +0000 (UTC) Received: from SNT112-W43 ([65.55.90.73]) by snt0-omc2-s23.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 31 Jan 2010 22:41:42 -0800 Message-ID: X-Originating-IP: [83.61.11.151] From: Ruben Lara To: Date: Mon, 1 Feb 2010 06:41:42 +0000 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 01 Feb 2010 06:41:42.0597 (UTC) FILETIME=[9D80AF50:01CAA309] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Problem with Mergemaster and FreeBSD Service Jails 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, 01 Feb 2010 06:53:43 -0000 Hi all! I have several freebsd service jail like: http://www.freebsd.org/doc/en/boo= ks/handbook/jails-application.html I just upgrade world from RELENG_7_1 to RELENG_8. Now=2C i need to run mergemaster in each jail to updgrade configuration fil= es. My first attempts of mergemaster i get: ... *** Beginning comparison *** Checking /etc/rc.d for stale files *** No stale files found *** The installed file /etc has the type "symbolic link" but the new version has the type "directory" How would you like to handle this? Use 'r' to remove /etc You will be able to install it as a "directory" Use 'i' to ignore this How to proceed? [i] i *** See the man page about adding /etc to the list of IGNORE_FILES *** Press the [Enter] or [Return] key to continue=20 =20 And similar with other simlinks neccessary to run freebsd service jails: # ln -s s/etc etc # ln -s s/root root # ln -s s/home home # ln -s ../s/usr-local usr/local # ln -s ../s/usr-X11R6 usr/X11R6 # ln -s s/tmp tmp # ln -s s/var var I think mergemaster is not updating my configuration files=2C at end of pro= ccess i get (i ignore often): *** There is no installed version of ./.cshrc Use 'd' to delete the temporary ./.cshrc Use 'i' to install the temporary ./.cshrc Default is to leave the temporary file to deal with by hand How should I deal with this? [Leave it for later] i install: //.cshrc: Read-only file system *** FATAL ERROR: Unable to install ./.cshrc to / I never have this problem before=2C i have my jails running for years... Anybody can help me??? Thank you Rub=E9n Lara =20 _________________________________________________________________ =BFA=FAn sin la =FAltima versi=F3n de Internet Explorer 8? =A1Actual=EDzate= gratis! http://www.vivelive.com/internetexplorer8= From owner-freebsd-stable@FreeBSD.ORG Mon Feb 1 08:51:44 2010 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 89790106566B for ; Mon, 1 Feb 2010 08:51:44 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.freebsd.org (Postfix) with ESMTP id 18E2C8FC0A for ; Mon, 1 Feb 2010 08:51:43 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c122-106-232-148.belrs3.nsw.optusnet.com.au [122.106.232.148]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o118pesn002735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 1 Feb 2010 19:51:41 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id o118pWP5034925 for ; Mon, 1 Feb 2010 19:51:32 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id o118pWej034924 for freebsd-stable@freebsd.org; Mon, 1 Feb 2010 19:51:32 +1100 (EST) (envelope-from peter) Date: Mon, 1 Feb 2010 19:51:32 +1100 From: Peter Jeremy To: freebsd-stable@freebsd.org Message-ID: <20100201085131.GA34006@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Kernel probe order issues 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, 01 Feb 2010 08:51:44 -0000 --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Whilst trying to boot a brand new FreeBSD 8-stable/amd64 kernel, I ran into an unfortunate nasty with the kernel probe order. This particular box has no PS/2 ports so I have a USB keyboard and have removed atkbd et al from my kernel config. Unfortunately, whilst trying to merge changes from 5 different sources, I also accidently deleted my HDD controller. Quite reasonably, the lack of disk controller made the kernel spit out an error message and "mountroot>" prompt. Unfortunately, this occurs after the kernel has switched from BIOS to its own drivers but _before_ ukbd(4) is probed so I didn't have any keyboard. (Some experimenting with a serial console confirmed that ukbd is probed after the root device). This strikes me as undesirable. Is there some way to bump up the probe/attach priority of console input devices to ensure that they exist before the kernel tries to read input? --=20 Peter Jeremy --X1bOJ3K7DJ5YkBrT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAktmlhMACgkQ/opHv/APuId9TgCfaTNNF4s7WxBTrMVLHvJh10Ul 6pIAnApvDKTD6fVeST+wUQvhLaFXlOYL =B1ii -----END PGP SIGNATURE----- --X1bOJ3K7DJ5YkBrT-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 1 09:37:40 2010 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 705D010656E1 for ; Mon, 1 Feb 2010 09:37:40 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B32158FC1E for ; Mon, 1 Feb 2010 09:37:39 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA19832; Mon, 01 Feb 2010 11:37:35 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Nbsit-000H8C-8c; Mon, 01 Feb 2010 11:37:35 +0200 Message-ID: <4B66A0DD.2070109@icyb.net.ua> Date: Mon, 01 Feb 2010 11:37:33 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091128) MIME-Version: 1.0 To: Peter Jeremy References: <20100201085131.GA34006@server.vk2pj.dyndns.org> In-Reply-To: <20100201085131.GA34006@server.vk2pj.dyndns.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Kernel probe order issues 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, 01 Feb 2010 09:37:40 -0000 on 01/02/2010 10:51 Peter Jeremy said the following: > Whilst trying to boot a brand new FreeBSD 8-stable/amd64 kernel, > I ran into an unfortunate nasty with the kernel probe order. > > This particular box has no PS/2 ports so I have a USB keyboard and > have removed atkbd et al from my kernel config. Unfortunately, whilst > trying to merge changes from 5 different sources, I also accidently > deleted my HDD controller. Quite reasonably, the lack of disk > controller made the kernel spit out an error message and "mountroot>" > prompt. Unfortunately, this occurs after the kernel has switched from > BIOS to its own drivers but _before_ ukbd(4) is probed so I didn't > have any keyboard. (Some experimenting with a serial console > confirmed that ukbd is probed after the root device). > > This strikes me as undesirable. Is there some way to bump up the > probe/attach priority of console input devices to ensure that they > exist before the kernel tries to read input? It seems to be a problem with either your keyboard or your USB controller. USB keyboard can be discovered much earlier than mountroot if the hardware is ready. No magical software priority bump can help here. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Feb 1 14:49:54 2010 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 7BD3D1065693; Mon, 1 Feb 2010 14:49:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3778A8FC15; Mon, 1 Feb 2010 14:49:54 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id C376F46B38; Mon, 1 Feb 2010 09:49:53 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id CC1678A024; Mon, 1 Feb 2010 09:49:52 -0500 (EST) From: John Baldwin To: Marius Strobl Date: Mon, 1 Feb 2010 09:46:57 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <20100126073336.GA1955@server.vk2pj.dyndns.org> <20100131010618.GA1864@server.vk2pj.dyndns.org> <20100131162854.GC77522@alchemy.franken.de> In-Reply-To: <20100131162854.GC77522@alchemy.franken.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201002010946.57253.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 01 Feb 2010 09:49:52 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.3 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: rmacklem@freebsd.org, dfr@freebsd.org, freebsd-stable@freebsd.org, Peter Jeremy Subject: Re: uma_zalloc_arg complaining about non-sleepable locks 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, 01 Feb 2010 14:49:54 -0000 On Sunday 31 January 2010 11:28:54 am Marius Strobl wrote: > On Sun, Jan 31, 2010 at 12:06:18PM +1100, Peter Jeremy wrote: > > Sorry for the delay, I was trying to avoid rebooting my server. > > I've setup a similar environment in VirtualBox to test it. > > > > On 2010-Jan-27 12:52:29 +0100, Marius Strobl wrote: > > >Ah, I forgot that using nfsm_aligned() causes nfs_realign() to > > >be a NOP on architectures without strict alignment requirements > > >for performance reasons. That's generally fine but unfortunately > > >that way you don't actually exercise the code which caused the > > >problem before (unfortunately I still don't manage to hit the > > >unaligned case myself). > > > > >Could you please test with #ifdef __NO_STRICT_ALIGNMENT replaced > > >with #if 0 in sys/nfs/nfs_common.h? The vfs.nfs.realign_count > > >counter should also increase then. > > > > I'm not sure what triggers the unaligned case either - I tried > > roughly "tar -cf - -C /mnt/usr src | tar -xf - -C /mnt/tmp" and > > that caused some unaligned accesses (but also completely wedged > > the VBox host). I also tried copying a pile of files off my > > NFS client (FreeBSD-8.x/i386) and that also triggered some > > unaligned accesses without any errors being reported. > > > > Currently, I have: > > vfs.nfs.realign_count: 12 > > vfs.nfs.realign_test: 188817 > > > > I'd say that your patch works. > > John, are you okay with that patch? > http://people.freebsd.org/~marius/fha_extract_info_realign2.diff > > It's intention is to: > - Move nfs_realign() from the NFS client to the shared NFS code and > remove the NFS server version in order to reduce code duplication. > The shared version now uses a second parameter how, which is passed > on to m_get(9) and m_getcl(9) as the server used M_WAIT while the > client requires M_DONTWAIT, and replaces the the previously unused > parameter hsiz. > - Change nfs_realign() to use nfsm_aligned() so as with other NFS code > the alignment check isn't actually performed on platforms without > strict alignment requirements for performance reasons because as the > comment suggests only occasionally occurs with TCP. > - Change fha_extract_info() to use nfs_realign() with M_NOWAIT rather > than M_DONTWAIT because it's called with the RPC sp_lock held. > > The only downside of the shared nfs_realign() are the combined > SYSCTL counters but the fact we incremented them non-atomically > so far I think already indicates that their intention only is a > rough indication rather than exact values for client and server. This all sounds good to me, but isn't M_NOWAIT == M_DONTWAIT? Hmm, reading the code more closely, it looks like fha_extract_info() was using M_WAIT rather than M_DONTWAIT previously. Also, I think you should be careful to use M_DONTWAIT instead of M_NOWAIT for mbufs, so I would fix that in fha_extract_info(). -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Feb 1 16:23:23 2010 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 14E00106568B for ; Mon, 1 Feb 2010 16:23:23 +0000 (UTC) (envelope-from freebsd@insightbb.com) Received: from mxsf03.insightbb.com (mxsf03.insightbb.com [74.128.0.64]) by mx1.freebsd.org (Postfix) with ESMTP id BC8698FC1D for ; Mon, 1 Feb 2010 16:23:22 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.49,384,1262581200"; d="scan'208";a="791572011" Received: from unknown (HELO asav01.insightbb.com) ([172.31.249.123]) by mxsf03.insightbb.com with ESMTP; 01 Feb 2010 11:23:21 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAPmOZkvQLicL/2dsb2JhbACBM9kfgkWCAASGAQ X-IronPort-AV: E=Sophos;i="4.49,384,1262581200"; d="scan'208";a="243557936" Received: from 208-46-39-11.dia.static.qwest.net (HELO laptop2.stevenfriedrich.org) ([208.46.39.11]) by asavout01.insightbb.com with ESMTP; 01 Feb 2010 11:23:19 -0500 From: Steven Friedrich To: freebsd-stable@freebsd.org Date: Mon, 1 Feb 2010 11:23:13 -0500 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; i386; ; ) References: <201001300708.37683.freebsd@insightbb.com> <20100131225714.GA20108@icarus.home.lan> <201001311933.19254.freebsd@insightbb.com> In-Reply-To: <201001311933.19254.freebsd@insightbb.com> X-Face: i~b2iK'Z*tJ)pO9@6lJG=k7>N, V~YMq":Iwdl!m|A"g, N@)'|zb[{ Cc: Jeremy Chadwick Subject: Re: loading module sdhci causes panic 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, 01 Feb 2010 16:23:23 -0000 On Sunday 31 January 2010 07:33:19 pm Steven Friedrich wrote: > On Sunday 31 January 2010 05:57:14 pm Jeremy Chadwick wrote: > > On Sun, Jan 31, 2010 at 04:44:39PM -0500, Steven Friedrich wrote: > > > On Saturday 30 January 2010 08:56:06 am Bartosz Fabianowski wrote: > > > > > Can anyone verify that sdhci is compatible with FreeBSD 8? > > > > > > > > I loaded mmc, mmcsd, and sdhci when I first installed FreeBSD 8.0 > > > > without any problems. Since then, I have updated to -STABLE and put > > > > these three devices in my kernel configuration file. No problems > > > > either. It must be very recent breakage or some incompatibility with > > > > your particular hardware. > > > > > > > > - Bartosz > > > > > > When I add the three drivers to my kernel, I don't get a panic, but > > > when I insert an SD 1GB card, nothing happens. > > > > > > pciconf -lv reveals that the driver attached to my device: > > > > > > sdhci0@pci0:11:0:4: class=0x080500 card=0x3082103c chip=0x8034104c > > > rev=0x00 hdr=0x00 > > > vendor = 'Texas Instruments (TI)' > > > device = 'SDA Standard Compliant SD Host Controller (10981734)' > > > class = base peripheral > > > subclass = SD host controller > > > > > > I verified that this SD card is recognized by Windows XP. > > > > > > When I plug in a card, should some message appear on the console? Will > > > it auto-mount? > > > > Can you please post your entire kernel configuration file (specifically > > the one which includes the above 3 drivers in it)? > > # > # LAPTOP -- Laptop kernel configuration file for FreeBSD/i386 > # > > ident LAPTOP > machine i386 > cpu I586_CPU > cpu I686_CPU > > # To statically compile in device wiring instead of /boot/device.hints > #hints "LAPTOP.hints" # Default places to look for devices. > > makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols > > # hopefully, cure the shutdown anomaly > options PRINTF_BUFR_SIZE=128 > > options INCLUDE_CONFIG_FILE > > options SCHED_ULE # ULE scheduler > #options SCHED_4BSD # 4BSD scheduler > options PREEMPTION # Enable kernel thread preemption > # IPI_PREEMPTION instructs the kernel to preempt threads running on other > # CPUS if needed. Relies on the PREEMPTION option > options IPI_PREEMPTION > options INET # InterNETworking > options INET6 # IPv6 communications protocols > options SCTP # Stream Control Transmission Protocol > options FFS # Berkeley Fast Filesystem > options SOFTUPDATES # Enable FFS soft updates support > options UFS_ACL # Support for access control lists > options UFS_DIRHASH # Improve performance on big directories > options UFS_GJOURNAL # Enable gjournal-based UFS journaling > #options MD_ROOT # MD is a potential root device > options PROCFS # Process filesystem (requires PSEUDOFS) > options PSEUDOFS # Pseudo-filesystem framework > #options GEOM_GPT # GUID Partition Tables. > # The options COMPAT_43 kernel configuration option has been deemed > unnecessary and > # has been removed from GENERIC and related kernel configurations. This > change may > # result in a small performance increase for some workloads. > #options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] > options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] > options COMPAT_FREEBSD4 # Compatible with FreeBSD4 > options COMPAT_FREEBSD5 # Compatible with FreeBSD5 > options COMPAT_FREEBSD6 # Compatible with FreeBSD6 > options COMPAT_FREEBSD7 # Compatible with FreeBSD7 > options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI > options SYSVSHM # SYSV-style shared memory > options SYSVMSG # SYSV-style message queues > options SYSVSEM # SYSV-style semaphores > options P1003_1B_SEMAPHORES # POSIX-style semaphores > options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions > options KBD_INSTALL_CDEV # install a CDEV entry in /dev > #options ADAPTIVE_GIANT # Giant mutex is adaptive. > options SC_HISTORY_SIZE=1000 > options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) > options AUDIT # Security event auditing > options MAC # TrustedBSD MAC Framework > options FLOWTABLE # per-cpu routing cache > options KTRACE # ktrace(1) support > options STACK # stack(9) support > #options KDTRACE_HOOKS # Kernel DTrace hooks > # PERFMON causes the driver for Pentium/Pentium Pro performance counters > # to be compiled. See perfmon(4) for more information. > # > options PERFMON > > # To make an SMP kernel, the next line is needed > options SMP # Symmetric MultiProcessor Kernel > # The apic device enables the use of the I/O APIC for interrupt delivery. > # The apic device can be used in both UP and SMP kernels, but is required > # for SMP kernels. Thus, the apic device is not strictly an SMP option, > # but it is a prerequisite for SMP. > device apic # I/O APIC > > # ACPI extras driver for HP laptops > device acpi_hp > > # CPU frequency control > device cpufreq > > # > # Temperature sensors: > # > # coretemp: on-die sensor on Intel Core and newer CPUs > # > device coretemp > > # Bus support. > device pci > > # Floppy drives > #device fdc > > # ATA and ATAPI devices > device ata > device atadisk # ATA disk drives > device atapicd # ATAPI CDROM drives > #device atausb # ATA USB support > options ATA_STATIC_ID # Static device numbering > > # SCSI peripherals > device scbus # SCSI bus (required for SCSI) > device da # Direct Access (disks) > #device cd # CD > device pass # Passthrough device (direct SCSI access) > > # atkbdc0 controls both the keyboard and the PS/2 mouse > device atkbdc # AT keyboard controller > device atkbd # AT keyboard > device psm # PS/2 mouse > > device vga # VGA video card driver > > device splash # Splash screen and screen saver support > > # syscons is the default console driver, resembling an SCO console > device sc > > device agp # support several AGP chipsets > device drm # DRM core module required by DRM drivers > device radeondrm # ATI Radeon > > # Power management support (see NOTES for more options) > #device apm > # Add suspend/resume support for the i8254. > device pmtimer > > # PCCARD (PCMCIA) support > # PCMCIA and cardbus bridge support > device cbb # cardbus (yenta) bridge > device pccard # PC Card (16-bit) bus > device cardbus # CardBus (32-bit) bus > > # Serial (COM) ports > #device sio # 8250, 16[45]50 based serial ports > > # Parallel port > #device ppc > #device ppbus # Parallel port bus (required) > #device lpt # Printer > #device plip # TCP/IP over parallel > #device ppi # Parallel port interface device > #device vpo # Requires scbus and da > > # PCI Ethernet NICs that use the common MII bus controller code. > # NOTE: Be sure to keep the 'device miibus' line in order to use these > NICs! #device miibus # MII bus support > #device rl # RealTek 8129/8139 > > # Wireless NIC cards > #device wlan # 802.11 support > #device wlan_wep # 802.11 WEP support > #device wlan_ccmp # 802.11 CCMP support > #device wlan_tkip # 802.11 TKIP support > #device wlan_amrr # AMRR transmit rate control algorithm > # the scan code has been folded into the wlan module in FreeBSD8.0 > #device wlan_scan_ap # 802.11 AP mode scanning > #device wlan_scan_sta # 802.11 STA mode scanning > #device wlan_xauth # > #device an # Aironet 4500/4800 802.11 wireless NICs. > #device awi # BayStack 660 and others > #device ral # Ralink Technology RT2500 wireless NICs. > #device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. > > # Pseudo devices. > device loop # Network loopback > device random # Entropy device > device ether # Ethernet support > device tun # Packet tunnel. > device pty # Pseudo-ttys (telnet etc) > #device md # Memory "disks" > device gif # IPv6 and IPv4 tunneling > device faith # IPv6-to-IPv4 relaying (translation) > > # The `bpf' device enables the Berkeley Packet Filter. > # Be aware of the administrative consequences of enabling this! > # Note that 'bpf' is required for DHCP. > device bpf # Berkeley packet filter > > # USB support > device uhci # UHCI PCI->USB interface > device ohci # OHCI PCI->USB interface > device ehci # EHCI PCI->USB interface (USB 2.0) > device usb # USB Bus (required) > # ugen is gone from 8.0, must have been folded-in > #device ugen # Generic > # umass will conflict with atausb > # removed umass per advice from Predrag Punosevac > device umass # Disks/Mass storage - > Requires scbus and da > device ums # Mouse > #device ulpt # printers > > #device ucom # why isn't this listed in NOTES? > #device uplcom # IOgear (ATEN) usb serial adapter > > # USB Ethernet, requires miibus > #device axe # ASIX Electronics USB Ethernet > > # FireWire support > #device firewire # FireWire bus code > > device snd_ich > device sound > #device speaker > # see man acpi > #device acpi > # acpi_video can conflict with device agp > # ACPI Video Extensions (LCD backlight/brightness, video output, etc.) > #device acpi_video > options VESA > # Enable NDIS binary driver support > options NDISAPI > #device ndis > # Netgear WG111T supported as of 8.0, but load as module > #device uath # Atheros AR5523 wireless NICs > > device dcons # Dumb console driver > #device dcons_crom # Configuration ROM for dcons > > device smb > device smbus > device ichsmb > > # how about SD controller > device mmc > device mmcsd > device sdhci > _______________________________________________ > 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" > Let me reiterate that it doesn't panic when the three drivers are built into the kernel. It only panics when I use loader.conf or hand-load. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 1 16:43:59 2010 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 CC71F1065692; Mon, 1 Feb 2010 16:43:59 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 1DA888FC13; Mon, 1 Feb 2010 16:43:58 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKiTZkuDaFvK/2dsb2JhbADaaIRFBA X-IronPort-AV: E=Sophos;i="4.49,384,1262581200"; d="scan'208";a="63883269" Received: from fraser.cs.uoguelph.ca ([131.104.91.202]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 01 Feb 2010 11:43:57 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id 1FAED109C2E3; Mon, 1 Feb 2010 11:43:57 -0500 (EST) X-Virus-Scanned: amavisd-new at fraser.cs.uoguelph.ca Received: from fraser.cs.uoguelph.ca ([127.0.0.1]) by localhost (fraser.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7JlsjdxmOPk; Mon, 1 Feb 2010 11:43:56 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id 63AFA109C2E2; Mon, 1 Feb 2010 11:43:56 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o11GssM09446; Mon, 1 Feb 2010 11:54:54 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Mon, 1 Feb 2010 11:54:54 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: John Baldwin In-Reply-To: <201002010946.57253.jhb@freebsd.org> Message-ID: References: <20100126073336.GA1955@server.vk2pj.dyndns.org> <20100131010618.GA1864@server.vk2pj.dyndns.org> <20100131162854.GC77522@alchemy.franken.de> <201002010946.57253.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: rmacklem@freebsd.org, dfr@freebsd.org, freebsd-stable@freebsd.org, Peter Jeremy , Marius Strobl Subject: Re: uma_zalloc_arg complaining about non-sleepable locks 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, 01 Feb 2010 16:43:59 -0000 On Mon, 1 Feb 2010, John Baldwin wrote: >>> I'd say that your patch works. >> >> John, are you okay with that patch? >> http://people.freebsd.org/~marius/fha_extract_info_realign2.diff >> >> It's intention is to: >> - Move nfs_realign() from the NFS client to the shared NFS code and >> remove the NFS server version in order to reduce code duplication. >> The shared version now uses a second parameter how, which is passed >> on to m_get(9) and m_getcl(9) as the server used M_WAIT while the >> client requires M_DONTWAIT, and replaces the the previously unused >> parameter hsiz. I don't think the client side can use M_WAIT/M_WAITOK if it wants to. (I believe that it was once called from the socket upcall and that was why M_DONTWAIT was used, but that isn't how it is called in the client now.) I mentioned this to dfr@ because I use a version shared between client and server for the experimental one that does M_WAIT, but he didn't think the regular client needed to be changed. Basically, I think the current code in the regular client can return ENOMEM for I/O system calls, which probably isn't what the app. expected. In the NFS client, you end up with this "do I wait forever?" or "do I return an error to an I/O system call which an app. doesn't expect" issue cropping up here and there. I don't know the correct answer to this, but tend to lean in the "wait forever" direction. >> - Change nfs_realign() to use nfsm_aligned() so as with other NFS code >> the alignment check isn't actually performed on platforms without >> strict alignment requirements for performance reasons because as the >> comment suggests only occasionally occurs with TCP. >> - Change fha_extract_info() to use nfs_realign() with M_NOWAIT rather >> than M_DONTWAIT because it's called with the RPC sp_lock held. >> Btw, from an historical perspective, this was originally added for the DEC PMAX port (MIPS R2000), which would trap whenever an unaligned ptr was used. Then, there was this involved chunk of MIPS assembly code that worked around the unaligned ptr access and the trap returned. Obviously this was a major performance hit and happened fairly frequently for NFS over ISO TP4. As you've seen, it happens infrequently enough over TCP (back then, I think it was only when the TCP window size ended up really small, although I'm way out of date on the TCP stack, so I have no idea now:-) that I'd only do the re-alignment on achitectures that will crash if it isn't done? I missed the beginning of this. Was there crashes occurring because the alignment wasn't being done or problems because the alignment wasn't working correctly? (I guess I'm trying to say that, if the arch works without nfs_realign(), then you might consider just not doing it for that arch. I suppose that isn't a good enough reason to not fix the function, though?;-) >> The only downside of the shared nfs_realign() are the combined >> SYSCTL counters but the fact we incremented them non-atomically >> so far I think already indicates that their intention only is a >> rough indication rather than exact values for client and server. > I'll admit I don't see how NFSCLIENT and NFSSERVER can both be loaded as modules without the stuff in sys/nfs/nfs_common.c coming up multiply defined, but it seems to work, so... > This all sounds good to me, but isn't M_NOWAIT == M_DONTWAIT? Hmm, reading > the code more closely, it looks like fha_extract_info() was using M_WAIT > rather than M_DONTWAIT previously. Also, I think you should be careful to use > M_DONTWAIT instead of M_NOWAIT for mbufs, so I would fix that in > fha_extract_info(). > As noted above, I think the client can use M_WAIT safely. It was just a design choice to do otherwise. Have fun with it, rick From owner-freebsd-stable@FreeBSD.ORG Mon Feb 1 18:15:18 2010 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 4FE701065679 for ; Mon, 1 Feb 2010 18:15:18 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 038898FC25 for ; Mon, 1 Feb 2010 18:15:17 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Nc0nW-0004XQ-8y for freebsd-stable@freebsd.org; Mon, 01 Feb 2010 19:14:54 +0100 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, 01 Feb 2010 19:14:54 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 01 Feb 2010 19:14:54 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Mon, 01 Feb 2010 19:13:48 +0100 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: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.5) Gecko/20100118 Thunderbird/3.0 Sender: news Subject: terminfo missing? 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, 01 Feb 2010 18:15:18 -0000 Hi, This has bugged me on a couple of machines but I've always attributed it to some misconfiguration of mine: running curses-like programs under "screen" (i.e. in virtual screens) fails with messages like "terminal entry not found". For example, "less" does this, and "vim" complains with this: E558: Terminal entry not found in terminfo 'screen' not known. Available builtin terminals are: builtin_ansi builtin_xterm builtin_iris-ansi builtin_dumb defaulting to 'ansi' Looking at terminfo(5) it looks like terminfo should be located at /usr/share/misc/terminfo/ but I have no such directory here. There is a /usr/share/misc/termcap file. This machine is relatively fresh, only a source-based update was performed from 8.0-R to 8.0-STABLE, so I don't think there is some package that does this. Can someone enlight me about what is happening here? From owner-freebsd-stable@FreeBSD.ORG Mon Feb 1 18:42:53 2010 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 E93681065695 for ; Mon, 1 Feb 2010 18:42:53 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by mx1.freebsd.org (Postfix) with ESMTP id D277E8FC1B for ; Mon, 1 Feb 2010 18:42:53 +0000 (UTC) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta13.emeryville.ca.mail.comcast.net with comcast id ciEK1d0011wfjNsADiiuPt; Mon, 01 Feb 2010 18:42:54 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta23.emeryville.ca.mail.comcast.net with comcast id ciir1d0023S48mS8jiirkm; Mon, 01 Feb 2010 18:42:54 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id CA3241E3033; Mon, 1 Feb 2010 10:42:49 -0800 (PST) Date: Mon, 1 Feb 2010 10:42:49 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100201184249.GA46038@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: terminfo missing? 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, 01 Feb 2010 18:42:54 -0000 On Mon, Feb 01, 2010 at 07:13:48PM +0100, Ivan Voras wrote: > This has bugged me on a couple of machines but I've always > attributed it to some misconfiguration of mine: running curses-like > programs under "screen" (i.e. in virtual screens) fails with > messages like "terminal entry not found". For example, "less" does > this, and "vim" complains with this: > > E558: Terminal entry not found in terminfo > 'screen' not known. Available builtin terminals are: > builtin_ansi > builtin_xterm > builtin_iris-ansi > builtin_dumb > defaulting to 'ansi' > > Looking at terminfo(5) it looks like terminfo should be located at > /usr/share/misc/terminfo/ but I have no such directory here. There > is a /usr/share/misc/termcap file. > > This machine is relatively fresh, only a source-based update was > performed from 8.0-R to 8.0-STABLE, so I don't think there is some > package that does this. > > Can someone enlight me about what is happening here? Don't let the message from vim fool you; it says "Terminal entry not found in terminfo", but what it's really trying to tell you is "not found in termcap". It'll say "terminfo" no matter what. FreeBSD uses termcap, not terminfo. The definition for the "screen" termcap entry is in /usr/share/misc/termcap, which is what /etc/termcap is symlinked to. You should also have a /usr/share/misc/termcap.db file. I've no issues using vim, sade, sysinstall, less, etc. under screen on RELENG_7 or RELENG_8 machines. This is with TERM=screen as well (no dotfiles or environment settings overriding it). Do you have some sort of library on your machine which is trumping the ones in /usr/lib? Relevant linking: /usr/local/bin/vim: libm.so.5 => /lib/libm.so.5 (0x30781000) libncurses.so.8 => /lib/libncurses.so.8 (0x308a0000) libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x309ea000) libc.so.7 => /lib/libc.so.7 (0x30be3000) /usr/bin/less: libncurses.so.8 => /lib/libncurses.so.8 (0x3065e000) libc.so.7 => /lib/libc.so.7 (0x307a8000) -- | Jeremy Chadwick jdc@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 Feb 1 21:44:53 2010 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 4F3661065670 for ; Mon, 1 Feb 2010 21:44:53 +0000 (UTC) (envelope-from dan@svwh.net) Received: from mail.denetron.com (mail.denetron.com [IPv6:2001:470:1f05:148::2:2]) by mx1.freebsd.org (Postfix) with ESMTP id 387F68FC15 for ; Mon, 1 Feb 2010 21:44:53 +0000 (UTC) Received: from adsl-75-60-71-102.dsl.pltn13.sbcglobal.net ([75.60.71.102] helo=[192.168.1.72]) by mail.denetron.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nc44i-000FKh-GM for freebsd-stable@freebsd.org; Mon, 01 Feb 2010 21:44:52 +0000 From: Daniel Ballenger Content-Type: multipart/signed; boundary=Apple-Mail-4--1009316906; protocol="application/pkcs7-signature"; micalg=sha1 Date: Mon, 1 Feb 2010 13:44:51 -0800 Message-Id: To: freebsd-stable@freebsd.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Kernel Panic on Freebsd 8-RELEASE 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, 01 Feb 2010 21:44:53 -0000 --Apple-Mail-4--1009316906 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi all, A recent HLDS update is causing my machine to kernel panic. Here is a copy of the kernel dump: #0 sched_switch (td=3D0xffffffff80be7600, newtd=3D0xffffff00014f6720, = flags=3DVariable "flags" is not available. ) at /usr/src/sys/kern/sched_ule.c:1864 1864 cpuid =3D PCPU_GET(cpuid); (kgdb)=20 (kgdb) bt #0 sched_switch (td=3D0xffffffff80be7600, newtd=3D0xffffff00014f6720, = flags=3DVariable "flags" is not available. ) at /usr/src/sys/kern/sched_ule.c:1864 #1 0xffffffff805879bf in mi_switch (flags=3D260, newtd=3D0x0) at = /usr/src/sys/kern/kern_synch.c:449 #2 0xffffffff805b94a2 in sleepq_timedwait (wchan=3D0xffffffff80be71a0, = pri=3D68) at /usr/src/sys/kern/subr_sleepqueue.c:623 #3 0xffffffff80587f38 in _sleep (ident=3D0xffffffff80be71a0, lock=3D0x0, = priority=3DVariable "priority" is not available. ) at /usr/src/sys/kern/kern_synch.c:230 #4 0xffffffff807c7faa in scheduler (dummy=3DVariable "dummy" is not = available. ) at /usr/src/sys/vm/vm_glue.c:779 #5 0xffffffff8053a859 in mi_startup () at = /usr/src/sys/kern/init_main.c:251 #6 0xffffffff8018a33c in btext () at = /usr/src/sys/amd64/amd64/locore.S:81 #7 0x0000000000e74000 in ?? () #8 0x0000000000000000 in ?? () #9 0x0000000000000000 in ?? () #10 0xffffffff80c0c710 in sleepq_chains () #11 0xffffffff80be7600 in proc0 () #12 0xffffffff80e52be0 in ?? () #13 0xffffffff80e52b98 in ?? () #14 0xffffff00014f6720 in ?? () #15 0xffffffff805a2bd8 in sched_switch (td=3D0x0, newtd=3D0x0, = flags=3DVariable "flags" is not available. ) at /usr/src/sys/kern/sched_ule.c:1858 Previous frame inner to this frame (corrupt stack?) (kgdb) uname -a: FreeBSD dl0009.sjc02.denetron.net 8.0-RELEASE FreeBSD 8.0-RELEASE #0: = Thu Jan 28 05:36:57 UTC 2010 = root@dl0009.sjc02.denetron.net:/usr/obj/usr/src/sys/GENERIC amd64 The message displayed to the console: =95 Unread portion of the kernel message buffer: =95 panic: tdsignal(): invalid signal 0 =95 cpuid =3D 2 =95 Uptime: 6m52s =95 Physical memory: 4073 MB t_j in the ##freebsd channel on freenode asked me to do this so I'll = include it incase it's some help: (kgdb) frame 0 #0 sched_switch (td=3D0xffffffff80be7600, newtd=3D0xffffff00014f6720, = flags=3DVariable "flags" is not available. ) at /usr/src/sys/kern/sched_ule.c:1864 1864 cpuid =3D PCPU_GET(cpuid); (kgdb) list 1859 /* 1860 * We may return from cpu_switch on a different = cpu. However, 1861 * we always return with td_lock pointing to the = current cpu's 1862 * run queue lock. 1863 */ 1864 cpuid =3D PCPU_GET(cpuid); 1865 tdq =3D TDQ_CPU(cpuid); 1866 lock_profile_obtain_lock_success( 1867 &TDQ_LOCKPTR(tdq)->lock_object, 0, 0, = __FILE__, __LINE__); 1868 #ifdef HWPMC_HOOKS The crash is repeatable (occurs everytime for me). I also confirmed = that another FreeBSD 8 machine I have ran into the same panic (also = amd64). I'm guessing this is a bug of some kind, if there's more information I = need to provide, just let me know. Thanks, Daniel= --Apple-Mail-4--1009316906-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 02:14:10 2010 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 24DB1106566C for ; Tue, 2 Feb 2010 02:14:10 +0000 (UTC) (envelope-from dan@svwh.net) Received: from mail.denetron.com (mail.denetron.com [IPv6:2001:470:1f05:148::2:2]) by mx1.freebsd.org (Postfix) with ESMTP id DF1928FC19 for ; Tue, 2 Feb 2010 02:14:09 +0000 (UTC) Received: from c-67-169-80-163.hsd1.ca.comcast.net ([67.169.80.163] helo=[192.168.1.119]) by mail.denetron.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nc8HI-000MQR-Ss; Tue, 02 Feb 2010 02:14:09 +0000 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-11--993160891; protocol="application/pkcs7-signature"; micalg=sha1 From: Daniel Ballenger In-Reply-To: <4e6cba831002011421w6316ac6dx3e06a73ed35c7202@mail.gmail.com> Date: Mon, 1 Feb 2010 18:14:07 -0800 Message-Id: <70F28BB5-1472-4067-B0F5-52B84E337514@svwh.net> References: <4e6cba831002011421w6316ac6dx3e06a73ed35c7202@mail.gmail.com> To: Giovanni Trematerra X-Mailer: Apple Mail (2.1077) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Kernel Panic on Freebsd 8-RELEASE 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, 02 Feb 2010 02:14:10 -0000 --Apple-Mail-11--993160891 Content-Type: multipart/mixed; boundary=Apple-Mail-10--993161082 --Apple-Mail-10--993161082 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 1, 2010, at 2:21 PM, Giovanni Trematerra wrote: > On Mon, Feb 1, 2010 at 10:44 PM, Daniel Ballenger = wrote: >>=20 >>=20 >> The crash is repeatable (occurs everytime for me). I also confirmed = that another FreeBSD 8 machine I have ran into the same panic (also = amd64). >=20 > Hi Daniel, > Can you explain in more detail how to reproduce the crash, please? All I have to do is start the HLDS server process. For example, the = command used is: ./srcds_run -game tf -timeout 1 -port 27015 -pidfile srcds.pid > Can you obtain a textdump(4) and send to the list along with dmesg? I've attached the tar generated from ddb, it appears to include all the = dmesg text. > info about obtain a kernel dump are here > = http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html#K= ERNELDEBUG-OBTAIN >=20 > info on textdump are > http://www.freebsd.org/cgi/man.cgi?query=3Dtextdump&sourceid=3Dopensearc= h > = http://lists.freebsd.org/pipermail/freebsd-current/2007-December/081626.ht= ml >=20 > Thank you >=20 > -- > Gianni --Apple-Mail-10--993161082 Content-Disposition: attachment; filename=textdump.tar.1 Content-Type: application/octet-stream; x-unix-mode=0644; name="textdump.tar.1" Content-Transfer-Encoding: quoted-printable d= db.txt=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=000600=00=00=00=00= 0=00=00=00=00=00=00=000=00=00=00=00=00=00=00140000=00=00=00=00=00=00113317= 04434=00=20=207072=00=20= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00ustar=00=00=00root=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00wheel=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00db:0:kdb= .enter.panic>=20=20show=20pcpu=0Acpuid=20=20=20=20=20=20=20=20=3D=200=0A= dynamic=20pcpu=20=20=20=20=3D=200x2bb780=0Acurthread=20=20=20=20=3D=20= 0xffffff0006555390:=20pid=201932=20"srcds_i486"=0Acurpcb=20=20=20=20=20=20= =20=3D=200xffffff8079e81d40=0Afpcurthread=20=20=3D=200xffffff0006555390:=20= pid=201932=20"srcds_i486"=0Aidlethread=20=20=20=3D=200xffffff00014f6720:=20= pid=2011=20"idle:=20cpu0"=0Acurpmap=20=20=20=20=20=20=20=20=20=3D=200=0A= tssp=20=20=20=20=20=20=20=20=20=20=20=20=3D=200xffffffff80c84800=0A= commontssp=20=20=20=20=20=20=3D=200xffffffff80c84800=0Arsp0=20=20=20=20=20= =20=20=20=20=20=20=20=3D=200xffffff8079e81d40=0Ags32p=20=20=20=20=20=20=20= =20=20=20=20=3D=200xffffffff80c83638=0Aldt=20=20=20=20=20=20=20=20=20=20=20= =20=20=3D=200xffffffff80c83678=0Atss=20=20=20=20=20=20=20=20=20=20=20=20=20= =3D=200xffffffff80c83668=0Adb:0:kdb.enter.panic>=20trace=0ATracing=20pid=20= 1932=20tid=20100171=20td=200xffffff0006555390=0Akdb_enter()=20at=20= kdb_enter+0x3d=0Apanic()=20at=20panic+0x17b=0Atdsignal()=20at=20= tdsignal+0x6b6=0Alinux_do_tkill()=20at=20linux_do_tkill+0x1cb=0A= ia32_syscall()=20at=20ia32_syscall+0x236=0AXint0x80_syscall()=20at=20= Xint0x80_syscall+0x95=0A---=20syscall=20(270,=20Linux=20ELF32,=20= linux_tgkill),=20rip=20=3D=200x280b3ffe,=20rsp=20=3D=200x338ed0b0,=20rbp=20= =3D=200x338ed0b8=20---=0Adb:0:kdb.enter.panic>=20show=20locks=0ANo=20= such=20command=0Adb:0:kdb.enter.panic>=20ps=0A=20=20pid=20=20ppid=20=20= pgrp=20=20=20uid=20=20=20state=20=20=20wmesg=20=20=20=20=20=20=20=20=20= wchan=20=20=20=20=20=20=20=20cmd=0A=201932=20=201909=20=201908=20=202033=20= =20R+=20=20=20=20=20=20CPU=200=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20srcds_i486=0A=201931=20=201909=20=201908=20=20= 2033=20=20R+=20=20=20=20=20=20CPU=201=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20srcds_i486=0A=201930=20=201865=20=20= 1755=20=201003=20=20S=20=20=20=20=20=20=20select=20=20=20= 0xffffff00061af7c0=20php-cgi=0A=201923=20=201909=20=201908=20=202033=20=20= S+=20=20=20=20=20=20futex=20=20=20=200xffffff000171e9a0=20srcds_i486=0A=20= 1922=20=201909=20=201908=20=202033=20=20S+=20=20=20=20=20=20biord=20=20=20= =200xffffff80529a1860=20srcds_i486=0A=201909=20=201908=20=201908=20=20= 2033=20=20S+=20=20=20=20=20=20wait=20=20=20=20=200xffffff00068de460=20sh=0A= =201908=20=201907=20=201908=20=202033=20=20S+=20=20=20=20=20=20wait=20=20= =20=20=200xffffff00068f3460=20bash=0A=201907=20=201906=20=201907=20=20= 2033=20=20Ss+=20=20=20=20=20wait=20=20=20=20=200xffffff0006ffd000=20bash=0A= =201906=20=201904=20=201904=20=202033=20=20S=20=20=20=20=20=20=20select=20= =20=200xffffff00677749c0=20sshd=0A=201904=20=201779=20=201904=20=20=20=20= =200=20=20Ss=20=20=20=20=20=20sbwait=20=20=200xffffff0006f92144=20sshd=0A= =201898=20=201897=20=201898=20=20=20=20=200=20=20S+=20=20=20=20=20=20= ttyin=20=20=20=200xffffff0001d020a8=20bash=0A=201897=20=201863=20=201897=20= =201001=20=20S+=20=20=20=20=20=20wait=20=20=20=20=200xffffff00068dc000=20= su=0A=201868=20=201755=20=201755=20=20=20=2080=20=20S=20=20=20=20=20=20=20= kqread=20=20=200xffffff0006aa3e00=20httpd=0A=201865=20=201755=20=201755=20= =20=20=2080=20=20S=20=20=20=20=20=20=20kqread=20=20=200xffffff00061c1c00=20= httpd=0A=201863=20=201862=20=201863=20=201001=20=20Ss+=20=20=20=20=20= wait=20=20=20=20=200xffffff0006155000=20bash=0A=201862=20=201860=20=20= 1860=20=201001=20=20S=20=20=20=20=20=20=20select=20=20=20= 0xffffff0006403140=20sshd=0A=201860=20=201779=20=201860=20=20=20=20=200=20= =20Ss=20=20=20=20=20=20sbwait=20=20=200xffffff0006afb694=20sshd=0A=20= 1859=20=201755=20=201755=20=20=20=2080=20=20S=20=20=20=20=20=20=20lockf=20= =20=20=200xffffff0006400080=20httpd=0A=201858=20=201755=20=201755=20=20=20= =2080=20=20S=20=20=20=20=20=20=20lockf=20=20=20=200xffffff0006341380=20= httpd=0A=201857=20=201755=20=201755=20=20=20=2080=20=20S=20=20=20=20=20=20= =20lockf=20=20=20=200xffffff0006403180=20httpd=0A=201856=20=201755=20=20= 1755=20=20=20=2080=20=20S=20=20=20=20=20=20=20lockf=20=20=20=20= 0xffffff0006403700=20httpd=0A=201855=20=201755=20=201755=20=20=20=2080=20= =20S=20=20=20=20=20=20=20lockf=20=20=20=200xffffff0006342480=20httpd=0A=20= 1854=20=20=20=20=201=20=20=20=20=201=20=20=20=20=200=20=20S=20=20=20=20=20= =20=20ttydcd=20=20=200xffffff0004f40ce8=20getty=0A=201853=20=20=20=20=20= 1=20=201853=20=20=20=20=200=20=20Ss+=20=20=20=20=20ttyin=20=20=20=20= 0xffffff0004f734a8=20getty=0A=201852=20=20=20=20=201=20=201852=20=20=20=20= =200=20=20Ss+=20=20=20=20=20ttyin=20=20=20=200xffffff0004f674a8=20getty=0A= =201851=20=20=20=20=201=20=201851=20=20=20=20=200=20=20Ss+=20=20=20=20=20= ttyin=20=20=20=200xffffff0004f69ca8=20getty=0A=201850=20=20=20=20=201=20=20= 1850=20=20=20=20=200=20=20Ss+=20=20=20=20=20ttyin=20=20=20=20= 0xffffff0004f670a8=20getty=0A=201849=20=20=20=20=201=20=201849=20=20=20=20= =200=20=20Ss+=20=20=20=20=20ttyin=20=20=20=200xffffff0004f684a8=20getty=0A= =201848=20=20=20=20=201=20=201848=20=20=20=20=200=20=20Ss+=20=20=20=20=20= ttyin=20=20=20=200xffffff0004f530a8=20getty=0A=201847=20=20=20=20=201=20=20= 1847=20=20=20=20=200=20=20Ss+=20=20=20=20=20ttyin=20=20=20=20= 0xffffff0004f690a8=20getty=0A=201846=20=20=20=20=201=20=201846=20=20=20=20= =200=20=20Ss+=20=20=20=20=20ttyin=20=20=20=200xffffff0004f6a4a8=20getty=0A= =201819=20=20=20=20=201=20=201819=20=20=20=20=200=20=20Ss=20=20=20=20=20=20= select=20=20=200xffffff00063419c0=20inetd=0A=201788=20=20=20=20=201=20=20= 1788=20=20=20=20=200=20=20Ss=20=20=20=20=20=20nanslp=20=20=20= 0xffffffff80c16b28=20cron=0A=201779=20=20=20=20=201=20=201779=20=20=20=20= =200=20=20Ss=20=20=20=20=20=20select=20=20=200xffffff0006342ac0=20sshd=0A= =201755=20=20=20=20=201=20=201755=20=20=20=20=200=20=20Ss=20=20=20=20=20=20= select=20=20=200xffffff00063421c0=20httpd=0A=201672=20=20=20=20=201=20=20= 1672=20=20=20=20=200=20=20Ss=20=20=20=20=20=20select=20=20=20= 0xffffff00063416c0=20ntpd=0A=201614=20=20=20=20=201=20=201613=20=20=20=20= =200=20=20S=20=20=20=20=20=20=20nanslp=20=20=200xffffffff80c16b28=20= smartd=0A=201604=20=20=20=20=201=20=201603=20=20=20=20=200=20=20S=20=20=20= =20=20=20=20select=20=20=200xffffff0006340dc0=20snmpd=0A=201594=20=20=20=20= =201=20=201594=20=20=20=20=200=20=20Ss=20=20=20=20=20=20select=20=20=20= 0xffffff00061aecc0=20pure-ftpd=0A=201572=20=201571=20=201571=20=20=20=20=20= 0=20=20S=20=20=20=20=20=20=20(threaded)=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20nfsd=0A100154=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20S=20=20=20=20=20=20=20rpcsvc=20=20=200xffffff00061fc8a0=20= nfsd:=20service=0A100153=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20S=20=20=20=20=20=20=20rpcsvc=20=20=200xffffff00061fc920=20nfsd:=20= service=0A100152=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= S=20=20=20=20=20=20=20rpcsvc=20=20=200xffffff00061fc9a0=20nfsd:=20= service=0A100143=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= S=20=20=20=20=20=20=20rpcsvc=20=20=200xffffff000678ad20=20nfsd:=20master=0A= =201571=20=20=20=20=201=20=201571=20=20=20=20=200=20=20Ss=20=20=20=20=20=20= select=20=20=200xffffff000678b140=20nfsd=0A=201569=20=20=20=20=201=20=20= 1569=20=20=20=20=200=20=20Ss=20=20=20=20=20=20select=20=20=20= 0xffffff0006168dc0=20mountd=0A=201548=20=20=20=20=201=20=201548=20=20=20=20= =200=20=20Ss=20=20=20=20=20=20select=20=20=200xffffff00067894c0=20= rpcbind=0A=201434=20=20=20=20=201=20=201434=20=20=20=20=200=20=20Ss=20=20= =20=20=20=20select=20=20=200xffffff000678b240=20syslogd=0A=201210=20=20=20= =20=201=20=201210=20=20=20=20=200=20=20Ss=20=20=20=20=20=20select=20=20=20= 0xffffff00061036c0=20devd=0A=201067=20=20=20=20=201=20=201067=20=20=20=20= =200=20=20Ss=20=20=20=20=20=20select=20=20=200xffffff00061ae8c0=20moused=0A= =20=20746=20=20=20=20=200=20=20=20=20=200=20=20=20=20=200=20=20SL=20=20=20= =20=20=20pftm=20=20=20=20=200xffffffff8104db70=20[pfpurge]=0A=20=20=2019=20= =20=20=20=200=20=20=20=20=200=20=20=20=20=200=20=20SL=20=20=20=20=20=20= flowclea=200xffffffff80c3b290=20[flowcleaner]=0A=20=20=2018=20=20=20=20=20= 0=20=20=20=20=200=20=20=20=20=200=20=20SL=20=20=20=20=20=20sdflush=20=20= 0xffffffff80c4a218=20[softdepflush]=0A=20=20=2017=20=20=20=20=200=20=20=20= =20=200=20=20=20=20=200=20=20SL=20=20=20=20=20=20vlruwt=20=20=20= 0xffffff00061588c0=20[vnlru]=0A=20=20=2016=20=20=20=20=200=20=20=20=20=20= 0=20=20=20=20=200=20=20SL=20=20=20=20=20=20syncer=20=20=20= 0xffffffff80c3afe0=20[syncer]=0A=20=20=2015=20=20=20=20=200=20=20=20=20=20= 0=20=20=20=20=200=20=20SL=20=20=20=20=20=20psleep=20=20=20= 0xffffffff80c3ab08=20[bufdaemon]=0A=20=20=20=209=20=20=20=20=200=20=20=20= =20=200=20=20=20=20=200=20=20SL=20=20=20=20=20=20pgzero=20=20=20= 0xffffffff80c4bcac=20[pagezero]=0A=20=20=20=208=20=20=20=20=200=20=20=20=20= =200=20=20=20=20=200=20=20SL=20=20=20=20=20=20psleep=20=20=20= 0xffffffff80c4b048=20[vmdaemon]=0A=20=20=20=207=20=20=20=20=200=20=20=20=20= =200=20=20=20=20=200=20=20SL=20=20=20=20=20=20psleep=20=20=20= 0xffffffff80c4b00c=20[pagedaemon]=0A=20=20=2014=20=20=20=20=200=20=20=20=20= =200=20=20=20=20=200=20=20SL=20=20=20=20=20=20(threaded)=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20usb=0A100077=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20=20= =200xffffff8000418dd0=20[usbus7]=0A100076=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffff8000418d78=20[usbus7]=0A100075=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffff8000418d20=20[usbus7]=0A100074=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffff8000418cc8=20[usbus7]=0A100073=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffff800040fef0=20[usbus6]=0A100072=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffff800040fe98=20[usbus6]=0A100071=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffff800040fe40=20[usbus6]=0A100070=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffff800040fde8=20[usbus6]=0A100069=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffff8000406ef0=20[usbus5]=0A100068=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffff8000406e98=20[usbus5]=0A100067=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffff8000406e40=20[usbus5]=0A100066=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffff8000406de8=20[usbus5]=0A100065=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffff80003fdef0=20[usbus4]=0A100064=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffff80003fde98=20[usbus4]=0A100063=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffff80003fde40=20[usbus4]=0A100062=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffff80003fdde8=20[usbus4]=0A100061=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffff80003f4dd0=20[usbus3]=0A100060=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffff80003f4d78=20[usbus3]=0A100059=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffff80003f4d20=20[usbus3]=0A100058=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffff80003f4cc8=20[usbus3]=0A100057=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffff80003ebef0=20[usbus2]=0A100056=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffff80003ebe98=20[usbus2]=0A100055=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffff80003ebe40=20[usbus2]=0A100054=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffff80003ebde8=20[usbus2]=0A100053=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffff80003e2ef0=20[usbus1]=0A100052=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffff80003e2e98=20[usbus1]=0A100051=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffff80003e2e40=20[usbus1]=0A100050=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffff80003e2de8=20[usbus1]=0A100049=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffff80003d9ef0=20[usbus0]=0A100048=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffff80003d9e98=20[usbus0]=0A100047=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffff80003d9e40=20[usbus0]=0A100046=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffff80003d9de8=20[usbus0]=0A=20=20=20=206=20=20=20=20=200=20=20=20=20= =200=20=20=20=20=200=20=20SL=20=20=20=20=20=20waiting_=20= 0xffffffff80c3dfa0=20[sctp_iterator]=0A=20=20=20=205=20=20=20=20=200=20=20= =20=20=200=20=20=20=20=200=20=20SL=20=20=20=20=20=20ccb_scan=20= 0xffffffff80be02e0=20[xpt_thrd]=0A=20=20=2013=20=20=20=20=200=20=20=20=20= =200=20=20=20=20=200=20=20SL=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffffff80c16804=20[yarrow]=0A=20=20=20=204=20=20=20=20=200=20=20=20=20= =200=20=20=20=20=200=20=20SL=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffffff80c13008=20[g_down]=0A=20=20=20=203=20=20=20=20=200=20=20=20=20= =200=20=20=20=20=200=20=20SL=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffffff80c13000=20[g_up]=0A=20=20=20=202=20=20=20=20=200=20=20=20=20=20= 0=20=20=20=20=200=20=20SL=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffffff80c12ff0=20[g_event]=0A=20=20=2012=20=20=20=20=200=20=20=20=20=20= 0=20=20=20=20=200=20=20WL=20=20=20=20=20=20(threaded)=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20intr=0A100044=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20I=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[irq1:=20= atkbd0]=0A100043=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= I=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[swi0:=20uart=20uart+]=0A100042=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20I=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20[irq262:=20ahci0]=0A100041=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20I=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[irq23:=20uhci3=20ehci1]=0A= 100040=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20I=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20[irq18:=20ehci0=20uhci5]=0A100039=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20I=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [irq19:=20uhci2=20uhci4]=0A100038=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20I=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[irq21:=20uhci1]=0A= 100037=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20I=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20[irq16:=20uhci0]=0A100036=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20I=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[irq261:=20= em1]=0A100035=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20I=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20[irq260:=20em1]=0A100034=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20I=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [irq259:=20em1]=0A100032=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20I=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20[irq258:=20em0]=0A100031=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20I=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20[irq257:=20em0]=0A100030=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20I=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20[irq256:=20em0]=0A100028=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20I=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20[irq9:=20acpi0]=0A100027=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20I=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[swi2:=20cambio]=0A100024=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20I=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20[swi6:=20task=20queue]=0A100023=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20I=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[swi6:=20= Giant=20taskq]=0A100021=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20I=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20[swi5:=20+]=0A100012=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20I=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [swi1:=20netisr=200]=0A100011=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20I=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[swi3:=20vm]=0A100010=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20I=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20[swi4:=20clock]=0A100009=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20I=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[swi4:=20clock]=0A100008=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20I=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20[swi4:=20clock]=0A100007=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20I=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[swi4:=20clock]=0A=20=20=20= 11=20=20=20=20=200=20=20=20=20=200=20=20=20=20=200=20=20RL=20=20=20=20=20= =20(threaded)=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20idle=0A= 100006=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20CanRun=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20[idle:=20cpu0]=0A100005=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20CanRun=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20[idle:=20cpu1]=0A100004=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20Run=20=20=20=20=20CPU=202=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[idle:=20= cpu2]=0A100003=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Run=20=20=20=20=20CPU=203=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20[idle:=20cpu3]=0A=20=20=20=201=20=20=20=20=200=20=20= =20=20=201=20=20=20=20=200=20=20SLs=20=20=20=20=20wait=20=20=20=20=20= 0xffffff00014e78c0=20[init]=0A=20=20=2010=20=20=20=20=200=20=20=20=20=20= 0=20=20=20=20=200=20=20SL=20=20=20=20=20=20audit_wo=200xffffffff80c49570=20= [audit]=0A=20=20=20=200=20=20=20=20=200=20=20=20=20=200=20=20=20=20=200=20= =20SLs=20=20=20=20=20(threaded)=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20kernel=0A100033=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffff000170fc00=20[em1=20taskq]=0A100029=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffff0001712000=20[em0=20taskq]=0A100025=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20=20=20= 0xffffff0001618800=20[kqueue=20taskq]=0A100022=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20=20= =200xffffff0001618a80=20[thread=20taskq]=0A100020=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20= =20=200xffffff000163f180=20[acpi_task_2]=0A100019=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20= =20=200xffffff000163f180=20[acpi_task_1]=0A100018=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20= =20=200xffffff000163f180=20[acpi_task_0]=0A100013=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20D=20=20=20=20=20=20=20-=20=20=20=20=20=20= =20=200xffffff00014e4e00=20[firmware=20taskq]=0A100000=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20D=20=20=20=20=20=20=20sched=20=20=20=20= 0xffffffff80c13100=20[swapper]=0Adb:0:kdb.enter.panic>=20alltrace=0A=0A= Tracing=20command=20srcds_i486=20pid=201932=20tid=20100171=20td=20= 0xffffff0006555390=0Akdb_enter()=20at=20kdb_enter+0x3d=0Apanic()=20at=20= panic+0x17b=0Atdsignal()=20at=20tdsignal+0x6b6=0Alinux_do_tkill()=20at=20= linux_do_tkill+0x1cb=0Aia32_syscall()=20at=20ia32_syscall+0x236=0A= Xint0x80_syscall()=20at=20Xint0x80_syscall+0x95=0A---=20syscall=20(270,=20= Linux=20ELF32,=20linux_tgkill),=20rip=20=3D=200x280b3ffe,=20rsp=20=3D=20= 0x338ed0b0,=20rbp=20=3D=200x338ed0b8=20---=0A=0ATracing=20command=20= srcds_i486=20pid=201931=20tid=20100107=20td=200xffffff000658a390=0A= cpustop_handler()=20at=20cpustop_handler+0x40=0Aipi_nmi_handler()=20at=20= ipi_nmi_handler+0x30=0Atrap()=20at=20trap+0x26b=0Anmi_calltrap()=20at=20= nmi_calltrap+0x8=0A---=20trap=200x13,=20rip=20=3D=200xffffffff805f0c60,=20= rsp=20=3D=200xffffff8000018fe0,=20rbp=20=3D=200xffffff8079d41880=20---=0A= sopoll_generic()=20at=20sopoll_generic+0x40=0Akern_select()=20at=20= kern_select+0x4f2=0Alinux_select()=20at=20linux_select+0x101=0A= ia32_syscall()=20at=20ia32_syscall+0x236=0AXint0x80_syscall()=20at=20= Xint0x80_syscall+0x95=0A---=20syscall=20(142,=20Linux=20ELF32,=20= linux_select),=20rip=20=3D=200x281a1547,=20rsp=20=3D=200x38ac3f8c,=20rbp=20= =3D=200x38ac4078=20---=0A=0ATracing=20command=20php-cgi=20pid=201930=20= tid=20100172=20td=200xffffff0006555000=0Asched_switch()=20at=20= sched_switch+0xf8=0Ami_switch()=20at=20mi_switch+0x16f=0A= sleepq_catch_signals()=20at=20sleepq_catch_signals+0x31f=0A= sleepq_timedwait_sig()=20at=20sleepq_timedwait_sig+0x19=0A= _cv_timedwait_sig()=20at=20_cv_timedwait_sig+0x129=0Aseltdwait()=20at=20= seltdwait+0x8d=0Apoll()=20at=20poll+0x2f8=0Asyscall()=20at=20= syscall+0x246=0AXfast_syscall()=20at=20Xfast_syscall+0xe1=0A---=20= syscall=20(209,=20FreeBSD=20ELF64,=20poll),=20rip=20=3D=200x8011955ec,=20= rsp=20=3D=200x7ffffffeef88,=20rbp=20=3D=200x3=20---=0A=0ATracing=20= command=20srcds_i486=20pid=201923=20tid=20100113=20td=20= 0xffffff000627a720=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_catch_signals()=20at=20= sleepq_catch_signals+0x31f=0Asleepq_timedwait_sig()=20at=20= sleepq_timedwait_sig+0x19=0A_sleep()=20at=20_sleep+0x1a3=0A= linux_sys_futex()=20at=20linux_sys_futex+0x503=0Aia32_syscall()=20at=20= ia32_syscall+0x236=0AXint0x80_syscall()=20at=20Xint0x80_syscall+0x95=0A= ---=20syscall=20(240,=20Linux=20ELF32,=20linux_sys_futex),=20rip=20=3D=20= 0x280b3278,=20rsp=20=3D=200x2e5aa184,=20rbp=20=3D=200x2e5aa1ec=20---=0A=0A= Tracing=20command=20srcds_i486=20pid=201922=20tid=20100173=20td=20= 0xffffff0006554ab0=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_wait()=20at=20= sleepq_wait+0x42=0A_sleep()=20at=20_sleep+0x31c=0Abwait()=20at=20= bwait+0x64=0Abufwait()=20at=20bufwait+0x56=0Abread()=20at=20bread+0x1e=0A= ffs_vgetf()=20at=20ffs_vgetf+0x2d4=0Aufs_lookup_()=20at=20= ufs_lookup_+0xb87=0Avfs_cache_lookup()=20at=20vfs_cache_lookup+0xf0=0A= VOP_LOOKUP_APV()=20at=20VOP_LOOKUP_APV+0x40=0Alookup()=20at=20= lookup+0x40a=0Anamei()=20at=20namei+0x50e=0Avn_open_cred()=20at=20= vn_open_cred+0x3be=0Akern_openat()=20at=20kern_openat+0x179=0A= linux_common_open()=20at=20linux_common_open+0xfe=0Alinux_open()=20at=20= linux_open+0x53=0Aia32_syscall()=20at=20ia32_syscall+0x236=0A= Xint0x80_syscall()=20at=20Xint0x80_syscall+0x95=0A---=20syscall=20(5,=20= Linux=20ELF32,=20linux_open),=20rip=20=3D=200x28198181,=20rsp=20=3D=20= 0xffff1db8,=20rbp=20=3D=200xffff1e0c=20---=0A=0ATracing=20command=20sh=20= pid=201909=20tid=20100141=20td=200xffffff00065ea390=0Asched_switch()=20= at=20sched_switch+0xf8=0Ami_switch()=20at=20mi_switch+0x16f=0A= sleepq_catch_signals()=20at=20sleepq_catch_signals+0x31f=0A= sleepq_wait_sig()=20at=20sleepq_wait_sig+0xc=0A_sleep()=20at=20= _sleep+0x26b=0Akern_wait()=20at=20kern_wait+0x77e=0Await4()=20at=20= wait4+0x35=0Asyscall()=20at=20syscall+0x246=0AXfast_syscall()=20at=20= Xfast_syscall+0xe1=0A---=20syscall=20(7,=20FreeBSD=20ELF64,=20wait4),=20= rip=20=3D=200x800935edc,=20rsp=20=3D=200x7fffffffe088,=20rbp=20=3D=20= 0x774=20---=0A=0ATracing=20command=20bash=20pid=201908=20tid=20100168=20= td=200xffffff0006aa9390=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_catch_signals()=20at=20= sleepq_catch_signals+0x31f=0Asleepq_wait_sig()=20at=20= sleepq_wait_sig+0xc=0A_sleep()=20at=20_sleep+0x26b=0Akern_wait()=20at=20= kern_wait+0x77e=0Await4()=20at=20wait4+0x35=0Asyscall()=20at=20= syscall+0x246=0AXfast_syscall()=20at=20Xfast_syscall+0xe1=0A---=20= syscall=20(7,=20FreeBSD=20ELF64,=20wait4),=20rip=20=3D=200x800b9bedc,=20= rsp=20=3D=200x7fffffffe5c8,=20rbp=20=3D=200x800e37140=20---=0A=0ATracing=20= command=20bash=20pid=201907=20tid=20100180=20td=200xffffff0006553000=0A= sched_switch()=20at=20sched_switch+0xf8=0Ami_switch()=20at=20= mi_switch+0x16f=0Asleepq_catch_signals()=20at=20= sleepq_catch_signals+0x31f=0Asleepq_wait_sig()=20at=20= sleepq_wait_sig+0xc=0A_sleep()=20at=20_sleep+0x26b=0Akern_wait()=20at=20= kern_wait+0x77e=0Await4()=20at=20wait4+0x35=0Asyscall()=20at=20= syscall+0x246=0AXfast_syscall()=20at=20Xfast_syscall+0xe1=0A---=20= syscall=20(7,=20FreeBSD=20ELF64,=20wait4),=20rip=20=3D=200x800b9bedc,=20= rsp=20=3D=200x7fffffffe8a8,=20rbp=20=3D=200x800e68d20=20---=0A=0ATracing=20= command=20sshd=20pid=201906=20tid=20100123=20td=200xffffff000658f000=0A= sched_switch()=20at=20sched_switch+0xf8=0Ami_switch()=20at=20= mi_switch+0x16f=0Asleepq_catch_signals()=20at=20= sleepq_catch_signals+0x31f=0Asleepq_wait_sig()=20at=20= sleepq_wait_sig+0xc=0A_cv_wait_sig()=20at=20_cv_wait_sig+0x120=0A= seltdwait()=20at=20seltdwait+0xf6=0Akern_select()=20at=20= kern_select+0x62f=0Aselect()=20at=20select+0x5d=0Asyscall()=20at=20= syscall+0x246=0AXfast_syscall()=20at=20Xfast_syscall+0xe1=0A---=20= syscall=20(93,=20FreeBSD=20ELF64,=20select),=20rip=20=3D=200x8013d772c,=20= rsp=20=3D=200x7fffffffdcb8,=20rbp=20=3D=200x7fffffffdd40=20---=0A=0A= Tracing=20command=20sshd=20pid=201904=20tid=20100183=20td=20= 0xffffff0067771390=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_catch_signals()=20at=20= sleepq_catch_signals+0x31f=0Asleepq_wait_sig()=20at=20= sleepq_wait_sig+0xc=0A_sleep()=20at=20_sleep+0x26b=0Asoreceive_generic()=20= at=20soreceive_generic+0xebe=0Adofileread()=20at=20dofileread+0xa1=0A= kern_readv()=20at=20kern_readv+0x60=0Aread()=20at=20read+0x55=0A= syscall()=20at=20syscall+0x246=0AXfast_syscall()=20at=20= Xfast_syscall+0xe1=0A---=20syscall=20(3,=20FreeBSD=20ELF64,=20read),=20= rip=20=3D=200x8013d77ac,=20rsp=20=3D=200x7fffffffdcd8,=20rbp=20=3D=200=20= ---=0A=0ATracing=20command=20bash=20pid=201898=20tid=20100109=20td=20= 0xffffff000658fab0=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_catch_signals()=20at=20= sleepq_catch_signals+0x31f=0Asleepq_wait_sig()=20at=20= sleepq_wait_sig+0xc=0A_cv_wait_sig()=20at=20_cv_wait_sig+0x120=0A= tty_wait()=20at=20tty_wait+0x25=0Attydisc_read()=20at=20= ttydisc_read+0x2b1=0Attydev_read()=20at=20ttydev_read+0x10e=0A= devfs_read_f()=20at=20devfs_read_f+0x86=0Adofileread()=20at=20= dofileread+0xa1=0Akern_readv()=20at=20kern_readv+0x60=0Aread()=20at=20= read+0x55=0Asyscall()=20at=20syscall+0x246=0AXfast_syscall()=20at=20= Xfast_syscall+0xe1=0A---=20syscall=20(3,=20FreeBSD=20ELF64,=20read),=20= rip=20=3D=200x800c237ac,=20rsp=20=3D=200x7fffffffd978,=20rbp=20=3D=20= 0x7fffffffd997=20---=0A=0ATracing=20command=20su=20pid=201897=20tid=20= 100148=20td=200xffffff00065e9720=0Asched_switch()=20at=20= sched_switch+0xf8=0Ami_switch()=20at=20mi_switch+0x16f=0A= sleepq_catch_signals()=20at=20sleepq_catch_signals+0x31f=0A= sleepq_wait_sig()=20at=20sleepq_wait_sig+0xc=0A_sleep()=20at=20= _sleep+0x26b=0Akern_wait()=20at=20kern_wait+0x77e=0Await4()=20at=20= wait4+0x35=0Asyscall()=20at=20syscall+0x246=0AXfast_syscall()=20at=20= Xfast_syscall+0xe1=0A---=20syscall=20(7,=20FreeBSD=20ELF64,=20wait4),=20= rip=20=3D=200x8009e8edc,=20rsp=20=3D=200x7fffffffe5f8,=20rbp=20=3D=20= 0x76a=20---=0A=0ATracing=20command=20httpd=20pid=201868=20tid=20100160=20= td=200xffffff0006845390=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_catch_signals()=20at=20= sleepq_catch_signals+0x31f=0Asleepq_timedwait_sig()=20at=20= sleepq_timedwait_sig+0x19=0A_sleep()=20at=20_sleep+0x1a3=0Akern_kevent()=20= at=20kern_kevent+0x369=0Akevent()=20at=20kevent+0x90=0Asyscall()=20at=20= syscall+0x246=0AXfast_syscall()=20at=20Xfast_syscall+0xe1=0A---=20= syscall=20(363,=20FreeBSD=20ELF64,=20kevent),=20rip=20=3D=200x8011569dc,=20= rsp=20=3D=200x7fffffffe9b8,=20rbp=20=3D=200x7fffffffea7c=20---=0A=0A= Tracing=20command=20httpd=20pid=201865=20tid=20100159=20td=20= 0xffffff0006845720=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_catch_signals()=20at=20= sleepq_catch_signals+0x31f=0Asleepq_timedwait_sig()=20at=20= sleepq_timedwait_sig+0x19=0A_sleep()=20at=20_sleep+0x1a3=0Akern_kevent()=20= at=20kern_kevent+0x369=0Akevent()=20at=20kevent+0x90=0Asyscall()=20at=20= syscall+0x246=0AXfast_syscall()=20at=20Xfast_syscall+0xe1=0A---=20= syscall=20(363,=20FreeBSD=20ELF64,=20kevent),=20rip=20=3D=200x8011569dc,=20= rsp=20=3D=200x7fffffffc698,=20rbp=20=3D=200x804eccda0=20---=0A=0ATracing=20= command=20bash=20pid=201863=20tid=20100090=20td=200xffffff000615b000=0A= sched_switch()=20at=20sched_switch+0xf8=0Ami_switch()=20at=20= mi_switch+0x16f=0Asleepq_catch_signals()=20at=20= sleepq_catch_signals+0x31f=0Asleepq_wait_sig()=20at=20= sleepq_wait_sig+0xc=0A_sleep()=20at=20_sleep+0x26b=0Akern_wait()=20at=20= kern_wait+0x77e=0Await4()=20at=20wait4+0x35=0Asyscall()=20at=20= syscall+0x246=0AXfast_syscall()=20at=20Xfast_syscall+0xe1=0A---=20= syscall=20(7,=20FreeBSD=20ELF64,=20wait4),=20rip=20=3D=200x800b9bedc,=20= rsp=20=3D=200x7fffffffe888,=20rbp=20=3D=200x800e54d00=20---=0A=0ATracing=20= command=20sshd=20pid=201862=20tid=20100100=20td=200xffffff000615a000=0A= sched_switch()=20at=20sched_switch+0xf8=0Ami_switch()=20at=20= mi_switch+0x16f=0Asleepq_catch_signals()=20at=20= sleepq_catch_signals+0x31f=0Asleepq_wait_sig()=20at=20= sleepq_wait_sig+0xc=0A_cv_wait_sig()=20at=20_cv_wait_sig+0x120=0A= seltdwait()=20at=20seltdwait+0xf6=0Akern_select()=20at=20= kern_select+0x62f=0Aselect()=20at=20select+0x5d=0Asyscall()=20at=20= syscall+0x246=0AXfast_syscall()=20at=20Xfast_syscall+0xe1=0A---=20= syscall=20(93,=20FreeBSD=20ELF64,=20select),=20rip=20=3D=200x8013d772c,=20= rsp=20=3D=200x7fffffffdcb8,=20rbp=20=3D=200x7fffffffdd40=20---=0A=0A= Tracing=20command=20sshd=20pid=201860=20tid=20100161=20td=20= 0xffffff0006845000=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_catch_signals()=20at=20= sleepq_catch_signals+0x31f=0Asleepq_wait_sig()=20at=20= sleepq_wait_sig+0xc=0A_sleep()=20at=20_sleep+0x26b=0Asoreceive_generic()=20= at=20soreceive_generic+0xebe=0Adofileread()=20at=20dofileread+0xa1=0A= kern_readv()=20at=20kern_readv+0x60=0Aread()=20at=20read+0x55=0A= syscall()=20at=20syscall+0x246=0AXfast_syscall()=20at=20= Xfast_syscall+0xe1=0A---=20syscall=20(3,=20FreeBSD=20ELF64,=20read),=20= rip=20=3D=200x8013d77ac,=20rsp=20=3D=200x7fffffffdcd8,=20rbp=20=3D=200=20= ---=0A=0ATracing=20command=20httpd=20pid=201859=20tid=20100156=20td=20= 0xffffff0006614390=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_catch_signals()=20at=20= sleepq_catch_signals+0x31f=0Asleepq_wait_sig()=20at=20= sleepq_wait_sig+0xc=0A_sleep()=20at=20_sleep+0x26b=0Alf_advlockasync()=20= at=20lf_advlockasync+0xf2e=0Alf_advlock()=20at=20lf_advlock+0x47=0A= vop_stdadvlock()=20at=20vop_stdadvlock+0xb3=0Aflock()=20at=20flock+0x147=0A= syscall()=20at=20syscall+0x246=0AXfast_syscall()=20at=20= Xfast_syscall+0xe1=0A---=20syscall=20(131,=20FreeBSD=20ELF64,=20flock),=20= rip=20=3D=200x8011016cc,=20rsp=20=3D=200x7fffffffe9d8,=20rbp=20=3D=20= 0x7fffffffea5c=20---=0A=0ATracing=20command=20httpd=20pid=201858=20tid=20= 100093=20td=200xffffff000615aab0=0Asched_switch()=20at=20= sched_switch+0xf8=0Ami_switch()=20at=20mi_switch+0x16f=0A= sleepq_catch_signals()=20at=20sleepq_catch_signals+0x31f=0A= sleepq_wait_sig()=20at=20sleepq_wait_sig+0xc=0A_sleep()=20at=20= _sleep+0x26b=0Alf_advlockasync()=20at=20lf_advlockasync+0xf2e=0A= lf_advlock()=20at=20lf_advlock+0x47=0Avop_stdadvlock()=20at=20= vop_stdadvlock+0xb3=0Aflock()=20at=20flock+0x147=0Asyscall()=20at=20= syscall+0x246=0AXfast_syscall()=20at=20Xfast_syscall+0xe1=0A---=20= syscall=20(131,=20FreeBSD=20ELF64,=20flock),=20rip=20=3D=200x8011016cc,=20= rsp=20=3D=200x7fffffffe9d8,=20rbp=20=3D=200x7fffffffea5c=20---=0A=0A= Tracing=20command=20httpd=20pid=201857=20tid=20100165=20td=20= 0xffffff0006908000=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_catch_signals()=20at=20= sleepq_catch_signals+0x31f=0Asleepq_wait_sig()=20at=20= sleepq_wait_sig+0xc=0A_sleep()=20at=20_sleep+0x26b=0Alf_advlockasync()=20= at=20lf_advlockasync+0xf2e=0Alf_advlock()=20at=20lf_advlock+0x47=0A= vop_stdadvlock()=20at=20vop_stdadvlock+0xb3=0Aflock()=20at=20flock+0x147=0A= syscall()=20at=20syscall+0x246=0AXfast_syscall()=20at=20= Xfast_syscall+0xe1=0A---=20syscall=20(131,=20FreeBSD=20ELF64,=20flock),=20= rip=20=3D=200x8011016cc,=20rsp=20=3D=200x7fffffffe9d8,=20rbp=20=3D=20= 0x7fffffffea5c=20---=0A=0ATracing=20command=20httpd=20pid=201856=20tid=20= 100101=20td=200xffffff0004fc9ab0=0Asched_switch()=20at=20= sched_switch+0xf8=0Ami_switch()=20at=20mi_switch+0x16f=0A= sleepq_catch_signals()=20at=20sleepq_catch_signals+0x31f=0A= sleepq_wait_sig()=20at=20sleepq_wait_sig+0xc=0A_sleep()=20at=20= _sleep+0x26b=0Alf_advlockasync()=20at=20lf_advlockasync+0xf2e=0A= lf_advlock()=20at=20lf_advlock+0x47=0Avop_stdadvlock()=20at=20= vop_stdadvlock+0xb3=0Aflock()=20at=20flock+0x147=0Asyscall()=20at=20= syscall+0x246=0AXfast_syscall()=20at=20Xfast_syscall+0xe1=0A---=20= syscall=20(131,=20FreeBSD=20ELF64,=20flock),=20rip=20=3D=200x8011016cc,=20= rsp=20=3D=200x7fffffffe9d8,=20rbp=20=3D=200x7fffffffea5c=20---=0A=0A= Tracing=20command=20httpd=20pid=201855=20tid=20100164=20td=20= 0xffffff0006908390=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_catch_signals()=20at=20= sleepq_catch_signals+0x31f=0Asleepq_wait_sig()=20at=20= sleepq_wait_sig+0xc=0A_sleep()=20at=20_sleep+0x26b=0Alf_advlockasync()=20= at=20lf_advlockasync+0xf2e=0Alf_advlock()=20at=20lf_advlock+0x47=0A= vop_stdadvlock()=20at=20vop_stdadvlock+0xb3=0Aflock()=20at=20flock+0x147=0A= syscall()=20at=20syscall+0x246=0AXfast_syscall()=20at=20= Xfast_syscall+0xe1=0A---=20syscall=20(131,=20FreeBSD=20ELF64,=20flock),=20= rip=20=3D=200x8011016cc,=20rsp=20=3D=200x7fffffffe9d8,=20rbp=20=3D=20= 0x7fffffffea5c=20---=0A=0ATracing=20command=20getty=20pid=201854=20tid=20= 100116=20td=200xffffff000615dab0=0Asched_switch()=20at=20= sched_switch+0xf8=0Ami_switch()=20at=20mi_switch+0x16f=0A= sleepq_catch_signals()=20at=20sleepq_catch_signals+0x31f=0A= sleepq_wait_sig()=20at=20sleepq_wait_sig+0xc=0A_cv_wait_sig()=20at=20= _cv_wait_sig+0x120=0Atty_wait()=20at=20tty_wait+0x25=0Attydev_open()=20= at=20ttydev_open+0x2e3=0Adevfs_open()=20at=20devfs_open+0x186=0A= vn_open_cred()=20at=20vn_open_cred+0x2f4=0Akern_openat()=20at=20= kern_openat+0x179=0Asyscall()=20at=20syscall+0x246=0AXfast_syscall()=20= at=20Xfast_syscall+0xe1=0A---=20syscall=20(5,=20FreeBSD=20ELF64,=20= open),=20rip=20=3D=200x80084057c,=20rsp=20=3D=200x7fffffffecd8,=20rbp=20= =3D=200x508700=20---=0A=0ATracing=20command=20getty=20pid=201853=20tid=20= 100086=20td=200xffffff000615b720=0Asched_switch()=20at=20= sched_switch+0xf8=0Ami_switch()=20at=20mi_switch+0x16f=0A= sleepq_catch_signals()=20at=20sleepq_catch_signals+0x31f=0A= sleepq_wait_sig()=20at=20sleepq_wait_sig+0xc=0A_cv_wait_sig()=20at=20= _cv_wait_sig+0x120=0Atty_wait()=20at=20tty_wait+0x25=0Attydisc_read()=20= at=20ttydisc_read+0x2b1=0Attydev_read()=20at=20ttydev_read+0x10e=0A= devfs_read_f()=20at=20devfs_read_f+0x86=0Adofileread()=20at=20= dofileread+0xa1=0Akern_readv()=20at=20kern_readv+0x60=0Aread()=20at=20= read+0x55=0Asyscall()=20at=20syscall+0x246=0AXfast_syscall()=20at=20= Xfast_syscall+0xe1=0A---=20syscall=20(3,=20FreeBSD=20ELF64,=20read),=20= rip=20=3D=200x80084f7ac,=20rsp=20=3D=200x7fffffffecc8,=20rbp=20=3D=200=20= ---=0A=0ATracing=20command=20getty=20pid=201852=20tid=20100094=20td=20= 0xffffff000627f390=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_catch_signals()=20at=20= sleepq_catch_signals+0x31f=0Asleepq_wait_sig()=20at=20= sleepq_wait_sig+0xc=0A_cv_wait_sig()=20at=20_cv_wait_sig+0x120=0A= tty_wait()=20at=20tty_wait+0x25=0Attydisc_read()=20at=20= ttydisc_read+0x2b1=0Attydev_read()=20at=20ttydev_read+0x10e=0A= devfs_read_f()=20at=20devfs_read_f+0x86=0Adofileread()=20at=20= dofileread+0xa1=0Akern_readv()=20at=20kern_readv+0x60=0Aread()=20at=20= read+0x55=0Asyscall()=20at=20syscall+0x246=0AXfast_syscall()=20at=20= Xfast_syscall+0xe1=0A---=20syscall=20(3,=20FreeBSD=20ELF64,=20read),=20= rip=20=3D=200x80084f7ac,=20rsp=20=3D=200x7fffffffecc8,=20rbp=20=3D=200=20= ---=0A=0ATracing=20command=20getty=20pid=201851=20tid=20100103=20td=20= 0xffffff0004fc9390=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_catch_signals()=20at=20= sleepq_catch_signals+0x31f=0Asleepq_wait_sig()=20at=20= sleepq_wait_sig+0xc=0A_cv_wait_sig()=20at=20_cv_wait_sig+0x120=0A= tty_wait()=20at=20tty_wait+0x25=0Attydisc_read()=20at=20= ttydisc_read+0x2b1=0Attydev_read()=20at=20ttydev_read+0x10e=0A= devfs_read_f()=20at=20devfs_read_f+0x86=0Adofileread()=20at=20= dofileread+0xa1=0Akern_readv()=20at=20kern_readv+0x60=0Aread()=20at=20= read+0x55=0Asyscall()=20at=20syscall+0x246=0AXfast_syscall()=20at=20= Xfast_syscall+0xe1=0A---=20syscall=20(3,=20FreeBSD=20ELF64,=20read),=20= rip=20=3D=200x80084f7ac,=20rsp=20=3D=200x7fffffffecc8,=20rbp=20=3D=200=20= ---=0A=0ATracing=20command=20getty=20pid=201850=20tid=20100104=20td=20= 0xffffff0006556390=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_catch_signals()=20at=20= sleepq_catch_signals+0x31f=0Asleepq_wait_sig()=20at=20= sleepq_wait_sig+0xc=0A_cv_wait_sig()=20at=20_cv_wait_sig+0x120=0A= tty_wait()=20at=20tty_wait+0x25=0Attydisc_read()=20at=20= ttydisc_read+0x2b1=0Attydev_read()=20at=20ttydev_read+0x10e=0A= devfs_read_f()=20at=20devfs_read_f+0x86=0Adofileread()=20at=20= dofileread+0xa1=0Akern_readv()=20at=20kern_readv+0x60=0Aread()=20at=20= read+0x55=0Asyscall()=20at=20syscall+0x246=0AXfast_syscall()=20at=20= Xfast_syscall+0xe1=0A---=20syscall=20(3,=20FreeBSD=20ELF64,=20read),=20= rip=20=3D=200x80084f7ac,=20rsp=20=3D=200x7fffffffecc8,=20rbp=20=3D=200=20= ---=0A=0ATracing=20command=20getty=20pid=201849=20tid=20100115=20td=20= 0xffffff000627a000=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_catch_signals()=20at=20= sleepq_catch_signals+0x31f=0Asleepq_wait_sig()=20at=20= sleepq_wait_sig+0xc=0A_cv_wait_sig()=20at=20_cv_wait_sig+0x120=0A= tty_wait()=20at=20tty_wait+0x25=0Attydisc_read()=20at=20= ttydisc_read+0x2b1=0Attydev_read()=20at=20ttydev_read+0x10e=0A= devfs_read_f()=20at=20devfs_read_f+0x86=0Adofileread()=20at=20= dofileread+0xa1=0Akern_readv()=20at=20kern_readv+0x60=0Aread()=20at=20= read+0x55=0Asyscall()=20at=20syscall+0x246=0AXfast_syscall()=20at=20= Xfast_syscall+0xe1=0A---=20syscall=20(3,=20FreeBSD=20ELF64,=20read),=20= rip=20=3D=200x80084f7ac,=20rsp=20=3D=200x7fffffffecc8,=20rbp=20=3D=200=20= ---=0A=0ATracing=20command=20getty=20pid=201848=20tid=20100097=20td=20= 0xffffff000615a390=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_catch_signals()=20at=20= sleepq_catch_signals+0x31f=0Asleepq_wait_sig()=20at=20= sleepq_wait_sig+0xc=0A_cv_wait_sig()=20at=20_cv_wait_sig+0x120=0A= tty_wait()=20at=20tty_wait+0x25=0Attydisc_read()=20at=20= ttydisc_read+0x2b1=0Attydev_read()=20at=20ttydev_read+0x10e=0A= devfs_read_f()=20at=20devfs_read_f+0x86=0Adofileread()=20at=20= dofileread+0xa1=0Akern_readv()=20at=20kern_readv+0x60=0Aread()=20at=20= read+0x55=0Asyscall()=20at=20syscall+0x246=0AXfast_syscall()=20at=20= Xfast_syscall+0xe1=0A---=20syscall=20(3,=20FreeBSD=20ELF64,=20read),=20= rip=20=3D=200x80084f7ac,=20rsp=20=3D=200x7fffffffecc8,=20rbp=20=3D=200=20= ---=0A=0ATracing=20command=20getty=20pid=201847=20tid=20100099=20td=20= 0xffffff000627e720=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_catch_signals()=20at=20= sleepq_catch_signals+0x31f=0Asleepq_wait_sig()=20at=20= sleepq_wait_sig+0xc=0A_cv_wait_sig()=20at=20_cv_wait_sig+0x120=0A= tty_wait()=20at=20tty_wait+0x25=0Attydisc_read()=20at=20= ttydisc_read+0x2b1=0Attydev_read()=20at=20ttydev_read+0x10e=0A= devfs_read_f()=20at=20devfs_read_f+0x86=0Adofileread()=20at=20= dofileread+0xa1=0Akern_readv()=20at=20kern_readv+0x60=0Aread()=20at=20= read+0x55=0Asyscall()=20at=20syscall+0x246=0AXfast_syscall()=20at=20= Xfast_syscall+0xe1=0A---=20syscall=20(3,=20FreeBSD=20ELF64,=20read),=20= rip=20=3D=200x80084f7ac,=20rsp=20=3D=200x7fffffffecc8,=20rbp=20=3D=200=20= ---=0A=0ATracing=20command=20getty=20pid=201846=20tid=20100121=20td=20= 0xffffff000658f720=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_catch_signals()=20at=20= sleepq_catch_signals+0x31f=0Asleepq_wait_sig()=20at=20= sleepq_wait_sig+0xc=0A_cv_wait_sig()=20at=20_cv_wait_sig+0x120=0A= tty_wait()=20at=20tty_wait+0x25=0Attydisc_read()=20at=20= ttydisc_read+0x2b1=0Attydev_read()=20at=20ttydev_read+0x10e=0A= devfs_read_f()=20at=20devfs_read_f+0x86=0Adofileread()=20at=20= dofileread+0xa1=0Akern_readv()=20at=20kern_readv+0x60=0Aread()=20at=20= read+0x55=0Asyscall()=20at=20syscall+0x246=0AXfast_syscall()=20at=20= Xfast_syscall+0xe1=0A---=20syscall=20(3,=20FreeBSD=20ELF64,=20read),=20= rip=20=3D=200x80084f7ac,=20rsp=20=3D=200x7fffffffecc8,=20rbp=20=3D=200=20= ---=0A=0ATracing=20command=20inetd=20pid=201819=20tid=20100089=20td=20= 0xffffff000615b390=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_catch_signals()=20at=20= sleepq_catch_signals+0x31f=0Asleepq_wait_sig()=20at=20= sleepq_wait_sig+0xc=0A_cv_wait_sig()=20at=20_cv_wait_sig+0x120=0A= seltdwait()=20at=20seltdwait+0xf6=0Akern_select()=20at=20= kern_select+0x62f=0Aselect()=20at=20select+0x5d=0Asyscall()=20at=20= syscall+0x246=0AXfast_syscall()=20at=20Xfast_syscall+0xe1=0A---=20= syscall=20(93,=20FreeBSD=20ELF64,=20select),=20rip=20=3D=200x800a6472c,=20= rsp=20=3D=200x7fffffffdda8,=20rbp=20=3D=200x7878787878787878=20---=0A=0A= Tracing=20command=20cron=20pid=201788=20tid=20100162=20td=20= 0xffffff0006908ab0=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_catch_signals()=20at=20= sleepq_catch_signals+0x31f=0Asleepq_timedwait_sig()=20at=20= sleepq_timedwait_sig+0x19=0A_sleep()=20at=20_sleep+0x1a3=0A= kern_nanosleep()=20at=20kern_nanosleep+0x118=0Ananosleep()=20at=20= nanosleep+0x6e=0Asyscall()=20at=20syscall+0x246=0AXfast_syscall()=20at=20= Xfast_syscall+0xe1=0A---=20syscall=20(240,=20FreeBSD=20ELF64,=20= nanosleep),=20rip=20=3D=200x80093d92c,=20rsp=20=3D=200x7fffffffeb28,=20= rbp=20=3D=200x3c=20---=0A=0ATracing=20command=20sshd=20pid=201779=20tid=20= 100167=20td=200xffffff00068fb720=0Asched_switch()=20at=20= sched_switch+0xf8=0Ami_switch()=20at=20mi_switch+0x16f=0A= sleepq_catch_signals()=20at=20sleepq_catch_signals+0x31f=0A= sleepq_wait_sig()=20at=20sleepq_wait_sig+0xc=0A_cv_wait_sig()=20at=20= _cv_wait_sig+0x120=0Aseltdwait()=20at=20seltdwait+0xf6=0Akern_select()=20= at=20kern_select+0x62f=0Aselect()=20at=20select+0x5d=0Asyscall()=20at=20= syscall+0x246=0AXfast_syscall()=20at=20Xfast_syscall+0xe1=0A---=20= syscall=20(93,=20FreeBSD=20ELF64,=20select),=20rip=20=3D=200x8013d772c,=20= rsp=20=3D=200x7fffffffddd8,=20rbp=20=3D=200x2=20---=0A=0ATracing=20= command=20httpd=20pid=201755=20tid=20100122=20td=200xffffff000658f390=0A= sched_switch()=20at=20sched_switch+0xf8=0Ami_switch()=20at=20= mi_switch+0x16f=0Asleepq_catch_signals()=20at=20= sleepq_catch_signals+0x31f=0Asleepq_timedwait_sig()=20at=20= sleepq_timedwait_sig+0x19=0A_cv_timedwait_sig()=20at=20= _cv_timedwait_sig+0x129=0Aseltdwait()=20at=20seltdwait+0x8d=0A= kern_select()=20at=20kern_select+0x62f=0Aselect()=20at=20select+0x5d=0A= syscall()=20at=20syscall+0x246=0AXfast_syscall()=20at=20= Xfast_syscall+0xe1=0A---=20syscall=20(93,=20FreeBSD=20ELF64,=20select),=20= rip=20=3D=200x80117272c,=20rsp=20=3D=200x7fffffffea48,=20rbp=20=3D=200=20= ---=0A=0ATracing=20command=20ntpd=20pid=201672=20tid=20100166=20td=20= 0xffffff00068fbab0=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_catch_signals()=20at=20= sleepq_catch_signals+0x31f=0Asleepq_wait_sig()=20at=20= sleepq_wait_sig+0xc=0A_cv_wait_sig()=20at=20_cv_wait_sig+0x120=0A= seltdwait()=20at=20seltdwait+0xf6=0Akern_select()=20at=20= kern_select+0x62f=0Aselect()=20at=20select+0x5d=0Asyscall()=20at=20= syscall+0x246=0AXfast_syscall()=20at=20Xfast_syscall+0xe1=0A---=20= syscall=20(93,=20FreeBSD=20ELF64,=20select),=20rip=20=3D=200x800d5172c,=20= rsp=20=3D=200x7fffffffec18,=20rbp=20=3D=200x7fffffffed48=20---=0A=0A= Tracing=20command=20smartd=20pid=201614=20tid=20100155=20td=20= 0xffffff0006614720=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_catch_signals()=20at=20= sleepq_catch_signals+0x31f=0Asleepq_timedwait_sig()=20at=20= sleepq_timedwait_sig+0x19=0A_sleep()=20at=20_sleep+0x1a3=0A= kern_nanosleep()=20at=20kern_nanosleep+0x118=0Ananosleep()=20at=20= nanosleep+0x6e=0Asyscall()=20at=20syscall+0x246=0AXfast_syscall()=20at=20= Xfast_syscall+0xe1=0A---=20syscall=20(240,=20FreeBSD=20ELF64,=20= nanosleep),=20rip=20=3D=200x800dc792c,=20rsp=20=3D=200x7fffffffeb68,=20= rbp=20=3D=200x4b678e29=20---=0A=0ATracing=20command=20snmpd=20pid=201604=20= tid=20100146=20td=200xffffff00065d3000=0Asched_switch()=20at=20= sched_switch+0xf8=0Ami_switch()=20at=20mi_switch+0x16f=0A= sleepq_catch_signals()=20at=20sleepq_catch_signals+0x31f=0A= sleepq_timedwait_sig()=20at=20sleepq_timedwait_sig+0x19=0A= _cv_timedwait_sig()=20at=20_cv_timedwait_sig+0x129=0Aseltdwait()=20at=20= seltdwait+0x8d=0Akern_select()=20at=20kern_select+0x62f=0Aselect()=20at=20= select+0x5d=0Asyscall()=20at=20syscall+0x246=0AXfast_syscall()=20at=20= Xfast_syscall+0xe1=0A---=20syscall=20(93,=20FreeBSD=20ELF64,=20select),=20= rip=20=3D=200x80196472c,=20rsp=20=3D=200x7fffffffea18,=20rbp=20=3D=20= 0x7fffffffec60=20---=0A=0ATracing=20command=20pure-ftpd=20pid=201594=20= tid=20100125=20td=200xffffff000658e720=0Asched_switch()=20at=20= sched_switch+0xf8=0Ami_switch()=20at=20mi_switch+0x16f=0A= sleepq_catch_signals()=20at=20sleepq_catch_signals+0x31f=0A= sleepq_wait_sig()=20at=20sleepq_wait_sig+0xc=0A_cv_wait_sig()=20at=20= _cv_wait_sig+0x120=0Aseltdwait()=20at=20seltdwait+0xf6=0Akern_select()=20= at=20kern_select+0x62f=0Aselect()=20at=20select+0x5d=0Asyscall()=20at=20= syscall+0x246=0AXfast_syscall()=20at=20Xfast_syscall+0xe1=0A---=20= syscall=20(93,=20FreeBSD=20ELF64,=20select),=20rip=20=3D=200x80097672c,=20= rsp=20=3D=200x7fffffffeaa8,=20rbp=20=3D=200x6=20---=0A=0ATracing=20= command=20nfsd=20pid=201572=20tid=20100154=20td=200xffffff0006614ab0=0A= sched_switch()=20at=20sched_switch+0xf8=0Ami_switch()=20at=20= mi_switch+0x16f=0Asleepq_catch_signals()=20at=20= sleepq_catch_signals+0x31f=0Asleepq_timedwait_sig()=20at=20= sleepq_timedwait_sig+0x19=0A_cv_timedwait_sig()=20at=20= _cv_timedwait_sig+0x129=0Asvc_run_internal()=20at=20= svc_run_internal+0x8b9=0Asvc_thread_start()=20at=20svc_thread_start+0xb=0A= fork_exit()=20at=20fork_exit+0x118=0Afork_trampoline()=20at=20= fork_trampoline+0xe=0A---=20trap=200xc,=20rip=20=3D=200x8006a133c,=20rsp=20= =3D=200x7fffffffe6d8,=20rbp=20=3D=200x5=20---=0A=0ATracing=20command=20= nfsd=20pid=201572=20tid=20100153=20td=200xffffff00067a9000=0A= sched_switch()=20at=20sched_switch+0xf8=0Ami_switch()=20at=20= mi_switch+0x16f=0Asleepq_catch_signals()=20at=20= sleepq_catch_signals+0x31f=0Asleepq_timedwait_sig()=20at=20= sleepq_timedwait_sig+0x19=0A_cv_timedwait_sig()=20at=20= _cv_timedwait_sig+0x129=0Asvc_run_internal()=20at=20= svc_run_internal+0x8b9=0Asvc_thread_start()=20at=20svc_thread_start+0xb=0A= fork_exit()=20at=20fork_exit+0x118=0Afork_trampoline()=20at=20= fork_trampoline+0xe=0A---=20trap=200xc,=20rip=20=3D=200x8006a133c,=20rsp=20= =3D=200x7fffffffe6d8,=20rbp=20=3D=200x5=20---=0A=0ATracing=20command=20= nfsd=20pid=201572=20tid=20100152=20td=200xffffff00067a9390=0A= sched_switch()=20at=20sched_switch+0xf8=0Ami_switch()=20at=20= mi_switch+0x16f=0Asleepq_catch_signals()=20at=20= sleepq_catch_signals+0x31f=0Asleepq_timedwait_sig()=20at=20= sleepq_timedwait_sig+0x19=0A_cv_timedwait_sig()=20at=20= _cv_timedwait_sig+0x129=0Asvc_run_internal()=20at=20= svc_run_internal+0x8b9=0Asvc_thread_start()=20at=20svc_thread_start+0xb=0A= fork_exit()=20at=20fork_exit+0x118=0Afork_trampoline()=20at=20= fork_trampoline+0xe=0A---=20trap=200xc,=20rip=20=3D=200x8006a133c,=20rsp=20= =3D=200x7fffffffe6d8,=20rbp=20=3D=200x5=20---=0A=0ATracing=20command=20= nfsd=20pid=201572=20tid=20100143=20td=200xffffff00065d3ab0=0A= sched_switch()=20at=20sched_switch+0xf8=0Ami_switch()=20at=20= mi_switch+0x16f=0Asleepq_catch_signals()=20at=20= sleepq_catch_signals+0x31f=0Asleepq_timedwait_sig()=20at=20= sleepq_timedwait_sig+0x19=0A_cv_timedwait_sig()=20at=20= _cv_timedwait_sig+0x129=0Asvc_run_internal()=20at=20= svc_run_internal+0x8b9=0Asvc_run()=20at=20svc_run+0x94=0Anfssvc_nfsd()=20= at=20nfssvc_nfsd+0x97=0Anfssvc_nfsserver()=20at=20nfssvc_nfsserver+0x5b=0A= nfssvc()=20at=20nfssvc+0x5e=0Asyscall()=20at=20syscall+0x246=0A= Xfast_syscall()=20at=20Xfast_syscall+0xe1=0A---=20syscall=20(155,=20= FreeBSD=20ELF64,=20nfssvc),=20rip=20=3D=200x8006a133c,=20rsp=20=3D=20= 0x7fffffffe6d8,=20rbp=20=3D=200x5=20---=0A=0ATracing=20command=20nfsd=20= pid=201571=20tid=20100087=20td=200xffffff0006280390=0Asched_switch()=20= at=20sched_switch+0xf8=0Ami_switch()=20at=20mi_switch+0x16f=0A= sleepq_catch_signals()=20at=20sleepq_catch_signals+0x31f=0A= sleepq_wait_sig()=20at=20sleepq_wait_sig+0xc=0A_cv_wait_sig()=20at=20= _cv_wait_sig+0x120=0Aseltdwait()=20at=20seltdwait+0xf6=0Akern_select()=20= at=20kern_select+0x62f=0Aselect()=20at=20select+0x5d=0Asyscall()=20at=20= syscall+0x246=0AXfast_syscall()=20at=20Xfast_syscall+0xe1=0A---=20= syscall=20(93,=20FreeBSD=20ELF64,=20select),=20rip=20=3D=200x80073e72c,=20= rsp=20=3D=200x7fffffffe978,=20rbp=20=3D=200x7fffffffec50=20---=0A=0A= Tracing=20command=20mountd=20pid=201569=20tid=20100147=20td=20= 0xffffff00065e9ab0=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_catch_signals()=20at=20= sleepq_catch_signals+0x31f=0Asleepq_wait_sig()=20at=20= sleepq_wait_sig+0xc=0A_cv_wait_sig()=20at=20_cv_wait_sig+0x120=0A= seltdwait()=20at=20seltdwait+0xf6=0Akern_select()=20at=20= kern_select+0x62f=0Aselect()=20at=20select+0x5d=0Asyscall()=20at=20= syscall+0x246=0AXfast_syscall()=20at=20Xfast_syscall+0xe1=0A---=20= syscall=20(93,=20FreeBSD=20ELF64,=20select),=20rip=20=3D=200x80085372c,=20= rsp=20=3D=200x7fffffffec78,=20rbp=20=3D=200x7fffffffed70=20---=0A=0A= Tracing=20command=20rpcbind=20pid=201548=20tid=20100145=20td=20= 0xffffff00065d3390=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_catch_signals()=20at=20= sleepq_catch_signals+0x31f=0Asleepq_timedwait_sig()=20at=20= sleepq_timedwait_sig+0x19=0A_cv_timedwait_sig()=20at=20= _cv_timedwait_sig+0x129=0Aseltdwait()=20at=20seltdwait+0x8d=0Apoll()=20= at=20poll+0x2f8=0Asyscall()=20at=20syscall+0x246=0AXfast_syscall()=20at=20= Xfast_syscall+0xe1=0A---=20syscall=20(209,=20FreeBSD=20ELF64,=20poll),=20= rip=20=3D=200x8009065ec,=20rsp=20=3D=200x7fffffffcad8,=20rbp=20=3D=20= 0x800b100c0=20---=0A=0ATracing=20command=20syslogd=20pid=201434=20tid=20= 100150=20td=200xffffff00065e9000=0Asched_switch()=20at=20= sched_switch+0xf8=0Ami_switch()=20at=20mi_switch+0x16f=0A= sleepq_catch_signals()=20at=20sleepq_catch_signals+0x31f=0A= sleepq_wait_sig()=20at=20sleepq_wait_sig+0xc=0A_cv_wait_sig()=20at=20= _cv_wait_sig+0x120=0Aseltdwait()=20at=20seltdwait+0xf6=0Akern_select()=20= at=20kern_select+0x62f=0Aselect()=20at=20select+0x5d=0Asyscall()=20at=20= syscall+0x246=0AXfast_syscall()=20at=20Xfast_syscall+0xe1=0A---=20= syscall=20(93,=20FreeBSD=20ELF64,=20select),=20rip=20=3D=200x80085272c,=20= rsp=20=3D=200x7fffffffdcb8,=20rbp=20=3D=200x1=20---=0A=0ATracing=20= command=20devd=20pid=201210=20tid=20100144=20td=200xffffff00065d3720=0A= sched_switch()=20at=20sched_switch+0xf8=0Ami_switch()=20at=20= mi_switch+0x16f=0Asleepq_catch_signals()=20at=20= sleepq_catch_signals+0x31f=0Asleepq_wait_sig()=20at=20= sleepq_wait_sig+0xc=0A_cv_wait_sig()=20at=20_cv_wait_sig+0x120=0A= seltdwait()=20at=20seltdwait+0xf6=0Akern_select()=20at=20= kern_select+0x62f=0Aselect()=20at=20select+0x5d=0Asyscall()=20at=20= syscall+0x246=0AXfast_syscall()=20at=20Xfast_syscall+0xe1=0A---=20= syscall=20(93,=20FreeBSD=20ELF64,=20select),=20rip=20=3D=200x440cfc,=20= rsp=20=3D=200x7fffffffe898,=20rbp=20=3D=200x7fffffffe8b0=20---=0A=0A= Tracing=20command=20moused=20pid=201067=20tid=20100127=20td=20= 0xffffff00065ea720=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_catch_signals()=20at=20= sleepq_catch_signals+0x31f=0Asleepq_wait_sig()=20at=20= sleepq_wait_sig+0xc=0A_cv_wait_sig()=20at=20_cv_wait_sig+0x120=0A= seltdwait()=20at=20seltdwait+0xf6=0Akern_select()=20at=20= kern_select+0x62f=0Aselect()=20at=20select+0x5d=0Asyscall()=20at=20= syscall+0x246=0AXfast_syscall()=20at=20Xfast_syscall+0xe1=0A---=20= syscall=20(93,=20FreeBSD=20ELF64,=20select),=20rip=20=3D=200x80097172c,=20= rsp=20=3D=200x7fffffffe848,=20rbp=20=3D=200=20---=0A=0ATracing=20command=20= pfpurge=20pid=20746=20tid=20100110=20td=200xffffff000627e390=0A= sched_switch()=20at=20sched_switch+0xf8=0Ami_switch()=20at=20= mi_switch+0x16f=0Asleepq_timedwait()=20at=20sleepq_timedwait+0x42=0A= _sleep()=20at=20_sleep+0x308=0Apf_purge_thread()=20at=20= pf_purge_thread+0x31=0Afork_exit()=20at=20fork_exit+0x118=0A= fork_trampoline()=20at=20fork_trampoline+0xe=0A---=20trap=200,=20rip=20=3D= =200,=20rsp=20=3D=200xffffff8079d50d30,=20rbp=20=3D=200=20---=0A=0A= Tracing=20command=20flowcleaner=20pid=2019=20tid=20100085=20td=20= 0xffffff000615bab0=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_timedwait()=20at=20= sleepq_timedwait+0x42=0A_cv_timedwait()=20at=20_cv_timedwait+0x129=0A= flowtable_cleaner()=20at=20flowtable_cleaner+0xe9=0Afork_exit()=20at=20= fork_exit+0x118=0Afork_trampoline()=20at=20fork_trampoline+0xe=0A---=20= trap=200,=20rip=20=3D=200,=20rsp=20=3D=200xffffff8077729d30,=20rbp=20=3D=20= 0=20---=0A=0ATracing=20command=20softdepflush=20pid=2018=20tid=20100084=20= td=200xffffff000615d000=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_timedwait()=20at=20= sleepq_timedwait+0x42=0A_sleep()=20at=20_sleep+0x308=0Asoftdep_flush()=20= at=20softdep_flush+0x34d=0Afork_exit()=20at=20fork_exit+0x118=0A= fork_trampoline()=20at=20fork_trampoline+0xe=0A---=20trap=200,=20rip=20=3D= =200,=20rsp=20=3D=200xffffff8077724d30,=20rbp=20=3D=200=20---=0A=0A= Tracing=20command=20vnlru=20pid=2017=20tid=20100083=20td=20= 0xffffff000615d390=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_timedwait()=20at=20= sleepq_timedwait+0x42=0A_sleep()=20at=20_sleep+0x308=0Avnlru_proc()=20at=20= vnlru_proc+0x4da=0Afork_exit()=20at=20fork_exit+0x118=0A= fork_trampoline()=20at=20fork_trampoline+0xe=0A---=20trap=200,=20rip=20=3D= =200,=20rsp=20=3D=200xffffff807771fd30,=20rbp=20=3D=200=20---=0A=0A= Tracing=20command=20syncer=20pid=2016=20tid=20100082=20td=20= 0xffffff000615d720=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_timedwait()=20at=20= sleepq_timedwait+0x42=0A_cv_timedwait()=20at=20_cv_timedwait+0x129=0A= sched_sync()=20at=20sched_sync+0x4e6=0Afork_exit()=20at=20= fork_exit+0x118=0Afork_trampoline()=20at=20fork_trampoline+0xe=0A---=20= trap=200,=20rip=20=3D=200,=20rsp=20=3D=200xffffff807771ad30,=20rbp=20=3D=20= 0=20---=0A=0ATracing=20command=20bufdaemon=20pid=2015=20tid=20100081=20= td=200xffffff0004fc5000=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_timedwait()=20at=20= sleepq_timedwait+0x42=0A_sleep()=20at=20_sleep+0x308=0Abuf_daemon()=20at=20= buf_daemon+0x192=0Afork_exit()=20at=20fork_exit+0x118=0A= fork_trampoline()=20at=20fork_trampoline+0xe=0A---=20trap=200,=20rip=20=3D= =200,=20rsp=20=3D=200xffffff8077715d30,=20rbp=20=3D=200=20---=0A=0A= Tracing=20command=20pagezero=20pid=209=20tid=20100080=20td=20= 0xffffff0004fc5390=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_timedwait()=20at=20= sleepq_timedwait+0x42=0A_sleep()=20at=20_sleep+0x308=0Avm_pagezero()=20= at=20vm_pagezero+0x83=0Afork_exit()=20at=20fork_exit+0x118=0A= fork_trampoline()=20at=20fork_trampoline+0xe=0A---=20trap=200,=20rip=20=3D= =200,=20rsp=20=3D=200xffffff8077710d30,=20rbp=20=3D=200=20---=0A=0A= Tracing=20command=20vmdaemon=20pid=208=20tid=20100079=20td=20= 0xffffff0004fc5720=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_wait()=20at=20= sleepq_wait+0x42=0A_sleep()=20at=20_sleep+0x31c=0Avm_daemon()=20at=20= vm_daemon+0x58=0Afork_exit()=20at=20fork_exit+0x118=0Afork_trampoline()=20= at=20fork_trampoline+0xe=0A---=20trap=200,=20rip=20=3D=200,=20rsp=20=3D=20= 0xffffff807770bd30,=20rbp=20=3D=200=20---=0A=0ATracing=20command=20= pagedaemon=20pid=207=20tid=20100078=20td=200xffffff0004fc5ab0=0A= sched_switch()=20at=20sched_switch+0xf8=0Ami_switch()=20at=20= mi_switch+0x16f=0Asleepq_timedwait()=20at=20sleepq_timedwait+0x42=0A= _sleep()=20at=20_sleep+0x308=0Avm_pageout()=20at=20vm_pageout+0x877=0A= fork_exit()=20at=20fork_exit+0x118=0Afork_trampoline()=20at=20= fork_trampoline+0xe=0A---=20trap=200,=20rip=20=3D=200,=20rsp=20=3D=20= 0xffffff8077706d30,=20rbp=20=3D=200=20---=0A=0ATracing=20command=20usb=20= pid=2014=20tid=20100077=20td=200xffffff0004fc6000=0Asched_switch()=20at=20= sched_switch+0xf8=0Ami_switch()=20at=20mi_switch+0x16f=0Asleepq_wait()=20= at=20sleepq_wait+0x42=0A_cv_wait()=20at=20_cv_wait+0x111=0Ausb_process()=20= at=20usb_process+0x18f=0Afork_exit()=20at=20fork_exit+0x118=0A= fork_trampoline()=20at=20fork_trampoline+0xe=0A---=20trap=200,=20rip=20=3D= =200,=20rsp=20=3D=200xffffff8077510d30,=20rbp=20=3D=200=20---=0A=0A= Tracing=20command=20usb=20pid=2014=20tid=20100076=20td=20= 0xffffff0004fc6390=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_wait()=20at=20= sleepq_wait+0x42=0A_cv_wait()=20at=20_cv_wait+0x111=0Ausb_process()=20at=20= usb_process+0x18f=0Afork_exit()=20at=20fork_exit+0x118=0A= fork_trampoline()=20at=20fork_trampoline+0xe=0A---=20trap=200,=20rip=20=3D= =200,=20rsp=20=3D=200xffffff807750bd30,=20rbp=20=3D=200=20---=0A=0A= Tracing=20command=20usb=20pid=2014=20tid=20100075=20td=20= 0xffffff0004fc6720=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_wait()=20at=20= sleepq_wait+0x42=0A_cv_wait()=20at=20_cv_wait+0x111=0Ausb_process()=20at=20= usb_process+0x18f=0Afork_exit()=20at=20fork_exit+0x118=0A= fork_trampoline()=20at=20fork_trampoline+0xe=0A---=20trap=200,=20rip=20=3D= =200,=20rsp=20=3D=200xffffff8077506d30,=20rbp=20=3D=200=20---=0A=0A= Tracing=20command=20usb=20pid=2014=20tid=20100074=20td=20= 0xffffff0004fc6ab0=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_wait()=20at=20= sleepq_wait+0x42=0A_cv_wait()=20at=20_cv_wait+0x111=0Ausb_process()=20at=20= usb_process+0x18f=0Afork_exit()=20at=20fork_exit+0x118=0A= fork_trampoline()=20at=20fork_trampoline+0xe=0A---=20trap=200,=20rip=20=3D= =200,=20rsp=20=3D=200xffffff8077501d30,=20rbp=20=3D=200=20---=0A=0A= Tracing=20command=20usb=20pid=2014=20tid=20100073=20td=20= 0xffffff0004fc8000=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_wait()=20at=20= sleepq_wait+0x42=0A_cv_wait()=20at=20_cv_wait+0x111=0Ausb_process()=20at=20= usb_process+0x18f=0Afork_exit()=20at=20fork_exit+0x118=0A= fork_trampoline()=20at=20fork_trampoline+0xe=0A---=20trap=200,=20rip=20=3D= =200,=20rsp=20=3D=200xffffff80774fcd30,=20rbp=20=3D=200=20---=0A=0A= Tracing=20command=20usb=20pid=2014=20tid=20100072=20td=20= 0xffffff0004fc8390=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_wait()=20at=20= sleepq_wait+0x42=0A_cv_wait()=20at=20_cv_wait+0x111=0Ausb_process()=20at=20= usb_process+0x18f=0Afork_exit()=20at=20fork_exit+0x118=0A= fork_trampoline()=20at=20fork_trampoline+0xe=0A---=20trap=200,=20rip=20=3D= =200,=20rsp=20=3D=200xffffff80774f7d30,=20rbp=20=3D=200=20---=0A=0A= Tracing=20command=20usb=20pid=2014=20tid=20100071=20td=20= 0xffffff0004fc8720=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_wait()=20at=20= sleepq_wait+0x42=0A_cv_wait()=20at=20_cv_wait+0x111=0Ausb_process()=20at=20= usb_process+0x18f=0Afork_exit()=20at=20fork_exit+0x118=0A= fork_trampoline()=20at=20fork_trampoline+0xe=0A---=20trap=200,=20rip=20=3D= =200,=20rsp=20=3D=200xffffff80774f2d30,=20rbp=20=3D=200=20---=0A=0A= Tracing=20command=20usb=20pid=2014=20tid=20100070=20td=20= 0xffffff0004fc8ab0=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_wait()=20at=20= sleepq_wait+0x42=0A_cv_wait()=20at=20_cv_wait+0x111=0Ausb_process()=20at=20= usb_process+0x18f=0Afork_exit()=20at=20fork_exit+0x118=0A= fork_trampoline()=20at=20fork_trampoline+0xe=0A---=20trap=200,=20rip=20=3D= =200,=20rsp=20=3D=200xffffff80774edd30,=20rbp=20=3D=200=20---=0A=0A= Tracing=20command=20usb=20pid=2014=20tid=20100069=20td=20= 0xffffff0004fc9000=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_wait()=20at=20= sleepq_wait+0x42=0A_cv_wait()=20at=20_cv_wait+0x111=0Ausb_process()=20at=20= usb_process+0x18f=0Afork_exit()=20at=20fork_exit+0x118=0A= fork_trampoline()=20at=20fork_trampoline+0xe=0A---=20trap=200,=20rip=20=3D= =200,=20rsp=20=3D=200xffffff80774e8d30,=20rbp=20=3D=200=20---=0A=0A= Tracing=20command=20usb=20pid=2014=20tid=20100068=20td=20= 0xffffff0004fbf000=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_wait()=20at=20= sleepq_wait+0x42=0A_cv_wait()=20at=20_cv_wait+0x111=0Ausb_process()=20at=20= usb_process+0x18f=0Afork_exit()=20at=20fork_exit+0x118=0A= fork_trampoline()=20at=20fork_trampoline+0xe=0A---=20trap=200,=20rip=20=3D= =200,=20rsp=20=3D=200xffffff80774e3d30,=20rbp=20=3D=200=20---=0A=0A= Tracing=20command=20usb=20pid=2014=20tid=20100067=20td=20= 0xffffff0004fbf390=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_wait()=20at=20= sleepq_wait+0x42=0A_cv_wait()=20at=20_cv_wait+0x111=0Ausb_process()=20at=20= usb_process+0x18f=0Afork_exit()=20at=20fork_exit+0x118=0A= fork_trampoline()=20at=20fork_trampoline+0xe=0A---=20trap=200,=20rip=20=3D= =200,=20rsp=20=3D=200xffffff80774ded30,=20rbp=20=3D=200=20---=0A=0A= Tracing=20command=20usb=20pid=2014=20tid=20100066=20td=20= 0xffffff0004fbf720=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_wait()=20at=20= sleepq_wait+0x42=0A_cv_wait()=20at=20_cv_wait+0x111=0Ausb_process()=20at=20= usb_process+0x18f=0Afork_exit()=20at=20fork_exit+0x118=0A= fork_trampoline()=20at=20fork_trampoline+0xe=0A---=20trap=200,=20rip=20=3D= =200,=20rsp=20=3D=200xffffff80774d9d30,=20rbp=20=3D=200=20---=0A=0A= Tracing=20command=20usb=20pid=2014=20tid=20100065=20td=20= 0xffffff0004fbfab0=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_wait()=20at=20= sleepq_wait+0x42=0A_cv_wait()=20at=20_cv_wait+0x111=0Ausb_process()=20at=20= usb_process+0x18f=0Afork_exit()=20at=20fork_exit+0x118=0A= fork_trampoline()=20at=20fork_trampoline+0xe=0A---=20trap=200,=20rip=20=3D= =200,=20rsp=20=3D=200xffffff80774d4d30,=20rbp=20=3D=200=20---=0A=0A= Tracing=20command=20usb=20pid=2014=20tid=20100064=20td=20= 0xffffff0004fc1000=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_wait()=20at=20= sleepq_wait+0x42=0A_cv_wait()=20at=20_cv_wait+0x111=0Ausb_process()=20at=20= usb_process+0x18f=0Afork_exit()=20at=20fork_exit+0x118=0A= fork_trampoline()=20at=20fork_trampoline+0xe=0A---=20trap=200,=20rip=20=3D= =200,=20rsp=20=3D=200xffffff80774cfd30,=20rbp=20=3D=200=20---=0A=0A= Tracing=20command=20usb=20pid=2014=20tid=20100063=20td=20= 0xffffff0004fc1390=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_wait()=20at=20= sleepq_wait+0x42=0A_cv_wait()=20at=20_cv_wait+0x111=0Ausb_process()=20at=20= usb_process+0x18f=0Afork_exit()=20at=20fork_exit+0x118=0A= fork_trampoline()=20at=20fork_trampoline+0xe=0A---=20trap=200,=20rip=20=3D= =200,=20rsp=20=3D=200xffffff80774cad30,=20rbp=20=3D=200=20---=0A=0A= Tracing=20command=20usb=20pid=2014=20tid=20100062=20td=20= 0xffffff0004fc1720=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_wait()=20at=20= sleepq_wait+0x42=0A_cv_wait()=20at=20_cv_wait+0x111=0Ausb_process()=20at=20= usb_process+0x18f=0Afork_exit()=20at=20fork_exit+0x118=0A= fork_trampoline()=20at=20fork_trampoline+0xe=0A---=20trap=200,=20rip=20=3D= =200,=20rsp=20=3D=200xffffff80774c5d30,=20rbp=20=3D=200=20---=0A=0A= Tracing=20command=20usb=20pid=2014=20tid=20100061=20td=20= 0xffffff0004fc1ab0=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_wait()=20at=20= sleepq_wait+0x42=0A_cv_wait()=20at=20_cv_wait+0x111=0Ausb_process()=20at=20= usb_process+0x18f=0Afork_exit()=20at=20fork_exit+0x118=0A= fork_trampoline()=20at=20fork_trampoline+0xe=0A---=20trap=200,=20rip=20=3D= =200,=20rsp=20=3D=200xffffff80774c0d30,=20rbp=20=3D=200=20---=0A=0A= Tracing=20command=20usb=20pid=2014=20tid=20100060=20td=20= 0xffffff0004fc2000=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_wait()=20at=20= sleepq_wait+0x42=0A_cv_wait()=20at=20_cv_wait+0x111=0Ausb_process()=20at=20= usb_process+0x18f=0Afork_exit()=20at=20fork_exit+0x118=0A= fork_trampoline()=20at=20fork_trampoline+0xe=0A---=20trap=200,=20rip=20=3D= =200,=20rsp=20=3D=200xffffff80774bbd30,=20rbp=20=3D=200=20---=0A=0A= Tracing=20command=20usb=20pid=2014=20tid=20100059=20td=20= 0xffffff0004fc2390=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_wait()=20at=20= sleepq_wait+0x42=0A_cv_wait()=20at=20_cv_wait+0x111=0Ausb_process()=20at=20= usb_process+0x18f=0Afork_exit()=20at=20fork_exit+0x118=0A= fork_trampoline()=20at=20fork_trampoline+0xe=0A---=20trap=200,=20rip=20=3D= =200,=20rsp=20=3D=200xffffff80774b6d30,=20rbp=20=3D=200=20---=0A=0A= Tracing=20command=20usb=20pid=2014=20tid=20100058=20td=20= 0xffffff0004fc2720=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_wait()=20at=20= sleepq_wait+0x42=0A_cv_wait()=20at=20_cv_wait+0x111=0Ausb_process()=20at=20= usb_process+0x18f=0Afork_exit()=20at=20fork_exit+0x118=0A= fork_trampoline()=20at=20fork_trampoline+0xe=0A---=20trap=200,=20rip=20=3D= =200,=20rsp=20=3D=200xffffff80774b1d30,=20rbp=20=3D=200=20---=0A=0A= Tracing=20command=20usb=20pid=2014=20tid=20100057=20td=20= 0xffffff0004fc2ab0=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_wait()=20at=20= sleepq_wait+0x42=0A_cv_wait()=20at=20_cv_wait+0x111=0Ausb_process()=20at=20= usb_process+0x18f=0Afork_exit()=20at=20fork_exit+0x118=0A= fork_trampoline()=20at=20fork_trampoline+0xe=0A---=20trap=200,=20rip=20=3D= =200,=20rsp=20=3D=200xffffff80774acd30,=20rbp=20=3D=200=20---=0A=0A= Tracing=20command=20usb=20pid=2014=20tid=20100056=20td=20= 0xffffff0001717390=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_switch()=20at=20mi_switch+0x16f=0Asleepq_wait()=20at=20= sleepq_wait+0x42=0A_cv_wait()=20at=20_cv_wait+0x111=0Ausb_process()=20at=20= usb_process+0x18f=0Afork_exit()=20at=20fork_exit+0x118=0A= fork_trampoline()=20at=20fork_trampoline+0xe=0A---=20trap=200,=20rip=20=3D= =200,=20rsp=20=3D=200xffffff80774a7d30,=20rbp=20=3D=200=20---=0A=0A= Tracing=20command=20usb=20pid=2014=20tid=20100055=20td=20= 0xffffff0001717720=0Asched_switch()=20at=20sched_switch+0xf8=0A= mi_msgbuf.txt=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=000600=00=00=00=000= =00=00=00=00=00=00=000=00=00=00=00=00=00=0055631=00=00=00=00=00=00=0011331= 704434=00=20=207563=00=20= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00ustar=00=00=00root=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00wheel=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00Copyrigh= t=20(c)=201992-2009=20The=20FreeBSD=20Project.=0ACopyright=20(c)=201979,=20= 1980,=201983,=201986,=201988,=201989,=201991,=201992,=201993,=201994=0A=09= The=20Regents=20of=20the=20University=20of=20California.=20All=20rights=20= reserved.=0AFreeBSD=20is=20a=20registered=20trademark=20of=20The=20= FreeBSD=20Foundation.=0AFreeBSD=208.0-RELEASE-p2=20#2:=20Tue=20Feb=20=20= 2=2001:14:26=20UTC=202010=0A=20=20=20=20= root@dl0009.sjc02.denetron.net:/usr/obj/usr/src/sys/GENERIC=0A= Timecounter=20"i8254"=20frequency=201193182=20Hz=20quality=200=0ACPU:=20= Intel(R)=20Xeon(R)=20CPU=20=20=20=20=20=20=20=20=20=20=20E5504=20=20@=20= 2.00GHz=20(1995.00-MHz=20K8-class=20CPU)=0A=20=20Origin=20=3D=20= "GenuineIntel"=20=20Id=20=3D=200x106a5=20=20Stepping=20=3D=205=0A=20=20= Features=3D0xbfebfbff=0A=20= =20= Features2=3D0x9ce3bd=0A=20=20AMD=20= Features=3D0x28100800=0A=20=20AMD=20= Features2=3D0x1=0A=20=20TSC:=20P-state=20invariant=0Areal=20memory=20= =20=3D=204299161600=20(4100=20MB)=0Aavail=20memory=20=3D=204090388480=20= (3900=20MB)=0AACPI=20APIC=20Table:=20<030609=20APIC0930>=0AFreeBSD/SMP:=20= Multiprocessor=20System=20Detected:=204=20CPUs=0AFreeBSD/SMP:=201=20= package(s)=20x=204=20core(s)=0A=20cpu0=20(BSP):=20APIC=20ID:=20=200=0A=20= cpu1=20(AP):=20APIC=20ID:=20=202=0A=20cpu2=20(AP):=20APIC=20ID:=20=204=0A= =20cpu3=20(AP):=20APIC=20ID:=20=206=0Aioapic0:=20Changing=20APIC=20ID=20= to=201=0Aioapic0=20=20irqs=200-23=20on=20motherboard=0A= kbd1=20at=20kbdmux0=0Aacpi0:=20=20on=20motherboard=0Aacpi0:=20= [ITHREAD]=0Aacpi0:=20Power=20Button=20(fixed)=0Aacpi0:=20reservation=20= of=200,=20a0000=20(3)=20failed=0Aacpi0:=20reservation=20of=20100000,=20= bff00000=20(3)=20failed=0ATimecounter=20"ACPI-fast"=20frequency=20= 3579545=20Hz=20quality=201000=0Aacpi_timer0:=20<24-bit=20timer=20at=20= 3.579545MHz>=20port=200x808-0x80b=20on=20acpi0=0Apcib0:=20=20port=200xcf8-0xcff=20on=20acpi0=0Apci0:=20=20on=20pcib0=0Apcib1:=20=20at=20= device=201.0=20on=20pci0=0Apci1:=20=20on=20pcib1=0A= em0:=20=20port=20= 0xdc00-0xdc1f=20mem=200xfaee0000-0xfaefffff,0xfaedc000-0xfaedffff=20irq=20= 16=20at=20device=200.0=20on=20pci1=0Aem0:=20Using=20MSIX=20interrupts=0A= em0:=20[ITHREAD]=0Aem0:=20[ITHREAD]=0Aem0:=20[ITHREAD]=0Aem0:=20Ethernet=20= address:=2000:30:48:be:6f:14=0Apcib2:=20=20at=20= device=202.0=20on=20pci0=0Apci2:=20=20on=20pcib2=0A= em1:=20=20port=20= 0xec00-0xec1f=20mem=200xfafe0000-0xfaffffff,0xfafdc000-0xfafdffff=20irq=20= 16=20at=20device=200.0=20on=20pci2=0Aem1:=20Using=20MSIX=20interrupts=0A= em1:=20[ITHREAD]=0Aem1:=20[ITHREAD]=0Aem1:=20[ITHREAD]=0Aem1:=20Ethernet=20= address:=2000:30:48:be:6f:15=0Apcib3:=20=20at=20= device=203.0=20on=20pci0=0Apci3:=20=20on=20pcib3=0A= pcib4:=20=20at=20device=207.0=20on=20pci0=0A= pci4:=20=20on=20pcib4=0Apcib5:=20=20at=20device=209.0=20on=20pci0=0Apci5:=20=20= on=20pcib5=0Apci0:=20=20at=20= device=2016.0=20(no=20driver=20attached)=0Apci0:=20=20at=20device=2016.1=20(no=20driver=20attached)=0A= pci0:=20=20at=20device=20= 17.0=20(no=20driver=20attached)=0Apci0:=20=20at=20device=2017.1=20(no=20driver=20attached)=0A= pci0:=20=20at=20device=20= 20.0=20(no=20driver=20attached)=0Apci0:=20=20at=20device=2020.1=20(no=20driver=20attached)=0A= pci0:=20=20at=20device=20= 20.2=20(no=20driver=20attached)=0Apci0:=20=20at=20device=2020.3=20(no=20driver=20attached)=0A= pci0:=20=20at=20device=2022.0=20(no=20driver=20= attached)=0Apci0:=20=20at=20device=2022.1=20(no=20= driver=20attached)=0Apci0:=20=20at=20device=2022.2=20= (no=20driver=20attached)=0Apci0:=20=20at=20device=20= 22.3=20(no=20driver=20attached)=0Apci0:=20=20at=20= device=2022.4=20(no=20driver=20attached)=0Apci0:=20=20= at=20device=2022.5=20(no=20driver=20attached)=0Apci0:=20=20at=20device=2022.6=20(no=20driver=20attached)=0Apci0:=20= =20at=20device=2022.7=20(no=20driver=20attached)=0A= uhci0:=20=20port=200xcc00-0xcc1f=20= irq=2016=20at=20device=2026.0=20on=20pci0=0Auhci0:=20[ITHREAD]=0Auhci0:=20= LegSup=20=3D=200x0f30=0Ausbus0:=20=20= on=20uhci0=0Auhci1:=20=20port=20= 0xc880-0xc89f=20irq=2021=20at=20device=2026.1=20on=20pci0=0Auhci1:=20= [ITHREAD]=0Auhci1:=20LegSup=20=3D=200x0f30=0Ausbus1:=20=20on=20uhci1=0Auhci2:=20=20port=200xc800-0xc81f=20irq=2019=20at=20device=2026.2=20on=20= pci0=0Auhci2:=20[ITHREAD]=0Auhci2:=20LegSup=20=3D=200x0f30=0Ausbus2:=20= =20on=20uhci2=0Aehci0:=20=20mem=200xfadde000-0xfadde3ff=20irq=20= 18=20at=20device=2026.7=20on=20pci0=0Aehci0:=20[ITHREAD]=0Ausbus3:=20= EHCI=20version=201.0=0Ausbus3:=20=20on=20ehci0=0Auhci3:=20=20port=200xc480-0xc49f=20irq=2023=20at=20device=2029.0=20on=20= pci0=0Auhci3:=20[ITHREAD]=0Auhci3:=20LegSup=20=3D=200x0f30=0Ausbus4:=20= =20on=20uhci3=0Auhci4:=20=20port=200xc400-0xc41f=20irq=2019=20at=20= device=2029.1=20on=20pci0=0Auhci4:=20[ITHREAD]=0Auhci4:=20LegSup=20=3D=20= 0x0f30=0Ausbus5:=20=20on=20uhci4=0A= uhci5:=20=20port=200xc080-0xc09f=20= irq=2018=20at=20device=2029.2=20on=20pci0=0Auhci5:=20[ITHREAD]=0Auhci5:=20= LegSup=20=3D=200x0f30=0Ausbus6:=20=20= on=20uhci5=0Aehci1:=20=20mem=20= 0xfaddc000-0xfaddc3ff=20irq=2023=20at=20device=2029.7=20on=20pci0=0A= ehci1:=20[ITHREAD]=0Ausbus7:=20EHCI=20version=201.0=0Ausbus7:=20=20on=20ehci1=0Apcib6:=20=20at=20device=2030.0=20on=20pci0=0Apci6:=20=20on=20pcib6=0Avgapci0:=20=20mem=20= 0xf9000000-0xf9ffffff,0xfbefc000-0xfbefffff,0xfb000000-0xfb7fffff=20irq=20= 17=20at=20device=204.0=20on=20pci6=0Aisab0:=20=20at=20= device=2031.0=20on=20pci0=0Aisa0:=20=20on=20isab0=0Aahci0:=20= =20port=20= 0xc000-0xc007,0xbc00-0xbc03,0xb880-0xb887,0xb800-0xb803,0xb480-0xb49f=20= mem=200xfadd6000-0xfadd67ff=20irq=2019=20at=20device=2031.2=20on=20pci0=0A= ahci0:=20[ITHREAD]=0Aahci0:=20AHCI=20v1.20=20with=206=203Gbps=20ports,=20= Port=20Multiplier=20not=20supported=0Aahcich0:=20=20at=20= channel=200=20on=20ahci0=0Aahcich0:=20[ITHREAD]=0Aahcich1:=20=20at=20channel=201=20on=20ahci0=0Aahcich1:=20[ITHREAD]=0A= ahcich2:=20=20at=20channel=202=20on=20ahci0=0Aahcich2:=20= [ITHREAD]=0Aahcich3:=20=20at=20channel=203=20on=20ahci0=0A= ahcich3:=20[ITHREAD]=0Aahcich4:=20=20at=20channel=204=20= on=20ahci0=0Aahcich4:=20[ITHREAD]=0Aahcich5:=20=20at=20= channel=205=20on=20ahci0=0Aahcich5:=20[ITHREAD]=0Apci0:=20=20at=20device=2031.3=20(no=20driver=20attached)=0Aacpi_button0:=20= =20on=20acpi0=0Aatrtc0:=20=20port=20= 0x70-0x71=20irq=208=20on=20acpi0=0Auart0:=20<16550=20or=20compatible>=20= port=200x3f8-0x3ff=20irq=204=20flags=200x10=20on=20acpi0=0Auart0:=20= [FILTER]=0Auart1:=20<16550=20or=20compatible>=20port=200x2f8-0x2ff=20irq=20= 3=20on=20acpi0=0Auart1:=20[FILTER]=0Auart2:=20<16550=20or=20compatible>=20= port=200x3e8-0x3ef=20irq=205=20on=20acpi0=0Auart2:=20[FILTER]=0Acpu0:=20= =20on=20acpi0=0AACPI=20Warning:=20Incorrect=20checksum=20in=20= table=20[OEMB]=20-=2093,=20should=20be=2090=2020090521=20tbutils-275=0A= est0:=20=20on=20cpu0=0A= p4tcc0:=20=20on=20cpu0=0Acpu1:=20= =20on=20acpi0=0Aest1:=20=20on=20cpu1=0Ap4tcc1:=20=20= on=20cpu1=0Acpu2:=20=20on=20acpi0=0Aest2:=20=20on=20cpu2=0Ap4tcc2:=20=20on=20cpu2=0Acpu3:=20=20on=20= acpi0=0Aest3:=20=20on=20cpu3=0A= p4tcc3:=20=20on=20cpu3=0Aorm0:=20= =20at=20iomem=200xc0000-0xc7fff=20on=20isa0=0Asc0:=20= =20at=20flags=200x100=20on=20isa0=0Asc0:=20VGA=20<16=20= virtual=20consoles,=20flags=3D0x300>=0Avga0:=20=20= at=20port=200x3c0-0x3df=20iomem=200xa0000-0xbffff=20on=20isa0=0Aatkbdc0:=20= =20at=20port=200x60,0x64=20on=20isa0=0A= atkbd0:=20=20irq=201=20on=20atkbdc0=0Akbd0=20at=20atkbd0=0A= atkbd0:=20[GIANT-LOCKED]=0Aatkbd0:=20[ITHREAD]=0Appc0:=20cannot=20= reserve=20I/O=20port=20range=0ATimecounters=20tick=20every=201.000=20= msec=0AWaiting=205=20seconds=20for=20SCSI=20devices=20to=20settle=0A= usbus0:=2012Mbps=20Full=20Speed=20USB=20v1.0=0Ausbus1:=2012Mbps=20Full=20= Speed=20USB=20v1.0=0Ausbus2:=2012Mbps=20Full=20Speed=20USB=20v1.0=0A= usbus3:=20480Mbps=20High=20Speed=20USB=20v2.0=0Ausbus4:=2012Mbps=20Full=20= Speed=20USB=20v1.0=0Ausbus5:=2012Mbps=20Full=20Speed=20USB=20v1.0=0A= usbus6:=2012Mbps=20Full=20Speed=20USB=20v1.0=0Ausbus7:=20480Mbps=20High=20= Speed=20USB=20v2.0=0Augen0.1:=20=20at=20usbus0=0Auhub0:=20=20on=20= usbus0=0Augen1.1:=20=20at=20usbus1=0Auhub1:=20=20on=20usbus1=0A= ugen2.1:=20=20at=20usbus2=0Auhub2:=20=20on=20usbus2=0Augen3.1:=20= =20at=20usbus3=0Auhub3:=20=20on=20usbus3=0Augen4.1:=20=20= at=20usbus4=0Auhub4:=20=20on=20usbus4=0Augen5.1:=20=20at=20usbus5=0A= uhub5:=20=20on=20usbus5=0Augen6.1:=20=20at=20usbus6=0Auhub6:=20= =20on=20usbus6=0Augen7.1:=20=20at=20usbus7=0Auhub7:=20=20on=20= usbus7=0Auhub0:=202=20ports=20with=202=20removable,=20self=20powered=0A= uhub1:=202=20ports=20with=202=20removable,=20self=20powered=0Auhub2:=202=20= ports=20with=202=20removable,=20self=20powered=0Auhub4:=202=20ports=20= with=202=20removable,=20self=20powered=0Auhub5:=202=20ports=20with=202=20= removable,=20self=20powered=0Auhub6:=202=20ports=20with=202=20removable,=20= self=20powered=0Auhub3:=206=20ports=20with=206=20removable,=20self=20= powered=0Auhub7:=206=20ports=20with=206=20removable,=20self=20powered=0A= ugen3.2:=20=20at=20usbus3=0Aumass0:=20= =20on=20usbus3=0Aumass0:=20=20SCSI=20over=20Bulk-Only;=20= quirks=20=3D=200x0000=0A(aprobe0:ahcich0:0:0:0):=20SIGNATURE:=20eb14=0A= (aprobe1:ahcich1:0:0:0):=20SIGNATURE:=200000=0A(aprobe2:ahcich2:0:0:0):=20= SIGNATURE:=200000=0Aada0=20at=20ahcich1=20bus=200=20target=200=20lun=200=0A= ada0:=20=20ATA/ATAPI-8=20SATA=202.x=20device=0Aada0:=20= 300.000MB/s=20transfers=0Aada0:=20238475MB=20(488397168=20512=20byte=20= sectors:=2016H=2063S/T=2016383C)=0Aada0:=20Native=20Command=20Queueing=20= enabled=0Aada1=20at=20ahcich2=20bus=200=20target=200=20lun=200=0Aada1:=20= =20ATA/ATAPI-6=20SATA=201.x=20device=0A= ada1:=20150.000MB/s=20transfers=0Aada1:=20238475MB=20(488397168=20512=20= byte=20sectors:=2016H=2063S/T=2016383C)=0ASMP:=20AP=20CPU=20#1=20= Launched!=0ASMP:=20AP=20CPU=20#2=20Launched!=0ASMP:=20AP=20CPU=20#3=20= Launched!=0Acd0=20at=20ahcich0=20bus=200=20target=200=20lun=200=0Acd0:=20= =20Removable=20CD-ROM=20SCSI-0=20= device=20=0Acd0:=20150.000MB/s=20transfers=0Acd0:=20Attempt=20to=20query=20= device=20size=20failed:=20NOT=20READY,=20Medium=20not=20present=20-=20= tray=20closedumass0:6:0:-1:=20Attached=20to=20scbus6=0A=0A= (probe0:umass-sim0:0:0:0):=20TEST=20UNIT=20READY.=20CDB:=200=200=200=200=20= 0=200=20=0A(probe0:umass-sim0:0:0:0):=20CAM=20Status:=20SCSI=20Status=20= Error=0A(probe0:umass-sim0:0:0:0):=20SCSI=20Status:=20Check=20Condition=0A= (probe0:umass-sim0:0:0:0):=20NOT=20READY=20asc:3a,0=0A= (probe0:umass-sim0:0:0:0):=20Medium=20not=20present=0A= (probe0:umass-sim0:0:0:0):=20Unretryable=20error=0Acd1=20at=20umass-sim0=20= bus=200=20target=200=20lun=200=0Acd1:=20=20= Removable=20CD-ROM=20SCSI-0=20device=20=0Acd1:=2040.000MB/s=20transfers=0A= cd1:=20Attempt=20to=20query=20device=20size=20failed:=20NOT=20READY,=20= Medium=20not=20present=0A(probe0:umass-sim0:0:0:1):=20TEST=20UNIT=20= READY.=20CDB:=200=2020=200=200=200=200=20=0A(probe0:umass-sim0:0:0:1):=20= CAM=20Status:=20SCSI=20Status=20Error=0A(probe0:umass-sim0:0:0:1):=20= SCSI=20Status:=20Check=20Condition=0A(probe0:umass-sim0:0:0:1):=20NOT=20= READY=20asc:3a,0=0A(probe0:umass-sim0:0:0:1):=20Medium=20not=20present=0A= (probe0:umass-sim0:0:0:1):=20Unretryable=20error=0Ada0=20at=20umass-sim0=20= bus=200=20target=200=20lun=201=0Ada0:=20=20= Removable=20Direct=20Access=20SCSI-0=20device=20=0Ada0:=2040.000MB/s=20= transfers=0Ada0:=20Attempt=20to=20query=20device=20size=20failed:=20NOT=20= READY,=20Medium=20not=20present=0ATrying=20to=20mount=20root=20from=20= ufs:/dev/ada0s1a=0A<118>Setting=20hostuuid:=20= 03000200-0400-0500-0006-000700080009.=0A<118>Setting=20hostid:=20= 0xfe4ac89c.=0A<118>Entropy=20harvesting:=0A<118>=20interrupts=0A<118>=20= ethernet=0A<118>=20point_to_point=0Augen2.2:=20=20at=20usbus2=0Aukbd0:=20=20on=20usbus2=0A= kbd2=20at=20ukbd0=0Aums0:=20=20on=20usbus2=0Aums0:=20= 3=20buttons=20and=20[XY]=20coordinates=20ID=3D0=0A<118>=20kickstart=0A= <118>.=0A<118>Starting=20file=20system=20checks:=0A<118>/dev/ada0s1a:=20= FILE=20SYSTEM=20CLEAN;=20SKIPPING=20CHECKS=0A<118>/dev/ada0s1a:=20clean,=20= 122687=20free=20(327=20frags,=2015295=20blocks,=200.1%=20fragmentation)=0A= <118>/dev/ada0s1e:=20FILE=20SYSTEM=20CLEAN;=20SKIPPING=20CHECKS=0A= <118>/dev/ada0s1e:=20clean,=20253764=20free=20(36=20frags,=2031716=20= blocks,=200.0%=20fragmentation)=0A<118>/dev/ada0s1f:=20FILE=20SYSTEM=20= CLEAN;=20SKIPPING=20CHECKS=0A<118>/dev/ada0s1f:=20clean,=202235316=20= free=20(40364=20frags,=20274369=20blocks,=200.5%=20fragmentation)=0A= <118>/dev/ada0s1g:=20FILE=20SYSTEM=20CLEAN;=20SKIPPING=20CHECKS=0A= <118>/dev/ada0s1g:=20clean,=2081856257=20free=20(11769=20frags,=20= 10230561=20blocks,=200.0%=20fragmentation)=0A<118>/dev/ada0s1d:=20FILE=20= SYSTEM=20CLEAN;=20SKIPPING=20CHECKS=0A<118>/dev/ada0s1d:=20clean,=20= 2150293=20free=20(373=20frags,=20268740=20blocks,=200.0%=20= fragmentation)=0A<118>Mounting=20local=20file=20systems:=0A<118>.=0A= <118>Setting=20hostname:=20dl0009.sjc02.denetron.net=0A<118>.=0A= <118>ifconfig:=20=0A<118>create:=20bad=20value=0A<118>=0A<118>Starting=20= Network:=20lo0=20em0=20em1=20em0.100=20em0.101=20em0.102=20em0.105=20= em0.300=20em0.304.=0A<118>lo0:=20= flags=3D8049=20metric=200=20mtu=2016384=0A= <118>=09options=3D3=0A<118>=09inet=20127.0.0.1=20netmask=20= 0xff000000=20=0A<118>=09inet6=20::1=20prefixlen=20128=20=0A<118>=09inet6=20= fe80::1%lo0=20prefixlen=2064=20scopeid=200x3=20=0A<118>em0:=20= flags=3D8843=20metric=200=20mtu=20= 1500=0A<118>=09= options=3D19b=0A= <118>=09ether=2000:30:48:be:6f:14=0A<118>=09inet6=20= fe80::230:48ff:febe:6f14%em0=20prefixlen=2064=20tentative=20scopeid=20= 0x1=20=0A<118>=09media:=20Ethernet=20autoselect=0A<118>=09status:=20no=20= carrier=0A<118>em1:=20flags=3D8843= =20metric=200=20mtu=201500=0A<118>=09= options=3D19b=0A= <118>=09ether=2000:30:48:be:6f:15=0A<118>=09inet6=20= fe80::230:48ff:febe:6f15%em1=20prefixlen=2064=20tentative=20scopeid=20= 0x2=20=0A<118>=09media:=20Ethernet=20autoselect=0A<118>=09status:=20no=20= carrier=0A<118>em0.100:=20= flags=3D8843=20metric=200=20mtu=20= 1500=0A<118>=09options=3D3=0A<118>=09ether=20= 00:30:48:be:6f:14=0A<118>=09inet6=20fe80::230:48ff:febe:6f14%em0.100=20= prefixlen=2064=20tentative=20scopeid=200x4=20=0A<118>=09media:=20= Ethernet=20autoselect=0A<118>=09status:=20no=20carrier=0A<118>=09vlan:=20= 100=20parent=20interface:=20em0=0A<118>em0.101:=20= flags=3D8843=20metric=200=20mtu=20= 1500=0A<118>=09options=3D3=0A<118>=09ether=20= 00:30:48:be:6f:14=0A<118>=09inet6=20fe80::230:48ff:febe:6f14%em0.101=20= prefixlen=2064=20tentative=20scopeid=200x5=20=0A<118>=09media:=20= Ethernet=20autoselect=0A<118>=09status:=20no=20carrier=0A<118>=09vlan:=20= 101=20parent=20interface:=20em0=0A<118>em0.102:=20= flags=3D8843=20metric=200=20mtu=20= 1500=0A<118>=09options=3D3=0A<118>=09ether=20= 00:30:48:be:6f:14=0A<118>=09inet6=20fe80::230:48ff:febe:6f14%em0.102=20= prefixlen=2064=20tentative=20scopeid=200x6=20=0A<118>=09media:=20= Ethernet=20autoselect=0A<118>=09status:=20no=20carrier=0A<118>=09vlan:=20= 102=20parent=20interface:=20em0=0A<118>em0.105:=20= flags=3D8843=20metric=200=20mtu=20= 1500=0A<118>=09options=3D3=0A<118>=09ether=20= 00:30:48:be:6f:14=0A<118>=09inet6=20fe80::230:48ff:febe:6f14%em0.105=20= prefixlen=2064=20tentative=20scopeid=200x7=20=0A<118>=09inet=20= 38.108.185.234=20netmask=200xfffffff8=20broadcast=2038.108.185.239=0A= <118>=09media:=20Ethernet=20autoselect=0A<118>=09status:=20no=20carrier=0A= <118>=09vlan:=20105=20parent=20interface:=20em0=0A<118>em0.300:=20= flags=3D8843=20metric=200=20mtu=20= 1500=0A<118>=09options=3D3=0A<118>=09ether=20= 00:30:48:be:6f:14=0A<118>=09inet6=20fe80::230:48ff:febe:6f14%em0.300=20= prefixlen=2064=20tentative=20scopeid=200x8=20=0A<118>=09media:=20= Ethernet=20autoselect=0A<118>=09status:=20no=20carrier=0A<118>=09vlan:=20= 300=20parent=20interface:=20em0=0A<118>em0.304:=20= flags=3D8843=20metric=200=20mtu=20= 1500=0A<118>=09options=3D3=0A<118>=09ether=20= 00:30:48:be:6f:14=0A<118>=09inet6=20fe80::230:48ff:febe:6f14%em0.304=20= prefixlen=2064=20tentative=20scopeid=200x9=20=0A<118>=09inet=20= 38.108.185.242=20netmask=200xfffffff8=20broadcast=2038.108.185.247=0A= <118>=09media:=20Ethernet=20autoselect=0A<118>=09status:=20no=20carrier=0A= <118>=09vlan:=20304=20parent=20interface:=20em0=0A<118>Enabling=20pf=0A= <118>No=20ALTQ=20support=20in=20kernel=0A<118>ALTQ=20related=20functions=20= disabled=0A<118>No=20ALTQ=20support=20in=20kernel=0A<118>ALTQ=20related=20= functions=20disabled=0A<118>No=20ALTQ=20support=20in=20kernel=0A= <118>ALTQ=20related=20functions=20disabled=0A<118>pf=20enabled=0A<118>.=0A= <118>add=20net=20default:=20gateway=2038.108.185.241=0A<118>add=20net=20= ::ffff:0.0.0.0:=20gateway=20::1=0A<118>add=20net=20::0.0.0.0:=20gateway=20= ::1=0A<118>net.inet6.ip6.forwarding:=20=0A<118>0=0A<118>=20->=20=0A= <118>1=0A<118>=0A<118>net.inet6.ip6.accept_rtadv:=20=0A<118>0=0A<118>=20= ->=20=0A<118>0=0A<118>=0A<118>em0:=20= flags=3D8843=20metric=200=20mtu=20= 1500=0A<118>=09= options=3D19b=0A= <118>=09inet6=20fe80::230:48ff:febe:6f14%em0=20prefixlen=2064=20scopeid=20= 0x1=20=0A<118>em1:=20flags=3D8843=20= metric=200=20mtu=201500=0A<118>=09= options=3D19b=0A= <118>=09inet6=20fe80::230:48ff:febe:6f15%em1=20prefixlen=2064=20scopeid=20= 0x2=20=0A<118>lo0:=20flags=3D8049=20= metric=200=20mtu=2016384=0A<118>=09options=3D3=0A<118>=09= inet6=20::1=20prefixlen=20128=20=0A<118>=09inet6=20fe80::1%lo0=20= prefixlen=2064=20scopeid=200x3=20=0A<118>em0.100:=20= flags=3D8843=20metric=200=20mtu=20= 1500=0A<118>=09options=3D3=0A<118>=09inet6=20= fe80::230:48ff:febe:6f14%em0.100=20prefixlen=2064=20scopeid=200x4=20=0A= <118>=09inet6=202001:470:1f05:148::1:1=20prefixlen=20112=20tentative=20=0A= <118>em0.101:=20flags=3D8843=20= metric=200=20mtu=201500=0A<118>=09options=3D3=0A<118>=09= inet6=20fe80::230:48ff:febe:6f14%em0.101=20prefixlen=2064=20scopeid=20= 0x5=20=0A<118>=09inet6=202001:470:1f05:148::3:1=20prefixlen=20112=20= tentative=20=0A<118>em0.102:=20= flags=3D8843=20metric=200=20mtu=20= 1500=0A<118>=09options=3D3=0A<118>=09inet6=20= fe80::230:48ff:febe:6f14%em0.102=20prefixlen=2064=20scopeid=200x6=20=0A= <118>=09inet6=202001:470:1f05:148::2:1=20prefixlen=20112=20tentative=20=0A= <118>em0.105:=20flags=3D8843=20= metric=200=20mtu=201500=0A<118>=09options=3D3=0A<118>=09= inet6=20fe80::230:48ff:febe:6f14%em0.105=20prefixlen=2064=20scopeid=20= 0x7=20=0A<118>=09inet6=202001:470:83f7:ffff::1=20prefixlen=2064=20= tentative=20=0A<118>em0.300:=20= flags=3D8843=20metric=200=20mtu=20= 1500=0A<118>=09options=3D3=0A<118>=09inet6=20= fe80::230:48ff:febe:6f14%em0.300=20prefixlen=2064=20scopeid=200x8=20=0A= <118>=09inet6=202001:470:83f7:3::1=20prefixlen=2064=20tentative=20=0A= <118>em0.304:=20flags=3D8843=20= metric=200=20mtu=201500=0A<118>=09options=3D3=0A<118>=09= inet6=20fe80::230:48ff:febe:6f14%em0.304=20prefixlen=2064=20scopeid=20= 0x9=20=0A<118>=09inet6=202001:470:83f7:2::2=20prefixlen=20112=20= tentative=20=0A<118>gif0:=20flags=3D8051= =20metric=200=20mtu=201280=0A<118>=09tunnel=20inet=2038.108.185.242=20= -->=2072.52.104.74=0A<118>=09inet6=20fe80::230:48ff:febe:6f14%gif0=20= prefixlen=2064=20scopeid=200xa=20=0A<118>=09inet6=202001:470:1f04:148::2=20= -->=202001:470:1f04:148::1=20prefixlen=20128=20tentative=20=0A<118>add=20= net=20fe80:::=20gateway=20::1=0A<118>add=20net=20ff02:::=20gateway=20::1=0A= <118>add=20net=20default:=20gateway=202001:470:1f04:148::1=0A<118>IPv4=20= mapped=20IPv6=20address=20support=3DNO=0A<118>Starting=20devd.=0A= <118>Starting=20ums0=20moused=0A<118>.=0A<118>ELF=20ldconfig=20path:=20= /lib=20/usr/lib=20/usr/lib/compat=20/usr/local/lib=20= /usr/local/lib/mysql=0A<118>32-bit=20compatibility=20ldconfig=20path:=20= /usr/lib32=0A<118>Creating=20and/or=20trimming=20log=20files=0A<118>.=0A= <118>Starting=20syslogd.=0A<118>No=20core=20dumps=20found.=0A= <118>Additional=20ABI=20support:=0A<118>=20linux=0A<118>.=0A<118>Setting=20= date=20via=20ntp.=0A<118>Error=20:=20hostname=20nor=20servname=20= provided,=20or=20not=20known=0A<118>=202=20Feb=2001:59:58=20=0A= <118>ntpdate[1448]:=20can't=20find=20host=20clock.sjc.he.net=0A<118>=0A= <118>Error=20:=20hostname=20nor=20servname=20provided,=20or=20not=20= known=0A<118>=202=20Feb=2001:59:58=20=0A<118>ntpdate[1448]:=20can't=20= find=20host=200.freebsd.pool.ntp.org=0A<118>=0A<118>Error=20:=20hostname=20= nor=20servname=20provided,=20or=20not=20known=0A<118>=202=20Feb=20= 01:59:58=20=0A<118>ntpdate[1448]:=20can't=20find=20host=20= 1.freebsd.pool.ntp.org=0A<118>=0A<118>Error=20:=20hostname=20nor=20= servname=20provided,=20or=20not=20known=0A<118>=202=20Feb=2001:59:58=20=0A= <118>ntpdate[1448]:=20can't=20find=20host=202.freebsd.pool.ntp.org=0A= <118>=0A<118>Error=20:=20hostname=20nor=20servname=20provided,=20or=20= not=20known=0A<118>=202=20Feb=2001:59:58=20=0A<118>ntpdate[1448]:=20= can't=20find=20host=203.freebsd.pool.ntp.org=0A<118>=0A<118>Error=20:=20= hostname=20nor=20servname=20provided,=20or=20not=20known=0A<118>=202=20= Feb=2001:59:58=20=0A<118>ntpdate[1448]:=20can't=20find=20host=20= clock.svwh.net=0A<118>=0A<118>=202=20Feb=2001:59:58=20=0A= <118>ntpdate[1448]:=20no=20servers=20can=20be=20used,=20exiting=0A= <118>Clearing=20/tmp=20(X=20related).=0A<118>Starting=20rpcbind.=0A= <118>Starting=20mountd.=0A<118>Starting=20nfsd.=0A<118>Starting=20= pureftpd.=0A<118>Running:=20/usr/local/sbin/pure-ftpd=20= -g/var/run/pure-ftpd.pid=20-A=20-c10=20-B=20-C8=20-D=20-fftp=20-H=20-I15=20= -L10000:8=20-m4=20-s=20-U133:022=20-u100=20-k99=20-Z=0A<118>Feb=20=202=20= 01:59:59=20dl0009=20pure-ftpd:=20(?@?)=20[ERROR]=20Unable=20to=20find=20= the=20'ftp'=20account=0A<118>Starting=20snmpd.=0A<118>Starting=20smartd.=0A= <118>Feb=20=202=2002:00:01=20dl0009=20smartd[1608]:=20Device:=20= /dev/ada1,=204=20Currently=20unreadable=20(pending)=20sectors=0A<118>Feb=20= =202=2002:00:01=20dl0009=20exim[1610]:=202010-02-02=2002:00:01=20= 1Nc83d-0000Py-Fs=20<=3D=20root@dl0009.sjc02.denetron.net=20U=3Droot=20= P=3Dlocal=20S=3D940=0A<118>Feb=20=202=2002:00:01=20dl0009=20exim[1610]:=20= 2010-02-02=2002:00:01=201Nc83d-0000Py-Fs=20Cannot=20open=20main=20log=20= file=20"/var/log/exim/mainlog":=20Permission=20denied:=20euid=3D26=20= egid=3D6=0A<118>Feb=20=202=2002:00:01=20dl0009=20smartd[1608]:=20Warning=20= via=20mail=20to=20dballenger@denetron.com=20produced=20unexpected=20= output=20(400=20bytes)=20to=20STDOUT/STDERR:=20=202010-02-02=2002:00:01=20= 1Nc83d-0000Py-Fs=20Cannot=20open=20main=20log=20file=20= "/var/log/exim/mainlog":=20Permission=20denied:=20euid=3D26=20egid=3D6=20= 2010-02-02=2002:00:01=201Nc83d-0000Py-Fs=20<=3D=20= root@dl0009.sjc02.denetron.net=20U=3Droot=20P=3Dlocal=20S=3D940=20= 2010-02-02=2002:00:01=201Nc83d-0000Py-Fs=20Cannot=20open=20main=20log=20= file=20"/var/log/exim/mainlog":=20Permission=20denied:=20euid=3D26=20= egid=3D6=20exim:=20could=20not=20open=20panic=20log=20-=20aborting:=20= see=20message(s)=20above=20=0A<118>Feb=20=202=2002:00:01=20dl0009=20= exim[1610]:=20exim:=20could=20not=20open=20panic=20log=20-=20aborting:=20= see=20message(s)=20above=0A<118>Feb=20=202=2002:00:01=20dl0009=20= smartd[1608]:=20Device:=20/dev/ada1,=203=20Offline=20uncorrectable=20= sectors=0A<118>Feb=20=202=2002:00:01=20dl0009=20exim[1612]:=202010-02-02=20= 02:00:01=201Nc83d-0000Q0-Gk=20<=3D=20root@dl0009.sjc02.denetron.net=20= U=3Droot=20P=3Dlocal=20S=3D937=0A<118>Feb=20=202=2002:00:01=20dl0009=20= exim[1612]:=202010-02-02=2002:00:01=201Nc83d-0000Q0-Gk=20Cannot=20open=20= main=20log=20file=20"/var/log/exim/mainlog":=20Permission=20denied:=20= euid=3D26=20egid=3D6=0A<118>Feb=20=202=2002:00:01=20dl0009=20exim[1612]:=20= exim:=20could=20not=20open=20panic=20log=20-=20aborting:=20see=20= message(s)=20above=0A<118>Feb=20=202=2002:00:01=20dl0009=20smartd[1608]:=20= Warning=20via=20mail=20to=20dballenger@denetron.com=20produced=20= unexpected=20output=20(400=20bytes)=20to=20STDOUT/STDERR:=20=20= 2010-02-02=2002:00:01=201Nc83d-0000Q0-Gk=20Cannot=20open=20main=20log=20= file=20"/var/log/exim/mainlog":=20Permission=20denied:=20euid=3D26=20= egid=3D6=202010-02-02=2002:00:01=201Nc83d-0000Q0-Gk=20<=3D=20= root@dl0009.sjc02.denetron.net=20U=3Droot=20P=3Dlocal=20S=3D937=20= 2010-02-02=2002:00:01=201Nc83d-0000Q0-Gk=20Cannot=20open=20main=20log=20= file=20"/var/log/exim/mainlog":=20Permission=20denied:=20euid=3D26=20= egid=3D6=20exim:=20could=20not=20open=20panic=20log=20-=20aborting:=20= see=20message(s)=20above=20=0A<118>Feb=20=202=2002:00:01=20dl0009=20= smartd[1608]:=20Device:=20/dev/ada1,=20previous=20self-test=20completed=20= with=20error=20(read=20test=20element)=0A<118>Updating=20motd:=0A<118>.=0A= <118>Starting=20ntpd.=0A<118>Performing=20sanity=20check=20on=20apache22=20= configuration:=0A<118>Syntax=20OK=0A<118>Starting=20apache22.=0A= <118>Configuring=20syscons:=0A<118>=20blanktime=0A<118>=20screensaver=0A= <5>fire_saver:=20the=20console=20does=20not=20support=20M_VGA_CG320=0A= module_register_init:=20MOD_LOAD=20(fire_saver,=200xffffffff8106f000,=20= 0)=20error=2019=0A<118>.=0A<118>Starting=20sshd.=0A<118>Starting=20cron.=0A= <118>/etc/rc.d/sysctl:=20WARNING:=20sysctl=20net.link.tap.user_open=20= does=20not=20exist.=0A<118>/etc/rc.d/sysctl:=20WARNING:=20sysctl=20= net.link.tap.up_on_open=20does=20not=20exist.=0A<118>Starting=20inetd.=0A= <118>Starting=20background=20file=20system=20checks=20in=2060=20seconds.=0A= <118>=0A<118>Tue=20Feb=20=202=2002:00:04=20UTC=202010=0A<118>Feb=20=202=20= 02:01:19=20dl0009=20su:=20dballenger=20to=20root=20on=20/dev/pts/0=0A= panic:=20tdsignal():=20invalid=20signal=200=0Acpuid=20=3D=200=0AKDB:=20= enter:=20panic=0A=0A0xffffff0067871588:=20tag=20ufs,=20type=20VDIR=0A=20=20= =20=20usecount=201,=20writecount=200,=20refcount=205=20mountedhere=200=0A= =20=20=20=20flags=20()=0A=20=20=20=20v_object=200xffffff006785c000=20ref=20= 0=20pages=206=0A=20=20=20=20lock=20type=20ufs:=20SHARED=20(count=201)=0A=09= ino=2012930093,=20on=20dev=20ada0s1g=0A=0A0xffffff0006f25ce8:=20tag=20= ufs,=20type=20VNON=0A=20=20=20=20usecount=201,=20writecount=200,=20= refcount=201=20mountedhere=200=0A=20=20=20=20flags=20()=0A=20=20=20=20= lock=20type=20ufs:=20EXCL=20by=20thread=200xffffff0006554ab0=20(pid=20= 1922)=0A=09ino=2012942467,=20on=20dev=20ada0s1g=0A= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00panic.txt=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=000600=00=00= =00=000=00=00=00=00=00=00=000=00=00=00=00=00=00=0034=00=00=00=00=00=00=00=00= =00=0011331704434=00=20=207135=00=20= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00ustar=00=00=00root=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00wheel=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00tdsignal= ():=20invalid=20signal=20= 0=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00version.txt=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=000600=00=00=00=000=00=00=00=00=00=00=000=00=00=00=00=00=00=00170=00=00= =00=00=00=00=00=00=0011331704434=00=20=207611=00=20= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00ustar=00=00=00root=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00wheel=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00FreeBSD=20= 8.0-RELEASE-p2=20#2:=20Tue=20Feb=20=202=2001:14:26=20UTC=202010=0A=20=20=20= =20root@dl0009.sjc02.denetron.net:/usr/obj/usr/src/sys/GENERIC=0A= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= --Apple-Mail-10--993161082-- --Apple-Mail-11--993160891-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 06:36:40 2010 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 B554210656A4 for ; Tue, 2 Feb 2010 06:36:40 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail14.syd.optusnet.com.au (mail14.syd.optusnet.com.au [211.29.132.195]) by mx1.freebsd.org (Postfix) with ESMTP id 4507B8FC2A for ; Tue, 2 Feb 2010 06:36:40 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c122-106-232-148.belrs3.nsw.optusnet.com.au [122.106.232.148]) by mail14.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o126aakp002714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Feb 2010 17:36:37 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id o126aavX064696; Tue, 2 Feb 2010 17:36:36 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id o126aZdo064695; Tue, 2 Feb 2010 17:36:35 +1100 (EST) (envelope-from peter) Date: Tue, 2 Feb 2010 17:36:35 +1100 From: Peter Jeremy To: Andriy Gapon Message-ID: <20100202063635.GA64643@server.vk2pj.dyndns.org> References: <20100201085131.GA34006@server.vk2pj.dyndns.org> <4B66A0DD.2070109@icyb.net.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline In-Reply-To: <4B66A0DD.2070109@icyb.net.ua> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Kernel probe order issues 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, 02 Feb 2010 06:36:40 -0000 --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Feb-01 11:37:33 +0200, Andriy Gapon wrote: >> This strikes me as undesirable. Is there some way to bump up the >> probe/attach priority of console input devices to ensure that they >> exist before the kernel tries to read input? > >It seems to be a problem with either your keyboard or your USB controller. >USB keyboard can be discovered much earlier than mountroot if the hardware= is >ready. No magical software priority bump can help here. I've tried a couple of different USB ports (controllers) with no change in behaviour. I'll try another keyboard if I can find one. It _does_ work as expected on 7.x so this is a regression. --=20 Peter Jeremy --X1bOJ3K7DJ5YkBrT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEUEARECAAYFAktnx/MACgkQ/opHv/APuIf/dQCYwUGkDo5J90dMghLw6CMqBSD+ yQCgjX37zHq1ImLZTXtkMTbLWubYrZQ= =Goke -----END PGP SIGNATURE----- --X1bOJ3K7DJ5YkBrT-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 06:39:42 2010 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 0D2681065692 for ; Tue, 2 Feb 2010 06:39:42 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 509FB8FC29 for ; Tue, 2 Feb 2010 06:39:40 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id IAA07647; Tue, 02 Feb 2010 08:39:36 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1NcCQC-000KnE-CI; Tue, 02 Feb 2010 08:39:36 +0200 Message-ID: <4B67C8A6.5050102@icyb.net.ua> Date: Tue, 02 Feb 2010 08:39:34 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091128) MIME-Version: 1.0 To: Peter Jeremy References: <20100201085131.GA34006@server.vk2pj.dyndns.org> <4B66A0DD.2070109@icyb.net.ua> <20100202063635.GA64643@server.vk2pj.dyndns.org> In-Reply-To: <20100202063635.GA64643@server.vk2pj.dyndns.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Kernel probe order issues 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, 02 Feb 2010 06:39:42 -0000 on 02/02/2010 08:36 Peter Jeremy said the following: > On 2010-Feb-01 11:37:33 +0200, Andriy Gapon wrote: >>> This strikes me as undesirable. Is there some way to bump up the >>> probe/attach priority of console input devices to ensure that they >>> exist before the kernel tries to read input? >> It seems to be a problem with either your keyboard or your USB controller. >> USB keyboard can be discovered much earlier than mountroot if the hardware is >> ready. No magical software priority bump can help here. > > I've tried a couple of different USB ports (controllers) with no > change in behaviour. I'll try another keyboard if I can find one. It > _does_ work as expected on 7.x so this is a regression. Unfortunately you keep being low on hardware details. For me going from stable/7 to stable/8 resulted in an improvement of the opposite nature on two different systems: now my keyboard is detected before disks are detected, whereas previously it was detected some time later. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 09:45:26 2010 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 9A9FC1065670 for ; Tue, 2 Feb 2010 09:45:26 +0000 (UTC) (envelope-from giovanni.trematerra@gmail.com) Received: from mail-fx0-f225.google.com (mail-fx0-f225.google.com [209.85.220.225]) by mx1.freebsd.org (Postfix) with ESMTP id 2F2EF8FC14 for ; Tue, 2 Feb 2010 09:45:25 +0000 (UTC) Received: by fxm25 with SMTP id 25so242789fxm.34 for ; Tue, 02 Feb 2010 01:45:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LduZVNARHzYlW7HL1ulmPhBW7gSJhQJi60LYKPxf1xE=; b=Yr6gI3GisGH6DLzjplu0hRWIQJzButdx2lqQyBCwywr7mNsu3XvSYKlc1Ah0UfbZ/Q HI+CsAYI46Edqo2FRh2KVbgu26gxL/ZgVEJUuK7hLSJFyYfx2cLXU99TskKTM+ei55Cn GQ4z+3xetHnJGsAri9K/RKHwB60QjBukuyzEw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=F8y/8LhYG7iDfJH+8zzvXaaXtTtqjP+OiK0xx0yHHl29iWgBZ9VBbSviFDT+hW9tBl a++qv/iTqiS4s75SIHEuuwTIDLXBFQMP8olMx8SBrhJLwSOpYn6XblLXl6CVJ3TxncnS J8jG9pZz5DtVOSZlNFLH2IDgTcjDSzKLJ/o28= MIME-Version: 1.0 Received: by 10.223.29.199 with SMTP id r7mr5946690fac.73.1265103924511; Tue, 02 Feb 2010 01:45:24 -0800 (PST) In-Reply-To: <70F28BB5-1472-4067-B0F5-52B84E337514@svwh.net> References: <4e6cba831002011421w6316ac6dx3e06a73ed35c7202@mail.gmail.com> <70F28BB5-1472-4067-B0F5-52B84E337514@svwh.net> Date: Tue, 2 Feb 2010 10:45:24 +0100 Message-ID: <4e6cba831002020145j6fd280cbt924c40c8b5ee90ad@mail.gmail.com> From: Giovanni Trematerra To: Daniel Ballenger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Kernel Panic on Freebsd 8-RELEASE 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, 02 Feb 2010 09:45:26 -0000 On Tue, Feb 2, 2010 at 3:14 AM, Daniel Ballenger wrote: > On Feb 1, 2010, at 2:21 PM, Giovanni Trematerra wrote: >> On Mon, Feb 1, 2010 at 10:44 PM, Daniel Ballenger wrote: >>> >>> >>> The crash is repeatable (occurs everytime for me). =A0I also confirmed = that another FreeBSD 8 machine I have ran into the same >>> panic (also amd= 64). Hi, Daniel The bug was resolved in HEAD r200667 and 8-STABLE in r200668 Hope this help -- Gianni From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 09:51:51 2010 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 DF17C10656A3 for ; Tue, 2 Feb 2010 09:51:51 +0000 (UTC) (envelope-from giovanni.trematerra@gmail.com) Received: from mail-fx0-f225.google.com (mail-fx0-f225.google.com [209.85.220.225]) by mx1.freebsd.org (Postfix) with ESMTP id 707D28FC12 for ; Tue, 2 Feb 2010 09:51:50 +0000 (UTC) Received: by fxm25 with SMTP id 25so248658fxm.34 for ; Tue, 02 Feb 2010 01:51:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LOuouFNRTypGgoOx2xt/quQiZm34FPGhdbFKsP58qVw=; b=KHNNhvn7elBYzjIaUp1hcOUcNbadQvC62krofx7CSxPNFEK1W33H3yfXUFiqbf92ws tUc8JPoSQ3wxeY9pSAW1KHwjuXJ3/H9qpBIMAKXyoVr++n7ZR72qiQoLhG8R7yDjVjFn 3R+FHFsnMTM/HrHSHpOsBRQbRSSwS7NJqugcQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=MfXAbtZKd+X1m8WRLCS4wjiqQlgTUAXlE+UH001PMCnw+EzUqZVlFPFNiIUEQn8u9I nOneTHTWqhz8L/C4F4hPi8YvUmFzuuJEUxHXs0VRYH0oQJOWb3AVPNrkgreoI3XV18Jv PVtkQojjxKqwHj41D/x0g2xUBbrYqcljKzOqc= MIME-Version: 1.0 Received: by 10.223.3.27 with SMTP id 27mr1008237fal.8.1265104310322; Tue, 02 Feb 2010 01:51:50 -0800 (PST) In-Reply-To: <4e6cba831002020145j6fd280cbt924c40c8b5ee90ad@mail.gmail.com> References: <4e6cba831002011421w6316ac6dx3e06a73ed35c7202@mail.gmail.com> <70F28BB5-1472-4067-B0F5-52B84E337514@svwh.net> <4e6cba831002020145j6fd280cbt924c40c8b5ee90ad@mail.gmail.com> Date: Tue, 2 Feb 2010 10:51:50 +0100 Message-ID: <4e6cba831002020151k634529deq460105ee44741bcd@mail.gmail.com> From: Giovanni Trematerra To: Daniel Ballenger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Kernel Panic on Freebsd 8-RELEASE 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, 02 Feb 2010 09:51:52 -0000 On Tue, Feb 2, 2010 at 10:45 AM, Giovanni Trematerra wrote: > On Tue, Feb 2, 2010 at 3:14 AM, Daniel Ballenger wrote: >> On Feb 1, 2010, at 2:21 PM, Giovanni Trematerra wrote: >>> On Mon, Feb 1, 2010 at 10:44 PM, Daniel Ballenger wrote: >>>> >>>> >>>> The crash is repeatable (occurs everytime for me). =A0I also confirmed= that another FreeBSD 8 machine I have ran into the same >>> panic (also am= d64). > > Hi, Daniel > The bug was resolved in HEAD r200667 and =A08-STABLE in r200668 > > Hope this help > Sorry I was wrong for 8-STABLE the fix is in r200768 > -- > Gianni > From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 14:21:44 2010 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 DC3A8106568F for ; Tue, 2 Feb 2010 14:21:44 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id A47028FC0C for ; Tue, 2 Feb 2010 14:21:44 +0000 (UTC) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NcJdQ-000Dm4-2O for freebsd-stable@freebsd.org; Tue, 02 Feb 2010 14:21:44 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NcJdQ-000Lv0-1W for freebsd-stable@freebsd.org; Tue, 02 Feb 2010 14:21:44 +0000 Date: Tue, 02 Feb 2010 14:21:44 +0000 Message-Id: To: freebsd-stable@freebsd.org From: Pete French Subject: patch for /usr/bin/mail 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, 02 Feb 2010 14:21:44 -0000 This patch fixes a problem of mail missing addresses when replying to emails generated by some Microsoft systems, which do not insert a space after the comma in lists of addresses. Was filed as PR bin/131861 If anyone who still uses /usr/bin/mail as their primarly email client could test it then I would be grateful (would also be garetful if someone could volunteer to commit it shold it prove to work fine :-) ) -pete. --- usr.bin/mail/util.c.orig 2010-02-02 14:10:34.220987358 +0000 +++ usr.bin/mail/util.c 2010-02-02 14:12:49.968147827 +0000 @@ -496,10 +496,10 @@ *cp2++ = ' '; } *cp2++ = c; - if (c == ',' && *cp == ' ' && !gotlt) { + if (c == ',' && (*cp == ' ' || *cp == '"') && !gotlt) { *cp2++ = ' '; - while (*++cp == ' ') - ; + while (*cp == ' ') + cp++; lastsp = 0; bufend = cp2; } From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 14:28:20 2010 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 F0D8B106566B for ; Tue, 2 Feb 2010 14:28:20 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by mx1.freebsd.org (Postfix) with ESMTP id CD1168FC0A for ; Tue, 2 Feb 2010 14:28:20 +0000 (UTC) Received: from omta13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by qmta10.emeryville.ca.mail.comcast.net with comcast id d1M41d00817UAYkAA2UMlT; Tue, 02 Feb 2010 14:28:21 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta13.emeryville.ca.mail.comcast.net with comcast id d2UL1d0063S48mS8Z2ULQ9; Tue, 02 Feb 2010 14:28:21 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 8D8541E3035; Tue, 2 Feb 2010 06:28:19 -0800 (PST) Date: Tue, 2 Feb 2010 06:28:19 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100202142819.GA71870@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: patch for /usr/bin/mail 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, 02 Feb 2010 14:28:21 -0000 On Tue, Feb 02, 2010 at 02:21:44PM +0000, Pete French wrote: > This patch fixes a problem of mail missing addresses when replying > to emails generated by some Microsoft systems, which do not insert a > space after the comma in lists of addresses. Was filed as PR bin/131861 > If anyone who still uses /usr/bin/mail as their primarly email client > could test it then I would be grateful (would also be garetful if > someone could volunteer to commit it shold it prove to work fine :-) ) > > -pete. > > --- usr.bin/mail/util.c.orig 2010-02-02 14:10:34.220987358 +0000 > +++ usr.bin/mail/util.c 2010-02-02 14:12:49.968147827 +0000 > @@ -496,10 +496,10 @@ > *cp2++ = ' '; > } > *cp2++ = c; > - if (c == ',' && *cp == ' ' && !gotlt) { > + if (c == ',' && (*cp == ' ' || *cp == '"') && !gotlt) { > *cp2++ = ' '; > - while (*++cp == ' ') > - ; > + while (*cp == ' ') > + cp++; > lastsp = 0; > bufend = cp2; > } For what it's worth: note that Outlook, by default, uses semi-colon as its delimiter between addresses in To/Cc/Bcc fields. The SMTP portion of the Exchange interface might turn these into commas though, but I'm not 100% certain (I'd have to manually check -- let me know if you want me to). -- | Jeremy Chadwick jdc@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 Tue Feb 2 14:34:17 2010 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 E16F8106566C for ; Tue, 2 Feb 2010 14:34:17 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id A9E648FC0C for ; Tue, 2 Feb 2010 14:34:17 +0000 (UTC) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NcJpT-000DvY-Sa; Tue, 02 Feb 2010 14:34:11 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NcJpT-000Lzu-Rc; Tue, 02 Feb 2010 14:34:11 +0000 Date: Tue, 02 Feb 2010 14:34:11 +0000 Message-Id: To: freebsd-stable@freebsd.org, freebsd@jdc.parodius.com In-Reply-To: <20100202142819.GA71870@icarus.home.lan> From: Pete French Cc: Subject: Re: patch for /usr/bin/mail 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, 02 Feb 2010 14:34:18 -0000 > For what it's worth: note that Outlook, by default, uses semi-colon as > its delimiter between addresses in To/Cc/Bcc fields. The SMTP portion > of the Exchange interface might turn these into commas though, but I'm > not 100% certain (I'd have to manually check -- let me know if you want > me to). It would be inetersting to see what the arrive as when they have been written onto a FreeBSd hhost by the mail transport certainly! That might actually be the source of this bug if they come out with commas but no spaces. cheers, -pete. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 14:59:12 2010 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 4EECC10656A5; Tue, 2 Feb 2010 14:59:12 +0000 (UTC) (envelope-from flo@smeets.im) Received: from mail.solomo.de (mail.solomo.de [85.214.124.163]) by mx1.freebsd.org (Postfix) with ESMTP id 010638FC1B; Tue, 2 Feb 2010 14:59:11 +0000 (UTC) Received: from mail.solomo.de (localhost [127.0.0.1]) by mail.solomo.de (Postfix) with ESMTP id 1E1126218E; Tue, 2 Feb 2010 15:59:11 +0100 (CET) X-Virus-Scanned: amavisd-new at vistream.de Received: from mail.solomo.de ([127.0.0.1]) by mail.solomo.de (mail.solomo.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YRZkeO80416y; Tue, 2 Feb 2010 15:59:08 +0100 (CET) Received: from nibbler.vistream.local (relay3.vistream.de [87.139.10.28]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.solomo.de (Postfix) with ESMTPSA id 9003462180; Tue, 2 Feb 2010 15:59:08 +0100 (CET) Message-ID: <4B683DBC.1090604@smeets.im> Date: Tue, 02 Feb 2010 15:59:08 +0100 From: Florian Smeets User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a1pre) Gecko/20100131 Shredder/3.2a1pre MIME-Version: 1.0 To: Max Laier References: <4B58280C.50602@smeets.im> <201001221818.20409.max@love2party.net> <201001221349.19810.jhb@freebsd.org> <201001222055.45980.max@love2party.net> In-Reply-To: <201001222055.45980.max@love2party.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Luigi Rizzo , Bjoern Zeeb , freebsd-stable@freebsd.org, John Baldwin Subject: Re: 7.2-STABLE page fault with kernel from 12.01.2010 / crashinfo 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: Tue, 02 Feb 2010 14:59:12 -0000 On 1/22/10 8:55 PM, Max Laier wrote: > On Friday 22 January 2010 19:49:19 John Baldwin wrote: >> On Friday 22 January 2010 12:18:20 pm Max Laier wrote: >>> >>> pf does change the byte order in the pfil hook, but changes it back on >>> return to the stack either when returning from the hook or when calling >>> back into the stack. There have been some issues where we missed returns >>> to the stack that would result in this situation, but since pf is not in >>> the trace, this is clearly not the case here. >> >> That isn't necessarily the case. ip_input() invokes the PFIL hooks which >> then return after possibly modifying the packet. The (possibly modified) >> packet is then passed to ip_forward() from ip_input(). If the PFIL hook >> modified the packet and returned ip_len in network byte order then it would >> cause this breakage without showing up in the stack trace. > > What I meant to say was: if we return from the pfil hook we either report > error (and/or consume the mbuf) or switch back to network byte order: > > http://fxr.watson.org/fxr/source/contrib/pf/net/pf_ioctl.c?v=FREEBSD72#L3655 > > While I can't completely rule out that there is a double flip happening in > some obscure path through pf, I very much doubt this is what is going on (or > there would be more reports and it would happen straight away, not only after > passing some data). A quick search through the sources also didn't turn up > any red flags. All byte order operations inside pf are either temporary or > performed on a properly copied packet that is send back through the stack > (icmp error, tcp packet, ...). > > Depending on how easily this can be reproduced, my money is on modifying a > shared mbuf (possibly inside enc(4)). > I have been running with a WITNESS kernel for 10 days now, and have tried quite a few things to reproduce the problem, but no luck so far. I'll post again if i find something. Thanks to everyone involved! Cheers, Florian From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 16:44:02 2010 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 ECE8E106566B for ; Tue, 2 Feb 2010 16:44:02 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f218.google.com (mail-bw0-f218.google.com [209.85.218.218]) by mx1.freebsd.org (Postfix) with ESMTP id 6C2008FC15 for ; Tue, 2 Feb 2010 16:44:01 +0000 (UTC) Received: by bwz10 with SMTP id 10so251986bwz.35 for ; Tue, 02 Feb 2010 08:44:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=fwZq5693NDgd5L5IDqQsng5uwgUgB4z6zwAahAeheio=; b=Jwo9d1+2Y2KjUMxkEJXhyR4AHmT7ClijtuTAc3O49e8WbtNR/XZOqaNK6x0znAKgWz eZcnmU6uTggV4dGyPgPsMXrRXUy/ujcgmjfvGimLvZEAstdgHBbYgBMosHankXcuu172 c2L2n15KYT352vzHf+E1g9k6/WDpukge8w8tI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=cdFBG0+CgNlGjWFlOevvNivgtVkuRGCgyW26NQwcgGIVSFi6U5KN90WgC+Ls26VdBQ 6TRR/mkzxzM8ySrUQuYuXYUb2yEpatJISwa5FdWnsQEfoccYbBs6Bjfg5a9l7ajQjBIo r/2s7fhaCKo309MH+ezgLyUweKySPLkR1Tpn0= MIME-Version: 1.0 Received: by 10.204.135.214 with SMTP id o22mr329142bkt.55.1265129040822; Tue, 02 Feb 2010 08:44:00 -0800 (PST) Date: Tue, 2 Feb 2010 19:44:00 +0300 Message-ID: From: pluknet To: freebsd-stable Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Subject: nmi_calltrap in siopoll() 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, 02 Feb 2010 16:44:03 -0000 Hi. I've got NMI on an almost idle system - FreeBSD 7.2-R amd64. I guess the reason may be in (hardware?) binary garbage seen once in a while on serial port (loader, then ttyd0). Ask me for more details. Tracing command swi4: clock sio pid 20 tid 100011 td 0xffffff000144e370 cpustop_handler() at cpustop_handler+64 ipi_nmi_handler() at ipi_nmi_handler+48 trap() at trap+796 nmi_calltrap() at nmi_calltrap+8 --- trap 19, rip =3D 18446744071567390785, rsp =3D 18446744067267268592, rbp =3D 18446744067267558272 --- _mtx_lock_spin() at _mtx_lock_spin+113 siopoll() at siopoll+206 ithread_loop() at ithread_loop+384 fork_exit() at fork_exit+287 fork_trampoline() at fork_trampoline+14 --- trap 0, rip =3D 0, rsp =3D 18446744067267558704, rbp =3D 0 --- (kgdb) thr 13 [Switching to thread 13 (Thread 100011)]#0 cpustop_handler () at atomic.h:= 264 264 atomic.h: No such file or directory. in atomic.h (kgdb) bt #0 cpustop_handler () at atomic.h:264 #1 0xffffffff807ec400 in ipi_nmi_handler () at /usr/src/sys/amd64/amd64/mp_machdep.c:1144 #2 0xffffffff807fceec in trap (frame=3D0xfffffffe80028f40) at /usr/src/sys/amd64/amd64/trap.c:198 #3 0xffffffff807e0aeb in nmi_calltrap () at /usr/src/sys/amd64/amd64/exception.S:427 #4 0xffffffff80513841 in _mtx_lock_spin (m=3D0xffffffff80bb3d00, tid=3D18446742974219215728, opts=3DVariable "opts" is not available. ) at /usr/src/sys/kern/kern_mutex.c:474 #5 0xffffffff8082b96e in siopoll (dummy=3DVariable "dummy" is not availabl= e. ) at /usr/src/sys/dev/sio/sio.c:1703 #6 0xffffffff804ff940 in ithread_loop (arg=3D0xffffff000142bac0) at /usr/src/sys/kern/kern_intr.c:1088 #7 0xffffffff804fc1df in fork_exit ( callout=3D0xffffffff804ff7c0 , arg=3D0xffffff000142bac0, frame=3D0xfffffffe8006fc80) at /usr/src/sys/kern/kern_fork.c:834 #8 0xffffffff807e0b5e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:455 #9 0x0000000000000000 in ?? () #10 0x0000000000000000 in ?? () #11 0x0000000000000001 in ?? () #12 0x0000000000000000 in ?? () #13 0x0000000000000000 in ?? () #14 0x0000000000000000 in ?? () ---Type to continue, or q to quit---q Quit (kgdb) f 5 #5 0xffffffff8082b96e in siopoll (dummy=3DVariable "dummy" is not availabl= e. ) at /usr/src/sys/dev/sio/sio.c:1703 1703 mtx_lock_spin(&sio_lock); (kgdb) i loc _tid =3D Variable "_tid" is not available. (kgdb) list 1698 com_events -=3D incc; 1699 mtx_unlock_spin(&sio_lock); 1700 continue; 1701 } 1702 if (com->iptr !=3D com->ibuf) { 1703 mtx_lock_spin(&sio_lock); 1704 sioinput(com); 1705 mtx_unlock_spin(&sio_lock); 1706 } 1707 if (com->state & CS_CHECKMSR) { (kgdb) p sio_lock $1 =3D {lock_object =3D {lo_name =3D 0xffffffff80b15380 "sio", lo_type =3D 0xffffffff80b15380 "sio", lo_flags =3D 458752, lo_witness_d= ata =3D { lod_list =3D {stqe_next =3D 0x0}, lod_witness =3D 0x0}}, mtx_lock =3D 18446742974219094608, mtx_recurse =3D 0} (kgdb) p/x sio_lock->mtx_lock $10 =3D 0xffffff0001430a50 # =3D=3D td for pid 17 tid 100008 Binary garbage is like below (not touching anything on k/board atm). login: FreeBSD/amd64 (ho FreeBSD/amd64 (host) (ttyd0) login: <<|=FE FreeBSD FreeBSD FreeBS FreeBSD Free FreeBSD/amd64 (host) (ttyd0) login: FreeBSD/amd64 (host) (ttyd0) login: FreeBSD Free FreeBS FreeBSD FreeBS FreeBSD FreeBSD FreeBS FreeBSD FreeBS FreeBSD FreeBSD FreeBS FreeBSD FreeBS=A0=A8H=C8=C9 M5 FreeBSD FreeBS FreeBSD FreeBSD FreeBS FreeBSD FreeBS=A0=A8H=C8=C9 M5 FreeBSD FreeBS FreeBSD FreeB FreeBSD/amd6 FreeBS FreeBS FreeBSD FreeBSD FreeBS FreeBSD FreeBS FreeBSD FreeBSD FreeBS FreeBSD FreeBS=A0=A8H=C8=C9 M5 FreeBSD FreeBS FreeBSD [..a little later..] [root@host ~]# <<<<<<<<<<<><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<8<<<<<8<<<< <<<<<<<<<<<<<<<<<<<<<<<<<<<<<8<<<<<<<>< Other useful stuff. (kgdb) f 4 #4 0xffffffff80513841 in _mtx_lock_spin (m=3D0xffffffff80bb3d00, tid=3D18446742974219215728, opts=3DVariable "opts" is not available. ) at /usr/src/sys/kern/kern_mutex.c:474 474 while (m->mtx_lock !=3D MTX_UNOWNED) { (kgdb) list 469 lock_profile_obtain_lock_failed(&m->lock_object, &contested, &waittime); 470 while (!_obtain_lock(m, tid)) { 471 472 /* Give interrupts a chance while we spin. */ 473 spinlock_exit(); 474 while (m->mtx_lock !=3D MTX_UNOWNED) { 475 if (i++ < 10000000) { 476 cpu_spinwait(); 477 continue; 478 } (kgdb) f 3 #3 0xffffffff807e0aeb in nmi_calltrap () at /usr/src/sys/amd64/amd64/exception.S:427 427 call trap Current language: auto; currently asm (kgdb) list 422 swapgs 423 /* Note: this label is also used by ddb and gdb: */ 424 nmi_calltrap: 425 FAKE_MCOUNT(TF_RIP(%rsp)) 426 movq %rsp, %rdi 427 call trap 428 MEXITCOUNT 429 testl %ebx,%ebx 430 jz nmi_restoreregs 431 swapgs (kgdb) f 2 #2 0xffffffff807fceec in trap (frame=3D0xfffffffe80028f40) at /usr/src/sys/amd64/amd64/trap.c:198 198 if (ipi_nmi_handler() =3D=3D 0) Current language: auto; currently c (kgdb) list 193 194 #ifdef SMP 195 #ifdef STOP_NMI 196 /* Handler for NMI IPIs used for stopping CPUs. */ 197 if (type =3D=3D T_NMI) { 198 if (ipi_nmi_handler() =3D=3D 0) 199 goto out; 200 } 201 #endif /* STOP_NMI */ 202 #endif /* SMP */ db> bt Tracing pid 17 tid 100008 td 0xffffff0001430a50 kdb_enter_why() at kdb_enter_why+0x3d siointr1() at siointr1+0x2c5 siointr() at siointr+0x58 intr_execute_handlers() at intr_execute_handlers+0x8b Xapic_isr1() at Xapic_isr1+0x7f --- interrupt, rip =3D 0xffffffff807d8bd6, rsp =3D 0xfffffffe8005fb90, rbp =3D 0xfffffffe8005fba0 --- acpi_cpu_c1() at acpi_cpu_c1+0x6 acpi_cpu_idle() at acpi_cpu_idle+0x19c sched_idletd() at sched_idletd+0x46 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xfffffffe8005fd30, rbp =3D 0 --- (kgdb) p (struct thread) *sio_lock->mtx_lock $15 =3D {td_lock =3D 0xffffffff80b7bc40, td_proc =3D 0xffffff000142e478, td= _plist =3D { tqe_next =3D 0x0, tqe_prev =3D 0xffffff000142e488}, td_slpq =3D {tqe_ne= xt =3D 0x0, tqe_prev =3D 0x0}, td_lockq =3D {tqe_next =3D 0x0, tqe_prev =3D 0x0}, t= d_selq =3D { tqh_first =3D 0x0, tqh_last =3D 0x0}, td_sleepqueue =3D 0xffffff0001418= c00, td_turnstile =3D 0xffffff00012f9a00, td_umtxq =3D 0xffffff000142a380, td_tid =3D 100008, td_sigqueue =3D {sq_signals =3D {__bits =3D {0, 0, 0, = 0}}, sq_kill =3D {__bits =3D {0, 0, 0, 0}}, sq_list =3D {tqh_first =3D 0x0, tqh_last =3D 0xffffff0001430ae0}, sq_proc =3D 0xffffff000142e478, sq_flags =3D 1}, td_flags =3D 65572, td_inhibitors =3D 0, td_pflags =3D= 0, td_dupfd =3D 0, td_sqqueue =3D 0, td_wchan =3D 0x0, td_wmesg =3D 0x0, td_lastcpu =3D 1 '\001', td_oncpu =3D 1 '\001', td_owepreempt =3D 0 '\0', td_locks =3D 0, td_tsqueue =3D 0 '\0', td_blocked =3D 0x0, td_lockname = =3D 0x0, td_contested =3D {lh_first =3D 0x0}, td_sleeplocks =3D 0x0, td_intr_nesting_level =3D 1, td_pinned =3D 0, td_mailbox =3D 0x0, td_ucred =3D 0xffffff0001300e00, td_standin =3D 0x0, td_upcall =3D 0x0, td_estcpu =3D 0, td_slptick =3D 0, td_ru =3D {ru_utime =3D {tv_sec =3D 0, tv_usec =3D 0}, ru_stime =3D {tv_sec =3D 0, tv_usec =3D 0}, ru_maxrss= =3D 0, ru_ixrss =3D 0, ru_idrss =3D 0, ru_isrss =3D 0, ru_minflt =3D 0, ru_maj= flt =3D 0, ru_nswap =3D 0, ru_inblock =3D 0, ru_oublock =3D 0, ru_msgsnd =3D 0, ru_msgrcv =3D 0, ru_nsignals =3D 0, ru_nvcsw =3D 6414, ru_nivcsw =3D 38= 607927}, td_runtime =3D 2179322361251400, td_pticks =3D 145105307, td_sticks =3D 7= 704049, td_iticks =3D 0, td_uticks =3D 0, td_uuticks =3D 0, td_usticks =3D 0, td_intrval =3D 0, td_oldsigmask =3D {__bits =3D {0, 0, 0, 0}}, td_sigmask= =3D { ---Type to continue, or q to quit--- __bits =3D {0, 0, 0, 0}}, td_generation =3D 38614341, td_sigstk =3D { ss_sp =3D 0x0, ss_size =3D 0, ss_flags =3D 0}, td_kflags =3D 0, td_xsig= =3D 0, td_profil_addr =3D 0, td_profil_ticks =3D 0, td_name =3D '\0' , td_base_pri =3D 255 '=FF', td_priority =3D 255 '=FF', td_pri_class =3D 4 = '\004', td_user_pri =3D 180 '=B4', td_base_user_pri =3D 180 '=B4', td_pcb =3D 0xfffffffe8005fd40, td_state =3D TDS_RUNNING, td_retval =3D {0= , 0}, td_slpcallout =3D {c_links =3D {sle =3D {sle_next =3D 0x0}, tqe =3D {tqe_= next =3D 0x0, tqe_prev =3D 0x0}}, c_time =3D 0, c_arg =3D 0x0, c_func =3D 0, c_mt= x =3D 0x0, c_flags =3D 16}, td_frame =3D 0xfffffffe8005fc80, td_kstack_obj =3D 0xffffff0001431740, td_kstack =3D 18446744067267477504, td_kstack_pages =3D 4, td_altkstack_obj =3D 0x0, td_altkstack =3D 0, td_altkstack_pages =3D 0, td_critnest =3D 2, td_md =3D {md_spinlock_count= =3D 1, md_saved_flags =3D 70}, td_sched =3D 0xffffff0001430d80, td_ar =3D 0x0, td_syscalls =3D 0, td_incruntime =3D 115662355444194, td_cpuset =3D 0xffffff0001424dc8, td_fpop =3D 0x0, td_dtrace =3D 0x0, td_= errno =3D 0} (kgdb) p (struct proc) *0xffffff000142e478 $16 =3D {p_list =3D {le_next =3D 0xffffff000142e8f0, le_prev =3D 0xffffff00= 014458f0}, p_threads =3D {tqh_first =3D 0xffffff0001430a50, tqh_last =3D 0xffffff000= 1430a60}, p_upcalls =3D {tqh_first =3D 0x0, tqh_last =3D 0xffffff000142e498}, p_slo= ck =3D { lock_object =3D {lo_name =3D 0xffffffff808da2a3 "process slock", lo_type =3D 0xffffffff808da2a3 "process slock", lo_flags =3D 720896, lo_witness_data =3D {lod_list =3D {stqe_next =3D 0x0}, lod_witness = =3D 0x0}}, mtx_lock =3D 4, mtx_recurse =3D 0}, p_ucred =3D 0xffffff0001300e00, p_fd =3D 0xffffff0001443400, p_fdtol =3D 0x0, p_stats =3D 0xffffff00012ff= 600, p_limit =3D 0xffffff0001300c00, p_limco =3D {c_links =3D {sle =3D {sle_ne= xt =3D 0x0}, tqe =3D {tqe_next =3D 0x0, tqe_prev =3D 0x0}}, c_time =3D 0, c_arg = =3D 0x0, c_func =3D 0, c_mtx =3D 0xffffff000142e590, c_flags =3D 0}, p_sigacts =3D 0xffffff000143e000, p_flag =3D 268435980, p_state =3D PRS_N= ORMAL, p_pid =3D 17, p_hash =3D {le_next =3D 0x0, le_prev =3D 0xfffffffe8021c088= }, p_pglist =3D {le_next =3D 0xffffff000142e8f0, le_prev =3D 0xffffff0001445= 9d8}, p_pptr =3D 0xffffffff80b64640, p_sibling =3D {le_next =3D 0xffffff000142e= 8f0, le_prev =3D 0xffffff00014459f0}, p_children =3D {lh_first =3D 0x0}, p_m= tx =3D { lock_object =3D {lo_name =3D 0xffffffff808da296 "process lock", lo_type =3D 0xffffffff808da296 "process lock", lo_flags =3D 21168128, lo_witness_data =3D {lod_list =3D {stqe_next =3D 0x0}, lod_witness = =3D 0x0}}, mtx_lock =3D 4, mtx_recurse =3D 0}, p_ksi =3D 0x0, p_sigqueue =3D {sq_s= ignals =3D { __bits =3D {0, 0, 0, 0}}, sq_kill =3D {__bits =3D {0, 0, 0, 0}}, sq_l= ist =3D { tqh_first =3D 0x0, tqh_last =3D 0xffffff000142e5e8}, sq_proc =3D 0xffffff000142e478, sq_flags =3D 1}, p_oppid =3D 0, ---Type to continue, or q to quit--- p_vmspace =3D 0xffffffff80b64e00, p_swtick =3D 0, p_realtimer =3D {it_int= erval =3D { tv_sec =3D 0, tv_usec =3D 0}, it_value =3D {tv_sec =3D 0, tv_usec =3D= 0}}, p_ru =3D { ru_utime =3D {tv_sec =3D 0, tv_usec =3D 0}, ru_stime =3D {tv_sec =3D 0, tv_usec =3D 0}, ru_maxrss =3D 0, ru_ixrss =3D 0, ru_idrss =3D 0, ru_i= srss =3D 0, ru_minflt =3D 0, ru_majflt =3D 0, ru_nswap =3D 0, ru_inblock =3D 0, ru_oublock =3D 0, ru_msgsnd =3D 0, ru_msgrcv =3D 0, ru_nsignals =3D 0, ru_nvcsw =3D 0, ru_nivcsw =3D 0}, p_rux =3D {rux_runtime =3D 2063660005= 807206, rux_uticks =3D 0, rux_sticks =3D 137401258, rux_iticks =3D 0, rux_uu = =3D 0, rux_su =3D 371936150861, rux_tu =3D 1034416043011}, p_crux =3D {rux_run= time =3D 0, rux_uticks =3D 0, rux_sticks =3D 0, rux_iticks =3D 0, rux_uu =3D 0, rux= _su =3D 0, rux_tu =3D 0}, p_profthreads =3D 0, p_exitthreads =3D 0, p_traceflag = =3D 0, p_tracevp =3D 0x0, p_tracecred =3D 0x0, p_textvp =3D 0x0, p_lock =3D 0 '\= 0', p_sigiolst =3D {slh_first =3D 0x0}, p_sigparent =3D 20, p_sig =3D 0, p_co= de =3D 0, p_stops =3D 0, p_stype =3D 0, p_step =3D 0 '\0', p_pfsflags =3D 0 '\0', p_nlminfo =3D 0x0, p_aioinfo =3D 0x0, p_singlethread =3D 0x0, p_suspcount= =3D 0, p_xthread =3D 0x0, p_boundary_count =3D 0, p_pendingcnt =3D 0, p_itimers = =3D 0x0, p_numupcalls =3D 0, p_upsleeps =3D 0, p_completed =3D 0x0, p_nextupcall = =3D 0, p_upquantum =3D 0, p_magic =3D 3203398350, p_osrel =3D 702000, p_comm =3D "idle: cpu1\000\000\000\000\000\000\000\000\000", p_pgrp =3D 0xffffffff80b65060, p_sysent =3D 0xffffffff80ad4d80, p_args = =3D 0x0, p_cpulimit =3D 9223372036854775807, p_nice =3D 0 '\0', p_fibnum =3D 0, p_xstat =3D 0, p_klist =3D {kl_list =3D {slh_first =3D 0x0}, kl_lock =3D 0xffffffff804f65d0 , ---Type to continue, or q to quit--- kl_unlock =3D 0xffffffff804f5ff0 , kl_locked =3D 0xffffffff804f5fd0 , kl_lockarg =3D 0xffffff000142e590}, p_numthreads =3D 1, p_md =3D , p_itcallout =3D {c_links =3D {sle =3D {sle_ne= xt =3D 0x0}, tqe =3D {tqe_next =3D 0x0, tqe_prev =3D 0x0}}, c_time =3D 0, c_arg = =3D 0x0, c_func =3D 0, c_mtx =3D 0x0, c_flags =3D 16}, p_acflag =3D 1, p_peers = =3D 0x0, p_leader =3D 0xffffff000142e478, p_emuldata =3D 0x0, p_label =3D 0x0, p_sched =3D 0xffffff000142e8f0, p_ktr =3D {stqh_first =3D 0x0, stqh_last =3D 0xffffff000142e8d0}, p_mqnotifier =3D {lh_first =3D 0x0}, p_dtrace =3D 0x0} db> show allpcpu Current CPU: 1 cpuid =3D 0 curthread =3D 0xffffff00014306e0: pid 18 "idle: cpu0" curpcb =3D 0xfffffffe80064d40 fpcurthread =3D none idlethread =3D 0xffffff00014306e0: pid 18 "idle: cpu0" cpuid =3D 1 curthread =3D 0xffffff0001430a50: pid 17 "idle: cpu1" curpcb =3D 0xfffffffe8005fd40 fpcurthread =3D none idlethread =3D 0xffffff0001430a50: pid 17 "idle: cpu1" cpuid =3D 2 curthread =3D 0xffffff000143c000: pid 16 "idle: cpu2" curpcb =3D 0xfffffffe8005ad40 fpcurthread =3D none idlethread =3D 0xffffff000143c000: pid 16 "idle: cpu2" cpuid =3D 3 curthread =3D 0xffffff000143c370: pid 15 "idle: cpu3" curpcb =3D 0xfffffffe80055d40 fpcurthread =3D none idlethread =3D 0xffffff000143c370: pid 15 "idle: cpu3" cpuid =3D 4 curthread =3D 0xffffff000143c6e0: pid 14 "idle: cpu4" curpcb =3D 0xfffffffe80050d40 fpcurthread =3D none idlethread =3D 0xffffff000143c6e0: pid 14 "idle: cpu4" cpuid =3D 5 curthread =3D 0xffffff000144e370: pid 20 "swi4: clock sio" curpcb =3D 0xfffffffe8006fd40 fpcurthread =3D none idlethread =3D 0xffffff000142f000: pid 13 "idle: cpu5" cpuid =3D 6 curthread =3D 0xffffff000142f370: pid 12 "idle: cpu6" curpcb =3D 0xfffffffe80046d40 fpcurthread =3D none idlethread =3D 0xffffff000142f370: pid 12 "idle: cpu6" cpuid =3D 7 curthread =3D 0xffffff000142f6e0: pid 11 "idle: cpu7" curpcb =3D 0xfffffffe80041d40 fpcurthread =3D none idlethread =3D 0xffffff000142f6e0: pid 11 "idle: cpu7" --=20 wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 17:19:57 2010 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 2AA8D1065670 for ; Tue, 2 Feb 2010 17:19:57 +0000 (UTC) (envelope-from jespasac@minibofh.org) Received: from smtp02.cdmon.com (smtp02.cdmon.com [212.36.74.53]) by mx1.freebsd.org (Postfix) with ESMTP id E3B9F8FC1A for ; Tue, 2 Feb 2010 17:19:56 +0000 (UTC) Received: from jespasac.cdmon.com (62.Red-217-126-43.staticIP.rima-tde.net [217.126.43.62]) (Authenticated sender: jespasac@noverificar) by smtp02.cdmon.com (Postfix) with ESMTP id DD1F945F06; Tue, 2 Feb 2010 18:19:54 +0100 (CET) Message-ID: <4B685EBA.4020501@minibofh.org> Date: Tue, 02 Feb 2010 18:19:54 +0100 From: Jordi Espasa Clofent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0b1 Thunderbird/3.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: ionice in 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, 02 Feb 2010 17:19:57 -0000 Hi all, In Linux exists the ionice(1) for "get/set program io scheduling class and priority". In FreeBSD we've nice(1), renice(8) and even rtprio, idprio(1) but if I'm understanding correctly, they're related to CPU priorty only, not to I/O. ¿Is there some ionice(1) equivalent in FreeBSD? -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 17:30:53 2010 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 B18FF106568D for ; Tue, 2 Feb 2010 17:30:53 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id 887A08FC16 for ; Tue, 2 Feb 2010 17:30:53 +0000 (UTC) Received: by pxi13 with SMTP id 13so286473pxi.3 for ; Tue, 02 Feb 2010 09:30:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=E4nm8LuoTS3FO5nOrK6yXQVpuE3JqEF+xbEaeOcMTe4=; b=kjuDUR6qKsDBUGE6WDn8fIJ9qVKX8y7jUpgd7XHMj6EUU6urv4C1X753K4KIJ9ajHF IlPM+IyRKgCBp9oUzmqa9NZ2m8K8SDyWt6qPWTMhBkGttbpRUkCiCPLeWfXqprmSLUm6 kUcjBn+BWwCVzCkoZy1pkCDdiXzCWL7EXR1Tk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nb9CTDb0A3bo16updt3arOmHRsG7WGXq1pIoJOVOeBpx042JiyLLA5kGQkJ1JjSSTO VPy4Bys2zJM1hrgtiqhML9yJyXYgVUvMa7jacACtrZCCzz3TMwI3De1Hm08FqcgUGcNf YN3blmW8+UXbqx0bDhP9q92frQsZGPlL7sF2A= MIME-Version: 1.0 Received: by 10.142.1.40 with SMTP id 40mr670127wfa.51.1265131852907; Tue, 02 Feb 2010 09:30:52 -0800 (PST) In-Reply-To: <20100131224033.GA1107@michelle.cdnetworks.com> References: <147432021001310037n1b67f01bx4b4e8781321cea8@mail.gmail.com> <20100131224033.GA1107@michelle.cdnetworks.com> Date: Tue, 2 Feb 2010 09:30:52 -0800 Message-ID: <147432021002020930y3591c278h6b07a235d3184752@mail.gmail.com> From: Nick Rogers To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: jfv@freebsd.org, stable@freebsd.org Subject: Re: em(4) + ALTQ broken 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, 02 Feb 2010 17:30:53 -0000 > I guess the problem comes from multi-queue support. The drbr > interface is implemented with inline function so em(4)/igb(4) may > have to define ALTQ to the header. I have not tested the patch(no > time at this moment) but would you give it try? > > I tried the patch and it did not work. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 17:39:11 2010 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 11B941065676; Tue, 2 Feb 2010 17:39:11 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f198.google.com (mail-qy0-f198.google.com [209.85.221.198]) by mx1.freebsd.org (Postfix) with ESMTP id A491D8FC0C; Tue, 2 Feb 2010 17:39:10 +0000 (UTC) Received: by qyk36 with SMTP id 36so362289qyk.15 for ; Tue, 02 Feb 2010 09:39:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=APuj+4xwOdct2P4hnfqSmGwqKbGOZ1AkdwUqUG592/s=; b=WY499t+jsMNTFgsvBrVuoqcgWuKZNmrkm/DxzStIPU5ra03c/9jpmb/mW7DTYA5ZCt d5UX7WxwXLE5Wg/dM2s5SU/kNJqHAlTCZewhkdr5Scjw+VEwW359vDEnjkITElqu9pFj HtwPppKZ1Tt5ZdVMVbzL44j3HmipvYa7LjQBU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=f6hGfbf5Ofu4WgJnMDK/UbCzHWNZfoScjXIEuxu5Sl5ztT19/0ZV408+Wr1axofmUw m9lY1SJO2CY//LFBvf4ev7zQaK9b9OEfT1vYw6SWQ/PIMXTBj1tLKxclGaRSGMq5iU7L WUcMatqxD0S4wmQdBNdyCB6JZs3QpPwZPO0sI= Received: by 10.224.50.146 with SMTP id z18mr2976625qaf.216.1265132349818; Tue, 02 Feb 2010 09:39:09 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 5sm21897693qwg.38.2010.02.02.09.39.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 02 Feb 2010 09:39:06 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 2 Feb 2010 09:37:46 -0800 From: Pyun YongHyeon Date: Tue, 2 Feb 2010 09:37:46 -0800 To: Nick Rogers Message-ID: <20100202173746.GA5901@michelle.cdnetworks.com> References: <147432021001310037n1b67f01bx4b4e8781321cea8@mail.gmail.com> <20100131224033.GA1107@michelle.cdnetworks.com> <147432021002020930y3591c278h6b07a235d3184752@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <147432021002020930y3591c278h6b07a235d3184752@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: jfv@freebsd.org, stable@freebsd.org Subject: Re: em(4) + ALTQ broken X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 17:39:11 -0000 On Tue, Feb 02, 2010 at 09:30:52AM -0800, Nick Rogers wrote: > > I guess the problem comes from multi-queue support. The drbr > > interface is implemented with inline function so em(4)/igb(4) may > > have to define ALTQ to the header. I have not tested the patch(no > > time at this moment) but would you give it try? > > > > I tried the patch and it did not work. You rebuilt kernel, right? Rebuilding kernel module has no effect. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 17:47:17 2010 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 DFD33106566B; Tue, 2 Feb 2010 17:47:17 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-pz0-f202.google.com (mail-pz0-f202.google.com [209.85.222.202]) by mx1.freebsd.org (Postfix) with ESMTP id AD9248FC13; Tue, 2 Feb 2010 17:47:17 +0000 (UTC) Received: by pzk40 with SMTP id 40so311382pzk.7 for ; Tue, 02 Feb 2010 09:47:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=KAJD+US97I3HBx/Ohdrzl97F2+ZFbtAjyeNi/q+5FZ8=; b=jLTSscn/ym4hJJnc9pveGeWIe1neA1I+IqWTAaEVJxjMTiSpuvrUbc9H7mRrXlEijB ZlOg7XnFRKWeXmtroyhHfsIIfIyJVhpvaI3Xtw0Vb1KCbgaA9rWd4RkmhvZXKRezgwcO a76E9mL39hIm0okat2Zvb2++eVLYJgfx0ZEG0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hxYJCMPYKLyA6gv0xDINoQSAm4qmYbZQxZbwKEEau1tZVamMEGjs1hvXQl3StEZ/VE DA9XewS1L4KXOYcTprm3rGtayTghSb0ZuGy/KGpD6UHdWS//9ROcCFRBsCydSF/VddTx /bkmBj0xkUbd56vnWumHNk+oSo8rPxVPfoI+0= MIME-Version: 1.0 Received: by 10.142.4.41 with SMTP id 41mr2678339wfd.56.1265132837207; Tue, 02 Feb 2010 09:47:17 -0800 (PST) In-Reply-To: <20100202173746.GA5901@michelle.cdnetworks.com> References: <147432021001310037n1b67f01bx4b4e8781321cea8@mail.gmail.com> <20100131224033.GA1107@michelle.cdnetworks.com> <147432021002020930y3591c278h6b07a235d3184752@mail.gmail.com> <20100202173746.GA5901@michelle.cdnetworks.com> Date: Tue, 2 Feb 2010 09:47:17 -0800 Message-ID: <147432021002020947m40e92094o742aa854ca89bd09@mail.gmail.com> From: Nick Rogers To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: jfv@freebsd.org, stable@freebsd.org Subject: Re: em(4) + ALTQ broken 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, 02 Feb 2010 17:47:18 -0000 On Tue, Feb 2, 2010 at 9:37 AM, Pyun YongHyeon wrote: > On Tue, Feb 02, 2010 at 09:30:52AM -0800, Nick Rogers wrote: > > > I guess the problem comes from multi-queue support. The drbr > > > interface is implemented with inline function so em(4)/igb(4) may > > > have to define ALTQ to the header. I have not tested the patch(no > > > time at this moment) but would you give it try? > > > > > > I tried the patch and it did not work. > > You rebuilt kernel, right? Rebuilding kernel module has no effect. > Yes I rebuilt the kernel itself and replaced the one on my test system. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 17:48:05 2010 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 BF3541065698; Tue, 2 Feb 2010 17:48:05 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id 2E4928FC33; Tue, 2 Feb 2010 17:48:04 +0000 (UTC) Received: by ewy3 with SMTP id 3so324273ewy.13 for ; Tue, 02 Feb 2010 09:48:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=d3jzmXS88AEkNdytHSVeYd8KeqnmSfSZh8/6uD7KETw=; b=GTbP77wEokDJh45LIbkNuBqxCMTOt6SNkjS92VVZhYS0qIEIOswiws/Yxfv70qLhtn E5O7PplabDKP1ICmlmCqCedQ03L1c/aDtn5opzrnRE6XoZC8r9ky5j8sl2AcAs0Hst3O oTt3QEB9N4u/ylMkqmfOQAjgwknnszZN0ZJkw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hn9NJa60knVVbGgoLwsEDEk3NIycfl4aORJAlDUvu4rbYnkwbvqQjgvgAQVP1l3Yg5 bj5QhgAZwdWQLSVEoRX9FYAt7JAqpZv3b8KZW7Tchn3Ab9WmeF1P7R7sk0fMQrBP5IWK uKpqioi331x5YdMRI75sNG5OIqrNrx4IKID4A= MIME-Version: 1.0 Received: by 10.216.87.11 with SMTP id x11mr898648wee.16.1265132883327; Tue, 02 Feb 2010 09:48:03 -0800 (PST) In-Reply-To: <20100202173746.GA5901@michelle.cdnetworks.com> References: <147432021001310037n1b67f01bx4b4e8781321cea8@mail.gmail.com> <20100131224033.GA1107@michelle.cdnetworks.com> <147432021002020930y3591c278h6b07a235d3184752@mail.gmail.com> <20100202173746.GA5901@michelle.cdnetworks.com> Date: Tue, 2 Feb 2010 09:48:02 -0800 Message-ID: <2a41acea1002020948l6f3d1a08v9f4ccefd1241f566@mail.gmail.com> From: Jack Vogel To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Nick Rogers , jfv@freebsd.org, stable@freebsd.org Subject: Re: em(4) + ALTQ broken 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, 02 Feb 2010 17:48:05 -0000 So apparently this thing needs no special knowledge in the driver, yet something in the new code breaks it, can someone explain tersely how the altq app actually "pokes" or "hooks up" to the driver? I am not clear about that and I suspect if I was this would all be clearer. Jack On Tue, Feb 2, 2010 at 9:37 AM, Pyun YongHyeon wrote: > On Tue, Feb 02, 2010 at 09:30:52AM -0800, Nick Rogers wrote: > > > I guess the problem comes from multi-queue support. The drbr > > > interface is implemented with inline function so em(4)/igb(4) may > > > have to define ALTQ to the header. I have not tested the patch(no > > > time at this moment) but would you give it try? > > > > > > I tried the patch and it did not work. > > You rebuilt kernel, right? Rebuilding kernel module has no effect. > From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 17:50:33 2010 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 C8A861065670; Tue, 2 Feb 2010 17:50:33 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 457DE8FC1C; Tue, 2 Feb 2010 17:50:29 +0000 (UTC) Received: by vws11 with SMTP id 11so196427vws.13 for ; Tue, 02 Feb 2010 09:50:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=ndq07vJLSDm6v3OGU5N1yfqeQF+G//muIQA4enYFzbk=; b=Bu3dWCNWjNr8YQ00Lt16SyXeCf76C2U7sQ81pZOHpaepfLTdqeUibkV11tKmFK4oJs LlCp7n2KF+nSDSNsALrh21vQ5KjSVOMsvJ4SPNQxPnWLpQ0O3JdQIEtt0G/PWvCUBtRU BB7p+8UPujvRQ2yvAMecq6v/m5BgOwpO758zI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=HvlAvfcZ2UoHZV9esqq+gW0XC3K5mvAuXOwH7C5BISc3NnncHkH9vDjgTKDUSsJizE gR6qlKYvC569T+sL1s10ZMtrvSBq7Ii4qAhtgTfCzgCNkgXqinAFe9CC5L1eruypBF8g 76mhK2CucU1/nmaVBxlrVta73p98KTNMEzdDE= Received: by 10.220.122.169 with SMTP id l41mr682347vcr.115.1265133029084; Tue, 02 Feb 2010 09:50:29 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 29sm71711620vws.3.2010.02.02.09.50.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 02 Feb 2010 09:50:28 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 2 Feb 2010 09:49:06 -0800 From: Pyun YongHyeon Date: Tue, 2 Feb 2010 09:49:06 -0800 To: Nick Rogers Message-ID: <20100202174906.GB5901@michelle.cdnetworks.com> References: <147432021001310037n1b67f01bx4b4e8781321cea8@mail.gmail.com> <20100131224033.GA1107@michelle.cdnetworks.com> <147432021002020930y3591c278h6b07a235d3184752@mail.gmail.com> <20100202173746.GA5901@michelle.cdnetworks.com> <147432021002020947m40e92094o742aa854ca89bd09@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <147432021002020947m40e92094o742aa854ca89bd09@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: jfv@freebsd.org, stable@freebsd.org Subject: Re: em(4) + ALTQ broken X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 17:50:33 -0000 On Tue, Feb 02, 2010 at 09:47:17AM -0800, Nick Rogers wrote: > On Tue, Feb 2, 2010 at 9:37 AM, Pyun YongHyeon wrote: > > > On Tue, Feb 02, 2010 at 09:30:52AM -0800, Nick Rogers wrote: > > > > I guess the problem comes from multi-queue support. The drbr > > > > interface is implemented with inline function so em(4)/igb(4) may > > > > have to define ALTQ to the header. I have not tested the patch(no > > > > time at this moment) but would you give it try? > > > > > > > > I tried the patch and it did not work. > > > > You rebuilt kernel, right? Rebuilding kernel module has no effect. > > > Yes I rebuilt the kernel itself and replaced the one on my test system. Hmm, I have to find time to experiment this. Thank you for testing! From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 18:28:14 2010 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 F1E07106566C for ; Tue, 2 Feb 2010 18:28:14 +0000 (UTC) (envelope-from hoganxian@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id 83F438FC1D for ; Tue, 2 Feb 2010 18:28:14 +0000 (UTC) Received: by fxm26 with SMTP id 26so359811fxm.13 for ; Tue, 02 Feb 2010 10:28:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=b1hcDrjJsgc4J+KhP4+eGFPfFqefa7r6taT2/Ei3tSs=; b=CM+lTFK8D5wL2+deyXZJUO09pmcLInkp090CbPRTUgQ4OE1AiMzursEnfxpyzAINKI maaxctwOEyC7+fK4fJ93WmovAMQ2WOfKlB0P2EHNb/4siwP+X7dI7cmV2dKhqOvEwcG2 e36CANrx6SxA0jL8LSx5n+LKI/i6yrKnlnvDQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Vw12ruuIzhUVM6MpOIASdsMaoC7T/ZaLre/czJC9bsNmAdJyj0i2BRamlIIImZ/KFs 8amgN0I28U7FVwEPrwQrACEj3olarpb/+SgZA58QJM5MapWXG8WFcHrlswM6HBxhPAg9 zyYQIZD6TwCwg2gtHK8wkuuIV5Px6NQZdXgaI= MIME-Version: 1.0 Received: by 10.239.184.80 with SMTP id x16mr712683hbg.198.1265133572034; Tue, 02 Feb 2010 09:59:32 -0800 (PST) Date: Tue, 2 Feb 2010 12:59:31 -0500 Message-ID: From: Xian Chen To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: install root certificates 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, 02 Feb 2010 18:28:15 -0000 Hello, I use 8.0 Release on my thinkpad T42 laptop and want to connect to the WIFI AP near me. The AP is encrypted by WPA2. I also need some root certifications installed ( UTN-USERFirst-Hardware ). I install /usr/ports/security/ca_root_nss and openssl but still I cannot find where the certifications are. Any ideas? Thanks, From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 18:57:14 2010 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 EBF711065679 for ; Tue, 2 Feb 2010 18:57:14 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id A65128FC0C for ; Tue, 2 Feb 2010 18:57:14 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id o12IuKW2048139; Tue, 2 Feb 2010 12:56:25 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id o12IuKeP048138; Tue, 2 Feb 2010 12:56:20 -0600 (CST) (envelope-from brooks) Date: Tue, 2 Feb 2010 12:56:19 -0600 From: Brooks Davis To: Xian Chen Message-ID: <20100202185619.GB39848@lor.one-eyed-alien.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1UWUbFP1cBYEclgG" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Tue, 02 Feb 2010 12:56:25 -0600 (CST) Cc: freebsd-stable Subject: Re: install root certificates 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, 02 Feb 2010 18:57:15 -0000 --1UWUbFP1cBYEclgG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 02, 2010 at 12:59:31PM -0500, Xian Chen wrote: > Hello, >=20 > I use 8.0 Release on my thinkpad T42 laptop and want to connect to the WI= FI > AP near me. The AP is encrypted by WPA2. I also need some root > certifications installed ( UTN-USERFirst-Hardware ). I install > /usr/ports/security/ca_root_nss and openssl but still I cannot find where > the certifications are. >=20 > Any ideas? $ pkg_info -L ca_root_nss\* Information for ca_root_nss-3.11.9_2: Files: /usr/local/share/certs/ca-root-nss.crt -- Brooks --1UWUbFP1cBYEclgG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD4DBQFLaHVTXY6L6fI4GtQRAnccAJiBIN9i2yUXKYl8USsBLhkgNa7QAJwLX/EU /hA50moew+7Xo5UrAT9cFw== =qSqG -----END PGP SIGNATURE----- --1UWUbFP1cBYEclgG-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 18:59:04 2010 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 2AACB1065694 for ; Tue, 2 Feb 2010 18:59:04 +0000 (UTC) (envelope-from hoganxian@gmail.com) Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by mx1.freebsd.org (Postfix) with ESMTP id 9E4478FC1D for ; Tue, 2 Feb 2010 18:59:03 +0000 (UTC) Received: by bwz3 with SMTP id 3so416479bwz.13 for ; Tue, 02 Feb 2010 10:59:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=3TJuLdfgtLIWQ/xgBHnfP+b4lZpHtzVKiJcB9cQZkLg=; b=ddev5QR5LDg3BxmfiZXaESfSKNzckatZtuKzeMAiSwsFVwwTJOR3odqh9N1Q0fG1dZ 9lDVwqp2ToxrI2GIBRataH2DVAqi0P84M7KkV3No+F6uXa5gw37MEuX+G02mDxhybNEO vnu7UflDR4pWYHj5J3KRhf4itTLwFfM12n80Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=IEqDEc33cH809VWWxt5sJhQG9fNJ0xyXhhNcafyzA1TUhiYGFt4NLoU1ejmuW2HbLL jKnS/jNmlx3w10JXS/2EQhLN9ybVCwltz3EEM1p4ZNh929BtfsYVInA6QSFLjZJsB+WW qhUDrN/3ZqwWgUC3FYJ458nfOk7x0xA26FE70= MIME-Version: 1.0 Received: by 10.239.148.8 with SMTP id d8mr715863hbb.109.1265137142198; Tue, 02 Feb 2010 10:59:02 -0800 (PST) In-Reply-To: <20100202185619.GB39848@lor.one-eyed-alien.net> References: <20100202185619.GB39848@lor.one-eyed-alien.net> Date: Tue, 2 Feb 2010 13:59:02 -0500 Message-ID: From: Xian Chen To: Brooks Davis Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable Subject: Re: install root certificates 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, 02 Feb 2010 18:59:04 -0000 Yes, I have this crt file. Is this one enough? I need UTN-USERFirst-Hardware . I do know exactly how the certification work. thanks, On Tue, Feb 2, 2010 at 1:56 PM, Brooks Davis wrote: > On Tue, Feb 02, 2010 at 12:59:31PM -0500, Xian Chen wrote: > > Hello, > > > > I use 8.0 Release on my thinkpad T42 laptop and want to connect to the > WIFI > > AP near me. The AP is encrypted by WPA2. I also need some root > > certifications installed ( UTN-USERFirst-Hardware ). I install > > /usr/ports/security/ca_root_nss and openssl but still I cannot find where > > the certifications are. > > > > Any ideas? > > $ pkg_info -L ca_root_nss\* > Information for ca_root_nss-3.11.9_2: > > Files: > /usr/local/share/certs/ca-root-nss.crt > > -- Brooks > From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 19:04:02 2010 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 9B31E10656C7 for ; Tue, 2 Feb 2010 19:04:02 +0000 (UTC) (envelope-from alan.bryan@yahoo.com) Received: from web50503.mail.re2.yahoo.com (web50503.mail.re2.yahoo.com [206.190.38.79]) by mx1.freebsd.org (Postfix) with SMTP id DF6A78FC13 for ; Tue, 2 Feb 2010 19:04:01 +0000 (UTC) Received: (qmail 73233 invoked by uid 60001); 2 Feb 2010 19:04:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1265137440; bh=ng1lKrfA+cE0WPrQjYGHD4cHoWvdgjXEtumZ8GpkifQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=sZW8BsGIbZCqU1/iJIkJ6gmHkR1GhcoBuy6YRN5iQteAItskenDaryLrOZol2NZAEyzn8v2jXt6yyZrlymuvAF9OV7kCiPMcz3NyaiAKu8+EETUrV3PtGkQOBTxqdE6XFy0Xdn/YdHmwPt59VThulpzyDLUkltzvkXjZmxqKL+s= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=g6cj7irOXr2ktrw5bEL9O2I41bfXWxvw2s7/s1d94d3Xc6rXkKLq+RvqpLZH+FCtvazT67yhVzAhaCwcIxcUOkLGJCpppLICh/ZsT04P8X9Hoqbx8BNepzV44hXev0NDArfiSHp7YDCYD3nHTJPnKAZK1MsTPRx1t/3+nztoDXQ=; Message-ID: <878205.72256.qm@web50503.mail.re2.yahoo.com> X-YMail-OSG: OBT7uVoVM1mdTUdKovKzmeFLfV2efCKcMoTRoG7MZxj7WXa_fk.PSVkTVVB6x3x5S1Z09TqqtcLPv0tCiE4iGyoAkT.HKM3j9_zl3y6YMuFvlK_ODgI5OzDIFAxZUUawVjQluZibLcDvYLKjG4UYz3c_ieNzZ80Kp78wiXUnmKbFpMKp5UV2F5yPooT2pToAoIFru9KKOP2AHrEwbVbHcKzRtLB7wmKQ6FgpqrZbmj6oRwWZq9bsRYgJIcbUb9voO5NQYipzjHMLz3ryxg.hsUX6nYfc597ZT.PXTR_VjSx7JoR1f.SmmWRCiuJ_0XPX05cngE6bVgpO6_jdm1Y.G2SM2_Y8JA-- Received: from [99.24.6.121] by web50503.mail.re2.yahoo.com via HTTP; Tue, 02 Feb 2010 11:04:00 PST X-Mailer: YahooMailClassic/9.1.10 YahooMailWebService/0.8.100.260964 Date: Tue, 2 Feb 2010 11:04:00 -0800 (PST) From: alan bryan To: Rick Macklem MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-977769940-1265137440=:72256" Cc: freebsd-stable@freebsd.org Subject: Re: Zombie NFS writing from FreeBSD clients to FreeBSD 8.0 server with ZFS 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, 02 Feb 2010 19:04:02 -0000 --0-977769940-1265137440=:72256 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable --- On Wed, 1/6/10, Rick Macklem wrote:=0A=0A> From:= Rick Macklem =0A> Subject: Re: Zombie NFS writing fr= om FreeBSD clients to FreeBSD 8.0 server with ZFS=0A> To: "alan bryan" =0A> Cc: freebsd-stable@freebsd.org=0A> Date: Wednesday, = January 6, 2010, 12:19 PM=0A> =0A> =0A> On Wed, 6 Jan 2010, alan bryan wrot= e:=0A> =0A> > I have a AMD64 FreeBSD 8.0 server with ZFS filesystem=0A> bei= ng shared via NFS.=A0 These are being accessed by the=0A> clients.=A0 The c= lients are a mix of FreeBSD 6.2 32bit=0A> and FreeBSD 7.0 64bit.=A0 I have = seen similar behavior=0A> from both versions of FreeBSD as clients.=0A> >= =0A> [stuff related to lotsa writes being done snipped]=0A> >=0A> > Any ide= as on what to try, where to look for more=0A> insight, etc...??=0A> >=0A> I= t might be worth taking a look at the traffic. Wireshark=0A> (or a tcpdump= =0A> packet capture read into wireshark) does a good job of=0A> interpretin= g NFS=0A> traffic. "tcpdump -s 0 -w host "=0A> run for a=0A>= short period of time when has the problem=0A> and then looking at= =0A> that in wireshark would at least allow you to see what the=0A> writes= =0A> look like?=0A> - Are they the same write being retried over and over?= =0A=0A=0Ayes - it appears so=0A=0A=0A> - Is the server replying to them wit= h an error?=0A=0Ayes=0A=0A> =0A> The above might give some insight into wha= t's happening,=0A> rick=0A=0A=0AAttached is the sequence of the tcpdump exp= orted as a text file. This is a freebsd 7.0 client talking to the above me= ntioned FreeBSD 8.0 NFS server. I've seen similar behavior from my FreeBSD= 6.1 NFS clients too.=0A=0AThis will just loop like this forever. At some = point after a day or so the FreeBSD 8.0 server will then lose all networkin= g (still can access the console just fine). Rebooting fixes everything for= a day or so until a client has problems again.=0A=0AI've tried different n= etwork driver igb->em, UDP->TCP for NFS, enabling NFS locking on the server= /clients (lockd, statd).=0A=0AI'm out of ideas so hoping this tcpdump sheds= light on how it's getting stuck in this loop.=0A=0AThanks,=0AAlan=0A=0A=0A= --0-977769940-1265137440=:72256 Content-Type: text/plain; name="tcpdump.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="tcpdump.txt" Tm8uICAgICBUaW1lICAgICAgICBTb3VyY2UgICAgICAgICAgICAgICAgRGVz dGluYXRpb24gICAgICAgICAgIFByb3RvY29sIEluZm8KICAgICAgMSAwLjAw MDAwMCAgICAxOTIuMTY4LjIuMTM3ICAgICAgICAgMTkyLjE2OC4yLjE1MyAg ICAgICAgIFJQQyAgICAgIENvbnRpbnVhdGlvbgoKRnJhbWUgMSAoOTQgYnl0 ZXMgb24gd2lyZSwgOTQgYnl0ZXMgY2FwdHVyZWQpCiAgICBBcnJpdmFsIFRp bWU6IEphbiAzMCwgMjAxMCAxMjo0MTo0Ni45MTA4MjgwMDAKICAgIFtUaW1l IGRlbHRhIGZyb20gcHJldmlvdXMgY2FwdHVyZWQgZnJhbWU6IDAuMDAwMDAw MDAwIHNlY29uZHNdCiAgICBbVGltZSBkZWx0YSBmcm9tIHByZXZpb3VzIGRp c3BsYXllZCBmcmFtZTogMC4wMDAwMDAwMDAgc2Vjb25kc10KICAgIFtUaW1l IHNpbmNlIHJlZmVyZW5jZSBvciBmaXJzdCBmcmFtZTogMC4wMDAwMDAwMDAg c2Vjb25kc10KICAgIEZyYW1lIE51bWJlcjogMQogICAgRnJhbWUgTGVuZ3Ro OiA5NCBieXRlcwogICAgQ2FwdHVyZSBMZW5ndGg6IDk0IGJ5dGVzCiAgICBb RnJhbWUgaXMgbWFya2VkOiBGYWxzZV0KICAgIFtQcm90b2NvbHMgaW4gZnJh bWU6IGV0aDppcDp0Y3A6cnBjXQogICAgW0NvbG9yaW5nIFJ1bGUgTmFtZTog VENQXQogICAgW0NvbG9yaW5nIFJ1bGUgU3RyaW5nOiB0Y3BdCkV0aGVybmV0 IElJLCBTcmM6IEludGVsQ29yX2JmOmViOjdiICgwMDoxNToxNzpiZjplYjo3 YiksIERzdDogU3VwZXJtaWNfN2I6NTI6MzQgKDAwOjMwOjQ4OjdiOjUyOjM0 KQogICAgRGVzdGluYXRpb246IFN1cGVybWljXzdiOjUyOjM0ICgwMDozMDo0 ODo3Yjo1MjozNCkKICAgICAgICBBZGRyZXNzOiBTdXBlcm1pY183Yjo1Mjoz NCAoMDA6MzA6NDg6N2I6NTI6MzQpCiAgICAgICAgLi4uLiAuLi4wIC4uLi4g Li4uLiAuLi4uIC4uLi4gPSBJRyBiaXQ6IEluZGl2aWR1YWwgYWRkcmVzcyAo dW5pY2FzdCkKICAgICAgICAuLi4uIC4uMC4gLi4uLiAuLi4uIC4uLi4gLi4u LiA9IExHIGJpdDogR2xvYmFsbHkgdW5pcXVlIGFkZHJlc3MgKGZhY3Rvcnkg ZGVmYXVsdCkKICAgIFNvdXJjZTogSW50ZWxDb3JfYmY6ZWI6N2IgKDAwOjE1 OjE3OmJmOmViOjdiKQogICAgICAgIEFkZHJlc3M6IEludGVsQ29yX2JmOmVi OjdiICgwMDoxNToxNzpiZjplYjo3YikKICAgICAgICAuLi4uIC4uLjAgLi4u LiAuLi4uIC4uLi4gLi4uLiA9IElHIGJpdDogSW5kaXZpZHVhbCBhZGRyZXNz ICh1bmljYXN0KQogICAgICAgIC4uLi4gLi4wLiAuLi4uIC4uLi4gLi4uLiAu Li4uID0gTEcgYml0OiBHbG9iYWxseSB1bmlxdWUgYWRkcmVzcyAoZmFjdG9y eSBkZWZhdWx0KQogICAgVHlwZTogSVAgKDB4MDgwMCkKSW50ZXJuZXQgUHJv dG9jb2wsIFNyYzogMTkyLjE2OC4yLjEzNyAoMTkyLjE2OC4yLjEzNyksIERz dDogMTkyLjE2OC4yLjE1MyAoMTkyLjE2OC4yLjE1MykKICAgIFZlcnNpb246 IDQKICAgIEhlYWRlciBsZW5ndGg6IDIwIGJ5dGVzCiAgICBEaWZmZXJlbnRp YXRlZCBTZXJ2aWNlcyBGaWVsZDogMHgwMCAoRFNDUCAweDAwOiBEZWZhdWx0 OyBFQ046IDB4MDApCiAgICAgICAgMDAwMCAwMC4uID0gRGlmZmVyZW50aWF0 ZWQgU2VydmljZXMgQ29kZXBvaW50OiBEZWZhdWx0ICgweDAwKQogICAgICAg IC4uLi4gLi4wLiA9IEVDTi1DYXBhYmxlIFRyYW5zcG9ydCAoRUNUKTogMAog ICAgICAgIC4uLi4gLi4uMCA9IEVDTi1DRTogMAogICAgVG90YWwgTGVuZ3Ro OiA4MAogICAgSWRlbnRpZmljYXRpb246IDB4YjhkNSAoNDczMTcpCiAgICBG bGFnczogMHgwNCAoRG9uJ3QgRnJhZ21lbnQpCiAgICAgICAgMC4uLiA9IFJl c2VydmVkIGJpdDogTm90IHNldAogICAgICAgIC4xLi4gPSBEb24ndCBmcmFn bWVudDogU2V0CiAgICAgICAgLi4wLiA9IE1vcmUgZnJhZ21lbnRzOiBOb3Qg c2V0CiAgICBGcmFnbWVudCBvZmZzZXQ6IDAKICAgIFRpbWUgdG8gbGl2ZTog NjQKICAgIFByb3RvY29sOiBUQ1AgKDB4MDYpCiAgICBIZWFkZXIgY2hlY2tz dW06IDB4ZmI1ZiBbY29ycmVjdF0KICAgICAgICBbR29vZDogVHJ1ZV0KICAg ICAgICBbQmFkIDogRmFsc2VdCiAgICBTb3VyY2U6IDE5Mi4xNjguMi4xMzcg KDE5Mi4xNjguMi4xMzcpCiAgICBEZXN0aW5hdGlvbjogMTkyLjE2OC4yLjE1 MyAoMTkyLjE2OC4yLjE1MykKVHJhbnNtaXNzaW9uIENvbnRyb2wgUHJvdG9j b2wsIFNyYyBQb3J0OiBuZnMgKDIwNDkpLCBEc3QgUG9ydDogc3NoZWxsICg2 MTQpLCBTZXE6IDEsIEFjazogMSwgTGVuOiA0MAogICAgU291cmNlIHBvcnQ6 IG5mcyAoMjA0OSkKICAgIERlc3RpbmF0aW9uIHBvcnQ6IHNzaGVsbCAoNjE0 KQogICAgU2VxdWVuY2UgbnVtYmVyOiAxICAgIChyZWxhdGl2ZSBzZXF1ZW5j ZSBudW1iZXIpCiAgICBbTmV4dCBzZXF1ZW5jZSBudW1iZXI6IDQxICAgIChy ZWxhdGl2ZSBzZXF1ZW5jZSBudW1iZXIpXQogICAgQWNrbm93bGVkZ2VtZW50 IG51bWJlcjogMSAgICAocmVsYXRpdmUgYWNrIG51bWJlcikKICAgIEhlYWRl ciBsZW5ndGg6IDIwIGJ5dGVzCiAgICBGbGFnczogMHgxOCAoUFNILCBBQ0sp CiAgICAgICAgMC4uLiAuLi4uID0gQ29uZ2VzdGlvbiBXaW5kb3cgUmVkdWNl ZCAoQ1dSKTogTm90IHNldAogICAgICAgIC4wLi4gLi4uLiA9IEVDTi1FY2hv OiBOb3Qgc2V0CiAgICAgICAgLi4wLiAuLi4uID0gVXJnZW50OiBOb3Qgc2V0 CiAgICAgICAgLi4uMSAuLi4uID0gQWNrbm93bGVkZ21lbnQ6IFNldAogICAg ICAgIC4uLi4gMS4uLiA9IFB1c2g6IFNldAogICAgICAgIC4uLi4gLjAuLiA9 IFJlc2V0OiBOb3Qgc2V0CiAgICAgICAgLi4uLiAuLjAuID0gU3luOiBOb3Qg c2V0CiAgICAgICAgLi4uLiAuLi4wID0gRmluOiBOb3Qgc2V0CiAgICBXaW5k b3cgc2l6ZTogNjU1MzUKICAgIENoZWNrc3VtOiAweDg4ODMgW2NvcnJlY3Rd CiAgICAgICAgW0dvb2QgQ2hlY2tzdW06IFRydWVdCiAgICAgICAgW0JhZCBD aGVja3N1bTogRmFsc2VdClJlbW90ZSBQcm9jZWR1cmUgQ2FsbAogICAgQ29u dGludWF0aW9uIGRhdGEKCjAwMDAgIDAwIDMwIDQ4IDdiIDUyIDM0IDAwIDE1 IDE3IGJmIGViIDdiIDA4IDAwIDQ1IDAwICAgLjBIe1I0Li4uLi57Li5FLgow MDEwICAwMCA1MCBiOCBkNSA0MCAwMCA0MCAwNiBmYiA1ZiBjMCBhOCAwMiA4 OSBjMCBhOCAgIC5QLi5ALkAuLl8uLi4uLi4KMDAyMCAgMDIgOTkgMDggMDEg MDIgNjYgZWUgYzMgYmUgMTIgMjIgZGQgMTkgYWUgNTAgMTggICAuLi4uLmYu Li4uIi4uLlAuCjAwMzAgIGZmIGZmIDg4IDgzIDAwIDAwIDgwIDAwIDAwIDI0 IDU3IGRiIGQ0IGRmIDAwIDAwICAgLi4uLi4uLi4uJFcuLi4uLgowMDQwICAw MCAwMSAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAgIC4uLi4uLi4uLi4uLi4uLi4KMDA1MCAgMDAgMDAgMDAgMDAgMDAgMDUg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgICAgICAgICAuLi4uLi4uLi4uLi4u LgoKTm8uICAgICBUaW1lICAgICAgICBTb3VyY2UgICAgICAgICAgICAgICAg RGVzdGluYXRpb24gICAgICAgICAgIFByb3RvY29sIEluZm8KICAgICAgMiAw LjAwMDA0MCAgICAxOTIuMTY4LjIuMTUzICAgICAgICAgMTkyLjE2OC4yLjEz NyAgICAgICAgIE5GUyAgICAgIFYzIFdSSVRFIENhbGwgKFJlcGx5IEluIDMp LCBGSDoweDgxMDYwMmZjIE9mZnNldDowIExlbjoxNSBVTlNUQUJMRQoKRnJh bWUgMiAoMTkwIGJ5dGVzIG9uIHdpcmUsIDE5MCBieXRlcyBjYXB0dXJlZCkK ICAgIEFycml2YWwgVGltZTogSmFuIDMwLCAyMDEwIDEyOjQxOjQ2LjkxMDg2 ODAwMAogICAgW1RpbWUgZGVsdGEgZnJvbSBwcmV2aW91cyBjYXB0dXJlZCBm cmFtZTogMC4wMDAwNDAwMDAgc2Vjb25kc10KICAgIFtUaW1lIGRlbHRhIGZy b20gcHJldmlvdXMgZGlzcGxheWVkIGZyYW1lOiAwLjAwMDA0MDAwMCBzZWNv bmRzXQogICAgW1RpbWUgc2luY2UgcmVmZXJlbmNlIG9yIGZpcnN0IGZyYW1l OiAwLjAwMDA0MDAwMCBzZWNvbmRzXQogICAgRnJhbWUgTnVtYmVyOiAyCiAg ICBGcmFtZSBMZW5ndGg6IDE5MCBieXRlcwogICAgQ2FwdHVyZSBMZW5ndGg6 IDE5MCBieXRlcwogICAgW0ZyYW1lIGlzIG1hcmtlZDogRmFsc2VdCiAgICBb UHJvdG9jb2xzIGluIGZyYW1lOiBldGg6aXA6dGNwOnJwYzpuZnNdCiAgICBb Q29sb3JpbmcgUnVsZSBOYW1lOiBDaGVja3N1bSBFcnJvcnNdCiAgICBbQ29s b3JpbmcgUnVsZSBTdHJpbmc6IGNkcC5jaGVja3N1bV9iYWQ9PTEgfHwgZWRw LmNoZWNrc3VtX2JhZD09MSB8fCBpcC5jaGVja3N1bV9iYWQ9PTEgfHwgdGNw LmNoZWNrc3VtX2JhZD09MSB8fCB1ZHAuY2hlY2tzdW1fYmFkPT0xXQpFdGhl cm5ldCBJSSwgU3JjOiBTdXBlcm1pY183Yjo1MjozNCAoMDA6MzA6NDg6N2I6 NTI6MzQpLCBEc3Q6IEludGVsQ29yX2JmOmViOjdiICgwMDoxNToxNzpiZjpl Yjo3YikKICAgIERlc3RpbmF0aW9uOiBJbnRlbENvcl9iZjplYjo3YiAoMDA6 MTU6MTc6YmY6ZWI6N2IpCiAgICAgICAgQWRkcmVzczogSW50ZWxDb3JfYmY6 ZWI6N2IgKDAwOjE1OjE3OmJmOmViOjdiKQogICAgICAgIC4uLi4gLi4uMCAu Li4uIC4uLi4gLi4uLiAuLi4uID0gSUcgYml0OiBJbmRpdmlkdWFsIGFkZHJl c3MgKHVuaWNhc3QpCiAgICAgICAgLi4uLiAuLjAuIC4uLi4gLi4uLiAuLi4u IC4uLi4gPSBMRyBiaXQ6IEdsb2JhbGx5IHVuaXF1ZSBhZGRyZXNzIChmYWN0 b3J5IGRlZmF1bHQpCiAgICBTb3VyY2U6IFN1cGVybWljXzdiOjUyOjM0ICgw MDozMDo0ODo3Yjo1MjozNCkKICAgICAgICBBZGRyZXNzOiBTdXBlcm1pY183 Yjo1MjozNCAoMDA6MzA6NDg6N2I6NTI6MzQpCiAgICAgICAgLi4uLiAuLi4w IC4uLi4gLi4uLiAuLi4uIC4uLi4gPSBJRyBiaXQ6IEluZGl2aWR1YWwgYWRk cmVzcyAodW5pY2FzdCkKICAgICAgICAuLi4uIC4uMC4gLi4uLiAuLi4uIC4u Li4gLi4uLiA9IExHIGJpdDogR2xvYmFsbHkgdW5pcXVlIGFkZHJlc3MgKGZh Y3RvcnkgZGVmYXVsdCkKICAgIFR5cGU6IElQICgweDA4MDApCkludGVybmV0 IFByb3RvY29sLCBTcmM6IDE5Mi4xNjguMi4xNTMgKDE5Mi4xNjguMi4xNTMp LCBEc3Q6IDE5Mi4xNjguMi4xMzcgKDE5Mi4xNjguMi4xMzcpCiAgICBWZXJz aW9uOiA0CiAgICBIZWFkZXIgbGVuZ3RoOiAyMCBieXRlcwogICAgRGlmZmVy ZW50aWF0ZWQgU2VydmljZXMgRmllbGQ6IDB4MDAgKERTQ1AgMHgwMDogRGVm YXVsdDsgRUNOOiAweDAwKQogICAgICAgIDAwMDAgMDAuLiA9IERpZmZlcmVu dGlhdGVkIFNlcnZpY2VzIENvZGVwb2ludDogRGVmYXVsdCAoMHgwMCkKICAg ICAgICAuLi4uIC4uMC4gPSBFQ04tQ2FwYWJsZSBUcmFuc3BvcnQgKEVDVCk6 IDAKICAgICAgICAuLi4uIC4uLjAgPSBFQ04tQ0U6IDAKICAgIFRvdGFsIExl bmd0aDogMTc2CiAgICBJZGVudGlmaWNhdGlvbjogMHhmOGFhICg2MzY1OCkK ICAgIEZsYWdzOiAweDA0IChEb24ndCBGcmFnbWVudCkKICAgICAgICAwLi4u ID0gUmVzZXJ2ZWQgYml0OiBOb3Qgc2V0CiAgICAgICAgLjEuLiA9IERvbid0 IGZyYWdtZW50OiBTZXQKICAgICAgICAuLjAuID0gTW9yZSBmcmFnbWVudHM6 IE5vdCBzZXQKICAgIEZyYWdtZW50IG9mZnNldDogMAogICAgVGltZSB0byBs aXZlOiA2NAogICAgUHJvdG9jb2w6IFRDUCAoMHgwNikKICAgIEhlYWRlciBj aGVja3N1bTogMHhiYjJhIFtjb3JyZWN0XQogICAgICAgIFtHb29kOiBUcnVl XQogICAgICAgIFtCYWQgOiBGYWxzZV0KICAgIFNvdXJjZTogMTkyLjE2OC4y LjE1MyAoMTkyLjE2OC4yLjE1MykKICAgIERlc3RpbmF0aW9uOiAxOTIuMTY4 LjIuMTM3ICgxOTIuMTY4LjIuMTM3KQpUcmFuc21pc3Npb24gQ29udHJvbCBQ cm90b2NvbCwgU3JjIFBvcnQ6IHNzaGVsbCAoNjE0KSwgRHN0IFBvcnQ6IG5m cyAoMjA0OSksIFNlcTogMSwgQWNrOiA0MSwgTGVuOiAxMzYKICAgIFNvdXJj ZSBwb3J0OiBzc2hlbGwgKDYxNCkKICAgIERlc3RpbmF0aW9uIHBvcnQ6IG5m cyAoMjA0OSkKICAgIFNlcXVlbmNlIG51bWJlcjogMSAgICAocmVsYXRpdmUg c2VxdWVuY2UgbnVtYmVyKQogICAgW05leHQgc2VxdWVuY2UgbnVtYmVyOiAx MzcgICAgKHJlbGF0aXZlIHNlcXVlbmNlIG51bWJlcildCiAgICBBY2tub3ds ZWRnZW1lbnQgbnVtYmVyOiA0MSAgICAocmVsYXRpdmUgYWNrIG51bWJlcikK ICAgIEhlYWRlciBsZW5ndGg6IDIwIGJ5dGVzCiAgICBGbGFnczogMHgxOCAo UFNILCBBQ0spCiAgICAgICAgMC4uLiAuLi4uID0gQ29uZ2VzdGlvbiBXaW5k b3cgUmVkdWNlZCAoQ1dSKTogTm90IHNldAogICAgICAgIC4wLi4gLi4uLiA9 IEVDTi1FY2hvOiBOb3Qgc2V0CiAgICAgICAgLi4wLiAuLi4uID0gVXJnZW50 OiBOb3Qgc2V0CiAgICAgICAgLi4uMSAuLi4uID0gQWNrbm93bGVkZ21lbnQ6 IFNldAogICAgICAgIC4uLi4gMS4uLiA9IFB1c2g6IFNldAogICAgICAgIC4u Li4gLjAuLiA9IFJlc2V0OiBOb3Qgc2V0CiAgICAgICAgLi4uLiAuLjAuID0g U3luOiBOb3Qgc2V0CiAgICAgICAgLi4uLiAuLi4wID0gRmluOiBOb3Qgc2V0 CiAgICBXaW5kb3cgc2l6ZTogNjU1MzUKICAgIENoZWNrc3VtOiAweDg3MTUg W2luY29ycmVjdCwgc2hvdWxkIGJlIDB4ZWZjNCAobWF5YmUgY2F1c2VkIGJ5 ICJUQ1AgY2hlY2tzdW0gb2ZmbG9hZCI/KV0KICAgICAgICBbR29vZCBDaGVj a3N1bTogRmFsc2VdCiAgICAgICAgW0JhZCBDaGVja3N1bTogVHJ1ZV0KICAg IFtTRVEvQUNLIGFuYWx5c2lzXQogICAgICAgIFtUaGlzIGlzIGFuIEFDSyB0 byB0aGUgc2VnbWVudCBpbiBmcmFtZTogMV0KICAgICAgICBbVGhlIFJUVCB0 byBBQ0sgdGhlIHNlZ21lbnQgd2FzOiAwLjAwMDA0MDAwMCBzZWNvbmRzXQpS ZW1vdGUgUHJvY2VkdXJlIENhbGwsIFR5cGU6Q2FsbCBYSUQ6MHg1N2RiZDRl MAogICAgRnJhZ21lbnQgaGVhZGVyOiBMYXN0IGZyYWdtZW50LCAxMzIgYnl0 ZXMKICAgICAgICAxLi4uIC4uLi4gLi4uLiAuLi4uIC4uLi4gLi4uLiAuLi4u IC4uLi4gPSBMYXN0IEZyYWdtZW50OiBZZXMKICAgICAgICAuMDAwIDAwMDAg MDAwMCAwMDAwIDAwMDAgMDAwMCAxMDAwIDAxMDAgPSBGcmFnbWVudCBMZW5n dGg6IDEzMgogICAgWElEOiAweDU3ZGJkNGUwICgxNDc0MDI0NjcyKQogICAg TWVzc2FnZSBUeXBlOiBDYWxsICgwKQogICAgUlBDIFZlcnNpb246IDIKICAg IFByb2dyYW06IE5GUyAoMTAwMDAzKQogICAgUHJvZ3JhbSBWZXJzaW9uOiAz CiAgICBQcm9jZWR1cmU6IFdSSVRFICg3KQogICAgW1RoZSByZXBseSB0byB0 aGlzIHJlcXVlc3QgaXMgaW4gZnJhbWUgM10KICAgIENyZWRlbnRpYWxzCiAg ICAgICAgRmxhdm9yOiBBVVRIX1VOSVggKDEpCiAgICAgICAgTGVuZ3RoOiAy NAogICAgICAgIFN0YW1wOiAweDAwMDAwMDAwCiAgICAgICAgTWFjaGluZSBO YW1lOiA8RU1QVFk+CiAgICAgICAgICAgIGxlbmd0aDogMAogICAgICAgICAg ICBjb250ZW50czogPEVNUFRZPgogICAgICAgIFVJRDogODAKICAgICAgICBH SUQ6IDgwCiAgICAgICAgQXV4aWxpYXJ5IEdJRHMKICAgICAgICAgICAgR0lE OiA4MAogICAgVmVyaWZpZXIKICAgICAgICBGbGF2b3I6IEFVVEhfTlVMTCAo MCkKICAgICAgICBMZW5ndGg6IDAKTmV0d29yayBGaWxlIFN5c3RlbSwgV1JJ VEUgQ2FsbCBGSDoweDgxMDYwMmZjIE9mZnNldDowIExlbjoxNSBVTlNUQUJM RQogICAgW1Byb2dyYW0gVmVyc2lvbjogM10KICAgIFtWMyBQcm9jZWR1cmU6 IFdSSVRFICg3KV0KICAgIGZpbGUKICAgICAgICBsZW5ndGg6IDI4CiAgICAg ICAgW2hhc2g6IDB4ODEwNjAyZmNdCiAgICAgICAgZGVjb2RlIHR5cGUgYXM6 IHVua25vd24KICAgICAgICBmaWxlaGFuZGxlOiA4QjI2OTZBOTA3QkYwRUQ0 MEEwMDFGODcwNTAwMDAwMDAyOUYwNDAwMDAwMDAwMDAuLi4KICAgIG9mZnNl dDogMAogICAgY291bnQ6IDE1CiAgICBTdGFibGU6IFVOU1RBQkxFICgwKQog ICAgRGF0YTogPERBVEE+CiAgICAgICAgbGVuZ3RoOiAxNQogICAgICAgIGNv bnRlbnRzOiA8REFUQT4KICAgICAgICBmaWxsIGJ5dGVzOiBvcGFxdWUgZGF0 YQoKMDAwMCAgMDAgMTUgMTcgYmYgZWIgN2IgMDAgMzAgNDggN2IgNTIgMzQg MDggMDAgNDUgMDAgICAuLi4uLnsuMEh7UjQuLkUuCjAwMTAgIDAwIGIwIGY4 IGFhIDQwIDAwIDQwIDA2IGJiIDJhIGMwIGE4IDAyIDk5IGMwIGE4ICAgLi4u LkAuQC4uKi4uLi4uLgowMDIwICAwMiA4OSAwMiA2NiAwOCAwMSAyMiBkZCAx OSBhZSBlZSBjMyBiZSAzYSA1MCAxOCAgIC4uLmYuLiIuLi4uLi46UC4KMDAz MCAgZmYgZmYgODcgMTUgMDAgMDAgODAgMDAgMDAgODQgNTcgZGIgZDQgZTAg MDAgMDAgICAuLi4uLi4uLi4uVy4uLi4uCjAwNDAgIDAwIDAwIDAwIDAwIDAw IDAyIDAwIDAxIDg2IGEzIDAwIDAwIDAwIDAzIDAwIDAwICAgLi4uLi4uLi4u Li4uLi4uLgowMDUwICAwMCAwNyAwMCAwMCAwMCAwMSAwMCAwMCAwMCAxOCAw MCAwMCAwMCAwMCAwMCAwMCAgIC4uLi4uLi4uLi4uLi4uLi4KMDA2MCAgMDAg MDAgMDAgMDAgMDAgNTAgMDAgMDAgMDAgNTAgMDAgMDAgMDAgMDEgMDAgMDAg ICAuLi4uLlAuLi5QLi4uLi4uCjAwNzAgIDAwIDUwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDFjIDhiIDI2ICAgLlAuLi4uLi4uLi4uLi4u JgowMDgwICA5NiBhOSAwNyBiZiAwZSBkNCAwYSAwMCAxZiA4NyAwNSAwMCAw MCAwMCAwMiA5ZiAgIC4uLi4uLi4uLi4uLi4uLi4KMDA5MCAgMDQgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgICAuLi4u Li4uLi4uLi4uLi4uCjAwYTAgIDAwIDAwIDAwIDAwIDAwIDBmIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDBmIDM4IDM5ICAgLi4uLi4uLi4uLi4uLi44OQowMGIw ICAzOSAzOCAzOCAyMCAzMiAzNiAzMiAzMSAzNCAzNCAzMCAzMCAzMCAwMCAg ICAgICAgIDk4OCAyNjIxNDQwMDAuCgpOby4gICAgIFRpbWUgICAgICAgIFNv dXJjZSAgICAgICAgICAgICAgICBEZXN0aW5hdGlvbiAgICAgICAgICAgUHJv dG9jb2wgSW5mbwogICAgICAzIDAuMDAwMjQ3ICAgIDE5Mi4xNjguMi4xMzcg ICAgICAgICAxOTIuMTY4LjIuMTUzICAgICAgICAgTkZTICAgICAgVjMgV1JJ VEUgUmVwbHkgKENhbGwgSW4gMikgRXJyb3I6TkZTM0VSUl9JTwoKRnJhbWUg MyAoOTQgYnl0ZXMgb24gd2lyZSwgOTQgYnl0ZXMgY2FwdHVyZWQpCiAgICBB cnJpdmFsIFRpbWU6IEphbiAzMCwgMjAxMCAxMjo0MTo0Ni45MTEwNzUwMDAK ICAgIFtUaW1lIGRlbHRhIGZyb20gcHJldmlvdXMgY2FwdHVyZWQgZnJhbWU6 IDAuMDAwMjA3MDAwIHNlY29uZHNdCiAgICBbVGltZSBkZWx0YSBmcm9tIHBy ZXZpb3VzIGRpc3BsYXllZCBmcmFtZTogMC4wMDAyMDcwMDAgc2Vjb25kc10K ICAgIFtUaW1lIHNpbmNlIHJlZmVyZW5jZSBvciBmaXJzdCBmcmFtZTogMC4w MDAyNDcwMDAgc2Vjb25kc10KICAgIEZyYW1lIE51bWJlcjogMwogICAgRnJh bWUgTGVuZ3RoOiA5NCBieXRlcwogICAgQ2FwdHVyZSBMZW5ndGg6IDk0IGJ5 dGVzCiAgICBbRnJhbWUgaXMgbWFya2VkOiBGYWxzZV0KICAgIFtQcm90b2Nv bHMgaW4gZnJhbWU6IGV0aDppcDp0Y3A6cnBjXQogICAgW0NvbG9yaW5nIFJ1 bGUgTmFtZTogVENQXQogICAgW0NvbG9yaW5nIFJ1bGUgU3RyaW5nOiB0Y3Bd CkV0aGVybmV0IElJLCBTcmM6IEludGVsQ29yX2JmOmViOjdiICgwMDoxNTox NzpiZjplYjo3YiksIERzdDogU3VwZXJtaWNfN2I6NTI6MzQgKDAwOjMwOjQ4 OjdiOjUyOjM0KQogICAgRGVzdGluYXRpb246IFN1cGVybWljXzdiOjUyOjM0 ICgwMDozMDo0ODo3Yjo1MjozNCkKICAgICAgICBBZGRyZXNzOiBTdXBlcm1p Y183Yjo1MjozNCAoMDA6MzA6NDg6N2I6NTI6MzQpCiAgICAgICAgLi4uLiAu Li4wIC4uLi4gLi4uLiAuLi4uIC4uLi4gPSBJRyBiaXQ6IEluZGl2aWR1YWwg YWRkcmVzcyAodW5pY2FzdCkKICAgICAgICAuLi4uIC4uMC4gLi4uLiAuLi4u IC4uLi4gLi4uLiA9IExHIGJpdDogR2xvYmFsbHkgdW5pcXVlIGFkZHJlc3Mg KGZhY3RvcnkgZGVmYXVsdCkKICAgIFNvdXJjZTogSW50ZWxDb3JfYmY6ZWI6 N2IgKDAwOjE1OjE3OmJmOmViOjdiKQogICAgICAgIEFkZHJlc3M6IEludGVs Q29yX2JmOmViOjdiICgwMDoxNToxNzpiZjplYjo3YikKICAgICAgICAuLi4u IC4uLjAgLi4uLiAuLi4uIC4uLi4gLi4uLiA9IElHIGJpdDogSW5kaXZpZHVh bCBhZGRyZXNzICh1bmljYXN0KQogICAgICAgIC4uLi4gLi4wLiAuLi4uIC4u Li4gLi4uLiAuLi4uID0gTEcgYml0OiBHbG9iYWxseSB1bmlxdWUgYWRkcmVz cyAoZmFjdG9yeSBkZWZhdWx0KQogICAgVHlwZTogSVAgKDB4MDgwMCkKSW50 ZXJuZXQgUHJvdG9jb2wsIFNyYzogMTkyLjE2OC4yLjEzNyAoMTkyLjE2OC4y LjEzNyksIERzdDogMTkyLjE2OC4yLjE1MyAoMTkyLjE2OC4yLjE1MykKICAg IFZlcnNpb246IDQKICAgIEhlYWRlciBsZW5ndGg6IDIwIGJ5dGVzCiAgICBE aWZmZXJlbnRpYXRlZCBTZXJ2aWNlcyBGaWVsZDogMHgwMCAoRFNDUCAweDAw OiBEZWZhdWx0OyBFQ046IDB4MDApCiAgICAgICAgMDAwMCAwMC4uID0gRGlm ZmVyZW50aWF0ZWQgU2VydmljZXMgQ29kZXBvaW50OiBEZWZhdWx0ICgweDAw KQogICAgICAgIC4uLi4gLi4wLiA9IEVDTi1DYXBhYmxlIFRyYW5zcG9ydCAo RUNUKTogMAogICAgICAgIC4uLi4gLi4uMCA9IEVDTi1DRTogMAogICAgVG90 YWwgTGVuZ3RoOiA4MAogICAgSWRlbnRpZmljYXRpb246IDB4YjhkNiAoNDcz MTgpCiAgICBGbGFnczogMHgwNCAoRG9uJ3QgRnJhZ21lbnQpCiAgICAgICAg MC4uLiA9IFJlc2VydmVkIGJpdDogTm90IHNldAogICAgICAgIC4xLi4gPSBE b24ndCBmcmFnbWVudDogU2V0CiAgICAgICAgLi4wLiA9IE1vcmUgZnJhZ21l bnRzOiBOb3Qgc2V0CiAgICBGcmFnbWVudCBvZmZzZXQ6IDAKICAgIFRpbWUg dG8gbGl2ZTogNjQKICAgIFByb3RvY29sOiBUQ1AgKDB4MDYpCiAgICBIZWFk ZXIgY2hlY2tzdW06IDB4ZmI1ZSBbY29ycmVjdF0KICAgICAgICBbR29vZDog VHJ1ZV0KICAgICAgICBbQmFkIDogRmFsc2VdCiAgICBTb3VyY2U6IDE5Mi4x NjguMi4xMzcgKDE5Mi4xNjguMi4xMzcpCiAgICBEZXN0aW5hdGlvbjogMTky LjE2OC4yLjE1MyAoMTkyLjE2OC4yLjE1MykKVHJhbnNtaXNzaW9uIENvbnRy b2wgUHJvdG9jb2wsIFNyYyBQb3J0OiBuZnMgKDIwNDkpLCBEc3QgUG9ydDog c3NoZWxsICg2MTQpLCBTZXE6IDQxLCBBY2s6IDEzNywgTGVuOiA0MAogICAg U291cmNlIHBvcnQ6IG5mcyAoMjA0OSkKICAgIERlc3RpbmF0aW9uIHBvcnQ6 IHNzaGVsbCAoNjE0KQogICAgU2VxdWVuY2UgbnVtYmVyOiA0MSAgICAocmVs YXRpdmUgc2VxdWVuY2UgbnVtYmVyKQogICAgW05leHQgc2VxdWVuY2UgbnVt YmVyOiA4MSAgICAocmVsYXRpdmUgc2VxdWVuY2UgbnVtYmVyKV0KICAgIEFj a25vd2xlZGdlbWVudCBudW1iZXI6IDEzNyAgICAocmVsYXRpdmUgYWNrIG51 bWJlcikKICAgIEhlYWRlciBsZW5ndGg6IDIwIGJ5dGVzCiAgICBGbGFnczog MHgxOCAoUFNILCBBQ0spCiAgICAgICAgMC4uLiAuLi4uID0gQ29uZ2VzdGlv biBXaW5kb3cgUmVkdWNlZCAoQ1dSKTogTm90IHNldAogICAgICAgIC4wLi4g Li4uLiA9IEVDTi1FY2hvOiBOb3Qgc2V0CiAgICAgICAgLi4wLiAuLi4uID0g VXJnZW50OiBOb3Qgc2V0CiAgICAgICAgLi4uMSAuLi4uID0gQWNrbm93bGVk Z21lbnQ6IFNldAogICAgICAgIC4uLi4gMS4uLiA9IFB1c2g6IFNldAogICAg ICAgIC4uLi4gLjAuLiA9IFJlc2V0OiBOb3Qgc2V0CiAgICAgICAgLi4uLiAu LjAuID0gU3luOiBOb3Qgc2V0CiAgICAgICAgLi4uLiAuLi4wID0gRmluOiBO b3Qgc2V0CiAgICBXaW5kb3cgc2l6ZTogNjU1MzUKICAgIENoZWNrc3VtOiAw eDg3ZDIgW2NvcnJlY3RdCiAgICAgICAgW0dvb2QgQ2hlY2tzdW06IFRydWVd CiAgICAgICAgW0JhZCBDaGVja3N1bTogRmFsc2VdCiAgICBbU0VRL0FDSyBh bmFseXNpc10KICAgICAgICBbVGhpcyBpcyBhbiBBQ0sgdG8gdGhlIHNlZ21l bnQgaW4gZnJhbWU6IDJdCiAgICAgICAgW1RoZSBSVFQgdG8gQUNLIHRoZSBz ZWdtZW50IHdhczogMC4wMDAyMDcwMDAgc2Vjb25kc10KUmVtb3RlIFByb2Nl ZHVyZSBDYWxsLCBUeXBlOlJlcGx5IFhJRDoweDU3ZGJkNGUwCiAgICBGcmFn bWVudCBoZWFkZXI6IExhc3QgZnJhZ21lbnQsIDM2IGJ5dGVzCiAgICAgICAg MS4uLiAuLi4uIC4uLi4gLi4uLiAuLi4uIC4uLi4gLi4uLiAuLi4uID0gTGFz dCBGcmFnbWVudDogWWVzCiAgICAgICAgLjAwMCAwMDAwIDAwMDAgMDAwMCAw MDAwIDAwMDAgMDAxMCAwMTAwID0gRnJhZ21lbnQgTGVuZ3RoOiAzNgogICAg WElEOiAweDU3ZGJkNGUwICgxNDc0MDI0NjcyKQogICAgTWVzc2FnZSBUeXBl OiBSZXBseSAoMSkKICAgIFtQcm9ncmFtOiBORlMgKDEwMDAwMyldCiAgICBb UHJvZ3JhbSBWZXJzaW9uOiAzXQogICAgW1Byb2NlZHVyZTogV1JJVEUgKDcp XQogICAgUmVwbHkgU3RhdGU6IGFjY2VwdGVkICgwKQogICAgW1RoaXMgaXMg YSByZXBseSB0byBhIHJlcXVlc3QgaW4gZnJhbWUgMl0KICAgIFtUaW1lIGZy b20gcmVxdWVzdDogMC4wMDAyMDcwMDAgc2Vjb25kc10KICAgIFZlcmlmaWVy CiAgICAgICAgRmxhdm9yOiBBVVRIX05VTEwgKDApCiAgICAgICAgTGVuZ3Ro OiAwCiAgICBBY2NlcHQgU3RhdGU6IFJQQyBleGVjdXRlZCBzdWNjZXNzZnVs bHkgKDApCk5ldHdvcmsgRmlsZSBTeXN0ZW0sIFdSSVRFIFJlcGx5ICBFcnJv cjpORlMzRVJSX0lPCiAgICBbUHJvZ3JhbSBWZXJzaW9uOiAzXQogICAgW1Yz IFByb2NlZHVyZTogV1JJVEUgKDcpXQogICAgU3RhdHVzOiBORlMzRVJSX0lP ICg1KQogICAgZmlsZV93Y2MKICAgICAgICBiZWZvcmUKICAgICAgICAgICAg YXR0cmlidXRlc19mb2xsb3c6IG5vIHZhbHVlICgwKQogICAgICAgIGFmdGVy CiAgICAgICAgICAgIGF0dHJpYnV0ZXNfZm9sbG93OiBubyB2YWx1ZSAoMCkK CjAwMDAgIDAwIDMwIDQ4IDdiIDUyIDM0IDAwIDE1IDE3IGJmIGViIDdiIDA4 IDAwIDQ1IDAwICAgLjBIe1I0Li4uLi57Li5FLgowMDEwICAwMCA1MCBiOCBk NiA0MCAwMCA0MCAwNiBmYiA1ZSBjMCBhOCAwMiA4OSBjMCBhOCAgIC5QLi5A LkAuLl4uLi4uLi4KMDAyMCAgMDIgOTkgMDggMDEgMDIgNjYgZWUgYzMgYmUg M2EgMjIgZGQgMWEgMzYgNTAgMTggICAuLi4uLmYuLi46Ii4uNlAuCjAwMzAg IGZmIGZmIDg3IGQyIDAwIDAwIDgwIDAwIDAwIDI0IDU3IGRiIGQ0IGUwIDAw IDAwICAgLi4uLi4uLi4uJFcuLi4uLgowMDQwICAwMCAwMSAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAgIC4uLi4uLi4uLi4u Li4uLi4KMDA1MCAgMDAgMDAgMDAgMDAgMDAgMDUgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgICAgICAgICAuLi4uLi4uLi4uLi4uLgoKTm8uICAgICBUaW1l ICAgICAgICBTb3VyY2UgICAgICAgICAgICAgICAgRGVzdGluYXRpb24gICAg ICAgICAgIFByb3RvY29sIEluZm8KICAgICAgNCAwLjAwMDI3NyAgICAxOTIu MTY4LjIuMTUzICAgICAgICAgMTkyLjE2OC4yLjEzNyAgICAgICAgIE5GUyAg ICAgIFYzIFdSSVRFIENhbGwgKFJlcGx5IEluIDUpLCBGSDoweDgxMDYwMmZj IE9mZnNldDowIExlbjoxNSBVTlNUQUJMRQoKRnJhbWUgNCAoMTkwIGJ5dGVz IG9uIHdpcmUsIDE5MCBieXRlcyBjYXB0dXJlZCkKICAgIEFycml2YWwgVGlt ZTogSmFuIDMwLCAyMDEwIDEyOjQxOjQ2LjkxMTEwNTAwMAogICAgW1RpbWUg ZGVsdGEgZnJvbSBwcmV2aW91cyBjYXB0dXJlZCBmcmFtZTogMC4wMDAwMzAw MDAgc2Vjb25kc10KICAgIFtUaW1lIGRlbHRhIGZyb20gcHJldmlvdXMgZGlz cGxheWVkIGZyYW1lOiAwLjAwMDAzMDAwMCBzZWNvbmRzXQogICAgW1RpbWUg c2luY2UgcmVmZXJlbmNlIG9yIGZpcnN0IGZyYW1lOiAwLjAwMDI3NzAwMCBz ZWNvbmRzXQogICAgRnJhbWUgTnVtYmVyOiA0CiAgICBGcmFtZSBMZW5ndGg6 IDE5MCBieXRlcwogICAgQ2FwdHVyZSBMZW5ndGg6IDE5MCBieXRlcwogICAg W0ZyYW1lIGlzIG1hcmtlZDogRmFsc2VdCiAgICBbUHJvdG9jb2xzIGluIGZy YW1lOiBldGg6aXA6dGNwOnJwYzpuZnNdCiAgICBbQ29sb3JpbmcgUnVsZSBO YW1lOiBDaGVja3N1bSBFcnJvcnNdCiAgICBbQ29sb3JpbmcgUnVsZSBTdHJp bmc6IGNkcC5jaGVja3N1bV9iYWQ9PTEgfHwgZWRwLmNoZWNrc3VtX2JhZD09 MSB8fCBpcC5jaGVja3N1bV9iYWQ9PTEgfHwgdGNwLmNoZWNrc3VtX2JhZD09 MSB8fCB1ZHAuY2hlY2tzdW1fYmFkPT0xXQpFdGhlcm5ldCBJSSwgU3JjOiBT dXBlcm1pY183Yjo1MjozNCAoMDA6MzA6NDg6N2I6NTI6MzQpLCBEc3Q6IElu dGVsQ29yX2JmOmViOjdiICgwMDoxNToxNzpiZjplYjo3YikKICAgIERlc3Rp bmF0aW9uOiBJbnRlbENvcl9iZjplYjo3YiAoMDA6MTU6MTc6YmY6ZWI6N2Ip CiAgICAgICAgQWRkcmVzczogSW50ZWxDb3JfYmY6ZWI6N2IgKDAwOjE1OjE3 OmJmOmViOjdiKQogICAgICAgIC4uLi4gLi4uMCAuLi4uIC4uLi4gLi4uLiAu Li4uID0gSUcgYml0OiBJbmRpdmlkdWFsIGFkZHJlc3MgKHVuaWNhc3QpCiAg ICAgICAgLi4uLiAuLjAuIC4uLi4gLi4uLiAuLi4uIC4uLi4gPSBMRyBiaXQ6 IEdsb2JhbGx5IHVuaXF1ZSBhZGRyZXNzIChmYWN0b3J5IGRlZmF1bHQpCiAg ICBTb3VyY2U6IFN1cGVybWljXzdiOjUyOjM0ICgwMDozMDo0ODo3Yjo1Mjoz NCkKICAgICAgICBBZGRyZXNzOiBTdXBlcm1pY183Yjo1MjozNCAoMDA6MzA6 NDg6N2I6NTI6MzQpCiAgICAgICAgLi4uLiAuLi4wIC4uLi4gLi4uLiAuLi4u IC4uLi4gPSBJRyBiaXQ6IEluZGl2aWR1YWwgYWRkcmVzcyAodW5pY2FzdCkK ICAgICAgICAuLi4uIC4uMC4gLi4uLiAuLi4uIC4uLi4gLi4uLiA9IExHIGJp dDogR2xvYmFsbHkgdW5pcXVlIGFkZHJlc3MgKGZhY3RvcnkgZGVmYXVsdCkK ICAgIFR5cGU6IElQICgweDA4MDApCkludGVybmV0IFByb3RvY29sLCBTcmM6 IDE5Mi4xNjguMi4xNTMgKDE5Mi4xNjguMi4xNTMpLCBEc3Q6IDE5Mi4xNjgu Mi4xMzcgKDE5Mi4xNjguMi4xMzcpCiAgICBWZXJzaW9uOiA0CiAgICBIZWFk ZXIgbGVuZ3RoOiAyMCBieXRlcwogICAgRGlmZmVyZW50aWF0ZWQgU2Vydmlj ZXMgRmllbGQ6IDB4MDAgKERTQ1AgMHgwMDogRGVmYXVsdDsgRUNOOiAweDAw KQogICAgICAgIDAwMDAgMDAuLiA9IERpZmZlcmVudGlhdGVkIFNlcnZpY2Vz IENvZGVwb2ludDogRGVmYXVsdCAoMHgwMCkKICAgICAgICAuLi4uIC4uMC4g PSBFQ04tQ2FwYWJsZSBUcmFuc3BvcnQgKEVDVCk6IDAKICAgICAgICAuLi4u IC4uLjAgPSBFQ04tQ0U6IDAKICAgIFRvdGFsIExlbmd0aDogMTc2CiAgICBJ ZGVudGlmaWNhdGlvbjogMHhmOGFiICg2MzY1OSkKICAgIEZsYWdzOiAweDA0 IChEb24ndCBGcmFnbWVudCkKICAgICAgICAwLi4uID0gUmVzZXJ2ZWQgYml0 OiBOb3Qgc2V0CiAgICAgICAgLjEuLiA9IERvbid0IGZyYWdtZW50OiBTZXQK ICAgICAgICAuLjAuID0gTW9yZSBmcmFnbWVudHM6IE5vdCBzZXQKICAgIEZy YWdtZW50IG9mZnNldDogMAogICAgVGltZSB0byBsaXZlOiA2NAogICAgUHJv dG9jb2w6IFRDUCAoMHgwNikKICAgIEhlYWRlciBjaGVja3N1bTogMHhiYjI5 IFtjb3JyZWN0XQogICAgICAgIFtHb29kOiBUcnVlXQogICAgICAgIFtCYWQg OiBGYWxzZV0KICAgIFNvdXJjZTogMTkyLjE2OC4yLjE1MyAoMTkyLjE2OC4y LjE1MykKICAgIERlc3RpbmF0aW9uOiAxOTIuMTY4LjIuMTM3ICgxOTIuMTY4 LjIuMTM3KQpUcmFuc21pc3Npb24gQ29udHJvbCBQcm90b2NvbCwgU3JjIFBv cnQ6IHNzaGVsbCAoNjE0KSwgRHN0IFBvcnQ6IG5mcyAoMjA0OSksIFNlcTog MTM3LCBBY2s6IDgxLCBMZW46IDEzNgogICAgU291cmNlIHBvcnQ6IHNzaGVs bCAoNjE0KQogICAgRGVzdGluYXRpb24gcG9ydDogbmZzICgyMDQ5KQogICAg U2VxdWVuY2UgbnVtYmVyOiAxMzcgICAgKHJlbGF0aXZlIHNlcXVlbmNlIG51 bWJlcikKICAgIFtOZXh0IHNlcXVlbmNlIG51bWJlcjogMjczICAgIChyZWxh dGl2ZSBzZXF1ZW5jZSBudW1iZXIpXQogICAgQWNrbm93bGVkZ2VtZW50IG51 bWJlcjogODEgICAgKHJlbGF0aXZlIGFjayBudW1iZXIpCiAgICBIZWFkZXIg bGVuZ3RoOiAyMCBieXRlcwogICAgRmxhZ3M6IDB4MTggKFBTSCwgQUNLKQog ICAgICAgIDAuLi4gLi4uLiA9IENvbmdlc3Rpb24gV2luZG93IFJlZHVjZWQg KENXUik6IE5vdCBzZXQKICAgICAgICAuMC4uIC4uLi4gPSBFQ04tRWNobzog Tm90IHNldAogICAgICAgIC4uMC4gLi4uLiA9IFVyZ2VudDogTm90IHNldAog ICAgICAgIC4uLjEgLi4uLiA9IEFja25vd2xlZGdtZW50OiBTZXQKICAgICAg ICAuLi4uIDEuLi4gPSBQdXNoOiBTZXQKICAgICAgICAuLi4uIC4wLi4gPSBS ZXNldDogTm90IHNldAogICAgICAgIC4uLi4gLi4wLiA9IFN5bjogTm90IHNl dAogICAgICAgIC4uLi4gLi4uMCA9IEZpbjogTm90IHNldAogICAgV2luZG93 IHNpemU6IDY1NTM1CiAgICBDaGVja3N1bTogMHg4NzE1IFtpbmNvcnJlY3Qs IHNob3VsZCBiZSAweGVmMTMgKG1heWJlIGNhdXNlZCBieSAiVENQIGNoZWNr c3VtIG9mZmxvYWQiPyldCiAgICAgICAgW0dvb2QgQ2hlY2tzdW06IEZhbHNl XQogICAgICAgIFtCYWQgQ2hlY2tzdW06IFRydWVdCiAgICBbU0VRL0FDSyBh bmFseXNpc10KICAgICAgICBbVGhpcyBpcyBhbiBBQ0sgdG8gdGhlIHNlZ21l bnQgaW4gZnJhbWU6IDNdCiAgICAgICAgW1RoZSBSVFQgdG8gQUNLIHRoZSBz ZWdtZW50IHdhczogMC4wMDAwMzAwMDAgc2Vjb25kc10KUmVtb3RlIFByb2Nl ZHVyZSBDYWxsLCBUeXBlOkNhbGwgWElEOjB4NTdkYmQ0ZTEKICAgIEZyYWdt ZW50IGhlYWRlcjogTGFzdCBmcmFnbWVudCwgMTMyIGJ5dGVzCiAgICAgICAg MS4uLiAuLi4uIC4uLi4gLi4uLiAuLi4uIC4uLi4gLi4uLiAuLi4uID0gTGFz dCBGcmFnbWVudDogWWVzCiAgICAgICAgLjAwMCAwMDAwIDAwMDAgMDAwMCAw MDAwIDAwMDAgMTAwMCAwMTAwID0gRnJhZ21lbnQgTGVuZ3RoOiAxMzIKICAg IFhJRDogMHg1N2RiZDRlMSAoMTQ3NDAyNDY3MykKICAgIE1lc3NhZ2UgVHlw ZTogQ2FsbCAoMCkKICAgIFJQQyBWZXJzaW9uOiAyCiAgICBQcm9ncmFtOiBO RlMgKDEwMDAwMykKICAgIFByb2dyYW0gVmVyc2lvbjogMwogICAgUHJvY2Vk dXJlOiBXUklURSAoNykKICAgIFtUaGUgcmVwbHkgdG8gdGhpcyByZXF1ZXN0 IGlzIGluIGZyYW1lIDVdCiAgICBDcmVkZW50aWFscwogICAgICAgIEZsYXZv cjogQVVUSF9VTklYICgxKQogICAgICAgIExlbmd0aDogMjQKICAgICAgICBT dGFtcDogMHgwMDAwMDAwMAogICAgICAgIE1hY2hpbmUgTmFtZTogPEVNUFRZ PgogICAgICAgICAgICBsZW5ndGg6IDAKICAgICAgICAgICAgY29udGVudHM6 IDxFTVBUWT4KICAgICAgICBVSUQ6IDgwCiAgICAgICAgR0lEOiA4MAogICAg ICAgIEF1eGlsaWFyeSBHSURzCiAgICAgICAgICAgIEdJRDogODAKICAgIFZl cmlmaWVyCiAgICAgICAgRmxhdm9yOiBBVVRIX05VTEwgKDApCiAgICAgICAg TGVuZ3RoOiAwCk5ldHdvcmsgRmlsZSBTeXN0ZW0sIFdSSVRFIENhbGwgRkg6 MHg4MTA2MDJmYyBPZmZzZXQ6MCBMZW46MTUgVU5TVEFCTEUKICAgIFtQcm9n cmFtIFZlcnNpb246IDNdCiAgICBbVjMgUHJvY2VkdXJlOiBXUklURSAoNyld CiAgICBmaWxlCiAgICAgICAgbGVuZ3RoOiAyOAogICAgICAgIFtoYXNoOiAw eDgxMDYwMmZjXQogICAgICAgIGRlY29kZSB0eXBlIGFzOiB1bmtub3duCiAg ICAgICAgZmlsZWhhbmRsZTogOEIyNjk2QTkwN0JGMEVENDBBMDAxRjg3MDUw MDAwMDAwMjlGMDQwMDAwMDAwMDAwLi4uCiAgICBvZmZzZXQ6IDAKICAgIGNv dW50OiAxNQogICAgU3RhYmxlOiBVTlNUQUJMRSAoMCkKICAgIERhdGE6IDxE QVRBPgogICAgICAgIGxlbmd0aDogMTUKICAgICAgICBjb250ZW50czogPERB VEE+CiAgICAgICAgZmlsbCBieXRlczogb3BhcXVlIGRhdGEKCjAwMDAgIDAw IDE1IDE3IGJmIGViIDdiIDAwIDMwIDQ4IDdiIDUyIDM0IDA4IDAwIDQ1IDAw ICAgLi4uLi57LjBIe1I0Li5FLgowMDEwICAwMCBiMCBmOCBhYiA0MCAwMCA0 MCAwNiBiYiAyOSBjMCBhOCAwMiA5OSBjMCBhOCAgIC4uLi5ALkAuLikuLi4u Li4KMDAyMCAgMDIgODkgMDIgNjYgMDggMDEgMjIgZGQgMWEgMzYgZWUgYzMg YmUgNjIgNTAgMTggICAuLi5mLi4iLi42Li4uYlAuCjAwMzAgIGZmIGZmIDg3 IDE1IDAwIDAwIDgwIDAwIDAwIDg0IDU3IGRiIGQ0IGUxIDAwIDAwICAgLi4u Li4uLi4uLlcuLi4uLgowMDQwICAwMCAwMCAwMCAwMCAwMCAwMiAwMCAwMSA4 NiBhMyAwMCAwMCAwMCAwMyAwMCAwMCAgIC4uLi4uLi4uLi4uLi4uLi4KMDA1 MCAgMDAgMDcgMDAgMDAgMDAgMDEgMDAgMDAgMDAgMTggMDAgMDAgMDAgMDAg MDAgMDAgICAuLi4uLi4uLi4uLi4uLi4uCjAwNjAgIDAwIDAwIDAwIDAwIDAw IDUwIDAwIDAwIDAwIDUwIDAwIDAwIDAwIDAxIDAwIDAwICAgLi4uLi5QLi4u UC4uLi4uLgowMDcwICAwMCA1MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAxYyA4YiAyNiAgIC5QLi4uLi4uLi4uLi4uLiYKMDA4MCAgOTYg YTkgMDcgYmYgMGUgZDQgMGEgMDAgMWYgODcgMDUgMDAgMDAgMDAgMDIgOWYg ICAuLi4uLi4uLi4uLi4uLi4uCjAwOTAgIDA0IDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAgLi4uLi4uLi4uLi4uLi4u LgowMGEwICAwMCAwMCAwMCAwMCAwMCAwZiAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwZiAzOCAzOSAgIC4uLi4uLi4uLi4uLi4uODkKMDBiMCAgMzkgMzggMzgg MjAgMzIgMzYgMzIgMzEgMzQgMzQgMzAgMzAgMzAgMDAgICAgICAgICA5ODgg MjYyMTQ0MDAwLgoKTm8uICAgICBUaW1lICAgICAgICBTb3VyY2UgICAgICAg ICAgICAgICAgRGVzdGluYXRpb24gICAgICAgICAgIFByb3RvY29sIEluZm8K ICAgICAgNSAwLjAwMDQ5OCAgICAxOTIuMTY4LjIuMTM3ICAgICAgICAgMTky LjE2OC4yLjE1MyAgICAgICAgIE5GUyAgICAgIFYzIFdSSVRFIFJlcGx5IChD YWxsIEluIDQpIEVycm9yOk5GUzNFUlJfSU8KCkZyYW1lIDUgKDk0IGJ5dGVz IG9uIHdpcmUsIDk0IGJ5dGVzIGNhcHR1cmVkKQogICAgQXJyaXZhbCBUaW1l OiBKYW4gMzAsIDIwMTAgMTI6NDE6NDYuOTExMzI2MDAwCiAgICBbVGltZSBk ZWx0YSBmcm9tIHByZXZpb3VzIGNhcHR1cmVkIGZyYW1lOiAwLjAwMDIyMTAw MCBzZWNvbmRzXQogICAgW1RpbWUgZGVsdGEgZnJvbSBwcmV2aW91cyBkaXNw bGF5ZWQgZnJhbWU6IDAuMDAwMjIxMDAwIHNlY29uZHNdCiAgICBbVGltZSBz aW5jZSByZWZlcmVuY2Ugb3IgZmlyc3QgZnJhbWU6IDAuMDAwNDk4MDAwIHNl Y29uZHNdCiAgICBGcmFtZSBOdW1iZXI6IDUKICAgIEZyYW1lIExlbmd0aDog OTQgYnl0ZXMKICAgIENhcHR1cmUgTGVuZ3RoOiA5NCBieXRlcwogICAgW0Zy YW1lIGlzIG1hcmtlZDogRmFsc2VdCiAgICBbUHJvdG9jb2xzIGluIGZyYW1l OiBldGg6aXA6dGNwOnJwY10KICAgIFtDb2xvcmluZyBSdWxlIE5hbWU6IFRD UF0KICAgIFtDb2xvcmluZyBSdWxlIFN0cmluZzogdGNwXQpFdGhlcm5ldCBJ SSwgU3JjOiBJbnRlbENvcl9iZjplYjo3YiAoMDA6MTU6MTc6YmY6ZWI6N2Ip LCBEc3Q6IFN1cGVybWljXzdiOjUyOjM0ICgwMDozMDo0ODo3Yjo1MjozNCkK ICAgIERlc3RpbmF0aW9uOiBTdXBlcm1pY183Yjo1MjozNCAoMDA6MzA6NDg6 N2I6NTI6MzQpCiAgICAgICAgQWRkcmVzczogU3VwZXJtaWNfN2I6NTI6MzQg KDAwOjMwOjQ4OjdiOjUyOjM0KQogICAgICAgIC4uLi4gLi4uMCAuLi4uIC4u Li4gLi4uLiAuLi4uID0gSUcgYml0OiBJbmRpdmlkdWFsIGFkZHJlc3MgKHVu aWNhc3QpCiAgICAgICAgLi4uLiAuLjAuIC4uLi4gLi4uLiAuLi4uIC4uLi4g PSBMRyBiaXQ6IEdsb2JhbGx5IHVuaXF1ZSBhZGRyZXNzIChmYWN0b3J5IGRl ZmF1bHQpCiAgICBTb3VyY2U6IEludGVsQ29yX2JmOmViOjdiICgwMDoxNTox NzpiZjplYjo3YikKICAgICAgICBBZGRyZXNzOiBJbnRlbENvcl9iZjplYjo3 YiAoMDA6MTU6MTc6YmY6ZWI6N2IpCiAgICAgICAgLi4uLiAuLi4wIC4uLi4g Li4uLiAuLi4uIC4uLi4gPSBJRyBiaXQ6IEluZGl2aWR1YWwgYWRkcmVzcyAo dW5pY2FzdCkKICAgICAgICAuLi4uIC4uMC4gLi4uLiAuLi4uIC4uLi4gLi4u LiA9IExHIGJpdDogR2xvYmFsbHkgdW5pcXVlIGFkZHJlc3MgKGZhY3Rvcnkg ZGVmYXVsdCkKICAgIFR5cGU6IElQICgweDA4MDApCkludGVybmV0IFByb3Rv Y29sLCBTcmM6IDE5Mi4xNjguMi4xMzcgKDE5Mi4xNjguMi4xMzcpLCBEc3Q6 IDE5Mi4xNjguMi4xNTMgKDE5Mi4xNjguMi4xNTMpCiAgICBWZXJzaW9uOiA0 CiAgICBIZWFkZXIgbGVuZ3RoOiAyMCBieXRlcwogICAgRGlmZmVyZW50aWF0 ZWQgU2VydmljZXMgRmllbGQ6IDB4MDAgKERTQ1AgMHgwMDogRGVmYXVsdDsg RUNOOiAweDAwKQogICAgICAgIDAwMDAgMDAuLiA9IERpZmZlcmVudGlhdGVk IFNlcnZpY2VzIENvZGVwb2ludDogRGVmYXVsdCAoMHgwMCkKICAgICAgICAu Li4uIC4uMC4gPSBFQ04tQ2FwYWJsZSBUcmFuc3BvcnQgKEVDVCk6IDAKICAg ICAgICAuLi4uIC4uLjAgPSBFQ04tQ0U6IDAKICAgIFRvdGFsIExlbmd0aDog ODAKICAgIElkZW50aWZpY2F0aW9uOiAweGI4ZDcgKDQ3MzE5KQogICAgRmxh Z3M6IDB4MDQgKERvbid0IEZyYWdtZW50KQogICAgICAgIDAuLi4gPSBSZXNl cnZlZCBiaXQ6IE5vdCBzZXQKICAgICAgICAuMS4uID0gRG9uJ3QgZnJhZ21l bnQ6IFNldAogICAgICAgIC4uMC4gPSBNb3JlIGZyYWdtZW50czogTm90IHNl dAogICAgRnJhZ21lbnQgb2Zmc2V0OiAwCiAgICBUaW1lIHRvIGxpdmU6IDY0 CiAgICBQcm90b2NvbDogVENQICgweDA2KQogICAgSGVhZGVyIGNoZWNrc3Vt OiAweGZiNWQgW2NvcnJlY3RdCiAgICAgICAgW0dvb2Q6IFRydWVdCiAgICAg ICAgW0JhZCA6IEZhbHNlXQogICAgU291cmNlOiAxOTIuMTY4LjIuMTM3ICgx OTIuMTY4LjIuMTM3KQogICAgRGVzdGluYXRpb246IDE5Mi4xNjguMi4xNTMg KDE5Mi4xNjguMi4xNTMpClRyYW5zbWlzc2lvbiBDb250cm9sIFByb3RvY29s LCBTcmMgUG9ydDogbmZzICgyMDQ5KSwgRHN0IFBvcnQ6IHNzaGVsbCAoNjE0 KSwgU2VxOiA4MSwgQWNrOiAyNzMsIExlbjogNDAKICAgIFNvdXJjZSBwb3J0 OiBuZnMgKDIwNDkpCiAgICBEZXN0aW5hdGlvbiBwb3J0OiBzc2hlbGwgKDYx NCkKICAgIFNlcXVlbmNlIG51bWJlcjogODEgICAgKHJlbGF0aXZlIHNlcXVl bmNlIG51bWJlcikKICAgIFtOZXh0IHNlcXVlbmNlIG51bWJlcjogMTIxICAg IChyZWxhdGl2ZSBzZXF1ZW5jZSBudW1iZXIpXQogICAgQWNrbm93bGVkZ2Vt ZW50IG51bWJlcjogMjczICAgIChyZWxhdGl2ZSBhY2sgbnVtYmVyKQogICAg SGVhZGVyIGxlbmd0aDogMjAgYnl0ZXMKICAgIEZsYWdzOiAweDE4IChQU0gs IEFDSykKICAgICAgICAwLi4uIC4uLi4gPSBDb25nZXN0aW9uIFdpbmRvdyBS ZWR1Y2VkIChDV1IpOiBOb3Qgc2V0CiAgICAgICAgLjAuLiAuLi4uID0gRUNO LUVjaG86IE5vdCBzZXQKICAgICAgICAuLjAuIC4uLi4gPSBVcmdlbnQ6IE5v dCBzZXQKICAgICAgICAuLi4xIC4uLi4gPSBBY2tub3dsZWRnbWVudDogU2V0 CiAgICAgICAgLi4uLiAxLi4uID0gUHVzaDogU2V0CiAgICAgICAgLi4uLiAu MC4uID0gUmVzZXQ6IE5vdCBzZXQKICAgICAgICAuLi4uIC4uMC4gPSBTeW46 IE5vdCBzZXQKICAgICAgICAuLi4uIC4uLjAgPSBGaW46IE5vdCBzZXQKICAg IFdpbmRvdyBzaXplOiA2NTUzNQogICAgQ2hlY2tzdW06IDB4ODcyMSBbY29y cmVjdF0KICAgICAgICBbR29vZCBDaGVja3N1bTogVHJ1ZV0KICAgICAgICBb QmFkIENoZWNrc3VtOiBGYWxzZV0KICAgIFtTRVEvQUNLIGFuYWx5c2lzXQog ICAgICAgIFtUaGlzIGlzIGFuIEFDSyB0byB0aGUgc2VnbWVudCBpbiBmcmFt ZTogNF0KICAgICAgICBbVGhlIFJUVCB0byBBQ0sgdGhlIHNlZ21lbnQgd2Fz OiAwLjAwMDIyMTAwMCBzZWNvbmRzXQpSZW1vdGUgUHJvY2VkdXJlIENhbGws IFR5cGU6UmVwbHkgWElEOjB4NTdkYmQ0ZTEKICAgIEZyYWdtZW50IGhlYWRl cjogTGFzdCBmcmFnbWVudCwgMzYgYnl0ZXMKICAgICAgICAxLi4uIC4uLi4g Li4uLiAuLi4uIC4uLi4gLi4uLiAuLi4uIC4uLi4gPSBMYXN0IEZyYWdtZW50 OiBZZXMKICAgICAgICAuMDAwIDAwMDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAw MDEwIDAxMDAgPSBGcmFnbWVudCBMZW5ndGg6IDM2CiAgICBYSUQ6IDB4NTdk YmQ0ZTEgKDE0NzQwMjQ2NzMpCiAgICBNZXNzYWdlIFR5cGU6IFJlcGx5ICgx KQogICAgW1Byb2dyYW06IE5GUyAoMTAwMDAzKV0KICAgIFtQcm9ncmFtIFZl cnNpb246IDNdCiAgICBbUHJvY2VkdXJlOiBXUklURSAoNyldCiAgICBSZXBs eSBTdGF0ZTogYWNjZXB0ZWQgKDApCiAgICBbVGhpcyBpcyBhIHJlcGx5IHRv IGEgcmVxdWVzdCBpbiBmcmFtZSA0XQogICAgW1RpbWUgZnJvbSByZXF1ZXN0 OiAwLjAwMDIyMTAwMCBzZWNvbmRzXQogICAgVmVyaWZpZXIKICAgICAgICBG bGF2b3I6IEFVVEhfTlVMTCAoMCkKICAgICAgICBMZW5ndGg6IDAKICAgIEFj Y2VwdCBTdGF0ZTogUlBDIGV4ZWN1dGVkIHN1Y2Nlc3NmdWxseSAoMCkKTmV0 d29yayBGaWxlIFN5c3RlbSwgV1JJVEUgUmVwbHkgIEVycm9yOk5GUzNFUlJf SU8KICAgIFtQcm9ncmFtIFZlcnNpb246IDNdCiAgICBbVjMgUHJvY2VkdXJl OiBXUklURSAoNyldCiAgICBTdGF0dXM6IE5GUzNFUlJfSU8gKDUpCiAgICBm aWxlX3djYwogICAgICAgIGJlZm9yZQogICAgICAgICAgICBhdHRyaWJ1dGVz X2ZvbGxvdzogbm8gdmFsdWUgKDApCiAgICAgICAgYWZ0ZXIKICAgICAgICAg ICAgYXR0cmlidXRlc19mb2xsb3c6IG5vIHZhbHVlICgwKQoKMDAwMCAgMDAg MzAgNDggN2IgNTIgMzQgMDAgMTUgMTcgYmYgZWIgN2IgMDggMDAgNDUgMDAg ICAuMEh7UjQuLi4uLnsuLkUuCjAwMTAgIDAwIDUwIGI4IGQ3IDQwIDAwIDQw IDA2IGZiIDVkIGMwIGE4IDAyIDg5IGMwIGE4ICAgLlAuLkAuQC4uXS4uLi4u LgowMDIwICAwMiA5OSAwOCAwMSAwMiA2NiBlZSBjMyBiZSA2MiAyMiBkZCAx YSBiZSA1MCAxOCAgIC4uLi4uZi4uLmIiLi4uUC4KMDAzMCAgZmYgZmYgODcg MjEgMDAgMDAgODAgMDAgMDAgMjQgNTcgZGIgZDQgZTEgMDAgMDAgICAuLi4h Li4uLi4kVy4uLi4uCjAwNDAgIDAwIDAxIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwICAgLi4uLi4uLi4uLi4uLi4uLgowMDUw ICAwMCAwMCAwMCAwMCAwMCAwNSAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAg ICAgICAgIC4uLi4uLi4uLi4uLi4uCgpOby4gICAgIFRpbWUgICAgICAgIFNv dXJjZSAgICAgICAgICAgICAgICBEZXN0aW5hdGlvbiAgICAgICAgICAgUHJv dG9jb2wgSW5mbwogICAgICA2IDAuMDAwNTMxICAgIDE5Mi4xNjguMi4xNTMg ICAgICAgICAxOTIuMTY4LjIuMTM3ICAgICAgICAgTkZTICAgICAgVjMgV1JJ VEUgQ2FsbCAoUmVwbHkgSW4gNyksIEZIOjB4ODEwNjAyZmMgT2Zmc2V0OjAg TGVuOjE1IFVOU1RBQkxFCgpGcmFtZSA2ICgxOTAgYnl0ZXMgb24gd2lyZSwg MTkwIGJ5dGVzIGNhcHR1cmVkKQogICAgQXJyaXZhbCBUaW1lOiBKYW4gMzAs IDIwMTAgMTI6NDE6NDYuOTExMzU5MDAwCiAgICBbVGltZSBkZWx0YSBmcm9t IHByZXZpb3VzIGNhcHR1cmVkIGZyYW1lOiAwLjAwMDAzMzAwMCBzZWNvbmRz XQogICAgW1RpbWUgZGVsdGEgZnJvbSBwcmV2aW91cyBkaXNwbGF5ZWQgZnJh bWU6IDAuMDAwMDMzMDAwIHNlY29uZHNdCiAgICBbVGltZSBzaW5jZSByZWZl cmVuY2Ugb3IgZmlyc3QgZnJhbWU6IDAuMDAwNTMxMDAwIHNlY29uZHNdCiAg ICBGcmFtZSBOdW1iZXI6IDYKICAgIEZyYW1lIExlbmd0aDogMTkwIGJ5dGVz CiAgICBDYXB0dXJlIExlbmd0aDogMTkwIGJ5dGVzCiAgICBbRnJhbWUgaXMg bWFya2VkOiBGYWxzZV0KICAgIFtQcm90b2NvbHMgaW4gZnJhbWU6IGV0aDpp cDp0Y3A6cnBjOm5mc10KICAgIFtDb2xvcmluZyBSdWxlIE5hbWU6IENoZWNr c3VtIEVycm9yc10KICAgIFtDb2xvcmluZyBSdWxlIFN0cmluZzogY2RwLmNo ZWNrc3VtX2JhZD09MSB8fCBlZHAuY2hlY2tzdW1fYmFkPT0xIHx8IGlwLmNo ZWNrc3VtX2JhZD09MSB8fCB0Y3AuY2hlY2tzdW1fYmFkPT0xIHx8IHVkcC5j aGVja3N1bV9iYWQ9PTFdCkV0aGVybmV0IElJLCBTcmM6IFN1cGVybWljXzdi OjUyOjM0ICgwMDozMDo0ODo3Yjo1MjozNCksIERzdDogSW50ZWxDb3JfYmY6 ZWI6N2IgKDAwOjE1OjE3OmJmOmViOjdiKQogICAgRGVzdGluYXRpb246IElu dGVsQ29yX2JmOmViOjdiICgwMDoxNToxNzpiZjplYjo3YikKICAgICAgICBB ZGRyZXNzOiBJbnRlbENvcl9iZjplYjo3YiAoMDA6MTU6MTc6YmY6ZWI6N2Ip CiAgICAgICAgLi4uLiAuLi4wIC4uLi4gLi4uLiAuLi4uIC4uLi4gPSBJRyBi aXQ6IEluZGl2aWR1YWwgYWRkcmVzcyAodW5pY2FzdCkKICAgICAgICAuLi4u IC4uMC4gLi4uLiAuLi4uIC4uLi4gLi4uLiA9IExHIGJpdDogR2xvYmFsbHkg dW5pcXVlIGFkZHJlc3MgKGZhY3RvcnkgZGVmYXVsdCkKICAgIFNvdXJjZTog U3VwZXJtaWNfN2I6NTI6MzQgKDAwOjMwOjQ4OjdiOjUyOjM0KQogICAgICAg IEFkZHJlc3M6IFN1cGVybWljXzdiOjUyOjM0ICgwMDozMDo0ODo3Yjo1Mjoz NCkKICAgICAgICAuLi4uIC4uLjAgLi4uLiAuLi4uIC4uLi4gLi4uLiA9IElH IGJpdDogSW5kaXZpZHVhbCBhZGRyZXNzICh1bmljYXN0KQogICAgICAgIC4u Li4gLi4wLiAuLi4uIC4uLi4gLi4uLiAuLi4uID0gTEcgYml0OiBHbG9iYWxs eSB1bmlxdWUgYWRkcmVzcyAoZmFjdG9yeSBkZWZhdWx0KQogICAgVHlwZTog SVAgKDB4MDgwMCkKSW50ZXJuZXQgUHJvdG9jb2wsIFNyYzogMTkyLjE2OC4y LjE1MyAoMTkyLjE2OC4yLjE1MyksIERzdDogMTkyLjE2OC4yLjEzNyAoMTky LjE2OC4yLjEzNykKICAgIFZlcnNpb246IDQKICAgIEhlYWRlciBsZW5ndGg6 IDIwIGJ5dGVzCiAgICBEaWZmZXJlbnRpYXRlZCBTZXJ2aWNlcyBGaWVsZDog MHgwMCAoRFNDUCAweDAwOiBEZWZhdWx0OyBFQ046IDB4MDApCiAgICAgICAg MDAwMCAwMC4uID0gRGlmZmVyZW50aWF0ZWQgU2VydmljZXMgQ29kZXBvaW50 OiBEZWZhdWx0ICgweDAwKQogICAgICAgIC4uLi4gLi4wLiA9IEVDTi1DYXBh YmxlIFRyYW5zcG9ydCAoRUNUKTogMAogICAgICAgIC4uLi4gLi4uMCA9IEVD Ti1DRTogMAogICAgVG90YWwgTGVuZ3RoOiAxNzYKICAgIElkZW50aWZpY2F0 aW9uOiAweGY4YWMgKDYzNjYwKQogICAgRmxhZ3M6IDB4MDQgKERvbid0IEZy YWdtZW50KQogICAgICAgIDAuLi4gPSBSZXNlcnZlZCBiaXQ6IE5vdCBzZXQK ICAgICAgICAuMS4uID0gRG9uJ3QgZnJhZ21lbnQ6IFNldAogICAgICAgIC4u MC4gPSBNb3JlIGZyYWdtZW50czogTm90IHNldAogICAgRnJhZ21lbnQgb2Zm c2V0OiAwCiAgICBUaW1lIHRvIGxpdmU6IDY0CiAgICBQcm90b2NvbDogVENQ ICgweDA2KQogICAgSGVhZGVyIGNoZWNrc3VtOiAweGJiMjggW2NvcnJlY3Rd CiAgICAgICAgW0dvb2Q6IFRydWVdCiAgICAgICAgW0JhZCA6IEZhbHNlXQog ICAgU291cmNlOiAxOTIuMTY4LjIuMTUzICgxOTIuMTY4LjIuMTUzKQogICAg RGVzdGluYXRpb246IDE5Mi4xNjguMi4xMzcgKDE5Mi4xNjguMi4xMzcpClRy YW5zbWlzc2lvbiBDb250cm9sIFByb3RvY29sLCBTcmMgUG9ydDogc3NoZWxs ICg2MTQpLCBEc3QgUG9ydDogbmZzICgyMDQ5KSwgU2VxOiAyNzMsIEFjazog MTIxLCBMZW46IDEzNgogICAgU291cmNlIHBvcnQ6IHNzaGVsbCAoNjE0KQog ICAgRGVzdGluYXRpb24gcG9ydDogbmZzICgyMDQ5KQogICAgU2VxdWVuY2Ug bnVtYmVyOiAyNzMgICAgKHJlbGF0aXZlIHNlcXVlbmNlIG51bWJlcikKICAg IFtOZXh0IHNlcXVlbmNlIG51bWJlcjogNDA5ICAgIChyZWxhdGl2ZSBzZXF1 ZW5jZSBudW1iZXIpXQogICAgQWNrbm93bGVkZ2VtZW50IG51bWJlcjogMTIx ICAgIChyZWxhdGl2ZSBhY2sgbnVtYmVyKQogICAgSGVhZGVyIGxlbmd0aDog MjAgYnl0ZXMKICAgIEZsYWdzOiAweDE4IChQU0gsIEFDSykKICAgICAgICAw Li4uIC4uLi4gPSBDb25nZXN0aW9uIFdpbmRvdyBSZWR1Y2VkIChDV1IpOiBO b3Qgc2V0CiAgICAgICAgLjAuLiAuLi4uID0gRUNOLUVjaG86IE5vdCBzZXQK ICAgICAgICAuLjAuIC4uLi4gPSBVcmdlbnQ6IE5vdCBzZXQKICAgICAgICAu Li4xIC4uLi4gPSBBY2tub3dsZWRnbWVudDogU2V0CiAgICAgICAgLi4uLiAx Li4uID0gUHVzaDogU2V0CiAgICAgICAgLi4uLiAuMC4uID0gUmVzZXQ6IE5v dCBzZXQKICAgICAgICAuLi4uIC4uMC4gPSBTeW46IE5vdCBzZXQKICAgICAg ICAuLi4uIC4uLjAgPSBGaW46IE5vdCBzZXQKICAgIFdpbmRvdyBzaXplOiA2 NTUzNQogICAgQ2hlY2tzdW06IDB4ODcxNSBbaW5jb3JyZWN0LCBzaG91bGQg YmUgMHhlZTYyIChtYXliZSBjYXVzZWQgYnkgIlRDUCBjaGVja3N1bSBvZmZs b2FkIj8pXQogICAgICAgIFtHb29kIENoZWNrc3VtOiBGYWxzZV0KICAgICAg ICBbQmFkIENoZWNrc3VtOiBUcnVlXQogICAgW1NFUS9BQ0sgYW5hbHlzaXNd CiAgICAgICAgW1RoaXMgaXMgYW4gQUNLIHRvIHRoZSBzZWdtZW50IGluIGZy YW1lOiA1XQogICAgICAgIFtUaGUgUlRUIHRvIEFDSyB0aGUgc2VnbWVudCB3 YXM6IDAuMDAwMDMzMDAwIHNlY29uZHNdClJlbW90ZSBQcm9jZWR1cmUgQ2Fs bCwgVHlwZTpDYWxsIFhJRDoweDU3ZGJkNGUyCiAgICBGcmFnbWVudCBoZWFk ZXI6IExhc3QgZnJhZ21lbnQsIDEzMiBieXRlcwogICAgICAgIDEuLi4gLi4u LiAuLi4uIC4uLi4gLi4uLiAuLi4uIC4uLi4gLi4uLiA9IExhc3QgRnJhZ21l bnQ6IFllcwogICAgICAgIC4wMDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAwMDAw IDEwMDAgMDEwMCA9IEZyYWdtZW50IExlbmd0aDogMTMyCiAgICBYSUQ6IDB4 NTdkYmQ0ZTIgKDE0NzQwMjQ2NzQpCiAgICBNZXNzYWdlIFR5cGU6IENhbGwg KDApCiAgICBSUEMgVmVyc2lvbjogMgogICAgUHJvZ3JhbTogTkZTICgxMDAw MDMpCiAgICBQcm9ncmFtIFZlcnNpb246IDMKICAgIFByb2NlZHVyZTogV1JJ VEUgKDcpCiAgICBbVGhlIHJlcGx5IHRvIHRoaXMgcmVxdWVzdCBpcyBpbiBm cmFtZSA3XQogICAgQ3JlZGVudGlhbHMKICAgICAgICBGbGF2b3I6IEFVVEhf VU5JWCAoMSkKICAgICAgICBMZW5ndGg6IDI0CiAgICAgICAgU3RhbXA6IDB4 MDAwMDAwMDAKICAgICAgICBNYWNoaW5lIE5hbWU6IDxFTVBUWT4KICAgICAg ICAgICAgbGVuZ3RoOiAwCiAgICAgICAgICAgIGNvbnRlbnRzOiA8RU1QVFk+ CiAgICAgICAgVUlEOiA4MAogICAgICAgIEdJRDogODAKICAgICAgICBBdXhp bGlhcnkgR0lEcwogICAgICAgICAgICBHSUQ6IDgwCiAgICBWZXJpZmllcgog ICAgICAgIEZsYXZvcjogQVVUSF9OVUxMICgwKQogICAgICAgIExlbmd0aDog MApOZXR3b3JrIEZpbGUgU3lzdGVtLCBXUklURSBDYWxsIEZIOjB4ODEwNjAy ZmMgT2Zmc2V0OjAgTGVuOjE1IFVOU1RBQkxFCiAgICBbUHJvZ3JhbSBWZXJz aW9uOiAzXQogICAgW1YzIFByb2NlZHVyZTogV1JJVEUgKDcpXQogICAgZmls ZQogICAgICAgIGxlbmd0aDogMjgKICAgICAgICBbaGFzaDogMHg4MTA2MDJm Y10KICAgICAgICBkZWNvZGUgdHlwZSBhczogdW5rbm93bgogICAgICAgIGZp bGVoYW5kbGU6IDhCMjY5NkE5MDdCRjBFRDQwQTAwMUY4NzA1MDAwMDAwMDI5 RjA0MDAwMDAwMDAwMC4uLgogICAgb2Zmc2V0OiAwCiAgICBjb3VudDogMTUK ICAgIFN0YWJsZTogVU5TVEFCTEUgKDApCiAgICBEYXRhOiA8REFUQT4KICAg ICAgICBsZW5ndGg6IDE1CiAgICAgICAgY29udGVudHM6IDxEQVRBPgogICAg ICAgIGZpbGwgYnl0ZXM6IG9wYXF1ZSBkYXRhCgowMDAwICAwMCAxNSAxNyBi ZiBlYiA3YiAwMCAzMCA0OCA3YiA1MiAzNCAwOCAwMCA0NSAwMCAgIC4uLi4u ey4wSHtSNC4uRS4KMDAxMCAgMDAgYjAgZjggYWMgNDAgMDAgNDAgMDYgYmIg MjggYzAgYTggMDIgOTkgYzAgYTggICAuLi4uQC5ALi4oLi4uLi4uCjAwMjAg IDAyIDg5IDAyIDY2IDA4IDAxIDIyIGRkIDFhIGJlIGVlIGMzIGJlIDhhIDUw IDE4ICAgLi4uZi4uIi4uLi4uLi5QLgowMDMwICBmZiBmZiA4NyAxNSAwMCAw MCA4MCAwMCAwMCA4NCA1NyBkYiBkNCBlMiAwMCAwMCAgIC4uLi4uLi4uLi5X Li4uLi4KMDA0MCAgMDAgMDAgMDAgMDAgMDAgMDIgMDAgMDEgODYgYTMgMDAg MDAgMDAgMDMgMDAgMDAgICAuLi4uLi4uLi4uLi4uLi4uCjAwNTAgIDAwIDA3 IDAwIDAwIDAwIDAxIDAwIDAwIDAwIDE4IDAwIDAwIDAwIDAwIDAwIDAwICAg Li4uLi4uLi4uLi4uLi4uLgowMDYwICAwMCAwMCAwMCAwMCAwMCA1MCAwMCAw MCAwMCA1MCAwMCAwMCAwMCAwMSAwMCAwMCAgIC4uLi4uUC4uLlAuLi4uLi4K MDA3MCAgMDAgNTAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MWMgOGIgMjYgICAuUC4uLi4uLi4uLi4uLi4mCjAwODAgIDk2IGE5IDA3IGJm IDBlIGQ0IDBhIDAwIDFmIDg3IDA1IDAwIDAwIDAwIDAyIDlmICAgLi4uLi4u Li4uLi4uLi4uLgowMDkwICAwNCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAgIC4uLi4uLi4uLi4uLi4uLi4KMDBhMCAg MDAgMDAgMDAgMDAgMDAgMGYgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMGYgMzgg MzkgICAuLi4uLi4uLi4uLi4uLjg5CjAwYjAgIDM5IDM4IDM4IDIwIDMyIDM2 IDMyIDMxIDM0IDM0IDMwIDMwIDMwIDAwICAgICAgICAgOTg4IDI2MjE0NDAw MC4KCk5vLiAgICAgVGltZSAgICAgICAgU291cmNlICAgICAgICAgICAgICAg IERlc3RpbmF0aW9uICAgICAgICAgICBQcm90b2NvbCBJbmZvCiAgICAgIDcg MC4wMDA3NDcgICAgMTkyLjE2OC4yLjEzNyAgICAgICAgIDE5Mi4xNjguMi4x NTMgICAgICAgICBORlMgICAgICBWMyBXUklURSBSZXBseSAoQ2FsbCBJbiA2 KSBFcnJvcjpORlMzRVJSX0lPCgpGcmFtZSA3ICg5NCBieXRlcyBvbiB3aXJl LCA5NCBieXRlcyBjYXB0dXJlZCkKICAgIEFycml2YWwgVGltZTogSmFuIDMw LCAyMDEwIDEyOjQxOjQ2LjkxMTU3NTAwMAogICAgW1RpbWUgZGVsdGEgZnJv bSBwcmV2aW91cyBjYXB0dXJlZCBmcmFtZTogMC4wMDAyMTYwMDAgc2Vjb25k c10KICAgIFtUaW1lIGRlbHRhIGZyb20gcHJldmlvdXMgZGlzcGxheWVkIGZy YW1lOiAwLjAwMDIxNjAwMCBzZWNvbmRzXQogICAgW1RpbWUgc2luY2UgcmVm ZXJlbmNlIG9yIGZpcnN0IGZyYW1lOiAwLjAwMDc0NzAwMCBzZWNvbmRzXQog ICAgRnJhbWUgTnVtYmVyOiA3CiAgICBGcmFtZSBMZW5ndGg6IDk0IGJ5dGVz CiAgICBDYXB0dXJlIExlbmd0aDogOTQgYnl0ZXMKICAgIFtGcmFtZSBpcyBt YXJrZWQ6IEZhbHNlXQogICAgW1Byb3RvY29scyBpbiBmcmFtZTogZXRoOmlw OnRjcDpycGNdCiAgICBbQ29sb3JpbmcgUnVsZSBOYW1lOiBUQ1BdCiAgICBb Q29sb3JpbmcgUnVsZSBTdHJpbmc6IHRjcF0KRXRoZXJuZXQgSUksIFNyYzog SW50ZWxDb3JfYmY6ZWI6N2IgKDAwOjE1OjE3OmJmOmViOjdiKSwgRHN0OiBT dXBlcm1pY183Yjo1MjozNCAoMDA6MzA6NDg6N2I6NTI6MzQpCiAgICBEZXN0 aW5hdGlvbjogU3VwZXJtaWNfN2I6NTI6MzQgKDAwOjMwOjQ4OjdiOjUyOjM0 KQogICAgICAgIEFkZHJlc3M6IFN1cGVybWljXzdiOjUyOjM0ICgwMDozMDo0 ODo3Yjo1MjozNCkKICAgICAgICAuLi4uIC4uLjAgLi4uLiAuLi4uIC4uLi4g Li4uLiA9IElHIGJpdDogSW5kaXZpZHVhbCBhZGRyZXNzICh1bmljYXN0KQog ICAgICAgIC4uLi4gLi4wLiAuLi4uIC4uLi4gLi4uLiAuLi4uID0gTEcgYml0 OiBHbG9iYWxseSB1bmlxdWUgYWRkcmVzcyAoZmFjdG9yeSBkZWZhdWx0KQog ICAgU291cmNlOiBJbnRlbENvcl9iZjplYjo3YiAoMDA6MTU6MTc6YmY6ZWI6 N2IpCiAgICAgICAgQWRkcmVzczogSW50ZWxDb3JfYmY6ZWI6N2IgKDAwOjE1 OjE3OmJmOmViOjdiKQogICAgICAgIC4uLi4gLi4uMCAuLi4uIC4uLi4gLi4u LiAuLi4uID0gSUcgYml0OiBJbmRpdmlkdWFsIGFkZHJlc3MgKHVuaWNhc3Qp CiAgICAgICAgLi4uLiAuLjAuIC4uLi4gLi4uLiAuLi4uIC4uLi4gPSBMRyBi aXQ6IEdsb2JhbGx5IHVuaXF1ZSBhZGRyZXNzIChmYWN0b3J5IGRlZmF1bHQp CiAgICBUeXBlOiBJUCAoMHgwODAwKQpJbnRlcm5ldCBQcm90b2NvbCwgU3Jj OiAxOTIuMTY4LjIuMTM3ICgxOTIuMTY4LjIuMTM3KSwgRHN0OiAxOTIuMTY4 LjIuMTUzICgxOTIuMTY4LjIuMTUzKQogICAgVmVyc2lvbjogNAogICAgSGVh ZGVyIGxlbmd0aDogMjAgYnl0ZXMKICAgIERpZmZlcmVudGlhdGVkIFNlcnZp Y2VzIEZpZWxkOiAweDAwIChEU0NQIDB4MDA6IERlZmF1bHQ7IEVDTjogMHgw MCkKICAgICAgICAwMDAwIDAwLi4gPSBEaWZmZXJlbnRpYXRlZCBTZXJ2aWNl cyBDb2RlcG9pbnQ6IERlZmF1bHQgKDB4MDApCiAgICAgICAgLi4uLiAuLjAu ID0gRUNOLUNhcGFibGUgVHJhbnNwb3J0IChFQ1QpOiAwCiAgICAgICAgLi4u LiAuLi4wID0gRUNOLUNFOiAwCiAgICBUb3RhbCBMZW5ndGg6IDgwCiAgICBJ ZGVudGlmaWNhdGlvbjogMHhiOGQ4ICg0NzMyMCkKICAgIEZsYWdzOiAweDA0 IChEb24ndCBGcmFnbWVudCkKICAgICAgICAwLi4uID0gUmVzZXJ2ZWQgYml0 OiBOb3Qgc2V0CiAgICAgICAgLjEuLiA9IERvbid0IGZyYWdtZW50OiBTZXQK ICAgICAgICAuLjAuID0gTW9yZSBmcmFnbWVudHM6IE5vdCBzZXQKICAgIEZy YWdtZW50IG9mZnNldDogMAogICAgVGltZSB0byBsaXZlOiA2NAogICAgUHJv dG9jb2w6IFRDUCAoMHgwNikKICAgIEhlYWRlciBjaGVja3N1bTogMHhmYjVj IFtjb3JyZWN0XQogICAgICAgIFtHb29kOiBUcnVlXQogICAgICAgIFtCYWQg OiBGYWxzZV0KICAgIFNvdXJjZTogMTkyLjE2OC4yLjEzNyAoMTkyLjE2OC4y LjEzNykKICAgIERlc3RpbmF0aW9uOiAxOTIuMTY4LjIuMTUzICgxOTIuMTY4 LjIuMTUzKQpUcmFuc21pc3Npb24gQ29udHJvbCBQcm90b2NvbCwgU3JjIFBv cnQ6IG5mcyAoMjA0OSksIERzdCBQb3J0OiBzc2hlbGwgKDYxNCksIFNlcTog MTIxLCBBY2s6IDQwOSwgTGVuOiA0MAogICAgU291cmNlIHBvcnQ6IG5mcyAo MjA0OSkKICAgIERlc3RpbmF0aW9uIHBvcnQ6IHNzaGVsbCAoNjE0KQogICAg U2VxdWVuY2UgbnVtYmVyOiAxMjEgICAgKHJlbGF0aXZlIHNlcXVlbmNlIG51 bWJlcikKICAgIFtOZXh0IHNlcXVlbmNlIG51bWJlcjogMTYxICAgIChyZWxh dGl2ZSBzZXF1ZW5jZSBudW1iZXIpXQogICAgQWNrbm93bGVkZ2VtZW50IG51 bWJlcjogNDA5ICAgIChyZWxhdGl2ZSBhY2sgbnVtYmVyKQogICAgSGVhZGVy IGxlbmd0aDogMjAgYnl0ZXMKICAgIEZsYWdzOiAweDE4IChQU0gsIEFDSykK ICAgICAgICAwLi4uIC4uLi4gPSBDb25nZXN0aW9uIFdpbmRvdyBSZWR1Y2Vk IChDV1IpOiBOb3Qgc2V0CiAgICAgICAgLjAuLiAuLi4uID0gRUNOLUVjaG86 IE5vdCBzZXQKICAgICAgICAuLjAuIC4uLi4gPSBVcmdlbnQ6IE5vdCBzZXQK ICAgICAgICAuLi4xIC4uLi4gPSBBY2tub3dsZWRnbWVudDogU2V0CiAgICAg ICAgLi4uLiAxLi4uID0gUHVzaDogU2V0CiAgICAgICAgLi4uLiAuMC4uID0g UmVzZXQ6IE5vdCBzZXQKICAgICAgICAuLi4uIC4uMC4gPSBTeW46IE5vdCBz ZXQKICAgICAgICAuLi4uIC4uLjAgPSBGaW46IE5vdCBzZXQKICAgIFdpbmRv dyBzaXplOiA2NTUzNQogICAgQ2hlY2tzdW06IDB4ODY3MCBbY29ycmVjdF0K ICAgICAgICBbR29vZCBDaGVja3N1bTogVHJ1ZV0KICAgICAgICBbQmFkIENo ZWNrc3VtOiBGYWxzZV0KICAgIFtTRVEvQUNLIGFuYWx5c2lzXQogICAgICAg IFtUaGlzIGlzIGFuIEFDSyB0byB0aGUgc2VnbWVudCBpbiBmcmFtZTogNl0K ICAgICAgICBbVGhlIFJUVCB0byBBQ0sgdGhlIHNlZ21lbnQgd2FzOiAwLjAw MDIxNjAwMCBzZWNvbmRzXQpSZW1vdGUgUHJvY2VkdXJlIENhbGwsIFR5cGU6 UmVwbHkgWElEOjB4NTdkYmQ0ZTIKICAgIEZyYWdtZW50IGhlYWRlcjogTGFz dCBmcmFnbWVudCwgMzYgYnl0ZXMKICAgICAgICAxLi4uIC4uLi4gLi4uLiAu Li4uIC4uLi4gLi4uLiAuLi4uIC4uLi4gPSBMYXN0IEZyYWdtZW50OiBZZXMK ICAgICAgICAuMDAwIDAwMDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAwMDEwIDAx MDAgPSBGcmFnbWVudCBMZW5ndGg6IDM2CiAgICBYSUQ6IDB4NTdkYmQ0ZTIg KDE0NzQwMjQ2NzQpCiAgICBNZXNzYWdlIFR5cGU6IFJlcGx5ICgxKQogICAg W1Byb2dyYW06IE5GUyAoMTAwMDAzKV0KICAgIFtQcm9ncmFtIFZlcnNpb246 IDNdCiAgICBbUHJvY2VkdXJlOiBXUklURSAoNyldCiAgICBSZXBseSBTdGF0 ZTogYWNjZXB0ZWQgKDApCiAgICBbVGhpcyBpcyBhIHJlcGx5IHRvIGEgcmVx dWVzdCBpbiBmcmFtZSA2XQogICAgW1RpbWUgZnJvbSByZXF1ZXN0OiAwLjAw MDIxNjAwMCBzZWNvbmRzXQogICAgVmVyaWZpZXIKICAgICAgICBGbGF2b3I6 IEFVVEhfTlVMTCAoMCkKICAgICAgICBMZW5ndGg6IDAKICAgIEFjY2VwdCBT dGF0ZTogUlBDIGV4ZWN1dGVkIHN1Y2Nlc3NmdWxseSAoMCkKTmV0d29yayBG aWxlIFN5c3RlbSwgV1JJVEUgUmVwbHkgIEVycm9yOk5GUzNFUlJfSU8KICAg IFtQcm9ncmFtIFZlcnNpb246IDNdCiAgICBbVjMgUHJvY2VkdXJlOiBXUklU RSAoNyldCiAgICBTdGF0dXM6IE5GUzNFUlJfSU8gKDUpCiAgICBmaWxlX3dj YwogICAgICAgIGJlZm9yZQogICAgICAgICAgICBhdHRyaWJ1dGVzX2ZvbGxv dzogbm8gdmFsdWUgKDApCiAgICAgICAgYWZ0ZXIKICAgICAgICAgICAgYXR0 cmlidXRlc19mb2xsb3c6IG5vIHZhbHVlICgwKQoKMDAwMCAgMDAgMzAgNDgg N2IgNTIgMzQgMDAgMTUgMTcgYmYgZWIgN2IgMDggMDAgNDUgMDAgICAuMEh7 UjQuLi4uLnsuLkUuCjAwMTAgIDAwIDUwIGI4IGQ4IDQwIDAwIDQwIDA2IGZi IDVjIGMwIGE4IDAyIDg5IGMwIGE4ICAgLlAuLkAuQC4uXC4uLi4uLgowMDIw ICAwMiA5OSAwOCAwMSAwMiA2NiBlZSBjMyBiZSA4YSAyMiBkZCAxYiA0NiA1 MCAxOCAgIC4uLi4uZi4uLi4iLi5GUC4KMDAzMCAgZmYgZmYgODYgNzAgMDAg MDAgODAgMDAgMDAgMjQgNTcgZGIgZDQgZTIgMDAgMDAgICAuLi5wLi4uLi4k Vy4uLi4uCjAwNDAgIDAwIDAxIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwICAgLi4uLi4uLi4uLi4uLi4uLgowMDUwICAwMCAw MCAwMCAwMCAwMCAwNSAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAgICAgICAg IC4uLi4uLi4uLi4uLi4uCgpOby4gICAgIFRpbWUgICAgICAgIFNvdXJjZSAg ICAgICAgICAgICAgICBEZXN0aW5hdGlvbiAgICAgICAgICAgUHJvdG9jb2wg SW5mbwogICAgICA4IDAuMDAwNzc2ICAgIDE5Mi4xNjguMi4xNTMgICAgICAg ICAxOTIuMTY4LjIuMTM3ICAgICAgICAgTkZTICAgICAgVjMgV1JJVEUgQ2Fs bCAoUmVwbHkgSW4gOSksIEZIOjB4ODEwNjAyZmMgT2Zmc2V0OjAgTGVuOjE1 IFVOU1RBQkxFCgpGcmFtZSA4ICgxOTAgYnl0ZXMgb24gd2lyZSwgMTkwIGJ5 dGVzIGNhcHR1cmVkKQogICAgQXJyaXZhbCBUaW1lOiBKYW4gMzAsIDIwMTAg MTI6NDE6NDYuOTExNjA0MDAwCiAgICBbVGltZSBkZWx0YSBmcm9tIHByZXZp b3VzIGNhcHR1cmVkIGZyYW1lOiAwLjAwMDAyOTAwMCBzZWNvbmRzXQogICAg W1RpbWUgZGVsdGEgZnJvbSBwcmV2aW91cyBkaXNwbGF5ZWQgZnJhbWU6IDAu MDAwMDI5MDAwIHNlY29uZHNdCiAgICBbVGltZSBzaW5jZSByZWZlcmVuY2Ug b3IgZmlyc3QgZnJhbWU6IDAuMDAwNzc2MDAwIHNlY29uZHNdCiAgICBGcmFt ZSBOdW1iZXI6IDgKICAgIEZyYW1lIExlbmd0aDogMTkwIGJ5dGVzCiAgICBD YXB0dXJlIExlbmd0aDogMTkwIGJ5dGVzCiAgICBbRnJhbWUgaXMgbWFya2Vk OiBGYWxzZV0KICAgIFtQcm90b2NvbHMgaW4gZnJhbWU6IGV0aDppcDp0Y3A6 cnBjOm5mc10KICAgIFtDb2xvcmluZyBSdWxlIE5hbWU6IENoZWNrc3VtIEVy cm9yc10KICAgIFtDb2xvcmluZyBSdWxlIFN0cmluZzogY2RwLmNoZWNrc3Vt X2JhZD09MSB8fCBlZHAuY2hlY2tzdW1fYmFkPT0xIHx8IGlwLmNoZWNrc3Vt X2JhZD09MSB8fCB0Y3AuY2hlY2tzdW1fYmFkPT0xIHx8IHVkcC5jaGVja3N1 bV9iYWQ9PTFdCkV0aGVybmV0IElJLCBTcmM6IFN1cGVybWljXzdiOjUyOjM0 ICgwMDozMDo0ODo3Yjo1MjozNCksIERzdDogSW50ZWxDb3JfYmY6ZWI6N2Ig KDAwOjE1OjE3OmJmOmViOjdiKQogICAgRGVzdGluYXRpb246IEludGVsQ29y X2JmOmViOjdiICgwMDoxNToxNzpiZjplYjo3YikKICAgICAgICBBZGRyZXNz OiBJbnRlbENvcl9iZjplYjo3YiAoMDA6MTU6MTc6YmY6ZWI6N2IpCiAgICAg ICAgLi4uLiAuLi4wIC4uLi4gLi4uLiAuLi4uIC4uLi4gPSBJRyBiaXQ6IElu ZGl2aWR1YWwgYWRkcmVzcyAodW5pY2FzdCkKICAgICAgICAuLi4uIC4uMC4g Li4uLiAuLi4uIC4uLi4gLi4uLiA9IExHIGJpdDogR2xvYmFsbHkgdW5pcXVl IGFkZHJlc3MgKGZhY3RvcnkgZGVmYXVsdCkKICAgIFNvdXJjZTogU3VwZXJt aWNfN2I6NTI6MzQgKDAwOjMwOjQ4OjdiOjUyOjM0KQogICAgICAgIEFkZHJl c3M6IFN1cGVybWljXzdiOjUyOjM0ICgwMDozMDo0ODo3Yjo1MjozNCkKICAg ICAgICAuLi4uIC4uLjAgLi4uLiAuLi4uIC4uLi4gLi4uLiA9IElHIGJpdDog SW5kaXZpZHVhbCBhZGRyZXNzICh1bmljYXN0KQogICAgICAgIC4uLi4gLi4w LiAuLi4uIC4uLi4gLi4uLiAuLi4uID0gTEcgYml0OiBHbG9iYWxseSB1bmlx dWUgYWRkcmVzcyAoZmFjdG9yeSBkZWZhdWx0KQogICAgVHlwZTogSVAgKDB4 MDgwMCkKSW50ZXJuZXQgUHJvdG9jb2wsIFNyYzogMTkyLjE2OC4yLjE1MyAo MTkyLjE2OC4yLjE1MyksIERzdDogMTkyLjE2OC4yLjEzNyAoMTkyLjE2OC4y LjEzNykKICAgIFZlcnNpb246IDQKICAgIEhlYWRlciBsZW5ndGg6IDIwIGJ5 dGVzCiAgICBEaWZmZXJlbnRpYXRlZCBTZXJ2aWNlcyBGaWVsZDogMHgwMCAo RFNDUCAweDAwOiBEZWZhdWx0OyBFQ046IDB4MDApCiAgICAgICAgMDAwMCAw MC4uID0gRGlmZmVyZW50aWF0ZWQgU2VydmljZXMgQ29kZXBvaW50OiBEZWZh dWx0ICgweDAwKQogICAgICAgIC4uLi4gLi4wLiA9IEVDTi1DYXBhYmxlIFRy YW5zcG9ydCAoRUNUKTogMAogICAgICAgIC4uLi4gLi4uMCA9IEVDTi1DRTog MAogICAgVG90YWwgTGVuZ3RoOiAxNzYKICAgIElkZW50aWZpY2F0aW9uOiAw eGY4YWQgKDYzNjYxKQogICAgRmxhZ3M6IDB4MDQgKERvbid0IEZyYWdtZW50 KQogICAgICAgIDAuLi4gPSBSZXNlcnZlZCBiaXQ6IE5vdCBzZXQKICAgICAg ICAuMS4uID0gRG9uJ3QgZnJhZ21lbnQ6IFNldAogICAgICAgIC4uMC4gPSBN b3JlIGZyYWdtZW50czogTm90IHNldAogICAgRnJhZ21lbnQgb2Zmc2V0OiAw CiAgICBUaW1lIHRvIGxpdmU6IDY0CiAgICBQcm90b2NvbDogVENQICgweDA2 KQogICAgSGVhZGVyIGNoZWNrc3VtOiAweGJiMjcgW2NvcnJlY3RdCiAgICAg ICAgW0dvb2Q6IFRydWVdCiAgICAgICAgW0JhZCA6IEZhbHNlXQogICAgU291 cmNlOiAxOTIuMTY4LjIuMTUzICgxOTIuMTY4LjIuMTUzKQogICAgRGVzdGlu YXRpb246IDE5Mi4xNjguMi4xMzcgKDE5Mi4xNjguMi4xMzcpClRyYW5zbWlz c2lvbiBDb250cm9sIFByb3RvY29sLCBTcmMgUG9ydDogc3NoZWxsICg2MTQp LCBEc3QgUG9ydDogbmZzICgyMDQ5KSwgU2VxOiA0MDksIEFjazogMTYxLCBM ZW46IDEzNgogICAgU291cmNlIHBvcnQ6IHNzaGVsbCAoNjE0KQogICAgRGVz dGluYXRpb24gcG9ydDogbmZzICgyMDQ5KQogICAgU2VxdWVuY2UgbnVtYmVy OiA0MDkgICAgKHJlbGF0aXZlIHNlcXVlbmNlIG51bWJlcikKICAgIFtOZXh0 IHNlcXVlbmNlIG51bWJlcjogNTQ1ICAgIChyZWxhdGl2ZSBzZXF1ZW5jZSBu dW1iZXIpXQogICAgQWNrbm93bGVkZ2VtZW50IG51bWJlcjogMTYxICAgIChy ZWxhdGl2ZSBhY2sgbnVtYmVyKQogICAgSGVhZGVyIGxlbmd0aDogMjAgYnl0 ZXMKICAgIEZsYWdzOiAweDE4IChQU0gsIEFDSykKICAgICAgICAwLi4uIC4u Li4gPSBDb25nZXN0aW9uIFdpbmRvdyBSZWR1Y2VkIChDV1IpOiBOb3Qgc2V0 CiAgICAgICAgLjAuLiAuLi4uID0gRUNOLUVjaG86IE5vdCBzZXQKICAgICAg ICAuLjAuIC4uLi4gPSBVcmdlbnQ6IE5vdCBzZXQKICAgICAgICAuLi4xIC4u Li4gPSBBY2tub3dsZWRnbWVudDogU2V0CiAgICAgICAgLi4uLiAxLi4uID0g UHVzaDogU2V0CiAgICAgICAgLi4uLiAuMC4uID0gUmVzZXQ6IE5vdCBzZXQK ICAgICAgICAuLi4uIC4uMC4gPSBTeW46IE5vdCBzZXQKICAgICAgICAuLi4u IC4uLjAgPSBGaW46IE5vdCBzZXQKICAgIFdpbmRvdyBzaXplOiA2NTUzNQog ICAgQ2hlY2tzdW06IDB4ODcxNSBbaW5jb3JyZWN0LCBzaG91bGQgYmUgMHhl ZGIxIChtYXliZSBjYXVzZWQgYnkgIlRDUCBjaGVja3N1bSBvZmZsb2FkIj8p XQogICAgICAgIFtHb29kIENoZWNrc3VtOiBGYWxzZV0KICAgICAgICBbQmFk IENoZWNrc3VtOiBUcnVlXQogICAgW1NFUS9BQ0sgYW5hbHlzaXNdCiAgICAg ICAgW1RoaXMgaXMgYW4gQUNLIHRvIHRoZSBzZWdtZW50IGluIGZyYW1lOiA3 XQogICAgICAgIFtUaGUgUlRUIHRvIEFDSyB0aGUgc2VnbWVudCB3YXM6IDAu MDAwMDI5MDAwIHNlY29uZHNdClJlbW90ZSBQcm9jZWR1cmUgQ2FsbCwgVHlw ZTpDYWxsIFhJRDoweDU3ZGJkNGUzCiAgICBGcmFnbWVudCBoZWFkZXI6IExh c3QgZnJhZ21lbnQsIDEzMiBieXRlcwogICAgICAgIDEuLi4gLi4uLiAuLi4u IC4uLi4gLi4uLiAuLi4uIC4uLi4gLi4uLiA9IExhc3QgRnJhZ21lbnQ6IFll cwogICAgICAgIC4wMDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAwMDAwIDEwMDAg MDEwMCA9IEZyYWdtZW50IExlbmd0aDogMTMyCiAgICBYSUQ6IDB4NTdkYmQ0 ZTMgKDE0NzQwMjQ2NzUpCiAgICBNZXNzYWdlIFR5cGU6IENhbGwgKDApCiAg ICBSUEMgVmVyc2lvbjogMgogICAgUHJvZ3JhbTogTkZTICgxMDAwMDMpCiAg ICBQcm9ncmFtIFZlcnNpb246IDMKICAgIFByb2NlZHVyZTogV1JJVEUgKDcp CiAgICBbVGhlIHJlcGx5IHRvIHRoaXMgcmVxdWVzdCBpcyBpbiBmcmFtZSA5 XQogICAgQ3JlZGVudGlhbHMKICAgICAgICBGbGF2b3I6IEFVVEhfVU5JWCAo MSkKICAgICAgICBMZW5ndGg6IDI0CiAgICAgICAgU3RhbXA6IDB4MDAwMDAw MDAKICAgICAgICBNYWNoaW5lIE5hbWU6IDxFTVBUWT4KICAgICAgICAgICAg bGVuZ3RoOiAwCiAgICAgICAgICAgIGNvbnRlbnRzOiA8RU1QVFk+CiAgICAg ICAgVUlEOiA4MAogICAgICAgIEdJRDogODAKICAgICAgICBBdXhpbGlhcnkg R0lEcwogICAgICAgICAgICBHSUQ6IDgwCiAgICBWZXJpZmllcgogICAgICAg IEZsYXZvcjogQVVUSF9OVUxMICgwKQogICAgICAgIExlbmd0aDogMApOZXR3 b3JrIEZpbGUgU3lzdGVtLCBXUklURSBDYWxsIEZIOjB4ODEwNjAyZmMgT2Zm c2V0OjAgTGVuOjE1IFVOU1RBQkxFCiAgICBbUHJvZ3JhbSBWZXJzaW9uOiAz XQogICAgW1YzIFByb2NlZHVyZTogV1JJVEUgKDcpXQogICAgZmlsZQogICAg ICAgIGxlbmd0aDogMjgKICAgICAgICBbaGFzaDogMHg4MTA2MDJmY10KICAg ICAgICBkZWNvZGUgdHlwZSBhczogdW5rbm93bgogICAgICAgIGZpbGVoYW5k bGU6IDhCMjY5NkE5MDdCRjBFRDQwQTAwMUY4NzA1MDAwMDAwMDI5RjA0MDAw MDAwMDAwMC4uLgogICAgb2Zmc2V0OiAwCiAgICBjb3VudDogMTUKICAgIFN0 YWJsZTogVU5TVEFCTEUgKDApCiAgICBEYXRhOiA8REFUQT4KICAgICAgICBs ZW5ndGg6IDE1CiAgICAgICAgY29udGVudHM6IDxEQVRBPgogICAgICAgIGZp bGwgYnl0ZXM6IG9wYXF1ZSBkYXRhCgowMDAwICAwMCAxNSAxNyBiZiBlYiA3 YiAwMCAzMCA0OCA3YiA1MiAzNCAwOCAwMCA0NSAwMCAgIC4uLi4uey4wSHtS NC4uRS4KMDAxMCAgMDAgYjAgZjggYWQgNDAgMDAgNDAgMDYgYmIgMjcgYzAg YTggMDIgOTkgYzAgYTggICAuLi4uQC5ALi4nLi4uLi4uCjAwMjAgIDAyIDg5 IDAyIDY2IDA4IDAxIDIyIGRkIDFiIDQ2IGVlIGMzIGJlIGIyIDUwIDE4ICAg Li4uZi4uIi4uRi4uLi5QLgowMDMwICBmZiBmZiA4NyAxNSAwMCAwMCA4MCAw MCAwMCA4NCA1NyBkYiBkNCBlMyAwMCAwMCAgIC4uLi4uLi4uLi5XLi4uLi4K MDA0MCAgMDAgMDAgMDAgMDAgMDAgMDIgMDAgMDEgODYgYTMgMDAgMDAgMDAg MDMgMDAgMDAgICAuLi4uLi4uLi4uLi4uLi4uCjAwNTAgIDAwIDA3IDAwIDAw IDAwIDAxIDAwIDAwIDAwIDE4IDAwIDAwIDAwIDAwIDAwIDAwICAgLi4uLi4u Li4uLi4uLi4uLgowMDYwICAwMCAwMCAwMCAwMCAwMCA1MCAwMCAwMCAwMCA1 MCAwMCAwMCAwMCAwMSAwMCAwMCAgIC4uLi4uUC4uLlAuLi4uLi4KMDA3MCAg MDAgNTAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMWMgOGIg MjYgICAuUC4uLi4uLi4uLi4uLi4mCjAwODAgIDk2IGE5IDA3IGJmIDBlIGQ0 IDBhIDAwIDFmIDg3IDA1IDAwIDAwIDAwIDAyIDlmICAgLi4uLi4uLi4uLi4u Li4uLgowMDkwICAwNCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAgIC4uLi4uLi4uLi4uLi4uLi4KMDBhMCAgMDAgMDAg MDAgMDAgMDAgMGYgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMGYgMzggMzkgICAu Li4uLi4uLi4uLi4uLjg5CjAwYjAgIDM5IDM4IDM4IDIwIDMyIDM2IDMyIDMx IDM0IDM0IDMwIDMwIDMwIDAwICAgICAgICAgOTg4IDI2MjE0NDAwMC4KCk5v LiAgICAgVGltZSAgICAgICAgU291cmNlICAgICAgICAgICAgICAgIERlc3Rp bmF0aW9uICAgICAgICAgICBQcm90b2NvbCBJbmZvCiAgICAgIDkgMC4wMDA5 OTcgICAgMTkyLjE2OC4yLjEzNyAgICAgICAgIDE5Mi4xNjguMi4xNTMgICAg ICAgICBORlMgICAgICBWMyBXUklURSBSZXBseSAoQ2FsbCBJbiA4KSBFcnJv cjpORlMzRVJSX0lPCgpGcmFtZSA5ICg5NCBieXRlcyBvbiB3aXJlLCA5NCBi eXRlcyBjYXB0dXJlZCkKICAgIEFycml2YWwgVGltZTogSmFuIDMwLCAyMDEw IDEyOjQxOjQ2LjkxMTgyNTAwMAogICAgW1RpbWUgZGVsdGEgZnJvbSBwcmV2 aW91cyBjYXB0dXJlZCBmcmFtZTogMC4wMDAyMjEwMDAgc2Vjb25kc10KICAg IFtUaW1lIGRlbHRhIGZyb20gcHJldmlvdXMgZGlzcGxheWVkIGZyYW1lOiAw LjAwMDIyMTAwMCBzZWNvbmRzXQogICAgW1RpbWUgc2luY2UgcmVmZXJlbmNl IG9yIGZpcnN0IGZyYW1lOiAwLjAwMDk5NzAwMCBzZWNvbmRzXQogICAgRnJh bWUgTnVtYmVyOiA5CiAgICBGcmFtZSBMZW5ndGg6IDk0IGJ5dGVzCiAgICBD YXB0dXJlIExlbmd0aDogOTQgYnl0ZXMKICAgIFtGcmFtZSBpcyBtYXJrZWQ6 IEZhbHNlXQogICAgW1Byb3RvY29scyBpbiBmcmFtZTogZXRoOmlwOnRjcDpy cGNdCiAgICBbQ29sb3JpbmcgUnVsZSBOYW1lOiBUQ1BdCiAgICBbQ29sb3Jp bmcgUnVsZSBTdHJpbmc6IHRjcF0KRXRoZXJuZXQgSUksIFNyYzogSW50ZWxD b3JfYmY6ZWI6N2IgKDAwOjE1OjE3OmJmOmViOjdiKSwgRHN0OiBTdXBlcm1p Y183Yjo1MjozNCAoMDA6MzA6NDg6N2I6NTI6MzQpCiAgICBEZXN0aW5hdGlv bjogU3VwZXJtaWNfN2I6NTI6MzQgKDAwOjMwOjQ4OjdiOjUyOjM0KQogICAg ICAgIEFkZHJlc3M6IFN1cGVybWljXzdiOjUyOjM0ICgwMDozMDo0ODo3Yjo1 MjozNCkKICAgICAgICAuLi4uIC4uLjAgLi4uLiAuLi4uIC4uLi4gLi4uLiA9 IElHIGJpdDogSW5kaXZpZHVhbCBhZGRyZXNzICh1bmljYXN0KQogICAgICAg IC4uLi4gLi4wLiAuLi4uIC4uLi4gLi4uLiAuLi4uID0gTEcgYml0OiBHbG9i YWxseSB1bmlxdWUgYWRkcmVzcyAoZmFjdG9yeSBkZWZhdWx0KQogICAgU291 cmNlOiBJbnRlbENvcl9iZjplYjo3YiAoMDA6MTU6MTc6YmY6ZWI6N2IpCiAg ICAgICAgQWRkcmVzczogSW50ZWxDb3JfYmY6ZWI6N2IgKDAwOjE1OjE3OmJm OmViOjdiKQogICAgICAgIC4uLi4gLi4uMCAuLi4uIC4uLi4gLi4uLiAuLi4u ID0gSUcgYml0OiBJbmRpdmlkdWFsIGFkZHJlc3MgKHVuaWNhc3QpCiAgICAg ICAgLi4uLiAuLjAuIC4uLi4gLi4uLiAuLi4uIC4uLi4gPSBMRyBiaXQ6IEds b2JhbGx5IHVuaXF1ZSBhZGRyZXNzIChmYWN0b3J5IGRlZmF1bHQpCiAgICBU eXBlOiBJUCAoMHgwODAwKQpJbnRlcm5ldCBQcm90b2NvbCwgU3JjOiAxOTIu MTY4LjIuMTM3ICgxOTIuMTY4LjIuMTM3KSwgRHN0OiAxOTIuMTY4LjIuMTUz ICgxOTIuMTY4LjIuMTUzKQogICAgVmVyc2lvbjogNAogICAgSGVhZGVyIGxl bmd0aDogMjAgYnl0ZXMKICAgIERpZmZlcmVudGlhdGVkIFNlcnZpY2VzIEZp ZWxkOiAweDAwIChEU0NQIDB4MDA6IERlZmF1bHQ7IEVDTjogMHgwMCkKICAg ICAgICAwMDAwIDAwLi4gPSBEaWZmZXJlbnRpYXRlZCBTZXJ2aWNlcyBDb2Rl cG9pbnQ6IERlZmF1bHQgKDB4MDApCiAgICAgICAgLi4uLiAuLjAuID0gRUNO LUNhcGFibGUgVHJhbnNwb3J0IChFQ1QpOiAwCiAgICAgICAgLi4uLiAuLi4w ID0gRUNOLUNFOiAwCiAgICBUb3RhbCBMZW5ndGg6IDgwCiAgICBJZGVudGlm aWNhdGlvbjogMHhiOGQ5ICg0NzMyMSkKICAgIEZsYWdzOiAweDA0IChEb24n dCBGcmFnbWVudCkKICAgICAgICAwLi4uID0gUmVzZXJ2ZWQgYml0OiBOb3Qg c2V0CiAgICAgICAgLjEuLiA9IERvbid0IGZyYWdtZW50OiBTZXQKICAgICAg ICAuLjAuID0gTW9yZSBmcmFnbWVudHM6IE5vdCBzZXQKICAgIEZyYWdtZW50 IG9mZnNldDogMAogICAgVGltZSB0byBsaXZlOiA2NAogICAgUHJvdG9jb2w6 IFRDUCAoMHgwNikKICAgIEhlYWRlciBjaGVja3N1bTogMHhmYjViIFtjb3Jy ZWN0XQogICAgICAgIFtHb29kOiBUcnVlXQogICAgICAgIFtCYWQgOiBGYWxz ZV0KICAgIFNvdXJjZTogMTkyLjE2OC4yLjEzNyAoMTkyLjE2OC4yLjEzNykK ICAgIERlc3RpbmF0aW9uOiAxOTIuMTY4LjIuMTUzICgxOTIuMTY4LjIuMTUz KQpUcmFuc21pc3Npb24gQ29udHJvbCBQcm90b2NvbCwgU3JjIFBvcnQ6IG5m cyAoMjA0OSksIERzdCBQb3J0OiBzc2hlbGwgKDYxNCksIFNlcTogMTYxLCBB Y2s6IDU0NSwgTGVuOiA0MAogICAgU291cmNlIHBvcnQ6IG5mcyAoMjA0OSkK ICAgIERlc3RpbmF0aW9uIHBvcnQ6IHNzaGVsbCAoNjE0KQogICAgU2VxdWVu Y2UgbnVtYmVyOiAxNjEgICAgKHJlbGF0aXZlIHNlcXVlbmNlIG51bWJlcikK ICAgIFtOZXh0IHNlcXVlbmNlIG51bWJlcjogMjAxICAgIChyZWxhdGl2ZSBz ZXF1ZW5jZSBudW1iZXIpXQogICAgQWNrbm93bGVkZ2VtZW50IG51bWJlcjog NTQ1ICAgIChyZWxhdGl2ZSBhY2sgbnVtYmVyKQogICAgSGVhZGVyIGxlbmd0 aDogMjAgYnl0ZXMKICAgIEZsYWdzOiAweDE4IChQU0gsIEFDSykKICAgICAg ICAwLi4uIC4uLi4gPSBDb25nZXN0aW9uIFdpbmRvdyBSZWR1Y2VkIChDV1Ip OiBOb3Qgc2V0CiAgICAgICAgLjAuLiAuLi4uID0gRUNOLUVjaG86IE5vdCBz ZXQKICAgICAgICAuLjAuIC4uLi4gPSBVcmdlbnQ6IE5vdCBzZXQKICAgICAg ICAuLi4xIC4uLi4gPSBBY2tub3dsZWRnbWVudDogU2V0CiAgICAgICAgLi4u LiAxLi4uID0gUHVzaDogU2V0CiAgICAgICAgLi4uLiAuMC4uID0gUmVzZXQ6 IE5vdCBzZXQKICAgICAgICAuLi4uIC4uMC4gPSBTeW46IE5vdCBzZXQKICAg ICAgICAuLi4uIC4uLjAgPSBGaW46IE5vdCBzZXQKICAgIFdpbmRvdyBzaXpl OiA2NTUzNQogICAgQ2hlY2tzdW06IDB4ODViZiBbY29ycmVjdF0KICAgICAg ICBbR29vZCBDaGVja3N1bTogVHJ1ZV0KICAgICAgICBbQmFkIENoZWNrc3Vt OiBGYWxzZV0KICAgIFtTRVEvQUNLIGFuYWx5c2lzXQogICAgICAgIFtUaGlz IGlzIGFuIEFDSyB0byB0aGUgc2VnbWVudCBpbiBmcmFtZTogOF0KICAgICAg ICBbVGhlIFJUVCB0byBBQ0sgdGhlIHNlZ21lbnQgd2FzOiAwLjAwMDIyMTAw MCBzZWNvbmRzXQpSZW1vdGUgUHJvY2VkdXJlIENhbGwsIFR5cGU6UmVwbHkg WElEOjB4NTdkYmQ0ZTMKICAgIEZyYWdtZW50IGhlYWRlcjogTGFzdCBmcmFn bWVudCwgMzYgYnl0ZXMKICAgICAgICAxLi4uIC4uLi4gLi4uLiAuLi4uIC4u Li4gLi4uLiAuLi4uIC4uLi4gPSBMYXN0IEZyYWdtZW50OiBZZXMKICAgICAg ICAuMDAwIDAwMDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAwMDEwIDAxMDAgPSBG cmFnbWVudCBMZW5ndGg6IDM2CiAgICBYSUQ6IDB4NTdkYmQ0ZTMgKDE0NzQw MjQ2NzUpCiAgICBNZXNzYWdlIFR5cGU6IFJlcGx5ICgxKQogICAgW1Byb2dy YW06IE5GUyAoMTAwMDAzKV0KICAgIFtQcm9ncmFtIFZlcnNpb246IDNdCiAg ICBbUHJvY2VkdXJlOiBXUklURSAoNyldCiAgICBSZXBseSBTdGF0ZTogYWNj ZXB0ZWQgKDApCiAgICBbVGhpcyBpcyBhIHJlcGx5IHRvIGEgcmVxdWVzdCBp biBmcmFtZSA4XQogICAgW1RpbWUgZnJvbSByZXF1ZXN0OiAwLjAwMDIyMTAw MCBzZWNvbmRzXQogICAgVmVyaWZpZXIKICAgICAgICBGbGF2b3I6IEFVVEhf TlVMTCAoMCkKICAgICAgICBMZW5ndGg6IDAKICAgIEFjY2VwdCBTdGF0ZTog UlBDIGV4ZWN1dGVkIHN1Y2Nlc3NmdWxseSAoMCkKTmV0d29yayBGaWxlIFN5 c3RlbSwgV1JJVEUgUmVwbHkgIEVycm9yOk5GUzNFUlJfSU8KICAgIFtQcm9n cmFtIFZlcnNpb246IDNdCiAgICBbVjMgUHJvY2VkdXJlOiBXUklURSAoNyld CiAgICBTdGF0dXM6IE5GUzNFUlJfSU8gKDUpCiAgICBmaWxlX3djYwogICAg ICAgIGJlZm9yZQogICAgICAgICAgICBhdHRyaWJ1dGVzX2ZvbGxvdzogbm8g dmFsdWUgKDApCiAgICAgICAgYWZ0ZXIKICAgICAgICAgICAgYXR0cmlidXRl c19mb2xsb3c6IG5vIHZhbHVlICgwKQoKMDAwMCAgMDAgMzAgNDggN2IgNTIg MzQgMDAgMTUgMTcgYmYgZWIgN2IgMDggMDAgNDUgMDAgICAuMEh7UjQuLi4u LnsuLkUuCjAwMTAgIDAwIDUwIGI4IGQ5IDQwIDAwIDQwIDA2IGZiIDViIGMw IGE4IDAyIDg5IGMwIGE4ICAgLlAuLkAuQC4uWy4uLi4uLgowMDIwICAwMiA5 OSAwOCAwMSAwMiA2NiBlZSBjMyBiZSBiMiAyMiBkZCAxYiBjZSA1MCAxOCAg IC4uLi4uZi4uLi4iLi4uUC4KMDAzMCAgZmYgZmYgODUgYmYgMDAgMDAgODAg MDAgMDAgMjQgNTcgZGIgZDQgZTMgMDAgMDAgICAuLi4uLi4uLi4kVy4uLi4u CjAwNDAgIDAwIDAxIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwICAgLi4uLi4uLi4uLi4uLi4uLgowMDUwICAwMCAwMCAwMCAw MCAwMCAwNSAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAgICAgICAgIC4uLi4u Li4uLi4uLi4uCgpOby4gICAgIFRpbWUgICAgICAgIFNvdXJjZSAgICAgICAg ICAgICAgICBEZXN0aW5hdGlvbiAgICAgICAgICAgUHJvdG9jb2wgSW5mbwog ICAgIDEwIDAuMDAxMDI2ICAgIDE5Mi4xNjguMi4xNTMgICAgICAgICAxOTIu MTY4LjIuMTM3ICAgICAgICAgTkZTICAgICAgVjMgV1JJVEUgQ2FsbCAoUmVw bHkgSW4gMTEpLCBGSDoweDgxMDYwMmZjIE9mZnNldDowIExlbjoxNSBVTlNU QUJMRQoKRnJhbWUgMTAgKDE5MCBieXRlcyBvbiB3aXJlLCAxOTAgYnl0ZXMg Y2FwdHVyZWQpCiAgICBBcnJpdmFsIFRpbWU6IEphbiAzMCwgMjAxMCAxMjo0 MTo0Ni45MTE4NTQwMDAKICAgIFtUaW1lIGRlbHRhIGZyb20gcHJldmlvdXMg Y2FwdHVyZWQgZnJhbWU6IDAuMDAwMDI5MDAwIHNlY29uZHNdCiAgICBbVGlt ZSBkZWx0YSBmcm9tIHByZXZpb3VzIGRpc3BsYXllZCBmcmFtZTogMC4wMDAw MjkwMDAgc2Vjb25kc10KICAgIFtUaW1lIHNpbmNlIHJlZmVyZW5jZSBvciBm aXJzdCBmcmFtZTogMC4wMDEwMjYwMDAgc2Vjb25kc10KICAgIEZyYW1lIE51 bWJlcjogMTAKICAgIEZyYW1lIExlbmd0aDogMTkwIGJ5dGVzCiAgICBDYXB0 dXJlIExlbmd0aDogMTkwIGJ5dGVzCiAgICBbRnJhbWUgaXMgbWFya2VkOiBG YWxzZV0KICAgIFtQcm90b2NvbHMgaW4gZnJhbWU6IGV0aDppcDp0Y3A6cnBj Om5mc10KICAgIFtDb2xvcmluZyBSdWxlIE5hbWU6IENoZWNrc3VtIEVycm9y c10KICAgIFtDb2xvcmluZyBSdWxlIFN0cmluZzogY2RwLmNoZWNrc3VtX2Jh ZD09MSB8fCBlZHAuY2hlY2tzdW1fYmFkPT0xIHx8IGlwLmNoZWNrc3VtX2Jh ZD09MSB8fCB0Y3AuY2hlY2tzdW1fYmFkPT0xIHx8IHVkcC5jaGVja3N1bV9i YWQ9PTFdCkV0aGVybmV0IElJLCBTcmM6IFN1cGVybWljXzdiOjUyOjM0ICgw MDozMDo0ODo3Yjo1MjozNCksIERzdDogSW50ZWxDb3JfYmY6ZWI6N2IgKDAw OjE1OjE3OmJmOmViOjdiKQogICAgRGVzdGluYXRpb246IEludGVsQ29yX2Jm OmViOjdiICgwMDoxNToxNzpiZjplYjo3YikKICAgICAgICBBZGRyZXNzOiBJ bnRlbENvcl9iZjplYjo3YiAoMDA6MTU6MTc6YmY6ZWI6N2IpCiAgICAgICAg Li4uLiAuLi4wIC4uLi4gLi4uLiAuLi4uIC4uLi4gPSBJRyBiaXQ6IEluZGl2 aWR1YWwgYWRkcmVzcyAodW5pY2FzdCkKICAgICAgICAuLi4uIC4uMC4gLi4u LiAuLi4uIC4uLi4gLi4uLiA9IExHIGJpdDogR2xvYmFsbHkgdW5pcXVlIGFk ZHJlc3MgKGZhY3RvcnkgZGVmYXVsdCkKICAgIFNvdXJjZTogU3VwZXJtaWNf N2I6NTI6MzQgKDAwOjMwOjQ4OjdiOjUyOjM0KQogICAgICAgIEFkZHJlc3M6 IFN1cGVybWljXzdiOjUyOjM0ICgwMDozMDo0ODo3Yjo1MjozNCkKICAgICAg ICAuLi4uIC4uLjAgLi4uLiAuLi4uIC4uLi4gLi4uLiA9IElHIGJpdDogSW5k aXZpZHVhbCBhZGRyZXNzICh1bmljYXN0KQogICAgICAgIC4uLi4gLi4wLiAu Li4uIC4uLi4gLi4uLiAuLi4uID0gTEcgYml0OiBHbG9iYWxseSB1bmlxdWUg YWRkcmVzcyAoZmFjdG9yeSBkZWZhdWx0KQogICAgVHlwZTogSVAgKDB4MDgw MCkKSW50ZXJuZXQgUHJvdG9jb2wsIFNyYzogMTkyLjE2OC4yLjE1MyAoMTky LjE2OC4yLjE1MyksIERzdDogMTkyLjE2OC4yLjEzNyAoMTkyLjE2OC4yLjEz NykKICAgIFZlcnNpb246IDQKICAgIEhlYWRlciBsZW5ndGg6IDIwIGJ5dGVz CiAgICBEaWZmZXJlbnRpYXRlZCBTZXJ2aWNlcyBGaWVsZDogMHgwMCAoRFND UCAweDAwOiBEZWZhdWx0OyBFQ046IDB4MDApCiAgICAgICAgMDAwMCAwMC4u ID0gRGlmZmVyZW50aWF0ZWQgU2VydmljZXMgQ29kZXBvaW50OiBEZWZhdWx0 ICgweDAwKQogICAgICAgIC4uLi4gLi4wLiA9IEVDTi1DYXBhYmxlIFRyYW5z cG9ydCAoRUNUKTogMAogICAgICAgIC4uLi4gLi4uMCA9IEVDTi1DRTogMAog ICAgVG90YWwgTGVuZ3RoOiAxNzYKICAgIElkZW50aWZpY2F0aW9uOiAweGY4 YWUgKDYzNjYyKQogICAgRmxhZ3M6IDB4MDQgKERvbid0IEZyYWdtZW50KQog ICAgICAgIDAuLi4gPSBSZXNlcnZlZCBiaXQ6IE5vdCBzZXQKICAgICAgICAu MS4uID0gRG9uJ3QgZnJhZ21lbnQ6IFNldAogICAgICAgIC4uMC4gPSBNb3Jl IGZyYWdtZW50czogTm90IHNldAogICAgRnJhZ21lbnQgb2Zmc2V0OiAwCiAg ICBUaW1lIHRvIGxpdmU6IDY0CiAgICBQcm90b2NvbDogVENQICgweDA2KQog ICAgSGVhZGVyIGNoZWNrc3VtOiAweGJiMjYgW2NvcnJlY3RdCiAgICAgICAg W0dvb2Q6IFRydWVdCiAgICAgICAgW0JhZCA6IEZhbHNlXQogICAgU291cmNl OiAxOTIuMTY4LjIuMTUzICgxOTIuMTY4LjIuMTUzKQogICAgRGVzdGluYXRp b246IDE5Mi4xNjguMi4xMzcgKDE5Mi4xNjguMi4xMzcpClRyYW5zbWlzc2lv biBDb250cm9sIFByb3RvY29sLCBTcmMgUG9ydDogc3NoZWxsICg2MTQpLCBE c3QgUG9ydDogbmZzICgyMDQ5KSwgU2VxOiA1NDUsIEFjazogMjAxLCBMZW46 IDEzNgogICAgU291cmNlIHBvcnQ6IHNzaGVsbCAoNjE0KQogICAgRGVzdGlu YXRpb24gcG9ydDogbmZzICgyMDQ5KQogICAgU2VxdWVuY2UgbnVtYmVyOiA1 NDUgICAgKHJlbGF0aXZlIHNlcXVlbmNlIG51bWJlcikKICAgIFtOZXh0IHNl cXVlbmNlIG51bWJlcjogNjgxICAgIChyZWxhdGl2ZSBzZXF1ZW5jZSBudW1i ZXIpXQogICAgQWNrbm93bGVkZ2VtZW50IG51bWJlcjogMjAxICAgIChyZWxh dGl2ZSBhY2sgbnVtYmVyKQogICAgSGVhZGVyIGxlbmd0aDogMjAgYnl0ZXMK ICAgIEZsYWdzOiAweDE4IChQU0gsIEFDSykKICAgICAgICAwLi4uIC4uLi4g PSBDb25nZXN0aW9uIFdpbmRvdyBSZWR1Y2VkIChDV1IpOiBOb3Qgc2V0CiAg ICAgICAgLjAuLiAuLi4uID0gRUNOLUVjaG86IE5vdCBzZXQKICAgICAgICAu LjAuIC4uLi4gPSBVcmdlbnQ6IE5vdCBzZXQKICAgICAgICAuLi4xIC4uLi4g PSBBY2tub3dsZWRnbWVudDogU2V0CiAgICAgICAgLi4uLiAxLi4uID0gUHVz aDogU2V0CiAgICAgICAgLi4uLiAuMC4uID0gUmVzZXQ6IE5vdCBzZXQKICAg ICAgICAuLi4uIC4uMC4gPSBTeW46IE5vdCBzZXQKICAgICAgICAuLi4uIC4u LjAgPSBGaW46IE5vdCBzZXQKICAgIFdpbmRvdyBzaXplOiA2NTUzNQogICAg Q2hlY2tzdW06IDB4ODcxNSBbaW5jb3JyZWN0LCBzaG91bGQgYmUgMHhlZDAw IChtYXliZSBjYXVzZWQgYnkgIlRDUCBjaGVja3N1bSBvZmZsb2FkIj8pXQog ICAgICAgIFtHb29kIENoZWNrc3VtOiBGYWxzZV0KICAgICAgICBbQmFkIENo ZWNrc3VtOiBUcnVlXQogICAgW1NFUS9BQ0sgYW5hbHlzaXNdCiAgICAgICAg W1RoaXMgaXMgYW4gQUNLIHRvIHRoZSBzZWdtZW50IGluIGZyYW1lOiA5XQog ICAgICAgIFtUaGUgUlRUIHRvIEFDSyB0aGUgc2VnbWVudCB3YXM6IDAuMDAw MDI5MDAwIHNlY29uZHNdClJlbW90ZSBQcm9jZWR1cmUgQ2FsbCwgVHlwZTpD YWxsIFhJRDoweDU3ZGJkNGU0CiAgICBGcmFnbWVudCBoZWFkZXI6IExhc3Qg ZnJhZ21lbnQsIDEzMiBieXRlcwogICAgICAgIDEuLi4gLi4uLiAuLi4uIC4u Li4gLi4uLiAuLi4uIC4uLi4gLi4uLiA9IExhc3QgRnJhZ21lbnQ6IFllcwog ICAgICAgIC4wMDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAwMDAwIDEwMDAgMDEw MCA9IEZyYWdtZW50IExlbmd0aDogMTMyCiAgICBYSUQ6IDB4NTdkYmQ0ZTQg KDE0NzQwMjQ2NzYpCiAgICBNZXNzYWdlIFR5cGU6IENhbGwgKDApCiAgICBS UEMgVmVyc2lvbjogMgogICAgUHJvZ3JhbTogTkZTICgxMDAwMDMpCiAgICBQ cm9ncmFtIFZlcnNpb246IDMKICAgIFByb2NlZHVyZTogV1JJVEUgKDcpCiAg ICBbVGhlIHJlcGx5IHRvIHRoaXMgcmVxdWVzdCBpcyBpbiBmcmFtZSAxMV0K ICAgIENyZWRlbnRpYWxzCiAgICAgICAgRmxhdm9yOiBBVVRIX1VOSVggKDEp CiAgICAgICAgTGVuZ3RoOiAyNAogICAgICAgIFN0YW1wOiAweDAwMDAwMDAw CiAgICAgICAgTWFjaGluZSBOYW1lOiA8RU1QVFk+CiAgICAgICAgICAgIGxl bmd0aDogMAogICAgICAgICAgICBjb250ZW50czogPEVNUFRZPgogICAgICAg IFVJRDogODAKICAgICAgICBHSUQ6IDgwCiAgICAgICAgQXV4aWxpYXJ5IEdJ RHMKICAgICAgICAgICAgR0lEOiA4MAogICAgVmVyaWZpZXIKICAgICAgICBG bGF2b3I6IEFVVEhfTlVMTCAoMCkKICAgICAgICBMZW5ndGg6IDAKTmV0d29y ayBGaWxlIFN5c3RlbSwgV1JJVEUgQ2FsbCBGSDoweDgxMDYwMmZjIE9mZnNl dDowIExlbjoxNSBVTlNUQUJMRQogICAgW1Byb2dyYW0gVmVyc2lvbjogM10K ICAgIFtWMyBQcm9jZWR1cmU6IFdSSVRFICg3KV0KICAgIGZpbGUKICAgICAg ICBsZW5ndGg6IDI4CiAgICAgICAgW2hhc2g6IDB4ODEwNjAyZmNdCiAgICAg ICAgZGVjb2RlIHR5cGUgYXM6IHVua25vd24KICAgICAgICBmaWxlaGFuZGxl OiA4QjI2OTZBOTA3QkYwRUQ0MEEwMDFGODcwNTAwMDAwMDAyOUYwNDAwMDAw MDAwMDAuLi4KICAgIG9mZnNldDogMAogICAgY291bnQ6IDE1CiAgICBTdGFi bGU6IFVOU1RBQkxFICgwKQogICAgRGF0YTogPERBVEE+CiAgICAgICAgbGVu Z3RoOiAxNQogICAgICAgIGNvbnRlbnRzOiA8REFUQT4KICAgICAgICBmaWxs IGJ5dGVzOiBvcGFxdWUgZGF0YQoKMDAwMCAgMDAgMTUgMTcgYmYgZWIgN2Ig MDAgMzAgNDggN2IgNTIgMzQgMDggMDAgNDUgMDAgICAuLi4uLnsuMEh7UjQu LkUuCjAwMTAgIDAwIGIwIGY4IGFlIDQwIDAwIDQwIDA2IGJiIDI2IGMwIGE4 IDAyIDk5IGMwIGE4ICAgLi4uLkAuQC4uJi4uLi4uLgowMDIwICAwMiA4OSAw MiA2NiAwOCAwMSAyMiBkZCAxYiBjZSBlZSBjMyBiZSBkYSA1MCAxOCAgIC4u LmYuLiIuLi4uLi4uUC4KMDAzMCAgZmYgZmYgODcgMTUgMDAgMDAgODAgMDAg MDAgODQgNTcgZGIgZDQgZTQgMDAgMDAgICAuLi4uLi4uLi4uVy4uLi4uCjAw NDAgIDAwIDAwIDAwIDAwIDAwIDAyIDAwIDAxIDg2IGEzIDAwIDAwIDAwIDAz IDAwIDAwICAgLi4uLi4uLi4uLi4uLi4uLgowMDUwICAwMCAwNyAwMCAwMCAw MCAwMSAwMCAwMCAwMCAxOCAwMCAwMCAwMCAwMCAwMCAwMCAgIC4uLi4uLi4u Li4uLi4uLi4KMDA2MCAgMDAgMDAgMDAgMDAgMDAgNTAgMDAgMDAgMDAgNTAg MDAgMDAgMDAgMDEgMDAgMDAgICAuLi4uLlAuLi5QLi4uLi4uCjAwNzAgIDAw IDUwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDFjIDhiIDI2 ICAgLlAuLi4uLi4uLi4uLi4uJgowMDgwICA5NiBhOSAwNyBiZiAwZSBkNCAw YSAwMCAxZiA4NyAwNSAwMCAwMCAwMCAwMiA5ZiAgIC4uLi4uLi4uLi4uLi4u Li4KMDA5MCAgMDQgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgICAuLi4uLi4uLi4uLi4uLi4uCjAwYTAgIDAwIDAwIDAw IDAwIDAwIDBmIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDBmIDM4IDM5ICAgLi4u Li4uLi4uLi4uLi44OQowMGIwICAzOSAzOCAzOCAyMCAzMiAzNiAzMiAzMSAz NCAzNCAzMCAzMCAzMCAwMCAgICAgICAgIDk4OCAyNjIxNDQwMDAuCgpOby4g ICAgIFRpbWUgICAgICAgIFNvdXJjZSAgICAgICAgICAgICAgICBEZXN0aW5h dGlvbiAgICAgICAgICAgUHJvdG9jb2wgSW5mbwogICAgIDExIDAuMDAxMjQ3 ICAgIDE5Mi4xNjguMi4xMzcgICAgICAgICAxOTIuMTY4LjIuMTUzICAgICAg ICAgTkZTICAgICAgVjMgV1JJVEUgUmVwbHkgKENhbGwgSW4gMTApIEVycm9y Ok5GUzNFUlJfSU8KCkZyYW1lIDExICg5NCBieXRlcyBvbiB3aXJlLCA5NCBi eXRlcyBjYXB0dXJlZCkKICAgIEFycml2YWwgVGltZTogSmFuIDMwLCAyMDEw IDEyOjQxOjQ2LjkxMjA3NTAwMAogICAgW1RpbWUgZGVsdGEgZnJvbSBwcmV2 aW91cyBjYXB0dXJlZCBmcmFtZTogMC4wMDAyMjEwMDAgc2Vjb25kc10KICAg IFtUaW1lIGRlbHRhIGZyb20gcHJldmlvdXMgZGlzcGxheWVkIGZyYW1lOiAw LjAwMDIyMTAwMCBzZWNvbmRzXQogICAgW1RpbWUgc2luY2UgcmVmZXJlbmNl IG9yIGZpcnN0IGZyYW1lOiAwLjAwMTI0NzAwMCBzZWNvbmRzXQogICAgRnJh bWUgTnVtYmVyOiAxMQogICAgRnJhbWUgTGVuZ3RoOiA5NCBieXRlcwogICAg Q2FwdHVyZSBMZW5ndGg6IDk0IGJ5dGVzCiAgICBbRnJhbWUgaXMgbWFya2Vk OiBGYWxzZV0KICAgIFtQcm90b2NvbHMgaW4gZnJhbWU6IGV0aDppcDp0Y3A6 cnBjXQogICAgW0NvbG9yaW5nIFJ1bGUgTmFtZTogVENQXQogICAgW0NvbG9y aW5nIFJ1bGUgU3RyaW5nOiB0Y3BdCkV0aGVybmV0IElJLCBTcmM6IEludGVs Q29yX2JmOmViOjdiICgwMDoxNToxNzpiZjplYjo3YiksIERzdDogU3VwZXJt aWNfN2I6NTI6MzQgKDAwOjMwOjQ4OjdiOjUyOjM0KQogICAgRGVzdGluYXRp b246IFN1cGVybWljXzdiOjUyOjM0ICgwMDozMDo0ODo3Yjo1MjozNCkKICAg ICAgICBBZGRyZXNzOiBTdXBlcm1pY183Yjo1MjozNCAoMDA6MzA6NDg6N2I6 NTI6MzQpCiAgICAgICAgLi4uLiAuLi4wIC4uLi4gLi4uLiAuLi4uIC4uLi4g PSBJRyBiaXQ6IEluZGl2aWR1YWwgYWRkcmVzcyAodW5pY2FzdCkKICAgICAg ICAuLi4uIC4uMC4gLi4uLiAuLi4uIC4uLi4gLi4uLiA9IExHIGJpdDogR2xv YmFsbHkgdW5pcXVlIGFkZHJlc3MgKGZhY3RvcnkgZGVmYXVsdCkKICAgIFNv dXJjZTogSW50ZWxDb3JfYmY6ZWI6N2IgKDAwOjE1OjE3OmJmOmViOjdiKQog ICAgICAgIEFkZHJlc3M6IEludGVsQ29yX2JmOmViOjdiICgwMDoxNToxNzpi ZjplYjo3YikKICAgICAgICAuLi4uIC4uLjAgLi4uLiAuLi4uIC4uLi4gLi4u LiA9IElHIGJpdDogSW5kaXZpZHVhbCBhZGRyZXNzICh1bmljYXN0KQogICAg ICAgIC4uLi4gLi4wLiAuLi4uIC4uLi4gLi4uLiAuLi4uID0gTEcgYml0OiBH bG9iYWxseSB1bmlxdWUgYWRkcmVzcyAoZmFjdG9yeSBkZWZhdWx0KQogICAg VHlwZTogSVAgKDB4MDgwMCkKSW50ZXJuZXQgUHJvdG9jb2wsIFNyYzogMTky LjE2OC4yLjEzNyAoMTkyLjE2OC4yLjEzNyksIERzdDogMTkyLjE2OC4yLjE1 MyAoMTkyLjE2OC4yLjE1MykKICAgIFZlcnNpb246IDQKICAgIEhlYWRlciBs ZW5ndGg6IDIwIGJ5dGVzCiAgICBEaWZmZXJlbnRpYXRlZCBTZXJ2aWNlcyBG aWVsZDogMHgwMCAoRFNDUCAweDAwOiBEZWZhdWx0OyBFQ046IDB4MDApCiAg ICAgICAgMDAwMCAwMC4uID0gRGlmZmVyZW50aWF0ZWQgU2VydmljZXMgQ29k ZXBvaW50OiBEZWZhdWx0ICgweDAwKQogICAgICAgIC4uLi4gLi4wLiA9IEVD Ti1DYXBhYmxlIFRyYW5zcG9ydCAoRUNUKTogMAogICAgICAgIC4uLi4gLi4u MCA9IEVDTi1DRTogMAogICAgVG90YWwgTGVuZ3RoOiA4MAogICAgSWRlbnRp ZmljYXRpb246IDB4YjhkYSAoNDczMjIpCiAgICBGbGFnczogMHgwNCAoRG9u J3QgRnJhZ21lbnQpCiAgICAgICAgMC4uLiA9IFJlc2VydmVkIGJpdDogTm90 IHNldAogICAgICAgIC4xLi4gPSBEb24ndCBmcmFnbWVudDogU2V0CiAgICAg ICAgLi4wLiA9IE1vcmUgZnJhZ21lbnRzOiBOb3Qgc2V0CiAgICBGcmFnbWVu dCBvZmZzZXQ6IDAKICAgIFRpbWUgdG8gbGl2ZTogNjQKICAgIFByb3RvY29s OiBUQ1AgKDB4MDYpCiAgICBIZWFkZXIgY2hlY2tzdW06IDB4ZmI1YSBbY29y cmVjdF0KICAgICAgICBbR29vZDogVHJ1ZV0KICAgICAgICBbQmFkIDogRmFs c2VdCiAgICBTb3VyY2U6IDE5Mi4xNjguMi4xMzcgKDE5Mi4xNjguMi4xMzcp CiAgICBEZXN0aW5hdGlvbjogMTkyLjE2OC4yLjE1MyAoMTkyLjE2OC4yLjE1 MykKVHJhbnNtaXNzaW9uIENvbnRyb2wgUHJvdG9jb2wsIFNyYyBQb3J0OiBu ZnMgKDIwNDkpLCBEc3QgUG9ydDogc3NoZWxsICg2MTQpLCBTZXE6IDIwMSwg QWNrOiA2ODEsIExlbjogNDAKICAgIFNvdXJjZSBwb3J0OiBuZnMgKDIwNDkp CiAgICBEZXN0aW5hdGlvbiBwb3J0OiBzc2hlbGwgKDYxNCkKICAgIFNlcXVl bmNlIG51bWJlcjogMjAxICAgIChyZWxhdGl2ZSBzZXF1ZW5jZSBudW1iZXIp CiAgICBbTmV4dCBzZXF1ZW5jZSBudW1iZXI6IDI0MSAgICAocmVsYXRpdmUg c2VxdWVuY2UgbnVtYmVyKV0KICAgIEFja25vd2xlZGdlbWVudCBudW1iZXI6 IDY4MSAgICAocmVsYXRpdmUgYWNrIG51bWJlcikKICAgIEhlYWRlciBsZW5n dGg6IDIwIGJ5dGVzCiAgICBGbGFnczogMHgxOCAoUFNILCBBQ0spCiAgICAg ICAgMC4uLiAuLi4uID0gQ29uZ2VzdGlvbiBXaW5kb3cgUmVkdWNlZCAoQ1dS KTogTm90IHNldAogICAgICAgIC4wLi4gLi4uLiA9IEVDTi1FY2hvOiBOb3Qg c2V0CiAgICAgICAgLi4wLiAuLi4uID0gVXJnZW50OiBOb3Qgc2V0CiAgICAg ICAgLi4uMSAuLi4uID0gQWNrbm93bGVkZ21lbnQ6IFNldAogICAgICAgIC4u Li4gMS4uLiA9IFB1c2g6IFNldAogICAgICAgIC4uLi4gLjAuLiA9IFJlc2V0 OiBOb3Qgc2V0CiAgICAgICAgLi4uLiAuLjAuID0gU3luOiBOb3Qgc2V0CiAg ICAgICAgLi4uLiAuLi4wID0gRmluOiBOb3Qgc2V0CiAgICBXaW5kb3cgc2l6 ZTogNjU1MzUKICAgIENoZWNrc3VtOiAweDg1MGUgW2NvcnJlY3RdCiAgICAg ICAgW0dvb2QgQ2hlY2tzdW06IFRydWVdCiAgICAgICAgW0JhZCBDaGVja3N1 bTogRmFsc2VdCiAgICBbU0VRL0FDSyBhbmFseXNpc10KICAgICAgICBbVGhp cyBpcyBhbiBBQ0sgdG8gdGhlIHNlZ21lbnQgaW4gZnJhbWU6IDEwXQogICAg ICAgIFtUaGUgUlRUIHRvIEFDSyB0aGUgc2VnbWVudCB3YXM6IDAuMDAwMjIx MDAwIHNlY29uZHNdClJlbW90ZSBQcm9jZWR1cmUgQ2FsbCwgVHlwZTpSZXBs eSBYSUQ6MHg1N2RiZDRlNAogICAgRnJhZ21lbnQgaGVhZGVyOiBMYXN0IGZy YWdtZW50LCAzNiBieXRlcwogICAgICAgIDEuLi4gLi4uLiAuLi4uIC4uLi4g Li4uLiAuLi4uIC4uLi4gLi4uLiA9IExhc3QgRnJhZ21lbnQ6IFllcwogICAg ICAgIC4wMDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAwMDAwIDAwMTAgMDEwMCA9 IEZyYWdtZW50IExlbmd0aDogMzYKICAgIFhJRDogMHg1N2RiZDRlNCAoMTQ3 NDAyNDY3NikKICAgIE1lc3NhZ2UgVHlwZTogUmVwbHkgKDEpCiAgICBbUHJv Z3JhbTogTkZTICgxMDAwMDMpXQogICAgW1Byb2dyYW0gVmVyc2lvbjogM10K ICAgIFtQcm9jZWR1cmU6IFdSSVRFICg3KV0KICAgIFJlcGx5IFN0YXRlOiBh Y2NlcHRlZCAoMCkKICAgIFtUaGlzIGlzIGEgcmVwbHkgdG8gYSByZXF1ZXN0 IGluIGZyYW1lIDEwXQogICAgW1RpbWUgZnJvbSByZXF1ZXN0OiAwLjAwMDIy MTAwMCBzZWNvbmRzXQogICAgVmVyaWZpZXIKICAgICAgICBGbGF2b3I6IEFV VEhfTlVMTCAoMCkKICAgICAgICBMZW5ndGg6IDAKICAgIEFjY2VwdCBTdGF0 ZTogUlBDIGV4ZWN1dGVkIHN1Y2Nlc3NmdWxseSAoMCkKTmV0d29yayBGaWxl IFN5c3RlbSwgV1JJVEUgUmVwbHkgIEVycm9yOk5GUzNFUlJfSU8KICAgIFtQ cm9ncmFtIFZlcnNpb246IDNdCiAgICBbVjMgUHJvY2VkdXJlOiBXUklURSAo NyldCiAgICBTdGF0dXM6IE5GUzNFUlJfSU8gKDUpCiAgICBmaWxlX3djYwog ICAgICAgIGJlZm9yZQogICAgICAgICAgICBhdHRyaWJ1dGVzX2ZvbGxvdzog bm8gdmFsdWUgKDApCiAgICAgICAgYWZ0ZXIKICAgICAgICAgICAgYXR0cmli dXRlc19mb2xsb3c6IG5vIHZhbHVlICgwKQoKMDAwMCAgMDAgMzAgNDggN2Ig NTIgMzQgMDAgMTUgMTcgYmYgZWIgN2IgMDggMDAgNDUgMDAgICAuMEh7UjQu Li4uLnsuLkUuCjAwMTAgIDAwIDUwIGI4IGRhIDQwIDAwIDQwIDA2IGZiIDVh IGMwIGE4IDAyIDg5IGMwIGE4ICAgLlAuLkAuQC4uWi4uLi4uLgowMDIwICAw MiA5OSAwOCAwMSAwMiA2NiBlZSBjMyBiZSBkYSAyMiBkZCAxYyA1NiA1MCAx OCAgIC4uLi4uZi4uLi4iLi5WUC4KMDAzMCAgZmYgZmYgODUgMGUgMDAgMDAg ODAgMDAgMDAgMjQgNTcgZGIgZDQgZTQgMDAgMDAgICAuLi4uLi4uLi4kVy4u Li4uCjAwNDAgIDAwIDAxIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwICAgLi4uLi4uLi4uLi4uLi4uLgowMDUwICAwMCAwMCAw MCAwMCAwMCAwNSAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAgICAgICAgIC4u Li4uLi4uLi4uLi4uCgpOby4gICAgIFRpbWUgICAgICAgIFNvdXJjZSAgICAg ICAgICAgICAgICBEZXN0aW5hdGlvbiAgICAgICAgICAgUHJvdG9jb2wgSW5m bwogICAgIDEyIDAuMDAxMjc2ICAgIDE5Mi4xNjguMi4xNTMgICAgICAgICAx OTIuMTY4LjIuMTM3ICAgICAgICAgTkZTICAgICAgVjMgV1JJVEUgQ2FsbCAo UmVwbHkgSW4gMTMpLCBGSDoweDgxMDYwMmZjIE9mZnNldDowIExlbjoxNSBV TlNUQUJMRQoKRnJhbWUgMTIgKDE5MCBieXRlcyBvbiB3aXJlLCAxOTAgYnl0 ZXMgY2FwdHVyZWQpCiAgICBBcnJpdmFsIFRpbWU6IEphbiAzMCwgMjAxMCAx Mjo0MTo0Ni45MTIxMDQwMDAKICAgIFtUaW1lIGRlbHRhIGZyb20gcHJldmlv dXMgY2FwdHVyZWQgZnJhbWU6IDAuMDAwMDI5MDAwIHNlY29uZHNdCiAgICBb VGltZSBkZWx0YSBmcm9tIHByZXZpb3VzIGRpc3BsYXllZCBmcmFtZTogMC4w MDAwMjkwMDAgc2Vjb25kc10KICAgIFtUaW1lIHNpbmNlIHJlZmVyZW5jZSBv ciBmaXJzdCBmcmFtZTogMC4wMDEyNzYwMDAgc2Vjb25kc10KICAgIEZyYW1l IE51bWJlcjogMTIKICAgIEZyYW1lIExlbmd0aDogMTkwIGJ5dGVzCiAgICBD YXB0dXJlIExlbmd0aDogMTkwIGJ5dGVzCiAgICBbRnJhbWUgaXMgbWFya2Vk OiBGYWxzZV0KICAgIFtQcm90b2NvbHMgaW4gZnJhbWU6IGV0aDppcDp0Y3A6 cnBjOm5mc10KICAgIFtDb2xvcmluZyBSdWxlIE5hbWU6IENoZWNrc3VtIEVy cm9yc10KICAgIFtDb2xvcmluZyBSdWxlIFN0cmluZzogY2RwLmNoZWNrc3Vt X2JhZD09MSB8fCBlZHAuY2hlY2tzdW1fYmFkPT0xIHx8IGlwLmNoZWNrc3Vt X2JhZD09MSB8fCB0Y3AuY2hlY2tzdW1fYmFkPT0xIHx8IHVkcC5jaGVja3N1 bV9iYWQ9PTFdCkV0aGVybmV0IElJLCBTcmM6IFN1cGVybWljXzdiOjUyOjM0 ICgwMDozMDo0ODo3Yjo1MjozNCksIERzdDogSW50ZWxDb3JfYmY6ZWI6N2Ig KDAwOjE1OjE3OmJmOmViOjdiKQogICAgRGVzdGluYXRpb246IEludGVsQ29y X2JmOmViOjdiICgwMDoxNToxNzpiZjplYjo3YikKICAgICAgICBBZGRyZXNz OiBJbnRlbENvcl9iZjplYjo3YiAoMDA6MTU6MTc6YmY6ZWI6N2IpCiAgICAg ICAgLi4uLiAuLi4wIC4uLi4gLi4uLiAuLi4uIC4uLi4gPSBJRyBiaXQ6IElu ZGl2aWR1YWwgYWRkcmVzcyAodW5pY2FzdCkKICAgICAgICAuLi4uIC4uMC4g Li4uLiAuLi4uIC4uLi4gLi4uLiA9IExHIGJpdDogR2xvYmFsbHkgdW5pcXVl IGFkZHJlc3MgKGZhY3RvcnkgZGVmYXVsdCkKICAgIFNvdXJjZTogU3VwZXJt aWNfN2I6NTI6MzQgKDAwOjMwOjQ4OjdiOjUyOjM0KQogICAgICAgIEFkZHJl c3M6IFN1cGVybWljXzdiOjUyOjM0ICgwMDozMDo0ODo3Yjo1MjozNCkKICAg ICAgICAuLi4uIC4uLjAgLi4uLiAuLi4uIC4uLi4gLi4uLiA9IElHIGJpdDog SW5kaXZpZHVhbCBhZGRyZXNzICh1bmljYXN0KQogICAgICAgIC4uLi4gLi4w LiAuLi4uIC4uLi4gLi4uLiAuLi4uID0gTEcgYml0OiBHbG9iYWxseSB1bmlx dWUgYWRkcmVzcyAoZmFjdG9yeSBkZWZhdWx0KQogICAgVHlwZTogSVAgKDB4 MDgwMCkKSW50ZXJuZXQgUHJvdG9jb2wsIFNyYzogMTkyLjE2OC4yLjE1MyAo MTkyLjE2OC4yLjE1MyksIERzdDogMTkyLjE2OC4yLjEzNyAoMTkyLjE2OC4y LjEzNykKICAgIFZlcnNpb246IDQKICAgIEhlYWRlciBsZW5ndGg6IDIwIGJ5 dGVzCiAgICBEaWZmZXJlbnRpYXRlZCBTZXJ2aWNlcyBGaWVsZDogMHgwMCAo RFNDUCAweDAwOiBEZWZhdWx0OyBFQ046IDB4MDApCiAgICAgICAgMDAwMCAw MC4uID0gRGlmZmVyZW50aWF0ZWQgU2VydmljZXMgQ29kZXBvaW50OiBEZWZh dWx0ICgweDAwKQogICAgICAgIC4uLi4gLi4wLiA9IEVDTi1DYXBhYmxlIFRy YW5zcG9ydCAoRUNUKTogMAogICAgICAgIC4uLi4gLi4uMCA9IEVDTi1DRTog MAogICAgVG90YWwgTGVuZ3RoOiAxNzYKICAgIElkZW50aWZpY2F0aW9uOiAw eGY4YWYgKDYzNjYzKQogICAgRmxhZ3M6IDB4MDQgKERvbid0IEZyYWdtZW50 KQogICAgICAgIDAuLi4gPSBSZXNlcnZlZCBiaXQ6IE5vdCBzZXQKICAgICAg ICAuMS4uID0gRG9uJ3QgZnJhZ21lbnQ6IFNldAogICAgICAgIC4uMC4gPSBN b3JlIGZyYWdtZW50czogTm90IHNldAogICAgRnJhZ21lbnQgb2Zmc2V0OiAw CiAgICBUaW1lIHRvIGxpdmU6IDY0CiAgICBQcm90b2NvbDogVENQICgweDA2 KQogICAgSGVhZGVyIGNoZWNrc3VtOiAweGJiMjUgW2NvcnJlY3RdCiAgICAg ICAgW0dvb2Q6IFRydWVdCiAgICAgICAgW0JhZCA6IEZhbHNlXQogICAgU291 cmNlOiAxOTIuMTY4LjIuMTUzICgxOTIuMTY4LjIuMTUzKQogICAgRGVzdGlu YXRpb246IDE5Mi4xNjguMi4xMzcgKDE5Mi4xNjguMi4xMzcpClRyYW5zbWlz c2lvbiBDb250cm9sIFByb3RvY29sLCBTcmMgUG9ydDogc3NoZWxsICg2MTQp LCBEc3QgUG9ydDogbmZzICgyMDQ5KSwgU2VxOiA2ODEsIEFjazogMjQxLCBM ZW46IDEzNgogICAgU291cmNlIHBvcnQ6IHNzaGVsbCAoNjE0KQogICAgRGVz dGluYXRpb24gcG9ydDogbmZzICgyMDQ5KQogICAgU2VxdWVuY2UgbnVtYmVy OiA2ODEgICAgKHJlbGF0aXZlIHNlcXVlbmNlIG51bWJlcikKICAgIFtOZXh0 IHNlcXVlbmNlIG51bWJlcjogODE3ICAgIChyZWxhdGl2ZSBzZXF1ZW5jZSBu dW1iZXIpXQogICAgQWNrbm93bGVkZ2VtZW50IG51bWJlcjogMjQxICAgIChy ZWxhdGl2ZSBhY2sgbnVtYmVyKQogICAgSGVhZGVyIGxlbmd0aDogMjAgYnl0 ZXMKICAgIEZsYWdzOiAweDE4IChQU0gsIEFDSykKICAgICAgICAwLi4uIC4u Li4gPSBDb25nZXN0aW9uIFdpbmRvdyBSZWR1Y2VkIChDV1IpOiBOb3Qgc2V0 CiAgICAgICAgLjAuLiAuLi4uID0gRUNOLUVjaG86IE5vdCBzZXQKICAgICAg ICAuLjAuIC4uLi4gPSBVcmdlbnQ6IE5vdCBzZXQKICAgICAgICAuLi4xIC4u Li4gPSBBY2tub3dsZWRnbWVudDogU2V0CiAgICAgICAgLi4uLiAxLi4uID0g UHVzaDogU2V0CiAgICAgICAgLi4uLiAuMC4uID0gUmVzZXQ6IE5vdCBzZXQK ICAgICAgICAuLi4uIC4uMC4gPSBTeW46IE5vdCBzZXQKICAgICAgICAuLi4u IC4uLjAgPSBGaW46IE5vdCBzZXQKICAgIFdpbmRvdyBzaXplOiA2NTUzNQog ICAgQ2hlY2tzdW06IDB4ODcxNSBbaW5jb3JyZWN0LCBzaG91bGQgYmUgMHhl YzRmIChtYXliZSBjYXVzZWQgYnkgIlRDUCBjaGVja3N1bSBvZmZsb2FkIj8p XQogICAgICAgIFtHb29kIENoZWNrc3VtOiBGYWxzZV0KICAgICAgICBbQmFk IENoZWNrc3VtOiBUcnVlXQogICAgW1NFUS9BQ0sgYW5hbHlzaXNdCiAgICAg ICAgW1RoaXMgaXMgYW4gQUNLIHRvIHRoZSBzZWdtZW50IGluIGZyYW1lOiAx MV0KICAgICAgICBbVGhlIFJUVCB0byBBQ0sgdGhlIHNlZ21lbnQgd2FzOiAw LjAwMDAyOTAwMCBzZWNvbmRzXQpSZW1vdGUgUHJvY2VkdXJlIENhbGwsIFR5 cGU6Q2FsbCBYSUQ6MHg1N2RiZDRlNQogICAgRnJhZ21lbnQgaGVhZGVyOiBM YXN0IGZyYWdtZW50LCAxMzIgYnl0ZXMKICAgICAgICAxLi4uIC4uLi4gLi4u LiAuLi4uIC4uLi4gLi4uLiAuLi4uIC4uLi4gPSBMYXN0IEZyYWdtZW50OiBZ ZXMKICAgICAgICAuMDAwIDAwMDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAxMDAw IDAxMDAgPSBGcmFnbWVudCBMZW5ndGg6IDEzMgogICAgWElEOiAweDU3ZGJk NGU1ICgxNDc0MDI0Njc3KQogICAgTWVzc2FnZSBUeXBlOiBDYWxsICgwKQog ICAgUlBDIFZlcnNpb246IDIKICAgIFByb2dyYW06IE5GUyAoMTAwMDAzKQog ICAgUHJvZ3JhbSBWZXJzaW9uOiAzCiAgICBQcm9jZWR1cmU6IFdSSVRFICg3 KQogICAgW1RoZSByZXBseSB0byB0aGlzIHJlcXVlc3QgaXMgaW4gZnJhbWUg MTNdCiAgICBDcmVkZW50aWFscwogICAgICAgIEZsYXZvcjogQVVUSF9VTklY ICgxKQogICAgICAgIExlbmd0aDogMjQKICAgICAgICBTdGFtcDogMHgwMDAw MDAwMAogICAgICAgIE1hY2hpbmUgTmFtZTogPEVNUFRZPgogICAgICAgICAg ICBsZW5ndGg6IDAKICAgICAgICAgICAgY29udGVudHM6IDxFTVBUWT4KICAg ICAgICBVSUQ6IDgwCiAgICAgICAgR0lEOiA4MAogICAgICAgIEF1eGlsaWFy eSBHSURzCiAgICAgICAgICAgIEdJRDogODAKICAgIFZlcmlmaWVyCiAgICAg ICAgRmxhdm9yOiBBVVRIX05VTEwgKDApCiAgICAgICAgTGVuZ3RoOiAwCk5l dHdvcmsgRmlsZSBTeXN0ZW0sIFdSSVRFIENhbGwgRkg6MHg4MTA2MDJmYyBP ZmZzZXQ6MCBMZW46MTUgVU5TVEFCTEUKICAgIFtQcm9ncmFtIFZlcnNpb246 IDNdCiAgICBbVjMgUHJvY2VkdXJlOiBXUklURSAoNyldCiAgICBmaWxlCiAg ICAgICAgbGVuZ3RoOiAyOAogICAgICAgIFtoYXNoOiAweDgxMDYwMmZjXQog ICAgICAgIGRlY29kZSB0eXBlIGFzOiB1bmtub3duCiAgICAgICAgZmlsZWhh bmRsZTogOEIyNjk2QTkwN0JGMEVENDBBMDAxRjg3MDUwMDAwMDAwMjlGMDQw MDAwMDAwMDAwLi4uCiAgICBvZmZzZXQ6IDAKICAgIGNvdW50OiAxNQogICAg U3RhYmxlOiBVTlNUQUJMRSAoMCkKICAgIERhdGE6IDxEQVRBPgogICAgICAg IGxlbmd0aDogMTUKICAgICAgICBjb250ZW50czogPERBVEE+CiAgICAgICAg ZmlsbCBieXRlczogb3BhcXVlIGRhdGEKCjAwMDAgIDAwIDE1IDE3IGJmIGVi IDdiIDAwIDMwIDQ4IDdiIDUyIDM0IDA4IDAwIDQ1IDAwICAgLi4uLi57LjBI e1I0Li5FLgowMDEwICAwMCBiMCBmOCBhZiA0MCAwMCA0MCAwNiBiYiAyNSBj MCBhOCAwMiA5OSBjMCBhOCAgIC4uLi5ALkAuLiUuLi4uLi4KMDAyMCAgMDIg ODkgMDIgNjYgMDggMDEgMjIgZGQgMWMgNTYgZWUgYzMgYmYgMDIgNTAgMTgg ICAuLi5mLi4iLi5WLi4uLlAuCjAwMzAgIGZmIGZmIDg3IDE1IDAwIDAwIDgw IDAwIDAwIDg0IDU3IGRiIGQ0IGU1IDAwIDAwICAgLi4uLi4uLi4uLlcuLi4u LgowMDQwICAwMCAwMCAwMCAwMCAwMCAwMiAwMCAwMSA4NiBhMyAwMCAwMCAw MCAwMyAwMCAwMCAgIC4uLi4uLi4uLi4uLi4uLi4KMDA1MCAgMDAgMDcgMDAg MDAgMDAgMDEgMDAgMDAgMDAgMTggMDAgMDAgMDAgMDAgMDAgMDAgICAuLi4u Li4uLi4uLi4uLi4uCjAwNjAgIDAwIDAwIDAwIDAwIDAwIDUwIDAwIDAwIDAw IDUwIDAwIDAwIDAwIDAxIDAwIDAwICAgLi4uLi5QLi4uUC4uLi4uLgowMDcw ICAwMCA1MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAxYyA4 YiAyNiAgIC5QLi4uLi4uLi4uLi4uLiYKMDA4MCAgOTYgYTkgMDcgYmYgMGUg ZDQgMGEgMDAgMWYgODcgMDUgMDAgMDAgMDAgMDIgOWYgICAuLi4uLi4uLi4u Li4uLi4uCjAwOTAgIDA0IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwICAgLi4uLi4uLi4uLi4uLi4uLgowMGEwICAwMCAw MCAwMCAwMCAwMCAwZiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwZiAzOCAzOSAg IC4uLi4uLi4uLi4uLi4uODkKMDBiMCAgMzkgMzggMzggMjAgMzIgMzYgMzIg MzEgMzQgMzQgMzAgMzAgMzAgMDAgICAgICAgICA5ODggMjYyMTQ0MDAwLgoK Tm8uICAgICBUaW1lICAgICAgICBTb3VyY2UgICAgICAgICAgICAgICAgRGVz dGluYXRpb24gICAgICAgICAgIFByb3RvY29sIEluZm8KICAgICAxMyAwLjAw MTQ5NyAgICAxOTIuMTY4LjIuMTM3ICAgICAgICAgMTkyLjE2OC4yLjE1MyAg ICAgICAgIE5GUyAgICAgIFYzIFdSSVRFIFJlcGx5IChDYWxsIEluIDEyKSBF cnJvcjpORlMzRVJSX0lPCgpGcmFtZSAxMyAoOTQgYnl0ZXMgb24gd2lyZSwg OTQgYnl0ZXMgY2FwdHVyZWQpCiAgICBBcnJpdmFsIFRpbWU6IEphbiAzMCwg MjAxMCAxMjo0MTo0Ni45MTIzMjUwMDAKICAgIFtUaW1lIGRlbHRhIGZyb20g cHJldmlvdXMgY2FwdHVyZWQgZnJhbWU6IDAuMDAwMjIxMDAwIHNlY29uZHNd CiAgICBbVGltZSBkZWx0YSBmcm9tIHByZXZpb3VzIGRpc3BsYXllZCBmcmFt ZTogMC4wMDAyMjEwMDAgc2Vjb25kc10KICAgIFtUaW1lIHNpbmNlIHJlZmVy ZW5jZSBvciBmaXJzdCBmcmFtZTogMC4wMDE0OTcwMDAgc2Vjb25kc10KICAg IEZyYW1lIE51bWJlcjogMTMKICAgIEZyYW1lIExlbmd0aDogOTQgYnl0ZXMK ICAgIENhcHR1cmUgTGVuZ3RoOiA5NCBieXRlcwogICAgW0ZyYW1lIGlzIG1h cmtlZDogRmFsc2VdCiAgICBbUHJvdG9jb2xzIGluIGZyYW1lOiBldGg6aXA6 dGNwOnJwY10KICAgIFtDb2xvcmluZyBSdWxlIE5hbWU6IFRDUF0KICAgIFtD b2xvcmluZyBSdWxlIFN0cmluZzogdGNwXQpFdGhlcm5ldCBJSSwgU3JjOiBJ bnRlbENvcl9iZjplYjo3YiAoMDA6MTU6MTc6YmY6ZWI6N2IpLCBEc3Q6IFN1 cGVybWljXzdiOjUyOjM0ICgwMDozMDo0ODo3Yjo1MjozNCkKICAgIERlc3Rp bmF0aW9uOiBTdXBlcm1pY183Yjo1MjozNCAoMDA6MzA6NDg6N2I6NTI6MzQp CiAgICAgICAgQWRkcmVzczogU3VwZXJtaWNfN2I6NTI6MzQgKDAwOjMwOjQ4 OjdiOjUyOjM0KQogICAgICAgIC4uLi4gLi4uMCAuLi4uIC4uLi4gLi4uLiAu Li4uID0gSUcgYml0OiBJbmRpdmlkdWFsIGFkZHJlc3MgKHVuaWNhc3QpCiAg ICAgICAgLi4uLiAuLjAuIC4uLi4gLi4uLiAuLi4uIC4uLi4gPSBMRyBiaXQ6 IEdsb2JhbGx5IHVuaXF1ZSBhZGRyZXNzIChmYWN0b3J5IGRlZmF1bHQpCiAg ICBTb3VyY2U6IEludGVsQ29yX2JmOmViOjdiICgwMDoxNToxNzpiZjplYjo3 YikKICAgICAgICBBZGRyZXNzOiBJbnRlbENvcl9iZjplYjo3YiAoMDA6MTU6 MTc6YmY6ZWI6N2IpCiAgICAgICAgLi4uLiAuLi4wIC4uLi4gLi4uLiAuLi4u IC4uLi4gPSBJRyBiaXQ6IEluZGl2aWR1YWwgYWRkcmVzcyAodW5pY2FzdCkK ICAgICAgICAuLi4uIC4uMC4gLi4uLiAuLi4uIC4uLi4gLi4uLiA9IExHIGJp dDogR2xvYmFsbHkgdW5pcXVlIGFkZHJlc3MgKGZhY3RvcnkgZGVmYXVsdCkK ICAgIFR5cGU6IElQICgweDA4MDApCkludGVybmV0IFByb3RvY29sLCBTcmM6 IDE5Mi4xNjguMi4xMzcgKDE5Mi4xNjguMi4xMzcpLCBEc3Q6IDE5Mi4xNjgu Mi4xNTMgKDE5Mi4xNjguMi4xNTMpCiAgICBWZXJzaW9uOiA0CiAgICBIZWFk ZXIgbGVuZ3RoOiAyMCBieXRlcwogICAgRGlmZmVyZW50aWF0ZWQgU2Vydmlj ZXMgRmllbGQ6IDB4MDAgKERTQ1AgMHgwMDogRGVmYXVsdDsgRUNOOiAweDAw KQogICAgICAgIDAwMDAgMDAuLiA9IERpZmZlcmVudGlhdGVkIFNlcnZpY2Vz IENvZGVwb2ludDogRGVmYXVsdCAoMHgwMCkKICAgICAgICAuLi4uIC4uMC4g PSBFQ04tQ2FwYWJsZSBUcmFuc3BvcnQgKEVDVCk6IDAKICAgICAgICAuLi4u IC4uLjAgPSBFQ04tQ0U6IDAKICAgIFRvdGFsIExlbmd0aDogODAKICAgIElk ZW50aWZpY2F0aW9uOiAweGI4ZGIgKDQ3MzIzKQogICAgRmxhZ3M6IDB4MDQg KERvbid0IEZyYWdtZW50KQogICAgICAgIDAuLi4gPSBSZXNlcnZlZCBiaXQ6 IE5vdCBzZXQKICAgICAgICAuMS4uID0gRG9uJ3QgZnJhZ21lbnQ6IFNldAog ICAgICAgIC4uMC4gPSBNb3JlIGZyYWdtZW50czogTm90IHNldAogICAgRnJh Z21lbnQgb2Zmc2V0OiAwCiAgICBUaW1lIHRvIGxpdmU6IDY0CiAgICBQcm90 b2NvbDogVENQICgweDA2KQogICAgSGVhZGVyIGNoZWNrc3VtOiAweGZiNTkg W2NvcnJlY3RdCiAgICAgICAgW0dvb2Q6IFRydWVdCiAgICAgICAgW0JhZCA6 IEZhbHNlXQogICAgU291cmNlOiAxOTIuMTY4LjIuMTM3ICgxOTIuMTY4LjIu MTM3KQogICAgRGVzdGluYXRpb246IDE5Mi4xNjguMi4xNTMgKDE5Mi4xNjgu Mi4xNTMpClRyYW5zbWlzc2lvbiBDb250cm9sIFByb3RvY29sLCBTcmMgUG9y dDogbmZzICgyMDQ5KSwgRHN0IFBvcnQ6IHNzaGVsbCAoNjE0KSwgU2VxOiAy NDEsIEFjazogODE3LCBMZW46IDQwCiAgICBTb3VyY2UgcG9ydDogbmZzICgy MDQ5KQogICAgRGVzdGluYXRpb24gcG9ydDogc3NoZWxsICg2MTQpCiAgICBT ZXF1ZW5jZSBudW1iZXI6IDI0MSAgICAocmVsYXRpdmUgc2VxdWVuY2UgbnVt YmVyKQogICAgW05leHQgc2VxdWVuY2UgbnVtYmVyOiAyODEgICAgKHJlbGF0 aXZlIHNlcXVlbmNlIG51bWJlcildCiAgICBBY2tub3dsZWRnZW1lbnQgbnVt YmVyOiA4MTcgICAgKHJlbGF0aXZlIGFjayBudW1iZXIpCiAgICBIZWFkZXIg bGVuZ3RoOiAyMCBieXRlcwogICAgRmxhZ3M6IDB4MTggKFBTSCwgQUNLKQog ICAgICAgIDAuLi4gLi4uLiA9IENvbmdlc3Rpb24gV2luZG93IFJlZHVjZWQg KENXUik6IE5vdCBzZXQKICAgICAgICAuMC4uIC4uLi4gPSBFQ04tRWNobzog Tm90IHNldAogICAgICAgIC4uMC4gLi4uLiA9IFVyZ2VudDogTm90IHNldAog ICAgICAgIC4uLjEgLi4uLiA9IEFja25vd2xlZGdtZW50OiBTZXQKICAgICAg ICAuLi4uIDEuLi4gPSBQdXNoOiBTZXQKICAgICAgICAuLi4uIC4wLi4gPSBS ZXNldDogTm90IHNldAogICAgICAgIC4uLi4gLi4wLiA9IFN5bjogTm90IHNl dAogICAgICAgIC4uLi4gLi4uMCA9IEZpbjogTm90IHNldAogICAgV2luZG93 IHNpemU6IDY1NTM1CiAgICBDaGVja3N1bTogMHg4NDVkIFtjb3JyZWN0XQog ICAgICAgIFtHb29kIENoZWNrc3VtOiBUcnVlXQogICAgICAgIFtCYWQgQ2hl Y2tzdW06IEZhbHNlXQogICAgW1NFUS9BQ0sgYW5hbHlzaXNdCiAgICAgICAg W1RoaXMgaXMgYW4gQUNLIHRvIHRoZSBzZWdtZW50IGluIGZyYW1lOiAxMl0K ICAgICAgICBbVGhlIFJUVCB0byBBQ0sgdGhlIHNlZ21lbnQgd2FzOiAwLjAw MDIyMTAwMCBzZWNvbmRzXQpSZW1vdGUgUHJvY2VkdXJlIENhbGwsIFR5cGU6 UmVwbHkgWElEOjB4NTdkYmQ0ZTUKICAgIEZyYWdtZW50IGhlYWRlcjogTGFz dCBmcmFnbWVudCwgMzYgYnl0ZXMKICAgICAgICAxLi4uIC4uLi4gLi4uLiAu Li4uIC4uLi4gLi4uLiAuLi4uIC4uLi4gPSBMYXN0IEZyYWdtZW50OiBZZXMK ICAgICAgICAuMDAwIDAwMDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAwMDEwIDAx MDAgPSBGcmFnbWVudCBMZW5ndGg6IDM2CiAgICBYSUQ6IDB4NTdkYmQ0ZTUg KDE0NzQwMjQ2NzcpCiAgICBNZXNzYWdlIFR5cGU6IFJlcGx5ICgxKQogICAg W1Byb2dyYW06IE5GUyAoMTAwMDAzKV0KICAgIFtQcm9ncmFtIFZlcnNpb246 IDNdCiAgICBbUHJvY2VkdXJlOiBXUklURSAoNyldCiAgICBSZXBseSBTdGF0 ZTogYWNjZXB0ZWQgKDApCiAgICBbVGhpcyBpcyBhIHJlcGx5IHRvIGEgcmVx dWVzdCBpbiBmcmFtZSAxMl0KICAgIFtUaW1lIGZyb20gcmVxdWVzdDogMC4w MDAyMjEwMDAgc2Vjb25kc10KICAgIFZlcmlmaWVyCiAgICAgICAgRmxhdm9y OiBBVVRIX05VTEwgKDApCiAgICAgICAgTGVuZ3RoOiAwCiAgICBBY2NlcHQg U3RhdGU6IFJQQyBleGVjdXRlZCBzdWNjZXNzZnVsbHkgKDApCk5ldHdvcmsg RmlsZSBTeXN0ZW0sIFdSSVRFIFJlcGx5ICBFcnJvcjpORlMzRVJSX0lPCiAg ICBbUHJvZ3JhbSBWZXJzaW9uOiAzXQogICAgW1YzIFByb2NlZHVyZTogV1JJ VEUgKDcpXQogICAgU3RhdHVzOiBORlMzRVJSX0lPICg1KQogICAgZmlsZV93 Y2MKICAgICAgICBiZWZvcmUKICAgICAgICAgICAgYXR0cmlidXRlc19mb2xs b3c6IG5vIHZhbHVlICgwKQogICAgICAgIGFmdGVyCiAgICAgICAgICAgIGF0 dHJpYnV0ZXNfZm9sbG93OiBubyB2YWx1ZSAoMCkKCjAwMDAgIDAwIDMwIDQ4 IDdiIDUyIDM0IDAwIDE1IDE3IGJmIGViIDdiIDA4IDAwIDQ1IDAwICAgLjBI e1I0Li4uLi57Li5FLgowMDEwICAwMCA1MCBiOCBkYiA0MCAwMCA0MCAwNiBm YiA1OSBjMCBhOCAwMiA4OSBjMCBhOCAgIC5QLi5ALkAuLlkuLi4uLi4KMDAy MCAgMDIgOTkgMDggMDEgMDIgNjYgZWUgYzMgYmYgMDIgMjIgZGQgMWMgZGUg NTAgMTggICAuLi4uLmYuLi4uIi4uLlAuCjAwMzAgIGZmIGZmIDg0IDVkIDAw IDAwIDgwIDAwIDAwIDI0IDU3IGRiIGQ0IGU1IDAwIDAwICAgLi4uXS4uLi4u JFcuLi4uLgowMDQwICAwMCAwMSAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAgIC4uLi4uLi4uLi4uLi4uLi4KMDA1MCAgMDAg MDAgMDAgMDAgMDAgMDUgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgICAgICAg ICAuLi4uLi4uLi4uLi4uLgoKTm8uICAgICBUaW1lICAgICAgICBTb3VyY2Ug ICAgICAgICAgICAgICAgRGVzdGluYXRpb24gICAgICAgICAgIFByb3RvY29s IEluZm8KICAgICAxNCAwLjAwMTUyNSAgICAxOTIuMTY4LjIuMTUzICAgICAg ICAgMTkyLjE2OC4yLjEzNyAgICAgICAgIE5GUyAgICAgIFYzIFdSSVRFIENh bGwgKFJlcGx5IEluIDE1KSwgRkg6MHg4MTA2MDJmYyBPZmZzZXQ6MCBMZW46 MTUgVU5TVEFCTEUKCkZyYW1lIDE0ICgxOTAgYnl0ZXMgb24gd2lyZSwgMTkw IGJ5dGVzIGNhcHR1cmVkKQogICAgQXJyaXZhbCBUaW1lOiBKYW4gMzAsIDIw MTAgMTI6NDE6NDYuOTEyMzUzMDAwCiAgICBbVGltZSBkZWx0YSBmcm9tIHBy ZXZpb3VzIGNhcHR1cmVkIGZyYW1lOiAwLjAwMDAyODAwMCBzZWNvbmRzXQog ICAgW1RpbWUgZGVsdGEgZnJvbSBwcmV2aW91cyBkaXNwbGF5ZWQgZnJhbWU6 IDAuMDAwMDI4MDAwIHNlY29uZHNdCiAgICBbVGltZSBzaW5jZSByZWZlcmVu Y2Ugb3IgZmlyc3QgZnJhbWU6IDAuMDAxNTI1MDAwIHNlY29uZHNdCiAgICBG cmFtZSBOdW1iZXI6IDE0CiAgICBGcmFtZSBMZW5ndGg6IDE5MCBieXRlcwog ICAgQ2FwdHVyZSBMZW5ndGg6IDE5MCBieXRlcwogICAgW0ZyYW1lIGlzIG1h cmtlZDogRmFsc2VdCiAgICBbUHJvdG9jb2xzIGluIGZyYW1lOiBldGg6aXA6 dGNwOnJwYzpuZnNdCiAgICBbQ29sb3JpbmcgUnVsZSBOYW1lOiBDaGVja3N1 bSBFcnJvcnNdCiAgICBbQ29sb3JpbmcgUnVsZSBTdHJpbmc6IGNkcC5jaGVj a3N1bV9iYWQ9PTEgfHwgZWRwLmNoZWNrc3VtX2JhZD09MSB8fCBpcC5jaGVj a3N1bV9iYWQ9PTEgfHwgdGNwLmNoZWNrc3VtX2JhZD09MSB8fCB1ZHAuY2hl Y2tzdW1fYmFkPT0xXQpFdGhlcm5ldCBJSSwgU3JjOiBTdXBlcm1pY183Yjo1 MjozNCAoMDA6MzA6NDg6N2I6NTI6MzQpLCBEc3Q6IEludGVsQ29yX2JmOmVi OjdiICgwMDoxNToxNzpiZjplYjo3YikKICAgIERlc3RpbmF0aW9uOiBJbnRl bENvcl9iZjplYjo3YiAoMDA6MTU6MTc6YmY6ZWI6N2IpCiAgICAgICAgQWRk cmVzczogSW50ZWxDb3JfYmY6ZWI6N2IgKDAwOjE1OjE3OmJmOmViOjdiKQog ICAgICAgIC4uLi4gLi4uMCAuLi4uIC4uLi4gLi4uLiAuLi4uID0gSUcgYml0 OiBJbmRpdmlkdWFsIGFkZHJlc3MgKHVuaWNhc3QpCiAgICAgICAgLi4uLiAu LjAuIC4uLi4gLi4uLiAuLi4uIC4uLi4gPSBMRyBiaXQ6IEdsb2JhbGx5IHVu aXF1ZSBhZGRyZXNzIChmYWN0b3J5IGRlZmF1bHQpCiAgICBTb3VyY2U6IFN1 cGVybWljXzdiOjUyOjM0ICgwMDozMDo0ODo3Yjo1MjozNCkKICAgICAgICBB ZGRyZXNzOiBTdXBlcm1pY183Yjo1MjozNCAoMDA6MzA6NDg6N2I6NTI6MzQp CiAgICAgICAgLi4uLiAuLi4wIC4uLi4gLi4uLiAuLi4uIC4uLi4gPSBJRyBi aXQ6IEluZGl2aWR1YWwgYWRkcmVzcyAodW5pY2FzdCkKICAgICAgICAuLi4u IC4uMC4gLi4uLiAuLi4uIC4uLi4gLi4uLiA9IExHIGJpdDogR2xvYmFsbHkg dW5pcXVlIGFkZHJlc3MgKGZhY3RvcnkgZGVmYXVsdCkKICAgIFR5cGU6IElQ ICgweDA4MDApCkludGVybmV0IFByb3RvY29sLCBTcmM6IDE5Mi4xNjguMi4x NTMgKDE5Mi4xNjguMi4xNTMpLCBEc3Q6IDE5Mi4xNjguMi4xMzcgKDE5Mi4x NjguMi4xMzcpCiAgICBWZXJzaW9uOiA0CiAgICBIZWFkZXIgbGVuZ3RoOiAy MCBieXRlcwogICAgRGlmZmVyZW50aWF0ZWQgU2VydmljZXMgRmllbGQ6IDB4 MDAgKERTQ1AgMHgwMDogRGVmYXVsdDsgRUNOOiAweDAwKQogICAgICAgIDAw MDAgMDAuLiA9IERpZmZlcmVudGlhdGVkIFNlcnZpY2VzIENvZGVwb2ludDog RGVmYXVsdCAoMHgwMCkKICAgICAgICAuLi4uIC4uMC4gPSBFQ04tQ2FwYWJs ZSBUcmFuc3BvcnQgKEVDVCk6IDAKICAgICAgICAuLi4uIC4uLjAgPSBFQ04t Q0U6IDAKICAgIFRvdGFsIExlbmd0aDogMTc2CiAgICBJZGVudGlmaWNhdGlv bjogMHhmOGIwICg2MzY2NCkKICAgIEZsYWdzOiAweDA0IChEb24ndCBGcmFn bWVudCkKICAgICAgICAwLi4uID0gUmVzZXJ2ZWQgYml0OiBOb3Qgc2V0CiAg ICAgICAgLjEuLiA9IERvbid0IGZyYWdtZW50OiBTZXQKICAgICAgICAuLjAu ID0gTW9yZSBmcmFnbWVudHM6IE5vdCBzZXQKICAgIEZyYWdtZW50IG9mZnNl dDogMAogICAgVGltZSB0byBsaXZlOiA2NAogICAgUHJvdG9jb2w6IFRDUCAo MHgwNikKICAgIEhlYWRlciBjaGVja3N1bTogMHhiYjI0IFtjb3JyZWN0XQog ICAgICAgIFtHb29kOiBUcnVlXQogICAgICAgIFtCYWQgOiBGYWxzZV0KICAg IFNvdXJjZTogMTkyLjE2OC4yLjE1MyAoMTkyLjE2OC4yLjE1MykKICAgIERl c3RpbmF0aW9uOiAxOTIuMTY4LjIuMTM3ICgxOTIuMTY4LjIuMTM3KQpUcmFu c21pc3Npb24gQ29udHJvbCBQcm90b2NvbCwgU3JjIFBvcnQ6IHNzaGVsbCAo NjE0KSwgRHN0IFBvcnQ6IG5mcyAoMjA0OSksIFNlcTogODE3LCBBY2s6IDI4 MSwgTGVuOiAxMzYKICAgIFNvdXJjZSBwb3J0OiBzc2hlbGwgKDYxNCkKICAg IERlc3RpbmF0aW9uIHBvcnQ6IG5mcyAoMjA0OSkKICAgIFNlcXVlbmNlIG51 bWJlcjogODE3ICAgIChyZWxhdGl2ZSBzZXF1ZW5jZSBudW1iZXIpCiAgICBb TmV4dCBzZXF1ZW5jZSBudW1iZXI6IDk1MyAgICAocmVsYXRpdmUgc2VxdWVu Y2UgbnVtYmVyKV0KICAgIEFja25vd2xlZGdlbWVudCBudW1iZXI6IDI4MSAg ICAocmVsYXRpdmUgYWNrIG51bWJlcikKICAgIEhlYWRlciBsZW5ndGg6IDIw IGJ5dGVzCiAgICBGbGFnczogMHgxOCAoUFNILCBBQ0spCiAgICAgICAgMC4u LiAuLi4uID0gQ29uZ2VzdGlvbiBXaW5kb3cgUmVkdWNlZCAoQ1dSKTogTm90 IHNldAogICAgICAgIC4wLi4gLi4uLiA9IEVDTi1FY2hvOiBOb3Qgc2V0CiAg ICAgICAgLi4wLiAuLi4uID0gVXJnZW50OiBOb3Qgc2V0CiAgICAgICAgLi4u MSAuLi4uID0gQWNrbm93bGVkZ21lbnQ6IFNldAogICAgICAgIC4uLi4gMS4u LiA9IFB1c2g6IFNldAogICAgICAgIC4uLi4gLjAuLiA9IFJlc2V0OiBOb3Qg c2V0CiAgICAgICAgLi4uLiAuLjAuID0gU3luOiBOb3Qgc2V0CiAgICAgICAg Li4uLiAuLi4wID0gRmluOiBOb3Qgc2V0CiAgICBXaW5kb3cgc2l6ZTogNjU1 MzUKICAgIENoZWNrc3VtOiAweDg3MTUgW2luY29ycmVjdCwgc2hvdWxkIGJl IDB4ZWI5ZSAobWF5YmUgY2F1c2VkIGJ5ICJUQ1AgY2hlY2tzdW0gb2ZmbG9h ZCI/KV0KICAgICAgICBbR29vZCBDaGVja3N1bTogRmFsc2VdCiAgICAgICAg W0JhZCBDaGVja3N1bTogVHJ1ZV0KICAgIFtTRVEvQUNLIGFuYWx5c2lzXQog ICAgICAgIFtUaGlzIGlzIGFuIEFDSyB0byB0aGUgc2VnbWVudCBpbiBmcmFt ZTogMTNdCiAgICAgICAgW1RoZSBSVFQgdG8gQUNLIHRoZSBzZWdtZW50IHdh czogMC4wMDAwMjgwMDAgc2Vjb25kc10KUmVtb3RlIFByb2NlZHVyZSBDYWxs LCBUeXBlOkNhbGwgWElEOjB4NTdkYmQ0ZTYKICAgIEZyYWdtZW50IGhlYWRl cjogTGFzdCBmcmFnbWVudCwgMTMyIGJ5dGVzCiAgICAgICAgMS4uLiAuLi4u IC4uLi4gLi4uLiAuLi4uIC4uLi4gLi4uLiAuLi4uID0gTGFzdCBGcmFnbWVu dDogWWVzCiAgICAgICAgLjAwMCAwMDAwIDAwMDAgMDAwMCAwMDAwIDAwMDAg MTAwMCAwMTAwID0gRnJhZ21lbnQgTGVuZ3RoOiAxMzIKICAgIFhJRDogMHg1 N2RiZDRlNiAoMTQ3NDAyNDY3OCkKICAgIE1lc3NhZ2UgVHlwZTogQ2FsbCAo MCkKICAgIFJQQyBWZXJzaW9uOiAyCiAgICBQcm9ncmFtOiBORlMgKDEwMDAw MykKICAgIFByb2dyYW0gVmVyc2lvbjogMwogICAgUHJvY2VkdXJlOiBXUklU RSAoNykKICAgIFtUaGUgcmVwbHkgdG8gdGhpcyByZXF1ZXN0IGlzIGluIGZy YW1lIDE1XQogICAgQ3JlZGVudGlhbHMKICAgICAgICBGbGF2b3I6IEFVVEhf VU5JWCAoMSkKICAgICAgICBMZW5ndGg6IDI0CiAgICAgICAgU3RhbXA6IDB4 MDAwMDAwMDAKICAgICAgICBNYWNoaW5lIE5hbWU6IDxFTVBUWT4KICAgICAg ICAgICAgbGVuZ3RoOiAwCiAgICAgICAgICAgIGNvbnRlbnRzOiA8RU1QVFk+ CiAgICAgICAgVUlEOiA4MAogICAgICAgIEdJRDogODAKICAgICAgICBBdXhp bGlhcnkgR0lEcwogICAgICAgICAgICBHSUQ6IDgwCiAgICBWZXJpZmllcgog ICAgICAgIEZsYXZvcjogQVVUSF9OVUxMICgwKQogICAgICAgIExlbmd0aDog MApOZXR3b3JrIEZpbGUgU3lzdGVtLCBXUklURSBDYWxsIEZIOjB4ODEwNjAy ZmMgT2Zmc2V0OjAgTGVuOjE1IFVOU1RBQkxFCiAgICBbUHJvZ3JhbSBWZXJz aW9uOiAzXQogICAgW1YzIFByb2NlZHVyZTogV1JJVEUgKDcpXQogICAgZmls ZQogICAgICAgIGxlbmd0aDogMjgKICAgICAgICBbaGFzaDogMHg4MTA2MDJm Y10KICAgICAgICBkZWNvZGUgdHlwZSBhczogdW5rbm93bgogICAgICAgIGZp bGVoYW5kbGU6IDhCMjY5NkE5MDdCRjBFRDQwQTAwMUY4NzA1MDAwMDAwMDI5 RjA0MDAwMDAwMDAwMC4uLgogICAgb2Zmc2V0OiAwCiAgICBjb3VudDogMTUK ICAgIFN0YWJsZTogVU5TVEFCTEUgKDApCiAgICBEYXRhOiA8REFUQT4KICAg ICAgICBsZW5ndGg6IDE1CiAgICAgICAgY29udGVudHM6IDxEQVRBPgogICAg ICAgIGZpbGwgYnl0ZXM6IG9wYXF1ZSBkYXRhCgowMDAwICAwMCAxNSAxNyBi ZiBlYiA3YiAwMCAzMCA0OCA3YiA1MiAzNCAwOCAwMCA0NSAwMCAgIC4uLi4u ey4wSHtSNC4uRS4KMDAxMCAgMDAgYjAgZjggYjAgNDAgMDAgNDAgMDYgYmIg MjQgYzAgYTggMDIgOTkgYzAgYTggICAuLi4uQC5ALi4kLi4uLi4uCjAwMjAg IDAyIDg5IDAyIDY2IDA4IDAxIDIyIGRkIDFjIGRlIGVlIGMzIGJmIDJhIDUw IDE4ICAgLi4uZi4uIi4uLi4uLipQLgowMDMwICBmZiBmZiA4NyAxNSAwMCAw MCA4MCAwMCAwMCA4NCA1NyBkYiBkNCBlNiAwMCAwMCAgIC4uLi4uLi4uLi5X Li4uLi4KMDA0MCAgMDAgMDAgMDAgMDAgMDAgMDIgMDAgMDEgODYgYTMgMDAg MDAgMDAgMDMgMDAgMDAgICAuLi4uLi4uLi4uLi4uLi4uCjAwNTAgIDAwIDA3 IDAwIDAwIDAwIDAxIDAwIDAwIDAwIDE4IDAwIDAwIDAwIDAwIDAwIDAwICAg Li4uLi4uLi4uLi4uLi4uLgowMDYwICAwMCAwMCAwMCAwMCAwMCA1MCAwMCAw MCAwMCA1MCAwMCAwMCAwMCAwMSAwMCAwMCAgIC4uLi4uUC4uLlAuLi4uLi4K MDA3MCAgMDAgNTAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MWMgOGIgMjYgICAuUC4uLi4uLi4uLi4uLi4mCjAwODAgIDk2IGE5IDA3IGJm IDBlIGQ0IDBhIDAwIDFmIDg3IDA1IDAwIDAwIDAwIDAyIDlmICAgLi4uLi4u Li4uLi4uLi4uLgowMDkwICAwNCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAgIC4uLi4uLi4uLi4uLi4uLi4KMDBhMCAg MDAgMDAgMDAgMDAgMDAgMGYgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMGYgMzgg MzkgICAuLi4uLi4uLi4uLi4uLjg5CjAwYjAgIDM5IDM4IDM4IDIwIDMyIDM2 IDMyIDMxIDM0IDM0IDMwIDMwIDMwIDAwICAgICAgICAgOTg4IDI2MjE0NDAw MC4KCk5vLiAgICAgVGltZSAgICAgICAgU291cmNlICAgICAgICAgICAgICAg IERlc3RpbmF0aW9uICAgICAgICAgICBQcm90b2NvbCBJbmZvCiAgICAgMTUg MC4wMDE3NDYgICAgMTkyLjE2OC4yLjEzNyAgICAgICAgIDE5Mi4xNjguMi4x NTMgICAgICAgICBORlMgICAgICBWMyBXUklURSBSZXBseSAoQ2FsbCBJbiAx NCkgRXJyb3I6TkZTM0VSUl9JTwoKRnJhbWUgMTUgKDk0IGJ5dGVzIG9uIHdp cmUsIDk0IGJ5dGVzIGNhcHR1cmVkKQogICAgQXJyaXZhbCBUaW1lOiBKYW4g MzAsIDIwMTAgMTI6NDE6NDYuOTEyNTc0MDAwCiAgICBbVGltZSBkZWx0YSBm cm9tIHByZXZpb3VzIGNhcHR1cmVkIGZyYW1lOiAwLjAwMDIyMTAwMCBzZWNv bmRzXQogICAgW1RpbWUgZGVsdGEgZnJvbSBwcmV2aW91cyBkaXNwbGF5ZWQg ZnJhbWU6IDAuMDAwMjIxMDAwIHNlY29uZHNdCiAgICBbVGltZSBzaW5jZSBy ZWZlcmVuY2Ugb3IgZmlyc3QgZnJhbWU6IDAuMDAxNzQ2MDAwIHNlY29uZHNd CiAgICBGcmFtZSBOdW1iZXI6IDE1CiAgICBGcmFtZSBMZW5ndGg6IDk0IGJ5 dGVzCiAgICBDYXB0dXJlIExlbmd0aDogOTQgYnl0ZXMKICAgIFtGcmFtZSBp cyBtYXJrZWQ6IEZhbHNlXQogICAgW1Byb3RvY29scyBpbiBmcmFtZTogZXRo OmlwOnRjcDpycGNdCiAgICBbQ29sb3JpbmcgUnVsZSBOYW1lOiBUQ1BdCiAg ICBbQ29sb3JpbmcgUnVsZSBTdHJpbmc6IHRjcF0KRXRoZXJuZXQgSUksIFNy YzogSW50ZWxDb3JfYmY6ZWI6N2IgKDAwOjE1OjE3OmJmOmViOjdiKSwgRHN0 OiBTdXBlcm1pY183Yjo1MjozNCAoMDA6MzA6NDg6N2I6NTI6MzQpCiAgICBE ZXN0aW5hdGlvbjogU3VwZXJtaWNfN2I6NTI6MzQgKDAwOjMwOjQ4OjdiOjUy OjM0KQogICAgICAgIEFkZHJlc3M6IFN1cGVybWljXzdiOjUyOjM0ICgwMDoz MDo0ODo3Yjo1MjozNCkKICAgICAgICAuLi4uIC4uLjAgLi4uLiAuLi4uIC4u Li4gLi4uLiA9IElHIGJpdDogSW5kaXZpZHVhbCBhZGRyZXNzICh1bmljYXN0 KQogICAgICAgIC4uLi4gLi4wLiAuLi4uIC4uLi4gLi4uLiAuLi4uID0gTEcg Yml0OiBHbG9iYWxseSB1bmlxdWUgYWRkcmVzcyAoZmFjdG9yeSBkZWZhdWx0 KQogICAgU291cmNlOiBJbnRlbENvcl9iZjplYjo3YiAoMDA6MTU6MTc6YmY6 ZWI6N2IpCiAgICAgICAgQWRkcmVzczogSW50ZWxDb3JfYmY6ZWI6N2IgKDAw OjE1OjE3OmJmOmViOjdiKQogICAgICAgIC4uLi4gLi4uMCAuLi4uIC4uLi4g Li4uLiAuLi4uID0gSUcgYml0OiBJbmRpdmlkdWFsIGFkZHJlc3MgKHVuaWNh c3QpCiAgICAgICAgLi4uLiAuLjAuIC4uLi4gLi4uLiAuLi4uIC4uLi4gPSBM RyBiaXQ6IEdsb2JhbGx5IHVuaXF1ZSBhZGRyZXNzIChmYWN0b3J5IGRlZmF1 bHQpCiAgICBUeXBlOiBJUCAoMHgwODAwKQpJbnRlcm5ldCBQcm90b2NvbCwg U3JjOiAxOTIuMTY4LjIuMTM3ICgxOTIuMTY4LjIuMTM3KSwgRHN0OiAxOTIu MTY4LjIuMTUzICgxOTIuMTY4LjIuMTUzKQogICAgVmVyc2lvbjogNAogICAg SGVhZGVyIGxlbmd0aDogMjAgYnl0ZXMKICAgIERpZmZlcmVudGlhdGVkIFNl cnZpY2VzIEZpZWxkOiAweDAwIChEU0NQIDB4MDA6IERlZmF1bHQ7IEVDTjog MHgwMCkKICAgICAgICAwMDAwIDAwLi4gPSBEaWZmZXJlbnRpYXRlZCBTZXJ2 aWNlcyBDb2RlcG9pbnQ6IERlZmF1bHQgKDB4MDApCiAgICAgICAgLi4uLiAu LjAuID0gRUNOLUNhcGFibGUgVHJhbnNwb3J0IChFQ1QpOiAwCiAgICAgICAg Li4uLiAuLi4wID0gRUNOLUNFOiAwCiAgICBUb3RhbCBMZW5ndGg6IDgwCiAg ICBJZGVudGlmaWNhdGlvbjogMHhiOGRjICg0NzMyNCkKICAgIEZsYWdzOiAw eDA0IChEb24ndCBGcmFnbWVudCkKICAgICAgICAwLi4uID0gUmVzZXJ2ZWQg Yml0OiBOb3Qgc2V0CiAgICAgICAgLjEuLiA9IERvbid0IGZyYWdtZW50OiBT ZXQKICAgICAgICAuLjAuID0gTW9yZSBmcmFnbWVudHM6IE5vdCBzZXQKICAg IEZyYWdtZW50IG9mZnNldDogMAogICAgVGltZSB0byBsaXZlOiA2NAogICAg UHJvdG9jb2w6IFRDUCAoMHgwNikKICAgIEhlYWRlciBjaGVja3N1bTogMHhm YjU4IFtjb3JyZWN0XQogICAgICAgIFtHb29kOiBUcnVlXQogICAgICAgIFtC YWQgOiBGYWxzZV0KICAgIFNvdXJjZTogMTkyLjE2OC4yLjEzNyAoMTkyLjE2 OC4yLjEzNykKICAgIERlc3RpbmF0aW9uOiAxOTIuMTY4LjIuMTUzICgxOTIu MTY4LjIuMTUzKQpUcmFuc21pc3Npb24gQ29udHJvbCBQcm90b2NvbCwgU3Jj IFBvcnQ6IG5mcyAoMjA0OSksIERzdCBQb3J0OiBzc2hlbGwgKDYxNCksIFNl cTogMjgxLCBBY2s6IDk1MywgTGVuOiA0MAogICAgU291cmNlIHBvcnQ6IG5m cyAoMjA0OSkKICAgIERlc3RpbmF0aW9uIHBvcnQ6IHNzaGVsbCAoNjE0KQog ICAgU2VxdWVuY2UgbnVtYmVyOiAyODEgICAgKHJlbGF0aXZlIHNlcXVlbmNl IG51bWJlcikKICAgIFtOZXh0IHNlcXVlbmNlIG51bWJlcjogMzIxICAgIChy ZWxhdGl2ZSBzZXF1ZW5jZSBudW1iZXIpXQogICAgQWNrbm93bGVkZ2VtZW50 IG51bWJlcjogOTUzICAgIChyZWxhdGl2ZSBhY2sgbnVtYmVyKQogICAgSGVh ZGVyIGxlbmd0aDogMjAgYnl0ZXMKICAgIEZsYWdzOiAweDE4IChQU0gsIEFD SykKICAgICAgICAwLi4uIC4uLi4gPSBDb25nZXN0aW9uIFdpbmRvdyBSZWR1 Y2VkIChDV1IpOiBOb3Qgc2V0CiAgICAgICAgLjAuLiAuLi4uID0gRUNOLUVj aG86IE5vdCBzZXQKICAgICAgICAuLjAuIC4uLi4gPSBVcmdlbnQ6IE5vdCBz ZXQKICAgICAgICAuLi4xIC4uLi4gPSBBY2tub3dsZWRnbWVudDogU2V0CiAg ICAgICAgLi4uLiAxLi4uID0gUHVzaDogU2V0CiAgICAgICAgLi4uLiAuMC4u ID0gUmVzZXQ6IE5vdCBzZXQKICAgICAgICAuLi4uIC4uMC4gPSBTeW46IE5v dCBzZXQKICAgICAgICAuLi4uIC4uLjAgPSBGaW46IE5vdCBzZXQKICAgIFdp bmRvdyBzaXplOiA2NTUzNQogICAgQ2hlY2tzdW06IDB4ODNhYyBbY29ycmVj dF0KICAgICAgICBbR29vZCBDaGVja3N1bTogVHJ1ZV0KICAgICAgICBbQmFk IENoZWNrc3VtOiBGYWxzZV0KICAgIFtTRVEvQUNLIGFuYWx5c2lzXQogICAg ICAgIFtUaGlzIGlzIGFuIEFDSyB0byB0aGUgc2VnbWVudCBpbiBmcmFtZTog MTRdCiAgICAgICAgW1RoZSBSVFQgdG8gQUNLIHRoZSBzZWdtZW50IHdhczog MC4wMDAyMjEwMDAgc2Vjb25kc10KUmVtb3RlIFByb2NlZHVyZSBDYWxsLCBU eXBlOlJlcGx5IFhJRDoweDU3ZGJkNGU2CiAgICBGcmFnbWVudCBoZWFkZXI6 IExhc3QgZnJhZ21lbnQsIDM2IGJ5dGVzCiAgICAgICAgMS4uLiAuLi4uIC4u Li4gLi4uLiAuLi4uIC4uLi4gLi4uLiAuLi4uID0gTGFzdCBGcmFnbWVudDog WWVzCiAgICAgICAgLjAwMCAwMDAwIDAwMDAgMDAwMCAwMDAwIDAwMDAgMDAx MCAwMTAwID0gRnJhZ21lbnQgTGVuZ3RoOiAzNgogICAgWElEOiAweDU3ZGJk NGU2ICgxNDc0MDI0Njc4KQogICAgTWVzc2FnZSBUeXBlOiBSZXBseSAoMSkK ICAgIFtQcm9ncmFtOiBORlMgKDEwMDAwMyldCiAgICBbUHJvZ3JhbSBWZXJz aW9uOiAzXQogICAgW1Byb2NlZHVyZTogV1JJVEUgKDcpXQogICAgUmVwbHkg U3RhdGU6IGFjY2VwdGVkICgwKQogICAgW1RoaXMgaXMgYSByZXBseSB0byBh IHJlcXVlc3QgaW4gZnJhbWUgMTRdCiAgICBbVGltZSBmcm9tIHJlcXVlc3Q6 IDAuMDAwMjIxMDAwIHNlY29uZHNdCiAgICBWZXJpZmllcgogICAgICAgIEZs YXZvcjogQVVUSF9OVUxMICgwKQogICAgICAgIExlbmd0aDogMAogICAgQWNj ZXB0IFN0YXRlOiBSUEMgZXhlY3V0ZWQgc3VjY2Vzc2Z1bGx5ICgwKQpOZXR3 b3JrIEZpbGUgU3lzdGVtLCBXUklURSBSZXBseSAgRXJyb3I6TkZTM0VSUl9J TwogICAgW1Byb2dyYW0gVmVyc2lvbjogM10KICAgIFtWMyBQcm9jZWR1cmU6 IFdSSVRFICg3KV0KICAgIFN0YXR1czogTkZTM0VSUl9JTyAoNSkKICAgIGZp bGVfd2NjCiAgICAgICAgYmVmb3JlCiAgICAgICAgICAgIGF0dHJpYnV0ZXNf Zm9sbG93OiBubyB2YWx1ZSAoMCkKICAgICAgICBhZnRlcgogICAgICAgICAg ICBhdHRyaWJ1dGVzX2ZvbGxvdzogbm8gdmFsdWUgKDApCgowMDAwICAwMCAz MCA0OCA3YiA1MiAzNCAwMCAxNSAxNyBiZiBlYiA3YiAwOCAwMCA0NSAwMCAg IC4wSHtSNC4uLi4uey4uRS4KMDAxMCAgMDAgNTAgYjggZGMgNDAgMDAgNDAg MDYgZmIgNTggYzAgYTggMDIgODkgYzAgYTggICAuUC4uQC5ALi5YLi4uLi4u CjAwMjAgIDAyIDk5IDA4IDAxIDAyIDY2IGVlIGMzIGJmIDJhIDIyIGRkIDFk IDY2IDUwIDE4ICAgLi4uLi5mLi4uKiIuLmZQLgowMDMwICBmZiBmZiA4MyBh YyAwMCAwMCA4MCAwMCAwMCAyNCA1NyBkYiBkNCBlNiAwMCAwMCAgIC4uLi4u Li4uLiRXLi4uLi4KMDA0MCAgMDAgMDEgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgICAuLi4uLi4uLi4uLi4uLi4uCjAwNTAg IDAwIDAwIDAwIDAwIDAwIDA1IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAg ICAgICAgLi4uLi4uLi4uLi4uLi4KCk5vLiAgICAgVGltZSAgICAgICAgU291 cmNlICAgICAgICAgICAgICAgIERlc3RpbmF0aW9uICAgICAgICAgICBQcm90 b2NvbCBJbmZvCiAgICAgMTYgMC4wMDE3NzYgICAgMTkyLjE2OC4yLjE1MyAg ICAgICAgIDE5Mi4xNjguMi4xMzcgICAgICAgICBORlMgICAgICBWMyBXUklU RSBDYWxsIChSZXBseSBJbiAxNyksIEZIOjB4ODEwNjAyZmMgT2Zmc2V0OjAg TGVuOjE1IFVOU1RBQkxFCgpGcmFtZSAxNiAoMTkwIGJ5dGVzIG9uIHdpcmUs IDE5MCBieXRlcyBjYXB0dXJlZCkKICAgIEFycml2YWwgVGltZTogSmFuIDMw LCAyMDEwIDEyOjQxOjQ2LjkxMjYwNDAwMAogICAgW1RpbWUgZGVsdGEgZnJv bSBwcmV2aW91cyBjYXB0dXJlZCBmcmFtZTogMC4wMDAwMzAwMDAgc2Vjb25k c10KICAgIFtUaW1lIGRlbHRhIGZyb20gcHJldmlvdXMgZGlzcGxheWVkIGZy YW1lOiAwLjAwMDAzMDAwMCBzZWNvbmRzXQogICAgW1RpbWUgc2luY2UgcmVm ZXJlbmNlIG9yIGZpcnN0IGZyYW1lOiAwLjAwMTc3NjAwMCBzZWNvbmRzXQog ICAgRnJhbWUgTnVtYmVyOiAxNgogICAgRnJhbWUgTGVuZ3RoOiAxOTAgYnl0 ZXMKICAgIENhcHR1cmUgTGVuZ3RoOiAxOTAgYnl0ZXMKICAgIFtGcmFtZSBp cyBtYXJrZWQ6IEZhbHNlXQogICAgW1Byb3RvY29scyBpbiBmcmFtZTogZXRo OmlwOnRjcDpycGM6bmZzXQogICAgW0NvbG9yaW5nIFJ1bGUgTmFtZTogQ2hl Y2tzdW0gRXJyb3JzXQogICAgW0NvbG9yaW5nIFJ1bGUgU3RyaW5nOiBjZHAu Y2hlY2tzdW1fYmFkPT0xIHx8IGVkcC5jaGVja3N1bV9iYWQ9PTEgfHwgaXAu Y2hlY2tzdW1fYmFkPT0xIHx8IHRjcC5jaGVja3N1bV9iYWQ9PTEgfHwgdWRw LmNoZWNrc3VtX2JhZD09MV0KRXRoZXJuZXQgSUksIFNyYzogU3VwZXJtaWNf N2I6NTI6MzQgKDAwOjMwOjQ4OjdiOjUyOjM0KSwgRHN0OiBJbnRlbENvcl9i ZjplYjo3YiAoMDA6MTU6MTc6YmY6ZWI6N2IpCiAgICBEZXN0aW5hdGlvbjog SW50ZWxDb3JfYmY6ZWI6N2IgKDAwOjE1OjE3OmJmOmViOjdiKQogICAgICAg IEFkZHJlc3M6IEludGVsQ29yX2JmOmViOjdiICgwMDoxNToxNzpiZjplYjo3 YikKICAgICAgICAuLi4uIC4uLjAgLi4uLiAuLi4uIC4uLi4gLi4uLiA9IElH IGJpdDogSW5kaXZpZHVhbCBhZGRyZXNzICh1bmljYXN0KQogICAgICAgIC4u Li4gLi4wLiAuLi4uIC4uLi4gLi4uLiAuLi4uID0gTEcgYml0OiBHbG9iYWxs eSB1bmlxdWUgYWRkcmVzcyAoZmFjdG9yeSBkZWZhdWx0KQogICAgU291cmNl OiBTdXBlcm1pY183Yjo1MjozNCAoMDA6MzA6NDg6N2I6NTI6MzQpCiAgICAg ICAgQWRkcmVzczogU3VwZXJtaWNfN2I6NTI6MzQgKDAwOjMwOjQ4OjdiOjUy OjM0KQogICAgICAgIC4uLi4gLi4uMCAuLi4uIC4uLi4gLi4uLiAuLi4uID0g SUcgYml0OiBJbmRpdmlkdWFsIGFkZHJlc3MgKHVuaWNhc3QpCiAgICAgICAg Li4uLiAuLjAuIC4uLi4gLi4uLiAuLi4uIC4uLi4gPSBMRyBiaXQ6IEdsb2Jh bGx5IHVuaXF1ZSBhZGRyZXNzIChmYWN0b3J5IGRlZmF1bHQpCiAgICBUeXBl OiBJUCAoMHgwODAwKQpJbnRlcm5ldCBQcm90b2NvbCwgU3JjOiAxOTIuMTY4 LjIuMTUzICgxOTIuMTY4LjIuMTUzKSwgRHN0OiAxOTIuMTY4LjIuMTM3ICgx OTIuMTY4LjIuMTM3KQogICAgVmVyc2lvbjogNAogICAgSGVhZGVyIGxlbmd0 aDogMjAgYnl0ZXMKICAgIERpZmZlcmVudGlhdGVkIFNlcnZpY2VzIEZpZWxk OiAweDAwIChEU0NQIDB4MDA6IERlZmF1bHQ7IEVDTjogMHgwMCkKICAgICAg ICAwMDAwIDAwLi4gPSBEaWZmZXJlbnRpYXRlZCBTZXJ2aWNlcyBDb2RlcG9p bnQ6IERlZmF1bHQgKDB4MDApCiAgICAgICAgLi4uLiAuLjAuID0gRUNOLUNh cGFibGUgVHJhbnNwb3J0IChFQ1QpOiAwCiAgICAgICAgLi4uLiAuLi4wID0g RUNOLUNFOiAwCiAgICBUb3RhbCBMZW5ndGg6IDE3NgogICAgSWRlbnRpZmlj YXRpb246IDB4ZjhiMSAoNjM2NjUpCiAgICBGbGFnczogMHgwNCAoRG9uJ3Qg RnJhZ21lbnQpCiAgICAgICAgMC4uLiA9IFJlc2VydmVkIGJpdDogTm90IHNl dAogICAgICAgIC4xLi4gPSBEb24ndCBmcmFnbWVudDogU2V0CiAgICAgICAg Li4wLiA9IE1vcmUgZnJhZ21lbnRzOiBOb3Qgc2V0CiAgICBGcmFnbWVudCBv ZmZzZXQ6IDAKICAgIFRpbWUgdG8gbGl2ZTogNjQKICAgIFByb3RvY29sOiBU Q1AgKDB4MDYpCiAgICBIZWFkZXIgY2hlY2tzdW06IDB4YmIyMyBbY29ycmVj dF0KICAgICAgICBbR29vZDogVHJ1ZV0KICAgICAgICBbQmFkIDogRmFsc2Vd CiAgICBTb3VyY2U6IDE5Mi4xNjguMi4xNTMgKDE5Mi4xNjguMi4xNTMpCiAg ICBEZXN0aW5hdGlvbjogMTkyLjE2OC4yLjEzNyAoMTkyLjE2OC4yLjEzNykK VHJhbnNtaXNzaW9uIENvbnRyb2wgUHJvdG9jb2wsIFNyYyBQb3J0OiBzc2hl bGwgKDYxNCksIERzdCBQb3J0OiBuZnMgKDIwNDkpLCBTZXE6IDk1MywgQWNr OiAzMjEsIExlbjogMTM2CiAgICBTb3VyY2UgcG9ydDogc3NoZWxsICg2MTQp CiAgICBEZXN0aW5hdGlvbiBwb3J0OiBuZnMgKDIwNDkpCiAgICBTZXF1ZW5j ZSBudW1iZXI6IDk1MyAgICAocmVsYXRpdmUgc2VxdWVuY2UgbnVtYmVyKQog ICAgW05leHQgc2VxdWVuY2UgbnVtYmVyOiAxMDg5ICAgIChyZWxhdGl2ZSBz ZXF1ZW5jZSBudW1iZXIpXQogICAgQWNrbm93bGVkZ2VtZW50IG51bWJlcjog MzIxICAgIChyZWxhdGl2ZSBhY2sgbnVtYmVyKQogICAgSGVhZGVyIGxlbmd0 aDogMjAgYnl0ZXMKICAgIEZsYWdzOiAweDE4IChQU0gsIEFDSykKICAgICAg ICAwLi4uIC4uLi4gPSBDb25nZXN0aW9uIFdpbmRvdyBSZWR1Y2VkIChDV1Ip OiBOb3Qgc2V0CiAgICAgICAgLjAuLiAuLi4uID0gRUNOLUVjaG86IE5vdCBz ZXQKICAgICAgICAuLjAuIC4uLi4gPSBVcmdlbnQ6IE5vdCBzZXQKICAgICAg ICAuLi4xIC4uLi4gPSBBY2tub3dsZWRnbWVudDogU2V0CiAgICAgICAgLi4u LiAxLi4uID0gUHVzaDogU2V0CiAgICAgICAgLi4uLiAuMC4uID0gUmVzZXQ6 IE5vdCBzZXQKICAgICAgICAuLi4uIC4uMC4gPSBTeW46IE5vdCBzZXQKICAg ICAgICAuLi4uIC4uLjAgPSBGaW46IE5vdCBzZXQKICAgIFdpbmRvdyBzaXpl OiA2NTUzNQogICAgQ2hlY2tzdW06IDB4ODcxNSBbaW5jb3JyZWN0LCBzaG91 bGQgYmUgMHhlYWVkIChtYXliZSBjYXVzZWQgYnkgIlRDUCBjaGVja3N1bSBv ZmZsb2FkIj8pXQogICAgICAgIFtHb29kIENoZWNrc3VtOiBGYWxzZV0KICAg ICAgICBbQmFkIENoZWNrc3VtOiBUcnVlXQogICAgW1NFUS9BQ0sgYW5hbHlz aXNdCiAgICAgICAgW1RoaXMgaXMgYW4gQUNLIHRvIHRoZSBzZWdtZW50IGlu IGZyYW1lOiAxNV0KICAgICAgICBbVGhlIFJUVCB0byBBQ0sgdGhlIHNlZ21l bnQgd2FzOiAwLjAwMDAzMDAwMCBzZWNvbmRzXQpSZW1vdGUgUHJvY2VkdXJl IENhbGwsIFR5cGU6Q2FsbCBYSUQ6MHg1N2RiZDRlNwogICAgRnJhZ21lbnQg aGVhZGVyOiBMYXN0IGZyYWdtZW50LCAxMzIgYnl0ZXMKICAgICAgICAxLi4u IC4uLi4gLi4uLiAuLi4uIC4uLi4gLi4uLiAuLi4uIC4uLi4gPSBMYXN0IEZy YWdtZW50OiBZZXMKICAgICAgICAuMDAwIDAwMDAgMDAwMCAwMDAwIDAwMDAg MDAwMCAxMDAwIDAxMDAgPSBGcmFnbWVudCBMZW5ndGg6IDEzMgogICAgWElE OiAweDU3ZGJkNGU3ICgxNDc0MDI0Njc5KQogICAgTWVzc2FnZSBUeXBlOiBD YWxsICgwKQogICAgUlBDIFZlcnNpb246IDIKICAgIFByb2dyYW06IE5GUyAo MTAwMDAzKQogICAgUHJvZ3JhbSBWZXJzaW9uOiAzCiAgICBQcm9jZWR1cmU6 IFdSSVRFICg3KQogICAgW1RoZSByZXBseSB0byB0aGlzIHJlcXVlc3QgaXMg aW4gZnJhbWUgMTddCiAgICBDcmVkZW50aWFscwogICAgICAgIEZsYXZvcjog QVVUSF9VTklYICgxKQogICAgICAgIExlbmd0aDogMjQKICAgICAgICBTdGFt cDogMHgwMDAwMDAwMAogICAgICAgIE1hY2hpbmUgTmFtZTogPEVNUFRZPgog ICAgICAgICAgICBsZW5ndGg6IDAKICAgICAgICAgICAgY29udGVudHM6IDxF TVBUWT4KICAgICAgICBVSUQ6IDgwCiAgICAgICAgR0lEOiA4MAogICAgICAg IEF1eGlsaWFyeSBHSURzCiAgICAgICAgICAgIEdJRDogODAKICAgIFZlcmlm aWVyCiAgICAgICAgRmxhdm9yOiBBVVRIX05VTEwgKDApCiAgICAgICAgTGVu Z3RoOiAwCk5ldHdvcmsgRmlsZSBTeXN0ZW0sIFdSSVRFIENhbGwgRkg6MHg4 MTA2MDJmYyBPZmZzZXQ6MCBMZW46MTUgVU5TVEFCTEUKICAgIFtQcm9ncmFt IFZlcnNpb246IDNdCiAgICBbVjMgUHJvY2VkdXJlOiBXUklURSAoNyldCiAg ICBmaWxlCiAgICAgICAgbGVuZ3RoOiAyOAogICAgICAgIFtoYXNoOiAweDgx MDYwMmZjXQogICAgICAgIGRlY29kZSB0eXBlIGFzOiB1bmtub3duCiAgICAg ICAgZmlsZWhhbmRsZTogOEIyNjk2QTkwN0JGMEVENDBBMDAxRjg3MDUwMDAw MDAwMjlGMDQwMDAwMDAwMDAwLi4uCiAgICBvZmZzZXQ6IDAKICAgIGNvdW50 OiAxNQogICAgU3RhYmxlOiBVTlNUQUJMRSAoMCkKICAgIERhdGE6IDxEQVRB PgogICAgICAgIGxlbmd0aDogMTUKICAgICAgICBjb250ZW50czogPERBVEE+ CiAgICAgICAgZmlsbCBieXRlczogb3BhcXVlIGRhdGEKCjAwMDAgIDAwIDE1 IDE3IGJmIGViIDdiIDAwIDMwIDQ4IDdiIDUyIDM0IDA4IDAwIDQ1IDAwICAg Li4uLi57LjBIe1I0Li5FLgowMDEwICAwMCBiMCBmOCBiMSA0MCAwMCA0MCAw NiBiYiAyMyBjMCBhOCAwMiA5OSBjMCBhOCAgIC4uLi5ALkAuLiMuLi4uLi4K MDAyMCAgMDIgODkgMDIgNjYgMDggMDEgMjIgZGQgMWQgNjYgZWUgYzMgYmYg NTIgNTAgMTggICAuLi5mLi4iLi5mLi4uUlAuCjAwMzAgIGZmIGZmIDg3IDE1 IDAwIDAwIDgwIDAwIDAwIDg0IDU3IGRiIGQ0IGU3IDAwIDAwICAgLi4uLi4u Li4uLlcuLi4uLgowMDQwICAwMCAwMCAwMCAwMCAwMCAwMiAwMCAwMSA4NiBh MyAwMCAwMCAwMCAwMyAwMCAwMCAgIC4uLi4uLi4uLi4uLi4uLi4KMDA1MCAg MDAgMDcgMDAgMDAgMDAgMDEgMDAgMDAgMDAgMTggMDAgMDAgMDAgMDAgMDAg MDAgICAuLi4uLi4uLi4uLi4uLi4uCjAwNjAgIDAwIDAwIDAwIDAwIDAwIDUw IDAwIDAwIDAwIDUwIDAwIDAwIDAwIDAxIDAwIDAwICAgLi4uLi5QLi4uUC4u Li4uLgowMDcwICAwMCA1MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAxYyA4YiAyNiAgIC5QLi4uLi4uLi4uLi4uLiYKMDA4MCAgOTYgYTkg MDcgYmYgMGUgZDQgMGEgMDAgMWYgODcgMDUgMDAgMDAgMDAgMDIgOWYgICAu Li4uLi4uLi4uLi4uLi4uCjAwOTAgIDA0IDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAgLi4uLi4uLi4uLi4uLi4uLgow MGEwICAwMCAwMCAwMCAwMCAwMCAwZiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw ZiAzOCAzOSAgIC4uLi4uLi4uLi4uLi4uODkKMDBiMCAgMzkgMzggMzggMjAg MzIgMzYgMzIgMzEgMzQgMzQgMzAgMzAgMzAgMDAgICAgICAgICA5ODggMjYy MTQ0MDAwLgoKTm8uICAgICBUaW1lICAgICAgICBTb3VyY2UgICAgICAgICAg ICAgICAgRGVzdGluYXRpb24gICAgICAgICAgIFByb3RvY29sIEluZm8KICAg ICAxNyAwLjAwMTk5NyAgICAxOTIuMTY4LjIuMTM3ICAgICAgICAgMTkyLjE2 OC4yLjE1MyAgICAgICAgIE5GUyAgICAgIFYzIFdSSVRFIFJlcGx5IChDYWxs IEluIDE2KSBFcnJvcjpORlMzRVJSX0lPCgpGcmFtZSAxNyAoOTQgYnl0ZXMg b24gd2lyZSwgOTQgYnl0ZXMgY2FwdHVyZWQpCiAgICBBcnJpdmFsIFRpbWU6 IEphbiAzMCwgMjAxMCAxMjo0MTo0Ni45MTI4MjUwMDAKICAgIFtUaW1lIGRl bHRhIGZyb20gcHJldmlvdXMgY2FwdHVyZWQgZnJhbWU6IDAuMDAwMjIxMDAw IHNlY29uZHNdCiAgICBbVGltZSBkZWx0YSBmcm9tIHByZXZpb3VzIGRpc3Bs YXllZCBmcmFtZTogMC4wMDAyMjEwMDAgc2Vjb25kc10KICAgIFtUaW1lIHNp bmNlIHJlZmVyZW5jZSBvciBmaXJzdCBmcmFtZTogMC4wMDE5OTcwMDAgc2Vj b25kc10KICAgIEZyYW1lIE51bWJlcjogMTcKICAgIEZyYW1lIExlbmd0aDog OTQgYnl0ZXMKICAgIENhcHR1cmUgTGVuZ3RoOiA5NCBieXRlcwogICAgW0Zy YW1lIGlzIG1hcmtlZDogRmFsc2VdCiAgICBbUHJvdG9jb2xzIGluIGZyYW1l OiBldGg6aXA6dGNwOnJwY10KICAgIFtDb2xvcmluZyBSdWxlIE5hbWU6IFRD UF0KICAgIFtDb2xvcmluZyBSdWxlIFN0cmluZzogdGNwXQpFdGhlcm5ldCBJ SSwgU3JjOiBJbnRlbENvcl9iZjplYjo3YiAoMDA6MTU6MTc6YmY6ZWI6N2Ip LCBEc3Q6IFN1cGVybWljXzdiOjUyOjM0ICgwMDozMDo0ODo3Yjo1MjozNCkK ICAgIERlc3RpbmF0aW9uOiBTdXBlcm1pY183Yjo1MjozNCAoMDA6MzA6NDg6 N2I6NTI6MzQpCiAgICAgICAgQWRkcmVzczogU3VwZXJtaWNfN2I6NTI6MzQg KDAwOjMwOjQ4OjdiOjUyOjM0KQogICAgICAgIC4uLi4gLi4uMCAuLi4uIC4u Li4gLi4uLiAuLi4uID0gSUcgYml0OiBJbmRpdmlkdWFsIGFkZHJlc3MgKHVu aWNhc3QpCiAgICAgICAgLi4uLiAuLjAuIC4uLi4gLi4uLiAuLi4uIC4uLi4g PSBMRyBiaXQ6IEdsb2JhbGx5IHVuaXF1ZSBhZGRyZXNzIChmYWN0b3J5IGRl ZmF1bHQpCiAgICBTb3VyY2U6IEludGVsQ29yX2JmOmViOjdiICgwMDoxNTox NzpiZjplYjo3YikKICAgICAgICBBZGRyZXNzOiBJbnRlbENvcl9iZjplYjo3 YiAoMDA6MTU6MTc6YmY6ZWI6N2IpCiAgICAgICAgLi4uLiAuLi4wIC4uLi4g Li4uLiAuLi4uIC4uLi4gPSBJRyBiaXQ6IEluZGl2aWR1YWwgYWRkcmVzcyAo dW5pY2FzdCkKICAgICAgICAuLi4uIC4uMC4gLi4uLiAuLi4uIC4uLi4gLi4u LiA9IExHIGJpdDogR2xvYmFsbHkgdW5pcXVlIGFkZHJlc3MgKGZhY3Rvcnkg ZGVmYXVsdCkKICAgIFR5cGU6IElQICgweDA4MDApCkludGVybmV0IFByb3Rv Y29sLCBTcmM6IDE5Mi4xNjguMi4xMzcgKDE5Mi4xNjguMi4xMzcpLCBEc3Q6 IDE5Mi4xNjguMi4xNTMgKDE5Mi4xNjguMi4xNTMpCiAgICBWZXJzaW9uOiA0 CiAgICBIZWFkZXIgbGVuZ3RoOiAyMCBieXRlcwogICAgRGlmZmVyZW50aWF0 ZWQgU2VydmljZXMgRmllbGQ6IDB4MDAgKERTQ1AgMHgwMDogRGVmYXVsdDsg RUNOOiAweDAwKQogICAgICAgIDAwMDAgMDAuLiA9IERpZmZlcmVudGlhdGVk IFNlcnZpY2VzIENvZGVwb2ludDogRGVmYXVsdCAoMHgwMCkKICAgICAgICAu Li4uIC4uMC4gPSBFQ04tQ2FwYWJsZSBUcmFuc3BvcnQgKEVDVCk6IDAKICAg ICAgICAuLi4uIC4uLjAgPSBFQ04tQ0U6IDAKICAgIFRvdGFsIExlbmd0aDog ODAKICAgIElkZW50aWZpY2F0aW9uOiAweGI4ZGQgKDQ3MzI1KQogICAgRmxh Z3M6IDB4MDQgKERvbid0IEZyYWdtZW50KQogICAgICAgIDAuLi4gPSBSZXNl cnZlZCBiaXQ6IE5vdCBzZXQKICAgICAgICAuMS4uID0gRG9uJ3QgZnJhZ21l bnQ6IFNldAogICAgICAgIC4uMC4gPSBNb3JlIGZyYWdtZW50czogTm90IHNl dAogICAgRnJhZ21lbnQgb2Zmc2V0OiAwCiAgICBUaW1lIHRvIGxpdmU6IDY0 CiAgICBQcm90b2NvbDogVENQICgweDA2KQogICAgSGVhZGVyIGNoZWNrc3Vt OiAweGZiNTcgW2NvcnJlY3RdCiAgICAgICAgW0dvb2Q6IFRydWVdCiAgICAg ICAgW0JhZCA6IEZhbHNlXQogICAgU291cmNlOiAxOTIuMTY4LjIuMTM3ICgx OTIuMTY4LjIuMTM3KQogICAgRGVzdGluYXRpb246IDE5Mi4xNjguMi4xNTMg KDE5Mi4xNjguMi4xNTMpClRyYW5zbWlzc2lvbiBDb250cm9sIFByb3RvY29s LCBTcmMgUG9ydDogbmZzICgyMDQ5KSwgRHN0IFBvcnQ6IHNzaGVsbCAoNjE0 KSwgU2VxOiAzMjEsIEFjazogMTA4OSwgTGVuOiA0MAogICAgU291cmNlIHBv cnQ6IG5mcyAoMjA0OSkKICAgIERlc3RpbmF0aW9uIHBvcnQ6IHNzaGVsbCAo NjE0KQogICAgU2VxdWVuY2UgbnVtYmVyOiAzMjEgICAgKHJlbGF0aXZlIHNl cXVlbmNlIG51bWJlcikKICAgIFtOZXh0IHNlcXVlbmNlIG51bWJlcjogMzYx ICAgIChyZWxhdGl2ZSBzZXF1ZW5jZSBudW1iZXIpXQogICAgQWNrbm93bGVk Z2VtZW50IG51bWJlcjogMTA4OSAgICAocmVsYXRpdmUgYWNrIG51bWJlcikK ICAgIEhlYWRlciBsZW5ndGg6IDIwIGJ5dGVzCiAgICBGbGFnczogMHgxOCAo UFNILCBBQ0spCiAgICAgICAgMC4uLiAuLi4uID0gQ29uZ2VzdGlvbiBXaW5k b3cgUmVkdWNlZCAoQ1dSKTogTm90IHNldAogICAgICAgIC4wLi4gLi4uLiA9 IEVDTi1FY2hvOiBOb3Qgc2V0CiAgICAgICAgLi4wLiAuLi4uID0gVXJnZW50 OiBOb3Qgc2V0CiAgICAgICAgLi4uMSAuLi4uID0gQWNrbm93bGVkZ21lbnQ6 IFNldAogICAgICAgIC4uLi4gMS4uLiA9IFB1c2g6IFNldAogICAgICAgIC4u Li4gLjAuLiA9IFJlc2V0OiBOb3Qgc2V0CiAgICAgICAgLi4uLiAuLjAuID0g U3luOiBOb3Qgc2V0CiAgICAgICAgLi4uLiAuLi4wID0gRmluOiBOb3Qgc2V0 CiAgICBXaW5kb3cgc2l6ZTogNjU1MzUKICAgIENoZWNrc3VtOiAweDgyZmIg W2NvcnJlY3RdCiAgICAgICAgW0dvb2QgQ2hlY2tzdW06IFRydWVdCiAgICAg ICAgW0JhZCBDaGVja3N1bTogRmFsc2VdCiAgICBbU0VRL0FDSyBhbmFseXNp c10KICAgICAgICBbVGhpcyBpcyBhbiBBQ0sgdG8gdGhlIHNlZ21lbnQgaW4g ZnJhbWU6IDE2XQogICAgICAgIFtUaGUgUlRUIHRvIEFDSyB0aGUgc2VnbWVu dCB3YXM6IDAuMDAwMjIxMDAwIHNlY29uZHNdClJlbW90ZSBQcm9jZWR1cmUg Q2FsbCwgVHlwZTpSZXBseSBYSUQ6MHg1N2RiZDRlNwogICAgRnJhZ21lbnQg aGVhZGVyOiBMYXN0IGZyYWdtZW50LCAzNiBieXRlcwogICAgICAgIDEuLi4g Li4uLiAuLi4uIC4uLi4gLi4uLiAuLi4uIC4uLi4gLi4uLiA9IExhc3QgRnJh Z21lbnQ6IFllcwogICAgICAgIC4wMDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAw MDAwIDAwMTAgMDEwMCA9IEZyYWdtZW50IExlbmd0aDogMzYKICAgIFhJRDog MHg1N2RiZDRlNyAoMTQ3NDAyNDY3OSkKICAgIE1lc3NhZ2UgVHlwZTogUmVw bHkgKDEpCiAgICBbUHJvZ3JhbTogTkZTICgxMDAwMDMpXQogICAgW1Byb2dy YW0gVmVyc2lvbjogM10KICAgIFtQcm9jZWR1cmU6IFdSSVRFICg3KV0KICAg IFJlcGx5IFN0YXRlOiBhY2NlcHRlZCAoMCkKICAgIFtUaGlzIGlzIGEgcmVw bHkgdG8gYSByZXF1ZXN0IGluIGZyYW1lIDE2XQogICAgW1RpbWUgZnJvbSBy ZXF1ZXN0OiAwLjAwMDIyMTAwMCBzZWNvbmRzXQogICAgVmVyaWZpZXIKICAg ICAgICBGbGF2b3I6IEFVVEhfTlVMTCAoMCkKICAgICAgICBMZW5ndGg6IDAK ICAgIEFjY2VwdCBTdGF0ZTogUlBDIGV4ZWN1dGVkIHN1Y2Nlc3NmdWxseSAo MCkKTmV0d29yayBGaWxlIFN5c3RlbSwgV1JJVEUgUmVwbHkgIEVycm9yOk5G UzNFUlJfSU8KICAgIFtQcm9ncmFtIFZlcnNpb246IDNdCiAgICBbVjMgUHJv Y2VkdXJlOiBXUklURSAoNyldCiAgICBTdGF0dXM6IE5GUzNFUlJfSU8gKDUp CiAgICBmaWxlX3djYwogICAgICAgIGJlZm9yZQogICAgICAgICAgICBhdHRy aWJ1dGVzX2ZvbGxvdzogbm8gdmFsdWUgKDApCiAgICAgICAgYWZ0ZXIKICAg ICAgICAgICAgYXR0cmlidXRlc19mb2xsb3c6IG5vIHZhbHVlICgwKQoKMDAw MCAgMDAgMzAgNDggN2IgNTIgMzQgMDAgMTUgMTcgYmYgZWIgN2IgMDggMDAg NDUgMDAgICAuMEh7UjQuLi4uLnsuLkUuCjAwMTAgIDAwIDUwIGI4IGRkIDQw IDAwIDQwIDA2IGZiIDU3IGMwIGE4IDAyIDg5IGMwIGE4ICAgLlAuLkAuQC4u Vy4uLi4uLgowMDIwICAwMiA5OSAwOCAwMSAwMiA2NiBlZSBjMyBiZiA1MiAy MiBkZCAxZCBlZSA1MCAxOCAgIC4uLi4uZi4uLlIiLi4uUC4KMDAzMCAgZmYg ZmYgODIgZmIgMDAgMDAgODAgMDAgMDAgMjQgNTcgZGIgZDQgZTcgMDAgMDAg ICAuLi4uLi4uLi4kVy4uLi4uCjAwNDAgIDAwIDAxIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAgLi4uLi4uLi4uLi4uLi4u LgowMDUwICAwMCAwMCAwMCAwMCAwMCAwNSAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAgICAgICAgIC4uLi4uLi4uLi4uLi4uCgpOby4gICAgIFRpbWUgICAg ICAgIFNvdXJjZSAgICAgICAgICAgICAgICBEZXN0aW5hdGlvbiAgICAgICAg ICAgUHJvdG9jb2wgSW5mbwogICAgIDE4IDAuMDAyMDI2ICAgIDE5Mi4xNjgu Mi4xNTMgICAgICAgICAxOTIuMTY4LjIuMTM3ICAgICAgICAgTkZTICAgICAg VjMgV1JJVEUgQ2FsbCAoUmVwbHkgSW4gMTkpLCBGSDoweDgxMDYwMmZjIE9m ZnNldDowIExlbjoxNSBVTlNUQUJMRQoKRnJhbWUgMTggKDE5MCBieXRlcyBv biB3aXJlLCAxOTAgYnl0ZXMgY2FwdHVyZWQpCiAgICBBcnJpdmFsIFRpbWU6 IEphbiAzMCwgMjAxMCAxMjo0MTo0Ni45MTI4NTQwMDAKICAgIFtUaW1lIGRl bHRhIGZyb20gcHJldmlvdXMgY2FwdHVyZWQgZnJhbWU6IDAuMDAwMDI5MDAw IHNlY29uZHNdCiAgICBbVGltZSBkZWx0YSBmcm9tIHByZXZpb3VzIGRpc3Bs YXllZCBmcmFtZTogMC4wMDAwMjkwMDAgc2Vjb25kc10KICAgIFtUaW1lIHNp bmNlIHJlZmVyZW5jZSBvciBmaXJzdCBmcmFtZTogMC4wMDIwMjYwMDAgc2Vj b25kc10KICAgIEZyYW1lIE51bWJlcjogMTgKICAgIEZyYW1lIExlbmd0aDog MTkwIGJ5dGVzCiAgICBDYXB0dXJlIExlbmd0aDogMTkwIGJ5dGVzCiAgICBb RnJhbWUgaXMgbWFya2VkOiBGYWxzZV0KICAgIFtQcm90b2NvbHMgaW4gZnJh bWU6IGV0aDppcDp0Y3A6cnBjOm5mc10KICAgIFtDb2xvcmluZyBSdWxlIE5h bWU6IENoZWNrc3VtIEVycm9yc10KICAgIFtDb2xvcmluZyBSdWxlIFN0cmlu ZzogY2RwLmNoZWNrc3VtX2JhZD09MSB8fCBlZHAuY2hlY2tzdW1fYmFkPT0x IHx8IGlwLmNoZWNrc3VtX2JhZD09MSB8fCB0Y3AuY2hlY2tzdW1fYmFkPT0x IHx8IHVkcC5jaGVja3N1bV9iYWQ9PTFdCkV0aGVybmV0IElJLCBTcmM6IFN1 cGVybWljXzdiOjUyOjM0ICgwMDozMDo0ODo3Yjo1MjozNCksIERzdDogSW50 ZWxDb3JfYmY6ZWI6N2IgKDAwOjE1OjE3OmJmOmViOjdiKQogICAgRGVzdGlu YXRpb246IEludGVsQ29yX2JmOmViOjdiICgwMDoxNToxNzpiZjplYjo3YikK ICAgICAgICBBZGRyZXNzOiBJbnRlbENvcl9iZjplYjo3YiAoMDA6MTU6MTc6 YmY6ZWI6N2IpCiAgICAgICAgLi4uLiAuLi4wIC4uLi4gLi4uLiAuLi4uIC4u Li4gPSBJRyBiaXQ6IEluZGl2aWR1YWwgYWRkcmVzcyAodW5pY2FzdCkKICAg ICAgICAuLi4uIC4uMC4gLi4uLiAuLi4uIC4uLi4gLi4uLiA9IExHIGJpdDog R2xvYmFsbHkgdW5pcXVlIGFkZHJlc3MgKGZhY3RvcnkgZGVmYXVsdCkKICAg IFNvdXJjZTogU3VwZXJtaWNfN2I6NTI6MzQgKDAwOjMwOjQ4OjdiOjUyOjM0 KQogICAgICAgIEFkZHJlc3M6IFN1cGVybWljXzdiOjUyOjM0ICgwMDozMDo0 ODo3Yjo1MjozNCkKICAgICAgICAuLi4uIC4uLjAgLi4uLiAuLi4uIC4uLi4g Li4uLiA9IElHIGJpdDogSW5kaXZpZHVhbCBhZGRyZXNzICh1bmljYXN0KQog ICAgICAgIC4uLi4gLi4wLiAuLi4uIC4uLi4gLi4uLiAuLi4uID0gTEcgYml0 OiBHbG9iYWxseSB1bmlxdWUgYWRkcmVzcyAoZmFjdG9yeSBkZWZhdWx0KQog ICAgVHlwZTogSVAgKDB4MDgwMCkKSW50ZXJuZXQgUHJvdG9jb2wsIFNyYzog MTkyLjE2OC4yLjE1MyAoMTkyLjE2OC4yLjE1MyksIERzdDogMTkyLjE2OC4y LjEzNyAoMTkyLjE2OC4yLjEzNykKICAgIFZlcnNpb246IDQKICAgIEhlYWRl ciBsZW5ndGg6IDIwIGJ5dGVzCiAgICBEaWZmZXJlbnRpYXRlZCBTZXJ2aWNl cyBGaWVsZDogMHgwMCAoRFNDUCAweDAwOiBEZWZhdWx0OyBFQ046IDB4MDAp CiAgICAgICAgMDAwMCAwMC4uID0gRGlmZmVyZW50aWF0ZWQgU2VydmljZXMg Q29kZXBvaW50OiBEZWZhdWx0ICgweDAwKQogICAgICAgIC4uLi4gLi4wLiA9 IEVDTi1DYXBhYmxlIFRyYW5zcG9ydCAoRUNUKTogMAogICAgICAgIC4uLi4g Li4uMCA9IEVDTi1DRTogMAogICAgVG90YWwgTGVuZ3RoOiAxNzYKICAgIElk ZW50aWZpY2F0aW9uOiAweGY4YjIgKDYzNjY2KQogICAgRmxhZ3M6IDB4MDQg KERvbid0IEZyYWdtZW50KQogICAgICAgIDAuLi4gPSBSZXNlcnZlZCBiaXQ6 IE5vdCBzZXQKICAgICAgICAuMS4uID0gRG9uJ3QgZnJhZ21lbnQ6IFNldAog ICAgICAgIC4uMC4gPSBNb3JlIGZyYWdtZW50czogTm90IHNldAogICAgRnJh Z21lbnQgb2Zmc2V0OiAwCiAgICBUaW1lIHRvIGxpdmU6IDY0CiAgICBQcm90 b2NvbDogVENQICgweDA2KQogICAgSGVhZGVyIGNoZWNrc3VtOiAweGJiMjIg W2NvcnJlY3RdCiAgICAgICAgW0dvb2Q6IFRydWVdCiAgICAgICAgW0JhZCA6 IEZhbHNlXQogICAgU291cmNlOiAxOTIuMTY4LjIuMTUzICgxOTIuMTY4LjIu MTUzKQogICAgRGVzdGluYXRpb246IDE5Mi4xNjguMi4xMzcgKDE5Mi4xNjgu Mi4xMzcpClRyYW5zbWlzc2lvbiBDb250cm9sIFByb3RvY29sLCBTcmMgUG9y dDogc3NoZWxsICg2MTQpLCBEc3QgUG9ydDogbmZzICgyMDQ5KSwgU2VxOiAx MDg5LCBBY2s6IDM2MSwgTGVuOiAxMzYKICAgIFNvdXJjZSBwb3J0OiBzc2hl bGwgKDYxNCkKICAgIERlc3RpbmF0aW9uIHBvcnQ6IG5mcyAoMjA0OSkKICAg IFNlcXVlbmNlIG51bWJlcjogMTA4OSAgICAocmVsYXRpdmUgc2VxdWVuY2Ug bnVtYmVyKQogICAgW05leHQgc2VxdWVuY2UgbnVtYmVyOiAxMjI1ICAgIChy ZWxhdGl2ZSBzZXF1ZW5jZSBudW1iZXIpXQogICAgQWNrbm93bGVkZ2VtZW50 IG51bWJlcjogMzYxICAgIChyZWxhdGl2ZSBhY2sgbnVtYmVyKQogICAgSGVh ZGVyIGxlbmd0aDogMjAgYnl0ZXMKICAgIEZsYWdzOiAweDE4IChQU0gsIEFD SykKICAgICAgICAwLi4uIC4uLi4gPSBDb25nZXN0aW9uIFdpbmRvdyBSZWR1 Y2VkIChDV1IpOiBOb3Qgc2V0CiAgICAgICAgLjAuLiAuLi4uID0gRUNOLUVj aG86IE5vdCBzZXQKICAgICAgICAuLjAuIC4uLi4gPSBVcmdlbnQ6IE5vdCBz ZXQKICAgICAgICAuLi4xIC4uLi4gPSBBY2tub3dsZWRnbWVudDogU2V0CiAg ICAgICAgLi4uLiAxLi4uID0gUHVzaDogU2V0CiAgICAgICAgLi4uLiAuMC4u ID0gUmVzZXQ6IE5vdCBzZXQKICAgICAgICAuLi4uIC4uMC4gPSBTeW46IE5v dCBzZXQKICAgICAgICAuLi4uIC4uLjAgPSBGaW46IE5vdCBzZXQKICAgIFdp bmRvdyBzaXplOiA2NTUzNQogICAgQ2hlY2tzdW06IDB4ODcxNSBbaW5jb3Jy ZWN0LCBzaG91bGQgYmUgMHhlYTNjIChtYXliZSBjYXVzZWQgYnkgIlRDUCBj aGVja3N1bSBvZmZsb2FkIj8pXQogICAgICAgIFtHb29kIENoZWNrc3VtOiBG YWxzZV0KICAgICAgICBbQmFkIENoZWNrc3VtOiBUcnVlXQogICAgW1NFUS9B Q0sgYW5hbHlzaXNdCiAgICAgICAgW1RoaXMgaXMgYW4gQUNLIHRvIHRoZSBz ZWdtZW50IGluIGZyYW1lOiAxN10KICAgICAgICBbVGhlIFJUVCB0byBBQ0sg dGhlIHNlZ21lbnQgd2FzOiAwLjAwMDAyOTAwMCBzZWNvbmRzXQpSZW1vdGUg UHJvY2VkdXJlIENhbGwsIFR5cGU6Q2FsbCBYSUQ6MHg1N2RiZDRlOAogICAg RnJhZ21lbnQgaGVhZGVyOiBMYXN0IGZyYWdtZW50LCAxMzIgYnl0ZXMKICAg ICAgICAxLi4uIC4uLi4gLi4uLiAuLi4uIC4uLi4gLi4uLiAuLi4uIC4uLi4g PSBMYXN0IEZyYWdtZW50OiBZZXMKICAgICAgICAuMDAwIDAwMDAgMDAwMCAw MDAwIDAwMDAgMDAwMCAxMDAwIDAxMDAgPSBGcmFnbWVudCBMZW5ndGg6IDEz MgogICAgWElEOiAweDU3ZGJkNGU4ICgxNDc0MDI0NjgwKQogICAgTWVzc2Fn ZSBUeXBlOiBDYWxsICgwKQogICAgUlBDIFZlcnNpb246IDIKICAgIFByb2dy YW06IE5GUyAoMTAwMDAzKQogICAgUHJvZ3JhbSBWZXJzaW9uOiAzCiAgICBQ cm9jZWR1cmU6IFdSSVRFICg3KQogICAgW1RoZSByZXBseSB0byB0aGlzIHJl cXVlc3QgaXMgaW4gZnJhbWUgMTldCiAgICBDcmVkZW50aWFscwogICAgICAg IEZsYXZvcjogQVVUSF9VTklYICgxKQogICAgICAgIExlbmd0aDogMjQKICAg ICAgICBTdGFtcDogMHgwMDAwMDAwMAogICAgICAgIE1hY2hpbmUgTmFtZTog PEVNUFRZPgogICAgICAgICAgICBsZW5ndGg6IDAKICAgICAgICAgICAgY29u dGVudHM6IDxFTVBUWT4KICAgICAgICBVSUQ6IDgwCiAgICAgICAgR0lEOiA4 MAogICAgICAgIEF1eGlsaWFyeSBHSURzCiAgICAgICAgICAgIEdJRDogODAK ICAgIFZlcmlmaWVyCiAgICAgICAgRmxhdm9yOiBBVVRIX05VTEwgKDApCiAg ICAgICAgTGVuZ3RoOiAwCk5ldHdvcmsgRmlsZSBTeXN0ZW0sIFdSSVRFIENh bGwgRkg6MHg4MTA2MDJmYyBPZmZzZXQ6MCBMZW46MTUgVU5TVEFCTEUKICAg IFtQcm9ncmFtIFZlcnNpb246IDNdCiAgICBbVjMgUHJvY2VkdXJlOiBXUklU RSAoNyldCiAgICBmaWxlCiAgICAgICAgbGVuZ3RoOiAyOAogICAgICAgIFto YXNoOiAweDgxMDYwMmZjXQogICAgICAgIGRlY29kZSB0eXBlIGFzOiB1bmtu b3duCiAgICAgICAgZmlsZWhhbmRsZTogOEIyNjk2QTkwN0JGMEVENDBBMDAx Rjg3MDUwMDAwMDAwMjlGMDQwMDAwMDAwMDAwLi4uCiAgICBvZmZzZXQ6IDAK ICAgIGNvdW50OiAxNQogICAgU3RhYmxlOiBVTlNUQUJMRSAoMCkKICAgIERh dGE6IDxEQVRBPgogICAgICAgIGxlbmd0aDogMTUKICAgICAgICBjb250ZW50 czogPERBVEE+CiAgICAgICAgZmlsbCBieXRlczogb3BhcXVlIGRhdGEKCjAw MDAgIDAwIDE1IDE3IGJmIGViIDdiIDAwIDMwIDQ4IDdiIDUyIDM0IDA4IDAw IDQ1IDAwICAgLi4uLi57LjBIe1I0Li5FLgowMDEwICAwMCBiMCBmOCBiMiA0 MCAwMCA0MCAwNiBiYiAyMiBjMCBhOCAwMiA5OSBjMCBhOCAgIC4uLi5ALkAu LiIuLi4uLi4KMDAyMCAgMDIgODkgMDIgNjYgMDggMDEgMjIgZGQgMWQgZWUg ZWUgYzMgYmYgN2EgNTAgMTggICAuLi5mLi4iLi4uLi4uelAuCjAwMzAgIGZm IGZmIDg3IDE1IDAwIDAwIDgwIDAwIDAwIDg0IDU3IGRiIGQ0IGU4IDAwIDAw ICAgLi4uLi4uLi4uLlcuLi4uLgowMDQwICAwMCAwMCAwMCAwMCAwMCAwMiAw MCAwMSA4NiBhMyAwMCAwMCAwMCAwMyAwMCAwMCAgIC4uLi4uLi4uLi4uLi4u Li4KMDA1MCAgMDAgMDcgMDAgMDAgMDAgMDEgMDAgMDAgMDAgMTggMDAgMDAg MDAgMDAgMDAgMDAgICAuLi4uLi4uLi4uLi4uLi4uCjAwNjAgIDAwIDAwIDAw IDAwIDAwIDUwIDAwIDAwIDAwIDUwIDAwIDAwIDAwIDAxIDAwIDAwICAgLi4u Li5QLi4uUC4uLi4uLgowMDcwICAwMCA1MCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAxYyA4YiAyNiAgIC5QLi4uLi4uLi4uLi4uLiYKMDA4 MCAgOTYgYTkgMDcgYmYgMGUgZDQgMGEgMDAgMWYgODcgMDUgMDAgMDAgMDAg MDIgOWYgICAuLi4uLi4uLi4uLi4uLi4uCjAwOTAgIDA0IDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAgLi4uLi4uLi4u Li4uLi4uLgowMGEwICAwMCAwMCAwMCAwMCAwMCAwZiAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwZiAzOCAzOSAgIC4uLi4uLi4uLi4uLi4uODkKMDBiMCAgMzkg MzggMzggMjAgMzIgMzYgMzIgMzEgMzQgMzQgMzAgMzAgMzAgMDAgICAgICAg ICA5ODggMjYyMTQ0MDAwLgoKTm8uICAgICBUaW1lICAgICAgICBTb3VyY2Ug ICAgICAgICAgICAgICAgRGVzdGluYXRpb24gICAgICAgICAgIFByb3RvY29s IEluZm8KICAgICAxOSAwLjAwMjI0NiAgICAxOTIuMTY4LjIuMTM3ICAgICAg ICAgMTkyLjE2OC4yLjE1MyAgICAgICAgIE5GUyAgICAgIFYzIFdSSVRFIFJl cGx5IChDYWxsIEluIDE4KSBFcnJvcjpORlMzRVJSX0lPCgpGcmFtZSAxOSAo OTQgYnl0ZXMgb24gd2lyZSwgOTQgYnl0ZXMgY2FwdHVyZWQpCiAgICBBcnJp dmFsIFRpbWU6IEphbiAzMCwgMjAxMCAxMjo0MTo0Ni45MTMwNzQwMDAKICAg IFtUaW1lIGRlbHRhIGZyb20gcHJldmlvdXMgY2FwdHVyZWQgZnJhbWU6IDAu MDAwMjIwMDAwIHNlY29uZHNdCiAgICBbVGltZSBkZWx0YSBmcm9tIHByZXZp b3VzIGRpc3BsYXllZCBmcmFtZTogMC4wMDAyMjAwMDAgc2Vjb25kc10KICAg IFtUaW1lIHNpbmNlIHJlZmVyZW5jZSBvciBmaXJzdCBmcmFtZTogMC4wMDIy NDYwMDAgc2Vjb25kc10KICAgIEZyYW1lIE51bWJlcjogMTkKICAgIEZyYW1l IExlbmd0aDogOTQgYnl0ZXMKICAgIENhcHR1cmUgTGVuZ3RoOiA5NCBieXRl cwogICAgW0ZyYW1lIGlzIG1hcmtlZDogRmFsc2VdCiAgICBbUHJvdG9jb2xz IGluIGZyYW1lOiBldGg6aXA6dGNwOnJwY10KICAgIFtDb2xvcmluZyBSdWxl IE5hbWU6IFRDUF0KICAgIFtDb2xvcmluZyBSdWxlIFN0cmluZzogdGNwXQpF dGhlcm5ldCBJSSwgU3JjOiBJbnRlbENvcl9iZjplYjo3YiAoMDA6MTU6MTc6 YmY6ZWI6N2IpLCBEc3Q6IFN1cGVybWljXzdiOjUyOjM0ICgwMDozMDo0ODo3 Yjo1MjozNCkKICAgIERlc3RpbmF0aW9uOiBTdXBlcm1pY183Yjo1MjozNCAo MDA6MzA6NDg6N2I6NTI6MzQpCiAgICAgICAgQWRkcmVzczogU3VwZXJtaWNf N2I6NTI6MzQgKDAwOjMwOjQ4OjdiOjUyOjM0KQogICAgICAgIC4uLi4gLi4u MCAuLi4uIC4uLi4gLi4uLiAuLi4uID0gSUcgYml0OiBJbmRpdmlkdWFsIGFk ZHJlc3MgKHVuaWNhc3QpCiAgICAgICAgLi4uLiAuLjAuIC4uLi4gLi4uLiAu Li4uIC4uLi4gPSBMRyBiaXQ6IEdsb2JhbGx5IHVuaXF1ZSBhZGRyZXNzIChm YWN0b3J5IGRlZmF1bHQpCiAgICBTb3VyY2U6IEludGVsQ29yX2JmOmViOjdi ICgwMDoxNToxNzpiZjplYjo3YikKICAgICAgICBBZGRyZXNzOiBJbnRlbENv cl9iZjplYjo3YiAoMDA6MTU6MTc6YmY6ZWI6N2IpCiAgICAgICAgLi4uLiAu Li4wIC4uLi4gLi4uLiAuLi4uIC4uLi4gPSBJRyBiaXQ6IEluZGl2aWR1YWwg YWRkcmVzcyAodW5pY2FzdCkKICAgICAgICAuLi4uIC4uMC4gLi4uLiAuLi4u IC4uLi4gLi4uLiA9IExHIGJpdDogR2xvYmFsbHkgdW5pcXVlIGFkZHJlc3Mg KGZhY3RvcnkgZGVmYXVsdCkKICAgIFR5cGU6IElQICgweDA4MDApCkludGVy bmV0IFByb3RvY29sLCBTcmM6IDE5Mi4xNjguMi4xMzcgKDE5Mi4xNjguMi4x MzcpLCBEc3Q6IDE5Mi4xNjguMi4xNTMgKDE5Mi4xNjguMi4xNTMpCiAgICBW ZXJzaW9uOiA0CiAgICBIZWFkZXIgbGVuZ3RoOiAyMCBieXRlcwogICAgRGlm ZmVyZW50aWF0ZWQgU2VydmljZXMgRmllbGQ6IDB4MDAgKERTQ1AgMHgwMDog RGVmYXVsdDsgRUNOOiAweDAwKQogICAgICAgIDAwMDAgMDAuLiA9IERpZmZl cmVudGlhdGVkIFNlcnZpY2VzIENvZGVwb2ludDogRGVmYXVsdCAoMHgwMCkK ICAgICAgICAuLi4uIC4uMC4gPSBFQ04tQ2FwYWJsZSBUcmFuc3BvcnQgKEVD VCk6IDAKICAgICAgICAuLi4uIC4uLjAgPSBFQ04tQ0U6IDAKICAgIFRvdGFs IExlbmd0aDogODAKICAgIElkZW50aWZpY2F0aW9uOiAweGI4ZGUgKDQ3MzI2 KQogICAgRmxhZ3M6IDB4MDQgKERvbid0IEZyYWdtZW50KQogICAgICAgIDAu Li4gPSBSZXNlcnZlZCBiaXQ6IE5vdCBzZXQKICAgICAgICAuMS4uID0gRG9u J3QgZnJhZ21lbnQ6IFNldAogICAgICAgIC4uMC4gPSBNb3JlIGZyYWdtZW50 czogTm90IHNldAogICAgRnJhZ21lbnQgb2Zmc2V0OiAwCiAgICBUaW1lIHRv IGxpdmU6IDY0CiAgICBQcm90b2NvbDogVENQICgweDA2KQogICAgSGVhZGVy IGNoZWNrc3VtOiAweGZiNTYgW2NvcnJlY3RdCiAgICAgICAgW0dvb2Q6IFRy dWVdCiAgICAgICAgW0JhZCA6IEZhbHNlXQogICAgU291cmNlOiAxOTIuMTY4 LjIuMTM3ICgxOTIuMTY4LjIuMTM3KQogICAgRGVzdGluYXRpb246IDE5Mi4x NjguMi4xNTMgKDE5Mi4xNjguMi4xNTMpClRyYW5zbWlzc2lvbiBDb250cm9s IFByb3RvY29sLCBTcmMgUG9ydDogbmZzICgyMDQ5KSwgRHN0IFBvcnQ6IHNz aGVsbCAoNjE0KSwgU2VxOiAzNjEsIEFjazogMTIyNSwgTGVuOiA0MAogICAg U291cmNlIHBvcnQ6IG5mcyAoMjA0OSkKICAgIERlc3RpbmF0aW9uIHBvcnQ6 IHNzaGVsbCAoNjE0KQogICAgU2VxdWVuY2UgbnVtYmVyOiAzNjEgICAgKHJl bGF0aXZlIHNlcXVlbmNlIG51bWJlcikKICAgIFtOZXh0IHNlcXVlbmNlIG51 bWJlcjogNDAxICAgIChyZWxhdGl2ZSBzZXF1ZW5jZSBudW1iZXIpXQogICAg QWNrbm93bGVkZ2VtZW50IG51bWJlcjogMTIyNSAgICAocmVsYXRpdmUgYWNr IG51bWJlcikKICAgIEhlYWRlciBsZW5ndGg6IDIwIGJ5dGVzCiAgICBGbGFn czogMHgxOCAoUFNILCBBQ0spCiAgICAgICAgMC4uLiAuLi4uID0gQ29uZ2Vz dGlvbiBXaW5kb3cgUmVkdWNlZCAoQ1dSKTogTm90IHNldAogICAgICAgIC4w Li4gLi4uLiA9IEVDTi1FY2hvOiBOb3Qgc2V0CiAgICAgICAgLi4wLiAuLi4u ID0gVXJnZW50OiBOb3Qgc2V0CiAgICAgICAgLi4uMSAuLi4uID0gQWNrbm93 bGVkZ21lbnQ6IFNldAogICAgICAgIC4uLi4gMS4uLiA9IFB1c2g6IFNldAog ICAgICAgIC4uLi4gLjAuLiA9IFJlc2V0OiBOb3Qgc2V0CiAgICAgICAgLi4u LiAuLjAuID0gU3luOiBOb3Qgc2V0CiAgICAgICAgLi4uLiAuLi4wID0gRmlu OiBOb3Qgc2V0CiAgICBXaW5kb3cgc2l6ZTogNjU1MzUKICAgIENoZWNrc3Vt OiAweDgyNGEgW2NvcnJlY3RdCiAgICAgICAgW0dvb2QgQ2hlY2tzdW06IFRy dWVdCiAgICAgICAgW0JhZCBDaGVja3N1bTogRmFsc2VdCiAgICBbU0VRL0FD SyBhbmFseXNpc10KICAgICAgICBbVGhpcyBpcyBhbiBBQ0sgdG8gdGhlIHNl Z21lbnQgaW4gZnJhbWU6IDE4XQogICAgICAgIFtUaGUgUlRUIHRvIEFDSyB0 aGUgc2VnbWVudCB3YXM6IDAuMDAwMjIwMDAwIHNlY29uZHNdClJlbW90ZSBQ cm9jZWR1cmUgQ2FsbCwgVHlwZTpSZXBseSBYSUQ6MHg1N2RiZDRlOAogICAg RnJhZ21lbnQgaGVhZGVyOiBMYXN0IGZyYWdtZW50LCAzNiBieXRlcwogICAg ICAgIDEuLi4gLi4uLiAuLi4uIC4uLi4gLi4uLiAuLi4uIC4uLi4gLi4uLiA9 IExhc3QgRnJhZ21lbnQ6IFllcwogICAgICAgIC4wMDAgMDAwMCAwMDAwIDAw MDAgMDAwMCAwMDAwIDAwMTAgMDEwMCA9IEZyYWdtZW50IExlbmd0aDogMzYK ICAgIFhJRDogMHg1N2RiZDRlOCAoMTQ3NDAyNDY4MCkKICAgIE1lc3NhZ2Ug VHlwZTogUmVwbHkgKDEpCiAgICBbUHJvZ3JhbTogTkZTICgxMDAwMDMpXQog ICAgW1Byb2dyYW0gVmVyc2lvbjogM10KICAgIFtQcm9jZWR1cmU6IFdSSVRF ICg3KV0KICAgIFJlcGx5IFN0YXRlOiBhY2NlcHRlZCAoMCkKICAgIFtUaGlz IGlzIGEgcmVwbHkgdG8gYSByZXF1ZXN0IGluIGZyYW1lIDE4XQogICAgW1Rp bWUgZnJvbSByZXF1ZXN0OiAwLjAwMDIyMDAwMCBzZWNvbmRzXQogICAgVmVy aWZpZXIKICAgICAgICBGbGF2b3I6IEFVVEhfTlVMTCAoMCkKICAgICAgICBM ZW5ndGg6IDAKICAgIEFjY2VwdCBTdGF0ZTogUlBDIGV4ZWN1dGVkIHN1Y2Nl c3NmdWxseSAoMCkKTmV0d29yayBGaWxlIFN5c3RlbSwgV1JJVEUgUmVwbHkg IEVycm9yOk5GUzNFUlJfSU8KICAgIFtQcm9ncmFtIFZlcnNpb246IDNdCiAg ICBbVjMgUHJvY2VkdXJlOiBXUklURSAoNyldCiAgICBTdGF0dXM6IE5GUzNF UlJfSU8gKDUpCiAgICBmaWxlX3djYwogICAgICAgIGJlZm9yZQogICAgICAg ICAgICBhdHRyaWJ1dGVzX2ZvbGxvdzogbm8gdmFsdWUgKDApCiAgICAgICAg YWZ0ZXIKICAgICAgICAgICAgYXR0cmlidXRlc19mb2xsb3c6IG5vIHZhbHVl ICgwKQoKMDAwMCAgMDAgMzAgNDggN2IgNTIgMzQgMDAgMTUgMTcgYmYgZWIg N2IgMDggMDAgNDUgMDAgICAuMEh7UjQuLi4uLnsuLkUuCjAwMTAgIDAwIDUw IGI4IGRlIDQwIDAwIDQwIDA2IGZiIDU2IGMwIGE4IDAyIDg5IGMwIGE4ICAg LlAuLkAuQC4uVi4uLi4uLgowMDIwICAwMiA5OSAwOCAwMSAwMiA2NiBlZSBj MyBiZiA3YSAyMiBkZCAxZSA3NiA1MCAxOCAgIC4uLi4uZi4uLnoiLi52UC4K MDAzMCAgZmYgZmYgODIgNGEgMDAgMDAgODAgMDAgMDAgMjQgNTcgZGIgZDQg ZTggMDAgMDAgICAuLi5KLi4uLi4kVy4uLi4uCjAwNDAgIDAwIDAxIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAgLi4uLi4u Li4uLi4uLi4uLgowMDUwICAwMCAwMCAwMCAwMCAwMCAwNSAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAgICAgICAgIC4uLi4uLi4uLi4uLi4uCgpOby4gICAg IFRpbWUgICAgICAgIFNvdXJjZSAgICAgICAgICAgICAgICBEZXN0aW5hdGlv biAgICAgICAgICAgUHJvdG9jb2wgSW5mbwogICAgIDIwIDAuMDAyMjc2ICAg IDE5Mi4xNjguMi4xNTMgICAgICAgICAxOTIuMTY4LjIuMTM3ICAgICAgICAg TkZTICAgICAgVjMgV1JJVEUgQ2FsbCAoUmVwbHkgSW4gMjEpLCBGSDoweDgx MDYwMmZjIE9mZnNldDowIExlbjoxNSBVTlNUQUJMRQoKRnJhbWUgMjAgKDE5 MCBieXRlcyBvbiB3aXJlLCAxOTAgYnl0ZXMgY2FwdHVyZWQpCiAgICBBcnJp dmFsIFRpbWU6IEphbiAzMCwgMjAxMCAxMjo0MTo0Ni45MTMxMDQwMDAKICAg IFtUaW1lIGRlbHRhIGZyb20gcHJldmlvdXMgY2FwdHVyZWQgZnJhbWU6IDAu MDAwMDMwMDAwIHNlY29uZHNdCiAgICBbVGltZSBkZWx0YSBmcm9tIHByZXZp b3VzIGRpc3BsYXllZCBmcmFtZTogMC4wMDAwMzAwMDAgc2Vjb25kc10KICAg IFtUaW1lIHNpbmNlIHJlZmVyZW5jZSBvciBmaXJzdCBmcmFtZTogMC4wMDIy NzYwMDAgc2Vjb25kc10KICAgIEZyYW1lIE51bWJlcjogMjAKICAgIEZyYW1l IExlbmd0aDogMTkwIGJ5dGVzCiAgICBDYXB0dXJlIExlbmd0aDogMTkwIGJ5 dGVzCiAgICBbRnJhbWUgaXMgbWFya2VkOiBGYWxzZV0KICAgIFtQcm90b2Nv bHMgaW4gZnJhbWU6IGV0aDppcDp0Y3A6cnBjOm5mc10KICAgIFtDb2xvcmlu ZyBSdWxlIE5hbWU6IENoZWNrc3VtIEVycm9yc10KICAgIFtDb2xvcmluZyBS dWxlIFN0cmluZzogY2RwLmNoZWNrc3VtX2JhZD09MSB8fCBlZHAuY2hlY2tz dW1fYmFkPT0xIHx8IGlwLmNoZWNrc3VtX2JhZD09MSB8fCB0Y3AuY2hlY2tz dW1fYmFkPT0xIHx8IHVkcC5jaGVja3N1bV9iYWQ9PTFdCkV0aGVybmV0IElJ LCBTcmM6IFN1cGVybWljXzdiOjUyOjM0ICgwMDozMDo0ODo3Yjo1MjozNCks IERzdDogSW50ZWxDb3JfYmY6ZWI6N2IgKDAwOjE1OjE3OmJmOmViOjdiKQog ICAgRGVzdGluYXRpb246IEludGVsQ29yX2JmOmViOjdiICgwMDoxNToxNzpi ZjplYjo3YikKICAgICAgICBBZGRyZXNzOiBJbnRlbENvcl9iZjplYjo3YiAo MDA6MTU6MTc6YmY6ZWI6N2IpCiAgICAgICAgLi4uLiAuLi4wIC4uLi4gLi4u LiAuLi4uIC4uLi4gPSBJRyBiaXQ6IEluZGl2aWR1YWwgYWRkcmVzcyAodW5p Y2FzdCkKICAgICAgICAuLi4uIC4uMC4gLi4uLiAuLi4uIC4uLi4gLi4uLiA9 IExHIGJpdDogR2xvYmFsbHkgdW5pcXVlIGFkZHJlc3MgKGZhY3RvcnkgZGVm YXVsdCkKICAgIFNvdXJjZTogU3VwZXJtaWNfN2I6NTI6MzQgKDAwOjMwOjQ4 OjdiOjUyOjM0KQogICAgICAgIEFkZHJlc3M6IFN1cGVybWljXzdiOjUyOjM0 ICgwMDozMDo0ODo3Yjo1MjozNCkKICAgICAgICAuLi4uIC4uLjAgLi4uLiAu Li4uIC4uLi4gLi4uLiA9IElHIGJpdDogSW5kaXZpZHVhbCBhZGRyZXNzICh1 bmljYXN0KQogICAgICAgIC4uLi4gLi4wLiAuLi4uIC4uLi4gLi4uLiAuLi4u ID0gTEcgYml0OiBHbG9iYWxseSB1bmlxdWUgYWRkcmVzcyAoZmFjdG9yeSBk ZWZhdWx0KQogICAgVHlwZTogSVAgKDB4MDgwMCkKSW50ZXJuZXQgUHJvdG9j b2wsIFNyYzogMTkyLjE2OC4yLjE1MyAoMTkyLjE2OC4yLjE1MyksIERzdDog MTkyLjE2OC4yLjEzNyAoMTkyLjE2OC4yLjEzNykKICAgIFZlcnNpb246IDQK ICAgIEhlYWRlciBsZW5ndGg6IDIwIGJ5dGVzCiAgICBEaWZmZXJlbnRpYXRl ZCBTZXJ2aWNlcyBGaWVsZDogMHgwMCAoRFNDUCAweDAwOiBEZWZhdWx0OyBF Q046IDB4MDApCiAgICAgICAgMDAwMCAwMC4uID0gRGlmZmVyZW50aWF0ZWQg U2VydmljZXMgQ29kZXBvaW50OiBEZWZhdWx0ICgweDAwKQogICAgICAgIC4u Li4gLi4wLiA9IEVDTi1DYXBhYmxlIFRyYW5zcG9ydCAoRUNUKTogMAogICAg ICAgIC4uLi4gLi4uMCA9IEVDTi1DRTogMAogICAgVG90YWwgTGVuZ3RoOiAx NzYKICAgIElkZW50aWZpY2F0aW9uOiAweGY4YjMgKDYzNjY3KQogICAgRmxh Z3M6IDB4MDQgKERvbid0IEZyYWdtZW50KQogICAgICAgIDAuLi4gPSBSZXNl cnZlZCBiaXQ6IE5vdCBzZXQKICAgICAgICAuMS4uID0gRG9uJ3QgZnJhZ21l bnQ6IFNldAogICAgICAgIC4uMC4gPSBNb3JlIGZyYWdtZW50czogTm90IHNl dAogICAgRnJhZ21lbnQgb2Zmc2V0OiAwCiAgICBUaW1lIHRvIGxpdmU6IDY0 CiAgICBQcm90b2NvbDogVENQICgweDA2KQogICAgSGVhZGVyIGNoZWNrc3Vt OiAweGJiMjEgW2NvcnJlY3RdCiAgICAgICAgW0dvb2Q6IFRydWVdCiAgICAg ICAgW0JhZCA6IEZhbHNlXQogICAgU291cmNlOiAxOTIuMTY4LjIuMTUzICgx OTIuMTY4LjIuMTUzKQogICAgRGVzdGluYXRpb246IDE5Mi4xNjguMi4xMzcg KDE5Mi4xNjguMi4xMzcpClRyYW5zbWlzc2lvbiBDb250cm9sIFByb3RvY29s LCBTcmMgUG9ydDogc3NoZWxsICg2MTQpLCBEc3QgUG9ydDogbmZzICgyMDQ5 KSwgU2VxOiAxMjI1LCBBY2s6IDQwMSwgTGVuOiAxMzYKICAgIFNvdXJjZSBw b3J0OiBzc2hlbGwgKDYxNCkKICAgIERlc3RpbmF0aW9uIHBvcnQ6IG5mcyAo MjA0OSkKICAgIFNlcXVlbmNlIG51bWJlcjogMTIyNSAgICAocmVsYXRpdmUg c2VxdWVuY2UgbnVtYmVyKQogICAgW05leHQgc2VxdWVuY2UgbnVtYmVyOiAx MzYxICAgIChyZWxhdGl2ZSBzZXF1ZW5jZSBudW1iZXIpXQogICAgQWNrbm93 bGVkZ2VtZW50IG51bWJlcjogNDAxICAgIChyZWxhdGl2ZSBhY2sgbnVtYmVy KQogICAgSGVhZGVyIGxlbmd0aDogMjAgYnl0ZXMKICAgIEZsYWdzOiAweDE4 IChQU0gsIEFDSykKICAgICAgICAwLi4uIC4uLi4gPSBDb25nZXN0aW9uIFdp bmRvdyBSZWR1Y2VkIChDV1IpOiBOb3Qgc2V0CiAgICAgICAgLjAuLiAuLi4u ID0gRUNOLUVjaG86IE5vdCBzZXQKICAgICAgICAuLjAuIC4uLi4gPSBVcmdl bnQ6IE5vdCBzZXQKICAgICAgICAuLi4xIC4uLi4gPSBBY2tub3dsZWRnbWVu dDogU2V0CiAgICAgICAgLi4uLiAxLi4uID0gUHVzaDogU2V0CiAgICAgICAg Li4uLiAuMC4uID0gUmVzZXQ6IE5vdCBzZXQKICAgICAgICAuLi4uIC4uMC4g PSBTeW46IE5vdCBzZXQKICAgICAgICAuLi4uIC4uLjAgPSBGaW46IE5vdCBz ZXQKICAgIFdpbmRvdyBzaXplOiA2NTUzNQogICAgQ2hlY2tzdW06IDB4ODcx NSBbaW5jb3JyZWN0LCBzaG91bGQgYmUgMHhlOThiIChtYXliZSBjYXVzZWQg YnkgIlRDUCBjaGVja3N1bSBvZmZsb2FkIj8pXQogICAgICAgIFtHb29kIENo ZWNrc3VtOiBGYWxzZV0KICAgICAgICBbQmFkIENoZWNrc3VtOiBUcnVlXQog ICAgW1NFUS9BQ0sgYW5hbHlzaXNdCiAgICAgICAgW1RoaXMgaXMgYW4gQUNL IHRvIHRoZSBzZWdtZW50IGluIGZyYW1lOiAxOV0KICAgICAgICBbVGhlIFJU VCB0byBBQ0sgdGhlIHNlZ21lbnQgd2FzOiAwLjAwMDAzMDAwMCBzZWNvbmRz XQpSZW1vdGUgUHJvY2VkdXJlIENhbGwsIFR5cGU6Q2FsbCBYSUQ6MHg1N2Ri ZDRlOQogICAgRnJhZ21lbnQgaGVhZGVyOiBMYXN0IGZyYWdtZW50LCAxMzIg Ynl0ZXMKICAgICAgICAxLi4uIC4uLi4gLi4uLiAuLi4uIC4uLi4gLi4uLiAu Li4uIC4uLi4gPSBMYXN0IEZyYWdtZW50OiBZZXMKICAgICAgICAuMDAwIDAw MDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAxMDAwIDAxMDAgPSBGcmFnbWVudCBM ZW5ndGg6IDEzMgogICAgWElEOiAweDU3ZGJkNGU5ICgxNDc0MDI0NjgxKQog ICAgTWVzc2FnZSBUeXBlOiBDYWxsICgwKQogICAgUlBDIFZlcnNpb246IDIK ICAgIFByb2dyYW06IE5GUyAoMTAwMDAzKQogICAgUHJvZ3JhbSBWZXJzaW9u OiAzCiAgICBQcm9jZWR1cmU6IFdSSVRFICg3KQogICAgW1RoZSByZXBseSB0 byB0aGlzIHJlcXVlc3QgaXMgaW4gZnJhbWUgMjFdCiAgICBDcmVkZW50aWFs cwogICAgICAgIEZsYXZvcjogQVVUSF9VTklYICgxKQogICAgICAgIExlbmd0 aDogMjQKICAgICAgICBTdGFtcDogMHgwMDAwMDAwMAogICAgICAgIE1hY2hp bmUgTmFtZTogPEVNUFRZPgogICAgICAgICAgICBsZW5ndGg6IDAKICAgICAg ICAgICAgY29udGVudHM6IDxFTVBUWT4KICAgICAgICBVSUQ6IDgwCiAgICAg ICAgR0lEOiA4MAogICAgICAgIEF1eGlsaWFyeSBHSURzCiAgICAgICAgICAg IEdJRDogODAKICAgIFZlcmlmaWVyCiAgICAgICAgRmxhdm9yOiBBVVRIX05V TEwgKDApCiAgICAgICAgTGVuZ3RoOiAwCk5ldHdvcmsgRmlsZSBTeXN0ZW0s IFdSSVRFIENhbGwgRkg6MHg4MTA2MDJmYyBPZmZzZXQ6MCBMZW46MTUgVU5T VEFCTEUKICAgIFtQcm9ncmFtIFZlcnNpb246IDNdCiAgICBbVjMgUHJvY2Vk dXJlOiBXUklURSAoNyldCiAgICBmaWxlCiAgICAgICAgbGVuZ3RoOiAyOAog ICAgICAgIFtoYXNoOiAweDgxMDYwMmZjXQogICAgICAgIGRlY29kZSB0eXBl IGFzOiB1bmtub3duCiAgICAgICAgZmlsZWhhbmRsZTogOEIyNjk2QTkwN0JG MEVENDBBMDAxRjg3MDUwMDAwMDAwMjlGMDQwMDAwMDAwMDAwLi4uCiAgICBv ZmZzZXQ6IDAKICAgIGNvdW50OiAxNQogICAgU3RhYmxlOiBVTlNUQUJMRSAo MCkKICAgIERhdGE6IDxEQVRBPgogICAgICAgIGxlbmd0aDogMTUKICAgICAg ICBjb250ZW50czogPERBVEE+CiAgICAgICAgZmlsbCBieXRlczogb3BhcXVl IGRhdGEKCjAwMDAgIDAwIDE1IDE3IGJmIGViIDdiIDAwIDMwIDQ4IDdiIDUy IDM0IDA4IDAwIDQ1IDAwICAgLi4uLi57LjBIe1I0Li5FLgowMDEwICAwMCBi MCBmOCBiMyA0MCAwMCA0MCAwNiBiYiAyMSBjMCBhOCAwMiA5OSBjMCBhOCAg IC4uLi5ALkAuLiEuLi4uLi4KMDAyMCAgMDIgODkgMDIgNjYgMDggMDEgMjIg ZGQgMWUgNzYgZWUgYzMgYmYgYTIgNTAgMTggICAuLi5mLi4iLi52Li4uLlAu CjAwMzAgIGZmIGZmIDg3IDE1IDAwIDAwIDgwIDAwIDAwIDg0IDU3IGRiIGQ0 IGU5IDAwIDAwICAgLi4uLi4uLi4uLlcuLi4uLgowMDQwICAwMCAwMCAwMCAw MCAwMCAwMiAwMCAwMSA4NiBhMyAwMCAwMCAwMCAwMyAwMCAwMCAgIC4uLi4u Li4uLi4uLi4uLi4KMDA1MCAgMDAgMDcgMDAgMDAgMDAgMDEgMDAgMDAgMDAg MTggMDAgMDAgMDAgMDAgMDAgMDAgICAuLi4uLi4uLi4uLi4uLi4uCjAwNjAg IDAwIDAwIDAwIDAwIDAwIDUwIDAwIDAwIDAwIDUwIDAwIDAwIDAwIDAxIDAw IDAwICAgLi4uLi5QLi4uUC4uLi4uLgowMDcwICAwMCA1MCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAxYyA4YiAyNiAgIC5QLi4uLi4uLi4u Li4uLiYKMDA4MCAgOTYgYTkgMDcgYmYgMGUgZDQgMGEgMDAgMWYgODcgMDUg MDAgMDAgMDAgMDIgOWYgICAuLi4uLi4uLi4uLi4uLi4uCjAwOTAgIDA0IDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAg Li4uLi4uLi4uLi4uLi4uLgowMGEwICAwMCAwMCAwMCAwMCAwMCAwZiAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwZiAzOCAzOSAgIC4uLi4uLi4uLi4uLi4uODkK MDBiMCAgMzkgMzggMzggMjAgMzIgMzYgMzIgMzEgMzQgMzQgMzAgMzAgMzAg MDAgICAgICAgICA5ODggMjYyMTQ0MDAwLgoKTm8uICAgICBUaW1lICAgICAg ICBTb3VyY2UgICAgICAgICAgICAgICAgRGVzdGluYXRpb24gICAgICAgICAg IFByb3RvY29sIEluZm8KICAgICAyMSAwLjAwMjQ5NyAgICAxOTIuMTY4LjIu MTM3ICAgICAgICAgMTkyLjE2OC4yLjE1MyAgICAgICAgIE5GUyAgICAgIFYz IFdSSVRFIFJlcGx5IChDYWxsIEluIDIwKSBFcnJvcjpORlMzRVJSX0lPCgpG cmFtZSAyMSAoOTQgYnl0ZXMgb24gd2lyZSwgOTQgYnl0ZXMgY2FwdHVyZWQp CiAgICBBcnJpdmFsIFRpbWU6IEphbiAzMCwgMjAxMCAxMjo0MTo0Ni45MTMz MjUwMDAKICAgIFtUaW1lIGRlbHRhIGZyb20gcHJldmlvdXMgY2FwdHVyZWQg ZnJhbWU6IDAuMDAwMjIxMDAwIHNlY29uZHNdCiAgICBbVGltZSBkZWx0YSBm cm9tIHByZXZpb3VzIGRpc3BsYXllZCBmcmFtZTogMC4wMDAyMjEwMDAgc2Vj b25kc10KICAgIFtUaW1lIHNpbmNlIHJlZmVyZW5jZSBvciBmaXJzdCBmcmFt ZTogMC4wMDI0OTcwMDAgc2Vjb25kc10KICAgIEZyYW1lIE51bWJlcjogMjEK ICAgIEZyYW1lIExlbmd0aDogOTQgYnl0ZXMKICAgIENhcHR1cmUgTGVuZ3Ro OiA5NCBieXRlcwogICAgW0ZyYW1lIGlzIG1hcmtlZDogRmFsc2VdCiAgICBb UHJvdG9jb2xzIGluIGZyYW1lOiBldGg6aXA6dGNwOnJwY10KICAgIFtDb2xv cmluZyBSdWxlIE5hbWU6IFRDUF0KICAgIFtDb2xvcmluZyBSdWxlIFN0cmlu ZzogdGNwXQpFdGhlcm5ldCBJSSwgU3JjOiBJbnRlbENvcl9iZjplYjo3YiAo MDA6MTU6MTc6YmY6ZWI6N2IpLCBEc3Q6IFN1cGVybWljXzdiOjUyOjM0ICgw MDozMDo0ODo3Yjo1MjozNCkKICAgIERlc3RpbmF0aW9uOiBTdXBlcm1pY183 Yjo1MjozNCAoMDA6MzA6NDg6N2I6NTI6MzQpCiAgICAgICAgQWRkcmVzczog U3VwZXJtaWNfN2I6NTI6MzQgKDAwOjMwOjQ4OjdiOjUyOjM0KQogICAgICAg IC4uLi4gLi4uMCAuLi4uIC4uLi4gLi4uLiAuLi4uID0gSUcgYml0OiBJbmRp dmlkdWFsIGFkZHJlc3MgKHVuaWNhc3QpCiAgICAgICAgLi4uLiAuLjAuIC4u Li4gLi4uLiAuLi4uIC4uLi4gPSBMRyBiaXQ6IEdsb2JhbGx5IHVuaXF1ZSBh ZGRyZXNzIChmYWN0b3J5IGRlZmF1bHQpCiAgICBTb3VyY2U6IEludGVsQ29y X2JmOmViOjdiICgwMDoxNToxNzpiZjplYjo3YikKICAgICAgICBBZGRyZXNz OiBJbnRlbENvcl9iZjplYjo3YiAoMDA6MTU6MTc6YmY6ZWI6N2IpCiAgICAg ICAgLi4uLiAuLi4wIC4uLi4gLi4uLiAuLi4uIC4uLi4gPSBJRyBiaXQ6IElu ZGl2aWR1YWwgYWRkcmVzcyAodW5pY2FzdCkKICAgICAgICAuLi4uIC4uMC4g Li4uLiAuLi4uIC4uLi4gLi4uLiA9IExHIGJpdDogR2xvYmFsbHkgdW5pcXVl IGFkZHJlc3MgKGZhY3RvcnkgZGVmYXVsdCkKICAgIFR5cGU6IElQICgweDA4 MDApCkludGVybmV0IFByb3RvY29sLCBTcmM6IDE5Mi4xNjguMi4xMzcgKDE5 Mi4xNjguMi4xMzcpLCBEc3Q6IDE5Mi4xNjguMi4xNTMgKDE5Mi4xNjguMi4x NTMpCiAgICBWZXJzaW9uOiA0CiAgICBIZWFkZXIgbGVuZ3RoOiAyMCBieXRl cwogICAgRGlmZmVyZW50aWF0ZWQgU2VydmljZXMgRmllbGQ6IDB4MDAgKERT Q1AgMHgwMDogRGVmYXVsdDsgRUNOOiAweDAwKQogICAgICAgIDAwMDAgMDAu LiA9IERpZmZlcmVudGlhdGVkIFNlcnZpY2VzIENvZGVwb2ludDogRGVmYXVs dCAoMHgwMCkKICAgICAgICAuLi4uIC4uMC4gPSBFQ04tQ2FwYWJsZSBUcmFu c3BvcnQgKEVDVCk6IDAKICAgICAgICAuLi4uIC4uLjAgPSBFQ04tQ0U6IDAK ICAgIFRvdGFsIExlbmd0aDogODAKICAgIElkZW50aWZpY2F0aW9uOiAweGI4 ZGYgKDQ3MzI3KQogICAgRmxhZ3M6IDB4MDQgKERvbid0IEZyYWdtZW50KQog ICAgICAgIDAuLi4gPSBSZXNlcnZlZCBiaXQ6IE5vdCBzZXQKICAgICAgICAu MS4uID0gRG9uJ3QgZnJhZ21lbnQ6IFNldAogICAgICAgIC4uMC4gPSBNb3Jl IGZyYWdtZW50czogTm90IHNldAogICAgRnJhZ21lbnQgb2Zmc2V0OiAwCiAg ICBUaW1lIHRvIGxpdmU6IDY0CiAgICBQcm90b2NvbDogVENQICgweDA2KQog ICAgSGVhZGVyIGNoZWNrc3VtOiAweGZiNTUgW2NvcnJlY3RdCiAgICAgICAg W0dvb2Q6IFRydWVdCiAgICAgICAgW0JhZCA6IEZhbHNlXQogICAgU291cmNl OiAxOTIuMTY4LjIuMTM3ICgxOTIuMTY4LjIuMTM3KQogICAgRGVzdGluYXRp b246IDE5Mi4xNjguMi4xNTMgKDE5Mi4xNjguMi4xNTMpClRyYW5zbWlzc2lv biBDb250cm9sIFByb3RvY29sLCBTcmMgUG9ydDogbmZzICgyMDQ5KSwgRHN0 IFBvcnQ6IHNzaGVsbCAoNjE0KSwgU2VxOiA0MDEsIEFjazogMTM2MSwgTGVu OiA0MAogICAgU291cmNlIHBvcnQ6IG5mcyAoMjA0OSkKICAgIERlc3RpbmF0 aW9uIHBvcnQ6IHNzaGVsbCAoNjE0KQogICAgU2VxdWVuY2UgbnVtYmVyOiA0 MDEgICAgKHJlbGF0aXZlIHNlcXVlbmNlIG51bWJlcikKICAgIFtOZXh0IHNl cXVlbmNlIG51bWJlcjogNDQxICAgIChyZWxhdGl2ZSBzZXF1ZW5jZSBudW1i ZXIpXQogICAgQWNrbm93bGVkZ2VtZW50IG51bWJlcjogMTM2MSAgICAocmVs YXRpdmUgYWNrIG51bWJlcikKICAgIEhlYWRlciBsZW5ndGg6IDIwIGJ5dGVz CiAgICBGbGFnczogMHgxOCAoUFNILCBBQ0spCiAgICAgICAgMC4uLiAuLi4u ID0gQ29uZ2VzdGlvbiBXaW5kb3cgUmVkdWNlZCAoQ1dSKTogTm90IHNldAog ICAgICAgIC4wLi4gLi4uLiA9IEVDTi1FY2hvOiBOb3Qgc2V0CiAgICAgICAg Li4wLiAuLi4uID0gVXJnZW50OiBOb3Qgc2V0CiAgICAgICAgLi4uMSAuLi4u ID0gQWNrbm93bGVkZ21lbnQ6IFNldAogICAgICAgIC4uLi4gMS4uLiA9IFB1 c2g6IFNldAogICAgICAgIC4uLi4gLjAuLiA9IFJlc2V0OiBOb3Qgc2V0CiAg ICAgICAgLi4uLiAuLjAuID0gU3luOiBOb3Qgc2V0CiAgICAgICAgLi4uLiAu Li4wID0gRmluOiBOb3Qgc2V0CiAgICBXaW5kb3cgc2l6ZTogNjU1MzUKICAg IENoZWNrc3VtOiAweDgxOTkgW2NvcnJlY3RdCiAgICAgICAgW0dvb2QgQ2hl Y2tzdW06IFRydWVdCiAgICAgICAgW0JhZCBDaGVja3N1bTogRmFsc2VdCiAg ICBbU0VRL0FDSyBhbmFseXNpc10KICAgICAgICBbVGhpcyBpcyBhbiBBQ0sg dG8gdGhlIHNlZ21lbnQgaW4gZnJhbWU6IDIwXQogICAgICAgIFtUaGUgUlRU IHRvIEFDSyB0aGUgc2VnbWVudCB3YXM6IDAuMDAwMjIxMDAwIHNlY29uZHNd ClJlbW90ZSBQcm9jZWR1cmUgQ2FsbCwgVHlwZTpSZXBseSBYSUQ6MHg1N2Ri ZDRlOQogICAgRnJhZ21lbnQgaGVhZGVyOiBMYXN0IGZyYWdtZW50LCAzNiBi eXRlcwogICAgICAgIDEuLi4gLi4uLiAuLi4uIC4uLi4gLi4uLiAuLi4uIC4u Li4gLi4uLiA9IExhc3QgRnJhZ21lbnQ6IFllcwogICAgICAgIC4wMDAgMDAw MCAwMDAwIDAwMDAgMDAwMCAwMDAwIDAwMTAgMDEwMCA9IEZyYWdtZW50IExl bmd0aDogMzYKICAgIFhJRDogMHg1N2RiZDRlOSAoMTQ3NDAyNDY4MSkKICAg IE1lc3NhZ2UgVHlwZTogUmVwbHkgKDEpCiAgICBbUHJvZ3JhbTogTkZTICgx MDAwMDMpXQogICAgW1Byb2dyYW0gVmVyc2lvbjogM10KICAgIFtQcm9jZWR1 cmU6IFdSSVRFICg3KV0KICAgIFJlcGx5IFN0YXRlOiBhY2NlcHRlZCAoMCkK ICAgIFtUaGlzIGlzIGEgcmVwbHkgdG8gYSByZXF1ZXN0IGluIGZyYW1lIDIw XQogICAgW1RpbWUgZnJvbSByZXF1ZXN0OiAwLjAwMDIyMTAwMCBzZWNvbmRz XQogICAgVmVyaWZpZXIKICAgICAgICBGbGF2b3I6IEFVVEhfTlVMTCAoMCkK ICAgICAgICBMZW5ndGg6IDAKICAgIEFjY2VwdCBTdGF0ZTogUlBDIGV4ZWN1 dGVkIHN1Y2Nlc3NmdWxseSAoMCkKTmV0d29yayBGaWxlIFN5c3RlbSwgV1JJ VEUgUmVwbHkgIEVycm9yOk5GUzNFUlJfSU8KICAgIFtQcm9ncmFtIFZlcnNp b246IDNdCiAgICBbVjMgUHJvY2VkdXJlOiBXUklURSAoNyldCiAgICBTdGF0 dXM6IE5GUzNFUlJfSU8gKDUpCiAgICBmaWxlX3djYwogICAgICAgIGJlZm9y ZQogICAgICAgICAgICBhdHRyaWJ1dGVzX2ZvbGxvdzogbm8gdmFsdWUgKDAp CiAgICAgICAgYWZ0ZXIKICAgICAgICAgICAgYXR0cmlidXRlc19mb2xsb3c6 IG5vIHZhbHVlICgwKQoKMDAwMCAgMDAgMzAgNDggN2IgNTIgMzQgMDAgMTUg MTcgYmYgZWIgN2IgMDggMDAgNDUgMDAgICAuMEh7UjQuLi4uLnsuLkUuCjAw MTAgIDAwIDUwIGI4IGRmIDQwIDAwIDQwIDA2IGZiIDU1IGMwIGE4IDAyIDg5 IGMwIGE4ICAgLlAuLkAuQC4uVS4uLi4uLgowMDIwICAwMiA5OSAwOCAwMSAw MiA2NiBlZSBjMyBiZiBhMiAyMiBkZCAxZSBmZSA1MCAxOCAgIC4uLi4uZi4u Li4iLi4uUC4KMDAzMCAgZmYgZmYgODEgOTkgMDAgMDAgODAgMDAgMDAgMjQg NTcgZGIgZDQgZTkgMDAgMDAgICAuLi4uLi4uLi4kVy4uLi4uCjAwNDAgIDAw IDAxIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw ICAgLi4uLi4uLi4uLi4uLi4uLgowMDUwICAwMCAwMCAwMCAwMCAwMCAwNSAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAgICAgICAgIC4uLi4uLi4uLi4uLi4u CgpOby4gICAgIFRpbWUgICAgICAgIFNvdXJjZSAgICAgICAgICAgICAgICBE ZXN0aW5hdGlvbiAgICAgICAgICAgUHJvdG9jb2wgSW5mbwogICAgIDIyIDAu MDAyNTI1ICAgIDE5Mi4xNjguMi4xNTMgICAgICAgICAxOTIuMTY4LjIuMTM3 ICAgICAgICAgTkZTICAgICAgVjMgV1JJVEUgQ2FsbCAoUmVwbHkgSW4gMjMp LCBGSDoweDgxMDYwMmZjIE9mZnNldDowIExlbjoxNSBVTlNUQUJMRQoKRnJh bWUgMjIgKDE5MCBieXRlcyBvbiB3aXJlLCAxOTAgYnl0ZXMgY2FwdHVyZWQp CiAgICBBcnJpdmFsIFRpbWU6IEphbiAzMCwgMjAxMCAxMjo0MTo0Ni45MTMz NTMwMDAKICAgIFtUaW1lIGRlbHRhIGZyb20gcHJldmlvdXMgY2FwdHVyZWQg ZnJhbWU6IDAuMDAwMDI4MDAwIHNlY29uZHNdCiAgICBbVGltZSBkZWx0YSBm cm9tIHByZXZpb3VzIGRpc3BsYXllZCBmcmFtZTogMC4wMDAwMjgwMDAgc2Vj b25kc10KICAgIFtUaW1lIHNpbmNlIHJlZmVyZW5jZSBvciBmaXJzdCBmcmFt ZTogMC4wMDI1MjUwMDAgc2Vjb25kc10KICAgIEZyYW1lIE51bWJlcjogMjIK ICAgIEZyYW1lIExlbmd0aDogMTkwIGJ5dGVzCiAgICBDYXB0dXJlIExlbmd0 aDogMTkwIGJ5dGVzCiAgICBbRnJhbWUgaXMgbWFya2VkOiBGYWxzZV0KICAg IFtQcm90b2NvbHMgaW4gZnJhbWU6IGV0aDppcDp0Y3A6cnBjOm5mc10KICAg IFtDb2xvcmluZyBSdWxlIE5hbWU6IENoZWNrc3VtIEVycm9yc10KICAgIFtD b2xvcmluZyBSdWxlIFN0cmluZzogY2RwLmNoZWNrc3VtX2JhZD09MSB8fCBl ZHAuY2hlY2tzdW1fYmFkPT0xIHx8IGlwLmNoZWNrc3VtX2JhZD09MSB8fCB0 Y3AuY2hlY2tzdW1fYmFkPT0xIHx8IHVkcC5jaGVja3N1bV9iYWQ9PTFdCkV0 aGVybmV0IElJLCBTcmM6IFN1cGVybWljXzdiOjUyOjM0ICgwMDozMDo0ODo3 Yjo1MjozNCksIERzdDogSW50ZWxDb3JfYmY6ZWI6N2IgKDAwOjE1OjE3OmJm OmViOjdiKQogICAgRGVzdGluYXRpb246IEludGVsQ29yX2JmOmViOjdiICgw MDoxNToxNzpiZjplYjo3YikKICAgICAgICBBZGRyZXNzOiBJbnRlbENvcl9i ZjplYjo3YiAoMDA6MTU6MTc6YmY6ZWI6N2IpCiAgICAgICAgLi4uLiAuLi4w IC4uLi4gLi4uLiAuLi4uIC4uLi4gPSBJRyBiaXQ6IEluZGl2aWR1YWwgYWRk cmVzcyAodW5pY2FzdCkKICAgICAgICAuLi4uIC4uMC4gLi4uLiAuLi4uIC4u Li4gLi4uLiA9IExHIGJpdDogR2xvYmFsbHkgdW5pcXVlIGFkZHJlc3MgKGZh Y3RvcnkgZGVmYXVsdCkKICAgIFNvdXJjZTogU3VwZXJtaWNfN2I6NTI6MzQg KDAwOjMwOjQ4OjdiOjUyOjM0KQogICAgICAgIEFkZHJlc3M6IFN1cGVybWlj XzdiOjUyOjM0ICgwMDozMDo0ODo3Yjo1MjozNCkKICAgICAgICAuLi4uIC4u LjAgLi4uLiAuLi4uIC4uLi4gLi4uLiA9IElHIGJpdDogSW5kaXZpZHVhbCBh ZGRyZXNzICh1bmljYXN0KQogICAgICAgIC4uLi4gLi4wLiAuLi4uIC4uLi4g Li4uLiAuLi4uID0gTEcgYml0OiBHbG9iYWxseSB1bmlxdWUgYWRkcmVzcyAo ZmFjdG9yeSBkZWZhdWx0KQogICAgVHlwZTogSVAgKDB4MDgwMCkKSW50ZXJu ZXQgUHJvdG9jb2wsIFNyYzogMTkyLjE2OC4yLjE1MyAoMTkyLjE2OC4yLjE1 MyksIERzdDogMTkyLjE2OC4yLjEzNyAoMTkyLjE2OC4yLjEzNykKICAgIFZl cnNpb246IDQKICAgIEhlYWRlciBsZW5ndGg6IDIwIGJ5dGVzCiAgICBEaWZm ZXJlbnRpYXRlZCBTZXJ2aWNlcyBGaWVsZDogMHgwMCAoRFNDUCAweDAwOiBE ZWZhdWx0OyBFQ046IDB4MDApCiAgICAgICAgMDAwMCAwMC4uID0gRGlmZmVy ZW50aWF0ZWQgU2VydmljZXMgQ29kZXBvaW50OiBEZWZhdWx0ICgweDAwKQog ICAgICAgIC4uLi4gLi4wLiA9IEVDTi1DYXBhYmxlIFRyYW5zcG9ydCAoRUNU KTogMAogICAgICAgIC4uLi4gLi4uMCA9IEVDTi1DRTogMAogICAgVG90YWwg TGVuZ3RoOiAxNzYKICAgIElkZW50aWZpY2F0aW9uOiAweGY4YjQgKDYzNjY4 KQogICAgRmxhZ3M6IDB4MDQgKERvbid0IEZyYWdtZW50KQogICAgICAgIDAu Li4gPSBSZXNlcnZlZCBiaXQ6IE5vdCBzZXQKICAgICAgICAuMS4uID0gRG9u J3QgZnJhZ21lbnQ6IFNldAogICAgICAgIC4uMC4gPSBNb3JlIGZyYWdtZW50 czogTm90IHNldAogICAgRnJhZ21lbnQgb2Zmc2V0OiAwCiAgICBUaW1lIHRv IGxpdmU6IDY0CiAgICBQcm90b2NvbDogVENQICgweDA2KQogICAgSGVhZGVy IGNoZWNrc3VtOiAweGJiMjAgW2NvcnJlY3RdCiAgICAgICAgW0dvb2Q6IFRy dWVdCiAgICAgICAgW0JhZCA6IEZhbHNlXQogICAgU291cmNlOiAxOTIuMTY4 LjIuMTUzICgxOTIuMTY4LjIuMTUzKQogICAgRGVzdGluYXRpb246IDE5Mi4x NjguMi4xMzcgKDE5Mi4xNjguMi4xMzcpClRyYW5zbWlzc2lvbiBDb250cm9s IFByb3RvY29sLCBTcmMgUG9ydDogc3NoZWxsICg2MTQpLCBEc3QgUG9ydDog bmZzICgyMDQ5KSwgU2VxOiAxMzYxLCBBY2s6IDQ0MSwgTGVuOiAxMzYKICAg IFNvdXJjZSBwb3J0OiBzc2hlbGwgKDYxNCkKICAgIERlc3RpbmF0aW9uIHBv cnQ6IG5mcyAoMjA0OSkKICAgIFNlcXVlbmNlIG51bWJlcjogMTM2MSAgICAo cmVsYXRpdmUgc2VxdWVuY2UgbnVtYmVyKQogICAgW05leHQgc2VxdWVuY2Ug bnVtYmVyOiAxNDk3ICAgIChyZWxhdGl2ZSBzZXF1ZW5jZSBudW1iZXIpXQog ICAgQWNrbm93bGVkZ2VtZW50IG51bWJlcjogNDQxICAgIChyZWxhdGl2ZSBh Y2sgbnVtYmVyKQogICAgSGVhZGVyIGxlbmd0aDogMjAgYnl0ZXMKICAgIEZs YWdzOiAweDE4IChQU0gsIEFDSykKICAgICAgICAwLi4uIC4uLi4gPSBDb25n ZXN0aW9uIFdpbmRvdyBSZWR1Y2VkIChDV1IpOiBOb3Qgc2V0CiAgICAgICAg LjAuLiAuLi4uID0gRUNOLUVjaG86IE5vdCBzZXQKICAgICAgICAuLjAuIC4u Li4gPSBVcmdlbnQ6IE5vdCBzZXQKICAgICAgICAuLi4xIC4uLi4gPSBBY2tu b3dsZWRnbWVudDogU2V0CiAgICAgICAgLi4uLiAxLi4uID0gUHVzaDogU2V0 CiAgICAgICAgLi4uLiAuMC4uID0gUmVzZXQ6IE5vdCBzZXQKICAgICAgICAu Li4uIC4uMC4gPSBTeW46IE5vdCBzZXQKICAgICAgICAuLi4uIC4uLjAgPSBG aW46IE5vdCBzZXQKICAgIFdpbmRvdyBzaXplOiA2NTUzNQogICAgQ2hlY2tz dW06IDB4ODcxNSBbaW5jb3JyZWN0LCBzaG91bGQgYmUgMHhlOGRhIChtYXli ZSBjYXVzZWQgYnkgIlRDUCBjaGVja3N1bSBvZmZsb2FkIj8pXQogICAgICAg IFtHb29kIENoZWNrc3VtOiBGYWxzZV0KICAgICAgICBbQmFkIENoZWNrc3Vt OiBUcnVlXQogICAgW1NFUS9BQ0sgYW5hbHlzaXNdCiAgICAgICAgW1RoaXMg aXMgYW4gQUNLIHRvIHRoZSBzZWdtZW50IGluIGZyYW1lOiAyMV0KICAgICAg ICBbVGhlIFJUVCB0byBBQ0sgdGhlIHNlZ21lbnQgd2FzOiAwLjAwMDAyODAw MCBzZWNvbmRzXQpSZW1vdGUgUHJvY2VkdXJlIENhbGwsIFR5cGU6Q2FsbCBY SUQ6MHg1N2RiZDRlYQogICAgRnJhZ21lbnQgaGVhZGVyOiBMYXN0IGZyYWdt ZW50LCAxMzIgYnl0ZXMKICAgICAgICAxLi4uIC4uLi4gLi4uLiAuLi4uIC4u Li4gLi4uLiAuLi4uIC4uLi4gPSBMYXN0IEZyYWdtZW50OiBZZXMKICAgICAg ICAuMDAwIDAwMDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAxMDAwIDAxMDAgPSBG cmFnbWVudCBMZW5ndGg6IDEzMgogICAgWElEOiAweDU3ZGJkNGVhICgxNDc0 MDI0NjgyKQogICAgTWVzc2FnZSBUeXBlOiBDYWxsICgwKQogICAgUlBDIFZl cnNpb246IDIKICAgIFByb2dyYW06IE5GUyAoMTAwMDAzKQogICAgUHJvZ3Jh bSBWZXJzaW9uOiAzCiAgICBQcm9jZWR1cmU6IFdSSVRFICg3KQogICAgW1Ro ZSByZXBseSB0byB0aGlzIHJlcXVlc3QgaXMgaW4gZnJhbWUgMjNdCiAgICBD cmVkZW50aWFscwogICAgICAgIEZsYXZvcjogQVVUSF9VTklYICgxKQogICAg ICAgIExlbmd0aDogMjQKICAgICAgICBTdGFtcDogMHgwMDAwMDAwMAogICAg ICAgIE1hY2hpbmUgTmFtZTogPEVNUFRZPgogICAgICAgICAgICBsZW5ndGg6 IDAKICAgICAgICAgICAgY29udGVudHM6IDxFTVBUWT4KICAgICAgICBVSUQ6 IDgwCiAgICAgICAgR0lEOiA4MAogICAgICAgIEF1eGlsaWFyeSBHSURzCiAg ICAgICAgICAgIEdJRDogODAKICAgIFZlcmlmaWVyCiAgICAgICAgRmxhdm9y OiBBVVRIX05VTEwgKDApCiAgICAgICAgTGVuZ3RoOiAwCk5ldHdvcmsgRmls ZSBTeXN0ZW0sIFdSSVRFIENhbGwgRkg6MHg4MTA2MDJmYyBPZmZzZXQ6MCBM ZW46MTUgVU5TVEFCTEUKICAgIFtQcm9ncmFtIFZlcnNpb246IDNdCiAgICBb VjMgUHJvY2VkdXJlOiBXUklURSAoNyldCiAgICBmaWxlCiAgICAgICAgbGVu Z3RoOiAyOAogICAgICAgIFtoYXNoOiAweDgxMDYwMmZjXQogICAgICAgIGRl Y29kZSB0eXBlIGFzOiB1bmtub3duCiAgICAgICAgZmlsZWhhbmRsZTogOEIy Njk2QTkwN0JGMEVENDBBMDAxRjg3MDUwMDAwMDAwMjlGMDQwMDAwMDAwMDAw Li4uCiAgICBvZmZzZXQ6IDAKICAgIGNvdW50OiAxNQogICAgU3RhYmxlOiBV TlNUQUJMRSAoMCkKICAgIERhdGE6IDxEQVRBPgogICAgICAgIGxlbmd0aDog MTUKICAgICAgICBjb250ZW50czogPERBVEE+CiAgICAgICAgZmlsbCBieXRl czogb3BhcXVlIGRhdGEKCjAwMDAgIDAwIDE1IDE3IGJmIGViIDdiIDAwIDMw IDQ4IDdiIDUyIDM0IDA4IDAwIDQ1IDAwICAgLi4uLi57LjBIe1I0Li5FLgow MDEwICAwMCBiMCBmOCBiNCA0MCAwMCA0MCAwNiBiYiAyMCBjMCBhOCAwMiA5 OSBjMCBhOCAgIC4uLi5ALkAuLiAuLi4uLi4KMDAyMCAgMDIgODkgMDIgNjYg MDggMDEgMjIgZGQgMWUgZmUgZWUgYzMgYmYgY2EgNTAgMTggICAuLi5mLi4i Li4uLi4uLlAuCjAwMzAgIGZmIGZmIDg3IDE1IDAwIDAwIDgwIDAwIDAwIDg0 IDU3IGRiIGQ0IGVhIDAwIDAwICAgLi4uLi4uLi4uLlcuLi4uLgowMDQwICAw MCAwMCAwMCAwMCAwMCAwMiAwMCAwMSA4NiBhMyAwMCAwMCAwMCAwMyAwMCAw MCAgIC4uLi4uLi4uLi4uLi4uLi4KMDA1MCAgMDAgMDcgMDAgMDAgMDAgMDEg MDAgMDAgMDAgMTggMDAgMDAgMDAgMDAgMDAgMDAgICAuLi4uLi4uLi4uLi4u Li4uCjAwNjAgIDAwIDAwIDAwIDAwIDAwIDUwIDAwIDAwIDAwIDUwIDAwIDAw IDAwIDAxIDAwIDAwICAgLi4uLi5QLi4uUC4uLi4uLgowMDcwICAwMCA1MCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAxYyA4YiAyNiAgIC5Q Li4uLi4uLi4uLi4uLiYKMDA4MCAgOTYgYTkgMDcgYmYgMGUgZDQgMGEgMDAg MWYgODcgMDUgMDAgMDAgMDAgMDIgOWYgICAuLi4uLi4uLi4uLi4uLi4uCjAw OTAgIDA0IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwICAgLi4uLi4uLi4uLi4uLi4uLgowMGEwICAwMCAwMCAwMCAwMCAw MCAwZiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwZiAzOCAzOSAgIC4uLi4uLi4u Li4uLi4uODkKMDBiMCAgMzkgMzggMzggMjAgMzIgMzYgMzIgMzEgMzQgMzQg MzAgMzAgMzAgMDAgICAgICAgICA5ODggMjYyMTQ0MDAwLgoKTm8uICAgICBU aW1lICAgICAgICBTb3VyY2UgICAgICAgICAgICAgICAgRGVzdGluYXRpb24g ICAgICAgICAgIFByb3RvY29sIEluZm8KICAgICAyMyAwLjAwMjc0NyAgICAx OTIuMTY4LjIuMTM3ICAgICAgICAgMTkyLjE2OC4yLjE1MyAgICAgICAgIE5G UyAgICAgIFYzIFdSSVRFIFJlcGx5IChDYWxsIEluIDIyKSBFcnJvcjpORlMz RVJSX0lPCgpGcmFtZSAyMyAoOTQgYnl0ZXMgb24gd2lyZSwgOTQgYnl0ZXMg Y2FwdHVyZWQpCiAgICBBcnJpdmFsIFRpbWU6IEphbiAzMCwgMjAxMCAxMjo0 MTo0Ni45MTM1NzUwMDAKICAgIFtUaW1lIGRlbHRhIGZyb20gcHJldmlvdXMg Y2FwdHVyZWQgZnJhbWU6IDAuMDAwMjIyMDAwIHNlY29uZHNdCiAgICBbVGlt ZSBkZWx0YSBmcm9tIHByZXZpb3VzIGRpc3BsYXllZCBmcmFtZTogMC4wMDAy MjIwMDAgc2Vjb25kc10KICAgIFtUaW1lIHNpbmNlIHJlZmVyZW5jZSBvciBm aXJzdCBmcmFtZTogMC4wMDI3NDcwMDAgc2Vjb25kc10KICAgIEZyYW1lIE51 bWJlcjogMjMKICAgIEZyYW1lIExlbmd0aDogOTQgYnl0ZXMKICAgIENhcHR1 cmUgTGVuZ3RoOiA5NCBieXRlcwogICAgW0ZyYW1lIGlzIG1hcmtlZDogRmFs c2VdCiAgICBbUHJvdG9jb2xzIGluIGZyYW1lOiBldGg6aXA6dGNwOnJwY10K ICAgIFtDb2xvcmluZyBSdWxlIE5hbWU6IFRDUF0KICAgIFtDb2xvcmluZyBS dWxlIFN0cmluZzogdGNwXQpFdGhlcm5ldCBJSSwgU3JjOiBJbnRlbENvcl9i ZjplYjo3YiAoMDA6MTU6MTc6YmY6ZWI6N2IpLCBEc3Q6IFN1cGVybWljXzdi OjUyOjM0ICgwMDozMDo0ODo3Yjo1MjozNCkKICAgIERlc3RpbmF0aW9uOiBT dXBlcm1pY183Yjo1MjozNCAoMDA6MzA6NDg6N2I6NTI6MzQpCiAgICAgICAg QWRkcmVzczogU3VwZXJtaWNfN2I6NTI6MzQgKDAwOjMwOjQ4OjdiOjUyOjM0 KQogICAgICAgIC4uLi4gLi4uMCAuLi4uIC4uLi4gLi4uLiAuLi4uID0gSUcg Yml0OiBJbmRpdmlkdWFsIGFkZHJlc3MgKHVuaWNhc3QpCiAgICAgICAgLi4u LiAuLjAuIC4uLi4gLi4uLiAuLi4uIC4uLi4gPSBMRyBiaXQ6IEdsb2JhbGx5 IHVuaXF1ZSBhZGRyZXNzIChmYWN0b3J5IGRlZmF1bHQpCiAgICBTb3VyY2U6 IEludGVsQ29yX2JmOmViOjdiICgwMDoxNToxNzpiZjplYjo3YikKICAgICAg ICBBZGRyZXNzOiBJbnRlbENvcl9iZjplYjo3YiAoMDA6MTU6MTc6YmY6ZWI6 N2IpCiAgICAgICAgLi4uLiAuLi4wIC4uLi4gLi4uLiAuLi4uIC4uLi4gPSBJ RyBiaXQ6IEluZGl2aWR1YWwgYWRkcmVzcyAodW5pY2FzdCkKICAgICAgICAu Li4uIC4uMC4gLi4uLiAuLi4uIC4uLi4gLi4uLiA9IExHIGJpdDogR2xvYmFs bHkgdW5pcXVlIGFkZHJlc3MgKGZhY3RvcnkgZGVmYXVsdCkKICAgIFR5cGU6 IElQICgweDA4MDApCkludGVybmV0IFByb3RvY29sLCBTcmM6IDE5Mi4xNjgu Mi4xMzcgKDE5Mi4xNjguMi4xMzcpLCBEc3Q6IDE5Mi4xNjguMi4xNTMgKDE5 Mi4xNjguMi4xNTMpCiAgICBWZXJzaW9uOiA0CiAgICBIZWFkZXIgbGVuZ3Ro OiAyMCBieXRlcwogICAgRGlmZmVyZW50aWF0ZWQgU2VydmljZXMgRmllbGQ6 IDB4MDAgKERTQ1AgMHgwMDogRGVmYXVsdDsgRUNOOiAweDAwKQogICAgICAg IDAwMDAgMDAuLiA9IERpZmZlcmVudGlhdGVkIFNlcnZpY2VzIENvZGVwb2lu dDogRGVmYXVsdCAoMHgwMCkKICAgICAgICAuLi4uIC4uMC4gPSBFQ04tQ2Fw YWJsZSBUcmFuc3BvcnQgKEVDVCk6IDAKICAgICAgICAuLi4uIC4uLjAgPSBF Q04tQ0U6IDAKICAgIFRvdGFsIExlbmd0aDogODAKICAgIElkZW50aWZpY2F0 aW9uOiAweGI4ZTAgKDQ3MzI4KQogICAgRmxhZ3M6IDB4MDQgKERvbid0IEZy YWdtZW50KQogICAgICAgIDAuLi4gPSBSZXNlcnZlZCBiaXQ6IE5vdCBzZXQK ICAgICAgICAuMS4uID0gRG9uJ3QgZnJhZ21lbnQ6IFNldAogICAgICAgIC4u MC4gPSBNb3JlIGZyYWdtZW50czogTm90IHNldAogICAgRnJhZ21lbnQgb2Zm c2V0OiAwCiAgICBUaW1lIHRvIGxpdmU6IDY0CiAgICBQcm90b2NvbDogVENQ ICgweDA2KQogICAgSGVhZGVyIGNoZWNrc3VtOiAweGZiNTQgW2NvcnJlY3Rd CiAgICAgICAgW0dvb2Q6IFRydWVdCiAgICAgICAgW0JhZCA6IEZhbHNlXQog ICAgU291cmNlOiAxOTIuMTY4LjIuMTM3ICgxOTIuMTY4LjIuMTM3KQogICAg RGVzdGluYXRpb246IDE5Mi4xNjguMi4xNTMgKDE5Mi4xNjguMi4xNTMpClRy YW5zbWlzc2lvbiBDb250cm9sIFByb3RvY29sLCBTcmMgUG9ydDogbmZzICgy MDQ5KSwgRHN0IFBvcnQ6IHNzaGVsbCAoNjE0KSwgU2VxOiA0NDEsIEFjazog MTQ5NywgTGVuOiA0MAogICAgU291cmNlIHBvcnQ6IG5mcyAoMjA0OSkKICAg IERlc3RpbmF0aW9uIHBvcnQ6IHNzaGVsbCAoNjE0KQogICAgU2VxdWVuY2Ug bnVtYmVyOiA0NDEgICAgKHJlbGF0aXZlIHNlcXVlbmNlIG51bWJlcikKICAg IFtOZXh0IHNlcXVlbmNlIG51bWJlcjogNDgxICAgIChyZWxhdGl2ZSBzZXF1 ZW5jZSBudW1iZXIpXQogICAgQWNrbm93bGVkZ2VtZW50IG51bWJlcjogMTQ5 NyAgICAocmVsYXRpdmUgYWNrIG51bWJlcikKICAgIEhlYWRlciBsZW5ndGg6 IDIwIGJ5dGVzCiAgICBGbGFnczogMHgxOCAoUFNILCBBQ0spCiAgICAgICAg MC4uLiAuLi4uID0gQ29uZ2VzdGlvbiBXaW5kb3cgUmVkdWNlZCAoQ1dSKTog Tm90IHNldAogICAgICAgIC4wLi4gLi4uLiA9IEVDTi1FY2hvOiBOb3Qgc2V0 CiAgICAgICAgLi4wLiAuLi4uID0gVXJnZW50OiBOb3Qgc2V0CiAgICAgICAg Li4uMSAuLi4uID0gQWNrbm93bGVkZ21lbnQ6IFNldAogICAgICAgIC4uLi4g MS4uLiA9IFB1c2g6IFNldAogICAgICAgIC4uLi4gLjAuLiA9IFJlc2V0OiBO b3Qgc2V0CiAgICAgICAgLi4uLiAuLjAuID0gU3luOiBOb3Qgc2V0CiAgICAg ICAgLi4uLiAuLi4wID0gRmluOiBOb3Qgc2V0CiAgICBXaW5kb3cgc2l6ZTog NjU1MzUKICAgIENoZWNrc3VtOiAweDgwZTggW2NvcnJlY3RdCiAgICAgICAg W0dvb2QgQ2hlY2tzdW06IFRydWVdCiAgICAgICAgW0JhZCBDaGVja3N1bTog RmFsc2VdCiAgICBbU0VRL0FDSyBhbmFseXNpc10KICAgICAgICBbVGhpcyBp cyBhbiBBQ0sgdG8gdGhlIHNlZ21lbnQgaW4gZnJhbWU6IDIyXQogICAgICAg IFtUaGUgUlRUIHRvIEFDSyB0aGUgc2VnbWVudCB3YXM6IDAuMDAwMjIyMDAw IHNlY29uZHNdClJlbW90ZSBQcm9jZWR1cmUgQ2FsbCwgVHlwZTpSZXBseSBY SUQ6MHg1N2RiZDRlYQogICAgRnJhZ21lbnQgaGVhZGVyOiBMYXN0IGZyYWdt ZW50LCAzNiBieXRlcwogICAgICAgIDEuLi4gLi4uLiAuLi4uIC4uLi4gLi4u LiAuLi4uIC4uLi4gLi4uLiA9IExhc3QgRnJhZ21lbnQ6IFllcwogICAgICAg IC4wMDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAwMDAwIDAwMTAgMDEwMCA9IEZy YWdtZW50IExlbmd0aDogMzYKICAgIFhJRDogMHg1N2RiZDRlYSAoMTQ3NDAy NDY4MikKICAgIE1lc3NhZ2UgVHlwZTogUmVwbHkgKDEpCiAgICBbUHJvZ3Jh bTogTkZTICgxMDAwMDMpXQogICAgW1Byb2dyYW0gVmVyc2lvbjogM10KICAg IFtQcm9jZWR1cmU6IFdSSVRFICg3KV0KICAgIFJlcGx5IFN0YXRlOiBhY2Nl cHRlZCAoMCkKICAgIFtUaGlzIGlzIGEgcmVwbHkgdG8gYSByZXF1ZXN0IGlu IGZyYW1lIDIyXQogICAgW1RpbWUgZnJvbSByZXF1ZXN0OiAwLjAwMDIyMjAw MCBzZWNvbmRzXQogICAgVmVyaWZpZXIKICAgICAgICBGbGF2b3I6IEFVVEhf TlVMTCAoMCkKICAgICAgICBMZW5ndGg6IDAKICAgIEFjY2VwdCBTdGF0ZTog UlBDIGV4ZWN1dGVkIHN1Y2Nlc3NmdWxseSAoMCkKTmV0d29yayBGaWxlIFN5 c3RlbSwgV1JJVEUgUmVwbHkgIEVycm9yOk5GUzNFUlJfSU8KICAgIFtQcm9n cmFtIFZlcnNpb246IDNdCiAgICBbVjMgUHJvY2VkdXJlOiBXUklURSAoNyld CiAgICBTdGF0dXM6IE5GUzNFUlJfSU8gKDUpCiAgICBmaWxlX3djYwogICAg ICAgIGJlZm9yZQogICAgICAgICAgICBhdHRyaWJ1dGVzX2ZvbGxvdzogbm8g dmFsdWUgKDApCiAgICAgICAgYWZ0ZXIKICAgICAgICAgICAgYXR0cmlidXRl c19mb2xsb3c6IG5vIHZhbHVlICgwKQoKMDAwMCAgMDAgMzAgNDggN2IgNTIg MzQgMDAgMTUgMTcgYmYgZWIgN2IgMDggMDAgNDUgMDAgICAuMEh7UjQuLi4u LnsuLkUuCjAwMTAgIDAwIDUwIGI4IGUwIDQwIDAwIDQwIDA2IGZiIDU0IGMw IGE4IDAyIDg5IGMwIGE4ICAgLlAuLkAuQC4uVC4uLi4uLgowMDIwICAwMiA5 OSAwOCAwMSAwMiA2NiBlZSBjMyBiZiBjYSAyMiBkZCAxZiA4NiA1MCAxOCAg IC4uLi4uZi4uLi4iLi4uUC4KMDAzMCAgZmYgZmYgODAgZTggMDAgMDAgODAg MDAgMDAgMjQgNTcgZGIgZDQgZWEgMDAgMDAgICAuLi4uLi4uLi4kVy4uLi4u CjAwNDAgIDAwIDAxIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwICAgLi4uLi4uLi4uLi4uLi4uLgowMDUwICAwMCAwMCAwMCAw MCAwMCAwNSAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAgICAgICAgIC4uLi4u Li4uLi4uLi4uCgpOby4gICAgIFRpbWUgICAgICAgIFNvdXJjZSAgICAgICAg ICAgICAgICBEZXN0aW5hdGlvbiAgICAgICAgICAgUHJvdG9jb2wgSW5mbwog ICAgIDI0IDAuMDAyNzc1ICAgIDE5Mi4xNjguMi4xNTMgICAgICAgICAxOTIu MTY4LjIuMTM3ICAgICAgICAgTkZTICAgICAgVjMgV1JJVEUgQ2FsbCAoUmVw bHkgSW4gMjUpLCBGSDoweDgxMDYwMmZjIE9mZnNldDowIExlbjoxNSBVTlNU QUJMRQoKRnJhbWUgMjQgKDE5MCBieXRlcyBvbiB3aXJlLCAxOTAgYnl0ZXMg Y2FwdHVyZWQpCiAgICBBcnJpdmFsIFRpbWU6IEphbiAzMCwgMjAxMCAxMjo0 MTo0Ni45MTM2MDMwMDAKICAgIFtUaW1lIGRlbHRhIGZyb20gcHJldmlvdXMg Y2FwdHVyZWQgZnJhbWU6IDAuMDAwMDI4MDAwIHNlY29uZHNdCiAgICBbVGlt ZSBkZWx0YSBmcm9tIHByZXZpb3VzIGRpc3BsYXllZCBmcmFtZTogMC4wMDAw MjgwMDAgc2Vjb25kc10KICAgIFtUaW1lIHNpbmNlIHJlZmVyZW5jZSBvciBm aXJzdCBmcmFtZTogMC4wMDI3NzUwMDAgc2Vjb25kc10KICAgIEZyYW1lIE51 bWJlcjogMjQKICAgIEZyYW1lIExlbmd0aDogMTkwIGJ5dGVzCiAgICBDYXB0 dXJlIExlbmd0aDogMTkwIGJ5dGVzCiAgICBbRnJhbWUgaXMgbWFya2VkOiBG YWxzZV0KICAgIFtQcm90b2NvbHMgaW4gZnJhbWU6IGV0aDppcDp0Y3A6cnBj Om5mc10KICAgIFtDb2xvcmluZyBSdWxlIE5hbWU6IENoZWNrc3VtIEVycm9y c10KICAgIFtDb2xvcmluZyBSdWxlIFN0cmluZzogY2RwLmNoZWNrc3VtX2Jh ZD09MSB8fCBlZHAuY2hlY2tzdW1fYmFkPT0xIHx8IGlwLmNoZWNrc3VtX2Jh ZD09MSB8fCB0Y3AuY2hlY2tzdW1fYmFkPT0xIHx8IHVkcC5jaGVja3N1bV9i YWQ9PTFdCkV0aGVybmV0IElJLCBTcmM6IFN1cGVybWljXzdiOjUyOjM0ICgw MDozMDo0ODo3Yjo1MjozNCksIERzdDogSW50ZWxDb3JfYmY6ZWI6N2IgKDAw OjE1OjE3OmJmOmViOjdiKQogICAgRGVzdGluYXRpb246IEludGVsQ29yX2Jm OmViOjdiICgwMDoxNToxNzpiZjplYjo3YikKICAgICAgICBBZGRyZXNzOiBJ bnRlbENvcl9iZjplYjo3YiAoMDA6MTU6MTc6YmY6ZWI6N2IpCiAgICAgICAg Li4uLiAuLi4wIC4uLi4gLi4uLiAuLi4uIC4uLi4gPSBJRyBiaXQ6IEluZGl2 aWR1YWwgYWRkcmVzcyAodW5pY2FzdCkKICAgICAgICAuLi4uIC4uMC4gLi4u LiAuLi4uIC4uLi4gLi4uLiA9IExHIGJpdDogR2xvYmFsbHkgdW5pcXVlIGFk ZHJlc3MgKGZhY3RvcnkgZGVmYXVsdCkKICAgIFNvdXJjZTogU3VwZXJtaWNf N2I6NTI6MzQgKDAwOjMwOjQ4OjdiOjUyOjM0KQogICAgICAgIEFkZHJlc3M6 IFN1cGVybWljXzdiOjUyOjM0ICgwMDozMDo0ODo3Yjo1MjozNCkKICAgICAg ICAuLi4uIC4uLjAgLi4uLiAuLi4uIC4uLi4gLi4uLiA9IElHIGJpdDogSW5k aXZpZHVhbCBhZGRyZXNzICh1bmljYXN0KQogICAgICAgIC4uLi4gLi4wLiAu Li4uIC4uLi4gLi4uLiAuLi4uID0gTEcgYml0OiBHbG9iYWxseSB1bmlxdWUg YWRkcmVzcyAoZmFjdG9yeSBkZWZhdWx0KQogICAgVHlwZTogSVAgKDB4MDgw MCkKSW50ZXJuZXQgUHJvdG9jb2wsIFNyYzogMTkyLjE2OC4yLjE1MyAoMTky LjE2OC4yLjE1MyksIERzdDogMTkyLjE2OC4yLjEzNyAoMTkyLjE2OC4yLjEz NykKICAgIFZlcnNpb246IDQKICAgIEhlYWRlciBsZW5ndGg6IDIwIGJ5dGVz CiAgICBEaWZmZXJlbnRpYXRlZCBTZXJ2aWNlcyBGaWVsZDogMHgwMCAoRFND UCAweDAwOiBEZWZhdWx0OyBFQ046IDB4MDApCiAgICAgICAgMDAwMCAwMC4u ID0gRGlmZmVyZW50aWF0ZWQgU2VydmljZXMgQ29kZXBvaW50OiBEZWZhdWx0 ICgweDAwKQogICAgICAgIC4uLi4gLi4wLiA9IEVDTi1DYXBhYmxlIFRyYW5z cG9ydCAoRUNUKTogMAogICAgICAgIC4uLi4gLi4uMCA9IEVDTi1DRTogMAog ICAgVG90YWwgTGVuZ3RoOiAxNzYKICAgIElkZW50aWZpY2F0aW9uOiAweGY4 YjUgKDYzNjY5KQogICAgRmxhZ3M6IDB4MDQgKERvbid0IEZyYWdtZW50KQog ICAgICAgIDAuLi4gPSBSZXNlcnZlZCBiaXQ6IE5vdCBzZXQKICAgICAgICAu MS4uID0gRG9uJ3QgZnJhZ21lbnQ6IFNldAogICAgICAgIC4uMC4gPSBNb3Jl IGZyYWdtZW50czogTm90IHNldAogICAgRnJhZ21lbnQgb2Zmc2V0OiAwCiAg ICBUaW1lIHRvIGxpdmU6IDY0CiAgICBQcm90b2NvbDogVENQICgweDA2KQog ICAgSGVhZGVyIGNoZWNrc3VtOiAweGJiMWYgW2NvcnJlY3RdCiAgICAgICAg W0dvb2Q6IFRydWVdCiAgICAgICAgW0JhZCA6IEZhbHNlXQogICAgU291cmNl OiAxOTIuMTY4LjIuMTUzICgxOTIuMTY4LjIuMTUzKQogICAgRGVzdGluYXRp b246IDE5Mi4xNjguMi4xMzcgKDE5Mi4xNjguMi4xMzcpClRyYW5zbWlzc2lv biBDb250cm9sIFByb3RvY29sLCBTcmMgUG9ydDogc3NoZWxsICg2MTQpLCBE c3QgUG9ydDogbmZzICgyMDQ5KSwgU2VxOiAxNDk3LCBBY2s6IDQ4MSwgTGVu OiAxMzYKICAgIFNvdXJjZSBwb3J0OiBzc2hlbGwgKDYxNCkKICAgIERlc3Rp bmF0aW9uIHBvcnQ6IG5mcyAoMjA0OSkKICAgIFNlcXVlbmNlIG51bWJlcjog MTQ5NyAgICAocmVsYXRpdmUgc2VxdWVuY2UgbnVtYmVyKQogICAgW05leHQg c2VxdWVuY2UgbnVtYmVyOiAxNjMzICAgIChyZWxhdGl2ZSBzZXF1ZW5jZSBu dW1iZXIpXQogICAgQWNrbm93bGVkZ2VtZW50IG51bWJlcjogNDgxICAgIChy ZWxhdGl2ZSBhY2sgbnVtYmVyKQogICAgSGVhZGVyIGxlbmd0aDogMjAgYnl0 ZXMKICAgIEZsYWdzOiAweDE4IChQU0gsIEFDSykKICAgICAgICAwLi4uIC4u Li4gPSBDb25nZXN0aW9uIFdpbmRvdyBSZWR1Y2VkIChDV1IpOiBOb3Qgc2V0 CiAgICAgICAgLjAuLiAuLi4uID0gRUNOLUVjaG86IE5vdCBzZXQKICAgICAg ICAuLjAuIC4uLi4gPSBVcmdlbnQ6IE5vdCBzZXQKICAgICAgICAuLi4xIC4u Li4gPSBBY2tub3dsZWRnbWVudDogU2V0CiAgICAgICAgLi4uLiAxLi4uID0g UHVzaDogU2V0CiAgICAgICAgLi4uLiAuMC4uID0gUmVzZXQ6IE5vdCBzZXQK ICAgICAgICAuLi4uIC4uMC4gPSBTeW46IE5vdCBzZXQKICAgICAgICAuLi4u IC4uLjAgPSBGaW46IE5vdCBzZXQKICAgIFdpbmRvdyBzaXplOiA2NTUzNQog ICAgQ2hlY2tzdW06IDB4ODcxNSBbaW5jb3JyZWN0LCBzaG91bGQgYmUgMHhl ODI5IChtYXliZSBjYXVzZWQgYnkgIlRDUCBjaGVja3N1bSBvZmZsb2FkIj8p XQogICAgICAgIFtHb29kIENoZWNrc3VtOiBGYWxzZV0KICAgICAgICBbQmFk IENoZWNrc3VtOiBUcnVlXQogICAgW1NFUS9BQ0sgYW5hbHlzaXNdCiAgICAg ICAgW1RoaXMgaXMgYW4gQUNLIHRvIHRoZSBzZWdtZW50IGluIGZyYW1lOiAy M10KICAgICAgICBbVGhlIFJUVCB0byBBQ0sgdGhlIHNlZ21lbnQgd2FzOiAw LjAwMDAyODAwMCBzZWNvbmRzXQpSZW1vdGUgUHJvY2VkdXJlIENhbGwsIFR5 cGU6Q2FsbCBYSUQ6MHg1N2RiZDRlYgogICAgRnJhZ21lbnQgaGVhZGVyOiBM YXN0IGZyYWdtZW50LCAxMzIgYnl0ZXMKICAgICAgICAxLi4uIC4uLi4gLi4u LiAuLi4uIC4uLi4gLi4uLiAuLi4uIC4uLi4gPSBMYXN0IEZyYWdtZW50OiBZ ZXMKICAgICAgICAuMDAwIDAwMDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAxMDAw IDAxMDAgPSBGcmFnbWVudCBMZW5ndGg6IDEzMgogICAgWElEOiAweDU3ZGJk NGViICgxNDc0MDI0NjgzKQogICAgTWVzc2FnZSBUeXBlOiBDYWxsICgwKQog ICAgUlBDIFZlcnNpb246IDIKICAgIFByb2dyYW06IE5GUyAoMTAwMDAzKQog ICAgUHJvZ3JhbSBWZXJzaW9uOiAzCiAgICBQcm9jZWR1cmU6IFdSSVRFICg3 KQogICAgW1RoZSByZXBseSB0byB0aGlzIHJlcXVlc3QgaXMgaW4gZnJhbWUg MjVdCiAgICBDcmVkZW50aWFscwogICAgICAgIEZsYXZvcjogQVVUSF9VTklY ICgxKQogICAgICAgIExlbmd0aDogMjQKICAgICAgICBTdGFtcDogMHgwMDAw MDAwMAogICAgICAgIE1hY2hpbmUgTmFtZTogPEVNUFRZPgogICAgICAgICAg ICBsZW5ndGg6IDAKICAgICAgICAgICAgY29udGVudHM6IDxFTVBUWT4KICAg ICAgICBVSUQ6IDgwCiAgICAgICAgR0lEOiA4MAogICAgICAgIEF1eGlsaWFy eSBHSURzCiAgICAgICAgICAgIEdJRDogODAKICAgIFZlcmlmaWVyCiAgICAg ICAgRmxhdm9yOiBBVVRIX05VTEwgKDApCiAgICAgICAgTGVuZ3RoOiAwCk5l dHdvcmsgRmlsZSBTeXN0ZW0sIFdSSVRFIENhbGwgRkg6MHg4MTA2MDJmYyBP ZmZzZXQ6MCBMZW46MTUgVU5TVEFCTEUKICAgIFtQcm9ncmFtIFZlcnNpb246 IDNdCiAgICBbVjMgUHJvY2VkdXJlOiBXUklURSAoNyldCiAgICBmaWxlCiAg ICAgICAgbGVuZ3RoOiAyOAogICAgICAgIFtoYXNoOiAweDgxMDYwMmZjXQog ICAgICAgIGRlY29kZSB0eXBlIGFzOiB1bmtub3duCiAgICAgICAgZmlsZWhh bmRsZTogOEIyNjk2QTkwN0JGMEVENDBBMDAxRjg3MDUwMDAwMDAwMjlGMDQw MDAwMDAwMDAwLi4uCiAgICBvZmZzZXQ6IDAKICAgIGNvdW50OiAxNQogICAg U3RhYmxlOiBVTlNUQUJMRSAoMCkKICAgIERhdGE6IDxEQVRBPgogICAgICAg IGxlbmd0aDogMTUKICAgICAgICBjb250ZW50czogPERBVEE+CiAgICAgICAg ZmlsbCBieXRlczogb3BhcXVlIGRhdGEKCjAwMDAgIDAwIDE1IDE3IGJmIGVi IDdiIDAwIDMwIDQ4IDdiIDUyIDM0IDA4IDAwIDQ1IDAwICAgLi4uLi57LjBI e1I0Li5FLgowMDEwICAwMCBiMCBmOCBiNSA0MCAwMCA0MCAwNiBiYiAxZiBj MCBhOCAwMiA5OSBjMCBhOCAgIC4uLi5ALkAuLi4uLi4uLi4KMDAyMCAgMDIg ODkgMDIgNjYgMDggMDEgMjIgZGQgMWYgODYgZWUgYzMgYmYgZjIgNTAgMTgg ICAuLi5mLi4iLi4uLi4uLlAuCjAwMzAgIGZmIGZmIDg3IDE1IDAwIDAwIDgw IDAwIDAwIDg0IDU3IGRiIGQ0IGViIDAwIDAwICAgLi4uLi4uLi4uLlcuLi4u LgowMDQwICAwMCAwMCAwMCAwMCAwMCAwMiAwMCAwMSA4NiBhMyAwMCAwMCAw MCAwMyAwMCAwMCAgIC4uLi4uLi4uLi4uLi4uLi4KMDA1MCAgMDAgMDcgMDAg MDAgMDAgMDEgMDAgMDAgMDAgMTggMDAgMDAgMDAgMDAgMDAgMDAgICAuLi4u Li4uLi4uLi4uLi4uCjAwNjAgIDAwIDAwIDAwIDAwIDAwIDUwIDAwIDAwIDAw IDUwIDAwIDAwIDAwIDAxIDAwIDAwICAgLi4uLi5QLi4uUC4uLi4uLgowMDcw ICAwMCA1MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAxYyA4 YiAyNiAgIC5QLi4uLi4uLi4uLi4uLiYKMDA4MCAgOTYgYTkgMDcgYmYgMGUg ZDQgMGEgMDAgMWYgODcgMDUgMDAgMDAgMDAgMDIgOWYgICAuLi4uLi4uLi4u Li4uLi4uCjAwOTAgIDA0IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwICAgLi4uLi4uLi4uLi4uLi4uLgowMGEwICAwMCAw MCAwMCAwMCAwMCAwZiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwZiAzOCAzOSAg IC4uLi4uLi4uLi4uLi4uODkKMDBiMCAgMzkgMzggMzggMjAgMzIgMzYgMzIg MzEgMzQgMzQgMzAgMzAgMzAgMDAgICAgICAgICA5ODggMjYyMTQ0MDAwLgoK Tm8uICAgICBUaW1lICAgICAgICBTb3VyY2UgICAgICAgICAgICAgICAgRGVz dGluYXRpb24gICAgICAgICAgIFByb3RvY29sIEluZm8KICAgICAyNSAwLjAw Mjk5NiAgICAxOTIuMTY4LjIuMTM3ICAgICAgICAgMTkyLjE2OC4yLjE1MyAg ICAgICAgIE5GUyAgICAgIFYzIFdSSVRFIFJlcGx5IChDYWxsIEluIDI0KSBF cnJvcjpORlMzRVJSX0lPCgpGcmFtZSAyNSAoOTQgYnl0ZXMgb24gd2lyZSwg OTQgYnl0ZXMgY2FwdHVyZWQpCiAgICBBcnJpdmFsIFRpbWU6IEphbiAzMCwg MjAxMCAxMjo0MTo0Ni45MTM4MjQwMDAKICAgIFtUaW1lIGRlbHRhIGZyb20g cHJldmlvdXMgY2FwdHVyZWQgZnJhbWU6IDAuMDAwMjIxMDAwIHNlY29uZHNd CiAgICBbVGltZSBkZWx0YSBmcm9tIHByZXZpb3VzIGRpc3BsYXllZCBmcmFt ZTogMC4wMDAyMjEwMDAgc2Vjb25kc10KICAgIFtUaW1lIHNpbmNlIHJlZmVy ZW5jZSBvciBmaXJzdCBmcmFtZTogMC4wMDI5OTYwMDAgc2Vjb25kc10KICAg IEZyYW1lIE51bWJlcjogMjUKICAgIEZyYW1lIExlbmd0aDogOTQgYnl0ZXMK ICAgIENhcHR1cmUgTGVuZ3RoOiA5NCBieXRlcwogICAgW0ZyYW1lIGlzIG1h cmtlZDogRmFsc2VdCiAgICBbUHJvdG9jb2xzIGluIGZyYW1lOiBldGg6aXA6 dGNwOnJwY10KICAgIFtDb2xvcmluZyBSdWxlIE5hbWU6IFRDUF0KICAgIFtD b2xvcmluZyBSdWxlIFN0cmluZzogdGNwXQpFdGhlcm5ldCBJSSwgU3JjOiBJ bnRlbENvcl9iZjplYjo3YiAoMDA6MTU6MTc6YmY6ZWI6N2IpLCBEc3Q6IFN1 cGVybWljXzdiOjUyOjM0ICgwMDozMDo0ODo3Yjo1MjozNCkKICAgIERlc3Rp bmF0aW9uOiBTdXBlcm1pY183Yjo1MjozNCAoMDA6MzA6NDg6N2I6NTI6MzQp CiAgICAgICAgQWRkcmVzczogU3VwZXJtaWNfN2I6NTI6MzQgKDAwOjMwOjQ4 OjdiOjUyOjM0KQogICAgICAgIC4uLi4gLi4uMCAuLi4uIC4uLi4gLi4uLiAu Li4uID0gSUcgYml0OiBJbmRpdmlkdWFsIGFkZHJlc3MgKHVuaWNhc3QpCiAg ICAgICAgLi4uLiAuLjAuIC4uLi4gLi4uLiAuLi4uIC4uLi4gPSBMRyBiaXQ6 IEdsb2JhbGx5IHVuaXF1ZSBhZGRyZXNzIChmYWN0b3J5IGRlZmF1bHQpCiAg ICBTb3VyY2U6IEludGVsQ29yX2JmOmViOjdiICgwMDoxNToxNzpiZjplYjo3 YikKICAgICAgICBBZGRyZXNzOiBJbnRlbENvcl9iZjplYjo3YiAoMDA6MTU6 MTc6YmY6ZWI6N2IpCiAgICAgICAgLi4uLiAuLi4wIC4uLi4gLi4uLiAuLi4u IC4uLi4gPSBJRyBiaXQ6IEluZGl2aWR1YWwgYWRkcmVzcyAodW5pY2FzdCkK ICAgICAgICAuLi4uIC4uMC4gLi4uLiAuLi4uIC4uLi4gLi4uLiA9IExHIGJp dDogR2xvYmFsbHkgdW5pcXVlIGFkZHJlc3MgKGZhY3RvcnkgZGVmYXVsdCkK ICAgIFR5cGU6IElQICgweDA4MDApCkludGVybmV0IFByb3RvY29sLCBTcmM6 IDE5Mi4xNjguMi4xMzcgKDE5Mi4xNjguMi4xMzcpLCBEc3Q6IDE5Mi4xNjgu Mi4xNTMgKDE5Mi4xNjguMi4xNTMpCiAgICBWZXJzaW9uOiA0CiAgICBIZWFk ZXIgbGVuZ3RoOiAyMCBieXRlcwogICAgRGlmZmVyZW50aWF0ZWQgU2Vydmlj ZXMgRmllbGQ6IDB4MDAgKERTQ1AgMHgwMDogRGVmYXVsdDsgRUNOOiAweDAw KQogICAgICAgIDAwMDAgMDAuLiA9IERpZmZlcmVudGlhdGVkIFNlcnZpY2Vz IENvZGVwb2ludDogRGVmYXVsdCAoMHgwMCkKICAgICAgICAuLi4uIC4uMC4g PSBFQ04tQ2FwYWJsZSBUcmFuc3BvcnQgKEVDVCk6IDAKICAgICAgICAuLi4u IC4uLjAgPSBFQ04tQ0U6IDAKICAgIFRvdGFsIExlbmd0aDogODAKICAgIElk ZW50aWZpY2F0aW9uOiAweGI4ZTEgKDQ3MzI5KQogICAgRmxhZ3M6IDB4MDQg KERvbid0IEZyYWdtZW50KQogICAgICAgIDAuLi4gPSBSZXNlcnZlZCBiaXQ6 IE5vdCBzZXQKICAgICAgICAuMS4uID0gRG9uJ3QgZnJhZ21lbnQ6IFNldAog ICAgICAgIC4uMC4gPSBNb3JlIGZyYWdtZW50czogTm90IHNldAogICAgRnJh Z21lbnQgb2Zmc2V0OiAwCiAgICBUaW1lIHRvIGxpdmU6IDY0CiAgICBQcm90 b2NvbDogVENQICgweDA2KQogICAgSGVhZGVyIGNoZWNrc3VtOiAweGZiNTMg W2NvcnJlY3RdCiAgICAgICAgW0dvb2Q6IFRydWVdCiAgICAgICAgW0JhZCA6 IEZhbHNlXQogICAgU291cmNlOiAxOTIuMTY4LjIuMTM3ICgxOTIuMTY4LjIu MTM3KQogICAgRGVzdGluYXRpb246IDE5Mi4xNjguMi4xNTMgKDE5Mi4xNjgu Mi4xNTMpClRyYW5zbWlzc2lvbiBDb250cm9sIFByb3RvY29sLCBTcmMgUG9y dDogbmZzICgyMDQ5KSwgRHN0IFBvcnQ6IHNzaGVsbCAoNjE0KSwgU2VxOiA0 ODEsIEFjazogMTYzMywgTGVuOiA0MAogICAgU291cmNlIHBvcnQ6IG5mcyAo MjA0OSkKICAgIERlc3RpbmF0aW9uIHBvcnQ6IHNzaGVsbCAoNjE0KQogICAg U2VxdWVuY2UgbnVtYmVyOiA0ODEgICAgKHJlbGF0aXZlIHNlcXVlbmNlIG51 bWJlcikKICAgIFtOZXh0IHNlcXVlbmNlIG51bWJlcjogNTIxICAgIChyZWxh dGl2ZSBzZXF1ZW5jZSBudW1iZXIpXQogICAgQWNrbm93bGVkZ2VtZW50IG51 bWJlcjogMTYzMyAgICAocmVsYXRpdmUgYWNrIG51bWJlcikKICAgIEhlYWRl ciBsZW5ndGg6IDIwIGJ5dGVzCiAgICBGbGFnczogMHgxOCAoUFNILCBBQ0sp CiAgICAgICAgMC4uLiAuLi4uID0gQ29uZ2VzdGlvbiBXaW5kb3cgUmVkdWNl ZCAoQ1dSKTogTm90IHNldAogICAgICAgIC4wLi4gLi4uLiA9IEVDTi1FY2hv OiBOb3Qgc2V0CiAgICAgICAgLi4wLiAuLi4uID0gVXJnZW50OiBOb3Qgc2V0 CiAgICAgICAgLi4uMSAuLi4uID0gQWNrbm93bGVkZ21lbnQ6IFNldAogICAg ICAgIC4uLi4gMS4uLiA9IFB1c2g6IFNldAogICAgICAgIC4uLi4gLjAuLiA9 IFJlc2V0OiBOb3Qgc2V0CiAgICAgICAgLi4uLiAuLjAuID0gU3luOiBOb3Qg c2V0CiAgICAgICAgLi4uLiAuLi4wID0gRmluOiBOb3Qgc2V0CiAgICBXaW5k b3cgc2l6ZTogNjU1MzUKICAgIENoZWNrc3VtOiAweDgwMzcgW2NvcnJlY3Rd CiAgICAgICAgW0dvb2QgQ2hlY2tzdW06IFRydWVdCiAgICAgICAgW0JhZCBD aGVja3N1bTogRmFsc2VdCiAgICBbU0VRL0FDSyBhbmFseXNpc10KICAgICAg ICBbVGhpcyBpcyBhbiBBQ0sgdG8gdGhlIHNlZ21lbnQgaW4gZnJhbWU6IDI0 XQogICAgICAgIFtUaGUgUlRUIHRvIEFDSyB0aGUgc2VnbWVudCB3YXM6IDAu MDAwMjIxMDAwIHNlY29uZHNdClJlbW90ZSBQcm9jZWR1cmUgQ2FsbCwgVHlw ZTpSZXBseSBYSUQ6MHg1N2RiZDRlYgogICAgRnJhZ21lbnQgaGVhZGVyOiBM YXN0IGZyYWdtZW50LCAzNiBieXRlcwogICAgICAgIDEuLi4gLi4uLiAuLi4u IC4uLi4gLi4uLiAuLi4uIC4uLi4gLi4uLiA9IExhc3QgRnJhZ21lbnQ6IFll cwogICAgICAgIC4wMDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAwMDAwIDAwMTAg MDEwMCA9IEZyYWdtZW50IExlbmd0aDogMzYKICAgIFhJRDogMHg1N2RiZDRl YiAoMTQ3NDAyNDY4MykKICAgIE1lc3NhZ2UgVHlwZTogUmVwbHkgKDEpCiAg ICBbUHJvZ3JhbTogTkZTICgxMDAwMDMpXQogICAgW1Byb2dyYW0gVmVyc2lv bjogM10KICAgIFtQcm9jZWR1cmU6IFdSSVRFICg3KV0KICAgIFJlcGx5IFN0 YXRlOiBhY2NlcHRlZCAoMCkKICAgIFtUaGlzIGlzIGEgcmVwbHkgdG8gYSBy ZXF1ZXN0IGluIGZyYW1lIDI0XQogICAgW1RpbWUgZnJvbSByZXF1ZXN0OiAw LjAwMDIyMTAwMCBzZWNvbmRzXQogICAgVmVyaWZpZXIKICAgICAgICBGbGF2 b3I6IEFVVEhfTlVMTCAoMCkKICAgICAgICBMZW5ndGg6IDAKICAgIEFjY2Vw dCBTdGF0ZTogUlBDIGV4ZWN1dGVkIHN1Y2Nlc3NmdWxseSAoMCkKTmV0d29y ayBGaWxlIFN5c3RlbSwgV1JJVEUgUmVwbHkgIEVycm9yOk5GUzNFUlJfSU8K ICAgIFtQcm9ncmFtIFZlcnNpb246IDNdCiAgICBbVjMgUHJvY2VkdXJlOiBX UklURSAoNyldCiAgICBTdGF0dXM6IE5GUzNFUlJfSU8gKDUpCiAgICBmaWxl X3djYwogICAgICAgIGJlZm9yZQogICAgICAgICAgICBhdHRyaWJ1dGVzX2Zv bGxvdzogbm8gdmFsdWUgKDApCiAgICAgICAgYWZ0ZXIKICAgICAgICAgICAg YXR0cmlidXRlc19mb2xsb3c6IG5vIHZhbHVlICgwKQoKMDAwMCAgMDAgMzAg NDggN2IgNTIgMzQgMDAgMTUgMTcgYmYgZWIgN2IgMDggMDAgNDUgMDAgICAu MEh7UjQuLi4uLnsuLkUuCjAwMTAgIDAwIDUwIGI4IGUxIDQwIDAwIDQwIDA2 IGZiIDUzIGMwIGE4IDAyIDg5IGMwIGE4ICAgLlAuLkAuQC4uUy4uLi4uLgow MDIwICAwMiA5OSAwOCAwMSAwMiA2NiBlZSBjMyBiZiBmMiAyMiBkZCAyMCAw ZSA1MCAxOCAgIC4uLi4uZi4uLi4iLiAuUC4KMDAzMCAgZmYgZmYgODAgMzcg MDAgMDAgODAgMDAgMDAgMjQgNTcgZGIgZDQgZWIgMDAgMDAgICAuLi43Li4u Li4kVy4uLi4uCjAwNDAgIDAwIDAxIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwICAgLi4uLi4uLi4uLi4uLi4uLgowMDUwICAw MCAwMCAwMCAwMCAwMCAwNSAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAgICAg ICAgIC4uLi4uLi4uLi4uLi4uCgpOby4gICAgIFRpbWUgICAgICAgIFNvdXJj ZSAgICAgICAgICAgICAgICBEZXN0aW5hdGlvbiAgICAgICAgICAgUHJvdG9j b2wgSW5mbwogICAgIDI2IDAuMDAzMDI1ICAgIDE5Mi4xNjguMi4xNTMgICAg ICAgICAxOTIuMTY4LjIuMTM3ICAgICAgICAgTkZTICAgICAgVjMgV1JJVEUg Q2FsbCAoUmVwbHkgSW4gMjcpLCBGSDoweDgxMDYwMmZjIE9mZnNldDowIExl bjoxNSBVTlNUQUJMRQoKRnJhbWUgMjYgKDE5MCBieXRlcyBvbiB3aXJlLCAx OTAgYnl0ZXMgY2FwdHVyZWQpCiAgICBBcnJpdmFsIFRpbWU6IEphbiAzMCwg MjAxMCAxMjo0MTo0Ni45MTM4NTMwMDAKICAgIFtUaW1lIGRlbHRhIGZyb20g cHJldmlvdXMgY2FwdHVyZWQgZnJhbWU6IDAuMDAwMDI5MDAwIHNlY29uZHNd CiAgICBbVGltZSBkZWx0YSBmcm9tIHByZXZpb3VzIGRpc3BsYXllZCBmcmFt ZTogMC4wMDAwMjkwMDAgc2Vjb25kc10KICAgIFtUaW1lIHNpbmNlIHJlZmVy ZW5jZSBvciBmaXJzdCBmcmFtZTogMC4wMDMwMjUwMDAgc2Vjb25kc10KICAg IEZyYW1lIE51bWJlcjogMjYKICAgIEZyYW1lIExlbmd0aDogMTkwIGJ5dGVz CiAgICBDYXB0dXJlIExlbmd0aDogMTkwIGJ5dGVzCiAgICBbRnJhbWUgaXMg bWFya2VkOiBGYWxzZV0KICAgIFtQcm90b2NvbHMgaW4gZnJhbWU6IGV0aDpp cDp0Y3A6cnBjOm5mc10KICAgIFtDb2xvcmluZyBSdWxlIE5hbWU6IENoZWNr c3VtIEVycm9yc10KICAgIFtDb2xvcmluZyBSdWxlIFN0cmluZzogY2RwLmNo ZWNrc3VtX2JhZD09MSB8fCBlZHAuY2hlY2tzdW1fYmFkPT0xIHx8IGlwLmNo ZWNrc3VtX2JhZD09MSB8fCB0Y3AuY2hlY2tzdW1fYmFkPT0xIHx8IHVkcC5j aGVja3N1bV9iYWQ9PTFdCkV0aGVybmV0IElJLCBTcmM6IFN1cGVybWljXzdi OjUyOjM0ICgwMDozMDo0ODo3Yjo1MjozNCksIERzdDogSW50ZWxDb3JfYmY6 ZWI6N2IgKDAwOjE1OjE3OmJmOmViOjdiKQogICAgRGVzdGluYXRpb246IElu dGVsQ29yX2JmOmViOjdiICgwMDoxNToxNzpiZjplYjo3YikKICAgICAgICBB ZGRyZXNzOiBJbnRlbENvcl9iZjplYjo3YiAoMDA6MTU6MTc6YmY6ZWI6N2Ip CiAgICAgICAgLi4uLiAuLi4wIC4uLi4gLi4uLiAuLi4uIC4uLi4gPSBJRyBi aXQ6IEluZGl2aWR1YWwgYWRkcmVzcyAodW5pY2FzdCkKICAgICAgICAuLi4u IC4uMC4gLi4uLiAuLi4uIC4uLi4gLi4uLiA9IExHIGJpdDogR2xvYmFsbHkg dW5pcXVlIGFkZHJlc3MgKGZhY3RvcnkgZGVmYXVsdCkKICAgIFNvdXJjZTog U3VwZXJtaWNfN2I6NTI6MzQgKDAwOjMwOjQ4OjdiOjUyOjM0KQogICAgICAg IEFkZHJlc3M6IFN1cGVybWljXzdiOjUyOjM0ICgwMDozMDo0ODo3Yjo1Mjoz NCkKICAgICAgICAuLi4uIC4uLjAgLi4uLiAuLi4uIC4uLi4gLi4uLiA9IElH IGJpdDogSW5kaXZpZHVhbCBhZGRyZXNzICh1bmljYXN0KQogICAgICAgIC4u Li4gLi4wLiAuLi4uIC4uLi4gLi4uLiAuLi4uID0gTEcgYml0OiBHbG9iYWxs eSB1bmlxdWUgYWRkcmVzcyAoZmFjdG9yeSBkZWZhdWx0KQogICAgVHlwZTog SVAgKDB4MDgwMCkKSW50ZXJuZXQgUHJvdG9jb2wsIFNyYzogMTkyLjE2OC4y LjE1MyAoMTkyLjE2OC4yLjE1MyksIERzdDogMTkyLjE2OC4yLjEzNyAoMTky LjE2OC4yLjEzNykKICAgIFZlcnNpb246IDQKICAgIEhlYWRlciBsZW5ndGg6 IDIwIGJ5dGVzCiAgICBEaWZmZXJlbnRpYXRlZCBTZXJ2aWNlcyBGaWVsZDog MHgwMCAoRFNDUCAweDAwOiBEZWZhdWx0OyBFQ046IDB4MDApCiAgICAgICAg MDAwMCAwMC4uID0gRGlmZmVyZW50aWF0ZWQgU2VydmljZXMgQ29kZXBvaW50 OiBEZWZhdWx0ICgweDAwKQogICAgICAgIC4uLi4gLi4wLiA9IEVDTi1DYXBh YmxlIFRyYW5zcG9ydCAoRUNUKTogMAogICAgICAgIC4uLi4gLi4uMCA9IEVD Ti1DRTogMAogICAgVG90YWwgTGVuZ3RoOiAxNzYKICAgIElkZW50aWZpY2F0 aW9uOiAweGY4YjYgKDYzNjcwKQogICAgRmxhZ3M6IDB4MDQgKERvbid0IEZy YWdtZW50KQogICAgICAgIDAuLi4gPSBSZXNlcnZlZCBiaXQ6IE5vdCBzZXQK ICAgICAgICAuMS4uID0gRG9uJ3QgZnJhZ21lbnQ6IFNldAogICAgICAgIC4u MC4gPSBNb3JlIGZyYWdtZW50czogTm90IHNldAogICAgRnJhZ21lbnQgb2Zm c2V0OiAwCiAgICBUaW1lIHRvIGxpdmU6IDY0CiAgICBQcm90b2NvbDogVENQ ICgweDA2KQogICAgSGVhZGVyIGNoZWNrc3VtOiAweGJiMWUgW2NvcnJlY3Rd CiAgICAgICAgW0dvb2Q6IFRydWVdCiAgICAgICAgW0JhZCA6IEZhbHNlXQog ICAgU291cmNlOiAxOTIuMTY4LjIuMTUzICgxOTIuMTY4LjIuMTUzKQogICAg RGVzdGluYXRpb246IDE5Mi4xNjguMi4xMzcgKDE5Mi4xNjguMi4xMzcpClRy YW5zbWlzc2lvbiBDb250cm9sIFByb3RvY29sLCBTcmMgUG9ydDogc3NoZWxs ICg2MTQpLCBEc3QgUG9ydDogbmZzICgyMDQ5KSwgU2VxOiAxNjMzLCBBY2s6 IDUyMSwgTGVuOiAxMzYKICAgIFNvdXJjZSBwb3J0OiBzc2hlbGwgKDYxNCkK ICAgIERlc3RpbmF0aW9uIHBvcnQ6IG5mcyAoMjA0OSkKICAgIFNlcXVlbmNl IG51bWJlcjogMTYzMyAgICAocmVsYXRpdmUgc2VxdWVuY2UgbnVtYmVyKQog ICAgW05leHQgc2VxdWVuY2UgbnVtYmVyOiAxNzY5ICAgIChyZWxhdGl2ZSBz ZXF1ZW5jZSBudW1iZXIpXQogICAgQWNrbm93bGVkZ2VtZW50IG51bWJlcjog NTIxICAgIChyZWxhdGl2ZSBhY2sgbnVtYmVyKQogICAgSGVhZGVyIGxlbmd0 aDogMjAgYnl0ZXMKICAgIEZsYWdzOiAweDE4IChQU0gsIEFDSykKICAgICAg ICAwLi4uIC4uLi4gPSBDb25nZXN0aW9uIFdpbmRvdyBSZWR1Y2VkIChDV1Ip OiBOb3Qgc2V0CiAgICAgICAgLjAuLiAuLi4uID0gRUNOLUVjaG86IE5vdCBz ZXQKICAgICAgICAuLjAuIC4uLi4gPSBVcmdlbnQ6IE5vdCBzZXQKICAgICAg ICAuLi4xIC4uLi4gPSBBY2tub3dsZWRnbWVudDogU2V0CiAgICAgICAgLi4u LiAxLi4uID0gUHVzaDogU2V0CiAgICAgICAgLi4uLiAuMC4uID0gUmVzZXQ6 IE5vdCBzZXQKICAgICAgICAuLi4uIC4uMC4gPSBTeW46IE5vdCBzZXQKICAg ICAgICAuLi4uIC4uLjAgPSBGaW46IE5vdCBzZXQKICAgIFdpbmRvdyBzaXpl OiA2NTUzNQogICAgQ2hlY2tzdW06IDB4ODcxNSBbaW5jb3JyZWN0LCBzaG91 bGQgYmUgMHhlNzc4IChtYXliZSBjYXVzZWQgYnkgIlRDUCBjaGVja3N1bSBv ZmZsb2FkIj8pXQogICAgICAgIFtHb29kIENoZWNrc3VtOiBGYWxzZV0KICAg ICAgICBbQmFkIENoZWNrc3VtOiBUcnVlXQogICAgW1NFUS9BQ0sgYW5hbHlz aXNdCiAgICAgICAgW1RoaXMgaXMgYW4gQUNLIHRvIHRoZSBzZWdtZW50IGlu IGZyYW1lOiAyNV0KICAgICAgICBbVGhlIFJUVCB0byBBQ0sgdGhlIHNlZ21l bnQgd2FzOiAwLjAwMDAyOTAwMCBzZWNvbmRzXQpSZW1vdGUgUHJvY2VkdXJl IENhbGwsIFR5cGU6Q2FsbCBYSUQ6MHg1N2RiZDRlYwogICAgRnJhZ21lbnQg aGVhZGVyOiBMYXN0IGZyYWdtZW50LCAxMzIgYnl0ZXMKICAgICAgICAxLi4u IC4uLi4gLi4uLiAuLi4uIC4uLi4gLi4uLiAuLi4uIC4uLi4gPSBMYXN0IEZy YWdtZW50OiBZZXMKICAgICAgICAuMDAwIDAwMDAgMDAwMCAwMDAwIDAwMDAg MDAwMCAxMDAwIDAxMDAgPSBGcmFnbWVudCBMZW5ndGg6IDEzMgogICAgWElE OiAweDU3ZGJkNGVjICgxNDc0MDI0Njg0KQogICAgTWVzc2FnZSBUeXBlOiBD YWxsICgwKQogICAgUlBDIFZlcnNpb246IDIKICAgIFByb2dyYW06IE5GUyAo MTAwMDAzKQogICAgUHJvZ3JhbSBWZXJzaW9uOiAzCiAgICBQcm9jZWR1cmU6 IFdSSVRFICg3KQogICAgW1RoZSByZXBseSB0byB0aGlzIHJlcXVlc3QgaXMg aW4gZnJhbWUgMjddCiAgICBDcmVkZW50aWFscwogICAgICAgIEZsYXZvcjog QVVUSF9VTklYICgxKQogICAgICAgIExlbmd0aDogMjQKICAgICAgICBTdGFt cDogMHgwMDAwMDAwMAogICAgICAgIE1hY2hpbmUgTmFtZTogPEVNUFRZPgog ICAgICAgICAgICBsZW5ndGg6IDAKICAgICAgICAgICAgY29udGVudHM6IDxF TVBUWT4KICAgICAgICBVSUQ6IDgwCiAgICAgICAgR0lEOiA4MAogICAgICAg IEF1eGlsaWFyeSBHSURzCiAgICAgICAgICAgIEdJRDogODAKICAgIFZlcmlm aWVyCiAgICAgICAgRmxhdm9yOiBBVVRIX05VTEwgKDApCiAgICAgICAgTGVu Z3RoOiAwCk5ldHdvcmsgRmlsZSBTeXN0ZW0sIFdSSVRFIENhbGwgRkg6MHg4 MTA2MDJmYyBPZmZzZXQ6MCBMZW46MTUgVU5TVEFCTEUKICAgIFtQcm9ncmFt IFZlcnNpb246IDNdCiAgICBbVjMgUHJvY2VkdXJlOiBXUklURSAoNyldCiAg ICBmaWxlCiAgICAgICAgbGVuZ3RoOiAyOAogICAgICAgIFtoYXNoOiAweDgx MDYwMmZjXQogICAgICAgIGRlY29kZSB0eXBlIGFzOiB1bmtub3duCiAgICAg ICAgZmlsZWhhbmRsZTogOEIyNjk2QTkwN0JGMEVENDBBMDAxRjg3MDUwMDAw MDAwMjlGMDQwMDAwMDAwMDAwLi4uCiAgICBvZmZzZXQ6IDAKICAgIGNvdW50 OiAxNQogICAgU3RhYmxlOiBVTlNUQUJMRSAoMCkKICAgIERhdGE6IDxEQVRB PgogICAgICAgIGxlbmd0aDogMTUKICAgICAgICBjb250ZW50czogPERBVEE+ CiAgICAgICAgZmlsbCBieXRlczogb3BhcXVlIGRhdGEKCjAwMDAgIDAwIDE1 IDE3IGJmIGViIDdiIDAwIDMwIDQ4IDdiIDUyIDM0IDA4IDAwIDQ1IDAwICAg Li4uLi57LjBIe1I0Li5FLgowMDEwICAwMCBiMCBmOCBiNiA0MCAwMCA0MCAw NiBiYiAxZSBjMCBhOCAwMiA5OSBjMCBhOCAgIC4uLi5ALkAuLi4uLi4uLi4K MDAyMCAgMDIgODkgMDIgNjYgMDggMDEgMjIgZGQgMjAgMGUgZWUgYzMgYzAg MWEgNTAgMTggICAuLi5mLi4iLiAuLi4uLlAuCjAwMzAgIGZmIGZmIDg3IDE1 IDAwIDAwIDgwIDAwIDAwIDg0IDU3IGRiIGQ0IGVjIDAwIDAwICAgLi4uLi4u Li4uLlcuLi4uLgowMDQwICAwMCAwMCAwMCAwMCAwMCAwMiAwMCAwMSA4NiBh MyAwMCAwMCAwMCAwMyAwMCAwMCAgIC4uLi4uLi4uLi4uLi4uLi4KMDA1MCAg MDAgMDcgMDAgMDAgMDAgMDEgMDAgMDAgMDAgMTggMDAgMDAgMDAgMDAgMDAg MDAgICAuLi4uLi4uLi4uLi4uLi4uCjAwNjAgIDAwIDAwIDAwIDAwIDAwIDUw IDAwIDAwIDAwIDUwIDAwIDAwIDAwIDAxIDAwIDAwICAgLi4uLi5QLi4uUC4u Li4uLgowMDcwICAwMCA1MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAxYyA4YiAyNiAgIC5QLi4uLi4uLi4uLi4uLiYKMDA4MCAgOTYgYTkg MDcgYmYgMGUgZDQgMGEgMDAgMWYgODcgMDUgMDAgMDAgMDAgMDIgOWYgICAu Li4uLi4uLi4uLi4uLi4uCjAwOTAgIDA0IDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAgLi4uLi4uLi4uLi4uLi4uLgow MGEwICAwMCAwMCAwMCAwMCAwMCAwZiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw ZiAzOCAzOSAgIC4uLi4uLi4uLi4uLi4uODkKMDBiMCAgMzkgMzggMzggMjAg MzIgMzYgMzIgMzEgMzQgMzQgMzAgMzAgMzAgMDAgICAgICAgICA5ODggMjYy MTQ0MDAwLgoKTm8uICAgICBUaW1lICAgICAgICBTb3VyY2UgICAgICAgICAg ICAgICAgRGVzdGluYXRpb24gICAgICAgICAgIFByb3RvY29sIEluZm8KICAg ICAyNyAwLjAwMzI0NiAgICAxOTIuMTY4LjIuMTM3ICAgICAgICAgMTkyLjE2 OC4yLjE1MyAgICAgICAgIE5GUyAgICAgIFYzIFdSSVRFIFJlcGx5IChDYWxs IEluIDI2KSBFcnJvcjpORlMzRVJSX0lPCgpGcmFtZSAyNyAoOTQgYnl0ZXMg b24gd2lyZSwgOTQgYnl0ZXMgY2FwdHVyZWQpCiAgICBBcnJpdmFsIFRpbWU6 IEphbiAzMCwgMjAxMCAxMjo0MTo0Ni45MTQwNzQwMDAKICAgIFtUaW1lIGRl bHRhIGZyb20gcHJldmlvdXMgY2FwdHVyZWQgZnJhbWU6IDAuMDAwMjIxMDAw IHNlY29uZHNdCiAgICBbVGltZSBkZWx0YSBmcm9tIHByZXZpb3VzIGRpc3Bs YXllZCBmcmFtZTogMC4wMDAyMjEwMDAgc2Vjb25kc10KICAgIFtUaW1lIHNp bmNlIHJlZmVyZW5jZSBvciBmaXJzdCBmcmFtZTogMC4wMDMyNDYwMDAgc2Vj b25kc10KICAgIEZyYW1lIE51bWJlcjogMjcKICAgIEZyYW1lIExlbmd0aDog OTQgYnl0ZXMKICAgIENhcHR1cmUgTGVuZ3RoOiA5NCBieXRlcwogICAgW0Zy YW1lIGlzIG1hcmtlZDogRmFsc2VdCiAgICBbUHJvdG9jb2xzIGluIGZyYW1l OiBldGg6aXA6dGNwOnJwY10KICAgIFtDb2xvcmluZyBSdWxlIE5hbWU6IFRD UF0KICAgIFtDb2xvcmluZyBSdWxlIFN0cmluZzogdGNwXQpFdGhlcm5ldCBJ SSwgU3JjOiBJbnRlbENvcl9iZjplYjo3YiAoMDA6MTU6MTc6YmY6ZWI6N2Ip LCBEc3Q6IFN1cGVybWljXzdiOjUyOjM0ICgwMDozMDo0ODo3Yjo1MjozNCkK ICAgIERlc3RpbmF0aW9uOiBTdXBlcm1pY183Yjo1MjozNCAoMDA6MzA6NDg6 N2I6NTI6MzQpCiAgICAgICAgQWRkcmVzczogU3VwZXJtaWNfN2I6NTI6MzQg KDAwOjMwOjQ4OjdiOjUyOjM0KQogICAgICAgIC4uLi4gLi4uMCAuLi4uIC4u Li4gLi4uLiAuLi4uID0gSUcgYml0OiBJbmRpdmlkdWFsIGFkZHJlc3MgKHVu aWNhc3QpCiAgICAgICAgLi4uLiAuLjAuIC4uLi4gLi4uLiAuLi4uIC4uLi4g PSBMRyBiaXQ6IEdsb2JhbGx5IHVuaXF1ZSBhZGRyZXNzIChmYWN0b3J5IGRl ZmF1bHQpCiAgICBTb3VyY2U6IEludGVsQ29yX2JmOmViOjdiICgwMDoxNTox NzpiZjplYjo3YikKICAgICAgICBBZGRyZXNzOiBJbnRlbENvcl9iZjplYjo3 YiAoMDA6MTU6MTc6YmY6ZWI6N2IpCiAgICAgICAgLi4uLiAuLi4wIC4uLi4g Li4uLiAuLi4uIC4uLi4gPSBJRyBiaXQ6IEluZGl2aWR1YWwgYWRkcmVzcyAo dW5pY2FzdCkKICAgICAgICAuLi4uIC4uMC4gLi4uLiAuLi4uIC4uLi4gLi4u LiA9IExHIGJpdDogR2xvYmFsbHkgdW5pcXVlIGFkZHJlc3MgKGZhY3Rvcnkg ZGVmYXVsdCkKICAgIFR5cGU6IElQICgweDA4MDApCkludGVybmV0IFByb3Rv Y29sLCBTcmM6IDE5Mi4xNjguMi4xMzcgKDE5Mi4xNjguMi4xMzcpLCBEc3Q6 IDE5Mi4xNjguMi4xNTMgKDE5Mi4xNjguMi4xNTMpCiAgICBWZXJzaW9uOiA0 CiAgICBIZWFkZXIgbGVuZ3RoOiAyMCBieXRlcwogICAgRGlmZmVyZW50aWF0 ZWQgU2VydmljZXMgRmllbGQ6IDB4MDAgKERTQ1AgMHgwMDogRGVmYXVsdDsg RUNOOiAweDAwKQogICAgICAgIDAwMDAgMDAuLiA9IERpZmZlcmVudGlhdGVk IFNlcnZpY2VzIENvZGVwb2ludDogRGVmYXVsdCAoMHgwMCkKICAgICAgICAu Li4uIC4uMC4gPSBFQ04tQ2FwYWJsZSBUcmFuc3BvcnQgKEVDVCk6IDAKICAg ICAgICAuLi4uIC4uLjAgPSBFQ04tQ0U6IDAKICAgIFRvdGFsIExlbmd0aDog ODAKICAgIElkZW50aWZpY2F0aW9uOiAweGI4ZTIgKDQ3MzMwKQogICAgRmxh Z3M6IDB4MDQgKERvbid0IEZyYWdtZW50KQogICAgICAgIDAuLi4gPSBSZXNl cnZlZCBiaXQ6IE5vdCBzZXQKICAgICAgICAuMS4uID0gRG9uJ3QgZnJhZ21l bnQ6IFNldAogICAgICAgIC4uMC4gPSBNb3JlIGZyYWdtZW50czogTm90IHNl dAogICAgRnJhZ21lbnQgb2Zmc2V0OiAwCiAgICBUaW1lIHRvIGxpdmU6IDY0 CiAgICBQcm90b2NvbDogVENQICgweDA2KQogICAgSGVhZGVyIGNoZWNrc3Vt OiAweGZiNTIgW2NvcnJlY3RdCiAgICAgICAgW0dvb2Q6IFRydWVdCiAgICAg ICAgW0JhZCA6IEZhbHNlXQogICAgU291cmNlOiAxOTIuMTY4LjIuMTM3ICgx OTIuMTY4LjIuMTM3KQogICAgRGVzdGluYXRpb246IDE5Mi4xNjguMi4xNTMg KDE5Mi4xNjguMi4xNTMpClRyYW5zbWlzc2lvbiBDb250cm9sIFByb3RvY29s LCBTcmMgUG9ydDogbmZzICgyMDQ5KSwgRHN0IFBvcnQ6IHNzaGVsbCAoNjE0 KSwgU2VxOiA1MjEsIEFjazogMTc2OSwgTGVuOiA0MAogICAgU291cmNlIHBv cnQ6IG5mcyAoMjA0OSkKICAgIERlc3RpbmF0aW9uIHBvcnQ6IHNzaGVsbCAo NjE0KQogICAgU2VxdWVuY2UgbnVtYmVyOiA1MjEgICAgKHJlbGF0aXZlIHNl cXVlbmNlIG51bWJlcikKICAgIFtOZXh0IHNlcXVlbmNlIG51bWJlcjogNTYx ICAgIChyZWxhdGl2ZSBzZXF1ZW5jZSBudW1iZXIpXQogICAgQWNrbm93bGVk Z2VtZW50IG51bWJlcjogMTc2OSAgICAocmVsYXRpdmUgYWNrIG51bWJlcikK ICAgIEhlYWRlciBsZW5ndGg6IDIwIGJ5dGVzCiAgICBGbGFnczogMHgxOCAo UFNILCBBQ0spCiAgICAgICAgMC4uLiAuLi4uID0gQ29uZ2VzdGlvbiBXaW5k b3cgUmVkdWNlZCAoQ1dSKTogTm90IHNldAogICAgICAgIC4wLi4gLi4uLiA9 IEVDTi1FY2hvOiBOb3Qgc2V0CiAgICAgICAgLi4wLiAuLi4uID0gVXJnZW50 OiBOb3Qgc2V0CiAgICAgICAgLi4uMSAuLi4uID0gQWNrbm93bGVkZ21lbnQ6 IFNldAogICAgICAgIC4uLi4gMS4uLiA9IFB1c2g6IFNldAogICAgICAgIC4u Li4gLjAuLiA9IFJlc2V0OiBOb3Qgc2V0CiAgICAgICAgLi4uLiAuLjAuID0g U3luOiBOb3Qgc2V0CiAgICAgICAgLi4uLiAuLi4wID0gRmluOiBOb3Qgc2V0 CiAgICBXaW5kb3cgc2l6ZTogNjU1MzUKICAgIENoZWNrc3VtOiAweDdmODYg W2NvcnJlY3RdCiAgICAgICAgW0dvb2QgQ2hlY2tzdW06IFRydWVdCiAgICAg ICAgW0JhZCBDaGVja3N1bTogRmFsc2VdCiAgICBbU0VRL0FDSyBhbmFseXNp c10KICAgICAgICBbVGhpcyBpcyBhbiBBQ0sgdG8gdGhlIHNlZ21lbnQgaW4g ZnJhbWU6IDI2XQogICAgICAgIFtUaGUgUlRUIHRvIEFDSyB0aGUgc2VnbWVu dCB3YXM6IDAuMDAwMjIxMDAwIHNlY29uZHNdClJlbW90ZSBQcm9jZWR1cmUg Q2FsbCwgVHlwZTpSZXBseSBYSUQ6MHg1N2RiZDRlYwogICAgRnJhZ21lbnQg aGVhZGVyOiBMYXN0IGZyYWdtZW50LCAzNiBieXRlcwogICAgICAgIDEuLi4g Li4uLiAuLi4uIC4uLi4gLi4uLiAuLi4uIC4uLi4gLi4uLiA9IExhc3QgRnJh Z21lbnQ6IFllcwogICAgICAgIC4wMDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAw MDAwIDAwMTAgMDEwMCA9IEZyYWdtZW50IExlbmd0aDogMzYKICAgIFhJRDog MHg1N2RiZDRlYyAoMTQ3NDAyNDY4NCkKICAgIE1lc3NhZ2UgVHlwZTogUmVw bHkgKDEpCiAgICBbUHJvZ3JhbTogTkZTICgxMDAwMDMpXQogICAgW1Byb2dy YW0gVmVyc2lvbjogM10KICAgIFtQcm9jZWR1cmU6IFdSSVRFICg3KV0KICAg IFJlcGx5IFN0YXRlOiBhY2NlcHRlZCAoMCkKICAgIFtUaGlzIGlzIGEgcmVw bHkgdG8gYSByZXF1ZXN0IGluIGZyYW1lIDI2XQogICAgW1RpbWUgZnJvbSBy ZXF1ZXN0OiAwLjAwMDIyMTAwMCBzZWNvbmRzXQogICAgVmVyaWZpZXIKICAg ICAgICBGbGF2b3I6IEFVVEhfTlVMTCAoMCkKICAgICAgICBMZW5ndGg6IDAK ICAgIEFjY2VwdCBTdGF0ZTogUlBDIGV4ZWN1dGVkIHN1Y2Nlc3NmdWxseSAo MCkKTmV0d29yayBGaWxlIFN5c3RlbSwgV1JJVEUgUmVwbHkgIEVycm9yOk5G UzNFUlJfSU8KICAgIFtQcm9ncmFtIFZlcnNpb246IDNdCiAgICBbVjMgUHJv Y2VkdXJlOiBXUklURSAoNyldCiAgICBTdGF0dXM6IE5GUzNFUlJfSU8gKDUp CiAgICBmaWxlX3djYwogICAgICAgIGJlZm9yZQogICAgICAgICAgICBhdHRy aWJ1dGVzX2ZvbGxvdzogbm8gdmFsdWUgKDApCiAgICAgICAgYWZ0ZXIKICAg ICAgICAgICAgYXR0cmlidXRlc19mb2xsb3c6IG5vIHZhbHVlICgwKQoKMDAw MCAgMDAgMzAgNDggN2IgNTIgMzQgMDAgMTUgMTcgYmYgZWIgN2IgMDggMDAg NDUgMDAgICAuMEh7UjQuLi4uLnsuLkUuCjAwMTAgIDAwIDUwIGI4IGUyIDQw IDAwIDQwIDA2IGZiIDUyIGMwIGE4IDAyIDg5IGMwIGE4ICAgLlAuLkAuQC4u Ui4uLi4uLgowMDIwICAwMiA5OSAwOCAwMSAwMiA2NiBlZSBjMyBjMCAxYSAy MiBkZCAyMCA5NiA1MCAxOCAgIC4uLi4uZi4uLi4iLiAuUC4KMDAzMCAgZmYg ZmYgN2YgODYgMDAgMDAgODAgMDAgMDAgMjQgNTcgZGIgZDQgZWMgMDAgMDAg ICAuLi4uLi4uLi4kVy4uLi4uCjAwNDAgIDAwIDAxIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAgLi4uLi4uLi4uLi4uLi4u LgowMDUwICAwMCAwMCAwMCAwMCAwMCAwNSAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAgICAgICAgIC4uLi4uLi4uLi4uLi4uCgpOby4gICAgIFRpbWUgICAg ICAgIFNvdXJjZSAgICAgICAgICAgICAgICBEZXN0aW5hdGlvbiAgICAgICAg ICAgUHJvdG9jb2wgSW5mbwogICAgIDI4IDAuMDAzMjc1ICAgIDE5Mi4xNjgu Mi4xNTMgICAgICAgICAxOTIuMTY4LjIuMTM3ICAgICAgICAgTkZTICAgICAg VjMgV1JJVEUgQ2FsbCAoUmVwbHkgSW4gMjkpLCBGSDoweDgxMDYwMmZjIE9m ZnNldDowIExlbjoxNSBVTlNUQUJMRQoKRnJhbWUgMjggKDE5MCBieXRlcyBv biB3aXJlLCAxOTAgYnl0ZXMgY2FwdHVyZWQpCiAgICBBcnJpdmFsIFRpbWU6 IEphbiAzMCwgMjAxMCAxMjo0MTo0Ni45MTQxMDMwMDAKICAgIFtUaW1lIGRl bHRhIGZyb20gcHJldmlvdXMgY2FwdHVyZWQgZnJhbWU6IDAuMDAwMDI5MDAw IHNlY29uZHNdCiAgICBbVGltZSBkZWx0YSBmcm9tIHByZXZpb3VzIGRpc3Bs YXllZCBmcmFtZTogMC4wMDAwMjkwMDAgc2Vjb25kc10KICAgIFtUaW1lIHNp bmNlIHJlZmVyZW5jZSBvciBmaXJzdCBmcmFtZTogMC4wMDMyNzUwMDAgc2Vj b25kc10KICAgIEZyYW1lIE51bWJlcjogMjgKICAgIEZyYW1lIExlbmd0aDog MTkwIGJ5dGVzCiAgICBDYXB0dXJlIExlbmd0aDogMTkwIGJ5dGVzCiAgICBb RnJhbWUgaXMgbWFya2VkOiBGYWxzZV0KICAgIFtQcm90b2NvbHMgaW4gZnJh bWU6IGV0aDppcDp0Y3A6cnBjOm5mc10KICAgIFtDb2xvcmluZyBSdWxlIE5h bWU6IENoZWNrc3VtIEVycm9yc10KICAgIFtDb2xvcmluZyBSdWxlIFN0cmlu ZzogY2RwLmNoZWNrc3VtX2JhZD09MSB8fCBlZHAuY2hlY2tzdW1fYmFkPT0x IHx8IGlwLmNoZWNrc3VtX2JhZD09MSB8fCB0Y3AuY2hlY2tzdW1fYmFkPT0x IHx8IHVkcC5jaGVja3N1bV9iYWQ9PTFdCkV0aGVybmV0IElJLCBTcmM6IFN1 cGVybWljXzdiOjUyOjM0ICgwMDozMDo0ODo3Yjo1MjozNCksIERzdDogSW50 ZWxDb3JfYmY6ZWI6N2IgKDAwOjE1OjE3OmJmOmViOjdiKQogICAgRGVzdGlu YXRpb246IEludGVsQ29yX2JmOmViOjdiICgwMDoxNToxNzpiZjplYjo3YikK ICAgICAgICBBZGRyZXNzOiBJbnRlbENvcl9iZjplYjo3YiAoMDA6MTU6MTc6 YmY6ZWI6N2IpCiAgICAgICAgLi4uLiAuLi4wIC4uLi4gLi4uLiAuLi4uIC4u Li4gPSBJRyBiaXQ6IEluZGl2aWR1YWwgYWRkcmVzcyAodW5pY2FzdCkKICAg ICAgICAuLi4uIC4uMC4gLi4uLiAuLi4uIC4uLi4gLi4uLiA9IExHIGJpdDog R2xvYmFsbHkgdW5pcXVlIGFkZHJlc3MgKGZhY3RvcnkgZGVmYXVsdCkKICAg IFNvdXJjZTogU3VwZXJtaWNfN2I6NTI6MzQgKDAwOjMwOjQ4OjdiOjUyOjM0 KQogICAgICAgIEFkZHJlc3M6IFN1cGVybWljXzdiOjUyOjM0ICgwMDozMDo0 ODo3Yjo1MjozNCkKICAgICAgICAuLi4uIC4uLjAgLi4uLiAuLi4uIC4uLi4g Li4uLiA9IElHIGJpdDogSW5kaXZpZHVhbCBhZGRyZXNzICh1bmljYXN0KQog ICAgICAgIC4uLi4gLi4wLiAuLi4uIC4uLi4gLi4uLiAuLi4uID0gTEcgYml0 OiBHbG9iYWxseSB1bmlxdWUgYWRkcmVzcyAoZmFjdG9yeSBkZWZhdWx0KQog ICAgVHlwZTogSVAgKDB4MDgwMCkKSW50ZXJuZXQgUHJvdG9jb2wsIFNyYzog MTkyLjE2OC4yLjE1MyAoMTkyLjE2OC4yLjE1MyksIERzdDogMTkyLjE2OC4y LjEzNyAoMTkyLjE2OC4yLjEzNykKICAgIFZlcnNpb246IDQKICAgIEhlYWRl ciBsZW5ndGg6IDIwIGJ5dGVzCiAgICBEaWZmZXJlbnRpYXRlZCBTZXJ2aWNl cyBGaWVsZDogMHgwMCAoRFNDUCAweDAwOiBEZWZhdWx0OyBFQ046IDB4MDAp CiAgICAgICAgMDAwMCAwMC4uID0gRGlmZmVyZW50aWF0ZWQgU2VydmljZXMg Q29kZXBvaW50OiBEZWZhdWx0ICgweDAwKQogICAgICAgIC4uLi4gLi4wLiA9 IEVDTi1DYXBhYmxlIFRyYW5zcG9ydCAoRUNUKTogMAogICAgICAgIC4uLi4g Li4uMCA9IEVDTi1DRTogMAogICAgVG90YWwgTGVuZ3RoOiAxNzYKICAgIElk ZW50aWZpY2F0aW9uOiAweGY4YjcgKDYzNjcxKQogICAgRmxhZ3M6IDB4MDQg KERvbid0IEZyYWdtZW50KQogICAgICAgIDAuLi4gPSBSZXNlcnZlZCBiaXQ6 IE5vdCBzZXQKICAgICAgICAuMS4uID0gRG9uJ3QgZnJhZ21lbnQ6IFNldAog ICAgICAgIC4uMC4gPSBNb3JlIGZyYWdtZW50czogTm90IHNldAogICAgRnJh Z21lbnQgb2Zmc2V0OiAwCiAgICBUaW1lIHRvIGxpdmU6IDY0CiAgICBQcm90 b2NvbDogVENQICgweDA2KQogICAgSGVhZGVyIGNoZWNrc3VtOiAweGJiMWQg W2NvcnJlY3RdCiAgICAgICAgW0dvb2Q6IFRydWVdCiAgICAgICAgW0JhZCA6 IEZhbHNlXQogICAgU291cmNlOiAxOTIuMTY4LjIuMTUzICgxOTIuMTY4LjIu MTUzKQogICAgRGVzdGluYXRpb246IDE5Mi4xNjguMi4xMzcgKDE5Mi4xNjgu Mi4xMzcpClRyYW5zbWlzc2lvbiBDb250cm9sIFByb3RvY29sLCBTcmMgUG9y dDogc3NoZWxsICg2MTQpLCBEc3QgUG9ydDogbmZzICgyMDQ5KSwgU2VxOiAx NzY5LCBBY2s6IDU2MSwgTGVuOiAxMzYKICAgIFNvdXJjZSBwb3J0OiBzc2hl bGwgKDYxNCkKICAgIERlc3RpbmF0aW9uIHBvcnQ6IG5mcyAoMjA0OSkKICAg IFNlcXVlbmNlIG51bWJlcjogMTc2OSAgICAocmVsYXRpdmUgc2VxdWVuY2Ug bnVtYmVyKQogICAgW05leHQgc2VxdWVuY2UgbnVtYmVyOiAxOTA1ICAgIChy ZWxhdGl2ZSBzZXF1ZW5jZSBudW1iZXIpXQogICAgQWNrbm93bGVkZ2VtZW50 IG51bWJlcjogNTYxICAgIChyZWxhdGl2ZSBhY2sgbnVtYmVyKQogICAgSGVh ZGVyIGxlbmd0aDogMjAgYnl0ZXMKICAgIEZsYWdzOiAweDE4IChQU0gsIEFD SykKICAgICAgICAwLi4uIC4uLi4gPSBDb25nZXN0aW9uIFdpbmRvdyBSZWR1 Y2VkIChDV1IpOiBOb3Qgc2V0CiAgICAgICAgLjAuLiAuLi4uID0gRUNOLUVj aG86IE5vdCBzZXQKICAgICAgICAuLjAuIC4uLi4gPSBVcmdlbnQ6IE5vdCBz ZXQKICAgICAgICAuLi4xIC4uLi4gPSBBY2tub3dsZWRnbWVudDogU2V0CiAg ICAgICAgLi4uLiAxLi4uID0gUHVzaDogU2V0CiAgICAgICAgLi4uLiAuMC4u ID0gUmVzZXQ6IE5vdCBzZXQKICAgICAgICAuLi4uIC4uMC4gPSBTeW46IE5v dCBzZXQKICAgICAgICAuLi4uIC4uLjAgPSBGaW46IE5vdCBzZXQKICAgIFdp bmRvdyBzaXplOiA2NTUzNQogICAgQ2hlY2tzdW06IDB4ODcxNSBbaW5jb3Jy ZWN0LCBzaG91bGQgYmUgMHhlNmM3IChtYXliZSBjYXVzZWQgYnkgIlRDUCBj aGVja3N1bSBvZmZsb2FkIj8pXQogICAgICAgIFtHb29kIENoZWNrc3VtOiBG YWxzZV0KICAgICAgICBbQmFkIENoZWNrc3VtOiBUcnVlXQogICAgW1NFUS9B Q0sgYW5hbHlzaXNdCiAgICAgICAgW1RoaXMgaXMgYW4gQUNLIHRvIHRoZSBz ZWdtZW50IGluIGZyYW1lOiAyN10KICAgICAgICBbVGhlIFJUVCB0byBBQ0sg dGhlIHNlZ21lbnQgd2FzOiAwLjAwMDAyOTAwMCBzZWNvbmRzXQpSZW1vdGUg UHJvY2VkdXJlIENhbGwsIFR5cGU6Q2FsbCBYSUQ6MHg1N2RiZDRlZAogICAg RnJhZ21lbnQgaGVhZGVyOiBMYXN0IGZyYWdtZW50LCAxMzIgYnl0ZXMKICAg ICAgICAxLi4uIC4uLi4gLi4uLiAuLi4uIC4uLi4gLi4uLiAuLi4uIC4uLi4g PSBMYXN0IEZyYWdtZW50OiBZZXMKICAgICAgICAuMDAwIDAwMDAgMDAwMCAw MDAwIDAwMDAgMDAwMCAxMDAwIDAxMDAgPSBGcmFnbWVudCBMZW5ndGg6IDEz MgogICAgWElEOiAweDU3ZGJkNGVkICgxNDc0MDI0Njg1KQogICAgTWVzc2Fn ZSBUeXBlOiBDYWxsICgwKQogICAgUlBDIFZlcnNpb246IDIKICAgIFByb2dy YW06IE5GUyAoMTAwMDAzKQogICAgUHJvZ3JhbSBWZXJzaW9uOiAzCiAgICBQ cm9jZWR1cmU6IFdSSVRFICg3KQogICAgW1RoZSByZXBseSB0byB0aGlzIHJl cXVlc3QgaXMgaW4gZnJhbWUgMjldCiAgICBDcmVkZW50aWFscwogICAgICAg IEZsYXZvcjogQVVUSF9VTklYICgxKQogICAgICAgIExlbmd0aDogMjQKICAg ICAgICBTdGFtcDogMHgwMDAwMDAwMAogICAgICAgIE1hY2hpbmUgTmFtZTog PEVNUFRZPgogICAgICAgICAgICBsZW5ndGg6IDAKICAgICAgICAgICAgY29u dGVudHM6IDxFTVBUWT4KICAgICAgICBVSUQ6IDgwCiAgICAgICAgR0lEOiA4 MAogICAgICAgIEF1eGlsaWFyeSBHSURzCiAgICAgICAgICAgIEdJRDogODAK ICAgIFZlcmlmaWVyCiAgICAgICAgRmxhdm9yOiBBVVRIX05VTEwgKDApCiAg ICAgICAgTGVuZ3RoOiAwCk5ldHdvcmsgRmlsZSBTeXN0ZW0sIFdSSVRFIENh bGwgRkg6MHg4MTA2MDJmYyBPZmZzZXQ6MCBMZW46MTUgVU5TVEFCTEUKICAg IFtQcm9ncmFtIFZlcnNpb246IDNdCiAgICBbVjMgUHJvY2VkdXJlOiBXUklU RSAoNyldCiAgICBmaWxlCiAgICAgICAgbGVuZ3RoOiAyOAogICAgICAgIFto YXNoOiAweDgxMDYwMmZjXQogICAgICAgIGRlY29kZSB0eXBlIGFzOiB1bmtu b3duCiAgICAgICAgZmlsZWhhbmRsZTogOEIyNjk2QTkwN0JGMEVENDBBMDAx Rjg3MDUwMDAwMDAwMjlGMDQwMDAwMDAwMDAwLi4uCiAgICBvZmZzZXQ6IDAK ICAgIGNvdW50OiAxNQogICAgU3RhYmxlOiBVTlNUQUJMRSAoMCkKICAgIERh dGE6IDxEQVRBPgogICAgICAgIGxlbmd0aDogMTUKICAgICAgICBjb250ZW50 czogPERBVEE+CiAgICAgICAgZmlsbCBieXRlczogb3BhcXVlIGRhdGEKCjAw MDAgIDAwIDE1IDE3IGJmIGViIDdiIDAwIDMwIDQ4IDdiIDUyIDM0IDA4IDAw IDQ1IDAwICAgLi4uLi57LjBIe1I0Li5FLgowMDEwICAwMCBiMCBmOCBiNyA0 MCAwMCA0MCAwNiBiYiAxZCBjMCBhOCAwMiA5OSBjMCBhOCAgIC4uLi5ALkAu Li4uLi4uLi4KMDAyMCAgMDIgODkgMDIgNjYgMDggMDEgMjIgZGQgMjAgOTYg ZWUgYzMgYzAgNDIgNTAgMTggICAuLi5mLi4iLiAuLi4uQlAuCjAwMzAgIGZm IGZmIDg3IDE1IDAwIDAwIDgwIDAwIDAwIDg0IDU3IGRiIGQ0IGVkIDAwIDAw ICAgLi4uLi4uLi4uLlcuLi4uLgowMDQwICAwMCAwMCAwMCAwMCAwMCAwMiAw MCAwMSA4NiBhMyAwMCAwMCAwMCAwMyAwMCAwMCAgIC4uLi4uLi4uLi4uLi4u Li4KMDA1MCAgMDAgMDcgMDAgMDAgMDAgMDEgMDAgMDAgMDAgMTggMDAgMDAg MDAgMDAgMDAgMDAgICAuLi4uLi4uLi4uLi4uLi4uCjAwNjAgIDAwIDAwIDAw IDAwIDAwIDUwIDAwIDAwIDAwIDUwIDAwIDAwIDAwIDAxIDAwIDAwICAgLi4u Li5QLi4uUC4uLi4uLgowMDcwICAwMCA1MCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAxYyA4YiAyNiAgIC5QLi4uLi4uLi4uLi4uLiYKMDA4 MCAgOTYgYTkgMDcgYmYgMGUgZDQgMGEgMDAgMWYgODcgMDUgMDAgMDAgMDAg MDIgOWYgICAuLi4uLi4uLi4uLi4uLi4uCjAwOTAgIDA0IDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAgLi4uLi4uLi4u Li4uLi4uLgowMGEwICAwMCAwMCAwMCAwMCAwMCAwZiAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwZiAzOCAzOSAgIC4uLi4uLi4uLi4uLi4uODkKMDBiMCAgMzkg MzggMzggMjAgMzIgMzYgMzIgMzEgMzQgMzQgMzAgMzAgMzAgMDAgICAgICAg ICA5ODggMjYyMTQ0MDAwLgoKTm8uICAgICBUaW1lICAgICAgICBTb3VyY2Ug ICAgICAgICAgICAgICAgRGVzdGluYXRpb24gICAgICAgICAgIFByb3RvY29s IEluZm8KICAgICAyOSAwLjAwMzQ5NiAgICAxOTIuMTY4LjIuMTM3ICAgICAg ICAgMTkyLjE2OC4yLjE1MyAgICAgICAgIE5GUyAgICAgIFYzIFdSSVRFIFJl cGx5IChDYWxsIEluIDI4KSBFcnJvcjpORlMzRVJSX0lPCgpGcmFtZSAyOSAo OTQgYnl0ZXMgb24gd2lyZSwgOTQgYnl0ZXMgY2FwdHVyZWQpCiAgICBBcnJp dmFsIFRpbWU6IEphbiAzMCwgMjAxMCAxMjo0MTo0Ni45MTQzMjQwMDAKICAg IFtUaW1lIGRlbHRhIGZyb20gcHJldmlvdXMgY2FwdHVyZWQgZnJhbWU6IDAu MDAwMjIxMDAwIHNlY29uZHNdCiAgICBbVGltZSBkZWx0YSBmcm9tIHByZXZp b3VzIGRpc3BsYXllZCBmcmFtZTogMC4wMDAyMjEwMDAgc2Vjb25kc10KICAg IFtUaW1lIHNpbmNlIHJlZmVyZW5jZSBvciBmaXJzdCBmcmFtZTogMC4wMDM0 OTYwMDAgc2Vjb25kc10KICAgIEZyYW1lIE51bWJlcjogMjkKICAgIEZyYW1l IExlbmd0aDogOTQgYnl0ZXMKICAgIENhcHR1cmUgTGVuZ3RoOiA5NCBieXRl cwogICAgW0ZyYW1lIGlzIG1hcmtlZDogRmFsc2VdCiAgICBbUHJvdG9jb2xz IGluIGZyYW1lOiBldGg6aXA6dGNwOnJwY10KICAgIFtDb2xvcmluZyBSdWxl IE5hbWU6IFRDUF0KICAgIFtDb2xvcmluZyBSdWxlIFN0cmluZzogdGNwXQpF dGhlcm5ldCBJSSwgU3JjOiBJbnRlbENvcl9iZjplYjo3YiAoMDA6MTU6MTc6 YmY6ZWI6N2IpLCBEc3Q6IFN1cGVybWljXzdiOjUyOjM0ICgwMDozMDo0ODo3 Yjo1MjozNCkKICAgIERlc3RpbmF0aW9uOiBTdXBlcm1pY183Yjo1MjozNCAo MDA6MzA6NDg6N2I6NTI6MzQpCiAgICAgICAgQWRkcmVzczogU3VwZXJtaWNf N2I6NTI6MzQgKDAwOjMwOjQ4OjdiOjUyOjM0KQogICAgICAgIC4uLi4gLi4u MCAuLi4uIC4uLi4gLi4uLiAuLi4uID0gSUcgYml0OiBJbmRpdmlkdWFsIGFk ZHJlc3MgKHVuaWNhc3QpCiAgICAgICAgLi4uLiAuLjAuIC4uLi4gLi4uLiAu Li4uIC4uLi4gPSBMRyBiaXQ6IEdsb2JhbGx5IHVuaXF1ZSBhZGRyZXNzIChm YWN0b3J5IGRlZmF1bHQpCiAgICBTb3VyY2U6IEludGVsQ29yX2JmOmViOjdi ICgwMDoxNToxNzpiZjplYjo3YikKICAgICAgICBBZGRyZXNzOiBJbnRlbENv cl9iZjplYjo3YiAoMDA6MTU6MTc6YmY6ZWI6N2IpCiAgICAgICAgLi4uLiAu Li4wIC4uLi4gLi4uLiAuLi4uIC4uLi4gPSBJRyBiaXQ6IEluZGl2aWR1YWwg YWRkcmVzcyAodW5pY2FzdCkKICAgICAgICAuLi4uIC4uMC4gLi4uLiAuLi4u IC4uLi4gLi4uLiA9IExHIGJpdDogR2xvYmFsbHkgdW5pcXVlIGFkZHJlc3Mg KGZhY3RvcnkgZGVmYXVsdCkKICAgIFR5cGU6IElQICgweDA4MDApCkludGVy bmV0IFByb3RvY29sLCBTcmM6IDE5Mi4xNjguMi4xMzcgKDE5Mi4xNjguMi4x MzcpLCBEc3Q6IDE5Mi4xNjguMi4xNTMgKDE5Mi4xNjguMi4xNTMpCiAgICBW ZXJzaW9uOiA0CiAgICBIZWFkZXIgbGVuZ3RoOiAyMCBieXRlcwogICAgRGlm ZmVyZW50aWF0ZWQgU2VydmljZXMgRmllbGQ6IDB4MDAgKERTQ1AgMHgwMDog RGVmYXVsdDsgRUNOOiAweDAwKQogICAgICAgIDAwMDAgMDAuLiA9IERpZmZl cmVudGlhdGVkIFNlcnZpY2VzIENvZGVwb2ludDogRGVmYXVsdCAoMHgwMCkK ICAgICAgICAuLi4uIC4uMC4gPSBFQ04tQ2FwYWJsZSBUcmFuc3BvcnQgKEVD VCk6IDAKICAgICAgICAuLi4uIC4uLjAgPSBFQ04tQ0U6IDAKICAgIFRvdGFs IExlbmd0aDogODAKICAgIElkZW50aWZpY2F0aW9uOiAweGI4ZTMgKDQ3MzMx KQogICAgRmxhZ3M6IDB4MDQgKERvbid0IEZyYWdtZW50KQogICAgICAgIDAu Li4gPSBSZXNlcnZlZCBiaXQ6IE5vdCBzZXQKICAgICAgICAuMS4uID0gRG9u J3QgZnJhZ21lbnQ6IFNldAogICAgICAgIC4uMC4gPSBNb3JlIGZyYWdtZW50 czogTm90IHNldAogICAgRnJhZ21lbnQgb2Zmc2V0OiAwCiAgICBUaW1lIHRv IGxpdmU6IDY0CiAgICBQcm90b2NvbDogVENQICgweDA2KQogICAgSGVhZGVy IGNoZWNrc3VtOiAweGZiNTEgW2NvcnJlY3RdCiAgICAgICAgW0dvb2Q6IFRy dWVdCiAgICAgICAgW0JhZCA6IEZhbHNlXQogICAgU291cmNlOiAxOTIuMTY4 LjIuMTM3ICgxOTIuMTY4LjIuMTM3KQogICAgRGVzdGluYXRpb246IDE5Mi4x NjguMi4xNTMgKDE5Mi4xNjguMi4xNTMpClRyYW5zbWlzc2lvbiBDb250cm9s IFByb3RvY29sLCBTcmMgUG9ydDogbmZzICgyMDQ5KSwgRHN0IFBvcnQ6IHNz aGVsbCAoNjE0KSwgU2VxOiA1NjEsIEFjazogMTkwNSwgTGVuOiA0MAogICAg U291cmNlIHBvcnQ6IG5mcyAoMjA0OSkKICAgIERlc3RpbmF0aW9uIHBvcnQ6 IHNzaGVsbCAoNjE0KQogICAgU2VxdWVuY2UgbnVtYmVyOiA1NjEgICAgKHJl bGF0aXZlIHNlcXVlbmNlIG51bWJlcikKICAgIFtOZXh0IHNlcXVlbmNlIG51 bWJlcjogNjAxICAgIChyZWxhdGl2ZSBzZXF1ZW5jZSBudW1iZXIpXQogICAg QWNrbm93bGVkZ2VtZW50IG51bWJlcjogMTkwNSAgICAocmVsYXRpdmUgYWNr IG51bWJlcikKICAgIEhlYWRlciBsZW5ndGg6IDIwIGJ5dGVzCiAgICBGbGFn czogMHgxOCAoUFNILCBBQ0spCiAgICAgICAgMC4uLiAuLi4uID0gQ29uZ2Vz dGlvbiBXaW5kb3cgUmVkdWNlZCAoQ1dSKTogTm90IHNldAogICAgICAgIC4w Li4gLi4uLiA9IEVDTi1FY2hvOiBOb3Qgc2V0CiAgICAgICAgLi4wLiAuLi4u ID0gVXJnZW50OiBOb3Qgc2V0CiAgICAgICAgLi4uMSAuLi4uID0gQWNrbm93 bGVkZ21lbnQ6IFNldAogICAgICAgIC4uLi4gMS4uLiA9IFB1c2g6IFNldAog ICAgICAgIC4uLi4gLjAuLiA9IFJlc2V0OiBOb3Qgc2V0CiAgICAgICAgLi4u LiAuLjAuID0gU3luOiBOb3Qgc2V0CiAgICAgICAgLi4uLiAuLi4wID0gRmlu OiBOb3Qgc2V0CiAgICBXaW5kb3cgc2l6ZTogNjU1MzUKICAgIENoZWNrc3Vt OiAweDdlZDUgW2NvcnJlY3RdCiAgICAgICAgW0dvb2QgQ2hlY2tzdW06IFRy dWVdCiAgICAgICAgW0JhZCBDaGVja3N1bTogRmFsc2VdCiAgICBbU0VRL0FD SyBhbmFseXNpc10KICAgICAgICBbVGhpcyBpcyBhbiBBQ0sgdG8gdGhlIHNl Z21lbnQgaW4gZnJhbWU6IDI4XQogICAgICAgIFtUaGUgUlRUIHRvIEFDSyB0 aGUgc2VnbWVudCB3YXM6IDAuMDAwMjIxMDAwIHNlY29uZHNdClJlbW90ZSBQ cm9jZWR1cmUgQ2FsbCwgVHlwZTpSZXBseSBYSUQ6MHg1N2RiZDRlZAogICAg RnJhZ21lbnQgaGVhZGVyOiBMYXN0IGZyYWdtZW50LCAzNiBieXRlcwogICAg ICAgIDEuLi4gLi4uLiAuLi4uIC4uLi4gLi4uLiAuLi4uIC4uLi4gLi4uLiA9 IExhc3QgRnJhZ21lbnQ6IFllcwogICAgICAgIC4wMDAgMDAwMCAwMDAwIDAw MDAgMDAwMCAwMDAwIDAwMTAgMDEwMCA9IEZyYWdtZW50IExlbmd0aDogMzYK ICAgIFhJRDogMHg1N2RiZDRlZCAoMTQ3NDAyNDY4NSkKICAgIE1lc3NhZ2Ug VHlwZTogUmVwbHkgKDEpCiAgICBbUHJvZ3JhbTogTkZTICgxMDAwMDMpXQog ICAgW1Byb2dyYW0gVmVyc2lvbjogM10KICAgIFtQcm9jZWR1cmU6IFdSSVRF ICg3KV0KICAgIFJlcGx5IFN0YXRlOiBhY2NlcHRlZCAoMCkKICAgIFtUaGlz IGlzIGEgcmVwbHkgdG8gYSByZXF1ZXN0IGluIGZyYW1lIDI4XQogICAgW1Rp bWUgZnJvbSByZXF1ZXN0OiAwLjAwMDIyMTAwMCBzZWNvbmRzXQogICAgVmVy aWZpZXIKICAgICAgICBGbGF2b3I6IEFVVEhfTlVMTCAoMCkKICAgICAgICBM ZW5ndGg6IDAKICAgIEFjY2VwdCBTdGF0ZTogUlBDIGV4ZWN1dGVkIHN1Y2Nl c3NmdWxseSAoMCkKTmV0d29yayBGaWxlIFN5c3RlbSwgV1JJVEUgUmVwbHkg IEVycm9yOk5GUzNFUlJfSU8KICAgIFtQcm9ncmFtIFZlcnNpb246IDNdCiAg ICBbVjMgUHJvY2VkdXJlOiBXUklURSAoNyldCiAgICBTdGF0dXM6IE5GUzNF UlJfSU8gKDUpCiAgICBmaWxlX3djYwogICAgICAgIGJlZm9yZQogICAgICAg ICAgICBhdHRyaWJ1dGVzX2ZvbGxvdzogbm8gdmFsdWUgKDApCiAgICAgICAg YWZ0ZXIKICAgICAgICAgICAgYXR0cmlidXRlc19mb2xsb3c6IG5vIHZhbHVl ICgwKQoKMDAwMCAgMDAgMzAgNDggN2IgNTIgMzQgMDAgMTUgMTcgYmYgZWIg N2IgMDggMDAgNDUgMDAgICAuMEh7UjQuLi4uLnsuLkUuCjAwMTAgIDAwIDUw IGI4IGUzIDQwIDAwIDQwIDA2IGZiIDUxIGMwIGE4IDAyIDg5IGMwIGE4ICAg LlAuLkAuQC4uUS4uLi4uLgowMDIwICAwMiA5OSAwOCAwMSAwMiA2NiBlZSBj MyBjMCA0MiAyMiBkZCAyMSAxZSA1MCAxOCAgIC4uLi4uZi4uLkIiLiEuUC4K MDAzMCAgZmYgZmYgN2UgZDUgMDAgMDAgODAgMDAgMDAgMjQgNTcgZGIgZDQg ZWQgMDAgMDAgICAuLn4uLi4uLi4kVy4uLi4uCjAwNDAgIDAwIDAxIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAgLi4uLi4u Li4uLi4uLi4uLgowMDUwICAwMCAwMCAwMCAwMCAwMCAwNSAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAgICAgICAgIC4uLi4uLi4uLi4uLi4uCgpOby4gICAg IFRpbWUgICAgICAgIFNvdXJjZSAgICAgICAgICAgICAgICBEZXN0aW5hdGlv biAgICAgICAgICAgUHJvdG9jb2wgSW5mbwogICAgIDMwIDAuMDAzNTI0ICAg IDE5Mi4xNjguMi4xNTMgICAgICAgICAxOTIuMTY4LjIuMTM3ICAgICAgICAg TkZTICAgICAgVjMgV1JJVEUgQ2FsbCAoUmVwbHkgSW4gMzEpLCBGSDoweDgx MDYwMmZjIE9mZnNldDowIExlbjoxNSBVTlNUQUJMRQoKRnJhbWUgMzAgKDE5 MCBieXRlcyBvbiB3aXJlLCAxOTAgYnl0ZXMgY2FwdHVyZWQpCiAgICBBcnJp dmFsIFRpbWU6IEphbiAzMCwgMjAxMCAxMjo0MTo0Ni45MTQzNTIwMDAKICAg IFtUaW1lIGRlbHRhIGZyb20gcHJldmlvdXMgY2FwdHVyZWQgZnJhbWU6IDAu MDAwMDI4MDAwIHNlY29uZHNdCiAgICBbVGltZSBkZWx0YSBmcm9tIHByZXZp b3VzIGRpc3BsYXllZCBmcmFtZTogMC4wMDAwMjgwMDAgc2Vjb25kc10KICAg IFtUaW1lIHNpbmNlIHJlZmVyZW5jZSBvciBmaXJzdCBmcmFtZTogMC4wMDM1 MjQwMDAgc2Vjb25kc10KICAgIEZyYW1lIE51bWJlcjogMzAKICAgIEZyYW1l IExlbmd0aDogMTkwIGJ5dGVzCiAgICBDYXB0dXJlIExlbmd0aDogMTkwIGJ5 dGVzCiAgICBbRnJhbWUgaXMgbWFya2VkOiBGYWxzZV0KICAgIFtQcm90b2Nv bHMgaW4gZnJhbWU6IGV0aDppcDp0Y3A6cnBjOm5mc10KICAgIFtDb2xvcmlu ZyBSdWxlIE5hbWU6IENoZWNrc3VtIEVycm9yc10KICAgIFtDb2xvcmluZyBS dWxlIFN0cmluZzogY2RwLmNoZWNrc3VtX2JhZD09MSB8fCBlZHAuY2hlY2tz dW1fYmFkPT0xIHx8IGlwLmNoZWNrc3VtX2JhZD09MSB8fCB0Y3AuY2hlY2tz dW1fYmFkPT0xIHx8IHVkcC5jaGVja3N1bV9iYWQ9PTFdCkV0aGVybmV0IElJ LCBTcmM6IFN1cGVybWljXzdiOjUyOjM0ICgwMDozMDo0ODo3Yjo1MjozNCks IERzdDogSW50ZWxDb3JfYmY6ZWI6N2IgKDAwOjE1OjE3OmJmOmViOjdiKQog ICAgRGVzdGluYXRpb246IEludGVsQ29yX2JmOmViOjdiICgwMDoxNToxNzpi ZjplYjo3YikKICAgICAgICBBZGRyZXNzOiBJbnRlbENvcl9iZjplYjo3YiAo MDA6MTU6MTc6YmY6ZWI6N2IpCiAgICAgICAgLi4uLiAuLi4wIC4uLi4gLi4u LiAuLi4uIC4uLi4gPSBJRyBiaXQ6IEluZGl2aWR1YWwgYWRkcmVzcyAodW5p Y2FzdCkKICAgICAgICAuLi4uIC4uMC4gLi4uLiAuLi4uIC4uLi4gLi4uLiA9 IExHIGJpdDogR2xvYmFsbHkgdW5pcXVlIGFkZHJlc3MgKGZhY3RvcnkgZGVm YXVsdCkKICAgIFNvdXJjZTogU3VwZXJtaWNfN2I6NTI6MzQgKDAwOjMwOjQ4 OjdiOjUyOjM0KQogICAgICAgIEFkZHJlc3M6IFN1cGVybWljXzdiOjUyOjM0 ICgwMDozMDo0ODo3Yjo1MjozNCkKICAgICAgICAuLi4uIC4uLjAgLi4uLiAu Li4uIC4uLi4gLi4uLiA9IElHIGJpdDogSW5kaXZpZHVhbCBhZGRyZXNzICh1 bmljYXN0KQogICAgICAgIC4uLi4gLi4wLiAuLi4uIC4uLi4gLi4uLiAuLi4u ID0gTEcgYml0OiBHbG9iYWxseSB1bmlxdWUgYWRkcmVzcyAoZmFjdG9yeSBk ZWZhdWx0KQogICAgVHlwZTogSVAgKDB4MDgwMCkKSW50ZXJuZXQgUHJvdG9j b2wsIFNyYzogMTkyLjE2OC4yLjE1MyAoMTkyLjE2OC4yLjE1MyksIERzdDog MTkyLjE2OC4yLjEzNyAoMTkyLjE2OC4yLjEzNykKICAgIFZlcnNpb246IDQK ICAgIEhlYWRlciBsZW5ndGg6IDIwIGJ5dGVzCiAgICBEaWZmZXJlbnRpYXRl ZCBTZXJ2aWNlcyBGaWVsZDogMHgwMCAoRFNDUCAweDAwOiBEZWZhdWx0OyBF Q046IDB4MDApCiAgICAgICAgMDAwMCAwMC4uID0gRGlmZmVyZW50aWF0ZWQg U2VydmljZXMgQ29kZXBvaW50OiBEZWZhdWx0ICgweDAwKQogICAgICAgIC4u Li4gLi4wLiA9IEVDTi1DYXBhYmxlIFRyYW5zcG9ydCAoRUNUKTogMAogICAg ICAgIC4uLi4gLi4uMCA9IEVDTi1DRTogMAogICAgVG90YWwgTGVuZ3RoOiAx NzYKICAgIElkZW50aWZpY2F0aW9uOiAweGY4YjggKDYzNjcyKQogICAgRmxh Z3M6IDB4MDQgKERvbid0IEZyYWdtZW50KQogICAgICAgIDAuLi4gPSBSZXNl cnZlZCBiaXQ6IE5vdCBzZXQKICAgICAgICAuMS4uID0gRG9uJ3QgZnJhZ21l bnQ6IFNldAogICAgICAgIC4uMC4gPSBNb3JlIGZyYWdtZW50czogTm90IHNl dAogICAgRnJhZ21lbnQgb2Zmc2V0OiAwCiAgICBUaW1lIHRvIGxpdmU6IDY0 CiAgICBQcm90b2NvbDogVENQICgweDA2KQogICAgSGVhZGVyIGNoZWNrc3Vt OiAweGJiMWMgW2NvcnJlY3RdCiAgICAgICAgW0dvb2Q6IFRydWVdCiAgICAg ICAgW0JhZCA6IEZhbHNlXQogICAgU291cmNlOiAxOTIuMTY4LjIuMTUzICgx OTIuMTY4LjIuMTUzKQogICAgRGVzdGluYXRpb246IDE5Mi4xNjguMi4xMzcg KDE5Mi4xNjguMi4xMzcpClRyYW5zbWlzc2lvbiBDb250cm9sIFByb3RvY29s LCBTcmMgUG9ydDogc3NoZWxsICg2MTQpLCBEc3QgUG9ydDogbmZzICgyMDQ5 KSwgU2VxOiAxOTA1LCBBY2s6IDYwMSwgTGVuOiAxMzYKICAgIFNvdXJjZSBw b3J0OiBzc2hlbGwgKDYxNCkKICAgIERlc3RpbmF0aW9uIHBvcnQ6IG5mcyAo MjA0OSkKICAgIFNlcXVlbmNlIG51bWJlcjogMTkwNSAgICAocmVsYXRpdmUg c2VxdWVuY2UgbnVtYmVyKQogICAgW05leHQgc2VxdWVuY2UgbnVtYmVyOiAy MDQxICAgIChyZWxhdGl2ZSBzZXF1ZW5jZSBudW1iZXIpXQogICAgQWNrbm93 bGVkZ2VtZW50IG51bWJlcjogNjAxICAgIChyZWxhdGl2ZSBhY2sgbnVtYmVy KQogICAgSGVhZGVyIGxlbmd0aDogMjAgYnl0ZXMKICAgIEZsYWdzOiAweDE4 IChQU0gsIEFDSykKICAgICAgICAwLi4uIC4uLi4gPSBDb25nZXN0aW9uIFdp bmRvdyBSZWR1Y2VkIChDV1IpOiBOb3Qgc2V0CiAgICAgICAgLjAuLiAuLi4u ID0gRUNOLUVjaG86IE5vdCBzZXQKICAgICAgICAuLjAuIC4uLi4gPSBVcmdl bnQ6IE5vdCBzZXQKICAgICAgICAuLi4xIC4uLi4gPSBBY2tub3dsZWRnbWVu dDogU2V0CiAgICAgICAgLi4uLiAxLi4uID0gUHVzaDogU2V0CiAgICAgICAg Li4uLiAuMC4uID0gUmVzZXQ6IE5vdCBzZXQKICAgICAgICAuLi4uIC4uMC4g PSBTeW46IE5vdCBzZXQKICAgICAgICAuLi4uIC4uLjAgPSBGaW46IE5vdCBz ZXQKICAgIFdpbmRvdyBzaXplOiA2NTUzNQogICAgQ2hlY2tzdW06IDB4ODcx NSBbaW5jb3JyZWN0LCBzaG91bGQgYmUgMHhlNjE2IChtYXliZSBjYXVzZWQg YnkgIlRDUCBjaGVja3N1bSBvZmZsb2FkIj8pXQogICAgICAgIFtHb29kIENo ZWNrc3VtOiBGYWxzZV0KICAgICAgICBbQmFkIENoZWNrc3VtOiBUcnVlXQog ICAgW1NFUS9BQ0sgYW5hbHlzaXNdCiAgICAgICAgW1RoaXMgaXMgYW4gQUNL IHRvIHRoZSBzZWdtZW50IGluIGZyYW1lOiAyOV0KICAgICAgICBbVGhlIFJU VCB0byBBQ0sgdGhlIHNlZ21lbnQgd2FzOiAwLjAwMDAyODAwMCBzZWNvbmRz XQpSZW1vdGUgUHJvY2VkdXJlIENhbGwsIFR5cGU6Q2FsbCBYSUQ6MHg1N2Ri ZDRlZQogICAgRnJhZ21lbnQgaGVhZGVyOiBMYXN0IGZyYWdtZW50LCAxMzIg Ynl0ZXMKICAgICAgICAxLi4uIC4uLi4gLi4uLiAuLi4uIC4uLi4gLi4uLiAu Li4uIC4uLi4gPSBMYXN0IEZyYWdtZW50OiBZZXMKICAgICAgICAuMDAwIDAw MDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAxMDAwIDAxMDAgPSBGcmFnbWVudCBM ZW5ndGg6IDEzMgogICAgWElEOiAweDU3ZGJkNGVlICgxNDc0MDI0Njg2KQog ICAgTWVzc2FnZSBUeXBlOiBDYWxsICgwKQogICAgUlBDIFZlcnNpb246IDIK ICAgIFByb2dyYW06IE5GUyAoMTAwMDAzKQogICAgUHJvZ3JhbSBWZXJzaW9u OiAzCiAgICBQcm9jZWR1cmU6IFdSSVRFICg3KQogICAgW1RoZSByZXBseSB0 byB0aGlzIHJlcXVlc3QgaXMgaW4gZnJhbWUgMzFdCiAgICBDcmVkZW50aWFs cwogICAgICAgIEZsYXZvcjogQVVUSF9VTklYICgxKQogICAgICAgIExlbmd0 aDogMjQKICAgICAgICBTdGFtcDogMHgwMDAwMDAwMAogICAgICAgIE1hY2hp bmUgTmFtZTogPEVNUFRZPgogICAgICAgICAgICBsZW5ndGg6IDAKICAgICAg ICAgICAgY29udGVudHM6IDxFTVBUWT4KICAgICAgICBVSUQ6IDgwCiAgICAg ICAgR0lEOiA4MAogICAgICAgIEF1eGlsaWFyeSBHSURzCiAgICAgICAgICAg IEdJRDogODAKICAgIFZlcmlmaWVyCiAgICAgICAgRmxhdm9yOiBBVVRIX05V TEwgKDApCiAgICAgICAgTGVuZ3RoOiAwCk5ldHdvcmsgRmlsZSBTeXN0ZW0s IFdSSVRFIENhbGwgRkg6MHg4MTA2MDJmYyBPZmZzZXQ6MCBMZW46MTUgVU5T VEFCTEUKICAgIFtQcm9ncmFtIFZlcnNpb246IDNdCiAgICBbVjMgUHJvY2Vk dXJlOiBXUklURSAoNyldCiAgICBmaWxlCiAgICAgICAgbGVuZ3RoOiAyOAog ICAgICAgIFtoYXNoOiAweDgxMDYwMmZjXQogICAgICAgIGRlY29kZSB0eXBl IGFzOiB1bmtub3duCiAgICAgICAgZmlsZWhhbmRsZTogOEIyNjk2QTkwN0JG MEVENDBBMDAxRjg3MDUwMDAwMDAwMjlGMDQwMDAwMDAwMDAwLi4uCiAgICBv ZmZzZXQ6IDAKICAgIGNvdW50OiAxNQogICAgU3RhYmxlOiBVTlNUQUJMRSAo MCkKICAgIERhdGE6IDxEQVRBPgogICAgICAgIGxlbmd0aDogMTUKICAgICAg ICBjb250ZW50czogPERBVEE+CiAgICAgICAgZmlsbCBieXRlczogb3BhcXVl IGRhdGEKCjAwMDAgIDAwIDE1IDE3IGJmIGViIDdiIDAwIDMwIDQ4IDdiIDUy IDM0IDA4IDAwIDQ1IDAwICAgLi4uLi57LjBIe1I0Li5FLgowMDEwICAwMCBi MCBmOCBiOCA0MCAwMCA0MCAwNiBiYiAxYyBjMCBhOCAwMiA5OSBjMCBhOCAg IC4uLi5ALkAuLi4uLi4uLi4KMDAyMCAgMDIgODkgMDIgNjYgMDggMDEgMjIg ZGQgMjEgMWUgZWUgYzMgYzAgNmEgNTAgMTggICAuLi5mLi4iLiEuLi4ualAu CjAwMzAgIGZmIGZmIDg3IDE1IDAwIDAwIDgwIDAwIDAwIDg0IDU3IGRiIGQ0 IGVlIDAwIDAwICAgLi4uLi4uLi4uLlcuLi4uLgowMDQwICAwMCAwMCAwMCAw MCAwMCAwMiAwMCAwMSA4NiBhMyAwMCAwMCAwMCAwMyAwMCAwMCAgIC4uLi4u Li4uLi4uLi4uLi4KMDA1MCAgMDAgMDcgMDAgMDAgMDAgMDEgMDAgMDAgMDAg MTggMDAgMDAgMDAgMDAgMDAgMDAgICAuLi4uLi4uLi4uLi4uLi4uCjAwNjAg IDAwIDAwIDAwIDAwIDAwIDUwIDAwIDAwIDAwIDUwIDAwIDAwIDAwIDAxIDAw IDAwICAgLi4uLi5QLi4uUC4uLi4uLgowMDcwICAwMCA1MCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAxYyA4YiAyNiAgIC5QLi4uLi4uLi4u Li4uLiYKMDA4MCAgOTYgYTkgMDcgYmYgMGUgZDQgMGEgMDAgMWYgODcgMDUg MDAgMDAgMDAgMDIgOWYgICAuLi4uLi4uLi4uLi4uLi4uCjAwOTAgIDA0IDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAg Li4uLi4uLi4uLi4uLi4uLgowMGEwICAwMCAwMCAwMCAwMCAwMCAwZiAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwZiAzOCAzOSAgIC4uLi4uLi4uLi4uLi4uODkK MDBiMCAgMzkgMzggMzggMjAgMzIgMzYgMzIgMzEgMzQgMzQgMzAgMzAgMzAg MDAgICAgICAgICA5ODggMjYyMTQ0MDAwLgo= --0-977769940-1265137440=:72256-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 19:12:50 2010 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 AE30E106566C for ; Tue, 2 Feb 2010 19:12:50 +0000 (UTC) (envelope-from ambsd@raisa.eu.org) Received: from raisa.eu.org (raisa.eu.org [83.17.178.202]) by mx1.freebsd.org (Postfix) with ESMTP id 64E788FC13 for ; Tue, 2 Feb 2010 19:12:50 +0000 (UTC) Received: from bolt.zol (62-121-98-25.home.aster.pl [62.121.98.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by raisa.eu.org (Postfix) with ESMTP id 563A56D9; Tue, 2 Feb 2010 19:49:09 +0100 (CET) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Xian Chen" References: Date: Tue, 02 Feb 2010 19:46:53 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Emil Smolenski" Message-ID: In-Reply-To: User-Agent: Opera Mail/10.10 (FreeBSD) Cc: freebsd-stable@freebsd.org Subject: Re: install root certificates 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, 02 Feb 2010 19:12:50 -0000 On Tue, 02 Feb 2010 18:59:31 +0100, Xian Chen wrote: > I install > /usr/ports/security/ca_root_nss and openssl but still I cannot find where > the certifications are. > > Any ideas? Try: pkg_info -xL ca_root_nss -- am From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 19:36:19 2010 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 F18BA1065703 for ; Tue, 2 Feb 2010 19:36:19 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from chen.org.nz (ip-58-28-152-174.static-xdsl.xnet.co.nz [58.28.152.174]) by mx1.freebsd.org (Postfix) with ESMTP id 8E3E88FC19 for ; Tue, 2 Feb 2010 19:36:19 +0000 (UTC) Received: by chen.org.nz (Postfix, from userid 1000) id 95C7BE044F; Wed, 3 Feb 2010 08:36:16 +1300 (NZDT) Date: Wed, 3 Feb 2010 08:36:16 +1300 From: Jonathan Chen To: freebsd-stable@freebsd.org Message-ID: <20100202193616.GA16953@osiris.chen.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: 8-STABLE outgoing scp stalling frequently. 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, 02 Feb 2010 19:36:20 -0000 Hi, I've noticed that on a recent 8-STABLE/amd64, scp(1) appears to be stalling very frequently. This is the output from a "scp -v -v" of a 300Mb file from a local to a remote within an internal network: [.. authentication negotiation ...] debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 131072 debug2: channel_input_status_confirm: type 99 id 0 debug2: exec request accepted on channel 0 Sending file modes: C0700 367085370 file1 file1 0% 192KB 140.0KB/s 42:39 ETAdebug2: channel 0: rcvd adjust 65593 file1 0% 256KB 78.2KB/s - stalled -debug2: channel 0: rcvd adjust 81920 file1 0% 336KB 41.6KB/s - stalled -debug2: channel 0: rcvd adjust 81920 file1 0% 416KB 26.9KB/s - stalled -debug2: channel 0: rcvd adjust 81920 file1 0% 496KB 17.1KB/s - stalled -debug2: channel 0: rcvd adjust 81920 file1 0% 576KB 12.4KB/s - stalled -debug2: channel 0: rcvd adjust 81920 file1 0% 656KB 11.3KB/s - stalled -debug2: channel 0: rcvd adjust 81920 file1 0% 736KB 9.7KB/s - stalled -debug2: channel 0: rcvd adjust 81920 file1 0% 816KB 9.9KB/s - stalled -debug2: channel 0: rcvd adjust 81920 file1 0% 896KB 9.0KB/s - stalled -debug2: channel 0: rcvd adjust 81920 file1 0% 976KB 9.5KB/s - stalled -debug2: channel 0: rcvd adjust 81920 /etc/ssh/ssh_config is untouched. Oddly enough a scp of a remote file to the local machine is blindingly fast. Does anyone know what's happening here? Any tips on how to track down what the problem is? The network config appears to be fine - fetch(1) will have downloads speeds of up to 300KB/s. Cheers. -- Jonathan Chen ---------------------------------------------------------------------- "With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead." -- RFC 1925 From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 19:44:10 2010 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 AC58A106566B for ; Tue, 2 Feb 2010 19:44:10 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 761B08FC0A for ; Tue, 2 Feb 2010 19:44:10 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id o12Ji3L4000876; Tue, 2 Feb 2010 14:44:03 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <201002021944.o12Ji3L4000876@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 02 Feb 2010 14:44:09 -0500 To: Jonathan Chen , freebsd-stable@freebsd.org From: Mike Tancsa In-Reply-To: <20100202193616.GA16953@osiris.chen.org.nz> References: <20100202193616.GA16953@osiris.chen.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Subject: Re: 8-STABLE outgoing scp stalling frequently. 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, 02 Feb 2010 19:44:10 -0000 At 02:36 PM 2/2/2010, Jonathan Chen wrote: >Hi, > >I've noticed that on a recent 8-STABLE/amd64, scp(1) appears to be >stalling very frequently. This is the output from a "scp -v -v" >of a 300Mb file from a local to a remote within an internal network: Hi, Is it on the same ethernet segment, or does it go through a router(s) and is the path asymmetric? I noticed similar symptoms on a jailed box where the round trip was asymmetric and an intermediary router was generating a lot of ICMP redirects that were ignored by the sending host. ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 19:52:16 2010 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 7025D106566C for ; Tue, 2 Feb 2010 19:52:16 +0000 (UTC) (envelope-from vmagerya@gmail.com) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.186]) by mx1.freebsd.org (Postfix) with ESMTP id F361C8FC28 for ; Tue, 2 Feb 2010 19:52:15 +0000 (UTC) Received: by gv-out-0910.google.com with SMTP id n29so103132gve.39 for ; Tue, 02 Feb 2010 11:52: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 :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=Gbma1Xb++RuwtABLSO8LtuUNffV1tnoO2ot+JZVUoFs=; b=PRSpKttxnMu2ToEbH26zs5dO9OriYDIgB3hp6ZBqK1cztETeeuHmMozyGy5kcYu1WP i2oJhFfCiFRSL6GQjxzAN8FYD06mrB5thErIWkraY4BEEHyJTB9GXMYC4wGy3UmM46Fg 4KR+QZN9mkvTJuYjZ2/nuqU+cYZgy1MflErWs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=g5YXd1kzAVVA8hAr9JPZH+sdiLGpA+z9QLCTipbp9sWU1yOKbLjBnemQ0n+XqCGPIX vOOceu5f2+zYSbp/gyR11IDzAlRhmMK3C/IOxjTohqLd/VaCAv0JHsJpyPfh/dBZCW0+ hHH7G9UoaLcaT41irVBq94NnVkKvEiL9xC8dc= Received: by 10.102.207.40 with SMTP id e40mr3899652mug.86.1265138974246; Tue, 02 Feb 2010 11:29:34 -0800 (PST) Received: from ?172.16.0.7? ([85.198.160.156]) by mx.google.com with ESMTPS id w5sm9773993mue.22.2010.02.02.11.29.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 02 Feb 2010 11:29:32 -0800 (PST) Message-ID: <4B687D16.6090809@gmail.com> Date: Tue, 02 Feb 2010 21:29:26 +0200 From: Vitaly Magerya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: 8.0 install fails to create filesystem ("unable to find device node") 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, 02 Feb 2010 19:52:16 -0000 Greetings everyone. I'm trying to install FreeBSD 8.0 from Disk1 on ThinkPad T40, so far unsuccessfully. Here are the setup steps: Installer complains that "77520/16/63" may not be a good geometry for ad0, proposes "4864/255/63" instead (both eventually lead to failure). I create a single disk-wide slice (ad0s1), choose a boot manager, set up standard labeling for ad0s1, choose distributions. The setup tries to create filesystem and fails with this message: Unable to find device node for /dev/ad0s1b in /dev! Aside from debug messages, there's this on second VT: GEOM: ad0: geometry does not match label (255h,63s != 16h,63s). I also tried to setup 7.0 (w/o dangerously dedicated slicing), and then freebsd-update to 8.0. On first reboot required by freebsd-update the system drops to bootloader prompt and fails to find init on any of the filesystems. Help. Is there anything I can do to install 8.0? The dmesg of this machine (as seen by 7.0) is at [1]. I'll provide any further information -- just name it. [1] http://tx97.net/~magv/dmesg-t40.70.txt From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 20:00:04 2010 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 6DA1E1065679 for ; Tue, 2 Feb 2010 20:00:04 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 09B328FC14 for ; Tue, 2 Feb 2010 20:00:03 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAIcTaEuDaFvJ/2dsb2JhbACPJMpShEUE X-IronPort-AV: E=Sophos;i="4.49,393,1262581200"; d="scan'208";a="63999152" Received: from ganges.cs.uoguelph.ca ([131.104.91.201]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 02 Feb 2010 15:00:03 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id 430F3FB8066; Tue, 2 Feb 2010 15:00:03 -0500 (EST) X-Virus-Scanned: amavisd-new at ganges.cs.uoguelph.ca Received: from ganges.cs.uoguelph.ca ([127.0.0.1]) by localhost (ganges.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oT6KW3j8jZM7; Tue, 2 Feb 2010 15:00:02 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id D5D87FB805D; Tue, 2 Feb 2010 15:00:02 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o12KB5s12049; Tue, 2 Feb 2010 15:11:05 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Tue, 2 Feb 2010 15:11:05 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: alan bryan In-Reply-To: <878205.72256.qm@web50503.mail.re2.yahoo.com> Message-ID: References: <878205.72256.qm@web50503.mail.re2.yahoo.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-684387517-1265141465=:9141" Cc: freebsd-stable@freebsd.org Subject: Re: Zombie NFS writing from FreeBSD clients to FreeBSD 8.0 server with ZFS 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, 02 Feb 2010 20:00:04 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-684387517-1265141465=:9141 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 2 Feb 2010, alan bryan wrote: > --- On Wed, 1/6/10, Rick Macklem wrote: > From: Rick Macklem > Subject: Re: Zombie NFS writing from FreeBSD clients to FreeBSD 8.0 serve= r with ZFS > To: "alan bryan" > Cc: freebsd-stable@freebsd.org > Date: Wednesday, January 6, 2010, 12:19 PM >=20 >=20 > On Wed, 6 Jan 2010, alan bryan wrote: >=20 > > I have a AMD64 FreeBSD 8.0 server with ZFS filesystem > being shared via NFS.=A0 These are being accessed by the > clients.=A0 The clients are a mix of FreeBSD 6.2 32bit > and FreeBSD 7.0 64bit.=A0 I have seen similar behavior > from both versions of FreeBSD as clients. > > > [stuff related to lotsa writes being done snipped] > > > > Any ideas on what to try, where to look for more > insight, etc...?? > > > - Are they the same write being retried over and over? yes - it appears so > - Is the server replying to them with an error? yes >=20 > The above might give some insight into what's happening, Didn't help much. The server is replying with NFS3ERR_IO (EIO) for some reason. Unfortunately EIO is the catch all for just about everything. (There is only one case in the NFS server code that generates EIO and that would be caused by a bogus data mbuf list.) As such, I suspect the EIO is coming from ZFS for some reason, but can't be sure. Btw, a binary capture using tcpdump can be read into wireshark, which is much better at decoding NFS etc than tcpdump. rick ---559023410-684387517-1265141465=:9141-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 20:37:58 2010 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 99F0D1065694 for ; Tue, 2 Feb 2010 20:37:58 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by mx1.freebsd.org (Postfix) with ESMTP id 4C5D78FC1D for ; Tue, 2 Feb 2010 20:37:56 +0000 (UTC) Received: from vampire.homelinux.org (dslb-088-064-184-208.pools.arcor-ip.net [88.64.184.208]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0Mb2zL-1NJUwi0wDz-00K6TN; Tue, 02 Feb 2010 21:37:55 +0100 Received: (qmail 17145 invoked from network); 2 Feb 2010 20:37:54 -0000 Received: from f8x64.laiers.local (192.168.4.188) by laiers.local with SMTP; 2 Feb 2010 20:37:54 -0000 From: Max Laier Organization: FreeBSD To: freebsd-stable@freebsd.org Date: Tue, 2 Feb 2010 21:37:51 +0100 User-Agent: KMail/1.12.4 (FreeBSD/8.0-RELEASE-p2; KDE/4.3.4; amd64; ; ) References: <147432021001310037n1b67f01bx4b4e8781321cea8@mail.gmail.com> <20100202173746.GA5901@michelle.cdnetworks.com> <2a41acea1002020948l6f3d1a08v9f4ccefd1241f566@mail.gmail.com> In-Reply-To: <2a41acea1002020948l6f3d1a08v9f4ccefd1241f566@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201002022137.52064.max@love2party.net> X-Provags-ID: V01U2FsdGVkX19I56Mr2mQwD7B9J6yO1+cHHFEavOGN8q42Ut7 Byb3PPPLYCeXMw4g+d1WcI2GX90ApPyemY9KxODs7TBncBm/w3 dBnmsA/eOAwGdeU94FNjg== Cc: pyunyh@gmail.com, Nick Rogers , stable@freebsd.org, jfv@freebsd.org, Jack Vogel Subject: Re: em(4) + ALTQ broken 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, 02 Feb 2010 20:37:58 -0000 On Tuesday 02 February 2010 18:48:02 Jack Vogel wrote: > So apparently this thing needs no special knowledge in the driver, yet > something in > the new code breaks it, can someone explain tersely how the altq app > actually > "pokes" or "hooks up" to the driver? I am not clear about that and I > suspect if I was > this would all be clearer. The whole story is in man 9 altq long story short, as long as you consistently use the IFQ_* macros to manage the interface queue, things should just work. if_var.h used to conditionally define these macros to avoid ALTQ overhead when the kernel is built without ALTQ. This has changed a long time ago and should not make any difference anymore. I can't figure out who the OP is, but could you make sure that the includes that are used to built the kernel are up to date? You are building with the buildkernel target and not "the old way", right? Also, if you build just the module, the build might pick up the includes from /usr/include instead of src/sys ... > Jack > > On Tue, Feb 2, 2010 at 9:37 AM, Pyun YongHyeon wrote: > > On Tue, Feb 02, 2010 at 09:30:52AM -0800, Nick Rogers wrote: > > > > I guess the problem comes from multi-queue support. The drbr > > > > interface is implemented with inline function so em(4)/igb(4) may > > > > have to define ALTQ to the header. I have not tested the patch(no > > > > time at this moment) but would you give it try? > > > > > > > > I tried the patch and it did not work. > > > > You rebuilt kernel, right? Rebuilding kernel module has no effect. > > _______________________________________________ > 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" > > > !DSPAM:4b686584144321871135632! > From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 20:50:30 2010 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 A7481106566B for ; Tue, 2 Feb 2010 20:50:30 +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 37CCD8FC14 for ; Tue, 2 Feb 2010 20:50:30 +0000 (UTC) Received: from vampire.homelinux.org (dslb-088-064-184-208.pools.arcor-ip.net [88.64.184.208]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MW7C9-1NEb7q0wIr-00XQUy; Tue, 02 Feb 2010 21:37:55 +0100 Received: (qmail 17145 invoked from network); 2 Feb 2010 20:37:54 -0000 Received: from f8x64.laiers.local (192.168.4.188) by laiers.local with SMTP; 2 Feb 2010 20:37:54 -0000 From: Max Laier Organization: FreeBSD To: freebsd-stable@freebsd.org Date: Tue, 2 Feb 2010 21:37:51 +0100 User-Agent: KMail/1.12.4 (FreeBSD/8.0-RELEASE-p2; KDE/4.3.4; amd64; ; ) References: <147432021001310037n1b67f01bx4b4e8781321cea8@mail.gmail.com> <20100202173746.GA5901@michelle.cdnetworks.com> <2a41acea1002020948l6f3d1a08v9f4ccefd1241f566@mail.gmail.com> In-Reply-To: <2a41acea1002020948l6f3d1a08v9f4ccefd1241f566@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201002022137.52064.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1+b3PakuDp8P71UdvdIx7JA6aEad2tp3B1Ub/z 6/g4t91eypukHD1Tqbvlyeww3xkYJhY/DI2HHLddiSAjzHzXWd XXJ7AwZkG48wkIzEjYhbw== Cc: pyunyh@gmail.com, Nick Rogers , stable@freebsd.org, jfv@freebsd.org, Jack Vogel Subject: Re: em(4) + ALTQ broken 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, 02 Feb 2010 20:50:30 -0000 On Tuesday 02 February 2010 18:48:02 Jack Vogel wrote: > So apparently this thing needs no special knowledge in the driver, yet > something in > the new code breaks it, can someone explain tersely how the altq app > actually > "pokes" or "hooks up" to the driver? I am not clear about that and I > suspect if I was > this would all be clearer. The whole story is in man 9 altq long story short, as long as you consistently use the IFQ_* macros to manage the interface queue, things should just work. if_var.h used to conditionally define these macros to avoid ALTQ overhead when the kernel is built without ALTQ. This has changed a long time ago and should not make any difference anymore. I can't figure out who the OP is, but could you make sure that the includes that are used to built the kernel are up to date? You are building with the buildkernel target and not "the old way", right? Also, if you build just the module, the build might pick up the includes from /usr/include instead of src/sys ... > Jack > > On Tue, Feb 2, 2010 at 9:37 AM, Pyun YongHyeon wrote: > > On Tue, Feb 02, 2010 at 09:30:52AM -0800, Nick Rogers wrote: > > > > I guess the problem comes from multi-queue support. The drbr > > > > interface is implemented with inline function so em(4)/igb(4) may > > > > have to define ALTQ to the header. I have not tested the patch(no > > > > time at this moment) but would you give it try? > > > > > > > > I tried the patch and it did not work. > > > > You rebuilt kernel, right? Rebuilding kernel module has no effect. > > _______________________________________________ > 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" > > > !DSPAM:4b686584144321871135632! > From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 20:51:13 2010 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 EEBEC1065695 for ; Tue, 2 Feb 2010 20:51:13 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from chen.org.nz (ip-58-28-152-174.static-xdsl.xnet.co.nz [58.28.152.174]) by mx1.freebsd.org (Postfix) with ESMTP id 962468FC08 for ; Tue, 2 Feb 2010 20:51:13 +0000 (UTC) Received: by chen.org.nz (Postfix, from userid 1000) id 97846E044F; Wed, 3 Feb 2010 09:51:11 +1300 (NZDT) Date: Wed, 3 Feb 2010 09:51:11 +1300 From: Jonathan Chen To: Mike Tancsa Message-ID: <20100202205111.GA18184@osiris.chen.org.nz> References: <20100202193616.GA16953@osiris.chen.org.nz> <201002021944.o12Ji3L4000876@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201002021944.o12Ji3L4000876@lava.sentex.ca> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: 8-STABLE outgoing scp stalling frequently. 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, 02 Feb 2010 20:51:14 -0000 On Tue, Feb 02, 2010 at 02:44:09PM -0500, Mike Tancsa wrote: > At 02:36 PM 2/2/2010, Jonathan Chen wrote: > >Hi, > > > >I've noticed that on a recent 8-STABLE/amd64, scp(1) appears to be > >stalling very frequently. This is the output from a "scp -v -v" > >of a 300Mb file from a local to a remote within an internal network: > > Hi, > Is it on the same ethernet segment, or does it go through a > router(s) and is the path asymmetric? The 2 hosts are going in on cables to the same switch. I've tried other ports and hosts , but experience the same problem. -- Jonathan Chen ---------------------------------------------------------------------- "Irrationality is the square root of all evil" - Douglas Hofstadter From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 21:09:26 2010 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 32978106568B for ; Tue, 2 Feb 2010 21:09:26 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-pz0-f202.google.com (mail-pz0-f202.google.com [209.85.222.202]) by mx1.freebsd.org (Postfix) with ESMTP id 06E348FC26 for ; Tue, 2 Feb 2010 21:09:25 +0000 (UTC) Received: by pzk40 with SMTP id 40so521703pzk.7 for ; Tue, 02 Feb 2010 13:09:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=jvHgc7Q98GGxQKZAnxUrvoP8ZQqT9lxJa+okT3BnbGs=; b=KFMAhUZsdrMzm2bT3AsKPXTOScM1gJ0o41U7mTlRT7iunNu1t/eXgRo9OiJmoE9QMM WZvcyzel8qhIycDDL9BVRHHNynQ57c0deDYT05hHVw2+64Ff3V6ynIneNAe8M4rRtVlR //G/Nx3sxTkrXKzoVD+Z85VvE23Wf5J9/rwTU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=pjz5Ys7Ku4B6FUUeJ0R7SU5odzygZ7mpID/+h1MfZvrhIfn/qhiedY8m0vxhlgTrPb DL2I+tjEAL9vwLSb7hMkMNx4JWS6D8EGwwnjsOzgkZ4yC8JYm7uFVO8rC4NZ6TR0AMXD 0d400bcuU19uV/mxNiIsxVDR1SEnfPVUVa+pE= MIME-Version: 1.0 Received: by 10.142.249.10 with SMTP id w10mr831096wfh.207.1265144965510; Tue, 02 Feb 2010 13:09:25 -0800 (PST) In-Reply-To: <20100202205111.GA18184@osiris.chen.org.nz> References: <20100202193616.GA16953@osiris.chen.org.nz> <201002021944.o12Ji3L4000876@lava.sentex.ca> <20100202205111.GA18184@osiris.chen.org.nz> Date: Tue, 2 Feb 2010 15:09:25 -0600 Message-ID: <6201873e1002021309t74415d5ah1b92b15da6074d4c@mail.gmail.com> From: Adam Vande More To: Jonathan Chen Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: 8-STABLE outgoing scp stalling frequently. 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, 02 Feb 2010 21:09:26 -0000 On Tue, Feb 2, 2010 at 2:51 PM, Jonathan Chen wrote: > The 2 hosts are going in on cables to the same switch. I've tried > other ports and hosts , but experience the same problem. > I run a similar network setup at home, and am unable to replicate your experience regardless which host is being copied to/from. Perhaps you have a more specific issue eg nic driver ? -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 21:16:11 2010 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 A1B7F106568B for ; Tue, 2 Feb 2010 21:16:11 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 693558FC17 for ; Tue, 2 Feb 2010 21:16:11 +0000 (UTC) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NcQ6I-000Hqv-5x; Tue, 02 Feb 2010 21:15:58 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NcQ6I-0002Wv-53; Tue, 02 Feb 2010 21:15:58 +0000 Date: Tue, 02 Feb 2010 21:15:58 +0000 Message-Id: To: amvandemore@gmail.com, jonc@chen.org.nz In-Reply-To: <6201873e1002021309t74415d5ah1b92b15da6074d4c@mail.gmail.com> From: Pete French Cc: freebsd-stable@freebsd.org Subject: Re: 8-STABLE outgoing scp stalling frequently. 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, 02 Feb 2010 21:16:11 -0000 > I run a similar network setup at home, and am unable to replicate your > experience regardless which host is being copied to/from. Perhaps you have > a more specific issue eg nic driver ? I missed the start of this thread, but I have also seen scp stalling on 8-STABLE, except in my case it as inbound ... i.e. uploading to the FreeBSd machine. The client was scp on OSX, though I also saw the same issue with rsync, leading me to belve taht the problem lies somewhere in ssh. In the end I just used NFS and didn't worry too much about it, but just a "me too" to show it's not just the OP. Mu machines were also directly connected to the same switch on the same ether. -pete. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 21:17:29 2010 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 508901065696 for ; Tue, 2 Feb 2010 21:17:29 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 368678FC08 for ; Tue, 2 Feb 2010 21:17:28 +0000 (UTC) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta01.emeryville.ca.mail.comcast.net with comcast id d2FZ1d00A1GXsucA19HVxb; Tue, 02 Feb 2010 21:17:29 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta07.emeryville.ca.mail.comcast.net with comcast id d9HU1d00B3S48mS8T9HVZa; Tue, 02 Feb 2010 21:17:29 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id CEDEA1E3033; Tue, 2 Feb 2010 13:17:27 -0800 (PST) Date: Tue, 2 Feb 2010 13:17:27 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100202211727.GA80240@icarus.home.lan> References: <20100202193616.GA16953@osiris.chen.org.nz> <201002021944.o12Ji3L4000876@lava.sentex.ca> <20100202205111.GA18184@osiris.chen.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100202205111.GA18184@osiris.chen.org.nz> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: 8-STABLE outgoing scp stalling frequently. 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, 02 Feb 2010 21:17:29 -0000 On Wed, Feb 03, 2010 at 09:51:11AM +1300, Jonathan Chen wrote: > On Tue, Feb 02, 2010 at 02:44:09PM -0500, Mike Tancsa wrote: > > At 02:36 PM 2/2/2010, Jonathan Chen wrote: > > >Hi, > > > > > >I've noticed that on a recent 8-STABLE/amd64, scp(1) appears to be > > >stalling very frequently. This is the output from a "scp -v -v" > > >of a 300Mb file from a local to a remote within an internal network: > > > > Hi, > > Is it on the same ethernet segment, or does it go through a > > router(s) and is the path asymmetric? > > The 2 hosts are going in on cables to the same switch. I've tried > other ports and hosts , but experience the same problem. Do you see this behaviour both directions, or just unidirectional? E.g. does the problem happen in both of the below examples, or just one? box1$ scp user@box2:/file . box1$ scp file user@box2:/some/path -- | Jeremy Chadwick jdc@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 Tue Feb 2 21:22:41 2010 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 C7A10106568B for ; Tue, 2 Feb 2010 21:22:41 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 883A78FC1A for ; Tue, 2 Feb 2010 21:22:41 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id o12LMbWX001373; Tue, 2 Feb 2010 16:22:37 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <201002022122.o12LMbWX001373@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 02 Feb 2010 16:22:43 -0500 To: Jonathan Chen From: Mike Tancsa In-Reply-To: <6201873e1002021309t74415d5ah1b92b15da6074d4c@mail.gmail.co m> References: <20100202193616.GA16953@osiris.chen.org.nz> <201002021944.o12Ji3L4000876@lava.sentex.ca> <20100202205111.GA18184@osiris.chen.org.nz> <6201873e1002021309t74415d5ah1b92b15da6074d4c@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: 8-STABLE outgoing scp stalling frequently. 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, 02 Feb 2010 21:22:42 -0000 At 04:09 PM 2/2/2010, Adam Vande More wrote: >On Tue, Feb 2, 2010 at 2:51 PM, Jonathan Chen ><jonc@chen.org.nz> wrote: >The 2 hosts are going in on cables to the same switch. I've tried >other ports and hosts , but experience the same problem. > > >I run a similar network setup at home, and am unable to replicate >your experience regardless which host is being copied >to/from. Perhaps you have a more specific issue eg nic driver ? This is to a box on the same ethernet and subnet 0(ich10)% dd if=/dev/urandom of=testfile bs=1024k count=100 100+0 records in 100+0 records out 104857600 bytes transferred in 1.879028 secs (55804169 bytes/sec) 0(ich10)% scp testfile 192.168.1.207:/dev/null testfile 100% 100MB 12.5MB/s 00:08 0(ich10)% scp -C testfile 192.168.1.207:/dev/null testfile 100% 100MB 11.1MB/s 00:09 0(ich10)% From RELENG_8 to RELENG_7 em0: flags=8843 metric 0 mtu 1500 options=19b ether 00:1c:c0:95:0d:0d inet 192.168.1.219 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX ) status: active uname -a FreeBSD ich10.sentex.ca 8.0-STABLE FreeBSD 8.0-STABLE #13: Tue Jan 19 12:24:57 EST 2010 mdtancsa@ich10.sentex.ca:/usr/obj/usr/src/sys/server i386 If you are using an em nic, does sysctl -w dev.em.0.stats=1 give any interesting numbers in /var/log/messages ? em0: Excessive collisions = 0 em0: Sequence errors = 0 em0: Defer count = 0 em0: Missed Packets = 0 em0: Receive No Buffers = 0 em0: Receive Length Errors = 0 em0: Receive errors = 0 em0: Crc errors = 0 em0: Alignment errors = 0 em0: Collision/Carrier extension errors = 0 em0: RX overruns = 0 em0: watchdog timeouts = 0 em0: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0 em0: XON Rcvd = 0 em0: XON Xmtd = 0 em0: XOFF Rcvd = 0 em0: XOFF Xmtd = 0 em0: Good Packets Rcvd = 1003041 em0: Good Packets Xmtd = 690690 em0: TSO Contexts Xmtd = 15709 em0: TSO Contexts Failed = 0 Results from RELENG_8 to RELENG_9 are about the same, but on a different nic 0(ich10)% scp testfile 10.255.255.117:/dev/null testfile 100% 100MB 11.1MB/s 00:09 0(ich10)% igb1: Excessive collisions = 0 igb1: Sequence errors = 0 igb1: Defer count = 0 igb1: Missed Packets = 0 igb1: Receive No Buffers = 0 igb1: Receive Length Errors = 0 igb1: Receive errors = 0 igb1: Crc errors = 0 igb1: Alignment errors = 0 igb1: Collision/Carrier extension errors = 0 igb1: RX overruns = 0 igb1: watchdog timeouts = 0 igb1: XON Rcvd = 0 igb1: XON Xmtd = 0 igb1: XOFF Rcvd = 0 igb1: XOFF Xmtd = 0 igb1: Good Packets Rcvd = 36484881 igb1: Good Packets Xmtd = 50922117 igb1: TSO Contexts Xmtd = 5452450 igb1: TSO Contexts Failed = 0 >-- >Adam Vande More -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 21:31:50 2010 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 0F4D8106568B for ; Tue, 2 Feb 2010 21:31:50 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail3.es.net [IPv6:2001:400:4c01::2]) by mx1.freebsd.org (Postfix) with ESMTP id D9ECC8FC12 for ; Tue, 2 Feb 2010 21:31:49 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o12LVm1L001376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Feb 2010 13:31:49 -0800 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 9A87B1CC3F; Tue, 2 Feb 2010 13:31:48 -0800 (PST) To: Vitaly Magerya In-reply-to: Your message of "Tue, 02 Feb 2010 21:29:26 +0200." <4B687D16.6090809@gmail.com> Date: Tue, 02 Feb 2010 13:31:48 -0800 From: "Kevin Oberman" Message-Id: <20100202213148.9A87B1CC3F@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-02-02_13:2010-01-20, 2010-02-02, 2010-02-02 signatures=0 X-Proofpoint-Spam-Reason: safe Cc: freebsd-stable@freebsd.org Subject: Re: 8.0 install fails to create filesystem ("unable to find device node") 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, 02 Feb 2010 21:31:50 -0000 > Date: Tue, 02 Feb 2010 21:29:26 +0200 > From: Vitaly Magerya > Sender: owner-freebsd-stable@freebsd.org > > Greetings everyone. I'm trying to install FreeBSD 8.0 from Disk1 on > ThinkPad T40, so far unsuccessfully. > > Here are the setup steps: > Installer complains that "77520/16/63" may not be a good geometry for > ad0, proposes "4864/255/63" instead (both eventually lead to failure). > I create a single disk-wide slice (ad0s1), choose a boot manager, set up > standard labeling for ad0s1, choose distributions. > > The setup tries to create filesystem and fails with this message: > > Unable to find device node for /dev/ad0s1b in /dev! Are you doing a 'W'rite in the labeling tools? I'm guess that you are not, but I wanted to be sure. You don't want to. You say that you are doing the default partitions. If so, the 'b' partition should be swap. It should not get 'newfs'ed. No file system needed (or wanted) there. This tells me that something was wrong in the partition setup if it THINKS that there is a need to newfs partition 'b'. > Aside from debug messages, there's this on second VT: > > GEOM: ad0: geometry does not match label (255h,63s != 16h,63s). This is a known issue, but cosmetic in almost all cases. I suspect that you are doing something wrong, but it's hard to figure out just what it might be. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 21:39:07 2010 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 0151C106566B; Tue, 2 Feb 2010 21:39:07 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 338AA8FC1B; Tue, 2 Feb 2010 21:39:05 +0000 (UTC) Received: by wwj40 with SMTP id 40so46069wwj.13 for ; Tue, 02 Feb 2010 13:39:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=z1zhJj3ky+cQaLCy7i4IQkULiRjdrKl0x3x4y3oaPVo=; b=MRpoC+6FcOtpSV7Nn2b/rpLqYzQLkLja28+1tYBJ5NR4lx/4+WcuoDpOdoc2CgyPaC Fe9ymgTAAsTO1MtUSmDSH34Roz31EuMCLqdsJcKLdabNUVoJxHzMG0cerqnq1e/yMtBw 4W6FsXf6RqfHi7zcY3H25zo+14O5NR/HfDYrI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=w2FnjrOrZieNSPp8QqbI4fVpkJbH6kBpioRD5ePuFu5uk4wqZH7U0ZQcBaH43Uy+qL jNHlQJNXjUeDoM5rB5q/T/GVOPnatWX1bTdRoNt0KFUb8ikOIaLqGjrgMHMY3lnRhGho 61ZkNSyEKrRnRQqcH5072VhY8S/QQIsWQKTtA= MIME-Version: 1.0 Received: by 10.216.87.20 with SMTP id x20mr960621wee.158.1265146745045; Tue, 02 Feb 2010 13:39:05 -0800 (PST) In-Reply-To: <201002022137.52064.max@love2party.net> References: <147432021001310037n1b67f01bx4b4e8781321cea8@mail.gmail.com> <20100202173746.GA5901@michelle.cdnetworks.com> <2a41acea1002020948l6f3d1a08v9f4ccefd1241f566@mail.gmail.com> <201002022137.52064.max@love2party.net> Date: Tue, 2 Feb 2010 13:39:04 -0800 Message-ID: <2a41acea1002021339i3801fc4bw736fa01188f60290@mail.gmail.com> From: Jack Vogel To: Max Laier Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: pyunyh@gmail.com, Nick Rogers , stable@freebsd.org, freebsd-stable@freebsd.org, jfv@freebsd.org Subject: Re: em(4) + ALTQ broken 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, 02 Feb 2010 21:39:07 -0000 Thanks Max, yes, i've done some digging myself and now see how things work, the rubber meets the road in the defines in if_var.h. And what it does is effectively short circuit Kip Macy's multiqueue code in favor of the old method. Right now I can see two possibilities, either the defines are not set in the build, OR there is something wrong in the logic of the short circuit approach in Kip's code. A question might be if ANY driver that is usinig TX Multiqueue has been successfully used with ALTQ? Jack On Tue, Feb 2, 2010 at 12:37 PM, Max Laier wrote: > On Tuesday 02 February 2010 18:48:02 Jack Vogel wrote: > > So apparently this thing needs no special knowledge in the driver, yet > > something in > > the new code breaks it, can someone explain tersely how the altq app > > actually > > "pokes" or "hooks up" to the driver? I am not clear about that and I > > suspect if I was > > this would all be clearer. > > The whole story is in > > man 9 altq > > long story short, as long as you consistently use the IFQ_* macros to > manage > the interface queue, things should just work. if_var.h used to > conditionally > define these macros to avoid ALTQ overhead when the kernel is built without > ALTQ. This has changed a long time ago and should not make any difference > anymore. > > I can't figure out who the OP is, but could you make sure that the includes > that are used to built the kernel are up to date? You are building with > the > buildkernel target and not "the old way", right? Also, if you build just > the > module, the build might pick up the includes from /usr/include instead of > src/sys ... > > > Jack > > > > On Tue, Feb 2, 2010 at 9:37 AM, Pyun YongHyeon wrote: > > > On Tue, Feb 02, 2010 at 09:30:52AM -0800, Nick Rogers wrote: > > > > > I guess the problem comes from multi-queue support. The drbr > > > > > interface is implemented with inline function so em(4)/igb(4) may > > > > > have to define ALTQ to the header. I have not tested the patch(no > > > > > time at this moment) but would you give it try? > > > > > > > > > > I tried the patch and it did not work. > > > > > > You rebuilt kernel, right? Rebuilding kernel module has no effect. > > > > _______________________________________________ > > 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 > " > > > > > > !DSPAM:4b686584144321871135632! > > > From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 21:39:07 2010 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 0151C106566B; Tue, 2 Feb 2010 21:39:07 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 338AA8FC1B; Tue, 2 Feb 2010 21:39:05 +0000 (UTC) Received: by wwj40 with SMTP id 40so46069wwj.13 for ; Tue, 02 Feb 2010 13:39:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=z1zhJj3ky+cQaLCy7i4IQkULiRjdrKl0x3x4y3oaPVo=; b=MRpoC+6FcOtpSV7Nn2b/rpLqYzQLkLja28+1tYBJ5NR4lx/4+WcuoDpOdoc2CgyPaC Fe9ymgTAAsTO1MtUSmDSH34Roz31EuMCLqdsJcKLdabNUVoJxHzMG0cerqnq1e/yMtBw 4W6FsXf6RqfHi7zcY3H25zo+14O5NR/HfDYrI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=w2FnjrOrZieNSPp8QqbI4fVpkJbH6kBpioRD5ePuFu5uk4wqZH7U0ZQcBaH43Uy+qL jNHlQJNXjUeDoM5rB5q/T/GVOPnatWX1bTdRoNt0KFUb8ikOIaLqGjrgMHMY3lnRhGho 61ZkNSyEKrRnRQqcH5072VhY8S/QQIsWQKTtA= MIME-Version: 1.0 Received: by 10.216.87.20 with SMTP id x20mr960621wee.158.1265146745045; Tue, 02 Feb 2010 13:39:05 -0800 (PST) In-Reply-To: <201002022137.52064.max@love2party.net> References: <147432021001310037n1b67f01bx4b4e8781321cea8@mail.gmail.com> <20100202173746.GA5901@michelle.cdnetworks.com> <2a41acea1002020948l6f3d1a08v9f4ccefd1241f566@mail.gmail.com> <201002022137.52064.max@love2party.net> Date: Tue, 2 Feb 2010 13:39:04 -0800 Message-ID: <2a41acea1002021339i3801fc4bw736fa01188f60290@mail.gmail.com> From: Jack Vogel To: Max Laier Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: pyunyh@gmail.com, Nick Rogers , stable@freebsd.org, freebsd-stable@freebsd.org, jfv@freebsd.org Subject: Re: em(4) + ALTQ broken 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, 02 Feb 2010 21:39:07 -0000 Thanks Max, yes, i've done some digging myself and now see how things work, the rubber meets the road in the defines in if_var.h. And what it does is effectively short circuit Kip Macy's multiqueue code in favor of the old method. Right now I can see two possibilities, either the defines are not set in the build, OR there is something wrong in the logic of the short circuit approach in Kip's code. A question might be if ANY driver that is usinig TX Multiqueue has been successfully used with ALTQ? Jack On Tue, Feb 2, 2010 at 12:37 PM, Max Laier wrote: > On Tuesday 02 February 2010 18:48:02 Jack Vogel wrote: > > So apparently this thing needs no special knowledge in the driver, yet > > something in > > the new code breaks it, can someone explain tersely how the altq app > > actually > > "pokes" or "hooks up" to the driver? I am not clear about that and I > > suspect if I was > > this would all be clearer. > > The whole story is in > > man 9 altq > > long story short, as long as you consistently use the IFQ_* macros to > manage > the interface queue, things should just work. if_var.h used to > conditionally > define these macros to avoid ALTQ overhead when the kernel is built without > ALTQ. This has changed a long time ago and should not make any difference > anymore. > > I can't figure out who the OP is, but could you make sure that the includes > that are used to built the kernel are up to date? You are building with > the > buildkernel target and not "the old way", right? Also, if you build just > the > module, the build might pick up the includes from /usr/include instead of > src/sys ... > > > Jack > > > > On Tue, Feb 2, 2010 at 9:37 AM, Pyun YongHyeon wrote: > > > On Tue, Feb 02, 2010 at 09:30:52AM -0800, Nick Rogers wrote: > > > > > I guess the problem comes from multi-queue support. The drbr > > > > > interface is implemented with inline function so em(4)/igb(4) may > > > > > have to define ALTQ to the header. I have not tested the patch(no > > > > > time at this moment) but would you give it try? > > > > > > > > > > I tried the patch and it did not work. > > > > > > You rebuilt kernel, right? Rebuilding kernel module has no effect. > > > > _______________________________________________ > > 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 > " > > > > > > !DSPAM:4b686584144321871135632! > > > From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 21:41:04 2010 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 29EE51065679; Tue, 2 Feb 2010 21:41:04 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id 54BC78FC23; Tue, 2 Feb 2010 21:41:03 +0000 (UTC) Received: by ewy3 with SMTP id 3so570822ewy.13 for ; Tue, 02 Feb 2010 13:41:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=El/JpphnyL/mXWtleXisNwSbpGDRFGkTkDqGyaDumpU=; b=RdbTbDLOJekC35GSlXFROcUbrFdJX8hS0KXtXoi7d1m7YR1oB8xPsvDejN0+qc0/xy QIAorBlu8bTmokg0AdDWqXWd/wzICRH+5AAVC4Zma+rvo2q2MEaIK2H3NjTHtGs1jTr1 W/uBoXF+iQ2Z6G3d+Gy44Ll9rmQnhrfNOH95c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Px8X8zI2Ym00jRCgUWFhMZiFx56zhGxzT4TW61lwxeGVsw/7tV0GIJNtEt6zo8Aoa0 YEtVSOM5z95D39CU2R4ZesgdQ4PwxVfaANlpduD9ZSZa48W7/jOXgMN6+1/H+4kAnCuQ t4uRzdP/6wT/d6hKPRf1OOgDbcpsEndbCCa6E= MIME-Version: 1.0 Received: by 10.216.87.20 with SMTP id x20mr961879wee.158.1265146862110; Tue, 02 Feb 2010 13:41:02 -0800 (PST) In-Reply-To: <2a41acea1002021339i3801fc4bw736fa01188f60290@mail.gmail.com> References: <147432021001310037n1b67f01bx4b4e8781321cea8@mail.gmail.com> <20100202173746.GA5901@michelle.cdnetworks.com> <2a41acea1002020948l6f3d1a08v9f4ccefd1241f566@mail.gmail.com> <201002022137.52064.max@love2party.net> <2a41acea1002021339i3801fc4bw736fa01188f60290@mail.gmail.com> Date: Tue, 2 Feb 2010 13:41:01 -0800 Message-ID: <2a41acea1002021341s62633188g4560960157f5cd1@mail.gmail.com> From: Jack Vogel To: Max Laier Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: pyunyh@gmail.com, Nick Rogers , stable@freebsd.org, freebsd-stable@freebsd.org, jfv@freebsd.org Subject: Re: em(4) + ALTQ broken 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, 02 Feb 2010 21:41:04 -0000 LOL, and I can answer my own question, I just looked and the ONLY 1Gig drivers using multiqueue are mine, so I guess not eh? :) J. On Tue, Feb 2, 2010 at 1:39 PM, Jack Vogel wrote: > Thanks Max, yes, i've done some digging myself and now see how things > work, the rubber meets the road in the defines in if_var.h. > > And what it does is effectively short circuit Kip Macy's multiqueue code > in favor of the old method. > > Right now I can see two possibilities, either the defines are not set in > the build, OR there is something wrong in the logic of the short circuit > approach in Kip's code. > > A question might be if ANY driver that is usinig TX Multiqueue has been > successfully used with ALTQ? > > Jack > > > > On Tue, Feb 2, 2010 at 12:37 PM, Max Laier wrote: > >> On Tuesday 02 February 2010 18:48:02 Jack Vogel wrote: >> > So apparently this thing needs no special knowledge in the driver, yet >> > something in >> > the new code breaks it, can someone explain tersely how the altq app >> > actually >> > "pokes" or "hooks up" to the driver? I am not clear about that and I >> > suspect if I was >> > this would all be clearer. >> >> The whole story is in >> >> man 9 altq >> >> long story short, as long as you consistently use the IFQ_* macros to >> manage >> the interface queue, things should just work. if_var.h used to >> conditionally >> define these macros to avoid ALTQ overhead when the kernel is built >> without >> ALTQ. This has changed a long time ago and should not make any difference >> anymore. >> >> I can't figure out who the OP is, but could you make sure that the >> includes >> that are used to built the kernel are up to date? You are building with >> the >> buildkernel target and not "the old way", right? Also, if you build just >> the >> module, the build might pick up the includes from /usr/include instead of >> src/sys ... >> >> > Jack >> > >> > On Tue, Feb 2, 2010 at 9:37 AM, Pyun YongHyeon >> wrote: >> > > On Tue, Feb 02, 2010 at 09:30:52AM -0800, Nick Rogers wrote: >> > > > > I guess the problem comes from multi-queue support. The drbr >> > > > > interface is implemented with inline function so em(4)/igb(4) may >> > > > > have to define ALTQ to the header. I have not tested the patch(no >> > > > > time at this moment) but would you give it try? >> > > > > >> > > > > I tried the patch and it did not work. >> > > >> > > You rebuilt kernel, right? Rebuilding kernel module has no effect. >> > >> > _______________________________________________ >> > 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" >> > >> > >> > !DSPAM:4b686584144321871135632! >> > >> > > From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 21:41:04 2010 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 29EE51065679; Tue, 2 Feb 2010 21:41:04 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id 54BC78FC23; Tue, 2 Feb 2010 21:41:03 +0000 (UTC) Received: by ewy3 with SMTP id 3so570822ewy.13 for ; Tue, 02 Feb 2010 13:41:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=El/JpphnyL/mXWtleXisNwSbpGDRFGkTkDqGyaDumpU=; b=RdbTbDLOJekC35GSlXFROcUbrFdJX8hS0KXtXoi7d1m7YR1oB8xPsvDejN0+qc0/xy QIAorBlu8bTmokg0AdDWqXWd/wzICRH+5AAVC4Zma+rvo2q2MEaIK2H3NjTHtGs1jTr1 W/uBoXF+iQ2Z6G3d+Gy44Ll9rmQnhrfNOH95c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Px8X8zI2Ym00jRCgUWFhMZiFx56zhGxzT4TW61lwxeGVsw/7tV0GIJNtEt6zo8Aoa0 YEtVSOM5z95D39CU2R4ZesgdQ4PwxVfaANlpduD9ZSZa48W7/jOXgMN6+1/H+4kAnCuQ t4uRzdP/6wT/d6hKPRf1OOgDbcpsEndbCCa6E= MIME-Version: 1.0 Received: by 10.216.87.20 with SMTP id x20mr961879wee.158.1265146862110; Tue, 02 Feb 2010 13:41:02 -0800 (PST) In-Reply-To: <2a41acea1002021339i3801fc4bw736fa01188f60290@mail.gmail.com> References: <147432021001310037n1b67f01bx4b4e8781321cea8@mail.gmail.com> <20100202173746.GA5901@michelle.cdnetworks.com> <2a41acea1002020948l6f3d1a08v9f4ccefd1241f566@mail.gmail.com> <201002022137.52064.max@love2party.net> <2a41acea1002021339i3801fc4bw736fa01188f60290@mail.gmail.com> Date: Tue, 2 Feb 2010 13:41:01 -0800 Message-ID: <2a41acea1002021341s62633188g4560960157f5cd1@mail.gmail.com> From: Jack Vogel To: Max Laier Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: pyunyh@gmail.com, Nick Rogers , stable@freebsd.org, freebsd-stable@freebsd.org, jfv@freebsd.org Subject: Re: em(4) + ALTQ broken 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, 02 Feb 2010 21:41:04 -0000 LOL, and I can answer my own question, I just looked and the ONLY 1Gig drivers using multiqueue are mine, so I guess not eh? :) J. On Tue, Feb 2, 2010 at 1:39 PM, Jack Vogel wrote: > Thanks Max, yes, i've done some digging myself and now see how things > work, the rubber meets the road in the defines in if_var.h. > > And what it does is effectively short circuit Kip Macy's multiqueue code > in favor of the old method. > > Right now I can see two possibilities, either the defines are not set in > the build, OR there is something wrong in the logic of the short circuit > approach in Kip's code. > > A question might be if ANY driver that is usinig TX Multiqueue has been > successfully used with ALTQ? > > Jack > > > > On Tue, Feb 2, 2010 at 12:37 PM, Max Laier wrote: > >> On Tuesday 02 February 2010 18:48:02 Jack Vogel wrote: >> > So apparently this thing needs no special knowledge in the driver, yet >> > something in >> > the new code breaks it, can someone explain tersely how the altq app >> > actually >> > "pokes" or "hooks up" to the driver? I am not clear about that and I >> > suspect if I was >> > this would all be clearer. >> >> The whole story is in >> >> man 9 altq >> >> long story short, as long as you consistently use the IFQ_* macros to >> manage >> the interface queue, things should just work. if_var.h used to >> conditionally >> define these macros to avoid ALTQ overhead when the kernel is built >> without >> ALTQ. This has changed a long time ago and should not make any difference >> anymore. >> >> I can't figure out who the OP is, but could you make sure that the >> includes >> that are used to built the kernel are up to date? You are building with >> the >> buildkernel target and not "the old way", right? Also, if you build just >> the >> module, the build might pick up the includes from /usr/include instead of >> src/sys ... >> >> > Jack >> > >> > On Tue, Feb 2, 2010 at 9:37 AM, Pyun YongHyeon >> wrote: >> > > On Tue, Feb 02, 2010 at 09:30:52AM -0800, Nick Rogers wrote: >> > > > > I guess the problem comes from multi-queue support. The drbr >> > > > > interface is implemented with inline function so em(4)/igb(4) may >> > > > > have to define ALTQ to the header. I have not tested the patch(no >> > > > > time at this moment) but would you give it try? >> > > > > >> > > > > I tried the patch and it did not work. >> > > >> > > You rebuilt kernel, right? Rebuilding kernel module has no effect. >> > >> > _______________________________________________ >> > 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" >> > >> > >> > !DSPAM:4b686584144321871135632! >> > >> > > From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 21:58:14 2010 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 5899F106568B for ; Tue, 2 Feb 2010 21:58:14 +0000 (UTC) (envelope-from vmagerya@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id D820F8FC0C for ; Tue, 2 Feb 2010 21:58:13 +0000 (UTC) Received: by fxm26 with SMTP id 26so576150fxm.13 for ; Tue, 02 Feb 2010 13:58:13 -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 :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=pWDgd2Cipzr4Tz/yjVVpoF9ETWfKUzG2dgfqDv7Y+EQ=; b=Mds7um6hfpJHkkqLC9X62L2yEbTWWvBJZMTDbkGKdtvzcZclzeQJ9K2Q7u1V0SkkG8 4FMzCV3Z0itg3JW6oG3jZF4tjTp/jSJlBXDCkXQx/Cy6HTKLA/1iAd0jiumKlpVovBFy o99sOyb5z16UWZocTV+NZ8YUsYA+DZ/ogLGAE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=j1EToJwWRervdcwR1twSHQZHZczQ03VSSr0yAPntj/s7QIUnwqJvnscJ9nL2p2uKG+ TQ2nfJKHFINNN4ttuRlb5n4iyc0vCK07YhKitfhsR9cwzQ+3mVKEWGikCLxkW5s3Lw+U yYPI34ZX5kOT9B2FSCYvvGB74qzd5GrKjH1E0= Received: by 10.102.235.8 with SMTP id i8mr4214514muh.31.1265147892956; Tue, 02 Feb 2010 13:58:12 -0800 (PST) Received: from ?172.16.0.7? ([85.198.160.156]) by mx.google.com with ESMTPS id t10sm1888150muh.11.2010.02.02.13.58.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 02 Feb 2010 13:58:12 -0800 (PST) Message-ID: <4B689FF3.5080104@gmail.com> Date: Tue, 02 Feb 2010 23:58:11 +0200 From: Vitaly Magerya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Kevin Oberman References: <20100202213148.9A87B1CC3F@ptavv.es.net> In-Reply-To: <20100202213148.9A87B1CC3F@ptavv.es.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 8.0 install fails to create filesystem ("unable to find device node") 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, 02 Feb 2010 21:58:14 -0000 Kevin Oberman wrote: >> The setup tries to create filesystem and fails with this message: >> >> Unable to find device node for /dev/ad0s1b in /dev! > > Are you doing a 'W'rite in the labeling tools? I'm guess that you are > not, but I wanted to be sure. You don't want to. Nope, no write. > You say that you are doing the default partitions. If so, the 'b' > partition should be swap. It should not get 'newfs'ed. No file system > needed (or wanted) there. This tells me that something was wrong in the > partition setup if it THINKS that there is a need to newfs partition > 'b'. Yes, ad0s1b is the swap, but I think it fails before doing newfs. "Writing partition information to ad0" is the last message I see before the error occurs, no newfs popups occur. >> Aside from debug messages, there's this on second VT: >> >> GEOM: ad0: geometry does not match label (255h,63s != 16h,63s). > > This is a known issue, but cosmetic in almost all cases. OK, good. > I suspect that you are doing something wrong, but it's hard to figure > out just what it might be. Anything I can do to see what's the problem? From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 22:09:40 2010 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 8914D106568B for ; Tue, 2 Feb 2010 22:09:40 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id 7132C8FC12 for ; Tue, 2 Feb 2010 22:09:40 +0000 (UTC) Received: from omta01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by qmta05.emeryville.ca.mail.comcast.net with comcast id d4Ey1d0080EPchoA5A9h6W; Tue, 02 Feb 2010 22:09:41 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta01.emeryville.ca.mail.comcast.net with comcast id dA9g1d0033S48mS8MA9gRi; Tue, 02 Feb 2010 22:09:40 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id E96E21E3033; Tue, 2 Feb 2010 14:09:38 -0800 (PST) Date: Tue, 2 Feb 2010 14:09:38 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100202220938.GA81464@icarus.home.lan> References: <20100202213148.9A87B1CC3F@ptavv.es.net> <4B689FF3.5080104@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B689FF3.5080104@gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: 8.0 install fails to create filesystem ("unable to find device node") 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, 02 Feb 2010 22:09:40 -0000 On Tue, Feb 02, 2010 at 11:58:11PM +0200, Vitaly Magerya wrote: > Kevin Oberman wrote: > >> The setup tries to create filesystem and fails with this message: > >> > >> Unable to find device node for /dev/ad0s1b in /dev! > > > > Are you doing a 'W'rite in the labeling tools? I'm guess that you are > > not, but I wanted to be sure. You don't want to. > > Nope, no write. > > > You say that you are doing the default partitions. If so, the 'b' > > partition should be swap. It should not get 'newfs'ed. No file system > > needed (or wanted) there. This tells me that something was wrong in the > > partition setup if it THINKS that there is a need to newfs partition > > 'b'. > > Yes, ad0s1b is the swap, but I think it fails before doing newfs. > "Writing partition information to ad0" is the last message I see before > the error occurs, no newfs popups occur. > > >> Aside from debug messages, there's this on second VT: > >> > >> GEOM: ad0: geometry does not match label (255h,63s != 16h,63s). > > > > This is a known issue, but cosmetic in almost all cases. > > OK, good. > > > I suspect that you are doing something wrong, but it's hard to figure > > out just what it might be. > > Anything I can do to see what's the problem? Can you get this disk into a system (or the same system if booting off CD, etc.) where you can do the following to it and then retry the installation? dd if=/dev/zero of=/dev/ad0 bs=64k count=1 No, this isn't a joke. This should also clear up the GEOM label error/warning you see. -- | Jeremy Chadwick jdc@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 Tue Feb 2 22:39:41 2010 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 D875F1065676; Tue, 2 Feb 2010 22:39:41 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 51C6E8FC16; Tue, 2 Feb 2010 22:39:41 +0000 (UTC) Received: by vws11 with SMTP id 11so347598vws.13 for ; Tue, 02 Feb 2010 14:39:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=TrerZgH/dYJD6aTrG2581dIsJdXHlkP0ezzsSuBhCUw=; b=I02HF/NzzBhvTSIe9hmj9BNvnDV/NgV/9r3cLcxEz4QCYQ0QQEmRVx/Crlmet1HLXB JIT+1K+Oyy2LYbwz5RBbatUN6Hcd/speP6HiXMNwSRYW9j1r7ekJ0DSrF+oAUvi+rX2E 9t6iXUqjdvDphqI7F8LFIa3crhNAzsmEK95EI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=FJhp150EcMil44nLtp6kN/qGHBGIva148I3yL4b852O01k/DVt884smgG2LFB3QXZe WT6hQpiv6XsyaZ0SvdZ3Scpr6X0vMyfiTT3+wGlTPtMkigSUWrJsVE6WhmdHb7gQulvI EU3jz5zJO9YOviPdW0P9SDUIlcdUfz6mfGPtw= Received: by 10.220.125.103 with SMTP id x39mr8732113vcr.70.1265150380538; Tue, 02 Feb 2010 14:39:40 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 36sm73830516vws.15.2010.02.02.14.39.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 02 Feb 2010 14:39:39 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 2 Feb 2010 14:38:18 -0800 From: Pyun YongHyeon Date: Tue, 2 Feb 2010 14:38:18 -0800 To: Jack Vogel Message-ID: <20100202223818.GD5901@michelle.cdnetworks.com> References: <147432021001310037n1b67f01bx4b4e8781321cea8@mail.gmail.com> <20100202173746.GA5901@michelle.cdnetworks.com> <2a41acea1002020948l6f3d1a08v9f4ccefd1241f566@mail.gmail.com> <201002022137.52064.max@love2party.net> <2a41acea1002021339i3801fc4bw736fa01188f60290@mail.gmail.com> <2a41acea1002021341s62633188g4560960157f5cd1@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2a41acea1002021341s62633188g4560960157f5cd1@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: Nick Rogers , Max Laier , stable@freebsd.org, freebsd-stable@freebsd.org, jfv@freebsd.org Subject: Re: em(4) + ALTQ broken X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 22:39:41 -0000 On Tue, Feb 02, 2010 at 01:41:01PM -0800, Jack Vogel wrote: > LOL, and I can answer my own question, I just looked and the ONLY > 1Gig drivers using multiqueue are mine, so I guess not eh? :) > I was wrong. ALTQ is defined in opt_global.h so drbr_ interface should already see ALTQ. I have to look into drbr_ code. > J. > > On Tue, Feb 2, 2010 at 1:39 PM, Jack Vogel wrote: > > > Thanks Max, yes, i've done some digging myself and now see how things > > work, the rubber meets the road in the defines in if_var.h. > > > > And what it does is effectively short circuit Kip Macy's multiqueue code > > in favor of the old method. > > > > Right now I can see two possibilities, either the defines are not set in > > the build, OR there is something wrong in the logic of the short circuit > > approach in Kip's code. > > > > A question might be if ANY driver that is usinig TX Multiqueue has been > > successfully used with ALTQ? > > > > Jack > > > > > > > > On Tue, Feb 2, 2010 at 12:37 PM, Max Laier wrote: > > > >> On Tuesday 02 February 2010 18:48:02 Jack Vogel wrote: > >> > So apparently this thing needs no special knowledge in the driver, yet > >> > something in > >> > the new code breaks it, can someone explain tersely how the altq app > >> > actually > >> > "pokes" or "hooks up" to the driver? I am not clear about that and I > >> > suspect if I was > >> > this would all be clearer. > >> > >> The whole story is in > >> > >> man 9 altq > >> > >> long story short, as long as you consistently use the IFQ_* macros to > >> manage > >> the interface queue, things should just work. if_var.h used to > >> conditionally > >> define these macros to avoid ALTQ overhead when the kernel is built > >> without > >> ALTQ. This has changed a long time ago and should not make any difference > >> anymore. > >> > >> I can't figure out who the OP is, but could you make sure that the > >> includes > >> that are used to built the kernel are up to date? You are building with > >> the > >> buildkernel target and not "the old way", right? Also, if you build just > >> the > >> module, the build might pick up the includes from /usr/include instead of > >> src/sys ... > >> > >> > Jack > >> > > >> > On Tue, Feb 2, 2010 at 9:37 AM, Pyun YongHyeon > >> wrote: > >> > > On Tue, Feb 02, 2010 at 09:30:52AM -0800, Nick Rogers wrote: > >> > > > > I guess the problem comes from multi-queue support. The drbr > >> > > > > interface is implemented with inline function so em(4)/igb(4) may > >> > > > > have to define ALTQ to the header. I have not tested the patch(no > >> > > > > time at this moment) but would you give it try? > >> > > > > > >> > > > > I tried the patch and it did not work. > >> > > > >> > > You rebuilt kernel, right? Rebuilding kernel module has no effect. > >> > > >> > _______________________________________________ > >> > 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" > >> > > >> > > >> > !DSPAM:4b686584144321871135632! > >> > > >> > > > > From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 22:39:41 2010 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 D875F1065676; Tue, 2 Feb 2010 22:39:41 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 51C6E8FC16; Tue, 2 Feb 2010 22:39:41 +0000 (UTC) Received: by vws11 with SMTP id 11so347598vws.13 for ; Tue, 02 Feb 2010 14:39:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=TrerZgH/dYJD6aTrG2581dIsJdXHlkP0ezzsSuBhCUw=; b=I02HF/NzzBhvTSIe9hmj9BNvnDV/NgV/9r3cLcxEz4QCYQ0QQEmRVx/Crlmet1HLXB JIT+1K+Oyy2LYbwz5RBbatUN6Hcd/speP6HiXMNwSRYW9j1r7ekJ0DSrF+oAUvi+rX2E 9t6iXUqjdvDphqI7F8LFIa3crhNAzsmEK95EI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=FJhp150EcMil44nLtp6kN/qGHBGIva148I3yL4b852O01k/DVt884smgG2LFB3QXZe WT6hQpiv6XsyaZ0SvdZ3Scpr6X0vMyfiTT3+wGlTPtMkigSUWrJsVE6WhmdHb7gQulvI EU3jz5zJO9YOviPdW0P9SDUIlcdUfz6mfGPtw= Received: by 10.220.125.103 with SMTP id x39mr8732113vcr.70.1265150380538; Tue, 02 Feb 2010 14:39:40 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 36sm73830516vws.15.2010.02.02.14.39.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 02 Feb 2010 14:39:39 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 2 Feb 2010 14:38:18 -0800 From: Pyun YongHyeon Date: Tue, 2 Feb 2010 14:38:18 -0800 To: Jack Vogel Message-ID: <20100202223818.GD5901@michelle.cdnetworks.com> References: <147432021001310037n1b67f01bx4b4e8781321cea8@mail.gmail.com> <20100202173746.GA5901@michelle.cdnetworks.com> <2a41acea1002020948l6f3d1a08v9f4ccefd1241f566@mail.gmail.com> <201002022137.52064.max@love2party.net> <2a41acea1002021339i3801fc4bw736fa01188f60290@mail.gmail.com> <2a41acea1002021341s62633188g4560960157f5cd1@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2a41acea1002021341s62633188g4560960157f5cd1@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: Nick Rogers , Max Laier , stable@freebsd.org, freebsd-stable@freebsd.org, jfv@freebsd.org Subject: Re: em(4) + ALTQ broken X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 22:39:41 -0000 On Tue, Feb 02, 2010 at 01:41:01PM -0800, Jack Vogel wrote: > LOL, and I can answer my own question, I just looked and the ONLY > 1Gig drivers using multiqueue are mine, so I guess not eh? :) > I was wrong. ALTQ is defined in opt_global.h so drbr_ interface should already see ALTQ. I have to look into drbr_ code. > J. > > On Tue, Feb 2, 2010 at 1:39 PM, Jack Vogel wrote: > > > Thanks Max, yes, i've done some digging myself and now see how things > > work, the rubber meets the road in the defines in if_var.h. > > > > And what it does is effectively short circuit Kip Macy's multiqueue code > > in favor of the old method. > > > > Right now I can see two possibilities, either the defines are not set in > > the build, OR there is something wrong in the logic of the short circuit > > approach in Kip's code. > > > > A question might be if ANY driver that is usinig TX Multiqueue has been > > successfully used with ALTQ? > > > > Jack > > > > > > > > On Tue, Feb 2, 2010 at 12:37 PM, Max Laier wrote: > > > >> On Tuesday 02 February 2010 18:48:02 Jack Vogel wrote: > >> > So apparently this thing needs no special knowledge in the driver, yet > >> > something in > >> > the new code breaks it, can someone explain tersely how the altq app > >> > actually > >> > "pokes" or "hooks up" to the driver? I am not clear about that and I > >> > suspect if I was > >> > this would all be clearer. > >> > >> The whole story is in > >> > >> man 9 altq > >> > >> long story short, as long as you consistently use the IFQ_* macros to > >> manage > >> the interface queue, things should just work. if_var.h used to > >> conditionally > >> define these macros to avoid ALTQ overhead when the kernel is built > >> without > >> ALTQ. This has changed a long time ago and should not make any difference > >> anymore. > >> > >> I can't figure out who the OP is, but could you make sure that the > >> includes > >> that are used to built the kernel are up to date? You are building with > >> the > >> buildkernel target and not "the old way", right? Also, if you build just > >> the > >> module, the build might pick up the includes from /usr/include instead of > >> src/sys ... > >> > >> > Jack > >> > > >> > On Tue, Feb 2, 2010 at 9:37 AM, Pyun YongHyeon > >> wrote: > >> > > On Tue, Feb 02, 2010 at 09:30:52AM -0800, Nick Rogers wrote: > >> > > > > I guess the problem comes from multi-queue support. The drbr > >> > > > > interface is implemented with inline function so em(4)/igb(4) may > >> > > > > have to define ALTQ to the header. I have not tested the patch(no > >> > > > > time at this moment) but would you give it try? > >> > > > > > >> > > > > I tried the patch and it did not work. > >> > > > >> > > You rebuilt kernel, right? Rebuilding kernel module has no effect. > >> > > >> > _______________________________________________ > >> > 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" > >> > > >> > > >> > !DSPAM:4b686584144321871135632! > >> > > >> > > > > From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 22:43:30 2010 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 7BF641065696; Tue, 2 Feb 2010 22:43:30 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by mx1.freebsd.org (Postfix) with ESMTP id AFA8C8FC2D; Tue, 2 Feb 2010 22:43:29 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 22so141826eye.9 for ; Tue, 02 Feb 2010 14:43:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=tep+tb2xuUYBHIQRT8cKB35cx3m5V2++75rscdBiIwc=; b=gj29tptgrfIYBa1CEg6DWFJdSGU++/UVFE8n2Tum9Kvawgr+57/OF5l6w1T0Y9VBns To/jpKPnCQl3F7QkPzoO1UrwgHlvYBpBmXfWi5psgrnsJJIYAHavsg41JsSPieGSz8g1 OKYp3seUWhD8h0VqCW/W5I+JV+Ui2gsscazMk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=G8Nf3kAIMZeeEp6hU0KiTzxJRz7IdBfZb97TrXiLVD4M3sTBnAdJZiIUCDoiywbN4m OPkzU90DzA+BgzVj8Eb4qWAaw9UzmfkpT5QaSwzdCUzpG2X5+TvOI1a2VU5/s7kQF3Ow ggpz8xDIm+GcuSRSHX0Bdajxvxf6nek4HqDs8= MIME-Version: 1.0 Received: by 10.216.89.11 with SMTP id b11mr3551777wef.171.1265150608654; Tue, 02 Feb 2010 14:43:28 -0800 (PST) In-Reply-To: <20100202223818.GD5901@michelle.cdnetworks.com> References: <147432021001310037n1b67f01bx4b4e8781321cea8@mail.gmail.com> <20100202173746.GA5901@michelle.cdnetworks.com> <2a41acea1002020948l6f3d1a08v9f4ccefd1241f566@mail.gmail.com> <201002022137.52064.max@love2party.net> <2a41acea1002021339i3801fc4bw736fa01188f60290@mail.gmail.com> <2a41acea1002021341s62633188g4560960157f5cd1@mail.gmail.com> <20100202223818.GD5901@michelle.cdnetworks.com> Date: Tue, 2 Feb 2010 14:43:28 -0800 Message-ID: <2a41acea1002021443t1c298528i2df3cf40269c733@mail.gmail.com> From: Jack Vogel To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Nick Rogers , Max Laier , stable@freebsd.org, freebsd-stable@freebsd.org, jfv@freebsd.org Subject: Re: em(4) + ALTQ broken 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, 02 Feb 2010 22:43:30 -0000 It should never get to the drbr code, look at net/if_var.h, in the inline definition of drbr_dequeue() there is an #ifdef ALTQ that will effectively vector if to use the old IFQ_DRV_DEQUEUE() method. I guess I can test the build on a system here, stick some syntax error in and see if it hits. Right now the inserted code looks solid enough to me, so somehow I think its not being defined. Jack On Tue, Feb 2, 2010 at 2:38 PM, Pyun YongHyeon wrote: > On Tue, Feb 02, 2010 at 01:41:01PM -0800, Jack Vogel wrote: > > LOL, and I can answer my own question, I just looked and the ONLY > > 1Gig drivers using multiqueue are mine, so I guess not eh? :) > > > > I was wrong. ALTQ is defined in opt_global.h so drbr_ interface > should already see ALTQ. I have to look into drbr_ code. > > > J. > > > > On Tue, Feb 2, 2010 at 1:39 PM, Jack Vogel wrote: > > > > > Thanks Max, yes, i've done some digging myself and now see how things > > > work, the rubber meets the road in the defines in if_var.h. > > > > > > And what it does is effectively short circuit Kip Macy's multiqueue > code > > > in favor of the old method. > > > > > > Right now I can see two possibilities, either the defines are not set > in > > > the build, OR there is something wrong in the logic of the short > circuit > > > approach in Kip's code. > > > > > > A question might be if ANY driver that is usinig TX Multiqueue has been > > > successfully used with ALTQ? > > > > > > Jack > > > > > > > > > > > > On Tue, Feb 2, 2010 at 12:37 PM, Max Laier wrote: > > > > > >> On Tuesday 02 February 2010 18:48:02 Jack Vogel wrote: > > >> > So apparently this thing needs no special knowledge in the driver, > yet > > >> > something in > > >> > the new code breaks it, can someone explain tersely how the altq app > > >> > actually > > >> > "pokes" or "hooks up" to the driver? I am not clear about that and I > > >> > suspect if I was > > >> > this would all be clearer. > > >> > > >> The whole story is in > > >> > > >> man 9 altq > > >> > > >> long story short, as long as you consistently use the IFQ_* macros to > > >> manage > > >> the interface queue, things should just work. if_var.h used to > > >> conditionally > > >> define these macros to avoid ALTQ overhead when the kernel is built > > >> without > > >> ALTQ. This has changed a long time ago and should not make any > difference > > >> anymore. > > >> > > >> I can't figure out who the OP is, but could you make sure that the > > >> includes > > >> that are used to built the kernel are up to date? You are building > with > > >> the > > >> buildkernel target and not "the old way", right? Also, if you build > just > > >> the > > >> module, the build might pick up the includes from /usr/include instead > of > > >> src/sys ... > > >> > > >> > Jack > > >> > > > >> > On Tue, Feb 2, 2010 at 9:37 AM, Pyun YongHyeon > > >> wrote: > > >> > > On Tue, Feb 02, 2010 at 09:30:52AM -0800, Nick Rogers wrote: > > >> > > > > I guess the problem comes from multi-queue support. The drbr > > >> > > > > interface is implemented with inline function so em(4)/igb(4) > may > > >> > > > > have to define ALTQ to the header. I have not tested the > patch(no > > >> > > > > time at this moment) but would you give it try? > > >> > > > > > > >> > > > > I tried the patch and it did not work. > > >> > > > > >> > > You rebuilt kernel, right? Rebuilding kernel module has no effect. > > >> > > > >> > _______________________________________________ > > >> > 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" > > >> > > > >> > > > >> > !DSPAM:4b686584144321871135632! > > >> > > > >> > > > > > > > From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 22:43:30 2010 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 7BF641065696; Tue, 2 Feb 2010 22:43:30 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by mx1.freebsd.org (Postfix) with ESMTP id AFA8C8FC2D; Tue, 2 Feb 2010 22:43:29 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 22so141826eye.9 for ; Tue, 02 Feb 2010 14:43:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=tep+tb2xuUYBHIQRT8cKB35cx3m5V2++75rscdBiIwc=; b=gj29tptgrfIYBa1CEg6DWFJdSGU++/UVFE8n2Tum9Kvawgr+57/OF5l6w1T0Y9VBns To/jpKPnCQl3F7QkPzoO1UrwgHlvYBpBmXfWi5psgrnsJJIYAHavsg41JsSPieGSz8g1 OKYp3seUWhD8h0VqCW/W5I+JV+Ui2gsscazMk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=G8Nf3kAIMZeeEp6hU0KiTzxJRz7IdBfZb97TrXiLVD4M3sTBnAdJZiIUCDoiywbN4m OPkzU90DzA+BgzVj8Eb4qWAaw9UzmfkpT5QaSwzdCUzpG2X5+TvOI1a2VU5/s7kQF3Ow ggpz8xDIm+GcuSRSHX0Bdajxvxf6nek4HqDs8= MIME-Version: 1.0 Received: by 10.216.89.11 with SMTP id b11mr3551777wef.171.1265150608654; Tue, 02 Feb 2010 14:43:28 -0800 (PST) In-Reply-To: <20100202223818.GD5901@michelle.cdnetworks.com> References: <147432021001310037n1b67f01bx4b4e8781321cea8@mail.gmail.com> <20100202173746.GA5901@michelle.cdnetworks.com> <2a41acea1002020948l6f3d1a08v9f4ccefd1241f566@mail.gmail.com> <201002022137.52064.max@love2party.net> <2a41acea1002021339i3801fc4bw736fa01188f60290@mail.gmail.com> <2a41acea1002021341s62633188g4560960157f5cd1@mail.gmail.com> <20100202223818.GD5901@michelle.cdnetworks.com> Date: Tue, 2 Feb 2010 14:43:28 -0800 Message-ID: <2a41acea1002021443t1c298528i2df3cf40269c733@mail.gmail.com> From: Jack Vogel To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Nick Rogers , Max Laier , stable@freebsd.org, freebsd-stable@freebsd.org, jfv@freebsd.org Subject: Re: em(4) + ALTQ broken 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, 02 Feb 2010 22:43:30 -0000 It should never get to the drbr code, look at net/if_var.h, in the inline definition of drbr_dequeue() there is an #ifdef ALTQ that will effectively vector if to use the old IFQ_DRV_DEQUEUE() method. I guess I can test the build on a system here, stick some syntax error in and see if it hits. Right now the inserted code looks solid enough to me, so somehow I think its not being defined. Jack On Tue, Feb 2, 2010 at 2:38 PM, Pyun YongHyeon wrote: > On Tue, Feb 02, 2010 at 01:41:01PM -0800, Jack Vogel wrote: > > LOL, and I can answer my own question, I just looked and the ONLY > > 1Gig drivers using multiqueue are mine, so I guess not eh? :) > > > > I was wrong. ALTQ is defined in opt_global.h so drbr_ interface > should already see ALTQ. I have to look into drbr_ code. > > > J. > > > > On Tue, Feb 2, 2010 at 1:39 PM, Jack Vogel wrote: > > > > > Thanks Max, yes, i've done some digging myself and now see how things > > > work, the rubber meets the road in the defines in if_var.h. > > > > > > And what it does is effectively short circuit Kip Macy's multiqueue > code > > > in favor of the old method. > > > > > > Right now I can see two possibilities, either the defines are not set > in > > > the build, OR there is something wrong in the logic of the short > circuit > > > approach in Kip's code. > > > > > > A question might be if ANY driver that is usinig TX Multiqueue has been > > > successfully used with ALTQ? > > > > > > Jack > > > > > > > > > > > > On Tue, Feb 2, 2010 at 12:37 PM, Max Laier wrote: > > > > > >> On Tuesday 02 February 2010 18:48:02 Jack Vogel wrote: > > >> > So apparently this thing needs no special knowledge in the driver, > yet > > >> > something in > > >> > the new code breaks it, can someone explain tersely how the altq app > > >> > actually > > >> > "pokes" or "hooks up" to the driver? I am not clear about that and I > > >> > suspect if I was > > >> > this would all be clearer. > > >> > > >> The whole story is in > > >> > > >> man 9 altq > > >> > > >> long story short, as long as you consistently use the IFQ_* macros to > > >> manage > > >> the interface queue, things should just work. if_var.h used to > > >> conditionally > > >> define these macros to avoid ALTQ overhead when the kernel is built > > >> without > > >> ALTQ. This has changed a long time ago and should not make any > difference > > >> anymore. > > >> > > >> I can't figure out who the OP is, but could you make sure that the > > >> includes > > >> that are used to built the kernel are up to date? You are building > with > > >> the > > >> buildkernel target and not "the old way", right? Also, if you build > just > > >> the > > >> module, the build might pick up the includes from /usr/include instead > of > > >> src/sys ... > > >> > > >> > Jack > > >> > > > >> > On Tue, Feb 2, 2010 at 9:37 AM, Pyun YongHyeon > > >> wrote: > > >> > > On Tue, Feb 02, 2010 at 09:30:52AM -0800, Nick Rogers wrote: > > >> > > > > I guess the problem comes from multi-queue support. The drbr > > >> > > > > interface is implemented with inline function so em(4)/igb(4) > may > > >> > > > > have to define ALTQ to the header. I have not tested the > patch(no > > >> > > > > time at this moment) but would you give it try? > > >> > > > > > > >> > > > > I tried the patch and it did not work. > > >> > > > > >> > > You rebuilt kernel, right? Rebuilding kernel module has no effect. > > >> > > > >> > _______________________________________________ > > >> > 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" > > >> > > > >> > > > >> > !DSPAM:4b686584144321871135632! > > >> > > > >> > > > > > > > From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 22:47:59 2010 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 03E2810656A7; Tue, 2 Feb 2010 22:47:59 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id 32EC08FC16; Tue, 2 Feb 2010 22:47:57 +0000 (UTC) Received: by ewy3 with SMTP id 3so639304ewy.13 for ; Tue, 02 Feb 2010 14:47:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=tBZ58xxdusvVk2N/KcDzlxd18jebd1noTJgMzFs8M2Y=; b=c95wpIcnOWj27RPHgp7Ekg+VY8O7T1idrBI/psYSB/XujmgVJs1VSCjngjQckpUWOq 11XTuffPTr+xZZnsP498KVOGphS+hPLKXldEjlep6Wc9ZbwnETB2JaEGSVcWsCi4/guZ 4qYxUYgq1dgObryx8MGkuaHHDE26O5MTTtFQc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=KTzyTNWl00RyhOU3hBMXmcIEBulnOPPE92CJ2d+bfqONajQWlzTSPTqVayvG7qVgEk rUGMI4aRoSriWwxCzuZZHTigMhUtgBk/vEpMflDz3diKwDKmgvRLrD99Fj5JMNRCOYa0 Y+iE5HEYKeZvy6GO2bCScn82gjvb/vkoNnP9w= MIME-Version: 1.0 Received: by 10.216.154.70 with SMTP id g48mr1009008wek.109.1265150877083; Tue, 02 Feb 2010 14:47:57 -0800 (PST) In-Reply-To: <2a41acea1002021443t1c298528i2df3cf40269c733@mail.gmail.com> References: <147432021001310037n1b67f01bx4b4e8781321cea8@mail.gmail.com> <20100202173746.GA5901@michelle.cdnetworks.com> <2a41acea1002020948l6f3d1a08v9f4ccefd1241f566@mail.gmail.com> <201002022137.52064.max@love2party.net> <2a41acea1002021339i3801fc4bw736fa01188f60290@mail.gmail.com> <2a41acea1002021341s62633188g4560960157f5cd1@mail.gmail.com> <20100202223818.GD5901@michelle.cdnetworks.com> <2a41acea1002021443t1c298528i2df3cf40269c733@mail.gmail.com> Date: Tue, 2 Feb 2010 14:47:56 -0800 Message-ID: <2a41acea1002021447t1067ee42gc59b25216270459b@mail.gmail.com> From: Jack Vogel To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Nick Rogers , Max Laier , stable@freebsd.org, freebsd-stable@freebsd.org, jfv@freebsd.org Subject: Re: em(4) + ALTQ broken 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, 02 Feb 2010 22:47:59 -0000 Just teseted, and at least in the kernel build I'm doing its definitely defining that code on, hit my syntax error rebuilding em. Jack On Tue, Feb 2, 2010 at 2:43 PM, Jack Vogel wrote: > It should never get to the drbr code, look at net/if_var.h, in the inline > definition > of drbr_dequeue() there is an #ifdef ALTQ that will effectively vector if > to use > the old IFQ_DRV_DEQUEUE() method. > > I guess I can test the build on a system here, stick some syntax error in > and see if it hits. > > Right now the inserted code looks solid enough to me, so somehow I think > its not being defined. > > Jack > > > > On Tue, Feb 2, 2010 at 2:38 PM, Pyun YongHyeon wrote: > >> On Tue, Feb 02, 2010 at 01:41:01PM -0800, Jack Vogel wrote: >> > LOL, and I can answer my own question, I just looked and the ONLY >> > 1Gig drivers using multiqueue are mine, so I guess not eh? :) >> > >> >> I was wrong. ALTQ is defined in opt_global.h so drbr_ interface >> should already see ALTQ. I have to look into drbr_ code. >> >> > J. >> > >> > On Tue, Feb 2, 2010 at 1:39 PM, Jack Vogel wrote: >> > >> > > Thanks Max, yes, i've done some digging myself and now see how things >> > > work, the rubber meets the road in the defines in if_var.h. >> > > >> > > And what it does is effectively short circuit Kip Macy's multiqueue >> code >> > > in favor of the old method. >> > > >> > > Right now I can see two possibilities, either the defines are not set >> in >> > > the build, OR there is something wrong in the logic of the short >> circuit >> > > approach in Kip's code. >> > > >> > > A question might be if ANY driver that is usinig TX Multiqueue has >> been >> > > successfully used with ALTQ? >> > > >> > > Jack >> > > >> > > >> > > >> > > On Tue, Feb 2, 2010 at 12:37 PM, Max Laier >> wrote: >> > > >> > >> On Tuesday 02 February 2010 18:48:02 Jack Vogel wrote: >> > >> > So apparently this thing needs no special knowledge in the driver, >> yet >> > >> > something in >> > >> > the new code breaks it, can someone explain tersely how the altq >> app >> > >> > actually >> > >> > "pokes" or "hooks up" to the driver? I am not clear about that and >> I >> > >> > suspect if I was >> > >> > this would all be clearer. >> > >> >> > >> The whole story is in >> > >> >> > >> man 9 altq >> > >> >> > >> long story short, as long as you consistently use the IFQ_* macros to >> > >> manage >> > >> the interface queue, things should just work. if_var.h used to >> > >> conditionally >> > >> define these macros to avoid ALTQ overhead when the kernel is built >> > >> without >> > >> ALTQ. This has changed a long time ago and should not make any >> difference >> > >> anymore. >> > >> >> > >> I can't figure out who the OP is, but could you make sure that the >> > >> includes >> > >> that are used to built the kernel are up to date? You are building >> with >> > >> the >> > >> buildkernel target and not "the old way", right? Also, if you build >> just >> > >> the >> > >> module, the build might pick up the includes from /usr/include >> instead of >> > >> src/sys ... >> > >> >> > >> > Jack >> > >> > >> > >> > On Tue, Feb 2, 2010 at 9:37 AM, Pyun YongHyeon >> > >> wrote: >> > >> > > On Tue, Feb 02, 2010 at 09:30:52AM -0800, Nick Rogers wrote: >> > >> > > > > I guess the problem comes from multi-queue support. The drbr >> > >> > > > > interface is implemented with inline function so em(4)/igb(4) >> may >> > >> > > > > have to define ALTQ to the header. I have not tested the >> patch(no >> > >> > > > > time at this moment) but would you give it try? >> > >> > > > > >> > >> > > > > I tried the patch and it did not work. >> > >> > > >> > >> > > You rebuilt kernel, right? Rebuilding kernel module has no >> effect. >> > >> > >> > >> > _______________________________________________ >> > >> > 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" >> > >> > >> > >> > >> > >> > !DSPAM:4b686584144321871135632! >> > >> > >> > >> >> > > >> > > >> > > From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 22:47:59 2010 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 03E2810656A7; Tue, 2 Feb 2010 22:47:59 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id 32EC08FC16; Tue, 2 Feb 2010 22:47:57 +0000 (UTC) Received: by ewy3 with SMTP id 3so639304ewy.13 for ; Tue, 02 Feb 2010 14:47:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=tBZ58xxdusvVk2N/KcDzlxd18jebd1noTJgMzFs8M2Y=; b=c95wpIcnOWj27RPHgp7Ekg+VY8O7T1idrBI/psYSB/XujmgVJs1VSCjngjQckpUWOq 11XTuffPTr+xZZnsP498KVOGphS+hPLKXldEjlep6Wc9ZbwnETB2JaEGSVcWsCi4/guZ 4qYxUYgq1dgObryx8MGkuaHHDE26O5MTTtFQc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=KTzyTNWl00RyhOU3hBMXmcIEBulnOPPE92CJ2d+bfqONajQWlzTSPTqVayvG7qVgEk rUGMI4aRoSriWwxCzuZZHTigMhUtgBk/vEpMflDz3diKwDKmgvRLrD99Fj5JMNRCOYa0 Y+iE5HEYKeZvy6GO2bCScn82gjvb/vkoNnP9w= MIME-Version: 1.0 Received: by 10.216.154.70 with SMTP id g48mr1009008wek.109.1265150877083; Tue, 02 Feb 2010 14:47:57 -0800 (PST) In-Reply-To: <2a41acea1002021443t1c298528i2df3cf40269c733@mail.gmail.com> References: <147432021001310037n1b67f01bx4b4e8781321cea8@mail.gmail.com> <20100202173746.GA5901@michelle.cdnetworks.com> <2a41acea1002020948l6f3d1a08v9f4ccefd1241f566@mail.gmail.com> <201002022137.52064.max@love2party.net> <2a41acea1002021339i3801fc4bw736fa01188f60290@mail.gmail.com> <2a41acea1002021341s62633188g4560960157f5cd1@mail.gmail.com> <20100202223818.GD5901@michelle.cdnetworks.com> <2a41acea1002021443t1c298528i2df3cf40269c733@mail.gmail.com> Date: Tue, 2 Feb 2010 14:47:56 -0800 Message-ID: <2a41acea1002021447t1067ee42gc59b25216270459b@mail.gmail.com> From: Jack Vogel To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Nick Rogers , Max Laier , stable@freebsd.org, freebsd-stable@freebsd.org, jfv@freebsd.org Subject: Re: em(4) + ALTQ broken 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, 02 Feb 2010 22:47:59 -0000 Just teseted, and at least in the kernel build I'm doing its definitely defining that code on, hit my syntax error rebuilding em. Jack On Tue, Feb 2, 2010 at 2:43 PM, Jack Vogel wrote: > It should never get to the drbr code, look at net/if_var.h, in the inline > definition > of drbr_dequeue() there is an #ifdef ALTQ that will effectively vector if > to use > the old IFQ_DRV_DEQUEUE() method. > > I guess I can test the build on a system here, stick some syntax error in > and see if it hits. > > Right now the inserted code looks solid enough to me, so somehow I think > its not being defined. > > Jack > > > > On Tue, Feb 2, 2010 at 2:38 PM, Pyun YongHyeon wrote: > >> On Tue, Feb 02, 2010 at 01:41:01PM -0800, Jack Vogel wrote: >> > LOL, and I can answer my own question, I just looked and the ONLY >> > 1Gig drivers using multiqueue are mine, so I guess not eh? :) >> > >> >> I was wrong. ALTQ is defined in opt_global.h so drbr_ interface >> should already see ALTQ. I have to look into drbr_ code. >> >> > J. >> > >> > On Tue, Feb 2, 2010 at 1:39 PM, Jack Vogel wrote: >> > >> > > Thanks Max, yes, i've done some digging myself and now see how things >> > > work, the rubber meets the road in the defines in if_var.h. >> > > >> > > And what it does is effectively short circuit Kip Macy's multiqueue >> code >> > > in favor of the old method. >> > > >> > > Right now I can see two possibilities, either the defines are not set >> in >> > > the build, OR there is something wrong in the logic of the short >> circuit >> > > approach in Kip's code. >> > > >> > > A question might be if ANY driver that is usinig TX Multiqueue has >> been >> > > successfully used with ALTQ? >> > > >> > > Jack >> > > >> > > >> > > >> > > On Tue, Feb 2, 2010 at 12:37 PM, Max Laier >> wrote: >> > > >> > >> On Tuesday 02 February 2010 18:48:02 Jack Vogel wrote: >> > >> > So apparently this thing needs no special knowledge in the driver, >> yet >> > >> > something in >> > >> > the new code breaks it, can someone explain tersely how the altq >> app >> > >> > actually >> > >> > "pokes" or "hooks up" to the driver? I am not clear about that and >> I >> > >> > suspect if I was >> > >> > this would all be clearer. >> > >> >> > >> The whole story is in >> > >> >> > >> man 9 altq >> > >> >> > >> long story short, as long as you consistently use the IFQ_* macros to >> > >> manage >> > >> the interface queue, things should just work. if_var.h used to >> > >> conditionally >> > >> define these macros to avoid ALTQ overhead when the kernel is built >> > >> without >> > >> ALTQ. This has changed a long time ago and should not make any >> difference >> > >> anymore. >> > >> >> > >> I can't figure out who the OP is, but could you make sure that the >> > >> includes >> > >> that are used to built the kernel are up to date? You are building >> with >> > >> the >> > >> buildkernel target and not "the old way", right? Also, if you build >> just >> > >> the >> > >> module, the build might pick up the includes from /usr/include >> instead of >> > >> src/sys ... >> > >> >> > >> > Jack >> > >> > >> > >> > On Tue, Feb 2, 2010 at 9:37 AM, Pyun YongHyeon >> > >> wrote: >> > >> > > On Tue, Feb 02, 2010 at 09:30:52AM -0800, Nick Rogers wrote: >> > >> > > > > I guess the problem comes from multi-queue support. The drbr >> > >> > > > > interface is implemented with inline function so em(4)/igb(4) >> may >> > >> > > > > have to define ALTQ to the header. I have not tested the >> patch(no >> > >> > > > > time at this moment) but would you give it try? >> > >> > > > > >> > >> > > > > I tried the patch and it did not work. >> > >> > > >> > >> > > You rebuilt kernel, right? Rebuilding kernel module has no >> effect. >> > >> > >> > >> > _______________________________________________ >> > >> > 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" >> > >> > >> > >> > >> > >> > !DSPAM:4b686584144321871135632! >> > >> > >> > >> >> > > >> > > >> > > From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 22:55:57 2010 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 187661065676 for ; Tue, 2 Feb 2010 22:55:57 +0000 (UTC) (envelope-from vmagerya@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id 9BDE88FC0C for ; Tue, 2 Feb 2010 22:55:56 +0000 (UTC) Received: by fxm26 with SMTP id 26so629085fxm.13 for ; Tue, 02 Feb 2010 14:55:55 -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 :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=bj3ZX6IA5Bv4fKidBflPmlqPz1Ctur1BOnNka4sE9RU=; b=VLIhaGYHImNxR627lYz9WNH84jcJMuCCs8MiC+nqG/EnLeuSA2lBHRJbCynxaJrX0L 91G53lMTCI1GUnFj883TNFbtSLurjIQFaUWlMo0CUSTDbe7vKrSwZoT3DLw1u8l2amqB QUkixNtv0brxS/bMcuDrjdNgrEehRFnsvK+lw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=wkp01bGgqVWB+QS4yI/idwQBVXAxZythfIr1PVjHPUR76IpcWxJW/tQDr0qNOuUgQ2 8qXeRXeXSM2cu6OTcWGVkf0QS8nq+wrpHnY9eaYi80c/LCPLiarhZGLbS0ahBlOmBv85 wNfcgLyuMeQXyocJXTk4EPIy2kbm72XPc0hDs= Received: by 10.103.125.37 with SMTP id c37mr4455705mun.3.1265151355539; Tue, 02 Feb 2010 14:55:55 -0800 (PST) Received: from ?172.16.0.7? ([85.198.160.156]) by mx.google.com with ESMTPS id s10sm2392320muh.59.2010.02.02.14.55.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 02 Feb 2010 14:55:54 -0800 (PST) Message-ID: <4B68AD7A.1070407@gmail.com> Date: Wed, 03 Feb 2010 00:55:54 +0200 From: Vitaly Magerya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20100202213148.9A87B1CC3F@ptavv.es.net> <4B689FF3.5080104@gmail.com> <20100202220938.GA81464@icarus.home.lan> In-Reply-To: <20100202220938.GA81464@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: 8.0 install fails to create filesystem ("unable to find device node") 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, 02 Feb 2010 22:55:57 -0000 Jeremy Chadwick wrote: >> Yes, ad0s1b is the swap, but I think it fails before doing newfs. >> "Writing partition information to ad0" is the last message I see before >> the error occurs, no newfs popups occur. By the way, in the fixit console /dev has ad0b but not ad0s1b. > Can you get this disk into a system (or the same system if booting off > CD, etc.) where you can do the following to it and then retry the > installation? > > dd if=/dev/zero of=/dev/ad0 bs=64k count=1 > > No, this isn't a joke. This should also clear up the GEOM label > error/warning you see. Yay, that did the trick. I installed 8.0 into a usb flash and cleaned ad0 from there. The setup successfully created the filesystems and is copying files right now. Thank you! I hope that sysinstall will be able to recognize this situation in future releases. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 23:18:48 2010 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 4CE7B106568F for ; Tue, 2 Feb 2010 23:18:48 +0000 (UTC) (envelope-from peter.jeremy@alcatel-lucent.com) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by mx1.freebsd.org (Postfix) with ESMTP id 195738FC17 for ; Tue, 2 Feb 2010 23:18:47 +0000 (UTC) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o12N5I5H018992; Tue, 2 Feb 2010 17:05:19 -0600 (CST) Received: from insmb.au.alcatel-lucent.com (insmb.au.alcatel-lucent.com [139.188.42.184]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id o12N5G5Y009317; Tue, 2 Feb 2010 17:05:17 -0600 (CST) Received: from pjdesk.au.alcatel-lucent.com (pjdesk.au.alcatel-lucent.com [139.188.12.19]) by insmb.au.alcatel-lucent.com (8.13.8+Sun/8.13.3) with ESMTP id o12N5E8Y029852; Wed, 3 Feb 2010 10:05:15 +1100 (EST) X-Bogosity: Ham, spamicity=0.000000 Received: from pjdesk.au.alcatel-lucent.com (localhost [127.0.0.1]) by pjdesk.au.alcatel-lucent.com (8.14.3/8.14.3) with ESMTP id o12N5DlJ019870; Wed, 3 Feb 2010 10:05:13 +1100 (EST) (envelope-from peter.jeremy@alcatel-lucent.com) Received: (from pjeremy@localhost) by pjdesk.au.alcatel-lucent.com (8.14.3/8.14.3/Submit) id o12N5BIx019869; Wed, 3 Feb 2010 10:05:11 +1100 (EST) (envelope-from peter.jeremy@alcatel-lucent.com) Date: Wed, 3 Feb 2010 10:05:11 +1100 From: Peter Jeremy To: Andriy Gapon Message-ID: <20100202230511.GA19744@pjdesk.au.alcatel-lucent.com> References: <20100201085131.GA34006@server.vk2pj.dyndns.org> <4B66A0DD.2070109@icyb.net.ua> <20100202063635.GA64643@server.vk2pj.dyndns.org> <4B67C8A6.5050102@icyb.net.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline In-Reply-To: <4B67C8A6.5050102@icyb.net.ua> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: freebsd-stable@freebsd.org Subject: Re: Kernel probe order issues 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, 02 Feb 2010 23:18:48 -0000 --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Feb-02 08:39:34 +0200, Andriy Gapon wrote: >on 02/02/2010 08:36 Peter Jeremy said the following: >> On 2010-Feb-01 11:37:33 +0200, Andriy Gapon wrote: >>>> This strikes me as undesirable. Is there some way to bump up the >>>> probe/attach priority of console input devices to ensure that they >>>> exist before the kernel tries to read input? >>> It seems to be a problem with either your keyboard or your USB controll= er. >>> USB keyboard can be discovered much earlier than mountroot if the hardw= are is >>> ready. No magical software priority bump can help here. >>=20 >> I've tried a couple of different USB ports (controllers) with no >> change in behaviour. I'll try another keyboard if I can find one. It >> _does_ work as expected on 7.x so this is a regression. > >Unfortunately you keep being low on hardware details. Sorry. The box is a Dell GX620 (P4 with ICH7 chipset). The keyboard is a Dell SK-8115 connected directly to a motherboard port. I've also tried a Dell SK-8135 (which is the "multimedia" variant and has a builtin hub) which behaves the same. I've uploaded full details as follows: FreeBSD 7.x verbose dmesg: http://pastebin.ca/1776339 FreeBSD 8.x verbose dmesg: http://pastebin.ca/1776359 "pciconf -lv" (same in 7 & 8): http://pastebin.ca/1776363 The output from 'usbdevs -v' on FreeBSD 7 is: Controller /dev/usb0: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), Intel(0x= 0000), rev 1.00 port 1 powered port 2 powered Controller /dev/usb1: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), Intel(0x= 0000), rev 1.00 port 1 powered port 2 powered Controller /dev/usb2: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), Intel(0x= 0000), rev 1.00 port 1 powered port 2 addr 2: low speed, power 70 mA, config 1, Dell USB Keyboard(0x2003)= , Dell(0x413c), rev 2.00 Controller /dev/usb3: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), Intel(0x= 0000), rev 1.00 port 1 powered port 2 powered Controller /dev/usb4: addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), Intel(0x= 0000), rev 1.00 port 1 powered port 2 powered port 3 powered port 4 powered port 5 powered port 6 powered port 7 powered port 8 powered And the output from "usbconfig list" on FreeBSD 8 is: ugen0.1: at usbus0, cfg=3D0 md=3DHOST spd=3DFULL (12M= bps) pwr=3DON ugen1.1: at usbus1, cfg=3D0 md=3DHOST spd=3DFULL (12M= bps) pwr=3DON ugen2.1: at usbus2, cfg=3D0 md=3DHOST spd=3DFULL (12M= bps) pwr=3DON ugen3.1: at usbus3, cfg=3D0 md=3DHOST spd=3DFULL (12M= bps) pwr=3DON ugen4.1: at usbus4, cfg=3D0 md=3DHOST spd=3DHIGH (480= Mbps) pwr=3DON ugen2.2: at usbus2, cfg=3D0 md=3DHOST spd=3DLOW (1= =2E5Mbps) pwr=3DON The alternate keyboard shows up as: port 2 addr 2: full speed, power 100 mA, config 1, Dell USB Keyboard Hub(0= x1003), Dell(0x413c), rev 2.00 port 1 addr 3: full speed, power 50 mA, config 1, Dell USB Keyboard(0x201= 0), Dell(0x413c), rev 2.00 port 2 addr 4: low speed, power 100 mA, config 1, product 0x3010(0x3010),= vendor 0x413c(0x413c), rev 2.30 port 3 powered --=20 Peter Jeremy --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAktor6cACgkQ/opHv/APuIc+BQCfW2dRq/4sOq//AXW+WfF1HjZU XuYAn1EHV0uwoC81kUn5baLAlunfYn8c =TpQJ -----END PGP SIGNATURE----- --OXfL5xGRrasGEqWY-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 3 00:47:19 2010 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 18A61106568D for ; Wed, 3 Feb 2010 00:47:19 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (email.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id D0F6E8FC0C for ; Wed, 3 Feb 2010 00:47:18 +0000 (UTC) Received: by email.octopus.com.au (Postfix, from userid 1002) id 05ED15CBB40; Wed, 3 Feb 2010 11:47:14 +1100 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: * X-Spam-Status: No, score=1.9 required=10.0 tests=ALL_TRUSTED, FH_DATE_PAST_20XX autolearn=no version=3.2.3 Received: from [10.1.50.60] (ppp121-44-233-216.lns20.syd7.internode.on.net [121.44.233.216]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id 6D8D55CB920; Wed, 3 Feb 2010 11:47:09 +1100 (EST) Message-ID: <4B68C72D.506@modulus.org> Date: Wed, 03 Feb 2010 11:45:33 +1100 From: Andrew Snow User-Agent: Thunderbird 2.0.0.14 (X11/20080523) MIME-Version: 1.0 To: Jordi Espasa Clofent References: <4B685EBA.4020501@minibofh.org> In-Reply-To: <4B685EBA.4020501@minibofh.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: Re: ionice in 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, 03 Feb 2010 00:47:19 -0000 Jordi Espasa Clofent wrote: > ¿Is there some ionice(1) equivalent in FreeBSD? No. - Andrew From owner-freebsd-stable@FreeBSD.ORG Wed Feb 3 01:16:26 2010 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 E0F1B106566C for ; Wed, 3 Feb 2010 01:16:26 +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 5938D8FC19 for ; Wed, 3 Feb 2010 01:16:26 +0000 (UTC) Received: from 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 o131GMEP044960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 3 Feb 2010 11:46:23 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Wed, 3 Feb 2010 11:46:11 +1030 User-Agent: KMail/1.9.10 References: <4B685EBA.4020501@minibofh.org> In-Reply-To: <4B685EBA.4020501@minibofh.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart9734329.A8rTl8QOFV"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201002031146.19870.doconnor@gsoft.com.au> X-Spam-Score: -3.64 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Jordi Espasa Clofent Subject: Re: ionice in 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, 03 Feb 2010 01:16:27 -0000 --nextPart9734329.A8rTl8QOFV Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, 3 Feb 2010, Jordi Espasa Clofent wrote: > In Linux exists the ionice(1) for "get/set program io scheduling > class and priority". > > In FreeBSD we've nice(1), renice(8) and even rtprio, idprio(1) but if > I'm understanding correctly, they're related to CPU priorty only, not > to I/O. > > =BFIs there some ionice(1) equivalent in FreeBSD? There is no IO scheduler in FreeBSD outside of some experimental patches=20 at=20 http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2009-01/msg00316.html (I have no idea of their status) =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 --nextPart9734329.A8rTl8QOFV Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLaM5j5ZPcIHs/zowRAv42AJ4/zjypxluIYR8Z9DufaT01PrPCjQCfb3tu WETUQ6cPfJNw6s5XKeiUgUQ= =o9yw -----END PGP SIGNATURE----- --nextPart9734329.A8rTl8QOFV-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 3 01:43:01 2010 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 C67ED106566B for ; Wed, 3 Feb 2010 01:43:01 +0000 (UTC) (envelope-from sektie@gmail.com) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id 9C0408FC16 for ; Wed, 3 Feb 2010 01:43:01 +0000 (UTC) Received: by pxi13 with SMTP id 13so773126pxi.3 for ; Tue, 02 Feb 2010 17:43:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=TEMhinOPlv288Wlp7v7kflXVAYLj3k9IsD9grP9gh/0=; b=SeBTqj2R+2xdUA/8FBgsm0REt+O5A9qBtGYC8hkmQoCOViu+LhxAxlnpplQbJcAfwS dwOgqg2jLs5Gi88OU6yDuQoLoIsiTbSRhktjRwoAltDfqCMmNefFo5AKmNJACLqnPzai 0j9wM4MsFVGA6lDk3MoEXJWyZR46usc4/oDYk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=ZdhBVPD1ebKBu/5DgaYLLY8c//kbp6U09CY81dnPIEtWHJKkejihP5iiejQOsLP97b 53jIo3OBXpPe7voaNxA96FJ9C8nnVT71wS+lFe6bgSYLhKVTzaYY13kbW7xF0HAdLtge NEqXGTpPn1s776rL+0GCEZN8TM4uiTKAcszL4= MIME-Version: 1.0 Sender: sektie@gmail.com Received: by 10.142.117.1 with SMTP id p1mr1011473wfc.185.1265161381280; Tue, 02 Feb 2010 17:43:01 -0800 (PST) In-Reply-To: References: <20100122162155.GG3917@e-Gitt.NET> Date: Tue, 2 Feb 2010 17:43:01 -0800 X-Google-Sender-Auth: 528d2e2c69466848 Message-ID: From: Randi Harper To: Marian Hettwer Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: 8.0-RELEASE -> -STABLE and size of / 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, 03 Feb 2010 01:43:01 -0000 On Fri, Jan 22, 2010 at 8:27 AM, Marian Hettwer wrote: > Hi All, > > On Fri, 22 Jan 2010 17:21:56 +0100, Oliver Brandmueller > wrote: >> Hi, >> >> I just noticed somthing: I setup an 8.0-RELEASE amd64 box, / is default >> 512M. First step after setup was to csup to RELENG_8 and buildkernel and >> buildworld (no custom kernel, no make.conf). >> >> Instaling the new kernel failed, since /boot/kernel/ is already well >> over 230 MBytes in size. moving that to kernel.old and writing a new one >> with about the same size fails due to no space left on device. >> >> This is not a question; I do know how to get around this and how to >> configure custom kernels so they are a fragment of that size afterwards. >> However, I think this is a clear POLA violation. So, either GENERIC with >> less debugging information (symbols and stuff), which makes debugging >> harder or setting a higher default for / would be options, if not anyone >> else has better ideas. >> > +1 vote for making / bigger. > At least a size where a make installkernel runs through. > > I like FreeBSD because it honors POLA. > And as Oliver stated, this is a clear POLA violation. > > Cheers, > Marian > > _______________________________________________ > 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" > This is going to happen. It's been on my to-do list for a while, as I find it increasingly annoying. The default sizes of all mount points need to be tweaked a bit. Be patient, there will be some new changes going into sysinstall very soon. -- randi From owner-freebsd-stable@FreeBSD.ORG Wed Feb 3 08:08:28 2010 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 9E27C106566C for ; Wed, 3 Feb 2010 08:08:28 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by mx1.freebsd.org (Postfix) with ESMTP id BB8F08FC1E for ; Wed, 3 Feb 2010 08:08:27 +0000 (UTC) Received: by bwz3 with SMTP id 3so834435bwz.13 for ; Wed, 03 Feb 2010 00:08:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=2t58gFYNmAvzxphT/Fwcqj1GSgUsohWBtn993xe/o/w=; b=hb9dZ4ZDhDHRk4kpO//Z08wPllaHmB88B9ye5/L94mZKf1NKBtqRkrOlP0prLZNLoB c3GgHUTU6PYY8IOoLqvcnf8QVeVYnFsJsBtQAU5todaoNqoPSNuAj3FbcPoCO5jdwRcJ 6Zl/SKu/bXWmaYrDb2JSVBv2a6cuYJ+rd161c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=uk7cU3tjEmnI5FsFtCIKDzajuJH/XDM6r4QH0B+3RcS2XKc+wM5bStFS4ILoD1/w7Z rpGSjV0Q+wj/J2Ufv+jbiXZCD2VCkwtemuhAnAdwVMz7OaTbDBKZfEByS9V+ZgR149bp 9Kim6Siyu0XPzW40u0NE1GjEAjs2tnlw547PY= MIME-Version: 1.0 Received: by 10.204.6.72 with SMTP id 8mr4585062bky.28.1265184506388; Wed, 03 Feb 2010 00:08:26 -0800 (PST) In-Reply-To: References: Date: Wed, 3 Feb 2010 11:08:26 +0300 Message-ID: From: pluknet To: freebsd-stable Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Subject: Re: nmi_calltrap in siopoll() 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, 03 Feb 2010 08:08:28 -0000 kern/143521 2010/2/2 pluknet : > Hi. > > I've got NMI on an almost idle system - FreeBSD 7.2-R amd64. > I guess the reason may be in (hardware?) binary garbage > seen once in a while on serial port (loader, then ttyd0). > Ask me for more details. > > Tracing command swi4: clock sio pid 20 tid 100011 td 0xffffff000144e370 > cpustop_handler() at cpustop_handler+64 > ipi_nmi_handler() at ipi_nmi_handler+48 > trap() at trap+796 > nmi_calltrap() at nmi_calltrap+8 > --- trap 19, rip =3D 18446744071567390785, rsp =3D 18446744067267268592, > rbp =3D 18446744067267558272 --- > _mtx_lock_spin() at _mtx_lock_spin+113 > siopoll() at siopoll+206 > ithread_loop() at ithread_loop+384 > fork_exit() at fork_exit+287 > fork_trampoline() at fork_trampoline+14 > --- trap 0, rip =3D 0, rsp =3D 18446744067267558704, rbp =3D 0 --- > > (kgdb) thr 13 > [Switching to thread 13 (Thread 100011)]#0 =9Acpustop_handler () at atomi= c.h:264 > 264 =9A =9A atomic.h: No such file or directory. > =9A =9A =9A =9Ain atomic.h > (kgdb) bt > #0 =9Acpustop_handler () at atomic.h:264 > #1 =9A0xffffffff807ec400 in ipi_nmi_handler () > =9A =9Aat /usr/src/sys/amd64/amd64/mp_machdep.c:1144 > #2 =9A0xffffffff807fceec in trap (frame=3D0xfffffffe80028f40) > =9A =9Aat /usr/src/sys/amd64/amd64/trap.c:198 > #3 =9A0xffffffff807e0aeb in nmi_calltrap () > =9A =9Aat /usr/src/sys/amd64/amd64/exception.S:427 > #4 =9A0xffffffff80513841 in _mtx_lock_spin (m=3D0xffffffff80bb3d00, > =9A =9Atid=3D18446742974219215728, opts=3DVariable "opts" is not availabl= e. > ) at /usr/src/sys/kern/kern_mutex.c:474 > #5 =9A0xffffffff8082b96e in siopoll (dummy=3DVariable "dummy" is not avai= lable. > ) at /usr/src/sys/dev/sio/sio.c:1703 > #6 =9A0xffffffff804ff940 in ithread_loop (arg=3D0xffffff000142bac0) > =9A =9Aat /usr/src/sys/kern/kern_intr.c:1088 > #7 =9A0xffffffff804fc1df in fork_exit ( > =9A =9Acallout=3D0xffffffff804ff7c0 , arg=3D0xffffff000142b= ac0, > =9A =9Aframe=3D0xfffffffe8006fc80) at /usr/src/sys/kern/kern_fork.c:834 > #8 =9A0xffffffff807e0b5e in fork_trampoline () > =9A =9Aat /usr/src/sys/amd64/amd64/exception.S:455 > #9 =9A0x0000000000000000 in ?? () > #10 0x0000000000000000 in ?? () > #11 0x0000000000000001 in ?? () > #12 0x0000000000000000 in ?? () > #13 0x0000000000000000 in ?? () > #14 0x0000000000000000 in ?? () > ---Type to continue, or q to quit---q > Quit > (kgdb) f 5 > #5 =9A0xffffffff8082b96e in siopoll (dummy=3DVariable "dummy" is not avai= lable. > ) at /usr/src/sys/dev/sio/sio.c:1703 > 1703 =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9Amtx_lock_spin= (&sio_lock); > (kgdb) i loc > _tid =3D Variable "_tid" is not available. > (kgdb) list > 1698 =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9Acom_events -= =3D incc; > 1699 =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9Amtx_unlock_sp= in(&sio_lock); > 1700 =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9Acontinue; > 1701 =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A} > 1702 =9A =9A =9A =9A =9A =9A =9A =9A =9A =9Aif (com->iptr !=3D com->ibuf)= { > 1703 =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9Amtx_lock_spin= (&sio_lock); > 1704 =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9Asioinput(com)= ; > 1705 =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9Amtx_unlock_sp= in(&sio_lock); > 1706 =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A} > 1707 =9A =9A =9A =9A =9A =9A =9A =9A =9A =9Aif (com->state & CS_CHECKMSR)= { > (kgdb) p sio_lock > $1 =3D {lock_object =3D {lo_name =3D 0xffffffff80b15380 "sio", > =9A =9Alo_type =3D 0xffffffff80b15380 "sio", lo_flags =3D 458752, lo_witn= ess_data =3D { > =9A =9A =9Alod_list =3D {stqe_next =3D 0x0}, lod_witness =3D 0x0}}, > =9Amtx_lock =3D 18446742974219094608, mtx_recurse =3D 0} > (kgdb) p/x sio_lock->mtx_lock > $10 =3D 0xffffff0001430a50 =9A# =3D=3D td for pid 17 tid 100008 > > > Binary garbage is like below (not touching anything on k/board atm). > > login: > FreeBSD/amd64 (ho > FreeBSD/amd64 (host) (ttyd0) > > login: <<|=FE > FreeBSD > FreeBSD > FreeBS > FreeBSD > Free > FreeBSD/amd64 (host) (ttyd0) > > login: > FreeBSD/amd64 (host) (ttyd0) > > login: > FreeBSD > Free > > FreeBS > FreeBSD > FreeBS > FreeBSD > FreeBSD > FreeBS > FreeBSD > FreeBS > FreeBSD > FreeBSD > FreeBS > FreeBSD > FreeBS=A0=A8H=C8=C9 =9A =9A M5 > FreeBSD > FreeBS > FreeBSD > FreeBSD > FreeBS > FreeBSD > FreeBS=A0=A8H=C8=C9 =9A =9A M5 > FreeBSD > FreeBS > FreeBSD > FreeB > FreeBSD/amd6 > FreeBS > FreeBS > FreeBSD > FreeBSD > FreeBS > FreeBSD > FreeBS > FreeBSD > FreeBSD > FreeBS > FreeBSD > FreeBS=A0=A8H=C8=C9 =9A =9A M5 > FreeBSD > FreeBS > FreeBSD > [..a little later..] > > [root@host ~]# <<<<<<<<<<<><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<8<<<<<8<<<= < > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<8<<<<<<<>< > > Other useful stuff. > > (kgdb) f 4 > #4 =9A0xffffffff80513841 in _mtx_lock_spin (m=3D0xffffffff80bb3d00, > =9A =9Atid=3D18446742974219215728, opts=3DVariable "opts" is not availabl= e. > ) at /usr/src/sys/kern/kern_mutex.c:474 > 474 =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A while (m->mtx_lock !=3D MTX_U= NOWNED) { > (kgdb) list > 469 =9A =9A =9A =9A =9A =9A lock_profile_obtain_lock_failed(&m->lock_obje= ct, > &contested, &waittime); > 470 =9A =9A =9A =9A =9A =9A while (!_obtain_lock(m, tid)) { > 471 > 472 =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A /* Give interrupts a chance w= hile we spin. */ > 473 =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A spinlock_exit(); > 474 =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A while (m->mtx_lock !=3D MTX_U= NOWNED) { > 475 =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A if (i++ < 100= 00000) { > 476 =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A = =9A cpu_spinwait(); > 477 =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A = =9A continue; > 478 =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A } > (kgdb) f 3 > #3 =9A0xffffffff807e0aeb in nmi_calltrap () > =9A =9Aat /usr/src/sys/amd64/amd64/exception.S:427 > 427 =9A =9A =9A =9A =9A =9A call =9A =9Atrap > Current language: =9Aauto; currently asm > (kgdb) list > 422 =9A =9A =9A =9A =9A =9A swapgs > 423 =9A =9A /* Note: this label is also used by ddb and gdb: */ > 424 =9A =9A nmi_calltrap: > 425 =9A =9A =9A =9A =9A =9A FAKE_MCOUNT(TF_RIP(%rsp)) > 426 =9A =9A =9A =9A =9A =9A movq =9A =9A%rsp, %rdi > 427 =9A =9A =9A =9A =9A =9A call =9A =9Atrap > 428 =9A =9A =9A =9A =9A =9A MEXITCOUNT > 429 =9A =9A =9A =9A =9A =9A testl =9A %ebx,%ebx > 430 =9A =9A =9A =9A =9A =9A jz =9A =9A =9Anmi_restoreregs > 431 =9A =9A =9A =9A =9A =9A swapgs > (kgdb) f 2 > #2 =9A0xffffffff807fceec in trap (frame=3D0xfffffffe80028f40) > =9A =9Aat /usr/src/sys/amd64/amd64/trap.c:198 > 198 =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9Aif (ipi_nmi_handler() =3D= =3D 0) > Current language: =9Aauto; currently c > (kgdb) list > 193 > 194 =9A =9A #ifdef SMP > 195 =9A =9A #ifdef STOP_NMI > 196 =9A =9A =9A =9A =9A =9A /* Handler for NMI IPIs used for stopping CPU= s. */ > 197 =9A =9A =9A =9A =9A =9A if (type =3D=3D T_NMI) { > 198 =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9Aif (ipi_nmi_handler() =3D= =3D 0) > 199 =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9Agoto o= ut; > 200 =9A =9A =9A =9A =9A =9A } > 201 =9A =9A #endif /* STOP_NMI */ > 202 =9A =9A #endif /* SMP */ > > > db> bt > Tracing pid 17 tid 100008 td 0xffffff0001430a50 > kdb_enter_why() at kdb_enter_why+0x3d > siointr1() at siointr1+0x2c5 > siointr() at siointr+0x58 > intr_execute_handlers() at intr_execute_handlers+0x8b > Xapic_isr1() at Xapic_isr1+0x7f > --- interrupt, rip =3D 0xffffffff807d8bd6, rsp =3D 0xfffffffe8005fb90, rb= p > =3D 0xfffffffe8005fba0 --- > acpi_cpu_c1() at acpi_cpu_c1+0x6 > acpi_cpu_idle() at acpi_cpu_idle+0x19c > sched_idletd() at sched_idletd+0x46 > fork_exit() at fork_exit+0x11f > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip =3D 0, rsp =3D 0xfffffffe8005fd30, rbp =3D 0 --- > > (kgdb) p (struct thread) *sio_lock->mtx_lock > $15 =3D {td_lock =3D 0xffffffff80b7bc40, td_proc =3D 0xffffff000142e478, = td_plist =3D { > =9A =9Atqe_next =3D 0x0, tqe_prev =3D 0xffffff000142e488}, td_slpq =3D {t= qe_next =3D 0x0, > =9A =9Atqe_prev =3D 0x0}, td_lockq =3D {tqe_next =3D 0x0, tqe_prev =3D 0x= 0}, td_selq =3D { > =9A =9Atqh_first =3D 0x0, tqh_last =3D 0x0}, td_sleepqueue =3D 0xffffff00= 01418c00, > =9Atd_turnstile =3D 0xffffff00012f9a00, td_umtxq =3D 0xffffff000142a380, > =9Atd_tid =3D 100008, td_sigqueue =3D {sq_signals =3D {__bits =3D {0, 0, = 0, 0}}, > =9A =9Asq_kill =3D {__bits =3D {0, 0, 0, 0}}, sq_list =3D {tqh_first =3D = 0x0, > =9A =9A =9Atqh_last =3D 0xffffff0001430ae0}, sq_proc =3D 0xffffff000142e4= 78, > =9A =9Asq_flags =3D 1}, td_flags =3D 65572, td_inhibitors =3D 0, td_pflag= s =3D 0, > =9Atd_dupfd =3D 0, td_sqqueue =3D 0, td_wchan =3D 0x0, td_wmesg =3D 0x0, > =9Atd_lastcpu =3D 1 '\001', td_oncpu =3D 1 '\001', td_owepreempt =3D 0 '\= 0', > =9Atd_locks =3D 0, td_tsqueue =3D 0 '\0', td_blocked =3D 0x0, td_lockname= =3D 0x0, > =9Atd_contested =3D {lh_first =3D 0x0}, td_sleeplocks =3D 0x0, > =9Atd_intr_nesting_level =3D 1, td_pinned =3D 0, td_mailbox =3D 0x0, > =9Atd_ucred =3D 0xffffff0001300e00, td_standin =3D 0x0, td_upcall =3D 0x0= , > =9Atd_estcpu =3D 0, td_slptick =3D 0, td_ru =3D {ru_utime =3D {tv_sec =3D= 0, > =9A =9A =9Atv_usec =3D 0}, ru_stime =3D {tv_sec =3D 0, tv_usec =3D 0}, ru= _maxrss =3D 0, > =9A =9Aru_ixrss =3D 0, ru_idrss =3D 0, ru_isrss =3D 0, ru_minflt =3D 0, r= u_majflt =3D 0, > =9A =9Aru_nswap =3D 0, ru_inblock =3D 0, ru_oublock =3D 0, ru_msgsnd =3D = 0, > =9A =9Aru_msgrcv =3D 0, ru_nsignals =3D 0, ru_nvcsw =3D 6414, ru_nivcsw = =3D 38607927}, > =9Atd_runtime =3D 2179322361251400, td_pticks =3D 145105307, td_sticks = =3D 7704049, > =9Atd_iticks =3D 0, td_uticks =3D 0, td_uuticks =3D 0, td_usticks =3D 0, > =9Atd_intrval =3D 0, td_oldsigmask =3D {__bits =3D {0, 0, 0, 0}}, td_sigm= ask =3D { > ---Type to continue, or q to quit--- > =9A =9A__bits =3D {0, 0, 0, 0}}, td_generation =3D 38614341, td_sigstk = =3D { > =9A =9Ass_sp =3D 0x0, ss_size =3D 0, ss_flags =3D 0}, td_kflags =3D 0, td= _xsig =3D 0, > =9Atd_profil_addr =3D 0, td_profil_ticks =3D 0, td_name =3D '\0' , > =9Atd_base_pri =3D 255 '=FF', td_priority =3D 255 '=FF', td_pri_class =3D= 4 '\004', > =9Atd_user_pri =3D 180 '=B4', td_base_user_pri =3D 180 '=B4', > =9Atd_pcb =3D 0xfffffffe8005fd40, td_state =3D TDS_RUNNING, td_retval =3D= {0, 0}, > =9Atd_slpcallout =3D {c_links =3D {sle =3D {sle_next =3D 0x0}, tqe =3D {t= qe_next =3D 0x0, > =9A =9A =9A =9Atqe_prev =3D 0x0}}, c_time =3D 0, c_arg =3D 0x0, c_func = =3D 0, c_mtx =3D 0x0, > =9A =9Ac_flags =3D 16}, td_frame =3D 0xfffffffe8005fc80, > =9Atd_kstack_obj =3D 0xffffff0001431740, td_kstack =3D 184467440672674775= 04, > =9Atd_kstack_pages =3D 4, td_altkstack_obj =3D 0x0, td_altkstack =3D 0, > =9Atd_altkstack_pages =3D 0, td_critnest =3D 2, td_md =3D {md_spinlock_co= unt =3D 1, > =9A =9Amd_saved_flags =3D 70}, td_sched =3D 0xffffff0001430d80, td_ar =3D= 0x0, > =9Atd_syscalls =3D 0, td_incruntime =3D 115662355444194, > =9Atd_cpuset =3D 0xffffff0001424dc8, td_fpop =3D 0x0, td_dtrace =3D 0x0, = td_errno =3D 0} > > (kgdb) p (struct proc) *0xffffff000142e478 > $16 =3D {p_list =3D {le_next =3D 0xffffff000142e8f0, le_prev =3D 0xffffff= 00014458f0}, > =9Ap_threads =3D {tqh_first =3D 0xffffff0001430a50, tqh_last =3D 0xffffff= 0001430a60}, > =9Ap_upcalls =3D {tqh_first =3D 0x0, tqh_last =3D 0xffffff000142e498}, p_= slock =3D { > =9A =9Alock_object =3D {lo_name =3D 0xffffffff808da2a3 "process slock", > =9A =9A =9Alo_type =3D 0xffffffff808da2a3 "process slock", lo_flags =3D 7= 20896, > =9A =9A =9Alo_witness_data =3D {lod_list =3D {stqe_next =3D 0x0}, lod_wit= ness =3D 0x0}}, > =9A =9Amtx_lock =3D 4, mtx_recurse =3D 0}, p_ucred =3D 0xffffff0001300e00= , > =9Ap_fd =3D 0xffffff0001443400, p_fdtol =3D 0x0, p_stats =3D 0xffffff0001= 2ff600, > =9Ap_limit =3D 0xffffff0001300c00, p_limco =3D {c_links =3D {sle =3D {sle= _next =3D 0x0}, > =9A =9A =9Atqe =3D {tqe_next =3D 0x0, tqe_prev =3D 0x0}}, c_time =3D 0, c= _arg =3D 0x0, > =9A =9Ac_func =3D 0, c_mtx =3D 0xffffff000142e590, c_flags =3D 0}, > =9Ap_sigacts =3D 0xffffff000143e000, p_flag =3D 268435980, p_state =3D PR= S_NORMAL, > =9Ap_pid =3D 17, p_hash =3D {le_next =3D 0x0, le_prev =3D 0xfffffffe8021c= 088}, > =9Ap_pglist =3D {le_next =3D 0xffffff000142e8f0, le_prev =3D 0xffffff0001= 4459d8}, > =9Ap_pptr =3D 0xffffffff80b64640, p_sibling =3D {le_next =3D 0xffffff0001= 42e8f0, > =9A =9Ale_prev =3D 0xffffff00014459f0}, p_children =3D {lh_first =3D 0x0}= , p_mtx =3D { > =9A =9Alock_object =3D {lo_name =3D 0xffffffff808da296 "process lock", > =9A =9A =9Alo_type =3D 0xffffffff808da296 "process lock", lo_flags =3D 21= 168128, > =9A =9A =9Alo_witness_data =3D {lod_list =3D {stqe_next =3D 0x0}, lod_wit= ness =3D 0x0}}, > =9A =9Amtx_lock =3D 4, mtx_recurse =3D 0}, p_ksi =3D 0x0, p_sigqueue =3D = {sq_signals =3D { > =9A =9A =9A__bits =3D {0, 0, 0, 0}}, sq_kill =3D {__bits =3D {0, 0, 0, 0}= }, sq_list =3D { > =9A =9A =9Atqh_first =3D 0x0, tqh_last =3D 0xffffff000142e5e8}, > =9A =9Asq_proc =3D 0xffffff000142e478, sq_flags =3D 1}, p_oppid =3D 0, > ---Type to continue, or q to quit--- > =9Ap_vmspace =3D 0xffffffff80b64e00, p_swtick =3D 0, p_realtimer =3D {it_= interval =3D { > =9A =9A =9Atv_sec =3D 0, tv_usec =3D 0}, it_value =3D {tv_sec =3D 0, tv_u= sec =3D 0}}, p_ru =3D { > =9A =9Aru_utime =3D {tv_sec =3D 0, tv_usec =3D 0}, ru_stime =3D {tv_sec = =3D 0, > =9A =9A =9Atv_usec =3D 0}, ru_maxrss =3D 0, ru_ixrss =3D 0, ru_idrss =3D = 0, ru_isrss =3D 0, > =9A =9Aru_minflt =3D 0, ru_majflt =3D 0, ru_nswap =3D 0, ru_inblock =3D 0= , > =9A =9Aru_oublock =3D 0, ru_msgsnd =3D 0, ru_msgrcv =3D 0, ru_nsignals = =3D 0, > =9A =9Aru_nvcsw =3D 0, ru_nivcsw =3D 0}, p_rux =3D {rux_runtime =3D 20636= 60005807206, > =9A =9Arux_uticks =3D 0, rux_sticks =3D 137401258, rux_iticks =3D 0, rux_= uu =3D 0, > =9A =9Arux_su =3D 371936150861, rux_tu =3D 1034416043011}, p_crux =3D {ru= x_runtime =3D 0, > =9A =9Arux_uticks =3D 0, rux_sticks =3D 0, rux_iticks =3D 0, rux_uu =3D 0= , rux_su =3D 0, > =9A =9Arux_tu =3D 0}, p_profthreads =3D 0, p_exitthreads =3D 0, p_tracefl= ag =3D 0, > =9Ap_tracevp =3D 0x0, p_tracecred =3D 0x0, p_textvp =3D 0x0, p_lock =3D 0= '\0', > =9Ap_sigiolst =3D {slh_first =3D 0x0}, p_sigparent =3D 20, p_sig =3D 0, p= _code =3D 0, > =9Ap_stops =3D 0, p_stype =3D 0, p_step =3D 0 '\0', p_pfsflags =3D 0 '\0'= , > =9Ap_nlminfo =3D 0x0, p_aioinfo =3D 0x0, p_singlethread =3D 0x0, p_suspco= unt =3D 0, > =9Ap_xthread =3D 0x0, p_boundary_count =3D 0, p_pendingcnt =3D 0, p_itime= rs =3D 0x0, > =9Ap_numupcalls =3D 0, p_upsleeps =3D 0, p_completed =3D 0x0, p_nextupcal= l =3D 0, > =9Ap_upquantum =3D 0, p_magic =3D 3203398350, p_osrel =3D 702000, > =9Ap_comm =3D "idle: cpu1\000\000\000\000\000\000\000\000\000", > =9Ap_pgrp =3D 0xffffffff80b65060, p_sysent =3D 0xffffffff80ad4d80, p_args= =3D 0x0, > =9Ap_cpulimit =3D 9223372036854775807, p_nice =3D 0 '\0', p_fibnum =3D 0, > =9Ap_xstat =3D 0, p_klist =3D {kl_list =3D {slh_first =3D 0x0}, > =9A =9Akl_lock =3D 0xffffffff804f65d0 , > ---Type to continue, or q to quit--- > =9A =9Akl_unlock =3D 0xffffffff804f5ff0 , > =9A =9Akl_locked =3D 0xffffffff804f5fd0 , > =9A =9Akl_lockarg =3D 0xffffff000142e590}, p_numthreads =3D 1, > =9Ap_md =3D , p_itcallout =3D {c_links =3D {sle =3D {sle= _next =3D 0x0}, > =9A =9A =9Atqe =3D {tqe_next =3D 0x0, tqe_prev =3D 0x0}}, c_time =3D 0, c= _arg =3D 0x0, > =9A =9Ac_func =3D 0, c_mtx =3D 0x0, c_flags =3D 16}, p_acflag =3D 1, p_pe= ers =3D 0x0, > =9Ap_leader =3D 0xffffff000142e478, p_emuldata =3D 0x0, p_label =3D 0x0, > =9Ap_sched =3D 0xffffff000142e8f0, p_ktr =3D {stqh_first =3D 0x0, > =9A =9Astqh_last =3D 0xffffff000142e8d0}, p_mqnotifier =3D {lh_first =3D = 0x0}, > =9Ap_dtrace =3D 0x0} > > > db> show allpcpu > Current CPU: 1 > > cpuid =9A =9A =9A =9A=3D 0 > curthread =9A =9A=3D 0xffffff00014306e0: pid 18 "idle: cpu0" > curpcb =9A =9A =9A =3D 0xfffffffe80064d40 > fpcurthread =9A=3D none > idlethread =9A =3D 0xffffff00014306e0: pid 18 "idle: cpu0" > > cpuid =9A =9A =9A =9A=3D 1 > curthread =9A =9A=3D 0xffffff0001430a50: pid 17 "idle: cpu1" > curpcb =9A =9A =9A =3D 0xfffffffe8005fd40 > fpcurthread =9A=3D none > idlethread =9A =3D 0xffffff0001430a50: pid 17 "idle: cpu1" > > cpuid =9A =9A =9A =9A=3D 2 > curthread =9A =9A=3D 0xffffff000143c000: pid 16 "idle: cpu2" > curpcb =9A =9A =9A =3D 0xfffffffe8005ad40 > fpcurthread =9A=3D none > idlethread =9A =3D 0xffffff000143c000: pid 16 "idle: cpu2" > > cpuid =9A =9A =9A =9A=3D 3 > curthread =9A =9A=3D 0xffffff000143c370: pid 15 "idle: cpu3" > curpcb =9A =9A =9A =3D 0xfffffffe80055d40 > fpcurthread =9A=3D none > idlethread =9A =3D 0xffffff000143c370: pid 15 "idle: cpu3" > > cpuid =9A =9A =9A =9A=3D 4 > curthread =9A =9A=3D 0xffffff000143c6e0: pid 14 "idle: cpu4" > curpcb =9A =9A =9A =3D 0xfffffffe80050d40 > fpcurthread =9A=3D none > idlethread =9A =3D 0xffffff000143c6e0: pid 14 "idle: cpu4" > > cpuid =9A =9A =9A =9A=3D 5 > curthread =9A =9A=3D 0xffffff000144e370: pid 20 "swi4: clock sio" > curpcb =9A =9A =9A =3D 0xfffffffe8006fd40 > fpcurthread =9A=3D none > idlethread =9A =3D 0xffffff000142f000: pid 13 "idle: cpu5" > > cpuid =9A =9A =9A =9A=3D 6 > curthread =9A =9A=3D 0xffffff000142f370: pid 12 "idle: cpu6" > curpcb =9A =9A =9A =3D 0xfffffffe80046d40 > fpcurthread =9A=3D none > idlethread =9A =3D 0xffffff000142f370: pid 12 "idle: cpu6" > > cpuid =9A =9A =9A =9A=3D 7 > curthread =9A =9A=3D 0xffffff000142f6e0: pid 11 "idle: cpu7" > curpcb =9A =9A =9A =3D 0xfffffffe80041d40 > fpcurthread =9A=3D none > idlethread =9A =3D 0xffffff000142f6e0: pid 11 "idle: cpu7" > > > -- > wbr, > pluknet > --=20 wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Wed Feb 3 10:51:42 2010 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 B0369106566B; Wed, 3 Feb 2010 10:51:42 +0000 (UTC) (envelope-from james-freebsd-fs2@jrv.org) Received: from mail.jrv.org (adsl-70-243-84-13.dsl.austtx.swbell.net [70.243.84.13]) by mx1.freebsd.org (Postfix) with ESMTP id C96408FC1A; Wed, 3 Feb 2010 10:51:41 +0000 (UTC) Received: from kremvax.housenet.jrv (kremvax.housenet.jrv [192.168.3.124]) by mail.jrv.org (8.14.3/8.14.3) with ESMTP id o13AF6Y1043770; Wed, 3 Feb 2010 04:15:06 -0600 (CST) (envelope-from james-freebsd-fs2@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-fs2@jrv.org DomainKey-Signature: a=rsa-sha1; s=enigma; d=jrv.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=XbLxPMEfxPhBS8EBaZFYLK1D7a7RoyNOfNtnrPb6a4i3R3pkxd4eb+gZH62IG1mZt sQFVy9lpG3gEo3PSmF4Mwm+pkYNaW7PP6uIvv1OKZdc+jfn1T664Gc/nyIYpQvxdNHp GiY2fYgFB16PK2C5yvHe7/4VRQ5UqS4wK0gD/Rk= Message-ID: <4B694CAA.60703@jrv.org> Date: Wed, 03 Feb 2010 04:15:06 -0600 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Dan Naumov References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance 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, 03 Feb 2010 10:51:42 -0000 Dan Naumov wrote: > [jago@atombsd ~]$ dd if=/dev/zero of=/home/jago/test2 bs=1M count=4096 > 4096+0 records in > 4096+0 records out > 4294967296 bytes transferred in 143.878615 secs (29851325 bytes/sec) > > This works out to 1GB in 36,2 seconds / 28,2mb/s in the first test and > 4GB in 143.8 seconds / 28,4mb/s For the record, better results can be seen. In my test I put 3 Seagate Barracuda XT drives in a port multiplier and connected that to one port of a PCIe 3124 card. The MIRROR case is at about the I/O bandwidth limit of those drives. [root@kraken ~]# zpool create tmpx ada{2,3,4} [root@kraken ~]# dd if=/dev/zero of=/tmpx/test2 bs=1M count=4096 4096+0 records in 4096+0 records out 4294967296 bytes transferred in 20.892818 secs (205571470 bytes/sec) [root@kraken ~]# zpool destroy tmpx [root@kraken ~]# zpool create tmpx mirror ada{2,3} [root@kraken ~]# dd if=/dev/zero of=/tmpx/test2 bs=1M count=4096 4096+0 records in 4096+0 records out 4294967296 bytes transferred in 36.432818 secs (117887321 bytes/sec) [root@kraken ~]# From owner-freebsd-stable@FreeBSD.ORG Wed Feb 3 11:12:28 2010 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 D30DD106568B for ; Wed, 3 Feb 2010 11:12:28 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id A37AB8FC14 for ; Wed, 3 Feb 2010 11:12:28 +0000 (UTC) Received: from compute1.internal (compute1.internal [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id D5842DCDBD for ; Wed, 3 Feb 2010 06:12:27 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 03 Feb 2010 06:12:27 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpout; bh=c0K7jpfBzHBoDxO4Qc6k6BCL1cY=; b=KXi79xHqh65ypIdhlWnNR5LEu8v905qz8htftoLdO+ourHIPvLaf2VPUcLt4aqg9JwnQHmZtp90oDiYo2va3ZJtCziSmMRUzKdkJds+eJHspUqip1B24hI/cYw8beUke3EGuMUKlAd5V1gUTZrPNZRW9AQHwJxj0Oc2rnjuRpnY= X-Sasl-enc: /m46GmBXzPOOs5rcwJ3ZlKtZzZvCIWpwpY98HjFGMB6Z 1265195547 Received: from [192.168.123.18] (cpc2-dals7-0-0-cust253.hari.cable.virginmedia.com [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 6CBD24A5FA3 for ; Wed, 3 Feb 2010 06:12:27 -0500 (EST) Message-ID: <4B695A1A.1000505@incunabulum.net> Date: Wed, 03 Feb 2010 11:12:26 +0000 From: Bruce Simpson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-GB; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4B685EBA.4020501@minibofh.org> In-Reply-To: <4B685EBA.4020501@minibofh.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ionice in 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, 03 Feb 2010 11:12:28 -0000 On 02/02/2010 17:19, Jordi Espasa Clofent wrote: > > In FreeBSD we've nice(1), renice(8) and even rtprio, idprio(1) but if > I'm understanding correctly, they're related to CPU priorty only, not > to I/O. That's not entirely true. A thread's CPU priority is still going to affect its ability to be scheduled on the CPU, and if it's waiting in the read() or write() syscalls, then this will make a difference to how quickly it can complete the next call. However, it doesn't explicitly affect relative I/O prioritization. This is another story entirely. I suspect in a lot of cases adding a weight to per thread I/O, isn't going to make much difference for disk I/Os which are being sorted for the geometry (e.g. AHCI NCQ). So I guess my question is, 'why do you need I/O scheduling, and what aspect of system performance are you trying to solve with it' ? From owner-freebsd-stable@FreeBSD.ORG Wed Feb 3 11:52:03 2010 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 AC6F41065672 for ; Wed, 3 Feb 2010 11:52:03 +0000 (UTC) (envelope-from jespasac@minibofh.org) Received: from smtp02.cdmon.com (smtp02.cdmon.com [212.36.74.56]) by mx1.freebsd.org (Postfix) with ESMTP id 6DFB98FC0C for ; Wed, 3 Feb 2010 11:52:03 +0000 (UTC) Received: from jespasac.cdmon.com (62.Red-217-126-43.staticIP.rima-tde.net [217.126.43.62]) (Authenticated sender: jespasac@noverificar) by smtp02.cdmon.com (Postfix) with ESMTP id 4817645BD6 for ; Wed, 3 Feb 2010 12:52:01 +0100 (CET) Message-ID: <4B696360.3070209@minibofh.org> Date: Wed, 03 Feb 2010 12:52:00 +0100 From: Jordi Espasa Clofent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0b1 Thunderbird/3.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4B685EBA.4020501@minibofh.org> <4B695A1A.1000505@incunabulum.net> In-Reply-To: <4B695A1A.1000505@incunabulum.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ionice in 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, 03 Feb 2010 11:52:03 -0000 On 02/03/2010 12:12 PM, Bruce Simpson wrote: > On 02/02/2010 17:19, Jordi Espasa Clofent wrote: >> >> In FreeBSD we've nice(1), renice(8) and even rtprio, idprio(1) but if >> I'm understanding correctly, they're related to CPU priorty only, not >> to I/O. > > That's not entirely true. > > A thread's CPU priority is still going to affect its ability to be > scheduled on the CPU, and if it's waiting in the read() or write() > syscalls, then this will make a difference to how quickly it can > complete the next call. Yes. I've already supposed it. > However, it doesn't explicitly affect relative I/O prioritization. This > is another story entirely. I suspect in a lot of cases adding a weight > to per thread I/O, isn't going to make much difference for disk I/Os > which are being sorted for the geometry (e.g. AHCI NCQ). > > So I guess my question is, 'why do you need I/O scheduling, and what > aspect of system performance are you trying to solve with it' ? Some shell-scripts based on dd or rsync, for example. Even a daily antivirus (ClamAV) scanner means an extensive I/O. -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 3 12:33:18 2010 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 4C63F106568D for ; Wed, 3 Feb 2010 12:33:18 +0000 (UTC) (envelope-from jespasac@minibofh.org) Received: from xen-smtp03.cdmon.com (rbl.cdmon.com [212.36.74.233]) by mx1.freebsd.org (Postfix) with ESMTP id 0E6638FC19 for ; Wed, 3 Feb 2010 12:33:17 +0000 (UTC) Received: from jespasac.cdmon.com (62.Red-217-126-43.staticIP.rima-tde.net [217.126.43.62]) (Authenticated sender: jespasac@noverificar) by xen-smtp03.cdmon.com (Postfix) with ESMTPA id C115A7C200; Wed, 3 Feb 2010 13:33:15 +0100 (CET) Message-ID: <4B696D0B.3070301@minibofh.org> Date: Wed, 03 Feb 2010 13:33:15 +0100 From: Jordi Espasa Clofent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0b1 Thunderbird/3.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Inmutable bit in some binaries 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, 03 Feb 2010 12:33:18 -0000 HI all, I'm hardening one test box and at present I'm planning to do: # chflags -R schg where will be some binaries that seems to be common targets for rootkits and lammers: ls du ps find top locate strings ifconfig netstat login I wonder if changing these files permissions as I've shown above will be cause some troubles in future upgrade (recompilation, the classic way, not the binary upgrade one) process. ¿It will? -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 3 13:40:27 2010 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 75E9F106568B for ; Wed, 3 Feb 2010 13:40:27 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id 5CCD38FC0A for ; Wed, 3 Feb 2010 13:40:26 +0000 (UTC) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta08.emeryville.ca.mail.comcast.net with comcast id dRcV1d0030vp7WLA8RgTcQ; Wed, 03 Feb 2010 13:40:27 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta05.emeryville.ca.mail.comcast.net with comcast id dRgS1d00D3S48mS8RRgSh9; Wed, 03 Feb 2010 13:40:27 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 5D4021E3033; Wed, 3 Feb 2010 05:40:25 -0800 (PST) Date: Wed, 3 Feb 2010 05:40:25 -0800 From: Jeremy Chadwick To: Jordi Espasa Clofent Message-ID: <20100203134025.GA1787@icarus.home.lan> References: <4B696D0B.3070301@minibofh.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4B696D0B.3070301@minibofh.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Inmutable bit in some binaries 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, 03 Feb 2010 13:40:27 -0000 On Wed, Feb 03, 2010 at 01:33:15PM +0100, Jordi Espasa Clofent wrote: > HI all, > > I'm hardening one test box and at present I'm planning to do: > > # chflags -R schg > > where will be some binaries that seems to be common targets > for rootkits and lammers: > > ls > du > ps > find > top > locate > strings > ifconfig > netstat login > > I wonder if changing these files permissions as I've shown above > will be cause some troubles in future upgrade (recompilation, the > classic way, not the binary upgrade one) process. ¿It will? It's possible installworld will break (fail/exit) when trying to overwrite some of these binaries. However... install(1) supports the -f flags to specify what the destination file should have its file flags (chflags) set to, and from looking at the code (src/usr.bin/xinstall/xinstall.c), there are some places which indicate before copying/installing a file the software may attempt to unset file flags first. I'm not 100% familiar with this code, but it appears as if use of the -S flag to install(1) would cause it to behave like described. It should be easy enough for you to test. Otherwise, my recommendation is to build a test system / virtual box of some sort (VMware, etc.) and try it. See what happens. Opinion below: What you're attempting to solve, ultimately, is security through obscurity and gets you a very large headache. :-) Your schg idea would only work if you planned on using kern.securelevel=1 or higher. This sounds great in concept, but many a time on this list have people posted problems with system administrative tasks (re: upgrading) when this sysctl is set to non-default (-1). If you plan on using this, I would advocate *all* installation/work be done in single-user mode. I know quite a few people who completely ignore the "boot into single user" step of src/Makefile and instead do it in multi-user mode -- only to be found later screaming/crying when binaries don't work or behave oddly because, say, /libexec/ld-elf.so was supposed to be updated yet wasn't due to their choosing to not follow the proper procedure. If your system doesn't have an out-of-band method of getting to it (ex. serial console), then I wouldn't bother trying any of the above. Otherwise, I'm pretty sure others here have made use of read-only environments, such as read-only NFS root filesystems (sometimes accomplished via PXE) and/or /usr, or CD-based OS (good luck changing any files there). I can't help in that regard. -- | Jeremy Chadwick jdc@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 Feb 3 18:50:35 2010 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 DE2E91065676 for ; Wed, 3 Feb 2010 18:50:34 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by mx1.freebsd.org (Postfix) with ESMTP id 660D08FC13 for ; Wed, 3 Feb 2010 18:50:34 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id o13IoVn2032705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 Feb 2010 19:50:31 +0100 Received: from [192.168.100.200] (146.Red-83-37-87.dynamicIP.rima-tde.net [83.37.87.146]) (authenticated bits=0) by ackerman2.upc.es (8.13.8/8.13.8) with ESMTP id o13IoQQN027533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Feb 2010 19:50:31 +0100 Message-ID: <4B69C572.1020601@entel.upc.edu> Date: Wed, 03 Feb 2010 19:50:26 +0100 From: =?ISO-8859-1?Q?Gustau_P=E9rez?= User-Agent: Thunderbird 2.0.0.23 (X11/20100112) MIME-Version: 1.0 To: Mikolaj Golub References: <4B62C890.3020802@entel.upc.edu> <86ljfg7hl3.fsf@kopusha.onet> In-Reply-To: <86ljfg7hl3.fsf@kopusha.onet> X-Enigmail-Version: 0.95.7 X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.63 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Wed, 03 Feb 2010 19:50:32 +0100 (CET) Cc: freebsd-stable@freebsd.org Subject: Re: bsnmpd returns incorrect hrProcessorLoad values 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, 03 Feb 2010 18:50:35 -0000 En/na Mikolaj Golub ha escrit: > On Fri, 29 Jan 2010 12:37:52 +0100 Gustau Pérez wrote: > > >> Hi, >> >> I'm using cacti to monitor some servers running FBSD. I was using 7.2 >> with SCHED_4BSD. With this configuration : bsnmpd+bsnmp-ucd was >> returning right values for the cores' load. >> >> I recently updated the servers (via csup) to RELENG_8 and bsnmpd is >> returning negative values for the cores' load. If I try something like >> in a 4-core system : >> >> snmpwalk -v 2c -c community server .1.3.6.1.2.1.25.3.3.1 >> >> what I get is : >> >> .1.3.6.1.2.1.25.3.3.1.1.6 = OID: .0.0 >> .1.3.6.1.2.1.25.3.3.1.1.10 = OID: .0.0 >> .1.3.6.1.2.1.25.3.3.1.1.14 = OID: .0.0 >> .1.3.6.1.2.1.25.3.3.1.1.18 = OID: .0.0 >> .1.3.6.1.2.1.25.3.3.1.2.6 = INTEGER: -182 >> .1.3.6.1.2.1.25.3.3.1.2.10 = INTEGER: -182 >> .1.3.6.1.2.1.25.3.3.1.2.14 = INTEGER: -182 >> .1.3.6.1.2.1.25.3.3.1.2.18 = INTEGER: -182 >> >> I tried and old bsnmpd-ucd (0.2.1, works fine in a 7,2 system) with a >> 8.0 system. Same wrong results. And it seems bsnmpd in /usr/src/contrib >> has not changed between 7.2 and 8.0. >> >> Any ideas ? I'm not an expert, but with tcpdump I see different >> results. Against an old 7.2 system, the field related to each core load >> gives the right value. Instead, against and 8.0 system, those field show >> (in hex) values like fd 4b. What I don't know is how bsdnmp-ucb retrives >> those values and how it construct the udp response packet. >> > > bsnmpd-ucd has nothing to do with HOST-RESOURCES-MIB. These mibs are provided > by snmp_hostres(3) module (/usr/lib/snmp_hostres.so). So something wrong is > there (I suppose it is not in sync with some recent changes in kernel or > libkvm). > > You are right. I checked the usr.sbin/bsnmpd/modules/snmp_hostres/hostres_processor_tbl.c. I think it has something to do with the processor_getpcpu function (line 122). The code is : > if (ccpu == 0 || fscale == 0) > return (0.0); > > #define fxtofl(fixpt) ((double)(fixpt) / fscale) > return (100.0 * fxtofl(ki_p->ki_pctcpu) / > (1.0 - exp(ki_p->ki_swtime * log(fxtofl(ccpu))))); With 4 core SCHED_ULE system I checked it and ccpu is always 0 (sysctl kern.ccpu gives 0 too). So this routine always returns 0.0. That makes the save_sample routine to fill e->samples[#cpu] with 100. If I comment the ccpu ==0, the I see strange values. I know, I changed the code. With some printfs, I see the returned value when starting bsnmpd is 98~99. But the it goes up until 350~400 (strange). I put some others printfs and then I saw that when starting the daemon it return 98~99 for each processor and the ki_pctcpu is 2026 (in my case). Then, the next time bsnmpd refreshes its values I see it returns wrong values and ki_pctcpu goes up four times. So the function returns nearly 400% of idle time for each processor... So I checked it with SCHED_4BSD with an 8 core system. The same behaviour, but this time I got an increase of eight times for the ki_pctcpu. Now I'm stuck in here. I think the kinfo_proc info is obtained ny using kvm_getprocs. Do you have any idea why it returns those values ? Regards, Gus - -- PGP KEY : http://www-entel.upc.edu/gus/gus.asc From owner-freebsd-stable@FreeBSD.ORG Wed Feb 3 22:52:18 2010 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 562B31065672 for ; Wed, 3 Feb 2010 22:52:18 +0000 (UTC) (envelope-from mail@vas.org.ua) Received: from relay.electro.ua (electro.ua [213.186.192.234]) by mx1.freebsd.org (Postfix) with ESMTP id 0CECE8FC1D for ; Wed, 3 Feb 2010 22:52:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by relay.electro.ua (Postfix) with ESMTP id 4FC7F1708F for ; Thu, 4 Feb 2010 00:35:51 +0200 (EET) X-Virus-Scanned: amavisd-new at http.org.ua Received: from relay.electro.ua ([127.0.0.1]) by localhost (http.org.ua [127.0.0.1]) (amavisd-new, port 10024) with LMTP id r4-SN92lj22h for ; Thu, 4 Feb 2010 00:35:51 +0200 (EET) Received: from [192.168.1.100] (blonde.org.ua [213.186.192.244]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by relay.electro.ua (Postfix) with ESMTPSA id 1F3BC1708B for ; Thu, 4 Feb 2010 00:35:51 +0200 (EET) Message-ID: <4B69FA56.10308@vas.org.ua> Date: Thu, 04 Feb 2010 00:36:06 +0200 From: Vasyl Samoilov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; uk; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: messages output starts getting interleaved 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, 03 Feb 2010 22:52:18 -0000 Hello. After migrating to 8.0-STABLE from 7.2-STABLE my messages output starts getting interleaved (see below). I'm running amd64 smp kernel. Is there anything can be done to get rid of this? Thanks in advance. Feb 3 19:44:49 tiger named[989]: running Feb 3 19:44:50 tiger ntpd[1179]: ntpd 4.2.4p5-a (1) Feb 3 19:44:50 tiger dhcpd: Feb 3 19:44:50 tiger kernel: a Feb 3 19:44:50 tiger kernel: <1 Feb 3 19:44:50 tiger dhcpd: No subnet declaration for rl0 (193.200.85.132). Feb 3 19:44:50 tiger dhcpd: ** Ignoring requests on rl0. If this is not what Feb 3 19:44:50 tiger dhcpd: you want, please write a subnet declaration Feb 3 19:44:50 tiger kernel: <118<>Fe1b 31 8>S1e9n:di4n4g: 5o0n t i gSeorc kdehtc/pfadl:l b a c ky/ofua wlanlt,b palecask-e nwreitt Feb 3 19:44:50 tiger kernel: e Feb 3 19:44:50 tiger dhcpd: in your dhcpd.conf file for the network segment Feb 3 19:44:50 tiger dhcpd: to which interface rl0 is attached. ** Feb 3 19:44:50 tiger dhcpd: From owner-freebsd-stable@FreeBSD.ORG Wed Feb 3 22:52:57 2010 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 73DF51065694 for ; Wed, 3 Feb 2010 22:52:57 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from chen.org.nz (ip-58-28-152-174.static-xdsl.xnet.co.nz [58.28.152.174]) by mx1.freebsd.org (Postfix) with ESMTP id 1FDC58FC1A for ; Wed, 3 Feb 2010 22:52:56 +0000 (UTC) Received: by chen.org.nz (Postfix, from userid 1000) id 14AD2E043B; Thu, 4 Feb 2010 11:52:55 +1300 (NZDT) Date: Thu, 4 Feb 2010 11:52:55 +1300 From: Jonathan Chen To: Nikos Ntarmos Message-ID: <20100203225255.GB14315@osiris.chen.org.nz> References: <20100202193616.GA16953@osiris.chen.org.nz> <20100202212029.GA5295@asgard.cs.uoi.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100202212029.GA5295@asgard.cs.uoi.gr> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: if_bge upload stalls repeatedly (Was: 8-STABLE outgoing scp stalling frequently) 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, 03 Feb 2010 22:52:57 -0000 On Tue, Feb 02, 2010 at 11:20:29PM +0200, Nikos Ntarmos wrote: > On Wed, Feb 03, 2010 at 08:36:16AM +1300, Jonathan Chen wrote: > > Hi, > > > > I've noticed that on a recent 8-STABLE/amd64, scp(1) appears to be > > stalling very frequently. This is the output from a "scp -v -v" > > of a 300Mb file from a local to a remote within an internal network: [...] > > Does anyone know what's happening here? Any tips on how to track down > > what the problem is? The network config appears to be fine - fetch(1) will > > have downloads speeds of up to 300KB/s. > > But how about upload speeds? It seems that's where scp is suffering as > well. This is the obvious test that I should have done; and you're hit the nail on the head. bge(4) on 8-STABLE (csup'd 4-Feb-2010) has a very bad upload speed. I've just tried using ftp to transfer some files: Upload speed: starts at 63 KB/s, falls rapidly before stalling. Download speeds: starts at 9 MB/s, increasing slightly before completing. Device from dmesg: bge0: mem 0xf1bf0000-0xf1bfffff irq 17 at device 0.0 on pci9 -- Jonathan Chen ---------------------------------------------------------------------- "I don't want to achive immortality through my works.. I want to achieve it through not dying" - Woody Allen From owner-freebsd-stable@FreeBSD.ORG Thu Feb 4 01:26:24 2010 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 D6A68106566C for ; Thu, 4 Feb 2010 01:26:24 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id 86EE98FC18 for ; Thu, 4 Feb 2010 01:26:24 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so103123qwd.7 for ; Wed, 03 Feb 2010 17:26:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=n2uzdVU175gfaYvD5xMS9LLFMzRczE2dg88JkpfaChk=; b=Pix+Kr4/o5ACA0KohTv09a1Tuo6uBpnw9BX0u96utiU7YByN2e7lAzAqBEOOJXuSio +HqwU3MwFq2hdtL/QS7q4eZjPFzDRkxKzEcVLF0RY/7f3+Jm12wnR8CriQz9CJKum6OM JkmA3gsZW7veQUaVPGJB7E5hm7aiNjcfDyNbY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=dn+RsxWXeWAMHC/U1NUKwhQxS6/zoDPY7OLCDOtO99T+rrH93uVvPk2GqWS9oG04DK 0mGg19C9zae4QxeP/WhPDCbLKBBta/4DPV4sHD9IzkB6BoFjD4PsnC0PEbVsWWEKwhsB lMOOnvHplqoHNEVijhELsjRG01izF8NAV8Xfk= Received: by 10.224.11.211 with SMTP id u19mr3364956qau.108.1265246783888; Wed, 03 Feb 2010 17:26:23 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 5sm27739372qwg.38.2010.02.03.17.26.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 03 Feb 2010 17:26:22 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 3 Feb 2010 17:25:03 -0800 From: Pyun YongHyeon Date: Wed, 3 Feb 2010 17:25:03 -0800 To: Jonathan Chen Message-ID: <20100204012503.GK5901@michelle.cdnetworks.com> References: <20100202193616.GA16953@osiris.chen.org.nz> <20100202212029.GA5295@asgard.cs.uoi.gr> <20100203225255.GB14315@osiris.chen.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100203225255.GB14315@osiris.chen.org.nz> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: if_bge upload stalls repeatedly (Was: 8-STABLE outgoing scp stalling frequently) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 01:26:24 -0000 On Thu, Feb 04, 2010 at 11:52:55AM +1300, Jonathan Chen wrote: > On Tue, Feb 02, 2010 at 11:20:29PM +0200, Nikos Ntarmos wrote: > > On Wed, Feb 03, 2010 at 08:36:16AM +1300, Jonathan Chen wrote: > > > Hi, > > > > > > I've noticed that on a recent 8-STABLE/amd64, scp(1) appears to be > > > stalling very frequently. This is the output from a "scp -v -v" > > > of a 300Mb file from a local to a remote within an internal network: > > [...] > > > Does anyone know what's happening here? Any tips on how to track down > > > what the problem is? The network config appears to be fine - fetch(1) will > > > have downloads speeds of up to 300KB/s. > > > > But how about upload speeds? It seems that's where scp is suffering as > > well. > > This is the obvious test that I should have done; and you're hit the > nail on the head. bge(4) on 8-STABLE (csup'd 4-Feb-2010) has a very > bad upload speed. > > I've just tried using ftp to transfer some files: > > Upload speed: starts at 63 KB/s, falls rapidly before stalling. > Download speeds: starts at 9 MB/s, increasing slightly before completing. > I'm not sure but recently added code to support TSO may cause the issue. Would you show me verbose boot output(only bge(4) related one)? To rule out possible TSO issue, disable TSO and try it again(#ifconfig bge0 -tso). Does it make any difference? > Device from dmesg: > bge0: mem 0xf1bf0000-0xf1bfffff irq 17 at device 0.0 on pci9 > From owner-freebsd-stable@FreeBSD.ORG Thu Feb 4 02:00:19 2010 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 256AC1065676 for ; Thu, 4 Feb 2010 02:00:19 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from chen.org.nz (ip-58-28-152-174.static-xdsl.xnet.co.nz [58.28.152.174]) by mx1.freebsd.org (Postfix) with ESMTP id B1E108FC15 for ; Thu, 4 Feb 2010 02:00:18 +0000 (UTC) Received: by chen.org.nz (Postfix, from userid 1000) id D9EF0E043B; Thu, 4 Feb 2010 15:00:15 +1300 (NZDT) Date: Thu, 4 Feb 2010 15:00:15 +1300 From: Jonathan Chen To: Pyun YongHyeon Message-ID: <20100204020015.GA17301@osiris.chen.org.nz> References: <20100202193616.GA16953@osiris.chen.org.nz> <20100202212029.GA5295@asgard.cs.uoi.gr> <20100203225255.GB14315@osiris.chen.org.nz> <20100204012503.GK5901@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100204012503.GK5901@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: if_bge upload stalls repeatedly (Was: 8-STABLE outgoing scp stalling frequently) 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, 04 Feb 2010 02:00:19 -0000 On Wed, Feb 03, 2010 at 05:25:03PM -0800, Pyun YongHyeon wrote: > On Thu, Feb 04, 2010 at 11:52:55AM +1300, Jonathan Chen wrote: > > On Tue, Feb 02, 2010 at 11:20:29PM +0200, Nikos Ntarmos wrote: > > > On Wed, Feb 03, 2010 at 08:36:16AM +1300, Jonathan Chen wrote: > > > > Hi, > > > > > > > > I've noticed that on a recent 8-STABLE/amd64, scp(1) appears to be > > > > stalling very frequently. This is the output from a "scp -v -v" > > > > of a 300Mb file from a local to a remote within an internal network: > > > > [...] > > > > Does anyone know what's happening here? Any tips on how to track down > > > > what the problem is? The network config appears to be fine - fetch(1) will > > > > have downloads speeds of up to 300KB/s. > > > > > > But how about upload speeds? It seems that's where scp is suffering as > > > well. > > > > This is the obvious test that I should have done; and you're hit the > > nail on the head. bge(4) on 8-STABLE (csup'd 4-Feb-2010) has a very > > bad upload speed. > > > > I've just tried using ftp to transfer some files: > > > > Upload speed: starts at 63 KB/s, falls rapidly before stalling. > > Download speeds: starts at 9 MB/s, increasing slightly before completing. > I'm not sure but recently added code to support TSO may cause the > issue. Would you show me verbose boot output(only bge(4) related > one)? bge0: mem 0xf1bf0000-0xf1bfffff irq 17 at device 0.0 on pci9 bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xf1bf0000 bge0: adjust device control 0x2000 -> 0x5000 bge0: attempting to allocate 1 MSI vectors (1 supported) bge0: using IRQ 258 for MSI bge0: CHIP ID 0x0000a002; ASIC REV 0x0a; CHIP REV 0xa0; PCI-E bge0: Disabling fastboot bge0: Disabling fastboot miibus0: on bge0 bge0: bpf attached bge0: Ethernet address: 00:1d:09:d2:d1:9e bge0: [MPSAFE] bge0: [FILTER] bge0: Disabling fastboot bge0: Disabling fastboot bge0: link UP >To rule out possible TSO issue, disable TSO and try it > again(#ifconfig bge0 -tso). Does it make any difference? Yup, it sure does! With a TSO disabled, my upload and download speeds are pretty much symmetrical at a decent 10MB/s. Thanks! -- Jonathan Chen ---------------------------------------------------------------------- Do not take life too seriously. You will never get out of it alive. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 4 13:31:40 2010 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 0CF29106568B for ; Thu, 4 Feb 2010 13:31:40 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id CFD048FC14 for ; Thu, 4 Feb 2010 13:31:39 +0000 (UTC) Received: from compute2.internal (compute2.internal [10.202.2.42]) by gateway1.messagingengine.com (Postfix) with ESMTP id 3E699DC7A9 for ; Thu, 4 Feb 2010 08:31:39 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Thu, 04 Feb 2010 08:31:39 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpout; bh=5iwrJhRmv8wkRkYdP+KdSfhHmaQ=; b=Ol2kdSTAhYMmTaueXlFHXE/ibtW+uSKSFQ0bv9AEgnimczIRyZP551VyUeV8sUxV3VzbGaR65S2HyLRwbz/WvAdBKTQjyo51rxNSTZD2biGTGflBh84ereZZCMWac8Do9sgIUoSSrVoe6vDQSmBAKZTO03jlurfFxPAp+MqTKgA= X-Sasl-enc: DbS7eU9YpcW8BZsK4OCeXB8Fv07pzxiHojCRYDyidRyO 1265290298 Received: from anglepoise.lon.incunabulum.net (cpc2-dals7-0-0-cust253.hari.cable.virginmedia.com [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id C637D483A for ; Thu, 4 Feb 2010 08:31:38 -0500 (EST) Message-ID: <4B6ACC38.2030708@incunabulum.net> Date: Thu, 04 Feb 2010 13:31:36 +0000 From: Bruce Simpson User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100124 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4B685EBA.4020501@minibofh.org> <4B695A1A.1000505@incunabulum.net> <4B696360.3070209@minibofh.org> In-Reply-To: <4B696360.3070209@minibofh.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ionice in 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, 04 Feb 2010 13:31:40 -0000 On 02/03/10 11:52, Jordi Espasa Clofent wrote: > >> So I guess my question is, 'why do you need I/O scheduling, and what >> aspect of system performance are you trying to solve with it' ? > > > Some shell-scripts based on dd or rsync, for example. Even a daily > antivirus (ClamAV) scanner means an extensive I/O. > Even just renicing the processes should help here. The thread(s) will still be scheduled to run when they need running, although it will reduce the rate at which the process(es) involved can saturate the kernel with I/O requests. Currently the FreeBSD kernel doesn't really make a distinction between I/O transactions per process, because of how the unified VM buffer cache works. read() and write() are satisfied from VM; VFS will cause a vm_object to be created for each opened vnode, so read() will be satisfied by the same set of vm_page's as for mmap(). The vnode_pager's getpages() routine will eventually read into physical pages, using BIO requests (although it's usually the filesystem which actually does this). The net effect is that VFS shares its buffers with VM, and this does have some piecemeal benefit as the BIO subsystem will read from the physical medium in large chunks. It isn't impossible to account for I/O per-process. The Xen hypervisor has a similiar problem for per-domain I/O accounting. Currently, Domain 0 is responsible for block I/O, and it can be difficult for its scheduler to tell things apart for similar reasons. There have been previous research forks of FreeBSD to implement I/O scheduling; Eclipse/BSD from Bell Labs was one of them. It might be a good Google Summer of Code project for an interested computer science student. cheers, BMS From owner-freebsd-stable@FreeBSD.ORG Thu Feb 4 14:12:03 2010 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 31642106568B for ; Thu, 4 Feb 2010 14:12:03 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id EE1308FC13 for ; Thu, 4 Feb 2010 14:12:02 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 2DC7973106; Thu, 4 Feb 2010 15:20:45 +0100 (CET) Date: Thu, 4 Feb 2010 15:20:45 +0100 From: Luigi Rizzo To: Bruce Simpson Message-ID: <20100204142045.GA86101@onelab2.iet.unipi.it> References: <4B685EBA.4020501@minibofh.org> <4B695A1A.1000505@incunabulum.net> <4B696360.3070209@minibofh.org> <4B6ACC38.2030708@incunabulum.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B6ACC38.2030708@incunabulum.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: ionice in 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, 04 Feb 2010 14:12:03 -0000 On Thu, Feb 04, 2010 at 01:31:36PM +0000, Bruce Simpson wrote: > On 02/03/10 11:52, Jordi Espasa Clofent wrote: > > > >>So I guess my question is, 'why do you need I/O scheduling, and what > >>aspect of system performance are you trying to solve with it' ? ... > There have been previous research forks of FreeBSD to implement I/O > scheduling; Eclipse/BSD from Bell Labs was one of them. It might be a > good Google Summer of Code project for an interested computer science > student. there is actually some good and current code at http://info.iet.unipi.it/~luigi/FreeBSD/ http://info.iet.unipi.it/~luigi/FreeBSD/geom_sched-20090307.tgz hopefully should still be working on RELENG_7 as long as you refrain from removing the scheduler from a live mounted fs. I used it on RELENG_7, with minor changes should work on R8/HEAD, and I hope to come up with updated versions by the end of the month when i am done with the dummynet rewrite. cheers luigi From owner-freebsd-stable@FreeBSD.ORG Thu Feb 4 16:07:38 2010 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 8560310656A5 for ; Thu, 4 Feb 2010 16:07:38 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 10F758FC14 for ; Thu, 4 Feb 2010 16:07:37 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o14G7Knk019928; Thu, 4 Feb 2010 17:07:35 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o14G7KLC019927; Thu, 4 Feb 2010 17:07:20 +0100 (CET) (envelope-from olli) Date: Thu, 4 Feb 2010 17:07:20 +0100 (CET) Message-Id: <201002041607.o14G7KLC019927@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, mail@vas.org.ua In-Reply-To: <4B69FA56.10308@vas.org.ua> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (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]); Thu, 04 Feb 2010 17:07:36 +0100 (CET) Cc: Subject: Re: messages output starts getting interleaved X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, mail@vas.org.ua List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 16:07:38 -0000 Vasyl Samoilov wrote: > After migrating to 8.0-STABLE from 7.2-STABLE my messages output starts > getting interleaved (see below). I'm running amd64 smp kernel. Is there > anything can be done to get rid of this? Thanks in advance. Do you have the following line in your kernel configuration? (It's in GENERIC by default.) options PRINTF_BUFR_SIZE=128 It mitigates the problem, but doesn't solve it completely. 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 Perl is worse than Python because people wanted it worse. -- Larry Wall From owner-freebsd-stable@FreeBSD.ORG Thu Feb 4 19:00:25 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id A32861065696 for ; Thu, 4 Feb 2010 19:00:25 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from xps.daemonology.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with SMTP id 20BC6151238 for ; Thu, 4 Feb 2010 19:00:25 +0000 (UTC) Received: (qmail 46680 invoked from network); 4 Feb 2010 19:00:24 -0000 Received: from unknown (HELO xps.daemonology.net) (127.0.0.1) by localhost with SMTP; 4 Feb 2010 19:00:24 -0000 Message-ID: <4B6B1948.4040408@freebsd.org> Date: Thu, 04 Feb 2010 11:00:24 -0800 From: FreeBSD Security Officer Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.23 (X11/20091215) MIME-Version: 1.0 To: freebsd security , FreeBSD Stable X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: FreeBSD supported branches update X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: security-officer@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, 04 Feb 2010 19:00:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Everyone, The branches supported by the FreeBSD Security Officer have been updated to reflect the EoL (end-of-life) of FreeBSD 6.3. The new list is below and at . Users of FreeBSD 6.3 are advised to upgrade promptly to a newer release, either by downloading an updated source tree and building updates manually, or (for i386 and amd64 systems) using the FreeBSD Update utility as described in the relevant release announcement. [Excerpt from http://security.freebsd.org/ follows] FreeBSD Security Advisories The FreeBSD Security Officer provides security advisories for several branches of FreeBSD development. These are the -STABLE Branches and the Security Branches. (Advisories are not issued for the -CURRENT Branch.) * The -STABLE branch tags have names like RELENG_7. The corresponding builds have names like FreeBSD 7.0-STABLE. * Each FreeBSD Release has an associated Security Branch. The Security Branch tags have names like RELENG_7_0. The corresponding builds have names like FreeBSD 7.0-RELEASE-p1. Isses affecting the FreeBSD Ports Collection are covered in the FreeBSD VuXML document. Each branch is supported by the Security Officer for a limited time only, and is designated as one of `Early adopter', `Normal', or `Extended'. The designation is used as a guideline for determining the lifetime of the branch as follows. Early adopter Releases which are published from the -CURRENT branch will be supported by the Security Officer for a minimum of 6 months after the release. Normal Releases which are published from a -STABLE branch will be supported by the Security Officer for a minimum of 12 months after the release, and for sufficient additional time (if needed) to ensure that there is a newer release for at least 3 months before the older Normal release expires. Extended Selected releases (normally every second release plus the last release from each -STABLE branch) will be supported by the Security Officer for a minimum of 24 months after the release, and for sufficient additional time (if needed) to ensure that there is a newer Extended release for at least 3 months before the older Extended release expires. The current designation and estimated lifetimes of the currently supported branches are given below. The Estimated EoL (end-of-life) column gives the earliest date on which that branch is likely to be dropped. Please note that these dates may be extended into the future, but only extenuating circumstances would lead to a branch's support being dropped earlier than the date listed. +--------------------------------------------------------------------+ | Branch | Release | Type | Release date | Estimated EoL | |-----------+-----------+--------+-----------------+-----------------| |RELENG_6 |n/a |n/a |n/a |November 30, 2010| |-----------+-----------+--------+-----------------+-----------------| |RELENG_6_4 |6.4-RELEASE|Extended|November 28, 2008|November 30, 2010| |-----------+-----------+--------+-----------------+-----------------| |RELENG_7 |n/a |n/a |n/a |last release + 2y| |-----------+-----------+--------+-----------------+-----------------| |RELENG_7_1 |7.1-RELEASE|Extended|January 4, 2009 |January 31, 2011 | |-----------+-----------+--------+-----------------+-----------------| |RELENG_7_2 |7.2-RELEASE|Normal |May 4, 2009 |May 31, 2010 | |-----------+-----------+--------+-----------------+-----------------| |RELENG_8 |n/a |n/a |n/a |last release + 2y| |-----------+-----------+--------+-----------------+-----------------| |RELENG_8_0 |8.0-RELEASE|Extended|November 25, 2009|November 30, 2010| +--------------------------------------------------------------------+ [End excerpt] The upcoming FreeBSD 7.3-RELEASE will receive Extended support, i.e., it will be supported until early 2012. - -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktrGFwACgkQFdaIBMps37JxjACfcgWacpfcPj94zP4NtsvF6rWp TiUAmwbfcPuFiKaSsZvxkncYo/DNXzpm =yIFR -----END PGP SIGNATURE----- -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid From owner-freebsd-stable@FreeBSD.ORG Thu Feb 4 19:24:38 2010 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 BCFA0106566C for ; Thu, 4 Feb 2010 19:24:38 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 68FD58FC1A for ; Thu, 4 Feb 2010 19:24:38 +0000 (UTC) Received: by vws11 with SMTP id 11so1347945vws.13 for ; Thu, 04 Feb 2010 11:24:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=NWqPExEbLdR7lPzLhMgxRT5+S49+w2/5d4XfAjJ35WE=; b=Gt/eklK7Hl+qzSzhaU9Gtzjujr+kBswcF21P+4Bgn/CRk3ut0jGVrs7PPPKXnMRH2P KX85E8uDBuGGJgP77hXToQRgThj6C4I7hrSA6csgOgG+PBNdjhyrnv0njb4gGcZEIw1W NG6zM8JhY4XYvKYOKKJ8hNwE62zprWtlNAnLw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=JRSksw0+N/wAAB026/ZR7UgGGuSlGex6oqXV0DCkkr5aeCQvLZ9/ER8ZFVbECOaQeT dg+8zAPJvwm9mANui6ATowtTLNliddnXh+9nlK+k9PmZBOzjZAXJ5kEP5iy+z1jcu216 WZwEUCEzWTlTdYTZqUEfyJAHCvmnYDb5bzcw4= Received: by 10.220.127.97 with SMTP id f33mr2817822vcs.47.1265311477588; Thu, 04 Feb 2010 11:24:37 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 24sm3594983vws.13.2010.02.04.11.24.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 04 Feb 2010 11:24:36 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 4 Feb 2010 11:23:15 -0800 From: Pyun YongHyeon Date: Thu, 4 Feb 2010 11:23:15 -0800 To: Jonathan Chen Message-ID: <20100204192315.GN5901@michelle.cdnetworks.com> References: <20100202193616.GA16953@osiris.chen.org.nz> <20100202212029.GA5295@asgard.cs.uoi.gr> <20100203225255.GB14315@osiris.chen.org.nz> <20100204012503.GK5901@michelle.cdnetworks.com> <20100204020015.GA17301@osiris.chen.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100204020015.GA17301@osiris.chen.org.nz> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: if_bge upload stalls repeatedly (Was: 8-STABLE outgoing scp stalling frequently) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 19:24:38 -0000 On Thu, Feb 04, 2010 at 03:00:15PM +1300, Jonathan Chen wrote: > On Wed, Feb 03, 2010 at 05:25:03PM -0800, Pyun YongHyeon wrote: > > On Thu, Feb 04, 2010 at 11:52:55AM +1300, Jonathan Chen wrote: > > > On Tue, Feb 02, 2010 at 11:20:29PM +0200, Nikos Ntarmos wrote: > > > > On Wed, Feb 03, 2010 at 08:36:16AM +1300, Jonathan Chen wrote: > > > > > Hi, > > > > > > > > > > I've noticed that on a recent 8-STABLE/amd64, scp(1) appears to be > > > > > stalling very frequently. This is the output from a "scp -v -v" > > > > > of a 300Mb file from a local to a remote within an internal network: > > > > > > [...] > > > > > Does anyone know what's happening here? Any tips on how to track down > > > > > what the problem is? The network config appears to be fine - fetch(1) will > > > > > have downloads speeds of up to 300KB/s. > > > > > > > > But how about upload speeds? It seems that's where scp is suffering as > > > > well. > > > > > > This is the obvious test that I should have done; and you're hit the > > > nail on the head. bge(4) on 8-STABLE (csup'd 4-Feb-2010) has a very > > > bad upload speed. > > > > > > I've just tried using ftp to transfer some files: > > > > > > Upload speed: starts at 63 KB/s, falls rapidly before stalling. > > > Download speeds: starts at 9 MB/s, increasing slightly before completing. > > I'm not sure but recently added code to support TSO may cause the > > issue. Would you show me verbose boot output(only bge(4) related > > one)? > > bge0: mem 0xf1bf0000-0xf1bfffff irq 17 at device 0.0 on pci9 > bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xf1bf0000 > bge0: adjust device control 0x2000 -> 0x5000 > bge0: attempting to allocate 1 MSI vectors (1 supported) > bge0: using IRQ 258 for MSI > bge0: CHIP ID 0x0000a002; ASIC REV 0x0a; CHIP REV 0xa0; PCI-E > bge0: Disabling fastboot > bge0: Disabling fastboot > miibus0: on bge0 > bge0: bpf attached > bge0: Ethernet address: 00:1d:09:d2:d1:9e > bge0: [MPSAFE] > bge0: [FILTER] > bge0: Disabling fastboot > bge0: Disabling fastboot > bge0: link UP > > >To rule out possible TSO issue, disable TSO and try it > > again(#ifconfig bge0 -tso). Does it make any difference? > > Yup, it sure does! With a TSO disabled, my upload and download speeds > are pretty much symmetrical at a decent 10MB/s. > Hmm, that means TSO was broken on your controller. Because BCM5755 or newer controllers have no known TSO issues I don't know why the controller fails on TSO. Very recent controllers use new TSO format but I don't think your controller is one of them and FreeBSD has no support for these controllers anyway. Would you show me the output of "pciconf -lcv" of your bge(4) controller? From owner-freebsd-stable@FreeBSD.ORG Thu Feb 4 21:31:40 2010 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 62697106566C for ; Thu, 4 Feb 2010 21:31:40 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from chen.org.nz (ip-58-28-152-174.static-xdsl.xnet.co.nz [58.28.152.174]) by mx1.freebsd.org (Postfix) with ESMTP id ECBC08FC19 for ; Thu, 4 Feb 2010 21:31:39 +0000 (UTC) Received: by chen.org.nz (Postfix, from userid 1000) id 71512E0452; Fri, 5 Feb 2010 10:31:37 +1300 (NZDT) Date: Fri, 5 Feb 2010 10:31:37 +1300 From: Jonathan Chen To: Pyun YongHyeon Message-ID: <20100204213137.GA9431@osiris.chen.org.nz> References: <20100202193616.GA16953@osiris.chen.org.nz> <20100202212029.GA5295@asgard.cs.uoi.gr> <20100203225255.GB14315@osiris.chen.org.nz> <20100204012503.GK5901@michelle.cdnetworks.com> <20100204020015.GA17301@osiris.chen.org.nz> <20100204192315.GN5901@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100204192315.GN5901@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: if_bge upload stalls repeatedly (Was: 8-STABLE outgoing scp stalling frequently) 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, 04 Feb 2010 21:31:40 -0000 On Thu, Feb 04, 2010 at 11:23:15AM -0800, Pyun YongHyeon wrote: > On Thu, Feb 04, 2010 at 03:00:15PM +1300, Jonathan Chen wrote: > > On Wed, Feb 03, 2010 at 05:25:03PM -0800, Pyun YongHyeon wrote: [...] > > > I'm not sure but recently added code to support TSO may cause the > > > issue. Would you show me verbose boot output(only bge(4) related > > > one)? > > > > bge0: mem 0xf1bf0000-0xf1bfffff irq 17 at device 0.0 on pci9 > > bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xf1bf0000 > > bge0: adjust device control 0x2000 -> 0x5000 > > bge0: attempting to allocate 1 MSI vectors (1 supported) > > bge0: using IRQ 258 for MSI > > bge0: CHIP ID 0x0000a002; ASIC REV 0x0a; CHIP REV 0xa0; PCI-E > > bge0: Disabling fastboot > > bge0: Disabling fastboot > > miibus0: on bge0 > > bge0: bpf attached > > bge0: Ethernet address: 00:1d:09:d2:d1:9e > > bge0: [MPSAFE] > > bge0: [FILTER] > > bge0: Disabling fastboot > > bge0: Disabling fastboot > > bge0: link UP > > > > >To rule out possible TSO issue, disable TSO and try it > > > again(#ifconfig bge0 -tso). Does it make any difference? > > > > Yup, it sure does! With a TSO disabled, my upload and download speeds > > are pretty much symmetrical at a decent 10MB/s. > > > > Hmm, that means TSO was broken on your controller. Because BCM5755 > or newer controllers have no known TSO issues I don't know why the > controller fails on TSO. Very recent controllers use new TSO format > but I don't think your controller is one of them and FreeBSD has no > support for these controllers anyway. > Would you show me the output of "pciconf -lcv" of your bge(4) > controller? bge0@pci0:9:0:0: class=0x020000 card=0x01fe1028 chip=0x167314e4 rev=0x02 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme BCM5755M Gigabit Ethernet PCIe' class = network subclass = ethernet cap 01[48] = powerspec 3 supports D0 D3 current D0 cap 03[50] = VPD cap 09[58] = vendor (length 120) cap 05[e8] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[d0] = PCI-Express 1 endpoint max data 128(128) link x1(x1) This is on a Dell Latitude D830 Laptop. Cheers. -- Jonathan Chen ---------------------------------------------------------------------- "Beer. Now there's a temporary solution." - Homer Simpson From owner-freebsd-stable@FreeBSD.ORG Thu Feb 4 22:22:13 2010 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 7A7E8106566B for ; Thu, 4 Feb 2010 22:22:13 +0000 (UTC) (envelope-from mail@vas.org.ua) Received: from relay.electro.ua (electro.ua [213.186.192.234]) by mx1.freebsd.org (Postfix) with ESMTP id 2F6C18FC18 for ; Thu, 4 Feb 2010 22:22:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by relay.electro.ua (Postfix) with ESMTP id 2BE001708F for ; Fri, 5 Feb 2010 00:22:12 +0200 (EET) X-Virus-Scanned: amavisd-new at http.org.ua Received: from relay.electro.ua ([127.0.0.1]) by localhost (http.org.ua [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qxUzNdRfplC0 for ; Fri, 5 Feb 2010 00:22:12 +0200 (EET) Received: from [192.168.1.100] (blonde.org.ua [213.186.192.244]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by relay.electro.ua (Postfix) with ESMTPSA id 024EB1708B for ; Fri, 5 Feb 2010 00:22:12 +0200 (EET) Message-ID: <4B6B489E.9030309@vas.org.ua> Date: Fri, 05 Feb 2010 00:22:22 +0200 From: Vasyl Samoilov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; uk; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <201002041607.o14G7KLC019927@lurza.secnetix.de> In-Reply-To: <201002041607.o14G7KLC019927@lurza.secnetix.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: messages output starts getting interleaved 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, 04 Feb 2010 22:22:13 -0000 04.02.2010 18:07, Oliver Fromme напиÑав(ла): > Vasyl Samoilov wrote: > > After migrating to 8.0-STABLE from 7.2-STABLE my messages output starts > > getting interleaved (see below). I'm running amd64 smp kernel. Is there > > anything can be done to get rid of this? Thanks in advance. > > Do you have the following line in your kernel configuration? > (It's in GENERIC by default.) > > options PRINTF_BUFR_SIZE=128 > > It mitigates the problem, but doesn't solve it completely. > > Best regards > Oliver > > Yes, I do, but the problem seems to be somewhere else. It seems that this garbage in /var/log/messages comes in only when isc-dhcpd is starting. It's always some message from "kernel" with garbage in between dhcpd messages on every reboot - it shouldn't be there. >uname -a FreeBSD tiger.local.domain 8.0-STABLE FreeBSD 8.0-STABLE #1: Tue Feb 2 10:04:02 EET 2010 vas@tiger.local.domain:/usr/obj/usr/src/sys/GENERIC amd64 >cat /usr/src/sys/amd64/conf/GENERIC | grep PRINTF_BUFR_SIZE options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed. >pkg_info | grep dhcp isc-dhcp31-server-3.1.3 The ISC Dynamic Host Configuration Protocol server From owner-freebsd-stable@FreeBSD.ORG Thu Feb 4 22:43:00 2010 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 5A4D4106566C for ; Thu, 4 Feb 2010 22:43:00 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9B8E78FC19 for ; Thu, 4 Feb 2010 22:42:59 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA02344; Fri, 05 Feb 2010 00:40:24 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1NdAN6-0004Mh-IL; Fri, 05 Feb 2010 00:40:24 +0200 Message-ID: <4B6B4CD8.8060208@icyb.net.ua> Date: Fri, 05 Feb 2010 00:40:24 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091128) MIME-Version: 1.0 To: Peter Jeremy References: <20100201085131.GA34006@server.vk2pj.dyndns.org> <4B66A0DD.2070109@icyb.net.ua> <20100202063635.GA64643@server.vk2pj.dyndns.org> <4B67C8A6.5050102@icyb.net.ua> <20100202230511.GA19744@pjdesk.au.alcatel-lucent.com> In-Reply-To: <20100202230511.GA19744@pjdesk.au.alcatel-lucent.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Kernel probe order issues 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, 04 Feb 2010 22:43:00 -0000 on 03/02/2010 01:05 Peter Jeremy said the following: > Sorry. The box is a Dell GX620 (P4 with ICH7 chipset). The keyboard > is a Dell SK-8115 connected directly to a motherboard port. I've also > tried a Dell SK-8135 (which is the "multimedia" variant and has a > builtin hub) which behaves the same. > > I've uploaded full details as follows: > FreeBSD 7.x verbose dmesg: http://pastebin.ca/1776339 > FreeBSD 8.x verbose dmesg: http://pastebin.ca/1776359 > "pciconf -lv" (same in 7 & 8): http://pastebin.ca/1776363 Peter, thank you for the very detailed data. Unfortunately, I don't see any explanation for what you are experiencing. I came up with some things with which you can try to experiment: 1. Boot with hw.pci.usb_early_takeover="0" in loader.conf. 2. Comment out the following line in sys/dev/usb/controller/uhci_pci.c: pci_write_config(self, PCI_LEGSUP, PCI_LEGSUP_USBPIRQDEN, 2); -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Feb 4 22:46:12 2010 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 81B401065695; Thu, 4 Feb 2010 22:46:12 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5919A8FC1E; Thu, 4 Feb 2010 22:46:11 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA02408; Fri, 05 Feb 2010 00:46:07 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1NdASd-0004N1-2x; Fri, 05 Feb 2010 00:46:07 +0200 Message-ID: <4B6B4E2E.2010902@icyb.net.ua> Date: Fri, 05 Feb 2010 00:46:06 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091128) MIME-Version: 1.0 To: Stephane LAPIE References: <4B682972.6030604@darkbsd.org> <4B682F29.90505@icyb.net.ua> <4B686324.2090308@elischer.org> <4B68641D.9000201@icyb.net.ua> <4B695CA3.50008@darkbsd.org> In-Reply-To: <4B695CA3.50008@darkbsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org, Julian Elischer , freebsd-hardware@freebsd.org Subject: Re: [zfs][hardware] Reproducible kernel panic in 8.0-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: Thu, 04 Feb 2010 22:46:12 -0000 on 03/02/2010 13:23 Stephane LAPIE said the following: > > I just rebuilt a kernel with debugger options, and obtained the > following output upon pulling out one disk : > > Sleeping thread (tid 100024, pid 0) owns a non-sleepable lock > sched_switch() at sched_switch+0xf8 > mi_switch() at mi_switch+0x16f > sleepq_timedwait() at sleepq_timedwait+0x42 > _cv_timedwait() at _cv_timedwait+0x129 > _sema_timedwait() at _sema_timedwait+0x55 > ata_queue_request() at ata_queue_request+0x526 > ata_controlcmd() at ata_controlcmd+0xa1 > ata_setmode() at ata_setmode+0xdc > ad_init() at ad_init+0x27 > ad_reinit() at ad_reinit+0x48 > ata_reinit() at ata_reinit+0x268 > ata_conn_event() at ata_conn_event+0x49 > taskqueue_run() at taskqueue_run+0x93 > taskqueue_thread_loop() at taskqueue_thread_loop+0x46 > fork_exit() at fork_exit+0x118 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff80000aad30, rbp = 0 --- > panic: sleeping thread > cpuid = 2 > KDB: enter: panic > [thread pid 12 tid 100008 ] > Stopped at kdb_enter+0x3d: movq $0,0x4943d0(%rip) Not sure if I can derive anything useful from here. Someone with more expertise is needed. One thing I noticed is that ata_conn_event and ata_reinit and some other functions up the stack acquire state_mtx recursively, but the mutex is not initialized with MTX_RECURSE. Perhaps, indeed you would have a better luck with AHCI controller _and_ ahci(4) driver. It seems to handle dynamic coming and going of disks much better than ata(4). -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Feb 5 01:16:11 2010 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 DA9E1106568B for ; Fri, 5 Feb 2010 01:16:11 +0000 (UTC) (envelope-from amesbury@umn.edu) Received: from mta-w3.tc.umn.edu (mta-w3.tc.umn.edu [134.84.119.32]) by mx1.freebsd.org (Postfix) with ESMTP id 9A4E38FC13 for ; Fri, 5 Feb 2010 01:16:11 +0000 (UTC) Received: from optimator.oitsec.umn.edu (optimator.oitsec.umn.edu [160.94.247.212]) by mta-w3.tc.umn.edu (UMN smtpd) with ESMTP for ; Thu, 4 Feb 2010 19:01:10 -0600 (CST) X-Umn-Remote-Mta: [N] optimator.oitsec.umn.edu [160.94.247.212] #+LO+TS+AU X-Umn-Classification: local Message-ID: <4B6B6DD5.10008@umn.edu> Date: Thu, 04 Feb 2010 19:01:09 -0600 From: Alan Amesbury User-Agent: Thunderbird 2.0.0.23 (X11/20100123) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Inmutable bit in some binaries 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, 05 Feb 2010 01:16:12 -0000 Jeremy Chadwick said: > It's possible installworld will break (fail/exit) when trying to > overwrite some of these binaries. However... It will totally break installworld where installworld tries to replace the file. Been there, done that, and have the collector's edition soundtrack. [snip] > What you're attempting to solve, ultimately, is security through > obscurity and gets you a very large headache. :-) Your schg idea would > only work if you planned on using kern.securelevel=1 or higher. This > sounds great in concept, but many a time on this list have people posted > problems with system administrative tasks (re: upgrading) when this > sysctl is set to non-default (-1). I run at kern.securelevel=2 on most hosts at work and home. The only problems I've encountered are a) you can't do an installworld reliably (but see below!) b) buildworld sometimes fails c) X and other devices that use /dev/io break Workstation-class hosts don't use securelevel specifically because of "c". I don't need X on my servers so it doesn't get installed; no problems there. > If you plan on using this, I would advocate *all* installation/work be > done in single-user mode. I know quite a few people who completely > ignore the "boot into single user" step of src/Makefile and instead do > it in multi-user mode -- only to be found later screaming/crying when [snip] 100% agreement! I admit to occasionally taking shortcuts on this, but the majority of the time installworld and mergemaster are done in single-user. Every time I've had a problem with installworld while *not* doing this could be attributed to trying to do it in multi-user. The fact that buildworld will only *sometimes* fail in multi-user with kern.securelevel=2 is something that I consider to be a bug in the buildworld process, but not one serious enough that I've dug into it to find the root cause. The failure is almost always when attempting to touch the SSH binaries that show up under /usr/obj during the build; schg gets set on those at some point... but, again, I haven't bothered to figure out when or how. In those instances, I'm willing to reboot with securelevel disabled, do my work, then enable it again when I'm finished. This seems to work well. The only problems I see with applying schg and friends to other files is that it will complicate your upgrades. I suspect it's doable, though, provided you keep track of which files you're modifying. Then you can remove the flags prior to an upgrade, let buildworld/installworld do its thing, and reapply them when the work's complete. It's possible that mtree(8) might be very useful for documenting this sort of thing. > Otherwise, I'm pretty sure others here have made use of read-only > environments, such as read-only NFS root filesystems (sometimes > accomplished via PXE) and/or /usr, or CD-based OS (good luck changing > any files there). I can't help in that regard. Actually, sysutils/ezjail puts together a pretty nice framework that makes use of what's effectively a read-only OS with other things overlaid on top of it. That might work as an example, if one's needed. -- Alan Amesbury OIT Security and Assurance University of Minnesota From owner-freebsd-stable@FreeBSD.ORG Fri Feb 5 02:51:15 2010 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 3A0C61065676 for ; Fri, 5 Feb 2010 02:51:15 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.freebsd.org (Postfix) with ESMTP id D58EE8FC17 for ; Fri, 5 Feb 2010 02:51:14 +0000 (UTC) Received: from vampire.homelinux.org (dslb-088-064-184-208.pools.arcor-ip.net [88.64.184.208]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0M1kWE-1Ns13C3ckc-00t1iK; Fri, 05 Feb 2010 03:51:13 +0100 Received: (qmail 64812 invoked from network); 5 Feb 2010 02:51:12 -0000 Received: from f8x64.laiers.local (192.168.4.188) by mx.laiers.local with SMTP; 5 Feb 2010 02:51:12 -0000 From: Max Laier Organization: FreeBSD To: freebsd-stable@freebsd.org Date: Fri, 5 Feb 2010 03:51:12 +0100 User-Agent: KMail/1.12.4 (FreeBSD/8.0-RELEASE-p2; KDE/4.3.4; amd64; ; ) References: <147432021001310037n1b67f01bx4b4e8781321cea8@mail.gmail.com> <2a41acea1002021443t1c298528i2df3cf40269c733@mail.gmail.com> <2a41acea1002021447t1067ee42gc59b25216270459b@mail.gmail.com> In-Reply-To: <2a41acea1002021447t1067ee42gc59b25216270459b@mail.gmail.com> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_ge4aL9vBl3gxbuc" Message-Id: <201002050351.12270.max@love2party.net> X-Provags-ID: V01U2FsdGVkX18Lr9EKfEyHrmgm+Xvkd+/3WI1cPcrAHDSsGiA w/XNL/djQ1x/aBmZfbPmx7JhcJEnkl9Q/LfqldKviX8CUQ7Q4X Wsb+wxFOTUKiiXP/9Hfpg== Cc: pyunyh@gmail.com, Nick Rogers , jfv@freebsd.org, Jack Vogel Subject: Re: em(4) + ALTQ broken 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, 05 Feb 2010 02:51:15 -0000 --Boundary-00=_ge4aL9vBl3gxbuc Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Okay ... attached is a patch to fix this for em(4) (and lay the groundwork to fix it for other drbr_* consumer as well). I have tested it in VirtualBox, but don't have real hardware to check for non-ALTQ performance or other regressions. Test, comments and review appreciated. -- Max --Boundary-00=_ge4aL9vBl3gxbuc Content-Type: text/x-patch; charset="ISO-8859-1"; name="drbr_altq.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="drbr_altq.diff" Index: sys/dev/e1000/if_em.c =================================================================== --- sys/dev/e1000/if_em.c (revision 203362) +++ sys/dev/e1000/if_em.c (working copy) @@ -943,7 +943,7 @@ { struct adapter *adapter = ifp->if_softc; struct mbuf *next; - int error = E1000_SUCCESS; + int ret, error = E1000_SUCCESS; EM_TX_LOCK_ASSERT(adapter); /* To allow being called from a tasklet */ @@ -955,28 +955,34 @@ || (!adapter->link_active)) { error = drbr_enqueue(ifp, adapter->br, m); return (error); - } else if (drbr_empty(ifp, adapter->br) && - (adapter->num_tx_desc_avail > EM_TX_OP_THRESHOLD)) { - if ((error = em_xmit(adapter, &m)) != 0) { - if (m) - error = drbr_enqueue(ifp, adapter->br, m); + } + ret = drbr_maybe_enqueue(ifp, adapter->br, m); + if (ret == 0) { + if (adapter->num_tx_desc_avail > EM_TX_OP_THRESHOLD) { + if ((error = em_xmit(adapter, &m)) != 0) { + if (m) + error = drbr_enqueue(ifp, adapter->br, + m); + return (error); + } else { + /* + * We've bypassed the buf ring so we need to + * update ifp directly + */ + drbr_stats_update(ifp, m->m_pkthdr.len, + m->m_flags); + /* + ** Send a copy of the frame to the BPF + ** listener and set the watchdog on. + */ + ETHER_BPF_MTAP(ifp, m); + adapter->watchdog_check = TRUE; + } + } else if ((error = drbr_enqueue(ifp, adapter->br, m)) != 0) return (error); - } else { - /* - * We've bypassed the buf ring so we need to update - * ifp directly - */ - drbr_stats_update(ifp, m->m_pkthdr.len, m->m_flags); - /* - ** Send a copy of the frame to the BPF - ** listener and set the watchdog on. - */ - ETHER_BPF_MTAP(ifp, m); - adapter->watchdog_check = TRUE; - } - } else if ((error = drbr_enqueue(ifp, adapter->br, m)) != 0) - return (error); - + } else if (ret < 0) + return (-ret); + process: if (drbr_empty(ifp, adapter->br)) return(error); @@ -989,7 +995,7 @@ break; if ((error = em_xmit(adapter, &next)) != 0) { if (next != NULL) - error = drbr_enqueue(ifp, adapter->br, next); + error = drbr_requeue(ifp, adapter->br, next); break; } drbr_stats_update(ifp, next->m_pkthdr.len, next->m_flags); Index: sys/net/if_var.h =================================================================== --- sys/net/if_var.h (revision 203362) +++ sys/net/if_var.h (working copy) @@ -597,18 +597,26 @@ return (error); } +static __inline int +drbr_requeue(struct ifnet *ifp, struct buf_ring *br, struct mbuf *m) +{ +#ifdef ALTQ + if (ALTQ_IS_ENABLED(&ifp->if_snd)) { + IFQ_DRV_PREPEND(&ifp->if_snd, m); + return (0); + } +#endif + return drbr_enqueue(ifp, br, m); +} + static __inline void drbr_flush(struct ifnet *ifp, struct buf_ring *br) { struct mbuf *m; #ifdef ALTQ - if (ifp != NULL && ALTQ_IS_ENABLED(&ifp->if_snd)) { - while (!IFQ_IS_EMPTY(&ifp->if_snd)) { - IFQ_DRV_DEQUEUE(&ifp->if_snd, m); - m_freem(m); - } - } + if (ifp != NULL && ALTQ_IS_ENABLED(&ifp->if_snd)) + IFQ_DRV_PURGE(&ifp->if_snd); #endif while ((m = buf_ring_dequeue_sc(br)) != NULL) m_freem(m); @@ -642,11 +650,12 @@ { struct mbuf *m; #ifdef ALTQ - /* - * XXX need to evaluate / requeue - */ if (ALTQ_IS_ENABLED(&ifp->if_snd)) { IFQ_DRV_DEQUEUE(&ifp->if_snd, m); + if (m != NULL && func(m, arg) == 0) { + IFQ_DRV_PREPEND(&ifp->if_snd, m); + return (NULL); + } return (m); } #endif @@ -668,6 +677,24 @@ } static __inline int +drbr_maybe_enqueue(struct ifnet *ifp, struct buf_ring *br, struct mbuf *m) +{ + int error; + +#ifdef ALTQ + if (ALTQ_IS_ENABLED(&ifp->if_snd)) { + IFQ_ENQUEUE(&ifp->if_snd, m, error); + return error ? -error : 1; + } +#endif + if (drbr_empty(ifp, br)) + return 0; + + error = drbr_enqueue(ifp, br, m); + return error ? -error : 1; +} + +static __inline int drbr_inuse(struct ifnet *ifp, struct buf_ring *br) { #ifdef ALTQ --Boundary-00=_ge4aL9vBl3gxbuc Content-Type: text/x-patch; charset="ISO-8859-1"; name="drbr_altq.stable_8.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="drbr_altq.stable_8.diff" diff --git a/sys/dev/e1000/if_em.c b/sys/dev/e1000/if_em.c index 7a2dbad..94ad229 100644 --- a/sys/dev/e1000/if_em.c +++ b/sys/dev/e1000/if_em.c @@ -1020,7 +1020,7 @@ em_mq_start_locked(struct ifnet *ifp, struct mbuf *m) { struct adapter *adapter = ifp->if_softc; struct mbuf *next; - int error = E1000_SUCCESS; + int ret, error = E1000_SUCCESS; EM_TX_LOCK_ASSERT(adapter); /* To allow being called from a tasklet */ @@ -1032,28 +1032,34 @@ em_mq_start_locked(struct ifnet *ifp, struct mbuf *m) || (!adapter->link_active)) { error = drbr_enqueue(ifp, adapter->br, m); return (error); - } else if (drbr_empty(ifp, adapter->br) && - (adapter->num_tx_desc_avail > EM_TX_OP_THRESHOLD)) { - if ((error = em_xmit(adapter, &m)) != 0) { - if (m != NULL) - error = drbr_enqueue(ifp, adapter->br, m); - return (error); - } else { - /* - * We've bypassed the buf ring so we need to update - * ifp directly - */ - drbr_stats_update(ifp, m->m_pkthdr.len, m->m_flags); - /* - ** Send a copy of the frame to the BPF - ** listener and set the watchdog on. - */ - ETHER_BPF_MTAP(ifp, m); - adapter->watchdog_timer = EM_TX_TIMEOUT; - } - } else if ((error = drbr_enqueue(ifp, adapter->br, m)) != 0) - return (error); - + } + ret = drbr_maybe_enqueue(ifp, adapter->br, m); + if (ret == 0) { + if (adapter->num_tx_desc_avail > EM_TX_OP_THRESHOLD) { + if ((error = em_xmit(adapter, &m)) != 0) { + if (m) + error = drbr_enqueue(ifp, adapter->br, + m); + return (error); + } else { + /* + * We've bypassed the buf ring so we need to + * update ifp directly + */ + drbr_stats_update(ifp, m->m_pkthdr.len, + m->m_flags); + /* + ** Send a copy of the frame to the BPF + ** listener and set the watchdog on. + */ + ETHER_BPF_MTAP(ifp, m); + adapter->watchdog_timer = EM_TX_TIMEOUT; + } + } else if ((error = drbr_enqueue(ifp, adapter->br, m)) != 0) + return (error); + } else if (ret < 0) + return (-ret); + process: if (drbr_empty(ifp, adapter->br)) return(error); @@ -1066,7 +1072,7 @@ process: break; if ((error = em_xmit(adapter, &next)) != 0) { if (next != NULL) - error = drbr_enqueue(ifp, adapter->br, next); + error = drbr_requeue(ifp, adapter->br, next); break; } drbr_stats_update(ifp, next->m_pkthdr.len, next->m_flags); diff --git a/sys/net/if_var.h b/sys/net/if_var.h index eac7dbf..1d59402 100644 --- a/sys/net/if_var.h +++ b/sys/net/if_var.h @@ -595,18 +595,26 @@ drbr_enqueue(struct ifnet *ifp, struct buf_ring *br, struct mbuf *m) return (error); } +static __inline int +drbr_requeue(struct ifnet *ifp, struct buf_ring *br, struct mbuf *m) +{ +#ifdef ALTQ + if (ALTQ_IS_ENABLED(&ifp->if_snd)) { + IFQ_DRV_PREPEND(&ifp->if_snd, m); + return (0); + } +#endif + return drbr_enqueue(ifp, br, m); +} + static __inline void drbr_flush(struct ifnet *ifp, struct buf_ring *br) { struct mbuf *m; #ifdef ALTQ - if (ifp != NULL && ALTQ_IS_ENABLED(&ifp->if_snd)) { - while (!IFQ_IS_EMPTY(&ifp->if_snd)) { - IFQ_DRV_DEQUEUE(&ifp->if_snd, m); - m_freem(m); - } - } + if (ifp != NULL && ALTQ_IS_ENABLED(&ifp->if_snd)) + IFQ_DRV_PURGE(&ifp->if_snd); #endif while ((m = buf_ring_dequeue_sc(br)) != NULL) m_freem(m); @@ -640,11 +648,12 @@ drbr_dequeue_cond(struct ifnet *ifp, struct buf_ring *br, { struct mbuf *m; #ifdef ALTQ - /* - * XXX need to evaluate / requeue - */ if (ALTQ_IS_ENABLED(&ifp->if_snd)) { IFQ_DRV_DEQUEUE(&ifp->if_snd, m); + if (m != NULL && func(m, arg) == 0) { + IFQ_DRV_PREPEND(&ifp->if_snd, m); + return (NULL); + } return (m); } #endif @@ -666,6 +675,24 @@ drbr_empty(struct ifnet *ifp, struct buf_ring *br) } static __inline int +drbr_maybe_enqueue(struct ifnet *ifp, struct buf_ring *br, struct mbuf *m) +{ + int error; + +#ifdef ALTQ + if (ALTQ_IS_ENABLED(&ifp->if_snd)) { + IFQ_ENQUEUE(&ifp->if_snd, m, error); + return error ? -error : 1; + } +#endif + if (drbr_empty(ifp, br)) + return 0; + + error = drbr_enqueue(ifp, br, m); + return error ? -error : 1; +} + +static __inline int drbr_inuse(struct ifnet *ifp, struct buf_ring *br) { #ifdef ALTQ --Boundary-00=_ge4aL9vBl3gxbuc-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 5 03:17:14 2010 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 8241B106566C for ; Fri, 5 Feb 2010 03:17:14 +0000 (UTC) (envelope-from tmclaugh@sdf.lonestar.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 673848FC16 for ; Fri, 5 Feb 2010 03:17:14 +0000 (UTC) Received: from straycat.dhs.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o153HCM2093279 for ; Fri, 5 Feb 2010 03:17:12 GMT (envelope-from tmclaugh@sdf.lonestar.org) Received: from tomcat.straycat.dhs.org (tomcat.straycat.dhs.org [192.168.2.213]) by straycat.dhs.org (8.14.1/8.14.1) with ESMTP id o1530tpE016496 for ; Thu, 4 Feb 2010 22:00:55 -0500 (EST) Message-ID: <4B6B89E7.8030002@sdf.lonestar.org> Date: Thu, 04 Feb 2010 22:00:55 -0500 From: Tom McLaughlin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-stable X-Enigmail-Version: 1.0 Content-Type: multipart/mixed; boundary="------------070707080408080604010100" Subject: Recent MFC to 7 causes crash on VMware ESXi 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, 05 Feb 2010 03:17:14 -0000 This is a multi-part message in MIME format. --------------070707080408080604010100 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi all, a recent MFC to 7-STABLE has started to cause issues for my VMs on VMware ESXi 3.5u4. After loading the mpt driver for the LSI disk controller the VM just shuts off. The workaround is to change the disk controller to the BusLogic type. Still, it used to work up until last week. The change was made around January 26th and based on the commits that day I'm guessing it's either r203047 or r203073 I have the same issue with both amd64 and i386 VMs. This affects HEAD and 8-STABLE as well and first affected HEAD over the summer. (I just worked around it and went about my business at the time. :-/) I've attached a dmesg from a kernel before the problem and one from after it started. tom -- | tmclaugh at sdf.lonestar.org tmclaugh at FreeBSD.org | | FreeBSD http://www.FreeBSD.org | --------------070707080408080604010100 Content-Type: text/plain; name="freebsd-72-amd64-r202734.dmesg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="freebsd-72-amd64-r202734.dmesg" U01BUCB0eXBlPTAxIGJhc2U9MDAwMDAwMDAwMDAwMDAwMCBsZW49MDAwMDAwMDAwMDA5Zjgw MApTTUFQIHR5cGU9MDIgYmFzZT0wMDAwMDAwMDAwMDlmODAwIGxlbj0wMDAwMDAwMDAwMDAw ODAwClNNQVAgdHlwZT0wMiBiYXNlPTAwMDAwMDAwMDAwY2EwMDAgbGVuPTAwMDAwMDAwMDAw MDIwMDAKU01BUCB0eXBlPTAyIGJhc2U9MDAwMDAwMDAwMDBkYzAwMCBsZW49MDAwMDAwMDAw MDAyNDAwMApTTUFQIHR5cGU9MDEgYmFzZT0wMDAwMDAwMDAwMTAwMDAwIGxlbj0wMDAwMDAw MDFmZGYwMDAwClNNQVAgdHlwZT0wMyBiYXNlPTAwMDAwMDAwMWZlZjAwMDAgbGVuPTAwMDAw MDAwMDAwMGYwMDAKU01BUCB0eXBlPTA0IGJhc2U9MDAwMDAwMDAxZmVmZjAwMCBsZW49MDAw MDAwMDAwMDAwMTAwMApTTUFQIHR5cGU9MDEgYmFzZT0wMDAwMDAwMDFmZjAwMDAwIGxlbj0w MDAwMDAwMDAwMTAwMDAwClNNQVAgdHlwZT0wMiBiYXNlPTAwMDAwMDAwZmVjMDAwMDAgbGVu PTAwMDAwMDAwMDAwMTAwMDAKU01BUCB0eXBlPTAyIGJhc2U9MDAwMDAwMDBmZWUwMDAwMCBs ZW49MDAwMDAwMDAwMDAwMTAwMApTTUFQIHR5cGU9MDIgYmFzZT0wMDAwMDAwMGZmZmUwMDAw IGxlbj0wMDAwMDAwMDAwMDIwMDAwCkNvcHlyaWdodCAoYykgMTk5Mi0yMDEwIFRoZSBGcmVl QlNEIFByb2plY3QuCkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4 OCwgMTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NAoJVGhlIFJlZ2VudHMgb2YgdGhlIFVu aXZlcnNpdHkgb2YgQ2FsaWZvcm5pYS4gQWxsIHJpZ2h0cyByZXNlcnZlZC4KRnJlZUJTRCBp cyBhIHJlZ2lzdGVyZWQgdHJhZGVtYXJrIG9mIFRoZSBGcmVlQlNEIEZvdW5kYXRpb24uCkZy ZWVCU0QgNy4yLVNUQUJMRSAjNCByMjAyNzM0OiBUdWUgRmViICAyIDEzOjQxOjQyIEVTVCAy MDEwCiAgICB0b21AZnJlZWJzZC03Mi1hbWQ2NC5zdHJheWNhdC5kaHMub3JnOi91c3Ivb2Jq L3Vzci9zcmMvc3lzL0dFTkVSSUMgYW1kNjQKUHJlbG9hZGVkIGVsZiBrZXJuZWwgIi9ib290 L2tlcm5lbC9rZXJuZWwiIGF0IDB4ZmZmZmZmZmY4MGQwNzAwMC4KQ2FsaWJyYXRpbmcgY2xv Y2socykgLi4uIGk4MjU0IGNsb2NrOiAxMTg1NzUxIEh6CkNMS19VU0VfSTgyNTRfQ0FMSUJS QVRJT04gbm90IHNwZWNpZmllZCAtIHVzaW5nIGRlZmF1bHQgZnJlcXVlbmN5ClRpbWVjb3Vu dGVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVhbGl0eSAwCkNhbGlicmF0aW5n IFRTQyBjbG9jayAuLi4gVFNDIGNsb2NrOiAyMjEyMzQ5ODAzIEh6CkNQVTogRHVhbC1Db3Jl IEFNRCBPcHRlcm9uKHRtKSBQcm9jZXNzb3IgMTIxNCAoMjIxMi4zNS1NSHogSzgtY2xhc3Mg Q1BVKQogIE9yaWdpbiA9ICJBdXRoZW50aWNBTUQiICBJZCA9IDB4NDBmMzMgIFN0ZXBwaW5n ID0gMwogIEZlYXR1cmVzPTB4NzhiZmJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxN Q0UsQ1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQU0UzNixDTEZMVVNILE1N WCxGWFNSLFNTRSxTU0UyPgogIEZlYXR1cmVzMj0weDIwMDE8U1NFMyxDWDE2PgogIEFNRCBG ZWF0dXJlcz0weGVhNTAwODAwPFNZU0NBTEwsTlgsTU1YKyxGRlhTUixSRFRTQ1AsTE0sM0RO b3chKywzRE5vdyE+CiAgQU1EIEZlYXR1cmVzMj0weDk8TEFIRixFeHRBUElDPgpMMSAyTUIg ZGF0YSBUTEI6IDggZW50cmllcywgZnVsbHkgYXNzb2NpYXRpdmUKTDEgMk1CIGluc3RydWN0 aW9uIFRMQjogOCBlbnRyaWVzLCBmdWxseSBhc3NvY2lhdGl2ZQpMMSA0S0IgZGF0YSBUTEI6 IDMyIGVudHJpZXMsIGZ1bGx5IGFzc29jaWF0aXZlCkwxIDRLQiBpbnN0cnVjdGlvbiBUTEI6 IDMyIGVudHJpZXMsIGZ1bGx5IGFzc29jaWF0aXZlCkwxIGRhdGEgY2FjaGU6IDY0IGtieXRl cywgNjQgYnl0ZXMvbGluZSwgMSBsaW5lcy90YWcsIDItd2F5IGFzc29jaWF0aXZlCkwxIGlu c3RydWN0aW9uIGNhY2hlOiA2NCBrYnl0ZXMsIDY0IGJ5dGVzL2xpbmUsIDEgbGluZXMvdGFn LCAyLXdheSBhc3NvY2lhdGl2ZQpMMiAyTUIgdW5pZmllZCBUTEI6IDAgZW50cmllcywgZGlz YWJsZWQvbm90IHByZXNlbnQKTDIgNEtCIGRhdGEgVExCOiA1MTIgZW50cmllcywgNC13YXkg YXNzb2NpYXRpdmUKTDIgNEtCIGluc3RydWN0aW9uIFRMQjogNTEyIGVudHJpZXMsIDQtd2F5 IGFzc29jaWF0aXZlCkwyIHVuaWZpZWQgY2FjaGU6IDEwMjQga2J5dGVzLCA2NCBieXRlcy9s aW5lLCAxIGxpbmVzL3RhZywgMTYtd2F5IGFzc29jaWF0aXZlCnVzYWJsZSBtZW1vcnkgPSA1 MjM1OTU3NzYgKDQ5OSBNQikKUGh5c2ljYWwgbWVtb3J5IGNodW5rKHMpOgoweDAwMDAwMDAw MDAwMDEwMDAgLSAweDAwMDAwMDAwMDAwOWJmZmYsIDYzNDg4MCBieXRlcyAoMTU1IHBhZ2Vz KQoweDAwMDAwMDAwMDBkMzQwMDAgLSAweDAwMDAwMDAwMWVmYjdmZmYsIDUwNTk1NDMwNCBi eXRlcyAoMTIzNTI0IHBhZ2VzKQoweDAwMDAwMDAwMWZmMDAwMDAgLSAweDAwMDAwMDAwMWZm ZWZmZmYsIDk4MzA0MCBieXRlcyAoMjQwIHBhZ2VzKQphdmFpbCBtZW1vcnkgID0gNTAyNzk2 Mjg4ICg0NzkgTUIpCkFDUEkgQVBJQyBUYWJsZTogPFBUTFREICAJIEFQSUMgID4KQVBJQzog Q1BVIDAgaGFzIEFDUEkgSUQgMApVTEU6IHNldHVwIGNwdSBncm91cCAwClVMRTogc2V0dXAg Y3B1IDAKVUxFOiBhZGRpbmcgY3B1IDAgdG8gZ3JvdXAgMDogY3B1cyAxIG1hc2sgMHgxCkFD UEk6IFJTRFAgQCAweDB4ZjZjNjAvMHgwMDE0ICh2ICAwIFBUTFREICkKQUNQSTogUlNEVCBA IDB4MHgxZmVmYWI2OC8weDAwMzAgKHYgIDEgUFRMVEQgICAgUlNEVCAgIDB4MDYwNDAwMDAg IExUUCAweDAwMDAwMDAwKQpBQ1BJOiBGQUNQIEAgMHgweDFmZWZlZjE0LzB4MDA3NCAodiAg MSBJTlRFTCAgNDQwQlggICAgMHgwNjA0MDAwMCBQVEwgIDB4MDAwRjQyNDApCkFDUEk6IERT RFQgQCAweDB4MWZlZmFiOTgvMHg0MzdDICh2ICAxIFBUTFREICBDdXN0b20gICAweDA2MDQw MDAwIE1TRlQgMHgwMTAwMDAwRCkKQUNQSTogRkFDUyBAIDB4MHgxZmVmZmZjMC8weDAwNDAK QUNQSTogQVBJQyBAIDB4MHgxZmVmZWY4OC8weDAwNTAgKHYgIDEgUFRMVEQgIAkgQVBJQyAg IDB4MDYwNDAwMDAgIExUUCAweDAwMDAwMDAwKQpBQ1BJOiBCT09UIEAgMHgweDFmZWZlZmQ4 LzB4MDAyOCAodiAgMSBQVExURCAgJFNCRlRCTCQgMHgwNjA0MDAwMCAgTFRQIDB4MDAwMDAw MDEpCk1BRFQ6IEZvdW5kIElPIEFQSUMgSUQgMSwgSW50ZXJydXB0IDAgYXQgMHhmZWMwMDAw MAppb2FwaWMwOiBSb3V0aW5nIGV4dGVybmFsIDgyNTlBJ3MgLT4gaW50cGluIDAKTUFEVDog SW50ZXJydXB0IG92ZXJyaWRlOiBzb3VyY2UgMCwgaXJxIDIKaW9hcGljMDogUm91dGluZyBJ UlEgMCAtPiBpbnRwaW4gMgpsYXBpYzA6IFJvdXRpbmcgTk1JIC0+IExJTlQxCmxhcGljMDog TElOVDEgdHJpZ2dlcjogZWRnZQpsYXBpYzA6IExJTlQxIHBvbGFyaXR5OiBoaWdoCk1BRFQ6 IEZvcmNpbmcgYWN0aXZlLWxvdyBwb2xhcml0eSBhbmQgbGV2ZWwgdHJpZ2dlciBmb3IgU0NJ CmlvYXBpYzA6IGludHBpbiA5IHBvbGFyaXR5OiBsb3cKaW9hcGljMDogaW50cGluIDkgdHJp Z2dlcjogbGV2ZWwKaW9hcGljMCA8VmVyc2lvbiAxLjE+IGlycXMgMC0yMyBvbiBtb3RoZXJi b2FyZApjcHUwIEJTUDoKICAgICBJRDogMHgwMDAwMDAwMCAgIFZFUjogMHg4MDA0MDAxMSBM RFI6IDB4MDAwMDAwMDAgREZSOiAweGZmZmZmZmZmCiAgbGludDA6IDB4MDAwMTA3MDAgbGlu dDE6IDB4MDAwMDA0MDAgVFBSOiAweDAwMDAwMDAwIFNWUjogMHgwMDAwMDFmZgogIHRpbWVy OiAweDAwMDEwMGVmIHRoZXJtOiAweDAwMDEwMDAwIGVycjogMHgwMDAxMDAwMCBwY206IDB4 MDAwMTA0MDAKd2xhbjogPDgwMi4xMSBMaW5rIExheWVyPgp3bGFuX2FtcnI6IDxBTVJSIFRy YW5zbWl0IFJhdGUgQ29udHJvbCBBbGdvcml0aG0+Cm51bGw6IDxudWxsIGRldmljZSwgemVy byBkZXZpY2U+CnJhbmRvbTogPGVudHJvcHkgc291cmNlLCBTb2Z0d2FyZSwgWWFycm93Pgpu ZnNsb2NrOiBwc2V1ZG8tZGV2aWNlCmtiZDogbmV3IGFycmF5IHNpemUgNAprYmQxIGF0IGti ZG11eDAKbWVtOiA8bWVtb3J5PgppbzogPEkvTz4KaHB0cnI6IFJvY2tldFJBSUQgMTd4eC8y eHh4IFNBVEEgY29udHJvbGxlciBkcml2ZXIgdjEuMiAoRmViICAyIDIwMTAgMTM6NDE6MzAp CmFjcGkwOiA8UFRMVEQgICBSU0RUPiBvbiBtb3RoZXJib2FyZAppb2FwaWMwOiByb3V0aW5n IGludHBpbiA5IChJU0EgSVJRIDkpIHRvIHZlY3RvciA0OAphY3BpMDogW01QU0FGRV0KYWNw aTA6IFtJVEhSRUFEXQpBY3BpT3NEZXJpdmVQY2lJZDogXF9TQl8uUENJMC5QV1JfLlBDSV8g LT4gYnVzIDAgZGV2IDcgZnVuYyAzCmFjcGkwOiBQb3dlciBCdXR0b24gKGZpeGVkKQpBY3Bp T3NEZXJpdmVQY2lJZDogXF9TQl8uUENJMC5SRUdTIC0+IGJ1cyAwIGRldiAwIGZ1bmMgMApB Y3BpT3NEZXJpdmVQY2lJZDogXF9TQl8uUENJMC5JU0FfLlBJUlggLT4gYnVzIDAgZGV2IDcg ZnVuYyAwCkFDUEkgdGltZXI6IDAvNzYgMC8zODggMC8xNyAwLzE1IDAvMTI2NSAwLzQ3IDAv ODkxIDAvMTUgMC8zMiAwLzMzNiAtPiAwClRpbWVjb3VudGVyICJBQ1BJLXNhZmUiIGZyZXF1 ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgODUwCmFjcGlfdGltZXIwOiA8MjQtYml0IHRpbWVy IGF0IDMuNTc5NTQ1TUh6PiBwb3J0IDB4MTAwOC0weDEwMGIgb24gYWNwaTAKcGNpX2xpbmsw OiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAg ICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDE0IDE1CiAgVmFsaWRh dGlvbiAgICAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxNCAx NQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkg MTAgMTEgMTQgMTUKcGNpX2xpbmsxOiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElS UXMKICBJbml0aWFsIFByb2JlICAgICAgIDAgICAgOSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5 IDEwIDExIDE0IDE1CiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAgIDkgICBOICAgICAwICAz IDQgNSA2IDcgOSAxMCAxMSAxNCAxNQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAg TiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTQgMTUKcGNpX2xpbmsyOiAgICAgICAgSW5k ZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAgIDAgICAxMSAg IE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDE0IDE1CiAgVmFsaWRhdGlvbiAgICAgICAg ICAwICAgMTEgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxNCAxNQogIEFmdGVyIERp c2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTQgMTUK cGNpX2xpbmszOiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFs IFByb2JlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDE0IDE1 CiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA2IDcgOSAx MCAxMSAxNCAxNQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0 IDUgNiA3IDkgMTAgMTEgMTQgMTUKcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gcG9y dCAweGNmOC0weGNmZiBvbiBhY3BpMApwY2kwOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMApw Y2kwOiBkb21haW49MCwgcGh5c2ljYWwgYnVzPTAKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBk ZXY9MHg3MTkwLCByZXZpZD0weDAxCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MCwgZnVuYz0w CgljbGFzcz0wNi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA2 LCBzdGF0cmVnPTB4MDIxMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAg KDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+ CXZlbmRvcj0weDgwODYsIGRldj0weDcxOTEsIHJldmlkPTB4MDEKCWRvbWFpbj0wLCBidXM9 MCwgc2xvdD0xLCBmdW5jPTAKCWNsYXNzPTA2LTA0LTAwLCBoZHJ0eXBlPTB4MDEsIG1mZGV2 PTAKCWNtZHJlZz0weDAxMWYsIHN0YXRyZWc9MHgwMjIwLCBjYWNoZWxuc3o9MCAoZHdvcmRz KQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDg0ICgzMzAwMCBucyksIG1heGxh dD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDcxMTAsIHJldmlk PTB4MDgKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD03LCBmdW5jPTAKCWNsYXNzPTA2LTAxLTAw LCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMjgw LCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0w eDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4ODA4Niwg ZGV2PTB4NzExMSwgcmV2aWQ9MHgwMQoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTcsIGZ1bmM9 MQoJY2xhc3M9MDEtMDEtOGEsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAw NSwgc3RhdHJlZz0weDAyODAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDQw ICgxOTIwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCW1h cFsyMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4MTA1MCwgc2l6ZSAgNCwg ZW5hYmxlZApmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDcxMTMsIHJldmlkPTB4MDgK CWRvbWFpbj0wLCBidXM9MCwgc2xvdD03LCBmdW5jPTMKCWNsYXNzPTA2LTgwLTAwLCBoZHJ0 eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDEsIHN0YXRyZWc9MHgwMjgwLCBjYWNo ZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgw IG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCgltYXBbOTBdOiB0eXBlIEkvTyBQb3J0LCByYW5n ZSAzMiwgYmFzZSAweDEwNDAsIHNpemUgIDQsIGVuYWJsZWQKZm91bmQtPgl2ZW5kb3I9MHgx NWFkLCBkZXY9MHgwNDA1LCByZXZpZD0weDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MTUs IGZ1bmM9MAoJY2xhc3M9MDMtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVn PTB4MDAwMywgc3RhdHJlZz0weDAyODAsIGNhY2hlbG5zej04IChkd29yZHMpCglsYXR0aW1l cj0weDQwICgxOTIwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBu cykKCW1hcFsxMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4MTA2MCwgc2l6 ZSAgNCwgZW5hYmxlZAoJbWFwWzE0XTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4 ZjgwMDAwMDAsIHNpemUgMjYsIGVuYWJsZWQKCW1hcFsxOF06IHR5cGUgTWVtb3J5LCByYW5n ZSAzMiwgYmFzZSAweGY0MDAwMDAwLCBzaXplIDIzLCBlbmFibGVkCmZvdW5kLT4JdmVuZG9y PTB4MTAwMCwgZGV2PTB4MDAzMCwgcmV2aWQ9MHgwMQoJZG9tYWluPTAsIGJ1cz0wLCBzbG90 PTE2LCBmdW5jPTAKCWNsYXNzPTAxLTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNt ZHJlZz0weDAwMDMsIHN0YXRyZWc9MHgwMjgwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0 dGltZXI9MHg0MCAoMTkyMCBucyksIG1pbmdudD0weDA2ICgxNTAwIG5zKSwgbWF4bGF0PTB4 ZmYgKDYzNzUwIG5zKQoJaW50cGluPWEsIGlycT05CgltYXBbMTBdOiB0eXBlIEkvTyBQb3J0 LCByYW5nZSAzMiwgYmFzZSAweDEwODAsIHNpemUgIDcsIGVuYWJsZWQKCW1hcFsxNF06IHR5 cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGY0ODEwMDAwLCBzaXplIDEyLCBlbmFibGVk CnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjE2LklOVEEKcGNpYjA6IHNsb3QgMTYgSU5U QSBoYXJkd2lyZWQgdG8gSVJRIDE3CmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MTAw ZiwgcmV2aWQ9MHgwMQoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTE3LCBmdW5jPTAKCWNsYXNz PTAyLTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAxMTMsIHN0YXRy ZWc9MHgwMjMwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMp LCBtaW5nbnQ9MHhmZiAoNjM3NTAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1h LCBpcnE9MTEKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJbWFw WzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4ZjQ4MjAwMDAsIHNpemUgMTcs IGVuYWJsZWQKCW1hcFsxOF06IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGY0ODAw MDAwLCBzaXplIDE2LCBlbmFibGVkCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAz MiwgYmFzZSAweDE0MDAsIHNpemUgIDYsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkg Zm9yIDAuMTcuSU5UQQpwY2liMDogc2xvdCAxNyBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMTgK cGNpYjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMS4wIG9uIHBjaTAKcGNp YjE6ICAgZG9tYWluICAgICAgICAgICAgMApwY2liMTogICBzZWNvbmRhcnkgYnVzICAgICAx CnBjaWIxOiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDEKcGNpYjE6ICAgSS9PIGRlY29kZSAgICAg ICAgMHhmMDAwLTB4ZmZmCnBjaWIxOiAgIG5vIHByZWZldGNoZWQgZGVjb2RlCnBjaWIxOiBj b3VsZCBub3QgZ2V0IFBDSSBpbnRlcnJ1cHQgcm91dGluZyB0YWJsZSBmb3IgXF9TQl8uUENJ MC5BR1BfIC0gQUVfTk9UX0ZPVU5ECnBjaTE6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIxCnBj aTE6IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9MQppc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBh dCBkZXZpY2UgNy4wIG9uIHBjaTAKaXNhMDogPElTQSBidXM+IG9uIGlzYWIwCmF0YXBjaTA6 IDxJbnRlbCBQSUlYNCBVRE1BMzMgY29udHJvbGxlcj4gcG9ydCAweDFmMC0weDFmNywweDNm NiwweDE3MC0weDE3NywweDM3NiwweDEwNTAtMHgxMDVmIGF0IGRldmljZSA3LjEgb24gcGNp MAphdGFwY2kwOiBSZXNlcnZlZCAweDEwIGJ5dGVzIGZvciByaWQgMHgyMCB0eXBlIDQgYXQg MHgxMDUwCmF0YTA6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kwCmF0YXBjaTA6IFJlc2Vy dmVkIDB4OCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSA0IGF0IDB4MWYwCmF0YXBjaTA6IFJl c2VydmVkIDB4MSBieXRlcyBmb3IgcmlkIDB4MTQgdHlwZSA0IGF0IDB4M2Y2CmF0YTA6IHJl c2V0IHRwMSBtYXNrPTAxIG9zdGF0MD01MCBvc3RhdDE9ZmYKYXRhMDogc3RhdDA9MHgwMCBl cnI9MHgwMSBsc2I9MHgxNCBtc2I9MHhlYgphdGEwOiByZXNldCB0cDIgc3RhdDA9MDAgc3Rh dDE9MDAgZGV2aWNlcz0weDQ8QVRBUElfTUFTVEVSPgppb2FwaWMwOiByb3V0aW5nIGludHBp biAxNCAoSVNBIElSUSAxNCkgdG8gdmVjdG9yIDQ5CmF0YTA6IFtNUFNBRkVdCmF0YTA6IFtJ VEhSRUFEXQphdGExOiA8QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpMAphdGFwY2kwOiBSZXNl cnZlZCAweDggYnl0ZXMgZm9yIHJpZCAweDE4IHR5cGUgNCBhdCAweDE3MAphdGFwY2kwOiBS ZXNlcnZlZCAweDEgYnl0ZXMgZm9yIHJpZCAweDFjIHR5cGUgNCBhdCAweDM3NgphdGExOiBy ZXNldCB0cDEgbWFzaz0wMCBvc3RhdDA9ZmYgb3N0YXQxPWZmCmlvYXBpYzA6IHJvdXRpbmcg aW50cGluIDE1IChJU0EgSVJRIDE1KSB0byB2ZWN0b3IgNTAKYXRhMTogW01QU0FGRV0KYXRh MTogW0lUSFJFQURdCnBjaTA6IDxicmlkZ2U+IGF0IGRldmljZSA3LjMgKG5vIGRyaXZlciBh dHRhY2hlZCkKdmdhcGNpMDogPFZHQS1jb21wYXRpYmxlIGRpc3BsYXk+IHBvcnQgMHgxMDYw LTB4MTA2ZiBtZW0gMHhmODAwMDAwMC0weGZiZmZmZmZmLDB4ZjQwMDAwMDAtMHhmNDdmZmZm ZiBhdCBkZXZpY2UgMTUuMCBvbiBwY2kwCm1wdDA6IDxMU0lMb2dpYyAxMDMwIFVsdHJhNCBB ZGFwdGVyPiBwb3J0IDB4MTA4MC0weDEwZmYgbWVtIDB4ZjQ4MTAwMDAtMHhmNDgxMGZmZiBp cnEgMTcgYXQgZGV2aWNlIDE2LjAgb24gcGNpMAptcHQwOiBSZXNlcnZlZCAweDgwIGJ5dGVz IGZvciByaWQgMHgxMCB0eXBlIDQgYXQgMHgxMDgwCm1wdDA6IFJlc2VydmVkIDB4MTAwMCBi eXRlcyBmb3IgcmlkIDB4MTQgdHlwZSAzIGF0IDB4ZjQ4MTAwMDAKaW9hcGljMDogcm91dGlu ZyBpbnRwaW4gMTcgKFBDSSBJUlEgMTcpIHRvIHZlY3RvciA1MQptcHQwOiBbTVBTQUZFXQpt cHQwOiBbSVRIUkVBRF0KbXB0MDogTVBJIFZlcnNpb249MS4yLjAuMAptcHQwOiBObyBIYW5k bGVycyBGb3IgQW55IEV2ZW50IE5vdGlmeSBGcmFtZXMuIEV2ZW50IDB4YSAoQUNLIG5vdCBy ZXF1aXJlZCkuCmVtMDogPEludGVsKFIpIFBSTy8xMDAwIE5ldHdvcmsgQ29ubmVjdGlvbiA2 LjkuNj4gcG9ydCAweDE0MDAtMHgxNDNmIG1lbSAweGY0ODIwMDAwLTB4ZjQ4M2ZmZmYsMHhm NDgwMDAwMC0weGY0ODBmZmZmIGlycSAxOCBhdCBkZXZpY2UgMTcuMCBvbiBwY2kwCmVtMDog TWVtb3J5IEFjY2VzcyBhbmQvb3IgQnVzIE1hc3RlciBiaXRzIHdlcmUgbm90IHNldCEKZW0w OiBSZXNlcnZlZCAweDIwMDAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMgYXQgMHhmNDgy MDAwMAplbTA6IFJlc2VydmVkIDB4NDAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5cGUgNCBhdCAw eDE0MDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMTggKFBDSSBJUlEgMTgpIHRvIHZlY3Rv ciA1MgplbTA6IFtGSUxURVJdCmVtMDogYnBmIGF0dGFjaGVkCmVtMDogRXRoZXJuZXQgYWRk cmVzczogMDA6MGM6Mjk6ZWU6YmQ6ZTkKZW0wOiBMaW5rIGlzIHVwIDEwMDAgTWJwcyBGdWxs IER1cGxleAphY3BpX2FjYWQwOiA8QUMgQWRhcHRlcj4gb24gYWNwaTAKYXRrYmRjMDogPEtl eWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gcG9ydCAweDYwLDB4NjQgaXJxIDEgb24gYWNw aTAKYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzAKYXRrYmQ6IHRoZSBj dXJyZW50IGtiZCBjb250cm9sbGVyIGNvbW1hbmQgYnl0ZSAwMDQ3CmF0a2JkOiBrZXlib2Fy ZCBJRCAweDQxYWIgKDIpCmtiZGM6IFJFU0VUX0tCRCByZXR1cm4gY29kZTowMGZhCmtiZGM6 IFJFU0VUX0tCRCBzdGF0dXM6MDBhYQprYmQwIGF0IGF0a2JkMAprYmQwOiBhdGtiZDAsIEFU IDEwMS8xMDIgKDIpLCBjb25maWc6MHgwLCBmbGFnczoweDNkMDAwMAppb2FwaWMwOiByb3V0 aW5nIGludHBpbiAxIChJU0EgSVJRIDEpIHRvIHZlY3RvciA1MwphdGtiZDA6IFtHSUFOVC1M T0NLRURdCmF0a2JkMDogW0lUSFJFQURdCnBzbTA6IHVuYWJsZSB0byBhbGxvY2F0ZSBJUlEK cHNtY3BucDA6IDxQUy8yIG1vdXNlIHBvcnQ+IGlycSAxMiBvbiBhY3BpMApwc20wOiBjdXJy ZW50IGNvbW1hbmQgYnl0ZTowMDQ3CmtiZGM6IFRFU1RfQVVYX1BPUlQgc3RhdHVzOjAwMDAK a2JkYzogUkVTRVRfQVVYIHJldHVybiBjb2RlOjAwZmEKa2JkYzogUkVTRVRfQVVYIHN0YXR1 czowMGFhCmtiZGM6IFJFU0VUX0FVWCBJRDowMDAwCmtiZGM6IFJFU0VUX0FVWCByZXR1cm4g Y29kZTowMGZhCmtiZGM6IFJFU0VUX0FVWCBzdGF0dXM6MDBhYQprYmRjOiBSRVNFVF9BVVgg SUQ6MDAwMApwc206IHN0YXR1cyAwMCAwMiA2NApwc206IHN0YXR1cyAxMCAwMCA2NApwc206 IHN0YXR1cyAxMCAwMyA2NApwc206IHN0YXR1cyAxMCAwMyA2NApwc206IGRhdGEgZmZmZmZm ZmYgMDAgODA3ZjlhMmUKcHNtOiBzdGF0dXMgMTAgMDIgNjQKcHNtMDogPFBTLzIgTW91c2U+ IGlycSAxMiBvbiBhdGtiZGMwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDEyIChJU0EgSVJR IDEyKSB0byB2ZWN0b3IgNTQKcHNtMDogW0dJQU5ULUxPQ0tFRF0KcHNtMDogW0lUSFJFQURd CnBzbTA6IG1vZGVsIEludGVsbGlNb3VzZSwgZGV2aWNlIElEIDMtMDAsIDMgYnV0dG9ucwpw c20wOiBjb25maWc6MDAwMDAwMDAsIGZsYWdzOjAwMDAwMDA4LCBwYWNrZXQgc2l6ZTo0CnBz bTA6IHN5bmNtYXNrOjA4LCBzeW5jYml0czowMApwcGMwOiB1c2luZyBleHRlbmRlZCBJL08g cG9ydCByYW5nZQpwcGMwOiBTUFAKcHBjMDogPFBhcmFsbGVsIHBvcnQ+IHBvcnQgMHgzNzgt MHgzN2YgaXJxIDcgb24gYWNwaTAKcHBjMDogR2VuZXJpYyBjaGlwc2V0IChOSUJCTEUtb25s eSkgaW4gQ09NUEFUSUJMRSBtb2RlCnBwYnVzMDogPFBhcmFsbGVsIHBvcnQgYnVzPiBvbiBw cGMwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDcgKElTQSBJUlEgNykgdG8gdmVjdG9yIDU1 CnBwYnVzMDogW01QU0FGRV0KcHBidXMwOiBbSVRIUkVBRF0KcGxpcDA6IDxQTElQIG5ldHdv cmsgaW50ZXJmYWNlPiBvbiBwcGJ1czAKcGxpcDA6IFdBUk5JTkc6IHVzaW5nIG9ic29sZXRl ZCBJRkZfTkVFRFNHSUFOVCBmbGFnCnBsaXAwOiBicGYgYXR0YWNoZWQKbHB0MDogPFByaW50 ZXI+IG9uIHBwYnVzMApscHQwOiBJbnRlcnJ1cHQtZHJpdmVuIHBvcnQKcHBpMDogPFBhcmFs bGVsIEkvTz4gb24gcHBidXMwCnBwYzA6IFtHSUFOVC1MT0NLRURdCnBwYzA6IFtJVEhSRUFE XQpzaW8wOiBjb25maWd1cmVkIGlycSA0IG5vdCBpbiBiaXRtYXAgb2YgcHJvYmVkIGlycXMg MApzaW8wOiBwb3J0IG1heSBub3QgYmUgZW5hYmxlZApzaW8wOiBpcnEgbWFwczogMCAwIDAg MApzaW8wOiBjb25maWd1cmVkIGlycSA0IG5vdCBpbiBiaXRtYXAgb2YgcHJvYmVkIGlycXMg MApzaW8wOiBwb3J0IG1heSBub3QgYmUgZW5hYmxlZApzaW8wOiBpcnEgbWFwczogMCAwIDAg MApzaW8wOiA8MTY1NTBBLWNvbXBhdGlibGUgQ09NIHBvcnQ+IHBvcnQgMHgzZjgtMHgzZmYg aXJxIDQgZmxhZ3MgMHgxMCBvbiBhY3BpMApzaW8wOiB0eXBlIDE2NTUwQSwgY29uc29sZQpp b2FwaWMwOiByb3V0aW5nIGludHBpbiA0IChJU0EgSVJRIDQpIHRvIHZlY3RvciA1NgpzaW8w OiBbRklMVEVSXQpzaW8xOiBjb25maWd1cmVkIGlycSAzIG5vdCBpbiBiaXRtYXAgb2YgcHJv YmVkIGlycXMgMApzaW8xOiBwb3J0IG1heSBub3QgYmUgZW5hYmxlZApzaW8xOiBpcnEgbWFw czogMCAwIDAgMApzaW8xOiBjb25maWd1cmVkIGlycSAzIG5vdCBpbiBiaXRtYXAgb2YgcHJv YmVkIGlycXMgMApzaW8xOiBwb3J0IG1heSBub3QgYmUgZW5hYmxlZApzaW8xOiBpcnEgbWFw czogMCAwIDAgMApzaW8xOiA8MTY1NTBBLWNvbXBhdGlibGUgQ09NIHBvcnQ+IHBvcnQgMHgy ZjgtMHgyZmYgaXJxIDMgb24gYWNwaTAKc2lvMTogdHlwZSAxNjU1MEEKaW9hcGljMDogcm91 dGluZyBpbnRwaW4gMyAoSVNBIElSUSAzKSB0byB2ZWN0b3IgNTcKc2lvMTogW0ZJTFRFUl0K ZmRjMDogPGZsb3BweSBkcml2ZSBjb250cm9sbGVyPiBwb3J0IDB4M2YwLTB4M2Y1LDB4M2Y3 IGlycSA2IGRycSAyIG9uIGFjcGkwCmZkYzA6IGljX3R5cGUgODEgcGFydF9pZCA4MAppb2Fw aWMwOiByb3V0aW5nIGludHBpbiA2IChJU0EgSVJRIDYpIHRvIHZlY3RvciA1OApmZGMwOiBb RklMVEVSXQpmZDA6IDwxNDQwLUtCIDMuNSIgZHJpdmU+IG9uIGZkYzAgZHJpdmUgMApjcHUw OiA8QUNQSSBDUFU+IG9uIGFjcGkwCmNwdTA6IHN3aXRjaGluZyB0byBnZW5lcmljIEN4IG1v ZGUKYWNwaV90aHJvdHRsZTA6IDxBQ1BJIENQVSBUaHJvdHRsaW5nPiBvbiBjcHUwCmFjcGlf dGhyb3R0bGUwOiBQX0NOVCBmcm9tIFBfQkxLIDB4MTAxMApwb3dlcm5vdzA6IDxDb29sYG4n UXVpZXQgSzg+IG9uIGNwdTAKcG93ZXJub3cwOiBTVEFUVVM6IDB4MApwb3dlcm5vdzA6IFNU QVRVUzogbWF4ZmlkOiAweDAwCnBvd2Vybm93MDogU1RBVFVTOiBtYXh2aWQ6IDB4MDAKZGV2 aWNlX2F0dGFjaDogcG93ZXJub3cwIGF0dGFjaCByZXR1cm5lZCA2CmV4X2lzYV9pZGVudGlm eSgpCmF0a2JkYzogYXRrYmRjMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKZmRjOiBm ZGMwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdApwcGM6IHBwYzAgYWxyZWFkeSBleGlz dHM7IHNraXBwaW5nIGl0CnNpbzogc2lvMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQK c2lvOiBzaW8xIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdApzYzogc2MwIGFscmVhZHkg ZXhpc3RzOyBza2lwcGluZyBpdAp2Z2E6IHZnYTAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5n IGl0CmlzYV9wcm9iZV9jaGlsZHJlbjogZGlzYWJsaW5nIFBuUCBkZXZpY2VzCmlzYV9wcm9i ZV9jaGlsZHJlbjogcHJvYmluZyBub24tUG5QIGRldmljZXMKb3JtMDogPElTQSBPcHRpb24g Uk9Ncz4gYXQgaW9tZW0gMHhjMDAwMC0weGM3ZmZmLDB4Y2EwMDAtMHhjYWZmZiwweGRjMDAw LTB4ZGZmZmYsMHhlMDAwMC0weGUzZmZmIG9uIGlzYTAKc2MwOiA8U3lzdGVtIGNvbnNvbGU+ IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTAKc2MwOiBWR0EgPDE2IHZpcnR1YWwgY29uc29sZXMs IGZsYWdzPTB4MzAwPgpzYzA6IGZiMCwga2JkMSwgdGVybWluYWwgZW11bGF0b3I6IHNjIChz eXNjb25zIHRlcm1pbmFsKQpzaW8yOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKc2lvMzogbm90 IHByb2JlZCAoZGlzYWJsZWQpCnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgz YzAtMHgzZGYgaW9tZW0gMHhhMDAwMC0weGJmZmZmIG9uIGlzYTAKaXNhX3Byb2JlX2NoaWxk cmVuOiBwcm9iaW5nIFBuUCBkZXZpY2VzCkRldmljZSBjb25maWd1cmF0aW9uIGZpbmlzaGVk Lgpwcm9jZnMgcmVnaXN0ZXJlZApsYXBpYzogRGl2aXNvciAyLCBGcmVxdWVuY3kgMzMxODYx MTAgaHoKVGltZWNvdW50ZXIgIlRTQyIgZnJlcXVlbmN5IDIyMTIzNDk4MDMgSHogcXVhbGl0 eSA4MDAKVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4wMDAgbXNlYwp2bGFuOiBpbml0aWFs aXplZCwgdXNpbmcgaGFzaCB0YWJsZXMgd2l0aCBjaGFpbmluZwpsbzA6IGJwZiBhdHRhY2hl ZApocHRycjogbm8gY29udHJvbGxlciBkZXRlY3RlZC4KYXRhMC1tYXN0ZXI6IHBpbz1QSU80 IHdkbWE9V0RNQTIgdWRtYT1VRE1BMzMgY2FibGU9NDAgd2lyZQplbTA6IGxpbmsgc3RhdGUg Y2hhbmdlZCB0byBVUAphY3BpX2FjYWQwOiBhY2xpbmUgaW5pdGlhbGl6YXRpb24gc3RhcnQK YWNwaV9hY2FkMDogT24gTGluZQphY3BpX2FjYWQwOiBhY2xpbmUgaW5pdGlhbGl6YXRpb24g ZG9uZSwgdHJpZWQgMSB0aW1lcwphY2QwOiBzZXR0aW5nIFBJTzQgb24gUElJWDQgY2hpcAph Y2QwOiBzZXR0aW5nIFVETUEzMyBvbiBQSUlYNCBjaGlwCmFjZDA6IDxWTXdhcmUgVmlydHVh bCBJREUgQ0RST00gRHJpdmUvMDAwMDAwMDE+IENEUk9NIGRyaXZlIGF0IGF0YTAgYXMgbWFz dGVyCmFjZDA6IHJlYWQgMTcxS0IvcyAoMTcxS0IvcyksIDMyS0IgYnVmZmVyLCBVRE1BMzMK YWNkMDogUmVhZHM6IENEREEgc3RyZWFtCmFjZDA6IFdyaXRlczoKYWNkMDogQXVkaW86IHBs YXksIDIgdm9sdW1lIGxldmVscwphY2QwOiBNZWNoYW5pc206IGVqZWN0YWJsZSB0cmF5LCB1 bmxvY2tlZAphY2QwOiBNZWRpdW06IENELVJPTSAxMjBtbSBkYXRhIGRpc2MKV2FpdGluZyA1 IHNlY29uZHMgZm9yIFNDU0kgZGV2aWNlcyB0byBzZXR0bGUKKHhwdDA6bXB0MDowOi0xOi0x KTogcmVzZXQgYnVzCihwcm9iZTA6bXB0MDowOjA6MCk6IGVycm9yIDIyCihwcm9iZTA6bXB0 MDowOjA6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTA6bXB0MDowOjA6MCk6IGVycm9y IDIyCihwcm9iZTA6bXB0MDowOjA6MCk6IFVucmV0cnlhYmxlIEVycm9yCnBhc3MwIGF0IG1w dDAgYnVzIDAgdGFyZ2V0IDAgbHVuIDAKcGFzczA6IDxWTXdhcmUgVmlydHVhbCBkaXNrIDEu MD4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTIgZGV2aWNlIApwYXNzMDogMzIwLjAwME1C L3MgdHJhbnNmZXJzICgxNjAuMDAwTUh6LCBvZmZzZXQgMTI3LCAxNmJpdCkKcGFzczA6IENv bW1hbmQgUXVldWVpbmcgRW5hYmxlZApkYTAgYXQgbXB0MCBidXMgMCB0YXJnZXQgMCBsdW4g MApkYTA6IDxWTXdhcmUgVmlydHVhbCBkaXNrIDEuMD4gRml4ZWQgRGlyZWN0IEFjY2VzcyBT Q1NJLTIgZGV2aWNlIApkYTA6IDMyMC4wMDBNQi9zIHRyYW5zZmVycyAoMTYwLjAwME1IeiBE VCwgb2Zmc2V0IDEyNywgMTZiaXQpCmRhMDogQ29tbWFuZCBRdWV1ZWluZyBFbmFibGVkCmRh MDogODE5Mk1CICgxNjc3NzIxNiA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDEwNDRD KQpHRU9NOiBuZXcgZGlzayBkYTAKQVRBIFBzZXVkb1JBSUQgbG9hZGVkClRyeWluZyB0byBt b3VudCByb290IGZyb20gdWZzOi9kZXYvZGEwczFhCnN0YXJ0X2luaXQ6IHRyeWluZyAvc2Jp bi9pbml0ClZNd2FyZSBtZW1vcnkgY29udHJvbCBkcml2ZXIgaW5pdGlhbGl6ZWQKcGNpMDog ZHJpdmVyIGFkZGVkCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4NzExMywgcmV2aWQ9 MHgwOAoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTcsIGZ1bmM9MwoJY2xhc3M9MDYtODAtMDAs IGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwMSwgc3RhdHJlZz0weDAyODAs IGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4 MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKcGNpMDowOjc6MzogcmVwcm9iaW5nIG9u IGRyaXZlciBhZGRlZApwY2kxOiBkcml2ZXIgYWRkZWQKc3BsYXNoOiBpbWFnZSBkZWNvZGVy IGZvdW5kOiBkYWVtb25fc2F2ZXIKCg== --------------070707080408080604010100 Content-Type: text/plain; name="freebsd-72-amd64-r203057.dmesg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="freebsd-72-amd64-r203057.dmesg" U01BUCB0eXBlPTAxIGJhc2U9MDAwMDAwMDAwMDAwMDAwMCBsZW49MDAwMDAwMDAwMDA5Zjgw MApTTUFQIHR5cGU9MDIgYmFzZT0wMDAwMDAwMDAwMDlmODAwIGxlbj0wMDAwMDAwMDAwMDAw ODAwClNNQVAgdHlwZT0wMiBiYXNlPTAwMDAwMDAwMDAwY2EwMDAgbGVuPTAwMDAwMDAwMDAw MDIwMDAKU01BUCB0eXBlPTAyIGJhc2U9MDAwMDAwMDAwMDBkYzAwMCBsZW49MDAwMDAwMDAw MDAyNDAwMApTTUFQIHR5cGU9MDEgYmFzZT0wMDAwMDAwMDAwMTAwMDAwIGxlbj0wMDAwMDAw MDFmZGYwMDAwClNNQVAgdHlwZT0wMyBiYXNlPTAwMDAwMDAwMWZlZjAwMDAgbGVuPTAwMDAw MDAwMDAwMGYwMDAKU01BUCB0eXBlPTA0IGJhc2U9MDAwMDAwMDAxZmVmZjAwMCBsZW49MDAw MDAwMDAwMDAwMTAwMApTTUFQIHR5cGU9MDEgYmFzZT0wMDAwMDAwMDFmZjAwMDAwIGxlbj0w MDAwMDAwMDAwMTAwMDAwClNNQVAgdHlwZT0wMiBiYXNlPTAwMDAwMDAwZmVjMDAwMDAgbGVu PTAwMDAwMDAwMDAwMTAwMDAKU01BUCB0eXBlPTAyIGJhc2U9MDAwMDAwMDBmZWUwMDAwMCBs ZW49MDAwMDAwMDAwMDAwMTAwMApTTUFQIHR5cGU9MDIgYmFzZT0wMDAwMDAwMGZmZmUwMDAw IGxlbj0wMDAwMDAwMDAwMDIwMDAwCkNvcHlyaWdodCAoYykgMTk5Mi0yMDEwIFRoZSBGcmVl QlNEIFByb2plY3QuCkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4 OCwgMTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NAoJVGhlIFJlZ2VudHMgb2YgdGhlIFVu aXZlcnNpdHkgb2YgQ2FsaWZvcm5pYS4gQWxsIHJpZ2h0cyByZXNlcnZlZC4KRnJlZUJTRCBp cyBhIHJlZ2lzdGVyZWQgdHJhZGVtYXJrIG9mIFRoZSBGcmVlQlNEIEZvdW5kYXRpb24uCkZy ZWVCU0QgNy4zLVBSRVJFTEVBU0UgIzEwIHIyMDMwNTc6IFR1ZSBGZWIgIDIgMjA6MTc6MjQg RVNUIDIwMTAKICAgIHRvbUBmcmVlYnNkLTcyLWFtZDY0LnN0cmF5Y2F0LmRocy5vcmc6L3Vz ci9vYmovdXNyL3NyYy9zeXMvR0VORVJJQyBhbWQ2NApQcmVsb2FkZWQgZWxmIGtlcm5lbCAi L2Jvb3Qva2VybmVsL2tlcm5lbCIgYXQgMHhmZmZmZmZmZjgwZDA4MDAwLgpDYWxpYnJhdGlu ZyBjbG9jayhzKSAuLi4gaTgyNTQgY2xvY2s6IDExOTIwNTkgSHoKQ0xLX1VTRV9JODI1NF9D QUxJQlJBVElPTiBub3Qgc3BlY2lmaWVkIC0gdXNpbmcgZGVmYXVsdCBmcmVxdWVuY3kKVGlt ZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDAKQ2FsaWJy YXRpbmcgVFNDIGNsb2NrIC4uLiBUU0MgY2xvY2s6IDIyMDEzNTAxNDMgSHoKQ1BVOiBEdWFs LUNvcmUgQU1EIE9wdGVyb24odG0pIFByb2Nlc3NvciAxMjE0ICgyMjAxLjM1LU1IeiBLOC1j bGFzcyBDUFUpCiAgT3JpZ2luID0gIkF1dGhlbnRpY0FNRCIgIElkID0gMHg0MGYzMyAgU3Rl cHBpbmcgPSAzCiAgRmVhdHVyZXM9MHg3OGJmYmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1Is UEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFULFBTRTM2LENMRkxV U0gsTU1YLEZYU1IsU1NFLFNTRTI+CiAgRmVhdHVyZXMyPTB4MjAwMTxTU0UzLENYMTY+CiAg QU1EIEZlYXR1cmVzPTB4ZWE1MDA4MDA8U1lTQ0FMTCxOWCxNTVgrLEZGWFNSLFJEVFNDUCxM TSwzRE5vdyErLDNETm93IT4KICBBTUQgRmVhdHVyZXMyPTB4OTxMQUhGLEV4dEFQSUM+Ckwx IDJNQiBkYXRhIFRMQjogOCBlbnRyaWVzLCBmdWxseSBhc3NvY2lhdGl2ZQpMMSAyTUIgaW5z dHJ1Y3Rpb24gVExCOiA4IGVudHJpZXMsIGZ1bGx5IGFzc29jaWF0aXZlCkwxIDRLQiBkYXRh IFRMQjogMzIgZW50cmllcywgZnVsbHkgYXNzb2NpYXRpdmUKTDEgNEtCIGluc3RydWN0aW9u IFRMQjogMzIgZW50cmllcywgZnVsbHkgYXNzb2NpYXRpdmUKTDEgZGF0YSBjYWNoZTogNjQg a2J5dGVzLCA2NCBieXRlcy9saW5lLCAxIGxpbmVzL3RhZywgMi13YXkgYXNzb2NpYXRpdmUK TDEgaW5zdHJ1Y3Rpb24gY2FjaGU6IDY0IGtieXRlcywgNjQgYnl0ZXMvbGluZSwgMSBsaW5l cy90YWcsIDItd2F5IGFzc29jaWF0aXZlCkwyIDJNQiB1bmlmaWVkIFRMQjogMCBlbnRyaWVz LCBkaXNhYmxlZC9ub3QgcHJlc2VudApMMiA0S0IgZGF0YSBUTEI6IDUxMiBlbnRyaWVzLCA0 LXdheSBhc3NvY2lhdGl2ZQpMMiA0S0IgaW5zdHJ1Y3Rpb24gVExCOiA1MTIgZW50cmllcywg NC13YXkgYXNzb2NpYXRpdmUKTDIgdW5pZmllZCBjYWNoZTogMTAyNCBrYnl0ZXMsIDY0IGJ5 dGVzL2xpbmUsIDEgbGluZXMvdGFnLCAxNi13YXkgYXNzb2NpYXRpdmUKdXNhYmxlIG1lbW9y eSA9IDUyMzU5MTY4MCAoNDk5IE1CKQpQaHlzaWNhbCBtZW1vcnkgY2h1bmsocyk6CjB4MDAw MDAwMDAwMDAwMTAwMCAtIDB4MDAwMDAwMDAwMDA5YmZmZiwgNjM0ODgwIGJ5dGVzICgxNTUg cGFnZXMpCjB4MDAwMDAwMDAwMGQzNTAwMCAtIDB4MDAwMDAwMDAxZWZiN2ZmZiwgNTA1OTUw MjA4IGJ5dGVzICgxMjM1MjMgcGFnZXMpCjB4MDAwMDAwMDAxZmYwMDAwMCAtIDB4MDAwMDAw MDAxZmZlZmZmZiwgOTgzMDQwIGJ5dGVzICgyNDAgcGFnZXMpCmF2YWlsIG1lbW9yeSAgPSA1 MDI3OTIxOTIgKDQ3OSBNQikKQUNQSSBBUElDIFRhYmxlOiA8UFRMVEQgIAkgQVBJQyAgPgpB UElDOiBDUFUgMCBoYXMgQUNQSSBJRCAwClVMRTogc2V0dXAgY3B1IGdyb3VwIDAKVUxFOiBz ZXR1cCBjcHUgMApVTEU6IGFkZGluZyBjcHUgMCB0byBncm91cCAwOiBjcHVzIDEgbWFzayAw eDEKQUNQSTogUlNEUCBAIDB4MHhmNmM2MC8weDAwMTQgKHYgIDAgUFRMVEQgKQpBQ1BJOiBS U0RUIEAgMHgweDFmZWZhYjY4LzB4MDAzMCAodiAgMSBQVExURCAgICBSU0RUICAgMHgwNjA0 MDAwMCAgTFRQIDB4MDAwMDAwMDApCkFDUEk6IEZBQ1AgQCAweDB4MWZlZmVmMTQvMHgwMDc0 ICh2ICAxIElOVEVMICA0NDBCWCAgICAweDA2MDQwMDAwIFBUTCAgMHgwMDBGNDI0MCkKQUNQ STogRFNEVCBAIDB4MHgxZmVmYWI5OC8weDQzN0MgKHYgIDEgUFRMVEQgIEN1c3RvbSAgIDB4 MDYwNDAwMDAgTVNGVCAweDAxMDAwMDBEKQpBQ1BJOiBGQUNTIEAgMHgweDFmZWZmZmMwLzB4 MDA0MApBQ1BJOiBBUElDIEAgMHgweDFmZWZlZjg4LzB4MDA1MCAodiAgMSBQVExURCAgCSBB UElDICAgMHgwNjA0MDAwMCAgTFRQIDB4MDAwMDAwMDApCkFDUEk6IEJPT1QgQCAweDB4MWZl ZmVmZDgvMHgwMDI4ICh2ICAxIFBUTFREICAkU0JGVEJMJCAweDA2MDQwMDAwICBMVFAgMHgw MDAwMDAwMSkKTUFEVDogRm91bmQgSU8gQVBJQyBJRCAxLCBJbnRlcnJ1cHQgMCBhdCAweGZl YzAwMDAwCmlvYXBpYzA6IFJvdXRpbmcgZXh0ZXJuYWwgODI1OUEncyAtPiBpbnRwaW4gMApN QURUOiBJbnRlcnJ1cHQgb3ZlcnJpZGU6IHNvdXJjZSAwLCBpcnEgMgppb2FwaWMwOiBSb3V0 aW5nIElSUSAwIC0+IGludHBpbiAyCmxhcGljMDogUm91dGluZyBOTUkgLT4gTElOVDEKbGFw aWMwOiBMSU5UMSB0cmlnZ2VyOiBlZGdlCmxhcGljMDogTElOVDEgcG9sYXJpdHk6IGhpZ2gK TUFEVDogRm9yY2luZyBhY3RpdmUtbG93IHBvbGFyaXR5IGFuZCBsZXZlbCB0cmlnZ2VyIGZv ciBTQ0kKaW9hcGljMDogaW50cGluIDkgcG9sYXJpdHk6IGxvdwppb2FwaWMwOiBpbnRwaW4g OSB0cmlnZ2VyOiBsZXZlbAppb2FwaWMwIDxWZXJzaW9uIDEuMT4gaXJxcyAwLTIzIG9uIG1v dGhlcmJvYXJkCmNwdTAgQlNQOgogICAgIElEOiAweDAwMDAwMDAwICAgVkVSOiAweDgwMDQw MDExIExEUjogMHgwMDAwMDAwMCBERlI6IDB4ZmZmZmZmZmYKICBsaW50MDogMHgwMDAxMDcw MCBsaW50MTogMHgwMDAwMDQwMCBUUFI6IDB4MDAwMDAwMDAgU1ZSOiAweDAwMDAwMWZmCiAg dGltZXI6IDB4MDAwMTAwZWYgdGhlcm06IDB4MDAwMTAwMDAgZXJyOiAweDAwMDEwMDAwIHBj bTogMHgwMDAxMDQwMAp3bGFuOiA8ODAyLjExIExpbmsgTGF5ZXI+CndsYW5fYW1ycjogPEFN UlIgVHJhbnNtaXQgUmF0ZSBDb250cm9sIEFsZ29yaXRobT4KbnVsbDogPG51bGwgZGV2aWNl LCB6ZXJvIGRldmljZT4KcmFuZG9tOiA8ZW50cm9weSBzb3VyY2UsIFNvZnR3YXJlLCBZYXJy b3c+Cm5mc2xvY2s6IHBzZXVkby1kZXZpY2UKa2JkOiBuZXcgYXJyYXkgc2l6ZSA0CmtiZDEg YXQga2JkbXV4MAptZW06IDxtZW1vcnk+CmlvOiA8SS9PPgpocHRycjogUm9ja2V0UkFJRCAx N3h4LzJ4eHggU0FUQSBjb250cm9sbGVyIGRyaXZlciB2MS4yIChGZWIgIDIgMjAxMCAyMDox NzoxMCkKYWNwaTA6IDxQVExURCAgIFJTRFQ+IG9uIG1vdGhlcmJvYXJkCmlvYXBpYzA6IHJv dXRpbmcgaW50cGluIDkgKElTQSBJUlEgOSkgdG8gdmVjdG9yIDQ4CmFjcGkwOiBbTVBTQUZF XQphY3BpMDogW0lUSFJFQURdCkFjcGlPc0Rlcml2ZVBjaUlkOiBcX1NCXy5QQ0kwLlBXUl8u UENJXyAtPiBidXMgMCBkZXYgNyBmdW5jIDMKYWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4ZWQp CkFjcGlPc0Rlcml2ZVBjaUlkOiBcX1NCXy5QQ0kwLlJFR1MgLT4gYnVzIDAgZGV2IDAgZnVu YyAwCkFjcGlPc0Rlcml2ZVBjaUlkOiBcX1NCXy5QQ0kwLklTQV8uUElSWCAtPiBidXMgMCBk ZXYgNyBmdW5jIDAKQUNQSSB0aW1lcjogMC8zOTcgMC8xNzQwIDAvMTQxIDAvMTk5IDAvNzIg MC8zMTUgMC8yNiAwLzQ0MCAwLzMxMyAwLzU2MiAtPiAwClRpbWVjb3VudGVyICJBQ1BJLXNh ZmUiIGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgODUwCmFjcGlfdGltZXIwOiA8MjQt Yml0IHRpbWVyIGF0IDMuNTc5NTQ1TUh6PiBwb3J0IDB4MTAwOC0weDEwMGIgb24gYWNwaTAK cGNpX2xpbmswOiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFs IFByb2JlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDE0IDE1 CiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA2IDcgOSAx MCAxMSAxNCAxNQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0 IDUgNiA3IDkgMTAgMTEgMTQgMTUKcGNpX2xpbmsxOiAgICAgICAgSW5kZXggIElSUSAgUnRk ICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAgIDAgICAgOSAgIE4gICAgIDAgIDMg NCA1IDYgNyA5IDEwIDExIDE0IDE1CiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAgIDkgICBO ICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxNCAxNQogIEFmdGVyIERpc2FibGUgICAgICAg MCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTQgMTUKcGNpX2xpbmsyOiAg ICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAg IDAgICAxMSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDE0IDE1CiAgVmFsaWRhdGlv biAgICAgICAgICAwICAgMTEgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxNCAxNQog IEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAg MTEgMTQgMTUKcGNpX2xpbmszOiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMK ICBJbml0aWFsIFByb2JlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEw IDExIDE0IDE1CiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQg NSA2IDcgOSAxMCAxMSAxNCAxNQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAg ICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTQgMTUKcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJy aWRnZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMApwY2kwOiA8QUNQSSBQQ0kgYnVzPiBv biBwY2liMApwY2kwOiBkb21haW49MCwgcGh5c2ljYWwgYnVzPTAKZm91bmQtPgl2ZW5kb3I9 MHg4MDg2LCBkZXY9MHg3MTkwLCByZXZpZD0weDAxCglkb21haW49MCwgYnVzPTAsIHNsb3Q9 MCwgZnVuYz0wCgljbGFzcz0wNi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRy ZWc9MHgwMDA2LCBzdGF0cmVnPTB4MDIxMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRp bWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5z KQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDcxOTEsIHJldmlkPTB4MDEKCWRvbWFp bj0wLCBidXM9MCwgc2xvdD0xLCBmdW5jPTAKCWNsYXNzPTA2LTA0LTAwLCBoZHJ0eXBlPTB4 MDEsIG1mZGV2PTAKCWNtZHJlZz0weDAxMWYsIHN0YXRyZWc9MHgwMjIwLCBjYWNoZWxuc3o9 MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDg0ICgzMzAwMCBu cyksIG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDcx MTAsIHJldmlkPTB4MDgKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD03LCBmdW5jPTAKCWNsYXNz PTA2LTAxLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDcsIHN0YXRy ZWc9MHgwMjgwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyks IG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9y PTB4ODA4NiwgZGV2PTB4NzExMSwgcmV2aWQ9MHgwMQoJZG9tYWluPTAsIGJ1cz0wLCBzbG90 PTcsIGZ1bmM9MQoJY2xhc3M9MDEtMDEtOGEsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21k cmVnPTB4MDAwNSwgc3RhdHJlZz0weDAyODAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0 aW1lcj0weDQwICgxOTIwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAo MCBucykKCW1hcFsyMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4MTA1MCwg c2l6ZSAgNCwgZW5hYmxlZApmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDcxMTMsIHJl dmlkPTB4MDgKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD03LCBmdW5jPTMKCWNsYXNzPTA2LTgw LTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDEsIHN0YXRyZWc9MHgw MjgwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdu dD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCgltYXBbOTBdOiB0eXBlIEkvTyBQ b3J0LCByYW5nZSAzMiwgYmFzZSAweDEwNDAsIHNpemUgIDQsIGVuYWJsZWQKZm91bmQtPgl2 ZW5kb3I9MHgxNWFkLCBkZXY9MHgwNDA1LCByZXZpZD0weDAwCglkb21haW49MCwgYnVzPTAs IHNsb3Q9MTUsIGZ1bmM9MAoJY2xhc3M9MDMtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9 MAoJY21kcmVnPTB4MDAwMywgc3RhdHJlZz0weDAyODAsIGNhY2hlbG5zej04IChkd29yZHMp CglsYXR0aW1lcj0weDQwICgxOTIwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9 MHgwMCAoMCBucykKCW1hcFsxMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4 MTA2MCwgc2l6ZSAgNCwgZW5hYmxlZAoJbWFwWzE0XTogdHlwZSBNZW1vcnksIHJhbmdlIDMy LCBiYXNlIDB4ZjgwMDAwMDAsIHNpemUgMjYsIGVuYWJsZWQKCW1hcFsxOF06IHR5cGUgTWVt b3J5LCByYW5nZSAzMiwgYmFzZSAweGY0MDAwMDAwLCBzaXplIDIzLCBlbmFibGVkCmZvdW5k LT4JdmVuZG9yPTB4MTAwMCwgZGV2PTB4MDAzMCwgcmV2aWQ9MHgwMQoJZG9tYWluPTAsIGJ1 cz0wLCBzbG90PTE2LCBmdW5jPTAKCWNsYXNzPTAxLTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1m ZGV2PTAKCWNtZHJlZz0weDAwMDMsIHN0YXRyZWc9MHgwMjgwLCBjYWNoZWxuc3o9MCAoZHdv cmRzKQoJbGF0dGltZXI9MHg0MCAoMTkyMCBucyksIG1pbmdudD0weDA2ICgxNTAwIG5zKSwg bWF4bGF0PTB4ZmYgKDYzNzUwIG5zKQoJaW50cGluPWEsIGlycT05CgltYXBbMTBdOiB0eXBl IEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDEwODAsIHNpemUgIDcsIGVuYWJsZWQKCW1h cFsxNF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGY0ODEwMDAwLCBzaXplIDEy LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjE2LklOVEEKcGNpYjA6IHNs b3QgMTYgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE3CmZvdW5kLT4JdmVuZG9yPTB4ODA4Niwg ZGV2PTB4MTAwZiwgcmV2aWQ9MHgwMQoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTE3LCBmdW5j PTAKCWNsYXNzPTAyLTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAx MTMsIHN0YXRyZWc9MHgwMjMwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4 MDAgKDAgbnMpLCBtaW5nbnQ9MHhmZiAoNjM3NTAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykK CWludHBpbj1hLCBpcnE9MTEKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVu dCBEMAoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4ZjQ4MjAwMDAs IHNpemUgMTcsIGVuYWJsZWQKCW1hcFsxOF06IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFz ZSAweGY0ODAwMDAwLCBzaXplIDE2LCBlbmFibGVkCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0 LCByYW5nZSAzMiwgYmFzZSAweDE0MDAsIHNpemUgIDYsIGVuYWJsZWQKcGNpYjA6IG1hdGNo ZWQgZW50cnkgZm9yIDAuMTcuSU5UQQpwY2liMDogc2xvdCAxNyBJTlRBIGhhcmR3aXJlZCB0 byBJUlEgMTgKcGNpYjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMS4wIG9u IHBjaTAKcGNpYjE6ICAgZG9tYWluICAgICAgICAgICAgMApwY2liMTogICBzZWNvbmRhcnkg YnVzICAgICAxCnBjaWIxOiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDEKcGNpYjE6ICAgSS9PIGRl Y29kZSAgICAgICAgMHhmMDAwLTB4ZmZmCnBjaWIxOiAgIG5vIHByZWZldGNoZWQgZGVjb2Rl CnBjaWIxOiBjb3VsZCBub3QgZ2V0IFBDSSBpbnRlcnJ1cHQgcm91dGluZyB0YWJsZSBmb3Ig XF9TQl8uUENJMC5BR1BfIC0gQUVfTk9UX0ZPVU5ECnBjaTE6IDxBQ1BJIFBDSSBidXM+IG9u IHBjaWIxCnBjaTE6IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9MQppc2FiMDogPFBDSS1JU0Eg YnJpZGdlPiBhdCBkZXZpY2UgNy4wIG9uIHBjaTAKaXNhMDogPElTQSBidXM+IG9uIGlzYWIw CmF0YXBjaTA6IDxJbnRlbCBQSUlYNCBVRE1BMzMgY29udHJvbGxlcj4gcG9ydCAweDFmMC0w eDFmNywweDNmNiwweDE3MC0weDE3NywweDM3NiwweDEwNTAtMHgxMDVmIGF0IGRldmljZSA3 LjEgb24gcGNpMAphdGFwY2kwOiBSZXNlcnZlZCAweDEwIGJ5dGVzIGZvciByaWQgMHgyMCB0 eXBlIDQgYXQgMHgxMDUwCmF0YTA6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kwCmF0YXBj aTA6IFJlc2VydmVkIDB4OCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSA0IGF0IDB4MWYwCmF0 YXBjaTA6IFJlc2VydmVkIDB4MSBieXRlcyBmb3IgcmlkIDB4MTQgdHlwZSA0IGF0IDB4M2Y2 CmF0YTA6IHJlc2V0IHRwMSBtYXNrPTAxIG9zdGF0MD01MCBvc3RhdDE9ZmYKYXRhMDogc3Rh dDA9MHgwMCBlcnI9MHgwMSBsc2I9MHgxNCBtc2I9MHhlYgphdGEwOiByZXNldCB0cDIgc3Rh dDA9MDAgc3RhdDE9MDAgZGV2aWNlcz0weDQ8QVRBUElfTUFTVEVSPgppb2FwaWMwOiByb3V0 aW5nIGludHBpbiAxNCAoSVNBIElSUSAxNCkgdG8gdmVjdG9yIDQ5CmF0YTA6IFtNUFNBRkVd CmF0YTA6IFtJVEhSRUFEXQphdGExOiA8QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpMAphdGFw Y2kwOiBSZXNlcnZlZCAweDggYnl0ZXMgZm9yIHJpZCAweDE4IHR5cGUgNCBhdCAweDE3MAph dGFwY2kwOiBSZXNlcnZlZCAweDEgYnl0ZXMgZm9yIHJpZCAweDFjIHR5cGUgNCBhdHRvIHZl Y3RvciA1MAphdGExOiBbTVBTQUZFXQphdGExOiBbSVRIUkVBRF0KcGNpMDogPGJyaWRnZT4g YXQgZGV2aWNlIDcuMyAobm8gZHJpdmVyIGF0dGFjaGVkKQp2Z2FwY2kwOiA8VkdBLWNvbXBh dGlibGUgZGlzcGxheT4gcG9ydCAweDEwNjAtMHgxMDZmIG1lbSAweGY4MDAwMDAwLTB4ZmJm ZmZmZmYsMHhmNDAwMDAwMC0weGY0N2ZmZmZmIGF0IGRldmljZSAxNS4wIG9uIHBjaTAKbXB0 MDogPExTSUxvZ2ljIDEwMzAgVWx0cmE0IEFkYXB0ZXI+IHBvcnQgMHgxMDgwLTB4MTBmZiBt ZW0gMHhmNDgxMDAwMC0weGY0ODEwZmZmIGlycSAxNyBhdCBkZXZpY2UgMTYuMCBvbiBwY2kw Cm1wdDA6IFJlc2VydmVkIDB4ODAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgNCBhdCAweDEw ODAKbXB0MDogUmVzZXJ2ZWQgMHgxMDAwIGJ5dGVzIGZvciByaWQgMHgxNCB0eXBlIDMgYXQg MHhmNDgxMDAwMAoK --------------070707080408080604010100-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 5 09:41:00 2010 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 279AB1065676 for ; Fri, 5 Feb 2010 09:41:00 +0000 (UTC) (envelope-from mamalos@eng.auth.gr) Received: from vergina.eng.auth.gr (vergina.eng.auth.gr [155.207.18.1]) by mx1.freebsd.org (Postfix) with ESMTP id 9F5378FC0A for ; Fri, 5 Feb 2010 09:40:58 +0000 (UTC) Received: from mamalacation.ee.auth.gr (mamalacation.ee.auth.gr [155.207.33.29]) by vergina.eng.auth.gr (8.14.3/8.14.1) with ESMTP id o159euD1000430 for ; Fri, 5 Feb 2010 11:40:56 +0200 (EET) (envelope-from mamalos@eng.auth.gr) Message-ID: <4B6BE7A2.6000402@eng.auth.gr> Date: Fri, 05 Feb 2010 11:40:50 +0200 From: George Mamalakis User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.5) Gecko/20100115 Thunderbird/3.0 MIME-Version: 1.0 To: freebsd-stable Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Kerberized NFSv3 incorrect behavior 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, 05 Feb 2010 09:41:00 -0000 Dear all, I am running FBSD8-STABLE on an nfsv3 server and an nfsv3 client. My configuration is based on http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup. My goal is to share filesystems securely through kerberos authentication. Everything works fine, until I try to kdestroy my tickets or kinit to some other user, where the system insists to think that I am the user that initially obtained their ticket. To be more extensive, my story is as follows: nfs server: /etc/rc.conf: rpcbind_enable="YES" mountd_flags="-e" nfs_server_enable="YES" nfs_client_enable="YES" gssd_enable="YES" and the kernel is compiled with: options KGSSAPI device crypto my /etc/exports contains: /exports -alldirs -sec=krb5 nfs client: /etc/rc.conf: rpcbind_enable="YES" nfs_client_enable="YES" gssd_enable="YES" on both client and server the /etc/krb5.conf contains: [libdefaults] default_realm = EXAMPLE.COM [realms] EXAMPLE.COM = { kdc = kdc.example.com admin_server = kdc.example.com kpasswd_server = kdc.example.com } [domain_realm] kdc.example.com = EXAMPLE.COM .kdc.example.com = EXAMPLE.COM .example.com = EXAMPLE.COM example.com = EXAMPLE.COM and both client and server have the correct entries about each other (and themselves) in their /etc/hosts, so heimdal works just fine. Both client and server have their respective keytabs stored in /etc/krb5.keytab, and I use two users in my example (that both exist in both systems with the same uid,gid): mamalos and testakis. So, when I mount the exported filesystem on the client giving: # mount -o nvfsv3,sec=krb5 server.example.com:/exports /mnt # mount /dev/da0s1a on / (ufs, local, soft-updates) devfs on /dev (devfs, local, multilabel) server.example.com:/exports on /mnt (nfs) and try to access the share: # ls /mnt ls: mnt: Permission denied I get the error I am expecting, since root does not have any kerberos tickets assigned, yet. Let's see what happens when I kinit as mamalos: # klist Credentials cache: FILE:/tmp/krb5cc_0 Principal: mamalos@EXAMPLE.COM Issued Expires Principal Feb 5 11:20:49 Feb 5 21:20:47 krbtgt/EXAPMLE.COM@EXAMPLE.COM # ls -la /mnt/ total 8 drwxr-xr-x 4 root wheel - 512 4 Feb 19:03 ./ drwxr-xr-x 21 root wheel - 512 3 Feb 11:27 ../ drwx------ 2 mamalos wheel - 512 5 Feb 11:11 mamalos/ drwx------ 2 testakis wheel - 512 4 Feb 19:06 testakis/ # touch /mnt/mamalos/myfile # ls -la /mnt/mamalos/myfile rw-r--r-- 1 mamalos wheel - 0 5 Feb 11:22 /mnt/mamalos/myfile Which is the exact behavior that is expected. Now when I kdestroy: # kdestroy # klist klist: No ticket file: /tmp/krb5cc_0 # touch /mnt/mamalos/myfilethatshouldnotbe # ls -la /mnt/mamalos/myfilethatshouldnotbe -rw-r--r-- 1 mamalos wheel - 0 5 Feb 11:24 /mnt/mamalos/myfilethatshouldnotbe And I can do everything in that share as if I were still mamalos, even though I kdestroyed my kerberos ticket. The same thing will happen even if I kinit to testakis after that. klist shows testakis' ticket this time, but I am not allowed to access (rwx) tetakis' files/folders, and I still have full control over mamalos' files and folders. In order to be able to do something as testakis, I have to unmount the share and remount it while having testakis' ticket (or having no ticket at all, and giving kinit testakis after mounting the share). I am not an NFS expert, but I suppose that this behavior is not the one to be expected, except if I am missing some fundamental information about kerberized NFS that explains it. Even so, it would be quite unwise to behave so, since even if the users kdestroys their tickets, they have still all permissions as when they obtained their ticket. Thank you all in advance, looking forward to an answer, kind regards, mamalos -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 From owner-freebsd-stable@FreeBSD.ORG Fri Feb 5 11:04:52 2010 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 49D5E1065670 for ; Fri, 5 Feb 2010 11:04:52 +0000 (UTC) (envelope-from jespasac@minibofh.org) Received: from smtp02.srv.cat (smtp02.cdmon.com [212.36.74.57]) by mx1.freebsd.org (Postfix) with ESMTP id CB6358FC1C for ; Fri, 5 Feb 2010 11:04:50 +0000 (UTC) Received: from jespasac.cdmon.com (62.Red-217-126-43.staticIP.rima-tde.net [217.126.43.62]) (Authenticated sender: jespasac@noverificar) by smtp02.srv.cat (Postfix) with ESMTP id 4C71F46E24 for ; Fri, 5 Feb 2010 12:04:48 +0100 (CET) Message-ID: <4B6BFB4F.5010505@minibofh.org> Date: Fri, 05 Feb 2010 12:04:47 +0100 From: Jordi Espasa Clofent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0b1 Thunderbird/3.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4B696D0B.3070301@minibofh.org> <20100203134025.GA1787@icarus.home.lan> In-Reply-To: <20100203134025.GA1787@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Inmutable bit in some binaries 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, 05 Feb 2010 11:04:52 -0000 > It's possible installworld will break (fail/exit) when trying to > overwrite some of these binaries. However... > > install(1) supports the -f flags to specify what the destination file > should have its file flags (chflags) set to, and from looking at the > code (src/usr.bin/xinstall/xinstall.c), there are some places which > indicate before copying/installing a file the software may attempt to > unset file flags first. I'm not 100% familiar with this code, but it > appears as if use of the -S flag to install(1) would cause it to behave > like described. It should be easy enough for you to test. > > Otherwise, my recommendation is to build a test system / virtual box of > some sort (VMware, etc.) and try it. See what happens. Ok. It's exactly what I've supposed. > Opinion below: > > What you're attempting to solve, ultimately, is security through > obscurity and gets you a very large headache. :-) Your schg idea would > only work if you planned on using kern.securelevel=1 or higher. This > sounds great in concept, but many a time on this list have people posted > problems with system administrative tasks (re: upgrading) when this > sysctl is set to non-default (-1). Mmmmmm... I don't undestand this like secuiryt by obscurity; anyway you've the reason: kern.securelevel should be the correct path to follow. > If you plan on using this, I would advocate *all* installation/work be > done in single-user mode. I know quite a few people who completely > ignore the "boot into single user" step of src/Makefile and instead do > it in multi-user mode -- only to be found later screaming/crying when > binaries don't work or behave oddly because, say, /libexec/ld-elf.so was > supposed to be updated yet wasn't due to their choosing to not follow > the proper procedure. If your system doesn't have an out-of-band > method of getting to it (ex. serial console), then I wouldn't bother > trying any of the above. > > Otherwise, I'm pretty sure others here have made use of read-only > environments, such as read-only NFS root filesystems (sometimes > accomplished via PXE) and/or /usr, or CD-based OS (good luck changing > any files there). I can't help in that regard. Thanks for comments. ;) -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 5 11:06:44 2010 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 33CF7106566B for ; Fri, 5 Feb 2010 11:06:44 +0000 (UTC) (envelope-from jespasac@minibofh.org) Received: from smtp03.srv.cat (xen-smtp03.cdmon.com [212.36.74.234]) by mx1.freebsd.org (Postfix) with ESMTP id E7A8D8FC1C for ; Fri, 5 Feb 2010 11:06:43 +0000 (UTC) Received: from jespasac.cdmon.com (62.Red-217-126-43.staticIP.rima-tde.net [217.126.43.62]) (Authenticated sender: jespasac@noverificar) by smtp03.srv.cat (Postfix) with ESMTPA id 10B697C154 for ; Fri, 5 Feb 2010 12:06:40 +0100 (CET) Message-ID: <4B6BFBBF.2000202@minibofh.org> Date: Fri, 05 Feb 2010 12:06:39 +0100 From: Jordi Espasa Clofent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0b1 Thunderbird/3.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4B685EBA.4020501@minibofh.org> <4B695A1A.1000505@incunabulum.net> <4B696360.3070209@minibofh.org> <4B6ACC38.2030708@incunabulum.net> In-Reply-To: <4B6ACC38.2030708@incunabulum.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ionice in 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, 05 Feb 2010 11:06:44 -0000 Great aclarations. Thanks. -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 5 11:07:38 2010 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 4205F1065696 for ; Fri, 5 Feb 2010 11:07:38 +0000 (UTC) (envelope-from jespasac@minibofh.org) Received: from smtp03.srv.cat (smtp03.cdmon.com [212.36.74.234]) by mx1.freebsd.org (Postfix) with ESMTP id 022568FC0C for ; Fri, 5 Feb 2010 11:07:37 +0000 (UTC) Received: from jespasac.cdmon.com (62.Red-217-126-43.staticIP.rima-tde.net [217.126.43.62]) (Authenticated sender: jespasac@noverificar) by smtp03.srv.cat (Postfix) with ESMTPA id C9B467C189 for ; Fri, 5 Feb 2010 12:07:36 +0100 (CET) Message-ID: <4B6BFBF8.8050302@minibofh.org> Date: Fri, 05 Feb 2010 12:07:36 +0100 From: Jordi Espasa Clofent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0b1 Thunderbird/3.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4B685EBA.4020501@minibofh.org> <4B695A1A.1000505@incunabulum.net> <4B696360.3070209@minibofh.org> <4B6ACC38.2030708@incunabulum.net> <20100204142045.GA86101@onelab2.iet.unipi.it> In-Reply-To: <20100204142045.GA86101@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: ionice in 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, 05 Feb 2010 11:07:38 -0000 Great work Luigi ;) That's amazing... anyway ¿is it production-ready? -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 5 11:20:53 2010 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 95763106566B; Fri, 5 Feb 2010 11:20:53 +0000 (UTC) (envelope-from prvs=065238b591=ob@sysadm.in) Received: from main.mx.e-gitt.net (service.rules.org [IPv6:2001:1560:2342::2]) by mx1.freebsd.org (Postfix) with ESMTP id 19AEE8FC0A; Fri, 5 Feb 2010 11:20:52 +0000 (UTC) Received: from tmo-108-84.customers.d1-online.com ([80.187.108.84] helo=[10.164.12.100]) by main.mx.e-gitt.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NdMEw-000EVJ-0Y; Fri, 05 Feb 2010 12:20:52 +0100 Message-ID: <4B6BFC66.6070300@sysadm.in> Date: Fri, 05 Feb 2010 12:09:26 +0100 From: Oliver Brandmueller User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.7) Gecko/20100123 Thunderbird/3.0.1 MIME-Version: 1.0 To: Randi Harper References: <20100122162155.GG3917@e-Gitt.NET> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Spam-Report: "gruft.de" scanned this message for spam and rated it at -1.4 points, 5.0 are required to tag a message as spam. In case of problems contact postmaster@mxbf.de pts rule name description ---- ---------------------- -------------------------------------------------- -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Flag: NO Cc: freebsd-stable@freebsd.org Subject: Re: 8.0-RELEASE -> -STABLE and size of / 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, 05 Feb 2010 11:20:53 -0000 Hi Randi, On 02/03/10 02:43, Randi Harper wrote: > This is going to happen. It's been on my to-do list for a while, as I > find it increasingly annoying. The default sizes of all mount points > need to be tweaked a bit. Be patient, there will be some new changes > going into sysinstall very soon. Great! Thank you! my next machine I again installed ZFS only, so there I didn't run into the topic :-) - Olli From owner-freebsd-stable@FreeBSD.ORG Fri Feb 5 11:29:37 2010 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 127CE106566C for ; Fri, 5 Feb 2010 11:29:37 +0000 (UTC) (envelope-from egypcio@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id 9A0338FC0A for ; Fri, 5 Feb 2010 11:29:36 +0000 (UTC) Received: by fxm26 with SMTP id 26so3654957fxm.33 for ; Fri, 05 Feb 2010 03:29:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=yEodzRiGIgJLNYJYZEdhBjV/NmnRW+NLbF/P88DVEus=; b=Y/vN5oHvhkUHuIi0f3wZHwqPTK2Ms6Wq+Sg+GyoG+bzb4rLsoKN30eUdt0uiVQxHaI kMpkFgARmnO2R0jfCR8Or63uo1tpneNUExE0rQDJp2U5p8ACS+mWV3aNOXJk0xNhnByp glmx73E3TkN4brc6pod+pDjF4PLUyaL2sTOMg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=vPM/6E0lC/gk+C1inh10x8KpEAXu+Y1nH63jxaSopK4Wt1qrJP1T/M/0kfZQv126ZR +ZLpuLoAnwHg9WyWKdXF+qOSfj3ggdIylaT17WF34hY32z4GXdu9zjcqn8QjI7p6MSwD 5RCitsp3URXMgoQPPffmidOxaiwKk49D/Rt88= MIME-Version: 1.0 Received: by 10.239.160.131 with SMTP id c3mr271121hbd.119.1265369375542; Fri, 05 Feb 2010 03:29:35 -0800 (PST) In-Reply-To: <8b5ad0e11001280245h703990a3t2085588e141b0ab6@mail.gmail.com> References: <8b5ad0e11001270926o19d1701fid30ba5a49cbb39b5@mail.gmail.com> <4B61295F.1030802@incunabulum.net> <8b5ad0e11001280245h703990a3t2085588e141b0ab6@mail.gmail.com> Date: Fri, 5 Feb 2010 08:29:35 -0300 Message-ID: <8b5ad0e11002050329n7fe0173aw735211d7eaea731f@mail.gmail.com> From: =?ISO-8859-1?Q?Zavam=2C_Vin=EDcius?= To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: freebsd 8.0 stable amd64/x86 needs ~9min to bootup 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, 05 Feb 2010 11:29:37 -0000 2010/1/28 Zavam, Vin=EDcius : > 2010/1/28 Bruce Simpson : >> Try GRUB4DOS. I use this so on boxes where I have Windows installed, I c= an >> keep GRUB in the NTFS partition. >> >> I haven't seen this issue and am tracking -STABLE on an ASUS V-series >> machine. >> > > Simpson, > I forgot to mention... but I tested it using boot0 (freebsd's > bootmanager) with no success ;< > > had no shots with grub4dos, gag, lilo or grub2; I assume it may not be > a bootmanager issue, but freebsd's btx bootstrap loader. > my gentoo and windows o.s. can be loaded using grub or boot0. > > > -- > Zavam, Vin=EDcius gentlemen, morning. I just did new fresh installs using 80-STABLE/amd64 and 90-CURRENT/amd64 snapshots. unfortunately, no success. when tryied the 90-CURRENT I've created a slice to /boot (d) at the beginning of the partition (ad4s4) and grub returned error code 18 [1]. strange. even installing in another slice, at the beginning of the disk (ad4s1), the bootup process was slow too. [1] http://wiki.linuxquestions.org/wiki/GRUB#Error_18 --=20 Zavam, Vin=EDcius From owner-freebsd-stable@FreeBSD.ORG Fri Feb 5 11:32:07 2010 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 74163106566B for ; Fri, 5 Feb 2010 11:32:07 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id E5D748FC1A for ; Fri, 5 Feb 2010 11:32:06 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id o15BW2Xr062652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Feb 2010 12:32:05 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4B6C01AB.5030500@omnilan.de> Date: Fri, 05 Feb 2010 12:31:55 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: freebsd-stable X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig120A922E0E2D3AAF348CCE25" Subject: 8.0-RELEASE hangs with lighttpd, unionfs related? Some traces included 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, 05 Feb 2010 11:32:07 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig120A922E0E2D3AAF348CCE25 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Hello, when I start lighttpd at boot time, the system half-locks in a way, that = any process, which accesses /usr/local/etc stalls. It's also impossible=20 to shut down. /usr/local/etc is unionfs mounted. I compiled a kernel with debug options. When mounting unionfs at boot time, here's the firt LOR with trace: lock order reversal: 1st 0xffffff00018b47f8 unionfs (unionfs) @=20 /usr/src/sys/fs/unionfs/union_subr.c:356 2nd 0xffffff00018d9d80 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2188 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x49 witness_checkorder() at witness_checkorder+0x7ea __lockmgr_args() at __lockmgr_args+0xcbd ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x50 vrele() at vrele+0x120 unionfs_noderem() at unionfs_noderem+0x1c4 unionfs_reclaim() at unionfs_reclaim+0x11 vgonel() at vgonel+0xf1 vrecycle() at vrecycle+0x58 unionfs_inactive() at uniougen2.2: at usbus2 nfs_inactive+ukbd0: 0 on usbus2 x20 vinactive() at vinactive+0x6b vput() at vput+0x216 kern_statatkbd1 at ukbd0 _vnhook() at kern_statat_vnhook+0xe9 kern_statat() at kern_statat+0x15 stat() at stat+0x22 syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- suhid0: y on usbus2 scall (188, FreeBSD ELF64, stat), rip =3D 0x8009a055c, rsp =3D=20 0x7fffffffe5b8, rbp =3D 0x800b312c0 --- KDB: enter: witness_checkorder [thread pid 27 tid 100068 ] Stopped at kdb_enter+0x3d: movq $0,0x4c04dc(%rip) Tracing pid 27 tid 100068 td 0xffffff00016fe720 kdb_enter() at kdb_enter+0x3d witness_checkorder() at witness_checkorder+0x7ea __lockmgr_args() at __lockmgr_args+0xcbd ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x50 vrele() at vrele+0x120 unionfs_noderem() at unionfs_noderem+0x1c4 unionfs_reclaim() at unionfs_reclaim+0x11 vgonel() at vgonel+0xf1 vrecycle() at vrecycle+0x58 unionfs_inactive() at unionfs_inactive+0x20 vinactive() at vinactive+0x6b vput() at vput+0x216 kern_statat_vnhook() at kern_statat_vnhook+0xe9 kern_statat() at kern_statat+0x15 stat() at stat+0x22 syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (188, FreeBSD ELF64, stat), rip =3D 0x8009a055c, rsp =3D=20 0x7fffffffe5b8, rbp =3D 0x800b312c0 - Like mentioned, there is that strange problem with lighttpd started at=20 boot time. Other /urs/local/etc/rc.d startups don't lead to a=20 /usr/local/etc deadlock. Unfortunately I don't get any panic or anything else when the hang happen= s. How can I aquire more information? It's no problem to log in and to do everything else outside=20 /usr/local/etc... =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Here's a LOR at shutdown with trace: lock order reversal: 1st 0xffffff0001bc2098 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1200 2nd 0xffffff0001bc1ba8 devfs (devfs) @=20 /usr/src/sys/ufs/ffs/ffs_vfsops.c:1194 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x49 witness_checkorder() at witness_checkorder+0x7ea __lockmgr_args() at __lockmgr_args+0xcbd vop_stdlock() at vop_stdlock+0x39 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x50 ffs_flushfiles() at ffs_flushfiles+0x93 ffs_unmount() at ffs_unmount+0x48 dounmount() at dounmount+0x2ac vfs_unmountall() at vfs_unmountall+0x54 boot() at boot+0x814 mkdumpheader() at mkdumpheader syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (55, FreeBSD ELF64, reboot), rip =3D 0x40829c, rsp =3D=20 0x7fffffffe738, rbp =3D 0x402290 --- KDB: enter: witness_checkorder [thread pid 1 tid 100002 ] Stopped at kdb_enter+0x3d: movq $0,0x4c04dc(%rip) Tracing pid 1 tid 100002 td 0xffffff0001310ab0 kdb_enter() at kdb_enter+0x3d witness_checkorder() at witness_checkorder+0x7ea __lockmgr_args() at __lockmgr_args+0xcbd vop_stdlock() at vop_stdlock+0x39 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x50 ffs_flushfiles() at ffs_flushfiles+0x93 ffs_unmount() at ffs_unmount+0x48 dounmount() at dounmount+0x2ac vfs_unmountall() at vfs_unmountall+0x54 boot() at boot+0x814 mkdumpheader() at mkdumpheader syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (55, FreeBSD ELF64, reboot), rip =3D 0x40829c, rsp =3D=20 0x7fffffffe738, rbp =3D 0x402290 --- Any Help highly appreciated! Thanks, -Harry --------------enig120A922E0E2D3AAF348CCE25 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAktsAbIACgkQLDqVQ9VXb8hGswCeJdmgieDOlI8iMCcqfTAye4aD Fe0AoMyVddRUyYig0/nXaQqus4Nl7KUz =dMun -----END PGP SIGNATURE----- --------------enig120A922E0E2D3AAF348CCE25-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 5 11:39:56 2010 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 C4969106566B for ; Fri, 5 Feb 2010 11:39:56 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id F13108FC16 for ; Fri, 5 Feb 2010 11:39:55 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id o15BdsmR062744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Feb 2010 12:39:54 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4B6C038A.9020500@omnilan.de> Date: Fri, 05 Feb 2010 12:39:54 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: freebsd-stable References: <4B6C01AB.5030500@omnilan.de> In-Reply-To: <4B6C01AB.5030500@omnilan.de> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig03798A21429BE8F6BCA74435" Subject: Reboot Loop: ffs_snapshot/bufwait LORs [Was: Re: 8.0-RELEASE hangs with lighttpd, unionfs related? Some traces included] 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, 05 Feb 2010 11:39:56 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig03798A21429BE8F6BCA74435 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Harald Schmalzbauer schrieb am 05.02.2010 12:31 (localtime): > Hello, >=20 > when I start lighttpd at boot time, the system half-locks in a way, tha= t=20 > any process, which accesses /usr/local/etc stalls. It's also impossible= =20 > to shut down. > /usr/local/etc is unionfs mounted. > I compiled a kernel with debug options. >=20 > When mounting unionfs at boot time, here's the firt LOR with trace: >=20 > lock order reversal: > 1st 0xffffff00018b47f8 unionfs (unionfs) @=20 > /usr/src/sys/fs/unionfs/union_subr.c:356 > 2nd 0xffffff00018d9d80 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2188 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x49 > witness_checkorder() at witness_checkorder+0x7ea > __lockmgr_args() at __lockmgr_args+0xcbd > ffs_lock() at ffs_lock+0x8c > VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b > _vn_lock() at _vn_lock+0x50 > vrele() at vrele+0x120 > unionfs_noderem() at unionfs_noderem+0x1c4 > unionfs_reclaim() at unionfs_reclaim+0x11 > vgonel() at vgonel+0xf1 > vrecycle() at vrecycle+0x58 > unionfs_inactive() at uniougen2.2: at usbus2 > nfs_inactive+ukbd0: 0 1.10/1.01, addr 2> on usbus2 > x20 > vinactive() at vinactive+0x6b > vput() at vput+0x216 > kern_statatkbd1 at ukbd0 > _vnhook() at kern_statat_vnhook+0xe9 > kern_statat() at kern_statat+0x15 > stat() at stat+0x22 > syscall() at syscall+0x1af > Xfast_syscall() at Xfast_syscall+0xe1 > --- suhid0: y addr 2> on usbus2 > scall (188, FreeBSD ELF64, stat), rip =3D 0x8009a055c, rsp =3D=20 > 0x7fffffffe5b8, rbp =3D 0x800b312c0 --- > KDB: enter: witness_checkorder > [thread pid 27 tid 100068 ] > Stopped at kdb_enter+0x3d: movq $0,0x4c04dc(%rip) > Tracing pid 27 tid 100068 td 0xffffff00016fe720 > kdb_enter() at kdb_enter+0x3d > witness_checkorder() at witness_checkorder+0x7ea > __lockmgr_args() at __lockmgr_args+0xcbd > ffs_lock() at ffs_lock+0x8c > VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b > _vn_lock() at _vn_lock+0x50 > vrele() at vrele+0x120 > unionfs_noderem() at unionfs_noderem+0x1c4 > unionfs_reclaim() at unionfs_reclaim+0x11 > vgonel() at vgonel+0xf1 > vrecycle() at vrecycle+0x58 > unionfs_inactive() at unionfs_inactive+0x20 > vinactive() at vinactive+0x6b > vput() at vput+0x216 > kern_statat_vnhook() at kern_statat_vnhook+0xe9 > kern_statat() at kern_statat+0x15 > stat() at stat+0x22 > syscall() at syscall+0x1af > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (188, FreeBSD ELF64, stat), rip =3D 0x8009a055c, rsp =3D=20 > 0x7fffffffe5b8, rbp =3D 0x800b312c0 - >=20 >=20 > Like mentioned, there is that strange problem with lighttpd started at = > boot time. Other /urs/local/etc/rc.d startups don't lead to a=20 > /usr/local/etc deadlock. > Unfortunately I don't get any panic or anything else when the hang happ= ens. > How can I aquire more information? > It's no problem to log in and to do everything else outside=20 > /usr/local/etc... >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Here's a LOR at shutdown with trace: >=20 > lock order reversal: > 1st 0xffffff0001bc2098 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1200 > 2nd 0xffffff0001bc1ba8 devfs (devfs) @=20 > /usr/src/sys/ufs/ffs/ffs_vfsops.c:1194 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x49 > witness_checkorder() at witness_checkorder+0x7ea > __lockmgr_args() at __lockmgr_args+0xcbd > vop_stdlock() at vop_stdlock+0x39 > VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b > _vn_lock() at _vn_lock+0x50 > ffs_flushfiles() at ffs_flushfiles+0x93 > ffs_unmount() at ffs_unmount+0x48 > dounmount() at dounmount+0x2ac > vfs_unmountall() at vfs_unmountall+0x54 > boot() at boot+0x814 > mkdumpheader() at mkdumpheader > syscall() at syscall+0x1af > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (55, FreeBSD ELF64, reboot), rip =3D 0x40829c, rsp =3D=20 > 0x7fffffffe738, rbp =3D 0x402290 --- > KDB: enter: witness_checkorder > [thread pid 1 tid 100002 ] > Stopped at kdb_enter+0x3d: movq $0,0x4c04dc(%rip) >=20 > Tracing pid 1 tid 100002 td 0xffffff0001310ab0 > kdb_enter() at kdb_enter+0x3d > witness_checkorder() at witness_checkorder+0x7ea > __lockmgr_args() at __lockmgr_args+0xcbd > vop_stdlock() at vop_stdlock+0x39 > VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b > _vn_lock() at _vn_lock+0x50 > ffs_flushfiles() at ffs_flushfiles+0x93 > ffs_unmount() at ffs_unmount+0x48 > dounmount() at dounmount+0x2ac > vfs_unmountall() at vfs_unmountall+0x54 > boot() at boot+0x814 > mkdumpheader() at mkdumpheader > syscall() at syscall+0x1af > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (55, FreeBSD ELF64, reboot), rip =3D 0x40829c, rsp =3D=20 > 0x7fffffffe738, rbp =3D 0x402290 --- >=20 > Any Help highly appreciated! >=20 > Thanks, >=20 > -Harry Additional LORs while regular machine operation (background fsck) which=20 leads to reboot! I have access over the serail console, but the machine is unresponsive=20 after that. So I'm now in a endelss reboot loop with the debug kernel... lock order reversal: 1st 0xffffff0001b899d0 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:= 423 2nd 0xffffff802970fc28 bufwait (bufwait) @=20 /usr/src/sys/kern/vfs_bio.c:2559 3rd 0xffffff00018b4448 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:= 544 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x49 witness_checkorder() at witness_checkorder+0x7ea __lockmgr_args() at __lockmgr_args+0xcbd ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x50 ffs_snapshot() at ffs_snapshot+0x1b70 ffs_mount() at ffs_mount+0x651 vfs_donmount() at vfs_donmount+0xcd4 nmount() at nmount+0x74 syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (378, FreeBSD ELF64, nmount), rip =3D 0x8007acfec, rsp =3D=20 0x7fffffffe988, rbp =3D 0x800a028e- KDB: enter: witness_checkorder [thread pid 947 tid 100073 ] Stopped at kdb_enter+0x3d: movq $0,0x4c04dc(%rip) db> lock order reversal: 1st 0xffffff00018b4470 vnode interlock (vnode interlock) @=20 /usr/src/sys/ufs/ffs/ffs_snapshot.c:523 2nd 0xffffff8000422028 uhci2 (uhci2) @=20 /usr/src/sys/dev/usb/controller/uhci.c:1551 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x49 witness_checkorder() at witness_checkorder+0x7ea _mtx_lock_flags() at _mtx_lock_flags+0x68 uhci_do_poll() at uhci_do_poll+0x2e usbd_transfer_poll() at usbd_transfer_poll+0x18d ukbd_do_poll() at ukbd_do_poll+0x63 ukbd_get_key() at ukbd_get_key+0xa8 ukbd_read_char() at ukbd_read_char+0xaa scgetc() at scgetc+0x5b sc_cngetc() at sc_cngetc+0xf2 cncheckc() at cncheckc+0x65 cngetc() at cngetc+0x1c db_readline() at db_readline+0x79 db_read_line() at db_read_line+0x15 db_command_loop() at db_command_loop+0x38 db_trap() at db_trap+0x87 kdb_trap() at kdb_trap+0x82 trap() at trap+0x18f calltrap() at calltrap+0x8 --- trap 0x3, rip =3D 0xffffffff80381141, rsp =3D 0xffffff803e959000, rbp= =3D=20 0xffffff803e959020 --- kdb_enter() at kdb_enter+0x3d witness_checkorder() at witness_checkorder+0x7ea __lockmgr_args() at __lockmgr_args+0xcbd ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x50 ffs_snapshot() at ffs_snapshot+0x1b70 ffs_mount() at ffs_mount+0x651 vfs_donmount() at vfs_donmount+0xcd4 nmount() at nmount+0x74 syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (378, FreeBSD ELF64, nmount), rip =3D 0x8007acfec, rsp =3D=20 0x7fffffffe988, rbp =3D 0x800a028e- lock order reversal: 1st 0xffffff00018b4470 vnode interlock (vnode interlock) @=20 /usr/src/sys/ufs/ffs/ffs_snapshot.c:523 2nd 0xffffff0001747890 USB device mutex (USB device mutex) @=20 /usr/src/sys/dev/usb/usb_device.c:1410 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x49 witness_checkorder() at witness_checkorder+0x7ea _mtx_lock_flags() at _mtx_lock_flags+0x68 usbd_clear_stall_proc() at usbd_clear_stall_proc+0x49 usbd_transfer_poll() at usbd_transfer_poll+0x1c0 ukbd_do_poll() at ukbd_do_poll+0x63 ukbd_get_key() at ukbd_get_key+0xa8 ukbd_read_char() at ukbd_read_char+0xaa scgetc() at scgetc+0x5b sc_cngetc() at sc_cngetc+0xf2 cncheckc() at cncheckc+0x65 cngetc() at cngetc+0x1c db_readline() at db_readline+0x79 db_read_line() at db_read_line+0x15 db_command_loop() at db_command_loop+0x38 db_trap() at db_trap+0x87 kdb_trap() at kdb_trap+0x82 trap() at trap+0x18f calltrap() at calltrap+0x8 --- trap 0x3, rip =3D 0xffffffff80381141, rsp =3D 0xffffff803e959000, rbp= =3D=20 0xffffff803e959020 --- kdb_enter() at kdb_enter+0x3d witness_checkorder() at witness_checkorder+0x7ea __lockmgr_args() at __lockmgr_args+0xcbd ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x50 ffs_snapshot() at ffs_snapshot+0x1b70 ffs_mount() at ffs_mount+0x651 vfs_donmount() at vfs_donmount+0xcd4 nmount() at nmount+0x74 syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (378, FreeBSD ELF64, nmount), rip =3D 0x8007acfec, rsp =3D=20 0x7fffffffe988, rbp =3D 0x800a028e- lock order reversal: (Giant after non-sleepable) 1st 0xffffff00018b4470 vnode interlock (vnode interlock) @=20 /usr/src/sys/ufs/ffs/ffs_snapshot.c:523 2nd 0xffffffff80820780 Giant (Giant) @=20 /usr/src/sys/dev/usb/usb_transfer.c:1952 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x49 witness_checkorder() at witness_checkorder+0x7ea _mtx_lock_flags() at _mtx_lock_flags+0x68 usb_callback_proc() at usb_callback_proc+0x48 usbd_transfer_poll() at usbd_transfer_poll+0x1e9 ukbd_do_poll() at ukbd_do_poll+0x63 ukbd_get_key() at ukbd_get_key+0xa8 ukbd_read_char() at ukbd_read_char+0xaa scgetc() at scgetc+0x5b sc_cngetc() at sc_cngetc+0xf2 cncheckc() at cncheckc+0x65 cngetc() at cngetc+0x1c db_readline() at db_readline+0x79 db_read_line() at db_read_line+0x15 db_command_loop() at db_command_loop+0x38 db_trap() at db_trap+0x87 kdb_trap() at kdb_trap+0x82 trap() at trap+0x18f calltrap() at calltrap+0x8 --- trap 0x3, rip =3D 0xffffffff80381141, rsp =3D 0xffffff803e959000, rbp= =3D=20 0xffffff803e959020 --- kdb_enter() at kdb_enter+0x3d witness_checkorder() at witness_checkorder+0x7ea __lockmgr_args() at __lockmgr_args+0xcbd ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x50 ffs_snapshot() at ffs_snapshot+0x1b70 ffs_mount() at ffs_mount+0x651 vfs_donmount() at vfs_donmount+0xcd4 nmount() at nmount+0x74 syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (378, FreeBSD ELF64, nmount), rip =3D 0x8007acfec, rsp =3D=20 0x7fffffffe988, rbp =3D 0x800a028e- lock order reversal: 1st 0xffffff802970fc28 bufwait (bufwait) @=20 /usr/src/sys/kern/vfs_bio.c:2559 2nd 0xffffff00440ef6b0 snaplk (snaplk) @=20 /usr/src/sys/ufs/ffs/ffs_snapshot.c:793 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x49 witness_checkorder() at witness_checkorder+0x7ea __lockmgr_args() at __lockmgr_args+0xcbd ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x50 ffs_snapshot() at ffs_snapshot+0x17d7 ffs_mount() at ffs_mount+0x651 vfs_donmount() at vfs_donmount+0xcd4 nmount() at nmount+0x74 syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (378, FreeBSD ELF64, nmount), rip =3D 0x8007acfec, rsp =3D=20 0x7fffffffe988, rbp =3D 0x800a028e- KDB: enter: witness_checkorder [thread pid 947 tid 100073 ] Stopped at kdb_enter+0x3d: movq $0,0x4c04dc(%rip) Thanks for any help, -Harry --------------enig03798A21429BE8F6BCA74435 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAktsA4oACgkQLDqVQ9VXb8guUgCdGFG3SthcgOQ6NtiR9pyFqtAd TAwAnRaC87hoy0vfIHOgRwEF60Im17KQ =jlMu -----END PGP SIGNATURE----- --------------enig03798A21429BE8F6BCA74435-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 5 11:50:02 2010 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 74A8E106568F for ; Fri, 5 Feb 2010 11:50:02 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 9C4628FC1D for ; Fri, 5 Feb 2010 11:50:01 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id o15Bo0Xd062876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Feb 2010 12:50:00 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4B6C05E7.2040503@omnilan.de> Date: Fri, 05 Feb 2010 12:49:59 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: freebsd-stable References: <4B6C01AB.5030500@omnilan.de> <4B6C038A.9020500@omnilan.de> In-Reply-To: <4B6C038A.9020500@omnilan.de> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6F2DD4F11A48E75DF85E15AF" Subject: Re: Reboot Loop: ffs_snapshot/bufwait LORs [Was: Re: 8.0-RELEASE hangs with lighttpd, unionfs related? Some traces included] 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, 05 Feb 2010 11:50:02 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6F2DD4F11A48E75DF85E15AF Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Harald Schmalzbauer schrieb am 05.02.2010 12:39 (localtime): > Harald Schmalzbauer schrieb am 05.02.2010 12:31 (localtime): =2E.. >=20 > Additional LORs while regular machine operation (background fsck) which= =20 > leads to reboot! > I have access over the serail console, but the machine is unresponsive = > after that. So I'm now in a endelss reboot loop with the debug kernel..= =2E >=20 > lock order reversal: > 1st 0xffffff0001b899d0 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c= :423 > 2nd 0xffffff802970fc28 bufwait (bufwait) @=20 > /usr/src/sys/kern/vfs_bio.c:2559 > 3rd 0xffffff00018b4448 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c= :544 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x49 > witness_checkorder() at witness_checkorder+0x7ea > __lockmgr_args() at __lockmgr_args+0xcbd > ffs_lock() at ffs_lock+0x8c > VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b > _vn_lock() at _vn_lock+0x50 > ffs_snapshot() at ffs_snapshot+0x1b70 > ffs_mount() at ffs_mount+0x651 > vfs_donmount() at vfs_donmount+0xcd4 > nmount() at nmount+0x74 > syscall() at syscall+0x1af > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (378, FreeBSD ELF64, nmount), rip =3D 0x8007acfec, rsp =3D = > 0x7fffffffe988, rbp =3D 0x800a028e- > KDB: enter: witness_checkorder > [thread pid 947 tid 100073 ] > Stopped at kdb_enter+0x3d: movq $0,0x4c04dc(%rip) > db> lock order reversal: > 1st 0xffffff00018b4470 vnode interlock (vnode interlock) @=20 > /usr/src/sys/ufs/ffs/ffs_snapshot.c:523 > 2nd 0xffffff8000422028 uhci2 (uhci2) @=20 > /usr/src/sys/dev/usb/controller/uhci.c:1551 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x49 > witness_checkorder() at witness_checkorder+0x7ea > _mtx_lock_flags() at _mtx_lock_flags+0x68 > uhci_do_poll() at uhci_do_poll+0x2e > usbd_transfer_poll() at usbd_transfer_poll+0x18d > ukbd_do_poll() at ukbd_do_poll+0x63 > ukbd_get_key() at ukbd_get_key+0xa8 > ukbd_read_char() at ukbd_read_char+0xaa > scgetc() at scgetc+0x5b > sc_cngetc() at sc_cngetc+0xf2 > cncheckc() at cncheckc+0x65 > cngetc() at cngetc+0x1c > db_readline() at db_readline+0x79 > db_read_line() at db_read_line+0x15 > db_command_loop() at db_command_loop+0x38 > db_trap() at db_trap+0x87 > kdb_trap() at kdb_trap+0x82 > trap() at trap+0x18f > calltrap() at calltrap+0x8 > --- trap 0x3, rip =3D 0xffffffff80381141, rsp =3D 0xffffff803e959000, r= bp =3D=20 > 0xffffff803e959020 --- > kdb_enter() at kdb_enter+0x3d > witness_checkorder() at witness_checkorder+0x7ea > __lockmgr_args() at __lockmgr_args+0xcbd > ffs_lock() at ffs_lock+0x8c > VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b > _vn_lock() at _vn_lock+0x50 > ffs_snapshot() at ffs_snapshot+0x1b70 > ffs_mount() at ffs_mount+0x651 > vfs_donmount() at vfs_donmount+0xcd4 > nmount() at nmount+0x74 > syscall() at syscall+0x1af > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (378, FreeBSD ELF64, nmount), rip =3D 0x8007acfec, rsp =3D = > 0x7fffffffe988, rbp =3D 0x800a028e- > lock order reversal: > 1st 0xffffff00018b4470 vnode interlock (vnode interlock) @=20 > /usr/src/sys/ufs/ffs/ffs_snapshot.c:523 > 2nd 0xffffff0001747890 USB device mutex (USB device mutex) @=20 > /usr/src/sys/dev/usb/usb_device.c:1410 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x49 > witness_checkorder() at witness_checkorder+0x7ea > _mtx_lock_flags() at _mtx_lock_flags+0x68 > usbd_clear_stall_proc() at usbd_clear_stall_proc+0x49 > usbd_transfer_poll() at usbd_transfer_poll+0x1c0 > ukbd_do_poll() at ukbd_do_poll+0x63 > ukbd_get_key() at ukbd_get_key+0xa8 > ukbd_read_char() at ukbd_read_char+0xaa > scgetc() at scgetc+0x5b > sc_cngetc() at sc_cngetc+0xf2 > cncheckc() at cncheckc+0x65 > cngetc() at cngetc+0x1c > db_readline() at db_readline+0x79 > db_read_line() at db_read_line+0x15 > db_command_loop() at db_command_loop+0x38 > db_trap() at db_trap+0x87 > kdb_trap() at kdb_trap+0x82 > trap() at trap+0x18f > calltrap() at calltrap+0x8 > --- trap 0x3, rip =3D 0xffffffff80381141, rsp =3D 0xffffff803e959000, r= bp =3D=20 > 0xffffff803e959020 --- > kdb_enter() at kdb_enter+0x3d > witness_checkorder() at witness_checkorder+0x7ea > __lockmgr_args() at __lockmgr_args+0xcbd > ffs_lock() at ffs_lock+0x8c > VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b > _vn_lock() at _vn_lock+0x50 > ffs_snapshot() at ffs_snapshot+0x1b70 > ffs_mount() at ffs_mount+0x651 > vfs_donmount() at vfs_donmount+0xcd4 > nmount() at nmount+0x74 > syscall() at syscall+0x1af > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (378, FreeBSD ELF64, nmount), rip =3D 0x8007acfec, rsp =3D = > 0x7fffffffe988, rbp =3D 0x800a028e- > lock order reversal: (Giant after non-sleepable) > 1st 0xffffff00018b4470 vnode interlock (vnode interlock) @=20 > /usr/src/sys/ufs/ffs/ffs_snapshot.c:523 > 2nd 0xffffffff80820780 Giant (Giant) @=20 > /usr/src/sys/dev/usb/usb_transfer.c:1952 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x49 > witness_checkorder() at witness_checkorder+0x7ea > _mtx_lock_flags() at _mtx_lock_flags+0x68 > usb_callback_proc() at usb_callback_proc+0x48 > usbd_transfer_poll() at usbd_transfer_poll+0x1e9 > ukbd_do_poll() at ukbd_do_poll+0x63 > ukbd_get_key() at ukbd_get_key+0xa8 > ukbd_read_char() at ukbd_read_char+0xaa > scgetc() at scgetc+0x5b > sc_cngetc() at sc_cngetc+0xf2 > cncheckc() at cncheckc+0x65 > cngetc() at cngetc+0x1c > db_readline() at db_readline+0x79 > db_read_line() at db_read_line+0x15 > db_command_loop() at db_command_loop+0x38 > db_trap() at db_trap+0x87 > kdb_trap() at kdb_trap+0x82 > trap() at trap+0x18f > calltrap() at calltrap+0x8 > --- trap 0x3, rip =3D 0xffffffff80381141, rsp =3D 0xffffff803e959000, r= bp =3D=20 > 0xffffff803e959020 --- > kdb_enter() at kdb_enter+0x3d > witness_checkorder() at witness_checkorder+0x7ea > __lockmgr_args() at __lockmgr_args+0xcbd > ffs_lock() at ffs_lock+0x8c > VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b > _vn_lock() at _vn_lock+0x50 > ffs_snapshot() at ffs_snapshot+0x1b70 > ffs_mount() at ffs_mount+0x651 > vfs_donmount() at vfs_donmount+0xcd4 > nmount() at nmount+0x74 > syscall() at syscall+0x1af > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (378, FreeBSD ELF64, nmount), rip =3D 0x8007acfec, rsp =3D = > 0x7fffffffe988, rbp =3D 0x800a028e- >=20 > lock order reversal: > 1st 0xffffff802970fc28 bufwait (bufwait) @=20 > /usr/src/sys/kern/vfs_bio.c:2559 > 2nd 0xffffff00440ef6b0 snaplk (snaplk) @=20 > /usr/src/sys/ufs/ffs/ffs_snapshot.c:793 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x49 > witness_checkorder() at witness_checkorder+0x7ea > __lockmgr_args() at __lockmgr_args+0xcbd > ffs_lock() at ffs_lock+0x8c > VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b > _vn_lock() at _vn_lock+0x50 > ffs_snapshot() at ffs_snapshot+0x17d7 > ffs_mount() at ffs_mount+0x651 > vfs_donmount() at vfs_donmount+0xcd4 > nmount() at nmount+0x74 > syscall() at syscall+0x1af > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (378, FreeBSD ELF64, nmount), rip =3D 0x8007acfec, rsp =3D = > 0x7fffffffe988, rbp =3D 0x800a028e- > KDB: enter: witness_checkorder > [thread pid 947 tid 100073 ] > Stopped at kdb_enter+0x3d: movq $0,0x4c04dc(%rip) Sorry, it was my watchdog who restarted the machine. Here's the trace I coudl get: Tracing pid 918 tid 100072 td 0xffffff0001816390 kdb_enter() at kdb_enter+0x3d witness_checkorder() at witness_checkorder+0x7ea __lockmgr_args() at __lockmgr_args+0xcbd ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x50 ffs_snapshot() at ffs_snapshot+0x1b70 ffs_mount() at ffs_mount+0x651 vfs_donmount() at vfs_donmount+0xcd4 nmount() at nmount+0x74 syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (378, FreeBSD ELF64, nmount), rip =3D 0x8007acfec, rsp =3D=20 0x7fffffffe988, rbp =3D 0x800a028e- =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 And another LOR after cont: lock order reversal: 1st 0xffffff0001e40d30 snaplk (snaplk) @ /usr/src/sys/kern/vfs_vnops.c:= 296 2nd 0xffffff00018a49d0 ufs (ufs) @=20 /usr/src/sys/ufs/ffs/ffs_snapshot.c:1587 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x49 witness_checkorder() at witness_checkorder+0x7ea __lockmgr_args() at __lockmgr_args+0xcbd ffs_snapremove() at ffs_snapremove+0xe2 softdep_releasefile() at softdep_releasefile+0x133 ufs_inactive() at ufs_inactive+0x185 vinactive() at vinactive+0x6b vput() at vput+0x216 vn_close() at vn_close+0x10b vn_closefile() at vn_closefile+0x51 _fdrop() at _fdrop+0x20 closef() at closef+0x58 kern_close() at kern_close+0xff syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (6, FreeBSD ELF64, close), rip =3D 0x8008435ec, rsp =3D=20 0x7fffffffe988, rbp =3D 0 --- KDB: enter: witness_checkorder [thread pid 914 tid 100080 ] Stopped at kdb_enter+0x3d: movq $0,0x4c04dc(%rip) db> trace Tracing pid 914 tid 100080 td 0xffffff000186dab0 kdb_enter() at kdb_enter+0x3d witness_checkorder() at witness_checkorder+0x7ea __lockmgr_args() at __lockmgr_args+0xcbd ffs_snapremove() at ffs_snapremove+0xe2 softdep_releasefile() at softdep_releasefile+0x133 ufs_inactive() at ufs_inactive+0x185 vinactive() at vinactive+0x6b vput() at vput+0x216 vn_close() at vn_close+0x10b vn_closefile() at vn_closefile+0x51 _fdrop() at _fdrop+0x20 closef() at closef+0x58 kern_close() at kern_close+0xff syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (6, FreeBSD ELF64, close), rip =3D 0x8008435ec, rsp =3D=20 0x7fffffffe988, rbp =3D 0 --- Thanks, -Harry --------------enig6F2DD4F11A48E75DF85E15AF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAktsBegACgkQLDqVQ9VXb8j0awCgo5t02dQXe6B/hitFgF3k2e53 UMAAnjl+Rre9bwrI7VXrWyA0yUWcqXid =5RJL -----END PGP SIGNATURE----- --------------enig6F2DD4F11A48E75DF85E15AF-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 5 13:35:05 2010 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 C94ED1065672 for ; Fri, 5 Feb 2010 13:35:05 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5051D8FC14 for ; Fri, 5 Feb 2010 13:35:05 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o15DYmUT070828; Fri, 5 Feb 2010 14:35:04 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o15DYm0a070827; Fri, 5 Feb 2010 14:34:48 +0100 (CET) (envelope-from olli) Date: Fri, 5 Feb 2010 14:34:48 +0100 (CET) Message-Id: <201002051334.o15DYm0a070827@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (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]); Fri, 05 Feb 2010 14:35:04 +0100 (CET) Cc: Subject: amdtemp(4) oddities, Athlon 64 X2 (8-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: Fri, 05 Feb 2010 13:35:06 -0000 This is a RELENG_8 box, csupped on 2010-01-22, kernel built with amdtemp(4). It's a dual-core Athlon 64, running i386 (32bit) SMP. Excerpt from dmesg: CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ (2009.28-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x40fb2 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f [...] FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) [...] amdtemp0: on hostb3 sysctl displays the following values (idle system): dev.cpu.0.temperature: 14.0C dev.cpu.1.temperature: 14.0C dev.amdtemp.0.sensor0.core0: 14.0C dev.amdtemp.0.sensor0.core1: 22.0C dev.amdtemp.0.sensor1.core0: -49.0C dev.amdtemp.0.sensor1.core1: -49.0C hw.acpi.thermal.tz0.temperature: 40.0C Upon consecutive calls, the first three vary from 13.0C to 16.0C, which is below room temperature, so it can't be true. The fourth one varies from 22.0C to 23.0C, which might be correct, although it still seems a bit low, even on an idle system. Under load (buildworld -j4), it looks like this: dev.cpu.0.temperature: 38.0C dev.cpu.1.temperature: 39.0C dev.amdtemp.0.sensor0.core0: 38.0C dev.amdtemp.0.sensor0.core1: 44.0C dev.amdtemp.0.sensor1.core0: -49.0C dev.amdtemp.0.sensor1.core1: -49.0C hw.acpi.thermal.tz0.temperature: 40.0C That's the maximum readings I've seen: The first three go up to 39.0C, the fourth one reaches 44.0C (I've never seen values higher than this). The first three are always about the same (+/-1), and the fourth is always 4 to 6 more. When buildworld -j4 is finished, the values quickly go down and reach the ones given for the idle system above after a few minutes. BTW, the machine is running powerd(8) which reduces the CPU clock from 2000 to 1000 when it is idle. The sensor1.* values are always fixed at -49.0C, and the ACPI temperature stays at exactly 40.0C. These three don't seem to be connected to any actual sensors. I'm not too worried about those. I've got two questions: First, I'm wondering why sensor0.core1 is different from all the other values. I think it should be the same as the dev.cpu.1.temperature value. This smells like a bug. According to the description in the manual page, I would expect it to be the same. Second, the temperature readings on the idle system are too low. I don't think they can realistically be below room temperature. 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 With Perl you can manipulate text, interact with programs, talk over networks, drive Web pages, perform arbitrary precision arithmetic, and write programs that look like Snoopy swearing. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 5 13:36:48 2010 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 C036010656A3 for ; Fri, 5 Feb 2010 13:36:48 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 934938FC19 for ; Fri, 5 Feb 2010 13:36:48 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 45ED946B2A; Fri, 5 Feb 2010 08:36:48 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 8B8A88A024; Fri, 5 Feb 2010 08:36:47 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Fri, 5 Feb 2010 08:27:53 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <4B6B89E7.8030002@sdf.lonestar.org> In-Reply-To: <4B6B89E7.8030002@sdf.lonestar.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201002050827.53343.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 05 Feb 2010 08:36:47 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.3 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Tom McLaughlin Subject: Re: Recent MFC to 7 causes crash on VMware ESXi 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, 05 Feb 2010 13:36:48 -0000 On Thursday 04 February 2010 10:00:55 pm Tom McLaughlin wrote: > Hi all, a recent MFC to 7-STABLE has started to cause issues for my VMs > on VMware ESXi 3.5u4. After loading the mpt driver for the LSI disk > controller the VM just shuts off. The workaround is to change the disk > controller to the BusLogic type. Still, it used to work up until last > week. The change was made around January 26th and based on the commits > that day I'm guessing it's either r203047 or r203073 > > I have the same issue with both amd64 and i386 VMs. This affects HEAD > and 8-STABLE as well and first affected HEAD over the summer. (I just > worked around it and went about my business at the time. :-/) I've > attached a dmesg from a kernel before the problem and one from after it > started. What if you set 'hw.clfush_disable=1' from the loader? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Feb 5 14:01:08 2010 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 DF9B610656A3; Fri, 5 Feb 2010 14:01:08 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 50D668FC0A; Fri, 5 Feb 2010 14:01:08 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o15E0pZe071853; Fri, 5 Feb 2010 15:01:07 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o15E0p2T071852; Fri, 5 Feb 2010 15:00:51 +0100 (CET) (envelope-from olli) Date: Fri, 5 Feb 2010 15:00:51 +0100 (CET) Message-Id: <201002051400.o15E0p2T071852@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, randi@FreeBSD.ORG In-Reply-To: X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (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]); Fri, 05 Feb 2010 15:01:07 +0100 (CET) Cc: Subject: Re: 8.0-RELEASE -> -STABLE and size of / X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, randi@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, 05 Feb 2010 14:01:09 -0000 Randi Harper wrote: > Marian Hettwer wrote: > > +1 vote for making / bigger. > > At least a size where a make installkernel runs through. > > This is going to happen. It's been on my to-do list for a while, as I > find it increasingly annoying. The default sizes of all mount points > need to be tweaked a bit. Be patient, there will be some new changes > going into sysinstall very soon. Revisiting sysinstall's default partition sizes is certainly a good idea. However, I think it makes a lot of sense to *not* install symbol files in /boot/kernel by default. I can't think of a good reason why they need to be there by default, and they're what causes the space problems for the root FS in the first place. Please change the default. 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 "If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor, and when was the last time you needed one?" -- Tom Cargil, C++ Journal From owner-freebsd-stable@FreeBSD.ORG Fri Feb 5 14:26:21 2010 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 C8DDF1065672 for ; Fri, 5 Feb 2010 14:26:21 +0000 (UTC) (envelope-from mail@vas.org.ua) Received: from relay.electro.ua (electro.ua [213.186.192.234]) by mx1.freebsd.org (Postfix) with ESMTP id 7EB058FC1B for ; Fri, 5 Feb 2010 14:26:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by relay.electro.ua (Postfix) with ESMTP id 7C8661708F; Fri, 5 Feb 2010 16:26:19 +0200 (EET) X-Virus-Scanned: amavisd-new at http.org.ua Received: from relay.electro.ua ([127.0.0.1]) by localhost (http.org.ua [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ZVxfYU3OEeHp; Fri, 5 Feb 2010 16:26:19 +0200 (EET) Received: from [192.168.1.100] (blonde.org.ua [213.186.192.244]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by relay.electro.ua (Postfix) with ESMTPSA id 338371708B; Fri, 5 Feb 2010 16:26:19 +0200 (EET) Message-ID: <4B6C2A96.3000305@vas.org.ua> Date: Fri, 05 Feb 2010 16:26:30 +0200 From: Vasyl Samoilov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; uk; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-stable References: <201002051334.o15DYm0a070827@lurza.secnetix.de> In-Reply-To: <201002051334.o15DYm0a070827@lurza.secnetix.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Oliver Fromme Subject: Re: amdtemp(4) oddities, Athlon 64 X2 (8-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: Fri, 05 Feb 2010 14:26:21 -0000 05.02.2010 15:34, Oliver Fromme напиÑав(ла): > This is a RELENG_8 box, csupped on 2010-01-22, kernel built > with amdtemp(4). It's a dual-core Athlon 64, running i386 > (32bit) SMP. Excerpt from dmesg: > > CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ (2009.28-MHz 686-class CPU) > Origin = "AuthenticAMD" Id = 0x40fb2 Stepping = 2 > Features=0x178bfbff > Features2=0x2001 > AMD Features=0xea500800 > AMD Features2=0x1f > [...] > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) > [...] > amdtemp0: on hostb3 > > sysctl displays the following values (idle system): > > dev.cpu.0.temperature: 14.0C > dev.cpu.1.temperature: 14.0C > dev.amdtemp.0.sensor0.core0: 14.0C > dev.amdtemp.0.sensor0.core1: 22.0C > dev.amdtemp.0.sensor1.core0: -49.0C > dev.amdtemp.0.sensor1.core1: -49.0C > hw.acpi.thermal.tz0.temperature: 40.0C > It's not Freebsd, it's cpu issuses. For brisbane core cpus CoreTemp author reported many times than the internal sensor seems to be defective because it reads ilogical temperatures. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 5 14:30:20 2010 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 8A222106566B for ; Fri, 5 Feb 2010 14:30:20 +0000 (UTC) (envelope-from danilomussolini@gmail.com) Received: from mail-yw0-f191.google.com (mail-yw0-f191.google.com [209.85.211.191]) by mx1.freebsd.org (Postfix) with ESMTP id 4B2FB8FC17 for ; Fri, 5 Feb 2010 14:30:20 +0000 (UTC) Received: by ywh29 with SMTP id 29so3556070ywh.13 for ; Fri, 05 Feb 2010 06:30:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:content-type; bh=A+Dw5kvbgPRzZ9UiJQGAMdYMiVYR+fLagAd1f5nFCtA=; b=ulhl2RC8XN2yP2QEcPRJIHmLxLrvrk/yBrkhljCAYFL++UmOtrMzLI3CkiC224IFjw AwABz66xq7JtX6ZtSNoVjB1kNStEmF7c0QZpTDuKw3qRUIvqwTkwnhU9jHOZCP1aurtW n2b0jlQJ3PTAs1OW6kPW7AeXubxZds1cVEql0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=v7pULTGnJYJLvtlQMn4yECWUXMdaO5W0IJAecvk58mbmeEs4BZ2TQit0tQYVAvwr5D WublmCpmkevIFZ+N/qhjDWwlJUIQNyVZIetYHi0u6e18IzafHCQYXaBgrs8U9A6y5l1I tDr64oIQAqTrl4wTexlTpa4DRBwsudpAz2MKw= MIME-Version: 1.0 Received: by 10.91.50.9 with SMTP id c9mr2586699agk.116.1265378478124; Fri, 05 Feb 2010 06:01:18 -0800 (PST) From: Danilo Mussolini Date: Fri, 5 Feb 2010 12:00:58 -0200 Message-ID: <132a58b51002050600t768ff95fs1d922d5ce470c26d@mail.gmail.com> To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: FreeBSD 8-Stable with Samba too slow 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, 05 Feb 2010 14:30:20 -0000 Hi all, I have just installed FreeBSD 8.0-STABLE-201001 to work as a file server running samba 3.3.9 installed by ports. But, I don't know why, when I try to access the share by Windows or by Linux, it is so slow. I takes a long time to give the authentication window and when I manage authenticate It keeps so slow to browse directories and files. And the interesting thing is that when I reach the share with my files (*.iso for tests) after a long time and start a copy, the transfer goes so good, in a normal gigabit speed. I tried compiling and installing samba 3.4.5 and had the same behaviour . Maybe it's not a samba issue. I already have two freebsd file servers both with the 8-RELEASE version and they're running ok! In this case, I need to use the 8-STABLE version because of my disk controller. So I don't know what could be happening. Thanks in advance! -- Danilo Mussolini Candido danilomussolini@gmail.com MSN: danilomussolini@gmail.com Home: http://mussolini.no-ip.org:30000 From owner-freebsd-stable@FreeBSD.ORG Fri Feb 5 14:46:46 2010 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 1671E106566C for ; Fri, 5 Feb 2010 14:46:46 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr13.xs4all.nl (smtp-vbr13.xs4all.nl [194.109.24.33]) by mx1.freebsd.org (Postfix) with ESMTP id A95578FC1A for ; Fri, 5 Feb 2010 14:46:45 +0000 (UTC) Received: from w2003s01.double-l.local (double-l.xs4all.nl [80.126.205.144]) by smtp-vbr13.xs4all.nl (8.13.8/8.13.8) with ESMTP id o15Ekhog098025; Fri, 5 Feb 2010 15:46:44 +0100 (CET) (envelope-from Johan@double-l.nl) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 5 Feb 2010 15:41:42 +0100 Message-ID: <57200BF94E69E54880C9BB1AF714BBCBA575D8@w2003s01.double-l.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FreeBSD 8-Stable with Samba too slow Thread-Index: AcqmcHEIujh9Ci5TRfS2rtKz94dXfwAADfxg References: <132a58b51002050600t768ff95fs1d922d5ce470c26d@mail.gmail.com> From: "Johan Hendriks" To: "Danilo Mussolini" X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-stable@freebsd.org Subject: RE: FreeBSD 8-Stable with Samba too slow 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, 05 Feb 2010 14:46:46 -0000 >Hi all, >I have just installed FreeBSD 8.0-STABLE-201001 to work as a file server >running samba 3.3.9 installed by ports. >But, I don't know why, when I try to access the share by Windows or by >Linux, it is so slow. I takes a long time to give the authentication window >and when I manage authenticate It keeps so slow to browse directories and >files. And the interesting thing is that when I reach the share with my >files (*.iso for tests) after a long time and start a copy, the transfer >goes so good, in a normal gigabit speed. >I tried compiling and installing samba 3.4.5 and had the same behaviour . >Maybe it's not a samba issue. >I already have two freebsd file servers both with the 8-RELEASE version and >they're running ok! >In this case, I need to use the 8-STABLE version because of my disk >controller. So I don't know what could be happening. >Thanks in advance! Just a me too! I had a 8.0 RELEASE server running on a HP Proliant ML110. The server responded quick wit no issues at all. I just upgraded the server to 8-Stable (No reason, just test) and the samba speed drops significant. Normally little files did not show the copy box, but after the update all copy's to the XP desktop shows me the copy window in windows. Same kernel file and settings. Samba version is 3.3.9 Regards, Johan From owner-freebsd-stable@FreeBSD.ORG Fri Feb 5 14:59:43 2010 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 35D11106566C; Fri, 5 Feb 2010 14:59:43 +0000 (UTC) (envelope-from mamalos@eng.auth.gr) Received: from vergina.eng.auth.gr (vergina.eng.auth.gr [155.207.18.1]) by mx1.freebsd.org (Postfix) with ESMTP id B20168FC1E; Fri, 5 Feb 2010 14:59:42 +0000 (UTC) Received: from mamalacation.ee.auth.gr (mamalacation.ee.auth.gr [155.207.33.29]) by vergina.eng.auth.gr (8.14.3/8.14.1) with ESMTP id o15Exf2i098509; Fri, 5 Feb 2010 16:59:41 +0200 (EET) (envelope-from mamalos@eng.auth.gr) Message-ID: <4B6C3258.7050607@eng.auth.gr> Date: Fri, 05 Feb 2010 16:59:36 +0200 From: George Mamalakis User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.5) Gecko/20100115 Thunderbird/3.0 MIME-Version: 1.0 To: freebsd-stable , freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Kerberized NFSv3 incorrect behavior (revisited) 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, 05 Feb 2010 14:59:43 -0000 What's more, if I obtain (as root for example) a ticket for user mamalos and kdestroy it, and then login as user root in a new terminal, the root user in the new terminal has still all privileges of mamalos in the share. Klist, of course, shows no tickets. This could be also a security threat, in case different kerberos principals (users in this setup) use a shared machine account to logon, and then access their resources by kiniting to their respective principals. I assume that this must have to do with kernel's KGSSAPI support, which "forgets" to delete or renew its kerberos' cache. Thank you all, again, for your time. -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 From owner-freebsd-stable@FreeBSD.ORG Fri Feb 5 15:08:19 2010 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 4EB21106566B for ; Fri, 5 Feb 2010 15:08:19 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by mx1.freebsd.org (Postfix) with ESMTP id 36A188FC17 for ; Fri, 5 Feb 2010 15:08:18 +0000 (UTC) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta02.emeryville.ca.mail.comcast.net with comcast id eD9P1d0051eYJf8A2F8KyC; Fri, 05 Feb 2010 15:08:19 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta19.emeryville.ca.mail.comcast.net with comcast id eF8J1d00G3S48mS01F8JJB; Fri, 05 Feb 2010 15:08:19 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 69DB41E3033; Fri, 5 Feb 2010 07:08:17 -0800 (PST) Date: Fri, 5 Feb 2010 07:08:17 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100205150817.GA6347@icarus.home.lan> References: <132a58b51002050600t768ff95fs1d922d5ce470c26d@mail.gmail.com> <57200BF94E69E54880C9BB1AF714BBCBA575D8@w2003s01.double-l.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCBA575D8@w2003s01.double-l.local> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: FreeBSD 8-Stable with Samba too slow 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, 05 Feb 2010 15:08:19 -0000 On Fri, Feb 05, 2010 at 03:41:42PM +0100, Johan Hendriks wrote: > >Hi all, > > >I have just installed FreeBSD 8.0-STABLE-201001 to work as a file > server > >running samba 3.3.9 installed by ports. > >But, I don't know why, when I try to access the share by Windows or by > >Linux, it is so slow. I takes a long time to give the authentication > window > >and when I manage authenticate It keeps so slow to browse directories > and > >files. And the interesting thing is that when I reach the share with my > >files (*.iso for tests) after a long time and start a copy, the > transfer > >goes so good, in a normal gigabit speed. > > >I tried compiling and installing samba 3.4.5 and had the same behaviour > . > >Maybe it's not a samba issue. > > >I already have two freebsd file servers both with the 8-RELEASE version > and > >they're running ok! > >In this case, I need to use the 8-STABLE version because of my disk > >controller. So I don't know what could be happening. > > > >Thanks in advance! > > Just a me too! > > I had a 8.0 RELEASE server running on a HP Proliant ML110. > The server responded quick wit no issues at all. > I just upgraded the server to 8-Stable (No reason, just test) and the > samba speed drops significant. > Normally little files did not show the copy box, but after the update > all copy's to the XP desktop shows me the copy window in windows. > > Same kernel file and settings. > Samba version is 3.3.9 I'm using Samba at home on FreeBSD 8.0-STABLE for personal use (user-level shares, and the guest OS is Windows XP). I've spent quite some time tuning both FreeBSD sysctls as well as smb.conf to try and get the most overall throughput. What I ended up with is this: sysctl.conf -- net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.sendspace=65536 net.inet.tcp.recvspace=131072 smb.conf -- socket options = TCP_NODELAY SO_SNDBUF=65536 SO_RCVBUF=65536 read raw = yes use sendfile = yes I tried adjusting many of the above parameters to try and find a "sweet spot" for reading/writing data to a 2-disk ZFS mirror (2x1TB disks, 7200rpm, SATA2 connected via ICH9 with AHCI enabled, and using ataahci(4) (not ahci(4)). The above is what works best. "Worked best" means I can push about 40-50MBytes/sec reading/writing to/from a Samba SMB/CIFS share. Comparatively, FTP gets around 75-85MByte/sec with the same sysctl.conf configuration. This is using Samba 3.3.10, though I can guarantee I saw the same speed/throughout as a result of the above tuning going back to 3.3.7. -- | Jeremy Chadwick jdc@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 Feb 5 15:13:17 2010 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 1132A106566B for ; Fri, 5 Feb 2010 15:13:17 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8EFB48FC22 for ; Fri, 5 Feb 2010 15:13:16 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o15FD0XL074776; Fri, 5 Feb 2010 16:13:15 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o15FCxRY074775; Fri, 5 Feb 2010 16:12:59 +0100 (CET) (envelope-from olli) Date: Fri, 5 Feb 2010 16:12:59 +0100 (CET) Message-Id: <201002051512.o15FCxRY074775@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, mail@vas.org.ua In-Reply-To: <4B6C2A96.3000305@vas.org.ua> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (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]); Fri, 05 Feb 2010 16:13:15 +0100 (CET) Cc: Subject: Re: amdtemp(4) oddities, Athlon 64 X2 (8-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: Fri, 05 Feb 2010 15:13:17 -0000 Vasyl Samoilov wrote: > Oliver Fromme wrote: > > dev.cpu.0.temperature: 14.0C > > dev.cpu.1.temperature: 14.0C > > dev.amdtemp.0.sensor0.core0: 14.0C > > dev.amdtemp.0.sensor0.core1: 22.0C > > dev.amdtemp.0.sensor1.core0: -49.0C > > dev.amdtemp.0.sensor1.core1: -49.0C > > hw.acpi.thermal.tz0.temperature: 40.0C > > It's not Freebsd, it's cpu issuses. For brisbane core cpus CoreTemp > author reported many times than the internal sensor seems to be > defective because it reads ilogical temperatures. That doesn't explain the difference between the second and the fourth line: dev.cpu.1.temperature: 14.0C dev.amdtemp.0.sensor0.core1: 22.0C They should come from the same sensor (at least the manual page implies this), so why are they different? 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 "In My Egoistical Opinion, most people's C programs should be indented six feet downward and covered with dirt." -- Blair P. Houghton From owner-freebsd-stable@FreeBSD.ORG Fri Feb 5 16:57:39 2010 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 E811F1065670 for ; Fri, 5 Feb 2010 16:57:39 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id AD2C28FC0C for ; Fri, 5 Feb 2010 16:57:39 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id DE56F730A1; Fri, 5 Feb 2010 18:06:22 +0100 (CET) Date: Fri, 5 Feb 2010 18:06:22 +0100 From: Luigi Rizzo To: Jordi Espasa Clofent Message-ID: <20100205170622.GA24658@onelab2.iet.unipi.it> References: <4B685EBA.4020501@minibofh.org> <4B695A1A.1000505@incunabulum.net> <4B696360.3070209@minibofh.org> <4B6ACC38.2030708@incunabulum.net> <20100204142045.GA86101@onelab2.iet.unipi.it> <4B6BFBF8.8050302@minibofh.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B6BFBF8.8050302@minibofh.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: ionice in 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, 05 Feb 2010 16:57:40 -0000 On Fri, Feb 05, 2010 at 12:07:36PM +0100, Jordi Espasa Clofent wrote: > Great work Luigi ;) > That's amazing... anyway ?is it production-ready? i would say it is pretty solid. I used it on my main workstation and desktop for a few months last year without a glitch. cheers luigi > -- > I must not fear. Fear is the mind-killer. Fear is the little-death that > brings total obliteration. I will face my fear. I will permit it to pass > over me and through me. And when it has gone past I will turn the inner > eye to see its path. Where the fear has gone there will be nothing. Only > I will remain. > > Bene Gesserit Litany Against Fear. > _______________________________________________ > 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 Feb 5 17:25:56 2010 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 85BBB106566C for ; Fri, 5 Feb 2010 17:25:56 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by mx1.freebsd.org (Postfix) with ESMTP id 637118FC19 for ; Fri, 5 Feb 2010 17:25:56 +0000 (UTC) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta12.emeryville.ca.mail.comcast.net with comcast id eEwr1d0031vN32cACHRwk3; Fri, 05 Feb 2010 17:25:56 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta22.emeryville.ca.mail.comcast.net with comcast id eHTS1d00D3S48mS8iHTSBx; Fri, 05 Feb 2010 17:27:27 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 104041E3033; Fri, 5 Feb 2010 09:25:55 -0800 (PST) Date: Fri, 5 Feb 2010 09:25:55 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100205172555.GA9144@icarus.home.lan> References: <4B685EBA.4020501@minibofh.org> <4B695A1A.1000505@incunabulum.net> <4B696360.3070209@minibofh.org> <4B6ACC38.2030708@incunabulum.net> <20100204142045.GA86101@onelab2.iet.unipi.it> <4B6BFBF8.8050302@minibofh.org> <20100205170622.GA24658@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100205170622.GA24658@onelab2.iet.unipi.it> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: ionice in 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, 05 Feb 2010 17:25:56 -0000 On Fri, Feb 05, 2010 at 06:06:22PM +0100, Luigi Rizzo wrote: > On Fri, Feb 05, 2010 at 12:07:36PM +0100, Jordi Espasa Clofent wrote: > > Great work Luigi ;) > > That's amazing... anyway ?is it production-ready? > > i would say it is pretty solid. I used it on my main workstation > and desktop for a few months last year without a glitch. I appreciate your work on this -- truly I do -- but the above statement is incredible. This is not meant as a flame-inducer, but there's really no other way to phrase it: This IS NOT what "production-ready" means to the rest of us, particularly those of us in the server world. A single developer running such code on their workstation for a few months is in no way identical to that of a heavily I/O-bound server. I thought freebsd.org (or maybe ISC?) offered some test/development boxes on the 'net available to developers who could test such code + perform stress tests over long periods of time? I'm probably mistaken, but I was under that impression. -- | Jeremy Chadwick jdc@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 Feb 5 17:30:00 2010 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 4A9C7106577C for ; Fri, 5 Feb 2010 17:30:00 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id C43E48FC0C for ; Fri, 5 Feb 2010 17:29:59 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAN7ka0uDaFvG/2dsb2JhbADYOYRSBA X-IronPort-AV: E=Sophos;i="4.49,414,1262581200"; d="scan'208";a="64395496" Received: from amazon.cs.uoguelph.ca ([131.104.91.198]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 05 Feb 2010 12:29:54 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by amazon.cs.uoguelph.ca (Postfix) with ESMTP id 990DE210138; Fri, 5 Feb 2010 12:29:54 -0500 (EST) X-Virus-Scanned: amavisd-new at amazon.cs.uoguelph.ca Received: from amazon.cs.uoguelph.ca ([127.0.0.1]) by localhost (amazon.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zwb1cWR9X0uI; Fri, 5 Feb 2010 12:29:52 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by amazon.cs.uoguelph.ca (Postfix) with ESMTP id B69D82100FB; Fri, 5 Feb 2010 12:29:52 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o15Hf0029809; Fri, 5 Feb 2010 12:41:01 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Fri, 5 Feb 2010 12:41:00 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: George Mamalakis In-Reply-To: <4B6BE7A2.6000402@eng.auth.gr> Message-ID: References: <4B6BE7A2.6000402@eng.auth.gr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable Subject: Re: Kerberized NFSv3 incorrect behavior 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, 05 Feb 2010 17:30:00 -0000 On Fri, 5 Feb 2010, George Mamalakis wrote: > Dear all, > > I am running FBSD8-STABLE on an nfsv3 server and an nfsv3 client. My > configuration is based on > http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup. My goal is > to share filesystems securely through kerberos authentication. Everything > works fine, until I try to kdestroy my tickets or kinit to some other user, > where the system insists to think that I am the user that initially obtained > their ticket. To be more extensive, my story is as follows: > [good stuff snipped] > > > and both client and server have the correct entries about each other (and > themselves) in their /etc/hosts, so heimdal works just fine. > > Both client and server have their respective keytabs stored in > /etc/krb5.keytab, and I use two users in my example (that both exist in both > systems with the same uid,gid): mamalos and testakis. > Unless you have applied the experimental patch, a keytab entry is meaningless in the client. Without that, it was assumed that "root" would never "kinit" as anyone. Basically, it was assumed that "root" would only do the mount and a user, like "mamalos" or "testakis" would be logged in and kinit'd as that user. The short answer is that any principal with TGT in the credentials cache for uid==N will be used to authenticate that user. Once authenticated, that "handle" for the user can be used until it expires (up to the server, but usually set to when the TGT that it found in the credential cache is due to expire). > So, when I mount the exported filesystem on the client giving: > > # mount -o nvfsv3,sec=krb5 server.example.com:/exports /mnt > # mount > /dev/da0s1a on / (ufs, local, soft-updates) > devfs on /dev (devfs, local, multilabel) > server.example.com:/exports on /mnt (nfs) > > and try to access the share: > # ls /mnt > ls: mnt: Permission denied > > I get the error I am expecting, since root does not have any kerberos tickets > assigned, yet. Let's see what happens when I kinit as mamalos: Yep, as expected. > # klist > Credentials cache: FILE:/tmp/krb5cc_0 > Principal: mamalos@EXAMPLE.COM > > Issued Expires Principal > Feb 5 11:20:49 Feb 5 21:20:47 krbtgt/EXAPMLE.COM@EXAMPLE.COM > # ls -la /mnt/ > total 8 > drwxr-xr-x 4 root wheel - 512 4 Feb 19:03 ./ > drwxr-xr-x 21 root wheel - 512 3 Feb 11:27 ../ > drwx------ 2 mamalos wheel - 512 5 Feb 11:11 mamalos/ > drwx------ 2 testakis wheel - 512 4 Feb 19:06 testakis/ > # touch /mnt/mamalos/myfile > # ls -la /mnt/mamalos/myfile > rw-r--r-- 1 mamalos wheel - 0 5 Feb 11:22 /mnt/mamalos/myfile > > Which is the exact behavior that is expected. Now when I kdestroy: > # kdestroy > # klist > klist: No ticket file: /tmp/krb5cc_0 > # touch /mnt/mamalos/myfilethatshouldnotbe > # ls -la /mnt/mamalos/myfilethatshouldnotbe > -rw-r--r-- 1 mamalos wheel - 0 5 Feb 11:24 > /mnt/mamalos/myfilethatshouldnotbe > Yes, this is a "bug/limitation" in the current implementation. I believe that "kdestroy" should do some sort of system call to inform the NFS client that "credentials for uid==N" should be invalidated. This is not implemented in FreeBSD8 (or Linux for that matter, last I checked). I don't know if dfr@ was planning on doing this and whether or not he thinks it is appropriate to do so? Without that implemented, the "handle" continues to work until the server expires it, normally when the TGT for "mamalos" would have expired if you hadn't kdestroy'd it. > And I can do everything in that share as if I were still mamalos, even though > I kdestroyed my kerberos ticket. The same thing will happen even if I kinit > to testakis after that. klist shows testakis' ticket this time, but I am not > allowed to access (rwx) tetakis' files/folders, and I still have full control > over mamalos' files and folders. > > In order to be able to do something as testakis, I have to unmount the share > and remount it while having testakis' ticket (or having no ticket at all, and > giving kinit testakis after mounting the share). > Actually, logging in as "testakis" should allow that user to access the mount as "testakis" once kinit'd as "testakis". The trick is that the credential cache entry needs to be in /tmp/krb5cc_N (where 'N' is the uid assigned to "testakis"). Same would apply to "mamalos" if that user were logged in with a non-0 uid. > I am not an NFS expert, but I suppose that this behavior is not the one to be > expected, except if I am missing some fundamental information about > kerberized NFS that explains it. Even so, it would be quite unwise to behave > so, since even if the users kdestroys their tickets, they have still all > permissions as when they obtained their ticket. > Yes, as noted above, I believe that "kdestroy" should get rid of the Kerberized NFS "handles" for the corresponding "uid". It's on my "to discuss with dfr and maybe do" list, but unfortunately not near the top of it. (I'd also like to come up with a good way to do initiator credentials from a keytab entry. The experimental patch is considered unacceptable for FreeBSD-current etc.) Hope that clarifies things, rick From owner-freebsd-stable@FreeBSD.ORG Fri Feb 5 17:36:34 2010 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 B6234106566B for ; Fri, 5 Feb 2010 17:36:34 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 796EC8FC18 for ; Fri, 5 Feb 2010 17:36:34 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 610FF73106; Fri, 5 Feb 2010 18:45:18 +0100 (CET) Date: Fri, 5 Feb 2010 18:45:18 +0100 From: Luigi Rizzo To: Jeremy Chadwick Message-ID: <20100205174518.GA25084@onelab2.iet.unipi.it> References: <4B685EBA.4020501@minibofh.org> <4B695A1A.1000505@incunabulum.net> <4B696360.3070209@minibofh.org> <4B6ACC38.2030708@incunabulum.net> <20100204142045.GA86101@onelab2.iet.unipi.it> <4B6BFBF8.8050302@minibofh.org> <20100205170622.GA24658@onelab2.iet.unipi.it> <20100205172555.GA9144@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100205172555.GA9144@icarus.home.lan> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: ionice in 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, 05 Feb 2010 17:36:34 -0000 On Fri, Feb 05, 2010 at 09:25:55AM -0800, Jeremy Chadwick wrote: > On Fri, Feb 05, 2010 at 06:06:22PM +0100, Luigi Rizzo wrote: > > On Fri, Feb 05, 2010 at 12:07:36PM +0100, Jordi Espasa Clofent wrote: > > > Great work Luigi ;) > > > That's amazing... anyway ?is it production-ready? > > > > i would say it is pretty solid. I used it on my main workstation > > and desktop for a few months last year without a glitch. > > I appreciate your work on this -- truly I do -- but the above statement > is incredible. This is not meant as a flame-inducer, but there's really > no other way to phrase it: > > This IS NOT what "production-ready" means to the rest of us, > particularly those of us in the server world. A single developer > running such code on their workstation for a few months is in no way > identical to that of a heavily I/O-bound server. exactly - i said "pretty robust" and not "production ready". There are known issues with multiple disks arrangements (gvinum etc.) due to a reuse of a field in a structure. These are solved in 8.x. cheers luigi > > I thought freebsd.org (or maybe ISC?) offered some test/development > boxes on the 'net available to developers who could test such code + > perform stress tests over long periods of time? I'm probably mistaken, > but I was under that impression. > > -- > | Jeremy Chadwick jdc@parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > _______________________________________________ > 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 Feb 5 17:57:04 2010 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 53BB5106568B for ; Fri, 5 Feb 2010 17:57:04 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id 1EA788FC1B for ; Fri, 5 Feb 2010 17:57:03 +0000 (UTC) Received: by pxi13 with SMTP id 13so1324843pxi.3 for ; Fri, 05 Feb 2010 09:57:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=/iqOBpmmfOHmIqd23+xO/kjytmXDDDIO2jttiQkmQZ4=; b=o6q6omBd/Z5iQQ1YOpn0/iIJ6Q7eKYBNPteN4gGJJRKjhsrJhvEMzG04eK7E4ET6u1 wzZwhkC52JukfWzN+jP0NUgKkJ0U7fr9+Ff8mZkhbprVDLh8sZgP8JYbMPB9+iT3BnZk lr6Fsx3VqWjnfLIaKHAfnBCJdAcZNl1ZDYlj0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=wfkYAhiBEIhWqGq6AeHosRT0NzOGa83r0YunUSFs1Ik0GHrZG4pjwhKQNPZgzwUn/X PRItf9uMSY60wQiOAQ2JqTskn1nKOHwsRlzhzdEZ3xtvumpZdSnPBcEdbA/z6gL7CYsV W0bJRIkH97QfZUSpqicbf1enlsI2tyXRVdgHQ= Received: by 10.115.132.8 with SMTP id j8mr1936884wan.215.1265391212000; Fri, 05 Feb 2010 09:33:32 -0800 (PST) Received: from kan.dnsalias.net (c-24-91-218-112.hsd1.ma.comcast.net [24.91.218.112]) by mx.google.com with ESMTPS id 13sm79750pwj.18.2010.02.05.09.33.29 (version=SSLv3 cipher=RC4-MD5); Fri, 05 Feb 2010 09:33:30 -0800 (PST) Date: Fri, 5 Feb 2010 12:33:24 -0500 From: Alexander Kabaev To: Jeremy Chadwick Message-ID: <20100205123324.2c47f8a0@kan.dnsalias.net> In-Reply-To: <20100205172555.GA9144@icarus.home.lan> References: <4B685EBA.4020501@minibofh.org> <4B695A1A.1000505@incunabulum.net> <4B696360.3070209@minibofh.org> <4B6ACC38.2030708@incunabulum.net> <20100204142045.GA86101@onelab2.iet.unipi.it> <4B6BFBF8.8050302@minibofh.org> <20100205170622.GA24658@onelab2.iet.unipi.it> <20100205172555.GA9144@icarus.home.lan> X-Mailer: Claws Mail 3.7.3 (GTK+ 2.18.5; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/4N84_hntZ0nWBoG_9JDZfFl"; protocol="application/pgp-signature" Cc: freebsd-stable@freebsd.org Subject: Re: ionice in 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, 05 Feb 2010 17:57:04 -0000 --Sig_/4N84_hntZ0nWBoG_9JDZfFl Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 5 Feb 2010 09:25:55 -0800 Jeremy Chadwick wrote: > I appreciate your work on this -- truly I do -- but the above > statement is incredible. This is not meant as a flame-inducer, but > there's really no other way to phrase it: >=20 > This IS NOT what "production-ready" means to the rest of us, > particularly those of us in the server world. A single developer > running such code on their workstation for a few months is in no way > identical to that of a heavily I/O-bound server. >=20 > I thought freebsd.org (or maybe ISC?) offered some test/development > boxes on the 'net available to developers who could test such code + > perform stress tests over long periods of time? I'm probably > mistaken, but I was under that impression. >=20 Luigi wrote: > i would say it is pretty solid. I used it on my main workstation > and desktop for a few months last year without a glitch. =20 In what twilight zone does that mean 'Yes, it is production ready' to warrant such a nice diatribe?=20 --=20 Alexander Kabaev --Sig_/4N84_hntZ0nWBoG_9JDZfFl Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iD8DBQFLbFZoQ6z1jMm+XZYRAgt2AJ9yppVdb07sPxyM7qx60zEVgZoLPQCg57cQ 5Ify4WT145kGxgvjUrTNK6o= =gtlS -----END PGP SIGNATURE----- --Sig_/4N84_hntZ0nWBoG_9JDZfFl-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 5 18:04:07 2010 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 793331065672 for ; Fri, 5 Feb 2010 18:04:07 +0000 (UTC) (envelope-from st0ma@sofiahouse.net) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by mx1.freebsd.org (Postfix) with ESMTP id 19F7C8FC08 for ; Fri, 5 Feb 2010 18:04:06 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id e12so11229fga.13 for ; Fri, 05 Feb 2010 10:04:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.102.17.40 with SMTP id 40mr2038250muq.119.1265391699878; Fri, 05 Feb 2010 09:41:39 -0800 (PST) Date: Fri, 5 Feb 2010 19:41:39 +0200 Message-ID: <331b660a1002050941y256e3343i65afe78df5eba4e5@mail.gmail.com> From: Spas Karabelov To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: PF Traffic Redirection issues 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, 05 Feb 2010 18:04:07 -0000 Hello, I am trying to perform traffic redirection with PF on 7.2-RELEASE. The traffic is in the same subnet and I try doing that by using just one interface em0. Mu current setup of pf is as follows: No ALTQ support in kernel ALTQ related functions disabled TRANSLATION RULES: rdr pass on em0 inet proto tcp from any os "NMAP" to any port 1:65535 -> 192.168.128.170 port 22 rdr pass on em0 inet proto tcp from 192.168.128.126 to any port = http -> 192.168.128.103 port 83 rdr pass on em0 inet proto tcp from 192.168.128.126 to any port = rdp -> 192.168.128.102 port 3389 rdr pass on em0 inet proto tcp from any to any port = ctf -> 192.168.128.102 port 83 FILTER RULES: scrub in all fragment reassemble block drop log all block drop in on ! em0 inet from 192.168.128.0/24 to any block drop in inet from 192.168.128.170 to any pass in on em0 inet proto tcp from any to 192.168.128.170 port = ssh flags S/SA keep state pass in on em0 inet proto tcp from any to 192.168.128.102 port = ctf flags S/SA synproxy state pass in on em0 inet proto tcp from any to 192.168.128.103 port = mit-ml-dev flags S/SA synproxy state pass out all flags S/SA keep state When I try to perform request they get the state of *SYN_SENT:CLOSED* : No ALTQ support in kernel ALTQ related functions disabled all tcp 192.168.128.170:22 <- 192.168.128.126:53162 ESTABLISHED:ESTABLISHED all tcp 192.168.128.102:83 <- 192.168.128.170:84 <- 192.168.128.104:8351 CLOSED:SYN_SENT all tcp 192.168.128.104:8351 -> 192.168.128.102:83 *SYN_SENT:CLOSED* Any advice is much appreciated. KR, Spas From owner-freebsd-stable@FreeBSD.ORG Fri Feb 5 18:39:24 2010 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 6052B106566C for ; Fri, 5 Feb 2010 18:39:24 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id 366158FC0C for ; Fri, 5 Feb 2010 18:39:24 +0000 (UTC) Received: by pxi13 with SMTP id 13so1368782pxi.3 for ; Fri, 05 Feb 2010 10:39:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=EPa5bkSzx/Zl6WsyZq0fPlAk2twUJGgjjj9sWerLMao=; b=VDC+VpUHpwCswi0ck8N1tSuXgP3SvIdkDmbQ4O2b5dUvaNiPXNwA3VZq+hWSAK3wkF LzdJhPxPjhtNlZvbISMWRrN3QYND6iSvh+S5/RLjzuXRhACaCncnuGDjp70JV461hlfB bakbYKh8m+nHG1mkQmT5yzHbCYHnLpM+KeJlg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rqHNIrZZbfKWS4NdhVPJ9x1p+fAYokI43MkuPwBWiBFHXWIzMvnEyzGBBwYmqyx3T+ UgfW9e+EReL3+t3NMNbmnFFfrrjxrt+iYErUIvMLwYbJ0jrYTl4ZBAp52UxP80LrL6jj ZkRFUpy2N4fMQckhDT8XpOoH5YwI54c4QfTTg= MIME-Version: 1.0 Received: by 10.142.61.24 with SMTP id j24mr1977442wfa.153.1265395163712; Fri, 05 Feb 2010 10:39:23 -0800 (PST) In-Reply-To: <331b660a1002050941y256e3343i65afe78df5eba4e5@mail.gmail.com> References: <331b660a1002050941y256e3343i65afe78df5eba4e5@mail.gmail.com> Date: Fri, 5 Feb 2010 10:39:23 -0800 Message-ID: <147432021002051039s16c72988n95e80f2e9ede0955@mail.gmail.com> From: Nick Rogers To: Spas Karabelov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: PF Traffic Redirection issues 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, 05 Feb 2010 18:39:24 -0000 On Fri, Feb 5, 2010 at 9:41 AM, Spas Karabelov wrote: > Hello, > > I am trying to perform traffic redirection with PF on 7.2-RELEASE. > The traffic is in the same subnet and I try doing that by using just one > interface em0. PF cannot redirect packets back out the interface they originated on. >From pf.conf(5)... "Redirections cannot reflect packets back through the interface they arrive on, they can only be redirected to hosts connected to different interfaces or to the firewall itself." From owner-freebsd-stable@FreeBSD.ORG Fri Feb 5 19:04:12 2010 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 760471065670; Fri, 5 Feb 2010 19:04:12 +0000 (UTC) (envelope-from jpaetzel@freebsd.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 453F28FC19; Fri, 5 Feb 2010 19:04:12 +0000 (UTC) Received: from compute2.internal (compute2.internal [10.202.2.42]) by gateway1.messagingengine.com (Postfix) with ESMTP id 989C9DFFE7; Fri, 5 Feb 2010 13:47:48 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Fri, 05 Feb 2010 13:47:48 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpout; bh=NvoevzLaUZd2EWPP+YdEOelph9o=; b=akWIP74Knnl9s2nvOAmkN1rZgOI8+FF6PR363i+kWTUzNT6kQLPscc6Zu6YoKMk40u1zjY7wzKy5jIKQG1DUf/uVdCKhAdE3wOS048L43+di5z18KLeWi68mtCNc4rvLUlezRAHavkdPHSbaorGQYel+0/v7Jl0vNpcaAq3ygn4= X-Sasl-enc: E809dTlzK8GIJNYpbjtoVuUSbg3mukXv1qWNdJBXn/A5 1265395668 Received: from ix.tcbug.org (71-82-134-106.dhcp.roch.mn.charter.com [71.82.134.106]) by mail.messagingengine.com (Postfix) with ESMTPSA id 3B69E22B52; Fri, 5 Feb 2010 13:47:48 -0500 (EST) Message-ID: <4B6C6797.8030803@freebsd.org> Date: Fri, 05 Feb 2010 12:46:47 -0600 From: Josh Paetzel Organization: FreeBSD User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100130 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4B6B89E7.8030002@sdf.lonestar.org> <201002050827.53343.jhb@freebsd.org> In-Reply-To: <201002050827.53343.jhb@freebsd.org> X-Enigmail-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: jhb@freebsd.org Subject: Re: Recent MFC to 7 causes crash on VMware ESXi 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, 05 Feb 2010 19:04:12 -0000 On 02/05/10 07:27, John Baldwin wrote: > On Thursday 04 February 2010 10:00:55 pm Tom McLaughlin wrote: >> Hi all, a recent MFC to 7-STABLE has started to cause issues for my VMs >> on VMware ESXi 3.5u4. After loading the mpt driver for the LSI disk >> controller the VM just shuts off. The workaround is to change the disk >> controller to the BusLogic type. Still, it used to work up until last >> week. The change was made around January 26th and based on the commits >> that day I'm guessing it's either r203047 or r203073 >> >> I have the same issue with both amd64 and i386 VMs. This affects HEAD >> and 8-STABLE as well and first affected HEAD over the summer. (I just >> worked around it and went about my business at the time. :-/) I've >> attached a dmesg from a kernel before the problem and one from after it >> started. > > What if you set 'hw.clfush_disable=1' from the loader? > For what it's worth, I have two machines running ESXi 4.0 and haven't encountered this problem. It's possible this issue affects 3.5 only. -- Thanks, Josh Paetzel FreeBSD -- The power to serve From owner-freebsd-stable@FreeBSD.ORG Fri Feb 5 20:08:12 2010 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 8A70C1065670; Fri, 5 Feb 2010 20:08:12 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 296498FC26; Fri, 5 Feb 2010 20:08:11 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPcIbEuDaFvK/2dsb2JhbADKNggBBo1BglYIAYFzBA X-IronPort-AV: E=Sophos;i="4.49,415,1262581200"; d="scan'208";a="64417998" Received: from fraser.cs.uoguelph.ca ([131.104.91.202]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 05 Feb 2010 15:08:11 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id 25E40109C26B; Fri, 5 Feb 2010 15:08:11 -0500 (EST) X-Virus-Scanned: amavisd-new at fraser.cs.uoguelph.ca Received: from fraser.cs.uoguelph.ca ([127.0.0.1]) by localhost (fraser.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVUf6wXzg2T5; Fri, 5 Feb 2010 15:08:10 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id 8CDB1109C274; Fri, 5 Feb 2010 15:08:10 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o15KJJF18935; Fri, 5 Feb 2010 15:19:19 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Fri, 5 Feb 2010 15:19:19 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: George Mamalakis In-Reply-To: <4B6C3258.7050607@eng.auth.gr> Message-ID: References: <4B6C3258.7050607@eng.auth.gr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, freebsd-stable Subject: Re: Kerberized NFSv3 incorrect behavior (revisited) 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, 05 Feb 2010 20:08:12 -0000 On Fri, 5 Feb 2010, George Mamalakis wrote: > shows no tickets. This could be also a security threat, in case different > kerberos principals (users in this setup) use a shared machine account to > logon, and then access their resources by kiniting to their respective > principals. > The kernel only knows the effective uid and the current gssd assumes that there will be "one" user principal with a TGT in /tmp/krb5cc_N (where 'N' is that uid#). Having multiple principals sharing the same login/uid (which I'm guessing is what you refer to as a "shared machine account", isn't going to work. I suppose that the gssd could do a "uid"->"username"->"principal name" mapping and then use that "principal name", but it is still going to be unique (ie only one) per uid. rick From owner-freebsd-stable@FreeBSD.ORG Fri Feb 5 20:16:00 2010 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 471391065692; Fri, 5 Feb 2010 20:16:00 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id DACF88FC16; Fri, 5 Feb 2010 20:15:59 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIsLbEuDaFvJ/2dsb2JhbADXeYRSBA X-IronPort-AV: E=Sophos;i="4.49,415,1262581200"; d="scan'208";a="64418903" Received: from ganges.cs.uoguelph.ca ([131.104.91.201]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 05 Feb 2010 15:15:55 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id F185DFB809A; Fri, 5 Feb 2010 15:15:55 -0500 (EST) X-Virus-Scanned: amavisd-new at ganges.cs.uoguelph.ca Received: from ganges.cs.uoguelph.ca ([127.0.0.1]) by localhost (ganges.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjDbRehmTmJW; Fri, 5 Feb 2010 15:15:55 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id 2D3F9FB80A3; Fri, 5 Feb 2010 15:15:55 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o15KR4m19591; Fri, 5 Feb 2010 15:27:04 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Fri, 5 Feb 2010 15:27:04 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: George Mamalakis In-Reply-To: <4B6C3258.7050607@eng.auth.gr> Message-ID: References: <4B6C3258.7050607@eng.auth.gr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, freebsd-stable Subject: Re: Kerberized NFSv3 incorrect behavior (revisited) 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, 05 Feb 2010 20:16:00 -0000 On Fri, 5 Feb 2010, George Mamalakis wrote: > > I assume that this must have to do with kernel's KGSSAPI support, which > "forgets" to delete or renew its kerberos' cache. > Oops, missed this on the last reply. It is actually a cache of "handles" for RPCSEC_GSS credentials allocated by the server (one per uid). It is normally the server that decides to expire them (they no longer really have anything to do with Kerberos, except that they were acquired via a Kerberos ticket and it uses the session key created by Kerberos). As noted before, I believe that kdestroy should somehow invalidate these handles (it's an RPC to the NFS server + flushing the cached entry in the client). A quick and dirty hack that has kdestroy do a system call to do this could be implemented fairly easily. A key management subsystem (aka key ring) that deals with all types of authentication and not just Kerberos would be much more work. rick From owner-freebsd-stable@FreeBSD.ORG Sat Feb 6 04:22:35 2010 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 53F8B1065679 for ; Sat, 6 Feb 2010 04:22:35 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from mail-gx0-f218.google.com (mail-gx0-f218.google.com [209.85.217.218]) by mx1.freebsd.org (Postfix) with ESMTP id E19F58FC0A for ; Sat, 6 Feb 2010 04:22:33 +0000 (UTC) Received: by gxk10 with SMTP id 10so973418gxk.3 for ; Fri, 05 Feb 2010 20:22:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:received :message-id:date:subject:from:to:user-agent:mime-version :content-type:content-transfer-encoding:x-priority:importance; bh=7Zum+aqIOnam1PgjGhZG8YCOA4uEaVGMX14qjSK+cDg=; b=Xfb8YClsjH7CXFaMFuHVcZNqshkHLZZhCpzm5MCJEWis/KVOPteH53fzCuOLTeUJIv vdFOfBcU12Shz5ANSNFNTAbsuvDv8RubnUFcVSKsApB82X+ZES1B+hwv9Hu0JMjETH2X 2uXiSkG+w670cme+Ri3cE9QvYVSsuA3mSxOG4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:subject:from:to:user-agent:mime-version :content-type:content-transfer-encoding:x-priority:importance; b=QdULjCKgx/cXri8BraQjIZwZIMMWm0VW5WDpmE8rNnp3ZG1wHhYWDZI5sXhQJgGcEZ mkDcoS7sb0/pCii7KE7GzRHW9iwhT/Y29FBzS+jHDHi9z9oixE2KztwaGuNKePlDSWso Oa8t5PqbBeN74h5ue9n9twzjcjhRPQ1KpOQtk= Received: by 10.150.37.20 with SMTP id k20mr5493334ybk.4.1265430151445; Fri, 05 Feb 2010 20:22:31 -0800 (PST) Received: from cygnus.homeunix.com ([189.71.106.77]) by mx.google.com with ESMTPS id 34sm678587yxf.47.2010.02.05.20.22.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 05 Feb 2010 20:22:30 -0800 (PST) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id CC426B8A1E; Sat, 6 Feb 2010 01:22:24 -0300 (BRT) Received: from 189.71.57.14 (SquirrelMail authenticated user matheus) by cygnus.homeunix.com with HTTP; Sat, 6 Feb 2010 02:22:24 -0200 (BRST) Message-ID: Date: Sat, 6 Feb 2010 02:22:24 -0200 (BRST) From: "Nenhum_de_Nos" To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: samba recplacement 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, 06 Feb 2010 04:22:35 -0000 hail, I've installed a recent 8-stable with gnome installed. I needed samba and noticed I have samba4-devel installed. but I can't manage to make it a simple file server as I need. so how to change samba package at minimum harm ? do I need to reinstall all ? a simple make fetch in samba33 says I can't as it conflicts with samba4 and some tbd-something (not in the machine right now). is there easy way ? I'd really like to choose samba version ... I've found a thread in gnome@ about this change (from late december). not a solution though. thanks, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-stable@FreeBSD.ORG Sat Feb 6 04:45:00 2010 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 335D1106566B; Sat, 6 Feb 2010 04:45:00 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id E7C678FC0A; Sat, 6 Feb 2010 04:44:59 +0000 (UTC) Received: by pxi13 with SMTP id 13so1867235pxi.3 for ; Fri, 05 Feb 2010 20:44:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=AODE0EaDQc+hXdFoK+/i4hBK4vtWThjIHyuQLH0AQV8=; b=BixhgUDChXU3yhyR5PU275xIkhIY4tHGm6pZP+vs8uSTFUQYx+pC/JPO/9dEAbo6Aq 4vMgXsg4CSK+xjcSagq6IISg6WGa+yvFnPezz3JF78tvK70H3Wfh1q1G6EHxKIZt9/Po 0kcqQP8+t+OgpGfKQhQ3HoJcD8CZ98SQbzSSI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=I5I+NbCXqF+cunzIG6s6+Tw1ar1uEXDEDOqgWM36RzmtdAxNvECqZJ+dAsmxCf87Ok lrD7G1BddrWoxzRxrlmmgIPPjvKonkawRInVGLUzJeNL+Uta0/i1o9wDSx4IkdNJWTNX +hf5Omgq3iW8HSU7gjKxP7MuUmveDBsWyR+ss= MIME-Version: 1.0 Received: by 10.142.55.5 with SMTP id d5mr2371403wfa.11.1265431499321; Fri, 05 Feb 2010 20:44:59 -0800 (PST) In-Reply-To: <201002050351.12270.max@love2party.net> References: <147432021001310037n1b67f01bx4b4e8781321cea8@mail.gmail.com> <2a41acea1002021443t1c298528i2df3cf40269c733@mail.gmail.com> <2a41acea1002021447t1067ee42gc59b25216270459b@mail.gmail.com> <201002050351.12270.max@love2party.net> Date: Fri, 5 Feb 2010 20:44:59 -0800 Message-ID: <147432021002052044h591c4050ka7f39b4ec739f2a@mail.gmail.com> From: Nick Rogers To: Max Laier Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: pyunyh@gmail.com, jfv@freebsd.org, freebsd-stable@freebsd.org, Jack Vogel Subject: Re: em(4) + ALTQ broken 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, 06 Feb 2010 04:45:00 -0000 I applied drbr_altq.diff to the e1000 driver (sys/dev/e1000) from HEAD on top of 8.0-RELEASE kernel sources. It appears to have fixed the immediate problem where queues simply don't work on em interfaces. Thanks a bunch. I suppose further review and testing by others would be greatly appreciated from my point of view. I am trying to decide on a relatively stable 8.0 kernel with working em(4) + ALTQ to put into production on 100 or so installations. Are you guys more comfortable with the HEAD sys/dev/e1000 + this patch on top of 8.0-RELEASE, or e1000 from 7.2 on top of 8.0-RELEASE? So far I am having good luck with the later. Thanks again for your contributions! On Thu, Feb 4, 2010 at 6:51 PM, Max Laier wrote: > Okay ... attached is a patch to fix this for em(4) (and lay the groundwork > to > fix it for other drbr_* consumer as well). I have tested it in VirtualBox, > but don't have real hardware to check for non-ALTQ performance or other > regressions. > > Test, comments and review appreciated. > > -- > Max > From owner-freebsd-stable@FreeBSD.ORG Sat Feb 6 10:11:53 2010 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 DE75A1065670 for ; Sat, 6 Feb 2010 10:11:53 +0000 (UTC) (envelope-from mamalos@eng.auth.gr) Received: from outgoing.holservices.gr (outgoing.holservices.gr [62.38.2.44]) by mx1.freebsd.org (Postfix) with SMTP id 03F168FC12 for ; Sat, 6 Feb 2010 10:11:52 +0000 (UTC) Received: (qmail 4287 invoked from network); 6 Feb 2010 09:36:20 -0000 Received: from unknown (HELO deliver.mail.dc.hol.net) (192.168.20.70) by arete.mail.dc.hol.net with SMTP; 6 Feb 2010 09:36:20 -0000 Received: from auth-smtp.hol.gr (takeit01.mail.dc.hol.net [192.168.20.71]) by deliver.hol.gr (8.12.11/8.11.6) with ESMTP id o169j565000991 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-SHA (256 bits) verified OK); Sat, 6 Feb 2010 11:45:05 +0200 Received: from [192.168.2.2] (ppp089210136134.dsl.hol.gr [89.210.136.134]) by auth-smtp.hol.gr (8.13.1/8.13.1) with ESMTP id o169j4ts026030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 6 Feb 2010 11:45:05 +0200 Message-ID: <4B6D3A18.2030304@eng.auth.gr> Date: Sat, 06 Feb 2010 11:44:56 +0200 From: George Mamalakis User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Rick Macklem References: <4B6BE7A2.6000402@eng.auth.gr> In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94.2/10362/Sat Feb 6 09:14:06 2010 on takeit01.mail.dc.hol.net X-Virus-Status: Clean Cc: freebsd-current@freebsd.org, freebsd-stable Subject: Re: Kerberized NFSv3 incorrect behavior 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, 06 Feb 2010 10:11:54 -0000 Rick Macklem wrote: > > > On Fri, 5 Feb 2010, George Mamalakis wrote: > >> Dear all, >> >> I am running FBSD8-STABLE on an nfsv3 server and an nfsv3 client. My >> configuration is based on >> http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup. My >> goal is to share filesystems securely through kerberos >> authentication. Everything works fine, until I try to kdestroy my >> tickets or kinit to some other user, where the system insists to >> think that I am the user that initially obtained their ticket. To be >> more extensive, my story is as follows: >> > [good stuff snipped] >> >> >> and both client and server have the correct entries about each other >> (and themselves) in their /etc/hosts, so heimdal works just fine. >> >> Both client and server have their respective keytabs stored in >> /etc/krb5.keytab, and I use two users in my example (that both exist >> in both systems with the same uid,gid): mamalos and testakis. >> > > Unless you have applied the experimental patch, a keytab entry is > meaningless in the client. Without that, it was assumed that "root" > would never "kinit" as anyone. Basically, it was assumed that "root" > would only do the mount and a user, like "mamalos" or "testakis" > would be logged in and kinit'd as that user. > > The short answer is that any principal with TGT in the credentials > cache for uid==N will be used to authenticate that user. Once > authenticated, that "handle" for the user can be used until it > expires (up to the server, but usually set to when the TGT that > it found in the credential cache is due to expire). > >> So, when I mount the exported filesystem on the client giving: >> >> # mount -o nvfsv3,sec=krb5 server.example.com:/exports /mnt >> # mount >> /dev/da0s1a on / (ufs, local, soft-updates) >> devfs on /dev (devfs, local, multilabel) >> server.example.com:/exports on /mnt (nfs) >> >> and try to access the share: >> # ls /mnt >> ls: mnt: Permission denied >> >> I get the error I am expecting, since root does not have any kerberos >> tickets assigned, yet. Let's see what happens when I kinit as mamalos: > > Yep, as expected. >> # klist >> Credentials cache: FILE:/tmp/krb5cc_0 >> Principal: mamalos@EXAMPLE.COM >> >> Issued Expires Principal >> Feb 5 11:20:49 Feb 5 21:20:47 krbtgt/EXAPMLE.COM@EXAMPLE.COM >> # ls -la /mnt/ >> total 8 >> drwxr-xr-x 4 root wheel - 512 4 Feb 19:03 ./ >> drwxr-xr-x 21 root wheel - 512 3 Feb 11:27 ../ >> drwx------ 2 mamalos wheel - 512 5 Feb 11:11 mamalos/ >> drwx------ 2 testakis wheel - 512 4 Feb 19:06 testakis/ >> # touch /mnt/mamalos/myfile >> # ls -la /mnt/mamalos/myfile >> rw-r--r-- 1 mamalos wheel - 0 5 Feb 11:22 /mnt/mamalos/myfile >> >> Which is the exact behavior that is expected. Now when I kdestroy: >> # kdestroy >> # klist >> klist: No ticket file: /tmp/krb5cc_0 >> # touch /mnt/mamalos/myfilethatshouldnotbe >> # ls -la /mnt/mamalos/myfilethatshouldnotbe >> -rw-r--r-- 1 mamalos wheel - 0 5 Feb 11:24 >> /mnt/mamalos/myfilethatshouldnotbe >> > > Yes, this is a "bug/limitation" in the current implementation. I believe > that "kdestroy" should do some sort of system call to inform the NFS > client that "credentials for uid==N" should be invalidated. This is not > implemented in FreeBSD8 (or Linux for that matter, last I checked). > I don't know if dfr@ was planning on doing this and whether or not he > thinks it is appropriate to do so? > > Without that implemented, the "handle" continues to work until the > server expires it, normally when the TGT for "mamalos" would have > expired if you hadn't kdestroy'd it. > >> And I can do everything in that share as if I were still mamalos, >> even though I kdestroyed my kerberos ticket. The same thing will >> happen even if I kinit to testakis after that. klist shows testakis' >> ticket this time, but I am not allowed to access (rwx) tetakis' >> files/folders, and I still have full control over mamalos' files and >> folders. >> >> In order to be able to do something as testakis, I have to unmount >> the share and remount it while having testakis' ticket (or having no >> ticket at all, and giving kinit testakis after mounting the share). >> > > Actually, logging in as "testakis" should allow that user to access the > mount as "testakis" once kinit'd as "testakis". The trick is that the > credential cache entry needs to be in /tmp/krb5cc_N (where 'N' is the > uid assigned to "testakis"). Same would apply to "mamalos" if that > user were logged in with a non-0 uid. > >> I am not an NFS expert, but I suppose that this behavior is not the >> one to be expected, except if I am missing some fundamental >> information about kerberized NFS that explains it. Even so, it would >> be quite unwise to behave so, since even if the users kdestroys their >> tickets, they have still all permissions as when they obtained their >> ticket. >> > > Yes, as noted above, I believe that "kdestroy" should get rid of the > Kerberized NFS "handles" for the corresponding "uid". It's on my > "to discuss with dfr and maybe do" list, but unfortunately not near > the top of it. (I'd also like to come up with a good way to do > initiator credentials from a keytab entry. The experimental patch > is considered unacceptable for FreeBSD-current etc.) > > Hope that clarifies things, rick > > _______________________________________________ > 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" > Rick, thank you for all your answers. I am planning on setting up the computer labs of my department using kerberized nfsv3 (since v4 seems to be "more" experimental) with a FreeBSD nfs server and Linux nfs clients. I was wondering "how stable" such an implementation would be; meaning that I wouldn't want to end up with an unstsable setup when receiving requests from 50-60 simultaneous clients, because that would be my everyday scenario. Thanks again for all your explanations (you covered me fully) and for your understanding of my remarks. mamalos -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 From owner-freebsd-stable@FreeBSD.ORG Sat Feb 6 11:22:43 2010 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 3EB3B1065670 for ; Sat, 6 Feb 2010 11:22:43 +0000 (UTC) (envelope-from Pascal.Stumpf@cubes.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.43]) by mx1.freebsd.org (Postfix) with ESMTP id 0304B8FC22 for ; Sat, 6 Feb 2010 11:22:42 +0000 (UTC) Received: from [62.224.220.220] (helo=pi) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1NdiZC-0006Xn-9C for freebsd-stable@freebsd.org; Sat, 06 Feb 2010 12:11:10 +0100 From: Pascal Stumpf To: freebsd-stable@freebsd.org Date: Sat, 6 Feb 2010 12:11:08 +0100 User-Agent: KMail/1.9.9 References: <4B696D0B.3070301@minibofh.org> In-Reply-To: <4B696D0B.3070301@minibofh.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201002061211.09140.Pascal.Stumpf@cubes.de> X-Df-Sender: 429867 Subject: Re: Inmutable bit in some binaries 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, 06 Feb 2010 11:22:43 -0000 HI, just another idea: You may want to take a look at integrity checking systems as an alternative, i.e. tripwire. -- PGP Fingerprint: 05C8 AE29 4147 6933 0EA9 C0C9 89B2 5B38 8AC4 D66B From owner-freebsd-stable@FreeBSD.ORG Sat Feb 6 11:51:01 2010 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 B4F111065670 for ; Sat, 6 Feb 2010 11:51:01 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 12FE78FC0C for ; Sat, 6 Feb 2010 11:51:00 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA29025 for ; Sat, 06 Feb 2010 13:50:59 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1NdjBi-000C6j-Jf for freebsd-stable@FreeBSD.org; Sat, 06 Feb 2010 13:50:58 +0200 Message-ID: <4B6D57A1.9020707@freebsd.org> Date: Sat, 06 Feb 2010 13:50:57 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091128) MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: {HEADSUP] ACPICA 20100121 MFC to stable/8 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, 06 Feb 2010 11:51:01 -0000 I am going to MFC ACPICA imports up to 20100121 plus some accompanying changes to stable/8 during the next hour. Please be extra attentive to this area during your next update and promptly report any regressions that you might see. Thank you! Here's a link to ACPI-CA changelog: http://www.acpica.org/download/changes.txt Below are some additional technical details. -------- Original Message -------- Subject: acpica in stable/8 Date: Fri, 05 Feb 2010 10:37:06 +0200 From: Andriy Gapon To: freebsd-acpi@FreeBSD.org, Jung-uk Kim I would like to bring version of ACPICA in stable/8 to that of head, that is 20100121. Here's svn status and svn diff outputs for the merge: http://people.freebsd.org/~avg/stable-8-acpi.status.txt http://people.freebsd.org/~avg/stable-8-acpi.diff I've performed this MFC by doing series of svn merges first to sys, then to usr.sbin/acpi. I hope that this is a correct approach. I have some doubts because of heard suggestions that such merges should be done from vendor area. But, OTOH, in head there were direct commits sys to fix consequences of merge from vendor area. Subversion gurus, please advise! Please also check if I haven't forgot to MFC something or maybe MFC-ed something unneeded, or made some other mistake. The change is compile tested on i386 and amd64, and run-tested on amd64, but on a rather 'plain' machine from ACPI point of view. If you would like and are able to test this change, I will greatly appreciate your feedback! Some arguments for doing this MFC (copied from an earlier email to jkim): First, it gets more testing. Then, I think it would be hard to keep it at the current version forever. Because some bugs get discovered and, as people get newer hardware, they are more likely to hit those bugs, and the people will demand fixes :-) And 8-STABLE is expected to have an active life for at least 2 years. And, the more frequent will be the updates, the easier it should be to catch bugs and fix them. One thing is getting a year's worth of changes, another is that of a month. Below is the list of the MFC-ed changes. It was generated in semi-automated fashion, so I might have made a mistake somewhere and the list could be incorrect: ------------------------------------------------------------------------ r197104 | jkim | 2009-09-12 01:48:53 +0300 (Sat, 12 Sep 2009) | 4 lines MFV: r196804 Import ACPICA 20090903 ------------------------------------------------------------------------ r197105 | jkim | 2009-09-12 01:49:34 +0300 (Sat, 12 Sep 2009) | 2 lines Catch up with ACPICA 20090903. ------------------------------------------------------------------------ r197106 | jkim | 2009-09-12 01:50:15 +0300 (Sat, 12 Sep 2009) | 2 lines Catch up with ACPICA 20090903. ------------------------------------------------------------------------ r197107 | jkim | 2009-09-12 01:56:08 +0300 (Sat, 12 Sep 2009) | 2 lines Canonify include paths for newly added files. ------------------------------------------------------------------------ r197688 | jkim | 2009-10-01 23:56:15 +0300 (Thu, 01 Oct 2009) | 4 lines Compile ACPI debugger and disassembler for kernel modules unconditionally. These files will generate almost empty object files without ACPI_DEBUG/DDB options. As a result, size of acpi.ko will increase slightly. ------------------------------------------------------------------------ r198237 | jkim | 2009-10-19 19:12:58 +0300 (Mon, 19 Oct 2009) | 2 lines Merge ACPICA 20091013. ------------------------------------------------------------------------ r199337 | jkim | 2009-11-16 23:47:12 +0200 (Mon, 16 Nov 2009) | 2 lines Merge ACPICA 20091112. ------------------------------------------------------------------------ r199338 | jkim | 2009-11-16 23:53:56 +0200 (Mon, 16 Nov 2009) | 2 lines Add a forgotten module Makefile change from the previous commit. ------------------------------------------------------------------------ r200553 | jkim | 2009-12-15 00:24:04 +0200 (Tue, 15 Dec 2009) | 2 lines Merge ACPICA 20091214. ------------------------------------------------------------------------ r200554 | jkim | 2009-12-15 00:28:32 +0200 (Tue, 15 Dec 2009) | 3 lines Remove _FDE quirk handling as these quirks are automatically repaired by ACPICA layer since ACPICA 20091214. ------------------------------------------------------------------------ r202771 | jkim | 2010-01-21 23:14:28 +0200 (Thu, 21 Jan 2010) | 2 lines Merge ACPICA 20100121. ------------------------------------------------------------------------ r202773 | jkim | 2010-01-21 23:31:39 +0200 (Thu, 21 Jan 2010) | 2 lines Fix a new header inclusion. ------------------------------------------------------------------------ In a raw form with some additional info: /head/usr.sbin/acpi:r197106,198237,199337,202771 /head/sys:r197104-197105,197107,197688,198237,199337-199338,200553-200554,202771,202773 /head/sys/dev/xen/xenpci:r197104-197105,197107,197688,198237,199337-199338,200553-200554,202771,202773 /head/sys/contrib/pf:r197104-197105,197107,197688,198237,199337-199338,200553-200554,202771,202773 /vendor-sys/acpica/dist:r193332-202768 /head/sys/contrib/dev/acpica:r197104-197105,197107,197688,198237,199337-199338,200553-200554,202771,202773 /head/sys/cddl/contrib/opensolaris:r197104-197105,197107,197688,198237,199337-199338,200553-200554,202771,202773 /head/sys/amd64/include/xen:r197104-197105,197107,197688,198237,199337-199338,200553-200554,202771,202773 -- Andriy Gapon -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sat Feb 6 16:46:53 2010 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 EE8C5106568F; Sat, 6 Feb 2010 16:46:52 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 8C4B38FC18; Sat, 6 Feb 2010 16:46:52 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id o16Gknr5062279; Sat, 6 Feb 2010 17:46:49 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id o16Gkmxt062278; Sat, 6 Feb 2010 17:46:48 +0100 (CET) (envelope-from marius) Date: Sat, 6 Feb 2010 17:46:48 +0100 From: Marius Strobl To: John Baldwin Message-ID: <20100206164648.GJ77522@alchemy.franken.de> References: <20100126073336.GA1955@server.vk2pj.dyndns.org> <20100131010618.GA1864@server.vk2pj.dyndns.org> <20100131162854.GC77522@alchemy.franken.de> <201002010946.57253.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201002010946.57253.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: rmacklem@freebsd.org, dfr@freebsd.org, freebsd-stable@freebsd.org, Peter Jeremy Subject: Re: uma_zalloc_arg complaining about non-sleepable locks 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, 06 Feb 2010 16:46:53 -0000 On Mon, Feb 01, 2010 at 09:46:57AM -0500, John Baldwin wrote: > On Sunday 31 January 2010 11:28:54 am Marius Strobl wrote: > > On Sun, Jan 31, 2010 at 12:06:18PM +1100, Peter Jeremy wrote: > > > Sorry for the delay, I was trying to avoid rebooting my server. > > > I've setup a similar environment in VirtualBox to test it. > > > > > > On 2010-Jan-27 12:52:29 +0100, Marius Strobl > wrote: > > > >Ah, I forgot that using nfsm_aligned() causes nfs_realign() to > > > >be a NOP on architectures without strict alignment requirements > > > >for performance reasons. That's generally fine but unfortunately > > > >that way you don't actually exercise the code which caused the > > > >problem before (unfortunately I still don't manage to hit the > > > >unaligned case myself). > > > > > > >Could you please test with #ifdef __NO_STRICT_ALIGNMENT replaced > > > >with #if 0 in sys/nfs/nfs_common.h? The vfs.nfs.realign_count > > > >counter should also increase then. > > > > > > I'm not sure what triggers the unaligned case either - I tried > > > roughly "tar -cf - -C /mnt/usr src | tar -xf - -C /mnt/tmp" and > > > that caused some unaligned accesses (but also completely wedged > > > the VBox host). I also tried copying a pile of files off my > > > NFS client (FreeBSD-8.x/i386) and that also triggered some > > > unaligned accesses without any errors being reported. > > > > > > Currently, I have: > > > vfs.nfs.realign_count: 12 > > > vfs.nfs.realign_test: 188817 > > > > > > I'd say that your patch works. > > > > John, are you okay with that patch? > > http://people.freebsd.org/~marius/fha_extract_info_realign2.diff > > > > It's intention is to: > > - Move nfs_realign() from the NFS client to the shared NFS code and > > remove the NFS server version in order to reduce code duplication. > > The shared version now uses a second parameter how, which is passed > > on to m_get(9) and m_getcl(9) as the server used M_WAIT while the > > client requires M_DONTWAIT, and replaces the the previously unused > > parameter hsiz. > > - Change nfs_realign() to use nfsm_aligned() so as with other NFS code > > the alignment check isn't actually performed on platforms without > > strict alignment requirements for performance reasons because as the > > comment suggests only occasionally occurs with TCP. > > - Change fha_extract_info() to use nfs_realign() with M_NOWAIT rather > > than M_DONTWAIT because it's called with the RPC sp_lock held. > > > > The only downside of the shared nfs_realign() are the combined > > SYSCTL counters but the fact we incremented them non-atomically > > so far I think already indicates that their intention only is a > > rough indication rather than exact values for client and server. > > This all sounds good to me, but isn't M_NOWAIT == M_DONTWAIT? Hmm, reading > the code more closely, it looks like fha_extract_info() was using M_WAIT > rather than M_DONTWAIT previously. Also, I think you should be careful to use > M_DONTWAIT instead of M_NOWAIT for mbufs, so I would fix that in > fha_extract_info(). > Ah, of course you're right, the above description should have read: Change fha_extract_info() to use nfs_realign() with M_DONTWAIT rather than M_WAIT because it's called with the RPC sp_lock held. and I had also managed to copy&paste M_NOWAIT instead of M_DONTWAIT into fha_extract_info() despite having read mbuf(9) regarding this topic. Thanks for pointing these out. Marius From owner-freebsd-stable@FreeBSD.ORG Sat Feb 6 17:20:34 2010 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 28F201065676; Sat, 6 Feb 2010 17:20:34 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id B0A028FC08; Sat, 6 Feb 2010 17:20:33 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id o16HKTst062500; Sat, 6 Feb 2010 18:20:30 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id o16HKTOW062499; Sat, 6 Feb 2010 18:20:29 +0100 (CET) (envelope-from marius) Date: Sat, 6 Feb 2010 18:20:29 +0100 From: Marius Strobl To: Rick Macklem Message-ID: <20100206172029.GK77522@alchemy.franken.de> References: <20100126073336.GA1955@server.vk2pj.dyndns.org> <20100131010618.GA1864@server.vk2pj.dyndns.org> <20100131162854.GC77522@alchemy.franken.de> <201002010946.57253.jhb@freebsd.org> 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: rmacklem@freebsd.org, dfr@freebsd.org, freebsd-stable@freebsd.org, Peter Jeremy , John Baldwin Subject: Re: uma_zalloc_arg complaining about non-sleepable locks 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, 06 Feb 2010 17:20:34 -0000 On Mon, Feb 01, 2010 at 11:54:54AM -0500, Rick Macklem wrote: > > > On Mon, 1 Feb 2010, John Baldwin wrote: > > >>>I'd say that your patch works. > >> > >>John, are you okay with that patch? > >>http://people.freebsd.org/~marius/fha_extract_info_realign2.diff > >> > >>It's intention is to: > >>- Move nfs_realign() from the NFS client to the shared NFS code and > >> remove the NFS server version in order to reduce code duplication. > >> The shared version now uses a second parameter how, which is passed > >> on to m_get(9) and m_getcl(9) as the server used M_WAIT while the > >> client requires M_DONTWAIT, and replaces the the previously unused > >> parameter hsiz. > > I don't think the client side can use M_WAIT/M_WAITOK if it wants to. > (I believe that it was once called from the socket upcall and that was > why M_DONTWAIT was used, but that isn't how it is called in the client > now.) > > I mentioned this to dfr@ because I use a version shared between client > and server for the experimental one that does M_WAIT, but he didn't > think the regular client needed to be changed. Basically, I think the > current code in the regular client can return ENOMEM for I/O system calls, > which probably isn't what the app. expected. In the NFS client, you end up > with this "do I wait forever?" or "do I return an error to an I/O system > call which an app. doesn't expect" issue cropping up here and there. I > don't know the correct answer to this, but tend to lean in the "wait > forever" direction. Well, as demonstrated by the problem with fha_extract_info() "waiting forever" must also match the locking so I'd rather leave chanGing the regular NFS client to someone who understands it better than I do :) Btw., newnfs_realign() should use #ifdef __NO_STRICT_ALIGNMENT instead of #if defined(__i386__) in order to bypass realigning on platforms which can deal with unaligned accesses. > > >>- Change nfs_realign() to use nfsm_aligned() so as with other NFS code > >> the alignment check isn't actually performed on platforms without > >> strict alignment requirements for performance reasons because as the > >> comment suggests only occasionally occurs with TCP. > >>- Change fha_extract_info() to use nfs_realign() with M_NOWAIT rather > >> than M_DONTWAIT because it's called with the RPC sp_lock held. > >> > > Btw, from an historical perspective, this was originally added for the > DEC PMAX port (MIPS R2000), which would trap whenever an unaligned ptr > was used. Then, there was this involved chunk of MIPS assembly code that > worked around the unaligned ptr access and the trap returned. Obviously > this was a major performance hit and happened fairly frequently for NFS > over ISO TP4. As you've seen, it happens infrequently enough over TCP > (back then, I think it was only when the TCP window size ended up really > small, although I'm way out of date on the TCP stack, so I have no idea > now:-) that I'd only do the re-alignment on achitectures that will crash > if it isn't done? > > I missed the beginning of this. Was there crashes occurring because > the alignment wasn't being done or problems because the alignment > wasn't working correctly? (I guess I'm trying to say that, if the > arch works without nfs_realign(), then you might consider just not > doing it for that arch. I suppose that isn't a good enough reason > to not fix the function, though?;-) The original problem with fha_extract_info() was that it didn't realign the mbuf data at all but called nfsm_srvmtofh_xx() which assumes the 4-byte alignment required by XDR. As mentioned above, changing nfs_realign() to use nfsm_aligned() has the effect you propose of not performing the realignment on platforms which can deal with unaligned acesses. Actually one could take this one step further and #ifdef the whole nfs_realign() like you do with newnfs_realign() but nfsm_aligned() already existed and I'm reluctant to rototill foreign code too much. Also the compiler should be smart enough to optimize this down to just incrementing nfs_realign_test when __NO_STRICT_ALIGNMENT is defined. Marius From owner-freebsd-stable@FreeBSD.ORG Sat Feb 6 21:47:19 2010 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 E9BE71065696; Sat, 6 Feb 2010 21:47:18 +0000 (UTC) (envelope-from tmclaugh@sdf.lonestar.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B9D748FC18; Sat, 6 Feb 2010 21:47:18 +0000 (UTC) Received: from straycat.dhs.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o16LlHZj014176; Sat, 6 Feb 2010 21:47:18 GMT (envelope-from tmclaugh@sdf.lonestar.org) Received: from tomcat.straycat.dhs.org (tomcat.straycat.dhs.org [192.168.2.213]) by straycat.dhs.org (8.14.1/8.14.1) with ESMTP id o16LlGcb022709; Sat, 6 Feb 2010 16:47:17 -0500 (EST) Message-ID: <4B6DE364.8030509@sdf.lonestar.org> Date: Sat, 06 Feb 2010 16:47:16 -0500 From: Tom McLaughlin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.1 MIME-Version: 1.0 To: John Baldwin References: <4B6B89E7.8030002@sdf.lonestar.org> <201002050827.53343.jhb@freebsd.org> In-Reply-To: <201002050827.53343.jhb@freebsd.org> X-Enigmail-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Recent MFC to 7 causes crash on VMware ESXi 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, 06 Feb 2010 21:47:19 -0000 John Baldwin wrote, On 02/05/2010 08:27 AM: > On Thursday 04 February 2010 10:00:55 pm Tom McLaughlin wrote: >> Hi all, a recent MFC to 7-STABLE has started to cause issues for my VMs >> on VMware ESXi 3.5u4. After loading the mpt driver for the LSI disk >> controller the VM just shuts off. The workaround is to change the disk >> controller to the BusLogic type. Still, it used to work up until last >> week. The change was made around January 26th and based on the commits >> that day I'm guessing it's either r203047 or r203073 >> >> I have the same issue with both amd64 and i386 VMs. This affects HEAD >> and 8-STABLE as well and first affected HEAD over the summer. (I just >> worked around it and went about my business at the time. :-/) I've >> attached a dmesg from a kernel before the problem and one from after it >> started. > > What if you set 'hw.clfush_disable=1' from the loader? > Yes, that corrected it on all my VMs. I've talked to people on ESXi 4 and they do not see the problem. I have yet to try 3.5u5 to see if this is a non-issue. 3.5 will be supported for awhile longer from VMware. I'm going to try upgrading the box during the week. tom -- | tmclaugh at sdf.lonestar.org tmclaugh at FreeBSD.org | | FreeBSD http://www.FreeBSD.org |