From owner-freebsd-stable@FreeBSD.ORG Sun Nov 7 00:13: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 8E95A106566C for ; Sun, 7 Nov 2010 00:13:44 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 6A5888FC08 for ; Sun, 7 Nov 2010 00:13:44 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id oA70DgpY054207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 6 Nov 2010 17:13:42 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id oA70Dg79054206; Sat, 6 Nov 2010 17:13:42 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA21065; Sat, 6 Nov 10 16:00:14 PST Date: Sat, 06 Nov 2010 17:00:17 -0700 From: perryh@pluto.rain.com To: fbsdlist@src.cx Message-Id: <4cd5ec11.yOJU6QpZmSq15Ng9%perryh@pluto.rain.com> References: <201011051721.05898.jhb@freebsd.org> In-Reply-To: User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: thomas.e.zander@googlemail.com, freebsd-stable@freebsd.org Subject: Re: How to tell whether ECC (memory) is enabled? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Nov 2010 00:13:44 -0000 Artem Belevich wrote: > All you need is intentionally make one data bit bad. Put some > tape on one of the data pads on the DIMM and run memtest ... and then spend the next couple of hours cleaning the gunk off of the DIMM and out of the slot :( From owner-freebsd-stable@FreeBSD.ORG Sun Nov 7 01:08:54 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 2BEF51065698 for ; Sun, 7 Nov 2010 01:08:54 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id E16278FC15 for ; Sun, 7 Nov 2010 01:08:53 +0000 (UTC) Received: from lawrence1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id 053217E84A; Sun, 7 Nov 2010 11:50:20 +1100 (EST) Message-ID: <4CD5F7C9.4070404@freebsd.org> Date: Sun, 07 Nov 2010 11:50:17 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-AU; rv:1.9.2.9) Gecko/20101006 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Sergey Kandaurov References: <4CD5DAD3.8020304@protected-networks.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lauren.room52.net Cc: stable@freebsd.org Subject: Re: releng_7 buildworld 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, 07 Nov 2010 01:08:54 -0000 On 11/07/10 09:54, Sergey Kandaurov wrote: > On 7 November 2010 01:46, Michael Butler wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> SVN rev 214875 on 2010-11-06 13:03:33Z breaks buildworld on releng_7. >> >> It introduces "siis.4" to /usr/src/share/man/man4/Makefile which doesn't >> exist (yet?) > > I guess that's rather due to SIFTR mismerge. My apologies for letting this slip through. I will commit the fix to remove siis.4 from the Makefile in a little bit when my buildworld test completes. Cheers, Lawrence From owner-freebsd-stable@FreeBSD.ORG Sun Nov 7 02:24:50 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 F11EA106564A; Sun, 7 Nov 2010 02:24:50 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (unknown [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id A6B638FC0C; Sun, 7 Nov 2010 02:24:50 +0000 (UTC) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id oA72Oguf040323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Nov 2010 22:24:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp1.sentex.ca (8.14.4/8.14.4) with ESMTP id oA72OgkL024567; Sat, 6 Nov 2010 22:24:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 8D9201B5060; Sat, 6 Nov 2010 22:24:41 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20101107022441.8D9201B5060@freebsd-stable.sentex.ca> Date: Sat, 6 Nov 2010 22:24:41 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.67 on 64.7.153.18 Cc: Subject: [releng_7 tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2010 02:24:51 -0000 TB --- 2010-11-07 01:27:03 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2010-11-07 01:27:03 - starting RELENG_7 tinderbox run for amd64/amd64 TB --- 2010-11-07 01:27:03 - cleaning the object tree TB --- 2010-11-07 01:27:41 - cvsupping the source tree TB --- 2010-11-07 01:27:41 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/amd64/amd64/supfile TB --- 2010-11-07 01:27:51 - building world TB --- 2010-11-07 01:27:51 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-07 01:27:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-07 01:27:51 - TARGET=amd64 TB --- 2010-11-07 01:27:51 - TARGET_ARCH=amd64 TB --- 2010-11-07 01:27:51 - TZ=UTC TB --- 2010-11-07 01:27:51 - __MAKE_CONF=/dev/null TB --- 2010-11-07 01:27:51 - cd /src TB --- 2010-11-07 01:27:51 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 7 01:27:53 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] gzip -cn /src/share/man/man4/sdhci.4 > sdhci.4.gz gzip -cn /src/share/man/man4/sem.4 > sem.4.gz gzip -cn /src/share/man/man4/ses.4 > ses.4.gz gzip -cn /src/share/man/man4/sf.4 > sf.4.gz gzip -cn /src/share/man/man4/sge.4 > sge.4.gz gzip -cn /src/share/man/man4/si.4 > si.4.gz gzip -cn /src/share/man/man4/siftr.4 > siftr.4.gz make: don't know how to make siis.4. Stop *** Error code 2 Stop in /src/share/man. *** Error code 1 Stop in /src/share. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-07 02:24:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-07 02:24:41 - ERROR: failed to build world TB --- 2010-11-07 02:24:41 - 2889.06 user 310.08 system 3457.52 real http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Sun Nov 7 03:16: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 C52C3106566C for ; Sun, 7 Nov 2010 03:16:08 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 766FB8FC0C for ; Sun, 7 Nov 2010 03:16:08 +0000 (UTC) Received: by qyk4 with SMTP id 4so179714qyk.13 for ; Sat, 06 Nov 2010 20:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=UUjbbGNKOznt+j5AKPsOgKOKf/9yg1bx2b9b+ZsOl68=; b=mxxc1Dpj6YzWyz9uA9LfhvwWXjs1+wZRYSloHBK0KLNq3tuy5hsygqE2swWGBAg2Cs 98LhvRUJFmmOHk24cGbww/0ObfVzIu16+Y0Xc5cIeldGfcaW9DrkcZcLR0Y0wgwL3x6g becPWWNDOPj54vBph8h/tkXNNDUaszxAKToYY= 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 :content-transfer-encoding; b=Xh5Hm7n0xa+zBLOCyQA52EIIFqwt0Ozy/Qi2YPgDalTThNLr23Ye9gwwpJ3bkM/l35 SWsM8eo4ypjiIzEgr+AqESUb02ahAV3B1jN/UkP48iDvxAu2VvMhzhHcGIpcoDhGCDKG kfnjNJJTTK1ztTyrZgFBsLrzrGikkRbChiUow= MIME-Version: 1.0 Received: by 10.224.128.210 with SMTP id l18mr2606659qas.24.1289099767436; Sat, 06 Nov 2010 20:16:07 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.220.180.2 with HTTP; Sat, 6 Nov 2010 20:16:07 -0700 (PDT) In-Reply-To: <4cd5ec11.yOJU6QpZmSq15Ng9%perryh@pluto.rain.com> References: <201011051721.05898.jhb@freebsd.org> <4cd5ec11.yOJU6QpZmSq15Ng9%perryh@pluto.rain.com> Date: Sat, 6 Nov 2010 20:16:07 -0700 X-Google-Sender-Auth: e20Tb12Q0EZqFEKFkkjZl5buEkQ Message-ID: From: Artem Belevich To: perryh@pluto.rain.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: thomas.e.zander@googlemail.com, freebsd-stable@freebsd.org Subject: Re: How to tell whether ECC (memory) is enabled? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Nov 2010 03:16:08 -0000 I would agree with you if one would try to use electrical tape. It would be unsuitable for this purpose because of it's thickness and because of the residue it tends to leave. I believe there are better options. For what it's worth, at home scotch tape ("invisible" matte kind) worked well enough for me. It didn't get damaged by the slot connector and it didn't leave any residue. YMMV, caveat emptor, beware, use at your own risk, you know the drill.. --Artem On Sat, Nov 6, 2010 at 5:00 PM, wrote: > Artem Belevich wrote: > >> All you need is intentionally make one data bit bad. =A0Put some >> tape on one of the data pads on the DIMM and run memtest ... > > and then spend the next couple of hours cleaning the gunk off of > the DIMM and out of the slot :( > From owner-freebsd-stable@FreeBSD.ORG Sun Nov 7 04:00: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 653F31065670 for ; Sun, 7 Nov 2010 04:00:02 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 00BB38FC08 for ; Sun, 7 Nov 2010 04:00:01 +0000 (UTC) Received: by yxl31 with SMTP id 31so2963832yxl.13 for ; Sat, 06 Nov 2010 21:00:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=0EKTb5Ee2WPaTsWqpFQrfM7IFvwE3UYGUME/HQG2dJM=; b=lVmp4ZX3orUtR3oRr+e9icAYs9ofQ5xe5jZzfIZnjJiHfJqThZQat7r4yxktW9t+3E PBmv4dV3TwgmQblhveQkReEM/ez4EH7w1A4N3IaGOMe61ejrKPxgvIERufKalLMrF8e6 q85kYOjGFu3NWgATlTOhZleeCrhttX7ksL95Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=ROpUAwNPd3axRSRp86MRfIxXsLfhHHWnKoBeZGP/kDhnY53mYXYuy5GhgaPZggUGkD LjArVMK6NqwvbF4UOhuBqWnw7HIaJTbQDID36iaMtIHOJFPBZZ1oBVwAlVbM6KJKnqf4 rYBoD3ZH/ZkLu7TGdr4LbHHf5rh62kkC0t/+4= Received: by 10.151.42.15 with SMTP id u15mr6166743ybj.222.1289102401094; Sat, 06 Nov 2010 21:00:01 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-136-243.dsl.klmzmi.sbcglobal.net [99.181.136.243]) by mx.google.com with ESMTPS id p1sm2466377ybn.17.2010.11.06.20.59.57 (version=SSLv3 cipher=RC4-MD5); Sat, 06 Nov 2010 20:59:58 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4CD6243B.90707@DataIX.net> Date: Sat, 06 Nov 2010 23:59:55 -0400 From: jhell Organization: http://www.DataIX.net User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.12) Gecko/20101028 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Rumen Telbizov References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Artem Belevich Subject: Re: Degraded zpool cannot detach old/bad drive X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Nov 2010 04:00:02 -0000 On 10/31/2010 15:53, Rumen Telbizov wrote: > Hi Artem, everyone, > > Here's the latest update on my case. > I did upgrade the system to the latest stable: 8.1-STABLE FreeBSD 8.1-STABLE > #0: Sun Oct 31 11:44:06 PDT 2010 > After that I did zpool upgrade and zfs upgrade -r all the filesystems. > Currently I am running zpool 15 and zfs 4. > Everything went fine with the upgrade but unfortunately my problem still > persists. There's no difference in this aspect. > I still have mfid devices. I also tried chmod-ing as you suggested /dev/mfid > devices but zfs/zpool didn't seem to care and imported > the array regardless. > > So at this point since no one else seems to have any ideas and we seem to be > stuck I am almost ready to declare defeat on this one. > Although the pool is usable I couldn't bring it back to exactly the same > state as it was before the disk replacements took place. > Disappointing indeed, although not a complete show stopper. > > I still think that if there's a way to edit the cache file and change the > devices that might do the trick. > > Thanks for all the help, > Rumen Telbizov > > > On Fri, Oct 29, 2010 at 5:01 PM, Artem Belevich wrote: > >> On Fri, Oct 29, 2010 at 4:42 PM, Rumen Telbizov >> wrote: >>> FreeBSD 8.1-STABLE #0: Sun Sep 5 00:22:45 PDT 2010 >>> That's when I csuped and rebuilt world/kernel. >> >> There were a lot of ZFS-related MFCs since then. I'd suggest updating >> to the most recent -stable and try again. >> >> I've got another idea that may or may not work. Assuming that GPT >> labels disappear because zpool opens one of the /dev/mfid* devices, >> you can try to do "chmod a-rw /dev/mfid*" on them and then try >> importing the pool again. >> >> --Artem >> > > > The problem seems to be that its just finding the actual disk before it finds the GPT labels. You should be able to export the pool and then re-import the pool after hiding the disks that it is finding via /etc/devfs.rules file. Try adding something like (WARNING: This will hide all devices mfi) adjust accordingly: add path 'mfi*' hide To your devfs ruleset before re-importing the pool and that should make ZFS go wondering around /dev enough to find the appropriate GPT label for the disk it is trying to locate. It would seem to me that using '-d' in this case would not be effective as ZFS would be looking for 'gpt/LABEL' within /dev/gpt/ if memory serves correctly, and obviously path /dev/gpt/gpt/ would not exist. Also even if it did find the correct gpt label then it would be assuming its at a /dev path and not /dev/gpt/* and would fall back to finding the mfi devices after the next boot again. -- jhell,v From owner-freebsd-stable@FreeBSD.ORG Sun Nov 7 06:19: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 098DF1065670 for ; Sun, 7 Nov 2010 06:19:35 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id B6BE08FC12 for ; Sun, 7 Nov 2010 06:19:34 +0000 (UTC) Received: by qyk7 with SMTP id 7so3747573qyk.13 for ; Sat, 06 Nov 2010 23:19:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=O7rtAE59kZlWVK+VrOJCUkGtax5hCMAoqXBZLdMPP7g=; b=rT5CNhPxqc+AxuiyhR3JdAdNk4LqVpZCMH9qgiR3UgD3uGU3wPSQuz9FMYFrM7WpGS DVVkLnxLnBIr7oBaNjSKwfRBxtBrYh/TRG/CwImx8EbAG3QsZb6quu5q/dXDIklwLbFb QHXLqSmrfWtwvtKn63WrCvMjES2GFgoJFHLUc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=OASLy8o3m5+me6r1SVAFxwe/p7PEvk8pdt36S7ozsgaQi33FpnLJHunj8iBNtDO88+ 8vsXKpV6Tj4odyW+8fd5KzxfdmhQbqsloNKRa84uiccFWSDVOzvddPATDeZTLvsHXjaS sOXfJKezoyIJH1m5aQOoaxQA12lLUTQ3toJh8= MIME-Version: 1.0 Received: by 10.224.3.14 with SMTP id 14mr2716313qal.52.1289110773878; Sat, 06 Nov 2010 23:19:33 -0700 (PDT) Received: by 10.220.200.11 with HTTP; Sat, 6 Nov 2010 23:19:33 -0700 (PDT) In-Reply-To: <20101106093700.GW85693@acme.spoerlein.net> References: <20101106093700.GW85693@acme.spoerlein.net> Date: Sat, 6 Nov 2010 23:19:33 -0700 Message-ID: From: Pyun YongHyeon To: =?ISO-8859-1?Q?Ulrich_Sp=F6rlein?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org Subject: Re: Abysmal re(4) performance under 8.1-STABLE (mid-August) 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, 07 Nov 2010 06:19:35 -0000 On Sat, Nov 6, 2010 at 2:37 AM, Ulrich Sp=F6rlein wrote= : > Hello Pyun, > > On this new server, I cannot get more than ~280kByte/s up/downstream out = of > re(4) without any tweaking. > > re0: flags=3D8843 metric 0 mtu 15= 00 > =A0 =A0 =A0 =A0options=3D389b > =A0 =A0 =A0 =A0ether 00:21:85:63:74:34 > =A0 =A0 =A0 =A0inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid 0x= 1 > =A0 =A0 =A0 =A0inet 46.4.12.147 netmask 0xffffffc0 broadcast 46.4.12.191 > =A0 =A0 =A0 =A0nd6 options=3D3 > =A0 =A0 =A0 =A0media: Ethernet autoselect (100baseTX ) > =A0 =A0 =A0 =A0status: active > It seems the link was resolved to half-duplex. Does link partner also agree on the resolved speed/duplex? > re0@pci0:2:0:0: class=3D0x020000 card=3D0x368c1462 chip=3D0x816810ec rev= =3D0x01 hdr=3D0x00 > =A0 =A0vendor =A0 =A0 =3D 'Realtek Semiconductor' > =A0 =A0device =A0 =A0 =3D 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8= 111c)' > =A0 =A0class =A0 =A0 =A0=3D network > =A0 =A0subclass =A0 =3D ethernet > > re0: port 0xd800-= 0xd8ff mem 0xfeaff000-0xfeafffff irq 19 at device 0.0 on pci2 > re0: Using 1 MSI messages > re0: Chip rev. 0x38000000 > re0: MAC rev. 0x00000000 > miibus0: on re0 > rgephy0: PHY 1 on miibus0 > rgephy0: =A010baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 10= 00baseT-FDX, auto > re0: Ethernet address: 00:21:85:63:74:34 > re0: [FILTER] > > > It's interesting to note, that re0 only negotiates half-duplex, where > linux will negotiate full-duplex (and gets ~10MByte/s as expected). > > Next, I disabled almost all options, except that I cannot disable > VLAN_MTU, VLAN_HWCSUM. I also forced the adapter into full-duplex. > > # ifconfig re0 -vlanmtu > # ifconfig re0 -vlanhwcsum > ifconfig: -vlanhwcsum: bad value I'm sure this has nothing to do that this issue. If you want to disable checksum offloading of VLAN interface, use vlan interface instead of parent interface of the VLAN interface(i.e. ifconfig vlan0 -txcsum -rxcsum). And you can't disable VLAN_MTU on re(4). There is no reason to disable supporting VLAN oversized frames. > # ifconfig re0 > re0: flags=3D8843 metric 0 mtu 15= 00 > =A0 =A0 =A0 =A0options=3D88 > =A0 =A0 =A0 =A0ether 00:21:85:63:74:34 > =A0 =A0 =A0 =A0inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid 0x= 1 > =A0 =A0 =A0 =A0inet 46.4.12.147 netmask 0xffffffc0 broadcast 46.4.12.191 > =A0 =A0 =A0 =A0nd6 options=3D3 > =A0 =A0 =A0 =A0media: Ethernet 100baseTX (100baseTX ) > =A0 =A0 =A0 =A0status: active > This time, it seems you used forced media configuration instead of auto. It still shows duplex mismatch so it's normal to see poor performance. What makes me wonder is why you have duplex mismatch? Did you use forced media configuration on link partner? What happens when you use different switch? > If I then immediately start the test-download, I get a ~2MByte/s spike, > which quickly returns to something around 250kByte/s. > > Booting with > hw.pci.enable_msix=3D0 > hw.pci.enable_msi=3D0 > > I can get almost up to 400kByte/s, but this may be coincidence. > > So this is usually as far as it gets: > > re0 =A0in =A0 =A0190.504 KB/s =A0 =A0 =A0 =A0246.136 KB/s =A0 =A0 =A0 =A0= =A0 66.709 MB > =A0 =A0 out =A0 =A010.290 KB/s =A0 =A0 =A0 =A0 12.985 KB/s =A0 =A0 =A0 = =A0 =A0 =A06.076 MB > > But then I ran tcpdump in another session, and it looks like the ssh traf= fic on > the upstream of the interface will make the downloads running in another = window > go faster: > > re0 =A0in =A0 =A0805.961 KB/s =A0 =A0 =A0 =A0 =A01.577 MB/s =A0 =A0 =A0 = =A0 =A0116.523 MB > =A0 =A0 out =A0 222.940 KB/s =A0 =A0 =A0 =A0502.045 KB/s =A0 =A0 =A0 =A0 = =A0 19.267 MB > > Any ideas? > > Uli > From owner-freebsd-stable@FreeBSD.ORG Sun Nov 7 11:24:23 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 582041065672 for ; Sun, 7 Nov 2010 11:24:23 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2001:470:9a47::1]) by mx1.freebsd.org (Postfix) with ESMTP id DEE008FC08 for ; Sun, 7 Nov 2010 11:24:22 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id oA7BOLCZ091628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Nov 2010 12:24:22 +0100 (CET) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1289129062; bh=kOi67nbyarH7ilXiBCqvt2uFZdlhQyv5F/XG3f4Xhjo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Transfer-Encoding:In-Reply-To; b=cG0RjPrBmLRoO+HlkBLsDTzVq7RAzfLUSY7B77oG64SoZiWL6seKX1V4jABvA/mpD MDccx3pG85IAIudltpnTc+haurBfsqs1dvV8nAgpak7hGxorL3kCldEHDNg69KZ3a3 1ampcwQGwT4nNxdQ+MZ6ucm1+POm0YGOSJpWoQhk= Received: (from uqs@localhost) by acme.spoerlein.net (8.14.4/8.14.4/Submit) id oA7BOLcO091627; Sun, 7 Nov 2010 12:24:21 +0100 (CET) (envelope-from uqs@spoerlein.net) Date: Sun, 7 Nov 2010 12:24:21 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Pyun YongHyeon Message-ID: <20101107112421.GH85693@acme.spoerlein.net> Mail-Followup-To: Pyun YongHyeon , stable@freebsd.org References: <20101106093700.GW85693@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@freebsd.org Subject: Re: Abysmal re(4) performance under 8.1-STABLE (mid-August) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Nov 2010 11:24:23 -0000 On Sat, 06.11.2010 at 23:19:33 -0700, Pyun YongHyeon wrote: > On Sat, Nov 6, 2010 at 2:37 AM, Ulrich Spörlein wrote: > > Hello Pyun, > > > > On this new server, I cannot get more than ~280kByte/s up/downstream out of > > re(4) without any tweaking. > > > > re0: flags=8843 metric 0 mtu 1500 > >        options=389b > >        ether 00:21:85:63:74:34 > >        inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid 0x1 > >        inet 46.4.12.147 netmask 0xffffffc0 broadcast 46.4.12.191 > >        nd6 options=3 > >        media: Ethernet autoselect (100baseTX ) > >        status: active > > > > It seems the link was resolved to half-duplex. Does link partner > also agree on the resolved speed/duplex? As this is a dedicated server in a colo hundreds of km away, I have no means to check this easily. Especially I cannot change the setting from auto-neg. Btw, linux will show a negotiated 100/full link via mii-tool. > > # ifconfig re0 > > re0: flags=8843 metric 0 mtu 1500 > >        options=88 > >        ether 00:21:85:63:74:34 > >        inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid 0x1 > >        inet 46.4.12.147 netmask 0xffffffc0 broadcast 46.4.12.191 > >        nd6 options=3 > >        media: Ethernet 100baseTX (100baseTX ) > >        status: active > > > > This time, it seems you used forced media configuration > instead of auto. It still shows duplex mismatch so it's > normal to see poor performance. What makes me wonder > is why you have duplex mismatch? > Did you use forced media configuration on link partner? > What happens when you use different switch? Sadly, none of these options are available to me :/ But even 100/half should give more than enough performance, right? Uli From owner-freebsd-stable@FreeBSD.ORG Sun Nov 7 17:13:33 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 ED8F2106564A for ; Sun, 7 Nov 2010 17:13:32 +0000 (UTC) (envelope-from buki@dev.null.cz) Received: from dev.null.cz (dev.null.cz [89.185.226.27]) by mx1.freebsd.org (Postfix) with ESMTP id 6F3D98FC08 for ; Sun, 7 Nov 2010 17:13:32 +0000 (UTC) Received: from dev.null.cz (localhost [127.0.0.1]) by dev.null.cz (8.13.1/8.13.1) with ESMTP id oA7GguMx066929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Nov 2010 17:43:01 +0100 (CET) (envelope-from buki@dev.null.cz) Received: (from buki@localhost) by dev.null.cz (8.13.1/8.13.1/Submit) id oA7Ggk1n066926; Sun, 7 Nov 2010 17:42:46 +0100 (CET) (envelope-from buki) Date: Sun, 7 Nov 2010 17:42:46 +0100 From: "Marek 'Buki' =?iso-8859-2?Q?Kozlovsk=FD?=" To: freebsd-stable@freebsd.org Message-ID: <20101107164246.GA28251@dev.null.cz> References: <20101106093700.GW85693@acme.spoerlein.net> <20101107112421.GH85693@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="U/5EjKfnYgGK6hcj" Content-Disposition: inline In-Reply-To: <20101107112421.GH85693@acme.spoerlein.net> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: ClamAV 0.88.7/7593/Mon Jun 30 23:00:22 2008 on dev.null.cz X-Virus-Status: Clean Cc: Pyun YongHyeon Subject: Re: Abysmal re(4) performance under 8.1-STABLE (mid-August) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Nov 2010 17:13:33 -0000 --U/5EjKfnYgGK6hcj Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 07, 2010 at 12:24:21PM +0100, Ulrich Sp=F6rlein wrote: > On Sat, 06.11.2010 at 23:19:33 -0700, Pyun YongHyeon wrote: > > On Sat, Nov 6, 2010 at 2:37 AM, Ulrich Sp=F6rlein w= rote: > > > Hello Pyun, > > > > > > On this new server, I cannot get more than ~280kByte/s up/downstream = out of > > > re(4) without any tweaking. > > > > > > re0: flags=3D8843 metric 0 mt= u 1500 > > > =A0 =A0 =A0 =A0options=3D389b > > > =A0 =A0 =A0 =A0ether 00:21:85:63:74:34 > > > =A0 =A0 =A0 =A0inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopei= d 0x1 > > > =A0 =A0 =A0 =A0inet 46.4.12.147 netmask 0xffffffc0 broadcast 46.4.12.= 191 > > > =A0 =A0 =A0 =A0nd6 options=3D3 > > > =A0 =A0 =A0 =A0media: Ethernet autoselect (100baseTX ) > > > =A0 =A0 =A0 =A0status: active > > > > >=20 > > It seems the link was resolved to half-duplex. Does link partner > > also agree on the resolved speed/duplex? >=20 > As this is a dedicated server in a colo hundreds of km away, I have no > means to check this easily. Especially I cannot change the setting from > auto-neg. Btw, linux will show a negotiated 100/full link via mii-tool. you can always ask the guys responsible for network infrastructure > > > # ifconfig re0 > > > re0: flags=3D8843 metric 0 mt= u 1500 > > > =A0 =A0 =A0 =A0options=3D88 > > > =A0 =A0 =A0 =A0ether 00:21:85:63:74:34 > > > =A0 =A0 =A0 =A0inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopei= d 0x1 > > > =A0 =A0 =A0 =A0inet 46.4.12.147 netmask 0xffffffc0 broadcast 46.4.12.= 191 > > > =A0 =A0 =A0 =A0nd6 options=3D3 > > > =A0 =A0 =A0 =A0media: Ethernet 100baseTX (100baseTX ) > > > =A0 =A0 =A0 =A0status: active > > > > >=20 > > This time, it seems you used forced media configuration > > instead of auto. It still shows duplex mismatch so it's > > normal to see poor performance. What makes me wonder > > is why you have duplex mismatch? > > Did you use forced media configuration on link partner? > > What happens when you use different switch? >=20 > Sadly, none of these options are available to me :/ > But even 100/half should give more than enough performance, right? no, not if the other end is 100/full. Duplex mismatch usually gives around 100-200 kB/s. I've experienced this (around 75kB/s), setting speed/duplex manually fixed the problem. > Uli > _______________________________________________ > 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" Buki --=20 PGP public key: http://dev.null.cz/buki.asc /"\ \ / ASCII Ribbon Campaign X Against HTML & Outlook Mail / \ http://www.thebackrow.net --U/5EjKfnYgGK6hcj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD4DBQFM1tcGPzhIkpLLm08RAjk7AJ9QAh44yO4LJ49CdFtBRa57f6+8EACWNZbr 3msJ/hAweC9hunVZ6F19iw== =wkVF -----END PGP SIGNATURE----- --U/5EjKfnYgGK6hcj-- From owner-freebsd-stable@FreeBSD.ORG Sun Nov 7 17:22: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 3ECBA1065670 for ; Sun, 7 Nov 2010 17:22:28 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2-6.sentex.ca [IPv6:2607:f3e0:80:80::2]) by mx1.freebsd.org (Postfix) with ESMTP id B3E938FC0A for ; Sun, 7 Nov 2010 17:22:27 +0000 (UTC) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.4/8.14.4) with ESMTP id oA7HMImE001575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 7 Nov 2010 12:22:18 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.4) with ESMTP id oA7HMHUQ037325; Sun, 7 Nov 2010 12:22:17 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <201011071722.oA7HMHUQ037325@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 07 Nov 2010 12:22:10 -0500 To: freebsd-stable@freebsd.org From: Mike Tancsa In-Reply-To: <201009262343.o8QNhgDG012676@lava.sentex.ca> References: <201006102031.o5AKVCH2016467@lava.sentex.ca> <201007021739.o62HdMOU092319@lava.sentex.ca> <20100702193654.GD10862@michelle.cdnetworks.com> <201008162107.o7GL76pA080191@lava.sentex.ca> <20100817185208.GA6482@michelle.cdnetworks.com> <201008171955.o7HJt67T087902@lava.sentex.ca> <20100817200020.GE6482@michelle.cdnetworks.com> <201009141759.o8EHxcZ0013539@lava.sentex.ca> <201009262157.o8QLvR0L012171@lava.sentex.ca> <201009262343.o8QNhgDG012676@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.67 on 205.211.164.50 Cc: pyunyh@gmail.com, Jack Vogel Subject: Re: RELENG_7 em problems (and RELENG_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: Sun, 07 Nov 2010 17:22:28 -0000 Just for the archives, the version of http://lists.freebsd.org/pipermail/svn-src-head/2010-November/022058.html fixes this particular problem on this particular version of the em nic for me on RELENG_8. The motherboard is an intel server board (S3420GPX) em1@pci0:10:0:0: class=0x020000 card=0x34ec8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0003[140] = Serial 1 001517ffffed68a4 em1: port 0x2000-0x201f mem 0xb4100000-0xb411ffff,0xb4120000-0xb4123fff irq 16 at device 0.0 on pci10 em1: Using MSIX interrupts with 3 vectors vmstat -i interrupt total rate irq256: em0 1025859018 993 irq257: em1:rx 0 512606295 496 irq258: em1:tx 0 405695908 393 irq259: em1:link 39853 0 Total 10422193166 10096 ---Mike At 06:43 PM 9/26/2010, Mike Tancsa wrote: >At 06:19 PM 9/26/2010, Jack Vogel wrote: >>Your em1 is using MSI not MSIX and thus can't have multiple queues. I'm >>not sure whats broken from what you show here. I will try to get the new >>driver out shortly for you to try. > >With this particular NIC, it will wedge under high load. I tried 2 >different motherboards and chipsets the same behaviour. > > ---Mike > > >>Jack >> >> >>On Sun, Sep 26, 2010 at 2:57 PM, Mike Tancsa >><mike@sentex.net> wrote: >>At 06:36 PM 9/24/2010, Jack Vogel wrote: >>There is a new revision of the em driver coming next week, its >>going thru some >>stress pounding over the weekend, if no issues show up I'll put it into HEAD. >> >>Yongari's changes in TX context handling which effects checksum and tso >>are added. I've also decided that multiple queues in 82574 just are a source >>of problems without a lot of benefit, so it still uses MSIX but >>with only 3 vectors, >>meaning it seperates TX and RX but has a single queue. >> >> >>Thanks, looking forward to trying it out! With respect to the >>multiple queues, I thought the driver already used just the one on >>RELENG_8 ? If not, is there a way to force the existing driver to >>use just the one queue ? >> >>On the box that has the NIC locking up, it shows >> >>em1@pci0:9:0:0: class=0x020000 card=0x34ec8086 chip=0x10d38086 >>rev=0x00 hdr=0x00 >> >> vendor = 'Intel Corporation' >> device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' >> class = network >> subclass = ethernet >> cap 01[c8] = powerspec 2 supports D0 D3 current D0 >> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message >> cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) >> >>and >> >>vmstat -i shows >> >>irq256: em0 5129063 353 >>irq257: em1 531251 36 >> >>in a wedged state, stats look like >> >>dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.0.5 >>dev.em.1.%driver: em >>dev.em.1.%location: slot=0 function=0 handle=\_SB_.PCI0.PEX4.HART >>dev.em.1.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x8086 >>subdevice=0x34ec class=0x020000 >>dev.em.1.%parent: pci9 >>dev.em.1.nvm: -1 >>dev.em.1.rx_int_delay: 0 >>dev.em.1.tx_int_delay: 66 >>dev.em.1.rx_abs_int_delay: 66 >>dev.em.1.tx_abs_int_delay: 66 >>dev.em.1.rx_processing_limit: 100 >>dev.em.1.link_irq: 0 >>dev.em.1.mbuf_alloc_fail: 0 >>dev.em.1.cluster_alloc_fail: 0 >>dev.em.1.dropped: 0 >>dev.em.1.tx_dma_fail: 0 >>dev.em.1.fc_high_water: 18432 >>dev.em.1.fc_low_water: 16932 >>dev.em.1.mac_stats.excess_coll: 0 >>dev.em.1.mac_stats.symbol_errors: 0 >>dev.em.1.mac_stats.sequence_errors: 0 >>dev.em.1.mac_stats.defer_count: 0 >>dev.em.1.mac_stats.missed_packets: 41522 >>dev.em.1.mac_stats.recv_no_buff: 19 >>dev.em.1.mac_stats.recv_errs: 0 >>dev.em.1.mac_stats.crc_errs: 0 >>dev.em.1.mac_stats.alignment_errs: 0 >>dev.em.1.mac_stats.coll_ext_errs: 0 >>dev.em.1.mac_stats.rx_overruns: 41398 >>dev.em.1.mac_stats.watchdog_timeouts: 0 >>dev.em.1.mac_stats.xon_recvd: 0 >>dev.em.1.mac_stats.xon_txd: 0 >>dev.em.1.mac_stats.xoff_recvd: 0 >>dev.em.1.mac_stats.xoff_txd: 0 >>dev.em.1.mac_stats.total_pkts_recvd: 95229129 >>dev.em.1.mac_stats.good_pkts_recvd: 95187607 >>dev.em.1.mac_stats.bcast_pkts_recvd: 79244 >>dev.em.1.mac_stats.mcast_pkts_recvd: 0 >>dev.em.1.mac_stats.rx_frames_64: 93680 >>dev.em.1.mac_stats.rx_frames_65_127: 1516349 >>dev.em.1.mac_stats.rx_frames_128_255: 4464941 >>dev.em.1.mac_stats.rx_frames_256_511: 4024 >>dev.em.1.mac_stats.rx_frames_512_1023: 2096067 >>dev.em.1.mac_stats.rx_frames_1024_1522: 87012546 >>dev.em.1.mac_stats.good_octets_recvd: 0 >>dev.em.1.mac_stats.good_octest_txd: 0 >>dev.em.1.mac_stats.total_pkts_txd: 66775098 >>dev.em.1.mac_stats.good_pkts_txd: 66775098 >>dev.em.1.mac_stats.bcast_pkts_txd: 509 >>dev.em.1.mac_stats.mcast_pkts_txd: 7 >>dev.em.1.mac_stats.tx_frames_64: 48038472 >>dev.em.1.mac_stats.tx_frames_65_127: 13402833 >>dev.em.1.mac_stats.tx_frames_128_255: 5324413 >>dev.em.1.mac_stats.tx_frames_256_511: 957 >>dev.em.1.mac_stats.tx_frames_512_1023: 319 >>dev.em.1.mac_stats.tx_frames_1024_1522: 8104 >>dev.em.1.mac_stats.tso_txd: 1069 >>dev.em.1.mac_stats.tso_ctx_fail: 0 >>dev.em.1.interrupts.asserts: 0 >>dev.em.1.interrupts.rx_pkt_timer: 0 >>dev.em.1.interrupts.rx_abs_timer: 0 >>dev.em.1.interrupts.tx_pkt_timer: 0 >>dev.em.1.interrupts.tx_abs_timer: 0 >>dev.em.1.interrupts.tx_queue_empty: 0 >>dev.em.1.interrupts.tx_queue_min_thresh: 0 >>dev.em.1.interrupts.rx_desc_min_thresh: 0 >>dev.em.1.interrupts.rx_overrun: 0 >>dev.em.1.host.breaker_tx_pkt: 0 >>dev.em.1.host.host_tx_pkt_discard: 0 >>dev.em.1.host.rx_pkt: 0 >>dev.em.1.host.breaker_rx_pkts: 0 >>dev.em.1.host.breaker_rx_pkt_drop: 0 >>dev.em.1.host.tx_good_pkt: 0 >>dev.em.1.host.breaker_tx_pkt_drop: 0 >>dev.em.1.host.rx_good_bytes: 0 >>dev.em.1.host.tx_good_bytes: 0 >>dev.em.1.host.length_errors: 0 >>dev.em.1.host.serdes_violation_pkt: 0 >>dev.em.1.host.header_redir_missed: 0 >> >>ifconfig down/up just panics or locks up the box when its in this >>state. I also have IPMI enabled on this nic, but it shows the same >>issue with it disabled. >> >> ---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 > >-------------------------------------------------------------------- >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 > >_______________________________________________ >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" -------------------------------------------------------------------- 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 Sun Nov 7 23:11:19 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 F10A3106566C for ; Sun, 7 Nov 2010 23:11:19 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id A42148FC08 for ; Sun, 7 Nov 2010 23:11:19 +0000 (UTC) Received: by yxl31 with SMTP id 31so3181669yxl.13 for ; Sun, 07 Nov 2010 15:11:19 -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:subject :message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=oZArevvnQbjePFnrABziZwobllOvhu7oBOznUVep2YA=; b=J4iH/7G8dwecA4dcX0HgcuUJYdAl1EqR+h30fCjFr5xtwzhHJHxekJEUJP9kOAcG3F 8nCYqGdB/vu9PKrGZtZuL64N6yag1+lBmGnqt4PoffOkAVuMw4+TWBVhnxvlqN/nSZnA /lP7nm/ODoAhMyvm5dmsTI6wnTC71cbUZJauA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=Xgb3fOaxnd7V7Onrnljlq3QE1Oe0b/Wpsi356S7u4MbxF6Sak7mzA6vPgPpO5wjklE gmu1eaXoaoQw6pU/Juh9Li7UHnNwN+PTbhFSCDdAsgGDBkgTZVZ82TjXZwf2n+NyQ7ue xAGmS1Gw/JXUWyic+j0yA5iyQQ8xt90ufwhVY= Received: by 10.150.143.14 with SMTP id q14mr5907344ybd.3.1289171478915; Sun, 07 Nov 2010 15:11:18 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id p38sm1825700ybk.16.2010.11.07.15.11.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 07 Nov 2010 15:11:17 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sun, 7 Nov 2010 15:10:20 -0800 From: Pyun YongHyeon Date: Sun, 7 Nov 2010 15:10:20 -0800 To: stable@freebsd.org Message-ID: <20101107231020.GB1279@michelle.cdnetworks.com> References: <20101106093700.GW85693@acme.spoerlein.net> <20101107112421.GH85693@acme.spoerlein.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101107112421.GH85693@acme.spoerlein.net> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: Abysmal re(4) performance under 8.1-STABLE (mid-August) 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, 07 Nov 2010 23:11:20 -0000 On Sun, Nov 07, 2010 at 12:24:21PM +0100, Ulrich Sp??rlein wrote: > On Sat, 06.11.2010 at 23:19:33 -0700, Pyun YongHyeon wrote: > > On Sat, Nov 6, 2010 at 2:37 AM, Ulrich Sp??rlein wrote: > > > Hello Pyun, > > > > > > On this new server, I cannot get more than ~280kByte/s up/downstream out of > > > re(4) without any tweaking. > > > > > > re0: flags=8843 metric 0 mtu 1500 > > > ?? ?? ?? ??options=389b > > > ?? ?? ?? ??ether 00:21:85:63:74:34 > > > ?? ?? ?? ??inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid 0x1 > > > ?? ?? ?? ??inet 46.4.12.147 netmask 0xffffffc0 broadcast 46.4.12.191 > > > ?? ?? ?? ??nd6 options=3 > > > ?? ?? ?? ??media: Ethernet autoselect (100baseTX ) > > > ?? ?? ?? ??status: active > > > > > > > It seems the link was resolved to half-duplex. Does link partner > > also agree on the resolved speed/duplex? > > As this is a dedicated server in a colo hundreds of km away, I have no > means to check this easily. Especially I cannot change the setting from > auto-neg. Btw, linux will show a negotiated 100/full link via mii-tool. > I guess you can contact network administrator of the data center to check the switch configuration. IEEE 802.3 says if link parter use forced full-duplex media and you use auto media, the resolved duplex is half-duplex by definition. I think RealTek may have followed the standard. There is no reason to use manual media configuration unless your link partner is severely broken with auto-negotiation. Due to silicon bug of RealTek PHYs, rgephy(4) always use auto-negotiation so manual media configuration is a kind of auto-negotiation with limited set of available media advertising. I don't know how Linux solve the silicon bug though. One of magic DSP fixups might fix the issue, the DSP fixups vendor released is not under BSD license and does not say more detailed information for the code. > > > # ifconfig re0 > > > re0: flags=8843 metric 0 mtu 1500 > > > ?? ?? ?? ??options=88 > > > ?? ?? ?? ??ether 00:21:85:63:74:34 > > > ?? ?? ?? ??inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid 0x1 > > > ?? ?? ?? ??inet 46.4.12.147 netmask 0xffffffc0 broadcast 46.4.12.191 > > > ?? ?? ?? ??nd6 options=3 > > > ?? ?? ?? ??media: Ethernet 100baseTX (100baseTX ) > > > ?? ?? ?? ??status: active > > > > > > > This time, it seems you used forced media configuration > > instead of auto. It still shows duplex mismatch so it's > > normal to see poor performance. What makes me wonder > > is why you have duplex mismatch? > > Did you use forced media configuration on link partner? > > What happens when you use different switch? > > Sadly, none of these options are available to me :/ > But even 100/half should give more than enough performance, right? > No, with half-duplex link, you can't send frames while RX is in progress. The reverse is also true for half-duplex link. The more severe problem is your link partner think it established full-duplex link so it does not care about possible collisions. Either change your link partner's media configuration to half-duplex or auto. auto is preferred one, of course. From owner-freebsd-stable@FreeBSD.ORG Sun Nov 7 23:52: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 5E39C106564A for ; Sun, 7 Nov 2010 23:52:51 +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 23EEA8FC0C for ; Sun, 7 Nov 2010 23:52:51 +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 1PFF2X-00024U-Og for freebsd-stable@freebsd.org; Sun, 07 Nov 2010 23:52:49 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PFF2X-000AYx-N5 for freebsd-stable@freebsd.org; Sun, 07 Nov 2010 23:52:49 +0000 Date: Sun, 07 Nov 2010 23:52:49 +0000 Message-Id: To: freebsd-stable@freebsd.org From: Pete French Subject: Re: hast vs ggate+gmirror sychrnoisation speed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Nov 2010 23:52:51 -0000 Just to report back on this - I just tried the patches from last week, which fixed the sending of the keepalives in the different thread, but my original issue (the sychronisation speed) remains I'm afraid - so much for the theory that the corruption was causing the speed decrease. It's obviously good to have the threading issue fixed though. -pete. From owner-freebsd-stable@FreeBSD.ORG Mon Nov 8 16:19: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 6B77F106567A for ; Mon, 8 Nov 2010 16:19:14 +0000 (UTC) (envelope-from joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com) Received: from relay01-haj2.antispameurope.com (relay01-haj2.antispameurope.com [83.246.65.51]) by mx1.freebsd.org (Postfix) with ESMTP id EF4BC8FC2A for ; Mon, 8 Nov 2010 16:19:13 +0000 (UTC) Received: by relay01-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 8DA02160058; Mon, 8 Nov 2010 17:19:11 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay01-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 8C831160053; Mon, 8 Nov 2010 17:19:09 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id oA8GJ3Yp026804; Mon, 8 Nov 2010 17:19:08 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Nov 2010 17:18:42 +0100 Date: Mon, 08 Nov 2010 17:18:39 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: mav@freebsd.org, marius@alchemy.franken.de Message-ID: <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> References: <4CD45209.5010607@FreeBSD.org> <20101105192028.GA68728@alchemy.franken.de> In-Reply-To: <20101105192028.GA68728@alchemy.franken.de> User-Agent: nail 11.22 3/20/05 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 08 Nov 2010 16:18:42.0976 (UTC) FILETIME=[9C854A00:01CB7F60] Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Sense fetching [Was: cdrtools /devel ...] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Nov 2010 16:19:14 -0000 Marius Strobl wrote: > On Fri, Nov 05, 2010 at 08:50:49PM +0200, Alexander Motin wrote: > > Hi. > > > > I've reviewed tests that scgcheck does to SCSI subsystem. It shown > > combination of several issues in both CAM, ahci(4) and cdrtools itself. > > Several small patches allow us to pass most of that tests: > > http://people.freebsd.org/~mav/sense/ > > > > ahci_resid.patch: Add support for reporting residual length on data > > underrun. SCSI commands often returns results shorter then expected. > > Returned value allows application to know/check how much data it really > > has. It is also important for sense fetching, as ATAPI and USB devices > > return sense as data in response to REQUEST_SENSE command. > > > > sense_resid.patch: When manually requesting sense data (ATAPI or USB), > > request only as much data as user requested (not the fixed structure > > size), and return respective sense residual length. Your patch to libscg looks definitely OK if we only look at the new corrected kernel driver behavior. There is a problem: In case that there is a sense data residual > 0, libscg will asume that there is less sense data that really present in case that a "new" libscg is runnung on an old kernel. Given the fact that many drives will probably only return 18 bytes of sense data, this will happen every time libscg is told to fetch more sense than the drive is willing to return. Is there a way to distinct an old kernel from a new one? > > pass_autosence.patch: Unless CAM_DIS_AUTOSENSE is set, always fetch > > sense if not done by SIM, independently of CAM_PASS_ERR_RECOVER. As soon > > as device freeze released before returning to user-level, user-level > > application by definition can't reliably fetch sense data if some other > > application (like hald) tries to access device same time. This is what we need! > > cdrtools.patch: Make libscg (part of cdrtools) on FreeBSD to submit > > wanted sense length to CAM and do not clear sense return buffer. It is > > mostly cosmetics, important probably only for scgcheck. I see no advantage in removing the call to fillbytes(). > Please don't commit this to the port directly but let it loop back > via upstream (CC'ed) instead, otherwise we would need to obey the > following, which is undesirable, especially if these really are > mostly cosmetic issues: > /* > * Warning: you may change this source, but if you do that > * you need to change the _scg_version and _scg_auth* string below. > * You may not return "schily" for an SCG_AUTHOR request anymore. > * Choose your name instead of "schily" and make clear that the version > * string is related to a modified source. > */ > > > > > Testers and reviewers welcome. I am especially interested in opinion > > about pass_autosence.patch -- may be we should lower sense fetching even > > deeper, to make it work for all cam_periph_runccb() consumers. Did you test a modified libscg on an unmodified kernel? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From owner-freebsd-stable@FreeBSD.ORG Mon Nov 8 17:07: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 B4601106566C; Mon, 8 Nov 2010 17:07:12 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3E1878FC17; Mon, 8 Nov 2010 17:07:11 +0000 (UTC) Received: by gya6 with SMTP id 6so3656542gya.13 for ; Mon, 08 Nov 2010 09:07:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=mKLa3Rhl/UcBVIRyAaMGm5Q/nCbrZQiygnc0ugu78rw=; b=A3XV+P5mrQmXOKz9L7KZfb7bYXFwW//qua9paFfJh1RJ6uig2tmHkl2Zv2mTfmFgiP t/n/dfyIJ2FVIYlvUDIebhzg5SVI4kzY5ieHUOp/GTuo+rxcPRYOCZjx8hXr42wIaVLl YcNr9r+uQkRRsud/nAT0eZbADQ57nno8EXYrQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=aet/aXVnQY3M3DJkssNRvfM2Xjne+7wCV/FN6RXf1dQFrB/XhLCSUFk7jI2sEDQ27y zM4d2HkmByjxQ0nEq2FktO+YOZcqOj0Uwkq0SLryFbbdcam2tCETyvxwWGV2NoA/redd M6AHDjyYel3npX1w0VzzcG6WcM+qiLWfOjG/Q= Received: by 10.204.83.215 with SMTP id g23mr4999124bkl.211.1289236030919; Mon, 08 Nov 2010 09:07:10 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id p34sm103871bkf.3.2010.11.08.09.07.07 (version=SSLv3 cipher=RC4-MD5); Mon, 08 Nov 2010 09:07:08 -0800 (PST) Sender: Alexander Motin Message-ID: <4CD82E2A.3070407@FreeBSD.org> Date: Mon, 08 Nov 2010 19:06:50 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Joerg Schilling References: <4CD45209.5010607@FreeBSD.org> <20101105192028.GA68728@alchemy.franken.de> <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> In-Reply-To: <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org, marius@alchemy.franken.de Subject: Re: Sense fetching [Was: cdrtools /devel ...] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Nov 2010 17:07:12 -0000 Joerg Schilling wrote: > Marius Strobl wrote: >> On Fri, Nov 05, 2010 at 08:50:49PM +0200, Alexander Motin wrote: >>> I've reviewed tests that scgcheck does to SCSI subsystem. It shown >>> combination of several issues in both CAM, ahci(4) and cdrtools itself. >>> Several small patches allow us to pass most of that tests: >>> http://people.freebsd.org/~mav/sense/ >>> >>> ahci_resid.patch: Add support for reporting residual length on data >>> underrun. SCSI commands often returns results shorter then expected. >>> Returned value allows application to know/check how much data it really >>> has. It is also important for sense fetching, as ATAPI and USB devices >>> return sense as data in response to REQUEST_SENSE command. >>> >>> sense_resid.patch: When manually requesting sense data (ATAPI or USB), >>> request only as much data as user requested (not the fixed structure >>> size), and return respective sense residual length. > > Your patch to libscg looks definitely OK if we only look at the new corrected > kernel driver behavior. > > There is a problem: > > In case that there is a sense data residual > 0, libscg will asume that there > is less sense data that really present in case that a "new" libscg is runnung > on an old kernel. > > Given the fact that many drives will probably only return 18 bytes of sense > data, this will happen every time libscg is told to fetch more sense than the > drive is willing to return. > > Is there a way to distinct an old kernel from a new one? I don't see the problem. Previous kernel in most cases reported sesnse_resid == 0, lying that there is more sense data then really is. New one should report real (often positive) value. In both cases sesnse_resid value measured from the value submitted to the kernel. >>> pass_autosence.patch: Unless CAM_DIS_AUTOSENSE is set, always fetch >>> sense if not done by SIM, independently of CAM_PASS_ERR_RECOVER. As soon >>> as device freeze released before returning to user-level, user-level >>> application by definition can't reliably fetch sense data if some other >>> application (like hald) tries to access device same time. > > This is what we need! Agree. >>> cdrtools.patch: Make libscg (part of cdrtools) on FreeBSD to submit >>> wanted sense length to CAM and do not clear sense return buffer. It is >>> mostly cosmetics, important probably only for scgcheck. > > I see no advantage in removing the call to fillbytes(). scgcheck tests how much sense data received by counting 0x00 and 0xff bytes. Zero-filling response buffer breaks that check. Though I have no idea if other crdtools' applications depend on these zeros. There could be some internal inconsistency. >> Please don't commit this to the port directly but let it loop back >> via upstream (CC'ed) instead, otherwise we would need to obey the >> following, which is undesirable, especially if these really are >> mostly cosmetic issues: >> /* >> * Warning: you may change this source, but if you do that >> * you need to change the _scg_version and _scg_auth* string below. >> * You may not return "schily" for an SCG_AUTHOR request anymore. >> * Choose your name instead of "schily" and make clear that the version >> * string is related to a modified source. >> */ >> >>> Testers and reviewers welcome. I am especially interested in opinion >>> about pass_autosence.patch -- may be we should lower sense fetching even >>> deeper, to make it work for all cam_periph_runccb() consumers. > > Did you test a modified libscg on an unmodified kernel? Unmodified kernel by default doesn't return any sense data at all for new CAM-based ATA -- this changes should be invariant. New scgcheck runs same bad as old. It just can't become worse. :) Legacy atapicam wrapper ignores sense_len on input and doesn't fill sense_resig on output -- I haven't tested, but it also should be invariant. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Mon Nov 8 17:23:31 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 4EB7E1065670 for ; Mon, 8 Nov 2010 17:23:31 +0000 (UTC) (envelope-from joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com) Received: from relay01-haj2.antispameurope.com (relay01-haj2.antispameurope.com [83.246.65.51]) by mx1.freebsd.org (Postfix) with ESMTP id D1B1B8FC18 for ; Mon, 8 Nov 2010 17:23:30 +0000 (UTC) Received: by relay01-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 549DF16009B; Mon, 8 Nov 2010 18:23:28 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay01-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 7C4EB160082; Mon, 8 Nov 2010 18:23:26 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id oA8HNQ3s028569; Mon, 8 Nov 2010 18:23:26 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Nov 2010 18:23:26 +0100 Date: Mon, 08 Nov 2010 18:23:22 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: mav@FreeBSD.org Message-ID: <4cd8320a.U7/OjtLLBVtE4dTy%Joerg.Schilling@fokus.fraunhofer.de> References: <4CD45209.5010607@FreeBSD.org> <20101105192028.GA68728@alchemy.franken.de> <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> <4CD82E2A.3070407@FreeBSD.org> In-Reply-To: <4CD82E2A.3070407@FreeBSD.org> User-Agent: nail 11.22 3/20/05 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 08 Nov 2010 17:23:26.0747 (UTC) FILETIME=[A76DB6B0:01CB7F69] Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, marius@alchemy.franken.de Subject: Re: Sense fetching [Was: cdrtools /devel ...] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Nov 2010 17:23:31 -0000 Alexander Motin wrote: > > Your patch to libscg looks definitely OK if we only look at the new corrected > > kernel driver behavior. > > > > There is a problem: > > > > In case that there is a sense data residual > 0, libscg will asume that there > > is less sense data that really present in case that a "new" libscg is runnung > > on an old kernel. > > > > Given the fact that many drives will probably only return 18 bytes of sense > > data, this will happen every time libscg is told to fetch more sense than the > > drive is willing to return. > > > > Is there a way to distinct an old kernel from a new one? > > I don't see the problem. Previous kernel in most cases reported > sesnse_resid == 0, lying that there is more sense data then really is. > New one should report real (often positive) value. In both cases > sesnse_resid value measured from the value submitted to the kernel. Did the old kernel return a zero sense_resid for any implemented SCSI transport? Libscg is a generic SCSI transport library and cdrecord is just one user of this lib. > > I see no advantage in removing the call to fillbytes(). > > scgcheck tests how much sense data received by counting 0x00 and 0xff > bytes. Zero-filling response buffer breaks that check. Though I have no > idea if other crdtools' applications depend on these zeros. There could > be some internal inconsistency. O, I need to check other low level transport adaptation layers and think about this statement. > > Did you test a modified libscg on an unmodified kernel? > > Unmodified kernel by default doesn't return any sense data at all for > new CAM-based ATA -- this changes should be invariant. New scgcheck runs > same bad as old. It just can't become worse. :) > > Legacy atapicam wrapper ignores sense_len on input and doesn't fill > sense_resig on output -- I haven't tested, but it also should be invariant. I am not only talking about ATAPI but abut SCSI in general. Do you know the CAM behavior for other SCSI transports? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From owner-freebsd-stable@FreeBSD.ORG Mon Nov 8 17:37: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 A4C541065679; Mon, 8 Nov 2010 17:37:14 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2B2458FC32; Mon, 8 Nov 2010 17:37:13 +0000 (UTC) Received: by gwj16 with SMTP id 16so3708623gwj.13 for ; Mon, 08 Nov 2010 09:37:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=J6iMJgoeWVi8OfHg7wJvIJktNxMfinvbWbpZDwyVoMM=; b=N3dxE/P7PSaaZHVB+cjmJML6yL9AVXJJFNVAbFmSfsMDpERNxFHaRcSIV1hEMAYB3P qFOWxtCjgYWbxkx5caGuLXo98jP1SVksBjh9WuIJ41qfco7MsHG5iGH4RTk1qx7rNNwU 2SU6TGDVMg+R9MO1bQ0BG0YuahnjJKqO6Ou6o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=bKyHCwuueJ/v8BgRu8SHAQcomYuFQ1UUHpTb7F8uigb/cvfHAa52TvUc7O6jnAPFDM mnlhfNR8+vqjeHvUhalIHIRMZms3G8LGl80cGvY8byZQoyhwmY6+6c7Pyu29ZBXYQJkV fJW75t1MJ0UpZjh1UFitr1p9Lr5SrVNJ/u1p4= Received: by 10.204.60.199 with SMTP id q7mr684335bkh.39.1289237832362; Mon, 08 Nov 2010 09:37:12 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id p22sm126133bkp.21.2010.11.08.09.37.10 (version=SSLv3 cipher=RC4-MD5); Mon, 08 Nov 2010 09:37:11 -0800 (PST) Sender: Alexander Motin Message-ID: <4CD83535.1010008@FreeBSD.org> Date: Mon, 08 Nov 2010 19:36:53 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Joerg Schilling References: <4CD45209.5010607@FreeBSD.org> <20101105192028.GA68728@alchemy.franken.de> <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> <4CD82E2A.3070407@FreeBSD.org> <4cd8320a.U7/OjtLLBVtE4dTy%Joerg.Schilling@fokus.fraunhofer.de> In-Reply-To: <4cd8320a.U7/OjtLLBVtE4dTy%Joerg.Schilling@fokus.fraunhofer.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, marius@alchemy.franken.de Subject: Re: Sense fetching [Was: cdrtools /devel ...] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Nov 2010 17:37:14 -0000 Joerg Schilling wrote: > Alexander Motin wrote: >>> Your patch to libscg looks definitely OK if we only look at the new corrected >>> kernel driver behavior. >>> >>> There is a problem: >>> >>> In case that there is a sense data residual > 0, libscg will asume that there >>> is less sense data that really present in case that a "new" libscg is runnung >>> on an old kernel. >>> >>> Given the fact that many drives will probably only return 18 bytes of sense >>> data, this will happen every time libscg is told to fetch more sense than the >>> drive is willing to return. >>> >>> Is there a way to distinct an old kernel from a new one? >> I don't see the problem. Previous kernel in most cases reported >> sesnse_resid == 0, lying that there is more sense data then really is. >> New one should report real (often positive) value. In both cases >> sesnse_resid value measured from the value submitted to the kernel. > > Did the old kernel return a zero sense_resid for any implemented SCSI > transport? Libscg is a generic SCSI transport library and cdrecord is just one > user of this lib. Not sure I understand your question. Zero sesnse_resid is absolutely normal situation if device gave same amount of sense as application requested. As I can see, many of SCSI controllers report sesnse_resid properly. I may assume that some, like atapicd don't -- in that case you'll also see 0 there. >>> I see no advantage in removing the call to fillbytes(). >> scgcheck tests how much sense data received by counting 0x00 and 0xff >> bytes. Zero-filling response buffer breaks that check. Though I have no >> idea if other crdtools' applications depend on these zeros. There could >> be some internal inconsistency. > > O, I need to check other low level transport adaptation layers and think about > this statement. > >>> Did you test a modified libscg on an unmodified kernel? >> Unmodified kernel by default doesn't return any sense data at all for >> new CAM-based ATA -- this changes should be invariant. New scgcheck runs >> same bad as old. It just can't become worse. :) >> >> Legacy atapicam wrapper ignores sense_len on input and doesn't fill >> sense_resig on output -- I haven't tested, but it also should be invariant. > > I am not only talking about ATAPI but abut SCSI in general. > > Do you know the CAM behavior for other SCSI transports? I don't have real SCSI CD to test, but a as I can see, most of SCSI controllers return sense data automatically. Sense fetching changes should not affect/break anything there. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Mon Nov 8 21:41:14 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 78FF6106564A for ; Mon, 8 Nov 2010 21:41:14 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2001:470:9a47::1]) by mx1.freebsd.org (Postfix) with ESMTP id 27D2D8FC14 for ; Mon, 8 Nov 2010 21:41:14 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id oA8LfC6F031725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Nov 2010 22:41:13 +0100 (CET) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1289252473; bh=DdJjqnSUGzFWP+q6vfU+q5jyKqlsDl2GWHUt27CESiE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=UIL6CReG8PjbbdNLhJlhh+kCxcTWdGaXxmpfUt6tjoAEwWdjbPjQ6e2kdWc7nV8vL GNwxNp14zBCCZmoXfKvi9XwbRdyxKPEgfTikn0N3Vjd5pSa19V+lPrd1p44rCCVaQs 5eVOzzsWpI7QcYVqJWSHAQq49d61YODTqaoEZit0= Received: (from uqs@localhost) by acme.spoerlein.net (8.14.4/8.14.4/Submit) id oA8LfC4M031724; Mon, 8 Nov 2010 22:41:12 +0100 (CET) (envelope-from uqs@spoerlein.net) Date: Mon, 8 Nov 2010 22:41:12 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Pyun YongHyeon Message-ID: <20101108214112.GY85693@acme.spoerlein.net> Mail-Followup-To: Pyun YongHyeon , stable@freebsd.org References: <20101106093700.GW85693@acme.spoerlein.net> <20101107112421.GH85693@acme.spoerlein.net> <20101107231020.GB1279@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101107231020.GB1279@michelle.cdnetworks.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@freebsd.org Subject: Re: Abysmal re(4) performance under 8.1-STABLE (mid-August) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Nov 2010 21:41:14 -0000 On Sun, 07.11.2010 at 15:10:20 -0800, Pyun YongHyeon wrote: > On Sun, Nov 07, 2010 at 12:24:21PM +0100, Ulrich Sp??rlein wrote: > > On Sat, 06.11.2010 at 23:19:33 -0700, Pyun YongHyeon wrote: > > > On Sat, Nov 6, 2010 at 2:37 AM, Ulrich Sp??rlein wrote: > > > > Hello Pyun, > > > > > > > > On this new server, I cannot get more than ~280kByte/s up/downstream out of > > > > re(4) without any tweaking. > > > > > > > > re0: flags=8843 metric 0 mtu 1500 > > > > ?? ?? ?? ??options=389b > > > > ?? ?? ?? ??ether 00:21:85:63:74:34 > > > > ?? ?? ?? ??inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid 0x1 > > > > ?? ?? ?? ??inet 46.4.12.147 netmask 0xffffffc0 broadcast 46.4.12.191 > > > > ?? ?? ?? ??nd6 options=3 > > > > ?? ?? ?? ??media: Ethernet autoselect (100baseTX ) > > > > ?? ?? ?? ??status: active > > > > > > > > > > It seems the link was resolved to half-duplex. Does link partner > > > also agree on the resolved speed/duplex? > > > > As this is a dedicated server in a colo hundreds of km away, I have no > > means to check this easily. Especially I cannot change the setting from > > auto-neg. Btw, linux will show a negotiated 100/full link via mii-tool. > > > > I guess you can contact network administrator of the data center to > check the switch configuration. IEEE 802.3 says if link parter use > forced full-duplex media and you use auto media, the resolved > duplex is half-duplex by definition. I think RealTek may have > followed the standard. There is no reason to use manual media > configuration unless your link partner is severely broken with > auto-negotiation. > > Due to silicon bug of RealTek PHYs, rgephy(4) always use > auto-negotiation so manual media configuration is a kind of > auto-negotiation with limited set of available media advertising. > I don't know how Linux solve the silicon bug though. One of magic > DSP fixups might fix the issue, the DSP fixups vendor released is > not under BSD license and does not say more detailed information > for the code. Luckily the provider switch me to another switch that is set to autoneg, instead of hardcoded to 100/full. re(4) now happily transfers with reasonable speeds, ie. 11MByte/s. Thanks! Uli From owner-freebsd-stable@FreeBSD.ORG Tue Nov 9 03:11: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 D98DB106564A for ; Tue, 9 Nov 2010 03:11:27 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id AE4678FC15 for ; Tue, 9 Nov 2010 03:11:27 +0000 (UTC) Received: (qmail 27347 invoked by uid 89); 9 Nov 2010 03:11:25 -0000 Received: from unknown (HELO ?192.168.0.18?) (danallen46@airwired.net@66.29.174.6) by mail.utahbroadband.com with ESMTPA; 9 Nov 2010 03:11:25 -0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/mixed; boundary=Apple-Mail-1--420044992 From: Dan Allen In-Reply-To: <4CD42127.5070902@icyb.net.ua> Date: Mon, 8 Nov 2010 20:11:23 -0700 Message-Id: References: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> <4CD11FE9.8050105@freebsd.org> <5224E1F5-4567-45A8-A12C-868F7B45BC21@airwired.net> <4CD42127.5070902@icyb.net.ua> To: Andriy Gapon X-Mailer: Apple Mail (2.1081) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Sergey Kandaurov , FreeBSD-STABLE Mailing List Subject: Re: Fatal trap 18 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Nov 2010 03:11:27 -0000 --Apple-Mail-1--420044992 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 5 Nov 2010, at 9:22 AM, Andriy Gapon wrote: > Let's look at the following: > 0. your kernel config > 1. verbose dmesg > 2. acpidump -dt output > 3. x86info -a (sysutils/x86info) Andriy, I sync'd with CURRENT and got your patch today as part of the = official sources. My machine at least boots up fine, but still with = just one logical CPU... Attached is a zip file containing all of the 4 outputs as requested = above. Dan --Apple-Mail-1--420044992 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail-1--420044992-- From owner-freebsd-stable@FreeBSD.ORG Tue Nov 9 05:31: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 7AA001065673 for ; Tue, 9 Nov 2010 05:31:17 +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 B92B28FC46 for ; Tue, 9 Nov 2010 05:31:16 +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 HAA14185; Tue, 09 Nov 2010 07:30:48 +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 1PFgn9-00074c-L1; Tue, 09 Nov 2010 07:30:47 +0200 Message-ID: <4CD8DC87.3090207@icyb.net.ua> Date: Tue, 09 Nov 2010 07:30:47 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Dan Allen References: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> <4CD11FE9.8050105@freebsd.org> <5224E1F5-4567-45A8-A12C-868F7B45BC21@airwired.net> <4CD42127.5070902@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sergey Kandaurov , FreeBSD-STABLE Mailing List Subject: Re: Fatal trap 18 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Nov 2010 05:31:17 -0000 on 09/11/2010 05:11 Dan Allen said the following: > > On 5 Nov 2010, at 9:22 AM, Andriy Gapon wrote: > >> Let's look at the following: >> 0. your kernel config >> 1. verbose dmesg >> 2. acpidump -dt output >> 3. x86info -a (sysutils/x86info) > > Andriy, I sync'd with CURRENT and got your patch today as part of the official sources. My machine at least boots up fine, but still with just one logical CPU... > > Attached is a zip file containing all of the 4 outputs as requested above. Can you please also provide the following output: $ kenv | fgrep hint.acpi -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Nov 9 11:19: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 6C5DB106564A for ; Tue, 9 Nov 2010 11:19:11 +0000 (UTC) (envelope-from mdonada@auroraalimentos.com.br) Received: from auroraalimentos.com.br (mx.auroraalimentos.com.br [200.228.43.6]) by mx1.freebsd.org (Postfix) with ESMTP id 182FB8FC08 for ; Tue, 9 Nov 2010 11:19:10 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by auroraalimentos.com.br (Postfix) with ESMTP id B8DF9FD40B4 for ; Tue, 9 Nov 2010 09:09:20 -0200 (BRST) Received: from auroraalimentos.com.br ([127.0.0.1]) by localhost (mx.auroraalimentos.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+yq+BFF4b8i for ; Tue, 9 Nov 2010 09:09:20 -0200 (BRST) Received: from [121.1.16.22] (unknown [121.1.16.22]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by auroraalimentos.com.br (Postfix) with ESMTP id 865FBFD4095 for ; Tue, 9 Nov 2010 09:09:18 -0200 (BRST) Message-ID: <4CD92E25.7060304@auroraalimentos.com.br> Date: Tue, 09 Nov 2010 09:19:01 -0200 From: =?ISO-8859-1?Q?M=E1rcio_Luciano_Donada?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: watchdog X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Nov 2010 11:19:11 -0000 Hi list, I'm using FreeBSD (uname is below) and these days I'm caught in the log message below: vpn# uname -a FreeBSD vpn.auroraalimentos.com.br 7.3-STABLE FreeBSD 7.3-STABLE #0: Sat Jun 19 18:39:18 BRT 2010 root@vpn.xxx.com.br:/usr/obj/usr/src/sys/VPN i386 Nov 8 11:53:55 vpn kernel: xl0: watchdog timeout (missed Tx interrupts) -- recovering Nov 8 12:01:21 vpn kernel: xl0: watchdog timeout (missed Tx interrupts) -- recovering Nov 8 12:21:55 vpn kernel: xl0: watchdog timeout (missed Tx interrupts) -- recovering Nov 8 16:11:34 vpn kernel: xl0: watchdog timeout (missed Tx interrupts) -- recovering it is possible that the network interface (xl0) is in trouble? -- Márcio Luciano Donada Aurora Alimentos - Cooperativa Central Oeste Catarinense Departamento de T.I. From owner-freebsd-stable@FreeBSD.ORG Tue Nov 9 13:55: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 285F5106564A for ; Tue, 9 Nov 2010 13:55:39 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id DE9C48FC1C for ; Tue, 9 Nov 2010 13:55:38 +0000 (UTC) Received: (qmail 4868 invoked by uid 89); 9 Nov 2010 13:55:35 -0000 Received: from unknown (HELO ?192.168.0.18?) (danallen46@airwired.net@66.29.174.6) by mail.utahbroadband.com with ESMTPA; 9 Nov 2010 13:55:35 -0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Dan Allen In-Reply-To: <4CD8DC87.3090207@icyb.net.ua> Date: Tue, 9 Nov 2010 06:55:34 -0700 Content-Transfer-Encoding: 7bit Message-Id: <24FCCE4A-C7C2-4EDE-9521-3D562391ACE4@airwired.net> References: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> <4CD11FE9.8050105@freebsd.org> <5224E1F5-4567-45A8-A12C-868F7B45BC21@airwired.net> <4CD42127.5070902@icyb.net.ua> <4CD8DC87.3090207@icyb.net.ua> To: Andriy Gapon X-Mailer: Apple Mail (2.1081) Cc: Sergey Kandaurov , FreeBSD-STABLE Mailing List Subject: Re: Fatal trap 18 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Nov 2010 13:55:39 -0000 On 8 Nov 2010, at 10:30 PM, Andriy Gapon wrote: > Can you please also provide the following output: > $ kenv | fgrep hint.acpi hint.acpi.0.oem="TOSHIB" hint.acpi.0.revision="1" hint.acpi.0.rsdp="0xf01e0" hint.acpi.0.rsdt="0x3f7a0000" From owner-freebsd-stable@FreeBSD.ORG Tue Nov 9 14:01: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 2F5C5106566B for ; Tue, 9 Nov 2010 14:01:02 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id E554D8FC15 for ; Tue, 9 Nov 2010 14:01:01 +0000 (UTC) Received: (qmail 7819 invoked by uid 89); 9 Nov 2010 14:00:53 -0000 Received: from unknown (HELO ?192.168.0.18?) (danallen46@airwired.net@66.29.174.6) by mail.utahbroadband.com with ESMTPA; 9 Nov 2010 14:00:53 -0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Dan Allen In-Reply-To: Date: Tue, 9 Nov 2010 07:00:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4B3E11D5-3909-4F27-8598-EA4BFB0A2B26@airwired.net> References: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> <4CD11FE9.8050105@freebsd.org> <5224E1F5-4567-45A8-A12C-868F7B45BC21@airwired.net> <4CD42127.5070902@icyb.net.ua> To: FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.1081) Cc: Sergey Kandaurov , Andriy Gapon , Jeremy Chadwick Subject: Missing CPU Debug Output X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Nov 2010 14:01:02 -0000 This very long email contains the non-zipped versions of the four debug = files requested. acpidump -dt output: /* RSD PTR: OEM=3DTOSHIB, ACPI_Rev=3D1.0x (0) RSDT=3D0x3f7a0000, cksum=3D95 */ /* RSDT: Length=3D56, Revision=3D1, Checksum=3D84, OEMID=3DTOSHIB, OEM Table ID=3D750, OEM Revision=3D0x970814, Creator ID=3DTASM, Creator Revision=3D0x4010000 Entries=3D{ 0x3f7a0068, 0x3f7a511c, 0x3f7a5cd4, 0x3f7a5d3c, = 0x3f7a5dac } */ /* FACP: Length=3D132, Revision=3D2, Checksum=3D48, OEMID=3DTOSHIB, OEM Table ID=3D750, OEM Revision=3D0x20030101, Creator ID=3DTASM, Creator Revision=3D0x4010000 FACS=3D0xeee00, DSDT=3D0x3f7a00ec INT_MODEL=3DPIC Preferred_PM_Profile=3DUnspecified (0) SCI_INT=3D9 SMI_CMD=3D0xb2, ACPI_ENABLE=3D0x71, ACPI_DISABLE=3D0x70, = S4BIOS_REQ=3D0x0 PSTATE_CNT=3D0x83 PM1a_EVT_BLK=3D0xd800-0xd803 PM1a_CNT_BLK=3D0xd804-0xd805 PM2_CNT_BLK=3D0xd820-0xd820 PM_TMR_BLK=3D0xd808-0xd80b GPE0_BLK=3D0xd828-0xd82f P_LVL2_LAT=3D32767 us, P_LVL3_LAT=3D32767 us FLUSH_SIZE=3D0, FLUSH_STRIDE=3D0 DUTY_OFFSET=3D1, DUTY_WIDTH=3D0 DAY_ALRM=3D13, MON_ALRM=3D126, CENTURY=3D0 IAPC_BOOT_ARCH=3D{LEGACY_DEVICES,8042} = Flags=3D{WBINVD,C1_SUPPORTED,SLEEP_BUTTON,S4_RTC_WAKE,RESET_REGISTER,PLATF= ORM_CLOCK} RESET_REG=3D0xb2:0[8] (IO), RESET_VALUE=3D0xfe */ /* FACS: Length=3D64, HwSig=3D0x00000000, Firm_Wake_Vec=3D0x00000000 Global_Lock=3D Flags=3D Version=3D0 */ /* DSDT: Length=3D20528, Revision=3D1, Checksum=3D198, OEMID=3DTOSHIB, OEM Table ID=3DA0044, OEM Revision=3D0x20060301, Creator ID=3DMSFT, Creator Revision=3D0x100000e */ /* SSDT: Length=3D774, Revision=3D1, Checksum=3D135, OEMID=3DTOSHIB, OEM Table ID=3DA0044, OEM Revision=3D0x20050926, Creator ID=3DMSFT, Creator Revision=3D0x100000e */ /* APIC: Length=3D104, Revision=3D1, Checksum=3D111, OEMID=3DTOSHIB, OEM Table ID=3D750, OEM Revision=3D0x970814, Creator ID=3DTASM, Creator Revision=3D0x4010000 Local APIC ADDR=3D0xfee00000 Flags=3D{PC-AT} Type=3DLocal APIC ACPI CPU=3D0 Flags=3D{ENABLED} APIC ID=3D0 Type=3DLocal APIC ACPI CPU=3D1 Flags=3D{ENABLED} APIC ID=3D1 Type=3DIO APIC APIC ID=3D1 INT BASE=3D0 ADDR=3D0x00000000fec00000 Type=3DINT Override BUS=3D0 IRQ=3D0 INTR=3D2 Flags=3D{Polarity=3Dconforming, Trigger=3Dconforming} Type=3DINT Override BUS=3D0 IRQ=3D9 INTR=3D9 Flags=3D{Polarity=3Dactive-hi, Trigger=3Dlevel} Type=3DLocal APIC NMI ACPI CPU=3D0 LINT Pin=3D1 Flags=3D{Polarity=3Dactive-hi, Trigger=3Dedge} Type=3DLocal APIC NMI ACPI CPU=3D1 LINT Pin=3D1 Flags=3D{Polarity=3Dactive-hi, Trigger=3Dedge} */ /* MCFG: Length=3D60, Revision=3D1, Checksum=3D133, OEMID=3DTOSHIB, OEM Table ID=3D750, OEM Revision=3D0x970814, Creator ID=3DTASM, Creator Revision=3D0x4010000 Base Address=3D0x00000000f0000000 Segment Group=3D0x0000 Start Bus=3D0 End Bus=3D63 */ /* HPET: Length=3D56, Revision=3D1, Checksum=3D173, OEMID=3DTOSHIB, OEM Table ID=3D750, OEM Revision=3D0x970814, Creator ID=3DTASM, Creator Revision=3D0x4010000 HPET Number=3D0 ADDR=3D0xfed00000:0[0] (Memory) HW Rev=3D0x1 Comparators=3D2 Counter Size=3D1 Legacy IRQ routing capable=3D{TRUE} PCI Vendor ID=3D0x8086 Minimal Tick=3D128 */ /* * Intel ACPI Component Architecture * AML Disassembler version 20100331 * * Disassembly of /tmp/acpidump.rmBW0a, Mon Nov 8 20:03:30 2010 * * * Original Table Header: * Signature "DSDT" * Length 0x00005312 (21266) * Revision 0x01 **** ACPI 1.0, no 64-bit math support * Checksum 0x7F * OEM ID "TOSHIB" * OEM Table ID "A0044 " * OEM Revision 0x20060301 (537264897) * Compiler ID "MSFT" * Compiler Version 0x0100000E (16777230) */ DefinitionBlock ("/tmp/acpidump.aml", "DSDT", 1, "TOSHIB", "A0044 ", = 0x20060301) { Name (\_S0, Package (0x04) { 0x00,=20 0x00,=20 0x00,=20 0x00 }) Name (\_S3, Package (0x04) { 0x05,=20 0x00,=20 0x00,=20 0x00 }) Name (\_S4, Package (0x04) { 0x06,=20 0x00,=20 0x00,=20 0x00 }) Name (\_S5, Package (0x04) { 0x07,=20 0x00,=20 0x00,=20 0x00 }) Scope (\_SB) { Name (PRS0, ResourceTemplate () { IRQ (Level, ActiveLow, Shared, ) {3,4,5,6,7,11} }) Device (LNKA) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x01) Method (_STA, 0, NotSerialized) { Return (STAL (\_SB.PCI0.FNC0.IRQA)) } Name (_PRS, ResourceTemplate () { IRQ (Level, ActiveLow, Shared, ) {10} }) Method (_CRS, 0, NotSerialized) { Return (CRSL (\_SB.PCI0.FNC0.IRQA)) } Method (_DIS, 0, NotSerialized) { Store (0x80, \_SB.PCI0.FNC0.IRQA) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x01, IRQX) FindSetRightBit (IRQX, Local0) Decrement (Local0) Store (Local0, \_SB.PCI0.FNC0.IRQA) } } Device (LNKB) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x02) Method (_STA, 0, NotSerialized) { Return (STAL (\_SB.PCI0.FNC0.IRQB)) } Method (_PRS, 0, NotSerialized) { Return (PRS0) } Method (_CRS, 0, NotSerialized) { Return (CRSL (\_SB.PCI0.FNC0.IRQB)) } Method (_DIS, 0, NotSerialized) { Store (0x80, \_SB.PCI0.FNC0.IRQB) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x01, IRQX) FindSetRightBit (IRQX, Local0) Decrement (Local0) Store (Local0, \_SB.PCI0.FNC0.IRQB) } } Device (LNKC) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x03) Method (_STA, 0, NotSerialized) { Return (STAL (\_SB.PCI0.FNC0.IRQC)) } Method (_PRS, 0, NotSerialized) { Return (PRS0) } Method (_CRS, 0, NotSerialized) { Return (CRSL (\_SB.PCI0.FNC0.IRQC)) } Method (_DIS, 0, NotSerialized) { Store (0x80, \_SB.PCI0.FNC0.IRQC) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x01, IRQX) FindSetRightBit (IRQX, Local0) Decrement (Local0) Store (Local0, \_SB.PCI0.FNC0.IRQC) } } Device (LNKD) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x04) Method (_STA, 0, NotSerialized) { Return (STAL (\_SB.PCI0.FNC0.IRQD)) } Method (_PRS, 0, NotSerialized) { Return (PRS0) } Method (_CRS, 0, NotSerialized) { Return (CRSL (\_SB.PCI0.FNC0.IRQD)) } Method (_DIS, 0, NotSerialized) { Store (0x80, \_SB.PCI0.FNC0.IRQD) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x01, IRQX) FindSetRightBit (IRQX, Local0) Decrement (Local0) Store (Local0, \_SB.PCI0.FNC0.IRQD) } } Device (LNKE) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x05) Method (_STA, 0, NotSerialized) { Return (STAL (\_SB.PCI0.FNC0.IRQE)) } Method (_PRS, 0, NotSerialized) { Return (PRS0) } Method (_CRS, 0, NotSerialized) { Return (CRSL (\_SB.PCI0.FNC0.IRQE)) } Method (_DIS, 0, NotSerialized) { Store (0x80, \_SB.PCI0.FNC0.IRQE) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x01, IRQX) FindSetRightBit (IRQX, Local0) Decrement (Local0) Store (Local0, \_SB.PCI0.FNC0.IRQE) } } Device (LNKF) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x06) Method (_STA, 0, NotSerialized) { Return (STAL (\_SB.PCI0.FNC0.IRQF)) } Method (_PRS, 0, NotSerialized) { Return (PRS0) } Method (_CRS, 0, NotSerialized) { Return (CRSL (\_SB.PCI0.FNC0.IRQF)) } Method (_DIS, 0, NotSerialized) { Store (0x80, \_SB.PCI0.FNC0.IRQF) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x01, IRQX) FindSetRightBit (IRQX, Local0) Decrement (Local0) Store (Local0, \_SB.PCI0.FNC0.IRQF) } } Device (LNKG) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x07) Method (_STA, 0, NotSerialized) { Return (STAL (\_SB.PCI0.FNC0.IRQG)) } Method (_PRS, 0, NotSerialized) { Return (PRS0) } Method (_CRS, 0, NotSerialized) { Return (CRSL (\_SB.PCI0.FNC0.IRQG)) } Method (_DIS, 0, NotSerialized) { Store (0x80, \_SB.PCI0.FNC0.IRQG) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x01, IRQX) FindSetRightBit (IRQX, Local0) Decrement (Local0) Store (Local0, \_SB.PCI0.FNC0.IRQG) } } Device (LNKH) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x08) Method (_STA, 0, NotSerialized) { Return (STAL (\_SB.PCI0.FNC0.IRQH)) } Method (_PRS, 0, NotSerialized) { Return (PRS0) } Method (_CRS, 0, NotSerialized) { Return (CRSL (\_SB.PCI0.FNC0.IRQH)) } Method (_DIS, 0, NotSerialized) { Store (0x80, \_SB.PCI0.FNC0.IRQH) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x01, IRQX) FindSetRightBit (IRQX, Local0) Decrement (Local0) Store (Local0, \_SB.PCI0.FNC0.IRQH) } } Device (MEM) { Name (_HID, EisaId ("PNP0C01")) Name (_STA, 0x0F) Method (_CRS, 0, NotSerialized) { Return (CRS (0x01)) } OperationRegion (SRAM, SystemMemory, 0x000EE800, 0x1800) Field (SRAM, AnyAcc, NoLock, Preserve) { PAR1, 16,=20 PAR2, 16,=20 PAR3, 16,=20 PAR4, 16,=20 PAR5, 16,=20 PAR6, 16 } Field (SRAM, AnyAcc, NoLock, Preserve) { Offset (0x02),=20 RDID, 32,=20 RDSN, 32,=20 CAPB, 16 } Field (SRAM, AnyAcc, NoLock, Preserve) { IEAX, 32,=20 IEBX, 32,=20 IECX, 32,=20 IEDX, 32,=20 IESI, 32,=20 IEDI, 32,=20 IEBP, 32,=20 Offset (0x20),=20 OEAX, 32,=20 OEBX, 32,=20 OECX, 32,=20 OEDX, 32,=20 OESI, 32,=20 OEDI, 32,=20 OEBP, 32,=20 Offset (0xFF),=20 ACST, 1,=20 BES1, 1,=20 BES2, 1,=20 , 4,=20 AACS, 1,=20 BMN1, 104,=20 BSN1, 88,=20 BTP1, 72,=20 BPU1, 32,=20 BDC1, 32,=20 BLF1, 32,=20 BTC1, 32,=20 BDV1, 32,=20 BST1, 32,=20 BPR1, 32,=20 BRC1, 32,=20 BPV1, 32,=20 Offset (0x149),=20 BCW1, 32,=20 BCL1, 32,=20 BG11, 32,=20 BG21, 32,=20 BOI1, 8,=20 BRF1, 1,=20 Offset (0x200),=20 BMN2, 104,=20 BSN2, 88,=20 BTP2, 72,=20 BPU2, 32,=20 BDC2, 32,=20 BLF2, 32,=20 BTC2, 32,=20 BDV2, 32,=20 BST2, 32,=20 BPR2, 32,=20 BRC2, 32,=20 BPV2, 32,=20 Offset (0x249),=20 BCW2, 32,=20 BCL2, 32,=20 BG12, 32,=20 BG22, 32,=20 BOI2, 32,=20 Offset (0x300),=20 AC01, 16,=20 AC11, 16,=20 PSV1, 16,=20 CRT1, 16,=20 TMP1, 16,=20 AST1, 16,=20 AC21, 16,=20 AC31, 16,=20 AC02, 16,=20 AC12, 16,=20 PSV2, 16,=20 CRT2, 16,=20 TMP2, 16,=20 AST2, 16,=20 AC22, 16,=20 AC32, 16,=20 AC03, 16,=20 AC13, 16,=20 PSV3, 16,=20 CRT3, 16,=20 TMP3, 16,=20 AST3, 16,=20 AC23, 16,=20 AC33, 16,=20 Offset (0x340),=20 TMPF, 16,=20 Offset (0x3F0),=20 FANH, 1,=20 FANL, 7,=20 TF11, 1,=20 TF21, 1,=20 TF31, 1,=20 , 1,=20 TF10, 1,=20 TF20, 1,=20 TF30, 1,=20 Offset (0x3F2),=20 TP11, 1,=20 TP21, 1,=20 TP31, 1,=20 Offset (0x400),=20 GP50, 1,=20 GP51, 1,=20 GP52, 1,=20 GP53, 1,=20 GP54, 1,=20 GP55, 1,=20 GP56, 1,=20 GP57, 1,=20 GP60, 1,=20 GP61, 1,=20 GP62, 1,=20 GP63, 1,=20 GP64, 1,=20 GP65, 1,=20 GP66, 1,=20 GP67, 1,=20 GP70, 1,=20 GP71, 1,=20 GP72, 1,=20 GP73, 1,=20 GP74, 1,=20 GP75, 1,=20 GP76, 1,=20 GP77, 1,=20 WED0, 1,=20 WED1, 1,=20 WED2, 1,=20 WED3, 1,=20 WED4, 1,=20 Offset (0x404),=20 SBL0, 1,=20 SBL1, 1,=20 SBL2, 1,=20 SBL3, 1,=20 Offset (0x405),=20 LIDS, 1,=20 VALF, 1,=20 DCST, 1,=20 DOS2, 1,=20 DCKI, 1,=20 DCKF, 1,=20 BT1F, 1,=20 BT2F, 1,=20 NXLA, 1,=20 NXCA, 1,=20 NXTA, 1,=20 NXDA, 1,=20 CTLA, 1,=20 CTCA, 1,=20 CTTA, 1,=20 CTDA, 1,=20 LANA, 1,=20 PNLS, 1,=20 B1ST, 1,=20 B2ST, 1,=20 Offset (0x483),=20 GCVS, 8,=20 Offset (0x486),=20 DDS0, 8,=20 Offset (0x4C0),=20 PSS0, 16,=20 PSS1, 16,=20 Offset (0x4D0),=20 SYU0, 1,=20 SYU1, 1,=20 SYU2, 1,=20 SYU3, 1,=20 SYU4, 1,=20 WAKS, 1,=20 SYU6, 1,=20 SYU7, 1,=20 RPPC, 1,=20 DNTF, 1,=20 DCKU, 1,=20 DCKD, 1,=20 Offset (0x500),=20 HKCD, 8,=20 Offset (0x502),=20 DLID, 32,=20 DSRN, 32,=20 Offset (0x50E),=20 BDID, 32,=20 DSPW, 1,=20 VGAF, 1,=20 VWE0, 1,=20 VWE1, 1,=20 PPSC, 1,=20 SPSC, 1,=20 EWLD, 1,=20 EPWS, 1,=20 LCDS, 4,=20 CRTS, 4,=20 VWE2, 1,=20 WEF0, 1,=20 WEF1, 1,=20 WED5, 1,=20 ECWE, 1,=20 MEWE, 1,=20 Offset (0x515),=20 BTMD, 1,=20 WSF0, 1,=20 WSF1, 1,=20 GP83, 1,=20 ECWS, 1,=20 , 1,=20 BPFE, 1,=20 BWUE, 1,=20 DVIS, 4,=20 Offset (0x517),=20 HTM0, 1,=20 HTM1, 1,=20 HTS0, 1,=20 , 1,=20 I1EJ, 1,=20 Offset (0x518),=20 PSND, 1,=20 PMDM, 1,=20 Offset (0x520),=20 VGAR, 1,=20 KBCR, 1,=20 ID0R, 1,=20 ID1R, 1,=20 ID2R, 1,=20 ID3R, 1,=20 IDAR, 1,=20 ACLR, 1,=20 BTRE, 1,=20 ACVA, 1,=20 Offset (0x522),=20 GP90, 1,=20 GP91, 1,=20 GP92, 1,=20 GP93, 1,=20 GP94, 1,=20 GP95, 1,=20 GP96, 1,=20 Offset (0x523),=20 HTTE, 1,=20 CPED, 1,=20 Offset (0x524),=20 EXHS, 1,=20 EXUP, 1,=20 Offset (0x525),=20 DSB0, 1,=20 DSB1, 1,=20 DSB2, 1,=20 Offset (0x526),=20 CFGD, 16,=20 Offset (0x6C0),=20 BDCS, 1,=20 Offset (0x6C1),=20 BWE0, 1,=20 BWE1, 1,=20 BWE2, 1,=20 BWE3, 1,=20 BWE4, 1,=20 BWE5, 1,=20 BWF0, 1,=20 BWF1, 1,=20 BCDD, 4,=20 Offset (0x701),=20 HAPS, 2,=20 HHSW, 2,=20 HPSU, 2,=20 HRCU, 2,=20 HGSU, 2,=20 HEBI, 2,=20 HTMD, 2,=20 Offset (0x703),=20 HKRD, 2,=20 HVBS, 2,=20 Offset (0x707),=20 MINF, 8,=20 TNVS, 1,=20 OSPC, 1,=20 ACBK, 1,=20 LBAT, 1,=20 LANB, 1,=20 PICM, 1,=20 Offset (0x709),=20 BTNE, 8,=20 PULD, 8,=20 PULA, 8,=20 BCLD, 8,=20 BCLA, 8,=20 Offset (0x710),=20 OSID, 8,=20 SVPN, 1,=20 Offset (0x712),=20 SLPE, 1,=20 Offset (0x720),=20 MSSI, 16,=20 MSSS, 8,=20 MSSR, 8,=20 MSP0, 8,=20 MSC0, 8,=20 MSP1, 8,=20 MSC1, 8,=20 Offset (0x740),=20 Offset (0x800),=20 PRES, 32768 } Field (SRAM, AnyAcc, NoLock, Preserve) { Offset (0x406),=20 NXDD, 4,=20 CTDD, 4 } Field (SRAM, AnyAcc, NoLock, Preserve) { Offset (0x800),=20 Offset (0x808),=20 Offset (0x812),=20 Offset (0x814),=20 Offset (0x818),=20 FSDP, 8,=20 Offset (0x823),=20 Offset (0x826),=20 Offset (0x836),=20 Offset (0x87E),=20 Offset (0x87F),=20 EDCK, 8 } } Device (EXPL) { Name (_HID, EisaId ("PNP0C02")) Name (_STA, 0x0F) Method (_CRS, 0, NotSerialized) { Return (CRS (0x30)) } } Device (PCI0) { Name (_HID, EisaId ("PNP0A08")) Name (_CID, EisaId ("PNP0A03")) Name (_ADR, 0x00) Method (_CRS, 0, NotSerialized) { Name (CRBF, ResourceTemplate () { WordBusNumber (ResourceProducer, MinFixed, MaxFixed, = PosDecode, 0x0000, // Granularity 0x0000, // Range Minimum 0x00FF, // Range Maximum 0x0000, // Translation Offset 0x0100, // Length ,, ) IO (Decode16, 0x0CF8, // Range Minimum 0x0CF8, // Range Maximum 0x01, // Alignment 0x08, // Length ) WordIO (ResourceProducer, MinFixed, MaxFixed, = PosDecode, EntireRange, 0x0000, // Granularity 0x0000, // Range Minimum 0x0CF7, // Range Maximum 0x0000, // Translation Offset 0x0CF8, // Length ,, , TypeStatic) WordIO (ResourceProducer, MinFixed, MaxFixed, = PosDecode, EntireRange, 0x0000, // Granularity 0x0D00, // Range Minimum 0xFFFF, // Range Maximum 0x0000, // Translation Offset 0xF300, // Length ,, , TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, = MaxFixed, NonCacheable, ReadWrite, 0x00000000, // Granularity 0x000A0000, // Range Minimum 0x000BFFFF, // Range Maximum 0x00000000, // Translation Offset 0x00020000, // Length ,, , AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, = MaxFixed, NonCacheable, ReadWrite, 0x00000000, // Granularity 0x000D0000, // Range Minimum 0x000DFFFF, // Range Maximum 0x00000000, // Translation Offset 0x00010000, // Length ,, _Y00, AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, = MaxFixed, NonCacheable, ReadWrite, 0x00000000, // Granularity 0xD0000000, // Range Minimum 0xEFFFFFFF, // Range Maximum 0x00000000, // Translation Offset 0x20000000, // Length ,, , AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, = MaxFixed, NonCacheable, ReadWrite, 0x00000000, // Granularity 0xF4000000, // Range Minimum 0xFEBFFFFF, // Range Maximum 0x00000000, // Translation Offset 0x0AC00000, // Length ,, , AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, = MaxFixed, NonCacheable, ReadWrite, 0x00000000, // Granularity 0xFEC18000, // Range Minimum 0xFEC1FFFF, // Range Maximum 0x00000000, // Translation Offset 0x00008000, // Length ,, , AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, = MaxFixed, NonCacheable, ReadWrite, 0x00000000, // Granularity 0xFEC28000, // Range Minimum 0xFECFFFFF, // Range Maximum 0x00000000, // Translation Offset 0x000D8000, // Length ,, , AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, = MaxFixed, NonCacheable, ReadWrite, 0x00000000, // Granularity 0xFED00400, // Range Minimum 0xFED13FFF, // Range Maximum 0x00000000, // Translation Offset 0x00013C00, // Length ,, , AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, = MaxFixed, NonCacheable, ReadWrite, 0x00000000, // Granularity 0xFED1A000, // Range Minimum 0xFED1BFFF, // Range Maximum 0x00000000, // Translation Offset 0x00002000, // Length ,, , AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, = MaxFixed, NonCacheable, ReadWrite, 0x00000000, // Granularity 0xFED40000, // Range Minimum 0xFED44FFF, // Range Maximum 0x00000000, // Translation Offset 0x00005000, // Length ,, , AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, = MaxFixed, NonCacheable, ReadWrite, 0x00000000, // Granularity 0xFED90000, // Range Minimum 0xFED9FFFF, // Range Maximum 0x00000000, // Translation Offset 0x00010000, // Length ,, , AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, = MaxFixed, NonCacheable, ReadWrite, 0x00000000, // Granularity 0xFEDC0000, // Range Minimum 0xFEDFFFFF, // Range Maximum 0x00000000, // Translation Offset 0x00040000, // Length ,, , AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, = MaxFixed, NonCacheable, ReadWrite, 0x00000000, // Granularity 0xFEE01000, // Range Minimum 0xFFAFFFFF, // Range Maximum 0x00000000, // Translation Offset 0x00CFF000, // Length ,, , AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, = MaxFixed, NonCacheable, ReadWrite, 0x00000000, // Granularity 0xFFC00000, // Range Minimum 0xFFDFFFFF, // Range Maximum 0x00000000, // Translation Offset 0x00200000, // Length ,, , AddressRangeMemory, TypeStatic) }) CreateDWordField (CRBF, \_SB.PCI0._CRS._Y00._MIN, EMMS) CreateDWordField (CRBF, \_SB.PCI0._CRS._Y00._LEN, EMME) If (\_SB.MEM.LANB) { Store (0x000D4000, EMMS) Store (0xC000, EMME) } Return (CRBF) } Method (_PRT, 0, NotSerialized) { If (LEqual (\_SB.MEM.PICM, 0x01)) { Return (APB0) } Else { Return (PB00) } } Device (PCIB) { Name (_ADR, 0x001E0000) OperationRegion (ICHB, PCI_Config, 0x00, 0xFF) Field (ICHB, ByteAcc, NoLock, Preserve) { Offset (0x19),=20 BRGB, 8 } Method (_PRT, 0, NotSerialized) { If (LEqual (\_SB.MEM.PICM, 0x01)) { Return (APB1) } Else { Return (PB01) } } Device (LAN) { Name (_ADR, 0x00080000) Name (_PRW, Package (0x02) { 0x0B,=20 0x04 }) Method (_PSW, 1, NotSerialized) { If (Arg0) { Store (0x01, \_SB.MEM.WED5) } Else { Store (0x00, \_SB.MEM.WED5) } } } Device (CRD0) { Name (_ADR, 0x000B0000) Name (_SUN, 0x00) } Device (SDC) { Name (_ADR, 0x000B0003) } Device (IEEE) { Name (_ADR, 0x000B0001) } } Device (FNC0) { Name (_ADR, 0x001F0000) OperationRegion (ICH3, PCI_Config, 0x00, 0xFF) Field (ICH3, ByteAcc, NoLock, Preserve) { Offset (0x60),=20 IRQA, 8,=20 IRQB, 8,=20 IRQC, 8,=20 IRQD, 8,=20 Offset (0x68),=20 IRQE, 8,=20 IRQF, 8,=20 IRQG, 8,=20 IRQH, 8 } Device (DMAC) { Name (_HID, EisaId ("PNP0200")) Name (_STA, 0x0F) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0000, // Range Minimum 0x0000, // Range Maximum 0x01, // Alignment 0x10, // Length ) IO (Decode16, 0x0081, // Range Minimum 0x0081, // Range Maximum 0x01, // Alignment 0x03, // Length ) IO (Decode16, 0x0087, // Range Minimum 0x0087, // Range Maximum 0x01, // Alignment 0x01, // Length ) IO (Decode16, 0x0089, // Range Minimum 0x0089, // Range Maximum 0x01, // Alignment 0x03, // Length ) IO (Decode16, 0x008F, // Range Minimum 0x008F, // Range Maximum 0x01, // Alignment 0x01, // Length ) IO (Decode16, 0x00C0, // Range Minimum 0x00C0, // Range Maximum 0x01, // Alignment 0x20, // Length ) DMA (Compatibility, NotBusMaster, Transfer8, ) {4} }) } Device (PIC) { Name (_HID, EisaId ("PNP0000")) Name (_STA, 0x0F) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0020, // Range Minimum 0x0020, // Range Maximum 0x01, // Alignment 0x02, // Length ) IO (Decode16, 0x00A0, // Range Minimum 0x00A0, // Range Maximum 0x01, // Alignment 0x02, // Length ) IRQ (Edge, ActiveHigh, Exclusive, ) {2} }) } Device (PIT) { Name (_HID, EisaId ("PNP0100")) Name (_STA, 0x0F) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0040, // Range Minimum 0x0040, // Range Maximum 0x01, // Alignment 0x04, // Length ) IRQ (Edge, ActiveHigh, Exclusive, ) {0} }) } Device (SPKR) { Name (_HID, EisaId ("PNP0800")) Name (_STA, 0x0F) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0061, // Range Minimum 0x0061, // Range Maximum 0x01, // Alignment 0x01, // Length ) }) } Device (NDP) { Name (_HID, EisaId ("PNP0C04")) Name (_STA, 0x0F) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x00F0, // Range Minimum 0x00F0, // Range Maximum 0x01, // Alignment 0x10, // Length ) IRQ (Edge, ActiveHigh, Exclusive, ) {13} }) } Device (KBC) { Name (_HID, EisaId ("PNP0303")) Method (_STA, 0, NotSerialized) { While (LEqual (\_SB.MEM.KBCR, 0x00)) {} Return (0x0F) } Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0060, // Range Minimum 0x0060, // Range Maximum 0x01, // Alignment 0x01, // Length ) IO (Decode16, 0x0064, // Range Minimum 0x0064, // Range Maximum 0x01, // Alignment 0x01, // Length ) IRQ (Edge, ActiveHigh, Exclusive, ) {1} }) } Device (PS2M) { Name (_HID, EisaId ("PNP0F13")) Method (_STA, 0, NotSerialized) { While (LEqual (\_SB.MEM.KBCR, 0x00)) {} Return (0x0F) } Name (_CRS, ResourceTemplate () { IRQ (Edge, ActiveHigh, Exclusive, ) {12} }) } Device (RTC) { Name (_HID, EisaId ("PNP0B00")) Name (_STA, 0x0F) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0070, // Range Minimum 0x0070, // Range Maximum 0x01, // Alignment 0x02, // Length ) IRQ (Edge, ActiveHigh, Exclusive, ) {8} }) } Device (SYSR) { Name (_HID, EisaId ("PNP0C02")) Name (_STA, 0x0F) Method (_CRS, 0, NotSerialized) { Return (CRS (0x0A)) } OperationRegion (SRG1, SystemIO, 0xB2, 0x01) Field (SRG1, ByteAcc, NoLock, Preserve) { TRP4, 8 } OperationRegion (PMIO, SystemIO, 0xD800, 0x40) Field (PMIO, ByteAcc, NoLock, Preserve) { Offset (0x28),=20 , 9,=20 PEXS, 1 } OperationRegion (GPIO, SystemIO, 0xEEC0, 0x40) Field (GPIO, ByteAcc, NoLock, Preserve) { Offset (0x0C),=20 GPLV, 32 } } Device (TPM) { Name (_HID, EisaId ("IFX0102")) Name (_CID, EisaId ("PNP0C31")) Method (_STA, 0, NotSerialized) { Return (STA (0x17)) } Method (_CRS, 0, NotSerialized) { Return (CRS (0x17)) } } Device (HPET) { Name (_HID, EisaId ("PNP0103")) Name (_STA, 0x0F) Name (BUF0, ResourceTemplate () { Memory32Fixed (ReadOnly, 0xFED00000, // Address Base 0x00000400, // Address Length ) }) Method (_CRS, 0, NotSerialized) { Return (BUF0) } } } Device (FNC2) { Name (_ADR, 0x001F0002) OperationRegion (IDEC, PCI_Config, 0x00, 0xFF) Field (IDEC, ByteAcc, NoLock, Preserve) { Offset (0x08),=20 RVID, 8,=20 Offset (0x40),=20 PRTE, 8,=20 PRTM, 8,=20 SRTE, 8,=20 SRTM, 8,=20 PSTM, 4,=20 SSTM, 4,=20 Offset (0x48),=20 PUDM, 1,=20 PSUM, 1,=20 SUDM, 1,=20 SSUM, 1,=20 Offset (0x4A),=20 PUDC, 2,=20 , 2,=20 PSUC, 2,=20 Offset (0x4B),=20 SUDC, 2,=20 , 2,=20 SSUC, 2,=20 Offset (0x54),=20 PCB0, 1,=20 PCB1, 1,=20 SCB0, 1,=20 SCB1, 1,=20 PCS0, 1,=20 PCS1, 1,=20 SCS0, 1,=20 SCS1, 1,=20 , 4,=20 FPC0, 1,=20 FPC1, 1,=20 FSC0, 1,=20 FSC1, 1 } Field (IDEC, ByteAcc, NoLock, Preserve) { Offset (0x54),=20 , 4,=20 CSTS, 4 } Device (IDE0) { Name (_ADR, 0x00) Method (_STA, 0, NotSerialized) { Return (0x0F) } Method (_PS0, 0, NotSerialized) { Store (0x00, \_SB.MEM.PPSC) } Method (_PS3, 0, NotSerialized) { Store (0x01, \_SB.MEM.PPSC) } Method (_PSC, 0, NotSerialized) { If (\_SB.MEM.PPSC) { Return (0x03) } Else { Return (0x00) } } Method (_STM, 3, NotSerialized) { While (LEqual (\_SB.MEM.ID0R, 0x00)) {} Store (0x01, \_SB.MEM.HTM0) CreateDWordField (Arg0, 0x00, PPIO) CreateDWordField (Arg0, 0x04, PDMA) CreateDWordField (Arg0, 0x10, PFLG) Store (PPIO, Local1) Store (PDMA, Local2) Store (PFLG, Local3) Store (0x80, Local4) Store (0x00, Local7) If (LLessEqual (Local1, 0x78)) { Store (0xA3, Local4) Store (0x03, Local7) } Else { If (LLessEqual (Local1, 0xB4)) { Store (0xA1, Local4) Store (0x03, Local7) } Else { If (LLessEqual (Local1, 0xF0)) { Store (0x90, Local4) Store (0x01, Local7) } } } Store (Local4, PRTM) Store (0x00, Local4) Store (0x00, Local5) Store (0x00, Local6) Store (0x00, Local1) And (Local3, 0x01, Local3) Store (Local3, PUDM) If (LEqual (Local3, 0x01)) { Store (0x07, Local7) Store (0x01, Local1) If (LLessEqual (Local2, 0x14)) { Store (0x01, Local6) Store (0x01, Local4) } Else { If (LLessEqual (Local2, 0x1E)) { Store (0x02, Local4) Store (0x01, Local5) } Else { If (LLessEqual (Local2, 0x3C)) { Store (0x02, Local4) } Else { If (LLessEqual (Local2, 0x5A)) { Store (0x01, Local4) } } } } } Store (Local4, PUDC) Store (Local5, PCB0) Store (Local6, FPC0) Store (Local7, PRTE) Store (Local1, PCS0) } Method (_GTM, 0, NotSerialized) { While (LEqual (\_SB.MEM.ID0R, 0x00)) {} Store (0x01, \_SB.MEM.HTM0) Store (PRTM, Local0) Store (0xFA, Local2) If (LEqual (Local0, 0xA3)) { Store (0x78, Local2) } Else { If (LEqual (Local0, 0xA1)) { Store (0xB4, Local2) } Else { If (LEqual (Local0, 0x90)) { Store (0xF0, Local2) } } } Store (PUDC, Local1) Store (0x02, Local4) If (LEqual (PUDM, 0x01)) { Store (0x03, Local4) If (LEqual (FPC0, 0x01)) { Store (0x14, Local3) } Else { If (LEqual (PCB0, 0x01)) { Store (0x1E, Local3) } Else { Store (0x78, Local3) If (LEqual (Local1, 0x01)) { Store (0x5A, Local3) } Else { If (LEqual (Local1, 0x02)) { Store (0x3C, Local3) } } } } } Else { Store (0xB4, Local3) If (LEqual (Local0, 0xA3)) { Store (0x78, Local3) } } Name (BUFF, Buffer (0x14) {}) CreateDWordField (BUFF, 0x00, PIO1) CreateDWordField (BUFF, 0x04, DMA1) CreateDWordField (BUFF, 0x08, PIO2) CreateDWordField (BUFF, 0x0C, DMA2) CreateDWordField (BUFF, 0x10, FLGS) Store (Local2, PIO1) Store (Local3, DMA1) Store (0xFFFFFFFF, PIO2) Store (0xFFFFFFFF, DMA2) Store (Local4, FLGS) Return (BUFF) } Device (HD_0) { Name (_ADR, 0x00) Method (_GTF, 0, NotSerialized) { While (LEqual (\_SB.MEM.ID0R, 0x00)) {} Store (0x01, \_SB.MEM.HTM0) Name (BUFF, Buffer (0x0E) { /* 0000 */ 0x03, 0x0C, 0x00, 0x00, = 0x00, 0x00, 0xEF, 0x03,=20 /* 0008 */ 0x23, 0x00, 0x00, 0x00, = 0x00, 0xEF }) CreateByteField (BUFF, 0x01, PIOM) CreateByteField (BUFF, 0x08, DMAM) Store (PRTM, Local0) Store (0x08, Local1) If (LEqual (Local0, 0xA3)) { Store (0x0C, Local1) } Else { If (LEqual (Local0, 0xA1)) { Store (0x0B, Local1) } Else { If (LEqual (Local0, 0x90)) { Store (0x0A, Local1) } } } Store (PUDM, Local2) If (LEqual (Local2, 0x01)) { Store (PUDC, Local4) If (LEqual (FPC0, 0x01)) { Store (0x45, Local3) } Else { If (LEqual (PCB0, 0x01)) { Store (0x44, Local3) } Else { Store (0x40, Local3) If (LEqual (Local4, 0x01)) { Store (0x41, Local3) } Else { If (LEqual (Local4, 0x02)) { Store (0x42, Local3) } } } } } Else { Store (0x21, Local3) If (LEqual (Local0, 0xA3)) { Store (0x22, Local3) } } Store (Local1, PIOM) Store (Local3, DMAM) Return (BUFF) } } } Device (IDE1) { Name (_ADR, 0x01) Method (_PS0, 0, NotSerialized) { While (LEqual (\_SB.MEM.ID1R, 0x00)) {} SMBR (0xFE00, 0x14, 0x00, 0x00, 0xB2) And (\_SB.MEM.OECX, 0x02, Local0) If (Local0) { Store (0x00, \_SB.MEM.SPSC) Store (0x01, \_SB.MEM.IESI) Store (0x02, \_SB.MEM.IEDI) SMBR (0xFE00, 0x23, 0xFA, 0x00, 0xB2) If (\_SB.MEM.OEDX) { Store (0x01, \_SB.MEM.IESI) Store (0x02, \_SB.MEM.IEDI) SMBR (0xFF00, 0x23, 0xFA, 0x00, 0xB2) Store (0x01, \_SB.MEM.OECX) While (\_SB.MEM.OECX) { Store (0x01, \_SB.MEM.IESI) Store (0x02, \_SB.MEM.IEDI) SMBR (0xFE00, 0x23, 0xFA, 0x00, = 0xB2) } } } } Method (_PS3, 0, NotSerialized) { While (LEqual (\_SB.MEM.ID1R, 0x00)) {} SMBR (0xFE00, 0x14, 0x00, 0x00, 0xB2) And (\_SB.MEM.OECX, 0x02, Local0) If (Local0) { Store (0x01, \_SB.MEM.SPSC) } } Method (_PSC, 0, NotSerialized) { While (LEqual (\_SB.MEM.ID1R, 0x00)) {} SMBR (0xFE00, 0x14, 0x00, 0x00, 0xB2) And (\_SB.MEM.OECX, 0x02, Local0) If (Local0) { If (\_SB.MEM.SPSC) { Return (0x03) } Else { Return (0x00) } } Else { Return (0x00) } } Method (_STM, 3, NotSerialized) { While (LEqual (\_SB.MEM.ID1R, 0x00)) {} SMBR (0xFE00, 0x14, 0x00, 0x00, 0xB2) And (\_SB.MEM.OECX, 0x02, Local0) If (Local0) { Store (0x01, \_SB.MEM.HTM1) CreateDWordField (Arg0, 0x00, PPIO) CreateDWordField (Arg0, 0x04, PDMA) CreateDWordField (Arg0, 0x10, PFLG) Store (PPIO, Local1) Store (PDMA, Local2) Store (PFLG, Local3) Store (0x80, Local4) Store (0x00, Local7) If (LLessEqual (Local1, 0x78)) { Store (0xA3, Local4) Store (0x03, Local7) } Else { If (LLessEqual (Local1, 0xB4)) { Store (0xA1, Local4) Store (0x03, Local7) } Else { If (LLessEqual (Local1, 0xF0)) { Store (0x90, Local4) Store (0x01, Local7) } } } Store (Local4, SRTM) Store (0x00, Local4) Store (0x00, Local5) Store (0x00, Local6) Store (0x00, Local1) And (Local3, 0x01, Local3) Store (Local3, SUDM) If (LEqual (Local3, 0x01)) { Store (0x07, Local7) Store (0x01, Local1) If (LLessEqual (Local2, 0x14)) { Store (0x01, Local6) Store (0x01, Local4) } Else { If (LLessEqual (Local2, 0x1E)) { Store (0x02, Local4) Store (0x01, Local5) } Else { If (LLessEqual (Local2, 0x3C)) { Store (0x02, Local4) } Else { If (LLessEqual (Local2, = 0x5A)) { Store (0x01, Local4) } } } } } Store (Local4, SUDC) Store (Local5, SCB0) Store (Local6, FSC0) Store (Local7, SRTE) Store (Local1, SCS0) } } Method (_GTM, 0, NotSerialized) { While (LEqual (\_SB.MEM.ID1R, 0x00)) {} Store (0x01, \_SB.MEM.HTM1) Store (SRTM, Local0) Store (0xFA, Local2) If (LEqual (Local0, 0xA3)) { Store (0x78, Local2) } Else { If (LEqual (Local0, 0xA1)) { Store (0xB4, Local2) } Else { If (LEqual (Local0, 0x90)) { Store (0xF0, Local2) } } } Store (SUDC, Local1) Store (0x02, Local4) If (LEqual (SUDM, 0x01)) { Store (0x03, Local4) If (LEqual (FSC0, 0x01)) { Store (0x14, Local3) } Else { If (LEqual (SCB0, 0x01)) { Store (0x1E, Local3) } Else { Store (0x78, Local3) If (LEqual (Local1, 0x01)) { Store (0x5A, Local3) } Else { If (LEqual (Local1, 0x02)) { Store (0x3C, Local3) } } } } } Else { Store (0xB4, Local3) If (LEqual (Local0, 0xA3)) { Store (0x78, Local3) } } Name (BUFF, Buffer (0x14) {}) CreateDWordField (BUFF, 0x00, PIO1) CreateDWordField (BUFF, 0x04, DMA1) CreateDWordField (BUFF, 0x08, PIO2) CreateDWordField (BUFF, 0x0C, DMA2) CreateDWordField (BUFF, 0x10, FLGS) Store (Local2, PIO1) Store (Local3, DMA1) Store (0xFFFFFFFF, PIO2) Store (0xFFFFFFFF, DMA2) Store (Local4, FLGS) Return (BUFF) } Device (ODD1) { Name (_ADR, 0x00) Method (_STA, 0, NotSerialized) { While (LEqual (\_SB.MEM.ID1R, 0x00)) {} SMBR (0xFE00, 0x14, 0x00, 0x00, 0xB2) And (\_SB.MEM.OECX, 0x02, Local0) If (Local0) { Return (0x0F) } Else { Return (0x00) } } Method (_EJ0, 1, NotSerialized) { Store (0x01, \_SB.MEM.I1EJ) SMBR (0xFE00, 0x14, 0x00, 0x00, 0xB2) And (\_SB.MEM.OECX, 0x02, Local0) If (Local0) { Store (0x01, \_SB.MEM.IESI) Store (0x02, \_SB.MEM.IEDI) SMBR (0xFE00, 0x23, 0xFA, 0x00, 0xB2) If (LNotEqual (\_SB.MEM.OEDX, 0x03)) { Store (0x01, \_SB.MEM.IESI) Store (0x02, \_SB.MEM.IEDI) SMBR (0xFF00, 0x23, 0xFA, 0x03, = 0xB2) Store (0x01, \_SB.MEM.OECX) While (\_SB.MEM.OECX) { Store (0x01, \_SB.MEM.IESI) Store (0x02, \_SB.MEM.IEDI) SMBR (0xFE00, 0x23, 0xFA, 0x00, = 0xB2) } } } } Method (_GTF, 0, NotSerialized) { While (LEqual (\_SB.MEM.ID1R, 0x00)) {} Store (0x01, \_SB.MEM.HTM1) Name (BUFF, Buffer (0x0E) { /* 0000 */ 0x03, 0x0C, 0x00, 0x00, = 0x00, 0x00, 0xEF, 0x03,=20 /* 0008 */ 0x23, 0x00, 0x00, 0x00, = 0x00, 0xEF }) CreateByteField (BUFF, 0x01, PIOM) CreateByteField (BUFF, 0x08, DMAM) Store (SRTM, Local0) Store (0x08, Local1) If (LEqual (Local0, 0xA3)) { Store (0x0C, Local1) } Else { If (LEqual (Local0, 0xA1)) { Store (0x0B, Local1) } Else { If (LEqual (Local0, 0x90)) { Store (0x0A, Local1) } } } Store (SUDM, Local2) If (LEqual (Local2, 0x01)) { Store (SUDC, Local4) If (LEqual (FSC0, 0x01)) { Store (0x45, Local3) } Else { If (LEqual (SCB0, 0x01)) { Store (0x44, Local3) } Else { Store (0x40, Local3) If (LEqual (Local4, 0x01)) { Store (0x41, Local3) } Else { If (LEqual (Local4, 0x02)) { Store (0x42, Local3) } } } } } Else { Store (0x21, Local3) If (LEqual (Local0, 0xA3)) { Store (0x22, Local3) } } Store (Local1, PIOM) Store (Local3, DMAM) Return (BUFF) } } } } Device (VGA) { Name (_ADR, 0x00020000) Method (_PS0, 0, Serialized) { While (LEqual (\_SB.MEM.VGAR, 0x00)) {} If (LEqual (\_SB.MEM.DOS2, 0x00)) { If (LOr (LNotEqual (\_SB.MEM.CTLA, = \_SB.MEM.NXLA), LOr (LNotEqual (\_SB.MEM.CTCA,=20 \_SB.MEM.NXCA), LOr (LNotEqual = (\_SB.MEM.CTDA, \_SB.MEM.NXDA), LNotEqual (\_SB.MEM.CTTA, = \_SB.MEM.NXTA))))) { Notify (\_SB.PCI0.VGA, 0x80) } } Store (0x01, \_SB.MEM.IESI) Store (0x00, \_SB.MEM.IEDI) SMBR (0xFE00, 0x23, 0x10, 0x00, 0xB2) If (LEqual (\_SB.MEM.OEAX, 0x00)) { Store (0x01, \_SB.MEM.IESI) Store (0x00, \_SB.MEM.IEDI) SMBR (0xFF00, 0x23, 0x10, 0x00, 0xB2) WPSX (0x10, 0x01, 0x00, 0x00) Store (0x00, \_SB.MEM.VGAF) } } Method (_PS1, 0, Serialized) { While (LEqual (\_SB.MEM.VGAR, 0x00)) {} Store (0x01, \_SB.MEM.IESI) Store (0x00, \_SB.MEM.IEDI) SMBR (0xFE00, 0x23, 0x10, 0x00, 0xB2) If (LEqual (\_SB.MEM.OEAX, 0x00)) { Store (0x01, \_SB.MEM.IESI) Store (0x00, \_SB.MEM.IEDI) SMBR (0xFF00, 0x23, 0x10, 0x01, 0xB2) WPSX (0x10, 0x01, 0x00, 0x01) Store (0x01, \_SB.MEM.VGAF) } } Method (_PS3, 0, Serialized) { While (LEqual (\_SB.MEM.VGAR, 0x00)) {} Store (0x01, \_SB.MEM.IESI) Store (0x00, \_SB.MEM.IEDI) SMBR (0xFE00, 0x23, 0x10, 0x00, 0xB2) If (LEqual (\_SB.MEM.OEAX, 0x00)) { Store (0x01, \_SB.MEM.IESI) Store (0x00, \_SB.MEM.IEDI) SMBR (0xFF00, 0x23, 0x10, 0x03, 0xB2) WPSX (0x10, 0x01, 0x00, 0x03) Store (0x01, \_SB.MEM.VGAF) } } Method (_PSC, 0, NotSerialized) { While (LEqual (\_SB.MEM.VGAR, 0x00)) {} Store (0x01, \_SB.MEM.IESI) Store (0x00, \_SB.MEM.IEDI) SMBR (0xFE00, 0x23, 0x10, 0x00, 0xB2) Return (\_SB.MEM.OEDX) } Method (_DOS, 1, NotSerialized) { If (LEqual (Arg0, 0x00)) { Store (0x01, \_SB.MEM.DCST) Store (0x00, \_SB.MEM.DOS2) } Else { If (LEqual (Arg0, 0x01)) { Store (0x00, \_SB.MEM.DCST) Store (0x01, \_SB.MEM.DOS2) } Else { If (LEqual (Arg0, 0x02)) { Store (0x01, \_SB.MEM.DCST) Store (0x01, \_SB.MEM.DOS2) } } } } Method (_DOD, 0, NotSerialized) { Name (BUFF, Package (0x02) { 0x0400,=20 0x0100 }) Return (BUFF) } Method (_ROM, 2, NotSerialized) { Add (Arg0, 0x000C0000, Local0) ShiftLeft (Arg1, 0x03, Local1) Name (BUFF, Buffer (Arg1) {}) Scope (\) { OperationRegion (VROM, SystemMemory, Local0, = Local1) Field (VROM, ByteAcc, NoLock, Preserve) { ROMI, 65536 } } Store (\ROMI, BUFF) Return (BUFF) } Device (LCD) { Name (_ADR, 0x0400) Method (_DCS, 0, NotSerialized) { If (\_SB.MEM.CTLA) { Return (0x0F) } Else { Return (0x0D) } } Method (_DDC, 1, NotSerialized) { If (LEqual (Arg0, 0x01)) { Store (0x80, Local0) } Else { If (LEqual (Arg0, 0x02)) { Store (0x0100, Local0) } Else { Return (Zero) } } Store (0x00, \_SB.MEM.PRES) ShiftLeft (Arg0, 0x08, Local1) Or (Local1, 0x01, Local1) Name (BUFF, Buffer (Local0) {}) SMBR (0xFE00, 0x37, Local1, 0x000EF000, 0xB2) And (Local1, 0xFF00, Local1) Store (0x0100, \_SB.MEM.OECX) While (\_SB.MEM.OECX) { SMBR (0xFE00, 0x37, Local1, 0x00, 0xB2) } Store (\_SB.MEM.FSDP, Local0) Or (Local0, 0x22, \_SB.MEM.FSDP) Subtract (\_SB.MEM.FSDP, Local0, Local0) Subtract (\_SB.MEM.EDCK, Local0, \_SB.MEM.EDCK) Store (\_SB.MEM.PRES, BUFF) Return (BUFF) } Method (_DGS, 0, NotSerialized) { If (\_SB.MEM.NXLA) { Return (One) } Else { Return (Zero) } } Method (_DSS, 1, NotSerialized) { Store (Arg0, Local0) And (Local0, 0x01, Local1) If (Local1) { Store (0x01, \_SB.MEM.NXLA) } Else { Store (0x00, \_SB.MEM.NXLA) } } Method (_BCL, 0, NotSerialized) { Name (BUFF, Package (0x05) { 0x64,=20 0x28,=20 0x00,=20 0x28,=20 0x64 }) If (\_SB.MEM.HPSU) { Store (\_SB.MEM.BCLA, Index (BUFF, 0x00)) Store (\_SB.MEM.BCLD, Index (BUFF, 0x01)) } Return (BUFF) } Method (_BCM, 1, NotSerialized) { If (LEqual (\_SB.MEM.HPSU, 0x00)) { Multiply (Arg0, 0xFFFF, Local0) Divide (Local0, 0x64, , Local0) SMBR (0xFF00, 0x2A, Local0, 0x00, 0xB2) } } Method (_PS0, 0, Serialized) { Store (0x00, \_SB.MEM.LCDS) } Method (_PS3, 0, Serialized) { Store (0x03, \_SB.MEM.LCDS) } Method (_PSC, 0, Serialized) { Return (\_SB.MEM.LCDS) } } Device (CRT) { Name (_ADR, 0x0100) Method (_DCS, 0, NotSerialized) { If (\_SB.MEM.CTCA) { Return (0x0F) } Else { Return (0x0D) } } Method (_DDC, 1, NotSerialized) { If (LEqual (Arg0, 0x01)) { Store (0x80, Local0) } Else { If (LEqual (Arg0, 0x02)) { Store (0x0100, Local0) } Else { Return (Zero) } } Store (0x00, \_SB.MEM.PRES) ShiftLeft (Arg0, 0x08, Local1) Or (Local1, 0x02, Local1) Name (BUFF, Buffer (Local0) {}) SMBR (0xFE00, 0x37, Local1, 0x000EF000, 0xB2) And (Local1, 0xFF00, Local1) Store (0x0100, \_SB.MEM.OECX) While (\_SB.MEM.OECX) { SMBR (0xFE00, 0x37, Local1, 0x00, 0xB2) } Store (\_SB.MEM.PRES, BUFF) Return (BUFF) } Method (_DGS, 0, NotSerialized) { If (\_SB.MEM.NXCA) { Return (One) } Else { Return (Zero) } } Method (_DSS, 1, NotSerialized) { Store (Arg0, Local0) And (Local0, 0x01, Local1) If (Local1) { Store (0x01, \_SB.MEM.NXCA) } Else { Store (0x00, \_SB.MEM.NXCA) } } Method (_PS0, 0, Serialized) { Store (0x00, \_SB.MEM.CRTS) } Method (_PS3, 0, Serialized) { Store (0x03, \_SB.MEM.CRTS) } Method (_PSC, 0, Serialized) { Return (\_SB.MEM.CRTS) } } } Device (USB1) { Name (_ADR, 0x001D0000) Device (HUB1) { Name (_ADR, 0x00) } Name (_PRW, Package (0x02) { 0x03,=20 0x03 }) Method (_PSW, 1, NotSerialized) { If (Arg0) { Store (0x01, \_SB.MEM.WED3) } Else { Store (0x00, \_SB.MEM.WED3) } } } Device (USB2) { Name (_ADR, 0x001D0001) Device (HUB2) { Name (_ADR, 0x00) } } Device (USB3) { Name (_ADR, 0x001D0002) Device (HUB3) { Name (_ADR, 0x00) } Name (_PRW, Package (0x02) { 0x0C,=20 0x03 }) Method (_PSW, 1, NotSerialized) { If (Arg0) { Store (0x01, \_SB.MEM.WED3) } Else { Store (0x00, \_SB.MEM.WED3) } } } Device (USB4) { Name (_ADR, 0x001D0003) Device (HUB4) { Name (_ADR, 0x00) } Name (_PRW, Package (0x02) { 0x0E,=20 0x03 }) Method (_PSW, 1, NotSerialized) { If (Arg0) { Store (0x01, \_SB.MEM.WED3) } Else { Store (0x00, \_SB.MEM.WED3) } } } Device (EHCI) { Name (_ADR, 0x001D0007) Name (_PRW, Package (0x02) { 0x0D,=20 0x03 }) Method (_PSW, 1, NotSerialized) { If (Arg0) { Store (0x01, \_SB.MEM.WED3) } Else { Store (0x00, \_SB.MEM.WED3) } } Device (HUB0) { Name (_ADR, 0x00) } } Device (AZAL) { Name (_ADR, 0x001B0000) Method (_PS0, 0, NotSerialized) { While (LEqual (\_SB.MEM.ACLR, 0x00)) {} Store (0x00, \_SB.MEM.PSND) } Method (_PS3, 0, NotSerialized) { Store (0x01, \_SB.MEM.PSND) } Method (_PSC, 0, NotSerialized) { If (\_SB.MEM.PSND) { Return (0x03) } Else { Return (0x00) } } Name (_PRW, Package (0x02) { 0x05,=20 0x03 }) Method (_PSW, 1, NotSerialized) { If (Arg0) { Store (0x01, \_SB.MEM.WED1) } Else { Store (0x00, \_SB.MEM.WED1) } } } Device (PEX1) { Name (_ADR, 0x001C0000) OperationRegion (PEX1, PCI_Config, 0x00, 0xFF) Field (PEX1, ByteAcc, NoLock, Preserve) { PLVI, 16,=20 Offset (0x60),=20 Offset (0x62),=20 PMES, 1,=20 Offset (0xDC),=20 , 30,=20 HPCS, 1,=20 PMCS, 1 } Method (_PRT, 0, NotSerialized) { If (LEqual (\_SB.MEM.PICM, 0x01)) { Return (APE1) } Else { Return (PPE1) } } Device (GLAN) { Name (_ADR, 0x00) Name (_PRW, Package (0x02) { 0x09,=20 0x04 }) Method (_PSW, 1, NotSerialized) { If (Arg0) { Store (0x01, \_SB.MEM.WED4) } Else { Store (0x00, \_SB.MEM.WED4) } } } } Device (MPEX) { Name (_ADR, 0x001C0002) OperationRegion (PEX3, PCI_Config, 0x00, 0xFF) Field (PEX3, ByteAcc, NoLock, Preserve) { PLVI, 16,=20 Offset (0x60),=20 Offset (0x62),=20 PMES, 1,=20 Offset (0xDC),=20 , 30,=20 HPCS, 1,=20 PMCS, 1 } Method (_PRT, 0, NotSerialized) { If (LEqual (\_SB.MEM.PICM, 0x01)) { Return (APE3) } Else { Return (PPE3) } } Device (WLAN) { Name (_ADR, 0x00) } } Method (_INI, 0, NotSerialized) { Store (\_SB.MEM.BES1, \_SB.MEM.BT1F) Store (0x00, \_SB.MEM.DSPW) Store (0x00, \_SB.MEM.VGAF) Store (0x00, \_SB.MEM.PPSC) Store (0x00, \_SB.MEM.SPSC) Store (0x00, \_SB.MEM.GP91) Store (0x00, Local0) If (CMPS (\_OS, "Microsoft Windows NT")) { Store (0x03, Local0) If (CondRefOf (\_OSI, Local1)) { If (\_OSI ("Windows 2001")) { Store (0x04, Local0) } } } Else { If (CMPS (\_OS, "Microsoft Windows")) { Store (0x01, Local0) } If (CMPS (\_OS, "Microsoft WindowsME:Millennium = Edition")) { Store (0x02, Local0) } } Store (Local0, \_SB.MEM.OSID) DIS (0x14) While (LEqual (\_SB.MEM.BTRE, 0x00)) {} SMBR (0xFF00, 0x1E, 0x01, 0x00, 0xB2) Store (0x01, \_SB.MEM.PAR1) Store (0x60, \_SB.PCI0.FNC0.SYSR.TRP4) SMBR (0xFA00, 0x3700, 0x00, 0x00, 0xB2) } } Name (APB0, Package (0x0A) { Package (0x04) { 0x0002FFFF,=20 0x00,=20 0x00,=20 0x10 },=20 Package (0x04) { 0x001BFFFF,=20 0x00,=20 0x00,=20 0x16 },=20 Package (0x04) { 0x001CFFFF,=20 0x00,=20 0x00,=20 0x11 },=20 Package (0x04) { 0x001CFFFF,=20 0x02,=20 0x00,=20 0x12 },=20 Package (0x04) { 0x001DFFFF,=20 0x00,=20 0x00,=20 0x17 },=20 Package (0x04) { 0x001DFFFF,=20 0x01,=20 0x00,=20 0x13 },=20 Package (0x04) { 0x001DFFFF,=20 0x02,=20 0x00,=20 0x12 },=20 Package (0x04) { 0x001DFFFF,=20 0x03,=20 0x00,=20 0x10 },=20 Package (0x04) { 0x001FFFFF,=20 0x00,=20 0x00,=20 0x12 },=20 Package (0x04) { 0x001FFFFF,=20 0x01,=20 0x00,=20 0x13 } }) Name (PB00, Package (0x0A) { Package (0x04) { 0x0002FFFF,=20 0x00,=20 \_SB.LNKA,=20 0x00 },=20 Package (0x04) { 0x001BFFFF,=20 0x00,=20 \_SB.LNKG,=20 0x00 },=20 Package (0x04) { 0x001CFFFF,=20 0x00,=20 \_SB.LNKB,=20 0x00 },=20 Package (0x04) { 0x001CFFFF,=20 0x02,=20 \_SB.LNKC,=20 0x00 },=20 Package (0x04) { 0x001DFFFF,=20 0x00,=20 \_SB.LNKH,=20 0x00 },=20 Package (0x04) { 0x001DFFFF,=20 0x01,=20 \_SB.LNKD,=20 0x00 },=20 Package (0x04) { 0x001DFFFF,=20 0x02,=20 \_SB.LNKC,=20 0x00 },=20 Package (0x04) { 0x001DFFFF,=20 0x03,=20 \_SB.LNKA,=20 0x00 },=20 Package (0x04) { 0x001FFFFF,=20 0x00,=20 \_SB.LNKC,=20 0x00 },=20 Package (0x04) { 0x001FFFFF,=20 0x01,=20 \_SB.LNKD,=20 0x00 } }) Name (APB1, Package (0x04) { Package (0x04) { 0x0008FFFF,=20 0x00,=20 0x00,=20 0x14 },=20 Package (0x04) { 0x000BFFFF,=20 0x00,=20 0x00,=20 0x15 },=20 Package (0x04) { 0x000BFFFF,=20 0x01,=20 0x00,=20 0x14 },=20 Package (0x04) { 0x000BFFFF,=20 0x03,=20 0x00,=20 0x17 } }) Name (PB01, Package (0x04) { Package (0x04) { 0x0008FFFF,=20 0x00,=20 \_SB.LNKE,=20 0x00 },=20 Package (0x04) { 0x000BFFFF,=20 0x00,=20 \_SB.LNKF,=20 0x00 },=20 Package (0x04) { 0x000BFFFF,=20 0x01,=20 \_SB.LNKE,=20 0x00 },=20 Package (0x04) { 0x000BFFFF,=20 0x03,=20 \_SB.LNKH,=20 0x00 } }) Name (APE1, Package (0x04) { Package (0x04) { 0xFFFF,=20 0x00,=20 0x00,=20 0x10 },=20 Package (0x04) { 0xFFFF,=20 0x01,=20 0x00,=20 0x11 },=20 Package (0x04) { 0xFFFF,=20 0x02,=20 0x00,=20 0x12 },=20 Package (0x04) { 0xFFFF,=20 0x03,=20 0x00,=20 0x13 } }) Name (PPE1, Package (0x04) { Package (0x04) { 0xFFFF,=20 0x00,=20 \_SB.LNKA,=20 0x00 },=20 Package (0x04) { 0xFFFF,=20 0x01,=20 \_SB.LNKB,=20 0x00 },=20 Package (0x04) { 0xFFFF,=20 0x02,=20 \_SB.LNKC,=20 0x00 },=20 Package (0x04) { 0xFFFF,=20 0x03,=20 \_SB.LNKD,=20 0x00 } }) Name (APE3, Package (0x04) { Package (0x04) { 0xFFFF,=20 0x00,=20 0x00,=20 0x12 },=20 Package (0x04) { 0xFFFF,=20 0x01,=20 0x00,=20 0x13 },=20 Package (0x04) { 0xFFFF,=20 0x02,=20 0x00,=20 0x10 },=20 Package (0x04) { 0xFFFF,=20 0x03,=20 0x00,=20 0x11 } }) Name (PPE3, Package (0x04) { Package (0x04) { 0xFFFF,=20 0x00,=20 \_SB.LNKC,=20 0x00 },=20 Package (0x04) { 0xFFFF,=20 0x01,=20 \_SB.LNKD,=20 0x00 },=20 Package (0x04) { 0xFFFF,=20 0x02,=20 \_SB.LNKA,=20 0x00 },=20 Package (0x04) { 0xFFFF,=20 0x03,=20 \_SB.LNKB,=20 0x00 } }) Device (BT) { Name (_HID, "TOS6205") Method (_STA, 0, NotSerialized) { If (\_SB.MEM.BTMD) { Return (0x0F) } Else { Return (0x00) } } Method (BTST, 0, NotSerialized) { Store (0x00, \_SB.MEM.OESI) SMBR (0xFE00, 0x4D, 0x01, 0x7D00, 0xB2) Store (0x01, Local0) While (Local0) { SMBR (0xFE00, 0x4D, 0x0101, 0x7D00, 0xB2) Store (\_SB.MEM.OESI, Local2) And (\_SB.MEM.OEAX, 0xFF00, Local1) If (Local1) { And (\_SB.MEM.OEAX, 0xFF, Local1) If (LNotEqual (Local1, 0x20)) { Store (0x00, Local2) Store (0x00, Local0) } } Else { Store (0x00, Local0) } } And (Local2, 0x02, Local0) ShiftLeft (Local0, 0x06, Local0) And (Local2, 0x04, Local1) ShiftLeft (Local1, 0x04, Local1) Or (Local0, Local1, Local0) And (Local2, 0x10, Local3) ShiftRight (Local3, 0x04, Local3) Or (Local0, Local3, Local0) Return (Local0) } Method (AUSB, 0, NotSerialized) { If (\_SB.MEM.BTMD) { Store (0x00, \_SB.MEM.IEDI) Store (0x03, \_SB.MEM.IESI) SMBR (0xFF00, 0x4D, 0x01, 0x7C00, 0xB2) Store (0x01, Local0) While (Local0) { SMBR (0xFF00, 0x4D, 0x0101, 0x7C00, 0xB2) And (\_SB.MEM.OEAX, 0xFF00, Local1) If (Local1) { And (\_SB.MEM.OEAX, 0xFF, Local1) If (LNotEqual (Local1, 0x20)) { Store (0x00, Local0) } } Else { Store (0x00, Local0) } } } } Method (DUSB, 0, NotSerialized) { If (\_SB.MEM.BTMD) { Store (0x00, \_SB.MEM.IEDI) Store (0x04, \_SB.MEM.IESI) SMBR (0xFF00, 0x4D, 0x01, 0x7C00, 0xB2) Store (0x01, Local0) While (Local0) { SMBR (0xFF00, 0x4D, 0x0101, 0x7C00, 0xB2) And (\_SB.MEM.OEAX, 0xFF00, Local1) If (Local1) { And (\_SB.MEM.OEAX, 0xFF, Local1) If (LNotEqual (Local1, 0x20)) { Store (0x00, Local0) } } Else { Store (0x00, Local0) } } } } Method (BTPO, 0, NotSerialized) { If (\_SB.MEM.BTMD) { Store (0x00, \_SB.MEM.IEDI) Store (0x01, \_SB.MEM.IESI) SMBR (0xFF00, 0x4D, 0x01, 0x7C00, 0xB2) Store (0x01, Local0) While (Local0) { SMBR (0xFF00, 0x4D, 0x0101, 0x7C00, 0xB2) And (\_SB.MEM.OEAX, 0xFF00, Local1) If (Local1) { And (\_SB.MEM.OEAX, 0xFF, Local1) If (LNotEqual (Local1, 0x20)) { Store (0x00, Local0) } } Else { Store (0x00, Local0) } } } } Method (BTPF, 0, NotSerialized) { If (\_SB.MEM.BTMD) { Store (0x00, \_SB.MEM.IEDI) Store (0x02, \_SB.MEM.IESI) SMBR (0xFF00, 0x4D, 0x01, 0x7C00, 0xB2) Store (0x01, Local0) While (Local0) { SMBR (0xFF00, 0x4D, 0x0101, 0x7C00, 0xB2) And (\_SB.MEM.OEAX, 0xFF00, Local1) If (Local1) { And (\_SB.MEM.OEAX, 0xFF, Local1) If (LNotEqual (Local1, 0x20)) { Store (0x00, Local0) } } Else { Store (0x00, Local0) } } } } } Device (LID) { Name (_HID, EisaId ("PNP0C0D")) Method (_LID, 0, NotSerialized) { Return (\_SB.MEM.LIDS) } Name (_PRW, Package (0x02) { 0x1C,=20 0x04 }) Method (_PSW, 1, NotSerialized) { If (LEqual (Arg0, 0x00)) { Store (0x00, \_SB.MEM.EWLD) } Else { Store (0x01, \_SB.MEM.EWLD) } } } Device (BAT1) { Name (_HID, EisaId ("PNP0C0A")) Name (_UID, 0x01) Name (_PCL, Package (0x01) { \_SB }) Method (_STA, 0, NotSerialized) { If (\_SB.MEM.BES1) { Return (0x1F) } Else { Return (0x0F) } } Method (_BIF, 0, NotSerialized) { Name (BUFF, Package (0x0D) {}) Store (0x00, Index (BUFF, 0x00)) Store (\_SB.MEM.BDV1, Local2) Multiply (\_SB.MEM.BDC1, Local2, Local0) Divide (Local0, 0x03E8, Local1, Local0) Store (Local0, Index (BUFF, 0x01)) Multiply (\_SB.MEM.BLF1, Local2, Local0) Divide (Local0, 0x03E8, Local1, Local0) Store (Local0, Index (BUFF, 0x02)) Store (\_SB.MEM.BTC1, Index (BUFF, 0x03)) Store (\_SB.MEM.BDV1, Index (BUFF, 0x04)) Multiply (\_SB.MEM.BCW1, Local2, Local0) Divide (Local0, 0x03E8, Local1, Local0) Store (Local0, Index (BUFF, 0x05)) Multiply (\_SB.MEM.BCL1, Local2, Local0) Divide (Local0, 0x03E8, Local1, Local0) Store (Local0, Index (BUFF, 0x06)) Multiply (\_SB.MEM.BG11, Local2, Local0) Divide (Local0, 0x03E8, Local1, Local0) Store (Local0, Index (BUFF, 0x07)) Multiply (\_SB.MEM.BG21, Local2, Local0) Divide (Local0, 0x03E8, Local1, Local0) Store (Local0, Index (BUFF, 0x08)) Store (\_SB.MEM.BMN1, Index (BUFF, 0x09)) Store (\_SB.MEM.BSN1, Index (BUFF, 0x0A)) Store (\_SB.MEM.BTP1, Index (BUFF, 0x0B)) Store (\_SB.MEM.BOI1, Index (BUFF, 0x0C)) Return (BUFF) } Method (_BST, 0, NotSerialized) { If (\_SB.MEM.BES2) { And (\_SB.MEM.BST1, 0x03, Local0) And (\_SB.MEM.BST2, 0x03, Local1) If (LOr (Local0, Local1)) { Multiply (\_SB.MEM.BPR1, \_SB.MEM.BDV1, Local0) Divide (Local0, 0x07D0, Local1, Local0) } Else { Store (0x00, Local0) } } Else { If (LAnd (\_SB.MEM.BST1, 0x03)) { Multiply (\_SB.MEM.BPR1, \_SB.MEM.BDV1, Local0) Divide (Local0, 0x03E8, Local1, Local0) } Else { Store (0x00, Local0) } } Name (BUFF, Package (0x04) {}) Store (\_SB.MEM.BST1, Index (BUFF, 0x00)) Store (Local0, Index (BUFF, 0x01)) Multiply (\_SB.MEM.BRC1, \_SB.MEM.BDV1, Local0) Divide (Local0, 0x03E8, Local1, Local0) Store (Local0, Index (BUFF, 0x02)) Store (\_SB.MEM.BPV1, Index (BUFF, 0x03)) Return (BUFF) } Method (_BTP, 1, NotSerialized) { Store (0x01, \_SB.MEM.PAR1) Store (Arg0, \_SB.MEM.PAR2) Store (0x61, \_SB.PCI0.FNC0.SYSR.TRP4) } } Device (PWRB) { Name (_HID, EisaId ("PNP0C0C")) Name (_PRW, Package (0x02) { 0x08,=20 0x04 }) Name (_STA, 0x0B) } Device (ADP1) { Name (_HID, "ACPI0003") Name (_PCL, Package (0x02) { \_SB,=20 \_SB.BAT1 }) Name (_STA, 0x0F) Method (_PSR, 0, NotSerialized) { Return (\_SB.MEM.AACS) } } Device (VALZ) { Name (_HID, EisaId ("TOS6208")) Name (_DDN, "VALZeneral") Method (_STA, 0, NotSerialized) { If (\_SB.MEM.WAKS) { While (LEqual (\_SB.MEM.ACVA, 0x00)) {} Store (0x00, \_SB.MEM.WAKS) } Return (0x0B) } Method (ENAB, 0, NotSerialized) { Store (0x01, \_SB.MEM.VALF) SMBR (0xFF00, 0x16, 0x01, 0x00, 0xB2) } Method (INFO, 0, NotSerialized) { Store (0x00, \_SB.MEM.OECX) SMBR (0xFE00, 0x16, 0x00, 0x00, 0xB2) If (LNotEqual (\_SB.MEM.OEAX, 0x00)) { Store (0x00, \_SB.MEM.OECX) } Return (\_SB.MEM.OECX) } Method (GHCI, 6, Serialized) { CreateDWordField (Arg0, 0x00, REAX) CreateWordField (Arg1, 0x00, R_BX) And (REAX, 0xFF00, Local0) If (LEqual (Local0, 0xFE00)) { If (LEqual (R_BX, 0xC000)) { Return (G000 (Local0, R_BX, Arg2, Arg3, Arg4, = Arg5)) } If (LEqual (R_BX, 0xC004)) { Return (G004 (Local0, R_BX, Arg2, Arg3, Arg4, = Arg5)) } If (LEqual (R_BX, 0xC800)) { Return (G800 (Local0, R_BX, Arg2, Arg3, Arg4, = Arg5)) } If (LEqual (R_BX, 0xC801)) { Return (G801 (Local0, R_BX, Arg2, Arg3, Arg4, = Arg5)) } } If (LEqual (Local0, 0xFF00)) { If (LEqual (R_BX, 0xC000)) { Return (G000 (Local0, R_BX, Arg2, Arg3, Arg4, = Arg5)) } If (LEqual (R_BX, 0xC801)) { Return (G801 (Local0, R_BX, Arg2, Arg3, Arg4, = Arg5)) } } Return (GCH0 (Arg0, Arg1, Arg2, Arg3, Arg4, Arg5)) } Method (GCH0, 6, NotSerialized) { Store (Arg4, \_SB.MEM.IESI) Store (Arg5, \_SB.MEM.IEDI) SMBR (Arg0, Arg1, Arg2, Arg3, 0xB2) Name (BUFF, Package (0x06) {}) Store (\_SB.MEM.OEAX, Index (BUFF, 0x00)) Store (\_SB.MEM.OEBX, Index (BUFF, 0x01)) Store (\_SB.MEM.OECX, Index (BUFF, 0x02)) Store (\_SB.MEM.OEDX, Index (BUFF, 0x03)) Store (\_SB.MEM.OESI, Index (BUFF, 0x04)) Store (\_SB.MEM.OEDI, Index (BUFF, 0x05)) Return (BUFF) } Method (G000, 6, NotSerialized) { Name (BUFF, Package (0x06) {}) CreateDWordField (Arg2, 0x00, RECX) CreateDWordField (Arg3, 0x00, REDX) CreateDWordField (Arg4, 0x00, RESI) CreateDWordField (Arg5, 0x00, REDI) CreateByteField (Arg2, 0x00, R_CL) Store (0x00, Index (BUFF, 0x00)) Store (Arg1, Index (BUFF, 0x01)) Store (RECX, Index (BUFF, 0x02)) Store (REDX, Index (BUFF, 0x03)) Store (RESI, Index (BUFF, 0x04)) Store (REDI, Index (BUFF, 0x05)) If (\_SB.MEM.GCVS) { If (LEqual (Arg0, 0xFE00)) { If (LEqual (R_CL, 0x00)) { Store (\_SB.MEM.TNVS, Local0) Store (Local0, Index (BUFF, 0x02)) } Else { If (LAnd (LGreaterEqual (R_CL, 0x01), = LLessEqual (R_CL, 0x04))) { Store (R_CL, Local0) Or (Local0, 0x3000, Local0) SMBR (0xFA00, Local0, 0x00, 0x00, 0xB2) Store (\_SB.MEM.OECX, Index (BUFF, = 0x02)) Store (\_SB.MEM.OEDX, Index (BUFF, = 0x03)) } Else { If (LEqual (R_CL, 0x05)) { Store (0x21, Index (BUFF, 0x02)) } Else { If (LEqual (R_CL, 0x06)) { Store (0x01, Index (BUFF, 0x02)) } Else { Store (0x8300, Index (BUFF, = 0x00)) } } } } } Else { CreateWordField (Arg3, 0x00, R_DX) If (LEqual (R_CL, 0x00)) { If (LEqual (R_DX, 0x00)) { Store (0x00, \_SB.MEM.TNVS) } Else { Store (0x01, \_SB.MEM.TNVS) } } Else { If (LEqual (R_CL, 0x01)) { Store (R_CL, Local0) Or (Local0, 0x3080, Local0) SMBR (0xFA00, Local0, R_DX, 0x00, 0xB2) } Else { If (LEqual (R_CL, 0x02)) { And (R_DX, 0x0F, Local0) Store (Local0, \_SB.MEM.NXDD) If (LLess (\_SB.MEM.OSID, 0x03)) { Or (Local0, 0x0100, Local0) SMBR (0xFF00, 0x1C, Local0, = 0x00, 0xB2) And (\_SB.MEM.OEAX, 0xFF00, = Local0) If (LEqual (Local0, 0x00)) { Store (0x80, Local0) While (LEqual (Local0, = 0x80)) { SMBR (0xFE00, 0x1C, = 0x00, 0x00, 0xB2) And (\_SB.MEM.OECX, = 0x80, Local0) } If (\_SB.MEM.CTLA) { If (LEqual = (\_SB.MEM.LCDS, 0x00)) { SMBR (0xFF00, 0x02, = 0x01, 0x00, 0xB2) Store (0x01, = \_SB.MEM.OEDX) While = (\_SB.MEM.OEDX) { SMBR (0xFE00, = 0x02, 0x00, 0x00, 0xB2) } } } } } Else { VGAN () } } Else { Store (0x8300, Index (BUFF, 0x00)) } } } } } Else { Store (0x8000, Index (BUFF, 0x00)) } Return (BUFF) } Method (G004, 6, NotSerialized) { CreateByteField (Arg2, 0x00, R_CL) Name (BUFF, Package (0x06) {}) Store (Arg1, Index (BUFF, 0x01)) Store (Arg4, Index (BUFF, 0x04)) Store (Arg5, Index (BUFF, 0x05)) If (LLessEqual (R_CL, 0x01)) { And (Arg2, 0xFFFF00FF, Local0) Store (Local0, Index (BUFF, 0x02)) And (Arg3, 0xFFFF0000, Local0) Store (Local0, Index (BUFF, 0x03)) Store (0x00, Local0) } Else { Store (Arg2, Index (BUFF, 0x02)) Store (Arg3, Index (BUFF, 0x03)) Store (0x8300, Local0) } Store (Local0, Index (BUFF, 0x00)) Return (BUFF) } Method (G800, 6, NotSerialized) { Store (\_SB.MEM.OSPC, Local0) Name (BUFF, Package (0x06) {}) CreateDWordField (Arg3, 0x00, REDX) CreateDWordField (Arg4, 0x00, RESI) CreateDWordField (Arg5, 0x00, REDI) Store (0x00, Index (BUFF, 0x00)) Store (Arg1, Index (BUFF, 0x01)) Store (Local0, Index (BUFF, 0x02)) Store (REDX, Index (BUFF, 0x03)) Store (RESI, Index (BUFF, 0x04)) Store (REDI, Index (BUFF, 0x05)) Return (BUFF) } Method (G801, 6, NotSerialized) { CreateDWordField (Arg2, 0x00, RECX) CreateDWordField (Arg3, 0x00, REDX) CreateDWordField (Arg4, 0x00, RESI) CreateDWordField (Arg5, 0x00, REDI) Store (0x8300, Local0) Store (RECX, Local1) If (LEqual (REDX, 0x01)) { Store (0x00, Local0) If (LEqual (Arg0, 0xFE00)) { Store (\_SB.MEM.PULD, Local1) Store (\_SB.MEM.PULA, Local2) ShiftLeft (Local2, 0x08, Local2) Or (Local1, Local2, Local1) } Else { And (Local1, 0xFF, Local2) ShiftRight (Local1, 0x08, Local3) Store (Local2, \_SB.MEM.PULD) Store (Local3, \_SB.MEM.PULA) } } If (LEqual (REDX, 0x02)) { Store (0x00, Local0) If (LEqual (Arg0, 0xFE00)) { Store (\_SB.MEM.BCLD, Local1) Store (\_SB.MEM.BCLA, Local2) ShiftLeft (Local2, 0x08, Local2) Or (Local1, Local2, Local1) } Else { And (Local1, 0xFF, Local2) ShiftRight (Local1, 0x08, Local3) Store (Local2, \_SB.MEM.BCLD) Store (Local3, \_SB.MEM.BCLA) } } Name (BUFF, Package (0x06) {}) Store (Local0, Index (BUFF, 0x00)) Store (Arg1, Index (BUFF, 0x01)) Store (Local1, Index (BUFF, 0x02)) Store (REDX, Index (BUFF, 0x03)) Store (RESI, Index (BUFF, 0x04)) Store (REDI, Index (BUFF, 0x05)) Return (BUFF) } Method (VNTF, 1, NotSerialized) { And (Arg0, 0xFFFF, Local0) ShiftRight (Arg0, 0x10, Local1) If (LEqual (Local1, 0x01)) { CPUN () } } Method (EHSS, 0, NotSerialized) { Name (BUFF, Buffer (0x20) { /* 0000 */ 0x07, 0x00, 0x00, 0x00, 0x3C, 0x00, = 0x00, 0x00,=20 /* 0008 */ 0x32, 0x00, 0x00, 0x00, 0x01, 0x00, = 0x00, 0x00,=20 /* 0010 */ 0x03, 0x00, 0x00, 0x00, 0x5E, 0x01, = 0x00, 0x00,=20 /* 0018 */ 0x3C, 0x00, 0x00, 0x00, 0x05, 0x00, = 0x00, 0x00 }) If (LNotEqual (\_SB.MEM.MSP0, 0x00)) { CreateWordField (BUFF, 0x00, INF0) CreateDWordField (BUFF, 0x04, SSP0) CreateDWordField (BUFF, 0x08, SSP1) CreateDWordField (BUFF, 0x0C, SSCH) CreateDWordField (BUFF, 0x10, SSCL) CreateDWordField (BUFF, 0x14, SSSI) CreateDWordField (BUFF, 0x18, SSS0) CreateDWordField (BUFF, 0x1C, SSR0) Divide (SizeOf (BUFF), 0x04, Local1, Local0) Decrement (Local0) Store (Local0, INF0) Store (\_SB.MEM.MSP0, SSP0) Store (\_SB.MEM.MSP1, SSP1) Store (\_SB.MEM.MSC0, SSCH) Store (\_SB.MEM.MSC1, SSCL) Store (\_SB.MEM.MSSI, SSSI) Store (\_SB.MEM.MSSS, SSS0) Store (\_SB.MEM.MSSR, SSR0) } Return (BUFF) } Method (ODLS, 0, NotSerialized) { Return (0x01) } Method (ODLB, 0, NotSerialized) { Name (BUFF, Buffer (0x10) { /* 0000 */ 0x86, 0x80, 0xC4, 0x27, 0x79, 0x11, = 0x01, 0x00,=20 /* 0008 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, = 0x00, 0x00 }) Store (\_SB.PCI0.FNC2.RVID, Local0) CreateByteField (BUFF, 0x08, IREV) Store (Local0, IREV) Return (BUFF) } } Device (HAPS) { Name (_HID, EisaId ("TOS620A")) Method (PTLV, 1, NotSerialized) { Store (Arg0, Local0) Or (Local0, 0x3500, Local0) SMBR (0xFA00, Local0, 0x00, 0x00, 0xB2) } Method (RSSS, 0, NotSerialized) { SMBR (0xFA00, 0x3580, 0x00, 0x00, 0xB2) } } } Scope (\_TZ) { ThermalZone (THRM) { Method (_TMP, 0, NotSerialized) { If (LLessEqual (\_SB.MEM.TMP1, 0x0B4C)) { Store (0x0B4C, \_SB.MEM.AST1) Return (0x0B4C) } Else { Store (\_SB.MEM.TMP1, \_SB.MEM.AST1) Return (\_SB.MEM.TMP1) } } Method (_CRT, 0, NotSerialized) { Return (\_SB.MEM.CRT1) } } } Scope (\_GPE) { Method (_L03, 0, Serialized) { Notify (\_SB.PCI0.USB1, 0x02) Store (0x00, \_SB.MEM.GP75) } Method (_L05, 0, Serialized) { If (\_SB.MEM.GP73) { Store (0x00, \_SB.MEM.GP73) Notify (\_SB.PCI0.AZAL, 0x02) } } Method (_L08, 0, Serialized) { Store (\_SB.PCI0.FNC0.SYSR.GPLV, Local0) Or (Local0, 0x02000000, Local0) Store (Local0, \_SB.PCI0.FNC0.SYSR.GPLV) While (LOr (\_SB.MEM.GP50, LOr (\_SB.MEM.GP52, LOr = (\_SB.MEM.GP53, LOr (\_SB.MEM.GP54, LOr ( \_SB.MEM.GP56, LOr (\_SB.MEM.GP66, LOr (\_SB.MEM.GP70, = LOr (\_SB.MEM.GP71, LOr (\_SB.MEM.GP93, LOr (\_SB.MEM.GP94,=20 LOr (\_SB.MEM.BPFE, \_SB.MEM.B1ST)))))))))))) { If (\_SB.MEM.GP50) { Store (0x00, \_SB.MEM.GP50) Notify (\_SB.ADP1, 0x80) CPUN () } If (\_SB.MEM.GP52) { Store (0x00, \_SB.MEM.GP52) If (LEqual (\_SB.MEM.BES1, \_SB.MEM.BT1F)) { Notify (\_SB.BAT1, 0x80) } Else { Store (\_SB.MEM.BES1, \_SB.MEM.BT1F) If (\_SB.MEM.BES1) { Notify (\_SB.BAT1, 0x00) } Else { Notify (\_SB.BAT1, 0x01) } } } If (\_SB.MEM.B1ST) { Store (0x00, \_SB.MEM.B1ST) Notify (\_SB.BAT1, 0x81) } If (\_SB.MEM.GP53) { Store (0x00, \_SB.MEM.GP53) If (LNotEqual (\_SB.MEM.TMP1, \_SB.MEM.AST1)) { Notify (\_TZ.THRM, 0x80) } } If (\_SB.MEM.GP54) { Store (0x00, \_SB.MEM.GP54) } If (\_SB.MEM.GP56) { Store (0x00, \_SB.MEM.GP56) Notify (\_SB.BAT1, 0x80) } If (\_SB.MEM.GP66) { Store (0x00, \_SB.MEM.GP66) SMBR (0xFE00, 0x14, 0x00, 0x00, 0xB2) Store (\_SB.MEM.OECX, Local0) If (LAnd (LNotEqual (\_SB.MEM.BDID, 0x00), LEqual = (\_SB.MEM.OECX, 0x00))) { Store (\_SB.MEM.BDID, Local0) } Store (\_SB.MEM.OECX, \_SB.MEM.BDID) If (LEqual (Local0, 0x02)) { Notify (\_SB.PCI0.FNC2.IDE1, 0x00) } } If (\_SB.MEM.GP70) { Store (0x00, \_SB.MEM.GP70) If (\_SB.MEM.VALF) { Notify (\_SB.VALZ, 0x80) } If (LEqual (\_SB.MEM.HKCD, 0x3D)) { TRAP (\_SB.MEM.HKCD) } If (LEqual (\_SB.MEM.DOS2, 0x00)) { If (LEqual (\_SB.MEM.HKCD, 0x3F)) { If (LEqual (\_SB.MEM.TNVS, 0x00)) { VGAN () } } } } If (\_SB.MEM.GP71) { Store (0x00, \_SB.MEM.GP71) Notify (\_SB.LID, 0x80) } If (\_SB.MEM.BPFE) { Store (0x00, \_SB.MEM.BPFE) Notify (\_SB.BT, 0x90) } If (\_SB.MEM.GP93) { Store (0x00, \_SB.MEM.GP93) Notify (\_SB.HAPS, 0x80) } If (\_SB.MEM.GP94) { Store (0x00, \_SB.MEM.GP94) Notify (\_SB.HAPS, 0x81) } } } Method (_L09, 0, Serialized) { If (LNotEqual (\_SB.PCI0.PEX1.PLVI, 0xFFFF)) { If (\_SB.PCI0.PEX1.PMES) { Store (0x01, \_SB.PCI0.PEX1.PMES) Store (0x01, \_SB.PCI0.PEX1.PMCS) Notify (\_SB.PCI0.PEX1, 0x02) } } } Method (_L0B, 0, Serialized) { Notify (\_SB.PCI0.PCIB, 0x02) } Method (_L0C, 0, Serialized) { Notify (\_SB.PCI0.USB3, 0x02) Store (0x00, \_SB.MEM.GP75) } Method (_L0E, 0, Serialized) { Notify (\_SB.PCI0.USB4, 0x02) Store (0x00, \_SB.MEM.GP75) } Method (_L0D, 0, Serialized) { If (\_SB.MEM.GP77) { Store (0x00, \_SB.MEM.GP77) Notify (\_SB.PCI0.EHCI, 0x02) } } Method (_L1C, 0, Serialized) { Store (0x00, Local0) Increment (Local0) } } Method (_PTS, 1, NotSerialized) { If (\_SB.MEM.SPSC) { GSBS () If (LEqual (SBTB, 0x01)) { Store (0x01, \_SB.MEM.IESI) Store (0x02, \_SB.MEM.IEDI) SMBR (0xFE00, 0x23, 0xFA, 0x00, 0xB2) If (LNotEqual (\_SB.MEM.OEDX, 0x03)) { Store (0x01, \_SB.MEM.IESI) Store (0x02, \_SB.MEM.IEDI) SMBR (0xFF00, 0x23, 0xFA, 0x03, 0xB2) Store (0x01, \_SB.MEM.OECX) While (\_SB.MEM.OECX) { Store (0x01, \_SB.MEM.IESI) Store (0x02, \_SB.MEM.IEDI) SMBR (0xFE00, 0x23, 0xFA, 0x00, 0xB2) } } } } Store (\_SB.MEM.CTDD, \_SB.MEM.BCDD) If (LAnd (LGreaterEqual (Arg0, 0x01), LLessEqual (Arg0, 0x04))) { Store (\_SB.MEM.EWLD, \_SB.MEM.PAR1) Store (0x60, \_SB.PCI0.FNC0.SYSR.TRP4) } Store (\_SB.MEM.ACST, \_SB.MEM.ACBK) } Method (_WAK, 1, NotSerialized) { Notify (\_SB.PCI0.FNC2.IDE1, 0x00) DIS (0x14) SMBR (0xFF00, 0x1E, 0x01, 0x00, 0xB2) If (LLessEqual (\_SB.MEM.OSID, 0x03)) { While (LEqual (\_SB.MEM.KBCR, 0x00)) {} } If (LOr (LEqual (Arg0, 0x03), LEqual (Arg0, 0x04))) { Store (0x01, \_SB.MEM.DNTF) } Store (0x01, \_SB.MEM.WAKS) Store (0x01, \_SB.MEM.PAR1) Store (0x60, \_SB.PCI0.FNC0.SYSR.TRP4) If (LNotEqual (\_SB.MEM.ACST, \_SB.MEM.ACBK)) { CPUN () } SMBR (0xFA00, 0x3700, 0x00, 0x00, 0xB2) If (\_SB.MEM.GP91) { Store (0x00, \_SB.MEM.GP91) If (LEqual (Arg0, 0x04)) { Notify (\_SB.PWRB, 0x02) } } Name (BUFF, Package (0x02) { 0x00,=20 0x01 }) If (LEqual (\_SB.MEM.ACST, 0x00)) { And (\_SB.MEM.BST1, 0x04, Local0) If (LEqual (Local0, 0x04)) { Store (0x01, Index (BUFF, 0x00)) } } Return (BUFF) } Method (_PIC, 1, NotSerialized) { Store (Arg0, \_SB.MEM.PICM) } Method (TRAP, 1, NotSerialized) { Add (Arg0, 0x12340000, Debug) } Method (SMBR, 5, NotSerialized) { Store (Arg0, \_SB.MEM.IEAX) Store (Arg1, \_SB.MEM.IEBX) Store (Arg2, \_SB.MEM.IECX) Store (Arg3, \_SB.MEM.IEDX) Store (Arg4, \_SB.PCI0.FNC0.SYSR.TRP4) } Method (STA, 1, NotSerialized) { Store (Arg0, \_SB.MEM.PAR1) Store (0x00, \_SB.MEM.PAR2) Store (0x00, \_SB.MEM.PAR3) Store (0x00, \_SB.MEM.PAR4) Store (0x00, \_SB.MEM.PAR5) Store (0x00, \_SB.MEM.PAR6) Store (0x01, \_SB.PCI0.FNC0.SYSR.TRP4) Return (\_SB.MEM.PAR4) } Method (CRS, 1, NotSerialized) { Store (Arg0, \_SB.MEM.PAR1) Store (0x00, \_SB.MEM.PAR2) Store (0x00, \_SB.MEM.PAR3) Store (0x00, \_SB.MEM.PAR4) Store (0x00, \_SB.MEM.PAR5) Store (0x00, \_SB.MEM.PAR6) Store (0x01, \_SB.PCI0.FNC0.SYSR.TRP4) If (LEqual (\_SB.MEM.PAR3, 0x00)) { Return (ResourceTemplate () { }) } Name (BUFF, Buffer (\_SB.MEM.PAR3) {}) Store (\_SB.MEM.PRES, BUFF) Return (BUFF) } Method (PRS, 1, NotSerialized) { Store (Arg0, \_SB.MEM.PAR1) Store (0x01, \_SB.MEM.PAR2) Store (0x00, \_SB.MEM.PAR3) Store (0x00, \_SB.MEM.PAR4) Store (0x00, \_SB.MEM.PAR5) Store (0x00, \_SB.MEM.PAR6) Store (0x01, \_SB.PCI0.FNC0.SYSR.TRP4) If (LEqual (\_SB.MEM.PAR3, 0x00)) { Return (ResourceTemplate () { }) } Name (BUFF, Buffer (\_SB.MEM.PAR3) {}) Store (\_SB.MEM.PRES, BUFF) Return (BUFF) } Method (SRS, 2, NotSerialized) { Store (Arg0, \_SB.MEM.PAR1) Store (0x00, \_SB.MEM.PAR2) Store (0x00, \_SB.MEM.PAR3) Store (0x00, \_SB.MEM.PAR4) Store (0x00, \_SB.MEM.PAR5) Store (0x00, \_SB.MEM.PAR6) Store (Arg1, \_SB.MEM.PRES) Store (0x02, \_SB.PCI0.FNC0.SYSR.TRP4) } Method (DIS, 1, NotSerialized) { Store (Arg0, \_SB.MEM.PAR1) Store (0x00, \_SB.MEM.PAR2) Store (0x00, \_SB.MEM.PAR3) Store (0x00, \_SB.MEM.PAR4) Store (0x00, \_SB.MEM.PAR5) Store (0x00, \_SB.MEM.PAR6) Store (0x03, \_SB.PCI0.FNC0.SYSR.TRP4) } Method (PS0, 1, NotSerialized) { Store (0x00, \_SB.MEM.IESI) SMBR (0xFE00, 0x23, Arg0, 0x00, 0xB2) If (LEqual (\_SB.MEM.OEAX, 0x00)) { Store (0x00, \_SB.MEM.IESI) SMBR (0xFF00, 0x23, Arg0, 0x00, 0xB2) WPSX (Arg0, 0x00, 0x00, 0x00) } } Method (PS3, 1, NotSerialized) { Store (0x00, \_SB.MEM.IESI) SMBR (0xFE00, 0x23, Arg0, 0x00, 0xB2) If (LEqual (\_SB.MEM.OEAX, 0x00)) { Store (0x00, \_SB.MEM.IESI) SMBR (0xFF00, 0x23, Arg0, 0x03, 0xB2) WPSX (Arg0, 0x00, 0x00, 0x03) } } Method (WPSX, 4, NotSerialized) { Store (Arg1, \_SB.MEM.IESI) Store (Arg2, \_SB.MEM.IEDI) SMBR (0xFE00, 0x23, Arg0, 0x00, 0xB2) While (LNotEqual (\_SB.MEM.OECX, 0x00)) { Store (Arg1, \_SB.MEM.IESI) Store (Arg2, \_SB.MEM.IEDI) SMBR (0xFE00, 0x23, Arg0, 0x00, 0xB2) } } Method (PSC, 1, NotSerialized) { Store (0x00, \_SB.MEM.IESI) SMBR (0xFE00, 0x23, Arg0, 0x00, 0xB2) Return (\_SB.MEM.OEDX) } Method (CMPS, 2, NotSerialized) { If (LEqual (SizeOf (Arg0), SizeOf (Arg1))) { Return (One) } Else { Return (Zero) } } Method (STAL, 1, NotSerialized) { If (LEqual (Arg0, 0x80)) { Return (0x09) } Else { Return (0x0B) } } Method (CRSL, 1, NotSerialized) { Name (IRQB, ResourceTemplate () { IRQ (Level, ActiveLow, Shared, _Y01) {} }) CreateWordField (IRQB, \CRSL._Y01._INT, INTX) If (LLess (Arg0, 0x10)) { And (Arg0, 0x0F, Local0) ShiftLeft (0x01, Local0, INTX) } Return (IRQB) } Method (VGAN, 0, NotSerialized) { Notify (\_SB.PCI0.VGA, 0x80) } Method (CPUN, 0, NotSerialized) { If (And (\_SB.MEM.CFGD, 0x01)) { If (And (SDTL, 0x01)) { Notify (\_PR.CPU0, 0x80) } If (And (SDTL, 0x02)) { Sleep (0x64) Notify (\_PR.CPU0, 0x81) } If (And (SDTL, 0x10)) { Notify (\_PR.CPU1, 0x80) } If (And (SDTL, 0x20)) { Sleep (0x64) Notify (\_PR.CPU1, 0x81) } } Else { Notify (\_PR.CPU0, 0x80) } } Method (GSBS, 0, NotSerialized) { SMBR (0xFE00, 0x14, 0x00, 0x00, 0xB2) Store (\_SB.MEM.OECX, Local0) If (LOr (LEqual (Local0, 0x02), LEqual (Local0, 0x03))) { Store (0x01, SBTB) } Else { If (LOr (LEqual (Local0, 0x07), LEqual (Local0, 0x08))) { Store (0x02, SBTB) } Else { Store (0x00, SBTB) } } } Name (SBTB, 0xFF) Mutex (MTEX, 0x00) OperationRegion (P0PS, SystemMemory, 0x3F7A5764, 0x000000F3) OperationRegion (P0CS, SystemMemory, 0x3F7A58CD, 0x0000034E) OperationRegion (P1PS, SystemMemory, 0x3F7A5857, 0x00000076) OperationRegion (P1CS, SystemMemory, 0x3F7A5C1B, 0x00000079) Name (P0PH, 0x00) Name (P0CH, 0x00) Name (P1PH, 0x00) Name (P1CH, 0x00) Name (PDC0, 0xFFFFFFFF) Name (PDC1, 0xFFFFFFFF) Name (SDTL, 0x00) Scope (\_PR) { Processor (CPU0, 0x00, 0x0000D810, 0x06) { Method (_PDC, 1, NotSerialized) { CreateDWordField (Arg0, 0x08, CAP0) Store (CAP0, PDC0) If (And (\_SB.MEM.CFGD, 0x02)) { If (And (\_SB.MEM.CFGD, 0x04)) { If (LEqual (And (PDC0, 0x09), 0x09)) { Or (SDTL, 0x01, SDTL) Load (P0PS, P0PH) } } } If (And (\_SB.MEM.CFGD, 0x78)) { If (And (PDC0, 0x10)) {} If (And (PDC0, 0x10)) { Or (SDTL, 0x02, SDTL) Load (P0CS, P0CH) } } } Name (TPSS, Package (0x03) { Package (0x06) { 0x0726,=20 0x00007918,=20 0x0A,=20 0x0A,=20 0x0B2C,=20 0x0B2C },=20 Package (0x06) { 0x0532,=20 0x00004E20,=20 0x0A,=20 0x0A,=20 0x081D,=20 0x081D },=20 Package (0x06) { 0x03E8,=20 0x000032C8,=20 0x0A,=20 0x0A,=20 0x0613,=20 0x0613 },=20 Package (0x06) { 0xFFFF,=20 0xFFFFFFFF,=20 0xFF,=20 0xFF,=20 0xFFFF,=20 0xFFFF },=20 Package (0x06) { 0xFFFF,=20 0xFFFFFFFF,=20 0xFF,=20 0xFF,=20 0xFFFF,=20 0xFFFF },=20 Package (0x06) { 0xFFFF,=20 0xFFFFFFFF,=20 0xFF,=20 0xFF,=20 0xFFFF,=20 0xFFFF },=20 Package (0x06) { 0xFFFF,=20 0xFFFFFFFF,=20 0xFF,=20 0xFF,=20 0xFFFF,=20 0xFFFF },=20 Package (0x06) { 0xFFFF,=20 0xFFFFFFFF,=20 0xFF,=20 0xFF,=20 0xFFFF,=20 0xFFFF },=20 Package (0x06) { 0xFFFF,=20 0xFFFFFFFF,=20 0xFF,=20 0xFF,=20 0xFFFF,=20 0xFFFF },=20 Package (0x06) { 0xFFFF,=20 0xFFFFFFFF,=20 0xFF,=20 0xFF,=20 0xFFFF,=20 0xFFFF },=20 Package (0x06) { 0xFFFF,=20 0xFFFFFFFF,=20 0xFF,=20 0xFF,=20 0xFFFF,=20 0xFFFF },=20 Package (0x06) { 0xFFFF,=20 0xFFFFFFFF,=20 0xFF,=20 0xFF,=20 0xFFFF,=20 0xFFFF } }) } Processor (CPU1, 0x01, 0x0000D810, 0x06) { Method (_PDC, 1, NotSerialized) { CreateDWordField (Arg0, 0x08, CAP1) Store (CAP1, PDC1) If (And (\_SB.MEM.CFGD, 0x02)) { If (And (\_SB.MEM.CFGD, 0x04)) { If (LEqual (And (PDC1, 0x09), 0x09)) { Or (SDTL, 0x10, SDTL) Load (P1PS, P1PH) } } } If (And (\_SB.MEM.CFGD, 0x78)) { If (And (PDC1, 0x10)) { Or (SDTL, 0x20, SDTL) Load (P1CS, P1CH) } } } } } } --- dmesg output from verbose boot: 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.1-STABLE #5: Mon Nov 8 18:16:16 MST 2010 root@u205.airwired.net:/usr/obj/usr/src/sys/DKA i386 Preloaded elf kernel "/boot/kernel/kernel" at 0xc0dfb000. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1828760164 Hz CPU: Genuine Intel(R) CPU T2400 @ 1.83GHz (1828.76-MHz = 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x6e8 Family =3D 6 Model =3D e = Stepping =3D 8 = Features=3D0xbfe9fbff Features2=3D0xc1a9 AMD Features=3D0x100000 TSC: P-state invariant Instruction TLB: 4 KB Pages, 4-way set associative, 128 entries Data TLB: 4 KB Pages, 4-way set associative, 128 entries Instruction TLB: 4 MB pages, fully associative, 2 entries 2nd-level cache: 2-MB, 8-way set associative, 64-byte line size 1st-level instruction cache: 32 KB, 8-way set associative, 64 byte line = size Data TLB: 4 MB Pages, 4-way set associative, 8 entries 1st-level data cache: 32 KB, 8-way set associative, 64 byte line size L2 cache: 2048 kbytes, 8-way associative, 64 bytes/line real memory =3D 1073741824 (1024 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000001026000 - 0x000000003e579fff, 1028997120 bytes (251220 pages) avail memory =3D 1027784704 (980 MB) x86bios: IVT 0x000000-0x0004ff at 0xc0000000 x86bios: SSEG 0x010000-0x01ffff at 0xc3f92000 x86bios: EBDA 0x09f000-0x09ffff at 0xc009f000 x86bios: ROM 0x0a0000-0x0effff at 0xc00a0000 bios32: Found BIOS32 Service Directory header at 0xc00f02b0 bios32: Entry =3D 0xfc229 (c00fc229) Rev =3D 0 Len =3D 1 pcibios: PCI BIOS entry at 0xf0000+0xd27d pnpbios: Found PnP BIOS data at 0xc00f0960 pnpbios: Entry =3D f0000:9106 Rev =3D 1.0 pnpbios: Event flag at 510 pnpbios: OEM ID 193df351 Other BIOS signatures found: ULE: setup cpu 0 wlan: <802.11 Link Layer> kbd: new array size 4 kbd1 at kbdmux0 nfslock: pseudo-device mem: Pentium Pro MTRR support enabled null: io: random: ACPI: RSDP 0xf01e0 00014 (v00 TOSHIB) ACPI: RSDT 0x3f7a0000 00038 (v01 TOSHIB 750 00970814 TASM 04010000) ACPI: FACP 0x3f7a0068 00084 (v02 TOSHIB 750 20030101 TASM 04010000) ACPI: DSDT 0x3f7a00ec 05030 (v01 TOSHIB A0044 20060301 MSFT 0100000E) ACPI: FACS 0xeee00 00040 ACPI: SSDT 0x3f7a511c 00306 (v01 TOSHIB A0044 20050926 MSFT 0100000E) ACPI: APIC 0x3f7a5cd4 00068 (v01 TOSHIB 750 00970814 TASM 04010000) ACPI: MCFG 0x3f7a5d3c 0003C (v01 TOSHIB 750 00970814 TASM 04010000) ACPI: HPET 0x3f7a5dac 00038 (v01 TOSHIB 750 00970814 TASM 04010000) npx0: INT 16 interface acpi0: on motherboard PCIe: Memory Mapped configuration base @ 0xf0000000 pcibios: BIOS version 2.10 acpi0: [MPSAFE] acpi0: [ITHREAD] ACPI: Actual Package length (12) is larger than NumElements field (3), = truncated acpi0: Power Button (fixed) acpi0: wakeup code va 0xc3f91000 pa 0x1000 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.FNC0.ICH3 -> bus 0 dev 31 func 0 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 3f6a0000 (3) failed ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/2 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xd808-0xd80b on acpi0 cpu0: on acpi0 ACPI: SSDT 0x3f7a5764 000F3 (v01 TOSHIB A0044 20050623 MSFT 0100000E) ACPI: SSDT 0x3f7a58cd 0034E (v01 TOSHIB A0044 20050916 MSFT 0100000E) pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 10 Validation 0 10 N 0 10 After Disable 0 255 N 0 10 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 11 Validation 0 11 N 0 3 4 5 6 7 11 After Disable 0 255 N 0 3 4 5 6 7 11 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 11 Validation 0 11 N 0 3 4 5 6 7 11 After Disable 0 255 N 0 3 4 5 6 7 11 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 11 Validation 0 11 N 0 3 4 5 6 7 11 After Disable 0 255 N 0 3 4 5 6 7 11 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 11 Validation 0 11 N 0 3 4 5 6 7 11 After Disable 0 255 N 0 3 4 5 6 7 11 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 11 Validation 0 11 N 0 3 4 5 6 7 11 After Disable 0 255 N 0 3 4 5 6 7 11 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 11 Validation 0 11 N 0 3 4 5 6 7 11 After Disable 0 255 N 0 3 4 5 6 7 11 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 11 Validation 0 11 N 0 3 4 5 6 7 11 After Disable 0 255 N 0 3 4 5 6 7 11 acpi_hpet0: iomem 0xfed00000-0xfed003ff on = acpi0 acpi_hpet0: vend: 0x8086 rev: 0x1 num: 3 hz: 14318180 opts: legacy_route = 64-bit Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 ACPI: Found matching pin for 0.2.INTA at func 0: 10 ACPI: Found matching pin for 0.27.INTA at func 0: 11 ACPI: Found matching pin for 0.28.INTA at func 0: 11 ACPI: Found matching pin for 0.28.INTC at func 2: 11 ACPI: Found matching pin for 0.29.INTA at func 0: 11 ACPI: Found matching pin for 0.29.INTB at func 1: 11 ACPI: Found matching pin for 0.29.INTC at func 2: 11 ACPI: Found matching pin for 0.29.INTD at func 3: 10 ACPI: Found matching pin for 0.31.INTB at func 2: 11 pci0: on pcib0 pci0: domain=3D0, physical bus=3D0 found-> vendor=3D0x8086, dev=3D0x27a0, revid=3D0x03 domain=3D0, bus=3D0, slot=3D0, func=3D0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0006, statreg=3D0x2090, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) found-> vendor=3D0x8086, dev=3D0x27a2, revid=3D0x03 domain=3D0, bus=3D0, slot=3D2, func=3D0 class=3D03-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0007, statreg=3D0x0090, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) intpin=3Da, irq=3D10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 32, base 0xffd80000, size 19, = enabled map[14]: type I/O Port, range 32, base 0xcff8, size 3, enabled map[18]: type Prefetchable Memory, range 32, base 0xe0000000, = size 28, enabled map[1c]: type Memory, range 32, base 0xffd40000, size 18, = enabled pcib0: matched entry for 0.2.INTA (src \\_SB_.LNKA:0) pcib0: slot 2 INTA routed to irq 10 via \\_SB_.LNKA found-> vendor=3D0x8086, dev=3D0x27a6, revid=3D0x03 domain=3D0, bus=3D0, slot=3D2, func=3D1 class=3D03-80-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0007, statreg=3D0x0090, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xffc80000, size 19, = enabled found-> vendor=3D0x8086, dev=3D0x27d8, revid=3D0x02 domain=3D0, bus=3D0, slot=3D27, func=3D0 class=3D04-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0006, statreg=3D0x0010, cachelnsz=3D8 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xffd3c000, size 14, = enabled pcib0: matched entry for 0.27.INTA (src \\_SB_.LNKG:0) pcib0: slot 27 INTA routed to irq 11 via \\_SB_.LNKG found-> vendor=3D0x8086, dev=3D0x27d0, revid=3D0x02 domain=3D0, bus=3D0, slot=3D28, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D8 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA (src \\_SB_.LNKB:0) pcib0: slot 28 INTA routed to irq 11 via \\_SB_.LNKB found-> vendor=3D0x8086, dev=3D0x27d4, revid=3D0x02 domain=3D0, bus=3D0, slot=3D28, func=3D2 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D8 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) intpin=3Dc, irq=3D11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTC (src \\_SB_.LNKC:0) pcib0: slot 28 INTC routed to irq 11 via \\_SB_.LNKC found-> vendor=3D0x8086, dev=3D0x27c8, revid=3D0x02 domain=3D0, bus=3D0, slot=3D29, func=3D0 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) intpin=3Da, irq=3D11 map[20]: type I/O Port, range 32, base 0xcf80, size 5, enabled pcib0: matched entry for 0.29.INTA (src \\_SB_.LNKH:0) pcib0: slot 29 INTA routed to irq 11 via \\_SB_.LNKH unknown: Reserved 0x20 bytes for rid 0x20 type 4 at 0xcf80 found-> vendor=3D0x8086, dev=3D0x27c9, revid=3D0x02 domain=3D0, bus=3D0, slot=3D29, func=3D1 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) intpin=3Db, irq=3D11 map[20]: type I/O Port, range 32, base 0xcf60, size 5, enabled pcib0: matched entry for 0.29.INTB (src \\_SB_.LNKD:0) pcib0: slot 29 INTB routed to irq 11 via \\_SB_.LNKD unknown: Reserved 0x20 bytes for rid 0x20 type 4 at 0xcf60 found-> vendor=3D0x8086, dev=3D0x27ca, revid=3D0x02 domain=3D0, bus=3D0, slot=3D29, func=3D2 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) intpin=3Dc, irq=3D11 map[20]: type I/O Port, range 32, base 0xcf40, size 5, enabled pcib0: matched entry for 0.29.INTC (src \\_SB_.LNKC:0) pcib0: slot 29 INTC routed to irq 11 via \\_SB_.LNKC unknown: Reserved 0x20 bytes for rid 0x20 type 4 at 0xcf40 found-> vendor=3D0x8086, dev=3D0x27cb, revid=3D0x02 domain=3D0, bus=3D0, slot=3D29, func=3D3 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) intpin=3Dd, irq=3D10 map[20]: type I/O Port, range 32, base 0xcf20, size 5, enabled pcib0: matched entry for 0.29.INTD (src \\_SB_.LNKA:0) pcib0: slot 29 INTD routed to irq 10 via \\_SB_.LNKA unknown: Reserved 0x20 bytes for rid 0x20 type 4 at 0xcf20 found-> vendor=3D0x8086, dev=3D0x27cc, revid=3D0x02 domain=3D0, bus=3D0, slot=3D29, func=3D7 class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0006, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xffd3bc00, size 10, = enabled pcib0: matched entry for 0.29.INTA (src \\_SB_.LNKH:0) pcib0: slot 29 INTA routed to irq 11 via \\_SB_.LNKH unknown: Reserved 0x400 bytes for rid 0x10 type 3 at 0xffd3bc00 found-> vendor=3D0x8086, dev=3D0x2448, revid=3D0xe2 domain=3D0, bus=3D0, slot=3D30, func=3D0 class=3D06-04-01, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) found-> vendor=3D0x8086, dev=3D0x27b9, revid=3D0x02 domain=3D0, bus=3D0, slot=3D31, func=3D0 class=3D06-01-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0007, statreg=3D0x0210, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) found-> vendor=3D0x8086, dev=3D0x27c4, revid=3D0x02 domain=3D0, bus=3D0, slot=3D31, func=3D2 class=3D01-01-80, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x02b8, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) intpin=3Db, irq=3D11 powerspec 2 supports D0 D3 current D0 map[20]: type I/O Port, range 32, base 0xafa0, size 4, enabled pcib0: matched entry for 0.31.INTB (src \\_SB_.LNKD:0) pcib0: slot 31 INTB routed to irq 11 via \\_SB_.LNKD vgapci0: port 0xcff8-0xcfff mem = 0xffd80000-0xffdfffff,0xe0000000-0xefffffff,0xffd40000-0xffd7ffff irq 10 = at device 2.0 on pci0 agp0: on vgapci0 vgapci0: Reserved 0x10000000 bytes for rid 0x18 type 3 at 0xe0000000 vgapci0: Reserved 0x80000 bytes for rid 0x10 type 3 at 0xffd80000 vgapci0: Reserved 0x40000 bytes for rid 0x1c type 3 at 0xffd40000 agp0: detected 7932k stolen memory agp0: aperture size is 256M vgapci1: mem 0xffc80000-0xffcfffff at device = 2.1 on pci0 pci0: at device 27.0 (no driver attached) pcib1: irq 11 at device 28.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xf000-0xfff pcib1: no prefetched decode pci1: on pcib1 pci1: domain=3D0, physical bus=3D1 pcib2: irq 11 at device 28.2 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xf000-0xfff pcib2: memory decode 0xffa00000-0xffafffff pcib2: no prefetched decode ACPI: Found matching pin for 2.0.INTA at func 0: 11 pci2: on pcib2 pci2: domain=3D0, physical bus=3D2 found-> vendor=3D0x8086, dev=3D0x4222, revid=3D0x02 domain=3D0, bus=3D2, slot=3D0, func=3D0 class=3D02-80-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0006, statreg=3D0x0010, cachelnsz=3D8 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xffaff000, size 12, = enabled pcib2: requested memory range 0xffaff000-0xffafffff: good pcib2: matched entry for 2.0.INTA (src \\_SB_.LNKC:0) pcib2: slot 0 INTA routed to irq 11 via \\_SB_.LNKC pci2: at device 0.0 (no driver attached) uhci0: port 0xcf80-0xcf9f irq = 11 at device 29.0 on pci0 uhci0: [MPSAFE] uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0xcf60-0xcf7f irq = 11 at device 29.1 on pci0 uhci1: [MPSAFE] uhci1: [ITHREAD] usbus1: on uhci1 uhci2: port 0xcf40-0xcf5f irq = 11 at device 29.2 on pci0 uhci2: [MPSAFE] uhci2: [ITHREAD] usbus2: on uhci2 uhci3: port 0xcf20-0xcf3f irq = 10 at device 29.3 on pci0 uhci3: [MPSAFE] uhci3: [ITHREAD] usbus3: on uhci3 ehci0: mem = 0xffd3bc00-0xffd3bfff irq 11 at device 29.7 on pci0 ehci0: [MPSAFE] ehci0: [ITHREAD] usbus4: EHCI version 1.0 usbus4: on ehci0 pcib3: at device 30.0 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 4 pcib3: I/O decode 0xb000-0xbfff pcib3: memory decode 0xff900000-0xff9fffff pcib3: no prefetched decode pcib3: Subtractively decoded bridge. ACPI: Found matching pin for 3.8.INTA at func 0: 11 ACPI: Found matching pin for 3.11.INTA at func 0: 255 ACPI: Found matching pin for 3.11.INTB at func 1: 11 ACPI: Found matching pin for 3.11.INTD at func 2: 11 pci3: on pcib3 pci3: domain=3D0, physical bus=3D3 found-> vendor=3D0x8086, dev=3D0x1092, revid=3D0x02 domain=3D0, bus=3D3, slot=3D8, func=3D0 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x0290, cachelnsz=3D8 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x08 (2000 ns), maxlat=3D0x38 = (14000 ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xff9ff000, size 12, = enabled pcib3: requested memory range 0xff9ff000-0xff9fffff: good map[14]: type I/O Port, range 32, base 0xbf40, size 6, enabled pcib3: requested I/O range 0xbf40-0xbf7f: in range pcib3: matched entry for 3.8.INTA (src \\_SB_.LNKE:0) pcib3: slot 8 INTA routed to irq 11 via \\_SB_.LNKE found-> vendor=3D0x104c, dev=3D0x8039, revid=3D0x00 domain=3D0, bus=3D3, slot=3D11, func=3D0 class=3D06-07-00, hdrtype=3D0x02, mfdev=3D1 cmdreg=3D0x0000, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x40 (16000 ns), maxlat=3D0x03= (750 ns) intpin=3Da, irq=3D255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0, size 12, memory disabled found-> vendor=3D0x104c, dev=3D0x803a, revid=3D0x00 domain=3D0, bus=3D3, slot=3D11, func=3D1 class=3D0c-00-10, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0006, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x02 (500 ns), maxlat=3D0x04 = (1000 ns) intpin=3Db, irq=3D11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xff9fe800, size 11, = enabled pcib3: requested memory range 0xff9fe800-0xff9fefff: good map[14]: type Memory, range 32, base 0xff9f8000, size 14, = enabled pcib3: requested memory range 0xff9f8000-0xff9fbfff: good pcib3: matched entry for 3.11.INTB (src \\_SB_.LNKE:0) pcib3: slot 11 INTB routed to irq 11 via \\_SB_.LNKE found-> vendor=3D0x104c, dev=3D0x803b, revid=3D0x00 domain=3D0, bus=3D3, slot=3D11, func=3D2 class=3D01-80-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0006, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x07 (1750 ns), maxlat=3D0x04 = (1000 ns) intpin=3Dd, irq=3D11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xff9fd000, size 12, = enabled pcib3: requested memory range 0xff9fd000-0xff9fdfff: good pcib3: matched entry for 3.11.INTD (src \\_SB_.LNKH:0) pcib3: slot 11 INTD routed to irq 11 via \\_SB_.LNKH found-> vendor=3D0x104c, dev=3D0x803c, revid=3D0x00 domain=3D0, bus=3D3, slot=3D11, func=3D3 class=3D08-05-01, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0006, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x07 (1750 ns), maxlat=3D0x04 = (1000 ns) intpin=3Dd, irq=3D11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xff9fe700, size 8, = enabled pcib3: requested memory range 0xff9fe700-0xff9fe7ff: good pcib3: matched entry for 3.11.INTD (src \\_SB_.LNKH:0) pcib3: slot 11 INTD routed to irq 11 via \\_SB_.LNKH fxp0: port 0xbf40-0xbf7f mem = 0xff9ff000-0xff9fffff irq 11 at device 8.0 on pci3 fxp0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xff9ff000 fxp0: using memory space register mapping fxp0: PCI IDs: 8086 1092 1179 0001 0002 fxp0: Dynamic Standby mode is enabled miibus0: on fxp0 inphy0: PHY 1 on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: bpf attached fxp0: Ethernet address: 00:0e:7b:30:ca:e5 fxp0: [MPSAFE] fxp0: [ITHREAD] cbb0: at device 11.0 on pci3 pcib3: cbb0 requested memory range 0x0-0xffffffff: good cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0x80000000 cbb0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x80000000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pcib3: matched entry for 3.11.INTA (src \\_SB_.LNKF:0) pcib3: slot 11 INTA routed to irq 11 via \\_SB_.LNKF cbb0: [MPSAFE] cbb0: [FILTER] cbb0: PCI Configuration space: 0x00: 0x8039104c 0x02100007 0x06070000 0x00824008=20 0x10: 0x80000000 0x020000a0 0x20040403 0xfffff000=20 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc=20 0x30: 0x00000000 0xfffffffc 0x00000000 0x0740010b=20 0x40: 0x00011179 0x00000001 0x00000000 0x00000000=20 0x50: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x60: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x70: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x80: 0x08009060 0x02130019 0x00070000 0x01aa1022=20 0x90: 0x606404c0 0x00000000 0x00000000 0x00000000=20 0xa0: 0x7e020001 0x00c00000 0x00000000 0x00000000=20 0xb0: 0x08000000 0x00000000 0x00000000 0x00000000=20 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xf0: 0x27852015 0xba019454 0x00000000 0x00000000=20 fwohci0: vendor=3D104c, dev=3D803a fwohci0: vendor=3D104c, dev=3D803a fwohci0: <1394 Open Host Controller Interface> mem = 0xff9fe800-0xff9fefff,0xff9f8000-0xff9fbfff irq 11 at device 11.1 on = pci3 fwohci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xff9fe800 fwohci0: [MPSAFE] fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=3D1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:00:39:00:00:96:6a:bb fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x1078000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:00:39:96:6a:bb fwe0: bpf attached fwe0: Ethernet address: 02:00:39:96:6a:bb fwip0: on firewire0 fwip0: bpf attached fwip0: Firewire address: 00:00:39:00:00:96:6a:bb @ 0xfffe00000000, S400, = maxrec 2048 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=3D0x00000000, SelfID Count=3D1, = CYCLEMASTER mode pci3: at device 11.2 (no driver attached) pci3: at device 11.3 (no driver = attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port = 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xafa0-0xafaf irq 11 at device 31.2 = on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xafa0 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D00 ata0: stat0=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata0: stat1=3D0x00 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata0: reset tp2 stat0=3D50 stat1=3D00 devices=3D0x1 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D00 ata1: stat0=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata1: stat1=3D0x00 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata1: reset tp2 stat0=3D00 stat1=3D00 devices=3D0x10000 ata1: [MPSAFE] ata1: [ITHREAD] acpi_lid0: on acpi0 battery0: on acpi0 acpi_button0: on acpi0 acpi_acad0: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0047 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model GlidePoint, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us) ex_isa_identify() pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff ahc_isa_probe 14: ioport 0xec00 alloc failed isa_probe_children: disabling PnP devices pmtimer0 on isa0 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it sc: sc0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcffff,0xe0000-0xeffff pnpid = ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on = isa0 fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 ppc0: parallel port not found. ppc0: failed to probe at irq 7 on isa0 uart0: failed to probe at port 0x3f8-0x3ff irq 4 on isa0 uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 isa_probe_children: probing PnP devices est0: on cpu0 p4tcc0: on cpu0 Device configuration finished. procfs registered Timecounter "TSC" frequency 1828760164 Hz quality 800 Timecounters tick every 1.000 msec vlan: initialized, using hash tables with chaining firewire0: 1 nodes, maxhop <=3D 0 cable IRM irm(0) (me)=20 firewire0: bus manager 0=20 lo0: bpf attached ata0: Identifying devices: 00000001 ata0: New devices: 00000001 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 battery0: battery initialization start battery0: battery initialization done, tried 1 times acpi_acad0: acline initialization start acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times ata0-master: pio=3DPIO4 wdma=3DWDMA2 udma=3DUDMA100 cable=3D40 wire ad0: setting UDMA100 ad0: 114473MB at ata0-master UDMA100 SATA ad0: 234441648 sectors [232581C/16H/63S] 16 sectors/interrupt 1 depth = queue GEOM: new disk ad0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered ad0: Intel check1 failed ad0: Adaptec check1 failed ad0: LSI (v3) check1 failed ad0: LSI (v2) check1 failed ad0: FreeBSD check1 failed ata1: Identifying devices: 00010000 ata1: New devices: 00010000 ata1-master: pio=3DPIO4 wdma=3DWDMA2 udma=3DUDMA33 cable=3D40 wire acd0: setting UDMA33 acd0: DVDR drive at ata1 as master acd0: read 4134KB/s (4134KB/s) write 4134KB/s (4134KB/s), 2048KB buffer, = UDMA33=20 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, DVDR, DVDRAM, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ATA PseudoRAID loaded Root mount waiting for: usbus4 Root mount waiting for: usbus4 Root mount waiting for: usbus4 uhub4: 8 ports with 8 removable, self powered Root mount waiting for: usbus4 Trying to mount root from ufs:/dev/ad0s2a ct_to_ts([2010-11-08 20:02:37]) =3D 1289246557.000000000 start_init: trying /sbin/init ugen1.2: at usbus1 --- kenv | fgrep hint.acpi: hint.acpi.0.oem=3D"TOSHIB" hint.acpi.0.revision=3D"1" hint.acpi.0.rsdp=3D"0xf01e0" hint.acpi.0.rsdt=3D"0x3f7a0000" --- kernel config residing at /usr/src/sys/i386/conf/DKA: # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the config(5) manual = page, # and/or the handbook section on Kernel Configuration Files: # # = http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-con= fig.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check = first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.519.2.12 2010/10/25 07:58:37 = avg Exp $ cpu I686_CPU ident DKA # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for = devices. # Use the following to compile in values accessible to the kernel # through getenv() (or kenv(1) in userland). The format of the file # is 'variable=3Dvalue', see kenv(1) # # env "GENERIC.env" #makeoptions DEBUG=3D-g # Build kernel with gdb(1) debug = symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread = 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 NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFSLOCKD # Network Lock Manager options NFS_ROOT # NFS usable as /, requires = NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires = PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat (sgtty) 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=3D5000 # Delay (in ms) before = probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support 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 PRINTF_BUFR_SIZE=3D128 # Prevent printf output being = interspersed. options KBD_INSTALL_CDEV # install a CDEV entry in /dev 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 KDTRACE_HOOKS # Kernel DTrace hooks options INCLUDE_CONFIG_FILE # Include this file in kernel options KDB # Kernel debugger related code options KDB_TRACE # Print a stack trace for a = panic # To make an SMP kernel, the next two lines are needed options SMP # Symmetric MultiProcessor = Kernel device apic # I/O APIC # CPU frequency control device cpufreq # Bus support. device acpi device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers device ahb # EISA AHA1742 family device ahc # AHA2940 and onboard AIC7xxx devices #options AHC_REG_PRETTY_PRINT # Print register bitfields in = debug # output. Adds ~128k to driver. device ahd # AHA39320/29320 and onboard AIC79xx = devices #options AHD_REG_PRETTY_PRINT # Print register bitfields in = debug # output. Adds ~215k to driver. device amd # AMD 53C974 (Tekram DC-390(T)) #device hptiop # Highpoint RocketRaid 3xxx series device isp # Qlogic family #device ispfw # Firmware for QLogic HBAs- normally a = module #device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic #device sym # NCR/Symbios Logic (newer chipsets + = those of `ncr') device trm # Tekram DC395U/UW/F DC315U adapters #device adv # Advansys SCSI adapters #device adw # Advansys wide SCSI adapters device aha # Adaptec 154x SCSI adapters device aic # Adaptec 15[012]x SCSI adapters, = AIC-6[23]60. #device bt # Buslogic/Mylex MultiMaster SCSI = adapters device ncv # NCR 53C500 device nsp # Workbit Ninja SCSI-3 device stg # TMC 18C30/18C50 # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI = access) device ses # SCSI Environmental Services (and = SAF-TE) # RAID controllers interfaced to the SCSI subsystem #device amr # AMI MegaRAID #device arcmsr # Areca SATA II RAID #device asr # DPT SmartRAID V, VI and Adaptec SCSI = RAID device ciss # Compaq Smart RAID 5* #device dpt # DPT Smartcache III, IV - See NOTES for = options #device hptmv # Highpoint RocketRAID 182x #device hptrr # Highpoint RocketRAID 17xx, 22xx, 23xx, = 25xx device iir # Intel Integrated RAID device ips # IBM (Adaptec) ServeRAID #device mly # Mylex AcceleRAID/eXtremeRAID #device twa # 3ware 9000 series PATA/SATA RAID # RAID controllers device aac # Adaptec FSA RAID device aacp # SCSI passthrough for aac (requires = CAM) device ida # Compaq Smart RAID #device mfi # LSI MegaRAID SAS #device mlx # Mylex DAC960 family #device pst # Promise Supertrak SX6000 #device twe # 3ware ATA RAID # 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 kbdmux # keyboard multiplexer 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 # 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 uart # Generic UART driver # 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 # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to sio, uart and/or ppc drivers): #device puc # PCI Ethernet NICs. device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel PRO/1000 Gigabit Ethernet Family device igb # Intel PRO/1000 PCIE Server Gigabit = Family device ixgb # Intel PRO/10GbE Ethernet Card #device le # AMD Am7900 LANCE and Am79C9xx PCnet #device ti # Alteon Networks Tigon I/II gigabit = Ethernet #device txp # 3Com 3cR990 (``Typhoon'') #device vx # 3Com 3c590, 3c595 (``Vortex'') # 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 ae # Attansic/Atheros L2 FastEthernet #device age # Attansic/Atheros L1 Gigabit Ethernet #device alc # Atheros AR8131/AR8132 Ethernet #device ale # Atheros AR8121/AR8113/AR8114 Ethernet device bce # Broadcom BCM5706/BCM5708 Gigabit = Ethernet device bfe # Broadcom BCM440x 10/100 Ethernet device bge # Broadcom BCM570xx Gigabit Ethernet device dc # DEC/Intel 21143 and various workalikes #device et # Agere ET1310 10/100/Gigabit Ethernet device fxp # Intel EtherExpress PRO/100B (82557, = 82558) #device jme # JMicron JMC250 Gigabit/JMC260 Fast = Ethernet device lge # Level 1 LXT1001 gigabit Ethernet device msk # Marvell/SysKonnect Yukon II Gigabit = Ethernet device nfe # nVidia nForce MCP on-board Ethernet #device nge # NatSemi DP83820 gigabit Ethernet #device nve # nVidia nForce MCP on-board Ethernet = Networking #device pcn # AMD Am79C97x PCI 10/100 (precedence = over 'le') device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 device sf # Adaptec AIC-6915 (``Starfire'') #device sge # Silicon Integrated Systems SiS190/191 #device sis # Silicon Integrated Systems SiS 900/SiS = 7016 #device sk # SysKonnect SK-984x & SK-982x gigabit = Ethernet #device ste # Sundance ST201 (D-Link DFE-550TX) #device stge # Sundance/Tamarack TC9021 gigabit = Ethernet device tl # Texas Instruments ThunderLAN device tx # SMC EtherPower II (83c170 ``EPIC'') device vge # VIA VT612x gigabit Ethernet device vr # VIA Rhine, Rhine II #device wb # Winbond W89C840F device xl # 3Com 3c90x (``Boomerang'', = ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' device ed # NE[12]000, SMC Ultra, 3c503, DS8390 = cards device ex # Intel EtherExpress Pro/10 and Pro/10+ device ep # Etherlink III based cards device fe # Fujitsu MB8696x based cards device ie # EtherExpress 8/16, 3C507, StarLAN 10 = etc. device sn # SMC's 9000 series of Ethernet chips device xe # Xircom pccard Ethernet # Wireless NIC cards device wlan # 802.11 support options IEEE80211_DEBUG # enable debug msgs options IEEE80211_AMPDU_AGE # age frames in AMPDU reorder q's options IEEE80211_SUPPORT_MESH # enable 802.11s draft 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 device an # Aironet 4500/4800 802.11 wireless = NICs. device ath # Atheros pci/cardbus NIC's device ath_hal # pci/cardbus chip support options AH_SUPPORT_AR5416 # enable AR5416 tx/rx = descriptors device ath_rate_sample # SampleRate tx rate control for ath #device ral # Ralink Technology RT2500 wireless = NICs. device wi # WaveLAN/Intersil/Symbol 802.11 = wireless NICs. #device wl # Older non 802.11 Wavelan wireless NIC. # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device vlan # 802.1Q VLAN support device tun # Packet tunnel. device pty # BSD-style compatibility pseudo ttys device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module # 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 options USB_DEBUG # enable debug msgs 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) #device udbp # USB Double Bulk Pipe devices device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus = and da device ums # Mouse #device urio # Diamond Rio 500 MP3 player # USB Serial devices device u3g # USB-based 3G modems (Option, Huawei, = Sierra) #device uark # Technologies ARK3116 based serial = adapters device ubsa # Belkin F5U103 and compatible serial = adapters #device uftdi # For FTDI usb serial adapters #device uipaq # Some WinCE based devices #device uplcom # Prolific PL-2303 serial adapters #device uslcom # SI Labs CP2101/CP2102 serial adapters #device uvisor # Visor and Palm devices #device uvscom # USB serial support for DDI pocket's = PHS # USB Ethernet, requires miibus device aue # ADMtek USB Ethernet device axe # ASIX Electronics USB Ethernet device cdce # Generic USB over Ethernet #device cue # CATC USB Ethernet #device kue # Kawasaki LSI USB Ethernet #device rue # RealTek RTL8150 USB Ethernet #device udav # Davicom DM9601E USB # USB Wireless #device rum # Ralink Technology RT2501USB wireless = NICs device uath # Atheros AR5523 wireless NICs #device ural # Ralink Technology RT2500USB wireless = NICs #device zyd # ZyDAS zb1211/zb1211b wireless NICs # FireWire support device firewire # FireWire bus code #device sbp # SCSI over FireWire (Requires scbus and = da) device fwe # Ethernet over FireWire (non-standard!) device fwip # IP over FireWire (RFC 2734,3146) device dcons # Dumb console driver device dcons_crom # Configuration ROM for dcons --- x86info -a output: x86info v1.27. Dave Jones 2001-2010 Feedback to . Found 1 CPU = --------------------------------------------------------------------------= EFamily: 0 EModel: 0 Family: 6 Model: 14 Stepping: 8 CPU Model: Unknown model.=20 Processor name string: Genuine Intel(R) CPU T2400 @ 1.83GHz Type: 0 (Original OEM) Brand: 0 (Unsupported) Siblings: 1 Physical Processor ID: 0 Processor Core ID: 0 eax in: 0x00000000, eax =3D 0000000a ebx =3D 756e6547 ecx =3D 6c65746e = edx =3D 49656e69 eax in: 0x00000001, eax =3D 000006e8 ebx =3D 00020800 ecx =3D 0000c1a9 = edx =3D bfe9fbff eax in: 0x00000002, eax =3D 02b3b001 ebx =3D 000000f0 ecx =3D 00000000 = edx =3D 2c04307d eax in: 0x00000003, eax =3D 00000000 ebx =3D 00000000 ecx =3D 00000000 = edx =3D 00000000 eax in: 0x00000004, eax =3D 04000121 ebx =3D 01c0003f ecx =3D 0000003f = edx =3D 00000001 eax in: 0x00000005, eax =3D 00000040 ebx =3D 00000040 ecx =3D 00000003 = edx =3D 00022220 eax in: 0x00000006, eax =3D 00000001 ebx =3D 00000002 ecx =3D 00000001 = edx =3D 00000000 eax in: 0x00000007, eax =3D 00000000 ebx =3D 00000000 ecx =3D 00000000 = edx =3D 00000000 eax in: 0x00000008, eax =3D 00000000 ebx =3D 00000000 ecx =3D 00000000 = edx =3D 00000000 eax in: 0x00000009, eax =3D 00000000 ebx =3D 00000000 ecx =3D 00000000 = edx =3D 00000000 eax in: 0x0000000a, eax =3D 07280201 ebx =3D 00000000 ecx =3D 00000000 = edx =3D 00000000 eax in: 0x80000000, eax =3D 80000008 ebx =3D 00000000 ecx =3D 00000000 = edx =3D 00000000 eax in: 0x80000001, eax =3D 00000000 ebx =3D 00000000 ecx =3D 00000000 = edx =3D 00100000 eax in: 0x80000002, eax =3D 756e6547 ebx =3D 20656e69 ecx =3D 65746e49 = edx =3D 2952286c eax in: 0x80000003, eax =3D 55504320 ebx =3D 20202020 ecx =3D 20202020 = edx =3D 54202020 eax in: 0x80000004, eax =3D 30303432 ebx =3D 20402020 ecx =3D 33382e31 = edx =3D 007a4847 eax in: 0x80000005, eax =3D 00000000 ebx =3D 00000000 ecx =3D 00000000 = edx =3D 00000000 eax in: 0x80000006, eax =3D 00000000 ebx =3D 00000000 ecx =3D 08006040 = edx =3D 00000000 eax in: 0x80000007, eax =3D 00000000 ebx =3D 00000000 ecx =3D 00000000 = edx =3D 00000000 eax in: 0x80000008, eax =3D 00002020 ebx =3D 00000000 ecx =3D 00000000 = edx =3D 00000000 Cache info L1 Instruction cache: 32KB, 8-way associative. 64 byte line size. L1 Data cache: 32KB, 8-way associative. 64 byte line size. L2 cache: 2MB, 8-way associative. 64 byte line size. TLB info Instruction TLB: 4K pages, 4-way associative, 128 entries. Instruction TLB: 4MB pages, fully associative, 2 entries Data TLB: 4K pages, 4-way associative, 128 entries. Data TLB: 4MB pages, 4-way associative, 8 entries 64 byte prefetching. Feature flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat = clflsh ds acpi mmx fxsr sse sse2 ss ht tm pbe sse3 monitor vmx est tm2 = xTPR pdcm Extended feature flags: xd dts 1.85GHz processor (estimate). Summary: Total processor threads: 1 This system has 1 processor running at an estimated 1.85GHz From owner-freebsd-stable@FreeBSD.ORG Tue Nov 9 14:24:55 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 10D03106564A for ; Tue, 9 Nov 2010 14:24:55 +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 4CABB8FC14 for ; Tue, 9 Nov 2010 14:24:53 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA25972; Tue, 09 Nov 2010 16:24:34 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4CD959A1.2030502@icyb.net.ua> Date: Tue, 09 Nov 2010 16:24:33 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Dan Allen References: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> <4CD11FE9.8050105@freebsd.org> <5224E1F5-4567-45A8-A12C-868F7B45BC21@airwired.net> <4CD42127.5070902@icyb.net.ua> <4B3E11D5-3909-4F27-8598-EA4BFB0A2B26@airwired.net> In-Reply-To: <4B3E11D5-3909-4F27-8598-EA4BFB0A2B26@airwired.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sergey Kandaurov , FreeBSD-STABLE Mailing List , Jeremy Chadwick Subject: Re: Missing CPU Debug Output X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Nov 2010 14:24:55 -0000 on 09/11/2010 16:00 Dan Allen said the following: > This very long email contains the non-zipped versions of the four debug files requested. The archive reached me successfully because I was in To/Cc, but it was stripped by mailing list software. BTW, instead of very long emails it's better to upload files and provide links to them. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Nov 9 15:11: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 6E4E31065670 for ; Tue, 9 Nov 2010 15:11:35 +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 AE5EF8FC0A for ; Tue, 9 Nov 2010 15:11:34 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA26748; Tue, 09 Nov 2010 17:11:06 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4CD9648A.2080606@icyb.net.ua> Date: Tue, 09 Nov 2010 17:11:06 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Dan Allen References: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> <4CD11FE9.8050105@freebsd.org> <5224E1F5-4567-45A8-A12C-868F7B45BC21@airwired.net> <4CD42127.5070902@icyb.net.ua> <4CD8DC87.3090207@icyb.net.ua> <24FCCE4A-C7C2-4EDE-9521-3D562391ACE4@airwired.net> In-Reply-To: <24FCCE4A-C7C2-4EDE-9521-3D562391ACE4@airwired.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sergey Kandaurov , FreeBSD-STABLE Mailing List Subject: Re: Fatal trap 18 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Nov 2010 15:11:35 -0000 on 09/11/2010 15:55 Dan Allen said the following: > > On 8 Nov 2010, at 10:30 PM, Andriy Gapon wrote: > >> Can you please also provide the following output: >> $ kenv | fgrep hint.acpi > > hint.acpi.0.oem="TOSHIB" > hint.acpi.0.revision="1" > hint.acpi.0.rsdp="0xf01e0" > hint.acpi.0.rsdt="0x3f7a0000" Two more things: - sysctl machdep.acpi_root - /boot/loader.conf contents -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Nov 9 15: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 04B8E106564A for ; Tue, 9 Nov 2010 15:21:44 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id B977F8FC08 for ; Tue, 9 Nov 2010 15:21:43 +0000 (UTC) Received: (qmail 6514 invoked by uid 89); 9 Nov 2010 15:21:42 -0000 Received: from unknown (HELO ?192.168.0.18?) (danallen46@airwired.net@66.29.174.6) by mail.utahbroadband.com with ESMTPA; 9 Nov 2010 15:21:42 -0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Dan Allen In-Reply-To: <4CD9648A.2080606@icyb.net.ua> Date: Tue, 9 Nov 2010 08:21:40 -0700 Content-Transfer-Encoding: 7bit Message-Id: <188B93B6-D96C-47BE-84DE-8459C8C0CCBF@airwired.net> References: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> <4CD11FE9.8050105@freebsd.org> <5224E1F5-4567-45A8-A12C-868F7B45BC21@airwired.net> <4CD42127.5070902@icyb.net.ua> <4CD8DC87.3090207@icyb.net.ua> <24FCCE4A-C7C2-4EDE-9521-3D562391ACE4@airwired.net> <4CD9648A.2080606@icyb.net.ua> To: Andriy Gapon X-Mailer: Apple Mail (2.1081) Cc: Sergey Kandaurov , FreeBSD-STABLE Mailing List Subject: Re: Fatal trap 18 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Nov 2010 15:21:44 -0000 On 9 Nov 2010, at 8:11 AM, Andriy Gapon wrote: > - sysctl machdep.acpi_root machdep.acpi_root: 983520 From owner-freebsd-stable@FreeBSD.ORG Tue Nov 9 15:22: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 ADBC9106564A for ; Tue, 9 Nov 2010 15:22:59 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id 6E3DA8FC22 for ; Tue, 9 Nov 2010 15:22:59 +0000 (UTC) Received: (qmail 7339 invoked by uid 89); 9 Nov 2010 15:22:58 -0000 Received: from unknown (HELO ?192.168.0.18?) (danallen46@airwired.net@66.29.174.6) by mail.utahbroadband.com with ESMTPA; 9 Nov 2010 15:22:58 -0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Dan Allen In-Reply-To: <4CD9648A.2080606@icyb.net.ua> Date: Tue, 9 Nov 2010 08:22:54 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> <4CD11FE9.8050105@freebsd.org> <5224E1F5-4567-45A8-A12C-868F7B45BC21@airwired.net> <4CD42127.5070902@icyb.net.ua> <4CD8DC87.3090207@icyb.net.ua> <24FCCE4A-C7C2-4EDE-9521-3D562391ACE4@airwired.net> <4CD9648A.2080606@icyb.net.ua> To: Andriy Gapon X-Mailer: Apple Mail (2.1081) Cc: Sergey Kandaurov , FreeBSD-STABLE Mailing List Subject: Re: Fatal trap 18 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Nov 2010 15:22:59 -0000 On 9 Nov 2010, at 8:11 AM, Andriy Gapon wrote: > /boot/loader.conf contents This might be the smoking gun! cat loader.conf: hint.apic.0.disabled="1" Dan From owner-freebsd-stable@FreeBSD.ORG Tue Nov 9 15:25: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 0A390106566C for ; Tue, 9 Nov 2010 15:25:29 +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 4E6ED8FC0A for ; Tue, 9 Nov 2010 15:25:28 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA27035; Tue, 09 Nov 2010 17:24:59 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4CD967CB.5090201@icyb.net.ua> Date: Tue, 09 Nov 2010 17:24:59 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Dan Allen References: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> <4CD11FE9.8050105@freebsd.org> <5224E1F5-4567-45A8-A12C-868F7B45BC21@airwired.net> <4CD42127.5070902@icyb.net.ua> <4CD8DC87.3090207@icyb.net.ua> <24FCCE4A-C7C2-4EDE-9521-3D562391ACE4@airwired.net> <4CD9648A.2080606@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sergey Kandaurov , FreeBSD-STABLE Mailing List Subject: Re: Fatal trap 18 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Nov 2010 15:25:29 -0000 on 09/11/2010 17:22 Dan Allen said the following: > > On 9 Nov 2010, at 8:11 AM, Andriy Gapon wrote: > >> /boot/loader.conf contents > > This might be the smoking gun! > > cat loader.conf: > > hint.apic.0.disabled="1" Yes, it is. So why do you have it and what happens if you remove it? -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Nov 9 15:59: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 3437B106564A for ; Tue, 9 Nov 2010 15:59:34 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id E720C8FC0A for ; Tue, 9 Nov 2010 15:59:33 +0000 (UTC) Received: (qmail 7360 invoked by uid 89); 9 Nov 2010 15:59:33 -0000 Received: from unknown (HELO ?192.168.0.18?) (danallen46@airwired.net@66.29.174.6) by mail.utahbroadband.com with ESMTPA; 9 Nov 2010 15:59:33 -0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Dan Allen In-Reply-To: <4CD967CB.5090201@icyb.net.ua> Date: Tue, 9 Nov 2010 08:59:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <817835F0-91C1-4945-917A-9C582C4FDFF6@airwired.net> References: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> <4CD11FE9.8050105@freebsd.org> <5224E1F5-4567-45A8-A12C-868F7B45BC21@airwired.net> <4CD42127.5070902@icyb.net.ua> <4CD8DC87.3090207@icyb.net.ua> <24FCCE4A-C7C2-4EDE-9521-3D562391ACE4@airwired.net> <4CD9648A.2080606@icyb.net.ua> <4CD967CB.5090201@icyb.net.ua> To: Andriy Gapon X-Mailer: Apple Mail (2.1081) Cc: Sergey Kandaurov , FreeBSD-STABLE Mailing List Subject: Re: Fatal trap 18 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Nov 2010 15:59:34 -0000 On 9 Nov 2010, at 8:24 AM, Andriy Gapon wrote: > on 09/11/2010 17:22 Dan Allen said the following: >>=20 >> On 9 Nov 2010, at 8:11 AM, Andriy Gapon wrote: >>=20 >>> /boot/loader.conf contents >>=20 >> This might be the smoking gun! >>=20 >> cat loader.conf: >>=20 >> hint.apic.0.disabled=3D"1" >=20 > Yes, it is. > So why do you have it and what happens if you remove it? Well, there is good news and bad news. The good news is that if I remove this hint the machine boots with 2 = CPUs. The bad news is that I get lots of: CPU0: local APIC error 0x40 CPU1: local APIC error 0x40 messages and the machine is very unresponsive. Every keystroke has a = second or two of delay. It really is unusable. If memory serves I had to turn off APIC in order to see both CPUs at = some time in the past. However, at some time in the past I had both = CPUs and did not have the severe unresponsiveness that I get without = this hint. So with APIC I get both CPUs but an unusable config. Without APIC I = have one CPU but things are lively. What next? Dan From owner-freebsd-stable@FreeBSD.ORG Tue Nov 9 16:08: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 2E486106566B for ; Tue, 9 Nov 2010 16:08:05 +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 6F6898FC0C for ; Tue, 9 Nov 2010 16:08:04 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA27733; Tue, 09 Nov 2010 18:07:30 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4CD971C2.1010506@icyb.net.ua> Date: Tue, 09 Nov 2010 18:07:30 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Dan Allen References: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> <4CD11FE9.8050105@freebsd.org> <5224E1F5-4567-45A8-A12C-868F7B45BC21@airwired.net> <4CD42127.5070902@icyb.net.ua> <4CD8DC87.3090207@icyb.net.ua> <24FCCE4A-C7C2-4EDE-9521-3D562391ACE4@airwired.net> <4CD9648A.2080606@icyb.net.ua> <4CD967CB.5090201@icyb.net.ua> <817835F0-91C1-4945-917A-9C582C4FDFF6@airwired.net> In-Reply-To: <817835F0-91C1-4945-917A-9C582C4FDFF6@airwired.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sergey Kandaurov , FreeBSD-STABLE Mailing List Subject: Re: Fatal trap 18 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Nov 2010 16:08:05 -0000 on 09/11/2010 17:59 Dan Allen said the following: > > On 9 Nov 2010, at 8:24 AM, Andriy Gapon wrote: > >> on 09/11/2010 17:22 Dan Allen said the following: >>> >>> On 9 Nov 2010, at 8:11 AM, Andriy Gapon wrote: >>> >>>> /boot/loader.conf contents >>> >>> This might be the smoking gun! >>> >>> cat loader.conf: >>> >>> hint.apic.0.disabled="1" >> >> Yes, it is. >> So why do you have it and what happens if you remove it? > > Well, there is good news and bad news. > > The good news is that if I remove this hint the machine boots with 2 CPUs. > > The bad news is that I get lots of: > > CPU0: local APIC error 0x40 > CPU1: local APIC error 0x40 > > messages and the machine is very unresponsive. Every keystroke has a second or two of delay. It really is unusable. > > If memory serves I had to turn off APIC in order to see both CPUs at some time in the past. However, at some time in the past I had both CPUs and did not have the severe unresponsiveness that I get without this hint. > > So with APIC I get both CPUs but an unusable config. Without APIC I have one CPU but things are lively. > > What next? Let's see if anybody else can help you with that stuff. My jurisdiction (area of expertise) ends here. Verbose dmesg will be useful in any case. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Nov 9 16:09: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 DDC371065674 for ; Tue, 9 Nov 2010 16:09:00 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id 9BAE18FC18 for ; Tue, 9 Nov 2010 16:09:00 +0000 (UTC) Received: (qmail 16686 invoked by uid 89); 9 Nov 2010 16:08:58 -0000 Received: from unknown (HELO ?192.168.0.18?) (danallen46@airwired.net@66.29.174.6) by mail.utahbroadband.com with ESMTPA; 9 Nov 2010 16:08:58 -0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Dan Allen In-Reply-To: <4CD971C2.1010506@icyb.net.ua> Date: Tue, 9 Nov 2010 09:08:57 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> <4CD11FE9.8050105@freebsd.org> <5224E1F5-4567-45A8-A12C-868F7B45BC21@airwired.net> <4CD42127.5070902@icyb.net.ua> <4CD8DC87.3090207@icyb.net.ua> <24FCCE4A-C7C2-4EDE-9521-3D562391ACE4@airwired.net> <4CD9648A.2080606@icyb.net.ua> <4CD967CB.5090201@icyb.net.ua> <817835F0-91C1-4945-917A-9C582C4FDFF6@airwired.net> <4CD971C2.1010506@icyb.net.ua> To: Andriy Gapon X-Mailer: Apple Mail (2.1081) Cc: Sergey Kandaurov , FreeBSD-STABLE Mailing List Subject: Re: Fatal trap 18 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Nov 2010 16:09:00 -0000 On 9 Nov 2010, at 9:07 AM, Andriy Gapon wrote: > Let's see if anybody else can help you with that stuff. > My jurisdiction (area of expertise) ends here. Thank you for your help! Dan From owner-freebsd-stable@FreeBSD.ORG Tue Nov 9 19:55: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 435A21065672 for ; Tue, 9 Nov 2010 19:55:41 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 04DA78FC1D for ; Tue, 9 Nov 2010 19:55:40 +0000 (UTC) Received: by iwn39 with SMTP id 39so7997808iwn.13 for ; Tue, 09 Nov 2010 11:55: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=nlnPFKdBAETnu/VBzCZYT+XQj4opMuIkq15Ew51bE2Y=; b=umuF4jaxFmg2xGNvqeDkt6qVI8zvP8ThgJi+2kneC/1ctlrQizs72usWBlM6q5DP52 tfsioF/YpywPkwUecK0c+yx6mdSbDo7lTDXdx4MCRofq2ZBrk0weRT3AUKA5tBNwk5uL LX7uy198dWwxfK1MxMjp6G7PZHeZKbxDfYAfY= 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=LLVOYqDM/QHG+a3S08VOf2sKXrO9OaIQOzqDe+34JIJYFVN4+8UrifVS4We2HN5eI6 ngBaBTBm/5GFxiVcJoNI31+xKKlupav9enpQ8rnsvRjrXr/9mPH0jz0YPgjKG933eEhj NF7/etIotywNCvsZbmGW0DAYcZqy5ALo9p8y0= Received: by 10.231.37.199 with SMTP id y7mr5477445ibd.127.1289330716561; Tue, 09 Nov 2010 11:25:16 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id gy41sm1698408ibb.23.2010.11.09.11.25.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Nov 2010 11:25:14 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 9 Nov 2010 11:24:19 -0800 From: Pyun YongHyeon Date: Tue, 9 Nov 2010 11:24:19 -0800 To: M?rcio Luciano Donada Message-ID: <20101109192419.GB7766@michelle.cdnetworks.com> References: <4CD92E25.7060304@auroraalimentos.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CD92E25.7060304@auroraalimentos.com.br> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: watchdog 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, 09 Nov 2010 19:55:41 -0000 On Tue, Nov 09, 2010 at 09:19:01AM -0200, M?rcio Luciano Donada wrote: > Hi list, > > I'm using FreeBSD (uname is below) and these days I'm caught in the log > message below: > > vpn# uname -a > FreeBSD vpn.auroraalimentos.com.br 7.3-STABLE FreeBSD 7.3-STABLE #0: Sat > Jun 19 18:39:18 BRT 2010 > root@vpn.xxx.com.br:/usr/obj/usr/src/sys/VPN i386 > > Nov 8 11:53:55 vpn kernel: xl0: watchdog timeout (missed Tx interrupts) > -- recovering > Nov 8 12:01:21 vpn kernel: xl0: watchdog timeout (missed Tx interrupts) > -- recovering > Nov 8 12:21:55 vpn kernel: xl0: watchdog timeout (missed Tx interrupts) > -- recovering > Nov 8 16:11:34 vpn kernel: xl0: watchdog timeout (missed Tx interrupts) > -- recovering > > it is possible that the network interface (xl0) is in trouble? > If my memory serve me right there were a couple of reports about xl(4) watchdog timeout in past. The message was added by me to track down possible cause of watchdog timeouts. The message means driver lost Tx completion interrupts but driver noticed that the queued frames were successfully transmitted such that it didn't reset the controller and showed the informational message. To further narrow down the issue, would you show me the following information? o full 'dmesg' output o 'pciconf -lcbv' output o 'devinfo -rv | grep phy' output From owner-freebsd-stable@FreeBSD.ORG Tue Nov 9 19:57:55 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 CF31A1065675 for ; Tue, 9 Nov 2010 19:57:55 +0000 (UTC) (envelope-from kensmith@buffalo.edu) Received: from localmailC.acsu.buffalo.edu (localmail.buffalo.edu [128.205.5.204]) by mx1.freebsd.org (Postfix) with ESMTP id 9E25F8FC1F for ; Tue, 9 Nov 2010 19:57:55 +0000 (UTC) Received: from localmailC.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D7F166F09A for ; Tue, 9 Nov 2010 14:40:32 -0500 (EST) Received: from localmailC.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailC.acsu.buffalo.edu (Postfix) with ESMTP id 5A0F26F2B8 for ; Tue, 9 Nov 2010 14:40:32 -0500 (EST) Received: from mweb1.acsu.buffalo.edu (mweb1.acsu.buffalo.edu [128.205.5.238]) by localmailC.acsu.buffalo.edu (Prefixe) with ESMTP id 556BB5A785 for ; Tue, 9 Nov 2010 14:40:32 -0500 (EST) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) by mweb1.acsu.buffalo.edu (Postfix) with ESMTP id 3B8FB5B003A for ; Tue, 9 Nov 2010 14:40:32 -0500 (EST) From: Ken Smith To: freebsd-stable Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-n7JZLrp5OW1n9gb4wbIu" Date: Tue, 09 Nov 2010 14:40:31 -0500 Message-ID: <1289331631.32929.35.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.28.2 FreeBSD GNOME Team Port X-PM-EL-Spam-Prob: : 8% Subject: Last of the RELENG_6 Monthly Snapshots... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Nov 2010 19:57:55 -0000 --=-n7JZLrp5OW1n9gb4wbIu Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The 201011 (November 2010) Monthly Snapshots are done. Since the Security Team will be dropping support for RELENG_6 at the end of this month we will stop generating RELENG_6 snapshots for the set of architectures that survived this long (amd64, i386, pc98, and sparc64). I also placed a copy of just the 6.4-STABLE-201011 ISOs on the ftp-archive site: ftp://ftp-archive.freebsd.org/pub/FreeBSD-Archive/snapshots/6-STABLE/ so they will remain available longer than the four months that they will stay on the primary FTP site. --=20 Ken Smith - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodor Geisel | --=-n7JZLrp5OW1n9gb4wbIu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEABECAAYFAkzZo68ACgkQ/G14VSmup/aQkwCdHB0NoqhCnIT/7nh6fPC8x72W hsAAnRkYt/6oc3US4yqAN4X9GJKZi/4S =GuQS -----END PGP SIGNATURE----- --=-n7JZLrp5OW1n9gb4wbIu-- From owner-freebsd-stable@FreeBSD.ORG Tue Nov 9 20:09:22 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 87EC8106566B for ; Tue, 9 Nov 2010 20:09:22 +0000 (UTC) (envelope-from mdonada@auroraalimentos.com.br) Received: from auroraalimentos.com.br (mx.auroraalimentos.com.br [200.228.43.6]) by mx1.freebsd.org (Postfix) with ESMTP id 9213D8FC0C for ; Tue, 9 Nov 2010 20:09:21 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by auroraalimentos.com.br (Postfix) with ESMTP id 3208DFD419A for ; Tue, 9 Nov 2010 17:59:30 -0200 (BRST) Received: from auroraalimentos.com.br ([127.0.0.1]) by localhost (mx.auroraalimentos.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOJgBq6k14cl for ; Tue, 9 Nov 2010 17:59:30 -0200 (BRST) Received: from [127.0.0.1] (unknown [121.1.16.22]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by auroraalimentos.com.br (Postfix) with ESMTP id 817F0FD40AC for ; Tue, 9 Nov 2010 17:59:29 -0200 (BRST) Message-ID: <4CD9AA69.7070408@auroraalimentos.com.br> Date: Tue, 09 Nov 2010 18:09:13 -0200 From: =?ISO-8859-1?Q?M=E1rcio_Luciano_Donada?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4CD92E25.7060304@auroraalimentos.com.br> <20101109192419.GB7766@michelle.cdnetworks.com> In-Reply-To: <20101109192419.GB7766@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: watchdog X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Nov 2010 20:09:22 -0000 Em 9/11/2010 17:24, Pyun YongHyeon escreveu: > On Tue, Nov 09, 2010 at 09:19:01AM -0200, M?rcio Luciano Donada wrote: >> Hi list, >> >> I'm using FreeBSD (uname is below) and these days I'm caught in the log >> message below: >> >> vpn# uname -a >> FreeBSD vpn.auroraalimentos.com.br 7.3-STABLE FreeBSD 7.3-STABLE #0: Sat >> Jun 19 18:39:18 BRT 2010 >> root@vpn.xxx.com.br:/usr/obj/usr/src/sys/VPN i386 >> >> Nov 8 11:53:55 vpn kernel: xl0: watchdog timeout (missed Tx interrupts) >> -- recovering >> Nov 8 12:01:21 vpn kernel: xl0: watchdog timeout (missed Tx interrupts) >> -- recovering >> Nov 8 12:21:55 vpn kernel: xl0: watchdog timeout (missed Tx interrupts) >> -- recovering >> Nov 8 16:11:34 vpn kernel: xl0: watchdog timeout (missed Tx interrupts) >> -- recovering >> >> it is possible that the network interface (xl0) is in trouble? >> > > If my memory serve me right there were a couple of reports about > xl(4) watchdog timeout in past. The message was added by me to > track down possible cause of watchdog timeouts. The message means > driver lost Tx completion interrupts but driver noticed that the > queued frames were successfully transmitted such that it didn't > reset the controller and showed the informational message. > > To further narrow down the issue, would you show me the following > information? > o full 'dmesg' output > o 'pciconf -lcbv' output > o 'devinfo -rv | grep phy' output Hi, here's the information you requested: vpn# devinfo -rv|grep phy rgephy0 pnpinfo oui=0x732 model=0x11 rev=0x0 at phyno=1 acphy0 pnpinfo oui=0x895 model=0x12 rev=0x1 at phyno=1 vpn# dmesg 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 7.3-STABLE #0: Sat Jun 19 18:39:18 BRT 2010 root@vpn.auroraalimentos.com.br:/usr/obj/usr/src/sys/VPN i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) XP 2800+ (2079.56-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x6a0 Family = 6 Model = a Stepping = 0 Features=0x383fbff AMD Features=0xc0400800 real memory = 2080309248 (1983 MB) avail memory = 2025820160 (1931 MB) kbd1 at kbdmux0 cryptosoft0: on motherboard pcib0: pcibus 0 on motherboard pir0: on motherboard pci0: on pcib0 Correcting nForce2 C1 CPU disconnect hangs agp0: on hostb0 pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) pci0: at device 0.4 (no driver attached) pci0: at device 0.5 (no driver attached) isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) ohci0: mem 0xfc300000-0xfc300fff irq 11 at device 2.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xfc301000-0xfc301fff irq 3 at device 2.1 on pci0 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb1: OHCI version 1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 3 ports with 3 removable, self powered ehci0: mem 0xfc303000-0xfc3030ff irq 5 at device 2.2 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb2: EHCI version 1.0 usb2: companion controllers, 4 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: on usb2 uhub2: 6 ports with 6 removable, self powered pci0: at device 6.0 (no driver attached) pcib1: at device 8.0 on pci0 pci5: on pcib1 $PIR: No matching entry for 5.4.INTA re0: port 0x2000-0x20ff mem 0xfc800000-0xfc8000ff irq 5 at device 4.0 on pci5 re0: Chip rev. 0x00800000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:08:54:d4:55:ba re0: [FILTER] atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x34a0-0x34af at device 9.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pcib2: at device 12.0 on pci0 pci20: on pcib2 xl0: <3Com 3c920B-EMB Integrated Fast Etherlink XL> port 0x1000-0x107f mem 0xfc900000-0xfc90007f irq 3 at device 1.0 on pci20 miibus1: on xl0 acphy0: PHY 1 on miibus1 acphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:0a:5e:30:c5:7e xl0: [ITHREAD] pcib3: at device 30.0 on pci0 pci1: on pcib3 vgapci0: mem 0xfd000000-0xfdffffff,0xf8000000-0xfbffffff,0xfc200000-0xfc27ffff irq 5 at device 0.0 on pci1 cpu0 on motherboard pnpbios: error 0/82 getting device count/size limit pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcafff,0xcb000-0xcb7ff pnpid ORM0000 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse Explorer, device ID 4 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/13 bytes threshold ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 2079560140 Hz quality 800 Timecounters tick every 1.000 msec IPsec: Initialized Security Association Processing. ad0: 38204MB at ata0-master UDMA100 ad1: 76351MB at ata0-slave UDMA100 acd0: CDROM at ata1-master PIO4 GEOM_MIRROR: Device mirror/gm0 launched (2/2). Trying to mount root from ufs:/dev/mirror/gm0s1a vpn# pciconf -lcbv hostb0@pci0:0:0:0: class=0x060000 card=0x00000000 chip=0x01e010de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'AGP Controller (nForce2)' class = bridge subclass = HOST-PCI bar [10] = type Prefetchable Memory, range 32, base 0xf4000000, size 67108 864, enabled cap 02[40] = AGP 4x 2x 1x SBA disabled cap 08[60] = HT host none0@pci0:0:0:1: class=0x050000 card=0x12b9103c chip=0x01eb10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'Memory Controller 1 (nForce2)' class = memory subclass = RAM none1@pci0:0:0:2: class=0x050000 card=0x12b9103c chip=0x01ee10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'Memory Controller 4 (nForce2)' class = memory subclass = RAM none2@pci0:0:0:3: class=0x050000 card=0x12b9103c chip=0x01ed10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'Memory Controller 3 (nForce2)' class = memory subclass = RAM none3@pci0:0:0:4: class=0x050000 card=0x12b9103c chip=0x01ec10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'Memory Controller 2 (nForce2)' class = memory subclass = RAM none4@pci0:0:0:5: class=0x050000 card=0x12b9103c chip=0x01ef10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'Memory Controller 5 (nForce2)' class = memory subclass = RAM isab0@pci0:0:1:0: class=0x060100 card=0x12b9103c chip=0x006010de rev=0xa4 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'PCI to ISA Bridge (MCP2)' class = bridge subclass = PCI-ISA cap 08[48] = HT slave none5@pci0:0:1:1: class=0x0c0500 card=0x12b9103c chip=0x006410de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce 2 SMBus Controller (MCP)' class = serial bus subclass = SMBus bar [10] = type I/O Port, range 32, base 0x3480, size 32, enabled cap 01[44] = powerspec 2 supports D0 D3 current D0 ohci0@pci0:0:2:0: class=0x0c0310 card=0x12b9103c chip=0x006710de rev=0xa4 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'Nvidia 7050 chipset HDMI Audio (MCP2)' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xfc300000, size 4096, enabled cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 ohci1@pci0:0:2:1: class=0x0c0310 card=0x12b9103c chip=0x006710de rev=0xa4 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'Nvidia 7050 chipset HDMI Audio (MCP2)' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xfc301000, size 4096, enabled cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 ehci0@pci0:0:2:2: class=0x0c0320 card=0x12b9103c chip=0x006810de rev=0xa4 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce2 EHCI USB 2.0 Controller' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xfc303000, size 256, enabled cap 01[80] = powerspec 2 supports D0 D1 D2 D3 current D0 none6@pci0:0:6:0: class=0x040100 card=0x12b9103c chip=0x006a10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce AC97 Audio Controller (MCP2)' class = multimedia subclass = audio bar [10] = type I/O Port, range 32, base 0x3000, size 256, enabled bar [14] = type I/O Port, range 32, base 0x3400, size 128, enabled bar [18] = type Memory, range 32, base 0xfc302000, size 4096, enabled cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 pcib1@pci0:0:8:0: class=0x060400 card=0x00000000 chip=0x006c10de rev=0xa3 hdr=0x01 vendor = 'NVIDIA Corporation' device = 'nForce MCP-T CPU to PCI Bridge' class = bridge subclass = PCI-PCI atapci0@pci0:0:9:0: class=0x01018a card=0x12b9103c chip=0x006510de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'PATA Controller (nForce MCP2/MCP2-T/MCP2-U)' class = mass storage subclass = ATA bar [20] = type I/O Port, range 32, base 0x34a0, size 16, enabled cap 01[44] = powerspec 2 supports D0 D3 current D0 pcib2@pci0:0:12:0: class=0x060400 card=0x00000000 chip=0x006d10de rev=0xa3 hdr=0x01 vendor = 'NVIDIA Corporation' device = 'Audio Codec Interface (nForce MCP-T)' class = bridge subclass = PCI-PCI pcib3@pci0:0:30:0: class=0x060400 card=0x00000000 chip=0x01e810de rev=0xa2 hdr=0x01 vendor = 'NVIDIA Corporation' device = 'AGP Host to PCI Bridge (nForce2)' class = bridge subclass = PCI-PCI re0@pci0:5:4:0: class=0x020000 card=0x816910ec chip=0x816910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'Single Gigabit LOM Ethernet Controller (RTL8110)' class = network subclass = ethernet bar [10] = type I/O Port, range 32, base 0x2000, size 256, enabled bar [14] = type Memory, range 32, base 0xfc800000, size 256, enabled cap 01[dc] = powerspec 2 supports D0 D1 D2 D3 current D0 xl0@pci0:20:1:0: class=0x020000 card=0x12b8103c chip=0x920110b7 rev=0x40 hdr=0x00 vendor = '3COM Corp, Networking Division' device = 'Integrated Fast Ethernet Controller (3C920B-EMB)' class = network subclass = ethernet bar [10] = type I/O Port, range 32, base 0x1000, size 128, enabled bar [14] = type Memory, range 32, base 0xfc900000, size 128, enabled cap 01[dc] = powerspec 2 supports D0 D1 D2 D3 current D0 vgapci0@pci0:1:0:0: class=0x030000 card=0x12b9103c chip=0x01f010de rev=0xa3 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'NVIDIA GeForce4 MX Integrated GPU (CR17)' class = display subclass = VGA bar [10] = type Memory, range 32, base 0xfd000000, size 16777216, enabled bar [14] = type Prefetchable Memory, range 32, base 0xf8000000, size 67108 864, enabled bar [18] = type Prefetchable Memory, range 32, base 0xfc200000, size 52428 8, enabled cap 01[60] = powerspec 2 supports D0 D3 current D0 cap 02[44] = AGP 4x 2x 1x SBA disabled -- Márcio Luciano Donada Aurora Alimentos - Cooperativa Central Oeste Catarinense Departamento de T.I. From owner-freebsd-stable@FreeBSD.ORG Tue Nov 9 22:03: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 DCA92106564A for ; Tue, 9 Nov 2010 22:03:23 +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 ACDC28FC0A for ; Tue, 9 Nov 2010 22:03:23 +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 3B98046B09; Tue, 9 Nov 2010 17:03:23 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B52AC8A009; Tue, 9 Nov 2010 17:03:21 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Tue, 9 Nov 2010 15:32:12 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> <4CD967CB.5090201@icyb.net.ua> In-Reply-To: <4CD967CB.5090201@icyb.net.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011091532.13083.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 09 Nov 2010 17:03:21 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Dan Allen , Sergey Kandaurov , Andriy Gapon Subject: Re: Fatal trap 18 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Nov 2010 22:03:23 -0000 On Tuesday, November 09, 2010 10:24:59 am Andriy Gapon wrote: > on 09/11/2010 17:22 Dan Allen said the following: > > > > On 9 Nov 2010, at 8:11 AM, Andriy Gapon wrote: > > > >> /boot/loader.conf contents > > > > This might be the smoking gun! > > > > cat loader.conf: > > > > hint.apic.0.disabled="1" > > Yes, it is. > So why do you have it and what happens if you remove it? The kernel should still not panic if someone disables APIC. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Nov 9 22:08: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 A93C61065670; Tue, 9 Nov 2010 22:08:45 +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 B56F78FC12; Tue, 9 Nov 2010 22:08:44 +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 AAA02302; Wed, 10 Nov 2010 00:08:43 +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 1PFwMs-0007yT-MM; Wed, 10 Nov 2010 00:08:42 +0200 Message-ID: <4CD9C669.5070805@icyb.net.ua> Date: Wed, 10 Nov 2010 00:08:41 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: John Baldwin References: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> <4CD967CB.5090201@icyb.net.ua> <201011091532.13083.jhb@freebsd.org> In-Reply-To: <201011091532.13083.jhb@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Dan Allen , Sergey Kandaurov , freebsd-stable@freebsd.org Subject: Re: Fatal trap 18 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Nov 2010 22:08:45 -0000 on 09/11/2010 22:32 John Baldwin said the following: > On Tuesday, November 09, 2010 10:24:59 am Andriy Gapon wrote: >> on 09/11/2010 17:22 Dan Allen said the following: >>> >>> On 9 Nov 2010, at 8:11 AM, Andriy Gapon wrote: >>> >>>> /boot/loader.conf contents >>> >>> This might be the smoking gun! >>> >>> cat loader.conf: >>> >>> hint.apic.0.disabled="1" >> >> Yes, it is. >> So why do you have it and what happens if you remove it? > > The kernel should still not panic if someone disables APIC. 100% agreement - and it shouldn't do that now. The last good half of this thread was devoted to finding the reason why Dan's system discovered only one logical CPU. The panic issue was resolved a bit earlier, but the thread subject wasn't changed. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Nov 10 00:40: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 6922E1065670 for ; Wed, 10 Nov 2010 00:40:41 +0000 (UTC) (envelope-from bryce@bryce.net) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 0E5518FC1A for ; Wed, 10 Nov 2010 00:40:40 +0000 (UTC) Received: by wwb22 with SMTP id 22so87963wwb.31 for ; Tue, 09 Nov 2010 16:40:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.128.131 with SMTP id k3mr7591791wbs.66.1289347748779; Tue, 09 Nov 2010 16:09:08 -0800 (PST) Received: by 10.216.172.209 with HTTP; Tue, 9 Nov 2010 16:09:08 -0800 (PST) Date: Tue, 9 Nov 2010 18:09:08 -0600 Message-ID: From: Bryce Edwards To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: 8-STABLE buildworld failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 00:40:41 -0000 After updating source today, I am receiving the following error when running make NOCCACHE=YES -j16 buildkernel ===> zlib (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/GENERIC -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/src/sys/modules/zlib/../../net/zlib.c ld -d -warn-common -r -d -o zlib.ko.debug zlib.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk zlib.ko.debug export_syms | xargs -J% objcopy % zlib.ko.debug objcopy --only-keep-debug zlib.ko.debug zlib.ko.symbols objcopy --strip-debug --add-gnu-debuglink=zlib.ko.symbols zlib.ko.debug zlib.ko 1 error *** Error code 2 1 error *** Error code 2 Here's make.conf: SUP_UPDATE=yes SUPFILE=/usr/share/examples/cvsup/stable-supfile PORTSSUPFILE=/usr/share/examples/cvsup/ports-supfile SUPHOST=cvsup5.us.freebsd.org #WITHOUT_X11=yes PORTS_MODULES=emulators/virtualbox-ose-kmod # ccache .if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*)) && !defined(NOCCACHE) #CC=/usr/local/libexec/ccache/world-cc #CXX=/usr/local/libexec/ccache/world-c++ .endif # added by use.perl 2010-11-09 09:32:27 PERL_VERSION=5.10.1 And src.conf: WITHOUT_PROFILE=true # Avoid compiling profiled libraries From owner-freebsd-stable@FreeBSD.ORG Wed Nov 10 02:26: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 70F82106566B for ; Wed, 10 Nov 2010 02:26:58 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id 3376E8FC0C for ; Wed, 10 Nov 2010 02:26:58 +0000 (UTC) Received: (qmail 15466 invoked by uid 89); 10 Nov 2010 02:26:56 -0000 Received: from unknown (HELO ?192.168.0.18?) (danallen46@airwired.net@66.29.174.6) by mail.utahbroadband.com with ESMTPA; 10 Nov 2010 02:26:56 -0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Dan Allen In-Reply-To: <4CD9C669.5070805@icyb.net.ua> Date: Tue, 9 Nov 2010 19:26:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> <4CD967CB.5090201@icyb.net.ua> <201011091532.13083.jhb@freebsd.org> <4CD9C669.5070805@icyb.net.ua> To: Andriy Gapon X-Mailer: Apple Mail (2.1081) Cc: Sergey Kandaurov , freebsd-stable@freebsd.org, John Baldwin Subject: Re: Fatal trap 18 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Nov 2010 02:26:58 -0000 On 9 Nov 2010, at 3:08 PM, Andriy Gapon wrote: >> The kernel should still not panic if someone disables APIC. >=20 > 100% agreement - and it shouldn't do that now. The kernel on my Core Duo machine does not panic with APIC off. In fact = it works much better with it off. The only problem is that I am missing = one of my two Cores with APIC off! Dan From owner-freebsd-stable@FreeBSD.ORG Wed Nov 10 03:26:52 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 A2DBA106566C; Wed, 10 Nov 2010 03:26:52 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5EDE58FC16; Wed, 10 Nov 2010 03:26:52 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oAA3QpV1006112; Tue, 9 Nov 2010 22:26:51 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oAA3QpV0006087; Wed, 10 Nov 2010 03:26:51 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 10 Nov 2010 03:26:51 GMT Message-Id: <201011100326.oAA3QpV0006087@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on i386/pc98 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 03:26:52 -0000 TB --- 2010-11-10 02:21:18 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-10 02:21:18 - starting RELENG_8 tinderbox run for i386/pc98 TB --- 2010-11-10 02:21:18 - cleaning the object tree TB --- 2010-11-10 02:21:41 - cvsupping the source tree TB --- 2010-11-10 02:21:41 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/pc98/supfile TB --- 2010-11-10 02:21:55 - building world TB --- 2010-11-10 02:21:55 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-10 02:21:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-10 02:21:55 - TARGET=pc98 TB --- 2010-11-10 02:21:55 - TARGET_ARCH=i386 TB --- 2010-11-10 02:21:55 - TZ=UTC TB --- 2010-11-10 02:21:55 - __MAKE_CONF=/dev/null TB --- 2010-11-10 02:21:55 - cd /src TB --- 2010-11-10 02:21:55 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 10 02:21:59 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Nov 10 03:23:54 UTC 2010 TB --- 2010-11-10 03:23:54 - generating LINT kernel config TB --- 2010-11-10 03:23:54 - cd /src/sys/pc98/conf TB --- 2010-11-10 03:23:54 - /usr/bin/make -B LINT TB --- 2010-11-10 03:23:54 - building LINT kernel TB --- 2010-11-10 03:23:54 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-10 03:23:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-10 03:23:54 - TARGET=pc98 TB --- 2010-11-10 03:23:54 - TARGET_ARCH=i386 TB --- 2010-11-10 03:23:54 - TZ=UTC TB --- 2010-11-10 03:23:54 - __MAKE_CONF=/dev/null TB --- 2010-11-10 03:23:54 - cd /src TB --- 2010-11-10 03:23:54 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Nov 10 03:23:54 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] from @/contrib/dev/acpica/include/acpi.h:128, from /src/sys/modules/tpm/../../dev/tpm/tpm_acpi.c:43: @/contrib/dev/acpica/include/platform/acfreebsd.h:124:36: error: machine/acpica_machdep.h: No such file or directory In file included from @/contrib/dev/acpica/include/acpi.h:130, from /src/sys/modules/tpm/../../dev/tpm/tpm_acpi.c:43: @/contrib/dev/acpica/include/actypes.h:127:2: error: #error ACPI_MACHINE_WIDTH not defined @/contrib/dev/acpica/include/actypes.h:276:2: error: #error unknown ACPI_MACHINE_WIDTH mkdep: compile failed *** Error code 1 Stop in /src/sys/modules/tpm. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-10 03:26:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-10 03:26:51 - ERROR: failed to build lint kernel TB --- 2010-11-10 03:26:51 - 2804.25 user 696.76 system 3932.69 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Wed Nov 10 03:47: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 8E723106567A for ; Wed, 10 Nov 2010 03:47:15 +0000 (UTC) (envelope-from larry.vaden@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 25BDA8FC1B for ; Wed, 10 Nov 2010 03:47:14 +0000 (UTC) Received: by wwb22 with SMTP id 22so226562wwb.31 for ; Tue, 09 Nov 2010 19:47:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=GetoNTg+u2cD9jGK5MBxyTBjrek4pNeatB2SkUKvcDk=; b=GPm1V26vv5MKyXBvunO92UQZh2eOts2lmWNdrYbqIY5YB+Ukut6pbYzeG2k9Ao7cXY uph5qGyIngkTvyTAaVh3+iW0kj8fEKrx6m3f9PxPKIPlqnjeNXYRtJ+jOMiIEdWT+NDv B5msH5pYC2bRBakCw1BysZXjDiVEtWgQqpQ1Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=f/DtPyJFXmL+6W/yw9L2JK28DkKNEM2VPrMFkQJW+9dsDmuvRmguppYf5DKxxDRmkw uxLsmbmYGKglRHR9401m8MUgT6L+3BLj4bD4fRRN12t6Y+1C0w4L2GdUYOJlsp8H9RcJ cGX+yrvsT6Jm8hNNdC5OiYjaQigRJBH5wWziM= MIME-Version: 1.0 Received: by 10.216.141.209 with SMTP id g59mr7773613wej.10.1289359143803; Tue, 09 Nov 2010 19:19:03 -0800 (PST) Sender: larry.vaden@gmail.com Received: by 10.216.242.12 with HTTP; Tue, 9 Nov 2010 19:19:03 -0800 (PST) Date: Tue, 9 Nov 2010 21:19:03 -0600 X-Google-Sender-Auth: nN-kZ7iWt__iblbkbBvGpN-yi7s Message-ID: From: Larry Vaden To: FreeBSD-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: Subject: what is best FreeBSD-based 802.11b/g/n AP package for Ubiquiti and Tranzeo gear? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Nov 2010 03:47:15 -0000 We are seeing the "stuck beacon" problem and the NETDEV WATCHDOG problem on Rocket M2 and Bullet M2 running AirOS 5.3-beta2 and the "stuck beacon" problem on Bullet 2 HP running AirOS 3.5.1 Does anyone have a recommendation for a solid FreeBSD-based 802.11b/g/n AP package for the Ubiquiti family and for the Tranzeo EX2-8? Your input is really appreciated. kind regards/ldv Larry Vaden Internet Texoma, Inc. Serving Rural Texomaland Since 1995 We Care About Your Connection! XM.v5.3-beta2.6873.101018.1811# dmesg | grep -i "stuck beacon" | wc -l 91 [94009.052000] ath_bstuck_tasklet: stuck beacon; resetting (bmiss count 9) XM.v5.3-beta2.6873.101018.1811# dmesg | grep -i "watchdog" [ 7945.985000] NETDEV WATCHDOG: wifi0: transmit timed out XM.v5.3-beta2.6873.101018.1811# From owner-freebsd-stable@FreeBSD.ORG Wed Nov 10 04:30:31 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 C12DF106566C; Wed, 10 Nov 2010 04:30:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 73DD28FC1B; Wed, 10 Nov 2010 04:30:31 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oAA4UUsR011487; Tue, 9 Nov 2010 23:30:30 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oAA4UUkH011483; Wed, 10 Nov 2010 04:30:30 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 10 Nov 2010 04:30:30 GMT Message-Id: <201011100430.oAA4UUkH011483@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 04:30:32 -0000 TB --- 2010-11-10 03:26:51 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-10 03:26:51 - starting RELENG_8 tinderbox run for powerpc/powerpc TB --- 2010-11-10 03:26:51 - cleaning the object tree TB --- 2010-11-10 03:27:16 - cvsupping the source tree TB --- 2010-11-10 03:27:16 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/powerpc/powerpc/supfile TB --- 2010-11-10 03:27:35 - building world TB --- 2010-11-10 03:27:35 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-10 03:27:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-10 03:27:35 - TARGET=powerpc TB --- 2010-11-10 03:27:35 - TARGET_ARCH=powerpc TB --- 2010-11-10 03:27:35 - TZ=UTC TB --- 2010-11-10 03:27:35 - __MAKE_CONF=/dev/null TB --- 2010-11-10 03:27:35 - cd /src TB --- 2010-11-10 03:27:35 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 10 03:27:36 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Nov 10 04:28:29 UTC 2010 TB --- 2010-11-10 04:28:29 - generating LINT kernel config TB --- 2010-11-10 04:28:29 - cd /src/sys/powerpc/conf TB --- 2010-11-10 04:28:29 - /usr/bin/make -B LINT TB --- 2010-11-10 04:28:29 - building LINT kernel TB --- 2010-11-10 04:28:29 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-10 04:28:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-10 04:28:29 - TARGET=powerpc TB --- 2010-11-10 04:28:29 - TARGET_ARCH=powerpc TB --- 2010-11-10 04:28:29 - TZ=UTC TB --- 2010-11-10 04:28:29 - __MAKE_CONF=/dev/null TB --- 2010-11-10 04:28:29 - cd /src TB --- 2010-11-10 04:28:29 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Nov 10 04:28:29 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] from @/contrib/dev/acpica/include/acpi.h:128, from /src/sys/modules/tpm/../../dev/tpm/tpm_acpi.c:43: @/contrib/dev/acpica/include/platform/acfreebsd.h:124:36: error: machine/acpica_machdep.h: No such file or directory In file included from @/contrib/dev/acpica/include/acpi.h:130, from /src/sys/modules/tpm/../../dev/tpm/tpm_acpi.c:43: @/contrib/dev/acpica/include/actypes.h:127:2: error: #error ACPI_MACHINE_WIDTH not defined @/contrib/dev/acpica/include/actypes.h:276:2: error: #error unknown ACPI_MACHINE_WIDTH mkdep: compile failed *** Error code 1 Stop in /src/sys/modules/tpm. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-10 04:30:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-10 04:30:30 - ERROR: failed to build lint kernel TB --- 2010-11-10 04:30:30 - 2845.32 user 638.80 system 3818.95 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Wed Nov 10 05:02: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 CD128106564A; Wed, 10 Nov 2010 05:02:05 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 7F99D8FC22; Wed, 10 Nov 2010 05:02:05 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oAA524YJ091991; Wed, 10 Nov 2010 00:02:04 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oAA524FF091990; Wed, 10 Nov 2010 05:02:04 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 10 Nov 2010 05:02:04 GMT Message-Id: <201011100502.oAA524FF091990@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 05:02:06 -0000 TB --- 2010-11-10 04:06:04 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-10 04:06:04 - starting RELENG_8 tinderbox run for sparc64/sparc64 TB --- 2010-11-10 04:06:04 - cleaning the object tree TB --- 2010-11-10 04:06:25 - cvsupping the source tree TB --- 2010-11-10 04:06:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/sparc64/sparc64/supfile TB --- 2010-11-10 04:06:52 - building world TB --- 2010-11-10 04:06:52 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-10 04:06:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-10 04:06:52 - TARGET=sparc64 TB --- 2010-11-10 04:06:52 - TARGET_ARCH=sparc64 TB --- 2010-11-10 04:06:52 - TZ=UTC TB --- 2010-11-10 04:06:52 - __MAKE_CONF=/dev/null TB --- 2010-11-10 04:06:52 - cd /src TB --- 2010-11-10 04:06:52 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 10 04:06:53 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Nov 10 05:00:16 UTC 2010 TB --- 2010-11-10 05:00:16 - generating LINT kernel config TB --- 2010-11-10 05:00:16 - cd /src/sys/sparc64/conf TB --- 2010-11-10 05:00:16 - /usr/bin/make -B LINT TB --- 2010-11-10 05:00:16 - building LINT kernel TB --- 2010-11-10 05:00:16 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-10 05:00:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-10 05:00:16 - TARGET=sparc64 TB --- 2010-11-10 05:00:16 - TARGET_ARCH=sparc64 TB --- 2010-11-10 05:00:16 - TZ=UTC TB --- 2010-11-10 05:00:16 - __MAKE_CONF=/dev/null TB --- 2010-11-10 05:00:16 - cd /src TB --- 2010-11-10 05:00:16 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Nov 10 05:00:16 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] from @/contrib/dev/acpica/include/acpi.h:128, from /src/sys/modules/tpm/../../dev/tpm/tpm_acpi.c:43: @/contrib/dev/acpica/include/platform/acfreebsd.h:124:36: error: machine/acpica_machdep.h: No such file or directory In file included from @/contrib/dev/acpica/include/acpi.h:130, from /src/sys/modules/tpm/../../dev/tpm/tpm_acpi.c:43: @/contrib/dev/acpica/include/actypes.h:127:2: error: #error ACPI_MACHINE_WIDTH not defined @/contrib/dev/acpica/include/actypes.h:276:2: error: #error unknown ACPI_MACHINE_WIDTH mkdep: compile failed *** Error code 1 Stop in /src/sys/modules/tpm. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-10 05:02:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-10 05:02:04 - ERROR: failed to build lint kernel TB --- 2010-11-10 05:02:04 - 2674.15 user 573.73 system 3359.59 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Wed Nov 10 05:04: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 D411C106564A for ; Wed, 10 Nov 2010 05:04:27 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 860918FC18 for ; Wed, 10 Nov 2010 05:04:27 +0000 (UTC) Received: by gwj16 with SMTP id 16so125457gwj.13 for ; Tue, 09 Nov 2010 21:04:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=gym91DjHDSSktKhLTrmSeFPTTPyP+5Dux39VdZ3twTc=; b=FPD2qQDMHxSiXBqj6CXZrniDB8cf/RLdzjdtBODhvCdeXonuMj1rDFiZs78MZwbkQW qIS7QeAWnh16iEpwGOLEEiOMj9kBreognB/S8WWW1B7Xhtrss7hm3ZjFacdLSLiiRfSO YQqNqTOiFPzLI1bCHZXzp1+BNfcf5zolJ86ro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=LuGkcwPr2RtU1ipJkNgCgFEfkM7BpxCiUYpSpJxKDNHPkMpX0gbGCCDLQmyiwz2x0D NOsR+jr9ksTPaytFlxeAWQeWc7qrHEzha7dPqZaT5H+PvrA6jAdJj/tDCTi7Q+mZJX+1 wctX5rygHBgD8xaY87r0KN8DsXrF6cRlHKc5A= Received: by 10.150.54.14 with SMTP id c14mr1104513yba.57.1289365466305; Tue, 09 Nov 2010 21:04:26 -0800 (PST) Received: from centel.dataix.local (adsl-99-181-136-243.dsl.klmzmi.sbcglobal.net [99.181.136.243]) by mx.google.com with ESMTPS id i2sm217714yha.31.2010.11.09.21.04.24 (version=SSLv3 cipher=RC4-MD5); Tue, 09 Nov 2010 21:04:24 -0800 (PST) Sender: "J. Hellenthal" Message-ID: <4CDA27D6.7040605@DataIX.net> Date: Wed, 10 Nov 2010 00:04:22 -0500 From: jhell Organization: http://www.DataIX.net User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.12) Gecko/20101028 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Bryce Edwards References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 8-STABLE buildworld failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 05:04:28 -0000 On 11/09/2010 19:09, Bryce Edwards wrote: > After updating source today, I am receiving the following error when > running make NOCCACHE=YES -j16 buildkernel > > > ===> zlib (all) > cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE > -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include > /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer > -I/usr/obj/usr/src/sys/GENERIC -mcmodel=kernel -mno-red-zone > -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow > -msoft-float -fno-asynchronous-unwind-tables -ffreestanding > -fstack-protector -std=iso9899:1999 -fstack-protector -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -c > /usr/src/sys/modules/zlib/../../net/zlib.c > ld -d -warn-common -r -d -o zlib.ko.debug zlib.o > :> export_syms > awk -f /usr/src/sys/conf/kmod_syms.awk zlib.ko.debug export_syms | > xargs -J% objcopy % zlib.ko.debug > objcopy --only-keep-debug zlib.ko.debug zlib.ko.symbols > objcopy --strip-debug --add-gnu-debuglink=zlib.ko.symbols zlib.ko.debug zlib.ko > 1 error > *** Error code 2 > 1 error > *** Error code 2 > > Here's make.conf: > > SUP_UPDATE=yes > SUPFILE=/usr/share/examples/cvsup/stable-supfile > PORTSSUPFILE=/usr/share/examples/cvsup/ports-supfile > SUPHOST=cvsup5.us.freebsd.org > > #WITHOUT_X11=yes > > PORTS_MODULES=emulators/virtualbox-ose-kmod > > # ccache > .if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*)) && > !defined(NOCCACHE) > #CC=/usr/local/libexec/ccache/world-cc > #CXX=/usr/local/libexec/ccache/world-c++ > .endif > > # added by use.perl 2010-11-09 09:32:27 > PERL_VERSION=5.10.1 > > And src.conf: > > WITHOUT_PROFILE=true # Avoid compiling profiled libraries This is a log from a buildkernel and not like the subject insists as a buildworld. Can you please rebuild world and then try a buildkernel cd /usr/src make -DNOCCACHE -DALWAYS_CHECK_MAKE buildworld make -DNOCCACHE -DALWAYS_CHECK_MAKE buildkernel make -DNOCCACHE -DALWAYS_CHECK_MAKE installkernel Reboot & then: cd /usr/src make -DNOCCACHE installworld make -DNOCCACHE delete-old make -DNOCCACHE delete-old-libs You may also want to adjust that example ccache make.conf example sometime too as that will not always do what you expect it to do. -- jhell,v From owner-freebsd-stable@FreeBSD.ORG Wed Nov 10 05:07: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 73ABC106564A for ; Wed, 10 Nov 2010 05:07:39 +0000 (UTC) (envelope-from bryce@bryce.net) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 16E2B8FC0C for ; Wed, 10 Nov 2010 05:07:38 +0000 (UTC) Received: by wya21 with SMTP id 21so350112wya.13 for ; Tue, 09 Nov 2010 21:07:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.255.148 with SMTP id j20mr7821127wes.11.1289365657644; Tue, 09 Nov 2010 21:07:37 -0800 (PST) Received: by 10.216.172.209 with HTTP; Tue, 9 Nov 2010 21:07:37 -0800 (PST) In-Reply-To: <4CDA27D6.7040605@DataIX.net> References: <4CDA27D6.7040605@DataIX.net> Date: Tue, 9 Nov 2010 23:07:37 -0600 Message-ID: From: Bryce Edwards To: jhell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: 8-STABLE buildworld failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 05:07:39 -0000 On Tue, Nov 9, 2010 at 11:04 PM, jhell wrote: > On 11/09/2010 19:09, Bryce Edwards wrote: >> After updating source today, I am receiving the following error when >> running make NOCCACHE=3DYES -j16 buildkernel >> >> >> =3D=3D=3D> zlib (all) >> cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE >> -nostdinc =A0 -DHAVE_KERNEL_OPTION_HEADERS -include >> /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq >> -finline-limit=3D8000 --param inline-unit-growth=3D100 --param >> large-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer >> -I/usr/obj/usr/src/sys/GENERIC -mcmodel=3Dkernel -mno-red-zone >> -mfpmath=3D387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow >> -msoft-float -fno-asynchronous-unwind-tables -ffreestanding >> -fstack-protector -std=3Diso9899:1999 -fstack-protector -Wall >> -Wredundant-decls -Wnested-externs -Wstrict-prototypes >> -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual =A0-Wundef >> -Wno-pointer-sign -fformat-extensions -c >> /usr/src/sys/modules/zlib/../../net/zlib.c >> ld =A0-d -warn-common -r -d -o zlib.ko.debug zlib.o >> :> export_syms >> awk -f /usr/src/sys/conf/kmod_syms.awk zlib.ko.debug =A0export_syms | >> xargs -J% objcopy % zlib.ko.debug >> objcopy --only-keep-debug zlib.ko.debug zlib.ko.symbols >> objcopy --strip-debug --add-gnu-debuglink=3Dzlib.ko.symbols zlib.ko.debu= g zlib.ko >> 1 error >> *** Error code 2 >> 1 error >> *** Error code 2 >> >> Here's make.conf: >> >> SUP_UPDATE=3Dyes >> SUPFILE=3D/usr/share/examples/cvsup/stable-supfile >> PORTSSUPFILE=3D/usr/share/examples/cvsup/ports-supfile >> SUPHOST=3Dcvsup5.us.freebsd.org >> >> #WITHOUT_X11=3Dyes >> >> PORTS_MODULES=3Demulators/virtualbox-ose-kmod >> >> # ccache >> .if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*)) && >> !defined(NOCCACHE) >> #CC=3D/usr/local/libexec/ccache/world-cc >> #CXX=3D/usr/local/libexec/ccache/world-c++ >> .endif >> >> # added by use.perl 2010-11-09 09:32:27 >> PERL_VERSION=3D5.10.1 >> >> And src.conf: >> >> WITHOUT_PROFILE=3Dtrue =A0 =A0# Avoid compiling profiled libraries > > This is a log from a buildkernel and not like the subject insists as a > buildworld. Can you please rebuild world and then try a buildkernel > > cd /usr/src > make -DNOCCACHE -DALWAYS_CHECK_MAKE buildworld > make -DNOCCACHE -DALWAYS_CHECK_MAKE buildkernel > make -DNOCCACHE -DALWAYS_CHECK_MAKE installkernel > > Reboot & then: > cd /usr/src > make -DNOCCACHE installworld > make -DNOCCACHE delete-old > make -DNOCCACHE delete-old-libs > My apologies! The subject is wrong and it was during the buildkernel. The buildworld was done just prior just like your example and completed OK. The only difference is that I did not define ALWAYS_CHECK_MAKE. > > You may also want to adjust that example ccache make.conf example > sometime too as that will not always do what you expect it to do. > > -- > > =A0jhell,v > From owner-freebsd-stable@FreeBSD.ORG Wed Nov 10 05:15: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 9E7B3106566C for ; Wed, 10 Nov 2010 05:15:57 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4FC288FC17 for ; Wed, 10 Nov 2010 05:15:57 +0000 (UTC) Received: by gwj16 with SMTP id 16so128451gwj.13 for ; Tue, 09 Nov 2010 21:15:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=MhvpQGPL94W147yDZp/LwVWR8MMd0Z5pjoR5CeC7wmU=; b=Mlu13j80/Lywr1DPu/FpUHAaUUJmApQL5tKr2LTCcUIhFVfWdJD/ByMquhCWLO51Yt 9di3dMo63jhy5gJrJ6VBQmeB1LQiN8ZCOswifRYy4nHatXJT16lhu6KfKh1YGwlmI7sR cG0ZsjtQkX6WrNi8SVHL5vCxCWGTAcqBeqkow= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=bUKCBn7Z5VLBJ+rOnbcZ8qRI/krHJhf7uSk1K6jUESvbG46kaA1iUhEdYBrINvlZrN oJexJcAj4EvoP+oT3plYB5hRswkNF2/2qcnVfCEa0XrT1uFJZlxf9de8fXDSZjsLHKvi 2x3C6q4eXvIEMJr+MgAzi85Q4wUJM7ECW0t0c= Received: by 10.151.155.6 with SMTP id h6mr8462123ybo.59.1289366155348; Tue, 09 Nov 2010 21:15:55 -0800 (PST) Received: from centel.dataix.local (adsl-99-181-136-243.dsl.klmzmi.sbcglobal.net [99.181.136.243]) by mx.google.com with ESMTPS id n28sm227555yha.16.2010.11.09.21.15.53 (version=SSLv3 cipher=RC4-MD5); Tue, 09 Nov 2010 21:15:54 -0800 (PST) Sender: "J. Hellenthal" Message-ID: <4CDA2A88.6080708@DataIX.net> Date: Wed, 10 Nov 2010 00:15:52 -0500 From: jhell Organization: http://www.DataIX.net User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.12) Gecko/20101028 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Bryce Edwards References: <4CDA27D6.7040605@DataIX.net> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 8-STABLE buildworld failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 05:15:57 -0000 On 11/10/2010 00:07, Bryce Edwards wrote: > On Tue, Nov 9, 2010 at 11:04 PM, jhell wrote: >> On 11/09/2010 19:09, Bryce Edwards wrote: >>> After updating source today, I am receiving the following error when >>> running make NOCCACHE=YES -j16 buildkernel >>> >>> >>> ===> zlib (all) >>> cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE >>> -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include >>> /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq >>> -finline-limit=8000 --param inline-unit-growth=100 --param >>> large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer >>> -I/usr/obj/usr/src/sys/GENERIC -mcmodel=kernel -mno-red-zone >>> -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow >>> -msoft-float -fno-asynchronous-unwind-tables -ffreestanding >>> -fstack-protector -std=iso9899:1999 -fstack-protector -Wall >>> -Wredundant-decls -Wnested-externs -Wstrict-prototypes >>> -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef >>> -Wno-pointer-sign -fformat-extensions -c >>> /usr/src/sys/modules/zlib/../../net/zlib.c >>> ld -d -warn-common -r -d -o zlib.ko.debug zlib.o >>> :> export_syms >>> awk -f /usr/src/sys/conf/kmod_syms.awk zlib.ko.debug export_syms | >>> xargs -J% objcopy % zlib.ko.debug >>> objcopy --only-keep-debug zlib.ko.debug zlib.ko.symbols >>> objcopy --strip-debug --add-gnu-debuglink=zlib.ko.symbols zlib.ko.debug zlib.ko >>> 1 error >>> *** Error code 2 >>> 1 error >>> *** Error code 2 >>> >>> Here's make.conf: >>> >>> SUP_UPDATE=yes >>> SUPFILE=/usr/share/examples/cvsup/stable-supfile >>> PORTSSUPFILE=/usr/share/examples/cvsup/ports-supfile >>> SUPHOST=cvsup5.us.freebsd.org >>> >>> #WITHOUT_X11=yes >>> >>> PORTS_MODULES=emulators/virtualbox-ose-kmod >>> >>> # ccache >>> .if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*)) && >>> !defined(NOCCACHE) >>> #CC=/usr/local/libexec/ccache/world-cc >>> #CXX=/usr/local/libexec/ccache/world-c++ >>> .endif >>> >>> # added by use.perl 2010-11-09 09:32:27 >>> PERL_VERSION=5.10.1 >>> >>> And src.conf: >>> >>> WITHOUT_PROFILE=true # Avoid compiling profiled libraries >> >> This is a log from a buildkernel and not like the subject insists as a >> buildworld. Can you please rebuild world and then try a buildkernel >> >> cd /usr/src >> make -DNOCCACHE -DALWAYS_CHECK_MAKE buildworld >> make -DNOCCACHE -DALWAYS_CHECK_MAKE buildkernel >> make -DNOCCACHE -DALWAYS_CHECK_MAKE installkernel >> >> Reboot & then: >> cd /usr/src >> make -DNOCCACHE installworld >> make -DNOCCACHE delete-old >> make -DNOCCACHE delete-old-libs >> > > My apologies! The subject is wrong and it was during the buildkernel. > The buildworld was done just prior just like your example and > completed OK. The only difference is that I did not define > ALWAYS_CHECK_MAKE. > Also quoting UPDATING: 20101022: A workaround for a fixed ld bug has been removed in kernel code, so make sure that your system ld is built from sources after revision 211583 from 2010-08-21 (r210245 from 2010-07-19 if building stable/8 kernel on head, r211584 from 2010-08-21 for stable/7). A symptom of incorrect ld version is different addresses for set_pcpu section and __start_set_pcpu symbol in kernel and/or modules. >> >> You may also want to adjust that example ccache make.conf example >> sometime too as that will not always do what you expect it to do. >> >> -- >> >> jhell,v >> -- jhell,v From owner-freebsd-stable@FreeBSD.ORG Wed Nov 10 05:48: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 5F1EE106566B for ; Wed, 10 Nov 2010 05:48:52 +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 452D68FC17 for ; Wed, 10 Nov 2010 05:48:51 +0000 (UTC) Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta01.emeryville.ca.mail.comcast.net with comcast id VGos1f0031ZMdJ4A1Hor5J; Wed, 10 Nov 2010 05:48:51 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta16.emeryville.ca.mail.comcast.net with comcast id VHoq1f00C3LrwQ28cHoquT; Wed, 10 Nov 2010 05:48:51 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 7CC969B427; Tue, 9 Nov 2010 21:48:50 -0800 (PST) Date: Tue, 9 Nov 2010 21:48:50 -0800 From: Jeremy Chadwick To: Bryce Edwards Message-ID: <20101110054850.GA49976@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.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: 8-STABLE buildworld failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 05:48:52 -0000 On Tue, Nov 09, 2010 at 06:09:08PM -0600, Bryce Edwards wrote: > After updating source today, I am receiving the following error when > running make NOCCACHE=YES -j16 buildkernel Please re-run the buildkernel without any -j or -jXX flags to see where the actual error happened. The below doesn't show the actual error due to the nature of the parallel build. I doubt this has anything to do with ccache. > ===> zlib (all) > cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE > -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include > /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer > -I/usr/obj/usr/src/sys/GENERIC -mcmodel=kernel -mno-red-zone > -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow > -msoft-float -fno-asynchronous-unwind-tables -ffreestanding > -fstack-protector -std=iso9899:1999 -fstack-protector -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -c > /usr/src/sys/modules/zlib/../../net/zlib.c > ld -d -warn-common -r -d -o zlib.ko.debug zlib.o > :> export_syms > awk -f /usr/src/sys/conf/kmod_syms.awk zlib.ko.debug export_syms | > xargs -J% objcopy % zlib.ko.debug > objcopy --only-keep-debug zlib.ko.debug zlib.ko.symbols > objcopy --strip-debug --add-gnu-debuglink=zlib.ko.symbols zlib.ko.debug zlib.ko > 1 error > *** Error code 2 > 1 error > *** Error code 2 -- | 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 Nov 10 12:41: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 A5CB51065670 for ; Wed, 10 Nov 2010 12:41:07 +0000 (UTC) (envelope-from ykirill@yahoo.com) Received: from nm1.bullet.mail.ne1.yahoo.com (nm1.bullet.mail.ne1.yahoo.com [98.138.90.64]) by mx1.freebsd.org (Postfix) with SMTP id 68B338FC16 for ; Wed, 10 Nov 2010 12:41:07 +0000 (UTC) Received: from [98.138.90.53] by nm1.bullet.mail.ne1.yahoo.com with NNFMP; 10 Nov 2010 12:28:34 -0000 Received: from [98.138.89.164] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 10 Nov 2010 12:28:34 -0000 Received: from [127.0.0.1] by omp1020.mail.ne1.yahoo.com with NNFMP; 10 Nov 2010 12:28:34 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 558616.43830.bm@omp1020.mail.ne1.yahoo.com Received: (qmail 74042 invoked by uid 60001); 10 Nov 2010 12:21:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1289391672; bh=kqC7vp9WEXxLN5bwO+5L+2gPC90xYzZtBpqOyfxKGNs=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=5aJbjFJCMpb3owtuRNjaGr18ofm1Uy2Ntr1Yz8Y70DDNKIRNveni59avDEafESUTymqyljbY8P3wpGIgbbrKW39YOhYzBxxJsZnbby3TCDDxTvqstnw0rkP0q8e5KxaqgbOjsm8nUC2EU2MkrlxG990VMtVTmf/3x4Mk34mkugM= 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:MIME-Version:Content-Type; b=2FLOWj+l4t4Bh6K7Bp3KY0pFw+1JtsGeXlVzj6KIRioE6zn/wiya9QVUmZAIqZKNXix/ZrqWYz30/RqxtcUhEyF5RbX5k3+PU2w8C16jMzCQ5kdRqoDvLmrgHVVa/ybmY8aH3prTKM/pKr/m4h3qa78hqvzjgLPNPyNTivAKiPg=; Message-ID: <889823.70463.qm@web120506.mail.ne1.yahoo.com> X-YMail-OSG: jieGeCQVM1mkLVNzf8x8.2L3O5gcwoiJhHB.aMw6ZuO2jH6 xL1J28YEziwrQw_Skc7djNC35uG821g.ynqcGUdvEdTls9hoYVFYR6wrTfEy rKF6tWdlTRLOmPTHvl4aAh6TfSySo2e68vHWG2HTcqdagBQLWurskt5tyU6r 6UUNSs1M6QtkM.ZWkPwHrY1xufBrkpFx0n8uzOfGdQb6BDEZPQDtnIkDe0cn Yyo5fQFkUDcFOjL7c8fG2A3Nyz3N8kHiwhFOXq3Ku.5Zjf3UA1qDXAZbpVMW T0WIwq_toP4j0qoGoXzXlGfb7h2QABblrl0MD8g-- Received: from [212.74.229.235] by web120506.mail.ne1.yahoo.com via HTTP; Wed, 10 Nov 2010 04:21:12 PST X-Mailer: YahooMailClassic/11.4.7 YahooMailWebService/0.8.107.285259 Date: Wed, 10 Nov 2010 04:21:12 -0800 (PST) From: Kirill Yelizarov To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: icmp packets on em larger than 1472 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Nov 2010 12:41:07 -0000 Hi, All my em cards running 8.1 stable don't reply to icmp echo requests packets larger than 1472 bytes. On stable 7.2 the same hardware works as expected: # ping -s 1500 192.168.64.99 PING 192.168.64.99 (192.168.64.99): 1500 data bytes 1508 bytes from 192.168.64.99: icmp_seq=0 ttl=63 time=1.249 ms 1508 bytes from 192.168.64.99: icmp_seq=1 ttl=63 time=1.158 ms Here is the dump on em interface 15:06:31.452043 IP 192.168.66.65 > *****: ICMP echo request, id 28729, seq 5, length 1480 15:06:31.452047 IP 192.168.66.65 > ****: icmp 15:06:31.452069 IP **** > 192.168.66.65: ICMP echo reply, id 28729, seq 5, length 1480 15:06:31.452071 IP *** > 192.168.66.65: icmp Same ping from same source (it's a 8.1 stable with fxp interface) to em card running 8.1 stable #pciconf -lv em0@pci0:3:4:0: class=0x020000 card=0x10798086 chip=0x10798086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Dual Port Gigabit Ethernet Controller (82546EB)' class = network subclass = ethernet # ping -s 1472 192.168.64.200 PING 192.168.64.200 (192.168.64.200): 1472 data bytes 1480 bytes from 192.168.64.200: icmp_seq=0 ttl=63 time=0.848 ms ^C # ping -s 1473 192.168.64.200 PING 192.168.64.200 (192.168.64.200): 1473 data bytes ^C --- 192.168.64.200 ping statistics --- 4 packets transmitted, 0 packets received, 100.0% packet loss And here is it's dump on em card 5:11:15.191496 IP 192.168.66.65 > *****: ICMP echo request, id 33593, seq 0, length 1480 15:11:15.191534 IP 192.168.66.65 > *****: icmp 15:11:16.192119 IP 192.168.66.65 > *****: ICMP echo request, id 33593, seq 1, length 1480 15:11:16.192156 IP 192.168.66.65 > ******: icmp igb cards on 8.1 stable are not affected Regards, Kirill From owner-freebsd-stable@FreeBSD.ORG Wed Nov 10 12:59: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 C4264106564A for ; Wed, 10 Nov 2010 12:59:23 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by mx1.freebsd.org (Postfix) with ESMTP id A95658FC14 for ; Wed, 10 Nov 2010 12:59:23 +0000 (UTC) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta07.emeryville.ca.mail.comcast.net with comcast id VQs21f0040lTkoCA7QzPTE; Wed, 10 Nov 2010 12:59:23 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta04.emeryville.ca.mail.comcast.net with comcast id VQzN1f0073LrwQ28QQzNpM; Wed, 10 Nov 2010 12:59:22 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 2A83E9B427; Wed, 10 Nov 2010 04:59:22 -0800 (PST) Date: Wed, 10 Nov 2010 04:59:22 -0800 From: Jeremy Chadwick To: Kirill Yelizarov Message-ID: <20101110125922.GA59015@icarus.home.lan> References: <889823.70463.qm@web120506.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <889823.70463.qm@web120506.mail.ne1.yahoo.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org, Jack Vogel Subject: Re: icmp packets on em larger than 1472 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Nov 2010 12:59:23 -0000 On Wed, Nov 10, 2010 at 04:21:12AM -0800, Kirill Yelizarov wrote: > Hi, > > All my em cards running 8.1 stable don't reply to icmp echo requests packets larger than 1472 bytes. > > On stable 7.2 the same hardware works as expected: > # ping -s 1500 192.168.64.99 > PING 192.168.64.99 (192.168.64.99): 1500 data bytes > 1508 bytes from 192.168.64.99: icmp_seq=0 ttl=63 time=1.249 ms > 1508 bytes from 192.168.64.99: icmp_seq=1 ttl=63 time=1.158 ms > > Here is the dump on em interface > 15:06:31.452043 IP 192.168.66.65 > *****: ICMP echo request, id 28729, seq 5, length 1480 > 15:06:31.452047 IP 192.168.66.65 > ****: icmp > 15:06:31.452069 IP **** > 192.168.66.65: ICMP echo reply, id 28729, seq 5, length 1480 > 15:06:31.452071 IP *** > 192.168.66.65: icmp > > Same ping from same source (it's a 8.1 stable with fxp interface) to em card running 8.1 stable > #pciconf -lv > em0@pci0:3:4:0: class=0x020000 card=0x10798086 chip=0x10798086 rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Dual Port Gigabit Ethernet Controller (82546EB)' > class = network > subclass = ethernet > > # ping -s 1472 192.168.64.200 > PING 192.168.64.200 (192.168.64.200): 1472 data bytes > 1480 bytes from 192.168.64.200: icmp_seq=0 ttl=63 time=0.848 ms > ^C > > # ping -s 1473 192.168.64.200 > PING 192.168.64.200 (192.168.64.200): 1473 data bytes > ^C > --- 192.168.64.200 ping statistics --- > 4 packets transmitted, 0 packets received, 100.0% packet loss > > And here is it's dump on em card > 5:11:15.191496 IP 192.168.66.65 > *****: ICMP echo request, id 33593, seq 0, length 1480 > 15:11:15.191534 IP 192.168.66.65 > *****: icmp > 15:11:16.192119 IP 192.168.66.65 > *****: ICMP echo request, id 33593, seq 1, length 1480 > 15:11:16.192156 IP 192.168.66.65 > ******: icmp > > igb cards on 8.1 stable are not affected Please provide uname -a output from the machine with the emX devices, as well as relevant emX information from "dmesg" (e.g. driver version). "sysctl dev.em.X" might also be helpful. Thanks. -- | 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 Nov 10 13:55: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 0F053106564A for ; Wed, 10 Nov 2010 13:55:39 +0000 (UTC) (envelope-from ykirill@yahoo.com) Received: from nm2.bullet.mail.ne1.yahoo.com (nm2.bullet.mail.ne1.yahoo.com [98.138.90.65]) by mx1.freebsd.org (Postfix) with SMTP id B50968FC08 for ; Wed, 10 Nov 2010 13:55:38 +0000 (UTC) Received: from [98.138.90.57] by nm2.bullet.mail.ne1.yahoo.com with NNFMP; 10 Nov 2010 13:55:38 -0000 Received: from [98.138.89.164] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 10 Nov 2010 13:55:38 -0000 Received: from [127.0.0.1] by omp1020.mail.ne1.yahoo.com with NNFMP; 10 Nov 2010 13:55:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 51634.60094.bm@omp1020.mail.ne1.yahoo.com Received: (qmail 74821 invoked by uid 60001); 10 Nov 2010 13:55:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1289397337; bh=hTVlMubD79Bu7LktsEKFV/IpYsaWLZCLFcQgF7c9ELs=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=zDgbFumyITxYBvi2XXeZrOATuS9IiKo+VhU1QQIvsRg91A/bwZ+GY/lX79wF/ngLktp5RI1tAhP0DBcLLx2br2pZBvArzpbXy8cOPb/DqqpOC6AfaMg3rKAMvuVw15TJ2NAk6fvp40yhflHZk0WTOyCw7PViFwO3LA4G+H4FIM0= 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:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Y7lXUvoHqpFoKLi+0SBM/TbscsExGJSD5LZ7aadW0M43yxVcLq3ZK0NWnrMSzML3591cOKYBSNqQmLSedjHzAMFjkhGv0bC3qL0xrDiurmVcJuobuLbUwd//cAASi0p8EBWChXFw7DHSMZi0Ua9OG7d3ryWoSDf1dGz3M+Rssvk=; Message-ID: <852653.73197.qm@web120519.mail.ne1.yahoo.com> X-YMail-OSG: d91kHCkVM1mq8SExBmNZEGT6WiVUdmihg_Axcjjp2_ICM7P P.TjdB9yaQzrV.LkisQyeAxbHEdgU5R83ncU34WTeAra2a0yYaiYIMQBByz3 h7NLu80DKPsFCBsUxnbfrxsuvqZ2mzIO9eY3plK_Dq8BTICmawQRTAMfx1bR rfofeku4k7HRa2D9P5SBRfwemfHa3urU7CUPxaHNsNV9tVVQMitafSNJPkbL OqTe2R3ZmbduBXEuARcV11Mvhe2QhzCRvBepMUn812SF6xTDK24kLpXsh5nQ .Ck64gnxHZtzTscWqUTai Received: from [212.74.229.235] by web120519.mail.ne1.yahoo.com via HTTP; Wed, 10 Nov 2010 05:55:37 PST X-Mailer: YahooMailClassic/11.4.7 YahooMailWebService/0.8.107.285259 Date: Wed, 10 Nov 2010 05:55:37 -0800 (PST) From: Kirill Yelizarov To: freebsd-stable@freebsd.org In-Reply-To: <20101110125922.GA59015@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Jeremy Chadwick Subject: Re: icmp packets on em larger than 1472 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Nov 2010 13:55:39 -0000 =0A=0A--- On Wed, 11/10/10, Jeremy Chadwick wrot= e:=0A=0A> From: Jeremy Chadwick =0A> Subject: Re:= icmp packets on em larger than 1472=0A> To: "Kirill Yelizarov" =0A> Cc: freebsd-stable@freebsd.org, "Jack Vogel" =0A> Date: Wednesday, November 10, 2010, 3:59 PM=0A> On Wed, Nov 10, 2010= at 04:21:12AM=0A> -0800, Kirill Yelizarov wrote:=0A> > Hi,=0A> > =0A> > Al= l my em cards running 8.1 stable don't reply to icmp=0A> echo requests pack= ets larger than 1472 bytes.=0A> > =0A> > On stable 7.2 the same hardware wo= rks as expected:=0A> > # ping -s 1500 192.168.64.99=0A> > PING 192.168.64.9= 9 (192.168.64.99): 1500 data bytes=0A> > 1508 bytes from 192.168.64.99: icm= p_seq=3D0 ttl=3D63=0A> time=3D1.249 ms=0A> > 1508 bytes from 192.168.64.99:= icmp_seq=3D1 ttl=3D63=0A> time=3D1.158 ms=0A> > =0A> > Here is the dump on= em interface=0A> > 15:06:31.452043 IP 192.168.66.65 > *****: ICMP echo=0A>= request, id 28729, seq 5, length 1480=0A> > 15:06:31.452047 IP 192.168.66.= 65 > ****: icmp=0A> > 15:06:31.452069 IP **** > 192.168.66.65: ICMP echo=0A= > reply, id 28729, seq 5, length 1480=0A> > 15:06:31.452071 IP *** > 192.16= 8.66.65: icmp=0A> >=A0 =0A> > Same ping from same source (it's a 8.1 stable= with fxp=0A> interface) to em card running 8.1 stable=0A> > #pciconf -lv= =0A> > em0@pci0:3:4:0:=A0=A0=A0 class=3D0x020000=0A> card=3D0x10798086 chip= =3D0x10798086 rev=3D0x03 hdr=3D0x00=0A> >=A0 =A0=A0=A0vendor=A0=0A> =A0=A0= =A0=3D 'Intel Corporation'=0A> >=A0 =A0=A0=A0device=A0=0A> =A0=A0=A0=3D 'Du= al Port Gigabit Ethernet Controller=0A> (82546EB)'=0A> >=A0 =A0=A0=A0class= =A0 =A0 =A0 =3D=0A> network=0A> >=A0 =A0=A0=A0subclass=A0=A0=A0=3D=0A> ethe= rnet=0A> > =0A> > # ping -s 1472 192.168.64.200=0A> > PING 192.168.64.200 (= 192.168.64.200): 1472 data bytes=0A> > 1480 bytes from 192.168.64.200: icmp= _seq=3D0 ttl=3D63=0A> time=3D0.848 ms=0A> > ^C=0A> > =0A> > # ping -s 1473 = 192.168.64.200=0A> > PING 192.168.64.200 (192.168.64.200): 1473 data bytes= =0A> > ^C=0A> > --- 192.168.64.200 ping statistics ---=0A> > 4 packets tran= smitted, 0 packets received, 100.0%=0A> packet loss=0A> > =0A> > And here i= s it's dump on em card=0A> > 5:11:15.191496 IP 192.168.66.65 > *****: ICMP = echo=0A> request, id 33593, seq 0, length 1480=0A> > 15:11:15.191534 IP 192= .168.66.65 > *****: icmp=0A> > 15:11:16.192119 IP 192.168.66.65 > *****: IC= MP echo=0A> request, id 33593, seq 1, length 1480=0A> > 15:11:16.192156 IP = 192.168.66.65 > ******: icmp=0A> > =0A> > igb cards on 8.1 stable are not a= ffected=0A> =0A> Please provide uname -a output from the machine with the= =0A> emX devices, as=0A> well as relevant emX information from "dmesg" (e.g= . driver=0A> version).=0A> "sysctl dev.em.X" might also be helpful.=0A> =0A= =0AHere are the two examples=0A=0Auname -a=0AFreeBSD border1 8.1-STABLE Fre= eBSD 8.1-STABLE #0: Thu Aug 26 16:54:15 MSD 2010 root@border1:/usr/obj/= usr/src/sys/BORDER1 amd64=0A=0AOct 22 14:36:18 border1 kernel: em0: port 0xdc00-0xdc3f mem 0xfcfc= 0000-0xfcfdffff irq 54 at device 4.0 on pci3=0AOct 22 14:36:18 border1 kern= el: em0: [FILTER]=0AOct 22 14:36:18 border1 kernel: em0: Ethernet address: = 00:04:23:cc:df:ea=0AOct 22 14:36:18 border1 kernel: em1: port 0xdc80-0xdcbf mem 0xfcfe0000-0xfcfff= fff irq 55 at device 4.1 on pci3=0AOct 22 14:36:18 border1 kernel: em1: [FI= LTER]=0AOct 22 14:36:18 border1 kernel: em1: Ethernet address: 00:04:23:cc:= df:eb=0A=0Adev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.0.5=0Adev= .em.0.%driver: em=0Adev.em.0.%location: slot=3D0 function=3D0 handle=3D\_SB= _.PCI0.MRP1.HART=0Adev.em.0.%pnpinfo: vendor=3D0x8086 device=3D0x10d3 subve= ndor=3D0x8086 subdevice=3D0x34da class=3D0x020000=0Adev.em.0.%parent: pci1= =0Adev.em.0.nvm: -1=0Adev.em.0.rx_int_delay: 66=0Adev.em.0.tx_int_delay: 66= =0Adev.em.0.rx_abs_int_delay: 250=0Adev.em.0.tx_abs_int_delay: 250=0Adev.em= .0.rx_processing_limit: -1=0Adev.em.0.link_irq: 0=0Adev.em.0.mbuf_alloc_fai= l: 0=0Adev.em.0.cluster_alloc_fail: 0=0Adev.em.0.dropped: 0=0Adev.em.0.tx_d= ma_fail: 0=0Adev.em.0.rx_overruns: 0=0Adev.em.0.watchdog_timeouts: 0=0Adev.= em.0.device_control: 1477444168=0Adev.em.0.rx_control: 67141634=0Adev.em.0.= fc_high_water: 18432=0Adev.em.0.fc_low_water: 16932=0Adev.em.0.queue0.txd_h= ead: 2757=0Adev.em.0.queue0.txd_tail: 2758=0Adev.em.0.queue0.tx_irq: 0=0Ade= v.em.0.queue0.no_desc_avail: 0=0Adev.em.0.queue0.rxd_head: 1419=0Adev.em.0.= queue0.rxd_tail: 1418=0Adev.em.0.queue0.rx_irq: 0=0Adev.em.0.mac_stats.exce= ss_coll: 0=0Adev.em.0.mac_stats.single_coll: 0=0Adev.em.0.mac_stats.multipl= e_coll: 0=0Adev.em.0.mac_stats.late_coll: 0=0Adev.em.0.mac_stats.collision_= count: 0=0Adev.em.0.mac_stats.symbol_errors: 0=0Adev.em.0.mac_stats.sequenc= e_errors: 0=0Adev.em.0.mac_stats.defer_count: 0=0Adev.em.0.mac_stats.missed= _packets: 0=0Adev.em.0.mac_stats.recv_no_buff: 0=0Adev.em.0.mac_stats.recv_= undersize: 0=0Adev.em.0.mac_stats.recv_fragmented: 0=0Adev.em.0.mac_stats.r= ecv_oversize: 0=0Adev.em.0.mac_stats.recv_jabber: 0=0Adev.em.0.mac_stats.re= cv_errs: 0=0Adev.em.0.mac_stats.crc_errs: 0=0Adev.em.0.mac_stats.alignment_= errs: 0=0Adev.em.0.mac_stats.coll_ext_errs: 0=0Adev.em.0.mac_stats.xon_recv= d: 0=0Adev.em.0.mac_stats.xon_txd: 0=0Adev.em.0.mac_stats.xoff_recvd: 0=0Ad= ev.em.0.mac_stats.xoff_txd: 0=0Adev.em.0.mac_stats.total_pkts_recvd: 153436= 9705=0Adev.em.0.mac_stats.good_pkts_recvd: 1534369705=0Adev.em.0.mac_stats.= bcast_pkts_recvd: 197891=0Adev.em.0.mac_stats.mcast_pkts_recvd: 0=0Adev.em.= 0.mac_stats.rx_frames_64: 1528844=0Adev.em.0.mac_stats.rx_frames_65_127: 46= 6039874=0Adev.em.0.mac_stats.rx_frames_128_255: 363351691=0Adev.em.0.mac_st= ats.rx_frames_256_511: 34424761=0Adev.em.0.mac_stats.rx_frames_512_1023: 53= 013458=0Adev.em.0.mac_stats.rx_frames_1024_1522: 616011077=0Adev.em.0.mac_s= tats.good_octets_recvd: 1076352218193=0Adev.em.0.mac_stats.good_octets_txd:= 222914134983=0Adev.em.0.mac_stats.total_pkts_txd: 1750421340=0Adev.em.0.ma= c_stats.good_pkts_txd: 1750421339=0Adev.em.0.mac_stats.bcast_pkts_txd: 995= =0Adev.em.0.mac_stats.mcast_pkts_txd: 0=0Adev.em.0.mac_stats.tx_frames_64: = 591494=0Adev.em.0.mac_stats.tx_frames_65_127: 1309064841=0Adev.em.0.mac_sta= ts.tx_frames_128_255: 320875656=0Adev.em.0.mac_stats.tx_frames_256_511: 846= 63967=0Adev.em.0.mac_stats.tx_frames_512_1023: 14057851=0Adev.em.0.mac_stat= s.tx_frames_1024_1522: 21167531=0Adev.em.0.mac_stats.tso_txd: 0=0Adev.em.0.= mac_stats.tso_ctx_fail: 0=0Adev.em.0.interrupts.asserts: 1080194011=0Adev.e= m.0.interrupts.rx_pkt_timer: 96628=0Adev.em.0.interrupts.rx_abs_timer: 0=0A= dev.em.0.interrupts.tx_pkt_timer: 36686=0Adev.em.0.interrupts.tx_abs_timer:= 4=0Adev.em.0.interrupts.tx_queue_empty: 0=0Adev.em.0.interrupts.tx_queue_m= in_thresh: 0=0Adev.em.0.interrupts.rx_desc_min_thresh: 0=0Adev.em.0.interru= pts.rx_overrun: 0=0Adev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.= 0.5=0Adev.em.1.%driver: em=0Adev.em.1.%location: slot=3D25 function=3D0 han= dle=3D\_SB_.PCI0.ILAN=0Adev.em.1.%pnpinfo: vendor=3D0x8086 device=3D0x10cc = subvendor=3D0x8086 subdevice=3D0x34da class=3D0x020000=0Adev.em.1.%parent: = pci0=0Adev.em.1.nvm: -1=0Adev.em.1.rx_int_delay: 66=0Adev.em.1.tx_int_delay= : 66=0Adev.em.1.rx_abs_int_delay: 250=0Adev.em.1.tx_abs_int_delay: 250=0Ade= v.em.1.rx_processing_limit: -1=0Adev.em.1.link_irq: 0=0Adev.em.1.mbuf_alloc= _fail: 0=0Adev.em.1.cluster_alloc_fail: 0=0Adev.em.1.dropped: 0=0Adev.em.1.= tx_dma_fail: 0=0Adev.em.1.rx_overruns: 0=0Adev.em.1.watchdog_timeouts: 0=0A= dev.em.1.device_control: 1477444160=0Adev.em.1.rx_control: 67141634=0Adev.e= m.1.fc_high_water: 8192=0Adev.em.1.fc_low_water: 6692=0Adev.em.1.queue0.txd= _head: 3081=0Adev.em.1.queue0.txd_tail: 3081=0Adev.em.1.queue0.tx_irq: 0=0A= dev.em.1.queue0.no_desc_avail: 0=0Adev.em.1.queue0.rxd_head: 2535=0Adev.em.= 1.queue0.rxd_tail: 2534=0Adev.em.1.queue0.rx_irq: 0=0Adev.em.1.mac_stats.ex= cess_coll: 0=0Adev.em.1.mac_stats.single_coll: 665694=0Adev.em.1.mac_stats.= multiple_coll: 238794=0Adev.em.1.mac_stats.late_coll: 591710=0Adev.em.1.mac= _stats.collision_count: 1262634=0Adev.em.1.mac_stats.symbol_errors: 0=0Adev= .em.1.mac_stats.sequence_errors: 0=0Adev.em.1.mac_stats.defer_count: 629570= 46=0Adev.em.1.mac_stats.missed_packets: 0=0Adev.em.1.mac_stats.recv_no_buff= : 0=0Adev.em.1.mac_stats.recv_undersize: 0=0Adev.em.1.mac_stats.recv_fragme= nted: 0=0Adev.em.1.mac_stats.recv_oversize: 0=0Adev.em.1.mac_stats.recv_jab= ber: 0=0Adev.em.1.mac_stats.recv_errs: 0=0Adev.em.1.mac_stats.crc_errs: 0= =0Adev.em.1.mac_stats.alignment_errs: 0=0Adev.em.1.mac_stats.coll_ext_errs:= 0=0Adev.em.1.mac_stats.xon_recvd: 0=0Adev.em.1.mac_stats.xon_txd: 0=0Adev.= em.1.mac_stats.xoff_recvd: 0=0Adev.em.1.mac_stats.xoff_txd: 0=0Adev.em.1.ma= c_stats.total_pkts_recvd: 143055129=0Adev.em.1.mac_stats.good_pkts_recvd: 1= 43055129=0Adev.em.1.mac_stats.bcast_pkts_recvd: 19788=0Adev.em.1.mac_stats.= mcast_pkts_recvd: 0=0Adev.em.1.mac_stats.rx_frames_64: 0=0Adev.em.1.mac_sta= ts.rx_frames_65_127: 0=0Adev.em.1.mac_stats.rx_frames_128_255: 0=0Adev.em.1= .mac_stats.rx_frames_256_511: 0=0Adev.em.1.mac_stats.rx_frames_512_1023: 0= =0Adev.em.1.mac_stats.rx_frames_1024_1522: 0=0Adev.em.1.mac_stats.good_octe= ts_recvd: 35245157589=0Adev.em.1.mac_stats.good_octets_txd: 175509471230=0A= dev.em.1.mac_stats.total_pkts_txd: 210873641=0Adev.em.1.mac_stats.good_pkts= _txd: 210873641=0Adev.em.1.mac_stats.bcast_pkts_txd: 151=0Adev.em.1.mac_sta= ts.mcast_pkts_txd: 0=0Adev.em.1.mac_stats.tx_frames_64: 0=0Adev.em.1.mac_st= ats.tx_frames_65_127: 0=0Adev.em.1.mac_stats.tx_frames_128_255: 0=0Adev.em.= 1.mac_stats.tx_frames_256_511: 0=0Adev.em.1.mac_stats.tx_frames_512_1023: 0= =0Adev.em.1.mac_stats.tx_frames_1024_1522: 0=0Adev.em.1.mac_stats.tso_txd: = 0=0Adev.em.1.mac_stats.tso_ctx_fail: 0=0Adev.em.1.interrupts.asserts: 26472= 5703=0Adev.em.1.interrupts.rx_pkt_timer: 0=0Adev.em.1.interrupts.rx_abs_tim= er: 0=0Adev.em.1.interrupts.tx_pkt_timer: 0=0Adev.em.1.interrupts.tx_abs_ti= mer: 0=0Adev.em.1.interrupts.tx_queue_empty: 0=0Adev.em.1.interrupts.tx_que= ue_min_thresh: 0=0Adev.em.1.interrupts.rx_desc_min_thresh: 0=0Adev.em.1.int= errupts.rx_overrun: 0=0Adev.em.1.wake: 0=0A=0A=0A=0Auname -a=0AFreeBSD web2= 8.1-STABLE FreeBSD 8.1-STABLE #0: Thu Oct 21 17:24:16 MSD 2010 root@fl= ash-srv:/usr/obj/nanobsd.WEB2_C7899_H16_S63/usr/src/sys/WEB2 amd64=0A=0AOc= t 22 13:06:51 web2 kernel: em0: port 0x1000-0x101f mem 0xb1a00000-0xb1a1ffff,0xb1900000-0xb19fffff,0xb1a2= 0000-0xb1a23fff irq 28 at device 0.0 on pci1=0AOct 22 13:06:51 web2 kernel:= em0: Using MSI interrupt=0AOct 22 13:06:51 web2 kernel: em0: [FILTER]=0AOc= t 22 13:06:51 web2 kernel: em0: Ethernet address: 00:15:17:ac:e5:bd=0AOct 2= 2 13:06:51 web2 kernel: em1: p= ort 0x20e0-0x20ff mem 0xb1b00000-0xb1b1ffff,0xb1b43000-0xb1b43fff irq 20 at= device 25.0 on pci0=0AOct 22 13:06:51 web2 kernel: em1: Using MSI interrup= t=0AOct 22 13:06:51 web2 kernel: em1: [FILTER]=0AOct 22 13:06:51 web2 kerne= l: em1: Ethernet address: 00:15:17:ac:e5:bc=0AOct 22 13:06:51 web2 kernel: = Starting Network: lo0 em0 em1.=0AOct 22 13:06:51 web2 kernel: em0: flags=3D= 8843 metric 0 mtu 1500=0AOct 22 13:= 06:51 web2 kernel: em1: flags=3D8843 metric 0 mtu 1500=0AOct 22 13:06:53 web2 kernel: em1: link state changed = to UP=0AOct 22 13:06:54 web2 kernel: em0: link state changed to UP=0A=0A=0A= dev.em.0.%desc: Intel(R) PRO/1000 Legacy Network Connection 1.0.1=0Adev.em.= 0.%driver: em=0Adev.em.0.%location: slot=3D4 function=3D0=0Adev.em.0.%pnpin= fo: vendor=3D0x8086 device=3D0x1079 subvendor=3D0x8086 subdevice=3D0x1079 c= lass=3D0x020000=0Adev.em.0.%parent: pci3=0Adev.em.0.debug: -1=0Adev.em.0.st= ats: -1=0Adev.em.0.rx_int_delay: 66=0Adev.em.0.tx_int_delay: 66=0Adev.em.0.= rx_abs_int_delay: 250=0Adev.em.0.tx_abs_int_delay: 250=0Adev.em.0.rx_proces= sing_limit: -1=0Adev.em.1.%desc: Intel(R) PRO/1000 Legacy Network Connectio= n 1.0.1=0Adev.em.1.%driver: em=0Adev.em.1.%location: slot=3D4 function=3D1= =0Adev.em.1.%pnpinfo: vendor=3D0x8086 device=3D0x1079 subvendor=3D0x8086 su= bdevice=3D0x1079 class=3D0x020000=0Adev.em.1.%parent: pci3=0Adev.em.1.debug= : -1=0Adev.em.1.stats: -1=0Adev.em.1.rx_int_delay: 66=0Adev.em.1.tx_int_del= ay: 66=0Adev.em.1.rx_abs_int_delay: 250=0Adev.em.1.tx_abs_int_delay: 250=0A= dev.em.1.rx_processing_limit: -1=0A=0AKirill=0A=0A=0A> Thanks.=0A> =0A> -- = =0A> | Jeremy Chadwick=A0 =A0 =A0 =A0 =A0 =A0=0A> =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0=0A> =A0 =A0 =A0=A0=A0jdc@parodius.com=0A> |=0A> | Parodius Networki= ng=A0 =A0 =A0 =A0 =A0=0A> =A0 =A0 =A0 =A0 =A0 =A0=A0=A0http://www.parodius.= com/ |=0A> | UNIX Systems Administrator=A0 =A0 =A0 =A0=0A> =A0 =A0 =A0 =A0 = =A0 Mountain View, CA, USA |=0A> | Making life hard for others since 1977.= =A0 =A0=0A> =A0 =A0 =A0 =A0 =A0 PGP: 4BD6C0CB |=0A> =0A> __________________= _____________________________=0A> freebsd-stable@freebsd.org=0A> mailing li= st=0A> http://lists.freebsd.org/mailman/listinfo/freebsd-stable=0A> To unsu= bscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"=0A> =0A= =0A From owner-freebsd-stable@FreeBSD.ORG Wed Nov 10 18:48:22 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 010051065696 for ; Wed, 10 Nov 2010 18:48:22 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 51C538FC1D for ; Wed, 10 Nov 2010 18:48:20 +0000 (UTC) Received: by fxm19 with SMTP id 19so648267fxm.13 for ; Wed, 10 Nov 2010 10:48:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=gel0YgsgtCFEwQdXKHpdeDIMFP5QuMtpqaBWzna2d6E=; b=Ik/Rx3F2oa81Yxxz6iKoJB6Dys5hxhjZYUzNlwsNmoY1oN4OGxbWtUYpRIIjfsBpxh ehg6ajmlO8NdEAmuc0YhaoALXiRGg2F0xLBKaA8Uvu7gCpN189mFBD486JoczEX5BQz9 NxJKcJyR0t6a761IH2yMCP+NtzY9xZIpOQpzA= 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=DBUVspKDSMfDMhJWjziBIQwX9ZnOVXhue7JKoVHoEtKcbfk1QJF7cLm/t8nUrObk/9 WE3q0Q5FJq5YKr1ANiezy8IPOUGhjTu8yzQcHCCB4+c0cUWKiBfQFzPdCkWSNgW3+UAB Q1HOK9rgONhSYstXD/2g9soZFwLhjwjmmZJ24= MIME-Version: 1.0 Received: by 10.216.50.11 with SMTP id y11mr8688780web.57.1289414899355; Wed, 10 Nov 2010 10:48:19 -0800 (PST) Received: by 10.216.2.206 with HTTP; Wed, 10 Nov 2010 10:48:19 -0800 (PST) In-Reply-To: <852653.73197.qm@web120519.mail.ne1.yahoo.com> References: <20101110125922.GA59015@icarus.home.lan> <852653.73197.qm@web120519.mail.ne1.yahoo.com> Date: Wed, 10 Nov 2010 10:48:19 -0800 Message-ID: From: Jack Vogel To: Kirill Yelizarov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: icmp packets on em larger than 1472 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Nov 2010 18:48:22 -0000 Try the code from HEAD, I've run that on a 82546 and it worked ok. Jack On Wed, Nov 10, 2010 at 5:55 AM, Kirill Yelizarov wrote: > > > --- On Wed, 11/10/10, Jeremy Chadwick wrote: > > > From: Jeremy Chadwick > > Subject: Re: icmp packets on em larger than 1472 > > To: "Kirill Yelizarov" > > Cc: freebsd-stable@freebsd.org, "Jack Vogel" > > Date: Wednesday, November 10, 2010, 3:59 PM > > On Wed, Nov 10, 2010 at 04:21:12AM > > -0800, Kirill Yelizarov wrote: > > > Hi, > > > > > > All my em cards running 8.1 stable don't reply to icmp > > echo requests packets larger than 1472 bytes. > > > > > > On stable 7.2 the same hardware works as expected: > > > # ping -s 1500 192.168.64.99 > > > PING 192.168.64.99 (192.168.64.99): 1500 data bytes > > > 1508 bytes from 192.168.64.99: icmp_seq=0 ttl=63 > > time=1.249 ms > > > 1508 bytes from 192.168.64.99: icmp_seq=1 ttl=63 > > time=1.158 ms > > > > > > Here is the dump on em interface > > > 15:06:31.452043 IP 192.168.66.65 > *****: ICMP echo > > request, id 28729, seq 5, length 1480 > > > 15:06:31.452047 IP 192.168.66.65 > ****: icmp > > > 15:06:31.452069 IP **** > 192.168.66.65: ICMP echo > > reply, id 28729, seq 5, length 1480 > > > 15:06:31.452071 IP *** > 192.168.66.65: icmp > > > > > > Same ping from same source (it's a 8.1 stable with fxp > > interface) to em card running 8.1 stable > > > #pciconf -lv > > > em0@pci0:3:4:0: class=0x020000 > > card=0x10798086 chip=0x10798086 rev=0x03 hdr=0x00 > > > vendor > > = 'Intel Corporation' > > > device > > = 'Dual Port Gigabit Ethernet Controller > > (82546EB)' > > > class = > > network > > > subclass = > > ethernet > > > > > > # ping -s 1472 192.168.64.200 > > > PING 192.168.64.200 (192.168.64.200): 1472 data bytes > > > 1480 bytes from 192.168.64.200: icmp_seq=0 ttl=63 > > time=0.848 ms > > > ^C > > > > > > # ping -s 1473 192.168.64.200 > > > PING 192.168.64.200 (192.168.64.200): 1473 data bytes > > > ^C > > > --- 192.168.64.200 ping statistics --- > > > 4 packets transmitted, 0 packets received, 100.0% > > packet loss > > > > > > And here is it's dump on em card > > > 5:11:15.191496 IP 192.168.66.65 > *****: ICMP echo > > request, id 33593, seq 0, length 1480 > > > 15:11:15.191534 IP 192.168.66.65 > *****: icmp > > > 15:11:16.192119 IP 192.168.66.65 > *****: ICMP echo > > request, id 33593, seq 1, length 1480 > > > 15:11:16.192156 IP 192.168.66.65 > ******: icmp > > > > > > igb cards on 8.1 stable are not affected > > > > Please provide uname -a output from the machine with the > > emX devices, as > > well as relevant emX information from "dmesg" (e.g. driver > > version). > > "sysctl dev.em.X" might also be helpful. > > > > Here are the two examples > > uname -a > FreeBSD border1 8.1-STABLE FreeBSD 8.1-STABLE #0: Thu Aug 26 16:54:15 MSD > 2010 root@border1:/usr/obj/usr/src/sys/BORDER1 amd64 > > Oct 22 14:36:18 border1 kernel: em0: Connection 1.0.1> port 0xdc00-0xdc3f mem 0xfcfc0000-0xfcfdffff irq 54 at > device 4.0 on pci3 > Oct 22 14:36:18 border1 kernel: em0: [FILTER] > Oct 22 14:36:18 border1 kernel: em0: Ethernet address: 00:04:23:cc:df:ea > Oct 22 14:36:18 border1 kernel: em1: Connection 1.0.1> port 0xdc80-0xdcbf mem 0xfcfe0000-0xfcffffff irq 55 at > device 4.1 on pci3 > Oct 22 14:36:18 border1 kernel: em1: [FILTER] > Oct 22 14:36:18 border1 kernel: em1: Ethernet address: 00:04:23:cc:df:eb > > dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.0.5 > dev.em.0.%driver: em > dev.em.0.%location: slot=0 function=0 handle=\_SB_.PCI0.MRP1.HART > dev.em.0.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x8086 > subdevice=0x34da class=0x020000 > dev.em.0.%parent: pci1 > dev.em.0.nvm: -1 > dev.em.0.rx_int_delay: 66 > dev.em.0.tx_int_delay: 66 > dev.em.0.rx_abs_int_delay: 250 > dev.em.0.tx_abs_int_delay: 250 > dev.em.0.rx_processing_limit: -1 > dev.em.0.link_irq: 0 > dev.em.0.mbuf_alloc_fail: 0 > dev.em.0.cluster_alloc_fail: 0 > dev.em.0.dropped: 0 > dev.em.0.tx_dma_fail: 0 > dev.em.0.rx_overruns: 0 > dev.em.0.watchdog_timeouts: 0 > dev.em.0.device_control: 1477444168 > dev.em.0.rx_control: 67141634 > dev.em.0.fc_high_water: 18432 > dev.em.0.fc_low_water: 16932 > dev.em.0.queue0.txd_head: 2757 > dev.em.0.queue0.txd_tail: 2758 > dev.em.0.queue0.tx_irq: 0 > dev.em.0.queue0.no_desc_avail: 0 > dev.em.0.queue0.rxd_head: 1419 > dev.em.0.queue0.rxd_tail: 1418 > dev.em.0.queue0.rx_irq: 0 > dev.em.0.mac_stats.excess_coll: 0 > dev.em.0.mac_stats.single_coll: 0 > dev.em.0.mac_stats.multiple_coll: 0 > dev.em.0.mac_stats.late_coll: 0 > dev.em.0.mac_stats.collision_count: 0 > dev.em.0.mac_stats.symbol_errors: 0 > dev.em.0.mac_stats.sequence_errors: 0 > dev.em.0.mac_stats.defer_count: 0 > dev.em.0.mac_stats.missed_packets: 0 > dev.em.0.mac_stats.recv_no_buff: 0 > dev.em.0.mac_stats.recv_undersize: 0 > dev.em.0.mac_stats.recv_fragmented: 0 > dev.em.0.mac_stats.recv_oversize: 0 > dev.em.0.mac_stats.recv_jabber: 0 > dev.em.0.mac_stats.recv_errs: 0 > dev.em.0.mac_stats.crc_errs: 0 > dev.em.0.mac_stats.alignment_errs: 0 > dev.em.0.mac_stats.coll_ext_errs: 0 > dev.em.0.mac_stats.xon_recvd: 0 > dev.em.0.mac_stats.xon_txd: 0 > dev.em.0.mac_stats.xoff_recvd: 0 > dev.em.0.mac_stats.xoff_txd: 0 > dev.em.0.mac_stats.total_pkts_recvd: 1534369705 > dev.em.0.mac_stats.good_pkts_recvd: 1534369705 > dev.em.0.mac_stats.bcast_pkts_recvd: 197891 > dev.em.0.mac_stats.mcast_pkts_recvd: 0 > dev.em.0.mac_stats.rx_frames_64: 1528844 > dev.em.0.mac_stats.rx_frames_65_127: 466039874 > dev.em.0.mac_stats.rx_frames_128_255: 363351691 > dev.em.0.mac_stats.rx_frames_256_511: 34424761 > dev.em.0.mac_stats.rx_frames_512_1023: 53013458 > dev.em.0.mac_stats.rx_frames_1024_1522: 616011077 > dev.em.0.mac_stats.good_octets_recvd: 1076352218193 > dev.em.0.mac_stats.good_octets_txd: 222914134983 > dev.em.0.mac_stats.total_pkts_txd: 1750421340 > dev.em.0.mac_stats.good_pkts_txd: 1750421339 > dev.em.0.mac_stats.bcast_pkts_txd: 995 > dev.em.0.mac_stats.mcast_pkts_txd: 0 > dev.em.0.mac_stats.tx_frames_64: 591494 > dev.em.0.mac_stats.tx_frames_65_127: 1309064841 > dev.em.0.mac_stats.tx_frames_128_255: 320875656 > dev.em.0.mac_stats.tx_frames_256_511: 84663967 > dev.em.0.mac_stats.tx_frames_512_1023: 14057851 > dev.em.0.mac_stats.tx_frames_1024_1522: 21167531 > dev.em.0.mac_stats.tso_txd: 0 > dev.em.0.mac_stats.tso_ctx_fail: 0 > dev.em.0.interrupts.asserts: 1080194011 > dev.em.0.interrupts.rx_pkt_timer: 96628 > dev.em.0.interrupts.rx_abs_timer: 0 > dev.em.0.interrupts.tx_pkt_timer: 36686 > dev.em.0.interrupts.tx_abs_timer: 4 > dev.em.0.interrupts.tx_queue_empty: 0 > dev.em.0.interrupts.tx_queue_min_thresh: 0 > dev.em.0.interrupts.rx_desc_min_thresh: 0 > dev.em.0.interrupts.rx_overrun: 0 > dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.0.5 > dev.em.1.%driver: em > dev.em.1.%location: slot=25 function=0 handle=\_SB_.PCI0.ILAN > dev.em.1.%pnpinfo: vendor=0x8086 device=0x10cc subvendor=0x8086 > subdevice=0x34da class=0x020000 > dev.em.1.%parent: pci0 > dev.em.1.nvm: -1 > dev.em.1.rx_int_delay: 66 > dev.em.1.tx_int_delay: 66 > dev.em.1.rx_abs_int_delay: 250 > dev.em.1.tx_abs_int_delay: 250 > dev.em.1.rx_processing_limit: -1 > dev.em.1.link_irq: 0 > dev.em.1.mbuf_alloc_fail: 0 > dev.em.1.cluster_alloc_fail: 0 > dev.em.1.dropped: 0 > dev.em.1.tx_dma_fail: 0 > dev.em.1.rx_overruns: 0 > dev.em.1.watchdog_timeouts: 0 > dev.em.1.device_control: 1477444160 > dev.em.1.rx_control: 67141634 > dev.em.1.fc_high_water: 8192 > dev.em.1.fc_low_water: 6692 > dev.em.1.queue0.txd_head: 3081 > dev.em.1.queue0.txd_tail: 3081 > dev.em.1.queue0.tx_irq: 0 > dev.em.1.queue0.no_desc_avail: 0 > dev.em.1.queue0.rxd_head: 2535 > dev.em.1.queue0.rxd_tail: 2534 > dev.em.1.queue0.rx_irq: 0 > dev.em.1.mac_stats.excess_coll: 0 > dev.em.1.mac_stats.single_coll: 665694 > dev.em.1.mac_stats.multiple_coll: 238794 > dev.em.1.mac_stats.late_coll: 591710 > dev.em.1.mac_stats.collision_count: 1262634 > dev.em.1.mac_stats.symbol_errors: 0 > dev.em.1.mac_stats.sequence_errors: 0 > dev.em.1.mac_stats.defer_count: 62957046 > dev.em.1.mac_stats.missed_packets: 0 > dev.em.1.mac_stats.recv_no_buff: 0 > dev.em.1.mac_stats.recv_undersize: 0 > dev.em.1.mac_stats.recv_fragmented: 0 > dev.em.1.mac_stats.recv_oversize: 0 > dev.em.1.mac_stats.recv_jabber: 0 > dev.em.1.mac_stats.recv_errs: 0 > dev.em.1.mac_stats.crc_errs: 0 > dev.em.1.mac_stats.alignment_errs: 0 > dev.em.1.mac_stats.coll_ext_errs: 0 > dev.em.1.mac_stats.xon_recvd: 0 > dev.em.1.mac_stats.xon_txd: 0 > dev.em.1.mac_stats.xoff_recvd: 0 > dev.em.1.mac_stats.xoff_txd: 0 > dev.em.1.mac_stats.total_pkts_recvd: 143055129 > dev.em.1.mac_stats.good_pkts_recvd: 143055129 > dev.em.1.mac_stats.bcast_pkts_recvd: 19788 > dev.em.1.mac_stats.mcast_pkts_recvd: 0 > dev.em.1.mac_stats.rx_frames_64: 0 > dev.em.1.mac_stats.rx_frames_65_127: 0 > dev.em.1.mac_stats.rx_frames_128_255: 0 > dev.em.1.mac_stats.rx_frames_256_511: 0 > dev.em.1.mac_stats.rx_frames_512_1023: 0 > dev.em.1.mac_stats.rx_frames_1024_1522: 0 > dev.em.1.mac_stats.good_octets_recvd: 35245157589 > dev.em.1.mac_stats.good_octets_txd: 175509471230 > dev.em.1.mac_stats.total_pkts_txd: 210873641 > dev.em.1.mac_stats.good_pkts_txd: 210873641 > dev.em.1.mac_stats.bcast_pkts_txd: 151 > dev.em.1.mac_stats.mcast_pkts_txd: 0 > dev.em.1.mac_stats.tx_frames_64: 0 > dev.em.1.mac_stats.tx_frames_65_127: 0 > dev.em.1.mac_stats.tx_frames_128_255: 0 > dev.em.1.mac_stats.tx_frames_256_511: 0 > dev.em.1.mac_stats.tx_frames_512_1023: 0 > dev.em.1.mac_stats.tx_frames_1024_1522: 0 > dev.em.1.mac_stats.tso_txd: 0 > dev.em.1.mac_stats.tso_ctx_fail: 0 > dev.em.1.interrupts.asserts: 264725703 > dev.em.1.interrupts.rx_pkt_timer: 0 > dev.em.1.interrupts.rx_abs_timer: 0 > dev.em.1.interrupts.tx_pkt_timer: 0 > dev.em.1.interrupts.tx_abs_timer: 0 > dev.em.1.interrupts.tx_queue_empty: 0 > dev.em.1.interrupts.tx_queue_min_thresh: 0 > dev.em.1.interrupts.rx_desc_min_thresh: 0 > dev.em.1.interrupts.rx_overrun: 0 > dev.em.1.wake: 0 > > > > uname -a > FreeBSD web2 8.1-STABLE FreeBSD 8.1-STABLE #0: Thu Oct 21 17:24:16 MSD 2010 > root@flash-srv:/usr/obj/nanobsd.WEB2_C7899_H16_S63/usr/src/sys/WEB2 > amd64 > > Oct 22 13:06:51 web2 kernel: em0: 7.0.5> port 0x1000-0x101f mem > 0xb1a00000-0xb1a1ffff,0xb1900000-0xb19fffff,0xb1a20000-0xb1a23fff irq 28 at > device 0.0 on pci1 > Oct 22 13:06:51 web2 kernel: em0: Using MSI interrupt > Oct 22 13:06:51 web2 kernel: em0: [FILTER] > Oct 22 13:06:51 web2 kernel: em0: Ethernet address: 00:15:17:ac:e5:bd > Oct 22 13:06:51 web2 kernel: em1: 7.0.5> port 0x20e0-0x20ff mem 0xb1b00000-0xb1b1ffff,0xb1b43000-0xb1b43fff > irq 20 at device 25.0 on pci0 > Oct 22 13:06:51 web2 kernel: em1: Using MSI interrupt > Oct 22 13:06:51 web2 kernel: em1: [FILTER] > Oct 22 13:06:51 web2 kernel: em1: Ethernet address: 00:15:17:ac:e5:bc > Oct 22 13:06:51 web2 kernel: Starting Network: lo0 em0 em1. > Oct 22 13:06:51 web2 kernel: em0: > flags=8843 metric 0 mtu 1500 > Oct 22 13:06:51 web2 kernel: em1: > flags=8843 metric 0 mtu 1500 > Oct 22 13:06:53 web2 kernel: em1: link state changed to UP > Oct 22 13:06:54 web2 kernel: em0: link state changed to UP > > > dev.em.0.%desc: Intel(R) PRO/1000 Legacy Network Connection 1.0.1 > dev.em.0.%driver: em > dev.em.0.%location: slot=4 function=0 > dev.em.0.%pnpinfo: vendor=0x8086 device=0x1079 subvendor=0x8086 > subdevice=0x1079 class=0x020000 > dev.em.0.%parent: pci3 > dev.em.0.debug: -1 > dev.em.0.stats: -1 > dev.em.0.rx_int_delay: 66 > dev.em.0.tx_int_delay: 66 > dev.em.0.rx_abs_int_delay: 250 > dev.em.0.tx_abs_int_delay: 250 > dev.em.0.rx_processing_limit: -1 > dev.em.1.%desc: Intel(R) PRO/1000 Legacy Network Connection 1.0.1 > dev.em.1.%driver: em > dev.em.1.%location: slot=4 function=1 > dev.em.1.%pnpinfo: vendor=0x8086 device=0x1079 subvendor=0x8086 > subdevice=0x1079 class=0x020000 > dev.em.1.%parent: pci3 > dev.em.1.debug: -1 > dev.em.1.stats: -1 > dev.em.1.rx_int_delay: 66 > dev.em.1.tx_int_delay: 66 > dev.em.1.rx_abs_int_delay: 250 > dev.em.1.tx_abs_int_delay: 250 > dev.em.1.rx_processing_limit: -1 > > Kirill > > > > Thanks. > > > > -- > > | 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 > " > > > > > _______________________________________________ > 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 Wed Nov 10 21:46: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 A3CC6106564A for ; Wed, 10 Nov 2010 21:46:13 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 54E368FC14 for ; Wed, 10 Nov 2010 21:46:13 +0000 (UTC) Received: by gya6 with SMTP id 6so806044gya.13 for ; Wed, 10 Nov 2010 13:46:12 -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=XtUO7NvzEsmFF2sEP/UETaoZzbXPr3iyXUfS1ZaBQ4g=; b=JcqPeKFQ5EWrUGX7hjgZNIvDTKKVbzveJAYEH3jBln8djdldvyRSPS2TcHc8mFEkQL sWxLmNT/MPIcf1hyp1VYAhfSAROVVwljBpqgcZwVycTKhTIcb4ckNGGP8vQdQimwF5WP 2+7ocRaF//lQjPfffq1kKSiinNDkM9LxSmN6w= 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=JmXRuEtnDIBTq01RefrCPVGVIbKHzQ4vuslB6KTz8PnDqhrWzZShCvoOQbJ9mfLxz1 COyzz+PW5TJn1rWVnRcOg5kUcp2Eub5ksMry32S9ySlL3odmnY3I84Vu7iLsCwGaFoh+ 0Jb50iOkl2hIqKDE/kZy3sQpMQFL5CSdS7euo= Received: by 10.90.185.14 with SMTP id i14mr216579agf.178.1289425572377; Wed, 10 Nov 2010 13:46:12 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id w32sm1330940ana.17.2010.11.10.13.46.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Nov 2010 13:46:10 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 10 Nov 2010 13:45:14 -0800 From: Pyun YongHyeon Date: Wed, 10 Nov 2010 13:45:14 -0800 To: M?rcio Luciano Donada Message-ID: <20101110214514.GB13340@michelle.cdnetworks.com> References: <4CD92E25.7060304@auroraalimentos.com.br> <20101109192419.GB7766@michelle.cdnetworks.com> <4CD9AA69.7070408@auroraalimentos.com.br> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline In-Reply-To: <4CD9AA69.7070408@auroraalimentos.com.br> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: watchdog 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: Wed, 10 Nov 2010 21:46:13 -0000 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Nov 09, 2010 at 06:09:13PM -0200, M?rcio Luciano Donada wrote: > Em 9/11/2010 17:24, Pyun YongHyeon escreveu: > > On Tue, Nov 09, 2010 at 09:19:01AM -0200, M?rcio Luciano Donada wrote: > >> Hi list, > >> > >> I'm using FreeBSD (uname is below) and these days I'm caught in the log > >> message below: > >> > >> vpn# uname -a > >> FreeBSD vpn.auroraalimentos.com.br 7.3-STABLE FreeBSD 7.3-STABLE #0: Sat > >> Jun 19 18:39:18 BRT 2010 > >> root@vpn.xxx.com.br:/usr/obj/usr/src/sys/VPN i386 > >> > >> Nov 8 11:53:55 vpn kernel: xl0: watchdog timeout (missed Tx interrupts) > >> -- recovering > >> Nov 8 12:01:21 vpn kernel: xl0: watchdog timeout (missed Tx interrupts) > >> -- recovering > >> Nov 8 12:21:55 vpn kernel: xl0: watchdog timeout (missed Tx interrupts) > >> -- recovering > >> Nov 8 16:11:34 vpn kernel: xl0: watchdog timeout (missed Tx interrupts) > >> -- recovering > >> > >> it is possible that the network interface (xl0) is in trouble? > >> > > > > If my memory serve me right there were a couple of reports about > > xl(4) watchdog timeout in past. The message was added by me to > > track down possible cause of watchdog timeouts. The message means > > driver lost Tx completion interrupts but driver noticed that the > > queued frames were successfully transmitted such that it didn't > > reset the controller and showed the informational message. > > > > To further narrow down the issue, would you show me the following > > information? > > o full 'dmesg' output > > o 'pciconf -lcbv' output > > o 'devinfo -rv | grep phy' output > > > Hi, > here's the information you requested: > Thanks for the information. If there is easy way to reproduce it would you let me know? I've cleaned up some part of xl(4) which looks wrong to me but I am not sure whether this can address the issue you reported. Anyway, would you try attached patch? --azLHFNyN32YCQGCU Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="xl.watchdog.diff" Index: sys/dev/xl/if_xl.c =================================================================== --- sys/dev/xl/if_xl.c (revision 215102) +++ sys/dev/xl/if_xl.c (working copy) @@ -1872,6 +1872,8 @@ XL_LOCK_ASSERT(sc); + bus_dmamap_sync(sc->xl_ldata.xl_rx_tag, sc->xl_ldata.xl_rx_dmamap, + BUS_DMASYNC_POSTREAD); pos = sc->xl_cdata.xl_rx_head; for (i = 0; i < XL_RX_LIST_CNT; i++) { @@ -2227,7 +2229,8 @@ } #endif - while ((status = CSR_READ_2(sc, XL_STATUS)) & XL_INTRS && + while (ifp->if_drv_flags & IFF_DRV_RUNNING && + (status = CSR_READ_2(sc, XL_STATUS)) & XL_INTRS && status != 0xFFFF) { CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_INTR_ACK|(status & XL_INTRS)); @@ -2260,14 +2263,12 @@ xl_init_locked(sc); } - if (status & XL_STAT_STATSOFLOW) { - sc->xl_stats_no_timeout = 1; + if (status & XL_STAT_STATSOFLOW) xl_stats_update_locked(sc); - sc->xl_stats_no_timeout = 0; - } } - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) { + if (ifp->if_drv_flags & IFF_DRV_RUNNING && + !IFQ_DRV_IS_EMPTY(&ifp->if_snd)) { if (sc->xl_type == XL_TYPE_905B) xl_start_90xB_locked(ifp); else @@ -2331,11 +2332,8 @@ xl_init_locked(sc); } - if (status & XL_STAT_STATSOFLOW) { - sc->xl_stats_no_timeout = 1; + if (status & XL_STAT_STATSOFLOW) xl_stats_update_locked(sc); - sc->xl_stats_no_timeout = 0; - } } } return (rx_npkts); @@ -2349,13 +2347,19 @@ xl_stats_update(void *xsc) { struct xl_softc *sc = xsc; + struct mii_data *mii; XL_LOCK_ASSERT(sc); - if (xl_watchdog(sc) == EJUSTRETURN) - return; + if (sc->xl_miibus != NULL) { + mii = device_get_softc(sc->xl_miibus); + mii_tick(mii); + } xl_stats_update_locked(sc); + + xl_watchdog(sc); + callout_reset(&sc->xl_stat_callout, hz, xl_stats_update, sc); } static void @@ -2365,15 +2369,11 @@ struct xl_stats xl_stats; u_int8_t *p; int i; - struct mii_data *mii = NULL; XL_LOCK_ASSERT(sc); bzero((char *)&xl_stats, sizeof(struct xl_stats)); - if (sc->xl_miibus != NULL) - mii = device_get_softc(sc->xl_miibus); - p = (u_int8_t *)&xl_stats; /* Read all the stats registers. */ @@ -2395,14 +2395,7 @@ */ XL_SEL_WIN(4); CSR_READ_1(sc, XL_W4_BADSSD); - - if ((mii != NULL) && (!sc->xl_stats_no_timeout)) - mii_tick(mii); - XL_SEL_WIN(7); - - if (!sc->xl_stats_no_timeout) - callout_reset(&sc->xl_stat_callout, hz, xl_stats_update, sc); } /* @@ -2939,9 +2932,7 @@ /* Clear out the stats counters. */ CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_STATS_DISABLE); - sc->xl_stats_no_timeout = 1; xl_stats_update_locked(sc); - sc->xl_stats_no_timeout = 0; XL_SEL_WIN(4); CSR_WRITE_2(sc, XL_W4_NET_DIAG, XL_NETDIAG_UPPER_BYTES_ENABLE); CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_STATS_ENABLE); Index: sys/dev/xl/if_xlreg.h =================================================================== --- sys/dev/xl/if_xlreg.h (revision 215102) +++ sys/dev/xl/if_xlreg.h (working copy) @@ -614,7 +614,6 @@ u_int32_t xl_xcvr; u_int16_t xl_media; u_int16_t xl_caps; - u_int8_t xl_stats_no_timeout; u_int16_t xl_tx_thresh; int xl_pmcap; int xl_if_flags; --azLHFNyN32YCQGCU-- From owner-freebsd-stable@FreeBSD.ORG Thu Nov 11 04:52: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 ED0BB106566B for ; Thu, 11 Nov 2010 04:52:27 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id D84F48FC17 for ; Thu, 11 Nov 2010 04:52:27 +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 oAB4qQuP030957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 Nov 2010 20:52:27 -0800 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id DCA681CC0F; Wed, 10 Nov 2010 20:52:26 -0800 (PST) To: Kirill Yelizarov In-reply-to: Your message of "Wed, 10 Nov 2010 04:21:12 PST." <889823.70463.qm@web120506.mail.ne1.yahoo.com> Date: Wed, 10 Nov 2010 20:52:26 -0800 From: "Kevin Oberman" Message-Id: <20101111045226.DCA681CC0F@ptavv.es.net> Cc: freebsd-stable@freebsd.org Subject: Re: icmp packets on em larger than 1472 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Nov 2010 04:52:28 -0000 > Date: Wed, 10 Nov 2010 04:21:12 -0800 (PST) > From: Kirill Yelizarov > Sender: owner-freebsd-stable@freebsd.org > > Hi, > > All my em cards running 8.1 stable don't reply to icmp echo requests packets larger than 1472 bytes. > > On stable 7.2 the same hardware works as expected: > # ping -s 1500 192.168.64.99 > PING 192.168.64.99 (192.168.64.99): 1500 data bytes > 1508 bytes from 192.168.64.99: icmp_seq=0 ttl=63 time=1.249 ms > 1508 bytes from 192.168.64.99: icmp_seq=1 ttl=63 time=1.158 ms > > Here is the dump on em interface > 15:06:31.452043 IP 192.168.66.65 > *****: ICMP echo request, id 28729, seq 5, length 1480 > 15:06:31.452047 IP 192.168.66.65 > ****: icmp > 15:06:31.452069 IP **** > 192.168.66.65: ICMP echo reply, id 28729, seq 5, length 1480 > 15:06:31.452071 IP *** > 192.168.66.65: icmp > > Same ping from same source (it's a 8.1 stable with fxp interface) to em card running 8.1 stable > #pciconf -lv > em0@pci0:3:4:0: class=0x020000 card=0x10798086 chip=0x10798086 rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Dual Port Gigabit Ethernet Controller (82546EB)' > class = network > subclass = ethernet > > # ping -s 1472 192.168.64.200 > PING 192.168.64.200 (192.168.64.200): 1472 data bytes > 1480 bytes from 192.168.64.200: icmp_seq=0 ttl=63 time=0.848 ms > ^C > > # ping -s 1473 192.168.64.200 > PING 192.168.64.200 (192.168.64.200): 1473 data bytes > ^C > --- 192.168.64.200 ping statistics --- > 4 packets transmitted, 0 packets received, 100.0% packet loss > > And here is it's dump on em card > 5:11:15.191496 IP 192.168.66.65 > *****: ICMP echo request, id 33593, seq 0, length 1480 > 15:11:15.191534 IP 192.168.66.65 > *****: icmp > 15:11:16.192119 IP 192.168.66.65 > *****: ICMP echo request, id 33593, seq 1, length 1480 > 15:11:16.192156 IP 192.168.66.65 > ******: icmp > > igb cards on 8.1 stable are not affected I'm unsure why it ever worked. Was the interface MTU set to 1500 (default) under V7? Most ping programs (including FreeBSD) send the specified number of DATA bytes. Add the ICMP header (8 bytes) and the IP header (20 bytes) to 1472 and you get 1500, the largest packet that should work. It even gives you a hint as, for no reason I have never understood, the program includes the ICMP header is the displayed packet size (1480/1508). Also, the IP MTU of 1500 does not include the Ethernet framing which includes 12 bytes of address and two bytes of ethertype or the CRC. If the igb is allowing over 1500 bytes of IP packet through, assuming the MTU has not been increased for the standard 1500, something is clearly broken. 1472 is the right answer and 1500 (or 1473) is not. -- 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 Thu Nov 11 05:01: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 504901065670 for ; Thu, 11 Nov 2010 05:01:30 +0000 (UTC) (envelope-from wilkinsa@dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id CE40A8FC0C for ; Thu, 11 Nov 2010 05:01:29 +0000 (UTC) Received: from ednmsw520.dsto.defence.gov.au (ednmsw520.dsto.defence.gov.au [131.185.68.60]) by digger1.defence.gov.au (DSTO/DSTO) with ESMTP id oAB4sN8t024430 for ; Thu, 11 Nov 2010 15:24:23 +1030 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw520.dsto.defence.gov.au (Clearswift SMTPRS 5.4.0) with ESMTP id for ; Thu, 11 Nov 2010 15:31:27 +1030 Received: from stlex511.dsto.defence.gov.au ([203.6.60.49]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Nov 2010 15:31:27 +1030 Received: from stlux550.dsto.defence.gov.au ([203.6.60.61]) by stlex511.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Nov 2010 13:01:26 +0800 Received: from stlux550.dsto.defence.gov.au (localhost [127.0.0.1]) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3) with ESMTP id oAB51Qrb041711 for ; Thu, 11 Nov 2010 13:01:26 +0800 (WST) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3/Submit) id oAB51Qbo041710 for freebsd-stable@freebsd.org; Thu, 11 Nov 2010 13:01:26 +0800 (WST) (envelope-from wilkinsa) Date: Thu, 11 Nov 2010 13:01:26 +0800 From: "Wilkinson, Alex" To: freebsd-stable@freebsd.org Message-ID: <20101111050126.GA41634@stlux503.dsto.defence.gov.au> Mail-Followup-To: freebsd-stable@freebsd.org References: <889823.70463.qm@web120506.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <889823.70463.qm@web120506.mail.ne1.yahoo.com> Organisation: Defence Science Technology Organisation X-Message-Flag: "Please Restore Line Breaks If Necessary" User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 11 Nov 2010 05:01:26.0584 (UTC) FILETIME=[7E953380:01CB815D] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-6.500.1024-17758.004 X-TM-AS-Result: No--13.747300-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Transfer-Encoding: 7bit Subject: Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Nov 2010 05:01:30 -0000 0n Wed, Nov 10, 2010 at 04:21:12AM -0800, Kirill Yelizarov wrote: >All my em cards running 8.1 stable don't reply to icmp echo requests packets larger than 1472 bytes. > >On stable 7.2 the same hardware works as expected: ># ping -s 1500 192.168.64.99 >PING 192.168.64.99 (192.168.64.99): 1500 data bytes >1508 bytes from 192.168.64.99: icmp_seq=0 ttl=63 time=1.249 ms >1508 bytes from 192.168.64.99: icmp_seq=1 ttl=63 time=1.158 ms > >Here is the dump on em interface >15:06:31.452043 IP 192.168.66.65 > *****: ICMP echo request, id 28729, seq 5, length 1480 >15:06:31.452047 IP 192.168.66.65 > ****: icmp >15:06:31.452069 IP **** > 192.168.66.65: ICMP echo reply, id 28729, seq 5, length 1480 >15:06:31.452071 IP *** > 192.168.66.65: icmp > >Same ping from same source (it's a 8.1 stable with fxp interface) to em card running 8.1 stable >#pciconf -lv >em0@pci0:3:4:0: class=0x020000 card=0x10798086 chip=0x10798086 rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Dual Port Gigabit Ethernet Controller (82546EB)' > class = network > subclass = ethernet > ># ping -s 1472 192.168.64.200 >PING 192.168.64.200 (192.168.64.200): 1472 data bytes >1480 bytes from 192.168.64.200: icmp_seq=0 ttl=63 time=0.848 ms >^C > ># ping -s 1473 192.168.64.200 >PING 192.168.64.200 (192.168.64.200): 1473 data bytes >^C >--- 192.168.64.200 ping statistics --- >4 packets transmitted, 0 packets received, 100.0% packet loss works fine for me: FreeBSD 8.1-STABLE #0 r213395 em0@pci0:0:25:0:class=0x020000 card=0x3035103c chip=0x10de8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel Gigabit network connection (82567LM-3 )' class = network subclass = ethernet #ping -s 1473 host PING host(192.168.1.1): 1473 data bytes 1481 bytes from 192.168.1.1: icmp_seq=0 ttl=253 time=31.506 ms 1481 bytes from 192.168.1.1: icmp_seq=1 ttl=253 time=31.493 ms 1481 bytes from 192.168.1.1: icmp_seq=2 ttl=253 time=31.550 ms ^C -Alex IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-stable@FreeBSD.ORG Thu Nov 11 05:27: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 12643106564A for ; Thu, 11 Nov 2010 05:27:00 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id F0D748FC12 for ; Thu, 11 Nov 2010 05:26:59 +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 oAB5Quc1020540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 Nov 2010 21:26:56 -0800 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 21C0E1CC0E; Wed, 10 Nov 2010 21:26:56 -0800 (PST) To: "Wilkinson, Alex" In-reply-to: Your message of "Thu, 11 Nov 2010 13:01:26 +0800." <20101111050126.GA41634@stlux503.dsto.defence.gov.au> Date: Wed, 10 Nov 2010 21:26:56 -0800 From: "Kevin Oberman" Message-Id: <20101111052656.21C0E1CC0E@ptavv.es.net> Cc: freebsd-stable@freebsd.org Subject: Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Nov 2010 05:27:00 -0000 > Date: Thu, 11 Nov 2010 13:01:26 +0800 > From: "Wilkinson, Alex" > Sender: owner-freebsd-stable@freebsd.org > > > 0n Wed, Nov 10, 2010 at 04:21:12AM -0800, Kirill Yelizarov wrote: > > >All my em cards running 8.1 stable don't reply to icmp echo requests packets larger than 1472 bytes. > > > >On stable 7.2 the same hardware works as expected: > ># ping -s 1500 192.168.64.99 > >PING 192.168.64.99 (192.168.64.99): 1500 data bytes > >1508 bytes from 192.168.64.99: icmp_seq=0 ttl=63 time=1.249 ms > >1508 bytes from 192.168.64.99: icmp_seq=1 ttl=63 time=1.158 ms > > > >Here is the dump on em interface > >15:06:31.452043 IP 192.168.66.65 > *****: ICMP echo request, id 28729, seq 5, length 1480 > >15:06:31.452047 IP 192.168.66.65 > ****: icmp > >15:06:31.452069 IP **** > 192.168.66.65: ICMP echo reply, id 28729, seq 5, length 1480 > >15:06:31.452071 IP *** > 192.168.66.65: icmp > > > >Same ping from same source (it's a 8.1 stable with fxp interface) to em card running 8.1 stable > >#pciconf -lv > >em0@pci0:3:4:0: class=0x020000 card=0x10798086 chip=0x10798086 rev=0x03 hdr=0x00 > > vendor = 'Intel Corporation' > > device = 'Dual Port Gigabit Ethernet Controller (82546EB)' > > class = network > > subclass = ethernet > > > ># ping -s 1472 192.168.64.200 > >PING 192.168.64.200 (192.168.64.200): 1472 data bytes > >1480 bytes from 192.168.64.200: icmp_seq=0 ttl=63 time=0.848 ms > >^C > > > ># ping -s 1473 192.168.64.200 > >PING 192.168.64.200 (192.168.64.200): 1473 data bytes > >^C > >--- 192.168.64.200 ping statistics --- > >4 packets transmitted, 0 packets received, 100.0% packet loss > > works fine for me: > > FreeBSD 8.1-STABLE #0 r213395 > > em0@pci0:0:25:0:class=0x020000 card=0x3035103c chip=0x10de8086 rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel Gigabit network connection (82567LM-3 )' > class = network > subclass = ethernet > > #ping -s 1473 host > PING host(192.168.1.1): 1473 data bytes > 1481 bytes from 192.168.1.1: icmp_seq=0 ttl=253 time=31.506 ms > 1481 bytes from 192.168.1.1: icmp_seq=1 ttl=253 time=31.493 ms > 1481 bytes from 192.168.1.1: icmp_seq=2 ttl=253 time=31.550 ms > ^C The reason the '-s 1500' worked was that the packets were fragmented. If I add the '-D' option, '-s 1473' fails on v7 and v8. Are the V8 systems where you see if failing without the '-D' on the same network segment? If not, it is likely that an intervening device is refusing to fragment the packet. (Some routers deliberately don't fragment ICMP Echos Request packets.) -- 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 Thu Nov 11 07:49: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 81B11106564A for ; Thu, 11 Nov 2010 07:49:58 +0000 (UTC) (envelope-from ykirill@yahoo.com) Received: from nm28.bullet.mail.ne1.yahoo.com (nm28.bullet.mail.ne1.yahoo.com [98.138.90.91]) by mx1.freebsd.org (Postfix) with SMTP id 2A13F8FC08 for ; Thu, 11 Nov 2010 07:49:57 +0000 (UTC) Received: from [98.138.90.57] by nm28.bullet.mail.ne1.yahoo.com with NNFMP; 11 Nov 2010 07:49:57 -0000 Received: from [98.138.89.199] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 11 Nov 2010 07:49:57 -0000 Received: from [127.0.0.1] by omp1057.mail.ne1.yahoo.com with NNFMP; 11 Nov 2010 07:49:56 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 954273.60239.bm@omp1057.mail.ne1.yahoo.com Received: (qmail 17837 invoked by uid 60001); 11 Nov 2010 07:49:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1289461796; bh=I63usKu27qQuoJ3vGuxBntycAYvgo9xC9R7ccaWbiV4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=RMPJebJvYUeo+p3gN2s8VEJwW0cYmWDgSh10ZpeWPVtGvKbxwTTqrjt0FBQ/wCdPQO0vY/id8xZ32DAoaSuZDDuFDYHmkxJCeH/FOeaPtJLLZiIoS5weGQPYeENihN+UoixxZrS1SOAR9/rs+wesQ1YPpiqjA4+a4IkeHKefsTg= 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:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=6Wkpgc6k5Xkz/gwhCX5iVm08bGJhQVQkCn032/6muqDMU1ktYBzXQjdshGyZsG1WXclsIr68rcWSSv947rwPglEQsygUoH8Kk908pqhi5cir+6YHdcHGEYTsyWsWkLKcFanWoBFgZTLT+m1BFIi7xgCyFa9yvNK40BeOOog9KKM=; Message-ID: <816869.17580.qm@web120510.mail.ne1.yahoo.com> X-YMail-OSG: L55PwMUVM1m1yAFWm1GwROWZZCGfVI2lgjGO2W.H1F0_qCx 5t13u3qNX9sfRaJkE9Vqb.drMEyglC7KXxNHx_KeTc599Skzwn5UJBWlR5TW jw6X_9KGjkBrxZuIc92PtwzIfIe7Qrr3efcDzU1RJ2sSfCtBQ6oV4zH3LWmY QwjGE1pSG8f4xUecMFFTvgVRonRpFUmV3DFX3Q63e5G3.2pKXqzRqeK_sksx yGbr0KLxOxDrMUjXDDCxMI9VscShyoFSYsjWbG.hMm1jVJ6gjUxvIRGinaHR l1outBAcaMvuqy4_N4Z_X.7s- Received: from [212.74.229.235] by web120510.mail.ne1.yahoo.com via HTTP; Wed, 10 Nov 2010 23:49:56 PST X-Mailer: YahooMailClassic/11.4.7 YahooMailWebService/0.8.107.285259 Date: Wed, 10 Nov 2010 23:49:56 -0800 (PST) From: Kirill Yelizarov To: freebsd-stable@freebsd.org In-Reply-To: <20101111052656.21C0E1CC0E@ptavv.es.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Nov 2010 07:49:58 -0000 =0A=0A--- On Thu, 11/11/10, Kevin Oberman wrote:=0A=0A> Fr= om: Kevin Oberman =0A> Subject: Re: icmp packets on em larg= er than 1472 [SEC=3DUNCLASSIFIED]=0A> To: "Wilkinson, Alex" =0A> Cc: freebsd-stable@freebsd.org=0A> Date: Thursday= , November 11, 2010, 8:26 AM=0A> > Date: Thu, 11 Nov 2010 13:01:26=0A> +080= 0=0A> > From: "Wilkinson, Alex" =0A> > = Sender: owner-freebsd-stable@freebsd.org=0A> > =0A> > =0A> >=A0 =A0=A0=A00n= Wed, Nov 10, 2010 at=0A> 04:21:12AM -0800, Kirill Yelizarov wrote: =0A> > = =0A> >=A0 =A0=A0=A0>All my em cards running=0A> 8.1 stable don't reply to i= cmp echo requests packets larger=0A> than 1472 bytes.=0A> >=A0 =A0=A0=A0>= =0A> >=A0 =A0=A0=A0>On stable 7.2 the same=0A> hardware works as expected:= =0A> >=A0 =A0=A0=A0># ping -s 1500=0A> 192.168.64.99=0A> >=A0 =A0=A0=A0>PIN= G 192.168.64.99=0A> (192.168.64.99): 1500 data bytes=0A> >=A0 =A0=A0=A0>150= 8 bytes from=0A> 192.168.64.99: icmp_seq=3D0 ttl=3D63 time=3D1.249 ms=0A> >= =A0 =A0=A0=A0>1508 bytes from=0A> 192.168.64.99: icmp_seq=3D1 ttl=3D63 time= =3D1.158 ms=0A> >=A0 =A0=A0=A0>=0A> >=A0 =A0=A0=A0>Here is the dump on em= =0A> interface=0A> >=A0 =A0=A0=A0>15:06:31.452043 IP=0A> 192.168.66.65 > **= ***: ICMP echo request, id 28729, seq=0A> 5, length 1480=0A> >=A0 =A0=A0=A0= >15:06:31.452047 IP=0A> 192.168.66.65 > ****: icmp=0A> >=A0 =A0=A0=A0>15:06= :31.452069 IP ****=0A> > 192.168.66.65: ICMP echo reply, id 28729, seq 5, l= ength=0A> 1480=0A> >=A0 =A0=A0=A0>15:06:31.452071 IP ***=0A> > 192.168.66.6= 5: icmp=0A> >=A0 =A0=A0=A0> =0A> >=A0 =A0=A0=A0>Same ping from same source= =0A> (it's a 8.1 stable with fxp interface) to em card running=0A> 8.1 stab= le=0A> >=A0 =A0=A0=A0>#pciconf -lv=0A> >=A0=0A> =A0=A0=A0>em0@pci0:3:4:0:= =A0=A0=A0=0A> class=3D0x020000 card=3D0x10798086 chip=3D0x10798086 rev=3D0x= 03=0A> hdr=3D0x00=0A> >=A0 =A0=A0=A0>=A0 =A0 vendor=A0=0A> =A0=A0=A0=3D 'In= tel Corporation'=0A> >=A0 =A0=A0=A0>=A0 =A0 device=A0=0A> =A0=A0=A0=3D 'Dua= l Port Gigabit Ethernet Controller=0A> (82546EB)'=0A> >=A0 =A0=A0=A0>=A0 = =A0 class=A0=0A> =A0 =A0 =3D network=0A> >=A0 =A0=A0=A0>=A0 =A0=0A> subclas= s=A0=A0=A0=3D ethernet=0A> >=A0 =A0=A0=A0>=0A> >=A0 =A0=A0=A0># ping -s 147= 2=0A> 192.168.64.200=0A> >=A0 =A0=A0=A0>PING 192.168.64.200=0A> (192.168.64= .200): 1472 data bytes=0A> >=A0 =A0=A0=A0>1480 bytes from=0A> 192.168.64.20= 0: icmp_seq=3D0 ttl=3D63 time=3D0.848 ms=0A> >=A0 =A0=A0=A0>^C=0A> >=A0 =A0= =A0=A0>=0A> >=A0 =A0=A0=A0># ping -s 1473=0A> 192.168.64.200=0A> >=A0 =A0= =A0=A0>PING 192.168.64.200=0A> (192.168.64.200): 1473 data bytes=0A> >=A0 = =A0=A0=A0>^C=0A> >=A0 =A0=A0=A0>--- 192.168.64.200 ping=0A> statistics ---= =0A> >=A0 =A0=A0=A0>4 packets transmitted, 0=0A> packets received, 100.0% p= acket loss=0A> > =0A> > works fine for me:=0A> > =0A> > FreeBSD 8.1-STABLE = #0 r213395=0A> > =0A> > em0@pci0:0:25:0:class=3D0x020000 card=3D0x3035103c= =0A> chip=3D0x10de8086 rev=3D0x02 hdr=3D0x00=0A> >=A0 =A0=A0=A0vendor=A0=0A= > =A0=A0=A0=3D 'Intel Corporation'=0A> >=A0 =A0=A0=A0device=A0=0A> =A0=A0= =A0=3D 'Intel Gigabit network connection=0A> (82567LM-3 )'=0A> >=A0 =A0=A0= =A0class=A0 =A0 =A0 =3D=0A> network=0A> >=A0 =A0=A0=A0subclass=A0=A0=A0=3D= =0A> ethernet=0A> > =0A> > #ping -s 1473 host=0A> > PING host(192.168.1.1):= 1473 data bytes=0A> > 1481 bytes from 192.168.1.1: icmp_seq=3D0 ttl=3D253= =0A> time=3D31.506 ms=0A> > 1481 bytes from 192.168.1.1: icmp_seq=3D1 ttl= =3D253=0A> time=3D31.493 ms=0A> > 1481 bytes from 192.168.1.1: icmp_seq=3D2= ttl=3D253=0A> time=3D31.550 ms=0A> > ^C=0A> =0A> The reason the '-s 1500' = worked was that the packets were=0A> fragmented. If=0A> I add the '-D' opti= on, '-s 1473' fails on v7 and v8. Are=0A> the V8 systems=0A> where you see = if failing without the '-D' on the same=0A> network segment?=0A> If not, it= is likely that an intervening device is refusing=0A> to fragment=0A> the p= acket. (Some routers deliberately don't fragment ICMP=0A> Echos Request=0A>= packets.) =0A=0AIf i set -D -s 1473 sender side refuses to ping and that i= s correct. All mentioned above machines are behind the same router and swit= ch. Same hardware running v7 is working while v8 is not. And i never saw su= ch problems before. Also correct me if i'm wrong but the dump shows that t= he packet arrived. I'll try driver from head and will post here results. = =0A=0AKirill=0A> -- =0A> R. Kevin Oberman, Network Engineer=0A> Energy Scie= nces Network (ESnet)=0A> Ernest O. Lawrence Berkeley National Laboratory (B= erkeley=0A> Lab)=0A> E-mail: oberman@es.net=A0=A0=A0=0A> =A0=A0=A0 =A0=A0= =A0 Phone: +1 510=0A> 486-8634=0A> Key fingerprint:059B 2DDF 031C 9BA3 14A4= =A0 EADA 927D=0A> EBB3 987B 3751=0A> ______________________________________= _________=0A> freebsd-stable@freebsd.org=0A> mailing list=0A> http://lists.= freebsd.org/mailman/listinfo/freebsd-stable=0A> To unsubscribe, send any ma= il to "freebsd-stable-unsubscribe@freebsd.org"=0A> =0A=0A=0A From owner-freebsd-stable@FreeBSD.ORG Thu Nov 11 10: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 73F8C1065673 for ; Thu, 11 Nov 2010 10:05:40 +0000 (UTC) (envelope-from joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com) Received: from relay03-haj2.antispameurope.com (relay03-haj2.antispameurope.com [83.246.65.53]) by mx1.freebsd.org (Postfix) with ESMTP id 016BE8FC0C for ; Thu, 11 Nov 2010 10:05:39 +0000 (UTC) Received: by relay03-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 3989263C20A; Thu, 11 Nov 2010 11:05:37 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay03-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 34ED063C239; Thu, 11 Nov 2010 11:05:36 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id oABA5ZAW000889; Thu, 11 Nov 2010 11:05:35 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Nov 2010 11:05:36 +0100 Date: Thu, 11 Nov 2010 11:05:35 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: mav@FreeBSD.org Message-ID: <4cdbbfef.v4cr/k2jZr9gdpyF%Joerg.Schilling@fokus.fraunhofer.de> References: <4CD45209.5010607@FreeBSD.org> <20101105192028.GA68728@alchemy.franken.de> <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> <4CD82E2A.3070407@FreeBSD.org> <4cd8320a.U7/OjtLLBVtE4dTy%Joerg.Schilling@fokus.fraunhofer.de> <4CD83535.1010008@FreeBSD.org> In-Reply-To: <4CD83535.1010008@FreeBSD.org> User-Agent: nail 11.22 3/20/05 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 11 Nov 2010 10:05:36.0084 (UTC) FILETIME=[FC21E940:01CB8187] Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, marius@alchemy.franken.de Subject: Re: Sense fetching [Was: cdrtools /devel ...] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Nov 2010 10:05:40 -0000 Alexander Motin wrote: > >>> Given the fact that many drives will probably only return 18 bytes of sense > >>> data, this will happen every time libscg is told to fetch more sense than the > >>> drive is willing to return. > >>> > >>> Is there a way to distinct an old kernel from a new one? > >> I don't see the problem. Previous kernel in most cases reported > >> sesnse_resid == 0, lying that there is more sense data then really is. > >> New one should report real (often positive) value. In both cases > >> sesnse_resid value measured from the value submitted to the kernel. > > > > Did the old kernel return a zero sense_resid for any implemented SCSI > > transport? Libscg is a generic SCSI transport library and cdrecord is just one > > user of this lib. > > Not sure I understand your question. Zero sesnse_resid is absolutely > normal situation if device gave same amount of sense as application > requested. As I can see, many of SCSI controllers report sesnse_resid > properly. I may assume that some, like atapicd don't -- in that case > you'll also see 0 there. FreeBSD-CAM did try to fetcth more than 18 bytes of sense data and it may be that some drives did return only 18 bytes. In this case, I would asume that there is a resid > 0. > > Do you know the CAM behavior for other SCSI transports? > > I don't have real SCSI CD to test, but a as I can see, most of SCSI > controllers return sense data automatically. Sense fetching changes > should not affect/break anything there. The question still remains whether the previous implementation did return resid > 0 in some cases. In this case, I would need to implement both variants in the libscg adaption layer and I would need to know whether I am running on an old version or on a new version kernel. Do you know of a simple method to implement this distinction? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From owner-freebsd-stable@FreeBSD.ORG Thu Nov 11 10:29: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 06340106564A; Thu, 11 Nov 2010 10:29:12 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 27D458FC08; Thu, 11 Nov 2010 10:29:10 +0000 (UTC) Received: by bwz2 with SMTP id 2so1745219bwz.13 for ; Thu, 11 Nov 2010 02:29:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=IBkmn7OjqaG8WH8tmY8jbDAX2tB+EFBeKS8TkX98YRo=; b=Im8CNONFvQTsxaC/ORkRK9l2KSrirGk9O0x3ONTGEzEL/QHLLUNfB6sC6ykQWW4U5A cwNvB6wnEgz22xVgUABtb41mQFxhj3Vi1OUAGAU2MsGBMf7rfkS43QgZjsr75VLIMeD7 otLa5gKixxFsoncTuRUD+qnbFyw/vDdMwHRbM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=puHTSR07x7EZyr2Yer1RraanUVyXIpAjDQ+4c97ebMUP27VTHwyTzNuwCy6te2PyS1 7Bajt99mILHleAdHp8+ip8npwIRgLzTe+ic0PurArYm3rPDOgb13XnM/A8O3bx0t2HHc Kos4RANrezdPhpCV2Y+aKY8SzBFJDEThs7NvY= Received: by 10.204.27.20 with SMTP id g20mr1051611bkc.114.1289471349947; Thu, 11 Nov 2010 02:29:09 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id r21sm845182bkj.22.2010.11.11.02.29.07 (version=SSLv3 cipher=RC4-MD5); Thu, 11 Nov 2010 02:29:08 -0800 (PST) Sender: Alexander Motin Message-ID: <4CDBC55B.1040307@FreeBSD.org> Date: Thu, 11 Nov 2010 12:28:43 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Joerg Schilling References: <4CD45209.5010607@FreeBSD.org> <20101105192028.GA68728@alchemy.franken.de> <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> <4CD82E2A.3070407@FreeBSD.org> <4cd8320a.U7/OjtLLBVtE4dTy%Joerg.Schilling@fokus.fraunhofer.de> <4CD83535.1010008@FreeBSD.org> <4cdbbfef.v4cr/k2jZr9gdpyF%Joerg.Schilling@fokus.fraunhofer.de> In-Reply-To: <4cdbbfef.v4cr/k2jZr9gdpyF%Joerg.Schilling@fokus.fraunhofer.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, marius@alchemy.franken.de Subject: Re: Sense fetching [Was: cdrtools /devel ...] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Nov 2010 10:29:12 -0000 Joerg Schilling wrote: > Alexander Motin wrote: >>>>> Given the fact that many drives will probably only return 18 bytes of sense >>>>> data, this will happen every time libscg is told to fetch more sense than the >>>>> drive is willing to return. >>>>> >>>>> Is there a way to distinct an old kernel from a new one? >>>> I don't see the problem. Previous kernel in most cases reported >>>> sesnse_resid == 0, lying that there is more sense data then really is. >>>> New one should report real (often positive) value. In both cases >>>> sesnse_resid value measured from the value submitted to the kernel. >>> Did the old kernel return a zero sense_resid for any implemented SCSI >>> transport? Libscg is a generic SCSI transport library and cdrecord is just one >>> user of this lib. >> Not sure I understand your question. Zero sesnse_resid is absolutely >> normal situation if device gave same amount of sense as application >> requested. As I can see, many of SCSI controllers report sesnse_resid >> properly. I may assume that some, like atapicd don't -- in that case >> you'll also see 0 there. > > FreeBSD-CAM did try to fetcth more than 18 bytes of sense data and it may be > that some drives did return only 18 bytes. In this case, I would asume that > there is a resid > 0. As I have said, many drivers return resid properly, but some others - don't. These changes should just improve situation. >>> Do you know the CAM behavior for other SCSI transports? >> I don't have real SCSI CD to test, but a as I can see, most of SCSI >> controllers return sense data automatically. Sense fetching changes >> should not affect/break anything there. > > The question still remains whether the previous implementation did return resid >> 0 in some cases. In this case, I would need to implement both variants in the > libscg adaption layer and I would need to know whether I am running on an old > version or on a new version kernel. Do you know of a simple method to implement > this distinction? Yes, some drivers were permanently reporting zero resid, while others (mostly real SCSI) were reporting proper values. Now it is the same, just more cases should work properly. Why do you want/need to distinguish them? You should already handle non-zero resid properly. Zero resid may be wrong in some cases, but at first I don't see fatal problem from it and at second I don't see what can you do about it. If I am missing something - sorry, explain it to me please. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Thu Nov 11 10:33: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 8BBFF10656A9 for ; Thu, 11 Nov 2010 10:33:07 +0000 (UTC) (envelope-from joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com) Received: from relay01-haj2.antispameurope.com (relay01-haj2.antispameurope.com [83.246.65.51]) by mx1.freebsd.org (Postfix) with ESMTP id 16C1A8FC1D for ; Thu, 11 Nov 2010 10:33:06 +0000 (UTC) Received: by relay01-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id BD9441600DA; Thu, 11 Nov 2010 11:33:04 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay01-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 31E5B1600B1; Thu, 11 Nov 2010 11:33:03 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id oABAX3S6001742; Thu, 11 Nov 2010 11:33:03 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Nov 2010 11:33:04 +0100 Date: Thu, 11 Nov 2010 11:33:03 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: mav@FreeBSD.org Message-ID: <4cdbc65f.bo+mYNFB2GPwXmq7%Joerg.Schilling@fokus.fraunhofer.de> References: <4CD45209.5010607@FreeBSD.org> <20101105192028.GA68728@alchemy.franken.de> <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> <4CD82E2A.3070407@FreeBSD.org> <4cd8320a.U7/OjtLLBVtE4dTy%Joerg.Schilling@fokus.fraunhofer.de> <4CD83535.1010008@FreeBSD.org> <4cdbbfef.v4cr/k2jZr9gdpyF%Joerg.Schilling@fokus.fraunhofer.de> <4CDBC55B.1040307@FreeBSD.org> In-Reply-To: <4CDBC55B.1040307@FreeBSD.org> User-Agent: nail 11.22 3/20/05 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 11 Nov 2010 10:33:04.0173 (UTC) FILETIME=[D27855D0:01CB818B] Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, marius@alchemy.franken.de Subject: Re: Sense fetching [Was: cdrtools /devel ...] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Nov 2010 10:33:07 -0000 Alexander Motin wrote: > > The question still remains whether the previous implementation did return resid > >> 0 in some cases. In this case, I would need to implement both variants in the > > libscg adaption layer and I would need to know whether I am running on an old > > version or on a new version kernel. Do you know of a simple method to implement > > this distinction? > > Yes, some drivers were permanently reporting zero resid, while others > (mostly real SCSI) were reporting proper values. Now it is the same, > just more cases should work properly. > > Why do you want/need to distinguish them? You should already handle > non-zero resid properly. Zero resid may be wrong in some cases, but at > first I don't see fatal problem from it and at second I don't see what > can you do about it. > > If I am missing something - sorry, explain it to me please. Compare the number of sense bytes I like to request (18) with the number previous FreeBSD versions did actually request. It is obvious that in case there is a resid reported onm an old kernel, libscg (with your chanhge) would believe that probably less that the absolute minumum of sense data is available. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From owner-freebsd-stable@FreeBSD.ORG Thu Nov 11 11:47: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 71F72106566B for ; Thu, 11 Nov 2010 11:47:02 +0000 (UTC) (envelope-from ykirill@yahoo.com) Received: from nm3-vm0.bullet.mail.ne1.yahoo.com (nm3-vm0.bullet.mail.ne1.yahoo.com [98.138.91.55]) by mx1.freebsd.org (Postfix) with SMTP id 2E8408FC14 for ; Thu, 11 Nov 2010 11:47:02 +0000 (UTC) Received: from [98.138.90.55] by nm3.bullet.mail.ne1.yahoo.com with NNFMP; 11 Nov 2010 11:47:01 -0000 Received: from [98.138.89.163] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 11 Nov 2010 11:47:01 -0000 Received: from [127.0.0.1] by omp1019.mail.ne1.yahoo.com with NNFMP; 11 Nov 2010 11:47:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 783856.93638.bm@omp1019.mail.ne1.yahoo.com Received: (qmail 62248 invoked by uid 60001); 11 Nov 2010 11:47:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1289476021; bh=qe6H2IROrjZ2QAmk38EZHvp7Ryj08Mov825Ab6n1o3E=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=x9pQRy9t/GNzwqHOfnUBU3XLUUZ+FaArTmEKRfNicEqmwY0bHtWNOgYNF6ptvCDAa7NZRd/ivl/VvbyPm9FoKRDJZSQ10oXe+udHreKlwYv7zCZkd/ZDTZiJ6cLI0Szp8A9ZDHnbxaPLAsoGI2VraRrlWDAPV8yA7dEOyMOTj1E= 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:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=lw03X0X98iTO2F8vRZWHF5oK8ShtOATKKk54vaZxk3iQDSc7aUvsbK9cA3NuksoK31Stqu9T6BdMYfbhnUAEvjm9YY+02oM7tejF88Y91ZrMQtROgyAjPstCWykeVq05h+QDi+rMTQ/u3CdV8b0jTl3SyTnUt/3+sJ29D3x5NSI=; Message-ID: <687600.57858.qm@web120511.mail.ne1.yahoo.com> X-YMail-OSG: xX9S3gAVM1klykpQrtHOW70T4IoKFowML7KvLO7A5AkUuxL SrdQOyE.u8kwdfknoDuayP9DzMjq9w7L3Fv08Ayb.yjbYmzsVmAjHZPWbMmM GASMFH9HbGu3UwpX6kJLlk.Ad_7SswP4RDpVl8tUx0zdLPqaW.ImkawOL9qs Pu8fdoiQ7wNisC2wN7wQ_JP.Pzq8enGvkxqSHUNT9cA8MGJAz3Pf8SCeUvZV LKjml4vgvkUWfma76ihMH50iR9cGtxZ5bVh_jBya3Eq713QHDNMuhucw2tYY YON7czn6BeS2JsAP34GtZM_Q- Received: from [212.74.229.235] by web120511.mail.ne1.yahoo.com via HTTP; Thu, 11 Nov 2010 03:47:01 PST X-Mailer: YahooMailClassic/11.4.7 YahooMailWebService/0.8.107.285259 Date: Thu, 11 Nov 2010 03:47:01 -0800 (PST) From: Kirill Yelizarov To: freebsd-stable@freebsd.org In-Reply-To: <816869.17580.qm@web120510.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Nov 2010 11:47:02 -0000 =0A=0A--- On Thu, 11/11/10, Kirill Yelizarov wrote:=0A= =0A> From: Kirill Yelizarov =0A> Subject: Re: icmp packe= ts on em larger than 1472 [SEC=3DUNCLASSIFIED]=0A> To: freebsd-stable@freeb= sd.org=0A> Date: Thursday, November 11, 2010, 10:49 AM=0A> =0A> =0A> --- On= Thu, 11/11/10, Kevin Oberman =0A> wrote:=0A> =0A> > From: = Kevin Oberman =0A> > Subject: Re: icmp packets on em larger= than 1472=0A> [SEC=3DUNCLASSIFIED]=0A> > To: "Wilkinson, Alex" =0A> > Cc: freebsd-stable@freebsd.org=0A> > Date: = Thursday, November 11, 2010, 8:26 AM=0A> > > Date: Thu, 11 Nov 2010 13:01:2= 6=0A> > +0800=0A> > > From: "Wilkinson, Alex" =0A> > > Sender: owner-freebsd-stable@freebsd.org=0A> > > =0A> > > = =0A> > >=A0 =A0=A0=A00n Wed, Nov 10, 2010 at=0A> > 04:21:12AM -0800, Kirill= Yelizarov wrote: =0A> > > =0A> > >=A0 =A0=A0=A0>All my em cards running=0A= > > 8.1 stable don't reply to icmp echo requests packets=0A> larger=0A> > t= han 1472 bytes.=0A> > >=A0 =A0=A0=A0>=0A> > >=A0 =A0=A0=A0>On stable 7.2 th= e same=0A> > hardware works as expected:=0A> > >=A0 =A0=A0=A0># ping -s 150= 0=0A> > 192.168.64.99=0A> > >=A0 =A0=A0=A0>PING 192.168.64.99=0A> > (192.16= 8.64.99): 1500 data bytes=0A> > >=A0 =A0=A0=A0>1508 bytes from=0A> > 192.16= 8.64.99: icmp_seq=3D0 ttl=3D63 time=3D1.249 ms=0A> > >=A0 =A0=A0=A0>1508 by= tes from=0A> > 192.168.64.99: icmp_seq=3D1 ttl=3D63 time=3D1.158 ms=0A> > >= =A0 =A0=A0=A0>=0A> > >=A0 =A0=A0=A0>Here is the dump on em=0A> > interface= =0A> > >=A0 =A0=A0=A0>15:06:31.452043 IP=0A> > 192.168.66.65 > *****: ICMP = echo request, id 28729,=0A> seq=0A> > 5, length 1480=0A> > >=A0 =A0=A0=A0>1= 5:06:31.452047 IP=0A> > 192.168.66.65 > ****: icmp=0A> > >=A0 =A0=A0=A0>15:= 06:31.452069 IP ****=0A> > > 192.168.66.65: ICMP echo reply, id 28729, seq = 5,=0A> length=0A> > 1480=0A> > >=A0 =A0=A0=A0>15:06:31.452071 IP ***=0A> > = > 192.168.66.65: icmp=0A> > >=A0 =A0=A0=A0> =0A> > >=A0 =A0=A0=A0>Same ping= from same source=0A> > (it's a 8.1 stable with fxp interface) to em card= =0A> running=0A> > 8.1 stable=0A> > >=A0 =A0=A0=A0>#pciconf -lv=0A> > >=A0= =0A> > =A0=A0=A0>em0@pci0:3:4:0:=A0=A0=A0=0A> > class=3D0x020000 card=3D0x1= 0798086 chip=3D0x10798086=0A> rev=3D0x03=0A> > hdr=3D0x00=0A> > >=A0 =A0=A0= =A0>=A0 =A0 vendor=A0=0A> > =A0=A0=A0=3D 'Intel Corporation'=0A> > >=A0 =A0= =A0=A0>=A0 =A0 device=A0=0A> > =A0=A0=A0=3D 'Dual Port Gigabit Ethernet Con= troller=0A> > (82546EB)'=0A> > >=A0 =A0=A0=A0>=A0 =A0 class=A0=0A> > =A0 = =A0 =3D network=0A> > >=A0 =A0=A0=A0>=A0 =A0=0A> > subclass=A0=A0=A0=3D eth= ernet=0A> > >=A0 =A0=A0=A0>=0A> > >=A0 =A0=A0=A0># ping -s 1472=0A> > 192.1= 68.64.200=0A> > >=A0 =A0=A0=A0>PING 192.168.64.200=0A> > (192.168.64.200): = 1472 data bytes=0A> > >=A0 =A0=A0=A0>1480 bytes from=0A> > 192.168.64.200: = icmp_seq=3D0 ttl=3D63 time=3D0.848 ms=0A> > >=A0 =A0=A0=A0>^C=0A> > >=A0 = =A0=A0=A0>=0A> > >=A0 =A0=A0=A0># ping -s 1473=0A> > 192.168.64.200=0A> > >= =A0 =A0=A0=A0>PING 192.168.64.200=0A> > (192.168.64.200): 1473 data bytes= =0A> > >=A0 =A0=A0=A0>^C=0A> > >=A0 =A0=A0=A0>--- 192.168.64.200 ping=0A> >= statistics ---=0A> > >=A0 =A0=A0=A0>4 packets transmitted, 0=0A> > packets= received, 100.0% packet loss=0A> > > =0A> > > works fine for me:=0A> > > = =0A> > > FreeBSD 8.1-STABLE #0 r213395=0A> > > =0A> > > em0@pci0:0:25:0:cla= ss=3D0x020000 card=3D0x3035103c=0A> > chip=3D0x10de8086 rev=3D0x02 hdr=3D0x= 00=0A> > >=A0 =A0=A0=A0vendor=A0=0A> > =A0=A0=A0=3D 'Intel Corporation'=0A>= > >=A0 =A0=A0=A0device=A0=0A> > =A0=A0=A0=3D 'Intel Gigabit network connec= tion=0A> > (82567LM-3 )'=0A> > >=A0 =A0=A0=A0class=A0 =A0 =A0 =3D=0A> > net= work=0A> > >=A0 =A0=A0=A0subclass=A0=A0=A0=3D=0A> > ethernet=0A> > > =0A> >= > #ping -s 1473 host=0A> > > PING host(192.168.1.1): 1473 data bytes=0A> >= > 1481 bytes from 192.168.1.1: icmp_seq=3D0 ttl=3D253=0A> > time=3D31.506 = ms=0A> > > 1481 bytes from 192.168.1.1: icmp_seq=3D1 ttl=3D253=0A> > time= =3D31.493 ms=0A> > > 1481 bytes from 192.168.1.1: icmp_seq=3D2 ttl=3D253=0A= > > time=3D31.550 ms=0A> > > ^C=0A> > =0A> > The reason the '-s 1500' worke= d was that the packets=0A> were=0A> > fragmented. If=0A> > I add the '-D' o= ption, '-s 1473' fails on v7 and v8.=0A> Are=0A> > the V8 systems=0A> > whe= re you see if failing without the '-D' on the same=0A> > network segment?= =0A> > If not, it is likely that an intervening device is=0A> refusing=0A> = > to fragment=0A> > the packet. (Some routers deliberately don't fragment= =0A> ICMP=0A> > Echos Request=0A> > packets.) =0A> =0A> If i set -D -s 1473= sender side refuses to ping and that is=0A> correct. All mentioned above m= achines are behind the same=0A> router and switch. Same hardware running v7= is working while=0A> v8 is not. And i never saw such problems before.=A0 A= lso=0A> correct me if i'm wrong but the dump shows that the packet=0A> arri= ved. I'll try driver from head and will post here=0A> results. =0A> =0A Sha= me on me! It was pf. I disabled scrubbing. Any of the two methods work=0A= =0A1.=0Ascrub in all=0Aicmp_types =3D "{0, 3, 4, 8, 11 }"=0Apass out quick = on $inside_if proto icmp from $inside_ip to any icmp-type $icmp_types no st= ate=0Apass in quick on $inside_if proto icmp from any to $inside_ip icmp-ty= pe $icmp_types no state=0A=0A2.=0Apass out quick on $inside_if proto icmp f= rom $inside_ip to any no state=0Apass in quick on $inside_if proto icmp fro= m any to $inside_ip no state=0AThis works without scrubbing=0A=0AKeep state= also working=0A=0AI disabled scrubbing because it seems to slow down nfs (= i'm not shure if this is right) and i specified icmp types i want to use. W= hat am i doing wrong with firewall icmp rules? Tcpdump shows echo requests = and replies only.=0A=0AI also compiled new driver from HEAD. It is working = like the old one. And firewall with igb has scrubbing.=0A=0AKirill=0A=0A> K= irill=0A> > -- =0A> > R. Kevin Oberman, Network Engineer=0A> > Energy Scien= ces Network (ESnet)=0A> > Ernest O. Lawrence Berkeley National Laboratory= =0A> (Berkeley=0A> > Lab)=0A> > E-mail: oberman@es.net=A0=A0=A0=0A> > =A0= =A0=A0 =A0=A0=A0 Phone: +1 510=0A> > 486-8634=0A> > Key fingerprint:059B 2D= DF 031C 9BA3 14A4=A0 EADA 927D=0A> > EBB3 987B 3751=0A> > _________________= ______________________________=0A> > freebsd-stable@freebsd.org=0A> > maili= ng list=0A> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable=0A> = > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"= =0A> > =0A> =0A> =0A> =0A> _______________________________________________= =0A> freebsd-stable@freebsd.org=0A> mailing list=0A> http://lists.freebsd.o= rg/mailman/listinfo/freebsd-stable=0A> To unsubscribe, send any mail to "fr= eebsd-stable-unsubscribe@freebsd.org"=0A> =0A=0A=0A From owner-freebsd-stable@FreeBSD.ORG Thu Nov 11 13:07:31 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 6A96E1065694; Thu, 11 Nov 2010 13:07:31 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 884CB8FC08; Thu, 11 Nov 2010 13:07:30 +0000 (UTC) Received: by bwz2 with SMTP id 2so1889170bwz.13 for ; Thu, 11 Nov 2010 05:07:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=a+pDfTT/zJsOxqc61Ol7WgkltbK1q8HNA3j1kujoJrQ=; b=rb+dMtjoYOvHnUg+J03C+pDstOgGpdMNfsp4e8BRN+8ZWj0DCHCdTW/iB+twBRdpjF l0HcEfypqvdpt48s/LyToeZgC0C1/pubTl2s31KS4n62INEt0/ftwos2wokLnM996k5B ytZaY5hX3KdxvtArO2IIgGiZ482aSV0ZXmTxM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=FxafP9goUSkzLj23mec3y3Ogy48FcQJlI+3u0WibEwH4nALNl/xwC7zgVa0gl2NDBK u5rJr8at9SlxI+0n4lHyB8hfCCsTA3Nr+KxdHfnrX0GAGTPjQGU14Bus/ijw5KdDbk20 m9X4vP3sZzj0SdFbV3zYUNFqaYvtzlurVS4E4= Received: by 10.204.76.67 with SMTP id b3mr1332240bkk.62.1289480848796; Thu, 11 Nov 2010 05:07:28 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 4sm919804bki.1.2010.11.11.05.07.26 (version=SSLv3 cipher=RC4-MD5); Thu, 11 Nov 2010 05:07:27 -0800 (PST) Sender: Alexander Motin Message-ID: <4CDBEA8B.1020306@FreeBSD.org> Date: Thu, 11 Nov 2010 15:07:23 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Joerg Schilling References: <4CD45209.5010607@FreeBSD.org> <20101105192028.GA68728@alchemy.franken.de> <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> <4CD82E2A.3070407@FreeBSD.org> <4cd8320a.U7/OjtLLBVtE4dTy%Joerg.Schilling@fokus.fraunhofer.de> <4CD83535.1010008@FreeBSD.org> <4cdbbfef.v4cr/k2jZr9gdpyF%Joerg.Schilling@fokus.fraunhofer.de> <4CDBC55B.1040307@FreeBSD.org> <4cdbc65f.bo+mYNFB2GPwXmq7%Joerg.Schilling@fokus.fraunhofer.de> In-Reply-To: <4cdbc65f.bo+mYNFB2GPwXmq7%Joerg.Schilling@fokus.fraunhofer.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, marius@alchemy.franken.de Subject: Re: Sense fetching [Was: cdrtools /devel ...] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Nov 2010 13:07:31 -0000 Joerg Schilling wrote: > Alexander Motin wrote: > >>> The question still remains whether the previous implementation did return resid >>>> 0 in some cases. In this case, I would need to implement both variants in the >>> libscg adaption layer and I would need to know whether I am running on an old >>> version or on a new version kernel. Do you know of a simple method to implement >>> this distinction? >> Yes, some drivers were permanently reporting zero resid, while others >> (mostly real SCSI) were reporting proper values. Now it is the same, >> just more cases should work properly. >> >> Why do you want/need to distinguish them? You should already handle >> non-zero resid properly. Zero resid may be wrong in some cases, but at >> first I don't see fatal problem from it and at second I don't see what >> can you do about it. >> >> If I am missing something - sorry, explain it to me please. > > Compare the number of sense bytes I like to request (18) with the number > previous FreeBSD versions did actually request. It is obvious that in case > there is a resid reported onm an old kernel, libscg (with your chanhge) would > believe that probably less that the absolute minumum of sense data is available. Kernel code I have changed affects only controllers without automatic sense fetching. For such controllers CAM previously always reported zero sense_resid, independently of requested size (which actually was also ignored in this case). So previously whatever you asked for 18 or 32 bytes - sense_resid was always zero, like if you got full 18 or 32 bytes. That was wrong. Now, in the same situation, if device wants to return let's say 20 bytes -- you will get 0 and 12 bytes of sense_resid respectively, meaning 18 and 20 bytes of received sense. AFAIK sense_resid always measured from the requested sense_len. In my patch for libscg you may see that I have changed both request and response paths. Resulted sense_count should be absolutely the same. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Thu Nov 11 13:17: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 850A61065674 for ; Thu, 11 Nov 2010 13:17:28 +0000 (UTC) (envelope-from joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com) Received: from relay01-haj2.antispameurope.com (relay01-haj2.antispameurope.com [83.246.65.51]) by mx1.freebsd.org (Postfix) with ESMTP id 0E7348FC16 for ; Thu, 11 Nov 2010 13:17:27 +0000 (UTC) Received: by relay01-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id B848516000F; Thu, 11 Nov 2010 14:17:26 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay01-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 622DE160049; Thu, 11 Nov 2010 14:17:25 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id oABDHOf3007031; Thu, 11 Nov 2010 14:17:24 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Nov 2010 14:17:24 +0100 Date: Thu, 11 Nov 2010 14:17:21 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: mav@FreeBSD.org Message-ID: <4cdbece1.EWYSqdvnx6XWF8EF%Joerg.Schilling@fokus.fraunhofer.de> References: <4CD45209.5010607@FreeBSD.org> <20101105192028.GA68728@alchemy.franken.de> <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> <4CD82E2A.3070407@FreeBSD.org> <4cd8320a.U7/OjtLLBVtE4dTy%Joerg.Schilling@fokus.fraunhofer.de> <4CD83535.1010008@FreeBSD.org> <4cdbbfef.v4cr/k2jZr9gdpyF%Joerg.Schilling@fokus.fraunhofer.de> <4CDBC55B.1040307@FreeBSD.org> <4cdbc65f.bo+mYNFB2GPwXmq7%Joerg.Schilling@fokus.fraunhofer.de> <4CDBEA8B.1020306@FreeBSD.org> In-Reply-To: <4CDBEA8B.1020306@FreeBSD.org> User-Agent: nail 11.22 3/20/05 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 11 Nov 2010 13:17:24.0928 (UTC) FILETIME=[C7F02400:01CB81A2] Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, marius@alchemy.franken.de Subject: Re: Sense fetching [Was: cdrtools /devel ...] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Nov 2010 13:17:28 -0000 Alexander Motin wrote: > > Compare the number of sense bytes I like to request (18) with the number > > previous FreeBSD versions did actually request. It is obvious that in case > > there is a resid reported onm an old kernel, libscg (with your chanhge) would > > believe that probably less that the absolute minumum of sense data is available. > > Kernel code I have changed affects only controllers without automatic > sense fetching. For such controllers CAM previously always reported zero > sense_resid, independently of requested size (which actually was also > ignored in this case). So previously whatever you asked for 18 or 32 > bytes - sense_resid was always zero, like if you got full 18 or 32 > bytes. That was wrong. Now, in the same situation, if device wants to > return let's say 20 bytes -- you will get 0 and 12 bytes of sense_resid > respectively, meaning 18 and 20 bytes of received sense. > > AFAIK sense_resid always measured from the requested sense_len. In my > patch for libscg you may see that I have changed both request and > response paths. Resulted sense_count should be absolutely the same. What is the requested size with the various HBAs in earlier kernels? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From owner-freebsd-stable@FreeBSD.ORG Thu Nov 11 13:28: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 90E44106566B; Thu, 11 Nov 2010 13:28:52 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id B53498FC08; Thu, 11 Nov 2010 13:28:51 +0000 (UTC) Received: by fxm19 with SMTP id 19so1277894fxm.13 for ; Thu, 11 Nov 2010 05:28:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=yZyM3gleemwPTCnpdko7NZf+EbCOFHP1Uk2zwbC8N44=; b=DR91x+fwCrStGLnv6wxRB3RVyU8cP216qRnN1R0Az5UqXQLRqdaHFTFgrKySZ70RdY B9v9PG0rLOHLoA2H6tCl7t3HbN+SpJqusw7zBVyU4o3OmmJRZuv691253J53HqsDe4V6 xda6Pi6StgjmZ3PXxZlpm45cdl2noV0drsK+k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=OBeNX+ckUDfEF0K2C+NI2OQPDCu89qKyy2WFojEswsJexiR+4dr9xI0fkPv+GeotBR BOEJxdYKYeBOai/BD1wZCUUgqdKbXvFkrKfnl0nXIAIkUAFzq0PUe0Rwq5INcKCdfG+T QzyrCPTgyS7I8neqtrRGx8tgyz8obpbCS1gt0= Received: by 10.204.54.82 with SMTP id p18mr1306551bkg.205.1289482130301; Thu, 11 Nov 2010 05:28:50 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id p22sm926623bkp.21.2010.11.11.05.28.48 (version=SSLv3 cipher=RC4-MD5); Thu, 11 Nov 2010 05:28:49 -0800 (PST) Sender: Alexander Motin Message-ID: <4CDBEF8D.5080001@FreeBSD.org> Date: Thu, 11 Nov 2010 15:28:45 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Joerg Schilling References: <4CD45209.5010607@FreeBSD.org> <20101105192028.GA68728@alchemy.franken.de> <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> <4CD82E2A.3070407@FreeBSD.org> <4cd8320a.U7/OjtLLBVtE4dTy%Joerg.Schilling@fokus.fraunhofer.de> <4CD83535.1010008@FreeBSD.org> <4cdbbfef.v4cr/k2jZr9gdpyF%Joerg.Schilling@fokus.fraunhofer.de> <4CDBC55B.1040307@FreeBSD.org> <4cdbc65f.bo+mYNFB2GPwXmq7%Joerg.Schilling@fokus.fraunhofer.de> <4CDBEA8B.1020306@FreeBSD.org> <4cdbece1.EWYSqdvnx6XWF8EF%Joerg.Schilling@fokus.fraunhofer.de> In-Reply-To: <4cdbece1.EWYSqdvnx6XWF8EF%Joerg.Schilling@fokus.fraunhofer.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, marius@alchemy.franken.de Subject: Re: Sense fetching [Was: cdrtools /devel ...] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Nov 2010 13:28:52 -0000 Joerg Schilling wrote: > Alexander Motin wrote: > >>> Compare the number of sense bytes I like to request (18) with the number >>> previous FreeBSD versions did actually request. It is obvious that in case >>> there is a resid reported onm an old kernel, libscg (with your chanhge) would >>> believe that probably less that the absolute minumum of sense data is available. >> Kernel code I have changed affects only controllers without automatic >> sense fetching. For such controllers CAM previously always reported zero >> sense_resid, independently of requested size (which actually was also >> ignored in this case). So previously whatever you asked for 18 or 32 >> bytes - sense_resid was always zero, like if you got full 18 or 32 >> bytes. That was wrong. Now, in the same situation, if device wants to >> return let's say 20 bytes -- you will get 0 and 12 bytes of sense_resid >> respectively, meaning 18 and 20 bytes of received sense. >> >> AFAIK sense_resid always measured from the requested sense_len. In my >> patch for libscg you may see that I have changed both request and >> response paths. Resulted sense_count should be absolutely the same. > > What is the requested size with the various HBAs in earlier kernels? For HBAs with automatic sense fetching -- as passed in sence_len request field. In case of libscg it was SSD_FULL_SIZE before and I've set it to be real value now. Returned sense_resid should be real in both cases, respecting submitted sense_len. For HBAs without sense fetching, CAM was always requesting SSD_FULL_SIZE and returned fake zero sense_resid, like if it just completely fulfilled sense_len from request. Now it should start honor sense_len on request and return real sense_resid on reply, relative to sense_len. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Thu Nov 11 13:45: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 3D35B10656A4 for ; Thu, 11 Nov 2010 13:45:50 +0000 (UTC) (envelope-from joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com) Received: from relay03-haj2.antispameurope.com (relay03-haj2.antispameurope.com [83.246.65.53]) by mx1.freebsd.org (Postfix) with ESMTP id 6EE428FC1D for ; Thu, 11 Nov 2010 13:45:49 +0000 (UTC) Received: by relay03-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id B78BE63C253; Thu, 11 Nov 2010 14:45:45 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay03-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id B195C63C24E; Thu, 11 Nov 2010 14:45:42 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id oABDjg5P007828; Thu, 11 Nov 2010 14:45:42 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Nov 2010 14:45:42 +0100 Date: Thu, 11 Nov 2010 14:45:42 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: mav@FreeBSD.org Message-ID: <4cdbf386.cAc+PtgM+41jseN5%Joerg.Schilling@fokus.fraunhofer.de> References: <4CD45209.5010607@FreeBSD.org> <20101105192028.GA68728@alchemy.franken.de> <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> <4CD82E2A.3070407@FreeBSD.org> <4cd8320a.U7/OjtLLBVtE4dTy%Joerg.Schilling@fokus.fraunhofer.de> <4CD83535.1010008@FreeBSD.org> <4cdbbfef.v4cr/k2jZr9gdpyF%Joerg.Schilling@fokus.fraunhofer.de> <4CDBC55B.1040307@FreeBSD.org> <4cdbc65f.bo+mYNFB2GPwXmq7%Joerg.Schilling@fokus.fraunhofer.de> <4CDBEA8B.1020306@FreeBSD.org> <4cdbece1.EWYSqdvnx6XWF8EF%Joerg.Schilling@fokus.fraunhofer.de> <4CDBEF8D.5080001@FreeBSD.org> In-Reply-To: <4CDBEF8D.5080001@FreeBSD.org> User-Agent: nail 11.22 3/20/05 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 11 Nov 2010 13:45:42.0628 (UTC) FILETIME=[BBD89A40:01CB81A6] Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, marius@alchemy.franken.de Subject: Re: Sense fetching [Was: cdrtools /devel ...] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Nov 2010 13:45:50 -0000 Alexander Motin wrote: > > What is the requested size with the various HBAs in earlier kernels? > > For HBAs with automatic sense fetching -- as passed in sence_len request > field. In case of libscg it was SSD_FULL_SIZE before and I've set it to > be real value now. Returned sense_resid should be real in both cases, > respecting submitted sense_len. > > For HBAs without sense fetching, CAM was always requesting SSD_FULL_SIZE > and returned fake zero sense_resid, like if it just completely fulfilled > sense_len from request. Now it should start honor sense_len on request > and return real sense_resid on reply, relative to sense_len. Then your patch to libscg seems to be OK and without risk. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From owner-freebsd-stable@FreeBSD.ORG Thu Nov 11 14:49: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 D34DA106564A for ; Thu, 11 Nov 2010 14:49:00 +0000 (UTC) (envelope-from bryce@bryce.net) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 738868FC16 for ; Thu, 11 Nov 2010 14:49:00 +0000 (UTC) Received: by wwi18 with SMTP id 18so1166107wwi.31 for ; Thu, 11 Nov 2010 06:48:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.255.148 with SMTP id j20mr829771wes.11.1289486938522; Thu, 11 Nov 2010 06:48:58 -0800 (PST) Received: by 10.216.172.209 with HTTP; Thu, 11 Nov 2010 06:48:58 -0800 (PST) In-Reply-To: <20101110054850.GA49976@icarus.home.lan> References: <20101110054850.GA49976@icarus.home.lan> Date: Thu, 11 Nov 2010 08:48:58 -0600 Message-ID: From: Bryce Edwards To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: 8-STABLE buildworld failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 14:49:01 -0000 On Tue, Nov 9, 2010 at 11:48 PM, Jeremy Chadwick wrote: > On Tue, Nov 09, 2010 at 06:09:08PM -0600, Bryce Edwards wrote: >> After updating source today, I am receiving the following error when >> running make NOCCACHE=3DYES -j16 buildkernel > > Please re-run the buildkernel without any -j or -jXX flags to see where > the actual error happened. =A0The below doesn't show the actual error due > to the nature of the parallel build. > > I doubt this has anything to do with ccache. > Thanks Jeremy, I forgot to disable paralllel builds. It is very clear now that it is related to the following in make.conf: PORTS_MODULES=3Demulators/virtualbox-ose-kmod Looks like the path of the make environment for the port doesn't find yasm (which is indeed installed and located in /usr/local/bin/yasm). cd ${PORTSDIR:-/usr/ports}/emulators/virtualbox-ose-kmod; SYSDIR=3D/usr/src/sys /usr/obj/usr/src/make.amd64/make -B all =3D=3D=3D> virtualbox-ose-kmod-3.2.10 depends on executable: yasm - not f= ound =3D=3D=3D> Verifying install for yasm in /usr/ports/devel/yasm =3D=3D=3D> Installing for yasm-1.1.0 =3D=3D=3D> yasm-1.1.0 depends on shared library: iconv.3 - found =3D=3D=3D> yasm-1.1.0 depends on shared library: intl - found =3D=3D=3D> Generating temporary packing list =3D=3D=3D> Checking if devel/yasm already installed =3D=3D=3D> yasm-1.1.0 is already installed You may wish to ``make deinstall'' and install this port again by ``make reinstall'' to upgrade it properly. If you really wish to overwrite the old port of devel/yasm without deleting it first, set the variable "FORCE_PKG_REGISTER" in your environment or the "make install" command line. *** Error code 1 Stop in /usr/ports/devel/yasm. *** Error code 1 Stop in /usr/ports/emulators/virtualbox-ose-kmod. *** Error code 1 Stop in /usr/ports/emulators/virtualbox-ose-kmod. *** Error code 1 Stop in /usr/obj/usr/src/sys/GENERIC. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. >> =3D=3D=3D> zlib (all) >> cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE >> -nostdinc =A0 -DHAVE_KERNEL_OPTION_HEADERS -include >> /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq >> -finline-limit=3D8000 --param inline-unit-growth=3D100 --param >> large-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer >> -I/usr/obj/usr/src/sys/GENERIC -mcmodel=3Dkernel -mno-red-zone >> -mfpmath=3D387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow >> -msoft-float -fno-asynchronous-unwind-tables -ffreestanding >> -fstack-protector -std=3Diso9899:1999 -fstack-protector -Wall >> -Wredundant-decls -Wnested-externs -Wstrict-prototypes >> -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual =A0-Wundef >> -Wno-pointer-sign -fformat-extensions -c >> /usr/src/sys/modules/zlib/../../net/zlib.c >> ld =A0-d -warn-common -r -d -o zlib.ko.debug zlib.o >> :> export_syms >> awk -f /usr/src/sys/conf/kmod_syms.awk zlib.ko.debug =A0export_syms | >> xargs -J% objcopy % zlib.ko.debug >> objcopy --only-keep-debug zlib.ko.debug zlib.ko.symbols >> objcopy --strip-debug --add-gnu-debuglink=3Dzlib.ko.symbols zlib.ko.debu= g zlib.ko >> 1 error >> *** Error code 2 >> 1 error >> *** Error code 2 > > -- > | Jeremy Chadwick =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 jdc@parodius.com | > | Parodius Networking =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://= www.parodius.com/ | > | UNIX Systems Administrator =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Mountain = View, CA, USA | > | Making life hard for others since 1977. =A0 =A0 =A0 =A0 =A0 =A0 =A0PGP:= 4BD6C0CB | > > From owner-freebsd-stable@FreeBSD.ORG Thu Nov 11 16:10: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 7740F1065672; Thu, 11 Nov 2010 16:10:58 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 61BF98FC15; Thu, 11 Nov 2010 16:10:58 +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 oABGAvV6018721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Nov 2010 08:10:57 -0800 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id CA5A71CC0E; Thu, 11 Nov 2010 08:10:57 -0800 (PST) To: Kirill Yelizarov In-reply-to: Your message of "Wed, 10 Nov 2010 23:49:56 PST." <816869.17580.qm@web120510.mail.ne1.yahoo.com> Date: Thu, 11 Nov 2010 08:10:57 -0800 From: "Kevin Oberman" Message-Id: <20101111161057.CA5A71CC0E@ptavv.es.net> Cc: freebsd-stable@freebsd.org, net@freebsd.org Subject: Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Nov 2010 16:10:58 -0000 > Date: Wed, 10 Nov 2010 23:49:56 -0800 (PST) > From: Kirill Yelizarov > > > > --- On Thu, 11/11/10, Kevin Oberman wrote: > > > From: Kevin Oberman > > Subject: Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED] > > To: "Wilkinson, Alex" > > Cc: freebsd-stable@freebsd.org > > Date: Thursday, November 11, 2010, 8:26 AM > > > Date: Thu, 11 Nov 2010 13:01:26 > > +0800 > > > From: "Wilkinson, Alex" > > > Sender: owner-freebsd-stable@freebsd.org > > > > > > > > >     0n Wed, Nov 10, 2010 at > > 04:21:12AM -0800, Kirill Yelizarov wrote: > > > > > >     >All my em cards running > > 8.1 stable don't reply to icmp echo requests packets larger > > than 1472 bytes. > > >     > > > >     >On stable 7.2 the same > > hardware works as expected: > > >     ># ping -s 1500 > > 192.168.64.99 > > >     >PING 192.168.64.99 > > (192.168.64.99): 1500 data bytes > > >     >1508 bytes from > > 192.168.64.99: icmp_seq=0 ttl=63 time=1.249 ms > > >     >1508 bytes from > > 192.168.64.99: icmp_seq=1 ttl=63 time=1.158 ms > > >     > > > >     >Here is the dump on em > > interface > > >     >15:06:31.452043 IP > > 192.168.66.65 > *****: ICMP echo request, id 28729, seq > > 5, length 1480 > > >     >15:06:31.452047 IP > > 192.168.66.65 > ****: icmp > > >     >15:06:31.452069 IP **** > > > 192.168.66.65: ICMP echo reply, id 28729, seq 5, length > > 1480 > > >     >15:06:31.452071 IP *** > > > 192.168.66.65: icmp > > >     > > > >     >Same ping from same source > > (it's a 8.1 stable with fxp interface) to em card running > > 8.1 stable > > >     >#pciconf -lv > > >  > >    >em0@pci0:3:4:0:    > > class=0x020000 card=0x10798086 chip=0x10798086 rev=0x03 > > hdr=0x00 > > >     >    vendor  > >    = 'Intel Corporation' > > >     >    device  > >    = 'Dual Port Gigabit Ethernet Controller > > (82546EB)' > > >     >    class  > >     = network > > >     >    > > subclass   = ethernet > > >     > > > >     ># ping -s 1472 > > 192.168.64.200 > > >     >PING 192.168.64.200 > > (192.168.64.200): 1472 data bytes > > >     >1480 bytes from > > 192.168.64.200: icmp_seq=0 ttl=63 time=0.848 ms > > >     >^C > > >     > > > >     ># ping -s 1473 > > 192.168.64.200 > > >     >PING 192.168.64.200 > > (192.168.64.200): 1473 data bytes > > >     >^C > > >     >--- 192.168.64.200 ping > > statistics --- > > >     >4 packets transmitted, 0 > > packets received, 100.0% packet loss > > > > > > works fine for me: > > > > > > FreeBSD 8.1-STABLE #0 r213395 > > > > > > em0@pci0:0:25:0:class=0x020000 card=0x3035103c > > chip=0x10de8086 rev=0x02 hdr=0x00 > > >     vendor  > >    = 'Intel Corporation' > > >     device  > >    = 'Intel Gigabit network connection > > (82567LM-3 )' > > >     class      = > > network > > >     subclass   = > > ethernet > > > > > > #ping -s 1473 host > > > PING host(192.168.1.1): 1473 data bytes > > > 1481 bytes from 192.168.1.1: icmp_seq=0 ttl=253 > > time=31.506 ms > > > 1481 bytes from 192.168.1.1: icmp_seq=1 ttl=253 > > time=31.493 ms > > > 1481 bytes from 192.168.1.1: icmp_seq=2 ttl=253 > > time=31.550 ms > > > ^C > > > > The reason the '-s 1500' worked was that the packets were > > fragmented. If > > I add the '-D' option, '-s 1473' fails on v7 and v8. Are > > the V8 systems > > where you see if failing without the '-D' on the same > > network segment? > > If not, it is likely that an intervening device is refusing > > to fragment > > the packet. (Some routers deliberately don't fragment ICMP > > Echos Request > > packets.) > > If i set -D -s 1473 sender side refuses to ping and that is > correct. All mentioned above machines are behind the same router and > switch. Same hardware running v7 is working while v8 is not. And i > never saw such problems before. Also correct me if i'm wrong but the > dump shows that the packet arrived. I'll try driver from head and will > post here results. I did a bit more looking at this today and I see that something bogus is going on and it MAY be the em driver. I tried 1473 data byte pings without the DF flag. I then captured the packets on both ends (where the sending system has a bge (Broadcom GE) and the responding end has an em (Intel) card. What I saw was the fragmented IP packets all being received by the system with the em interface and an ICMP Echo Reply being sent back, again fragmented. I saw the reply on both ends, so both interfaces were able to fragment an over-sized packet, transmit the two pieces, and receive the two pieces. The em device could re-assemble them properly, but the bge device does not seem to re-assemble them correctly or else has a problem with ICMP packets bigger then MTU size. When I send from the em system, I see the packets and fragments all arrive in good form, but the system never sends out a reply. Since this is a kernel function, it may be a driver, but I suspect that it is in the IP stack since I am seeing the problem with a Broadcom card and I see the data all arriving. I think Jack can probably relax, but some patch to the network stack seems to have broken at least ICMP processing. And, since the bge system ups updated to 8-Stable on October 20 while the em system was updated back on August 9, I suspect the flaw was not driver related and was committed between August 9 and Oct. 20. I think this needs to go to the network list where the folks who tinker with that part of the kernel tend to hang out. Sorry for the cross-post. -- 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 Thu Nov 11 19:01: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 5B2901065673 for ; Thu, 11 Nov 2010 19:01:35 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 0DD4A8FC08 for ; Thu, 11 Nov 2010 19:01:34 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:b11b:8f5:3197:8539] ([IPv6:2607:f3e0:0:4:b11b:8f5:3197:8539]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id oABJ1RZu003156 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 11 Nov 2010 14:01:27 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4CDC3D7B.7000108@sentex.net> Date: Thu, 11 Nov 2010 14:01:15 -0500 From: Mike Tancsa User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20101111052656.21C0E1CC0E@ptavv.es.net> In-Reply-To: <20101111052656.21C0E1CC0E@ptavv.es.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Subject: Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Nov 2010 19:01:35 -0000 On 11/11/2010 12:26 AM, Kevin Oberman wrote: >> Date: Thu, 11 Nov 2010 13:01:26 +0800 >> From: "Wilkinson, Alex" >> Sender: owner-freebsd-stable@freebsd.org >> >> >> 0n Wed, Nov 10, 2010 at 04:21:12AM -0800, Kirill Yelizarov wrote: >> >> >All my em cards running 8.1 stable don't reply to icmp echo requests packets larger than 1472 bytes. >> > >> >On stable 7.2 the same hardware works as expected: >> ># ping -s 1500 192.168.64.99 >> >PING 192.168.64.99 (192.168.64.99): 1500 data bytes >> >1508 bytes from 192.168.64.99: icmp_seq=0 ttl=63 time=1.249 ms >> >1508 bytes from 192.168.64.99: icmp_seq=1 ttl=63 time=1.158 ms >> > >> >Here is the dump on em interface >> >15:06:31.452043 IP 192.168.66.65 > *****: ICMP echo request, id 28729, seq 5, length 1480 >> >15:06:31.452047 IP 192.168.66.65 > ****: icmp >> >15:06:31.452069 IP **** > 192.168.66.65: ICMP echo reply, id 28729, seq 5, length 1480 >> >15:06:31.452071 IP *** > 192.168.66.65: icmp >> > >> >Same ping from same source (it's a 8.1 stable with fxp interface) to em card running 8.1 stable >> >#pciconf -lv >> >em0@pci0:3:4:0: class=0x020000 card=0x10798086 chip=0x10798086 rev=0x03 hdr=0x00 >> > vendor = 'Intel Corporation' >> > device = 'Dual Port Gigabit Ethernet Controller (82546EB)' >> > class = network >> > subclass = ethernet >> > >> ># ping -s 1472 192.168.64.200 >> >PING 192.168.64.200 (192.168.64.200): 1472 data bytes >> >1480 bytes from 192.168.64.200: icmp_seq=0 ttl=63 time=0.848 ms >> >^C >> > >> ># ping -s 1473 192.168.64.200 >> >PING 192.168.64.200 (192.168.64.200): 1473 data bytes >> >^C >> >--- 192.168.64.200 ping statistics --- >> >4 packets transmitted, 0 packets received, 100.0% packet loss >> >> works fine for me: >> >> FreeBSD 8.1-STABLE #0 r213395 >> >> em0@pci0:0:25:0:class=0x020000 card=0x3035103c chip=0x10de8086 rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'Intel Gigabit network connection (82567LM-3 )' >> class = network >> subclass = ethernet >> >> #ping -s 1473 host >> PING host(192.168.1.1): 1473 data bytes >> 1481 bytes from 192.168.1.1: icmp_seq=0 ttl=253 time=31.506 ms >> 1481 bytes from 192.168.1.1: icmp_seq=1 ttl=253 time=31.493 ms >> 1481 bytes from 192.168.1.1: icmp_seq=2 ttl=253 time=31.550 ms >> ^C > > The reason the '-s 1500' worked was that the packets were fragmented. If > I add the '-D' option, '-s 1473' fails on v7 and v8. Are the V8 systems > where you see if failing without the '-D' on the same network segment? > If not, it is likely that an intervening device is refusing to fragment > the packet. (Some routers deliberately don't fragment ICMP Echos Request > packets.) I am not sure I follow. If you do a ping -s 1473 -D on an interface that has the default MTU of 1500, it wont work, as the entire packet is going to be 1501 (note the data bytes) eg. # ping -q -s 1472 -c 1 192.168.43.219 PING 192.168.43.219 (192.168.43.219): 1472 data bytes --- 192.168.43.219 ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 1.714/1.714/1.714/0.000 ms on 192.168.43.219, I see and on .43.219, I see 0(ich10)# tcpdump -vvvni em2 icmp tcpdump: listening on em2, link-type EN10MB (Ethernet), capture size 96 bytes 13:49:17.564482 IP (tos 0x0, ttl 63, id 53656, offset 0, flags [none], proto ICMP (1), length 1500) 192.168.42.11 > 192.168.43.219: ICMP echo request, id 23315, seq 0, length 1480 13:49:17.564499 IP (tos 0x0, ttl 64, id 14346, offset 0, flags [none], proto ICMP (1), length 1500) 192.168.43.219 > 192.168.42.11: ICMP echo reply, id 23315, seq 0, length 1480 Note the length is 1500 of the packet. That being said, if its failing on the em nic where you dont specify the -D flag on the ping, then there is a bug somewhere. On certain em nics, I found doing ifconfig em0 -rxcsum ifconfig em0 -txcsum ifconfig em0 -tso works around a number of bugs ---Mike From owner-freebsd-stable@FreeBSD.ORG Thu Nov 11 20:23: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 09F93106564A for ; Thu, 11 Nov 2010 20:23:19 +0000 (UTC) (envelope-from ykirill@yahoo.com) Received: from web120519.mail.ne1.yahoo.com (web120519.mail.ne1.yahoo.com [98.138.85.246]) by mx1.freebsd.org (Postfix) with SMTP id C33F08FC1B for ; Thu, 11 Nov 2010 20:23:18 +0000 (UTC) Received: (qmail 19301 invoked by uid 60001); 11 Nov 2010 19:56:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1289505397; bh=vKVDqC838MUp22edXbN1LUVKhPvFt2S9y5AGaRrz2vM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=h8VSQxGxDlbvvKqClP0mGZCna4A0U8BA3rF1+IR+qMKyolwfGeXgsTeMCcDfMuw7i7l0XPnrOhb29wbJ4V+WHcJXC2RohbTMNpN/MJM5r9Xha6MQKTBe8+avtJ3GXgIwEoLHvGoE1o3J1s+zOD9MlMun3wASjWFftMx42aB/zjk= 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:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=HFTw1x+VjA9x7pgcN5K9gzCOAPqpqLgZ5RpiZYdrOVsGaWAu3q83Iyyi7BXbAkNf7wF7aNbMoGeXR7glntjvzMjcofe93BIw2aOf66buZ1LyKW3IlwZgukTh9cJ3cc2FruDhtNnycFQ7zTOJSO1Rb2F5YjYjPae6lnU0Y+ISmm4=; Message-ID: <985402.19076.qm@web120519.mail.ne1.yahoo.com> X-YMail-OSG: LV1V2OQVM1lTRokG4mjVK17LUsWFil5wTpKRercsQ2U1gzx bKsPg4AME Received: from [195.14.37.142] by web120519.mail.ne1.yahoo.com via HTTP; Thu, 11 Nov 2010 11:56:37 PST X-Mailer: YahooMailClassic/11.4.9 YahooMailWebService/0.8.107.285259 Date: Thu, 11 Nov 2010 11:56:37 -0800 (PST) From: Kirill Yelizarov To: freebsd-stable@freebsd.org In-Reply-To: <4CDC3D7B.7000108@sentex.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Nov 2010 20:23:19 -0000 =0A=0A--- On Thu, 11/11/10, Mike Tancsa wrote:=0A=0A> Fro= m: Mike Tancsa =0A> Subject: Re: icmp packets on em larger= than 1472 [SEC=3DUNCLASSIFIED]=0A> To: freebsd-stable@freebsd.org=0A> Date= : Thursday, November 11, 2010, 10:01 PM=0A> On 11/11/2010 12:26 AM, Kevin O= berman=0A> wrote:=0A> >> Date: Thu, 11 Nov 2010 13:01:26 +0800=0A> >> From:= "Wilkinson, Alex" =0A> >> Sender: owne= r-freebsd-stable@freebsd.org=0A> >>=0A> >>=0A> >>=A0 =A0=A0=A00n Wed, Nov 1= 0, 2010 at=0A> 04:21:12AM -0800, Kirill Yelizarov wrote: =0A> >>=0A> >>=A0 = =A0=A0=A0>All my em cards=0A> running 8.1 stable don't reply to icmp echo r= equests packets=0A> larger than 1472 bytes.=0A> >>=A0 =A0=A0=A0>=0A> >>=A0 = =A0=A0=A0>On stable 7.2 the same=0A> hardware works as expected:=0A> >>=A0 = =A0=A0=A0># ping -s 1500=0A> 192.168.64.99=0A> >>=A0 =A0=A0=A0>PING 192.168= .64.99=0A> (192.168.64.99): 1500 data bytes=0A> >>=A0 =A0=A0=A0>1508 bytes = from=0A> 192.168.64.99: icmp_seq=3D0 ttl=3D63 time=3D1.249 ms=0A> >>=A0 =A0= =A0=A0>1508 bytes from=0A> 192.168.64.99: icmp_seq=3D1 ttl=3D63 time=3D1.15= 8 ms=0A> >>=A0 =A0=A0=A0>=0A> >>=A0 =A0=A0=A0>Here is the dump on em=0A> in= terface=0A> >>=A0 =A0=A0=A0>15:06:31.452043 IP=0A> 192.168.66.65 > *****: I= CMP echo request, id 28729, seq=0A> 5, length 1480=0A> >>=A0 =A0=A0=A0>15:0= 6:31.452047 IP=0A> 192.168.66.65 > ****: icmp=0A> >>=A0 =A0=A0=A0>15:06:31.= 452069 IP=0A> **** > 192.168.66.65: ICMP echo reply, id 28729, seq 5,=0A> l= ength 1480=0A> >>=A0 =A0=A0=A0>15:06:31.452071 IP ***=0A> > 192.168.66.65: = icmp=0A> >>=A0 =A0=A0=A0> =0A> >>=A0 =A0=A0=A0>Same ping from same=0A> sour= ce (it's a 8.1 stable with fxp interface) to em card=0A> running 8.1 stable= =0A> >>=A0 =A0=A0=A0>#pciconf -lv=0A> >>=A0=0A> =A0=A0=A0>em0@pci0:3:4:0:= =A0=A0=A0=0A> class=3D0x020000 card=3D0x10798086 chip=3D0x10798086 rev=3D0x= 03=0A> hdr=3D0x00=0A> >>=A0 =A0=A0=A0>=A0 =A0=0A> vendor=A0 =A0=A0=A0=3D 'I= ntel Corporation'=0A> >>=A0 =A0=A0=A0>=A0 =A0=0A> device=A0 =A0=A0=A0=3D 'D= ual Port Gigabit Ethernet=0A> Controller (82546EB)'=0A> >>=A0 =A0=A0=A0>=A0= =A0=0A> class=A0 =A0 =A0 =3D network=0A> >>=A0 =A0=A0=A0>=A0 =A0=0A> subcl= ass=A0=A0=A0=3D ethernet=0A> >>=A0 =A0=A0=A0>=0A> >>=A0 =A0=A0=A0># ping -s= 1472=0A> 192.168.64.200=0A> >>=A0 =A0=A0=A0>PING 192.168.64.200=0A> (192.1= 68.64.200): 1472 data bytes=0A> >>=A0 =A0=A0=A0>1480 bytes from=0A> 192.168= .64.200: icmp_seq=3D0 ttl=3D63 time=3D0.848 ms=0A> >>=A0 =A0=A0=A0>^C=0A> >= >=A0 =A0=A0=A0>=0A> >>=A0 =A0=A0=A0># ping -s 1473=0A> 192.168.64.200=0A> >= >=A0 =A0=A0=A0>PING 192.168.64.200=0A> (192.168.64.200): 1473 data bytes=0A= > >>=A0 =A0=A0=A0>^C=0A> >>=A0 =A0=A0=A0>--- 192.168.64.200=0A> ping statis= tics ---=0A> >>=A0 =A0=A0=A0>4 packets transmitted,=0A> 0 packets received,= 100.0% packet loss=0A> >>=0A> >> works fine for me:=0A> >>=0A> >> FreeBSD = 8.1-STABLE #0 r213395=0A> >>=0A> >> em0@pci0:0:25:0:class=3D0x020000 card= =3D0x3035103c=0A> chip=3D0x10de8086 rev=3D0x02 hdr=3D0x00=0A> >>=A0 =A0=A0= =A0vendor=A0=0A> =A0=A0=A0=3D 'Intel Corporation'=0A> >>=A0 =A0=A0=A0device= =A0=0A> =A0=A0=A0=3D 'Intel Gigabit network connection=0A> (82567LM-3 )'=0A= > >>=A0 =A0=A0=A0class=A0 =A0 =A0=0A> =3D network=0A> >>=A0=0A> =A0=A0=A0su= bclass=A0=A0=A0=3D ethernet=0A> >>=0A> >> #ping -s 1473 host=0A> >> PING ho= st(192.168.1.1): 1473 data bytes=0A> >> 1481 bytes from 192.168.1.1: icmp_s= eq=3D0 ttl=3D253=0A> time=3D31.506 ms=0A> >> 1481 bytes from 192.168.1.1: i= cmp_seq=3D1 ttl=3D253=0A> time=3D31.493 ms=0A> >> 1481 bytes from 192.168.1= .1: icmp_seq=3D2 ttl=3D253=0A> time=3D31.550 ms=0A> >> ^C=0A> > =0A> > The = reason the '-s 1500' worked was that the packets=0A> were fragmented. If=0A= > > I add the '-D' option, '-s 1473' fails on v7 and v8.=0A> Are the V8 sys= tems=0A> > where you see if failing without the '-D' on the same=0A> networ= k segment?=0A> > If not, it is likely that an intervening device is=0A> ref= using to fragment=0A> > the packet. (Some routers deliberately don't fragme= nt=0A> ICMP Echos Request=0A> > packets.) =0A> =0A> =0A> I am not sure I fo= llow. If you do a=0A> ping -s 1473 -D=0A> on an interface that has the defa= ult MTU of 1500, it wont=0A> work, as the=0A> entire packet is going to be = 1501 (note the data bytes)=0A> =0A> eg.=0A> # ping=A0 -q -s 1472 -c 1 192.1= 68.43.219=0A> PING 192.168.43.219 (192.168.43.219): 1472 data bytes=0A> =0A= > --- 192.168.43.219 ping statistics ---=0A> 1 packets transmitted, 1 packe= ts received, 0.0% packet=0A> loss=0A> round-trip min/avg/max/stddev =3D 1.7= 14/1.714/1.714/0.000 ms=0A> on 192.168.43.219, I see=0A> =0A> and on .43.21= 9, I see=0A> =0A> 0(ich10)# tcpdump -vvvni em2 icmp=0A> tcpdump: listening = on em2, link-type EN10MB (Ethernet),=0A> capture size 96=0A> bytes=0A> 13:4= 9:17.564482 IP (tos 0x0, ttl 63, id 53656, offset 0,=0A> flags [none],=0A> = proto ICMP (1), length 1500)=0A> =A0 =A0 192.168.42.11 > 192.168.43.219: IC= MP echo=0A> request, id 23315, seq 0,=0A> length 1480=0A> 13:49:17.564499 I= P (tos 0x0, ttl 64, id 14346, offset 0,=0A> flags [none],=0A> proto ICMP (1= ), length 1500)=0A> =A0 =A0 192.168.43.219 > 192.168.42.11: ICMP echo=0A> r= eply, id 23315, seq 0,=0A> length 1480=0A> =0A> =0A> Note the length is 150= 0 of the packet.=0A> =0A> That being said, if its failing on the em nic whe= re you=0A> dont specify the=0A> -D flag on the ping, then there is a bug so= mewhere.=A0=0A> On certain em nics,=0A> I found doing=0A> ifconfig em0 -rxc= sum=0A> ifconfig em0 -txcsum=0A> ifconfig em0 -tso=0A> =0A> works around a = number of bugs=0A> =0A> =A0=A0=A0 ---Mike=0A> =0AYes, i know it. This was t= he first thing i tried. Sorry, i didn't mention it. =0A=0AKirill=0A> =0A> = =0A> _______________________________________________=0A> freebsd-stable@fre= ebsd.org=0A> mailing list=0A> http://lists.freebsd.org/mailman/listinfo/fre= ebsd-stable=0A> To unsubscribe, send any mail to "freebsd-stable-unsubscrib= e@freebsd.org"=0A> =0A=0A From owner-freebsd-stable@FreeBSD.ORG Thu Nov 11 21:05: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 601DC1065672; Thu, 11 Nov 2010 21:05:34 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1F1698FC19; Thu, 11 Nov 2010 21:05:33 +0000 (UTC) Received: by pvc22 with SMTP id 22so535219pvc.13 for ; Thu, 11 Nov 2010 13:05:33 -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:content-transfer-encoding:in-reply-to :user-agent; bh=bJmqtQRPm38Y9qOJkCB8izzVHlpKxHbp9sa9dtsInYY=; b=qfi0XeKeaXMAgRgVyoXRX0iiJBlY4Z+IRXa1zfTd4Sa8NEYPu4WKg69iXHNd2IKOOy l1B2Tl06a07vkbUbg3vbgs5e9DmUDiPIfrtWA00DtfXTQVo4WNlrwvsrZ5XJwbB1ZvdD AwzXS+pSs9WysV2HNNqDvQrqm//JUJheFt9Aw= 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:content-transfer-encoding :in-reply-to:user-agent; b=GUr0CCYqG7nxk55uOCqu4Kc3vCPpMmcUlm/2/CkEMXJz4gjRZN7ZHxZnUCxN/KDBRv Zl7+8xpSNmqx9LunvF/v2PJoaoM7IJQHREnABkFZnaDPc9IQ6dfpmNrOvhJrLpGKaQon Wz4rFfF0QeBctwbJIgFDDKVF5ZoyvwoFD1TD0= Received: by 10.143.18.7 with SMTP id v7mr1188924wfi.254.1289509532674; Thu, 11 Nov 2010 13:05:32 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id q13sm2832996wfc.17.2010.11.11.13.05.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Nov 2010 13:05:30 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 11 Nov 2010 13:04:36 -0800 From: Pyun YongHyeon Date: Thu, 11 Nov 2010 13:04:36 -0800 To: Kevin Oberman Message-ID: <20101111210436.GD17566@michelle.cdnetworks.com> References: <816869.17580.qm@web120510.mail.ne1.yahoo.com> <20101111161057.CA5A71CC0E@ptavv.es.net> Mime-Version: 1.0 Content-Type: text/plain; charset=EUC-KR Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20101111161057.CA5A71CC0E@ptavv.es.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org, Kirill Yelizarov , net@freebsd.org Subject: Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED] 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, 11 Nov 2010 21:05:34 -0000 On Thu, Nov 11, 2010 at 08:10:57AM -0800, Kevin Oberman wrote: > > Date: Wed, 10 Nov 2010 23:49:56 -0800 (PST) > > From: Kirill Yelizarov > > > > > > > > --- On Thu, 11/11/10, Kevin Oberman wrote: > > > > > From: Kevin Oberman > > > Subject: Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED] > > > To: "Wilkinson, Alex" > > > Cc: freebsd-stable@freebsd.org > > > Date: Thursday, November 11, 2010, 8:26 AM > > > > Date: Thu, 11 Nov 2010 13:01:26 > > > +0800 > > > > From: "Wilkinson, Alex" > > > > Sender: owner-freebsd-stable@freebsd.org > > > > > > > > > > > >? ???0n Wed, Nov 10, 2010 at > > > 04:21:12AM -0800, Kirill Yelizarov wrote: > > > > > > > >? ???>All my em cards running > > > 8.1 stable don't reply to icmp echo requests packets larger > > > than 1472 bytes. > > > >? ???> > > > >? ???>On stable 7.2 the same > > > hardware works as expected: > > > >? ???># ping -s 1500 > > > 192.168.64.99 > > > >? ???>PING 192.168.64.99 > > > (192.168.64.99): 1500 data bytes > > > >? ???>1508 bytes from > > > 192.168.64.99: icmp_seq=0 ttl=63 time=1.249 ms > > > >? ???>1508 bytes from > > > 192.168.64.99: icmp_seq=1 ttl=63 time=1.158 ms > > > >? ???> > > > >? ???>Here is the dump on em > > > interface > > > >? ???>15:06:31.452043 IP > > > 192.168.66.65 > *****: ICMP echo request, id 28729, seq > > > 5, length 1480 > > > >? ???>15:06:31.452047 IP > > > 192.168.66.65 > ****: icmp > > > >? ???>15:06:31.452069 IP **** > > > > 192.168.66.65: ICMP echo reply, id 28729, seq 5, length > > > 1480 > > > >? ???>15:06:31.452071 IP *** > > > > 192.168.66.65: icmp > > > >? ???> > > > >? ???>Same ping from same source > > > (it's a 8.1 stable with fxp interface) to em card running > > > 8.1 stable > > > >? ???>#pciconf -lv > > > >? > > > ???>em0@pci0:3:4:0:??? > > > class=0x020000 card=0x10798086 chip=0x10798086 rev=0x03 > > > hdr=0x00 > > > >? ???>? ? vendor? > > > ???= 'Intel Corporation' > > > >? ???>? ? device? > > > ???= 'Dual Port Gigabit Ethernet Controller > > > (82546EB)' > > > >? ???>? ? class? > > > ? ? = network > > > >? ???>? ? > > > subclass???= ethernet > > > >? ???> > > > >? ???># ping -s 1472 > > > 192.168.64.200 > > > >? ???>PING 192.168.64.200 > > > (192.168.64.200): 1472 data bytes > > > >? ???>1480 bytes from > > > 192.168.64.200: icmp_seq=0 ttl=63 time=0.848 ms > > > >? ???>^C > > > >? ???> > > > >? ???># ping -s 1473 > > > 192.168.64.200 > > > >? ???>PING 192.168.64.200 > > > (192.168.64.200): 1473 data bytes > > > >? ???>^C > > > >? ???>--- 192.168.64.200 ping > > > statistics --- > > > >? ???>4 packets transmitted, 0 > > > packets received, 100.0% packet loss > > > > > > > > works fine for me: > > > > > > > > FreeBSD 8.1-STABLE #0 r213395 > > > > > > > > em0@pci0:0:25:0:class=0x020000 card=0x3035103c > > > chip=0x10de8086 rev=0x02 hdr=0x00 > > > >? ???vendor? > > > ???= 'Intel Corporation' > > > >? ???device? > > > ???= 'Intel Gigabit network connection > > > (82567LM-3 )' > > > >? ???class? ? ? = > > > network > > > >? ???subclass???= > > > ethernet > > > > > > > > #ping -s 1473 host > > > > PING host(192.168.1.1): 1473 data bytes > > > > 1481 bytes from 192.168.1.1: icmp_seq=0 ttl=253 > > > time=31.506 ms > > > > 1481 bytes from 192.168.1.1: icmp_seq=1 ttl=253 > > > time=31.493 ms > > > > 1481 bytes from 192.168.1.1: icmp_seq=2 ttl=253 > > > time=31.550 ms > > > > ^C > > > > > > The reason the '-s 1500' worked was that the packets were > > > fragmented. If > > > I add the '-D' option, '-s 1473' fails on v7 and v8. Are > > > the V8 systems > > > where you see if failing without the '-D' on the same > > > network segment? > > > If not, it is likely that an intervening device is refusing > > > to fragment > > > the packet. (Some routers deliberately don't fragment ICMP > > > Echos Request > > > packets.) > > > > If i set -D -s 1473 sender side refuses to ping and that is > > correct. All mentioned above machines are behind the same router and > > switch. Same hardware running v7 is working while v8 is not. And i > > never saw such problems before. Also correct me if i'm wrong but the > > dump shows that the packet arrived. I'll try driver from head and will > > post here results. > > I did a bit more looking at this today and I see that something bogus is > going on and it MAY be the em driver. > > I tried 1473 data byte pings without the DF flag. I then captured the > packets on both ends (where the sending system has a bge (Broadcom GE) > and the responding end has an em (Intel) card. > > What I saw was the fragmented IP packets all being received by the > system with the em interface and an ICMP Echo Reply being sent back, > again fragmented. I saw the reply on both ends, so both interfaces were > able to fragment an over-sized packet, transmit the two pieces, and > receive the two pieces. The em device could re-assemble them properly, > but the bge device does not seem to re-assemble them correctly or else > has a problem with ICMP packets bigger then MTU size. > > When I send from the em system, I see the packets and fragments all > arrive in good form, but the system never sends out a reply. Since this > is a kernel function, it may be a driver, but I suspect that it is in > the IP stack since I am seeing the problem with a Broadcom card and I > see the data all arriving. > Most ethernet controllers including bge(4) have a function to specify how much RX buffer space would be allocated to receive a frame. When controller receive a frame that has larger size than the size specified in RX buffer space, it would drop the frame. Because the oversized frame was silently dropped in driver layer upper stack has no chance to reply back ICMP responses with fragmentation needed bit for frames that set don't fragment bit. This is where correct MTU configuration play an important role in driver layer. If you want to handle oversized frame you also have to set correct MTU of interface. However all controllers should be able to receive standard MTU sized frame including VLAN tag so no special configuration is needed when you handle standard MTU sized frames. Some old controllers can't handle VLAN oversized frame such that you would have no way to send or receive them. em(4) controllers have different receiving logic where it allows chaining multiple oversized frames into a single frame. So up to certain point, which depends on the size of jumbo frame controller supports, em(4) can receive these oversized frames regardless of MTU configuration with the help of driver. The chaining is done in driver layer and that would add additional overhead(chaining + multiple mbuf allocation) but it has its own advantages. I was not able to to reproduce the issue with em(4)/bge(4) on CURRENT and these drivers worked as expected. > I think Jack can probably relax, but some patch to the network stack > seems to have broken at least ICMP processing. And, since the bge system > ups updated to 8-Stable on October 20 while the em system was updated > back on August 9, I suspect the flaw was not driver related and was > committed between August 9 and Oct. 20. > > I think this needs to go to the network list where the folks who tinker > with that part of the kernel tend to hang out. Sorry for the cross-post. > -- > 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 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Thu Nov 11 21:11:03 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 15B1B1065670; Thu, 11 Nov 2010 21:11:03 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy.sentex.ca (unknown [IPv6:2607:f3e0:0:3::6502:9a]) by mx1.freebsd.org (Postfix) with ESMTP id C34188FC16; Thu, 11 Nov 2010 21:11:02 +0000 (UTC) Received: from freebsd-legacy.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy.sentex.ca (8.14.4/8.14.4) with ESMTP id oABGBDl2035588; Thu, 11 Nov 2010 16:11:13 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy.sentex.ca (8.14.4/8.14.4/Submit) id oABGBDwK035587; Thu, 11 Nov 2010 16:11:13 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 11 Nov 2010 16:11:13 GMT Message-Id: <201011111611.oABGBDwK035587@freebsd-legacy.sentex.ca> X-Authentication-Warning: freebsd-legacy.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_7_1 tinderbox] failure on i386/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 21:11:03 -0000 TB --- 2010-11-11 15:34:59 - tinderbox 2.6 running on freebsd-legacy.sentex.ca TB --- 2010-11-11 15:34:59 - starting RELENG_7_1 tinderbox run for i386/i386 TB --- 2010-11-11 15:34:59 - cleaning the object tree TB --- 2010-11-11 15:35:03 - cvsupping the source tree TB --- 2010-11-11 15:35:03 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca -s /usr/home/tinderbox/RELENG_7_1/i386/i386/supfile TB --- 2010-11-11 15:35:08 - building world TB --- 2010-11-11 15:35:08 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-11 15:35:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-11 15:35:08 - TARGET=i386 TB --- 2010-11-11 15:35:08 - TARGET_ARCH=i386 TB --- 2010-11-11 15:35:08 - TZ=UTC TB --- 2010-11-11 15:35:08 - __MAKE_CONF=/dev/null TB --- 2010-11-11 15:35:08 - cd /src TB --- 2010-11-11 15:35:08 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 11 15:35:09 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies [...] ===> gnu/usr.bin/cc (depend) ===> gnu/usr.bin/cc/cc_tools (depend) cc -O2 -fno-strict-aliasing -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/obj/i386/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -c /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/gengtype.c cc -O2 -fno-strict-aliasing -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/obj/i386/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -c gengtype-yacc+%DIKED.c cc -O2 -fno-strict-aliasing -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/obj/i386/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -c gengtype-lex.c cc -O2 -fno-strict-aliasing -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/obj/i386/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -c /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/errors.c cc -O2 -fno-strict-aliasing -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/obj/i386/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -o gengtype gengtype.o gengtype-yacc+%DIKED.o gengtype-lex.o errors.o libiberty.a libiberty.a: could not read symbols: File format not recognized *** Error code 1 Stop in /src/gnu/usr.bin/cc/cc_tools. *** Error code 1 Stop in /src/gnu/usr.bin/cc. *** Error code 1 Stop in /src/gnu/usr.bin. *** Error code 1 Stop in /src/gnu. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-11 16:11:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-11 16:11:13 - ERROR: failed to build world TB --- 2010-11-11 16:11:13 - 1693.76 user 262.76 system 2174.26 real http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7_1-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Thu Nov 11 21:37: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 2A21D106564A; Thu, 11 Nov 2010 21:37:23 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 149648FC17; Thu, 11 Nov 2010 21:37:23 +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 oABLbM8p009216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Nov 2010 13:37:22 -0800 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 55BC91CC12; Thu, 11 Nov 2010 13:37:22 -0800 (PST) To: pyunyh@gmail.com In-reply-to: Your message of "Thu, 11 Nov 2010 13:04:36 PST." <20101111210436.GD17566@michelle.cdnetworks.com> Date: Thu, 11 Nov 2010 13:37:22 -0800 From: "Kevin Oberman" Message-Id: <20101111213722.55BC91CC12@ptavv.es.net> Cc: freebsd-stable@freebsd.org, Kirill Yelizarov , net@freebsd.org Subject: Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Nov 2010 21:37:23 -0000 > From: Pyun YongHyeon > Date: Thu, 11 Nov 2010 13:04:36 -0800 > > On Thu, Nov 11, 2010 at 08:10:57AM -0800, Kevin Oberman wrote: > > > Date: Wed, 10 Nov 2010 23:49:56 -0800 (PST) > > > From: Kirill Yelizarov > > > > > > > > > > > > --- On Thu, 11/11/10, Kevin Oberman wrote: > > > > > > > From: Kevin Oberman > > > > Subject: Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED] > > > > To: "Wilkinson, Alex" > > > > Cc: freebsd-stable@freebsd.org > > > > Date: Thursday, November 11, 2010, 8:26 AM > > > > > Date: Thu, 11 Nov 2010 13:01:26 > > > > +0800 > > > > > From: "Wilkinson, Alex" > > > > > Sender: owner-freebsd-stable@freebsd.org > > > > > > > > > > > > > > >? ???0n Wed, Nov 10, 2010 at > > > > 04:21:12AM -0800, Kirill Yelizarov wrote: > > > > > > > > > >? ???>All my em cards running > > > > 8.1 stable don't reply to icmp echo requests packets larger > > > > than 1472 bytes. > > > > >? ???> > > > > >? ???>On stable 7.2 the same > > > > hardware works as expected: > > > > >? ???># ping -s 1500 > > > > 192.168.64.99 > > > > >? ???>PING 192.168.64.99 > > > > (192.168.64.99): 1500 data bytes > > > > >? ???>1508 bytes from > > > > 192.168.64.99: icmp_seq=0 ttl=63 time=1.249 ms > > > > >? ???>1508 bytes from > > > > 192.168.64.99: icmp_seq=1 ttl=63 time=1.158 ms > > > > >? ???> > > > > >? ???>Here is the dump on em > > > > interface > > > > >? ???>15:06:31.452043 IP > > > > 192.168.66.65 > *****: ICMP echo request, id 28729, seq > > > > 5, length 1480 > > > > >? ???>15:06:31.452047 IP > > > > 192.168.66.65 > ****: icmp > > > > >? ???>15:06:31.452069 IP **** > > > > > 192.168.66.65: ICMP echo reply, id 28729, seq 5, length > > > > 1480 > > > > >? ???>15:06:31.452071 IP *** > > > > > 192.168.66.65: icmp > > > > >? ???> > > > > >? ???>Same ping from same source > > > > (it's a 8.1 stable with fxp interface) to em card running > > > > 8.1 stable > > > > >? ???>#pciconf -lv > > > > >? > > > > ???>em0@pci0:3:4:0:??? > > > > class=0x020000 card=0x10798086 chip=0x10798086 rev=0x03 > > > > hdr=0x00 > > > > >? ???>? ? vendor? > > > > ???= 'Intel Corporation' > > > > >? ???>? ? device? > > > > ???= 'Dual Port Gigabit Ethernet Controller > > > > (82546EB)' > > > > >? ???>? ? class? > > > > ? ? = network > > > > >? ???>? ? > > > > subclass???= ethernet > > > > >? ???> > > > > >? ???># ping -s 1472 > > > > 192.168.64.200 > > > > >? ???>PING 192.168.64.200 > > > > (192.168.64.200): 1472 data bytes > > > > >? ???>1480 bytes from > > > > 192.168.64.200: icmp_seq=0 ttl=63 time=0.848 ms > > > > >? ???>^C > > > > >? ???> > > > > >? ???># ping -s 1473 > > > > 192.168.64.200 > > > > >? ???>PING 192.168.64.200 > > > > (192.168.64.200): 1473 data bytes > > > > >? ???>^C > > > > >? ???>--- 192.168.64.200 ping > > > > statistics --- > > > > >? ???>4 packets transmitted, 0 > > > > packets received, 100.0% packet loss > > > > > > > > > > works fine for me: > > > > > > > > > > FreeBSD 8.1-STABLE #0 r213395 > > > > > > > > > > em0@pci0:0:25:0:class=0x020000 card=0x3035103c > > > > chip=0x10de8086 rev=0x02 hdr=0x00 > > > > >? ???vendor? > > > > ???= 'Intel Corporation' > > > > >? ???device? > > > > ???= 'Intel Gigabit network connection > > > > (82567LM-3 )' > > > > >? ???class? ? ? = > > > > network > > > > >? ???subclass???= > > > > ethernet > > > > > > > > > > #ping -s 1473 host > > > > > PING host(192.168.1.1): 1473 data bytes > > > > > 1481 bytes from 192.168.1.1: icmp_seq=0 ttl=253 > > > > time=31.506 ms > > > > > 1481 bytes from 192.168.1.1: icmp_seq=1 ttl=253 > > > > time=31.493 ms > > > > > 1481 bytes from 192.168.1.1: icmp_seq=2 ttl=253 > > > > time=31.550 ms > > > > > ^C > > > > > > > > The reason the '-s 1500' worked was that the packets were > > > > fragmented. If > > > > I add the '-D' option, '-s 1473' fails on v7 and v8. Are > > > > the V8 systems > > > > where you see if failing without the '-D' on the same > > > > network segment? > > > > If not, it is likely that an intervening device is refusing > > > > to fragment > > > > the packet. (Some routers deliberately don't fragment ICMP > > > > Echos Request > > > > packets.) > > > > > > If i set -D -s 1473 sender side refuses to ping and that is > > > correct. All mentioned above machines are behind the same router and > > > switch. Same hardware running v7 is working while v8 is not. And i > > > never saw such problems before. Also correct me if i'm wrong but the > > > dump shows that the packet arrived. I'll try driver from head and will > > > post here results. > > > > I did a bit more looking at this today and I see that something bogus is > > going on and it MAY be the em driver. > > > > I tried 1473 data byte pings without the DF flag. I then captured the > > packets on both ends (where the sending system has a bge (Broadcom GE) > > and the responding end has an em (Intel) card. > > > > What I saw was the fragmented IP packets all being received by the > > system with the em interface and an ICMP Echo Reply being sent back, > > again fragmented. I saw the reply on both ends, so both interfaces were > > able to fragment an over-sized packet, transmit the two pieces, and > > receive the two pieces. The em device could re-assemble them properly, > > but the bge device does not seem to re-assemble them correctly or else > > has a problem with ICMP packets bigger then MTU size. > > > > When I send from the em system, I see the packets and fragments all > > arrive in good form, but the system never sends out a reply. Since this > > is a kernel function, it may be a driver, but I suspect that it is in > > the IP stack since I am seeing the problem with a Broadcom card and I > > see the data all arriving. > > > > Most ethernet controllers including bge(4) have a function to > specify how much RX buffer space would be allocated to receive a > frame. When controller receive a frame that has larger size than > the size specified in RX buffer space, it would drop the frame. > Because the oversized frame was silently dropped in driver layer > upper stack has no chance to reply back ICMP responses with > fragmentation needed bit for frames that set don't fragment bit. > This is where correct MTU configuration play an important role in > driver layer. If you want to handle oversized frame you also have > to set correct MTU of interface. However all controllers should be > able to receive standard MTU sized frame including VLAN tag so no > special configuration is needed when you handle standard MTU sized > frames. Some old controllers can't handle VLAN oversized frame such > that you would have no way to send or receive them. > > em(4) controllers have different receiving logic where it allows > chaining multiple oversized frames into a single frame. So up to > certain point, which depends on the size of jumbo frame controller > supports, em(4) can receive these oversized frames regardless of > MTU configuration with the help of driver. The chaining is done in > driver layer and that would add additional overhead(chaining + > multiple mbuf allocation) but it has its own advantages. > > I was not able to to reproduce the issue with em(4)/bge(4) on > CURRENT and these drivers worked as expected. I don't have any systems running CURRENT at the moment, so I can't check it out. I hope it is fixed there, but it needs to be fixed in STABLE. Not fragmenting packets that will not fit in a standard frame is a very serious issues as, when the frame is dropped, the source re-transmits the same over-sized frame. Of course, this should not happen if the interface is set to an MTU of 1500 as the higher layers should never pass a block of data larger than 1480 bytes to the IP layer. That's the only reason this had not already been noticed. -- 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 Thu Nov 11 21:49:51 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 533611065670; Thu, 11 Nov 2010 21:49:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy.sentex.ca (unknown [IPv6:2607:f3e0:0:3::6502:9a]) by mx1.freebsd.org (Postfix) with ESMTP id 1F0418FC13; Thu, 11 Nov 2010 21:49:51 +0000 (UTC) Received: from freebsd-legacy.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy.sentex.ca (8.14.4/8.14.4) with ESMTP id oABGoEeu061950; Thu, 11 Nov 2010 16:50:14 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy.sentex.ca (8.14.4/8.14.4/Submit) id oABGoEEQ061946; Thu, 11 Nov 2010 16:50:14 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 11 Nov 2010 16:50:14 GMT Message-Id: <201011111650.oABGoEEQ061946@freebsd-legacy.sentex.ca> X-Authentication-Warning: freebsd-legacy.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_7_1 tinderbox] failure on i386/pc98 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 21:49:51 -0000 TB --- 2010-11-11 16:11:14 - tinderbox 2.6 running on freebsd-legacy.sentex.ca TB --- 2010-11-11 16:11:14 - starting RELENG_7_1 tinderbox run for i386/pc98 TB --- 2010-11-11 16:11:14 - mkdir /usr/home/tinderbox/RELENG_7_1/i386/pc98 TB --- 2010-11-11 16:11:14 - cleaning the object tree TB --- 2010-11-11 16:11:14 - cvsupping the source tree TB --- 2010-11-11 16:11:14 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca -s /usr/home/tinderbox/RELENG_7_1/i386/pc98/supfile TB --- 2010-11-11 16:14:28 - building world TB --- 2010-11-11 16:14:28 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-11 16:14:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-11 16:14:28 - TARGET=pc98 TB --- 2010-11-11 16:14:28 - TARGET_ARCH=i386 TB --- 2010-11-11 16:14:28 - TZ=UTC TB --- 2010-11-11 16:14:28 - __MAKE_CONF=/dev/null TB --- 2010-11-11 16:14:28 - cd /src TB --- 2010-11-11 16:14:28 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 11 16:14:29 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies [...] ===> gnu/usr.bin/cc (depend) ===> gnu/usr.bin/cc/cc_tools (depend) cc -O2 -fno-strict-aliasing -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/obj/pc98/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -c /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/gengtype.c cc -O2 -fno-strict-aliasing -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/obj/pc98/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -c gengtype-yacc+%DIKED.c cc -O2 -fno-strict-aliasing -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/obj/pc98/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -c gengtype-lex.c cc -O2 -fno-strict-aliasing -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/obj/pc98/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -c /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/errors.c cc -O2 -fno-strict-aliasing -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/obj/pc98/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -o gengtype gengtype.o gengtype-yacc+%DIKED.o gengtype-lex.o errors.o libiberty.a libiberty.a: could not read symbols: File format not recognized *** Error code 1 Stop in /src/gnu/usr.bin/cc/cc_tools. *** Error code 1 Stop in /src/gnu/usr.bin/cc. *** Error code 1 Stop in /src/gnu/usr.bin. *** Error code 1 Stop in /src/gnu. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-11 16:50:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-11 16:50:14 - ERROR: failed to build world TB --- 2010-11-11 16:50:14 - 1702.50 user 287.94 system 2340.17 real http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7_1-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Fri Nov 12 00:40: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 97F72106566B for ; Fri, 12 Nov 2010 00:40:58 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id DB7E38FC17 for ; Fri, 12 Nov 2010 00:40:57 +0000 (UTC) Received: by bwz2 with SMTP id 2so2537539bwz.13 for ; Thu, 11 Nov 2010 16:40:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:x-enigmail-version:content-type :content-transfer-encoding; bh=yPK3bcEHvQsrRojmaSK6JZf2r/KKBjxl35yVvM7S2nY=; b=KVhlnOOVNGRf2AdfMQ0HTyXLkiP/6YUWKsygWr9l5KgjbX6+dIm/a2b/lKHpcB9ktd gqoQiH8ExWnYP/go0v0UCtPnh8EzutUveM21YEW3S6HuYwtEIs3GPKO4ajth15KKCKpr 8N7qBIVqGgDiyyy34nttG5D/B5s1092vZYkwc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; b=YmvanjxBvK9K/tW1h5k06Odrl0Oip4Nt4Pv3vVHPq9R7vwTiqzUUA1kOaAD/OtuqjH tlo7czn9lXCdgnEN8aMfH0ojtaQ+UFuqgIqjxCkgSZ2m69ChD7dFY3iFCgDcVAyrur7t Za37bbsKgBPRCdGp37+S4sQ4hmFUj5XJlmMr8= Received: by 10.204.69.73 with SMTP id y9mr2071234bki.76.1289522455917; Thu, 11 Nov 2010 16:40:55 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id p34sm1240689bkf.3.2010.11.11.16.40.54 (version=SSLv3 cipher=RC4-MD5); Thu, 11 Nov 2010 16:40:55 -0800 (PST) Sender: Alexander Motin Message-ID: <4CDC8CFC.8040402@FreeBSD.org> Date: Fri, 12 Nov 2010 02:40:28 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: FreeBSD Stable , freebsd-mobile@freebsd.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Subject: New event timers for 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, 12 Nov 2010 00:40:58 -0000 Hi. I've created a patch, merging all kernel event timers related stuff from HEAD to 8-STABLE. The only thing I have skipped at this moment was mips architecture, because of too big code difference there between HEAD and 8-STABLE. Patch appeared to be quite large and includes more then 60 SVN revisions from HEAD. I hope I haven't missed anything important. I would like to ask interested people to test it. Patched code successfully builds on all platforms and successfully runs on my amd64 test machine. In HEAD code seems to be working enough stable, There only two known open issues at the moment: - kernel freeze on XEN HVM when using LAPIC timer in one-shot mode -- can be workarounded by switching to periodic mode or other timer. - if HPET interrupt shared with other device, system load average may lie (report +1 value) -- not a timer problem and not fatal. Please report me if you find anything else. Latest patch can be found here: http://people.freebsd.org/~mav/timers_merge/timers_merge-20101111.patch Merge instructions (list of revisions, if somebody want to redo it): http://people.freebsd.org/~mav/timers_merge/guide-20101111 After patching you need just rebuild/reinstall the kernel. I haven't merged related manual pages yet, so, if needed, consult with man pages from HEAD: eventtimers(7), attimer(4), atrtc(4), hpet(4). -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Fri Nov 12 03:30: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 C65591065693 for ; Fri, 12 Nov 2010 03:30:12 +0000 (UTC) (envelope-from wilkinsa@dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id 6967B8FC14 for ; Fri, 12 Nov 2010 03:30:12 +0000 (UTC) Received: from ednmsw520.dsto.defence.gov.au (ednmsw520.dsto.defence.gov.au [131.185.68.60]) by digger1.defence.gov.au (DSTO/DSTO) with ESMTP id oAC3N4CZ007165 for ; Fri, 12 Nov 2010 13:53:04 +1030 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw520.dsto.defence.gov.au (Clearswift SMTPRS 5.4.0) with ESMTP id for ; Fri, 12 Nov 2010 14:00:10 +1030 Received: from stlex511.dsto.defence.gov.au ([203.6.60.49]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Nov 2010 14:00:10 +1030 Received: from stlux550.dsto.defence.gov.au ([203.6.60.61]) by stlex511.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.4675); Fri, 12 Nov 2010 11:30:09 +0800 Received: from stlux550.dsto.defence.gov.au (localhost [127.0.0.1]) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3) with ESMTP id oAC3U9hx047424 for ; Fri, 12 Nov 2010 11:30:09 +0800 (WST) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3/Submit) id oAC3U8Cm047423 for freebsd-stable@freebsd.org; Fri, 12 Nov 2010 11:30:09 +0800 (WST) (envelope-from wilkinsa) Date: Fri, 12 Nov 2010 11:30:08 +0800 From: "Wilkinson, Alex" To: freebsd-stable@freebsd.org Message-ID: <20101112033008.GA47411@stlux503.dsto.defence.gov.au> Mail-Followup-To: freebsd-stable@freebsd.org References: <4CDC8CFC.8040402@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <4CDC8CFC.8040402@FreeBSD.org> Organisation: Defence Science Technology Organisation X-Message-Flag: "Please Restore Line Breaks If Necessary" User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 12 Nov 2010 03:30:09.0784 (UTC) FILETIME=[E8919780:01CB8219] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-6.500.1024-17760.003 X-TM-AS-Result: No--15.978100-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: Re: New event timers for 8-STABLE [SEC=UNCLASSIFIED] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Nov 2010 03:30:12 -0000 0n Fri, Nov 12, 2010 at 02:40:28AM +0200, Alexander Motin wrote:=20 >I've created a patch, merging all kernel event timers related stuff fr= om >HEAD to 8-STABLE. The only thing I have skipped at this moment was mips >architecture, because of too big code difference there between HEAD and >8-STABLE. Patch appeared to be quite large and includes more then 60 S= VN >revisions from HEAD. I hope I haven't missed anything important. I wou= ld >like to ask interested people to test it. Patched code successfully >builds on all platforms and successfully runs on my amd64 test machine. > >In HEAD code seems to be working enough stable, There only two known >open issues at the moment: > - kernel freeze on XEN HVM when using LAPIC timer in one-shot mode -- >can be workarounded by switching to periodic mode or other timer. > - if HPET interrupt shared with other device, system load average may >lie (report +1 value) -- not a timer problem and not fatal. >Please report me if you find anything else. > >Latest patch can be found here: >http://people.freebsd.org/~mav/timers_merge/timers_merge-20101111.patch > >Merge instructions (list of revisions, if somebody want to redo it): >http://people.freebsd.org/~mav/timers_merge/guide-20101111 > >After patching you need just rebuild/reinstall the kernel. I haven't >merged related manual pages yet, so, if needed, consult with man pages >from HEAD: eventtimers(7), attimer(4), atrtc(4), hpet(4). patches apply cleanly but buildkernel fails: make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP=3D"cc -E" CC=3D"= cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -march=3Dnocon= a -std=3Dc99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototype= s -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-= pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/s= ys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -= I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib= /ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/gnu/fs/xfs/FreeBSD -I/usr/src/= sys/gnu/fs/xfs/FreeBSD/support -I/usr/src/sys/gnu/fs/xfs -I/usr/src/sys/con= trib/opensolaris/compat -I/usr/src/sys/dev/cxgb -D_KERNEL -DHAVE_KERNEL_OPT= ION_HEADERS -include opt_global.h -fno-common -finline-limit=3D8000 --param= inline-unit-growth=3D100 --param large-function-growth=3D1000 -fno-omit-f= rame-pointer -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D387 -mno-sse -mno-= sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector cc: /usr/src/sys/kern/kern_et.c: No such file or directory cc: /usr/src/sys/kern/kern_clocksource.c: No such file or directory /usr/src/sys/dev/acpica/acpi_hpet.c:46:24: error: sys/timeet.h: No such fil= e or directory /usr/src/sys/x86/x86/local_apic.c:52:24: error: sys/timeet.h: No such file = or directory /usr/src/sys/x86/isa/atrtc.c:45:24: error: sys/timeet.h: No such file or di= rectory /usr/src/sys/x86/isa/clock.c:60:24: error: sys/timeet.h: No such file or di= rectory mkdep: compile failed *** Error code 1 Stop in /usr/obj/usr/src/sys/MARGS. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. IMPORTANT: This email remains the property of the Department of Defence and= is subject to the jurisdiction of section 70 of the Crimes Act 1914. If yo= u have received this email in error, you are requested to contact the sende= r and delete the email. From owner-freebsd-stable@FreeBSD.ORG Fri Nov 12 03:53: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 451BB1065694 for ; Fri, 12 Nov 2010 03:53:18 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id CBA088FC19 for ; Fri, 12 Nov 2010 03:53:17 +0000 (UTC) Received: by fxm19 with SMTP id 19so1936916fxm.13 for ; Thu, 11 Nov 2010 19:53:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=XrOGwhXbTbxtAJ8WiD0oPT5ZwEK941X0K4mzGAzkriM=; b=OqUw4l7IVWLC1V4fw8WdeENOQAhVWxggfrOUUhwxBeCRS70sPteYkNSF4Ov4yonmfh CbpjhYGg5WOtvVMbQW5xUVTP6qKALhRPHaWli0snfAU8MqoEuIERCABS4hpJMqdXxYSU 6t9CjfX9cQI1H3/N15ixId+9RToDKQCJrAwBI= 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; b=oPI7WmfCFHrvN0gxyIDKfwVNuhcyxwlJZ2PndLzpBJE1ThaA7pnWbfm0l0JsDY/7S9 wXAGO38IQ6y2N4Vt9k1G3fZm2VR2lgPBaXKTKdhkpaOkFkjG5f4XSwJuMCRkcCQB2mY8 QUKVdmIdqCwgeA1PDwgZTEJx4C/XR8VR8Zy8o= MIME-Version: 1.0 Received: by 10.223.87.6 with SMTP id u6mr946189fal.6.1289533996672; Thu, 11 Nov 2010 19:53:16 -0800 (PST) Received: by 10.223.121.138 with HTTP; Thu, 11 Nov 2010 19:53:16 -0800 (PST) In-Reply-To: <20101112033008.GA47411@stlux503.dsto.defence.gov.au> References: <4CDC8CFC.8040402@FreeBSD.org> <20101112033008.GA47411@stlux503.dsto.defence.gov.au> Date: Thu, 11 Nov 2010 21:53:16 -0600 Message-ID: From: Adam Vande More To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: New event timers for 8-STABLE [SEC=UNCLASSIFIED] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Nov 2010 03:53:18 -0000 > > patches apply cleanly but buildkernel fails: > > Works here with fresh source, amd64 -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Fri Nov 12 04:43: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 BC724106564A for ; Fri, 12 Nov 2010 04:43:53 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 263E08FC12 for ; Fri, 12 Nov 2010 04:43:52 +0000 (UTC) Received: by wya21 with SMTP id 21so428045wya.13 for ; Thu, 11 Nov 2010 20:43:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=y8G/EoJ2u8nb7BJHEgptIWROSR5lfNRsaw3Edsq6ojI=; b=WhvFOjUU2D9LoXkQwIVZES6rPcMQyZcffZbOQbbTawO4jM/43NEqtjFmjoKmMufaT7 UBQ1AZjL1rGSjAEzSu3Zx8NkGG3UVr2lcB9W3QLs+Hb53mT7955d3cbvMIw1Nhz/x6b/ FXC9gfboVoCntrDRbQs82LRgJ4FpEtDchDuUw= 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=ny2JApwsorak8Z7wfnabGXchyXb7nQZwaWaQkCTVnj9fPxgimUtVDt1luXfbN2T3Xq 3Rv11IFusuxsXztuRHWcMgWFpajD+vhs5TtJdFsRAT2o0DTCOB/1e7YEDyvC+QYhGgZx BfvF/8hB3bhZBdttBSSLKQsEQV5C0qMfjUI4k= MIME-Version: 1.0 Received: by 10.216.154.131 with SMTP id h3mr3114772wek.74.1289536582420; Thu, 11 Nov 2010 20:36:22 -0800 (PST) Received: by 10.216.12.80 with HTTP; Thu, 11 Nov 2010 20:36:22 -0800 (PST) In-Reply-To: <4CDC8CFC.8040402@FreeBSD.org> References: <4CDC8CFC.8040402@FreeBSD.org> Date: Thu, 11 Nov 2010 22:36:22 -0600 Message-ID: From: Brandon Gooch To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Stable , freebsd-mobile@freebsd.org Subject: Re: New event timers for 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, 12 Nov 2010 04:43:53 -0000 2010/11/11 Alexander Motin : > Hi. > > I've created a patch, merging all kernel event timers related stuff from > HEAD to 8-STABLE. The only thing I have skipped at this moment was mips > architecture, because of too big code difference there between HEAD and > 8-STABLE. Patch appeared to be quite large and includes more then 60 SVN > revisions from HEAD. I hope I haven't missed anything important. I would > like to ask interested people to test it. Patched code successfully > builds on all platforms and successfully runs on my amd64 test machine. > > In HEAD code seems to be working enough stable, There only two known > open issues at the moment: > =A0- kernel freeze on XEN HVM when using LAPIC timer in one-shot mode -- > can be workarounded by switching to periodic mode or other timer. > =A0- if HPET interrupt shared with other device, system load average may > lie (report +1 value) -- not a timer problem and not fatal. > Please report me if you find anything else. > > Latest patch can be found here: > http://people.freebsd.org/~mav/timers_merge/timers_merge-20101111.patch > > Merge instructions (list of revisions, if somebody want to redo it): > http://people.freebsd.org/~mav/timers_merge/guide-20101111 > > After patching you need just rebuild/reinstall the kernel. I haven't > merged related manual pages yet, so, if needed, consult with man pages > from HEAD: eventtimers(7), attimer(4), atrtc(4), hpet(4). > Reporting successes! No noticeable anomalies yet, two 8-STABLE systems (behaving similarly to my 9-CURRENT system in regard to timer settings). I'll keep prodding away to see what I can break ;) Of course I'll report the pertinent bits if/when required... Good job Alexander! -Brandon From owner-freebsd-stable@FreeBSD.ORG Fri Nov 12 04:52:32 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 B46431065672 for ; Fri, 12 Nov 2010 04:52:32 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 477F58FC0A for ; Fri, 12 Nov 2010 04:52:31 +0000 (UTC) Received: by wya21 with SMTP id 21so432855wya.13 for ; Thu, 11 Nov 2010 20:52:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=KqSsrTaxop98qjJLqNRLrGfbWGpjCldpPEig49+MTOg=; b=jPeVevhOUKIt1ZFv06ZFQwthg1wIkOGBBQsPqoGOF3+pM6FgqB8FAHomaeG2fsoRbS 52iVlPZyBz/fGiTBWZCSYOuJhlF1KRd7ywLgFgs18X1aB0oSXz7tZzU+EFnpjvyqAudW 0mPflr2Vc2V9xfcHfsb92iHHGS4u6yAKX0x9o= 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=YYJ1XE0HN45MzFsSSsr6/I6mpXbgIzOlYuPy5ympIVyjkIhMGKoIHqrUDaVIW6X20p 3HRKvT7ec30EMq01XRoKrpbDm8rZo9YliQpNUEVnfDXP5pmfCvFKXsE+i9Ej8xxPwChd SRkWdQl+/f1NEBHlNwX+fVPXHLwTF/C7erUcU= MIME-Version: 1.0 Received: by 10.216.171.75 with SMTP id q53mr1462651wel.74.1289536100889; Thu, 11 Nov 2010 20:28:20 -0800 (PST) Received: by 10.216.12.80 with HTTP; Thu, 11 Nov 2010 20:28:20 -0800 (PST) In-Reply-To: <20101112033008.GA47411@stlux503.dsto.defence.gov.au> References: <4CDC8CFC.8040402@FreeBSD.org> <20101112033008.GA47411@stlux503.dsto.defence.gov.au> Date: Thu, 11 Nov 2010 22:28:20 -0600 Message-ID: From: Brandon Gooch To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: New event timers for 8-STABLE [SEC=UNCLASSIFIED] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Nov 2010 04:52:32 -0000 On Thu, Nov 11, 2010 at 9:30 PM, Wilkinson, Alex wrote: > > =A0 =A00n Fri, Nov 12, 2010 at 02:40:28AM +0200, Alexander Motin wrote: > > =A0 =A0>I've created a patch, merging all kernel event timers related stu= ff from > =A0 =A0>HEAD to 8-STABLE. The only thing I have skipped at this moment wa= s mips > =A0 =A0>architecture, because of too big code difference there between HE= AD and > =A0 =A0>8-STABLE. Patch appeared to be quite large and includes more then= 60 SVN > =A0 =A0>revisions from HEAD. I hope I haven't missed anything important. = I would > =A0 =A0>like to ask interested people to test it. Patched code successful= ly > =A0 =A0>builds on all platforms and successfully runs on my amd64 test ma= chine. > =A0 =A0> > =A0 =A0>In HEAD code seems to be working enough stable, There only two kn= own > =A0 =A0>open issues at the moment: > =A0 =A0> - kernel freeze on XEN HVM when using LAPIC timer in one-shot mo= de -- > =A0 =A0>can be workarounded by switching to periodic mode or other timer. > =A0 =A0> - if HPET interrupt shared with other device, system load averag= e may > =A0 =A0>lie (report +1 value) -- not a timer problem and not fatal. > =A0 =A0>Please report me if you find anything else. > =A0 =A0> > =A0 =A0>Latest patch can be found here: > =A0 =A0>http://people.freebsd.org/~mav/timers_merge/timers_merge-20101111= .patch > =A0 =A0> > =A0 =A0>Merge instructions (list of revisions, if somebody want to redo i= t): > =A0 =A0>http://people.freebsd.org/~mav/timers_merge/guide-20101111 > =A0 =A0> > =A0 =A0>After patching you need just rebuild/reinstall the kernel. I have= n't > =A0 =A0>merged related manual pages yet, so, if needed, consult with man = pages > =A0 =A0>from HEAD: eventtimers(7), attimer(4), atrtc(4), hpet(4). > > patches apply cleanly but buildkernel fails: > > make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | =A0MKDEP_CPP=3D"cc -E" CC= =3D"cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -march=3Dn= ocona -std=3Dc99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-proto= types =A0-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual =A0-Wund= ef -Wno-pointer-sign -fformat-extensions -nostdinc =A0-I. -I/usr/src/sys -I= /usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/co= ntrib/pf -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/s= ys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/gnu/fs/xfs/FreeBSD -= I/usr/src/sys/gnu/fs/xfs/FreeBSD/support -I/usr/src/sys/gnu/fs/xfs -I/usr/s= rc/sys/contrib/opensolaris/compat -I/usr/src/sys/dev/cxgb -D_KERNEL -DHAVE_= KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=3D80= 00 --param inline-unit-growth=3D100 --param large-function-growth=3D1000 = =A0-fno-omit-frame-pointer -mcmodel=3Dkernel -mno-red-zone =A0-mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow =A0-msoft-float -fno-asy= nchronous-unwind-tables -ffreestanding -fstack-protector > cc: /usr/src/sys/kern/kern_et.c: No such file or directory > cc: /usr/src/sys/kern/kern_clocksource.c: No such file or directory > /usr/src/sys/dev/acpica/acpi_hpet.c:46:24: error: sys/timeet.h: No such f= ile or directory > /usr/src/sys/x86/x86/local_apic.c:52:24: error: sys/timeet.h: No such fil= e or directory > /usr/src/sys/x86/isa/atrtc.c:45:24: error: sys/timeet.h: No such file or = directory > /usr/src/sys/x86/isa/clock.c:60:24: error: sys/timeet.h: No such file or = directory > mkdep: compile failed > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/MARGS. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > Revert the patch (patch -R) and reapply the patch with -p0: [/usr/src]# patch -p0 < /path/to/file.patch ...and try it again :) -Brandon From owner-freebsd-stable@FreeBSD.ORG Fri Nov 12 10:48:33 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 E6C19106566B for ; Fri, 12 Nov 2010 10:48:33 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norman-vivat.ru [89.250.210.68]) by mx1.freebsd.org (Postfix) with ESMTP id 3AC5B8FC1C for ; Fri, 12 Nov 2010 10:48:32 +0000 (UTC) Received: from bsdrookie.norma.com. (bsdrookie.hq.norma.perm.ru [192.168.7.246]) by elf.hq.norma.perm.ru (8.14.3/8.14.3) with ESMTP id oACAGugH026668 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 12 Nov 2010 15:17:04 +0500 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <4CDD1418.8020107@norma.perm.ru> Date: Fri, 12 Nov 2010 15:16:56 +0500 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100917 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (elf.hq.norma.perm.ru [192.168.3.10]); Fri, 12 Nov 2010 15:17:04 +0500 (YEKT) X-Callback: Sender verified by milter-callback 1.5.10 at elf.hq.norma.perm.ru. X-Callback-Status: relay [192.168.7.246] found in white list. X-Callback-Envelope-From: emz@norma.perm.ru X-Spam-Status: No hits=-102.9 bayes=0.0000 testhits ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on elf.hq.norma.perm.ru Subject: krb5 and clock skew X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Nov 2010 10:48:34 -0000 Hi. Panic on em(4) in vlan environment (after upgrade from 7.2-RELEASE to 8.1-RELEASE) forced me to use 8.1-STABLE (built 2 days ago) on one of my productions. Almost all is fine now except of two things, which I decided to split in two letters. This one is about my kerberos setup. I have a windows 2008 server which acts as AD domain controller, thus implying KDC. I have a bunch of various FreeBSD 7.x/8.0 around, and I have this particular FreeBSD 8.1-STABLE, lets name it 'A'. 'A' is a primary ntp server, which is a preferred and only peer for many of others FreeBSD servers around. 'A' is synced to some WAN hosts of 1st stratum. All of 'others' FreeBSD are synced to 'A'. KDC is also synced to 'A'. 'A' and 'others' FreeBSD have Kerberos V deployed, with identical configs that point to KDC (win 2008). All of the machines have user 'emz', which for FreeBSDs is local user and for KDC is domain user. The problem is, that 'others' FreeBSD can request tickets for emz with kinit, but when I'm issuing 'kinit' command on 'A' I'm always getting 'Clock skew too great'. As I said, the time is synced between KDC and 'A'. I've looked into win 2008 event logs, it says 'reason 0x25', which means 'Clock skew too great', I've looked into tcpdump just to see that packets coming from KDC contain the same error. I've installed heimdal 1.4 from ports, used it's /usr/local/bin/kinit but situation was the same. However this setup was working on this server for years, even on 8.1 (during the moments between panics :)) and it was broken after the upgrade to 8.1-STABLE. How can I solve this ? Thanks. Eugene. From owner-freebsd-stable@FreeBSD.ORG Fri Nov 12 11:56: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 A9018106566B for ; Fri, 12 Nov 2010 11:56:05 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norman-vivat.ru [89.250.210.68]) by mx1.freebsd.org (Postfix) with ESMTP id 167208FC08 for ; Fri, 12 Nov 2010 11:56:04 +0000 (UTC) Received: from bsdrookie.norma.com. (bsdrookie.hq.norma.perm.ru [192.168.7.246]) by elf.hq.norma.perm.ru (8.14.3/8.14.3) with ESMTP id oACBtut9033571 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 12 Nov 2010 16:56:00 +0500 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <4CDD2B4C.5090106@norma.perm.ru> Date: Fri, 12 Nov 2010 16:55:56 +0500 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100917 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (elf.hq.norma.perm.ru [192.168.3.10]); Fri, 12 Nov 2010 16:56:00 +0500 (YEKT) X-Callback: Sender verified by milter-callback 1.5.10 at elf.hq.norma.perm.ru. X-Callback-Status: relay [192.168.7.246] found in white list. X-Callback-Envelope-From: emz@norma.perm.ru X-Spam-Status: No hits=-102.9 bayes=0.0000 testhits ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on elf.hq.norma.perm.ru Subject: netgraph and interface nodes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Nov 2010 11:56:05 -0000 Hi. I'm using 8.1-STABLE on one of my production servers. I wrote about krb5 problem some time ago. Second trouble is netgraph-related. I'm using dot1q on an em(4) card. It's loaded as a module atm (however earlier it was in kernel). I have ng_ether/ng_iface in kernel, if_vlan loaded as a module, but I cannot see vlan interface nodes in ngctl. Is this known problem related to a driver loaded a s a module ? Or maby it can be helped some other way ? Thanks. Eugene. From owner-freebsd-stable@FreeBSD.ORG Fri Nov 12 11:58: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 09B201065670; Fri, 12 Nov 2010 11:58:01 +0000 (UTC) (envelope-from alexz@visp.ru) Received: from mail.visp.ru (srv1.visp.ru [91.215.204.2]) by mx1.freebsd.org (Postfix) with ESMTP id AF5828FC18; Fri, 12 Nov 2010 11:58:00 +0000 (UTC) Received: from 91-215-205-255.static.visp.ru ([91.215.205.255] helo=zagrebin) by mail.visp.ru with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PGsGU-0004rl-Dw; Fri, 12 Nov 2010 14:57:58 +0300 From: "Alexander Zagrebin" To: , Date: Fri, 12 Nov 2010 14:57:58 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: AcuCYNju4THmbqyLQdC782dwcgeoxA== Cc: Subject: 8.1-STABLE: problem with unmounting ZFS snapshots X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Nov 2010 11:58:01 -0000 I have found that there is an issue with unmounting ZFS snapshots: the /sbin/umount "hangs" after unmounting. The test system is i386, but I can reproduce this issue on amd64 too. # uname -a FreeBSD alpha.vosz.local 8.1-STABLE FreeBSD 8.1-STABLE #0: Tue Oct 19 18:47:05 MSD 2010 root@alpha.vosz.local:/usr/obj/usr/src/sys/GENERIC i386 How to try to repeat: # zfs snapshot pool/var@test # zfs list -t all -r pool/var NAME USED AVAIL REFER MOUNTPOINT pool/var 4,86M 2,99G 4,86M /var pool/var@test 0 - 4,86M - # mount -t zfs pool/var@test /mnt # mount ... pool/var@test on /mnt (zfs, local, noatime, read-only) # umount /mnt At this point umount hangs and it's impossible to kill it even with the `kill -9`. >From the working console I can see that: 1. snapshot is unmounted successfully # mount pool/root on / (zfs, local) devfs on /dev (devfs, local, multilabel) pool/home on /home (zfs, local) pool/tmp on /tmp (zfs, local) pool/usr on /usr (zfs, local) pool/usr/src on /usr/src (zfs, local) pool/var on /var (zfs, local) 2. the umount is waiting for disk #ps | egrep 'PID|umount' PID TT STAT TIME COMMAND 958 0 D+ 0:00,04 umount /mnt # procstat -t 958 PID TID COMM TDNAME CPU PRI STATE WCHAN 958 100731 umount - 3 133 sleep mntref Can anybody confirm this issue? Any suggestions? -- Alexander Zagrebin From owner-freebsd-stable@FreeBSD.ORG Fri Nov 12 12:13: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 57B1C1065694; Fri, 12 Nov 2010 12:13:24 +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 577A08FC31; Fri, 12 Nov 2010 12:13:23 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA28407; Fri, 12 Nov 2010 14:13:20 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CDD2F5F.2000902@freebsd.org> Date: Fri, 12 Nov 2010 14:13:19 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Alexander Zagrebin References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.1-STABLE: problem with unmounting ZFS snapshots X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Nov 2010 12:13:24 -0000 on 12/11/2010 13:57 Alexander Zagrebin said the following: > 2. the umount is waiting for disk > #ps | egrep 'PID|umount' > PID TT STAT TIME COMMAND > 958 0 D+ 0:00,04 umount /mnt > # procstat -t 958 > PID TID COMM TDNAME CPU PRI STATE WCHAN > 958 100731 umount - 3 133 sleep mntref procstat -kk > Can anybody confirm this issue? > Any suggestions? > ktrace-ing umount could also be useful. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Nov 12 12:19:31 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 9933F106566B for ; Fri, 12 Nov 2010 12:19:31 +0000 (UTC) (envelope-from zec@icir.org) Received: from munja.zvne.fer.hr (munja.zvne.fer.hr [161.53.66.248]) by mx1.freebsd.org (Postfix) with ESMTP id 2AD5D8FC2B for ; Fri, 12 Nov 2010 12:19:30 +0000 (UTC) Received: from sluga.fer.hr ([161.53.66.244]) by munja.zvne.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 12 Nov 2010 13:07:25 +0100 Received: from localhost ([161.53.19.8]) by sluga.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 12 Nov 2010 13:07:25 +0100 From: Marko Zec To: freebsd-stable@freebsd.org Date: Fri, 12 Nov 2010 13:07:22 +0100 User-Agent: KMail/1.9.10 References: <4CDD2B4C.5090106@norma.perm.ru> In-Reply-To: <4CDD2B4C.5090106@norma.perm.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201011121307.23133.zec@icir.org> X-OriginalArrivalTime: 12 Nov 2010 12:07:25.0400 (UTC) FILETIME=[2B3CC580:01CB8262] Cc: "Eugene M. Zheganin" Subject: Re: netgraph and interface nodes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Nov 2010 12:19:31 -0000 On Friday 12 November 2010 12:55:56 Eugene M. Zheganin wrote: > Hi. > > I'm using 8.1-STABLE on one of my production servers. I wrote about krb5 > problem some time ago. > Second trouble is netgraph-related. > > I'm using dot1q on an em(4) card. > It's loaded as a module atm (however earlier it was in kernel). > > I have ng_ether/ng_iface in kernel, if_vlan loaded as a module, but I > cannot see vlan interface nodes in ngctl. > > Is this known problem related to a driver loaded a s a module ? > Or maby it can be helped some other way ? That kind of setup works fine here on stable/8: tpx32# uname -a FreeBSD tpx32.icir.org 8.1-STABLE FreeBSD 8.1-STABLE #3: Tue Nov 9 15:15:54 CET 2010 tpx32# ngctl l There are 3 total nodes: Name: em0 Type: ether ID: 00000001 Num hooks: 0 Name: wlan0 Type: ether ID: 00000008 Num hooks: 0 Name: ngctl7968 Type: socket ID: 00000009 Num hooks: 0 tpx32# ifconfig vlan0 create tpx32# ifconfig vlan0 vlan 101 vlandev em0 tpx32# ngctl l There are 4 total nodes: Name: em0 Type: ether ID: 00000001 Num hooks: 0 Name: vlan0 Type: ether ID: 0000000a Num hooks: 0 Name: wlan0 Type: ether ID: 00000008 Num hooks: 0 Name: ngctl8033 Type: socket ID: 0000000b Num hooks: 0 tpx32# Marko From owner-freebsd-stable@FreeBSD.ORG Fri Nov 12 12:37:06 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 2868C106564A for ; Fri, 12 Nov 2010 12:37:06 +0000 (UTC) (envelope-from freebsd-stable@dino.sk) Received: from loki.netlab.sk (loki.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id B251D8FC08 for ; Fri, 12 Nov 2010 12:37:05 +0000 (UTC) Received: from door.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Fri, 12 Nov 2010 13:35:38 +0100 id 00033C18.4CDD349A.0000DC4C From: Milan Obuch To: freebsd-stable@freebsd.org Date: Fri, 12 Nov 2010 13:27:03 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.5.3; i386; ; ) References: <4CDD2B4C.5090106@norma.perm.ru> <201011121307.23133.zec@icir.org> In-Reply-To: <201011121307.23133.zec@icir.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011121327.04287.freebsd-stable@dino.sk> Subject: Re: netgraph and interface nodes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Nov 2010 12:37:06 -0000 On Friday 12 November 2010 13:07:22 Marko Zec wrote: > On Friday 12 November 2010 12:55:56 Eugene M. Zheganin wrote: > > Hi. > > > > I'm using 8.1-STABLE on one of my production servers. I wrote about krb5 > > problem some time ago. > > Second trouble is netgraph-related. > > > > I'm using dot1q on an em(4) card. > > It's loaded as a module atm (however earlier it was in kernel). > > > > I have ng_ether/ng_iface in kernel, if_vlan loaded as a module, but I > > cannot see vlan interface nodes in ngctl. > > > > Is this known problem related to a driver loaded a s a module ? > > Or maby it can be helped some other way ? > > That kind of setup works fine here on stable/8: > > tpx32# uname -a > FreeBSD tpx32.icir.org 8.1-STABLE FreeBSD 8.1-STABLE #3: Tue Nov 9 > 15:15:54 CET 2010 > tpx32# ngctl l > There are 3 total nodes: > Name: em0 Type: ether ID: 00000001 Num hooks: 0 > Name: wlan0 Type: ether ID: 00000008 Num hooks: 0 > Name: ngctl7968 Type: socket ID: 00000009 Num hooks: 0 > tpx32# ifconfig vlan0 create > tpx32# ifconfig vlan0 vlan 101 vlandev em0 > tpx32# ngctl l > There are 4 total nodes: > Name: em0 Type: ether ID: 00000001 Num hooks: 0 > Name: vlan0 Type: ether ID: 0000000a Num hooks: 0 > Name: wlan0 Type: ether ID: 00000008 Num hooks: 0 > Name: ngctl8033 Type: socket ID: 0000000b Num hooks: 0 > tpx32# > > Marko > Slightly related... how about em0.100 type nodes? # ngctl list There are 3 total nodes: Name: em0 Type: ether ID: 00000001 Num hooks: 0 Name: em1 Type: ether ID: 00000002 Num hooks: 0 Name: ngctl48803 Type: socket ID: 00000005 Num hooks: 0 door.dino.sk# ifconfig em0.100 create door.dino.sk# ngctl list There are 4 total nodes: Name: Type: ether ID: 00000006 Num hooks: 0 Name: em0 Type: ether ID: 00000001 Num hooks: 0 Name: em1 Type: ether ID: 00000002 Num hooks: 0 Name: ngctl49103 Type: socket ID: 00000007 Num hooks: 0 It looks like the dot in interface name is not handled gracefully here... Regards, Milan From owner-freebsd-stable@FreeBSD.ORG Fri Nov 12 13:22: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 60844106564A for ; Fri, 12 Nov 2010 13:22:21 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norman-vivat.ru [89.250.210.68]) by mx1.freebsd.org (Postfix) with ESMTP id DB60C8FC20 for ; Fri, 12 Nov 2010 13:22:19 +0000 (UTC) Received: from bsdrookie.norma.com. (bsdrookie.hq.norma.perm.ru [192.168.7.246]) by elf.hq.norma.perm.ru (8.14.3/8.14.3) with ESMTP id oACDMCZA046705 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 12 Nov 2010 18:22:13 +0500 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <4CDD3F84.9010901@norma.perm.ru> Date: Fri, 12 Nov 2010 18:22:12 +0500 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100917 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4CDD2B4C.5090106@norma.perm.ru> <201011121307.23133.zec@icir.org> <201011121327.04287.freebsd-stable@dino.sk> In-Reply-To: <201011121327.04287.freebsd-stable@dino.sk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (elf.hq.norma.perm.ru [192.168.3.10]); Fri, 12 Nov 2010 18:22:13 +0500 (YEKT) X-Callback: Sender verified by milter-callback 1.5.10 at elf.hq.norma.perm.ru. X-Callback-Status: relay [192.168.7.246] found in white list. X-Callback-Envelope-From: emz@norma.perm.ru X-Spam-Status: No hits=-102.9 bayes=0.0000 testhits ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on elf.hq.norma.perm.ru Subject: Re: netgraph and interface nodes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Nov 2010 13:22:21 -0000 Hi. On 12.11.2010 17:27, Milan Obuch wrote: > > Slightly related... how about em0.100 type nodes? > > # ngctl list > There are 3 total nodes: > Name: em0 Type: ether ID: 00000001 Num hooks: 0 > Name: em1 Type: ether ID: 00000002 Num hooks: 0 > Name: ngctl48803 Type: socket ID: 00000005 Num hooks: 0 > door.dino.sk# ifconfig em0.100 create > door.dino.sk# ngctl list > There are 4 total nodes: > Name: Type: ether ID: 00000006 Num hooks: 0 > Name: em0 Type: ether ID: 00000001 Num hooks: 0 > Name: em1 Type: ether ID: 00000002 Num hooks: 0 > Name: ngctl49103 Type: socket ID: 00000007 Num hooks: 0 > > It looks like the dot in interface name is not handled gracefully here... > Nothing: %kldstat Id Refs Address Size Name 1 57 0xc0400000 8c50f4 kernel 2 1 0xc0cc6000 4beb8 if_em.ko 4 1 0xc0d17000 2424 accf_http.ko 5 1 0xc0d1a000 bfe0 ipmi.ko 6 2 0xc0d26000 1bd0 smbus.ko 7 1 0xc0d28000 27cc ng_ipfw.ko 8 1 0xc6c38000 5000 if_vlan.ko 9 1 0xc6ec1000 5000 ng_netflow.ko 10 1 0xc71c0000 26000 linux.ko 11 1 0xc72a4000 4000 ng_mppc.ko 12 1 0xc72a8000 2000 rc4.ko 13 1 0xc77ca000 4000 ng_nat.ko 14 1 0xc7dbe000 5000 ng_l2tp.ko 15 1 0xc7e43000 5000 ng_ksocket.ko 16 1 0xc7eea000 3000 ng_tcpmss.ko 17 1 0xc9197000 3000 ng_eiface.ko 18 1 0xcbc81000 3000 ng_vlan.ko %ngctl list There are 14 total nodes: Name: Type: ksocket ID: 0000012f Num hooks: 1 Name: Type: l2tp ID: 0000012d Num hooks: 3 Name: Type: socket ID: 0000012c Num hooks: 1 Name: ng0 Type: iface ID: 00000133 Num hooks: 1 Name: ngctl54909 Type: socket ID: 0000013c Num hooks: 0 Name: mpd94408-stats Type: socket ID: 00000135 Num hooks: 0 Name: ipfw Type: ipfw ID: 00000001 Num hooks: 2 Name: mpd94408-cso Type: socket ID: 0000012a Num hooks: 0 Name: mpd94408-eso Type: socket ID: 0000012b Num hooks: 0 Name: nat Type: nat ID: 0000000a Num hooks: 2 Name: mpd94408-lso Type: socket ID: 00000129 Num hooks: 1 Name: mpd94408-B2-3-mss Type: tcpmss ID: 00000136 Num hooks: 2 Name: mpd94408-B2-3 Type: ppp ID: 00000134 Num hooks: 3 Name: mpd94408-L1-2-lt Type: tee ID: 00000130 Num hooks: 2 %ifconfig -l em0 em1 ipfw0 lo0 vlan1 vlan2 vlan3 vlan5 vlan6 vlan9 vlan10 vlan11 vlan12 vlan21 vlan104 vlan15 vlan818 ng0 Eugene. From owner-freebsd-stable@FreeBSD.ORG Fri Nov 12 13:31: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 EF93B106564A for ; Fri, 12 Nov 2010 13:31:28 +0000 (UTC) (envelope-from freebsd-stable@dino.sk) Received: from loki.netlab.sk (ns3.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id AF2D18FC12 for ; Fri, 12 Nov 2010 13:31:28 +0000 (UTC) Received: from door.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Fri, 12 Nov 2010 14:40:03 +0100 id 00033C04.4CDD43B3.0000DFB9 From: Milan Obuch To: freebsd-stable@freebsd.org Date: Fri, 12 Nov 2010 14:31:28 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.5.3; i386; ; ) References: <4CDD2B4C.5090106@norma.perm.ru> <201011121327.04287.freebsd-stable@dino.sk> <4CDD3F84.9010901@norma.perm.ru> In-Reply-To: <4CDD3F84.9010901@norma.perm.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011121431.29613.freebsd-stable@dino.sk> Subject: Re: netgraph and interface nodes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Nov 2010 13:31:29 -0000 On Friday 12 November 2010 14:22:12 Eugene M. Zheganin wrote: > Hi. > > On 12.11.2010 17:27, Milan Obuch wrote: > > Slightly related... how about em0.100 type nodes? > > > > # ngctl list > > > > There are 3 total nodes: > > Name: em0 Type: ether ID: 00000001 Num hooks: > > 0 Name: em1 Type: ether ID: 00000002 Num > > hooks: 0 Name: ngctl48803 Type: socket ID: 00000005 > > Num hooks: 0 > > > > door.dino.sk# ifconfig em0.100 create > > door.dino.sk# ngctl list > > > > There are 4 total nodes: > > Name: Type: ether ID: 00000006 Num hooks: > > 0 Name: em0 Type: ether ID: 00000001 Num > > hooks: 0 Name: em1 Type: ether ID: 00000002 > > Num hooks: 0 Name: ngctl49103 Type: socket ID: 00000007 > > Num hooks: 0 > > > > It looks like the dot in interface name is not handled gracefully here... > > Nothing: > > %kldstat > Id Refs Address Size Name > 1 57 0xc0400000 8c50f4 kernel > 2 1 0xc0cc6000 4beb8 if_em.ko > 4 1 0xc0d17000 2424 accf_http.ko > 5 1 0xc0d1a000 bfe0 ipmi.ko > 6 2 0xc0d26000 1bd0 smbus.ko > 7 1 0xc0d28000 27cc ng_ipfw.ko > 8 1 0xc6c38000 5000 if_vlan.ko > 9 1 0xc6ec1000 5000 ng_netflow.ko > 10 1 0xc71c0000 26000 linux.ko > 11 1 0xc72a4000 4000 ng_mppc.ko > 12 1 0xc72a8000 2000 rc4.ko > 13 1 0xc77ca000 4000 ng_nat.ko > 14 1 0xc7dbe000 5000 ng_l2tp.ko > 15 1 0xc7e43000 5000 ng_ksocket.ko > 16 1 0xc7eea000 3000 ng_tcpmss.ko > 17 1 0xc9197000 3000 ng_eiface.ko > 18 1 0xcbc81000 3000 ng_vlan.ko > %ngctl list > There are 14 total nodes: > Name: Type: ksocket ID: 0000012f Num hooks: 1 > Name: Type: l2tp ID: 0000012d Num hooks: 3 > Name: Type: socket ID: 0000012c Num hooks: 1 > Name: ng0 Type: iface ID: 00000133 Num hooks: 1 > Name: ngctl54909 Type: socket ID: 0000013c Num hooks: 0 > Name: mpd94408-stats Type: socket ID: 00000135 Num hooks: 0 > Name: ipfw Type: ipfw ID: 00000001 Num hooks: 2 > Name: mpd94408-cso Type: socket ID: 0000012a Num hooks: 0 > Name: mpd94408-eso Type: socket ID: 0000012b Num hooks: 0 > Name: nat Type: nat ID: 0000000a Num hooks: 2 > Name: mpd94408-lso Type: socket ID: 00000129 Num hooks: 1 > Name: mpd94408-B2-3-mss Type: tcpmss ID: 00000136 Num hooks: > 2 Name: mpd94408-B2-3 Type: ppp ID: 00000134 Num hooks: 3 > Name: mpd94408-L1-2-lt Type: tee ID: 00000130 Num hooks: 2 > %ifconfig -l > em0 em1 ipfw0 lo0 vlan1 vlan2 vlan3 vlan5 vlan6 vlan9 vlan10 vlan11 > vlan12 vlan21 vlan104 vlan15 vlan818 ng0 > > Eugene. > # kldstat Id Refs Address Size Name 1 45 0xc0400000 50005c kernel 2 1 0xc0901000 6434 vesa.ko 3 1 0xc0908000 5e4c if_vlan.ko 4 1 0xc090e000 4b690 if_em.ko 5 1 0xc095a000 4554 ng_ether.ko 6 3 0xc095f000 d944 netgraph.ko 7 1 0xc096d000 947c uhci.ko 8 3 0xc0977000 241e4 usb.ko 9 1 0xc099c000 b2a4 ehci.ko 10 1 0xc09a8000 4f8c ichsmb.ko 11 3 0xc09ad000 1be0 smbus.ko 12 1 0xc09af000 362c smb.ko 13 1 0xc09b3000 3d84 ichwd.ko 14 1 0xc45a5000 4000 if_gre.ko 15 1 0xc46d6000 2f000 pf.ko 16 1 0xc7721000 4000 ng_socket.ko I see no ng_ether module in your list, or did I somehow misinterpreted your query? Regards, Milan From owner-freebsd-stable@FreeBSD.ORG Fri Nov 12 14:00: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 3896F10656A8; Fri, 12 Nov 2010 14:00:24 +0000 (UTC) (envelope-from alexz@visp.ru) Received: from mail.visp.ru (srv1.visp.ru [91.215.204.2]) by mx1.freebsd.org (Postfix) with ESMTP id 2EF348FC15; Fri, 12 Nov 2010 14:00:14 +0000 (UTC) Received: from 91-215-205-255.static.visp.ru ([91.215.205.255] helo=zagrebin) by mail.visp.ru with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PGuAl-000Lo1-Nd; Fri, 12 Nov 2010 17:00:11 +0300 From: "Alexander Zagrebin" To: "'Andriy Gapon'" References: <4CDD2F5F.2000902@freebsd.org> Date: Fri, 12 Nov 2010 17:00:11 +0300 Keywords: freebsd-stable Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: AcuCYyqzfZYrwX5jRtKA2oGCQvAKogADjN1w In-Reply-To: <4CDD2F5F.2000902@freebsd.org> Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: RE: 8.1-STABLE: problem with unmounting ZFS snapshots X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Nov 2010 14:00:24 -0000 Thanks for your reply! > > 2. the umount is waiting for disk > > #ps | egrep 'PID|umount' > > PID TT STAT TIME COMMAND > > 958 0 D+ 0:00,04 umount /mnt > > # procstat -t 958 > > PID TID COMM TDNAME CPU PRI > STATE WCHAN > > 958 100731 umount - 3 133 > sleep mntref > > procstat -kk $ ps a | grep umount 86874 2- D 0:00,06 umount /mnt 90433 3 S+ 0:00,01 grep umount $ sudo procstat -kk 86874 PID TID COMM TDNAME KSTACK 86874 100731 umount - mi_switch+0x176 sleepq_wait+0x42 _sleep+0x317 vfs_mount_destroy+0x5a dounmount+0x4d4 unmount+0x38b syscall+0x1cf Xfast_syscall+0xe2 -- Alexander Zagrebin From owner-freebsd-stable@FreeBSD.ORG Fri Nov 12 14:27: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 6DDA9106566B; Fri, 12 Nov 2010 14:27:05 +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 562148FC18; Fri, 12 Nov 2010 14:27:03 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA00315; Fri, 12 Nov 2010 16:27:01 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CDD4EB4.40004@freebsd.org> Date: Fri, 12 Nov 2010 16:27:00 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Alexander Zagrebin References: <4CDD2F5F.2000902@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org, Martin Matuska Subject: Re: 8.1-STABLE: problem with unmounting ZFS snapshots X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Nov 2010 14:27:05 -0000 on 12/11/2010 16:00 Alexander Zagrebin said the following: > Thanks for your reply! > >>> 2. the umount is waiting for disk >>> #ps | egrep 'PID|umount' >>> PID TT STAT TIME COMMAND >>> 958 0 D+ 0:00,04 umount /mnt >>> # procstat -t 958 >>> PID TID COMM TDNAME CPU PRI >> STATE WCHAN >>> 958 100731 umount - 3 133 >> sleep mntref >> >> procstat -kk > > $ ps a | grep umount > 86874 2- D 0:00,06 umount /mnt > 90433 3 S+ 0:00,01 grep umount > > $ sudo procstat -kk 86874 > PID TID COMM TDNAME KSTACK > 86874 100731 umount - mi_switch+0x176 > sleepq_wait+0x42 _sleep+0x317 vfs_mount_destroy+0x5a dounmount+0x4d4 > unmount+0x38b syscall+0x1cf Xfast_syscall+0xe2 > Looks like possible mnt_ref leak. I think that something like that was fixed some not long time ago. Perhaps you either don't have the fix or there is another leak. What revision do you have? Perhaps Martin has an insight here. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Nov 12 15:35: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 729FE1065694 for ; Fri, 12 Nov 2010 15:35:24 +0000 (UTC) (envelope-from daryl@isletech.net) Received: from lagoon.isletech.net (lagoon.isletech.net [64.235.98.66]) by mx1.freebsd.org (Postfix) with ESMTP id 434ED8FC0A for ; Fri, 12 Nov 2010 15:35:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=isletech.net; s=isle; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=OsGR/1ez3XroVT0q9aDPNh/BPsoVjtrPfJuhDpicItg=; b=RmMrqwLxxM/S+nUhp73ArI2h4qpt1wKhve5xEn5ywdAGeGrH4bGZSsLo6jB4Kv04hFLLKIAOl4PsPez7E7lxdg==; Received: from coin1.ocl.net ([198.20.51.134]:19163 helo=[10.220.53.175]) by lagoon.isletech.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PGv5U-0008z2-Gk for freebsd-stable@freebsd.org; Fri, 12 Nov 2010 09:58:48 -0500 Message-ID: <4CDD562D.3050403@isletech.net> Date: Fri, 12 Nov 2010 09:58:53 -0500 From: Daryl Richards User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 12 Nov 2010 16:44:08 +0000 Subject: AESNI X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Nov 2010 15:35:24 -0000 I'm wondering what the status is of AES-NI in 8-STABLE? I can find references to it being put into 9 back in July, with the note that it would be MFC'ed within a month, but as far as I've been able to find, nothing after that. Did I miss something? Does it just need testing? How can I go about doing that? I'd like to help! Thanks, -- Daryl Richards Isle Technical Services Inc. From owner-freebsd-stable@FreeBSD.ORG Fri Nov 12 18:25: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 F2F22106564A for ; Fri, 12 Nov 2010 18:25:50 +0000 (UTC) (envelope-from biuro@wwv.pl) Received: from wwv.pl (wwv.pl [62.87.136.170]) by mx1.freebsd.org (Postfix) with ESMTP id A3E5F8FC08 for ; Fri, 12 Nov 2010 18:25:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wwv.pl; s=dkim; h=Subject:Content-Transfer-Encoding:Mime-Version:Message-ID:Date:Content-Type:To:From; bh=eBXU6/Efcli/xgqO0KdaWUde/WFG5nR6ZKK933QoRQY=; b=mPKyrAvktTFByPyQKZzu8WElhwhVLBXfPbD8uQ1pJg9llIp88CLTdcAD/J24iv6nMcMYgJibZB27vDAaVH1JKDo0dlrMaNh8j5NPv0+pzUcbdUMFMrVKIN0PhvQezTil; Received: from [46.112.92.2] by wwv.pl with esmtpsa (Cipher SSLv3:CAMELLIA256-SHA:256) (Exim 4.72 compile 0) id 1PGxsO-000KSQ-BT by authid with auth_login for ; Fri, 12 Nov 2010 18:57:33 +0100 From: Maciej Friedel To: freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" Date: Fri, 12 Nov 2010 19:03:45 +0000 Message-ID: <1289588625.1584.11.camel@toshiba> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 46.112.92.2 X-SA-Exim-Rcpt-To: freebsd-stable@freebsd.org X-SA-Exim-Mail-From: biuro@wwv.pl X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on wwv.pl X-Spam-Level: X-Spam-Status: No, score=-11.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.3.1 X-Spam-Flag: NO X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on wwv.pl) Subject: 8.1-STABLE - zpool import problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Nov 2010 18:25:51 -0000 I have a problem with importing the newly created pool # uname -a FreeBSD backup.wwv.pl 8.1-STABLE FreeBSD 8.1-STABLE #1: Thu Nov 11 15:13:25 CET 2010 root@backup.wwv.pl:/usr/obj/usr/src/sys/BACKUP i386 # dmesg | grep WDC ad4: 610480MB at ata2-master UDMA100 SATA 1.5Gb/s ad6: 610480MB at ata3-master UDMA100 SATA 1.5Gb/s ad12: 152627MB at ata6-master UDMA100 SATA 1.5Gb/s # zpool create backupfs ad4 ad6 # zpool status pool: backupfs state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM backupfs ONLINE 0 0 0 ad4 ONLINE 0 0 0 ad6 ONLINE 0 0 0 errors: No known data errors pool: basefs state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM basefs ONLINE 0 0 0 ad12s2 ONLINE 0 0 0 errors: No known data errors # zfs create backupfs/backup # df -h Filesystem Size Used Avail Capacity Mounted on /dev/label/rootfs 496M 354M 102M 78% / devfs 1.0K 1.0K 0B 100% /dev basefs/home 141G 117G 24G 83% /home basefs/usr 27G 2.8G 24G 11% /usr basefs/var 24G 255M 24G 1% /var /dev/md0 496M 46K 496M 0% /tmp backupfs 1.1T 21K 1.1T 0% /backupfs backupfs/backup 1.1T 21K 1.1T 0% /backupfs/backup # mkdir /home/backup # zfs umount /backupfs/backup # zfs umount /backupfs # zfs set mountpoint=/home/backup backupfs/backup # zfs set mountpoint=none backupfs # zpool export backupfs # zpool import backupfs cannot import 'backupfs': pool is formatted using a newer ZFS version # zpool import pool: backupfs id: 1262536404400505900 state: ONLINE action: The pool can be imported using its name or numeric identifier. config: backupfs ONLINE ad4 ONLINE ad6 ONLINE # zfs upgrade This system is currently running ZFS filesystem version 3. All filesystems are formatted with the current version. # zpool upgrade This system is currently running ZFS pool version 14. All pools are formatted using this version. Regards, Maciej Friedel -- Maciej Friedel From owner-freebsd-stable@FreeBSD.ORG Fri Nov 12 19:12:17 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id C3F6C106566B; Fri, 12 Nov 2010 19:12:17 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-stable@FreeBSD.org Date: Fri, 12 Nov 2010 14:12:05 -0500 User-Agent: KMail/1.6.2 References: <4CDD8019.30009@googlemail.com> In-Reply-To: <4CDD8019.30009@googlemail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011121412.08017.jkim@FreeBSD.org> Cc: Veniamin Gvozdikov Subject: Re: MacBookPro7,1 and FreeBSD 8.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Nov 2010 19:12:17 -0000 [Move the thread to freebsd-stable@] On Friday 12 November 2010 12:57 pm, Veniamin Gvozdikov wrote: > Hi everybody. > I have the macbook and I tryed install FreeBSD 8.1. But I have > froze loading. > > I have it's: > with acpi (default loading) > http://img203.imageshack.us/img203/2556/dscn2822u.jpg > > disable acpi > http://img152.imageshack.us/img152/1796/dscn2823.jpg > > verbose mode (option 5 at the boot menu) > http://img822.imageshack.us/img822/8069/dscn2825gm.jpg It seems it is yet another mysterious and notorious "memory mapped IO hangs after PAT change" case of Apple hardware. If that's the case, FreeBSD 7.3 or older should work, I think. Then, you can upgrade it from source *after* adding your Mac model in sys/amd64/amd64/pmap.c such as this: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/amd64/amd64/pmap.c.diff?r1=1.710;r2=1.711 If it works, please let us know. Jung-uk Kim From owner-freebsd-stable@FreeBSD.ORG Fri Nov 12 19:16: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 A4AA3106564A for ; Fri, 12 Nov 2010 19:16:37 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 30A9F8FC1A for ; Fri, 12 Nov 2010 19:16:36 +0000 (UTC) Received: by wwj40 with SMTP id 40so283964wwj.31 for ; Fri, 12 Nov 2010 11:16:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=B2/vPHXREB5KkI7erH8VhorRWF9EeUK6Jbehz+evtOo=; b=W/ZJ/Uo349e1M7HvCCWGeYG0kP4zBQrSiyQymIIRqY95E/ksBGc9y+EdM7slYv9cWZ bOsDI+71itZ7esLwjmN4zYPqnQHvIcKmz4+NoX471VYdms5cbAqXQnKBK9/nnukw8DcR DZb2UPgU5xhrwUr9uL/m4DcBOUp2sQ/lPPbUQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=n/i97kq1eoUP+BsiD2reMGduKqh5BVM1eLxZ8IjaJnDiWlghV/4aAwB+YPxc6AVRTw HVbSQSeKgtHzbMc7BkcsDTpw05lztUYr8blWlVWhRlCdKBdXSZYmo9qRt6kRBMOUJfD3 AuuK9FyD21ZQXVA1aMaHbZyiN/1i0HnqtNmno= Received: by 10.216.13.207 with SMTP id b57mr2446058web.32.1289589394739; Fri, 12 Nov 2010 11:16:34 -0800 (PST) Received: from centel.dataix.local (adsl-99-181-128-23.dsl.klmzmi.sbcglobal.net [99.181.128.23]) by mx.google.com with ESMTPS id f31sm2347151wej.39.2010.11.12.11.16.26 (version=SSLv3 cipher=RC4-MD5); Fri, 12 Nov 2010 11:16:28 -0800 (PST) Sender: "J. Hellenthal" Message-ID: <4CDD9289.80600@DataIX.net> Date: Fri, 12 Nov 2010 14:16:25 -0500 From: jhell Organization: http://www.DataIX.net User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.12) Gecko/20101028 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Maciej Friedel References: <1289588625.1584.11.camel@toshiba> In-Reply-To: <1289588625.1584.11.camel@toshiba> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 8.1-STABLE - zpool import problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Nov 2010 19:16:37 -0000 On 11/12/2010 14:03, Maciej Friedel wrote: > I have a problem with importing the newly created pool > > # uname -a > FreeBSD backup.wwv.pl 8.1-STABLE FreeBSD 8.1-STABLE #1: Thu Nov 11 > 15:13:25 CET 2010 root@backup.wwv.pl:/usr/obj/usr/src/sys/BACKUP > i386 > > # dmesg | grep WDC > ad4: 610480MB at ata2-master UDMA100 > SATA 1.5Gb/s > ad6: 610480MB at ata3-master UDMA100 > SATA 1.5Gb/s > ad12: 152627MB at ata6-master UDMA100 > SATA 1.5Gb/s > > # zpool create backupfs ad4 ad6 > # zpool status > pool: backupfs > state: ONLINE > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > backupfs ONLINE 0 0 0 > ad4 ONLINE 0 0 0 > ad6 ONLINE 0 0 0 > > errors: No known data errors > > pool: basefs > state: ONLINE > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > basefs ONLINE 0 0 0 > ad12s2 ONLINE 0 0 0 > > errors: No known data errors > > # zfs create backupfs/backup > # df -h > Filesystem Size Used Avail Capacity Mounted on > /dev/label/rootfs 496M 354M 102M 78% / > devfs 1.0K 1.0K 0B 100% /dev > basefs/home 141G 117G 24G 83% /home > basefs/usr 27G 2.8G 24G 11% /usr > basefs/var 24G 255M 24G 1% /var > /dev/md0 496M 46K 496M 0% /tmp > backupfs 1.1T 21K 1.1T 0% /backupfs > backupfs/backup 1.1T 21K 1.1T 0% /backupfs/backup > # mkdir /home/backup > # zfs umount /backupfs/backup > # zfs umount /backupfs > # zfs set mountpoint=/home/backup backupfs/backup > # zfs set mountpoint=none backupfs > # zpool export backupfs > # zpool import backupfs > cannot import 'backupfs': pool is formatted using a newer ZFS version > > # zpool import > pool: backupfs > id: 1262536404400505900 > state: ONLINE > action: The pool can be imported using its name or numeric identifier. > config: > > backupfs ONLINE > ad4 ONLINE > ad6 ONLINE > # zfs upgrade > This system is currently running ZFS filesystem version 3. > > All filesystems are formatted with the current version. > # zpool upgrade > This system is currently running ZFS pool version 14. > > All pools are formatted using this version. > > Regards, > Maciej Friedel > One thing to note here is that your running 8.1-STABLE November code which is a zpl version 4 and spa 15 or otherwise known as ZFS v15. Did you build this from source ? or install via snapshot. If you installed via upgrading from source... Is your user-level zfs utilities & libs up-to-date or in sync with your kernel ? -- jhell,v From owner-freebsd-stable@FreeBSD.ORG Fri Nov 12 19:44: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 72F08106564A for ; Fri, 12 Nov 2010 19:44:44 +0000 (UTC) (envelope-from biuro@wwv.pl) Received: from wwv.pl (wwv.pl [62.87.136.170]) by mx1.freebsd.org (Postfix) with ESMTP id 2150E8FC23 for ; Fri, 12 Nov 2010 19:44:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wwv.pl; s=dkim; h=Subject:Content-Transfer-Encoding:Mime-Version:Message-ID:Date:Content-Type:References:In-Reply-To:Cc:To:From; bh=NkVmau+QwaAMM9sCPdYCIGIeOkXsT4noUMq0E8F/hv0=; b=Fm+8yJ9dcOD/KONbzSPnLedziRhnae3y1BumZS75tkHwed2zkyIsudLXDwHrSsar7Ldp1G06+eUNwbycd5gf2Nxpc2E4PvBsGUbX6DZJg+AqhbuN7UL47I2ylZ3LlkG9; Received: from [46.112.92.2] by wwv.pl with esmtpsa (Cipher SSLv3:CAMELLIA256-SHA:256) (Exim 4.72 compile 0) id 1PGzRT-000L82-QA by authid with auth_login; Fri, 12 Nov 2010 20:37:51 +0100 From: Maciej Friedel To: jhell In-Reply-To: <4CDD9289.80600@DataIX.net> References: <1289588625.1584.11.camel@toshiba> <4CDD9289.80600@DataIX.net> Content-Type: text/plain; charset="UTF-8" Date: Fri, 12 Nov 2010 20:44:09 +0000 Message-ID: <1289594649.1584.13.camel@toshiba> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 46.112.92.2 X-SA-Exim-Rcpt-To: jhell@DataIX.net, freebsd-stable@freebsd.org X-SA-Exim-Mail-From: biuro@wwv.pl X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on wwv.pl X-Spam-Level: X-Spam-Status: No, score=-12.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, GREYLIST_ISWHITE autolearn=ham version=3.3.1 X-Spam-Flag: NO X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on wwv.pl) Cc: freebsd-stable@freebsd.org Subject: Re: 8.1-STABLE - zpool import problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Nov 2010 19:44:44 -0000 Dnia 2010-11-12, ptk o godzinie 14:16 -0500, jhell pisze: > One thing to note here is that your running 8.1-STABLE November code > which is a zpl version 4 and spa 15 or otherwise known as ZFS v15. Did > you build this from source ? or install via snapshot. If you installed > via upgrading from source... Is your user-level zfs utilities & libs > up-to-date or in sync with your kernel ? yes, here is the problem, thanks wdupe.wwv.pl:/root # zdb -l /dev/ad4 -------------------------------------------- LABEL 0 -------------------------------------------- version=15 name='backupfs' state=1 txg=57 pool_guid=1262536404400505900 hostid=2180312168 hostname='backup.wwv.pl' top_guid=924617532259060961 guid=924617532259060961 vdev_tree type='disk' id=0 guid=924617532259060961 path='/dev/ad4' whole_disk=0 metaslab_array=26 metaslab_shift=32 ashift=9 asize=640130220032 is_log=0 -------------------------------------------- -- Maciej Friedel From owner-freebsd-stable@FreeBSD.ORG Fri Nov 12 20:26:09 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 87D22106566C for ; Fri, 12 Nov 2010 20:26:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id DAF268FC28 for ; Fri, 12 Nov 2010 20:26:08 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id oACKQ4Ti084789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Nov 2010 22:26:04 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id oACKQ4QR019218; Fri, 12 Nov 2010 22:26:04 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oACKQ3os019217; Fri, 12 Nov 2010 22:26:03 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 12 Nov 2010 22:26:03 +0200 From: Kostik Belousov To: Daryl Richards Message-ID: <20101112202603.GD2392@deviant.kiev.zoral.com.ua> References: <4CDD562D.3050403@isletech.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="n8KC9La+guUBZEkD" Content-Disposition: inline In-Reply-To: <4CDD562D.3050403@isletech.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-stable@freebsd.org Subject: Re: AESNI X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Nov 2010 20:26:09 -0000 --n8KC9La+guUBZEkD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 12, 2010 at 09:58:53AM -0500, Daryl Richards wrote: > I'm wondering what the status is of AES-NI in 8-STABLE? I can find=20 > references to it being put into 9 back in July, with the note that it=20 > would be MFC'ed within a month, but as far as I've been able to find,=20 > nothing after that. As a public service, since I already got several private mails, I will state the current situation: AESNI merge depends on the merge of r208833 and a lot of followups to r208833. The merge of r208833 needs r208453, that was committed to stable/8 only recently, since it required an approval from re@. This delay together with lack of the time recently on my side makes me skeptical about chances to have aesni(4) in 8.2. Please note that aesni(4) is not needed to use AESNI in usermode. >=20 > Did I miss something? Does it just need testing? How can I go about=20 > doing that? I'd like to help! >=20 > Thanks, > --=20 > Daryl Richards > Isle Technical Services Inc. > _______________________________________________ > 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" --n8KC9La+guUBZEkD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzdotsACgkQC3+MBN1Mb4jgIACfYSziqpjkAEW8kMC+q8xkSq53 8TAAn3GA2aiv9uewAF7JnV1I2dEczFVW =/Vx1 -----END PGP SIGNATURE----- --n8KC9La+guUBZEkD-- From owner-freebsd-stable@FreeBSD.ORG Fri Nov 12 21: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 833B310656EF for ; Fri, 12 Nov 2010 21:23:23 +0000 (UTC) (envelope-from daryl@isletech.net) Received: from lagoon.isletech.net (lagoon.isletech.net [64.235.98.66]) by mx1.freebsd.org (Postfix) with ESMTP id 551148FC12 for ; Fri, 12 Nov 2010 21:23:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=isletech.net; s=isle; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=i0zDquMBTGtgLBD99dwud02df4CSCoyQZr4I3HGzoKc=; b=dlVQGhG15oFjln1BU7yBjtmzAEpA6ze2xkNh6M22MA6gWd4gk4vcyEeSo6Or9hHQIspH9PW3bLzolQhcNa1jRw==; Received: from coin1.ocl.net ([198.20.51.134]:64253 helo=[10.220.53.175]) by lagoon.isletech.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PH15d-000Brn-6P for freebsd-stable@freebsd.org; Fri, 12 Nov 2010 16:23:21 -0500 Message-ID: <4CDDB049.5070805@isletech.net> Date: Fri, 12 Nov 2010 16:23:21 -0500 From: Daryl Richards User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4CDD562D.3050403@isletech.net> <20101112202603.GD2392@deviant.kiev.zoral.com.ua> In-Reply-To: <20101112202603.GD2392@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: AESNI X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Nov 2010 21:23:23 -0000 I was hoping to take advantage of it in openssl, ssh, and geli, which would just happen if it was part of crypto.. I'll just keep watching then, thanks! Daryl Richards Isle Technical Services Inc. On 11/12/2010 3:26 PM, Kostik Belousov wrote: > On Fri, Nov 12, 2010 at 09:58:53AM -0500, Daryl Richards wrote: >> I'm wondering what the status is of AES-NI in 8-STABLE? I can find >> references to it being put into 9 back in July, with the note that it >> would be MFC'ed within a month, but as far as I've been able to find, >> nothing after that. > As a public service, since I already got several private mails, > I will state the current situation: > > AESNI merge depends on the merge of r208833 and a lot of followups to > r208833. The merge of r208833 needs r208453, that was committed to stable/8 > only recently, since it required an approval from re@. > > This delay together with lack of the time recently on my side makes me > skeptical about chances to have aesni(4) in 8.2. > > Please note that aesni(4) is not needed to use AESNI in usermode. > >> >> Did I miss something? Does it just need testing? How can I go about >> doing that? I'd like to help! >> >> Thanks, >> -- >> Daryl Richards >> Isle Technical Services Inc. >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Fri Nov 12 21:29: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 80D7A106567A for ; Fri, 12 Nov 2010 21:29:14 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 387618FC13 for ; Fri, 12 Nov 2010 21:29:14 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:808a:bf97:8eb:f23b] ([IPv6:2607:f3e0:0:4:808a:bf97:8eb:f23b]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id oACLT2Fw065089 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 12 Nov 2010 16:29:02 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4CDDB182.4060707@sentex.net> Date: Fri, 12 Nov 2010 16:28:34 -0500 From: Mike Tancsa User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Kostik Belousov References: <4CDD562D.3050403@isletech.net> <20101112202603.GD2392@deviant.kiev.zoral.com.ua> In-Reply-To: <20101112202603.GD2392@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: Daryl Richards , freebsd-stable@freebsd.org Subject: Re: AESNI X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Nov 2010 21:29:14 -0000 On 11/12/2010 3:26 PM, Kostik Belousov wrote: > On Fri, Nov 12, 2010 at 09:58:53AM -0500, Daryl Richards wrote: >> I'm wondering what the status is of AES-NI in 8-STABLE? I can find >> references to it being put into 9 back in July, with the note that it >> would be MFC'ed within a month, but as far as I've been able to find, >> nothing after that. > As a public service, since I already got several private mails, > I will state the current situation: > > AESNI merge depends on the merge of r208833 and a lot of followups to > r208833. The merge of r208833 needs r208453, that was committed to stable/8 > only recently, since it required an approval from re@. > > This delay together with lack of the time recently on my side makes me > skeptical about chances to have aesni(4) in 8.2. > > Please note that aesni(4) is not needed to use AESNI in usermode. BTW, has anyone tried merging the patch at http://rt.openssl.org/Ticket/Display.html?id=2067&user=guest&pass=guest to RELENG_8's openssl ? ---Mike From owner-freebsd-stable@FreeBSD.ORG Fri Nov 12 22:29: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 7EBFA1065780 for ; Fri, 12 Nov 2010 22:29:17 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 1B04A8FC14 for ; Fri, 12 Nov 2010 22:29:16 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:808a:bf97:8eb:f23b] ([IPv6:2607:f3e0:0:4:808a:bf97:8eb:f23b]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id oACMT3Gh091936 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 12 Nov 2010 17:29:04 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4CDDBF93.1000601@sentex.net> Date: Fri, 12 Nov 2010 17:28:35 -0500 From: Mike Tancsa User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Kostik Belousov References: <4CDD562D.3050403@isletech.net> <20101112202603.GD2392@deviant.kiev.zoral.com.ua> <4CDDB182.4060707@sentex.net> In-Reply-To: <4CDDB182.4060707@sentex.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: Daryl Richards , freebsd-stable@freebsd.org Subject: Re: AESNI X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Nov 2010 22:29:17 -0000 On 11/12/2010 4:28 PM, Mike Tancsa wrote: > On 11/12/2010 3:26 PM, Kostik Belousov wrote: >> On Fri, Nov 12, 2010 at 09:58:53AM -0500, Daryl Richards wrote: >>> I'm wondering what the status is of AES-NI in 8-STABLE? I can find >>> references to it being put into 9 back in July, with the note that it >>> would be MFC'ed within a month, but as far as I've been able to find, >>> nothing after that. >> As a public service, since I already got several private mails, >> I will state the current situation: >> >> AESNI merge depends on the merge of r208833 and a lot of followups to >> r208833. The merge of r208833 needs r208453, that was committed to stable/8 >> only recently, since it required an approval from re@. >> >> This delay together with lack of the time recently on my side makes me >> skeptical about chances to have aesni(4) in 8.2. >> >> Please note that aesni(4) is not needed to use AESNI in usermode. > > BTW, has anyone tried merging the patch at > > http://rt.openssl.org/Ticket/Display.html?id=2067&user=guest&pass=guest > > to RELENG_8's openssl ? Seems to fail in the buildworld. Patching /usr/src/crypto/openssl works (if you remove the windows patches to .bat files) and even doing cd /usr/src/secure/usr.bin/openssl;make depend;make works ===> libexec/telnetd (all) cc -O2 -pipe -DLINEMODE -DUSE_TERMIO -DDIAGNOSTICS -DOLD_ENVIRON -DENV_HACK -DSTREAMSPTY -DINET6 -I/usr/src/libexec/telnetd/../../contrib/telnet -DAUTHENTICATION -DENCRYPTION -DKRB5 -DFORWARD -Dnet_write=telnet_net_write -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o telnetd global.o slc.o state.o sys_term.o telnetd.o termstat.o utility.o authenc.o -lutil -ltermcap /usr/obj/usr/src/libexec/telnetd/../../lib/libtelnet/libtelnet.a -lmp -lcrypto -lcrypt -lpam -lkrb5 -lhx509 -lasn1 -lroken -lcom_err /usr/obj/usr/src/tmp/usr/lib/libcrypto.so: undefined reference to `ENGINE_load_aesni' *** Error code 1 Stop in /usr/src/libexec/telnetd. *** Error code 1 Stop in /usr/src/libexec. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. From owner-freebsd-stable@FreeBSD.ORG Sat Nov 13 00:38:50 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 369B6106564A; Sat, 13 Nov 2010 00:38:50 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id EC7FC8FC25; Sat, 13 Nov 2010 00:38:49 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oAD0cnXo070517; Fri, 12 Nov 2010 19:38:49 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oAD0cnHi070515; Sat, 13 Nov 2010 00:38:49 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 13 Nov 2010 00:38:49 GMT Message-Id: <201011130038.oAD0cnHi070515@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_1 tinderbox] failure on i386/pc98 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2010 00:38:50 -0000 TB --- 2010-11-13 00:33:06 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-13 00:33:06 - starting RELENG_8_1 tinderbox run for i386/pc98 TB --- 2010-11-13 00:33:06 - cleaning the object tree TB --- 2010-11-13 00:33:33 - cvsupping the source tree TB --- 2010-11-13 00:33:33 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_1/i386/pc98/supfile TB --- 2010-11-13 00:38:48 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-11-13 00:38:48 - ERROR: unable to cvsup the source tree TB --- 2010-11-13 00:38:48 - 1.09 user 13.98 system 342.87 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_1-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Sat Nov 13 01:44: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 74FB5106566C; Sat, 13 Nov 2010 01:44:26 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id D66738FC13; Sat, 13 Nov 2010 01:44:23 +0000 (UTC) Received: by wyb36 with SMTP id 36so590909wyb.13 for ; Fri, 12 Nov 2010 17:44:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=XTZtD7hKiaN8YOXPK3hT+aftPBaAHfLBCbTu3Tf4Keo=; b=oC5Ztad57ScrtV0Dv8/CGBiHVwCqTyM0HZc6lVQtqtMYd5zWQ7kTMllCOtElG4BKsl xcuEgga2bMLYj4hH+uTLBQxuf1eMFFcllTz/oNwLV8zHjMsaiS5TBI8/S/8fpnQr1Bzd d4hIw8PmDv6G6gNTLiG91IkCAzp/xIaJRWgHM= 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=Y4qttIXt0J2ILt/McwctD1RAMO5KOolgNHQfvhqkmrykZqd/U9QrgOTp0p3E7xagLA Bw5i8N5IriEatVYIF3xeIRA2a4GIusi5su3ukQ4N5ET/ltOF2eh3+DRfSQ+JBRFZ9XAp DMRfgfHKCeK6/CxChKs/eVkxlY6Y/mn1xch9A= MIME-Version: 1.0 Received: by 10.216.171.75 with SMTP id q53mr2596431wel.74.1289612661936; Fri, 12 Nov 2010 17:44:21 -0800 (PST) Received: by 10.216.12.80 with HTTP; Fri, 12 Nov 2010 17:44:21 -0800 (PST) In-Reply-To: <4CD45209.5010607@FreeBSD.org> References: <4CD45209.5010607@FreeBSD.org> Date: Fri, 12 Nov 2010 19:44:21 -0600 Message-ID: From: Brandon Gooch To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-scsi@freebsd.org, FreeBSD-Current , FreeBSD Stable Subject: Re: Sense fetching [Was: cdrtools /devel ...] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Nov 2010 01:44:26 -0000 2010/11/5 Alexander Motin : > Hi. > > I've reviewed tests that scgcheck does to SCSI subsystem. It shown > combination of several issues in both CAM, ahci(4) and cdrtools itself. > Several small patches allow us to pass most of that tests: > http://people.freebsd.org/~mav/sense/ > > ahci_resid.patch: Add support for reporting residual length on data > underrun. SCSI commands often returns results shorter then expected. > Returned value allows application to know/check how much data it really > has. It is also important for sense fetching, as ATAPI and USB devices > return sense as data in response to REQUEST_SENSE command. > > sense_resid.patch: When manually requesting sense data (ATAPI or USB), > request only as much data as user requested (not the fixed structure > size), and return respective sense residual length. > > pass_autosence.patch: Unless CAM_DIS_AUTOSENSE is set, always fetch > sense if not done by SIM, independently of CAM_PASS_ERR_RECOVER. As soon > as device freeze released before returning to user-level, user-level > application by definition can't reliably fetch sense data if some other > application (like hald) tries to access device same time. > > cdrtools.patch: Make libscg (part of cdrtools) on FreeBSD to submit > wanted sense length to CAM and do not clear sense return buffer. It is > mostly cosmetics, important probably only for scgcheck. > > Testers and reviewers welcome. I am especially interested in opinion > about pass_autosence.patch -- may be we should lower sense fetching even > deeper, to make it work for all cam_periph_runccb() consumers. > Hey mav, sorry to chime in after so long here, but have some of these patches been committed (as of r215179)? Which patches are still applicable for testing? I assume the cdrtools patch for sure... -Brandon From owner-freebsd-stable@FreeBSD.ORG Sat Nov 13 02:27: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 03C751065672; Sat, 13 Nov 2010 02:27:12 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [IPv6:2a01:4f8:100:1043::3]) by mx1.freebsd.org (Postfix) with ESMTP id 459958FC16; Sat, 13 Nov 2010 02:27:11 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.1]) by mail.vx.sk (Postfix) with ESMTP id 4405E11C005; Sat, 13 Nov 2010 03:27:08 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk ([127.0.0.1]) by core.vx.sk (mail.vx.sk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Qe5JL+6kd74J; Sat, 13 Nov 2010 03:27:06 +0100 (CET) Received: from [10.9.8.1] (188-167-78-139.dynamic.chello.sk [188.167.78.139]) by mail.vx.sk (Postfix) with ESMTPSA id B0C8511BFFB; Sat, 13 Nov 2010 03:27:05 +0100 (CET) Message-ID: <4CDDF77B.90708@FreeBSD.org> Date: Sat, 13 Nov 2010 03:27:07 +0100 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sk; rv:1.8.1.23) Gecko/20090812 Lightning/0.9 Thunderbird/2.0.0.23 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Andriy Gapon References: <4CDD2F5F.2000902@freebsd.org> <4CDD4EB4.40004@freebsd.org> In-Reply-To: <4CDD4EB4.40004@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org, Alexander Zagrebin Subject: Re: 8.1-STABLE: problem with unmounting ZFS snapshots X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Nov 2010 02:27:12 -0000 Yes, this is indeed a leak introduced by importing onnv revision 9214 and it exists in perforce as well - very easy to reproduce. # mount -t zfs test@t1 /mnt # umount /mnt (-> hang) http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6604992 http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6810367 This is not compatible with mounting snapshots outside mounted ZFS and I was not able to reproduce the errors defined in 6604992 and 6810367 (they are Solaris-specific). I suggest we comment out this code (from head, later MFC and p4 as well). Patch (should work with HEAD and 8-STABLE): http://people.freebsd.org/~mm/patches/zfs/zfs_vfsops.c.patch Dňa 12.11.2010 15:27, Andriy Gapon wrote / napísal(a): > on 12/11/2010 16:00 Alexander Zagrebin said the following: >> Thanks for your reply! >> >>>> 2. the umount is waiting for disk >>>> #ps | egrep 'PID|umount' >>>> PID TT STAT TIME COMMAND >>>> 958 0 D+ 0:00,04 umount /mnt >>>> # procstat -t 958 >>>> PID TID COMM TDNAME CPU PRI >>> STATE WCHAN >>>> 958 100731 umount - 3 133 >>> sleep mntref >>> >>> procstat -kk >> >> $ ps a | grep umount >> 86874 2- D 0:00,06 umount /mnt >> 90433 3 S+ 0:00,01 grep umount >> >> $ sudo procstat -kk 86874 >> PID TID COMM TDNAME KSTACK >> 86874 100731 umount - mi_switch+0x176 >> sleepq_wait+0x42 _sleep+0x317 vfs_mount_destroy+0x5a dounmount+0x4d4 >> unmount+0x38b syscall+0x1cf Xfast_syscall+0xe2 >> > > > Looks like possible mnt_ref leak. > I think that something like that was fixed some not long time ago. > Perhaps you either don't have the fix or there is another leak. > What revision do you have? > > Perhaps Martin has an insight here. > From owner-freebsd-stable@FreeBSD.ORG Sat Nov 13 03:38: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 9A28D10656A6 for ; Sat, 13 Nov 2010 03:38:51 +0000 (UTC) (envelope-from ptyll@nitronet.pl) Received: from mail.nitronet.pl (smtp.nitronet.pl [195.90.106.27]) by mx1.freebsd.org (Postfix) with ESMTP id D06B28FC14 for ; Sat, 13 Nov 2010 03:38:46 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PH6Jf-000HTp-FS for freebsd-stable@freebsd.org; Sat, 13 Nov 2010 03:58:11 +0100 Resent-Date: Sat, 13 Nov 2010 03:58:11 +0100 Resent-Message-Id: Date: Sat, 13 Nov 2010 03:58:01 +0100 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <198322694.20101113035801@nitronet.pl> To: Luigi Rizzo Resent-from: Pawel Tyll MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------581BD1DE24DDAE94" X-Virus-Scanned: Nitronet.pl X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ptyll@nitronet.pl X-SA-Exim-Scanned: No (on mail.nitronet.pl); SAEximRunCond expanded to false Cc: freebsd-stable@freebsd.org Subject: Re: Crash in dummynet. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Nov 2010 03:38:51 -0000 ------------581BD1DE24DDAE94 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable Hi Luigi, > a backtrace and the detailed version of the ipfw+dummynet > files will help Sorry for the delay - system crashes "only" every two-three weeks, and recently it's hard to get a proper dump out of FreeBSD, at least on my hardware. Anyway, it worked some time ago, dumped on second drive from a mirror, and due to some changes I made recently, savecore located the dump. While the dump is from 8.1-RELEASE, problem persists on recent STABLE builds. ------------581BD1DE24DDAE94 Content-Type: application/octet-stream; name="core.txt.0" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="core.txt.0" aG9zdG5hbWUuZG9tYWluLnRsZCBkdW1wZWQgY29yZSAtIHNlZSAvdmFyL2NyYXNoL3ZtY29y ZS4wCgpTdW4gTm92ICA3IDAwOjE2OjA5IENFVCAyMDEwCgpGcmVlQlNEIGhvc3RuYW1lLmRv bWFpbi50bGQgOC4xLVJFTEVBU0UgRnJlZUJTRCA4LjEtUkVMRUFTRSAjMTogVHVlIEp1bCAy NyAwNDoxODo1NCBDRVNUIDIwMTAgICAgIHVzZXJAaG9zdG5hbWUuZG9tYWluLnRsZDovdXNy L29iai91c3Ivc3JjL3N5cy9ob3N0bmFtZSAgYW1kNjQKCnBhbmljOiBwYWdlIGZhdWx0CgpH TlUgZ2RiIDYuMS4xIFtGcmVlQlNEXQpDb3B5cmlnaHQgMjAwNCBGcmVlIFNvZnR3YXJlIEZv dW5kYXRpb24sIEluYy4KR0RCIGlzIGZyZWUgc29mdHdhcmUsIGNvdmVyZWQgYnkgdGhlIEdO VSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlLCBhbmQgeW91IGFyZQp3ZWxjb21lIHRvIGNoYW5n ZSBpdCBhbmQvb3IgZGlzdHJpYnV0ZSBjb3BpZXMgb2YgaXQgdW5kZXIgY2VydGFpbiBjb25k aXRpb25zLgpUeXBlICJzaG93IGNvcHlpbmciIHRvIHNlZSB0aGUgY29uZGl0aW9ucy4KVGhl cmUgaXMgYWJzb2x1dGVseSBubyB3YXJyYW50eSBmb3IgR0RCLiAgVHlwZSAic2hvdyB3YXJy YW50eSIgZm9yIGRldGFpbHMuClRoaXMgR0RCIHdhcyBjb25maWd1cmVkIGFzICJhbWQ2NC1t YXJjZWwtZnJlZWJzZCIuLi4KClVucmVhZCBwb3J0aW9uIG9mIHRoZSBrZXJuZWwgbWVzc2Fn ZSBidWZmZXI6CgoJCQk9IERQTCAwLCBwcmVzIDEsIGxvbmcgMSwgZGVmMzIgMCwgZ3JhbiAx CnByb2Nlc3NvciBlZmxhZ3MJPSAKcHJvY2Vzc29yIGVmbGFncwk9IGludGVycnVwdCBlbmFi bGVkLCBpbnRlcnJ1cHQgZW5hYmxlZCwgcmVzdW1lLCByZXN1bWUsIElPUEwgPSAwSU9QTCA9 IDAKY3VycmVudCBwcm9jZXNzCQk9IApjdXJyZW50IHByb2Nlc3MJCT0gMTIgKGlycTI1Nzog ZW0xKTAgKGR1bW15bmV0KQp0cmFwIG51bWJlcgkJPSAxMgp0cmFwIG51bWJlcgkJPSAxMgpw YW5pYzogcGFnZSBmYXVsdAoKY3B1aWQgPSA2ClVwdGltZTogMTZkMjNoNTdtNDVzClBoeXNp Y2FsIG1lbW9yeTogNDA0NCBNQgpEdW1waW5nIDE3MDQgTUI6IDE2ODkgMTY3MyAxNjU3IDE2 NDEgMTYyNSAxNjA5IDE1OTMgMTU3NyAxNTYxIDE1NDUgMTUyOSAxNTEzIDE0OTcgMTQ4MSAx NDY1IDE0NDkgMTQzMyAxNDE3IDE0MDEgMTM4NSAxMzY5IDEzNTMgMTMzNyAxMzIxIDEzMDUg MTI4OSAxMjczIDEyNTcgMTI0MSAxMjI1IDEyMDkgMTE5MyAxMTc3IDExNjEgMTE0NSAxMTI5 IDExMTMgMTA5NyAxMDgxIDEwNjUgMTA0OSAxMDMzIDEwMTcgMTAwMSA5ODUgOTY5IDk1MyA5 MzcgOTIxIDkwNSA4ODkgODczIDg1NyA4NDEgODI1IDgwOSA3OTMgNzc3IDc2MSA3NDUgNzI5 IDcxMyA2OTcgNjgxIDY2NSA2NDkgNjMzIDYxNyA2MDEgNTg1IDU2OSA1NTMgNTM3IDUyMSA1 MDUgNDg5IDQ3MyA0NTcgNDQxIDQyNSA0MDkgMzkzIDM3NyAzNjEgMzQ1IDMyOSAzMTMgMjk3 IDI4MSAyNjUgMjQ5IDIzMyAyMTcgMjAxIDE4NSAxNjkgMTUzIDEzNyAxMjEgMTA1IDg5IDcz IDU3IDQxIDI1IDkKClJlYWRpbmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC96ZnMua28u Li5SZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvemZzLmtvLnN5bWJvbHMuLi5k b25lLgpkb25lLgpMb2FkZWQgc3ltYm9scyBmb3IgL2Jvb3Qva2VybmVsL3pmcy5rbwpSZWFk aW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvb3BlbnNvbGFyaXMua28uLi5SZWFkaW5n IHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvb3BlbnNvbGFyaXMua28uc3ltYm9scy4uLmRv bmUuCmRvbmUuCkxvYWRlZCBzeW1ib2xzIGZvciAvYm9vdC9rZXJuZWwvb3BlbnNvbGFyaXMu a28KUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL2dlb21fbWlycm9yLmtvLi4u UmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL2dlb21fbWlycm9yLmtvLnN5bWJv bHMuLi5kb25lLgpkb25lLgpMb2FkZWQgc3ltYm9scyBmb3IgL2Jvb3Qva2VybmVsL2dlb21f bWlycm9yLmtvClJlYWRpbmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC9pZl9lbS5rby4u LlJlYWRpbmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC9pZl9lbS5rby5zeW1ib2xzLi4u ZG9uZS4KZG9uZS4KTG9hZGVkIHN5bWJvbHMgZm9yIC9ib290L2tlcm5lbC9pZl9lbS5rbwpS ZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvYWhjaS5rby4uLlJlYWRpbmcgc3lt Ym9scyBmcm9tIC9ib290L2tlcm5lbC9haGNpLmtvLnN5bWJvbHMuLi5kb25lLgpkb25lLgpM b2FkZWQgc3ltYm9scyBmb3IgL2Jvb3Qva2VybmVsL2FoY2kua28KUmVhZGluZyBzeW1ib2xz IGZyb20gL2Jvb3Qva2VybmVsL2lwbWkua28uLi5SZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9v dC9rZXJuZWwvaXBtaS5rby5zeW1ib2xzLi4uZG9uZS4KZG9uZS4KTG9hZGVkIHN5bWJvbHMg Zm9yIC9ib290L2tlcm5lbC9pcG1pLmtvClJlYWRpbmcgc3ltYm9scyBmcm9tIC9ib290L2tl cm5lbC9zbWJ1cy5rby4uLlJlYWRpbmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC9zbWJ1 cy5rby5zeW1ib2xzLi4uZG9uZS4KZG9uZS4KTG9hZGVkIHN5bWJvbHMgZm9yIC9ib290L2tl cm5lbC9zbWJ1cy5rbwojMCAgZG9hZHVtcCAoKSBhdCBwY3B1Lmg6MjIzCjIyMwlwY3B1Lmg6 IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkuCglpbiBwY3B1LmgKKGtnZGIpICMwICBkb2Fk dW1wICgpIGF0IHBjcHUuaDoyMjMKIzEgIDB4ZmZmZmZmZmY4MDU5YWY1OSBpbiBib290ICho b3d0bz0yNjApCiAgICBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3NodXRkb3duLmM6NDE2 CiMyICAweGZmZmZmZmZmODA1OWIzOGMgaW4gcGFuaWMgKGZtdD0weGZmZmZmZmZmODA5NmQz NTQgIiVzIikKICAgIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fc2h1dGRvd24uYzo1OTAK IzMgIDB4ZmZmZmZmZmY4MDg5NDEyOCBpbiB0cmFwX2ZhdGFsIChmcmFtZT0weGZmZmZmZjAw MDMxYTI3YzAsIGV2YT1WYXJpYWJsZSAiZXZhIiBpcyBub3QgYXZhaWxhYmxlLgopCiAgICBh dCAvdXNyL3NyYy9zeXMvYW1kNjQvYW1kNjQvdHJhcC5jOjc3NwojNCAgMHhmZmZmZmZmZjgw ODk0NGY0IGluIHRyYXBfcGZhdWx0IChmcmFtZT0weGZmZmZmZjgxYjFjODg1NjAsIHVzZXJt b2RlPTApCiAgICBhdCAvdXNyL3NyYy9zeXMvYW1kNjQvYW1kNjQvdHJhcC5jOjY5MwojNSAg MHhmZmZmZmZmZjgwODk0ZDNhIGluIHRyYXAgKGZyYW1lPTB4ZmZmZmZmODFiMWM4ODU2MCkK ICAgIGF0IC91c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC90cmFwLmM6NDUxCiM2ICAweGZmZmZm ZmZmODA4N2E3MDMgaW4gY2FsbHRyYXAgKCkKICAgIGF0IC91c3Ivc3JjL3N5cy9hbWQ2NC9h bWQ2NC9leGNlcHRpb24uUzoyMjMKIzcgIDB4ZmZmZmZmZmY4MDY5OGFiZiBpbiBpbl9sb2Nh bGFkZHIgKGluPVZhcmlhYmxlICJpbiIgaXMgbm90IGF2YWlsYWJsZS4KKSBhdCAvdXNyL3Ny Yy9zeXMvbmV0aW5ldC9pbi5jOjExNQojOCAgMHhmZmZmZmZmZjgwNmIwZGViIGluIGlwZndf Y2hrIChhcmdzPTB4ZmZmZmZmODFiMWM4ODdkMCkKICAgIGF0IC91c3Ivc3JjL3N5cy9uZXRp bmV0L2lwZncvaXBfZncyLmM6MTY4OAojOSAgMHhmZmZmZmZmZjgwNmIzZTRhIGluIGlwZndf Y2hlY2tfaG9vayAoYXJnPVZhcmlhYmxlICJhcmciIGlzIG5vdCBhdmFpbGFibGUuCikKICAg IGF0IC91c3Ivc3JjL3N5cy9uZXRpbmV0L2lwZncvaXBfZndfcGZpbC5jOjEzOQojMTAgMHhm ZmZmZmZmZjgwNjU0MzhjIGluIHBmaWxfcnVuX2hvb2tzIChwaD1WYXJpYWJsZSAicGgiIGlz IG5vdCBhdmFpbGFibGUuCikgYXQgL3Vzci9zcmMvc3lzL25ldC9wZmlsLmM6ODIKIzExIDB4 ZmZmZmZmZmY4MDZiOTRiMyBpbiBpcF9pbnB1dCAobT1kd2FyZjJfcmVhZF9hZGRyZXNzOiBD b3JydXB0ZWQgRFdBUkYgZXhwcmVzc2lvbi4KKSBhdCAvdXNyL3NyYy9zeXMvbmV0aW5ldC9p cF9pbnB1dC5jOjUzNQojMTIgMHhmZmZmZmZmZjgwNjUzNzllIGluIG5ldGlzcl9kaXNwYXRj aF9zcmMgKHByb3RvPTEsIHNvdXJjZT1WYXJpYWJsZSAic291cmNlIiBpcyBub3QgYXZhaWxh YmxlLgopCiAgICBhdCAvdXNyL3NyYy9zeXMvbmV0L25ldGlzci5jOjkxNwojMTMgMHhmZmZm ZmZmZjgwNjQ5YzJkIGluIGV0aGVyX2RlbXV4IChpZnA9MHhmZmZmZmYwMDA1NTcyMDAwLCAK ICAgIG09MHhmZmZmZmYwMDA1Yzk0ZTAwKSBhdCAvdXNyL3NyYy9zeXMvbmV0L2lmX2V0aGVy c3Vici5jOjkwMQojMTQgMHhmZmZmZmZmZjgwNjQ5ZmY3IGluIGV0aGVyX2lucHV0IChpZnA9 MHhmZmZmZmYwMDA1NTcyMDAwLCAKICAgIG09MHhmZmZmZmYwMDA1Yzk0ZTAwKSBhdCAvdXNy L3NyYy9zeXMvbmV0L2lmX2V0aGVyc3Vici5jOjc2MAojMTUgMHhmZmZmZmZmZjgwNjQ5YjRm IGluIGV0aGVyX2RlbXV4IChpZnA9MHhmZmZmZmYwMDAzMDZlODAwLCAKICAgIG09MHhmZmZm ZmYwMDA1Yzk0ZTAwKSBhdCAvdXNyL3NyYy9zeXMvbmV0L2lmX2V0aGVyc3Vici5jOjgxMAoj MTYgMHhmZmZmZmZmZjgwNjQ5ZmY3IGluIGV0aGVyX2lucHV0IChpZnA9MHhmZmZmZmYwMDAz MDZlODAwLCAKICAgIG09MHhmZmZmZmYwMDA1Yzk0ZTAwKSBhdCAvdXNyL3NyYy9zeXMvbmV0 L2lmX2V0aGVyc3Vici5jOjc2MAojMTcgMHhmZmZmZmZmZjgxMDNiMjM1IGluIGVtX3JlZnJl c2hfbWJ1ZnMgKHJ4cj0weGZmZmZmZjAwMDMxYTI3YzAsIAogICAgbGltaXQ9LTEwNjI3Mjcz MTEpIGF0IC91c3Ivc3JjL3N5cy9tb2R1bGVzL2VtLy4uLy4uL2Rldi9lMTAwMC9pZl9lbS5j OjM2ODAKIzE4IDB4ZmZmZmZmZmY4MTAzYjQ1MiBpbiBlbV9yZWZyZXNoX21idWZzIChyeHI9 MHhmZmZmZmYwMDAzMDZlODAwLCBsaW1pdD0xKQogICAgYXQgbWJ1Zi5oOjU2NAojMTkgMHhm ZmZmZmZmZjgwNTczMmZkIGluIGludHJfZXZlbnRfZXhlY3V0ZV9oYW5kbGVycyAocD1WYXJp YWJsZSAicCIgaXMgbm90IGF2YWlsYWJsZS4KKQogICAgYXQgL3Vzci9zcmMvc3lzL2tlcm4v a2Vybl9pbnRyLmM6MTIyMAojMjAgMHhmZmZmZmZmZjgwNTc0OWFlIGluIGl0aHJlYWRfbG9v cCAoYXJnPTB4ZmZmZmZmMDAwMzE4ZjZhMCkKICAgIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tl cm5faW50ci5jOjEyMzMKIzIxIDB4ZmZmZmZmZmY4MDU3MTJiOCBpbiBmb3JrX2V4aXQgKAog ICAgY2FsbG91dD0weGZmZmZmZmZmODA1NzQ5MjAgPGl0aHJlYWRfbG9vcD4sIGFyZz0weGZm ZmZmZjAwMDMxOGY2YTAsIAogICAgZnJhbWU9MHhmZmZmZmY4MWIxYzg4YzgwKSBhdCAvdXNy L3NyYy9zeXMva2Vybi9rZXJuX2ZvcmsuYzo4NDQKIzIyIDB4ZmZmZmZmZmY4MDg3YWJkZSBp biBmb3JrX3RyYW1wb2xpbmUgKCkKICAgIGF0IC91c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC9l eGNlcHRpb24uUzo1NjIKIzIzIDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQojMjQgMHgw MDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCiMyNSAweDAwMDAwMDAwMDAwMDAwMDEgaW4gPz8g KCkKIzI2IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQojMjcgMHgwMDAwMDAwMDAwMDAw MDAwIGluID8/ICgpCiMyOCAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKIzI5IDB4MDAw MDAwMDAwMDAwMDAwMCBpbiA/PyAoKQojMzAgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgp CiMzMSAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKIzMyIDB4MDAwMDAwMDAwMDAwMDAw MCBpbiA/PyAoKQojMzMgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCiMzNCAweDAwMDAw MDAwMDAwMDAwMDAgaW4gPz8gKCkKIzM1IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQoj MzYgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCiMzNyAweDAwMDAwMDAwMDAwMDAwMDAg aW4gPz8gKCkKIzM4IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQojMzkgMHgwMDAwMDAw MDAwMDAwMDAwIGluID8/ICgpCiM0MCAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKIzQx IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQojNDIgMHgwMDAwMDAwMDAwMDAwMDAwIGlu ID8/ICgpCiM0MyAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKIzQ0IDB4MDAwMDAwMDAw MDAwMDAwMCBpbiA/PyAoKQojNDUgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCiM0NiAw eDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKIzQ3IDB4MDAwMDAwMDAwMTBjYzAwMCBpbiA/ PyAoKQojNDggMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCiM0OSAweDAwMDAwMDAwMDAw MDAwMDAgaW4gPz8gKCkKIzUwIDB4ZmZmZmZmZmY4MGM1OTQ1OCBpbiBzbGVlcHFfY2hhaW5z ICgpCiM1MSAweGZmZmZmZjAwMDJlZWI3YzAgaW4gPz8gKCkKIzUyIDB4ZmZmZmZmODFiMWM4 N2U2MCBpbiA/PyAoKQojNTMgMHhmZmZmZmY4MWIxYzg3ZTE4IGluID8/ICgpCiM1NCAweGZm ZmZmZjAwMDMxYTI3YzAgaW4gPz8gKCkKIzU1IDB4ZmZmZmZmZmY4MDViZWI5YSBpbiBzY2hl ZF9zd2l0Y2ggKHRkPTB4ZmZmZmZmMDAwMzE4ZjZhMCwgCiAgICBuZXd0ZD0weGZmZmZmZmZm ODA1NzQ5MjAsIGZsYWdzPVZhcmlhYmxlICJmbGFncyIgaXMgbm90IGF2YWlsYWJsZS4KKSBh dCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoxODQ0ClByZXZpb3VzIGZyYW1lIGlu bmVyIHRvIHRoaXMgZnJhbWUgKGNvcnJ1cHQgc3RhY2s/KQooa2dkYikgCgotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0KcHMgLWF4bAoKICBVSUQgICBQSUQgIFBQSUQgQ1BVIFBSSSBOSSAgIFZTWiAg IFJTUyBNV0NIQU4gU1RBVCAgVFQgICAgICAgVElNRSBDT01NQU5ECiAgICAwICAgICAwICAg ICAwICAgMCAtNjggIDAgICAgIDAgICAgIDAgLSAgICAgIFJMcyAgID8/ICAyOTc3MTMyNjE4 NzE6MjguMTQgW2tlcm5lbF0KICAgIDAgICAgIDEgICAgIDAgICAwICA0NiAgMCAgMzIwNCAg ICAgMCB3YWl0ICAgRExzICAgPz8gIDIzNjE2OTg2NToxOS4wMCBbaW5pdF0KICAgIDAgICAg IDIgICAgIDAgICAwICAtOCAgMCAgICAgMCAgICAgMCAtICAgICAgUkwgICAgPz8gIDExNDkx NzcwNjk6NDcuMDAgW2dfZXZlbnRdCiAgICAwICAgICAzICAgICAwICAgMCAgLTggIDAgICAg IDAgICAgIDAgLSAgICAgIERMICAgID8/ICAxNDIwNDAwMDI1OjA1LjAwIFtnX3VwXQogICAg MCAgICAgNCAgICAgMCAgIDAgIC04ICAwICAgICAwICAgICAwIC0gICAgICBETCAgICA/PyAg MTMxNzM2MDgxMToxMC4wMCBbZ19kb3duXQogICAgMCAgICAgNSAgICAgMCAgIDAgIC04ICAw ICAgICAwICAgICAwIC0gICAgICBSTCAgICA/PyAgMjc0MzI5Njk5OjAzLjAwIFt6ZnNrZXJu XQogICAgMCAgICAgNiAgICAgMCAgIDAgLTE2ICAwICAgICAwICAgICAwIHdhaXRpbiBETCAg ICA/PyAgMzcxMjoxMi4wMCBbc2N0cF9pdGVyYQogICAgMCAgICAgNyAgICAgMCAgIDAgIDc2 ICAwICAgICAwICAgICAwIGNjYl9zYyBETCAgICA/PyAgIDY5OjE2LjAwIFt4cHRfdGhyZF0K ICAgIDAgICAgIDggICAgIDAgICAwICAtOCAgMCAgICAgMCAgICAgMCBtOncxICAgREwgICAg Pz8gIDExMDcyMTA1NTU6MzQuMDAgW2dfbWlycm9yIGcKICAgIDAgICAgIDkgICAgIDAgICAw ICA0NCAgMCAgICAgMCAgICAgMCBwc2xlZXAgREwgICAgPz8gIDUwMzg2MDEyOjI1LjAwIFtw YWdlZGFlbW9uCiAgICAwICAgIDEwICAgICAwICAgMCAtMTYgIDAgICAgIDAgICAgIDAgYXVk aXRfIERMICAgID8/ICAgIDA6MDAuMDAgW2F1ZGl0XQogICAgMCAgICAxMSAgICAgMCAgIDAg MTcxICAwICAgICAwICAgICAwIC0gICAgICBSTCAgICA/PyAgNTEwNTM4MDg5Nzg6NDAuODkg W2lkbGVdCiAgICAwICAgIDEyICAgICAwICAgMCAtNDggIDAgICAgIDAgICAgIDAgLSAgICAg IFdMICAgID8/ICA5MTE2NjEwNTgxMToxOC40MiBbaW50cl0KICAgIDAgICAgMTMgICAgIDAg ICAwICA0NCAgMCAgICAgMCAgICAgMCAtICAgICAgREwgICAgPz8gIDg2OTYxMTY4Mzg4OjU0 LjAwIFt5YXJyb3ddCiAgICAwICAgIDE0ICAgICAwICAgMCAtNjQgIDAgICAgIDAgICAgIDAg VVNCIGRlIExMICAgID8/ICAyMTc4NzUwMDIxOjQ0LjAwIFt1c2JdCiAgICAwICAgIDE1ICAg ICAwICAgMCAtMTYgIDAgICAgIDAgICAgIDAgcHNsZWVwIERMICAgID8/ICAxMTY6MTYuMDAg W3ZtZGFlbW9uXQogICAgMCAgICAxNiAgICAgMCAgIDAgIDc2ICAwICAgICAwICAgICAwIHBn emVybyBETCAgICA/PyAgNDI1NjQxOjA2LjAwIFtwYWdlemVyb10KICAgIDAgICAgMTcgICAg IDAgICAwICA3NiAgMCAgICAgMCAgICAgMCAtICAgICAgUkwgICAgPz8gIDM4MzQ0MzYxOjQ5 LjAwIFtpZGxlcG9sbF0KICAgIDAgICAgMTggICAgIDAgICAwICA0NCAgMCAgICAgMCAgICAg MCBwc2xlZXAgREwgICAgPz8gIDExODg0ODg1MDowNy4wMCBbYnVmZGFlbW9uXQogICAgMCAg ICAxOSAgICAgMCAgIDAgIDQ0ICAwICAgICAwICAgICAwIC0gICAgICBSTCAgICA/PyAgMzQz MzYwOTY5ODY6MDMuMDAgW3N5bmNlcl0KICAgIDAgICAgMjAgICAgIDAgICAwICA0NCAgMCAg ICAgMCAgICAgMCB2bHJ1d3QgREwgICAgPz8gIDEyNTA1MzkwOToyMC4wMCBbdm5scnVdCiAg ICAwICAgIDIxICAgICAwICAgMCAgNDQgIDAgICAgIDAgICAgIDAgLSAgICAgIFJMICAgID8/ ICAyODY5MjUyMTE6MDAuMDAgW3NvZnRkZXBmbHUKICAgIDAgICAgMjIgICAgIDAgICAwIC0x NiAgMCAgICAgMCAgICAgMCAtICAgICAgUkwgICAgPz8gIDIwMDI2MzY3MzozNy4wMCBbZmxv d2NsZWFuZQogICAgMCAgIDk2MyAgICAgMSAgIDAgIDc2ICAwICA4MDQ0ICAgICAwIHNlbGVj dCBEcyAgICA/PyAgNDQ5Njo0MC4wMCBbbW91c2VkXQogICAgMCAgMTQzMCAgICAgMSAgIDAg IDQ0ICAwICAzMjA0ICAgICAwIHNlbGVjdCBEcyAgICA/PyAgMTIxMTE3MjY6MTUuMDAgW2Rl dmRdCiAgICAwICAyMjg4ICAgICAxICAgMCAgIDEgIDAgIDcwMjQgICAgIDAgLSAgICAgIFJz ICAgID8/ICAxMDI4MjgzODAwOjU5LjAwIFtzeXNsb2dkXQogICA1MyAgMjUxMSAgICAgMSAg IDAgIDQ0ICAwIDI0Nzk2MCAgICAgMCBrcXJlYWQgRHMgICAgPz8gIDI0Nzk2MTkyNDA4NTo1 Mi4wMCBbbmFtZWRdCiAgICAwICAyOTQ2ICAgICAxICAgMCAgNDQgIDAgIDkyMDAgICAgIDAg LSAgICAgIFJzICAgID8/ICA0MjM0NDUzODg5OjEwLjAwIFtudHBkXQogICAgMCAgMzAyNiAg ICAgMSAgIDAgIDUwICAwIDI1MjQ0ICAgICAwIHNlbGVjdCBEcyAgICA/PyAgNTA4Mzg3NDMx MTo0Ni4wMCBbc3NoZF0KICAgIDAgIDMwNTQgICAgIDEgICAwICA3NiAgMCAgNzk1MiAgICAg MCAtICAgICAgUnMgICAgPz8gIDIxNDY1OTkwNjo0MC4wMCBbY3Jvbl0KICAgIDAgIDMxMDIg ICAgIDEgICAwICA3NiAgMCAgOTAwOCAgICAgMCBzZWxlY3QgRHMgICAgPz8gIDQwODgyOjA0 LjAwIFtpbmV0ZF0KICAgIDAgIDMxMzYgICAgIDEgICAwICA3NiAgMCAgNjg5MiAgICAgMCB0 dHlpbiAgRHMrICAgPz8gIDEwMDUyMTowOS4wMCBbZ2V0dHldCiAgICAwICAzMTM3ICAgICAx ICAgMCAgNzYgIDAgIDY4OTIgICAgIDAgdHR5aW4gIERzKyAgID8/ICA2OTI3OToxMy4wMCBb Z2V0dHldCiAgICAwICAzMTM4ICAgICAxICAgMCAgNzYgIDAgIDY4OTIgICAgIDAgdHR5aW4g IERzKyAgID8/ICA4MDg2NzoyMy4wMCBbZ2V0dHldCiAgICAwICAzMTM5ICAgICAxICAgMCAg NzYgIDAgIDY4OTIgICAgIDAgdHR5aW4gIERzKyAgID8/ICA4Nzg5Mjo1NC4wMCBbZ2V0dHld CiAgICAwICAzMTQwICAgICAxICAgMCAgNzYgIDAgIDY4OTIgICAgIDAgdHR5aW4gIERzKyAg ID8/ICA5NzcyNTowOS4wMCBbZ2V0dHldCiAgICAwICAzMTQxICAgICAxICAgMCAgNzYgIDAg IDY4OTIgICAgIDAgdHR5aW4gIERzKyAgID8/ICA5MTEyODoyNi4wMCBbZ2V0dHldCiAgICAw ICAzMTQyICAgICAxICAgMCAgNzYgIDAgIDY4OTIgICAgIDAgdHR5aW4gIERzKyAgID8/ICA5 NzkwMjo0MC4wMCBbZ2V0dHldCiAgICAwICAzMTQzICAgICAxICAgMCAgNzYgIDAgIDY4OTIg ICAgIDAgdHR5aW4gIERzKyAgID8/ICA5NTI0MjozMy4wMCBbZ2V0dHldCiAgICAwICAzMTQ0 ICAgICAxICAgMCAgNDQgIDAgIDY4OTIgICAgIDAgdHR5aW4gIERzKyAgID8/ICAxMTEyNDg2 OTo0Ni4wMCBbZ2V0dHldCiAgICAwICAzMTQ1ICAgICAxICAgMCAgNzYgIDAgIDY4OTIgICAg IDAgdHR5ZGNkIEQgICAgID8/ICA4Mzk1MDoyMS4wMCBbZ2V0dHldCiAgICAwIDIxMzU3ICAg ICAwICAgMCAgNDQgIDAgICAgIDAgICAgIDAgaXBtaXJlIERMICAgID8/ICAzNzQ0MDgwOjAw LjAwIFtpcG1pMDoga2NzCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0Kdm1zdGF0IC1zCgozNjIzMzE0 MTM0IGNwdSBjb250ZXh0IHN3aXRjaGVzCjE5NDk1NDAwNjUgZGV2aWNlIGludGVycnVwdHMK MTQ3OTk0OTE2MSBzb2Z0d2FyZSBpbnRlcnJ1cHRzCjQ1NzU0MTYxOSB0cmFwcwoyMDg3Njcx NDExIHN5c3RlbSBjYWxscwogICAgICAgMjMga2VybmVsIHRocmVhZHMgY3JlYXRlZAogIDE3 MzMyNjAgIGZvcmsoKSBjYWxscwogICAxNDExMDQgdmZvcmsoKSBjYWxscwogICAgICAgIDAg cmZvcmsoKSBjYWxscwogICAgICAgIDAgc3dhcCBwYWdlciBwYWdlaW5zCiAgICAgICAgMCBz d2FwIHBhZ2VyIHBhZ2VzIHBhZ2VkIGluCiAgICAgICAgMCBzd2FwIHBhZ2VyIHBhZ2VvdXRz CiAgICAgICAgMCBzd2FwIHBhZ2VyIHBhZ2VzIHBhZ2VkIG91dAogICAgIDIyMjUgdm5vZGUg cGFnZXIgcGFnZWlucwogICAgMTU0MzYgdm5vZGUgcGFnZXIgcGFnZXMgcGFnZWQgaW4KICAg ICAgICAwIHZub2RlIHBhZ2VyIHBhZ2VvdXRzCiAgICAgICAgMCB2bm9kZSBwYWdlciBwYWdl cyBwYWdlZCBvdXQKICAgICAgMTAwIHBhZ2UgZGFlbW9uIHdha2V1cHMKICAyNDUwNzMwIHBh Z2VzIGV4YW1pbmVkIGJ5IHRoZSBwYWdlIGRhZW1vbgogICAgIDQwMTIgcGFnZXMgcmVhY3Rp dmF0ZWQKMTY3MDUxMDI3IGNvcHktb24td3JpdGUgZmF1bHRzCiAgICAxNDQwOCBjb3B5LW9u LXdyaXRlIG9wdGltaXplZCBmYXVsdHMKMTcwNDY1MTYxIHplcm8gZmlsbCBwYWdlcyB6ZXJv ZWQKICAgIDE4NTU1IHplcm8gZmlsbCBwYWdlcyBwcmV6ZXJvZWQKICAgMTUzOTA0IGludHJh bnNpdCBibG9ja2luZyBwYWdlIGZhdWx0cwo0MjI1Mjk2NzMgdG90YWwgVk0gZmF1bHRzIHRh a2VuCiAgICAgICAgMCBwYWdlcyBhZmZlY3RlZCBieSBrZXJuZWwgdGhyZWFkIGNyZWF0aW9u CjM4Mzk3OTEzMiBwYWdlcyBhZmZlY3RlZCBieSAgZm9yaygpCiAzNDc2NzM3MSBwYWdlcyBh ZmZlY3RlZCBieSB2Zm9yaygpCiAgICAgICAgMCBwYWdlcyBhZmZlY3RlZCBieSByZm9yaygp CiAgMjQyOTIzNCBwYWdlcyBjYWNoZWQKNDE1MTUzMjkwIHBhZ2VzIGZyZWVkCiAgICAgICAg MCBwYWdlcyBmcmVlZCBieSBkYWVtb24KMjUzODc2OTM0IHBhZ2VzIGZyZWVkIGJ5IGV4aXRp bmcgcHJvY2Vzc2VzCiAgICA1MTMyNSBwYWdlcyBhY3RpdmUKICAgNzU4MzcyIHBhZ2VzIGlu YWN0aXZlCiAgICA0NTA4OSBwYWdlcyBpbiBWTSBjYWNoZQogICAxMzQxMDggcGFnZXMgd2ly ZWQgZG93bgogICAgIDM4NzcgcGFnZXMgZnJlZQogICAgIDQwOTYgYnl0ZXMgcGVyIHBhZ2UK Mjk1MjM2MjcwIHRvdGFsIG5hbWUgbG9va3VwcwogICAgICAgICAgY2FjaGUgaGl0cyAoNzgl IHBvcyArIDE3JSBuZWcpIHN5c3RlbSAwJSBwZXItZGlyZWN0b3J5CiAgICAgICAgICBkZWxl dGlvbnMgMCUsIGZhbHNlaGl0cyAwJSwgdG9vbG9uZyAwJQoKLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t CnZtc3RhdCAtbQoKICAgICAgICAgVHlwZSBJblVzZSBNZW1Vc2UgSGlnaFVzZSBSZXF1ZXN0 cyAgU2l6ZShzKQogICAgICAgIHNpZ2lvICAgICAxICAgICAxSyAgICAgICAtICAgICAgICAx ICA2NAogICAgIGZpbGVkZXNjICAgIDUyICAgIDUzSyAgICAgICAtICAxOTc1MzYzICAxNiwz Miw2NCwxMjgsNTEyLDEwMjQsMjA0OCw0MDk2CiAgICAgICAgIGtlbnYgICAgNzggICAgMTFL ICAgICAgIC0gICAgICAgODUgIDE2LDMyLDY0LDEyOAogICAgICAga3F1ZXVlICAgICAyICAg ICA5SyAgICAgICAtICAzMTczMjA1ICAyNTYsMjA0OAogICAgICBhY3BpZGV2ICAgMTA1ICAg ICA3SyAgICAgICAtICAgICAgMTA1ICA2NAogICAgcHJvYy1hcmdzICAgIDE5ICAgICAySyAg ICAgICAtICAzNjkzNDI0ICAxNiwzMiw2NCwxMjgsMjU2CiAgICAgIGl0aHJlYWQgICAgOTcg ICAgMTZLICAgICAgIC0gICAgICAgOTcgIDMyLDEyOCwyNTYKICAgICAgIEtUUkFDRSAgIDEw MCAgICAxM0sgICAgICAgLSAgICAgIDEwMCAgMTI4CiAgIENBTSBwZXJpcGggICAgIDYgICAg IDJLICAgICAgIC0gICAgICAgMjIgIDE2LDMyLDY0LDEyOCwyNTYKICAgICAgIGxpbmtlciAg IDE3MyAgICA2NUsgICAgICAgLSAgICAgIDIxMCAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAy NCwyMDQ4LDQwOTYKICAgICAgICBsb2NrZiAgICAxNyAgICAgMksgICAgICAgLSAgICAgIDE5 MyAgNjQsMTI4CiAgICAgICBpcDZuZHAgICAgNTEgICAgIDRLICAgICAgIC0gICAgICAgNTEg IDY0LDEyOAogICAgICAgaXA2b3B0ICAgICAwICAgICAwSyAgICAgICAtICAgMjA0MzI3ICAy NTYKICAgICAgICAgdGVtcCAgIDIzNCAgICAyM0sgICAgICAgLSAgNjUzMTUzMCAgMTYsMzIs NjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYKICAgICAgIGRldmJ1ZiAxODMyNCA0MDI1 M0sgICAgICAgLSAgICAxODYzMyAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQw OTYKICAgICBwY2lfbGluayAgICAxNiAgICAgMksgICAgICAgLSAgICAgICAxNiAgNjQsMTI4 CiAgICAgICBtb2R1bGUgICA0MjcgICAgNTRLICAgICAgIC0gICAgICA0MjcgIDEyOAogICAg IG10eF9wb29sICAgICAyICAgIDE2SyAgICAgICAtICAgICAgICAyICAKICAgIGFjcGlfcGVy ZiAgICAgOCAgICAgNEsgICAgICAgLSAgICAgICAgOCAgNTEyCiAgICAgICAgICBvc2QgICAg IDMgICAgIDFLICAgICAgIC0gICAgICAgIDQgIDE2LDY0CiAgICAgIHN1YnByb2MgIDE3ODEg IDEwMzhLICAgICAgIC0gIDE4NzYxMjcgIDUxMiw0MDk2CiAgICAgICAgIHByb2MgICAgIDIg ICAgMTZLICAgICAgIC0gICAgICAgIDIgIAogICAgICBzZXNzaW9uICAgIDE4ICAgICAzSyAg ICAgICAtICAgNTM2NTQ5ICAxMjgKICAgICAgICAgcGdycCAgICAxOCAgICAgM0sgICAgICAg LSAgIDUzNzYyNSAgMTI4CiAgICAgICAgIGNyZWQgICAgMjYgICAgIDVLICAgICAgIC0gMTAx Mzc3MDUwICA2NCwyNTYKICAgICAgdWlkaW5mbyAgICAgMyAgICAgM0sgICAgICAgLSAgICAy OTc2OSAgMTI4LDIwNDgKICAgICAgIHBsaW1pdCAgICAxMyAgICAgNEsgICAgICAgLSAgIDc2 NjQzMiAgMjU2CiAgICBzeXNjdGx0bXAgICAgIDAgICAgIDBLICAgICAgIC0gICA2MzQyNzgg IDE2LDMyLDY0LDEyOCwyNTYsNDA5NgogICAgc3lzY3Rsb2lkICAzOTM0ICAgMTk0SyAgICAg ICAtICAgICA0MDYxICAxNiwzMiw2NCwxMjgKICAgICAgIHN5c2N0bCAgICAgMCAgICAgMEsg ICAgICAgLSAgMjc4NjA1MCAgMTYsMzIsNjQKICAgICAgY2FsbG91dCAgICAgNyAgMzU4NEsg ICAgICAgLSAgICAgICAgNyAgCiAgICAgICAgIHVtdHggIDE5MDAgICAyMzhLICAgICAgIC0g ICAgIDE5MDAgIDEyOAogICAgIHAxMDAzLjFiICAgICAxICAgICAxSyAgICAgICAtICAgICAg ICAxICAxNgogICAgICAgICBTV0FQICAgICAyICAxMDk3SyAgICAgICAtICAgICAgICAyICA2 NAogICAgICAgYnVzLXNjICAgIDg2ICAgMTk5SyAgICAgICAtICAgICA2NTIwICAxNiwzMiw2 NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5NgogICAgICAgICAgYnVzICAxMTQ0ICAgMTA4 SyAgICAgICAtICAgIDEwNDg0ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0CiAgICAgIGRl dnN0YXQgICAgIDggICAgMTdLICAgICAgIC0gICAgICAgIDggIDMyLDQwOTYKIGV2ZW50aGFu ZGxlciAgICA4MSAgICAgN0sgICAgICAgLSAgICAgICA4MSAgNjQsMTI4CiAgICAgICBhY3Bp Y2EgIDkyMzggICA5MjhLICAgICAgIC0gICAxOTAzNTMgIDE2LDMyLDY0LDEyOCwyNTYsNTEy LDEwMjQsMjA0OAogICAgICAgICBrb2JqICAgMjkzICAxMTcySyAgICAgICAtICAgICAgMzQ1 ICA0MDk2CiAgICAgIFBlci1jcHUgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEgIDMy CiAgICAgYWNwaXRhc2sgICAgIDEgICAgIDJLICAgICAgIC0gICAgICAgIDEgIDIwNDgKICAg ICAgICAgcm1hbiAgIDE2MyAgICAyMEsgICAgICAgLSAgICAgIDYzNiAgMTYsMzIsMTI4CiAg ICAgICAgIHNidWYgICAgIDAgICAgIDBLICAgICAgIC0gICAgICA3NzEgIDE2LDMyLDY0LDEy OCwyNTYsNTEyLDEwMjQsMjA0OCw0MDk2CiAgICAgIGVudHJvcHkgIDEwMjQgICAgNjRLICAg ICAgIC0gICAgIDEwMjQgIDY0CiAgICAgICAgc3RhY2sgICAgIDAgICAgIDBLICAgICAgIC0g ICAgICAgIDIgIDI1NgogICAgdGFza3F1ZXVlICAgIDI3ICAgICAzSyAgICAgICAtICAgICAg IDI3ICAxNiwzMiw2NCwxMjgKICAgICAgIFVuaXRubyAgICAxMSAgICAgMUsgICAgICAgLSAg ICAgIDYxMyAgMzIsNjQKICAgICAgICAgIGlvdiAgICAgMCAgICAgMEsgICAgICAgLSAxNDcy MTE4NTkgIDE2LDY0LDEyOCwyNTYsNTEyCiAgICAgICBzZWxlY3QgIDE3MTAgICAyMTRLICAg ICAgIC0gICAgIDE3MTAgIDEyOAogICAgIGlvY3Rsb3BzICAgICAwICAgICAwSyAgICAgICAt ICAxNTU0MDczICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0CiAgICAgICAgICBtc2cgICAg IDQgICAgMzBLICAgICAgIC0gICAgICAgIDQgIDIwNDgsNDA5NgogICAgICAgICAgc2VtICAg ICA0ICAgIDExSyAgICAgICAtICAgICAgICA0ICA1MTIsMTAyNAogICAgICAgICAgc2htICAg ICAxICAgIDIwSyAgICAgICAtICAgICAgICAxICAKICAgICAgICAgIHR0eSAgICAyMSAgICAy MUsgICAgICAgLSAgICAgIDEyNCAgMTAyNCwyMDQ4CiAgICAgICAgICBwdHMgICAgIDAgICAg IDBLICAgICAgIC0gICAgICAxMDEgIDI1NgogICAgIG1idWZfdGFnICAgMjk3ICAgIDc0SyAg ICAgICAtIDIxMzg4NDI0OTU2ICAzMiw2NCwxMjgsMjU2CiAgICAgICAgIGtzZW0gICAgIDEg ICAgIDhLICAgICAgIC0gICAgICAgIDEgIAogICAgICAgIHNobWZkICAgICAxICAgICA4SyAg ICAgICAtICAgICAgICAxICAKICAgICAgICAgIHBjYiAgICAyMiAgIDE1N0sgICAgICAgLSAx NDQ4NTY1MiAgMTYsMzIsMTI4LDEwMjQsMjA0OCw0MDk2CiAgICAgICBzb25hbWUgICAgIDUg ICAgIDFLICAgICAgIC0gMTA4Njk5MDQ3ICAxNiwzMiw2NCwxMjgKICAgICAgICAgIGFjbCAg ICAgMCAgICAgMEsgICAgICAgLSAgICAxNzEzMCAgNDA5NgogICAgICAgYmlvYnVmICAgICAw ICAgICAwSyAgICAgICAtICAgIDEzNDY5ICAyMDQ4CiAgICAgdmZzY2FjaGUgICAgIDEgIDEw MjRLICAgICAgIC0gICAgICAgIDEgIAogICBjbF9zYXZlYnVmICAgICAwICAgICAwSyAgICAg ICAtICAgMjg3ODY3ICA2NCwxMjgKICAgICB2ZnNfaGFzaCAgICAgMSAgIDUxMksgICAgICAg LSAgICAgICAgMSAgCiAgICAgICB2bm9kZXMgICAgIDIgICAgIDFLICAgICAgIC0gICAgICAg IDUgIDY0LDI1NgogICAgICBDQU0gWFBUICAgMTE4ICAgMTU3SyAgICAgICAtICAgICAgMjAy ICAzMiw2NCwxMjgsMTAyNCwyMDQ4CiAgdm5vZGVtYXJrZXIgICAgIDAgICAgIDBLICAgICAg IC0gICA0MjM5NTUgIDUxMgogICAgICAgIG1vdW50ICAgIDgyICAgICA0SyAgICAgICAtICAg ICAgMTI2ICAxNiwzMiw2NCwxMjgsMjU2CiAgICAgICAgICBCUEYgICAgNTAgICAgIDdLICAg ICAgIC0gICAgICAgNTUgIDE2LDEyOCw1MTIKICBldGhlcl9tdWx0aSAgIDI0MiAgICAxM0sg ICAgICAgLSAgICAgIDI4OCAgMTYsMzIsNjQKICAgICAgIGlmYWRkciAgIDM2MSAgICA5NEsg ICAgICAgLSAgICAgIDM3NCAgMzIsNjQsMTI4LDI1Niw1MTIsNDA5NgogICAgICAgIGlmbmV0 ICAgIDUxICAgMTAxSyAgICAgICAtICAgICAgIDUzICAxMjgsMjU2LDUxMiwyMDQ4CiAgICAg ICAgY2xvbmUgICAgIDYgICAgMjRLICAgICAgIC0gICAgICAgIDYgIDQwOTYKICAgICAgIGFy cGNvbSAgICA0OSAgICAgMUsgICAgICAgLSAgICAgICA0OSAgMTYKICAgICAgbGx0YWJsZSAg IDIwOCAgICA3N0sgICAgICAgLSAgIDM1ODE5NSAgMjU2LDUxMgogICAgICAgICB2bGFuICAg IDk0ICAgICA0SyAgICAgICAtICAgICAgIDk0ICAxNiw2NCwxMjgKICAgICAgICAgVUFSVCAg ICAgNiAgICAgNEsgICAgICAgLSAgICAgICAgNiAgMTYsNTEyLDEwMjQKICAgICAgYWNwaXNl bSAgICAxNCAgICAgMksgICAgICAgLSAgICAgICAxNCAgMTI4CiAgICAgICBVU0JkZXYgICAg MjYgICAgMTFLICAgICAgIC0gICAgICAgMjYgIDY0LDEyOCw1MTIsMTAyNCw0MDk2CiAgICAg ICAgICBVU0IgICAgNDIgICAgNDZLICAgICAgIC0gICAgICAgNDggIDE2LDMyLDY0LDEyOCwy NTYsMjA0OCw0MDk2CiAgICAgcm91dGV0YmwgICAzMjkgIDIxMzlLICAgICAgIC0gICAgMTE1 NDkgIDMyLDY0LDEyOCwyNTYsNTEyCiAgICAgICAgIGlnbXAgICAgNTAgICAgMTNLICAgICAg IC0gICAgICAgNTAgIDI1NgogICAgICAgICBpcGlkICAgICAyICAgIDI0SyAgICAgICAtICAg ICAgICAyICAKICAgICBpbl9tdWx0aSAgICA0NyAgICAxMksgICAgICAgLSAgICAgICA0NyAg MjU2CiAgICAgZHVtbXluZXQgICAgIDMgICAgIDZLICAgICAgIC0gICAgICAgIDYgIDUxMiwx MDI0LDIwNDgsNDA5NgogICAgIGR1bW15bmV0ICA5MDU0ICA0NTI3SyAgICAgICAtIDE3NTc4 MTY0OTUgIDE2LDI1Niw1MTIsMTAyNAogIElwRncvSXBBY2N0ICAgIDMxICAgICA0SyAgICAg ICAtICAgICAgIDYwICAxNiwzMiw2NCwxMjgsMjU2CiAgICAgaXBmd190YmwgIDMwMTAgICA3 NTNLICAgICAgIC0gICAxOTg1NjUgIDI1NgogICAgc2N0cF9pdGVyICAgICAwICAgICAwSyAg ICAgICAtICAgICAgIDQ4ICAyNTYKICAgICBzY3RwX2lmbiAgICA0NyAgICAgNksgICAgICAg LSAgICAgICA0NyAgMTI4CiAgICAgc2N0cF9pZmEgICAgNTAgICAgIDdLICAgICAgIC0gICAg ICAgNTAgIDEyOAogICAgIHNjdHBfdnJmICAgICAxICAgICAxSyAgICAgICAtICAgICAgICAx ICA2NAogICAgc2N0cF9hX2l0ICAgICAwICAgICAwSyAgICAgICAtICAgICAgIDQ4ICAxNgog ICAgaG9zdGNhY2hlICAgICAxICAgIDI4SyAgICAgICAtICAgICAgICAxICAKICAgICBzeW5j YWNoZSAgICAgMSAgICA5NksgICAgICAgLSAgICAgICAgMSAgCiAgICBpbjZfbXVsdGkgICAg MTIgICAgIDJLICAgICAgIC0gICAgICAgMTIgIDMyLDI1NgogICAgICAgREVWRlMxICAgIDk5 ICAgIDUwSyAgICAgICAtICAgICAgMjA4ICA1MTIKICAgICAgIERFVkZTMyAgIDIzOSAgICA2 MEsgICAgICAgLSAgICAgIDM3MiAgMjU2CiAgICAgICAgICBtbGQgICAgNTAgICAgIDdLICAg ICAgIC0gICAgICAgNTAgIDEyOAogICAgICBORlMgRkhBICAgICAxICAgICAySyAgICAgICAt ICAgICAgICAxICAyMDQ4CiAgICAgICAgICBycGMgICAgIDIgICAgIDlLICAgICAgIC0gICAg ICAgIDIgIDI1NgphdWRpdF9ldmNsYXNzICAgMTcyICAgICA2SyAgICAgICAtICAgICAgMjEx ICAzMgogICAgIHNhdmVkaW5vICAgICAwICAgICAwSyAgICAgICAtICAgIDg1NjMxICAyNTYK ICAgIG5ld2RpcmJsayAgICAgMCAgICAgMEsgICAgICAgLSAgICAgIDMwMyAgNjQKICAgICAg IGRpcnJlbSAgICAgMCAgICAgMEsgICAgICAgLSAgIDE2NTM5OSAgNjQKICAgICAgICBta2Rp ciAgICAgMCAgICAgMEsgICAgICAgLSAgICAyNjkzNiAgNjQKICAgICAgIGRpcmFkZCAgICAg MSAgICAgMUsgICAgICAgLSAgIDE5NDU0NSAgNjQKICAgICBmcmVlZmlsZSAgICAgMCAgICAg MEsgICAgICAgLSAgIDEzNzI1OCAgNjQKICAgICBmcmVlYmxrcyAgICAgMCAgICAgMEsgICAg ICAgLSAgIDEzNTcwNyAgMjU2CiAgICAgZnJlZWZyYWcgICAgIDUgICAgIDFLICAgICAgIC0g ICA5OTExMDUgIDY0CiAgIGFsbG9jaW5kaXIgICAgMjYgICAgIDRLICAgICAgIC0gIDE3NjA0 NjkgIDEyOAogICAgIGluZGlyZGVwICAgICAyICAgICAxSyAgICAgICAtICAgIDg4MjU5ICA2 NAogIGFsbG9jZGlyZWN0ICAgIDEzICAgICA0SyAgICAgICAtICAxMDE2MzQ2ICAyNTYKICAg IGJtc2FmZW1hcCAgICAgNCAgICAgMUsgICAgICAgLSAgIDE2NTc3MSAgMTI4CiAgICAgICBu ZXdibGsgICAgIDEgICAgIDFLICAgICAgIC0gIDI3NzY4MTYgIDY0LDUxMgogICAgIGlub2Rl ZGVwICAgICAyICAgNTEzSyAgICAgICAtICAgMjg5ODc0ICAyNTYKICAgICAgcGFnZWRlcCAg ICAgMiAgIDEyOUsgICAgICAgLSAgICAzOTE2MyAgMTI4CiAgdWZzX2Rpcmhhc2ggICAyNjYg ICAxMzNLICAgICAgIC0gIDIwMzYyMjEgIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDQwOTYKICAg IHVmc19tb3VudCAgICAxMiAgICA1NEsgICAgICAgLSAgICAgICAxMiAgNTEyLDIwNDgsNDA5 NgogICAgICBVTUFIYXNoICAgICAzICAgIDE2SyAgICAgICAtICAgICAgIDEzICA1MTIsMTAy NCwyMDQ4LDQwOTYKICAgICAgIERFVkZTMiAgICA5OSAgICAgMksgICAgICAgLSAgICAgIDEy MiAgMTYKICAgREVWRlNfUlVMRSAgICA1MyAgICAyNUsgICAgICAgLSAgICAgICA1MyAgNjQs NTEyCiAgICAgICAgREVWRlMgICAgMjggICAgIDFLICAgICAgIC0gICAgICAgMjkgIDE2LDMy LDEyOAogICAgdm1fcGdkYXRhICAgICAyICAgMTI5SyAgICAgICAtICAgICAgICAyICAxMjgK ICAgICAgIERFVkZTUCAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMyAgNjQKICAgIHBm c19ub2RlcyAgICAyMSAgICAgNksgICAgICAgLSAgICAgICAyMSAgMjU2CiAgICAgIGlvX2Fw aWMgICAgIDEgICAgIDJLICAgICAgIC0gICAgICAgIDEgIDIwNDgKQ0FNIGRldiBxdWV1ZSAg ICAgNyAgICAgMUsgICAgICAgLSAgICAgICAgNyAgMTI4CiAgICAgICAgIEdFT00gICAgODAg ICAgMjJLICAgICAgIC0gICAgICA1NDcgIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDEwMjQKICAg IENBTSBxdWV1ZSAgICAyNSAgICAgMUsgICAgICAgLSAgICAgICA4OSAgMTYsMzIsMjU2CiAg ICAgIG1lbWRlc2MgICAgIDEgICAgIDRLICAgICAgIC0gICAgICAgIDEgIDQwOTYKICAgICAg ICAgIG1zaSAgICAgNyAgICAgMUsgICAgICAgLSAgICAgICAgNyAgMTI4CiAgICAgbmV4dXNk ZXYgICAgIDMgICAgIDFLICAgICAgIC0gICAgICAgIDMgIDE2CiAgICAgIENBTSBTSU0gICAg IDcgICAgIDJLICAgICAgIC0gICAgICAgIDcgIDI1NgogICAgICAga2JkbXV4ICAgICA2ICAg IDEwSyAgICAgICAtICAgICAgICA2ICAxNiw1MTIsMTAyNCwyMDQ4LDQwOTYKICAgICAgICAg IExFRCAgICAgMiAgICAgMUsgICAgICAgLSAgICAgICAgMiAgMTI4CiAgICAgICBpc2FkZXYg ICAgIDYgICAgIDFLICAgICAgIC0gICAgICAgIDYgIDEyOAogICAgICAgICBjZGV2ICAgICA5 ICAgICAzSyAgICAgICAtICAgICAgICA5ICAyNTYKICAgICAgc29sYXJpcyAgIDEwMCAgODcx MUsgICAgICAgLSAgICAgIDEwMiAgMTYsNjQsMTI4LDEwMjQKICAga3N0YXRfZGF0YSAgICAg MyAgICAgMUsgICAgICAgLSAgICAgICAgMyAgNjQKICBtaXJyb3JfZGF0YSAgICAgMyAgICAg MUsgICAgICAgLSAgIDQ4MzE4NSAgNjQsMTI4LDUxMgogICAgICAgICBpcG1pICAgICAwICAg ICAwSyAgICAgICAtICAgICAgIDMwICAxMjgsMjA0OAoKLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCnZt c3RhdCAtegoKSVRFTSAgICAgICAgICAgICAgICAgICAgIFNJWkUgICAgIExJTUlUICAgICAg VVNFRCAgICAgIEZSRUUgIFJFUVVFU1RTICBGQUlMVVJFUwoKVU1BIEtlZ3M6ICAgICAgICAg ICAgICAgICAyMDgsICAgICAgICAwLCAgICAgIDE4NiwgICAgICAgIDEsICAgICAgMTg2LCAg ICAgICAgMApVTUEgWm9uZXM6ICAgICAgICAgICAgICAgIDQ0OCwgICAgICAgIDAsICAgICAg MTg2LCAgICAgICAgNiwgICAgICAxODYsICAgICAgICAwClVNQSBTbGFiczogICAgICAgICAg ICAgICAgNTY4LCAgICAgICAgMCwgICAgIDM2MjksICAgICAgNjYyLCAgIDEyMTc3NiwgICAg ICAgIDAKVU1BIFJDbnRTbGFiczogICAgICAgICAgICA1NjgsICAgICAgICAwLCAgICAgMzI0 OCwgICAgICA0NzYsICAgIDI3NTA1LCAgICAgICAgMApVTUEgSGFzaDogICAgICAgICAgICAg ICAgIDI1NiwgICAgICAgIDAsICAgICAgIDc4LCAgICAgICAxMiwgICAgICAgODEsICAgICAg ICAwCjE2IEJ1Y2tldDogICAgICAgICAgICAgICAgMTUyLCAgICAgICAgMCwgICAgICAgMTIs ICAgICAgMTM4LCAgICAgIDE3OSwgICAgICAgIDAKMzIgQnVja2V0OiAgICAgICAgICAgICAg ICAyODAsICAgICAgICAwLCAgICAgICA2MSwgICAgICAxOTEsICAgICAgMzE5LCAgICAgICAg MAo2NCBCdWNrZXQ6ICAgICAgICAgICAgICAgIDUzNiwgICAgICAgIDAsICAgICAgIDUyLCAg ICAgIDEwMiwgICAgICA3MTUsICAgICAgIDU2CjEyOCBCdWNrZXQ6ICAgICAgICAgICAgICAx MDQ4LCAgICAgICAgMCwgICAgICA2MTQsICAgICAgMTQ1LCAgICAyMjQzNiwgICAgMTI5MjUK Vk0gT0JKRUNUOiAgICAgICAgICAgICAgICAyMTYsICAgICAgICAwLCAgICA2NDM4OCwgICAg MTQzNjIsIDcyMzM3MDE1LCAgICAgICAgMApNQVA6ICAgICAgICAgICAgICAgICAgICAgIDIz MiwgICAgICAgIDAsICAgICAgICA3LCAgICAgICAyNSwgICAgICAgIDcsICAgICAgICAwCktN QVAgRU5UUlk6ICAgICAgICAgICAgICAgMTIwLCAgIDE0ODgwMCwgICAgICAgMjksICAgICAg OTYzLCAgIDE3Nzk1NiwgICAgICAgIDAKTUFQIEVOVFJZOiAgICAgICAgICAgICAgICAxMjAs ICAgICAgICAwLCAgICAgIDM5OCwgICAgIDIxMTMsIDE4MzY0MTgwMywgICAgICAgIDAKRFAg ZmFrZXBnOiAgICAgICAgICAgICAgICAxMjAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAg IDAsICAgICAgICAwLCAgICAgICAgMApTRyBmYWtlcGc6ICAgICAgICAgICAgICAgIDEyMCwg ICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCm10X3pv bmU6ICAgICAgICAgICAgICAgICAyMDU2LCAgICAgICAgMCwgICAgICAyNzEsICAgICAgICA4 LCAgICAgIDI3MSwgICAgICAgIDAKMTY6ICAgICAgICAgICAgICAgICAgICAgICAgMTYsICAg ICAgICAwLCAgICAgMjIzNSwgICAgIDE2MjksIDI0NDMxMjIwMCwgICAgICAgIDAKMzI6ICAg ICAgICAgICAgICAgICAgICAgICAgMzIsICAgICAgICAwLCAgICAgMzg3MCwgICAgIDE1ODQs IDE4NjgwNTE3LCAgICAgICAgMAo2NDogICAgICAgICAgICAgICAgICAgICAgICA2NCwgICAg ICAgIDAsICAgIDEyMDUzLCAgICAgMjAwMywgODY1OTE2MjIxMiwgICAgICAgIDAKMTI4OiAg ICAgICAgICAgICAgICAgICAgICAxMjgsICAgICAgICAwLCAgICAxMjg5OCwgICAgIDQyMTIs IDE2NzgwNTkxLCAgICAgICAgMAoyNTY6ICAgICAgICAgICAgICAgICAgICAgIDI1NiwgICAg ICAgIDAsICAgICA4Njc1LCAgICAgMjk1MCwgMTI4NDU2MzY5MzcsICAgICAgICAwCjUxMjog ICAgICAgICAgICAgICAgICAgICAgNTEyLCAgICAgICAgMCwgICAgIDQ5NDYsICAgICAxMzQw LCAxNzYzODgyNzMyLCAgICAgICAgMAoxMDI0OiAgICAgICAgICAgICAgICAgICAgMTAyNCwg ICAgICAgIDAsICAgICAyMjk5LCAgICAgIDI3NywgICAyMzQ3MDIsICAgICAgICAwCjIwNDg6 ICAgICAgICAgICAgICAgICAgICAyMDQ4LCAgICAgICAgMCwgICAgICAxNzAsICAgICAxMDA4 LCAgMTYwMDY5NSwgICAgICAgIDAKNDA5NjogICAgICAgICAgICAgICAgICAgIDQwOTYsICAg ICAgICAwLCAgICAgIDM5MywgICAgIDEyMjgsICAzODg1NDE2LCAgICAgICAgMApGaWxlczog ICAgICAgICAgICAgICAgICAgICA4MCwgICAgICAgIDAsICAgICAgMTIwLCAgICAgMTY4MCwg NjQzNDU4NTgsICAgICAgICAwClRVUk5TVElMRTogICAgICAgICAgICAgICAgMTM2LCAgICAg ICAgMCwgICAgIDE5MDEsICAgICAgIDk5LCAgICAgMTkwMSwgICAgICAgIDAKdW10eCBwaTog ICAgICAgICAgICAgICAgICAgOTYsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAg ICAgICAwLCAgICAgICAgMApNQUMgbGFiZWxzOiAgICAgICAgICAgICAgICA0MCwgICAgICAg IDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwClBST0M6ICAgICAg ICAgICAgICAgICAgICAxMTIwLCAgICAgICAgMCwgICAgICAgNDEsICAgICAxNjk2LCAgMTg3 NDM4NywgICAgICAgIDAKVEhSRUFEOiAgICAgICAgICAgICAgICAgICA5ODQsICAgICAgICAw LCAgICAgMTgwNiwgICAgICAgOTQsICAgICAxODk3LCAgICAgICAgMApTTEVFUFFVRVVFOiAg ICAgICAgICAgICAgICA4MCwgICAgICAgIDAsICAgICAxOTAxLCAgICAgIDIxNiwgICAgIDE5 MDEsICAgICAgICAwClZNU1BBQ0U6ICAgICAgICAgICAgICAgICAgMzkyLCAgICAgICAgMCwg ICAgICAgMTksICAgICAxNTUxLCAgMTg3NDM2NSwgICAgICAgIDAKY3B1c2V0OiAgICAgICAg ICAgICAgICAgICAgNzIsICAgICAgICAwLCAgICAgICAgMiwgICAgICAgOTgsICAgICAgICAy LCAgICAgICAgMAphdWRpdF9yZWNvcmQ6ICAgICAgICAgICAgIDk1MiwgICAgICAgIDAsICAg ICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCm1idWZfcGFja2V0OiAgICAg ICAgICAgICAgMjU2LCAgICAgICAgMCwgICAgIDIzNDQsICAgICAyMTcxLCAxNjk1MTYxOTc0 MiwgICAgICAgIDAKbWJ1ZjogICAgICAgICAgICAgICAgICAgICAyNTYsICAgICAgICAwLCAg ICAgICAgMiwgICAgIDI2MDMsIDE2ODcwODQwNzA4LCAgICAgICAgMAptYnVmX2NsdXN0ZXI6 ICAgICAgICAgICAgMjA0OCwgICAgMjU2MDAsICAgICAzNDQwLCAgICAgMTAxOCwgNjM1MzM0 MDcxLCAgICAgICAgMAptYnVmX2p1bWJvX3BhZ2U6ICAgICAgICAgNDA5NiwgICAgMTI4MDAs ICAgICAgICAwLCAgICAgMTAxOSwgIDIzMzUwNzEsICAgICAgICAwCm1idWZfanVtYm9fOWs6 ICAgICAgICAgICA5MjE2LCAgICAxOTIwMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAg MCwgICAgICAgIDAKbWJ1Zl9qdW1ib18xNms6ICAgICAgICAgMTYzODQsICAgIDEyODAwLCAg ICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAptYnVmX2V4dF9yZWZjbnQ6 ICAgICAgICAgICAgNCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAs ICAgICAgICAwCmdfYmlvOiAgICAgICAgICAgICAgICAgICAgMjMyLCAgICAgICAgMCwgICAg ICAgIDAsICAgICAzNzQ0LCAyMTI0OTExNiwgICAgICAgIDAKdHR5aW5xOiAgICAgICAgICAg ICAgICAgICAxNjAsICAgICAgICAwLCAgICAgIDE5NSwgICAgICA1MDEsICAgICAyMjM1LCAg ICAgICAgMAp0dHlvdXRxOiAgICAgICAgICAgICAgICAgIDI1NiwgICAgICAgIDAsICAgICAg MTAzLCAgICAgIDI4NywgICAgIDExODksICAgICAgICAwCmF0YV9yZXF1ZXN0OiAgICAgICAg ICAgICAgMzIwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAg ICAgIDAKYXRhX2NvbXBvc2l0ZTogICAgICAgICAgICAzMzYsICAgICAgICAwLCAgICAgICAg MCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAp0YXNrcV96b25lOiAgICAgICAgICAg ICAgICA1NiwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAg ICAwClZOT0RFOiAgICAgICAgICAgICAgICAgICAgNDcyLCAgICAgICAgMCwgICAgODczMzgs ICAgICAzNzI2LCAxMTYzNzAxMCwgICAgICAgIDAKVk5PREVQT0xMOiAgICAgICAgICAgICAg ICAxMTIsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAg MApTIFZGUyBDYWNoZTogICAgICAgICAgICAgIDEwOCwgICAgICAgIDAsICAgIDczNzQxLCAg ICAyMzk3MiwgMTE4MjIzOTIsICAgICAgICAwCkwgVkZTIENhY2hlOiAgICAgICAgICAgICAg MzI4LCAgICAgICAgMCwgICAgMjI3MDAsICAgICAgNTgwLCAgIDQ1MzkwMSwgICAgICAgIDAK TkFNRUk6ICAgICAgICAgICAgICAgICAgIDEwMjQsICAgICAgICAwLCAgICAgICAgMCwgICAg IDExNjgsIDEyNTk2OTc1MSwgICAgICAgIDAKTkZTTU9VTlQ6ICAgICAgICAgICAgICAgICA2 MTYsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMApO RlNOT0RFOiAgICAgICAgICAgICAgICAgIDY1NiwgICAgICAgIDAsICAgICAgICAwLCAgICAg ICAgMCwgICAgICAgIDAsICAgICAgICAwCkRJUkhBU0g6ICAgICAgICAgICAgICAgICAxMDI0 LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgNTI4LCAgIDE3OTg4MSwgICAgICAgIDAKcGlw ZTogICAgICAgICAgICAgICAgICAgICA3MjgsICAgICAgICAwLCAgICAgICAgMiwgICAgIDE0 NzMsICAgODgxNjQzLCAgICAgICAgMAp6aW9fY2FjaGU6ICAgICAgICAgICAgICAgIDc3Niwg ICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnppb19i dWZfNTEyOiAgICAgICAgICAgICAgNTEyLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAw LCAgICAgICAgMCwgICAgICAgIDAKemlvX2RhdGFfYnVmXzUxMjogICAgICAgICA1MTIsICAg ICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAp6aW9fYnVm XzEwMjQ6ICAgICAgICAgICAgMTAyNCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwg ICAgICAgIDAsICAgICAgICAwCnppb19kYXRhX2J1Zl8xMDI0OiAgICAgICAxMDI0LCAgICAg ICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKemlvX2J1Zl8x NTM2OiAgICAgICAgICAgIDE1MzYsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAg ICAgICAwLCAgICAgICAgMAp6aW9fZGF0YV9idWZfMTUzNjogICAgICAgMTUzNiwgICAgICAg IDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnppb19idWZfMjA0 ODogICAgICAgICAgICAyMDQ4LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAg ICAgMCwgICAgICAgIDAKemlvX2RhdGFfYnVmXzIwNDg6ICAgICAgIDIwNDgsICAgICAgICAw LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAp6aW9fYnVmXzI1NjA6 ICAgICAgICAgICAgMjU2MCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAg IDAsICAgICAgICAwCnppb19kYXRhX2J1Zl8yNTYwOiAgICAgICAyNTYwLCAgICAgICAgMCwg ICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKemlvX2J1Zl8zMDcyOiAg ICAgICAgICAgIDMwNzIsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAw LCAgICAgICAgMAp6aW9fZGF0YV9idWZfMzA3MjogICAgICAgMzA3MiwgICAgICAgIDAsICAg ICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnppb19idWZfMzU4NDogICAg ICAgICAgICAzNTg0LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwg ICAgICAgIDAKemlvX2RhdGFfYnVmXzM1ODQ6ICAgICAgIDM1ODQsICAgICAgICAwLCAgICAg ICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAp6aW9fYnVmXzQwOTY6ICAgICAg ICAgICAgNDA5NiwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAg ICAgICAwCnppb19kYXRhX2J1Zl80MDk2OiAgICAgICA0MDk2LCAgICAgICAgMCwgICAgICAg IDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKemlvX2J1Zl81MTIwOiAgICAgICAg ICAgIDUxMjAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAg ICAgMAp6aW9fZGF0YV9idWZfNTEyMDogICAgICAgNTEyMCwgICAgICAgIDAsICAgICAgICAw LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnppb19idWZfNjE0NDogICAgICAgICAg ICA2MTQ0LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAg IDAKemlvX2RhdGFfYnVmXzYxNDQ6ICAgICAgIDYxNDQsICAgICAgICAwLCAgICAgICAgMCwg ICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAp6aW9fYnVmXzcxNjg6ICAgICAgICAgICAg NzE2OCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAw Cnppb19kYXRhX2J1Zl83MTY4OiAgICAgICA3MTY4LCAgICAgICAgMCwgICAgICAgIDAsICAg ICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKemlvX2J1Zl84MTkyOiAgICAgICAgICAgIDgx OTIsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAp6 aW9fZGF0YV9idWZfODE5MjogICAgICAgODE5MiwgICAgICAgIDAsICAgICAgICAwLCAgICAg ICAgMCwgICAgICAgIDAsICAgICAgICAwCnppb19idWZfMTAyNDA6ICAgICAgICAgIDEwMjQw LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKemlv X2RhdGFfYnVmXzEwMjQwOiAgICAgMTAyNDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAg IDAsICAgICAgICAwLCAgICAgICAgMAp6aW9fYnVmXzEyMjg4OiAgICAgICAgICAxMjI4OCwg ICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnppb19k YXRhX2J1Zl8xMjI4ODogICAgIDEyMjg4LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAw LCAgICAgICAgMCwgICAgICAgIDAKemlvX2J1Zl8xNDMzNjogICAgICAgICAgMTQzMzYsICAg ICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAp6aW9fZGF0 YV9idWZfMTQzMzY6ICAgICAxNDMzNiwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwg ICAgICAgIDAsICAgICAgICAwCnppb19idWZfMTYzODQ6ICAgICAgICAgIDE2Mzg0LCAgICAg ICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKemlvX2RhdGFf YnVmXzE2Mzg0OiAgICAgMTYzODQsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAg ICAgICAwLCAgICAgICAgMAp6aW9fYnVmXzIwNDgwOiAgICAgICAgICAyMDQ4MCwgICAgICAg IDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnppb19kYXRhX2J1 Zl8yMDQ4MDogICAgIDIwNDgwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAg ICAgMCwgICAgICAgIDAKemlvX2J1Zl8yNDU3NjogICAgICAgICAgMjQ1NzYsICAgICAgICAw LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAp6aW9fZGF0YV9idWZf MjQ1NzY6ICAgICAyNDU3NiwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAg IDAsICAgICAgICAwCnppb19idWZfMjg2NzI6ICAgICAgICAgIDI4NjcyLCAgICAgICAgMCwg ICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKemlvX2RhdGFfYnVmXzI4 NjcyOiAgICAgMjg2NzIsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAw LCAgICAgICAgMAp6aW9fYnVmXzMyNzY4OiAgICAgICAgICAzMjc2OCwgICAgICAgIDAsICAg ICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnppb19kYXRhX2J1Zl8zMjc2 ODogICAgIDMyNzY4LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwg ICAgICAgIDAKemlvX2J1Zl8zNjg2NDogICAgICAgICAgMzY4NjQsICAgICAgICAwLCAgICAg ICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAp6aW9fZGF0YV9idWZfMzY4NjQ6 ICAgICAzNjg2NCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAg ICAgICAwCnppb19idWZfNDA5NjA6ICAgICAgICAgIDQwOTYwLCAgICAgICAgMCwgICAgICAg IDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKemlvX2RhdGFfYnVmXzQwOTYwOiAg ICAgNDA5NjAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAg ICAgMAp6aW9fYnVmXzQ1MDU2OiAgICAgICAgICA0NTA1NiwgICAgICAgIDAsICAgICAgICAw LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnppb19kYXRhX2J1Zl80NTA1NjogICAg IDQ1MDU2LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAg IDAKemlvX2J1Zl80OTE1MjogICAgICAgICAgNDkxNTIsICAgICAgICAwLCAgICAgICAgMCwg ICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAp6aW9fZGF0YV9idWZfNDkxNTI6ICAgICA0 OTE1MiwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAw Cnppb19idWZfNTMyNDg6ICAgICAgICAgIDUzMjQ4LCAgICAgICAgMCwgICAgICAgIDAsICAg ICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKemlvX2RhdGFfYnVmXzUzMjQ4OiAgICAgNTMy NDgsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAp6 aW9fYnVmXzU3MzQ0OiAgICAgICAgICA1NzM0NCwgICAgICAgIDAsICAgICAgICAwLCAgICAg ICAgMCwgICAgICAgIDAsICAgICAgICAwCnppb19kYXRhX2J1Zl81NzM0NDogICAgIDU3MzQ0 LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKemlv X2J1Zl82MTQ0MDogICAgICAgICAgNjE0NDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAg IDAsICAgICAgICAwLCAgICAgICAgMAp6aW9fZGF0YV9idWZfNjE0NDA6ICAgICA2MTQ0MCwg ICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnppb19i dWZfNjU1MzY6ICAgICAgICAgIDY1NTM2LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAw LCAgICAgICAgMCwgICAgICAgIDAKemlvX2RhdGFfYnVmXzY1NTM2OiAgICAgNjU1MzYsICAg ICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAp6aW9fYnVm XzY5NjMyOiAgICAgICAgICA2OTYzMiwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwg ICAgICAgIDAsICAgICAgICAwCnppb19kYXRhX2J1Zl82OTYzMjogICAgIDY5NjMyLCAgICAg ICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKemlvX2J1Zl83 MzcyODogICAgICAgICAgNzM3MjgsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAg ICAgICAwLCAgICAgICAgMAp6aW9fZGF0YV9idWZfNzM3Mjg6ICAgICA3MzcyOCwgICAgICAg IDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnppb19idWZfNzc4 MjQ6ICAgICAgICAgIDc3ODI0LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAg ICAgMCwgICAgICAgIDAKemlvX2RhdGFfYnVmXzc3ODI0OiAgICAgNzc4MjQsICAgICAgICAw LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAp6aW9fYnVmXzgxOTIw OiAgICAgICAgICA4MTkyMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAg IDAsICAgICAgICAwCnppb19kYXRhX2J1Zl84MTkyMDogICAgIDgxOTIwLCAgICAgICAgMCwg ICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKemlvX2J1Zl84NjAxNjog ICAgICAgICAgODYwMTYsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAw LCAgICAgICAgMAp6aW9fZGF0YV9idWZfODYwMTY6ICAgICA4NjAxNiwgICAgICAgIDAsICAg ICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnppb19idWZfOTAxMTI6ICAg ICAgICAgIDkwMTEyLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwg ICAgICAgIDAKemlvX2RhdGFfYnVmXzkwMTEyOiAgICAgOTAxMTIsICAgICAgICAwLCAgICAg ICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAp6aW9fYnVmXzk0MjA4OiAgICAg ICAgICA5NDIwOCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAg ICAgICAwCnppb19kYXRhX2J1Zl85NDIwODogICAgIDk0MjA4LCAgICAgICAgMCwgICAgICAg IDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKemlvX2J1Zl85ODMwNDogICAgICAg ICAgOTgzMDQsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAg ICAgMAp6aW9fZGF0YV9idWZfOTgzMDQ6ICAgICA5ODMwNCwgICAgICAgIDAsICAgICAgICAw LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnppb19idWZfMTAyNDAwOiAgICAgICAg MTAyNDAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAg IDAKemlvX2RhdGFfYnVmXzEwMjQwMDogICAxMDI0MDAsICAgICAgICAwLCAgICAgICAgMCwg ICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAp6aW9fYnVmXzEwNjQ5NjogICAgICAgIDEw NjQ5NiwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAw Cnppb19kYXRhX2J1Zl8xMDY0OTY6ICAgMTA2NDk2LCAgICAgICAgMCwgICAgICAgIDAsICAg ICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKemlvX2J1Zl8xMTA1OTI6ICAgICAgICAxMTA1 OTIsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAp6 aW9fZGF0YV9idWZfMTEwNTkyOiAgIDExMDU5MiwgICAgICAgIDAsICAgICAgICAwLCAgICAg ICAgMCwgICAgICAgIDAsICAgICAgICAwCnppb19idWZfMTE0Njg4OiAgICAgICAgMTE0Njg4 LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKemlv X2RhdGFfYnVmXzExNDY4ODogICAxMTQ2ODgsICAgICAgICAwLCAgICAgICAgMCwgICAgICAg IDAsICAgICAgICAwLCAgICAgICAgMAp6aW9fYnVmXzExODc4NDogICAgICAgIDExODc4NCwg ICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnppb19k YXRhX2J1Zl8xMTg3ODQ6ICAgMTE4Nzg0LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAw LCAgICAgICAgMCwgICAgICAgIDAKemlvX2J1Zl8xMjI4ODA6ICAgICAgICAxMjI4ODAsICAg ICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAp6aW9fZGF0 YV9idWZfMTIyODgwOiAgIDEyMjg4MCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwg ICAgICAgIDAsICAgICAgICAwCnppb19idWZfMTI2OTc2OiAgICAgICAgMTI2OTc2LCAgICAg ICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKemlvX2RhdGFf YnVmXzEyNjk3NjogICAxMjY5NzYsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAg ICAgICAwLCAgICAgICAgMAp6aW9fYnVmXzEzMTA3MjogICAgICAgIDEzMTA3MiwgICAgICAg IDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnppb19kYXRhX2J1 Zl8xMzEwNzI6ICAgMTMxMDcyLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAg ICAgMCwgICAgICAgIDAKZG11X2J1Zl9pbXBsX3Q6ICAgICAgICAgICAyMjQsICAgICAgICAw LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMApkbm9kZV90OiAgICAg ICAgICAgICAgICAgIDc3NiwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAg IDAsICAgICAgICAwCmFyY19idWZfaGRyX3Q6ICAgICAgICAgICAgMjA4LCAgICAgICAgMCwg ICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKYXJjX2J1Zl90OiAgICAg ICAgICAgICAgICAgNzIsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAw LCAgICAgICAgMAp6aWxfbHdiX2NhY2hlOiAgICAgICAgICAgIDIwMCwgICAgICAgIDAsICAg ICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnpmc196bm9kZV9jYWNoZTog ICAgICAgICAgMzc2LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwg ICAgICAgIDAKa3NpZ2luZm86ICAgICAgICAgICAgICAgICAxMTIsICAgICAgICAwLCAgICAg MTcyOCwgICAgIDEzNDEsICAgIDUyMTAyLCAgICAgICAgMAppdGltZXI6ICAgICAgICAgICAg ICAgICAgIDM0NCwgICAgICAgIDAsICAgICAgICAxLCAgICAgICAyMSwgICAgICAgIDEsICAg ICAgICAwCktOT1RFOiAgICAgICAgICAgICAgICAgICAgMTI4LCAgICAgICAgMCwgICAgICAg IDgsICAgICAxNDQyLCAyMDUzNTYwOTQsICAgICAgICAwCnNvY2tldDogICAgICAgICAgICAg ICAgICAgNjgwLCAgICAyNTYwMiwgICAgICAgNzAsICAgICAxNDY2LCAyMDQzOTg0NywgICAg ICAgIDAKaXBxOiAgICAgICAgICAgICAgICAgICAgICAgNTYsICAgICAgODE5LCAgICAgICAg MCwgICAgICA0NDEsICAgICAxMzc1LCAgICAgICAgMAp1ZHBfaW5wY2I6ICAgICAgICAgICAg ICAgIDMzNiwgICAgMjU2MDgsICAgICAgIDU2LCAgICAgMTMwOCwgMTUzNzcwNDcsICAgICAg ICAwCnVkcGNiOiAgICAgICAgICAgICAgICAgICAgIDE2LCAgICAyNTcwNCwgICAgICAgNTYs ICAgICAxNDU2LCAxNTM3NzA0NywgICAgICAgIDAKdGNwX2lucGNiOiAgICAgICAgICAgICAg ICAzMzYsICAgIDI1NjA4LCAgICAgICAgNiwgICAgIDE2NzcsICAgNTc5MjE5LCAgICAgICAg MAp0Y3BjYjogICAgICAgICAgICAgICAgICAgIDg4MCwgICAgMjU2MDAsICAgICAgICA2LCAg ICAgMTA0NiwgICA1NzkyMTksICAgICAgICAwCnRjcHR3OiAgICAgICAgICAgICAgICAgICAg IDcyLCAgICAgNTE1MCwgICAgICAgIDAsICAgICAxNzUwLCAgIDE0MjAyOCwgICAgICAgIDAK c3luY2FjaGU6ICAgICAgICAgICAgICAgICAxNDQsICAgIDE1MzY2LCAgICAgICAgMCwgICAg ICA0NDIsICAgNTE4Mzk0LCAgICAgICAgMApob3N0Y2FjaGU6ICAgICAgICAgICAgICAgIDEz NiwgICAgMTUzNzIsICAgICAgICAyLCAgICAgIDQ0NiwgICAgICA0NzIsICAgICAgICAwCnRj cHJlYXNzOiAgICAgICAgICAgICAgICAgIDQwLCAgICAgMTY4MCwgICAgICAgIDAsICAgICAg ODQwLCAgIDM1ODYxNCwgICAgICAgIDAKc2Fja2hvbGU6ICAgICAgICAgICAgICAgICAgMzIs ICAgICAgICAwLCAgICAgICAgMCwgICAgICAzMDMsICAgICAgMTc0LCAgICAgICAgMApzY3Rw X2VwOiAgICAgICAgICAgICAgICAgMTI3MiwgICAgMjU2MDIsICAgICAgICAwLCAgICAgICAg MCwgICAgICAgIDAsICAgICAgICAwCnNjdHBfYXNvYzogICAgICAgICAgICAgICAyMjMyLCAg ICA0MDAwMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKc2N0cF9s YWRkcjogICAgICAgICAgICAgICAgNDgsICAgIDgwMDY0LCAgICAgICAgMCwgICAgICAyODgs ICAgICAgIDQ5LCAgICAgICAgMApzY3RwX3JhZGRyOiAgICAgICAgICAgICAgIDYxNiwgICAg ODAwMDQsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnNjdHBfY2h1 bms6ICAgICAgICAgICAgICAgMTM2LCAgIDQwMDAwOCwgICAgICAgIDAsICAgICAgICAwLCAg ICAgICAgMCwgICAgICAgIDAKc2N0cF9yZWFkcTogICAgICAgICAgICAgICAxMDQsICAgNDAw MDMyLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMApzY3RwX3N0cmVh bV9tc2dfb3V0OiAgICAgICA5NiwgICA0MDAwMjYsICAgICAgICAwLCAgICAgICAgMCwgICAg ICAgIDAsICAgICAgICAwCnNjdHBfYXNjb25mOiAgICAgICAgICAgICAgIDQwLCAgIDQwMDAw OCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKc2N0cF9hc2NvbmZf YWNrOiAgICAgICAgICAgNDgsICAgNDAwMDMyLCAgICAgICAgMCwgICAgICAgIDAsICAgICAg ICAwLCAgICAgICAgMApyaXBjYjogICAgICAgICAgICAgICAgICAgIDMzNiwgICAgMjU2MDgs ICAgICAgICAwLCAgICAgIDI2NCwgICAgMjUxMjYsICAgICAgICAwCnVucGNiOiAgICAgICAg ICAgICAgICAgICAgMjQwLCAgICAyNTYwMCwgICAgICAgIDcsICAgICAxMzM3LCAgNDQ1ODQy NCwgICAgICAgIDAKcnRlbnRyeTogICAgICAgICAgICAgICAgICAyMDAsICAgICAgICAwLCAg ICAgIDEyNSwgICAgICAgNDYsICAgICAgMTI2LCAgICAgICAgMApJUEZXIGR5bmFtaWMgcnVs ZTogICAgICAgIDEyMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAs ICAgICAgICAwCmRpdmNiOiAgICAgICAgICAgICAgICAgICAgMzM2LCAgICAyNTYwOCwgICAg ICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKc2VsZmQ6ICAgICAgICAgICAg ICAgICAgICAgNTYsICAgICAgICAwLCAgICAgMjcwOCwgICAgIDEyNjEsIDIwNDY2OTU0Miwg ICAgICAgIDAKU1dBUE1FVEE6ICAgICAgICAgICAgICAgICAyODgsICAgMTE2NTE5LCAgICAg ICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAppcDRmbG93OiAgICAgICAgICAg ICAgICAgICA1NiwgICAxOTc2OTQsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAg ICAgICAwCmlwNmZsb3c6ICAgICAgICAgICAgICAgICAgIDgwLCAgIDE5NzY0MCwgICAgICAg IDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKTW91bnRwb2ludHM6ICAgICAgICAg ICAgICA3NTIsICAgICAgICAwLCAgICAgICAgNiwgICAgICAgMTksICAgICAgICA2LCAgICAg ICAgMApGRlMgaW5vZGU6ICAgICAgICAgICAgICAgIDE2OCwgICAgICAgIDAsICAgIDg3MzAw LCAgICAgMzY5MiwgMTE2MzY1NjQsICAgICAgICAwCkZGUzEgZGlub2RlOiAgICAgICAgICAg ICAgMTI4LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAg IDAKRkZTMiBkaW5vZGU6ICAgICAgICAgICAgICAyNTYsICAgICAgICAwLCAgICA4NzMwMCwg ICAgIDM3OTUsIDExNjM2NTYyLCAgICAgICAgMAoKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQp2bXN0 YXQgLWkKCmludGVycnVwdCAgICAgICAgICAgICAgICAgICAgICAgICAgdG90YWwgICAgICAg cmF0ZQppcnE0OiB1YXJ0MCAgICAgICAgICAgICAgICAgICAgICAgMjI5NTEzICAgICAgIDE0 NTIKaXJxMjE6IGVoY2kwICAgICAgICAgICAgICAgICAgICAgMjE5MzI4MyAgICAgIDEzODgx CmlycTIzOiBlaGNpMSAgICAgICAgICAgICAgICAgICAgIDI5MjcwMDUgICAgICAxODUyNQpj cHUwOiB0aW1lciAgICAgICAgICAgICAgICAgICAyOTIwOTAzOTAyICAgMTg0ODY3MzMKaXJx MjU3OiBlbTEgICAgICAgICAgICAgICAgICAgNzcwMDU3MzE2NiAgIDQ4NzM3ODA0CmlycTI1 ODogZW0xICAgICAgICAgICAgICAgICAgIDcxMjE3NzExNjYgICA0NTA3NDUwMQppcnEyNjE6 IGVtMSAgICAgICAgICAgICAgICAgICAgICAgMzA4MzI1ICAgICAgIDE5NTEKaXJxMjYyOiBh aGNpMCAgICAgICAgICAgICAgICAgICAgNjQzOTQwMyAgICAgIDQwNzU1CmNwdTE6IHRpbWVy ICAgICAgICAgICAgICAgICAgIDI5MjEwMDUyMzAgICAxODQ4NzM3NApjcHU0OiB0aW1lciAg ICAgICAgICAgICAgICAgICAyOTIxMDE2NjgxICAgMTg0ODc0NDcKY3B1MjogdGltZXIgICAg ICAgICAgICAgICAgICAgMjkyMTAyMTI1MiAgIDE4NDg3NDc2CmNwdTU6IHRpbWVyICAgICAg ICAgICAgICAgICAgIDI5MjEwMTcwNjMgICAxODQ4NzQ0OQpjcHUzOiB0aW1lciAgICAgICAg ICAgICAgICAgICAyOTIxMDIyMTg3ICAgMTg0ODc0ODIKY3B1NjogdGltZXIgICAgICAgICAg ICAgICAgICAgMjkyMTAxNTg0NiAgIDE4NDg3NDQyCmNwdTc6IHRpbWVyICAgICAgICAgICAg ICAgICAgIDI5MjEwMTU2MzQgICAxODQ4NzQ0MApUb3RhbCAgICAgICAgICAgICAgICAgICAg ICAgIDM4MjAyNDU5NjU2ICAyNDE3ODc3MTkKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpwc3RhdCAt VAoKMTIwLzEyMzI4IGZpbGVzCjBNLzgxOTFNIHN3YXAgc3BhY2UKCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQpwc3RhdCAtcwoKRGV2aWNlICAgICAgICAgIDUxMi1ibG9ja3MgICAgIFVzZWQgICAg QXZhaWwgQ2FwYWNpdHkKL2Rldi9taXJyb3IvZ20wczFiICAgMTY3NzY5NjAgICAgICAgIDAg MTY3NzY5NjAgICAgIDAlCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KaW9zdGF0Cgppb3N0YXQ6IGt2 bV9yZWFkKF90a19uaW4pOiBpbnZhbGlkIGFkZHJlc3MgKDB4MCkKaW9zdGF0OiBkaXNhYmxp bmcgVFRZIHN0YXRpc3RpY3MKaW9zdGF0OiBrdm1fZ2V0Y3B0aW1lOiBpbnZhbGlkIGFkZHJl c3MgKDB4MCkKaW9zdGF0OiBkaXNhYmxpbmcgQ1BVIHRpbWUgc3RhdGlzdGljcwogICAgICAg ICAgICBhZGEwICAgICAgICAgICAgIGFkYTEgICAgICAgICAgICBwYXNzMCAKICBLQi90IHRw cyAgTUIvcyAgIEtCL3QgdHBzICBNQi9zICAgS0IvdCB0cHMgIE1CL3MgCiAyMC45OSAxOTE3 NiAzOTIuOTcgIDIwLjk5IDE5MTc2IDM5Mi45OCAgIDAuMDAgICAwICAwLjAwIAoKLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tCmlwY3MgLWEKCk1lc3NhZ2UgUXVldWVzOgpUICAgICAgICAgICBJRCAg ICAgICAgICBLRVkgTU9ERSAgICAgICAgT1dORVIgICAgR1JPVVAgICAgQ1JFQVRPUiAgQ0dS T1VQICAgICAgICAgICAgICAgICBDQllURVMgICAgICAgICAgICAgICAgIFFOVU0gICAgICAg ICAgICAgICBRQllURVMgICAgICAgIExTUElEICAgICAgICBMUlBJRCBTVElNRSAgICBSVElN RSAgICBDVElNRSAgIAoKU2hhcmVkIE1lbW9yeToKVCAgICAgICAgICAgSUQgICAgICAgICAg S0VZIE1PREUgICAgICAgIE9XTkVSICAgIEdST1VQICAgIENSRUFUT1IgIENHUk9VUCAgICAg ICAgIE5BVFRDSCAgICAgICAgU0VHU1ogICAgICAgICBDUElEICAgICAgICAgTFBJRCBBVElN RSAgICBEVElNRSAgICBDVElNRSAgIAoKU2VtYXBob3JlczoKVCAgICAgICAgICAgSUQgICAg ICAgICAgS0VZIE1PREUgICAgICAgIE9XTkVSICAgIEdST1VQICAgIENSRUFUT1IgIENHUk9V UCAgICAgICAgICBOU0VNUyBPVElNRSAgICBDVElNRSAgIAoKCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQppcGNzIC1UCgptc2dpbmZvOgoJbXNnbWF4OiAgICAgICAgMTYzODQJKG1heCBjaGFyYWN0 ZXJzIGluIGEgbWVzc2FnZSkKCW1zZ21uaTogICAgICAgICAgIDQwCSgjIG9mIG1lc3NhZ2Ug cXVldWVzKQoJbXNnbW5iOiAgICAgICAgIDIwNDgJKG1heCBjaGFyYWN0ZXJzIGluIGEgbWVz c2FnZSBxdWV1ZSkKCW1zZ3RxbDogICAgICAgICAgIDQwCShtYXggIyBvZiBtZXNzYWdlcyBp biBzeXN0ZW0pCgltc2dzc3o6ICAgICAgICAgICAgOAkoc2l6ZSBvZiBhIG1lc3NhZ2Ugc2Vn bWVudCkKCW1zZ3NlZzogICAgICAgICAyMDQ4CSgjIG9mIG1lc3NhZ2Ugc2VnbWVudHMgaW4g c3lzdGVtKQoKc2htaW5mbzoKCXNobW1heDogICAgIDMzNTU0NDMyCShtYXggc2hhcmVkIG1l bW9yeSBzZWdtZW50IHNpemUpCglzaG1taW46ICAgICAgICAgICAgMQkobWluIHNoYXJlZCBt ZW1vcnkgc2VnbWVudCBzaXplKQoJc2htbW5pOiAgICAgICAgICAxOTIJKG1heCBudW1iZXIg b2Ygc2hhcmVkIG1lbW9yeSBpZGVudGlmaWVycykKCXNobXNlZzogICAgICAgICAgMTI4CSht YXggc2hhcmVkIG1lbW9yeSBzZWdtZW50cyBwZXIgcHJvY2VzcykKCXNobWFsbDogICAgICAg ICA4MTkyCShtYXggYW1vdW50IG9mIHNoYXJlZCBtZW1vcnkgaW4gcGFnZXMpCgpzZW1pbmZv OgoJc2VtbWFwOiAgICAgICAgICAgMzAJKCMgb2YgZW50cmllcyBpbiBzZW1hcGhvcmUgbWFw KQoJc2VtbW5pOiAgICAgICAgICAgMTAJKCMgb2Ygc2VtYXBob3JlIGlkZW50aWZpZXJzKQoJ c2VtbW5zOiAgICAgICAgICAgNjAJKCMgb2Ygc2VtYXBob3JlcyBpbiBzeXN0ZW0pCglzZW1t bnU6ICAgICAgICAgICAzMAkoIyBvZiB1bmRvIHN0cnVjdHVyZXMgaW4gc3lzdGVtKQoJc2Vt bXNsOiAgICAgICAgICAgNjAJKG1heCAjIG9mIHNlbWFwaG9yZXMgcGVyIGlkKQoJc2Vtb3Bt OiAgICAgICAgICAxMDAJKG1heCAjIG9mIG9wZXJhdGlvbnMgcGVyIHNlbW9wIGNhbGwpCglz ZW11bWU6ICAgICAgICAgICAxMAkobWF4ICMgb2YgdW5kbyBlbnRyaWVzIHBlciBwcm9jZXNz KQoJc2VtdXN6OiAgICAgICAgICAxNTIJKHNpemUgaW4gYnl0ZXMgb2YgdW5kbyBzdHJ1Y3R1 cmUpCglzZW12bXg6ICAgICAgICAzMjc2Nwkoc2VtYXBob3JlIG1heGltdW0gdmFsdWUpCglz ZW1hZW06ICAgICAgICAxNjM4NAkoYWRqdXN0IG9uIGV4aXQgbWF4IHZhbHVlKQoKCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQpuZnNzdGF0CgpDbGllbnQgSW5mbzoKUnBjIENvdW50czoKICBHZXRh dHRyICAgU2V0YXR0ciAgICBMb29rdXAgIFJlYWRsaW5rICAgICAgUmVhZCAgICAgV3JpdGUg ICAgQ3JlYXRlICAgIFJlbW92ZQogICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAg ICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwCiAgIFJlbmFt ZSAgICAgIExpbmsgICBTeW1saW5rICAgICBNa2RpciAgICAgUm1kaXIgICBSZWFkZGlyICBS ZGlyUGx1cyAgICBBY2Nlc3MKICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAg ICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMAogICAgTWtub2Qg ICAgRnNzdGF0ICAgIEZzaW5mbyAgUGF0aENvbmYgICAgQ29tbWl0CiAgICAgICAgMCAgICAg ICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAKUnBjIEluZm86CiBUaW1lZE91 dCAgIEludmFsaWQgWCBSZXBsaWVzICAgUmV0cmllcyAgUmVxdWVzdHMKICAgICAgICAwICAg ICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMApDYWNoZSBJbmZvOgpBdHRy IEhpdHMgICAgTWlzc2VzIExrdXAgSGl0cyAgICBNaXNzZXMgQmlvUiBIaXRzICAgIE1pc3Nl cyBCaW9XIEhpdHMgICAgTWlzc2VzCiAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAg ICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAKQmlvUkxI aXRzICAgIE1pc3NlcyBCaW9EIEhpdHMgICAgTWlzc2VzIERpckUgSGl0cyAgICBNaXNzZXMK ICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAg ICAgIDAKClNlcnZlciBJbmZvOgogIEdldGF0dHIgICBTZXRhdHRyICAgIExvb2t1cCAgUmVh ZGxpbmsgICAgICBSZWFkICAgICBXcml0ZSAgICBDcmVhdGUgICAgUmVtb3ZlCiAgICAgICAg MCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAg ICAgICAgMCAgICAgICAgIDAKICAgUmVuYW1lICAgICAgTGluayAgIFN5bWxpbmsgICAgIE1r ZGlyICAgICBSbWRpciAgIFJlYWRkaXIgIFJkaXJQbHVzICAgIEFjY2VzcwogICAgICAgIDAg ICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAg ICAgIDAgICAgICAgICAwCiAgICBNa25vZCAgICBGc3N0YXQgICAgRnNpbmZvICBQYXRoQ29u ZiAgICBDb21taXQKICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAg ICAgICAgMApTZXJ2ZXIgUmV0LUZhaWxlZAogICAgICAgICAgICAgICAgMApTZXJ2ZXIgRmF1 bHRzCiAgICAgICAgICAgIDAKU2VydmVyIENhY2hlIFN0YXRzOgogICBJbnByb2cgICAgICBJ ZGVtICBOb24taWRlbSAgICBNaXNzZXMKICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAg ICAgICAgICAwClNlcnZlciBXcml0ZSBHYXRoZXJpbmc6CiBXcml0ZU9wcyAgV3JpdGVSUEMg ICBPcHNhdmVkCiAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwCgotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0KbmV0c3RhdCAtcwoKdGNwOgoJMTQxMDIwODEgcGFja2V0cyBzZW50CgkJNjI3ODQ4 MiBkYXRhIHBhY2tldHMgKDM2NjAzMTA0NDIgYnl0ZXMpCgkJMjI0MDAgZGF0YSBwYWNrZXRz ICg2OTQ2NDg3IGJ5dGVzKSByZXRyYW5zbWl0dGVkCgkJMjcwMiBkYXRhIHBhY2tldHMgdW5u ZWNlc3NhcmlseSByZXRyYW5zbWl0dGVkCgkJMCByZXNlbmRzIGluaXRpYXRlZCBieSBNVFUg ZGlzY292ZXJ5CgkJNTk3NjIwNyBhY2stb25seSBwYWNrZXRzICgyNjA0Njg3IGRlbGF5ZWQp CgkJMCBVUkcgb25seSBwYWNrZXRzCgkJMCB3aW5kb3cgcHJvYmUgcGFja2V0cwoJCTExODA4 MTQgd2luZG93IHVwZGF0ZSBwYWNrZXRzCgkJNjQzOTg4IGNvbnRyb2wgcGFja2V0cwoJMTU5 MjY3NDQgcGFja2V0cyByZWNlaXZlZAoJCTczMDYyNjMgYWNrcyAoZm9yIDM2NTk5NjcwOTMg Ynl0ZXMpCgkJNjk1MTY1IGR1cGxpY2F0ZSBhY2tzCgkJMTE3MTY5IGFja3MgZm9yIHVuc2Vu dCBkYXRhCgkJOTUzNjAyOCBwYWNrZXRzICg1OTA5NTUxODE0IGJ5dGVzKSByZWNlaXZlZCBp bi1zZXF1ZW5jZQoJCTkzODI2IGNvbXBsZXRlbHkgZHVwbGljYXRlIHBhY2tldHMgKDgzNjE1 ODQxIGJ5dGVzKQoJCTE3MCBvbGQgZHVwbGljYXRlIHBhY2tldHMKCQkyOTggcGFja2V0cyB3 aXRoIHNvbWUgZHVwLiBkYXRhICgxODk5MyBieXRlcyBkdXBlZCkKCQkzNTg2MDcgb3V0LW9m LW9yZGVyIHBhY2tldHMgKDQwNjY2MjY3NCBieXRlcykKCQkwIHBhY2tldHMgKDAgYnl0ZXMp IG9mIGRhdGEgYWZ0ZXIgd2luZG93CgkJMCB3aW5kb3cgcHJvYmVzCgkJMjYyOCB3aW5kb3cg dXBkYXRlIHBhY2tldHMKCQk1NyBwYWNrZXRzIHJlY2VpdmVkIGFmdGVyIGNsb3NlCgkJMzcz OTYgZGlzY2FyZGVkIGZvciBiYWQgY2hlY2tzdW1zCgkJMCBkaXNjYXJkZWQgZm9yIGJhZCBo ZWFkZXIgb2Zmc2V0IGZpZWxkcwoJCTAgZGlzY2FyZGVkIGJlY2F1c2UgcGFja2V0IHRvbyBz aG9ydAoJCTE2ODMgZGlzY2FyZGVkIGR1ZSB0byBtZW1vcnkgcHJvYmxlbXMKCTgwMjE4IGNv bm5lY3Rpb24gcmVxdWVzdHMKCTQ5NzUwMSBjb25uZWN0aW9uIGFjY2VwdHMKCTE5NSBiYWQg Y29ubmVjdGlvbiBhdHRlbXB0cwoJMCBsaXN0ZW4gcXVldWUgb3ZlcmZsb3dzCgk2MjQxIGln bm9yZWQgUlNUcyBpbiB0aGUgd2luZG93cwoJNTcxNTc3IGNvbm5lY3Rpb25zIGVzdGFibGlz aGVkIChpbmNsdWRpbmcgYWNjZXB0cykKCTU3OTIxMyBjb25uZWN0aW9ucyBjbG9zZWQgKGlu Y2x1ZGluZyA4MDczIGRyb3BzKQoJCTUzOTE5MSBjb25uZWN0aW9ucyB1cGRhdGVkIGNhY2hl ZCBSVFQgb24gY2xvc2UKCQk1MzkyNTcgY29ubmVjdGlvbnMgdXBkYXRlZCBjYWNoZWQgUlRU IHZhcmlhbmNlIG9uIGNsb3NlCgkJMzcwODgzIGNvbm5lY3Rpb25zIHVwZGF0ZWQgY2FjaGVk IHNzdGhyZXNoIG9uIGNsb3NlCgk1IGVtYnJ5b25pYyBjb25uZWN0aW9ucyBkcm9wcGVkCgk3 MDYyMzM2IHNlZ21lbnRzIHVwZGF0ZWQgcnR0IChvZiA2NjE0MzY0IGF0dGVtcHRzKQoJMjk0 MTcgcmV0cmFuc21pdCB0aW1lb3V0cwoJCTEzMCBjb25uZWN0aW9ucyBkcm9wcGVkIGJ5IHJl eG1pdCB0aW1lb3V0CgkwIHBlcnNpc3QgdGltZW91dHMKCQkwIGNvbm5lY3Rpb25zIGRyb3Bw ZWQgYnkgcGVyc2lzdCB0aW1lb3V0CgkwIENvbm5lY3Rpb25zIChmaW5fd2FpdF8yKSBkcm9w cGVkIGJlY2F1c2Ugb2YgdGltZW91dAoJMTk5IGtlZXBhbGl2ZSB0aW1lb3V0cwoJCTE5NSBr ZWVwYWxpdmUgcHJvYmVzIHNlbnQKCQk0IGNvbm5lY3Rpb25zIGRyb3BwZWQgYnkga2VlcGFs aXZlCgk0MTcgY29ycmVjdCBBQ0sgaGVhZGVyIHByZWRpY3Rpb25zCgk2ODAyNzIxIGNvcnJl Y3QgZGF0YSBwYWNrZXQgaGVhZGVyIHByZWRpY3Rpb25zCgk1MTgzOTIgc3luY2FjaGUgZW50 cmllcyBhZGRlZAoJCTk2MzAgcmV0cmFuc21pdHRlZAoJCTI1MjkgZHVwc3luCgkJMiBkcm9w cGVkCgkJNDk3NTAxIGNvbXBsZXRlZAoJCTEzIGJ1Y2tldCBvdmVyZmxvdwoJCTAgY2FjaGUg b3ZlcmZsb3cKCQkxODYzNiByZXNldAoJCTIyNTIgc3RhbGUKCQkwIGFib3J0ZWQKCQkwIGJh ZGFjawoJCTMgdW5yZWFjaAoJCTAgem9uZSBmYWlsdXJlcwoJNTE4Mzk0IGNvb2tpZXMgc2Vu dAoJMTQgY29va2llcyByZWNlaXZlZAoJMjkxIFNBQ0sgcmVjb3ZlcnkgZXBpc29kZXMKCTEw OCBzZWdtZW50IHJleG1pdHMgaW4gU0FDSyByZWNvdmVyeSBlcGlzb2RlcwoJMTQ1NzIwIGJ5 dGUgcmV4bWl0cyBpbiBTQUNLIHJlY292ZXJ5IGVwaXNvZGVzCgkxMjMwOSBTQUNLIG9wdGlv bnMgKFNBQ0sgYmxvY2tzKSByZWNlaXZlZAoJMjU2MjkwIFNBQ0sgb3B0aW9ucyAoU0FDSyBi bG9ja3MpIHNlbnQKCTAgU0FDSyBzY29yZWJvYXJkIG92ZXJmbG93CgkwIHBhY2tldHMgd2l0 aCBFQ04gQ0UgYml0IHNldAoJMCBwYWNrZXRzIHdpdGggRUNOIEVDVCgwKSBiaXQgc2V0Cgkw IHBhY2tldHMgd2l0aCBFQ04gRUNUKDEpIGJpdCBzZXQKCTAgc3VjY2Vzc2Z1bCBFQ04gaGFu ZHNoYWtlcwoJMCB0aW1lcyBFQ04gcmVkdWNlZCB0aGUgY29uZ2VzdGlvbiB3aW5kb3cKdWRw OgoJNDE1MDk2MjkgZGF0YWdyYW1zIHJlY2VpdmVkCgkwIHdpdGggaW5jb21wbGV0ZSBoZWFk ZXIKCTAgd2l0aCBiYWQgZGF0YSBsZW5ndGggZmllbGQKCTMwNiB3aXRoIGJhZCBjaGVja3N1 bQoJMTQ0ODk4IHdpdGggbm8gY2hlY2tzdW0KCTQxMTM0MCBkcm9wcGVkIGR1ZSB0byBubyBz b2NrZXQKCTI2MjAyNzggYnJvYWRjYXN0L211bHRpY2FzdCBkYXRhZ3JhbXMgdW5kZWxpdmVy ZWQKCTAgZHJvcHBlZCBkdWUgdG8gZnVsbCBzb2NrZXQgYnVmZmVycwoJMCBub3QgZm9yIGhh c2hlZCBwY2IKCTM4NDc3NzA1IGRlbGl2ZXJlZAoJMzg2NzExMjMgZGF0YWdyYW1zIG91dHB1 dAoJMCB0aW1lcyBtdWx0aWNhc3Qgc291cmNlIGZpbHRlciBtYXRjaGVkCmlwOgoJMjAwMjA0 MDkwMzkgdG90YWwgcGFja2V0cyByZWNlaXZlZAoJMTAxIGJhZCBoZWFkZXIgY2hlY2tzdW1z CgkwIHdpdGggc2l6ZSBzbWFsbGVyIHRoYW4gbWluaW11bQoJMTA5IHdpdGggZGF0YSBzaXpl IDwgZGF0YSBsZW5ndGgKCTAgd2l0aCBpcCBsZW5ndGggPiBtYXggaXAgcGFja2V0IHNpemUK CTAgd2l0aCBoZWFkZXIgbGVuZ3RoIDwgZGF0YSBzaXplCgkwIHdpdGggZGF0YSBsZW5ndGgg PCBoZWFkZXIgbGVuZ3RoCgkwIHdpdGggYmFkIG9wdGlvbnMKCTAgd2l0aCBpbmNvcnJlY3Qg dmVyc2lvbiBudW1iZXIKCTI4MTIgZnJhZ21lbnRzIHJlY2VpdmVkCgkwIGZyYWdtZW50cyBk cm9wcGVkIChkdXAgb3Igb3V0IG9mIHNwYWNlKQoJMjEgZnJhZ21lbnRzIGRyb3BwZWQgYWZ0 ZXIgdGltZW91dAoJMTM1NiBwYWNrZXRzIHJlYXNzZW1ibGVkIG9rCgk1NzczNzgyOSBwYWNr ZXRzIGZvciB0aGlzIGhvc3QKCTQxOTAgcGFja2V0cyBmb3IgdW5rbm93bi91bnN1cHBvcnRl ZCBwcm90b2NvbAoJMTY2NjI1NTUwNzYgcGFja2V0cyBmb3J3YXJkZWQgKDAgcGFja2V0cyBm YXN0IGZvcndhcmRlZCkKCTYwNjIxNTAxIHBhY2tldHMgbm90IGZvcndhcmRhYmxlCgkwIHBh Y2tldHMgcmVjZWl2ZWQgZm9yIHVua25vd24gbXVsdGljYXN0IGdyb3VwCgk5ODY5MDc1IHJl ZGlyZWN0cyBzZW50Cgk3NzY0NDAzOCBwYWNrZXRzIHNlbnQgZnJvbSB0aGlzIGhvc3QKCTIx NDggcGFja2V0cyBzZW50IHdpdGggZmFicmljYXRlZCBpcCBoZWFkZXIKCTAgb3V0cHV0IHBh Y2tldHMgZHJvcHBlZCBkdWUgdG8gbm8gYnVmcywgZXRjLgoJMCBvdXRwdXQgcGFja2V0cyBk aXNjYXJkZWQgZHVlIHRvIG5vIHJvdXRlCgkzOTcgb3V0cHV0IGRhdGFncmFtcyBmcmFnbWVu dGVkCgk3OTQgZnJhZ21lbnRzIGNyZWF0ZWQKCTAgZGF0YWdyYW1zIHRoYXQgY2FuJ3QgYmUg ZnJhZ21lbnRlZAoJMCB0dW5uZWxpbmcgcGFja2V0cyB0aGF0IGNhbid0IGZpbmQgZ2lmCgkx IGRhdGFncmFtIHdpdGggYmFkIGFkZHJlc3MgaW4gaGVhZGVyCmljbXA6CgkxNDY1NTQxNSBj YWxscyB0byBpY21wX2Vycm9yCgk2NDkgZXJyb3JzIG5vdCBnZW5lcmF0ZWQgaW4gcmVzcG9u c2UgdG8gYW4gaWNtcCBtZXNzYWdlCglPdXRwdXQgaGlzdG9ncmFtOgoJCWVjaG8gcmVwbHk6 IDI5OTUyOAoJCWRlc3RpbmF0aW9uIHVucmVhY2hhYmxlOiAxNjQzODQ5CgkJcm91dGluZyBy ZWRpcmVjdDogOTg2OTA3NQoJCXRpbWUgZXhjZWVkZWQ6IDEzMDEwOTE3CgkwIG1lc3NhZ2Vz IHdpdGggYmFkIGNvZGUgZmllbGRzCgkwIG1lc3NhZ2VzIGxlc3MgdGhhbiB0aGUgbWluaW11 bSBsZW5ndGgKCTAgbWVzc2FnZXMgd2l0aCBiYWQgY2hlY2tzdW0KCTAgbWVzc2FnZXMgd2l0 aCBiYWQgbGVuZ3RoCgkyOSBtdWx0aWNhc3QgZWNobyByZXF1ZXN0cyBpZ25vcmVkCgkwIG11 bHRpY2FzdCB0aW1lc3RhbXAgcmVxdWVzdHMgaWdub3JlZAoJSW5wdXQgaGlzdG9ncmFtOgoJ CWVjaG8gcmVwbHk6IDQxNgoJCWRlc3RpbmF0aW9uIHVucmVhY2hhYmxlOiAyMDcKCQlzb3Vy Y2UgcXVlbmNoOiA2CgkJcm91dGluZyByZWRpcmVjdDogMTM0CgkJZWNobzogMjk5NTU3CgkJ cm91dGVyIHNvbGljaXRhdGlvbjogMjc5CgkJdGltZSBleGNlZWRlZDogMjE1NAoJMjk5NTI4 IG1lc3NhZ2UgcmVzcG9uc2VzIGdlbmVyYXRlZAoJMCBpbnZhbGlkIHJldHVybiBhZGRyZXNz ZXMKCTAgbm8gcmV0dXJuIHJvdXRlcwppZ21wOgoJMjkwMiBtZXNzYWdlcyByZWNlaXZlZAoJ MCBtZXNzYWdlcyByZWNlaXZlZCB3aXRoIHRvbyBmZXcgYnl0ZXMKCTAgbWVzc2FnZXMgcmVj ZWl2ZWQgd2l0aCB3cm9uZyBUVEwKCTAgbWVzc2FnZXMgcmVjZWl2ZWQgd2l0aCBiYWQgY2hl Y2tzdW0KCTAgVjEvVjIgbWVtYmVyc2hpcCBxdWVyaWVzIHJlY2VpdmVkCgkwIFYzIG1lbWJl cnNoaXAgcXVlcmllcyByZWNlaXZlZAoJMCBtZW1iZXJzaGlwIHF1ZXJpZXMgcmVjZWl2ZWQg d2l0aCBpbnZhbGlkIGZpZWxkKHMpCgkwIGdlbmVyYWwgcXVlcmllcyByZWNlaXZlZAoJMCBn cm91cCBxdWVyaWVzIHJlY2VpdmVkCgkwIGdyb3VwLXNvdXJjZSBxdWVyaWVzIHJlY2VpdmVk CgkwIGdyb3VwLXNvdXJjZSBxdWVyaWVzIGRyb3BwZWQKCTM2IG1lbWJlcnNoaXAgcmVwb3J0 cyByZWNlaXZlZAoJMCBtZW1iZXJzaGlwIHJlcG9ydHMgcmVjZWl2ZWQgd2l0aCBpbnZhbGlk IGZpZWxkKHMpCgkwIG1lbWJlcnNoaXAgcmVwb3J0cyByZWNlaXZlZCBmb3IgZ3JvdXBzIHRv IHdoaWNoIHdlIGJlbG9uZwoJMCBWMyByZXBvcnRzIHJlY2VpdmVkIHdpdGhvdXQgUm91dGVy IEFsZXJ0CgkwIG1lbWJlcnNoaXAgcmVwb3J0cyBzZW50CmFycDoKCTIzMzIzNjAgQVJQIHJl cXVlc3RzIHNlbnQKCTYyNTI4OSBBUlAgcmVwbGllcyBzZW50Cgk0MTI3MTY5IEFSUCByZXF1 ZXN0cyByZWNlaXZlZAoJNzc1NzYgQVJQIHJlcGxpZXMgcmVjZWl2ZWQKCTQyMDQ3NDUgQVJQ IHBhY2tldHMgcmVjZWl2ZWQKCTE5NDM1OTIgdG90YWwgcGFja2V0cyBkcm9wcGVkIGR1ZSB0 byBubyBBUlAgZW50cnkKCTM1Nzk4NyBBUlAgZW50cnlzIHRpbWVkIG91dAoJMCBEdXBsaWNh dGUgSVBzIHNlZW4KaXA2OgoJNDY5IHRvdGFsIHBhY2tldHMgcmVjZWl2ZWQKCTAgd2l0aCBz aXplIHNtYWxsZXIgdGhhbiBtaW5pbXVtCgkwIHdpdGggZGF0YSBzaXplIDwgZGF0YSBsZW5n dGgKCTAgd2l0aCBiYWQgb3B0aW9ucwoJMCB3aXRoIGluY29ycmVjdCB2ZXJzaW9uIG51bWJl cgoJMCBmcmFnbWVudHMgcmVjZWl2ZWQKCTAgZnJhZ21lbnRzIGRyb3BwZWQgKGR1cCBvciBv dXQgb2Ygc3BhY2UpCgkwIGZyYWdtZW50cyBkcm9wcGVkIGFmdGVyIHRpbWVvdXQKCTAgZnJh Z21lbnRzIHRoYXQgZXhjZWVkZWQgbGltaXQKCTAgcGFja2V0cyByZWFzc2VtYmxlZCBvawoJ MTQgcGFja2V0cyBmb3IgdGhpcyBob3N0CgkwIHBhY2tldHMgZm9yd2FyZGVkCgkwIHBhY2tl dHMgbm90IGZvcndhcmRhYmxlCgkwIHJlZGlyZWN0cyBzZW50CgkxMyBwYWNrZXRzIHNlbnQg ZnJvbSB0aGlzIGhvc3QKCTAgcGFja2V0cyBzZW50IHdpdGggZmFicmljYXRlZCBpcCBoZWFk ZXIKCTAgb3V0cHV0IHBhY2tldHMgZHJvcHBlZCBkdWUgdG8gbm8gYnVmcywgZXRjLgoJNDA4 NjQxIG91dHB1dCBwYWNrZXRzIGRpc2NhcmRlZCBkdWUgdG8gbm8gcm91dGUKCTAgb3V0cHV0 IGRhdGFncmFtcyBmcmFnbWVudGVkCgkwIGZyYWdtZW50cyBjcmVhdGVkCgkwIGRhdGFncmFt cyB0aGF0IGNhbid0IGJlIGZyYWdtZW50ZWQKCTAgcGFja2V0cyB0aGF0IHZpb2xhdGVkIHNj b3BlIHJ1bGVzCgkxIG11bHRpY2FzdCBwYWNrZXQgd2hpY2ggd2UgZG9uJ3Qgam9pbgoJSW5w dXQgaGlzdG9ncmFtOgoJCWhvcCBieSBob3A6IDE5CgkJVURQOiAzNDQKCQlJQ01QNjogMTA2 CglNYnVmIHN0YXRpc3RpY3M6CgkJMTMgb25lIG1idWYKCQk0NTYgb25lIGV4dCBtYnVmCgkJ MCB0d28gb3IgbW9yZSBleHQgbWJ1ZgoJMCBwYWNrZXRzIHdob3NlIGhlYWRlcnMgYXJlIG5v dCBjb250aW51b3VzCgkwIHR1bm5lbGluZyBwYWNrZXRzIHRoYXQgY2FuJ3QgZmluZCBnaWYK CTAgcGFja2V0cyBkaXNjYXJkZWQgYmVjYXVzZSBvZiB0b28gbWFueSBoZWFkZXJzCgkwIGZh aWx1cmVzIG9mIHNvdXJjZSBhZGRyZXNzIHNlbGVjdGlvbgoJU291cmNlIGFkZHJlc3NlcyBz ZWxlY3Rpb24gcnVsZSBhcHBsaWVkOgoJCTEzIGZpcnN0IGNhbmRpZGF0ZQoJCTEzIHNhbWUg YWRkcmVzcwppY21wNjoKCTAgY2FsbHMgdG8gaWNtcDZfZXJyb3IKCTAgZXJyb3JzIG5vdCBn ZW5lcmF0ZWQgaW4gcmVzcG9uc2UgdG8gYW4gaWNtcDYgbWVzc2FnZQoJMCBlcnJvcnMgbm90 IGdlbmVyYXRlZCBiZWNhdXNlIG9mIHJhdGUgbGltaXRhdGlvbgoJMCBtZXNzYWdlcyB3aXRo IGJhZCBjb2RlIGZpZWxkcwoJMCBtZXNzYWdlcyA8IG1pbmltdW0gbGVuZ3RoCgkwIGJhZCBj aGVja3N1bXMKCTAgbWVzc2FnZXMgd2l0aCBiYWQgbGVuZ3RoCglIaXN0b2dyYW0gb2YgZXJy b3IgbWVzc2FnZXMgdG8gYmUgZ2VuZXJhdGVkOgoJCTAgbm8gcm91dGUKCQkwIGFkbWluaXN0 cmF0aXZlbHkgcHJvaGliaXRlZAoJCTAgYmV5b25kIHNjb3BlCgkJMCBhZGRyZXNzIHVucmVh Y2hhYmxlCgkJMCBwb3J0IHVucmVhY2hhYmxlCgkJMCBwYWNrZXQgdG9vIGJpZwoJCTAgdGlt ZSBleGNlZWQgdHJhbnNpdAoJCTAgdGltZSBleGNlZWQgcmVhc3NlbWJseQoJCTAgZXJyb25l b3VzIGhlYWRlciBmaWVsZAoJCTAgdW5yZWNvZ25pemVkIG5leHQgaGVhZGVyCgkJMCB1bnJl Y29nbml6ZWQgb3B0aW9uCgkJMCByZWRpcmVjdAoJCTAgdW5rbm93bgoJMCBtZXNzYWdlIHJl c3BvbnNlcyBnZW5lcmF0ZWQKCTAgbWVzc2FnZXMgd2l0aCB0b28gbWFueSBORCBvcHRpb25z CgkwIG1lc3NhZ2VzIHdpdGggYmFkIE5EIG9wdGlvbnMKCTAgYmFkIG5laWdoYm9yIHNvbGlj aXRhdGlvbiBtZXNzYWdlcwoJMCBiYWQgbmVpZ2hib3IgYWR2ZXJ0aXNlbWVudCBtZXNzYWdl cwoJMCBiYWQgcm91dGVyIHNvbGljaXRhdGlvbiBtZXNzYWdlcwoJMCBiYWQgcm91dGVyIGFk dmVydGlzZW1lbnQgbWVzc2FnZXMKCTAgYmFkIHJlZGlyZWN0IG1lc3NhZ2VzCgkwIHBhdGgg TVRVIGNoYW5nZXMKcmlwNjoKCTAgbWVzc2FnZXMgcmVjZWl2ZWQKCTAgY2hlY2tzdW0gY2Fs Y3VsYXRpb25zIG9uIGluYm91bmQKCTAgbWVzc2FnZXMgd2l0aCBiYWQgY2hlY2tzdW0KCTAg bWVzc2FnZXMgZHJvcHBlZCBkdWUgdG8gbm8gc29ja2V0CgkwIG11bHRpY2FzdCBtZXNzYWdl cyBkcm9wcGVkIGR1ZSB0byBubyBzb2NrZXQKCTAgbWVzc2FnZXMgZHJvcHBlZCBkdWUgdG8g ZnVsbCBzb2NrZXQgYnVmZmVycwoJMCBkZWxpdmVyZWQKCTAgZGF0YWdyYW1zIG91dHB1dAoK LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tCm5ldHN0YXQgLW0KCjIzNDYvNDc3NC83MTIwIG1idWZzIGlu IHVzZSAoY3VycmVudC9jYWNoZS90b3RhbCkKMTI2OS8zMTg5LzQ0NTgvMjU2MDAgbWJ1ZiBj bHVzdGVycyBpbiB1c2UgKGN1cnJlbnQvY2FjaGUvdG90YWwvbWF4KQoyMzQ0LzIxNzEgbWJ1 ZitjbHVzdGVycyBvdXQgb2YgcGFja2V0IHNlY29uZGFyeSB6b25lIGluIHVzZSAoY3VycmVu dC9jYWNoZSkKMC8xMDE5LzEwMTkvMTI4MDAgNGsgKHBhZ2Ugc2l6ZSkganVtYm8gY2x1c3Rl cnMgaW4gdXNlIChjdXJyZW50L2NhY2hlL3RvdGFsL21heCkKMC8wLzAvMTkyMDAgOWsganVt Ym8gY2x1c3RlcnMgaW4gdXNlIChjdXJyZW50L2NhY2hlL3RvdGFsL21heCkKMC8wLzAvMTI4 MDAgMTZrIGp1bWJvIGNsdXN0ZXJzIGluIHVzZSAoY3VycmVudC9jYWNoZS90b3RhbC9tYXgp CjMxOThLLzExNjQ3Sy8xNDg0NUsgYnl0ZXMgYWxsb2NhdGVkIHRvIG5ldHdvcmsgKGN1cnJl bnQvY2FjaGUvdG90YWwpCjAvMC8wIHJlcXVlc3RzIGZvciBtYnVmcyBkZW5pZWQgKG1idWZz L2NsdXN0ZXJzL21idWYrY2x1c3RlcnMpCjAvMC8wIHJlcXVlc3RzIGZvciBqdW1ibyBjbHVz dGVycyBkZW5pZWQgKDRrLzlrLzE2aykKMCByZXF1ZXN0cyBmb3Igc2ZidWZzIGRlbmllZAow IHJlcXVlc3RzIGZvciBzZmJ1ZnMgZGVsYXllZAowIHJlcXVlc3RzIGZvciBJL08gaW5pdGlh dGVkIGJ5IHNlbmRmaWxlCjAgY2FsbHMgdG8gcHJvdG9jb2wgZHJhaW4gcm91dGluZXMKCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQpuZXRzdGF0IC1pZAoKQnVzIGVycm9yCgotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0KbmV0c3RhdCAtYW5yCgpSb3V0aW5nIHRhYmxlcwoKSW50ZXJuZXQ6CkRlc3RpbmF0 aW9uICAgICAgICBHYXRld2F5ICAgICAgICAgICAgRmxhZ3MgICAgUmVmcyAgICAgIFVzZSAg TmV0aWYgRXhwaXJlCmRlZmF1bHQgICAgICAgICAgICAxMDAuMTAwLjEwNi4xICAgICAgIFVH UyAgICAgICAgIDEgODQ2MTQwNDMxNiB2bGFuMjAKMTAuMi43LjAvMjQgICAgICAgIDEwMC4x MDAuMTA2LjI0ICAgICAgVUdTICAgICAgICAgMCAgICAgIDM1NCB2bGFuMjAKMTAuMi42My4w LzI0ICAgICAgIDEwMC4xMDAuMTA2LjI0ICAgICAgVUdTICAgICAgICAgMCAgICAgIDY2NiB2 bGFuMjAKMTAuMTAxLjEuMC8yNCAgICAgIGxpbmsjNSAgICAgICAgICAgICBVICAgICAgICAg ICAwICAgMTcyMDcxIHZsYW4yMAoxMC4xMDEuMS4yNTAgICAgICAgbGluayM1ICAgICAgICAg ICAgIFVIUyAgICAgICAgIDAgICAgICAgIDAgICAgbG8wCjEwLjI0MS43LjAvMjQgICAgICBs aW5rIzcgICAgICAgICAgICAgVSAgICAgICAgICAgMCAgICAxMzY2MiB2bGFuMjAKMTAuMjQx LjcuMjUwICAgICAgIGxpbmsjNyAgICAgICAgICAgICBVSFMgICAgICAgICAwICAgICAgICAw ICAgIGxvMAoxMC4yNDIuNy4wLzI0ICAgICAgbGluayM2ICAgICAgICAgICAgIFUgICAgICAg ICAgIDAgICAgMjI1MTEgdmxhbjIwCjEwLjI0Mi43LjI1MCAgICAgICBsaW5rIzYgICAgICAg ICAgICAgVUhTICAgICAgICAgMCAgICAgICAgMCAgICBsbzAKNzkuOTguMTQ0LjAvMjkgICAg IGxpbmsjMzAgICAgICAgICAgICBVICAgICAgICAgICAwICAzODM0MDg5IHZsYW44Ngo3OS45 OC4xNDQuMSAgICAgICAgbGluayMzMCAgICAgICAgICAgIFVIUyAgICAgICAgIDAgICAgICAg IDAgICAgbG8wCjc5Ljk4LjE0NC44LzMwICAgICBsaW5rIzEyICAgICAgICAgICAgVSAgICAg ICAgICAgMCAxNzc5MDYwMiB2bGFuMTcKNzkuOTguMTQ0LjkgICAgICAgIGxpbmsjMTIgICAg ICAgICAgICBVSFMgICAgICAgICAwICAgICAgICAwICAgIGxvMAo3OS45OC4xNDQuMTIvMzAg ICAgbGluayM0MiAgICAgICAgICAgIFUgICAgICAgICAgIDAgICAgIDYyMDUgdmxhbjE2Cjc5 Ljk4LjE0NC4xMyAgICAgICBsaW5rIzQyICAgICAgICAgICAgVUhTICAgICAgICAgMCAgICAg ICAgMCAgICBsbzAKNzkuOTguMTQ0LjE2LzI5ICAgIGxpbmsjMzYgICAgICAgICAgICBVICAg ICAgICAgICAwICA0MDU1MTU1IHZsYW4xMQo3OS45OC4xNDQuMTcgICAgICAgbGluayMzNiAg ICAgICAgICAgIFVIUyAgICAgICAgIDAgICAgICAgIDAgICAgbG8wCjc5Ljk4LjE0NC4yNC8y OSAgICBsaW5rIzUwICAgICAgICAgICAgVSAgICAgICAgICAgMCAgIDcwOTkwOCB2bGFuMjkK NzkuOTguMTQ0LjI1ICAgICAgIGxpbmsjNTAgICAgICAgICAgICBVSFMgICAgICAgICAwICAg ICAgICAwICAgIGxvMAo3OS45OC4xNDQuMzIvMjggICAgbGluayMxMCAgICAgICAgICAgIFUg ICAgICAgICAgIDAgMTI2NzY5NjcgdmxhbjEzCjc5Ljk4LjE0NC4zMyAgICAgICBsaW5rIzEw ICAgICAgICAgICAgVUhTICAgICAgICAgMCAgICAgICAgMCAgICBsbzAKNzkuOTguMTQ0LjY0 LzI5ICAgIGxpbmsjMjIgICAgICAgICAgICBVICAgICAgICAgICAwICA1MTQ3MjA2IHZsYW40 Ngo3OS45OC4xNDQuNjUgICAgICAgbGluayMyMiAgICAgICAgICAgIFVIUyAgICAgICAgIDAg ICAgICAgIDAgICAgbG8wCjc5Ljk4LjE0NC43Mi8yOSAgICBsaW5rIzM0ICAgICAgICAgICAg VSAgICAgICAgICAgMCAzMjg5NTM0NyB2bGFuMTAKNzkuOTguMTQ0LjczICAgICAgIGxpbmsj MzQgICAgICAgICAgICBVSFMgICAgICAgICAwICAgICAgICAwICAgIGxvMAo3OS45OC4xNDQu OTYvMjkgICAgbGluayM0OSAgICAgICAgICAgIFUgICAgICAgICAgIDAgMTcyNjM0MzYgdmxh bjQwCjc5Ljk4LjE0NC45NyAgICAgICBsaW5rIzQ5ICAgICAgICAgICAgVUhTICAgICAgICAg MCAgICAgICAgMCAgICBsbzAKNzkuOTguMTQ0LjExMi8yOCAgIDEwMC4xMDAuMTA2LjIxOCAg ICAgVUdTICAgICAgICAgMCAgICAzNzEzOCB2bGFuMjAKNzkuOTguMTQ0LjE0MC8zMCAgIGxp bmsjMjcgICAgICAgICAgICBVICAgICAgICAgICAwICAgICA1Mjk0IHZsYW44MAo3OS45OC4x NDQuMTQxICAgICAgbGluayMyNyAgICAgICAgICAgIFVIUyAgICAgICAgIDAgICAgICAgIDAg ICAgbG8wCjc5Ljk4LjE0NC4xNDQvMjggICAxMDAuMTAwLjEwNi4xMCAgICAgIFVHUyAgICAg ICAgIDAgICA3MzY5ODggdmxhbjIwCjc5Ljk4LjE0NC4xNjAvMjkgICBsaW5rIzM1ICAgICAg ICAgICAgVSAgICAgICAgICAgMCAgNzA4NDI5OCB2bGFuMTEKNzkuOTguMTQ0LjE2MSAgICAg IGxpbmsjMzUgICAgICAgICAgICBVSFMgICAgICAgICAwICAgICAgICAwICAgIGxvMAo3OS45 OC4xNDQuMTY4LzI5ICAgbGluayMxNyAgICAgICAgICAgIFUgICAgICAgICAgIDAgMTMyMTYz OTcgdmxhbjMzCjc5Ljk4LjE0NC4xNjkgICAgICBsaW5rIzE3ICAgICAgICAgICAgVUhTICAg ICAgICAgMCAgICAgICAgMCAgICBsbzAKNzkuOTguMTQ0LjE3Ni8yOSAgIDEwMC4xMDAuMTA2 LjEwICAgICAgVUdTICAgICAgICAgMCAzOTY0NjcyMSB2bGFuMjAKNzkuOTguMTQ0LjE5Mi8y OCAgIDEwMC4xMDAuMTA2LjEwICAgICAgVUdTICAgICAgICAgMCA2NzEyNzIxOSB2bGFuMjAK NzkuOTguMTQ0LjIwOC8yOSAgIDEwMC4xMDAuMTA2LjEwICAgICAgVUdTICAgICAgICAgMCAy NTg3OTA5OCB2bGFuMjAKNzkuOTguMTQ0LjIyNC8yNyAgIGxpbmsjMjQgICAgICAgICAgICBV ICAgICAgICAgICAwIDEwMzMyNzg5NCB2bGFuNTgKNzkuOTguMTQ0LjIyNSAgICAgIGxpbmsj MjQgICAgICAgICAgICBVSFMgICAgICAgICAwICAgICAgICAwICAgIGxvMAo3OS45OC4xNDUu MC8yOSAgICAgbGluayMxOCAgICAgICAgICAgIFUgICAgICAgICAgIDAgMTI4MTU4OTYgdmxh bjM1Cjc5Ljk4LjE0NS4xICAgICAgICBsaW5rIzE4ICAgICAgICAgICAgVUhTICAgICAgICAg MCAgICAgICAgMCAgICBsbzAKNzkuOTguMTQ1LjgvMjkgICAgIDEwMC4xMDAuMTA2LjEwICAg ICAgVUdTICAgICAgICAgMCAzODQxMjg0MiB2bGFuMjAKNzkuOTguMTQ1LjE2LzI5ICAgIDEw MC4xMDAuMTA2LjEwICAgICAgVUdTICAgICAgICAgMCAxMTU5MzI1NSB2bGFuMjAKNzkuOTgu MTQ1LjI0LzI5ICAgIGxpbmsjMzkgICAgICAgICAgICBVICAgICAgICAgICAwIDE5MTU3ODAz IHZsYW4xNQo3OS45OC4xNDUuMjUgICAgICAgbGluayMzOSAgICAgICAgICAgIFVIUyAgICAg ICAgIDAgICAgICAgIDAgICAgbG8wCjc5Ljk4LjE0NS4zMi8yNyAgICBsaW5rIzQ2ICAgICAg ICAgICAgVSAgICAgICAgICAgMCA3Njg0MjYwNjIgdmxhbjIwCjc5Ljk4LjE0NS4zMyAgICAg ICBsaW5rIzQ2ICAgICAgICAgICAgVUhTICAgICAgICAgMCAgICAgICAgMCAgICBsbzAKNzku OTguMTQ1LjY0LzI4ICAgIDc5Ljk4LjE1MS4yICAgICAgICBVR1MgICAgICAgICAwIDE2MTQ1 ODQ2IHZsYW45OQo3OS45OC4xNDUuODAvMjggICAgbGluayMzMiAgICAgICAgICAgIFUgICAg ICAgICAgIDAgMzE1MDQxMDMgdmxhbjEwCjc5Ljk4LjE0NS44MSAgICAgICBsaW5rIzMyICAg ICAgICAgICAgVUhTICAgICAgICAgMCAgICAgICAgMCAgICBsbzAKNzkuOTguMTQ1Ljk2LzI4 ICAgIDEwMC4xMDAuMTA2LjEwICAgICAgVUdTICAgICAgICAgMCAgOTM4NjE2MiB2bGFuMjAK NzkuOTguMTQ1LjExMi8yOSAgIGxpbmsjMTkgICAgICAgICAgICBVICAgICAgICAgICAwIDg3 OTgxMTkxMyB2bGFuMzYKNzkuOTguMTQ1LjExMyAgICAgIGxpbmsjMTkgICAgICAgICAgICBV SFMgICAgICAgICAwICAgICAgICAwICAgIGxvMAo3OS45OC4xNDUuMTIwLzI5ICAgbGluayMy MyAgICAgICAgICAgIFUgICAgICAgICAgIDAgNjg5OTA1NDEgdmxhbjQ5Cjc5Ljk4LjE0NS4x MjEgICAgICBsaW5rIzIzICAgICAgICAgICAgVUhTICAgICAgICAgMCAgICAgICAgMCAgICBs bzAKNzkuOTguMTQ1LjEyOC8yOSAgIDEwMC4xMDAuMTA2LjEwICAgICAgVUdTICAgICAgICAg MCA1OTg2MzU0MyB2bGFuMjAKNzkuOTguMTQ1LjEzNi8yOSAgIDEwMC4xMDAuMTA2LjE1NCAg ICAgVUdTICAgICAgICAgMCAgICA4NzA0MCB2bGFuMzEKNzkuOTguMTQ1LjE0NC8zMCAgIDEw MC4xMDAuMTA2LjEwICAgICAgVUdTICAgICAgICAgMCAgICA4MTMxMyB2bGFuMjAKNzkuOTgu MTQ1LjE0OC8zMCAgIGxpbmsjMjkgICAgICAgICAgICBVICAgICAgICAgICAwICAgNTQ5NzYz IHZsYW44Mgo3OS45OC4xNDUuMTQ5ICAgICAgbGluayMyOSAgICAgICAgICAgIFVIUyAgICAg ICAgIDAgICAgICAgIDAgICAgbG8wCjc5Ljk4LjE0NS4xNTIvMjkgICAxMDAuMTAwLjEwNi4x MCAgICAgIFVHUyAgICAgICAgIDAgMzY0NzYzMjggdmxhbjIwCjc5Ljk4LjE0NS4xNjAvMjkg ICBsaW5rIzI4ICAgICAgICAgICAgVSAgICAgICAgICAgMCAgNDMxNDA2OSB2bGFuODEKNzku OTguMTQ1LjE2MSAgICAgIGxpbmsjMjggICAgICAgICAgICBVSFMgICAgICAgICAwICAgICAg ICAwICAgIGxvMAo3OS45OC4xNDUuMTc2LzI5ICAgMTAwLjEwMC4xMDYuMTAgICAgICBVR1Mg ICAgICAgICAwICA5NDM4MTQxIHZsYW4yMAo3OS45OC4xNDUuMTg0LzMwICAgbGluayM0MSAg ICAgICAgICAgIFUgICAgICAgICAgIDAgNTY4MjEyMjYgdmxhbjE2Cjc5Ljk4LjE0NS4xODUg ICAgICBsaW5rIzQxICAgICAgICAgICAgVUhTICAgICAgICAgMCAgICAgICAgMCAgICBsbzAK NzkuOTguMTQ1LjE5Mi8yOSAgIDEwMC4xMDAuMTA2LjEwICAgICAgVUdTICAgICAgICAgMCA3 MTY5MzQxOCB2bGFuMjAKNzkuOTguMTQ1LjIwMC8yOSAgIDEwMC4xMDAuMTA2LjEwICAgICAg VUdTICAgICAgICAgMCA5MzEwNDc0NyB2bGFuMjAKNzkuOTguMTQ1LjIwOC8yOSAgIGxpbmsj NDMgICAgICAgICAgICBVICAgICAgICAgICAwICAgIDEwOTU2IHZsYW4xNwo3OS45OC4xNDUu MjA5ICAgICAgbGluayM0MyAgICAgICAgICAgIFVIUyAgICAgICAgIDAgICAgICAgIDAgICAg bG8wCjc5Ljk4LjE0NS4yMTYvMjkgICBsaW5rIzQ0ICAgICAgICAgICAgVSAgICAgICAgICAg MCAxMDI5NTIzNzkgdmxhbjE3Cjc5Ljk4LjE0NS4yMTcgICAgICBsaW5rIzQ0ICAgICAgICAg ICAgVUhTICAgICAgICAgMCAgICAgICAgMCAgICBsbzAKNzkuOTguMTQ1LjIyNC8yOSAgIGxp bmsjNDUgICAgICAgICAgICBVICAgICAgICAgICAwIDEyOTUxMDU1IHZsYW4xNwo3OS45OC4x NDUuMjI1ICAgICAgbGluayM0NSAgICAgICAgICAgIFVIUyAgICAgICAgIDAgICAgICAgIDAg ICAgbG8wCjc5Ljk4LjE0NS4yMzIvMjkgICBsaW5rIzQwICAgICAgICAgICAgVSAgICAgICAg ICAgMCAgICAgOTY2NSB2bGFuMTUKNzkuOTguMTQ1LjIzMyAgICAgIGxpbmsjNDAgICAgICAg ICAgICBVSFMgICAgICAgICAwICAgICAgICAwICAgIGxvMAo3OS45OC4xNDYuMC8yNSAgICAg MTAwLjEwMC4xMDYuMTE4ICAgICBVR1MgICAgICAgICAwIDExMjA4ODE1NSB2bGFuMTAKNzku OTguMTQ2LjEyOC8yOSAgIGxpbmsjMzcgICAgICAgICAgICBVICAgICAgICAgICAwIDM3NjQy MzY2IHZsYW4xMQo3OS45OC4xNDYuMTI5ICAgICAgbGluayMzNyAgICAgICAgICAgIFVIUyAg ICAgICAgIDAgICAgICAgIDAgICAgbG8wCjc5Ljk4LjE0Ni4xMzYvMjkgICBsaW5rIzE0ICAg ICAgICAgICAgVSAgICAgICAgICAgMCAgMzU2ODA4MiB2bGFuMjUKNzkuOTguMTQ2LjEzNyAg ICAgIGxpbmsjMTQgICAgICAgICAgICBVSFMgICAgICAgICAwICAgICAgICAwICAgIGxvMAo3 OS45OC4xNDYuMTQ0LzI5ICAgbGluayMxNSAgICAgICAgICAgIFUgICAgICAgICAgIDAgIDQ4 Mjg1OTcgdmxhbjI4Cjc5Ljk4LjE0Ni4xNDUgICAgICBsaW5rIzE1ICAgICAgICAgICAgVUhT ICAgICAgICAgMCAgICAgICAgMCAgICBsbzAKNzkuOTguMTQ2LjE1Mi8yOSAgIGxpbmsjOSAg ICAgICAgICAgICBVICAgICAgICAgICAwICA2NTg2MjMwIHZsYW4xMgo3OS45OC4xNDYuMTUz ICAgICAgbGluayM5ICAgICAgICAgICAgIFVIUyAgICAgICAgIDAgICAgICAgIDAgICAgbG8w Cjc5Ljk4LjE1MS4wLzMwICAgICBsaW5rIzMxICAgICAgICAgICAgVSAgICAgICAgICAgMCAg ICAgOTA4NyB2bGFuOTkKNzkuOTguMTUxLjEgICAgICAgIGxpbmsjMzEgICAgICAgICAgICBV SFMgICAgICAgICAwICAgICAgICAwICAgIGxvMAoxMjcuMC4wLjEgICAgICAgICAgbGluayM0 ICAgICAgICAgICAgIFVIICAgICAgICAgIDAgICAgICAgNjQgICAgbG8wCjE5Mi4xNjguMC4w LzE2ICAgICAxMDAuMTAwLjEwNi4yNCAgICAgIFVHUyAgICAgICAgIDAgNzI0MDc2MjY0OCB2 bGFuMjAKMTAwLjEwMC4xMDYuMC8yNyAgICBsaW5rIzggICAgICAgICAgICAgVSAgICAgICAg ICAgMCA0MzE1NDk3MzcyIHZsYW4yMAoxMDAuMTAwLjEwNi44ICAgICAgIGxpbmsjOCAgICAg ICAgICAgICBVSFMgICAgICAgICAwICAgICAgICAwICAgIGxvMAoxMDAuMTAwLjEwNi4yOSAg ICAgIGxpbmsjOCAgICAgICAgICAgICBVSFMgICAgICAgICAwICAgICAgIDk0ICAgIGxvMCA9 PgoxMDAuMTAwLjEwNi4yOS8zMiAgIGxpbmsjOCAgICAgICAgICAgICBVICAgICAgICAgICAw ICAgICAgICAwIHZsYW4yMAoxMDAuMTAwLjEwNi4zMi8yNyAgIGxpbmsjMjAgICAgICAgICAg ICBVICAgICAgICAgICAwICA4MzkxMjI4IHZsYW4zNwoxMDAuMTAwLjEwNi4zMyAgICAgIGxp bmsjMjAgICAgICAgICAgICBVSFMgICAgICAgICAwICAgICAgICAwICAgIGxvMAoxMDAuMTAw LjEwNi4xMTIvMzAgIGxpbmsjMzggICAgICAgICAgICBVICAgICAgICAgICAwIDEwMzg3NDky NyB2bGFuMTQKMTAwLjEwMC4xMDYuMTEzICAgICBsaW5rIzM4ICAgICAgICAgICAgVUhTICAg ICAgICAgMCAgICAgICAgMCAgICBsbzAKMTAwLjEwMC4xMDYuMTE2LzMwICBsaW5rIzMzICAg ICAgICAgICAgVSAgICAgICAgICAgMCAgMTAzNjg5OSB2bGFuMTAKMTAwLjEwMC4xMDYuMTE3 ICAgICBsaW5rIzMzICAgICAgICAgICAgVUhTICAgICAgICAgMCAgICAgICAgMCAgICBsbzAK MTAwLjEwMC4xMDYuMTI0LzMwICBsaW5rIzQ4ICAgICAgICAgICAgVSAgICAgICAgICAgMCAg MjYyNTY2MiB2bGFuMjEKMTAwLjEwMC4xMDYuMTI1ICAgICBsaW5rIzQ4ICAgICAgICAgICAg VUhTICAgICAgICAgMCAgICAgICAgMCAgICBsbzAKMTAwLjEwMC4xMDYuMTI4LzI5ICBsaW5r IzIxICAgICAgICAgICAgVSAgICAgICAgICAgMCAgNjkzNTI2MCB2bGFuNDQKMTAwLjEwMC4x MDYuMTI5ICAgICBsaW5rIzIxICAgICAgICAgICAgVUhTICAgICAgICAgMCAgICAgICAgMCAg ICBsbzAKMTAwLjEwMC4xMDYuMTM2LzI5ICAxMDAuMTAwLjEwNi4xMCAgICAgIFVHUyAgICAg ICAgIDAgICAgMTczMTUgdmxhbjIwCjEwMC4xMDAuMTA2LjE0NC8yOSAgMTAwLjEwMC4xMDYu MTAgICAgICBVR1MgICAgICAgICAwICAgIDE2NjMyIHZsYW4yMAoxMDAuMTAwLjEwNi4xNTIv MzAgIGxpbmsjMTYgICAgICAgICAgICBVICAgICAgICAgICAwICAgICA3MzUzIHZsYW4zMQox MDAuMTAwLjEwNi4xNTMgICAgIGxpbmsjMTYgICAgICAgICAgICBVSFMgICAgICAgICAwICAg ICAgICAwICAgIGxvMAoxMDAuMTAwLjEwNi4xNjAvMjkgIGxpbmsjMjUgICAgICAgICAgICBV ICAgICAgICAgICAwICAgIDM4MjMzIHZsYW42NAoxMDAuMTAwLjEwNi4xNjEgICAgIGxpbmsj MjUgICAgICAgICAgICBVSFMgICAgICAgICAwICAgICAgICAwICAgIGxvMAoxMDAuMTAwLjEw Ni4xOTIvMjggIGxpbmsjMjYgICAgICAgICAgICBVICAgICAgICAgICAwIDUwMDIwNDc5MCB2 bGFuNzMKMTAwLjEwMC4xMDYuMTkzICAgICBsaW5rIzI2ICAgICAgICAgICAgVUhTICAgICAg ICAgMCAgICAgICAgMCAgICBsbzAKMTAwLjEwMC4xMDYuMjA4LzI5ICBsaW5rIzExICAgICAg ICAgICAgVSAgICAgICAgICAgMCAgMTAxNDk5NSB2bGFuMTQKMTAwLjEwMC4xMDYuMjA5ICAg ICBsaW5rIzExICAgICAgICAgICAgVUhTICAgICAgICAgMCAgICAgICAgMCAgICBsbzAKMTAw LjEwMC4xMDYuMjE2LzI5ICBsaW5rIzEzICAgICAgICAgICAgVSAgICAgICAgICAgMCA2NDk5 ODM5OCB2bGFuMjAKMTAwLjEwMC4xMDYuMjE3ICAgICBsaW5rIzEzICAgICAgICAgICAgVUhT ICAgICAgICAgMCAgICAgICAgMCAgICBsbzAKMTAwLjEwMC4xMDYuMjMyLzI5ICAxMDAuMTAw LjEwNi4xMCAgICAgIFVHUyAgICAgICAgIDAgICAgICAgIDAgdmxhbjIwCjEwMC4xMDAuMTA2 LjI0MC8yOCAgbGluayM0NyAgICAgICAgICAgIFUgICAgICAgICAgIDAgMTI5NDg1ODc1IHZs YW4yMQoxMDAuMTAwLjEwNi4yNDEgICAgIGxpbmsjNDcgICAgICAgICAgICBVSFMgICAgICAg ICAwICAgICAgICAwICAgIGxvMAoxMDAuMTAwLjEwNy4wLzI0ICAgIDEwMC4xMDAuMTA2LjI0 ICAgICAgVUdTICAgICAgICAgMCAxNjYxMzQwNDU1IHZsYW4yMAoKSW50ZXJuZXQ2OgpEZXN0 aW5hdGlvbiAgICAgICAgICAgICAgICAgICAgICAgR2F0ZXdheSAgICAgICAgICAgICAgICAg ICAgICAgRmxhZ3MgICAgICBOZXRpZiBFeHBpcmUKOjoxICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDo6MSAgICAgICAgICAgICAgICAgICAgICAgICAgIFVIICAgICAgICAgIGxv MApmZTgwOjolbG8wLzY0ICAgICAgICAgICAgICAgICAgICAgbGluayM0ICAgICAgICAgICAg ICAgICAgICAgICAgVSAgICAgICAgICAgbG8wCmZlODA6OjElbG8wICAgICAgICAgICAgICAg ICAgICAgICBsaW5rIzQgICAgICAgICAgICAgICAgICAgICAgICBVSFMgICAgICAgICBsbzAK ZmYwMTo0OjovMzIgICAgICAgICAgICAgICAgICAgICAgIGZlODA6OjElbG8wICAgICAgICAg ICAgICAgICAgIFUgICAgICAgICAgIGxvMApmZjAyOjolbG8wLzMyICAgICAgICAgICAgICAg ICAgICAgZmU4MDo6MSVsbzAgICAgICAgICAgICAgICAgICAgVSAgICAgICAgICAgbG8wCgot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0KbmV0c3RhdCAtYW5BCgpBY3RpdmUgSW50ZXJuZXQgY29ubmVj dGlvbnMgKGluY2x1ZGluZyBzZXJ2ZXJzKQpUY3BjYiAgICBQcm90byBSZWN2LVEgU2VuZC1R ICBMb2NhbCBBZGRyZXNzICAgICAgRm9yZWlnbiBBZGRyZXNzICAgKHN0YXRlKQpmZmZmZmYw MDQ4NGNjMDAwIHRjcDQgICAgICAgMCAgICAgIDAgKi4yMiAgICAgICAgICAgICAgICouKiAg ICAgICAgICAgICAgICBMSVNURU4KZmZmZmZmMDA0ODRjYzM3MCB0Y3A2ICAgICAgIDAgICAg ICAwICouMjIgICAgICAgICAgICAgICAqLiogICAgICAgICAgICAgICAgTElTVEVOCmZmZmZm ZjAwNDgyZDJhNTAgdGNwNiAgICAgICAwICAgICAgMCA6OjEuOTUzICAgICAgICAgICAgKi4q ICAgICAgICAgICAgICAgIExJU1RFTgpmZmZmZmYwMDQ4MmQyNmUwIHRjcDQgICAgICAgMCAg ICAgIDAgMTI3LjAuMC4xLjk1MyAgICAgICouKiAgICAgICAgICAgICAgICBMSVNURU4KZmZm ZmZmMDA0ODJkMjAwMCB0Y3A0ICAgICAgIDAgICAgICAwIDEwMC4xMDAuMTA2LjI5LjUzICAg Ki4qICAgICAgICAgICAgICAgIExJU1RFTgpmZmZmZmYwMDQ4MmQyMzcwIHRjcDQgICAgICAg MCAgICAgIDAgMTI3LjAuMC4xLjUzICAgICAgICouKiAgICAgICAgICAgICAgICBMSVNURU4K ZmZmZmZmMDA4OGFkZTAwMCB1ZHA0ICAgICAgIDAgICAgICAwIDc5Ljk4LjE0NC4yNS4xMjMg ICAqLiogICAgICAgICAgICAgICAgCmZmZmZmZjAwNDg1MTMyYTAgdWRwNCAgICAgICAwICAg ICAgMCAqLjY5ICAgICAgICAgICAgICAgKi4qICAgICAgICAgICAgICAgIApmZmZmZmYwMDQ4 NGYzNTQwIHVkcDQgICAgICAgMCAgICAgIDAgNzkuOTguMTQ0Ljk3LjEyMyAgICouKiAgICAg ICAgICAgICAgICAKZmZmZmZmMDAwNTllYjdlMCB1ZHA0ICAgICAgIDAgICAgICAwIDEwMC4x MDAuMTA2LjEyNS4xMjMgKi4qICAgICAgICAgICAgICAgIApmZmZmZmYwMDA1OWI1MTUwIHVk cDQgICAgICAgMCAgICAgIDAgMTAwLjEwMC4xMDYuMjQxLjEyMyAqLiogICAgICAgICAgICAg ICAgCmZmZmZmZjAwNDg1MTMzZjAgdWRwNCAgICAgICAwICAgICAgMCA3OS45OC4xNDUuMzMu MTIzICAgKi4qICAgICAgICAgICAgICAgIApmZmZmZmYwMDQ4NGU5NjkwIHVkcDQgICAgICAg MCAgICAgIDAgNzkuOTguMTQ1LjIyNS4xMjMgICouKiAgICAgICAgICAgICAgICAKZmZmZmZm MDA0ODUwMTE1MCB1ZHA0ICAgICAgIDAgICAgICAwIDc5Ljk4LjE0NS4yMTcuMTIzICAqLiog ICAgICAgICAgICAgICAgCmZmZmZmZjAwNDg0ZWFiZDAgdWRwNCAgICAgICAwICAgICAgMCA3 OS45OC4xNDUuMjA5LjEyMyAgKi4qICAgICAgICAgICAgICAgIApmZmZmZmYwMDQ4NGVhNTQw IHVkcDQgICAgICAgMCAgICAgIDAgNzkuOTguMTQ0LjEzLjEyMyAgICouKiAgICAgICAgICAg ICAgICAKZmZmZmZmMDA0ODJmOTY5MCB1ZHA0ICAgICAgIDAgICAgICAwIDc5Ljk4LjE0NS4x ODUuMTIzICAqLiogICAgICAgICAgICAgICAgCmZmZmZmZjAwNDgxN2QwMDAgdWRwNCAgICAg ICAwICAgICAgMCA3OS45OC4xNDUuMjMzLjEyMyAgKi4qICAgICAgICAgICAgICAgIApmZmZm ZmYwMDQ4MmY5YTgwIHVkcDQgICAgICAgMCAgICAgIDAgNzkuOTguMTQ1LjI1LjEyMyAgICou KiAgICAgICAgICAgICAgICAKZmZmZmZmMDA0ODUwMjdlMCB1ZHA0ICAgICAgIDAgICAgICAw IDEwMC4xMDAuMTA2LjExMy4xMjMgKi4qICAgICAgICAgICAgICAgIApmZmZmZmYwMDQ4MTdl MTUwIHVkcDQgICAgICAgMCAgICAgIDAgNzkuOTguMTQ2LjEyOS4xMjMgICouKiAgICAgICAg ICAgICAgICAKZmZmZmZmMDA0ODE3ZWJkMCB1ZHA0ICAgICAgIDAgICAgICAwIDc5Ljk4LjE0 NC4xNy4xMjMgICAqLiogICAgICAgICAgICAgICAgCmZmZmZmZjAwNDg1MTM1NDAgdWRwNCAg ICAgICAwICAgICAgMCA3OS45OC4xNDQuMTYxLjEyMyAgKi4qICAgICAgICAgICAgICAgIApm ZmZmZmYwMDQ4NTAwN2UwIHVkcDQgICAgICAgMCAgICAgIDAgNzkuOTguMTQ0LjczLjEyMyAg ICouKiAgICAgICAgICAgICAgICAKZmZmZmZmMDA0ODUwMjE1MCB1ZHA0ICAgICAgIDAgICAg ICAwIDEwMC4xMDAuMTA2LjExNy4xMjMgKi4qICAgICAgICAgICAgICAgIApmZmZmZmYwMDQ4 NTAyMDAwIHVkcDQgICAgICAgMCAgICAgIDAgNzkuOTguMTQ1LjgxLjEyMyAgICouKiAgICAg ICAgICAgICAgICAKZmZmZmZmMDA0ODRmMjE1MCB1ZHA0ICAgICAgIDAgICAgICAwIDc5Ljk4 LjE1MS4xLjEyMyAgICAqLiogICAgICAgICAgICAgICAgCmZmZmZmZjAwNDg0ZTk1NDAgdWRw NCAgICAgICAwICAgICAgMCA3OS45OC4xNDQuMS4xMjMgICAgKi4qICAgICAgICAgICAgICAg IApmZmZmZmYwMDA1OWViNTQwIHVkcDQgICAgICAgMCAgICAgIDAgNzkuOTguMTQ1LjE0OS4x MjMgICouKiAgICAgICAgICAgICAgICAKZmZmZmZmMDA0ODRlOTAwMCB1ZHA0ICAgICAgIDAg ICAgICAwIDc5Ljk4LjE0NS4xNjEuMTIzICAqLiogICAgICAgICAgICAgICAgCmZmZmZmZjAw NDg0ZTkxNTAgdWRwNCAgICAgICAwICAgICAgMCA3OS45OC4xNDQuMTQxLjEyMyAgKi4qICAg ICAgICAgICAgICAgIApmZmZmZmYwMDQ4MTdlN2UwIHVkcDQgICAgICAgMCAgICAgIDAgMTAw LjEwMC4xMDYuMTkzLjEyMyAqLiogICAgICAgICAgICAgICAgCmZmZmZmZjAwNDg0ZjMxNTAg dWRwNCAgICAgICAwICAgICAgMCAxMDAuMTAwLjEwNi4xNjEuMTIzICouKiAgICAgICAgICAg ICAgICAKZmZmZmZmMDAwNTliNTU0MCB1ZHA0ICAgICAgIDAgICAgICAwIDc5Ljk4LjE0NC4y MjUuMTIzICAqLiogICAgICAgICAgICAgICAgCmZmZmZmZjAwNDg1MDAxNTAgdWRwNCAgICAg ICAwICAgICAgMCA3OS45OC4xNDUuMTIxLjEyMyAgKi4qICAgICAgICAgICAgICAgIApmZmZm ZmYwMDA1OWViMmEwIHVkcDQgICAgICAgMCAgICAgIDAgNzkuOTguMTQ0LjY1LjEyMyAgICou KiAgICAgICAgICAgICAgICAKZmZmZmZmMDA0ODUwMWQyMCB1ZHA0ICAgICAgIDAgICAgICAw IDEwMC4xMDAuMTA2LjEyOS4xMjMgKi4qICAgICAgICAgICAgICAgIApmZmZmZmYwMDQ4MTdl MmEwIHVkcDQgICAgICAgMCAgICAgIDAgMTAwLjEwMC4xMDYuMzMuMTIzICAqLiogICAgICAg ICAgICAgICAgCmZmZmZmZjAwNDg0ZTk3ZTAgdWRwNCAgICAgICAwICAgICAgMCA3OS45OC4x NDUuMTEzLjEyMyAgKi4qICAgICAgICAgICAgICAgIApmZmZmZmYwMDQ4NGVhZDIwIHVkcDQg ICAgICAgMCAgICAgIDAgNzkuOTguMTQ1LjEuMTIzICAgICouKiAgICAgICAgICAgICAgICAK ZmZmZmZmMDA0ODUwMGJkMCB1ZHA0ICAgICAgIDAgICAgICAwIDc5Ljk4LjE0NC4xNjkuMTIz ICAqLiogICAgICAgICAgICAgICAgCmZmZmZmZjAwMDU5ZWMxNTAgdWRwNCAgICAgICAwICAg ICAgMCAxMDAuMTAwLjEwNi4xNTMuMTIzICouKiAgICAgICAgICAgICAgICAKZmZmZmZmMDA0 ODUwZTU0MCB1ZHA0ICAgICAgIDAgICAgICAwIDc5Ljk4LjE0Ni4xNDUuMTIzICAqLiogICAg ICAgICAgICAgICAgCmZmZmZmZjAwNDg0ZWEwMDAgdWRwNCAgICAgICAwICAgICAgMCA3OS45 OC4xNDYuMTM3LjEyMyAgKi4qICAgICAgICAgICAgICAgIApmZmZmZmYwMDA1OWYyN2UwIHVk cDQgICAgICAgMCAgICAgIDAgMTAwLjEwMC4xMDYuMjE3LjEyMyAqLiogICAgICAgICAgICAg ICAgCmZmZmZmZjAwMDU5ZWJkMjAgdWRwNCAgICAgICAwICAgICAgMCA3OS45OC4xNDQuOS4x MjMgICAgKi4qICAgICAgICAgICAgICAgIApmZmZmZmYwMDQ4NGYzOTMwIHVkcDQgICAgICAg MCAgICAgIDAgMTAwLjEwMC4xMDYuMjA5LjEyMyAqLiogICAgICAgICAgICAgICAgCmZmZmZm ZjAwNDg1MDEwMDAgdWRwNCAgICAgICAwICAgICAgMCA3OS45OC4xNDQuMzMuMTIzICAgKi4q ICAgICAgICAgICAgICAgIApmZmZmZmYwMDQ4MTdkNTQwIHVkcDQgICAgICAgMCAgICAgIDAg NzkuOTguMTQ2LjE1My4xMjMgICouKiAgICAgICAgICAgICAgICAKZmZmZmZmMDA0ODUwZGJk MCB1ZHA0ICAgICAgIDAgICAgICAwIDEwMC4xMDAuMTA2LjI5LjEyMyAgKi4qICAgICAgICAg ICAgICAgIApmZmZmZmYwMDQ4NGVhN2UwIHVkcDQgICAgICAgMCAgICAgIDAgMTAwLjEwMC4x MDYuOC4xMjMgICAqLiogICAgICAgICAgICAgICAgCmZmZmZmZjAwMDU5ZjIxNTAgdWRwNCAg ICAgICAwICAgICAgMCAxMC4yNDEuNy4yNTAuMTIzICAgKi4qICAgICAgICAgICAgICAgIApm ZmZmZmYwMDA1OWVjNTQwIHVkcDQgICAgICAgMCAgICAgIDAgMTAuMjQyLjcuMjUwLjEyMyAg ICouKiAgICAgICAgICAgICAgICAKZmZmZmZmMDAwNWZkYTdlMCB1ZHA0ICAgICAgIDAgICAg ICAwIDEwLjEwMS4xLjI1MC4xMjMgICAqLiogICAgICAgICAgICAgICAgCmZmZmZmZjAwNDgx N2QyYTAgdWRwNCAgICAgICAwICAgICAgMCAxMjcuMC4wLjEuMTIzICAgICAgKi4qICAgICAg ICAgICAgICAgIApmZmZmZmYwMDQ4NTAxYmQwIHVkcDYgICAgICAgMCAgICAgIDAgOjoxLjEy MyAgICAgICAgICAgICouKiAgICAgICAgICAgICAgICAKZmZmZmZmMDA0ODRmMjAwMCB1ZHA2 ICAgICAgIDAgICAgICAwIGZlODA6NDo6MS4xMjMgICAgICAqLiogICAgICAgICAgICAgICAg CmZmZmZmZjAwNDgxN2Q5MzAgdWRwNiAgICAgICAwICAgICAgMCAqLjEyMyAgICAgICAgICAg ICAgKi4qICAgICAgICAgICAgICAgIApmZmZmZmYwMDQ4NGYzYmQwIHVkcDQgICAgICAgMCAg ICAgIDAgKi4xMjMgICAgICAgICAgICAgICouKiAgICAgICAgICAgICAgICAKZmZmZmZmMDA0 ODJmOTdlMCB1ZHA0ICAgICAgIDAgICAgICAwIDEwMC4xMDAuMTA2LjI5LjUzICAgKi4qICAg ICAgICAgICAgICAgIApmZmZmZmYwMDQ4MmY5OTMwIHVkcDQgICAgICAgMCAgICAgIDAgMTI3 LjAuMC4xLjUzICAgICAgICouKiAgICAgICAgICAgICAgICAKZmZmZmZmMDAwNTllYzkzMCB1 ZHA0ICAgICAgIDAgICAgICAwICouNTE0ICAgICAgICAgICAgICAqLiogICAgICAgICAgICAg ICAgCkFjdGl2ZSBVTklYIGRvbWFpbiBzb2NrZXRzCkFkZHJlc3MgIFR5cGUgICBSZWN2LVEg U2VuZC1RICAgIElub2RlICAgICBDb25uICAgICBSZWZzICBOZXh0cmVmIEFkZHIKZmZmZmZm MDAwNTllZmUxMCBzdHJlYW0gICAgICAwICAgICAgMCBmZmZmZmYwMDA1OWU3YjEwICAgICAg ICAwICAgICAgICAwICAgICAgICAwIC92YXIvcnVuL2RldmQucGlwZQpmZmZmZmYwMDA1OWM4 OTYwIGRncmFtICAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZjAwMDU5ZWZhNTAgICAg ICAgIDAgZmZmZmZmMDA0ODIzODNjMApmZmZmZmYwMDQ4MjM4M2MwIGRncmFtICAgICAgIDAg ICAgICAwICAgICAgICAwIGZmZmZmZjAwMDU5ZWZhNTAgICAgICAgIDAgICAgICAgIDAKZmZm ZmZmMDAwNTllZmMzMCBkZ3JhbSAgICAgICAwICAgICAgMCBmZmZmZmYwMDQ4MDdjM2IwICAg ICAgICAwICAgICAgICAwICAgICAgICAwIC91c3IvbG9jYWwvZXRjL25hbWVkYi92YXIvcnVu L2xvZwpmZmZmZmYwMDA1OWVmYjQwIGRncmFtICAgICAgIDAgICAgICAwIGZmZmZmZjAwNDgx N2EwMDAgICAgICAgIDAgICAgICAgIDAgICAgICAgIDAgL3Zhci9ydW4vbG9nCmZmZmZmZjAw MDU5ZWZhNTAgZGdyYW0gICAgICAgMCAgICAgIDAgZmZmZmZmMDA0ODE3YTFkOCAgICAgICAg MCBmZmZmZmYwMDA1OWM4OTYwICAgICAgICAwIC92YXIvcnVuL2xvZ3ByaXYKZmZmZmZmMDAw NTllZjk2MCBkZ3JhbSAgICAgICAwICAgICAgMCBmZmZmZmYwMDQ4MTdhM2IwICAgICAgICAw ICAgICAgICAwICAgICAgICAwIC92YXIvcnVuL2xvZwoKLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCm5l dHN0YXQgLWFMCgpDdXJyZW50IGxpc3RlbiBxdWV1ZSBzaXplcyAocWxlbi9pbmNxbGVuL21h eHFsZW4pClByb3RvIExpc3RlbiAgICAgICAgIExvY2FsIEFkZHJlc3MgICAgICAgICAKdGNw NCAgMC8wLzEyOCAgICAgICAgKi5zc2ggICAgICAgICAgICAgICAgICAKdGNwNiAgMC8wLzEy OCAgICAgICAgKi5zc2ggICAgICAgICAgICAgICAgICAKdGNwNiAgMC8wLzEyOCAgICAgICAg bG9jYWxob3N0LnJuZGMgICAgICAgICAKdGNwNCAgMC8wLzEyOCAgICAgICAgbG9jYWxob3N0 LnJuZGMgICAgICAgICAKdGNwNCAgMC8wLzMgICAgICAgICAgZG5zLmRvbWFpbiAgICAgICAg ICAgICAKdGNwNCAgMC8wLzMgICAgICAgICAgbG9jYWxob3N0LmRvbWFpbiAgICAgICAKdW5p eCAgMC8wLzQgICAgICAgICAgL3Zhci9ydW4vZGV2ZC5waXBlCgotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0KZnN0YXQKClVTRVIgICAgIENNRCAgICAgICAgICBQSUQgICBGRCBNT1VOVCAgICAgIElO VU0gTU9ERSAgICAgICAgIFNafERWIFIvVwpyb290ICAgICBpcG1pMDoga2NzIDIxMzU3IHJv b3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcgpyb290ICAgICBpcG1p MDoga2NzIDIxMzU3ICAgd2QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAg cgpyb290ICAgICBnZXR0eSAgICAgICAzMTQ1IHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hy LXhyLXggICAgIDUxMiAgcgpyb290ICAgICBnZXR0eSAgICAgICAzMTQ1ICAgd2QgLyAgICAg ICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcgpyb290ICAgICBnZXR0eSAgICAgICAz MTQ1IHRleHQgL3VzciAgICAgMTAxOTgwNDIgLXIteHIteHIteCAgIDI3Nzg0ICByCnJvb3Qg ICAgIGdldHR5ICAgICAgIDMxNDQgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAg ICAgNTEyICByCnJvb3QgICAgIGdldHR5ICAgICAgIDMxNDQgICB3ZCAvICAgICAgICAgICAg IDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIGdldHR5ICAgICAgIDMxNDQgdGV4 dCAvdXNyICAgICAxMDE5ODA0MiAtci14ci14ci14ICAgMjc3ODQgIHIKcm9vdCAgICAgZ2V0 dHkgICAgICAgMzE0NCAgICAwIC9kZXYgICAgICAgICAzNyBjcnctLS0tLS0tICAgdHR5dTAg cncKcm9vdCAgICAgZ2V0dHkgICAgICAgMzE0NCAgICAxIC9kZXYgICAgICAgICAzNyBjcnct LS0tLS0tICAgdHR5dTAgcncKcm9vdCAgICAgZ2V0dHkgICAgICAgMzE0NCAgICAyIC9kZXYg ICAgICAgICAzNyBjcnctLS0tLS0tICAgdHR5dTAgcncKcm9vdCAgICAgZ2V0dHkgICAgICAg MzE0MyByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAg ICAgZ2V0dHkgICAgICAgMzE0MyAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAg ICA1MTIgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAgMzE0MyB0ZXh0IC91c3IgICAgIDEwMTk4 MDQyIC1yLXhyLXhyLXggICAyNzc4NCAgcgpyb290ICAgICBnZXR0eSAgICAgICAzMTQzICAg IDAgL2RldiAgICAgICAgIDU2IGNydy0tLS0tLS0gICB0dHl2NyBydwpyb290ICAgICBnZXR0 eSAgICAgICAzMTQzICAgIDEgL2RldiAgICAgICAgIDU2IGNydy0tLS0tLS0gICB0dHl2NyBy dwpyb290ICAgICBnZXR0eSAgICAgICAzMTQzICAgIDIgL2RldiAgICAgICAgIDU2IGNydy0t LS0tLS0gICB0dHl2NyBydwpyb290ICAgICBnZXR0eSAgICAgICAzMTQyIHJvb3QgLyAgICAg ICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcgpyb290ICAgICBnZXR0eSAgICAgICAz MTQyICAgd2QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcgpyb290ICAg ICBnZXR0eSAgICAgICAzMTQyIHRleHQgL3VzciAgICAgMTAxOTgwNDIgLXIteHIteHIteCAg IDI3Nzg0ICByCnJvb3QgICAgIGdldHR5ICAgICAgIDMxNDIgICAgMCAvZGV2ICAgICAgICAg NTUgY3J3LS0tLS0tLSAgIHR0eXY2IHJ3CnJvb3QgICAgIGdldHR5ICAgICAgIDMxNDIgICAg MSAvZGV2ICAgICAgICAgNTUgY3J3LS0tLS0tLSAgIHR0eXY2IHJ3CnJvb3QgICAgIGdldHR5 ICAgICAgIDMxNDIgICAgMiAvZGV2ICAgICAgICAgNTUgY3J3LS0tLS0tLSAgIHR0eXY2IHJ3 CnJvb3QgICAgIGdldHR5ICAgICAgIDMxNDEgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIt eHIteCAgICAgNTEyICByCnJvb3QgICAgIGdldHR5ICAgICAgIDMxNDEgICB3ZCAvICAgICAg ICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIGdldHR5ICAgICAgIDMx NDEgdGV4dCAvdXNyICAgICAxMDE5ODA0MiAtci14ci14ci14ICAgMjc3ODQgIHIKcm9vdCAg ICAgZ2V0dHkgICAgICAgMzE0MSAgICAwIC9kZXYgICAgICAgICA1NCBjcnctLS0tLS0tICAg dHR5djUgcncKcm9vdCAgICAgZ2V0dHkgICAgICAgMzE0MSAgICAxIC9kZXYgICAgICAgICA1 NCBjcnctLS0tLS0tICAgdHR5djUgcncKcm9vdCAgICAgZ2V0dHkgICAgICAgMzE0MSAgICAy IC9kZXYgICAgICAgICA1NCBjcnctLS0tLS0tICAgdHR5djUgcncKcm9vdCAgICAgZ2V0dHkg ICAgICAgMzE0MCByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIK cm9vdCAgICAgZ2V0dHkgICAgICAgMzE0MCAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14 ci14ICAgICA1MTIgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAgMzE0MCB0ZXh0IC91c3IgICAg IDEwMTk4MDQyIC1yLXhyLXhyLXggICAyNzc4NCAgcgpyb290ICAgICBnZXR0eSAgICAgICAz MTQwICAgIDAgL2RldiAgICAgICAgIDUzIGNydy0tLS0tLS0gICB0dHl2NCBydwpyb290ICAg ICBnZXR0eSAgICAgICAzMTQwICAgIDEgL2RldiAgICAgICAgIDUzIGNydy0tLS0tLS0gICB0 dHl2NCBydwpyb290ICAgICBnZXR0eSAgICAgICAzMTQwICAgIDIgL2RldiAgICAgICAgIDUz IGNydy0tLS0tLS0gICB0dHl2NCBydwpyb290ICAgICBnZXR0eSAgICAgICAzMTM5IHJvb3Qg LyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcgpyb290ICAgICBnZXR0eSAg ICAgICAzMTM5ICAgd2QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcgpy b290ICAgICBnZXR0eSAgICAgICAzMTM5IHRleHQgL3VzciAgICAgMTAxOTgwNDIgLXIteHIt eHIteCAgIDI3Nzg0ICByCnJvb3QgICAgIGdldHR5ICAgICAgIDMxMzkgICAgMCAvZGV2ICAg ICAgICAgNTIgY3J3LS0tLS0tLSAgIHR0eXYzIHJ3CnJvb3QgICAgIGdldHR5ICAgICAgIDMx MzkgICAgMSAvZGV2ICAgICAgICAgNTIgY3J3LS0tLS0tLSAgIHR0eXYzIHJ3CnJvb3QgICAg IGdldHR5ICAgICAgIDMxMzkgICAgMiAvZGV2ICAgICAgICAgNTIgY3J3LS0tLS0tLSAgIHR0 eXYzIHJ3CnJvb3QgICAgIGdldHR5ICAgICAgIDMxMzggcm9vdCAvICAgICAgICAgICAgIDIg ZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIGdldHR5ICAgICAgIDMxMzggICB3ZCAv ICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIGdldHR5ICAg ICAgIDMxMzggdGV4dCAvdXNyICAgICAxMDE5ODA0MiAtci14ci14ci14ICAgMjc3ODQgIHIK cm9vdCAgICAgZ2V0dHkgICAgICAgMzEzOCAgICAwIC9kZXYgICAgICAgICA1MSBjcnctLS0t LS0tICAgdHR5djIgcncKcm9vdCAgICAgZ2V0dHkgICAgICAgMzEzOCAgICAxIC9kZXYgICAg ICAgICA1MSBjcnctLS0tLS0tICAgdHR5djIgcncKcm9vdCAgICAgZ2V0dHkgICAgICAgMzEz OCAgICAyIC9kZXYgICAgICAgICA1MSBjcnctLS0tLS0tICAgdHR5djIgcncKcm9vdCAgICAg Z2V0dHkgICAgICAgMzEzNyByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1 MTIgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAgMzEzNyAgIHdkIC8gICAgICAgICAgICAgMiBk cnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAgMzEzNyB0ZXh0IC91 c3IgICAgIDEwMTk4MDQyIC1yLXhyLXhyLXggICAyNzc4NCAgcgpyb290ICAgICBnZXR0eSAg ICAgICAzMTM3ICAgIDAgL2RldiAgICAgICAgIDUwIGNydy0tLS0tLS0gICB0dHl2MSBydwpy b290ICAgICBnZXR0eSAgICAgICAzMTM3ICAgIDEgL2RldiAgICAgICAgIDUwIGNydy0tLS0t LS0gICB0dHl2MSBydwpyb290ICAgICBnZXR0eSAgICAgICAzMTM3ICAgIDIgL2RldiAgICAg ICAgIDUwIGNydy0tLS0tLS0gICB0dHl2MSBydwpyb290ICAgICBnZXR0eSAgICAgICAzMTM2 IHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcgpyb290ICAgICBn ZXR0eSAgICAgICAzMTM2ICAgd2QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUx MiAgcgpyb290ICAgICBnZXR0eSAgICAgICAzMTM2IHRleHQgL3VzciAgICAgMTAxOTgwNDIg LXIteHIteHIteCAgIDI3Nzg0ICByCnJvb3QgICAgIGdldHR5ICAgICAgIDMxMzYgICAgMCAv ZGV2ICAgICAgICAgNDkgY3J3LS0tLS0tLSAgIHR0eXYwIHJ3CnJvb3QgICAgIGdldHR5ICAg ICAgIDMxMzYgICAgMSAvZGV2ICAgICAgICAgNDkgY3J3LS0tLS0tLSAgIHR0eXYwIHJ3CnJv b3QgICAgIGdldHR5ICAgICAgIDMxMzYgICAgMiAvZGV2ICAgICAgICAgNDkgY3J3LS0tLS0t LSAgIHR0eXYwIHJ3CnJvb3QgICAgIGluZXRkICAgICAgIDMxMDIgcm9vdCAvICAgICAgICAg ICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIGluZXRkICAgICAgIDMxMDIg ICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIGlu ZXRkICAgICAgIDMxMDIgdGV4dCAvdXNyICAgICA0NjYzNDQ0IC1yLXhyLXhyLXggICA0Nzky MCAgcgpyb290ICAgICBpbmV0ZCAgICAgICAzMTAyICAgIDAgL2RldiAgICAgICAgIDI1IGNy dy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBpbmV0ZCAgICAgICAzMTAyICAgIDEgL2Rl diAgICAgICAgIDI1IGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBpbmV0ZCAgICAg ICAzMTAyICAgIDIgL2RldiAgICAgICAgIDI1IGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290 ICAgICBpbmV0ZCAgICAgICAzMTAyICAgIDMgL3ZhciAgICAgMzI5NzU5IC1ydy0tLS0tLS0g ICAgICAgNCAgdwpyb290ICAgICBpbmV0ZCAgICAgICAzMTAyICAgIDQqIHBpcGUgZmZmZmZm MDAwNTlhZjg4OCA8LT4gZmZmZmZmMDAwNTlhZjllMCAgICAgIDAgcncKcm9vdCAgICAgaW5l dGQgICAgICAgMzEwMiAgICA1KiBpbnRlcm5ldCBkZ3JhbSB1ZHAgZmZmZmZmMDA0ODUxMzJh MApyb290ICAgICBpbmV0ZCAgICAgICAzMTAyICAgIDYqIHBpcGUgZmZmZmZmMDAwNTlhZjll MCA8LT4gZmZmZmZmMDAwNTlhZjg4OCAgICAgIDAgcncKcm9vdCAgICAgY3JvbiAgICAgICAg MzA1NCByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAg ICAgY3JvbiAgICAgICAgMzA1NCAgIHdkIC92YXIgICAgIDEyNzE4MDggZHJ3eHIteC0tLSAg ICAgNTEyICByCnJvb3QgICAgIGNyb24gICAgICAgIDMwNTQgdGV4dCAvdXNyICAgICA0NjYz Mzg0IC1yLXhyLXhyLXggICAzOTY1NiAgcgpyb290ICAgICBjcm9uICAgICAgICAzMDU0ICAg IDAgL2RldiAgICAgICAgIDI1IGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBjcm9u ICAgICAgICAzMDU0ICAgIDEgL2RldiAgICAgICAgIDI1IGNydy1ydy1ydy0gICAgbnVsbCBy dwpyb290ICAgICBjcm9uICAgICAgICAzMDU0ICAgIDIgL2RldiAgICAgICAgIDI1IGNydy1y dy1ydy0gICAgbnVsbCBydwpyb290ICAgICBjcm9uICAgICAgICAzMDU0ICAgIDMgL3ZhciAg ICAgMzI5NzU4IC1ydy0tLS0tLS0gICAgICAgNCAgdwpyb290ICAgICBzc2hkICAgICAgICAz MDI2IHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcgpyb290ICAg ICBzc2hkICAgICAgICAzMDI2ICAgd2QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAg IDUxMiAgcgpyb290ICAgICBzc2hkICAgICAgICAzMDI2IHRleHQgL3VzciAgICAgNDY2MzM2 NyAtcnd4ci14ci14ICA0MTMxOTIgIHIKcm9vdCAgICAgc3NoZCAgICAgICAgMzAyNiAgICAw IC9kZXYgICAgICAgICAyNSBjcnctcnctcnctICAgIG51bGwgcncKcm9vdCAgICAgc3NoZCAg ICAgICAgMzAyNiAgICAxIC9kZXYgICAgICAgICAyNSBjcnctcnctcnctICAgIG51bGwgcncK cm9vdCAgICAgc3NoZCAgICAgICAgMzAyNiAgICAyIC9kZXYgICAgICAgICAyNSBjcnctcnct cnctICAgIG51bGwgcncKcm9vdCAgICAgc3NoZCAgICAgICAgMzAyNiAgICAzKiBpbnRlcm5l dDYgc3RyZWFtIHRjcCBmZmZmZmYwMDQ4NGNjMzcwCnJvb3QgICAgIHNzaGQgICAgICAgIDMw MjYgICAgNCogaW50ZXJuZXQgc3RyZWFtIHRjcCBmZmZmZmYwMDQ4NGNjMDAwCnJvb3QgICAg IG50cGQgICAgICAgIDI5NDYgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAg NTEyICByCnJvb3QgICAgIG50cGQgICAgICAgIDI5NDYgICB3ZCAvICAgICAgICAgICAgIDIg ZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIG50cGQgICAgICAgIDI5NDYgdGV4dCAv dXNyICAgICA0NjYzNDg1IC1yLXhyLXhyLXggIDM0MTQ2NCAgcgpyb290ICAgICBudHBkICAg ICAgICAyOTQ2ICAgIDAgL2RldiAgICAgICAgIDI1IGNydy1ydy1ydy0gICAgbnVsbCBydwpy b290ICAgICBudHBkICAgICAgICAyOTQ2ICAgIDEgL2RldiAgICAgICAgIDI1IGNydy1ydy1y dy0gICAgbnVsbCBydwpyb290ICAgICBudHBkICAgICAgICAyOTQ2ICAgIDIgL2RldiAgICAg ICAgIDI1IGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBudHBkICAgICAgICAyOTQ2 ICAgIDMqIGxvY2FsIGRncmFtIGZmZmZmZjAwMDU5Yzg5NjAgPC0+IGZmZmZmZjAwMDU5ZWZh NTAKcm9vdCAgICAgbnRwZCAgICAgICAgMjk0NiAgIDIwKiBpbnRlcm5ldCBkZ3JhbSB1ZHAg ZmZmZmZmMDA0ODRmM2JkMApyb290ICAgICBudHBkICAgICAgICAyOTQ2ICAgMjEqIGludGVy bmV0NiBkZ3JhbSB1ZHAgZmZmZmZmMDA0ODE3ZDkzMApyb290ICAgICBudHBkICAgICAgICAy OTQ2ICAgMjIqIGludGVybmV0NiBkZ3JhbSB1ZHAgZmZmZmZmMDA0ODRmMjAwMApyb290ICAg ICBudHBkICAgICAgICAyOTQ2ICAgMjMqIGludGVybmV0NiBkZ3JhbSB1ZHAgZmZmZmZmMDA0 ODUwMWJkMApyb290ICAgICBudHBkICAgICAgICAyOTQ2ICAgMjQqIGludGVybmV0IGRncmFt IHVkcCBmZmZmZmYwMDQ4MTdkMmEwCnJvb3QgICAgIG50cGQgICAgICAgIDI5NDYgICAyNSog aW50ZXJuZXQgZGdyYW0gdWRwIGZmZmZmZjAwMDVmZGE3ZTAKcm9vdCAgICAgbnRwZCAgICAg ICAgMjk0NiAgIDI2KiBpbnRlcm5ldCBkZ3JhbSB1ZHAgZmZmZmZmMDAwNTllYzU0MApyb290 ICAgICBudHBkICAgICAgICAyOTQ2ICAgMjcqIGludGVybmV0IGRncmFtIHVkcCBmZmZmZmYw MDA1OWYyMTUwCnJvb3QgICAgIG50cGQgICAgICAgIDI5NDYgICAyOCogaW50ZXJuZXQgZGdy YW0gdWRwIGZmZmZmZjAwNDg0ZWE3ZTAKcm9vdCAgICAgbnRwZCAgICAgICAgMjk0NiAgIDI5 KiBpbnRlcm5ldCBkZ3JhbSB1ZHAgZmZmZmZmMDA0ODUwZGJkMApyb290ICAgICBudHBkICAg ICAgICAyOTQ2ICAgMzAqIGludGVybmV0IGRncmFtIHVkcCBmZmZmZmYwMDQ4MTdkNTQwCnJv b3QgICAgIG50cGQgICAgICAgIDI5NDYgICAzMSogaW50ZXJuZXQgZGdyYW0gdWRwIGZmZmZm ZjAwNDg1MDEwMDAKcm9vdCAgICAgbnRwZCAgICAgICAgMjk0NiAgIDMyKiBpbnRlcm5ldCBk Z3JhbSB1ZHAgZmZmZmZmMDA0ODRmMzkzMApyb290ICAgICBudHBkICAgICAgICAyOTQ2ICAg MzMqIGludGVybmV0IGRncmFtIHVkcCBmZmZmZmYwMDA1OWViZDIwCnJvb3QgICAgIG50cGQg ICAgICAgIDI5NDYgICAzNCogaW50ZXJuZXQgZGdyYW0gdWRwIGZmZmZmZjAwMDU5ZjI3ZTAK cm9vdCAgICAgbnRwZCAgICAgICAgMjk0NiAgIDM1KiBpbnRlcm5ldCBkZ3JhbSB1ZHAgZmZm ZmZmMDA0ODRlYTAwMApyb290ICAgICBudHBkICAgICAgICAyOTQ2ICAgMzYqIGludGVybmV0 IGRncmFtIHVkcCBmZmZmZmYwMDQ4NTBlNTQwCnJvb3QgICAgIG50cGQgICAgICAgIDI5NDYg ICAzNyogaW50ZXJuZXQgZGdyYW0gdWRwIGZmZmZmZjAwMDU5ZWMxNTAKcm9vdCAgICAgbnRw ZCAgICAgICAgMjk0NiAgIDM4KiBpbnRlcm5ldCBkZ3JhbSB1ZHAgZmZmZmZmMDA0ODUwMGJk MApyb290ICAgICBudHBkICAgICAgICAyOTQ2ICAgMzkqIGludGVybmV0IGRncmFtIHVkcCBm ZmZmZmYwMDQ4NGVhZDIwCnJvb3QgICAgIG50cGQgICAgICAgIDI5NDYgICA0MCogaW50ZXJu ZXQgZGdyYW0gdWRwIGZmZmZmZjAwNDg0ZTk3ZTAKcm9vdCAgICAgbnRwZCAgICAgICAgMjk0 NiAgIDQxKiBpbnRlcm5ldCBkZ3JhbSB1ZHAgZmZmZmZmMDA0ODE3ZTJhMApyb290ICAgICBu dHBkICAgICAgICAyOTQ2ICAgNDIqIGludGVybmV0IGRncmFtIHVkcCBmZmZmZmYwMDQ4NTAx ZDIwCnJvb3QgICAgIG50cGQgICAgICAgIDI5NDYgICA0MyogaW50ZXJuZXQgZGdyYW0gdWRw IGZmZmZmZjAwMDU5ZWIyYTAKcm9vdCAgICAgbnRwZCAgICAgICAgMjk0NiAgIDQ0KiBpbnRl cm5ldCBkZ3JhbSB1ZHAgZmZmZmZmMDA0ODUwMDE1MApyb290ICAgICBudHBkICAgICAgICAy OTQ2ICAgNDUqIGludGVybmV0IGRncmFtIHVkcCBmZmZmZmYwMDA1OWI1NTQwCnJvb3QgICAg IG50cGQgICAgICAgIDI5NDYgICA0NiogaW50ZXJuZXQgZGdyYW0gdWRwIGZmZmZmZjAwNDg0 ZjMxNTAKcm9vdCAgICAgbnRwZCAgICAgICAgMjk0NiAgIDQ3KiBpbnRlcm5ldCBkZ3JhbSB1 ZHAgZmZmZmZmMDA0ODE3ZTdlMApyb290ICAgICBudHBkICAgICAgICAyOTQ2ICAgNDgqIGlu dGVybmV0IGRncmFtIHVkcCBmZmZmZmYwMDQ4NGU5MTUwCnJvb3QgICAgIG50cGQgICAgICAg IDI5NDYgICA0OSogaW50ZXJuZXQgZGdyYW0gdWRwIGZmZmZmZjAwNDg0ZTkwMDAKcm9vdCAg ICAgbnRwZCAgICAgICAgMjk0NiAgIDUwKiBpbnRlcm5ldCBkZ3JhbSB1ZHAgZmZmZmZmMDAw NTllYjU0MApyb290ICAgICBudHBkICAgICAgICAyOTQ2ICAgNTEqIGludGVybmV0IGRncmFt IHVkcCBmZmZmZmYwMDQ4NGU5NTQwCnJvb3QgICAgIG50cGQgICAgICAgIDI5NDYgICA1Miog aW50ZXJuZXQgZGdyYW0gdWRwIGZmZmZmZjAwNDg0ZjIxNTAKcm9vdCAgICAgbnRwZCAgICAg ICAgMjk0NiAgIDUzKiBpbnRlcm5ldCBkZ3JhbSB1ZHAgZmZmZmZmMDA0ODUwMjAwMApyb290 ICAgICBudHBkICAgICAgICAyOTQ2ICAgNTQqIGludGVybmV0IGRncmFtIHVkcCBmZmZmZmYw MDQ4NTAyMTUwCnJvb3QgICAgIG50cGQgICAgICAgIDI5NDYgICA1NSogaW50ZXJuZXQgZGdy YW0gdWRwIGZmZmZmZjAwNDg1MDA3ZTAKcm9vdCAgICAgbnRwZCAgICAgICAgMjk0NiAgIDU2 KiBpbnRlcm5ldCBkZ3JhbSB1ZHAgZmZmZmZmMDA0ODUxMzU0MApyb290ICAgICBudHBkICAg ICAgICAyOTQ2ICAgNTcqIGludGVybmV0IGRncmFtIHVkcCBmZmZmZmYwMDQ4MTdlYmQwCnJv b3QgICAgIG50cGQgICAgICAgIDI5NDYgICA1OCogaW50ZXJuZXQgZGdyYW0gdWRwIGZmZmZm ZjAwNDgxN2UxNTAKcm9vdCAgICAgbnRwZCAgICAgICAgMjk0NiAgIDU5KiBpbnRlcm5ldCBk Z3JhbSB1ZHAgZmZmZmZmMDA0ODUwMjdlMApyb290ICAgICBudHBkICAgICAgICAyOTQ2ICAg NjAqIGludGVybmV0IGRncmFtIHVkcCBmZmZmZmYwMDQ4MmY5YTgwCnJvb3QgICAgIG50cGQg ICAgICAgIDI5NDYgICA2MSogaW50ZXJuZXQgZGdyYW0gdWRwIGZmZmZmZjAwNDgxN2QwMDAK cm9vdCAgICAgbnRwZCAgICAgICAgMjk0NiAgIDYyKiBpbnRlcm5ldCBkZ3JhbSB1ZHAgZmZm ZmZmMDA0ODJmOTY5MApyb290ICAgICBudHBkICAgICAgICAyOTQ2ICAgNjMqIGludGVybmV0 IGRncmFtIHVkcCBmZmZmZmYwMDQ4NGVhNTQwCnJvb3QgICAgIG50cGQgICAgICAgIDI5NDYg ICA2NCogaW50ZXJuZXQgZGdyYW0gdWRwIGZmZmZmZjAwNDg0ZWFiZDAKcm9vdCAgICAgbnRw ZCAgICAgICAgMjk0NiAgIDY1KiBpbnRlcm5ldCBkZ3JhbSB1ZHAgZmZmZmZmMDA0ODUwMTE1 MApyb290ICAgICBudHBkICAgICAgICAyOTQ2ICAgNjYqIGludGVybmV0IGRncmFtIHVkcCBm ZmZmZmYwMDQ4NGU5NjkwCnJvb3QgICAgIG50cGQgICAgICAgIDI5NDYgICA2NyogaW50ZXJu ZXQgZGdyYW0gdWRwIGZmZmZmZjAwNDg1MTMzZjAKcm9vdCAgICAgbnRwZCAgICAgICAgMjk0 NiAgIDY4KiBpbnRlcm5ldCBkZ3JhbSB1ZHAgZmZmZmZmMDAwNTliNTE1MApyb290ICAgICBu dHBkICAgICAgICAyOTQ2ICAgNjkqIGludGVybmV0IGRncmFtIHVkcCBmZmZmZmYwMDA1OWVi N2UwCnJvb3QgICAgIG50cGQgICAgICAgIDI5NDYgICA3MCogaW50ZXJuZXQgZGdyYW0gdWRw IGZmZmZmZjAwNDg0ZjM1NDAKcm9vdCAgICAgbnRwZCAgICAgICAgMjk0NiAgIDcxKiByb3V0 ZSByYXcgMCBmZmZmZmYwMDQ4NTA5NTUwCnJvb3QgICAgIG50cGQgICAgICAgIDI5NDYgICA3 MiogaW50ZXJuZXQgZGdyYW0gdWRwIGZmZmZmZjAwODhhZGUwMDAKYmluZCAgICAgbmFtZWQg ICAgICAgMjUxMSByb290IC91c3IgICAgIDEwMTc0NDY0IGRyd3hyLXhyLXggICAgIDUxMiAg cgpiaW5kICAgICBuYW1lZCAgICAgICAyNTExICAgd2QgL3VzciAgICAgMTAyNzAzMjYgZHJ3 eHIteHIteCAgICAgNTEyICByCmJpbmQgICAgIG5hbWVkICAgICAgIDI1MTEgamFpbCAvdXNy ICAgICAxMDE3NDQ2NCBkcnd4ci14ci14ICAgICA1MTIgIHIKYmluZCAgICAgbmFtZWQgICAg ICAgMjUxMSB0ZXh0IC91c3IgICAgIDEwMDU4NDk0IC1yLXhyLXhyLXggIDIwMzI2NDAgIHIK YmluZCAgICAgbmFtZWQgICAgICAgMjUxMSAgICAwIC9kZXYgICAgICAgICAyNSBjcnctcnct cnctICAgIG51bGwgcncKYmluZCAgICAgbmFtZWQgICAgICAgMjUxMSAgICAxIC9kZXYgICAg ICAgICAyNSBjcnctcnctcnctICAgIG51bGwgcncKYmluZCAgICAgbmFtZWQgICAgICAgMjUx MSAgICAyIC9kZXYgICAgICAgICAyNSBjcnctcnctcnctICAgIG51bGwgcncKYmluZCAgICAg bmFtZWQgICAgICAgMjUxMSAgICAzKiBsb2NhbCBkZ3JhbSBmZmZmZmYwMDQ4MjM4M2MwIDwt PiBmZmZmZmYwMDA1OWVmYTUwCmJpbmQgICAgIG5hbWVkICAgICAgIDI1MTEgICAgNCAvZGV2 ICAgICAgICAgMjUgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CmJpbmQgICAgIG5hbWVkICAgICAg IDI1MTEgICAgNSAvdXNyICAgICAxMDI2ODY3NCAtcnctci0tci0tICAxODMwMjkxMyAgdwpi aW5kICAgICBuYW1lZCAgICAgICAyNTExICAgIDYqIHBpcGUgZmZmZmZmMDA0ODBkZGI2MCA8 LT4gZmZmZmZmMDA0ODBkZGNiOCAgICAgIDAgcncKYmluZCAgICAgbmFtZWQgICAgICAgMjUx MSAgICA3IC91c3IgICAgIDEwMjY4Njc5IC1ydy1yLS1yLS0gIDU0MDMzMjkgIHcKYmluZCAg ICAgbmFtZWQgICAgICAgMjUxMSAgICA4KiBwaXBlIGZmZmZmZjAwNDgwZGRjYjggPC0+IGZm ZmZmZjAwNDgwZGRiNjAgICAgICAwIHJ3CmJpbmQgICAgIG5hbWVkICAgICAgIDI1MTEgICAx MCAvdXNyL2xvY2FsL2V0Yy9uYW1lZGIvZGV2ICAgICAzMSBjcnctcnctcnctICByYW5kb20g IHIKYmluZCAgICAgbmFtZWQgICAgICAgMjUxMSAgIDExIC91c3IgICAgIDEwMjcwNDExIC1y dy1yLS1yLS0gIDM5NzYyNCAgdwpiaW5kICAgICBuYW1lZCAgICAgICAyNTExICAgMTIgL3Vz ciAgICAgMTAyNjg2NzYgLXJ3LXItLXItLSAgODg4OTY5MiAgdwpiaW5kICAgICBuYW1lZCAg ICAgICAyNTExICAgMjAqIGludGVybmV0IHN0cmVhbSB0Y3AgZmZmZmZmMDA0ODJkMjM3MApi aW5kICAgICBuYW1lZCAgICAgICAyNTExICAgMjEqIGludGVybmV0IHN0cmVhbSB0Y3AgZmZm ZmZmMDA0ODJkMjAwMApiaW5kICAgICBuYW1lZCAgICAgICAyNTExICAgMjIqIGludGVybmV0 IHN0cmVhbSB0Y3AgZmZmZmZmMDA0ODJkMjZlMApiaW5kICAgICBuYW1lZCAgICAgICAyNTEx ICAgMjMqIGludGVybmV0NiBzdHJlYW0gdGNwIGZmZmZmZjAwNDgyZDJhNTAKYmluZCAgICAg bmFtZWQgICAgICAgMjUxMSAgNTEyKiBpbnRlcm5ldCBkZ3JhbSB1ZHAgZmZmZmZmMDA0ODJm OTkzMApiaW5kICAgICBuYW1lZCAgICAgICAyNTExICA1MTMqIGludGVybmV0IGRncmFtIHVk cCBmZmZmZmYwMDQ4MmY5N2UwCnJvb3QgICAgIHN5c2xvZ2QgICAgIDIyODggcm9vdCAvICAg ICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIHN5c2xvZ2QgICAg IDIyODggICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3Qg ICAgIHN5c2xvZ2QgICAgIDIyODggdGV4dCAvdXNyICAgICA0NjYzNTc0IC1yLXhyLXhyLXgg ICAzOTQ3MiAgcgpyb290ICAgICBzeXNsb2dkICAgICAyMjg4ICAgIDAgL2RldiAgICAgICAg IDI1IGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBzeXNsb2dkICAgICAyMjg4ICAg IDEgL2RldiAgICAgICAgIDI1IGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBzeXNs b2dkICAgICAyMjg4ICAgIDIgL2RldiAgICAgICAgIDI1IGNydy1ydy1ydy0gICAgbnVsbCBy dwpyb290ICAgICBzeXNsb2dkICAgICAyMjg4ICAgIDMgL3ZhciAgICAgMzI5NzQ2IC1ydy0t LS0tLS0gICAgICAgNCAgdwpyb290ICAgICBzeXNsb2dkICAgICAyMjg4ICAgIDQqIGxvY2Fs IGRncmFtIGZmZmZmZjAwMDU5ZWY5NjAKcm9vdCAgICAgc3lzbG9nZCAgICAgMjI4OCAgICA1 KiBsb2NhbCBkZ3JhbSBmZmZmZmYwMDA1OWVmYTUwCnJvb3QgICAgIHN5c2xvZ2QgICAgIDIy ODggICAgNiogbG9jYWwgZGdyYW0gZmZmZmZmMDAwNTllZmI0MApyb290ICAgICBzeXNsb2dk ICAgICAyMjg4ICAgIDcqIGxvY2FsIGRncmFtIGZmZmZmZjAwMDU5ZWZjMzAKcm9vdCAgICAg c3lzbG9nZCAgICAgMjI4OCAgICA4KiBpbnRlcm5ldCBkZ3JhbSB1ZHAgZmZmZmZmMDAwNTll YzkzMApyb290ICAgICBzeXNsb2dkICAgICAyMjg4ICAgIDkgL2RldiAgICAgICAgIDI3IGNy dy0tLS0tLS0gICAga2xvZyAgcgpyb290ICAgICBzeXNsb2dkICAgICAyMjg4ICAgMTEgL2Rl diAgICAgICAgICA1IGNydy0tLS0tLS0gIGNvbnNvbGUgIHcKcm9vdCAgICAgc3lzbG9nZCAg ICAgMjI4OCAgIDEyIC92YXIgICAgIDIzNTUyOSAtcnctci0tci0tICAgNTUwMDAgIHcKcm9v dCAgICAgc3lzbG9nZCAgICAgMjI4OCAgIDEzIC92YXIgICAgIDIzNTUzMSAtcnctLS0tLS0t ICAgICAgNjIgIHcKcm9vdCAgICAgc3lzbG9nZCAgICAgMjI4OCAgIDE0IC92YXIgICAgIDIz NTUyMyAtcnctLS0tLS0tICAgNjE3MjEgIHcKcm9vdCAgICAgc3lzbG9nZCAgICAgMjI4OCAg IDE1IC92YXIgICAgIDIzNTU0OCAtcnctci0tLS0tICAgIDI4NTUgIHcKcm9vdCAgICAgc3lz bG9nZCAgICAgMjI4OCAgIDE2IC92YXIgICAgIDIzNTUyNyAtcnctci0tci0tICAgICAgNjIg IHcKcm9vdCAgICAgc3lzbG9nZCAgICAgMjI4OCAgIDE3IC92YXIgICAgIDIzNTUzMiAtcnct LS0tLS0tICAgIDQ1NzUgIHcKcm9vdCAgICAgc3lzbG9nZCAgICAgMjI4OCAgIDE4IC92YXIg ICAgIDIzNTU3MyAtcnctLS0tLS0tICAgNjgxNjIgIHcKcm9vdCAgICAgc3lzbG9nZCAgICAg MjI4OCAgIDE5IC92YXIgICAgIDIzNTU0NCAtcnctLS0tLS0tICAgICAgNzggIHcKcm9vdCAg ICAgc3lzbG9nZCAgICAgMjI4OCAgIDIwIC92YXIgICAgIDIzNTU5OCAtcnctLS0tLS0tICAg NDkxNDEgIHcKcm9vdCAgICAgc3lzbG9nZCAgICAgMjI4OCAgIDIxIC92YXIgICAgIDIzNTU0 MSAtcnctLS0tLS0tICA3NTgyNjMgIHcKcm9vdCAgICAgc3lzbG9nZCAgICAgMjI4OCAgIDIy IC92YXIgICAgIDIzNTUzMCAtcnctci0tLS0tICAgICAgNjIgIHcKcm9vdCAgICAgZGV2ZCAg ICAgICAgMTQzMCByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIK cm9vdCAgICAgZGV2ZCAgICAgICAgMTQzMCAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14 ci14ICAgICA1MTIgIHIKcm9vdCAgICAgZGV2ZCAgICAgICAgMTQzMCB0ZXh0IC8gICAgICAg ICA5NDI5NiAtci14ci14ci14ICA0MTk0NzIgIHIKcm9vdCAgICAgZGV2ZCAgICAgICAgMTQz MCAgICAwIC9kZXYgICAgICAgICAyNSBjcnctcnctcnctICAgIG51bGwgcncKcm9vdCAgICAg ZGV2ZCAgICAgICAgMTQzMCAgICAxIC9kZXYgICAgICAgICAyNSBjcnctcnctcnctICAgIG51 bGwgcncKcm9vdCAgICAgZGV2ZCAgICAgICAgMTQzMCAgICAyIC9kZXYgICAgICAgICAyNSBj cnctcnctcnctICAgIG51bGwgcncKcm9vdCAgICAgZGV2ZCAgICAgICAgMTQzMCAgICAzIC8g ICAgICAgIDQwMDM5NiBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAgICAgZGV2ZCAgICAg ICAgMTQzMCAgICA0IC9kZXYgICAgICAgICAgNCBjcnctLS0tLS0tICBkZXZjdGwgIHIKcm9v dCAgICAgZGV2ZCAgICAgICAgMTQzMCAgICA1KiBsb2NhbCBzdHJlYW0gZmZmZmZmMDAwNTll ZmUxMApyb290ICAgICBkZXZkICAgICAgICAxNDMwICAgIDYgL3ZhciAgICAgMzI5NzM2IC1y dy0tLS0tLS0gICAgICAgNCAgdwpyb290ICAgICBtb3VzZWQgICAgICAgOTYzIHJvb3QgLyAg ICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcgpyb290ICAgICBtb3VzZWQgICAg ICAgOTYzICAgd2QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcgpyb290 ICAgICBtb3VzZWQgICAgICAgOTYzIHRleHQgL3VzciAgICAgNDY2MzM5NiAtci14ci14ci14 ICAgNDAyNDAgIHIKcm9vdCAgICAgbW91c2VkICAgICAgIDk2MyAgICAwIC9kZXYgICAgICAg ICAyNSBjcnctcnctcnctICAgIG51bGwgcncKcm9vdCAgICAgbW91c2VkICAgICAgIDk2MyAg ICAxIC9kZXYgICAgICAgICAyNSBjcnctcnctcnctICAgIG51bGwgcncKcm9vdCAgICAgbW91 c2VkICAgICAgIDk2MyAgICAyIC9kZXYgICAgICAgICAyNSBjcnctcnctcnctICAgIG51bGwg cncKcm9vdCAgICAgbW91c2VkICAgICAgIDk2MyAgICAzIC9kZXYgICAgICAgIDEwNCBjcnct ci0tci0tICAgIHVtczAgcncKcm9vdCAgICAgbW91c2VkICAgICAgIDk2MyAgICA0IC9kZXYg ICAgICAgICA2NSBjcnctLS0tLS0tICBjb25zb2xlY3RsIHJ3CnJvb3QgICAgIG1vdXNlZCAg ICAgICA5NjMgICAgNSogbG9jYWwgc3RyZWFtIGZmZmZmZjAwMDU5ZWZlMTAKcm9vdCAgICAg bW91c2VkICAgICAgIDk2MyAgICA2IC92YXIgICAgIDMyOTczNSAtcnctLS0tLS0tICAgICAg IDMgIHcKcm9vdCAgICAgaW5pdCAgICAgICAgICAgMSByb290IC8gICAgICAgICAgICAgMiBk cnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAgICAgaW5pdCAgICAgICAgICAgMSAgIHdkIC8g ICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAgICAgaW5pdCAgICAg ICAgICAgMSB0ZXh0IC8gICAgICAgICA5NDMwMiAtci14ci14ci14ICA3NDU4MDggIHIKcm9v dCAgICAga2VybmVsICAgICAgICAgMCByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14 ICAgICA1MTIgIHIKcm9vdCAgICAga2VybmVsICAgICAgICAgMCAgIHdkIC8gICAgICAgICAg ICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpkbWVzZwoK dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAy IDIzOjM0OjAzIGhvc3RuYW1lIHNzaGRbOTg2ODZdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNh dGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNDow MyBob3N0bmFtZSBzc2hkWzk4Njg4XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJy b3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6MzQ6MDQgaG9zdG5h bWUgc3NoZFs5ODY4Nl06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciBy b290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM0OjA0IGhvc3RuYW1lIHNzaGRb OTg2ODhdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9t IDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNDowNCBob3N0bmFtZSBzc2hkWzk4Njg2XTog ZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEu MTExLjE4MApPY3QgIDIgMjM6MzQ6MDQgaG9zdG5hbWUgc3NoZFs5ODY4OF06IGVycm9yOiBQ QU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAK T2N0ICAyIDIzOjM0OjA1IGhvc3RuYW1lIHNzaGRbOTg2ODZdOiBlcnJvcjogUEFNOiBhdXRo ZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAy MzozNDowNSBob3N0bmFtZSBzc2hkWzk4Njg4XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRp b24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6MzQ6MDUg aG9zdG5hbWUgc3NoZFs5ODY4Nl06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9y IGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM0OjA1IGhvc3RuYW1l IHNzaGRbOTg2ODhdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9v dCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNDowNiBob3N0bmFtZSBzc2hkWzk4 Njg4XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAx OTAuODEuMTExLjE4MApPY3QgIDIgMjM6MzQ6MTEgaG9zdG5hbWUgc3NoZFs5ODcyMl06IGVy cm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjEx MS4xODAKT2N0ICAyIDIzOjM0OjEyIGhvc3RuYW1lIHNzaGRbOTg3MjJdOiBlcnJvcjogUEFN OiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9j dCAgMiAyMzozNDoxMiBob3N0bmFtZSBzc2hkWzk4NzI0XTogZXJyb3I6IFBBTTogYXV0aGVu dGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6 MzQ6MTIgaG9zdG5hbWUgc3NoZFs5ODcyMl06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9u IGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM0OjEzIGhv c3RuYW1lIHNzaGRbOTg3MjRdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBm b3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNDoxMyBob3N0bmFtZSBz c2hkWzk4NzIyXTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3Qg ZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6MzQ6MTQgaG9zdG5hbWUgc3NoZFs5ODcy NF06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkw LjgxLjExMS4xODAKT2N0ICAyIDIzOjM0OjE0IGhvc3RuYW1lIHNzaGRbOTg3MjJdOiBlcnJv cjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEu MTgwCk9jdCAgMiAyMzozNDoxNCBob3N0bmFtZSBzc2hkWzk4NzI0XTogZXJyb3I6IFBBTTog YXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3Qg IDIgMjM6MzQ6MTUgaG9zdG5hbWUgc3NoZFs5ODcyMl06IGVycm9yOiBQQU06IGF1dGhlbnRp Y2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM0 OjE1IGhvc3RuYW1lIHNzaGRbOTg3MjRdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBl cnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNDoxNSBob3N0 bmFtZSBzc2hkWzk4NzI0XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9y IHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6MzQ6MTggaG9zdG5hbWUgc3No ZFs5ODczOF06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZy b20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM0OjE4IGhvc3RuYW1lIHNzaGRbOTg3Mzhd OiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44 MS4xMTEuMTgwCk9jdCAgMiAyMzozNDoxOSBob3N0bmFtZSBzc2hkWzk4NzM4XTogZXJyb3I6 IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4 MApPY3QgIDIgMjM6MzQ6MTkgaG9zdG5hbWUgc3NoZFs5ODc0MF06IGVycm9yOiBQQU06IGF1 dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAy IDIzOjM0OjE5IGhvc3RuYW1lIHNzaGRbOTg3MzhdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNh dGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNDoy MCBob3N0bmFtZSBzc2hkWzk4NzQwXTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJy b3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6MzQ6MjAgaG9zdG5h bWUgc3NoZFs5ODczOF06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciBy b290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM0OjIwIGhvc3RuYW1lIHNzaGRb OTg3NDBdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9t IDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNDoyMSBob3N0bmFtZSBzc2hkWzk4NzM4XTog ZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEu MTExLjE4MApPY3QgIDIgMjM6MzQ6MjEgaG9zdG5hbWUgc3NoZFs5ODc0MF06IGVycm9yOiBQ QU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAK T2N0ICAyIDIzOjM0OjIyIGhvc3RuYW1lIHNzaGRbOTg3NDBdOiBlcnJvcjogUEFNOiBhdXRo ZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAy MzozNDoyMiBob3N0bmFtZSBzc2hkWzk4NzQwXTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRp b24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6MzQ6MjQg aG9zdG5hbWUgc3NoZFs5ODc1Ml06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9y IGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM0OjI0IGhvc3RuYW1l IHNzaGRbOTg3NTJdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9v dCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNDoyNSBob3N0bmFtZSBzc2hkWzk4 NzUyXTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAx OTAuODEuMTExLjE4MApPY3QgIDIgMjM6MzQ6MjUgaG9zdG5hbWUgc3NoZFs5ODc1Nl06IGVy cm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjEx MS4xODAKT2N0ICAyIDIzOjM0OjI1IGhvc3RuYW1lIHNzaGRbOTg3NTJdOiBlcnJvcjogUEFN OiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9j dCAgMiAyMzozNDoyNiBob3N0bmFtZSBzc2hkWzk4NzU2XTogZXJyb3I6IFBBTTogYXV0aGVu dGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6 MzQ6MjYgaG9zdG5hbWUgc3NoZFs5ODc1Ml06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9u IGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM0OjI2IGhv c3RuYW1lIHNzaGRbOTg3NTZdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBm b3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNDoyNiBob3N0bmFtZSBz c2hkWzk4NzUyXTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3Qg ZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6MzQ6MjcgaG9zdG5hbWUgc3NoZFs5ODc1 Nl06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkw LjgxLjExMS4xODAKT2N0ICAyIDIzOjM0OjI3IGhvc3RuYW1lIHNzaGRbOTg3NTZdOiBlcnJv cjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEu MTgwCk9jdCAgMiAyMzozNDoyOCBob3N0bmFtZSBzc2hkWzk4NzU2XTogZXJyb3I6IFBBTTog YXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3Qg IDIgMjM6MzQ6MzAgaG9zdG5hbWUgc3NoZFs5ODc2OF06IGVycm9yOiBQQU06IGF1dGhlbnRp Y2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM0 OjMxIGhvc3RuYW1lIHNzaGRbOTg3NjhdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBl cnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNDozMSBob3N0 bmFtZSBzc2hkWzk4NzcyXTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9y IHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6MzQ6MzEgaG9zdG5hbWUgc3No ZFs5ODc2OF06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZy b20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM0OjMyIGhvc3RuYW1lIHNzaGRbOTg3NzJd OiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44 MS4xMTEuMTgwCk9jdCAgMiAyMzozNDozMiBob3N0bmFtZSBzc2hkWzk4NzY4XTogZXJyb3I6 IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4 MApPY3QgIDIgMjM6MzQ6MzIgaG9zdG5hbWUgc3NoZFs5ODc3Ml06IGVycm9yOiBQQU06IGF1 dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAy IDIzOjM0OjMyIGhvc3RuYW1lIHNzaGRbOTg3NjhdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNh dGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNDoz MyBob3N0bmFtZSBzc2hkWzk4NzY4XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJy b3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6MzQ6MzMgaG9zdG5h bWUgc3NoZFs5ODc3Ml06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciBy b290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM0OjM0IGhvc3RuYW1lIHNzaGRb OTg3NzJdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9t IDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNDozNCBob3N0bmFtZSBzc2hkWzk4NzcyXTog ZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEu MTExLjE4MApPY3QgIDIgMjM6MzQ6MzYgaG9zdG5hbWUgc3NoZFs5ODc4NV06IGVycm9yOiBQ QU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAK T2N0ICAyIDIzOjM0OjM3IGhvc3RuYW1lIHNzaGRbOTg3ODVdOiBlcnJvcjogUEFNOiBhdXRo ZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAy MzozNDozNyBob3N0bmFtZSBzc2hkWzk4Nzg4XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRp b24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6MzQ6Mzgg aG9zdG5hbWUgc3NoZFs5ODc4NV06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9y IGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM0OjM4IGhvc3RuYW1l IHNzaGRbOTg3ODhdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9v dCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNDozOCBob3N0bmFtZSBzc2hkWzk4 Nzg1XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAx OTAuODEuMTExLjE4MApPY3QgIDIgMjM6MzQ6MzkgaG9zdG5hbWUgc3NoZFs5ODc4OF06IGVy cm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjEx MS4xODAKT2N0ICAyIDIzOjM0OjM5IGhvc3RuYW1lIHNzaGRbOTg3ODVdOiBlcnJvcjogUEFN OiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9j dCAgMiAyMzozNDozOSBob3N0bmFtZSBzc2hkWzk4Nzg4XTogZXJyb3I6IFBBTTogYXV0aGVu dGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6 MzQ6MzkgaG9zdG5hbWUgc3NoZFs5ODc4NV06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9u IGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM0OjQwIGhv c3RuYW1lIHNzaGRbOTg3ODhdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBm b3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNDo0MCBob3N0bmFtZSBz c2hkWzk4Nzg4XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3Qg ZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6MzQ6NDIgaG9zdG5hbWUgc3NoZFs5ODgw Ml06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkw LjgxLjExMS4xODAKT2N0ICAyIDIzOjM0OjQzIGhvc3RuYW1lIHNzaGRbOTg4MDJdOiBlcnJv cjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEu MTgwCk9jdCAgMiAyMzozNDo0MyBob3N0bmFtZSBzc2hkWzk4ODA0XTogZXJyb3I6IFBBTTog YXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3Qg IDIgMjM6MzQ6NDQgaG9zdG5hbWUgc3NoZFs5ODgwMl06IGVycm9yOiBQQU06IGF1dGhlbnRp Y2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM0 OjQ0IGhvc3RuYW1lIHNzaGRbOTg4MDJdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBl cnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNDo0NCBob3N0 bmFtZSBzc2hkWzk4ODA0XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9y IHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6MzQ6NDUgaG9zdG5hbWUgc3No ZFs5ODgwMl06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZy b20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM0OjQ1IGhvc3RuYW1lIHNzaGRbOTg4MDRd OiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44 MS4xMTEuMTgwCk9jdCAgMiAyMzozNDo0NSBob3N0bmFtZSBzc2hkWzk4ODAyXTogZXJyb3I6 IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4 MApPY3QgIDIgMjM6MzQ6NDYgaG9zdG5hbWUgc3NoZFs5ODgwNF06IGVycm9yOiBQQU06IGF1 dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAy IDIzOjM0OjQ2IGhvc3RuYW1lIHNzaGRbOTg4MDRdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNh dGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNDo0 NyBob3N0bmFtZSBzc2hkWzk4ODA0XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJy b3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6MzQ6NDkgaG9zdG5h bWUgc3NoZFs5ODgxN106IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciBy b290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM0OjUwIGhvc3RuYW1lIHNzaGRb OTg4MTddOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9t IDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNDo1MCBob3N0bmFtZSBzc2hkWzk4ODE3XTog ZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEu MTExLjE4MApPY3QgIDIgMjM6MzQ6NTAgaG9zdG5hbWUgc3NoZFs5ODgyMF06IGVycm9yOiBQ QU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAK T2N0ICAyIDIzOjM0OjUxIGhvc3RuYW1lIHNzaGRbOTg4MTddOiBlcnJvcjogUEFNOiBhdXRo ZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAy MzozNDo1MSBob3N0bmFtZSBzc2hkWzk4ODIwXTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRp b24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6MzQ6NTEg aG9zdG5hbWUgc3NoZFs5ODgxN106IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9y IGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM0OjUyIGhvc3RuYW1l IHNzaGRbOTg4MjBdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9v dCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNDo1MiBob3N0bmFtZSBzc2hkWzk4 ODE3XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAx OTAuODEuMTExLjE4MApPY3QgIDIgMjM6MzQ6NTIgaG9zdG5hbWUgc3NoZFs5ODgyMF06IGVy cm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjEx MS4xODAKT2N0ICAyIDIzOjM0OjUzIGhvc3RuYW1lIHNzaGRbOTg4MjBdOiBlcnJvcjogUEFN OiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9j dCAgMiAyMzozNDo1MyBob3N0bmFtZSBzc2hkWzk4ODIwXTogZXJyb3I6IFBBTTogYXV0aGVu dGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6 MzQ6NTUgaG9zdG5hbWUgc3NoZFs5ODgzM106IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9u IGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM0OjU4IGhv c3RuYW1lIHNzaGRbOTg4MzZdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBm b3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNToyMCBob3N0bmFtZSBz c2hkWzk4ODM2XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3Qg ZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6MzU6MjAgaG9zdG5hbWUgc3NoZFs5ODgz M106IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkw LjgxLjExMS4xODAKT2N0ICAyIDIzOjM1OjMzIGhvc3RuYW1lIHNzaGRbOTg4MzZdOiBlcnJv cjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEu MTgwCk9jdCAgMiAyMzozNTozMyBob3N0bmFtZSBzc2hkWzk4ODMzXTogZXJyb3I6IFBBTTog YXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3Qg IDIgMjM6MzU6MzQgaG9zdG5hbWUgc3NoZFs5ODgzM106IGVycm9yOiBQQU06IGF1dGhlbnRp Y2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM1 OjM0IGhvc3RuYW1lIHNzaGRbOTg4MzZdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBl cnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNTozNCBob3N0 bmFtZSBzc2hkWzk4ODMzXTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9y IHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6MzU6MzUgaG9zdG5hbWUgc3No ZFs5ODgzNl06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZy b20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM1OjM1IGhvc3RuYW1lIHNzaGRbOTg4MzNd OiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44 MS4xMTEuMTgwCk9jdCAgMiAyMzozNTozNSBob3N0bmFtZSBzc2hkWzk4ODM2XTogZXJyb3I6 IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4 MApPY3QgIDIgMjM6MzU6MzkgaG9zdG5hbWUgc3NoZFs5ODg3NF06IGVycm9yOiBQQU06IGF1 dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAy IDIzOjM1OjM5IGhvc3RuYW1lIHNzaGRbOTg4NzJdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNh dGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNToz OSBob3N0bmFtZSBzc2hkWzk4ODc0XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJy b3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6MzU6MzkgaG9zdG5h bWUgc3NoZFs5ODg3Ml06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciBy b290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM1OjQwIGhvc3RuYW1lIHNzaGRb OTg4NzRdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9t IDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNTo0MCBob3N0bmFtZSBzc2hkWzk4ODc0XTog ZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEu MTExLjE4MApPY3QgIDIgMjM6MzU6NDAgaG9zdG5hbWUgc3NoZFs5ODg3Ml06IGVycm9yOiBQ QU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAK T2N0ICAyIDIzOjM1OjQxIGhvc3RuYW1lIHNzaGRbOTg4NzRdOiBlcnJvcjogUEFNOiBhdXRo ZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAy MzozNTo0MSBob3N0bmFtZSBzc2hkWzk4ODcyXTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRp b24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6MzU6NDEg aG9zdG5hbWUgc3NoZFs5ODg3NF06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9y IGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM1OjQyIGhvc3RuYW1l IHNzaGRbOTg4NzJdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9v dCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNTo0MyBob3N0bmFtZSBzc2hkWzk4 ODcyXTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAx OTAuODEuMTExLjE4MApPY3QgIDIgMjM6MzU6NDQgaG9zdG5hbWUgc3NoZFs5ODg4N106IGVy cm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjEx MS4xODAKT2N0ICAyIDIzOjM1OjQ1IGhvc3RuYW1lIHNzaGRbOTg4ODddOiBlcnJvcjogUEFN OiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9j dCAgMiAyMzozNTo0NiBob3N0bmFtZSBzc2hkWzk4ODg3XTogZXJyb3I6IFBBTTogYXV0aGVu dGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6 MzU6NDYgaG9zdG5hbWUgc3NoZFs5ODg4N106IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9u IGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM1OjQ2IGhv c3RuYW1lIHNzaGRbOTg4OTBdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBm b3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNTo0NyBob3N0bmFtZSBz c2hkWzk4ODg3XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3Qg ZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6MzU6NDcgaG9zdG5hbWUgc3NoZFs5ODg5 MF06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkw LjgxLjExMS4xODAKT2N0ICAyIDIzOjM1OjQ3IGhvc3RuYW1lIHNzaGRbOTg4ODddOiBlcnJv cjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEu MTgwCk9jdCAgMiAyMzozNTo0NyBob3N0bmFtZSBzc2hkWzk4ODkwXTogZXJyb3I6IFBBTTog YXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3Qg IDIgMjM6MzU6NDggaG9zdG5hbWUgc3NoZFs5ODg5MF06IGVycm9yOiBQQU06IGF1dGhlbnRp Y2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM1 OjQ5IGhvc3RuYW1lIHNzaGRbOTg4OTBdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBl cnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNTo0OSBob3N0 bmFtZSBzc2hkWzk4ODkwXTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9y IHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6MzU6NTAgaG9zdG5hbWUgc3No ZFs5ODkwMl06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZy b20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM1OjUxIGhvc3RuYW1lIHNzaGRbOTg5MDJd OiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44 MS4xMTEuMTgwCk9jdCAgMiAyMzozNTo1MSBob3N0bmFtZSBzc2hkWzk4OTAyXTogZXJyb3I6 IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4 MApPY3QgIDIgMjM6MzU6NTIgaG9zdG5hbWUgc3NoZFs5ODkwMl06IGVycm9yOiBQQU06IGF1 dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAy IDIzOjM1OjUzIGhvc3RuYW1lIHNzaGRbOTg5MDZdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNh dGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNTo1 MyBob3N0bmFtZSBzc2hkWzk4OTAyXTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJy b3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6MzY6MTkgaG9zdG5h bWUgc3NoZFs5ODkwMl06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciBy b290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM2OjE5IGhvc3RuYW1lIHNzaGRb OTg5MDZdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9t IDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNjoyMiBob3N0bmFtZSBzc2hkWzk4OTM2XTog ZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEu MTExLjE4MApPY3QgIDIgMjM6MzY6MzMgaG9zdG5hbWUgc3NoZFs5ODkzNl06IGVycm9yOiBQ QU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAK T2N0ICAyIDIzOjM2OjMzIGhvc3RuYW1lIHNzaGRbOTg5MDZdOiBlcnJvcjogUEFNOiBhdXRo ZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAy MzozNjozMyBob3N0bmFtZSBzc2hkWzk4OTM2XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRp b24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6MzY6MzMg aG9zdG5hbWUgc3NoZFs5ODkwNl06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9y IGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM2OjM0IGhvc3RuYW1l IHNzaGRbOTg5MzZdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9v dCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNjozNCBob3N0bmFtZSBzc2hkWzk4 OTA2XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAx OTAuODEuMTExLjE4MApPY3QgIDIgMjM6MzY6MzQgaG9zdG5hbWUgc3NoZFs5ODkzNl06IGVy cm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjEx MS4xODAKT2N0ICAyIDIzOjM2OjM0IGhvc3RuYW1lIHNzaGRbOTg5MDZdOiBlcnJvcjogUEFN OiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9j dCAgMiAyMzozNjozNSBob3N0bmFtZSBzc2hkWzk4OTM2XTogZXJyb3I6IFBBTTogYXV0aGVu dGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6 MzY6MzcgaG9zdG5hbWUgc3NoZFs5ODk0OF06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9u IGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM2OjM4IGhv c3RuYW1lIHNzaGRbOTg5NTBdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBm b3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNjozOCBob3N0bmFtZSBz c2hkWzk4OTQ4XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3Qg ZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6MzY6MzkgaG9zdG5hbWUgc3NoZFs5ODk1 MF06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkw LjgxLjExMS4xODAKT2N0ICAyIDIzOjM2OjM5IGhvc3RuYW1lIHNzaGRbOTg5NDhdOiBlcnJv cjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEu MTgwCk9jdCAgMiAyMzozNjo0MCBob3N0bmFtZSBzc2hkWzk4OTUwXTogZXJyb3I6IFBBTTog YXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3Qg IDIgMjM6MzY6NDAgaG9zdG5hbWUgc3NoZFs5ODk0OF06IGVycm9yOiBQQU06IGF1dGhlbnRp Y2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM2 OjQwIGhvc3RuYW1lIHNzaGRbOTg5NTBdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBl cnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNjo0MCBob3N0 bmFtZSBzc2hkWzk4OTQ4XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9y IHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6MzY6NDEgaG9zdG5hbWUgc3No ZFs5ODk1MF06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZy b20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM2OjQxIGhvc3RuYW1lIHNzaGRbOTg5NDhd OiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44 MS4xMTEuMTgwCk9jdCAgMiAyMzozNjo0MSBob3N0bmFtZSBzc2hkWzk4OTUwXTogZXJyb3I6 IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4 MApPY3QgIDIgMjM6MzY6NDQgaG9zdG5hbWUgc3NoZFs5ODk2NF06IGVycm9yOiBQQU06IGF1 dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAy IDIzOjM2OjQ0IGhvc3RuYW1lIHNzaGRbOTg5NjRdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNh dGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNjo0 NSBob3N0bmFtZSBzc2hkWzk4OTY0XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJy b3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6MzY6NDYgaG9zdG5h bWUgc3NoZFs5ODk2NF06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciBy b290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM2OjQ2IGhvc3RuYW1lIHNzaGRb OTg5NjRdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9t IDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNjo0NyBob3N0bmFtZSBzc2hkWzk4OTY0XTog ZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEu MTExLjE4MApPY3QgIDIgMjM6MzY6NDcgaG9zdG5hbWUgc3NoZFs5ODk2OV06IGVycm9yOiBQ QU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAK T2N0ICAyIDIzOjM2OjUxIGhvc3RuYW1lIHNzaGRbOTg5NzVdOiBlcnJvcjogUEFNOiBhdXRo ZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAy MzozNzoxNCBob3N0bmFtZSBzc2hkWzk4OTY5XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRp b24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6Mzc6MTQg aG9zdG5hbWUgc3NoZFs5ODk3NV06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9y IGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM3OjI5IGhvc3RuYW1l IHNzaGRbOTg5NzVdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9v dCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNzoyOSBob3N0bmFtZSBzc2hkWzk4 OTY5XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAx OTAuODEuMTExLjE4MApPY3QgIDIgMjM6Mzc6MzAgaG9zdG5hbWUgc3NoZFs5ODk3NV06IGVy cm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjEx MS4xODAKT2N0ICAyIDIzOjM3OjMwIGhvc3RuYW1lIHNzaGRbOTg5NjldOiBlcnJvcjogUEFN OiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9j dCAgMiAyMzozNzozMCBob3N0bmFtZSBzc2hkWzk4OTc1XTogZXJyb3I6IFBBTTogYXV0aGVu dGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6 Mzc6MzAgaG9zdG5hbWUgc3NoZFs5ODk2OV06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9u IGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM3OjMxIGhv c3RuYW1lIHNzaGRbOTg5NzVdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBm b3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNzozMSBob3N0bmFtZSBz c2hkWzk4OTY5XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3Qg ZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6Mzc6MzQgaG9zdG5hbWUgc3NoZFs5OTAw OF06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkw LjgxLjExMS4xODAKT2N0ICAyIDIzOjM3OjM1IGhvc3RuYW1lIHNzaGRbOTkwMDhdOiBlcnJv cjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEu MTgwCk9jdCAgMiAyMzozNzozNSBob3N0bmFtZSBzc2hkWzk5MDA4XTogZXJyb3I6IFBBTTog YXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3Qg IDIgMjM6Mzc6MzYgaG9zdG5hbWUgc3NoZFs5OTAwOF06IGVycm9yOiBQQU06IGF1dGhlbnRp Y2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM3 OjM3IGhvc3RuYW1lIHNzaGRbOTkwMDhdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBl cnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNzozNyBob3N0 bmFtZSBzc2hkWzk5MDEyXTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9y IHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6Mzc6MzcgaG9zdG5hbWUgc3No ZFs5OTAwOF06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZy b20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM3OjM4IGhvc3RuYW1lIHNzaGRbOTkwMTJd OiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44 MS4xMTEuMTgwCk9jdCAgMiAyMzozNzozOCBob3N0bmFtZSBzc2hkWzk5MDEyXTogZXJyb3I6 IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4 MApPY3QgIDIgMjM6Mzc6MzkgaG9zdG5hbWUgc3NoZFs5OTAxMl06IGVycm9yOiBQQU06IGF1 dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAy IDIzOjM3OjM5IGhvc3RuYW1lIHNzaGRbOTkwMTJdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNh dGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNzo0 MCBob3N0bmFtZSBzc2hkWzk5MDEyXTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJy b3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6Mzc6NDMgaG9zdG5h bWUgc3NoZFs5OTAyNF06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciBy b290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM3OjQzIGhvc3RuYW1lIHNzaGRb OTkwMjRdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9t IDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNzo0NCBob3N0bmFtZSBzc2hkWzk5MDI0XTog ZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEu MTExLjE4MApPY3QgIDIgMjM6Mzc6NDUgaG9zdG5hbWUgc3NoZFs5OTAyNF06IGVycm9yOiBQ QU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAK T2N0ICAyIDIzOjM3OjQ1IGhvc3RuYW1lIHNzaGRbOTkwMjRdOiBlcnJvcjogUEFNOiBhdXRo ZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAy MzozNzo0NiBob3N0bmFtZSBzc2hkWzk5MDI0XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRp b24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6Mzc6NDkg aG9zdG5hbWUgc3NoZFs5OTAzMl06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9y IGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM3OjUwIGhvc3RuYW1l IHNzaGRbOTkwMzJdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9v dCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNzo1MCBob3N0bmFtZSBzc2hkWzk5 MDM0XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAx OTAuODEuMTExLjE4MApPY3QgIDIgMjM6Mzc6NTEgaG9zdG5hbWUgc3NoZFs5OTAzMl06IGVy cm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjEx MS4xODAKT2N0ICAyIDIzOjM3OjUxIGhvc3RuYW1lIHNzaGRbOTkwMzRdOiBlcnJvcjogUEFN OiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9j dCAgMiAyMzozNzo1MSBob3N0bmFtZSBzc2hkWzk5MDMyXTogZXJyb3I6IFBBTTogYXV0aGVu dGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6 Mzc6NTEgaG9zdG5hbWUgc3NoZFs5OTAzNF06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9u IGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM3OjUyIGhv c3RuYW1lIHNzaGRbOTkwMzJdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBm b3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNzo1MiBob3N0bmFtZSBz c2hkWzk5MDMyXTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3Qg ZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6Mzc6NTIgaG9zdG5hbWUgc3NoZFs5OTAz NF06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkw LjgxLjExMS4xODAKT2N0ICAyIDIzOjM3OjUzIGhvc3RuYW1lIHNzaGRbOTkwMzRdOiBlcnJv cjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEu MTgwCk9jdCAgMiAyMzozNzo1NCBob3N0bmFtZSBzc2hkWzk5MDM0XTogZXJyb3I6IFBBTTog YXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3Qg IDIgMjM6Mzc6NTcgaG9zdG5hbWUgc3NoZFs5OTA1MF06IGVycm9yOiBQQU06IGF1dGhlbnRp Y2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM3 OjU3IGhvc3RuYW1lIHNzaGRbOTkwNDddOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBl cnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNzo1NyBob3N0 bmFtZSBzc2hkWzk5MDUwXTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9y IHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6Mzc6NTcgaG9zdG5hbWUgc3No ZFs5OTA0N106IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZy b20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM3OjU4IGhvc3RuYW1lIHNzaGRbOTkwNTBd OiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44 MS4xMTEuMTgwCk9jdCAgMiAyMzozNzo1OCBob3N0bmFtZSBzc2hkWzk5MDQ3XTogZXJyb3I6 IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4 MApPY3QgIDIgMjM6Mzc6NTggaG9zdG5hbWUgc3NoZFs5OTA1MF06IGVycm9yOiBQQU06IGF1 dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAy IDIzOjM3OjU4IGhvc3RuYW1lIHNzaGRbOTkwNDddOiBlcnJvcjogUEFNOiBhdXRoZW50aWNh dGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozNzo1 OSBob3N0bmFtZSBzc2hkWzk5MDUwXTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJy b3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6Mzc6NTkgaG9zdG5h bWUgc3NoZFs5OTA0N106IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciBy b290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM3OjU5IGhvc3RuYW1lIHNzaGRb OTkwNTBdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9t IDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozODowMCBob3N0bmFtZSBzc2hkWzk5MDQ3XTog ZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEu MTExLjE4MApPY3QgIDIgMjM6Mzg6MDMgaG9zdG5hbWUgc3NoZFs5OTA3NV06IGVycm9yOiBQ QU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAK T2N0ICAyIDIzOjM4OjA0IGhvc3RuYW1lIHNzaGRbOTkwNzVdOiBlcnJvcjogUEFNOiBhdXRo ZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAy MzozODowNSBob3N0bmFtZSBzc2hkWzk5MDc1XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRp b24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6Mzg6MDUg aG9zdG5hbWUgc3NoZFs5OTA3NV06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9y IGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM4OjA1IGhvc3RuYW1l IHNzaGRbOTkwODZdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9v dCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozODowNiBob3N0bmFtZSBzc2hkWzk5 MDc1XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAx OTAuODEuMTExLjE4MApPY3QgIDIgMjM6Mzg6MDYgaG9zdG5hbWUgc3NoZFs5OTA4Nl06IGVy cm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjEx MS4xODAKT2N0ICAyIDIzOjM4OjA2IGhvc3RuYW1lIHNzaGRbOTkwNzVdOiBlcnJvcjogUEFN OiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9j dCAgMiAyMzozODowNyBob3N0bmFtZSBzc2hkWzk5MDg2XTogZXJyb3I6IFBBTTogYXV0aGVu dGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6 Mzg6MDcgaG9zdG5hbWUgc3NoZFs5OTA4Nl06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9u IGVycm9yIGZvciByb290IGZyb20gMTkwLjgxLjExMS4xODAKT2N0ICAyIDIzOjM4OjA4IGhv c3RuYW1lIHNzaGRbOTkwODZdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBm b3Igcm9vdCBmcm9tIDE5MC44MS4xMTEuMTgwCk9jdCAgMiAyMzozODowOSBob3N0bmFtZSBz c2hkWzk5MDk3XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3Qg ZnJvbSAxOTAuODEuMTExLjE4MApPY3QgIDIgMjM6NTE6MDEgaG9zdG5hbWUgc2VuZG1haWxb OTkzNjldOiBOT1FVRVVFOiBTWVNFUlIocm9vdCk6IGNhbiBub3QgY2hkaXIoL3Zhci9zcG9v bC9jbGllbnRtcXVldWUvKTogUGVybWlzc2lvbiBkZW5pZWQKT2N0ICAzIDAwOjIxOjAwIGhv c3RuYW1lIHNlbmRtYWlsWzEyOV06IE5PUVVFVUU6IFNZU0VSUihyb290KTogY2FuIG5vdCBj aGRpcigvdmFyL3Nwb29sL2NsaWVudG1xdWV1ZS8pOiBQZXJtaXNzaW9uIGRlbmllZApPY3Qg IDMgMDA6Mzc6MjcgaG9zdG5hbWUgc2VuZG1haWxbODA2XTogTk9RVUVVRTogU1lTRVJSKHJv b3QpOiBjYW4gbm90IGNoZGlyKC92YXIvc3Bvb2wvY2xpZW50bXF1ZXVlLyk6IFBlcm1pc3Np b24gZGVuaWVkCk9jdCAgMyAwMDo1NjoxMyBob3N0bmFtZSBzc2hkWzQ5MTBdOiBlcnJvcjog UEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDIwMS4yMzAuMTU1LjYK T2N0ICAzIDAwOjU2OjEzIGhvc3RuYW1lIHNzaGRbNDkxNV06IGVycm9yOiBQQU06IGF1dGhl bnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMjAxLjIzMC4xNTUuNgpPY3QgIDMgMDA6 NTY6MTQgaG9zdG5hbWUgc3NoZFs0OTE0XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24g ZXJyb3IgZm9yIHJvb3QgZnJvbSAyMDEuMjMwLjE1NS42Ck9jdCAgMyAwMDo1NjoxNiBob3N0 bmFtZSBzc2hkWzQ5MTBdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Ig cm9vdCBmcm9tIDIwMS4yMzAuMTU1LjYKT2N0ICAzIDAwOjU2OjMwIGhvc3RuYW1lIHNzaGRb NDkxMF06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20g MjAxLjIzMC4xNTUuNgpPY3QgIDMgMDA6NTY6MzEgaG9zdG5hbWUgc3NoZFs0OTE0XTogZXJy b3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAyMDEuMjMwLjE1 NS42Ck9jdCAgMyAwMDo1NjozOSBob3N0bmFtZSBzc2hkWzQ5MTRdOiBlcnJvcjogUEFNOiBh dXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDIwMS4yMzAuMTU1LjYKT2N0ICAz IDAwOjU2OjM5IGhvc3RuYW1lIHNzaGRbNDkxOV06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0 aW9uIGVycm9yIGZvciByb290IGZyb20gMjAxLjIzMC4xNTUuNgpPY3QgIDMgMDA6NTY6NDAg aG9zdG5hbWUgc3NoZFs0OTExXTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3Ig Zm9yIHJvb3QgZnJvbSAyMDEuMjMwLjE1NS42Ck9jdCAgMyAwMDo1Njo0MCBob3N0bmFtZSBz c2hkWzQ5MTBdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBm cm9tIDIwMS4yMzAuMTU1LjYKT2N0ICAzIDAwOjU2OjQwIGhvc3RuYW1lIHNzaGRbNDkxOV06 IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMjAxLjIz MC4xNTUuNgpPY3QgIDMgMDA6NTY6NDAgaG9zdG5hbWUgc3NoZFs0OTE0XTogZXJyb3I6IFBB TTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAyMDEuMjMwLjE1NS42Ck9j dCAgMyAwMDo1Njo0MSBob3N0bmFtZSBzc2hkWzQ5MTBdOiBlcnJvcjogUEFNOiBhdXRoZW50 aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDIwMS4yMzAuMTU1LjYKT2N0ICAzIDAwOjU2 OjQxIGhvc3RuYW1lIHNzaGRbNDkxMV06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVy cm9yIGZvciByb290IGZyb20gMjAxLjIzMC4xNTUuNgpPY3QgIDMgMDA6NTY6NDEgaG9zdG5h bWUgc3NoZFs0OTE1XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJv b3QgZnJvbSAyMDEuMjMwLjE1NS42Ck9jdCAgMyAwMDo1Njo0MSBob3N0bmFtZSBzc2hkWzQ5 MTRdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDIw MS4yMzAuMTU1LjYKT2N0ICAzIDAwOjU2OjQxIGhvc3RuYW1lIHNzaGRbNDkxMF06IGVycm9y OiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMjAxLjIzMC4xNTUu NgpPY3QgIDMgMDA6NTY6NDEgaG9zdG5hbWUgc3NoZFs0OTE2XTogZXJyb3I6IFBBTTogYXV0 aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAyMDEuMjMwLjE1NS42Ck9jdCAgMyAw MDo1Njo0MiBob3N0bmFtZSBzc2hkWzQ5MTFdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlv biBlcnJvciBmb3Igcm9vdCBmcm9tIDIwMS4yMzAuMTU1LjYKT2N0ICAzIDAwOjU2OjQyIGhv c3RuYW1lIHNzaGRbNDkxNF06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZv ciByb290IGZyb20gMjAxLjIzMC4xNTUuNgpPY3QgIDMgMDA6NTY6NDIgaG9zdG5hbWUgc3No ZFs0OTE1XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJv bSAyMDEuMjMwLjE1NS42Ck9jdCAgMyAwMDo1Njo0MiBob3N0bmFtZSBzc2hkWzQ5MTZdOiBl cnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDIwMS4yMzAu MTU1LjYKT2N0ICAzIDAwOjU2OjQzIGhvc3RuYW1lIHNzaGRbNDkxMV06IGVycm9yOiBQQU06 IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMjAxLjIzMC4xNTUuNgpPY3Qg IDMgMDA6NTY6NDMgaG9zdG5hbWUgc3NoZFs0OTE5XTogZXJyb3I6IFBBTTogYXV0aGVudGlj YXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAyMDEuMjMwLjE1NS42Ck9jdCAgMyAwMDo1Njo0 MyBob3N0bmFtZSBzc2hkWzQ5MTZdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJv ciBmb3Igcm9vdCBmcm9tIDIwMS4yMzAuMTU1LjYKT2N0ICAzIDAwOjU2OjQzIGhvc3RuYW1l IHNzaGRbNDkxNV06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290 IGZyb20gMjAxLjIzMC4xNTUuNgpPY3QgIDMgMDA6NTY6NDMgaG9zdG5hbWUgc3NoZFs0OTE5 XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAyMDEu MjMwLjE1NS42Ck9jdCAgMyAwMDo1Njo0NCBob3N0bmFtZSBzc2hkWzQ5MTldOiBlcnJvcjog UEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDIwMS4yMzAuMTU1LjYK T2N0ICAzIDAwOjU2OjQ0IGhvc3RuYW1lIHNzaGRbNDkxNl06IGVycm9yOiBQQU06IGF1dGhl bnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMjAxLjIzMC4xNTUuNgpPY3QgIDMgMDA6 NTY6NDQgaG9zdG5hbWUgc3NoZFs0OTE1XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24g ZXJyb3IgZm9yIHJvb3QgZnJvbSAyMDEuMjMwLjE1NS42Ck9jdCAgMyAwMDo1Njo0NCBob3N0 bmFtZSBzc2hkWzQ5MTFdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Ig cm9vdCBmcm9tIDIwMS4yMzAuMTU1LjYKT2N0ICAzIDAwOjU2OjQ1IGhvc3RuYW1lIHNzaGRb NDkxOV06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20g MjAxLjIzMC4xNTUuNgpPY3QgIDMgMDA6NTY6NDUgaG9zdG5hbWUgc3NoZFs0OTE2XTogZXJy b3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAyMDEuMjMwLjE1 NS42Ck9jdCAgMyAwMDo1Njo0NSBob3N0bmFtZSBzc2hkWzQ5MTVdOiBlcnJvcjogUEFNOiBh dXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDIwMS4yMzAuMTU1LjYKT2N0ICAz IDAwOjU2OjQ1IGhvc3RuYW1lIHNzaGRbNDkxMV06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0 aW9uIGVycm9yIGZvciByb290IGZyb20gMjAxLjIzMC4xNTUuNgpPY3QgIDMgMDA6NTY6NDUg aG9zdG5hbWUgc3NoZFs0OTE2XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3Ig Zm9yIHJvb3QgZnJvbSAyMDEuMjMwLjE1NS42Ck9jdCAgMyAwMDo1NzowNCBob3N0bmFtZSBz c2hkWzQ5MjJdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBm cm9tIDIwMS4yMzAuMTU1LjYKT2N0ICAzIDAwOjU3OjA1IGhvc3RuYW1lIHNzaGRbNDkyMl06 IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMjAxLjIz MC4xNTUuNgpPY3QgIDMgMDA6NTc6MDggaG9zdG5hbWUgc3NoZFs0OTIyXTogZXJyb3I6IFBB TTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAyMDEuMjMwLjE1NS42Ck9j dCAgMyAwMDo1NzoxMSBob3N0bmFtZSBzc2hkWzQ5MjJdOiBlcnJvcjogUEFNOiBhdXRoZW50 aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDIwMS4yMzAuMTU1LjYKT2N0ICAzIDAwOjU3 OjEyIGhvc3RuYW1lIHNzaGRbNDkyMl06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVy cm9yIGZvciByb290IGZyb20gMjAxLjIzMC4xNTUuNgpPY3QgIDMgMDA6NTc6MTIgaG9zdG5h bWUgc3NoZFs0OTIyXTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJv b3QgZnJvbSAyMDEuMjMwLjE1NS42Ck9jdCAgMyAwMDo1NzoyNiBob3N0bmFtZSBzc2hkWzQ5 NjJdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDIw MS4yMzAuMTU1LjYKT2N0ICAzIDAwOjU3OjI2IGhvc3RuYW1lIHNzaGRbNDk2Ml06IGVycm9y OiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMjAxLjIzMC4xNTUu NgpPY3QgIDMgMDA6NTc6MjggaG9zdG5hbWUgc3NoZFs0OTYyXTogZXJyb3I6IFBBTTogYXV0 aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAyMDEuMjMwLjE1NS42Ck9jdCAgMyAw MDo1NzozMSBob3N0bmFtZSBzc2hkWzQ5NjBdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlv biBlcnJvciBmb3Igcm9vdCBmcm9tIDIwMS4yMzAuMTU1LjYKT2N0ICAzIDAwOjU3OjMxIGhv c3RuYW1lIHNzaGRbNDk2Ml06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZv ciByb290IGZyb20gMjAxLjIzMC4xNTUuNgpPY3QgIDMgMDA6NTc6MzEgaG9zdG5hbWUgc3No ZFs0OTY0XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJv bSAyMDEuMjMwLjE1NS42Ck9jdCAgMyAwMDo1NzozMiBob3N0bmFtZSBzc2hkWzQ5NjJdOiBl cnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDIwMS4yMzAu MTU1LjYKT2N0ICAzIDAwOjU3OjMyIGhvc3RuYW1lIHNzaGRbNDk2Ml06IGVycm9yOiBQQU06 IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMjAxLjIzMC4xNTUuNgpPY3Qg IDMgMDA6NTc6MzQgaG9zdG5hbWUgc3NoZFs0OTYwXTogZXJyb3I6IFBBTTogYXV0aGVudGlj YXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAyMDEuMjMwLjE1NS42Ck9jdCAgMyAwMDo1Nzoz NCBob3N0bmFtZSBzc2hkWzQ5NjRdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJv ciBmb3Igcm9vdCBmcm9tIDIwMS4yMzAuMTU1LjYKT2N0ICAzIDAwOjU3OjM0IGhvc3RuYW1l IHNzaGRbNDk2MF06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290 IGZyb20gMjAxLjIzMC4xNTUuNgpPY3QgIDMgMDA6NTc6MzQgaG9zdG5hbWUgc3NoZFs0OTY0 XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAyMDEu MjMwLjE1NS42Ck9jdCAgMyAwMDo1NzozNSBob3N0bmFtZSBzc2hkWzQ5NjFdOiBlcnJvcjog UEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDIwMS4yMzAuMTU1LjYK T2N0ICAzIDAwOjU3OjM1IGhvc3RuYW1lIHNzaGRbNDk2MF06IGVycm9yOiBQQU06IGF1dGhl bnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMjAxLjIzMC4xNTUuNgpPY3QgIDMgMDA6 NTc6MzUgaG9zdG5hbWUgc3NoZFs0OTY0XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24g ZXJyb3IgZm9yIHJvb3QgZnJvbSAyMDEuMjMwLjE1NS42Ck9jdCAgMyAwMDo1NzozNSBob3N0 bmFtZSBzc2hkWzQ5NjBdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Ig cm9vdCBmcm9tIDIwMS4yMzAuMTU1LjYKT2N0ICAzIDAwOjU3OjM1IGhvc3RuYW1lIHNzaGRb NDk2MV06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20g MjAxLjIzMC4xNTUuNgpPY3QgIDMgMDA6NTc6MzUgaG9zdG5hbWUgc3NoZFs0OTY0XTogZXJy b3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAyMDEuMjMwLjE1 NS42Ck9jdCAgMyAwMDo1NzozNiBob3N0bmFtZSBzc2hkWzQ5NjBdOiBlcnJvcjogUEFNOiBh dXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDIwMS4yMzAuMTU1LjYKT2N0ICAz IDAwOjU3OjM3IGhvc3RuYW1lIHNzaGRbNDk2MV06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0 aW9uIGVycm9yIGZvciByb290IGZyb20gMjAxLjIzMC4xNTUuNgpPY3QgIDMgMDA6NTc6Mzcg aG9zdG5hbWUgc3NoZFs0OTY0XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3Ig Zm9yIHJvb3QgZnJvbSAyMDEuMjMwLjE1NS42Ck9jdCAgMyAwMDo1NzozNyBob3N0bmFtZSBz c2hkWzQ5NjFdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBm cm9tIDIwMS4yMzAuMTU1LjYKT2N0ICAzIDAwOjU3OjM4IGhvc3RuYW1lIHNzaGRbNDk2MV06 IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMjAxLjIz MC4xNTUuNgpPY3QgIDMgMDA6NTc6MzggaG9zdG5hbWUgc3NoZFs0OTYxXTogZXJyb3I6IFBB TTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAyMDEuMjMwLjE1NS42Ck9j dCAgMyAwMDo1Nzo0NSBob3N0bmFtZSBzc2hkWzQ5OTddOiBlcnJvcjogUEFNOiBhdXRoZW50 aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDIwMS4yMzAuMTU1LjYKT2N0ICAzIDAwOjU3 OjQ2IGhvc3RuYW1lIHNzaGRbNDk5NF06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVy cm9yIGZvciByb290IGZyb20gMjAxLjIzMC4xNTUuNgpPY3QgIDMgMDA6NTc6NDYgaG9zdG5h bWUgc3NoZFs0OTk3XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJv b3QgZnJvbSAyMDEuMjMwLjE1NS42Ck9jdCAgMyAwMDo1Nzo0NyBob3N0bmFtZSBzc2hkWzQ5 OTRdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDIw MS4yMzAuMTU1LjYKT2N0ICAzIDAwOjU3OjQ3IGhvc3RuYW1lIHNzaGRbNDk5N106IGVycm9y OiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMjAxLjIzMC4xNTUu NgpPY3QgIDMgMDA6NTc6NDcgaG9zdG5hbWUgc3NoZFs1MDA3XTogZXJyb3I6IFBBTTogYXV0 aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAyMDEuMjMwLjE1NS42Ck9jdCAgMyAw MDo1Nzo0NyBob3N0bmFtZSBzc2hkWzQ5OTddOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlv biBlcnJvciBmb3Igcm9vdCBmcm9tIDIwMS4yMzAuMTU1LjYKT2N0ICAzIDAwOjU3OjQ3IGhv c3RuYW1lIHNzaGRbNDk5NF06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZv ciByb290IGZyb20gMjAxLjIzMC4xNTUuNgpPY3QgIDMgMDA6NTc6NDcgaG9zdG5hbWUgc3No ZFs1MDA3XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJv bSAyMDEuMjMwLjE1NS42Ck9jdCAgMyAwMDo1Nzo0OCBob3N0bmFtZSBzc2hkWzQ5OTRdOiBl cnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDIwMS4yMzAu MTU1LjYKT2N0ICAzIDAwOjU3OjUwIGhvc3RuYW1lIHNzaGRbNTAwN106IGVycm9yOiBQQU06 IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMjAxLjIzMC4xNTUuNgpPY3Qg IDMgMDA6NTc6NTAgaG9zdG5hbWUgc3NoZFs0OTk0XTogZXJyb3I6IFBBTTogYXV0aGVudGlj YXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAyMDEuMjMwLjE1NS42Ck9jdCAgMyAwMDo1Nzo1 MSBob3N0bmFtZSBzc2hkWzUwMDddOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJv ciBmb3Igcm9vdCBmcm9tIDIwMS4yMzAuMTU1LjYKT2N0ICAzIDAwOjU3OjUxIGhvc3RuYW1l IHNzaGRbNDk5N106IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290 IGZyb20gMjAxLjIzMC4xNTUuNgpPY3QgIDMgMDA6NTc6NTIgaG9zdG5hbWUgc3NoZFs1MDA3 XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAyMDEu MjMwLjE1NS42Ck9jdCAgMyAwMDo1Nzo1MyBob3N0bmFtZSBzc2hkWzQ5OTddOiBlcnJvcjog UEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDIwMS4yMzAuMTU1LjYK T2N0ICAzIDAwOjU3OjUzIGhvc3RuYW1lIHNzaGRbNDk5OV06IGVycm9yOiBQQU06IGF1dGhl bnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMjAxLjIzMC4xNTUuNgpPY3QgIDMgMDA6 NTc6NTMgaG9zdG5hbWUgc3NoZFs1MDA3XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24g ZXJyb3IgZm9yIHJvb3QgZnJvbSAyMDEuMjMwLjE1NS42Ck9jdCAgMyAwMDo1Nzo1NCBob3N0 bmFtZSBzc2hkWzQ5OTRdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Ig cm9vdCBmcm9tIDIwMS4yMzAuMTU1LjYKT2N0ICAzIDAwOjU3OjU1IGhvc3RuYW1lIHNzaGRb NDk5OV06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20g MjAxLjIzMC4xNTUuNgpPY3QgIDMgMDA6NTc6NTUgaG9zdG5hbWUgc3NoZFs1MDI2XTogZXJy b3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAyMDEuMjMwLjE1 NS42Ck9jdCAgMyAwMDo1Nzo1NSBob3N0bmFtZSBzc2hkWzQ5OTldOiBlcnJvcjogUEFNOiBh dXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDIwMS4yMzAuMTU1LjYKT2N0ICAz IDAwOjU3OjU2IGhvc3RuYW1lIHNzaGRbNTAyNl06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0 aW9uIGVycm9yIGZvciByb290IGZyb20gMjAxLjIzMC4xNTUuNgpPY3QgIDMgMDA6NTc6NTYg aG9zdG5hbWUgc3NoZFs0OTk5XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3Ig Zm9yIHJvb3QgZnJvbSAyMDEuMjMwLjE1NS42Ck9jdCAgMyAwMDo1Nzo1NyBob3N0bmFtZSBz c2hkWzUwMjZdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBm cm9tIDIwMS4yMzAuMTU1LjYKT2N0ICAzIDAwOjU3OjU3IGhvc3RuYW1lIHNzaGRbNDk5OV06 IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMjAxLjIz MC4xNTUuNgpPY3QgIDMgMDA6NTc6NTcgaG9zdG5hbWUgc3NoZFs1MDI2XTogZXJyb3I6IFBB TTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAyMDEuMjMwLjE1NS42Ck9j dCAgMyAwMDo1Nzo1OCBob3N0bmFtZSBzc2hkWzQ5OTldOiBlcnJvcjogUEFNOiBhdXRoZW50 aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDIwMS4yMzAuMTU1LjYKT2N0ICAzIDAwOjU3 OjU4IGhvc3RuYW1lIHNzaGRbNTAyNl06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVy cm9yIGZvciByb290IGZyb20gMjAxLjIzMC4xNTUuNgpPY3QgIDMgMDA6NTc6NTkgaG9zdG5h bWUgc3NoZFs1MDI2XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJv b3QgZnJvbSAyMDEuMjMwLjE1NS42Ck9jdCAgMyAwMDo1ODowMiBob3N0bmFtZSBzc2hkWzUw MjhdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDIw MS4yMzAuMTU1LjYKT2N0ICAzIDAwOjU4OjAzIGhvc3RuYW1lIHNzaGRbNTAyOF06IGVycm9y OiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMjAxLjIzMC4xNTUu NgpPY3QgIDMgMDA6NTg6MDMgaG9zdG5hbWUgc3NoZFs1MDI4XTogZXJyb3I6IFBBTTogYXV0 aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAyMDEuMjMwLjE1NS42Ck9jdCAgMyAw MDo1ODowNCBob3N0bmFtZSBzc2hkWzUwMjhdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlv biBlcnJvciBmb3Igcm9vdCBmcm9tIDIwMS4yMzAuMTU1LjYKT2N0ICAzIDAwOjU4OjA1IGhv c3RuYW1lIHNzaGRbNTA1Ml06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZv ciByb290IGZyb20gMjAxLjIzMC4xNTUuNgpPY3QgIDMgMDA6NTg6MDUgaG9zdG5hbWUgc3No ZFs1MDI4XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJv bSAyMDEuMjMwLjE1NS42Ck9jdCAgMyAwMDo1ODowNSBob3N0bmFtZSBzc2hkWzUwNTJdOiBl cnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDIwMS4yMzAu MTU1LjYKT2N0ICAzIDAwOjU4OjA2IGhvc3RuYW1lIHNzaGRbNTA1Ml06IGVycm9yOiBQQU06 IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMjAxLjIzMC4xNTUuNgpPY3Qg IDMgMDA6NTg6MDYgaG9zdG5hbWUgc3NoZFs1MDQ5XTogZXJyb3I6IFBBTTogYXV0aGVudGlj YXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAyMDEuMjMwLjE1NS42Ck9jdCAgMyAwMDo1ODow NiBob3N0bmFtZSBzc2hkWzUwMjhdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJv ciBmb3Igcm9vdCBmcm9tIDIwMS4yMzAuMTU1LjYKT2N0ICAzIDAwOjU4OjA2IGhvc3RuYW1l IHNzaGRbNTA1Ml06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290 IGZyb20gMjAxLjIzMC4xNTUuNgpPY3QgIDMgMDA6NTg6MDcgaG9zdG5hbWUgc3NoZFs1MDUy XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAyMDEu MjMwLjE1NS42Ck9jdCAgMyAwMDo1ODowNyBob3N0bmFtZSBzc2hkWzUwNDldOiBlcnJvcjog UEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDIwMS4yMzAuMTU1LjYK T2N0ICAzIDAwOjU4OjA3IGhvc3RuYW1lIHNzaGRbNTA1Ml06IGVycm9yOiBQQU06IGF1dGhl bnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMjAxLjIzMC4xNTUuNgpPY3QgIDMgMDA6 NTg6MDcgaG9zdG5hbWUgc3NoZFs1MDQ5XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24g ZXJyb3IgZm9yIHJvb3QgZnJvbSAyMDEuMjMwLjE1NS42Ck9jdCAgMyAwMDo1ODowOCBob3N0 bmFtZSBzc2hkWzUwNDldOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Ig cm9vdCBmcm9tIDIwMS4yMzAuMTU1LjYKT2N0ICAzIDAwOjU4OjA4IGhvc3RuYW1lIHNzaGRb NTA0OV06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20g MjAxLjIzMC4xNTUuNgpPY3QgIDMgMDA6NTg6MDkgaG9zdG5hbWUgc3NoZFs1MDU4XTogZXJy b3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAyMDEuMjMwLjE1 NS42Ck9jdCAgMyAwMDo1ODowOSBob3N0bmFtZSBzc2hkWzUwNDldOiBlcnJvcjogUEFNOiBh dXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDIwMS4yMzAuMTU1LjYKT2N0ICAz IDAwOjU4OjA5IGhvc3RuYW1lIHNzaGRbNTA1OF06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0 aW9uIGVycm9yIGZvciByb290IGZyb20gMjAxLjIzMC4xNTUuNgpPY3QgIDMgMDA6NTg6MTAg aG9zdG5hbWUgc3NoZFs1MDU4XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3Ig Zm9yIHJvb3QgZnJvbSAyMDEuMjMwLjE1NS42Ck9jdCAgMyAwMDo1ODoxMCBob3N0bmFtZSBz c2hkWzUwNThdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBm cm9tIDIwMS4yMzAuMTU1LjYKT2N0ICAzIDAwOjU4OjExIGhvc3RuYW1lIHNzaGRbNTA1OF06 IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMjAxLjIz MC4xNTUuNgpPY3QgIDMgMDA6NTg6MTEgaG9zdG5hbWUgc3NoZFs1MDU4XTogZXJyb3I6IFBB TTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAyMDEuMjMwLjE1NS42Ck9j dCAgMyAwMTowMDowMSBob3N0bmFtZSBzc2hkWzUxMjBdOiBlcnJvcjogc3NoX21zZ19zZW5k OiB3cml0ZQpPY3QgIDMgMDE6MDA6MDEgaG9zdG5hbWUgc3NoZFs1MTIzXTogZXJyb3I6IHNz aF9tc2dfc2VuZDogd3JpdGUKT2N0ICAzIDAxOjEyOjAxIGhvc3RuYW1lIHNlbmRtYWlsWzU2 OThdOiBOT1FVRVVFOiBTWVNFUlIocm9vdCk6IGNhbiBub3QgY2hkaXIoL3Zhci9zcG9vbC9j bGllbnRtcXVldWUvKTogUGVybWlzc2lvbiBkZW5pZWQKT2N0ICAzIDAxOjI5OjM4IGhvc3Ru YW1lIHNzaGRbNjA2OF06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciBy b290IGZyb20gMjAxLjIzMC4xNTUuNgpPY3QgIDMgMDE6Mjk6MzkgaG9zdG5hbWUgc3NoZFs2 MDY4XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAy MDEuMjMwLjE1NS42Ck9jdCAgMyAwMToyOTo0MCBob3N0bmFtZSBzc2hkWzYwNjhdOiBlcnJv cjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDIwMS4yMzAuMTU1 LjYKT2N0ICAzIDAxOjI5OjQwIGhvc3RuYW1lIHNzaGRbNjA2OF06IGVycm9yOiBQQU06IGF1 dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMjAxLjIzMC4xNTUuNgpPY3QgIDMg MDE6Mjk6NDEgaG9zdG5hbWUgc3NoZFs2MDY4XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRp b24gZXJyb3IgZm9yIHJvb3QgZnJvbSAyMDEuMjMwLjE1NS42Ck9jdCAgMyAwMToyOTo0MiBo b3N0bmFtZSBzc2hkWzYwNjhdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBm b3Igcm9vdCBmcm9tIDIwMS4yMzAuMTU1LjYKT2N0ICAzIDAyOjA2OjAxIGhvc3RuYW1lIHNl bmRtYWlsWzY4NzddOiBOT1FVRVVFOiBTWVNFUlIocm9vdCk6IGNhbiBub3QgY2hkaXIoL3Zh ci9zcG9vbC9jbGllbnRtcXVldWUvKTogUGVybWlzc2lvbiBkZW5pZWQKT2N0ICAzIDAzOjAx OjAxIGhvc3RuYW1lIHNlbmRtYWlsWzgxNzRdOiBOT1FVRVVFOiBTWVNFUlIocm9vdCk6IGNh biBub3QgY2hkaXIoL3Zhci9zcG9vbC9jbGllbnRtcXVldWUvKTogUGVybWlzc2lvbiBkZW5p ZWQKT2N0ICAzIDAzOjAxOjA5IGhvc3RuYW1lIHNlbmRtYWlsWzg1NDFdOiBOT1FVRVVFOiBT WVNFUlIocm9vdCk6IGNhbiBub3QgY2hkaXIoL3Zhci9zcG9vbC9jbGllbnRtcXVldWUvKTog UGVybWlzc2lvbiBkZW5pZWQKT2N0ICAzIDAzOjAxOjA5IGhvc3RuYW1lIHNlbmRtYWlsWzg1 ODldOiBOT1FVRVVFOiBTWVNFUlIocm9vdCk6IGNhbiBub3QgY2hkaXIoL3Zhci9zcG9vbC9j bGllbnRtcXVldWUvKTogUGVybWlzc2lvbiBkZW5pZWQKT2N0ICAzIDAzOjAxOjA5IGhvc3Ru YW1lIHNlbmRtYWlsWzg1OTldOiBOT1FVRVVFOiBTWVNFUlIocm9vdCk6IGNhbiBub3QgY2hk aXIoL3Zhci9zcG9vbC9jbGllbnRtcXVldWUvKTogUGVybWlzc2lvbiBkZW5pZWQKT2N0ICAz IDAzOjAxOjA5IGhvc3RuYW1lIHNlbmRtYWlsWzg2MDFdOiBOT1FVRVVFOiBTWVNFUlIocm9v dCk6IGNhbiBub3QgY2hkaXIoL3Zhci9zcG9vbC9jbGllbnRtcXVldWUvKTogUGVybWlzc2lv biBkZW5pZWQKT2N0ICAzIDAzOjQ0OjAwIGhvc3RuYW1lIHNlbmRtYWlsWzk2MTZdOiBOT1FV RVVFOiBTWVNFUlIocm9vdCk6IGNhbiBub3QgY2hkaXIoL3Zhci9zcG9vbC9jbGllbnRtcXVl dWUvKTogUGVybWlzc2lvbiBkZW5pZWQKT2N0ICAzIDA0OjI4OjAwIGhvc3RuYW1lIHNlbmRt YWlsWzEwNTY4XTogTk9RVUVVRTogU1lTRVJSKHJvb3QpOiBjYW4gbm90IGNoZGlyKC92YXIv c3Bvb2wvY2xpZW50bXF1ZXVlLyk6IFBlcm1pc3Npb24gZGVuaWVkCk9jdCAgMyAwNDoyODow OCBob3N0bmFtZSBzdTogdXNlciB0byByb290IG9uIC9kZXYvcHRzLzEKT2N0ICAzIDA1OjIz OjAwIGhvc3RuYW1lIHNlbmRtYWlsWzExNzg5XTogTk9RVUVVRTogU1lTRVJSKHJvb3QpOiBj YW4gbm90IGNoZGlyKC92YXIvc3Bvb2wvY2xpZW50bXF1ZXVlLyk6IFBlcm1pc3Npb24gZGVu aWVkCk9jdCAgMyAwNjowMTo0MyBob3N0bmFtZSBzc2hkWzEyNTczXTogZXJyb3I6IHNzaF9t c2dfc2VuZDogd3JpdGUKT2N0ICAzIDA2OjIzOjAwIGhvc3RuYW1lIHNlbmRtYWlsWzEzMTEx XTogTk9RVUVVRTogU1lTRVJSKHJvb3QpOiBjYW4gbm90IGNoZGlyKC92YXIvc3Bvb2wvY2xp ZW50bXF1ZXVlLyk6IFBlcm1pc3Npb24gZGVuaWVkCk9jdCAgMyAwNjo0ODozNSBob3N0bmFt ZSBzZW5kbWFpbFsxMzk0MF06IE5PUVVFVUU6IFNZU0VSUihyb290KTogY2FuIG5vdCBjaGRp cigvdmFyL3Nwb29sL2NsaWVudG1xdWV1ZS8pOiBQZXJtaXNzaW9uIGRlbmllZApPY3QgIDMg MDc6MTQ6MDEgaG9zdG5hbWUgc2VuZG1haWxbMTQ1ODhdOiBOT1FVRVVFOiBTWVNFUlIocm9v dCk6IGNhbiBub3QgY2hkaXIoL3Zhci9zcG9vbC9jbGllbnRtcXVldWUvKTogUGVybWlzc2lv biBkZW5pZWQKT2N0ICAzIDA3OjU3OjAwIGhvc3RuYW1lIHNlbmRtYWlsWzE1NTE1XTogTk9R VUVVRTogU1lTRVJSKHJvb3QpOiBjYW4gbm90IGNoZGlyKC92YXIvc3Bvb2wvY2xpZW50bXF1 ZXVlLyk6IFBlcm1pc3Npb24gZGVuaWVkCk9jdCAgMyAwODoxMTowMSBob3N0bmFtZSBzZW5k bWFpbFsxNTgzM106IE5PUVVFVUU6IFNZU0VSUihyb290KTogY2FuIG5vdCBjaGRpcigvdmFy L3Nwb29sL2NsaWVudG1xdWV1ZS8pOiBQZXJtaXNzaW9uIGRlbmllZApPY3QgIDMgMDg6NDM6 MDEgaG9zdG5hbWUgc2VuZG1haWxbMTY1MjhdOiBOT1FVRVVFOiBTWVNFUlIocm9vdCk6IGNh biBub3QgY2hkaXIoL3Zhci9zcG9vbC9jbGllbnRtcXVldWUvKTogUGVybWlzc2lvbiBkZW5p ZWQKT2N0ICAzIDA4OjUyOjU3IGhvc3RuYW1lIHN1OiB1c2VyIHRvIHJvb3Qgb24gL2Rldi9w dHMvMQpPY3QgIDMgMDg6NTY6MDAgaG9zdG5hbWUgc2VuZG1haWxbMTY4MzddOiBOT1FVRVVF OiBTWVNFUlIocm9vdCk6IGNhbiBub3QgY2hkaXIoL3Zhci9zcG9vbC9jbGllbnRtcXVldWUv KTogUGVybWlzc2lvbiBkZW5pZWQKT2N0ICAzIDA5OjA5OjAyIGhvc3RuYW1lIHNzaGRbMTcx MjhdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3IgdXNlciBmcm9tIGh4 eHh4eGIyMy5jbGkuZG9tYWluLnRsZApPY3QgIDMgMDk6MDk6MDMgaG9zdG5hbWUgc3NoZFsx NzEyOF06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciB1c2VyIGZyb20g aHh4eHh4YjIzLmNsaS5kb21haW4udGxkCk9jdCAgMyAwOTowOTowNCBob3N0bmFtZSBzc2hk WzE3MTI4XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHVzZXIgZnJv bSBoeHh4eHhiMjMuY2xpLmRvbWFpbi50bGQKT2N0ICAzIDEwOjU3OjAxIGhvc3RuYW1lIHNl bmRtYWlsWzE5NjAzXTogTk9RVUVVRTogU1lTRVJSKHJvb3QpOiBjYW4gbm90IGNoZGlyKC92 YXIvc3Bvb2wvY2xpZW50bXF1ZXVlLyk6IFBlcm1pc3Npb24gZGVuaWVkCk9jdCAgMyAxMTow MDowMCBob3N0bmFtZSBzZW5kbWFpbFsxOTY4M106IE5PUVVFVUU6IFNZU0VSUihyb290KTog Y2FuIG5vdCBjaGRpcigvdmFyL3Nwb29sL2NsaWVudG1xdWV1ZS8pOiBQZXJtaXNzaW9uIGRl bmllZApPY3QgIDMgMTE6MzM6MDAgaG9zdG5hbWUgc2VuZG1haWxbMjA0MDddOiBOT1FVRVVF OiBTWVNFUlIocm9vdCk6IGNhbiBub3QgY2hkaXIoL3Zhci9zcG9vbC9jbGllbnRtcXVldWUv KTogUGVybWlzc2lvbiBkZW5pZWQKT2N0ICAzIDEyOjA5OjAwIGhvc3RuYW1lIHNlbmRtYWls WzIxMTgxXTogTk9RVUVVRTogU1lTRVJSKHJvb3QpOiBjYW4gbm90IGNoZGlyKC92YXIvc3Bv b2wvY2xpZW50bXF1ZXVlLyk6IFBlcm1pc3Npb24gZGVuaWVkCk9jdCAgMyAxMjoxNDowMCBo b3N0bmFtZSBzZW5kbWFpbFsyMTI5NF06IE5PUVVFVUU6IFNZU0VSUihyb290KTogY2FuIG5v dCBjaGRpcigvdmFyL3Nwb29sL2NsaWVudG1xdWV1ZS8pOiBQZXJtaXNzaW9uIGRlbmllZApP Y3QgIDMgMTI6MzQ6MDEgaG9zdG5hbWUgc2VuZG1haWxbMjE3NTldOiBOT1FVRVVFOiBTWVNF UlIocm9vdCk6IGNhbiBub3QgY2hkaXIoL3Zhci9zcG9vbC9jbGllbnRtcXVldWUvKTogUGVy bWlzc2lvbiBkZW5pZWQKT2N0ICAzIDEyOjM5OjAxIGhvc3RuYW1lIHNlbmRtYWlsWzIxODY0 XTogTk9RVUVVRTogU1lTRVJSKHJvb3QpOiBjYW4gbm90IGNoZGlyKC92YXIvc3Bvb2wvY2xp ZW50bXF1ZXVlLyk6IFBlcm1pc3Npb24gZGVuaWVkCk9jdCAgMyAxMjo0OTo0NSBob3N0bmFt ZSBzZW5kbWFpbFsyMjU2NV06IE5PUVVFVUU6IFNZU0VSUihyb290KTogY2FuIG5vdCBjaGRp cigvdmFyL3Nwb29sL2NsaWVudG1xdWV1ZS8pOiBQZXJtaXNzaW9uIGRlbmllZApPY3QgIDMg MTM6MjY6MDEgaG9zdG5hbWUgc2VuZG1haWxbMjM1NDRdOiBOT1FVRVVFOiBTWVNFUlIocm9v dCk6IGNhbiBub3QgY2hkaXIoL3Zhci9zcG9vbC9jbGllbnRtcXVldWUvKTogUGVybWlzc2lv biBkZW5pZWQKT2N0ICAzIDEzOjMxOjAwIGhvc3RuYW1lIHNlbmRtYWlsWzIzNjQ3XTogTk9R VUVVRTogU1lTRVJSKHJvb3QpOiBjYW4gbm90IGNoZGlyKC92YXIvc3Bvb2wvY2xpZW50bXF1 ZXVlLyk6IFBlcm1pc3Npb24gZGVuaWVkCk9jdCAgMyAxMzo0NjowMCBob3N0bmFtZSBzZW5k bWFpbFsyNDE4MF06IE5PUVVFVUU6IFNZU0VSUihyb290KTogY2FuIG5vdCBjaGRpcigvdmFy L3Nwb29sL2NsaWVudG1xdWV1ZS8pOiBQZXJtaXNzaW9uIGRlbmllZApPY3QgIDMgMTQ6MDk6 MDAgaG9zdG5hbWUgc2VuZG1haWxbMjQ3MTBdOiBOT1FVRVVFOiBTWVNFUlIocm9vdCk6IGNh biBub3QgY2hkaXIoL3Zhci9zcG9vbC9jbGllbnRtcXVldWUvKTogUGVybWlzc2lvbiBkZW5p ZWQKT2N0ICAzIDE0OjEyOjAxIGhvc3RuYW1lIHNlbmRtYWlsWzI0Nzg0XTogTk9RVUVVRTog U1lTRVJSKHJvb3QpOiBjYW4gbm90IGNoZGlyKC92YXIvc3Bvb2wvY2xpZW50bXF1ZXVlLyk6 IFBlcm1pc3Npb24gZGVuaWVkCk9jdCAgMyAxNDoxODowMSBob3N0bmFtZSBzZW5kbWFpbFsy NDkxMV06IE5PUVVFVUU6IFNZU0VSUihyb290KTogY2FuIG5vdCBjaGRpcigvdmFyL3Nwb29s L2NsaWVudG1xdWV1ZS8pOiBQZXJtaXNzaW9uIGRlbmllZApPY3QgIDMgMTQ6MjY6MDEgaG9z dG5hbWUgc2VuZG1haWxbMjUwODhdOiBOT1FVRVVFOiBTWVNFUlIocm9vdCk6IGNhbiBub3Qg Y2hkaXIoL3Zhci9zcG9vbC9jbGllbnRtcXVldWUvKTogUGVybWlzc2lvbiBkZW5pZWQKT2N0 ICAzIDE0OjI5OjAwIGhvc3RuYW1lIHNlbmRtYWlsWzI1MTUxXTogTk9RVUVVRTogU1lTRVJS KHJvb3QpOiBjYW4gbm90IGNoZGlyKC92YXIvc3Bvb2wvY2xpZW50bXF1ZXVlLyk6IFBlcm1p c3Npb24gZGVuaWVkCk9jdCAgMyAxNDo0NDowMCBob3N0bmFtZSBzZW5kbWFpbFsyNTQ4Ml06 IE5PUVVFVUU6IFNZU0VSUihyb290KTogY2FuIG5vdCBjaGRpcigvdmFyL3Nwb29sL2NsaWVu dG1xdWV1ZS8pOiBQZXJtaXNzaW9uIGRlbmllZApPY3QgIDMgMTQ6NTU6MDEgaG9zdG5hbWUg c2VuZG1haWxbMjU3MTldOiBOT1FVRVVFOiBTWVNFUlIocm9vdCk6IGNhbiBub3QgY2hkaXIo L3Zhci9zcG9vbC9jbGllbnRtcXVldWUvKTogUGVybWlzc2lvbiBkZW5pZWQKT2N0ICAzIDE1 OjAyOjAwIGhvc3RuYW1lIHNlbmRtYWlsWzI1ODc4XTogTk9RVUVVRTogU1lTRVJSKHJvb3Qp OiBjYW4gbm90IGNoZGlyKC92YXIvc3Bvb2wvY2xpZW50bXF1ZXVlLyk6IFBlcm1pc3Npb24g ZGVuaWVkCk9jdCAgMyAxNTowODowMCBob3N0bmFtZSBzZW5kbWFpbFsyNjAwMl06IE5PUVVF VUU6IFNZU0VSUihyb290KTogY2FuIG5vdCBjaGRpcigvdmFyL3Nwb29sL2NsaWVudG1xdWV1 ZS8pOiBQZXJtaXNzaW9uIGRlbmllZApPY3QgIDMgMTU6MzM6MDAgaG9zdG5hbWUgc2VuZG1h aWxbMjY1NTFdOiBOT1FVRVVFOiBTWVNFUlIocm9vdCk6IGNhbiBub3QgY2hkaXIoL3Zhci9z cG9vbC9jbGllbnRtcXVldWUvKTogUGVybWlzc2lvbiBkZW5pZWQKT2N0ICAzIDE1OjM0OjAx IGhvc3RuYW1lIHNlbmRtYWlsWzI2NTcyXTogTk9RVUVVRTogU1lTRVJSKHJvb3QpOiBjYW4g bm90IGNoZGlyKC92YXIvc3Bvb2wvY2xpZW50bXF1ZXVlLyk6IFBlcm1pc3Npb24gZGVuaWVk Ck9jdCAgMyAxNTo0NDowMCBob3N0bmFtZSBzZW5kbWFpbFsyNjc4N106IE5PUVVFVUU6IFNZ U0VSUihyb290KTogY2FuIG5vdCBjaGRpcigvdmFyL3Nwb29sL2NsaWVudG1xdWV1ZS8pOiBQ ZXJtaXNzaW9uIGRlbmllZApPY3QgIDMgMTY6MjU6MDEgaG9zdG5hbWUgc2VuZG1haWxbMjgz MTddOiBOT1FVRVVFOiBTWVNFUlIocm9vdCk6IGNhbiBub3QgY2hkaXIoL3Zhci9zcG9vbC9j bGllbnRtcXVldWUvKTogUGVybWlzc2lvbiBkZW5pZWQKT2N0ICAzIDE2OjI2OjAwIGhvc3Ru YW1lIHNlbmRtYWlsWzI4NDE3XTogTk9RVUVVRTogU1lTRVJSKHJvb3QpOiBjYW4gbm90IGNo ZGlyKC92YXIvc3Bvb2wvY2xpZW50bXF1ZXVlLyk6IFBlcm1pc3Npb24gZGVuaWVkCk9jdCAg MyAxNjozNzowMCBob3N0bmFtZSBzZW5kbWFpbFsyOTA4NV06IE5PUVVFVUU6IFNZU0VSUihy b290KTogY2FuIG5vdCBjaGRpcigvdmFyL3Nwb29sL2NsaWVudG1xdWV1ZS8pOiBQZXJtaXNz aW9uIGRlbmllZApPY3QgIDMgMTY6Mzk6MDEgaG9zdG5hbWUgc2VuZG1haWxbMjkxMjRdOiBO T1FVRVVFOiBTWVNFUlIocm9vdCk6IGNhbiBub3QgY2hkaXIoL3Zhci9zcG9vbC9jbGllbnRt cXVldWUvKTogUGVybWlzc2lvbiBkZW5pZWQKT2N0ICAzIDE2OjQ2OjAxIGhvc3RuYW1lIHNl bmRtYWlsWzI5NTAzXTogTk9RVUVVRTogU1lTRVJSKHJvb3QpOiBjYW4gbm90IGNoZGlyKC92 YXIvc3Bvb2wvY2xpZW50bXF1ZXVlLyk6IFBlcm1pc3Npb24gZGVuaWVkCk9jdCAgMyAxNjo1 ODowMSBob3N0bmFtZSBzZW5kbWFpbFszMDUwN106IE5PUVVFVUU6IFNZU0VSUihyb290KTog Y2FuIG5vdCBjaGRpcigvdmFyL3Nwb29sL2NsaWVudG1xdWV1ZS8pOiBQZXJtaXNzaW9uIGRl bmllZApPY3QgIDMgMTc6MDg6MDAgaG9zdG5hbWUgc2VuZG1haWxbMzE3NDFdOiBOT1FVRVVF OiBTWVNFUlIocm9vdCk6IGNhbiBub3QgY2hkaXIoL3Zhci9zcG9vbC9jbGllbnRtcXVldWUv KTogUGVybWlzc2lvbiBkZW5pZWQKT2N0ICAzIDE3OjE3OjAxIGhvc3RuYW1lIHNlbmRtYWls WzMyMjMyXTogTk9RVUVVRTogU1lTRVJSKHJvb3QpOiBjYW4gbm90IGNoZGlyKC92YXIvc3Bv b2wvY2xpZW50bXF1ZXVlLyk6IFBlcm1pc3Npb24gZGVuaWVkCk9jdCAgMyAxNzoyMDowMCBo b3N0bmFtZSBzZW5kbWFpbFszMjM3Ml06IE5PUVVFVUU6IFNZU0VSUihyb290KTogY2FuIG5v dCBjaGRpcigvdmFyL3Nwb29sL2NsaWVudG1xdWV1ZS8pOiBQZXJtaXNzaW9uIGRlbmllZApP Y3QgIDMgMTc6MzM6MDEgaG9zdG5hbWUgc2VuZG1haWxbMzMxMjFdOiBOT1FVRVVFOiBTWVNF UlIocm9vdCk6IGNhbiBub3QgY2hkaXIoL3Zhci9zcG9vbC9jbGllbnRtcXVldWUvKTogUGVy bWlzc2lvbiBkZW5pZWQKT2N0ICAzIDE3OjQ4OjAwIGhvc3RuYW1lIHNlbmRtYWlsWzMzOTMw XTogTk9RVUVVRTogU1lTRVJSKHJvb3QpOiBjYW4gbm90IGNoZGlyKC92YXIvc3Bvb2wvY2xp ZW50bXF1ZXVlLyk6IFBlcm1pc3Npb24gZGVuaWVkCk9jdCAgMyAxNzo1MDowMCBob3N0bmFt ZSBzZW5kbWFpbFszMzk3Nl06IE5PUVVFVUU6IFNZU0VSUihyb290KTogY2FuIG5vdCBjaGRp cigvdmFyL3Nwb29sL2NsaWVudG1xdWV1ZS8pOiBQZXJtaXNzaW9uIGRlbmllZApPY3QgIDMg MTc6NTQ6MDAgaG9zdG5hbWUgc2VuZG1haWxbMzQyMTddOiBOT1FVRVVFOiBTWVNFUlIocm9v dCk6IGNhbiBub3QgY2hkaXIoL3Zhci9zcG9vbC9jbGllbnRtcXVldWUvKTogUGVybWlzc2lv biBkZW5pZWQKT2N0ICAzIDE4OjMwOjExIGhvc3RuYW1lIHNzaGRbMzU3NjddOiBlcnJvcjog UEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC40MC4xMDQuMjA2 Ck9jdCAgMyAxODozMDoxMSBob3N0bmFtZSBzc2hkWzM1NzY2XTogZXJyb3I6IFBBTTogYXV0 aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuNDAuMTA0LjIwNgpPY3QgIDMg MTg6MzA6MTEgaG9zdG5hbWUgc3NoZFszNTc2OF06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0 aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjQwLjEwNC4yMDYKT2N0ICAzIDE4OjMwOjEy IGhvc3RuYW1lIHNzaGRbMzU3NjhdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJv ciBmb3Igcm9vdCBmcm9tIDE5MC40MC4xMDQuMjA2Ck9jdCAgMyAxODozMDoxMiBob3N0bmFt ZSBzc2hkWzM1NzY3XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJv b3QgZnJvbSAxOTAuNDAuMTA0LjIwNgpPY3QgIDMgMTg6MzA6MTMgaG9zdG5hbWUgc3NoZFsz NTc2OF06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20g MTkwLjQwLjEwNC4yMDYKT2N0ICAzIDE4OjMwOjEzIGhvc3RuYW1lIHNzaGRbMzU3NjhdOiBl cnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC40MC4x MDQuMjA2Ck9jdCAgMyAxODozMDoxMyBob3N0bmFtZSBzc2hkWzM1NzY3XTogZXJyb3I6IFBB TTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuNDAuMTA0LjIwNgpP Y3QgIDMgMTg6MzA6MTQgaG9zdG5hbWUgc3NoZFszNTc2OF06IGVycm9yOiBQQU06IGF1dGhl bnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjQwLjEwNC4yMDYKT2N0ICAzIDE4 OjMwOjE1IGhvc3RuYW1lIHNzaGRbMzU3NjhdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlv biBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC40MC4xMDQuMjA2Ck9jdCAgMyAxODozMDoxNSBo b3N0bmFtZSBzc2hkWzM1NzY2XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3Ig Zm9yIHJvb3QgZnJvbSAxOTAuNDAuMTA0LjIwNgpPY3QgIDMgMTg6MzA6MTcgaG9zdG5hbWUg c3NoZFszNTc2N106IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290 IGZyb20gMTkwLjQwLjEwNC4yMDYKT2N0ICAzIDE4OjMwOjE3IGhvc3RuYW1lIHNzaGRbMzU3 NjZdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5 MC40MC4xMDQuMjA2Ck9jdCAgMyAxODozMDoxOCBob3N0bmFtZSBzc2hkWzM1NzY3XTogZXJy b3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuNDAuMTA0 LjIwNgpPY3QgIDMgMTg6MzA6MTggaG9zdG5hbWUgc3NoZFszNTc2Nl06IGVycm9yOiBQQU06 IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjQwLjEwNC4yMDYKT2N0 ICAzIDE4OjMwOjE4IGhvc3RuYW1lIHNzaGRbMzU3NjddOiBlcnJvcjogUEFNOiBhdXRoZW50 aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC40MC4xMDQuMjA2Ck9jdCAgMyAxODoz MDoxOCBob3N0bmFtZSBzc2hkWzM1NzY2XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24g ZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuNDAuMTA0LjIwNgpPY3QgIDMgMTg6MzA6MTkgaG9z dG5hbWUgc3NoZFszNTc2Nl06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZv ciByb290IGZyb20gMTkwLjQwLjEwNC4yMDYKT2N0ICAzIDE4OjMwOjM2IGhvc3RuYW1lIHNz aGRbMzU4MTNdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBm cm9tIDE5MC40MC4xMDQuMjA2Ck9jdCAgMyAxODozMDozNyBob3N0bmFtZSBzc2hkWzM1ODEz XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAu NDAuMTA0LjIwNgpPY3QgIDMgMTg6MzA6MzggaG9zdG5hbWUgc3NoZFszNTgxM106IGVycm9y OiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjQwLjEwNC4y MDYKT2N0ICAzIDE4OjMwOjM5IGhvc3RuYW1lIHNzaGRbMzU4MTNdOiBlcnJvcjogUEFNOiBh dXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC40MC4xMDQuMjA2Ck9jdCAg MyAxODozMDozOSBob3N0bmFtZSBzc2hkWzM1ODEyXTogZXJyb3I6IFBBTTogYXV0aGVudGlj YXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuNDAuMTA0LjIwNgpPY3QgIDMgMTg6MzA6 MzkgaG9zdG5hbWUgc3NoZFszNTgxM106IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVy cm9yIGZvciByb290IGZyb20gMTkwLjQwLjEwNC4yMDYKT2N0ICAzIDE4OjMwOjQwIGhvc3Ru YW1lIHNzaGRbMzU4MTNdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Ig cm9vdCBmcm9tIDE5MC40MC4xMDQuMjA2Ck9jdCAgMyAxODozMDo0MCBob3N0bmFtZSBzc2hk WzM1ODE1XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJv bSAxOTAuNDAuMTA0LjIwNgpPY3QgIDMgMTg6MzA6NDAgaG9zdG5hbWUgc3NoZFszNTgxNl06 IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjQw LjEwNC4yMDYKT2N0ICAzIDE4OjMwOjQwIGhvc3RuYW1lIHNzaGRbMzU4MTJdOiBlcnJvcjog UEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC40MC4xMDQuMjA2 Ck9jdCAgMyAxODozMDo0MCBob3N0bmFtZSBzc2hkWzM1ODE1XTogZXJyb3I6IFBBTTogYXV0 aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuNDAuMTA0LjIwNgpPY3QgIDMg MTg6MzA6NDEgaG9zdG5hbWUgc3NoZFszNTgxMl06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0 aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjQwLjEwNC4yMDYKT2N0ICAzIDE4OjMwOjQx IGhvc3RuYW1lIHNzaGRbMzU4MTZdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJv ciBmb3Igcm9vdCBmcm9tIDE5MC40MC4xMDQuMjA2Ck9jdCAgMyAxODozMDo0MSBob3N0bmFt ZSBzc2hkWzM1ODE1XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJv b3QgZnJvbSAxOTAuNDAuMTA0LjIwNgpPY3QgIDMgMTg6MzA6NDEgaG9zdG5hbWUgc3NoZFsz NTgxNl06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20g MTkwLjQwLjEwNC4yMDYKT2N0ICAzIDE4OjMwOjQxIGhvc3RuYW1lIHNzaGRbMzU4MTJdOiBl cnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC40MC4x MDQuMjA2Ck9jdCAgMyAxODozMDo0MSBob3N0bmFtZSBzc2hkWzM1ODE1XTogZXJyb3I6IFBB TTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuNDAuMTA0LjIwNgpP Y3QgIDMgMTg6MzA6NDIgaG9zdG5hbWUgc3NoZFszNTgxNl06IGVycm9yOiBQQU06IGF1dGhl bnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjQwLjEwNC4yMDYKT2N0ICAzIDE4 OjMwOjQyIGhvc3RuYW1lIHNzaGRbMzU4MTJdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlv biBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC40MC4xMDQuMjA2Ck9jdCAgMyAxODozMDo0MiBo b3N0bmFtZSBzc2hkWzM1ODE1XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3Ig Zm9yIHJvb3QgZnJvbSAxOTAuNDAuMTA0LjIwNgpPY3QgIDMgMTg6MzA6NDIgaG9zdG5hbWUg c3NoZFszNTgxNl06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290 IGZyb20gMTkwLjQwLjEwNC4yMDYKT2N0ICAzIDE4OjMwOjQyIGhvc3RuYW1lIHNzaGRbMzU4 MTJdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5 MC40MC4xMDQuMjA2Ck9jdCAgMyAxODozMDo0MiBob3N0bmFtZSBzc2hkWzM1ODE1XTogZXJy b3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuNDAuMTA0 LjIwNgpPY3QgIDMgMTg6MzA6NDMgaG9zdG5hbWUgc3NoZFszNTgxNl06IGVycm9yOiBQQU06 IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjQwLjEwNC4yMDYKT2N0 ICAzIDE4OjMxOjA4IGhvc3RuYW1lIHNzaGRbMzU4NTddOiBlcnJvcjogUEFNOiBhdXRoZW50 aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC40MC4xMDQuMjA2Ck9jdCAgMyAxODoz MToxMCBob3N0bmFtZSBzc2hkWzM1ODU3XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24g ZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuNDAuMTA0LjIwNgpPY3QgIDMgMTg6MzE6MTAgaG9z dG5hbWUgc3NoZFszNTg1N106IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZv ciByb290IGZyb20gMTkwLjQwLjEwNC4yMDYKT2N0ICAzIDE4OjMxOjExIGhvc3RuYW1lIHNz aGRbMzU4NTddOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBm cm9tIDE5MC40MC4xMDQuMjA2Ck9jdCAgMyAxODozMToxMiBob3N0bmFtZSBzc2hkWzM1ODU3 XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAu NDAuMTA0LjIwNgpPY3QgIDMgMTg6MzE6MTIgaG9zdG5hbWUgc3NoZFszNTg1N106IGVycm9y OiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjQwLjEwNC4y MDYKT2N0ICAzIDE4OjMxOjIwIGhvc3RuYW1lIHNzaGRbMzU4NTldOiBlcnJvcjogUEFNOiBh dXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC40MC4xMDQuMjA2Ck9jdCAg MyAxODozMToyMCBob3N0bmFtZSBzc2hkWzM1ODYyXTogZXJyb3I6IFBBTTogYXV0aGVudGlj YXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuNDAuMTA0LjIwNgpPY3QgIDMgMTg6MzE6 MjAgaG9zdG5hbWUgc3NoZFszNTg2MV06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVy cm9yIGZvciByb290IGZyb20gMTkwLjQwLjEwNC4yMDYKT2N0ICAzIDE4OjMxOjIxIGhvc3Ru YW1lIHNzaGRbMzU4NTldOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Ig cm9vdCBmcm9tIDE5MC40MC4xMDQuMjA2Ck9jdCAgMyAxODozMToyMSBob3N0bmFtZSBzc2hk WzM1ODYyXTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJv bSAxOTAuNDAuMTA0LjIwNgpPY3QgIDMgMTg6MzE6MjEgaG9zdG5hbWUgc3NoZFszNTg2MV06 IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjQw LjEwNC4yMDYKT2N0ICAzIDE4OjMxOjIxIGhvc3RuYW1lIHNzaGRbMzU4NjJdOiBlcnJvcjog UEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC40MC4xMDQuMjA2 Ck9jdCAgMyAxODozMToyMSBob3N0bmFtZSBzc2hkWzM1ODU5XTogZXJyb3I6IFBBTTogYXV0 aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuNDAuMTA0LjIwNgpPY3QgIDMg MTg6MzE6MjIgaG9zdG5hbWUgc3NoZFszNTg1OV06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0 aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjQwLjEwNC4yMDYKT2N0ICAzIDE4OjMxOjIy IGhvc3RuYW1lIHNzaGRbMzU4NjJdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJv ciBmb3Igcm9vdCBmcm9tIDE5MC40MC4xMDQuMjA2Ck9jdCAgMyAxODozMToyMiBob3N0bmFt ZSBzc2hkWzM1ODYxXTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJv b3QgZnJvbSAxOTAuNDAuMTA0LjIwNgpPY3QgIDMgMTg6MzE6MjMgaG9zdG5hbWUgc3NoZFsz NTg2MV06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20g MTkwLjQwLjEwNC4yMDYKT2N0ICAzIDE4OjMxOjIzIGhvc3RuYW1lIHNzaGRbMzU4NjFdOiBl cnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC40MC4x MDQuMjA2Ck9jdCAgMyAxODozMToyMyBob3N0bmFtZSBzc2hkWzM1ODYyXTogZXJyb3I6IFBB TTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuNDAuMTA0LjIwNgpP Y3QgIDMgMTg6MzE6MjQgaG9zdG5hbWUgc3NoZFszNTg2MV06IGVycm9yOiBQQU06IGF1dGhl bnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjQwLjEwNC4yMDYKT2N0ICAzIDE4 OjMxOjI1IGhvc3RuYW1lIHNzaGRbMzU4NTldOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlv biBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC40MC4xMDQuMjA2Ck9jdCAgMyAxODozMToyNSBo b3N0bmFtZSBzc2hkWzM1ODYyXTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3Ig Zm9yIHJvb3QgZnJvbSAxOTAuNDAuMTA0LjIwNgpPY3QgIDMgMTg6MzE6MjYgaG9zdG5hbWUg c3NoZFszNTg1OV06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290 IGZyb20gMTkwLjQwLjEwNC4yMDYKT2N0ICAzIDE4OjMxOjMyIGhvc3RuYW1lIHNzaGRbMzU5 NDJdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5 MC40MC4xMDQuMjA2Ck9jdCAgMyAxODozMTozMiBob3N0bmFtZSBzc2hkWzM1OTQyXTogZXJy b3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuNDAuMTA0 LjIwNgpPY3QgIDMgMTg6MzE6MzMgaG9zdG5hbWUgc3NoZFszNTk0Ml06IGVycm9yOiBQQU06 IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjQwLjEwNC4yMDYKT2N0 ICAzIDE4OjMxOjMzIGhvc3RuYW1lIHNzaGRbMzU5NDJdOiBlcnJvcjogUEFNOiBhdXRoZW50 aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC40MC4xMDQuMjA2Ck9jdCAgMyAxODoz MTozNCBob3N0bmFtZSBzc2hkWzM1OTQyXTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24g ZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuNDAuMTA0LjIwNgpPY3QgIDMgMTg6MzE6MzQgaG9z dG5hbWUgc3NoZFszNTk0Ml06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZv ciByb290IGZyb20gMTkwLjQwLjEwNC4yMDYKT2N0ICAzIDE4OjMxOjU0IGhvc3RuYW1lIHNz aGRbMzU5NDFdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBm cm9tIDE5MC4xMjguMTEwLjY0Ck9jdCAgMyAxODozMTo1NCBob3N0bmFtZSBzc2hkWzM1OTE2 XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAu MTI4LjExMC42NApPY3QgIDMgMTg6MzE6NTQgaG9zdG5hbWUgc3NoZFszNTk0MV06IGVycm9y OiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjEyOC4xMTAu NjQKT2N0ICAzIDE4OjMxOjU0IGhvc3RuYW1lIHNzaGRbMzU5MTZdOiBlcnJvcjogUEFNOiBh dXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC4xMjguMTEwLjY0Ck9jdCAg MyAxODozMTo1NSBob3N0bmFtZSBzc2hkWzM1OTE2XTogZXJyb3I6IFBBTTogYXV0aGVudGlj YXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuMTI4LjExMC42NApPY3QgIDMgMTg6MzE6 NTUgaG9zdG5hbWUgc3NoZFszNTk0MV06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVy cm9yIGZvciByb290IGZyb20gMTkwLjEyOC4xMTAuNjQKT2N0ICAzIDE4OjMxOjU1IGhvc3Ru YW1lIHNzaGRbMzU5MTZdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Ig cm9vdCBmcm9tIDE5MC4xMjguMTEwLjY0Ck9jdCAgMyAxODozMTo1NSBob3N0bmFtZSBzc2hk WzM1OTQxXTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJv bSAxOTAuMTI4LjExMC42NApPY3QgIDMgMTg6MzE6NTUgaG9zdG5hbWUgc3NoZFszNTkxNl06 IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjEy OC4xMTAuNjQKT2N0ICAzIDE4OjMxOjU1IGhvc3RuYW1lIHNzaGRbMzU5NDFdOiBlcnJvcjog UEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC4xMjguMTEwLjY0 Ck9jdCAgMyAxODozMTo1NiBob3N0bmFtZSBzc2hkWzM1OTQxXTogZXJyb3I6IFBBTTogYXV0 aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuMTI4LjExMC42NApPY3QgIDMg MTg6MzE6NTYgaG9zdG5hbWUgc3NoZFszNTkxNl06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0 aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjEyOC4xMTAuNjQKT2N0ICAzIDE4OjMyOjA3 IGhvc3RuYW1lIHNzaGRbMzU5NjRdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJv ciBmb3Igcm9vdCBmcm9tIDE5MC4xMjguMTEwLjY0Ck9jdCAgMyAxODozMjowOCBob3N0bmFt ZSBzc2hkWzM1OTY0XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJv b3QgZnJvbSAxOTAuMTI4LjExMC42NApPY3QgIDMgMTg6MzI6MDggaG9zdG5hbWUgc3NoZFsz NTk2NF06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20g MTkwLjEyOC4xMTAuNjQKT2N0ICAzIDE4OjMyOjA5IGhvc3RuYW1lIHNzaGRbMzU5NjRdOiBl cnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC4xMjgu MTEwLjY0Ck9jdCAgMyAxODozMjowOSBob3N0bmFtZSBzc2hkWzM1OTY0XTogZXJyb3I6IFBB TTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuMTI4LjExMC42NApP Y3QgIDMgMTg6MzI6MTAgaG9zdG5hbWUgc3NoZFszNTk2NF06IGVycm9yOiBQQU06IGF1dGhl bnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjEyOC4xMTAuNjQKT2N0ICAzIDE4 OjMyOjIwIGhvc3RuYW1lIHNzaGRbMzU5ODldOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlv biBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC4xMjguMTEwLjY0Ck9jdCAgMyAxODozMjoyMCBo b3N0bmFtZSBzc2hkWzM1OTg5XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3Ig Zm9yIHJvb3QgZnJvbSAxOTAuMTI4LjExMC42NApPY3QgIDMgMTg6MzI6MjEgaG9zdG5hbWUg c3NoZFszNTk4OV06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290 IGZyb20gMTkwLjEyOC4xMTAuNjQKT2N0ICAzIDE4OjMyOjIxIGhvc3RuYW1lIHNzaGRbMzU5 ODldOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5 MC4xMjguMTEwLjY0Ck9jdCAgMyAxODozMjoyMiBob3N0bmFtZSBzc2hkWzM1OTg5XTogZXJy b3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuMTI4LjEx MC42NApPY3QgIDMgMTg6MzI6MjIgaG9zdG5hbWUgc3NoZFszNTk4OV06IGVycm9yOiBQQU06 IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjEyOC4xMTAuNjQKT2N0 ICAzIDE4OjMyOjIyIGhvc3RuYW1lIHNzaGRbMzU5OTRdOiBlcnJvcjogUEFNOiBhdXRoZW50 aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC4xMjguMTEwLjY0Ck9jdCAgMyAxODoz MjoyMyBob3N0bmFtZSBzc2hkWzM1OTk0XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24g ZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuMTI4LjExMC42NApPY3QgIDMgMTg6MzI6MjQgaG9z dG5hbWUgc3NoZFszNTk5NF06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZv ciByb290IGZyb20gMTkwLjEyOC4xMTAuNjQKT2N0ICAzIDE4OjMyOjI0IGhvc3RuYW1lIHNz aGRbMzU5OTRdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBm cm9tIDE5MC4xMjguMTEwLjY0Ck9jdCAgMyAxODozMjoyNCBob3N0bmFtZSBzc2hkWzM1OTk0 XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAu MTI4LjExMC42NApPY3QgIDMgMTg6MzI6MjUgaG9zdG5hbWUgc3NoZFszNTk5NF06IGVycm9y OiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjEyOC4xMTAu NjQKT2N0ICAzIDE4OjMyOjM4IGhvc3RuYW1lIHNzaGRbMzYwMDhdOiBlcnJvcjogUEFNOiBh dXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC4xMjguMTEwLjY0Ck9jdCAg MyAxODozMjozOCBob3N0bmFtZSBzc2hkWzM2MDA4XTogZXJyb3I6IFBBTTogYXV0aGVudGlj YXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuMTI4LjExMC42NApPY3QgIDMgMTg6MzI6 MzkgaG9zdG5hbWUgc3NoZFszNjAwOF06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVy cm9yIGZvciByb290IGZyb20gMTkwLjEyOC4xMTAuNjQKT2N0ICAzIDE4OjMyOjM5IGhvc3Ru YW1lIHNzaGRbMzYwMDhdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Ig cm9vdCBmcm9tIDE5MC4xMjguMTEwLjY0Ck9jdCAgMyAxODozMjo0MCBob3N0bmFtZSBzc2hk WzM2MDA4XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJv bSAxOTAuMTI4LjExMC42NApPY3QgIDMgMTg6MzI6NDEgaG9zdG5hbWUgc3NoZFszNjAwOF06 IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjEy OC4xMTAuNjQKT2N0ICAzIDE4OjMyOjUyIGhvc3RuYW1lIHNzaGRbMzYwMTZdOiBlcnJvcjog UEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC4xMjguMTEwLjY0 Ck9jdCAgMyAxODozMjo1MiBob3N0bmFtZSBzc2hkWzM2MDE2XTogZXJyb3I6IFBBTTogYXV0 aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuMTI4LjExMC42NApPY3QgIDMg MTg6MzI6NTIgaG9zdG5hbWUgc3NoZFszNjAxNl06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0 aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjEyOC4xMTAuNjQKT2N0ICAzIDE4OjMyOjUz IGhvc3RuYW1lIHNzaGRbMzYwMTZdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJv ciBmb3Igcm9vdCBmcm9tIDE5MC4xMjguMTEwLjY0Ck9jdCAgMyAxODozMjo1MyBob3N0bmFt ZSBzc2hkWzM2MDE2XTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJv b3QgZnJvbSAxOTAuMTI4LjExMC42NApPY3QgIDMgMTg6MzI6NTQgaG9zdG5hbWUgc3NoZFsz NjAxNl06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20g MTkwLjEyOC4xMTAuNjQKT2N0ICAzIDE4OjM0OjAzIGhvc3RuYW1lIHNzaGRbMzYwNzRdOiBl cnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC4xMjgu MTEwLjY0Ck9jdCAgMyAxODozNDo1OCBob3N0bmFtZSBzc2hkWzM2MTkyXTogZXJyb3I6IHNz aF9tc2dfc2VuZDogd3JpdGUKT2N0ICAzIDE4OjM1OjEwIGhvc3RuYW1lIHNzaGRbMzYyMjNd OiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC4x MjguMTEwLjY0Ck9jdCAgMyAxODozNToxMSBob3N0bmFtZSBzc2hkWzM2MjIzXTogZXJyb3I6 IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuMTI4LjExMC42 NApPY3QgIDMgMTg6MzU6MTEgaG9zdG5hbWUgc3NoZFszNjIyM106IGVycm9yOiBQQU06IGF1 dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjEyOC4xMTAuNjQKT2N0ICAz IDE4OjM1OjEyIGhvc3RuYW1lIHNzaGRbMzYyMjNdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNh dGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC4xMjguMTEwLjY0Ck9jdCAgMyAxODozNTox MiBob3N0bmFtZSBzc2hkWzM2MjIzXTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJy b3IgZm9yIHJvb3QgZnJvbSAxOTAuMTI4LjExMC42NApPY3QgIDMgMTg6MzU6MTMgaG9zdG5h bWUgc3NoZFszNjIyM106IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciBy b290IGZyb20gMTkwLjEyOC4xMTAuNjQKT2N0ICAzIDE4OjM1OjI4IGhvc3RuYW1lIHNzaGRb MzYyMzFdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9t IDE5MC4xMjguMTEwLjY0Ck9jdCAgMyAxODozNToyOSBob3N0bmFtZSBzc2hkWzM2MjMxXTog ZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuMTI4 LjExMC42NApPY3QgIDMgMTg6MzU6MjkgaG9zdG5hbWUgc3NoZFszNjIzMV06IGVycm9yOiBQ QU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjEyOC4xMTAuNjQK T2N0ICAzIDE4OjM1OjMwIGhvc3RuYW1lIHNzaGRbMzYyMzFdOiBlcnJvcjogUEFNOiBhdXRo ZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC4xMjguMTEwLjY0Ck9jdCAgMyAx ODozNTozMCBob3N0bmFtZSBzc2hkWzM2MjMxXTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRp b24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuMTI4LjExMC42NApPY3QgIDMgMTg6MzU6MzEg aG9zdG5hbWUgc3NoZFszNjIzMV06IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9y IGZvciByb290IGZyb20gMTkwLjEyOC4xMTAuNjQKT2N0ICAzIDE4OjM1OjMyIGhvc3RuYW1l IHNzaGRbMzYyMzNdOiBlcnJvcjogUEFNOiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9v dCBmcm9tIDE5MC4xMjguMTEwLjY0Ck9jdCAgMyAxODozNTozMiBob3N0bmFtZSBzc2hkWzM2 MjMzXTogZXJyb3I6IFBBTTogYXV0aGVudGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAx OTAuMTI4LjExMC42NApPY3QgIDMgMTg6MzU6MzMgaG9zdG5hbWUgc3NoZFszNjIzM106IGVy cm9yOiBQQU06IGF1dGhlbnRpY2F0aW9uIGVycm9yIGZvciByb290IGZyb20gMTkwLjEyOC4x MTAuNjQKT2N0ICAzIDE4OjM1OjMzIGhvc3RuYW1lIHNzaGRbMzYyMzNdOiBlcnJvcjogUEFN OiBhdXRoZW50aWNhdGlvbiBlcnJvciBmb3Igcm9vdCBmcm9tIDE5MC4xMjguMTEwLjY0Ck9j dCAgMyAxODozNTozNCBob3N0bmFtZSBzc2hkWzM2MjMzXTogZXJyb3I6IFBBTTogYXV0aGVu dGljYXRpb24gZXJyb3IgZm9yIHJvb3QgZnJvbSAxOTAuMTI4LjExMC42NApPY3QgIDMgMTg6 MzU6MzQgaG9zdG5hbWUgc3NoZFszNjIzM106IGVycm9yOiBQQU06IGF1dGhlbnRpY2F0aW9u IGVycm9yIGZvciByb290IGZyb20gMTkwLjEyOC4xMTAuNjQKT2N0ICAzIDE5OjAwOjAxIGhv c3RuYW1lIHNlbmRtYWlsWzM3Nzc2XTogTk9RVUVVRTogU1lTRVJSKHJvb3QpOiBjYW4gbm90 IGNoZGlyKC92YXIvc3Bvb2wvY2xpZW50bXF1ZXVlLyk6IFBlcm1pc3Npb24gZGVuaWVkCk9j dCAgMyAxOTowNTowMSBob3N0bmFtZSBzZW5kbWFpbFszODIzMl06IE5PUVVFVUU6IFNZU0VS Uihyb290KTogY2FuIG5vdCBjaGRpcigvdmFyL3Nwb29sL2NsaWVudG1xdWV1ZS8pOiBQZXJt aXNzaW9uIGRlbmllZApPY3QgIDMgMTk6MDY6MDEgaG9zdG5hbWUgc2VuZG1haWxbMzgzMzld OiBOT1FVRVVFOiBTWVNFUlIocm9vdCk6IGNhbiBub3QgY2hkaXIoL3Zhci9zcG9vbC9jbGll bnRtcXVldWUvKTogUGVybWlzc2lvbiBkZW5pZWQKT2N0ICAzIDE5OjEzOjQ2IGhvc3RuYW1l IHNlbmRtYWlsWzM5MjAyXTogTk9RVUVVRTogU1lTRVJSKHJvb3QpOiBjYW4gbm90IGNoZGly KC92YXIvc3Bvb2wvY2xpZW50bXF1ZXVlLyk6IFBlcm1pc3Npb24gZGVuaWVkCk9jdCAgMyAx OTozNzowMCBob3N0bmFtZSBzZW5kbWFpbFs0MDcwMF06IE5PUVVFVUU6IFNZU0VSUihyb290 KTogY2FuIG5vdCBjaGRpcigvdmFyL3Nwb29sL2NsaWVudG1xdWV1ZS8pOiBQZXJtaXNzaW9u IGRlbmllZApPY3QgIDMgMTk6NDU6MDAgaG9zdG5hbWUgc2VuZG1haWxbNDA5NzJdOiBOT1FV RVVFOiBTWVNFUlIocm9vdCk6IGNhbiBub3QgY2hkaXIoL3Zhci9zcG9vbC9jbGllbnRtcXVl dWUvKTogUGVybWlzc2lvbiBkZW5pZWQKT2N0ICAzIDE5OjQ5OjAxIGhvc3RuYW1lIHNlbmRt YWlsWzQxMjIyXTogTk9RVUVVRTogU1lTRVJSKHJvb3QpOiBjYW4gbm90IGNoZGlyKC92YXIv c3Bvb2wvY2xpZW50bXF1ZXVlLyk6IFBlcm1pc3Npb24gZGVuaWVkCk9jdCAgMyAyMDoyMjow MCBob3N0bmFtZSBzZW5kbWFpbFs0NjAxNl06IE5PUVVFVUU6IFNZU0VSUihyb290KTogY2Fu IG5vdCBjaGRpcigvdmFyL3Nwb29sL2NsaWVudG1xdWV1ZS8pOiBQZXJtaXNzaW9uIGRlbmll ZApPY3QgIDMgMjA6MjY6MDEgaG9zdG5hbWUgc2VuZG1haWxbNDY1NTVdOiBOT1FVRVVFOiBT WVNFUlIocm9vdCk6IGNhbiBub3QgY2hkaXIoL3Zhci9zcG9vbC9jbGllbnRtcXVldWUvKTog UGVybWlzc2lvbiBkZW5pZWQKT2N0ICAzIDIwOjM4OjAxIGhvc3RuYW1lIHNlbmRtYWlsWzQ5 MjI1XTogTk9RVUVVRTogU1lTRVJSKHJvb3QpOiBjYW4gbm90IGNoZGlyKC92YXIvc3Bvb2wv Y2xpZW50bXF1ZXVlLyk6IFBlcm1pc3Npb24gZGVuaWVkCk9jdCAgMyAyMDo0MTowMSBob3N0 bmFtZSBzZW5kbWFpbFs0OTkyNl06IE5PUVVFVUU6IFNZU0VSUihyb290KTogY2FuIG5vdCBj aGRpcigvdmFyL3Nwb29sL2NsaWVudG1xdWV1ZS8pOiBQZXJtaXNzaW9uIGRlbmllZApPY3Qg IDMgMjE6MDY6MDAgaG9zdG5hbWUgc2VuZG1haWxbNTEzODhdOiBOT1FVRVVFOiBTWVNFUlIo cm9vdCk6IGNhbiBub3QgY2hkaXIoL3Zhci9zcG9vbC9jbGllbnRtcXVldWUvKTogUGVybWlz c2lvbiBkZW5pZWQKT2N0ICAzIDIxOjE4OjAwIGhvc3RuYW1lIHNlbmRtYWlsWzUxNjQ1XTog Tk9RVUVVRTogU1lTRVJSKHJvb3QpOiBjYW4gbm90IGNoZGlyKC92YXIvc3Bvb2wvY2xpZW50 bXF1ZXVlLyk6IFBlcm1pc3Npb24gZGVuaWVkCk9jdCAgMyAyMTozMDowMCBob3N0bmFtZSBz ZW5kbWFpbFs1MTkxOF06IE5PUVVFVUU6IFNZU0VSUihyb290KTogY2FuIG5vdCBjaGRpcigv dmFyL3Nwb29sL2NsaWVudG1xdWV1ZS8pOiBQZXJtaXNzaW9uIGRlbmllZApPY3QgIDMgMjE6 NDA6MDEgaG9zdG5hbWUgc2VuZG1haWxbNTQ4NTldOiBOT1FVRVVFOiBTWVNFUlIocm9vdCk6 IGNhbiBub3QgY2hkaXIoL3Zhci9zcG9vbC9jbGllbnRtcXVldWUvKTogUGVybWlzc2lvbiBk ZW5pZWQKT2N0ICAzIDIxOjQxOjAxIGhvc3RuYW1lIHNlbmRtYWlsWzU1MTY2XTogTk9RVUVV RTogU1lTRVJSKHJvb3QpOiBjYW4gbm90IGNoZGlyKC92YXIvc3Bvb2wvY2xpZW50bXF1ZXVl Lyk6IFBlcm1pc3Npb24gZGVuaWVkCk9jdCAgMyAyMTo1MDowMCBob3N0bmFtZSBzZW5kbWFp bFs1NjIwMV06IE5PUVVFVUU6IFNZU0VSUihyb290KTogY2FuIG5vdCBjaGRpcigvdmFyL3Nw b29sL2NsaWVudG1xdWV1ZS8pOiBQZXJtaXNzaW9uIGRlbmllZApPY3QgIDMgMjI6MDk6MDEg aG9zdG5hbWUgc2VuZG1haWxbNTcyMzhdOiBOT1FVRVVFOiBTWVNFUlIocm9vdCk6IGNhbiBu b3QgY2hkaXIoL3Zhci9zcG9vbC9jbGllbnRtcXVldWUvKTogUGVybWlzc2lvbiBkZW5pZWQK T2N0ICAzIDIyOjQ4OjAwIGhvc3RuYW1lIHNlbmRtYWlsWzYxNTY4XTogTk9RVUVVRTogU1lT RVJSKHJvb3QpOiBjYW4gbm90IGNoZGlyKC92YXIvc3Bvb2wvY2xpZW50bXF1ZXVlLyk6IFBl cm1pc3Npb24gZGVuaWVkCk9jdCAgMyAyMzowNzowMCBob3N0bmFtZSBzZW5kbWFpbFs2Mzk1 NV06IE5PUVVFVUU6IFNZU0VSUihyb290KTogY2FuIG5vdCBjaGRpcigvdmFyL3Nwb29sL2Ns aWVudG1xdWV1ZS8pOiBQZXJtaXNzaW9uIGRlbmllZApPY3QgIDMgMjM6MzY6MDEgaG9zdG5h bWUgc2VuZG1haWxbNjU0MDFdOiBOT1FVRVVFOiBTWVNFUlIocm9vdCk6IGNhbiBub3QgY2hk aXIoL3Zhci9zcG9vbC9jbGllbnRtcXVldWUvKTogUGVybWlzc2lvbiBkZW5pZWQKT2N0ICAz IDIzOjM5OjAxIGhvc3RuYW1lIHNlbmRtYWlsWzY1NDY3XTogTk9RVUVVRTogU1lTRVJSKHJv b3QpOiBjYW4gbm90IGNoZGlyKC92YXIvc3Bvb2wvY2xpZW50bXF1ZXVlLyk6IFBlcm1pc3Np b24gZGVuaWVkCk9jdCAgMyAyMzo1MDowMSBob3N0bmFtZSBzZW5kbWFpbFs2NTcxNV06IE5P UVVFVUU6IFNZU0VSUihyb290KTogY2FuIG5vdCBjaGRpcigvdmFyL3Nwb29sL2NsaWVudG1x dWV1ZS8pOiBQZXJtaXNzaW9uIGRlbmllZApPY3QgIDQgMDA6NDU6MDAgaG9zdG5hbWUgc2Vu ZG1haWxbNjc2NDVdOiBOT1FVRVVFOiBTWVNFUlIocm9vdCk6IGNhbiBub3QgY2hkaXIoL3Zh ci9zcG9vbC9jbGllbnRtcXVldWUvKTogUGVybWlzc2lvbiBkZW5pZWQKT2N0ICA0IDAxOjA1 OjAwIGhvc3RuYW1lIHNlbmRtYWlsWzY4MjYyXTogTk9RVUVVRTogU1lTRVJSKHJvb3QpOiBj YW4gbm90IGNoZGlyKC92YXIvc3Bvb2wvY2xpZW50bXF1ZXVlLyk6IFBlcm1pc3Npb24gZGVu aWVkCmNvbmZpZ19yZWQgY2FsbGVkCmNvbmZpZ19yZWQgZXhpdApjb25maWdfcmVkIGNhbGxl ZApjb25maWdfcmVkIGV4aXQKY29uZmlnX3JlZCBjYWxsZWQKY29uZmlnX3JlZCBleGl0CmNv bmZpZ19yZWQgY2FsbGVkCmNvbmZpZ19yZWQgZXhpdApjb25maWdfcmVkIGNhbGxlZApjb25m aWdfcmVkIGV4aXQKY29uZmlnX3JlZCBjYWxsZWQKY29uZmlnX3JlZCBleGl0Ck9jdCAgNCAw MToxNTowMSBob3N0bmFtZSBzZW5kbWFpbFs2ODQ5MF06IE5PUVVFVUU6IFNZU0VSUihyb290 KTogY2FuIG5vdCBjaGRpcigvdmFyL3Nwb29sL2NsaWVudG1xdWV1ZS8pOiBQZXJtaXNzaW9u IGRlbmllZApPY3QgIDQgMDE6MjM6MDAgaG9zdG5hbWUgc2VuZG1haWxbNjg2NTldOiBOT1FV RVVFOiBTWVNFUlIocm9vdCk6IGNhbiBub3QgY2hkaXIoL3Zhci9zcG9vbC9jbGllbnRtcXVl dWUvKTogUGVybWlzc2lvbiBkZW5pZWQKT2N0ICA0IDAxOjM4OjAxIGhvc3RuYW1lIHNlbmRt YWlsWzY4OTgwXTogTk9RVUVVRTogU1lTRVJSKHJvb3QpOiBjYW4gbm90IGNoZGlyKC92YXIv c3Bvb2wvY2xpZW50bXF1ZXVlLyk6IFBlcm1pc3Npb24gZGVuaWVkCk9jdCAgNCAwMTo0NDow MCBob3N0bmFtZSBzZW5kbWFpbFs2OTExNV06IE5PUVVFVUU6IFNZU0VSUihyb290KTogY2Fu IG5vdCBjaGRpcigvdmFyL3Nwb29sL2NsaWVudG1xdWV1ZS8pOiBQZXJtaXNzaW9uIGRlbmll ZApPY3QgIDQgMDE6NTE6MDAgaG9zdG5hbWUgc2VuZG1haWxbNjkyNThdOiBOT1FVRVVFOiBT WVNFUlIocm9vdCk6IGNhbiBub3QgY2hkaXIoL3Zhci9zcG9vbC9jbGllbnRtcXVldWUvKTog UGVybWlzc2lvbiBkZW5pZWQKT2N0ICA0IDAyOjMzOjAwIGhvc3RuYW1lIHNlbmRtYWlsWzcw MzAwXTogTk9RVUVVRTogU1lTRVJSKHJvb3QpOiBjYW4gbm90IGNoZGlyKC92YXIvc3Bvb2wv Y2xpZW50bXF1ZXVlLyk6IFBlcm1pc3Npb24gZGVuaWVkCk9jdCAgNCAwMjo0MTowMCBob3N0 bmFtZSBzZW5kbWFpbFs3MTMxOV06IE5PUVVFVUU6IFNZU0VSUihyb290KTogY2FuIG5vdCBj aGRpcigvdmFyL3Nwb29sL2NsaWVudG1xdWV1ZS8pOiBQZXJtaXNzaW9uIGRlbmllZApPY3Qg IDQgMDI6NDg6MDAgaG9zdG5hbWUgc2VuZG1haWxbNzIyMjBdOiBOT1FVRVVFOiBTWVNFUlIo cm9vdCk6IGNhbiBub3QgY2hkaXIoL3Zhci9zcG9vbC9jbGllbnRtcXVldWUvKTogUGVybWlz c2lvbiBkZW5pZWQKT2N0ICA0IDAzOjAxOjAxIGhvc3RuYW1lIHNlbmRtYWlsWzczOTYxXTog Tk9RVUVVRTogU1lTRVJSKHJvb3QpOiBjYW4gbm90IGNoZGlyKC92YXIvc3Bvb2wvY2xpZW50 bXF1ZXVlLyk6IFBlcm1pc3Npb24gZGVuaWVkCk9jdCAgNCAwMzowMToxNCBob3N0bmFtZSBz ZW5kbWFpbFs3NDM2NV06IE5PUVVFVUU6IFNZU0VSUihyb290KTogY2FuIG5vdCBjaGRpcigv dmFyL3Nwb29sL2NsaWVudG1xdWV1ZS8pOiBQZXJtaXNzaW9uIGRlbmllZApPY3QgIDQgMDM6 MDE6MTQgaG9zdG5hbWUgc2VuZG1haWxbNzQ0MTNdOiBOT1FVRVVFOiBTWVNFUlIocm9vdCk6 IGNhbiBub3QgY2hkaXIoL3Zhci9zcG9vbC9jbGllbnRtcXVldWUvKTogUGVybWlzc2lvbiBk ZW5pZWQKT2N0ICA0IDAzOjAxOjE0IGhvc3RuYW1lIHNlbmRtYWlsWzc0NDIzXTogTk9RVUVV RTogU1lTRVJSKHJvb3QpOiBjYW4gbm90IGNoZGlyKC92YXIvc3Bvb2wvY2xpZW50bXF1ZXVl Lyk6IFBlcm1pc3Npb24gZGVuaWVkCk9jdCAgNCAwMzowMToxNCBob3N0bmFtZSBzZW5kbWFp bFs3NDQyNV06IE5PUVVFVUU6IFNZU0VSUihyb290KTogY2FuIG5vdCBjaGRpcigvdmFyL3Nw b29sL2NsaWVudG1xdWV1ZS8pOiBQZXJtaXNzaW9uIGRlbmllZAoKCgpGYXRhbCB0cmFwIDEy OiBwYWdlIGZhdWx0IHdoaWxlIGluIGtlcm5lbCBtb2RlCkZhdGFsIHRyYXAgMTI6IHBhZ2Ug ZmF1bHQgd2hpbGUgaW4ga2VybmVsIG1vZGUKY3B1aWQgPSA2OyAKY3B1aWQgPSA0OyBhcGlj IGlkID0gMDZhcGljIGlkID0gMDQKZmF1bHQgdmlydHVhbCBhZGRyZXNzCT0gMHhmZmZmZmZm ZjAwMDAwMTIwCmZhdWx0IHZpcnR1YWwgYWRkcmVzcwk9IDB4ZmZmZmZmZmYwMDA0MDA2MQpm YXVsdCBjb2RlCQk9IHN1cGVydmlzb3IgcmVhZCBkYXRhLCBwYWdlIG5vdCBwcmVzZW50CmZh dWx0IGNvZGUJCT0gc3VwZXJ2aXNvciByZWFkIGRhdGEsIHBhZ2Ugbm90IHByZXNlbnQKaW5z dHJ1Y3Rpb24gcG9pbnRlcgk9IDB4MjA6MHhmZmZmZmZmZjgwNjk4YWJmCmluc3RydWN0aW9u IHBvaW50ZXIJPSAweDIwOjB4ZmZmZmZmZmY4MDY5YjRmZgpzdGFjayBwb2ludGVyCSAgICAg ICAgPSAweDI4OjB4ZmZmZmZmODFiMWM4ODYxMApzdGFjayBwb2ludGVyCSAgICAgICAgPSAw eDI4OjB4ZmZmZmZmODFiM2YxMzkyMApmcmFtZSBwb2ludGVyCSAgICAgICAgPSAweDI4OjB4 ZmZmZmZmODFiMWM4ODYzMApmcmFtZSBwb2ludGVyCSAgICAgICAgPSAweDI4OjB4ZmZmZmZm ODFiM2YxMzkzMApjb2RlIHNlZ21lbnQJCT0gYmFzZSAweDAsIGxpbWl0IDB4ZmZmZmYsIHR5 cGUgMHgxYgpjb2RlIHNlZ21lbnQJCT0gYmFzZSAweDAsIGxpbWl0IDB4ZmZmZmYsIHR5cGUg MHgxYgoJCQk9IERQTCAwLCBwcmVzIDEsIGxvbmcgMSwgZGVmMzIgMCwgZ3JhbiAxCgkJCT0g RFBMIDAsIHByZXMgMSwgbG9uZyAxLCBkZWYzMiAwLCBncmFuIDEKcHJvY2Vzc29yIGVmbGFn cwk9IApwcm9jZXNzb3IgZWZsYWdzCT0gaW50ZXJydXB0IGVuYWJsZWQsIGludGVycnVwdCBl bmFibGVkLCByZXN1bWUsIHJlc3VtZSwgSU9QTCA9IDBJT1BMID0gMApjdXJyZW50IHByb2Nl c3MJCT0gCmN1cnJlbnQgcHJvY2VzcwkJPSAxMiAoaXJxMjU3OiBlbTEpMCAoZHVtbXluZXQp CnRyYXAgbnVtYmVyCQk9IDEyCnRyYXAgbnVtYmVyCQk9IDEyCnBhbmljOiBwYWdlIGZhdWx0 CgpjcHVpZCA9IDYKVXB0aW1lOiAxNmQyM2g1N200NXMKUGh5c2ljYWwgbWVtb3J5OiA0MDQ0 IE1CCkR1bXBpbmcgMTcwNCBNQjogMTY4OSAxNjczIDE2NTcgMTY0MSAxNjI1IDE2MDkgMTU5 MyAxNTc3IDE1NjEgMTU0NSAxNTI5IDE1MTMgMTQ5NyAxNDgxIDE0NjUgMTQ0OSAxNDMzIDE0 MTcgMTQwMSAxMzg1IDEzNjkgMTM1MyAxMzM3IDEzMjEgMTMwNSAxMjg5IDEyNzMgMTI1NyAx MjQxIDEyMjUgMTIwOSAxMTkzIDExNzcgMTE2MSAxMTQ1IDExMjkgMTExMyAxMDk3IDEwODEg MTA2NSAxMDQ5IDEwMzMgMTAxNyAxMDAxIDk4NSA5NjkgOTUzIDkzNyA5MjEgOTA1IDg4OSA4 NzMgODU3IDg0MSA4MjUgODA5IDc5MyA3NzcgNzYxIDc0NSA3MjkgNzEzIDY5NyA2ODEgNjY1 IDY0OSA2MzMgNjE3IDYwMSA1ODUgNTY5IDU1MyA1MzcgNTIxIDUwNSA0ODkgNDczIDQ1NyA0 NDEgNDI1IDQwOSAzOTMgMzc3IDM2MSAzNDUgMzI5IDMxMyAyOTcgMjgxIDI2NSAyNDkgMjMz IDIxNyAyMDEgMTg1IDE2OSAxNTMgMTM3IDEyMSAxMDUgODkgNzMgNTcgNDEgMjUgOQoKLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tCmtlcm5lbCBjb25maWcKCm9wdGlvbnMJQ09ORklHX0FVVE9HRU5F UkFURUQKaWRlbnQJaG9zdG5hbWUKbWFjaGluZQlhbWQ2NApjcHUJSEFNTUVSCm1ha2VvcHRp b25zCURFQlVHPS1nCm9wdGlvbnMJRFVNTVlORVQKb3B0aW9ucwlJUFNURUFMVEgKb3B0aW9u cwlJUERJVkVSVApvcHRpb25zCURFVklDRV9QT0xMSU5HCm9wdGlvbnMJSVBGSVJFV0FMTF9E RUZBVUxUX1RPX0FDQ0VQVApvcHRpb25zCUlQRklSRVdBTExfRk9SV0FSRApvcHRpb25zCUlQ RklSRVdBTEwKb3B0aW9ucwlBSF9TVVBQT1JUX0FSNTQxNgpvcHRpb25zCUlFRUU4MDIxMV9T VVBQT1JUX01FU0gKb3B0aW9ucwlJRUVFODAyMTFfQU1QRFVfQUdFCm9wdGlvbnMJSUVFRTgw MjExX0RFQlVHCm9wdGlvbnMJQUhEX1JFR19QUkVUVFlfUFJJTlQKb3B0aW9ucwlBSENfUkVH X1BSRVRUWV9QUklOVApvcHRpb25zCUFUQV9TVEFUSUNfSUQKb3B0aW9ucwlTTVAKb3B0aW9u cwlJTkNMVURFX0NPTkZJR19GSUxFCm9wdGlvbnMJRkxPV1RBQkxFCm9wdGlvbnMJTUFDCm9w dGlvbnMJQVVESVQKb3B0aW9ucwlIV1BNQ19IT09LUwpvcHRpb25zCUtCRF9JTlNUQUxMX0NE RVYKb3B0aW9ucwlQUklOVEZfQlVGUl9TSVpFPTEyOApvcHRpb25zCV9LUE9TSVhfUFJJT1JJ VFlfU0NIRURVTElORwpvcHRpb25zCVAxMDAzXzFCX1NFTUFQSE9SRVMKb3B0aW9ucwlTWVNW U0VNCm9wdGlvbnMJU1lTVk1TRwpvcHRpb25zCVNZU1ZTSE0Kb3B0aW9ucwlTVEFDSwpvcHRp b25zCUtUUkFDRQpvcHRpb25zCVNDU0lfREVMQVk9NTAwMApvcHRpb25zCUNPTVBBVF9GUkVF QlNENwpvcHRpb25zCUNPTVBBVF9GUkVFQlNENgpvcHRpb25zCUNPTVBBVF9GUkVFQlNENQpv cHRpb25zCUNPTVBBVF9GUkVFQlNENApvcHRpb25zCUNPTVBBVF9GUkVFQlNEMzIKb3B0aW9u cwlDT01QQVRfNDNUVFkKb3B0aW9ucwlHRU9NX0xBQkVMCm9wdGlvbnMJR0VPTV9QQVJUX0dQ VApvcHRpb25zCVBTRVVET0ZTCm9wdGlvbnMJUFJPQ0ZTCm9wdGlvbnMJQ0Q5NjYwCm9wdGlv bnMJTVNET1NGUwpvcHRpb25zCU5GU19ST09UCm9wdGlvbnMJTkZTTE9DS0QKb3B0aW9ucwlO RlNTRVJWRVIKb3B0aW9ucwlORlNDTElFTlQKb3B0aW9ucwlNRF9ST09UCm9wdGlvbnMJVUZT X0dKT1VSTkFMCm9wdGlvbnMJVUZTX0RJUkhBU0gKb3B0aW9ucwlVRlNfQUNMCm9wdGlvbnMJ U09GVFVQREFURVMKb3B0aW9ucwlGRlMKb3B0aW9ucwlTQ1RQCm9wdGlvbnMJSU5FVDYKb3B0 aW9ucwlJTkVUCm9wdGlvbnMJUFJFRU1QVElPTgpvcHRpb25zCVNDSEVEX1VMRQpvcHRpb25z CUdFT01fUEFSVF9NQlIKb3B0aW9ucwlHRU9NX1BBUlRfRUJSX0NPTVBBVApvcHRpb25zCUdF T01fUEFSVF9FQlIKb3B0aW9ucwlHRU9NX1BBUlRfQlNECmRldmljZQlpc2EKZGV2aWNlCW1l bQpkZXZpY2UJaW8KZGV2aWNlCXVhcnRfbnM4MjUwCmRldmljZQljcHVmcmVxCmRldmljZQlh Y3BpCmRldmljZQlwY2kKZGV2aWNlCWZkYwpkZXZpY2UJYXRhCmRldmljZQlhdGFkaXNrCmRl dmljZQlhdGFyYWlkCmRldmljZQlhdGFwaWNkCmRldmljZQlhdGFwaWZkCmRldmljZQlhdGFw aXN0CmRldmljZQlhaGMKZGV2aWNlCWFoZApkZXZpY2UJYW1kCmRldmljZQlocHRpb3AKZGV2 aWNlCWlzcApkZXZpY2UJbXB0CmRldmljZQlzeW0KZGV2aWNlCXRybQpkZXZpY2UJYWR2CmRl dmljZQlhZHcKZGV2aWNlCWFpYwpkZXZpY2UJYnQKZGV2aWNlCXNjYnVzCmRldmljZQljaApk ZXZpY2UJZGEKZGV2aWNlCXNhCmRldmljZQljZApkZXZpY2UJcGFzcwpkZXZpY2UJc2VzCmRl dmljZQlhbXIKZGV2aWNlCWFyY21zcgpkZXZpY2UJY2lzcwpkZXZpY2UJZHB0CmRldmljZQlo cHRtdgpkZXZpY2UJaHB0cnIKZGV2aWNlCWlpcgpkZXZpY2UJaXBzCmRldmljZQltbHkKZGV2 aWNlCXR3YQpkZXZpY2UJYWFjCmRldmljZQlhYWNwCmRldmljZQlpZGEKZGV2aWNlCW1maQpk ZXZpY2UJbWx4CmRldmljZQl0d2UKZGV2aWNlCWF0a2JkYwpkZXZpY2UJYXRrYmQKZGV2aWNl CXBzbQpkZXZpY2UJa2JkbXV4CmRldmljZQl2Z2EKZGV2aWNlCXNwbGFzaApkZXZpY2UJc2MK ZGV2aWNlCWFncApkZXZpY2UJY2JiCmRldmljZQlwY2NhcmQKZGV2aWNlCWNhcmRidXMKZGV2 aWNlCXVhcnQKZGV2aWNlCXBwYwpkZXZpY2UJcHBidXMKZGV2aWNlCWxwdApkZXZpY2UJcGxp cApkZXZpY2UJcHBpCmRldmljZQlkZQpkZXZpY2UJZW0KZGV2aWNlCWlnYgpkZXZpY2UJaXhn YmUKZGV2aWNlCWxlCmRldmljZQl0aQpkZXZpY2UJdHhwCmRldmljZQl2eApkZXZpY2UJbWlp YnVzCmRldmljZQlhZQpkZXZpY2UJYWdlCmRldmljZQlhbGMKZGV2aWNlCWFsZQpkZXZpY2UJ YmNlCmRldmljZQliZmUKZGV2aWNlCWJnZQpkZXZpY2UJZGMKZGV2aWNlCWV0CmRldmljZQlm eHAKZGV2aWNlCWptZQpkZXZpY2UJbGdlCmRldmljZQltc2sKZGV2aWNlCW5mZQpkZXZpY2UJ bmdlCmRldmljZQlwY24KZGV2aWNlCXJlCmRldmljZQlybApkZXZpY2UJc2YKZGV2aWNlCXNp cwpkZXZpY2UJc2sKZGV2aWNlCXN0ZQpkZXZpY2UJc3RnZQpkZXZpY2UJdGwKZGV2aWNlCXR4 CmRldmljZQl2Z2UKZGV2aWNlCXZyCmRldmljZQl3YgpkZXZpY2UJeGwKZGV2aWNlCWNzCmRl dmljZQllZApkZXZpY2UJZXgKZGV2aWNlCWVwCmRldmljZQlmZQpkZXZpY2UJc24KZGV2aWNl CXhlCmRldmljZQl3bGFuCmRldmljZQl3bGFuX3dlcApkZXZpY2UJd2xhbl9jY21wCmRldmlj ZQl3bGFuX3RraXAKZGV2aWNlCXdsYW5fYW1ycgpkZXZpY2UJYW4KZGV2aWNlCWF0aApkZXZp Y2UJYXRoX2hhbApkZXZpY2UJYXRoX3JhdGVfc2FtcGxlCmRldmljZQlyYWwKZGV2aWNlCXdp CmRldmljZQlsb29wCmRldmljZQlyYW5kb20KZGV2aWNlCWV0aGVyCmRldmljZQl2bGFuCmRl dmljZQl0dW4KZGV2aWNlCXB0eQpkZXZpY2UJbWQKZGV2aWNlCWdpZgpkZXZpY2UJZmFpdGgK ZGV2aWNlCWZpcm13YXJlCmRldmljZQlicGYKZGV2aWNlCXVoY2kKZGV2aWNlCW9oY2kKZGV2 aWNlCWVoY2kKZGV2aWNlCXVzYgpkZXZpY2UJdWhpZApkZXZpY2UJdWtiZApkZXZpY2UJdWxw dApkZXZpY2UJdW1hc3MKZGV2aWNlCXVtcwpkZXZpY2UJdXJpbwpkZXZpY2UJdWFyawpkZXZp Y2UJdWJzYQpkZXZpY2UJdWZ0ZGkKZGV2aWNlCXVpcGFxCmRldmljZQl1cGxjb20KZGV2aWNl CXVzbGNvbQpkZXZpY2UJdXZpc29yCmRldmljZQl1dnNjb20KZGV2aWNlCWF1ZQpkZXZpY2UJ YXhlCmRldmljZQljZGNlCmRldmljZQljdWUKZGV2aWNlCWt1ZQpkZXZpY2UJcnVlCmRldmlj ZQl1ZGF2CmRldmljZQlydW0KZGV2aWNlCXVhdGgKZGV2aWNlCXVyYWwKZGV2aWNlCXp5ZApk ZXZpY2UJZmlyZXdpcmUKZGV2aWNlCWZ3ZQpkZXZpY2UJZndpcApkZXZpY2UJZGNvbnMKZGV2 aWNlCWRjb25zX2Nyb20KCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpkZGIgY2FwdHVyZSBidWZmZXIK CmRkYjogZGRiX2NhcHR1cmU6IGt2bV9ubGlzdAo= ------------581BD1DE24DDAE94-- From owner-freebsd-stable@FreeBSD.ORG Sat Nov 13 05:20: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 1ACA0106566C for ; Sat, 13 Nov 2010 05:20:14 +0000 (UTC) (envelope-from fanreach@reverbnation.com) Received: from profanreach-ub.reverbnation.com (profanreach-ub.reverbnation.com [64.151.117.190]) by mx1.freebsd.org (Postfix) with ESMTP id 078DA8FC0C for ; Sat, 13 Nov 2010 05:20:12 +0000 (UTC) Received: from angus.reverbnation.com (angus.reverbnation.com [192.168.0.22]) by profanreach-ub.reverbnation.com (Postfix) with ESMTP id 6CEB84073F6 for ; Sat, 13 Nov 2010 00:00:31 -0500 (EST) From: BeatsBeast Producer To: freebsd-stable@freebsd.org Message-Id: Date: Sat, 13 Nov 2010 00:00:31 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Confirmation Message from BeatsBeast (Producer) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Nov 2010 05:20:14 -0000 freebsd-stable@freebsd.org, You are receiving this message because BeatsBeast (Producer) added you as a contact. "" -- BeatsBeast (Producer) Your options: [1]Confirm my email so that I will be eligible for any exclusives from BeatsBeast (Producer) Do nothing and remain on the BeatsBeast (Producer) mailing list. [2]Unsubscribe from this list [3]Report Spam or Abuse _________________________________________________________________ This email sent through FanReach from ReverbNation. BeatsBeast (Producer) have indicated that you have requested this information. ReverbNation.com: 501 Washington St., Suite D, Durham NC 27701 [4] Update Contact Info [5] Unsubscribe [6] Report Abuse [7] Privacy References 1. http://www.reverbnation.com/c/fr7/artist_158288?eid=A158288_6238539_30674416&fsc=791e9d14a39&action_code=opt_in 2. http://www.reverbnation.com/c/fr2/artist_158288?eid=A158288_6238539_30674416&fsc=791e9d14a39 3. http://www.reverbnation.com/c/fr6/artist_158288?eid=A158288_6238539_30674416&fsc=791e9d14a39 4. http://www.reverbnation.com/c/fr7/artist_158288?eid=A158288_6238539_30674416&fsc=791e9d14a39 5. http://www.reverbnation.com/c/fr2/artist_158288?eid=A158288_6238539_30674416&fsc=791e9d14a39 6. http://www.reverbnation.com/c/fr6/artist_158288?eid=A158288_6238539_30674416&fsc=791e9d14a39 7. http://www.reverbnation.com/c./cms/PrivacyPolicy?layout=popup&display=view_popup From owner-freebsd-stable@FreeBSD.ORG Sat Nov 13 06:30: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 86829106566B; Sat, 13 Nov 2010 06:30:53 +0000 (UTC) (envelope-from alexz@visp.ru) Received: from mail.visp.ru (srv1.visp.ru [91.215.204.2]) by mx1.freebsd.org (Postfix) with ESMTP id EBA288FC1B; Sat, 13 Nov 2010 06:30:52 +0000 (UTC) Received: from 91-215-205-255.static.visp.ru ([91.215.205.255] helo=zagrebin) by mail.visp.ru with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PH9dS-000Ivu-4I; Sat, 13 Nov 2010 09:30:50 +0300 From: "Alexander Zagrebin" To: "'Martin Matuska'" References: <4CDD2F5F.2000902@freebsd.org> <4CDD4EB4.40004@freebsd.org> <4CDDF77B.90708@FreeBSD.org> Date: Sat, 13 Nov 2010 09:30:49 +0300 Keywords: freebsd-stable Message-ID: <8EEEFFFCCE94428992BE20F4A2EB8362@vosz.local> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: AcuC2oQL0Tr2Iry0RMqsIX6jZG2/hgAGlavQ In-Reply-To: <4CDDF77B.90708@FreeBSD.org> Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org, 'Andriy Gapon' Subject: RE: 8.1-STABLE: problem with unmounting ZFS snapshots X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Nov 2010 06:30:53 -0000 > Yes, this is indeed a leak introduced by importing onnv revision 9214 > and it exists in perforce as well - very easy to reproduce. > > # mount -t zfs test@t1 /mnt > # umount /mnt (-> hang) > > http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6604992 > http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6810367 > > This is not compatible with mounting snapshots outside > mounted ZFS and I > was not able to reproduce the errors defined in 6604992 and 6810367 > (they are Solaris-specific). I suggest we comment out this code (from > head, later MFC and p4 as well). > > Patch (should work with HEAD and 8-STABLE): > http://people.freebsd.org/~mm/patches/zfs/zfs_vfsops.c.patch > The patch was applied cleanly to the latest stable. umount doesn't hangs now. Thanks. Let me ask a question... I'm updating the source tree via csup/cvs. Is there a method to determine a SVN revision in this case? If no, then may be possible to add (and automatically maintain on svn -> cvs replication) special file into cvs tree (for example, /usr/src/revision) with the current svn revision inside? -- Alexander Zagrebin From owner-freebsd-stable@FreeBSD.ORG Sat Nov 13 07:55: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 E33CD1065670 for ; Sat, 13 Nov 2010 07:55:44 +0000 (UTC) (envelope-from vanopen@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 92EAB8FC17 for ; Sat, 13 Nov 2010 07:55:44 +0000 (UTC) Received: by yxe1 with SMTP id 1so308501yxe.13 for ; Fri, 12 Nov 2010 23:55:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:organization :subject:to:mime-version:from:date:message-id:user-agent; bh=3/hokMiHxGQ5Q+50jmU6itNN7e83SZApkN4AbT7u03E=; b=kmGpEVqETQJQDQ9q1Gnd37xueqDgK8eBJwtupq7gOt2/26vMC/1SOrBv0tGpGRJV/0 Ib9AycP/o1uVp2KkPa85Y61x2hZEzJV9st3imIXPJxwLjsgpYKFn2YxkSHgM7z6TW3qq HoxHeBIxdhUcmCp0QlH3XBqu7Yi9mliu9TCyE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:organization:subject:to:mime-version:from:date :message-id:user-agent; b=t1IU9rHVVmQIWWw8TJjmWJxE8jO5QRihdcWTypmNxR8Ikhe/9F8/SrTSfAJSsJVjXI bCOtg75n7rqXTo4ioDXwcSNlHX074FV37CIdkPfqvDdYh+aepsFueCK74KhFrpcy/2OL cMpmpxe6aJ0j7PWHVr4Njub4S9FJnG9j5S8t8= Received: by 10.90.60.16 with SMTP id i16mr4470856aga.114.1289633530808; Fri, 12 Nov 2010 23:32:10 -0800 (PST) Received: from ywuw2k ([221.6.39.130]) by mx.google.com with ESMTPS id z30sm2992016yhc.9.2010.11.12.23.32.07 (version=SSLv3 cipher=RC4-MD5); Fri, 12 Nov 2010 23:32:09 -0800 (PST) Content-Type: multipart/mixed; boundary=----------D1Ghkj6lV57h7diO5qoA0o Organization: China Pharmaceutical University To: freebsd-stable@freebsd.org MIME-Version: 1.0 From: "Yue Wu" Date: Sat, 13 Nov 2010 15:32:05 +0800 Message-ID: User-Agent: Opera Mail/10.63 (Win32) Subject: Can't use wireless networking after upgrade the world recently X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Nov 2010 07:55:45 -0000 ------------D1Ghkj6lV57h7diO5qoA0o Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi list, As the title, my settings for wireless networking worked fine before upgrade to the yesterday stable src, don't know why now it doesn't work anymore. I've attached the startup's log, loader.conf, rc.conf, and output of ifconfig(trancated useless parts of them as needed). any info is needed? plz let me know. Sorry for my poor English, plz let me know if I didn't describe clearly. -- Regards, Yue Wu Key Laboratory of Modern Chinese Medicines Department of Traditional Chinese Medicine China Pharmaceutical University No.24, Tongjia Xiang Street, Nanjing 210009, China ------------D1Ghkj6lV57h7diO5qoA0o Content-Disposition: attachment; filename=ifconfig Content-Type: application/octet-stream; name=ifconfig Content-Transfer-Encoding: Base64 IyBpZmNvbmZpZwplbTA6IGZsYWdzPTg4MDI8QlJPQURDQVNULFNJTVBMRVgsTVVM VElDQVNUPiBtZXRyaWMgMCBtdHUgMTUwMAogICAgICAgIG9wdGlvbnM9MjE5YjxS WENTVU0sVFhDU1VNLFZMQU5fTVRVLFZMQU5fSFdUQUdHSU5HLFZMQU5fSFdDU1VN LFRTTzQsV09MXwpNQUdJQz4KICAgICAgICBldGhlciAwMDoxNjo0MTplNTplMzo4 ZAogICAgICAgIG1lZGlhOiBFdGhlcm5ldCBhdXRvc2VsZWN0CiAgICAgICAgc3Rh dHVzOiBubyBjYXJyaWVyCndwaTA6IGZsYWdzPTg4NDM8VVAsQlJPQURDQVNULFJV Tk5JTkcsU0lNUExFWCxNVUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAyMjkwCiAgICAg ICAgZXRoZXIgMDA6MTk6ZDI6OWY6MzE6YzAKICAgICAgICBtZWRpYTogSUVFRSA4 MDIuMTEgV2lyZWxlc3MgRXRoZXJuZXQgYXV0b3NlbGVjdCBtb2RlIDExZwogICAg ICAgIHN0YXR1czogYXNzb2NpYXRlZApsbzA6IGZsYWdzPTgwNDk8VVAsTE9PUEJB Q0ssUlVOTklORyxNVUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAxNjM4NAogICAgICAg IG9wdGlvbnM9MzxSWENTVU0sVFhDU1VNPgogICAgICAgIGluZXQgMTI3LjAuMC4x IG5ldG1hc2sgMHhmZjAwMDAwMAp3bGFuMDogZmxhZ3M9ODg0MzxVUCxCUk9BRENB U1QsUlVOTklORyxTSU1QTEVYLE1VTFRJQ0FTVD4gbWV0cmljIDAgbXR1IDE1MDAK ICAgICAgICBldGhlciAwMDoxOTpkMjo5ZjozMTpjMAogICAgICAgIGluZXQgMC4w LjAuMCBuZXRtYXNrIDB4ZmYwMDAwMDAgYnJvYWRjYXN0IDI1NS4yNTUuMjU1LjI1 NQogICAgICAgIG1lZGlhOiBJRUVFIDgwMi4xMSBXaXJlbGVzcyBFdGhlcm5ldCBh dXRvc2VsZWN0IG1vZGUgMTFnCiAgICAgICAgc3RhdHVzOiBhc3NvY2lhdGVkCiAg ICAgICAgc3NpZCBUUC1MSU5LXzM0MEE5QSBjaGFubmVsIDEgKDI0MTIgTUh6IDEx ZykgYnNzaWQgNzQ6ZWE6M2E6MzQ6MGE6OWEKICAgICAgICBjb3VudHJ5IFVTIGF1 dGhtb2RlIE9QRU4gcHJpdmFjeSBPTiBkZWZ0eGtleSAxIHdlcGtleSAxOjQwLWJp dAogICAgICAgIHR4cG93ZXIgMCBibWlzcyA3IHNjYW52YWxpZCA2MCBwcm90bW9k ZSBDVFMK ------------D1Ghkj6lV57h7diO5qoA0o Content-Disposition: attachment; filename=rc.conf Content-Type: application/octet-stream; name=rc.conf Content-Transfer-Encoding: Base64 aG9zdG5hbWU9ImZic2QudDYwLmNwdSIKCndsYW5zX3dwaTA9IndsYW4wIgpkZWZh dWx0cm91dGVyPSIxOTIuMTY4LjEuMSIKaWZjb25maWdfd2xhbjA9Im1vZGUgMTFn IGJzc2lkIDc0OmVhOjNhOjM0OjBhOjlhIHdlcG1vZGUgb24gd2VwdHhrZXkgMSB3 ZXBrZXkgMToweDExMTExMTExMTEgREhDUCIK ------------D1Ghkj6lV57h7diO5qoA0o Content-Disposition: attachment; filename=loader.conf Content-Type: application/octet-stream; name=loader.conf Content-Transfer-Encoding: Base64 ZmlybXdhcmVfbG9hZD0iWUVTIgp3cGlmd19sb2FkPSJZRVMiCmlmX3dwaV9sb2Fk PSJZRVMiCndsYW5fd2VwX2xvYWQ9IllFUyIKbGVnYWwuaW50ZWxfd3BpLmxpY2Vu c2VfYWNrPTEKaWZfZW1fbG9hZD0iWUVTIgo= ------------D1Ghkj6lV57h7diO5qoA0o Content-Disposition: attachment; filename=startlog Content-Type: application/octet-stream; name=startlog Content-Transfer-Encoding: Base64 U2V0dGluZyBob3N0bmFtZTogZmJzZC50NjAuY3B1LgppZWVlODAyMTFfbG9hZF9t b2R1bGU6IGxvYWQgdGhlIHdsYW5fYW1yciBtb2R1bGUgYnkgaGFuZCBmb3Igbm93 Lgp3bGFuMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MTk6ZDI6OWY6MzE6YzAKd3Bp MDogdGltZW91dCByZXNldHRpbmcgVHggcmluZyAxCndwaTA6IHRpbWVvdXQgcmVz ZXR0aW5nIFR4IHJpbmcgMwp3cGkwOiB0aW1lb3V0IHJlc2V0dGluZyBUeCByaW5n IDQKbWljcm9jb2RlIGFsaXZlIG5vdGlmaWNhdGlvbiB2ZXJzaW9uIDEwZTAyIGFs aXZlIDEKbWljcm9jb2RlIGFsaXZlIG5vdGlmaWNhdGlvbiB2ZXJzaW9uIDEwZTAy IGFsaXZlIDEKd3BpX25ld3N0YXRlOiBJTklUIC0+IFNDQU4gZmxhZ3MgMHgwClN0 YXJ0aW5nIE5ldHdvcms6IGxvMCB3cGkwLgpsbzA6IGZsYWdzPTgwNDk8VVAsTE9P UEJBQ0ssUlVOTklORyxNVUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAxNjM4NAogICAg ICAgIG9wdGlvbnM9MzxSWENTVU0sVFhDU1VNPgogICAgICAgIGluZXQgMTI3LjAu MC4xIG5ldG1hc2sgMHhmZjAwMDAwMAp3cGkwOiBmbGFncz04ODQzPFVQLEJST0FE Q0FTVCxSVU5OSU5HLFNJTVBMRVgsTVVMVElDQVNUPiBtZXRyaWMgMCBtdHUgMjI5 MAogICAgICAgIGV0aGVyIDAwOjE5OmQyOjlmOjMxOmMwCiAgICAgICAgbWVkaWE6 IElFRUUgODAyLjExIFdpcmVsZXNzIEV0aGVybmV0IGF1dG9zZWxlY3QgbW9kZSAx MWcKICAgICAgICBzdGF0dXM6IGFzc29jaWF0ZWQKd3BpX25ld3N0YXRlOiBTQ0FO IC0+IEFVVEggZmxhZ3MgMHgwCmNvbmZpZyBjaGFuIDEgZmxhZ3MgODAwNSBjY2sg ZiBvZmRtIDE1CndwaV9uZXdzdGF0ZTogQVVUSCAtPiBBU1NPQyBmbGFncyAweDAK d3BpX25ld3N0YXRlOiBBU1NPQyAtPiBSVU4gZmxhZ3MgMHgwCmNvbmZpZyBjaGFu IDEgZmxhZ3MgODAzNQp3bGFuMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQCnJv dXRlOiB3cml0aW5nIHRvIHJvdXRpbmcgc29ja2V0OiBOZXR3b3JrIGlzIHVucmVh Y2hhYmxlCmFkZCBuZXQgZGVmYXVsdDogZ2F0ZXdheSAxOTIuMTY4LjcuNzogTmV0 d29yayBpcyB1bnJlYWNoYWJsZQpTdGFydGluZyBkZXZkLgp3cGkwOiBuZWVkIG11 bHRpY2FzdCB1cGRhdGUgY2FsbGJhY2sKREhDUERJU0NPVkVSIG9uIHdsYW4wIHRv IDI1NS4yNTUuMjU1LjI1NSBwb3J0IDY3IGludGVydmFsIDQKREhDUERJU0NPVkVS IG9uIHdsYW4wIHRvIDI1NS4yNTUuMjU1LjI1NSBwb3J0IDY3IGludGVydmFsIDYK REhDUERJU0NPVkVSIG9uIHdsYW4wIHRvIDI1NS4yNTUuMjU1LjI1NSBwb3J0IDY3 IGludGVydmFsIDEyCkRIQ1BESVNDT1ZFUiBvbiB3bGFuMCB0byAyNTUuMjU1LjI1 NS4yNTUgcG9ydCA2NyBpbnRlcnZhbCAxOApESENQRElTQ09WRVIgb24gd2xhbjAg dG8gMjU1LjI1NS4yNTUuMjU1IHBvcnQgNjcgaW50ZXJ2YWwgOQpESENQRElTQ09W RVIgb24gd2xhbjAgdG8gMjU1LjI1NS4yNTUuMjU1IHBvcnQgNjcgaW50ZXJ2YWwg MTIKTm8gREhDUE9GRkVSUyByZWNlaXZlZC4KTm8gd29ya2luZyBsZWFzZXMgaW4g cGVyc2lzdGVudCBkYXRhYmFzZSAtIHNsZWVwaW5nLgoKV2FpdGluZyAzMHMgZm9y IHRoZSBkZWZhdWx0IHJvdXRlIGludGVyZmFjZTogLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4KRUxGIGxkY29uZmlnIHBhdGg6IC9saWIgL3Vzci9saWIgL3Vz ci9saWIvY29tcGF0IC91c3IvbG9jYWwvbGliIC91c3IvbG9jYWwvbGliIC8KdXNy L2xvY2FsL2xpYi9nY2M0NCAvdXNyL2xvY2FsL2xpYi9nY2M0NSAvdXNyL2xvY2Fs L2xpYi93aW5lCmEub3V0IGxkY29uZmlnIHBhdGg6IC91c3IvbGliL2FvdXQgL3Vz ci9saWIvY29tcGF0L2FvdXQKQ3JlYXRpbmcgYW5kL29yIHRyaW1taW5nIGxvZyBm aWxlcy4KU3RhcnRpbmcgc3lzbG9nZC4K ------------D1Ghkj6lV57h7diO5qoA0o-- From owner-freebsd-stable@FreeBSD.ORG Sat Nov 13 09:03:36 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 2EE9B106566B; Sat, 13 Nov 2010 09:03:36 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id 6E6A28FC14; Sat, 13 Nov 2010 09:03:35 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id C08C1A68243; Sat, 13 Nov 2010 17:03:31 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id EsoYoFKCCbOW; Sat, 13 Nov 2010 17:03:23 +0800 (CST) Received: from delta.delphij.net (c-76-102-26-215.hsd1.ca.comcast.net [76.102.26.215]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 6FFA5A67DDF; Sat, 13 Nov 2010 17:03:22 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:subject:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=YgVXIWFD7GB8650ZRU+vaAi1oDuGu/Y4ysNEbCsfPhOfNHgGIz9tBdc6VOOakEVfx p/Z7K55MIsMK9O5kWulyQ== Message-ID: <4CDE5453.1020400@delphij.net> Date: Sat, 13 Nov 2010 01:03:15 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.15) Gecko/20101028 Thunderbird/3.0.10 ThunderBrowse/3.3.2 MIME-Version: 1.0 To: FreeBSD Current , FreeBSD-STABLE Mailing List X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: Call for Area SATA II RAID controller testers [Fwd: svn commit: r215234 - head/sys/dev/arcmsr] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2010 09:03:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I have just committed a new vendor release of arcmsr(4) driver. This is intended for 8.2-RELEASE so please test if you could. Thanks in advance! (Note: I have a tarball at http://people.freebsd.org/~delphij/misc/arcmsr.tar.xz which can be used for 8.x system, untar over /usr/src and rebuild the kernel or module depending on your configuration). - -------- Original Message -------- Subject: svn commit: r215234 - head/sys/dev/arcmsr Date: Sat, 13 Nov 2010 08:58:36 +0000 (UTC) From: Xin LI To: src-committers@FreeBSD.ORG, svn-src-all@FreeBSD.ORG, svn-src-head@FreeBSD.ORG Author: delphij Date: Sat Nov 13 08:58:36 2010 New Revision: 215234 URL: http://svn.freebsd.org/changeset/base/215234 Log: Update to vendor release 1.20.00.19. Bug fixes: * Fixed "inquiry data fails comparion at DV1 step" * Fixed bad range input in bus_alloc_resource for ADAPTER_TYPE_B * Fixed arcmsr driver prevent arcsas support for Areca SAS HBA ARC13x0 Many thanks to Areca for continuing to support FreeBSD. This commit is intended for MFC before 8.2-RELEASE. Submitted by: Ching-Lung Huang -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJM3lRTAAoJEATO+BI/yjfBs3wH/24ViOUPwdDjr9lDsX6RaWCQ Ux+9YsekrXLVks61zH8B1dW1rXmthk+aiXpE223UYkcb2M5sLgOQCBYlSDoSwJXu q8iLLZ9Dg6hWpLiS1u6sCj3jjsQbsDVuW1BCrCTSr/eOp6AbXI19GEDouPxVKkt3 wc1amh3eo6ZQAWnxksk+6/HK4nGJOQhjuEC8llybSsImeqqzoEGhRyqJVGa3NO7q fZfTX108QItRmx9Uavh3/2Sa4WA9RWWky+QUSg3hPZg1kNSYJOHuCHgEQIGEE+9R qG38IjHP+NPw0jZVAE7Qap0rA/iMY5FOKeLTjH0PvRBsFeRiPP22KRvdf8eQBM8= =X4q7 -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Sat Nov 13 09:16: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 44DD11065670 for ; Sat, 13 Nov 2010 09:16:52 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id D52D68FC08 for ; Sat, 13 Nov 2010 09:16:51 +0000 (UTC) Received: by fxm19 with SMTP id 19so2869531fxm.13 for ; Sat, 13 Nov 2010 01:16:51 -0800 (PST) Received: by 10.223.106.134 with SMTP id x6mr2423376fao.66.1289639810984; Sat, 13 Nov 2010 01:16:50 -0800 (PST) Received: from julie.lab.techwires.net (dslb-088-065-223-045.pools.arcor-ip.net [88.65.223.45]) by mx.google.com with ESMTPS id 14sm286882fas.20.2010.11.13.01.16.49 (version=SSLv3 cipher=RC4-MD5); Sat, 13 Nov 2010 01:16:49 -0800 (PST) Sender: Bernhard Schmidt From: Bernhard Schmidt To: "Yue Wu" Date: Sat, 13 Nov 2010 10:13:06 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.5.3; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201011131013.06685.bschmidt@freebsd.org> Cc: freebsd-stable@freebsd.org Subject: Re: Can't use wireless networking after upgrade the world recently X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Nov 2010 09:16:52 -0000 On Saturday 13 November 2010 08:32:05 Yue Wu wrote: > Hi list, > > As the title, my settings for wireless networking worked fine before > upgrade to the yesterday stable src, don't know why now it doesn't work > anymore. I've attached the startup's log, loader.conf, rc.conf, and output > of ifconfig(trancated useless parts of them as needed). > > any info is needed? plz let me know. > > Sorry for my poor English, plz let me know if I didn't describe clearly. Can you try that with the wlan_amrr module loaded? Adding it to loader.conf should be sufficient. -- Bernhard From owner-freebsd-stable@FreeBSD.ORG Sat Nov 13 09:34: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 8CAC4106566B; Sat, 13 Nov 2010 09:34:14 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id AE7708FC14; Sat, 13 Nov 2010 09:34:13 +0000 (UTC) Received: by bwz2 with SMTP id 2so3794627bwz.13 for ; Sat, 13 Nov 2010 01:34:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=JYmhMzNeU5OnbnDeUrtS0qRDtJv+dv+6J3HXRmLkOLc=; b=blUU6zzlg0GENwyADU+RZS0V1/ejTnubAGC57nrxVtp7Qjqj4a7aDstkxbslKAEOqh cN/ZpaeXYHpO9y0hhjWC/Hz/yK8p6MJoeFQeBnlBFazkLjpmp9wR/7DVq7g4NiDu8Zsn g4uaAbQAmMFXgrjoT0UjTg/+tryGKpw+GTiMI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=EyHpdeynSoto2XbB2vJRTb08CQJ2MTZNPe5HtvcQibh7KO2SGt6Ef1JJ4oe1YMVoDY q4a5+dkiJRnB7GJsJBmZYWHS47njKIoYgetQES9fF/e8Oeao/2vXe15KbRBhScv4K0JK rW2OoG/RacUEbaakWnj/XMgvPvSW0HykSyNtQ= Received: by 10.204.116.74 with SMTP id l10mr3840744bkq.113.1289640851774; Sat, 13 Nov 2010 01:34:11 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 4sm1950121bki.1.2010.11.13.01.34.08 (version=SSLv3 cipher=RC4-MD5); Sat, 13 Nov 2010 01:34:09 -0800 (PST) Sender: Alexander Motin Message-ID: <4CDE5B8C.4000102@FreeBSD.org> Date: Sat, 13 Nov 2010 11:34:04 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Brandon Gooch References: <4CD45209.5010607@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org, FreeBSD-Current , FreeBSD Stable Subject: Re: Sense fetching [Was: cdrtools /devel ...] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Nov 2010 09:34:14 -0000 Brandon Gooch wrote: > 2010/11/5 Alexander Motin : >> Hi. >> >> I've reviewed tests that scgcheck does to SCSI subsystem. It shown >> combination of several issues in both CAM, ahci(4) and cdrtools itself. >> Several small patches allow us to pass most of that tests: >> http://people.freebsd.org/~mav/sense/ >> >> ahci_resid.patch: Add support for reporting residual length on data >> underrun. SCSI commands often returns results shorter then expected. >> Returned value allows application to know/check how much data it really >> has. It is also important for sense fetching, as ATAPI and USB devices >> return sense as data in response to REQUEST_SENSE command. >> >> sense_resid.patch: When manually requesting sense data (ATAPI or USB), >> request only as much data as user requested (not the fixed structure >> size), and return respective sense residual length. >> >> pass_autosence.patch: Unless CAM_DIS_AUTOSENSE is set, always fetch >> sense if not done by SIM, independently of CAM_PASS_ERR_RECOVER. As soon >> as device freeze released before returning to user-level, user-level >> application by definition can't reliably fetch sense data if some other >> application (like hald) tries to access device same time. >> >> cdrtools.patch: Make libscg (part of cdrtools) on FreeBSD to submit >> wanted sense length to CAM and do not clear sense return buffer. It is >> mostly cosmetics, important probably only for scgcheck. >> >> Testers and reviewers welcome. I am especially interested in opinion >> about pass_autosence.patch -- may be we should lower sense fetching even >> deeper, to make it work for all cam_periph_runccb() consumers. > > Hey mav, sorry to chime in after so long here, but have some of these > patches been committed (as of r215179)? > > Which patches are still applicable for testing? I assume the cdrtools > patch for sure... Now uncommitted pass_autosence.patch and possibly cdrtools.patch. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Sat Nov 13 10:29: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 AECBF1065673; Sat, 13 Nov 2010 10:29:10 +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 921488FC12; Sat, 13 Nov 2010 10:29:09 +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 MAA11999; Sat, 13 Nov 2010 12:29:08 +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 1PHDM4-000Mtu-1O; Sat, 13 Nov 2010 12:29:08 +0200 Message-ID: <4CDE6823.6080907@freebsd.org> Date: Sat, 13 Nov 2010 12:27:47 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Martin Matuska References: <4CDD2F5F.2000902@freebsd.org> <4CDD4EB4.40004@freebsd.org> <4CDDF77B.90708@FreeBSD.org> In-Reply-To: <4CDDF77B.90708@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.1-STABLE: problem with unmounting ZFS snapshots X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Nov 2010 10:29:10 -0000 on 13/11/2010 04:27 Martin Matuska said the following: > Yes, this is indeed a leak introduced by importing onnv revision 9214 > and it exists in perforce as well - very easy to reproduce. > > # mount -t zfs test@t1 /mnt > # umount /mnt (-> hang) > > http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6604992 > http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6810367 > > This is not compatible with mounting snapshots outside mounted ZFS and I > was not able to reproduce the errors defined in 6604992 and 6810367 > (they are Solaris-specific). I suggest we comment out this code (from > head, later MFC and p4 as well). > > Patch (should work with HEAD and 8-STABLE): > http://people.freebsd.org/~mm/patches/zfs/zfs_vfsops.c.patch Not quite sure, but perhaps it's better to make the logic in each place match the other. That is, I see that the code does hold on a filesystem of a covered vnode, but does rele on a parent ZFS filesystem. Or is this kind of protection not needed at all for FreeBSD? -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sat Nov 13 11:06:33 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 0BAFB106564A; Sat, 13 Nov 2010 11:06:33 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [IPv6:2a01:4f8:100:1043::3]) by mx1.freebsd.org (Postfix) with ESMTP id 906F18FC0A; Sat, 13 Nov 2010 11:06:32 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.1]) by mail.vx.sk (Postfix) with ESMTP id B9FBE122D76; Sat, 13 Nov 2010 12:06:31 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk ([127.0.0.1]) by core.vx.sk (mail.vx.sk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8gpd45QMWnIz; Sat, 13 Nov 2010 12:06:27 +0100 (CET) Received: from [10.9.8.1] (188-167-78-139.dynamic.chello.sk [188.167.78.139]) by mail.vx.sk (Postfix) with ESMTPSA id 0D0E3122D5E; Sat, 13 Nov 2010 12:06:27 +0100 (CET) Message-ID: <4CDE7133.6010803@FreeBSD.org> Date: Sat, 13 Nov 2010 12:06:27 +0100 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sk; rv:1.8.1.23) Gecko/20090812 Lightning/0.9 Thunderbird/2.0.0.23 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Andriy Gapon References: <4CDD2F5F.2000902@freebsd.org> <4CDD4EB4.40004@freebsd.org> <4CDDF77B.90708@FreeBSD.org> <4CDE6823.6080907@freebsd.org> In-Reply-To: <4CDE6823.6080907@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.1-STABLE: problem with unmounting ZFS snapshots X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Nov 2010 11:06:33 -0000 No, this is not good for us. Solaris does not allow "mounting" of snapshots on any vnode, like we do. Solaris has them only in .zfs/snapshots. This allows us to have read-only mounts without even mounting the parent zfs. Before v15 we have been happy with that code and had no issues :-) I have a very simple testcase where just fixing the VFS_RELE breaks our forced unmount. Let's say we use the correct VFS_RELE in zfs_vfsops.c: VFS_RELE(vfsp->mnt_vnodecovered->v_vfsp); Now let's say you have a mounted filesystem (e.g. md) under /mnt: /dev/md5 on /mnt (ufs, local) # mkdir /mnt/test # mount -t zfs tank@t2 /mnt/test # umount -f /mnt Now you will hang because the second VFS_HOLD. So I stick to my opinion that this "extra protection" is more a problem than a solution in our case and it should be commented out. Dňa 13.11.2010 11:27, Andriy Gapon wrote / napísal(a): > on 13/11/2010 04:27 Martin Matuska said the following: >> Yes, this is indeed a leak introduced by importing onnv revision 9214 >> and it exists in perforce as well - very easy to reproduce. >> >> # mount -t zfs test@t1 /mnt >> # umount /mnt (-> hang) >> >> http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6604992 >> http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6810367 >> >> This is not compatible with mounting snapshots outside mounted ZFS and I >> was not able to reproduce the errors defined in 6604992 and 6810367 >> (they are Solaris-specific). I suggest we comment out this code (from >> head, later MFC and p4 as well). >> >> Patch (should work with HEAD and 8-STABLE): >> http://people.freebsd.org/~mm/patches/zfs/zfs_vfsops.c.patch > > Not quite sure, but perhaps it's better to make the logic in each place match > the other. That is, I see that the code does hold on a filesystem of a covered > vnode, but does rele on a parent ZFS filesystem. > Or is this kind of protection not needed at all for FreeBSD? > From owner-freebsd-stable@FreeBSD.ORG Sat Nov 13 11:11: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 856F21065701; Sat, 13 Nov 2010 11:11:19 +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 6626C8FC08; Sat, 13 Nov 2010 11:11:17 +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 NAA12371; Sat, 13 Nov 2010 13:11:16 +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 1PHE0q-000Mwy-MH; Sat, 13 Nov 2010 13:11:16 +0200 Message-ID: <4CDE7203.7090507@freebsd.org> Date: Sat, 13 Nov 2010 13:09:55 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Martin Matuska References: <4CDD2F5F.2000902@freebsd.org> <4CDD4EB4.40004@freebsd.org> <4CDDF77B.90708@FreeBSD.org> <4CDE6823.6080907@freebsd.org> <4CDE7133.6010803@FreeBSD.org> In-Reply-To: <4CDE7133.6010803@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.1-STABLE: problem with unmounting ZFS snapshots X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Nov 2010 11:11:19 -0000 on 13/11/2010 13:06 Martin Matuska said the following: > No, this is not good for us. Solaris does not allow "mounting" of > snapshots on any vnode, like we do. Solaris has them only in > .zfs/snapshots. This allows us to have read-only mounts without even > mounting the parent zfs. > > Before v15 we have been happy with that code and had no issues :-) > > I have a very simple testcase where just fixing the VFS_RELE breaks our > forced unmount. Let's say we use the correct VFS_RELE in zfs_vfsops.c: > VFS_RELE(vfsp->mnt_vnodecovered->v_vfsp); > > Now let's say you have a mounted filesystem (e.g. md) under /mnt: > /dev/md5 on /mnt (ufs, local) > > # mkdir /mnt/test > # mount -t zfs tank@t2 /mnt/test > # umount -f /mnt > > Now you will hang because the second VFS_HOLD. Hang here would be bad, I agree. But I think that the umount shouldn't succeed either, in this case. > So I stick to my opinion > that this "extra protection" is more a problem than a solution in our > case and it should be commented out. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sat Nov 13 11:21: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 A350D1065679; Sat, 13 Nov 2010 11:21:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 3794E8FC28; Sat, 13 Nov 2010 11:21:17 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id oADBL47a079627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Nov 2010 13:21:04 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id oADBL4hj036568; Sat, 13 Nov 2010 13:21:04 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oADBL4tO036567; Sat, 13 Nov 2010 13:21:04 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 13 Nov 2010 13:21:04 +0200 From: Kostik Belousov To: Andriy Gapon Message-ID: <20101113112104.GE2392@deviant.kiev.zoral.com.ua> References: <4CDD2F5F.2000902@freebsd.org> <4CDD4EB4.40004@freebsd.org> <4CDDF77B.90708@FreeBSD.org> <4CDE6823.6080907@freebsd.org> <4CDE7133.6010803@FreeBSD.org> <4CDE7203.7090507@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QrrxbCYKnJeJBlX9" Content-Disposition: inline In-Reply-To: <4CDE7203.7090507@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org, Martin Matuska Subject: Re: 8.1-STABLE: problem with unmounting ZFS snapshots X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Nov 2010 11:21:18 -0000 --QrrxbCYKnJeJBlX9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 13, 2010 at 01:09:55PM +0200, Andriy Gapon wrote: > on 13/11/2010 13:06 Martin Matuska said the following: > > No, this is not good for us. Solaris does not allow "mounting" of > > snapshots on any vnode, like we do. Solaris has them only in > > .zfs/snapshots. This allows us to have read-only mounts without even > > mounting the parent zfs. > >=20 > > Before v15 we have been happy with that code and had no issues :-) > >=20 > > I have a very simple testcase where just fixing the VFS_RELE breaks our > > forced unmount. Let's say we use the correct VFS_RELE in zfs_vfsops.c: > > VFS_RELE(vfsp->mnt_vnodecovered->v_vfsp); > >=20 > > Now let's say you have a mounted filesystem (e.g. md) under /mnt: > > /dev/md5 on /mnt (ufs, local) > >=20 > > # mkdir /mnt/test > > # mount -t zfs tank@t2 /mnt/test > > # umount -f /mnt > >=20 > > Now you will hang because the second VFS_HOLD. >=20 > Hang here would be bad, I agree. > But I think that the umount shouldn't succeed either, in this case. Normal unmount indeed shall not succeed in this case, because mount adds a reference to the covered vnode. But forced unmount should be allowed to proceed. After unmount, you can use fsid to unmount the lower mount point. >=20 > > So I stick to my opinion > > that this "extra protection" is more a problem than a solution in our > > case and it should be commented out. >=20 >=20 > --=20 > Andriy Gapon > _______________________________________________ > 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" --QrrxbCYKnJeJBlX9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzedJ8ACgkQC3+MBN1Mb4iVbACg9BjzaWe4CKTTgoiDq/g3eJab gxIAoPIu6gsaPqGxSYGORw1XUPtuAgSx =P5Rh -----END PGP SIGNATURE----- --QrrxbCYKnJeJBlX9-- From owner-freebsd-stable@FreeBSD.ORG Sat Nov 13 11:26: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 B7D6D1065695; Sat, 13 Nov 2010 11:26:48 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8C9258FC20; Sat, 13 Nov 2010 11:26:47 +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 NAA12514; Sat, 13 Nov 2010 13:26:45 +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 1PHEFo-000MyQ-NM; Sat, 13 Nov 2010 13:26:44 +0200 Message-ID: <4CDE75A4.8050702@freebsd.org> Date: Sat, 13 Nov 2010 13:25:24 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Kostik Belousov References: <4CDD2F5F.2000902@freebsd.org> <4CDD4EB4.40004@freebsd.org> <4CDDF77B.90708@FreeBSD.org> <4CDE6823.6080907@freebsd.org> <4CDE7133.6010803@FreeBSD.org> <4CDE7203.7090507@freebsd.org> <20101113112104.GE2392@deviant.kiev.zoral.com.ua> In-Reply-To: <20101113112104.GE2392@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org, Martin Matuska Subject: Re: 8.1-STABLE: problem with unmounting ZFS snapshots X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Nov 2010 11:26:48 -0000 on 13/11/2010 13:21 Kostik Belousov said the following: > On Sat, Nov 13, 2010 at 01:09:55PM +0200, Andriy Gapon wrote: >> on 13/11/2010 13:06 Martin Matuska said the following: >>> No, this is not good for us. Solaris does not allow "mounting" of >>> snapshots on any vnode, like we do. Solaris has them only in >>> .zfs/snapshots. This allows us to have read-only mounts without even >>> mounting the parent zfs. >>> >>> Before v15 we have been happy with that code and had no issues :-) >>> >>> I have a very simple testcase where just fixing the VFS_RELE breaks our >>> forced unmount. Let's say we use the correct VFS_RELE in zfs_vfsops.c: >>> VFS_RELE(vfsp->mnt_vnodecovered->v_vfsp); >>> >>> Now let's say you have a mounted filesystem (e.g. md) under /mnt: >>> /dev/md5 on /mnt (ufs, local) >>> >>> # mkdir /mnt/test >>> # mount -t zfs tank@t2 /mnt/test >>> # umount -f /mnt >>> >>> Now you will hang because the second VFS_HOLD. >> >> Hang here would be bad, I agree. >> But I think that the umount shouldn't succeed either, in this case. > Normal unmount indeed shall not succeed in this case, because mount > adds a reference to the covered vnode. But forced unmount should be > allowed to proceed. > > After unmount, you can use fsid to unmount the lower mount point. Ah, I see now, thank you for the explanation. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sat Nov 13 18:19: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 56A531065670; Sat, 13 Nov 2010 18:19:05 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 635698FC13; Sat, 13 Nov 2010 18:19:04 +0000 (UTC) Received: by wwj40 with SMTP id 40so1127917wwj.31 for ; Sat, 13 Nov 2010 10:19:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gLWMC3n9RgOVqCs8HlNzEPZkHAbNYz215ojbg+6SC2s=; b=lG54Cz4n/BjL8cvnRO18e5p5T+oBkYWGF2a7elEggxx3AUvhwpjkOSuVWBSiqegPu1 6OIusNA6ne1AIHZPKZS9SYVcLBI4sOpSTLMg+uREeNkJBF66gkP0AV4isvT6yAkdjoot CASiUn51FNGdIiSn7KhJC6mJgtyUE6MVkeHDg= 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=b8nZ69wHMurqKcAqlXbaNMpKGGpn9A+E2utgzQjkWBnklR/dqZLsSBxkQQQ7FM/IG1 +Tk4eZlH74RiGyDVAG+MPAsM/vzX3wRDblJXecHNVIBW1AgBdtHbQhwDFKOwSKtjtK4q P2Pz8lZJHbx8jlbfsnAux2YgifnLoHOMXprmA= MIME-Version: 1.0 Received: by 10.216.93.9 with SMTP id k9mr3250012wef.89.1289672343001; Sat, 13 Nov 2010 10:19:03 -0800 (PST) Received: by 10.216.12.80 with HTTP; Sat, 13 Nov 2010 10:19:02 -0800 (PST) In-Reply-To: <4CDE5B8C.4000102@FreeBSD.org> References: <4CD45209.5010607@FreeBSD.org> <4CDE5B8C.4000102@FreeBSD.org> Date: Sat, 13 Nov 2010 12:19:02 -0600 Message-ID: From: Brandon Gooch To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-scsi@freebsd.org, FreeBSD-Current , FreeBSD Stable Subject: Re: Sense fetching [Was: cdrtools /devel ...] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Nov 2010 18:19:05 -0000 On Sat, Nov 13, 2010 at 3:34 AM, Alexander Motin wrote: > Brandon Gooch wrote: >> 2010/11/5 Alexander Motin : >>> Hi. >>> >>> I've reviewed tests that scgcheck does to SCSI subsystem. It shown >>> combination of several issues in both CAM, ahci(4) and cdrtools itself. >>> Several small patches allow us to pass most of that tests: >>> http://people.freebsd.org/~mav/sense/ >>> >>> ahci_resid.patch: Add support for reporting residual length on data >>> underrun. SCSI commands often returns results shorter then expected. >>> Returned value allows application to know/check how much data it really >>> has. It is also important for sense fetching, as ATAPI and USB devices >>> return sense as data in response to REQUEST_SENSE command. >>> >>> sense_resid.patch: When manually requesting sense data (ATAPI or USB), >>> request only as much data as user requested (not the fixed structure >>> size), and return respective sense residual length. >>> >>> pass_autosence.patch: Unless CAM_DIS_AUTOSENSE is set, always fetch >>> sense if not done by SIM, independently of CAM_PASS_ERR_RECOVER. As soo= n >>> as device freeze released before returning to user-level, user-level >>> application by definition can't reliably fetch sense data if some other >>> application (like hald) tries to access device same time. >>> >>> cdrtools.patch: Make libscg (part of cdrtools) on FreeBSD to submit >>> wanted sense length to CAM and do not clear sense return buffer. It is >>> mostly cosmetics, important probably only for scgcheck. >>> >>> Testers and reviewers welcome. I am especially interested in opinion >>> about pass_autosence.patch -- may be we should lower sense fetching eve= n >>> deeper, to make it work for all cam_periph_runccb() consumers. >> >> Hey mav, sorry to chime in after so long here, but have some of these >> patches been committed (as of r215179)? >> >> Which patches are still applicable for testing? I assume the cdrtools >> patch for sure... > > Now uncommitted pass_autosence.patch and possibly cdrtools.patch. > OK. Patched kernel and cdrtools has resulted in a working cdrecord (burned an ISO successfully) and an endless stream of: ... (pass0:ata0:0:0:0): Requesting SCSI sense data (pass0:ata0:0:0:0): SCSI status error (pass0:ata0:0:0:0): Requesting SCSI sense data (pass0:ata0:0:0:0): SCSI status error (pass0:ata0:0:0:0): Requesting SCSI sense data (pass0:ata0:0:0:0): SCSI status error (pass0:ata0:0:0:0): Requesting SCSI sense data (pass0:ata0:0:0:0): SCSI status error ... ad infinitum until I start cdrecord: (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): Requesting SCSI sense data (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:4,8 (Logical unit not ready, long write in progress) (cd0:ata0:0:0:0): Error 16, Unretryable error (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): Requesting SCSI sense data (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:4,8 (Logical unit not ready, long write in progress) (cd0:ata0:0:0:0): Error 16, Unretryable error (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): Requesting SCSI sense data (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:4,8 (Logical unit not ready, long write in progress) (cd0:ata0:0:0:0): Error 16, Unretryable error (pass0:ata0:0:0:0): SCSI status error (pass0:ata0:0:0:0): Requesting SCSI sense data cdrecord output: brandon@x300:~$ sudo cdrecord dev=3D0,0,0 Fedora-14-i686-Live-Desktop.iso (11-13 11:41) cdrecord: No write mode specified. cdrecord: Assuming -sao mode. cdrecord: If your drive does not accept -sao, try -tao. cdrecord: Future versions of cdrecord may have different drive dependent defaults. Cdrecord-ProDVD-ProBD-Clone 3.00 (amd64-unknown-freebsd9.0) Copyright (C) 1995-2010 J=F6rg Schilling scsidev: '0,0,0' scsibus: 0 target: 0 lun: 0 Using libscg version 'schily-0.9'. Device type : Removable CD-ROM Version : 0 Response Format: 2 Capabilities : Vendor_info : 'MATSHITA' Identifikation : 'DVD-RAM UJ-844 ' Revision : 'RC02' Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). Driver flags : MMC-3 SWABAUDIO BURNFREE Supported modes: TAO PACKET SAO cdrecord: Warning: Cannot read drive buffer. cdrecord: Warning: The DMA speed test has been skipped. Starting to write CD/DVD/BD at speed 16 in real SAO mode for single session= . Last chance to quit, starting real write 0 seconds. Operation starts. Turning BURN-Free off cdrecord: WARNING: Drive returns wrong startsec (0) using -150 load: 0.00 cmd: cdrecord 2111 [nanslp] 302.32r 0.12u 1.83s 0% 13380k load: 0.00 cmd: cdrecord 2111 [nanslp] 306.11r 0.12u 1.87s 0% 13380k load: 0.00 cmd: cdrecord 2111 [nanslp] 306.66r 0.12u 1.87s 0% 13380k Track 01: Total bytes read/written: 719323136/719323136 (351232 sectors). After cdrecord completed, the messages reappeared on the console: ... (pass0:ata0:0:0:0): Requesting SCSI sense data (pass0:ata0:0:0:0): SCSI status error (pass0:ata0:0:0:0): Requesting SCSI sense data (pass0:ata0:0:0:0): SCSI status error (pass0:ata0:0:0:0): Requesting SCSI sense data (pass0:ata0:0:0:0): SCSI status error (pass0:ata0:0:0:0): Requesting SCSI sense data (pass0:ata0:0:0:0): SCSI status error ... But most important part: It works, and it burned very quickly! The CD was created, and fully functional (I booted the Fedora image and completed an installation). Let me know what's next... -Brandon From owner-freebsd-stable@FreeBSD.ORG Sat Nov 13 23:02: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 EAFEC1065672 for ; Sat, 13 Nov 2010 23:02:01 +0000 (UTC) (envelope-from TERRY@tmk.com) Received: from server.tmk.com (server.tmk.com [204.141.35.63]) by mx1.freebsd.org (Postfix) with ESMTP id C87FF8FC1C for ; Sat, 13 Nov 2010 23:02:01 +0000 (UTC) Received: from tmk.com by tmk.com (PMDF V6.4 #37010) id <01NU7T8XRYKW00BCHX@tmk.com>; Sat, 13 Nov 2010 18:01:59 -0500 (EST) Date: Sat, 13 Nov 2010 18:00:29 -0500 (EST) From: Terry Kennedy To: freebsd-stable@freebsd.org, freebsd-fs@freebsd.org Message-id: <01NU7TBBN3D000BCHX@tmk.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Cc: Subject: ZFS panic after replacing log device X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Nov 2010 23:02:02 -0000 I'm posting this to the freebsd-stable and freebsd-fs mailing lists. Followups should probably happen on freebsd-fs. I have a ZFS pool configured as: zpool create data raidz da1 da2 da3 da4 da5 raidz da6 da7 da8 da9 da10 raidz da11 da12 da13 da14 da15 spare da16 log da0 where da1-16 are WD2003FYYS drives (2TB RE4) and da0 is a 256GB PCI-Express SSD (name omitted to protect the guilty). The SSD has been dropping offline randomly - it seems that one or more flash modules pop out of their sockets and need to be re-seated frequently for some reason. The most recent time it did that, I replaced the SSD with another one (for some reason, the manufacturer ties the flash modules to a particular controller, so just moving the modules results in an offline SSD and inability to manage it due to "license limits exceeded" or some such nonsense). ZFS wasn't happy with the log device being changed, and reported it as corrupted, with the suggested corrective action being to "zpool clear" it. I did that, and then did a "zpool replace data da0 da0" and it claimed to successfully resilver it. I then did a "zpool scrub" and the scrub completed with no errors. So far, so good. However, any attempt to write to the array results in a near-immediate panic: panic: solaris assert: sm->sm_spare + size <= sm->sm_size, file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/space_map.c, line: 93 cpuid=2 (Screenshot at http://www.tmk.com/transient/zfs-panic.png in case I mis-typed something). This is repeatable across reboot / scrub / test cycles. System is 8-STABLE as of Fri Nov 5 19:08:35 EDT 2010, on-disk pool is version 4/15, same as the kernel. I know that certain operations on log devices aren't supported until pool version 19 or thereabouts, but the error messages and zpool command results gave the impression that what I was doing was supported and worked (when it didn't). If this is truly a "you can't do that in pool version 15", perhaps a warning could be added so users don't get fooled into thinking it worked? I can give a developer remote console / root access to the box if that would help. I have a couple days before I will need to nuke the pool and restore it from backups. Terry Kennedy http://www.tmk.com terry@tmk.com New York, NY USA